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.
