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

[Joe Touch <[e-mail]>]

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