Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

[Joe Touch <[e-mail]>]

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

Hi, Adam,

Adam Langley wrote:
| 2008/7/14  <[e-mail]>:
|> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
|>        Title           : The TCP Authentication Option
|>        Author(s)       : J. Touch, et al.
|>        Filename        : draft-ietf-tcpm-tcp-auth-opt-01.txt
|
| An item which I believe is unclear in the spec:
|
| Are KeyIDs specific to a single direction? E.g if A and B are
| transmitting with different keys, could they both call them KeyID 0?
| At the moment the wording around the TSAD seems to allow this
| (specifically 6.1).

Yes.

| Also, comments on the linux netdev mailing list got me thinking more
| about key rotation and I think the spec probably needs a sentence or
| two advising about the use of key rotation.

How often would be in the key management document; we don't specify that.

| The spec currently suggests that rotation occur every 2**31 bytes
| sent. It's not clear if the keys for each direction are assumed to
| rotate independently or not.

They are. The purpose of key rotation based on 2**31 is replay attacks,
not frequency of rotation for other reasons. Others have noted that such
rotation may not be needed with modern HMACs.

| If the directions are independent then a large one-way transfer allows
| an attacker to build up a dictionary of valid ACKs. Since the transfer
| is only one way, the ACKing side will never rotate keys. Thus an
| attacker could step in and convince the sender that everything was
| fine even if the true destination was dead.

The ACKing side needs to rotate keys only when its seqnums rollover, not
the ones it's ACKing.

| If the keys rotate after 2**31 bytes sent or recved there is a
| possible window issue. Consider a host which is sending with a very
| large window over a high delay link. It transmits several key
| rotations worth of data before the first ack comes back from the other
| side. Since this ack was elicited by the beginning of the data, it
| will be transmitted with the first key. If the first key is still
| active, everything is fine, but if the key window has rotated to the
| point where old keys are getting evicted then the ACK will be
| rejected.

The key rotations are supposed to be reasonably synchronized and/or
overlapped to avoid such issues.

| This currently shouldn't be a problem because the max window size is
| 1GB, which is less than 2**31 bytes. At some point in the future, if
| window scaling is allowed to grow past 2**14, then key rotation could
| limit the window size.

This isn't an issue of window scaling; it's an issue of replaying. Keys
are rotated per 2**31 (recommended, at least) based on the rollover of
the seqno; they can be rotated for other reasons as well.

| Given all these questions, I think the spec should make some advisory
remarks.
|
| I'm not too sure, but I think I like rotating a per-direction key
| better. The ACK dictionary attack is unfortunate, but if we aren't
| having real sequence numbers then our security is limited at best
| anyway. Based on that I'd suggest a 2-key pair, where, for a
| half-connection from A to B: B RX enables key 1 at 2**30 bytes
| received, A switches to key 1 at 2**31 bytes, B RX enables a new key 0
| at 2**31 + 2**30 bytes, A switches to new key 0 at 2**32 etc. That
| would also mean that KeyIDs are specific to a given half-connection.

They should already be; the TSAD entries are specified per-direction for
that reason.

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

iEYEARECAAYFAkiE9UgACgkQE5f5cImnZrudaQCgzwgXYSauxf9kwmIvkpAQFZje
82kAn3mVEgGOOcBKiaOC71JKtPdepwaw
=6DCJ
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm