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

["Gregory M. Lebovitz" <[e-mail]>]

my comments inline...

At 10:34 AM 3/23/2009, Gregory M. Lebovitz wrote:
>To: Eric Rescorla <[e-mail]>, [e-mail]
>From: "Gregory M. Lebovitz" <[e-mail]>
>Subject: Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00
>Bcc: ƒ\IETF\tcpm
>In-Reply-To: <[e-mail]>
>References: 
><[e-mail]> 
><[e-mail]>
>
>Hey all,
>So far EKR's is the only review I've seen of 
>this draft. And many of you might have missed 
>it, for the wrong subject line he used. So I'm 
>resending my one and only precious review to the list w/ correct subject line.
>
>Gregory.
>
>At 05:32 PM 3/19/2009, Eric Rescorla wrote:
>>At Thu, 19 Mar 2009 17:31:06 -0700,
>>Doh. This review was of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00
>>
>>A review of auth-opt is forthcoming.
>>-Ekr
>>
>>
>>At Thu, 19 Mar 2009 17:31:06 -0700,
>>Eric Rescorla wrote:
>> >
>> > [Resent from an account that's subscribed.]
>> >
>> > -Ekr
>> >
>> > $Id: 
>> draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00-rev.txt,v 
>> 1.1 2009/03/19 22:37:19 ekr Exp $
>> >
>> > S 2.1.
>> > This whole {SHOULD,MUST}{+,-,*,?} thing is a bad idea. It's hard
>> > enough for developers to understand SHOULD vs. MUST, but now we have 5
>> > separate options for implementors to understand and us to argue
>> > over. I don't remember there being WG consensus on this point.
>> >
>> >
>> > S 2.2.
>> > The assignment of HMAC-SHA-1 to MUST- and AES-CMAC to SHOULD+ is
>> > basically unjustified. There's no good reason to believe that
>> > HMAC-SHA1 will be broken before AES-CMAC.  This is exactly the
>> > confusion fostered by the +/- regime.  Make HMAC-SHA1 MUST and
>> > AES-CMAC SHOULD.

For last two, I remember MSP's meeting different, 
that we discussed this "move away from" and "move 
toward" stuff there. However, I'm not stuck on it. Let's let WG decide today.


>> >
>> >
>> > S 3.1.
>> > It's confusing to talk about KDFs having an interface and then
>> > have the function named "PRF".
>> >
>> > I would rewrite this as:
>> >
>> >      All KDFs used in TCP-AO have the following interface:
>> >
>> >       Derived_Key = KDF(Master_Key, Context, Output_Length)

See the point and I'm fine with the change.

re:  "Context" vs "Input", I was using the lingo 
so as to align with [NIST-SP800-108]. So, unless 
someone has a really good reason why, I'll stick with "Input" in this case.


>> >
>> >      Where these values are defined as.... [blah blah]
>> >
>> > Then:
>> >      The KDFs defined in this document are all based on pseudorandom
>> >      functions (PRFs) which take a key and an input and emit a
>> >      fixed-length pseudorandom value.  Given PRF X, the associated
>> >      KDF, KDF_X, is constructed as follows:
>> >
>> >      KDF_X(Master_Key, Context, Output_Length) =
>> >          X(Master_Key, Input)

to be more clear about the use of the PRF could 
this be simplified to use the same descriptive 
text above, but then the formula is:
       KDF_X =
            PRF_X(Master_Key, Input)

Or am I missing something?

>> >
>> >      Where Input is constructed as:...
>> >
>> > Where you say that the master key isn't random, that's not quite
>> > right. The point is not that it doesn't contain high entropy.
>> > For instance HEX(X) where X is a 128-bit random number has high
>> > entropy but may or may not be suitable for use keying a MAC
>> > function.

Text currently says
"We assume that, in manual key mode, this is a 
human readable pre-shared key (PSK), thus we 
assume that it is of variable length, and we also 
assume it is in no way random."
The point is that someone might enter "dogfood" 
as Master_Key, so we are creating a mechanism 
that assumes it most likely is NOT 128-bit random with high entropy.

What would you prefer the text say?


>> >
>> > This section of the document is pretty confusing about the concept of
>> > output length. To recap:
>> >
>> > 1. The underlying PRFs have fixed sized output lengths, 128 bits in the
>> >    case of AES-CMAC, 160 bits in the case of HMAC-SHA1.
>> > 2. It is possible to generate an arbitrary number of output bits with
>> >    a given PRF by operating it in a feedback or counter mode.
>> >    The FIPS-whatever KDFs incorporate this feature, hence the
>> >    leading "0".
>> > 3. Each MAC needs a key of a specific length.
>> > 4. Not totally uncoincidentally, the KDFs we have chosen to use with
>> >    each MAC happen to generate the right key size for use with the
>> >    MAC, thus avoiding the need for the procedure in (2).
>> > 5. If you wanted to use these KDFs with a MAC requiring a longer key
>> >    (e.g., HMAC-SHA-256) you would, however need to use the procedure.

I'll put this stuff in to add clarification.

>> > 6. For some reason, the FIPS-whatever KDFs seem to think it's
>> >    a useful idea to mix the desired number of bits produced by the
>> >    KDF into the KDF input. I don't see the point of this, but
>> >    whatever.
>> >
>> > You'll note that the PRF does not need to be parametrized in terms
>> > of output length. It's fixed.

but you need it for #6 above, as it's part of the 
"FIPS-whatever" as you call it. So that's why 
it's there, because implementers will need it as 
a variable for runing the function. Can you live w/ that?

>> >
>> > IMO, this could be a lot clearer.
>> >
>> > S 3.1.1.
>> > Is this an ASCII 0 (0x30) or a NUL (0x00)

I'll look up the FIPS thing and call it out in 
the next rev, unless someone clarifies in the WG session.

>> >
>> >
>> > S 3.1.2.
>> > It's pretty unclear what problem you're trying to solve here. I would
>> > write:
>> >
>> > RFC 4615 is designed to take an arbitrary length key but for any
>> > key length other than 128 bits, whitens it by first computing an
>> > AES-CMAC with key 0. Because the keys in use with TCP-AO will
>> > likely be arbitrary-length ASCII strings, TCP AO always performs
>> > this whitening step even if the key happens to be 16 bytes long.
>> > In other words, using the terminology of RFC 4615:
>> >
>> >    K = AES-CMAC(0^128, MK, MKlen)

ok. I'm fine with that text.

>> >
>> >
>> > S 4.
>> > This UI labels section should be entirely removed. As far as I know,
>> > there was never WG consensus to include it and it just creates
>> > extra confusion. In AO, the MAC completely defines the KDF, so
>> > the concept of suites just adds an extra name. Moreover, since
>> > MACs have obvious names and the suites have opaque, confusing names,
>> > this is doubly bad.

I'm fine with that. We'll make the final call at WG today.

Thx EKR,
Gregory.

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>_______________________________________________
>>tcpm mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/tcpm