idnits 2.17.1 draft-ietf-kitten-2478bis-05.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 989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 979. ** 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 (January 23, 2005) is 7032 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 955 -- Looks like a reference, but probably isn't: '1' on line 758 -- Looks like a reference, but probably isn't: '2' on line 760 -- Looks like a reference, but probably isn't: '3' on line 761 -- 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: July 27, 2005 Microsoft Corporation 6 W. Ingersoll 7 Sun Microsystems 8 January 23, 2005 10 The Simple and Protected GSS-API Negotiation Mechanism 11 draft-ietf-kitten-2478bis-05 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 July 27, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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 inter-operate 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. SPNEGO ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 23 85 B. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 25 86 B.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25 87 B.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25 88 C. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 27 89 D. mechListMIC Computation Example . . . . . . . . . . . . . . . 29 90 Intellectual Property and Copyright Statements . . . . . . . . 30 92 1. Introduction 94 The GSS-API [RFC2743] provides a generic interface which can be 95 layered atop different security mechanisms such that if communicating 96 peers acquire GSS-API credentials for the same security mechanism, 97 then a security context may be established between them (subject to 98 policy). However, GSS-API does not prescribe the method by which 99 GSS-API peers can establish whether they have a common security 100 mechanism. 102 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 103 defined here is a pseudo security mechanism, which enables GSS-API 104 peers to determine in-band whether their credentials support a common 105 set of one or more GSS-API security mechanisms, and if so, to invoke 106 the normal security context establishment for a selected common 107 security mechanism. This is most useful for applications which 108 depend on GSS-API implementations and share multiple mechanisms 109 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 SPNEGO relies on the concepts developed in the GSS-API specification 138 [RFC2743]. The negotiation data is encapsulated in context-level 139 tokens. Therefore, callers of the GSS-API do not need to be aware of 140 the existence of the negotiation tokens but only of the new 141 pseudo-security mechanism. A failure in the negotiation phase causes 142 a major status code to be returned: GSS_S_BAD_MECH. 144 2. Conventions Used in This Document 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Negotiation Protocol 152 When the established mechanism context provides integrity protection, 153 the mechanism negotiation can be protected. When acquiring 154 negotiated security mechanism tokens, per-message integrity services 155 are always requested by the SPNEGO mechanism. 157 When the established mechanism context supports per-message integrity 158 services, SPNEGO guarantees that the selected mechanism is mutually 159 preferred. 161 This section describes the negotiation process of this protocol. 163 3.1 Negotiation Description 165 The first negotiation token sent by the initiator contains an ordered 166 list of mechanisms in decreasing preference order (favorite mechanism 167 first), and optionally the initial mechanism token for the preferred 168 mechanism of the initiator (i.e., the first in the list). (Note that 169 the list MUST NOT contain either this SPNEGO mechanism itself or any 170 mechanism for which the client does not have appropriate 171 credentials.) 173 The target then processes the token from the initiator. This will 174 result in one of four possible states (as defined in Section 4.2.2) 175 being returned in the reply message: accept-completed, 176 accept-incomplete, reject, or request-mic. A reject state will 177 terminate the negotiation; an accept-completed state indicates that 178 not only was the initiator-selected mechanism acceptable to the 179 target, but also that the security mechanism token embedded in the 180 first negotiation message was sufficient to complete the 181 authentication; an accept-incomplete state indicates that further 182 message exchange is needed but the MIC token exchange as described in 183 Section 5 is OPTIONAL; a request-mic state (this state can only be 184 present in the first reply message from the target) indicates the MIC 185 token exchange is REQUIRED if per-message integrity services are 186 available. 188 Unless the preference order is specified by the application, the 189 policy by which the target chooses a mechanism is an 190 implementation-specific local matter. In the absence of an 191 application specified preference order or other policy, the target 192 SHALL choose the first mechanism in the initiator proposed list for 193 which it has valid credentials. 195 In case of a successful negotiation, the security mechanism in the 196 first reply message represents the value suitable for the target, 197 chosen from the list offered by the initiator. 199 In case of an unsuccessful negotiation, the reject state is returned 200 and generating a context level negotiation token is OPTIONAL. 202 Once a mechanism has been selected, context establishment tokens 203 specific to the selected mechanism are carried within the negotiation 204 tokens. 206 Lastly, MIC tokens may be exchanged to ensure the authenticity of the 207 mechanism list received by the target. 209 To avoid conflicts with the use of MIC tokens by SPNEGO, 210 partially-established contexts MUST NOT be used for per-message 211 calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set 212 to false on return from GSS_Init_sec_context() and 213 GSS_Accept_sec_context() even if the underlying mechanism returned 214 true. 216 Note that in order to avoid an extra round trip, the first context 217 establishment token of the initiator's preferred mechanism SHOULD be 218 embedded in the initial negotiation message (as defined in 219 Section 4.2). (This mechanism token is referred to as the optimistic 220 mechanism token in this document.) In addition, using the optimistic 221 mechanism token allows the initiator to recover from non-fatal errors 222 encountered trying to produce the first mechanism token before a 223 mechanism can be selected. Implementations MAY omit the optimistic 224 mechanism token in cases where the likelihood of the initiator's 225 preferred mechanism not being selected by the acceptor is significant 226 given the cost of generating it. 228 3.2 Negotiation Procedure 230 The basic form of the procedure assumes that per-message integrity 231 services are available on the established mechanism context, and it 232 is summarized as follows: 234 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 235 but requests that SPNEGO be used. SPNEGO can either be explicitly 236 requested or accepted as the default mechanism. 238 (b) The initiator GSS-API implementation generates a negotiation 239 token containing a list of one or more security mechanisms that 240 are available based on the credentials used for this context 241 establishment, and optionally the initial mechanism token for the 242 first mechanism in the list. 244 (c) The GSS-API initiator application sends the token to the target 245 application. The GSS-API target application passes the token by 246 invoking GSS_Accept_sec_context(). The acceptor will do one of 247 the following: 249 (I) If none of the proposed mechanisms are acceptable, the 250 negotiation SHALL be terminated. GSS_Accept_sec_context 251 indicates GSS_S_BAD_MECH. The acceptor MAY output a 252 negotiation token containing a reject state. 254 (II) If either the initiator's preferred mechanism is not 255 accepted by the target or this mechanism is accepted but it 256 is not the acceptor's most preferred mechanism (i.e., the 257 MIC token exchange as described in Section 5 is required), 258 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. 259 The acceptor MUST output a negotiation token containing a 260 request-mic state. 262 (III) Otherwise if at least one additional negotiation token 263 from the initiator is needed to establish this context, 264 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and 265 outputs a negotiation token containing an accept-incomplete 266 state. 268 (IV) Otherwise no additional negotiation token from the 269 initiator is needed to establish this context, 270 GSS_Accept_sec_context() indicates GSS_S_COMPLETE and 271 outputs a negotiation token containing an accept_complete 272 state. 274 If the initiator's preferred mechanism is accepted, and an 275 optimistic mechanism token was included, this mechanism token MUST 276 be passed to the selected mechanism by invoking 277 GSS_Accept_sec_context() and if a response mechanism token is 278 returned, it MUST be included in the response negotiation token. 279 Otherwise, the target will not generate a response mechanism token 280 in the first reply. 282 (d) The GSS-API target application returns the negotiation token to 283 the initiator application. The GSS-API initiator application 284 passes the token by invoking GSS_Init_sec_context(). The security 285 context initialization is then continued according to the standard 286 GSS-API conventions for the selected mechanism, where the tokens 287 of the selected mechanism are encapsulated in negotiation messages 288 (see Section 4) until GSS_S_COMPLETE is returned for both the 289 initiator and the target by the selected security 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 B 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 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 349 Subsequent tokens MUST NOT be encapsulated in this GSS-API generic 350 token framing. 352 This section specifies the syntax of the inner token for the initial 353 message and the syntax of subsequent context establishment tokens. 355 NegotiationToken ::= CHOICE { 356 negTokenInit [0] NegTokenInit, 357 negTokenResp [1] NegTokenResp 358 } 360 4.2.1 negTokenInit 362 NegTokenInit ::= SEQUENCE { 363 mechTypes [0] MechTypeList, 364 reqFlags [1] ContextFlags OPTIONAL, 365 -- inherited from RFC 2478 for backward compatibility, 366 -- RECOMMENDED to be left out 367 mechToken [2] OCTET STRING OPTIONAL, 368 mechListMIC [3] OCTET STRING OPTIONAL, 369 ... 370 } 371 ContextFlags ::= BIT STRING { 372 delegFlag (0), 373 mutualFlag (1), 374 replayFlag (2), 375 sequenceFlag (3), 376 anonFlag (4), 377 confFlag (5), 378 integFlag (6) 379 } (SIZE (32)) 381 This is the syntax for the inner token of the initial negotiation 382 message. 384 mechTypes 386 This field contains one or more security mechanisms available 387 for the initiator in decreasing preference order (favorite 388 choice first). 390 reqFlags 392 This field, if present, contains the service options that are 393 requested to establish the context (the req_flags parameter of 394 GSS_Init_sec_context()). This field is inherited from RFC 2478 395 and it is not integrity protected. For implementations of this 396 specification the initiator SHOULD omit this reqFlags field, 397 and the acceptor MUST ignore this reqFlags field. 399 mechToken 401 This field, if present, contains the optimistic mechanism 402 token. 404 mechlistMIC 406 This field, if present, contains a MIC token for the mechanism 407 list in the initial negotiation message. This MIC token is 408 computed according to Section 5. 410 4.2.2 negTokenResp 412 NegTokenResp ::= SEQUENCE { 413 negState [0] ENUMERATED { 414 accept-completed (0), 415 accept-incomplete (1), 416 reject (2), 417 request-mic (3) 418 } OPTIONAL, 419 -- REQUIRED in the first reply from the target 420 supportedMech [1] MechType OPTIONAL, 421 -- present only in the first reply from the target 422 responseToken [2] OCTET STRING OPTIONAL, 423 mechListMIC [3] OCTET STRING OPTIONAL, 424 ... 425 } 427 This is the syntax for all subsequent negotiation messages. 429 negState 431 This field, if present, contains the state of the negotiation. 432 This can be: 434 accept-completed 436 No further negotiation message from the peer is expected, 437 and the security context is established for the sender. 439 accept-incomplete 441 At least one more negotiation message from the peer is 442 needed to establish the security context. 444 reject 446 The sender terminates the negotiation. 448 request-mic 450 The sender indicates that the exchange of MIC tokens, as 451 described in Section 5, will be REQUIRED if per-message 452 integrity services are available on the mechanism context to 453 be established. This value SHALL only be present in the 454 first reply from the target. 456 This field is REQUIRED in the first reply from the target, and 457 it is OPTIONAL thereafter. When negState is absent the actual 458 state should be inferred from the state of the negotiated 459 mechanism context. 461 supportedMech 463 This field SHALL only be present in the first reply from the 464 target. It MUST be one of the mechanism(s) offered by the 465 initiator. 467 ResponseToken 469 This field, if present, contains tokens specific to the 470 mechanism selected. 472 mechlistMIC 474 This field, if present, contains a MIC token for the mechanism 475 list in the initial negotiation message. This MIC token is 476 computed according to Section 5. 478 5. Processing of mechListMIC 480 If the mechanism selected by the negotiation does not support 481 integrity protection, then no mechlistMIC token is used. 483 Otherwise, if the accepted mechanism is the most preferred mechanism 484 of both the initiator and the acceptor, then the MIC token exchange, 485 as described later in this section, is OPTIONAL. A mechanism is the 486 acceptor's most preferred mechanism if there is no other mechanism 487 which, had it been present in the mechanism list, the acceptor would 488 have preferred over the accepted mechanism. 490 In all other cases, MIC tokens MUST be exchanged after the mechanism 491 context is fully established. 493 a) The mechlistMIC token (or simply the MIC token) is computed over 494 the mechanism list in the initial negotiation message by invoking 495 GSS_GetMIC() as follows: the input context_handle is the 496 established mechanism context, the input qop_req is 0, and the 497 input message is the DER encoding of the value of type 498 MechTypeList which is contained in the "mechTypes" field of the 499 NegTokenInit. The input message is NOT the DER encoding of the 500 type "[0] MechTypeList". 502 b) If the selected mechanism exchanges an even number of mechanism 503 tokens (i.e., the acceptor sends the last mechanism token), the 504 acceptor does the following when generating the negotiation 505 message containing the last mechanism token: if the MIC token 506 exchange is optional, GSS_Accept_sec_context() either indicates 507 GSS_S_COMPLETE and does not include a mechlistMIC token, or 508 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 509 and an accept-incomplete state; if the MIC token exchange is 510 required, GSS_Accept_sec_context() indicates 511 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 512 Acceptors that wish to be compatible with legacy Windows SPNEGO 513 implementations as described in Appendix C should not generate a 514 mechlistMIC token when the MIC token exchange is not required. 515 The initiator then processes the last mechanism token, and does 516 one of the following: 518 (I) If a mechlistMIC token was included, and is correctly 519 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 520 output negotiation message contains a mechlistMIC token, and an 521 accept_complete state. The acceptor MUST then verify this 522 mechlistMIC token. 524 (II) If a mechlistMIC token was included but is incorrect, the 525 negotiation SHALL be terminated. GSS_Init_sec_context() 526 indicates GSS_S_DEFECTIVE_TOKEN. 528 (III) If no mechlistMIC token was included, and the MIC token 529 exchange is not required, GSS_Init_sec_context() indicates 530 GSS_S_COMPLETE with no output token. 532 (IV) If no mechlistMIC token was included, but the MIC token 533 exchange is required, the negotiation SHALL be terminated. 534 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 536 c) In the case that the chosen mechanism exchanges an odd number of 537 mechanism tokens (i.e., the initiator sends the last mechanism 538 token), the initiator does the following when generating the 539 negotiation message containing the last mechanism token: if the 540 negState was request-mic in the first reply from the target, a 541 mechlistMIC token MUST be included, otherwise the mechlistMIC 542 token is OPTIONAL. (Note that the MIC token exchange is required 543 if a mechanism other than the initiator's first choice is chosen.) 544 In the case that the optimistic mechanism token is the only 545 mechanism token for the initiator's preferred mechanism, the 546 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC 547 token is included, GSS_Init_sec_context() indicates 548 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with 549 legacy Windows SPNEGO implementations as described in Appendix C 550 should not generate a mechlistMIC token when the MIC token 551 exchange is not required. The acceptor then processes the last 552 mechanism token and does one of the following: 554 (I) If a mechlistMIC token was included and is correctly verified, 555 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 556 negotiation message contains a mechlistMIC token and an 557 accept_complete state. The initiator MUST then verify this 558 mechlistMIC token. 560 (II) If a mechlistMIC token was included but is incorrect, the 561 negotiation SHALL be terminated. GSS_Accept_sec_context() 562 indicates GSS_S_DEFECTIVE_TOKEN. 564 (III) If no mechlistMIC token was included and the mechlistMIC 565 token exchange is not required, GSS_Accept_sec_context() 566 indicates GSS_S_COMPLETE. The output negotiation message 567 contains an accept_complete state. 569 (IV) In the case that the optimistic mechanism token is also the 570 last mechanism token (when the initiator's preferred mechanism 571 is accepted by the target) and the target sends a request-mic 572 state but the initiator did not send a mechlistMIC token, the 573 target then MUST include a mechlistMIC token in that first 574 reply. GSS_Accept_sec_context() indicates 575 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 576 mechlistMIC token and generate a mechlistMIC token to send back 577 to the target. The target SHALL in turn verify the returned 578 mechlistMIC token and complete the negotiation. 580 (V) If no mechlistMIC token was included and the acceptor sent a 581 request-mic state in the first reply message (the exchange of 582 MIC tokens is required), the negotiation SHALL be terminated. 583 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 585 6. Extensibility 587 Two mechanisms are provided for extensibility. First, the ASN.1 588 structures in this specification MAY be expanded by IETF standards 589 action. Implementations receiving unknown fields MUST ignore these 590 fields. 592 Secondly, OIDs corresponding to a desired mechanism attribute (i.e., 593 mechanism variants) may be included in the set of preferred 594 mechanisms by an initiator. The acceptor can choose to honor this 595 request by preferring mechanisms that have the included attributes. 596 Future work within the Kitten working group is expected to 597 standardize common attributes that SPNEGO mechanisms may wish to 598 support. At this time it is sufficient to say that initiators MAY 599 include OIDs that do not correspond to mechanisms. Such OIDs MAY 600 influence the acceptor's choice of mechanism. As discussed in 601 Section 5, if there are mechanisms that if present in the initiator's 602 list of mechanisms might be preferred by the acceptor to the 603 initiator's preferred mechanism, the acceptor MUST demand the MIC 604 token exchange. As the consequence, acceptors MUST demand the MIC 605 token exchange if they support negotiation of attributes not 606 available in the initiator's preferred mechanism regardless of 607 whether the initiator actually requested these attributes. 609 7. Security Considerations 611 In order to produce the MIC token for the mechanism list, the 612 mechanism must provide integrity protection. When the selected 613 mechanism does not support integrity protection, the negotiation is 614 vulnerable: an active attacker can force it to use a security 615 mechanism that is not mutually preferred but is acceptable to the 616 target. 618 This protocol provides the following guarantees when per-message 619 integrity services are available on the established mechanism context 620 and the mechanism list was altered by an adversary such that a 621 mechanism which is not mutually preferred could be selected: 623 a) If the last mechanism token is sent by the initiator, both peers 624 shall fail; 625 b) If the last mechanism token is sent by the acceptor, the acceptor 626 shall not complete and the initiator at worst shall complete with 627 its preferred mechanism being selected. 629 The negotiation may not be terminated if an alteration was made but 630 it had no material impact. 632 The protection of the negotiation depends on the strength of the 633 integrity protection. In particular, the strength of SPNEGO is no 634 stronger than the integrity protection of the weakest mechanism 635 acceptable to GSS-API peers. 637 Note that where there exist multiple mechanisms with similar context 638 tokens, but different semantics, such that some or all of the 639 mechanisms' context tokens can be easily altered so that one 640 mechanism's context tokens may pass for another of the similar 641 mechanism's context tokens, then there may exist downgrade or similar 642 attacks. For example, if a given family of mechanisms uses the same 643 context token syntax for two or more variants and depends on the OID 644 in the initial token's pseudo-ASN.1/DER wrapper, but does not provide 645 integrity protection for that OID, then there may exist an attack 646 against those mechanisms. SPNEGO does not generally defeat such 647 attacks. 649 In all cases, the communicating peers are exposed to the denial of 650 service threat. 652 8. IANA Considerations 654 This document has no actions for IANA. 656 9. Acknowledgments 658 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 659 Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero and Bill 660 Sommerfeld for their comments and suggestions during development of 661 this document. 663 Luke Howard provided a prototype of this protocol in Heimdal and 664 resolved several issues in the initial draft. 666 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 667 [RFC2478] of which some of the text has been retained in this 668 document. 670 10. References 672 10.1 Normative References 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC2743] Linn, J., "Generic Security Service Application Program 678 Interface Version 2, Update 1", RFC 2743, January 2000. 680 [X690] ASN.1 encoding rules: Specification of Basic Encoding 681 Rules (BER), Canonical Encoding Rules (CER) and 682 Distinguished Encoding Rules (DER), ITU-T Recommendation 683 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 685 10.2 Informative References 687 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 688 Negotiation Mechanism", RFC 2478, December 1998. 690 Authors' Addresses 692 Larry Zhu 693 Microsoft Corporation 694 One Microsoft Way 695 Redmond, WA 98052 696 US 698 Email: lzhu@microsoft.com 700 Paul Leach 701 Microsoft Corporation 702 One Microsoft Way 703 Redmond, WA 98052 704 US 706 Email: paulle@microsoft.com 708 Karthik Jaganathan 709 Microsoft Corporation 710 One Microsoft Way 711 Redmond, WA 98052 712 US 714 Email: karthikj@microsoft.com 715 Wyllys Ingersoll 716 Sun Microsystems 717 1775 Wiehle Avenue, 2nd Floor 718 Reston, VA 20190 719 US 721 Email: wyllys.ingersoll@sun.com 723 Appendix A. SPNEGO ASN.1 Module 725 SPNEGOASNOneSpec { 726 iso(1) identified-organization(3) dod(6) internet(1) 727 security(5) mechanism(5) snego (2) modules(4) spec2(2) 728 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 730 MechType ::= OBJECT IDENTIFIER 731 -- OID represents each security mechanism as suggested by 732 -- [RFC2743] 734 MechTypeList ::= SEQUENCE OF MechType 736 NegotiationToken ::= CHOICE { 737 negTokenInit [0] NegTokenInit, 738 negTokenResp [1] NegTokenResp 739 } 741 NegTokenInit ::= SEQUENCE { 742 mechTypes [0] MechTypeList, 743 reqFlags [1] ContextFlags OPTIONAL, 744 -- inherited from RFC 2478 for backward compatibility, 745 -- RECOMMENDED to be left out 746 mechToken [2] OCTET STRING OPTIONAL, 747 mechListMIC [3] OCTET STRING OPTIONAL, 748 ... 749 } 750 NegTokenResp ::= SEQUENCE { 751 negState [0] ENUMERATED { 752 accept-completed (0), 753 accept-incomplete (1), 754 reject (2), 755 request-mic (3) 756 } OPTIONAL, 757 -- REQUIRED in the first reply from the target 758 supportedMech [1] MechType OPTIONAL, 759 -- present only in the first reply from the target 760 responseToken [2] OCTET STRING OPTIONAL, 761 mechListMIC [3] OCTET STRING OPTIONAL, 762 ... 763 } 765 ContextFlags ::= BIT STRING { 766 delegFlag (0), 767 mutualFlag (1), 768 replayFlag (2), 769 sequenceFlag (3), 770 anonFlag (4), 771 confFlag (5), 772 integFlag (6) 773 } (SIZE (32)) 775 END 777 Appendix B. GSS-API Negotiation Support API 779 In order to provide to a GSS-API caller (either the initiator or the 780 target or both) the ability to choose among the set of supported 781 mechanisms a reduced set of mechanisms for negotiation, two 782 additional APIs are defined: 784 o GSS_Get_neg_mechs() indicates the set of security mechanisms 785 available on the local system to the caller for negotiation, for 786 which appropriate credentials are available. 787 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 788 used on the local system by the caller for negotiation, for the 789 given credentials. 791 B.1 GSS_Set_neg_mechs call 793 Inputs: 795 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 796 -- credentials 797 o mech_set SET OF OBJECT IDENTIFIER 799 Outputs: 801 o major_status INTEGER, 802 o minor_status INTEGER 804 Return major_status codes: 806 o GSS_S_COMPLETE indicates that the set of security mechanisms 807 available for negotiation has been set to mech_set. 808 o GSS_S_FAILURE indicates that the requested operation could not be 809 performed for reasons unspecified at the GSS-API level. 811 Allows callers to specify the set of security mechanisms that may be 812 negotiated with the credential identified by cred_handle. This call 813 is intended for support of specialized callers who need to restrict 814 the set of negotiable security mechanisms from the set of all 815 security mechanisms available to the caller (based on available 816 credentials). Note that if more than one mechanism is specified in 817 mech_set, the order in which those mechanisms are specified implies a 818 relative preference. 820 B.2 GSS_Get_neg_mechs call 822 Input: 824 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 825 -- credentials 827 Outputs: 829 o major_status INTEGER, 830 o minor_status INTEGER, 831 o mech_set SET OF OBJECT IDENTIFIER 833 Return major_status codes: 835 o GSS_S_COMPLETE indicates that the set of security mechanisms 836 available for negotiation has been returned in mech_set. 837 o GSS_S_FAILURE indicates that the requested operation could not be 838 performed for reasons unspecified at the GSS-API level. 840 Allows callers to determine the set of security mechanisms available 841 for negotiation with the credential identified by cred_handle. This 842 call is intended for support of specialized callers who need to 843 reduce the set of negotiable security mechanisms from the set of 844 supported security mechanisms available to the caller (based on 845 available credentials). 847 Note: The GSS_Indicate_mechs() function indicates the full set of 848 mechanism types available on the local system. Since this call has 849 no input parameter, the returned set is not necessarily available for 850 all credentials. 852 Appendix C. Changes since RFC2478 854 SPNEGO implementations in Microsoft Windows 2000/Windows 855 XP/Windows Server 2003 have the following behavior: no mechlistMIC 856 is produced and mechlistMIC is not processed if one is provided; 857 if the initiator sends the last mechanism token, the acceptor will 858 send back a negotiation token with an accept_complete state and no 859 mechlistMIC token. In addition, an incorrect OID 860 (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos 861 Version 5 mechanism. 863 The following changes have been made to be compatible with these 864 legacy implementations. 866 * NegTokenTarg is changed to negTokenResp and it is the message 867 format for all subsequent negotiation tokens. 868 * NegTokenInit is the message for the initial negotiation message 869 and that message only. 870 * mechTypes in negTokenInit is not optional. 871 * If the selected mechanism is also the most preferred mechanism 872 for both peers, it is safe to omit the MIC tokens. 874 If at least one of the two peers implements the updated pseudo 875 mechanism in this document, the negotiation is protected. 877 The following changes are to address problems in RFC 2478. 879 * reqFlags is not protected therefore it should not impact the 880 negotiation. 881 * DER encoding is required. 882 * GSS_GetMIC() input is clarified. 883 * Per-message integrity services are requested for the negotiated 884 mechanism. 885 * Two MIC tokens are exchanged, one in each direction. 887 An implementation that conforms to this specification will not 888 inter-operate with a strict 2748 implementation. Even if the new 889 implementation always sends a mechlistMIC token, it will still fail 890 to inter-operate. If it is a server, it will fail because it 891 requests a mechlistMIC token using an option that older 892 implementations simply do not support. Clients will tend to fail as 893 well. 895 As an alternative to the approach chosen in this specification, we 896 could have documented a correct behavior that is fully backward 897 compatible with RFC 2478 and included an appendix on how to 898 inter-operate with existing incorrect implementations of RFC 2478. 900 As a practical matter, the SPNEGO implementers within the IETF have 901 valued interoperability with the Microsoft implementations. We were 902 unable to choose to maintain reasonable security guarantees, maintain 903 interoperability with the Microsoft implementations and maintain 904 interoperability with correct implementations of RFC 2478. The 905 working group was not aware of any RFC 2478 implementations deployed 906 on the Internet. Even if there are such implementations, it is 907 unlikely that they will inter-operate because of a critical flaw in 908 the description of the encoding of the mechanism list in RFC 2478. 910 With the approach taken in this specification, security is ensured 911 between new implementations all the time while maintaining 912 interoperability with the implementations deployed within the IETF 913 community. The working group believes that this justifies breaking 914 compatibility with a correct implementation of RFC 2478. 916 Appendix D. mechListMIC Computation Example 918 The following is an example to illustrate how the mechListMIC field 919 would be computed. 921 The initial part of the DER encoding of NegTokenInit is constructed 922 as follows (the "nn" are length encodings, possibly longer than one 923 octet): 925 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) 926 nn -- length 928 -- contents octets of the SEQUENCE begin with 929 -- DER encoding of "[0] MechTypeList": 930 A0 -- identifier octet for constructed [0] 931 nn -- length 933 -- contents of the constructed [0] are DER encoding 934 -- of MechTypeList (which is a SEQUENCE): 935 30 -- identifier octet for constructed SEQUENCE 936 nn -- length 938 -- contents octets of the SEQUENCE begin with 939 -- DER encoding of OBJECT IDENTIFIER: 940 06 -- identifier octet for primitive OBJECT IDENTIFIER 941 09 -- length 942 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 943 -- {1 2 840 113554 1 2 2} 945 If a mechlistMIC needs to be generated (according to the rules in 946 Section 5), it is computed by using the DER encoding of the type 947 MechTypeList data from the initiator's NegTokenInit token as input to 948 the GSS_GetMIC() function. In this case, the MIC would be computed 949 over the following octets: 951 DER encoding of MechTypeList: 952 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... 954 Note that the identifier octet and length octet(s) for constructed 955 [0] (A0 nn) are not included in the MIC computation. 957 Intellectual Property Statement 959 The IETF takes no position regarding the validity or scope of any 960 Intellectual Property Rights or other rights that might be claimed to 961 pertain to the implementation or use of the technology described in 962 this document or the extent to which any license under such rights 963 might or might not be available; nor does it represent that it has 964 made any independent effort to identify any such rights. Information 965 on the procedures with respect to rights in RFC documents can be 966 found in BCP 78 and BCP 79. 968 Copies of IPR disclosures made to the IETF Secretariat and any 969 assurances of licenses to be made available, or the result of an 970 attempt made to obtain a general license or permission for the use of 971 such proprietary rights by implementers or users of this 972 specification can be obtained from the IETF on-line IPR repository at 973 http://www.ietf.org/ipr. 975 The IETF invites any interested party to bring to its attention any 976 copyrights, patents or patent applications, or other proprietary 977 rights that may cover technology that may be required to implement 978 this standard. Please address the information to the IETF at 979 ietf-ipr@ietf.org. 981 Disclaimer of Validity 983 This document and the information contained herein are provided on an 984 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 985 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 986 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 987 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 988 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 989 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 991 Copyright Statement 993 Copyright (C) The Internet Society (2005). This document is subject 994 to the rights, licenses and restrictions contained in BCP 78, and 995 except as set forth therein, the authors retain all their rights. 997 Acknowledgment 999 Funding for the RFC Editor function is currently provided by the 1000 Internet Society.