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

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Jul 2009 16:27:11 -0700

$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

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jul 2009 04:34:23 -0700

Hi, Eric,

Agreed on the editorial feedback, and thanks. Notes on the technical
issues below - I think we agree on most.

Joe

> independently, so why make implementations gnerate keys they don't

Agreed - I was trying to say that every MKT *can* derive any of the four
traffic keys, not that all four *are* always derived.

...
> accept it. I don't agree with this. It should discard it. It's clearly

Agreed. The original intent was to allow communication with an endpoint
that didn't have an MKT, but that clearly won't work because MKTs cover
both directions, and thus the ACKs won't be received anyway.

> we need to recommend log throttling.

I thought we had; I'll check and add or add a reminder.

> EDITORIAL
...
>    general TCP Authentication Option (TCP-AO), to support the use of

I thought we needed to use the term "obsoletes" somewhere. Maybe this is
the right sentence to do so, maybe not.

...
> dictated by the MKT, not the option.

The length of the MAC field is dictated by the option. If the option
says the MAC is 70 bytes, and the MKT says it should be 72, then the
packet would fail authentication.

I'll correct to call this "indicating MAC fields of very short length"

...
> monolothic process. How would you do this for a Cisco?

Keep the keys in an area that non-operator processes can't get to
without explicit permission or override.

...
...
>   match only one MKT, determined by key-id.

If it matches multiple MKTs, the question is whether there is a
preferred one or not. I had thought there was, but if not then this text
can be used.

If it matches no MKTs, TCP-AO is not used.

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

If it matches zero MKTs and has TCP-AO option, then it must be dropped.

If it matches one or more MKTs and has no TCP-AO option, then it must be
dropped.

> rewriting the text to contain more or less just this.

As per above, the full set of cases needs to be discussed here. Granted
the text can be revised to avoid "preferred" keys as per above.

...
> Current_Key and Next_Key seem confusing here because we're punning

Agreed - should change that to "current_MKT" and "next_MKT".

> in that they match, I suppose...

Next_key is a value indicated by the user. It needs to be stored somewhere.

Connections need to either store the traffic keys or the info to
generate them. The latter would include the ISNs. I'll list the info
needed to generate them instead of storing the keys.

> AO's business whether those MACs were produced by a truncation process.

We need to describe the function as a call; the details are provided in
Gregory's doc. Since truncation is an argument to the call, I need to
indicate it.

Otherwise, we need two versions:
	
	1) the API between TCP-AO and Gregory's doc

	2) the API between Gregory's doc and the MAC alg.

Gregory's doc focuses on parameters; TCP-AO describes the algs and
interfaces, so I think it's important to include this here - even though
it's an opaque 'pass-through' value.

> general. Who says the PRF is truncated?

Again, I was describing a general alg from Gregory's doc. If that's
never an arg to a PRF, then we can omit it in TCP-AO.

...
> nonces, it's part of the protocol.
...

"It" here is TCP-AO, not the user. That should be revised to be more clear.

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

The timer is optional, and shifting keyIDs is required.

If we shift the order, we would need an intermediate value for
current_key, since we operate on current_key in (a). The order described
avoids that. I don't see why we'd reverse the order of these as a result.

> Even if so, this seems like kind of an unwarranted requirement.

Hard to say. RFC793 says all options must be implemented, and separates
that claim from the list of "currently specified" options. Whatever the
WG feels is appropriate here is fine.

IMO, it can't just be optional; it should be manditory at least in some
environments.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2009 07:39:05 -0700

At Mon, 27 Jul 2009 04:34:23 -0700,
> traffic keys, not that all four *are* always derived.

OK. So this may be editorial only.

> the right sentence to do so, maybe not.

Well, I think we could rewrite this as.

"This document obsoletes the TCP MD5 option. It replaces it with..."

> I'll correct to call this "indicating MAC fields of very short length"

AGreed. I'm just mentioning this so people don't think that you
can specify a shorter MAC in the option and have it validate.

> without explicit permission or override.

Sure. I'm just observing that this isn't true on some systems
which only have one level of securuty.

> preferred one or not. I had thought there was, but if not then this text

I had sort of assumed that this was an invariant--that the system
had to pick a preference if there were any.

> Next_key is a value indicated by the user. It needs to be stored somewhere.

Sure, but it could be a global setting.

> Gregory's doc. Since truncation is an argument to the call, I need to

Right, I don't think it should be an argument to the call--so it's
Greg's fault :)

> avoids that. I don't see why we'd reverse the order of these as a result.

OK.

I just think mndatory before optional.

> IMO, it can't just be optional; it should be manditory at least in some

I'm not going to go to the wall on this one. What do others
think?

-Ekr