Re: [tcpm] Review of draft-tcp-mtcp-auth-opt-04

[Eric Rescorla <[e-mail]>]

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.
> 
> 
> S 3.
> You repeat the phrase "Each MAC algorithm MUST..." twice.
> 
> 
> 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)
>      
>      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)
> 
>      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.
> 
> 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.
> 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. 
> 
> IMO, this could be a lot clearer.
> 
> S 3.1.1.
> Is this an ASCII 0 (0x30) or a NUL (0x00)
> 
> 
> 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)
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>