Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

[Benjamin Kaduk <[e-mail]>]

On Thu, 2 Apr 2015, Greg Hudson wrote:

> On 03/30/2015 12:40 PM, Benjamin Kaduk wrote:
> > This message begins the Working Group Last Call (WGLC) of "AES Encryption
> > with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
> > The WGLC will last two weeks, ending on Monday, April 13th.
>
> I put together a simple implementation of this draft in Python, and
> verified some of the test vectors (but not all; see below).

Thank you!

> There are several aspects of the enctype design whose motivations are
> unclear to me.  They affect performance but not security.  They are:
>
> * For the 192-bit security level, why use SHA-384 and truncate to 192
> bits?  Why not use SHA-256 and truncate to 192 bits?

I did not go on a full trawl through the archives, but
http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies
that NIST is generating a document covering "what you get from what you
used" indicating that SHA-256 only gives you 128 bits, under some set of
assumptions.

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

I don't think there is logic supporting this choice in the list archives;
if I remember correctly, Kp was added rather late in the document's
history, and the decision to have an explicit intermediate Kp instead of
just making the PRF use the base key direction (in some form) was made
pretty arbitrarily ("it feels better to keep the behavior parallel across
enctypes" or thereabouts).

Leaving k as 256 allows the PRF = k-truncate(HMAC-SHA2(Kp, octet-string))
to produce a pseudo-random function output which is a multiple of the
random-to-key input size (and the underlying cipher block size), which is
a nice feature to retain.  I don't know of a reason why we could not
retain 256-truncate using a 192-bit Kp, though.

> * Why use 128/256-bit PRF output lengths?  Why not just output the full
> hash?  It can't be for consistency with RFC 3962, as
> aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
> out of some desire to consistently truncate SHA-2 results in half, or we
> would have 128/192-bit output lengths.

I think there is some desire to always truncate SHA-2 results in half,
though, for the reasons mentioned above.  But a 192-bit output would not
be a multiple of the blocksize or random-to-key input size, so in that
sense (random-to-key input), 256 bits makes more sense.  This is probably
"okay" in the sense of wanting to always cut SHA-2 outputs in half,
because the aes256-...-192 enctype only claims to provide 192 bits of
security.

> I have one concern about formal correctness:
>
> * Following the lead of the simplified profile, the formulation of the
> key derivation function in section 3 ends by calling random-to-key() as
> if the result had the same abstract type as a protocol key.  But for the
> AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the
> same abstract type as a 256-bit protocol key.  The formalism is also

So random-to-key() only applies for generating base keys, and the
derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Or is the argument rather that since we are not using the simplified
profile, we just don't need random-to-key() at all because we are defining
things manually and can make use of the fact that it is the identity
function for these enctypes?

> sloppy because it depends on context; instead of taking a length
> parameter, it uses an implicit length based on what operation the
> invoker is performing.  In a similar vein, section 3 talks about what
> the input constant is for each derivation use; this is not the case for
> RFC 3961 or RFC 6803 and seems out of place.

So you want to rely just on the (type of the) key being derived and not
mention the last octet of the constant?  I think that would be a valid way
to specify things, but want to confirm the nature of your comment.

> I have several concerns about the presentation of the test vectors:
>
> * The PRF test vectors do not list a base key; instead it lists a Kp
> value.  This requires tests to exercise only a component of the PRF
> implementation, which may be inconvenient.  The base keys are present in
> the key derivation test vectors, but this is not immediately clear.

We could add text so the PRF test vectors say "Kp value (repeated from
above):"; would that help?

> * The encryption test vectors do not list base keys and key usages;
> instead they only list "AES key" and "HMAC key" values which are
> presumably Kc and Ki.  For the first 128-bit test vector, the base key
> and usage is recoverable from the key derivation test vectors, but that
> does not appear to be the case for any of the other encryption test
> vectors.  Because of this, I only verified the first encryption test vector.

Hmm.  I don't really want to propose removing test vectors to replace them
with new ones, but could we add some additional test vectors which do
possess the desired properties?  (I.e., that the Kc and Ki are listed in a
previous test vector from base key and usage, or that they are test
vectors starting from base key.)

> * The checksum test vectors do not list a base key or key usage.  The
> base keys and usages are present in the key derivation test vectors, but
> this is not immediately clear.

Similarly to the PRF, does "HMAC key (repeated from above):" help enough?

> (It looks like RFC 6803 is missing key usages for encryption test
> vectors, which may have contributed to some of the above issues.  I will
> submit an erratum.)

Thanks.


My own review notes that section 8.2 contains an extra space in "The
encryption".  It additionally claims that this document is proposing "the
use of [...] AES-256 with a 192-bit key", but this is confusing since
AES-256 definitionally requires a 256-bit encryption key, and the base key
is also a 256-bit key.  Perhaps "AES-256 with some derived keys of length
192 bits" is better, albeit clunky.


-Ben