Summary

  • RFC 3962 encoded the Kerberos AES password work factor in four big-endian octets: an explicit all-zero value meant 4,294,967,296 PBKDF2 iterations, while an absent field meant 4,096 only after the KDC had a chance to supply the parameter.
  • A high count could exhaust a client and a low one could cheapen an attacker’s password search, so the durable control was not one magic number but authenticated provenance, local bounds and separate receipts for derivation, preauthentication and authorization.

Suppose a Kerberos client receives four bytes that look like zero. A conventional parser might turn them into the integer zero, replace zero with a default, and continue. Another might discard the field as empty. Both would erase the distinction RFC 3962 took unusual care to preserve.

The parameter was an unsigned four-octet integer in big-endian order. Ordinarily that integer was the number of PBKDF2 iterations used to derive an AES key from a passphrase and salt. But the bit pattern 00 00 00 00 was assigned a special numerical meaning: 4,294,967,296 iterations, or (2^{32}). The minimum expressible count was therefore one, not zero.

Absence had a different meaning. If the string-to-key parameter field was not supplied after the KDC had an opportunity to provide it, the client used 00 00 10 00, decimal 4,096. This was not a general recommendation for realm databases and not the prescribed guess for optimistic preauthentication. It was only the interpretation of a missing field in that protocol context.

One field carried two kinds of state

This is a small piece of encoding design with a large systems consequence. The record needed at least two coordinates: whether the field was present and, if present, which four bytes it contained. A pipeline that normalized “missing,” zero and an empty buffer into one value could change the cost by a factor of 1,048,576.

RFC 3962 was published in February 2005 as the AES profile for Kerberos 5. It fitted AES into the cryptographic interface defined by RFC 3961: 128-bit blocks, 128- or 256-bit keys, ciphertext stealing for messages that did not align to a block, and HMAC-SHA1-96 for integrity. The assigned encryption types were 17 and 18; checksum types were 15 and 16. The current IANA Kerberos Parameters registry still records those identifiers and references, but a registry entry is not evidence that a realm enabled or selected them.

For password-derived keys, the profile applied PBKDF2 to the passphrase and salt to make a temporary key, then applied the RFC 3961 derivation operation with the constant kerberos. RFC 2898 supplied the contemporary PBKDF2 specification; RFC 8018 later republished the PKCS #5 family. A 256-bit output did not turn a human password into 256 bits of entropy. The iteration count could raise the cost of testing guesses, but it could not manufacture unpredictability that the password never had.

The attacker could turn the dial both ways

The work factor multiplied two people’s costs at once. Every extra PBKDF2 round slowed an offline attacker testing candidates, and it slowed the legitimate client deriving the correct key by the same factor. RFC 3962 described the count as useful primarily as a constant multiplier, not as an asymmetrical advantage.

That symmetry created two opposite spoofing attacks. If an intruder could forge a KDC response containing a very high count, the client might burn a great deal of CPU calculating the wrong key. The RFC allowed implementations to cap accepted counts to control this denial-of-service risk. If such a cap existed, it said the cap should be no lower than 50,000. Four billion rounds would still take a long time even on fast hardware, so an interruptible operation was prudent.

Turn the dial down and the threat changed direction. A forged response carrying a low count could coax the client into producing a reply derived with less work. An observer could then test password guesses more cheaply. The document therefore contemplated lower bounds as well as upper ones. The safe decision was a locally governed interval, not “largest is always strongest” and not “accept whatever the wire says.”

This makes provenance as important as magnitude. A log that records only iterations=4096 cannot show whether those bytes came from an authenticated KDC exchange, an unauthenticated error, cached site configuration, an absent-field rule or a test override. Nor does it show whether the client enforced its bounds before beginning the work. The same integer can be a legitimate policy choice, a compatibility fallback or an attacker-controlled input.

Optimism turned freshness into a configuration problem

Kerberos clients sometimes try optimistic preauthentication: derive a long-term key and send a protected timestamp before first asking the KDC for current parameters. It saves a round trip when the guess is right. Yet a client with no additional information can only guess the iteration count.

RFC 3962 rejected the tempting answer “remember the last one.” A count used for the same principal a few hours earlier could already be wrong, especially because sites were expected to increase counts as hardware improved. The document found no specific permanent default to recommend and instead pointed to site-local configuration, kept between the same lower and upper limits used for received values.

The historical point is not that 4,096, 50,000 or four billion is the correct figure today. Hardware, password distributions and acceptable latency move. The point is that a value with security and availability consequences had an owner, an observation time and an authenticity state. Optimism removed the fresh KDC observation, so another governance mechanism had to replace it.

Deriving a key was still not authenticating a user

Even when the parameter was parsed correctly and PBKDF2 completed, the result was only key material. RFC 4120 supplies the wider Kerberos ticket, authenticator, replay and protocol machinery. A string-to-key success does not prove that the password was correct, that a KDC accepted preauthentication, that a ticket is current, that the application authorized a request or that a service was delivered.

Later specifications preserved those separations. RFC 4537 distinguished offered encryption types from the type selected under server policy. RFC 6113 generalized preauthentication and the carriage of cryptographic parameters. RFC 8009 introduced AES-CTS/HMAC-SHA2 profiles, while RFC 8429 deprecated several older Kerberos algorithms. Each changed part of the chain; none made a registry number, work factor or successful key derivation equivalent to authority.

There was another, independent limit in the AES construction. Ciphertext stealing avoided padding expansion, which meant ciphertext length exposed exact plaintext length. Higher layers had to add their own obscuring data if length privacy mattered. More CPU did not repair that leakage. One control should never be credited with solving a different boundary.

An adequate operational record would therefore keep the field’s presence bit, exact octets, parsed count, source message and authenticity status, local bounds, selected encryption type, salt provenance, library version, time and resources consumed, interruption status and a non-secret derivation outcome. It would then record preauthentication, ticket, replay, application authorization and service outcome separately. Passwords and derived keys do not belong in the log.

The maintained specification record supports a careful reading. The RFC Editor information page and IETF Datatracker establish publication and status; the RFC 3962 errata search returned no matching entries at capture time. That absence is not a blanket guarantee about implementations. It is simply the state of one evidence ledger.

RFC 3962’s memorable number was not its most important lesson. The lesson was that “zero,” “absent” and “default” are three different claims. Once a protocol attaches millions—or billions—of operations to the difference, preserving that distinction becomes part of both security and availability.

Sources