|
|
| Previous | Table of Contents | Next |
Encryption Keys
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
}
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 (msg-seq) 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.
Checksums
The following structure is used for a checksum:
Checksum = {
cksumtype[0] INTEGER,
checksum[1] BYTE STRING
}
Negative values for the checksum type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations.
Kerberos supports a variety of checksums. In addition, specific implementations may also support implementation-specific checksums. The following sections describe the standard checksums supported by Kerberos. Selection of a specific checksum is up to the application providing the information.
Note: Kerberos uses checksums that can be classified by two properties: whether they’re collision-proof and whether they’re keyed.
A checksum is said to be collision-proof if finding two plaintexts that generate the same checksum value is infeasible. This means that it is not possible for someone to change a message in a manner that leaves the checksum unchanged. Any change to the message makes an unpredictable change to the checksum.
| Previous | Table of Contents | Next |