Skip to main content

AES Encryption with HMAC-SHA2 for Kerberos 5
RFC 8009

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: "IETF-Announce" <>
Cc:,, "Benjamin Kaduk" <>,,, "The IESG" <>,,
Subject: Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt)

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:

Ballot Text

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

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.  


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

RFC Editor Note

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.