1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                                  P. Leach
5Obsoletes: 2478 (if approved)                              K. Jaganathan
6Expires: July 27, 2005                             Microsoft Corporation
7                                                            W. Ingersoll
8                                                        Sun Microsystems
9                                                        January 23, 2005
10
11
12         The Simple and Protected GSS-API Negotiation Mechanism
13                      draft-ietf-kitten-2478bis-05
14
15Status of this Memo
16
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.
23
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.
28
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."
33
34   The list of current Internet-Drafts can be accessed at
35   http://www.ietf.org/ietf/1id-abstracts.txt.
36
37   The list of Internet-Draft Shadow Directories can be accessed at
38   http://www.ietf.org/shadow.html.
39
40   This Internet-Draft will expire on July 27, 2005.
41
42Copyright Notice
43
44   Copyright (C) The Internet Society (2005).
45
46Abstract
47
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.
51
52
53
54Zhu, et al.               Expires July 27, 2005                 [Page 1]
55
56Internet-Draft        GSS-API Negotiation Mechanism         January 2005
57
58
59   GSS-API peers can use this negotiation mechanism to choose from a
60   common set of security mechanisms.
61
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
65   peers.
66
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
70   Internet.
71
72Table of Contents
73
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
100
101
102
103
104
105
106
107
108
109
110Zhu, et al.               Expires July 27, 2005                 [Page 2]
111
112Internet-Draft        GSS-API Negotiation Mechanism         January 2005
113
114
1151.  Introduction
116
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
123   mechanism.
124
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
132   between the peers.
133
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.
141
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.
147
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.
159
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
163
164
165
166Zhu, et al.               Expires July 27, 2005                 [Page 3]
167
168Internet-Draft        GSS-API Negotiation Mechanism         January 2005
169
170
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.
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222Zhu, et al.               Expires July 27, 2005                 [Page 4]
223
224Internet-Draft        GSS-API Negotiation Mechanism         January 2005
225
226
2272.  Conventions Used in This Document
228
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].
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278Zhu, et al.               Expires July 27, 2005                 [Page 5]
279
280Internet-Draft        GSS-API Negotiation Mechanism         January 2005
281
282
2833.  Negotiation Protocol
284
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.
289
290   When the established mechanism context supports per-message integrity
291   services, SPNEGO guarantees that the selected mechanism is mutually
292   preferred.
293
294   This section describes the negotiation process of this protocol.
295
2963.1  Negotiation Description
297
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
304   credentials.)
305
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
319   available.
320
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.
327
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.
331
332
333
334Zhu, et al.               Expires July 27, 2005                 [Page 6]
335
336Internet-Draft        GSS-API Negotiation Mechanism         January 2005
337
338
339   In case of an unsuccessful negotiation, the reject state is returned
340   and generating a context level negotiation token is OPTIONAL.
341
342   Once a mechanism has been selected, context establishment tokens
343   specific to the selected mechanism are carried within the negotiation
344   tokens.
345
346   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
347   mechanism list received by the target.
348
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.
355
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.
367
3683.2  Negotiation Procedure
369
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:
373
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.
377
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.
383
384
385
386
387
388
389
390Zhu, et al.               Expires July 27, 2005                 [Page 7]
391
392Internet-Draft        GSS-API Negotiation Mechanism         January 2005
393
394
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
398      the following:
399
400
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.
405
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
412            request-mic state.
413
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
418            state.
419
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
424            state.
425
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
432      in the first reply.
433
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.
442
443
444
445
446Zhu, et al.               Expires July 27, 2005                 [Page 8]
447
448Internet-Draft        GSS-API Negotiation Mechanism         January 2005
449
450
451   (e) MIC tokens are then either skipped or exchanged according to
452      Section 5.
453
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.
458
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.
463
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.
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502Zhu, et al.               Expires July 27, 2005                 [Page 9]
503
504Internet-Draft        GSS-API Negotiation Mechanism         January 2005
505
506
5074.  Token Definitions
508
509   The type definitions in this section assume an ASN.1 module
510   definition of the following form:
511
512
513       SPNEGOASNOneSpec {
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
517
518       -- rest of definitions here
519
520       END
521
522
523   This specifies that the tagging context for the module will be
524   explicit and non-automatic.
525
526   The encoding of SPNEGO protocol messages shall obey the Distinguished
527   Encoding Rules (DER) of ASN.1 as described in [X690].
528
5294.1  Mechanism Types
530
531   In this negotiation model, each OID represents one GSS-API mechanism
532   or one variant (see Section 6) of it according to [RFC2743].
533
534
535       MechType ::= OBJECT IDENTIFIER
536           -- OID represents each security mechanism as suggested by
537           -- [RFC2743]
538
539       MechTypeList ::= SEQUENCE OF MechType
540
541
5424.2  Negotiation Tokens
543
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
549   token framing.
550
551   This section specifies the syntax of the inner token for the initial
552   message and the syntax of subsequent context establishment tokens.
553
554
555
556
557
558Zhu, et al.               Expires July 27, 2005                [Page 10]
559
560Internet-Draft        GSS-API Negotiation Mechanism         January 2005
561
562
563       NegotiationToken ::= CHOICE {
564           negTokenInit    [0] NegTokenInit,
565           negTokenResp    [1] NegTokenResp
566       }
567
568
569
5704.2.1  negTokenInit
571
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,
579           ...
580       }
581       ContextFlags ::= BIT STRING {
582           delegFlag       (0),
583           mutualFlag      (1),
584           replayFlag      (2),
585           sequenceFlag    (3),
586           anonFlag        (4),
587           confFlag        (5),
588           integFlag       (6)
589       } (SIZE (32))
590
591   This is the syntax for the inner token of the initial negotiation
592   message.
593
594   mechTypes
595
596         This field contains one or more security mechanisms available
597         for the initiator in decreasing preference order (favorite
598         choice first).
599
600   reqFlags
601
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.
608
609
610
611
612
613
614Zhu, et al.               Expires July 27, 2005                [Page 11]
615
616Internet-Draft        GSS-API Negotiation Mechanism         January 2005
617
618
619   mechToken
620
621         This field, if present, contains the optimistic mechanism
622         token.
623
624   mechlistMIC
625
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.
629
630
6314.2.2  negTokenResp
632
633       NegTokenResp ::= SEQUENCE {
634           negState       [0] ENUMERATED {
635               accept-completed    (0),
636               accept-incomplete   (1),
637               reject              (2),
638               request-mic         (3)
639           }                                 OPTIONAL,
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,
645           ...
646       }
647
648   This is the syntax for all subsequent negotiation messages.
649
650   negState
651
652         This field, if present, contains the state of the negotiation.
653         This can be:
654
655         accept-completed
656
657            No further negotiation message from the peer is expected,
658            and the security context is established for the sender.
659
660         accept-incomplete
661
662            At least one more negotiation message from the peer is
663            needed to establish the security context.
664
665
666
667
668
669
670Zhu, et al.               Expires July 27, 2005                [Page 12]
671
672Internet-Draft        GSS-API Negotiation Mechanism         January 2005
673
674
675         reject
676
677            The sender terminates the negotiation.
678
679         request-mic
680
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.
686
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
690         mechanism context.
691
692   supportedMech
693
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
696         initiator.
697
698   ResponseToken
699
700         This field, if present, contains tokens specific to the
701         mechanism selected.
702
703   mechlistMIC
704
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.
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726Zhu, et al.               Expires July 27, 2005                [Page 13]
727
728Internet-Draft        GSS-API Negotiation Mechanism         January 2005
729
730
7315.  Processing of mechListMIC
732
733   If the mechanism selected by the negotiation does not support
734   integrity protection, then no mechlistMIC token is used.
735
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.
742
743   In all other cases, MIC tokens MUST be exchanged after the mechanism
744   context is fully established.
745
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".
754
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:
770
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.
776
777
778
779
780
781
782Zhu, et al.               Expires July 27, 2005                [Page 14]
783
784Internet-Draft        GSS-API Negotiation Mechanism         January 2005
785
786
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.
790
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.
794
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.
798
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:
816
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
821         mechlistMIC token.
822
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.
826
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.
831
832
833
834
835
836
837
838Zhu, et al.               Expires July 27, 2005                [Page 15]
839
840Internet-Draft        GSS-API Negotiation Mechanism         January 2005
841
842
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.
853
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.
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894Zhu, et al.               Expires July 27, 2005                [Page 16]
895
896Internet-Draft        GSS-API Negotiation Mechanism         January 2005
897
898
8996.  Extensibility
900
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
904   fields.
905
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.
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950Zhu, et al.               Expires July 27, 2005                [Page 17]
951
952Internet-Draft        GSS-API Negotiation Mechanism         January 2005
953
954
9557.  Security Considerations
956
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
962   target.
963
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:
968
969   a) If the last mechanism token is sent by the initiator, both peers
970      shall fail;
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.
974
975   The negotiation may not be terminated if an alteration was made but
976   it had no material impact.
977
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.
982
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
993   attacks.
994
995   In all cases, the communicating peers are exposed to the denial of
996   service threat.
997
998
999
1000
1001
1002
1003
1004
1005
1006Zhu, et al.               Expires July 27, 2005                [Page 18]
1007
1008Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1009
1010
10118.  IANA Considerations
1012
1013   This document has no actions for IANA.
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062Zhu, et al.               Expires July 27, 2005                [Page 19]
1063
1064Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1065
1066
10679.  Acknowledgments
1068
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
1072   this document.
1073
1074   Luke Howard provided a prototype of this protocol in Heimdal and
1075   resolved several issues in the initial draft.
1076
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.
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118Zhu, et al.               Expires July 27, 2005                [Page 20]
1119
1120Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1121
1122
112310.  References
1124
112510.1  Normative References
1126
1127   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1128              Requirement Levels", BCP 14, RFC 2119, March 1997.
1129
1130   [RFC2743]  Linn, J., "Generic Security Service Application Program
1131              Interface Version 2, Update 1", RFC 2743, January 2000.
1132
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.
1137
113810.2  Informative References
1139
1140   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1141              Negotiation Mechanism", RFC 2478, December 1998.
1142
1143
1144Authors' Addresses
1145
1146   Larry Zhu
1147   Microsoft Corporation
1148   One Microsoft Way
1149   Redmond, WA  98052
1150   US
1151
1152   Email: lzhu@microsoft.com
1153
1154
1155   Paul Leach
1156   Microsoft Corporation
1157   One Microsoft Way
1158   Redmond, WA  98052
1159   US
1160
1161   Email: paulle@microsoft.com
1162
1163
1164   Karthik Jaganathan
1165   Microsoft Corporation
1166   One Microsoft Way
1167   Redmond, WA  98052
1168   US
1169
1170   Email: karthikj@microsoft.com
1171
1172
1173
1174
1175Zhu, et al.               Expires July 27, 2005                [Page 21]
1176
1177Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1178
1179
1180   Wyllys Ingersoll
1181   Sun Microsystems
1182   1775 Wiehle Avenue, 2nd Floor
1183   Reston, VA  20190
1184   US
1185
1186   Email: wyllys.ingersoll@sun.com
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231Zhu, et al.               Expires July 27, 2005                [Page 22]
1232
1233Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1234
1235
1236Appendix A.  SPNEGO ASN.1 Module
1237
1238       SPNEGOASNOneSpec {
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
1242
1243       MechType ::= OBJECT IDENTIFIER
1244           -- OID represents each security mechanism as suggested by
1245           -- [RFC2743]
1246
1247       MechTypeList ::= SEQUENCE OF MechType
1248
1249       NegotiationToken ::= CHOICE {
1250           negTokenInit    [0] NegTokenInit,
1251           negTokenResp    [1] NegTokenResp
1252       }
1253
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,
1261           ...
1262       }
1263       NegTokenResp ::= SEQUENCE {
1264           negState       [0] ENUMERATED {
1265               accept-completed    (0),
1266               accept-incomplete   (1),
1267               reject              (2),
1268               request-mic         (3)
1269           }                                 OPTIONAL,
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,
1275           ...
1276       }
1277
1278       ContextFlags ::= BIT STRING {
1279           delegFlag       (0),
1280           mutualFlag      (1),
1281           replayFlag      (2),
1282           sequenceFlag    (3),
1283           anonFlag        (4),
1284
1285
1286
1287Zhu, et al.               Expires July 27, 2005                [Page 23]
1288
1289Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1290
1291
1292           confFlag        (5),
1293           integFlag       (6)
1294       } (SIZE (32))
1295
1296       END
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343Zhu, et al.               Expires July 27, 2005                [Page 24]
1344
1345Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1346
1347
1348Appendix B.  GSS-API Negotiation Support API
1349
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:
1354
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
1360      given credentials.
1361
1362B.1  GSS_Set_neg_mechs call
1363
1364   Inputs:
1365
1366   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
1367      -- credentials
1368   o  mech_set SET OF OBJECT IDENTIFIER
1369
1370   Outputs:
1371
1372   o  major_status INTEGER,
1373   o  minor_status INTEGER
1374
1375   Return major_status codes:
1376
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.
1381
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.
1390
1391B.2  GSS_Get_neg_mechs call
1392
1393   Input:
1394
1395
1396
1397
1398
1399Zhu, et al.               Expires July 27, 2005                [Page 25]
1400
1401Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1402
1403
1404   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
1405      -- credentials
1406
1407   Outputs:
1408
1409   o  major_status INTEGER,
1410   o  minor_status INTEGER,
1411   o  mech_set SET OF OBJECT IDENTIFIER
1412
1413   Return major_status codes:
1414
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.
1419
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).
1426
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
1430   all credentials.
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455Zhu, et al.               Expires July 27, 2005                [Page 26]
1456
1457Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1458
1459
1460Appendix C.  Changes since RFC2478
1461
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.
1470
1471      The following changes have been made to be compatible with these
1472      legacy implementations.
1473
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.
1481
1482      If at least one of the two peers implements the updated pseudo
1483      mechanism in this document, the negotiation is protected.
1484
1485      The following changes are to address problems in RFC 2478.
1486
1487      *  reqFlags is not protected therefore it should not impact the
1488         negotiation.
1489      *  DER encoding is required.
1490      *  GSS_GetMIC() input is clarified.
1491      *  Per-message integrity services are requested for the negotiated
1492         mechanism.
1493      *  Two MIC tokens are exchanged, one in each direction.
1494
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
1501   well.
1502
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.
1507
1508
1509
1510
1511Zhu, et al.               Expires July 27, 2005                [Page 27]
1512
1513Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1514
1515
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.
1525
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.
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567Zhu, et al.               Expires July 27, 2005                [Page 28]
1568
1569Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1570
1571
1572Appendix D.  mechListMIC Computation Example
1573
1574   The following is an example to illustrate how the mechListMIC field
1575   would be computed.
1576
1577   The initial part of the DER encoding of NegTokenInit is constructed
1578   as follows (the "nn" are length encodings, possibly longer than one
1579   octet):
1580
1581      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
1582      nn -- length
1583
1584         -- contents octets of the SEQUENCE begin with
1585         -- DER encoding of "[0] MechTypeList":
1586         A0 -- identifier octet for constructed [0]
1587         nn -- length
1588
1589             -- contents of the constructed [0] are DER encoding
1590             -- of MechTypeList (which is a SEQUENCE):
1591             30 -- identifier octet for constructed SEQUENCE
1592             nn -- length
1593
1594                -- contents octets of the SEQUENCE begin with
1595                -- DER encoding of OBJECT IDENTIFIER:
1596                06 -- identifier octet for primitive OBJECT IDENTIFIER
1597                09 -- length
1598                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
1599                                           -- {1 2 840 113554 1 2 2}
1600
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:
1606
1607      DER encoding of MechTypeList:
1608      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
1609
1610   Note that the identifier octet and length octet(s) for constructed
1611   [0] (A0 nn) are not included in the MIC computation.
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623Zhu, et al.               Expires July 27, 2005                [Page 29]
1624
1625Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1626
1627
1628Intellectual Property Statement
1629
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.
1638
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.
1645
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
1650   ietf-ipr@ietf.org.
1651
1652
1653Disclaimer of Validity
1654
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.
1662
1663
1664Copyright Statement
1665
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.
1669
1670
1671Acknowledgment
1672
1673   Funding for the RFC Editor function is currently provided by the
1674   Internet Society.
1675
1676
1677
1678
1679Zhu, et al.               Expires July 27, 2005                [Page 30]
1680
1681