Encryption and Checksum Specifications for Kerberos 5
updated by
- rfc-8429 — Deprecate Triple-DES (3DES) and RC4 in Kerberos
Extracted elements (29)
Keys in Kerberos serve multiple distinct functions, making it unwise to use the same key for multiple purposes. The framework enumerates different key usages and takes a 'usage number' as input to encryption and checksum mechanisms, producing a distinct 'specific key' derived from the base key for each usage, so compromise of one derived key does not compromise others.
Some DES-based mechanisms in Section 6 do not fulfill all profile requirements (e.g., missing non-malleability, no key derivation); they are defined for backward compatibility with existing Kerberos implementations. Newer implementations should use mechanisms that satisfy all profile requirements whenever possible.
An encryption mechanism must provide confidentiality, integrity, and non-malleability of the original plaintext. Use of a random confounder prepended to the plaintext is recommended so an observer cannot determine if two ciphertexts correspond to the same plaintext, even with identical keys and cipher state.
For application protocol convenience, for every plaintext length L1 there must exist a message size L2 with L1 ≤ L2 < L1 + 65,536 such that decrypt(encrypt(M)) = M for every message M of length L2. This constrains padding schemes to avoid unrecoverable extra octets after decryption.
Key usage numbers are unsigned 32-bit integers and zero is not permitted. New protocols defined in terms of Kerberos encryption and checksum types should use their own key usage values distinct from those assigned to the core Kerberos protocol.
Strings provided to the string-to-key function in encodings other than UTF-8 MUST first be converted to UTF-8 before applying the function. No specific Unicode version should be assumed; all valid UTF-8 strings must be accepted.
The cipher state must be non-empty and must influence encryption so that messages are decrypted in the same order they were encrypted when cipher state is chained. The cipher state may not be reused across multiple encryption or decryption operations; each operation produces a new cipher state.
The four 'weak' and twelve 'semi-weak' DES keys identified in the DES specifications SHALL NOT be used for encrypting Kerberos messages. The 48 'possibly-weak' keys are not avoided; weak-key corrections are applied after key generation and string-to-key operations.
Unkeyed checksum mechanisms (CRC-32 type 1, RSA-MD4 type 2, RSA-MD5 type 7) may only be used with caution in limited circumstances where the lack of a key creates no attack window, preferably only within an encrypted message. Keyed checksum algorithms are recommended.
des-cbc-crc (etype 1) uses DES-CBC with the key itself as the initialization vector and a modified 4-octet CRC-32. The modification from standard CRC-32 omits the sum with the all-ones polynomial times x**k and does not ones-complement the final remainder; bit ordering within octets is LSB-first.
des-cbc-md5 (etype 3) uses DES-CBC with all-zero initial vector and an MD5 checksum. Protocol key is 8 bytes with parity in low bit of each octet; specific key is a copy of the original key; cipher state is the 8-byte CBC IV initialized to all-zero; required checksum mechanism is rsa-md5-des.
des3-cbc-hmac-sha1-kd (etype 16) with hmac-sha1-des3-kd (checksum type 12) uses Triple-DES Outer-CBC mode and HMAC-SHA1 with key derivation per the simplified profile. Key is 24 bytes (three 8-byte DES subkeys), seed length 21 bytes, HMAC output 160 bits, message block size 8 bytes, confounder 8 random octets.
DES3 random-to-key divides 168 random bits into three 56-bit groups; each is expanded to 64 bits by inserting parity bits at specified positions (bits 1–7, p; 9–15, p; ... ; 56, 48, 40, 32, 24, 16, 8, p). Each sub-key is corrected for DES weak/semi-weak keys, then the three 8-byte sub-keys are concatenated.
DES3 string-to-key applies the n-fold algorithm (168-fold) to the concatenation of password and salt, invokes random-to-key to produce a temporary key, then applies DK(tmpKey, KerberosConstant) where KerberosConstant is the 8-byte ASCII encoding of 'kerberos' (0x6b65726265726f73).
rsa-md5-des (checksum type 8) produces a 24-octet keyed checksum: get_mic = des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md5(conf | msg), ivec=0), where conf is an 8-octet confounder. Associated cryptosystems are des-cbc-md5, des-cbc-md4, and des-cbc-crc.
The checksum algorithm profile requires: associated encryption algorithm(s), a get_mic function producing a MIC token of at most 65,535 octets, and a verify_mic function. Both must accept inputs of arbitrary length; any padding scheme must be specified as part of these functions.
The encryption algorithm profile mandates definition of: protocol key format, specific key structure, required checksum mechanism, key-generation seed length, string-to-key, random-to-key, and key-derivation functions, string-to-key parameter format, cipher state and initial cipher state, encrypt, decrypt, and pseudo-random functions. All operations must be defined as mathematical functions with no implicit inputs.
The key derivation function is defined as DK(Key, Constant) = random-to-key(DR(Key, Constant)), where DR(Key, Constant) = k-truncate(K1 | K2 | …) with Ki = E(Key, K(i-1), initial-cipher-state). If the Constant is smaller than the cipher block size c, it is expanded using n-fold. Deriving the base key from a derived key is as hard as breaking the underlying cipher.
The n-fold algorithm takes m input bits and produces n output bits with equal contribution from each input bit by replicating the input to the LCM of n and m bits (rotating right 13 positions before each repetition) and adding successive n-bit chunks using 1's-complement addition. The Constant passed to DR must not be larger than the cipher block size c.
The simplified profile for CBC ciphers with key derivation requires: unkeyed hash algorithm H suitable for HMAC, HMAC output size h (at least 80 bits and at least half of H's output size), message block size m (multiple of 8 bits), basic encryption/decryption functions E and D, and cipher block size c (at least 5 octets).
Three specific keys are derived from the base key using the DK function with the 4-byte big-endian key usage number followed by a one-octet suffix: Kc = DK(base-key, usage | 0x99) for checksum computation, Ke = DK(base-key, usage | 0xAA) for encryption, Ki = DK(base-key, usage | 0x55) for HMAC integrity verification.
Two IANA registries are created: Kerberos Encryption Type Numbers and Kerberos Checksum Type Numbers. Values are signed 32-bit integers; positive values require Standards Action (for standards-track) or Expert Review (for non-standards-track RFCs); negative values are private-use; zero is reserved. Smaller positive values are preferred for IETF standards-track mechanisms due to ASN.1 encoding efficiency.
DES is no longer considered a strong encryption mechanism due to advances in large-scale attacks; Triple-DES is generally preferred despite poorer performance. DES also has 48 'possibly-weak' keys beyond the 16 weak/semi-weak keys that are not avoided by the Kerberos specification.
Random confounders are essential to prevent use of Kerberos protocol exchanges as encryption oracles. Without a confounder, encryption of constant plaintext yields constant ciphertext (as in Kerberos v4), creating an effective oracle. Random confounders frustrate chosen-plaintext attacks by ensuring different ciphertexts even for identical plaintexts.
The CRC-32 as modified for Kerberos is not collision-proof; a probabilistic chosen-plaintext attack can generate an alternative message with the same checksum. Additionally, the Kerberos CRC-32 implementation effectively ignores leading zero bits, so messages differing only in leading zeros share the same checksum value.
Unkeyed encrypted checksums (as in single-DES cryptosystems from RFC 1510) allow cut-and-paste attacks and are vulnerable to chosen-plaintext attacks: an attacker with access to an encryption oracle can encrypt the required unkeyed checksum with chosen plaintext, enabling forgery and cross-protocol attacks from Kerberos v4 to v5.
Using the same key for both Kerberos version 4 and version 5 in dual-version implementations enables a cross-protocol attack: version 4's encryption-of-constant-plaintext oracle can be exploited to attack version 5 sessions. This makes using a single key for multiple purposes unwise.
DES encryption data format is: confounder (8 bytes, one DES block) | checksum (type-dependent length, zeroed before checksum computation) | msg-seq | pad (zero-valued octets to reach 8-byte boundary). The checksum is computed over the entire structure with checksum field zeroed, then inserted before DES-CBC encryption.
Simplified-profile ciphertext is: C1 | H1[1..h], where C1 = E(Ke, conf | plaintext | pad, oldstate.ivec) and H1 = HMAC(Ki, conf | plaintext | pad). The confounder 'conf' is a random string of length c; padding brings confounder plus plaintext to a multiple of message block size m.