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

[Joe Touch <[e-mail]>]

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


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

OK; we're dancing around terms here. TCP-AO uses a _separate_ document
to specify the out-of-band key mechanism. What that includes can be
discussed in that context - e.g., on SAAG.

| 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 "KMP" (or whatever we're calling it) should be underway in SAAG; if
it has stalled, then we'll address that issue off-list.

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

That's burying the key generation protocol inside TCP-AO. My
understanding is that this is the reason for an external mechanism,
whatever it is called, and regardless of whether it explicitly or
implicitly coordinates with the other end (you're referring to implicit
coordination).

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

If so, then why generate fresh keys on rollover?

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

iEYEARECAAYFAkiN4CAACgkQE5f5cImnZrsZfACg5JAuUmZvhyEEZ8t62f5L3ngc
shwAoMqqK1ZZ3lbEPWpl535UbP+SHPSq
=VXgX
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm