Encryption and Checksum Specifications

The Kerberos protocols described in the RFC are designed to use stream encryption ciphers, such as the Data Encryption Standard (DES), in conjunction with block chaining and checksum methods. Encryption is used to prove the identities of the network entities participating in message exchanges. The Key Distribution Center for each realm is trusted by all principals registered in that realm to store a secret key in confidence. Proof of knowledge of this secret key is used to verify the authenticity of a principal.

The Key Distribution Center uses the principal’s secret key (in the Authentication Server exchange) or a shared session key (in the Ticket Granting Server exchange) to encrypt responses to ticket requests. The capability to obtain the secret key or session key implies knowing the appropriate keys and the identity of the Key Distribution Center. The capability of a principal to decrypt the Key Distribution Center response and present a ticket and a properly formed authenticator (generated with the session key from the Key Distribution Center response) to a service verifies the identity of the principal. Likewise, the capability of the service to extract the session key from the ticket and prove its knowledge thereof in a response verifies the identity of the service.

The Kerberos protocols generally assume that the encryption used is secure from cryptanalysis. Sometimes, though, the order of fields in the encrypted portions of messages is arranged to minimize the effects of poorly chosen keys. Choosing good keys still is important. If keys are derived from user-typed passwords, those passwords need to be chosen well to make brute force attacks more difficult. Poorly chosen keys still make easy targets for intruders.

The following sections specify the encryption and checksum mechanisms currently defined for Kerberos and describe the encoding, chaining, and padding requirements for each. For encryption methods, placing random information (often referred to as a confounder) at the start of the message is often a good idea. The requirements for a confounder are specified along with each encryption mechanism.

Some encryption systems use a block-chaining method to improve the security characteristics of the ciphertext. These chaining methods often don’t provide an integrity check upon decryption. Such systems (such as DES in Cipher Block Chaining mode) must be augmented using a checksum of the plaintext that can be verified at decryption and used to detect any tampering or damage. Such checksums should be good at detecting burst errors in the input. If any damage is detected, the decryption routine is expected to return an error indicating the failure of an integrity check. Each encryption type is expected to provide and verify an appropriate checksum. The specification of each encryption method sets out its checksum requirements.

Finally, if a key is to be derived from a user’s password, an algorithm for converting the password to a key of the appropriate type is required. The string-to-key function ideally should be one-way and mapping should be different in different realms, because users registered in more than one realm often use the same password in each. An attacker compromising the Kerberos server in one realm should not be able to just obtain or derive the user’s key in another realm.