[tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05

[Eric Rescorla <[e-mail]>]

$Id: draft-ietf-tcpm-tcp-auth-opt-05-rev-real.txt,v 1.1 2009/07/26 22:18:40 ekr Exp $

This draft seems to resolve all my major technical issues.
The comments below are primarily editorial.


TECHNICAL
   The relationship between MKTs and traffic keys is shown in Figure
   Figure 3. Traffic keys are indicated with a "*". Note that every MKT
   derives all four traffic keys, regardless of whether all four are
   needed for a given connection. Section 7.2 provides further details
   on how traffic keys are derived.

This seems like an unwarranted requirement. The keys are generated
independently, so why make implementations gnerate keys they don't
need?



S 8.2.
   When a segment is received, the following algorithm (written in C)
   computes the SNE used in the MAC; an equivalent algorithm can be
   applied to the "SND" side:

I know it seems like I'm nitpicking about this, but this algorithm is 
*not* valid C: # is not a comment character and C identifiers may not
contain .s in the name. I suppose for the latter you could be arguing that these
are structs, but then where's the defn of those? This seems like
perfectly legitimate pseudocode, but if you're going to claim it's C, 
it really needs to be valid C. I would remove the claim.

S 9.5.
As I read this description, if an implementation receives a TCP segment
with TCP-AO but it doesn't match any existing MKT, it should silently
accept it. I don't agree with this. It should discard it. It's clearly
not valid.

           i. If lengths differ, silently discard the segment. Log
               and/or signal the event as indicated in Section 9.3.

I observe that this logging suggestion has the possibility to be
a DoS in and of itself. If we're going to recommend logging,
we need to recommend log throttling.








EDITORIAL
Abstract
   protects against replays even for long-lived TCP connections, and

s/protects against replays/detects replayed segments/

   set of MACs with minimal other system and operational changes. TCP-AO
   uses its own option identifier, even though used mutually exclusive
   of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is

I would just remove "even though..." This wording is clumsy and
it probably isn't necessary at the level of the abstract


S 2.
   Section 9.6). This document obsoletes the TCP MD5 option with a more
   general TCP Authentication Option (TCP-AO), to support the use of

s/obsoletes/replaces/


   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-AO is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case to support some routing protocols, or in cases
   where keys need to be tightly coordinated with individual transport
   sessions [Be07].

I would remove this paragraph entirely, but if you with to retain
it, I don't think it does that great a job of explaining the relationship
here. Fundamentally people have complained that IPSec is too 
heavyweight. I would rewrite this as:

   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. Rather,
   it is intended for the limited goal of providing traffic integrity
   and denial of service (DoS) protection for TCP connections in
   settings where a simpler solution than IPsec/IKE is desired.


S 2.1
   o  TCP-AO ensures per-connection traffic keys as unique as the TCP
      connection itself, using TCP's initial sequence numbers (ISNs) for

s/ensures/provides/
s/as unique/which are as unique/


   o  TCP-AO forces a change of computed MACs when a connection
      restarts, even when reusing a TCP socket pair (IP addresses and
      port numbers) [Be07].

I think I know what this is supposed to mean, but I think it's
getting off into the weeds. However, if you want to say it,
try:

   TCP-AO does not allow packets from one TCP connection to
   be replayed on another TCP connection, even if the
   connection parameters (IP addess and port numbers)
   are the same.


S 4.2.
   The new TCP-AO option provides a superset of the capabilities of TCP
   MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new
   Kind field, and similar Length field to TCP MD5, a KeyID field, and a
   NextKeyID field as shown in Figure 2.

Isn't a similar length field a requirement of the TCP options layout.
I would also observe that SP4 is now over 20 years old and was never
widely deployed even then, so references to the spirit of SP4 feel
anachronistic.

      Values of 4 and other small values larger than 4 (e.g., indicating
      MACs of very short length) are of dubious utility but are not
      specifically prohibited.

It's probably worth stating explicitly here that the MAC length is
dictated by the MKT, not the option.



S 5.

I would rewrite this first paragraph as follows:

TCP-AO makes use of two sets of keys:

- Master Key Tuples (MKTs) are managed either manually or by a
  (future) key management protocols. They comprise a master key, the
  set of cryptographic algorithms to be used with that key, and the
  TCP connection identifiers to which the MKT applies. MKTs are never
  used directly to protect data but rather are used to derive traffic
  keys.  Multiple MKTs may apply to a given connection, and are
  distinguished by a key identifier (key-id).

- Traffic keys are used to compute the MAC for each TCP segment.  Each
  TCP connection has a fresh set(s) of traffic keys which are
  automatically derived from the appropriate MKT(s) for that
  connection. The traffic key derivation function includes the TCP
  Initial Sequence numbers, resulting in a high probability that
  traffic keys will be unique, even if the IP address and TCP port are
  reused.


S 5.1.
      >> MKT IDs MUST support any value, 0-255 inclusive. There are no
      reserved ID values.

MKTs don't support anything. TCP-AO implementations do. This construct
appears in a number of places in the document and should be replaced
with "Implementations MUST suupport"


      Implementations are advised to keep master key values in a
      private, protected area of memory or other storage.

I'm curious if anyone has a concrete notion of what this means. As I
understand the situation, Cisco routers (for example) are a single
monolothic process. How would you do this for a Cisco?


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

IDs aren't ranges. I would rewrite as:

Any two MKTs with overlapping TCP connection identifiers [could we
use "specifications" here more generally] MUST have distinct
MKT IDs.


S 5.2.
MKTs don't derive (see above).

I'm not sure this taxonomy and the use of send/receive is that
useful here, since each side has its own send and receive.
It gets doubly confusing when you say

   Note that the keys are directional. A given connection typically uses
   only three of these keys, because only one of the SYN keys is
   typically used. All four are used only when a connection goes through
   'simultaneous open' [RFC793].

But as a practical matter, if Alice does an active open (connect) to Bob,
she will generate:

   o  Send_SYN_traffic_key

   o  Send_other_traffic_key

   o  Receive_other_traffic_key


And Bob will generate:

   o  Receive_SYN_traffic_key

   o  Send_other_traffic_key

   o  Receive_other_traffic_key

But Bob's Receive keys are Alice's send keys and vice versa.

So, I think for clarity, this should be rewritten not to talk
about the connection but about the implementation's view.
E.g.,

   Each side of the connection needs up to four traffic keys:

   o  Send_SYN_traffic_key

   o  Receive_SYN_traffic_key

   o  Send_other_traffic_key

   o  Receive_other_traffic_key
   
   The only time when the *_SYN keys are used is when sending
   a SYN before having seen any packets from the other side.
   
   A given side typically uses only three of these keys, because only
   one of the SYN keys is typically used: either that node will be
   doing an active open and will need the Send_SYN_traffic key or will
   be doing a passive open and will need the Send_SYN_traffic key. All
   four are used only when a connection goes through 'simultaneous
   open' [RFC793].



S 5.3.
This whole discussion of how many MKTs can match seems confusing
and self-contradictory.

My understanding of the rules is as follows:

- Any outgoing packet, which has not yet been processed by TCP-AO,
  may match any number of MKTs, but each MKT must have a distinct
  key-id. Once that packet has been processed by AO, it must
  match only one MKT, determined by key-id.

- Any incoming packet must match either one or zero MKTs.

Is there any disagreement that this is correct? If so, I recommend
rewriting the text to contain more or less just this.



S 6.
Current_Key and Next_Key seem confusing here because we're punning
on the use of key.

- Conenctions must store the current traffic keys (or enough information
  to regenerate them). They must also store the key-id needed to indicate
  those traffic keys.

- The SNEs.

There is no need to *store* Next_Key. It can be regenerated every time.
What's required is simply that it appear on the wire. I don't see any
need to store the MKTs with the connection either. They're "associated"
in that they match, I suppose...


S 7.1.

   o  MAC_truncation - the number of bytes to truncate the output of the 
      MAC to. This is indicated by the MAC algorithm, as specified in 
      [ao-crypto]. 

I don't think it makes sense to talk about truncation here.
The MACs produce a value that is crammed into the packet.
If there's a separate spec that describes the MACs, it's not
AO's business whether those MACs were produced by a truncation process.



S 7.2.
   o  Output_length - The desired output length of the KDF, i.e., the
      length to which the KDF's output will be truncated. In TCP-AO, the
      output_length is the PRF_truncation value of the MKT. This is
      specified by the KDF as described in [ao-crypto].

Everything from i.e., seems (1) superfluous and (2) isnufficiently
general. Who says the PRF is truncated?


   The data used as input to the KDF combines TCP socket pair with the
   endpoint initial sequence numbers (ISNs) of a connection. This

s/TCP socket/the TCP socket/


   Traffic keys are directional, so "source" and "destaination" are

s/destaination/destination/


S 7.3.
   of the TCP-AO option), or for coordinating rekeying during a
   connection. We assume out-of-band mechanisms for MKT establishment,

It does now...


   We encourage users of TCP-AO to apply known techniques for generating
   appropriate MKTs, including the use of reasonable master key lengths,
   limited traffic key sharing, and limiting the duration of MKT use
   [RFC3562]. This also includes the use of per-connection nonces, as
   suggested in Section 7.2.

This seems like old text. We don't encoruage people to use per-connection
nonces, it's part of the protocol. I don't agree that a recommendation
to limit lifetime is really that sensible. I would simply remove this entirely.


S 9.5.
                     a. Optionally, set a timer on the MKT indicated by
                       the current_key and segment socket pair to
                       ensure that the MKT cannot be deleted for 2*MSL.
                       If a timer has already been set, reset the
                       timer.

                       This timer is advisory only. Removing MKTs with
                       unexpired timers can result in a user-level
                       warning, but is not prohibited. Implementation
                       of timers is not required.

                     b. Set Current_key to the NextKeyID MKT.

I would reverse the order of these, since (a) is required and (b) is
optional.


S 10.
Was TCP-MD5 Mandatory to Implement? If not, this shouldn't be either.
Even if so, this seems like kind of an unwarranted requirement.

-Ekr