Subject: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02

From: Shawn M Emery <[email-masked]>
Date: Sun, 18 May 2014 23:05:55 -0600

This message officially starts the kitten Working Group Last Call for the following document:

AES Encryption with HMAC-SHA2 for Kerberos 5
http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02

The Working Group Last Call for this document starts today on Sunday, May 18th and will end on Sunday, June 1st.

Please send any comments to the kitten mailing list or directly to the chairs.  Even if you reviewed this document
and found no issues then please provide this feed-back.  We would especially like to hear from reviewers that have
provided comments that were instrumental in nudging this to CTS mode with a confounder.

Thank you,

Shawn Emery
kitten co-chair
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 May 2014 17:15:44 -0400 (EDT)

> 18th and will end on Sunday, June 1st.

This looks pretty much okay.

A few minor things:

The specification of en/decryption in section 5 assigns the new 
cipherstate as "next-to-last 128-bit block of C"; this is slightly 
ambiguous when C does not end on a block boundary.  I believe the intent 
is that the last full block will be used in this case, but one could read 
the current text as saying that the next-to-last full block would be used.
Also, the description of D() says it is an AES encryption function, not a 
decryption function.

There are no test vectors for the PRF.  Having such vectors would also 
make it clear what the output length of the PRF is (luckily, we are not 
using the simplified profile, with its ambiguous language "truncate tmp1 
to multiple of m").  (The PRF output length looks to be 256 and 384 bits 
for the two variants, to me.)

In section 8.1, "at least 128 bits of random" feels ungrammatical.  Also 
in that section, the third and fourth bullet points may be specific to the 
MIT krb5 implementation; it might be worth tweaking the wording to reflect 
that this is only known to affect some implementations, or something like 
that.

I did not attempt to verify the test vectors.

-Ben

---

From: "Peck, Michael A" <[email-masked]>
Date: Fri, 23 May 2014 01:23:24 +0000

Ben,

Thanks for the comments, I'll fix those.

Could you help me understand or give an example of what the pseudo-random
function defined in the protocol parameters is used for?  I'm not quite
following the RFC 3961 section 3 definition.

We already separately define how a base-key is derived from a passphrase
(in cases where a passphrase is used), and how the Kc, Ke, and Ki keys are
derived from the base-key. What are the additional use cases for a generic
PRF?

Right now our pseudo-random function definition refers to KDF-HMAC-SHA2,
which we define in section 3 but in the context of deriving the base-key,
Kc, Ke, or Ki key (so that we get the right output length) rather than
arbitrary keys, so we may need to clean up that language a bit.  Then
you're right that it just says "HMAC" which would mean an output of 256 or
384 bits, which probably isn't right (RFC 3961 says the "pseudo-random
function should generate an octet string of some size" - but how do we
know what size is needed?).  Also, calling HMAC a second time rather than
just passing the octet-string (and perhaps a desired output length?) into
KDF-HMAC-SHA2 may be redundant.

Thanks,
Mike

On 5/22/14, 5:15 PM, "Benjamin Kaduk" <[email-masked]> wrote:

>> This message officially starts the kitten Working Group Last Call for
>>the 
>> following document:
>>
>> The Working Group Last Call for this document starts today on Sunday,
>>May 
>> 18th and will end on Sunday, June 1st.
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 May 2014 22:18:06 -0400 (EDT)

> Thanks for the comments, I'll fix those.

Thanks.

> following the RFC 3961 section 3 definition.

Sure.  Probably the easiest example to refer to that comes to mind is in 
the implementation of gss_pseudo_random() for the krb5 mech, RFC 4402.

The summary is that an RFC 3961 enctype is supposed to provide a 
deterministic way to turn a protocol key and some input string into 
pseudo-random bits, which are unpredictable to anyone who does not know 
the protocol key.  The output from this function is a fixed length per 
enctype, so consumers frequently end up defining a PRF+ function to get 
arbitrary-length output.

> derived from the base-key. What are the additional use cases for a generic

RFC 3961 sort of hints at this with the phrase "suitable for use in key 
generation".  I don't think I know of any uses of the prf other than for 
key generation.  This would basically always be key generation for some 
key to be used outside of kerberos, bootstrapping from (say) a kerberos 
session key and some other shared state between two parties.

gss_pseudo_random() is used in draft-wilkinson-afs3-rxgk; in implementing 
that protocol we actually discovered a couple of interoperability issues 
between Heimdal and MIT kerberos, partially because the prf functionality 
was not very well specified originally (which in turn is possibly because 
the original authors did not really have a concrete use in mind).

> KDF-HMAC-SHA2 may be redundant.

That's a good point; it's not specified what the length of Kp is for the 
aes256-cts-hmac-sha384-192 variant.  It would seem that section 3 should 
cover the Kp case as well as Kc, Ke, Ki, and the base key.  (I just 
assumed that it was 192, when I was reading it.)

The introduction does say "the HMAC algorithm uses the SHA-256 or SHA-384 
hash algorithm", so I think that the bare usage of "HMAC" at the end of 
section 5 is reasonably well specified; it's only which variant of 
KDF-HMAC-SHA2 should be used that is particularly unclear.  We could 
"cheat" by changing the "prf" input to KDF-HMAC-SHA2 to instead be "prfU", 
since ASCII 'U' is 0x55 (and the 'ends in 0x55' case is already covered 
for Ki), but it's probably better to explicitly specify which form to use.
I don't think there's a need to specify a fully general KDF-HMAC-SHA2, 
since that's just an internal tool used in defining other quantities, and 
it is those output quantities which are actually parameters of the RFC 
3961 enctype.

There is some strong convention that the pseudo_random() output be a 
multiple of the message block size of the underlying cipher, but from 
memory I do not think that RFC 3961 imposes that as a hard constraint. 
There is not really any other restriction or condition on what size output 
it should produce; consumers are already using PRF+ constructs because of 
existing enctypes, so we just need to pick a length. (In any case, whether 
HMAC is SHA-256 or SHA-384, it is still a multiple of the 128-bit block 
size for AES, so "multiple of the block size" is a non-issue.)

I think that calling HMAC a second time is preferable to just passing the 
octet-string into KDF-HMAC-SHA2; it seems to be more in keeping with the 
other applications of KDF-HMAC-SHA2 in the specification.

I will note again for clarity that the output length of pseudo_random() is 
a protocol constant; the idea of a "desired output length" is not 
relevant, since the output length must always for any key of a given 
enctype.

Hope that helps.

-Ben

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 May 2014 10:42:17 +0200

> http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02

I know this is a late generic comment, and I have vague memories that
this was already discussed.  But why are we standardizing separate
encrypt and MAC when everyone else is moving towards AEAD-based modes?
I don't see any discussion of this in the draft.  There are AEAD modes
with nicer properties wrt IV reuse, like SIV.  It seems unforunate that
Kerberos lingers behind when several other protocols have already
specified AEAD modes.

I don't see any conflict between moving this draft forward, and working
on AEAD modes in parallel, so no objection from me.

/Simon

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 May 2014 11:08:00 -0400 (EDT)

> Kerberos lingers behind when several other protocols have already

AEAD had been mentioned in previous discussions, in particular in the 
guise of GCM.  GCM is not appropriate for an RFC 3961 enctype because of 
the disasterous consequences of counter rollover: RFC 3961 keys are 
potentially used for a very long time, and there did not seem to be a 
reasonable way to prevent rollover or signal errors in that case.

See, e.g., 
http://www.ietf.org/mail-archive/web/kitten/current/msg04277.html and 
surroundings.

I don't know that non-GCM AEAD solutions had been explicitly considered 
for use with kerberos; I think we would be happy if you did so.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Fri, 23 May 2014 11:26:17 -0400

> encrypt and MAC when everyone else is moving towards AEAD-based modes?

We have spent a lot of time considering CCM and GCM.  In the end, the
uncoordinated nature of Kerberos key usage on long-term keys makes it
too hard to pick nonces within the 128-bit space of an AES block with
sufficient confidence that they won't be reused.

Channel protocols such as TLS can assume state on either end of a
connection, making it much easier to select nonces.  A Kerberos enctype
could be specified which is intended only to be used with short-lived
keys via RFC 4537 enctype negotiation, but there would have to be a
significant practical advantage to justify that extra complexity.

> with nicer properties wrt IV reuse, like SIV.

We have not considered SIV as no one has brought it up before (and in
fact, I hadn't heard about it until now).  Since a goal of this enctype
is to hew as closely as possible to NIST-certified cryptography
practices, I don't know that SIV would be an attractive option, but I
will definitely read up on it.