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

[Radia Perlman <[e-mail]>]

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 <[e-mail]> wrote:

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