start the process of adding authentication/authorization mechanisms

to the rendezvous process.

also start to handle intro and rend points at ipv6 addresses.

(none of this is implemented yet; this is for discussion.)


svn:r4910
This commit is contained in:
Roger Dingledine 2005-09-06 09:15:32 +00:00
parent c384fa706d
commit f7256b7007

View file

@ -14,26 +14,27 @@ $Id$
Bob does this by anonymously advertising a public key for his Bob does this by anonymously advertising a public key for his
service, along with a list of onion routers to act as "Introduction service, along with a list of onion routers to act as "Introduction
Points" for his service. He creates forward OR circuits to those Points" for his service. He creates forward circuits to those
introduction points, and tells them about his public key. To introduction points, and tells them about his public key. To
connect to Bob, Alice first builds an OR circuit to an OR to act as connect to Bob, Alice first builds a circuit to an OR to act as
her "Rendezvous Point", then connects to one of Bob's chosen her "Rendezvous Point." She then connects to one of Bob's chosen
introduction points, and asks it to tell him about her Rendezvous introduction points, optionally provides authentication or
Point (RP). If Bob chooses to answer, he builds an OR circuit to her authorization information, and asks it to tell him about her Rendezvous
RP, and tells it to connect him to Alice. The RP joints their Point (RP). If Bob chooses to answer, he builds a circuit to her
RP, and tells it to connect him to Alice. The RP joins their
circuits together, and begins relaying cells. Alice's 'BEGIN' circuits together, and begins relaying cells. Alice's 'BEGIN'
cells are received directly by Bob's OP, which responds by cells are received directly by Bob's OP, which passes data to
communication with the local server implementing Bob's service. and from the local server implementing Bob's service.
Below, we describe a network-level specification of this service, Below we describe a network-level specification of this service,
along with interfaces to make this process transparent to Alice along with interfaces to make this process transparent to Alice
(so long as she is using an OP). (so long as she is using an OP).
0.1. Notation, conventions and prerequisites 0.1. Notation, conventions and prerequisites
In the specifications below, we use the same notation as in In the specifications below, we use the same notation as in
"tor-spec.txt". The service specified here also requires the existence of "tor-spec.txt". The service specified here also requires the
an onion routing network as specified in "tor-spec.txt". existence of an onion routing network as specified in that file.
H(x) is a SHA1 digest of x. H(x) is a SHA1 digest of x.
PKSign(SK,x) is a PKCS.1-padded RSA signature of x with SK. PKSign(SK,x) is a PKCS.1-padded RSA signature of x with SK.
@ -49,7 +50,8 @@ $Id$
0.2. Protocol outline 0.2. Protocol outline
1. Bob->Bob's OP: "Offer IP:Port as public-key-name:Port". [configuration] 1. Bob->Bob's OP: "Offer IP:Port as
public-key-name:Port". [configuration]
(We do not specify this step; it is left to the implementor of (We do not specify this step; it is left to the implementor of
Bob's OP.) Bob's OP.)
@ -59,20 +61,22 @@ $Id$
3. Bob's OP->Introduction point via Tor: [introduction setup] 3. Bob's OP->Introduction point via Tor: [introduction setup]
"This pk is me." "This pk is me."
4. Bob's OP->directory service via Tor: publishes Bob's service descriptor 4. Bob's OP->directory service via Tor: publishes Bob's service
[advertisement] descriptor [advertisement]
5. Out of band, Alice receives a y.onion:port address. She opens a 5. Out of band, Alice receives a [x.y.]z.onion:port address.
SOCKS connection to her OP, and requests y.onion:port. She opens a SOCKS connection to her OP, and requests
x.y.z.onion:port.
6. Alice's OP retrieves Bob's descriptor via Tor: [descriptor lookup.] 6. Alice's OP retrieves Bob's descriptor via Tor. [descriptor lookup.]
7. Alice's OP chooses a rendezvous point, opens a circuit to that 7. Alice's OP chooses a rendezvous point, opens a circuit to that
rendezvous point, and establishes a rendezvous circuit. [rendezvous rendezvous point, and establishes a rendezvous circuit. [rendezvous
setup.] setup.]
8. Alice connects to the Introduction point via Tor, and tells it about 8. Alice connects to the Introduction point via Tor, and tells it about
her rendezvous point. (Encrypted to Bob.) [Introduction 1] her rendezvous point and optional authentication/authorization
information. (Encrypted to Bob.) [Introduction 1]
9. The Introduction point passes this on to Bob's OP via Tor, along the 9. The Introduction point passes this on to Bob's OP via Tor, along the
introduction circuit. [Introduction 2] introduction circuit. [Introduction 2]
@ -112,21 +116,47 @@ $Id$
a public/private keypair (stored locally). Periodically, the OP a public/private keypair (stored locally). Periodically, the OP
generates a pair of service descriptors, one "V1" and one "V0". generates a pair of service descriptors, one "V1" and one "V0".
The "V1" descriptor contains: The "V1" descriptor in 0.1.1.6-alpha contains:
V Format byte: set to 255 [1 octet] V Format byte: set to 255 [1 octet]
V Version byte: set to 1 [1 octet] V Version byte: set to 1 [1 octet]
KL Key length [2 octets] KL Key length [2 octets]
PK Bob's public key [KL octets] PK Bob's public key [KL octets]
TS A timestamp [4 octets] TS A timestamp [4 octets]
PROTO Protocol versions: bitmask [2 octets] PROTO Rendezvous protocol versions: bitmask [2 octets]
NA Number of auth mechanisms accepted [1 octet]
For each auth mechanism:
AUTHT The auth type that is supported [2 octets]
AUTHL Length of auth data [1 octet]
AUTHD Auth data [variable]
NI Number of introduction points [2 octets] NI Number of introduction points [2 octets]
For each introduction point: (as in INTRODUCE2 cells) For each introduction point: (as in INTRODUCE2 cells)
IP Rendezvous point's address [4 octets] ATYPE An address type (typically 4) [1 octet]
PORT Rendezvous point's OR port [2 octets] ADDR Introduction point's IP address [4 or 16 octets]
ID Rendezvous point identity ID [20 octets] PORT Introduction point's OR port [2 octets]
KLEN Length of onion key [2 octets] AUTHT The auth type that is supported [2 octets]
KEY Rendezvous point onion key [KLEN octets] AUTHL Length of auth data [1 octet]
AUTHD Auth data [variable]
ID Introduction point identity ID [20 octets]
KLEN Length of onion key [2 octets]
KEY Introduction point onion key [KLEN octets]
SIG Signature of above fields [variable]
The "V1" descriptor in 0.1.1.5-alpha-cvs contains:
V Format byte: set to 255 [1 octet]
V Version byte: set to 1 [1 octet]
KL Key length [2 octets]
PK Bob's public key [KL octets]
TS A timestamp [4 octets]
PROTO Protocol versions: bitmask [2 octets]
NI Number of introduction points [2 octets]
For each introduction point: (as in INTRODUCE2 cells)
IP Introduction point's address [4 octets]
PORT Introduction point's OR port [2 octets]
ID Introduction point identity ID [20 octets]
KLEN Length of onion key [2 octets]
KEY Introduction point onion key [KLEN octets]
SIG Signature of above fields [variable] SIG Signature of above fields [variable]
The "V0" descriptor contains: The "V0" descriptor contains:
@ -141,6 +171,12 @@ $Id$
KL is the length of PK, in octets. (Currently, KL must be 128.) KL is the length of PK, in octets. (Currently, KL must be 128.)
TS is the number of seconds elapsed since Jan 1, 1970. TS is the number of seconds elapsed since Jan 1, 1970.
AUTHT specifies which authentication/authorization mechanism is
required by the hidden service or the introduction point. AUTHD
is arbitrary data that can be associated with an auth approach.
Currently only AUTHT of [00 00] is supported, with an AUTHL of 0.
See section 2 of this document for details on auth mechanisms.
The members of Ipt may be either (a) nicknames, or (b) identity key The members of Ipt may be either (a) nicknames, or (b) identity key
digests, encoded in hex, and prefixed with a '$'. Clients must digests, encoded in hex, and prefixed with a '$'. Clients must
accept both forms. Services must only generate the second form. accept both forms. Services must only generate the second form.
@ -165,6 +201,8 @@ $Id$
HS Hash of session info [20 octets] HS Hash of session info [20 octets]
SIG Signature of above information [variable] SIG Signature of above information [variable]
[XXX011, need to add auth information here. -RD]
To prevent replay attacks, the HS field contains a SHA-1 hash based on the To prevent replay attacks, the HS field contains a SHA-1 hash based on the
shared secret KH between Bob's OP and the introduction point, as shared secret KH between Bob's OP and the introduction point, as
follows: follows:
@ -181,29 +219,34 @@ $Id$
currently associated with PK. On success, the OR sends Bob a currently associated with PK. On success, the OR sends Bob a
RELAY_INTRO_ESTABLISHED cell with an empty payload. RELAY_INTRO_ESTABLISHED cell with an empty payload.
1.4. Bob's OP advertises his service descriptor(s) 1.4. Bob's OP advertises his service descriptor(s).
Bob's OP opens a stream to each directory server's directory port via Tor. Bob's OP opens a stream to each directory server's directory port via Tor.
(He may re-use old circuits for this.) Over this stream, Bob's OP makes (He may re-use old circuits for this.) Over this stream, Bob's OP makes
an HTTP 'POST' request, to a URL "/tor/rendezvous/publish" relative to the an HTTP 'POST' request, to a URL "/tor/rendezvous/publish" relative to the
directory server's root, containing as its body Bob's service descriptor. directory server's root, containing as its body Bob's service descriptor.
Bob should upload a service descriptor for each version format that
is supported in the current Tor network.
Upon receiving a descriptor, the directory server checks the signature, Upon receiving a descriptor, the directory server checks the signature,
and discards the descriptor if the signature does not match the enclosed and discards the descriptor if the signature does not match the enclosed
public key. Next, the directory server checks the timestamp. If the public key. Next, the directory server checks the timestamp. If the
timestamp is more than 24 hours in the past or more than 1 hour in the timestamp is more than 24 hours in the past or more than 1 hour in the
future, or the directory server already has a newer descriptor with the future, or the directory server already has a newer descriptor with the
same public key, the server discards the descriptor. Otherwise, the same public key, the server discards the descriptor. Otherwise, the
server discards any older descriptors with the same public key, and server discards any older descriptors with the same public key and
associates the new descriptor with the public key. The directory server version format, and associates the new descriptor with the public key.
remembers this descriptor for at least 24 hours after its timestamp. At The directory server remembers this descriptor for at least 24 hours
least every 24 hours, Bob's OP uploads a fresh descriptor. after its timestamp. At least every 18 hours, Bob's OP uploads a
fresh descriptor.
1.5. Alice receives a y.onion address 1.5. Alice receives a x.y.z.onion address.
When Alice receives a pointer to a location-hidden service, it is as a When Alice receives a pointer to a location-hidden service, it is as a
hostname of the form "y.onion", where y is a base-32 encoding of a hostname of the form "z.onion" or "y.z.onion" or "x.y.z.onion", where
10-octet hash of Bob's service's public key, computed as follows: z is a base-32 encoding of a 10-octet hash of Bob's service's public
key, computed as follows:
1. Let H = H(PK). 1. Let H = H(PK).
2. Let H' = the first 80 bits of H, considering each octet from 2. Let H' = the first 80 bits of H, considering each octet from
@ -215,22 +258,29 @@ $Id$
need to worry about man-in-the-middle attacks, and because it will make need to worry about man-in-the-middle attacks, and because it will make
handling the url's more convenient.) handling the url's more convenient.)
The string "x", if present, is the base-32 encoding of the
authentication/authorization required by the introduction point.
The string "y", if present, is the base-32 encoding of the
authentication/authorization required by the hidden service.
Omitting a string is taken to mean auth type [00 00].
See section 2 of this document for details on auth mechanisms.
[Yes, numbers are allowed at the beginning. See RFC1123. -NM] [Yes, numbers are allowed at the beginning. See RFC1123. -NM]
1.6. Alice's OP retrieves a service descriptor 1.6. Alice's OP retrieves a service descriptor.
Alice opens a stream to a directory server via Tor, and makes an HTTP GET Alice opens a stream to a directory server via Tor, and makes an HTTP GET
request for the document '/tor/rendezvous/<y>' or '/tor/rendezvous1/<y>', request for the document '/tor/rendezvous/<z>' or '/tor/rendezvous1/<z>',
where '<y> is replaced with the encoding of Bob's public key as described where '<z>' is replaced with the encoding of Bob's public key as described
above. (She may re-use old circuits for this.) The directory replies with above. (She may re-use old circuits for this.) The directory replies with
a 404 HTTP response if it does not recognize <y>, and otherwise returns a 404 HTTP response if it does not recognize <z>, and otherwise returns
Bob's most recently uploaded service descriptor. (If Alice requests Bob's most recently uploaded service descriptor. (If Alice requests
'rendezvous1', the directory server provides a V1 descriptor or a V0 'rendezvous1', the directory server provides a V1 descriptor or a V0
descriptor if no V1 descriptor is available. If Alice requests descriptor if no V1 descriptor is available. If Alice requests
'rendezvous', the directory server returns a V0 descriptor.) 'rendezvous', the directory server returns a V0 descriptor.)
If Alice's OP receives a 404 response, it tries the other directory If Alice's OP receives a 404 response, it tries the other directory
servers, and only fails the lookup if none recognizes the public key hash. servers, and only fails the lookup if none recognize the public key hash.
Upon receiving a service descriptor, Alice verifies with the same process Upon receiving a service descriptor, Alice verifies with the same process
as the directory server uses, described above in section 1.4. as the directory server uses, described above in section 1.4.
@ -254,6 +304,8 @@ $Id$
RC Rendezvous cookie [20 octets] RC Rendezvous cookie [20 octets]
[XXX011 this looks like an auth mechanism. should we generalize here? -RD]
The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by
Alice's OP. Alice's OP.
@ -271,6 +323,7 @@ $Id$
Cleartext Cleartext
PK_ID Identifier for Bob's PK [20 octets] PK_ID Identifier for Bob's PK [20 octets]
[XXX011 want to put intro-level auth info here, but no version. crap. -RD]
Encrypted to Bob's PK: Encrypted to Bob's PK:
RP Rendezvous point's nickname [20 octets] RP Rendezvous point's nickname [20 octets]
@ -287,9 +340,22 @@ $Id$
PORT Rendezvous point's OR port [2 octets] PORT Rendezvous point's OR port [2 octets]
ID Rendezvous point identity ID [20 octets] ID Rendezvous point identity ID [20 octets]
KLEN Length of onion key [2 octets] KLEN Length of onion key [2 octets]
KEY Rendezvous point onion key [KLEN octets] KEY Rendezvous point onion key [KLEN octets]
RC Rendezvous cookie [20 octets] RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets] g^x Diffie-Hellman data, part 1 [128 octets]
OR
VER Version byte: set to 3. [1 octet]
ATYPE An address type (typically 4) [1 octet]
ADDR Introduction point's IP address [4 or 16 octets]
PORT Rendezvous point's OR port [2 octets]
AUTHT The auth type that is supported [2 octets]
AUTHL Length of auth data [1 octet]
AUTHD Auth data [variable]
ID Rendezvous point identity ID [20 octets]
KLEN Length of onion key [2 octets]
KEY Rendezvous point onion key [KLEN octets]
RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets]
PK_ID is the hash of Bob's public key. RP is NUL-padded and terminated, PK_ID is the hash of Bob's public key. RP is NUL-padded and terminated,
and must contain EITHER a nickname, or an identity key digest, encoded in and must contain EITHER a nickname, or an identity key digest, encoded in
@ -326,7 +392,7 @@ $Id$
1.10. Rendezvous 1.10. Rendezvous
Bob's OP build a new Tor circuit ending at Alice's chosen rendezvous Bob's OP builds a new Tor circuit ending at Alice's chosen rendezvous
point, and sends a RELAY_RENDEZVOUS1 cell along this circuit, containing: point, and sends a RELAY_RENDEZVOUS1 cell along this circuit, containing:
RC Rendezvous cookie [20 octets] RC Rendezvous cookie [20 octets]
g^y Diffie-Hellman [128 octets] g^y Diffie-Hellman [128 octets]
@ -377,3 +443,7 @@ $Id$
multiple streams to Bob. Alice SHOULD NOT send RELAY_BEGIN cells for any multiple streams to Bob. Alice SHOULD NOT send RELAY_BEGIN cells for any
other address along her circuit to Bob; if she does, Bob MUST reject them. other address along her circuit to Bob; if she does, Bob MUST reject them.
2.0. Authentication and authorization.
Foo.