Last Call Review of draft-ietf-tcpm-tcp-auth-opt-
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This protocol is essentially a lightweight special purpose version of the Authentication Header (AH) protocol (RFC 4302). It is intended as a generalization, improvement, and replacement of the TCP-MD5 protocol documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, which had certain unique requirements (like keeping a TCP connection up through crashes of one or both endpoints). The proposal does not explicitly limit the applicability.
One question that leaps to mind is why there is both this and AH (not to mention ESP).
The primary differences between TCP-AO and AH are:
TCP-AO can only be used to protect TCP connections (because the integrity checksum is included in a TCP extension header).
TCP-AO only increases the packet length by 16 bytes with default crypto (AH adds 24 bytes with default crypto).
While both are technically independent of any particular keying mechanism, AH was designed to be keyed using IKE (RFC 4306) while TCP-AO was designed for manual keying. In particular, TCP-AO includes an in-band protocol for signally when a new key is available so that when new keys are configured at the two ends of a connection, both ends will start using the new key only when it is available at both ends.
Review of the document:
Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the document says that KeyID values are arbitrary. This is not quite true. The same KeyID value cannot be used for two different valid keys. (So an implementation must assure that all nodes have deconfigured or expired keys with a particular KeyID value before assigning that KeyID value to a new key.
Section 4.2 also implies that the KeyID for the same master key used to generate different encryption keys for the two different directions of TCP can have different KeyIDs in the two different directions. That seems like a useless generality.
Section 8.1 specifies how to choose the key to use in a next packet based on the RNextKeyID in the last received packet. It does not specify how to choose the key when starting a new connection (i.e. sending a SYN). I would assume that there is some non-connection state saved on the node (and preserved across crashes) that remembers the last RNextKeyID received on any connection, and this is used to open new connections. The first time a connection is opened to a node that has never successfully been connected to, the sender would cycle through all valid keys until finding one the other end will accept. In any case, the spec should say.
Section 8.2 paragraph 5 says the implementation of SNEs (extended sequence numbers) is not specified in this document. This seems entirely unacceptable, since the two ends must implement them identically for the protocol to work and they aren't specified anywhere else. Further, it appears that they *are* specified in the paragraphs that follow (though stated as an example rather than a spec).
Sections 9.3-9.5 appear to be dealing with the case where one end of the connection has been configured to use TCP-AO but the other has not. This should probably be modeled as having a special "no authentication" key configured as a valid key for the connection. The initiator would not use that key when sending a SYN, but would switch to that key if he got an unsigned ACK from the other end or he got an unsigned SYN from the other end. There is an implication that existing implementations will ignore the TCP-AO extension if they don't support TCP-AO. Is that true? (When in this mode, there is no security, but it is a way to add initial keys to the two endpoints without breaking connectivity during the period when one end has been keyed and the other has not. Once both ends have received a correctly signed message from the other end, they should stop accepting unsigned ones.
Section 10 says "TCP implementations MUST support TCP-AO". What does this mean? Implementations of this spec MUST implement this spec. It is not reasonable to expect *all* TCP implementations to support TCP-AO.
Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if NATs are present, but does not suggest how that would be negotiated. Or is this saying that IPsec NAT traversal is preferred in any scenario where NAT traversal *might* be needed?
Page 4 2nd to last paragraph: There is a badly structured sentence that could be fixed in multiple ways. One way would be: "This document obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO). The new design supports the use of other (stronger) hash functions, provides replay protection for long-lived connections and across repeated instances of a single connection, coordinates key changes between endpoints, and provides a more structured recommendation for external key management."
Section 3 paragraph 3: "proceeding -> preceding"
Page 13 3rd to last line: "match at exactly" -> "match exactly"
Page 21 3rd to last line: "when is" -> "when it is"