idnits 2.17.1 draft-ietf-kitten-2478bis-03.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 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 902. ** 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 14, 2004) is 7065 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 877 -- Looks like a reference, but probably isn't: '1' on line 414 -- Looks like a reference, but probably isn't: '2' on line 416 -- Looks like a reference, but probably isn't: '3' on line 417 -- 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 14, 2005 Microsoft Corporation 6 W. Ingersoll 7 Sun Microsystems 8 December 14, 2004 10 The Simple and Protected GSS-API Negotiation Mechanism 11 draft-ietf-kitten-2478bis-03 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 14, 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 (see 199 Appendix A), the 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 until the 287 GSS_S_COMPLETE is returned for both the initiator and the target 288 by the selected security mechanism. 290 (e) MIC tokens are then either skipped or exchanged according to 291 Section 5. 293 Note that the *_req_flag input parameters for context establishment 294 are relative to the selected mechanism, as are the *_state output 295 parameters. i.e., these parameters are not applicable to the 296 negotiation process per se. 298 On receipt of a negotiation token on the target side, a GSS-API 299 implementation that does not support negotiation would indicate the 300 GSS_S_BAD_MECH status as if a particular basic security mechanism had 301 been requested and was not supported. 303 When GSS_Acquire_cred is invoked with this negotiation mechanism in 304 the desired_mechs, an implementation-specific default credential is 305 used to carry on the negotiation. A set of mechanisms as specified 306 locally by the system administrator is then available for 307 negotiation. If there is a desire for the caller to make its own 308 choice, then an additional API has to be used (see Appendix A). 310 4. Token Definitions 312 The type definitions in this section assume an ASN.1 module 313 definition of the following form: 315 SPNEGOASNOneSpec { 316 iso(1) identified-organization(3) dod(6) internet(1) 317 security(5) mechanism(5) snego (2) modules(4) spec2(2) 318 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 320 -- rest of definitions here 322 END 324 This specifies that the tagging context for the module will be 325 explicit and non-automatic. 327 The encoding of SPNEGO protocol messages shall obey the Distinguished 328 Encoding Rules (DER) of ASN.1 as described in [X690]. 330 4.1 Mechanism Types 332 In this negotiation model, each OID represents one GSS-API mechanism 333 or one variant (see Section 6) of it according to [RFC2743]. 335 MechType ::= OBJECT IDENTIFIER 336 -- OID represents each security mechanism as suggested by 337 -- [RFC2743] 339 MechTypeList ::= SEQUENCE OF MechType 341 4.2 Negotiation Tokens 343 The syntax of the initial negotiation tokens follows the 344 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 345 SPNEGO pseudo mechanism is identified by the Object Identifier 346 specified in Section 1. Subsequent tokens are not encapsulated in 347 this GSS-API generic token framing. 349 This section specifies the syntax of the inner token for the initial 350 message and the syntax of subsequent context establishment tokens. 352 NegotiationToken ::= CHOICE { 353 negTokenInit [0] NegTokenInit, 354 negTokenResp [1] negTokenResp 355 } 357 4.2.1 negTokenInit 359 NegTokenInit ::= SEQUENCE { 360 mechTypes [0] MechTypeList, 361 reqFlags [1] ContextFlags OPTIONAL, 362 mechToken [2] OCTET STRING OPTIONAL, 363 mechListMIC [3] OCTET STRING OPTIONAL, 364 ... 365 } 366 ContextFlags ::= BIT STRING { 367 delegFlag (0), 368 mutualFlag (1), 369 replayFlag (2), 370 sequenceFlag (3), 371 anonFlag (4), 372 confFlag (5), 373 integFlag (6) 374 } 376 This is the syntax for the inner token of the initial negotiation 377 message. 379 mechTypes 381 This field contains one or more security mechanisms available 382 for the initiator in decreasing preference order (favorite 383 choice first). 385 reqFlags 387 This field, if present, contains the service options that are 388 requested to establish the context. The context flags SHOULD 389 be filled in from the req_flags parameter of 390 GSS_Init_sec_context(). This field SHALL NOT have impact on 391 the negotiation. 393 mechToken 395 This field, if present, contains the optimistic mechanism 396 token. 398 mechlistMIC 400 This field, if present, contains a MIC token for the mechanism 401 list in the initial negotiation message. This MIC token is 402 computed according to Section 5. 404 4.2.2 negTokenResp 406 NegTokenResp ::= SEQUENCE { 407 negState [0] ENUMERATED { 408 accept_completed (0), 409 accept_incomplete (1), 410 reject (2), 411 request_mic (3) 412 } OPTIONAL, 413 -- REQUIRED in the first reply from the target 414 supportedMech [1] MechType OPTIONAL, 415 -- present only in the first reply from the target 416 responseToken [2] OCTET STRING OPTIONAL, 417 mechListMIC [3] OCTET STRING OPTIONAL, 418 ... 419 } 421 This is the syntax for all subsequent negotiation messages. 423 negState 425 This field, if present, contains the state of the negotiation. 426 This can be: 428 accept_completed 430 No further negotiation message from the peer is expected, 431 and the security context is established for the sender. 433 accept_incomplete 435 At least one more negotiation message from the peer is 436 needed to establish the security context. 438 reject 440 The sender terminates the negotiation. 442 request_mic 444 The sender indicates that the exchange of MIC tokens, as 445 described in Section 5, will be REQUIRED if per-message 446 integrity services are available on the mechanism context to 447 be established. This value SHALL only be present in the 448 first reply from the target. 450 This field is REQUIRED in the first reply from the target, and 451 it is OPTIONAL thereafter. 453 supportedMech 455 This field SHALL only be present in the first reply from the 456 target. It MUST be one of the mechanism(s) offered by the 457 initiator. 459 ResponseToken 461 This field, if present, contains tokens specific to the 462 mechanism selected. 464 mechlistMIC 466 This field, if present, contains a MIC token for the mechanism 467 list in the initial negotiation message. This MIC token is 468 computed according to Section 5. 470 5. Processing of mechListMIC 472 If the mechanism selected by the negotiation does not support 473 integrity protection, then no mechlistMIC token is used. 475 Otherwise, if the accepted mechanism is the most preferred mechanism 476 of both the initiator and the acceptor, then the MIC token exchange, 477 as described later in this section, is OPTIONAL. A mechanism is the 478 acceptor's most preferred mechanism if there is no other mechanism 479 which, had it been present in the mechanism list, the acceptor would 480 have preferred over the accepted mechanism. 482 In all other cases, MIC tokens MUST be exchanged after the mechanism 483 context is fully established. 485 a) The mechlistMIC token (or simply the MIC token) is computed over 486 the mechanism list in the initial negotiation message by invoking 487 GSS_GetMIC() as follows: the input context_handle is the 488 established mechanism context, the input qop_req is 0, and the 489 input message is the DER encoding of the value of type 490 MechTypeList which is contained in the "mechTypes" field of the 491 NegTokenInit. The input message is NOT the DER encoding of the 492 type "[0] MechTypeList". 494 b) If the selected mechanism exchanges an even number of mechanism 495 tokens (i.e., the acceptor sends the last mechanism token), the 496 acceptor does the following when emitting the negotiation message 497 containing the last mechanism token: if the MIC token exchange is 498 optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE 499 and does not include a mechlistMIC token, or indicates 500 GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an 501 accept_incomplete state; if the MIC token exchange is required, 502 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and 503 includes a mechlistMIC token. Acceptors that wish to be 504 compatible with legacy Windows SPNEGO implementations as described 505 in Appendix B should not generate a mechlistMIC token when the MIC 506 token exchange is not required. The initiator then processes the 507 last mechanism token, and does one of the following: 509 (I) If a mechlistMIC token was included, and is correctly 510 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 511 output negotiation message contains a mechlistMIC token, and an 512 accept_complete state. The acceptor MUST then verify this 513 mechlistMIC token. 515 (II) If a mechlistMIC token was included but is incorrect, the 516 negotiation SHALL be terminated. GSS_Init_sec_context() 517 indicates GSS_S_DEFECTIVE_TOKEN. 519 (III) If no mechlistMIC token was included, and the MIC token 520 exchange is not required, GSS_Init_sec_context() indicates 521 GSS_S_COMPLETE with no output token. 523 (IV) If no mechlistMIC token was included, but the MIC token 524 exchange is required, the negotiation SHALL be terminated. 525 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 527 c) In the case that the chosen mechanism exchanges an odd number of 528 mechanism tokens (i.e., the initiator sends the last mechanism 529 token), the initiator does the following when emitting the 530 negotiation message containing the last mechanism token: if the 531 negState was request_mic in the first reply from the target, a 532 mechlistMIC token MUST be included, otherwise the mechlistMIC 533 token is OPTIONAL. (Note that the MIC token exchange is required 534 if a mechanism other than the initiator's first choice is chosen.) 535 In the case that the optimistic mechanism token is the only 536 mechanism token for the initiator's preferred mechanism, the 537 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC 538 token is included, GSS_Init_sec_context() indicates 539 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with 540 legacy Windows SPNEGO implementations as described in Appendix B 541 should not generate a mechlistMIC token when the MIC token 542 exchange is not required. The acceptor then processes the last 543 mechanism token and does one of the following: 545 (I) If a mechlistMIC token was included and is correctly verified, 546 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 547 negotiation message contains a mechlistMIC token and an 548 accept_complete state. The initiator MUST then verify this 549 mechlistMIC token. 551 (II) If a mechlistMIC token was included but is incorrect, the 552 negotiation SHALL be terminated. GSS_Accept_sec_context() 553 indicates GSS_S_DEFECTIVE_TOKEN. 555 (III) If no mechlistMIC token was included but the mechlistMIC 556 token exchange is not required, GSS_Accept_sec_context() 557 indicates GSS_S_COMPLETE. The output negotiation message 558 contains an accept_complete state. 560 (IV) In the case that the optimistic mechanism token is also the 561 last mechanism token (when the initiator's preferred mechanism 562 is accepted by the target) and the target sends a request_mic 563 state but the initiator did not send a mechlistMIC token, the 564 target then MUST include a mechlistMIC token in that first 565 reply. GSS_Accept_sec_context() indicates 566 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 567 mechlistMIC token and generate a mechlistMIC token to send back 568 to the target. The target SHALL in turn verify the returned 569 mechlistMIC token and complete the negotiation. 571 (V) If no mechlistMIC token was included and the acceptor sent a 572 request_mic state in the first reply message (the exchange of 573 MIC tokens is required), the negotiation SHALL be terminated. 574 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 576 6. Extensibility 578 Two mechanisms are provided for extensibility. First, the ASN.1 579 structures in this specification MAY be expanded by IETF standards 580 action. Implementations receiving unknown fields MUST ignore these 581 fields. 583 Secondly, OIDs corresponding to a desired mechanism attribute (i.e., 584 mechanism variants) may be included in the set of preferred 585 mechanisms by an initiator. The acceptor can choose to honor this 586 request by preferring mechanisms that have the included attributes. 587 Future work within the Kitten working group is expected to 588 standardize common attributes that SPNEGO mechanisms may wish to 589 support. At this time it is sufficient to say that initiators MAY 590 include OIDs that do not correspond to mechanisms but instead 591 correspond to desired mechanism attributes in their requests. Such 592 OIDs MAY influence the acceptor's choice of mechanism. As discussed 593 in Section 5, if there are mechanisms that if present in the 594 initiator's list of mechanisms might be preferred by the acceptor to 595 the initiator's preferred mechanism, the acceptor MUST demand the MIC 596 token exchange. As a consequence, acceptors MUST demand the MIC 597 token exchange if they support negotiation of attributes not 598 available in the initiator's preferred mechanism regardless of 599 whether the initiator actually requested these attributes. 601 7. Security Considerations 603 In order to produce the MIC token for the mechanism list, the 604 mechanism must provide integrity protection. When the selected 605 mechanism does not support integrity protection, the negotiation is 606 vulnerable: an active attacker can force it to use a security 607 mechanism that is not mutually preferred but is acceptable to the 608 target. 610 This protocol provides the following guarantees when per-message 611 integrity services are available on the established mechanism context 612 and the mechanism list was altered by an adversary such that a 613 mechanism which is not mutually preferred could be selected: 615 a) If the last mechanism token is sent by the initiator, both peers 616 shall fail; 617 b) If the last mechanism token is sent by the acceptor, the acceptor 618 shall not complete and the initiator at worst shall complete with 619 its preferred mechanism being selected. 621 The negotiation may not be terminated if an alteration was made but 622 it had no material impact. 624 The protection of the negotiation depends on the strength of the 625 integrity protection. In particular, the strength of SPNEGO is no 626 stronger than the integrity protection of the weakest mechanism 627 acceptable to GSS-API peers. 629 In all cases, the communicating peers are exposed to the denial of 630 service threat. 632 8. IANA Considerations 634 This document has no actions for IANA. 636 9. Acknowledgments 638 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 639 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments 640 and suggestions during development of this document. 642 Luke Howard provided a prototype of this protocol in Heimdal and 643 resolved several issues in the initial draft. 645 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 646 [RFC2478] of which some of the text has been retained in this 647 document. 649 10. References 651 10.1 Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, March 1997. 656 [RFC2743] Linn, J., "Generic Security Service Application Program 657 Interface Version 2, Update 1", RFC 2743, January 2000. 659 [X690] ASN.1 encoding rules: Specification of Basic Encoding 660 Rules (BER), Canonical Encoding Rules (CER) and 661 Distinguished Encoding Rules (DER), ITU-T Recommendation 662 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 664 10.2 Informative References 666 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 667 Negotiation Mechanism", RFC 2478, December 1998. 669 Authors' Addresses 671 Larry Zhu 672 Microsoft Corporation 673 One Microsoft Way 674 Redmond, WA 98052 675 US 677 EMail: lzhu@microsoft.com 679 Paul Leach 680 Microsoft Corporation 681 One Microsoft Way 682 Redmond, WA 98052 683 US 685 EMail: paulle@microsoft.com 687 Karthik Jaganathan 688 Microsoft Corporation 689 One Microsoft Way 690 Redmond, WA 98052 691 US 693 EMail: karthikj@microsoft.com 694 Wyllys Ingersoll 695 Sun Microsystems 696 1775 Wiehle Avenue, 2nd Floor 697 Reston, VA 20190 698 US 700 EMail: wyllys.ingersoll@sun.com 702 Appendix A. GSS-API Negotiation Support API 704 In order to provide to a GSS-API caller (either the initiator or the 705 target or both) the ability to choose among the set of supported 706 mechanisms a reduced set of mechanisms for negotiation, two 707 additional APIs are defined: 709 o GSS_Get_neg_mechs() indicates the set of security mechanisms 710 available on the local system to the caller for negotiation, for 711 which appropriate credentials are available. 712 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 713 used on the local system by the caller for negotiation, for the 714 given credentials. 716 A.1 GSS_Set_neg_mechs call 718 Inputs: 720 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 721 -- credentials 722 o mech_set SET OF OBJECT IDENTIFIER 724 Outputs: 726 o major_status INTEGER, 727 o minor_status INTEGER 729 Return major_status codes: 731 o GSS_S_COMPLETE indicates that the set of security mechanisms 732 available for negotiation has been set to mech_set. 733 o GSS_S_FAILURE indicates that the requested operation could not be 734 performed for reasons unspecified at the GSS-API level. 736 Allows callers to specify the set of security mechanisms that may be 737 negotiated with the credential identified by cred_handle. This call 738 is intended for support of specialized callers who need to restrict 739 the set of negotiable security mechanisms from the set of all 740 security mechanisms available to the caller (based on available 741 credentials). Note that if more than one mechanism is specified in 742 mech_set, the order in which those mechanisms are specified implies a 743 relative preference. 745 A.2 GSS_Get_neg_mechs call 747 Input: 749 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 750 -- credentials 752 Outputs: 754 o major_status INTEGER, 755 o minor_status INTEGER, 756 o mech_set SET OF OBJECT IDENTIFIER 758 Return major_status codes: 760 o GSS_S_COMPLETE indicates that the set of security mechanisms 761 available for negotiation has been returned in mech_set. 762 o GSS_S_FAILURE indicates that the requested operation could not be 763 performed for reasons unspecified at the GSS-API level. 765 Allows callers to determine the set of security mechanisms available 766 for negotiation with the credential identified by cred_handle. This 767 call is intended for support of specialized callers who need to 768 reduce the set of negotiable security mechanisms from the set of 769 supported security mechanisms available to the caller (based on 770 available credentials). 772 Note: The GSS_Indicate_mechs() function indicates the full set of 773 mechanism types available on the local system. Since this call has 774 no input parameter, the returned set is not necessarily available for 775 all credentials. 777 Appendix B. Changes since RFC2478 779 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 780 2003 have the following behavior: no mechlistMIC is produced and 781 mechlistMIC is not processed if one is provided; if the initiator 782 sends the last mechanism token, the acceptor will send back a 783 negotiation token with an accept_complete state and no mechlistMIC 784 token. In addition, an incorrect OID (1.2.840.48018.1.2.2) can be 785 used to identify the GSS-API Kerberos Version 5 mechanism. 787 The following changes have been made to be compatible with these 788 legacy implementations. 790 * NegTokenTarg is changed to negTokenResp and it is the message 791 format for all subsequent negotiation tokens. 792 * NegTokenInit is the message for the initial negotiation message 793 and that message only. 794 * mechTypes in negTokenInit is not optional. 795 * If the selected mechanism is also the most preferred mechanism 796 for both peers, it is safe to omit the MIC tokens. 798 If at least one of the two peers implements the updated pseudo 799 mechanism in this document, the negotiation is protected. 801 The following changes are to address the problems in RFC 2478. 803 * reqFlags is not protected therefore it should not impact the 804 negotiation. 805 * DER encoding is required. 806 * GSS_GetMIC() input is clarified. 807 * Per-message integrity services are requested for the negotiated 808 mechanism. 809 * Two MIC tokens are exchanged, one in each direction. 811 An implementation that conforms to this specification will not 812 interoperate with a strict 2748 implementation. Even if the new 813 implementation always sends a mechlistMIC token, it will still fail 814 to interoperate. If it is a server, it will fail because it requests 815 a mechlistMIC token using an option that older implementations simply 816 do not support. Clients will tend to fail as well. 818 As an alternative to the approach chosen in this specification, we 819 could have documented a correct behavior that is fully backward 820 compatible with RFC 2478 and included an appendix on how to 821 interoperate with existing incorrect implementations of RFC 2478. 823 As a practical matter, the SPNEGO implementers within the IETF have 824 valued interoperability with the Microsoft implementations. We were 825 unable to choose to maintain reasonable security guarantees, maintain 826 interoperability with the Microsoft implementations and maintain 827 interoperability with correct implementations of RFC 2478. The 828 working group was not aware of any RFC 2478 implementations deployed 829 on the Internet. Even if there are such implementations, it is 830 unlikely that they will interoperate because of a critical flaw in 831 the description of the encoding of the mechanism list in RFC 2478. 833 With the approach taken in this specification, security is ensured 834 between new implementations all the time while maintaining 835 interoperability with the implementations deployed within the IETF 836 community. The working group believes that this justifies breaking 837 compatibility with a correct implementation of RFC 2478. 839 Appendix C. mechListMIC Computation Example 841 The following is an example to illustrate how the mechListMIC field 842 would be computed. 844 The initial part of the DER encoding of NegTokenInit is constructed 845 as follows (the "nn" are length encodings, possibly longer than one 846 octet): 848 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) 849 nn -- length 851 -- contents octets of the SEQUENCE begin with 852 -- DER encoding of "[0] MechTypeList": 853 A0 -- identifier octet for constructed [0] 854 nn -- length 856 -- contents of the constructed [0] are DER encoding 857 -- of MechTypeList (which is a SEQUENCE): 858 30 -- identifier octet for constructed SEQUENCE 859 nn -- length 861 -- contents octets of the SEQUENCE begin with 862 -- DER encoding of OBJECT IDENTIFIER: 863 06 -- identifier octet for primitive OBJECT IDENTIFIER 864 09 -- length 865 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 866 -- {1 2 840 113554 1 2 2} 868 If a mechlistMIC needs to be generated (according to the rules in 869 Section 5), it is computed by using the DER encoding of the type 870 MechTypeList data from the initiator's NegTokenInit token as input to 871 the GSS_GetMIC() function. In this case, the MIC would be computed 872 over the following octets: 874 DER encoding of MechTypeList: 875 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... 877 Note that the identifier octet and lengh octet(s) for constructed [0] 878 (A0 nn) are not included in the MIC computation. 880 Intellectual Property Statement 882 The IETF takes no position regarding the validity or scope of any 883 Intellectual Property Rights or other rights that might be claimed to 884 pertain to the implementation or use of the technology described in 885 this document or the extent to which any license under such rights 886 might or might not be available; nor does it represent that it has 887 made any independent effort to identify any such rights. Information 888 on the procedures with respect to rights in RFC documents can be 889 found in BCP 78 and BCP 79. 891 Copies of IPR disclosures made to the IETF Secretariat and any 892 assurances of licenses to be made available, or the result of an 893 attempt made to obtain a general license or permission for the use of 894 such proprietary rights by implementers or users of this 895 specification can be obtained from the IETF on-line IPR repository at 896 http://www.ietf.org/ipr. 898 The IETF invites any interested party to bring to its attention any 899 copyrights, patents or patent applications, or other proprietary 900 rights that may cover technology that may be required to implement 901 this standard. Please address the information to the IETF at 902 ietf-ipr@ietf.org. 904 Disclaimer of Validity 906 This document and the information contained herein are provided on an 907 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 908 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 909 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 910 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 911 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 912 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 914 Copyright Statement 916 Copyright (C) The Internet Society (2004). This document is subject 917 to the rights, licenses and restrictions contained in BCP 78, and 918 except as set forth therein, the authors retain all their rights. 920 Acknowledgment 922 Funding for the RFC Editor function is currently provided by the 923 Internet Society.