Re: [tcpm] tcp-auth-opt issue: unique connection keys

At Wed, 30 Jul 2008 15:42:38 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Eric has raised the point that we should expect the TCP-AO system
> (TCP-AO and its required key management system [KMS]) to ensure unique
> connection keys.
> 
> draft-01 outlines the information that would be used to provide this
> information (i.e., derivative of the ISN, etc.).
> 
> Eric raised concerns about whether this function can reasonably be
> external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about
> the vagueness of the description. The current document was intended as a
> starting point for that discussion, FWIW.
> 
> One observation is that the KMS manages keys for connections - i.e., the
> socket pair (addr/port pair) - but has no info on ISNs. It can establish
> keys for that socket pair in the TSAD, but cannot generate appropriate
> session keys in advance of a connection being established.
> 
> Let's assume that the KMS includes the socket pair in the connection key
> when it inserts it into the TSAD (or that this can occur trivially for
> wildcard source port entries by re-hashing with the appropriate port
> when the first packet instantiates the entry). As a result, the ISNs are
> the only missing component to the connection key.
> 
> As was suggested before, use ISNs as follow:
> 
> 	SYN (without ACK) - use src_ISN from SYN, dst_ISN=0
> 	all other packets - use src_ISN, dst_ISN from first SYN rec'd
> 
> There are (at least) two ways to achieve this:
> 
> 1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation
> 
> 2) overwrite the TSAD keys established by the KMS
> 	i.e., on first SYN emitted
> 		key=hash(key, src_ISN)
> 	on SYN-ACK received
> 		key=hash(key, dst_ISN)
> 
> #1 has the advantage that it appears to work for simultaneous open, in
> which the SYNs are keyed based on different ISN info in each direction,
> but are received properly
> 
> #2 reduces the per-packet cost by the length of two ISNs, by investing
> in the hash at connection establishment. However, it appears to prohibit
> simultaneous open. Can anyone suggest a solution that supports
> simultaneous open?

Why does this prohibit simultaneous open? Because you're assuming
that there's only one possible key for a given host/port quartet?

-Ekr

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm