idnits 2.17.1 draft-ietf-kitten-2478bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 826. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 19) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC2478, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 776 has weird spacing: '...ication will ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1, 2004) is 7085 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 376 -- Looks like a reference, but probably isn't: '1' on line 383 -- Looks like a reference, but probably isn't: '2' on line 385 -- Looks like a reference, but probably isn't: '3' on line 386 ** Obsolete normative reference: RFC 2478 (Obsoleted by RFC 4178) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WORKING GROUP L. Zhu 2 Internet-Draft P. Leach 3 Obsoletes: 2478 (if approved) K. Jaganathan 4 Expires: June 1, 2005 Microsoft Corporation 5 W. Ingersoll 6 Sun Microsystems 7 December 1, 2004 9 The Simple and Protected GSS-API Negotiation Mechanism 10 draft-ietf-kitten-2478bis-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 1, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document specifies a negotiation mechanism for the Generic 46 Security Service Application Program Interface (GSS-API) which is 47 described in RFC 2743. 49 GSS-API peers can use this negotiation mechanism to choose from a 50 common set of security mechanisms. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 56 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6 58 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7 59 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 9 61 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 9 62 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 10 63 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 11 64 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13 65 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 19 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 71 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21 72 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21 73 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21 74 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23 75 Intellectual Property and Copyright Statements . . . . . . . . 25 77 1. Introduction 79 The GSS-API [RFC2743] provides a generic interface which can be 80 layered atop different security mechanisms such that if communicating 81 peers acquire GSS-API credentials for the same security mechanism, 82 then a security context may be established between them (subject to 83 policy). However, GSS-API does not prescribe the method by which 84 GSS-API peers can establish whether they have a common security 85 mechanism. 87 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 88 defined here is a pseudo security mechanism, represented by the 89 Object Identifier iso.org.dod.internet.security.mechanism.snego 90 (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band 91 whether their credentials share common GSS-API security mechanism(s), 92 and if so, to invoke normal security context establishment for a 93 selected common security mechanism. This is most useful for 94 applications which are based on GSS-API implementations and share 95 multiple mechanisms between the peers. 97 The SPNEGO mechanism negotiation is based on the following 98 negotiation model: the initiator proposes a list of security 99 mechanism(s), in decreasing preference order (favorite choice first), 100 the acceptor (also known as the target) either accepts the 101 initiator's preferred security mechanism (the first in the list), or 102 chooses one that is available from the offered list, or rejects the 103 proposed value(s). The target then informs the initiator of its 104 choice. 106 Once a common security mechanism is chosen, mechanism-specific 107 options MAY be negotiated as part of the selected mechanism's context 108 establishment. These negotiations (if any) are internal to the 109 mechanism and opaque to the SPNEGO protocol. As such they are 110 outside the scope of this document. 112 If per-message integrity services are available on the established 113 mechanism security context, then the peers can exchange MIC tokens to 114 ensure that the mechanism list was not tampered with. This MIC token 115 exchange is OPTIONAL if the selected mechanism is the most preferred 116 choice of both peers (see Section 5). 118 In order to avoid an extra round trip, the first security token of 119 the initiator's preferred mechanism SHOULD be embedded in the initial 120 negotiation message (as defined in Section 4.2). This mechanism 121 token is referred to as the optimistic mechanism token in this 122 document. If the selected mechanism matches the initiator's 123 preferred mechanism, no additional round trips need be incurred by 124 using this protocol. In addition, using the optimistic mechanism 125 token allows the initiator to recover from non-fatal errors while 126 producing the first mechanism token before a mechanism can be 127 selected. Implementations MAY omit the optimistic mechanism token to 128 avoid the cost of generating it in cases where the initiator's 129 preferred mechanism is not selected by the acceptor. 131 SPNEGO relies the concepts developed in the GSS-API specification 132 [RFC2743]. The negotiation data is encapsulated in context-level 133 tokens. Therefore, callers of the GSS-API do not need to be aware of 134 the existence of the negotiation tokens but only of the new 135 pseudo-security mechanism. A failure in the negotiation phase causes 136 a major status code to be returned: GSS_S_BAD_MECH. 138 2. Conventions Used in This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Negotiation Protocol 146 When the established mechanism context provides integrity protection, 147 the mechanism negotiation can be protected. When acquiring 148 negotiated security mechanism tokens, per-message integrity services 149 are always requested by the SPNEGO mechanism. 151 When the established mechanism context supports per-message integrity 152 services, SPNEGO guarantees that the selected mechanism is mutually 153 preferred. 155 This section describes the negotiation process of this protocol. 157 3.1 Negotiation Description 159 The first negotiation token sent by the initiator contains an ordered 160 list of mechanisms (in decreasing preference order, favorite 161 mechanism first), and optionally the initial mechanism token for the 162 preferred mechanism of the initiator (i.e., the first in the list). 163 The list of security mechanisms available for negotiation is based on 164 the credentials being used. 166 The target then processes the token from the initiator. This will 167 result in one of four possible states (as defined in Section 4.2.2): 168 accept_completed, accept_incomplete, reject, or request_mic. A 169 reject state will terminate the negotiation; an accept_completed 170 state indicates that not only was the initiator-selected mechanism 171 acceptable to the target, but also that the initial mechanism token 172 was sufficient to complete the authentication; an accept_incomplete 173 state indicates that further message exchange is needed but the MIC 174 token exchange as described in Section 5 is OPTIONAL; a request_mic 175 state (this state can only be present in the first reply message from 176 the target) indicates the MIC token exchange is REQUIRED if 177 per-message integrity services are available. 179 Unless the preference order is specified by the application (see 180 Appendix A), the policy by which the target chooses a mechanism is an 181 implementation-specific local matter. In the absence of an 182 application specified preference order or other policy, the target 183 SHALL choose the first mechanism in the initiator proposed list for 184 which it has valid credentials. 186 In case of a successful negotiation, the security mechanism in the 187 first reply message represents the value suitable for the target, 188 picked up from the list offered by the initiator. A context level 189 token for a reject state is OPTIONAL. 191 Once a mechanism has been selected, the tokens specific to the 192 selected mechanism are carried within the negotiation tokens. 194 Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the 195 mechanism list received by the target. 197 To avoid conflicts with the use of MIC tokens by SPNEGO, 198 partially-established contexts are not used for per-message calls: 199 the prot_ready_state [RFC2743] will be false even if the underlying 200 mechanism would return true natively. 202 3.2 Negotiation Procedure 204 The basic form of the procedure assumes that per-message integrity 205 services are available on the established mechanism context, and it 206 is summarized as follows: 208 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 209 but requests that SPNEGO be used. SPNEGO can either be explicity 210 requested or accepted as the default mechanism. 212 (b) The initiator GSS-API implementation emits a negotiation token 213 containing a list of one or more security mechanisms that are 214 available based on the credentials used for this context 215 establishment, and optionally the initial mechanism token for the 216 first mechanism in the list. 218 (c) The GSS-API initiator application sends the token to the target 219 application. The GSS-API target application deposits the token by 220 invoking GSS_Accept_sec_context(). The acceptor will do one of 221 the following: 223 (I) If none of the proposed mechanisms are acceptable, the 224 negotiation SHALL be terminated. GSS_Accept_sec_context 225 indicates GSS_S_BAD_MECH. The acceptor MAY output a 226 negotiation token containing a reject state. 228 (II) If either the initiator's preferred mechanism is not accepted 229 by the target or this mechanism is accepted but it is not the 230 acceptor's most preferred mechanism (see Section 3.1 and 231 Section 5), GSS_Accept_sec_context() indicates 232 GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation 233 token containing a request_mic state. 235 (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE 236 or GSS_S_CONTINUE_NEEDED depending on if at least one 237 additional negotiation token from the initiator is needed to 238 establish this context. The acceptor outputs a negotiation 239 token containing an accept_complete or accept_incomplete state, 240 respectively. 242 If the initiator's preferred mechanism is accepted, and an 243 optimistic mechanism token was included, this mechanism token MUST 244 be deposited to the selected mechanism by invoking 245 GSS_Accept_sec_context() and if a response mechanism token is 246 emitted, it MUST be included in the response negotiation token. 247 Otherwise, the target will not emit a response mechanism token in 248 the first reply. 250 (d) The GSS-API target application returns the negotiation token to 251 the initiator application. The GSS-API initiator application 252 deposits the token by invoking GSS_Init_sec_context(). The 253 security context initialization is then continued according to the 254 standard GSS-API conventions for the selected mechanism, where the 255 tokens of the selected mechanism are encapsulated until the 256 GSS_S_COMPLETE is returned for both the initiator and the target 257 by the selected security mechanism. 259 (e) MIC tokens are then either skipped or exchanged according to 260 Section 5. 262 Note that the *_req_flag input parameters for context establishment 263 are relative to the selected mechanism, as are the *_state output 264 parameters. i.e., these parameters are not applicable to the 265 negotiation process per se. 267 On receipt of a negotiation token on the target side, a GSS-API 268 implementation that does not support negotiation would indicate the 269 GSS_S_BAD_MECH status as if a particular basic security mechanism had 270 been requested and was not supported. 272 When GSS_Acquire_cred is invoked with this negotiation mechanism in 273 the desired_mechs, an implementation-specific default credential is 274 used to carry on the negotiation. A set of mechanisms as specified 275 locally by the system administrator is then available for 276 negotiation. If there is a desire for the caller to make its own 277 choice, then an additional API has to be used (see Appendix A). 279 4. Token Definitions 281 The type definitions in this section assume an ASN.1 module 282 definition of the following form: 284 SPNEGOASNOneSpec { 285 iso(1) identified-organization(3) dod(6) internet(1) 286 security(5) mechanism(5) snego (2) modules(4) spec2(2) 287 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 289 -- rest of definitions here 291 END 293 This specifies that the tagging context for the module will be 294 explicit and non-automatic. 296 The encoding of SPNEGO protocol messages shall obey the Distinguished 297 Encoding Rules (DER) of ASN.1 as described in [X690]. 299 4.1 Mechanism Types 301 In this negotiation model, each OID represents one GSS-API mechanism 302 or one variant (see Section 6) of it according to [RFC2743]. 304 MechType ::= OBJECT IDENTIFIER 305 -- OID represents each security mechanism as suggested by 306 -- [RFC2743] 308 MechTypeList ::= SEQUENCE OF MechType 310 4.2 Negotiation Tokens 312 The syntax of the initial negotiation tokens follows the 313 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 314 SPNEGO pseudo mechanism is identified by the Object Identifier 315 specified in Section 1. Subsequent tokens are not encapsulated in 316 this GSS-API generic token framing. 318 This section specifies the syntax of the inner token for the initial 319 message and the syntax of subsequent context establishment tokens. 321 NegotiationToken ::= CHOICE { 322 negTokenInit [0] NegTokenInit, 323 negTokenResp [1] negTokenResp 324 } 326 4.2.1 negTokenInit 328 NegTokenInit ::= SEQUENCE { 329 mechTypes [0] MechTypeList, 330 reqFlags [1] ContextFlags OPTIONAL, 331 mechToken [2] OCTET STRING OPTIONAL, 332 mechListMIC [3] OCTET STRING OPTIONAL, 333 ... 334 } 335 ContextFlags ::= BIT STRING { 336 delegFlag (0), 337 mutualFlag (1), 338 replayFlag (2), 339 sequenceFlag (3), 340 anonFlag (4), 341 confFlag (5), 342 integFlag (6) 343 } 345 This is the syntax for the inner token of the initial negotiation 346 message. 348 mechTypes 350 This field contains one or more security mechanisms available 351 for the initiator in decreasing preference order (favorite 352 choice first). 354 reqFlags 356 This field, if present, contains the service options that are 357 requested to establish the context. The context flags SHOULD 358 be filled in from the req_flags parameter of 359 GSS_Init_sec_context(). This field SHALL NOT have impact on 360 the negotiation. 362 mechToken 364 This field, if present, contains the optimistic mechanism 365 token. 367 mechlistMIC 369 This field, if present, contains a MIC token for the mechanism 370 list in the initial negotiation message. This MIC token is 371 computed according to Section 5. 373 4.2.2 negTokenResp 375 NegTokenResp ::= SEQUENCE { 376 negResult [0] ENUMERATED { 377 accept_completed (0), 378 accept_incomplete (1), 379 reject (2), 380 request_mic (3) 381 } OPTIONAL, 382 -- REQUIRED in the first reply from the target 383 supportedMech [1] MechType OPTIONAL, 384 -- present only in the first reply from the target 385 responseToken [2] OCTET STRING OPTIONAL, 386 mechListMIC [3] OCTET STRING OPTIONAL, 387 ... 388 } 390 This is the syntax for all subsequent negotiation messages. 392 negResult 394 This field, if present, contains the state of the negotiation. 395 This can be: 397 accept_completed 399 No further negotiation message from the peer is expected, 400 and the security context is established for the sender. 402 accept_incomplete 404 At least one more negotiation message from the peer is 405 needed to establish the security context. 407 reject 409 The sender terminates the negotiation. 411 request_mic 413 The sender indicates that the exchange of MIC tokens, as 414 described in Section 5, will be REQUIRED if per-message 415 integrity services are available on the mechanism context to 416 be established. This value SHALL only be present in the 417 first reply from the target. 419 This field is REQUIRED in the first reply from the target, and 420 it is OPTIONAL thereafter. 422 supportedMech 424 This field SHALL only be present in the first reply from the 425 target. It MUST be one of the mechanism(s) offered by the 426 initiator. 428 ResponseToken 430 This field, if present, contains tokens specific to the 431 mechanism selected. 433 mechlistMIC 435 This field, if present, contains a MIC token for the mechanism 436 list in the initial negotiation message. This MIC token is 437 computed according to Section 5. 439 5. Processing of mechListMIC 441 If the mechanism selected by the negotiation does not support 442 integrity protection, then no mechlistMIC token is used. 444 Otherwise if the accepted mechanism is the most preferred mechanism 445 of both the initiator and the acceptor, then the MIC token exchange, 446 as described later in this section, is OPTIONAL. A mechanism is the 447 acceptor's most preferred mechanism if there is no other mechanism 448 which would have been preferred over the accepted mechanism if it had 449 been present in the received mechanism list. 451 In all other cases, MIC tokens MUST be exchanged after the mechanism 452 context is fully established. 454 It is assumed that per-message integrity services are available on 455 the established mechanism context in the following procedure for 456 processing MIC tokens of the initiator's mechanism list. 458 a) The mechlistMIC token (or simply the MIC token) is computed by 459 invoking GSS_GetMIC(): the input context_handle is the established 460 mechanism context, the input qop_req is 0, and the input message 461 is the mechTypes field in the initial negotiation message (only 462 the DER encoding of the type MechTypeList is included). 464 b) If the selected mechanism uses an even number of mechanism tokens 465 (namely the acceptor sends the last mechanism token), the acceptor 466 does the following when emitting the negotiation message 467 containing the last mechanism token: if the MIC token exchange is 468 not required, GSS_Accept_sec_context() either indicates 469 GSS_S_COMPLETE and does not include a mechlistMIC token, or 470 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 471 and an accept_incomplete state; if the MIC token exchange is 472 required, GSS_Accept_sec_context() indicates 473 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 474 Acceptors that wish to be compatible with legacy Windows SPNEGO 475 implementations as described in Appendix B shall not generate a 476 mechlistMIC token when the MIC token exchange is not required. 477 The initiator then processes the last mechanism token, and does 478 one of the following: 480 (I) If a mechlistMIC token was included, and is correctly 481 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 482 output negotiation message contains a mechlistMIC token, and an 483 accept_complete state. The acceptor MUST then verify this 484 mechlistMIC token. 486 (II) If a mechlistMIC token was included but is incorrect, the 487 negotiation SHALL be terminated. GSS_Accept_sec_context() 488 indicates GSS_S_DEFECTIVE_TOKEN. 490 (III) If no mechlistMIC token was included, and the MIC token 491 exchange is not required, GSS_Init_sec_context() indicates 492 GSS_S_COMPLETE with no output token. 494 (IV) If no mechlistMIC token was included, but the MIC token 495 exchange is required, the negotiation SHALL be terminated. 496 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 498 c) In the case that the chosen mechanism uses an odd number of 499 mechanism tokens (namely the initiator sends the last mechanism 500 token), the initiator does the following when emitting the 501 negotiation message containing the last mechanism token: if the 502 negResult state was request_mic in the first reply from the 503 target, a mechlistMIC token MUST be included, otherwise the 504 mechlistMIC token is OPTIONAL. In the case that the optimistic 505 mechanism token is the only mechanism token for the initiator's 506 preferred mechanism, the mechlistMIC token is OPTIONAL. 507 GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED. 508 Initiators that wish to be compatible with legacy Windows SPNEGO 509 implementations as described in Appendix B shall not generate a 510 mechlistMIC token when the MIC token exchange is not required. 511 The acceptor then processes the last mechanism token and does one 512 of the following: 514 (I) If a mechlistMIC token was included and is correctly verified, 515 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 516 negotiation message contains a mechlistMIC token and an 517 accept_complete state. The initiator MUST then verify this 518 mechlistMIC token. 520 (II) If a mechlistMIC token was included but is incorrect, the 521 negotiation SHALL be terminated. GSS_Accept_sec_context() 522 indicates GSS_S_DEFECTIVE_TOKEN. 524 (III) If no mechlistMIC token was included but the mechlistMIC 525 token exchange is not required, GSS_Accept_sec_context() 526 indicates GSS_S_COMPLETE. The output negotiation message 527 contains an accept_complete state. 529 (IV) In the case that the optimistic mechanism token is also the 530 last mechanism token (when the initiator's preferred mechanism 531 is accepted by the target) and the target sends a request_mic 532 state but the initiator did not send a mechlistMIC token, the 533 target then MUST include a mechlistMIC token in that first 534 reply. GSS_Accept_sec_context() indicates 535 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 536 mechlistMIC token and generate a mechlistMIC token to send back 537 to the target. The target SHALL in turn verify the returned 538 mechlistMIC token and complete the negotiation. 540 (V) If no mechlistMIC token was included and the acceptor sent a 541 request_mic state in the first reply message (the exchange of 542 MIC tokens is required), the negotiation SHALL be terminated. 543 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 545 6. Extensibility 547 Two mechanisms are provided for extensibility. First, the ASN.1 548 structures in this specification MAY be expanded by IETF standards 549 action. Implementations receiving unknown fields MUST ignore these 550 fields. 552 Secondly, OIDs corresponding to a desired mechanism attribute may be 553 included in the set of preferred mechanisms by an initiator. The 554 acceptor can choose to honor this request by preferring mechanisms 555 that have the included attributes. Future work within the Kitten 556 working group is expected to standardize common attributes that 557 SPNEGO mechanisms may wish to support. At this time it is sufficient 558 to say that initiators MAY include OIDs that do not correspond to 559 mechanisms but instead correspond to desired mechanism attributes in 560 their requests. Such OIDs MAY influence the acceptor's choice of 561 mechanism. As discussed in Section 5, if there are mechanisms that 562 if present in the initiator's list of mechanisms might be preferred 563 by the acceptor to the initiator's preferred mechanism, the acceptor 564 MUST demand the MIC token exchange. As a consequence, acceptors MUST 565 demand the MIC token exchange if they support negotiation of 566 attributes not available in the initiator's preferred mechanism 567 regardless of whether the initiator actually requested these 568 attributes. 570 7. Security Considerations 572 In order to produce the MIC token for the mechanism list, the 573 mechanism must provide integrity protection. When the selected 574 mechanism does not support integrity protection, the negotiation is 575 vulnerable: an active attacker can force it to use a security 576 mechanism that is not mutually preferred but is acceptable to the 577 target. 579 This protocol provides the following guarantees when per-message 580 integrity services are available on the established mechanism context 581 and the mechanism list was altered by an adversary such that a 582 mechanism which is not mutually preferred could be selected: 584 o if the last mechanism token is sent by the initiator, both peers 585 shall fail; 586 o if the last mechanism token is sent by the acceptor, the acceptor 587 shall not complete and the initiator at worst shall complete with 588 its preferred mechanism being selected. 590 The negotiation may not be terminated if an alteration was made but 591 it had no material impact. 593 The protection of the negotiation depends on the strength of the 594 integrity protection. In particular, the strength of SPNEGO is no 595 stronger than the integrity protection of the weakest mechanism 596 acceptable to GSS-API peers. 598 In all cases, the communicating peers are exposed to the denial of 599 service threat. 601 8. IANA Considerations 603 This document has no actions for IANA. 605 9. Acknowledgments 607 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 608 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments 609 and suggestions during development of this document. 611 Luke Howard provided a prototype of this protocol in Heimdal and 612 resolved several issues in the initial draft. 614 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 615 [RFC2478] of which some of the text has been retained in this 616 document. 618 10 Normative References 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 624 Negotiation Mechanism", RFC 2478, December 1998. 626 [RFC2743] Linn, J., "Generic Security Service Application Program 627 Interface Version 2, Update 1", RFC 2743, January 2000. 629 [X690] ASN.1 encoding rules: Specification of Basic Encoding 630 Rules (BER), Canonical Encoding Rules (CER) and 631 Distinguished Encoding Rules (DER), ITU-T Recommendation 632 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 634 Authors' Addresses 636 Larry Zhu 637 Microsoft Corporation 638 One Microsoft Way 639 Redmond, WA 98052 640 US 642 EMail: lzhu@microsoft.com 644 Paul Leach 645 Microsoft Corporation 646 One Microsoft Way 647 Redmond, WA 98052 648 US 650 EMail: paulle@microsoft.com 651 Karthik Jaganathan 652 Microsoft Corporation 653 One Microsoft Way 654 Redmond, WA 98052 655 US 657 EMail: karthikj@microsoft.com 659 Wyllys Ingersoll 660 Sun Microsystems 661 1775 Wiehle Avenue, 2nd Floor 662 Reston, VA 20190 663 US 665 EMail: wyllys.ingersoll@sun.com 667 Appendix A. GSS-API Negotiation Support API 669 In order to provide to a GSS-API caller (either the initiator or the 670 target or both) the ability to choose among the set of supported 671 mechanisms a reduced set of mechanisms for negotiation, two 672 additional APIs are defined: 674 o GSS_Get_neg_mechs() indicates the set of security mechanisms 675 available on the local system to the caller for negotiation, based 676 on the credentials being used. 677 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 678 used on the local system by the caller for negotiation, for the 679 given credentials. 681 A.1 GSS_Set_neg_mechs call 683 Inputs: 685 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 686 -- credentials 687 o mech_set SET OF OBJECT IDENTIFIER 689 Outputs: 691 o major_status INTEGER, 692 o minor_status INTEGER 694 Return major_status codes: 696 o GSS_S_COMPLETE indicates that the set of security mechanisms 697 available for negotiation has been set to mech_set. 698 o GSS_S_FAILURE indicates that the requested operation could not be 699 performed for reasons unspecified at the GSS-API level. 701 Allows callers to specify the set of security mechanisms that may be 702 negotiated with the credential identified by cred_handle. This call 703 is intended for support of specialized callers who need to restrict 704 the set of negotiable security mechanisms from the set of all 705 security mechanisms available to the caller (based on available 706 credentials). Note that if more than one mechanism is specified in 707 mech_set, the order in which those mechanisms are specified implies a 708 relative preference. 710 A.2 GSS_Get_neg_mechs call 712 Input: 714 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 715 -- credentials 717 Outputs: 719 o major_status INTEGER, 720 o minor_status INTEGER, 721 o mech_set SET OF OBJECT IDENTIFIER 723 Return major_status codes: 725 o GSS_S_COMPLETE indicates that the set of security mechanisms 726 available for negotiation has been returned in mech_set. 727 o GSS_S_FAILURE indicates that the requested operation could not be 728 performed for reasons unspecified at the GSS-API level. 730 Allows callers to determine the set of security mechanisms available 731 for negotiation with the credential identified by cred_handle. This 732 call is intended for support of specialized callers who need to 733 reduce the set of negotiable security mechanisms from the set of 734 supported security mechanisms available to the caller (based on 735 available credentials). 737 Note: The GSS_Indicate_mechs() function indicates the full set of 738 mechanism types available on the local system. Since this call has 739 no input parameter, the returned set is not necessarily available for 740 all credentials. 742 Appendix B. Changes since RFC2478 744 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 745 2003 have the following behavior: no mechlistMIC is produced and 746 mechlistMIC is not processed if one is provided; if the initiator 747 sends the last mechanism token, the acceptor will send back a 748 negotiation token with an accept_complete state and no mechlistMIC 749 token. In addition, the OID (1.2.840.48018.1.2.2) can be used to 750 identify the GSS-API Kerberos Version 5 mechanism. 752 The following changes have been made to be compatible with these 753 legacy implementations. 755 * NegTokenTarg is changed to negTokenResp and it is the message 756 format for all subsequent negotiation tokens. 757 * NegTokenInit is the message for the initial negotiation message 758 and that message only. 759 * mechTypes in negTokenInit is not optional. 760 * Two MIC tokens are exchanged, one in each direction. 761 * If the selected mechanism is also the most preferred mechanism 762 for both peers, it is safe to omit the MIC tokens. 764 If at least one of the two peers implements the pseudo mechanism 765 in this document, the negotiation is protected. 767 The following changes are to address the problems in RFC 2478. 769 * reqFlags is not protected therefore it should not impact the 770 negotiation. 771 * DER encoding is required. 772 * GSS_GetMIC() input is clarified. 773 * Per-message integrity services are requested for the negotiated 774 mechanism. 776 An implementation that conforms to this specification will not 777 interoperate with a strict 2748 implementation. Even if the new 778 implementation always sends a mechlistMIC token, it will still fail 779 to interoperate. If it is a server, it will fail because it requests 780 a mechlistMIC token using an option that older implementations simply 781 do not support. Clients will tend to fail as well. 783 As an alternative to the approach chosen in this specification, we 784 could have documented a correct behavior that is fully backward 785 compatible with RFC 2478 and included an appendix on how to 786 interoperate with existing incorrect implementations of RFC 2478. 788 As a practical matter, the SPNEGO implementers within the IETF have 789 valued interoperability with the Microsoft implementations. We were 790 unable to choose to maintain reasonable security guarantees, maintain 791 interoperability with the Microsoft implementations and maintain 792 interoperability with correct implementations of RFC 2478. The 793 working group was not aware of any RFC 2478 implementations. Even if 794 there are RFC 2478 implementations, it is unlikely that they will 795 interoperate because of a critical flaw in the description of the 796 encoding of the mechanism list in RFC 2478. 798 With the approach taken in this specification, we get security 799 between new implementations all the time while maintaining 800 interoperability with the implementations we have within the IETF 801 community. The working group believes that this justifies breaking 802 compatibility with a correct implementation of RFC 2478. 804 Intellectual Property Statement 806 The IETF takes no position regarding the validity or scope of any 807 Intellectual Property Rights or other rights that might be claimed to 808 pertain to the implementation or use of the technology described in 809 this document or the extent to which any license under such rights 810 might or might not be available; nor does it represent that it has 811 made any independent effort to identify any such rights. Information 812 on the procedures with respect to rights in RFC documents can be 813 found in BCP 78 and BCP 79. 815 Copies of IPR disclosures made to the IETF Secretariat and any 816 assurances of licenses to be made available, or the result of an 817 attempt made to obtain a general license or permission for the use of 818 such proprietary rights by implementers or users of this 819 specification can be obtained from the IETF on-line IPR repository at 820 http://www.ietf.org/ipr. 822 The IETF invites any interested party to bring to its attention any 823 copyrights, patents or patent applications, or other proprietary 824 rights that may cover technology that may be required to implement 825 this standard. Please address the information to the IETF at 826 ietf-ipr@ietf.org. 828 Disclaimer of Validity 830 This document and the information contained herein are provided on an 831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 833 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 834 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 835 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 838 Copyright Statement 840 Copyright (C) The Internet Society (2004). This document is subject 841 to the rights, licenses and restrictions contained in BCP 78, and 842 except as set forth therein, the authors retain all their rights. 844 Acknowledgment 846 Funding for the RFC Editor function is currently provided by the 847 Internet Society.