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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
