| blob | 7d407186511f0063aa5e4293b4274b9e56714834 |
3 <Network 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-04.txt MIT
8 November 21, 2003
9 Expires: May 21, 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."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 Abstract
35 This memo defines protocols, procedures, and conventions to be
36 employed by peers implementing the Generic Security Service
37 Application Program Interface (GSS-API as specified in [RFC-2743])
38 when using the Kerberos Version 5 mechanism (as specified in
39 [KRBCLAR]).
41 [RFC-1964] is updated and incremental changes are proposed in
42 response to recent developments such as the introduction of Kerberos
43 crypto framework [KCRYPTO]. These changes support the inclusion of
44 new cryptosystems based on crypto profiles [KCRYPTO], by defining
45 new per-message tokens along with their encryption and checksum
46 algorithms.
48 Conventions used in this document
50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
52 document are to be interpreted as described in [RFC-2119].
54 1. Introduction
58 Zhu Internet Draft 1 \f
59 Kerberos Version 5 GSS-API November 2003
62 [KCRYPTO] defines a generic framework for describing encryption and
63 checksum types to be used with the Kerberos protocol and associated
64 protocols.
66 [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.
67 It defines the format of context establishment, per-message and
68 context deletion tokens and uses algorithm identifiers for each
69 cryptosystem in per message and context deletion tokens.
71 The approach taken in this document obviates the need for algorithm
72 identifiers. This is accomplished by using the same encryption
73 algorithm, specified by the crypto profile [KCRYPTO] for the session
74 key or subkey that is created during context negotiation, and its
75 required checksum algorithm. Message layouts of the per-message
76 tokens are therefore revised to remove algorithm indicators and also
77 to add extra information to support the generic crypto framework
78 [KCRYPTO].
80 Tokens transferred between GSS-API peers for security context
81 establishment are also described in this document. The data
82 elements exchanged between a GSS-API endpoint implementation and the
83 Kerberos KDC are not specific to GSS-API usage and are therefore
84 defined within [KRBCLAR] rather than within this specification.
86 The new token formats specified in this memo MUST be used with all
87 "newer" encryption types [KRBCLAR] and MAY be used with "older"
88 encryption types, provided that the initiator and acceptor know,
89 from the context establishment, that they can both process these new
90 token formats.
92 "Newer" encryption types are those which have been specified along
93 with or since the new Kerberos cryptosystem specification [KCRYPTO],
94 as defined in section 3.1.3 of [KRBCLAR]. The list of not-newer
95 encryption types is as follows [KCRYPTO]:
97 Encryption Type Assigned Number
98 ----------------------------------------------
99 des-cbc-crc 1
100 des-cbc-md4 2
101 des-cbc-md5 3
102 des3-cbc-md5 5
103 des3-cbc-sha1 7
104 dsaWithSHA1-CmsOID 9
105 md5WithRSAEncryption-CmsOID 10
106 sha1WithRSAEncryption-CmsOID 11
107 rc2CBC-EnvOID 12
108 rsaEncryption-EnvOID 13
109 rsaES-OAEP-ENV-OID 14
110 des-ede3-cbc-Env-OID 15
111 des3-cbc-sha1-kd 16
112 rc4-hmac 23
114 Note that in this document, the term "little endian order" is used
115 for brevity to refer to the least-significant-octet-first encoding,
118 Zhu Internet Draft 2 \f
119 Kerberos Version 5 GSS-API November 2003
122 while the term "big endian order" is for the most-significant-octet-
123 first encoding.
125 2. Key Derivation for Per-Message Tokens
127 To limit the exposure of a given key, [KCRYPTO] adopted "one-way"
128 "entropy-preserving" derived keys, for different purposes or key
129 usages, from a base key or protocol key.
131 This document defines four key usage values below that are used to
132 derive a specific key for signing and sealing messages, from the
133 session key or subkey [KRBCLAR] created during the context
134 establishment.
136 Name Value
137 -------------------------------------
138 KG-USAGE-ACCEPTOR-SEAL 22
139 KG-USAGE-ACCEPTOR-SIGN 23
140 KG-USAGE-INITIATOR-SEAL 24
141 KG-USAGE-INITIATOR-SIGN 25
143 When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
144 used as the usage number in the key derivation function for deriving
145 keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used
146 for Wrap tokens; similarly when the sender is the context initiator,
147 KG-USAGE-INITIATOR-SIGN is used as the usage number in the key
148 derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used
149 for Wrap Tokens. Even if the Wrap token does not provide for
150 confidentiality the same usage values specified above are used.
152 During the context initiation and acceptance sequence, the acceptor
153 MAY assert a subkey, and if so, subsequent messages MUST use this
154 subkey as the protocol key and these messages MUST be flagged as
155 "AcceptorSubkey" as described in section 4.2.2.
157 3. Quality of Protection
159 The GSS-API specification [RFC-2743] provides for Quality of
160 Protection (QOP) values that can be used by applications to request
161 a certain type of encryption or signing. A zero QOP value is used
162 to indicate the "default" protection; applications which do not use
163 the default QOP are not guaranteed to be portable across
164 implementations or even inter-operate with different deployment
165 configurations of the same implementation. Using an algorithm that
166 is different from the one for which the key is defined may not be
167 appropriate. Therefore, when the new method in this document is
168 used, the QOP value is ignored.
170 The encryption and checksum algorithms in per-message tokens are now
171 implicitly defined by the algorithms associated with the session key
172 or subkey. Algorithms identifiers as described in [RFC-1964] are
173 therefore no longer needed and removed from the new token headers.
175 4. Definitions and Token Formats
178 Zhu Internet Draft 3 \f
179 Kerberos Version 5 GSS-API November 2003
183 This section provides terms and definitions, as well as descriptions
184 for tokens specific to the Kerberos Version 5 GSS-API mechanism.
186 4.1. Context Establishment Tokens
188 All context establishment tokens emitted by the Kerberos V5 GSS-API
189 mechanism will have the framing shown below:
191 GSS-API DEFINITIONS ::=
193 BEGIN
195 MechType ::= OBJECT IDENTIFIER
196 -- representing Kerberos V5 mechanism
198 GSSAPI-Token ::=
199 -- option indication (delegation, etc.) indicated within
200 -- mechanism-specific token
201 [APPLICATION 0] IMPLICIT SEQUENCE {
202 thisMech MechType,
203 innerToken ANY DEFINED BY thisMech
204 -- contents mechanism-specific
205 -- ASN.1 structure not required
206 }
208 END
210 Where the notation and encoding of this pseudo ASN.1 header, which
211 is referred as the generic GSS-API token framing later in this
212 document, are described in [RFC-2743], and the innerToken field
213 starts with a two-octet token-identifier (TOK_ID) expressed in big
214 endian order, followed by a Kerberos message.
216 Here are the TOK_ID values used in the context establishment tokens:
218 Token TOK_ID Value in Hex
219 -----------------------------------------
220 KRB_AP_REQUEST 01 00
221 KRB_AP_REPLY 02 00
222 KRB_ERROR 03 00
224 Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR
225 are defined in [KRBCLAR].
227 If an unknown token identifier (TOK_ID) is received in the initial
228 context estalishment token, the receiver MUST return
229 GSS_S_CONTINUE_NEEDED major status, and the returned output token
230 MUST contain a KRB_ERROR message with the error code
231 KRB_AP_ERR_MSG_TYPE [KRBCLAR].
233 4.1.1. Authenticator Checksum
236 Zhu Internet Draft 4 \f
237 Kerberos Version 5 GSS-API November 2003
240 The authenticator in the KRB_AP_REQ message MUST include the
241 optional sequence number and the checksum field. The checksum field
242 is used to convey service flags, channel bindings, and optional
243 delegation information. The checksum type MUST be 0x8003. The
244 length of the checksum MUST be 24 octets when delegation is not
245 used. When delegation is used, a ticket-granting ticket will be
246 transferred in a KRB_CRED message. This ticket SHOULD have its
247 forwardable flag set. The KRB_CRED message MUST be encrypted in the
248 session key of the ticket used to authenticate the context.
250 The format of the authenticator checksum field is as follows.
252 Octet Name Description
253 -----------------------------------------------------------------
254 0..3 Lgth Number of octets in Bnd field; Currently
255 contains hex value 10 00 00 00 (16, represented
256 in little-endian order)
257 4..19 Bnd Channel binding information, as described in
258 section 4.1.1.2.
259 20..23 Flags Four-octet context-establishment flags in little-
260 endian order as described in section 4.1.1.1.
261 24..25 DlgOpt The Delegation Option identifier (=1) [optional]
262 26..27 Dlgth The length of the Deleg field [optional]
263 28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]
265 4.1.1.1. Checksum Flags Field
267 The checksum "Flags" field is used to convey service options or
268 extension negotiation information. The following context
269 establishment flags are defined in [RFC-2744].
271 Flag Name Value
272 ---------------------------------
273 GSS_C_DELEG_FLAG 1
274 GSS_C_MUTUAL_FLAG 2
275 GSS_C_REPLAY_FLAG 4
276 GSS_C_SEQUENCE_FLAG 8
277 GSS_C_CONF_FLAG 16
278 GSS_C_INTEG_FLAG 32
280 Context establishment flags are exposed to the calling application.
281 If the calling application desires a particular service option then
282 it requests that option via GSS_Init_sec_context() [RFC-2743]. An
283 implementation that supports a particular option or extension SHOULD
284 then set the appropriate flag in the checksum Flags field.
286 The most significant eight bits of the checksum flags are reserved
287 for future use. The receiver MUST ignore unknown checksum flags.
289 4.1.1.2. Channel Binding Information
291 Channel bindings are user-specified tags to identify a given context
292 to the peer application. These tags are intended to be used to
295 Zhu Internet Draft 5 \f
296 Kerberos Version 5 GSS-API November 2003
299 identify the particular communications channel that carries the
300 context [RFC-2743] [RFC-2744].
302 When using C language bindings, channel bindings are communicated to
303 the GSS-API using the following structure [RFC-2744]:
305 typedef struct gss_channel_bindings_struct {
306 OM_uint32 initiator_addrtype;
307 gss_buffer_desc initiator_address;
308 OM_uint32 acceptor_addrtype;
309 gss_buffer_desc acceptor_address;
310 gss_buffer_desc application_data;
311 } *gss_channel_bindings_t;
313 The member fields and constants used for different address types are
314 defined in [RFC-2744].
316 The "Bnd" field contains the MD5 hash of channel bindings, taken
317 over all non-null components of bindings, in order of declaration.
318 Integer fields within channel bindings are represented in little-
319 endian order for the purposes of the MD5 calculation.
321 In computing the contents of the Bnd field, the following detailed
322 points apply:
324 (1) Each integer field shall be formatted into four octets, using
325 little endian octet ordering, for purposes of MD5 hash computation.
327 (2) All input length fields within gss_buffer_desc elements of a
328 gss_channel_bindings_struct even those which are zero-valued, shall
329 be included in the hash calculation; the value elements of
330 gss_buffer_desc elements shall be dereferenced, and the resulting
331 data shall be included within the hash computation, only for the
332 case of gss_buffer_desc elements having non-zero length specifiers.
334 (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
335 valid channel binding structure, the Bnd field shall be set to 16
336 zero-valued octets.
338 4.2. Per-Message Tokens
340 Two classes of tokens are defined in this section: "MIC" tokens,
341 emitted by calls to GSS_GetMIC() and consumed by calls to
342 GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and
343 consumed by calls to GSS_Unwrap().
345 The new per-message tokens introduced here do not include the
346 generic GSS-API token framing used by the context establishment
347 tokens. These new tokens are designed to be used with newer crypto
348 systems that can, for example, have variable-size checksums.
350 4.2.1. Sequence Number
353 Zhu Internet Draft 6 \f
354 Kerberos Version 5 GSS-API November 2003
357 To distinguish intentionally-repeated messages from maliciously-
358 replayed ones, per-message tokens contain a sequence number field,
359 which is a 64 bit integer expressed in big endian order. After
360 sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence
361 numbers are incremented by one.
363 4.2.2. Flags Field
365 The "Flags" field is a one-octet integer used to indicate a set of
366 attributes for the protected message. For example, one flag is
367 allocated as the direction-indicator, thus preventing an adversary
368 from sending back the same message in the reverse direction and
369 having it accepted.
371 The meanings of bits in this field (the least significant bit is bit
372 0) are as follows:
374 Bit Name Description
375 ---------------------------------------------------------------
376 0 SentByAcceptor When set, this flag indicates the sender
377 is the context acceptor. When not set,
378 it indicates the sender is the context
379 initiator.
380 1 Sealed When set in Wrap tokens, this flag
381 indicates confidentiality is provided
382 for. It SHALL NOT be set in MIC tokens.
383 2 AcceptorSubkey A subkey asserted by the context acceptor
384 is used to protect the message.
386 The rest of available bits are reserved for future use and MUST be
387 cleared. The receiver MUST ignore unknown flags.
389 4.2.3. EC Field
391 The "EC" (Extra Count) field is a two-octet integer field expressed
392 in big endian order.
394 In Wrap tokens with confidentiality, the EC field is used to encode
395 the number of octets in the filler, as described in section 4.2.4.
397 In Wrap tokens without confidentiality, the EC field is used to
398 encode the number of octets in the trailing checksum, as described
399 in section 4.2.4.
401 4.2.4. Encryption and Checksum Operations
403 The encryption algorithms defined by the crypto profiles provide for
404 integrity protection [KCRYPTO]. Therefore no separate checksum is
405 needed.
407 The result of decryption can be longer than the original plaintext
408 [KCRYPTO] and the extra trailing octets are called "crypto-system
409 garbage". However, given the size of any plaintext data, one can
410 always find the next (possibly larger) size so that, when padding
413 Zhu Internet Draft 7 \f
414 Kerberos Version 5 GSS-API November 2003
417 the to-be-encrypted text to that size, there will be no crypto-
418 system garbage added [KCRYPTO].
420 In Wrap tokens that provide for confidentiality, the first 16 octets
421 of the Wrap token (the "header", as defined in section 4.2.6), are
422 appended to the plaintext data before encryption. Filler octets can
423 be inserted between the plaintext data and the "header", and the
424 values and size of the filler octets are chosen by implementations,
425 such that there is no crypto-system garbage present after the
426 decryption. The resulting Wrap token is {"header" |
427 encrypt(plaintext-data | filler | "header")}, where encrypt() is the
428 encryption operation (which provides for integrity protection)
429 defined in the crypto profile [KCRYPTO], and the RRC field in the
430 to-be-encrypted header contains the hex value 00 00.
432 In Wrap tokens that do not provide for confidentiality, the checksum
433 is calculated first over the to-be-signed plaintext data, and then
434 the first 16 octets of the Wrap token (the "header", as defined in
435 section 4.2.6). Both the EC field and the RRC field in the token
436 header are filled with zeroes for the purpose of calculating the
437 checksum. The resulting Wrap token is {"header" | plaintext-data |
438 get_mic(plaintext-data | "header")}, where get_mic() is the
439 checksum operation for the required checksum mechanism of the chosen
440 encryption mechanism defined in the crypto profile [KCRYPTO].
442 The parameters for the key and the cipher-state in the encrypt() and
443 get_mic() operations have been omitted for brevity.
445 For MIC tokens, the checksum is first calculated over the to-be-
446 signed plaintext data, and then the first 16 octets of the MIC
447 token, where the checksum mechanism is the required checksum
448 mechanism of the chosen encryption mechanism defined in the crypto
449 profile [KCRYPTO].
451 The resulting Wrap and MIC tokens bind the data to the token header,
452 including the sequence number and the direction indicator.
454 4.2.5. RRC Field
456 The "RRC" (Right Rotation Count) field in Wrap tokens is added to
457 allow the data to be encrypted in-place by existing [SSPI]
458 applications that do not provide an additional buffer for the
459 trailer (the cipher text after the in-place-encrypted data) in
460 addition to the buffer for the header (the cipher text before the
461 in-place-encrypted data). The resulting Wrap token in the previous
462 section, excluding the first 16 octets of the token header, is
463 rotated to the right by "RRC" octets. The net result is that "RRC"
464 octets of trailing octets are moved toward the header. Consider the
465 following as an example of this rotation operation: Assume that the
466 RRC value is 3 and the token before the rotation is {"header" | aa |
467 bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be
468 {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb
469 | cc |...| hh} is used to indicate the octet sequence.
472 Zhu Internet Draft 8 \f
473 Kerberos Version 5 GSS-API November 2003
476 The RRC field is expressed as a two-octet integer in big endian
477 order.
479 The rotation count value is chosen by the sender based on
480 implementation details, and the receiver MUST be able to interpret
481 all possible rotation count values.
483 4.2.6. Message Layouts
485 Per-message tokens start with a two-octet token identifier (TOK_ID)
486 field, expressed in big endian order. These tokens are defined
487 separately in subsequent sub-sections.
489 4.2.6.1. MIC Tokens
491 Use of the GSS_GetMIC() call yields a token, separate from the user
492 data being protected, which can be used to verify the integrity of
493 that data as received. The token has the following format:
495 Octet no Name Description
496 -----------------------------------------------------------------
497 0..1 TOK_ID Identification field. Tokens emitted by
498 GSS_GetMIC() contain the hex value 04 04
499 expressed in big endian order in this field.
500 2 Flags Attributes field, as described in section
501 4.2.2.
502 3..7 Filler Contains five octets of hex value FF.
503 8..15 SND_SEQ Sequence number field in clear text,
504 expressed in big endian order.
505 16..last SGN_CKSUM Checksum of octet 0..15 and the "to-be-
506 signed" data, as described in section 4.2.4.
508 The Filler field is included in the checksum calculation for
509 simplicity.
511 4.2.6.2. Wrap Tokens
513 Use of the GSS_Wrap() call yields a token, which consists of a
514 descriptive header, followed by a body portion that contains either
515 the input user data in plaintext concatenated with the checksum, or
516 the input user data encrypted. The GSS_Wrap() token has the
517 following format:
519 Octet no Name Description
520 ---------------------------------------------------------------
521 0..1 TOK_ID Identification field. Tokens emitted by
522 GSS_Wrap() contain the the hex value 05 04
523 expressed in big endian order in this field.
524 2 Flags Attributes field, as described in section
525 4.2.2.
526 3 Filler Contains the hex value FF.
527 4..5 EC Contains the "extra count" field, in big
528 endian order as described in section 4.2.3.
529 6..7 RRC Contains the "right rotation count" in big
532 Zhu Internet Draft 9 \f
533 Kerberos Version 5 GSS-API November 2003
536 endian order, as described in section 4.2.5.
537 8..15 SND_SEQ Sequence number field in clear text,
538 expressed in big endian order.
539 16..last Data Encrypted data for Wrap tokens with
540 confidentiality, or plaintext data followed
541 by the checksum for Wrap tokens without
542 confidentiality, as described in section
543 4.2.4.
545 4.3. Context Deletion Tokens
547 Context deletion tokens are empty in this mechanism. Both peers to
548 a security context invoke GSS_Delete_sec_context() [RFC-2743]
549 independently, passing a null output_context_token buffer to
550 indicate that no context_token is required. Implementations of
551 GSS_Delete_sec_context() should delete relevant locally-stored
552 context information.
554 4.4. Token Identifier Assignment Considerations
556 Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF
557 inclusive are reserved and SHALL NOT be assigned. Thus by examining
558 the first two octets of a token, one can tell unambiguously if it is
559 wrapped with the generic GSS-API token framing.
561 5. Parameter Definitions
563 This section defines parameter values used by the Kerberos V5 GSS-
564 API mechanism. It defines interface elements in support of
565 portability, and assumes use of C language bindings per [RFC-2744].
567 5.1. Minor Status Codes
569 This section recommends common symbolic names for minor_status
570 values to be returned by the Kerberos V5 GSS-API mechanism. Use of
571 these definitions will enable independent implementers to enhance
572 application portability across different implementations of the
573 mechanism defined in this specification. (In all cases,
574 implementations of GSS_Display_status() will enable callers to
575 convert minor_status indicators to text representations.) Each
576 implementation should make available, through include files or other
577 means, a facility to translate these symbolic names into the
578 concrete values which a particular GSS-API implementation uses to
579 represent the minor_status values specified in this section.
581 It is recognized that this list may grow over time, and that the
582 need for additional minor_status codes specific to particular
583 implementations may arise. It is recommended, however, that
584 implementations should return a minor_status value as defined on a
585 mechanism-wide basis within this section when that code is
586 accurately representative of reportable status rather than using a
587 separate, implementation-defined code.
589 5.1.1. Non-Kerberos-specific codes
592 Zhu Internet Draft 10 \f
593 Kerberos Version 5 GSS-API November 2003
597 GSS_KRB5_S_G_BAD_SERVICE_NAME
598 /* "No @ in SERVICE-NAME name string" */
599 GSS_KRB5_S_G_BAD_STRING_UID
600 /* "STRING-UID-NAME contains nondigits" */
601 GSS_KRB5_S_G_NOUSER
602 /* "UID does not resolve to username" */
603 GSS_KRB5_S_G_VALIDATE_FAILED
604 /* "Validation error" */
605 GSS_KRB5_S_G_BUFFER_ALLOC
606 /* "Couldn't allocate gss_buffer_t data" */
607 GSS_KRB5_S_G_BAD_MSG_CTX
608 /* "Message context invalid" */
609 GSS_KRB5_S_G_WRONG_SIZE
610 /* "Buffer is the wrong size" */
611 GSS_KRB5_S_G_BAD_USAGE
612 /* "Credential usage type is unknown" */
613 GSS_KRB5_S_G_UNKNOWN_QOP
614 /* "Unknown quality of protection specified" */
616 5.1.2. Kerberos-specific-codes
618 GSS_KRB5_S_KG_CCACHE_NOMATCH
619 /* "Client principal in credentials does not match
620 specified name" */
621 GSS_KRB5_S_KG_KEYTAB_NOMATCH
622 /* "No key available for specified service principal" */
623 GSS_KRB5_S_KG_TGT_MISSING
624 /* "No Kerberos ticket-granting ticket available" */
625 GSS_KRB5_S_KG_NO_SUBKEY
626 /* "Authenticator has no subkey" */
627 GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
628 /* "Context is already fully established" */
629 GSS_KRB5_S_KG_BAD_SIGN_TYPE
630 /* "Unknown signature type in token" */
631 GSS_KRB5_S_KG_BAD_LENGTH
632 /* "Invalid field length in token" */
633 GSS_KRB5_S_KG_CTX_INCOMPLETE
634 /* "Attempt to use incomplete security context" */
636 5.2. Buffer Sizes
638 All implementations of this specification shall be capable of
639 accepting buffers of at least 16K octets as input to GSS_GetMIC(),
640 GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
641 the output_token generated by GSS_Wrap() for a 16K octet input
642 buffer as input to GSS_Unwrap(). Support for larger buffer sizes is
643 optional but recommended.
645 6. Backwards Compatibility Considerations
647 The new token formats defined in this document will only be
648 recognized by new implementations. To address this, implementations
649 can always use the explicit sign or seal algorithm in [RFC-1964]
652 Zhu Internet Draft 11 \f
653 Kerberos Version 5 GSS-API November 2003
656 when the key type corresponds to "older" enctypes. An alternative
657 approach might be to retry sending the message with the sign or seal
658 algorithm explicitly defined as in [RFC-1964]. However this would
659 require either the use of a mechanism such as [RFC-2478] to securely
660 negotiate the method or the use out of band mechanism to choose
661 appropriate mechanism. For this reason, it is RECOMMENDED that the
662 new token formats defined in this document SHOULD be used only if
663 both peers are known to support the new mechanism during context
664 negotiation because of, for example, the use of "new" enctypes.
666 GSS_Unwrap() or GSS_Verify_MIC() can process a message token as
667 follows: it can look at the first octet of the token header, if it
668 is 0x60 then the token must carry the generic GSS-API pseudo ASN.1
669 framing, otherwise the first two octets of the token contain the
670 TOK_ID that uniquely identify the token message format.
672 7. Security Considerations
674 Under the current mechanism, no negotiation of algorithm types
675 occurs, so server-side (acceptor) implementations cannot request
676 that clients not use algorithm types not understood by the server.
677 However, administration of the server's Kerberos data (e.g., the
678 service key) has to be done in communication with the KDC, and it is
679 from the KDC that the client will request credentials. The KDC
680 could therefore be given the task of limiting session keys for a
681 given service to types actually supported by the Kerberos and GSSAPI
682 software on the server.
684 This does have a drawback for cases where a service principal name
685 is used both for GSSAPI-based and non-GSSAPI-based communication
686 (most notably the "host" service key), if the GSSAPI implementation
687 does not understand (for example) AES [AES-KRB5] but the Kerberos
688 implementation does. It means that AES session keys cannot be
689 issued for that service principal, which keeps the protection of
690 non-GSSAPI services weaker than necessary. KDC administrators
691 desiring to limit the session key types to support interoperability
692 with such GSSAPI implementations should carefully weigh the
693 reduction in protection offered by such mechanisms against the
694 benefits of interoperability.
696 8. Acknowledgments
698 Ken Raeburn and Nicolas Williams corrected many of our errors in the
699 use of generic profiles and were instrumental in the creation of this
700 memo.
702 The text for security considerations was contributed by Ken Raeburn.
704 Sam Hartman and Ken Raeburn suggested the "floating trailer" idea,
705 namely the encoding of the RRC field.
707 Sam Hartman and Nicolas Williams recommended the replacing our
708 earlier key derivation function for directional keys with different
711 Zhu Internet Draft 12 \f
712 Kerberos Version 5 GSS-API November 2003
715 key usage numbers for each direction as well as retaining the
716 directional bit for maximum compatibility.
718 Paul Leach provided numerous suggestions and comments.
720 Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided
721 valuable inputs on this memo.
723 Jeffrey Hutzelman provided comments on channel bindings and suggested
724 many editorial changes.
726 Luke Howard provided implementations of this memo for the Heimdal
727 code base, and helped inter-operability testing with the Microsoft
728 code base, together with Love Hornquist Astrand. These experiments
729 formed the basis of this memo.
731 Martin Rex provided suggestions of TOK_ID assignment recommendations
732 thus the token tagging in this memo is unambiguous if the token is
733 wrapped with the pseudo ASN.1 header.
735 This document retains some of the text of RFC-1964 in relevant
736 sections.
738 9. References
740 9.1. Normative References
742 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
743 3", BCP 9, RFC 2026, October 1996.
745 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
746 Requirement Levels", BCP 14, RFC 2119, March 1997.
748 [RFC-2743] Linn, J., "Generic Security Service Application Program
749 Interface Version 2, Update 1", RFC 2743, January 2000.
751 [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
752 bindings", RFC 2744, January 2000.
754 [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
755 RFC 1964, June 1996.
757 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
758 Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in
759 progress.
761 [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,
762 Raeburn, K., "The Kerberos Network Authentication Service (V5)",
763 draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002.
764 Work in progress.
766 [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
767 raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress.
770 Zhu Internet Draft 13 \f
771 Kerberos Version 5 GSS-API November 2003
775 [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API
776 Negotiation Mechanism", RFC 2478, December 1998.
778 9.2. Informative References
780 [SSPI] Leach, P., "Security Service Provider Interface", Microsoft
781 Developer Network (MSDN), April 2003.
783 10. Author's Address
785 Larry Zhu
786 One Microsoft Way
787 Redmond, WA 98052 - USA
788 EMail: LZhu@microsoft.com
790 Karthik Jaganathan
791 One Microsoft Way
792 Redmond, WA 98052 - USA
793 EMail: karthikj@microsoft.com
795 Sam Hartman
796 Massachusetts Institute of Technology
797 77 Massachusetts Avenue
798 Cambridge, MA 02139 - USA
799 Email: hartmans@MIT.EDU
826 Zhu Internet Draft 14 \f
827 Kerberos Version 5 GSS-API November 2003
831 Full Copyright Statement
833 Copyright (C) The Internet Society (date). All Rights Reserved.
835 This document and translations of it may be copied and furnished to
836 others, and derivative works that comment on or otherwise explain it
837 or assist in its implementation may be prepared, copied, published
838 and distributed, in whole or in part, without restriction of any
839 kind, provided that the above copyright notice and this paragraph
840 are included on all such copies and derivative works. However, this
841 document itself may not be modified in any way, such as by removing
842 the copyright notice or references to the Internet Society or other
843 Internet organizations, except as needed for the purpose of
844 developing Internet standards in which case the procedures for
845 copyrights defined in the Internet Standards process must be
846 followed, or as required to translate it into languages other than
847 English.
849 The limited permissions granted above are perpetual and will not be
850 revoked by the Internet Society or its successors or assigns.
852 This document and the information contained herein is provided on an
853 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
854 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
855 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
856 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
857 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
884 Zhu Internet Draft 15 \f