Advanced Encryption Standard (AES) Encryption for Kerberos 5
RFC 3962

Document Type RFC - Proposed Standard (February 2005; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3962 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Russ Housley
Send notices to <>
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 Notice

   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
   cryptosystem suite.

1.  Introduction

   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",
   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 2005

3.  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]
RFC 3962             AES Encryption for Kerberos 5         February 2005

   If the string-to-key parameters are not supplied, the value used is
   00 00 10 00 (decimal 4,096, indicating 4,096 iterations).

   Note that this is not a requirement, nor even a recommendation, for
   this value to be used in "optimistic preauthentication" (e.g.,
   attempting timestamp-based preauthentication using the user's long-
Show full document text