3 NETWORK WORKING GROUP L. Zhu
4 Internet-Draft P. Leach
5 Obsoletes: 2478 (if approved) K. Jaganathan
6 Expires: June 1, 2005 Microsoft Corporation
12 The Simple and Protected GSS-API Negotiation Mechanism
13 draft-ietf-kitten-2478bis
17 This document is an Internet-Draft and is subject to all provisions
18 of section 3 of RFC 3667. By submitting this Internet-Draft, each
19 author represents that any applicable patent or other IPR claims of
20 which he or she is aware have been or will be disclosed, and any of
21 which he or she become aware will be disclosed, in accordance with
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on June 1, 2005.
44 Copyright (C) The Internet Society (2004).
48 This document specifies a negotiation mechanism for the Generic
49 Security Service Application Program Interface (GSS-API) which is
50 described in RFC 2743.
55 Zhu, et al. Expires June 1, 2005 [Page 1]
57 Internet-Draft GSS-API Negotiation Mechanism December 2004
60 GSS-API peers can use this negotiation mechanism to choose from a
61 common set of security mechanisms.
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
67 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6
68 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6
69 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7
70 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 9
71 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 9
72 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 9
73 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
74 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
75 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13
76 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16
77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
80 10. Normative References . . . . . . . . . . . . . . . . . . . . 19
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
82 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21
83 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21
84 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21
85 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23
86 Intellectual Property and Copyright Statements . . . . . . . . 25
111 Zhu, et al. Expires June 1, 2005 [Page 2]
113 Internet-Draft GSS-API Negotiation Mechanism December 2004
118 The GSS-API [RFC2743] provides a generic interface which can be
119 layered atop different security mechanisms such that if communicating
120 peers acquire GSS-API credentials for the same security mechanism,
121 then a security context may be established between them (subject to
122 policy). However, GSS-API does not prescribe the method by which
123 GSS-API peers can establish whether they have a common security
126 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
127 defined here is a pseudo security mechanism, represented by the
128 Object Identifier iso.org.dod.internet.security.mechanism.snego
129 (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
130 whether their credentials share common GSS-API security mechanism(s),
131 and if so, to invoke normal security context establishment for a
132 selected common security mechanism. This is most useful for
133 applications which are based on GSS-API implementations and share
134 multiple mechanisms between the peers.
136 The SPNEGO mechanism negotiation is based on the following
137 negotiation model: the initiator proposes a list of security
138 mechanism(s), in decreasing preference order (favorite choice first),
139 the acceptor (also known as the target) either accepts the
140 initiator's preferred security mechanism (the first in the list), or
141 chooses one that is available from the offered list, or rejects the
142 proposed value(s). The target then informs the initiator of its
145 Once a common security mechanism is chosen, mechanism-specific
146 options MAY be negotiated as part of the selected mechanism's context
147 establishment. These negotiations (if any) are internal to the
148 mechanism and opaque to the SPNEGO protocol. As such they are
149 outside the scope of this document.
151 If per-message integrity services are available on the established
152 mechanism security context, then the peers can exchange MIC tokens to
153 ensure that the mechanism list was not tampered with. This MIC token
154 exchange is OPTIONAL if the selected mechanism is the most preferred
155 choice of both peers (see Section 5).
157 In order to avoid an extra round trip, the first security token of
158 the initiator's preferred mechanism SHOULD be embedded in the initial
159 negotiation message (as defined in Section 4.2). This mechanism
160 token is referred to as the optimistic mechanism token in this
161 document. If the selected mechanism matches the initiator's
162 preferred mechanism, no additional round trips need be incurred by
163 using this protocol. In addition, using the optimistic mechanism
167 Zhu, et al. Expires June 1, 2005 [Page 3]
169 Internet-Draft GSS-API Negotiation Mechanism December 2004
172 token allows the initiator to recover from non-fatal errors while
173 producing the first mechanism token before a mechanism can be
174 selected. Implementations MAY omit the optimistic mechanism token to
175 avoid the cost of generating it in cases where the initiator's
176 preferred mechanism is not selected by the acceptor.
178 SPNEGO relies the concepts developed in the GSS-API specification
179 [RFC2743]. The negotiation data is encapsulated in context-level
180 tokens. Therefore, callers of the GSS-API do not need to be aware of
181 the existence of the negotiation tokens but only of the new
182 pseudo-security mechanism. A failure in the negotiation phase causes
183 a major status code to be returned: GSS_S_BAD_MECH.
223 Zhu, et al. Expires June 1, 2005 [Page 4]
225 Internet-Draft GSS-API Negotiation Mechanism December 2004
228 2. Conventions Used in This Document
230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
232 document are to be interpreted as described in [RFC2119].
279 Zhu, et al. Expires June 1, 2005 [Page 5]
281 Internet-Draft GSS-API Negotiation Mechanism December 2004
284 3. Negotiation Protocol
286 When the established mechanism context provides integrity protection,
287 the mechanism negotiation can be protected. When acquiring
288 negotiated security mechanism tokens, per-message integrity services
289 are always requested by the SPNEGO mechanism.
291 When the established mechanism context supports per-message integrity
292 services, SPNEGO guarantees that the selected mechanism is mutually
295 This section describes the negotiation process of this protocol.
297 3.1 Negotiation Description
299 The first negotiation token sent by the initiator contains an ordered
300 list of mechanisms (in decreasing preference order, favorite
301 mechanism first), and optionally the initial mechanism token for the
302 preferred mechanism of the initiator (i.e., the first in the list).
303 The list of security mechanisms available for negotiation is based on
304 the credentials being used.
306 The target then processes the token from the initiator. This will
307 result in one of four possible states (as defined in Section 4.2.2):
308 accept_completed, accept_incomplete, reject, or request_mic. A
309 reject state will terminate the negotiation; an accept_completed
310 state indicates that not only was the initiator-selected mechanism
311 acceptable to the target, but also that the initial mechanism token
312 was sufficient to complete the authentication; an accept_incomplete
313 state indicates that further message exchange is needed but the MIC
314 token exchange as described in Section 5 is OPTIONAL; a request_mic
315 state (this state can only be present in the first reply message from
316 the target) indicates the MIC token exchange is REQUIRED if
317 per-message integrity services are available.
319 Unless the preference order is specified by the application (see
320 Appendix A), the policy by which the target chooses a mechanism is an
321 implementation-specific local matter. In the absence of an
322 application specified preference order or other policy, the target
323 SHALL choose the first mechanism in the initiator proposed list for
324 which it has valid credentials.
326 In case of a successful negotiation, the security mechanism in the
327 first reply message represents the value suitable for the target,
328 picked up from the list offered by the initiator. A context level
329 token for a reject state is OPTIONAL.
331 Once a mechanism has been selected, the tokens specific to the
335 Zhu, et al. Expires June 1, 2005 [Page 6]
337 Internet-Draft GSS-API Negotiation Mechanism December 2004
340 selected mechanism are carried within the negotiation tokens.
342 Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
343 mechanism list received by the target.
345 To avoid conflicts with the use of MIC tokens by SPNEGO,
346 partially-established contexts are not used for per-message calls:
347 the prot_ready_state [RFC2743] will be false even if the underlying
348 mechanism would return true natively.
350 3.2 Negotiation Procedure
352 The basic form of the procedure assumes that per-message integrity
353 services are available on the established mechanism context, and it
354 is summarized as follows:
356 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
357 but requests that SPNEGO be used. SPNEGO can either be explicity
358 requested or accepted as the default mechanism.
360 (b) The initiator GSS-API implementation emits a negotiation token
361 containing a list of one or more security mechanisms that are
362 available based on the credentials used for this context
363 establishment, and optionally the initial mechanism token for the
364 first mechanism in the list.
366 (c) The GSS-API initiator application sends the token to the target
367 application. The GSS-API target application deposits the token by
368 invoking GSS_Accept_sec_context(). The acceptor will do one of
371 (I) If none of the proposed mechanisms are acceptable, the
372 negotiation SHALL be terminated. GSS_Accept_sec_context
373 indicates GSS_S_BAD_MECH. The acceptor MAY output a
374 negotiation token containing a reject state.
376 (II) If either the initiator's preferred mechanism is not accepted
377 by the target or this mechanism is accepted but it is not the
378 acceptor's most preferred mechanism (see Section 3.1 and
379 Section 5), GSS_Accept_sec_context() indicates
380 GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation
381 token containing a request_mic state.
383 (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
384 or GSS_S_CONTINUE_NEEDED depending on if at least one
385 additional negotiation token from the initiator is needed to
386 establish this context. The acceptor outputs a negotiation
387 token containing an accept_complete or accept_incomplete state,
391 Zhu, et al. Expires June 1, 2005 [Page 7]
393 Internet-Draft GSS-API Negotiation Mechanism December 2004
398 If the initiator's preferred mechanism is accepted, and an
399 optimistic mechanism token was included, this mechanism token MUST
400 be deposited to the selected mechanism by invoking
401 GSS_Accept_sec_context() and if a response mechanism token is
402 emitted, it MUST be included in the response negotiation token.
403 Otherwise, the target will not emit a response mechanism token in
406 (d) The GSS-API target application returns the negotiation token to
407 the initiator application. The GSS-API initiator application
408 deposits the token by invoking GSS_Init_sec_context(). The
409 security context initialization is then continued according to the
410 standard GSS-API conventions for the selected mechanism, where the
411 tokens of the selected mechanism are encapsulated until the
412 GSS_S_COMPLETE is returned for both the initiator and the target
413 by the selected security mechanism.
415 (e) MIC tokens are then either skipped or exchanged according to
418 Note that the *_req_flag input parameters for context establishment
419 are relative to the selected mechanism, as are the *_state output
420 parameters. i.e., these parameters are not applicable to the
421 negotiation process per se.
423 On receipt of a negotiation token on the target side, a GSS-API
424 implementation that does not support negotiation would indicate the
425 GSS_S_BAD_MECH status as if a particular basic security mechanism had
426 been requested and was not supported.
428 When GSS_Acquire_cred is invoked with this negotiation mechanism in
429 the desired_mechs, an implementation-specific default credential is
430 used to carry on the negotiation. A set of mechanisms as specified
431 locally by the system administrator is then available for
432 negotiation. If there is a desire for the caller to make its own
433 choice, then an additional API has to be used (see Appendix A).
447 Zhu, et al. Expires June 1, 2005 [Page 8]
449 Internet-Draft GSS-API Negotiation Mechanism December 2004
454 The type definitions in this section assume an ASN.1 module
455 definition of the following form:
459 iso(1) identified-organization(3) dod(6) internet(1)
460 security(5) mechanism(5) snego (2) modules(4) spec2(2)
461 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
463 -- rest of definitions here
468 This specifies that the tagging context for the module will be
469 explicit and non-automatic.
471 The encoding of SPNEGO protocol messages shall obey the Distinguished
472 Encoding Rules (DER) of ASN.1 as described in [X690].
476 In this negotiation model, each OID represents one GSS-API mechanism
477 or one variant (see Section 6) of it according to [RFC2743].
480 MechType ::= OBJECT IDENTIFIER
481 -- OID represents each security mechanism as suggested by
484 MechTypeList ::= SEQUENCE OF MechType
487 4.2 Negotiation Tokens
489 The syntax of the initial negotiation tokens follows the
490 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The
491 SPNEGO pseudo mechanism is identified by the Object Identifier
492 specified in Section 1. Subsequent tokens are not encapsulated in
493 this GSS-API generic token framing.
495 This section specifies the syntax of the inner token for the initial
496 message and the syntax of subsequent context establishment tokens.
498 NegotiationToken ::= CHOICE {
499 negTokenInit [0] NegTokenInit,
503 Zhu, et al. Expires June 1, 2005 [Page 9]
505 Internet-Draft GSS-API Negotiation Mechanism December 2004
508 negTokenResp [1] negTokenResp
515 NegTokenInit ::= SEQUENCE {
516 mechTypes [0] MechTypeList,
517 reqFlags [1] ContextFlags OPTIONAL,
518 mechToken [2] OCTET STRING OPTIONAL,
519 mechListMIC [3] OCTET STRING OPTIONAL,
522 ContextFlags ::= BIT STRING {
532 This is the syntax for the inner token of the initial negotiation
537 This field contains one or more security mechanisms available
538 for the initiator in decreasing preference order (favorite
543 This field, if present, contains the service options that are
544 requested to establish the context. The context flags SHOULD
545 be filled in from the req_flags parameter of
546 GSS_Init_sec_context(). This field SHALL NOT have impact on
551 This field, if present, contains the optimistic mechanism
559 Zhu, et al. Expires June 1, 2005 [Page 10]
561 Internet-Draft GSS-API Negotiation Mechanism December 2004
566 This field, if present, contains a MIC token for the mechanism
567 list in the initial negotiation message. This MIC token is
568 computed according to Section 5.
573 NegTokenResp ::= SEQUENCE {
574 negResult [0] ENUMERATED {
575 accept_completed (0),
576 accept_incomplete (1),
580 -- REQUIRED in the first reply from the target
581 supportedMech [1] MechType OPTIONAL,
582 -- present only in the first reply from the target
583 responseToken [2] OCTET STRING OPTIONAL,
584 mechListMIC [3] OCTET STRING OPTIONAL,
588 This is the syntax for all subsequent negotiation messages.
592 This field, if present, contains the state of the negotiation.
597 No further negotiation message from the peer is expected,
598 and the security context is established for the sender.
602 At least one more negotiation message from the peer is
603 needed to establish the security context.
607 The sender terminates the negotiation.
615 Zhu, et al. Expires June 1, 2005 [Page 11]
617 Internet-Draft GSS-API Negotiation Mechanism December 2004
622 The sender indicates that the exchange of MIC tokens, as
623 described in Section 5, will be REQUIRED if per-message
624 integrity services are available on the mechanism context to
625 be established. This value SHALL only be present in the
626 first reply from the target.
628 This field is REQUIRED in the first reply from the target, and
629 it is OPTIONAL thereafter.
633 This field SHALL only be present in the first reply from the
634 target. It MUST be one of the mechanism(s) offered by the
639 This field, if present, contains tokens specific to the
644 This field, if present, contains a MIC token for the mechanism
645 list in the initial negotiation message. This MIC token is
646 computed according to Section 5.
671 Zhu, et al. Expires June 1, 2005 [Page 12]
673 Internet-Draft GSS-API Negotiation Mechanism December 2004
676 5. Processing of mechListMIC
678 If the mechanism selected by the negotiation does not support
679 integrity protection, then no mechlistMIC token is used.
681 Otherwise if the accepted mechanism is the most preferred mechanism
682 of both the initiator and the acceptor, then the MIC token exchange,
683 as described later in this section, is OPTIONAL. A mechanism is the
684 acceptor's most preferred mechanism if there is no other mechanism
685 which would have been preferred over the accepted mechanism if it had
686 been present in the received mechanism list.
688 In all other cases, MIC tokens MUST be exchanged after the mechanism
689 context is fully established.
691 It is assumed that per-message integrity services are available on
692 the established mechanism context in the following procedure for
693 processing MIC tokens of the initiator's mechanism list.
695 a) The mechlistMIC token (or simply the MIC token) is computed by
696 invoking GSS_GetMIC(): the input context_handle is the established
697 mechanism context, the input qop_req is 0, and the input message
698 is the mechTypes field in the initial negotiation message (only
699 the DER encoding of the type MechTypeList is included).
701 b) If the selected mechanism uses an even number of mechanism tokens
702 (namely the acceptor sends the last mechanism token), the acceptor
703 does the following when emitting the negotiation message
704 containing the last mechanism token: if the MIC token exchange is
705 not required, GSS_Accept_sec_context() either indicates
706 GSS_S_COMPLETE and does not include a mechlistMIC token, or
707 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
708 and an accept_incomplete state; if the MIC token exchange is
709 required, GSS_Accept_sec_context() indicates
710 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
711 Acceptors that wish to be compatible with legacy Windows SPNEGO
712 implementations as described in Appendix B shall not generate a
713 mechlistMIC token when the MIC token exchange is not required.
714 The initiator then processes the last mechanism token, and does
715 one of the following:
717 (I) If a mechlistMIC token was included, and is correctly
718 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The
719 output negotiation message contains a mechlistMIC token, and an
720 accept_complete state. The acceptor MUST then verify this
727 Zhu, et al. Expires June 1, 2005 [Page 13]
729 Internet-Draft GSS-API Negotiation Mechanism December 2004
732 (II) If a mechlistMIC token was included but is incorrect, the
733 negotiation SHALL be terminated. GSS_Accept_sec_context()
734 indicates GSS_S_DEFECTIVE_TOKEN.
736 (III) If no mechlistMIC token was included, and the MIC token
737 exchange is not required, GSS_Init_sec_context() indicates
738 GSS_S_COMPLETE with no output token.
740 (IV) If no mechlistMIC token was included, but the MIC token
741 exchange is required, the negotiation SHALL be terminated.
742 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
744 c) In the case that the chosen mechanism uses an odd number of
745 mechanism tokens (namely the initiator sends the last mechanism
746 token), the initiator does the following when emitting the
747 negotiation message containing the last mechanism token: if the
748 negResult state was request_mic in the first reply from the
749 target, a mechlistMIC token MUST be included, otherwise the
750 mechlistMIC token is OPTIONAL. In the case that the optimistic
751 mechanism token is the only mechanism token for the initiator's
752 preferred mechanism, the mechlistMIC token is OPTIONAL.
753 GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
754 Initiators that wish to be compatible with legacy Windows SPNEGO
755 implementations as described in Appendix B shall not generate a
756 mechlistMIC token when the MIC token exchange is not required.
757 The acceptor then processes the last mechanism token and does one
760 (I) If a mechlistMIC token was included and is correctly verified,
761 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output
762 negotiation message contains a mechlistMIC token and an
763 accept_complete state. The initiator MUST then verify this
766 (II) If a mechlistMIC token was included but is incorrect, the
767 negotiation SHALL be terminated. GSS_Accept_sec_context()
768 indicates GSS_S_DEFECTIVE_TOKEN.
770 (III) If no mechlistMIC token was included but the mechlistMIC
771 token exchange is not required, GSS_Accept_sec_context()
772 indicates GSS_S_COMPLETE. The output negotiation message
773 contains an accept_complete state.
775 (IV) In the case that the optimistic mechanism token is also the
776 last mechanism token (when the initiator's preferred mechanism
777 is accepted by the target) and the target sends a request_mic
778 state but the initiator did not send a mechlistMIC token, the
779 target then MUST include a mechlistMIC token in that first
783 Zhu, et al. Expires June 1, 2005 [Page 14]
785 Internet-Draft GSS-API Negotiation Mechanism December 2004
788 reply. GSS_Accept_sec_context() indicates
789 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received
790 mechlistMIC token and generate a mechlistMIC token to send back
791 to the target. The target SHALL in turn verify the returned
792 mechlistMIC token and complete the negotiation.
794 (V) If no mechlistMIC token was included and the acceptor sent a
795 request_mic state in the first reply message (the exchange of
796 MIC tokens is required), the negotiation SHALL be terminated.
797 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
839 Zhu, et al. Expires June 1, 2005 [Page 15]
841 Internet-Draft GSS-API Negotiation Mechanism December 2004
846 Two mechanisms are provided for extensibility. First, the ASN.1
847 structures in this specification MAY be expanded by IETF standards
848 action. Implementations receiving unknown fields MUST ignore these
851 Secondly, OIDs corresponding to a desired mechanism attribute may be
852 included in the set of preferred mechanisms by an initiator. The
853 acceptor can choose to honor this request by preferring mechanisms
854 that have the included attributes. Future work within the Kitten
855 working group is expected to standardize common attributes that
856 SPNEGO mechanisms may wish to support. At this time it is sufficient
857 to say that initiators MAY include OIDs that do not correspond to
858 mechanisms but instead correspond to desired mechanism attributes in
859 their requests. Such OIDs MAY influence the acceptor's choice of
860 mechanism. As discussed in Section 5, if there are mechanisms that
861 if present in the initiator's list of mechanisms might be preferred
862 by the acceptor to the initiator's preferred mechanism, the acceptor
863 MUST demand the MIC token exchange. As a consequence, acceptors MUST
864 demand the MIC token exchange if they support negotiation of
865 attributes not available in the initiator's preferred mechanism
866 regardless of whether the initiator actually requested these
895 Zhu, et al. Expires June 1, 2005 [Page 16]
897 Internet-Draft GSS-API Negotiation Mechanism December 2004
900 7. Security Considerations
902 In order to produce the MIC token for the mechanism list, the
903 mechanism must provide integrity protection. When the selected
904 mechanism does not support integrity protection, the negotiation is
905 vulnerable: an active attacker can force it to use a security
906 mechanism that is not mutually preferred but is acceptable to the
909 This protocol provides the following guarantees when per-message
910 integrity services are available on the established mechanism context
911 and the mechanism list was altered by an adversary such that a
912 mechanism which is not mutually preferred could be selected:
914 o if the last mechanism token is sent by the initiator, both peers
916 o if the last mechanism token is sent by the acceptor, the acceptor
917 shall not complete and the initiator at worst shall complete with
918 its preferred mechanism being selected.
920 The negotiation may not be terminated if an alteration was made but
921 it had no material impact.
923 The protection of the negotiation depends on the strength of the
924 integrity protection. In particular, the strength of SPNEGO is no
925 stronger than the integrity protection of the weakest mechanism
926 acceptable to GSS-API peers.
928 In all cases, the communicating peers are exposed to the denial of
951 Zhu, et al. Expires June 1, 2005 [Page 17]
953 Internet-Draft GSS-API Negotiation Mechanism December 2004
956 8. IANA Considerations
958 This document has no actions for IANA.
1007 Zhu, et al. Expires June 1, 2005 [Page 18]
1009 Internet-Draft GSS-API Negotiation Mechanism December 2004
1014 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
1015 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
1016 and suggestions during development of this document.
1018 Luke Howard provided a prototype of this protocol in Heimdal and
1019 resolved several issues in the initial draft.
1021 Eric Baize and Denis Pinkas wrote the original SPNEGO specification
1022 [RFC2478] of which some of the text has been retained in this
1025 10 Normative References
1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1028 Requirement Levels", BCP 14, RFC 2119, March 1997.
1030 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1031 Negotiation Mechanism", RFC 2478, December 1998.
1033 [RFC2743] Linn, J., "Generic Security Service Application Program
1034 Interface Version 2, Update 1", RFC 2743, January 2000.
1036 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1037 Rules (BER), Canonical Encoding Rules (CER) and
1038 Distinguished Encoding Rules (DER), ITU-T Recommendation
1039 X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
1044 Microsoft Corporation
1049 EMail: lzhu@microsoft.com
1053 Microsoft Corporation
1058 EMail: paulle@microsoft.com
1067 Zhu, et al. Expires June 1, 2005 [Page 19]
1069 Internet-Draft GSS-API Negotiation Mechanism December 2004
1073 Microsoft Corporation
1078 EMail: karthikj@microsoft.com
1083 1775 Wiehle Avenue, 2nd Floor
1087 EMail: wyllys.ingersoll@sun.com
1123 Zhu, et al. Expires June 1, 2005 [Page 20]
1125 Internet-Draft GSS-API Negotiation Mechanism December 2004
1128 Appendix A. GSS-API Negotiation Support API
1130 In order to provide to a GSS-API caller (either the initiator or the
1131 target or both) the ability to choose among the set of supported
1132 mechanisms a reduced set of mechanisms for negotiation, two
1133 additional APIs are defined:
1135 o GSS_Get_neg_mechs() indicates the set of security mechanisms
1136 available on the local system to the caller for negotiation, based
1137 on the credentials being used.
1138 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be
1139 used on the local system by the caller for negotiation, for the
1142 A.1 GSS_Set_neg_mechs call
1146 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default
1148 o mech_set SET OF OBJECT IDENTIFIER
1152 o major_status INTEGER,
1153 o minor_status INTEGER
1155 Return major_status codes:
1157 o GSS_S_COMPLETE indicates that the set of security mechanisms
1158 available for negotiation has been set to mech_set.
1159 o GSS_S_FAILURE indicates that the requested operation could not be
1160 performed for reasons unspecified at the GSS-API level.
1162 Allows callers to specify the set of security mechanisms that may be
1163 negotiated with the credential identified by cred_handle. This call
1164 is intended for support of specialized callers who need to restrict
1165 the set of negotiable security mechanisms from the set of all
1166 security mechanisms available to the caller (based on available
1167 credentials). Note that if more than one mechanism is specified in
1168 mech_set, the order in which those mechanisms are specified implies a
1169 relative preference.
1171 A.2 GSS_Get_neg_mechs call
1179 Zhu, et al. Expires June 1, 2005 [Page 21]
1181 Internet-Draft GSS-API Negotiation Mechanism December 2004
1184 o cred_handle CREDENTIAL HANDLE -- NULL specifies default
1189 o major_status INTEGER,
1190 o minor_status INTEGER,
1191 o mech_set SET OF OBJECT IDENTIFIER
1193 Return major_status codes:
1195 o GSS_S_COMPLETE indicates that the set of security mechanisms
1196 available for negotiation has been returned in mech_set.
1197 o GSS_S_FAILURE indicates that the requested operation could not be
1198 performed for reasons unspecified at the GSS-API level.
1200 Allows callers to determine the set of security mechanisms available
1201 for negotiation with the credential identified by cred_handle. This
1202 call is intended for support of specialized callers who need to
1203 reduce the set of negotiable security mechanisms from the set of
1204 supported security mechanisms available to the caller (based on
1205 available credentials).
1207 Note: The GSS_Indicate_mechs() function indicates the full set of
1208 mechanism types available on the local system. Since this call has
1209 no input parameter, the returned set is not necessarily available for
1235 Zhu, et al. Expires June 1, 2005 [Page 22]
1237 Internet-Draft GSS-API Negotiation Mechanism December 2004
1240 Appendix B. Changes since RFC2478
1242 SPNEGO implementations in Windows 2000/Windows XP/Windows Server
1243 2003 have the following behavior: no mechlistMIC is produced and
1244 mechlistMIC is not processed if one is provided; if the initiator
1245 sends the last mechanism token, the acceptor will send back a
1246 negotiation token with an accept_complete state and no mechlistMIC
1247 token. In addition, the OID (1.2.840.48018.1.2.2) can be used to
1248 identify the GSS-API Kerberos Version 5 mechanism.
1250 The following changes have been made to be compatible with these
1251 legacy implementations.
1253 * NegTokenTarg is changed to negTokenResp and it is the message
1254 format for all subsequent negotiation tokens.
1255 * NegTokenInit is the message for the initial negotiation message
1256 and that message only.
1257 * mechTypes in negTokenInit is not optional.
1258 * Two MIC tokens are exchanged, one in each direction.
1259 * If the selected mechanism is also the most preferred mechanism
1260 for both peers, it is safe to omit the MIC tokens.
1262 If at least one of the two peers implements the pseudo mechanism
1263 in this document, the negotiation is protected.
1265 The following changes are to address the problems in RFC 2478.
1267 * reqFlags is not protected therefore it should not impact the
1269 * DER encoding is required.
1270 * GSS_GetMIC() input is clarified.
1271 * Per-message integrity services are requested for the negotiated
1274 An implementation that conforms to this specification will not
1275 interoperate with a strict 2748 implementation. Even if the new
1276 implementation always sends a mechlistMIC token, it will still fail
1277 to interoperate. If it is a server, it will fail because it requests
1278 a mechlistMIC token using an option that older implementations simply
1279 do not support. Clients will tend to fail as well.
1281 As an alternative to the approach chosen in this specification, we
1282 could have documented a correct behavior that is fully backward
1283 compatible with RFC 2478 and included an appendix on how to
1284 interoperate with existing incorrect implementations of RFC 2478.
1286 As a practical matter, the SPNEGO implementers within the IETF have
1287 valued interoperability with the Microsoft implementations. We were
1291 Zhu, et al. Expires June 1, 2005 [Page 23]
1293 Internet-Draft GSS-API Negotiation Mechanism December 2004
1296 unable to choose to maintain reasonable security guarantees, maintain
1297 interoperability with the Microsoft implementations and maintain
1298 interoperability with correct implementations of RFC 2478. The
1299 working group was not aware of any RFC 2478 implementations. Even if
1300 there are RFC 2478 implementations, it is unlikely that they will
1301 interoperate because of a critical flaw in the description of the
1302 encoding of the mechanism list in RFC 2478.
1304 With the approach taken in this specification, we get security
1305 between new implementations all the time while maintaining
1306 interoperability with the implementations we have within the IETF
1307 community. The working group believes that this justifies breaking
1308 compatibility with a correct implementation of RFC 2478.
1347 Zhu, et al. Expires June 1, 2005 [Page 24]
1349 Internet-Draft GSS-API Negotiation Mechanism December 2004
1352 Intellectual Property Statement
1354 The IETF takes no position regarding the validity or scope of any
1355 Intellectual Property Rights or other rights that might be claimed to
1356 pertain to the implementation or use of the technology described in
1357 this document or the extent to which any license under such rights
1358 might or might not be available; nor does it represent that it has
1359 made any independent effort to identify any such rights. Information
1360 on the procedures with respect to rights in RFC documents can be
1361 found in BCP 78 and BCP 79.
1363 Copies of IPR disclosures made to the IETF Secretariat and any
1364 assurances of licenses to be made available, or the result of an
1365 attempt made to obtain a general license or permission for the use of
1366 such proprietary rights by implementers or users of this
1367 specification can be obtained from the IETF on-line IPR repository at
1368 http://www.ietf.org/ipr.
1370 The IETF invites any interested party to bring to its attention any
1371 copyrights, patents or patent applications, or other proprietary
1372 rights that may cover technology that may be required to implement
1373 this standard. Please address the information to the IETF at
1377 Disclaimer of Validity
1379 This document and the information contained herein are provided on an
1380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1390 Copyright (C) The Internet Society (2004). This document is subject
1391 to the rights, licenses and restrictions contained in BCP 78, and
1392 except as set forth therein, the authors retain all their rights.
1397 Funding for the RFC Editor function is currently provided by the
1403 Zhu, et al. Expires June 1, 2005 [Page 25]