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

[Eric Rescorla <ekr at networkresonance.com>]

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