1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                                  P. Leach
5Obsoletes: 2478 (if approved)                              K. Jaganathan
6Expires: June 15, 2005                             Microsoft Corporation
7                                                            W. Ingersoll
8                                                        Sun Microsystems
9                                                       December 15, 2004
10
11
12         The Simple and Protected GSS-API Negotiation Mechanism
13                      draft-ietf-kitten-2478bis-04
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 June 15, 2005.
41
42Copyright Notice
43
44   Copyright (C) The Internet Society (2004).
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
54
55Zhu, et al.              Expires June 15, 2005                  [Page 1]
56
57Internet-Draft       GSS-API Negotiation Mechanism         December 2004
58
59
60   GSS-API peers can use this negotiation mechanism to choose from a
61   common set of security mechanisms.
62
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.
67
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.
72
73Table of Contents
74
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
100
101
102
103
104
105
106
107
108
109
110
111Zhu, et al.              Expires June 15, 2005                  [Page 2]
112
113Internet-Draft       GSS-API Negotiation Mechanism         December 2004
114
115
1161.  Introduction
117
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.
125
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.
135
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.
143
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.
149
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.
161
162   In order to avoid an extra round trip, the first context
163   establishment token of the initiator's preferred mechanism SHOULD be
164
165
166
167Zhu, et al.              Expires June 15, 2005                  [Page 3]
168
169Internet-Draft       GSS-API Negotiation Mechanism         December 2004
170
171
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.
181
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.
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
222
223Zhu, et al.              Expires June 15, 2005                  [Page 4]
224
225Internet-Draft       GSS-API Negotiation Mechanism         December 2004
226
227
2282.  Conventions Used in This Document
229
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].
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
278
279Zhu, et al.              Expires June 15, 2005                  [Page 5]
280
281Internet-Draft       GSS-API Negotiation Mechanism         December 2004
282
283
2843.  Negotiation Protocol
285
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.
290
291   When the established mechanism context supports per-message integrity
292   services, SPNEGO guarantees that the selected mechanism is mutually
293   preferred.
294
295   This section describes the negotiation process of this protocol.
296
2973.1  Negotiation Description
298
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.)
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 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.
319
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.
326
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.
330
331   In case of an unsuccessful negotiation, the reject state is returned
332
333
334
335Zhu, et al.              Expires June 15, 2005                  [Page 6]
336
337Internet-Draft       GSS-API Negotiation Mechanism         December 2004
338
339
340   and it is OPTIONAL to emit a context level negotiation token.
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
3563.2  Negotiation Procedure
357
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:
361
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.
365
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.
371
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:
376
377
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.
382
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.
388
389
390
391Zhu, et al.              Expires June 15, 2005                  [Page 7]
392
393Internet-Draft       GSS-API Negotiation Mechanism         December 2004
394
395
396            The acceptor MUST output a negotiation token containing a
397            request_mic state.
398
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.
404
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.
410
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.
418
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.
428
429   (e) MIC tokens are then either skipped or exchanged according to
430      Section 5.
431
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.
436
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.
441
442   When a GSS-API credential is acquired for the SPNEGO mechanism the
443   implementation SHOULD produce a credential element for the SPNEGO
444
445
446
447Zhu, et al.              Expires June 15, 2005                  [Page 8]
448
449Internet-Draft       GSS-API Negotiation Mechanism         December 2004
450
451
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.
457
458
459
460
461
462
463
464
465
466
467
468
469
470
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
502
503Zhu, et al.              Expires June 15, 2005                  [Page 9]
504
505Internet-Draft       GSS-API Negotiation Mechanism         December 2004
506
507
5084.  Token Definitions
509
510   The type definitions in this section assume an ASN.1 module
511   definition of the following form:
512
513
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
518
519      -- rest of definitions here
520
521      END
522
523
524   This specifies that the tagging context for the module will be
525   explicit and non-automatic.
526
527   The encoding of SPNEGO protocol messages shall obey the Distinguished
528   Encoding Rules (DER) of ASN.1 as described in [X690].
529
5304.1  Mechanism Types
531
532   In this negotiation model, each OID represents one GSS-API mechanism
533   or one variant (see Section 6) of it according to [RFC2743].
534
535
536       MechType ::= OBJECT IDENTIFIER
537           -- OID represents each security mechanism as suggested by
538           -- [RFC2743]
539
540       MechTypeList ::= SEQUENCE OF MechType
541
542
5434.2  Negotiation Tokens
544
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.
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       NegotiationToken ::= CHOICE {
555           negTokenInit    [0] NegTokenInit,
556
557
558
559Zhu, et al.              Expires June 15, 2005                 [Page 10]
560
561Internet-Draft       GSS-API Negotiation Mechanism         December 2004
562
563
564           negTokenResp    [1] negTokenResp
565       }
566
567
568
5694.2.1  negTokenInit
570
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       }
589
590   This is the syntax for the inner token of the initial negotiation
591   message.
592
593   mechTypes
594
595         This field contains one or more security mechanisms available
596         for the initiator in decreasing preference order (favorite
597         choice first).
598
599   reqFlags
600
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.
606
607   mechToken
608
609         This field, if present, contains the optimistic mechanism
610         token.
611
612
613
614
615Zhu, et al.              Expires June 15, 2005                 [Page 11]
616
617Internet-Draft       GSS-API Negotiation Mechanism         December 2004
618
619
620   mechlistMIC
621
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.
625
626
6274.2.2  negTokenResp
628
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       }
643
644   This is the syntax for all subsequent negotiation messages.
645
646   negState
647
648         This field, if present, contains the state of the negotiation.
649         This can be:
650
651         accept_completed
652
653            No further negotiation message from the peer is expected,
654            and the security context is established for the sender.
655
656         accept_incomplete
657
658            At least one more negotiation message from the peer is
659            needed to establish the security context.
660
661         reject
662
663            The sender terminates the negotiation.
664
665
666
667
668
669
670
671Zhu, et al.              Expires June 15, 2005                 [Page 12]
672
673Internet-Draft       GSS-API Negotiation Mechanism         December 2004
674
675
676         request_mic
677
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.
683
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.
688
689   supportedMech
690
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.
694
695   ResponseToken
696
697         This field, if present, contains tokens specific to the
698         mechanism selected.
699
700   mechlistMIC
701
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.
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727Zhu, et al.              Expires June 15, 2005                 [Page 13]
728
729Internet-Draft       GSS-API Negotiation Mechanism         December 2004
730
731
7325.  Processing of mechListMIC
733
734   If the mechanism selected by the negotiation does not support
735   integrity protection, then no mechlistMIC token is used.
736
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.
743
744   In all other cases, MIC tokens MUST be exchanged after the mechanism
745   context is fully established.
746
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".
755
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:
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
782
783Zhu, et al.              Expires June 15, 2005                 [Page 14]
784
785Internet-Draft       GSS-API Negotiation Mechanism         December 2004
786
787
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.
791
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.
795
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.
799
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:
817
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.
823
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.
827
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.
832
833
834
835
836
837
838
839Zhu, et al.              Expires June 15, 2005                 [Page 15]
840
841Internet-Draft       GSS-API Negotiation Mechanism         December 2004
842
843
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.
854
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.
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
894
895Zhu, et al.              Expires June 15, 2005                 [Page 16]
896
897Internet-Draft       GSS-API Negotiation Mechanism         December 2004
898
899
9006.  Extensibility
901
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.
906
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.
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
950
951Zhu, et al.              Expires June 15, 2005                 [Page 17]
952
953Internet-Draft       GSS-API Negotiation Mechanism         December 2004
954
955
9567.  Security Considerations
957
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.
964
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:
969
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.
975
976   The negotiation may not be terminated if an alteration was made but
977   it had no material impact.
978
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.
983
984   In all cases, the communicating peers are exposed to the denial of
985   service threat.
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007Zhu, et al.              Expires June 15, 2005                 [Page 18]
1008
1009Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1010
1011
10128.  IANA Considerations
1013
1014   This document has no actions for IANA.
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
1062
1063Zhu, et al.              Expires June 15, 2005                 [Page 19]
1064
1065Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1066
1067
10689.  Acknowledgments
1069
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.
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
1118
1119Zhu, et al.              Expires June 15, 2005                 [Page 20]
1120
1121Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1122
1123
112410.  References
1125
112610.1  Normative References
1127
1128   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1129              Requirement Levels", BCP 14, RFC 2119, March 1997.
1130
1131   [RFC2743]  Linn, J., "Generic Security Service Application Program
1132              Interface Version 2, Update 1", RFC 2743, January 2000.
1133
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.
1138
113910.2  Informative References
1140
1141   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1142              Negotiation Mechanism", RFC 2478, December 1998.
1143
1144
1145Authors' Addresses
1146
1147   Larry Zhu
1148   Microsoft Corporation
1149   One Microsoft Way
1150   Redmond, WA  98052
1151   US
1152
1153   EMail: lzhu@microsoft.com
1154
1155
1156   Paul Leach
1157   Microsoft Corporation
1158   One Microsoft Way
1159   Redmond, WA  98052
1160   US
1161
1162   EMail: paulle@microsoft.com
1163
1164
1165   Karthik Jaganathan
1166   Microsoft Corporation
1167   One Microsoft Way
1168   Redmond, WA  98052
1169   US
1170
1171   EMail: karthikj@microsoft.com
1172
1173
1174
1175
1176Zhu, et al.              Expires June 15, 2005                 [Page 21]
1177
1178Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1179
1180
1181   Wyllys Ingersoll
1182   Sun Microsystems
1183   1775 Wiehle Avenue, 2nd Floor
1184   Reston, VA  20190
1185   US
1186
1187   EMail: wyllys.ingersoll@sun.com
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
1231
1232Zhu, et al.              Expires June 15, 2005                 [Page 22]
1233
1234Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1235
1236
1237Appendix A.  GSS-API Negotiation Support API
1238
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:
1243
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.
1250
1251A.1  GSS_Set_neg_mechs call
1252
1253   Inputs:
1254
1255   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
1256      -- credentials
1257   o  mech_set SET OF OBJECT IDENTIFIER
1258
1259   Outputs:
1260
1261   o  major_status INTEGER,
1262   o  minor_status INTEGER
1263
1264   Return major_status codes:
1265
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.
1270
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.
1279
1280A.2  GSS_Get_neg_mechs call
1281
1282   Input:
1283
1284
1285
1286
1287
1288Zhu, et al.              Expires June 15, 2005                 [Page 23]
1289
1290Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1291
1292
1293   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
1294      -- credentials
1295
1296   Outputs:
1297
1298   o  major_status INTEGER,
1299   o  minor_status INTEGER,
1300   o  mech_set SET OF OBJECT IDENTIFIER
1301
1302   Return major_status codes:
1303
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.
1308
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).
1315
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.
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344Zhu, et al.              Expires June 15, 2005                 [Page 24]
1345
1346Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1347
1348
1349Appendix B.  Changes since RFC2478
1350
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.
1358
1359      The following changes have been made to be compatible with these
1360      legacy implementations.
1361
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.
1369
1370      If at least one of the two peers implements the updated pseudo
1371      mechanism in this document, the negotiation is protected.
1372
1373      The following changes are to address the problems in RFC 2478.
1374
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.
1382
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.
1389
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.
1394
1395   As a practical matter, the SPNEGO implementers within the IETF have
1396   valued interoperability with the Microsoft implementations.  We were
1397
1398
1399
1400Zhu, et al.              Expires June 15, 2005                 [Page 25]
1401
1402Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1403
1404
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.
1412
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.
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456Zhu, et al.              Expires June 15, 2005                 [Page 26]
1457
1458Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1459
1460
1461Appendix C.  mechListMIC Computation Example
1462
1463   The following is an example to illustrate how the mechListMIC field
1464   would be computed.
1465
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):
1469
1470      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
1471      nn -- length
1472
1473         -- contents octets of the SEQUENCE begin with
1474         -- DER encoding of "[0] MechTypeList":
1475         A0 -- identifier octet for constructed [0]
1476         nn -- length
1477
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
1482
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}
1489
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:
1495
1496      DER encoding of MechTypeList:
1497      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
1498
1499   Note that the identifier octet and lengh octet(s) for constructed [0]
1500   (A0 nn) are not included in the MIC computation.
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512Zhu, et al.              Expires June 15, 2005                 [Page 27]
1513
1514Internet-Draft       GSS-API Negotiation Mechanism         December 2004
1515
1516
1517Intellectual Property Statement
1518
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.
1527
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.
1534
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.
1540
1541
1542Disclaimer of Validity
1543
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.
1551
1552
1553Copyright Statement
1554
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.
1558
1559
1560Acknowledgment
1561
1562   Funding for the RFC Editor function is currently provided by the
1563   Internet Society.
1564
1565
1566
1567
1568Zhu, et al.              Expires June 15, 2005                 [Page 28]
1569
1570
1571