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

[Greg Hudson <[e-mail]>]

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

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?

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

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

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.

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

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

(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.)