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

[Eric Rescorla <[e-mail]>]

At Wed, 30 Jul 2008 23:29:49 -0700,
Joe Touch wrote:
> 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.

This seems like unnecessary concreteness about the implementation.
The question isn't what's stored in the database but rather what
keys are used to protect the packets. Given that at least in the
manual key management mode the "origkey" is going to sit around
for years, it's a little weird to talk about it being "replaced".


> 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.

The performance advantage of either choice seem to be rather slight.

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

As I indicated in my previous comments, you could probably
cryptographically tolerate only one master MAC key and just use
differentiating prefixes rather than separate keys. Convention
is to use separate keys, though, in my experience, so this
probably requires less analysis. 

-Ekr

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm