git.meshlink.io Git - meshlink/blob - doc/SECURITY2

   1 This is the security documentation for tinc, a Virtual Private Network daemon.
   2
   3    Copyright 2001-2002 Guus Sliepen <guus@sliepen.warande.net>,
   4              2001-2002 Wessel Dankers <wsl@nl.linux.org>
   5
   6    Permission is granted to make and distribute verbatim copies of
   7    this documentation provided the copyright notice and this
   8    permission notice are preserved on all copies.
   9
  10    Permission is granted to copy and distribute modified versions of
  11    this documentation under the conditions for verbatim copying,
  12    provided that the entire resulting derived work is distributed
  13    under the terms of a permission notice identical to this one.
  14
  15    $Id: SECURITY2,v 1.1.2.2 2002/02/10 21:57:51 guus Exp $
  16
  17 Proposed new authentication scheme
  18 ----------------------------------
  19
  20 A new scheme for authentication in tinc has been devised, which offers some
  21 improvements over the protocol used in 1.0pre2 and 1.0pre3. Explanation is
  22 below.
  23
  24 daemon  message
  25 --------------------------------------------------------------------------
  26 client  <attempts connection>
  27
  28 server  <accepts connection>
  29
  30 client  ID client 12
  31               |   +---> version
  32               +-------> name of tinc daemon
  33
  34 server  ID server 12
  35               |   +---> version
  36               +-------> name of tinc daemon
  37
  38 client  META_KEY 5f0823a93e35b69e...7086ec7866ce582b
  39                  \_________________________________/
  40                                  +-> RSAKEYLEN bits totally random string S1,
  41                                      encrypted with server's public RSA key
  42
  43 server  META_KEY 6ab9c1640388f8f0...45d1a07f8a672630
  44                  \_________________________________/
  45                                  +-> RSAKEYLEN bits totally random string S2,
  46                                      encrypted with client's public RSA key
  47
  48 From now on:
  49  - the client will symmetrically encrypt outgoing traffic using S1
  50  - the server will symmetrically encrypt outgoing traffic using S2
  51
  52 client  CHALLENGE da02add1817c1920989ba6ae2a49cecbda0
  53                   \_________________________________/
  54                                  +-> CHALLEN bits totally random string H1
  55
  56 server  CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d57f
  57                   \_________________________________/
  58                                  +-> CHALLEN bits totally random string H2
  59
  60 client  CHAL_REPLY 816a86
  61                       +-> 160 bits SHA1 of H2
  62
  63 server  CHAL_REPLY 928ffe
  64                       +-> 160 bits SHA1 of H1
  65
  66 After the correct challenge replies are recieved, both ends have proved
  67 their identity. Further information is exchanged.
  68
  69 client  ACK 655 12.23.34.45 123 0
  70              |       |       |  +-> options
  71              |       |       +----> estimated weight
  72              |       +------------> IP address of server as seen by client
  73              +--------------------> UDP port of client
  74
  75 server  ACK 655 21.32.43.54 321 0
  76              |       |       |  +-> options
  77              |       |       +----> estimated weight
  78              |       +------------> IP address of client as seen by server
  79              +--------------------> UDP port of server
  80 --------------------------------------------------------------------------
  81
  82 This new scheme has several improvements, both in efficiency and security.
  83
  84 First of all, the server sends exactly the same kind of messages over the wire
  85 as the client. The previous versions of tinc first authenticated the client,
  86 and then the server. This scheme even allows both sides to send their messages
  87 simultaneously, there is no need to wait for the other to send something first.
  88 This means that any calculations that need to be done upon sending or receiving
  89 a message can also be done in parallel. This is especially important when doing
  90 RSA encryption/decryption. Given that these calculations are the main part of
  91 the CPU time spent for the authentication, speed is improved by a factor 2.
  92
  93 Second, only one RSA encrypted message is sent instead of two. This reduces the
  94 amount of information attackers can see (and thus use for a crypto attack). It
  95 also improves speed by a factor two, making the total speedup a factor 4.
  96
  97 Third, and most important:
  98
  99 The symmetric cipher keys are exchanged first, the challenge is done
 100 afterwards. In the previous authentication scheme, because a man-in-the-middle
 101 could pass the challenge/chal_reply phase (by just copying the messages between
 102 the two real tinc daemons), but no information was exchanged that was really
 103 needed to read the rest of the messages, the challenge/chal_reply phase was of
 104 no real use. The man-in-the-middle was only stopped by the fact that only after
 105 the ACK messages were encrypted with the symmetric cipher. Potentially, it
 106 could even send it's own symmetric key to the server (if it knew the server's
 107 public key) and read some of the metadata the server would send it (it was
 108 impossible for the mitm to read actual network packets though). The new scheme
 109 however prevents this.
 110
 111 This new scheme makes sure that first of all, symmetric keys are exchanged. The
 112 rest of the messages are then encrypted with the symmetric cipher. Then, each
 113 side can only read received messages if they have their private key. The
 114 challenge is there to let the other side know that the private key is really
 115 known, because a challenge reply can only be sent back if the challenge is
 116 decrypted correctly, and that can only be done with knowledge of the private
 117 key.
 118
 119 Fourth: the first thing that is send via the symmetric cipher encrypted
 120 connection is a totally random string, so that there is no known plaintext (for
 121 an attacker) in the beginning of the encrypted stream.
 122
 123 Some things to be discussed:
 124
 125  - What should CHALLEN be? Same as RSAKEYLEN? 256 bits? More/less?