Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

At Mon, 28 Jul 2008 07:28:13 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Eric,
> 
> Eric Rescorla wrote:
> | I did want to make one more note.
> |
> | At Sun, 27 Jul 2008 23:38:32 -0700,
> | Joe Touch wrote:
> |> | - The discussion of key rollover seems incomplete
> |> |
> |> |       >> TCP-AO implementations SHOULD change keys for a connection at
> |> |       least every 2^31 bytes, to avoid resending segments with the same
> |> |       TCP sequence number, data, and length under the same key.
> |> |
> |> | How is this intended to work?
> |>
> |> The key management mechanism should react to sequence numbers rolling
> |> over the ISN (perhaps masking out the high bit to roll over twice as
> often).
> |
> | Regardless of whether there is a KMP, it strikes me as unwise to punt this
> | job to it.
> 
> There is a KMP; it is required (and we can't move forward to submit this
> as final until there is).

Well, as I've indicated previously, I don't agree that a KMP is
required or desirable. It's quite straightforward to make this system
work with a single, pairwise, static key, provided you have an
appropriate key diversification mechanism. If you want to call that a
KMP, I suppose you could, but since it doesn't require actually
exchanging any messages, I would not do so.

If your assertion is that a KMP is required to make this protocol
useful, given that (1) there's no draft for such a KMP on the
horizon and (2) the most likely consumers of this draft, the 
routing/ops community, seem to have no interest in doing a KMP, 
then I think this raises serious questions about the viability
of this approach.

> | The TCP authentication protocol should be able to provide security for
> | packets even in the face of sequence number rollover, out to the
> | limits of security of the MAC algorithm (which far exceed 2^31 bytes
> | in both cases). There are (at least) two potential approaches:
> |
> | 1. Use a (synthetic) extended sequence number.
> 
> We discussed this, but there are concerns with interactions with TCP. We
> don't want to add separate, coordinated state outside the existing TCP
> state mechanism.

Uh, ok... It's not like this doesn't need to be tightly coordinated
with TCP in any case.

> | 2. Change the key used to compute the MAC inside the protoco.
> 
> Can you explain this?

Sure. You have a per-connection key. Every time the sequence number
rolls, you run the KDF again to generate a fresh per-connection key.
No KMP required. (This meshes with my previous key diversification
comments).

> | But I don't think it's a good idea to punt this to the KMP, since
> | you don't really need to change the key for any cryptographic reason.
> 
> If there's no cryptographic reason, why would we need to change the key
> at all? I.e., isn't the need for a unique per-packet nonce a
> cryptographic requirement (if not, why do we care?)

There is no need for a unique per-packet nonce.

-Ekr

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