1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft P. Leach 5Obsoletes: 2478 (if approved) K. Jaganathan 6Expires: July 27, 2005 Microsoft Corporation 7 W. Ingersoll 8 Sun Microsystems 9 January 23, 2005 10 11 12 The Simple and Protected GSS-API Negotiation Mechanism 13 draft-ietf-kitten-2478bis-05 14 15Status of this Memo 16 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 23 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 28 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 33 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 36 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 39 40 This Internet-Draft will expire on July 27, 2005. 41 42Copyright Notice 43 44 Copyright (C) The Internet Society (2005). 45 46Abstract 47 48 This document specifies a negotiation mechanism for the Generic 49 Security Service Application Program Interface (GSS-API) which is 50 described in RFC 2743. 51 52 53 54Zhu, et al. Expires July 27, 2005 [Page 1] 55 56Internet-Draft GSS-API Negotiation Mechanism January 2005 57 58 59 GSS-API peers can use this negotiation mechanism to choose from a 60 common set of security mechanisms. 61 62 If per-message integrity services are available on the established 63 mechanism context, then the negotiation is protected against an 64 attacker forcing the selection of a mechanism not desired by the 65 peers. 66 67 This mechanism replaces RFC 2478 in order to fix defects in that 68 specification and to describe how to inter-operate with 69 implementations of that specification commonly deployed on the 70 Internet. 71 72Table of Contents 73 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 76 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6 77 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6 78 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7 79 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10 80 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10 81 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10 82 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11 83 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12 84 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14 85 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 10.1 Normative References . . . . . . . . . . . . . . . . . . . 21 91 10.2 Informative References . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 93 A. SPNEGO ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 23 94 B. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 25 95 B.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25 96 B.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25 97 C. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 27 98 D. mechListMIC Computation Example . . . . . . . . . . . . . . . 29 99 Intellectual Property and Copyright Statements . . . . . . . . 30 100 101 102 103 104 105 106 107 108 109 110Zhu, et al. Expires July 27, 2005 [Page 2] 111 112Internet-Draft GSS-API Negotiation Mechanism January 2005 113 114 1151. Introduction 116 117 The GSS-API [RFC2743] provides a generic interface which can be 118 layered atop different security mechanisms such that if communicating 119 peers acquire GSS-API credentials for the same security mechanism, 120 then a security context may be established between them (subject to 121 policy). However, GSS-API does not prescribe the method by which 122 GSS-API peers can establish whether they have a common security 123 mechanism. 124 125 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 126 defined here is a pseudo security mechanism, which enables GSS-API 127 peers to determine in-band whether their credentials support a common 128 set of one or more GSS-API security mechanisms, and if so, to invoke 129 the normal security context establishment for a selected common 130 security mechanism. This is most useful for applications which 131 depend on GSS-API implementations and share multiple mechanisms 132 between the peers. 133 134 The SPNEGO mechanism negotiation is based on the following model: the 135 initiator proposes a list of security mechanism(s), in decreasing 136 preference order (favorite choice first), the acceptor (also known as 137 the target) either accepts the initiator's preferred security 138 mechanism (the first in the list), or chooses one that is available 139 from the offered list, or rejects the proposed value(s). The target 140 then informs the initiator of its choice. 141 142 Once a common security mechanism is chosen, mechanism-specific 143 options MAY be negotiated as part of the selected mechanism's context 144 establishment. These negotiations (if any) are internal to the 145 mechanism and opaque to the SPNEGO protocol. As such they are 146 outside the scope of this document. 147 148 If per-message integrity services are available on the established 149 mechanism security context, then the negotiation is protected to 150 ensure that the mechanism list has not been modified. In cases where 151 an attacker could have materially influenced the negotiation, peers 152 exchange message integrity code (MIC) tokens to confirm the mechanism 153 list has not been modified. If no action of an attacker could have 154 materially modified the outcome of the negotiation, the exchange of 155 MIC tokens is optional (see Section 5). Allowing MIC tokens to be 156 optional in this case provides interoperability with existing 157 implementations while still protecting the negotiation. This 158 interoperability comes at the cost of increased complexity. 159 160 SPNEGO relies on the concepts developed in the GSS-API specification 161 [RFC2743]. The negotiation data is encapsulated in context-level 162 tokens. Therefore, callers of the GSS-API do not need to be aware of 163 164 165 166Zhu, et al. Expires July 27, 2005 [Page 3] 167 168Internet-Draft GSS-API Negotiation Mechanism January 2005 169 170 171 the existence of the negotiation tokens but only of the new 172 pseudo-security mechanism. A failure in the negotiation phase causes 173 a major status code to be returned: GSS_S_BAD_MECH. 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222Zhu, et al. Expires July 27, 2005 [Page 4] 223 224Internet-Draft GSS-API Negotiation Mechanism January 2005 225 226 2272. Conventions Used in This Document 228 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278Zhu, et al. Expires July 27, 2005 [Page 5] 279 280Internet-Draft GSS-API Negotiation Mechanism January 2005 281 282 2833. Negotiation Protocol 284 285 When the established mechanism context provides integrity protection, 286 the mechanism negotiation can be protected. When acquiring 287 negotiated security mechanism tokens, per-message integrity services 288 are always requested by the SPNEGO mechanism. 289 290 When the established mechanism context supports per-message integrity 291 services, SPNEGO guarantees that the selected mechanism is mutually 292 preferred. 293 294 This section describes the negotiation process of this protocol. 295 2963.1 Negotiation Description 297 298 The first negotiation token sent by the initiator contains an ordered 299 list of mechanisms in decreasing preference order (favorite mechanism 300 first), and optionally the initial mechanism token for the preferred 301 mechanism of the initiator (i.e., the first in the list). (Note that 302 the list MUST NOT contain either this SPNEGO mechanism itself or any 303 mechanism for which the client does not have appropriate 304 credentials.) 305 306 The target then processes the token from the initiator. This will 307 result in one of four possible states (as defined in Section 4.2.2) 308 being returned in the reply message: accept-completed, 309 accept-incomplete, reject, or request-mic. A reject state will 310 terminate the negotiation; an accept-completed state indicates that 311 not only was the initiator-selected mechanism acceptable to the 312 target, but also that the security mechanism token embedded in the 313 first negotiation message was sufficient to complete the 314 authentication; an accept-incomplete state indicates that further 315 message exchange is needed but the MIC token exchange as described in 316 Section 5 is OPTIONAL; a request-mic state (this state can only be 317 present in the first reply message from the target) indicates the MIC 318 token exchange is REQUIRED if per-message integrity services are 319 available. 320 321 Unless the preference order is specified by the application, the 322 policy by which the target chooses a mechanism is an 323 implementation-specific local matter. In the absence of an 324 application specified preference order or other policy, the target 325 SHALL choose the first mechanism in the initiator proposed list for 326 which it has valid credentials. 327 328 In case of a successful negotiation, the security mechanism in the 329 first reply message represents the value suitable for the target, 330 chosen from the list offered by the initiator. 331 332 333 334Zhu, et al. Expires July 27, 2005 [Page 6] 335 336Internet-Draft GSS-API Negotiation Mechanism January 2005 337 338 339 In case of an unsuccessful negotiation, the reject state is returned 340 and generating a context level negotiation token is OPTIONAL. 341 342 Once a mechanism has been selected, context establishment tokens 343 specific to the selected mechanism are carried within the negotiation 344 tokens. 345 346 Lastly, MIC tokens may be exchanged to ensure the authenticity of the 347 mechanism list received by the target. 348 349 To avoid conflicts with the use of MIC tokens by SPNEGO, 350 partially-established contexts MUST NOT be used for per-message 351 calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set 352 to false on return from GSS_Init_sec_context() and 353 GSS_Accept_sec_context() even if the underlying mechanism returned 354 true. 355 356 Note that in order to avoid an extra round trip, the first context 357 establishment token of the initiator's preferred mechanism SHOULD be 358 embedded in the initial negotiation message (as defined in 359 Section 4.2). (This mechanism token is referred to as the optimistic 360 mechanism token in this document.) In addition, using the optimistic 361 mechanism token allows the initiator to recover from non-fatal errors 362 encountered trying to produce the first mechanism token before a 363 mechanism can be selected. Implementations MAY omit the optimistic 364 mechanism token in cases where the likelihood of the initiator's 365 preferred mechanism not being selected by the acceptor is significant 366 given the cost of generating it. 367 3683.2 Negotiation Procedure 369 370 The basic form of the procedure assumes that per-message integrity 371 services are available on the established mechanism context, and it 372 is summarized as follows: 373 374 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 375 but requests that SPNEGO be used. SPNEGO can either be explicitly 376 requested or accepted as the default mechanism. 377 378 (b) The initiator GSS-API implementation generates a negotiation 379 token containing a list of one or more security mechanisms that 380 are available based on the credentials used for this context 381 establishment, and optionally the initial mechanism token for the 382 first mechanism in the list. 383 384 385 386 387 388 389 390Zhu, et al. Expires July 27, 2005 [Page 7] 391 392Internet-Draft GSS-API Negotiation Mechanism January 2005 393 394 395 (c) The GSS-API initiator application sends the token to the target 396 application. The GSS-API target application passes the token by 397 invoking GSS_Accept_sec_context(). The acceptor will do one of 398 the following: 399 400 401 (I) If none of the proposed mechanisms are acceptable, the 402 negotiation SHALL be terminated. GSS_Accept_sec_context 403 indicates GSS_S_BAD_MECH. The acceptor MAY output a 404 negotiation token containing a reject state. 405 406 (II) If either the initiator's preferred mechanism is not 407 accepted by the target or this mechanism is accepted but it 408 is not the acceptor's most preferred mechanism (i.e., the 409 MIC token exchange as described in Section 5 is required), 410 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. 411 The acceptor MUST output a negotiation token containing a 412 request-mic state. 413 414 (III) Otherwise if at least one additional negotiation token 415 from the initiator is needed to establish this context, 416 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and 417 outputs a negotiation token containing an accept-incomplete 418 state. 419 420 (IV) Otherwise no additional negotiation token from the 421 initiator is needed to establish this context, 422 GSS_Accept_sec_context() indicates GSS_S_COMPLETE and 423 outputs a negotiation token containing an accept_complete 424 state. 425 426 If the initiator's preferred mechanism is accepted, and an 427 optimistic mechanism token was included, this mechanism token MUST 428 be passed to the selected mechanism by invoking 429 GSS_Accept_sec_context() and if a response mechanism token is 430 returned, it MUST be included in the response negotiation token. 431 Otherwise, the target will not generate a response mechanism token 432 in the first reply. 433 434 (d) The GSS-API target application returns the negotiation token to 435 the initiator application. The GSS-API initiator application 436 passes the token by invoking GSS_Init_sec_context(). The security 437 context initialization is then continued according to the standard 438 GSS-API conventions for the selected mechanism, where the tokens 439 of the selected mechanism are encapsulated in negotiation messages 440 (see Section 4) until GSS_S_COMPLETE is returned for both the 441 initiator and the target by the selected security mechanism. 442 443 444 445 446Zhu, et al. Expires July 27, 2005 [Page 8] 447 448Internet-Draft GSS-API Negotiation Mechanism January 2005 449 450 451 (e) MIC tokens are then either skipped or exchanged according to 452 Section 5. 453 454 Note that the *_req_flag input parameters for context establishment 455 are relative to the selected mechanism, as are the *_state output 456 parameters. i.e., these parameters are not applicable to the 457 negotiation process per se. 458 459 On receipt of a negotiation token on the target side, a GSS-API 460 implementation that does not support negotiation would indicate the 461 GSS_S_BAD_MECH status as if a particular basic security mechanism had 462 been requested and was not supported. 463 464 When a GSS-API credential is acquired for the SPNEGO mechanism the 465 implementation SHOULD produce a credential element for the SPNEGO 466 mechanism which internally contains GSS-API credential elements for 467 all mechanisms for which the principal has credentials available, 468 except for any mechanisms which are not to be negotiated, either as 469 per implementation-, site- or application-specific policy. See 470 Appendix B for interfaces for expressing application policy. 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502Zhu, et al. Expires July 27, 2005 [Page 9] 503 504Internet-Draft GSS-API Negotiation Mechanism January 2005 505 506 5074. Token Definitions 508 509 The type definitions in this section assume an ASN.1 module 510 definition of the following form: 511 512 513 SPNEGOASNOneSpec { 514 iso(1) identified-organization(3) dod(6) internet(1) 515 security(5) mechanism(5) snego (2) modules(4) spec2(2) 516 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 517 518 -- rest of definitions here 519 520 END 521 522 523 This specifies that the tagging context for the module will be 524 explicit and non-automatic. 525 526 The encoding of SPNEGO protocol messages shall obey the Distinguished 527 Encoding Rules (DER) of ASN.1 as described in [X690]. 528 5294.1 Mechanism Types 530 531 In this negotiation model, each OID represents one GSS-API mechanism 532 or one variant (see Section 6) of it according to [RFC2743]. 533 534 535 MechType ::= OBJECT IDENTIFIER 536 -- OID represents each security mechanism as suggested by 537 -- [RFC2743] 538 539 MechTypeList ::= SEQUENCE OF MechType 540 541 5424.2 Negotiation Tokens 543 544 The syntax of the initial negotiation tokens follows the 545 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 546 SPNEGO pseudo mechanism is identified by the Object Identifier 547 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 548 Subsequent tokens MUST NOT be encapsulated in this GSS-API generic 549 token framing. 550 551 This section specifies the syntax of the inner token for the initial 552 message and the syntax of subsequent context establishment tokens. 553 554 555 556 557 558Zhu, et al. Expires July 27, 2005 [Page 10] 559 560Internet-Draft GSS-API Negotiation Mechanism January 2005 561 562 563 NegotiationToken ::= CHOICE { 564 negTokenInit [0] NegTokenInit, 565 negTokenResp [1] NegTokenResp 566 } 567 568 569 5704.2.1 negTokenInit 571 572 NegTokenInit ::= SEQUENCE { 573 mechTypes [0] MechTypeList, 574 reqFlags [1] ContextFlags OPTIONAL, 575 -- inherited from RFC 2478 for backward compatibility, 576 -- RECOMMENDED to be left out 577 mechToken [2] OCTET STRING OPTIONAL, 578 mechListMIC [3] OCTET STRING OPTIONAL, 579 ... 580 } 581 ContextFlags ::= BIT STRING { 582 delegFlag (0), 583 mutualFlag (1), 584 replayFlag (2), 585 sequenceFlag (3), 586 anonFlag (4), 587 confFlag (5), 588 integFlag (6) 589 } (SIZE (32)) 590 591 This is the syntax for the inner token of the initial negotiation 592 message. 593 594 mechTypes 595 596 This field contains one or more security mechanisms available 597 for the initiator in decreasing preference order (favorite 598 choice first). 599 600 reqFlags 601 602 This field, if present, contains the service options that are 603 requested to establish the context (the req_flags parameter of 604 GSS_Init_sec_context()). This field is inherited from RFC 2478 605 and it is not integrity protected. For implementations of this 606 specification the initiator SHOULD omit this reqFlags field, 607 and the acceptor MUST ignore this reqFlags field. 608 609 610 611 612 613 614Zhu, et al. Expires July 27, 2005 [Page 11] 615 616Internet-Draft GSS-API Negotiation Mechanism January 2005 617 618 619 mechToken 620 621 This field, if present, contains the optimistic mechanism 622 token. 623 624 mechlistMIC 625 626 This field, if present, contains a MIC token for the mechanism 627 list in the initial negotiation message. This MIC token is 628 computed according to Section 5. 629 630 6314.2.2 negTokenResp 632 633 NegTokenResp ::= SEQUENCE { 634 negState [0] ENUMERATED { 635 accept-completed (0), 636 accept-incomplete (1), 637 reject (2), 638 request-mic (3) 639 } OPTIONAL, 640 -- REQUIRED in the first reply from the target 641 supportedMech [1] MechType OPTIONAL, 642 -- present only in the first reply from the target 643 responseToken [2] OCTET STRING OPTIONAL, 644 mechListMIC [3] OCTET STRING OPTIONAL, 645 ... 646 } 647 648 This is the syntax for all subsequent negotiation messages. 649 650 negState 651 652 This field, if present, contains the state of the negotiation. 653 This can be: 654 655 accept-completed 656 657 No further negotiation message from the peer is expected, 658 and the security context is established for the sender. 659 660 accept-incomplete 661 662 At least one more negotiation message from the peer is 663 needed to establish the security context. 664 665 666 667 668 669 670Zhu, et al. Expires July 27, 2005 [Page 12] 671 672Internet-Draft GSS-API Negotiation Mechanism January 2005 673 674 675 reject 676 677 The sender terminates the negotiation. 678 679 request-mic 680 681 The sender indicates that the exchange of MIC tokens, as 682 described in Section 5, will be REQUIRED if per-message 683 integrity services are available on the mechanism context to 684 be established. This value SHALL only be present in the 685 first reply from the target. 686 687 This field is REQUIRED in the first reply from the target, and 688 it is OPTIONAL thereafter. When negState is absent the actual 689 state should be inferred from the state of the negotiated 690 mechanism context. 691 692 supportedMech 693 694 This field SHALL only be present in the first reply from the 695 target. It MUST be one of the mechanism(s) offered by the 696 initiator. 697 698 ResponseToken 699 700 This field, if present, contains tokens specific to the 701 mechanism selected. 702 703 mechlistMIC 704 705 This field, if present, contains a MIC token for the mechanism 706 list in the initial negotiation message. This MIC token is 707 computed according to Section 5. 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726Zhu, et al. Expires July 27, 2005 [Page 13] 727 728Internet-Draft GSS-API Negotiation Mechanism January 2005 729 730 7315. Processing of mechListMIC 732 733 If the mechanism selected by the negotiation does not support 734 integrity protection, then no mechlistMIC token is used. 735 736 Otherwise, if the accepted mechanism is the most preferred mechanism 737 of both the initiator and the acceptor, then the MIC token exchange, 738 as described later in this section, is OPTIONAL. A mechanism is the 739 acceptor's most preferred mechanism if there is no other mechanism 740 which, had it been present in the mechanism list, the acceptor would 741 have preferred over the accepted mechanism. 742 743 In all other cases, MIC tokens MUST be exchanged after the mechanism 744 context is fully established. 745 746 a) The mechlistMIC token (or simply the MIC token) is computed over 747 the mechanism list in the initial negotiation message by invoking 748 GSS_GetMIC() as follows: the input context_handle is the 749 established mechanism context, the input qop_req is 0, and the 750 input message is the DER encoding of the value of type 751 MechTypeList which is contained in the "mechTypes" field of the 752 NegTokenInit. The input message is NOT the DER encoding of the 753 type "[0] MechTypeList". 754 755 b) If the selected mechanism exchanges an even number of mechanism 756 tokens (i.e., the acceptor sends the last mechanism token), the 757 acceptor does the following when generating the negotiation 758 message containing the last mechanism token: if the MIC token 759 exchange is optional, GSS_Accept_sec_context() either indicates 760 GSS_S_COMPLETE and does not include a mechlistMIC token, or 761 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 762 and an accept-incomplete state; if the MIC token exchange is 763 required, GSS_Accept_sec_context() indicates 764 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 765 Acceptors that wish to be compatible with legacy Windows SPNEGO 766 implementations as described in Appendix C should not generate a 767 mechlistMIC token when the MIC token exchange is not required. 768 The initiator then processes the last mechanism token, and does 769 one of the following: 770 771 (I) If a mechlistMIC token was included, and is correctly 772 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 773 output negotiation message contains a mechlistMIC token, and an 774 accept_complete state. The acceptor MUST then verify this 775 mechlistMIC token. 776 777 778 779 780 781 782Zhu, et al. Expires July 27, 2005 [Page 14] 783 784Internet-Draft GSS-API Negotiation Mechanism January 2005 785 786 787 (II) If a mechlistMIC token was included but is incorrect, the 788 negotiation SHALL be terminated. GSS_Init_sec_context() 789 indicates GSS_S_DEFECTIVE_TOKEN. 790 791 (III) If no mechlistMIC token was included, and the MIC token 792 exchange is not required, GSS_Init_sec_context() indicates 793 GSS_S_COMPLETE with no output token. 794 795 (IV) If no mechlistMIC token was included, but the MIC token 796 exchange is required, the negotiation SHALL be terminated. 797 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 798 799 c) In the case that the chosen mechanism exchanges an odd number of 800 mechanism tokens (i.e., the initiator sends the last mechanism 801 token), the initiator does the following when generating the 802 negotiation message containing the last mechanism token: if the 803 negState was request-mic in the first reply from the target, a 804 mechlistMIC token MUST be included, otherwise the mechlistMIC 805 token is OPTIONAL. (Note that the MIC token exchange is required 806 if a mechanism other than the initiator's first choice is chosen.) 807 In the case that the optimistic mechanism token is the only 808 mechanism token for the initiator's preferred mechanism, the 809 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC 810 token is included, GSS_Init_sec_context() indicates 811 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with 812 legacy Windows SPNEGO implementations as described in Appendix C 813 should not generate a mechlistMIC token when the MIC token 814 exchange is not required. The acceptor then processes the last 815 mechanism token and does one of the following: 816 817 (I) If a mechlistMIC token was included and is correctly verified, 818 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 819 negotiation message contains a mechlistMIC token and an 820 accept_complete state. The initiator MUST then verify this 821 mechlistMIC token. 822 823 (II) If a mechlistMIC token was included but is incorrect, the 824 negotiation SHALL be terminated. GSS_Accept_sec_context() 825 indicates GSS_S_DEFECTIVE_TOKEN. 826 827 (III) If no mechlistMIC token was included and the mechlistMIC 828 token exchange is not required, GSS_Accept_sec_context() 829 indicates GSS_S_COMPLETE. The output negotiation message 830 contains an accept_complete state. 831 832 833 834 835 836 837 838Zhu, et al. Expires July 27, 2005 [Page 15] 839 840Internet-Draft GSS-API Negotiation Mechanism January 2005 841 842 843 (IV) In the case that the optimistic mechanism token is also the 844 last mechanism token (when the initiator's preferred mechanism 845 is accepted by the target) and the target sends a request-mic 846 state but the initiator did not send a mechlistMIC token, the 847 target then MUST include a mechlistMIC token in that first 848 reply. GSS_Accept_sec_context() indicates 849 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 850 mechlistMIC token and generate a mechlistMIC token to send back 851 to the target. The target SHALL in turn verify the returned 852 mechlistMIC token and complete the negotiation. 853 854 (V) If no mechlistMIC token was included and the acceptor sent a 855 request-mic state in the first reply message (the exchange of 856 MIC tokens is required), the negotiation SHALL be terminated. 857 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894Zhu, et al. Expires July 27, 2005 [Page 16] 895 896Internet-Draft GSS-API Negotiation Mechanism January 2005 897 898 8996. Extensibility 900 901 Two mechanisms are provided for extensibility. First, the ASN.1 902 structures in this specification MAY be expanded by IETF standards 903 action. Implementations receiving unknown fields MUST ignore these 904 fields. 905 906 Secondly, OIDs corresponding to a desired mechanism attribute (i.e., 907 mechanism variants) may be included in the set of preferred 908 mechanisms by an initiator. The acceptor can choose to honor this 909 request by preferring mechanisms that have the included attributes. 910 Future work within the Kitten working group is expected to 911 standardize common attributes that SPNEGO mechanisms may wish to 912 support. At this time it is sufficient to say that initiators MAY 913 include OIDs that do not correspond to mechanisms. Such OIDs MAY 914 influence the acceptor's choice of mechanism. As discussed in 915 Section 5, if there are mechanisms that if present in the initiator's 916 list of mechanisms might be preferred by the acceptor to the 917 initiator's preferred mechanism, the acceptor MUST demand the MIC 918 token exchange. As the consequence, acceptors MUST demand the MIC 919 token exchange if they support negotiation of attributes not 920 available in the initiator's preferred mechanism regardless of 921 whether the initiator actually requested these attributes. 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950Zhu, et al. Expires July 27, 2005 [Page 17] 951 952Internet-Draft GSS-API Negotiation Mechanism January 2005 953 954 9557. Security Considerations 956 957 In order to produce the MIC token for the mechanism list, the 958 mechanism must provide integrity protection. When the selected 959 mechanism does not support integrity protection, the negotiation is 960 vulnerable: an active attacker can force it to use a security 961 mechanism that is not mutually preferred but is acceptable to the 962 target. 963 964 This protocol provides the following guarantees when per-message 965 integrity services are available on the established mechanism context 966 and the mechanism list was altered by an adversary such that a 967 mechanism which is not mutually preferred could be selected: 968 969 a) If the last mechanism token is sent by the initiator, both peers 970 shall fail; 971 b) If the last mechanism token is sent by the acceptor, the acceptor 972 shall not complete and the initiator at worst shall complete with 973 its preferred mechanism being selected. 974 975 The negotiation may not be terminated if an alteration was made but 976 it had no material impact. 977 978 The protection of the negotiation depends on the strength of the 979 integrity protection. In particular, the strength of SPNEGO is no 980 stronger than the integrity protection of the weakest mechanism 981 acceptable to GSS-API peers. 982 983 Note that where there exist multiple mechanisms with similar context 984 tokens, but different semantics, such that some or all of the 985 mechanisms' context tokens can be easily altered so that one 986 mechanism's context tokens may pass for another of the similar 987 mechanism's context tokens, then there may exist downgrade or similar 988 attacks. For example, if a given family of mechanisms uses the same 989 context token syntax for two or more variants and depends on the OID 990 in the initial token's pseudo-ASN.1/DER wrapper, but does not provide 991 integrity protection for that OID, then there may exist an attack 992 against those mechanisms. SPNEGO does not generally defeat such 993 attacks. 994 995 In all cases, the communicating peers are exposed to the denial of 996 service threat. 997 998 999 1000 1001 1002 1003 1004 1005 1006Zhu, et al. Expires July 27, 2005 [Page 18] 1007 1008Internet-Draft GSS-API Negotiation Mechanism January 2005 1009 1010 10118. IANA Considerations 1012 1013 This document has no actions for IANA. 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062Zhu, et al. Expires July 27, 2005 [Page 19] 1063 1064Internet-Draft GSS-API Negotiation Mechanism January 2005 1065 1066 10679. Acknowledgments 1068 1069 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 1070 Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero and Bill 1071 Sommerfeld for their comments and suggestions during development of 1072 this document. 1073 1074 Luke Howard provided a prototype of this protocol in Heimdal and 1075 resolved several issues in the initial draft. 1076 1077 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 1078 [RFC2478] of which some of the text has been retained in this 1079 document. 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118Zhu, et al. Expires July 27, 2005 [Page 20] 1119 1120Internet-Draft GSS-API Negotiation Mechanism January 2005 1121 1122 112310. References 1124 112510.1 Normative References 1126 1127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1128 Requirement Levels", BCP 14, RFC 2119, March 1997. 1129 1130 [RFC2743] Linn, J., "Generic Security Service Application Program 1131 Interface Version 2, Update 1", RFC 2743, January 2000. 1132 1133 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1134 Rules (BER), Canonical Encoding Rules (CER) and 1135 Distinguished Encoding Rules (DER), ITU-T Recommendation 1136 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 1137 113810.2 Informative References 1139 1140 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 1141 Negotiation Mechanism", RFC 2478, December 1998. 1142 1143 1144Authors' Addresses 1145 1146 Larry Zhu 1147 Microsoft Corporation 1148 One Microsoft Way 1149 Redmond, WA 98052 1150 US 1151 1152 Email: lzhu@microsoft.com 1153 1154 1155 Paul Leach 1156 Microsoft Corporation 1157 One Microsoft Way 1158 Redmond, WA 98052 1159 US 1160 1161 Email: paulle@microsoft.com 1162 1163 1164 Karthik Jaganathan 1165 Microsoft Corporation 1166 One Microsoft Way 1167 Redmond, WA 98052 1168 US 1169 1170 Email: karthikj@microsoft.com 1171 1172 1173 1174 1175Zhu, et al. Expires July 27, 2005 [Page 21] 1176 1177Internet-Draft GSS-API Negotiation Mechanism January 2005 1178 1179 1180 Wyllys Ingersoll 1181 Sun Microsystems 1182 1775 Wiehle Avenue, 2nd Floor 1183 Reston, VA 20190 1184 US 1185 1186 Email: wyllys.ingersoll@sun.com 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231Zhu, et al. Expires July 27, 2005 [Page 22] 1232 1233Internet-Draft GSS-API Negotiation Mechanism January 2005 1234 1235 1236Appendix A. SPNEGO ASN.1 Module 1237 1238 SPNEGOASNOneSpec { 1239 iso(1) identified-organization(3) dod(6) internet(1) 1240 security(5) mechanism(5) snego (2) modules(4) spec2(2) 1241 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1242 1243 MechType ::= OBJECT IDENTIFIER 1244 -- OID represents each security mechanism as suggested by 1245 -- [RFC2743] 1246 1247 MechTypeList ::= SEQUENCE OF MechType 1248 1249 NegotiationToken ::= CHOICE { 1250 negTokenInit [0] NegTokenInit, 1251 negTokenResp [1] NegTokenResp 1252 } 1253 1254 NegTokenInit ::= SEQUENCE { 1255 mechTypes [0] MechTypeList, 1256 reqFlags [1] ContextFlags OPTIONAL, 1257 -- inherited from RFC 2478 for backward compatibility, 1258 -- RECOMMENDED to be left out 1259 mechToken [2] OCTET STRING OPTIONAL, 1260 mechListMIC [3] OCTET STRING OPTIONAL, 1261 ... 1262 } 1263 NegTokenResp ::= SEQUENCE { 1264 negState [0] ENUMERATED { 1265 accept-completed (0), 1266 accept-incomplete (1), 1267 reject (2), 1268 request-mic (3) 1269 } OPTIONAL, 1270 -- REQUIRED in the first reply from the target 1271 supportedMech [1] MechType OPTIONAL, 1272 -- present only in the first reply from the target 1273 responseToken [2] OCTET STRING OPTIONAL, 1274 mechListMIC [3] OCTET STRING OPTIONAL, 1275 ... 1276 } 1277 1278 ContextFlags ::= BIT STRING { 1279 delegFlag (0), 1280 mutualFlag (1), 1281 replayFlag (2), 1282 sequenceFlag (3), 1283 anonFlag (4), 1284 1285 1286 1287Zhu, et al. Expires July 27, 2005 [Page 23] 1288 1289Internet-Draft GSS-API Negotiation Mechanism January 2005 1290 1291 1292 confFlag (5), 1293 integFlag (6) 1294 } (SIZE (32)) 1295 1296 END 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343Zhu, et al. Expires July 27, 2005 [Page 24] 1344 1345Internet-Draft GSS-API Negotiation Mechanism January 2005 1346 1347 1348Appendix B. GSS-API Negotiation Support API 1349 1350 In order to provide to a GSS-API caller (either the initiator or the 1351 target or both) the ability to choose among the set of supported 1352 mechanisms a reduced set of mechanisms for negotiation, two 1353 additional APIs are defined: 1354 1355 o GSS_Get_neg_mechs() indicates the set of security mechanisms 1356 available on the local system to the caller for negotiation, for 1357 which appropriate credentials are available. 1358 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 1359 used on the local system by the caller for negotiation, for the 1360 given credentials. 1361 1362B.1 GSS_Set_neg_mechs call 1363 1364 Inputs: 1365 1366 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 1367 -- credentials 1368 o mech_set SET OF OBJECT IDENTIFIER 1369 1370 Outputs: 1371 1372 o major_status INTEGER, 1373 o minor_status INTEGER 1374 1375 Return major_status codes: 1376 1377 o GSS_S_COMPLETE indicates that the set of security mechanisms 1378 available for negotiation has been set to mech_set. 1379 o GSS_S_FAILURE indicates that the requested operation could not be 1380 performed for reasons unspecified at the GSS-API level. 1381 1382 Allows callers to specify the set of security mechanisms that may be 1383 negotiated with the credential identified by cred_handle. This call 1384 is intended for support of specialized callers who need to restrict 1385 the set of negotiable security mechanisms from the set of all 1386 security mechanisms available to the caller (based on available 1387 credentials). Note that if more than one mechanism is specified in 1388 mech_set, the order in which those mechanisms are specified implies a 1389 relative preference. 1390 1391B.2 GSS_Get_neg_mechs call 1392 1393 Input: 1394 1395 1396 1397 1398 1399Zhu, et al. Expires July 27, 2005 [Page 25] 1400 1401Internet-Draft GSS-API Negotiation Mechanism January 2005 1402 1403 1404 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 1405 -- credentials 1406 1407 Outputs: 1408 1409 o major_status INTEGER, 1410 o minor_status INTEGER, 1411 o mech_set SET OF OBJECT IDENTIFIER 1412 1413 Return major_status codes: 1414 1415 o GSS_S_COMPLETE indicates that the set of security mechanisms 1416 available for negotiation has been returned in mech_set. 1417 o GSS_S_FAILURE indicates that the requested operation could not be 1418 performed for reasons unspecified at the GSS-API level. 1419 1420 Allows callers to determine the set of security mechanisms available 1421 for negotiation with the credential identified by cred_handle. This 1422 call is intended for support of specialized callers who need to 1423 reduce the set of negotiable security mechanisms from the set of 1424 supported security mechanisms available to the caller (based on 1425 available credentials). 1426 1427 Note: The GSS_Indicate_mechs() function indicates the full set of 1428 mechanism types available on the local system. Since this call has 1429 no input parameter, the returned set is not necessarily available for 1430 all credentials. 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455Zhu, et al. Expires July 27, 2005 [Page 26] 1456 1457Internet-Draft GSS-API Negotiation Mechanism January 2005 1458 1459 1460Appendix C. Changes since RFC2478 1461 1462 SPNEGO implementations in Microsoft Windows 2000/Windows 1463 XP/Windows Server 2003 have the following behavior: no mechlistMIC 1464 is produced and mechlistMIC is not processed if one is provided; 1465 if the initiator sends the last mechanism token, the acceptor will 1466 send back a negotiation token with an accept_complete state and no 1467 mechlistMIC token. In addition, an incorrect OID 1468 (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos 1469 Version 5 mechanism. 1470 1471 The following changes have been made to be compatible with these 1472 legacy implementations. 1473 1474 * NegTokenTarg is changed to negTokenResp and it is the message 1475 format for all subsequent negotiation tokens. 1476 * NegTokenInit is the message for the initial negotiation message 1477 and that message only. 1478 * mechTypes in negTokenInit is not optional. 1479 * If the selected mechanism is also the most preferred mechanism 1480 for both peers, it is safe to omit the MIC tokens. 1481 1482 If at least one of the two peers implements the updated pseudo 1483 mechanism in this document, the negotiation is protected. 1484 1485 The following changes are to address problems in RFC 2478. 1486 1487 * reqFlags is not protected therefore it should not impact the 1488 negotiation. 1489 * DER encoding is required. 1490 * GSS_GetMIC() input is clarified. 1491 * Per-message integrity services are requested for the negotiated 1492 mechanism. 1493 * Two MIC tokens are exchanged, one in each direction. 1494 1495 An implementation that conforms to this specification will not 1496 inter-operate with a strict 2748 implementation. Even if the new 1497 implementation always sends a mechlistMIC token, it will still fail 1498 to inter-operate. If it is a server, it will fail because it 1499 requests a mechlistMIC token using an option that older 1500 implementations simply do not support. Clients will tend to fail as 1501 well. 1502 1503 As an alternative to the approach chosen in this specification, we 1504 could have documented a correct behavior that is fully backward 1505 compatible with RFC 2478 and included an appendix on how to 1506 inter-operate with existing incorrect implementations of RFC 2478. 1507 1508 1509 1510 1511Zhu, et al. Expires July 27, 2005 [Page 27] 1512 1513Internet-Draft GSS-API Negotiation Mechanism January 2005 1514 1515 1516 As a practical matter, the SPNEGO implementers within the IETF have 1517 valued interoperability with the Microsoft implementations. We were 1518 unable to choose to maintain reasonable security guarantees, maintain 1519 interoperability with the Microsoft implementations and maintain 1520 interoperability with correct implementations of RFC 2478. The 1521 working group was not aware of any RFC 2478 implementations deployed 1522 on the Internet. Even if there are such implementations, it is 1523 unlikely that they will inter-operate because of a critical flaw in 1524 the description of the encoding of the mechanism list in RFC 2478. 1525 1526 With the approach taken in this specification, security is ensured 1527 between new implementations all the time while maintaining 1528 interoperability with the implementations deployed within the IETF 1529 community. The working group believes that this justifies breaking 1530 compatibility with a correct implementation of RFC 2478. 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567Zhu, et al. Expires July 27, 2005 [Page 28] 1568 1569Internet-Draft GSS-API Negotiation Mechanism January 2005 1570 1571 1572Appendix D. mechListMIC Computation Example 1573 1574 The following is an example to illustrate how the mechListMIC field 1575 would be computed. 1576 1577 The initial part of the DER encoding of NegTokenInit is constructed 1578 as follows (the "nn" are length encodings, possibly longer than one 1579 octet): 1580 1581 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) 1582 nn -- length 1583 1584 -- contents octets of the SEQUENCE begin with 1585 -- DER encoding of "[0] MechTypeList": 1586 A0 -- identifier octet for constructed [0] 1587 nn -- length 1588 1589 -- contents of the constructed [0] are DER encoding 1590 -- of MechTypeList (which is a SEQUENCE): 1591 30 -- identifier octet for constructed SEQUENCE 1592 nn -- length 1593 1594 -- contents octets of the SEQUENCE begin with 1595 -- DER encoding of OBJECT IDENTIFIER: 1596 06 -- identifier octet for primitive OBJECT IDENTIFIER 1597 09 -- length 1598 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 1599 -- {1 2 840 113554 1 2 2} 1600 1601 If a mechlistMIC needs to be generated (according to the rules in 1602 Section 5), it is computed by using the DER encoding of the type 1603 MechTypeList data from the initiator's NegTokenInit token as input to 1604 the GSS_GetMIC() function. In this case, the MIC would be computed 1605 over the following octets: 1606 1607 DER encoding of MechTypeList: 1608 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... 1609 1610 Note that the identifier octet and length octet(s) for constructed 1611 [0] (A0 nn) are not included in the MIC computation. 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623Zhu, et al. Expires July 27, 2005 [Page 29] 1624 1625Internet-Draft GSS-API Negotiation Mechanism January 2005 1626 1627 1628Intellectual Property Statement 1629 1630 The IETF takes no position regarding the validity or scope of any 1631 Intellectual Property Rights or other rights that might be claimed to 1632 pertain to the implementation or use of the technology described in 1633 this document or the extent to which any license under such rights 1634 might or might not be available; nor does it represent that it has 1635 made any independent effort to identify any such rights. Information 1636 on the procedures with respect to rights in RFC documents can be 1637 found in BCP 78 and BCP 79. 1638 1639 Copies of IPR disclosures made to the IETF Secretariat and any 1640 assurances of licenses to be made available, or the result of an 1641 attempt made to obtain a general license or permission for the use of 1642 such proprietary rights by implementers or users of this 1643 specification can be obtained from the IETF on-line IPR repository at 1644 http://www.ietf.org/ipr. 1645 1646 The IETF invites any interested party to bring to its attention any 1647 copyrights, patents or patent applications, or other proprietary 1648 rights that may cover technology that may be required to implement 1649 this standard. Please address the information to the IETF at 1650 ietf-ipr@ietf.org. 1651 1652 1653Disclaimer of Validity 1654 1655 This document and the information contained herein are provided on an 1656 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1657 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1658 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1659 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1660 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1661 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1662 1663 1664Copyright Statement 1665 1666 Copyright (C) The Internet Society (2005). This document is subject 1667 to the rights, licenses and restrictions contained in BCP 78, and 1668 except as set forth therein, the authors retain all their rights. 1669 1670 1671Acknowledgment 1672 1673 Funding for the RFC Editor function is currently provided by the 1674 Internet Society. 1675 1676 1677 1678 1679Zhu, et al. Expires July 27, 2005 [Page 30] 1680 1681