diff options
| author | Nick Mathewson <nickm@torproject.org> | 2003-06-12 06:20:20 +0000 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2003-06-12 06:20:20 +0000 |
| commit | 3d538f6d702937c23bec33b3bdd62ff9fba9d2a3 (patch) | |
| tree | 85aa9825023d2933128ec19b5a19cd08926910af | |
| parent | cb2c43d7358d2e933481553a606c845378f3b93c (diff) | |
Add first draft of rendezvous point document
svn:r310
| -rw-r--r-- | doc/rendezvous.txt | 138 |
1 files changed, 138 insertions, 0 deletions
diff --git a/doc/rendezvous.txt b/doc/rendezvous.txt new file mode 100644 index 0000000..b1ef97b --- /dev/null +++ b/doc/rendezvous.txt @@ -0,0 +1,138 @@ + How to make rendezvous points work + 1-11Jun2003 + +1. Overview + + This document provides a design overview for rendezvous points, as + discussed by Nick and Roger after Discex. + + Rendezvous points are an implementation of server anonymity / + location-hidden servers in the onion routing network. There are + three components needed for rendezvous points: + + A) A means for the client ("Alice") to tell a server ("Bob") where + to contact her in order to establish a connection. (Notification) + B) A means for Bob to contact Alice to actually establish the + connection, and for them to communicate later. (Meeting) + C) Necessary glue code so that Alice can view webpages on a + location-hidden webserver, and Bob can run a location-hidden + server with minimal invasive changes. (Application) + + We'll tackle these in order. In all cases, I'll assume that both + Alice and Bob have local OPs. + +2. Notification service + + Bob wants to learn about client requests for communication, but + wants to avoid responding unnecessarily to unauthorized clients. + Bob's proxy opens a circuit, and tells some onion router on that + circuit to expect incoming connections, and notify Bob of them. + + When establishing such a notification point, Bob provides the onion + router with a public "notification" key. The hash of this public + key uniquely identifies Bob, and prevents anybody else from + usurping Bob's notification point in the future. Additionally, Bob + can use the same public key to establish a notification point on + another OR, and Alice can still be confident that Bob is the same + server. + + (The set-up-a-notification-point command should come via a + RELAY_BIND_NOTIFICATION cell. This cell creates a new stream on the + circuit from Bob to the notification point.) + + ORs that support notification run a notification service on a + separate port. When Alice wants to notify Bob of a meeting point, + she connects (directly or via Tor) to the notification port, and + sends the following: + + MEETING REQUEST + Encrypted with server's public key: + Hash of Bob's public key (identifies which Bob to notify) + Initial authentication [optional] + Encrypted with Bob's public key: + Meeting point + Meeting cookie + End-to-end forward key + End-to-end backward key + End-to-end authentication [optional] + + [Add a Nonce or some kind of replay prevention mechanism? -NM] + [Should this use DH instead? -NM] + + The meeting point and meeting cookie allow Bob to contact Alice and + prove his identity; the end-to-end authentication enables Bob to + decide whether to talk to Alice; the initial authentication enables + the meeting point to pre-screen notification requests before + sending them to Bob. (See 3 for a discussion of meeting points; + see 2.1 for a proposed authentication mechanism.) + + When the notification point receives a valid meeting request, it + sends the portion encrypted with Bob's public key along the stream + created by Bob's RELAY_BIND_NOTIFICATION. Bob then, at his + discretion, connects to Alice's meeting point. + +2.1. Proposed authentication for notification services + + Bob makes two short-term secrets SB and SN, and tells the + notification point about SN. Bob gives Alice a cookie consisting + of A,B,C such that H(A|SB)=B and H(A|SN)=C. Alice's initial + authentication is <A,C>; Alice's end-to-end authentication is <A,B>. + + [Maybe] Bob keeps a replay cache of A values, and doesn't allow any + value to be used twice. Over time, Bob rotates SB and SN. + + [Maybe] Each 'A' has an expiration time built in to it. + +3. Meeting points + + For Bob to actually reply to Alice, Alice first establishes a + circuit to an onion router R, and sends a RELAY_BIND_MEETING cell + to that onion router. The RELAY_BIND_MEETING cell contains a + 'Meeting cookie' (MC) that Bob can use to authenticate to R. R + remembers the cookie and associates it with Alice. + + Later, Bob also routes to R and sends R a RELAY_JOIN_MEETING cell + with the meeting cookie MC. After this point, R routes all traffic + from Bob's circuit or Alice's circuit as if the two circuits were + joined: any RELAY cells that are not for a recognized topic are + passed down Alice or Bob's circuit. + + To prevent R from reading their traffic, Alice and Bob use the two + end-to-end keys in Alice's original notification to Bob: Bob uses + the 'forward' key and Alice the 'backward' key. (These keys are + used in addition to the series of encryption keys already in use on + Alice and Bob's circuits.) + + Bob's OP accepts RELAY_BEGIN, RELAY_DATA, RELAY_END, and + RELAY_SENDME cells from Alice. Alice's OP accepts RELAY_DATA, + RELAY_END, and RELAY_SENDME cells from Bob. All RELAY_BEGIN cells + to Bob must have target IP and port of zero; Bob's OP will redirect + them to the actual target IP and port of Bob's server. + + Alice and Bob's OPs disallow CREATE or RELAY_EXTEND cells as usual. + +4. Application interface + +4.1. Application interface: client side + + Because we require that the client interface remain a SOCKS proxy, + we can't have clients explicitly connect to Bob. Instead, we have + the OP map DNS addresses used by the client to the + <Notification point, Bob's PK, Authentication> + tuples needed to establish a connection to Bob. + + [We had earlier hoped encode this information into the DNS address, + but that won't work. The data needed will be at least ~1024 bits + long (for Bob's public key). You'd need over 197 characters to + encode a blob that long, and you'd wind up triggering pathological + cases in a lot of client code. -NM] + + I propose that the client OP receive this mapping information + outside of the Tor protocol: either from true out-of-band entry, or + from protocol-specific transmission. + + (For example of protocol-specific, an HTTP server could include + notification information in reply headers, or cookies, or + something.) + + |