ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/gvpe/doc/gvpe.protocol.7
(Generate patch)

Comparing gvpe/doc/gvpe.protocol.7 (file contents):
Revision 1.12 by root, Sat Jul 13 04:10:29 2013 UTC vs.
Revision 1.13 by root, Fri Sep 20 11:57:03 2013 UTC

… …
122.\} 122.\}
123.rm #[ #] #H #V #F C 123.rm #[ #] #H #V #F C
124.\" ======================================================================== 124.\" ========================================================================
125.\" 125.\"
126.IX Title "GVPE.PROTOCOL 7" 126.IX Title "GVPE.PROTOCOL 7"
127.TH GVPE.PROTOCOL 7 "2013-07-12" "2.24" "GNU Virtual Private Ethernet" 127.TH GVPE.PROTOCOL 7 "2013-07-19" "2.25" "GNU Virtual Private Ethernet"
128.\" For nroff, turn off justification. Always turn off hyphenation; it makes 128.\" For nroff, turn off justification. Always turn off hyphenation; it makes
129.\" way too many mistakes in technical documents. 129.\" way too many mistakes in technical documents.
130.if n .ad l 130.if n .ad l
131.nh 131.nh
132.SH "The GNU-VPE Protocols" 132.SH "The GNU-VPE Protocols"
… …
269.PP 269.PP
270\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of 270\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of
271the data for encryption purposes. 271the data for encryption purposes.
272.PP 272.PP
273\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection 273\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection
274initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses 274initialization and starts at some random 31 bit value. \s-1GVPE\s0 currently uses
275a sliding window of 512 packets/sequence numbers to detect reordering, 275a sliding window of 512 packets/sequence numbers to detect reordering,
276duplication and replay attacks. 276duplication and replay attacks.
277.PP 277.PP
278The encryption is done on \s-1RAND+SEQNO+DATA\s0 in \s-1CBC\s0 mode with zero \s-1IV\s0 (or, 278The encryption is done on \s-1RAND+SEQNO+DATA\s0 in \s-1CBC\s0 mode with zero \s-1IV\s0 (or,
279equivalently, the \s-1IV\s0 is \s-1RAND+SEQNO\s0, encrypted with the block cipher, 279equivalently, the \s-1IV\s0 is \s-1RAND+SEQNO\s0, encrypted with the block cipher,
280unless \s-1RAND\s0 size is decreased or increased over the default value). 280unless \s-1RAND\s0 size is decreased or increased over the default value).
281.PP
282The random prefix itself is generated by using \s-1AES\s0 in \s-1CTR\s0 mode with a
283random key and starting value, which should make them unpredictable even
284before encrypting them again. The sequence number additionally ensures
285that the \s-1IV\s0 is unique.
281.SS "The authentication protocol" 286.SS "The authentication/key exchange protocol"
282.IX Subsection "The authentication protocol" 287.IX Subsection "The authentication/key exchange protocol"
283Before nodes can exchange packets, they need to establish authenticity of 288Before nodes can exchange packets, they need to establish authenticity of
284the other side and a key. Every node has a private \s-1RSA\s0 key and the public 289the other side and a key. Every node has a private \s-1RSA\s0 key and the public
285\&\s-1RSA\s0 keys of all other nodes. 290\&\s-1RSA\s0 keys of all other nodes.
286.PP 291.PP
287A host establishes a simplex connection by sending the other node an \s-1RSA\s0 292When a node wants to establish a connection to another node, it sends an
288encrypted challenge containing a random challenge (consisting of the 293RSA-OEAP-encrypted challenge and an \s-1ECDH\s0 key. The other node replies with
289encryption and authentication keys to use when sending packets, more 294it's own \s-1ECDH\s0 key and a \s-1HKDF\s0 of the challange and both \s-1ECDH\s0 keys to proof
290random data and \s-1PKCS1_OAEP\s0 padding) and a random 16 byte \*(L"challenge-id\*(R" 295it's identity.
291(used to detect duplicate auth packets). The destination node will respond
292by replying with an (unencrypted) hash of the decrypted challenge, which
293will authenticate that node. The destination node will also set the
294outgoing encryption parameters as given in the packet.
295.PP 296.PP
296When the source node receives a correct auth reply (by verifying the 297The remote node enganges in exactly the same protocol. When both nodes
297hash and the id, which will expire after 120 seconds), it will start to 298have exchanged their challenge and verified the response, they calculate a
298accept data packets from the destination node. 299cipher key and a \s-1HMAC\s0 key and start exchanging data packets.
299.PP 300.PP
300This means that a node can only initiate a simplex connection, telling the 301In detail, the challenge consist of:
301other side the key it has to use when it sends packets. The challenge
302reply is only used to set the current \s-1IP\s0 address of the other side and
303protocol parameters.
304.PP 302.PP
305This protocol is completely symmetric, so to be able to send packets the 303.Vb 1
306destination node must send a challenge in the exact same way as already 304\& RSA\-OAEP (SEQNO MAC CIPHER SALT EXTRA\-AUTH) ECDH1
307described (so, in essence, two simplex connections are created per node 305.Ve
308pair). 306.PP
307That is, it encrypts (with the public key of the remote node) an initial
308sequence number for data packets, key material for the \s-1HMAC\s0 key, key
309material for the cipher key, a salt used by the \s-1HKDF\s0 (as shown later) and
310some extra random bytes that are unused except for authentication. It also
311sends the public key of a curve25519 exchange.
312.PP
313The remote node decrypts the \s-1RSA\s0 data, generates it's own \s-1ECDH\s0 key (\s-1ECDH2\s0), and
314replies with:
315.PP
316.Vb 1
317\& HKDF\-Expand (HKDF\-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2
318.Ve
319.PP
320That is, it extracts from the decrypted \s-1RSA\s0 challenge, using it's \s-1ECDH\s0
321key as salt, and then expands using the requesting node's \s-1ECDH1\s0 key. The
322resulting has is returned as a proof that the node could decrypt the \s-1RSA\s0
323challenge data, together with the \s-1ECDH\s0 key.
324.PP
325After both nodes have done this to each other, they calculate the shared
326\&\s-1ECDH\s0 secrets, cipher and \s-1HMAC\s0 keys for the session (each
327node generates two cipher and \s-1HMAC\s0 keys, one for sending and one for
328receiving).
329.PP
330The \s-1HMAC\s0 key for sending is generated as follow:
331.PP
332.Vb 1
333\& HMAC_KEY = HKDF\-Expand (HKDF\-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE)
334.Ve
335.PP
336It extracts from \s-1MAC\s0 and \s-1ECDH_SECRET\s0 using the \fIremote\fR \s-1SALT\s0, then
337expands using a static info string.
338.PP
339The cipher key is generated in the same way, except using the \s-1CIPHER\s0 part
340of the original challenge.
341.PP
342The result of this process is to authenticate each node to the other
343node, while exchanging keys using both \s-1RSA\s0 and \s-1ECDH\s0, the latter providing
344perfect forward secrecy.
345.PP
346The protocol has been overdesigned where this was possible without
347increasing implementation complexity, in an attempt to protect against
348implementation or protocol failures. For example, if the \s-1ECDH\s0 challenge
349was found to be flawed, perfect forward secrecy would be lost, but
350the data would still be protected. Likewise, standard algorithms and
351implementations are used where possible.
309.SS "Retrying" 352.SS "Retrying"
310.IX Subsection "Retrying" 353.IX Subsection "Retrying"
311When there is no response to an auth request, the node will send auth 354When there is no response to an auth request, the node will send auth
312requests in bursts with an exponential back-off. After some time it will 355requests in bursts with an exponential back-off. After some time it will
313resort to \s-1PING\s0 packets, which are very small (8 bytes + protocol header) 356resort to \s-1PING\s0 packets, which are very small (8 bytes + protocol header)

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines