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

Comparing gvpe/doc/gvpe.protocol.7.pod (file contents):
Revision 1.8 by root, Sun Mar 6 19:40:27 2011 UTC vs.
Revision 1.11 by root, Fri Jul 19 21:01:16 2013 UTC

… …
146SEQNO is a 32-bit sequence number. It is negotiated at every connection 146SEQNO is a 32-bit sequence number. It is negotiated at every connection
147initialization and starts at some random 31 bit value. VPE currently uses 147initialization and starts at some random 31 bit value. VPE currently uses
148a sliding window of 512 packets/sequence numbers to detect reordering, 148a sliding window of 512 packets/sequence numbers to detect reordering,
149duplication and replay attacks. 149duplication and replay attacks.
150 150
151The encryption is done on RAND+SEQNO+DATA in CBC mode with zero IV (or,
152equivalently, the IV is RAND+SEQNO, encrypted with the block cipher,
153unless RAND size is decreased or increased over the default value).
154
151=head2 The authentication protocol 155=head2 The authentication/key exchange protocol
152 156
153Before nodes can exchange packets, they need to establish authenticity of 157Before nodes can exchange packets, they need to establish authenticity of
154the other side and a key. Every node has a private RSA key and the public 158the other side and a key. Every node has a private RSA key and the public
155RSA keys of all other nodes. 159RSA keys of all other nodes.
156 160
157A host establishes a simplex connection by sending the other node an 161When a node wants to establish a connection to another node, it sends an
158RSA encrypted challenge containing a random challenge (consisting of 162RSA-OEAP-encrypted challenge and an ECDH key. The other node replies with
159the encryption key to use when sending packets, more random data and 163it's own ECDH key and a HKDF of the challange and both ECDH keys to proof
160PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect 164it's identity.
161duplicate auth packets). The destination node will respond by replying
162with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which
163will authenticate that node. The destination node will also set the
164outgoing encryption parameters as given in the packet.
165 165
166When the source node receives a correct auth reply (by verifying the 166The remote node enganges in exactly the same protocol. When both nodes
167hash and the id, which will expire after 120 seconds), it will start to 167have exchanged their challenge and verified the response, they calculate a
168accept data packets from the destination node. 168cipher key and a HMAC key and start exchanging data packets.
169 169
170This means that a node can only initiate a simplex connection, telling the 170In detail, the challenge consist of:
171other side the key it has to use when it sends packets. The challenge
172reply is only used to set the current IP address of the other side and
173protocol parameters.
174 171
175This protocol is completely symmetric, so to be able to send packets the 172 RSA-OAEP (SEQNO MAC CIPHER SALT EXTRA-AUTH) ECDH1
176destination node must send a challenge in the exact same way as already 173
177described (so, in essence, two simplex connections are created per node 174That is, it encrypts (with the public key of the remote node) an initial
178pair). 175sequence number for data packets, key material for the HMAC key, key
176material for the cipher key, a salt used by the HKDF (as shown later) and
177some extra random bytes that are unused except for authentication. It also
178sends the public key of a curve25519 exchange.
179
180The remote node decrypts the RSA data, generates it's own ECDH key (ECDH2), and
181replies with:
182
183 HKDF-Expand (HKDF-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2
184
185That is, it extracts from the decrypted RSA challenge, using it's ECDH
186key as salt, and then expands using the requesting node's ECDH1 key. The
187resulting has is returned as a proof that the node could decrypt the RSA
188challenge data, together with the ECDH key.
189
190After both nodes have done this to each other, they calculate the shared
191ECDH secrets, cipher and HMAC keys for the session (each
192node generates two cipher and HMAC keys, one for sending and one for
193receiving).
194
195The HMAC key for sending is generated as follow:
196
197 HMAC_KEY = HKDF-Expand (HKDF-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE)
198
199It extracts from MAC and ECDH_SECRET using the I<remote> SALT, then
200expands using a static info string.
201
202The cipher key is generated in the same way, except using the CIPHER part
203of the original challenge.
204
205The result of this process is to authenticate each node to the other
206node, while exchanging keys using both RSA and ECDH, the latter providing
207perfect forward secrecy.
179 208
180=head2 Retrying 209=head2 Retrying
181 210
182When there is no response to an auth request, the node will send auth 211When there is no response to an auth request, the node will send auth
183requests in bursts with an exponential back-off. After some time it will 212requests in bursts with an exponential back-off. After some time it will
… …
203will try to connect every few seconds. 232will try to connect every few seconds.
204 233
205=head2 Routing and Protocol translation 234=head2 Routing and Protocol translation
206 235
207The GVPE routing algorithm is easy: there isn't much routing to speak 236The GVPE routing algorithm is easy: there isn't much routing to speak
208of: When routing packets to another node, GVPE trues the following 237of: When routing packets to another node, GVPE tries the following
209options, in order: 238options, in order:
210 239
211=over 4 240=over 4
212 241
213=item If the two nodes should be able to reach each other directly (common 242=item If the two nodes should be able to reach each other directly (common

Diff Legend

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