www.tinc-vpn.org Git - tinc/blob - doc/SECURITY3

   1 This is the security documentation for tinc, a Virtual Private Network daemon.
   2
   3    Copyright 2001-2003 Guus Sliepen <guus@sliepen.eu.org>,
   4              2001-2003 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: SECURITY3,v 1.1 2003/10/01 09:43:01 guus Exp $
  16
  17 Proposed authentication scheme for tinc 2.0
  18 -------------------------------------------
  19
  20 daemon  message
  21 --------------------------------------------------------------------------
  22 A       <attempts connection>
  23
  24 B       <accepts connection>
  25
  26 A       ID "A" <version> <cipher> <digest> <compression>
  27
  28 B       ID "B" <version> <cipher> <digest> <compression>
  29
  30 A       META_KEY <Diffie-Hellman public key> <nonce> <signature>
  31
  32         Where signature is that of the public key and nonce, using A's
  33         private RSA key.
  34
  35 B       META_KEY <Diffie-Hellman public key> <nonce> <signature>
  36
  37 Both sides now use Diffie-Hellman to compute the shared secret key. Because
  38 only A and B can decrypt the respective public keys, only A and B can know this
  39 shared key.
  40
  41 From the shared key the following things will be derived:
  42
  43 A's symmetric cipher key
  44 A's symmetric cipher IV
  45 A's HMAC key
  46 A's verification data
  47 B's symmetric cipher key
  48 B's symmetric cipher IV
  49 B's HMAC key
  50 B's verification data
  51
  52 From now on:
  53  - A will symmetrically encrypt outgoing traffic using A's symmetric cipher key
  54  - B will symmetrically encrypt outgoing traffic using B's symmetric cipher key
  55
  56 A       ACK <A's verification data> <port> <weight> <options>
  57
  58 B       ACK <B's verification data> <port> <weight> <options>
  59
  60 After ACKs with the correct verification messages have been recieved, both ends have proved
  61 their identity.
  62 -------------------------------------------------------------------------
  63
  64 Changes from the protocol used in tinc 1.0pre5 up to 1.0.1:
  65
  66 Instead of directly sending the keys which will be used for symmetric
  67 encryption, a Diffie-Hellman key exchange will be done.  This prevents an
  68 attacker from being able to send and use his own key if he can't read the key
  69 that is sent to him.  It also allows us to have perfect forward security, since
  70 only public keys are exchanged in the Diffie-Hellman key exchange, so after the
  71 RSA keys have been compromised it still is not possible to recover the shared
  72 key from recorded authentications from the past.
  73
  74 The CHALLENGE/RESPONSE messages have been replaced by verification data in the
  75 ACK message, which saves two round trips.
  76
  77 The ID messages will also contain information about the cipher and digest
  78 algorithm and compression to use for encrypting the TCP connections.
  79