| blob | 9848626cee905717d2d40bd4b3542d59bf046787 |
10 INTERNET DRAFT K. Raeburn
11 Kerberos Working Group MIT
12 Document: draft-ietf-krb-wg-crypto-01.txt May 3, 2002
13 expires November 3, 2002
15 Encryption and Checksum Specifications
16 for Kerberos 5
18 Abstract
20 This document describes a framework for defining encryption and
21 checksum mechanisms for use with the Kerberos protocol [Kerb],
22 defining an abstraction layer between the Kerberos protocol and
23 related protocols, and the actual mechanisms themselves. Several
24 mechanisms are also defined in this document. Some are taken from
25 RFC 1510, modified in form to fit this new framework, and
26 occasionally modified in content when the old specification was
27 incorrect. New mechanisms are presented here as well. This document
28 does NOT indicate which mechanisms may be considered "required to
29 implement" or deprecated.
31 Comments should be sent to the editor, or to the IETF Kerberos
32 working group (ietf-krb-wg@anl.gov).
34 Status
36 This document is an Internet-Draft and is in full conformance with
37 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts
38 are working documents of the Internet Engineering Task Force (IETF),
39 its areas, and its working groups. Note that other groups may also
40 distribute working documents as Internet-Drafts. Internet-Drafts are
41 draft documents valid for a maximum of six months and may be updated,
42 replaced, or obsoleted by other documents at any time. It is
43 inappropriate to use Internet-Drafts as reference material or to cite
44 them other than as "work in progress."
46 The list of current Internet-Drafts can be accessed at
47 http://www.ietf.org/ietf/1id-abstracts.html.
49 The list of Internet-Draft Shadow Directories can be accessed at
50 http://www.ietf.org/shadow.html.
58 Raeburn [Page 1]
59 \f
60 INTERNET DRAFT May 2002
63 Table of Contents
66 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
67 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
68 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
69 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
71 2. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4
72 3. Checksum mechanism attributes . . . . . . . . . . . . . . . . . . 9
73 4. Simplified profile for CBC ciphers with key derivation . . . . . 10
74 4.1. A key derivation function . . . . . . . . . . . . . . . . . . . 10
75 4.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 12
76 4.3. Cryptosystem profile based on simplified profile . . . . . . . 13
77 4.4. Checksum profiles based on simplified profile . . . . . . . . . 14
78 5. Profiles for Kerberos encryption systems . . . . . . . . . . . . 15
79 5.1. null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
80 5.2. DES-based encryption systems . . . . . . . . . . . . . . . . . 16
81 5.3. Triple-DES Encryption with Key Derivation . . . . . . . . . . . 22
82 6. Profiles for Kerberos checksums . . . . . . . . . . . . . . . . . 24
83 6.1. RSA MD4- and MD5-Based Checksums . . . . . . . . . . . . . . . 24
84 6.2. CRC-32 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 27
85 6.3. DES MAC checksums . . . . . . . . . . . . . . . . . . . . . . . 28
86 6.4. HMAC-SHA1-DES3-KD Checksum . . . . . . . . . . . . . . . . . . 29
87 7. Use of Kerberos encryption outside this specification . . . . . . 29
88 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 30
89 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 32
90 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 32
91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 33
92 12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . . 34
93 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34
94 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
95 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
96 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 35
97 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 37
98 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 38
99 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 39
100 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 39
101 C. Document History (delete before publication) . . . . . . . . . . 40
102 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
103 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 43
104 Informative References . . . . . . . . . . . . . . . . . . . . . . . 44
114 Raeburn [Page 2]
115 \f
116 INTERNET DRAFT May 2002
119 Introduction
121 The Kerberos protocols are designed to encrypt messages of arbitrary
122 sizes, using block encryption ciphers, or less commonly, stream
123 encryption ciphers. Encryption is used to prove the identities of
124 the network entities participating in message exchanges. However,
125 nothing in the Kerberos protocol requires any specific encryption
126 algorithm be used, as long as certain operations are available in the
127 algorithm that is used.
129 The following sections specify the encryption and checksum mechanisms
130 currently defined for Kerberos, as well as a framework for defining
131 future mechanisms. The encoding, chaining, padding and other
132 requirements for each are described. Test vectors for several
133 functions are given in appendix A.
135 1. Concepts
137 Both encryption and checksum mechanisms are defined in terms of
138 profiles, detailed in later sections. Each specifies a collection of
139 operations and attributes that must be defined for a mechanism. A
140 Kerberos encryption or checksum mechanism specification is not
141 complete if it does not define all of these operations and
142 attributes.
144 An encryption mechanism must provide for confidentiality and
145 integrity of the original plaintext. (Integrity checking may be
146 achieved by incorporating a checksum, if the encryption mode does not
147 provide an integrity check itself.) It must also provide non-
148 malleability [Bellare98, Dolev91]. Use of a random confounder
149 prepended to the plaintext is recommended. It should not be possible
150 to determine if two ciphertexts correspond to the same plaintext,
151 without knowledge of the key.
153 A checksum mechanism [1] must provide proof of the integrity of the
154 associated message, and must preserve the confidentiality of the
155 message in case it is not sent in the clear. It should be infeasible
156 to find two plaintexts which have the same checksum. It is NOT
157 required that an eavesdropper be unable to determine if two checksums
158 are for the same message; it is assumed that the messages themselves
159 will be visible to any such eavesdropper.
161 Due to advances in cryptography, it is considered unwise by some
162 cryptographers to use the same key for multiple purposes. Since keys
163 are used in performing a number of different functions in Kerberos,
164 it is desirable to use different keys for each of these purposes,
165 even though we start with a single long-term or session key.
170 Raeburn [Page 3]
171 \f
172 INTERNET DRAFT May 2002
175 We do this by enumerating the different uses of keys within Kerberos,
176 and making the "usage number" an input to the encryption or checksum
177 mechanisms; this enumeration is outside the scope of this document.
178 Later sections of this document define simplified profile templates
179 for encryption and checksum mechanisms that use a key derivation
180 function applied to a CBC mode (or similar) cipher and a checksum or
181 hash algorithm.
183 We distinguish the "base key" specified by other documents from the
184 "specific key" to be used for a particular instance of encryption or
185 checksum operations. It is expected but not required that the
186 specific key will be one or more separate keys derived from the
187 original protocol key and the key usage number. The specific key
188 should not be explicitly referenced outside of this document. The
189 typical language used in other documents should be something like,
190 "encrypt this octet string using this key and this usage number";
191 generation of the specific key and cipher state (described in the
192 next section) are implicit. The creation of a new cipher-state
193 object, or the re-use of one from a previous encryption operation,
194 may also be explicit.
196 New protocols defined in terms of the Kerberos encryption and
197 checksum types should use their own key usage values. Key usages are
198 unsigned 32 bit integers; zero is not permitted.
200 All data is assumed to be in the form of strings of octets or 8-bit
201 bytes. Environments with other byte sizes will have to emulate this
202 behavior in order to get correct results.
204 2. Encryption algorithm profile
206 An encryption mechanism profile must define the following attributes
207 and operations. The operations must be defined as functions in the
208 mathematical sense: no additional or implicit inputs (such as
209 Kerberos principal names or message sequence numbers) are permitted.
211 protocol key format
212 This describes what octet string values represent valid keys. For
213 encryption mechanisms that don't have perfectly dense key spaces,
214 this will describe the representation used for encoding keys. It
215 need not describe specific values that are not valid or desirable
216 for use; such values should be avoid by all key generation
217 routines.
219 specific key structure
220 This is not a protocol format at all, but a description of the
221 keying material derived from the chosen key and used to encrypt or
222 decrypt data or compute or verify a checksum. It may, for
226 Raeburn [Page 4]
227 \f
228 INTERNET DRAFT May 2002
231 example, be a single key, a set of keys, or a combination of the
232 original key with additional data. The authors recommend using
233 one or more keys derived from the original key via one-way
234 functions.
236 required checksum mechanism
237 This indicates a checksum mechanism that must be available when
238 this encryption mechanism is used. Since Kerberos has no built in
239 mechanism for negotiating checksum mechanisms, once an encryption
240 mechanism has been decided upon, the corresponding checksum
241 mechanism can simply be used.
243 key-generation seed length, K
244 This is the length of the random bitstring needed to generate a
245 key with the encryption scheme's random-to-key function (described
246 below). This must be a fixed value so that various techniques for
247 producing a random bitstring of a given length may be used with
248 key generation functions.
250 key generation functions
251 Keys must be generated in a number of cases, from different types
252 of inputs. All function specifications must indicate how to
253 generate keys in the proper wire format, and must avoid generation
254 of keys that significantly compromise the confidentiality of
255 encrypted data, if the cryptosystem has such. Entropy from each
256 source should be preserved as much as possible. Many of the
257 inputs, while unknown, may be at least partly predictable (e.g., a
258 password string is likely to be entirely in the ASCII subset and
259 of fairly short length in many environments; a semi-random string
260 may include timestamps); the benefit of such predictability to an
261 attacker must be minimized.
263 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
264 This function generates a key from two UTF-8 strings and an
265 opaque octet string. One of the strings is normally the
266 principal's pass phrase, but is in general merely a secret
267 string. The other string is a "salt" string intended to
268 produce different keys from the same password for different
269 users or realms. While the strings provided will use UTF-8
270 encoding, no specific version of Unicode should be assumed; all
271 valid UTF-8 strings should be allowed.
273 The third argument, the octet string, may be used to pass
274 mechanism-specific parameters in to this function. Since doing
275 so implies knowledge of the specific encryption system, it is
276 intended that generating non-default parameter values be an
277 uncommon operation, and that normal Kerberos applications be
278 able to treat this parameter block as an opaque object supplied
282 Raeburn [Page 5]
283 \f
284 INTERNET DRAFT May 2002
287 by the KDC or defaulted to some mechanism-specific constant
288 value.
290 This should be a one-way function, so that compromising a
291 user's key in one realm does not compromise the user's key in
292 another realm, even if the same password (but a different salt)
293 is used.
295 random-to-key (bitstring[K])->(protocol-key)
296 This function generates a key from a random bit string of a
297 specific size. It may be assumed that all the bits of the
298 input string are equally random, even though the entropy
299 present in the random source may be limited.
301 key-derivation (protocol-key, integer)->(specific-key)
302 In this function, the integer input is the key usage value as
303 described above; the usage values must be assumed to be known
304 to an attacker. The specific-key output value was described in
305 section 1.
307 string-to-key parameter format
308 This describes the format of the block of data that can be passed
309 to the string-to-key function above to configure additional
310 parameters for that function. Along with the mechanism of
311 encoding parameter values, bounds on the allowed parameters should
312 also be described to avoid allowing a spoofed KDC to compromise
313 the user's password. It may be desirable to construct the
314 encoding such that values weakening the resulting key unacceptably
315 cannot be encoded, if practical.
317 Tighter bounds might be permitted by local security policy, or to
318 avoid excess resource consumption; if so, recommended defaults for
319 those bounds should be given in the specification. The
320 description should also outline possible weaknesses that may be
321 caused by not applying bounds checks or other validation to a
322 parameter string received from the network.
324 As emntioned above, this should be considered opaque to most
325 normal applications.
327 default string-to-key parameters (octet string)
328 This default value for the "params" argument to the string-to-key
329 function is to be used when the application protocol (Kerberos or
330 otherwise) does not explicitly set the parameter value. As
331 indicated above, this parameter block should be treated as an
332 opaque object in most cases.
338 Raeburn [Page 6]
339 \f
340 INTERNET DRAFT May 2002
343 cipher state
344 This describes any information that can be carried over from one
345 encryption or decryption operation to the next, for use in
346 conjunction with a given specific key. For example, a block
347 cipher used in CBC mode may put an initial vector of one block in
348 the cipher state.
350 This state must be non-empty, and must influence encryption so as
351 to require that messages be decrypted in the same order they were
352 encrypted, if the cipher state is carried over from one encryption
353 to the next. Distinguishing out-of-order or missing messages from
354 corrupted messages is not required; if desired, this can be done
355 at a higher level by including sequence numbers and not "chaining"
356 the cipher state between encryption operations.
358 The cipher state may not be reused in multiple encryption or
359 decryption operations; these operations all generate a new cipher
360 state that may be used for following operations using the same key
361 and operation.
363 The contents of the cipher state must be treated as opaque outside
364 of encryption system specifications.
366 initial cipher state (specific-key, direction)->(state)
367 This describes the generation of the initial value for the cipher
368 state if it is not being carried over from a previous encryption
369 or decryption operation.
371 This describes any initial state setup needed before encrypting
372 arbitrary amounts of data with a given specific key; the specific
373 key and the direction of operations to be performed (encrypt
374 versus decrypt) must be the only input needed for this
375 initialization.
377 This state should be treated as opaque in any uses outside of an
378 encryption algorithm definition.
380 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
381 degree an application protocol could exercise control over the
382 initial vector used in DES CBC operations. Some existing
383 implementations permit the setting of the initial vector. This
384 new specification does not permit application control of the
385 cipher state (beyond "initialize" and "carry over from previous
386 encryption"), since the form and content of the initial cipher
387 state can vary between encryption systems, and may not always be a
388 single block of random data.
390 New Kerberos application protocols should not assume that they can
394 Raeburn [Page 7]
395 \f
396 INTERNET DRAFT May 2002
399 control the initial vector, or that one even exists. However, a
400 general-purpose implementation may wish to provide the capability,
401 in case applications explicitly setting it are encountered.
403 encrypt (specific-key, state, octet string)->(state, octet string)
404 This function takes the specific key, cipher state, and plaintext
405 as input, and generates ciphertext and a new cipher state as
406 outputs. If the basic encryption algorithm itself does not
407 provide for integrity protection (as DES in CBC mode does not do),
408 then some form of MAC or checksum must be included that can be
409 verified by the receiver. Some random factor such as a confounder
410 should be included so that an observer cannot know if two messages
411 contain the same plaintext, even if the cipher state and specific
412 keys are the same. The exact length of the plaintext need not be
413 encoded, but if it is not and if padding is required, the padding
414 must be added at the end of the string so that the decrypted
415 version may be parsed from the beginning.
417 The specification of the encryption function must not only
418 indicate the precise contents of the output octet string, but also
419 the output cipher state, if that state is not empty. The
420 application protocol may carry forward the output cipher state
421 from one encryption with a given specific key to another; the
422 effect of this "chaining" must be defined.
424 Assuming correctly-produced values for the specific key and cipher
425 state, no input octet string may result in an error indication.
427 decrypt (specific-key, state, octet string)->(state, octet string)
428 This function takes the specific key, cipher state, and ciphertext
429 as inputs, and verifies the integrity of the supplied ciphertext.
430 If the ciphertext's integrity is intact, this function produces
431 the plaintext and a new cipher state as outputs; otherwise, an
432 error indication must be returned, and the data discarded.
434 The result of the decryption may be longer than the original
435 plaintext, for example if the encryption mode adds padding to
436 reach a multiple of a block size. If this is the case, any extra
437 octets must be after the decoded plaintext. An application
438 protocol which needs to know the exact length of the message must
439 encode a length or recognizable "end of message" marker within the
440 plaintext. [2]
442 As with the encryption function, a correct specification for this
443 function must indicate not only the contents of the output octet
444 string, but also the resulting cipher state.
446 These operations and attributes are all that should be required to
450 Raeburn [Page 8]
451 \f
452 INTERNET DRAFT May 2002
455 support Kerberos and various proposed preauthentication schemes.
457 A document defining a new encryption type should also describe known
458 weaknesses or attacks, so that its security may be fairly assessed,
459 and should include test vectors or other validation procedures for
460 the operations defined. Specific references to information readily
461 available elsewhere are sufficient.
463 3. Checksum mechanism attributes
465 A checksum mechanism profile must define the following attributes and
466 operations:
468 associated encryption algorithm(s)
469 This essentially indicates the type of encryption key this
470 checksum mechanism can be used with. A single checksum mechanism
471 may have more than one associated encryption algorithm if they
472 share the same wire key format, string-to-key function, and key
473 derivation function. (This combination means that, for example, a
474 checksum type and password are adequate to get the specific key
475 used to compute a checksum.)
477 get_mic function
478 This function generates a MIC token for a given specific key (see
479 section 2), and message (represented as an octet string), that may
480 be used to verify the integrity of the associated message. This
481 function is not required to return the same deterministic result
482 on every use; it need only generate a token that the verify_mic
483 routine can check.
485 The output of this function will also dictate the size of the
486 checksum.
488 verify_mic function
489 Given a specific key, message, and MIC token, this function
490 ascertains whether the message integrity has been compromised.
491 For a deterministic get_mic routine, the corresponding verify_mic
492 may simply generate another checksum and compare them.
494 The get_mic and verify_mic operations must be able to handle inputs
495 of arbitrary length; if any padding is needed, the padding scheme
496 must be specified as part of these functions.
498 These operations and attributes are all that should be required to
499 support Kerberos and various proposed preauthentication schemes.
501 As with encryption mechanism definition documents, documents defining
502 new checksum mechanisms should indicate validation processes and
506 Raeburn [Page 9]
507 \f
508 INTERNET DRAFT May 2002
511 known weaknesses.
513 4. Simplified profile for CBC ciphers with key derivation
515 The profile outlines in sections 2 and 3 describes a large number of
516 operations that must be defined for encryption and checksum
517 algorithms to be used with Kerberos. We describe here a simpler
518 profile from which both encryption and checksum mechanism definitions
519 can be generated, filling in uses of key derivation in appropriate
520 places, providing integrity protection, and defining multiple
521 operations for the cryptosystem profile based on a smaller set of
522 operations given in the simplified profile. Not all of the existing
523 cryptosystems for Kerberos fit into this simplified profile, but we
524 recommend that future cryptosystems use it or something based on it.
525 [3]
527 Not all of the operations in the complete profiles are defined
528 through this mechanism; several must still be defined for each new
529 algorithm pair.
531 4.1. A key derivation function
533 Rather than define some scheme by which a "protocol key" is composed
534 of a large number of encryption keys, we use keys derived from a base
535 key to perform cryptographic operations. The base key must be used
536 only for generating the derived keys, and this derivation must be
537 non-invertible and entropy-preserving. Given these restrictions,
538 compromise of one derived key does not compromise the other subkeys.
539 Attack of the base key is limited, since it is only used for
540 derivation, and is not exposed to any user data.
542 Since the derived key has as much entropy as the base keys (if the
543 cryptosystem is good), password-derived keys have the full benefit of
544 all the entropy in the password.
546 To generate a derived key from a base key, we generate a pseudorandom
547 octet string, using an algorithm DR described below, and generate a
548 key from that octet string using a function dependent on the
549 encryption algorithm; the input length needed for that function,
550 which is also dependent on the encryption algorithm, dictates the
551 length of the string to be generated by the DR algorithm (the value
552 "k" below).
554 Derived Key = DK(Base Key, Well-Known Constant)
556 DK(Key, Constant) = random-to-key(DR(Key, Constant))
558 DR(Key, Constant) = k-truncate(E(Key, Constant))
562 Raeburn [Page 10]
563 \f
564 INTERNET DRAFT May 2002
567 Here DR is the random-octet generation function described below, and
568 DK is the key-derivation function produced from it. In this
569 construction, E(Key, Plaintext) is a block cipher, Constant is a
570 well-known constant determined by the specific usage of this
571 function, and k-truncate truncates its argument by taking the first k
572 bits. Here, k is the key generation seed length needed for the
573 encryption system.
575 The output of the DR function is a string of bits; the actual key is
576 produced by applying the cryptosystem's random-to-key operation on
577 this bitstring.
579 If the output of E is shorter than k bits, then some entropy in the
580 key will be lost. If the Constant is smaller than the block size of
581 E, then it must be padded so it may be encrypted.
583 In either of these situations, a variation of the above construction
584 is used, where the folded Constant is encrypted, and the resulting
585 output is fed back into the encryption as necessary (the | indicates
586 concatentation):
588 K1 = E(Key, n-fold(Constant))
589 K2 = E(Key, K1)
590 K3 = E(Key, K2)
591 K4 = ...
593 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
595 n-fold is an algorithm which takes m input bits and ``stretches''
596 them to form n output bits with equal contribution from each input
597 bit to the output, as described in [Blumenthal96]:
599 We first define a primitive called n-folding, which takes a
600 variable-length input block and produces a fixed-length output
601 sequence. The intent is to give each input bit approximately
602 equal weight in determining the value of each output bit. Note
603 that whenever we need to treat a string of octets as a number, the
604 assumed representation is Big-Endian -- Most Significant Byte
605 first.
607 To n-fold a number X, replicate the input value to a length that
608 is the least common multiple of n and the length of X. Before
609 each repetition, the input is rotated to the right by 13 bit
610 positions. The successive n-bit chunks are added together using
611 1's-complement addition (that is, with end-around carry) to yield
612 a n-bit result....
618 Raeburn [Page 11]
619 \f
620 INTERNET DRAFT May 2002
623 Test vectors for n-fold are supplied in Appendix A. [4]
625 In this document, n-fold is always used to produce n bits of output,
626 where n is the block size of E.
628 The size of the Constant must not be larger than the block size of E,
629 because reducing the length of the Constant by n-folding can cause
630 collisions.
632 If the size of the Constant is smaller than the block size of E, then
633 the Constant must be n-folded to the block size of E. This string is
634 used as input to E. If the block size of E is less than the key
635 size, then the output from E is taken as input to a second invocation
636 of E. This process is repeated until the number of bits accumulated
637 is greater than or equal to the key size of E. When enough bits have
638 been computed, the first k are taken as the derived key.
640 Since the derived key is the result of one or more encryptions in the
641 base key, deriving the base key from the derived key is equivalent to
642 determining the key from a very small number of plaintext/ciphertext
643 pairs. Thus, this construction is as strong as the cryptosystem
644 itself.
646 4.2. Simplified profile parameters
648 These are the operations and attributes that must be defined:
650 protocol key format
651 string-to-key function
652 default string-to-key parameters
653 key-generation seed length, k
654 random-to-key function
655 As above for the normal encryption mechanism profile.
657 unkeyed hash algorithm, H
658 This should be a collision-resistant hash algorithm with fixed-
659 size output, suitable for use in an HMAC [HMAC]. It must support
660 inputs of arbitrary length.
662 encryption block size, n
663 encryption/decryption functions, E and D
664 These are basic encryption and decryption functions for messages
665 of sizes that are multiples of the block size. No integrity
666 checking or confounder should be included here. They take as
667 input the IV or similar data, a protocol-format key, and a octet
668 string, returning a new IV and octet string.
670 The encryption function is not required to use CBC mode, but is
674 Raeburn [Page 12]
675 \f
676 INTERNET DRAFT May 2002
679 assumed to be using something with similar properties. In
680 particular, prepending a one-block confounder to the plaintext
681 should alter the entire ciphertext (comparable to choosing and
682 including a random initial vector for CBC mode).
684 While there are still a number of properties to specify, they are
685 fewer and simpler than in the full profile.
687 4.3. Cryptosystem profile based on simplified profile
689 The above key derivation function is used to produce three
690 intermediate keys. One is used for computing checksums of
691 unencrypted data. The other two are used for encrypting and
692 checksumming plaintext to be sent encrypted.
694 The ciphertext output is the concatenation of the output of the basic
695 encryption function E and an HMAC using the specified hash function
696 H, both applied to the plaintext with a one-block random confounder
697 prefix and sufficient padding to bring it to a multiple of the
698 encryption algorithm's block size. Decryption is performed by
699 stripping off the HMAC, decrypting the remainder, and verifying the
700 HMAC. The cipher state is an initial vector, initialized to zero.
703 cryptosystem from simplified profile
704 ---------------------------------------------------------------------------------
705 protocol key format As given.
707 specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
709 key-generation seed As given.
710 length
712 required checksum The checksum mechanism defined by the
713 mechanism simplified checksum profile given later.
715 cipher state CBC initial vector (one block), initialized
716 to all zero.
718 encryption function
719 C1 = E(Ke, conf | plaintext | pad, oldstate.ivec)
720 H1 = HMAC(Ki, conf | plaintext | pad)
721 ciphertext = C1 | H1
722 newstate.ivec = last block of C1
730 Raeburn [Page 13]
731 \f
732 INTERNET DRAFT May 2002
735 cryptosystem from simplified profile
736 ---------------------------------------------------------------------------------
737 decryption function P1 = D(Ke, C1, oldstate.ivec)
738 if (H1 != HMAC(Ki, P1)) report error
739 newstate.ivec = last block of C1
741 default string-to-key As given.
742 params
744 key generation functions:
746 string-to-key function As given.
748 random-to-key function As given.
750 key-derivation function The "well-known constant" used for the DK function is
751 the key usage number, expressed as four octets in big-
752 endian order, followed by one octet indicated below.
754 Kc = DK(base-key, usage | 0x99);
755 Ke = DK(base-key, usage | 0xAA);
756 Ki = DK(base-key, usage | 0x55);
761 4.4. Checksum profiles based on simplified profile
763 When an encryption system is defined using the simplified profile
764 given in section 4.2, a checksum algorithm may be defined for it as
765 follows:
768 checksum mechanism from simplified profile
769 ----------------------------------------------
770 associated cryptosystem as defined above
772 get_mic HMAC(Kc, message)
774 verify_mic get_mic and compare
777 The HMAC function and key Kc are as described in section 4.3.
786 Raeburn [Page 14]
787 \f
788 INTERNET DRAFT May 2002
791 5. Profiles for Kerberos encryption systems
793 These are the currently defined encryption systems for Kerberos. The
794 astute reader will notice that some of them do not fulfill all of the
795 requirements outlined above. These weaker encryption systems are
796 defined for backwards compatibility; newer implementations should
797 attempt to make use of the stronger encryption systems when possible.
799 The full list of current encryption type number assignments is given
800 in section 8.
802 5.1. null
804 If no encryption is in use, the encryption system is said to be the
805 NULL encryption system. In the NULL encryption system there is no
806 checksum, confounder or padding. The ciphertext is simply the
807 plaintext. The null Key is used by the null encryption system and is
808 zero octets in length.
810 This encryption system should not be used for protection of data. It
811 exists primarily to associate with the rsa-md5 checksum type, but may
812 also be useful for testing protocol implementations.
814 null
815 ------------------------------------------------
816 protocol key format zero-length bit string
818 specific key structure empty
820 required checksum rsa-md5
821 mechanism
823 key-generation seed 0
824 length
826 cipher state none
828 initial cipher state none
830 encryption function identity
832 decryption function identity, no integrity
833 check
835 default string-to-key none
836 params
842 Raeburn [Page 15]
843 \f
844 INTERNET DRAFT May 2002
847 null
848 ------------------------------------------------
849 key generation functions:
851 string-to-key empty string
853 random-to-key empty string
855 key-derivation empty string
858 The null encryption algorithm is assigned the etype value zero (0).
860 5.2. DES-based encryption systems
862 These encryption systems encrypt information under the Data
863 Encryption Standard [DES77] using the cipher block chaining mode
864 [DESM80]. A checksum is computed as described below and placed in
865 the cksum field. DES blocks are 8 bytes. As a result, the data to
866 be encrypted (the concatenation of confounder, checksum, and message)
867 must be padded to an 8 byte boundary before encryption. The values
868 of the padding bytes are unspecified.
870 Plaintext and DES ciphertext are encoded as blocks of 8 octets which
871 are concatenated to make the 64-bit inputs for the DES algorithms.
872 The first octet supplies the 8 most significant bits (with the
873 octet's MSB used as the DES input block's MSB, etc.), the second
874 octet the next 8 bits, ..., and the eighth octet supplies the 8 least
875 significant bits.
877 Encryption under DES using cipher block chaining requires an
878 additional input in the form of an initialization vector; this vector
879 is specified for each encryption system, below.
881 The DES specifications identify some 'weak' and 'semi-weak' keys;
882 those keys shall not be used for encrypting messages for use in
883 Kerberos. Additionally, because of the way that keys are derived for
884 the encryption of checksums, keys shall not be used that yield 'weak'
885 or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant
886 0xF0F0F0F0F0F0F0F0.
888 A DES key is 8 octets of data. This consists of 56 bits of actual
889 key data, and 8 parity bits, one per octet. The key is encoded as a
890 series of 8 octets written in MSB-first order. The bits within the
891 key are also encoded in MSB order. For example, if the encryption
892 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
893 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
894 are the parity bits, the first octet of the key would be
898 Raeburn [Page 16]
899 \f
900 INTERNET DRAFT May 2002
903 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the
904 [DESM80] introduction for reference.
906 Encryption data format
908 The format for the data to be encrypted includes a one-block
909 confounder, a checksum, the encoded plaintext, and any necessary
910 padding, as described in the following diagram. The msg-seq field
911 contains the part of the protocol message which is to be encrypted.
913 +-----------+----------+---------+-----+
914 |confounder | checksum | msg-seq | pad |
915 +-----------+----------+---------+-----+
917 One generates a random confounder of one block, placing it in
918 confounder; zeroes out the checksum field (of length appropriate to
919 exactly hold the checksum to be computed); calculates the appropriate
920 checksum over the whole sequence, placing the result in check; adds
921 the necessary padding; then encrypts using the specified encryption
922 type and the appropriate key.
924 String to key transformation
926 To generate a DES key from a UTF-8 text string (password), a "salt"
927 is concatenated to the text string, and then padded with zero-valued
928 octets to a multiple of 8 octets.
930 This string is then fan-folded and eXclusive-ORed with itself to form
931 an 8 byte DES key. Before eXclusive-ORing a block, every byte is
932 shifted one bit to the left to leave the lowest bit zero. The key is
933 the "corrected" by correcting the parity on the key, and if the key
934 matches a 'weak' or 'semi-weak' key as described in the DES
935 specification, it is eXclusive-ORed with the constant
936 0x00000000000000F0. This key is then used to generate a DES CBC
937 checksum on the initial string with the salt appended. The result of
938 the CBC checksum is the "corrected" as described above to form the
939 result which is returned as the key.
941 Pseudocode follows:
943 key_correction(key) {
944 fixparity(key);
945 if (is_weak_key_key(key))
946 key = key XOR 0xF0;
947 return(key);
948 }
954 Raeburn [Page 17]
955 \f
956 INTERNET DRAFT May 2002
959 mit_des_string_to_key(string,salt) {
960 odd = 1;
961 s = string | salt;
962 tempkey = NULL;
963 pad(s); /* with nulls to 8 byte boundary */
964 for (8byteblock in s) {
965 if (odd == 0) {
966 odd = 1;
967 reverse(8byteblock)
968 }
969 else odd = 0;
970 left shift every byte in 8byteblock one bit;
971 tempkey = tempkey XOR 8byteblock;
972 }
973 tempkey = key_correction(tempkey);
974 key = key_correction(DES-CBC-check(s,tempkey));
975 return(key);
976 }
978 des_string_to_key(string,salt,params) {
979 if (length(params) == 0)
980 type = 0;
981 else if (length(params) == 1)
982 type = params[0];
983 else
984 error("invalid params");
985 if (type == 0)
986 mit_des_string_to_key(string,salt);
987 else if (type == 1)
988 afs_des_string_to_key(string,salt);
989 else
990 error("invalid params");
991 }
993 The AFS string-to-key algorithm is not defined here, but a parameter
994 block containing a byte value of one (1) is reserved for its use.
996 5.2.1. DES with MD5
998 The des-cbc-md5 encryption mode encrypts information under DES in CBC
999 mode with an all-zero initial vector, with an MD5 checksum (described
1000 in [MD5-92]) computed and placed in the checksum field.
1010 Raeburn [Page 18]
1011 \f
1012 INTERNET DRAFT May 2002
1015 The encryption system parameters for des-cbc-md5 are:
1017 des-cbc-md5
1018 --------------------------------------------------------------------
1019 protocol key format 8 bytes, parity in low bit of each
1021 specific key structure copy of original key
1023 required checksum rsa-md5-des
1024 mechanism
1026 key-generation seed 8 bytes
1027 length
1029 cipher state 8 bytes (CBC initial vector)
1031 initial cipher state all-zero
1033 encryption function des-cbc(confounder | checksum | msg | pad,
1034 ivec=oldstate)
1035 where
1036 checksum = md5(confounder | 0000...
1037 | msg | pad)
1039 newstate = last block of des-cbc output
1041 decryption function decrypt encrypted text and verify checksum
1043 newstate = last block of ciphertext
1045 default string-to-key empty string
1046 params
1048 key generation functions:
1050 string-to-key des_string_to_key
1052 random-to-key copy input, then fix parity bits (discards
1053 low bit of each input byte)
1055 key-derivation identity
1058 The des-cbc-md5 encryption type is assigned the etype value three
1059 (3).
1066 Raeburn [Page 19]
1067 \f
1068 INTERNET DRAFT May 2002
1071 5.2.2. DES with MD4
1073 The des-cbc-md4 encryption mode also encrypts information under DES
1074 in CBC mode, with an all-zero initial vector. An MD4 checksum
1075 (described in [MD4-92]) is computed and placed in the checksum field.
1077 des-cbc-md4
1078 --------------------------------------------------------------------
1079 protocol key format 8 bytes, parity in low bit of each
1081 specific key structure copy of original key
1083 required checksum rsa-md4-des
1084 mechanism
1086 key-generation seed 8 bytes
1087 length
1089 cipher state 8 bytes (CBC initial vector)
1091 initial cipher state all-zero
1093 encryption function des-cbc(confounder | checksum | msg | pad,
1094 ivec=oldstate)
1095 where
1096 checksum = md4(confounder | 0000...
1097 | msg | pad)
1099 newstate = last block of des-cbc output
1101 decryption function decrypt encrypted text and verify checksum
1103 newstate = last block of ciphertext
1105 default string-to-key empty string
1106 params
1108 key generation functions:
1110 string-to-key des_string_to_key
1112 random-to-key copy input, then fix parity bits
1114 key-derivation identity
1117 The des-cbc-md4 encryption algorithm is assigned the etype value two
1118 (2).
1122 Raeburn [Page 20]
1123 \f
1124 INTERNET DRAFT May 2002
1127 5.2.3. DES with CRC
1129 The des-cbc-crc encryption type uses DES in CBC mode, with a 4-octet
1130 CRC-based checksum computed as described in section 6.2. Note that
1131 this is not a standard CRC-32 checksum, but a slightly modified one.
1133 Unless otherwise specified, the key should be used as the
1134 initialization vector, unlike for the other Kerberos DES encryption
1135 schemes. The other details of the encryption of this data are
1136 identical to those for the des-cbc-md5 encryption mode.
1138 des-cbc-crc
1139 --------------------------------------------------------------------
1140 protocol key format 8 bytes, parity in low bit of each
1142 specific key structure copy of original key
1144 required checksum rsa-md5-des
1145 mechanism
1147 key-generation seed 8 bytes
1148 length
1150 cipher state 8 bytes (CBC initial vector)
1152 initial cipher state copy of original key
1154 encryption function des-cbc(confounder | checksum | msg | pad,
1155 ivec=oldstate)
1156 where
1157 checksum = crc(confounder | 00000000
1158 | msg | pad)
1160 newstate = last block of des-cbc output
1162 decryption function decrypt encrypted text and verify checksum
1164 newstate = last block of ciphertext
1166 default string-to-key empty string
1167 params
1169 key generation functions:
1171 string-to-key des_string_to_key
1173 random-to-key copy input, then fix parity bits
1178 Raeburn [Page 21]
1179 \f
1180 INTERNET DRAFT May 2002
1183 des-cbc-crc
1184 --------------------------------------------------------------------
1186 key-derivation identity
1189 The des-cbc-crc encryption algorithm is assigned the etype value one
1190 (1).
1192 5.3. Triple-DES Encryption with Key Derivation
1194 This encryption type is based on the Triple DES cryptosystem in
1195 Outer-CBC mode, and the HMAC-SHA1 message authentication algorithm.
1197 A Triple DES key is the concatenation of three DES keys as described
1198 above for des-cbc-md5. A Triple DES key is generated from random
1199 data by creating three DES keys from separate sequences of random
1200 data.
1202 Encrypted data using this type must be generated as described in
1203 section 4.3. If the length of the input data is not a multiple of
1204 the block size, zero octets must be used to pad the plaintext to the
1205 next eight-octet boundary. The confounder must be eight random
1206 octets (one block).
1208 The simplified profile for Triple DES, with key derivation as defined
1209 in section 4, is as follows:
1211 des3-cbc-hmac-sha1-kd
1212 ------------------------------------------------
1213 protocol key format 24 bytes, parity in low
1214 bit of each
1216 key-generation seed 21 bytes
1217 length
1219 hash function SHA-1
1221 block size 8 bytes
1223 default string-to-key none
1224 params
1226 encryption and triple-DES encrypt and
1227 decryption functions decrypt, in outer-CBC
1228 mode
1234 Raeburn [Page 22]
1235 \f
1236 INTERNET DRAFT May 2002
1239 des3-cbc-hmac-sha1-kd
1240 ------------------------------------------------
1241 key generation functions:
1243 random-to-key see below
1245 string-to-key DES3string-to-key (see
1246 below)
1249 The des3-cbc-hmac-sha1-kd encryption type is assigned the value
1250 sixteen (16).
1252 5.3.1. Triple DES Key Production (random-to-key, string-to-key)
1254 The 168 bits of random key data are converted to a protocol key value
1255 as follows. First, the 168 bits are divided into three groups of 56
1256 bits, which are expanded individually into 64 bits as follows:
1258 1 2 3 4 5 6 7 p
1259 9 10 11 12 13 14 15 p
1260 17 18 19 20 21 22 23 p
1261 25 26 27 28 29 30 31 p
1262 33 34 35 36 37 38 39 p
1263 41 42 43 44 45 46 47 p
1264 49 50 51 52 53 54 55 p
1265 56 48 40 32 24 16 8 p
1267 The "p" bits are parity bits computed over the data bits. The output
1268 of the three expansions are concatenated to form the protocol key
1269 value.
1271 When the HMAC-SHA1 of a string is computed, the key is used in the
1272 protocol key form.
1274 The string-to-key function is used to transform UTF-8 passwords into
1275 DES3 keys. The DES3 string-to-key function relies on the "N-fold"
1276 algorithm and DK function, described in section 4.
1278 The n-fold algorithm is applied to the password string concatenated
1279 with a salt value. For 3-key triple DES, the operation will involve
1280 a 168-fold of the input password string, to generate an intermediate
1281 key, from which the user's long-term key will be derived with the DK
1282 function. The DES3 string-to-key function is shown here in
1283 pseudocode:
1290 Raeburn [Page 23]
1291 \f
1292 INTERNET DRAFT May 2002
1295 DES3string-to-key(passwordString, salt, params)
1296 if (params != emptyString)
1297 error("invalid params");
1298 s = passwordString + salt
1299 tmpKey = random-to-key(168-fold(s))
1300 key = DK (tmpKey, KerberosConstant)
1302 No weak-key checking is performed. The KerberosConstant value is the
1303 byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values
1304 correspond to the ASCII encoding for the string "kerberos".
1306 6. Profiles for Kerberos checksums
1308 These are the checksum types currently defined for Kerberos. The
1309 full list of current checksum type number assignments is given in
1310 section 8.
1312 6.1. RSA MD4- and MD5-Based Checksums
1314 6.1.1. RSA MD4 Cryptographic Checksum Using DES
1316 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
1317 by prepending an 8 octet confounder before the text, applying the RSA
1318 MD4 checksum algorithm [MD4-92], and encrypting the confounder and
1319 the checksum using DES in cipher-block-chaining (CBC) mode using a
1320 variant of the key, where the variant is computed by eXclusive-ORing
1321 the key with the constant 0xF0F0F0F0F0F0F0F0. [5] The initialization
1322 vector should be zero. The resulting checksum is 24 octets long.
1323 This checksum is tamper-proof and believed to be collision-proof.
1325 The DES specifications identify some weak keys' and 'semi-weak keys';
1326 those keys shall not be used for generating RSA-MD4 checksums for use
1327 in Kerberos.
1329 rsa-md4-des
1330 ----------------------------------------------------------------
1331 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1333 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1334 conf | rsa-md4(conf | msg),
1335 ivec=0)
1337 verify_mic decrypt and verify rsa-md4 checksum
1340 The rsa-md4-des checksum algorithm is assigned a checksum type number
1341 of three (3).
1346 Raeburn [Page 24]
1347 \f
1348 INTERNET DRAFT May 2002
1351 6.1.2. The RSA MD5 Checksum
1353 The RSA-MD5 checksum calculates a checksum using the RSA MD5
1354 algorithm [MD5-92]. The algorithm takes as input an input message of
1355 arbitrary length and produces as output a 128-bit (16 octet)
1356 checksum. RSA-MD5 is believed to be collision-proof. However, since
1357 it is unkeyed, it must be used with caution. Currently it is used by
1358 some implementations in places where the checksum itself is part of a
1359 larger message that will be encrypted. Its use is not recommended.
1361 rsa-md5
1362 ----------------------------------------------
1363 associated cryptosystem null
1365 get_mic rsa-md5(msg)
1367 verify_mic get_mic and compare
1370 The rsa-md5 checksum algorithm is assigned a checksum type number of
1371 seven (7).
1373 6.1.3. RSA MD5 Cryptographic Checksum Using DES
1375 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
1376 by prepending an 8 octet confounder before the text, applying the RSA
1377 MD5 checksum algorithm, and encrypting the confounder and the
1378 checksum using DES in cipher-block-chaining (CBC) mode using a
1379 variant of the key, where the variant is computed by eXclusive-ORing
1380 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The
1381 initialization vector should be zero. The resulting checksum is 24
1382 octets long. This checksum is tamper-proof and believed to be
1383 collision-proof.
1385 The DES specifications identify some 'weak keys' and 'semi-weak
1386 keys'; those keys shall not be used for encrypting RSA-MD5 checksums
1387 for use in Kerberos.
1390 rsa-md5-des
1391 ----------------------------------------------------------------
1392 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1394 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1395 conf | rsa-md5(conf | msg))
1397 verify_mic decrypt and verify rsa-md5 checksum
1402 Raeburn [Page 25]
1403 \f
1404 INTERNET DRAFT May 2002
1407 rsa-md5-des
1408 ----------------------------------------------------------------
1412 The rsa-md5-des checksum algorithm is assigned a checksum type number
1413 of eight (8).
1415 6.1.4. The RSA MD4 Checksum
1417 The RSA-MD4 checksum calculates a checksum using the RSA MD4
1418 algorithm [MD4-92]. The algorithm takes as input an input message of
1419 arbitrary length and produces as output a 128-bit (16 octet)
1420 checksum. RSA-MD4 is believed to be collision-proof.
1423 rsa-md4
1424 ------------------------------------------------
1425 associated cryptosystem des-cbc-md5, des-cbc-
1426 md4, des-cbc-crc
1428 get_mic md4(msg)
1430 verify_mic compute checksum and
1431 compare
1435 The rsa-md4 checksum algorithm is assigned a checksum type number of
1436 two (2).
1438 6.1.5. RSA MD4 Cryptographic Checksum Using DES alternative
1440 The RSA-MD4-DES-K checksum calculates a keyed collision-proof
1441 checksum by applying the RSA MD4 checksum algorithm and encrypting
1442 the results using DES in cipher block chaining (CBC) mode using a DES
1443 key as both key and initialization vector. The resulting checksum is
1444 16 octets long. This checksum is tamper-proof and believed to be
1445 collision-proof. Note that this checksum type is the old method for
1446 encoding the RSA-MD4-DES checksum and it is no longer recommended.
1458 Raeburn [Page 26]
1459 \f
1460 INTERNET DRAFT May 2002
1463 rsa-md4-des-k
1464 ----------------------------------------------------------------
1465 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1467 get_mic des-cbc(key, md4(msg), ivec=key)
1469 verify_mic decrypt, compute checksum and compare
1473 The rsa-md4-des-k checksum algorithm is assigned a checksum type
1474 number of six (6).
1476 6.2. CRC-32 Checksum
1478 This CRC-32 checksum calculates a checksum based on a cyclic
1479 redundancy check as described in ISO 3309 [CRC], modified as
1480 described below. The resulting checksum is four (4) octets in
1481 length. The CRC-32 is neither keyed nor collision-proof; thus, the
1482 use of this checksum is not recommended. An attacker using a
1483 probabilistic chosen-plaintext attack as described in [SG92] might be
1484 able to generate an alternative message that satisfies the checksum.
1485 The use of collision-proof checksums is recommended for environments
1486 where such attacks represent a significant threat.
1488 The CRC-32 checksum used in the des-cbc-crc encryption mode is
1489 identical to the 32-bit FCS described in ISO 3309 with two
1490 exceptions: the sum with the all-ones polynomial times x**k is
1491 omitted, and the final remainder is not ones-complemented. ISO 3309
1492 describes the FCS in terms of bits, while this document describes the
1493 Kerberos protocol in terms of octets. To disambiguate the ISO 3309
1494 definition for the purpose of computing the CRC-32 in the des-cbc-crc
1495 encryption mode, the ordering of bits in each octet shall be assumed
1496 to be LSB-first. Given this assumed ordering of bits within an
1497 octet, the mapping of bits to polynomial coefficients shall be
1498 identical to that specified in ISO 3309.
1501 crc32
1502 ------------------------------------------------
1503 associated cryptosystem des-cbc-md5, des-cbc-
1504 md4, des-cbc-crc
1506 get_mic crc32(msg)
1508 verify_mic compute checksum and
1509 compare
1514 Raeburn [Page 27]
1515 \f
1516 INTERNET DRAFT May 2002
1519 The crc32 checksum algorithm is assigned a checksum type number of
1520 one (1).
1522 6.3. DES MAC checksums
1524 6.3.1. DES CBC checksum
1526 The DES-MAC checksum is computed by prepending an 8 octet confounder
1527 to the plaintext, performing a DES CBC-mode encryption on the result
1528 using the key and an initialization vector of zero, taking the last
1529 block of the ciphertext, prepending the same confounder and
1530 encrypting the pair using DES in cipher-block-chaining (CBC) mode
1531 using a a variant of the key, where the variant is computed by
1532 eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The
1533 initialization vector should be zero. The resulting checksum is 128
1534 bits (16 octets) long, 64 bits of which are redundant. This checksum
1535 is tamper-proof and collision-proof.
1537 The DES specifications identify some "weak" and "semiweak" keys;
1538 those keys shall not be used for generating DES-MAC checksums for use
1539 in Kerberos, nor shall a key be used whose variant is "weak" or
1540 "semi-weak".
1543 des-mac
1544 ----------------------------------------------------------------
1545 associated des-cbc-md5, des-cbc-md4, des-cbc-crc
1546 cryptosystem
1548 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1549 conf | des-mac(key, conf | msg, ivec=0),
1550 ivec=0)
1552 verify_mic decrypt, compute DES MAC using confounder,
1553 compare
1557 The des-mac checksum algorithm is assigned a checksum type number of
1558 four (4).
1560 6.3.2. DES CBC checksum alternative
1562 The DES-MAC-K checksum is computed by performing a DES CBC-mode
1563 encryption of the plaintext, and using the last block of the
1564 ciphertext as the checksum value. It is keyed with an encryption key
1565 and an initialization vector; any uses which do not specify an
1566 additional initialization vector will use the key as both key and
1570 Raeburn [Page 28]
1571 \f
1572 INTERNET DRAFT May 2002
1575 initialization vector. The resulting checksum is 64 bits (8 octets)
1576 long. This checksum is tamper-proof and collision-proof. Note that
1577 this checksum type is the old method for encoding the DESMAC checksum
1578 and it is no longer recommended.
1580 The DES specifications identify some "weak keys"; those keys shall
1581 not be used for generating DES-MAC checksums for use in Kerberos.
1584 des-mac-k
1585 ----------------------------------------------------------------
1586 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1588 get_mic des-mac(key, msg, ivec=key or given)
1590 verify_mic compute MAC and compare
1594 The des-mac-k checksum algorithm is assigned a checksum type number
1595 of five (5).
1597 6.4. HMAC-SHA1-DES3-KD Checksum
1599 This checksum type is defined as outlined in section 4.2 above, using
1600 the des3-hmac-sha1-kd encryption algorithm parameters from section
1601 5.3. The checksum is thus a SHA-1 HMAC using the computed key Kc
1602 over the message to be protected.
1604 The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type
1605 number of twelve (12).
1607 7. Use of Kerberos encryption outside this specification
1609 Several Kerberos-based application protocols and preauthentication
1610 systems have been designed and deployed that perform encryption and
1611 message integrity checks in various ways. While in some cases there
1612 may be good reason for specifying these protocols in terms of
1613 specific encryption or checksum algorithms, we anticipate that in
1614 many cases this will not be true, and more generic approaches
1615 independent of particular algorithms will be desirable. Rather than
1616 having each protocol designer reinvent schemes for protecting data,
1617 using multiple keys, etc, we have attempted to present in this
1618 section a general framework that should be sufficient not only for
1619 the Kerberos protocol itself but also for many preauthentication
1620 systems and application protocols, while trying to avoid some of the
1621 assumptions that can work their way into such protocol designs.
1626 Raeburn [Page 29]
1627 \f
1628 INTERNET DRAFT May 2002
1631 Some problematic assumptions we've seen (and sometimes made) include:
1632 that a random bitstring is always valid as a key (not true for DES
1633 keys with parity); that the basic block encryption chaining mode
1634 provides no integrity checking, or can easily be separated from such
1635 checking (not true for many modes in development that do both
1636 simultaneously); that a checksum for a message always results in the
1637 same value (not true if a confounder is incorporated); that an
1638 initial vector is used (may not be true if a block cipher in CBC mode
1639 is not in use).
1641 Such assumptions, while they may hold for any given set of encryption
1642 and checksum algorithms, may not be true of the next algorithms to be
1643 defined, leaving the application protocol unable to make use of those
1644 algorithms without updates to its specification.
1646 The Kerberos protocol uses only the attributes and operations
1647 described in sections 2 and 3. Preauthentication systems and
1648 application protocols making use of Kerberos are encouraged to use
1649 them as well. The specific key and string-to-key parameters should
1650 generally be treated as opaque. While the string-to-key parameters
1651 are manipulated as an octet string, the representation for the
1652 specific key structure is implementation-defined; it may not even be
1653 a single object.
1655 While we don't recommend it, some application protocols will
1656 undoubtedly continue to use the key data directly, even if only in
1657 some of the currently existing protocol specifications. An
1658 implementation intended to support general Kerberos applications may
1659 therefore need to make the key data available, as well as the
1660 attributes and operations described in sections 2 and 3. [6]
1662 8. Assigned Numbers
1664 The following encryption type numbers are already assigned or
1665 reserved for use in Kerberos and related protocols.
1668 Encryption type etype block minimum confounder section
1669 value size pad size size
1670 ----------------------------------------------------------------------
1671 NULL 0 1 0 0 5.1
1672 des-cbc-crc 1 8 4 8 5.2.3
1673 des-cbc-md4 2 8 0 8 5.2.2
1674 des-cbc-md5 3 8 0 8 5.2.1
1675 des3-cbc-sha1-kd 16 8 0 8 5.3
1678 Other numbers have been reserved for use in encryption systems not
1682 Raeburn [Page 30]
1683 \f
1684 INTERNET DRAFT May 2002
1687 defined here. Encryption type numbers are unfortunately overloaded
1688 on occasion in Kerberos-related protocols, so some of the reserved
1689 numbers do not and will not correspond to encryption systems fitting
1690 the profile presented here.
1693 Encryption type etype value comment
1694 ----------------------------------------------------------------------
1695 [reserved] 4
1696 des3-cbc-md5 5
1697 [reserved] 6
1698 des3-cbc-sha1 7
1699 dsaWithSHA1-CmsOID 9 (pkinit)
1700 md5WithRSAEncryption-CmsOID 10 (pkinit)
1701 sha1WithRSAEncryption-CmsOID 11 (pkinit)
1702 rc2CBC-EnvOID 12 (pkinit)
1703 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
1704 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
1705 des-ede3-cbc-Env-OID 15 (pkinit)
1706 rc4-hmac 23 (swift)
1707 rc4-hmac-exp 24 (swift)
1708 subkey-keynaterial 65 (opaque mhur)
1711 The following checksum type numbers are assigned or reserved. As
1712 with encryption type numbers, some overloading of checksum numbers
1713 has occurred.
1716 Checksum type sumtype checksum section
1717 value size
1718 ----------------------------------------------------------------------
1719 CRC32 1 4 6.2
1720 rsa-md4 2 16 6.1.4
1721 rsa-md4-des 3 24 6.1.1
1722 des-mac 4 16 6.3.1
1723 des-mac-k 5 8 6.3.2
1724 rsa-md4-des-k 6 16 6.1.5
1725 rsa-md5 7 16 6.1.2
1726 rsa-md5-des 8 24 6.1.3
1727 rsa-md5-des3 9 24
1728 hmac-sha1-des3-kd 12 20 6.4
1729 hmac-sha1-des3 13 20
1730 sha1 (unkeyed) 14 20
1731 [reserved] 0x8003 ? [GSS-KRB5]
1734 Management of these assignments is not being delegated to IANA at
1738 Raeburn [Page 31]
1739 \f
1740 INTERNET DRAFT May 2002
1743 this time.
1745 9. Implementation Notes
1747 The "interface" described here is the minimal information that must
1748 be defined to make a cryptosystem useful within Kerberos in an
1749 interoperable fashion. It is not an attempt to define a complete API
1750 for cryptographic functionality within Kerberos. Actual
1751 implementations providing clean APIs will probably find it useful to
1752 make additional information available, which should be possible to
1753 derive from a specification written to the framework given here. For
1754 example, an application designer may wish to determine the largest
1755 number of bytes that can be encrypted without overflowing a certain
1756 size output buffer, or conversely, the maximum number of bytes that
1757 might be obtained by decrypting a given ciphertext message. (In
1758 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
1759 will require some of these.)
1761 The presence of a mechanism in this document should not be taken as
1762 an indication that it must be implemented for compliance with any
1763 specification; required mechanisms will be specified elsewhere.
1764 Indeed, some of the mechanisms described here for backwards
1765 compatibility are now considered rather weak for protecting critical
1766 data.
1768 10. Security Considerations
1770 Recent years have brought advancements in the ability to perform
1771 large-scale attacks against DES, to such a degree that it is not
1772 considered a strong encryption mechanism any longer; triple-DES is
1773 generally preferred in its place, despite the poorer performance.
1774 See [ESP-DES] for a summary of some of the potential attacks, and
1775 [EFF-DES] for a detailed discussion of the implementation of
1776 particular attack. However, most Kerberos implementations still have
1777 DES as their primary interoperable encryption type.
1779 DES has a small number of "weak" and "semiweak" keys, but the use of
1780 triple-DES makes no effort to avoid them. The nature of the weak
1781 keys is such that it is extremely unlikely that they will weaken the
1782 triple-DES encryption -- only slightly more likely than having the
1783 middle of the three sub-keys match one of the other two, which
1784 effectively converts the encryption to single-DES. (Which is another
1785 case we make no effort to avoid.)
1787 The true CRC-32 checksum is not collision-proof; an attacker could
1788 use a probabilistic chosen-plaintext attack to generate a valid
1789 message even if a confounder is used [SG92]. The use of collision-
1790 proof checksums is of course recommended for environments where such
1794 Raeburn [Page 32]
1795 \f
1796 INTERNET DRAFT May 2002
1799 attacks represent a significant threat. The "simplifications" (read:
1800 bugs) introduced when CRC-32 was implemented for Kerberos cause
1801 leading zeros to effectively be ignored, so messages differing only
1802 in leading zero bits will have the same checksum.
1804 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
1805 Unlike [IPSEC-HMAC], this specification does not use the suggested
1806 truncation of the HMAC output. As pointed out in [IPSEC-HMAC], SHA-1
1807 was not developed to be used as a keyed hash function, which is a
1808 criterion of HMAC. [HMAC-TEST] contains test vectors for HMAC-SHA-1.
1810 The mit_des_string_to_key function was originally constructed with
1811 the assumption that all input would be ASCII; it ignores the top bit
1812 of each input byte. Folding with XOR is also not an especially good
1813 mixing mechanism in terms of preserving randomness.
1815 The n-fold function used in the string-to-key operation for des3-cbc-
1816 hmac-sha1-kd was designed to cause each bit of input to contribute
1817 equally to the output; it was not designed to maximize or equally
1818 distribute randomness in the input, and there are conceivable cases
1819 of partially structured input where randomness may be lost. This
1820 should only be an issue for highly structured passwords, however.
1822 [RFC1851] discusses the relative strength of triple-DES encryption.
1823 The relative slow speed of triple-DES encryption may also be an issue
1824 for some applications.
1826 This document, like the Kerberos protocol, completely ignores the
1827 notion of limiting the amount of data a key may be used with to a
1828 quantity based on the robustness of the algorithm or size of the key.
1829 It is assumed that any defined algorithms and key sizes will be
1830 strong enough to support very large amounts of data, or they will be
1831 deprecated once significant attacks are known.
1833 This document also places no bounds on the amount of data that can be
1834 handled in various operations. In order to avoid denial of service
1835 attacks, implementations will probably want to restrict message sizes
1836 at some higher level.
1838 11. Acknowledgments
1840 This document is an extension of the encryption specification
1841 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
1842 of the text of the background, concepts, and DES specifications are
1843 drawn directly from that document.
1845 The abstract framework presented in this document was put together by
1846 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
1850 Raeburn [Page 33]
1851 \f
1852 INTERNET DRAFT May 2002
1855 and Tom Yu, and the details were refined several times based on
1856 comments from John Brezak and others.
1858 Marc Horowitz wrote the original specification of triple-DES and key
1859 derivation in a pair of Internet Drafts (under the names draft-
1860 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
1861 were later folded into a draft revision of [Kerb1510], from which
1862 this document was later split off.
1864 Tom Yu provided the text describing the modifications to the standard
1865 CRC algorithm as Kerberos implementations actually use it.
1867 Miroslav Jurisic provided information for one of the UTF-8 test cases
1868 for the string-to-key functions.
1870 Marcus Watts and Louis LeVay caught some errors in an earlier draft.
1872 12. Editor's address
1874 Kenneth Raeburn
1875 Massachusetts Institute of Technology
1876 77 Massachusetts Avenue
1877 Cambridge, MA 02139
1878 raeburn@mit.edu
1881 13. Full Copyright Statement
1883 Copyright (C) The Internet Society (2002). All Rights Reserved.
1885 This document and translations of it may be copied and furnished to
1886 others, and derivative works that comment on or otherwise explain it
1887 or assist in its implementation may be prepared, copied, published
1888 and distributed, in whole or in part, without restriction of any
1889 kind, provided that the above copyright notice and this paragraph are
1890 included on all such copies and derivative works. However, this
1891 document itself may not be modified in any way, such as by removing
1892 the copyright notice or references to the Internet Society or other
1893 Internet organizations, except as needed for the purpose of
1894 developing Internet standards in which case the procedures for
1895 copyrights defined in the Internet Standards process must be
1896 followed, or as required to translate it into languages other than
1897 English.
1899 The limited permissions granted above are perpetual and will not be
1900 revoked by the Internet Society or its successors or assigns.
1902 This document and the information contained herein is provided on an
1906 Raeburn [Page 34]
1907 \f
1908 INTERNET DRAFT May 2002
1911 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1912 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1913 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1914 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1915 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
1917 A. Test vectors
1919 This section provides test vectors for various functions defined or
1920 described in this document. For convenience, most inputs are ASCII
1921 strings, though some UTF-8 samples are be provided for string-to-key
1922 functions. Keys and other binary data are specified as hexadecimal
1923 strings.
1925 A.1. n-fold
1927 The n-fold function is defined in section 4.1. As noted there, the
1928 sample vector in the original paper defining the algorithm appears to
1929 be incorrect. Here are values provided by Marc Horowitz:
1931 64-fold("012345") =
1932 64-fold(303132333435) = be072631276b1955
1934 56-fold("password") =
1935 56-fold(70617373776f7264) = 78a07b6caf85fa
1937 64-fold("Rough Consensus, and Running Code") =
1938 64-fold(526f75676820436f6e73656e7375732c20616e642052756e
1939 6e696e6720436f6465) = bb6ed30870b7f0e0
1941 168-fold("password") =
1942 168-fold(70617373776f7264) =
1943 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
1945 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
1946 192-fold(4d41535341434856534554545320494e5354495456544520
1947 4f4620544543484e4f4c4f4759) =
1948 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
1950 A.2. mit_des_string_to_key
1952 The function mit_des_string_to_key is defined in section 5.2. We
1953 present here several test values, with some of the intermediate
1954 results. The fourth test demonstrates the use of UTF-8 with three
1955 characters. The last two tests are specifically constructed so as to
1956 trigger the weak-key fixups for the intermediate key produced by fan-
1957 folding; we have no test cases that cause such fixups for the final
1958 key.
1962 Raeburn [Page 35]
1963 \f
1964 INTERNET DRAFT May 2002
1967 UTF-8 encodings used in test vector:
1968 eszett C3 9F s-caron C5 A1 c-acute C4 87
1969 g-clef F0 9D 84 9E
1972 Test vector:
1975 salt: "ATHENA.MIT.EDUraeburn"
1976 415448454e412e4d49542e4544557261656275726e
1977 password: "password" 70617373776f7264
1978 fan-fold result: c01e38688ac86c2e
1979 intermediate key: c11f38688ac86d2f
1980 DES key: cbc22fae235298e3
1984 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79
1985 password: "potatoe" 706f7461746f65
1986 fan-fold result: a028944ee63c0416
1987 intermediate key: a129944fe63d0416
1988 DES key: df3d32a74fd92a01
1992 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374
1993 password: g-clef f09d849e
1994 fan-fold result: 3c4a262c18fab090
1995 intermediate key: 3d4a262c19fbb091
1996 DES key: 4ffb26bab0cd9413
2000 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
2001 415448454e412e4d49542e4544554a757269c5a169c487
2002 password: eszett c39f
2003 fan-fold result: b8f6c40e305afc9e
2004 intermediate key: b9f7c40e315bfd9e
2005 DES key: 62c81a5232b5e69d
2009 salt: "AAAAAAAA" 4141414141414141
2010 password: "11119999" 3131313139393939
2011 fan-fold result: e0e0e0e0f0f0f0f0
2012 intermediate key: e0e0e0e0f1f1f101
2013 DES key: 984054d0f1a73e31
2018 Raeburn [Page 36]
2019 \f
2020 INTERNET DRAFT May 2002
2023 salt: "FFFFAAAA" 4646464641414141
2024 password: "NNNN6666" 4e4e4e4e36363636
2025 fan-fold result: 1e1e1e1e0e0e0e0e
2026 intermediate key: 1f1f1f1f0e0e0efe
2027 DES key: c4bf6b25adf7a4f8
2030 A.3. DES3 DR and DK
2032 These tests show the derived-random and derived-key values for the
2033 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
2034 defined in section 5.3.1. The input keys were randomly generated;
2035 the usage values are from this specification.
2038 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
2039 usage: 0000000155
2040 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
2041 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
2045 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
2046 usage: 00000001aa
2047 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
2048 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
2052 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
2053 usage: 0000000155
2054 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
2055 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
2059 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
2060 usage: 00000001aa
2061 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
2062 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
2066 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
2067 usage: 6b65726265726f73
2068 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
2069 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
2074 Raeburn [Page 37]
2075 \f
2076 INTERNET DRAFT May 2002
2079 key: b55e983467e551b3e5d0e5b6c80d45769423a873dc62b30e
2080 usage: 636f6d62696e65
2081 DR: 0127398bacc81a2a62bc45f8d4c151bbcdd5cb788a
2082 DK: 0126388aadc81a1f2a62bc45f8d5c19151bacdd5cb798a3e
2086 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
2087 usage: 0000000155
2088 DR: 348056ec98fcc517171d2b4d7a9493af482d999175
2089 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
2093 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
2094 usage: 00000001aa
2095 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
2096 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
2100 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
2101 usage: 0000000155
2102 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
2103 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
2107 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
2108 usage: 00000001aa
2109 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
2110 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
2113 A.4. DES3string_to_key
2115 These are the keys generated for some of the above input strings for
2116 triple-DES with key derivation as defined in section 5.3.1.
2118 salt: "ATHENA.MIT.EDUraeburn"
2119 passwd: "password"
2120 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
2122 salt: "WHITEHOUSE.GOVdanny"
2123 passwd: "potatoe"
2124 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
2130 Raeburn [Page 38]
2131 \f
2132 INTERNET DRAFT May 2002
2135 salt: "EXAMPLE.COMbuckaroo"
2136 passwd: "penny"
2137 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
2139 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
2140 passwd: eszett
2141 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
2143 salt: "EXAMPLE.COMpianist"
2144 passwd: g-clef
2145 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
2147 A.5. Modified CRC-32
2149 Below are modified-CRC32 values for various ASCII strings. Only the
2150 printable ASCII characters are checksummed, no C-style trailing zero-
2151 valued octet. The 32-bit modified CRC and the sequence of output
2152 bytes as used in Kerberos are shown. (The octet values are separated
2153 here to emphasize that they are octet values and not 32-bit numbers,
2154 which will be the most convenient form for manipulation in some
2155 implementations. The bit and byte order used internally for such a
2156 number is irrelevant; the octet sequence generated is what is
2157 important.)
2160 mod-crc-32("foo") = 33 bc 32 73
2162 mod-crc-32("test0123456789") = d6 88 3e b8
2164 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
2166 mod-crc-32(8000) = 4b 98 83 3b
2168 mod-crc-32(0008) = 32 88 db 0e
2170 mod-crc-32(0080) = 20 83 b8 ed
2172 mod-crc-32(80) = 20 83 b8 ed
2174 mod-crc-32(80000000) = 3b b6 59 ed
2176 mod-crc-32(00000001) = 96 30 07 77
2179 B. Significant Changes from RFC 1510
2181 The encryption and checksum mechanism profiles are new. The old
2182 specification defined a few operations for various mechanisms, but
2186 Raeburn [Page 39]
2187 \f
2188 INTERNET DRAFT May 2002
2191 didn't outline what should be required of new mechanisms in terms of
2192 abstract properties, nor how to ensure that a mechanism specification
2193 is complete enough for interoperability between implementations. The
2194 new profiles do differ from the old specification in a few ways:
2196 Some message definitions in [Kerb1510] could be read as permitting
2197 the initial vector to be specified by the application; the text
2198 was too vague. It is specifically not permitted in this
2199 specification. Some encryption algorithms may not use
2200 initialization vectors, so relying on chosen, secret
2201 initialization vectors for security is unwise. Also, the
2202 prepended confounder in the existing algorithms is roughly
2203 equivalent to a per-message initialization vector that is revealed
2204 in encrypted form. However, carrying state across from one
2205 encryption to another is explicitly permitted through the opaque
2206 "cipher state" object.
2208 The use of key derivation is new.
2210 Several new methods are introduced, including generation of a key
2211 in wire-protocol format from random input data.
2213 The means for influencing the string-to-key algorithm are laid out
2214 more clearly.
2216 other new methods?
2218 Triple-DES support is new.
2220 The des-cbc-crc and CRC descriptions have been updated to align them
2221 with existing implementations.
2223 [Kerb1510] had no indication what character set or encoding might be
2224 used for pass phrases and salts.
2226 In [Kerb1510], key types, encryption algorithms and checksum
2227 algorithms were only loosely associated, and the association was not
2228 well described. In this specification, key types and encryption
2229 algorithms have a one-to-one correspondence, and associations between
2230 encryption and checksum algorithms are described so that checksums
2231 can be computed given negotiated keys, without requiring further
2232 negotiation for checksum types.
2234 C. Document History (delete before publication)
2236 Changes from kerberos-revisions-## to crypto-00 draft:
2238 Collected DES encryption algorithms together under one subsection.
2242 Raeburn [Page 40]
2243 \f
2244 INTERNET DRAFT May 2002
2247 Replaced salt type number with string-to-key parameter octet-string.
2249 Incorporated Tom Yu's description of our "modified" (i.e., broken)
2250 CRC algorithm.
2252 Changes from -00 to -01:
2254 Added "Significant Changes from RFC 1510" and "Document History"
2255 appendixes.
2257 Fixed up some incorrect section number references.
2259 Collected RSA checksum algorithms together under one section, and
2260 likewise for DES MAC checksum algorithms.
2262 Changed DES encryption description to indicate that the trailing
2263 padding is included in the checksum calculation.
2265 Updated introduction.
2267 Dropped combine-keys function. It'll be needed eventually, but this
2268 isn't the best place for it.
2270 Added request for weaknesses, attacks, test vectors in follow-on
2271 documents defining cipher suites, and references on weaknesses for
2272 suites defined here.
2274 We are not assigning the number registrations to IANA at this time.
2276 The get_mic function need not have a fixed size output. (If it is
2277 required, someone remind me why.) The hash function used in the
2278 simplified profile must, on the other hand.
2280 Cipher state description tightened up a bit: Split description into
2281 state and initial-state. Added direction (encrypt vs decrypt) as an
2282 input parameter for initialization, operations performed must be
2283 consistent with that. Cipher state can be used as input to
2284 encrypt/decrypt only once; operations output the new state to be used
2285 next time, if chaining at all. Chaining is required to influence the
2286 output, to detect message stream modifications; previously this was
2287 explicitly not required.
2289 Moved some descriptive text out of tables.
2291 Fixed some speling probelms.
2298 Raeburn [Page 41]
2299 \f
2300 INTERNET DRAFT May 2002
2303 Notes
2305 [1] While Message Authentication Code (MAC) or Message Integrity
2306 Check (MIC) would be more appropriate terms for many of the
2307 uses in this document, we continue to use the term "checksum"
2308 for historical reasons.
2310 [2] In the case of Kerberos, the encrypted objects will generally
2311 be ASN.1 DER encodings, which contain indications of their
2312 length in the first few octets.
2314 [3] As of the time of this writing, some new modes of operation
2315 have been proposed, some of which may permit encryption and
2316 integrity protection simultaneously. After some of these
2317 proposals have been subjected to adequate analysis, we may
2318 wish to formulate a new simplified profile based on one of
2319 them.
2321 [4] It should be noted that the sample vector in Appendix B.2 of
2322 the original paper appears to be incorrect. Two independent
2323 implementations from the specification (one in C by Marc
2324 Horowitz, and another in Scheme by Bill Sommerfeld) agree on
2325 a value different from that in [Blumenthal96].
2327 [5] A variant of the key is used to limit the use of a key to a
2328 particular function, separating the functions of generating a
2329 checksum from other encryption performed using the session
2330 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it
2331 maintains key parity. The properties of DES precluded the
2332 use of the complement. The same constant is used for similar
2333 purpose in the Message Integrity Check in the Privacy
2334 Enhanced Mail standard.
2336 [6] Perhaps one of the more common reasons for directly
2337 performing encryption is direct control over the negotiation
2338 and to select a "sufficiently strong" encryption algorithm
2339 (whatever that means in the context of a given application).
2340 While Kerberos directly provides no facility for negotiating
2341 encryption types between the application client and server,
2342 there are other means for accomplishing similar goals. For
2343 example, requesting only "strong" session key types from the
2344 KDC, and assuming that the type actually returned by the KDC
2345 will be understood and supported by the application server.
2354 Raeburn [Page 42]
2355 \f
2356 INTERNET DRAFT May 2002
2359 Normative References
2361 @@ NOTE: draft-rfc-editor-rfc2223bis-01 specifies separate "normative
2362 references" and "informative references" sections. This draft has
2363 not yet become an RFC as of the time of this writing.
2365 This section copied from kerberos-revisions draft. Drop the ones we
2366 don't need, add anything new that we do need. Move informational-
2367 only references to the next section. Update old I-D references to
2368 RFCs, or find other sources.
2371 [Bellare98]
2372 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
2373 "Relations Among Notions of Security for Public-Key Encryption
2374 Schemes". Extended abstract published in Advances in Cryptology-
2375 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
2376 1462, H. Krawcyzk ed., Springer-Verlag, 1998.
2377 [Blumenthal96]
2378 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers",
2379 Proceedings of PRAGOCRYPT '96, 1996.
2380 [CRC]
2381 International Organization for Standardization, "ISO Information
2382 Processing Systems - Data Communication - High-Level Data Link
2383 Control Procedure - Frame Structure," IS 3309, 3rd Edition,
2384 October 1984.
2385 [DES77]
2386 National Bureau of Standards, U.S. Department of Commerce, "Data
2387 Encryption Standard," Federal Information Processing Standards
2388 Publication 46, Washington, DC, 1977.
2389 [DESM80]
2390 National Bureau of Standards, U.S. Department of Commerce, "DES
2391 Modes of Operation," Federal Information Processing Standards
2392 Publication 81, Springfield, VA, December 1980.
2393 [Dolev91]
2394 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
2395 Proceedings of the 23rd Annual Symposium on Theory of Computing,
2396 ACM, 1991.
2397 [HMAC]
2398 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
2399 for Message Authentication", RFC 2104, February 1997.
2400 [MD4-92]
2401 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
2402 Laboratory for Computer Science, April 1992.
2403 [MD5-92]
2404 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
2405 Laboratory for Computer Science, April 1992.
2410 Raeburn [Page 43]
2411 \f
2412 INTERNET DRAFT May 2002
2415 [RFC2026]
2416 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
2417 2026, October 1996.
2418 [SG92]
2419 Stubblebine, S., and V. D. Gligor, "On Message Integrity in
2420 Cryptographic Protocols," in Proceedings of the IEEE Symposium on
2421 Research in Security and Privacy, Oakland, California, May 1992.
2423 Informative References
2425 [EFF-DES]
2426 Electronic Frontier Foundation, "Cracking DES: Secrets of
2427 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
2428 & Associates, Inc., May 1998.
2429 [ESP-DES]
2430 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
2431 With Explicit IV", RFC 2405, November 1998.
2432 [GSS-KRB5]
2433 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
2434 June 1996.
2435 [HMAC-TEST]
2436 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
2437 RFC 2202, September 1997.
2438 [IPSEC-HMAC]
2439 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
2440 AH", RFC 2404, November 1998.
2441 [Kerb]
2442 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
2443 Raeburn, "The Kerberos Network Authentication Service (V5)",
2444 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
2445 2002. Work in progress.
2446 [Kerb1510]
2447 Kohl, J., and C. Neuman, "The Kerberos Network Authentication
2448 Service (V5)", RFC 1510, September 1993.
2466 Raeburn [Page 44]