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

Eric Rescorla <> Sun, 16 November 2008 20:33 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B8A543A699C; Sun, 16 Nov 2008 12:33:26 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE02F3A699C for <>; Sun, 16 Nov 2008 12:33:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xnA4EIrNoMn8 for <>; Sun, 16 Nov 2008 12:33:24 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 4779C3A67AA for <>; Sun, 16 Nov 2008 12:33:24 -0800 (PST)
Received: from kilo-2.local (localhost []) by (Postfix) with ESMTP id 79E27757B07; Sat, 15 Nov 2008 17:31:46 -0600 (CST)
Date: Sat, 15 Nov 2008 17:31:46 -0600
From: Eric Rescorla <>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <>
References: <> <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <>
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

At Sat, 15 Nov 2008 14:48:15 -0800,
Joe Touch wrote:
> Hash: SHA1
> Hi, Eric,
> Some clarifying questions below. I think most of these are easy to fix...
> Joe
> Eric Rescorla wrote:
> > $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev.txt,v 1.1 2008/11/15 20:50:05 ekr Exp $
> > 
> > Overall, this document is substantially improved. However, 
> > a number of the issues I raised in previous reviews remain:
> > 
> > In particular, I wrote:
> > 
> >     I don't think this API, specification of the TSAD, etc., is
> >     particularly helpful. IPsec needed the concept of an association
> >     database because packets corresponding to multiple associations
> >     got similar treatment. However, TCP has an explicit notion
> >     of connection so it would be far more convenient to simply
> >     refer to keys as tied to connections, and then have a set
> >     of rules for mapping which connections get which keys.
> >     
> >     Even if some TSAD-type abstraction is useful, I don't think
> >     it's appropriate to define things like the size of each
> >     parameter in the TSAD as opposed to on the wire, or to
> >     describe the default values of various parameters as in
> >     S 3. For instance:
> >     
> >              iii. Key length. A byte indicating the length of the 
> >                    connection key in bytes.  
> >     
> >     Those are internal implementation issues. Certainly, I might
> >     want to use a native int in my implementation. Why should
> >     this document tell me otherwise?
> > 
> > In response to my previous review, Joe indicated that:
> > 
> >     The TSAD API needs to be specified in detail because the key management 
> >     solution needs to rely on that information.
> > 
> > I don't agree that it's necessary to define *any* API. What's
> > necessary is to define clear boundaries between the packet processing
> > system and the key management system (if any). I don't see that it's
> > necessary to be specified at the level of "this parameter is a byte".
> > If you want enough specificity that uncooperating implementors could
> > independently develop these components and have them work together out
> > of the box, then you need to explicitly define much more material,
> > i.e., argument order, struct packing, error formats, calling sequences
> > etc. In other words, you should either be defining language bindings
> > or a formal language like IDL. Absent that, I don't agree that 
> > defining the length of the fields containing these parameters is of
> > any value. It's particularly odd to focus on the length of the
> > parameters and not specify (for instance) the signedness or the
> > bit order.
> These would be good reasons to include the signedness (all are unsigned)
> and byte order (network standard). I don't see a reason to indicate bit
> order.

I want to remove the entire feature, not finish it. I only mention the
fact that it's insufficient in passing.

> > WRT to S 3 (now in S 6) I wrote:
> > 
> >                >> At least one direction (inbound/outbound) SHOULD have 
> >                a non-"NONE" MAC in practice, but this MUST NOT be 
> >                strictly required by an implementation.  
> > 
> >      1. This seems like a bad idea. It's very hard to analyze the security
> >      properties of a connection when only one side is protected. To take
> >      one case that is obviously bad, if you're worried about DoS attacks
> >      and you use TCP-AO, then forging packets in either direction can
> >      bring it down. I would reverse this and require MACs in both directions.
> >      
> >      2. Even if we stipulate that this might be an OK idea, it's not
> >      appropriate to require implementations to support it.
> > 
> > No good reason has ever been offered for this feature. Given the above
> > reasoning, I propose it be removed.
> We covered this in detail in an extended discussion in Philadelphia; it
> is needed to support channel binding. We can't turn on TCP AO after a
> connection has started (because TCP has no option handshake after
> connection establishment), but we can go from using a null algorithm to
> using a real one.

Well, I wasn't in Philadelphia, but I don't find this to be enough information
to convince me--I can certainly think of ways to make channel binding
work that don't require asymmetric protection.

Perhaps you can point me to something someone has written that describes
the issue?

> > Overall
> > I'm wondering if we should specify heuristics or algorithms for
> > key changeover. Here's what I mean: Alice and Bob are currently
> > using Key 1 and they want to change over to Key 2. At time 
> > T0, Alice installs Key 2, but she can't start transmitting with
> > it until she knows that Bob has installed it. At time T1,
> > Bob installs Key 2. Now, if he knows that Alice installed first,
> > he can start using it, but if he does and Alice hasn't, then
> > packets start getting dropped. Finally, once Bob has installed
> > Key 2, he needs to tell Alice that he has installed Key 2
> > so he can switch over. This is a lot of manual coordination.
> Agreed; IMO, this is the responsibility of the key management system,
> not TCP-AO.

The key management system is two people at either end of a cell
phone. I'm trying to make their lives easier.

> > Lebovitz and I spent some time the other day trying to make this
> > problem easier and here's what we came up with. 
> > 
> > 1. As soon as a node receives a segment protected with Key X
> >    (and verifies it, of course) it can conclude that the peer
> >    knows Key X and start using Key X to transmit with.
> We do not require symmetric key changeover. Side A can use key X while
> side B uses key Y; there is no requirement that the senders use the same
> index.

Nor did I say otherwise. I'm saying that receiving index X from
the peer is permission to respond with it. It doesn't require you
to do so.

> > 2. Once a peer has had a new key installed, it should periodically
> >    send a segment protected with that key. Note that the interval
> >    here should be low enough that if the verification fails it
> >    doesn't cause TCP to back off really far. But other than that,
> >    it doesn't matter how it's set. [Maybe there's some TCP wizardry
> >    here to decrease the effect, like you only treat ACKs this way
> >    or something...]
> This sounds like a protocol on top of TCP; we're trying to avoid that.
> TCP segments have other meanings, and sending such segments just for a
> key management reason would impact other TCP properties we're trying to
> leave alone.

I'm sorry if I gave the impression you would send extra segments.
That's not what I meant. I merely meant that every so often instead
of using key X, you use key Y as a probe instead. 

> > I'm assuming there's some concept of ordering or priority where key
> > X is assumed to be better (newer) than Y. That seems easy to have.
> > 
> > Anyway, the point of this algorithm is that Alice and Bob can 
> > independently configure new keys and then the system will automatically
> > detect when they both have them configured and start using them
> > without any explicit coordination over when the keys are installed.
> The common algorithm is:
> a) install key at receiver
> b) install key at sender
> Since our keys are directional,

The traffic keys are directional. It wasn't my impression from the document
that the master keys were directional. If so, I think that should be

> (b) is taken as implicit permission to
> use that key. I don't see a reason for further key coordination.

Well, as it is you effectively need a two phase commit protocol.
I'm trying to remove that.

> > S 4.
> > I found this ESN management algorithm extremely hard to follow.
> > For starters, no initial values are provided for {SND,RCV}.PREV_SEQ,
> > which makes it hard to see even where to start. 
> We can initialize those as ISN-1.
> > Aside from that, let's look at the first line:
> > 
> >          ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); 
> > 
> > Why is 0xffff magic?
> Sorry - that's a bug. It had been 0x7fff; I had changed it incorrectly
> in this version. I need to debug that code...

Now I'm even more puzzled. Why should it be 0x7fff?

> > 2. What you want to generate a key is a pseudorandom function (PRF)
> >    Not all MACs are PRFs. This is easy to forget because HMAC is
> >    both. However, this is not always the case.
> Understood; the question is whether we should be specifying separate
> PRFs, or a PRF that can be based on a MAC. I'd prefer the latter, to
> allow the PRF to track the addition of new MAC algorithms.
> Is there a way to do this?

Well, clearly one can do what TLS does and require each algorithm
to specify a PRF. I'm not sure if there is a general transformation
from MACs to PRFs. My intuition is no, however, because you somehow
need to extract the random versus non-random components of the MAC

> >       Additional reductions in MAC validation can be supported by using a 
> >       MAC algorithm that partitions the MAC field into fixed and computed 
> >       portions, where the fixed value is validated before investing in the 
> >       computed portion. This optimization would be contained in the MAC 
> >       algorithm specification. Note that the KeyID cannot be used for 
> >       connection validation per se, because it is not assumed random. 
> > 
> > 
> > The use of the term "connection key" and "connection block" are
> > confusing here because the keys are different in each direction, so
> > there is no single conn key. I suggest using the term "traffic
> > key".
> We don't use those terms in the above paragraph. We might use connection
> receive key and connection transmit key, but I don't think 'traffic' key
> is appropriate in a TCP document.

Well, traffic key is the standard comsec terminology. However, I'm fine
with connection receive key and conneciton transmit ke.

tcpm mailing list