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