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

[Joe Touch <[e-mail]>]

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

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

| 2. Change the key used to compute the MAC inside the protoco.

Can you explain this?

| 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?)

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

iEYEARECAAYFAkiN130ACgkQE5f5cImnZrsRLACfd5jC/XzZgCmYsvd8Kwex88pw
op8AoMVQvcQDcs6YeuYKiFJ8MM9V0NiH
=Up28
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm