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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
| 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?

The difference between #1 and #2 is that #2 overwrites the TSAD entries
with the hash. Yes, the issue with simultaneous opens is the need for
multiple keys per "host/port quartet" (can we call that a socket pair,
as per 793?).

<individual hat on>
We could also keep multiple keys just in case there's a simultaneous
open, until at least the SYN-ACK is received on a given side (at which
point we can drop the extra keys).

E.g.:
	origkey = as installed by KMS
	SYNkey = hash(origkey, src_ISN) computed when SYN is sent
		before an incoming SYN is rec'd (by either side)
	connkey = hash(origkey, src_ISN, dst_ISN)
		computed when the ack of the SYN is rec'd or
		an incoming SYN is ack'd

only the connkey can overwrite the origkey in the TSAD. for space
reasons, we don't want to keep too many keys around.

If we prepend the ISNs to the data, we avoid separate calls to the MAC
algorithm during the three-way handshake, but we keep reprocessing the
ISNs for each packet sent.
<individual hat off>

So at this point both #1 and #2 could support simultaneous opens. Which
method is preferable and why?

Comments?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiRW90ACgkQE5f5cImnZrtgqwCgymZFT0TqMxVPOJOmsdD+JoMQ
GWAAoJbaASP2CRh2oJYLDRBfa3uKAKny
=ypqa
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm