rfc-3962

Advanced Encryption Standard (AES) Encryption for Kerberos 5

K. Raeburn
date2005-02 streamIETF areasec wgkrb-wg statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc3962 doi10.17487/RFC3962
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. [STANDARDS-TRACK]

updated by

Extracted elements (23)

design-rationale §5

Ciphertext stealing was chosen over CBC with padding to avoid message expansion for arbitrary-length messages. This is a deliberate departure from previous Kerberos cryptosystems, which used padding.

crypto, security

design-rationale §4

The default PBKDF2 iteration count of 4,096 (00 00 10 00) is defined solely as the interpretation of an absent string-to-key parameter when the KDC has had an opportunity to supply it; it is explicitly not a recommendation for use in optimistic preauthentication or as a site default.

crypto, security

design-rationale §4

The random-to-key function is effectively an identity operation for AES because the AES key space is dense — any bit string of the correct length is a valid key, so no transformation is needed when generating keys from random data.

crypto, security

errata §A

Errata for RFC 2040 (RC5-CTS) Section 8 correct three errors: (1) for short messages where Cn-2 does not exist in the encryption XOR step, the IV should be used; (2) the mode only handles plaintext longer than one block, not any length; (3) decryption step 6 should XOR the decrypted block with Cn-2 (or IV for short messages) to produce Pn-1.

crypto, security

interoperability-note §6

These AES encryption and checksum types are defined using the 'simplified profile' of RFC 3961 (KCRYPTO). Implementations must follow the profile parameters in Section 6 exactly, including the specific HMAC truncation to 96 bits and CBC-CTS mode with next-to-last block as IV carry-forward.

crypto, security

normative-requirement §4 SHOULD

If an implementation limits the accepted PBKDF2 iteration count to prevent denial-of-service attacks, that limit SHOULD be no less than 50,000.

crypto, security

normative-requirement §5 MUST NOT

If exactly one block is to be encrypted, it is encrypted with AES in ECB mode. Input smaller than one block is padded at the end; implementations MAY use all-zero or random padding, but protocols MUST NOT rely on the result being deterministic or non-deterministic.

crypto, security

normative-requirement §4 OPTIONAL

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

crypto, security

protocol-element §5

Ciphertext stealing (CTS) is used instead of padding to handle partial final blocks, ensuring no message expansion for arbitrary-length messages. CTS is always applied to the last two blocks for consistency; if data length is a multiple of block size this is equivalent to plain CBC with the last two ciphertext blocks swapped.

crypto, security

protocol-element §3

Protocol key format is a 128- or 256-bit string. Because the AES key space is dense, any bit string of appropriate length can be used as a key, represented with the first bit of the bit string as the high bit of the first byte.

crypto, security

protocol-element §4

String-to-key derivation uses PBKDF2 (PKCS#5 v2.0) with SHA-1 HMAC as the pseudorandom function, followed by the DK function with the 8-octet ASCII string 'kerberos': tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)); key = DK(tkey, 'kerberos').

crypto, security

protocol-element §5

The initial vector carried forward from one encryption to the next is the next-to-last block of the encryption output (the encrypted form of the last plaintext block). When decrypting, the next-to-last block of the ciphertext is used as the next IV. If only one block is available, that single block is carried out instead.

crypto, security

protocol-element §6

The Kerberos algorithm profile uses PBKDF2+DK for string-to-key, SHA-1 as the hash function, 12-octet (96-bit) HMAC output, 1-octet message block size, and AES in CBC-CTS mode with 16-octet cipher block size. The next-to-last block (or last block if only one) is used as the CBC-style IV.

crypto, security

protocol-element §7

Two checksum types are defined: hmac-sha1-96-aes128 (sumtype 15, 96-bit output) and hmac-sha1-96-aes256 (sumtype 16, 96-bit output), corresponding to their respective encryption types.

crypto, security, registry

protocol-element §7

Two encryption types are defined: aes128-cts-hmac-sha1-96 (etype 17, 128-bit key) and aes256-cts-hmac-sha1-96 (etype 18, 256-bit key). Both use AES in CBC-CTS mode with SHA-1 HMAC truncated to 96 bits.

crypto, security, registry

registry §7

Encryption type numbers 17 (aes128-cts-hmac-sha1-96) and 18 (aes256-cts-hmac-sha1-96), and checksum type numbers 15 (hmac-sha1-96-aes128) and 16 (hmac-sha1-96-aes256) are assigned. These were previously reserved in RFC 3961; the registries are updated to reference this document.

registry, crypto, security

security-consideration §8

AES has not received the decades of cryptanalytic scrutiny that DES has; a previously undiscovered weakness may exist. The use of HMAC with SHA-1 has a drawback for pass phrases longer than 64 bytes, which are hashed to 20 bytes before the main HMAC computation, though sparse entropy in long pass phrases may mitigate this in practice.

crypto, security

security-consideration §8

An attacker spoofing a KDC reply with a low iteration count can reduce the work required for brute-force attacks. Implementations should enforce both lower and upper bounds on accepted iteration counts; site-specific configuration of these bounds is recommended.

crypto, security

security-consideration §8

Ciphertext stealing mode reveals the exact length of each encrypted message (no padding), rather than bounding it to a range as in padded CBC. If message length must be hidden, it should be obscured at a higher protocol layer by intentionally varying message length.

crypto, security, privacy

security-consideration §8

Generating a 256-bit key from a pass phrase of any length may be misleading: the effective entropy of a pass-phrase-derived key cannot approach 256 bits given the properties of the string-to-key function. Users and implementers should not assume key length alone implies security.

crypto, security

security-consideration §8

If the PBKDF2 iteration count can be spoofed by a network attacker and the implementation's upper bound is very high, the attacker can mount a denial-of-service attack against the client by supplying an excessively large iteration count, causing the client to spend significant CPU time computing an incorrect key.

crypto, security

security-consideration §8

The PBKDF2 iteration count is a constant multiplier on brute-force work for both attacker and legitimate user. The iteration count should be chosen based on attacker/user hardware balance and should be increased over time (approximately 40–60% per year) as CPU power increases. A new random salt should be generated when passwords change to prevent caching of intermediate PBKDF2 results.

crypto, security

wire-format §4

The string-to-key parameter field is four octets encoding an unsigned big-endian iteration count for PBKDF2. A value of 00 00 00 00 means 2^32 (4,294,967,296) iterations; the minimum expressible count is 1.

crypto, security