| blob | a13f67c5a08036d80e7cb2a2e1c4ab56cccde24b |
3 <Kerberos Working Group> Larry Zhu
4 Internet Draft Karthik Jaganathan
5 Updates: 1964 Microsoft
6 Category: Standards Track Sam Hartman
7 draft-ietf-krb-wg-gssapi-cfx-01.txt MIT
8 August 29, 2003
9 Expires: February 29, 2004
11 The Kerberos Version 5 GSS-API Mechanism: Version 2
13 Status of this Memo
15 This document is an Internet-Draft and is in full conformance with
16 all provisions of Section 10 of [RFC-2026].
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts. Internet-Drafts are draft documents valid for a maximum of
22 six months and may be updated, replaced, or obsoleted by other
23 documents at any time. It is inappropriate to use Internet- Drafts
24 as reference material or to cite them other than as "work in
25 progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
32 1. Abstract
34 [RFC-1964] defines protocols, procedures, and conventions to be
35 employed by peers implementing the Generic Security Service
36 Application Program Interface (as specified in [RFC-2743]) when
37 using the Kerberos Version 5 mechanism (as specified in [KRBCLAR]).
39 This memo obsoletes [RFC-1964] and proposes changes in response to
40 recent developments such as the introduction of Kerberos crypto
41 framework. It is intended that this memo or a subsequent version
42 will become the Kerberos Version 5 GSS-API mechanism specification
43 on the standards track.
45 2. Conventions used in this document
47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
49 document are to be interpreted as described in [RFC-2119].
51 3. Introduction
53 [KCRYPTO] defines a generic framework for describing encryption and
54 checksum types to be used with the Kerberos protocol and associated
55 protocols.
58 Zhu Standards Trace - February 16, 2003 1 \f
59 Kerberos Version 5 GSS-API August 2003
62 [RFC-1964] describes the GSSAPI mechanism for Kerberos V5. It
63 defines the format of context initiation, per-message and context
64 deletion tokens and uses algorithm identifiers for each cryptosystem
65 in per message and context deletion tokens.
67 The approach taken in this document obviates the need for algorithm
68 identifiers. This is accomplished by using the same encryption and
69 checksum algorithms specified by the crypto profile [KCRYPTO] for
70 the session key or subkey that is created during context
71 negotiation. Message layouts of the per-message and context
72 deletion tokens are therefore revised to remove algorithm indicators
73 and also to add extra information to support the generic crypto
74 framework [KCRYPTO].
76 Tokens transferred between GSS-API peers for security context
77 initiation are also described in this document. The data elements
78 exchanged between a GSS-API endpoint implementation and the Kerberos
79 KDC are not specific to GSS-API usage and are therefore defined
80 within [KRBCLAR] rather than within this specification.
82 The new token formats specified in this memo MUST be used with all
83 "newer" encryption types [KRBCLAR] and MAY be used with "older"
84 encryption types, provided that the initiator and acceptor know,
85 from the context establishment, that they can both process these new
86 token formats.
88 "Newer" encryption types are those which have been specified along
89 with or since the new Kerberos cryptosystem specification [KCRYPTO]
90 [KRBCLAR].
92 Note that in this document, "AES" is used for brevity to refer
93 loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96
94 as defined in [AES-KRB5]. AES is used as an example of the new
95 method defined in this document.
97 4. Key Derivation for Per-Message and Context Deletion Tokens
99 To limit the exposure of a given key, [KCRYPTO] adopted "one-way"
100 "entropy-preserving" derived keys, for different purposes or key
101 usages, from a base key or protocol key. This document defines four
102 key usage values below for signing and sealing messages:
104 Name value
105 -------------------------------------
106 KG-USAGE-ACCEPTOR-SEAL 22
107 KG-USAGE-ACCEPTOR-SIGN 23
108 KG-USAGE-INITIATOR-SEAL 24
109 KG-USAGE-INITIATOR-SIGN 25
111 When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
112 used as the usage number in the key derivation function for deriving
113 keys to be used in MIC and context deletion tokens, and KG-USAGE-
114 ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is
115 the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage
117 Zhu Standards Track - February 16, 2004 2 \f
118 Kerberos Version 5 GSS-API August 2003
121 number in the key derivation function for MIC and context deletion
122 tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens. Even if
123 the Wrap token does not provide for confidentiality the same usage
124 values specified above are used.
126 5. Quality of Protection
128 The GSSAPI specification [RFC-2743] provides for Quality of
129 Protection (QOP) values that can be used by the application to
130 request a certain type of encryption or signing. A zero QOP value
131 is used to indicate the "default" protection; applications which use
132 the default QOP are not guaranteed to be portable across
133 implementations or even inter-operate with different deployment
134 configurations of the same implementation. Using an algorithm that
135 is different from the one for which the key is defined may not be
136 appropriate. Therefore, when the new method in this document is
137 used, the QOP value is ignored.
139 The encryption and checksum algorithms in per-message and context
140 deletion tokens are now implicitly defined by the algorithms
141 associated with the session key or subkey. Algorithms identifiers
142 as described in [RFC-1964] are therefore no longer needed and
143 removed from the new token headers.
145 6. Token Framing
147 Per [RFC-2743], all tokens emitted by the Kerberos V5 GSS-API
148 mechanism will have the framing shown below:
150 GSS-API DEFINITIONS ::=
152 BEGIN
154 MechType ::= OBJECT IDENTIFIER
155 -- representing Kerberos V5 mechanism
157 GSSAPI-Token ::=
158 -- option indication (delegation, etc.) indicated within
159 -- mechanism-specific token
160 [APPLICATION 0] IMPLICIT SEQUENCE {
161 thisMech MechType,
162 innerToken ANY DEFINED BY thisMech
163 -- contents mechanism-specific
164 -- ASN.1 structure not required
165 }
166 END
168 The innerToken field always starts with a two byte token-identifier
169 (TOK_ID). Here are the TOK_ID values:
171 Token TOK_ID Value in hex
172 -------------------------------------------
173 KRB_AP_REQUEST 01 00
174 KRB_AP_REQPLY 02 00
176 Zhu Standards Track - February 16, 2004 3 \f
177 Kerberos Version 5 GSS-API August 2003
180 KRB_ERROR 03 00
181 [RFC-1964] MIC 01 01
182 [RFC-1964] Wrap 01 02
183 [RFC-1964] context deletion 02 01
184 MIC 04 04
185 Wrap 04 05
186 context deletion 05 04
189 7. Context Initialization Tokens
191 For context initialization tokens, the body for the innerToken field
192 contains a Kerberos V5 message (KRB_AP_REQUEST, KRB_AP_REPLY, or
193 KRB_ERROR) as defined in [KRBCLAR].
195 7.1. Authenticator Checksum
197 The authenticator in the KRB_AP_REQ message MUST include the
198 optional sequence number and the checksum field. The checksum field
199 is used to convey service flags, channel binding, and optional
200 delegation information. It MUST have a type of 0x8003. The length
201 of the checksum MUST be 24 bytes when delegation is not used. When
202 delegation is used, a TGT with its FORWARDABLE flag set will be
203 transferred within the KRB_CRED [KRBCLAR] message.
205 The format of the authenticator checksum field is as follows.
207 Byte Name Description
208 -----------------------------------------------------------------
209 0..3 Lgth Number of bytes in Bnd field;
210 Currently contains hex 10 00 00 00
211 (16, represented in little-endian form)
212 4..19 Bnd MD5 hash of channel bindings, taken over all
213 non-null components of bindings, in order
214 of declaration. Integer fields within channel
215 bindings are represented in little-endian order
216 for the purposes of the MD5 calculation.
217 20..23 Flags Bit vector of context-establishment flags,
218 as defined next. The resulting bit vector is
219 encoded into bytes 20..23 in little-endian form.
220 24..25 DlgOpt The Delegation Option identifier (=1) [optional]
221 26..27 Dlgth The length of the Deleg field [optional]
222 28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]
224 [we need to get input on how to allow additional data for
225 extensions. Nicolas will post some text for this. If that is the
226 case, do we need to change the checksum type?]
228 7.1.1. Flags Field
230 The checksum flags are used to convey service options or extension
231 negotiation information. The bits in the Flags field are allocated
232 as follows (Most significant bit is bit 0):
234 Zhu Standards Track - February 16, 2004 4 \f
235 Kerberos Version 5 GSS-API August 2003
238 Bit Name Description
239 ----------------------------------------------------
240 0..11 Mandatory Critical extension flags
241 12..15 Optional Non-critical extension flags
242 16..31 Standard Context establishment flags
244 An extension or context establishment flag can either be critical or
245 non-critical. When the context initiator desires a particular
246 extension or context establishment flag (either critical or non-
247 critical) it sets the appropriate checksum flag. The context
248 acceptor MUST ignore unsupported non-critical extensions or flags in
249 the initiator's context token (i.e., acceptors MUST NOT return an
250 error just because there were unsupported non-critical extensions or
251 flags in the initiator's token). The acceptor MUST return
252 GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical
253 extensions or flags in the initiator's context token.
255 The following context establishment flags are defined in [RFC-2744]
257 Flag Name Value
258 ---------------------------------
259 GSS_C_DELEG_FLAG 1
260 GSS_C_MUTUAL_FLAG 2
261 GSS_C_REPLAY_FLAG 4
262 GSS_C_SEQUENCE_FLAG 8
263 GSS_C_CONF_FLAG 16
264 GSS_C_INTEG_FLAG 32
265 GSS_C_ANON_FLAG 64
267 Context establishment flags are exposed to the calling application.
268 If the calling application desires a particular service option then
269 it requests that option via GSS_Init_sec_context(). An
270 implementation that supports a particular extension SHOULD then set
271 the appropriate flag in the checksum Flags field.
273 All existing context establishment flags are non-critical, and it is
274 possible that a new context establishment flag can be added as a
275 critical flag.
277 7.1.2. Channel Binding Information
279 In computing the contents of the "Bnd" field, the following detailed
280 points apply:
282 (1) Each integer field shall be formatted into four bytes, using
283 little-endian byte ordering, for purposes of MD5 hash computation.
285 (2) All input length fields within gss_buffer_desc [RFC-2744]
286 elements of a gss_channel_bindings_struct [RFC-2744], even those
287 which are zero-valued, shall be included in the hash calculation;
288 the value elements of gss_buffer_desc elements shall be
289 dereferenced, and the resulting data shall be included within the
290 hash computation, only for the case of gss_buffer_desc elements
291 having non-zero length specifiers.
293 Zhu Standards Track - February 16, 2004 5 \f
294 Kerberos Version 5 GSS-API August 2003
298 (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
299 valid channel bindings structure, the Bnd field shall be set to 16
300 zero-valued bytes.
302 [Nicolas suggested that the only change that might be needed here
303 was the use of SHA1 instead of MD5]
305 8. Per-Message and Context Deletion Tokens
307 The new per-message and context deletion token formats defined in
308 this document are designed to accommodate the requirements of newer
309 crypto systems. The token layouts have also been designed to
310 facilitate scatter-gather and in-place encryption without incurring
311 significant performance penalties for implementations that do not
312 allow for either scatter-gather or in-place encryption.
314 The design along with the rationale behind it is discussed in detail
315 in the following sections.
317 8.1. Sequence Number and Direction Indicator
319 The sequence number for any per-message or context deletion token is
320 a 64 bit integer (expressed in big endian order). One separate flag
321 is used as the direction-indicator as described in section 8.2.
322 Both the sequence number and the direction-indicator are protected
323 by the encryption and checksum procedures as specified in section
324 8.4.
326 8.2. Flags Field
328 The Flags field is a one-byte bit vector used to indicate a set of
329 attributes. The meanings of the flags are:
331 Bit Name Description
332 ---------------------------------------------------------------
333 0 SentByAcceptor When set, this flag indicates the sender
334 is the context acceptor. When not set,
335 it indicates the sender is the context
336 initiator.
337 1 Sealed When set in Wrap tokens, this flag
338 indicates confidentiality is provided
339 for. It MUST not be set in MIC and
340 context deletion tokens.
342 The rest of available bits are reserved for future use.
344 8.3. EC Field
346 The EC (Extra Count) field is a two-byte integer field expressed in
347 big endian order.
351 Zhu Standards Track - February 16, 2004 6 \f
352 Kerberos Version 5 GSS-API August 2003
355 In Wrap tokens with confidentiality, the EC field is used to encode
356 the size (in bytes) of the random filler, as described in section
357 8.4.
359 In Wrap tokens without confidentiality, the EC field is used to
360 encode the size (in bytes) of the trailing checksum, as described in
361 section 8.4.
363 When AES is used, the EC field contains the hex value 00 0C in Wrap
364 tokens without confidentiality, and 00 00 in Wrap tokens with
365 confidentiality.
367 8.4. Encryption and Checksum Operations
369 The encryption algorithms defined by the crypto profiles provide for
370 integrity protection. Therefore no separate checksum is needed.
372 The result of decryption can be longer than the original plaintext
373 [KCRYPTO] and the extra trailing bytes are called "crypto-system
374 garbage". However, given the size of any plaintext data, one can
375 always find the next (possibly larger) size so that, when padding
376 the to-be-encrypted text to that size, there will be no crypto-
377 system garbage added [KCRYPTO].
379 In Wrap tokens that provide for confidentiality, the "header" (the
380 first 16 bytes of the Wrap token) is appended to the plaintext data
381 before encryption. Random filler is inserted between the plaintext-
382 data and the "header", and there SHALL NOT be crypto-system garbage
383 added by the decryption operation. The resulting Wrap token is
384 {"header" | encrypt(plaintext-data | random-filler | "header")},
385 where encrypt() is the encryption operation (which provides for
386 integrity protection) defined in the crypto profile [KCRYPTO].
388 [A note from the design team (Sam, Nicolas, Ken, JK and Larry):
389 constraints need to be added to kcrypto to keep the header at the
390 end of the decrypted data. Without these constraints, we might have
391 the header pre-pended to the front of the data and encode an 8 byte
392 length for the plaintext data, which is less efficient.
394 Constraints to be added: Given the length of any plaintext data,
395 there should always exist the next (possibly larger) size for which,
396 when padding the to-be-encrypted data to that size, there will be no
397 cryptosystem garbage added, and the number of bytes needed to pad to
398 the next size is no larger than 64K. This is a small addition to
399 kcrypto and we will bring it up at the IETF last call for kcrypto]
401 In Wrap tokens that do not provide for confidentiality, the checksum
402 is calculated over the plaintext data concatenated with the token
403 header (the first 16 bytes of the Wrap token). The resulting Wrap
404 token is {"header" | plaintext-data | get_mic(plaintext-data |
405 "header")}, where get_mic() is the checksum operation defined in
406 the crypto profile [KCRYPTO].
409 Zhu Standards Track - February 16, 2004 7 \f
410 Kerberos Version 5 GSS-API August 2003
413 The parameters for the key and the cipher-state in the encrypt() and
414 get_mic() operations have been omitted for brevity.
416 The resulting Wrap tokens bind the data to the token header,
417 including the sequence number and the directional indicator.
419 [With AEAD, Wrap tokens with confidentiality do not need to encrypt
420 the header and the overhead can be reduced slightly]
422 For MIC tokens, the checksum is first calculated over the token
423 header (the first 16 bytes of the MIC token) and then the to-be-
424 signed plaintext data.
426 For context deletion tokens, the checksum is calculated over the
427 token header (the first 16 bytes of the context deletion token).
429 When AES is used, the checksum algorithm is HMAC_SHA1_96 and the
430 checksum size is 12 bytes. Data is pre-pended with a 16 byte
431 confounder before encryption, and no padding is needed.
433 8.5. RRC Field
435 The RRC (Right Rotation Count) field in Wrap tokens is added to
436 allow the data to be encrypted in-place by existing [SSPI]
437 applications that do not provide an additional buffer for the
438 trailer (the cipher text after the in-place-encrypted data) in
439 addition to the buffer for the header (the cipher text before the
440 in-place-encrypted data). The resulting Wrap token in the previous
441 section, excluding the first 16 bytes of the token header, is
442 rotated to the right by "RRC" bytes. The net result is that "RRC"
443 bytes of trailing octets are moved toward the header. Consider the
444 following as an example of this rotation operation: Assume that the
445 RRC value is 3 and the token before the rotation is {"header" | aa |
446 bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be
447 {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb
448 | cc |...| hh} is used to indicate the byte sequence.
450 The RRC field is expressed as a two-byte integer in big endian
451 order.
453 The rotation count value is chosen by the sender based on
454 implementation details, and the receiver MUST be able to interpret
455 all possible rotation count values.
457 8.6. Message Layout for Per-message and Context Deletion Tokens
459 The new message layouts are as follows.
461 MIC Token:
463 Byte no Name Description
464 0..1 TOK_ID Identification field.
465 Tokens emitted by GSS_GetMIC()
466 contain the hex value 04 04 in
468 Zhu Standards Track - February 16, 2004 8 \f
469 Kerberos Version 5 GSS-API August 2003
472 this field.
473 2 Flags Attributes field, as described in
474 Section 8.2.
475 3..7 Filler Contains 5 bytes of hex value FF.
476 8..15 SND_SEQ Sequence number field in
477 cleartext, in big endian order.
478 16..last SGN_CKSUM Checksum of byte 0..15 and the
479 "to-be-signed" data, where the
480 checksum algorithm is defined by
481 the crypto profile for the
482 session key or subkey.
485 The Filler field is included in the checksum calculation for
486 simplicity. This is common to both MIC and context deletion token
487 checksum calculations.
489 Wrap Token:
491 Byte no Name Description
492 0..1 TOK_ID Identification field.
493 Tokens emitted by GSS_Wrap()
494 contain the hex value 05 04
495 in this field.
496 2 Flags Attributes field, as described in
497 Section 8.2.
498 3 Filler Contains the hex value FF.
499 4..5 EC Contains the "extra count" field,
500 in big endian order as described in
501 section 8.3.
502 6..7 RRC Contains the "right rotation
503 count" in big endian order, as
504 described in section 8.5.
505 8..15 SND_SEQ Sequence number field in
506 cleartext, in big endian order.
507 16..last Data Encrypted data or (plaintext data +
508 checksum), as described in section
509 8.4, where the encryption or
510 checksum algorithm is defined by
511 the crypto profile for the session
512 key or subkey.
515 Context Deletion Token:
517 Byte no Name Description
518 0..1 TOK_ID Identification field.
519 Tokens emitted by
520 GSS_Delete_sec_context() contain
521 the hex value 04 05 in this
522 field.
523 2 Flags Attributes field, as described in
524 Section 8.2.
526 Zhu Standards Track - February 16, 2004 9 \f
527 Kerberos Version 5 GSS-API August 2003
530 3..7 Filler Contains 5 bytes of hex value FF.
531 8..15 SND_SEQ Sequence number field in
532 cleartext, in big endian order.
533 16..N SGN_CKSUM Checksum of byte 0..15, where the
534 checksum algorithm is defined by
535 the crypto profile for the
536 session key or subkey.
539 9. Parameter Definitions
541 This section defines parameter values used by the Kerberos V5 GSS-
542 API mechanism. It defines interface elements in support of
543 portability, and assumes use of C language bindings per [RFC-2744].
545 9.1. Minor Status Codes
547 This section recommends common symbolic names for minor_status
548 values to be returned by the Kerberos V5 GSS-API mechanism. Use of
549 these definitions will enable independent implementers to enhance
550 application portability across different implementations of the
551 mechanism defined in this specification. (In all cases,
552 implementations of GSS_Display_status() will enable callers to
553 convert minor_status indicators to text representations.) Each
554 implementation should make available, through include files or other
555 means, a facility to translate these symbolic names into the
556 concrete values which a particular GSS-API implementation uses to
557 represent the minor_status values specified in this section.
559 It is recognized that this list may grow over time, and that the
560 need for additional minor_status codes specific to particular
561 implementations may arise. It is recommended, however, that
562 implementations should return a minor_status value as defined on a
563 mechanism-wide basis within this section when that code is
564 accurately representative of reportable status rather than using a
565 separate, implementation-defined code.
567 9.1.1. Non-Kerberos-specific codes
569 GSS_KRB5_S_G_BAD_SERVICE_NAME
570 /* "No @ in SERVICE-NAME name string" */
571 GSS_KRB5_S_G_BAD_STRING_UID
572 /* "STRING-UID-NAME contains nondigits" */
573 GSS_KRB5_S_G_NOUSER
574 /* "UID does not resolve to username" */
575 GSS_KRB5_S_G_VALIDATE_FAILED
576 /* "Validation error" */
577 GSS_KRB5_S_G_BUFFER_ALLOC
578 /* "Couldn't allocate gss_buffer_t data" */
579 GSS_KRB5_S_G_BAD_MSG_CTX
580 /* "Message context invalid" */
581 GSS_KRB5_S_G_WRONG_SIZE
582 /* "Buffer is the wrong size" */
583 GSS_KRB5_S_G_BAD_USAGE
585 Zhu Standards Track - February 16, 2004 10 \f
586 Kerberos Version 5 GSS-API August 2003
589 /* "Credential usage type is unknown" */
590 GSS_KRB5_S_G_UNKNOWN_QOP
591 /* "Unknown quality of protection specified" */
593 9.1.2. Kerberos-specific-codes
595 GSS_KRB5_S_KG_CCACHE_NOMATCH
596 /* "Principal in credential cache does not match desired
597 name" */
598 GSS_KRB5_S_KG_KEYTAB_NOMATCH
599 /* "No principal in keytab matches desired name" */
600 GSS_KRB5_S_KG_TGT_MISSING
601 /* "Credential cache has no TGT" */
602 GSS_KRB5_S_KG_NO_SUBKEY
603 /* "Authenticator has no subkey" */
604 GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
605 /* "Context is already fully established" */
606 GSS_KRB5_S_KG_BAD_SIGN_TYPE
607 /* "Unknown signature type in token" */
608 GSS_KRB5_S_KG_BAD_LENGTH
609 /* "Invalid field length in token" */
610 GSS_KRB5_S_KG_CTX_INCOMPLETE
611 /* "Attempt to use incomplete security context" */
613 9.2. Buffer Sizes
615 All implementations of this specification shall be capable of
616 accepting buffers of at least 16K bytes as input to GSS_GetMIC(),
617 GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
618 the output_token generated by GSS_Wrap() for a 16K byte input buffer
619 as input to GSS_Unwrap(). Support for larger buffer sizes is
620 optional but recommended.
622 10. Backwards Compatibility Considerations
624 The new token formats defined in this document will only be
625 recognized by new implementations. To address this, implementations
626 can always use the explicit sign or seal algorithm in [GSSAPI-KRB5]
627 when the key type corresponds to "older" algorithms. An alternative
628 approach might be to retry sending the message with the sign or seal
629 algorithm explicitly defined as in [GSSAPI-KRB5]. However this
630 would require the use of a mechanism such as [RFC-2478] to securely
631 negotiate the algorithm or the use out of band mechanism to choose
632 appropriate algorithms. For this reason, it is RECOMMENDED that the
633 new token formats defined in this document can be used only if both
634 peers are known during context negotiation to support the new
635 mechanism (either because of the use of "new" enctypes or because of
636 the use of Kerberos V extensions).
638 11. Security Considerations
640 It is possible that the KDC returns a session-key type that is not
641 supported by the GSSAPI implementation (either on the client and the
642 server). In this case the implementation MUST not try to use the key
644 Zhu Standards Track - February 16, 2004 11 \f
645 Kerberos Version 5 GSS-API August 2003
648 with a supported cryptosystem. This will ensure that no security
649 weaknesses arise due to the use of an inappropriate key with an
650 encryption algorithm.
652 In addition the security problem described in [3DES] arising from
653 the use of a service implementation with a GSSAPI mechanism
654 supporting only DES and a Kerberos mechanism supporting both DES and
655 Triple DES is actually a more generic one. It arises whenever the
656 GSSAPI implementation does not support a stronger cryptosystem
657 supported by the Kerberos mechanism. KDC administrators desiring to
658 limit the session key types to support interoperability with such
659 GSSAPI implementations should carefully weigh the reduction in
660 protection offered by such mechanisms against the benefits of
661 interoperability.
664 12. Acknowledgments
666 The authors wish to acknowledge the contributions from the following
667 individuals:
669 Ken Raeburn and Nicolas Willams corrected many of our errors in the
670 use of generic profiles and were instrumental in the creation of this
671 draft.
673 Sam Hartman and Ken Raeburn suggested the "floating trailer" idea.
675 Sam Hartman and Nicolas Williams recommended the replacing our
676 earlier key derivation function for directional keys with different
677 key usage numbers for each direction as well as retaining the
678 directional bit for maximum compatibility.
680 Paul Leach provided numerous suggestions and comments.
682 Scott Field, Richard Ward, Dan Simon also provided valuable inputs on
683 this draft.
685 13. References
687 13.1. Normative References
689 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
690 3", BCP 9, RFC 2026, October 1996.
692 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
693 Requirement Levels", BCP 14, RFC 2119, March 1997.
695 [AES] National Institute of Standards and Technology, U.S.
696 Department of Commerce, "Advanced Encryption Standard", Federal
697 Information Processing Standards Publication 197, Washington, DC,
698 November 2001.
702 Zhu Standards Track - February 16, 2004 12 \f
703 Kerberos Version 5 GSS-API August 2003
706 [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
707 raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress.
709 [3DES] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI
710 Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT
711 distribution, June 2000.
713 [RFC-2743] Linn, J., "Generic Security Service Application Program
714 Interface Version 2, Update 1", RFC 2743, January 2000.
716 [RFC-2744] Wray, J., "Generic Security Service API Version 2 : C-
717 bindings", RFC 2744, January 2000.
719 [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
720 RFC 1964, June 1996.
722 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
723 Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in
724 progress.
726 [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,
727 Raeburn, K., "The Kerveros Network Authentication Service (V5)",
728 draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002.
729 Work in progress.
731 [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API
732 Negotiation Mechanism.", RFC 2478, December 1998.
734 13.2. Informative References
736 [SSPI] Leach, P., Security Service Provider Interface, MSDN, April
737 2003
739 14. Author's Address
741 Larry Zhu
742 One Microsoft Way
743 Redmond, WA 98052 - USA
744 EMail: LZhu@microsoft.com
746 Karthik Jaganathan
747 One Microsoft Way
748 Redmond, WA 98052 - USA
749 EMail: karthikj@microsoft.com
751 Sam Hartman
752 Massachusetts Institute of Technology
753 77 Massachusetts Avenue
754 Cambridge, MA 02139 - USA
755 Email: hartmans@MIT.EDU
758 Zhu Standards Track - February 16, 2004 13 \f
759 Kerberos Version 5 GSS-API August 2003
763 Full Copyright Statement
765 "Copyright (C) The Internet Society (date). All Rights Reserved.
767 This document and translations of it may be copied and
768 furnished to others, and derivative works that comment on or
769 otherwise explain it or assist in its implementation may be
770 prepared, copied, published and distributed, in whole or in
771 part, without restriction of any kind, provided that the above
772 copyright notice and this paragraph are included on all such
773 copies and derivative works. However, this document itself may
774 not be modified in any way, such as by removing the copyright
775 notice or references to the Internet Society or other Internet
776 organizations, except as needed for the purpose of developing
777 Internet standards in which case the procedures for copyrights
778 defined in the Internet Standards process must be followed, or
779 as required to translate it into languages other than English.
781 The limited permissions granted above are perpetual and will
782 not be revoked by the Internet Society or its successors or
783 assigns.
816 Zhu Standards Track - February 16, 2004 14 \f