[kitten] shepherd review of draft-aes-cts-hmac-sha2-09

[Benjamin Kaduk <[e-mail]>]

Hi Michael et al,

As I was preparing the shepherd writeup for this document, I noticed some
things that do not block the progression of the document but do require
changes, and one item that may require further WG input.  Can you prepare
a new version with the changes mentioned below?

The one item which would potentially affect the actual protocol: at the
end of Section 5, the pseudo-random function seems to be using a SP800-108
KDF but omits the zero byte between label and context.  I think it would
be better to have the zero byte -- do you remember whether there was a
reason to omit it?  (Adding the zero byte would require re-rolling some
test vectors, to be clear.)

Additionally, all document authors will need to confirm compliance with
BCPs 78 and 79 for this document, namely that there are no intellectual
property concerns with the document that are not already disclosed.

Please add a normative reference to RFC 2104 for HMAC, first mentioned at
the end of Section 1.

In Section 3, it might aid clarity to mention that the 0x00000001 input to
HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
first block of output, even though it is the only block of output as
well].

In Section 4, it might be worth re-mentioning "where PBKDF2 is the
function of that name from RFC 2898" after the algorithm block, since most
everything else used there also gets clarified.  (It is already cited at
the beginning of the section, in the overview paragraph.)

The document should be consistent about using "cipher state" as one word
or two (RFC 3961 prefers the two-word form).  It also makes a rather
sudden appearance at the beginning of Section 5 with no explanatory
introduction; it might help the reader to instead start with "The RFC 3961
cipher state that maintains cryptographic state across different
encryption operations using the same key is used as the formal
initialization vector [...]" On the next page, "cipherstate" is defined as
"a 128-bit initialization vector derived from the ciphertext", which is
potentially misleading, since it can't be both used as the IV for and
derived from the same ciphertext!  Probably it's better to say "derived
from a previous (if any) ciphertext using the same encryption key, as
specified below".

Still in Section 5, in the definition of the encryption function (well,
computing the cipherstate, really), I'm of two minds whether it's worth
mentioning that the case of L < 128 is impossible because of the 128-bit
confounder.

In the decryption function, can you add a note to the right of "(C, H) =
ciphertext" that "[H is the last h bits of the ciphertext]"?

In the pseudo-random function, please replace "base-key" with "input-key",
since the key input to the PRF is not expected to be a kerberos protocol
long-term base key.

In Section 6, the "associated cryptosystem"s are supposed to be
"AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
in the document.  While the meaning is pretty clear, it's probably better
to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
appropriate".  This does duplicate the preceding text, but we do want to
explicitly list the "associated encryption algorithm" as listed in the
Checksum Algorithm Profile of Section 4 of RFC 3961.

In Section 8.1, the acronym "TGT" is used, the only instance in the
document.  It's also potentially misleading, since ticket-granting tickets
are generally objects that are issued to client principals by the AS.
I'd go with "Cross-realm krbtgt keys" instead.

The test vectors for key derivation have a parenthetical "constant =
0x...", but the term "constant" does not appear elsewhere in the document.
The hex values are the label input for the HMAC, so we should call them
that.


Thanks,

Ben