idnits 2.17.1 draft-ietf-kitten-2478bis-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 907. ** 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 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. 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 (December 15, 2004) is 7071 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 882 -- Looks like a reference, but probably isn't: '1' on line 418 -- Looks like a reference, but probably isn't: '2' on line 420 -- Looks like a reference, but probably isn't: '3' on line 421 -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Obsolete informational reference (is this intentional?): RFC 2478 (Obsoleted by RFC 4178) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft P. Leach 4 Obsoletes: 2478 (if approved) K. Jaganathan 5 Expires: June 15, 2005 Microsoft Corporation 6 W. Ingersoll 7 Sun Microsystems 8 December 15, 2004 10 The Simple and Protected GSS-API Negotiation Mechanism 11 draft-ietf-kitten-2478bis-04 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 15, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document specifies a negotiation mechanism for the Generic 47 Security Service Application Program Interface (GSS-API) which is 48 described in RFC 2743. 50 GSS-API peers can use this negotiation mechanism to choose from a 51 common set of security mechanisms. 53 If per-message integrity services are available on the established 54 mechanism context, then the negotiation is protected against an 55 attacker forcing the selection of a mechanism not desired by the 56 peers. 58 This mechanism replaces RFC 2478 in order to fix defects in that 59 specification and to describe how to interoperate with 60 implementations of that specification commonly deployed on the 61 Internet. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 67 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6 68 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6 69 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7 70 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10 72 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11 74 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12 75 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14 76 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 82 10.2 Informative References . . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 84 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 23 85 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23 86 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23 87 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 25 88 C. mechListMIC Computation Example . . . . . . . . . . . . . . . 27 89 Intellectual Property and Copyright Statements . . . . . . . . 28 91 1. Introduction 93 The GSS-API [RFC2743] provides a generic interface which can be 94 layered atop different security mechanisms such that if communicating 95 peers acquire GSS-API credentials for the same security mechanism, 96 then a security context may be established between them (subject to 97 policy). However, GSS-API does not prescribe the method by which 98 GSS-API peers can establish whether they have a common security 99 mechanism. 101 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 102 defined here is a pseudo security mechanism, represented by the 103 Object Identifier iso.org.dod.internet.security.mechanism.snego 104 (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band 105 whether their credentials support a common set of one or more GSS-API 106 security mechanisms, and if so, to invoke the normal security context 107 establishment for a selected common security mechanism. This is most 108 useful for applications which depend on GSS-API implementations and 109 share multiple mechanisms between the peers. 111 The SPNEGO mechanism negotiation is based on the following model: the 112 initiator proposes a list of security mechanism(s), in decreasing 113 preference order (favorite choice first), the acceptor (also known as 114 the target) either accepts the initiator's preferred security 115 mechanism (the first in the list), or chooses one that is available 116 from the offered list, or rejects the proposed value(s). The target 117 then informs the initiator of its choice. 119 Once a common security mechanism is chosen, mechanism-specific 120 options MAY be negotiated as part of the selected mechanism's context 121 establishment. These negotiations (if any) are internal to the 122 mechanism and opaque to the SPNEGO protocol. As such they are 123 outside the scope of this document. 125 If per-message integrity services are available on the established 126 mechanism security context, then the negotiation is protected to 127 ensure that the mechanism list has not been modified. In cases where 128 an attacker could have materially influenced the negotiation, peers 129 exchange message integrity code (MIC) tokens to confirm the mechanism 130 list has not been modified. If no action of an attacker could have 131 materially modified the outcome of the negotiation, the exchange of 132 MIC tokens is optional (see Section 5). Allowing MIC tokens to be 133 optional in this case provides interoperability with existing 134 implementations while still protecting the negotiation. This 135 interoperability comes at the cost of increased complexity. 137 In order to avoid an extra round trip, the first context 138 establishment token of the initiator's preferred mechanism SHOULD be 139 embedded in the initial negotiation message (as defined in Section 140 4.2). (This mechanism token is referred to as the optimistic 141 mechanism token in this document.) In addition, using the optimistic 142 mechanism token allows the initiator to recover from non-fatal errors 143 encountered trying to produce the first mechanism token before a 144 mechanism can be selected. Implementations MAY omit the optimistic 145 mechanism token in cases where the likelihood of the initiator's 146 preferred mechanism not being selected by the acceptor is significant 147 given the cost of generating it. 149 SPNEGO relies on the concepts developed in the GSS-API specification 150 [RFC2743]. The negotiation data is encapsulated in context-level 151 tokens. Therefore, callers of the GSS-API do not need to be aware of 152 the existence of the negotiation tokens but only of the new 153 pseudo-security mechanism. A failure in the negotiation phase causes 154 a major status code to be returned: GSS_S_BAD_MECH. 156 2. Conventions Used in This Document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 3. Negotiation Protocol 164 When the established mechanism context provides integrity protection, 165 the mechanism negotiation can be protected. When acquiring 166 negotiated security mechanism tokens, per-message integrity services 167 are always requested by the SPNEGO mechanism. 169 When the established mechanism context supports per-message integrity 170 services, SPNEGO guarantees that the selected mechanism is mutually 171 preferred. 173 This section describes the negotiation process of this protocol. 175 3.1 Negotiation Description 177 The first negotiation token sent by the initiator contains an ordered 178 list of mechanisms in decreasing preference order (favorite mechanism 179 first), and optionally the initial mechanism token for the preferred 180 mechanism of the initiator (i.e., the first in the list). (Note that 181 the list MUST NOT contain mechanisms for which the client does not 182 have appropriate credentials.) 184 The target then processes the token from the initiator. This will 185 result in one of four possible states (as defined in Section 4.2.2) 186 being returned in the reply message: accept_completed, 187 accept_incomplete, reject, or request_mic. A reject state will 188 terminate the negotiation; an accept_completed state indicates that 189 not only was the initiator-selected mechanism acceptable to the 190 target, but also that the optimistic mechanism token was sufficient 191 to complete the authentication; an accept_incomplete state indicates 192 that further message exchange is needed but the MIC token exchange as 193 described in Section 5 is OPTIONAL; a request_mic state (this state 194 can only be present in the first reply message from the target) 195 indicates the MIC token exchange is REQUIRED if per-message integrity 196 services are available. 198 Unless the preference order is specified by the application, the 199 policy by which the target chooses a mechanism is an 200 implementation-specific local matter. In the absence of an 201 application specified preference order or other policy, the target 202 SHALL choose the first mechanism in the initiator proposed list for 203 which it has valid credentials. 205 In case of a successful negotiation, the security mechanism in the 206 first reply message represents the value suitable for the target, 207 chosen from the list offered by the initiator. 209 In case of an unsuccessful negotiation, the reject state is returned 210 and it is OPTIONAL to emit a context level negotiation token. 212 Once a mechanism has been selected, context establishment tokens 213 specific to the selected mechanism are carried within the negotiation 214 tokens. 216 Lastly, MIC tokens may be exchanged to ensure the authenticity of the 217 mechanism list received by the target. 219 To avoid conflicts with the use of MIC tokens by SPNEGO, 220 partially-established contexts MUST NOT be used for per-message 221 calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set 222 to false on return from GSS_Init_sec_context() and 223 GSS_Accept_sec_context() even if the underlying mechanism returned 224 true. 226 3.2 Negotiation Procedure 228 The basic form of the procedure assumes that per-message integrity 229 services are available on the established mechanism context, and it 230 is summarized as follows: 232 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 233 but requests that SPNEGO be used. SPNEGO can either be explicity 234 requested or accepted as the default mechanism. 236 (b) The initiator GSS-API implementation emits a negotiation token 237 containing a list of one or more security mechanisms that are 238 available based on the credentials used for this context 239 establishment, and optionally the initial mechanism token for the 240 first mechanism in the list. 242 (c) The GSS-API initiator application sends the token to the target 243 application. The GSS-API target application deposits the token by 244 invoking GSS_Accept_sec_context(). The acceptor will do one of 245 the following: 247 (I) If none of the proposed mechanisms are acceptable, the 248 negotiation SHALL be terminated. GSS_Accept_sec_context 249 indicates GSS_S_BAD_MECH. The acceptor MAY output a 250 negotiation token containing a reject state. 252 (II) If either the initiator's preferred mechanism is not 253 accepted by the target or this mechanism is accepted but it 254 is not the acceptor's most preferred mechanism (i.e., the 255 MIC token exchange as described in Section 5 is required), 256 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. 258 The acceptor MUST output a negotiation token containing a 259 request_mic state. 261 (III) Otherwise if at least one additional negotiation token 262 from the initiator is needed to establish this context, 263 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and 264 outputs a negotiation token containing an accept_incomplete 265 state. 267 (IV) Otherwise no additional negotiation token from the 268 initiator is needed to establish this context, 269 GSS_Accept_sec_context() indicates GSS_S_COMPLETE and 270 outputs a negotiation token containing an accept_complete 271 state. 273 If the initiator's preferred mechanism is accepted, and an 274 optimistic mechanism token was included, this mechanism token MUST 275 be deposited to the selected mechanism by invoking 276 GSS_Accept_sec_context() and if a response mechanism token is 277 emitted, it MUST be included in the response negotiation token. 278 Otherwise, the target will not emit a response mechanism token in 279 the first reply. 281 (d) The GSS-API target application returns the negotiation token to 282 the initiator application. The GSS-API initiator application 283 deposits the token by invoking GSS_Init_sec_context(). The 284 security context initialization is then continued according to the 285 standard GSS-API conventions for the selected mechanism, where the 286 tokens of the selected mechanism are encapsulated in negotiation 287 messages (see Section 4) until the GSS_S_COMPLETE is returned for 288 both the initiator and the target by the selected security 289 mechanism. 291 (e) MIC tokens are then either skipped or exchanged according to 292 Section 5. 294 Note that the *_req_flag input parameters for context establishment 295 are relative to the selected mechanism, as are the *_state output 296 parameters. i.e., these parameters are not applicable to the 297 negotiation process per se. 299 On receipt of a negotiation token on the target side, a GSS-API 300 implementation that does not support negotiation would indicate the 301 GSS_S_BAD_MECH status as if a particular basic security mechanism had 302 been requested and was not supported. 304 When a GSS-API credential is acquired for the SPNEGO mechanism the 305 implementation SHOULD produce a credential element for the SPNEGO 306 mechanism which internally contains GSS-API credential elements for 307 all mechanisms for which the principal has credentials available, 308 except for any mechanisms which are not to be negotiated, either as 309 per implementation-, site- or application-specific policy. See 310 Appendix A for interfaces for expressing application policy. 312 4. Token Definitions 314 The type definitions in this section assume an ASN.1 module 315 definition of the following form: 317 SPNEGOASNOneSpec { 318 iso(1) identified-organization(3) dod(6) internet(1) 319 security(5) mechanism(5) snego (2) modules(4) spec2(2) 320 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 322 -- rest of definitions here 324 END 326 This specifies that the tagging context for the module will be 327 explicit and non-automatic. 329 The encoding of SPNEGO protocol messages shall obey the Distinguished 330 Encoding Rules (DER) of ASN.1 as described in [X690]. 332 4.1 Mechanism Types 334 In this negotiation model, each OID represents one GSS-API mechanism 335 or one variant (see Section 6) of it according to [RFC2743]. 337 MechType ::= OBJECT IDENTIFIER 338 -- OID represents each security mechanism as suggested by 339 -- [RFC2743] 341 MechTypeList ::= SEQUENCE OF MechType 343 4.2 Negotiation Tokens 345 The syntax of the initial negotiation tokens follows the 346 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 347 SPNEGO pseudo mechanism is identified by the Object Identifier 348 specified in Section 1. Subsequent tokens MUST NOT be encapsulated 349 in this GSS-API generic token framing. 351 This section specifies the syntax of the inner token for the initial 352 message and the syntax of subsequent context establishment tokens. 354 NegotiationToken ::= CHOICE { 355 negTokenInit [0] NegTokenInit, 356 negTokenResp [1] negTokenResp 357 } 359 4.2.1 negTokenInit 361 NegTokenInit ::= SEQUENCE { 362 mechTypes [0] MechTypeList, 363 reqFlags [1] ContextFlags OPTIONAL, 364 -- maintained from RFC 2478 for backward compatibility, 365 -- RECOMMENDED to be left out 366 mechToken [2] OCTET STRING OPTIONAL, 367 mechListMIC [3] OCTET STRING OPTIONAL, 368 ... 369 } 370 ContextFlags ::= BIT STRING { 371 delegFlag (0), 372 mutualFlag (1), 373 replayFlag (2), 374 sequenceFlag (3), 375 anonFlag (4), 376 confFlag (5), 377 integFlag (6) 378 } 380 This is the syntax for the inner token of the initial negotiation 381 message. 383 mechTypes 385 This field contains one or more security mechanisms available 386 for the initiator in decreasing preference order (favorite 387 choice first). 389 reqFlags 391 This field, if present, contains the service options that are 392 requested to establish the context. The context flags SHOULD 393 be filled in from the req_flags parameter of 394 GSS_Init_sec_context(). This field SHALL NOT have impact on 395 the negotiation. 397 mechToken 399 This field, if present, contains the optimistic mechanism 400 token. 402 mechlistMIC 404 This field, if present, contains a MIC token for the mechanism 405 list in the initial negotiation message. This MIC token is 406 computed according to Section 5. 408 4.2.2 negTokenResp 410 NegTokenResp ::= SEQUENCE { 411 negState [0] ENUMERATED { 412 accept_completed (0), 413 accept_incomplete (1), 414 reject (2), 415 request_mic (3) 416 } OPTIONAL, 417 -- REQUIRED in the first reply from the target 418 supportedMech [1] MechType OPTIONAL, 419 -- present only in the first reply from the target 420 responseToken [2] OCTET STRING OPTIONAL, 421 mechListMIC [3] OCTET STRING OPTIONAL, 422 ... 423 } 425 This is the syntax for all subsequent negotiation messages. 427 negState 429 This field, if present, contains the state of the negotiation. 430 This can be: 432 accept_completed 434 No further negotiation message from the peer is expected, 435 and the security context is established for the sender. 437 accept_incomplete 439 At least one more negotiation message from the peer is 440 needed to establish the security context. 442 reject 444 The sender terminates the negotiation. 446 request_mic 448 The sender indicates that the exchange of MIC tokens, as 449 described in Section 5, will be REQUIRED if per-message 450 integrity services are available on the mechanism context to 451 be established. This value SHALL only be present in the 452 first reply from the target. 454 This field is REQUIRED in the first reply from the target, and 455 it is OPTIONAL thereafter. When negState is absent the actual 456 state should be inferred from the state of the negotiated 457 mechanism context. 459 supportedMech 461 This field SHALL only be present in the first reply from the 462 target. It MUST be one of the mechanism(s) offered by the 463 initiator. 465 ResponseToken 467 This field, if present, contains tokens specific to the 468 mechanism selected. 470 mechlistMIC 472 This field, if present, contains a MIC token for the mechanism 473 list in the initial negotiation message. This MIC token is 474 computed according to Section 5. 476 5. Processing of mechListMIC 478 If the mechanism selected by the negotiation does not support 479 integrity protection, then no mechlistMIC token is used. 481 Otherwise, if the accepted mechanism is the most preferred mechanism 482 of both the initiator and the acceptor, then the MIC token exchange, 483 as described later in this section, is OPTIONAL. A mechanism is the 484 acceptor's most preferred mechanism if there is no other mechanism 485 which, had it been present in the mechanism list, the acceptor would 486 have preferred over the accepted mechanism. 488 In all other cases, MIC tokens MUST be exchanged after the mechanism 489 context is fully established. 491 a) The mechlistMIC token (or simply the MIC token) is computed over 492 the mechanism list in the initial negotiation message by invoking 493 GSS_GetMIC() as follows: the input context_handle is the 494 established mechanism context, the input qop_req is 0, and the 495 input message is the DER encoding of the value of type 496 MechTypeList which is contained in the "mechTypes" field of the 497 NegTokenInit. The input message is NOT the DER encoding of the 498 type "[0] MechTypeList". 500 b) If the selected mechanism exchanges an even number of mechanism 501 tokens (i.e., the acceptor sends the last mechanism token), the 502 acceptor does the following when emitting the negotiation message 503 containing the last mechanism token: if the MIC token exchange is 504 optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE 505 and does not include a mechlistMIC token, or indicates 506 GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an 507 accept_incomplete state; if the MIC token exchange is required, 508 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and 509 includes a mechlistMIC token. Acceptors that wish to be 510 compatible with legacy Windows SPNEGO implementations as described 511 in Appendix B should not generate a mechlistMIC token when the MIC 512 token exchange is not required. The initiator then processes the 513 last mechanism token, and does one of the following: 515 (I) If a mechlistMIC token was included, and is correctly 516 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 517 output negotiation message contains a mechlistMIC token, and an 518 accept_complete state. The acceptor MUST then verify this 519 mechlistMIC token. 521 (II) If a mechlistMIC token was included but is incorrect, the 522 negotiation SHALL be terminated. GSS_Init_sec_context() 523 indicates GSS_S_DEFECTIVE_TOKEN. 525 (III) If no mechlistMIC token was included, and the MIC token 526 exchange is not required, GSS_Init_sec_context() indicates 527 GSS_S_COMPLETE with no output token. 529 (IV) If no mechlistMIC token was included, but the MIC token 530 exchange is required, the negotiation SHALL be terminated. 531 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 533 c) In the case that the chosen mechanism exchanges an odd number of 534 mechanism tokens (i.e., the initiator sends the last mechanism 535 token), the initiator does the following when emitting the 536 negotiation message containing the last mechanism token: if the 537 negState was request_mic in the first reply from the target, a 538 mechlistMIC token MUST be included, otherwise the mechlistMIC 539 token is OPTIONAL. (Note that the MIC token exchange is required 540 if a mechanism other than the initiator's first choice is chosen.) 541 In the case that the optimistic mechanism token is the only 542 mechanism token for the initiator's preferred mechanism, the 543 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC 544 token is included, GSS_Init_sec_context() indicates 545 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with 546 legacy Windows SPNEGO implementations as described in Appendix B 547 should not generate a mechlistMIC token when the MIC token 548 exchange is not required. The acceptor then processes the last 549 mechanism token and does one of the following: 551 (I) If a mechlistMIC token was included and is correctly verified, 552 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 553 negotiation message contains a mechlistMIC token and an 554 accept_complete state. The initiator MUST then verify this 555 mechlistMIC token. 557 (II) If a mechlistMIC token was included but is incorrect, the 558 negotiation SHALL be terminated. GSS_Accept_sec_context() 559 indicates GSS_S_DEFECTIVE_TOKEN. 561 (III) If no mechlistMIC token was included but the mechlistMIC 562 token exchange is not required, GSS_Accept_sec_context() 563 indicates GSS_S_COMPLETE. The output negotiation message 564 contains an accept_complete state. 566 (IV) In the case that the optimistic mechanism token is also the 567 last mechanism token (when the initiator's preferred mechanism 568 is accepted by the target) and the target sends a request_mic 569 state but the initiator did not send a mechlistMIC token, the 570 target then MUST include a mechlistMIC token in that first 571 reply. GSS_Accept_sec_context() indicates 572 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 573 mechlistMIC token and generate a mechlistMIC token to send back 574 to the target. The target SHALL in turn verify the returned 575 mechlistMIC token and complete the negotiation. 577 (V) If no mechlistMIC token was included and the acceptor sent a 578 request_mic state in the first reply message (the exchange of 579 MIC tokens is required), the negotiation SHALL be terminated. 580 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 582 6. Extensibility 584 Two mechanisms are provided for extensibility. First, the ASN.1 585 structures in this specification MAY be expanded by IETF standards 586 action. Implementations receiving unknown fields MUST ignore these 587 fields. 589 Secondly, OIDs corresponding to a desired mechanism attribute (i.e., 590 mechanism variants) may be included in the set of preferred 591 mechanisms by an initiator. The acceptor can choose to honor this 592 request by preferring mechanisms that have the included attributes. 593 Future work within the Kitten working group is expected to 594 standardize common attributes that SPNEGO mechanisms may wish to 595 support. At this time it is sufficient to say that initiators MAY 596 include OIDs that do not correspond to mechanisms. Such OIDs MAY 597 influence the acceptor's choice of mechanism. As discussed in 598 Section 5, if there are mechanisms that if present in the initiator's 599 list of mechanisms might be preferred by the acceptor to the 600 initiator's preferred mechanism, the acceptor MUST demand the MIC 601 token exchange. As a consequence, acceptors MUST demand the MIC 602 token exchange if they support negotiation of attributes not 603 available in the initiator's preferred mechanism regardless of 604 whether the initiator actually requested these attributes. 606 7. Security Considerations 608 In order to produce the MIC token for the mechanism list, the 609 mechanism must provide integrity protection. When the selected 610 mechanism does not support integrity protection, the negotiation is 611 vulnerable: an active attacker can force it to use a security 612 mechanism that is not mutually preferred but is acceptable to the 613 target. 615 This protocol provides the following guarantees when per-message 616 integrity services are available on the established mechanism context 617 and the mechanism list was altered by an adversary such that a 618 mechanism which is not mutually preferred could be selected: 620 a) If the last mechanism token is sent by the initiator, both peers 621 shall fail; 622 b) If the last mechanism token is sent by the acceptor, the acceptor 623 shall not complete and the initiator at worst shall complete with 624 its preferred mechanism being selected. 626 The negotiation may not be terminated if an alteration was made but 627 it had no material impact. 629 The protection of the negotiation depends on the strength of the 630 integrity protection. In particular, the strength of SPNEGO is no 631 stronger than the integrity protection of the weakest mechanism 632 acceptable to GSS-API peers. 634 In all cases, the communicating peers are exposed to the denial of 635 service threat. 637 8. IANA Considerations 639 This document has no actions for IANA. 641 9. Acknowledgments 643 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 644 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments 645 and suggestions during development of this document. 647 Luke Howard provided a prototype of this protocol in Heimdal and 648 resolved several issues in the initial draft. 650 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 651 [RFC2478] of which some of the text has been retained in this 652 document. 654 10. References 656 10.1 Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 [RFC2743] Linn, J., "Generic Security Service Application Program 662 Interface Version 2, Update 1", RFC 2743, January 2000. 664 [X690] ASN.1 encoding rules: Specification of Basic Encoding 665 Rules (BER), Canonical Encoding Rules (CER) and 666 Distinguished Encoding Rules (DER), ITU-T Recommendation 667 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 669 10.2 Informative References 671 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 672 Negotiation Mechanism", RFC 2478, December 1998. 674 Authors' Addresses 676 Larry Zhu 677 Microsoft Corporation 678 One Microsoft Way 679 Redmond, WA 98052 680 US 682 EMail: lzhu@microsoft.com 684 Paul Leach 685 Microsoft Corporation 686 One Microsoft Way 687 Redmond, WA 98052 688 US 690 EMail: paulle@microsoft.com 692 Karthik Jaganathan 693 Microsoft Corporation 694 One Microsoft Way 695 Redmond, WA 98052 696 US 698 EMail: karthikj@microsoft.com 699 Wyllys Ingersoll 700 Sun Microsystems 701 1775 Wiehle Avenue, 2nd Floor 702 Reston, VA 20190 703 US 705 EMail: wyllys.ingersoll@sun.com 707 Appendix A. GSS-API Negotiation Support API 709 In order to provide to a GSS-API caller (either the initiator or the 710 target or both) the ability to choose among the set of supported 711 mechanisms a reduced set of mechanisms for negotiation, two 712 additional APIs are defined: 714 o GSS_Get_neg_mechs() indicates the set of security mechanisms 715 available on the local system to the caller for negotiation, for 716 which appropriate credentials are available. 717 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 718 used on the local system by the caller for negotiation, for the 719 given credentials. 721 A.1 GSS_Set_neg_mechs call 723 Inputs: 725 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 726 -- credentials 727 o mech_set SET OF OBJECT IDENTIFIER 729 Outputs: 731 o major_status INTEGER, 732 o minor_status INTEGER 734 Return major_status codes: 736 o GSS_S_COMPLETE indicates that the set of security mechanisms 737 available for negotiation has been set to mech_set. 738 o GSS_S_FAILURE indicates that the requested operation could not be 739 performed for reasons unspecified at the GSS-API level. 741 Allows callers to specify the set of security mechanisms that may be 742 negotiated with the credential identified by cred_handle. This call 743 is intended for support of specialized callers who need to restrict 744 the set of negotiable security mechanisms from the set of all 745 security mechanisms available to the caller (based on available 746 credentials). Note that if more than one mechanism is specified in 747 mech_set, the order in which those mechanisms are specified implies a 748 relative preference. 750 A.2 GSS_Get_neg_mechs call 752 Input: 754 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 755 -- credentials 757 Outputs: 759 o major_status INTEGER, 760 o minor_status INTEGER, 761 o mech_set SET OF OBJECT IDENTIFIER 763 Return major_status codes: 765 o GSS_S_COMPLETE indicates that the set of security mechanisms 766 available for negotiation has been returned in mech_set. 767 o GSS_S_FAILURE indicates that the requested operation could not be 768 performed for reasons unspecified at the GSS-API level. 770 Allows callers to determine the set of security mechanisms available 771 for negotiation with the credential identified by cred_handle. This 772 call is intended for support of specialized callers who need to 773 reduce the set of negotiable security mechanisms from the set of 774 supported security mechanisms available to the caller (based on 775 available credentials). 777 Note: The GSS_Indicate_mechs() function indicates the full set of 778 mechanism types available on the local system. Since this call has 779 no input parameter, the returned set is not necessarily available for 780 all credentials. 782 Appendix B. Changes since RFC2478 784 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 785 2003 have the following behavior: no mechlistMIC is produced and 786 mechlistMIC is not processed if one is provided; if the initiator 787 sends the last mechanism token, the acceptor will send back a 788 negotiation token with an accept_complete state and no mechlistMIC 789 token. In addition, an incorrect OID (1.2.840.48018.1.2.2) can be 790 used to identify the GSS-API Kerberos Version 5 mechanism. 792 The following changes have been made to be compatible with these 793 legacy implementations. 795 * NegTokenTarg is changed to negTokenResp and it is the message 796 format for all subsequent negotiation tokens. 797 * NegTokenInit is the message for the initial negotiation message 798 and that message only. 799 * mechTypes in negTokenInit is not optional. 800 * If the selected mechanism is also the most preferred mechanism 801 for both peers, it is safe to omit the MIC tokens. 803 If at least one of the two peers implements the updated pseudo 804 mechanism in this document, the negotiation is protected. 806 The following changes are to address the problems in RFC 2478. 808 * reqFlags is not protected therefore it should not impact the 809 negotiation. 810 * DER encoding is required. 811 * GSS_GetMIC() input is clarified. 812 * Per-message integrity services are requested for the negotiated 813 mechanism. 814 * Two MIC tokens are exchanged, one in each direction. 816 An implementation that conforms to this specification will not 817 interoperate with a strict 2748 implementation. Even if the new 818 implementation always sends a mechlistMIC token, it will still fail 819 to interoperate. If it is a server, it will fail because it requests 820 a mechlistMIC token using an option that older implementations simply 821 do not support. Clients will tend to fail as well. 823 As an alternative to the approach chosen in this specification, we 824 could have documented a correct behavior that is fully backward 825 compatible with RFC 2478 and included an appendix on how to 826 interoperate with existing incorrect implementations of RFC 2478. 828 As a practical matter, the SPNEGO implementers within the IETF have 829 valued interoperability with the Microsoft implementations. We were 830 unable to choose to maintain reasonable security guarantees, maintain 831 interoperability with the Microsoft implementations and maintain 832 interoperability with correct implementations of RFC 2478. The 833 working group was not aware of any RFC 2478 implementations deployed 834 on the Internet. Even if there are such implementations, it is 835 unlikely that they will interoperate because of a critical flaw in 836 the description of the encoding of the mechanism list in RFC 2478. 838 With the approach taken in this specification, security is ensured 839 between new implementations all the time while maintaining 840 interoperability with the implementations deployed within the IETF 841 community. The working group believes that this justifies breaking 842 compatibility with a correct implementation of RFC 2478. 844 Appendix C. mechListMIC Computation Example 846 The following is an example to illustrate how the mechListMIC field 847 would be computed. 849 The initial part of the DER encoding of NegTokenInit is constructed 850 as follows (the "nn" are length encodings, possibly longer than one 851 octet): 853 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) 854 nn -- length 856 -- contents octets of the SEQUENCE begin with 857 -- DER encoding of "[0] MechTypeList": 858 A0 -- identifier octet for constructed [0] 859 nn -- length 861 -- contents of the constructed [0] are DER encoding 862 -- of MechTypeList (which is a SEQUENCE): 863 30 -- identifier octet for constructed SEQUENCE 864 nn -- length 866 -- contents octets of the SEQUENCE begin with 867 -- DER encoding of OBJECT IDENTIFIER: 868 06 -- identifier octet for primitive OBJECT IDENTIFIER 869 09 -- length 870 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 871 -- {1 2 840 113554 1 2 2} 873 If a mechlistMIC needs to be generated (according to the rules in 874 Section 5), it is computed by using the DER encoding of the type 875 MechTypeList data from the initiator's NegTokenInit token as input to 876 the GSS_GetMIC() function. In this case, the MIC would be computed 877 over the following octets: 879 DER encoding of MechTypeList: 880 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... 882 Note that the identifier octet and lengh octet(s) for constructed [0] 883 (A0 nn) are not included in the MIC computation. 885 Intellectual Property Statement 887 The IETF takes no position regarding the validity or scope of any 888 Intellectual Property Rights or other rights that might be claimed to 889 pertain to the implementation or use of the technology described in 890 this document or the extent to which any license under such rights 891 might or might not be available; nor does it represent that it has 892 made any independent effort to identify any such rights. Information 893 on the procedures with respect to rights in RFC documents can be 894 found in BCP 78 and BCP 79. 896 Copies of IPR disclosures made to the IETF Secretariat and any 897 assurances of licenses to be made available, or the result of an 898 attempt made to obtain a general license or permission for the use of 899 such proprietary rights by implementers or users of this 900 specification can be obtained from the IETF on-line IPR repository at 901 http://www.ietf.org/ipr. 903 The IETF invites any interested party to bring to its attention any 904 copyrights, patents or patent applications, or other proprietary 905 rights that may cover technology that may be required to implement 906 this standard. Please address the information to the IETF at 907 ietf-ipr@ietf.org. 909 Disclaimer of Validity 911 This document and the information contained herein are provided on an 912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 914 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 915 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 916 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 919 Copyright Statement 921 Copyright (C) The Internet Society (2004). This document is subject 922 to the rights, licenses and restrictions contained in BCP 78, and 923 except as set forth therein, the authors retain all their rights. 925 Acknowledgment 927 Funding for the RFC Editor function is currently provided by the 928 Internet Society.