idnits 2.17.1 draft-ietf-kitten-2478bis-01.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 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 785. ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 -- 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 (November 25, 2004) is 7092 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 373 -- Looks like a reference, but probably isn't: '1' on line 380 -- Looks like a reference, but probably isn't: '2' on line 382 -- Looks like a reference, but probably isn't: '3' on line 383 ** Obsolete normative reference: RFC 2478 (Obsoleted by RFC 4178) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 7 errors (**), 0 flaws (~~), 4 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: May 26, 2005 Microsoft Corporation 5 W. Ingersoll 6 Sun Microsystems 7 November 25, 2004 9 The Simple and Protected GSS-API Negotiation Mechanism 10 draft-ietf-kitten-2478bis-01 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 May 26, 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 . . . . . . . . 24 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 doesn't 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 that are based on GSS-API implementations and multiple 95 mechanisms are shared 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 its preference order (favorite choice first), the 100 acceptor (also known as the target) either accepts the initiator's 101 preferred security mechanism (the first in the list), or chooses one 102 that is available from the offered list, or rejects the proposed 103 value(s). The target then informs the initiator of its choice. 105 Once a common security mechanism is chosen, it MAY also negotiate 106 mechanism-specific options during its context establishment, but that 107 will be inside the mechanism tokens and invisible to this protocol. 109 If per-message integrity services are available on the established 110 mechanism security context, the peers can then exchange MIC tokens to 111 ensure that the mechanism list was not tampered with. This MIC token 112 exchange is OPTIONAL if no interference could have material impact on 113 the negotiation, i.e., when the selected mechanism is the first 114 choice for both peers. 116 In order to avoid an extra round trip, the first security token of 117 the preferred mechanism SHOULD be embedded in the initial negotiation 118 message (as defined in Section 4.2). This mechanism token is 119 referred to as the optimistic token in this document. If the 120 selected mechanism matches the initiator's preferred mechanism, no 121 additional round trips need to be incurred by using this protocol. 122 In addition, by using the optimistic token, the initiator can recover 123 from a non-fatal error in producing the first token before a 124 mechanism can be selected. Implementations, however, MAY omit the 125 optimistic token, to avoid the cost of generating it in cases where 126 the initiator's preferred mechanism is not selected by the acceptor. 128 SPNEGO uses the concepts developed in the GSS-API specification 129 [RFC2743]. The negotiation data is encapsulated in context-level 130 tokens. Therefore, callers of the GSS-API do not need to be aware of 131 the existence of the negotiation tokens but only of the new 132 pseudo-security mechanism. A failure in the negotiation phase causes 133 a major status code to be returned: GSS_S_BAD_MECH. 135 2. Conventions Used in This Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Negotiation Protocol 143 When the established mechanism context provides for integrity 144 protection, the mechanism negotiation can be protected. When 145 acquiring negotiated security mechanism tokens, per-message integrity 146 services are always requested by the SPNEGO mechanism. 148 When the established mechanism context supports per-message integrity 149 services, SPNEGO guarantees that the selected mechanism is mutually 150 preferred. 152 This section describes the negotiation process of this protocol. 154 3.1 Negotiation Description 156 The first negotiation token sent by the initiator contains an ordered 157 list of mechanisms (in preference order, favorite choice first), and 158 optionally the initial security token for the preferred mechanism of 159 the initiator (i.e., the first in the list). The list of security 160 mechanisms available for negotiation is based on the credentials 161 being used. 163 The target then processes the token from the initiator. This will 164 result in one of four possible states (as defined in Section 4.2.2): 165 accept_completed, accept_incomplete, reject, or request_mic. A 166 reject state will terminate the negotiation; an accept_completed 167 state indicates that not only was the initiator-selected mechanism 168 acceptable to the target, but that the initial token was sufficient 169 to complete the authentication; an accept_incomplete state indicates 170 that further message exchange is needed but the MIC token exchange as 171 described in Section 5 is OPITONAL; a request_mic state (this state 172 can only be present in the first reply message from the target) 173 indicates the MIC token exchange is REQUIRED if per-message integrity 174 services are available. 176 Unless the preference order is specified by the application (see 177 Appendix A), the policy by which the target chooses a mechanism is an 178 implementation-specific local matter. In the absence of application 179 specified preference order or other policy, the target SHALL choose 180 the first mechanism in the initiator proposed list for which it has 181 valid credentials. 183 In case of a successful negotiation, the security mechanism in the 184 first reply message represents the value suitable for the target, and 185 picked up from the list offered by the initiator. A context level 186 token for a reject state is OPTIONAL. 188 Once a mechanism has been selected, the tokens specific to the 189 selected mechanism are carried within the negotiation tokens. 191 Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the 192 mechanism list as seen by the target. 194 To avoid conflicts with the use of MIC tokens by SPNEGO, 195 partially-established contexts are not used for per-message calls: 196 the prot_ready_state [RFC2743] will be false even if the underlying 197 mechanism would return true natively. 199 3.2 Negotiation Procedure 201 The basic form of the procedure assumes that per-message integrity 202 services are available on the established mechanism context, and it 203 is summarized as follows: 205 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 206 but requests (either explicitly, with the negotiation mechanism, 207 or through accepting a default, when the default is this 208 negotiation mechanism) that SPNEGO is used. 210 (b) The initiator GSS-API implementation emits a negotiation token 211 containing a list of supported security mechanisms (possible just 212 one mechanism) for the credentials used for this context 213 establishment, and optionally an initial security token for the 214 first mechanism from that list. 216 (c) The GSS-API initiator application sends the token to the target 217 application. The GSS-API target application deposits the token 218 through invoking GSS_Accept_sec_context(). The acceptor will do 219 one of the following: 221 (I) No proposed mechanism is acceptable, the negotiation SHALL be 222 terminated. GSS_Accept_sec_context indicates GSS_S_BAD_MECH. 223 The acceptor MAY output a negotiation token containing a reject 224 state. 226 (II) If either the initiator's preferred mechanism is not accepted 227 by the target, or this mechanism is accepted but it is not the 228 most preferred mechanism available for the acceptor (see 229 Section 3.1 and Section 5), GSS_Accept_sec_context() indicates 230 GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation 231 token containing a request_mic state. 233 (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE 234 or GSS_S_CONTINUE_NEEDED, depending on if at least one 235 additional negotiation token from the initiator is needed to 236 establish this context. The acceptor outputs a negotiation 237 token containing an accept_complete or accept_incomplete state, 238 respectively. 240 If the initiator's preferred mechanism is accepted, and an 241 optimistic mechanism token was included, this mechanism token MUST 242 be deposited to the selected mechanism through invoking 243 GSS_Accept_sec_context() and if a response mechanism token is 244 emitted, it MUST be included in the response negotiation token. 245 Otherwise, the target will not emit a response mechanism token in 246 the first reply. 248 (d) The GSS-API target application returns the negotiation token to 249 the initiator application. The GSS-API initiator application 250 deposits the token through invoking GSS_Init_sec_context(). The 251 security context initialization is then continued according to the 252 standard GSS-API conventions for the selected mechanism, where the 253 tokens of the selected mechanism are encapsulated until the 254 GSS_S_COMPLETE is returned for both the initiator and the target 255 by the selected security mechanism. 257 (e) MIC tokens are then either skipped or exchanged according to 258 Section 5. 260 Note that the *_req_flag input parameters for context establishment 261 are relative to the selected mechanism, as are the *_state output 262 parameters. i.e., these parameters are not applicable to the 263 negotiation process per se. 265 On receipt of a negotiation token on the target side, a GSS-API 266 implementation that does not support negotiation would indicate the 267 GSS_S_BAD_MECH status as if a particular basic security mechanism had 268 been requested but was not supported. 270 When GSS_Acquire_cred is invoked with this SPNEGO mechanism as 271 desired_mechs, an implementation-specific default credential is used 272 to carry on the negotiation. A set of mechanisms as specified 273 locally by the system administrator is then available for 274 negotiation. If there is a desire for the caller to make its own 275 choice, then an additional API has to be used (see Appendix A). 277 4. Token Definitions 279 The type definitions in this section assume an ASN.1 module 280 definition of the following form: 282 SPNEGOASNOneSpec { 283 iso(1) identified-organization(3) dod(6) internet(1) 284 security(5) mechanism(5) snego (2) modules(4) spec2(2) 285 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 287 -- rest of definitions here 289 END 291 This specifies that the tagging context for the module will be 292 explicit and non-automatic. 294 The encoding of SPNEGO protocol messages shall obey the Distinguished 295 Encoding Rules (DER) of ASN.1 as described in [X690]. 297 4.1 Mechanism Types 299 In this negotiation model, each OID represents one GSS-API mechanism 300 or one variant (see Section 6) of it according to [RFC2743]. 302 MechType ::= OBJECT IDENTIFIER 303 -- OID represents each security mechanism as suggested by 304 -- [RFC2743] 306 MechTypeList ::= SEQUENCE OF MechType 308 4.2 Negotiation Tokens 310 The syntax of the initial negotiation tokens follows the 311 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 312 SPNEGO pseudo mechanism is identified by the Object Identifier 313 specified in Section 1. Subsequent tokens are not encapsulated in 314 this GSS-API generic token framing. 316 This section specifies the syntax of the inner token for the initial 317 message, and the syntax of subsequent context establishment tokens. 319 NegotiationToken ::= CHOICE { 320 negTokenInit [0] NegTokenInit, 321 negTokenResp [1] negTokenResp 322 } 324 4.2.1 negTokenInit 326 NegTokenInit ::= SEQUENCE { 327 mechTypes [0] MechTypeList, 328 reqFlags [1] ContextFlags OPTIONAL, 329 mechToken [2] OCTET STRING OPTIONAL, 330 mechListMIC [3] OCTET STRING OPTIONAL, 331 ... 332 } 333 ContextFlags ::= BIT STRING { 334 delegFlag (0), 335 mutualFlag (1), 336 replayFlag (2), 337 sequenceFlag (3), 338 anonFlag (4), 339 confFlag (5), 340 integFlag (6) 341 } 343 This is the syntax for the inner token of the initial negotiation 344 message. 346 mechTypes 348 This field contains one or more security mechanisms available 349 for the initiator in preference order (favorite choice first). 351 reqFlags 353 This field, if present, contains the service options that are 354 requested to establish the context. The context flags SHOULD 355 be filled in from the req_flags parameter of 356 GSS_Init_sec_context(). This field SHALL NOT have impact on 357 the negotiation. 359 mechToken 361 This field, is present, contains the optimistic security 362 mechanism token. 364 mechlistMIC 366 This field, is present, contains a MIC token, which is computed 367 according to Section 5, for the mechanism list in the initial 368 negotiation message. 370 4.2.2 negTokenResp 372 NegTokenResp ::= SEQUENCE { 373 negResult [0] ENUMERATED { 374 accept_completed (0), 375 accept_incomplete (1), 376 reject (2), 377 request_mic (3) 378 } OPTIONAL, 379 -- REQUIRED in the first reply from the target 380 supportedMech [1] MechType OPTIONAL, 381 -- present only in the first reply from the target 382 responseToken [2] OCTET STRING OPTIONAL, 383 mechListMIC [3] OCTET STRING OPTIONAL, 384 ... 385 } 387 This is the syntax for all subsequent negotiation messages. 389 negResult 391 This field, if present, contains the state of the negotiation. 392 This can be: 394 accept_completed 395 No further negotiation message from the peer is expected, 396 and the security context is established for the sender. 398 accept_incomplete 399 At least one more negotiation message from the peer is 400 needed to establish the security context. 402 reject 403 The sender terminates the negotiation. 405 request_mic 406 The sender indicates that the exchange of MIC tokens, as 407 described in Section 5, will be REQUIRED if per-message 408 integrity services are available on the mechanism context to 409 be established. This value SHALL only be present in the 410 first reply from the target. 412 This field is REQUIRED in the first reply from the target, and 413 it is OPTIONAL thereafter. 415 supportedMech 417 This field SHALL only be present in the first reply from the 418 target. It is a choice from the mechanism(s) offered by the 419 initiator. 421 ResponseToken 423 The field, if present, contains tokens specific to the 424 mechanism selected. 426 mechlistMIC 428 This field, is present, contains a MIC token, which is computed 429 according to Section 5, for the mechanism list in the initial 430 negotiation message. 432 5. Processing of mechListMIC 434 If the mechanism selected by the negotiation does not support 435 integrity protection, then no mechlistMIC token is used. Otherwise 436 if the initiator's preferred mechanism is accepted and it is also the 437 most preferred mechanism available for the acceptor (there is no 438 mechanism which, had it been present in the mechanism list, the 439 acceptor would have preferred over the accepted mechanism), then the 440 MIC token exchange, as described later in this section, is OPTIONAL. 441 In all other cases, MIC tokens MUST be exchanged after the mechanism 442 context is fully established. 444 It is assumed that per-message integrity services are available on 445 the established mechanism context in the following procedure for 446 processing MIC tokens of the initiator's mechanism list. 448 a) The mechlistMIC token (or simply the MIC token) is computed 449 through invoking GSS_GetMIC(): the input context_handle is the 450 established mechanism context, the input qop_req is 0, and the 451 input message is the mechTypes field in the initial negotiation 452 message (only the DER encoding of type MechTypeList is included). 454 b) If the selected mechanism uses an even number of mechanism tokens 455 (namely the acceptor sends the last mechanism token), the acceptor 456 does the following when emitting the negotiation message 457 containing the last mechanism token: if the MIC token exchange is 458 not required, GSS_Accept_sec_context() either indicates 459 GSS_S_COMPLETE and does not include a mechlistMIC token, or 460 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 461 and an accept_incomplete state; if the MIC token exchange is 462 required, GSS_Accept_sec_context() indicates 463 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 464 Acceptors who wish to be compatible with legacy Windows SPNEGO 465 implementations as described in Appendix B shall not generate a 466 mechlistMIC token when the MIC token exchange is not required. 467 The initiator then processes the last mechanism token, and does 468 one of the following: 470 (I) If a mechlistMIC token was included, and is correctly 471 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 472 output negotiation message contains a mechlistMIC token, and an 473 accept_complete state. The acceptor MUST then verify this 474 mechlistMIC token. 476 (II) If a mechlistMIC token was included but is incorrect, the 477 negotiation SHALL be terminated. GSS_Accept_sec_context() 478 indicates GSS_S_DEFECTIVE_TOKEN. 480 (III) If no mechlistMIC token was included, and the MIC token 481 exchange is not required, GSS_Init_sec_context() indicates 482 GSS_S_COMPLETE with no output token. 484 (IV) If no mechlistMIC token was included, but the MIC token 485 exchange is required, the negotiation SHALL be terminated. 486 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 488 c) In the case that the chosen mechanism uses an odd number of 489 mechanism tokens (namely the initiator sends the last mechanism 490 token), the initiator does the following when emitting the 491 negotiation message containing the last mechanism token: if the 492 negResult state was request_mic in the first reply from the 493 target, a mechlistMIC token MUST be included, otherwise the 494 mechlistMIC token is OPTIONAL. In the case that the optimistic 495 mechanism token is the only mechanism token for the initiator's 496 preferred mechanism, the mechlistMIC token is OPTIONAL. 497 GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED. 498 Initiators who wish to be compatible with legacy Windows SPNEGO 499 implementations as described in Appendix B shall not generate a 500 mechlistMIC token when the MIC token exchange is not required. 501 The acceptor then processes the last mechanism token, and does one 502 of the following: 504 (I) If a mechlistMIC token was included, and is correctly 505 verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE. 506 The output negotiation message contains a mechlistMIC token, 507 and an accept_complete state. The initiator MUST then verify 508 this mechlistMIC token. 510 (II) If a mechlistMIC token was included but is incorrect, the 511 negotiation SHALL be terminated. GSS_Accept_sec_context() 512 indicates GSS_S_DEFECTIVE_TOKEN. 514 (III) If no mechlistMIC token was included and the mechlistMIC 515 token exchange is not required, GSS_Accept_sec_context() 516 indicates GSS_S_COMPLETE. The output negotiation message 517 contains an accept_complete state. 519 (IV) In the case that the optimistic mechanism token is also the 520 last mechanism token (when the initiator's preferred mechanism 521 is accepted by the target), and the target sends a request_mic 522 state, but the initiator did not send a mechlistMIC token, the 523 target then MUST include a mechlistMIC token in that first 524 reply. GSS_Accept_sec_context() indicates 525 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 526 mechlistMIC token, and generate a mechlistMIC token to send 527 back to the target, who SHALL in turn verify the returned 528 mechlistMIC token and complete the negotiation. 530 (V) If no mechlistMIC token was included and the acceptor sent a 531 request_mic state in the first reply message (the exchange of 532 MIC tokens is required), the negotiation SHALL be terminated. 533 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 535 6. Extensibility 537 Two mechanisms are provided by extensibility. First, the ASN.1 538 structures in this specification MAY be expanded by IETF standards 539 action. Implementations receiving unknown fields MUST ignore these 540 fields. 542 Secondly, OIDs corresponding to a desired mechanism attribute may be 543 included in the set of preferred mechanisms by an initiator. The 544 acceptor can choose to honor this request by preferring mechanisms 545 that have that attribute. Future work within the Kitten working 546 group is expected to standardize common attributes that SPNEGO 547 mechanisms may wish to support. At this time it is sufficient to say 548 that initiators MAY include OIDs that do not correspond to mechanisms 549 but instead correspond to desired mechanism attributes in their 550 requests. Such OIDs MAY influence the acceptor's choice of 551 mechanism. As discussed in Section 5, if there are mechanisms that 552 if present in the initiator's list of mechanisms might be preferred 553 by the acceptor to the initiator's preferred mechanism, the acceptor 554 MUST demand the MIC token exchange. As a consequence, acceptors MUST 555 demand the MIC token exchange if they support negotiation of 556 attributes not available in the initiator's preferred mechanism 557 regardless of whether the initiator actually requested these 558 attributes. 560 7. Security Considerations 562 In order to produce the MIC token for the mechanism list, the 563 mechanism must provide integrity protection. When the selected 564 mechanism does not support integrity protection, then the negotiation 565 is vulnerable: an active attacker can force it to use a security 566 mechanism that is not mutually preferred but is acceptable anyway to 567 the target. 569 When per-message integrity services are available on the established 570 mechanism context, and there was an alteration of the mechanism list 571 by an adversary such that a common mechanism that is not mutually 572 preferred could be selected, this protocol provides the following 573 guarantees: if the last mechanism token is sent by the initiator, 574 both peers shall fail; if the last mechanism token is sent by the 575 acceptor, the acceptor shall not complete and the initiator at worst 576 shall complete with its preferred mechanism being selected. The 577 negotiation may not be terminated if an alteration was made but it 578 had no material impact. 580 The protection of the negotiation depends on the strength of the 581 integrity protection. In particular, the strength of SPNEGO is no 582 stronger than the integrity protection of the weakest mechanism 583 acceptable to GSS-API peers. 585 In all cases, the communicating peers are exposed to the denial of 586 service threat. 588 8. IANA Considerations 590 This document has no actions for IANA. 592 9. Acknowledgments 594 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 595 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments 596 and suggestions on earlier versions of this document. 598 Luke Howard provided a prototype of this protocol in Heimdal, and 599 resolved several issues in the initial draft. 601 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 602 [RFC2478], of which some of the text has been retained in this 603 document. 605 10 Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 611 Negotiation Mechanism", RFC 2478, December 1998. 613 [RFC2743] Linn, J., "Generic Security Service Application Program 614 Interface Version 2, Update 1", RFC 2743, January 2000. 616 [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules 617 (BER), Canonical Encoding Rules (CER) and Distinguished 618 Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 619 ISO/IEC International Standard 8825-1:1998. 621 Authors' Addresses 623 Larry Zhu 624 Microsoft Corporation 625 One Microsoft Way 626 Redmond, WA 98052 627 US 629 EMail: lzhu@microsoft.com 631 Paul Leach 632 Microsoft Corporation 633 One Microsoft Way 634 Redmond, WA 98052 635 US 637 EMail: paulle@microsoft.com 638 Karthik Jaganathan 639 Microsoft Corporation 640 One Microsoft Way 641 Redmond, WA 98052 642 US 644 EMail: karthikj@microsoft.com 646 Wyllys Ingersoll 647 Sun Microsystems 648 1775 Wiehle Avenue, 2nd Floor 649 Reston, VA 20190 650 US 652 EMail: wyllys.ingersoll@sun.com 654 Appendix A. GSS-API Negotiation Support API 656 In order to provide to a GSS-API caller (either the initiator or the 657 target or both) the ability to choose among the set of supported 658 mechanisms a reduced set of mechanisms for negotiation, two 659 additional APIs are defined: 661 o GSS_Get_neg_mechs() indicates the set of security mechanisms 662 available on the local system to the caller for negotiation, based 663 on the credentials being used. 664 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 665 used on the local system by the caller for negotiation, for the 666 given credentials. 668 A.1 GSS_Set_neg_mechs call 670 Inputs: 672 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 673 -- credentials 674 o mech_set SET OF OBJECT IDENTIFIER 676 Outputs: 678 o major_status INTEGER, 679 o minor_status INTEGER 681 Return major_status codes: 683 o GSS_S_COMPLETE indicates that the set of security mechanisms 684 available for negotiation has been set to mech_set. 685 o GSS_S_FAILURE indicates that the requested operation could not be 686 performed for reasons unspecified at the GSS-API level. 688 Allows callers to specify the set of security mechanisms that may be 689 negotiated with the credential identified by cred_handle. This call 690 is intended for support of specialized callers who need to restrict 691 the set of negotiable security mechanisms from the set of all 692 security mechanisms available to the caller (based on available 693 credentials). Note that if more than one mechanism is specified in 694 mech_set, the order in which those mechanisms are specified implies a 695 relative preference. 697 A.2 GSS_Get_neg_mechs call 699 Input: 701 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 702 -- credentials 704 Outputs: 706 o major_status INTEGER, 707 o minor_status INTEGER, 708 o mech_set SET OF OBJECT IDENTIFIER 710 Return major_status codes: 712 o GSS_S_COMPLETE indicates that the set of security mechanisms 713 available for negotiation has been returned in mech_set. 714 o GSS_S_FAILURE indicates that the requested operation could not be 715 performed for reasons unspecified at the GSS-API level. 717 Allows callers to determine the set of security mechanisms available 718 for negotiation with the credential identified by cred_handle. This 719 call is intended for support of specialized callers who need to 720 reduce the set of negotiable security mechanisms from the set of 721 supported security mechanisms available to the caller (based on 722 available credentials). 724 Note: The GSS_Indicate_mechs() function indicates the full set of 725 mechanism types available on the local system. Since this call has 726 no input parameter, the returned set is not necessarily available for 727 all credentials. 729 Appendix B. Changes since RFC2478 731 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 732 2003 have the following behavior: no mechlistMIC is produced, and 733 mechlistMIC is not processed if one is provided; if the initiator 734 sends the last mechanism token, the acceptor will send back a 735 negotiation token with an accept_complete state and no mechlistMIC 736 token. In addition, the OID (1.2.840.48018.1.2.2) can be used to 737 identify the GSS-API Kerberos Version 5 mechanism. 739 The following changes have been made to be compatible with these 740 legacy implementations. 742 * NegTokenTarg is changed to negTokenResp and it is the message 743 format for all subsequent negotiation tokens. 744 * NegTokenInit is the message for the initial token and that 745 token only. 746 * mechTypes in negTokenInit is not optional. 747 * Two MIC tokens are exchanged, one in each direction. 748 * If the selected mechanism is also the most preferred mechanism 749 for both peers, it is safe to omit the MIC tokens. 751 If at least one of the two peers implements the pseudo mechanism 752 in this document, the negotiation is protected. 754 The following changes are to address the problems in RFC 2478. 756 * reqFlags is not protected therefore it should not impact the 757 negotiation. 758 * DER encoding is required. 759 * GSS_GetMIC() input is clarified. 760 * Per-message integrity services are requested for the negotiated 761 mechanism. 763 Intellectual Property Statement 765 The IETF takes no position regarding the validity or scope of any 766 Intellectual Property Rights or other rights that might be claimed to 767 pertain to the implementation or use of the technology described in 768 this document or the extent to which any license under such rights 769 might or might not be available; nor does it represent that it has 770 made any independent effort to identify any such rights. Information 771 on the procedures with respect to rights in RFC documents can be 772 found in BCP 78 and BCP 79. 774 Copies of IPR disclosures made to the IETF Secretariat and any 775 assurances of licenses to be made available, or the result of an 776 attempt made to obtain a general license or permission for the use of 777 such proprietary rights by implementers or users of this 778 specification can be obtained from the IETF on-line IPR repository at 779 http://www.ietf.org/ipr. 781 The IETF invites any interested party to bring to its attention any 782 copyrights, patents or patent applications, or other proprietary 783 rights that may cover technology that may be required to implement 784 this standard. Please address the information to the IETF at 785 ietf-ipr@ietf.org. 787 Disclaimer of Validity 789 This document and the information contained herein are provided on an 790 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 791 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 792 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 793 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 794 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 795 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 797 Copyright Statement 799 Copyright (C) The Internet Society (2004). This document is subject 800 to the rights, licenses and restrictions contained in BCP 78, and 801 except as set forth therein, the authors retain all their rights. 803 Acknowledgment 805 Funding for the RFC Editor function is currently provided by the 806 Internet Society.