3 NETWORK WORKING GROUP L. Zhu
4 Internet-Draft P. Leach
5 Obsoletes: 2478 (if approved) K. Jaganathan
6 Expires: July 27, 2005 Microsoft Corporation
12 The Simple and Protected GSS-API Negotiation Mechanism
13 draft-ietf-kitten-2478bis-05
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 July 27, 2005.
44 Copyright (C) The Internet Society (2005).
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.
54 Zhu, et al. Expires July 27, 2005 [Page 1]
56 Internet-Draft GSS-API Negotiation Mechanism January 2005
59 GSS-API peers can use this negotiation mechanism to choose from a
60 common set of security mechanisms.
62 If per-message integrity services are available on the established
63 mechanism context, then the negotiation is protected against an
64 attacker forcing the selection of a mechanism not desired by the
67 This mechanism replaces RFC 2478 in order to fix defects in that
68 specification and to describe how to inter-operate with
69 implementations of that specification commonly deployed on the
74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
75 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
76 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6
77 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6
78 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7
79 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10
80 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10
81 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
82 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
83 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
84 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14
85 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17
86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
90 10.1 Normative References . . . . . . . . . . . . . . . . . . . 21
91 10.2 Informative References . . . . . . . . . . . . . . . . . . 21
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
93 A. SPNEGO ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 23
94 B. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 25
95 B.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25
96 B.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25
97 C. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 27
98 D. mechListMIC Computation Example . . . . . . . . . . . . . . . 29
99 Intellectual Property and Copyright Statements . . . . . . . . 30
110 Zhu, et al. Expires July 27, 2005 [Page 2]
112 Internet-Draft GSS-API Negotiation Mechanism January 2005
117 The GSS-API [RFC2743] provides a generic interface which can be
118 layered atop different security mechanisms such that if communicating
119 peers acquire GSS-API credentials for the same security mechanism,
120 then a security context may be established between them (subject to
121 policy). However, GSS-API does not prescribe the method by which
122 GSS-API peers can establish whether they have a common security
125 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
126 defined here is a pseudo security mechanism, which enables GSS-API
127 peers to determine in-band whether their credentials support a common
128 set of one or more GSS-API security mechanisms, and if so, to invoke
129 the normal security context establishment for a selected common
130 security mechanism. This is most useful for applications which
131 depend on GSS-API implementations and share multiple mechanisms
134 The SPNEGO mechanism negotiation is based on the following model: the
135 initiator proposes a list of security mechanism(s), in decreasing
136 preference order (favorite choice first), the acceptor (also known as
137 the target) either accepts the initiator's preferred security
138 mechanism (the first in the list), or chooses one that is available
139 from the offered list, or rejects the proposed value(s). The target
140 then informs the initiator of its choice.
142 Once a common security mechanism is chosen, mechanism-specific
143 options MAY be negotiated as part of the selected mechanism's context
144 establishment. These negotiations (if any) are internal to the
145 mechanism and opaque to the SPNEGO protocol. As such they are
146 outside the scope of this document.
148 If per-message integrity services are available on the established
149 mechanism security context, then the negotiation is protected to
150 ensure that the mechanism list has not been modified. In cases where
151 an attacker could have materially influenced the negotiation, peers
152 exchange message integrity code (MIC) tokens to confirm the mechanism
153 list has not been modified. If no action of an attacker could have
154 materially modified the outcome of the negotiation, the exchange of
155 MIC tokens is optional (see Section 5). Allowing MIC tokens to be
156 optional in this case provides interoperability with existing
157 implementations while still protecting the negotiation. This
158 interoperability comes at the cost of increased complexity.
160 SPNEGO relies on the concepts developed in the GSS-API specification
161 [RFC2743]. The negotiation data is encapsulated in context-level
162 tokens. Therefore, callers of the GSS-API do not need to be aware of
166 Zhu, et al. Expires July 27, 2005 [Page 3]
168 Internet-Draft GSS-API Negotiation Mechanism January 2005
171 the existence of the negotiation tokens but only of the new
172 pseudo-security mechanism. A failure in the negotiation phase causes
173 a major status code to be returned: GSS_S_BAD_MECH.
222 Zhu, et al. Expires July 27, 2005 [Page 4]
224 Internet-Draft GSS-API Negotiation Mechanism January 2005
227 2. Conventions Used in This Document
229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
231 document are to be interpreted as described in [RFC2119].
278 Zhu, et al. Expires July 27, 2005 [Page 5]
280 Internet-Draft GSS-API Negotiation Mechanism January 2005
283 3. Negotiation Protocol
285 When the established mechanism context provides integrity protection,
286 the mechanism negotiation can be protected. When acquiring
287 negotiated security mechanism tokens, per-message integrity services
288 are always requested by the SPNEGO mechanism.
290 When the established mechanism context supports per-message integrity
291 services, SPNEGO guarantees that the selected mechanism is mutually
294 This section describes the negotiation process of this protocol.
296 3.1 Negotiation Description
298 The first negotiation token sent by the initiator contains an ordered
299 list of mechanisms in decreasing preference order (favorite mechanism
300 first), and optionally the initial mechanism token for the preferred
301 mechanism of the initiator (i.e., the first in the list). (Note that
302 the list MUST NOT contain either this SPNEGO mechanism itself or any
303 mechanism for which the client does not have appropriate
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 being returned in the reply message: accept-completed,
309 accept-incomplete, reject, or request-mic. A reject state will
310 terminate the negotiation; an accept-completed state indicates that
311 not only was the initiator-selected mechanism acceptable to the
312 target, but also that the security mechanism token embedded in the
313 first negotiation message was sufficient to complete the
314 authentication; an accept-incomplete state indicates that further
315 message exchange is needed but the MIC token exchange as described in
316 Section 5 is OPTIONAL; a request-mic state (this state can only be
317 present in the first reply message from the target) indicates the MIC
318 token exchange is REQUIRED if per-message integrity services are
321 Unless the preference order is specified by the application, the
322 policy by which the target chooses a mechanism is an
323 implementation-specific local matter. In the absence of an
324 application specified preference order or other policy, the target
325 SHALL choose the first mechanism in the initiator proposed list for
326 which it has valid credentials.
328 In case of a successful negotiation, the security mechanism in the
329 first reply message represents the value suitable for the target,
330 chosen from the list offered by the initiator.
334 Zhu, et al. Expires July 27, 2005 [Page 6]
336 Internet-Draft GSS-API Negotiation Mechanism January 2005
339 In case of an unsuccessful negotiation, the reject state is returned
340 and generating a context level negotiation token is OPTIONAL.
342 Once a mechanism has been selected, context establishment tokens
343 specific to the selected mechanism are carried within the negotiation
346 Lastly, MIC tokens may be exchanged to ensure the authenticity of the
347 mechanism list received by the target.
349 To avoid conflicts with the use of MIC tokens by SPNEGO,
350 partially-established contexts MUST NOT be used for per-message
351 calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set
352 to false on return from GSS_Init_sec_context() and
353 GSS_Accept_sec_context() even if the underlying mechanism returned
356 Note that in order to avoid an extra round trip, the first context
357 establishment token of the initiator's preferred mechanism SHOULD be
358 embedded in the initial negotiation message (as defined in
359 Section 4.2). (This mechanism token is referred to as the optimistic
360 mechanism token in this document.) In addition, using the optimistic
361 mechanism token allows the initiator to recover from non-fatal errors
362 encountered trying to produce the first mechanism token before a
363 mechanism can be selected. Implementations MAY omit the optimistic
364 mechanism token in cases where the likelihood of the initiator's
365 preferred mechanism not being selected by the acceptor is significant
366 given the cost of generating it.
368 3.2 Negotiation Procedure
370 The basic form of the procedure assumes that per-message integrity
371 services are available on the established mechanism context, and it
372 is summarized as follows:
374 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
375 but requests that SPNEGO be used. SPNEGO can either be explicitly
376 requested or accepted as the default mechanism.
378 (b) The initiator GSS-API implementation generates a negotiation
379 token containing a list of one or more security mechanisms that
380 are available based on the credentials used for this context
381 establishment, and optionally the initial mechanism token for the
382 first mechanism in the list.
390 Zhu, et al. Expires July 27, 2005 [Page 7]
392 Internet-Draft GSS-API Negotiation Mechanism January 2005
395 (c) The GSS-API initiator application sends the token to the target
396 application. The GSS-API target application passes the token by
397 invoking GSS_Accept_sec_context(). The acceptor will do one of
401 (I) If none of the proposed mechanisms are acceptable, the
402 negotiation SHALL be terminated. GSS_Accept_sec_context
403 indicates GSS_S_BAD_MECH. The acceptor MAY output a
404 negotiation token containing a reject state.
406 (II) If either the initiator's preferred mechanism is not
407 accepted by the target or this mechanism is accepted but it
408 is not the acceptor's most preferred mechanism (i.e., the
409 MIC token exchange as described in Section 5 is required),
410 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
411 The acceptor MUST output a negotiation token containing a
414 (III) Otherwise if at least one additional negotiation token
415 from the initiator is needed to establish this context,
416 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
417 outputs a negotiation token containing an accept-incomplete
420 (IV) Otherwise no additional negotiation token from the
421 initiator is needed to establish this context,
422 GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
423 outputs a negotiation token containing an accept_complete
426 If the initiator's preferred mechanism is accepted, and an
427 optimistic mechanism token was included, this mechanism token MUST
428 be passed to the selected mechanism by invoking
429 GSS_Accept_sec_context() and if a response mechanism token is
430 returned, it MUST be included in the response negotiation token.
431 Otherwise, the target will not generate a response mechanism token
434 (d) The GSS-API target application returns the negotiation token to
435 the initiator application. The GSS-API initiator application
436 passes the token by invoking GSS_Init_sec_context(). The security
437 context initialization is then continued according to the standard
438 GSS-API conventions for the selected mechanism, where the tokens
439 of the selected mechanism are encapsulated in negotiation messages
440 (see Section 4) until GSS_S_COMPLETE is returned for both the
441 initiator and the target by the selected security mechanism.
446 Zhu, et al. Expires July 27, 2005 [Page 8]
448 Internet-Draft GSS-API Negotiation Mechanism January 2005
451 (e) MIC tokens are then either skipped or exchanged according to
454 Note that the *_req_flag input parameters for context establishment
455 are relative to the selected mechanism, as are the *_state output
456 parameters. i.e., these parameters are not applicable to the
457 negotiation process per se.
459 On receipt of a negotiation token on the target side, a GSS-API
460 implementation that does not support negotiation would indicate the
461 GSS_S_BAD_MECH status as if a particular basic security mechanism had
462 been requested and was not supported.
464 When a GSS-API credential is acquired for the SPNEGO mechanism the
465 implementation SHOULD produce a credential element for the SPNEGO
466 mechanism which internally contains GSS-API credential elements for
467 all mechanisms for which the principal has credentials available,
468 except for any mechanisms which are not to be negotiated, either as
469 per implementation-, site- or application-specific policy. See
470 Appendix B for interfaces for expressing application policy.
502 Zhu, et al. Expires July 27, 2005 [Page 9]
504 Internet-Draft GSS-API Negotiation Mechanism January 2005
509 The type definitions in this section assume an ASN.1 module
510 definition of the following form:
514 iso(1) identified-organization(3) dod(6) internet(1)
515 security(5) mechanism(5) snego (2) modules(4) spec2(2)
516 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
518 -- rest of definitions here
523 This specifies that the tagging context for the module will be
524 explicit and non-automatic.
526 The encoding of SPNEGO protocol messages shall obey the Distinguished
527 Encoding Rules (DER) of ASN.1 as described in [X690].
531 In this negotiation model, each OID represents one GSS-API mechanism
532 or one variant (see Section 6) of it according to [RFC2743].
535 MechType ::= OBJECT IDENTIFIER
536 -- OID represents each security mechanism as suggested by
539 MechTypeList ::= SEQUENCE OF MechType
542 4.2 Negotiation Tokens
544 The syntax of the initial negotiation tokens follows the
545 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The
546 SPNEGO pseudo mechanism is identified by the Object Identifier
547 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
548 Subsequent tokens MUST NOT be encapsulated in this GSS-API generic
551 This section specifies the syntax of the inner token for the initial
552 message and the syntax of subsequent context establishment tokens.
558 Zhu, et al. Expires July 27, 2005 [Page 10]
560 Internet-Draft GSS-API Negotiation Mechanism January 2005
563 NegotiationToken ::= CHOICE {
564 negTokenInit [0] NegTokenInit,
565 negTokenResp [1] NegTokenResp
572 NegTokenInit ::= SEQUENCE {
573 mechTypes [0] MechTypeList,
574 reqFlags [1] ContextFlags OPTIONAL,
575 -- inherited from RFC 2478 for backward compatibility,
576 -- RECOMMENDED to be left out
577 mechToken [2] OCTET STRING OPTIONAL,
578 mechListMIC [3] OCTET STRING OPTIONAL,
581 ContextFlags ::= BIT STRING {
591 This is the syntax for the inner token of the initial negotiation
596 This field contains one or more security mechanisms available
597 for the initiator in decreasing preference order (favorite
602 This field, if present, contains the service options that are
603 requested to establish the context (the req_flags parameter of
604 GSS_Init_sec_context()). This field is inherited from RFC 2478
605 and it is not integrity protected. For implementations of this
606 specification the initiator SHOULD omit this reqFlags field,
607 and the acceptor MUST ignore this reqFlags field.
614 Zhu, et al. Expires July 27, 2005 [Page 11]
616 Internet-Draft GSS-API Negotiation Mechanism January 2005
621 This field, if present, contains the optimistic mechanism
626 This field, if present, contains a MIC token for the mechanism
627 list in the initial negotiation message. This MIC token is
628 computed according to Section 5.
633 NegTokenResp ::= SEQUENCE {
634 negState [0] ENUMERATED {
635 accept-completed (0),
636 accept-incomplete (1),
640 -- REQUIRED in the first reply from the target
641 supportedMech [1] MechType OPTIONAL,
642 -- present only in the first reply from the target
643 responseToken [2] OCTET STRING OPTIONAL,
644 mechListMIC [3] OCTET STRING OPTIONAL,
648 This is the syntax for all subsequent negotiation messages.
652 This field, if present, contains the state of the negotiation.
657 No further negotiation message from the peer is expected,
658 and the security context is established for the sender.
662 At least one more negotiation message from the peer is
663 needed to establish the security context.
670 Zhu, et al. Expires July 27, 2005 [Page 12]
672 Internet-Draft GSS-API Negotiation Mechanism January 2005
677 The sender terminates the negotiation.
681 The sender indicates that the exchange of MIC tokens, as
682 described in Section 5, will be REQUIRED if per-message
683 integrity services are available on the mechanism context to
684 be established. This value SHALL only be present in the
685 first reply from the target.
687 This field is REQUIRED in the first reply from the target, and
688 it is OPTIONAL thereafter. When negState is absent the actual
689 state should be inferred from the state of the negotiated
694 This field SHALL only be present in the first reply from the
695 target. It MUST be one of the mechanism(s) offered by the
700 This field, if present, contains tokens specific to the
705 This field, if present, contains a MIC token for the mechanism
706 list in the initial negotiation message. This MIC token is
707 computed according to Section 5.
726 Zhu, et al. Expires July 27, 2005 [Page 13]
728 Internet-Draft GSS-API Negotiation Mechanism January 2005
731 5. Processing of mechListMIC
733 If the mechanism selected by the negotiation does not support
734 integrity protection, then no mechlistMIC token is used.
736 Otherwise, if the accepted mechanism is the most preferred mechanism
737 of both the initiator and the acceptor, then the MIC token exchange,
738 as described later in this section, is OPTIONAL. A mechanism is the
739 acceptor's most preferred mechanism if there is no other mechanism
740 which, had it been present in the mechanism list, the acceptor would
741 have preferred over the accepted mechanism.
743 In all other cases, MIC tokens MUST be exchanged after the mechanism
744 context is fully established.
746 a) The mechlistMIC token (or simply the MIC token) is computed over
747 the mechanism list in the initial negotiation message by invoking
748 GSS_GetMIC() as follows: the input context_handle is the
749 established mechanism context, the input qop_req is 0, and the
750 input message is the DER encoding of the value of type
751 MechTypeList which is contained in the "mechTypes" field of the
752 NegTokenInit. The input message is NOT the DER encoding of the
753 type "[0] MechTypeList".
755 b) If the selected mechanism exchanges an even number of mechanism
756 tokens (i.e., the acceptor sends the last mechanism token), the
757 acceptor does the following when generating the negotiation
758 message containing the last mechanism token: if the MIC token
759 exchange is optional, GSS_Accept_sec_context() either indicates
760 GSS_S_COMPLETE and does not include a mechlistMIC token, or
761 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
762 and an accept-incomplete state; if the MIC token exchange is
763 required, GSS_Accept_sec_context() indicates
764 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
765 Acceptors that wish to be compatible with legacy Windows SPNEGO
766 implementations as described in Appendix C should not generate a
767 mechlistMIC token when the MIC token exchange is not required.
768 The initiator then processes the last mechanism token, and does
769 one of the following:
771 (I) If a mechlistMIC token was included, and is correctly
772 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The
773 output negotiation message contains a mechlistMIC token, and an
774 accept_complete state. The acceptor MUST then verify this
782 Zhu, et al. Expires July 27, 2005 [Page 14]
784 Internet-Draft GSS-API Negotiation Mechanism January 2005
787 (II) If a mechlistMIC token was included but is incorrect, the
788 negotiation SHALL be terminated. GSS_Init_sec_context()
789 indicates GSS_S_DEFECTIVE_TOKEN.
791 (III) If no mechlistMIC token was included, and the MIC token
792 exchange is not required, GSS_Init_sec_context() indicates
793 GSS_S_COMPLETE with no output token.
795 (IV) If no mechlistMIC token was included, but the MIC token
796 exchange is required, the negotiation SHALL be terminated.
797 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
799 c) In the case that the chosen mechanism exchanges an odd number of
800 mechanism tokens (i.e., the initiator sends the last mechanism
801 token), the initiator does the following when generating the
802 negotiation message containing the last mechanism token: if the
803 negState was request-mic in the first reply from the target, a
804 mechlistMIC token MUST be included, otherwise the mechlistMIC
805 token is OPTIONAL. (Note that the MIC token exchange is required
806 if a mechanism other than the initiator's first choice is chosen.)
807 In the case that the optimistic mechanism token is the only
808 mechanism token for the initiator's preferred mechanism, the
809 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC
810 token is included, GSS_Init_sec_context() indicates
811 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with
812 legacy Windows SPNEGO implementations as described in Appendix C
813 should not generate a mechlistMIC token when the MIC token
814 exchange is not required. The acceptor then processes the last
815 mechanism token and does one of the following:
817 (I) If a mechlistMIC token was included and is correctly verified,
818 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output
819 negotiation message contains a mechlistMIC token and an
820 accept_complete state. The initiator MUST then verify this
823 (II) If a mechlistMIC token was included but is incorrect, the
824 negotiation SHALL be terminated. GSS_Accept_sec_context()
825 indicates GSS_S_DEFECTIVE_TOKEN.
827 (III) If no mechlistMIC token was included and the mechlistMIC
828 token exchange is not required, GSS_Accept_sec_context()
829 indicates GSS_S_COMPLETE. The output negotiation message
830 contains an accept_complete state.
838 Zhu, et al. Expires July 27, 2005 [Page 15]
840 Internet-Draft GSS-API Negotiation Mechanism January 2005
843 (IV) In the case that the optimistic mechanism token is also the
844 last mechanism token (when the initiator's preferred mechanism
845 is accepted by the target) and the target sends a request-mic
846 state but the initiator did not send a mechlistMIC token, the
847 target then MUST include a mechlistMIC token in that first
848 reply. GSS_Accept_sec_context() indicates
849 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received
850 mechlistMIC token and generate a mechlistMIC token to send back
851 to the target. The target SHALL in turn verify the returned
852 mechlistMIC token and complete the negotiation.
854 (V) If no mechlistMIC token was included and the acceptor sent a
855 request-mic state in the first reply message (the exchange of
856 MIC tokens is required), the negotiation SHALL be terminated.
857 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
894 Zhu, et al. Expires July 27, 2005 [Page 16]
896 Internet-Draft GSS-API Negotiation Mechanism January 2005
901 Two mechanisms are provided for extensibility. First, the ASN.1
902 structures in this specification MAY be expanded by IETF standards
903 action. Implementations receiving unknown fields MUST ignore these
906 Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
907 mechanism variants) may be included in the set of preferred
908 mechanisms by an initiator. The acceptor can choose to honor this
909 request by preferring mechanisms that have the included attributes.
910 Future work within the Kitten working group is expected to
911 standardize common attributes that SPNEGO mechanisms may wish to
912 support. At this time it is sufficient to say that initiators MAY
913 include OIDs that do not correspond to mechanisms. Such OIDs MAY
914 influence the acceptor's choice of mechanism. As discussed in
915 Section 5, if there are mechanisms that if present in the initiator's
916 list of mechanisms might be preferred by the acceptor to the
917 initiator's preferred mechanism, the acceptor MUST demand the MIC
918 token exchange. As the consequence, acceptors MUST demand the MIC
919 token exchange if they support negotiation of attributes not
920 available in the initiator's preferred mechanism regardless of
921 whether the initiator actually requested these attributes.
950 Zhu, et al. Expires July 27, 2005 [Page 17]
952 Internet-Draft GSS-API Negotiation Mechanism January 2005
955 7. Security Considerations
957 In order to produce the MIC token for the mechanism list, the
958 mechanism must provide integrity protection. When the selected
959 mechanism does not support integrity protection, the negotiation is
960 vulnerable: an active attacker can force it to use a security
961 mechanism that is not mutually preferred but is acceptable to the
964 This protocol provides the following guarantees when per-message
965 integrity services are available on the established mechanism context
966 and the mechanism list was altered by an adversary such that a
967 mechanism which is not mutually preferred could be selected:
969 a) If the last mechanism token is sent by the initiator, both peers
971 b) If the last mechanism token is sent by the acceptor, the acceptor
972 shall not complete and the initiator at worst shall complete with
973 its preferred mechanism being selected.
975 The negotiation may not be terminated if an alteration was made but
976 it had no material impact.
978 The protection of the negotiation depends on the strength of the
979 integrity protection. In particular, the strength of SPNEGO is no
980 stronger than the integrity protection of the weakest mechanism
981 acceptable to GSS-API peers.
983 Note that where there exist multiple mechanisms with similar context
984 tokens, but different semantics, such that some or all of the
985 mechanisms' context tokens can be easily altered so that one
986 mechanism's context tokens may pass for another of the similar
987 mechanism's context tokens, then there may exist downgrade or similar
988 attacks. For example, if a given family of mechanisms uses the same
989 context token syntax for two or more variants and depends on the OID
990 in the initial token's pseudo-ASN.1/DER wrapper, but does not provide
991 integrity protection for that OID, then there may exist an attack
992 against those mechanisms. SPNEGO does not generally defeat such
995 In all cases, the communicating peers are exposed to the denial of
1006 Zhu, et al. Expires July 27, 2005 [Page 18]
1008 Internet-Draft GSS-API Negotiation Mechanism January 2005
1011 8. IANA Considerations
1013 This document has no actions for IANA.
1062 Zhu, et al. Expires July 27, 2005 [Page 19]
1064 Internet-Draft GSS-API Negotiation Mechanism January 2005
1069 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
1070 Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero and Bill
1071 Sommerfeld for their comments and suggestions during development of
1074 Luke Howard provided a prototype of this protocol in Heimdal and
1075 resolved several issues in the initial draft.
1077 Eric Baize and Denis Pinkas wrote the original SPNEGO specification
1078 [RFC2478] of which some of the text has been retained in this
1118 Zhu, et al. Expires July 27, 2005 [Page 20]
1120 Internet-Draft GSS-API Negotiation Mechanism January 2005
1125 10.1 Normative References
1127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1128 Requirement Levels", BCP 14, RFC 2119, March 1997.
1130 [RFC2743] Linn, J., "Generic Security Service Application Program
1131 Interface Version 2, Update 1", RFC 2743, January 2000.
1133 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1134 Rules (BER), Canonical Encoding Rules (CER) and
1135 Distinguished Encoding Rules (DER), ITU-T Recommendation
1136 X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
1138 10.2 Informative References
1140 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1141 Negotiation Mechanism", RFC 2478, December 1998.
1147 Microsoft Corporation
1152 Email: lzhu@microsoft.com
1156 Microsoft Corporation
1161 Email: paulle@microsoft.com
1165 Microsoft Corporation
1170 Email: karthikj@microsoft.com
1175 Zhu, et al. Expires July 27, 2005 [Page 21]
1177 Internet-Draft GSS-API Negotiation Mechanism January 2005
1182 1775 Wiehle Avenue, 2nd Floor
1186 Email: wyllys.ingersoll@sun.com
1231 Zhu, et al. Expires July 27, 2005 [Page 22]
1233 Internet-Draft GSS-API Negotiation Mechanism January 2005
1236 Appendix A. SPNEGO ASN.1 Module
1239 iso(1) identified-organization(3) dod(6) internet(1)
1240 security(5) mechanism(5) snego (2) modules(4) spec2(2)
1241 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1243 MechType ::= OBJECT IDENTIFIER
1244 -- OID represents each security mechanism as suggested by
1247 MechTypeList ::= SEQUENCE OF MechType
1249 NegotiationToken ::= CHOICE {
1250 negTokenInit [0] NegTokenInit,
1251 negTokenResp [1] NegTokenResp
1254 NegTokenInit ::= SEQUENCE {
1255 mechTypes [0] MechTypeList,
1256 reqFlags [1] ContextFlags OPTIONAL,
1257 -- inherited from RFC 2478 for backward compatibility,
1258 -- RECOMMENDED to be left out
1259 mechToken [2] OCTET STRING OPTIONAL,
1260 mechListMIC [3] OCTET STRING OPTIONAL,
1263 NegTokenResp ::= SEQUENCE {
1264 negState [0] ENUMERATED {
1265 accept-completed (0),
1266 accept-incomplete (1),
1270 -- REQUIRED in the first reply from the target
1271 supportedMech [1] MechType OPTIONAL,
1272 -- present only in the first reply from the target
1273 responseToken [2] OCTET STRING OPTIONAL,
1274 mechListMIC [3] OCTET STRING OPTIONAL,
1278 ContextFlags ::= BIT STRING {
1287 Zhu, et al. Expires July 27, 2005 [Page 23]
1289 Internet-Draft GSS-API Negotiation Mechanism January 2005
1343 Zhu, et al. Expires July 27, 2005 [Page 24]
1345 Internet-Draft GSS-API Negotiation Mechanism January 2005
1348 Appendix B. GSS-API Negotiation Support API
1350 In order to provide to a GSS-API caller (either the initiator or the
1351 target or both) the ability to choose among the set of supported
1352 mechanisms a reduced set of mechanisms for negotiation, two
1353 additional APIs are defined:
1355 o GSS_Get_neg_mechs() indicates the set of security mechanisms
1356 available on the local system to the caller for negotiation, for
1357 which appropriate credentials are available.
1358 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be
1359 used on the local system by the caller for negotiation, for the
1362 B.1 GSS_Set_neg_mechs call
1366 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default
1368 o mech_set SET OF OBJECT IDENTIFIER
1372 o major_status INTEGER,
1373 o minor_status INTEGER
1375 Return major_status codes:
1377 o GSS_S_COMPLETE indicates that the set of security mechanisms
1378 available for negotiation has been set to mech_set.
1379 o GSS_S_FAILURE indicates that the requested operation could not be
1380 performed for reasons unspecified at the GSS-API level.
1382 Allows callers to specify the set of security mechanisms that may be
1383 negotiated with the credential identified by cred_handle. This call
1384 is intended for support of specialized callers who need to restrict
1385 the set of negotiable security mechanisms from the set of all
1386 security mechanisms available to the caller (based on available
1387 credentials). Note that if more than one mechanism is specified in
1388 mech_set, the order in which those mechanisms are specified implies a
1389 relative preference.
1391 B.2 GSS_Get_neg_mechs call
1399 Zhu, et al. Expires July 27, 2005 [Page 25]
1401 Internet-Draft GSS-API Negotiation Mechanism January 2005
1404 o cred_handle CREDENTIAL HANDLE -- NULL specifies default
1409 o major_status INTEGER,
1410 o minor_status INTEGER,
1411 o mech_set SET OF OBJECT IDENTIFIER
1413 Return major_status codes:
1415 o GSS_S_COMPLETE indicates that the set of security mechanisms
1416 available for negotiation has been returned in mech_set.
1417 o GSS_S_FAILURE indicates that the requested operation could not be
1418 performed for reasons unspecified at the GSS-API level.
1420 Allows callers to determine the set of security mechanisms available
1421 for negotiation with the credential identified by cred_handle. This
1422 call is intended for support of specialized callers who need to
1423 reduce the set of negotiable security mechanisms from the set of
1424 supported security mechanisms available to the caller (based on
1425 available credentials).
1427 Note: The GSS_Indicate_mechs() function indicates the full set of
1428 mechanism types available on the local system. Since this call has
1429 no input parameter, the returned set is not necessarily available for
1455 Zhu, et al. Expires July 27, 2005 [Page 26]
1457 Internet-Draft GSS-API Negotiation Mechanism January 2005
1460 Appendix C. Changes since RFC2478
1462 SPNEGO implementations in Microsoft Windows 2000/Windows
1463 XP/Windows Server 2003 have the following behavior: no mechlistMIC
1464 is produced and mechlistMIC is not processed if one is provided;
1465 if the initiator sends the last mechanism token, the acceptor will
1466 send back a negotiation token with an accept_complete state and no
1467 mechlistMIC token. In addition, an incorrect OID
1468 (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos
1469 Version 5 mechanism.
1471 The following changes have been made to be compatible with these
1472 legacy implementations.
1474 * NegTokenTarg is changed to negTokenResp and it is the message
1475 format for all subsequent negotiation tokens.
1476 * NegTokenInit is the message for the initial negotiation message
1477 and that message only.
1478 * mechTypes in negTokenInit is not optional.
1479 * If the selected mechanism is also the most preferred mechanism
1480 for both peers, it is safe to omit the MIC tokens.
1482 If at least one of the two peers implements the updated pseudo
1483 mechanism in this document, the negotiation is protected.
1485 The following changes are to address problems in RFC 2478.
1487 * reqFlags is not protected therefore it should not impact the
1489 * DER encoding is required.
1490 * GSS_GetMIC() input is clarified.
1491 * Per-message integrity services are requested for the negotiated
1493 * Two MIC tokens are exchanged, one in each direction.
1495 An implementation that conforms to this specification will not
1496 inter-operate with a strict 2748 implementation. Even if the new
1497 implementation always sends a mechlistMIC token, it will still fail
1498 to inter-operate. If it is a server, it will fail because it
1499 requests a mechlistMIC token using an option that older
1500 implementations simply do not support. Clients will tend to fail as
1503 As an alternative to the approach chosen in this specification, we
1504 could have documented a correct behavior that is fully backward
1505 compatible with RFC 2478 and included an appendix on how to
1506 inter-operate with existing incorrect implementations of RFC 2478.
1511 Zhu, et al. Expires July 27, 2005 [Page 27]
1513 Internet-Draft GSS-API Negotiation Mechanism January 2005
1516 As a practical matter, the SPNEGO implementers within the IETF have
1517 valued interoperability with the Microsoft implementations. We were
1518 unable to choose to maintain reasonable security guarantees, maintain
1519 interoperability with the Microsoft implementations and maintain
1520 interoperability with correct implementations of RFC 2478. The
1521 working group was not aware of any RFC 2478 implementations deployed
1522 on the Internet. Even if there are such implementations, it is
1523 unlikely that they will inter-operate because of a critical flaw in
1524 the description of the encoding of the mechanism list in RFC 2478.
1526 With the approach taken in this specification, security is ensured
1527 between new implementations all the time while maintaining
1528 interoperability with the implementations deployed within the IETF
1529 community. The working group believes that this justifies breaking
1530 compatibility with a correct implementation of RFC 2478.
1567 Zhu, et al. Expires July 27, 2005 [Page 28]
1569 Internet-Draft GSS-API Negotiation Mechanism January 2005
1572 Appendix D. mechListMIC Computation Example
1574 The following is an example to illustrate how the mechListMIC field
1577 The initial part of the DER encoding of NegTokenInit is constructed
1578 as follows (the "nn" are length encodings, possibly longer than one
1581 30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
1584 -- contents octets of the SEQUENCE begin with
1585 -- DER encoding of "[0] MechTypeList":
1586 A0 -- identifier octet for constructed [0]
1589 -- contents of the constructed [0] are DER encoding
1590 -- of MechTypeList (which is a SEQUENCE):
1591 30 -- identifier octet for constructed SEQUENCE
1594 -- contents octets of the SEQUENCE begin with
1595 -- DER encoding of OBJECT IDENTIFIER:
1596 06 -- identifier octet for primitive OBJECT IDENTIFIER
1598 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
1599 -- {1 2 840 113554 1 2 2}
1601 If a mechlistMIC needs to be generated (according to the rules in
1602 Section 5), it is computed by using the DER encoding of the type
1603 MechTypeList data from the initiator's NegTokenInit token as input to
1604 the GSS_GetMIC() function. In this case, the MIC would be computed
1605 over the following octets:
1607 DER encoding of MechTypeList:
1608 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
1610 Note that the identifier octet and length octet(s) for constructed
1611 [0] (A0 nn) are not included in the MIC computation.
1623 Zhu, et al. Expires July 27, 2005 [Page 29]
1625 Internet-Draft GSS-API Negotiation Mechanism January 2005
1628 Intellectual Property Statement
1630 The IETF takes no position regarding the validity or scope of any
1631 Intellectual Property Rights or other rights that might be claimed to
1632 pertain to the implementation or use of the technology described in
1633 this document or the extent to which any license under such rights
1634 might or might not be available; nor does it represent that it has
1635 made any independent effort to identify any such rights. Information
1636 on the procedures with respect to rights in RFC documents can be
1637 found in BCP 78 and BCP 79.
1639 Copies of IPR disclosures made to the IETF Secretariat and any
1640 assurances of licenses to be made available, or the result of an
1641 attempt made to obtain a general license or permission for the use of
1642 such proprietary rights by implementers or users of this
1643 specification can be obtained from the IETF on-line IPR repository at
1644 http://www.ietf.org/ipr.
1646 The IETF invites any interested party to bring to its attention any
1647 copyrights, patents or patent applications, or other proprietary
1648 rights that may cover technology that may be required to implement
1649 this standard. Please address the information to the IETF at
1653 Disclaimer of Validity
1655 This document and the information contained herein are provided on an
1656 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1657 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1658 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1659 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1660 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1661 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1666 Copyright (C) The Internet Society (2005). This document is subject
1667 to the rights, licenses and restrictions contained in BCP 78, and
1668 except as set forth therein, the authors retain all their rights.
1673 Funding for the RFC Editor function is currently provided by the
1679 Zhu, et al. Expires July 27, 2005 [Page 30]