Re: [secdir] review of draft-ietf-tcpm-tcp-auth-opt-10

[Joe Touch <[e-mail]>]

Hi, Radia,

Thanks for your comments. Some clarifications below.

It would be useful to determine how to proceed on these issues.

Joe

Radia Perlman wrote:
> 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).

The document contains a list of the differences. One other notable
difference is that TCP-AO rekeys on each new TCP connection even when
used with manual master keys, without requiring an in-band or
out-of-band key negotation protocol.

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

The same keyID can be used for different valid (master) keys, so long as
they otherwise do not apply to the same TCP socket pair (connection), as
noted in the following requirement in 5.1:

   >> The IDs of MKTs MUST NOT overlap where their TCP connection
   identifiers overlap.

The primary reason for calling them "arbitrary" is to note that the
values are not monotonically increasing, have no reserved values, and
are otherwise not meaningful.

Would it help to clarify that in the doc?

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

It specifically allows for at least two capabilities:

1) master keys can be installed on a set of devices without coordinating
their keyIDs in advance	

2) master keys can be installed on a set of devices, and new devices
added to the set of keys later without requiring renumbering of keyIDs

These two capabilities are particularly important when used with
wildcards in the TCP socket pair of the master key tuple, i.e., when a
key is used among a set of devices specified by a pattern.

Would it be useful to add as motivation in the doc?

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

8.1 talks about how to use new keys in established connections.

9.4 addresses how to start a connection as follows:

   1. Find the per-connection parameters for the segment:

       a. If the segment is a SYN, then this is the first segment of a
          new connection. Find the matching MKT for this segment based
          on the segment's socket pair.

           i. If there is no matching MKT, omit the TCP-AO option.
               Proceed with transmitting the segment.

          ii. If there is a matching MKT, then set the per-connection
               parameters as needed (see Section 6). Proceed with the
               step 2.

This is enabled by the requirement that:

   >> An outgoing TCP segment MUST match at most one desired MKT,
   indicated by the segment's socket pair. The segment MAY match
   multiple MKTs, provided that exactly one MKT is indicated as desired.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Other information in the segment MAY be used to determine the desired
   MKT when multiple MKTs match; such information MUST NOT include
   values in any TCP option fields.


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

There is no such state. New connections are opened by using the
"desired" MKT for a socket pair (this is like setting one of the MKTs
for a set of overlapping MKTs as "use first").

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

Would it be useful, given the above already in the doc, to be more clear
about the idea of "desired" MKTs, and how MKTs are selected when a
connection is opened?

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

The implementation is not specified. The code is one way to implement
them, but not the only way. SNE properties are described throughout that
section.

We meant that to say more like "the requirements are specified in this
section, but the implementation is up to the user".

Does that address your concerns, or would it be useful to either update
the text to require the algorithm indicated, or to be more clear about
what is being required and what is offered as an example?

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

Section 9 as a whole describes how TCP-AO interacts with RFC 793. It
deals with sent and received segments separately, because they are
specified separately in 793, and typically implemented separately.

None of this is specific to asymmetric use.

> This
> should probably be modeled as having a special "no authentication" key
> configured as a valid key for the connection.

In TCP-AO, the default is that all packets are allowed as having no
authentication unless there is a key required. This differs from IPsec,
in which all packets would be blocked until a "default pass" rule were
installed.

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

Yes. This is consistent with RFC 793.

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

TCP-AO is not intended to 'startup' mid-connection. That would make the
use of SNE impossible, among other things.

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

I'll let the TSV ADs speak to this issue. I had thought we were
intending this to be a MUST for all TCP implementations, to encourage
its use. This would be in the spirit of IPsec being a MUST for IPv6 -
even though there are IPv6 implementations that don't support IPsec.

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

We're trying to offer a path for NAT traversal; another path is the
TCP-AO-nat extension, currently under ongoing discussion in the WG. The
point is more "do NAT traversal *like* IPsec", not to use "IPsec NAT
traversal" - i.e., traversal by UDP encapsulation.

We can update the doc to make that more clear.

The updates below would be useful to include, and the ADs can indicate
when they should be done (e.g., now, or during AUTH48).


> Typos:
> 
> 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"
>