idnits 2.17.1 draft-ietf-krb-wg-crypto-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC2026], [Kerb]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 639 has weird spacing: '...osystem as d...' == Line 674 has weird spacing: '...ructure empt...' == Line 691 has weird spacing: '...-to-key non...' == Line 835 has weird spacing: '...ructure copy...' == Line 859 has weird spacing: '...-to-key emp...' == (16 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 (November 3, 2002) is 7838 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 1859 == Missing Reference: 'K' is mentioned on line 237, but not defined -- Looks like a reference, but probably isn't: '2' on line 1864 -- Looks like a reference, but probably isn't: '3' on line 1868 -- Looks like a reference, but probably isn't: '4' on line 1875 -- Looks like a reference, but probably isn't: '0' on line 809 -- Looks like a reference, but probably isn't: '5' on line 1881 -- Looks like a reference, but probably isn't: '6' on line 1890 == Missing Reference: 'RFC1851' is mentioned on line 1484, 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. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dolev91' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** 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: 9 errors (**), 0 flaws (~~), 11 warnings (==), 18 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-01.txt May 3, 2002 5 expires November 3, 2002 7 Encryption and Checksum Specifications 8 for Kerberos 5 10 Abstract 12 This document describes a framework for defining encryption and 13 checksum mechanisms for use with the Kerberos protocol [Kerb], 14 defining an abstraction layer between the Kerberos protocol and 15 related protocols, and the actual mechanisms themselves. Several 16 mechanisms are also defined in this document. Some are taken from 17 RFC 1510, modified in form to fit this new framework, and 18 occasionally modified in content when the old specification was 19 incorrect. New mechanisms are presented here as well. This document 20 does NOT indicate which mechanisms may be considered "required to 21 implement" or deprecated. 23 Comments should be sent to the editor, or to the IETF Kerberos 24 working group (ietf-krb-wg@anl.gov). 26 Status 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 30 are working documents of the Internet Engineering Task Force (IETF), 31 its areas, and its working groups. Note that other groups may also 32 distribute working documents as Internet-Drafts. Internet-Drafts are 33 draft documents valid for a maximum of six months and may be updated, 34 replaced, or obsoleted by other documents at any time. It is 35 inappropriate to use Internet-Drafts as reference material or to cite 36 them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.html. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 47 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 48 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 52 3. Checksum mechanism attributes . . . . . . . . . . . . . . . . . . 9 53 4. Simplified profile for CBC ciphers with key derivation . . . . . 10 54 4.1. A key derivation function . . . . . . . . . . . . . . . . . . . 10 55 4.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 12 56 4.3. Cryptosystem profile based on simplified profile . . . . . . . 13 57 4.4. Checksum profiles based on simplified profile . . . . . . . . . 14 58 5. Profiles for Kerberos encryption systems . . . . . . . . . . . . 15 59 5.1. null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 5.2. DES-based encryption systems . . . . . . . . . . . . . . . . . 16 61 5.3. Triple-DES Encryption with Key Derivation . . . . . . . . . . . 22 62 6. Profiles for Kerberos checksums . . . . . . . . . . . . . . . . . 24 63 6.1. RSA MD4- and MD5-Based Checksums . . . . . . . . . . . . . . . 24 64 6.2. CRC-32 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 27 65 6.3. DES MAC checksums . . . . . . . . . . . . . . . . . . . . . . . 28 66 6.4. HMAC-SHA1-DES3-KD Checksum . . . . . . . . . . . . . . . . . . 29 67 7. Use of Kerberos encryption outside this specification . . . . . . 29 68 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 30 69 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 32 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 32 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 33 72 12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . . 34 73 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34 74 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 75 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 76 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 35 77 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 37 78 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 38 79 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 39 80 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 39 81 C. Document History (delete before publication) . . . . . . . . . . 40 82 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 83 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 43 84 Informative References . . . . . . . . . . . . . . . . . . . . . . . 44 85 Introduction 87 The Kerberos protocols are designed to encrypt messages of arbitrary 88 sizes, using block encryption ciphers, or less commonly, stream 89 encryption ciphers. Encryption is used to prove the identities of 90 the network entities participating in message exchanges. However, 91 nothing in the Kerberos protocol requires any specific encryption 92 algorithm be used, as long as certain operations are available in the 93 algorithm that is used. 95 The following sections specify the encryption and checksum mechanisms 96 currently defined for Kerberos, as well as a framework for defining 97 future mechanisms. The encoding, chaining, padding and other 98 requirements for each are described. Test vectors for several 99 functions are given in appendix A. 101 1. Concepts 103 Both encryption and checksum mechanisms are defined in terms of 104 profiles, detailed in later sections. Each specifies a collection of 105 operations and attributes that must be defined for a mechanism. A 106 Kerberos encryption or checksum mechanism specification is not 107 complete if it does not define all of these operations and 108 attributes. 110 An encryption mechanism must provide for confidentiality and 111 integrity of the original plaintext. (Integrity checking may be 112 achieved by incorporating a checksum, if the encryption mode does not 113 provide an integrity check itself.) It must also provide non- 114 malleability [Bellare98, Dolev91]. Use of a random confounder 115 prepended to the plaintext is recommended. It should not be possible 116 to determine if two ciphertexts correspond to the same plaintext, 117 without knowledge of the key. 119 A checksum mechanism [1] must provide proof of the integrity of the 120 associated message, and must preserve the confidentiality of the 121 message in case it is not sent in the clear. It should be infeasible 122 to find two plaintexts which have the same checksum. It is NOT 123 required that an eavesdropper be unable to determine if two checksums 124 are for the same message; it is assumed that the messages themselves 125 will be visible to any such eavesdropper. 127 Due to advances in cryptography, it is considered unwise by some 128 cryptographers to use the same key for multiple purposes. Since keys 129 are used in performing a number of different functions in Kerberos, 130 it is desirable to use different keys for each of these purposes, 131 even though we start with a single long-term or session key. 133 We do this by enumerating the different uses of keys within Kerberos, 134 and making the "usage number" an input to the encryption or checksum 135 mechanisms; this enumeration is outside the scope of this document. 136 Later sections of this document define simplified profile templates 137 for encryption and checksum mechanisms that use a key derivation 138 function applied to a CBC mode (or similar) cipher and a checksum or 139 hash algorithm. 141 We distinguish the "base key" specified by other documents from the 142 "specific key" to be used for a particular instance of encryption or 143 checksum operations. It is expected but not required that the 144 specific key will be one or more separate keys derived from the 145 original protocol key and the key usage number. The specific key 146 should not be explicitly referenced outside of this document. The 147 typical language used in other documents should be something like, 148 "encrypt this octet string using this key and this usage number"; 149 generation of the specific key and cipher state (described in the 150 next section) are implicit. The creation of a new cipher-state 151 object, or the re-use of one from a previous encryption operation, 152 may also be explicit. 154 New protocols defined in terms of the Kerberos encryption and 155 checksum types should use their own key usage values. Key usages are 156 unsigned 32 bit integers; zero is not permitted. 158 All data is assumed to be in the form of strings of octets or 8-bit 159 bytes. Environments with other byte sizes will have to emulate this 160 behavior in order to get correct results. 162 2. 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 184 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. 223 The third argument, the octet string, may be used to pass 224 mechanism-specific parameters in to this function. Since doing 225 so implies knowledge of the specific encryption system, it is 226 intended that generating non-default parameter values be an 227 uncommon operation, and that normal Kerberos applications be 228 able to treat this parameter block as an opaque object supplied 229 by the KDC or defaulted to some mechanism-specific constant 230 value. 232 This should be a one-way function, so that compromising a 233 user's key in one realm does not compromise the user's key in 234 another realm, even if the same password (but a different salt) 235 is used. 237 random-to-key (bitstring[K])->(protocol-key) 238 This function generates a key from a random bit string of a 239 specific size. It may be assumed that all the bits of the 240 input string are equally random, even though the entropy 241 present in the random source may be limited. 243 key-derivation (protocol-key, integer)->(specific-key) 244 In this function, the integer input is the key usage value as 245 described above; the usage values must be assumed to be known 246 to an attacker. The specific-key output value was described in 247 section 1. 249 string-to-key parameter format 250 This describes the format of the block of data that can be passed 251 to the string-to-key function above to configure additional 252 parameters for that function. Along with the mechanism of 253 encoding parameter values, bounds on the allowed parameters should 254 also be described to avoid allowing a spoofed KDC to compromise 255 the user's password. It may be desirable to construct the 256 encoding such that values weakening the resulting key unacceptably 257 cannot be encoded, if practical. 259 Tighter bounds might be permitted by local security policy, or to 260 avoid excess resource consumption; if so, recommended defaults for 261 those bounds should be given in the specification. The 262 description should also outline possible weaknesses that may be 263 caused by not applying bounds checks or other validation to a 264 parameter string received from the network. 266 As emntioned above, this should be considered opaque to most 267 normal applications. 269 default string-to-key parameters (octet string) 270 This default value for the "params" argument to the string-to-key 271 function is to be used when the application protocol (Kerberos or 272 otherwise) does not explicitly set the parameter value. As 273 indicated above, this parameter block should be treated as an 274 opaque object in most cases. 276 cipher state 277 This describes any information that can be carried over from one 278 encryption or decryption operation to the next, for use in 279 conjunction with a given specific key. For example, a block 280 cipher used in CBC mode may put an initial vector of one block in 281 the cipher state. 283 This state must be non-empty, and must influence encryption so as 284 to require that messages be decrypted in the same order they were 285 encrypted, if the cipher state is carried over from one encryption 286 to the next. Distinguishing out-of-order or missing messages from 287 corrupted messages is not required; if desired, this can be done 288 at a higher level by including sequence numbers and not "chaining" 289 the cipher state between encryption operations. 291 The cipher state may not be reused in multiple encryption or 292 decryption operations; these operations all generate a new cipher 293 state that may be used for following operations using the same key 294 and operation. 296 The contents of the cipher state must be treated as opaque outside 297 of encryption system specifications. 299 initial cipher state (specific-key, direction)->(state) 300 This describes the generation of the initial value for the cipher 301 state if it is not being carried over from a previous encryption 302 or decryption operation. 304 This describes any initial state setup needed before encrypting 305 arbitrary amounts of data with a given specific key; the specific 306 key and the direction of operations to be performed (encrypt 307 versus decrypt) must be the only input needed for this 308 initialization. 310 This state should be treated as opaque in any uses outside of an 311 encryption algorithm definition. 313 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what 314 degree an application protocol could exercise control over the 315 initial vector used in DES CBC operations. Some existing 316 implementations permit the setting of the initial vector. This 317 new specification does not permit application control of the 318 cipher state (beyond "initialize" and "carry over from previous 319 encryption"), since the form and content of the initial cipher 320 state can vary between encryption systems, and may not always be a 321 single block of random data. 323 New Kerberos application protocols should not assume that they can 324 control the initial vector, or that one even exists. However, a 325 general-purpose implementation may wish to provide the capability, 326 in case applications explicitly setting it are encountered. 328 encrypt (specific-key, state, octet string)->(state, octet string) 329 This function takes the specific key, cipher state, and plaintext 330 as input, and generates ciphertext and a new cipher state as 331 outputs. If the basic encryption algorithm itself does not 332 provide for integrity protection (as DES in CBC mode does not do), 333 then some form of MAC or checksum must be included that can be 334 verified by the receiver. Some random factor such as a confounder 335 should be included so that an observer cannot know if two messages 336 contain the same plaintext, even if the cipher state and specific 337 keys are the same. The exact length of the plaintext need not be 338 encoded, but if it is not and if padding is required, the padding 339 must be added at the end of the string so that the decrypted 340 version may be parsed from the beginning. 342 The specification of the encryption function must not only 343 indicate the precise contents of the output octet string, but also 344 the output cipher state, if that state is not empty. The 345 application protocol may carry forward the output cipher state 346 from one encryption with a given specific key to another; the 347 effect of this "chaining" must be defined. 349 Assuming correctly-produced values for the specific key and cipher 350 state, no input octet string may result in an error indication. 352 decrypt (specific-key, state, octet string)->(state, octet string) 353 This function takes the specific key, cipher state, and ciphertext 354 as inputs, and verifies the integrity of the supplied ciphertext. 355 If the ciphertext's integrity is intact, this function produces 356 the plaintext and a new cipher state as outputs; otherwise, an 357 error indication must be returned, and the data discarded. 359 The result of the decryption may be longer than the original 360 plaintext, for example if the encryption mode adds padding to 361 reach a multiple of a block size. If this is the case, any extra 362 octets must be after the decoded plaintext. An application 363 protocol which needs to know the exact length of the message must 364 encode a length or recognizable "end of message" marker within the 365 plaintext. [2] 367 As with the encryption function, a correct specification for this 368 function must indicate not only the contents of the output octet 369 string, but also the resulting cipher state. 371 These operations and attributes are all that should be required to 372 support Kerberos and various proposed preauthentication schemes. 374 A document defining a new encryption type should also describe known 375 weaknesses or attacks, so that its security may be fairly assessed, 376 and should include test vectors or other validation procedures for 377 the operations defined. Specific references to information readily 378 available elsewhere are sufficient. 380 3. Checksum mechanism attributes 382 A checksum mechanism profile must define the following attributes and 383 operations: 385 associated encryption algorithm(s) 386 This essentially indicates the type of encryption key this 387 checksum mechanism can be used with. A single checksum mechanism 388 may have more than one associated encryption algorithm if they 389 share the same wire key format, string-to-key function, and key 390 derivation function. (This combination means that, for example, a 391 checksum type and password are adequate to get the specific key 392 used to compute a checksum.) 394 get_mic function 395 This function generates a MIC token for a given specific key (see 396 section 2), and message (represented as an octet string), that may 397 be used to verify the integrity of the associated message. This 398 function is not required to return the same deterministic result 399 on every use; it need only generate a token that the verify_mic 400 routine can check. 402 The output of this function will also dictate the size of the 403 checksum. 405 verify_mic function 406 Given a specific key, message, and MIC token, this function 407 ascertains whether the message integrity has been compromised. 408 For a deterministic get_mic routine, the corresponding verify_mic 409 may simply generate another checksum and compare them. 411 The get_mic and verify_mic operations must be able to handle inputs 412 of arbitrary length; if any padding is needed, the padding scheme 413 must be specified as part of these functions. 415 These operations and attributes are all that should be required to 416 support Kerberos and various proposed preauthentication schemes. 418 As with encryption mechanism definition documents, documents defining 419 new checksum mechanisms should indicate validation processes and 420 known weaknesses. 422 4. Simplified profile for CBC ciphers with key derivation 424 The profile outlines in sections 2 and 3 describes a large number of 425 operations that must be defined for encryption and checksum 426 algorithms to be used with Kerberos. We describe here a simpler 427 profile from which both encryption and checksum mechanism definitions 428 can be generated, filling in uses of key derivation in appropriate 429 places, providing integrity protection, and defining multiple 430 operations for the cryptosystem profile based on a smaller set of 431 operations given in the simplified profile. Not all of the existing 432 cryptosystems for Kerberos fit into this simplified profile, but we 433 recommend that future cryptosystems use it or something based on it. 434 [3] 436 Not all of the operations in the complete profiles are defined 437 through this mechanism; several must still be defined for each new 438 algorithm pair. 440 4.1. A key derivation function 442 Rather than define some scheme by which a "protocol key" is composed 443 of a large number of encryption keys, we use keys derived from a base 444 key to perform cryptographic operations. The base key must be used 445 only for generating the derived keys, and this derivation must be 446 non-invertible and entropy-preserving. Given these restrictions, 447 compromise of one derived key does not compromise the other subkeys. 448 Attack of the base key is limited, since it is only used for 449 derivation, and is not exposed to any user data. 451 Since the derived key has as much entropy as the base keys (if the 452 cryptosystem is good), password-derived keys have the full benefit of 453 all the entropy in the password. 455 To generate a derived key from a base key, we generate a pseudorandom 456 octet string, using an algorithm DR described below, and generate a 457 key from that octet string using a function dependent on the 458 encryption algorithm; the input length needed for that function, 459 which is also dependent on the encryption algorithm, dictates the 460 length of the string to be generated by the DR algorithm (the value 461 "k" below). 463 Derived Key = DK(Base Key, Well-Known Constant) 465 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 467 DR(Key, Constant) = k-truncate(E(Key, Constant)) 469 Here DR is the random-octet generation function described below, and 470 DK is the key-derivation function produced from it. In this 471 construction, E(Key, Plaintext) is a block cipher, Constant is a 472 well-known constant determined by the specific usage of this 473 function, and k-truncate truncates its argument by taking the first k 474 bits. Here, k is the key generation seed length needed for the 475 encryption system. 477 The output of the DR function is a string of bits; the actual key is 478 produced by applying the cryptosystem's random-to-key operation on 479 this bitstring. 481 If the output of E is shorter than k bits, then some entropy in the 482 key will be lost. If the Constant is smaller than the block size of 483 E, then it must be padded so it may be encrypted. 485 In either of these situations, a variation of the above construction 486 is used, where the folded Constant is encrypted, and the resulting 487 output is fed back into the encryption as necessary (the | indicates 488 concatentation): 490 K1 = E(Key, n-fold(Constant)) 491 K2 = E(Key, K1) 492 K3 = E(Key, K2) 493 K4 = ... 495 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 497 n-fold is an algorithm which takes m input bits and ``stretches'' 498 them to form n output bits with equal contribution from each input 499 bit to the output, as described in [Blumenthal96]: 501 We first define a primitive called n-folding, which takes a 502 variable-length input block and produces a fixed-length output 503 sequence. The intent is to give each input bit approximately 504 equal weight in determining the value of each output bit. Note 505 that whenever we need to treat a string of octets as a number, the 506 assumed representation is Big-Endian -- Most Significant Byte 507 first. 509 To n-fold a number X, replicate the input value to a length that 510 is the least common multiple of n and the length of X. Before 511 each repetition, the input is rotated to the right by 13 bit 512 positions. The successive n-bit chunks are added together using 513 1's-complement addition (that is, with end-around carry) to yield 514 a n-bit result.... 516 Test vectors for n-fold are supplied in Appendix A. [4] 518 In this document, n-fold is always used to produce n bits of output, 519 where n is the block size of E. 521 The size of the Constant must not be larger than the block size of E, 522 because reducing the length of the Constant by n-folding can cause 523 collisions. 525 If the size of the Constant is smaller than the block size of E, then 526 the Constant must be n-folded to the block size of E. This string is 527 used as input to E. If the block size of E is less than the key 528 size, then the output from E is taken as input to a second invocation 529 of E. This process is repeated until the number of bits accumulated 530 is greater than or equal to the key size of E. When enough bits have 531 been computed, the first k are taken as the derived key. 533 Since the derived key is the result of one or more encryptions in the 534 base key, deriving the base key from the derived key is equivalent to 535 determining the key from a very small number of plaintext/ciphertext 536 pairs. Thus, this construction is as strong as the cryptosystem 537 itself. 539 4.2. Simplified profile parameters 541 These are the operations and attributes that must be defined: 543 protocol key format 544 string-to-key function 545 default string-to-key parameters 546 key-generation seed length, k 547 random-to-key function 548 As above for the normal encryption mechanism profile. 550 unkeyed hash algorithm, H 551 This should be a collision-resistant hash algorithm with fixed- 552 size output, suitable for use in an HMAC [HMAC]. It must support 553 inputs of arbitrary length. 555 encryption block size, n 556 encryption/decryption functions, E and D 557 These are basic encryption and decryption functions for messages 558 of sizes that are multiples of the block size. No integrity 559 checking or confounder should be included here. They take as 560 input the IV or similar data, a protocol-format key, and a octet 561 string, returning a new IV and octet string. 563 The encryption function is not required to use CBC mode, but is 564 assumed to be using something with similar properties. In 565 particular, prepending a one-block confounder to the plaintext 566 should alter the entire ciphertext (comparable to choosing and 567 including a random initial vector for CBC mode). 569 While there are still a number of properties to specify, they are 570 fewer and simpler than in the full profile. 572 4.3. Cryptosystem profile based on simplified profile 574 The above key derivation function is used to produce three 575 intermediate keys. One is used for computing checksums of 576 unencrypted data. The other two are used for encrypting and 577 checksumming plaintext to be sent encrypted. 579 The ciphertext output is the concatenation of the output of the basic 580 encryption function E and an HMAC using the specified hash function 581 H, both applied to the plaintext with a one-block random confounder 582 prefix and sufficient padding to bring it to a multiple of the 583 encryption algorithm's block size. Decryption is performed by 584 stripping off the HMAC, decrypting the remainder, and verifying the 585 HMAC. The cipher state is an initial vector, initialized to zero. 587 cryptosystem from simplified profile 588 --------------------------------------------------------------------------------- 589 protocol key format As given. 591 specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 593 key-generation seed As given. 594 length 596 required checksum The checksum mechanism defined by the 597 mechanism simplified checksum profile given later. 599 cipher state CBC initial vector (one block), initialized 600 to all zero. 602 encryption function 603 C1 = E(Ke, conf | plaintext | pad, oldstate.ivec) 604 H1 = HMAC(Ki, conf | plaintext | pad) 605 ciphertext = C1 | H1 606 newstate.ivec = last block of C1 608 cryptosystem from simplified profile 609 --------------------------------------------------------------------------------- 610 decryption function P1 = D(Ke, C1, oldstate.ivec) 611 if (H1 != HMAC(Ki, P1)) report error 612 newstate.ivec = last block of C1 614 default string-to-key As given. 615 params 617 key generation functions: 619 string-to-key function As given. 621 random-to-key function As given. 623 key-derivation function The "well-known constant" used for the DK function is 624 the key usage number, expressed as four octets in big- 625 endian order, followed by one octet indicated below. 627 Kc = DK(base-key, usage | 0x99); 628 Ke = DK(base-key, usage | 0xAA); 629 Ki = DK(base-key, usage | 0x55); 631 4.4. Checksum profiles based on simplified profile 633 When an encryption system is defined using the simplified profile 634 given in section 4.2, a checksum algorithm may be defined for it as 635 follows: 637 checksum mechanism from simplified profile 638 ---------------------------------------------- 639 associated cryptosystem as defined above 641 get_mic HMAC(Kc, message) 643 verify_mic get_mic and compare 645 The HMAC function and key Kc are as described in section 4.3. 647 5. Profiles for Kerberos encryption systems 649 These are the currently defined encryption systems for Kerberos. The 650 astute reader will notice that some of them do not fulfill all of the 651 requirements outlined above. These weaker encryption systems are 652 defined for backwards compatibility; newer implementations should 653 attempt to make use of the stronger encryption systems when possible. 655 The full list of current encryption type number assignments is given 656 in section 8. 658 5.1. null 660 If no encryption is in use, the encryption system is said to be the 661 NULL encryption system. In the NULL encryption system there is no 662 checksum, confounder or padding. The ciphertext is simply the 663 plaintext. The null Key is used by the null encryption system and is 664 zero octets in length. 666 This encryption system should not be used for protection of data. It 667 exists primarily to associate with the rsa-md5 checksum type, but may 668 also be useful for testing protocol implementations. 670 null 671 ------------------------------------------------ 672 protocol key format zero-length bit string 674 specific key structure empty 676 required checksum rsa-md5 677 mechanism 679 key-generation seed 0 680 length 682 cipher state none 684 initial cipher state none 686 encryption function identity 688 decryption function identity, no integrity 689 check 691 default string-to-key none 692 params 693 null 694 ------------------------------------------------ 695 key generation functions: 697 string-to-key empty string 699 random-to-key empty string 701 key-derivation empty string 703 The null encryption algorithm is assigned the etype value zero (0). 705 5.2. DES-based encryption systems 707 These encryption systems encrypt information under the Data 708 Encryption Standard [DES77] using the cipher block chaining mode 709 [DESM80]. A checksum is computed as described below and placed in 710 the cksum field. DES blocks are 8 bytes. As a result, the data to 711 be encrypted (the concatenation of confounder, checksum, and message) 712 must be padded to an 8 byte boundary before encryption. The values 713 of the padding bytes are unspecified. 715 Plaintext and DES ciphertext are encoded as blocks of 8 octets which 716 are concatenated to make the 64-bit inputs for the DES algorithms. 717 The first octet supplies the 8 most significant bits (with the 718 octet's MSB used as the DES input block's MSB, etc.), the second 719 octet the next 8 bits, ..., and the eighth octet supplies the 8 least 720 significant bits. 722 Encryption under DES using cipher block chaining requires an 723 additional input in the form of an initialization vector; this vector 724 is specified for each encryption system, below. 726 The DES specifications identify some 'weak' and 'semi-weak' keys; 727 those keys shall not be used for encrypting messages for use in 728 Kerberos. Additionally, because of the way that keys are derived for 729 the encryption of checksums, keys shall not be used that yield 'weak' 730 or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant 731 0xF0F0F0F0F0F0F0F0. 733 A DES key is 8 octets of data. This consists of 56 bits of actual 734 key data, and 8 parity bits, one per octet. The key is encoded as a 735 series of 8 octets written in MSB-first order. The bits within the 736 key are also encoded in MSB order. For example, if the encryption 737 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 738 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 739 are the parity bits, the first octet of the key would be 740 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the 741 [DESM80] introduction for reference. 743 Encryption data format 745 The format for the data to be encrypted includes a one-block 746 confounder, a checksum, the encoded plaintext, and any necessary 747 padding, as described in the following diagram. The msg-seq field 748 contains the part of the protocol message which is to be encrypted. 750 +-----------+----------+---------+-----+ 751 |confounder | checksum | msg-seq | pad | 752 +-----------+----------+---------+-----+ 754 One generates a random confounder of one block, placing it in 755 confounder; zeroes out the checksum field (of length appropriate to 756 exactly hold the checksum to be computed); calculates the appropriate 757 checksum over the whole sequence, placing the result in check; adds 758 the necessary padding; then encrypts using the specified encryption 759 type and the appropriate key. 761 String to key transformation 763 To generate a DES key from a UTF-8 text string (password), a "salt" 764 is concatenated to the text string, and then padded with zero-valued 765 octets to a multiple of 8 octets. 767 This string is then fan-folded and eXclusive-ORed with itself to form 768 an 8 byte DES key. Before eXclusive-ORing a block, every byte is 769 shifted one bit to the left to leave the lowest bit zero. The key is 770 the "corrected" by correcting the parity on the key, and if the key 771 matches a 'weak' or 'semi-weak' key as described in the DES 772 specification, it is eXclusive-ORed with the constant 773 0x00000000000000F0. This key is then used to generate a DES CBC 774 checksum on the initial string with the salt appended. The result of 775 the CBC checksum is the "corrected" as described above to form the 776 result which is returned as the key. 778 Pseudocode follows: 780 key_correction(key) { 781 fixparity(key); 782 if (is_weak_key_key(key)) 783 key = key XOR 0xF0; 784 return(key); 785 } 786 mit_des_string_to_key(string,salt) { 787 odd = 1; 788 s = string | salt; 789 tempkey = NULL; 790 pad(s); /* with nulls to 8 byte boundary */ 791 for (8byteblock in s) { 792 if (odd == 0) { 793 odd = 1; 794 reverse(8byteblock) 795 } 796 else odd = 0; 797 left shift every byte in 8byteblock one bit; 798 tempkey = tempkey XOR 8byteblock; 799 } 800 tempkey = key_correction(tempkey); 801 key = key_correction(DES-CBC-check(s,tempkey)); 802 return(key); 803 } 805 des_string_to_key(string,salt,params) { 806 if (length(params) == 0) 807 type = 0; 808 else if (length(params) == 1) 809 type = params[0]; 810 else 811 error("invalid params"); 812 if (type == 0) 813 mit_des_string_to_key(string,salt); 814 else if (type == 1) 815 afs_des_string_to_key(string,salt); 816 else 817 error("invalid params"); 818 } 820 The AFS string-to-key algorithm is not defined here, but a parameter 821 block containing a byte value of one (1) is reserved for its use. 823 5.2.1. DES with MD5 825 The des-cbc-md5 encryption mode encrypts information under DES in CBC 826 mode with an all-zero initial vector, with an MD5 checksum (described 827 in [MD5-92]) computed and placed in the checksum field. 829 The encryption system parameters for des-cbc-md5 are: 831 des-cbc-md5 832 -------------------------------------------------------------------- 833 protocol key format 8 bytes, parity in low bit of each 835 specific key structure copy of original key 837 required checksum rsa-md5-des 838 mechanism 840 key-generation seed 8 bytes 841 length 843 cipher state 8 bytes (CBC initial vector) 845 initial cipher state all-zero 847 encryption function des-cbc(confounder | checksum | msg | pad, 848 ivec=oldstate) 849 where 850 checksum = md5(confounder | 0000... 851 | msg | pad) 853 newstate = last block of des-cbc output 855 decryption function decrypt encrypted text and verify checksum 857 newstate = last block of ciphertext 859 default string-to-key empty string 860 params 862 key generation functions: 864 string-to-key des_string_to_key 866 random-to-key copy input, then fix parity bits (discards 867 low bit of each input byte) 869 key-derivation identity 871 The des-cbc-md5 encryption type is assigned the etype value three 872 (3). 874 5.2.2. DES with MD4 876 The des-cbc-md4 encryption mode also encrypts information under DES 877 in CBC mode, with an all-zero initial vector. An MD4 checksum 878 (described in [MD4-92]) is computed and placed in the checksum field. 880 des-cbc-md4 881 -------------------------------------------------------------------- 882 protocol key format 8 bytes, parity in low bit of each 884 specific key structure copy of original key 886 required checksum rsa-md4-des 887 mechanism 889 key-generation seed 8 bytes 890 length 892 cipher state 8 bytes (CBC initial vector) 894 initial cipher state all-zero 896 encryption function des-cbc(confounder | checksum | msg | pad, 897 ivec=oldstate) 898 where 899 checksum = md4(confounder | 0000... 900 | msg | pad) 902 newstate = last block of des-cbc output 904 decryption function decrypt encrypted text and verify checksum 906 newstate = last block of ciphertext 908 default string-to-key empty string 909 params 911 key generation functions: 913 string-to-key des_string_to_key 915 random-to-key copy input, then fix parity bits 917 key-derivation identity 919 The des-cbc-md4 encryption algorithm is assigned the etype value two 920 (2). 922 5.2.3. DES with CRC 924 The des-cbc-crc encryption type uses DES in CBC mode, with a 4-octet 925 CRC-based checksum computed as described in section 6.2. Note that 926 this is not a standard CRC-32 checksum, but a slightly modified one. 928 Unless otherwise specified, the key should be used as the 929 initialization vector, unlike for the other Kerberos DES encryption 930 schemes. The other details of the encryption of this data are 931 identical to those for the des-cbc-md5 encryption mode. 933 des-cbc-crc 934 -------------------------------------------------------------------- 935 protocol key format 8 bytes, parity in low bit of each 937 specific key structure copy of original key 939 required checksum rsa-md5-des 940 mechanism 942 key-generation seed 8 bytes 943 length 945 cipher state 8 bytes (CBC initial vector) 947 initial cipher state copy of original key 949 encryption function des-cbc(confounder | checksum | msg | pad, 950 ivec=oldstate) 951 where 952 checksum = crc(confounder | 00000000 953 | msg | pad) 955 newstate = last block of des-cbc output 957 decryption function decrypt encrypted text and verify checksum 959 newstate = last block of ciphertext 961 default string-to-key empty string 962 params 964 key generation functions: 966 string-to-key des_string_to_key 968 random-to-key copy input, then fix parity bits 969 des-cbc-crc 970 -------------------------------------------------------------------- 972 key-derivation identity 974 The des-cbc-crc encryption algorithm is assigned the etype value one 975 (1). 977 5.3. Triple-DES Encryption with Key Derivation 979 This encryption type is based on the Triple DES cryptosystem in 980 Outer-CBC mode, and the HMAC-SHA1 message authentication algorithm. 982 A Triple DES key is the concatenation of three DES keys as described 983 above for des-cbc-md5. A Triple DES key is generated from random 984 data by creating three DES keys from separate sequences of random 985 data. 987 Encrypted data using this type must be generated as described in 988 section 4.3. If the length of the input data is not a multiple of 989 the block size, zero octets must be used to pad the plaintext to the 990 next eight-octet boundary. The confounder must be eight random 991 octets (one block). 993 The simplified profile for Triple DES, with key derivation as defined 994 in section 4, is as follows: 996 des3-cbc-hmac-sha1-kd 997 ------------------------------------------------ 998 protocol key format 24 bytes, parity in low 999 bit of each 1001 key-generation seed 21 bytes 1002 length 1004 hash function SHA-1 1006 block size 8 bytes 1008 default string-to-key none 1009 params 1011 encryption and triple-DES encrypt and 1012 decryption functions decrypt, in outer-CBC 1013 mode 1015 des3-cbc-hmac-sha1-kd 1016 ------------------------------------------------ 1017 key generation functions: 1019 random-to-key see below 1021 string-to-key DES3string-to-key (see 1022 below) 1024 The des3-cbc-hmac-sha1-kd encryption type is assigned the value 1025 sixteen (16). 1027 5.3.1. Triple DES Key Production (random-to-key, string-to-key) 1029 The 168 bits of random key data are converted to a protocol key value 1030 as follows. First, the 168 bits are divided into three groups of 56 1031 bits, which are expanded individually into 64 bits as follows: 1033 1 2 3 4 5 6 7 p 1034 9 10 11 12 13 14 15 p 1035 17 18 19 20 21 22 23 p 1036 25 26 27 28 29 30 31 p 1037 33 34 35 36 37 38 39 p 1038 41 42 43 44 45 46 47 p 1039 49 50 51 52 53 54 55 p 1040 56 48 40 32 24 16 8 p 1042 The "p" bits are parity bits computed over the data bits. The output 1043 of the three expansions are concatenated to form the protocol key 1044 value. 1046 When the HMAC-SHA1 of a string is computed, the key is used in the 1047 protocol key form. 1049 The string-to-key function is used to transform UTF-8 passwords into 1050 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 1051 algorithm and DK function, described in section 4. 1053 The n-fold algorithm is applied to the password string concatenated 1054 with a salt value. For 3-key triple DES, the operation will involve 1055 a 168-fold of the input password string, to generate an intermediate 1056 key, from which the user's long-term key will be derived with the DK 1057 function. The DES3 string-to-key function is shown here in 1058 pseudocode: 1060 DES3string-to-key(passwordString, salt, params) 1061 if (params != emptyString) 1062 error("invalid params"); 1063 s = passwordString + salt 1064 tmpKey = random-to-key(168-fold(s)) 1065 key = DK (tmpKey, KerberosConstant) 1067 No weak-key checking is performed. The KerberosConstant value is the 1068 byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values 1069 correspond to the ASCII encoding for the string "kerberos". 1071 6. Profiles for Kerberos checksums 1073 These are the checksum types currently defined for Kerberos. The 1074 full list of current checksum type number assignments is given in 1075 section 8. 1077 6.1. RSA MD4- and MD5-Based Checksums 1079 6.1.1. RSA MD4 Cryptographic Checksum Using DES 1081 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum 1082 by prepending an 8 octet confounder before the text, applying the RSA 1083 MD4 checksum algorithm [MD4-92], and encrypting the confounder and 1084 the checksum using DES in cipher-block-chaining (CBC) mode using a 1085 variant of the key, where the variant is computed by eXclusive-ORing 1086 the key with the constant 0xF0F0F0F0F0F0F0F0. [5] The initialization 1087 vector should be zero. The resulting checksum is 24 octets long. 1088 This checksum is tamper-proof and believed to be collision-proof. 1090 The DES specifications identify some weak keys' and 'semi-weak keys'; 1091 those keys shall not be used for generating RSA-MD4 checksums for use 1092 in Kerberos. 1094 rsa-md4-des 1095 ---------------------------------------------------------------- 1096 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1098 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1099 conf | rsa-md4(conf | msg), 1100 ivec=0) 1102 verify_mic decrypt and verify rsa-md4 checksum 1104 The rsa-md4-des checksum algorithm is assigned a checksum type number 1105 of three (3). 1107 6.1.2. The RSA MD5 Checksum 1109 The RSA-MD5 checksum calculates a checksum using the RSA MD5 1110 algorithm [MD5-92]. The algorithm takes as input an input message of 1111 arbitrary length and produces as output a 128-bit (16 octet) 1112 checksum. RSA-MD5 is believed to be collision-proof. However, since 1113 it is unkeyed, it must be used with caution. Currently it is used by 1114 some implementations in places where the checksum itself is part of a 1115 larger message that will be encrypted. Its use is not recommended. 1117 rsa-md5 1118 ---------------------------------------------- 1119 associated cryptosystem null 1121 get_mic rsa-md5(msg) 1123 verify_mic get_mic and compare 1125 The rsa-md5 checksum algorithm is assigned a checksum type number of 1126 seven (7). 1128 6.1.3. RSA MD5 Cryptographic Checksum Using DES 1130 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum 1131 by prepending an 8 octet confounder before the text, applying the RSA 1132 MD5 checksum algorithm, and encrypting the confounder and the 1133 checksum using DES in cipher-block-chaining (CBC) mode using a 1134 variant of the key, where the variant is computed by eXclusive-ORing 1135 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The 1136 initialization vector should be zero. The resulting checksum is 24 1137 octets long. This checksum is tamper-proof and believed to be 1138 collision-proof. 1140 The DES specifications identify some 'weak keys' and 'semi-weak 1141 keys'; those keys shall not be used for encrypting RSA-MD5 checksums 1142 for use in Kerberos. 1144 rsa-md5-des 1145 ---------------------------------------------------------------- 1146 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1148 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1149 conf | rsa-md5(conf | msg)) 1151 verify_mic decrypt and verify rsa-md5 checksum 1152 rsa-md5-des 1153 ---------------------------------------------------------------- 1155 The rsa-md5-des checksum algorithm is assigned a checksum type number 1156 of eight (8). 1158 6.1.4. The RSA MD4 Checksum 1160 The RSA-MD4 checksum calculates a checksum using the RSA MD4 1161 algorithm [MD4-92]. The algorithm takes as input an input message of 1162 arbitrary length and produces as output a 128-bit (16 octet) 1163 checksum. RSA-MD4 is believed to be collision-proof. 1165 rsa-md4 1166 ------------------------------------------------ 1167 associated cryptosystem des-cbc-md5, des-cbc- 1168 md4, des-cbc-crc 1170 get_mic md4(msg) 1172 verify_mic compute checksum and 1173 compare 1175 The rsa-md4 checksum algorithm is assigned a checksum type number of 1176 two (2). 1178 6.1.5. RSA MD4 Cryptographic Checksum Using DES alternative 1180 The RSA-MD4-DES-K checksum calculates a keyed collision-proof 1181 checksum by applying the RSA MD4 checksum algorithm and encrypting 1182 the results using DES in cipher block chaining (CBC) mode using a DES 1183 key as both key and initialization vector. The resulting checksum is 1184 16 octets long. This checksum is tamper-proof and believed to be 1185 collision-proof. Note that this checksum type is the old method for 1186 encoding the RSA-MD4-DES checksum and it is no longer recommended. 1188 rsa-md4-des-k 1189 ---------------------------------------------------------------- 1190 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1192 get_mic des-cbc(key, md4(msg), ivec=key) 1194 verify_mic decrypt, compute checksum and compare 1196 The rsa-md4-des-k checksum algorithm is assigned a checksum type 1197 number of six (6). 1199 6.2. CRC-32 Checksum 1201 This CRC-32 checksum calculates a checksum based on a cyclic 1202 redundancy check as described in ISO 3309 [CRC], modified as 1203 described below. The resulting checksum is four (4) octets in 1204 length. The CRC-32 is neither keyed nor collision-proof; thus, the 1205 use of this checksum is not recommended. An attacker using a 1206 probabilistic chosen-plaintext attack as described in [SG92] might be 1207 able to generate an alternative message that satisfies the checksum. 1208 The use of collision-proof checksums is recommended for environments 1209 where such attacks represent a significant threat. 1211 The CRC-32 checksum used in the des-cbc-crc encryption mode is 1212 identical to the 32-bit FCS described in ISO 3309 with two 1213 exceptions: the sum with the all-ones polynomial times x**k is 1214 omitted, and the final remainder is not ones-complemented. ISO 3309 1215 describes the FCS in terms of bits, while this document describes the 1216 Kerberos protocol in terms of octets. To disambiguate the ISO 3309 1217 definition for the purpose of computing the CRC-32 in the des-cbc-crc 1218 encryption mode, the ordering of bits in each octet shall be assumed 1219 to be LSB-first. Given this assumed ordering of bits within an 1220 octet, the mapping of bits to polynomial coefficients shall be 1221 identical to that specified in ISO 3309. 1223 crc32 1224 ------------------------------------------------ 1225 associated cryptosystem des-cbc-md5, des-cbc- 1226 md4, des-cbc-crc 1228 get_mic crc32(msg) 1230 verify_mic compute checksum and 1231 compare 1233 The crc32 checksum algorithm is assigned a checksum type number of 1234 one (1). 1236 6.3. DES MAC checksums 1238 6.3.1. DES CBC checksum 1240 The DES-MAC checksum is computed by prepending an 8 octet confounder 1241 to the plaintext, performing a DES CBC-mode encryption on the result 1242 using the key and an initialization vector of zero, taking the last 1243 block of the ciphertext, prepending the same confounder and 1244 encrypting the pair using DES in cipher-block-chaining (CBC) mode 1245 using a a variant of the key, where the variant is computed by 1246 eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The 1247 initialization vector should be zero. The resulting checksum is 128 1248 bits (16 octets) long, 64 bits of which are redundant. This checksum 1249 is tamper-proof and collision-proof. 1251 The DES specifications identify some "weak" and "semiweak" keys; 1252 those keys shall not be used for generating DES-MAC checksums for use 1253 in Kerberos, nor shall a key be used whose variant is "weak" or 1254 "semi-weak". 1256 des-mac 1257 ---------------------------------------------------------------- 1258 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 1259 cryptosystem 1261 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1262 conf | des-mac(key, conf | msg, ivec=0), 1263 ivec=0) 1265 verify_mic decrypt, compute DES MAC using confounder, 1266 compare 1268 The des-mac checksum algorithm is assigned a checksum type number of 1269 four (4). 1271 6.3.2. DES CBC checksum alternative 1273 The DES-MAC-K checksum is computed by performing a DES CBC-mode 1274 encryption of the plaintext, and using the last block of the 1275 ciphertext as the checksum value. It is keyed with an encryption key 1276 and an initialization vector; any uses which do not specify an 1277 additional initialization vector will use the key as both key and 1278 initialization vector. The resulting checksum is 64 bits (8 octets) 1279 long. This checksum is tamper-proof and collision-proof. Note that 1280 this checksum type is the old method for encoding the DESMAC checksum 1281 and it is no longer recommended. 1283 The DES specifications identify some "weak keys"; those keys shall 1284 not be used for generating DES-MAC checksums for use in Kerberos. 1286 des-mac-k 1287 ---------------------------------------------------------------- 1288 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1290 get_mic des-mac(key, msg, ivec=key or given) 1292 verify_mic compute MAC and compare 1294 The des-mac-k checksum algorithm is assigned a checksum type number 1295 of five (5). 1297 6.4. HMAC-SHA1-DES3-KD Checksum 1299 This checksum type is defined as outlined in section 4.2 above, using 1300 the des3-hmac-sha1-kd encryption algorithm parameters from section 1301 5.3. The checksum is thus a SHA-1 HMAC using the computed key Kc 1302 over the message to be protected. 1304 The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type 1305 number of twelve (12). 1307 7. Use of Kerberos encryption outside this specification 1309 Several Kerberos-based application protocols and preauthentication 1310 systems have been designed and deployed that perform encryption and 1311 message integrity checks in various ways. While in some cases there 1312 may be good reason for specifying these protocols in terms of 1313 specific encryption or checksum algorithms, we anticipate that in 1314 many cases this will not be true, and more generic approaches 1315 independent of particular algorithms will be desirable. Rather than 1316 having each protocol designer reinvent schemes for protecting data, 1317 using multiple keys, etc, we have attempted to present in this 1318 section a general framework that should be sufficient not only for 1319 the Kerberos protocol itself but also for many preauthentication 1320 systems and application protocols, while trying to avoid some of the 1321 assumptions that can work their way into such protocol designs. 1323 Some problematic assumptions we've seen (and sometimes made) include: 1324 that a random bitstring is always valid as a key (not true for DES 1325 keys with parity); that the basic block encryption chaining mode 1326 provides no integrity checking, or can easily be separated from such 1327 checking (not true for many modes in development that do both 1328 simultaneously); that a checksum for a message always results in the 1329 same value (not true if a confounder is incorporated); that an 1330 initial vector is used (may not be true if a block cipher in CBC mode 1331 is not in use). 1333 Such assumptions, while they may hold for any given set of encryption 1334 and checksum algorithms, may not be true of the next algorithms to be 1335 defined, leaving the application protocol unable to make use of those 1336 algorithms without updates to its specification. 1338 The Kerberos protocol uses only the attributes and operations 1339 described in sections 2 and 3. Preauthentication systems and 1340 application protocols making use of Kerberos are encouraged to use 1341 them as well. The specific key and string-to-key parameters should 1342 generally be treated as opaque. While the string-to-key parameters 1343 are manipulated as an octet string, the representation for the 1344 specific key structure is implementation-defined; it may not even be 1345 a single object. 1347 While we don't recommend it, some application protocols will 1348 undoubtedly continue to use the key data directly, even if only in 1349 some of the currently existing protocol specifications. An 1350 implementation intended to support general Kerberos applications may 1351 therefore need to make the key data available, as well as the 1352 attributes and operations described in sections 2 and 3. [6] 1354 8. Assigned Numbers 1356 The following encryption type numbers are already assigned or 1357 reserved for use in Kerberos and related protocols. 1359 Encryption type etype block minimum confounder section 1360 value size pad size size 1361 ---------------------------------------------------------------------- 1362 NULL 0 1 0 0 5.1 1363 des-cbc-crc 1 8 4 8 5.2.3 1364 des-cbc-md4 2 8 0 8 5.2.2 1365 des-cbc-md5 3 8 0 8 5.2.1 1366 des3-cbc-sha1-kd 16 8 0 8 5.3 1368 Other numbers have been reserved for use in encryption systems not 1369 defined here. Encryption type numbers are unfortunately overloaded 1370 on occasion in Kerberos-related protocols, so some of the reserved 1371 numbers do not and will not correspond to encryption systems fitting 1372 the profile presented here. 1374 Encryption type etype value comment 1375 ---------------------------------------------------------------------- 1376 [reserved] 4 1377 des3-cbc-md5 5 1378 [reserved] 6 1379 des3-cbc-sha1 7 1380 dsaWithSHA1-CmsOID 9 (pkinit) 1381 md5WithRSAEncryption-CmsOID 10 (pkinit) 1382 sha1WithRSAEncryption-CmsOID 11 (pkinit) 1383 rc2CBC-EnvOID 12 (pkinit) 1384 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 1385 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 1386 des-ede3-cbc-Env-OID 15 (pkinit) 1387 rc4-hmac 23 (swift) 1388 rc4-hmac-exp 24 (swift) 1389 subkey-keynaterial 65 (opaque mhur) 1391 The following checksum type numbers are assigned or reserved. As 1392 with encryption type numbers, some overloading of checksum numbers 1393 has occurred. 1395 Checksum type sumtype checksum section 1396 value size 1397 ---------------------------------------------------------------------- 1398 CRC32 1 4 6.2 1399 rsa-md4 2 16 6.1.4 1400 rsa-md4-des 3 24 6.1.1 1401 des-mac 4 16 6.3.1 1402 des-mac-k 5 8 6.3.2 1403 rsa-md4-des-k 6 16 6.1.5 1404 rsa-md5 7 16 6.1.2 1405 rsa-md5-des 8 24 6.1.3 1406 rsa-md5-des3 9 24 1407 hmac-sha1-des3-kd 12 20 6.4 1408 hmac-sha1-des3 13 20 1409 sha1 (unkeyed) 14 20 1410 [reserved] 0x8003 ? [GSS-KRB5] 1412 Management of these assignments is not being delegated to IANA at 1413 this time. 1415 9. Implementation Notes 1417 The "interface" described here is the minimal information that must 1418 be defined to make a cryptosystem useful within Kerberos in an 1419 interoperable fashion. It is not an attempt to define a complete API 1420 for cryptographic functionality within Kerberos. Actual 1421 implementations providing clean APIs will probably find it useful to 1422 make additional information available, which should be possible to 1423 derive from a specification written to the framework given here. For 1424 example, an application designer may wish to determine the largest 1425 number of bytes that can be encrypted without overflowing a certain 1426 size output buffer, or conversely, the maximum number of bytes that 1427 might be obtained by decrypting a given ciphertext message. (In 1428 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] 1429 will require some of these.) 1431 The presence of a mechanism in this document should not be taken as 1432 an indication that it must be implemented for compliance with any 1433 specification; required mechanisms will be specified elsewhere. 1434 Indeed, some of the mechanisms described here for backwards 1435 compatibility are now considered rather weak for protecting critical 1436 data. 1438 10. Security Considerations 1440 Recent years have brought advancements in the ability to perform 1441 large-scale attacks against DES, to such a degree that it is not 1442 considered a strong encryption mechanism any longer; triple-DES is 1443 generally preferred in its place, despite the poorer performance. 1444 See [ESP-DES] for a summary of some of the potential attacks, and 1445 [EFF-DES] for a detailed discussion of the implementation of 1446 particular attack. However, most Kerberos implementations still have 1447 DES as their primary interoperable encryption type. 1449 DES has a small number of "weak" and "semiweak" keys, but the use of 1450 triple-DES makes no effort to avoid them. The nature of the weak 1451 keys is such that it is extremely unlikely that they will weaken the 1452 triple-DES encryption -- only slightly more likely than having the 1453 middle of the three sub-keys match one of the other two, which 1454 effectively converts the encryption to single-DES. (Which is another 1455 case we make no effort to avoid.) 1457 The true CRC-32 checksum is not collision-proof; an attacker could 1458 use a probabilistic chosen-plaintext attack to generate a valid 1459 message even if a confounder is used [SG92]. The use of collision- 1460 proof checksums is of course recommended for environments where such 1461 attacks represent a significant threat. The "simplifications" (read: 1462 bugs) introduced when CRC-32 was implemented for Kerberos cause 1463 leading zeros to effectively be ignored, so messages differing only 1464 in leading zero bits will have the same checksum. 1466 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. 1467 Unlike [IPSEC-HMAC], this specification does not use the suggested 1468 truncation of the HMAC output. As pointed out in [IPSEC-HMAC], SHA-1 1469 was not developed to be used as a keyed hash function, which is a 1470 criterion of HMAC. [HMAC-TEST] contains test vectors for HMAC-SHA-1. 1472 The mit_des_string_to_key function was originally constructed with 1473 the assumption that all input would be ASCII; it ignores the top bit 1474 of each input byte. Folding with XOR is also not an especially good 1475 mixing mechanism in terms of preserving randomness. 1477 The n-fold function used in the string-to-key operation for des3-cbc- 1478 hmac-sha1-kd was designed to cause each bit of input to contribute 1479 equally to the output; it was not designed to maximize or equally 1480 distribute randomness in the input, and there are conceivable cases 1481 of partially structured input where randomness may be lost. This 1482 should only be an issue for highly structured passwords, however. 1484 [RFC1851] discusses the relative strength of triple-DES encryption. 1485 The relative slow speed of triple-DES encryption may also be an issue 1486 for some applications. 1488 This document, like the Kerberos protocol, completely ignores the 1489 notion of limiting the amount of data a key may be used with to a 1490 quantity based on the robustness of the algorithm or size of the key. 1491 It is assumed that any defined algorithms and key sizes will be 1492 strong enough to support very large amounts of data, or they will be 1493 deprecated once significant attacks are known. 1495 This document also places no bounds on the amount of data that can be 1496 handled in various operations. In order to avoid denial of service 1497 attacks, implementations will probably want to restrict message sizes 1498 at some higher level. 1500 11. Acknowledgments 1502 This document is an extension of the encryption specification 1503 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much 1504 of the text of the background, concepts, and DES specifications are 1505 drawn directly from that document. 1507 The abstract framework presented in this document was put together by 1508 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, 1509 and Tom Yu, and the details were refined several times based on 1510 comments from John Brezak and others. 1512 Marc Horowitz wrote the original specification of triple-DES and key 1513 derivation in a pair of Internet Drafts (under the names draft- 1514 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which 1515 were later folded into a draft revision of [Kerb1510], from which 1516 this document was later split off. 1518 Tom Yu provided the text describing the modifications to the standard 1519 CRC algorithm as Kerberos implementations actually use it. 1521 Miroslav Jurisic provided information for one of the UTF-8 test cases 1522 for the string-to-key functions. 1524 Marcus Watts and Louis LeVay caught some errors in an earlier draft. 1526 12. Editor's address 1528 Kenneth Raeburn 1529 Massachusetts Institute of Technology 1530 77 Massachusetts Avenue 1531 Cambridge, MA 02139 1532 raeburn@mit.edu 1534 13. Full Copyright Statement 1536 Copyright (C) The Internet Society (2002). All Rights Reserved. 1538 This document and translations of it may be copied and furnished to 1539 others, and derivative works that comment on or otherwise explain it 1540 or assist in its implementation may be prepared, copied, published 1541 and distributed, in whole or in part, without restriction of any 1542 kind, provided that the above copyright notice and this paragraph are 1543 included on all such copies and derivative works. However, this 1544 document itself may not be modified in any way, such as by removing 1545 the copyright notice or references to the Internet Society or other 1546 Internet organizations, except as needed for the purpose of 1547 developing Internet standards in which case the procedures for 1548 copyrights defined in the Internet Standards process must be 1549 followed, or as required to translate it into languages other than 1550 English. 1552 The limited permissions granted above are perpetual and will not be 1553 revoked by the Internet Society or its successors or assigns. 1555 This document and the information contained herein is provided on an 1556 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1557 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1558 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1559 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1560 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1562 A. Test vectors 1564 This section provides test vectors for various functions defined or 1565 described in this document. For convenience, most inputs are ASCII 1566 strings, though some UTF-8 samples are be provided for string-to-key 1567 functions. Keys and other binary data are specified as hexadecimal 1568 strings. 1570 A.1. n-fold 1572 The n-fold function is defined in section 4.1. As noted there, the 1573 sample vector in the original paper defining the algorithm appears to 1574 be incorrect. Here are values provided by Marc Horowitz: 1576 64-fold("012345") = 1577 64-fold(303132333435) = be072631276b1955 1579 56-fold("password") = 1580 56-fold(70617373776f7264) = 78a07b6caf85fa 1582 64-fold("Rough Consensus, and Running Code") = 1583 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 1584 6e696e6720436f6465) = bb6ed30870b7f0e0 1586 168-fold("password") = 1587 168-fold(70617373776f7264) = 1588 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 1590 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 1591 192-fold(4d41535341434856534554545320494e5354495456544520 1592 4f4620544543484e4f4c4f4759) = 1593 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 1595 A.2. mit_des_string_to_key 1597 The function mit_des_string_to_key is defined in section 5.2. We 1598 present here several test values, with some of the intermediate 1599 results. The fourth test demonstrates the use of UTF-8 with three 1600 characters. The last two tests are specifically constructed so as to 1601 trigger the weak-key fixups for the intermediate key produced by fan- 1602 folding; we have no test cases that cause such fixups for the final 1603 key. 1605 UTF-8 encodings used in test vector: 1606 eszett C3 9F s-caron C5 A1 c-acute C4 87 1607 g-clef F0 9D 84 9E 1609 Test vector: 1611 salt: "ATHENA.MIT.EDUraeburn" 1612 415448454e412e4d49542e4544557261656275726e 1613 password: "password" 70617373776f7264 1614 fan-fold result: c01e38688ac86c2e 1615 intermediate key: c11f38688ac86d2f 1616 DES key: cbc22fae235298e3 1618 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 1619 password: "potatoe" 706f7461746f65 1620 fan-fold result: a028944ee63c0416 1621 intermediate key: a129944fe63d0416 1622 DES key: df3d32a74fd92a01 1624 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 1625 password: g-clef f09d849e 1626 fan-fold result: 3c4a262c18fab090 1627 intermediate key: 3d4a262c19fbb091 1628 DES key: 4ffb26bab0cd9413 1630 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1631 415448454e412e4d49542e4544554a757269c5a169c487 1632 password: eszett c39f 1633 fan-fold result: b8f6c40e305afc9e 1634 intermediate key: b9f7c40e315bfd9e 1635 DES key: 62c81a5232b5e69d 1637 salt: "AAAAAAAA" 4141414141414141 1638 password: "11119999" 3131313139393939 1639 fan-fold result: e0e0e0e0f0f0f0f0 1640 intermediate key: e0e0e0e0f1f1f101 1641 DES key: 984054d0f1a73e31 1642 salt: "FFFFAAAA" 4646464641414141 1643 password: "NNNN6666" 4e4e4e4e36363636 1644 fan-fold result: 1e1e1e1e0e0e0e0e 1645 intermediate key: 1f1f1f1f0e0e0efe 1646 DES key: c4bf6b25adf7a4f8 1648 A.3. DES3 DR and DK 1650 These tests show the derived-random and derived-key values for the 1651 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions 1652 defined in section 5.3.1. The input keys were randomly generated; 1653 the usage values are from this specification. 1655 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 1656 usage: 0000000155 1657 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 1658 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 1660 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 1661 usage: 00000001aa 1662 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 1663 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 1665 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 1666 usage: 0000000155 1667 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 1668 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 1670 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 1671 usage: 00000001aa 1672 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 1673 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 1675 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 1676 usage: 6b65726265726f73 1677 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 1678 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 1679 key: b55e983467e551b3e5d0e5b6c80d45769423a873dc62b30e 1680 usage: 636f6d62696e65 1681 DR: 0127398bacc81a2a62bc45f8d4c151bbcdd5cb788a 1682 DK: 0126388aadc81a1f2a62bc45f8d5c19151bacdd5cb798a3e 1684 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 1685 usage: 0000000155 1686 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 1687 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 1689 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 1690 usage: 00000001aa 1691 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 1692 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 1694 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 1695 usage: 0000000155 1696 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 1697 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 1699 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 1700 usage: 00000001aa 1701 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 1702 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 1704 A.4. DES3string_to_key 1706 These are the keys generated for some of the above input strings for 1707 triple-DES with key derivation as defined in section 5.3.1. 1709 salt: "ATHENA.MIT.EDUraeburn" 1710 passwd: "password" 1711 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1713 salt: "WHITEHOUSE.GOVdanny" 1714 passwd: "potatoe" 1715 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 1716 salt: "EXAMPLE.COMbuckaroo" 1717 passwd: "penny" 1718 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 1720 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1721 passwd: eszett 1722 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 1724 salt: "EXAMPLE.COMpianist" 1725 passwd: g-clef 1726 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 1728 A.5. Modified CRC-32 1730 Below are modified-CRC32 values for various ASCII strings. Only the 1731 printable ASCII characters are checksummed, no C-style trailing zero- 1732 valued octet. The 32-bit modified CRC and the sequence of output 1733 bytes as used in Kerberos are shown. (The octet values are separated 1734 here to emphasize that they are octet values and not 32-bit numbers, 1735 which will be the most convenient form for manipulation in some 1736 implementations. The bit and byte order used internally for such a 1737 number is irrelevant; the octet sequence generated is what is 1738 important.) 1740 mod-crc-32("foo") = 33 bc 32 73 1742 mod-crc-32("test0123456789") = d6 88 3e b8 1744 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 1746 mod-crc-32(8000) = 4b 98 83 3b 1748 mod-crc-32(0008) = 32 88 db 0e 1750 mod-crc-32(0080) = 20 83 b8 ed 1752 mod-crc-32(80) = 20 83 b8 ed 1754 mod-crc-32(80000000) = 3b b6 59 ed 1756 mod-crc-32(00000001) = 96 30 07 77 1758 B. Significant Changes from RFC 1510 1760 The encryption and checksum mechanism profiles are new. The old 1761 specification defined a few operations for various mechanisms, but 1762 didn't outline what should be required of new mechanisms in terms of 1763 abstract properties, nor how to ensure that a mechanism specification 1764 is complete enough for interoperability between implementations. The 1765 new profiles do differ from the old specification in a few ways: 1767 Some message definitions in [Kerb1510] could be read as permitting 1768 the initial vector to be specified by the application; the text 1769 was too vague. It is specifically not permitted in this 1770 specification. Some encryption algorithms may not use 1771 initialization vectors, so relying on chosen, secret 1772 initialization vectors for security is unwise. Also, the 1773 prepended confounder in the existing algorithms is roughly 1774 equivalent to a per-message initialization vector that is revealed 1775 in encrypted form. However, carrying state across from one 1776 encryption to another is explicitly permitted through the opaque 1777 "cipher state" object. 1779 The use of key derivation is new. 1781 Several new methods are introduced, including generation of a key 1782 in wire-protocol format from random input data. 1784 The means for influencing the string-to-key algorithm are laid out 1785 more clearly. 1787 other new methods? 1789 Triple-DES support is new. 1791 The des-cbc-crc and CRC descriptions have been updated to align them 1792 with existing implementations. 1794 [Kerb1510] had no indication what character set or encoding might be 1795 used for pass phrases and salts. 1797 In [Kerb1510], key types, encryption algorithms and checksum 1798 algorithms were only loosely associated, and the association was not 1799 well described. In this specification, key types and encryption 1800 algorithms have a one-to-one correspondence, and associations between 1801 encryption and checksum algorithms are described so that checksums 1802 can be computed given negotiated keys, without requiring further 1803 negotiation for checksum types. 1805 C. Document History (delete before publication) 1807 Changes from kerberos-revisions-## to crypto-00 draft: 1809 Collected DES encryption algorithms together under one subsection. 1811 Replaced salt type number with string-to-key parameter octet-string. 1813 Incorporated Tom Yu's description of our "modified" (i.e., broken) 1814 CRC algorithm. 1816 Changes from -00 to -01: 1818 Added "Significant Changes from RFC 1510" and "Document History" 1819 appendixes. 1821 Fixed up some incorrect section number references. 1823 Collected RSA checksum algorithms together under one section, and 1824 likewise for DES MAC checksum algorithms. 1826 Changed DES encryption description to indicate that the trailing 1827 padding is included in the checksum calculation. 1829 Updated introduction. 1831 Dropped combine-keys function. It'll be needed eventually, but this 1832 isn't the best place for it. 1834 Added request for weaknesses, attacks, test vectors in follow-on 1835 documents defining cipher suites, and references on weaknesses for 1836 suites defined here. 1838 We are not assigning the number registrations to IANA at this time. 1840 The get_mic function need not have a fixed size output. (If it is 1841 required, someone remind me why.) The hash function used in the 1842 simplified profile must, on the other hand. 1844 Cipher state description tightened up a bit: Split description into 1845 state and initial-state. Added direction (encrypt vs decrypt) as an 1846 input parameter for initialization, operations performed must be 1847 consistent with that. Cipher state can be used as input to 1848 encrypt/decrypt only once; operations output the new state to be used 1849 next time, if chaining at all. Chaining is required to influence the 1850 output, to detect message stream modifications; previously this was 1851 explicitly not required. 1853 Moved some descriptive text out of tables. 1855 Fixed some speling probelms. 1857 Notes 1859 [1] While Message Authentication Code (MAC) or Message Integrity 1860 Check (MIC) would be more appropriate terms for many of the 1861 uses in this document, we continue to use the term "checksum" 1862 for historical reasons. 1864 [2] In the case of Kerberos, the encrypted objects will generally 1865 be ASN.1 DER encodings, which contain indications of their 1866 length in the first few octets. 1868 [3] As of the time of this writing, some new modes of operation 1869 have been proposed, some of which may permit encryption and 1870 integrity protection simultaneously. After some of these 1871 proposals have been subjected to adequate analysis, we may 1872 wish to formulate a new simplified profile based on one of 1873 them. 1875 [4] It should be noted that the sample vector in Appendix B.2 of 1876 the original paper appears to be incorrect. Two independent 1877 implementations from the specification (one in C by Marc 1878 Horowitz, and another in Scheme by Bill Sommerfeld) agree on 1879 a value different from that in [Blumenthal96]. 1881 [5] A variant of the key is used to limit the use of a key to a 1882 particular function, separating the functions of generating a 1883 checksum from other encryption performed using the session 1884 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it 1885 maintains key parity. The properties of DES precluded the 1886 use of the complement. The same constant is used for similar 1887 purpose in the Message Integrity Check in the Privacy 1888 Enhanced Mail standard. 1890 [6] Perhaps one of the more common reasons for directly 1891 performing encryption is direct control over the negotiation 1892 and to select a "sufficiently strong" encryption algorithm 1893 (whatever that means in the context of a given application). 1894 While Kerberos directly provides no facility for negotiating 1895 encryption types between the application client and server, 1896 there are other means for accomplishing similar goals. For 1897 example, requesting only "strong" session key types from the 1898 KDC, and assuming that the type actually returned by the KDC 1899 will be understood and supported by the application server. 1901 Normative References 1903 @@ NOTE: draft-rfc-editor-rfc2223bis-01 specifies separate "normative 1904 references" and "informative references" sections. This draft has 1905 not yet become an RFC as of the time of this writing. 1907 This section copied from kerberos-revisions draft. Drop the ones we 1908 don't need, add anything new that we do need. Move informational- 1909 only references to the next section. Update old I-D references to 1910 RFCs, or find other sources. 1912 [Bellare98] 1913 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, 1914 "Relations Among Notions of Security for Public-Key Encryption 1915 Schemes". Extended abstract published in Advances in Cryptology- 1916 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 1917 1462, H. Krawcyzk ed., Springer-Verlag, 1998. 1918 [Blumenthal96] 1919 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers", 1920 Proceedings of PRAGOCRYPT '96, 1996. 1921 [CRC] 1922 International Organization for Standardization, "ISO Information 1923 Processing Systems - Data Communication - High-Level Data Link 1924 Control Procedure - Frame Structure," IS 3309, 3rd Edition, 1925 October 1984. 1926 [DES77] 1927 National Bureau of Standards, U.S. Department of Commerce, "Data 1928 Encryption Standard," Federal Information Processing Standards 1929 Publication 46, Washington, DC, 1977. 1930 [DESM80] 1931 National Bureau of Standards, U.S. Department of Commerce, "DES 1932 Modes of Operation," Federal Information Processing Standards 1933 Publication 81, Springfield, VA, December 1980. 1934 [Dolev91] 1935 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 1936 Proceedings of the 23rd Annual Symposium on Theory of Computing, 1937 ACM, 1991. 1938 [HMAC] 1939 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1940 for Message Authentication", RFC 2104, February 1997. 1941 [MD4-92] 1942 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT 1943 Laboratory for Computer Science, April 1992. 1944 [MD5-92] 1945 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT 1946 Laboratory for Computer Science, April 1992. 1948 [RFC2026] 1949 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC 1950 2026, October 1996. 1951 [SG92] 1952 Stubblebine, S., and V. D. Gligor, "On Message Integrity in 1953 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 1954 Research in Security and Privacy, Oakland, California, May 1992. 1956 Informative References 1958 [EFF-DES] 1959 Electronic Frontier Foundation, "Cracking DES: Secrets of 1960 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly 1961 & Associates, Inc., May 1998. 1962 [ESP-DES] 1963 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 1964 With Explicit IV", RFC 2405, November 1998. 1965 [GSS-KRB5] 1966 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964, 1967 June 1996. 1968 [HMAC-TEST] 1969 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 1970 RFC 2202, September 1997. 1971 [IPSEC-HMAC] 1972 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 1973 AH", RFC 2404, November 1998. 1974 [Kerb] 1975 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 1976 Raeburn, "The Kerberos Network Authentication Service (V5)", 1977 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 1978 2002. Work in progress. 1979 [Kerb1510] 1980 Kohl, J., and C. Neuman, "The Kerberos Network Authentication 1981 Service (V5)", RFC 1510, September 1993.