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

[Benjamin Kaduk <[e-mail]>]

Thanks, Michael.

If the WG does want to treat the PRF octet-string input as a SP800-108
context and use a zero-byte separator, it seems like the "quick-and-dirty"
patch would be to just stick one in after "prf" and then there would be
another (somewhat superfluous) one appended after the octet-string by
KDF-HMAC-SHA2.  That might be easier than essentially inlining the
definitino of KDF-HMAC-SHA2 for just the PRF calculation.

-Ben

On Mon, 27 Jun 2016, Michael Jenkins wrote:

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