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

From: Greg Hudson <[email-masked]>
Date: Thu, 02 Apr 2015 12:20:05 -0400

On 03/30/2015 12:40 PM, Benjamin Kaduk wrote:
> This message begins the Working Group Last Call (WGLC) of "AES Encryption
> with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
> The WGLC will last two weeks, ending on Monday, April 13th.

I put together a simple implementation of this draft in Python, and
verified some of the test vectors (but not all; see below).

There are several aspects of the enctype design whose motivations are
unclear to me.  They affect performance but not security.  They are:

* For the 192-bit security level, why use SHA-384 and truncate to 192
bits?  Why not use SHA-256 and truncate to 192 bits?

* Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

* Why use 128/256-bit PRF output lengths?  Why not just output the full
hash?  It can't be for consistency with RFC 3962, as
aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
out of some desire to consistently truncate SHA-2 results in half, or we
would have 128/192-bit output lengths.

I have one concern about formal correctness:

* Following the lead of the simplified profile, the formulation of the
key derivation function in section 3 ends by calling random-to-key() as
if the result had the same abstract type as a protocol key.  But for the
AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the
same abstract type as a 256-bit protocol key.  The formalism is also
sloppy because it depends on context; instead of taking a length
parameter, it uses an implicit length based on what operation the
invoker is performing.  In a similar vein, section 3 talks about what
the input constant is for each derivation use; this is not the case for
RFC 3961 or RFC 6803 and seems out of place.

I have several concerns about the presentation of the test vectors:

* The PRF test vectors do not list a base key; instead it lists a Kp
value.  This requires tests to exercise only a component of the PRF
implementation, which may be inconvenient.  The base keys are present in
the key derivation test vectors, but this is not immediately clear.

* The encryption test vectors do not list base keys and key usages;
instead they only list "AES key" and "HMAC key" values which are
presumably Kc and Ki.  For the first 128-bit test vector, the base key
and usage is recoverable from the key derivation test vectors, but that
does not appear to be the case for any of the other encryption test
vectors.  Because of this, I only verified the first encryption test vector.

* The checksum test vectors do not list a base key or key usage.  The
base keys and usages are present in the key derivation test vectors, but
this is not immediately clear.

(It looks like RFC 6803 is missing key usages for encryption test
vectors, which may have contributed to some of the above issues.  I will
submit an erratum.)

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Apr 2015 16:03:40 -0400 (EDT)

Sorry for the slighty-late reminder; there is less than a week remaining
in this WGLC period.

-Ben

On Mon, 30 Mar 2015, Benjamin Kaduk wrote:

> The WGLC will last two weeks, ending on Monday, April 13th.  The draft is
> available at:
>
> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06
>
> Please review the document and send comments to the Working Group mailing
> list <[email-masked]> or the co-chairs <[email-masked]>
> before the end of the WGLC.  Any and all comments on the document are
> sought in order to access the strength of consensus.  Even if you have
> read and commented on this or earlier versions of the draft, please feel
> free to comment again.  This is particularly important if you found issues
> with the previous version.
>
> As a reminder, comments can be anything from "this looks fine" to "this is
> a horrible idea"; they can include suggestions for minor editorial
> corrections to significant editorial changes.
>
>
> - Your Kitten Chairs
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Apr 2015 17:26:41 -0400 (EDT)

> verified some of the test vectors (but not all; see below).

Thank you!

> bits?  Why not use SHA-256 and truncate to 192 bits?

I did not go on a full trawl through the archives, but
http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies
that NIST is generating a document covering "what you get from what you
used" indicating that SHA-256 only gives you 128 bits, under some set of
assumptions.

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

I don't think there is logic supporting this choice in the list archives;
if I remember correctly, Kp was added rather late in the document's
history, and the decision to have an explicit intermediate Kp instead of
just making the PRF use the base key direction (in some form) was made
pretty arbitrarily ("it feels better to keep the behavior parallel across
enctypes" or thereabouts).

Leaving k as 256 allows the PRF = k-truncate(HMAC-SHA2(Kp, octet-string))
to produce a pseudo-random function output which is a multiple of the
random-to-key input size (and the underlying cipher block size), which is
a nice feature to retain.  I don't know of a reason why we could not
retain 256-truncate using a 192-bit Kp, though.

> would have 128/192-bit output lengths.

I think there is some desire to always truncate SHA-2 results in half,
though, for the reasons mentioned above.  But a 192-bit output would not
be a multiple of the blocksize or random-to-key input size, so in that
sense (random-to-key input), 256 bits makes more sense.  This is probably
"okay" in the sense of wanting to always cut SHA-2 outputs in half,
because the aes256-...-192 enctype only claims to provide 192 bits of
security.

> same abstract type as a 256-bit protocol key.  The formalism is also

So random-to-key() only applies for generating base keys, and the
derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Or is the argument rather that since we are not using the simplified
profile, we just don't need random-to-key() at all because we are defining
things manually and can make use of the fact that it is the identity
function for these enctypes?

> RFC 3961 or RFC 6803 and seems out of place.

So you want to rely just on the (type of the) key being derived and not
mention the last octet of the constant?  I think that would be a valid way
to specify things, but want to confirm the nature of your comment.

> the key derivation test vectors, but this is not immediately clear.

We could add text so the PRF test vectors say "Kp value (repeated from
above):"; would that help?

> vectors.  Because of this, I only verified the first encryption test vector.

Hmm.  I don't really want to propose removing test vectors to replace them
with new ones, but could we add some additional test vectors which do
possess the desired properties?  (I.e., that the Kc and Ki are listed in a
previous test vector from base key and usage, or that they are test
vectors starting from base key.)

> this is not immediately clear.

Similarly to the PRF, does "HMAC key (repeated from above):" help enough?

> vectors, which may have contributed to some of the above issues.  I will

Thanks.

My own review notes that section 8.2 contains an extra space in "The
encryption".  It additionally claims that this document is proposing "the
use of [...] AES-256 with a 192-bit key", but this is confusing since
AES-256 definitionally requires a 256-bit encryption key, and the base key
is also a 256-bit key.  Perhaps "AES-256 with some derived keys of length
192 bits" is better, albeit clunky.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Wed, 08 Apr 2015 18:48:36 -0400

> used" indicating that SHA-256 only gives you 128 bits, under some set of

I do not understand what assumptions would yield a security level of 128
bits from SHA-256 truncated to 192 bits, and a security level of 192
bits from SHA-384 truncated to 192 bits.  If there is a concern about
birthday attacks on the integrity tag, then we can't get away with
truncating at all; we would need to send a 256-bit tag for the 128-bit
security level, and a 384-bit tag for the 192-bit security level.

I wonder if NIST finished its document in the interim.

>> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This was probably a dumb question, and really devolves into "why use a
256-bit PRF output length?"  For the 192-bit security level, Ki and Kc
are used to generate a 192-bit tag, but Kp is used to generate a 256-bit
PRF.

[Regarding truncation of the PRF output:]
> though, for the reasons mentioned above.

I would like to better understand these reasons.

> derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Yes.  RFC 3961 defines random-to-key() as producing a protocol key.  It
is probably a conceptual error that RFC 3961 section 5.1 uses
random-to-key() as the last step of its key derivation function.  That
error would be especially confusing in the new context, where derived
HMAC keys can have different lengths than protocol keys.

> function for these enctypes?

No, we need a random-to-key(); it is part the RFC 3961 definition of an
encryption algorithm profile.  By contrast, key derivation is not part
of this definition; it's just an internal feature of every
non-single-DES encryption type so far.

> to specify things, but want to confirm the nature of your comment.

My suggestion is to:

* Give the key derivation function KDF-HMAC-SHA2() an explicit length
parameter, and remove the discussion of what its value is for each use.
 Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in
the document.  This argument will probably need to be given
symbolically, as it varies between the 128-bit and 192-bit security levels.

* Remove the discussion of what the constant values are from section 3.

> above):"; would that help?

I think it would be better to explicitly list the base key.  If it
happens to be the same as the base key from a previous test vector,
that's not really important.

> vectors starting from base key.)

I don't think there's anything precious about the currently listed test
vectors.  If the draft authors possess the base keys they used for the
encryption test vectors, they can provide them; otherwise they can
generate new test vectors and we can discard the old ones.  Including
encryption test vectors with missing base keys just seems frustrating to
an implementor.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Apr 2015 15:06:34 -0400

Greg,

Thank you for performing this important review.   The questions you have
raised are significant.   Do we have independent review from trusted
cryptographers?  I'm not one so will not try to review the math.

> encryption test vectors with missing base keys just seems frustrating to

My personal opinion is that the last call should not complete
successfully if it is not possible to verify all of the test vectors.

It would also be my preference that there be two interoperable
implementations before the working group approves the document.

Sincerely

Jeffrey Altman

---

From: Michael Jenkins <[email-masked]>
Date: Thu, 9 Apr 2015 18:21:55 -0400

Hi, sorry for the silence. I've been on travel and I wanted to make sure I
got one of the original authors to help respond. So, we should be able to
address all of Greg's concerns shortly. In the meantime, I can comment
generally if simplistically on two things:

Bit string lengths and bits-o'-security: When this draft was originally
introduced to kitten, it was stated that it was to support
draft-burgin-kerberos-suiteb <
http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So
there's an implicit presumption that one is working in one of two modes,
192-bit or 128-bit security, and consequently using either SHA-384 or
SHA-256, respectively.

In general, though, it's designed to make sense - you can't use SHA-256 to
get a 192 bit key because a SHA-256 output has at most 128 bits of security
no matter how you slice it. I am not an expert in attacks on hashes nor on
hash-function construction (boy howdy!), so I'm not going to argue about
whether this particular application is susceptible to this-or-that attack -
ultimately the answer is "because Suite B". I'm not saying that as a
hammer; I'm saying that's how the thing was pitched and accepted as a
work-item back at version -02.

Test vectors: I can nearly guarantee (see inheritance disclaimer above)
that the Ke for the encryption test vector sets beyond the first 128-bit
one came straight out of /dev/random, no doubt based on the fact that it
was easier to do so than to figure out how to get access to Kelley's
abandoned workfiles after he left for greener pastures (go him!). I can
regenerate them taking a more soup-to-nuts approach.

Mike J

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Apr 2015 18:26:40 -0400 (EDT)

Hi Jeffrey,

> implementations before the working group approves the document.

The authors have used two independent implementations to verify the test
vectors; I have done some additional verification and Greg has done some
different verification as well.

The last I checked, two interoperable implementations was a requirement
for full Internet Standard, and not required even for Proposed Standard
documents, let alone the Information status this document claims to be
targetting. Could you say a bit more about why you feel the situation is
different here?

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Thu, 09 Apr 2015 20:11:50 -0400

On 04/09/2015 06:21 PM, Michael Jenkins wrote:
> draft-burgin-kerberos-suiteb
> <http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So

I am not familiar with what Suite B requires in detail.  Looking at
https://www.nsa.gov/ia/programs/suiteb_cryptography/
I do see that Suite B indicates the use of SHA-384 for TOP SECRET.  I
assume that it requires this because the weakest inherent aspect of a
hash is its collision resistance, and SHA-384 has (we hope) a collision
resistance strength of 192 bits.  Some uses of a hash may not require
collision resistance, but using SHA-384 means you're covered regardless.

However, SHA-384 truncated to 192 bits does not have a collision
resistance strength of 192 bits; it has a collision resistance strength
of 96 bits.  This is described in detail in SP 800-107 section 5.1,
which is referenced by FIPS 180-4 section 7.

I don't think any meaningful review would deem
192-truncate(HMAC-SHA-384(k, m)) to be stronger than
192-truncate(HMAC-SHA-256(k, m)) by any metric.

> In general, though, it's designed to make sense - you can't use SHA-256
> to get a 192 bit key because a SHA-256 output has at most 128 bits of
> security no matter how you slice it.

I think it very much does matter how you slice it.  For key derivation
using an HMAC, collision resistance is not required, so it is entirely
reasonable to use SHA-256 to generate a 192-bit key.  In fact, the key
derivation function used in this draft (from SP 800-108 section 5.1) can
work securely even if more keying material is required than the HMAC
output size.

For the encryption integrity tag and checksum, collision resistance may
be required for Suite B compliance (but I don't really know).  But as
mentioned above, if we're going to truncate the HMAC result down to 192
bits, we cannot achieve collision resistance strength greater than 96
bits no matter what hash function we use in the HMAC.

In conclusion, to the best of my knowledge:

* If the goal is to meet a checklist of Suite B requirements, using
SHA-384 over SHA-256 internally might be necessary, but it really is
just a meaningless checklist tick.  Moreover, the small integrity tag
and checksum lengths could mean that the draft doesn't actually satisfy
Suite B--I can't speak confidently either way on that point.

* If the goal is to achieve some real security strength, using truncated
SHA-384 is not an improvement over using truncated SHA-256.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Apr 2015 21:54:27 -0400

> different verification as well.

I am glad to hear this.  Are there 3961 implementations available for
public review?

> targetting. Could you say a bit more about why you feel the situation is

The requirements that you mention are lower bounds that apply to all
RFCs regardless of the IETF Area.  Kitten is not any working group.  It
is a security working group whose RFCs are implemented and deployed as
the basis for securing computer systems around the globe.  The last
"informational" Kerberos encryption type RC4-HMAC (RFC 4757) became one
of the most widely deployed enc-types used for Kerberos authentication.

Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die
the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption
types for RFC 3961 based protocols.  Regardless of what track this
document is placed on it is going to be widely and rapidly deployed.  As
a result it is important that the working group ensure that the
encryption type is correct and that independent implementations for the
most widely used Kerberos implementations are available and are
demonstrated to be interoperable.

Without interoperable implementations there is very little justification
in my opinion for publishing a security framework building block as an
RFC.  Its not as if the working group is going to come back and revise
the RFC once it is deployed.

Sincerely,

Jeffrey Altman

---

From: Greg Hudson <[email-masked]>
Date: Fri, 10 Apr 2015 00:24:45 -0400

> I am glad to hear this.  Are there 3961 implementations available for

My Python implementation is at:

  https://github.com/greghudson/pyk5

in crypto.py.  No stability guarantees for that repository, though.

I should note that my implementation assumes the default cipher state,
as do all of the test vectors in the draft.  (That's true of test
vectors for all past enctypes, I'm pretty certain.)

---

From: Weijun Wang <[email-masked]>
Date: Fri, 10 Apr 2015 15:10:42 +0800

I also verified the test vectors with Java:

https://gist.github.com/wangweij/49d98745a461f12c1f54

Thanks
Weijun

---

From: Luke Howard <[email-masked]>
Date: Wed, 15 Apr 2015 14:59:02 +1000

> On 10 Apr 2015, at 10:11 am, Greg Hudson <[email-masked]> wrote:
> 

I am not a cryptographer but Greg’s arguments make sense to me. Why not always truncate the hash to 256 bits when using 256-bit AES keys?

— Luke

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 15 Apr 2015 05:57:38 +0000

> work securely even if more keying material is required than the HMAC

Yes.  A n-bit HMAC used as a key-derivation PRF is sound for deriving
n-bit keys.  The n/2 collision resistance is not in scope.  Combine
your nonces with the raw DH secret and key-purpose-specific salt,
and away you go.

-- 
	Viktor.

---

From: [email-masked]
Date: Wed, 15 Apr 2015 11:54:17 +0200

Hi Luke,

as I understand it truncating introduces potential predicablities and therefore weeknesses.

Here the argument is that truncating from a 384 set to 196, is no more secure than truncating from 256 to 196.

Starting from a larger set and truncating to the same end result does improve security, it may reduce it.

As would truncating 256 to 256, could be less secure than using straight 256, but it would be interesting to know if anyone has examined that.

SHA-256 of the SHA-2 family is a significant improvement over its predecessor SHA-1. So, where the ouput size has to be limited, using anything more than 256 is not necessary.

In terms of performance though, SHA-384 computes slightly faster than SHA-256.

Dean

Gesendet: Mittwoch, 15. April 2015 um 06:59 Uhr

Von: "Luke Howard" <[email-masked]>

An: "Greg Hudson" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Betreff: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

— Luke

Kitten mailing list

[email-masked]

---

From: Luke Howard <[email-masked]>
Date: Thu, 16 Apr 2015 01:13:26 +1000

> On 15 Apr 2015, at 7:54 pm, [email-masked] wrote:
> 

My understanding is that as long as the hash function has strong diffusion this is not a problem. The different SHA-2 variants are all truncated versions of SHA-512 (with different initial values). Also, not relevant here (because HMAC is used) but truncating hashes can actually improve security by avoiding length extension attacks.

Feel free to correct me as I’m not a cryptographer, I don’t even play one on TV… :)

— Luke

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 15 Apr 2015 15:50:42 +0000

On Thu, Apr 16, 2015 at 01:13:26AM +1000, Luke Howard wrote:

> My understanding is that as long as the hash function has strong
> diffusion this is not a problem. The different SHA-2 variants are
> all truncated versions of SHA-512 (with different initial values).

This is not the case.  There are algorithms SHA2-512 and SHA2-256
(either smaller internal state, fewer rounds or both).  SHA2-384
is a truncated SHA2-512 (with different initialization).  SHA2-224
is a truncated SHA2-256 (with different initialization).

-- 
	Viktor.

---

From: [email-masked]
Date: Wed, 15 Apr 2015 18:03:07 +0200

Hi Luke,

quite right, i should have sensed a trap when you wrote you are "not a crytographer" :-)

I would not presume to correct anyone, just that this a big topic, and attempting to generalise always leaves room for further comment.

The SHA-2 family has six members, falling into two architectural groups, meaning that SHA 512 truncated to 256 can be thought of as a version of SHA-512, this cannot be said for SHA-256.

But as you say, this may be going off at a tangent as HMAC is not suseptible to length extension attacks anway.

Dean

Gesendet: Mittwoch, 15. April 2015 um 17:13 Uhr

An: [email-masked]

Cc: "Greg Hudson" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

— Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 14:29:57 -0500

> bits?  Why not use SHA-256 and truncate to 192 bits?

I've no objection to the construction

    MAC(k, x) = trunc(HMAC(k,H), output_size(H)/2.

It's simple and obvious.

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This I dont' understand.  The HMAC key should be the same size as the
cipher key.

I suspect this is an editing error.

There should be two or three enctypes:

 - aes128-cts-hmac-sha256-128

   AES with 128-bit keys, and
     MAC = trunc-128(HMAC-SHA256) with 128-bit HMAC keys

 - aes192-cts-hmac-sha384-192

   AES with 192-bit keys, and
     MAC = trunc-192(HMAC-SHA384) with 192-bit HMAC keys

 - aes256-cts-hmac-sha512-256

   AES with 256-bit keys, and
     MAC = trunc-256(HMAC-SHA512) with 256-bit HMAC keys

Generally, the security level of the components should match the overall
security level of the enctype.

I suppose an aes256-cts-hmac-sha384-192 would be OK, but only if we
reject AES-192 and such an enctype is noticeably faster than
aes256-cts-hmac-sha512-256.

> would have 128/192-bit output lengths.

Eh?  The KDF is a truncation of the PRF.  The PRF is not truncated.

>From the draft:

   When the encryption type is aes128-cts-hmac-sha256-128, the output
   key length k is 128 bits for all applications of KDF-HMAC-SHA2(key,
   constant) which is computed as follows:

     K1 = HMAC-SHA-256(key, 00 00 00 01 | constant | 00 | 00 00 00 80)
     KDF-HMAC-SHA2(key, constant) = random-to-key(k-truncate(K1))
              ^^^^

The "SHA2" there must be a cut-n-paste error, otherwise it looks right
to me.

(RFC3962 does not define a PRF, just a KDF.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 14:54:48 -0500

> security level, and a 384-bit tag for the 192-bit security level.

I expect HMAC-SHA-256 with 128-bit HMAC keys provides 128-bit security
against forgeries (which is all we're after if we encrypt-then-MAC) no
matter length the result is truncated to as long as that length is 128
or more bits.

The reason is: the attacker has a 128-bit key search space, and any
forgery attack that requires more work than a key brute-force attack is
not worth it, so using a MAC length of more than 128 bits is not likely
to be useful (it will cause defenders to waste bandwidth) unless there
are forgery attacks at least a few bits better than the MAC length, for
HMAC with any given MAC length.

The critical thing here is the size of the HMAC key.

Perhaps HMAC-SHA256-192 with 192-bit keys could also provide 192-bit
security against distinguishing attacks and forgeries.  But if there are
such attacks depending only attacking the hash against collisions then
HMAC-SHA256-192 can't provide 192-bit security against forgeries -- it
seems prudent to assume such attacks.

ISTM prudent to use HMAC with keys of size matching the advertised
collision resistance of the base hash function and then truncate the
result to that same size.

So, HMAC-SHA256-128 w/ 128-bit keys is OK, but HMAC-SHA256-192 is not
(even if the keys are 192-bit).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 15:27:26 -0500

> which is referenced by FIPS 180-4 section 7.

(We're talking about the HMAC being truncated.  And we're after forgery
and valid MAC distinction attacks, not collision resistance.)

> 192-truncate(HMAC-SHA-256(k, m)) by any metric.

(provided that k is 192-bit)

I suggested that prudence would.  But I was wrong.  Recall that Bellare
and Mihir proved HMAC is secure if the hash function is a PRF, and this
does not depend on collision resistance.

AES256-HMAC-SHA256-192 works.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 15:52:00 -0500

> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06

To summarize the changes from RFC3962:

 - CTS remains the same but is now given by a different reference
   (SP800-38A+).  The motivation is clear (to have a NIST reference for
   the cipher mode).

   This should be the same as in RFC3962.

   (Confounding is still used.)

 - Use encrypt-then-MAC instead of MAC-then-encrypt.  +1 to that.

 - SHA-256 is used at the 128-bit security level, instead of SHA-1, and
   the HMAC output is truncated to 128 bits.  The keys for the HMAC are
   128 bits at the 128-bit security level.

 - SHA-256 is used at the 192-bit security level, and the HMAC is
   truncated to 192 bits.  The keys for the HMAC are 192 bits at the
   192-bit security level.

   AES-256 is used at the 192-bit security level because AES-192
   implementations are not as universally available as AES-256, or
   something.  In any case, I've no objection.

   I also do not object to the use of HMAC-SHA256-192 with 192-bit keys
   at the 192 bit security level.

Pending a re-review of SP800-38A+ (I think I did it last time around),
I'm OK with the contents of this I-D.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Apr 2015 16:58:08 -0400 (EDT)

>    at the 192 bit security level.

I think that some of these "256" should be "384", unless you have
progressed from summarizing the document to describing what you would like
to see...

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 16:05:40 -0500

> progressed from summarizing the document to describing what you would like

Yes, sorry.

Nico
--

---

From: Michael Peck <[email-masked]>
Date: Wed, 15 Apr 2015 22:20:56 -0400

Hi -

To try to address the comments on the draft:

1. HMAC-SHA-384 truncated to 192 bits versus HMAC-SHA-256 truncated to 192
bits :

Suite B was our motivation for proposing the two encryption types.
Suite B pairs AES-128 with SHA-256, and pairs AES-256 with SHA-384.  When
used in the digital signature context, SHA-256 provides an expected 128 bit
security level, and SHA-384 an expected 192 bit security level because of
the dependence on collision resistance.
In the case of our proposed Kerberos enctypes, we're using the hashes with
HMAC for message authentication and for a KDF so collision resistance is
not a factor - in this case, SHA-384 truncated to 192 bits appears to add
no cryptographic value over SHA-256 truncated to 192 bits.
However, our preference would still be to keep the hash choice as is for
consistency with the Suite B pairing of AES-256 with SHA-384.  This could
theoretically enable someone using just that option to not even need
SHA-256, and might also help avoid confusing compliance assessors.
(NIST SP 800-107 has a discussion of hash strengths as used in various
contexts :
http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf )

2. With aes256-cts-hmac-sha384-192, why is a 192-bit HMAC key used for Ki
and Kc but not for Kp?

Kp is used for the Kerberos pseudo-random function (PRF).
RFC3961 states that the PRF output "should be suitable for use in key
generation" - if i recall correctly, our thinking here was that we didn't
know what types of keys could potentially be derived from the PRF output,
so we'd output the full 256 bits (whether the strength of the PRF output is
actually 256 bits would of course depend on how the base-key is
generated/derived) in case the PRF might be used to generate an AES-256 key
- figured no need to drop bits even if our expected strength of the enctype
overall is 192 bits.

3. Greg's suggestion to change KDF-HMAC-SHA2 to include an explicit length
parameter, add the length parameter everywhere KDF-HMAC-SHA2 is invoked,
and remove the discussion of the constant values from section 3:

I need to work through this still, but it seems reasonable.  We'll need to
separately list invocations of KDF-HMAC-SHA2 for each encryption type, but
that might help make the draft more readable, particularly if we instead
separately refer to it as KDF-HMAC-SHA-256 and KDF-HMAC-SHA-384.

4. Provide more detail in the test vectors
We can do this -- and thank you to those who wrote and shared test vector
code.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Apr 2015 06:46:14 +0000

> http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf )

In terms of throughput, interestingly enough SHA2-512 is faster or
bulk data processing, because of its wider state, which means more
data is processed per step.  (Tested with OpenSSL 1.1 dev branch):

    $ openssl speed sha256
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    sha256           41170.10k    90881.05k   154050.73k   187984.90k   200602.63k

    $ openssl speed sha512
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    sha512           27398.45k   107324.81k   167345.58k   234789.84k   265300.65k

Similar gain reported at:

    https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions

So I guess there's no harm in using SHA2-384 even though SHA2-256
might do.  Of course the story may be different on 32-bit CPUs.

-- 
	Viktor.

---

From: Greg Hudson <[email-masked]>
Date: Thu, 16 Apr 2015 05:21:25 -0400

On 04/15/2015 10:20 PM, Michael Peck wrote:
> In the case of our proposed Kerberos enctypes, we're using the hashes
> with HMAC for message authentication and for a KDF so collision
> resistance is not a factor - in this case, SHA-384 truncated to 192 bits
> appears to add no cryptographic value over SHA-256 truncated to 192 bits.  
> consistency with the Suite B pairing of AES-256 with SHA-384.  This
> could theoretically enable someone using just that option to not even
> need SHA-256, and might also help avoid confusing compliance assessors.

I can accept the reasoning that the choice is about Suite B pairing and
not cryptographic strength.  As Viktor notes, the performance impact of
using SHA-384 over SHA-256 is a mixed bag; it is likely to be slower for
computing derived keys and PRFs, but faster for computing integrity tags
and checksums for large messages.

> generation" - if i recall correctly, our thinking here was that we
> didn't know what types of keys could potentially be derived from the PRF
> output, so we'd output the full 256 bits (whether the strength of the
> PRF output is actually 256 bits would of course depend on how the
> base-key is generated/derived) in case the PRF might be used to generate
> an AES-256 key - figured no need to drop bits even if our expected
> strength of the enctype overall is 192 bits.

Okay, but why truncate the PRF output at all?  Why not make the PRF
output 256 bits for aes128-cts-hmac-sha256-128 and 384 bits for
aes256-cts-hmac-sha384-192?

Generally speaking, the size of the PRF output is something convenient
to the enctype, and a construction like the RFC 6112 PRF+ is used to
construct however much keying material is necessary by iterating and
truncating the PRF.  There is no need for the enctype to restrict its
output length to the input key length.  (Of course the entropy of the
output is limited to the entropy of the input key.)

For comparison, RFC 4757 defines its PRF as HMAC-SHA1(K, S) and outputs
160 bits for a 128-bit input key.

I agree that Kp should be 256 bits for aes256-cts-hmac-sha384-192; that
was a dumb question.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Apr 2015 14:35:42 -0400 (EDT)

Hi Jeffrey,

> cryptographers?  I'm not one so will not try to review the math.

I don't believe there was explicit "independent cryptographer" review at
the time you wrote this.  ("Does Nico count as a cryptographer?")

That said, this document is basically just taking some well-understood
building blocks and combining them in well-understood ways.  It differs
from the existing AES enctypes in using encrypt-then-mac (now the
~universal consensus of the community), in using newer hash functions
truncated to a longer length, and in the key derivation algorithm.  The
key derivation algorithm it uses, from NIST SP800-108, is quite well
understood.  Oh, and the default PBKDF2 iteration count was increased.

I do not think that there is any sufficiently novel cryptography going on
so as to require additional review.  If you still feel that more review
(e.g., from CFRG) is necessary, please say so, ideally with some rebuttals
to my above argument.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 14:06:14 -0500

> the time you wrote this.  ("Does Nico count as a cryptographer?")

"Decidedly not."

However, we have authorities we can quote as to:

 - the safety of the confounded CTS construction (which isn't new here)

 - the safety of the HMAC truncation (which isn't new here)

 - the safety of encrypt-then-MAC (which is new here for Kerberos)

 - the safety of HMAC with SHA-2 functions (we need only that they be a
   good PRF) (which is new here, of course, for Kerberos anyways)

What controversies are there?

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Apr 2015 15:43:52 -0400 (EDT)

> I am glad to hear this.  Are there 3961 implementations available for

Greg linked to his, as did Weijun.  My checks were not part of a 3961
implementation but rather just confirmations of the test vectors by
manually performing the specified operations.

I don't think that the implementations of the authors have been published.

> of the most widely deployed enc-types used for Kerberos authentication.

My understanding is that RFC 4757 needed to be Informational because it
was constrained by a desire to interoperate with NTLM-SSP, and if it was
Proposed Standard, the design would be open to modification as an IETF
work, so the interoperability would be lost.

> demonstrated to be interoperable.

I don't share your confidence that this particular enctype is going to be
widely and rapidly deployed.  I agree with the sentiment that we should
have something other than enctypes 17 and 18, but it is not necessarily
clear that this would be it.  There might be more excitement for something
other than AES; I don't know.  We certainly don't have people coming to us
(MIT krb5) and clamoring for this exact enctype...

> the RFC once it is deployed.

Well, some people may not want to implement until there is a final spec to
implement (i.e., an RFC).  There are mechanisms to adjust things if we
mess up, whether that's an erratum or a quick bis RFC, so I am comfortable
moving forward with the level of testing we currently have (test vector
verification without explicit interoperation).  It is certainly something
that the responsible AD and the IESG can consider as the document moves
forward, as well.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Apr 2015 16:41:32 -0400 (EDT)

> The "SHA2" there must be a cut-n-paste error, otherwise it looks right

It is not a cut/paste error; they are defining KDF-HMAC-SHA2() one way for
the 128-bit case, and below KDF-HMAC-SHA2() is defined for the 256-bit
case.

Greg doesn't like this implicitness and requested an explicit length
parameter be used.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Apr 2015 17:23:10 -0400 (EDT)

We got a number of comments and questions in this last call.  I will try
to summarize them and the response to them, below.  Please let me know if
I have missed something or inaccurately represented someone's statements.

=======================================================

* Greg asked about using SHA-256 instead of SHA-384 for 192-bit truncated
HMACs.

There was a lot of discussion on this point.  The conclusion seems to be
that, when used with a has function that is a PRF, the HMAC construction
is not dependent on collision resistance and therefore the security level
is capped by the size of the input key (or the hash output length).
(Note, however, that a hash which is not collision resistant to the
2^(n/2)-bit level, such as SHA-1, is as a consequence not a PRF.)  So,
while it would be cryptographically fine to use HMAC-SHA2-256() truncated
to 192 bits as message authentication tag, we will still retain
HMAC-SHA2-384() at the 192-bit security level to be consistent with the
Suite B recommendations.  (It may also be faster in some situations on
some hardware, but this is hard to make general statements about.)

* Greg asked why Ki and Kc are 192-bit but Kp is 256-bit, or alternately
"why use a 256-bit PRF output length?", but later retracted that question,
as there are reasons why a 256-bit Kp makes sense that do not apply to Ki
and Kc.  "But why truncate the PRF at all?" remains.

There is not really an issue here anymore.  Ki and Kc are 192-bit derived
keys because they are used to derive 192-bit message authenticity tags.
The base key, Ke, and Kp are 256-bits.  It is convenient to make the base
key 256 bits, since we use aes256, and will need 256-bit encryption keys;
making the base key smaller than that seems silly in some sense.  Ke has
to be 256 bits since it is in the path to the aes256 encryption keys as
well.  Kp is 256 bits because the PRF output should be suitable for key
generation, and there is no reason to reduce the number of bits of
keyspace at this point.  (But see the next item.)

* Greg asked why the PRF output length is 128/256 bit instead of the full
hash width.

There does not seem to be any reason to truncate the HMAC output, here.
The output length is supposed to be what is convenient for the enctype,
and there is precedent for not being a multiple of the key size.  It would
be good to get acknowledgement from the authors that this will go in the
next revision.

* Greg noted that random-to-key() is used in computing Ki and Kc, but for
the AES256 variant, random-to-key() formally only produces a (256-bit)
base key, so this is slightly problematic.

The random-to-key() function for this enctype is the identity function,
and the uses in section 3 are entirely internal to the implementation;
there is no need to write random-to-key() in these places.  We can safely
just write things like KDF-HMAC-SHA2(key,constant,k) = k-truncate(K1).

* Greg wants base keys and key usages for the test vectors instead of
intermediate keys.

General agreement; new test vectors will be generated that include base
keys and derivation constants.

* I noted an instance of "the use of [...] AES-256 with a 192-bit key"
which should be reworded.

No objections; will the document editor please take note.

* Greg suggested giving KDF-HMAC-SHA2() an output length parameter.

Michael thinks this is probably reasonable, and may help the readability
of the document.  It sounds like we will go forward with this approach.

* Greg wants to remove discussion of the constant values from section 3.

Also no objections and probably reasonable.

* Jeff A. asked if we have independent cryptographic review

Nico and I claim that we are using well-understood building blocks in
well-understood ways, and no additional review is needed.  Jeff A. has not
had a chance to reply to these claims yet.

* Jeff A. cares strongly about interoperability and test vector
verification.

Greg and Weijun have published python and java code respectively, which
verify the test vectors, but are not quite enough for interoperability
testing (?).  The authors had java and python implementations to verify
the test vectors, which are not (?) published.  I claim this is sufficient
for now, and Jeff A. has not had a chance to reply yet.

* Michael plans to update the draft in response to comments, and expand
the test vectors.

There is much rejoicing.

=======================================================

That seems to leave us with the following action items:

For the document editor:
* remove truncation from the PRF output and use the natural hash output
length
* remove the use of random-to-key() and discussion of constant values from
section 3
* add an output length argument to KDF-HMAC-SHA2() and adjust text
accordingly
* update test vectors to include base keys and key usage values for all
test cases
* reword the text discussing aes256 with 192-bit keys

For Jeffrey Altman:
* comment about the status of the crypto review and the interoperability
testing in light of other comments that have come in on those points.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 16:57:26 -0500

> (MIT krb5) and clamoring for this exact enctype...

We're definitely in shape to *add* enctypes now.  Interop issues from
dealing with 3DES and RC4 have shaken out the sorts of bugs that would
make adding new enctypes difficult.

The fact that these enctypes are simple variants on the existing ones
should help get implementations, should anyone need them.

I think there will be sites that need to move away from SHA-1, even if
HMAC-SHA-1 remains secure (which I'm not saying it does).

That said, I don't think these enctypes will generate much interest
beyond moving beyond SHA-1.  As with TLS, ideally we should add new
enctypes based on ciphers other than AES in addition to the AES ones.
For Kerberos this is much harder than for TLS due to the fact that a)
AEAD ciphers/cipher modes are all the rage now, b) RFC3961 is not
AEAD-friendly, c) if we're to use AEAD ciphermodes then we need ones
which don't require stateful nodes (i.e., which don't fall apart because
of (key, IV) reuse).  There's a relevant thread on CFRG about this right
now.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Apr 2015 19:32:50 -0400 (EDT)

> make adding new enctypes difficult.

Well, the enctype-selection logic should be in reasonable shape, but I
think some implementations will have some work to do for actually
generating and using these keys for service principals, since the KDC
ought not generate them without explicit signal from the service that its
implementation supports the new enctype.  I don't think everybody is in
good shape, there.

For tightly controlled environments, of course, there is no concern in
this space.

-Ben

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Apr 2015 11:15:04 -0400

> had a chance to reply to these claims yet.

I am happy with the current level of review activity.

> for now, and Jeff A. has not had a chance to reply yet.

I care enough about interoperability that I have agreed to fund an
implementation for Heimdal.  I would like to see someone commit to a
second implementation.

> * Michael plans to update the draft in response to comments, and expand

Thank you.

Done.

---

From: Michael Peck <[email-masked]>
Date: Mon, 20 Apr 2015 11:56:44 -0400

Ben,

Thank you for summarizing the discussion, and we'll work on making these
changes.

Our draft's current practice of truncating the pseudo-random function
output to 128 bits (for enctype aes128-cts-hmac-sha256-128) and 256 bits
(for enctype aes256-cts-hmac-sha384-192) rather than providing the full
HMAC output has the benefit of discouraging misuse of the output.  If the
full HMAC output is returned by the PRF, I'd be afraid it may imply an
output of 256 or 384 bit strength when the maximum strength is in reality
limited to 128 or 256.  It's not clear to me the potential ways the PRF
output might be used - certainly I could see both appropriate and
inappropriate ways to use the output.

If the working group prefers the full output be returned, we can do that
and could attempt to address it in the security considerations.  We provide
the PRF definition to comply with the RFC 3961 framework but would probably
prefer a NIST SP 800-108 KDF be used to derive keys for other uses.  I
could see the PRF output potentially being used as the Ki key derivation
key input to a NIST SP 800-108 KDF for those who want to use that.

Mike

---

From: Greg Hudson <[email-masked]>
Date: Mon, 20 Apr 2015 13:24:22 -0400

On 04/20/2015 11:56 AM, Michael Peck wrote:
> HMAC output has the benefit of discouraging misuse of the output.  If
> the full HMAC output is returned by the PRF, I'd be afraid it may imply
> an output of 256 or 384 bit strength when the maximum strength is in
> reality limited to 128 or 256.  It's not clear to me the potential ways
> the PRF output might be used - certainly I could see both appropriate
> and inappropriate ways to use the output.

To the best of my knowledge, all current users of the RFC 3961 PRF have
a fixed amount of desired output, and iterate and truncate the PRF
function to produce the number of desired bytes.  See the definitions of
PRF+ in RFC 4402 and RFC 6112.

So, for example, if someone asks for 256 bits of PRF output (e.g. via
gss_pseudo_random()) and the enctype is aes128-cts-hmac-sha256-128 with
the PRF truncated to 128 bits.  The user will wind up invoking

  PRF(K, 00 00 00 00 || string)
  PRF(K, 00 00 00 01 || string)

and concatenating the results.  The application has not in any way been
discouraged from producing a 256-bit string with only 2^128 possible
values; it has merely been made twice as slow.

> and could attempt to address it in the security considerations.

I think the audience of this enctype's security considerations is mainly
implementors of the enctype.  Applications aren't written to specific
enctypes; they are written to RFC 3961 or a higher layer.  If you want
to say something about the inherently limited entropy of the PRF output
then I won't object, but I don't think it is necessary or useful.

> We
> provide the PRF definition to comply with the RFC 3961 framework but
> would probably prefer a NIST SP 800-108 KDF be used to derive keys for
> other uses.  I could see the PRF output potentially being used as the Ki
> key derivation key input to a NIST SP 800-108 KDF for those who want to
> use that.

The PRF+ construction is pretty similar to the KDF used in the aes-sha2
draft, except that it doesn't append a length to the end of each PRF
invocation's input string.  I believe the only potential problem there
is that PRF+(K, 256, S) will be an extension of PRF+(K, 128, S) rather
than a totally different value.  That's a potential safety issue, but as
long as callers use different S values for different kinds of keys, it's
not a real problem.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Apr 2015 20:32:55 -0400 (EDT)

> PRF+ in RFC 4402 and RFC 6112.

I'm trimming most of the mail, but I agree with everything Greg said.  The
RFC 3961 pseudo-random function is basically only useful as a building
block for a PRF+ construction, given that different enctypes are permitted
to (and do!) output different length pseudo-random output.

-Ben