1. Summary
Benjamin Kaduk is the document shepherd. Stephen Farrell is the
responsible Area Director.
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.
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.
2. Review and Consensus
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.
The two main issues that shaped this document's evolution were the
decision between the CBC and CTS cipher modes, and the use of a random
IV versus a random confounder. CBC modes are simpler and more
typical for Suite-B deployments, but they bring a larger range of possible
ciphertext expansions; there are reportedly applications written against
Windows APIs that can only accomodate the 64-bit range of ciphertext
expansion that was possible with the DES CBC-mode ciphers, and would
fail badly for larger (128- or 256-bit) variable ciphertext expansion.
The desire to not break such existing software forced the use of a CTS
mode. Similarly, explicit random IVs are more typical for Suite-B
deployments, but Kerberos has traditionally used an implicit random
confounder prepended to the plaintext, with an initial zero IV.
In this case, the confounder presents something of an advantage in that
it does not expose the raw output of a participant's PRNG on the wire,
which could potentially limit certain attacks against the PRNG
algorithm in certain circumstances. Given that advantage and the
Kerberos tradition, this document continues the use of a random confounder
with initial zero IV, since they fulfil the same cryptographic purpose.
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.
3. Intellectual Property
There are no intellectual property disclosures against this document,
and all three authors have confirmed compliance with BCPs 78 and 79.
4. Other Points
This document is a little old (~150 days, as noted by idnits) due to the
shepherd being preoccupied due to moving residences.
The IANA considerations are simple, just requesting assignment of
four numbers in tables that are only number, name, and reference.