Network Working Group K. Raeburn
Request for Comments: 3962 MIT
Category: Standards Track February 2005
Advanced Encryption Standard (AES) Encryption for Kerberos 5
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2005).
The United States National Institute of Standards and Technology
(NIST) has chosen a new Advanced Encryption Standard (AES), which is
significantly faster and (it is believed) more secure than the old
Data Encryption Standard (DES) algorithm. This document is a
specification for the addition of this algorithm to the Kerberos
This document defines encryption key and checksum types for Kerberos
5 using the AES algorithm recently chosen by NIST. These new types
support 128-bit block encryption and key sizes of 128 or 256 bits.
Using the "simplified profile" of [KCRYPTO], we can define a pair of
encryption and checksum schemes. AES is used with ciphertext
stealing to avoid message expansion, and SHA-1 [SHA1] is the
associated checksum function.
2. Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
Raeburn Standards Track [Page 1]RFC 3962 AES Encryption for Kerberos 5 February 20053. Protocol Key Representation
The profile in [KCRYPTO] treats keys and random octet strings as
conceptually different. But since the AES key space is dense, we can
use any bit string of appropriate length as a key. We use the byte
representation for the key described in [AES], where the first bit of
the bit string is the high bit of the first byte of the byte string
(octet string) representation.
4. Key Generation from Pass Phrases or Random Data
Given the above format for keys, we can generate keys from the
appropriate amounts of random data (128 or 256 bits) by simply
copying the input string.
To generate an encryption key from a pass phrase and salt string, we
use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
indicated below, to generate an intermediate key (of the same length
as the desired final key), which is then passed into the DK function
with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function
produces a "random octet string", hence the application of the
random-to-key function even though it's effectively a simple identity
operation.) The resulting key is the user's long-term key for use
with the encryption algorithm in question.
tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
key = DK(tkey, "kerberos")
The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
passphrase and salt, as described in Appendix B.1 to PKCS#5.
The number of iterations is specified by the string-to-key parameters
supplied. The parameter string is four octets indicating an unsigned
number in big-endian order. This is the number of iterations to be
performed. If the value is 00 00 00 00, the number of iterations to
be performed is 4,294,967,296 (2**32). (Thus the minimum expressible
iteration count is 1.)
For environments where slower hardware is the norm, implementations
of protocols such as Kerberos may wish to limit the number of
iterations to prevent a spoofed response supplied by an attacker from
consuming lots of client-side CPU time; if such a limit is
implemented, it SHOULD be no less than 50,000. Even for environments
with fast hardware, 4 billion iterations is likely to take a fairly
long time; much larger bounds might still be enforced, and it might
be wise for implementations to permit interruption of this operation
by the user if the environment allows for it.
Raeburn Standards Track [Page 2]