idnits 2.17.1 draft-ietf-krb-wg-crypto-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 222: '... other encodings MUST first be convert...' RFC 2119 keyword, line 843: '...keys; those keys SHALL NOT be used for...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 691 has weird spacing: '...unction tmp...' == Line 720 has weird spacing: '...osystem as d...' == Line 758 has weird spacing: '...osystem any...' == Line 776 has weird spacing: '...osystem any...' == Line 812 has weird spacing: '...osystem any...' == (15 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 10, 2004) is 7192 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2084 == Missing Reference: 'K' is mentioned on line 239, but not defined -- Looks like a reference, but probably isn't: '2' on line 2089 -- Looks like a reference, but probably isn't: '3' on line 2098 -- Looks like a reference, but probably isn't: '4' on line 2102 -- Looks like a reference, but probably isn't: '5' on line 2109 -- Looks like a reference, but probably isn't: '6' on line 2115 -- Looks like a reference, but probably isn't: '0' on line 962 -- Looks like a reference, but probably isn't: '7' on line 2122 -- Looks like a reference, but probably isn't: '8' on line 2131 == Missing Reference: 'RFC1851' is mentioned on line 1559, but not defined == Missing Reference: 'BCP26' is mentioned on line 1619, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESI81' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dolev91' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'KRB5-AES' ** Obsolete normative reference: RFC 1320 (ref. 'MD4-92') (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5-92') -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-kerberos-clarifications-00 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT K. Raeburn 3 Kerberos Working Group MIT 4 Document: draft-ietf-krb-wg-crypto-07.txt February 10, 2004 5 expires August 10, 2004 7 Encryption and Checksum Specifications 8 for Kerberos 5 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 14 are working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. Internet-Drafts are 17 draft documents valid for a maximum of six months and may be updated, 18 replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.html. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes a framework for defining encryption and 31 checksum mechanisms for use with the Kerberos protocol, defining an 32 abstraction layer between the Kerberos protocol and related 33 protocols, and the actual mechanisms themselves. Several mechanisms 34 are also defined in this document. Some are taken from RFC 1510, 35 modified in form to fit this new framework, and occasionally modified 36 in content when the old specification was incorrect. New mechanisms 37 are presented here as well. This document does NOT indicate which 38 mechanisms may be considered "required to implement". 40 Comments should be sent to the editor, or to the IETF Kerberos 41 working group (ietf-krb-wg@anl.gov). 43 1mTable of Contents0m 45 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 46 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 47 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 51 4. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9 52 5. Simplified profile for CBC ciphers with key derivation . . . . . 10 53 5.1. A key derivation function . . . . . . . . . . . . . . . . . . . 11 54 5.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 13 55 5.3. Cryptosystem profile based on simplified profile . . . . . . . 14 56 5.4. Checksum profiles based on simplified profile . . . . . . . . . 16 57 6. Profiles for Kerberos encryption and checksum algorithms . . . . 16 58 6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 17 59 6.2. DES-based encryption and checksum types . . . . . . . . . . . . 18 60 6.3. Triple-DES based encryption and checksum types . . . . . . . . 28 61 7. Use of Kerberos encryption outside this specification . . . . . . 30 62 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 63 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 33 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35 66 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36 67 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 68 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 69 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 39 70 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 43 71 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 44 72 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 45 73 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 45 74 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 75 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 47 76 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 48 77 Informative References . . . . . . . . . . . . . . . . . . . . . . . 49 78 Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . . 50 79 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 50 80 1. Introduction 82 The Kerberos protocols [Kerb] are designed to encrypt messages of 83 arbitrary sizes, using block encryption ciphers, or less commonly, 84 stream encryption ciphers. Encryption is used to prove the 85 identities of the network entities participating in message 86 exchanges. However, nothing in the Kerberos protocol requires any 87 specific encryption algorithm be used, as long as certain operations 88 are available in the algorithm that is used. 90 The following sections specify the encryption and checksum mechanisms 91 currently defined for Kerberos, as well as a framework for defining 92 future mechanisms. The encoding, chaining, padding and other 93 requirements for each are described. Test vectors for several 94 functions are given in appendix A. 96 2. Concepts 98 Both encryption and checksum mechanisms are defined in terms of 99 profiles, detailed in later sections. Each specifies a collection of 100 operations and attributes that must be defined for a mechanism. A 101 Kerberos encryption or checksum mechanism specification is not 102 complete if it does not define all of these operations and 103 attributes. 105 An encryption mechanism must provide for confidentiality and 106 integrity of the original plaintext. (Integrity checking may be 107 achieved by incorporating a checksum, if the encryption mode does not 108 provide an integrity check itself.) It must also provide non- 109 malleability [Bellare98, Dolev91]. Use of a random confounder 110 prepended to the plaintext is recommended. It should not be possible 111 to determine if two ciphertexts correspond to the same plaintext, 112 without knowledge of the key. 114 A checksum mechanism [1] must provide proof of the integrity of the 115 associated message, and must preserve the confidentiality of the 116 message in case it is not sent in the clear. It should be infeasible 117 to find two plaintexts which have the same checksum. It is NOT 118 required that an eavesdropper be unable to determine if two checksums 119 are for the same message; it is assumed that the messages themselves 120 will be visible to any such eavesdropper. 122 Due to advances in cryptography, it is considered unwise by some 123 cryptographers to use the same key for multiple purposes. Since keys 124 are used in performing a number of different functions in Kerberos, 125 it is desirable to use different keys for each of these purposes, 126 even though we start with a single long-term or session key. 128 We do this by enumerating the different uses of keys within Kerberos, 129 and making the "usage number" an input to the encryption or checksum 130 mechanisms; this enumeration is outside the scope of this document. 131 Later sections of this document define simplified profile templates 132 for encryption and checksum mechanisms that use a key derivation 133 function applied to a CBC mode (or similar) cipher and a checksum or 134 hash algorithm. 136 We distinguish the "base key" specified by other documents from the 137 "specific key" to be used for a particular instance of encryption or 138 checksum operations. It is expected but not required that the 139 specific key will be one or more separate keys derived from the 140 original protocol key and the key usage number. The specific key 141 should not be explicitly referenced outside of this document. The 142 typical language used in other documents should be something like, 143 "encrypt this octet string using this key and this usage number"; 144 generation of the specific key and cipher state (described in the 145 next section) are implicit. The creation of a new cipher-state 146 object, or the re-use of one from a previous encryption operation, 147 may also be explicit. 149 New protocols defined in terms of the Kerberos encryption and 150 checksum types should use their own key usage values. Key usages are 151 unsigned 32 bit integers; zero is not permitted. 153 All data is assumed to be in the form of strings of octets or 8-bit 154 bytes. Environments with other byte sizes will have to emulate this 155 behavior in order to get correct results. 157 Each algorithm is assigned an encryption type (or "etype") or 158 checksum type number, for algorithm identification within the 159 Kerberos protocol. The full list of current type number assignments 160 is given in section 8. 162 3. Encryption algorithm profile 164 An encryption mechanism profile must define the following attributes 165 and operations. The operations must be defined as functions in the 166 mathematical sense: no additional or implicit inputs (such as 167 Kerberos principal names or message sequence numbers) are permitted. 169 protocol key format 170 This describes what octet string values represent valid keys. For 171 encryption mechanisms that don't have perfectly dense key spaces, 172 this will describe the representation used for encoding keys. It 173 need not describe specific values that are not valid or desirable 174 for use; such values should be avoid by all key generation 175 routines. 177 specific key structure 178 This is not a protocol format at all, but a description of the 179 keying material derived from the chosen key and used to encrypt or 180 decrypt data or compute or verify a checksum. It may, for 181 example, be a single key, a set of keys, or a combination of the 182 original key with additional data. The authors recommend using 183 one or more keys derived from the original key via one-way key 184 derivation functions. 186 required checksum mechanism 187 This indicates a checksum mechanism that must be available when 188 this encryption mechanism is used. Since Kerberos has no built in 189 mechanism for negotiating checksum mechanisms, once an encryption 190 mechanism has been decided upon, the corresponding checksum 191 mechanism can simply be used. 193 key-generation seed length, K 194 This is the length of the random bitstring needed to generate a 195 key with the encryption scheme's random-to-key function (described 196 below). This must be a fixed value so that various techniques for 197 producing a random bitstring of a given length may be used with 198 key generation functions. 200 key generation functions 201 Keys must be generated in a number of cases, from different types 202 of inputs. All function specifications must indicate how to 203 generate keys in the proper wire format, and must avoid generation 204 of keys that significantly compromise the confidentiality of 205 encrypted data, if the cryptosystem has such. Entropy from each 206 source should be preserved as much as possible. Many of the 207 inputs, while unknown, may be at least partly predictable (e.g., a 208 password string is likely to be entirely in the ASCII subset and 209 of fairly short length in many environments; a semi-random string 210 may include timestamps); the benefit of such predictability to an 211 attacker must be minimized. 213 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) 214 This function generates a key from two UTF-8 strings and an 215 opaque octet string. One of the strings is normally the 216 principal's pass phrase, but is in general merely a secret 217 string. The other string is a "salt" string intended to 218 produce different keys from the same password for different 219 users or realms. While the strings provided will use UTF-8 220 encoding, no specific version of Unicode should be assumed; all 221 valid UTF-8 strings should be allowed. Strings provided in 222 other encodings MUST first be converted to UTF-8 before 223 applying this function. 225 The third argument, the octet string, may be used to pass 226 mechanism-specific parameters in to this function. Since doing 227 so implies knowledge of the specific encryption system, it is 228 intended that generating non-default parameter values be an 229 uncommon operation, and that normal Kerberos applications be 230 able to treat this parameter block as an opaque object supplied 231 by the Key Distribution Center or defaulted to some mechanism- 232 specific constant value. 234 The string-to-key function should be a one-way function, so 235 that compromising a user's key in one realm does not compromise 236 the user's key in another realm, even if the same password (but 237 a different salt) is used. 239 random-to-key (bitstring[K])->(protocol-key) 240 This function generates a key from a random bitstring of a 241 specific size. It may be assumed that all the bits of the 242 input string are equally random, even though the entropy 243 present in the random source may be limited. 245 key-derivation (protocol-key, integer)->(specific-key) 246 In this function, the integer input is the key usage value as 247 described above; the usage values must be assumed to be known 248 to an attacker. The specific-key output value was described in 249 section 2. 251 string-to-key parameter format 252 This describes the format of the block of data that can be passed 253 to the string-to-key function above to configure additional 254 parameters for that function. Along with the mechanism of 255 encoding parameter values, bounds on the allowed parameters should 256 also be described to avoid allowing a spoofed KDC to compromise 257 the user's password. It may be desirable to construct the 258 encoding such that values weakening the resulting key unacceptably 259 cannot be encoded, if practical. 261 Tighter bounds might be permitted by local security policy, or to 262 avoid excess resource consumption; if so, recommended defaults for 263 those bounds should be given in the specification. The 264 description should also outline possible weaknesses that may be 265 caused by not applying bounds checks or other validation to a 266 parameter string received from the network. 268 As mentioned above, this should be considered opaque to most 269 normal applications. 271 default string-to-key parameters (octet string) 272 This default value for the "params" argument to the string-to-key 273 function is to be used when the application protocol (Kerberos or 274 otherwise) does not explicitly set the parameter value. As 275 indicated above, this parameter block should be treated as an 276 opaque object in most cases. 278 cipher state 279 This describes any information that can be carried over from one 280 encryption or decryption operation to the next, for use in 281 conjunction with a given specific key. For example, a block 282 cipher used in CBC mode may put an initial vector of one block in 283 the cipher state. Other encryption modes may track nonces or 284 other data. 286 This state must be non-empty, and must influence encryption so as 287 to require that messages be decrypted in the same order they were 288 encrypted, if the cipher state is carried over from one encryption 289 to the next. Distinguishing out-of-order or missing messages from 290 corrupted messages is not required; if desired, this can be done 291 at a higher level by including sequence numbers and not "chaining" 292 the cipher state between encryption operations. 294 The cipher state may not be reused in multiple encryption or 295 decryption operations; these operations all generate a new cipher 296 state that may be used for following operations using the same key 297 and operation. 299 The contents of the cipher state must be treated as opaque outside 300 of encryption system specifications. 302 initial cipher state (specific-key, direction)->(state) 303 This describes the generation of the initial value for the cipher 304 state if it is not being carried over from a previous encryption 305 or decryption operation. 307 This describes any initial state setup needed before encrypting 308 arbitrary amounts of data with a given specific key; the specific 309 key and the direction of operations to be performed (encrypt 310 versus decrypt) must be the only input needed for this 311 initialization. 313 This state should be treated as opaque in any uses outside of an 314 encryption algorithm definition. 316 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what 317 degree an application protocol could exercise control over the 318 initial vector used in DES CBC operations. Some existing 319 implementations permit the setting of the initial vector. This 320 framework does not provide for application control of the cipher 321 state (beyond "initialize" and "carry over from previous 322 encryption"), since the form and content of the initial cipher 323 state can vary between encryption systems, and may not always be a 324 single block of random data. 326 New Kerberos application protocols should not assume that they can 327 control the initial vector, or that one even exists. However, a 328 general-purpose implementation may wish to provide the capability, 329 in case applications explicitly setting it are encountered. 331 encrypt (specific-key, state, octet string)->(state, octet string) 332 This function takes the specific key, cipher state, and a non- 333 empty plaintext string as input, and generates ciphertext and a 334 new cipher state as outputs. If the basic encryption algorithm 335 itself does not provide for integrity protection (as DES in CBC 336 mode does not do), then some form of MAC or checksum must be 337 included that can be verified by the receiver. Some random factor 338 such as a confounder should be included so that an observer cannot 339 know if two messages contain the same plaintext, even if the 340 cipher state and specific keys are the same. The exact length of 341 the plaintext need not be encoded, but if it is not and if padding 342 is required, the padding must be added at the end of the string so 343 that the decrypted version may be parsed from the beginning. 345 The specification of the encryption function must not only 346 indicate the precise contents of the output octet string, but also 347 the output cipher state. The application protocol may carry 348 forward the output cipher state from one encryption with a given 349 specific key to another; the effect of this "chaining" must be 350 defined. [2] 352 Assuming correctly-produced values for the specific key and cipher 353 state, no input octet string may result in an error indication. 355 decrypt (specific-key, state, octet string)->(state, octet string) 356 This function takes the specific key, cipher state, and ciphertext 357 as inputs, and verifies the integrity of the supplied ciphertext. 358 If the ciphertext's integrity is intact, this function produces 359 the plaintext and a new cipher state as outputs; otherwise, an 360 error indication must be returned, and the data discarded. 362 The result of the decryption may be longer than the original 363 plaintext, for example if the encryption mode adds padding to 364 reach a multiple of a block size. If this is the case, any extra 365 octets must be after the decoded plaintext. An application 366 protocol which needs to know the exact length of the message must 367 encode a length or recognizable "end of message" marker within the 368 plaintext. [3] 370 As with the encryption function, a correct specification for this 371 function must indicate not only the contents of the output octet 372 string, but also the resulting cipher state. 374 pseudo-random (protocol-key, octet-string)->(octet-string) 375 This pseudo-random function should generate an octet string of 376 some size that independent of the octet string input. The PRF 377 output string should be suitable for use in key generation, even 378 if the octet string input is public. It should not reveal the 379 input key, even if the output is made public. 381 These operations and attributes are all that is required to support 382 Kerberos and various proposed preauthentication schemes. 384 For convenience of certain application protocols that may wish to use 385 the encryption profile, we add the constraint that, for any given 386 plaintext input size, there must be a message size between that given 387 size and that size plus 65535 such that the length of such that the 388 decrypted version of the ciphertext for any message of that size will 389 never have extra octets added at the end. 391 Expressed mathematically, for every message length L1, there exists a 392 message size L2 such that: 394 L2 >= L1 395 L2 < L1 + 65536 396 for every message M with |M| = L2, decrypt(encrypt(M)) = M 398 A document defining a new encryption type should also describe known 399 weaknesses or attacks, so that its security may be fairly assessed, 400 and should include test vectors or other validation procedures for 401 the operations defined. Specific references to information readily 402 available elsewhere are sufficient. 404 4. Checksum algorithm profile 406 A checksum mechanism profile must define the following attributes and 407 operations: 409 associated encryption algorithm(s) 410 This indicates the types of encryption keys this checksum 411 mechanism can be used with. 413 A keyed checksum mechanism may have more than one associated 414 encryption algorithm if they share the same wire key format, 415 string-to-key function, and key derivation function. (This 416 combination means that, for example, a checksum type, key usage 417 value and password are adequate to get the specific key used to 418 compute a checksum.) 420 An unkeyed checksum mechanism can be used in conjunction with any 421 encryption type, since the key is ignored, but its use must be 422 limited to cases where the checksum itself is protected, to avoid 423 trivial attacks. 425 get_mic function 426 This function generates a MIC token for a given specific key (see 427 section 3), and message (represented as an octet string), that may 428 be used to verify the integrity of the associated message. This 429 function is not required to return the same deterministic result 430 on every use; it need only generate a token that the verify_mic 431 routine can check. 433 The output of this function will also dictate the size of the 434 checksum. It must be no larger than 65535 octets. 436 verify_mic function 437 Given a specific key, message, and MIC token, this function 438 ascertains whether the message integrity has been compromised. 439 For a deterministic get_mic routine, the corresponding verify_mic 440 may simply generate another checksum and compare them. 442 The get_mic and verify_mic operations must be able to handle inputs 443 of arbitrary length; if any padding is needed, the padding scheme 444 must be specified as part of these functions. 446 These operations and attributes are all that should be required to 447 support Kerberos and various proposed preauthentication schemes. 449 As with encryption mechanism definition documents, documents defining 450 new checksum mechanisms should indicate validation processes and 451 known weaknesses. 453 5. Simplified profile for CBC ciphers with key derivation 455 The profile outlines in sections 3 and 4 describes a large number of 456 operations that must be defined for encryption and checksum 457 algorithms to be used with Kerberos. We describe here a simpler 458 profile from which both encryption and checksum mechanism definitions 459 can be generated, filling in uses of key derivation in appropriate 460 places, providing integrity protection, and defining multiple 461 operations for the cryptosystem profile based on a smaller set of 462 operations given in the simplified profile. Not all of the existing 463 cryptosystems for Kerberos fit into this simplified profile, but we 464 recommend that future cryptosystems use it or something based on it. 465 [4] 467 Not all of the operations in the complete profiles are defined 468 through this mechanism; several must still be defined for each new 469 algorithm pair. 471 5.1. A key derivation function 473 Rather than define some scheme by which a "protocol key" is composed 474 of a large number of encryption keys, we use keys derived from a base 475 key to perform cryptographic operations. The base key must be used 476 only for generating the derived keys, and this derivation must be 477 non-invertible and entropy-preserving. Given these restrictions, 478 compromise of one derived key does not compromise the other subkeys. 479 Attack of the base key is limited, since it is only used for 480 derivation, and is not exposed to any user data. 482 Since the derived key has as much entropy as the base keys (if the 483 cryptosystem is good), password-derived keys have the full benefit of 484 all the entropy in the password. 486 To generate a derived key from a base key, we generate a pseudorandom 487 octet string, using an algorithm DR described below, and generate a 488 key from that octet string using a function dependent on the 489 encryption algorithm; the input length needed for that function, 490 which is also dependent on the encryption algorithm, dictates the 491 length of the string to be generated by the DR algorithm (the value 492 "k" below). These procedures are based on the key derivation in 493 [Blumenthal96]. 495 Derived Key = DK(Base Key, Well-Known Constant) 497 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 499 DR(Key, Constant) = k-truncate(E(Key, Constant, 500 initial-cipher-state)) 502 Here DR is the random-octet generation function described below, and 503 DK is the key-derivation function produced from it. In this 504 construction, E(Key, Plaintext, CipherState) is a cipher, Constant is 505 a well-known constant determined by the specific usage of this 506 function, and k-truncate truncates its argument by taking the first k 507 bits. Here, k is the key generation seed length needed for the 508 encryption system. 510 The output of the DR function is a string of bits; the actual key is 511 produced by applying the cryptosystem's random-to-key operation on 512 this bitstring. 514 If the Constant is smaller than the cipher block size of E, then it 515 must be expanded with n-fold() so it can be encrypted. If the output 516 of E is shorter than k bits it is fed back into the encryption as 517 many times as necessary. The construct is as follows (where | 518 indicates concatentation): 520 K1 = E(Key, n-fold(Constant), initial-cipher-state) 521 K2 = E(Key, K1, initial-cipher-state) 522 K3 = E(Key, K2, initial-cipher-state) 523 K4 = ... 525 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 527 n-fold is an algorithm which takes m input bits and ``stretches'' 528 them to form n output bits with equal contribution from each input 529 bit to the output, as described in [Blumenthal96]: 531 We first define a primitive called n-folding, which takes a 532 variable-length input block and produces a fixed-length output 533 sequence. The intent is to give each input bit approximately 534 equal weight in determining the value of each output bit. Note 535 that whenever we need to treat a string of octets as a number, the 536 assumed representation is Big-Endian -- Most Significant Byte 537 first. 539 To n-fold a number X, replicate the input value to a length that 540 is the least common multiple of n and the length of X. Before 541 each repetition, the input is rotated to the right by 13 bit 542 positions. The successive n-bit chunks are added together using 543 1's-complement addition (that is, with end-around carry) to yield 544 a n-bit result.... 546 Test vectors for n-fold are supplied in Appendix A. [5] 548 In this section, n-fold is always used to produce c bits of output, 549 where c is the cipher block size of E. 551 The size of the Constant must not be larger than c, because reducing 552 the length of the Constant by n-folding can cause collisions. 554 If the size of the Constant is smaller than c, then the Constant must 555 be n-folded to length c. This string is used as input to E. If the 556 block size of E is less than the random-to-key input size, then the 557 output from E is taken as input to a second invocation of E. This 558 process is repeated until the number of bits accumulated is greater 559 than or equal to the random-to-key input size. When enough bits have 560 been computed, the first k are taken as the random data used to 561 create the key with the algorithm-dependent random-to-key function. 563 Since the derived key is the result of one or more encryptions in the 564 base key, deriving the base key from the derived key is equivalent to 565 determining the key from a very small number of plaintext/ciphertext 566 pairs. Thus, this construction is as strong as the cryptosystem 567 itself. 569 5.2. Simplified profile parameters 571 These are the operations and attributes that must be defined: 573 protocol key format 574 string-to-key function 575 default string-to-key parameters 576 key-generation seed length, k 577 random-to-key function 578 As above for the normal encryption mechanism profile. 580 unkeyed hash algorithm, H 581 This should be a collision-resistant hash algorithm with fixed- 582 size output, suitable for use in an HMAC [HMAC]. It must support 583 inputs of arbitrary length. Its output must be at least the 584 message block size (below). 586 HMAC output size, h 587 This indicates the size of the leading substring output by the 588 HMAC function that should be used in transmitted messages. It 589 should be at least half the output size of the hash function H, 590 and at least 80 bits; it need not match the output size. 592 message block size, m 593 This is the size of the smallest units the cipher can handle in 594 the mode in which it is being used. Messages will be padded to a 595 multiple of this size. If a block cipher is used in a mode that 596 can handle messages that are not multiples of the cipher block 597 size, such as CBC mode with cipher text stealing (CTS, see [RC5]), 598 this value would be one octet. For traditional CBC mode with 599 padding, it will be the underlying cipher's block size. 601 This value must be a multiple of 8 bits (one octet). 603 encryption/decryption functions, E and D 604 These are basic encryption and decryption functions for messages 605 of sizes that are multiples of the message block size. No 606 integrity checking or confounder should be included here. These 607 functions take as input the IV or similar data, a protocol-format 608 key, and a octet string, returning a new IV and octet string. 610 The encryption function is not required to use CBC mode, but is 611 assumed to be using something with similar properties. In 612 particular, prepending a cipher-block-size confounder to the 613 plaintext should alter the entire ciphertext (comparable to 614 choosing and including a random initial vector for CBC mode). 616 The result of encrypting one cipher block (of size c, above) must 617 be deterministic, for the random octet generation function DR in 618 the previous section to work. For best security, it should also 619 be no larger than c. 621 cipher block size, c 622 This is the block size of the block cipher underlying the 623 encryption and decryption functions indicated above, used for key 624 derivation and for the size of the message confounder and initial 625 vector. (If a block cipher is not in use, some comparable 626 parameter should be determined.) It must be at least 5 octets. 628 This is not actually an independent parameter; rather, it is a 629 property of the functions E and D. It is listed here to clarify 630 the distinction between it and the message block size, m. 632 While there are still a number of properties to specify, they are 633 fewer and simpler than in the full profile. 635 5.3. Cryptosystem profile based on simplified profile 637 The above key derivation function is used to produce three 638 intermediate keys. One is used for computing checksums of 639 unencrypted data. The other two are used for encrypting and 640 checksumming plaintext to be sent encrypted. 642 The ciphertext output is the concatenation of the output of the basic 643 encryption function E and a (possibly truncated) HMAC using the 644 specified hash function H, both applied to the plaintext with a 645 random confounder prefix and sufficient padding to bring it to a 646 multiple of the message block size. When the HMAC is computed, the 647 key is used in the protocol key form. 649 Decryption is performed by removing the (partial) HMAC, decrypting 650 the remainder, and verifying the HMAC. The cipher state is an 651 initial vector, initialized to zero. 653 The substring notation "[1..h]" in the following table should be read 654 as using 1-based indexing; leading substrings are used. 656 cryptosystem from simplified profile 657 ---------------------------------------------------------------------------- 658 protocol key format As given. 660 specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 662 key-generation seed As given. 663 length 665 required checksum As defined below in section 5.4. 666 mechanism 668 cipher state initial vector (usually of length c) 670 initial cipher state all bits zero 672 encryption function conf = random string of length c 673 pad = shortest string to bring confounder 674 and plaintext to a length that's a 675 multiple of m 676 (C1, newIV) = E(Ke, conf | plaintext | pad, 677 oldstate.ivec) 678 H1 = HMAC(Ki, conf | plaintext | pad) 679 ciphertext = C1 | H1[1..h] 680 newstate.ivec = newIV 682 decryption function (C1,H1) = ciphertext 683 (P1, newIV) = D(Ke, C1, oldstate.ivec) 684 if (H1 != HMAC(Ki, P1)[1..h]) 685 report error 686 newstate.ivec = newIV 688 default string-to-key As given. 689 params 691 pseudo-random function tmp1 = H(octet-string) 692 tmp2 = truncate tmp1 to multiple of m 693 PRF = E(protocol-key, tmp2, initial-cipher-state) 695 key generation functions: 697 cryptosystem from simplified profile 698 ---------------------------------------------------------------------------- 699 string-to-key function As given. 701 random-to-key function As given. 703 key-derivation function The "well-known constant" used for the DK 704 function is the key usage number, expressed as 705 four octets in big-endian order, followed by one 706 octet indicated below. 708 Kc = DK(base-key, usage | 0x99); 709 Ke = DK(base-key, usage | 0xAA); 710 Ki = DK(base-key, usage | 0x55); 712 5.4. Checksum profiles based on simplified profile 714 When an encryption system is defined using the simplified profile 715 given in section 5.2, a checksum algorithm may be defined for it as 716 follows: 718 checksum mechanism from simplified profile 719 -------------------------------------------------- 720 associated cryptosystem as defined above 722 get_mic HMAC(Kc, message)[1..h] 724 verify_mic get_mic and compare 726 The HMAC function and key Kc are as described in section 5.3. 728 6. Profiles for Kerberos encryption and checksum algorithms 730 These profiles describe the encryption and checksum systems defined 731 for Kerberos. The astute reader will notice that some of them do not 732 fulfull all of the requirements outlined in previous sections. These 733 systems are defined for backward compatibility; newer implementations 734 should (whenever possible) attempt to make use of encryption systems 735 which satisfy all of the profile requirements. 737 The full list of current encryption and checksum type number 738 assignments, including values currently reserved but not defined in 739 this document, is given in section 8. 741 6.1. Unkeyed checksums 743 These checksum types use no encryption keys, and thus can be used in 744 combination with any encryption type, but may only be used with 745 caution, in limited circumstances where the lack of a key does not 746 provide a window for an attack, preferably as part of an encrypted 747 message. [6] Keyed checksum algorithms are recommended. 749 6.1.1. The RSA MD5 Checksum 751 The RSA-MD5 checksum calculates a checksum using the RSA MD5 752 algorithm [MD5-92]. The algorithm takes as input an input message of 753 arbitrary length and produces as output a 128-bit (16 octet) 754 checksum. RSA-MD5 is believed to be collision-proof. 756 rsa-md5 757 ---------------------------------------------- 758 associated cryptosystem any 760 get_mic rsa-md5(msg) 762 verify_mic get_mic and compare 764 The rsa-md5 checksum algorithm is assigned a checksum type number of 765 seven (7). 767 6.1.2. The RSA MD4 Checksum 769 The RSA-MD4 checksum calculates a checksum using the RSA MD4 770 algorithm [MD4-92]. The algorithm takes as input an input message of 771 arbitrary length and produces as output a 128-bit (16 octet) 772 checksum. RSA-MD4 is believed to be collision-proof. 774 rsa-md4 775 ---------------------------------------------- 776 associated cryptosystem any 778 get_mic md4(msg) 780 verify_mic get_mic and compare 782 The rsa-md4 checksum algorithm is assigned a checksum type number of 783 two (2). 785 6.1.3. CRC-32 Checksum 787 This CRC-32 checksum calculates a checksum based on a cyclic 788 redundancy check as described in ISO 3309 [CRC], modified as 789 described below. The resulting checksum is four (4) octets in 790 length. The CRC-32 is neither keyed nor collision-proof; thus, the 791 use of this checksum is not recommended. An attacker using a 792 probabilistic chosen-plaintext attack as described in [SG92] might be 793 able to generate an alternative message that satisfies the checksum. 795 The CRC-32 checksum used in the des-cbc-crc encryption mode is 796 identical to the 32-bit FCS described in ISO 3309 with two 797 exceptions: the sum with the all-ones polynomial times x**k is 798 omitted, and the final remainder is not ones-complemented. ISO 3309 799 describes the FCS in terms of bits, while this document describes the 800 Kerberos protocol in terms of octets. To disambiguate the ISO 3309 801 definition for the purpose of computing the CRC-32 in the des-cbc-crc 802 encryption mode, the ordering of bits in each octet shall be assumed 803 to be LSB-first. Given this assumed ordering of bits within an 804 octet, the mapping of bits to polynomial coefficients shall be 805 identical to that specified in ISO 3309. 807 Test values for this modified CRC function are included in appendix 808 A.5. 810 crc32 811 ---------------------------------------------- 812 associated cryptosystem any 814 get_mic crc32(msg) 816 verify_mic get_mic and compare 818 The crc32 checksum algorithm is assigned a checksum type number of 819 one (1). 821 6.2. DES-based encryption and checksum types 823 These encryption systems encrypt information under the Data 824 Encryption Standard [DES77] using the cipher block chaining mode 825 [DESM80]. A checksum is computed as described below and placed in 826 the cksum field. DES blocks are 8 bytes. As a result, the data to 827 be encrypted (the concatenation of confounder, checksum, and message) 828 must be padded to an 8 byte boundary before encryption. The values 829 of the padding bytes are unspecified. 831 Plaintext and DES ciphertext are encoded as blocks of 8 octets which 832 are concatenated to make the 64-bit inputs for the DES algorithms. 833 The first octet supplies the 8 most significant bits (with the 834 octet's MSB used as the DES input block's MSB, etc.), the second 835 octet the next 8 bits, ..., and the eighth octet supplies the 8 least 836 significant bits. 838 Encryption under DES using cipher block chaining requires an 839 additional input in the form of an initialization vector; this vector 840 is specified for each encryption system, below. 842 The DES specifications [DESI81] identify four 'weak' and twelve 843 'semi-weak' keys; those keys SHALL NOT be used for encrypting 844 messages for use in Kerberos. The "variant keys" generated for the 845 RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive- 846 or of a DES key with a constant are not checked for this property. 848 A DES key is 8 octets of data. This consists of 56 bits of actual 849 key data, and 8 parity bits, one per octet. The key is encoded as a 850 series of 8 octets written in MSB-first order. The bits within the 851 key are also encoded in MSB order. For example, if the encryption 852 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 853 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 854 are the parity bits, the first octet of the key would be 855 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the 856 [DESM80] introduction for reference. 858 Encryption data format 860 The format for the data to be encrypted includes a one-block 861 confounder, a checksum, the encoded plaintext, and any necessary 862 padding, as described in the following diagram. The msg-seq field 863 contains the part of the protocol message which is to be encrypted. 865 +-----------+----------+---------+-----+ 866 |confounder | checksum | msg-seq | pad | 867 +-----------+----------+---------+-----+ 869 One generates a random confounder of one block, placing it in 870 'confounder'; zeroes out the 'checksum' field (of length appropriate 871 to exactly hold the checksum to be computed); calculates the 872 appropriate checksum over the whole sequence, placing the result in 873 'checksum'; adds the necessary padding; then encrypts using the 874 specified encryption type and the appropriate key. 876 String or random-data to key transformation 878 To generate a DES key from two UTF-8 text strings (password and 879 salt), the two strings are concatenated, password first, and the 880 result is then padded with zero-valued octets to a multiple of 8 881 octets. 883 The top bit of each octet (always zero if the password is plain 884 ASCII, as was assumed when the original specification was written) is 885 discarded, and a bitstring is formed of the remaining seven bits of 886 each octet. This bitstring is then fan-folded and eXclusive-ORed 887 with itself to produce a 56-bit string. An eight-octet key is formed 888 from this string, each octet using seven bits from the bitstring, 889 leaving the least significant bit unassigned. The key is then 890 "corrected" by correcting the parity on the key, and if the key 891 matches a 'weak' or 'semi-weak' key as described in the DES 892 specification, it is eXclusive-ORed with the constant 893 0x00000000000000F0. This key is then used to generate a DES CBC 894 checksum on the initial string with the salt appended. The result of 895 the CBC checksum is then "corrected" as described above to form the 896 result which is returned as the key. 898 For purposes of the string-to-key function, the DES CBC checksum is 899 calculated by CBC encrypting a string using the key as IV and using 900 the final 8 byte block as the checksum. 902 Pseudocode follows: 904 removeMSBits(8byteblock) { 905 /* Treats a 64 bit block as 8 octets and remove the MSB in 906 each octect (in big endian mode) and concatenates the 907 result. E.g., input octet string: 908 01110000 01100001 11110011 01110011 11110111 01101111 909 11110010 01100100 910 results in output bitstring: 911 1110000 1100001 1110011 1110011 1110111 1101111 912 1110010 1100100 */ 913 } 915 reverse(56bitblock) { 916 /* Treats a 56-bit block as a binary string and reverse it. 917 E.g., input string: 918 1000001 1010100 1001000 1000101 1001110 1000001 919 0101110 1001101 920 results in output string: 921 1011001 0111010 1000001 0111001 1010001 0001001 922 0010101 1000001 */ 923 } 924 add_parity_bits(56bitblock) { 925 /* Copies a 56-bit block into a 64-bit block, left shift 926 content in each octet and add DES parity bit. 927 E.g., input string: 928 1100000 0001111 0011100 0110100 1000101 1100100 929 0110110 0010111 930 results in output string: 931 11000001 00011111 00111000 01101000 10001010 11001000 932 01101101 00101111 */ 933 } 935 key_correction(key) { 936 fixparity(key); 937 if (is_weak_key(key)) 938 key = key XOR 0xF0; 939 return(key); 940 } 942 mit_des_string_to_key(string,salt) { 943 odd = 1; 944 s = string | salt; 945 tempstring = 0; /* 56-bit string */ 946 pad(s); /* with nulls to 8 byte boundary */ 947 for (8byteblock in s) { 948 56bitstring = removeMSBits(8byteblock); 949 if (odd == 0) reverse(56bitstring); 950 odd = ! odd; 951 tempstring = tempstring XOR 56bitstring; 952 } 953 tempkey = key_correction(add_parity_bits(tempstring)); 954 key = key_correction(DES-CBC-check(s,tempkey)); 955 return(key); 956 } 958 des_string_to_key(string,salt,params) { 959 if (length(params) == 0) 960 type = 0; 961 else if (length(params) == 1) 962 type = params[0]; 963 else 964 error("invalid params"); 965 if (type == 0) 966 mit_des_string_to_key(string,salt); 967 else 968 error("invalid params"); 969 } 971 One common extension is to support the "AFS string-to-key" algorithm, 972 which is not defined here, if the type value above is one (1). 974 For generation of a key from a random bitstring, we start with a 975 56-bit string, and as with the string-to-key operation above, insert 976 parity bits, and if the result is a weak or semi-weak key, modify it 977 by exclusive-OR with the constart 0x00000000000000F0: 979 des_random_to_key(bitstring) { 980 return key_correction(add_parity_bits(bitstring)); 981 } 983 6.2.1. DES with MD5 985 The des-cbc-md5 encryption mode encrypts information under DES in CBC 986 mode with an all-zero initial vector, with an MD5 checksum (described 987 in [MD5-92]) computed and placed in the checksum field. 989 The encryption system parameters for des-cbc-md5 are: 991 des-cbc-md5 992 -------------------------------------------------------------------- 993 protocol key format 8 bytes, parity in low bit of each 995 specific key structure copy of original key 997 required checksum rsa-md5-des 998 mechanism 1000 key-generation seed 8 bytes 1001 length 1003 cipher state 8 bytes (CBC initial vector) 1005 initial cipher state all-zero 1007 encryption function des-cbc(confounder | checksum | msg | pad, 1008 ivec=oldstate) 1009 where 1010 checksum = md5(confounder | 0000... 1011 | msg | pad) 1013 newstate = last block of des-cbc output 1015 decryption function decrypt encrypted text and verify checksum 1017 newstate = last block of ciphertext 1018 des-cbc-md5 1019 -------------------------------------------------------------------- 1020 default string-to-key empty string 1021 params 1023 pseudo-random function des-cbc(md5(input-string), ivec=0) 1025 key generation functions: 1027 string-to-key des_string_to_key 1029 random-to-key des_random_to_key 1031 key-derivation identity 1033 The des-cbc-md5 encryption type is assigned the etype value three 1034 (3). 1036 6.2.2. DES with MD4 1038 The des-cbc-md4 encryption mode also encrypts information under DES 1039 in CBC mode, with an all-zero initial vector. An MD4 checksum 1040 (described in [MD4-92]) is computed and placed in the checksum field. 1042 des-cbc-md4 1043 -------------------------------------------------------------------- 1044 protocol key format 8 bytes, parity in low bit of each 1046 specific key structure copy of original key 1048 required checksum rsa-md4-des 1049 mechanism 1051 key-generation seed 8 bytes 1052 length 1054 cipher state 8 bytes (CBC initial vector) 1056 initial cipher state all-zero 1058 encryption function des-cbc(confounder | checksum | msg | pad, 1059 ivec=oldstate) 1060 where 1061 checksum = md4(confounder | 0000... 1062 | msg | pad) 1064 newstate = last block of des-cbc output 1065 des-cbc-md4 1066 -------------------------------------------------------------------- 1068 decryption function decrypt encrypted text and verify checksum 1070 newstate = last block of ciphertext 1072 default string-to-key empty string 1073 params 1075 pseudo-random function des-cbc(md5(input-string), ivec=0) 1077 key generation functions: 1079 string-to-key des_string_to_key 1081 random-to-key copy input, then fix parity bits 1083 key-derivation identity 1085 Note that des-cbc-md4 uses md5, not md4, in the PRF definition. 1087 The des-cbc-md4 encryption algorithm is assigned the etype value two 1088 (2). 1090 6.2.3. DES with CRC 1092 The des-cbc-crc encryption type uses DES in CBC mode with the key 1093 used as the initialization vector, with a 4-octet CRC-based checksum 1094 computed as described in section 6.1.3. Note that this is not a 1095 standard CRC-32 checksum, but a slightly modified one. 1097 des-cbc-crc 1098 -------------------------------------------------------------------- 1099 protocol key format 8 bytes, parity in low bit of each 1101 specific key structure copy of original key 1103 required checksum rsa-md5-des 1104 mechanism 1106 key-generation seed 8 bytes 1107 length 1109 cipher state 8 bytes (CBC initial vector) 1110 des-cbc-crc 1111 -------------------------------------------------------------------- 1112 initial cipher state copy of original key 1114 encryption function des-cbc(confounder | checksum | msg | pad, 1115 ivec=oldstate) 1116 where 1117 checksum = crc(confounder | 00000000 1118 | msg | pad) 1120 newstate = last block of des-cbc output 1122 decryption function decrypt encrypted text and verify checksum 1124 newstate = last block of ciphertext 1126 default string-to-key empty string 1127 params 1129 pseudo-random function des-cbc(md5(input-string), ivec=0) 1131 key generation functions: 1133 string-to-key des_string_to_key 1135 random-to-key copy input, then fix parity bits 1137 key-derivation identity 1139 The des-cbc-crc encryption algorithm is assigned the etype value one 1140 (1). 1142 6.2.4. RSA MD5 Cryptographic Checksum Using DES 1144 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum 1145 by prepending an 8 octet confounder before the text, applying the RSA 1146 MD5 checksum algorithm, and encrypting the confounder and the 1147 checksum using DES in cipher-block-chaining (CBC) mode using a 1148 variant of the key, where the variant is computed by eXclusive-ORing 1149 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The 1150 initialization vector should be zero. The resulting checksum is 24 1151 octets long. This checksum is tamper-proof and believed to be 1152 collision-proof. 1154 rsa-md5-des 1155 ---------------------------------------------------------------- 1156 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1158 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1159 conf | rsa-md5(conf | msg)) 1161 verify_mic decrypt and verify rsa-md5 checksum 1163 The rsa-md5-des checksum algorithm is assigned a checksum type number 1164 of eight (8). 1166 6.2.5. RSA MD4 Cryptographic Checksum Using DES 1168 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum 1169 by prepending an 8 octet confounder before the text, applying the RSA 1170 MD4 checksum algorithm [MD4-92], and encrypting the confounder and 1171 the checksum using DES in cipher-block-chaining (CBC) mode using a 1172 variant of the key, where the variant is computed by eXclusive-ORing 1173 the key with the constant 0xF0F0F0F0F0F0F0F0. [7] The initialization 1174 vector should be zero. The resulting checksum is 24 octets long. 1175 This checksum is tamper-proof and believed to be collision-proof. 1177 rsa-md4-des 1178 ---------------------------------------------------------------- 1179 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1181 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1182 conf | rsa-md4(conf | msg), 1183 ivec=0) 1185 verify_mic decrypt and verify rsa-md4 checksum 1187 The rsa-md4-des checksum algorithm is assigned a checksum type number 1188 of three (3). 1190 6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative 1192 The RSA-MD4-DES-K checksum calculates a keyed collision-proof 1193 checksum by applying the RSA MD4 checksum algorithm and encrypting 1194 the results using DES in cipher block chaining (CBC) mode using a DES 1195 key as both key and initialization vector. The resulting checksum is 1196 16 octets long. This checksum is tamper-proof and believed to be 1197 collision-proof. Note that this checksum type is the old method for 1198 encoding the RSA-MD4-DES checksum and it is no longer recommended. 1200 rsa-md4-des-k 1201 ---------------------------------------------------------------- 1202 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1204 get_mic des-cbc(key, md4(msg), ivec=key) 1206 verify_mic decrypt, compute checksum and compare 1208 The rsa-md4-des-k checksum algorithm is assigned a checksum type 1209 number of six (6). 1211 6.2.7. DES CBC checksum 1213 The DES-MAC checksum is computed by prepending an 8 octet confounder 1214 to the plaintext, padding with zero-valued octets if necessary to 1215 bring the length to a multiple of 8 octets, performing a DES CBC-mode 1216 encryption on the result using the key and an initialization vector 1217 of zero, taking the last block of the ciphertext, prepending the same 1218 confounder and encrypting the pair using DES in cipher-block-chaining 1219 (CBC) mode using a variant of the key, where the variant is computed 1220 by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The 1221 initialization vector should be zero. The resulting checksum is 128 1222 bits (16 octets) long, 64 bits of which are redundant. This checksum 1223 is tamper-proof and collision-proof. 1225 des-mac 1226 ---------------------------------------------------------------------- 1227 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 1228 cryptosystem 1230 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1231 conf | des-mac(key, conf | msg | pad, ivec=0), 1232 ivec=0) 1234 verify_mic decrypt, compute DES MAC using confounder, compare 1236 The des-mac checksum algorithm is assigned a checksum type number of 1237 four (4). 1239 6.2.8. DES CBC checksum alternative 1241 The DES-MAC-K checksum is computed by performing a DES CBC-mode 1242 encryption of the plaintext, with zero-valued padding bytes if 1243 necessary to bring the length to a multiple of 8 octets, and using 1244 the last block of the ciphertext as the checksum value. It is keyed 1245 with an encryption key which is also used as the initialization 1246 vector. The resulting checksum is 64 bits (8 octets) long. This 1247 checksum is tamper-proof and collision-proof. Note that this 1248 checksum type is the old method for encoding the DESMAC checksum and 1249 it is no longer recommended. 1251 des-mac-k 1252 ---------------------------------------------------------------- 1253 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1255 get_mic des-mac(key, msg | pad, ivec=key) 1257 verify_mic compute MAC and compare 1259 The des-mac-k checksum algorithm is assigned a checksum type number 1260 of five (5). 1262 6.3. Triple-DES based encryption and checksum types 1264 This encryption and checksum type pair is based on the Triple DES 1265 cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message 1266 authentication algorithm. 1268 A Triple DES key is the concatenation of three DES keys as described 1269 above for des-cbc-md5. A Triple DES key is generated from random 1270 data by creating three DES keys from separate sequences of random 1271 data. 1273 Encrypted data using this type must be generated as described in 1274 section 5.3. If the length of the input data is not a multiple of 1275 the block size, zero-valued octets must be used to pad the plaintext 1276 to the next eight-octet boundary. The confounder must be eight 1277 random octets (one block). 1279 The simplified profile for Triple DES, with key derivation as defined 1280 in section 5, is as follows: 1282 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1283 ------------------------------------------------ 1284 protocol key format 24 bytes, parity in low 1285 bit of each 1287 key-generation seed 21 bytes 1288 length 1289 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1290 ------------------------------------------------ 1291 hash function SHA-1 1293 HMAC output size 160 bits 1295 message block size 8 bytes 1297 default string-to-key empty string 1298 params 1300 encryption and triple-DES encrypt and 1301 decryption functions decrypt, in outer-CBC 1302 mode (cipher block size 1303 8 octets) 1305 key generation functions: 1307 random-to-key DES3random-to-key (see 1308 below) 1310 string-to-key DES3string-to-key (see 1311 below) 1313 The des3-cbc-hmac-sha1-kd encryption type is assigned the value 1314 sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a 1315 checksum type number of twelve (12). 1317 6.3.1. Triple DES Key Production (random-to-key, string-to-key) 1319 The 168 bits of random key data are converted to a protocol key value 1320 as follows. First, the 168 bits are divided into three groups of 56 1321 bits, which are expanded individually into 64 bits as follows: 1323 DES3random-to-key: 1324 1 2 3 4 5 6 7 p 1325 9 10 11 12 13 14 15 p 1326 17 18 19 20 21 22 23 p 1327 25 26 27 28 29 30 31 p 1328 33 34 35 36 37 38 39 p 1329 41 42 43 44 45 46 47 p 1330 49 50 51 52 53 54 55 p 1331 56 48 40 32 24 16 8 p 1333 The "p" bits are parity bits computed over the data bits. The output 1334 of the three expansions, each corrected to avoid "weak" and "semi- 1335 weak" keys as in section 6.2, are concatenated to form the protocol 1336 key value. 1338 The string-to-key function is used to transform UTF-8 passwords into 1339 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 1340 algorithm and DK function, described in section 5. 1342 The n-fold algorithm is applied to the password string concatenated 1343 with a salt value. For 3-key triple DES, the operation will involve 1344 a 168-fold of the input password string, to generate an intermediate 1345 key, from which the user's long-term key will be derived with the DK 1346 function. The DES3 string-to-key function is shown here in 1347 pseudocode: 1349 DES3string-to-key(passwordString, salt, params) 1350 if (params != emptyString) 1351 error("invalid params"); 1352 s = passwordString + salt 1353 tmpKey = random-to-key(168-fold(s)) 1354 key = DK (tmpKey, KerberosConstant) 1356 Weak key checking is performed in the random-to-key and DK 1357 operations. The KerberosConstant value is the byte string {0x6b 0x65 1358 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII 1359 encoding for the string "kerberos". 1361 7. Use of Kerberos encryption outside this specification 1363 Several Kerberos-based application protocols and preauthentication 1364 systems have been designed and deployed that perform encryption and 1365 message integrity checks in various ways. While in some cases there 1366 may be good reason for specifying these protocols in terms of 1367 specific encryption or checksum algorithms, we anticipate that in 1368 many cases this will not be true, and more generic approaches 1369 independent of particular algorithms will be desirable. Rather than 1370 having each protocol designer reinvent schemes for protecting data, 1371 using multiple keys, etc, we have attempted to present in this 1372 section a general framework that should be sufficient not only for 1373 the Kerberos protocol itself but also for many preauthentication 1374 systems and application protocols, while trying to avoid some of the 1375 assumptions that can work their way into such protocol designs. 1377 Some problematic assumptions we've seen (and sometimes made) include: 1378 that a random bitstring is always valid as a key (not true for DES 1379 keys with parity); that the basic block encryption chaining mode 1380 provides no integrity checking, or can easily be separated from such 1381 checking (not true for many modes in development that do both 1382 simultaneously); that a checksum for a message always results in the 1383 same value (not true if a confounder is incorporated); that an 1384 initial vector is used (may not be true if a block cipher in CBC mode 1385 is not in use). 1387 Such assumptions, while they may hold for any given set of encryption 1388 and checksum algorithms, may not be true of the next algorithms to be 1389 defined, leaving the application protocol unable to make use of those 1390 algorithms without updates to its specification. 1392 The Kerberos protocol uses only the attributes and operations 1393 described in sections 3 and 4. Preauthentication systems and 1394 application protocols making use of Kerberos are encouraged to use 1395 them as well. The specific key and string-to-key parameters should 1396 generally be treated as opaque. While the string-to-key parameters 1397 are manipulated as an octet string, the representation for the 1398 specific key structure is implementation-defined; it may not even be 1399 a single object. 1401 While we don't recommend it, some application protocols will 1402 undoubtedly continue to use the key data directly, even if only in 1403 some of the currently existing protocol specifications. An 1404 implementation intended to support general Kerberos applications may 1405 therefore need to make the key data available, as well as the 1406 attributes and operations described in sections 3 and 4. [8] 1408 8. Assigned Numbers 1410 The following encryption type numbers are already assigned or 1411 reserved for use in Kerberos and related protocols. 1413 encryption type etype section or comment 1414 ----------------------------------------------------------------- 1415 des-cbc-crc 1 6.2.3 1416 des-cbc-md4 2 6.2.2 1417 des-cbc-md5 3 6.2.1 1418 [reserved] 4 1419 des3-cbc-md5 5 1420 [reserved] 6 1421 des3-cbc-sha1 7 1422 dsaWithSHA1-CmsOID 9 (pkinit) 1423 md5WithRSAEncryption-CmsOID 10 (pkinit) 1424 sha1WithRSAEncryption-CmsOID 11 (pkinit) 1425 rc2CBC-EnvOID 12 (pkinit) 1426 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 1427 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 1428 des-ede3-cbc-Env-OID 15 (pkinit) 1429 des3-cbc-sha1-kd 16 6.3 1430 aes128-cts-hmac-sha1-96 17 [KRB5-AES] 1431 aes256-cts-hmac-sha1-96 18 [KRB5-AES] 1432 rc4-hmac 23 (Microsoft) 1433 rc4-hmac-exp 24 (Microsoft) 1434 subkey-keymaterial 65 (opaque; PacketCable) 1436 (The "des3-cbc-sha1" assignment is a deprecated version using no key 1437 derivation. It should not be confused with des3-cbc-sha1-kd.) 1439 Several numbers have been reserved for use in encryption systems not 1440 defined here. Encryption type numbers have unfortunately been 1441 overloaded on occasion in Kerberos-related protocols, so some of the 1442 reserved numbers do not and will not correspond to encryption systems 1443 fitting the profile presented here. 1445 The following checksum type numbers are assigned or reserved. As 1446 with encryption type numbers, some overloading of checksum numbers 1447 has occurred. 1449 Checksum type sumtype checksum section or 1450 value size reference 1451 ---------------------------------------------------------------------- 1452 CRC32 1 4 6.1.3 1453 rsa-md4 2 16 6.1.2 1454 rsa-md4-des 3 24 6.2.5 1455 des-mac 4 16 6.2.7 1456 des-mac-k 5 8 6.2.8 1457 rsa-md4-des-k 6 16 6.2.6 1458 rsa-md5 7 16 6.1.1 1459 rsa-md5-des 8 24 6.2.4 1460 rsa-md5-des3 9 24 ?? 1461 sha1 (unkeyed) 10 20 ?? 1462 hmac-sha1-des3-kd 12 20 6.3 1463 hmac-sha1-des3 13 20 ?? 1464 sha1 (unkeyed) 14 20 ?? 1465 hmac-sha1-96-aes128 15 20 [KRB5-AES] 1466 hmac-sha1-96-aes256 16 20 [KRB5-AES] 1467 [reserved] 0x8003 ? [GSS-KRB5] 1469 Encryption and checksum type numbers are signed 32-bit values. Zero 1470 is invalid, and negative numbers are reserved for local use. All 1471 standardized values must be positive. 1473 9. Implementation Notes 1475 The "interface" described here is the minimal information that must 1476 be defined to make a cryptosystem useful within Kerberos in an 1477 interoperable fashion. Despite the functional notation used in some 1478 places, it is not an attempt to define an API for cryptographic 1479 functionality within Kerberos. Actual implementations providing 1480 clean APIs will probably find it useful to make additional 1481 information available, which should be possible to derive from a 1482 specification written to the framework given here. For example, an 1483 application designer may wish to determine the largest number of 1484 bytes that can be encrypted without overflowing a certain size output 1485 buffer, or conversely, the maximum number of bytes that might be 1486 obtained by decrypting a ciphertext message of a given size. (In 1487 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] 1488 will require some of these.) 1490 The presence of a mechanism in this document should not be taken as 1491 an indication that it must be implemented for compliance with any 1492 specification; required mechanisms will be specified elsewhere. 1493 Indeed, some of the mechanisms described here for backwards 1494 compatibility are now considered rather weak for protecting critical 1495 data. 1497 10. Security Considerations 1499 Recent years have brought advancements in the ability to perform 1500 large-scale attacks against DES, to such a degree that it is not 1501 considered a strong encryption mechanism any longer; triple-DES is 1502 generally preferred in its place, despite the poorer performance. 1503 See [ESP-DES] for a summary of some of the potential attacks, and 1504 [EFF-DES] for a detailed discussion of the implementation of 1505 particular attack. However, most Kerberos implementations still have 1506 DES as their primary interoperable encryption type. 1508 DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of 1509 single-DES here avoids them. However, DES also has 48 'possibly- 1510 weak' keys [Schneier96] (note that the tables in many editions of the 1511 reference contains errors) which are not avoided. 1513 DES weak keys are keys with the property that E1(E1(P)) = P (where E1 1514 denotes encryption of a single block with key 1). DES semi-weak keys 1515 or "dual" keys are pairs of keys with the property that E1(P) = 1516 D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and 1517 leading random confounder, however, these properties are unlikely to 1518 present a security problem. 1520 Many of the choices concerning when weak-key corrections are 1521 performed relate more to compatibility with existing implementations 1522 than to any risk analysis. 1524 While checks are also done for the component DES keys in a triple-DES 1525 key, the nature of the weak keys is such that it is extremely 1526 unlikely that they will weaken the triple-DES encryption -- only 1527 slightly more likely than having the middle of the three sub-keys 1528 match one of the other two, which effectively converts the encryption 1529 to single-DES, which is a case we make no effort to avoid. 1531 The true CRC-32 checksum is not collision-proof; an attacker could 1532 use a probabilistic chosen-plaintext attack to generate a valid 1533 message even if a confounder is used [SG92]. The use of collision- 1534 proof checksums is of course recommended for environments where such 1535 attacks represent a significant threat. The "simplifications" (read: 1536 bugs) introduced when CRC-32 was implemented for Kerberos cause 1537 leading zeros to effectively be ignored, so messages differing only 1538 in leading zero bits will have the same checksum. 1540 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. 1541 Unlike [IPSEC-HMAC], the triple-DES specification here does not use 1542 the suggested truncation of the HMAC output. As pointed out in 1543 [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash 1544 function, which is a criterion of HMAC. [HMAC-TEST] contains test 1545 vectors for HMAC-SHA-1. 1547 The mit_des_string_to_key function was originally constructed with 1548 the assumption that all input would be ASCII; it ignores the top bit 1549 of each input byte. Folding with XOR is also not an especially good 1550 mixing mechanism in terms of preserving randomness. 1552 The n-fold function used in the string-to-key operation for des3-cbc- 1553 hmac-sha1-kd was designed to cause each bit of input to contribute 1554 equally to the output; it was not designed to maximize or equally 1555 distribute randomness in the input, and there are conceivable cases 1556 of partially structured input where randomness may be lost. This 1557 should only be an issue for highly structured passwords, however. 1559 [RFC1851] discusses the relative strength of triple-DES encryption. 1560 The relative slow speed of triple-DES encryption may also be an issue 1561 for some applications. 1563 In [Bellovin91], there is a suggestion that analyses of encryption 1564 schemes should include a model of an attacker capable of submitting 1565 known plaintexts to be encrypted with an unknown key, as well as 1566 being able to perform many types of operations on known protocol 1567 messages. Recent experiences with the chosen-plaintext attacks on 1568 Kerberos version 4 bear out the value of this suggestion. 1570 The use of unkeyed encrypted checksums, such as those used in the 1571 single-DES cryptosystems specified in [Kerb1510], allows for cut-and- 1572 paste attacks, especially if a confounder is not used. In addition, 1573 unkeyed encrypted checksums are vulnerable to chosen-plaintext 1574 attacks: an attacker with access to an encryption oracle can easily 1575 encrypt the required unkeyed checksum along with the chosen 1576 plaintext. [Bellovin99] These weaknesses, combined with a common 1577 implementation design choice described below, allow for a cross- 1578 protocol attack from version 4 to version 5. 1580 The use of a random confounder is an important means of preventing an 1581 attacker from making effective use of protocol exchanges as an 1582 encryption oracle. In Kerberos version 4, the encryption of constant 1583 plaintext to constant ciphertext makes an effective encryption oracle 1584 for an attacker. The use of random confounders in [Kerb1510] 1585 frustrates this sort of chosen-plaintext attack. 1587 Using the same key for multiple purposes can enable or increase the 1588 scope of chosen-plaintext attacks. Some software which implements 1589 both versions 4 and 5 of the Kerberos protocol uses the same keys for 1590 both versions of the protocol. This enables the encryption oracle of 1591 version 4 to be used to attack version 5. Vulnerabilities such as 1592 this cross-protocol attack reinforce the wisdom of not using a key 1593 for multiple purposes. 1595 This document, like the Kerberos protocol, completely ignores the 1596 notion of limiting the amount of data a key may be used with to a 1597 quantity based on the robustness of the algorithm or size of the key. 1598 It is assumed that any defined algorithms and key sizes will be 1599 strong enough to support very large amounts of data, or they will be 1600 deprecated once significant attacks are known. 1602 This document also places no bounds on the amount of data that can be 1603 handled in various operations. In order to avoid denial of service 1604 attacks, implementations will probably want to restrict message sizes 1605 at some higher level. 1607 11. IANA Considerations 1609 Two registries for numeric values should be created: Kerberos 1610 Encryption Type Numbers and Kerberos Checksum Type Numbers. These 1611 are signed values ranging from -2147483648 to 2147483647. Positive 1612 values should be assigned only for algorithms specified in accordance 1613 with this specification for use with Kerberos or related protocols. 1614 Negative values are for private use; local and experimental 1615 algorithms should use these values. Zero is reserved and may not be 1616 assigned. 1618 Positive encryption and checksum type numbers may be assigned 1619 following either of two policies described in [BCP26]. 1621 Standards-track specifications may be assigned values under the 1622 Standards Action policy. 1624 Specifications in non-standards track RFCs may be assigned values 1625 after Expert Review. A non-IETF specification may be assigned values 1626 by publishing an Informational or standards-track RFC referencing the 1627 external specification; that specification must be public and 1628 published in some permanent record much like the IETF RFCs. It is 1629 highly desirable, though not required, that the full specification be 1630 published as an IETF RFC. 1632 Smaller encryption type values should be used for IETF standards- 1633 track mechanisms, and much higher values (16777216 and above) for 1634 other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, 1635 smaller numbers encode to smaller octet sequences, so this favors 1636 standards-track mechanisms with slightly smaller messages.) Aside 1637 from that guideline, IANA may choose numbers as it sees fit. 1639 Internet-Draft specifications should not include values for 1640 encryption and checksum type numbers. Instead, they should indicate 1641 that values would be assigned by IANA when the document is approved 1642 as an RFC. For development and interoperability testing, values in 1643 the private-use range (negative values) may be used, but should not 1644 be included in the draft specification. 1646 Each registered value should have an associated unique name to refer 1647 to it by. The lists given in section 8 should be used as an initial 1648 registry; they include reservations for specifications in progress in 1649 parallel with this document, and for certain other values believed to 1650 be in use already. 1652 12. Acknowledgments 1654 This document is an extension of the encryption specification 1655 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much 1656 of the text of the background, concepts, and DES specifications are 1657 drawn directly from that document. 1659 The abstract framework presented in this document was put together by 1660 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, 1661 and Tom Yu, and the details were refined several times based on 1662 comments from John Brezak and others. 1664 Marc Horowitz wrote the original specification of triple-DES and key 1665 derivation in a pair of Internet Drafts (under the names draft- 1666 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which 1667 were later folded into a draft revision of [Kerb1510], from which 1668 this document was later split off. 1670 Tom Yu provided the text describing the modifications to the standard 1671 CRC algorithm as Kerberos implementations actually use it, and some 1672 of the Security Considerations section. 1674 Miroslav Jurisic provided information for one of the UTF-8 test cases 1675 for the string-to-key functions. 1677 Marcus Watts noticed some errors in earlier drafts, and pointed out 1678 that the simplified profile could easily be modified to support 1679 cipher text stealing modes. 1681 Simon Josefsson contributed some clarifications to the DES "CBC 1682 checksum", string-to-key and weak key descriptions, and some test 1683 vectors. 1685 Simon Josefsson, Louis LeVay and others also caught some errors in 1686 earlier drafts. 1688 A. Test vectors 1690 This section provides test vectors for various functions defined or 1691 described in this document. For convenience, most inputs are ASCII 1692 strings, though some UTF-8 samples are be provided for string-to-key 1693 functions. Keys and other binary data are specified as hexadecimal 1694 strings. 1696 A.1. n-fold 1698 The n-fold function is defined in section 5.1. As noted there, the 1699 sample vector in the original paper defining the algorithm appears to 1700 be incorrect. Here are some test cases provided by Marc Horowitz and 1701 Simon Josefsson: 1703 64-fold("012345") = 1704 64-fold(303132333435) = be072631276b1955 1706 56-fold("password") = 1707 56-fold(70617373776f7264) = 78a07b6caf85fa 1709 64-fold("Rough Consensus, and Running Code") = 1710 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 1711 6e696e6720436f6465) = bb6ed30870b7f0e0 1713 168-fold("password") = 1714 168-fold(70617373776f7264) = 1715 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 1717 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 1718 192-fold(4d41535341434856534554545320494e5354495456544520 1719 4f4620544543484e4f4c4f4759) = 1720 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 1722 168-fold("Q") = 1723 168-fold(51) = 1724 518a54a2 15a8452a 518a54a2 15a8452a 1725 518a54a2 15 1727 168-fold("ba") = 1728 168-fold(6261) = 1729 fb25d531 ae897449 9f52fd92 ea9857c4 1730 ba24cf29 7e 1732 Here are some additional values corresponding to folded values of the 1733 string "kerberos"; the 64-bit form is used in the des3 string-to-key 1734 (section 6.3.1). 1736 64-fold("kerberos") = 1737 6b657262 65726f73 1738 128-fold("kerberos") = 1739 6b657262 65726f73 7b9b5b2b 93132b93 1740 168-fold("kerberos") = 1741 8372c236 344e5f15 50cd0747 e15d62ca 1742 7a5a3bce a4 1743 256-fold("kerberos") = 1744 6b657262 65726f73 7b9b5b2b 93132b93 1745 5c9bdcda d95c9899 c4cae4de e6d6cae4 1747 Note that the initial octets exactly match the input string when the 1748 output length is a multiple of the input length. 1750 A.2. mit_des_string_to_key 1752 The function mit_des_string_to_key is defined in section 6.2. We 1753 present here several test values, with some of the intermediate 1754 results. The fourth test demonstrates the use of UTF-8 with three 1755 characters. The last two tests are specifically constructed so as to 1756 trigger the weak-key fixups for the intermediate key produced by fan- 1757 folding; we have no test cases that cause such fixups for the final 1758 key. 1760 UTF-8 encodings used in test vector: 1761 eszett U+00DF C3 9F s-caron U+0161 C5 A1 1762 c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E 1764 Test vector: 1766 salt: "ATHENA.MIT.EDUraeburn" 1767 415448454e412e4d49542e4544557261656275726e 1768 password: "password" 70617373776f7264 1769 fan-fold result: c01e38688ac86c2e 1770 intermediate key: c11f38688ac86d2f 1771 DES key: cbc22fae235298e3 1773 salt: "WHITEHOUSE.GOVdanny" 1774 5748495445484f5553452e474f5664616e6e79 1775 password: "potatoe" 706f7461746f65 1776 fan-fold result: a028944ee63c0416 1777 intermediate key: a129944fe63d0416 1778 DES key: df3d32a74fd92a01 1780 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 1781 password: g-clef (U+1011E) f09d849e 1782 fan-fold result: 3c4a262c18fab090 1783 intermediate key: 3d4a262c19fbb091 1784 DES key: 4ffb26bab0cd9413 1786 salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107) 1787 415448454e412e4d49542e4544554a757269c5a169c487 1788 password: eszett(U+00DF) 1789 c39f 1790 fan-fold result:b8f6c40e305afc9e 1791 intermediate key: b9f7c40e315bfd9e 1792 DES key: 62c81a5232b5e69d 1793 salt: "AAAAAAAA" 4141414141414141 1794 password: "11119999" 3131313139393939 1795 fan-fold result: e0e0e0e0f0f0f0f0 1796 intermediate key: e0e0e0e0f1f1f101 1797 DES key: 984054d0f1a73e31 1799 salt: "FFFFAAAA" 4646464641414141 1800 password: "NNNN6666" 4e4e4e4e36363636 1801 fan-fold result: 1e1e1e1e0e0e0e0e 1802 intermediate key: 1f1f1f1f0e0e0efe 1803 DES key: c4bf6b25adf7a4f8 1805 This trace provided by Simon Josefsson shows the intermediate 1806 processing stages of one of the test inputs: 1808 string_to_key (des-cbc-md5, string, salt) 1809 ;; string: 1810 ;; `password' (length 8 bytes) 1811 ;; 70 61 73 73 77 6f 72 64 1812 ;; salt: 1813 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 1814 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 1815 ;; 65 62 75 72 6e 1816 des_string_to_key (string, salt) 1817 ;; String: 1818 ;; `password' (length 8 bytes) 1819 ;; 70 61 73 73 77 6f 72 64 1820 ;; Salt: 1821 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 1822 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 1823 ;; 65 62 75 72 6e 1824 odd = 1; 1825 s = string | salt; 1826 tempstring = 0; /* 56-bit string */ 1827 pad(s); /* with nulls to 8 byte boundary */ 1828 ;; s = pad(string|salt): 1829 ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' 1830 ;; (length 32 bytes) 1831 ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d 1832 ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 1833 for (8byteblock in s) { 1834 ;; loop iteration 0 1835 ;; 8byteblock: 1836 ;; `password' (length 8 bytes) 1837 ;; 70 61 73 73 77 6f 72 64 1838 ;; 01110000 01100001 01110011 01110011 01110111 01101111 1839 ;; 01110010 01100100 1840 56bitstring = removeMSBits(8byteblock); 1841 ;; 56bitstring: 1842 ;; 1110000 1100001 1110011 1110011 1110111 1101111 1843 ;; 1110010 1100100 1844 if (odd == 0) reverse(56bitstring); ;; odd=1 1845 odd = ! odd 1846 tempstring = tempstring XOR 56bitstring; 1847 ;; tempstring 1848 ;; 1110000 1100001 1110011 1110011 1110111 1101111 1849 ;; 1110010 1100100 1851 for (8byteblock in s) { 1852 ;; loop iteration 1 1853 ;; 8byteblock: 1854 ;; `ATHENA.M' (length 8 bytes) 1855 ;; 41 54 48 45 4e 41 2e 4d 1856 ;; 01000001 01010100 01001000 01000101 01001110 01000001 1857 ;; 00101110 01001101 1858 56bitstring = removeMSBits(8byteblock); 1859 ;; 56bitstring: 1860 ;; 1000001 1010100 1001000 1000101 1001110 1000001 1861 ;; 0101110 1001101 1862 if (odd == 0) reverse(56bitstring); ;; odd=0 1863 reverse(56bitstring) 1864 ;; 56bitstring after reverse 1865 ;; 1011001 0111010 1000001 0111001 1010001 0001001 1866 ;; 0010101 1000001 1867 odd = ! odd 1868 tempstring = tempstring XOR 56bitstring; 1869 ;; tempstring 1870 ;; 0101001 1011011 0110010 1001010 0100110 1100110 1871 ;; 1100111 0100101 1873 for (8byteblock in s) { 1874 ;; loop iteration 2 1875 ;; 8byteblock: 1876 ;; `IT.EDUra' (length 8 bytes) 1877 ;; 49 54 2e 45 44 55 72 61 1878 ;; 01001001 01010100 00101110 01000101 01000100 01010101 1879 ;; 01110010 01100001 1880 56bitstring = removeMSBits(8byteblock); 1881 ;; 56bitstring: 1882 ;; 1001001 1010100 0101110 1000101 1000100 1010101 1883 ;; 1110010 1100001 1884 if (odd == 0) reverse(56bitstring); ;; odd=1 1885 odd = ! odd 1886 tempstring = tempstring XOR 56bitstring; 1887 ;; tempstring 1888 ;; 1100000 0001111 0011100 0001111 1100010 0110011 1889 ;; 0010101 1000100 1891 for (8byteblock in s) { 1892 ;; loop iteration 3 1893 ;; 8byteblock: 1894 ;; `eburn\x00\x00\x00' (length 8 bytes) 1895 ;; 65 62 75 72 6e 00 00 00 1896 ;; 01100101 01100010 01110101 01110010 01101110 00000000 1897 ;; 00000000 00000000 1898 56bitstring = removeMSBits(8byteblock); 1899 ;; 56bitstring: 1900 ;; 1100101 1100010 1110101 1110010 1101110 0000000 1901 ;; 0000000 0000000 1902 if (odd == 0) reverse(56bitstring); ;; odd=0 1903 reverse(56bitstring) 1904 ;; 56bitstring after reverse 1905 ;; 0000000 0000000 0000000 0111011 0100111 1010111 1906 ;; 0100011 1010011 1907 odd = ! odd 1908 tempstring = tempstring XOR 56bitstring; 1909 ;; tempstring 1910 ;; 1100000 0001111 0011100 0110100 1000101 1100100 1911 ;; 0110110 0010111 1913 for (8byteblock in s) { 1914 } 1915 ;; for loop terminated 1917 tempkey = key_correction(add_parity_bits(tempstring)); 1918 ;; tempkey 1919 ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) 1920 ;; c1 1f 38 68 8a c8 6d 2f 1921 ;; 11000001 00011111 00111000 01101000 10001010 11001000 1922 ;; 01101101 00101111 1924 key = key_correction(DES-CBC-check(s,tempkey)); 1925 ;; key 1926 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 1927 ;; cb c2 2f ae 23 52 98 e3 1928 ;; 11001011 11000010 00101111 10101110 00100011 01010010 1929 ;; 10011000 11100011 1931 ;; string_to_key key: 1932 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 1933 ;; cb c2 2f ae 23 52 98 e3 1935 A.3. DES3 DR and DK 1937 These tests show the derived-random and derived-key values for the 1938 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions 1939 defined in section 6.3.1. The input keys were randomly generated; 1940 the usage values are from this specification. 1942 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 1943 usage: 0000000155 1944 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 1945 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 1947 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 1948 usage: 00000001aa 1949 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 1950 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 1952 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 1953 usage: 0000000155 1954 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 1955 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 1957 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 1958 usage: 00000001aa 1959 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 1960 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 1962 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 1963 usage: 6b65726265726f73 ("kerberos") 1964 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 1965 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 1967 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 1968 usage: 0000000155 1969 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 1970 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 1972 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 1973 usage: 00000001aa 1974 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 1975 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 1977 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 1978 usage: 0000000155 1979 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 1980 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 1982 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 1983 usage: 00000001aa 1984 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 1985 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 1987 A.4. DES3string_to_key 1989 These are the keys generated for some of the above input strings for 1990 triple-DES with key derivation as defined in section 6.3.1. 1992 salt: "ATHENA.MIT.EDUraeburn" 1993 passwd: "password" 1994 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1996 salt: "WHITEHOUSE.GOVdanny" 1997 passwd: "potatoe" 1998 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 2000 salt: "EXAMPLE.COMbuckaroo" 2001 passwd: "penny" 2002 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 2004 salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" 2005 + c-acute(U+0107) 2006 passwd: eszett(U+00DF) 2007 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 2009 salt: "EXAMPLE.COMpianist" 2010 passwd: g-clef(U+1011E) 2011 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 2013 A.5. Modified CRC-32 2015 Below are modified-CRC32 values for various ASCII and octet strings. 2016 Only the printable ASCII characters are checksummed, no C-style 2017 trailing zero-valued octet. The 32-bit modified CRC and the sequence 2018 of output bytes as used in Kerberos are shown. (The octet values are 2019 separated here to emphasize that they are octet values and not 32-bit 2020 numbers, which will be the most convenient form for manipulation in 2021 some implementations. The bit and byte order used internally for 2022 such a number is irrelevant; the octet sequence generated is what is 2023 important.) 2025 mod-crc-32("foo") = 33 bc 32 73 2026 mod-crc-32("test0123456789") = d6 88 3e b8 2027 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 2028 mod-crc-32(8000) = 4b 98 83 3b 2029 mod-crc-32(0008) = 32 88 db 0e 2030 mod-crc-32(0080) = 20 83 b8 ed 2031 mod-crc-32(80) = 20 83 b8 ed 2032 mod-crc-32(80000000) = 3b b6 59 ed 2033 mod-crc-32(00000001) = 96 30 07 77 2035 B. Significant Changes from RFC 1510 2037 The encryption and checksum mechanism profiles are new. The old 2038 specification defined a few operations for various mechanisms, but 2039 didn't outline what should be required of new mechanisms in terms of 2040 abstract properties, nor how to ensure that a mechanism specification 2041 is complete enough for interoperability between implementations. The 2042 new profiles do differ from the old specification in a few ways: 2044 Some message definitions in [Kerb1510] could be read as permitting 2045 the initial vector to be specified by the application; the text 2046 was too vague. It is specifically not permitted in this 2047 specification. Some encryption algorithms may not use 2048 initialization vectors, so relying on chosen, secret 2049 initialization vectors for security is unwise. Also, the 2050 prepended confounder in the existing algorithms is roughly 2051 equivalent to a per-message initialization vector that is revealed 2052 in encrypted form. However, carrying state across from one 2053 encryption to another is explicitly permitted through the opaque 2054 "cipher state" object. 2056 The use of key derivation is new. 2058 Several new methods are introduced, including generation of a key 2059 in wire-protocol format from random input data. 2061 The means for influencing the string-to-key algorithm are laid out 2062 more clearly. 2064 Triple-DES support is new. 2066 The pseudo-random function is new. 2068 The des-cbc-crc, DES string-to-key and CRC descriptions have been 2069 updated to align them with existing implementations. 2071 [Kerb1510] had no indication what character set or encoding might be 2072 used for pass phrases and salts. 2074 In [Kerb1510], key types, encryption algorithms and checksum 2075 algorithms were only loosely associated, and the association was not 2076 well described. In this specification, key types and encryption 2077 algorithms have a one-to-one correspondence, and associations between 2078 encryption and checksum algorithms are described so that checksums 2079 can be computed given negotiated keys, without requiring further 2080 negotiation for checksum types. 2082 Notes 2084 [1] While Message Authentication Code (MAC) or Message Integrity 2085 Check (MIC) would be more appropriate terms for many of the 2086 uses in this document, we continue to use the term "checksum" 2087 for historical reasons. 2089 [2] Extending CBC mode across messages would be one obvious 2090 example of this chaining. Another might be the use of 2091 counter mode, with a counter randomly initialized and 2092 attached to the ciphertext; a second message could continue 2093 incrementing the counter when chaining the cipher state, thus 2094 avoiding having to transmit another counter value. However, 2095 this chaining is only useful for uninterrupted, ordered 2096 sequences of messages. 2098 [3] In the case of Kerberos, the encrypted objects will generally 2099 be ASN.1 DER encodings, which contain indications of their 2100 length in the first few octets. 2102 [4] As of the time of this writing, some new modes of operation 2103 have been proposed, some of which may permit encryption and 2104 integrity protection simultaneously. After some of these 2105 proposals have been subjected to adequate analysis, we may 2106 wish to formulate a new simplified profile based on one of 2107 them. 2109 [5] It should be noted that the sample vector in Appendix B.2 of 2110 the original paper appears to be incorrect. Two independent 2111 implementations from the specification (one in C by Marc 2112 Horowitz, and another in Scheme by Bill Sommerfeld) agree on 2113 a value different from that in [Blumenthal96]. 2115 [6] For example, in MIT's implementation of [Kerb1510], the rsa- 2116 md5 unkeyed checksum of application data may be included in 2117 an authenticator encrypted in a service's key; since rsa-md5 2118 is believed to be collision-proof, even if the application 2119 data is exposed to an attacker, it cannot be modified without 2120 causing the checksum verification to fail. 2122 [7] A variant of the key is used to limit the use of a key to a 2123 particular function, separating the functions of generating a 2124 checksum from other encryption performed using the session 2125 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it 2126 maintains key parity. The properties of DES precluded the 2127 use of the complement. The same constant is used for similar 2128 purpose in the Message Integrity Check in the Privacy 2129 Enhanced Mail standard. 2131 [8] Perhaps one of the more common reasons for directly 2132 performing encryption is direct control over the negotiation 2133 and to select a "sufficiently strong" encryption algorithm 2134 (whatever that means in the context of a given application). 2135 While Kerberos directly provides no facility for negotiating 2136 encryption types between the application client and server, 2137 there are other means for accomplishing similar goals. For 2138 example, requesting only "strong" session key types from the 2139 KDC, and assuming that the type actually returned by the KDC 2140 will be understood and supported by the application server. 2142 Intellectual Property Statement 2144 The IETF takes no position regarding the validity or scope of any 2145 intellectual property or other rights that might be claimed to 2146 pertain to the implementation or use of the technology described in 2147 this document or the extent to which any license under such rights 2148 might or might not be available; neither does it represent that it 2149 has made any effort to identify any such rights. Information on the 2150 IETF's procedures with respect to rights in standards-track and 2151 standards-related documentation can be found in BCP-11. Copies of 2152 claims of rights made available for publication and any assurances of 2153 licenses to be made available, or the result of an attempt made to 2154 obtain a general license or permission for the use of such 2155 proprietary rights by implementors or users of this specification can 2156 be obtained from the IETF Secretariat. 2158 The IETF invites any interested party to bring to its attention any 2159 copyrights, patents or patent applications, or other proprietary 2160 rights which may cover technology that may be required to practice 2161 this standard. Please address the information to the IETF Executive 2162 Director. 2164 Normative References 2166 [Bellare98] 2167 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, 2168 "Relations Among Notions of Security for Public-Key Encryption 2169 Schemes". Extended abstract published in Advances in Cryptology- 2170 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 2171 1462, H. Krawcyzk ed., Springer-Verlag, 1998. 2172 [Blumenthal96] 2173 Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES- 2174 Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996. 2175 [CRC] 2176 International Organization for Standardization, "ISO Information 2177 Processing Systems - Data Communication - High-Level Data Link 2178 Control Procedure - Frame Structure," IS 3309, 3rd Edition, 2179 October 1984. 2180 [DES77] 2181 National Bureau of Standards, U.S. Department of Commerce, "Data 2182 Encryption Standard," Federal Information Processing Standards 2183 Publication 46, Washington, DC, 1977. 2184 [DESI81] 2185 National Bureau of Standards, U.S. Department of Commerce, 2186 "Guidelines for implementing and using NBS Data Encryption 2187 Standard," Federal Information Processing Standards Publication 2188 74, Washington, DC, 1981. 2189 [DESM80] 2190 National Bureau of Standards, U.S. Department of Commerce, "DES 2191 Modes of Operation," Federal Information Processing Standards 2192 Publication 81, Springfield, VA, December 1980. 2193 [Dolev91] 2194 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 2195 Proceedings of the 23rd Annual Symposium on Theory of Computing, 2196 ACM, 1991. 2197 [HMAC] 2198 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2199 for Message Authentication", RFC 2104, February 1997. 2201 [KRB5-AES] 2202 Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx 2203 2003. 2204 [MD4-92] 2205 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT 2206 Laboratory for Computer Science, April 1992. 2207 [MD5-92] 2208 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT 2209 Laboratory for Computer Science, April 1992. 2210 [RFC2026] 2211 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC 2212 2026, October 1996. 2213 [SG92] 2214 Stubblebine, S., and V. D. Gligor, "On Message Integrity in 2215 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 2216 Research in Security and Privacy, Oakland, California, May 1992. 2218 Informative References 2220 [Bellovin91] 2221 Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos 2222 Authentication System", in Proceedings of the Winter 1991 Usenix 2223 Security Conference, January, 1991. 2224 [Bellovin99] 2225 Bellovin, S. M., and D. Atkins, private communications, 1999. 2226 [EFF-DES] 2227 Electronic Frontier Foundation, "Cracking DES: Secrets of 2228 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly 2229 & Associates, Inc., May 1998. 2230 [ESP-DES] 2231 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 2232 With Explicit IV", RFC 2405, November 1998. 2233 [GSS-KRB5] 2234 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964, 2235 June 1996. 2236 [HMAC-TEST] 2237 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 2238 RFC 2202, September 1997. 2239 [IPSEC-HMAC] 2240 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 2241 AH", RFC 2404, November 1998. 2242 [Kerb] 2243 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 2244 Raeburn, "The Kerberos Network Authentication Service (V5)", 2245 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 2246 2002. Work in progress. 2248 [Kerb1510] 2249 Kohl, J., and C. Neuman, "The Kerberos Network Authentication 2250 Service (V5)", RFC 1510, September 1993. 2251 [RC5] 2252 Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 2253 RC5-CTS Algorithms", RFC 2040, October 1996. 2254 [Schneier96] 2255 Schneier, B., "Applied Cryptography Second Edition", John Wiley & 2256 Sons, New York, NY, 1996. ISBN 0-471-12845-7. 2258 Editor's address 2260 Kenneth Raeburn 2261 Massachusetts Institute of Technology 2262 77 Massachusetts Avenue 2263 Cambridge, MA 02139 2264 raeburn@mit.edu 2266 Full Copyright Statement 2268 Copyright (C) The Internet Society (2004). All Rights Reserved. 2270 This document and translations of it may be copied and furnished to 2271 others, and derivative works that comment on or otherwise explain it 2272 or assist in its implementation may be prepared, copied, published 2273 and distributed, in whole or in part, without restriction of any 2274 kind, provided that the above copyright notice and this paragraph are 2275 included on all such copies and derivative works. However, this 2276 document itself may not be modified in any way, such as by removing 2277 the copyright notice or references to the Internet Society or other 2278 Internet organizations, except as needed for the purpose of 2279 developing Internet standards in which case the procedures for 2280 copyrights defined in the Internet Standards process must be 2281 followed, or as required to translate it into languages other than 2282 English. 2284 The limited permissions granted above are perpetual and will not be 2285 revoked by the Internet Society or its successors or assigns. 2287 This document and the information contained herein is provided on an 2288 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2289 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2290 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2291 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2292 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2294 Notes to RFC Editor 2296 Before publication of this document as an RFC, the following changes 2297 are needed: 2299 Change the reference "[KRB5-AES]" in Normative References to indicate 2300 the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be 2301 advancing to RFC at the same time. The RFC number and publication 2302 date are needed. 2304 If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the 2305 same time as this document, change the information for [Kerb] in the 2306 Informative References section as well. 2308 Change the first-page headers to indicate the RFC number, network 2309 working group, etc, as appropriate for an RFC instead of an I-D. 2311 Remove the contact-info paragraph from the Abstract. 2313 Delete this section.