idnits 2.17.1 draft-ietf-kitten-2478bis-00.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 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 764. ** 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 18) 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 22, 2004) is 7066 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 379 -- Looks like a reference, but probably isn't: '2' on line 380 -- Looks like a reference, but probably isn't: '3' on line 381 ** 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 23, 2005 Microsoft Corporation 5 W. Ingersoll 6 Sun Microsystems 7 November 22, 2004 9 The Simple and Protected GSS-API Negotiation Mechanism 10 draft-ietf-kitten-2478bis-00 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 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 71 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 20 72 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 20 73 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 20 74 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 22 75 Intellectual Property and Copyright Statements . . . . . . . . 23 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 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 }, 379 supportedMech [1] MechType OPTIONAL, 380 responseToken [2] OCTET STRING OPTIONAL, 381 mechListMIC [3] OCTET STRING OPTIONAL, 382 ... 383 } 385 This is the syntax for all subsequent negotiation messages. 387 negResult 389 This field contains the state of the negotiation. This can be: 391 accept_completed 392 No further negotiation message from the peer is expected, 393 and the security context is established for the sender. 395 accept_incomplete 396 At least one more negotiation message from the peer is 397 needed to establish the security context. 399 reject 400 The sender terminates the negotiation. 402 request_mic 403 The sender indicates that the exchange of MIC tokens, as 404 described in Section 5, will be REQUIRED if per-message 405 integrity services are available on the mechanism context to 406 be established. This value SHALL only be present in the 407 first reply from the target. 409 supportedMech 411 This field SHALL only be present in the first reply from the 412 target. It is a choice from the mechanism(s) offered by the 413 initiator. 415 ResponseToken 417 The field, if present, contains tokens specific to the 418 mechanism selected. 420 mechlistMIC 422 This field, is present, contains a MIC token, which is computed 423 according to Section 5, for the mechanism list in the initial 424 negotiation message. 426 5. Processing of mechListMIC 428 If the mechanism selected by the negotiation does not support 429 integrity protection, then no mechlistMIC token is used. Otherwise 430 if the initiator's preferred mechanism is accepted and it is also the 431 most preferred mechanism available for the acceptor (there is no 432 mechanism which, had it been present in the mechanism list, the 433 acceptor would have preferred over the accepted mechanism), then the 434 MIC token exchange, as described later in this section, is OPTIONAL. 435 In all other cases, MIC tokens MUST be exchanged after the mechanism 436 context is fully established. 438 It is assumed that per-message integrity services are available on 439 the established mechanism context in the following procedure for 440 processing MIC tokens of the initiator's mechanism list. 442 a) The mechlistMIC token (or simply the MIC token) is computed 443 through invoking GSS_GetMIC(): the input context_handle is the 444 established mechanism context, the input qop_req is 0, and the 445 input message is the mechTypes field in the initial negotiation 446 message (only the "value" portion, omitting the tag and length, of 447 the ASN.1 encoding for that field is included). 449 b) If the selected mechanism uses an even number of mechanism tokens 450 (namely the acceptor sends the last mechanism token), the acceptor 451 does the following when emitting the negotiation message 452 containing the last mechanism token: if the MIC token exchange is 453 not required, GSS_Accept_sec_context() either indicates 454 GSS_S_COMPLETE and does not include a mechlistMIC token, or 455 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 456 and an accept_incomplete state; if the MIC token exchange is 457 required, GSS_Accept_sec_context() indicates 458 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 459 Acceptors who wish to be compatible with legacy Windows SPNEGO 460 implementations as described in Appendix B shall not generate a 461 mechlistMIC token when the MIC token exchange is not required. 462 The initiator then processes the last mechanism token, and does 463 one of the following: 465 (I) If a mechlistMIC token was included, and is correctly 466 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 467 output negotiation message contains a mechlistMIC token, and an 468 accept_complete state. The acceptor MUST then verify this 469 mechlistMIC token. 471 (II) If a mechlistMIC token was included but is incorrect, the 472 negotiation SHALL be terminated. GSS_Accept_sec_context() 473 indicates GSS_S_DEFECTIVE_TOKEN. 475 (III) If no mechlistMIC token was included, and the MIC token 476 exchange is not required, GSS_Init_sec_context() indicates 477 GSS_S_COMPLETE with no output token. 479 (IV) If no mechlistMIC token was included, but the MIC token 480 exchange is required, the negotiation SHALL be terminated. 481 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 483 c) In the case that the chosen mechanism uses an odd number of 484 mechanism tokens (namely the initiator sends the last mechanism 485 token), the initiator does the following when emitting the 486 negotiation message containing the last mechanism token: if the 487 negResult state was request_mic in the first reply from the 488 target, a mechlistMIC token MUST be included, otherwise the 489 mechlistMIC token is OPTIONAL. GSS_Init_sec_context() indicates 490 GSS_S_CONTINUE_NEEDED. Initiators who wish to be compatible with 491 legacy Windows SPNEGO implementations as described in Appendix B 492 shall not generate a mechlistMIC token when the MIC token exchange 493 is not required. The acceptor then processes the last mechanism 494 token, and does one of the following: 496 (I) If a mechlistMIC token was included, and is correctly 497 verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE. 498 The output negotiation message contains a mechlistMIC token, 499 and an accept_complete state. The initiator MUST then verify 500 this mechlistMIC token. 502 (II) If a mechlistMIC token was included but is incorrect, the 503 negotiation SHALL be terminated. GSS_Accept_sec_context() 504 indicates GSS_S_DEFECTIVE_TOKEN. 506 (III) If no mechlistMIC token was included and the mechlistMIC 507 token exchange is not required, GSS_Accept_sec_context() 508 indicates GSS_S_COMPLETE. The output negotiation message 509 contains an accept_complete state. 511 (IV) If no mechlistMIC token was included and the acceptor sent a 512 request_mic state in the first reply message (the exchange of 513 MIC tokens is required), the negotiation SHALL be terminated. 514 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 516 6. Extensibility 518 Two mechanisms are provided by extensibility. First, the ASN.1 519 structures in this specification MAY be expanded by IETF standards 520 action. Implementations receiving unknown fields MUST ignore these 521 fields. 523 Secondly, OIDs corresponding to a desired mechanism attribute may be 524 included in the set of preferred mechanisms by an initiator. The 525 acceptor can choose to honor this request by preferring mechanisms 526 that have that attribute. Future work within the Kitten working 527 group is expected to standardize common attributes that SPNEGO 528 mechanisms may wish to support. At this time it is sufficient to say 529 that initiators MAY include OIDs that do not correspond to mechanisms 530 but instead correspond to desired mechanism attributes in their 531 requests. Such OIDs MAY influence the acceptor's choice of 532 mechanism. As discussed in Section 5, if there are mechanisms that 533 if present in the initiator's list of mechanisms might be preferred 534 by the acceptor to the initiator's preferred mechanism, the acceptor 535 MUST demand the MIC token exchange. As a consequence, acceptors MUST 536 demand the MIC token exchange if they support negotiation of 537 attributes not available in the initiator's preferred mechanism 538 regardless of whether the initiator actually requested these 539 attributes. 541 7. Security Considerations 543 In order to produce the MIC token for the mechanism list, the 544 mechanism must provide integrity protection. When the selected 545 mechanism does not support integrity protection, then the negotiation 546 is vulnerable: an active attacker can force it to use a security 547 mechanism that is not mutually preferred but is acceptable anyway to 548 the target. 550 When per-message integrity services are available on the established 551 mechanism context, and there was an alteration of the mechanism list 552 by an adversary such that a common mechanism that is not mutually 553 preferred could be selected, this protocol provides the following 554 guarantees: if the last mechanism token is sent by the initiator, 555 both peers shall fail; if the last mechanism token is sent by the 556 acceptor, the acceptor shall not complete and the initiator at worst 557 shall complete with its preferred mechanism being selected. The 558 negotiation may not be terminated if an alteration was made but it 559 had no material impact. 561 The protection of the negotiation depends on the strength of the 562 integrity protection. In particular, the strength of SPNEGO is no 563 stronger than the integrity protection of the weakest mechanism 564 acceptable to GSS-API peers. 566 In all cases, the communicating peers are exposed to the denial of 567 service threat. 569 8. IANA Considerations 571 This document has no actions for IANA. 573 9. Acknowledgments 575 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 576 Jeff Altman, Cristian Ilac and Martin Rex for their comments and 577 suggestions on earlier versions of this document. 579 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 580 [RFC2478], of which some of the text has been retained in this 581 document. 583 10 Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 589 Negotiation Mechanism", RFC 2478, December 1998. 591 [RFC2743] Linn, J., "Generic Security Service Application Program 592 Interface Version 2, Update 1", RFC 2743, January 2000. 594 [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules 595 (BER), Canonical Encoding Rules (CER) and Distinguished 596 Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 597 ISO/IEC International Standard 8825-1:1998. 599 Authors' Addresses 601 Larry Zhu 602 Microsoft Corporation 603 One Microsoft Way 604 Redmond, WA 98052 605 US 607 EMail: lzhu@microsoft.com 609 Paul Leach 610 Microsoft Corporation 611 One Microsoft Way 612 Redmond, WA 98052 613 US 615 EMail: paulle@microsoft.com 616 Karthik Jaganathan 617 Microsoft Corporation 618 One Microsoft Way 619 Redmond, WA 98052 620 US 622 EMail: karthikj@microsoft.com 624 Wyllys Ingersoll 625 Sun Microsystems 626 1775 Wiehle Avenue, 2nd Floor 627 Reston, VA 20190 628 US 630 EMail: wyllys.ingersoll@sun.com 632 Appendix A. GSS-API Negotiation Support API 634 In order to provide to a GSS-API caller (either the initiator or the 635 target or both) the ability to choose among the set of supported 636 mechanisms a reduced set of mechanisms for negotiation, two 637 additional APIs are defined: 639 o GSS_Get_neg_mechs() indicates the set of security mechanisms 640 available on the local system to the caller for negotiation, based 641 on the credentials being used. 642 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 643 used on the local system by the caller for negotiation, for the 644 given credentials. 646 A.1 GSS_Set_neg_mechs call 648 Inputs: 650 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 651 -- credentials 652 o mech_set SET OF OBJECT IDENTIFIER 654 Outputs: 656 o major_status INTEGER, 657 o minor_status INTEGER 659 Return major_status codes: 661 o GSS_S_COMPLETE indicates that the set of security mechanisms 662 available for negotiation has been set to mech_set. 663 o GSS_S_FAILURE indicates that the requested operation could not be 664 performed for reasons unspecified at the GSS-API level. 666 Allows callers to specify the set of security mechanisms that may be 667 negotiated with the credential identified by cred_handle. This call 668 is intended for support of specialized callers who need to restrict 669 the set of negotiable security mechanisms from the set of all 670 security mechanisms available to the caller (based on available 671 credentials). Note that if more than one mechanism is specified in 672 mech_set, the order in which those mechanisms are specified implies a 673 relative preference. 675 A.2 GSS_Get_neg_mechs call 677 Input: 679 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 680 -- credentials 682 Outputs: 684 o major_status INTEGER, 685 o minor_status INTEGER, 686 o mech_set SET OF OBJECT IDENTIFIER 688 Return major_status codes: 690 o GSS_S_COMPLETE indicates that the set of security mechanisms 691 available for negotiation has been returned in mech_set. 692 o GSS_S_FAILURE indicates that the requested operation could not be 693 performed for reasons unspecified at the GSS-API level. 695 Allows callers to determine the set of security mechanisms available 696 for negotiation with the credential identified by cred_handle. This 697 call is intended for support of specialized callers who need to 698 reduce the set of negotiable security mechanisms from the set of 699 supported security mechanisms available to the caller (based on 700 available credentials). 702 Note: The GSS_Indicate_mechs() function indicates the full set of 703 mechanism types available on the local system. Since this call has 704 no input parameter, the returned set is not necessarily available for 705 all credentials. 707 Appendix B. Changes since RFC2478 709 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 710 2003 have the following behavior: no mechlistMIC is produced, and 711 mechlistMIC is not processed if one is provided; if the initiator 712 sends the last mechanism token, the acceptor will send back a 713 negotiation token with an accept_complete state and no mechlistMIC 714 token. In addition, the OID (1.2.840.48018.1.2.2) can be used to 715 identify the GSS-API Kerberos Version 5 mechanism. 717 The following changes have been made to be compatible with these 718 legacy implementations. 720 * NegTokenTarg is changed to negTokenResp and it is the message 721 format for all subsequent negotiation tokens. 722 * NegTokenInit is the message for the initial token and that 723 token only. 724 * mechTypes in negTokenInit is not optional. 725 * negResult is not optional in the negTokenResp token. 726 * Two MIC tokens are exchanged, one in each direction. 727 * If the selected mechanism is also the most preferred mechanism 728 for both peers, it is safe to omit the MIC tokens. 730 If at least one of the two peers implements the pseudo mechanism 731 in this document, the negotiation is protected. 733 The following changes are to address the problems in RFC 2478. 735 * reqFlags is not protected therefore it should not impact the 736 negotiation. 737 * DER encoding is required. 738 * GSS_GetMIC() input is clarified. 739 * Per-message integrity services are requested for the negotiated 740 mechanism. 742 Intellectual Property Statement 744 The IETF takes no position regarding the validity or scope of any 745 Intellectual Property Rights or other rights that might be claimed to 746 pertain to the implementation or use of the technology described in 747 this document or the extent to which any license under such rights 748 might or might not be available; nor does it represent that it has 749 made any independent effort to identify any such rights. Information 750 on the procedures with respect to rights in RFC documents can be 751 found in BCP 78 and BCP 79. 753 Copies of IPR disclosures made to the IETF Secretariat and any 754 assurances of licenses to be made available, or the result of an 755 attempt made to obtain a general license or permission for the use of 756 such proprietary rights by implementers or users of this 757 specification can be obtained from the IETF on-line IPR repository at 758 http://www.ietf.org/ipr. 760 The IETF invites any interested party to bring to its attention any 761 copyrights, patents or patent applications, or other proprietary 762 rights that may cover technology that may be required to implement 763 this standard. Please address the information to the IETF at 764 ietf-ipr@ietf.org. 766 Disclaimer of Validity 768 This document and the information contained herein are provided on an 769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 771 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 772 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 773 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 776 Copyright Statement 778 Copyright (C) The Internet Society (2004). This document is subject 779 to the rights, licenses and restrictions contained in BCP 78, and 780 except as set forth therein, the authors retain all their rights. 782 Acknowledgment 784 Funding for the RFC Editor function is currently provided by the 785 Internet Society.