[or-cvs] Add first draft of rendezvous point document
nickm at seul.org
Thu Jun 12 06:20:22 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv31747
Add first draft of rendezvous point document
--- NEW FILE: rendezvous.txt ---
How to make rendezvous points work
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
(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:
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:
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
More information about the tor-commits