[or-cvs] update spec: OR/OR and OP/OR handshakes have merged
Roger Dingledine
arma at seul.org
Mon Jun 23 09:44:39 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home/arma/work/onion/cvs/doc
Modified Files:
tor-spec.txt
Log Message:
update spec: OR/OR and OP/OR handshakes have merged
Index: tor-spec.txt
===================================================================
RCS file: /home/or/cvsroot/doc/tor-spec.txt,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -d -r1.21 -r1.22
--- tor-spec.txt 19 Jun 2003 23:23:35 -0000 1.21
+++ tor-spec.txt 23 Jun 2003 09:44:35 -0000 1.22
@@ -48,33 +48,44 @@
2. Connections
-2.1. Establishing OR connections
+2.1. Establishing connections to onion routers (ORs)
- When one onion router opens a connection to another, the initiating
- OR (called the 'client') and the listening OR (called the 'server')
- perform the following handshake.
-[or when an op wants to connect to or]
+ There are two ways to connect to an OR. The first is as an onion
+ proxy (OP), which allows any node to connect without providing any
+ authentication or name. The second is as another OR, which allows
+ strong authentication. In both cases the initiating party (called
+ the 'client') sets up shared keys with the listening OR (called the
+ 'server').
- Before the handshake begins, the client and server know one
- another's (1024-bit) public keys, IPV4 addresses, and ports.
+ Before the handshake begins, assume all parties know the {(1024-bit)
+ public key, IPV4 address, and port} triplet of each OR.
1. Client connects to server:
- The client generates a pair of 8-byte symmetric keys (one
+ The client generates a pair of 16-byte symmetric keys (one
[K_f] for the 'forward' stream from client to server, and one
[K_b] for the 'backward' stream from server to client.
The client then generates a 'Client authentication' message [M]
containing:
- The number 2 to signify OR handshake [2 bytes]
- The client's published IPV4 address [4 bytes]
- The client's published port [2 bytes]
- The server's published IPV4 address [4 bytes]
- The server's published port [2 bytes]
- The forward key (K_f) [16 bytes]
- The backward key (K_f) [16 bytes]
- The maximum bandwidth (bytes/s) [4 bytes]
- [Total: 50 bytes]
+
+ (If client is an OP)
+ The number 1 to signify OP handshake [2 bytes]
+ Maximum bandwidth (bytes/s) [4 bytes]
+ Forward key [K_f] [16 bytes]
+ Backward key [K_b] [16 bytes]
+ [Total: 38 bytes]
+
+ (If client is an OR)
+ The number 2 to signify OR handshake [2 bytes]
+ The client's published IPV4 address [4 bytes]
+ The client's published port [2 bytes]
+ The server's published IPV4 address [4 bytes]
+ The server's published port [2 bytes]
+ The forward key [K_f] [16 bytes]
+ The backward key [K_b] [16 bytes]
+ The maximum bandwidth (bytes/s) [4 bytes]
+ [Total: 50 bytes]
The client then RSA-encrypts [M] with the server's public key
and PKCS1 padding to give an encrypted message.
@@ -83,22 +94,32 @@
the 128-byte RSA-encrypted data to the server, and waits for a
reply.
- 2. Server authenticates to client:
+ 2. The server receives the first handshake
- Upon receiving a TCP connection, the server waits to receive
- 128 bytes from the client. It decrypts the message with its
- private key, and checks the PKCS1 padding. If the padding is
- incorrect, or if the message's length is other than 50 bytes,
- the server closes the TCP connection and stops handshaking.
+ The OR waits for 128 bytes of data, and decrypts the resulting
+ data with its private key, checking the PKCS1 padding. If
+ the padding is invalid, it closes the connection. If the tag
+ indicates the client is an OP, and the message is 38 bytes long,
+ it performs step 2a. If the tag indicates the client is an OR,
+ and the message is 50 bytes long, it performs step 2b. Else,
+ it closes the connection.
- The server then checks the list of known ORs for one with the
- address and port given in the client's authentication. If no
- such OR is known, or if the server is already connected to
- that OR, the server closes the current TCP connection and
- stops handshaking.
+ 2a. If client is an OP:
- For later use, the server sets its keys for this connection,
- setting K_f to the client's K_b, and K_b to the client's K_f.
+ The connection is established, and the OR is ready to receive
+ cells. The server sets its keys for this connection, setting K_f
+ to the client's K_b, and K_b to the client's K_f. The handshake
+ is complete.
+
+ 2b. If the client is an OR:
+
+ The server checks the list of known ORs for one with the address
+ and port given in the client's authentication. If no such OR
+ is known, or if the server is already connected to that OR, the
+ server closes the current TCP connection and stops handshaking.
+
+ The server sets its keys for this connection, setting K_f to
+ the client's K_b, and K_b to the client's K_f.
The server then creates a server authentication message [M2] as
follows:
@@ -153,50 +174,9 @@
cells to one another. Otherwise, the server closes the TCP
connection.
-2.2. Establishing OP-to-OR connections
-
-[wrap this with the above]
- When an Onion Proxy (OP) needs to establish a connection to an OR,
- the handshake is simpler because the OR does not need to verify the
- OP's identity. The OP and OR establish the following steps:
-
- 1. OP connects to OR:
-
- First, the OP generates a pair of 8-byte symmetric keys (one
- [K_f] for the 'forward' stream from OP to OR, and one
- [K_b] for the 'backward' stream from OR to OP).
-
- The OP generates a message [M] in the following format:
- The number 1 to signify OP handshake [2 bytes]
- Maximum bandwidth (bytes/s) [4 bytes]
- Forward key [K_f] [16 bytes]
- Backward key [K_b] [16 bytes]
- [Total: 38 bytes]
-
- The OP encrypts M with the OR's public key and PKCS1 padding,
- opens a TCP connection to the OR's TCP port, and sends the
- resulting 128-byte encrypted message to the OR.
-
- 2. OR receives keys:
-
- When the OR receives a connection from an OP [This is on a
- different port, right? How does it know the difference? -NM],
- [Correct. The 'or_port' config variable specifies the OR port,
- and the op_port variable specified the OP port. -RD]
- it waits for 128 bytes of data, and decrypts the resulting
- data with its private key, checking the PKCS1 padding. If the
- padding is invalid, or the message is not 38 bytes long, the
- OR closes the connection.
-
- Otherwise, the connection is established, and the OR is ready
- to receive cells.
-
- The server sets its keys for this connection, setting K_f to
- the client's K_b, and K_b to the client's K_f.
-
-2.3. Sending cells and link encryption
+2.2. Sending cells and link encryption
- Once the handshake is complete, the ORs or OR and OP send cells
+ Once the handshake is complete, the two sides send cells
(specified below) to one another. Cells are sent serially,
encrypted with the 3DES-OFB keystream specified by the handshake
protocol. Over a connection, communicants encrypt outgoing cells
@@ -309,7 +289,7 @@
going from the OP to the OR, and second of which (called Kb) is
used to encrypt the stream of data going from the OR to the OP.
-4.3. Creating circuits
+4.3. Creating circuits
When creating a circuit through the network, the circuit creator
performs the following steps:
More information about the tor-commits
mailing list