[tcpm] Review of draft-duan-tcpm-tcp-ao-rekeying-00

[Eric Rescorla <[e-mail]>]

$Id: draft-duan-tcpm-tcp-ao-rekeying-00-rev.txt 112 2010-03-21 00:28:12Z ekr $

In TCP-AO a receiver can signal that it is ready to receive authenticated
packets using a new key, but it cannot signal that it wishes to send
with a new key. This draft describes a mechanism to provide that
signaling.

It's unclear to me what benefit this draft provides. The basic principle
behind TCP-AO is that key changes are coordinated between the sides:
a new key cannot be used until it is known by both endpoints. At the
time when that key is established, the establishment process (likely
a phone call or email) can indicate that the new key is preferred,
in which case both sides will start advertising the ability to
receive it as soon as it is installed. Thus, this mechanism is
unnecessary. The authors argue that:

   the RNextKeyID MKT when the RNextKeyID MKT is ready.  It works well
   for changing the incoming key.  However, if a sender finds its MKT
   which is used to authenticate outgoing segments has been attacked and
   should change into a new one, it can do nothing but has to wait for
   the receiver sending a segment which carries a different RNextKeyID.

   In this case, the communication becomes dangerous probably because
   the sender always authenticates outgoing segment by an attacked key
   before the receiver changes the incoming key.  This paper proposes a
   method which the sender can trigger the other part to change the
   RNextKeyID when the sender finds the former outgoing key is not safe
   any longer.

I don't find this convincing. If you know your key has been compromised
you need to immediately notify your peers, who will want to promptly
disable it. I don't see that any new protocol mechanisms are needed.

Incidentally, the use of 0xff as a signal in the RNextKeyID field
clearly violates S 4.2 of TCP-AO:

   o  RNextKeyID: An unsigned 1-byte field indicating the MKT that the
      sender is ready use to receive authenticated segments, i.e., the
      desired 'receive next' keyID.

      It supports efficient key change coordination, to be discussed
      further in Section 8.1. Note that the RNextKeyID has no
      cryptographic properties - it need not be random, nor are there
      any reserved values.

-Ekr