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

From: Radia Perlman <[email-masked]>
Date: Sat, 6 Mar 2010 21:30:41 -0800

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?

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"

---

From: Joe Touch <[email-masked]>
Date: Sun, 07 Mar 2010 11:07:01 -0800

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:
> This protocol is essentially a lightweight special purpose version of
> the Authentication Header (AH) protocol (RFC 4302). It is intended as a
> 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.
>  
> 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:
> 
> 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?

> 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

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?

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

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

---

From: Radia Perlman <[email-masked]>
Date: Sun, 7 Mar 2010 11:28:55 -0800

re: all the opportunities for clarification: I certainly like documenting
clarifications and motivations, whether it be in the base document, or a
companion "tutorial/motivation" document.

Radia

---

From: Joe Touch <[email-masked]>
Date: Sun, 07 Mar 2010 11:44:13 -0800

Hi, Radia (et al.),

I expect that this will be 'documented' not only as an RFC, but as a
published paper elsewhere; that paper might provide the context, but it
won't be citable in the RFC (not ready yet). I don't see the need for
that as an RFC per se - it's more useful as advertisement to the
community at large, IMO, so I'd like to seek a wider venue for that.

Joe

Radia Perlman wrote:
> re: all the opportunities for clarification: I certainly like
> documenting clarifications and motivations, whether it be in the base
> document, or a companion "tutorial/motivation" document.
>  
> Radia
> 
> On Sun, Mar 7, 2010 at 11:07 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi, Radia,
>