X-Git-Url: https://git.distorted.org.uk/~mdw/secnet/blobdiff_plain/4f5e39ecfaa49376b0a5c3a4c384e91a828c1105..0a6cbadea08d824e26838a18bb75745c78f27461:/NOTES diff --git a/NOTES b/NOTES index 84453df..3e9d71d 100644 --- a/NOTES +++ b/NOTES @@ -174,8 +174,9 @@ quite stable so the feature doesn't gain us much. Definitions: -A is the originating gateway machine -B is the destination gateway machine +A is the originating gateway machine name +B is the destination gateway machine name +A+ and B+ are the names with optional additional data, currently ignored PK_A is the public RSA key of A PK_B is the public RSA key of B PK_A^-1 is the private RSA key of A @@ -193,21 +194,21 @@ i? is appropriate index for receiver Note that 'i' may be re-used from one session to the next, whereas 'n' is always fresh. -The protocol version selection stuff is not yet implemented: I'm not -yet convinced it's a good idea. Instead, the initiator could try -using its preferred protocol (which starts with a different magic -number) and fall back if there's no reply. +The protocol version selection stuff is not yet implemented. Messages: -1) A->B: *,iA,msg1,A,B,protorange-A,nA +1) A->B: *,iA,msg1,A+,B+,nA -2) B->A: iA,iB,msg2,B,A,chosen-protocol,nB,nA +i* must be encoded as 0. (However, it is permitted for a site to use +zero as its "index" for another site.) + +2) B->A: iA,iB,msg2,B+,A+,nB,nA (The order of B and A reverses in alternate messages so that the same code can be used to construct them...) -3) A->B: {iB,iA,msg3,A,B,protorange-A,chosen-protocol,nA,nB,g^x mod m}_PK_A^-1 +3) A->B: {iB,iA,msg3,A+,B+,nA,nB,g^x mod m}_PK_A^-1 If message 1 was a replay then A will not generate message 3, because it doesn't recognise nA. @@ -215,18 +216,11 @@ it doesn't recognise nA. If message 2 was from an attacker then B will not generate message 4, because it doesn't recognise nB. -If an attacker is trying to manipulate the chosen protocol, B can spot -this when it sees A's message 3. - -4) B->A: {iA,iB,msg4,B,A,protorange-B,chosen-protocol,nB,nA,g^y mod m}_PK_B^-1 +4) B->A: {iA,iB,msg4,B+,A+,nB,nA,g^y mod m}_PK_B^-1 At this point, A and B share a key, k. B must keep retransmitting message 4 until it receives a packet encrypted using key k. -A can abandon the exchange if the chosen protocol is not the one that -it would have chosen knowing the acceptable protocol ranges of A and -B. - 5) A: iB,iA,msg5,(ping/msg5)_k 6) B: iA,iB,msg6,(pong/msg6)_k @@ -247,32 +241,29 @@ retransmit or confirm reception. It is suggested that this message be sent when a key times out, or the tunnel is forcibly terminated for some reason. -8) i?,i?,NAK (encoded as zero) - -If the link-layer can't work out what to do with a packet (session has -gone away, etc.) it can transmit a NAK back to the sender. The sender -can then try to verify whether the session is alive by sending ping -packets, and forget the key if it isn't. Potential denial-of-service -if the attacker can stop the ping/pong packets getting through (the -key will be forgotten and another key setup must take place), but if -they can delete packets then we've lost anyway... +**** Protocol sub-goal 3: send a packet -The attacker can of course forge NAKs since they aren't protected. But -if they can only forge packets then they won't be able to stop the -ping/pong working. Trust in NAKs can be rate-limited... +8) i?,i?,msg0,(send-packet/msg9,packet)_k -Alternative idea (which is actually implemented): if you receive a -packet you can't decode, because there's no key established, then -initiate key setup... +**** Other messages -Keepalives are probably a good idea. +9) i?,i?,NAK (NAK is encoded as zero) -**** Protocol sub-goal 3: send a packet +If the link-layer can't work out what to do with a packet (session has +gone away, etc.) it can transmit a NAK back to the sender. -9) i?,i?,msg0,(send-packet/msg9,packet)_k +This can alert the sender to the situation where the sender has a key +but the receiver doesn't (eg because it has been restarted). The +sender, on receiving the NAK, will try to initiate a key exchange. -Some messages may take a long time to prepare (software modexp on slow -machines); this is a "please wait" message to indicate that a message -is in preparation. +Forged (or overly delayed) NAKs can cause wasted resources due to +spurious key exchange initiation, but there is a limit on this because +of the key exchange retry timeout. 10) i?,i?,msg8,A,B,nA,nB,msg? + +This is an obsolete form of NAK packet which is not sent by any even +vaguely recent version of secnet. (In fact, there is no evidence in +the git history of it ever being sent.) + +This message number is reserved.