[or-cvs] start the process of adding authentication/authorization me...
arma at seul.org
arma at seul.org
Tue Sep 6 09:15:34 UTC 2005
Update of /home2/or/cvsroot/tor/doc
In directory moria:/home/arma/work/onion/cvs/tor/doc
Modified Files:
rend-spec.txt
Log Message:
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.)
Index: rend-spec.txt
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/rend-spec.txt,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- rend-spec.txt 27 Jun 2005 20:43:07 -0000 1.28
+++ rend-spec.txt 6 Sep 2005 09:15:32 -0000 1.29
@@ -14,26 +14,27 @@
Bob does this by anonymously advertising a public key for his
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
- connect to Bob, Alice first builds an OR circuit to an OR to act as
- her "Rendezvous Point", then connects to one of Bob's chosen
- introduction points, and asks it to tell him about her Rendezvous
- Point (RP). If Bob chooses to answer, he builds an OR circuit to her
- RP, and tells it to connect him to Alice. The RP joints their
+ connect to Bob, Alice first builds a circuit to an OR to act as
+ her "Rendezvous Point." She then connects to one of Bob's chosen
+ introduction points, optionally provides authentication or
+ authorization information, and asks it to tell him about her Rendezvous
+ 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'
- cells are received directly by Bob's OP, which responds by
- communication with the local server implementing Bob's service.
+ cells are received directly by Bob's OP, which passes data to
+ 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
(so long as she is using an OP).
0.1. Notation, conventions and prerequisites
In the specifications below, we use the same notation as in
- "tor-spec.txt". The service specified here also requires the existence of
- an onion routing network as specified in "tor-spec.txt".
+ "tor-spec.txt". The service specified here also requires the
+ existence of an onion routing network as specified in that file.
H(x) is a SHA1 digest of x.
PKSign(SK,x) is a PKCS.1-padded RSA signature of x with SK.
@@ -49,7 +50,8 @@
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
Bob's OP.)
@@ -59,20 +61,22 @@
3. Bob's OP->Introduction point via Tor: [introduction setup]
"This pk is me."
- 4. Bob's OP->directory service via Tor: publishes Bob's service descriptor
- [advertisement]
+ 4. Bob's OP->directory service via Tor: publishes Bob's service
+ descriptor [advertisement]
- 5. Out of band, Alice receives a y.onion:port address. She opens a
- SOCKS connection to her OP, and requests y.onion:port.
+ 5. Out of band, Alice receives a [x.y.]z.onion:port address.
+ 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
rendezvous point, and establishes a rendezvous circuit. [rendezvous
setup.]
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
introduction circuit. [Introduction 2]
@@ -112,21 +116,47 @@
a public/private keypair (stored locally). Periodically, the OP
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 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]
+ 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]
For each introduction point: (as in INTRODUCE2 cells)
- IP Rendezvous point's address [4 octets]
- PORT Rendezvous point's OR port [2 octets]
- ID Rendezvous point identity ID [20 octets]
- KLEN Length of onion key [2 octets]
- KEY Rendezvous point onion key [KLEN octets]
+ ATYPE An address type (typically 4) [1 octet]
+ ADDR Introduction point's IP address [4 or 16 octets]
+ PORT Introduction 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 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]
The "V0" descriptor contains:
@@ -141,6 +171,12 @@
KL is the length of PK, in octets. (Currently, KL must be 128.)
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
digests, encoded in hex, and prefixed with a '$'. Clients must
accept both forms. Services must only generate the second form.
@@ -165,6 +201,8 @@
HS Hash of session info [20 octets]
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
shared secret KH between Bob's OP and the introduction point, as
follows:
@@ -181,29 +219,34 @@
currently associated with PK. On success, the OR sends Bob a
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.
(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
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,
and discards the descriptor if the signature does not match the enclosed
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
future, or the directory server already has a newer descriptor with the
same public key, the server discards the descriptor. Otherwise, the
- server discards any older descriptors with the same public key, and
- associates the new descriptor with the public key. The directory server
- remembers this descriptor for at least 24 hours after its timestamp. At
- least every 24 hours, Bob's OP uploads a fresh descriptor.
+ server discards any older descriptors with the same public key and
+ version format, and associates the new descriptor with the public key.
+ The directory server remembers this descriptor for at least 24 hours
+ 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
- hostname of the form "y.onion", where y is a base-32 encoding of a
- 10-octet hash of Bob's service's public key, computed as follows:
+ hostname of the form "z.onion" or "y.z.onion" or "x.y.z.onion", where
+ 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).
2. Let H' = the first 80 bits of H, considering each octet from
@@ -215,22 +258,29 @@
need to worry about man-in-the-middle attacks, and because it will make
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]
-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
- request for the document '/tor/rendezvous/<y>' or '/tor/rendezvous1/<y>',
- where '<y> is replaced with the encoding of Bob's public key as described
+ request for the document '/tor/rendezvous/<z>' or '/tor/rendezvous1/<z>',
+ 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
- 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
'rendezvous1', the directory server provides a V1 descriptor or a V0
descriptor if no V1 descriptor is available. If Alice requests
'rendezvous', the directory server returns a V0 descriptor.)
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
as the directory server uses, described above in section 1.4.
@@ -254,6 +304,8 @@
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
Alice's OP.
@@ -271,6 +323,7 @@
Cleartext
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:
RP Rendezvous point's nickname [20 octets]
@@ -287,9 +340,22 @@
PORT Rendezvous point's OR port [2 octets]
ID Rendezvous point identity ID [20 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]
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,
and must contain EITHER a nickname, or an identity key digest, encoded in
@@ -326,7 +392,7 @@
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:
RC Rendezvous cookie [20 octets]
g^y Diffie-Hellman [128 octets]
@@ -377,3 +443,7 @@
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.
+2.0. Authentication and authorization.
+
+Foo.
+
More information about the tor-commits
mailing list