From bb0870498037565209e24fbb2ffa07b815350a0b Mon Sep 17 00:00:00 2001 From: Guus Sliepen Date: Tue, 13 Feb 2001 09:54:29 +0000 Subject: [PATCH] Added description of the proposed new authentication scheme. --- doc/SECURITY2 | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 doc/SECURITY2 diff --git a/doc/SECURITY2 b/doc/SECURITY2 new file mode 100644 index 0000000..3922f3f --- /dev/null +++ b/doc/SECURITY2 @@ -0,0 +1,115 @@ +This is the security documentation for tinc, a Virtual Private Network daemon. + + Copyright 2001 Guus Sliepen , + 2001 Wessel Dankers + + Permission is granted to make and distribute verbatim copies of + this documentation provided the copyright notice and this + permission notice are preserved on all copies. + + Permission is granted to copy and distribute modified versions of + this documentation under the conditions for verbatim copying, + provided that the entire resulting derived work is distributed + under the terms of a permission notice identical to this one. + + $Id: SECURITY2,v 1.1.2.1 2001/02/13 09:54:29 guus Exp $ + +Proposed new authentication scheme +---------------------------------- + +A new scheme for authentication in tinc has been devised, which offers some +improvements over the protocol used in 1.0pre2 and 1.0pre3. Explanation is +below. + +daemon message +-------------------------------------------------------------------------- +client + +server + +client ID client 9 0 + | | +-> options + | +---> version + +-------> name of tinc daemon + +server ID server 9 0 + | | +-> options + | +---> version + +-------> name of tinc daemon + +client META_KEY 5f0823a93e35b69e...7086ec7866ce582b + \_________________________________/ + +-> RSAKEYLEN bits totally random string S1, + encrypted with server's public RSA key + +server META_KEY 6ab9c1640388f8f0...45d1a07f8a672630 + \_________________________________/ + +-> RSAKEYLEN bits totally random string S2, + encrypted with client's public RSA key + +From now on: + - the client will symmetrically encrypt outgoing traffic using S1 + - the server will symmetrically encrypt outgoing traffic using S2 + +client CHALLENGE da02add1817c1920989ba6ae2a49cecbda0 + \_________________________________/ + +-> CHALLEN bits totally random string H1 + +server CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d57f + \_________________________________/ + +-> CHALLEN bits totally random string H2 + +client CHAL_REPLY 816a86 + +-> 160 bits SHA1 of H2 + +server CHAL_REPLY 928ffe + +-> 160 bits SHA1 of H1 +-------------------------------------------------------------------------- + +This new scheme has several improvements, both in efficiency and security. + +First of all, the server sends exactly the same kind of messages over the wire +as the client. The previous versions of tinc first authenticated the client, +and then the server. This scheme even allows both sides to send their messages +simultaneously, there is no need to wait for the other to send something first. +This means that any calculations that need to be done upon sending or receiving +a message can also be done in parallel. This is especially important when doing +RSA encryption/decryption. Given that these calculations are the main part of +the CPU time spent for the authentication, speed is improved by a factor 2. + +Second, only one RSA encrypted message is sent instead of two. This reduces the +amount of information attackers can see (and thus use for a crypto attack). It +also improves speed by a factor two, making the total speedup a factor 4. + +Third, and most important: + +The symmetric cipher keys are exchanged first, the challenge is done +afterwards. In the previous authentication scheme, because a man-in-the-middle +could pass the challenge/chal_reply phase (by just copying the messages between +the two real tinc daemons), but no information was exchanged that was really +needed to read the rest of the messages, the challenge/chal_reply phase was of +no real use. The man-in-the-middle was only stopped by the fact that only after +the ACK messages were encrypted with the symmetric cipher. Potentially, it +could even send it's own symmetric key to the server (if it knew the server's +public key) and read some of the metadata the server would send it (it was +impossible for the mitm to read actual network packets though). The new scheme +however prevents this. + +This new scheme makes sure that first of all, symmetric keys are exchanged. The +rest of the messages are then encrypted with the symmetric cipher. Then, each +side can only read received messages if they have their private key. The +challenge is there to let the other side know that the private key is really +known, because a challenge reply can only be sent back if the challenge is +decrypted correctly, and that can only be done with knowledge of the private +key. + +Fourth: the first thing that is send via the symmetric cipher encrypted +connection is a totally random string, so that there is no known plaintext (for +an attacker) in the beginning of the encrypted stream. + + +An explicit ACK is no longer needed, the CHAL_REPLY serves as an ACK. + +Some things to be discussed: + + - What should CHALLEN be? Same as RSAKEYLEN? 256 bits? More/less? -- 2.25.1