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

[Michael Jenkins <[e-mail]>]

Ben,

we'll get started on these.

On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[e-mail]> wrote:

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



-- 
Mike Jenkins
[e-mail] - if you want me to read it only at my desk
[e-mail] - to read everywhere
443-634-3951