Encryption Specifications

The following structure describes all encrypted messages. The encrypted field that appears in the unencrypted part of messages is a sequence that consists of an encryption type, an optional key version number, and the ciphertext.

EncryptedData = 

{

etype[0] INTEGER -- Encryption Type

kvno[1] INTEGER OPTIONAL,

cipher[2] BYTE STRING -- ciphertext

}

• etype. Identifies the encryption algorithm used to encrypt the cipher.
• kvno. Contains the version number of the key under which data is encrypted. Present in messages encrypted under long-lasting keys, such as principals’ secret keys. Used to determine which key to use when a ticket is valid across a change in key, such as when a user changes his password.
• cipher. Contains the encrypted field(s).

The cipher field is generated by applying the specified encryption algorithm to data composed of the message and algorithm-specific inputs. Encryption mechanisms defined for use with Kerberos must take sufficient measures to guarantee the integrity of the plaintext. The protections often can be enhanced by adding a checksum and a confounder.

The suggested format for the data to be encrypted includes a confounder, a checksum, the encoded plaintext, and any necessary padding. The msg-seq field contains the part of the protocol message that is to be encrypted. The format for the data to be encrypted is described in the following:

{

confounder[0] BYTE STRING(conf_length) OPTIONAL,

check[1] BYTE STRING(checksum_length) OPTIONAL,

msg-seq[2] MsgSequence,

pad BYTE STRING(pad_length) OPTIONAL

}

The first step is to create a confounder. The confounder is a random sequence the same length as the encryption blocking length. Its purpose is to confuse or confound certain types of brute force attacks. The second step is to zero out the checksum. Next, calculate the appropriate checksum over confounder, the zeroed checksum, and the message. Place the result in the checksum. Add the necessary padding to bring the total length to a multiple of the encryption blocking length. Encrypt using the specified encryption type and the appropriate key.

Unless otherwise specified, a definition of a Kerberos encryption algorithm uses this ciphertext format. The ordering of the fields in the ciphertext is important. Additionally, messages encoded in this format must include a length as part of the message field, to enable the recipient to verify that the message has not been truncated. Without a length, an attacker could generate a message that could be truncated, leaving the checksum intact.

To enable all implementations using a particular encryption type to communicate with all others using that type, the specification of an encryption type defines any checksum needed as part of the encryption process. If an alternative checksum is to be used, a new encryption type must be defined.

Some encryption systems require additional information beyond the key and the data to be encrypted. When DES is used in Cipher Block Chaining mode, for example, it requires an initialization vector. If required, the description for each encryption type must specify the source of such additional information.