Request for Comments: 3961 MIT
Category: Standards Track February 2005
Encryption and Checksum Specifications
for Kerberos 5
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a framework for defining encryption and
checksum mechanisms for use with the Kerberos protocol, defining an
abstraction layer between the Kerberos protocol and related
protocols, and the actual mechanisms themselves. The document also
defines several mechanisms. Some are taken from RFC 1510, modified
in form to fit this new framework and occasionally modified in
content when the old specification was incorrect. New mechanisms are
presented here as well. This document does NOT indicate which
mechanisms may be considered "required to implement".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4
4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9
5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10
5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10
5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12
5.3. Cryptosystem Profile Based on Simplified Profile . . . 13
5.4. Checksum Profiles Based on Simplified Profile . . . . . 16
6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16
6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
6.2. DES-based Encryption and Checksum Types . . . . . . . . 18
6.3. Triple-DES Based Encryption and Checksum Types . . . . 28
7. Use of Kerberos Encryption Outside This Specification . . . . 30
8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31
9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43
A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
Informative References. . . . . . . . . . . . . . . . . . . . . . 48
Editor’s Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
1. Introduction
The Kerberos protocols [Kerb] are designed to encrypt messages of
arbitrary sizes, using block encryption ciphers or, less commonly,
stream encryption ciphers. Encryption is used to prove the
identities of the network entities participating in message
exchanges. However, nothing in the Kerberos protocol requires that
any specific encryption algorithm be used, as long as the algorithm
includes certain operations.
The following sections specify the encryption and checksum mechanisms
currently defined for Kerberos, as well as a framework for defining
future mechanisms. The encoding, chaining, padding, and other
requirements for each are described. Appendix A gives test vectors
for several functions.
2. Concepts
Both encryption and checksum mechanisms are profiled in later
sections. Each profile specifies a collection of operations and
attributes that must be defined for a mechanism. A Kerberos
encryption or checksum mechanism specification is not complete if it
does not define all of these operations and attributes.
An encryption mechanism must provide for confidentiality and
integrity of the original plaintext. (Incorporating a checksum may
permit integrity checking, if the encryption mode does not provide an
integrity check itself.) It must also provide non-malleability
[Bellare98] [Dolev91]. Use of a random confounder prepended to the
plaintext is recommended. It should not be possible to determine if
two ciphertexts correspond to the same plaintext without the key.
A checksum mechanism [1] must provide proof of the integrity of the
associated message and must preserve the confidentiality of the
message in case it is not sent in the clear. Finding two plaintexts
with the same checksum should be infeasible. It is NOT required that
an eavesdropper be unable to determine whether two checksums are for
the same message, as the messages themselves would presumably be
visible to any such eavesdropper.
Due to advances in cryptography, some cryptographers consider using
the same key for multiple purposes unwise. Since keys are used in
performing a number of different functions in Kerberos, it is
desirable to use different keys for each of these purposes, even
though we start with a single long-term or session key.
We do this by enumerating the different uses of keys within Kerberos
and by making the "usage number" an input to the encryption or
checksum mechanisms; such enumeration is outside the scope of this
document. Later sections define simplified profile templates for
encryption and checksum mechanisms that use a key derivation function
applied to a CBC mode (or similar) cipher and a checksum or hash
algorithm.
We distinguish the "base key" specified by other documents from the
"specific key" for a specific encryption or checksum operation. It
is expected but not required that the specific key be one or more
separate keys derived from the original protocol key and the key
usage number. The specific key should not be explicitly referenced
outside of this document. The typical language used in other
documents should be something like, "encrypt this octet string using
this key and this usage number"; generation of the specific key and
cipher state (described in the next section) are implicit. The
creation of a new cipher-state object, or the re-use of one from a
previous encryption operation, may also be explicit.
New protocols defined in terms of the Kerberos encryption and
checksum types should use their own key usage values. Key usages are
unsigned 32-bit integers; zero is not permitted.
All data is assumed to be in the form of strings of octets or eight-
bit bytes. Environments with other byte sizes will have to emulate
this behavior in order to get correct results.
Each algorithm is assigned an encryption type (or "etype") or
checksum type number, for algorithm identification within the
Kerberos protocol. The full list of current type number assignments
is given in section 8.
3. Encryption Algorithm Profile
An encryption mechanism profile must define the following attributes
and operations. The operations must be defined as functions in the
mathematical sense. No additional or implicit inputs (such as
Kerberos principal names or message sequence numbers) are permitted.
protocol key format
This describes which octet string values represent valid keys.
For encryption mechanisms that don’t have perfectly dense key
spaces, this will describe the representation used for encoding
keys. It need not describe invalid specific values; all key
generation routines should avoid such values.
specific key structure
This is not a protocol format at all, but a description of the
keying material derived from the chosen key and used to encrypt or
decrypt data or compute or verify a checksum. It may, for
example, be a single key, a set of keys, or a combination of the
original key with additional data. The authors recommend using
one or more keys derived from the original key via one-way key
derivation functions.
required checksum mechanism
This indicates a checksum mechanism that must be available when
this encryption mechanism is used. Since Kerberos has no built in
mechanism for negotiating checksum mechanisms, once an encryption
mechanism is decided, the corresponding checksum mechanism can be
used.
key-generation seed length, K
This is the length of the random bitstring needed to generate a
key with the encryption scheme’s random-to-key function (described
below). This must be a fixed value so that various techniques for
producing a random bitstring of a given length may be used with
key generation functions.
key generation functions
Keys must be generated in a number of cases, from different types
of inputs. All function specifications must indicate how to
generate keys in the proper wire format and must avoid generating
keys that significantly compromise the confidentiality of
encrypted data, if the cryptosystem has such. Entropy from each
source should be preserved as much as possible. Many of the
inputs, although unknown, may be at least partly predictable
(e.g., a password string is likely to be entirely in the ASCII
subset and of fairly short length in many environments; a semi-
random string may include time stamps). The benefit of such
predictability to an attacker must be minimized.
string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
This function generates a key from two UTF-8 strings and an opaque
octet string. One of the strings is usually the principal’s pass
phrase, but generally it is merely a secret string. The other
string is a "salt" string intended to produce different keys from
the same password for different users or realms. Although the
strings provided will use UTF-8 encoding, no specific version of
Unicode should be assumed; all valid UTF-8 strings should be
allowed. Strings provided in other encodings MUST first be
converted to UTF-8 before applying this function.
The third argument, the octet string, may be used to pass
mechanism-specific parameters into this function. Since doing so
implies knowledge of the specific encryption system, generating
non-default parameter values should be an uncommon operation, and
normal Kerberos applications should be able to treat this
parameter block as an opaque object supplied by the Key
Distribution Center or defaulted to some mechanism-specific
constant value.
The string-to-key function should be a one-way function so that
compromising a user’s key in one realm does not compromise it in
another, even if the same password (but a different salt) is used.
random-to-key (bitstring[K])->(protocol-key)
This function generates a key from a random bitstring of a
specific size. All the bits of the input string are assumed to be
equally random, even though the entropy present in the random
source may be limited.
key-derivation (protocol-key, integer)->(specific-key)
In this function, the integer input is the key usage value, as
described above. An attacker is assumed to know the usage values.
The specific-key output value was described in section 2.
string-to-key parameter format
This describes the format of the block of data that can be passed
to the string-to-key function above to configure additional
parameters for that function. Along with the mechanism of
encoding parameter values, bounds on the allowed parameters should
also be described to avoid allowing a spoofed KDC to compromise
the user’s password. If practical it may be desirable to
construct the encoding so that values unacceptably weakening the
resulting key cannot be encoded.
Local security policy might permit tighter bounds to avoid excess
resource consumption. If so, the specification should recommended
defaults for these bounds. The description should also outline
possible weaknesses if bounds checks or other validations are not
applied to a parameter string received from the network.
As mentioned above, this should be considered opaque to most
normal applications.
default string-to-key parameters (octet string)
This default value for the "params" argument to the string-to-key
function should be used when the application protocol (Kerberos or
other) does not explicitly set the parameter value. As indicated
above, in most cases this parameter block should be treated as an
opaque object.
cipher state
This describes any information that can be carried over from one
encryption or decryption operation to the next, for use with a
given specific key. For example, a block cipher used in CBC mode
may put an initial vector of one block in the cipher state. Other
encryption modes may track nonces or other data.
This state must be non-empty and must influence encryption so that
messages are decrypted in the same order they were a encrypted, if
the cipher state is carried over from one encryption to the next.
Distinguishing out-of-order or missing messages from corrupted
messages is not required. If desired, this can be done at a
higher level by including sequence numbers and not "chaining" the
cipher state between encryption operations.
The cipher state may not be reused in multiple encryption or
decryption operations. These operations all generate a new cipher
state that may be used for following operations using the same key
and operation.
The contents of the cipher state must be treated as opaque outside
of encryption system specifications.
initial cipher state (specific-key, direction)->(state)
This describes the generation of the initial value for the cipher
state if it is not being carried over from a previous encryption
or decryption operation.
This describes any initial state setup needed before encrypting
arbitrary amounts of data with a given specific key. The specific
key and the direction of operations to be performed (encrypt
versus decrypt) must be the only input needed for this
initialization.
This state should be treated as opaque in any uses outside of an
encryption algorithm definition.
IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
degree an application protocol could exercise control over the
initial vector used in DES CBC operations. Some existing
implementations permit setting the initial vector. This framework
does not provide for application control of the cipher state
(beyond "initialize" and "carry over from previous encryption"),
as the form and content of the initial cipher state can vary
between encryption systems and may not always be a single block of
random data.
New Kerberos application protocols should not assume control over
the initial vector, or that one even exists. However, a general-
purpose implementation may wish to provide the capability, in case
applications explicitly setting it are encountered.
encrypt (specific-key, state, octet string)->(state, octet string)
This function takes the specific key, cipher state, and a non-
empty plaintext string as input and generates ciphertext and a new
cipher state as outputs. If the basic encryption algorithm itself
does not provide for integrity protection (e.g., DES in CBC mode),
then some form of verifiable MAC or checksum must be included.
Some random factor such as a confounder should be included so that
an observer cannot know if two messages contain the same
plaintext, even if the cipher state and specific keys are the
same. The exact length of the plaintext need not be encoded, but
if it is not and if padding is required, the padding must be added
at the end of the string so that the decrypted version may be
parsed from the beginning.
The specification of the encryption function must indicate not
only the precise contents of the output octet string, but also the
output cipher state. The application protocol may carry the
output cipher state forward from one encryption with a given
specific key to another; the effect of this "chaining" must be
defined [2].
Assuming that values for the specific key and cipher state are
correctly-produced, no input octet string may result in an error
indication.
decrypt (specific-key, state, octet string)->(state, octet string)
This function takes the specific key, cipher state, and ciphertext
as inputs and verifies the integrity of the supplied ciphertext.
If the ciphertext’s integrity is intact, this function produces
the plaintext and a new cipher state as outputs; otherwise, an
error indication must be returned, and the data discarded.
The result of the decryption may be longer than the original
plaintext, as, for example, when the encryption mode adds padding
to reach a multiple of a block size. If this is the case, any
extra octets must come after the decoded plaintext. An
application protocol that needs to know the exact length of the
message must encode a length or recognizable "end of message"
marker within the plaintext [3].
As with the encryption function, a correct specification for this
function must indicate not only the contents of the output octet
string, but also the resulting cipher state.
pseudo-random (protocol-key, octet-string)->(octet-string)
This pseudo-random function should generate an octet string of
some size that is independent of the octet string input. The PRF
output string should be suitable for use in key generation, even
if the octet string input is public. It should not reveal the
input key, even if the output is made public.
These operations and attributes are all that is required to support
Kerberos and various proposed preauthentication schemes.
For convenience of certain application protocols that may wish to use
the encryption profile, we add the constraint that, for any given
plaintext input size, a message size must exist between that given
size and that size plus 65,535 such that the length of the decrypted
version of the ciphertext will never have extra octets at the end.
Expressed mathematically, for every message length L1, there exists a
message size L2 such that
L2 >= L1
L2 < L1 + 65,536
for every message M with |M| = L2, decrypt(encrypt(M)) = M
A document defining a new encryption type should also describe known
weaknesses or attacks, so that its security may be fairly assessed,
and should include test vectors or other validation procedures for
the operations defined. Specific references to information that is
readily available elsewhere are sufficient.
4. Checksum Algorithm Profile
A checksum mechanism profile must define the following attributes and
operations:
associated encryption algorithm(s)
This indicates the types of encryption keys this checksum
mechanism can be used with.
A keyed checksum mechanism may have more than one associated
encryption algorithm if they share the same wire-key format,
string-to-key function, default string-to-key-parameters, and key
derivation function. (This combination means that, for example, a
checksum type, key usage value, and password are adequate to get
the specific key used to compute a checksum.)
An unkeyed checksum mechanism can be used with any encryption
type, as the key is ignored, but its use must be limited to cases
where the checksum itself is protected, to avoid trivial attacks.
get_mic function
This function generates a MIC token for a given specific key (see
section 3) and message (represented as an octet string) that may
be used to verify the integrity of the associated message. This
function is not required to return the same deterministic result
for each use; it need only generate a token that the verify_mic
routine can check.
The output of this function will also dictate the size of the
checksum. It must be no larger than 65,535 octets.
verify_mic function
Given a specific key, message, and MIC token, this function
ascertains whether the message integrity has been compromised.
For a deterministic get_mic routine, the corresponding verify_mic
may simply generate another checksum and compare the two.
The get_mic and verify_mic operations must allow inputs of arbitrary
length; if any padding is needed, the padding scheme must be
specified as part of these functions.
These operations and attributes are all that should be required to
support Kerberos and various proposed preauthentication schemes.
As with encryption mechanism definition documents, documents defining
new checksum mechanisms should indicate validation processes and
known weaknesses.
5. Simplified Profile for CBC Ciphers with Key Derivation
The profile outlined in sections 3 and 4 describes a large number of
operations that must be defined for encryption and checksum
algorithms to be used with Kerberos. Here we describe a simpler
profile that can generate both encryption and checksum mechanism
definitions, filling in uses of key derivation in appropriate places,
providing integrity protection, and defining multiple operations for
the cryptosystem profile based on a smaller set of operations. Not
all of the existing cryptosystems for Kerberos fit into this
simplified profile, but we recommend that future cryptosystems use it
or something based on it [4].
Not all the operations in the complete profiles are defined through