This is the security documentation for tinc, a Virtual Private Network daemon.
- Copyright 2000 Guus Sliepen <guus@sliepen.warande.net>,
- 2000 Ivo Timmmermans <itimmermans@bigfoot.com>
+ Copyright 2000,2001 Guus Sliepen <guus@sliepen.warande.net>,
+ 2000,2001 Ivo Timmmermans <itimmermans@bigfoot.com>
Permission is granted to make and distribute verbatim copies of
this documentation provided the copyright notice and this
provided that the entire resulting derived work is distributed
under the terms of a permission notice identical to this one.
- $Id: SECURITY,v 1.1.2.2 2000/09/17 20:11:59 guus Exp $
+ $Id: SECURITY,v 1.1.2.4 2001/01/07 17:08:03 guus Exp $
1. Authentication
send_id(u)
send_challenge(R)
send_chal_reply(H)
- ---------------------------------------
- Any negotations about the meta protocol
- encryption go here(u).
- ---------------------------------------
+ send_metakey(R)
+ send_metakey(R)
send_ack(u)
send_ack(u)
---------------------------------------
(H) SHA1,
(E) Encrypted with symmetric cipher.
+See section 4 for a detailed example version of the authentication.
+
Authentication in tinc will be done in a way that is very similar to the way
the SSH (Secure SHell) authentication protocol works. It is based on public
key cryptography.
-Every tinc host has it's own public/private key pair. Suppose there are two
+Every tinc host has its own public/private key pair. Suppose there are two
tinc hosts, A and B. If A and B trust each other, they store a copy of
eachothers public key (in the same way passphrases were stored in versions
of tinc <= 1.0pre2). They know these public keys beforehand, and the origin
that this key exchange is also done securely, and no man-in-the-middle attack
is possible, RSA would be the best choice for exchanging keys.
-Instead of doing RSA encryption again, tinc will use a part of the random
-string that was exchanged during the authentication phase as the key for the
-symmetric cipher. Some symmetric ciphers require a random initialisation vector
-for improved security. This vector can be taken from the random string as well.
-
-Is this secure? I (Guus Sliepen) think at this moment that it is:
-
-- Since the random string cannot be decrypted by anyone eavesdropping or
- playing man-in-the-middle, the symmetric key cannot be known by sniffing.
-- The unencrypted returned hash value is supposed to be cryptographically
- secure. Furthermore, it can only at most give a way 160 bits of information
- from the complete random string which is longer than the key for the
- symmetric cipher, so very few bits will actualy contain information about
- the symmetric cipher key alone, if any.
-- If the RSA encryption is cracked, the rest of the communications can be
- decrypted anyway.
-- If the symmetric cipher encryption is cracked without using the information
- from the encrypted random strings or the hash values, this still won't give
- the full plaintext for the random string, so it won't facilitate a known-
- plaintext attack on the RSA encryption.
-- RSA and symmetric ciphers are fundamentally different. It is very unlikely
- that the overlap of both will create any interference that will facilitate
- an easier-than-brute-force attack.
-
-Other options for key exchange could be:
-
-* A second exchange of RSA encrypted random strings.
- This is equal to the former scheme just without knowing the hash value of
- the unecrypted random string.
-
-* Diffie-Hellman with RSA signing.
- This should be very secure, but there are a lot of pitholes with using both
- encryption with public keys and private keys together with the same keypair.
-
-* Diffie-Hellman with passphrases.
- This is what tinc <= 1.0pre2 used to do. Passphrases are secret, exchanging
- them must be done with great care, nobody may eavesdrop. Exchanging public
- keys on the other hand is much safer, everybody may eavesdrop, just as long
- as you are sure that the public key itself belongs to the right owner.
-
3. Symmetric cipher
--------------------
cipher that is available in OpenSSL could possibly be used. The default however
will be Blowfish. Blowfish is widely in use and still has not been cracked
today (as far as we know). It also is one of the faster ciphers available.
+
+4. Detailed "example" of communication
+---------------------------------------
+
+Tinc uses a peer-to-peer protocol, but during the authentication phase we will
+make a distinction between a server (a tinc daemon listening for incoming
+connections) and a client (a tinc daemon that is trying to connect to the tinc
+daemon playing server).
+
+The message strings here are kept short for clarity. The real length of the
+exchanged messages is indicated. The capital words ID, CHALLENGE, CHAL_REPLY,
+META_KEY and ACK are in reality replaced by the numbers 0, 1, 2, 3 and 4
+respectively.
+
+daemon message
+--------------------------------------------------------------------------
+server <listening for connection>
+client <tries to connect>
+server <accepts connection>
+client ID client 8 0
+ | | +-> options
+ | +---> version
+ +-------> name of tinc daemon
+server CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d
+ \______________________________/
+ +-> KEYLENGTH bits totally random string, encrypted
+ with client's public RSA key
+client CHAL_REPLY 191e23
+ +-> 160 bits SHA1 value of the complete decrypted
+ CHALLENGE sent by the server
+server ID server 8 0
+ | | +-> options
+ | +---> version
+ +-------> name of tinc daemon
+client CHALLENGE da02add1817c1920989ba6ae2a49cecb
+ \______________________________/
+ +-> KEYLENGTH bits totally random string, encrypted
+ with server's public RSA key
+server CHAL_REPLY 2bdeed
+ +-> 160 bits SHA1 value of the complete decrypted
+ CHALLENGE sent by the client
+client META_KEY 5f0823a93e35b69e7086ec7866ce582b
+ \______________________________/
+ +-> KEYLENGTH bits totally random string, encrypted
+ with server's public RSA key
+server META_KEY 6ab9c1640388f8f045d1a07f8a672630
+ \______________________________/
+ +-> KEYLENGTH bits totally random string, encrypted
+ with client's public RSA key
+client ACK
+server ACK
+--------------------------------------------------------------------------
+
+When the server receives the ACK from the client, it should prepare itself
+for the fact that any subsequent data will be encrypted with the key the server
+sent itself in the META_KEY. Ofcourse, this key is taken from the decrypted
+version of that META_KEY, so that we will know for sure only the real client
+can send us messages. The same goes for the client when it receives an ACK.
+
+5. Encryption of VPN packets
+-----------------------------
+
+The VPN packets are also encrypted, but with a different key than the one used
+for the meta connection. The reason is that VPN packets can also come from
+other clients which do not have a meta connection with server. Each tinc daemon
+propagates (on request) a separate key for packets that it receives. This key
+is a random string, generated on the fly. Since it is exchanged using the meta
+connection, this key itself will be encrypted.
projects / tinc / blobdiff