| blob | 48c11d2169c5a70f02c08728f8d5a1507c9f939f |
3 NETWORK WORKING GROUP L. Zhu
4 Internet-Draft P. Leach
5 Obsoletes: 2478 (if approved) K. Jaganathan
6 Expires: June 15, 2005 Microsoft Corporation
7 W. Ingersoll
8 Sun Microsystems
9 December 15, 2004
12 The Simple and Protected GSS-API Negotiation Mechanism
13 draft-ietf-kitten-2478bis-04
15 Status of this Memo
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
22 RFC 3668.
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
27 Internet-Drafts.
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 15, 2005.
42 Copyright Notice
44 Copyright (C) The Internet Society (2004).
46 Abstract
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 15, 2005 [Page 1]
56 \f
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.
63 If per-message integrity services are available on the established
64 mechanism context, then the negotiation is protected against an
65 attacker forcing the selection of a mechanism not desired by the
66 peers.
68 This mechanism replaces RFC 2478 in order to fix defects in that
69 specification and to describe how to interoperate with
70 implementations of that specification commonly deployed on the
71 Internet.
73 Table of Contents
75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
76 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
77 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6
78 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6
79 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7
80 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10
81 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10
82 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
83 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
84 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
85 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14
86 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17
87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
91 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
92 10.2 Informative References . . . . . . . . . . . . . . . . . . . 21
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
94 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 23
95 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23
96 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23
97 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 25
98 C. mechListMIC Computation Example . . . . . . . . . . . . . . . 27
99 Intellectual Property and Copyright Statements . . . . . . . . 28
111 Zhu, et al. Expires June 15, 2005 [Page 2]
112 \f
113 Internet-Draft GSS-API Negotiation Mechanism December 2004
116 1. Introduction
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
124 mechanism.
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 support a common set of one or more GSS-API
131 security mechanisms, and if so, to invoke the normal security context
132 establishment for a selected common security mechanism. This is most
133 useful for applications which depend on GSS-API implementations and
134 share multiple mechanisms between the peers.
136 The SPNEGO mechanism negotiation is based on the following model: the
137 initiator proposes a list of security mechanism(s), in decreasing
138 preference order (favorite choice first), the acceptor (also known as
139 the target) either accepts the initiator's preferred security
140 mechanism (the first in the list), or chooses one that is available
141 from the offered list, or rejects the proposed value(s). The target
142 then informs the initiator of its choice.
144 Once a common security mechanism is chosen, mechanism-specific
145 options MAY be negotiated as part of the selected mechanism's context
146 establishment. These negotiations (if any) are internal to the
147 mechanism and opaque to the SPNEGO protocol. As such they are
148 outside the scope of this document.
150 If per-message integrity services are available on the established
151 mechanism security context, then the negotiation is protected to
152 ensure that the mechanism list has not been modified. In cases where
153 an attacker could have materially influenced the negotiation, peers
154 exchange message integrity code (MIC) tokens to confirm the mechanism
155 list has not been modified. If no action of an attacker could have
156 materially modified the outcome of the negotiation, the exchange of
157 MIC tokens is optional (see Section 5). Allowing MIC tokens to be
158 optional in this case provides interoperability with existing
159 implementations while still protecting the negotiation. This
160 interoperability comes at the cost of increased complexity.
162 In order to avoid an extra round trip, the first context
163 establishment token of the initiator's preferred mechanism SHOULD be
167 Zhu, et al. Expires June 15, 2005 [Page 3]
168 \f
169 Internet-Draft GSS-API Negotiation Mechanism December 2004
172 embedded in the initial negotiation message (as defined in Section
173 4.2). (This mechanism token is referred to as the optimistic
174 mechanism token in this document.) In addition, using the optimistic
175 mechanism token allows the initiator to recover from non-fatal errors
176 encountered trying to produce the first mechanism token before a
177 mechanism can be selected. Implementations MAY omit the optimistic
178 mechanism token in cases where the likelihood of the initiator's
179 preferred mechanism not being selected by the acceptor is significant
180 given the cost of generating it.
182 SPNEGO relies on the concepts developed in the GSS-API specification
183 [RFC2743]. The negotiation data is encapsulated in context-level
184 tokens. Therefore, callers of the GSS-API do not need to be aware of
185 the existence of the negotiation tokens but only of the new
186 pseudo-security mechanism. A failure in the negotiation phase causes
187 a major status code to be returned: GSS_S_BAD_MECH.
223 Zhu, et al. Expires June 15, 2005 [Page 4]
224 \f
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 15, 2005 [Page 5]
280 \f
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
293 preferred.
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 mechanism
301 first), and optionally the initial mechanism token for the preferred
302 mechanism of the initiator (i.e., the first in the list). (Note that
303 the list MUST NOT contain mechanisms for which the client does not
304 have appropriate credentials.)
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 optimistic mechanism token was sufficient
313 to complete the authentication; an accept_incomplete state indicates
314 that further message exchange is needed but the MIC token exchange as
315 described in Section 5 is OPTIONAL; a request_mic state (this state
316 can only be present in the first reply message from the target)
317 indicates the MIC token exchange is REQUIRED if per-message integrity
318 services are available.
320 Unless the preference order is specified by the application, the
321 policy by which the target chooses a mechanism is an
322 implementation-specific local matter. In the absence of an
323 application specified preference order or other policy, the target
324 SHALL choose the first mechanism in the initiator proposed list for
325 which it has valid credentials.
327 In case of a successful negotiation, the security mechanism in the
328 first reply message represents the value suitable for the target,
329 chosen from the list offered by the initiator.
331 In case of an unsuccessful negotiation, the reject state is returned
335 Zhu, et al. Expires June 15, 2005 [Page 6]
336 \f
337 Internet-Draft GSS-API Negotiation Mechanism December 2004
340 and it is OPTIONAL to emit a context level negotiation token.
342 Once a mechanism has been selected, context establishment tokens
343 specific to the selected mechanism are carried within the negotiation
344 tokens.
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
354 true.
356 3.2 Negotiation Procedure
358 The basic form of the procedure assumes that per-message integrity
359 services are available on the established mechanism context, and it
360 is summarized as follows:
362 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
363 but requests that SPNEGO be used. SPNEGO can either be explicity
364 requested or accepted as the default mechanism.
366 (b) The initiator GSS-API implementation emits a negotiation token
367 containing a list of one or more security mechanisms that are
368 available based on the credentials used for this context
369 establishment, and optionally the initial mechanism token for the
370 first mechanism in the list.
372 (c) The GSS-API initiator application sends the token to the target
373 application. The GSS-API target application deposits the token by
374 invoking GSS_Accept_sec_context(). The acceptor will do one of
375 the following:
378 (I) If none of the proposed mechanisms are acceptable, the
379 negotiation SHALL be terminated. GSS_Accept_sec_context
380 indicates GSS_S_BAD_MECH. The acceptor MAY output a
381 negotiation token containing a reject state.
383 (II) If either the initiator's preferred mechanism is not
384 accepted by the target or this mechanism is accepted but it
385 is not the acceptor's most preferred mechanism (i.e., the
386 MIC token exchange as described in Section 5 is required),
387 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
391 Zhu, et al. Expires June 15, 2005 [Page 7]
392 \f
393 Internet-Draft GSS-API Negotiation Mechanism December 2004
396 The acceptor MUST output a negotiation token containing a
397 request_mic state.
399 (III) Otherwise if at least one additional negotiation token
400 from the initiator is needed to establish this context,
401 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
402 outputs a negotiation token containing an accept_incomplete
403 state.
405 (IV) Otherwise no additional negotiation token from the
406 initiator is needed to establish this context,
407 GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
408 outputs a negotiation token containing an accept_complete
409 state.
411 If the initiator's preferred mechanism is accepted, and an
412 optimistic mechanism token was included, this mechanism token MUST
413 be deposited to the selected mechanism by invoking
414 GSS_Accept_sec_context() and if a response mechanism token is
415 emitted, it MUST be included in the response negotiation token.
416 Otherwise, the target will not emit a response mechanism token in
417 the first reply.
419 (d) The GSS-API target application returns the negotiation token to
420 the initiator application. The GSS-API initiator application
421 deposits the token by invoking GSS_Init_sec_context(). The
422 security context initialization is then continued according to the
423 standard GSS-API conventions for the selected mechanism, where the
424 tokens of the selected mechanism are encapsulated in negotiation
425 messages (see Section 4) until the GSS_S_COMPLETE is returned for
426 both the initiator and the target by the selected security
427 mechanism.
429 (e) MIC tokens are then either skipped or exchanged according to
430 Section 5.
432 Note that the *_req_flag input parameters for context establishment
433 are relative to the selected mechanism, as are the *_state output
434 parameters. i.e., these parameters are not applicable to the
435 negotiation process per se.
437 On receipt of a negotiation token on the target side, a GSS-API
438 implementation that does not support negotiation would indicate the
439 GSS_S_BAD_MECH status as if a particular basic security mechanism had
440 been requested and was not supported.
442 When a GSS-API credential is acquired for the SPNEGO mechanism the
443 implementation SHOULD produce a credential element for the SPNEGO
447 Zhu, et al. Expires June 15, 2005 [Page 8]
448 \f
449 Internet-Draft GSS-API Negotiation Mechanism December 2004
452 mechanism which internally contains GSS-API credential elements for
453 all mechanisms for which the principal has credentials available,
454 except for any mechanisms which are not to be negotiated, either as
455 per implementation-, site- or application-specific policy. See
456 Appendix A for interfaces for expressing application policy.
503 Zhu, et al. Expires June 15, 2005 [Page 9]
504 \f
505 Internet-Draft GSS-API Negotiation Mechanism December 2004
508 4. Token Definitions
510 The type definitions in this section assume an ASN.1 module
511 definition of the following form:
514 SPNEGOASNOneSpec {
515 iso(1) identified-organization(3) dod(6) internet(1)
516 security(5) mechanism(5) snego (2) modules(4) spec2(2)
517 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
519 -- rest of definitions here
521 END
524 This specifies that the tagging context for the module will be
525 explicit and non-automatic.
527 The encoding of SPNEGO protocol messages shall obey the Distinguished
528 Encoding Rules (DER) of ASN.1 as described in [X690].
530 4.1 Mechanism Types
532 In this negotiation model, each OID represents one GSS-API mechanism
533 or one variant (see Section 6) of it according to [RFC2743].
536 MechType ::= OBJECT IDENTIFIER
537 -- OID represents each security mechanism as suggested by
538 -- [RFC2743]
540 MechTypeList ::= SEQUENCE OF MechType
543 4.2 Negotiation Tokens
545 The syntax of the initial negotiation tokens follows the
546 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The
547 SPNEGO pseudo mechanism is identified by the Object Identifier
548 specified in Section 1. Subsequent tokens MUST NOT be encapsulated
549 in this GSS-API generic token framing.
551 This section specifies the syntax of the inner token for the initial
552 message and the syntax of subsequent context establishment tokens.
554 NegotiationToken ::= CHOICE {
555 negTokenInit [0] NegTokenInit,
559 Zhu, et al. Expires June 15, 2005 [Page 10]
560 \f
561 Internet-Draft GSS-API Negotiation Mechanism December 2004
564 negTokenResp [1] negTokenResp
565 }
569 4.2.1 negTokenInit
571 NegTokenInit ::= SEQUENCE {
572 mechTypes [0] MechTypeList,
573 reqFlags [1] ContextFlags OPTIONAL,
574 -- maintained from RFC 2478 for backward compatibility,
575 -- RECOMMENDED to be left out
576 mechToken [2] OCTET STRING OPTIONAL,
577 mechListMIC [3] OCTET STRING OPTIONAL,
578 ...
579 }
580 ContextFlags ::= BIT STRING {
581 delegFlag (0),
582 mutualFlag (1),
583 replayFlag (2),
584 sequenceFlag (3),
585 anonFlag (4),
586 confFlag (5),
587 integFlag (6)
588 }
590 This is the syntax for the inner token of the initial negotiation
591 message.
593 mechTypes
595 This field contains one or more security mechanisms available
596 for the initiator in decreasing preference order (favorite
597 choice first).
599 reqFlags
601 This field, if present, contains the service options that are
602 requested to establish the context. The context flags SHOULD
603 be filled in from the req_flags parameter of
604 GSS_Init_sec_context(). This field SHALL NOT have impact on
605 the negotiation.
607 mechToken
609 This field, if present, contains the optimistic mechanism
610 token.
615 Zhu, et al. Expires June 15, 2005 [Page 11]
616 \f
617 Internet-Draft GSS-API Negotiation Mechanism December 2004
620 mechlistMIC
622 This field, if present, contains a MIC token for the mechanism
623 list in the initial negotiation message. This MIC token is
624 computed according to Section 5.
627 4.2.2 negTokenResp
629 NegTokenResp ::= SEQUENCE {
630 negState [0] ENUMERATED {
631 accept_completed (0),
632 accept_incomplete (1),
633 reject (2),
634 request_mic (3)
635 } OPTIONAL,
636 -- REQUIRED in the first reply from the target
637 supportedMech [1] MechType OPTIONAL,
638 -- present only in the first reply from the target
639 responseToken [2] OCTET STRING OPTIONAL,
640 mechListMIC [3] OCTET STRING OPTIONAL,
641 ...
642 }
644 This is the syntax for all subsequent negotiation messages.
646 negState
648 This field, if present, contains the state of the negotiation.
649 This can be:
651 accept_completed
653 No further negotiation message from the peer is expected,
654 and the security context is established for the sender.
656 accept_incomplete
658 At least one more negotiation message from the peer is
659 needed to establish the security context.
661 reject
663 The sender terminates the negotiation.
671 Zhu, et al. Expires June 15, 2005 [Page 12]
672 \f
673 Internet-Draft GSS-API Negotiation Mechanism December 2004
676 request_mic
678 The sender indicates that the exchange of MIC tokens, as
679 described in Section 5, will be REQUIRED if per-message
680 integrity services are available on the mechanism context to
681 be established. This value SHALL only be present in the
682 first reply from the target.
684 This field is REQUIRED in the first reply from the target, and
685 it is OPTIONAL thereafter. When negState is absent the actual
686 state should be inferred from the state of the negotiated
687 mechanism context.
689 supportedMech
691 This field SHALL only be present in the first reply from the
692 target. It MUST be one of the mechanism(s) offered by the
693 initiator.
695 ResponseToken
697 This field, if present, contains tokens specific to the
698 mechanism selected.
700 mechlistMIC
702 This field, if present, contains a MIC token for the mechanism
703 list in the initial negotiation message. This MIC token is
704 computed according to Section 5.
727 Zhu, et al. Expires June 15, 2005 [Page 13]
728 \f
729 Internet-Draft GSS-API Negotiation Mechanism December 2004
732 5. Processing of mechListMIC
734 If the mechanism selected by the negotiation does not support
735 integrity protection, then no mechlistMIC token is used.
737 Otherwise, if the accepted mechanism is the most preferred mechanism
738 of both the initiator and the acceptor, then the MIC token exchange,
739 as described later in this section, is OPTIONAL. A mechanism is the
740 acceptor's most preferred mechanism if there is no other mechanism
741 which, had it been present in the mechanism list, the acceptor would
742 have preferred over the accepted mechanism.
744 In all other cases, MIC tokens MUST be exchanged after the mechanism
745 context is fully established.
747 a) The mechlistMIC token (or simply the MIC token) is computed over
748 the mechanism list in the initial negotiation message by invoking
749 GSS_GetMIC() as follows: the input context_handle is the
750 established mechanism context, the input qop_req is 0, and the
751 input message is the DER encoding of the value of type
752 MechTypeList which is contained in the "mechTypes" field of the
753 NegTokenInit. The input message is NOT the DER encoding of the
754 type "[0] MechTypeList".
756 b) If the selected mechanism exchanges an even number of mechanism
757 tokens (i.e., the acceptor sends the last mechanism token), the
758 acceptor does the following when emitting the negotiation message
759 containing the last mechanism token: if the MIC token exchange is
760 optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE
761 and does not include a mechlistMIC token, or indicates
762 GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an
763 accept_incomplete state; if the MIC token exchange is required,
764 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and
765 includes a mechlistMIC token. Acceptors that wish to be
766 compatible with legacy Windows SPNEGO implementations as described
767 in Appendix B should not generate a mechlistMIC token when the MIC
768 token exchange is not required. The initiator then processes the
769 last mechanism token, and does 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
775 mechlistMIC token.
783 Zhu, et al. Expires June 15, 2005 [Page 14]
784 \f
785 Internet-Draft GSS-API Negotiation Mechanism December 2004
788 (II) If a mechlistMIC token was included but is incorrect, the
789 negotiation SHALL be terminated. GSS_Init_sec_context()
790 indicates GSS_S_DEFECTIVE_TOKEN.
792 (III) If no mechlistMIC token was included, and the MIC token
793 exchange is not required, GSS_Init_sec_context() indicates
794 GSS_S_COMPLETE with no output token.
796 (IV) If no mechlistMIC token was included, but the MIC token
797 exchange is required, the negotiation SHALL be terminated.
798 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
800 c) In the case that the chosen mechanism exchanges an odd number of
801 mechanism tokens (i.e., the initiator sends the last mechanism
802 token), the initiator does the following when emitting the
803 negotiation message containing the last mechanism token: if the
804 negState was request_mic in the first reply from the target, a
805 mechlistMIC token MUST be included, otherwise the mechlistMIC
806 token is OPTIONAL. (Note that the MIC token exchange is required
807 if a mechanism other than the initiator's first choice is chosen.)
808 In the case that the optimistic mechanism token is the only
809 mechanism token for the initiator's preferred mechanism, the
810 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC
811 token is included, GSS_Init_sec_context() indicates
812 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with
813 legacy Windows SPNEGO implementations as described in Appendix B
814 should not generate a mechlistMIC token when the MIC token
815 exchange is not required. The acceptor then processes the last
816 mechanism token and does one of the following:
818 (I) If a mechlistMIC token was included and is correctly verified,
819 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output
820 negotiation message contains a mechlistMIC token and an
821 accept_complete state. The initiator MUST then verify this
822 mechlistMIC token.
824 (II) If a mechlistMIC token was included but is incorrect, the
825 negotiation SHALL be terminated. GSS_Accept_sec_context()
826 indicates GSS_S_DEFECTIVE_TOKEN.
828 (III) If no mechlistMIC token was included but the mechlistMIC
829 token exchange is not required, GSS_Accept_sec_context()
830 indicates GSS_S_COMPLETE. The output negotiation message
831 contains an accept_complete state.
839 Zhu, et al. Expires June 15, 2005 [Page 15]
840 \f
841 Internet-Draft GSS-API Negotiation Mechanism December 2004
844 (IV) In the case that the optimistic mechanism token is also the
845 last mechanism token (when the initiator's preferred mechanism
846 is accepted by the target) and the target sends a request_mic
847 state but the initiator did not send a mechlistMIC token, the
848 target then MUST include a mechlistMIC token in that first
849 reply. GSS_Accept_sec_context() indicates
850 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received
851 mechlistMIC token and generate a mechlistMIC token to send back
852 to the target. The target SHALL in turn verify the returned
853 mechlistMIC token and complete the negotiation.
855 (V) If no mechlistMIC token was included and the acceptor sent a
856 request_mic state in the first reply message (the exchange of
857 MIC tokens is required), the negotiation SHALL be terminated.
858 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
895 Zhu, et al. Expires June 15, 2005 [Page 16]
896 \f
897 Internet-Draft GSS-API Negotiation Mechanism December 2004
900 6. Extensibility
902 Two mechanisms are provided for extensibility. First, the ASN.1
903 structures in this specification MAY be expanded by IETF standards
904 action. Implementations receiving unknown fields MUST ignore these
905 fields.
907 Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
908 mechanism variants) may be included in the set of preferred
909 mechanisms by an initiator. The acceptor can choose to honor this
910 request by preferring mechanisms that have the included attributes.
911 Future work within the Kitten working group is expected to
912 standardize common attributes that SPNEGO mechanisms may wish to
913 support. At this time it is sufficient to say that initiators MAY
914 include OIDs that do not correspond to mechanisms. Such OIDs MAY
915 influence the acceptor's choice of mechanism. As discussed in
916 Section 5, if there are mechanisms that if present in the initiator's
917 list of mechanisms might be preferred by the acceptor to the
918 initiator's preferred mechanism, the acceptor MUST demand the MIC
919 token exchange. As a consequence, acceptors MUST demand the MIC
920 token exchange if they support negotiation of attributes not
921 available in the initiator's preferred mechanism regardless of
922 whether the initiator actually requested these attributes.
951 Zhu, et al. Expires June 15, 2005 [Page 17]
952 \f
953 Internet-Draft GSS-API Negotiation Mechanism December 2004
956 7. Security Considerations
958 In order to produce the MIC token for the mechanism list, the
959 mechanism must provide integrity protection. When the selected
960 mechanism does not support integrity protection, the negotiation is
961 vulnerable: an active attacker can force it to use a security
962 mechanism that is not mutually preferred but is acceptable to the
963 target.
965 This protocol provides the following guarantees when per-message
966 integrity services are available on the established mechanism context
967 and the mechanism list was altered by an adversary such that a
968 mechanism which is not mutually preferred could be selected:
970 a) If the last mechanism token is sent by the initiator, both peers
971 shall fail;
972 b) If the last mechanism token is sent by the acceptor, the acceptor
973 shall not complete and the initiator at worst shall complete with
974 its preferred mechanism being selected.
976 The negotiation may not be terminated if an alteration was made but
977 it had no material impact.
979 The protection of the negotiation depends on the strength of the
980 integrity protection. In particular, the strength of SPNEGO is no
981 stronger than the integrity protection of the weakest mechanism
982 acceptable to GSS-API peers.
984 In all cases, the communicating peers are exposed to the denial of
985 service threat.
1007 Zhu, et al. Expires June 15, 2005 [Page 18]
1008 \f
1009 Internet-Draft GSS-API Negotiation Mechanism December 2004
1012 8. IANA Considerations
1014 This document has no actions for IANA.
1063 Zhu, et al. Expires June 15, 2005 [Page 19]
1064 \f
1065 Internet-Draft GSS-API Negotiation Mechanism December 2004
1068 9. Acknowledgments
1070 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
1071 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
1072 and suggestions during development of this document.
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
1079 document.
1119 Zhu, et al. Expires June 15, 2005 [Page 20]
1120 \f
1121 Internet-Draft GSS-API Negotiation Mechanism December 2004
1124 10. References
1126 10.1 Normative References
1128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1129 Requirement Levels", BCP 14, RFC 2119, March 1997.
1131 [RFC2743] Linn, J., "Generic Security Service Application Program
1132 Interface Version 2, Update 1", RFC 2743, January 2000.
1134 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1135 Rules (BER), Canonical Encoding Rules (CER) and
1136 Distinguished Encoding Rules (DER), ITU-T Recommendation
1137 X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
1139 10.2 Informative References
1141 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1142 Negotiation Mechanism", RFC 2478, December 1998.
1145 Authors' Addresses
1147 Larry Zhu
1148 Microsoft Corporation
1149 One Microsoft Way
1150 Redmond, WA 98052
1151 US
1153 EMail: lzhu@microsoft.com
1156 Paul Leach
1157 Microsoft Corporation
1158 One Microsoft Way
1159 Redmond, WA 98052
1160 US
1162 EMail: paulle@microsoft.com
1165 Karthik Jaganathan
1166 Microsoft Corporation
1167 One Microsoft Way
1168 Redmond, WA 98052
1169 US
1171 EMail: karthikj@microsoft.com
1176 Zhu, et al. Expires June 15, 2005 [Page 21]
1177 \f
1178 Internet-Draft GSS-API Negotiation Mechanism December 2004
1181 Wyllys Ingersoll
1182 Sun Microsystems
1183 1775 Wiehle Avenue, 2nd Floor
1184 Reston, VA 20190
1185 US
1187 EMail: wyllys.ingersoll@sun.com
1232 Zhu, et al. Expires June 15, 2005 [Page 22]
1233 \f
1234 Internet-Draft GSS-API Negotiation Mechanism December 2004
1237 Appendix A. GSS-API Negotiation Support API
1239 In order to provide to a GSS-API caller (either the initiator or the
1240 target or both) the ability to choose among the set of supported
1241 mechanisms a reduced set of mechanisms for negotiation, two
1242 additional APIs are defined:
1244 o GSS_Get_neg_mechs() indicates the set of security mechanisms
1245 available on the local system to the caller for negotiation, for
1246 which appropriate credentials are available.
1247 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be
1248 used on the local system by the caller for negotiation, for the
1249 given credentials.
1251 A.1 GSS_Set_neg_mechs call
1253 Inputs:
1255 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default
1256 -- credentials
1257 o mech_set SET OF OBJECT IDENTIFIER
1259 Outputs:
1261 o major_status INTEGER,
1262 o minor_status INTEGER
1264 Return major_status codes:
1266 o GSS_S_COMPLETE indicates that the set of security mechanisms
1267 available for negotiation has been set to mech_set.
1268 o GSS_S_FAILURE indicates that the requested operation could not be
1269 performed for reasons unspecified at the GSS-API level.
1271 Allows callers to specify the set of security mechanisms that may be
1272 negotiated with the credential identified by cred_handle. This call
1273 is intended for support of specialized callers who need to restrict
1274 the set of negotiable security mechanisms from the set of all
1275 security mechanisms available to the caller (based on available
1276 credentials). Note that if more than one mechanism is specified in
1277 mech_set, the order in which those mechanisms are specified implies a
1278 relative preference.
1280 A.2 GSS_Get_neg_mechs call
1282 Input:
1288 Zhu, et al. Expires June 15, 2005 [Page 23]
1289 \f
1290 Internet-Draft GSS-API Negotiation Mechanism December 2004
1293 o cred_handle CREDENTIAL HANDLE -- NULL specifies default
1294 -- credentials
1296 Outputs:
1298 o major_status INTEGER,
1299 o minor_status INTEGER,
1300 o mech_set SET OF OBJECT IDENTIFIER
1302 Return major_status codes:
1304 o GSS_S_COMPLETE indicates that the set of security mechanisms
1305 available for negotiation has been returned in mech_set.
1306 o GSS_S_FAILURE indicates that the requested operation could not be
1307 performed for reasons unspecified at the GSS-API level.
1309 Allows callers to determine the set of security mechanisms available
1310 for negotiation with the credential identified by cred_handle. This
1311 call is intended for support of specialized callers who need to
1312 reduce the set of negotiable security mechanisms from the set of
1313 supported security mechanisms available to the caller (based on
1314 available credentials).
1316 Note: The GSS_Indicate_mechs() function indicates the full set of
1317 mechanism types available on the local system. Since this call has
1318 no input parameter, the returned set is not necessarily available for
1319 all credentials.
1344 Zhu, et al. Expires June 15, 2005 [Page 24]
1345 \f
1346 Internet-Draft GSS-API Negotiation Mechanism December 2004
1349 Appendix B. Changes since RFC2478
1351 SPNEGO implementations in Windows 2000/Windows XP/Windows Server
1352 2003 have the following behavior: no mechlistMIC is produced and
1353 mechlistMIC is not processed if one is provided; if the initiator
1354 sends the last mechanism token, the acceptor will send back a
1355 negotiation token with an accept_complete state and no mechlistMIC
1356 token. In addition, an incorrect OID (1.2.840.48018.1.2.2) can be
1357 used to identify the GSS-API Kerberos Version 5 mechanism.
1359 The following changes have been made to be compatible with these
1360 legacy implementations.
1362 * NegTokenTarg is changed to negTokenResp and it is the message
1363 format for all subsequent negotiation tokens.
1364 * NegTokenInit is the message for the initial negotiation message
1365 and that message only.
1366 * mechTypes in negTokenInit is not optional.
1367 * If the selected mechanism is also the most preferred mechanism
1368 for both peers, it is safe to omit the MIC tokens.
1370 If at least one of the two peers implements the updated pseudo
1371 mechanism in this document, the negotiation is protected.
1373 The following changes are to address the problems in RFC 2478.
1375 * reqFlags is not protected therefore it should not impact the
1376 negotiation.
1377 * DER encoding is required.
1378 * GSS_GetMIC() input is clarified.
1379 * Per-message integrity services are requested for the negotiated
1380 mechanism.
1381 * Two MIC tokens are exchanged, one in each direction.
1383 An implementation that conforms to this specification will not
1384 interoperate with a strict 2748 implementation. Even if the new
1385 implementation always sends a mechlistMIC token, it will still fail
1386 to interoperate. If it is a server, it will fail because it requests
1387 a mechlistMIC token using an option that older implementations simply
1388 do not support. Clients will tend to fail as well.
1390 As an alternative to the approach chosen in this specification, we
1391 could have documented a correct behavior that is fully backward
1392 compatible with RFC 2478 and included an appendix on how to
1393 interoperate with existing incorrect implementations of RFC 2478.
1395 As a practical matter, the SPNEGO implementers within the IETF have
1396 valued interoperability with the Microsoft implementations. We were
1400 Zhu, et al. Expires June 15, 2005 [Page 25]
1401 \f
1402 Internet-Draft GSS-API Negotiation Mechanism December 2004
1405 unable to choose to maintain reasonable security guarantees, maintain
1406 interoperability with the Microsoft implementations and maintain
1407 interoperability with correct implementations of RFC 2478. The
1408 working group was not aware of any RFC 2478 implementations deployed
1409 on the Internet. Even if there are such implementations, it is
1410 unlikely that they will interoperate because of a critical flaw in
1411 the description of the encoding of the mechanism list in RFC 2478.
1413 With the approach taken in this specification, security is ensured
1414 between new implementations all the time while maintaining
1415 interoperability with the implementations deployed within the IETF
1416 community. The working group believes that this justifies breaking
1417 compatibility with a correct implementation of RFC 2478.
1456 Zhu, et al. Expires June 15, 2005 [Page 26]
1457 \f
1458 Internet-Draft GSS-API Negotiation Mechanism December 2004
1461 Appendix C. mechListMIC Computation Example
1463 The following is an example to illustrate how the mechListMIC field
1464 would be computed.
1466 The initial part of the DER encoding of NegTokenInit is constructed
1467 as follows (the "nn" are length encodings, possibly longer than one
1468 octet):
1470 30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
1471 nn -- length
1473 -- contents octets of the SEQUENCE begin with
1474 -- DER encoding of "[0] MechTypeList":
1475 A0 -- identifier octet for constructed [0]
1476 nn -- length
1478 -- contents of the constructed [0] are DER encoding
1479 -- of MechTypeList (which is a SEQUENCE):
1480 30 -- identifier octet for constructed SEQUENCE
1481 nn -- length
1483 -- contents octets of the SEQUENCE begin with
1484 -- DER encoding of OBJECT IDENTIFIER:
1485 06 -- identifier octet for primitive OBJECT IDENTIFIER
1486 09 -- length
1487 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
1488 -- {1 2 840 113554 1 2 2}
1490 If a mechlistMIC needs to be generated (according to the rules in
1491 Section 5), it is computed by using the DER encoding of the type
1492 MechTypeList data from the initiator's NegTokenInit token as input to
1493 the GSS_GetMIC() function. In this case, the MIC would be computed
1494 over the following octets:
1496 DER encoding of MechTypeList:
1497 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
1499 Note that the identifier octet and lengh octet(s) for constructed [0]
1500 (A0 nn) are not included in the MIC computation.
1512 Zhu, et al. Expires June 15, 2005 [Page 27]
1513 \f
1514 Internet-Draft GSS-API Negotiation Mechanism December 2004
1517 Intellectual Property Statement
1519 The IETF takes no position regarding the validity or scope of any
1520 Intellectual Property Rights or other rights that might be claimed to
1521 pertain to the implementation or use of the technology described in
1522 this document or the extent to which any license under such rights
1523 might or might not be available; nor does it represent that it has
1524 made any independent effort to identify any such rights. Information
1525 on the procedures with respect to rights in RFC documents can be
1526 found in BCP 78 and BCP 79.
1528 Copies of IPR disclosures made to the IETF Secretariat and any
1529 assurances of licenses to be made available, or the result of an
1530 attempt made to obtain a general license or permission for the use of
1531 such proprietary rights by implementers or users of this
1532 specification can be obtained from the IETF on-line IPR repository at
1533 http://www.ietf.org/ipr.
1535 The IETF invites any interested party to bring to its attention any
1536 copyrights, patents or patent applications, or other proprietary
1537 rights that may cover technology that may be required to implement
1538 this standard. Please address the information to the IETF at
1539 ietf-ipr@ietf.org.
1542 Disclaimer of Validity
1544 This document and the information contained herein are provided on an
1545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1547 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1548 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1549 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1553 Copyright Statement
1555 Copyright (C) The Internet Society (2004). This document is subject
1556 to the rights, licenses and restrictions contained in BCP 78, and
1557 except as set forth therein, the authors retain all their rights.
1560 Acknowledgment
1562 Funding for the RFC Editor function is currently provided by the
1563 Internet Society.
1568 Zhu, et al. Expires June 15, 2005 [Page 28]
1569 \f