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

At Sat, 15 Nov 2008 14:48:15 -0800,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 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:
> > 
> > OLD ISSUES
> > 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?

> > NEW TECHNICAL ISSUES
> > 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
changed.

> (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
output.

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

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm