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

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 26 Jun 2016 23:03:54 -0400 (EDT)

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

---

From: Luke Howard <[email-masked]>
Date: Mon, 27 Jun 2016 19:17:49 +1000

> test vectors, to be clear.)

The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts the zero byte when invoking HMAC-SHA-256(), e.g.:

	PRF = KDF-HMAC-SHA2(base-key, "prf" | octet-string, 256)
	= k-truncate(HMAC-SHA-256(key, 0x00000001 | "prf" | octet-string | 0x00 | 256))

if I’m not mistaken? Pretty sure our implementation passed the test vectors.

— Luke

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Jun 2016 10:14:41 -0400 (EDT)

On Mon, 27 Jun 2016, Luke Howard wrote:

> The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts
> the zero byte when invoking HMAC-SHA-256(), e.g.:
>

I think that SP800-108 would have it be

[counter] | [label] | 0x00 | [context] | [output-length]

with the NUL between label and context, not between context and
output-length.

Its definitions are:

%%%%%%%%%%%

3) Label
 A string that identifies the purpose for the derived keying material,
which is encoded as a binary string. The encoding method for the Label is
defined in a larger context, for example, in the protocol that uses a KDF.

4) Context
 A binary string containing the information related to the derived keying
material. It may include identities of parties who are deriving and/or
using the derived keying material and, optionally, a nonce known by the
parties who derive the keys.

%%%%%%%%%%%

For the PRF, the octet-string input is pretty clearly something
specifically known to the parties who derive the keys, which seems like a
context.

For the use of KDF-HMAC-SHA2 elsewhere in the document, e.g. for deriving
Kc, Ke, and Ki, the line between label and context is less clear, since we
invoke it as (e.g.)

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128)

and the 0x99 is defined by the protocol and would plausibly still be part
of the label.

As I recall, the PRF was something of a late addition, and if the
KDF-HMAC-SHA2 construct was defined originally for password key derivation
and deriving Kc/Ke/Ki, that would explain why there was not thought about
having a proper SP800-108 context that would also need separation.
(SP800-108 has the context as optional ("One or more of these fixed input
data fields may be omitted unless required for certain purposes as
discussed in Section 7.5 and Section 7.6."), which is fine and would apply
for the non-PRF cases here.)

-Ben

---

From: Michael Jenkins <[email-masked]>
Date: Mon, 27 Jun 2016 10:53:54 -0400

Ben,

we'll get started on these.

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

---

From: Luke Howard <[email-masked]>
Date: Tue, 28 Jun 2016 07:27:46 +1000

Our implementation assumes that the context is always empty and only the label is used. But it’s trivial to change if you update the draft to use the context for the PRF.

— Luke

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Jun 2016 17:39:36 -0400 (EDT)

On Mon, 27 Jun 2016, Luke Howard wrote:

> Our implementation assumes that the context is always empty and only the
> label is used. But it’s trivial to change if you update the draft to use
> the context for the PRF.

Yeah, I don't expect much trouble for implementations if this does change.
A big reason I'm inclined to treat the PRF input as context and not label
is that in some scenarios it can be attacker-controlled, so having the
forced separation from the prf prefix could be useful.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Jun 2016 21:49:48 -0400 (EDT)

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

---

From: Luke Howard <[email-masked]>
Date: Tue, 28 Jun 2016 17:21:10 +1000

I reckon let's do it "properly" even if at the expense of redundant text.

Sent from my iPhone

> On 28 Jun 2016, at 11:49, Benjamin Kaduk <[email-masked]> wrote:
> 
> Thanks, Michael.
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 28 Jun 2016 07:58:23 -0400

+1