Allow broadcast packets to be sent directly instead of via the MST.
[tinc] / doc / SECURITY2
index 3922f3f..62d6a07 100644 (file)
@@ -1,7 +1,7 @@
 This is the security documentation for tinc, a Virtual Private Network daemon.
 
 This is the security documentation for tinc, a Virtual Private Network daemon.
 
-   Copyright 2001 Guus Sliepen <guus@sliepen.warande.net>,
-             2001 Wessel Dankers <wsl@nl.linux.org>
+   Copyright 2001-2006 Guus Sliepen <guus@tinc-vpn.org>,
+             2001-2006 Wessel Dankers <wsl@tinc-vpn.org>
 
    Permission is granted to make and distribute verbatim copies of
    this documentation provided the copyright notice and this
 
    Permission is granted to make and distribute verbatim copies of
    this documentation provided the copyright notice and this
@@ -12,8 +12,6 @@ This is the security documentation for tinc, a Virtual Private Network daemon.
    provided that the entire resulting derived work is distributed
    under the terms of a permission notice identical to this one.
 
    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
 ----------------------------------
 
 Proposed new authentication scheme
 ----------------------------------
 
@@ -27,13 +25,11 @@ client  <attempts connection>
 
 server  <accepts connection>
 
 
 server  <accepts connection>
 
-client  ID client 9 0
-              |   | +-> options
+client  ID client 12
               |   +---> version
               +-------> name of tinc daemon
 
               |   +---> version
               +-------> name of tinc daemon
 
-server  ID server 9 0
-              |   | +-> options
+server  ID server 12
               |   +---> version
               +-------> name of tinc daemon
 
               |   +---> version
               +-------> name of tinc daemon
 
@@ -64,6 +60,19 @@ client  CHAL_REPLY 816a86
 
 server  CHAL_REPLY 928ffe
                       +-> 160 bits SHA1 of H1
 
 server  CHAL_REPLY 928ffe
                       +-> 160 bits SHA1 of H1
+
+After the correct challenge replies are recieved, both ends have proved
+their identity. Further information is exchanged.
+
+client  ACK 655 123 0
+             |   |  +-> options
+                |   +----> estimated weight
+                +--------> listening port of client
+
+server  ACK 655 321 0
+             |   |  +-> options
+                |   +----> estimated weight
+                +--------> listening port of server
 --------------------------------------------------------------------------
 
 This new scheme has several improvements, both in efficiency and security.
 --------------------------------------------------------------------------
 
 This new scheme has several improvements, both in efficiency and security.
@@ -107,9 +116,6 @@ 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.
 
 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?
 Some things to be discussed:
 
  - What should CHALLEN be? Same as RSAKEYLEN? 256 bits? More/less?