AES Encryption with HMAC-SHA2 for Kerberos 5
draft-ietf-kitten-aes-cts-hmac-sha2-11

[Ballot discuss]
There was a Gen-ART review from Vijay, with a question about the contents of the Context field. I don't think the document necessarily needs a change or even new text here, but at the very least we need an answer from the authors. I got the same question as Vijay when reading the draft.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-kitten-aes-cts-hmac-sha2-10.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Kerberos Encryption Type Numbers subregistry of the Kerberos Parameters registry located at:

https://www.iana.org/assignments/kerberos-parameters/

two new encryption type numbers are to be registered as follows:

etype: [ TBD-at-registration ]
encryption type: aes128-cts-hmac-sha256-128
Reference: [ RFC-to-be ]

etype: [ TBD-at-registration ]
encryption type: aes256-cts-hmac-sha384-192
Reference: [ RFC-to-be ]

Second, in the Kerberos Checksum Type Numbers subregistry of the Kerberos Parameters registry located at:

https://www.iana.org/assignments/kerberos-parameters/

two new checksum type numbers are to be registered as follows:

sumtype value: [ TBD-at-registration ]
Checksum type: hmac-sha256-128-aes128
checksum size: 16
Reference: [ RFC-to-be ]

sumtype value: [ TBD-at-registration ]
Checksum type: hmac-sha384-192-aes256
checksum size: 24
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that the two actions above are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-kitten-aes-cts-hmac-sha2@ietf.org, kitten-chairs@ietf.org, "Benjamin Kaduk" , kitten@ietf.org, kaduk@mit.edu, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (AES Encryption with HMAC-SHA2 for Kerberos 5) to Informational RFC


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'AES Encryption with HMAC-SHA2 for Kerberos 5'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies two encryption types and two corresponding
  checksum types for Kerberos 5.  The new types use AES in CTS mode
  (CBC mode with ciphertext stealing) for confidentiality and HMAC with
  a SHA-2 hash for integrity.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ballot/


No IPR declarations have been submitted directly on this I-D.

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.

The careless AD almost started IETF LC even though there was recent
traffic on the WG list that needs to be resolved first.

-09 is fine from an AD review POV, so once the WG have resolved the
issue being discussed now, this'll be fine to go ahead.

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 the authors have been asked to confirm 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.

The WG elected to go with CTS over CBC due to concerns about the inability of software in the Widows ecosystem to handle variable-length ciphertext expansion larger than 7 octets.