The Kerberos protocols described in this document are designed to use
stream encryption ciphers, which can be simulated using commonly
available block encryption ciphers, such as the Data Encryption
Standard [11], in conjunction with block chaining and checksum
methods [12]. 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 KDC uses the principal's secret key (in the AS exchange) or a
shared session key (in the TGS exchange) to encrypt responses to
ticket requests; the ability to obtain the secret key or session key
implies the knowledge of the appropriate keys and the identity of the
KDC. The ability of a principal to decrypt the KDC response and
present a Ticket and a properly formed Authenticator (generated with
the session key from the KDC response) to a service verifies the
identity of the principal; likewise the ability 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; however, in some cases, the order of
fields in the encrypted portions of messages are arranged to minimize
the effects of poorly chosen keys. It is still important to choose
good keys. If keys are derived from user-typed passwords, those
passwords need to be well chosen 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. The encodings, chaining, and padding
requirements for each are described. For encryption methods, it is
often desirable to place random information (often referred to as a
confounder) at the start of the message. The requirements for a
confounder are specified with each encryption mechanism.
Some encryption systems use a block-chaining method to improve the
the security characteristics of the ciphertext. However, these
chaining methods often don't provide an integrity check upon
decryption. Such systems (such as DES in CBC mode) must be augmented
with a checksum of the plaintext which 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, where 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 included. It is desirable for the string to key function to
be one-way, and for the mapping to be different in different realms.
This is important because users who are registered in more than one
realm will often use the same password in each, and it is desirable
that an attacker compromising the Kerberos server in one realm not
obtain or derive the user's key in another.
For a discussion of the integrity characteristics of the candidate
encryption and checksum methods considered for Kerberos, the the
reader is referred to [13].
