| blob | 0ac50b9590d5030948624cc012c0a49f99c5ea3b |
7 Network Working Group K. Raeburn
8 Request for Comments: 3961 MIT
9 Category: Standards Track February 2005
12 Encryption and Checksum Specifications
13 for Kerberos 5
15 Status of This Memo
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
23 Copyright Notice
25 Copyright (C) The Internet Society (2005).
27 Abstract
29 This document describes a framework for defining encryption and
30 checksum mechanisms for use with the Kerberos protocol, defining an
31 abstraction layer between the Kerberos protocol and related
32 protocols, and the actual mechanisms themselves. The document also
33 defines several mechanisms. Some are taken from RFC 1510, modified
34 in form to fit this new framework and occasionally modified in
35 content when the old specification was incorrect. New mechanisms are
36 presented here as well. This document does NOT indicate which
37 mechanisms may be considered "required to implement".
39 Table of Contents
41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
42 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2
43 3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4
44 4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9
45 5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10
46 5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10
47 5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12
48 5.3. Cryptosystem Profile Based on Simplified Profile . . . 13
49 5.4. Checksum Profiles Based on Simplified Profile . . . . . 16
50 6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16
51 6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
52 6.2. DES-based Encryption and Checksum Types . . . . . . . . 18
53 6.3. Triple-DES Based Encryption and Checksum Types . . . . 28
54 7. Use of Kerberos Encryption Outside This Specification . . . . 30
58 Raeburn Standards Track [Page 1]
59 \f
60 RFC 3961 Encryption and Checksum Specifications February 2005
63 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31
64 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32
65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
67 12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
68 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38
69 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38
70 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
71 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43
72 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
73 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
74 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
75 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
76 Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
77 Informative References. . . . . . . . . . . . . . . . . . . . . . 48
78 Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
79 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
81 1. Introduction
83 The Kerberos protocols [Kerb] are designed to encrypt messages of
84 arbitrary sizes, using block encryption ciphers or, less commonly,
85 stream encryption ciphers. Encryption is used to prove the
86 identities of the network entities participating in message
87 exchanges. However, nothing in the Kerberos protocol requires that
88 any specific encryption algorithm be used, as long as the algorithm
89 includes certain operations.
91 The following sections specify the encryption and checksum mechanisms
92 currently defined for Kerberos, as well as a framework for defining
93 future mechanisms. The encoding, chaining, padding, and other
94 requirements for each are described. Appendix A gives test vectors
95 for several functions.
97 2. Concepts
99 Both encryption and checksum mechanisms are profiled in later
100 sections. Each profile specifies a collection of operations and
101 attributes that must be defined for a mechanism. A Kerberos
102 encryption or checksum mechanism specification is not complete if it
103 does not define all of these operations and attributes.
105 An encryption mechanism must provide for confidentiality and
106 integrity of the original plaintext. (Incorporating a checksum may
107 permit integrity checking, if the encryption mode does not provide an
108 integrity check itself.) It must also provide non-malleability
114 Raeburn Standards Track [Page 2]
115 \f
116 RFC 3961 Encryption and Checksum Specifications February 2005
119 [Bellare98] [Dolev91]. Use of a random confounder prepended to the
120 plaintext is recommended. It should not be possible to determine if
121 two ciphertexts correspond to the same plaintext without the key.
123 A checksum mechanism [1] must provide proof of the integrity of the
124 associated message and must preserve the confidentiality of the
125 message in case it is not sent in the clear. Finding two plaintexts
126 with the same checksum should be infeasible. It is NOT required that
127 an eavesdropper be unable to determine whether two checksums are for
128 the same message, as the messages themselves would presumably be
129 visible to any such eavesdropper.
131 Due to advances in cryptography, some cryptographers consider using
132 the same key for multiple purposes unwise. Since keys are used in
133 performing a number of different functions in Kerberos, it is
134 desirable to use different keys for each of these purposes, even
135 though we start with a single long-term or session key.
137 We do this by enumerating the different uses of keys within Kerberos
138 and by making the "usage number" an input to the encryption or
139 checksum mechanisms; such enumeration is outside the scope of this
140 document. Later sections define simplified profile templates for
141 encryption and checksum mechanisms that use a key derivation function
142 applied to a CBC mode (or similar) cipher and a checksum or hash
143 algorithm.
145 We distinguish the "base key" specified by other documents from the
146 "specific key" for a specific encryption or checksum operation. It
147 is expected but not required that the specific key be one or more
148 separate keys derived from the original protocol key and the key
149 usage number. The specific key should not be explicitly referenced
150 outside of this document. The typical language used in other
151 documents should be something like, "encrypt this octet string using
152 this key and this usage number"; generation of the specific key and
153 cipher state (described in the next section) are implicit. The
154 creation of a new cipher-state object, or the re-use of one from a
155 previous encryption operation, may also be explicit.
157 New protocols defined in terms of the Kerberos encryption and
158 checksum types should use their own key usage values. Key usages are
159 unsigned 32-bit integers; zero is not permitted.
161 All data is assumed to be in the form of strings of octets or eight-
162 bit bytes. Environments with other byte sizes will have to emulate
163 this behavior in order to get correct results.
170 Raeburn Standards Track [Page 3]
171 \f
172 RFC 3961 Encryption and Checksum Specifications February 2005
175 Each algorithm is assigned an encryption type (or "etype") or
176 checksum type number, for algorithm identification within the
177 Kerberos protocol. The full list of current type number assignments
178 is given in section 8.
180 3. Encryption Algorithm Profile
182 An encryption mechanism profile must define the following attributes
183 and operations. The operations must be defined as functions in the
184 mathematical sense. No additional or implicit inputs (such as
185 Kerberos principal names or message sequence numbers) are permitted.
187 protocol key format
188 This describes which octet string values represent valid keys.
189 For encryption mechanisms that don't have perfectly dense key
190 spaces, this will describe the representation used for encoding
191 keys. It need not describe invalid specific values; all key
192 generation routines should avoid such values.
194 specific key structure
195 This is not a protocol format at all, but a description of the
196 keying material derived from the chosen key and used to encrypt or
197 decrypt data or compute or verify a checksum. It may, for
198 example, be a single key, a set of keys, or a combination of the
199 original key with additional data. The authors recommend using
200 one or more keys derived from the original key via one-way key
201 derivation functions.
203 required checksum mechanism
204 This indicates a checksum mechanism that must be available when
205 this encryption mechanism is used. Since Kerberos has no built in
206 mechanism for negotiating checksum mechanisms, once an encryption
207 mechanism is decided, the corresponding checksum mechanism can be
208 used.
210 key-generation seed length, K
211 This is the length of the random bitstring needed to generate a
212 key with the encryption scheme's random-to-key function (described
213 below). This must be a fixed value so that various techniques for
214 producing a random bitstring of a given length may be used with
215 key generation functions.
217 key generation functions
218 Keys must be generated in a number of cases, from different types
219 of inputs. All function specifications must indicate how to
220 generate keys in the proper wire format and must avoid generating
221 keys that significantly compromise the confidentiality of
222 encrypted data, if the cryptosystem has such. Entropy from each
226 Raeburn Standards Track [Page 4]
227 \f
228 RFC 3961 Encryption and Checksum Specifications February 2005
231 source should be preserved as much as possible. Many of the
232 inputs, although unknown, may be at least partly predictable
233 (e.g., a password string is likely to be entirely in the ASCII
234 subset and of fairly short length in many environments; a semi-
235 random string may include time stamps). The benefit of such
236 predictability to an attacker must be minimized.
238 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
239 This function generates a key from two UTF-8 strings and an opaque
240 octet string. One of the strings is usually the principal's pass
241 phrase, but generally it is merely a secret string. The other
242 string is a "salt" string intended to produce different keys from
243 the same password for different users or realms. Although the
244 strings provided will use UTF-8 encoding, no specific version of
245 Unicode should be assumed; all valid UTF-8 strings should be
246 allowed. Strings provided in other encodings MUST first be
247 converted to UTF-8 before applying this function.
249 The third argument, the octet string, may be used to pass
250 mechanism-specific parameters into this function. Since doing so
251 implies knowledge of the specific encryption system, generating
252 non-default parameter values should be an uncommon operation, and
253 normal Kerberos applications should be able to treat this
254 parameter block as an opaque object supplied by the Key
255 Distribution Center or defaulted to some mechanism-specific
256 constant value.
258 The string-to-key function should be a one-way function so that
259 compromising a user's key in one realm does not compromise it in
260 another, even if the same password (but a different salt) is used.
262 random-to-key (bitstring[K])->(protocol-key)
263 This function generates a key from a random bitstring of a
264 specific size. All the bits of the input string are assumed to be
265 equally random, even though the entropy present in the random
266 source may be limited.
268 key-derivation (protocol-key, integer)->(specific-key)
269 In this function, the integer input is the key usage value, as
270 described above. An attacker is assumed to know the usage values.
271 The specific-key output value was described in section 2.
273 string-to-key parameter format
274 This describes the format of the block of data that can be passed
275 to the string-to-key function above to configure additional
276 parameters for that function. Along with the mechanism of
277 encoding parameter values, bounds on the allowed parameters should
278 also be described to avoid allowing a spoofed KDC to compromise
282 Raeburn Standards Track [Page 5]
283 \f
284 RFC 3961 Encryption and Checksum Specifications February 2005
287 the user's password. If practical it may be desirable to
288 construct the encoding so that values unacceptably weakening the
289 resulting key cannot be encoded.
291 Local security policy might permit tighter bounds to avoid excess
292 resource consumption. If so, the specification should recommended
293 defaults for these bounds. The description should also outline
294 possible weaknesses if bounds checks or other validations are not
295 applied to a parameter string received from the network.
297 As mentioned above, this should be considered opaque to most
298 normal applications.
300 default string-to-key parameters (octet string)
301 This default value for the "params" argument to the string-to-key
302 function should be used when the application protocol (Kerberos or
303 other) does not explicitly set the parameter value. As indicated
304 above, in most cases this parameter block should be treated as an
305 opaque object.
307 cipher state
308 This describes any information that can be carried over from one
309 encryption or decryption operation to the next, for use with a
310 given specific key. For example, a block cipher used in CBC mode
311 may put an initial vector of one block in the cipher state. Other
312 encryption modes may track nonces or other data.
314 This state must be non-empty and must influence encryption so that
315 messages are decrypted in the same order they were a encrypted, if
316 the cipher state is carried over from one encryption to the next.
317 Distinguishing out-of-order or missing messages from corrupted
318 messages is not required. If desired, this can be done at a
319 higher level by including sequence numbers and not "chaining" the
320 cipher state between encryption operations.
322 The cipher state may not be reused in multiple encryption or
323 decryption operations. These operations all generate a new cipher
324 state that may be used for following operations using the same key
325 and operation.
327 The contents of the cipher state must be treated as opaque outside
328 of encryption system specifications.
330 initial cipher state (specific-key, direction)->(state)
331 This describes the generation of the initial value for the cipher
332 state if it is not being carried over from a previous encryption
333 or decryption operation.
338 Raeburn Standards Track [Page 6]
339 \f
340 RFC 3961 Encryption and Checksum Specifications February 2005
343 This describes any initial state setup needed before encrypting
344 arbitrary amounts of data with a given specific key. The specific
345 key and the direction of operations to be performed (encrypt
346 versus decrypt) must be the only input needed for this
347 initialization.
349 This state should be treated as opaque in any uses outside of an
350 encryption algorithm definition.
352 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
353 degree an application protocol could exercise control over the
354 initial vector used in DES CBC operations. Some existing
355 implementations permit setting the initial vector. This framework
356 does not provide for application control of the cipher state
357 (beyond "initialize" and "carry over from previous encryption"),
358 as the form and content of the initial cipher state can vary
359 between encryption systems and may not always be a single block of
360 random data.
362 New Kerberos application protocols should not assume control over
363 the initial vector, or that one even exists. However, a general-
364 purpose implementation may wish to provide the capability, in case
365 applications explicitly setting it are encountered.
367 encrypt (specific-key, state, octet string)->(state, octet string)
368 This function takes the specific key, cipher state, and a non-
369 empty plaintext string as input and generates ciphertext and a new
370 cipher state as outputs. If the basic encryption algorithm itself
371 does not provide for integrity protection (e.g., DES in CBC mode),
372 then some form of verifiable MAC or checksum must be included.
373 Some random factor such as a confounder should be included so that
374 an observer cannot know if two messages contain the same
375 plaintext, even if the cipher state and specific keys are the
376 same. The exact length of the plaintext need not be encoded, but
377 if it is not and if padding is required, the padding must be added
378 at the end of the string so that the decrypted version may be
379 parsed from the beginning.
381 The specification of the encryption function must indicate not
382 only the precise contents of the output octet string, but also the
383 output cipher state. The application protocol may carry the
384 output cipher state forward from one encryption with a given
385 specific key to another; the effect of this "chaining" must be
386 defined [2].
388 Assuming that values for the specific key and cipher state are
389 correctly-produced, no input octet string may result in an error
390 indication.
394 Raeburn Standards Track [Page 7]
395 \f
396 RFC 3961 Encryption and Checksum Specifications February 2005
399 decrypt (specific-key, state, octet string)->(state, octet string)
400 This function takes the specific key, cipher state, and ciphertext
401 as inputs and verifies the integrity of the supplied ciphertext.
402 If the ciphertext's integrity is intact, this function produces
403 the plaintext and a new cipher state as outputs; otherwise, an
404 error indication must be returned, and the data discarded.
406 The result of the decryption may be longer than the original
407 plaintext, as, for example, when the encryption mode adds padding
408 to reach a multiple of a block size. If this is the case, any
409 extra octets must come after the decoded plaintext. An
410 application protocol that needs to know the exact length of the
411 message must encode a length or recognizable "end of message"
412 marker within the plaintext [3].
414 As with the encryption function, a correct specification for this
415 function must indicate not only the contents of the output octet
416 string, but also the resulting cipher state.
418 pseudo-random (protocol-key, octet-string)->(octet-string)
419 This pseudo-random function should generate an octet string of
420 some size that is independent of the octet string input. The PRF
421 output string should be suitable for use in key generation, even
422 if the octet string input is public. It should not reveal the
423 input key, even if the output is made public.
425 These operations and attributes are all that is required to support
426 Kerberos and various proposed preauthentication schemes.
428 For convenience of certain application protocols that may wish to use
429 the encryption profile, we add the constraint that, for any given
430 plaintext input size, a message size must exist between that given
431 size and that size plus 65,535 such that the length of the decrypted
432 version of the ciphertext will never have extra octets at the end.
434 Expressed mathematically, for every message length L1, there exists a
435 message size L2 such that
437 L2 >= L1
438 L2 < L1 + 65,536
439 for every message M with |M| = L2, decrypt(encrypt(M)) = M
441 A document defining a new encryption type should also describe known
442 weaknesses or attacks, so that its security may be fairly assessed,
443 and should include test vectors or other validation procedures for
444 the operations defined. Specific references to information that is
445 readily available elsewhere are sufficient.
450 Raeburn Standards Track [Page 8]
451 \f
452 RFC 3961 Encryption and Checksum Specifications February 2005
455 4. Checksum Algorithm Profile
457 A checksum mechanism profile must define the following attributes and
458 operations:
460 associated encryption algorithm(s)
461 This indicates the types of encryption keys this checksum
462 mechanism can be used with.
464 A keyed checksum mechanism may have more than one associated
465 encryption algorithm if they share the same wire-key format,
466 string-to-key function, default string-to-key-parameters, and key
467 derivation function. (This combination means that, for example, a
468 checksum type, key usage value, and password are adequate to get
469 the specific key used to compute a checksum.)
471 An unkeyed checksum mechanism can be used with any encryption
472 type, as the key is ignored, but its use must be limited to cases
473 where the checksum itself is protected, to avoid trivial attacks.
475 get_mic function
476 This function generates a MIC token for a given specific key (see
477 section 3) and message (represented as an octet string) that may
478 be used to verify the integrity of the associated message. This
479 function is not required to return the same deterministic result
480 for each use; it need only generate a token that the verify_mic
481 routine can check.
483 The output of this function will also dictate the size of the
484 checksum. It must be no larger than 65,535 octets.
486 verify_mic function
487 Given a specific key, message, and MIC token, this function
488 ascertains whether the message integrity has been compromised.
489 For a deterministic get_mic routine, the corresponding verify_mic
490 may simply generate another checksum and compare the two.
492 The get_mic and verify_mic operations must allow inputs of arbitrary
493 length; if any padding is needed, the padding scheme must be
494 specified as part of these functions.
496 These operations and attributes are all that should be required to
497 support Kerberos and various proposed preauthentication schemes.
499 As with encryption mechanism definition documents, documents defining
500 new checksum mechanisms should indicate validation processes and
501 known weaknesses.
506 Raeburn Standards Track [Page 9]
507 \f
508 RFC 3961 Encryption and Checksum Specifications February 2005
511 5. Simplified Profile for CBC Ciphers with Key Derivation
513 The profile outlined in sections 3 and 4 describes a large number of
514 operations that must be defined for encryption and checksum
515 algorithms to be used with Kerberos. Here we describe a simpler
516 profile that can generate both encryption and checksum mechanism
517 definitions, filling in uses of key derivation in appropriate places,
518 providing integrity protection, and defining multiple operations for
519 the cryptosystem profile based on a smaller set of operations. Not
520 all of the existing cryptosystems for Kerberos fit into this
521 simplified profile, but we recommend that future cryptosystems use it
522 or something based on it [4].
524 Not all the operations in the complete profiles are defined through
525 this mechanism; several must still be defined for each new algorithm
526 pair.
528 5.1. A Key Derivation Function
530 Rather than define some scheme by which a "protocol key" is composed
531 of a large number of encryption keys, we use keys derived from a base
532 key to perform cryptographic operations. The base key must be used
533 only for generating the derived keys, and this derivation must be
534 non-invertible and entropy preserving. Given these restrictions,
535 compromise of one derived key does not compromise others. Attack of
536 the base key is limited, as it is only used for derivation and is not
537 exposed to any user data.
539 To generate a derived key from a base key, we generate a pseudorandom
540 octet string by using an algorithm DR, described below, and generate
541 a key from that octet string by using a function dependent on the
542 encryption algorithm. The input length needed for that function,
543 which is also dependent on the encryption algorithm, dictates the
544 length of the string to be generated by the DR algorithm (the value
545 "k" below). These procedures are based on the key derivation in
546 [Blumenthal96].
548 Derived Key = DK(Base Key, Well-Known Constant)
550 DK(Key, Constant) = random-to-key(DR(Key, Constant))
552 DR(Key, Constant) = k-truncate(E(Key, Constant,
553 initial-cipher-state))
555 Here DR is the random-octet generation function described below, and
556 DK is the key-derivation function produced from it. In this
557 construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
558 a well-known constant determined by the specific usage of this
562 Raeburn Standards Track [Page 10]
563 \f
564 RFC 3961 Encryption and Checksum Specifications February 2005
567 function, and k-truncate truncates its argument by taking the first k
568 bits. Here, k is the key generation seed length needed for the
569 encryption system.
571 The output of the DR function is a string of bits; the actual key is
572 produced by applying the cryptosystem's random-to-key operation on
573 this bitstring.
575 If the Constant is smaller than the cipher block size of E, then it
576 must be expanded with n-fold() so it can be encrypted. If the output
577 of E is shorter than k bits, it is fed back into the encryption as
578 many times as necessary. The construct is as follows (where |
579 indicates concatentation):
581 K1 = E(Key, n-fold(Constant), initial-cipher-state)
582 K2 = E(Key, K1, initial-cipher-state)
583 K3 = E(Key, K2, initial-cipher-state)
584 K4 = ...
586 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
588 n-fold is an algorithm that takes m input bits and "stretches" them
589 to form n output bits with equal contribution from each input bit to
590 the output, as described in [Blumenthal96]:
592 We first define a primitive called n-folding, which takes a
593 variable-length input block and produces a fixed-length output
594 sequence. The intent is to give each input bit approximately
595 equal weight in determining the value of each output bit. Note
596 that whenever we need to treat a string of octets as a number, the
597 assumed representation is Big-Endian -- Most Significant Byte
598 first.
600 To n-fold a number X, replicate the input value to a length that
601 is the least common multiple of n and the length of X. Before
602 each repetition, the input is rotated to the right by 13 bit
603 positions. The successive n-bit chunks are added together using
604 1's-complement addition (that is, with end-around carry) to yield
605 a n-bit result....
607 Test vectors for n-fold are supplied in appendix A [5].
609 In this section, n-fold is always used to produce c bits of output,
610 where c is the cipher block size of E.
612 The size of the Constant must not be larger than c, because reducing
613 the length of the Constant by n-folding can cause collisions.
618 Raeburn Standards Track [Page 11]
619 \f
620 RFC 3961 Encryption and Checksum Specifications February 2005
623 If the size of the Constant is smaller than c, then the Constant must
624 be n-folded to length c. This string is used as input to E. If the
625 block size of E is less than the random-to-key input size, then the
626 output from E is taken as input to a second invocation of E. This
627 process is repeated until the number of bits accumulated is greater
628 than or equal to the random-to-key input size. When enough bits have
629 been computed, the first k are taken as the random data used to
630 create the key with the algorithm-dependent random-to-key function.
632 As the derived key is the result of one or more encryptions in the
633 base key, deriving the base key from the derived key is equivalent to
634 determining the key from a very small number of plaintext/ciphertext
635 pairs. Thus, this construction is as strong as the cryptosystem
636 itself.
638 5.2. Simplified Profile Parameters
640 These are the operations and attributes that must be defined:
642 protocol key format
643 string-to-key function
644 default string-to-key parameters
645 key-generation seed length, k
646 random-to-key function
647 As above for the normal encryption mechanism profile.
649 unkeyed hash algorithm, H
650 This should be a collision-resistant hash algorithm with fixed-
651 size output, suitable for use in an HMAC [HMAC]. It must support
652 inputs of arbitrary length. Its output must be at least the
653 message block size (below).
655 HMAC output size, h
656 This indicates the size of the leading substring output by the
657 HMAC function that should be used in transmitted messages. It
658 should be at least half the output size of the hash function H,
659 and at least 80 bits; it need not match the output size.
661 message block size, m
662 This is the size of the smallest units the cipher can handle in
663 the mode in which it is being used. Messages will be padded to a
664 multiple of this size. If a block cipher is used in a mode that
674 Raeburn Standards Track [Page 12]
675 \f
676 RFC 3961 Encryption and Checksum Specifications February 2005
679 can handle messages that are not multiples of the cipher block
680 size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
681 this value would be one octet. For traditional CBC mode with
682 padding, it would be the underlying cipher's block size.
684 This value must be a multiple of eight bits (one octet).
686 encryption/decryption functions, E and D
687 These are basic encryption and decryption functions for messages
688 of sizes that are multiples of the message block size. No
689 integrity checking or confounder should be included here. For
690 inputs these functions take the IV or similar data, a protocol-
691 format key, and an octet string, returning a new IV and octet
692 string.
694 The encryption function is not required to use CBC mode but is
695 assumed to be using something with similar properties. In
696 particular, prepending a cipher block-size confounder to the
697 plaintext should alter the entire ciphertext (comparable to
698 choosing and including a random initial vector for CBC mode).
700 The result of encrypting one cipher block (of size c, above) must
701 be deterministic for the random octet generation function DR in
702 the previous section to work. For best security, it should also
703 be no larger than c.
705 cipher block size, c
706 This is the block size of the block cipher underlying the
707 encryption and decryption functions indicated above, used for key
708 derivation and for the size of the message confounder and initial
709 vector. (If a block cipher is not in use, some comparable
710 parameter should be determined.) It must be at least 5 octets.
712 This is not actually an independent parameter; rather, it is a
713 property of the functions E and D. It is listed here to clarify
714 the distinction between it and the message block size, m.
716 Although there are still a number of properties to specify, they are
717 fewer and simpler than in the full profile.
719 5.3. Cryptosystem Profile Based on Simplified Profile
721 The above key derivation function is used to produce three
722 intermediate keys. One is used for computing checksums of
723 unencrypted data. The other two are used for encrypting and
724 checksumming plaintext to be sent encrypted.
730 Raeburn Standards Track [Page 13]
731 \f
732 RFC 3961 Encryption and Checksum Specifications February 2005
735 The ciphertext output is the concatenation of the output of the basic
736 encryption function E and a (possibly truncated) HMAC using the
737 specified hash function H, both applied to the plaintext with a
738 random confounder prefix and sufficient padding to bring it to a
739 multiple of the message block size. When the HMAC is computed, the
740 key is used in the protocol key form.
742 Decryption is performed by removing the (partial) HMAC, decrypting
743 the remainder, and verifying the HMAC. The cipher state is an
744 initial vector, initialized to zero.
746 The substring notation "[1..h]" in the following table should be read
747 as using 1-based indexing; leading substrings are used.
786 Raeburn Standards Track [Page 14]
787 \f
788 RFC 3961 Encryption and Checksum Specifications February 2005
791 Cryptosystem from Simplified Profile
792 ------------------------------------------------------------------------
793 protocol key format As given.
795 specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
797 key-generation seed As given.
798 length
800 required checksum As defined below in section 5.4.
801 mechanism
803 cipher state Initial vector (usually of length c)
805 initial cipher state All bits zero
807 encryption function conf = Random string of length c
808 pad = Shortest string to bring confounder
809 and plaintext to a length that's a
810 multiple of m.
811 (C1, newIV) = E(Ke, conf | plaintext | pad,
812 oldstate.ivec)
813 H1 = HMAC(Ki, conf | plaintext | pad)
814 ciphertext = C1 | H1[1..h]
815 newstate.ivec = newIV
817 decryption function (C1,H1) = ciphertext
818 (P1, newIV) = D(Ke, C1, oldstate.ivec)
819 if (H1 != HMAC(Ki, P1)[1..h])
820 report error
821 newstate.ivec = newIV
823 default string-to-key As given.
824 params
826 pseudo-random function tmp1 = H(octet-string)
827 tmp2 = truncate tmp1 to multiple of m
828 PRF = E(DK(protocol-key, prfconstant),
829 tmp2, initial-cipher-state)
831 The "prfconstant" used in the PRF operation is the three-octet string
832 "prf".
842 Raeburn Standards Track [Page 15]
843 \f
844 RFC 3961 Encryption and Checksum Specifications February 2005
847 Cryptosystem from Simplified Profile
848 ------------------------------------------------------------------------
849 key generation functions:
851 string-to-key function As given.
853 random-to-key function As given.
855 key-derivation function The "well-known constant" used for the DK
856 function is the key usage number, expressed as
857 four octets in big-endian order, followed by
858 one octet indicated below.
860 Kc = DK(base-key, usage | 0x99);
861 Ke = DK(base-key, usage | 0xAA);
862 Ki = DK(base-key, usage | 0x55);
864 5.4. Checksum Profiles Based on Simplified Profile
866 When an encryption system is defined with the simplified profile
867 given in section 5.2, a checksum algorithm may be defined for it as
868 follows:
870 Checksum Mechanism from Simplified Profile
871 --------------------------------------------------
872 associated cryptosystem As defined above.
874 get_mic HMAC(Kc, message)[1..h]
876 verify_mic get_mic and compare
878 The HMAC function and key Kc are as described in section 5.3.
880 6. Profiles for Kerberos Encryption and Checksum Algorithms
882 These profiles describe the encryption and checksum systems defined
883 for Kerberos. The astute reader will notice that some of them do not
884 fulfill all the requirements outlined in previous sections. These
885 systems are defined for backward compatibility; newer implementations
886 should (whenever possible) attempt to utilize encryption systems that
887 satisfy all the profile requirements.
889 The full list of current encryption and checksum type number
890 assignments, including values currently reserved but not defined in
891 this document, is given in section 8.
898 Raeburn Standards Track [Page 16]
899 \f
900 RFC 3961 Encryption and Checksum Specifications February 2005
903 6.1. Unkeyed Checksums
905 These checksum types use no encryption keys and thus can be used in
906 combination with any encryption type, but they may only be used with
907 caution, in limited circumstances where the lack of a key does not
908 provide a window for an attack, preferably as part of an encrypted
909 message [6]. Keyed checksum algorithms are recommended.
911 6.1.1. The RSA MD5 Checksum
913 The RSA-MD5 checksum calculates a checksum by using the RSA MD5
914 algorithm [MD5-92]. The algorithm takes as input an input message of
915 arbitrary length and produces as output a 128-bit (sixteen octet)
916 checksum.
918 rsa-md5
919 ----------------------------------------------
920 associated cryptosystem any
922 get_mic rsa-md5(msg)
924 verify_mic get_mic and compare
926 The rsa-md5 checksum algorithm is assigned a checksum type number of
927 seven (7).
929 6.1.2. The RSA MD4 Checksum
931 The RSA-MD4 checksum calculates a checksum using the RSA MD4
932 algorithm [MD4-92]. The algorithm takes as input an input message of
933 arbitrary length and produces as output a 128-bit (sixteen octet)
934 checksum.
936 rsa-md4
937 ----------------------------------------------
938 associated cryptosystem any
940 get_mic md4(msg)
942 verify_mic get_mic and compare
944 The rsa-md4 checksum algorithm is assigned a checksum type number of
945 two (2).
954 Raeburn Standards Track [Page 17]
955 \f
956 RFC 3961 Encryption and Checksum Specifications February 2005
959 6.1.3. CRC-32 Checksum
961 This CRC-32 checksum calculates a checksum based on a cyclic
962 redundancy check as described in ISO 3309 [CRC] but modified as
963 described below. The resulting checksum is four (4) octets in
964 length. The CRC-32 is neither keyed nor collision-proof; thus, the
965 use of this checksum is not recommended. An attacker using a
966 probabilistic chosen-plaintext attack as described in [SG92] might be
967 able to generate an alternative message that satisfies the checksum.
969 The CRC-32 checksum used in the des-cbc-crc encryption mode is
970 identical to the 32-bit FCS described in ISO 3309 with two
971 exceptions: The sum with the all-ones polynomial times x**k is
972 omitted, and the final remainder is not ones-complemented. ISO 3309
973 describes the FCS in terms of bits, whereas this document describes
974 the Kerberos protocol in terms of octets. To clarify the ISO 3309
975 definition for the purpose of computing the CRC-32 in the des-cbc-crc
976 encryption mode, the ordering of bits in each octet shall be assumed
977 to be LSB first. Given this assumed ordering of bits within an
978 octet, the mapping of bits to polynomial coefficients shall be
979 identical to that specified in ISO 3309.
981 Test values for this modified CRC function are included in appendix
982 A.5.
984 crc32
985 ----------------------------------------------
986 associated cryptosystem any
988 get_mic crc32(msg)
990 verify_mic get_mic and compare
992 The crc32 checksum algorithm is assigned a checksum type number of
993 one (1).
995 6.2. DES-Based Encryption and Checksum Types
997 These encryption systems encrypt information under the Data
998 Encryption Standard [DES77] by using the cipher block chaining mode
999 [DESM80]. A checksum is computed as described below and placed in
1000 the cksum field. DES blocks are eight bytes. As a result, the data
1001 to be encrypted (the concatenation of confounder, checksum, and
1002 message) must be padded to an eight byte boundary before encryption.
1003 The values of the padding bytes are unspecified.
1010 Raeburn Standards Track [Page 18]
1011 \f
1012 RFC 3961 Encryption and Checksum Specifications February 2005
1015 Plaintext and DES ciphertext are encoded as blocks of eight octets,
1016 which are concatenated to make the 64-bit inputs for the DES
1017 algorithms. The first octet supplies the eight most significant bits
1018 (with the octet's MSB used as the DES input block's MSB, etc.), the
1019 second octet the next eight bits, and so on. The eighth octet
1020 supplies the 8 least significant bits.
1022 Encryption under DES using cipher block chaining requires an
1023 additional input in the form of an initialization vector; this vector
1024 is specified below for each encryption system.
1026 The DES specifications [DESI81] identify four 'weak' and twelve
1027 'semi-weak' keys; these keys SHALL NOT be used for encrypting
1028 messages for use in Kerberos. The "variant keys" generated for the
1029 RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an
1030 eXclusive-OR of a DES key with a constant are not checked for this
1031 property.
1033 A DES key is eight octets of data. This consists of 56 bits of
1034 actual key data, and eight parity bits, one per octet. The key is
1035 encoded as a series of eight octets written in MSB-first order. The
1036 bits within the key are also encoded in MSB order. For example, if
1037 the encryption key is
1038 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where
1039 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
1040 parity bits, the first octet of the key would be B1,B2,...,B7,P1
1041 (with B1 as the most significant bit). See the [DESM80] introduction
1042 for reference.
1044 Encryption Data Format
1046 The format for the data to be encrypted includes a one-block
1047 confounder, a checksum, the encoded plaintext, and any necessary
1048 padding, as described in the following diagram. The msg-seq field
1049 contains the part of the protocol message to be encrypted.
1051 +-----------+----------+---------+-----+
1052 |confounder | checksum | msg-seq | pad |
1053 +-----------+----------+---------+-----+
1055 One generates a random confounder of one block, placing it in
1056 'confounder'; zeros out the 'checksum' field (of length appropriate
1057 to exactly hold the checksum to be computed); adds the necessary
1058 padding; calculates the appropriate checksum over the whole sequence,
1059 placing the result in 'checksum'; and then encrypts using the
1060 specified encryption type and the appropriate key.
1066 Raeburn Standards Track [Page 19]
1067 \f
1068 RFC 3961 Encryption and Checksum Specifications February 2005
1071 String or Random-Data to Key Transformation
1073 To generate a DES key from two UTF-8 text strings (password and
1074 salt), the two strings are concatenated, password first, and the
1075 result is then padded with zero-valued octets to a multiple of eight
1076 octets.
1078 The top bit of each octet (always zero if the password is plain
1079 ASCII, as was assumed when the original specification was written) is
1080 discarded, and the remaining seven bits of each octet form a
1081 bitstring. This is then fan-folded and eXclusive-ORed with itself to
1082 produce a 56-bit string. An eight-octet key is formed from this
1083 string, each octet using seven bits from the bitstring, leaving the
1084 least significant bit unassigned. The key is then "corrected" by
1085 correcting the parity on the key, and if the key matches a 'weak' or
1086 'semi-weak' key as described in the DES specification, it is
1087 eXclusive-ORed with the constant 0x00000000000000F0. This key is
1088 then used to generate a DES CBC checksum on the initial string with
1089 the salt appended. The result of the CBC checksum is then
1090 "corrected" as described above to form the result, which is returned
1091 as the key.
1093 For purposes of the string-to-key function, the DES CBC checksum is
1094 calculated by CBC encrypting a string using the key as IV and the
1095 final eight byte block as the checksum.
1097 Pseudocode follows:
1099 removeMSBits(8byteblock) {
1100 /* Treats a 64 bit block as 8 octets and removes the MSB in
1101 each octet (in big endian mode) and concatenates the
1102 result. E.g., the input octet string:
1103 01110000 01100001 11110011 01110011 11110111 01101111
1104 11110010 01100100
1105 results in the output bitstring:
1106 1110000 1100001 1110011 1110011 1110111 1101111
1107 1110010 1100100 */
1108 }
1110 reverse(56bitblock) {
1111 /* Treats a 56-bit block as a binary string and reverses it.
1112 E.g., the input string:
1113 1000001 1010100 1001000 1000101 1001110 1000001
1114 0101110 1001101
1115 results in the output string:
1116 1011001 0111010 1000001 0111001 1010001 0001001
1117 0010101 1000001 */
1118 }
1122 Raeburn Standards Track [Page 20]
1123 \f
1124 RFC 3961 Encryption and Checksum Specifications February 2005
1127 add_parity_bits(56bitblock) {
1128 /* Copies a 56-bit block into a 64-bit block, left shifts
1129 content in each octet, and add DES parity bit.
1130 E.g., the input string:
1131 1100000 0001111 0011100 0110100 1000101 1100100
1132 0110110 0010111
1133 results in the output string:
1134 11000001 00011111 00111000 01101000 10001010 11001000
1135 01101101 00101111 */
1136 }
1138 key_correction(key) {
1139 fixparity(key);
1140 if (is_weak_key(key))
1141 key = key XOR 0xF0;
1142 return(key);
1143 }
1145 mit_des_string_to_key(string,salt) {
1146 odd = 1;
1147 s = string | salt;
1148 tempstring = 0; /* 56-bit string */
1149 pad(s); /* with nulls to 8 byte boundary */
1150 for (8byteblock in s) {
1151 56bitstring = removeMSBits(8byteblock);
1152 if (odd == 0) reverse(56bitstring);
1153 odd = ! odd;
1154 tempstring = tempstring XOR 56bitstring;
1155 }
1156 tempkey = key_correction(add_parity_bits(tempstring));
1157 key = key_correction(DES-CBC-check(s,tempkey));
1158 return(key);
1159 }
1161 des_string_to_key(string,salt,params) {
1162 if (length(params) == 0)
1163 type = 0;
1164 else if (length(params) == 1)
1165 type = params[0];
1166 else
1167 error("invalid params");
1168 if (type == 0)
1169 mit_des_string_to_key(string,salt);
1170 else
1171 error("invalid params");
1172 }
1178 Raeburn Standards Track [Page 21]
1179 \f
1180 RFC 3961 Encryption and Checksum Specifications February 2005
1183 One common extension is to support the "AFS string-to-key" algorithm,
1184 which is not defined here, if the type value above is one (1).
1186 For generation of a key from a random bitstring, we start with a 56-
1187 bit string and, as with the string-to-key operation above, insert
1188 parity bits. If the result is a weak or semi-weak key, we modify it
1189 by eXclusive-OR with the constant 0x00000000000000F0:
1191 des_random_to_key(bitstring) {
1192 return key_correction(add_parity_bits(bitstring));
1193 }
1195 6.2.1. DES with MD5
1197 The des-cbc-md5 encryption mode encrypts information under DES in CBC
1198 mode with an all-zero initial vector and with an MD5 checksum
1199 (described in [MD5-92]) computed and placed in the checksum field.
1201 The encryption system parameters for des-cbc-md5 are as follows:
1203 des-cbc-md5
1204 --------------------------------------------------------------------
1205 protocol key format 8 bytes, parity in low bit of each
1207 specific key structure copy of original key
1209 required checksum rsa-md5-des
1210 mechanism
1212 key-generation seed 8 bytes
1213 length
1215 cipher state 8 bytes (CBC initial vector)
1217 initial cipher state all-zero
1219 encryption function des-cbc(confounder | checksum | msg | pad,
1220 ivec=oldstate)
1221 where
1222 checksum = md5(confounder | 0000...
1223 | msg | pad)
1225 newstate = last block of des-cbc output
1227 decryption function decrypt encrypted text and verify checksum
1229 newstate = last block of ciphertext
1234 Raeburn Standards Track [Page 22]
1235 \f
1236 RFC 3961 Encryption and Checksum Specifications February 2005
1239 des-cbc-md5
1240 --------------------------------------------------------------------
1241 default string-to-key empty string
1242 params
1244 pseudo-random function des-cbc(md5(input-string), ivec=0)
1246 key generation functions:
1248 string-to-key des_string_to_key
1250 random-to-key des_random_to_key
1252 key-derivation identity
1254 The des-cbc-md5 encryption type is assigned the etype value three
1255 (3).
1257 6.2.2. DES with MD4
1259 The des-cbc-md4 encryption mode also encrypts information under DES
1260 in CBC mode, with an all-zero initial vector. An MD4 checksum
1261 (described in [MD4-92]) is computed and placed in the checksum field.
1263 des-cbc-md4
1264 --------------------------------------------------------------------
1265 protocol key format 8 bytes, parity in low bit of each
1267 specific key structure copy of original key
1269 required checksum rsa-md4-des
1270 mechanism
1272 key-generation seed 8 bytes
1273 length
1275 cipher state 8 bytes (CBC initial vector)
1277 initial cipher state all-zero
1279 encryption function des-cbc(confounder | checksum | msg | pad,
1280 ivec=oldstate)
1281 where
1282 checksum = md4(confounder | 0000...
1283 | msg | pad)
1285 newstate = last block of des-cbc output
1290 Raeburn Standards Track [Page 23]
1291 \f
1292 RFC 3961 Encryption and Checksum Specifications February 2005
1295 des-cbc-md4
1296 --------------------------------------------------------------------
1298 decryption function decrypt encrypted text and verify checksum
1300 newstate = last block of ciphertext
1302 default string-to-key empty string
1303 params
1305 pseudo-random function des-cbc(md5(input-string), ivec=0)
1307 key generation functions:
1309 string-to-key des_string_to_key
1311 random-to-key copy input, then fix parity bits
1313 key-derivation identity
1315 Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
1317 The des-cbc-md4 encryption algorithm is assigned the etype value two
1318 (2).
1320 6.2.3. DES with CRC
1322 The des-cbc-crc encryption type uses DES in CBC mode with the key
1323 used as the initialization vector, with a four-octet CRC-based
1324 checksum computed as described in section 6.1.3. Note that this is
1325 not a standard CRC-32 checksum, but a slightly modified one.
1327 des-cbc-crc
1328 --------------------------------------------------------------------
1329 protocol key format 8 bytes, parity in low bit of each
1331 specific key structure copy of original key
1333 required checksum rsa-md5-des
1334 mechanism
1336 key-generation seed 8 bytes
1337 length
1339 cipher state 8 bytes (CBC initial vector)
1346 Raeburn Standards Track [Page 24]
1347 \f
1348 RFC 3961 Encryption and Checksum Specifications February 2005
1351 des-cbc-crc
1352 --------------------------------------------------------------------
1353 initial cipher state copy of original key
1355 encryption function des-cbc(confounder | checksum | msg | pad,
1356 ivec=oldstate)
1357 where
1358 checksum = crc(confounder | 00000000
1359 | msg | pad)
1361 newstate = last block of des-cbc output
1363 decryption function decrypt encrypted text and verify checksum
1365 newstate = last block of ciphertext
1367 default string-to-key empty string
1368 params
1370 pseudo-random function des-cbc(md5(input-string), ivec=0)
1372 key generation functions:
1374 string-to-key des_string_to_key
1376 random-to-key copy input, then fix parity bits
1378 key-derivation identity
1380 The des-cbc-crc encryption algorithm is assigned the etype value one
1381 (1).
1383 6.2.4. RSA MD5 Cryptographic Checksum Using DES
1385 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
1386 by prepending an eight octet confounder before the text, applying the
1387 RSA MD5 checksum algorithm, and encrypting the confounder and the
1388 checksum by using DES in cipher-block-chaining (CBC) mode with a
1389 variant of the key, where the variant is computed by eXclusive-ORing
1390 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The
1391 initialization vector should be zero. The resulting checksum is 24
1392 octets long.
1402 Raeburn Standards Track [Page 25]
1403 \f
1404 RFC 3961 Encryption and Checksum Specifications February 2005
1407 rsa-md5-des
1408 ----------------------------------------------------------------
1409 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1411 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1412 conf | rsa-md5(conf | msg))
1414 verify_mic decrypt and verify rsa-md5 checksum
1416 The rsa-md5-des checksum algorithm is assigned a checksum type number
1417 of eight (8).
1419 6.2.5. RSA MD4 Cryptographic Checksum Using DES
1421 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
1422 by prepending an eight octet confounder before the text, applying the
1423 RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder
1424 and the checksum using DES in cipher-block-chaining (CBC) mode with a
1425 variant of the key, where the variant is computed by eXclusive-ORing
1426 the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization
1427 vector should be zero. The resulting checksum is 24 octets long.
1429 rsa-md4-des
1430 ----------------------------------------------------------------
1431 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1433 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1434 conf | rsa-md4(conf | msg),
1435 ivec=0)
1437 verify_mic decrypt and verify rsa-md4 checksum
1439 The rsa-md4-des checksum algorithm is assigned a checksum type number
1440 of three (3).
1442 6.2.6. RSA MD4 Cryptographic Checksum Using DES Alternative
1444 The RSA-MD4-DES-K checksum calculates a keyed collision-proof
1445 checksum by applying the RSA MD4 checksum algorithm and encrypting
1446 the results by using DES in cipher block chaining (CBC) mode with a
1447 DES key as both key and initialization vector. The resulting
1448 checksum is 16 octets long. This checksum is tamper-proof and
1449 believed to be collision-proof. Note that this checksum type is the
1450 old method for encoding the RSA-MD4-DES checksum; it is no longer
1451 recommended.
1458 Raeburn Standards Track [Page 26]
1459 \f
1460 RFC 3961 Encryption and Checksum Specifications February 2005
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
1471 The rsa-md4-des-k checksum algorithm is assigned a checksum type
1472 number of six (6).
1474 6.2.7. DES CBC Checksum
1476 The DES-MAC checksum is computed by prepending an eight octet
1477 confounder to the plaintext, padding with zero-valued octets if
1478 necessary to bring the length to a multiple of eight octets,
1479 performing a DES CBC-mode encryption on the result by using the key
1480 and an initialization vector of zero, taking the last block of the
1481 ciphertext, prepending the same confounder, and encrypting the pair
1482 by using DES in cipher-block-chaining (CBC) mode with a variant of
1483 the key, where the variant is computed by eXclusive-ORing the key
1484 with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector
1485 should be zero. The resulting checksum is 128 bits (sixteen octets)
1486 long, 64 bits of which are redundant. This checksum is tamper-proof
1487 and collision-proof.
1489 des-mac
1490 ---------------------------------------------------------------------
1491 associated des-cbc-md5, des-cbc-md4, des-cbc-crc
1492 cryptosystem
1494 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1495 conf | des-mac(key, conf | msg | pad, ivec=0),
1496 ivec=0)
1498 verify_mic decrypt, compute DES MAC using confounder, compare
1500 The des-mac checksum algorithm is assigned a checksum type number of
1501 four (4).
1503 6.2.8. DES CBC Checksum Alternative
1505 The DES-MAC-K checksum is computed by performing a DES CBC-mode
1506 encryption of the plaintext, with zero-valued padding bytes if
1507 necessary to bring the length to a multiple of eight octets, and by
1508 using the last block of the ciphertext as the checksum value. It is
1509 keyed with an encryption key that is also used as the initialization
1510 vector. The resulting checksum is 64 bits (eight octets) long. This
1514 Raeburn Standards Track [Page 27]
1515 \f
1516 RFC 3961 Encryption and Checksum Specifications February 2005
1519 checksum is tamper-proof and collision-proof. Note that this
1520 checksum type is the old method for encoding the DESMAC checksum; it
1521 is no longer recommended.
1523 des-mac-k
1524 ----------------------------------------------------------------
1525 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1527 get_mic des-mac(key, msg | pad, ivec=key)
1529 verify_mic compute MAC and compare
1531 The des-mac-k checksum algorithm is assigned a checksum type number
1532 of five (5).
1534 6.3. Triple-DES Based Encryption and Checksum Types
1536 This encryption and checksum type pair is based on the Triple DES
1537 cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message
1538 authentication algorithm.
1540 A Triple DES key is the concatenation of three DES keys as described
1541 above for des-cbc-md5. A Triple DES key is generated from random
1542 data by creating three DES keys from separate sequences of random
1543 data.
1545 Encrypted data using this type must be generated as described in
1546 section 5.3. If the length of the input data is not a multiple of
1547 the block size, zero-valued octets must be used to pad the plaintext
1548 to the next eight-octet boundary. The confounder must be eight
1549 random octets (one block).
1551 The simplified profile for Triple DES, with key derivation as defined
1552 in section 5, is as follows:
1554 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
1555 ------------------------------------------------
1556 protocol key format 24 bytes, parity in low
1557 bit of each
1559 key-generation seed 21 bytes
1560 length
1570 Raeburn Standards Track [Page 28]
1571 \f
1572 RFC 3961 Encryption and Checksum Specifications February 2005
1575 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
1576 ------------------------------------------------
1577 hash function SHA-1
1579 HMAC output size 160 bits
1581 message block size 8 bytes
1583 default string-to-key empty string
1584 params
1586 encryption and triple-DES encrypt and
1587 decryption functions decrypt, in outer-CBC
1588 mode (cipher block size
1589 8 octets)
1591 key generation functions:
1593 random-to-key DES3random-to-key (see
1594 below)
1596 string-to-key DES3string-to-key (see
1597 below)
1599 The des3-cbc-hmac-sha1-kd encryption type is assigned the value
1600 sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a
1601 checksum type number of twelve (12).
1603 6.3.1. Triple DES Key Production (random-to-key, string-to-key)
1605 The 168 bits of random key data are converted to a protocol key value
1606 as follows. First, the 168 bits are divided into three groups of 56
1607 bits, which are expanded individually into 64 bits as follows:
1609 DES3random-to-key:
1610 1 2 3 4 5 6 7 p
1611 9 10 11 12 13 14 15 p
1612 17 18 19 20 21 22 23 p
1613 25 26 27 28 29 30 31 p
1614 33 34 35 36 37 38 39 p
1615 41 42 43 44 45 46 47 p
1616 49 50 51 52 53 54 55 p
1617 56 48 40 32 24 16 8 p
1619 The "p" bits are parity bits computed over the data bits. The output
1620 of the three expansions, each corrected to avoid "weak" and "semi-
1621 weak" keys as in section 6.2, are concatenated to form the protocol
1622 key value.
1626 Raeburn Standards Track [Page 29]
1627 \f
1628 RFC 3961 Encryption and Checksum Specifications February 2005
1631 The string-to-key function is used to transform UTF-8 passwords into
1632 DES3 keys. The DES3 string-to-key function relies on the "N-fold"
1633 algorithm and DK function, described in section 5.
1635 The n-fold algorithm is applied to the password string concatenated
1636 with a salt value. For 3-key triple DES, the operation will involve
1637 a 168-fold of the input password string, to generate an intermediate
1638 key, from which the user's long-term key will be derived with the DK
1639 function. The DES3 string-to-key function is shown here in
1640 pseudocode:
1642 DES3string-to-key(passwordString, salt, params)
1643 if (params != emptyString)
1644 error("invalid params");
1645 s = passwordString + salt
1646 tmpKey = random-to-key(168-fold(s))
1647 key = DK (tmpKey, KerberosConstant)
1649 Weak key checking is performed in the random-to-key and DK
1650 operations. The KerberosConstant value is the byte string {0x6b 0x65
1651 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII
1652 encoding for the string "kerberos".
1654 7. Use of Kerberos Encryption Outside This Specification
1656 Several Kerberos-based application protocols and preauthentication
1657 systems have been designed and deployed that perform encryption and
1658 message integrity checks in various ways. Although in some cases
1659 there may be good reason for specifying these protocols in terms of
1660 specific encryption or checksum algorithms, we anticipate that in
1661 many cases this will not be true, and more generic approaches
1662 independent of particular algorithms will be desirable. Rather than
1663 have each protocol designer reinvent schemes for protecting data,
1664 using multiple keys, etc., we have attempted to present in this
1665 section a general framework that should be sufficient not only for
1666 the Kerberos protocol itself but also for many preauthentication
1667 systems and application protocols, while trying to avoid some of the
1668 assumptions that can work their way into such protocol designs.
1670 Some problematic assumptions we've seen (and sometimes made) include
1671 the following: a random bitstring is always valid as a key (not true
1672 for DES keys with parity); the basic block encryption chaining mode
1673 provides no integrity checking, or can easily be separated from such
1674 checking (not true for many modes in development that do both
1675 simultaneously); a checksum for a message always results in the same
1676 value (not true if a confounder is incorporated); an initial vector
1677 is used (may not be true if a block cipher in CBC mode is not in
1678 use).
1682 Raeburn Standards Track [Page 30]
1683 \f
1684 RFC 3961 Encryption and Checksum Specifications February 2005
1687 Although such assumptions the may hold for any given set of
1688 encryption and checksum algorithms, they may not be true of the next
1689 algorithms to be defined, leaving the application protocol unable to
1690 make use of those algorithms without updates to its specification.
1692 The Kerberos protocol uses only the attributes and operations
1693 described in sections 3 and 4. Preauthentication systems and
1694 application protocols making use of Kerberos are encouraged to use
1695 them as well. The specific key and string-to-key parameters should
1696 generally be treated as opaque. Although the string-to-key
1697 parameters are manipulated as an octet string, the representation for
1698 the specific key structure is implementation defined; it may not even
1699 be a single object.
1701 We don't recommend doing so, but some application protocols will
1702 undoubtedly continue to use the key data directly, even if only in
1703 some of the currently existing protocol specifications. An
1704 implementation intended to support general Kerberos applications may
1705 therefore need to make the key data available, as well as the
1706 attributes and operations described in sections 3 and 4 [8].
1708 8. Assigned Numbers
1710 The following encryption-type numbers are already assigned or
1711 reserved for use in Kerberos and related protocols.
1713 encryption type etype section or comment
1714 -----------------------------------------------------------------
1715 des-cbc-crc 1 6.2.3
1716 des-cbc-md4 2 6.2.2
1717 des-cbc-md5 3 6.2.1
1718 [reserved] 4
1719 des3-cbc-md5 5
1720 [reserved] 6
1721 des3-cbc-sha1 7
1722 dsaWithSHA1-CmsOID 9 (pkinit)
1723 md5WithRSAEncryption-CmsOID 10 (pkinit)
1724 sha1WithRSAEncryption-CmsOID 11 (pkinit)
1725 rc2CBC-EnvOID 12 (pkinit)
1726 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
1727 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
1728 des-ede3-cbc-Env-OID 15 (pkinit)
1729 des3-cbc-sha1-kd 16 6.3
1730 aes128-cts-hmac-sha1-96 17 [KRB5-AES]
1731 aes256-cts-hmac-sha1-96 18 [KRB5-AES]
1732 rc4-hmac 23 (Microsoft)
1733 rc4-hmac-exp 24 (Microsoft)
1734 subkey-keymaterial 65 (opaque; PacketCable)
1738 Raeburn Standards Track [Page 31]
1739 \f
1740 RFC 3961 Encryption and Checksum Specifications February 2005
1743 (The "des3-cbc-sha1" assignment is a deprecated version using no key
1744 derivation. It should not be confused with des3-cbc-sha1-kd.)
1746 Several numbers have been reserved for use in encryption systems not
1747 defined here. Encryption-type numbers have unfortunately been
1748 overloaded on occasion in Kerberos-related protocols, so some of the
1749 reserved numbers do not and will not correspond to encryption systems
1750 fitting the profile presented here.
1752 The following checksum-type numbers are assigned or reserved. As
1753 with encryption-type numbers, some overloading of checksum numbers
1754 has occurred.
1756 Checksum type sumtype checksum section or
1757 value size reference
1758 ---------------------------------------------------------------------
1759 CRC32 1 4 6.1.3
1760 rsa-md4 2 16 6.1.2
1761 rsa-md4-des 3 24 6.2.5
1762 des-mac 4 16 6.2.7
1763 des-mac-k 5 8 6.2.8
1764 rsa-md4-des-k 6 16 6.2.6
1765 rsa-md5 7 16 6.1.1
1766 rsa-md5-des 8 24 6.2.4
1767 rsa-md5-des3 9 24 ??
1768 sha1 (unkeyed) 10 20 ??
1769 hmac-sha1-des3-kd 12 20 6.3
1770 hmac-sha1-des3 13 20 ??
1771 sha1 (unkeyed) 14 20 ??
1772 hmac-sha1-96-aes128 15 20 [KRB5-AES]
1773 hmac-sha1-96-aes256 16 20 [KRB5-AES]
1774 [reserved] 0x8003 ? [GSS-KRB5]
1776 Encryption and checksum-type numbers are signed 32-bit values. Zero
1777 is invalid, and negative numbers are reserved for local use. All
1778 standardized values must be positive.
1780 9. Implementation Notes
1782 The "interface" described here is the minimal information that must
1783 be defined to make a cryptosystem useful within Kerberos in an
1784 interoperable fashion. The use of functional notation used in some
1785 places is not an attempt to define an API for cryptographic
1786 functionality within Kerberos. Actual implementations providing
1787 clean APIs will probably make additional information available, that
1788 could be derived from a specification written to the framework given
1789 here. For example, an application designer may wish to determine the
1790 largest number of bytes that can be encrypted without overflowing a
1794 Raeburn Standards Track [Page 32]
1795 \f
1796 RFC 3961 Encryption and Checksum Specifications February 2005
1799 certain size output buffer or conversely, the maximum number of bytes
1800 that might be obtained by decrypting a ciphertext message of a given
1801 size. (In fact, an implementation of the GSS-API Kerberos mechanism
1802 [GSS-KRB5] will require some of these.)
1804 The presence of a mechanism in this document should not be taken to
1805 indicate that it must be implemented for compliance with any
1806 specification; required mechanisms will be specified elsewhere.
1807 Indeed, some of the mechanisms described here for backward
1808 compatibility are now considered rather weak for protecting critical
1809 data.
1811 10. Security Considerations
1813 Recent years have brought so many advancements in large-scale attacks
1814 capability against DES that it is no longer considered a strong
1815 encryption mechanism. Triple-DES is generally preferred in its
1816 place, despite its poorer performance. See [ESP-DES] for a summary
1817 of some of the potential attacks and [EFF-DES] for a detailed
1818 discussion of the implementation of particular attacks. However,
1819 most Kerberos implementations still have DES as their primary
1820 interoperable encryption type.
1822 DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
1823 single-DES here avoids them. However, DES also has 48 'possibly-
1824 weak' keys [Schneier96] (note that the tables in many editions of the
1825 reference contains errors) that are not avoided.
1827 DES weak keys have the property that E1(E1(P)) = P (where E1 denotes
1828 encryption of a single block with key 1). DES semi-weak keys, or
1829 "dual" keys, are pairs of keys with the property that E1(P) = D2(P),
1830 and thus E2(E1(P)) = P. Because of the use of CBC mode and the
1831 leading random confounder, however, these properties are unlikely to
1832 present a security problem.
1834 Many of the choices concerning when to perform weak-key corrections
1835 relate more to compatibility with existing implementations than to
1836 any risk analysis.
1838 Although checks are also done for the component DES keys in a
1839 triple-DES key, the nature of the weak keys make it extremely
1840 unlikely that they will weaken the triple-DES encryption. It is only
1841 slightly more likely than having the middle of the three sub-keys
1842 match one of the other two, which effectively converts the encryption
1843 to single-DES - a case we make no effort to avoid.
1850 Raeburn Standards Track [Page 33]
1851 \f
1852 RFC 3961 Encryption and Checksum Specifications February 2005
1855 The true CRC-32 checksum is not collision-proof; an attacker could
1856 use a probabilistic chosen-plaintext attack to generate a valid
1857 message even if a confounder is used [SG92]. The use of collision-
1858 proof checksums is of course recommended for environments where such
1859 attacks represent a significant threat. The "simplifications" (read:
1860 bugs) introduced when CRC-32 was implemented for Kerberos cause
1861 leading zeros effectively to be ignored, so messages differing only
1862 in leading zero bits will have the same checksum.
1864 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
1865 Unlike [IPSEC-HMAC], the triple-DES specification here does not use
1866 the suggested truncation of the HMAC output. As pointed out in
1867 [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash
1868 function, which is a criterion of HMAC. [HMAC-TEST] contains test
1869 vectors for HMAC-SHA-1.
1871 The mit_des_string_to_key function was originally constructed with
1872 the assumption that all input would be ASCII; it ignores the top bit
1873 of each input byte. Folding with XOR is also not an especially good
1874 mixing mechanism for preserving randomness.
1876 The n-fold function used in the string-to-key operation for des3-
1877 cbc-hmac-sha1-kd was designed to cause each bit of input to
1878 contribute equally to the output. It was not designed to maximize or
1879 equally distribute randomness in the input, and conceivably
1880 randomness may be lost in cases of partially structured input. This
1881 should only be an issue for highly structured passwords, however.
1883 [RFC1851] discusses the relative strength of triple-DES encryption.
1884 The relatively slow speed of triple-DES encryption may also be an
1885 issue for some applications.
1887 [Bellovin91] suggests that analyses of encryption schemes include a
1888 model of an attacker capable of submitting known plaintexts to be
1889 encrypted with an unknown key, as well as be able to perform many
1890 types of operations on known protocol messages. Recent experiences
1891 with the chosen-plaintext attacks on Kerberos version 4 bear out the
1892 value of this suggestion.
1894 The use of unkeyed encrypted checksums, such as those used in the
1895 single-DES cryptosystems specified in [Kerb1510], allows for cut-
1896 and-paste attacks, especially if a confounder is not used. In
1897 addition, unkeyed encrypted checksums are vulnerable to chosen-
1898 plaintext attacks: An attacker with access to an encryption oracle
1899 can easily encrypt the required unkeyed checksum along with the
1906 Raeburn Standards Track [Page 34]
1907 \f
1908 RFC 3961 Encryption and Checksum Specifications February 2005
1911 chosen plaintext. [Bellovin99] These weaknesses, combined with a
1912 common implementation design choice described below, allow for a
1913 cross-protocol attack from version 4 to version 5.
1915 The use of a random confounder is an important means to prevent an
1916 attacker from making effective use of protocol exchanges as an
1917 encryption oracle. In Kerberos version 4, the encryption of constant
1918 plaintext to constant ciphertext makes an effective encryption oracle
1919 for an attacker. The use of random confounders in [Kerb1510]
1920 frustrates this sort of chosen-plaintext attack.
1922 Using the same key for multiple purposes can enable or increase the
1923 scope of chosen-plaintext attacks. Some software that implements
1924 both versions 4 and 5 of the Kerberos protocol uses the same keys for
1925 both versions. This enables the encryption oracle of version 4 to be
1926 used to attack version 5. Vulnerabilities to attacks such as this
1927 cross-protocol attack make it unwise to use a key for multiple
1928 purposes.
1930 This document, like the Kerberos protocol, does not address limiting
1931 the amount of data a key may be used with to a quantity based on the
1932 robustness of the algorithm or size of the key. It is assumed that
1933 any defined algorithms and key sizes will be strong enough to support
1934 very large amounts of data, or they will be deprecated once
1935 significant attacks are known.
1937 This document also places no bounds on the amount of data that can be
1938 handled in various operations. To avoid denial of service attacks,
1939 implementations will probably seek to restrict message sizes at some
1940 higher level.
1942 11. IANA Considerations
1944 Two registries for numeric values have been created: Kerberos
1945 Encryption Type Numbers and Kerberos Checksum Type Numbers. These
1946 are signed values ranging from -2147483648 to 2147483647. Positive
1947 values should be assigned only for algorithms specified in accordance
1948 with this specification for use with Kerberos or related protocols.
1949 Negative values are for private use; local and experimental
1950 algorithms should use these values. Zero is reserved and may not be
1951 assigned.
1953 Positive encryption- and checksum-type numbers may be assigned
1954 following either of two policies described in [BCP26].
1956 Standards-track specifications may be assigned values under the
1957 Standards Action policy.
1962 Raeburn Standards Track [Page 35]
1963 \f
1964 RFC 3961 Encryption and Checksum Specifications February 2005
1967 Specifications in non-standards track RFCs may be assigned values
1968 after Expert Review. A non-IETF specification may be assigned values
1969 by publishing an Informational or standards-track RFC referencing the
1970 external specification; that specification must be public and
1971 published in some permanent record, much like the IETF RFCs. It is
1972 highly desirable, though not required, that the full specification be
1973 published as an IETF RFC.
1975 Smaller encryption type values should be used for IETF standards-
1976 track mechanisms, and much higher values (16777216 and above) for
1977 other mechanisms. (Rationale: In the Kerberos ASN.1 encoding,
1978 smaller numbers encode to smaller octet sequences, so this favors
1979 standards-track mechanisms with slightly smaller messages.) Aside
1980 from that guideline, IANA may choose numbers as it sees fit.
1982 Internet-Draft specifications should not include values for
1983 encryption- and checksum-type numbers. Instead, they should indicate
1984 that values would be assigned by IANA when the document is approved
1985 as an RFC. For development and interoperability testing, values in
1986 the private-use range (negative values) may be used but should not be
1987 included in the draft specification.
1989 Each registered value should have an associated unique reference
1990 name. The lists given in section 8 were used to create the initial
1991 registry; they include reservations for specifications in progress in
1992 parallel with this document, and certain other values believed to
1993 already be in use.
1995 12. Acknowledgements
1997 This document is an extension of the encryption specification
1998 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
1999 of the text of the background, concepts, and DES specifications is
2000 drawn directly from that document.
2002 The abstract framework presented in this document was put together by
2003 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
2004 and Tom Yu, and the details were refined several times based on
2005 comments from John Brezak and others.
2007 Marc Horowitz wrote the original specification of triple-DES and key
2008 derivation in a pair of Internet-Drafts (under the names draft-
2009 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that
2010 were later folded into a draft revision of [Kerb1510], from which
2011 this document was later split off.
2018 Raeburn Standards Track [Page 36]
2019 \f
2020 RFC 3961 Encryption and Checksum Specifications February 2005
2023 Tom Yu provided the text describing the modifications to the standard
2024 CRC algorithm as Kerberos implementations actually use it, and some
2025 of the text in the Security Considerations section.
2027 Miroslav Jurisic provided information for one of the UTF-8 test cases
2028 for the string-to-key functions.
2030 Marcus Watts noticed some errors in earlier versions and pointed out
2031 that the simplified profile could easily be modified to support
2032 cipher text stealing modes.
2034 Simon Josefsson contributed some clarifications to the DES "CBC
2035 checksum" and string-to-key and weak key descriptions, and some test
2036 vectors.
2038 Simon Josefsson, Louis LeVay, and others also caught some errors in
2039 earlier versions of this document.
2074 Raeburn Standards Track [Page 37]
2075 \f
2076 RFC 3961 Encryption and Checksum Specifications February 2005
2079 A. Test Vectors
2081 This section provides test vectors for various functions defined or
2082 described in this document. For convenience, most inputs are ASCII
2083 strings, though some UTF-8 samples are provided for string-to-key
2084 functions. Keys and other binary data are specified as hexadecimal
2085 strings.
2087 A.1. n-fold
2089 The n-fold function is defined in section 5.1. As noted there, the
2090 sample vector in the original paper defining the algorithm appears to
2091 be incorrect. Here are some test cases provided by Marc Horowitz and
2092 Simon Josefsson:
2094 64-fold("012345") =
2095 64-fold(303132333435) = be072631276b1955
2097 56-fold("password") =
2098 56-fold(70617373776f7264) = 78a07b6caf85fa
2100 64-fold("Rough Consensus, and Running Code") =
2101 64-fold(526f75676820436f6e73656e7375732c20616e642052756e
2102 6e696e6720436f6465) = bb6ed30870b7f0e0
2104 168-fold("password") =
2105 168-fold(70617373776f7264) =
2106 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
2108 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
2109 192-fold(4d41535341434856534554545320494e5354495456544520
2110 4f4620544543484e4f4c4f4759) =
2111 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
2113 168-fold("Q") =
2114 168-fold(51) =
2115 518a54a2 15a8452a 518a54a2 15a8452a
2116 518a54a2 15
2118 168-fold("ba") =
2119 168-fold(6261) =
2120 fb25d531 ae897449 9f52fd92 ea9857c4
2121 ba24cf29 7e
2123 Here are some additional values corresponding to folded values of the
2124 string "kerberos"; the 64-bit form is used in the des3 string-to-key
2125 (section 6.3.1).
2130 Raeburn Standards Track [Page 38]
2131 \f
2132 RFC 3961 Encryption and Checksum Specifications February 2005
2135 64-fold("kerberos") =
2136 6b657262 65726f73
2137 128-fold("kerberos") =
2138 6b657262 65726f73 7b9b5b2b 93132b93
2139 168-fold("kerberos") =
2140 8372c236 344e5f15 50cd0747 e15d62ca
2141 7a5a3bce a4
2142 256-fold("kerberos") =
2143 6b657262 65726f73 7b9b5b2b 93132b93
2144 5c9bdcda d95c9899 c4cae4de e6d6cae4
2146 Note that the initial octets exactly match the input string when the
2147 output length is a multiple of the input length.
2149 A.2. mit_des_string_to_key
2151 The function mit_des_string_to_key is defined in section 6.2. We
2152 present here several test values, with some of the intermediate
2153 results. The fourth test demonstrates the use of UTF-8 with three
2154 characters. The last two tests are specifically constructed so as to
2155 trigger the weak-key fixups for the intermediate key produced by
2156 fan-folding; we have no test cases that cause such fixups for the
2157 final key.
2159 UTF-8 encodings used in test vector:
2160 eszett U+00DF C3 9F s-caron U+0161 C5 A1
2161 c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E
2163 Test vector:
2165 salt: "ATHENA.MIT.EDUraeburn"
2166 415448454e412e4d49542e4544557261656275726e
2167 password: "password" 70617373776f7264
2168 fan-fold result: c01e38688ac86c2e
2169 intermediate key: c11f38688ac86d2f
2170 DES key: cbc22fae235298e3
2172 salt: "WHITEHOUSE.GOVdanny"
2173 5748495445484f5553452e474f5664616e6e79
2174 password: "potatoe" 706f7461746f65
2175 fan-fold result: a028944ee63c0416
2176 intermediate key: a129944fe63d0416
2177 DES key: df3d32a74fd92a01
2179 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374
2180 password: g-clef (U+1011E) f09d849e
2181 fan-fold result: 3c4a262c18fab090
2182 intermediate key: 3d4a262c19fbb091
2186 Raeburn Standards Track [Page 39]
2187 \f
2188 RFC 3961 Encryption and Checksum Specifications February 2005
2191 DES key: 4ffb26bab0cd9413
2193 salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
2194 415448454e412e4d49542e4544554a757269c5a169c487
2195 password: eszett(U+00DF)
2196 c39f
2197 fan-fold result:b8f6c40e305afc9e
2198 intermediate key: b9f7c40e315bfd9e
2199 DES key: 62c81a5232b5e69d
2201 salt: "AAAAAAAA" 4141414141414141
2202 password: "11119999" 3131313139393939
2203 fan-fold result: e0e0e0e0f0f0f0f0
2204 intermediate key: e0e0e0e0f1f1f101
2205 DES key: 984054d0f1a73e31
2207 salt: "FFFFAAAA" 4646464641414141
2208 password: "NNNN6666" 4e4e4e4e36363636
2209 fan-fold result: 1e1e1e1e0e0e0e0e
2210 intermediate key: 1f1f1f1f0e0e0efe
2211 DES key: c4bf6b25adf7a4f8
2213 This trace provided by Simon Josefsson shows the intermediate
2214 processing stages of one of the test inputs:
2216 string_to_key (des-cbc-md5, string, salt)
2217 ;; string:
2218 ;; `password' (length 8 bytes)
2219 ;; 70 61 73 73 77 6f 72 64
2220 ;; salt:
2221 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
2222 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
2223 ;; 65 62 75 72 6e
2224 des_string_to_key (string, salt)
2225 ;; String:
2226 ;; `password' (length 8 bytes)
2227 ;; 70 61 73 73 77 6f 72 64
2228 ;; Salt:
2229 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
2230 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
2231 ;; 65 62 75 72 6e
2232 odd = 1;
2233 s = string | salt;
2234 tempstring = 0; /* 56-bit string */
2235 pad(s); /* with nulls to 8 byte boundary */
2236 ;; s = pad(string|salt):
2237 ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
2238 ;; (length 32 bytes)
2242 Raeburn Standards Track [Page 40]
2243 \f
2244 RFC 3961 Encryption and Checksum Specifications February 2005
2247 ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d
2248 ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00
2249 for (8byteblock in s) {
2250 ;; loop iteration 0
2251 ;; 8byteblock:
2252 ;; `password' (length 8 bytes)
2253 ;; 70 61 73 73 77 6f 72 64
2254 ;; 01110000 01100001 01110011 01110011 01110111 01101111
2255 ;; 01110010 01100100
2256 56bitstring = removeMSBits(8byteblock);
2257 ;; 56bitstring:
2258 ;; 1110000 1100001 1110011 1110011 1110111 1101111
2259 ;; 1110010 1100100
2260 if (odd == 0) reverse(56bitstring); ;; odd=1
2261 odd = ! odd
2262 tempstring = tempstring XOR 56bitstring;
2263 ;; tempstring
2264 ;; 1110000 1100001 1110011 1110011 1110111 1101111
2265 ;; 1110010 1100100
2267 for (8byteblock in s) {
2268 ;; loop iteration 1
2269 ;; 8byteblock:
2270 ;; `ATHENA.M' (length 8 bytes)
2271 ;; 41 54 48 45 4e 41 2e 4d
2272 ;; 01000001 01010100 01001000 01000101 01001110 01000001
2273 ;; 00101110 01001101
2274 56bitstring = removeMSBits(8byteblock);
2275 ;; 56bitstring:
2276 ;; 1000001 1010100 1001000 1000101 1001110 1000001
2277 ;; 0101110 1001101
2278 if (odd == 0) reverse(56bitstring); ;; odd=0
2279 reverse(56bitstring)
2280 ;; 56bitstring after reverse
2281 ;; 1011001 0111010 1000001 0111001 1010001 0001001
2282 ;; 0010101 1000001
2283 odd = ! odd
2284 tempstring = tempstring XOR 56bitstring;
2285 ;; tempstring
2286 ;; 0101001 1011011 0110010 1001010 0100110 1100110
2287 ;; 1100111 0100101
2289 for (8byteblock in s) {
2290 ;; loop iteration 2
2291 ;; 8byteblock:
2292 ;; `IT.EDUra' (length 8 bytes)
2293 ;; 49 54 2e 45 44 55 72 61
2294 ;; 01001001 01010100 00101110 01000101 01000100 01010101
2298 Raeburn Standards Track [Page 41]
2299 \f
2300 RFC 3961 Encryption and Checksum Specifications February 2005
2303 ;; 01110010 01100001
2304 56bitstring = removeMSBits(8byteblock);
2305 ;; 56bitstring:
2306 ;; 1001001 1010100 0101110 1000101 1000100 1010101
2307 ;; 1110010 1100001
2308 if (odd == 0) reverse(56bitstring); ;; odd=1
2309 odd = ! odd
2310 tempstring = tempstring XOR 56bitstring;
2311 ;; tempstring
2312 ;; 1100000 0001111 0011100 0001111 1100010 0110011
2313 ;; 0010101 1000100
2315 for (8byteblock in s) {
2316 ;; loop iteration 3
2317 ;; 8byteblock:
2318 ;; `eburn\x00\x00\x00' (length 8 bytes)
2319 ;; 65 62 75 72 6e 00 00 00
2320 ;; 01100101 01100010 01110101 01110010 01101110 00000000
2321 ;; 00000000 00000000
2322 56bitstring = removeMSBits(8byteblock);
2323 ;; 56bitstring:
2324 ;; 1100101 1100010 1110101 1110010 1101110 0000000
2325 ;; 0000000 0000000
2326 if (odd == 0) reverse(56bitstring); ;; odd=0
2327 reverse(56bitstring)
2328 ;; 56bitstring after reverse
2329 ;; 0000000 0000000 0000000 0111011 0100111 1010111
2330 ;; 0100011 1010011
2331 odd = ! odd
2332 tempstring = tempstring XOR 56bitstring;
2333 ;; tempstring
2334 ;; 1100000 0001111 0011100 0110100 1000101 1100100
2335 ;; 0110110 0010111
2337 for (8byteblock in s) {
2338 }
2339 ;; for loop terminated
2341 tempkey = key_correction(add_parity_bits(tempstring));
2342 ;; tempkey
2343 ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
2344 ;; c1 1f 38 68 8a c8 6d 2f
2345 ;; 11000001 00011111 00111000 01101000 10001010 11001000
2346 ;; 01101101 00101111
2348 key = key_correction(DES-CBC-check(s,tempkey));
2349 ;; key
2350 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
2354 Raeburn Standards Track [Page 42]
2355 \f
2356 RFC 3961 Encryption and Checksum Specifications February 2005
2359 ;; cb c2 2f ae 23 52 98 e3
2360 ;; 11001011 11000010 00101111 10101110 00100011 01010010
2361 ;; 10011000 11100011
2363 ;; string_to_key key:
2364 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
2365 ;; cb c2 2f ae 23 52 98 e3
2367 A.3. DES3 DR and DK
2369 These tests show the derived-random and derived-key values for the
2370 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
2371 defined in section 6.3.1. The input keys were randomly generated;
2372 the usage values are from this specification.
2374 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
2375 usage: 0000000155
2376 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
2377 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
2379 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
2380 usage: 00000001aa
2381 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
2382 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
2384 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
2385 usage: 0000000155
2386 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
2387 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
2389 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
2390 usage: 00000001aa
2391 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
2392 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
2394 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
2395 usage: 6b65726265726f73 ("kerberos")
2396 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
2397 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
2399 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
2400 usage: 0000000155
2401 DR: 348056ec98fcc517171d2b4d7a9493af482d999175
2402 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
2404 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
2405 usage: 00000001aa
2406 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
2410 Raeburn Standards Track [Page 43]
2411 \f
2412 RFC 3961 Encryption and Checksum Specifications February 2005
2415 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
2417 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
2418 usage: 0000000155
2419 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
2420 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
2422 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
2423 usage: 00000001aa
2424 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
2425 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
2427 A.4. DES3string_to_key
2429 These are the keys generated for some of the above input strings for
2430 triple-DES with key derivation as defined in section 6.3.1.
2432 salt: "ATHENA.MIT.EDUraeburn"
2433 passwd: "password"
2434 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
2436 salt: "WHITEHOUSE.GOVdanny"
2437 passwd: "potatoe"
2438 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
2440 salt: "EXAMPLE.COMbuckaroo"
2441 passwd: "penny"
2442 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
2444 salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
2445 + c-acute(U+0107)
2446 passwd: eszett(U+00DF)
2447 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
2449 salt: "EXAMPLE.COMpianist"
2450 passwd: g-clef(U+1011E)
2451 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
2453 A.5. Modified CRC-32
2455 Below are modified-CRC32 values for various ASCII and octet strings.
2456 Only the printable ASCII characters are checksummed, without a C-
2457 style trailing zero-valued octet. The 32-bit modified CRC and the
2458 sequence of output bytes as used in Kerberos are shown. (The octet
2459 values are separated here to emphasize that they are octet values and
2460 not 32-bit numbers, which will be the most convenient form for
2461 manipulation in some implementations. The bit and byte order used
2466 Raeburn Standards Track [Page 44]
2467 \f
2468 RFC 3961 Encryption and Checksum Specifications February 2005
2471 internally for such a number is irrelevant; the octet sequence
2472 generated is what is important.)
2474 mod-crc-32("foo") = 33 bc 32 73
2475 mod-crc-32("test0123456789") = d6 88 3e b8
2476 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
2477 mod-crc-32(8000) = 4b 98 83 3b
2478 mod-crc-32(0008) = 32 88 db 0e
2479 mod-crc-32(0080) = 20 83 b8 ed
2480 mod-crc-32(80) = 20 83 b8 ed
2481 mod-crc-32(80000000) = 3b b6 59 ed
2482 mod-crc-32(00000001) = 96 30 07 77
2484 B. Significant Changes from RFC 1510
2486 The encryption and checksum mechanism profiles are new. The old
2487 specification defined a few operations for various mechanisms but
2488 didn't outline what abstract properties should be required of new
2489 mechanisms, or how to ensure that a mechanism specification is
2490 complete enough for interoperability between implementations. The
2491 new profiles differ from the old specification in a few ways:
2493 Some message definitions in [Kerb1510] could be read as permitting
2494 the initial vector to be specified by the application; the text
2495 was too vague. It is explicitly not permitted in this
2496 specification. Some encryption algorithms may not use
2497 initialization vectors, so relying on chosen, secret
2498 initialization vectors for security is unwise. Also, the
2499 prepended confounder in the existing algorithms is roughly
2500 equivalent to a per-message initialization vector that is revealed
2501 in encrypted form. However, carrying state across from one
2502 encryption to another is explicitly permitted through the opaque
2503 "cipher state" object.
2505 The use of key derivation is new.
2507 Several new methods are introduced, including generation of a key
2508 in wire-protocol format from random input data.
2510 The means for influencing the string-to-key algorithm are laid out
2511 more clearly.
2513 Triple-DES support is new.
2515 The pseudo-random function is new.
2517 The des-cbc-crc, DES string-to-key and CRC descriptions have been
2518 updated to align them with existing implementations.
2522 Raeburn Standards Track [Page 45]
2523 \f
2524 RFC 3961 Encryption and Checksum Specifications February 2005
2527 [Kerb1510] did not indicate what character set or encoding might be
2528 used for pass phrases and salts.
2530 In [Kerb1510], key types, encryption algorithms, and checksum
2531 algorithms were only loosely associated, and the association was not
2532 well described. In this specification, key types and encryption
2533 algorithms have a one-to-one correspondence, and associations between
2534 encryption and checksum algorithms are described so that checksums
2535 can be computed given negotiated keys, without requiring further
2536 negotiation for checksum types.
2538 Notes
2540 [1] Although Message Authentication Code (MAC) or Message Integrity
2541 Check (MIC) would be more appropriate terms for many of the uses
2542 in this document, we continue to use the term checksum for
2543 historical reasons.
2545 [2] Extending CBC mode across messages would be one obvious example
2546 of this chaining. Another might be the use of counter mode, with
2547 a counter randomly initialized and attached to the ciphertext; a
2548 second message could continue incrementing the counter when
2549 chaining the cipher state, thus avoiding having to transmit
2550 another counter value. However, this chaining is only useful for
2551 uninterrupted, ordered sequences of messages.
2553 [3] In the case of Kerberos, the encrypted objects will generally be
2554 ASN.1 DER encodings, which contain indications of their length in
2555 the first few octets.
2557 [4] As of the time of this writing, new modes of operation have been
2558 proposed, some of which may permit encryption and integrity
2559 protection simultaneously. After some of these proposals have
2560 been subjected to adequate analysis, we may wish to formulate a
2561 new simplified profile based on one of them.
2563 [5] It should be noted that the sample vector in appendix B.2 of the
2564 original paper appears to be incorrect. Two independent
2565 implementations from the specification (one in C by Marc
2566 Horowitz, and another in Scheme by Bill Sommerfeld) agree on a
2567 value different from that in [Blumenthal96].
2569 [6] For example, in MIT's implementation of [Kerb1510], the rsa-md5
2570 unkeyed checksum of application data may be included in an
2571 authenticator encrypted in a service's key.
2573 [7] Using a variant of the key limits the use of a key to a
2574 particular function, separating the functions of generating a
2578 Raeburn Standards Track [Page 46]
2579 \f
2580 RFC 3961 Encryption and Checksum Specifications February 2005
2583 checksum from other encryption performed using the session key.
2584 The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains
2585 key parity. The properties of DES precluded the use of the
2586 complement. The same constant is used for similar purpose in the
2587 Message Integrity Check in the Privacy Enhanced Mail standard.
2589 [8] Perhaps one of the more common reasons for directly performing
2590 encryption is direct control over the negotiation and to select a
2591 "sufficiently strong" encryption algorithm (whatever that means
2592 in the context of a given application). Although Kerberos
2593 directly provides no direct facility for negotiating encryption
2594 types between the application client and server, there are other
2595 means to accomplish similar goals (for example, requesting only
2596 "strong" session key types from the KDC, and assuming that the
2597 type actually returned by the KDC will be understood and
2598 supported by the application server).
2600 Normative References
2602 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
2603 an IANA Considerations Section in RFCs", BCP 26, RFC
2604 2434, October 1998.
2606 [Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P.
2607 Rogaway, "Relations Among Notions of Security for
2608 Public-Key Encryption Schemes". Extended abstract
2609 published in Advances in Cryptology-Crypto 98
2610 Proceedings, Lecture Notes in Computer Science Vol.
2611 1462, H. Krawcyzk ed., Springer-Verlag, 1998.
2613 [Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule
2614 for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96,
2615 1996.
2617 [CRC] International Organization for Standardization, "ISO
2618 Information Processing Systems - Data Communication -
2619 High-Level Data Link Control Procedure - Frame
2620 Structure," IS 3309, 3rd Edition, October 1984.
2622 [DES77] National Bureau of Standards, U.S. Department of
2623 Commerce, "Data Encryption Standard," Federal
2624 Information Processing Standards Publication 46,
2625 Washington, DC, 1977.
2634 Raeburn Standards Track [Page 47]
2635 \f
2636 RFC 3961 Encryption and Checksum Specifications February 2005
2639 [DESI81] National Bureau of Standards, U.S. Department of
2640 Commerce, "Guidelines for implementing and using NBS
2641 Data Encryption Standard," Federal Information
2642 Processing Standards Publication 74, Washington, DC,
2643 1981.
2645 [DESM80] National Bureau of Standards, U.S. Department of
2646 Commerce, "DES Modes of Operation," Federal
2647 Information Processing Standards Publication 81,
2648 Springfield, VA, December 1980.
2650 [Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable
2651 cryptography", Proceedings of the 23rd Annual
2652 Symposium on Theory of Computing, ACM, 1991.
2654 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
2655 Keyed-Hashing for Message Authentication", RFC 2104,
2656 February 1997.
2658 [KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES)
2659 Encryption for Kerberos 5", RFC 3962, February 2005.
2661 [MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC
2662 1320, April 1992.
2664 [MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
2665 1321, April 1992.
2667 [SG92] Stubblebine, S. and V. D. Gligor, "On Message
2668 Integrity in Cryptographic Protocols," in Proceedings
2669 of the IEEE Symposium on Research in Security and
2670 Privacy, Oakland, California, May 1992.
2672 Informative References
2674 [Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the
2675 Kerberos Authentication System", in Proceedings of the
2676 Winter 1991 Usenix Security Conference, January, 1991.
2678 [Bellovin99] Bellovin, S. M. and D. Atkins, private communications,
2679 1999.
2681 [EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets
2682 of Encryption Research, Wiretap Politics, and Chip
2683 Design", O'Reilly & Associates, Inc., May 1998.
2685 [ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
2686 Algorithm With Explicit IV", RFC 2405, November 1998.
2690 Raeburn Standards Track [Page 48]
2691 \f
2692 RFC 3961 Encryption and Checksum Specifications February 2005
2695 [GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
2696 RFC 1964, June 1996.
2698 [HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
2699 HMAC-SHA-1", RFC 2202, September 1997.
2701 [IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
2702 within ESP and AH", RFC 2404, November 1998.
2704 [Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
2705 Kerberos Network Authentication Service (V5)", Work in
2706 Progress, September 2004.
2708 [Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network
2709 Authentication Service (V5)", RFC 1510, September
2710 1993.
2712 [RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-
2713 CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October
2714 1996.
2716 [RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple
2717 DES Transform", RFC 1851, September 1995.
2719 [Schneier96] Schneier, B., "Applied Cryptography Second Edition",
2720 John Wiley & Sons, New York, NY, 1996. ISBN 0-471-
2721 12845-7.
2723 Editor's Address
2725 Kenneth Raeburn
2726 Massachusetts Institute of Technology
2727 77 Massachusetts Avenue
2728 Cambridge, MA 02139
2730 EMail: raeburn@mit.edu
2746 Raeburn Standards Track [Page 49]
2747 \f
2748 RFC 3961 Encryption and Checksum Specifications February 2005
2751 Full Copyright Statement
2753 Copyright (C) The Internet Society (2005).
2755 This document is subject to the rights, licenses and restrictions
2756 contained in BCP 78, and except as set forth therein, the authors
2757 retain all their rights.
2759 This document and the information contained herein are provided on an
2760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2762 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2763 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2764 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2765 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2767 Intellectual Property
2769 The IETF takes no position regarding the validity or scope of any
2770 Intellectual Property Rights or other rights that might be claimed to
2771 pertain to the implementation or use of the technology described in
2772 this document or the extent to which any license under such rights
2773 might or might not be available; nor does it represent that it has
2774 made any independent effort to identify any such rights. Information
2775 on the IETF's procedures with respect to rights in IETF Documents can
2776 be found in BCP 78 and BCP 79.
2778 Copies of IPR disclosures made to the IETF Secretariat and any
2779 assurances of licenses to be made available, or the result of an
2780 attempt made to obtain a general license or permission for the use of
2781 such proprietary rights by implementers or users of this
2782 specification can be obtained from the IETF on-line IPR repository at
2783 http://www.ietf.org/ipr.
2785 The IETF invites any interested party to bring to its attention any
2786 copyrights, patents or patent applications, or other proprietary
2787 rights that may cover technology that may be required to implement
2788 this standard. Please address the information to the IETF at ietf-
2789 ipr@ietf.org.
2791 Acknowledgement
2793 Funding for the RFC Editor function is currently provided by the
2794 Internet Society.
2802 Raeburn Standards Track [Page 50]
2803 \f