1NETWORK WORKING GROUP L. Zhu 2Internet-Draft P. Leach 3Obsoletes: 2478 (if approved) K. Jaganathan 4Expires: May 22, 2005 Microsoft Corporation 5 S. Harman 6 MIT 7 W. Ingersoll 8 Sun Microsystems 9 November 21, 2004 10 11 12 The Simple and Protected GSS-API Negotiation Mechanism 13 draft-ietf-kitten-2478bis-00 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 May 22, 2005. 41 42Copyright Notice 43 44 Copyright (C) The Internet Society (2004). 45 46Abstract 47 48 This document specifies a negotiation mechanism for the Generic 49 Security Service Application Program Interface (GSS-API) which is 50 51 52 53Zhu, et al. Expires May 22, 2005 [Page 1] 54 55Internet-Draft GSS-API Negotiation Mechanism November 2004 56 57 58 described in RFC 2743. 59 60 GSS-API peers can use this negotiation mechanism to choose from a 61 common set of security mechanisms. 62 63Table of Contents 64 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 . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 9 72 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 9 73 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 10 74 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 11 75 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13 76 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 81 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 19 82 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 19 83 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 19 84 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 21 85 Intellectual Property and Copyright Statements . . . . . . . . 22 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109Zhu, et al. Expires May 22, 2005 [Page 2] 110 111Internet-Draft GSS-API Negotiation Mechanism November 2004 112 113 1141. Introduction 115 116 The GSS-API [RFC2743] provides a generic interface which can be 117 layered atop different security mechanisms such that if communicating 118 peers acquire GSS-API credentials for the same security mechanism, 119 then a security context may be established between them (subject to 120 policy). However, GSS-API doesn't prescribe the method by which 121 GSS-API peers can establish whether they have a common security 122 mechanism. 123 124 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 125 defined here is a pseudo security mechanism, represented by the 126 Object Identifier iso.org.dod.internet.security.mechanism.snego 127 (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band 128 whether their credentials share common GSS-API security mechanism(s), 129 and if so, to invoke normal security context establishment for a 130 selected common security mechanism. This is most useful for 131 applications that are based on GSS-API implementations and multiple 132 mechanisms are shared between the peers. 133 134 The SPNEGO mechanism negotiation is based on the following 135 negotiation model: the initiator proposes a list of security 136 mechanism(s), in its preference order (favorite choice first), the 137 acceptor (also known as the target) either accepts the initiator's 138 preferred security mechanism (the first in the list), or chooses one 139 that is available from the offered list, or rejects the proposed 140 value(s). The target then informs the initiator of its choice. 141 142 Once a common security mechanism is chosen, it MAY also negotiate 143 mechanism-specific options during its context establishment, but that 144 will be inside the mechanism tokens and invisible to this protocol. 145 146 If per-message integrity services are available on the established 147 mechanism security context, the peers can then exchange MIC tokens to 148 ensure that the mechanism list was not tampered with. This MIC token 149 exchange is OPTIONAL if no interference could have material impact on 150 the negotiation, i.e., when the selected mechanism is the first 151 choice for both peers. 152 153 In order to avoid an extra round trip, the first security token of 154 the preferred mechanism SHOULD be embedded in the initial negotiation 155 message (as defined in Section 4.2). This mechanism token is 156 referred to as the optimistic token in this document. If the 157 selected mechanism matches the initiator's preferred mechanism, no 158 additional round trips need to be incurred by using this protocol. 159 In addition, by using the optimistic token, the initiator can recover 160 from a non-fatal error in producing the first token before a 161 mechanism can be selected. Implementations, however, MAY omit the 162 163 164 165Zhu, et al. Expires May 22, 2005 [Page 3] 166 167Internet-Draft GSS-API Negotiation Mechanism November 2004 168 169 170 optimistic token, to avoid the cost of generating it in cases where 171 the initiator's preferred mechanism is not selected by the acceptor. 172 173 SPNEGO uses the concepts developed in the GSS-API specification 174 [RFC2743]. The negotiation data is encapsulated in context-level 175 tokens. Therefore, callers of the GSS-API do not need to be aware of 176 the existence of the negotiation tokens but only of the new 177 pseudo-security mechanism. A failure in the negotiation phase causes 178 a major status code to be returned: GSS_S_BAD_MECH. 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 221Zhu, et al. Expires May 22, 2005 [Page 4] 222 223Internet-Draft GSS-API Negotiation Mechanism November 2004 224 225 2262. Conventions Used in This Document 227 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in [RFC2119]. 231 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 277Zhu, et al. Expires May 22, 2005 [Page 5] 278 279Internet-Draft GSS-API Negotiation Mechanism November 2004 280 281 2823. Negotiation Protocol 283 284 When the established mechanism context provides for integrity 285 protection, the mechanism negotiation can be protected. When 286 acquiring negotiated security mechanism tokens, per-message integrity 287 services are always requested by the SPNEGO mechanism. 288 289 When the established mechanism context supports per-message integrity 290 services, SPNEGO guarantees that the selected mechanism is mutually 291 preferred. 292 293 This section describes the negotiation process of this protocol. 294 2953.1 Negotiation Description 296 297 The first negotiation token sent by the initiator contains an ordered 298 list of mechanisms (in preference order, favorite choice first), and 299 optionally the initial security token for the preferred mechanism of 300 the initiator (i.e., the first in the list). The list of security 301 mechanisms available for negotiation is based on the credentials 302 being used. 303 304 The target then processes the token from the initiator. This will 305 result in one of four possible states (as defined in Section 4.2.2): 306 accept_completed, accept_incomplete, reject, or request_mic. A 307 reject state will terminate the negotiation; an accept_completed 308 state indicates that not only was the initiator-selected mechanism 309 acceptable to the target, but that the initial token was sufficient 310 to complete the authentication; an accept_incomplete state indicates 311 that further message exchange is needed but the MIC token exchange as 312 described in Section 5 is OPITONAL; a request_mic state (this state 313 can only be present in the first reply message from the target) 314 indicates the MIC token exchange is REQUIRED if per-message integrity 315 services are available. 316 317 Unless the preference order is specified by the application (see 318 Appendix A), the policy by which the target chooses a mechanism is an 319 implementation-specific local matter. In the absence of application 320 specified preference order or other policy, the target SHALL choose 321 the first mechanism in the initiator proposed list for which it has 322 valid credentials. 323 324 In case of a successful negotiation, the security mechanism in the 325 first reply message represents the value suitable for the target, and 326 picked up from the list offered by the initiator. A context level 327 token for a reject state is OPTIONAL. 328 329 Once a mechanism has been selected, the tokens specific to the 330 331 332 333Zhu, et al. Expires May 22, 2005 [Page 6] 334 335Internet-Draft GSS-API Negotiation Mechanism November 2004 336 337 338 selected mechanism are carried within the negotiation tokens. 339 340 Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the 341 mechanism list as seen by the target. 342 343 To avoid conflicts with the use of MIC tokens by SPNEGO, 344 partially-established contexts are not used for per-message calls: 345 the prot_ready_state [RFC2743] will be false even if the underlying 346 mechanism would return true natively. 347 3483.2 Negotiation Procedure 349 350 The basic form of the procedure assumes that per-message integrity 351 services are available on the established mechanism context, and it 352 is summarized as follows: 353 354 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 355 but requests (either explicitly, with the negotiation mechanism, 356 or through accepting a default, when the default is this 357 negotiation mechanism) that SPNEGO is used. 358 359 (b) The initiator GSS-API implementation emits a negotiation token 360 containing a list of supported security mechanisms (possible just 361 one mechanism) for the credentials used for this context 362 establishment, and optionally an initial security token for the 363 first mechanism from that list. 364 365 (c) The GSS-API initiator application sends the token to the target 366 application. The GSS-API target application deposits the token 367 through invoking GSS_Accept_sec_context(). The acceptor will do 368 one of the following: 369 370 (I) No proposed mechanism is acceptable, the negotiation SHALL be 371 terminated. GSS_Accept_sec_context indicates GSS_S_BAD_MECH. 372 The acceptor MAY output a negotiation token containing a reject 373 state. 374 375 (II) If either the initiator's preferred mechanism is not accepted 376 by the target, or this mechanism is accepted but it is not the 377 most preferred mechanism available for the acceptor (see 378 Section 3.1 and Section 5), GSS_Accept_sec_context() indicates 379 GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation 380 token containing a request_mic state. 381 382 (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE 383 or GSS_S_CONTINUE_NEEDED, depending on if at least one 384 additional negotiation token from the initiator is needed to 385 establish this context. The acceptor outputs a negotiation 386 387 388 389Zhu, et al. Expires May 22, 2005 [Page 7] 390 391Internet-Draft GSS-API Negotiation Mechanism November 2004 392 393 394 token containing an accept_complete or accept_incomplete state, 395 respectively. 396 397 If the initiator's preferred mechanism is accepted, and an 398 optimistic mechanism token was included, this mechanism token MUST 399 be deposited to the selected mechanism through invoking 400 GSS_Accept_sec_context() and if a response mechanism token is 401 emitted, it MUST be included in the response negotiation token. 402 Otherwise, the target will not emit a response mechanism token in 403 the first reply. 404 405 (d) The GSS-API target application returns the negotiation token to 406 the initiator application. The GSS-API initiator application 407 deposits the token through invoking GSS_Init_sec_context(). The 408 security context initialization is then continued according to the 409 standard GSS-API conventions for the selected mechanism, where the 410 tokens of the selected mechanism are encapsulated until the 411 GSS_S_COMPLETE is returned for both the initiator and the target 412 by the selected security mechanism. 413 414 (e) MIC tokens are then either skipped or exchanged according to 415 Section 5. 416 417 Note that the *_req_flag input parameters for context establishment 418 are relative to the selected mechanism, as are the *_state output 419 parameters. i.e., these parameters are not applicable to the 420 negotiation process per se. 421 422 On receipt of a negotiation token on the target side, a GSS-API 423 implementation that does not support negotiation would indicate the 424 GSS_S_BAD_MECH status as if a particular basic security mechanism had 425 been requested but was not supported. 426 427 When GSS_Acquire_cred is invoked with this SPNEGO mechanism as 428 desired_mechs, an implementation-specific default credential is used 429 to carry on the negotiation. A set of mechanisms as specified 430 locally by the system administrator is then available for 431 negotiation. If there is a desire for the caller to make its own 432 choice, then an additional API has to be used (see Appendix A). 433 434 435 436 437 438 439 440 441 442 443 444 445Zhu, et al. Expires May 22, 2005 [Page 8] 446 447Internet-Draft GSS-API Negotiation Mechanism November 2004 448 449 4504. Token Definitions 451 452 The type definitions in this section assume an ASN.1 module 453 definition of the following form: 454 455 456 SPNEGOASNOneSpec { 457 iso(1) identified-organization(3) dod(6) internet(1) 458 security(5) mechanism(5) snego (2) modules(4) spec2(2) 459 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 460 461 -- rest of definitions here 462 463 END 464 465 466 This specifies that the tagging context for the module will be 467 explicit and non-automatic. 468 469 The encoding of SPNEGO protocol messages shall obey the Distinguished 470 Encoding Rules (DER) of ASN.1 as described in [X690]. 471 4724.1 Mechanism Types 473 474 In this negotiation model, each OID represents one GSS-API mechanism 475 or one variant of it according to [RFC2743]. 476 477 478 MechType ::= OBJECT IDENTIFIER 479 -- OID represents each security mechanism as suggested by 480 -- [RFC2743] 481 482 MechTypeList ::= SEQUENCE OF MechType 483 484 4854.2 Negotiation Tokens 486 487 The syntax of the initial negotiation tokens follows the 488 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 489 SPNEGO pseudo mechanism is identified by the Object Identifier 490 specified in Section 1. Subsequent tokens are not encapsulated in 491 this GSS-API generic token framing. 492 493 This section specifies the syntax of the inner token for the initial 494 message, and the syntax of subsequent context establishment tokens. 495 496 NegotiationToken ::= CHOICE { 497 negTokenInit [0] NegTokenInit, 498 499 500 501Zhu, et al. Expires May 22, 2005 [Page 9] 502 503Internet-Draft GSS-API Negotiation Mechanism November 2004 504 505 506 negTokenResp [1] negTokenResp 507 } 508 509 510 5114.2.1 negTokenInit 512 513 NegTokenInit ::= SEQUENCE { 514 mechTypes [0] MechTypeList, 515 reqFlags [1] ContextFlags OPTIONAL, 516 mechToken [2] OCTET STRING OPTIONAL, 517 mechListMIC [3] OCTET STRING OPTIONAL, 518 ... 519 } 520 ContextFlags ::= BIT STRING { 521 delegFlag (0), 522 mutualFlag (1), 523 replayFlag (2), 524 sequenceFlag (3), 525 anonFlag (4), 526 confFlag (5), 527 integFlag (6) 528 } 529 530 This is the syntax for the inner token of the initial negotiation 531 message. 532 533 mechTypes 534 535 This field contains one or more security mechanisms available 536 for the initiator in preference order (favorite choice first). 537 538 reqFlags 539 540 This field, if present, contains the service options that are 541 requested to establish the context. The context flags SHOULD 542 be filled in from the req_flags parameter of 543 GSS_Init_sec_context(). This field SHALL NOT have impact on 544 the negotiation. 545 546 mechToken 547 548 This field, is present, contains the optimistic security 549 mechanism token. 550 551 552 553 554 555 556 557Zhu, et al. Expires May 22, 2005 [Page 10] 558 559Internet-Draft GSS-API Negotiation Mechanism November 2004 560 561 562 mechlistMIC 563 564 This field, is present, contains a MIC token, which is computed 565 according to Section 5, for the mechanism list in the initial 566 negotiation message. 567 568 5694.2.2 negTokenResp 570 571 NegTokenResp ::= SEQUENCE { 572 negResult [0] ENUMERATED { 573 accept_completed (0), 574 accept_incomplete (1), 575 reject (2), 576 request_mic (3) 577 }, 578 supportedMech [1] MechType OPTIONAL, 579 responseToken [2] OCTET STRING OPTIONAL, 580 mechListMIC [3] OCTET STRING OPTIONAL, 581 ... 582 } 583 584 This is the syntax for all subsequent negotiation messages. 585 586 negResult 587 588 This field contains the state of the negotiation. This can be: 589 590 accept_completed 591 No further negotiation message from the peer is expected, 592 and the security context is established for the sender. 593 594 accept_incomplete 595 At least one more negotiation message from the peer is 596 needed to establish the security context. 597 598 reject 599 The sender terminates the negotiation. 600 601 request_mic 602 The sender indicates that the exchange of MIC tokens, as 603 described in Section 5, will be REQUIRED if per-message 604 integrity services are available on the mechanism context to 605 be established. This value SHALL only be present in the 606 first reply from the target. 607 608 609 610 611 612 613Zhu, et al. Expires May 22, 2005 [Page 11] 614 615Internet-Draft GSS-API Negotiation Mechanism November 2004 616 617 618 supportedMech 619 620 This field SHALL only be present in the first reply from the 621 target. It is a choice from the mechanism(s) offered by the 622 initiator. 623 624 ResponseToken 625 626 The field, if present, contains tokens specific to the 627 mechanism selected. 628 629 mechlistMIC 630 631 This field, is present, contains a MIC token, which is computed 632 according to Section 5, for the mechanism list in the initial 633 negotiation message. 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669Zhu, et al. Expires May 22, 2005 [Page 12] 670 671Internet-Draft GSS-API Negotiation Mechanism November 2004 672 673 6745. Processing of mechListMIC 675 676 If the mechanism selected by the negotiation does not support 677 integrity protection, then no mechlistMIC token is used. Otherwise 678 if the initiator's preferred mechanism is accepted and it is also the 679 most preferred mechanism available for the acceptor (there is no 680 mechanism which, had it been present in the mechanism list, the 681 acceptor would have preferred over the accepted mechanism), then the 682 MIC token exchange, as described later in this section, is OPTIONAL. 683 In all other cases, MIC tokens MUST be exchanged after the mechanism 684 context is fully established. 685 686 It is assumed that per-message integrity services are available on 687 the established mechanism context in the following procedure for 688 processing MIC tokens of the initiator's mechanism list. 689 690 a) The mechlistMIC token (or simply the MIC token) is computed 691 through invoking GSS_GetMIC(): the input context_handle is the 692 established mechanism context, the input qop_req is 0, and the 693 input message is the mechTypes field in the initial negotiation 694 message (only the "value" portion, omitting the tag and length, of 695 the ASN.1 encoding for that field is included). 696 697 b) If the selected mechanism uses an even number of mechanism tokens 698 (namely the acceptor sends the last mechanism token), the acceptor 699 does the following when emitting the negotiation message 700 containing the last mechanism token: if the MIC token exchange is 701 not required, GSS_Accept_sec_context() either indicates 702 GSS_S_COMPLETE and does not include a mechlistMIC token, or 703 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 704 and an accept_incomplete state; if the MIC token exchange is 705 required, GSS_Accept_sec_context() indicates 706 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 707 Acceptors who wish to be compatible with legacy Windows SPNEGO 708 implementations as described in Appendix B shall not generate a 709 mechlistMIC token when the MIC token exchange is not required. 710 The initiator then processes the last mechanism token, and does 711 one of the following: 712 713 (I) If a mechlistMIC token was included, and is correctly 714 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 715 output negotiation message contains a mechlistMIC token, and an 716 accept_complete state. The acceptor MUST then verify this 717 mechlistMIC token. 718 719 720 721 722 723 724 725Zhu, et al. Expires May 22, 2005 [Page 13] 726 727Internet-Draft GSS-API Negotiation Mechanism November 2004 728 729 730 (II) If a mechlistMIC token was included but is incorrect, the 731 negotiation SHALL be terminated. GSS_Accept_sec_context() 732 indicates GSS_S_DEFECTIVE_TOKEN. 733 734 (III) If no mechlistMIC token was included, and the MIC token 735 exchange is not required, GSS_Init_sec_context() indicates 736 GSS_S_COMPLETE with no output token. 737 738 (IV) If no mechlistMIC token was included, but the MIC token 739 exchange is required, the negotiation SHALL be terminated. 740 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 741 742 c) In the case that the chosen mechanism uses an odd number of 743 mechanism tokens (namely the initiator sends the last mechanism 744 token), the initiator does the following when emitting the 745 negotiation message containing the last mechanism token: if the 746 negResult state was request_mic in the first reply from the 747 target, a mechlistMIC token MUST be included, otherwise the 748 mechlistMIC token is OPTIONAL. GSS_Init_sec_context() indicates 749 GSS_S_CONTINUE_NEEDED. Initiators who wish to be compatible with 750 legacy Windows SPNEGO implementations as described in Appendix B 751 shall not generate a mechlistMIC token when the MIC token exchange 752 is not required. The acceptor then processes the last mechanism 753 token, and does one of the following: 754 755 (I) If a mechlistMIC token was included, and is correctly 756 verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE. 757 The output negotiation message contains a mechlistMIC token, 758 and an accept_complete state. The initiator MUST then verify 759 this mechlistMIC token. 760 761 (II) If a mechlistMIC token was included but is incorrect, the 762 negotiation SHALL be terminated. GSS_Accept_sec_context() 763 indicates GSS_S_DEFECTIVE_TOKEN. 764 765 (III) If no mechlistMIC token was included and the mechlistMIC 766 token exchange is not required, GSS_Accept_sec_context() 767 indicates GSS_S_COMPLETE. The output negotiation message 768 contains an accept_complete state. 769 770 (IV) If no mechlistMIC token was included and the acceptor sent a 771 request_mic state in the first reply message (the exchange of 772 MIC tokens is required), the negotiation SHALL be terminated. 773 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 774 775 776 777 778 779 780 781Zhu, et al. Expires May 22, 2005 [Page 14] 782 783Internet-Draft GSS-API Negotiation Mechanism November 2004 784 785 7866. Extensibility 787 788 Two mechanisms are provided by extensibility. First, the ASN.1 789 structures in this specification MAY be expanded by IETF standards 790 action. Implementations receiving unknown fields MUST ignore these 791 fields. 792 793 Secondly, OIDs corresponding to a desired mechanism attribute may be 794 included in the set of preferred mechanisms by an initiator. The 795 acceptor can choose to honor this request by preferring mechanisms 796 that have that attribute. Future work within the Kitten working 797 group is expected to standardize common attributes that SPNEGO 798 mechanisms may wish to support. At this time it is sufficient to say 799 that initiators MAY include OIDs that do not correspond to mechanisms 800 but instead correspond to desired mechanism attributes in their 801 requests. Such OIDs MAY influence the acceptor's choice of 802 mechanism. As discussed in Section 5, if there are mechanisms that 803 if present in the initiator's list of mechanisms might be preferred 804 by the acceptor to the initiator's preferred mechanism, the acceptor 805 MUST demand the MIC token exchange. As a consequence, acceptors MUST 806 demand the MIC token exchange if they support negotiation of 807 attributes not available in the initiator's preferred mechanism 808 regardless of whether the initiator actually requested these 809 attributes. 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837Zhu, et al. Expires May 22, 2005 [Page 15] 838 839Internet-Draft GSS-API Negotiation Mechanism November 2004 840 841 8427. Security Considerations 843 844 In order to produce the MIC token for the mechanism list, the 845 mechanism must provide integrity protection. When the selected 846 mechanism does not support integrity protection, then the negotiation 847 is vulnerable: an active attacker can force it to use a security 848 mechanism that is not mutually preferred but is acceptable anyway to 849 the target. 850 851 When per-message integrity services are available on the established 852 mechanism context, and there was an alteration of the mechanism list 853 by an adversary such that a common mechanism that is not mutually 854 preferred could be selected, this protocol provides the following 855 guarantees: if the last mechanism token is sent by the initiator, 856 both peers shall fail; if the last mechanism token is sent by the 857 acceptor, the acceptor shall not complete and the initiator at worst 858 shall complete with its preferred mechanism being selected. The 859 negotiation may not be terminated if an alteration was made but it 860 had no material impact. 861 862 The protection of the negotiation depends on the strength of the 863 integrity protection. In particular, the strength of SPNEGO is no 864 stronger than the integrity protection of the weakest mechanism 865 acceptable to GSS-API peers. 866 867 In all cases, the communicating peers are exposed to the denial of 868 service threat. 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893Zhu, et al. Expires May 22, 2005 [Page 16] 894 895Internet-Draft GSS-API Negotiation Mechanism November 2004 896 897 8988. Acknowledgments 899 900 The authors wish to thank Nicolas Williams, Ken Raeburn, Jeff Altman, 901 Cristian Ilac and Martin Rex for their comments and suggestions on 902 earlier versions of this document. 903 904 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 905 [RFC2478], of which some of the text has been retained in this 906 document. 907 9089 References 909 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 912 913 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 914 Negotiation Mechanism", RFC 2478, December 1998. 915 916 [RFC2743] Linn, J., "Generic Security Service Application Program 917 Interface Version 2, Update 1", RFC 2743, January 2000. 918 919 [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules 920 (BER), Canonical Encoding Rules (CER) and Distinguished 921 Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 922 ISO/IEC International Standard 8825-1:1998. 923 924Authors' Addresses 925 926 Larry Zhu 927 Microsoft Corporation 928 One Microsoft Way 929 Redmond, WA 98052 930 US 931 932 EMail: lzhu@microsoft.com 933 934 935 Paul Leach 936 Microsoft Corporation 937 One Microsoft Way 938 Redmond, WA 98052 939 US 940 941 EMail: paulle@microsoft.com 942 943 944 945 946 947 948Zhu, et al. Expires May 22, 2005 [Page 17] 949 950Internet-Draft GSS-API Negotiation Mechanism November 2004 951 952 953 Karthik Jaganathan 954 Microsoft Corporation 955 One Microsoft Way 956 Redmond, WA 98052 957 US 958 959 EMail: karthikj@microsoft.com 960 961 962 Sam Hartman 963 Massachusetts Institute of Technology 964 77 Massachusetts Avenue 965 Cambridge, MA 02139 966 US 967 968 EMail: hartmans@mit.edu 969 970 971 Wyllys Ingersoll 972 Sun Microsystems 973 1775 Wiehle Avenue, 2nd Floor 974 Reston, VA 20190 975 US 976 977 EMail: wyllys.ingersoll@sun.com 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004Zhu, et al. Expires May 22, 2005 [Page 18] 1005 1006Internet-Draft GSS-API Negotiation Mechanism November 2004 1007 1008 1009Appendix A. GSS-API Negotiation Support API 1010 1011 In order to provide to a GSS-API caller (either the initiator or the 1012 target or both) the ability to choose among the set of supported 1013 mechanisms a reduced set of mechanisms for negotiation, two 1014 additional APIs are defined: 1015 1016 o GSS_Get_neg_mechs() indicates the set of security mechanisms 1017 available on the local system to the caller for negotiation, based 1018 on the credentials being used. 1019 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 1020 used on the local system by the caller for negotiation, for the 1021 given credentials. 1022 1023A.1 GSS_Set_neg_mechs call 1024 1025 Inputs: 1026 1027 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 1028 -- credentials 1029 o mech_set SET OF OBJECT IDENTIFIER 1030 1031 Outputs: 1032 1033 o major_status INTEGER, 1034 o minor_status INTEGER 1035 1036 Return major_status codes: 1037 1038 o GSS_S_COMPLETE indicates that the set of security mechanisms 1039 available for negotiation has been set to mech_set. 1040 o GSS_S_FAILURE indicates that the requested operation could not be 1041 performed for reasons unspecified at the GSS-API level. 1042 1043 Allows callers to specify the set of security mechanisms that may be 1044 negotiated with the credential identified by cred_handle. This call 1045 is intended for support of specialized callers who need to restrict 1046 the set of negotiable security mechanisms from the set of all 1047 security mechanisms available to the caller (based on available 1048 credentials). Note that if more than one mechanism is specified in 1049 mech_set, the order in which those mechanisms are specified implies a 1050 relative preference. 1051 1052A.2 GSS_Get_neg_mechs call 1053 1054 Input: 1055 1056 1057 1058 1059 1060Zhu, et al. Expires May 22, 2005 [Page 19] 1061 1062Internet-Draft GSS-API Negotiation Mechanism November 2004 1063 1064 1065 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 1066 -- credentials 1067 1068 Outputs: 1069 1070 o major_status INTEGER, 1071 o minor_status INTEGER, 1072 o mech_set SET OF OBJECT IDENTIFIER 1073 1074 Return major_status codes: 1075 1076 o GSS_S_COMPLETE indicates that the set of security mechanisms 1077 available for negotiation has been returned in mech_set. 1078 o GSS_S_FAILURE indicates that the requested operation could not be 1079 performed for reasons unspecified at the GSS-API level. 1080 1081 Allows callers to determine the set of security mechanisms available 1082 for negotiation with the credential identified by cred_handle. This 1083 call is intended for support of specialized callers who need to 1084 reduce the set of negotiable security mechanisms from the set of 1085 supported security mechanisms available to the caller (based on 1086 available credentials). 1087 1088 Note: The GSS_Indicate_mechs() function indicates the full set of 1089 mechanism types available on the local system. Since this call has 1090 no input parameter, the returned set is not necessarily available for 1091 all credentials. 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116Zhu, et al. Expires May 22, 2005 [Page 20] 1117 1118Internet-Draft GSS-API Negotiation Mechanism November 2004 1119 1120 1121Appendix B. Changes since RFC2478 1122 1123 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 1124 2003 have the following behavior: no mechlistMIC is produced, and 1125 mechlistMIC is not processed if one is provided; if the initiator 1126 sends the last mechanism token, the acceptor will send back a 1127 negotiation token with an accept_complete state and no mechlistMIC 1128 token. In addition, the OID (1.2.840.48018.1.2.2) can be used to 1129 identify the GSS-API Kerberos Version 5 mechanism. 1130 1131 The following changes have been made to be compatible with these 1132 legacy implementations. 1133 1134 * NegTokenTarg is changed to negTokenResp and it is the message 1135 format for all subsequent negotiation tokens. 1136 * NegTokenInit is the message for the initial token and that 1137 token only. 1138 * mechTypes in negTokenInit is not optional. 1139 * negResult is not optional in the negTokenResp token. 1140 * Two MIC tokens are exchanged, one in each direction. 1141 * If the selected mechanism is also the most preferred mechanism 1142 for both peers, it is safe to omit the MIC tokens. 1143 1144 If at least one of the two peers implements the pseudo mechanism 1145 in this document, the negotiation is protected. 1146 1147 The following changes are to address the problems in RFC 2478. 1148 1149 * reqFlags is not protected therefore it should not impact the 1150 negotiation. 1151 * DER encoding is required. 1152 * GSS_GetMIC() input is clarified. 1153 * Per-message integrity services are requested for the negotiated 1154 mechanism. 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172Zhu, et al. Expires May 22, 2005 [Page 21] 1173 1174Internet-Draft GSS-API Negotiation Mechanism November 2004 1175 1176 1177Intellectual Property Statement 1178 1179 The IETF takes no position regarding the validity or scope of any 1180 Intellectual Property Rights or other rights that might be claimed to 1181 pertain to the implementation or use of the technology described in 1182 this document or the extent to which any license under such rights 1183 might or might not be available; nor does it represent that it has 1184 made any independent effort to identify any such rights. Information 1185 on the procedures with respect to rights in RFC documents can be 1186 found in BCP 78 and BCP 79. 1187 1188 Copies of IPR disclosures made to the IETF Secretariat and any 1189 assurances of licenses to be made available, or the result of an 1190 attempt made to obtain a general license or permission for the use of 1191 such proprietary rights by implementers or users of this 1192 specification can be obtained from the IETF on-line IPR repository at 1193 http://www.ietf.org/ipr. 1194 1195 The IETF invites any interested party to bring to its attention any 1196 copyrights, patents or patent applications, or other proprietary 1197 rights that may cover technology that may be required to implement 1198 this standard. Please address the information to the IETF at 1199 ietf-ipr@ietf.org. 1200 1201 1202Disclaimer of Validity 1203 1204 This document and the information contained herein are provided on an 1205 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1206 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1207 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1208 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1209 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1211 1212 1213Copyright Statement 1214 1215 Copyright (C) The Internet Society (2004). This document is subject 1216 to the rights, licenses and restrictions contained in BCP 78, and 1217 except as set forth therein, the authors retain all their rights. 1218 1219 1220Acknowledgment 1221 1222 Funding for the RFC Editor function is currently provided by the 1223 Internet Society. 1224 1225 1226 1227 1228Zhu, et al. Expires May 22, 2005 [Page 22] 1229 1230 1231