Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01

[Eric Rescorla <[e-mail]>]

At Mon, 27 Jul 2009 01:24:21 -0700,
Gregory M. Lebovitz wrote:
> 
> inline...
> 
> At 04:46 PM 7/26/2009, Eric Rescorla wrote:
> >$Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 
> >2009/07/26 22:40:47 ekr Exp $
> >
> >TECHNICAL
> >S 3.1.
> >This mixing of the KDF interface and the NIST 800-108 interface
> >is extraordinarily confusing.
> 
> I'm not sure it's "mixing". Isn't one is a subset of the other? The 
> KDF interface is an interface. The NIST thing is the actual 
> concatenated construct which fulfills the Context.

Well, as usual, the interface is abstract and the NIST thing is
a concrete implementation.


> >To recap:
> >The input to the KDF requires:
> >
> >- Master Key
> >- Context (i.e., the conn-data)
> 
> it's not just the Data_Block (updated lingo, per auth-opt-05). In 
> order to follow SP800-180, the context is a few things concatenated, 
> and Data_Block is one of the things.

Yes, that's what it is now and my point is that that's wrong.




> >- Output length
> >
> >Now, as it happens, you're constructing your KDFs a la SP800-108,
> >so you then use the relevant PRF with an input block constructed
> >as:
> >
> >            ( i || Label || Context || Output_Length)
> >
> >But that is not a meaningful part of the interface to the KDF
> >as far as AO is concerned. If you were (for instance) to define
> >a new TLS PRF based KDF, you would not use i internally because
> >the TLS PRF generates an arbitrary length string. Again, it's
> >important to distinguish between the TCP-AO requirements and
> >what this document happens to do.
> 
> I think this document is NOT just the generic interface - that's 
> covered in auth-opt-05. This document reminds us of the generic 
> interface, and then specifically defines how to do the SHA1 and 
> AES-128 KDFs themselves. That's why we made it specific. Maybe I'm 
> not understanding you?

Apparently not. My point is that you shouldn't be exporting
the SP800-108 stuff into the TCP-AO document, and the way you
have defined the generic interface does that.


> >S 3.1.3.
> >Wait, I don't remember agreeing to this. I'm happy to use these
> >as labels in soem IANA registry, byt people's UI is not our
> >business.
> 
> This is the years of IKE interop work which motivates this. 

Well, years of TLS interop suggest the exact contrary.
We're not in the business of mandating UI.


> Clarifying the UI representations to make it very easy on operators 
> is a good thing. Others opinions on this UI guidance?



> >S 2.3.
> >        (1)  Key Derivation Functions (KDFs) which name a pseudorandom
> >             function (PRF) and use a Master_Key and some connection-
> >             specific Input with that PRF to produce Conn_Keys, the keys
> >             suitable for authenticating and integrity checking
> >             individual TCP segments.
> >
> >This is confusing. KDFs may or may not be constructed with PRFs.
> >However, THESE KDFs are so constructed. If you're giong to have
> >a document which applies to future KDFs, don't say PRF here.
> 
> it does say "which name", not "MUST name". Doesn't this cover your point?

Not really, no. I think you need to separate the abstract requirements
from the concrete instantiations.


-Ekr