Encryption Keys & Encryption Systems

Kerberos maintains a database of active encryption keys. The following structure shows the encoding of an encryption key:

EncryptionKey =

{

keytype[0] INTEGER,

keyvalue[1] BYTE STRING

}

• keytype. Specifies the type of encryption key that follows in the keyvalue field. It almost always corresponds to the encryption algorithm used to generate the encrypted data, though more than one algorithm may use the same type of key (the mapping is many to one). This might happen, for example, if the encryption algorithm uses an alternative checksum algorithm for an integrity check or a different chaining mechanism.
• keyvalue. Contains the key itself, encoded as a byte string.

All negative values for the encryption key type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations.

Encryption Systems

Kerberos defines a number of encryption systems that may be selected for use in a message. In addition, it also provides a mechanism for a developer to add his own encryption method. When a principal sends a message using an encryption method, the destination principal must also support the encryption method. If it doesn’t, an error message will be returned.

The NULL Encryption System (null)

If no encryption is in use, the encryption system is said to be a NULL encryption system. A NULL encryption system has no checksum, confounder, or padding. The ciphertext simply is the plaintext. The NULL encryption system uses the NULL key, which is zero bytes in length and has keytype zero (0).

DES in CBC Mode with a CRC-32 Checksum (des-cbc-crc)

The des-cbc-crc encryption mode encrypts information under the Data Encryption Standard using the Cipher Block Chaining (CBC) mode. A CRC-32 checksum is applied to the confounder and message sequence and placed in the checksum field. The details of the encryption of this data are identical to those for the des-cbc-md5 encryption mode.

Because the CRC-32 checksum is not collision-proof, different messages can be generated having the same checksum. An attacker could use a probabilistic chosen plaintext attack to generate a valid message, even in the face of a confounder. Using collision-proof checksums is recommended for environments in which such attacks represent a significant threat. Any time the message will pass through a hostile environment, such as the Internet, or any time the message has great value, as in financial transactions, a collision-proof checksum should be used.

Note:  Using the CRC-32 as the checksum for ticket or authenticator no longer is mandated as an interoperability requirement for Kerberos version 5 Specification 1.

DES in CBC Mode with an MD4 Checksum (des-cbc-md4)

The des-cbc-md4 encryption mode encrypts information under DES using the Cipher Block Chaining mode. An MD4 checksum is applied to the confounder and message sequence (msgseq) and placed in the cksum field. The details of the encryption of this data are identical to those for the des-cbc-md5 encryption mode.

DES in CBC Mode with an MD5 Checksum (des-cbc-md5)

The des-cbc-md5 encryption mode encrypts information under the Data Encryption Standard using the Cipher Block Chaining mode. An MD5 checksum is applied to the confounder and message sequence and placed in the cksum field.

Plaintext and DES ciphertext are encoded as 8-byte blocks that are concatenated to make the 64-bit inputs for the DES algorithms. As a result, the data to be encrypted must be padded to an 8-byte boundary before encryption. Encryption under DES using Cipher Block Chaining requires an additional input in the form of an initialization vector. Unless otherwise specified, zero should be used as the initialization vector. Kerberos’ use of DES requires an 8-byte confounder.

The DES specifications identify some weak and semi-weak keys. Those keys are not to be used for encrypting Kerberos messages. Because of the way that keys are derived for the encryption of checksums, keys shall not be used that yield weak or semi-weak keys when eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.

A DES key is 8-bytes of data, with keytype one (1). This consists of 56 bits of key, and 8 parity bits (one per byte). To generate a DES key from a password, the password normally must have the Kerberos realm name and each component of the principal’s name appended, then padded with ASCII nulls to an 8-byte boundary. This string is then fan-folded and eXclusive-ORed with itself to form an 8-byte DES key. The parity is corrected on the key, and it is used to generate a DES-CBC checksum on the initial string (with the realm and name appended). Next, parity is corrected on the CBC checksum. If the result matches a “weak” or “semi-weak” key as described in the DES specification, it is eXclusive-ORed with the constant 00000000000000F0. Finally, the result is returned as the key.