4. Encryption and Checksum Specifications
4. Encryption and Checksum Specifications
The Kerberos protocols described in this document are designed to encrypt messages of arbitrary sizes, using stream or block encryption ciphers. 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 to 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 to prove its knowledge thereof in a response verifies the identity of the service.
[RFC3961] defines a framework for defining encryption and checksum mechanisms for use with Kerberos. It also defines several such mechanisms, and more may be added in future updates to that document.
The string-to-key operation provided by [RFC3961] is used to produce a long-term key for a principal (generally for a user). The default salt string, if none is provided via pre-authentication data, is the concatenation of the principal's realm and name components, in order, with no separators. Unless it is indicated otherwise, the default string-to-key opaque parameter set as defined in [RFC3961] is used.
Encrypted data, keys, and checksums are transmitted using the EncryptedData, EncryptionKey, and Checksum data objects defined in Section 5.2.9. The encryption, decryption, and checksum operations described in this document use the corresponding encryption, decryption, and get_mic operations described in [RFC3961], with implicit "specific key" generation using the "key usage" values specified in the description of each EncryptedData or Checksum object to vary the key for each operation. Note that in some cases, the value to be used is dependent on the method of choosing the key or the context of the message.
Key usages are unsigned 32-bit integers; zero is not permitted. The key usage values for encrypting or checksumming Kerberos messages are indicated in Section 5 along with the message definitions. The key usage values 512-1023 are reserved for uses internal to a Kerberos implementation. (For example, seeding a pseudo-random number generator with a value produced by encrypting something with a session key and a key usage value not used for any other purpose.) Key usage values between 1024 and 2047 (inclusive) are reserved for application use; applications SHOULD use even values for encryption and odd values for checksums within this range. Key usage values are also summarized in a table in Section 7.5.1.
There might exist other documents that define protocols in terms of the RFC 1510 encryption types or checksum types. These documents would not know about key usages. In order that these specifications continue to be meaningful until they are updated, if no key usage values are specified, then key usages 1024 and 1025 must be used to derive keys for encryption and checksums, respectively. (This does not apply to protocols that do their own encryption independent of this framework, by directly using the key resulting from the Kerberos authentication exchange.) New protocols defined in terms of the Kerberos encryption and checksum types SHOULD use their own key usage values.
Unless it is indicated otherwise, no cipher state chaining is done from one encryption operation to another.
Implementation note: Although it is not recommended, some application protocols will continue to use the key data directly, even if only in currently existing protocol specifications. An implementation intended to support general Kerberos applications may therefore need to make key data available, as well as the attributes and operations described in [RFC3961]. One of the more common reasons for directly performing encryption is direct control over negotiation and selection of a "sufficiently strong" encryption algorithm (in the context of a given application). Although Kerberos does not directly provide a facility for negotiating encryption types between the
application client and server, there are approaches for using Kerberos to facilitate this negotiation. For example, a client may request only "sufficiently strong" session key types from the KDC and expect that any type returned by the KDC will be understood and supported by the application server.