diff --git a/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt b/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt new file mode 100644 index 000000000..b1bee6fa4 --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt @@ -0,0 +1,2690 @@ + + + + + + + + + +INTERNET DRAFT K. Raeburn +Kerberos Working Group MIT +Document: draft-ietf-krb-wg-crypto-03.txt February 24, 2003 + expires August 24, 2003 + + Encryption and Checksum Specifications + for Kerberos 5 + +Abstract + + This document describes a framework for defining encryption and + checksum mechanisms for use with the Kerberos protocol [Kerb], + defining an abstraction layer between the Kerberos protocol and + related protocols, and the actual mechanisms themselves. Several + mechanisms are also defined in this document. 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". + + Comments should be sent to the editor, or to the IETF Kerberos + working group (ietf-krb-wg@anl.gov). + +Status + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts + are working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be updated, + replaced, or obsoleted by other documents at any time. It is + inappropriate to use Internet-Drafts as reference material or to cite + them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.html. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + + + + + +Raeburn [Page 1] + +INTERNET DRAFT February 2003 + + + Table of Contents + + +Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 +Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 +Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 +Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 +1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 +2. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 +3. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9 +4. Simplified profile for CBC ciphers with key derivation . . . . . 10 +4.1. A key derivation function . . . . . . . . . . . . . . . . . . . 10 +4.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 12 +4.3. Cryptosystem profile based on simplified profile . . . . . . . 14 +4.4. Checksum profiles based on simplified profile . . . . . . . . . 16 +5. Profiles for Kerberos encryption and checksum algorithms . . . . 16 +5.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 16 +5.2. DES-based encryption and checksum types . . . . . . . . . . . . 18 +5.3. Triple-DES based encryption and checksum types . . . . . . . . 28 +6. Use of Kerberos encryption outside this specification . . . . . . 30 +7. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 +8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 32 +9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 33 +10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34 +11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 35 +12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . . 35 +13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 36 +A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 +A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 +A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 38 +A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 42 +A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 43 +A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 44 +B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 44 +Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 +Normative References . . . . . . . . . . . . . . . . . . . . . . . . 46 +Informative References . . . . . . . . . . . . . . . . . . . . . . . 48 + + + + + + + + + + + + + + +Raeburn [Page 2] + +INTERNET DRAFT February 2003 + + +Introduction + + The Kerberos protocols 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 any specific encryption + algorithm be used, as long as certain operations are available in the + algorithm that is used. + + 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. Test vectors for several + functions are given in appendix A. + +1. Concepts + + Both encryption and checksum mechanisms are defined in terms of + profiles, detailed in later sections. Each 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. (Integrity checking may be + achieved by incorporating a checksum, 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 knowledge of 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. It should be infeasible + to find two plaintexts which have the same checksum. It is NOT + required that an eavesdropper be unable to determine if two checksums + are for the same message; it is assumed that the messages themselves + will be visible to any such eavesdropper. + + Due to advances in cryptography, it is considered unwise by some + cryptographers to use the same key for multiple purposes. 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. + + + + +Raeburn [Page 3] + +INTERNET DRAFT February 2003 + + + We do this by enumerating the different uses of keys within Kerberos, + and making the "usage number" an input to the encryption or checksum + mechanisms; this enumeration is outside the scope of this document. + Later sections of this document 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" to be used for a particular instance of encryption or + checksum operations. It is expected but not required that the + specific key will 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 8-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 7. + +2. 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 what 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 specific values that are not valid or desirable + for use; such values should be avoid by all key generation + routines. + + + +Raeburn [Page 4] + +INTERNET DRAFT February 2003 + + + 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 + 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 has been decided upon, the corresponding checksum + mechanism can simply 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 generation + of 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, while 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 timestamps); 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 normally the + principal's pass phrase, but is in general 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. While the strings provided will use UTF-8 + encoding, no specific version of Unicode should be assumed; all + valid UTF-8 strings should be allowed. + + The third argument, the octet string, may be used to pass + mechanism-specific parameters in to this function. Since doing + + + +Raeburn [Page 5] + +INTERNET DRAFT February 2003 + + + so implies knowledge of the specific encryption system, it is + intended that generating non-default parameter values be an + uncommon operation, and that normal Kerberos applications be + able to treat this parameter block as an opaque object supplied + by the KDC or defaulted to some mechanism-specific constant + value. + + This should be a one-way function, so that compromising a + user's key in one realm does not compromise the user's key in + another realm, 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 bit string of a + specific size. It may be assumed that all the bits of the + input string are 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; the usage values must be assumed to be known + to an attacker. The specific-key output value was described in + section 1. + + 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. It may be desirable to construct the + encoding such that values weakening the resulting key unacceptably + cannot be encoded, if practical. + + Tighter bounds might be permitted by local security policy, or to + avoid excess resource consumption; if so, recommended defaults for + those bounds should be given in the specification. The + description should also outline possible weaknesses that may be + caused by not applying bounds checks or other validation 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 is to be used when the application protocol (Kerberos or + otherwise) does not explicitly set the parameter value. As + + + +Raeburn [Page 6] + +INTERNET DRAFT February 2003 + + + indicated above, this parameter block should be treated as an + opaque object in most cases. + + cipher state + This describes any information that can be carried over from one + encryption or decryption operation to the next, for use in + conjunction 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 as + to require that messages be decrypted in the same order they were + 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 the setting of the initial vector. This + new specification does not permit application control of the + cipher state (beyond "initialize" and "carry over from previous + encryption"), since the form and content of the initial cipher + + + +Raeburn [Page 7] + +INTERNET DRAFT February 2003 + + + state can vary between encryption systems, and may not always be a + single block of random data. + + New Kerberos application protocols should not assume that they can + control 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 (as DES in CBC + mode does not do), then some form of MAC or checksum must be + included that can be verified by the receiver. 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 not only + indicate the precise contents of the output octet string, but also + the output cipher state. The application protocol may carry + forward the output cipher state from one encryption with a given + specific key to another; the effect of this "chaining" must be + defined. [2] + + Assuming correctly-produced values for the specific key and cipher + state, 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, for example if the encryption mode adds padding to + reach a multiple of a block size. If this is the case, any extra + octets must be after the decoded plaintext. An application + protocol which 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 + + + +Raeburn [Page 8] + +INTERNET DRAFT February 2003 + + + 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 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 should be required to + support Kerberos and various proposed preauthentication schemes. + + 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 readily + available elsewhere are sufficient. + +3. 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, 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 in conjunction with any + encryption type, since 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 2), 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 + on every use; it need only generate a token that the verify_mic + routine can check. + + + + +Raeburn [Page 9] + +INTERNET DRAFT February 2003 + + + The output of this function will also dictate the size of the + checksum. + + 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 them. + + The get_mic and verify_mic operations must be able to handle 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. + +4. Simplified profile for CBC ciphers with key derivation + + The profile outlines in sections 2 and 3 describes a large number of + operations that must be defined for encryption and checksum + algorithms to be used with Kerberos. We describe here a simpler + profile from which both encryption and checksum mechanism definitions + can be generated, 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 given in the simplified profile. 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 of the operations in the complete profiles are defined + through this mechanism; several must still be defined for each new + algorithm pair. + +4.1. A key derivation function + + Rather than define some scheme by which a "protocol key" is composed + of a large number of encryption keys, we use keys derived from a base + key to perform cryptographic operations. The base key must be used + only for generating the derived keys, and this derivation must be + non-invertible and entropy-preserving. Given these restrictions, + compromise of one derived key does not compromise the other subkeys. + Attack of the base key is limited, since it is only used for + derivation, and is not exposed to any user data. + + + +Raeburn [Page 10] + +INTERNET DRAFT February 2003 + + + Since the derived key has as much entropy as the base keys (if the + cryptosystem is good), password-derived keys have the full benefit of + all the entropy in the password. + + To generate a derived key from a base key, we generate a pseudorandom + octet string, using an algorithm DR described below, and generate a + key from that octet string using a function dependent on the + encryption algorithm; the input length needed for that function, + which is also dependent on the encryption algorithm, dictates the + length of the string to be generated by the DR algorithm (the value + "k" below). These procedures are based on the key derivation in + [Blumenthal96]. + + Derived Key = DK(Base Key, Well-Known Constant) + + DK(Key, Constant) = random-to-key(DR(Key, Constant)) + + DR(Key, Constant) = k-truncate(E(Key, Constant, + initial-cipher-state)) + + Here DR is the random-octet generation function described below, and + DK is the key-derivation function produced from it. In this + construction, E(Key, Plaintext, CipherState) is a cipher, Constant is + a well-known constant determined by the specific usage of this + function, and k-truncate truncates its argument by taking the first k + bits. Here, k is the key generation seed length needed for the + encryption system. + + The output of the DR function is a string of bits; the actual key is + produced by applying the cryptosystem's random-to-key operation on + this bitstring. + + If the Constant is smaller than the cipher block size of E, then it + must be expanded with n-fold() so it can be encrypted. If the output + of E is shorter than k bits it is fed back into the encryption as + many times as necessary. The construct is as follows (where | + indicates concatentation): + + K1 = E(Key, n-fold(Constant), initial-cipher-state) + K2 = E(Key, K1, initial-cipher-state) + K3 = E(Key, K2, initial-cipher-state) + K4 = ... + + DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) + + n-fold is an algorithm which takes m input bits and ``stretches'' + them to form n output bits with equal contribution from each input + bit to the output, as described in [Blumenthal96]: + + + +Raeburn [Page 11] + +INTERNET DRAFT February 2003 + + + We first define a primitive called n-folding, which takes a + variable-length input block and produces a fixed-length output + sequence. The intent is to give each input bit approximately + equal weight in determining the value of each output bit. Note + that whenever we need to treat a string of octets as a number, the + assumed representation is Big-Endian -- Most Significant Byte + first. + + To n-fold a number X, replicate the input value to a length that + is the least common multiple of n and the length of X. Before + each repetition, the input is rotated to the right by 13 bit + positions. The successive n-bit chunks are added together using + 1's-complement addition (that is, with end-around carry) to yield + a n-bit result.... + + + Test vectors for n-fold are supplied in Appendix A. [5] + + In this section, n-fold is always used to produce c bits of output, + where c is the cipher block size of E. + + The size of the Constant must not be larger than c, because reducing + the length of the Constant by n-folding can cause collisions. + + If the size of the Constant is smaller than c, then the Constant must + be n-folded to length c. This string is used as input to E. If the + block size of E is less than the random-to-key input size, then the + output from E is taken as input to a second invocation of E. This + process is repeated until the number of bits accumulated is greater + than or equal to the random-to-key input size. When enough bits have + been computed, the first k are taken as the random data used to + create the key with the algorithm-dependent random-to-key function. + + Since the derived key is the result of one or more encryptions in the + base key, deriving the base key from the derived key is equivalent to + determining the key from a very small number of plaintext/ciphertext + pairs. Thus, this construction is as strong as the cryptosystem + itself. + +4.2. Simplified profile parameters + + These are the operations and attributes that must be defined: + + + + + + + + + +Raeburn [Page 12] + +INTERNET DRAFT February 2003 + + + protocol key format + string-to-key function + default string-to-key parameters + key-generation seed length, k + random-to-key function + As above for the normal encryption mechanism profile. + + unkeyed hash algorithm, H + This should be a collision-resistant hash algorithm with fixed- + size output, suitable for use in an HMAC [HMAC]. It must support + inputs of arbitrary length. Its output must be at least the + message block size (below). + + HMAC output size, h + This indicates the size of the leading substring output by the + HMAC function that should be used in transmitted messages. It + should be at least half the output size of the hash function H, + and at least 80 bits; it need not match the output size. + + message block size, m + This is the size of the smallest units the cipher can handle in + the mode in which it is being used. Messages will be padded to a + multiple of this size. If a block cipher is used in a mode that + can handle messages that are not multiples of the cipher block + size, such as CBC mode with cipher text stealing (CTS, see [RC5]), + this value would be one octet. For traditional CBC mode with + padding, it will be the underlying cipher's block size. + + This value must be a multiple of 8 bits (one octet). + + encryption/decryption functions, E and D + These are basic encryption and decryption functions for messages + of sizes that are multiples of the message block size. No + integrity checking or confounder should be included here. These + functions take as input the IV or similar data, a protocol-format + key, and a octet string, returning a new IV and octet string. + + The encryption function is not required to use CBC mode, but is + assumed to be using something with similar properties. In + particular, prepending a cipher-block-size confounder to the + plaintext should alter the entire ciphertext (comparable to + choosing and including a random initial vector for CBC mode). + + The result of encrypting one cipher block (of size c, above) must + be deterministic, for the random octet generation function DR in + the previous section to work. For best security, it should also + be no larger than c. + + + + +Raeburn [Page 13] + +INTERNET DRAFT February 2003 + + + cipher block size, c + This is the block size of the block cipher underlying the + encryption and decryption functions indicated above, used for key + derivation and for the size of the message confounder and initial + vector. (If a block cipher is not in use, some comparable + parameter should be determined.) It must be at least 5 octets. + + This is not actually an independent parameter; rather, it is a + property of the functions E and D. It is listed here to clarify + the distinction between it and the message block size, m. + + While there are still a number of properties to specify, they are + fewer and simpler than in the full profile. + +4.3. Cryptosystem profile based on simplified profile + + The above key derivation function is used to produce three + intermediate keys. One is used for computing checksums of + unencrypted data. The other two are used for encrypting and + checksumming plaintext to be sent encrypted. + + The ciphertext output is the concatenation of the output of the basic + encryption function E and a (possibly truncated) HMAC using the + specified hash function H, both applied to the plaintext with a + random confounder prefix and sufficient padding to bring it to a + multiple of the message block size. When the HMAC is computed, the + key is used in the protocol key form. + + Decryption is performed by removing the (partial) HMAC, decrypting + the remainder, and verifying the HMAC. The cipher state is an + initial vector, initialized to zero. + + The substring notation "[1..h]" in the following table should be read + as using 1-based indexing; leading substrings are used. + + + cryptosystem from simplified profile +---------------------------------------------------------------------------- +protocol key format As given. + +specific key structure Three protocol-format keys: { Kc, Ke, Ki }. + +key-generation seed As given. +length + +required checksum As defined below in section 4.4. +mechanism + + + + +Raeburn [Page 14] + +INTERNET DRAFT February 2003 + + + cryptosystem from simplified profile +---------------------------------------------------------------------------- + +cipher state initial vector (usually of length c) + +initial cipher state all bits zero + +encryption function conf = random string of length c + pad = shortest string to bring confounder + and plaintext to a length that's a + multiple of m + C1 = E(Ke, conf | plaintext | pad, + oldstate.ivec) + H1 = HMAC(Ki, conf | plaintext | pad) + ciphertext = C1 | H1[1..h] + newstate.ivec = last c of C1 + +decryption function (C1,H1) = ciphertext + P1 = D(Ke, C1, oldstate.ivec) + if (H1 != HMAC(Ki, P1)[1..h]) + report error + newstate.ivec = last c of C1 + +default string-to-key As given. +params + +pseudo-random function tmp1 = H(octet-string) + tmp2 = truncate tmp1 to multiple of m + PRF = E(protocol-key, tmp2, initial-cipher-state) + +key generation functions: + +string-to-key function As given. + +random-to-key function As given. + +key-derivation function The "well-known constant" used for the DK + function is the key usage number, expressed as + four octets in big-endian order, followed by one + octet indicated below. + + Kc = DK(base-key, usage | 0x99); + Ke = DK(base-key, usage | 0xAA); + Ki = DK(base-key, usage | 0x55); + + + + + + + +Raeburn [Page 15] + +INTERNET DRAFT February 2003 + + +4.4. Checksum profiles based on simplified profile + + When an encryption system is defined using the simplified profile + given in section 4.2, a checksum algorithm may be defined for it as + follows: + + + checksum mechanism from simplified profile + -------------------------------------------------- + associated cryptosystem as defined above + + get_mic HMAC(Kc, message)[1..h] + + verify_mic get_mic and compare + + The HMAC function and key Kc are as described in section 4.3. + +5. Profiles for Kerberos encryption and checksum algorithms + + These profiles describe the encryption and checksum systems defined + for Kerberos. The astute reader will notice that some of them do not + fulfull all of the requirements outlined in previous sections. These + systems are defined for backward compatibility; newer implementations + should (whenever possible) attempt to make use of encryption systems + which satisfy all of the profile requirements. + + The full list of current encryption and checksum type number + assignments, including values currently reserved but not defined in + this document, is given in section 7. + +5.1. Unkeyed checksums + + These checksum types use no encryption keys, and thus can be used in + combination with any encryption type, but may only be used with + caution, in limited circumstances where the lack of a key does not + provide a window for an attack, preferably as part of an encrypted + message. [6] Keyed checksum algorithms are recommended. + +5.1.1. The RSA MD5 Checksum + + The RSA-MD5 checksum calculates a checksum using the RSA MD5 + algorithm [MD5-92]. The algorithm takes as input an input message of + arbitrary length and produces as output a 128-bit (16 octet) + + + + + + + + +Raeburn [Page 16] + +INTERNET DRAFT February 2003 + + + checksum. RSA-MD5 is believed to be collision-proof. + + rsa-md5 + ---------------------------------------------- + associated cryptosystem any + + get_mic rsa-md5(msg) + + verify_mic get_mic and compare + + The rsa-md5 checksum algorithm is assigned a checksum type number of + seven (7). + +5.1.2. The RSA MD4 Checksum + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 + algorithm [MD4-92]. The algorithm takes as input an input message of + arbitrary length and produces as output a 128-bit (16 octet) + checksum. RSA-MD4 is believed to be collision-proof. + + + rsa-md4 + ---------------------------------------------- + associated cryptosystem any + + get_mic md4(msg) + + verify_mic get_mic and compare + + + The rsa-md4 checksum algorithm is assigned a checksum type number of + two (2). + +5.1.3. CRC-32 Checksum + + This CRC-32 checksum calculates a checksum based on a cyclic + redundancy check as described in ISO 3309 [CRC], modified as + described below. The resulting checksum is four (4) octets in + length. The CRC-32 is neither keyed nor collision-proof; thus, the + use of this checksum is not recommended. An attacker using a + probabilistic chosen-plaintext attack as described in [SG92] might be + able to generate an alternative message that satisfies the checksum. + + The CRC-32 checksum used in the des-cbc-crc encryption mode is + identical to the 32-bit FCS described in ISO 3309 with two + exceptions: the sum with the all-ones polynomial times x**k is + omitted, and the final remainder is not ones-complemented. ISO 3309 + describes the FCS in terms of bits, while this document describes the + + + +Raeburn [Page 17] + +INTERNET DRAFT February 2003 + + + Kerberos protocol in terms of octets. To disambiguate the ISO 3309 + definition for the purpose of computing the CRC-32 in the des-cbc-crc + encryption mode, the ordering of bits in each octet shall be assumed + to be LSB-first. Given this assumed ordering of bits within an + octet, the mapping of bits to polynomial coefficients shall be + identical to that specified in ISO 3309. + + Test values for this modified CRC function are included in appendix + A.5. + + + crc32 + ---------------------------------------------- + associated cryptosystem any + + get_mic crc32(msg) + + verify_mic get_mic and compare + + + The crc32 checksum algorithm is assigned a checksum type number of + one (1). + +5.2. DES-based encryption and checksum types + + These encryption systems encrypt information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. A checksum is computed as described below and placed in + the cksum field. DES blocks are 8 bytes. As a result, the data to + be encrypted (the concatenation of confounder, checksum, and message) + must be padded to an 8 byte boundary before encryption. The values + of the padding bytes are unspecified. + + Plaintext and DES ciphertext are encoded as blocks of 8 octets which + are concatenated to make the 64-bit inputs for the DES algorithms. + The first octet supplies the 8 most significant bits (with the + octet's MSB used as the DES input block's MSB, etc.), the second + octet the next 8 bits, ..., and the eighth octet supplies the 8 least + significant bits. + + Encryption under DES using cipher block chaining requires an + additional input in the form of an initialization vector; this vector + is specified for each encryption system, below. + + The DES specifications [DESI81] identify four 'weak' and twelve + 'semi-weak' keys; those keys shall not be used for encrypting + messages for use in Kerberos. + + + + +Raeburn [Page 18] + +INTERNET DRAFT February 2003 + + + A DES key is 8 octets of data. This consists of 56 bits of actual + key data, and 8 parity bits, one per octet. The key is encoded as a + series of 8 octets written in MSB-first order. The bits within the + key are also encoded in MSB order. For example, if the encryption + key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) + where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 + are the parity bits, the first octet of the key would be + B1,B2,...,B7,P1 (with B1 as the most significant bit). See the + [DESM80] introduction for reference. + + Encryption data format + + The format for the data to be encrypted includes a one-block + confounder, a checksum, the encoded plaintext, and any necessary + padding, as described in the following diagram. The msg-seq field + contains the part of the protocol message which is to be encrypted. + + +-----------+----------+---------+-----+ + |confounder | checksum | msg-seq | pad | + +-----------+----------+---------+-----+ + + One generates a random confounder of one block, placing it in + 'confounder'; zeroes out the 'checksum' field (of length appropriate + to exactly hold the checksum to be computed); calculates the + appropriate checksum over the whole sequence, placing the result in + 'checksum'; adds the necessary padding; then encrypts using the + specified encryption type and the appropriate key. + + String or random-data to key transformation + + To generate a DES key from two UTF-8 text strings (password and + salt), the two strings are concatenated, password first, and the + result is then padded with zero-valued octets to a multiple of 8 + octets. + + The top bit of each octet (always zero if the password is plain + ASCII, as was assumed when the original specification was written) is + discarded, and a bitstring is formed of the remaining seven bits of + each octet. This bitstring is then fan-folded and eXclusive-ORed + with itself to produce a 56-bit string. An eight-octet key is formed + from this string, each octet using seven bits from the bit string, + leaving the least significant bit unassigned. The key is then + "corrected" by correcting the parity on the key, and if the key + matches a 'weak' or 'semi-weak' key as described in the DES + specification, it is eXclusive-ORed with the constant + 0x00000000000000F0. This key is then used to generate a DES CBC + checksum on the initial string with the salt appended. The result of + the CBC checksum is then "corrected" as described above to form the + + + +Raeburn [Page 19] + +INTERNET DRAFT February 2003 + + + result which is returned as the key. + + For purposes of the string-to-key function, the DES CBC checksum is + calculated by CBC encrypting a string using the key as IV and using + the final 8 byte block as the checksum. + + Pseudocode follows: + + removeMSBits(8byteblock) { + /* Treats a 64 bit block as 8 octets and remove the MSB in + each octect (in big endian mode) and concatenates the + result. E.g., input octet string: + 01110000 01100001 11110011 01110011 11110111 01101111 + 11110010 01100100 + results in output bit string: + 1110000 1100001 1110011 1110011 1110111 1101111 + 1110010 1100100 */ + } + + reverse(56bitblock) { + /* Treats a 56-bit block as a binary string and reverse it. + E.g., input string: + 1000001 1010100 1001000 1000101 1001110 1000001 + 0101110 1001101 + results in output string: + 1011001 0111010 1000001 0111001 1010001 0001001 + 0010101 1000001 */ + } + + add_parity_bits(56bitblock) { + /* Copies a 56-bit block into a 64-bit block, left shift + content in each octet and add DES parity bit. + E.g., input string: + 1100000 0001111 0011100 0110100 1000101 1100100 + 0110110 0010111 + results in output string: + 11000001 00011111 00111000 01101000 10001010 11001000 + 01101101 00101111 */ + } + + key_correction(key) { + fixparity(key); + if (is_weak_key(key)) + key = key XOR 0xF0; + return(key); + } + + + + + +Raeburn [Page 20] + +INTERNET DRAFT February 2003 + + + mit_des_string_to_key(string,salt) { + odd = 1; + s = string | salt; + tempstring = 0; /* 56-bit string */ + pad(s); /* with nulls to 8 byte boundary */ + for (8byteblock in s) { + 56bitstring = removeMSBits(8byteblock); + if (odd == 0) reverse(56bitstring); + odd = ! odd; + tempstring = tempstring XOR 56bitstring; + } + tempkey = key_correction(add_parity_bits(tempstring)); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + des_string_to_key(string,salt,params) { + if (length(params) == 0) + type = 0; + else if (length(params) == 1) + type = params[0]; + else + error("invalid params"); + if (type == 0) + mit_des_string_to_key(string,salt); + else + error("invalid params"); + } + + One common extension is to support the "AFS string-to-key" algorithm, + which is not defined here, if the type value above is one (1). + + For generation of a key from a random bit-string, we start with a + 56-bit string, and as with the string-to-key operation above, insert + parity bits, and if the result is a weak or semi-weak key, modify it + by exclusive-OR with the constart 0x00000000000000F0: + + des_random_to_key(bitstring) { + return key_correction(add_parity_bits(bitstring)); + } + +5.2.1. DES with MD5 + + The des-cbc-md5 encryption mode encrypts information under DES in CBC + mode with an all-zero initial vector, with an MD5 checksum (described + in [MD5-92]) computed and placed in the checksum field. + + + + + +Raeburn [Page 21] + +INTERNET DRAFT February 2003 + + + The encryption system parameters for des-cbc-md5 are: + + des-cbc-md5 + -------------------------------------------------------------------- + protocol key format 8 bytes, parity in low bit of each + + specific key structure copy of original key + + required checksum rsa-md5-des + mechanism + + key-generation seed 8 bytes + length + + cipher state 8 bytes (CBC initial vector) + + initial cipher state all-zero + + encryption function des-cbc(confounder | checksum | msg | pad, + ivec=oldstate) + where + checksum = md5(confounder | 0000... + | msg | pad) + + newstate = last block of des-cbc output + + decryption function decrypt encrypted text and verify checksum + + newstate = last block of ciphertext + + default string-to-key empty string + params + + pseudo-random function des-cbc(md5(input-string), ivec=0) + + key generation functions: + + string-to-key des_string_to_key + + random-to-key des_random_to_key + + key-derivation identity + + The des-cbc-md5 encryption type is assigned the etype value three + (3). + + + + + + +Raeburn [Page 22] + +INTERNET DRAFT February 2003 + + +5.2.2. DES with MD4 + + The des-cbc-md4 encryption mode also encrypts information under DES + in CBC mode, with an all-zero initial vector. An MD4 checksum + (described in [MD4-92]) is computed and placed in the checksum field. + + des-cbc-md4 + -------------------------------------------------------------------- + protocol key format 8 bytes, parity in low bit of each + + specific key structure copy of original key + + required checksum rsa-md4-des + mechanism + + key-generation seed 8 bytes + length + + cipher state 8 bytes (CBC initial vector) + + initial cipher state all-zero + + encryption function des-cbc(confounder | checksum | msg | pad, + ivec=oldstate) + where + checksum = md4(confounder | 0000... + | msg | pad) + + newstate = last block of des-cbc output + + decryption function decrypt encrypted text and verify checksum + + newstate = last block of ciphertext + + default string-to-key empty string + params + + pseudo-random function des-cbc(md5(input-string), ivec=0) + + key generation functions: + + string-to-key des_string_to_key + + random-to-key copy input, then fix parity bits + + key-derivation identity + + + + + +Raeburn [Page 23] + +INTERNET DRAFT February 2003 + + + Note that des-cbc-md4 uses md5, not md4, in the PRF definition. + + The des-cbc-md4 encryption algorithm is assigned the etype value two + (2). + +5.2.3. DES with CRC + + The des-cbc-crc encryption type uses DES in CBC mode with the key + used as the initialization vector, with a 4-octet CRC-based checksum + computed as described in section 5.1.3. Note that this is not a + standard CRC-32 checksum, but a slightly modified one. + + + des-cbc-crc + -------------------------------------------------------------------- + protocol key format 8 bytes, parity in low bit of each + + specific key structure copy of original key + + required checksum rsa-md5-des + mechanism + + key-generation seed 8 bytes + length + + cipher state 8 bytes (CBC initial vector) + + initial cipher state copy of original key + + encryption function des-cbc(confounder | checksum | msg | pad, + ivec=oldstate) + where + checksum = crc(confounder | 00000000 + | msg | pad) + + newstate = last block of des-cbc output + + decryption function decrypt encrypted text and verify checksum + + newstate = last block of ciphertext + + default string-to-key empty string + params + + pseudo-random function des-cbc(md5(input-string), ivec=0) + + key generation functions: + + + + +Raeburn [Page 24] + +INTERNET DRAFT February 2003 + + + des-cbc-crc + -------------------------------------------------------------------- + + string-to-key des_string_to_key + + random-to-key copy input, then fix parity bits + + key-derivation identity + + The des-cbc-crc encryption algorithm is assigned the etype value one + (1). + +5.2.4. RSA MD5 Cryptographic Checksum Using DES + + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum + by prepending an 8 octet confounder before the text, applying the RSA + MD5 checksum algorithm, and encrypting the confounder and the + checksum using DES in cipher-block-chaining (CBC) mode using a + variant of the key, where the variant is computed by eXclusive-ORing + the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The + initialization vector should be zero. The resulting checksum is 24 + octets long. This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some 'weak keys' and 'semi-weak + keys'; those keys shall not be used for encrypting RSA-MD5 checksums + for use in Kerberos. + + + rsa-md5-des + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, + conf | rsa-md5(conf | msg)) + + verify_mic decrypt and verify rsa-md5 checksum + + + The rsa-md5-des checksum algorithm is assigned a checksum type number + of eight (8). + +5.2.5. RSA MD4 Cryptographic Checksum Using DES + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum + by prepending an 8 octet confounder before the text, applying the RSA + MD4 checksum algorithm [MD4-92], and encrypting the confounder and + the checksum using DES in cipher-block-chaining (CBC) mode using a + + + +Raeburn [Page 25] + +INTERNET DRAFT February 2003 + + + variant of the key, where the variant is computed by eXclusive-ORing + the key with the constant 0xF0F0F0F0F0F0F0F0. [7] The initialization + vector should be zero. The resulting checksum is 24 octets long. + This checksum is tamper-proof and believed to be collision-proof. + + The DES specifications identify some "weak keys" and "semi-weak + keys"; those keys shall not be used for generating RSA-MD4 checksums + for use in Kerberos. + + rsa-md4-des + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, + conf | rsa-md4(conf | msg), + ivec=0) + + verify_mic decrypt and verify rsa-md4 checksum + + The rsa-md4-des checksum algorithm is assigned a checksum type number + of three (3). + +5.2.6. RSA MD4 Cryptographic Checksum Using DES alternative + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof + checksum by applying the RSA MD4 checksum algorithm and encrypting + the results using DES in cipher block chaining (CBC) mode using a DES + key as both key and initialization vector. The resulting checksum is + 16 octets long. This checksum is tamper-proof and believed to be + collision-proof. Note that this checksum type is the old method for + encoding the RSA-MD4-DES checksum and it is no longer recommended. + + + rsa-md4-des-k + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-cbc(key, md4(msg), ivec=key) + + verify_mic decrypt, compute checksum and compare + + + The rsa-md4-des-k checksum algorithm is assigned a checksum type + number of six (6). + + + + + + + +Raeburn [Page 26] + +INTERNET DRAFT February 2003 + + +5.2.7. DES CBC checksum + + The DES-MAC checksum is computed by prepending an 8 octet confounder + to the plaintext, padding with zero-valued octets if necessary to + bring the length to a multiple of 8 octets, performing a DES CBC-mode + encryption on the result using the key and an initialization vector + of zero, taking the last block of the ciphertext, prepending the same + confounder and encrypting the pair using DES in cipher-block-chaining + (CBC) mode using a variant of the key, where the variant is computed + by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The + initialization vector should be zero. The resulting checksum is 128 + bits (16 octets) long, 64 bits of which are redundant. This checksum + is tamper-proof and collision-proof. + + + des-mac + ---------------------------------------------------------------------- + associated des-cbc-md5, des-cbc-md4, des-cbc-crc + cryptosystem + + get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, + conf | des-mac(key, conf | msg | pad, ivec=0), + ivec=0) + + verify_mic decrypt, compute DES MAC using confounder, compare + + + The des-mac checksum algorithm is assigned a checksum type number of + four (4). + +5.2.8. DES CBC checksum alternative + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, with zero-valued padding bytes if + necessary to bring the length to a multiple of 8 octets, and using + the last block of the ciphertext as the checksum value. It is keyed + with an encryption key which is also used as the initialization + vector. The resulting checksum is 64 bits (8 octets) long. This + checksum is tamper-proof and collision-proof. Note that this + checksum type is the old method for encoding the DESMAC checksum and + it is no longer recommended. + + + + + + + + + + +Raeburn [Page 27] + +INTERNET DRAFT February 2003 + + + des-mac-k + ---------------------------------------------------------------- + associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc + + get_mic des-mac(key, msg | pad, ivec=key) + + verify_mic compute MAC and compare + + + The des-mac-k checksum algorithm is assigned a checksum type number + of five (5). + +5.3. Triple-DES based encryption and checksum types + + This encryption and checksum type pair is based on the Triple DES + cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message + authentication algorithm. + + A Triple DES key is the concatenation of three DES keys as described + above for des-cbc-md5. A Triple DES key is generated from random + data by creating three DES keys from separate sequences of random + data. + + Encrypted data using this type must be generated as described in + section 4.3. If the length of the input data is not a multiple of + the block size, zero-valued octets must be used to pad the plaintext + to the next eight-octet boundary. The confounder must be eight + random octets (one block). + + The simplified profile for Triple DES, with key derivation as defined + in section 4, is as follows: + + des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd + ------------------------------------------------ + protocol key format 24 bytes, parity in low + bit of each + + key-generation seed 21 bytes + length + + hash function SHA-1 + + HMAC output size 160 bits + + message block size 8 bytes + + + + + + +Raeburn [Page 28] + +INTERNET DRAFT February 2003 + + + des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd + ------------------------------------------------ + default string-to-key empty string + params + + encryption and triple-DES encrypt and + decryption functions decrypt, in outer-CBC + mode (cipher block size + 8 octets) + + key generation functions: + + random-to-key DES3random-to-key (see + below) + + string-to-key DES3string-to-key (see + below) + + The des3-cbc-hmac-sha1-kd encryption type is assigned the value + sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a + checksum type number of twelve (12). + +5.3.1. Triple DES Key Production (random-to-key, string-to-key) + + The 168 bits of random key data are converted to a protocol key value + as follows. First, the 168 bits are divided into three groups of 56 + bits, which are expanded individually into 64 bits as follows: + + DES3random-to-key: + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p + 17 18 19 20 21 22 23 p + 25 26 27 28 29 30 31 p + 33 34 35 36 37 38 39 p + 41 42 43 44 45 46 47 p + 49 50 51 52 53 54 55 p + 56 48 40 32 24 16 8 p + + The "p" bits are parity bits computed over the data bits. The output + of the three expansions are concatenated to form the protocol key + value. + + The string-to-key function is used to transform UTF-8 passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm and DK function, described in section 4. + + The n-fold algorithm is applied to the password string concatenated + with a salt value. For 3-key triple DES, the operation will involve + + + +Raeburn [Page 29] + +INTERNET DRAFT February 2003 + + + a 168-fold of the input password string, to generate an intermediate + key, from which the user's long-term key will be derived with the DK + function. The DES3 string-to-key function is shown here in + pseudocode: + + DES3string-to-key(passwordString, salt, params) + if (params != emptyString) + error("invalid params"); + s = passwordString + salt + tmpKey = random-to-key(168-fold(s)) + key = DK (tmpKey, KerberosConstant) + + No weak-key checking is performed. The KerberosConstant value is the + byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values + correspond to the ASCII encoding for the string "kerberos". + +6. Use of Kerberos encryption outside this specification + + Several Kerberos-based application protocols and preauthentication + systems have been designed and deployed that perform encryption and + message integrity checks in various ways. While in some cases there + may be good reason for specifying these protocols in terms of + specific encryption or checksum algorithms, we anticipate that in + many cases this will not be true, and more generic approaches + independent of particular algorithms will be desirable. Rather than + having each protocol designer reinvent schemes for protecting data, + using multiple keys, etc, we have attempted to present in this + section a general framework that should be sufficient not only for + the Kerberos protocol itself but also for many preauthentication + systems and application protocols, while trying to avoid some of the + assumptions that can work their way into such protocol designs. + + Some problematic assumptions we've seen (and sometimes made) include: + that a random bitstring is always valid as a key (not true for DES + keys with parity); that the basic block encryption chaining mode + provides no integrity checking, or can easily be separated from such + checking (not true for many modes in development that do both + simultaneously); that a checksum for a message always results in the + same value (not true if a confounder is incorporated); that an + initial vector is used (may not be true if a block cipher in CBC mode + is not in use). + + Such assumptions, while they may hold for any given set of encryption + and checksum algorithms, may not be true of the next algorithms to be + defined, leaving the application protocol unable to make use of those + algorithms without updates to its specification. + + The Kerberos protocol uses only the attributes and operations + + + +Raeburn [Page 30] + +INTERNET DRAFT February 2003 + + + described in sections 2 and 3. Preauthentication systems and + application protocols making use of Kerberos are encouraged to use + them as well. The specific key and string-to-key parameters should + generally be treated as opaque. While the string-to-key parameters + are manipulated as an octet string, the representation for the + specific key structure is implementation-defined; it may not even be + a single object. + + While we don't recommend it, some application protocols will + undoubtedly continue to use the key data directly, even if only in + some of the currently existing protocol specifications. An + implementation intended to support general Kerberos applications may + therefore need to make the key data available, as well as the + attributes and operations described in sections 2 and 3. [8] + +7. Assigned Numbers + + The following encryption type numbers are already assigned or + reserved for use in Kerberos and related protocols. + + + encryption type etype section or comment + ----------------------------------------------------------------- + des-cbc-crc 1 5.2.3 + des-cbc-md4 2 5.2.2 + des-cbc-md5 3 5.2.1 + [reserved] 4 + des3-cbc-md5 5 + [reserved] 6 + des3-cbc-sha1 7 + dsaWithSHA1-CmsOID 9 (pkinit) + md5WithRSAEncryption-CmsOID 10 (pkinit) + sha1WithRSAEncryption-CmsOID 11 (pkinit) + rc2CBC-EnvOID 12 (pkinit) + rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) + rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) + des-ede3-cbc-Env-OID 15 (pkinit) + des3-cbc-sha1-kd 16 5.3 + aes128-cts-hmac-sha1-96 17 [KRB5-AES] + aes256-cts-hmac-sha1-96 18 [KRB5-AES] + rc4-hmac 23 (Microsoft) + rc4-hmac-exp 24 (Microsoft) + subkey-keymaterial 65 (opaque; PacketCable) + + + (The "des3-cbc-sha1" assignment is a deprecated version using no key + derivation. It should not be confused with des3-cbc-sha1-kd.) + + + + +Raeburn [Page 31] + +INTERNET DRAFT February 2003 + + + Several numbers have been reserved for use in encryption systems not + defined here. Encryption type numbers have unfortunately been + overloaded on occasion in Kerberos-related protocols, so some of the + reserved numbers do not and will not correspond to encryption systems + fitting the profile presented here. + + The following checksum type numbers are assigned or reserved. As + with encryption type numbers, some overloading of checksum numbers + has occurred. + + + Checksum type sumtype checksum section or + value size reference + ---------------------------------------------------------------------- + CRC32 1 4 5.1.3 + rsa-md4 2 16 5.1.2 + rsa-md4-des 3 24 5.2.5 + des-mac 4 16 5.2.7 + des-mac-k 5 8 5.2.8 + rsa-md4-des-k 6 16 5.2.6 + rsa-md5 7 16 5.1.1 + rsa-md5-des 8 24 5.2.4 + rsa-md5-des3 9 24 ?? + sha1 (unkeyed) 10 20 ?? + hmac-sha1-des3-kd 12 20 5.3 + hmac-sha1-des3 13 20 ?? + sha1 (unkeyed) 14 20 ?? + hmac-sha1-96-aes128 15 20 [KRB5-AES] + hmac-sha1-96-aes256 16 20 [KRB5-AES] + [reserved] 0x8003 ? [GSS-KRB5] + + + Encryption and checksum type numbers are signed 32-bit values. Zero + is invalid, and negative numbers are reserved for local use. All + standardized values must be positive. + +8. Implementation Notes + + The "interface" described here is the minimal information that must + be defined to make a cryptosystem useful within Kerberos in an + interoperable fashion. Despite the functional notation used in some + places, it is not an attempt to define an API for cryptographic + functionality within Kerberos. Actual implementations providing + clean APIs will probably find it useful to make additional + information available, which should be possible to derive from a + specification written to the framework given here. For example, an + application designer may wish to determine the largest number of + bytes that can be encrypted without overflowing a certain size output + + + +Raeburn [Page 32] + +INTERNET DRAFT February 2003 + + + buffer, or conversely, the maximum number of bytes that might be + obtained by decrypting a ciphertext message of a given size. (In + fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] + will require some of these.) + + The presence of a mechanism in this document should not be taken as + an indication that it must be implemented for compliance with any + specification; required mechanisms will be specified elsewhere. + Indeed, some of the mechanisms described here for backwards + compatibility are now considered rather weak for protecting critical + data. + +9. Security Considerations + + Recent years have brought advancements in the ability to perform + large-scale attacks against DES, to such a degree that it is not + considered a strong encryption mechanism any longer; triple-DES is + generally preferred in its place, despite the poorer performance. + See [ESP-DES] for a summary of some of the potential attacks, and + [EFF-DES] for a detailed discussion of the implementation of + particular attack. However, most Kerberos implementations still have + DES as their primary interoperable encryption type. + + DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of + single-DES here avoids them. However, DES also has 48 'possibly-weak' + keys [Schneier96] (note that the tables in many editions of the + reference contains errors) which are not avoided. + + DES weak keys are keys with the property that E1(E1(P)) = P (where E1 + denotes encryption of a single block with key 1). DES semi-weak keys + or "dual" keys are pairs of keys with the property that E1(P) = + D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and + leading random confounder, however, these properties are unlikely to + present a security problem. + + The use of triple-DES in Kerberos makes no effort to avoid these + keys. The nature of the weak keys is such that it is extremely + unlikely that they will weaken the triple-DES encryption -- only + slightly more likely than having the middle of the three sub-keys + match one of the other two, which effectively converts the encryption + to single-DES, which is another case we make no effort to avoid. + + The true CRC-32 checksum is not collision-proof; an attacker could + use a probabilistic chosen-plaintext attack to generate a valid + message even if a confounder is used [SG92]. The use of collision- + proof checksums is of course recommended for environments where such + attacks represent a significant threat. The "simplifications" (read: + bugs) introduced when CRC-32 was implemented for Kerberos cause + + + +Raeburn [Page 33] + +INTERNET DRAFT February 2003 + + + leading zeros to effectively be ignored, so messages differing only + in leading zero bits will have the same checksum. + + [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. + Unlike [IPSEC-HMAC], the triple-DES specification here does not use + the suggested truncation of the HMAC output. As pointed out in + [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash + function, which is a criterion of HMAC. [HMAC-TEST] contains test + vectors for HMAC-SHA-1. + + The mit_des_string_to_key function was originally constructed with + the assumption that all input would be ASCII; it ignores the top bit + of each input byte. Folding with XOR is also not an especially good + mixing mechanism in terms of preserving randomness. + + The n-fold function used in the string-to-key operation for des3-cbc- + hmac-sha1-kd was designed to cause each bit of input to contribute + equally to the output; it was not designed to maximize or equally + distribute randomness in the input, and there are conceivable cases + of partially structured input where randomness may be lost. This + should only be an issue for highly structured passwords, however. + + [RFC1851] discusses the relative strength of triple-DES encryption. + The relative slow speed of triple-DES encryption may also be an issue + for some applications. + + This document, like the Kerberos protocol, completely ignores the + notion of limiting the amount of data a key may be used with to a + quantity based on the robustness of the algorithm or size of the key. + It is assumed that any defined algorithms and key sizes will be + strong enough to support very large amounts of data, or they will be + deprecated once significant attacks are known. + + This document also places no bounds on the amount of data that can be + handled in various operations. In order to avoid denial of service + attacks, implementations will probably want to restrict message sizes + at some higher level. + +10. IANA Considerations + + None at present. The management of encryption and checksum type + number assignments may be transferred to IANA at some future time. + + + + + + + + + +Raeburn [Page 34] + +INTERNET DRAFT February 2003 + + +11. Acknowledgments + + This document is an extension of the encryption specification + included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much + of the text of the background, concepts, and DES specifications are + drawn directly from that document. + + The abstract framework presented in this document was put together by + Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, + and Tom Yu, and the details were refined several times based on + comments from John Brezak and others. + + Marc Horowitz wrote the original specification of triple-DES and key + derivation in a pair of Internet Drafts (under the names draft- + horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which + were later folded into a draft revision of [Kerb1510], from which + this document was later split off. + + Tom Yu provided the text describing the modifications to the standard + CRC algorithm as Kerberos implementations actually use it. + + Miroslav Jurisic provided information for one of the UTF-8 test cases + for the string-to-key functions. + + Marcus Watts noticed some errors in earlier drafts, and pointed out + that the simplified profile could easily be modified to support + cipher text stealing modes. + + Simon Josefsson contributed some clarifications to the DES "CBC + checksum", string-to-key and weak key descriptions, and some test + vectors. + + Simon Josefsson, Louis LeVay and others also caught some errors in + earlier drafts. + +12. Editor's address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + raeburn@mit.edu + + + + + + + + + +Raeburn [Page 35] + +INTERNET DRAFT February 2003 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +A. Test vectors + + This section provides test vectors for various functions defined or + described in this document. For convenience, most inputs are ASCII + strings, though some UTF-8 samples are be provided for string-to-key + functions. Keys and other binary data are specified as hexadecimal + strings. + +A.1. n-fold + + The n-fold function is defined in section 4.1. As noted there, the + sample vector in the original paper defining the algorithm appears to + be incorrect. Here are some test cases provided by Marc Horowitz and + Simon Josefsson: + + + + + + + + + +Raeburn [Page 36] + +INTERNET DRAFT February 2003 + + + 64-fold("012345") = + 64-fold(303132333435) = be072631276b1955 + + 56-fold("password") = + 56-fold(70617373776f7264) = 78a07b6caf85fa + + 64-fold("Rough Consensus, and Running Code") = + 64-fold(526f75676820436f6e73656e7375732c20616e642052756e + 6e696e6720436f6465) = bb6ed30870b7f0e0 + + 168-fold("password") = + 168-fold(70617373776f7264) = + 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e + + 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" + 192-fold(4d41535341434856534554545320494e5354495456544520 + 4f4620544543484e4f4c4f4759) = + db3b0d8f0b061e603282b308a50841229ad798fab9540c1b + + 168-fold("Q") = + 168-fold(51) = + 518a54a2 15a8452a 518a54a2 15a8452a + 518a54a2 15 + + 168-fold("ba") = + 168-fold(6261) = + fb25d531 ae897449 9f52fd92 ea9857c4 + ba24cf29 7e + + Here are some additional values corresponding to folded values of the + string "kerberos"; the 64-bit form is used in the des3 string-to-key + (section 5.3.1). + + 64-fold("kerberos") = + 6b657262 65726f73 + 128-fold("kerberos") = + 6b657262 65726f73 7b9b5b2b 93132b93 + 168-fold("kerberos") = + 8372c236 344e5f15 50cd0747 e15d62ca + 7a5a3bce a4 + 256-fold("kerberos") = + 6b657262 65726f73 7b9b5b2b 93132b93 + 5c9bdcda d95c9899 c4cae4de e6d6cae4 + + Note that the initial octets exactly match the input string when the + output length is a multiple of the input length. + + + + + +Raeburn [Page 37] + +INTERNET DRAFT February 2003 + + +A.2. mit_des_string_to_key + + The function mit_des_string_to_key is defined in section 5.2. We + present here several test values, with some of the intermediate + results. The fourth test demonstrates the use of UTF-8 with three + characters. The last two tests are specifically constructed so as to + trigger the weak-key fixups for the intermediate key produced by fan- + folding; we have no test cases that cause such fixups for the final + key. + + + UTF-8 encodings used in test vector: + eszett C3 9F s-caron C5 A1 c-acute C4 87 + g-clef F0 9D 84 9E + + + Test vector: + + + salt: "ATHENA.MIT.EDUraeburn" + 415448454e412e4d49542e4544557261656275726e + password: "password" 70617373776f7264 + fan-fold result: c01e38688ac86c2e + intermediate key: c11f38688ac86d2f + DES key: cbc22fae235298e3 + + + + salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 + password: "potatoe" 706f7461746f65 + fan-fold result: a028944ee63c0416 + intermediate key: a129944fe63d0416 + DES key: df3d32a74fd92a01 + + + + salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 + password: g-clef f09d849e + fan-fold result: 3c4a262c18fab090 + intermediate key: 3d4a262c19fbb091 + DES key: 4ffb26bab0cd9413 + + + + + + + + + + +Raeburn [Page 38] + +INTERNET DRAFT February 2003 + + + salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute + 415448454e412e4d49542e4544554a757269c5a169c487 + password: eszett c39f + fan-fold result: b8f6c40e305afc9e + intermediate key: b9f7c40e315bfd9e + DES key: 62c81a5232b5e69d + + + + salt: "AAAAAAAA" 4141414141414141 + password: "11119999" 3131313139393939 + fan-fold result: e0e0e0e0f0f0f0f0 + intermediate key: e0e0e0e0f1f1f101 + DES key: 984054d0f1a73e31 + + + + salt: "FFFFAAAA" 4646464641414141 + password: "NNNN6666" 4e4e4e4e36363636 + fan-fold result: 1e1e1e1e0e0e0e0e + intermediate key: 1f1f1f1f0e0e0efe + DES key: c4bf6b25adf7a4f8 + + + This trace provided by Simon Josefsson shows the intermediate + processing stages of one of the test inputs: + + string_to_key (des-cbc-md5, string, salt) + ;; string: + ;; `password' (length 8 bytes) + ;; 70 61 73 73 77 6f 72 64 + ;; salt: + ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) + ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 + ;; 65 62 75 72 6e + des_string_to_key (string, salt) + ;; String: + ;; `password' (length 8 bytes) + ;; 70 61 73 73 77 6f 72 64 + ;; Salt: + ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) + ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 + ;; 65 62 75 72 6e + odd = 1; + s = string | salt; + + + + + + +Raeburn [Page 39] + +INTERNET DRAFT February 2003 + + + tempstring = 0; /* 56-bit string */ + pad(s); /* with nulls to 8 byte boundary */ + ;; s = pad(string|salt): + ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' + ;; (length 32 bytes) + ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d + ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 + for (8byteblock in s) { + ;; loop iteration 0 + ;; 8byteblock: + ;; `password' (length 8 bytes) + ;; 70 61 73 73 77 6f 72 64 + ;; 01110000 01100001 01110011 01110011 01110111 01101111 + ;; 01110010 01100100 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1110000 1100001 1110011 1110011 1110111 1101111 + ;; 1110010 1100100 + if (odd == 0) reverse(56bitstring); ;; odd=1 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 1110000 1100001 1110011 1110011 1110111 1101111 + ;; 1110010 1100100 + + for (8byteblock in s) { + ;; loop iteration 1 + ;; 8byteblock: + ;; `ATHENA.M' (length 8 bytes) + ;; 41 54 48 45 4e 41 2e 4d + ;; 01000001 01010100 01001000 01000101 01001110 01000001 + ;; 00101110 01001101 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1000001 1010100 1001000 1000101 1001110 1000001 + ;; 0101110 1001101 + if (odd == 0) reverse(56bitstring); ;; odd=0 + reverse(56bitstring) + ;; 56bitstring after reverse + ;; 1011001 0111010 1000001 0111001 1010001 0001001 + ;; 0010101 1000001 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 0101001 1011011 0110010 1001010 0100110 1100110 + ;; 1100111 0100101 + + + + + +Raeburn [Page 40] + +INTERNET DRAFT February 2003 + + + for (8byteblock in s) { + ;; loop iteration 2 + ;; 8byteblock: + ;; `IT.EDUra' (length 8 bytes) + ;; 49 54 2e 45 44 55 72 61 + ;; 01001001 01010100 00101110 01000101 01000100 01010101 + ;; 01110010 01100001 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1001001 1010100 0101110 1000101 1000100 1010101 + ;; 1110010 1100001 + if (odd == 0) reverse(56bitstring); ;; odd=1 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 1100000 0001111 0011100 0001111 1100010 0110011 + ;; 0010101 1000100 + + for (8byteblock in s) { + ;; loop iteration 3 + ;; 8byteblock: + ;; `eburn\x00\x00\x00' (length 8 bytes) + ;; 65 62 75 72 6e 00 00 00 + ;; 01100101 01100010 01110101 01110010 01101110 00000000 + ;; 00000000 00000000 + 56bitstring = removeMSBits(8byteblock); + ;; 56bitstring: + ;; 1100101 1100010 1110101 1110010 1101110 0000000 + ;; 0000000 0000000 + if (odd == 0) reverse(56bitstring); ;; odd=0 + reverse(56bitstring) + ;; 56bitstring after reverse + ;; 0000000 0000000 0000000 0111011 0100111 1010111 + ;; 0100011 1010011 + odd = ! odd + tempstring = tempstring XOR 56bitstring; + ;; tempstring + ;; 1100000 0001111 0011100 0110100 1000101 1100100 + ;; 0110110 0010111 + + for (8byteblock in s) { + } + ;; for loop terminated + + + + + + + + +Raeburn [Page 41] + +INTERNET DRAFT February 2003 + + + tempkey = key_correction(add_parity_bits(tempstring)); + ;; tempkey + ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) + ;; c1 1f 38 68 8a c8 6d 2f + ;; 11000001 00011111 00111000 01101000 10001010 11001000 + ;; 01101101 00101111 + + key = key_correction(DES-CBC-check(s,tempkey)); + ;; key + ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) + ;; cb c2 2f ae 23 52 98 e3 + ;; 11001011 11000010 00101111 10101110 00100011 01010010 + ;; 10011000 11100011 + + ;; string_to_key key: + ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) + ;; cb c2 2f ae 23 52 98 e3 + + +A.3. DES3 DR and DK + + These tests show the derived-random and derived-key values for the + des3-hmac-sha1-kd encryption scheme, using the DR and DK functions + defined in section 5.3.1. The input keys were randomly generated; + the usage values are from this specification. + + + key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 + usage: 0000000155 + DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 + DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd + + key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 + usage: 00000001aa + DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 + DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 + + key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc + usage: 0000000155 + DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb + DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf + + key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 + usage: 00000001aa + DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 + DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e + + + + + +Raeburn [Page 42] + +INTERNET DRAFT February 2003 + + + key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb + usage: 6b65726265726f73 ("kerberos") + DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da + DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 + + key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da + usage: 0000000155 + DR: 348056ec98fcc517171d2b4d7a9493af482d999175 + DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 + + key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c + usage: 00000001aa + DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 + DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 + + key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 + usage: 0000000155 + DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a + DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 + + key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 + usage: 00000001aa + DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec + DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d + + +A.4. DES3string_to_key + + These are the keys generated for some of the above input strings for + triple-DES with key derivation as defined in section 5.3.1. + + salt: "ATHENA.MIT.EDUraeburn" + passwd: "password" + key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e + + salt: "WHITEHOUSE.GOVdanny" + passwd: "potatoe" + key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a + + salt: "EXAMPLE.COMbuckaroo" + passwd: "penny" + key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a + + salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute + passwd: eszett + key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 + + + + + +Raeburn [Page 43] + +INTERNET DRAFT February 2003 + + + salt: "EXAMPLE.COMpianist" + passwd: g-clef + key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 + +A.5. Modified CRC-32 + + Below are modified-CRC32 values for various ASCII and octet strings. + Only the printable ASCII characters are checksummed, no C-style + trailing zero-valued octet. The 32-bit modified CRC and the sequence + of output bytes as used in Kerberos are shown. (The octet values are + separated here to emphasize that they are octet values and not 32-bit + numbers, which will be the most convenient form for manipulation in + some implementations. The bit and byte order used internally for + such a number is irrelevant; the octet sequence generated is what is + important.) + + + mod-crc-32("foo") = 33 bc 32 73 + mod-crc-32("test0123456789") = d6 88 3e b8 + mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 + mod-crc-32(8000) = 4b 98 83 3b + mod-crc-32(0008) = 32 88 db 0e + mod-crc-32(0080) = 20 83 b8 ed + mod-crc-32(80) = 20 83 b8 ed + mod-crc-32(80000000) = 3b b6 59 ed + mod-crc-32(00000001) = 96 30 07 77 + + +B. Significant Changes from RFC 1510 + + The encryption and checksum mechanism profiles are new. The old + specification defined a few operations for various mechanisms, but + didn't outline what should be required of new mechanisms in terms of + abstract properties, nor how to ensure that a mechanism specification + is complete enough for interoperability between implementations. The + new profiles do differ from the old specification in a few ways: + + Some message definitions in [Kerb1510] could be read as permitting + the initial vector to be specified by the application; the text + was too vague. It is specifically not permitted in this + specification. Some encryption algorithms may not use + initialization vectors, so relying on chosen, secret + initialization vectors for security is unwise. Also, the + prepended confounder in the existing algorithms is roughly + equivalent to a per-message initialization vector that is revealed + in encrypted form. However, carrying state across from one + encryption to another is explicitly permitted through the opaque + "cipher state" object. + + + +Raeburn [Page 44] + +INTERNET DRAFT February 2003 + + + The use of key derivation is new. + + Several new methods are introduced, including generation of a key + in wire-protocol format from random input data. + + The means for influencing the string-to-key algorithm are laid out + more clearly. + + Triple-DES support is new. + + The pseudo-random function is new. + + The des-cbc-crc, DES string-to-key and CRC descriptions have been + updated to align them with existing implementations. + + [Kerb1510] had no indication what character set or encoding might be + used for pass phrases and salts. + + In [Kerb1510], key types, encryption algorithms and checksum + algorithms were only loosely associated, and the association was not + well described. In this specification, key types and encryption + algorithms have a one-to-one correspondence, and associations between + encryption and checksum algorithms are described so that checksums + can be computed given negotiated keys, without requiring further + negotiation for checksum types. + +Notes + + [1] While Message Authentication Code (MAC) or Message Integrity + Check (MIC) would be more appropriate terms for many of the + uses in this document, we continue to use the term "checksum" + for historical reasons. + + [2] Extending CBC mode across messages would be one obvious + example of this chaining. Another might be the use of + counter mode, with a counter randomly initialized and + attached to the ciphertext; a second message could continue + incrementing the counter when chaining the cipher state, thus + avoiding having to transmit another counter value. However, + this chaining is only useful for uninterrupted, ordered + sequences of messages. + + [3] In the case of Kerberos, the encrypted objects will generally + be ASN.1 DER encodings, which contain indications of their + length in the first few octets. + + [4] As of the time of this writing, some new modes of operation + have been proposed, some of which may permit encryption and + + + +Raeburn [Page 45] + +INTERNET DRAFT February 2003 + + + integrity protection simultaneously. After some of these + proposals have been subjected to adequate analysis, we may + wish to formulate a new simplified profile based on one of + them. + + [5] It should be noted that the sample vector in Appendix B.2 of + the original paper appears to be incorrect. Two independent + implementations from the specification (one in C by Marc + Horowitz, and another in Scheme by Bill Sommerfeld) agree on + a value different from that in [Blumenthal96]. + + [6] For example, in MIT's implementation of [Kerb1510], the rsa- + md5 unkeyed checksum of application data may be included in + an authenticator encrypted in a service's key; since rsa-md5 + is believed to be collision-proof, even if the application + data is exposed to an attacker, it cannot be modified without + causing the checksum verification to fail. + + [7] A variant of the key is used to limit the use of a key to a + particular function, separating the functions of generating a + checksum from other encryption performed using the session + key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it + maintains key parity. The properties of DES precluded the + use of the complement. The same constant is used for similar + purpose in the Message Integrity Check in the Privacy + Enhanced Mail standard. + + [8] Perhaps one of the more common reasons for directly + performing encryption is direct control over the negotiation + and to select a "sufficiently strong" encryption algorithm + (whatever that means in the context of a given application). + While Kerberos directly provides no facility for negotiating + encryption types between the application client and server, + there are other means for accomplishing similar goals. For + example, requesting only "strong" session key types from the + KDC, and assuming that the type actually returned by the KDC + will be understood and supported by the application server. + +Normative References + + [Bellare98] + Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, + "Relations Among Notions of Security for Public-Key Encryption + Schemes". Extended abstract published in Advances in Cryptology- + Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. + 1462, H. Krawcyzk ed., Springer-Verlag, 1998. + + + + + +Raeburn [Page 46] + +INTERNET DRAFT February 2003 + + + [Blumenthal96] + Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES- + Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996. + [CRC] + International Organization for Standardization, "ISO Information + Processing Systems - Data Communication - High-Level Data Link + Control Procedure - Frame Structure," IS 3309, 3rd Edition, + October 1984. + [DES77] + National Bureau of Standards, U.S. Department of Commerce, "Data + Encryption Standard," Federal Information Processing Standards + Publication 46, Washington, DC, 1977. + [DESI81] + National Bureau of Standards, U.S. Department of Commerce, + "Guidelines for implementing and using NBS Data Encryption + Standard," Federal Information Processing Standards Publication + 74, Washington, DC, 1981. + [DESM80] + National Bureau of Standards, U.S. Department of Commerce, "DES + Modes of Operation," Federal Information Processing Standards + Publication 81, Springfield, VA, December 1980. + [Dolev91] + Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", + Proceedings of the 23rd Annual Symposium on Theory of Computing, + ACM, 1991. + [HMAC] + Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + [KRB5-AES] + Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx + 2003. + [MD4-92] + Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT + Laboratory for Computer Science, April 1992. + [MD5-92] + Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT + Laboratory for Computer Science, April 1992. + [RFC2026] + Bradner, S., "The Internet Standards Process -- Revisions 3," RFC + 2026, October 1996. + [SG92] + Stubblebine, S., and V. D. Gligor, "On Message Integrity in + Cryptographic Protocols," in Proceedings of the IEEE Symposium on + Research in Security and Privacy, Oakland, California, May 1992. + + + + + + + +Raeburn [Page 47] + +INTERNET DRAFT February 2003 + + +Informative References + + [EFF-DES] + Electronic Frontier Foundation, "Cracking DES: Secrets of + Encryption Research, Wiretap Politics, and Chip Design", O'Reilly + & Associates, Inc., May 1998. + [ESP-DES] + Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm + With Explicit IV", RFC 2405, November 1998. + [GSS-KRB5] + Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964, + June 1996. + [HMAC-TEST] + Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", + RFC 2202, September 1997. + [IPSEC-HMAC] + Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and + AH", RFC 2404, November 1998. + [Kerb] + Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. + Raeburn, "The Kerberos Network Authentication Service (V5)", + draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, + 2002. Work in progress. + [Kerb1510] + Kohl, J., and C. Neuman, "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993. + [RC5] + Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and + RC5-CTS Algorithms", RFC 2040, October 1996. + [Schneier96] + Schneier, B., "Applied Cryptography Second Edition", John Wiley & + Sons, New York, NY, 1996. ISBN 0-471-12845-7. + +Notes to RFC Editor + + Before publication of this document as an RFC, the following changes + are needed: + + Change the reference "[KRB5-AES]" in Normative References to indicate + the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be + advancing to RFC at the same time. The RFC number and publication + date are needed. + + If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the + same time as this document, change the information for [Kerb] in the + Informative References section as well. + + Delete this section. + + + +Raeburn [Page 48] diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt new file mode 100644 index 000000000..005ea86b0 --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt @@ -0,0 +1,7975 @@ + +INTERNET-DRAFT Clifford Neuman + USC-ISI + Tom Yu + Sam Hartman + Ken Raeburn + MIT + March 2, 2003 + Expires 2 September, 2003 + + The Kerberos Network Authentication Service (V5) + draft-ietf-krb-wg-kerberos-clarifications-03.txt + +STATUS OF THIS MEMO + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), + ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as draft- + ietf-krb-wg-kerberos-clarifications-03.txt, and expires 2 September + 2003. Please send comments to: ietf-krb-wg@anl.gov + +ABSTRACT + + This document provides an overview and specification of Version 5 of + the Kerberos protocol, and updates RFC1510 to clarify aspects of the + protocol and its intended use that require more detailed or clearer + explanation than was provided in RFC1510. This document is intended + to provide a detailed description of the protocol, suitable for + implementation, together with descriptions of the appropriate use of + protocol messages and fields within those messages. + + + +March 2003 [Page 1] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + This document contains a subset of the changes considered and + discussed in the Kerberos working group and is intended as an interim + description of Kerberos. Additional changes to the Kerberos protocol + have been proposed and will appear in a subsequent extensions + document. + + This document is not intended to describe Kerberos to the end user, + system administrator, or application developer. Higher level papers + describing Version 5 of the Kerberos system [NT94] and documenting + version 4 [SNS88], are available elsewhere. + +OVERVIEW + + This INTERNET-DRAFT describes the concepts and model upon which the + Kerberos network authentication system is based. It also specifies + Version 5 of the Kerberos protocol. + + The motivations, goals, assumptions, and rationale behind most design + decisions are treated cursorily; they are more fully described in a + paper available in IEEE communications [NT94] and earlier in the + Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols + have been a proposed standard and are being considered for + advancement for draft standard through the IETF standard process. + Comments are encouraged on the presentation, but only minor + refinements to the protocol as implemented or extensions that fit + within current protocol framework will be considered at this time. + + Requests for addition to an electronic mailing list for discussion of + Kerberos, kerberos@MIT.EDU, may be addressed to kerberos- + request@MIT.EDU. This mailing list is gatewayed onto the Usenet as + the group comp.protocols.kerberos. Requests for further information, + including documents and code availability, may be sent to info- + kerberos@MIT.EDU. + +BACKGROUND + + The Kerberos model is based in part on Needham and Schroeder's + trusted third-party authentication protocol [NS78] and on + modifications suggested by Denning and Sacco [DS81]. The original + design and implementation of Kerberos Versions 1 through 4 was the + work of two former Project Athena staff members, Steve Miller of + Digital Equipment Corporation and Clifford Neuman (now at the + Information Sciences Institute of the University of Southern + California), along with Jerome Saltzer, Technical Director of Project + Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other + members of Project Athena have also contributed to the work on + Kerberos. + + + + +March 2003 [Page 2] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Version 5 of the Kerberos protocol (described in this document) has + evolved from Version 4 based on new requirements and desires for + features not available in Version 4. The design of Version 5 of the + Kerberos protocol was led by Clifford Neuman and John Kohl with much + input from the community. The development of the MIT reference + implementation was led at MIT by John Kohl and Theodore Ts'o, with + help and contributed code from many others. Since RFC1510 was issued, + extensions and revisions to the protocol have been proposed by many + individuals. Some of these proposals are reflected in this document. + Where such changes involved significant effort, the document cites + the contribution of the proposer. + + Reference implementations of both version 4 and version 5 of Kerberos + are publicly available and commercial implementations have been + developed and are widely used. Details on the differences between + Kerberos Versions 4 and 5 can be found in [KNT94]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +March 2003 [Page 3] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + TTaabbllee ooff CCoonntteennttss + + +1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 7 +1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . . 9 +1.2. Choosing a principal with which to communicate . . . . . . . . 10 +1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 11 +1.4. Extending Kerberos Without Breaking Interoperability . . . . . 11 +1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . . 12 +1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . . 13 +1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . . 13 +1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . . 14 +2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . . 16 +2.1. Initial, pre-authenticated, and hardware authenticated + tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 +2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . . 17 +2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . . 18 +2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . . 18 +2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . . 19 +2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . . 20 +2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . . 21 +2.8. OK as Delegate . . . . . . . . . . . . . . . . . . . . . . . . 21 +2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . . 22 +2.9.1. Renewable-OK . . . . . . . . . . . . . . . . . . . . . . . . 22 +2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . . 22 +2.9.3. Passwordless Hardware Authentication . . . . . . . . . . . . 22 +3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 23 +3.1. The Authentication Service Exchange . . . . . . . . . . . . . . 23 +3.1.1. Generation of KRB_AS_REQ message . . . . . . . . . . . . . . 24 +3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . . 24 +3.1.3. Generation of KRB_AS_REP message . . . . . . . . . . . . . . 25 +3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . . 27 +3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . . 28 +3.1.6. Receipt of KRB_ERROR message . . . . . . . . . . . . . . . . 29 +3.2. The Client/Server Authentication Exchange . . . . . . . . . . . 29 +3.2.1. The KRB_AP_REQ message . . . . . . . . . . . . . . . . . . . 29 +3.2.2. Generation of a KRB_AP_REQ message . . . . . . . . . . . . . 29 +3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . . 30 +3.2.4. Generation of a KRB_AP_REP message . . . . . . . . . . . . . 32 +3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . . 33 +3.2.6. Using the encryption key . . . . . . . . . . . . . . . . . . 33 +3.3. The Ticket-Granting Service (TGS) Exchange . . . . . . . . . . 34 +3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . . 35 +3.3.2. Receipt of KRB_TGS_REQ message . . . . . . . . . . . . . . . 37 +3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . . 37 +3.3.3.1. Checking for revoked tickets . . . . . . . . . . . . . . . 40 +3.3.3.2. Encoding the transited field . . . . . . . . . . . . . . . 40 +3.3.4. Receipt of KRB_TGS_REP message . . . . . . . . . . . . . . . 42 + + + +March 2003 [Page 4] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . . 42 +3.4.1. Generation of a KRB_SAFE message . . . . . . . . . . . . . . 42 +3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . . 43 +3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . . 44 +3.5.1. Generation of a KRB_PRIV message . . . . . . . . . . . . . . 44 +3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . . 44 +3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . . 45 +3.6.1. Generation of a KRB_CRED message . . . . . . . . . . . . . . 45 +3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . . 46 +3.7. User to User Authentication Exchanges . . . . . . . . . . . . . 46 +4. Encryption and Checksum Specifications . . . . . . . . . . . . . 48 +5. Message Specifications . . . . . . . . . . . . . . . . . . . . . 49 +5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . . 51 +5.1.1. ASN.1 Distinguished Encoding Rules . . . . . . . . . . . . . 51 +5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . . 51 +5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . . 51 +5.1.4. Unrecognized Tag Numbers . . . . . . . . . . . . . . . . . . 52 +5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . . 52 +5.2. Basic Kerberos Types . . . . . . . . . . . . . . . . . . . . . 52 +5.2.1. KerberosString . . . . . . . . . . . . . . . . . . . . . . . 52 +5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . . 54 +5.2.3. KerberosTime . . . . . . . . . . . . . . . . . . . . . . . . 54 +5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . . 55 +5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . . 55 +5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . . 56 +5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . . 57 +5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . . 57 +5.2.6.3. AND-OR . . . . . . . . . . . . . . . . . . . . . . . . . . 59 +5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . . 59 +5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 +5.2.7.1. PA-TGS-REQ . . . . . . . . . . . . . . . . . . . . . . . . 60 +5.2.7.2. Encrypted Timestamp Pre-authentication . . . . . . . . . . 60 +5.2.7.3. PA-PW-SALT . . . . . . . . . . . . . . . . . . . . . . . . 61 +5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . . 61 +5.2.7.5. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . . 62 +5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . . 63 +5.2.9. Cryptosystem-related Types . . . . . . . . . . . . . . . . . 64 +5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 +5.4. Specifications for the AS and TGS exchanges . . . . . . . . . . 73 +5.4.1. KRB_KDC_REQ definition . . . . . . . . . . . . . . . . . . . 73 +5.4.2. KRB_KDC_REP definition . . . . . . . . . . . . . . . . . . . 80 +5.5. Client/Server (CS) message specifications . . . . . . . . . . . 84 +5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . . 84 +5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . . 87 +5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . . 88 +5.6. KRB_SAFE message specification . . . . . . . . . . . . . . . . 88 +5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . . 88 +5.7. KRB_PRIV message specification . . . . . . . . . . . . . . . . 90 + + + +March 2003 [Page 5] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . . 90 +5.8. KRB_CRED message specification . . . . . . . . . . . . . . . . 91 +5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . . 91 +5.9. Error message specification . . . . . . . . . . . . . . . . . . 93 +5.9.1. KRB_ERROR definition . . . . . . . . . . . . . . . . . . . . 93 +5.10. Application Tag Numbers . . . . . . . . . . . . . . . . . . . 95 +6. Naming Constraints . . . . . . . . . . . . . . . . . . . . . . . 96 +6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . . 96 +6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . . 98 +6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 99 +7. Constants and other defined values . . . . . . . . . . . . . . . 100 +7.1. Host address types . . . . . . . . . . . . . . . . . . . . . . 100 +7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101 +7.2.1. UDP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101 +7.2.2. TCP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101 +7.2.3. KDC Discovery on IP Networks . . . . . . . . . . . . . . . . 103 +7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names . . . . 103 +7.2.3.2. Specifying KDC Location information with DNS SRV + records . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 +7.2.3.3. KDC Discovery for Domain Style Realm Names on IP + Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 +7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 104 +7.4. OID arc for KerberosV5 . . . . . . . . . . . . . . . . . . . . 104 +7.5. Protocol constants and associated values . . . . . . . . . . . 104 +7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105 +7.5.2. PreAuthentication Data Types . . . . . . . . . . . . . . . . 106 +7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 107 +7.5.4. Authorization Data Types . . . . . . . . . . . . . . . . . . 107 +7.5.5. Transited Encoding Types . . . . . . . . . . . . . . . . . . 107 +7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 107 +7.5.7. Kerberos Message Types . . . . . . . . . . . . . . . . . . . 108 +7.5.8. Name Types . . . . . . . . . . . . . . . . . . . . . . . . . 108 +7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 108 +8. Interoperability requirements . . . . . . . . . . . . . . . . . . 110 +8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 110 +8.2. Recommended KDC values . . . . . . . . . . . . . . . . . . . . 113 +9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 113 +10. Security Considerations . . . . . . . . . . . . . . . . . . . . 113 +11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 +12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 117 +13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 +A. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 120 +B. Changes since RFC-1510 . . . . . . . . . . . . . . . . . . . . . 129 +END NOTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 + + + + + + + +March 2003 [Page 6] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +1. Introduction + + Kerberos provides a means of verifying the identities of principals, + (e.g. a workstation user or a network server) on an open + (unprotected) network. This is accomplished without relying on + assertions by the host operating system, without basing trust on host + addresses, without requiring physical security of all the hosts on + the network, and under the assumption that packets traveling along + the network can be read, modified, and inserted at will[1]. Kerberos + performs authentication under these conditions as a trusted third- + party authentication service by using conventional (shared secret key + [2]) cryptography. Kerberos extensions (outside the scope of this + document) can provide for the use of public key cryptography during + certain phases of the authentication protocol [@RFCE: if PKINIT + advances concurrently include reference to the RFC here]. Such + extensions support Kerberos authentication for users registered with + public key certification authorities and provide certain benefits of + public key cryptography in situations where they are needed. + + The basic Kerberos authentication process proceeds as follows: A + client sends a request to the authentication server (AS) requesting + "credentials" for a given server. The AS responds with these + credentials, encrypted in the client's key. The credentials consist + of a "ticket" for the server and a temporary encryption key (often + called a "session key"). The client transmits the ticket (which + contains the client's identity and a copy of the session key, all + encrypted in the server's key) to the server. The session key (now + shared by the client and server) is used to authenticate the client, + and may optionally be used to authenticate the server. It may also be + used to encrypt further communication between the two parties or to + exchange a separate sub-session key to be used to encrypt further + communication. + + Implementation of the basic protocol consists of one or more + authentication servers running on physically secure hosts. The + authentication servers maintain a database of principals (i.e., users + and servers) and their secret keys. Code libraries provide encryption + and implement the Kerberos protocol. In order to add authentication + to its transactions, a typical network application adds one or two + calls to the Kerberos library directly or through the Generic + Security Services Application Programming Interface, GSSAPI, + described in separate document [ref to GSSAPI RFC]. These calls + result in the transmission of the necessary messages to achieve + authentication. + + The Kerberos protocol consists of several sub-protocols (or + exchanges). There are two basic methods by which a client can ask a + Kerberos server for credentials. In the first approach, the client + + + +March 2003 [Page 7] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + sends a cleartext request for a ticket for the desired server to the + AS. The reply is sent encrypted in the client's secret key. Usually + this request is for a ticket-granting ticket (TGT) which can later be + used with the ticket-granting server (TGS). In the second method, + the client sends a request to the TGS. The client uses the TGT to + authenticate itself to the TGS in the same manner as if it were + contacting any other application server that requires Kerberos + authentication. The reply is encrypted in the session key from the + TGT. Though the protocol specification describes the AS and the TGS + as separate servers, they are implemented in practice as different + protocol entry points within a single Kerberos server. + + Once obtained, credentials may be used to verify the identity of the + principals in a transaction, to ensure the integrity of messages + exchanged between them, or to preserve privacy of the messages. The + application is free to choose whatever protection may be necessary. + + To verify the identities of the principals in a transaction, the + client transmits the ticket to the application server. Since the + ticket is sent "in the clear" (parts of it are encrypted, but this + encryption doesn't thwart replay) and might be intercepted and reused + by an attacker, additional information is sent to prove that the + message originated with the principal to whom the ticket was issued. + This information (called the authenticator) is encrypted in the + session key, and includes a timestamp. The timestamp proves that the + message was recently generated and is not a replay. Encrypting the + authenticator in the session key proves that it was generated by a + party possessing the session key. Since no one except the requesting + principal and the server know the session key (it is never sent over + the network in the clear) this guarantees the identity of the client. + + The integrity of the messages exchanged between principals can also + be guaranteed using the session key (passed in the ticket and + contained in the credentials). This approach provides detection of + both replay attacks and message stream modification attacks. It is + accomplished by generating and transmitting a collision-proof + checksum (elsewhere called a hash or digest function) of the client's + message, keyed with the session key. Privacy and integrity of the + messages exchanged between principals can be secured by encrypting + the data to be passed using the session key contained in the ticket + or the sub-session key found in the authenticator. + + The authentication exchanges mentioned above require read-only access + to the Kerberos database. Sometimes, however, the entries in the + database must be modified, such as when adding new principals or + changing a principal's key. This is done using a protocol between a + client and a third Kerberos server, the Kerberos Administration + Server (KADM). There is also a protocol for maintaining multiple + + + +March 2003 [Page 8] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + copies of the Kerberos database. Neither of these protocols are + described in this document. + +1.1. Cross-realm operation + + The Kerberos protocol is designed to operate across organizational + boundaries. A client in one organization can be authenticated to a + server in another. Each organization wishing to run a Kerberos server + establishes its own "realm". The name of the realm in which a client + is registered is part of the client's name, and can be used by the + end-service to decide whether to honor a request. + + By establishing "inter-realm" keys, the administrators of two realms + can allow a client authenticated in the local realm to prove its + identity to servers in other realms[3]. The exchange of inter-realm + keys (a separate key may be used for each direction) registers the + ticket-granting service of each realm as a principal in the other + realm. A client is then able to obtain a ticket-granting ticket for + the remote realm's ticket-granting service from its local realm. When + that ticket-granting ticket is used, the remote ticket-granting + service uses the inter-realm key (which usually differs from its own + normal TGS key) to decrypt the ticket-granting ticket, and is thus + certain that it was issued by the client's own TGS. Tickets issued by + the remote ticket-granting service will indicate to the end-service + that the client was authenticated from another realm. + + A realm is said to communicate with another realm if the two realms + share an inter-realm key, or if the local realm shares an inter-realm + key with an intermediate realm that communicates with the remote + realm. An authentication path is the sequence of intermediate realms + that are transited in communicating from one realm to another. + + Realms may be organized hierarchically. Each realm shares a key with + its parent and a different key with each child. If an inter-realm key + is not directly shared by two realms, the hierarchical organization + allows an authentication path to be easily constructed. If a + hierarchical organization is not used, it may be necessary to consult + a database in order to construct an authentication path between + realms. + + Although realms are typically hierarchical, intermediate realms may + be bypassed to achieve cross-realm authentication through alternate + authentication paths (these might be established to make + communication between two realms more efficient). It is important for + the end-service to know which realms were transited when deciding how + much faith to place in the authentication process. To facilitate this + decision, a field in each ticket contains the names of the realms + that were involved in authenticating the client. + + + +March 2003 [Page 9] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + The application server is ultimately responsible for accepting or + rejecting authentication and SHOULD check the transited field. The + application server may choose to rely on the KDC for the application + server's realm to check the transited field. The application server's + KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs + for intermediate realms may also check the transited field as they + issue ticket-granting tickets for other realms, but they are + encouraged not to do so. A client may request that the KDCs not check + the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs + are encouraged but not required to honor this flag. + +1.2. Choosing a principal with which to communicate + + The Kerberos protocol provides the means for verifying (subject to + the assumptions in 1.5) that the entity with which one communicates + is the same entity that was registered with the KDC using the claimed + identity (principal name). It is still necessary to determine whether + that identity corresponds to the entity with which one intends to + communicate. + + When appropriate data has been exchanged in advance, this + determination may be performed syntactically by the application based + on the application protocol specification, information provided by + the user, and configuration files. For example, the server principal + name (including realm) for a telnet server might be derived from the + user specified host name (from the telnet command line), the "host/" + prefix specified in the application protocol specification, and a + mapping to a Kerberos realm derived syntactically from the domain + part of the specified hostname and information from the local + Kerberos realms database. + + One can also rely on trusted third parties to make this + determination, but only when the data obtained from the third party + is suitably integrity protected while resident on the third party + server and when transmitted. Thus, for example, one should not rely + on an unprotected domain name system record to map a host alias to + the primary name of a server, accepting the primary name as the party + one intends to contact, since an attacker can modify the mapping and + impersonate the party with which one intended to communicate. + + Implementations of Kerberos and protocols based on Kerberos MUST NOT + use insecure DNS queries to canonicalize the hostname components of + the service principal names. In an environment without secure name + service, application authors MAY append a statically configured + domain name to unqualified hostnames before passing the name to the + security mechanisms, but should do no more than that. Secure name + service facilities, if available, might be trusted for hostname + canonicalization, but such canonicalization by the client SHOULD NOT + + + +March 2003 [Page 10] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + be required by an KDC implementation. + + Implementation note: Many current implementations do some degree of + canonicalization of the provided service name, often using DNS even + though it creates security problems. However there is no consistency + among implementations about whether the service name is case folded + to lower case or whether reverse resolution is used. To maximize + interoperability and security, applications SHOULD provide security + mechanisms with names which result from folding the user-entered name + to lower case, without performing any other modifications or + canonicalization. + +1.3. Authorization + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. Authentication is usually + useful primarily as a first step in the process of authorization, + determining whether a client may use a service, which objects the + client is allowed to access, and the type of access allowed for each. + Kerberos does not, by itself, provide authorization. Possession of a + client ticket for a service provides only for authentication of the + client to that service, and in the absence of a separate + authorization procedure, it should not be considered by an + application as authorizing the use of that service. + + Such separate authorization methods MAY be implemented as application + specific access control functions and may utilize files on the + application server, or on separately issued authorization credentials + such as those based on proxies [Neu93], or on other authorization + services. Separately authenticated authorization credentials MAY be + embedded in a ticket's authorization data when encapsulated by the + KDC-issued authorization data element. + + Applications should not accept the mere issuance of a service ticket + by the Kerberos server (even by a modified Kerberos server) as + granting authority to use the service, since such applications may + become vulnerable to the bypass of this authorization check in an + environment if they interoperate with other KDCs or where other + options for application authentication (e.g. the PKTAPP proposal) + are provided. + +1.4. Extending Kerberos Without Breaking Interoperability + + As the deployed base of Kerberos implementations grows, extending + Kerberos becomes more important. Unfortunately some extensions to the + existing Kerberos protocol create interoperability issues because of + uncertainty regarding the treatment of certain extensibility options + by some implementations. This section includes guidelines that will + + + +March 2003 [Page 11] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + enable future implementations to maintain interoperability. + + Kerberos provides a general mechanism for protocol extensibility. + Some protocol messages contain typed holes -- sub-messages that + contain an octet-string along with an integer that defines how to + interpret the octet-string. The integer types are registered + centrally, but can be used both for vendor extensions and for + extensions standardized through the IETF. + +1.4.1. Compatibility with RFC 1510 + + It is important to note that existing Kerberos message formats can + not be readily extended by adding fields to the ASN.1 types. Sending + additional fields often results in the entire message being discarded + without an error indication. Future versions of this specification + will provide guidelines to ensure that ASN.1 fields can be added + without creating an interoperability problem. + + In the meantime, all new or modified implementations of Kerberos that + receive an unknown message extension SHOULD preserve the encoding of + the extension but otherwise ignore the presence of the extension. + Recipients MUST NOT decline a request simply because an extension is + present. + + There is one exception to this rule. If an unknown authorization data + element type is received by a server other than the ticket granting + service either in an AP-REQ or in a ticket contained in an AP-REQ, + then authentication MUST fail. One of the primary uses of + authorization data is to restrict the use of the ticket. If the + service cannot determine whether the restriction applies to that + service then a security weakness may result if the ticket can be used + for that service. Authorization elements that are optional SHOULD be + enclosed in the AD-IF-RELEVANT element. + + The ticket granting service MUST ignore but propagate to derivative + tickets any unknown authorization data types, unless those data types + are embedded in a MANDATORY-FOR-KDC element, in which case the + request will be rejected. This behavior is appropriate because + requiring that the ticket granting service understand unknown + authorization data types would require that KDC software be upgraded + to understand new application-level restrictions before applications + used these restrictions, decreasing the utility of authorization data + as a mechanism for restricting the use of tickets. No security + problem is created because services to which the tickets are issued + will verify the authorization data. + + Implementation note: Many RFC 1510 implementations ignore unknown + authorization data elements. Depending on these implementations to + + + +March 2003 [Page 12] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + honor authorization data restrictions may create a security weakness. + +1.4.2. Sending Extensible Messages + + Care must be taken to ensure that old implementations can understand + messages sent to them even if they do not understand an extension + that is used. Unless the sender knows an extension is supported, the + extension cannot change the semantics of the core message or + previously defined extensions. + + For example, an extension including key information necessary to + decrypt the encrypted part of a KDC-REP could only be used in + situations where the recipient was known to support the extension. + Thus when designing such extensions it is important to provide a way + for the recipient to notify the sender of support for the extension. + For example in the case of an extension that changes the KDC-REP + reply key, the client could indicate support for the extension by + including a padata element in the AS-REQ sequence. The KDC should + only use the extension if this padata element is present in the AS- + REQ. Even if policy requires the use of the extension, it is better + to return an error indicating that the extension is required than to + use the extension when the recipient may not support it; debugging + why implementations do not interoperate is easier when errors are + returned. + +1.5. Environmental assumptions + + Kerberos imposes a few assumptions on the environment in which it can + properly function: + + * "Denial of service" attacks are not solved with Kerberos. There + are places in the protocols where an intruder can prevent an + application from participating in the proper authentication steps. + Detection and solution of such attacks (some of which can appear + to be not-uncommon "normal" failure modes for the system) is + usually best left to the human administrators and users. + + * Principals MUST keep their secret keys secret. If an intruder + somehow steals a principal's key, it will be able to masquerade as + that principal or impersonate any server to the legitimate + principal. + + * "Password guessing" attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an offline dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained which are encrypted under a key derived from the + user's password. + + + +March 2003 [Page 13] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + * Each host on the network MUST have a clock which is "loosely + synchronized" to the time of the other hosts; this synchronization + is used to reduce the bookkeeping needs of application servers + when they do replay detection. The degree of "looseness" can be + configured on a per-server basis, but is typically on the order of + 5 minutes. If the clocks are synchronized over the network, the + clock synchronization protocol MUST itself be secured from network + attackers. + + * Principal identifiers are not recycled on a short-term basis. A + typical mode of access control will use access control lists + (ACLs) to grant permissions to particular principals. If a stale + ACL entry remains for a deleted principal and the principal + identifier is reused, the new principal will inherit rights + specified in the stale ACL entry. By not re-using principal + identifiers, the danger of inadvertent access is removed. + +1.6. Glossary of terms + + Below is a list of terms used throughout this document. + + Authentication + Verifying the claimed identity of a principal. + + Authentication header + A record containing a Ticket and an Authenticator to be presented + to a server as part of the authentication process. + + Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. + + Authenticator + A record containing information that can be shown to have been + recently generated using the session key known only by the client + and server. + + Authorization + The process of determining whether a client may use a service, + which objects the client is allowed to access, and the type of + access allowed for each. + + Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is + restricted by the contents of the authorization data field, but + which lists no network addresses, together with the session key + necessary to use the ticket. + + + +March 2003 [Page 14] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Ciphertext + The output of an encryption function. Encryption transforms + plaintext into ciphertext. + + Client + A process that makes use of a network service on behalf of a user. + Note that in some cases a Server may itself be a client of some + other server (e.g. a print server may be a client of a file + server). + + Credentials + A ticket plus the secret session key necessary to successfully use + that ticket in an authentication exchange. + + Encryption Type (etype) + When associated with encrypted data, an encryption type identifies + the algorithm used to encrypt the data and is used to select the + appropriate algorithm for decrypting the data. Encryption type + tags are communicated in other messages to enumerate algorithms + that are desired, supported, preferred, or allowed to be used for + encryption of data between parties. This preference is combined + with local information and policy to select an algorithm to be + used. + + KDC + Key Distribution Center, a network service that supplies tickets + and temporary session keys; or an instance of that service or the + host on which it runs. The KDC services both initial ticket and + ticket-granting ticket requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service). + The ticket-granting ticket portion is sometimes referred to as the + ticket-granting server (or service). + + Kerberos + The name given to the Project Athena's authentication service, the + protocol used by that service, or the code used to implement the + authentication service. The name is adopted from the three-headed + dog which guards Hades. + + Key Version Number (kvno) + A tag associated with encrypted data identifies which key was used + for encryption when a long lived key associated with a principal + changes over time. It is used during the transition to a new key + so that the party decrypting a message can tell whether the data + was encrypted using the old or the new key. + + Plaintext + The input to an encryption function or the output of a decryption + + + +March 2003 [Page 15] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + function. Decryption transforms ciphertext into plaintext. + + Principal + A named client or server entity that participates in a network + communication, with one name that is considered canonical. + + Principal identifier + The canonical name used to uniquely identify each different + principal. + + Seal + To encipher a record containing several fields in such a way that + the fields cannot be individually replaced without either + knowledge of the encryption key or leaving evidence of tampering. + + Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the + case of a human user's principal, the secret key MAY be derived + from a password. + + Server + A particular Principal which provides a resource to network + clients. The server is sometimes referred to as the Application + Server. + + Service + A resource provided to network clients; often provided by more + than one server (for example, remote file service). + + Session key + A temporary encryption key used between two principals, with a + lifetime limited to the duration of a single login "session". + + Sub-session key + A temporary encryption key used between two principals, selected + and exchanged by the principals using the session key, and with a + lifetime limited to the duration of a single association. + + Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and + other information, all sealed using the server's secret key. It + only serves to authenticate a client when presented along with a + fresh Authenticator. + + +2. Ticket flag uses and requests + + + +March 2003 [Page 16] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Each Kerberos ticket contains a set of flags which are used to + indicate attributes of that ticket. Most flags may be requested by a + client when the ticket is obtained; some are automatically turned on + and off by a Kerberos server as required. The following sections + explain what the various flags mean and give examples of reasons to + use them. With the exception of the INVALID flag clients MUST ignore + ticket flags that are not recognized. KDCs MUST ignore KDC options + that are not recognized. Some implementations of RFC 1510 are known + to reject unknown KDC options, so clients may need to resend a + request without KDC new options absent if the request was rejected + when sent with option added since RFC 1510. Since new KDCs will + ignore unknown options, clients MUST confirm that the ticket returned + by the KDC meets their needs. + + Note that it is not, in general, possible to determine whether an + option was not honored because it was not understood or because it + was rejected either through configuration or policy. When adding a + new option to the Kerberos protocol, designers should consider + whether the distinction is important for their option. In cases where + it is, a mechanism for the KDC to return an indication that the + option was understood but rejected needs to be provided in the + specification of the option. Often in such cases, the mechanism needs + to be broad enough to permit an error or reason to be returned. + +2.1. Initial, pre-authenticated, and hardware authenticated tickets + + The INITIAL flag indicates that a ticket was issued using the AS + protocol, rather than issued based on a ticket-granting ticket. + Application servers that want to require the demonstrated knowledge + of a client's secret key (e.g. a password-changing program) can + insist that this flag be set in any tickets they accept, and thus be + assured that the client's key was recently presented to the + application client. + + The PRE-AUTHENT and HW-AUTHENT flags provide additional information + about the initial authentication, regardless of whether the current + ticket was issued directly (in which case INITIAL will also be set) + or issued on the basis of a ticket-granting ticket (in which case the + INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are + carried forward from the ticket-granting ticket). + +2.2. Invalid tickets + + The INVALID flag indicates that a ticket is invalid. Application + servers MUST reject tickets which have this flag set. A postdated + ticket will be issued in this form. Invalid tickets MUST be validated + by the KDC before use, by presenting them to the KDC in a TGS request + with the VALIDATE option specified. The KDC will only validate + + + +March 2003 [Page 17] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + tickets after their starttime has passed. The validation is required + so that postdated tickets which have been stolen before their + starttime can be rendered permanently invalid (through a hot-list + mechanism) (see section 3.3.3.1). + +2.3. Renewable tickets + + Applications may desire to hold tickets which can be valid for long + periods of time. However, this can expose their credentials to + potential theft for equally long periods, and those stolen + credentials would be valid until the expiration time of the + ticket(s). Simply using short-lived tickets and obtaining new ones + periodically would require the client to have long-term access to its + secret key, an even greater risk. Renewable tickets can be used to + mitigate the consequences of theft. Renewable tickets have two + "expiration times": the first is when the current instance of the + ticket expires, and the second is the latest permissible value for an + individual expiration time. An application client must periodically + (i.e. before it expires) present a renewable ticket to the KDC, with + the RENEW option set in the KDC request. The KDC will issue a new + ticket with a new session key and a later expiration time. All other + fields of the ticket are left unmodified by the renewal process. When + the latest permissible expiration time arrives, the ticket expires + permanently. At each renewal, the KDC MAY consult a hot-list to + determine if the ticket had been reported stolen since its last + renewal; it will refuse to renew such stolen tickets, and thus the + usable lifetime of stolen tickets is reduced. + + The RENEWABLE flag in a ticket is normally only interpreted by the + ticket-granting service (discussed below in section 3.3). It can + usually be ignored by application servers. However, some particularly + careful application servers MAY disallow renewable tickets. + + If a renewable ticket is not renewed by its expiration time, the KDC + will not renew the ticket. The RENEWABLE flag is reset by default, + but a client MAY request it be set by setting the RENEWABLE option in + the KRB_AS_REQ message. If it is set, then the renew-till field in + the ticket contains the time after which the ticket may not be + renewed. + +2.4. Postdated tickets + + Applications may occasionally need to obtain tickets for use much + later, e.g. a batch submission system would need tickets to be valid + at the time the batch job is serviced. However, it is dangerous to + hold valid tickets in a batch queue, since they will be on-line + longer and more prone to theft. Postdated tickets provide a way to + obtain these tickets from the KDC at job submission time, but to + + + +March 2003 [Page 18] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + leave them "dormant" until they are activated and validated by a + further request of the KDC. If a ticket theft were reported in the + interim, the KDC would refuse to validate the ticket, and the thief + would be foiled. + + The MAY-POSTDATE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + This flag MUST be set in a ticket-granting ticket in order to issue a + postdated ticket based on the presented ticket. It is reset by + default; it MAY be requested by a client by setting the ALLOW- + POSTDATE option in the KRB_AS_REQ message. This flag does not allow + a client to obtain a postdated ticket-granting ticket; postdated + ticket-granting tickets can only by obtained by requesting the + postdating in the KRB_AS_REQ message. The life (endtime-starttime) of + a postdated ticket will be the remaining life of the ticket-granting + ticket at the time of the request, unless the RENEWABLE option is + also set, in which case it can be the full life (endtime-starttime) + of the ticket-granting ticket. The KDC MAY limit how far in the + future a ticket may be postdated. + + The POSTDATED flag indicates that a ticket has been postdated. The + application server can check the authtime field in the ticket to see + when the original authentication occurred. Some services MAY choose + to reject postdated tickets, or they may only accept them within a + certain period after the original authentication. When the KDC issues + a POSTDATED ticket, it will also be marked as INVALID, so that the + application client MUST present the ticket to the KDC to be validated + before use. + +2.5. Proxiable and proxy tickets + + At times it may be necessary for a principal to allow a service to + perform an operation on its behalf. The service must be able to take + on the identity of the client, but only for a particular purpose. A + principal can allow a service to take on the principal's identity for + a particular purpose by granting it a proxy. + + The process of granting a proxy using the proxy and proxiable flags + is used to provide credentials for use with specific services. Though + conceptually also a proxy, users wishing to delegate their identity + in a form usable for all purpose MUST use the ticket forwarding + mechanism described in the next section to forward a ticket-granting + ticket. + + The PROXIABLE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + When set, this flag tells the ticket-granting server that it is OK to + issue a new ticket (but not a ticket-granting ticket) with a + + + +March 2003 [Page 19] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + different network address based on this ticket. This flag is set if + requested by the client on initial authentication. By default, the + client will request that it be set when requesting a ticket-granting + ticket, and reset when requesting any other ticket. + + This flag allows a client to pass a proxy to a server to perform a + remote request on its behalf (e.g. a print service client can give + the print server a proxy to access the client's files on a particular + file server in order to satisfy a print request). + + In order to complicate the use of stolen credentials, Kerberos + tickets are usually valid from only those network addresses + specifically included in the ticket[4]. When granting a proxy, the + client MUST specify the new network address from which the proxy is + to be used, or indicate that the proxy is to be issued for use from + any address. + + The PROXY flag is set in a ticket by the TGS when it issues a proxy + ticket. Application servers MAY check this flag and at their option + they MAY require additional authentication from the agent presenting + the proxy in order to provide an audit trail. + +2.6. Forwardable tickets + + Authentication forwarding is an instance of a proxy where the service + granted is complete use of the client's identity. An example where it + might be used is when a user logs in to a remote system and wants + authentication to work from that system as if the login were local. + + The FORWARDABLE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + The FORWARDABLE flag has an interpretation similar to that of the + PROXIABLE flag, except ticket-granting tickets may also be issued + with different network addresses. This flag is reset by default, but + users MAY request that it be set by setting the FORWARDABLE option in + the AS request when they request their initial ticket-granting + ticket. + + This flag allows for authentication forwarding without requiring the + user to enter a password again. If the flag is not set, then + authentication forwarding is not permitted, but the same result can + still be achieved if the user engages in the AS exchange specifying + the requested network addresses and supplies a password. + + The FORWARDED flag is set by the TGS when a client presents a ticket + with the FORWARDABLE flag set and requests a forwarded ticket by + specifying the FORWARDED KDC option and supplying a set of addresses + for the new ticket. It is also set in all tickets issued based on + + + +March 2003 [Page 20] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + tickets with the FORWARDED flag set. Application servers may choose + to process FORWARDED tickets differently than non-FORWARDED tickets. + + If addressless tickets are forwarded from one system to another, + clients SHOULD still use this option to obtain a new TGT in order to + have different session keys on the different systems. + +2.7. Transited Policy Checking + + In Kerberos, the application server is ultimately responsible for + accepting or rejecting authentication and SHOULD check that only + suitably trusted KDCs are relied upon to authenticate a principal. + The transited field in the ticket identifies which realms (and thus + which KDCs) were involved in the authentication process and an + application server would normally check this field. If any of these + are untrusted to authenticate the indicated client principal + (probably determined by a realm-based policy), the authentication + attempt MUST be rejected. The presence of trusted KDCs in this list + does not provide any guarantee; an untrusted KDC may have fabricated + the list. + + While the end server ultimately decides whether authentication is + valid, the KDC for the end server's realm MAY apply a realm specific + policy for validating the transited field and accepting credentials + for cross-realm authentication. When the KDC applies such checks and + accepts such cross-realm authentication it will set the TRANSITED- + POLICY-CHECKED flag in the service tickets it issues based on the + cross-realm TGT. A client MAY request that the KDCs not check the + transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are + encouraged but not required to honor this flag. + + Application servers MUST either do the transited-realm checks + themselves, or reject cross-realm tickets without TRANSITED-POLICY- + CHECKED set. + +2.8. OK as Delegate + + For some applications a client may need to delegate authority to a + server to act on its behalf in contacting other services. This + requires that the client forward credentials to an intermediate + server. The ability for a client to obtain a service ticket to a + server conveys no information to the client about whether the server + should be trusted to accept delegated credentials. The OK-AS- + DELEGATE provides a way for a KDC to communicate local realm policy + to a client regarding whether an intermediate server is trusted to + accept such credentials. + + The OK-AS-DELEGATE flag from the copy of the ticket flags in the + + + +March 2003 [Page 21] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + encrypted part of the KDC reply indicates to the client that the + server (not the client) specified in the ticket has been determined + by policy of the realm to be a suitable recipient of delegation. A + client can use the presence of this flag to help it make a decision + whether to delegate credentials (either grant a proxy or a forwarded + ticket-granting ticket) to this server. Ignore the value of this + flag. When setting this flag, an administrator should consider the + Security and placement of the server on which the service will run, + as well as whether the service requires the use of delegated + credentials. + +2.9. Other KDC options + + There are three additional options which MAY be set in a client's + request of the KDC. + +2.9.1. Renewable-OK + + The RENEWABLE-OK option indicates that the client will accept a + renewable ticket if a ticket with the requested life cannot otherwise + be provided. If a ticket with the requested life cannot be provided, + then the KDC MAY issue a renewable ticket with a renew-till equal to + the requested endtime. The value of the renew-till field MAY still be + adjusted by site-determined limits or limits imposed by the + individual principal or server. + +2.9.2. ENC-TKT-IN-SKEY + + In its basic form the Kerberos protocol supports authentication in a + client-server + setting and is not well suited to authentication in a peer-to-peer + environment because the long term key of the user does not remain on + the workstation after initial login. Authentication of such peers may + be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN- + SKEY option supports user-to-user authentication by allowing the KDC + to issue a service ticket encrypted using the session key from + another ticket-granting ticket issued to another user. The ENC-TKT- + IN-SKEY option is honored only by the ticket-granting service. It + indicates that the ticket to be issued for the end server is to be + encrypted in the session key from the additional second ticket- + granting ticket provided with the request. See section 3.3.3 for + specific details. + +2.9.3. Passwordless Hardware Authentication + + The OPT-HARDWARE-AUTH option indicates that the client wishes to use + some form of hardware authentication instead of or in addition to the + client's password or other long-lived encryption key. OPT-HARDWARE- + + + +March 2003 [Page 22] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + AUTH is honored only by the authentication service. If supported and + allowed by policy, the KDC will return an errorcode + KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to + perform such authentication. + +3. Message Exchanges + + The following sections describe the interactions between network + clients and servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The Authentication Service (AS) Exchange between the client and the + Kerberos Authentication Server is initiated by a client when it + wishes to obtain authentication credentials for a given server but + currently holds no credentials. In its basic form, the client's + secret key is used for encryption and decryption. This exchange is + typically used at the initiation of a login session to obtain + credentials for a Ticket-Granting Server which will subsequently be + used to obtain credentials for other servers (see section 3.3) + without requiring further use of the client's secret key. This + exchange is also used to request credentials for services which must + not be mediated through the Ticket-Granting Service, but rather + require a principal's secret key, such as the password-changing + service[5]. This exchange does not by itself provide any assurance of + the identity of the user[6]. + + The exchange consists of two messages: KRB_AS_REQ from the client to + Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these + messages are described in sections 5.4.1, 5.4.2, and 5.9.1. + + In the request, the client sends (in cleartext) its own identity and + the identity of the server for which it is requesting credentials, + other information about the credentials it is requesting, and a + randomly generated nonce which can be used to detect replays, and to + associate replies with the matching requests. This nonce MUST be + generated randomly by the client and remembered for checking against + the nonce in the expected reply. The response, KRB_AS_REP, contains a + ticket for the client to present to the server, and a session key + that will be shared by the client and the server. The session key + and additional information are encrypted in the client's secret key. + + + +March 2003 [Page 23] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + The encrypted part of the KRB_AS_REP message also contains the nonce + which MUST be matched with the nonce from the KRB_AS_REQ message. + + Without pre-authentication, the authentication server does not know + whether the client is actually the principal named in the request. It + simply sends a reply without knowing or caring whether they are the + same. This is acceptable because nobody but the principal whose + identity was given in the request will be able to use the reply. Its + critical information is encrypted in that principal's key. However, + an attacker can send a KRB_AS_REQ message to get known plaintext in + order to attack the principal's key. Especially if the key is based + on a password, this may create a security exposure. So, the initial + request supports an optional field that can be used to pass + additional information that might be needed for the initial exchange. + This field SHOULD be used for pre-authentication as described in + sections 3.1.1 and 5.2.7. + + Various errors can occur; these are indicated by an error response + (KRB_ERROR) instead of the KRB_AS_REP response. The error message is + not encrypted. The KRB_ERROR message contains information which can + be used to associate it with the message to which it replies. The + contents of the KRB_ERROR message are not integrity-protected. As + such, the client cannot detect replays, fabrications or + modifications. A solution to this problem will be included in a + future version of the protocol. + +3.1.1. Generation of KRB_AS_REQ message + + The client may specify a number of options in the initial request. + Among these options are whether pre-authentication is to be + performed; whether the requested ticket is to be renewable, + proxiable, or forwardable; whether it should be postdated or allow + postdating of derivative tickets; and whether a renewable ticket will + be accepted in lieu of a non-renewable ticket if the requested ticket + expiration date cannot be satisfied by a non-renewable ticket (due to + configuration constraints). + + The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + + If all goes well, processing the KRB_AS_REQ message will result in + the creation of a ticket for the client to present to the server. The + format for the ticket is described in section 5.3. The contents of + the ticket are determined as follows. + + Because Kerberos can run over unreliable transports such as UDP, the + KDC MUST be prepared to retransmit responses in case they are lost. + + + +March 2003 [Page 24] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + If a KDC receives a request identical to one it has recently + successfully processed, the KDC MUST respond with a KRB_AS_REP + message rather than a replay error. In order to reduce ciphertext + given to a potential attacker, KDCs MAY send the same response + generated when the request was first handled. KDCs MUST obey this + replay behavior even if the actual transport in use is reliable. + +3.1.3. Generation of KRB_AS_REP message + + The authentication server looks up the client and server principals + named in the KRB_AS_REQ in its database, extracting their respective + keys. If the requested client principal named in the request is not + known because it doesn't exist in the KDC's principal database, then + an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. + + If required, the server pre-authenticates the request, and if the + pre-authentication check fails, an error message with the code + KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is + required, but was not present in the request, an error message with + the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA + object will be stored in the e-data field of the KRB-ERROR message to + specify which pre-authentication mechanisms are acceptable. Usually + this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as + described below. If the server cannot accommodate any encryption type + requested by the client, an error message with code + KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a + 'random' session key[7]. + + When responding to an AS request, if there are multiple encryption + keys registered for a client in the Kerberos database, then the etype + field from the AS request is used by the KDC to select the encryption + method to be used to protect the encrypted part of the KRB_AS_REP + message which is sent to the client. If there is more than one + supported strong encryption type in the etype list, the KDC SHOULD + use the first valid strong etype for which an encryption key is + available. + + When the user's key is generated from a password or pass phrase, the + string-to-key function for the particular encryption key type is + used, as specified in [@KCRYPTO]. The salt value and additional + parameters for the string-to-key function have default values + (specified by section 4 and by the encryption mechanism + specification, respectively) that may be overridden by pre- + authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA- + ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the + resulting key only, these values should not be changed for password- + based keys except when changing the principal's key. + + + + +March 2003 [Page 25] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + When the AS server is to include pre-authentication data in a KRB- + ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO, + if the etype field of the client's AS-REQ lists at least one "newer" + encryption type. Otherwise (when the etype field of the client's AS- + REQ does not list any "newer" encryption types) it MUST send both, + PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each + enctype). A "newer" enctype is any enctype first officially + specified concurrently with or subsequent to the issue of this RFC. + The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not + newer enctypes. + + It is not possible to reliably generate a user's key given a pass + phrase without contacting the KDC, since it will not be known whether + alternate salt or parameter values are required. + + The KDC will attempt to assign the type of the random session key + from the list of methods in the etype field. The KDC will select the + appropriate type using the list of methods provided together with + information from the Kerberos database indicating acceptable + encryption methods for the application server. The KDC will not issue + tickets with a weak session key encryption type. + + If the requested start time is absent, indicates a time in the past, + or is within the window of acceptable clock skew for the KDC and the + POSTDATE option has not been specified, then the start time of the + ticket is set to the authentication server's current time. If it + indicates a time in the future beyond the acceptable clock skew, but + the POSTDATED option has not been specified then the error + KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start + time is checked against the policy of the local realm (the + administrator might decide to prohibit certain types or ranges of + postdated tickets), and if acceptable, the ticket's start time is set + as requested and the INVALID flag is set in the new ticket. The + postdated ticket MUST be validated before use by presenting it to the + KDC after the start time has been reached. + + The expiration time of the ticket will be set to the earlier of the + requested endtime and a time determined by local policy, possibly + determined using realm or principal specific factors. For example, + the expiration time MAY be set to the earliest of the following: + + * The expiration time (endtime) requested in the KRB_AS_REQ + message. + + * The ticket's start time plus the maximum allowable lifetime + associated with the client principal from the authentication + server's database. + + + + +March 2003 [Page 26] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + * The ticket's start time plus the maximum allowable lifetime + associated with the server principal. + + * The ticket's start time plus the maximum lifetime set by the + policy of the local realm. + + If the requested expiration time minus the start time (as determined + above) is less than a site-determined minimum lifetime, an error + message with code KDC_ERR_NEVER_VALID is returned. If the requested + expiration time for the ticket exceeds what was determined as above, + and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' + flag is set in the new ticket, and the renew-till value is set as if + the 'RENEWABLE' option were requested (the field and option names are + described fully in section 5.4.1). + + If the RENEWABLE option has been requested or if the RENEWABLE-OK + option has been set and a renewable ticket is to be issued, then the + renew-till field MAY be set to the earliest of: + + * Its requested value. + + * The start time of the ticket plus the minimum of the two + maximum renewable lifetimes associated with the principals' + database entries. + + * The start time of the ticket plus the maximum renewable + lifetime set by the policy of the local realm. + + The flags field of the new ticket will have the following options set + if they have been requested and if the policy of the local realm + allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. + If the new ticket is postdated (the start time is in the future), its + INVALID flag will also be set. + + If all of the above succeed, the server will encrypt the ciphertext + part of the ticket using the encryption key extracted from the server + principal's record in the Kerberos database using the encryption type + associated with the server principal's key (this choice is NOT + affected by the etype field in the request). It then formats a + KRB_AS_REP message (see section 5.4.2), copying the addresses in the + request into the caddr of the response, placing any required pre- + authentication data into the padata of the response, and encrypts the + ciphertext part in the client's key using an acceptable encryption + method requested in the etype field of the request, or in some key + specified by pre-authentication mechanisms being used. + +3.1.4. Generation of KRB_ERROR message + + + + +March 2003 [Page 27] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Several errors can occur, and the Authentication Server responds by + returning an error message, KRB_ERROR, to the client, with the error- + code and e-text fields set to appropriate values. The error message + contents and details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP message + + If the reply message type is KRB_AS_REP, then the client verifies + that the cname and crealm fields in the cleartext portion of the + reply match what it requested. If any padata fields are present, they + may be used to derive the proper secret key to decrypt the message. + The client decrypts the encrypted part of the response using its + secret key, verifies that the nonce in the encrypted part matches the + nonce it supplied in its request (to detect replays). It also + verifies that the sname and srealm in the response match those in the + request (or are otherwise expected values), and that the host address + field is also correct. It then stores the ticket, session key, start + and expiration times, and other information for later use. The last- + req field (and the deprecated key-expiration field) from the + encrypted part of the response MAY be checked to notify the user of + impending key expiration. This enables the client program to suggest + remedial action, such as a password change. + + Upon validation of the KRB_AS_REP message (by checking the returned + nonce against that sent in the KRB_AS_REQ message) the client knows + that the current time on the KDC is that read from the authtime field + of the encrypted part of the reply. The client can optionally use + this value for clock synchronization in subsequent messages by + recording with the ticket the difference (offset) between the + authtime value and the local clock. This offset can then be used by + the same user to adjust the time read from the system clock when + generating messages [DGT96]. + + This technique MUST be used when adjusting for clock skew instead of + directly changing the system clock because the KDC reply is only + authenticated to the user whose secret key was used, but not to the + system or workstation. If the clock were adjusted, an attacker + colluding with a user logging into a workstation could agree on a + password, resulting in a KDC reply that would be correctly validated + even though it did not originate from a KDC trusted by the + workstation. + + Proper decryption of the KRB_AS_REP message is not sufficient for the + host to verify the identity of the user; the user and an attacker + could cooperate to generate a KRB_AS_REP format message which + decrypts properly but is not from the proper KDC. If the host wishes + to verify the identity of the user, it MUST require the user to + present application credentials which can be verified using a + + + +March 2003 [Page 28] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + securely-stored secret key for the host. If those credentials can be + verified, then the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR message + + If the reply message type is KRB_ERROR, then the client interprets it + as an error and performs whatever application-specific tasks are + necessary to recover. + +3.2. The Client/Server Authentication Exchange + + Summary + Message direction Message type Section + Client to Application server KRB_AP_REQ 5.5.1 + [optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + + The client/server authentication (CS) exchange is used by network + applications to authenticate the client to the server and vice versa. + The client MUST have already acquired credentials for the server + using the AS or TGS exchange. + +3.2.1. The KRB_AP_REQ message + + The KRB_AP_REQ contains authentication information which SHOULD be + part of the first message in an authenticated transaction. It + contains a ticket, an authenticator, and some additional bookkeeping + information (see section 5.5.1 for the exact format). The ticket by + itself is insufficient to authenticate a client, since tickets are + passed across the network in cleartext[8], so the authenticator is + used to prevent invalid replay of tickets by proving to the server + that the client knows the session key of the ticket and thus is + entitled to use the ticket. The KRB_AP_REQ message is referred to + elsewhere as the 'authentication header.' + +3.2.2. Generation of a KRB_AP_REQ message + + When a client wishes to initiate authentication to a server, it + obtains (either through a credentials cache, the AS exchange, or the + TGS exchange) a ticket and session key for the desired service. The + client MAY re-use any tickets it holds until they expire. To use a + ticket the client constructs a new Authenticator from the system + time, its name, and optionally an application specific checksum, an + initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, + and/or a session subkey to be used in negotiations for a session key + unique to this particular session. Authenticators MAY NOT be re-used + and will be rejected if replayed to a server[9]. If a sequence number + is to be included, it SHOULD be randomly chosen so that even after + + + +March 2003 [Page 29] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + many messages have been exchanged it is not likely to collide with + other sequence numbers in use. + + The client MAY indicate a requirement of mutual authentication or the + use of a session-key based ticket (for user to user authentication - + see section 3.7) by setting the appropriate flag(s) in the ap-options + field of the message. + + The Authenticator is encrypted in the session key and combined with + the ticket to form the KRB_AP_REQ message which is then sent to the + end server along with any additional application-specific + information. + +3.2.3. Receipt of KRB_AP_REQ message + + Authentication is based on the server's current time of day (clocks + MUST be loosely synchronized), the authenticator, and the ticket. + Several errors are possible. If an error occurs, the server is + expected to reply to the client with a KRB_ERROR message. This + message MAY be encapsulated in the application protocol if its 'raw' + form is not acceptable to the protocol. The format of error messages + is described in section 5.9.1. + + The algorithm for verifying authentication information is as follows. + If the message type is not KRB_AP_REQ, the server returns the + KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket + in the KRB_AP_REQ is not one the server can use (e.g., it indicates + an old key, and the server no longer possesses a copy of the old + key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION- + KEY flag is set in the ap-options field, it indicates to the server + that user-to-user authentication is in use, and that the ticket is + encrypted in the session key from the server's ticket-granting ticket + rather than in the server's secret key. See section 3.7 for a more + complete description of the affect of user to user authentication on + all messages in the Kerberos protocol. + + Since it is possible for the server to be registered in multiple + realms, with different keys in each, the srealm field in the + unencrypted portion of the ticket in the KRB_AP_REQ is used to + specify which secret key the server should use to decrypt that + ticket. The KRB_AP_ERR_NOKEY error code is returned if the server + doesn't have the proper key to decipher the ticket. + + The ticket is decrypted using the version of the server's key + specified by the ticket. If the decryption routines detect a + modification of the ticket (each encryption system MUST provide + safeguards to detect modified ciphertext; see section 6), the + KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that + + + +March 2003 [Page 30] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + different keys were used to encrypt and decrypt). + + The authenticator is decrypted using the session key extracted from + the decrypted ticket. If decryption shows it to have been modified, + the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of + the client from the ticket are compared against the same fields in + the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH + error is returned; this normally is caused by a client error or + attempted attack. The addresses in the ticket (if any) are then + searched for an address matching the operating-system reported + address of the client. If no match is found or the server insists on + ticket addresses but none are present in the ticket, the + KRB_AP_ERR_BADADDR error is returned. If the local (server) time and + the client time in the authenticator differ by more than the + allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is + returned. + + Unless the application server provides its own suitable means to + protect against replay (for example, a challenge-response sequence + initiated by the server after authentication, or use of a server- + generated encryption subkey), the server MUST utilize a replay cache + to remember any authenticator presented within the allowable clock + skew. Careful analysis of the application protocol and implementation + is recommended before eliminating this cache. The replay cache will + store at least the server name, along with the client name, time and + microsecond fields from the recently-seen authenticators and if a + matching tuple is found, the KRB_AP_ERR_REPEAT error is returned + [10]. If a server loses track of authenticators presented within the + allowable clock skew, it MUST reject all requests until the clock + skew interval has passed, providing assurance that any lost or + replayed authenticators will fall outside the allowable clock skew + and can no longer be successfully replayed [11]. + + Implementation note: If a client generates multiple requests to the + KDC with the same timestamp, including the microsecond field, all but + the first of the requests received will be rejected as replays. This + might happen, for example, if the resolution of the client's clock is + too coarse. Implementations SHOULD ensure that the timestamps are + not reused, possibly by incrementing the microseconds field in the + time stamp when the clock returns the same time for multiple + requests. + + If multiple servers (for example, different services on one machine, + or a single service implemented on multiple machines) share a service + principal (a practice we do not recommend in general, but acknowledge + will be used in some cases), they should also share this replay + cache, or the application protocol should be designed so as to + eliminate the need for it. Note that this applies to all of the + + + +March 2003 [Page 31] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + services, if any of the application protocols does not have replay + protection built in; an authenticator used with such a service could + later be replayed to a different service with the same service + principal but no replay protection, if the former doesn't record the + authenticator information in the common replay cache. + + If a sequence number is provided in the authenticator, the server + saves it for later use in processing KRB_SAFE and/or KRB_PRIV + messages. If a subkey is present, the server either saves it for + later use or uses it to help generate its own choice for a subkey to + be returned in a KRB_AP_REP message. + + The server computes the age of the ticket: local (server) time minus + the start time inside the Ticket. If the start time is later than the + current time by more than the allowable clock skew or if the INVALID + flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. + Otherwise, if the current time is later than end time by more than + the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is + returned. + + If all these checks succeed without an error, the server is assured + that the client possesses the credentials of the principal named in + the ticket and thus, the client has been authenticated to the server. + + Passing these checks provides only authentication of the named + principal; it does not imply authorization to use the named service. + Applications MUST make a separate authorization decisions based upon + the authenticated name of the user, the requested operation, local + access control information such as that contained in a .k5login or + .k5users file, and possibly a separate distributed authorization + service. + +3.2.4. Generation of a KRB_AP_REP message + + Typically, a client's request will include both the authentication + information and its initial request in the same message, and the + server need not explicitly reply to the KRB_AP_REQ. However, if + mutual authentication (not only authenticating the client to the + server, but also the server to the client) is being performed, the + KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options + field, and a KRB_AP_REP message is required in response. As with the + error message, this message MAY be encapsulated in the application + protocol if its "raw" form is not acceptable to the application's + protocol. The timestamp and microsecond field used in the reply MUST + be the client's timestamp and microsecond field (as provided in the + authenticator) [12]. If a sequence number is to be included, it + SHOULD be randomly chosen as described above for the authenticator. A + subkey MAY be included if the server desires to negotiate a different + + + +March 2003 [Page 32] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + subkey. The KRB_AP_REP message is encrypted in the session key + extracted from the ticket. + +3.2.5. Receipt of KRB_AP_REP message + + If a KRB_AP_REP message is returned, the client uses the session key + from the credentials obtained for the server [13] to decrypt the + message, and verifies that the timestamp and microsecond fields match + those in the Authenticator it sent to the server. If they match, then + the client is assured that the server is genuine. The sequence number + and subkey (if present) are retained for later use. + +3.2.6. Using the encryption key + + After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and + server share an encryption key which can be used by the application. + In some cases, the use of this session key will be implicit in the + protocol; in others the method of use must be chosen from several + alternatives. The 'true session key' to be used for KRB_PRIV, + KRB_SAFE, or other application-specific uses MAY be chosen by the + application based on the session key from the ticket and subkeys in + the KRB_AP_REP message and the authenticator [14]. To mitigate the + effect of failures in random number generation on the client it is + strongly encouraged that any key derived by an application for + subsequent use include the full key entropy derived from the KDC + generated session key carried in the ticket. We leave the protocol + negotiations of how to use the key (e.g. selecting an encryption or + checksum type) to the application programmer; the Kerberos protocol + does not constrain the implementation options, but an example of how + this might be done follows. + + One way that an application may choose to negotiate a key to be used + for subsequent integrity and privacy protection is for the client to + propose a key in the subkey field of the authenticator. The server + can then choose a key using the proposed key from the client as + input, returning the new subkey in the subkey field of the + application reply. This key could then be used for subsequent + communication. + + To make this example more concrete, if the communication patterns of + an application dictates the use of encryption modes of operation + incompatible with the encryption system used for the authenticator, + then a key compatible with the required encryption system may be + generated by either the client, the server, or collaboratively by + both and exchanged using the subkey field. This generation might + involve the use of a random number as a pre-key, initially generated + by either party, which could then be encrypted using the session key + from the ticket, and the result exchanged and used for subsequent + + + +March 2003 [Page 33] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + encryption. By encrypting the pre-key with the session key from the + ticket, randomness from the KDC generated key is assured of being + present in the negotiated key. Application developers must be careful + however, to use a means of introducing this entropy that does not + allow an attacker to learn the session key from the ticket if it + learns the key generated and used for subsequent communication. The + reader should note that this is only an example, and that an analysis + of the particular cryptosystem to be used, must be made before + deciding how to generate values for the subkey fields, and the key to + be used for subsequent communication. + + With both the one-way and mutual authentication exchanges, the peers + should take care not to send sensitive information to each other + without proper assurances. In particular, applications that require + privacy or integrity SHOULD use the KRB_AP_REP response from the + server to client to assure both client and server of their peer's + identity. If an application protocol requires privacy of its + messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE + message (section 3.4) can be used to assure integrity. + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The TGS exchange between a client and the Kerberos Ticket-Granting + Server is initiated by a client when it wishes to obtain + authentication credentials for a given server (which might be + registered in a remote realm), when it wishes to renew or validate an + existing ticket, or when it wishes to obtain a proxy ticket. In the + first case, the client must already have acquired a ticket for the + Ticket-Granting Service using the AS exchange (the ticket-granting + ticket is usually obtained when a client initially authenticates to + the system, such as when a user logs in). The message format for the + TGS exchange is almost identical to that for the AS exchange. The + primary difference is that encryption and decryption in the TGS + exchange does not take place under the client's key. Instead, the + session key from the ticket-granting ticket or renewable ticket, or + sub-session key from an Authenticator is used. As is the case for all + application servers, expired tickets are not accepted by the TGS, so + once a renewable or ticket-granting ticket expires, the client must + use a separate exchange to obtain valid tickets. + + The TGS exchange consists of two messages: A request (KRB_TGS_REQ) + from the client to the Kerberos Ticket-Granting Server, and a reply + + + +March 2003 [Page 34] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes + information authenticating the client plus a request for credentials. + The authentication information consists of the authentication header + (KRB_AP_REQ) which includes the client's previously obtained ticket- + granting, renewable, or invalid ticket. In the ticket-granting + ticket and proxy cases, the request MAY include one or more of: a + list of network addresses, a collection of typed authorization data + to be sealed in the ticket for authorization use by the application + server, or additional tickets (the use of which are described later). + The TGS reply (KRB_TGS_REP) contains the requested credentials, + encrypted in the session key from the ticket-granting ticket or + renewable ticket, or if present, in the sub-session key from the + Authenticator (part of the authentication header). The KRB_ERROR + message contains an error code and text explaining what went wrong. + The KRB_ERROR message is not encrypted. The KRB_TGS_REP message + contains information which can be used to detect replays, and to + associate it with the message to which it replies. The KRB_ERROR + message also contains information which can be used to associate it + with the message to which it replies. The same comments about + integrity protection of KRB_ERROR messages mentioned in section 3.1 + apply to the TGS exchange. + +3.3.1. Generation of KRB_TGS_REQ message + + Before sending a request to the ticket-granting service, the client + MUST determine in which realm the application server is believed to + be registered [15]. If the client knows the service principal name + and realm and it does not already possess a ticket-granting ticket + for the appropriate realm, then one must be obtained. This is first + attempted by requesting a ticket-granting ticket for the destination + realm from a Kerberos server for which the client possesses a ticket- + granting ticket (using the KRB_TGS_REQ message recursively). The + Kerberos server MAY return a TGT for the desired realm in which case + one can proceed. Alternatively, the Kerberos server MAY return a TGT + for a realm which is 'closer' to the desired realm (further along the + standard hierarchical path between the client's realm and the + requested realm server's realm). It should be noted in this case that + misconfiguration of the Kerberos servers may cause loops in the + resulting authentication path, which the client should be careful to + detect and avoid. + + If the Kerberos server returns a TGT for a 'closer' realm other than + the desired realm, the client MAY use local policy configuration to + verify that the authentication path used is an acceptable one. + Alternatively, a client MAY choose its own authentication path, + rather than relying on the Kerberos server to select one. In either + case, any policy or configuration information used to choose or + validate authentication paths, whether by the Kerberos server or + + + +March 2003 [Page 35] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + client, MUST be obtained from a trusted source. + + When a client obtains a ticket-granting ticket that is 'closer' to + the destination realm, the client MAY cache this ticket and reuse it + in future KRB-TGS exchanges with services in the 'closer' realm. + However, if the client were to obtain a ticket-granting ticket for + the 'closer' realm by starting at the initial KDC rather than as part + of obtaining another ticket, then a shorter path to the 'closer' + realm might be used. This shorter path may be desirable because fewer + intermediate KDCs would know the session key of the ticket involved. + For this reason, clients SHOULD evaluate whether they trust the + realms transited in obtaining the 'closer' ticket when making a + decision to use the ticket in future. + + Once the client obtains a ticket-granting ticket for the appropriate + realm, it determines which Kerberos servers serve that realm, and + contacts one. The list might be obtained through a configuration file + or network service or it MAY be generated from the name of the realm; + as long as the secret keys exchanged by realms are kept secret, only + denial of service results from using a false Kerberos server. + + (This paragraph changed) As in the AS exchange, the client MAY + specify a number of options in the KRB_TGS_REQ message. One of these + options is the ENC-TKT-IN-SKEY option used for user-to-user + authentication. An overview of user to user authentication can be + found in section 3.7. When generating the KRB_TGS_REQ message, this + option indicates that the client is including a ticket-granting + ticket obtained from the application server in the additional tickets + field of the request and that the KDC SHOULD encrypt the ticket for + the application server using the session key from this additional + ticket, instead of using a server key from the principal database. + + The client prepares the KRB_TGS_REQ message, providing an + authentication header as an element of the padata field, and + including the same fields as used in the KRB_AS_REQ message along + with several optional fields: the enc-authorizatfion-data field for + application server use and additional tickets required by some + options. + + In preparing the authentication header, the client can select a sub- + session key under which the response from the Kerberos server will be + encrypted [16]. If the sub-session key is not specified, the session + key from the ticket-granting ticket will be used. If the enc- + authorization-data is present, it MUST be encrypted in the sub- + session key, if present, from the authenticator portion of the + authentication header, or if not present, using the session key from + the ticket-granting ticket. + + + + +March 2003 [Page 36] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Once prepared, the message is sent to a Kerberos server for the + destination realm. + +3.3.2. Receipt of KRB_TGS_REQ message + + The KRB_TGS_REQ message is processed in a manner similar to the + KRB_AS_REQ message, but there are many additional checks to be + performed. First, the Kerberos server MUST determine which server the + accompanying ticket is for and it MUST select the appropriate key to + decrypt it. For a normal KRB_TGS_REQ message, it will be for the + ticket granting service, and the TGS's key will be used. If the TGT + was issued by another realm, then the appropriate inter-realm key + MUST be used. If the accompanying ticket is not a ticket-granting + ticket for the current realm, but is for an application server in the + current realm, the RENEW, VALIDATE, or PROXY options are specified in + the request, and the server for which a ticket is requested is the + server named in the accompanying ticket, then the KDC will decrypt + the ticket in the authentication header using the key of the server + for which it was issued. If no ticket can be found in the padata + field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + + Once the accompanying ticket has been decrypted, the user-supplied + checksum in the Authenticator MUST be verified against the contents + of the request, and the message rejected if the checksums do not + match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum + is not keyed or not collision-proof (with an error code of + KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the + KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data + are present, they are decrypted using the sub-session key from the + Authenticator. + + If any of the decryptions indicate failed integrity checks, the + KRB_AP_ERR_BAD_INTEGRITY error is returned. + + As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP + message if it receives a KRB_TGS_REQ message identical to one it has + recently processed. However, if the authenticator is a replay, but + the rest of the request is not identical, then the KDC SHOULD return + KRB_AP_ERR_REPEAT. + +3.3.3. Generation of KRB_TGS_REP message + + The KRB_TGS_REP message shares its format with the KRB_AS_REP + (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The + detailed specification is in section 5.4.2. + + The response will include a ticket for the requested server or for a + ticket granting server of an intermediate KDC to be contacted to + + + +March 2003 [Page 37] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + obtain the requested ticket. The Kerberos database is queried to + retrieve the record for the appropriate server (including the key + with which the ticket will be encrypted). If the request is for a + ticket-granting ticket for a remote realm, and if no key is shared + with the requested realm, then the Kerberos server will select the + realm 'closest' to the requested realm with which it does share a + key, and use that realm instead. If the requested server cannot be + found in the TGS database, then a TGT for another trusted realm MAY + be returned instead of a ticket for the service. This TGT is a + referral mechanism to cause the client to retry the request to the + realm of the TGT. These are the only cases where the response for + the KDC will be for a different server than that requested by the + client. + + By default, the address field, the client's name and realm, the list + of transited realms, the time of initial authentication, the + expiration time, and the authorization data of the newly-issued + ticket will be copied from the ticket-granting ticket (TGT) or + renewable ticket. If the transited field needs to be updated, but the + transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is + returned. + + If the request specifies an endtime, then the endtime of the new + ticket is set to the minimum of (a) that request, (b) the endtime + from the TGT, and (c) the starttime of the TGT plus the minimum of + the maximum life for the application server and the maximum life for + the local realm (the maximum life for the requesting principal was + already applied when the TGT was issued). If the new ticket is to be + a renewal, then the endtime above is replaced by the minimum of (a) + the value of the renew_till field of the ticket and (b) the starttime + for the new ticket plus the life (endtime-starttime) of the old + ticket. + + If the FORWARDED option has been requested, then the resulting ticket + will contain the addresses specified by the client. This option will + only be honored if the FORWARDABLE flag is set in the TGT. The PROXY + option is similar; the resulting ticket will contain the addresses + specified by the client. It will be honored only if the PROXIABLE + flag in the TGT is set. The PROXY option will not be honored on + requests for additional ticket-granting tickets. + + If the requested start time is absent, indicates a time in the past, + or is within the window of acceptable clock skew for the KDC and the + POSTDATE option has not been specified, then the start time of the + ticket is set to the authentication server's current time. If it + indicates a time in the future beyond the acceptable clock skew, but + the POSTDATED option has not been specified or the MAY-POSTDATE flag + is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is + + + +March 2003 [Page 38] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + returned. Otherwise, if the ticket-granting ticket has the MAY- + POSTDATE flag set, then the resulting ticket will be postdated and + the requested starttime is checked against the policy of the local + realm. If acceptable, the ticket's start time is set as requested, + and the INVALID flag is set. The postdated ticket MUST be validated + before use by presenting it to the KDC after the starttime has been + reached. However, in no case may the starttime, endtime, or renew- + till time of a newly-issued postdated ticket extend beyond the renew- + till time of the ticket-granting ticket. + + If the ENC-TKT-IN-SKEY option has been specified and an additional + ticket has been included in the request, it indicates that the client + is using user- to-user authentication to prove its identity to a + server that does not have access to a persistent key. Section 3.7 + describes the affect of this option on the entire Kerberos protocol. + When generating the KRB_TGS_REP message, this option in the + KRB_TGS_REQ message tells the KDC to decrypt the additional ticket + using the key for the server to which the additional ticket was + issued and verify that it is a ticket-granting ticket. If the name of + the requested server is missing from the request, the name of the + client in the additional ticket will be used. Otherwise the name of + the requested server will be compared to the name of the client in + the additional ticket and if different, the request will be rejected. + If the request succeeds, the session key from the additional ticket + will be used to encrypt the new ticket that is issued instead of + using the key of the server for which the new ticket will be used. + + If the name of the server in the ticket that is presented to the KDC + as part of the authentication header is not that of the ticket- + granting server itself, the server is registered in the realm of the + KDC, and the RENEW option is requested, then the KDC will verify that + the RENEWABLE flag is set in the ticket, that the INVALID flag is not + set in the ticket, and that the renew_till time is still in the + future. If the VALIDATE option is requested, the KDC will check that + the starttime has passed and the INVALID flag is set. If the PROXY + option is requested, then the KDC will check that the PROXIABLE flag + is set in the ticket. If the tests succeed, and the ticket passes the + hotlist check described in the next section, the KDC will issue the + appropriate new ticket. + + The ciphertext part of the response in the KRB_TGS_REP message is + encrypted in the sub-session key from the Authenticator, if present, + or the session key from the ticket-granting ticket. It is not + encrypted using the client's secret key. Furthermore, the client's + key's expiration date and the key version number fields are left out + since these values are stored along with the client's database + record, and that record is not needed to satisfy a request based on a + ticket-granting ticket. + + + +March 2003 [Page 39] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +3.3.3.1. Checking for revoked tickets + + Whenever a request is made to the ticket-granting server, the + presented ticket(s) is(are) checked against a hot-list of tickets + which have been canceled. This hot-list might be implemented by + storing a range of issue timestamps for 'suspect tickets'; if a + presented ticket had an authtime in that range, it would be rejected. + In this way, a stolen ticket-granting ticket or renewable ticket + cannot be used to gain additional tickets (renewals or otherwise) + once the theft has been reported to the KDC for the realm in which + the server resides. Any normal ticket obtained before it was reported + stolen will still be valid (because they require no interaction with + the KDC), but only until their normal expiration time. If TGT's have + been issued for cross-realm authentication, use of the cross-realm + TGT will not be affected unless the hot-list is propagated to the + KDCs for the realms for which such cross-realm tickets were issued. + +3.3.3.2. Encoding the transited field + + If the identity of the server in the TGT that is presented to the KDC + as part of the authentication header is that of the ticket-granting + service, but the TGT was issued from another realm, the KDC will look + up the inter-realm key shared with that realm and use that key to + decrypt the ticket. If the ticket is valid, then the KDC will honor + the request, subject to the constraints outlined above in the section + describing the AS exchange. The realm part of the client's identity + will be taken from the ticket-granting ticket. The name of the realm + that issued the ticket-granting ticket, if it is not the realm of the + client principal, will be added to the transited field of the ticket + to be issued. This is accomplished by reading the transited field + from the ticket-granting ticket (which is treated as an unordered set + of realm names), adding the new realm to the set, then constructing + and writing out its encoded (shorthand) form (this may involve a + rearrangement of the existing encoding). + + Note that the ticket-granting service does not add the name of its + own realm. Instead, its responsibility is to add the name of the + previous realm. This prevents a malicious Kerberos server from + intentionally leaving out its own name (it could, however, omit other + realms' names). + + The names of neither the local realm nor the principal's realm are to + be included in the transited field. They appear elsewhere in the + ticket and both are known to have taken part in authenticating the + principal. Since the endpoints are not included, both local and + single-hop inter-realm authentication result in a transited field + that is empty. + + + + +March 2003 [Page 40] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Because the name of each realm transited is added to this field, it + might potentially be very long. To decrease the length of this field, + its contents are encoded. The initially supported encoding is + optimized for the normal case of inter-realm communication: a + hierarchical arrangement of realms using either domain or X.500 style + realm names. This encoding (called DOMAIN-X500-COMPRESS) is now + described. + + Realm names in the transited field are separated by a ",". The ",", + "\", trailing "."s, and leading spaces (" ") are special characters, + and if they are part of a realm name, they MUST be quoted in the + transited field by preceding them with a "\". + + A realm name ending with a "." is interpreted as being prepended to + the previous realm. For example, we can encode traversal of EDU, + MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + + Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, + that they would not be included in this field, and we would have: + + "EDU,MIT.,WASHINGTON.EDU" + + A realm name beginning with a "/" is interpreted as being appended to + the previous realm. For the purpose of appending, the realm + preceding the first listed realm is considered to be the null realm + (""). If a realm name beginning with a "/" is to stand by itself, + then it SHOULD be preceded by a space (" "). For example, we can + encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: + + "/COM,/HP,/APOLLO, /COM/DEC". + + Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, + they would not be included in this field, and we would have: + + "/COM,/HP" + + A null subfield preceding or following a "," indicates that all + realms between the previous realm and the next realm have been + traversed. For the purpose of interpreting null subfields, the + client's realm is considered to precede those in the transited field, + and the server's realm is considered to follow them. Thus, "," means + that all realms along the path between the client and the server have + been traversed. ",EDU, /COM," means that all realms from the client's + realm up to EDU (in a domain style hierarchy) have been traversed, + and that everything from /COM down to the server's realm in an X.500 + style has also been traversed. This could occur if the EDU realm in + + + +March 2003 [Page 41] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + one hierarchy shares an inter-realm key directly with the /COM realm + in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + + When the KRB_TGS_REP is received by the client, it is processed in + the same manner as the KRB_AS_REP processing described above. The + primary difference is that the ciphertext part of the response must + be decrypted using the sub-session key from the Authenticator, if it + was specified in the request, or the session key from the ticket- + granting ticket, rather than the client's secret key. The server name + returned in the reply is the true principal name of the service. + +3.4. The KRB_SAFE Exchange + + The KRB_SAFE message MAY be used by clients requiring the ability to + detect modifications of messages they exchange. It achieves this by + including a keyed collision-proof checksum of the user data and some + control information. The checksum is keyed with an encryption key + (usually the last key negotiated via subkeys, or the session key if + no negotiation has occurred). + +3.4.1. Generation of a KRB_SAFE message + + When an application wishes to send a KRB_SAFE message, it collects + its data and the appropriate control information and computes a + checksum over them. The checksum algorithm should be the keyed + checksum mandated to be implemented along with the crypto system used + for the sub-session or session key. The checksum is generated using + the sub-session key if present, and the session key. Some + implementations use a different checksum algorithm for the KRB_SAFE + messages but doing so in a interoperable manner is not always + possible. + + Implementations SHOULD accept any checksum algorithm they implement + that both have adequate security and that have keys compatible with + the sub-session or session key. Unkeyed or non-collision-proof + checksums are not suitable for this use. + + The control information for the KRB_SAFE message includes both a + timestamp and a sequence number. The designer of an application using + the KRB_SAFE message MUST choose at least one of the two mechanisms. + This choice SHOULD be based on the needs of the application protocol. + + Sequence numbers are useful when all messages sent will be received + by one's peer. Connection state is presently required to maintain the + session key, so maintaining the next sequence number should not + present an additional problem. + + + +March 2003 [Page 42] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + If the application protocol is expected to tolerate lost messages + without them being resent, the use of the timestamp is the + appropriate replay detection mechanism. Using timestamps is also the + appropriate mechanism for multi-cast protocols where all of one's + peers share a common sub-session key, but some messages will be sent + to a subset of one's peers. + + After computing the checksum, the client then transmits the + information and checksum to the recipient in the message format + specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + + When an application receives a KRB_SAFE message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_SAFE, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application verifies that the checksum used is a + collision-proof keyed checksum that uses keys compatible with the + sub-session or session key as appropriate (or with the application + key derived from the session or sub-session keys), and if it is not, + a KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address + MUST be included in the control information; the recipient verifies + that the operating system's report of the sender's address matches + the sender's address in the message, and (if a recipient address is + specified or the recipient requires an address) that one of the + recipient's addresses appears as the recipient's address in the + message. To work with network address translation, senders MAY use + the directional address type specified in section 8.1 for the sender + address and not include recipient addresses. A failed match for + either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp + and usec and/or the sequence number fields are checked. If timestamp + and usec are expected and not present, or they are present but not + current, the KRB_AP_ERR_SKEW error is generated. If the server name, + along with the client name, time and microsecond fields from the + Authenticator match any recently-seen (sent or received) such tuples, + the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence + number is included, or a sequence number is expected but not present, + the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp + and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error + is generated. Finally, the checksum is computed over the data and + control information, and if it doesn't match the received checksum, a + KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application is assured that the + + + +March 2003 [Page 43] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + message was generated by its peer and was not modified in transit. + +3.5. The KRB_PRIV Exchange + + The KRB_PRIV message MAY be used by clients requiring confidentiality + and the ability to detect modifications of exchanged messages. It + achieves this by encrypting the messages and adding control + information. + +3.5.1. Generation of a KRB_PRIV message + + When an application wishes to send a KRB_PRIV message, it collects + its data and the appropriate control information (specified in + section 5.7.1) and encrypts them under an encryption key (usually the + last key negotiated via subkeys, or the session key if no negotiation + has occurred). As part of the control information, the client MUST + choose to use either a timestamp or a sequence number (or both); see + the discussion in section 3.4.1 for guidelines on which to use. After + the user data and control information are encrypted, the client + transmits the ciphertext and some 'envelope' information to the + recipient. + +3.5.2. Receipt of KRB_PRIV message + + When an application receives a KRB_PRIV message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_PRIV, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application then decrypts the ciphertext and processes the + resultant plaintext. If decryption shows the data to have been + modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. + + The sender's address MUST be included in the control information; the + recipient verifies that the operating system's report of the sender's + address matches the sender's address in the message. If a recipient + address is specified or the recipient requires an address then one of + the recipient's addresses MUST also appear as the recipient's address + in the message. Where a sender's or receiver's address might not + otherwise match the address in a message because of network address + translation, an application MAY be written to use addresses of the + directional address type in place of the actual network address. + + A failed match for either case generates a KRB_AP_ERR_BADADDR error. + To work with network address translation, implementations MAY use the + directional address type defined in section 7.1 for the sender + + + +March 2003 [Page 44] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + address and include no recipient address. Then the timestamp and usec + and/or the sequence number fields are checked. If timestamp and usec + are expected and not present, or they are present but not current, + the KRB_AP_ERR_SKEW error is generated. If the server name, along + with the client name, time and microsecond fields from the + Authenticator match any recently-seen such tuples, the + KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number + is included, or a sequence number is expected but not present, the + KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and + usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is + generated. + + If all the checks succeed, the application can assume the message was + generated by its peer, and was securely transmitted (without + intruders able to see the unencrypted contents). + +3.6. The KRB_CRED Exchange + + The KRB_CRED message MAY be used by clients requiring the ability to + send Kerberos credentials from one host to another. It achieves this + by sending the tickets together with encrypted data containing the + session keys and other information associated with the tickets. + +3.6.1. Generation of a KRB_CRED message + + When an application wishes to send a KRB_CRED message it first (using + the KRB_TGS exchange) obtains credentials to be sent to the remote + host. It then constructs a KRB_CRED message using the ticket or + tickets so obtained, placing the session key needed to use each + ticket in the key field of the corresponding KrbCredInfo sequence of + the encrypted part of the KRB_CRED message. + + Other information associated with each ticket and obtained during the + KRB_TGS exchange is also placed in the corresponding KrbCredInfo + sequence in the encrypted part of the KRB_CRED message. The current + time and, if specifically required by the application (and + communicated from the recipient to the sender by application specific + means) the nonce, s-address, and r-address fields, are placed in the + encrypted part of the KRB_CRED message which is then encrypted under + an encryption key previously exchanged in the KRB_AP exchange + (usually the last key negotiated via subkeys, or the session key if + no negotiation has occurred). + + Implementation note: When constructing a KRB_CRED message for + inclusion in a GSSAPI initial context token, the MIT implementation + of Kerberos will not encrypt the KRB_CRED message if the session key + is a DES or triple DES key. For interoperability with MIT, the + Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI + + + +March 2003 [Page 45] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + token if it is using a DES session key. Starting at version 1.2.5, + MIT Kerberos can receive and decode either encrypted or unencrypted + KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of + Kerberos can also accept either encrypted or unencrypted KRB_CRED + messages. Since the KRB_CRED message in a GSSAPI token is encrypted + in the authenticator, the MIT behavior does not present a security + problem, although it is a violation of the Kerberos specification. + +3.6.2. Receipt of KRB_CRED message + + When an application receives a KRB_CRED message, it verifies it. If + any error occurs, an error code is reported for use by the + application. The message is verified by checking that the protocol + version and type fields match the current version and KRB_CRED, + respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or + KRB_AP_ERR_MSG_TYPE error. The application then decrypts the + ciphertext and processes the resultant plaintext. If decryption shows + the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is + generated. + + If present or required, the recipient MAY verify that the operating + system's report of the sender's address matches the sender's address + in the message, and that one of the recipient's addresses appears as + the recipient's address in the message. The address check does not + provide any added security, since the address if present has already + been checked in the KRB_AP_REQ message and there is not any benefit + to be gained by an attacker in reflecting a KRB_CRED message back to + its originator. Thus, the recipient MAY ignore the address even if + present in order to work better in NAT environments. A failed match + for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY + skip the address check as the KRB_CRED message cannot generally be + reflected back to the originator. The timestamp and usec fields (and + the nonce field if required) are checked next. If the timestamp and + usec are not present, or they are present but not current, the + KRB_AP_ERR_SKEW error is generated. + + If all the checks succeed, the application stores each of the new + tickets in its credentials cache together with the session key and + other information in the corresponding KrbCredInfo sequence from the + encrypted part of the KRB_CRED message. + +3.7. User to User Authentication Exchanges + + User to User authentication provides a method to perform + authentication when the verifier does not have a access to long term + service key. This might be the case when running a server (for + example a window server) as a user on a workstation. In such cases, + the server may have access to the ticket-granting ticket obtained + + + +March 2003 [Page 46] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + when the user logged in to the workstation, but because the server is + running as an unprivileged user it might not have access to system + keys. Similar situations may arise when running peer-to-peer + applications. + + Summary + Message direction Message type Sections + 0. Message from application server Not Specified + 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 + KRB_ERROR 5.9.1 + 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 + + To address this problem, the Kerberos protocol allows the client to + request that the ticket issued by the KDC be encrypted using a + session key from a ticket-granting ticket issued to the party that + will verify the authentication. This ticket-granting ticket must be + obtained from the verifier by means of an exchange external to the + Kerberos protocol, usually as part of the application protocol. This + message is shown in the summary above as message 0. Note that because + the ticket-granting ticket is encrypted in the KDC's secret key, it + can not be used for authentication without posession of the + corresponding secret key. Furthermore, because the verifier does not + reveal the corresponding secret key, providing a copy of the + verifier's ticket-granting ticket does not allow impersonation of the + verifier. + + Message 0 in the table above represents an application specific + negotation between the client and server, at the end of which both + have determined that they will use user to user authentication and + the client has obtained the server's TGT. + + Next, the client includes the server's TGT as an additional ticket in + its KRB_TGS_REQ request to the KDC (message 1 in the table above) and + specifyies the ENC-TKT-IN-SKEY option in its request. + + If validated according to the instructions in 3.3.3, the application + ticket returned to the client (message 2 in the table above) will be + encrypted using the session key from the additional ticket and the + client will note this when it uses or stores the application ticket. + + When contacting the server using a ticket obtained for user to user + authentication (message 3 in the table above), the client MUST + specify the USE-SESSION-KEY flag in the ap-options field. This tells + the application server to use the session key associated with its + ticket-granting ticket to decrypt the server ticket provided in the + application request. + + + + +March 2003 [Page 47] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +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 + 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. + + [@KCRYPTO] 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 [@KCRYPTO] 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 otherwise indicated, the default string- + to-key opaque parameter set as defined in [@KCRYPTO] 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 [@KCRYPTO], 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. Key usage + values 512-1023 are reserved for uses internal to a Kerberos + implementation. (For example, seeding a pseudo-random number + + + +March 2003 [Page 48] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + 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 which define protocols in terms of + the RFC1510 encryption types or checksum types. Such documents would + not know about key usages. In order that these specifications + continue to be meaningful until they are updated, if not 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, 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 otherwise indicated, no cipher state chaining is done from one + encryption operation to another. + + Implementation note: While 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 [@KCRYPTO]. 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). While 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. + +5. Message Specifications + + NOTE: The ASN.1 collected here should be identical to the contents of + Appendix A. In case of conflict, the contents of Appendix A shall + take precedence. + + The Kerberos protocol is defined here in terms of Abstract Syntax + Notation One (ASN.1) [X680], which provides a syntax for specifying + both the abstract layout of protocol messages as well as their + encodings. Implementors not utilizing an existing ASN.1 compiler or + + + +March 2003 [Page 49] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + support library are cautioned to thoroughly understand the actual + ASN.1 specification to ensure correct implementation behavior, as + there is more complexity in the notation than is immediately obvious, + and some tutorials and guides to ASN.1 are misleading or erroneous. + + Note that in several places, there have been changes here from RFC + 1510 that change the abstract types. This is in part to address + widespread assumptions that various implementors have made, in some + cases resulting in unintentional violations of the ASN.1 standard. + These are clearly flagged where they occur. The differences between + the abstract types in RFC 1510 and abstract types in this document + can cause incompatible encodings to be emitted when certain encoding + rules, e.g. the Packed Encoding Rules (PER), are used. This + theoretical incompatibility should not be relevant for Kerberos, + since Kerberos explicitly specifies the use of the Distinguished + Encoding Rules (DER). It might be an issue for protocols wishing to + use Kerberos types with other encoding rules. (This practice is not + recommended.) With very few exceptions (most notably the usages of + BIT STRING), the encodings resulting from using the DER remain + identical between the types defined in RFC 1510 and the types defined + in this document. + + The type definitions in this section assume an ASN.1 module + definition of the following form: + + KerberosV5Spec2 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec2(2) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + -- rest of definitions here + + END + + This specifies that the tagging context for the module will be + explicit and non-automatic. + + Note that in some other publications [RFC1510] [RFC1964], the "dod" + portion of the object identifier is erroneously specified as having + the value "5". In the case of RFC 1964, use of the "correct" OID + value would result in a change in the wire protocol; therefore, it + remains unchanged for now. + + Note that elsewhere in this document, nomenclature for various + message types is inconsistent, but seems to largely follow C language + conventions, including use of underscore (_) characters and all-caps + spelling of names intended to be numeric constants. Also, in some + places, identifiers (especially ones refering to constants) are + + + +March 2003 [Page 50] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + written in all-caps in order to distinguish them from surrounding + explanatory text. + + The ASN.1 notation does not permit underscores in identifiers, so in + actual ASN.1 definitions, underscores are replaced with hyphens (-). + Additionally, structure member names and defined values in ASN.1 MUST + begin with a lowercase letter, while type names MUST begin with an + uppercase letter. + +5.1. Specific Compatibility Notes on ASN.1 + + For compatibility purposes, implementors should heed the following + specific notes regarding the use of ASN.1 in Kerberos. These notes do + not describe deviations from standard usage of ASN.1. The purpose of + these notes is to instead describe some historical quirks and non- + compliance of various implementations, as well as historical + ambiguities, which, while being valid ASN.1, can lead to confusion + during implementation. + +5.1.1. ASN.1 Distinguished Encoding Rules + + The encoding of Kerberos protocol messages shall obey the + Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. + Some implementations (believed to be primarly ones derived from DCE + 1.1 and earlier) are known to use the more general Basic Encoding + Rules (BER); in particular, these implementations send indefinite + encodings of lengths. Implementations MAY accept such encodings in + the interests of backwards compatibility, though implementors are + warned that decoding fully-general BER is fraught with peril. + +5.1.2. Optional Integer Fields + + Some implementations do not internally distinguish between an omitted + optional integer value and a transmitted value of zero. The places in + the protocol where this is relevant include various microseconds + fields, nonces, and sequence numbers. Implementations SHOULD treat + omitted optional integer values as having been transmitted with a + value of zero, if the application is expecting this. + +5.1.3. Empty SEQUENCE OF Types + + There are places in the protocol where a message contains a SEQUENCE + OF type as an optional member. This can result in an encoding that + contains an empty SEQUENCE OF encoding. The Kerberos protocol does + not semantically distinguish between an absent optional SEQUENCE OF + type and a present optional but empty SEQUENCE OF type. + Implementations SHOULD NOT send empty SEQUENCE OF encodings that are + marked OPTIONAL, but SHOULD accept them as being equivalent to an + + + +March 2003 [Page 51] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos + messages, instances of these problematic optional SEQUENCE OF types + are indicated with a comment. + +5.1.4. Unrecognized Tag Numbers + + Future revisions to this protocol may include new message types with + different APPLICATION class tag numbers. Such revisions should + protect older implementations by only sending the message types to + parties that are known to understand them, e.g. by means of a flag + bit set by the receiver in a preceding request. In the interest of + robust error handling, implementations SHOULD gracefully handle + receiving a message with an unrecognized tag anyway, and return an + error message if appropriate. + +5.1.5. Tag Numbers Greater Than 30 + + A naive implementation of a DER ASN.1 decoder may experience problems + with ASN.1 tag numbers greater than 30, due to such tag numbers being + encoded using more than one byte. Future revisions of this protocol + may utilize tag numbers greater than 30, and implementations SHOULD + be prepared to gracefully return an error, if appropriate, if they do + not recognize the tag. + +5.2. Basic Kerberos Types + + This section defines a number of basic types that are potentially + used in multiple Kerberos protocol messages. + +5.2.1. KerberosString + + The original specification of the Kerberos protocol in RFC 1510 uses + GeneralString in numerous places for human-readable string data. + Historical implementations of Kerberos cannot utilize the full power + of GeneralString. This ASN.1 type requires the use of designation + and invocation escape sequences as specified in ISO-2022/ECMA-35 + [ISO-2022/ECMA-35] to switch character sets, and the default + character set that is designated as G0 is the ISO-646/ECMA-6 + [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S. + ASCII), which mostly works. + + ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) + and two Control-function code elements (C0..C1). DER prohibits the + designation of character sets as any but the G0 and C0 sets. + Unfortunately, this seems to have the side effect of prohibiting the + use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other + character-sets that utilize a 96-character set, since it is + prohibited by ISO-2022/ECMA-35 to designate them as the G0 code + + + +March 2003 [Page 52] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + element. This side effect is being investigated in the ASN.1 + standards community. + + In practice, many implementations treat GeneralStrings as if they + were 8-bit strings of whichever character set the implementation + defaults to, without regard for correct usage of character-set + designation escape sequences. The default character set is often + determined by the current user's operating system dependent locale. + At least one major implementation places unescaped UTF-8 encoded + Unicode characters in the GeneralString. This failure to adhere to + the GeneralString specifications results in interoperability issues + when conflicting character encodings are utilized by the Kerberos + clients, services, and KDC. + + This unfortunate situation is the result of improper documentation of + the restrictions of the ASN.1 GeneralString type in prior Kerberos + specifications. + + The new (post-RFC 1510) type KerberosString, defined below, is a + GeneralString that is constrained to only contain characters in + IA5String + + KerberosString ::= GeneralString (IA5String) + + US-ASCII control characters should in general not be used in + KerberosString, except for cases such as newlines in lengthy error + messages. Control characters SHOULD NOT be used in principal names or + realm names. + + For compatibility, implementations MAY choose to accept GeneralString + values that contain characters other than those permitted by + IA5String, but they should be aware that character set designation + codes will likely be absent, and that the encoding should probably be + treated as locale-specific in almost every way. Implementations MAY + also choose to emit GeneralString values that are beyond those + permitted by IA5String, but should be aware that doing so is + extraordinarily risky from an interoperability perspective. + + Some existing implementations use GeneralString to encode unescaped + locale-specific characters. This is a violation of the ASN.1 + standard. Most of these implementations encode US-ASCII in the left- + hand half, so as long the implementation transmits only US-ASCII, the + ASN.1 standard is not violated in this regard. As soon as such an + implementation encodes unescaped locale-specific characters with the + high bit set, it violates the ASN.1 standard. + + Other implementations have been known to use GeneralString to contain + a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 + + + +March 2003 [Page 53] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + is a different encoding, not a 94 or 96 character "G" set as defined + by ISO 2022. It is believed that these implementations do not even + use the ISO 2022 escape sequence to change the character encoding. + Even if implementations were to announce the change of encoding by + using that escape sequence, the ASN.1 standard prohibits the use of + any escape sequences other than those used to designate/invoke "G" or + "C" sets allowed by GeneralString. + + Future revisions to this protocol will almost certainly allow for a + more interoperable representation of principal names, probably + including UTF8String. + + Note that applying a new constraint to a previously unconstrained + type constitutes creation of a new ASN.1 type. In this particular + case, the change does not result in a changed encoding under DER. + +5.2.2. Realm and PrincipalName + + Realm ::= KerberosString + + PrincipalName ::= SEQUENCE { + name-type [0] Int32, + name-string [1] SEQUENCE OF KerberosString + } + + Kerberos realm names are encoded as KerberosStrings. Realms shall not + contain a character with the code 0 (the US-ASCII NUL). Most realms + will usually consist of several components separated by periods (.), + in the style of Internet Domain Names, or separated by slashes (/) in + the style of X.500 names. Acceptable forms for realm names are + specified in section 6.1.. A PrincipalName is a typed sequence of + components consisting of the following sub-fields: + + name-type + This field specifies the type of name that follows. Pre-defined + values for this field are specified in section 6.2. The name-type + SHOULD be treated as a hint. Ignoring the name type, no two names + can be the same (i.e. at least one of the components, or the + realm, must be different). + + name-string + This field encodes a sequence of components that form a name, each + component encoded as a KerberosString. Taken together, a + PrincipalName and a Realm form a principal identifier. Most + PrincipalNames will have only a few components (typically one or + two). + +5.2.3. KerberosTime + + + +March 2003 [Page 54] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + KerberosTime ::= GeneralizedTime -- with no fractional seconds + + The timestamps used in Kerberos are encoded as GeneralizedTimes. A + KerberosTime value shall not include any fractional portions of the + seconds. As required by the DER, it further shall not include any + separators, and it shall specify the UTC time zone (Z). Example: The + only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 + November 1985 is 19851106210627Z. + +5.2.4. Constrained Integer types + + Some integer members of types SHOULD be constrained to values + representable in 32 bits, for compatibility with reasonable + implementation limits. + + Int32 ::= INTEGER (-2147483648..2147483647) + -- signed values representable in 32 bits + + UInt32 ::= INTEGER (0..4294967295) + -- unsigned 32 bit values + + Microseconds ::= INTEGER (0..999999) + -- microseconds + + While this results in changes to the abstract types from the RFC 1510 + version, the encoding in DER should be unaltered. Historical + implementations were typically limited to 32-bit integer values + anyway, and assigned numbers SHOULD fall in the space of integer + values representable in 32 bits in order to promote interoperability + anyway. + + There are several integer fields in messages that are constrained to + fixed values. + + pvno + also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always + the constant integer 5. There is no easy way to make this field + into a useful protocol version number, so its value is fixed. + + msg-type + this integer field is usually identical to the application tag + number of the containing message type. + +5.2.5. HostAddress and HostAddresses + + HostAddress ::= SEQUENCE { + addr-type [0] Int32, + address [1] OCTET STRING + + + +March 2003 [Page 55] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be empty. + HostAddresses -- NOTE: subtly different from rfc1510, + -- but has a value mapping and encodes the same + ::= SEQUENCE OF HostAddress + + The host address encodings consists of two fields: + + addr-type + This field specifies the type of address that follows. Pre-defined + values for this field are specified in section 7.5.3. + + address + This field encodes a single address of type addr-type. + +5.2.6. AuthorizationData + + -- NOTE: AuthorizationData is always used as an OPTIONAL field and + -- should not be empty. + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] Int32, + ad-data [1] OCTET STRING + } + + ad-data + This field contains authorization data to be interpreted according + to the value of the corresponding ad-type field. + + ad-type + This field specifies the format for the ad-data subfield. All + negative values are reserved for local use. Non-negative values + are reserved for registered use. + + Each sequence of type and data is referred to as an authorization + element. Elements MAY be application specific, however, there is a + common set of recursive elements that should be understood by all + implementations. These elements contain other elements embedded + within them, and the interpretation of the encapsulating element + determines which of the embedded elements must be interpreted, and + which may be ignored. + + These common authorization data elements are recursively defined, + meaning the ad-data for these types will itself contain a sequence of + authorization data whose interpretation is affected by the + encapsulating element. Depending on the meaning of the encapsulating + element, the encapsulated elements may be ignored, might be + + + +March 2003 [Page 56] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + interpreted as issued directly by the KDC, or they might be stored in + a separate plaintext part of the ticket. The types of the + encapsulating elements are specified as part of the Kerberos + specification because the behavior based on these values should be + understood across implementations whereas other elements need only be + understood by the applications which they affect. + + Authorization data elements are considered critical if present in a + ticket or authenticator. Unless encapsulated in a known authorization + data element amending the criticality of the elements it contains, if + an unknown authorization data element type is received by a server + either in an AP-REQ or in a ticket contained in an AP-REQ, then + authentication MUST fail. Authorization data is intended to restrict + the use of a ticket. If the service cannot determine whether the + restriction applies to that service then a security weakness may + result if the ticket can be used for that service. Authorization + elements that are optional can be enclosed in AD-IF-RELEVANT element. + + In the definitions that follow, the value of the ad-type for the + element will be specified as the least significant part of the + subsection number, and the value of the ad-data will be as shown in + the ASN.1 structure that follows the subsection heading. + + contents of ad-data ad-type + + DER encoding of AD-IF-RELEVANT 1 + + DER encoding of AD-KDCIssued 4 + + DER encoding of AD-AND-OR 5 + + DER encoding of AD-MANDATORY-FOR-KDC 8 + +5.2.6.1. IF-RELEVANT + + AD-IF-RELEVANT ::= AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that + do not understand the type of an element embedded within the if- + relevant element MAY ignore the uninterpretable element. This element + promotes interoperability across implementations which may have local + extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). + +5.2.6.2. KDCIssued + + AD-KDCIssued ::= SEQUENCE { + + + +March 2003 [Page 57] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + ad-checksum [0] Checksum, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the + ticket itself (i.e. using the same hash function and the same + encryption algorithm used to encrypt the ticket) using the key + used to protect the ticket, and a key usage value of 19. + + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + + elements + A sequence of authorization data elements issued by the KDC. + + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, + amplifying the privileges of the principal beyond what can be done + using a credentials without such an a-data element. + + This can not be provided without this element because the definition + of the authorization-data field allows elements to be added at will + by the bearer of a TGT at the time that they request service tickets + and elements may also be added to a delegated ticket by inclusion in + the authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the + server's key (the same key used to encrypt the ticket - or a key + derived from that key). Elements encapsulated with in the KDC-issued + element will be ignored by the application server if this "signature" + is not present. Further, elements encapsulated within this element + from a ticket-granting ticket MAY be interpreted by the KDC, and used + as a basis according to policy for including new signed elements + within derivative tickets, but they will not be copied to a + derivative ticket directly. If they are copied directly to a + derivative ticket by a KDC that is not aware of this element, the + signature will not be correct for the application ticket elements, + and the field will be ignored by the application server. + + + +March 2003 [Page 58] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + This element and the elements it encapulates MAY be safely ignored by + applications, application servers, and KDCs that do not implement + this element. + + The ad-type for AD-KDC-ISSUED is (4). + +5.2.6.3. AND-OR + + AD-AND-OR ::= SEQUENCE { + condition-count [0] INTEGER, + elements [1] AuthorizationData + } + + + When restrictive AD elements are encapsulated within the and-or + element, the and-or element is considered satisfied if and only if at + least the number of encapsulated elements specified in condition- + count are satisifed. Therefore, this element MAY be used to + implement an "or" operation by setting the condition-count field to + 1, and it MAY specify an "and" operation by setting the condition + count to the number of embedded elements. Application servers that do + not implement this element MUST reject tickets that contain + authorization data elements of this type. + + The ad-type for AD-AND-OR is (5). + +5.2.6.4. MANDATORY-FOR-KDC + + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + AD elements encapsulated within the mandatory-for-kdc element are to + be interpreted by the KDC. KDCs that do not understand the type of an + element embedded within the mandatory-for-kdc element MUST reject the + request. + + The ad-type for AD-MANDATORY-FOR-KDC is (8). + +5.2.7. PA-DATA + + Historically, PA-DATA have been known as "pre-authentication data", + meaning that they were used to augment the initial authentication + with the KDC. Since that time, they have also been used as a typed + hole with which to extend protocol exchanges with the KDC. + + PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] Int32, + padata-value [2] OCTET STRING -- might be encoded AP-REQ + + + +March 2003 [Page 59] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + } + + padata-type + indicates the way that the padata-value element is to be + interpreted. Negative values of padata-type are reserved for + unregistered use; non-negative values are used for a registered + interpretation of the element type. + + padata-value + Usually contains the DER encoding of another type; the padata-type + field identifies which type is encoded here. + + padata-type name contents of padata-value + + 1 pa-tgs-req DER encoding of AP-REQ + + 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP + + 3 pa-pw-salt salt (not ASN.1 encoded) + + 11 pa-etype-info DER encoding of ETYPE-INFO + + 19 pa-etype-info2 DER encoding of ETYPE-INFO2 + + This field MAY also contain information needed by certain + extensions to the Kerberos protocol. For example, it might be used + to initially verify the identity of a client before any response + is returned. + + The padata field can also contain information needed to help the + KDC or the client select the key needed for generating or + decrypting the response. This form of the padata is useful for + supporting the use of certain token cards with Kerberos. The + details of such extensions are specified in separate documents. + See [Pat92] for additional uses of this field. + +5.2.7.1. PA-TGS-REQ + + In the case of requests for additional tickets (KRB_TGS_REQ), padata- + value will contain an encoded AP-REQ. The checksum in the + authenticator (which MUST be collision-proof) is to be computed over + the KDC-REQ-BODY encoding. + +5.2.7.2. Encrypted Timestamp Pre-authentication + + There are pre-authentication types that may be used to pre- + authenticate a client by means of an encrypted timestamp. + + + + +March 2003 [Page 60] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL + } + + Patimestamp contains the client's time, and pausec contains the + microseconds, which MAY be omitted if a client will not generate more + than one request per second. The ciphertext (padata-value) consists + of the PA-ENC-TS-ENC encoding, encrypted using the client's secret + key and a key usage value of 1. + + This pre-authentication type was not present in RFC 1510, but many + implementations support it. + +5.2.7.3. PA-PW-SALT + + The padata-value for this pre-authentication type contains the salt + for the string-to-key to be used by the client to obtain the key for + decrypting the encrypted part of an AS-REP message. Unfortunately, + for historical reasons, the character set to be used is unspecified + and probably locale-specific. + + This pre-authentication type was not present in RFC 1510, but many + implementations support it. It is necessary in any case where the + salt for the string-to-key algorithm is not the default. + + In the trivial example, a zero-length salt string is very commonplace + for realms that have converted their principal databases from + Kerberos 4. + + A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message + that requests additional pre-authentication. Implementation note: + some KDC implementations issue an erroneous PA-PW-SALT when issuing a + KRB-ERROR message that requests additional pre-authentication. + Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB- + ERROR message that requests additional pre-authentication. + +5.2.7.4. PA-ETYPE-INFO + + The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB- + ERROR indicating a requirement for additional pre-authentication. It + is usually used to notify a client of which key to use for the + encryption of an encrypted timestamp for the purposes of sending a + PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an + AS-REP to provide information to the client about which key salt to + use for the string-to-key to be used by the client to obtain the key + + + +March 2003 [Page 61] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + for decrypting the encrypted part the AS-REP. + + ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] OCTET STRING OPTIONAL + } + + ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + + The salt, like that of PA-PW-SALT, is also completely unspecified + with respect to character set and is probably locale-specific. + + If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE- + INFO-ENTRY, and its etype shall match that of the enc-part in the AS- + REP. + + This pre-authentication type was not present in RFC 1510, but many + implementations that support encrypted timestamps for pre- + authentication need to support ETYPE-INFO as well. + +5.2.7.5. PA-ETYPE-INFO2 + + The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB- + ERROR indicating a requirement for additional pre-authentication. It + is usually used to notify a client of which key to use for the + encryption of an encrypted timestamp for the purposes of sending a + PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an + AS-REP to provide information to the client about which key salt to + use for the string-to-key to be used by the client to obtain the key + for decrypting the encrypted part the AS-REP. + + ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL + } + + ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY + + The type of the salt is KerberosString, but existing installations + might have locale-specific characters stored in salt strings, and + implementors MAY choose to handle them. + + The interpretation of s2kparams is specified in the cryptosystem + description associated with the etype. Each cryptosystem has a + default interpretation of s2kparams that will hold if that element is + omitted from the encoding of ETYPE-INFO2-ENTRY. + + + + +March 2003 [Page 62] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one + ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in + the AS-REP. + + The preferred ordering of pre-authentication data that modify client + key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by + PW-SALT. A KDC shall send all of these pre-authentication data that + it supports, in the preferred ordering, when issuing an AS-REP or + when issuing a KRB-ERROR requesting additional pre-authentication. + + The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. + +5.2.8. KerberosFlags + + For several message types, a specific constrained bit string type, + KerberosFlags, is used. + + KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits + -- shall be sent, but no fewer than 32 + + Compatibility note: the following paragraphs describe a change from + the RFC1510 description of bit strings that would result in + incompatility in the case of an implementation that strictly + conformed to ASN.1 DER and RFC1510. + + ASN.1 bit strings have multiple uses. The simplest use of a bit + string is to contain a vector of bits, with no particular meaning + attached to individual bits. This vector of bits is not necessarily a + multiple of eight bits long. The use in Kerberos of a bit string as + a compact boolean vector wherein each element has a distinct meaning + poses some problems. The natural notation for a compact boolean + vector is the ASN.1 "NamedBit" notation, and the DER require that + encodings of a bit string using "NamedBit" notation exclude any + trailing zero bits. This truncation is easy to neglect, especially + given C language implementations that naturally choose to store + boolean vectors as 32 bit integers. + + For example, if the notation for KDCOptions were to include the + "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be + encoded had only the "forwardable" (bit number one) bit set, the DER + encoding MUST include only two bits: the first reserved bit + ("reserved", bit number zero, value zero) and the one-valued bit (bit + number one) for "forwardable". + + Most existing implementations of Kerberos unconditionally send 32 + bits on the wire when encoding bit strings used as boolean vectors. + This behavior violates the ASN.1 syntax used for flag values in RFC + 1510, but occurs on such a widely installed base that the protocol + + + +March 2003 [Page 63] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + description is being modified to accomodate it. + + Consequently, this document removes the "NamedBit" notations for + individual bits, relegating them to comments. The size constraint on + the KerberosFlags type requires that at least 32 bits be encoded at + all times, though a lenient implementation MAY choose to accept fewer + than 32 bits and to treat the missing bits as set to zero. + + Currently, no uses of KerberosFlags specify more than 32 bits worth + of flags, although future revisions of this document may do so. When + more than 32 bits are to be transmitted in a KerberosFlags value, + future revisions to this document will likely specify that the + smallest number of bits needed to encode the highest-numbered one- + valued bit should be sent. This is somewhat similar to the DER + encoding of a bit string that is declared with the "NamedBit" + notation. + +5.2.9. Cryptosystem-related Types + + Many Kerberos protocol messages contain an EncryptedData as a + container for arbitrary encrypted data, which is often the encrypted + encoding of another data type. Fields within EncryptedData assist the + recipient in selecting a key with which to decrypt the enclosed data. + + EncryptedData ::= SEQUENCE { + etype [0] Int32 -- EncryptionType --, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING -- ciphertext + } + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. + + kvno + This field contains the version number of the key under which data + is encrypted. It is only present in messages encrypted under long + lasting keys, such as principals' secret keys. + + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. (Note that the encryption mechanisms defined in + [@KCRYPTO] MUST incorporate integrity protection as well, so no + additional checksum is required.) + + The EncryptionKey type is the means by which cryptographic keys used + for encryption are transfered. + + + + +March 2003 [Page 64] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + EncryptionKey ::= SEQUENCE { + keytype [0] Int32 -- actually encryption type --, + keyvalue [1] OCTET STRING + } + + keytype + This field specifies the encryption type of the encryption key + that follows in the keyvalue field. While its name is "keytype", + it actually specifies an encryption type. Previously, multiple + cryptosystems that performed encryption differently but were + capable of using keys with the same characteristics were permitted + to share an assigned number to designate the type of key; this + usage is now deprecated. + + keyvalue + This field contains the key itself, encoded as an octet string. + + Messages containing cleartext data to be authenticated will usually + do so by using a member of type Checksum. Most instances of Checksum + use a keyed hash, though exceptions will be noted. + + Checksum ::= SEQUENCE { + cksumtype [0] Int32, + checksum [1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + + checksum + This field contains the checksum itself, encoded as an octet + string. + + See section 4 for a brief description of the use of encryption and + checksums in Kerberos. + +5.3. Tickets + + This section describes the format and encryption parameters for + tickets and authenticators. When a ticket or authenticator is + included in a protocol message it is treated as an opaque object. A + ticket is a record that helps a client authenticate to a service. A + Ticket contains the following information: + + Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] Realm, + + + +March 2003 [Page 65] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + sname [2] PrincipalName, + enc-part [3] EncryptedData -- EncTicketPart + } + + -- Encrypted part of ticket + EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + cname [3] PrincipalName, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL + } + + -- encoded Transited field + TransitedEncoding ::= SEQUENCE { + tr-type [0] Int32 -- must be registered --, + contents [1] OCTET STRING + } + + TicketFlags ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- the following are new since 1510 + -- transited-policy-checked(12), + -- ok-as-delegate(13) + + tkt-vno + This field specifies the version number for the ticket format. + This document describes version number 5. + + realm + This field specifies the realm that issued a ticket. It also + + + +March 2003 [Page 66] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + serves to identify the realm part of the server's principal + identifier. Since a Kerberos server can only issue tickets for + servers within its realm, the two will always be identical. + + sname + This field specifies all components of the name part of the + server's identity, including those parts that identify a specific + instance of a service. + + enc-part + This field holds the encrypted encoding of the EncTicketPart + sequence. It is encrypted in the key shared by Kerberos and the + end server (the server's secret key), using a key usage value of + 2. + + flags + This field indicates which of various options were used or + requested when the ticket was issued. The meanings of the flags + are: + + Bit(s) Name Description + + 0 reserved Reserved for future expansion of this + field. + + The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, this + 1 forwardable flag tells the ticket-granting server + that it is OK to issue a new + ticket-granting ticket with a + different network address based on the + presented ticket. + + When set, this flag indicates that the + ticket has either been forwarded or + 2 forwarded was issued based on authentication + involving a forwarded ticket-granting + ticket. + + The PROXIABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. The PROXIABLE + flag has an interpretation identical + 3 proxiable to that of the FORWARDABLE flag, + except that the PROXIABLE flag tells + the ticket-granting server that only + non-ticket-granting tickets may be + + + +March 2003 [Page 67] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + issued with different network + addresses. + + 4 proxy When set, this flag indicates that a + ticket is a proxy. + + The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be + 5 may-postdate ignored by end servers. This flag + tells the ticket-granting server that + a post-dated ticket MAY be issued + based on this ticket-granting ticket. + + This flag indicates that this ticket + has been postdated. The end-service + 6 postdated can check the authtime field to see + when the original authentication + occurred. + + This flag indicates that a ticket is + invalid, and it must be validated by + 7 invalid the KDC before use. Application + servers must reject tickets which have + this flag set. + + The RENEWABLE flag is normally only + interpreted by the TGS, and can + usually be ignored by end servers + 8 renewable (some particularly careful servers MAY + disallow renewable tickets). A + renewable ticket can be used to obtain + a replacement ticket that expires at a + later date. + + This flag indicates that this ticket + 9 initial was issued using the AS protocol, and + not issued based on a ticket-granting + ticket. + + This flag indicates that during + initial authentication, the client was + authenticated by the KDC before a + 10 pre-authent ticket was issued. The strength of the + pre-authentication method is not + indicated, but is acceptable to the + KDC. + + This flag indicates that the protocol + + + +March 2003 [Page 68] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + employed for initial authentication + required the use of hardware expected + 11 hw-authent to be possessed solely by the named + client. The hardware authentication + method is selected by the KDC and the + strength of the method is not + indicated. + + This flag indicates that the KDC for + the realm has checked the transited + field against a realm defined policy + for trusted certifiers. If this flag + is reset (0), then the application + server must check the transited field + itself, and if unable to do so it must + reject the authentication. If the flag + 12 transited- is set (1) then the application server + policy-checked MAY skip its own validation of the + transited field, relying on the + validation performed by the KDC. At + its option the application server MAY + still apply its own validation based + on a separate policy for acceptance. + + This flag is new since RFC 1510. + + This flag indicates that the server + (not the client) specified in the + ticket has been determined by policy + of the realm to be a suitable + recipient of delegation. A client can + use the presence of this flag to help + it make a decision whether to delegate + credentials (either grant a proxy or a + forwarded ticket-granting ticket) to + 13 ok-as-delegate this server. The client is free to + ignore the value of this flag. When + setting this flag, an administrator + should consider the Security and + placement of the server on which the + service will run, as well as whether + the service requires the use of + delegated credentials. + + This flag is new since RFC 1510. + + 14-31 reserved Reserved for future use. + + + + +March 2003 [Page 69] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + key + This field exists in the ticket and the KDC response and is used + to pass the session key from Kerberos to the application server + and the client. + + crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. + + cname + This field contains the name part of the client's principal + identifier. + + transited + This field lists the names of the Kerberos realms that took part + in authenticating the user to whom this ticket was issued. It does + not specify the order in which the realms were transited. See + section 3.3.3.2 for details on how this field encodes the + traversed realms. When the names of CA's are to be embedded in + the transited field (as specified for some extensions to the + protocol), the X.500 names of the CA's SHOULD be mapped into items + in the transited field using the mapping defined by RFC2253. + + authtime + This field indicates the time of initial authentication for the + named principal. It is the time of issue for the original ticket + on which this ticket is based. It is included in the ticket to + provide additional information to the end service, and to provide + the necessary information for implementation of a `hot list' + service at the KDC. An end service that is particularly paranoid + could refuse to accept tickets for which the initial + authentication occurred "too far" in the past. This field is also + returned as part of the response from the KDC. When returned as + part of the response to initial authentication (KRB_AS_REP), this + is the current time on the Kerberos server. It is NOT recommended + that this time value be used to adjust the workstation's clock + since the workstation cannot reliably determine that such a + KRB_AS_REP actually came from the proper KDC in a timely manner. + + + starttime + + This field in the ticket specifies the time after which the ticket + is valid. Together with endtime, this field specifies the life of + the ticket. If the starttime field is absent from the ticket, then + the authtime field SHOULD be used in its place to determine the + life of the ticket. + + + + +March 2003 [Page 70] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + endtime + This field contains the time after which the ticket will not be + honored (its expiration time). Note that individual services MAY + place their own limits on the life of a ticket and MAY reject + tickets which have not yet expired. As such, this is really an + upper bound on the expiration time for the ticket. + + renew-till + This field is only present in tickets that have the RENEWABLE flag + set in the flags field. It indicates the maximum endtime that may + be included in a renewal. It can be thought of as the absolute + expiration time for the ticket, including all renewals. + + caddr + This field in a ticket contains zero (if omitted) or more (if + present) host addresses. These are the addresses from which the + ticket can be used. If there are no addresses, the ticket can be + used from any location. The decision by the KDC to issue or by the + end server to accept addressless tickets is a policy decision and + is left to the Kerberos and end-service administrators; they MAY + refuse to issue or accept such tickets. Because of the wide + deployment of network address translation, it is recommended that + policy allow the issue and acceptance of such tickets. + + Network addresses are included in the ticket to make it harder for + an attacker to use stolen credentials. Because the session key is + not sent over the network in cleartext, credentials can't be + stolen simply by listening to the network; an attacker has to gain + access to the session key (perhaps through operating system + security breaches or a careless user's unattended session) to make + use of stolen tickets. + + It is important to note that the network address from which a + connection is received cannot be reliably determined. Even if it + could be, an attacker who has compromised the client's workstation + could use the credentials from there. Including the network + addresses only makes it more difficult, not impossible, for an + attacker to walk off with stolen credentials and then use them + from a "safe" location. + + authorization-data + The authorization-data field is used to pass authorization data + from the principal on whose behalf a ticket was issued to the + application service. If no authorization data is included, this + field will be left out. Experience has shown that the name of this + field is confusing, and that a better name for this field would be + restrictions. Unfortunately, it is not possible to change the name + of this field at this time. + + + +March 2003 [Page 71] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + This field contains restrictions on any authority obtained on the + basis of authentication using the ticket. It is possible for any + principal in posession of credentials to add entries to the + authorization data field since these entries further restrict what + can be done with the ticket. Such additions can be made by + specifying the additional entries when a new ticket is obtained + during the TGS exchange, or they MAY be added during chained + delegation using the authorization data field of the + authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapsulation in the KDC-issued element, it is not allowable for + the presence of an entry in the authorization data field of a + ticket to amplify the privileges one would obtain from using a + ticket. + + The data in this field may be specific to the end service; the + field will contain the names of service specific objects, and the + rights to those objects. The format for this field is described in + section 5.2.6. Although Kerberos is not concerned with the format + of the contents of the sub-fields, it does carry type information + (ad-type). + + By using the authorization_data field, a principal is able to + issue a proxy that is valid for a specific purpose. For example, a + client wishing to print a file can obtain a file server proxy to + be passed to the print server. By specifying the name of the file + in the authorization_data field, the file server knows that the + print server can only use the client's rights when accessing the + particular file to be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In + this case, the entity granting authorization (not the authorized + entity), may obtain a ticket in its own name (e.g. the ticket is + issued in the name of a privilege server), and this entity adds + restrictions on its own authority and delegates the restricted + authority through a proxy to the client. The client would then + present this authorization credential to the application server + separately from the authentication exchange. Alternatively, such + authorization credentials MAY be embedded in the ticket + authenticating the authorized entity, when the authorization is + separately authenticated using the KDC-issued authorization data + element (see 5.2.6.2). + + Similarly, if one specifies the authorization-data field of a + proxy and leaves the host addresses blank, the resulting ticket + + + +March 2003 [Page 72] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + and session key can be treated as a capability. See [Neu93] for + some suggested uses of this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.4. Specifications for the AS and TGS exchanges + + This section specifies the format of the messages used in the + exchange between the client and the Kerberos server. The format of + possible error messages appears in section 5.9.1. + +5.4.1. KRB_KDC_REQ definition + + The KRB_KDC_REQ message has no application tag number of its own. + Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, + which each have an application tag, depending on whether the request + is for an initial ticket or an additional ticket. In either case, the + message is sent from the client to the KDC to request credentials for + a service. + + The message fields are: + + AS-REQ ::= [APPLICATION 10] KDC-REQ + + TGS-REQ ::= [APPLICATION 12] KDC-REQ + + KDC-REQ ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5) , + msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), + padata [3] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + req-body [4] KDC-REQ-BODY + } + + KDC-REQ-BODY ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + realm [2] Realm + -- Server's realm + -- Also client's in AS-REQ --, + sname [3] PrincipalName OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime, + rtime [6] KerberosTime OPTIONAL, + nonce [7] UInt32, + + + +March 2003 [Page 73] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + etype [8] SEQUENCE OF Int32 -- EncryptionType + -- in preference order --, + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData -- AuthorizationData --, + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty + } + + KDCOptions ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + -- unused7(7), + -- renewable(8), + -- unused9(9), + -- unused10(10), + -- opt-hardware-auth(11), + -- unused12(12), + -- unused13(13), + -- 15 is reserved for canonicalize + -- unused15(15), + -- 26 was unused in 1510 + -- disable-transited-check(26), + -- + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + + The fields in this message are: + + pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. + + msg-type + This field indicates the type of a protocol message. It will + almost always be the same as the application identifier associated + with a message. It is included to make the identifier more readily + accessible to the application. For the KDC-REQ message, this type + will be KRB_AS_REQ or KRB_TGS_REQ. + + padata + Contains pre-authentication data. Requests for additional tickets + + + +March 2003 [Page 74] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. + + The padata (pre-authentication data) field contains a sequence of + authentication information which may be needed before credentials + can be issued or decrypted. + + req-body + This field is a placeholder delimiting the extent of the remaining + fields. If a checksum is to be calculated over the request, it is + calculated over an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. + + kdc-options + This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to + the KDC and indicates the flags that the client wants set on the + tickets as well as other information that is to modify the + behavior of the KDC. Where appropriate, the name of an option may + be the same as the flag that is set by that option. Although in + most case, the bit in the options field will be the same as that + in the flags field, this is not guaranteed, so it is not + acceptable to simply copy the options field to the flags field. + There are various checks that must be made before honoring an + option anyway. + + The kdc_options field is a bit-field, where the selected options + are indicated by the bit being set (1), and the unselected options + and reserved fields being reset (0). The encoding of the bits is + specified in section 5.2. The options are described in more detail + above in section 2. The meanings of the options are: + + Bits Name Description + + 0 RESERVED Reserved for future expansion of + this field. + + The FORWARDABLE option indicates + that the ticket to be issued is to + have its forwardable flag set. It + 1 FORWARDABLE may only be set on the initial + request, or in a subsequent request + if the ticket-granting ticket on + which it is based is also + forwardable. + + The FORWARDED option is only + specified in a request to the + ticket-granting server and will only + be honored if the ticket-granting + + + +March 2003 [Page 75] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + ticket in the request has its + 2 FORWARDED FORWARDABLE bit set. This option + indicates that this is a request for + forwarding. The address(es) of the + host from which the resulting ticket + is to be valid are included in the + addresses field of the request. + + The PROXIABLE option indicates that + the ticket to be issued is to have + its proxiable flag set. It may only + 3 PROXIABLE be set on the initial request, or in + a subsequent request if the + ticket-granting ticket on which it + is based is also proxiable. + + The PROXY option indicates that this + is a request for a proxy. This + option will only be honored if the + ticket-granting ticket in the + 4 PROXY request has its PROXIABLE bit set. + The address(es) of the host from + which the resulting ticket is to be + valid are included in the addresses + field of the request. + + The ALLOW-POSTDATE option indicates + that the ticket to be issued is to + have its MAY-POSTDATE flag set. It + 5 ALLOW-POSTDATE may only be set on the initial + request, or in a subsequent request + if the ticket-granting ticket on + which it is based also has its + MAY-POSTDATE flag set. + + The POSTDATED option indicates that + this is a request for a postdated + ticket. This option will only be + honored if the ticket-granting + ticket on which it is based has its + 6 POSTDATED MAY-POSTDATE flag set. The resulting + ticket will also have its INVALID + flag set, and that flag may be reset + by a subsequent request to the KDC + after the starttime in the ticket + has been reached. + + 7 RESERVED This option is presently unused. + + + +March 2003 [Page 76] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + The RENEWABLE option indicates that + the ticket to be issued is to have + its RENEWABLE flag set. It may only + be set on the initial request, or + when the ticket-granting ticket on + 8 RENEWABLE which the request is based is also + renewable. If this option is + requested, then the rtime field in + the request contains the desired + absolute expiration time for the + ticket. + + 9 RESERVED Reserved for PK-Cross + + 10 RESERVED Reserved for future use. + + 11 RESERVED Reserved for opt-hardware-auth. + + 12-25 RESERVED Reserved for future use. + + By default the KDC will check the + transited field of a + ticket-granting-ticket against the + policy of the local realm before it + will issue derivative tickets based + on the ticket-granting ticket. If + this flag is set in the request, + checking of the transited field is + disabled. Tickets issued without the + 26 DISABLE-TRANSITED-CHECK performance of this check will be + noted by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the tranisted field must be + checked locally. KDCs are + encouraged but not required to honor + the DISABLE-TRANSITED-CHECK option. + + This flag is new since RFC 1510 + + The RENEWABLE-OK option indicates + that a renewable ticket will be + acceptable if a ticket with the + requested life cannot otherwise be + provided. If a ticket with the + requested life cannot be provided, + 27 RENEWABLE-OK then a renewable ticket may be + issued with a renew-till equal to + + + +March 2003 [Page 77] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + the requested endtime. The value + of the renew-till field may still be + limited by local limits, or limits + selected by the individual principal + or server. + + This option is used only by the + ticket-granting service. The + ENC-TKT-IN-SKEY option indicates + 28 ENC-TKT-IN-SKEY that the ticket for the end server + is to be encrypted in the session + key from the additional + ticket-granting ticket provided. + + 29 RESERVED Reserved for future use. + + This option is used only by the + ticket-granting service. The RENEW + option indicates that the present + request is for a renewal. The ticket + provided is encrypted in the secret + key for the server on which it is + 30 RENEW valid. This option will only be + honored if the ticket to be renewed + has its RENEWABLE flag set and if + the time in its renew-till field has + not passed. The ticket to be renewed + is passed in the padata field as + part of the authentication header. + + This option is used only by the + ticket-granting service. The + VALIDATE option indicates that the + request is to validate a postdated + ticket. It will only be honored if + the ticket presented is postdated, + presently has its INVALID flag set, + 31 VALIDATE and would be otherwise usable at + this time. A ticket cannot be + validated before its starttime. The + ticket presented for validation is + encrypted in the key of the server + for which it is valid and is passed + in the padata field as part of the + authentication header. + cname and sname + These fields are the same as those described for the ticket in + section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY + + + +March 2003 [Page 78] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + option is specified. If absent, the name of the server is taken + from the name of the client in the ticket passed as additional- + tickets. + + enc-authorization-data + The enc-authorization-data, if present (and it can only be present + in the TGS_REQ form), is an encoding of the desired authorization- + data encrypted under the sub-session key if present in the + Authenticator, or alternatively from the session key in the + ticket-granting ticket (both the Authenticator and ticket-granting + ticket come from the padata field in the KRB_TGS_REQ). The key + usage value used when encrypting is 5 if a sub-session key is + used, or 4 if the session key is used. + + realm + This field specifies the realm part of the server's principal + identifier. In the AS exchange, this is also the realm part of the + client's principal identifier. + + from + This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket + requests when the requested ticket is to be postdated. It + specifies the desired start time for the requested ticket. If this + field is omitted then the KDC SHOULD use the current time instead. + + till + This field contains the expiration date requested by the client in + a ticket request. It is not optional, but if the requested endtime + is "19700101000000Z", the requested ticket is to have the maximum + endtime permitted according to KDC policy. Implementation note: + This special timestamp corresponds to a UNIX time_t value of zero + on most systems. + + rtime + This field is the requested renew-till time sent from a client to + the KDC in a ticket request. It is optional. + + nonce + This field is part of the KDC request and response. It is intended + to hold a random number generated by the client. If the same + number is included in the encrypted response from the KDC, it + provides evidence that the response is fresh and has not been + replayed by an attacker. Nonces MUST NEVER be reused. + + etype + This field specifies the desired encryption algorithm to be used + in the response. + + + + +March 2003 [Page 79] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + addresses + This field is included in the initial request for tickets, and + optionally included in requests for additional tickets from the + ticket-granting server. It specifies the addresses from which the + requested ticket is to be valid. Normally it includes the + addresses for the client's host. If a proxy is requested, this + field will contain other addresses. The contents of this field are + usually copied by the KDC into the caddr field of the resulting + ticket. + + additional-tickets + Additional tickets MAY be optionally included in a request to the + ticket-granting server. If the ENC-TKT-IN-SKEY option has been + specified, then the session key from the additional ticket will be + used in place of the server's key to encrypt the new ticket. When + the ENC-TKT-IN-SKEY option is used for user-to-user + authentication, this addional ticket MAY be a TGT issued by the + local realm or an inter-realm TGT issued for the current KDC's + realm by a remote KDC. If more than one option which requires + additional tickets has been specified, then the additional tickets + are used in the order specified by the ordering of the options + bits (see kdc-options, above). + + The application tag number will be either ten (10) or twelve (12) + depending on whether the request is for an initial ticket (AS-REQ) or + for an additional ticket (TGS-REQ). + + The optional fields (addresses, authorization-data and additional- + tickets) are only included if necessary to perform the operation + specified in the kdc-options field. + + It should be noted that in KRB_TGS_REQ, the protocol version number + appears twice and two different message types appear: the KRB_TGS_REQ + message contains these fields as does the authentication header + (KRB_AP_REQ) that is passed in the padata field. + +5.4.2. KRB_KDC_REP definition + + The KRB_KDC_REP message format is used for the reply from the KDC for + either an initial (AS) request or a subsequent (TGS) request. There + is no message type for KRB_KDC_REP. Instead, the type will be either + KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext + part of the reply depends on the message type. For KRB_AS_REP, the + ciphertext is encrypted in the client's secret key, and the client's + key version number is included in the key version number for the + encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the + sub-session key from the Authenticator, or if absent, the session key + from the ticket-granting ticket used in the request. In that case, + + + +March 2003 [Page 80] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + no version number will be present in the EncryptedData sequence. + + The KRB_KDC_REP message contains the following fields: + + AS-REP ::= [APPLICATION 11] KDC-REP + + TGS-REP ::= [APPLICATION 13] KDC-REP + + KDC-REP ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), + padata [2] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + crealm [3] Realm, + cname [4] PrincipalName, + ticket [5] Ticket, + enc-part [6] EncryptedData + -- EncASRepPart or EncTGSRepPart, + -- as appropriate + } + + EncASRepPart ::= [APPLICATION 25] EncKDCRepPart + + EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + + EncKDCRepPart ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] UInt32, + key-expiration [3] KerberosTime OPTIONAL, + flags [4] TicketFlags, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + srealm [9] Realm, + sname [10] PrincipalName, + caddr [11] HostAddresses OPTIONAL + } + + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type [0] Int32, + lr-value [1] KerberosTime + } + + pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + either KRB_AS_REP or KRB_TGS_REP. + + + +March 2003 [Page 81] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + padata + This field is described in detail in section 5.4.1. One possible + use for this field is to encode an alternate "salt" string to be + used with a string-to-key algorithm. This ability is useful to + ease transitions if a realm name needs to change (e.g. when a + company is acquired); in such a case all existing password-derived + entries in the KDC database would be flagged as needing a special + salt string until the next password change. + + crealm, cname, srealm and sname + These fields are the same as those described for the ticket in + section 5.3. + + ticket + The newly-issued ticket, from section 5.3. + + enc-part + This field is a place holder for the ciphertext and related + information that forms the encrypted part of a message. The + description of the encrypted part of the message follows each + appearance of this field. + + The key usage value for encrypting this field is 3 in an AS-REP + message, using the client's long-term key or another key selected + via pre-authentication mechanisms. In a TGS-REP message, the key + usage value is 8 if the TGS session key is used, or 9 if a TGS + authenticator subkey is used. + + Compatibility note: Some implementations unconditionally send an + encrypted EncTGSRepPart (application tag number 26) in this field + regardless of whether the reply is a AS-REP or a TGS-REP. In the + interests of compatibility, implementors MAY relax the check on + the tag number of the decrypted ENC-PART. + + key + This field is the same as described for the ticket in section 5.3. + + last-req + This field is returned by the KDC and specifies the time(s) of the + last request by a principal. Depending on what information is + available, this might be the last time that a request for a + ticket-granting ticket was made, or the last time that a request + based on a ticket-granting ticket was successful. It also might + cover all servers for a realm, or just the particular server. Some + implementations MAY display this information to the user to aid in + discovering unauthorized use of one's identity. It is similar in + spirit to the last login time displayed when logging into + timesharing systems. + + + +March 2003 [Page 82] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + lr-type + This field indicates how the following lr-value field is to be + interpreted. Negative values indicate that the information + pertains only to the responding server. Non-negative values + pertain to all servers for the realm. + + If the lr-type field is zero (0), then no information is + conveyed by the lr-value subfield. If the absolute value of the + lr-type field is one (1), then the lr-value subfield is the + time of last initial request for a TGT. If it is two (2), then + the lr-value subfield is the time of last initial request. If + it is three (3), then the lr-value subfield is the time of + issue for the newest ticket-granting ticket used. If it is four + (4), then the lr-value subfield is the time of the last + renewal. If it is five (5), then the lr-value subfield is the + time of last request (of any type). If it is (6), then the lr- + value subfield is the time when the password will expire. If + it is (7), then the lr-value subfield is the time when the + account will expire. + + lr-value + This field contains the time of the last request. The time MUST + be interpreted according to the contents of the accompanying + lr-type subfield. + + nonce + This field is described above in section 5.4.1. + + key-expiration + The key-expiration field is part of the response from the KDC and + specifies the time that the client's secret key is due to expire. + The expiration might be the result of password aging or an account + expiration. If present, it SHOULD be set to the earliest of the + user's key expiration and account expiration. The use of this + field is deprecated and the last-req field SHOULD be used to + convey this information instead. This field will usually be left + out of the TGS reply since the response to the TGS request is + encrypted in a session key and no client information need be + retrieved from the KDC database. It is up to the application + client (usually the login program) to take appropriate action + (such as notifying the user) if the expiration time is imminent. + + flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the encrypted + portion of the attached ticket (see section 5.3), provided so the + client MAY verify they match the intended request and to assist in + proper ticket caching. If the message is of type KRB_TGS_REP, the + caddr field will only be filled in if the request was for a proxy + + + +March 2003 [Page 83] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + or forwarded ticket, or if the user is substituting a subset of + the addresses from the ticket-granting ticket. If the client- + requested addresses are not present or not used, then the + addresses contained in the ticket will be the same as those + included in the ticket-granting ticket. + +5.5. Client/Server (CS) message specifications + + This section specifies the format of the messages used for the + authentication of the client to the application server. + +5.5.1. KRB_AP_REQ definition + + The KRB_AP_REQ message contains the Kerberos protocol version number, + the message type KRB_AP_REQ, an options field to indicate any options + in use, and the ticket and authenticator themselves. The KRB_AP_REQ + message is often referred to as the 'authentication header'. + + AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData -- Authenticator + } + + APOptions ::= KerberosFlags + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + + pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REQ. + + ap-options + This field appears in the application request (KRB_AP_REQ) and + affects the way the request is processed. It is a bit-field, where + the selected options are indicated by the bit being set (1), and + the unselected options and reserved fields being reset (0). The + encoding of the bits is specified in section 5.2. The meanings of + the options are: + + Bit(s) Name Description + + 0 reserved Reserved for future expansion of this field. + + The USE-SESSION-KEY option indicates that the + + + +March 2003 [Page 84] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + ticket the client is presenting to a server + 1 use-session-key is encrypted in the session key from the + server's ticket-granting ticket. When this + option is not specified, the ticket is + encrypted in the server's secret key. + + The MUTUAL-REQUIRED option tells the server + 2 mutual-required that the client requires mutual + authentication, and that it must respond with + a KRB_AP_REP message. + + 3-31 reserved Reserved for future use. + + ticket + This field is a ticket authenticating the client to the server. + + authenticator + This contains the encrypted authenticator, which includes the + client's choice of a subkey. + + The encrypted authenticator is included in the AP-REQ; it certifies + to a server that the sender has recent knowledge of the encryption + key in the accompanying ticket, to help the server detect replays. It + also assists in the selection of a "true session key" to use with the + particular session. The DER encoding of the following is encrypted + in the ticket's session key, with a key usage value of 11 in normal + application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field + of a TGS-REQ exchange (see section 5.4.1): + + -- Unencrypted authenticator + Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] Realm, + cname [2] PrincipalName, + cksum [3] Checksum OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] UInt32 OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL + } + + authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies version 5. + + crealm and cname + These fields are the same as those described for the ticket in + + + +March 2003 [Page 85] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + section 5.3. + + cksum + This field contains a checksum of the application data that + accompanies the KRB_AP_REQ, computed using a key usage value of 10 + in normal application exchanges, or 6 when used in the TGS-REQ PA- + TGS-REQ AP-DATA field. + + cusec + This field contains the microsecond part of the client's + timestamp. Its value (before encryption) ranges from 0 to 999999. + It often appears along with ctime. The two fields are used + together to specify a reasonably accurate timestamp. + + ctime + This field contains the current time on the client's host. + + subkey + This field contains the client's choice for an encryption key + which is to be used to protect this specific application session. + Unless an application specifies otherwise, if this field is left + out the session key from the ticket will be used. + + seq-number + This optional field includes the initial sequence number to be + used by the KRB_PRIV or KRB_SAFE messages when sequence numbers + are used to detect replays (It may also be used by application + specific messages). When included in the authenticator this field + specifies the initial sequence number for messages from the client + to the server. When included in the AP-REP message, the initial + sequence number is that for messages from the server to the + client. When used in KRB_PRIV or KRB_SAFE messages, it is + incremented by one after each message is sent. Sequence numbers + fall in the range of 0 through 2^32 - 1 and wrap to zero following + the value 2^32 - 1. + + For sequence numbers to adequately support the detection of + replays they SHOULD be non-repeating, even across connection + boundaries. The initial sequence number SHOULD be random and + uniformly distributed across the full space of possible sequence + numbers, so that it cannot be guessed by an attacker and so that + it and the successive sequence numbers do not repeat other + sequences. + + Implmentation note: historically, some implementations transmit + signed twos-complement numbers for sequence numbers. In the + interests of compatibility, implementations MAY accept the + equivalent negative number where a positive number greater than + + + +March 2003 [Page 86] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + 2^31 - 1 is expected. + + Implementation note: as noted before, some implementations omit + the optional sequence number when its value would be zero. + Implementations MAY accept an omitted sequence number when + expecting a value of zero, and SHOULD NOT transmit an + Authenticator with a initial sequence number of zero. + + authorization-data + This field is the same as described for the ticket in section 5.3. + It is optional and will only appear when additional restrictions + are to be placed on the use of a ticket, beyond those carried in + the ticket itself. + +5.5.2. KRB_AP_REP definition + + The KRB_AP_REP message contains the Kerberos protocol version number, + the message type, and an encrypted time-stamp. The message is sent in + response to an application request (KRB_AP_REQ) where the mutual + authentication option has been selected in the ap-options field. + + AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15), + enc-part [2] EncryptedData -- EncAPRepPart + } + + EncAPRepPart ::= [APPLICATION 27] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] UInt32 OPTIONAL + } + + The encoded EncAPRepPart is encrypted in the shared session key of + the ticket. The optional subkey field can be used in an application- + arranged negotiation to choose a per association session key. + + pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REP. + + enc-part + This field is described above in section 5.4.2. It is computed + with a key usage value of 12. + + ctime + This field contains the current time on the client's host. + + + +March 2003 [Page 87] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + cusec + This field contains the microsecond part of the client's + timestamp. + + subkey + This field contains an encryption key which is to be used to + protect this specific application session. See section 3.2.6 for + specifics on how this field is used to negotiate a key. Unless an + application specifies otherwise, if this field is left out, the + sub-session key from the authenticator, or if also left out, the + session key from the ticket will be used. + + seq-number + This field is described above in section 5.3.2. + +5.5.3. Error message reply + + If an error occurs while processing the application request, the + KRB_ERROR message will be sent in response. See section 5.9.1 for the + format of the error message. The cname and crealm fields MAY be left + out if the server cannot determine their appropriate values from the + corresponding KRB_AP_REQ message. If the authenticator was + decipherable, the ctime and cusec fields will contain the values from + it. + +5.6. KRB_SAFE message specification + + This section specifies the format of a message that can be used by + either side (client or server) of an application to send a tamper- + proof message to its peer. It presumes that a session key has + previously been exchanged (for example, by using the + KRB_AP_REQ/KRB_AP_REP messages). + +5.6.1. KRB_SAFE definition + + The KRB_SAFE message contains user data along with a collision-proof + checksum keyed with the last encryption key negotiated via subkeys, + or the session key if no negotiation has occurred. The message fields + are: + + KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (20), + safe-body [2] KRB-SAFE-BODY, + cksum [3] Checksum + } + + KRB-SAFE-BODY ::= SEQUENCE { + + + +March 2003 [Page 88] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL + } + + pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_SAFE. + + safe-body + This field is a placeholder for the body of the KRB-SAFE message. + + cksum + This field contains the checksum of the application data, computed + with a key usage value of 15. + + The checksum is computed over the encoding of the KRB-SAFE + sequence. First, the cksum is set to a type zero, zero-length + value and the checksum is computed over the encoding of the KRB- + SAFE sequence, then the checksum is set to the result of that + computation, and finally the KRB-SAFE sequence is encoded again. + This method, while different than the one specified in RFC 1510, + corresponds to existing practice. + + user-data + This field is part of the KRB_SAFE and KRB_PRIV messages and + contain the application specific data that is being passed from + the sender to the recipient. + + timestamp + This field is part of the KRB_SAFE and KRB_PRIV messages. Its + contents are the current time as known by the sender of the + message. By checking the timestamp, the recipient of the message + is able to make sure that it was recently generated, and is not a + replay. + + usec + This field is part of the KRB_SAFE and KRB_PRIV headers. It + contains the microsecond part of the timestamp. + + seq-number + This field is described above in section 5.3.2. + + s-address + Sender's address. + + + +March 2003 [Page 89] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + This field specifies the address in use by the sender of the + message. It MAY be omitted if not required by the application + protocol. + + r-address + This field specifies the address in use by the recipient of the + message. It MAY be omitted for some uses (such as broadcast + protocols), but the recipient MAY arbitrarily reject such + messages. This field, along with s-address, can be used to help + detect messages which have been incorrectly or maliciously + delivered to the wrong recipient. + +5.7. KRB_PRIV message specification + + This section specifies the format of a message that can be used by + either side (client or server) of an application to securely and + privately send a message to its peer. It presumes that a session key + has previously been exchanged (for example, by using the + KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + + The KRB_PRIV message contains user data encrypted in the Session Key. + The message fields are: + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + -- NOTE: there is no [2] tag + enc-part [3] EncryptedData -- EncKrbPrivPart + } + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr + } + + pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_PRIV. + + enc-part + This field holds an encoding of the EncKrbPrivPart sequence + encrypted under the session key, with a key usage value of 13. + + + +March 2003 [Page 90] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + This encrypted encoding is used for the enc-part field of the KRB- + PRIV message. + + user-data, timestamp, usec, s-address and r-address + These fields are described above in section 5.6.1. + + seq-number + This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + + This section specifies the format of a message that can be used to + send Kerberos credentials from one principal to another. It is + presented here to encourage a common mechanism to be used by + applications when forwarding tickets or providing proxies to + subordinate servers. It presumes that a session key has already been + exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + + The KRB_CRED message contains a sequence of tickets to be sent and + information needed to use the tickets, including the session key from + each. The information needed to use the tickets is encrypted under + an encryption key previously exchanged or transferred alongside the + KRB_CRED message. The message fields are: + + KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData -- EncKrbCredPart + } + + EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] UInt32 OPTIONAL, + timestamp [2] KerberosTime OPTIONAL, + usec [3] Microseconds OPTIONAL, + s-address [4] HostAddress OPTIONAL, + r-address [5] HostAddress OPTIONAL + } + + KrbCredInfo ::= SEQUENCE { + key [0] EncryptionKey, + prealm [1] Realm OPTIONAL, + pname [2] PrincipalName OPTIONAL, + flags [3] TicketFlags OPTIONAL, + authtime [4] KerberosTime OPTIONAL, + + + +March 2003 [Page 91] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + starttime [5] KerberosTime OPTIONAL, + endtime [6] KerberosTime OPTIONAL, + renew-till [7] KerberosTime OPTIONAL, + srealm [8] Realm OPTIONAL, + sname [9] PrincipalName OPTIONAL, + caddr [10] HostAddresses OPTIONAL + } + + pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_CRED. + + tickets + These are the tickets obtained from the KDC specifically for use + by the intended recipient. Successive tickets are paired with the + corresponding KrbCredInfo sequence from the enc-part of the KRB- + CRED message. + + enc-part + This field holds an encoding of the EncKrbCredPart sequence + encrypted under the session key shared between the sender and the + intended recipient, with a key usage value of 14. This encrypted + encoding is used for the enc-part field of the KRB-CRED message. + + Implementation note: implementations of certain applications, most + notably certain implementations of the Kerberos GSS-API mechanism, + do not separately encrypt the contents of the EncKrbCredPart of + the KRB-CRED message when sending it. In the case of those GSS- + API mechanisms, this is not a security vulnerability, as the + entire KRB-CRED message is itself embedded in an encrypted + message. + + nonce + If practical, an application MAY require the inclusion of a nonce + generated by the recipient of the message. If the same value is + included as the nonce in the message, it provides evidence that + the message is fresh and has not been replayed by an attacker. A + nonce MUST NEVER be reused; it SHOULD be generated randomly by the + recipient of the message and provided to the sender of the message + in an application specific manner. + + timestamp and usec + These fields specify the time that the KRB-CRED message was + generated. The time is used to provide assurance that the message + is fresh. + + s-address and r-address + These fields are described above in section 5.6.1. They are used + + + +March 2003 [Page 92] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + optionally to provide additional assurance of the integrity of the + KRB-CRED message. + + key + This field exists in the corresponding ticket passed by the KRB- + CRED message and is used to pass the session key from the sender + to the intended recipient. The field's encoding is described in + section 5.2.9. + + The following fields are optional. If present, they can be associated + with the credentials in the remote ticket file. If left out, then it + is assumed that the recipient of the credentials already knows their + value. + + prealm and pname + The name and realm of the delegated principal identity. + + flags, authtime, starttime, endtime, renew-till, srealm, sname, and + caddr + These fields contain the values of the corresponding fields from + the ticket found in the ticket field. Descriptions of the fields + are identical to the descriptions in the KDC-REP message. + +5.9. Error message specification + + This section specifies the format for the KRB_ERROR message. The + fields included in the message are intended to return as much + information as possible about an error. It is not expected that all + the information required by the fields will be available for all + types of errors. If the appropriate information is not available when + the message is composed, the corresponding field will be left out of + the message. + + Note that since the KRB_ERROR message is not integrity protected, it + is quite possible for an intruder to synthesize or modify such a + message. In particular, this means that the client SHOULD NOT use any + fields in this message for security-critical purposes, such as + setting a system clock or generating a fresh authenticator. The + message can be useful, however, for advising a user on the reason for + some failure. + +5.9.1. KRB_ERROR definition + + The KRB_ERROR message consists of the following fields: + + KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30), + + + +March 2003 [Page 93] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] Int32, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- service realm --, + sname [10] PrincipalName -- service name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL + } + + pvno and msg-type + These fields are described above in section 5.4.1. +A msg-type is + KRB_ERROR. + + ctime + This field is described above in section 5.4.1. + + cusec + This field is described above in section 5.5.2. + + stime + This field contains the current time on the server. It is of type + KerberosTime. + + susec + This field contains the microsecond part of the server's + timestamp. Its value ranges from 0 to 999999. It appears along + with stime. The two fields are used in conjunction to specify a + reasonably accurate timestamp. + + error-code + This field contains the error code returned by Kerberos or the + server when a request fails. To interpret the value of this field + see the list of error codes in section 7.5.9. Implementations are + encouraged to provide for national language support in the display + of error messages. + + crealm, cname, srealm and sname + These fields are described above in section 5.3. + + e-text + This field contains additional text to help explain the error code + associated with the failed request (for example, it might include + a principal name which was unknown). + + + + +March 2003 [Page 94] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + e-data + This field contains additional data about the error for use by the + application to help it recover from or handle the error. If the + errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will + contain an encoding of a sequence of padata fields, each + corresponding to an acceptable pre-authentication method and + optionally containing data for the method: + + METHOD-DATA ::= SEQUENCE OF PA-DATA + + For error codes defined in this document other than + KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field + are implementation-defined. Similarly, for future error codes, the + format and contents of the e-data field are implementation-defined + unless specified. Whether defined by the implementation or in a + future document, the e-data field MAY take the form of TYPED-DATA: + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING OPTIONAL + } + +5.10. Application Tag Numbers + + The following table lists the application class tag numbers used by + various data types defined in this section. + + Tag Number(s) Type Name Comments + + 0 unused + + 1 Ticket PDU + + 2 Authenticator non-PDU + + 3 EncTicketPart non-PDU + + 4-9 unused + + 10 AS-REQ PDU + + 11 AS-REP PDU + + 12 TGS-REQ PDU + + 13 TGS-REP PDU + + 14 AP-REQ PDU + + + +March 2003 [Page 95] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + 15 AP-REP PDU + + 16 RESERVED16 TGT-REQ (for user-to-user) + + 17 RESERVED17 TGT-REP (for user-to-user) + + 18-19 unused + + 20 KRB-SAFE PDU + + 21 KRB-PRIV PDU + + 22 KRB-CRED PDU + + 23-24 unused + + 25 EncASRepPart non-PDU + + 26 EncTGSRepPart non-PDU + + 27 EncApRepPart non-PDU + + 28 EncKrbPrivPart non-PDU + + 29 EncKrbCredPart non-PDU + + 30 KRB-ERROR PDU + + The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are + the only ASN.1 types intended as top-level types of the Kerberos + protcol, and are the only types that may be used as elements in + another protocol that makes use of Kerberos. + +6. Naming Constraints + +6.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a + realm can technically select any name it chooses, interoperability + across realm boundaries requires agreement on how realm names are to + be assigned, and what information they imply. + + To enforce these conventions, each realm MUST conform to the + conventions itself, and it MUST require that any realms with which + inter-realm keys are shared also conform to the conventions and + require the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names that differ only + + + +March 2003 [Page 96] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + in the case of the characters are not equivalent. There are presently + three styles of realm names: domain, X500, and other. Examples of + each style follow: + + domain: ATHENA.MIT.EDU + X500: C=US/O=OSF + other: NAMETYPE:rest/of.name=without-restrictions + + Domain syle realm names MUST look like domain names: they consist of + components separated by periods (.) and they contain neither colons + (:) nor slashes (/). Though domain names themselves are case + insensitive, in order for realms to match, the case must match as + well. When establishing a new realm name based on an internet domain + name it is recommended by convention that the characters be converted + to upper case. + + X.500 names contain an equal (=) and cannot contain a colon (:) + before the equal. The realm names for X.500 names will be string + representations of the names with components separated by slashes. + Leading and trailing slashes will not be included. Note that the + slash separator is consistent with Kerberos implementations based on + RFC1510, but it is different from the separator recommended in + RFC2253. + + Names that fall into the other category MUST begin with a prefix that + contains no equal (=) or period (.) and the prefix MUST be followed + by a colon (:) and the rest of the name. All prefixes must be + assigned before they may be used. Presently none are assigned. + + The reserved category includes strings which do not fall into the + first three categories. All names in this category are reserved. It + is unlikely that names will be assigned to this category unless there + is a very strong argument for not using the 'other' category. + + These rules guarantee that there will be no conflicts between the + various name styles. The following additional constraints apply to + the assignment of realm names in the domain and X.500 categories: the + name of a realm for the domain or X.500 formats must either be used + by the organization owning (to whom it was assigned) an Internet + domain name or X.500 name, or in the case that no such names are + registered, authority to use a realm name MAY be derived from the + authority of the parent realm. For example, if there is no domain + name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can + authorize the creation of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + its children in the X.500 and domain name systems as well. If the + + + +March 2003 [Page 97] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make + sure that there will not in the future exist a name identical to the + realm name of the child unless it is assigned to the same entity as + the realm name. + +6.2. Principal Names + + As was the case for realm names, conventions are needed to ensure + that all agree on what information is implied by a principal name. + The name-type field that is part of the principal name indicates the + kind of information implied by the name. The name-type SHOULD be + treated only as a hint to interpreting the meaning of a name. It is + not significant when checking for equivalence. Principal names that + differ only in the name-type identify the same principal. The name + type does not partition the name space. Ignoring the name type, no + two names can be the same (i.e. at least one of the components, or + the realm, MUST be different). The following name types are defined: + + name-type value meaning + + name types + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) + NT-SRV-XHST 4 Service with host as remaining components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) + NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name + + When a name implies no information other than its uniqueness at a + particular time the name type PRINCIPAL SHOULD be used. The principal + name type SHOULD be used for users, and it might also be used for a + unique server. If the name is a unique machine generated ID that is + guaranteed never to be reassigned then the name type of UID SHOULD be + used (note that it is generally a bad idea to reassign names of any + type since stale entries might remain in access control lists). + + If the first component of a name identifies a service and the + remaining components identify an instance of the service in a server + specified manner, then the name type of SRV-INST SHOULD be used. An + example of this name type is the Kerberos ticket-granting service + whose name has a first component of krbtgt and a second component + identifying the realm for which the ticket is valid. + + + + +March 2003 [Page 98] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + If the first component of a name identifies a service and there is a + single component following the service name identifying the instance + as the host on which the server is running, then the name type SRV- + HST SHOULD be used. This type is typically used for Internet services + such as telnet and the Berkeley R commands. If the separate + components of the host name appear as successive components following + the name of the service, then the name type SRV-XHST SHOULD be used. + This type might be used to identify servers on hosts with X.500 names + where the slash (/) might otherwise be ambiguous. + + A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an + X.509 certificate is translated into a Kerberos name. The encoding of + the X.509 name as a Kerberos principal shall conform to the encoding + rules specified in RFC 2253. + + A name type of SMTP allows a name to be of a form that resembles a + SMTP email name. This name, including an "@" and a domain name, is + used as the one component of the principal name. + + A name type of UNKNOWN SHOULD be used when the form of the name is + not known. When comparing names, a name of type UNKNOWN will match + principals authenticated with names of any type. A principal + authenticated with a name of type UNKNOWN, however, will only match + other names of type UNKNOWN. + + Names of any type with an initial component of 'krbtgt' are reserved + for the Kerberos ticket granting service. See section 7.5.8 for the + form of such names. + +6.2.1. Name of server principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST if the + host name is an Internet domain name or a multi-component name of + type NT-SRV-XHST if the name of the host is of a form such as X.500 + that allows slash (/) separators. The first component of the two- or + multi-component name will identify the service and the latter + components will identify the host. Where the name of the host is not + case sensitive (for example, with Internet domain names) the name of + the host MUST be lower case. If specified by the application protocol + for services such as telnet and the Berkeley R commands which run + with system privileges, the first component MAY be the string 'host' + instead of a service specific identifier. When a host has an official + name and one or more aliases and the official name can be reliably + determined, the official name of the host SHOULD be used when + constructing the name of the server principal. + + + + +March 2003 [Page 99] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +7. Constants and other defined values + +7.1. Host address types + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned + type fields and interpretations. + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded + in MSB order. The IPv4 loopback address SHOULD NOT appear in a + Kerberos packet. The type of IPv4 addresses is two (2). + + Internet (IPv6) Addresses + + IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, + encoded in MSB order. The type of IPv6 addresses is twenty-four + (24). The following addresses MUST NOT appear in any Kerberos + packet: + + * the Unspecified Address + * the Loopback Address + * Link-Local addresses + + IPv4-mapped IPv6 addresses MUST be represented as addresses of + type 2. + + DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB + order. The type of DECnet Phase IV addresses is twelve (12). + + Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 + to 15 alphanumeric characters and padded with the US-ASCII SPC + character (code 32). The 16th octet MUST be the US-ASCII NUL + character (code 0). The type of Netbios addresses is twenty (20). + + Directional Addresses + + In many environments, including the sender address in KRB_SAFE and + KRB_PRIV messages is undesirable because the addresses may be + changed in transport by network address translators. However, if + these addresses are removed, the messages may be subject to a + reflection attack in which a message is reflected back to its + originator. The directional address type provides a way to avoid + + + +March 2003 [Page 100] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + transport addresses and reflection attacks. Directional addresses + are encoded as four byte unsigned integers in network byte order. + If the message is originated by the party sending the original + KRB_AP_REQ message, then an address of 0 SHOULD be used. If the + message is originated by the party to whom that KRB_AP_REQ was + sent, then the address 1 SHOULD be used. Applications involving + multiple parties can specify the use of other addresses. + + Directional addresses MUST only be used for the sender address + field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used + as a ticket address or in a KRB_AP_REQ message. This address type + SHOULD only be used in situations where the sending party knows + that the receiving party supports the address type. This generally + means that directional addresses may only be used when the + application protocol requires their support. Directional addresses + are type (3). + +7.2. KDC messaging - IP Transports + + Kerberos defines two IP transport mechanisms for communication + between clients and servers: UDP/IP and TCP/IP. + +7.2.1. UDP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept UDP + requests and SHOULD listen for such requests on port 88 (decimal) + unless specifically configured to listen on an alternative UDP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Kerberos clients supporting IP transports SHOULD support the sending + of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify + the IP address and port to which they will send their request. + + When contacting a KDC for a KRB_KDC_REQ request using UDP/IP + transport, the client shall send a UDP datagram containing only an + encoding of the request to the KDC. The KDC will respond with a reply + datagram containing only an encoding of the reply message (either a + KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP + address. The response to a request made through UDP/IP transport MUST + also use UDP/IP transport. If the response can not be handled using + UDP (for example because it is too large), the KDC MUST return + KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request + using the TCP transport. + +7.2.2. TCP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept TCP + + + +March 2003 [Page 101] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + requests and SHOULD listen for such requests on port 88 (decimal) + unless specifically configured to listen on an alternate TCP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Clients MUST support the sending of TCP requests, but MAY choose to + intially try a request using the UDP transport. Clients SHOULD use + KDC discovery [7.2.3] to identify the IP address and port to which + they will send their request. + + Implementation note: Some extensions to the Kerberos protocol will + not succeed if any client or KDC not supporting the TCP transport is + involved. Implementations of RFC 1510 were not required to support + TCP/IP transports. + + When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, + the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to + the client on the same TCP stream that was established for the + request. The KDC MAY close the TCP stream after sending a response, + but MAY leave the stream open for a reasonable period of time if it + expects a followup. Care must be taken in managing TCP/IP connections + on the KDC to prevent denial of service attacks based on the number + of open TCP/IP connections. + + The client MUST be prepared to have the stream closed by the KDC at + anytime after the receipt of a response. A stream closure SHOULD NOT + be treated as a fatal error. Instead, if multiple exchanges are + required (e.g., certain forms of pre-authentication) the client may + need to establish a new connection when it is ready to send + subsequent messages. A client MAY close the stream after receiving a + response, and SHOULD close the stream if it does not expect to send + followup messages. + + A client MAY send multiple requests before receiving responses, + though it must be prepared to handle the connection being closed + after the first response. + + Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) + sent over the TCP stream is preceded by the length of the request as + 4 octets in network byte order. The high bit of the length is + reserved for future expansion and MUST currently be set to zero. + + If multiple requests are sent over a single TCP connection, and the + KDC sends multiple responses, the KDC is not required to send the + responses in the order of the corresponding requests. This may permit + some implementations to send each response as soon as it is ready + even if earlier requests are still being processed (for example, + waiting for a response from an external device or database). + + + +March 2003 [Page 102] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + +7.2.3. KDC Discovery on IP Networks + + Kerberos client implementations MUST provide a means for the client + to determine the location of the Kerberos Key Distribution Centers + (KDCs). Traditionally, Kerberos implementations have stored such + configuration information in a file on each client machine. + Experience has shown this method of storing configuration information + presents problems with out-of-date information and scaling problems, + especially when using cross-realm authentication. This section + describes a method for using the Domain Name System [RFC 1035] for + storing KDC location information. + +7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. While it is strongly + encouraged that all realm names be all upper case this recommendation + has not been adopted by all sites. Some sites use all lower case + names and other use mixed case. DNS on the other hand is case + insensitive for queries. Since "MYREALM", "myrealm", and "MyRealm" + are all different it is necessary that only one of the possible + combinations of upper and lower case characters be used. This + restriction may be lifted in the future as the DNS naming scheme is + expanded to support non-US-ASCII names. + +7.2.3.2. Specifying KDC Location information with DNS SRV records + + KDC location information is to be stored using the DNS SRV RR [RFC + 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "_kerberos". + + The Proto can be one of "_udp", "_tcp". If these SRV records are to + be used, both "_udp" and "_tcp" records MUST be specified for all KDC + deployments. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, and Target have the standard + meaning as defined in RFC 2052. + + As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV + records SHOULD be the value assigned to "kerberos" by the Internet + Assigned Number Authority: 88 (decimal) unless the KDC is configured + to listen on an alternate TCP port. + + Implementation note: Many existing client implementations do not + + + +March 2003 [Page 103] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + support KDC Discovery and are configured to send requests to the IANA + assigned port (88 decimal), so it is strongly recommended that KDCs + be configured to listen on that port. + +7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks + + These are DNS records for a Kerberos realm EXAMPLE.COM. It has two + Kerberos servers, kdc1.example.com and kdc2.example.com. Queries + should be directed to kdc1.example.com first as per the specified + priority. Weights are not used in these sample records. + + _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + +7.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: (1) the realm of the KDC issuing the TGS + ticket (2) a two-part name of type NT-SRV-INST, with the first part + "krbtgt" and the second part the name of the realm which will accept + the ticket-granting ticket. For example, a ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting + ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets + from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "MIT.EDU") (name). + +7.4. OID arc for KerberosV5 + + This OID MAY be used to identify Kerberos protocol messages + encapsulated in other protocols. It also designates the OID arc for + KerberosV5-related OIDs assigned by future IETF action. + Implementation note:: RFC 1510 had an incorrect value (5) for "dod" + in its OID. + + id-krb5 OBJECT IDENTIFIER ::= { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) + } + + Assignment of OIDs beneath the id-krb5 arc must be obtained by + contacting krb5-oid-registrar@mit.edu. + +7.5. Protocol constants and associated values + + + + +March 2003 [Page 104] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + The following tables list constants used in the protocol and define + their meanings. Ranges are specified in the "specification" section + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementation + receiving values outside the range specified in the "specification" + section MAY reject the request, but they MUST recover cleanly. + +7.5.1. Key usage numbers + + The encryption and checksum specifications in [@KCRYPTO] require as + input a "key usage number", to alter the encryption key used in any + specific message, to make certain types of cryptographic attack more + difficult. These are the key usage values assigned in this document: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted + with the client key (section 5.2.7.2) + 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session + key or application session key), encrypted with the + service key (section 5.3) + 3. AS-REP encrypted part (includes TGS session key or + application session key), encrypted with the client key + (section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with + the TGS session key (section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with + the TGS authenticator subkey (section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, + keyed with the TGS session key (sections 5.5.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator + (includes TGS authenticator subkey), encrypted with the + TGS session key (section 5.5.1) + 8. TGS-REP encrypted part (includes application session + key), encrypted with the TGS session key (section + 5.4.2) + 9. TGS-REP encrypted part (includes application session + key), encrypted with the TGS authenticator subkey + (section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application + session key (section 5.5.1) + 11. AP-REQ Authenticator (includes application + authenticator subkey), encrypted with the application + session key (section 5.5.1) + 12. AP-REP encrypted part (includes application session + subkey), encrypted with the application session key + (section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by + the application (section 5.7.1) + + + +March 2003 [Page 105] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + 14. KRB-CRED encrypted part, encrypted with a key chosen by + the application (section 5.8.1) + 15. KRB-SAFE cksum, keyed with a key chosen by the + application (section 5.6.1) + 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) + 22-24. Reserved for use in GSSAPI mechanisms derived from RFC + 1964. (raeburn/MIT) + 16-18,20-21,25-511. Reserved for future use in Kerberos and related + protocols. + 512-1023. Reserved for uses internal to a Kerberos + implementation. + 1024. Encryption for application use in protocols that + do not specify key usage values + 1025. Checksums for application use in protocols that + do not specify key usage values + 1026-2047. Reserved for application use. + + +7.5.2. PreAuthentication Data Types + + padata and data types padata-type value comment + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + [reserved] 4 + PA-ENC-UNIX-TIME 5 (deprecated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ 14 (pkinit) + PA-PK-AS-REP 15 (pkinit) + PA-ETYPE-INFO2 19 (replaces pa-etype-info) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) + TD-PADATA 22 (embeds padata) + PA-SAM-ETYPE-INFO 23 (sam/otp) + PA-ALT-PRINC 24 (crawdad@fnal.gov) + PA-SAM-CHALLENGE2 30 (kenh@pobox.com) + PA-SAM-RESPONSE2 31 (kenh@pobox.com) + PA-EXTRA-TGT 41 Reserved extra TGT + TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS + + + +March 2003 [Page 106] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + TD-KRB-PRINCIPAL 102 PrincipalName + TD-KRB-REALM 103 Realm + TD-TRUSTED-CERTIFIERS 104 from PKINIT + TD-CERTIFICATE-INDEX 105 from PKINIT + TD-APP-DEFINED-ERROR 106 application specific + TD-REQ-NONCE 107 INTEGER + TD-REQ-SEQ 108 INTEGER + PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) + +7.5.3. Address Types + + Address type value + + IPv4 2 + Directional 3 + ChaosNet 5 + XNS 6 + ISO 7 + DECNET Phase IV 12 + AppleTalk DDP 16 + NetBios 20 + IPv6 24 + +7.5.4. Authorization Data Types + + authorization data type ad-type value + AD-IF-RELEVANT 1 + AD-INTENDED-FOR-SERVER 2 + AD-INTENDED-FOR-APPLICATION-CLASS 3 + AD-KDC-ISSUED 4 + AD-AND-OR 5 + AD-MANDATORY-TICKET-EXTENSIONS 6 + AD-IN-TICKET-EXTENSIONS 7 + AD-MANDATORY-FOR-KDC 8 + reserved values 9-63 + OSF-DCE 64 + SESAME 65 + AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) + +7.5.5. Transited Encoding Types + + transited encoding type tr-type value + DOMAIN-X500-COMPRESS 1 + reserved values all others + +7.5.6. Protocol Version Number + + + + +March 2003 [Page 107] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Label Value Meaning or MIT code + + pvno 5 current Kerberos protocol version number + +7.5.7. Kerberos Message Types + + message types + + KRB_AS_REQ 10 Request for initial authentication + KRB_AS_REP 11 Response to KRB_AS_REQ request + KRB_TGS_REQ 12 Request for authentication based on TGT + KRB_TGS_REP 13 Response to KRB_TGS_REQ request + KRB_AP_REQ 14 application request to server + KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL + KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request + KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply + KRB_SAFE 20 Safe (checksummed) application message + KRB_PRIV 21 Private (encrypted) application message + KRB_CRED 22 Private (encrypted) message to forward credentials + KRB_ERROR 30 Error response + +7.5.8. Name Types + + name types + + KRB_NT_UNKNOWN 0 Name type not known + KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users + KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) + KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) + KRB_NT_SRV_XHST 4 Service with host as remaining components + KRB_NT_UID 5 Unique ID + KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com) + KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name + +7.5.9. Error Codes + + error codes + + KDC_ERR_NONE 0 No error + KDC_ERR_NAME_EXP 1 Client's entry in database has expired + KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired + KDC_ERR_BAD_PVNO 3 Requested protocol version number + not supported + KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key + KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key + KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database + KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database + + + +March 2003 [Page 108] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database + KDC_ERR_NULL_KEY 9 The client or server has a null key + KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating + KDC_ERR_NEVER_VALID 11 Requested start time is later than end time + KDC_ERR_POLICY 12 KDC policy rejects request + KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option + KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type + KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type + KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type + KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type + KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked + KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked + KDC_ERR_TGT_REVOKED 20 TGT has been revoked + KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later + KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later + KDC_ERR_KEY_EXPIRED 23 Password has expired + - change password to reset + KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid + KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired + KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match + KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only + KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path + KDC_ERR_SVC_UNAVAILABLE 29 A service is not available + KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed + KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired + KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid + KRB_AP_ERR_REPEAT 34 Request is a replay + KRB_AP_ERR_NOT_US 35 The ticket isn't for us + KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match + KRB_AP_ERR_SKEW 37 Clock skew too great + KRB_AP_ERR_BADADDR 38 Incorrect net address + KRB_AP_ERR_BADVERSION 39 Protocol version mismatch + KRB_AP_ERR_MSG_TYPE 40 Invalid msg type + KRB_AP_ERR_MODIFIED 41 Message stream modified + KRB_AP_ERR_BADORDER 42 Message out of order + KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available + KRB_AP_ERR_NOKEY 45 Service key not available + KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed + KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction + KRB_AP_ERR_METHOD 48 Alternative authentication method required + KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message + KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message + KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path + KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP + KRB_ERR_GENERIC 60 Generic error (description in e-text) + KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation + KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT + KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT + + + +March 2003 [Page 109] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT + KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT + KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT + KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER + KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC + KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT + KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT + KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT + KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT + KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT + +8. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of options. + Among these are multiple encryption and checksum types, alternative + encoding schemes for the transited field, optional mechanisms for + pre-authentication, the handling of tickets with no addresses, + options for mutual authentication, user to user authentication, + support for proxies, forwarding, postdating, and renewing tickets, + the format of realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + +8.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to + support Kerberos Version 5 Specification 2 (5.2). Specification 1 + (deprecated) may be found in RFC1510. + + Transport + + TCP/IP and UDP/IP transport MUST be supported by clients and KDCs + claiming conformance to specification 2. + + Encryption and checksum methods + + The following encryption and checksum mechanisms MUST be + supported. + + + + +March 2003 [Page 110] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Encryption: AES256-CTS-HMAC-SHA1-96 + Checksums: HMAC-SHA1-96-AES256 + + Implementations SHOULD support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them. The mechanisms that SHOULD + be supported are: + + Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD + Checksums: DES-MD5, HMAC-SHA1-DES3-KD + + Implementations MAY support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them. + + Implementation note: earlier implementations of Kerberos generate + messages using the CRC-32, RSA-MD5 checksum methods. For + interoperability with these earlier releases implementors MAY + consider supporting these checksum methods but should carefully + analyze the security impplications to limit the situations within + which these methods are accepted. + + Realm Names + + All implementations MUST understand hierarchical realms in both + the Internet Domain and the X.500 style. When a ticket-granting + ticket for an unknown realm is requested, the KDC MUST be able to + determine the names of the intermediate realms between the KDCs + realm and the requested realm. + + Transited field encoding + + DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be + supported. Alternative encodings MAY be supported, but they may + be used only when that encoding is supported by ALL intermediate + realms. + + Pre-authentication methods + + The TGS-REQ method MUST be supported. The TGS-REQ method is not + used on the initial request. The PA-ENC-TIMESTAMP method MUST be + supported by clients but whether it is enabled by default MAY be + determined on a realm by realm basis. If not used in the initial + request and the error KDC_ERR_PREAUTH_REQUIRED is returned + specifying PA-ENC-TIMESTAMP as an acceptable method, the client + SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- + authentication method. Servers need not support the PA-ENC- + TIMESTAMP method, but if not supported the server SHOULD ignore + + + +March 2003 [Page 111] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + the presence of PA-ENC-TIMESTAMP pre-authentication in a request. + + The ETYPE-INFO2 method MUST be supported; this method is used to + communicate the set of supported encryption types, and + corresponding salt and string to key paramters. The ETYPE-INFO + method SHOULD be supported for interoperability with older + implementation. + + Mutual authentication + + Mutual authentication (via the KRB_AP_REP message) MUST be + supported. + + Ticket addresses and flags + + All KDCs MUST pass through tickets that carry no addresses (i.e. + if a TGT contains no addresses, the KDC will return derivative + tickets). Implementations SHOULD default to requesting + addressless tickets as this significantly increases + interoperability with network address translation. In some cases + realms or application servers MAY require that tickets have an + address. + + Implementations SHOULD accept directional address type for the + KRB_SAFE and KRB_PRIV message and SHOULD include directional + addresses in these messages when other address types are not + available. + + Proxies and forwarded tickets MUST be supported. Individual realms + and application servers can set their own policy on when such + tickets will be accepted. + + All implementations MUST recognize renewable and postdated + tickets, but need not actually implement them. If these options + are not supported, the starttime and endtime in the ticket shall + specify a ticket's entire useful life. When a postdated ticket is + decoded by a server, all implementations shall make the presence + of the postdated flag visible to the calling server. + + User-to-user authentication + + Support for user to user authentication (via the ENC-TKT-IN-SKEY + KDC option) MUST be provided by implementations, but individual + realms MAY decide as a matter of policy to reject such requests on + a per-principal or realm-wide basis. + + Authorization data + + + + +March 2003 [Page 112] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Implementations MUST pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless directed + to suppress a subfield as part of the definition of that + registered subfield type (it is never incorrect to pass on a + subfield, and no registered subfield types presently specify + suppression at the KDC). + + Implementations MUST make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + Constant ranges + + All protocol constants are constrained to 32 bit (signed) values + unless further constrained by the protocol definition. This limit + is provided to allow implementations to make assumptions about the + maximum values that will be received for these constants. + Implementation receiving values outside this range MAY reject the + request, but they MUST recover cleanly. + +8.2. Recommended KDC values + + Following is a list of recommended values for a KDC configuration. + + minimum lifetime 5 minutes + maximum renewable lifetime 1 week + maximum ticket lifetime 1 day + acceptable clock skew 5 minutes + empty addresses Allowed. + proxiable, etc. Allowed. + +9. IANA considerations + + Section 7 of this document specifies protocol constants and other + defined values required for the interoperability of multiple + implementations. Until otherwise specified in a subsequent RFC, + allocations of additional protocol constants and other defined values + required for extensions to the Kerberos protocol will be administered + by the Kerberos Working Group. + +10. Security Considerations + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. Kerberos does not, by + itself, provide authorization. Applications should not accept the + issuance of a service ticket by the Kerberos server as granting + authority to use the service, since such applications may become + + + +March 2003 [Page 113] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + vulnerable to the bypass of this authorization check in an + environment if they inter-operate with other KDCs or where other + options for application authentication are provided. + + Denial of service attacks are not solved with Kerberos. There are + places in the protocols where an intruder can prevent an application + from participating in the proper authentication steps. Because + authentication is a required step for the use of many services, + successful denial of service attacks on a Kerberos server might + result in the denial of other network services that rely on Kerberos + for authentication. Kerberos is vulnerable to many kinds of denial of + service attacks: denial of service attacks on the network which would + prevent clients from contacting the KDC; denial of service attacks on + the domain name system which could prevent a client from finding the + IP address of the Kerberos server; and denial of service attack by + overloading the Kerberos KDC itself with repeated requests. + + Interoperability conflicts caused by incompatible character-set usage + (see 5.2.1) can result in denial of service for clients that utilize + character-sets in Kerberos strings other than those stored in the KDC + database. + + Authentication servers maintain a database of principals (i.e., users + and servers) and their secret keys. The security of the + authentication server machines is critical. The breach of security of + an authentication server will compromise the security of all servers + that rely upon the compromised KDC, and will compromise the + authentication of any principals registered in the realm of the + compromised KDC. + + Principals must keep their secret keys secret. If an intruder somehow + steals a principal's key, it will be able to masquerade as that + principal or impersonate any server to the legitimate principal. + + Password guessing attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an off-line dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained which are encrypted under a key derived from the + user's password. + + Unless pre-authentication options are required by the policy of a + realm, the KDC will not know whether a request for authentication + succeeds. An attacker can request a reply with credentials for any + principal. These credentials will likely not be of much use to the + attacker unless it knows the client's secret key, but the + availability of the response encrypted in the client's secret key + provides the attacker with ciphertext that may be used to mount brute + + + +March 2003 [Page 114] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + force or dictionary attacks to decrypt the credentials, by guessing + the user's password. For this reason it is strongly encouraged that + Kerberos realms require the use of pre-authentication. Even with pre- + authentication, attackers may try brute force or dictionary attacks + against credentials that are observed by eavesdropping on the + network. + + Because a client can request a ticket for any server principal and + can attempt a brute force or dictionary attack against the server + principal's key using that ticket, it is strongly encouraged that + keys be randomly generated (rather than generated from passwords) for + any principals that are usable as the target principal for a + KRB_TGS_REQ or KRB_AS_REQ messages. + + Each host on the network must have a clock which is loosely + synchronized to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on a + per-server basis, but is typically on the order of 5 minutes. If the + clocks are synchronized over the network, the clock synchronization + protocol must itself be secured from network attackers. + + Principal identifiers must not recycled on a short-term basis. A + typical mode of access control will use access control lists (ACLs) + to grant permissions to particular principals. If a stale ACL entry + remains for a deleted principal and the principal identifier is + reused, the new principal will inherit rights specified in the stale + ACL entry. By not reusing principal identifiers, the danger of + inadvertent access is removed. + + Proper decryption of an KRB_AS_REP message from the KDC is not + sufficient for the host to verify the identity of the user; the user + and an attacker could cooperate to generate a KRB_AS_REP format + message which decrypts properly but is not from the proper KDC. To + authenticate a user logging on to a local system, the credentials + obtained in the AS exchange may first be used in a TGS exchange to + obtain credentials for a local server. Those credentials must then be + verified by a local server through successful completion of the + Client/Server exchange. + + Kerberos credentials contain clear-text information identifying the + principals to which they apply. If privacy of this information is + needed, this exchange should itself be encapsulated in a protocol + providing for confidentiality on the exchange of these credentials. + + Applications must take care to protect communications subsequent to + authentication either by using the KRB_PRIV or KRB_SAFE messages as + appropriate, or by applying their own confidentiality or integrity + + + +March 2003 [Page 115] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + mechanisms on such communications. Completion of the KRB_AP_REQ and + KRB_AP_REP exchange without subsequent use of confidentiality and + integrity mechanisms provides only for authentication of the parties + to the communication and not confidentiality and integrity of the + subsequent communication. Application applying confidentiality and + protections mechanisms other than KRB_PRIV and KRB_SAFE must make + sure that the authentication step is appropriately linked with the + protected communication channel that is established by the + application. + + Unless the application server provides its own suitable means to + protect against replay (for example, a challenge-response sequence + initiated by the server after authentication, or use of a server- + generated encryption subkey), the server must utilize a replay cache + to remember any authenticator presented within the allowable clock + skew. All services sharing a key need to use the same replay cache. + If separate replay caches are used, then and authenticator used with + one such service could later be replayed to a different service with + the same service principal. + + If a server loses track of authenticators presented within the + allowable clock skew, it must reject all requests until the clock + skew interval has passed, providing assurance that any lost or + replayed authenticators will fall outside the allowable clock skew + and can no longer be successfully replayed. + + Implementations of Kerberos should not use untrusted directory + servers to determine the realm of a host. To allow such would allow + the compromise of the directory server to enable an attacker to + direct the client to accept authentication with the wrong principal + (i.e. one with a similar name, but in a realm with which the + legitimate host was not registered). + + Implementations of Kerberos must not use DNS to canonicalize the host + components of service principal names. To allow such canonicalization + would allow a compromise of the DNS to result in a client obtaining + credentials and correctly authenticating to the wrong principal. + Though the client will know who it is communicating with, it will not + be the principal with which it intended to communicate. + + If the Kerberos server returns a TGT for a 'closer' realm other than + the desired realm, the client may use local policy configuration to + verify that the authentication path used is an acceptable one. + Alternatively, a client may choose its own authentication path, + rather than relying on the Kerberos server to select one. In either + case, any policy or configuration information used to choose or + validate authentication paths, whether by the Kerberos server or + client, must be obtained from a trusted source. + + + +March 2003 [Page 116] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + The Kerberos protocol in its basic form does not provide perfect + forward secrecy for communications. If traffic has been recorded by + an eavesdropper, then messages encrypted using the KRB_PRIV message, + or messages encrypted using application specific encryption under + keys exchanged using Kerberos can be decrypted if any of the user's, + application server's, or KDC's key is subsequently discovered. This + is because the session key use to encrypt such messages is + transmitted over the network encrypted in the key of the application + server, and also encrypted under the session key from the user's + ticket-granting ticket when returned to the user in the KRB_TGS_REP + message. The session key from the ticket-granting ticket was sent to + the user in the KRB_AS_REP message encrypted in the user's secret + key, and embedded in the ticket-granting ticket, which was encrypted + in the key of the KDC. Application requiring perfect forward secrecy + must exchange keys through mechanisms that provide such assurance, + but may use Kerberos for authentication of the encrypted channel + established through such other means. + +11. Author's Addresses + + + Clifford Neuman + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, CA 90292, USA + Email: bcn@isi.edu + + Tom Yu + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + Email: tlyu@mit.edu + + Sam Hartman + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + Email: hartmans@mit.edu + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139, USA + Email: raeburn@MIT.EDU + + +12. Acknowledgements + + + +March 2003 [Page 117] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + This document is a revision to RFC1510 which was co-authored with + John Kohl. The specification of the Kerberos protocol described in + this document is the result of many years of effort. Over this + period many individuals have contributed to the definition of the + protocol and to the writing of the specification. Unfortunately it is + not possible to list all contributors as authors of this document, + though there are many not listed who are authors in spirit, because + they contributed text for parts of some sections, because they + contributed to the design of parts of the protocol, or because they + contributed significantly to the discussion of the protocol in the + IETF common authentication technology (CAT) and Kerberos working + groups. + + Among those contributing to the development and specification of + Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan + Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, + Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, + Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome + Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, + Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar + Westerlund, and Nicolas Williams. Many other members of MIT Project + Athena, the MIT networking group, and the Kerberos and CAT working + groups of the IETF contributed but are not listed. + +13. REFERENCES + + [@KRYPTO] + RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- + crypto. + + [@AES] + RFC-Editor: To be replaced by RFC number for draft-raeburn0krb- + rijndael-krb. + + [DGT96] + Don Davis, Daniel Geer, and Theodore Ts'0, "Kerberos With Clocks + Adrift: History, Protocols, and Implementation", USENIX Computing + Systems 9:1 (Januart 1996). + + [DS81] + Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key + Distribution Protocols," Communications of the ACM, Vol. 24(8), + pp. 533-536 (August 1981). + + [ISO-646/ECMA-6] + 7-bit Coded Character Set + + [ISO-2022/ECMA-35] + + + +March 2003 [Page 118] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Character Code Structure and Extension Techniques + + [ISO-4873/ECMA-43] + 8-bit Coded Character Set Structure and Rules + + [KNT94] + + John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The + Evolution of the Kerberos Authentication System". In Distributed + Open Systems, pages 78-94. IEEE Computer Society Press, 1994. + + [MNSS87] + S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, + Section E.2.1: Kerberos Authentication and Authorization System, + M.I.T. Project Athena, Cambridge, Massachusetts (December 21, + 1987). + + [Neu93] + B. Clifford Neuman, "Proxy-Based Authorization and Accounting for + Distributed Systems," in Proceedings of the 13th International + Conference on Distributed Computing Systems, Pittsburgh, PA (May, + 1993). + + [NS78] + Roger M. Needham and Michael D. Schroeder, "Using Encryption for + Authentication in Large Networks of Computers," Communications of + the ACM, Vol. 21(12), pp. 993-999 (December, 1978). + + [NT94] + B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication + Service for Computer Networks," IEEE Communications Magazine, Vol. + 32(9), pp. 33-38 (September 1994). + + [Pat92]. + J. Pato, Using Pre-Authentication to Avoid Password Guessing + Attacks, Open Software Foundation DCE Request for Comments 26 + (December 1992). + + [RFC1035] + P.V. Mockapetris, RFC1035: "Domain Names - Implementations and + Specification," November 1, 1987, Obsoletes - RFC973, RFC882, + RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982, + RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, + RFC2535, RFC2845, and RFC3425. Status: Standard. + + [RFC1510] + J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network + Authentication Service (v5)," September 1993, Status: Proposed + + + +March 2003 [Page 119] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + Standard. + + [RFC2026] + S. Bradner, RFC2026: "The Internet Standard Process - Revision + 3," October 1996, Obsoletes - RFC 1602, Status: Best Current + Practice. + + [RFC2052] + A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying the + Location of Services (DNS SRV)," October 1996, Obseleted by + RFC2782, Status: Experimental + + [RFC2253] + M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory + Access Protocol (v3): UTF-8 String Representation or Distinguished + Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377, + Status: Proposed Standard. + + [RFC2273] + D. Levi, P. Meyer, and B. Stewart, RFC2273: "SNMPv3 Applications," + January 1998, Obsoletes - RFC2263, Obsoleted by RFC2573, Status: + Proposed Standard. + + [RFC2373] + R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing + Architecture," July 1998, Status: Proposed Standard. + + [SNS88] + J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An + Authentication Service for Open Network Systems," pp. 191-202 in + Usenix Conference Proceedings, Dallas, Texas (February, 1988). + + [X680] + Abstract Syntax Notation One (ASN.1): Specification of Basic + Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC + International Standard 8824-1:1998. + + [X690] + ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished Encoding Rules + (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International + Standard 8825-1:1998. + +A. ASN.1 module + + KerberosV5Spec2 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec2(2) + + + +March 2003 [Page 120] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + -- OID arc for KerberosV5 + -- + -- This OID may be used to identify Kerberos protocol messages + -- encapsulated in other protocols. + -- + -- This OID also designates the OID arc for KerberosV5-related OIDs. + -- + -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. + id-krb5 OBJECT IDENTIFIER ::= { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) + } + + Int32 ::= INTEGER (-2147483648..2147483647) + -- signed values representable in 32 bits + + UInt32 ::= INTEGER (0..4294967295) + -- unsigned 32 bit values + + Microseconds ::= INTEGER (0..999999) + -- microseconds + + KerberosString ::= GeneralString (IA5String) + + Realm ::= KerberosString + + PrincipalName ::= SEQUENCE { + name-type [0] Int32, + name-string [1] SEQUENCE OF KerberosString + } + + KerberosTime ::= GeneralizedTime -- with no fractional seconds + + HostAddress ::= SEQUENCE { + addr-type [0] Int32, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be empty. + HostAddresses -- NOTE: subtly different from rfc1510, + -- but has a value mapping and encodes the same + ::= SEQUENCE OF HostAddress + + -- NOTE: AuthorizationData is always used as an OPTIONAL field and + -- should not be empty. + + + +March 2003 [Page 121] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] Int32, + ad-data [1] OCTET STRING + } + + PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] Int32, + padata-value [2] OCTET STRING -- might be encoded AP-REQ + } + + KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits + -- shall be sent, but no fewer than 32 + + EncryptedData ::= SEQUENCE { + etype [0] Int32 -- EncryptionType --, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING -- ciphertext + } + + EncryptionKey ::= SEQUENCE { + keytype [0] Int32 -- actually encryption type --, + keyvalue [1] OCTET STRING + } + + Checksum ::= SEQUENCE { + cksumtype [0] Int32, + checksum [1] OCTET STRING + } + + Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] Realm, + sname [2] PrincipalName, + enc-part [3] EncryptedData -- EncTicketPart + } + + -- Encrypted part of ticket + EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] Realm, + cname [3] PrincipalName, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + + + +March 2003 [Page 122] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL + } + + -- encoded Transited field + TransitedEncoding ::= SEQUENCE { + tr-type [0] Int32 -- must be registered --, + contents [1] OCTET STRING + } + + TicketFlags ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- the following are new since 1510 + -- transited-policy-checked(12), + -- ok-as-delegate(13) + + AS-REQ ::= [APPLICATION 10] KDC-REQ + + TGS-REQ ::= [APPLICATION 12] KDC-REQ + + KDC-REQ ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5) , + msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), + padata [3] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + req-body [4] KDC-REQ-BODY + } + + KDC-REQ-BODY ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + realm [2] Realm + -- Server's realm + -- Also client's in AS-REQ --, + sname [3] PrincipalName OPTIONAL, + + + +March 2003 [Page 123] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime, + rtime [6] KerberosTime OPTIONAL, + nonce [7] UInt32, + etype [8] SEQUENCE OF Int32 -- EncryptionType + -- in preference order --, + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData -- AuthorizationData --, + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty + } + + KDCOptions ::= KerberosFlags + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + -- unused7(7), + -- renewable(8), + -- unused9(9), + -- unused10(10), + -- opt-hardware-auth(11), + -- unused12(12), + -- unused13(13), + -- 15 is reserved for canonicalize + -- unused15(15), + -- 26 was unused in 1510 + -- disable-transited-check(26), + -- + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + + AS-REP ::= [APPLICATION 11] KDC-REP + + TGS-REP ::= [APPLICATION 13] KDC-REP + + KDC-REP ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), + padata [2] SEQUENCE OF PA-DATA OPTIONAL + -- NOTE: not empty --, + crealm [3] Realm, + cname [4] PrincipalName, + + + +March 2003 [Page 124] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + ticket [5] Ticket, + enc-part [6] EncryptedData + -- EncASRepPart or EncTGSRepPart, + -- as appropriate + } + + EncASRepPart ::= [APPLICATION 25] EncKDCRepPart + + EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + + EncKDCRepPart ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] UInt32, + key-expiration [3] KerberosTime OPTIONAL, + flags [4] TicketFlags, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + srealm [9] Realm, + sname [10] PrincipalName, + caddr [11] HostAddresses OPTIONAL + } + + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type [0] Int32, + lr-value [1] KerberosTime + } + + AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData -- Authenticator + } + + APOptions ::= KerberosFlags + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + + -- Unencrypted authenticator + Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] Realm, + cname [2] PrincipalName, + + + +March 2003 [Page 125] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + cksum [3] Checksum OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] UInt32 OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL + } + + AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15), + enc-part [2] EncryptedData -- EncAPRepPart + } + + EncAPRepPart ::= [APPLICATION 27] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] UInt32 OPTIONAL + } + + KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (20), + safe-body [2] KRB-SAFE-BODY, + cksum [3] Checksum + } + + KRB-SAFE-BODY ::= SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL + } + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + -- NOTE: there is no [2] tag + enc-part [3] EncryptedData -- EncKrbPrivPart + } + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + + + +March 2003 [Page 126] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + seq-number [3] UInt32 OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr + } + + KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData -- EncKrbCredPart + } + + EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] UInt32 OPTIONAL, + timestamp [2] KerberosTime OPTIONAL, + usec [3] Microseconds OPTIONAL, + s-address [4] HostAddress OPTIONAL, + r-address [5] HostAddress OPTIONAL + } + + KrbCredInfo ::= SEQUENCE { + key [0] EncryptionKey, + prealm [1] Realm OPTIONAL, + pname [2] PrincipalName OPTIONAL, + flags [3] TicketFlags OPTIONAL, + authtime [4] KerberosTime OPTIONAL, + starttime [5] KerberosTime OPTIONAL, + endtime [6] KerberosTime OPTIONAL, + renew-till [7] KerberosTime OPTIONAL, + srealm [8] Realm OPTIONAL, + sname [9] PrincipalName OPTIONAL, + caddr [10] HostAddresses OPTIONAL + } + + KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] Int32, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- service realm --, + sname [10] PrincipalName -- service name --, + e-text [11] KerberosString OPTIONAL, + + + +March 2003 [Page 127] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + e-data [12] OCTET STRING OPTIONAL + } + + METHOD-DATA ::= SEQUENCE OF PA-DATA + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING OPTIONAL + } + + -- preauth stuff follows + + PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL + } + + ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] OCTET STRING OPTIONAL + } + + ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + + ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] Int32, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL + } + + ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY + + AD-IF-RELEVANT ::= AuthorizationData + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] Checksum, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + AD-AND-OR ::= SEQUENCE { + condition-count [0] INTEGER, + elements [1] AuthorizationData + } + + + + +March 2003 [Page 128] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + END + +B. Changes since RFC-1510 + + This document replaces RFC-1510 and clarifies specification of items + that were not completely specified. Where changes to recommended + implementation choices were made, or where new options were added, + those changes are described within the document and listed in this + section. More significantly, "Specification 2" in section 8 changes + the required encryption and checksum methods to bring them in line + with the best current practices and to deprecate methods that are no + longer considered sufficiently strong. + + Discussion was added to section 1 regarding the ability to rely on + the KDC to check the transited field, and on the inclusion of a flag + in a ticket indicating that this check has occurred. This is a new + capability not present in RFC1510. Pre-existing implementations may + ignore or not set this flag without negative security implications. + + The definition of the secret key says that in the case of a user the + key may be derived from a password. In 1510, it said that the key was + derived from the password. This change was made to accommodate + situations where the user key might be stored on a smart-card, or + otherwise obtained independent of a password. + + The introduction mentions the use of public key cryptography for + initial authentication in Kerberos by reference. RFC1510 did not + include such a reference. + + Section 1.2 was added to explain that while Kerberos provides + authentication of a named principal, it is still the responsibility + of the application to ensure that the authenticated name is the + entity with which the application wishes to communicate. + + Discussion of extensibility has been added to the introduction. + + Discussion of how extensibility affects ticket flags and KDC options + was added to the introduction of section 2. No changes were made to + existing options and flags specified in RFC1510, though some of the + sections in the specification were renumbered, and text was revised + to make the description and intent of existing options clearer, + especially with respect to the ENC-TKT-IN-SKEY option (now section + 2.9.2) which is used for user-to-user authentication. The new option + and ticket flag transited policy checking (section 2.7) was added. + + A warning regarding generation of session keys for application use + + + +March 2003 [Page 129] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + was added to section 3, urging the inclusion of key entropy from the + KDC generated session key in the ticket. An example regarding use of + the sub-session key was added to section 3.2.6. Descriptions of the + pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data + items were added. The recommendation for use of pre-authentication + was changed from "may" to "should" and a note was added regarding + known plaintext attacks. + + In RFC 1510, section 4 described the database in the KDC. This + discussion was not necessary for interoperability and unnecessarily + constrained implementation. The old section 4 was removed. + + The current section 4 was formerly section 6 on encryption and + checksum specifications. The major part of this section was brought + up to date to support new encryption methods, and move to a separate + document. Those few remaining aspects of the encryption and checksum + specification specific to Kerberos are now specified in section 4. + + Significant changes were made to the layout of section 5 to clarify + the correct behavior for optional fields. Many of these changes were + made necessary because of improper ASN.1 description in the original + Kerberos specification which left the correct behavior + underspecified. Additionally, the wording in this section was + tightened wherever possible to ensure that implementations conforming + to this specification will be extensible with the addition of new + fields in future specifications. + + Text was added describing time_t=0 issues in the ASN.1. Text was also + added, clarifying issues with implementations treating omitted + optional integers as zero. Text was added clarifying behavior for + optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was + added regarding sequence numbers and behavior of some + implementations, including "zero" behavior and negative numbers. A + compatibility note was added regarding the unconditional sending of + EncTGSRepPart regardless of the enclosing reply type. Minor changes + were made to the description of the HostAddresses type. Integer types + were constrained. KerberosString was defined as a (significantly) + constrained GeneralString. KerberosFlags was defined to reflect + existing implementation behavior that departs from the definition in + RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13) + ticket flags were added. The disable-transited-check(26) KDC option + was added. + + Descriptions of commonly implemented PA-DATA were added to section 5. + The description of KRB-SAFE has been updated to note the existing + implementation behavior of double-encoding. + + There were two definitions of METHOD-DATA in RFC 1510. The second + + + +March 2003 [Page 130] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + one, intended for use with KRB_AP_ERR_METHOD was removed leaving the + SEQUENCE OF PA-DATA definition. + + Section 7, naming constraints, from RFC1510 was moved to section 6. + + Words were added describing the convention that domain based realm + names for newly created realms should be specified as upper case. + This recommendation does not make lower case realm names illegal. + Words were added highlighting that the slash separated components in + the X500 style of realm names is consistent with existing RFC1510 + based implementations, but that it conflicts with the general + recommendation of X.500 name representation specified in RFC2253. + + Section 8, network transport, constants and defined values, from + RFC1510 was moved to section 7. Since RFC1510, the definition of the + TCP transport for Kerberos messages was added, and the encryption and + checksum number assignments have been moved into a separate document. + + "Specification 2" in section 8 of the current document changes the + required encryption and checksum methods to bring them in line with + the best current practices and to deprecate methods that are no + longer considered sufficiently strong. + + Two new sections, on IANA considerations and security considerations + were added. + + The pseudo-code has been removed from the appendix. The pseudo-code + was sometimes misinterpreted to limit implementation choices and in + RFC 1510, it was not always consistent with the words in the + specification. Effort was made to clear up any ambiguities in the + specification, rather than to rely on the pseudo-code. + + An appendix was added containing the complete ASN.1 module drawn from + the discussion in section 5 of the current document. + + An appendix was added defining those authorization data elements that + must be understood by all Kerberos implementations. + +END NOTES + + [TM] Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). No commercial use of + these trademarks may be made without prior written permission of MIT. + + [1] Note, however, that many applications use Kerberos' functions + only upon the initiation of a stream-based network connection. Unless + an application subsequently provides integrity protection for the + data stream, the identity verification applies only to the initiation + + + +March 2003 [Page 131] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + of the connection, and does not guarantee that subsequent messages on + the connection originate from the same principal. + + [2] Secret and private are often used interchangeably in the + literature. In our usage, it takes two (or more) to share a secret, + thus a shared DES key is a secret key. Something is only private when + no one but its owner knows it. Thus, in public key cryptosystems, one + has a public and a private key. + + [3] Of course, with appropriate permission the client could arrange + registration of a separately-named principal in a remote realm, and + engage in normal exchanges with that realm's services. However, for + even small numbers of clients this becomes cumbersome, and more + automatic methods as described here are necessary. + + [4] Though it is permissible to request or issue tickets with no + network addresses specified. + + [5] The password-changing request must not be honored unless the + requester can provide the old password (the user's current secret + key). Otherwise, it would be possible for someone to walk up to an + unattended session and change another user's password. + + [6] To authenticate a user logging on to a local system, the + credentials obtained in the AS exchange may first be used in a TGS + exchange to obtain credentials for a local server. Those credentials + must then be verified by a local server through successful completion + of the Client/Server exchange. + + [7] "Random" means that, among other things, it should be impossible + to guess the next session key based on knowledge of past session + keys. This can only be achieved in a pseudo-random number generator + if it is based on cryptographic principles. It is more desirable to + use a truly random number generator, such as one based on + measurements of random physical phenomena. + + [8] Tickets contain both an encrypted and unencrypted portion, so + cleartext here refers to the entire unit, which can be copied from + one message and replayed in another without any cryptographic skill. + + [9] Note that this can make applications based on unreliable + transports difficult to code correctly. If the transport might + deliver duplicated messages, either a new authenticator must be + generated for each retry, or the application server must match + requests and replies and replay the first reply in response to a + detected duplicate. + + [10] Note also that the rejection here is restricted to + + + +March 2003 [Page 132] + + + + + +Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT + + + authenticators from the same principal to the same server. Other + client principals communicating with the same server principal should + not be have their authenticators rejected if the time and microsecond + fields happen to match some other client's authenticator. + + [11] If this is not done, an attacker could subvert the + authentication by recording the ticket and authenticator sent over + the network to a server and replaying them following an event that + caused the server to lose track of recently seen authenticators. + + [12] In the Kerberos version 4 protocol, the timestamp in the reply + was the client's timestamp plus one. This is not necessary in version + 5 because version 5 messages are formatted in such a way that it is + not possible to create the reply by judicious message surgery (even + in encrypted form) without knowledge of the appropriate encryption + keys. + + [13] Note that for encrypting the KRB_AP_REP message, the sub-session + key is not used, even if present in the Authenticator. + + [14] Implementations of the protocol may provide routines to choose + subkeys based on session keys and random numbers and to generate a + negotiated key to be returned in the KRB_AP_REP message. + + [15]This can be accomplished in several ways. It might be known + beforehand (since the realm is part of the principal identifier), it + might be stored in a nameserver, or it might be obtained from a + configuration file. If the realm to be used is obtained from a + nameserver, there is a danger of being spoofed if the nameservice + providing the realm name is not authenticated. This might result in + the use of a realm which has been compromised, and would result in an + attacker's ability to compromise the authentication of the + application server to the client. + + [16] If the client selects a sub-session key, care must be taken to + ensure the randomness of the selected sub-session key. One approach + would be to generate a random number and XOR it with the session key + from the ticket-granting ticket. + + + + + + + + + + + + + +March 2003 [Page 133] + diff --git a/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt b/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt new file mode 100644 index 000000000..70395f2ba --- /dev/null +++ b/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt @@ -0,0 +1,674 @@ + + + + + + + + + +Kerberos Working Group K. Raeburn +Document: draft-raeburn-krb-rijndael-krb-03.txt MIT + February 24, 2003 + expires August 24, 2003 + + AES Encryption for Kerberos 5 + +Abstract + + Recently the US National Institute of Standards and Technology chose + a new Advanced Encryption Standard [AES], which is significantly + faster and (it is believed) more secure than the old DES algorithm. + This document is a specification for the addition of this algorithm + to the Kerberos cryptosystem suite [KCRYPTO]. + + Comments should be sent to the author, or to the IETF Kerberos + working group (ietf-krb-wg@anl.gov). + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts + are working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be updated, + replaced, or obsoleted by other documents at any time. It is + inappropriate to use Internet-Drafts as reference material or to cite + them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Introduction + + This document defines encryption key and checksum types for Kerberos + 5 using the AES algorithm recently chosen by NIST. These new types + support 128-bit block encryption, and key sizes of 128 or 256 bits. + + Using the "simplified profile" of [KCRYPTO], we can define a pair of + encryption and checksum schemes. AES is used with cipher text + stealing to avoid message expansion, and SHA-1 [SHA1] is the + + + +Raeburn [Page 1] + +INTERNET DRAFT February 2003 + + + associated checksum function. + +2. Conventions Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +3. Protocol Key Representation + + The profile in [KCRYPTO] treats keys and random octet strings as + conceptually different. But since the AES key space is dense, we can + use any bit string of appropriate length as a key. We use the byte + representation for the key described in [AES], where the first bit of + the bit string is the high bit of the first byte of the byte string + (octet string) representation. + +4. Key Generation From Pass Phrases or Random Data + + Given the above format for keys, we can generate keys from the + appropriate amounts of random data (128 or 256 bits) by simply + copying the input string. + + To generate an encryption key from a pass phrase and salt string, we + use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters + indicated below, to generate an intermediate key (of the same length + as the desired final key), which is then passed into the DK function + with the 8-octet ASCII string "kerberos" as is done for des3-cbc- + hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function + produces a "random octet string", hence the application of the + random-to-key function even though it's effectively a simple identity + operation.) The resulting key is the user's long-term key for use + with the encryption algorithm in question. + + tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) + key = DK(tkey, "kerberos") + + The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the + passphrase and salt, as described in Appendix B.1 to PKCS#5. + + The number of iterations is specified by the string-to-key parameters + supplied. The parameter string is four octets indicating an unsigned + number in big-endian order. This is the number of iterations to be + performed. If the value is 00 00 00 00, the number of iterations to + be performed is 4294967296 (2**32). (Thus the minimum expressable + iteration count is 1.) + + For environments where slower hardware is the norm, implementations + + + +Raeburn [Page 2] + +INTERNET DRAFT February 2003 + + + may wish to limit the number of iterations to prevent a spoofed + response from consuming lots of client-side CPU time; it is + recommended that this bound be no less than 50000. Even for + environments with fast hardware, 4 billion iterations is likely to + take a fairly long time; much larger bounds might still be enforced, + and it might be wise for implementations to permit interruption of + this operation by the user if the environment allows for it. + + If the string-to-key parameters are not supplied, the default value + to be used is 00 00 b0 00 (decimal 45056, indicating 45056 + iterations, which takes slightly under 1 second on a 300MHz Pentium + II in tests run by the author). + + Sample test vectors are given in the appendix. + +5. Cipher Text Stealing + + Cipher block chaining is used to encrypt messages. Unlike previous + Kerberos cryptosystems, we use cipher text stealing to handle the + possibly partial final block of the message. + + Cipher text stealing is described on pages 195-196 of [AC], and + section 8 of [RC5]; it has the advantage that no message expansion is + done during encryption of messages of arbitrary sizes as is typically + done in CBC mode with padding. + + Cipher text stealing, as defined in [RC5], assumes that more than one + block of plain text is available. If exactly one block is to be + encrypted, that block is simply encrypted with AES (also known as ECB + mode). Input of less than one block is padded at the end to one + block; the values of the padding bits are unspecified. + (Implementations may use all-zero padding, but protocols should not + rely on the result being deterministic. Implementations may use + random padding, but protocols should not rely on the result not being + deterministic. Note that in most cases, the Kerberos encryption + profile will add a random confounder independent of this padding.) + + For consistency, cipher text stealing is always used for the last two + blocks of the data to be encrypted, as in [RC5]. If the data length + is a multiple of the block size, this is equivalent to plain CBC mode + with the last two cipher text blocks swapped. + + A test vector is given in the appendix. + + + + + + + + +Raeburn [Page 3] + +INTERNET DRAFT February 2003 + + +6. Kerberos Algorithm Profile Parameters + + This is a summary of the parameters to be used with the simplified + algorithm profile described in [KCRYPTO]: + + +--------------------------------------------------------------------+ + | protocol key format 128- or 256-bit string | + | | + | string-to-key function PBKDF2+DK with variable | + | iteration count (see | + | above) | + | | + | default string-to-key parameters 00 00 b0 00 | + | | + | key-generation seed length key size | + | | + | random-to-key function identity function | + | | + | hash function, H SHA-1 | + | | + | HMAC output size, h 12 octets (96 bits) | + | | + | message block size, m 1 octet | + | | + | encryption/decryption functions, AES in CBC-CTS mode with | + | E and D zero ivec (cipher block | + | size 16 octets) | + +--------------------------------------------------------------------+ + + Using this profile with each key size gives us two each of encryption + and checksum algorithm definitions. + +7. Assigned Numbers + + The following encryption type numbers are assigned: + + +--------------------------------------------------------------------+ + | encryption types | + +--------------------------------------------------------------------+ + | type name etype value key size | + +--------------------------------------------------------------------+ + | aes128-cts-hmac-sha1-96 17 128 | + | aes256-cts-hmac-sha1-96 18 256 | + +--------------------------------------------------------------------+ + + The following checksum type numbers are assigned: + + + + + +Raeburn [Page 4] + +INTERNET DRAFT February 2003 + + + +--------------------------------------------------------------------+ + | checksum types | + +--------------------------------------------------------------------+ + | type name sumtype value length | + +--------------------------------------------------------------------+ + | hmac-sha1-96-aes128 15 96 | + | hmac-sha1-96-aes256 16 96 | + +--------------------------------------------------------------------+ + + These checksum types will be used with the corresponding encryption + types defined above. + +8. Security Considerations + + This new algorithm has not been around long enough to receive the + decades of intense analysis that DES has received. It is possible + that some weakness exists that has not been found by the + cryptographers analyzing these algorithms before and during the AES + selection process. + + The use of the HMAC function has drawbacks for certain pass phrase + lengths. For example, a pass phrase longer than the hash function + block size (64 bytes, for SHA-1) is hashed to a smaller size (20 + bytes) before applying the main HMAC algorithm. However, entropy is + generally sparse in pass phrases, especially in long ones, so this + may not be a problem in the rare cases of users with long pass + phrases. + + Also, generating a 256-bit key from a pass phrase of any length may + be deceptive, since the effective entropy in pass-phrase-derived key + cannot be nearly that large. + + The iteration count in PBKDF2 appears to be useful primarily as a + constant multiplier for the amount of work required for an attacker + using brute-force methods. Unfortunately, it also multiplies, by the + same amount, the work needed by a legitimate user with a valid + password. Thus the work factor imposed on an attacker (who may have + many powerful workstations at his disposal) must be balanced against + the work factor imposed on the legitimate user (who may have a PDA or + cell phone); the available computing power on either side increases + as time goes on, as well. A better way to deal with the brute-force + attack is through preauthentication mechanisms that provide better + protection of, the user's long-term key. Use of such mechanisms is + out of scope for this document. + + If the PBKDF2 iteration count can be spoofed by an intruder on the + network, and the limit on the accepted iteration count is very high, + the intruder may be able to introduce a form of denial of service + + + +Raeburn [Page 5] + +INTERNET DRAFT February 2003 + + + attack against the client by sending a very high iteration count, + causing the client to spend a great deal of CPU time computing an + incorrect key. + + Any benefit against other attacks specific to the HMAC or SHA-1 + algorithms is probably achieved with a fairly small number of + iterations. + + Cipher text stealing mode, since it requires no additional padding in + most cases, will reveal the exact length of each message being + encrypted, rather than merely bounding it to a small range of + possible lengths as in CBC mode. Such obfuscation should not be + relied upon at higher levels in any case; if the length must be + obscured from an outside observer, it should be done by intentionally + varying the length of the message to be encrypted. + + The author is not a cryptographer. Caveat emptor. + +9. IANA Considerations + + None. + +10. Acknowledgements + + Thanks to John Brezak, Gerardo Diaz Cuellar and Marcus Watts for + feedback on earlier versions of this document. + +11. Normative References + + [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley + and Sons, New York, 1996. + + [AES] National Institute of Standards and Technology, U.S. Department + of Commerce, "Advanced Encryption Standard", Federal Information + Processing Standards Publication 197, Washington, DC, November 2001. + + [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002. Work in + progress. + + [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification Version 2.0", RFC 2898, September 2000. + + [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and + RC5-CTS Algorithms", RFC 2040, October 1996. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", RFC 2026, October 1996. + + + +Raeburn [Page 6] + +INTERNET DRAFT February 2003 + + + [SHA1] National Institute of Standards and Technology, U.S. + Department of Commerce, "Secure Hash Standard", Federal Information + Processing Standards Publication 180-1, Washington, DC, April 1995. + +12. Informative References + + [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, + December 2001. + +13. Author's Address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + raeburn@mit.edu + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +A. Sample test vectors + + Sample values for the string-to-key function are included below. + + + +Raeburn [Page 7] + +INTERNET DRAFT February 2003 + + + Iteration count = 1 + Pass phrase = "password" + Salt = "ATHENA.MIT.EDUraeburn" + 128-bit PBKDF2 output: + cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 + 128-bit AES key: + 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 + 256-bit PBKDF2 output: + cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 + 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 + 256-bit AES key: + fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b + bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61 + + Iteration count = 2 + Pass phrase = "password" + Salt="ATHENA.MIT.EDUraeburn" + 128-bit PBKDF2 output: + 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d + 128-bit AES key: + c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 + 256-bit PBKDF2 output: + 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d + a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 + 256-bit AES key: + a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 + 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff + + Iteration count = 1200 + Pass phrase = "password" + Salt = "ATHENA.MIT.EDUraeburn" + 128-bit PBKDF2 output: + 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b + 128-bit AES key: + 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a + 256-bit PBKDF2 output: + 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b + a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 + 256-bit AES key: + 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 + 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a + + + + + + + + + + +Raeburn [Page 8] + +INTERNET DRAFT February 2003 + + + Iteration count = 5 + Pass phrase = "password" + Salt=0x1234567878563412 + 128-bit PBKDF2 output: + d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 + 128-bit AES key: + e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e + 256-bit PBKDF2 output: + d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 + 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee + 256-bit AES key: + 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c + ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 + (This test is based on values given in [PECMS].) + + Iteration count = 1200 + Pass phrase = (64 characters) + "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" + Salt="pass phrase equals block size" + 128-bit PBKDF2 output: + 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 + 128-bit AES key: + 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed + 256-bit PBKDF2 output: + 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 + c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 + 256-bit AES key: + 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 + 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34 + + Iteration count = 1200 + Pass phrase = (65 characters) + "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" + Salt = "pass phrase exceeds block size" + 128-bit PBKDF2 output: + 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 + 128-bit AES key: + cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d + 256-bit PBKDF2 output: + 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 + 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a + 256-bit AES key: + d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 + 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b + + + + + + + +Raeburn [Page 9] + +INTERNET DRAFT February 2003 + + + Iteration count = 50 + Pass phrase = g-clef (0xf09d849e) + Salt = "EXAMPLE.COMpianist" + 128-bit PBKDF2 output: + 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 + 128-bit AES key: + f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 + 256-bit PBKDF2 output: + 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 + e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 + 256-bit AES key: + 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c + 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e + + Some test vectors for CBC with cipher text stealing, using an initial + vector of all-zero. + + AES 128-bit key: + 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 + + Input: + 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 20 + Output: + c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f + 97 + + Input: + 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 + Output: + fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 + 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 + + Input: + 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + Output: + 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + + + + + + + + + + + +Raeburn [Page 10] + +INTERNET DRAFT February 2003 + + + Input: + 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c + Output: + 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e + 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 + + Input: + 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 + Output: + 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 + 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + + Input: + 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 + 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 + 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 + 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e + Output: + 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 + 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 + 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 + 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 + +Document History (delete before RFC publication) + + Major changes from -02 to -03: + + Describe encryption of data of one block or less. + + Fix default string-to-key parameters in table to agree with text. + + Remove Recommendations section; the Kerberos RFC will cover + recommendations and requirements. + + Restore change history, added notes to RFC editor saying to remove + it, and update the [KCRYPTO] entry in Normative References. + + Delete confounder size, since it's gone from the simplified profile + in crypto-03. + + Change checksum numbers, since Assar Westerlund says 10 is in use. + + + + +Raeburn [Page 11] + +INTERNET DRAFT February 2003 + + + Add Security Consideration about denial of service caused by very + high spoofed iteration count. + + Major changes from -01 to -02: + + Add test vectors. + + Drop 192/384-bit variants. Prevailing opinion seems to be that + 128-bit keys are good for speed, and 256-bit for paranoia, and no one + cares about the intermediate sizes. + + Update for new string-to-key params per new Kerberos crypto draft and + discussions during the IETF conferences at Salt Lake City, December, + 2001, and Minneapolis, March, 2002. + + Drop Serpent and Twofish; Rijndael is the only one people care about. + Use "AES" in preference to "Rijndael". + + Use cipher text stealing mode intead of plain CBC, and add -cts to + the algorithm names. + + Drop SHA-2, stick with SHA-1. New test cases to exercise boundary + conditions in HMAC used in string-to-key. + + Split References into Normative/Informative. + + Major changes from -00: + + Define different types based on key/hash sizes, with hash size always + twice key size. Use simplified profile of revised section 6 of + RFC1510bis. Drop "-kd" from the names. + + Use PKCS#5 instead of simple hash. Changed string-to-key vector to + use some "Appendix Z" cases also submitted for kerberos-revisions. + +Notes to RFC Editor + + Assuming this document goes through Last Call along with the Kerberos + crypto framework draft, the reference entry for [KCRYPTO] will list + the draft name, not the RFC number. This should be replaced with the + RFC info. + + The "Document History" section should be deleted, as should this one. + + + + + + + + +Raeburn [Page 12]