NOTES

   1 * Design of new, multi-subnet secnet protocol
   2
   3 Like the first (1995/6) version, we're tunnelling IP packets inside
   4 UDP packets. To defeat various restrictions which may be imposed on us
   5 by network providers (like the prohibition of incoming TCP
   6 connections) we're sticking with UDP for everything this time,
   7 including key setup.
   8
   9 Other new features include being able to deal with subnets hidden
  10 behind changing 'real' IP addresses, and the ability to choose
  11 algorithms and keys per pair of communicating sites.
  12
  13 ** Configuration and structure
  14
  15 The network is made up from a number of 'sites'. These are collections
  16 of machines with private IP addresses. The new secnet code runs on
  17 machines which have interfaces on the private site network and some
  18 way of accessing the 'real' internet.
  19
  20 Each end of a tunnel is identified by a name. Often it will be
  21 convenient for every gateway machine to use the same name for each
  22 tunnel endpoint, but this is not vital. Individual tunnels are
  23 identified by their two endpoint names.
  24
  25 ** Protocols
  26
  27 *** Protocol environment:
  28
  29 Each gateway machine serves a particular, well-known set of private IP
  30 addresses (i.e. the agreement over which addresses it serves is
  31 outside the scope of this discussion). Each gateway machine has an IP
  32 address on the interconnecting network (usually the Internet), which
  33 may be dynamically allocated and may change at any point.
  34
  35 Each gateway knows the RSA public keys of the other gateways with
  36 which it wishes to communicate. The mechanism by which this happens is
  37 outside the scope of this discussion. There exists a means by which
  38 each gateway can look up the probable IP address of any other.
  39
  40 *** Protocol goals:
  41
  42 The ultimate goal of the protocol is for the originating gateway
  43 machine to be able to forward packets from its section of the private
  44 network to the appropriate gateway machine for the destination
  45 machine, in such a way that it can be sure that the packets are being
  46 sent to the correct destination machine, the destination machine can
  47 be sure that the source of the packets is the originating gateway
  48 machine, and the contents of the packets cannot be understood other
  49 than by the two communicating gateways.
  50
  51 XXX not sure about the address-change stuff; leave it out of the first
  52 version of the protocol. From experience, IP addresses seem to be
  53 quite stable so the feature doesn't gain us much.
  54
  55 **** Protocol sub-goal 1: establish a shared key
  56
  57 Definitions:
  58
  59 A is the originating gateway machine
  60 B is the destination gateway machine
  61 PK_A is the public RSA key of A
  62 PK_B is the public RSA key of B
  63 PK_A^-1 is the private RSA key of A
  64 PK_B^-1 is the private RSA key of B
  65 x is the fresh private DH key of A
  66 y is the fresh private DH key of B
  67 k is g^xy mod m
  68 g and m are generator and modulus for Diffie-Hellman
  69 nA is a nonce generated by A
  70 nB is a nonce generated by B
  71 iA is an index generated by A, to be used in packets sent from B to A
  72 iB is an index generated by B, to be used in packets sent from A to B
  73 i? is appropriate index for receiver
  74
  75 Note that 'i' may be re-used from one session to the next, whereas 'n'
  76 is always fresh.
  77
  78 Messages:
  79
  80 1) A->B: *,iA,msg1,A,B,nA
  81
  82 2) B->A: iA,iB,msg2,B,A,nB,nA
  83
  84 (The order of B and A reverses in alternate messages so that the same
  85 code can be used to construct them...)
  86
  87 3) A->B: {iB,iA,msg3,A,B,nA,nB,g^x mod m}_PK_A^-1
  88
  89 If message 1 was a replay then A will not generate message 3, because
  90 it doesn't recognise nA.
  91
  92 If message 2 was from an attacker then B will not generate message 4,
  93 because it doesn't recognise nB.
  94
  95 4) B->A: {iA,iB,msg4,B,A,nB,nA,g^y mod m}_PK_B^-1
  96
  97 At this point, A and B share a key, k. B must keep retransmitting
  98 message 4 until it receives a packet encrypted using key k.
  99
 100 5) A: iB,iA,msg5,(ping/msg5)_k
 101
 102 6) B: iA,iB,msg6,(pong/msg6)_k
 103
 104 (Note that these are encrypted using the same transform that's used
 105 for normal traffic, so they include sequence number, MAC, etc.)
 106
 107 The ping and pong messages can be used by either end of the tunnel at
 108 any time, but using msg0 as the unencrypted message type indicator.
 109
 110 **** Protocol sub-goal 2: end the use of a shared key
 111
 112 7) i?,i?,msg0,(end-session/msg7,A,B)_k
 113
 114 This message can be sent by either party. Once sent, k can be
 115 forgotten. Once received and checked, k can be forgotten. No need to
 116 retransmit or confirm reception. It is suggested that this message be
 117 sent when a key times out, or the tunnel is forcibly terminated for
 118 some reason.
 119
 120 XXX not yet implemented.
 121
 122 8) i?,i?,NAK/msg8
 123
 124 If the link-layer can't work out what to do with a packet (session has
 125 gone away, etc.) it can transmit a NAK back to the sender.  The sender
 126 can then try to verify whether the session is alive by sending ping
 127 packets, and forget the key if it isn't. Potential denial-of-service
 128 if the attacker can stop the ping/pong packets getting through (the
 129 key will be forgotten and another key setup must take place), but if
 130 they can delete packets then we've lost anyway...
 131
 132 The attacker can of course forge NAKs since they aren't protected. But
 133 if they can only forge packets then they won't be able to stop the
 134 ping/pong working. Trust in NAKs can be rate-limited...
 135
 136 Alternative idea (which is actually implemented): if you receive a
 137 packet you can't decode, because there's no key established, then
 138 initiate key setup...
 139
 140 Keepalives are probably a good idea.
 141
 142 **** Protocol sub-goal 3: send a packet
 143
 144 9) i?,i?,msg0,(send-packet/msg9,packet)_k