Summary

  • RFC 3961 made a non-zero key-usage number part of Kerberos encryption and checksum operations, so one base key did not become an undifferentiated capability across message types and protocol roles.
  • In its simplified profile, the usage number helped derive separate checksum, encryption and integrity keys; a valid result proved consistency with that cryptographic context, not the user’s authority or the application’s eventual action.

Imagine two sealed envelopes produced from the same session key. One is meant to authenticate a request; the other protects a reply. If the cipher sees only “key plus bytes,” the distinction between those jobs exists outside the cryptographic calculation. A message accepted in one place may become useful in another place that shares the key.

RFC 3961, published in February 2005, put the job description into the calculation. Kerberos specifications would assign a key-usage number to each operation. Encryption and checksum mechanisms would take that number as an input. The number was public, unsigned, 32 bits wide and never zero. Its value was not secrecy. Its value was context.

That move was part of a larger separation. The RFC distinguished the protocol key—the long-term or session key named by another Kerberos document—from the specific material used for one cryptographic operation. Other specifications could say “encrypt these octets with this key and this usage number” without reaching inside a cipher’s IV, checksum, padding or derived-key structure. The application named the purpose; the profile determined how the purpose changed the cryptographic work.

An encryption type was not a complete answer

The RFC’s title sounds like an algorithm catalogue, and it did assign encryption and checksum type numbers. But its durable contribution was a contract. A conforming encryption profile had to define the wire-key format, string-to-key and random-to-key functions, derivation, cipher state, encryption, integrity behavior and pseudorandom function. A checksum profile had to say which keys it could use and how MIC generation and verification worked. The document warned that a mechanism was incomplete if any required operation or attribute was missing.

This matters because an etype is only an identifier for such a profile. It does not say that a client implemented the profile, that a server enabled it, that a KDC selected it, or that the resulting exchange authorized anything. The current IANA Kerberos Parameters registry preserves assigned numbers and references. It is a ledger of names, not a deployment map.

The distinction became operationally visible in RFC 4537. That extension let a client offer encryption types in preference order and a server select one under local policy, possibly creating a new subkey. An assigned type, an offered type and a selected type are three separate records. Even a negotiated stronger type was protected by the earlier session key, so breaking the weaker protection could expose the stronger subkey. “Supported” was not “used,” and “used” was not “secure in every surrounding condition.”

Five bytes made three different jobs

RFC 3961’s simplified profile made the separation concrete. It encoded the four-byte usage number in big-endian order and added a one-byte constant. From the same base key it derived Kc with usage | 0x99 for standalone checksums, Ke with usage | 0xAA for encryption, and Ki with usage | 0x55 for the encrypted message’s integrity check.

The result was not merely three variable names. The base key was supposed to serve only as derivation material. A derived key compromised in one role should not reveal the others. A request protected under one usage should not automatically be valid as a reply or as a field in another protocol exchange. The protocol’s semantic boundary became an input to the cryptographic boundary.

RFC 3961 explained why this mattered with a historical failure mode. Some software used the same keys for Kerberos versions 4 and 5. Version 4 could act as an encryption oracle for attacks on version 5. Random confounders reduced the usefulness of predictable plaintext, while purpose-specific derivation limited the damage caused by treating one key as universal. The document did not report a named incident; it described the attack surface that the framework was built to narrow.

Verification remained a local receipt

On decryption, the profile verified integrity and discarded data when verification failed. That is a meaningful result, but it is not the whole Kerberos decision. It says that ciphertext, derived key, usage context and integrity tag agree. It does not independently identify the principal to whom the base key belongs, show that the caller selected the usage mandated by the protocol, prove freshness, defeat replay, authorize an application action or establish that a service was delivered.

Those joins live above the primitive. RFC 4120 defines the Kerberos V5 protocol, ticket and authenticator semantics; it obsoleted the older RFC 1510, from which RFC 3961 drew and separated earlier cryptographic material. RFC 6113 later used the framework for generalized preauthentication. None of these layers makes the next layer’s decision disappear.

The clean audit record therefore has more than “decrypt succeeded.” It joins the message type, selected etype, key version or non-secret key reference, exact usage number and the clause assigning it, protected-object hash, library version, integrity result, replay and freshness checks, ticket result, application authorization and observed service outcome. Secret key bytes do not belong in that record.

The abstraction outlived its first recommendations

The framework was designed to survive algorithm change. RFC 3962 placed AES types inside it. RFC 6649 later deprecated single DES, and RFC 8429 updated RFC 3961 while deprecating more old cryptography. Those documents changed the acceptable algorithm set; they did not make a registry entry proof that every realm had migrated.

More revealingly, RFC 8009 said its AES-CTS/HMAC-SHA2 mechanisms conformed to the broader RFC 3961 framework but did not use the simplified profile. Modern practice called for authenticating ciphertext before decryption, so a later profile replaced the construction while retaining the abstraction. The interface endured because it had not confused one cipher design with Kerberos itself.

The maintained record also resists easy mythology. The RFC Editor information page and IETF Datatracker history establish publication and status. The errata record contains a verified Unicode code-point correction, a held technical correction to old DES key generation, and a rejected proposal whose verifier distinguished a required checksum operation from the checksum embedded in encryption. Errata status is evidence about the specification record, not evidence of a production outage.

RFC 3961’s historical lesson is smaller and more durable than “Kerberos used strong cryptography.” It taught protocols to state which job a key was performing and to make that statement affect the derived key. The number did not confer authority. It prevented authority contexts from silently collapsing into one cryptographic bucket.

Sources