Subject: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt)

From: The IESG <[email-masked]>
Date: Thu, 01 Sep 2016 13:17:15 -0700

The IESG has approved the following document:
- 'AES Encryption with HMAC-SHA2 for Kerberos 5'
  (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt) as Informational RFC

This document is the product of the Common Authentication Technology Next
Generation Working Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/

Technical Summary

This document specifies new Kerberos encryption types that use the AES
block cipher and cryptographic hashes from the SHA-2 family.  They differ
from the existing AES encryption types by using SHA-2 hashes instead of
SHA-1 (and truncating at a longer length), using encrypt-then-MAC
intsead of encrypt-and-MAC, and other changes to move closer towards
current cryptographic best practices.  It is expected that an updated
Suite-B profile for Kerberos will make use of these new encryption types.

Working Group Summary

There is consensus for this document, which brings incremental improvements
to the cryptography available for use with Kerberos.  Initial individual
drafts attempted to combine a Suite B profile and new encryption types
into a single document, but the new encryption types have been split out
into this document appropriately, with the Suite B profile to follow
separately.

This is a Informational document that specifies a new Kerberos
encryption type; it does not need to update any Kerberos protocol
elements.  There will eventually be desire for another (set of)
standards-track Kerberos encryption types, but it remains unclear
whether that will be this set or some other cipher; there is no procedural
reason to target standards-track at this time.  

Document Quality

This document (and its predecessors) has received a large amount of attention
and review from essentially all of the prominent WG contributors, spread out
over a few years, and there are multiple implementations that are able to
reproduce the supplied test vectors.  

Personnel

Benjamin Kaduk is the document shepherd.  Stephen Farrell is the
responsible Area Director.

RFC Editor Note

Please add RFC4556 to the informative references in 10.2. 

It's mentioned in the security  considerations but there's nothing in 
10.2 at present.

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 2 Sep 2016 21:12:36 -0400

>   (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt) as Informational RFC

Now that approval has been obtained from the IESG, can the encryption
and checksum type numbers be allocated by the working group or do we
have to wait for an IANA action?

Jeffrey Altman

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Sep 2016 17:19:07 -0400 (EDT)

> have to wait for an IANA action?

IANA has to perform the allocation, but they seem to have already started
taking action, as can be seen at the document history
(https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/history/).
(There was a two hour gap between the "In Progress" and "On Hold" state
transitions.)  Maybe that means they are asking the expert, though I did
not think that the standards action policy required such consultation.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Sep 2016 01:52:27 +0100

> not think that the standards action policy required such consultation.

If getting numbers assigned is important, please say why and
we can see if it can happen sooner. Shouldn't be too long at
all though.

For future reference, please see [1] (I know the WG chairs
know that, but maybe other folks may not) which allows WGs
to ask for early allocations of codepoints.

S.

[1] https://tools.ietf.org/html/rfc7120

> 
> -Ben
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Greg Hudson <[email-masked]>
Date: Tue, 6 Sep 2016 10:08:18 -0400

> we can see if it can happen sooner. Shouldn't be too long at

MIT krb5 and Heimdal are both interested in including aes-sha2 support
in their next releases, but can't even add code to their respective
master branches without IANA assignments.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Sep 2016 17:14:41 +0100

Hiya,

I'm checking with IANA if we can speed things up.

Cheers,
S.