1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft P. Leach 5Obsoletes: 2478 (if approved) K. Jaganathan 6Expires: June 1, 2005 Microsoft Corporation 7 W. Ingersoll 8 Sun Microsystems 9 December 1, 2004 10 11 12 The Simple and Protected GSS-API Negotiation Mechanism 13 draft-ietf-kitten-2478bis 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 June 1, 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 described in RFC 2743. 51 52 53 54 55Zhu, et al. Expires June 1, 2005 [Page 1] 56 57Internet-Draft GSS-API Negotiation Mechanism December 2004 58 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 80 10. Normative References . . . . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 82 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21 83 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21 84 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21 85 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23 86 Intellectual Property and Copyright Statements . . . . . . . . 25 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Zhu, et al. Expires June 1, 2005 [Page 2] 112 113Internet-Draft GSS-API Negotiation Mechanism December 2004 114 115 1161. Introduction 117 118 The GSS-API [RFC2743] provides a generic interface which can be 119 layered atop different security mechanisms such that if communicating 120 peers acquire GSS-API credentials for the same security mechanism, 121 then a security context may be established between them (subject to 122 policy). However, GSS-API does not prescribe the method by which 123 GSS-API peers can establish whether they have a common security 124 mechanism. 125 126 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 127 defined here is a pseudo security mechanism, represented by the 128 Object Identifier iso.org.dod.internet.security.mechanism.snego 129 (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band 130 whether their credentials share common GSS-API security mechanism(s), 131 and if so, to invoke normal security context establishment for a 132 selected common security mechanism. This is most useful for 133 applications which are based on GSS-API implementations and share 134 multiple mechanisms between the peers. 135 136 The SPNEGO mechanism negotiation is based on the following 137 negotiation model: the initiator proposes a list of security 138 mechanism(s), in decreasing preference order (favorite choice first), 139 the acceptor (also known as the target) either accepts the 140 initiator's preferred security mechanism (the first in the list), or 141 chooses one that is available from the offered list, or rejects the 142 proposed value(s). The target then informs the initiator of its 143 choice. 144 145 Once a common security mechanism is chosen, mechanism-specific 146 options MAY be negotiated as part of the selected mechanism's context 147 establishment. These negotiations (if any) are internal to the 148 mechanism and opaque to the SPNEGO protocol. As such they are 149 outside the scope of this document. 150 151 If per-message integrity services are available on the established 152 mechanism security context, then the peers can exchange MIC tokens to 153 ensure that the mechanism list was not tampered with. This MIC token 154 exchange is OPTIONAL if the selected mechanism is the most preferred 155 choice of both peers (see Section 5). 156 157 In order to avoid an extra round trip, the first security token of 158 the initiator's preferred mechanism SHOULD be embedded in the initial 159 negotiation message (as defined in Section 4.2). This mechanism 160 token is referred to as the optimistic mechanism token in this 161 document. If the selected mechanism matches the initiator's 162 preferred mechanism, no additional round trips need be incurred by 163 using this protocol. In addition, using the optimistic mechanism 164 165 166 167Zhu, et al. Expires June 1, 2005 [Page 3] 168 169Internet-Draft GSS-API Negotiation Mechanism December 2004 170 171 172 token allows the initiator to recover from non-fatal errors while 173 producing the first mechanism token before a mechanism can be 174 selected. Implementations MAY omit the optimistic mechanism token to 175 avoid the cost of generating it in cases where the initiator's 176 preferred mechanism is not selected by the acceptor. 177 178 SPNEGO relies the concepts developed in the GSS-API specification 179 [RFC2743]. The negotiation data is encapsulated in context-level 180 tokens. Therefore, callers of the GSS-API do not need to be aware of 181 the existence of the negotiation tokens but only of the new 182 pseudo-security mechanism. A failure in the negotiation phase causes 183 a major status code to be returned: GSS_S_BAD_MECH. 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 222 223Zhu, et al. Expires June 1, 2005 [Page 4] 224 225Internet-Draft GSS-API Negotiation Mechanism December 2004 226 227 2282. Conventions Used in This Document 229 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119]. 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 278 279Zhu, et al. Expires June 1, 2005 [Page 5] 280 281Internet-Draft GSS-API Negotiation Mechanism December 2004 282 283 2843. Negotiation Protocol 285 286 When the established mechanism context provides integrity protection, 287 the mechanism negotiation can be protected. When acquiring 288 negotiated security mechanism tokens, per-message integrity services 289 are always requested by the SPNEGO mechanism. 290 291 When the established mechanism context supports per-message integrity 292 services, SPNEGO guarantees that the selected mechanism is mutually 293 preferred. 294 295 This section describes the negotiation process of this protocol. 296 2973.1 Negotiation Description 298 299 The first negotiation token sent by the initiator contains an ordered 300 list of mechanisms (in decreasing preference order, favorite 301 mechanism first), and optionally the initial mechanism token for the 302 preferred mechanism of the initiator (i.e., the first in the list). 303 The list of security mechanisms available for negotiation is based on 304 the credentials being used. 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 accept_completed, accept_incomplete, reject, or request_mic. A 309 reject state will terminate the negotiation; an accept_completed 310 state indicates that not only was the initiator-selected mechanism 311 acceptable to the target, but also that the initial mechanism token 312 was sufficient to complete the authentication; an accept_incomplete 313 state indicates that further message exchange is needed but the MIC 314 token exchange as described in Section 5 is OPTIONAL; a request_mic 315 state (this state can only be present in the first reply message from 316 the target) indicates the MIC token exchange is REQUIRED if 317 per-message integrity services are available. 318 319 Unless the preference order is specified by the application (see 320 Appendix A), the policy by which the target chooses a mechanism is an 321 implementation-specific local matter. In the absence of an 322 application specified preference order or other policy, the target 323 SHALL choose the first mechanism in the initiator proposed list for 324 which it has valid credentials. 325 326 In case of a successful negotiation, the security mechanism in the 327 first reply message represents the value suitable for the target, 328 picked up from the list offered by the initiator. A context level 329 token for a reject state is OPTIONAL. 330 331 Once a mechanism has been selected, the tokens specific to the 332 333 334 335Zhu, et al. Expires June 1, 2005 [Page 6] 336 337Internet-Draft GSS-API Negotiation Mechanism December 2004 338 339 340 selected mechanism are carried within the negotiation tokens. 341 342 Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the 343 mechanism list received by the target. 344 345 To avoid conflicts with the use of MIC tokens by SPNEGO, 346 partially-established contexts are not used for per-message calls: 347 the prot_ready_state [RFC2743] will be false even if the underlying 348 mechanism would return true natively. 349 3503.2 Negotiation Procedure 351 352 The basic form of the procedure assumes that per-message integrity 353 services are available on the established mechanism context, and it 354 is summarized as follows: 355 356 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 357 but requests that SPNEGO be used. SPNEGO can either be explicity 358 requested or accepted as the default mechanism. 359 360 (b) The initiator GSS-API implementation emits a negotiation token 361 containing a list of one or more security mechanisms that are 362 available based on the credentials used for this context 363 establishment, and optionally the initial mechanism token for the 364 first mechanism in the list. 365 366 (c) The GSS-API initiator application sends the token to the target 367 application. The GSS-API target application deposits the token by 368 invoking GSS_Accept_sec_context(). The acceptor will do one of 369 the following: 370 371 (I) If none of the proposed mechanisms are acceptable, the 372 negotiation SHALL be terminated. GSS_Accept_sec_context 373 indicates GSS_S_BAD_MECH. The acceptor MAY output a 374 negotiation token containing a reject state. 375 376 (II) If either the initiator's preferred mechanism is not accepted 377 by the target or this mechanism is accepted but it is not the 378 acceptor's most preferred mechanism (see Section 3.1 and 379 Section 5), GSS_Accept_sec_context() indicates 380 GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation 381 token containing a request_mic state. 382 383 (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE 384 or GSS_S_CONTINUE_NEEDED depending on if at least one 385 additional negotiation token from the initiator is needed to 386 establish this context. The acceptor outputs a negotiation 387 token containing an accept_complete or accept_incomplete state, 388 389 390 391Zhu, et al. Expires June 1, 2005 [Page 7] 392 393Internet-Draft GSS-API Negotiation Mechanism December 2004 394 395 396 respectively. 397 398 If the initiator's preferred mechanism is accepted, and an 399 optimistic mechanism token was included, this mechanism token MUST 400 be deposited to the selected mechanism by invoking 401 GSS_Accept_sec_context() and if a response mechanism token is 402 emitted, it MUST be included in the response negotiation token. 403 Otherwise, the target will not emit a response mechanism token in 404 the first reply. 405 406 (d) The GSS-API target application returns the negotiation token to 407 the initiator application. The GSS-API initiator application 408 deposits the token by invoking GSS_Init_sec_context(). The 409 security context initialization is then continued according to the 410 standard GSS-API conventions for the selected mechanism, where the 411 tokens of the selected mechanism are encapsulated until the 412 GSS_S_COMPLETE is returned for both the initiator and the target 413 by the selected security mechanism. 414 415 (e) MIC tokens are then either skipped or exchanged according to 416 Section 5. 417 418 Note that the *_req_flag input parameters for context establishment 419 are relative to the selected mechanism, as are the *_state output 420 parameters. i.e., these parameters are not applicable to the 421 negotiation process per se. 422 423 On receipt of a negotiation token on the target side, a GSS-API 424 implementation that does not support negotiation would indicate the 425 GSS_S_BAD_MECH status as if a particular basic security mechanism had 426 been requested and was not supported. 427 428 When GSS_Acquire_cred is invoked with this negotiation mechanism in 429 the desired_mechs, an implementation-specific default credential is 430 used to carry on the negotiation. A set of mechanisms as specified 431 locally by the system administrator is then available for 432 negotiation. If there is a desire for the caller to make its own 433 choice, then an additional API has to be used (see Appendix A). 434 435 436 437 438 439 440 441 442 443 444 445 446 447Zhu, et al. Expires June 1, 2005 [Page 8] 448 449Internet-Draft GSS-API Negotiation Mechanism December 2004 450 451 4524. Token Definitions 453 454 The type definitions in this section assume an ASN.1 module 455 definition of the following form: 456 457 458 SPNEGOASNOneSpec { 459 iso(1) identified-organization(3) dod(6) internet(1) 460 security(5) mechanism(5) snego (2) modules(4) spec2(2) 461 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 462 463 -- rest of definitions here 464 465 END 466 467 468 This specifies that the tagging context for the module will be 469 explicit and non-automatic. 470 471 The encoding of SPNEGO protocol messages shall obey the Distinguished 472 Encoding Rules (DER) of ASN.1 as described in [X690]. 473 4744.1 Mechanism Types 475 476 In this negotiation model, each OID represents one GSS-API mechanism 477 or one variant (see Section 6) of it according to [RFC2743]. 478 479 480 MechType ::= OBJECT IDENTIFIER 481 -- OID represents each security mechanism as suggested by 482 -- [RFC2743] 483 484 MechTypeList ::= SEQUENCE OF MechType 485 486 4874.2 Negotiation Tokens 488 489 The syntax of the initial negotiation tokens follows the 490 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 491 SPNEGO pseudo mechanism is identified by the Object Identifier 492 specified in Section 1. Subsequent tokens are not encapsulated in 493 this GSS-API generic token framing. 494 495 This section specifies the syntax of the inner token for the initial 496 message and the syntax of subsequent context establishment tokens. 497 498 NegotiationToken ::= CHOICE { 499 negTokenInit [0] NegTokenInit, 500 501 502 503Zhu, et al. Expires June 1, 2005 [Page 9] 504 505Internet-Draft GSS-API Negotiation Mechanism December 2004 506 507 508 negTokenResp [1] negTokenResp 509 } 510 511 512 5134.2.1 negTokenInit 514 515 NegTokenInit ::= SEQUENCE { 516 mechTypes [0] MechTypeList, 517 reqFlags [1] ContextFlags OPTIONAL, 518 mechToken [2] OCTET STRING OPTIONAL, 519 mechListMIC [3] OCTET STRING OPTIONAL, 520 ... 521 } 522 ContextFlags ::= BIT STRING { 523 delegFlag (0), 524 mutualFlag (1), 525 replayFlag (2), 526 sequenceFlag (3), 527 anonFlag (4), 528 confFlag (5), 529 integFlag (6) 530 } 531 532 This is the syntax for the inner token of the initial negotiation 533 message. 534 535 mechTypes 536 537 This field contains one or more security mechanisms available 538 for the initiator in decreasing preference order (favorite 539 choice first). 540 541 reqFlags 542 543 This field, if present, contains the service options that are 544 requested to establish the context. The context flags SHOULD 545 be filled in from the req_flags parameter of 546 GSS_Init_sec_context(). This field SHALL NOT have impact on 547 the negotiation. 548 549 mechToken 550 551 This field, if present, contains the optimistic mechanism 552 token. 553 554 555 556 557 558 559Zhu, et al. Expires June 1, 2005 [Page 10] 560 561Internet-Draft GSS-API Negotiation Mechanism December 2004 562 563 564 mechlistMIC 565 566 This field, if present, contains a MIC token for the mechanism 567 list in the initial negotiation message. This MIC token is 568 computed according to Section 5. 569 570 5714.2.2 negTokenResp 572 573 NegTokenResp ::= SEQUENCE { 574 negResult [0] ENUMERATED { 575 accept_completed (0), 576 accept_incomplete (1), 577 reject (2), 578 request_mic (3) 579 } OPTIONAL, 580 -- REQUIRED in the first reply from the target 581 supportedMech [1] MechType OPTIONAL, 582 -- present only in the first reply from the target 583 responseToken [2] OCTET STRING OPTIONAL, 584 mechListMIC [3] OCTET STRING OPTIONAL, 585 ... 586 } 587 588 This is the syntax for all subsequent negotiation messages. 589 590 negResult 591 592 This field, if present, contains the state of the negotiation. 593 This can be: 594 595 accept_completed 596 597 No further negotiation message from the peer is expected, 598 and the security context is established for the sender. 599 600 accept_incomplete 601 602 At least one more negotiation message from the peer is 603 needed to establish the security context. 604 605 reject 606 607 The sender terminates the negotiation. 608 609 610 611 612 613 614 615Zhu, et al. Expires June 1, 2005 [Page 11] 616 617Internet-Draft GSS-API Negotiation Mechanism December 2004 618 619 620 request_mic 621 622 The sender indicates that the exchange of MIC tokens, as 623 described in Section 5, will be REQUIRED if per-message 624 integrity services are available on the mechanism context to 625 be established. This value SHALL only be present in the 626 first reply from the target. 627 628 This field is REQUIRED in the first reply from the target, and 629 it is OPTIONAL thereafter. 630 631 supportedMech 632 633 This field SHALL only be present in the first reply from the 634 target. It MUST be one of the mechanism(s) offered by the 635 initiator. 636 637 ResponseToken 638 639 This field, if present, contains tokens specific to the 640 mechanism selected. 641 642 mechlistMIC 643 644 This field, if present, contains a MIC token for the mechanism 645 list in the initial negotiation message. This MIC token is 646 computed according to Section 5. 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Zhu, et al. Expires June 1, 2005 [Page 12] 672 673Internet-Draft GSS-API Negotiation Mechanism December 2004 674 675 6765. Processing of mechListMIC 677 678 If the mechanism selected by the negotiation does not support 679 integrity protection, then no mechlistMIC token is used. 680 681 Otherwise if the accepted mechanism is the most preferred mechanism 682 of both the initiator and the acceptor, then the MIC token exchange, 683 as described later in this section, is OPTIONAL. A mechanism is the 684 acceptor's most preferred mechanism if there is no other mechanism 685 which would have been preferred over the accepted mechanism if it had 686 been present in the received mechanism list. 687 688 In all other cases, MIC tokens MUST be exchanged after the mechanism 689 context is fully established. 690 691 It is assumed that per-message integrity services are available on 692 the established mechanism context in the following procedure for 693 processing MIC tokens of the initiator's mechanism list. 694 695 a) The mechlistMIC token (or simply the MIC token) is computed by 696 invoking GSS_GetMIC(): the input context_handle is the established 697 mechanism context, the input qop_req is 0, and the input message 698 is the mechTypes field in the initial negotiation message (only 699 the DER encoding of the type MechTypeList is included). 700 701 b) If the selected mechanism uses an even number of mechanism tokens 702 (namely the acceptor sends the last mechanism token), the acceptor 703 does the following when emitting the negotiation message 704 containing the last mechanism token: if the MIC token exchange is 705 not required, GSS_Accept_sec_context() either indicates 706 GSS_S_COMPLETE and does not include a mechlistMIC token, or 707 indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token 708 and an accept_incomplete state; if the MIC token exchange is 709 required, GSS_Accept_sec_context() indicates 710 GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. 711 Acceptors that wish to be compatible with legacy Windows SPNEGO 712 implementations as described in Appendix B shall not generate a 713 mechlistMIC token when the MIC token exchange is not required. 714 The initiator then processes the last mechanism token, and does 715 one of the following: 716 717 (I) If a mechlistMIC token was included, and is correctly 718 verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The 719 output negotiation message contains a mechlistMIC token, and an 720 accept_complete state. The acceptor MUST then verify this 721 mechlistMIC token. 722 723 724 725 726 727Zhu, et al. Expires June 1, 2005 [Page 13] 728 729Internet-Draft GSS-API Negotiation Mechanism December 2004 730 731 732 (II) If a mechlistMIC token was included but is incorrect, the 733 negotiation SHALL be terminated. GSS_Accept_sec_context() 734 indicates GSS_S_DEFECTIVE_TOKEN. 735 736 (III) If no mechlistMIC token was included, and the MIC token 737 exchange is not required, GSS_Init_sec_context() indicates 738 GSS_S_COMPLETE with no output token. 739 740 (IV) If no mechlistMIC token was included, but the MIC token 741 exchange is required, the negotiation SHALL be terminated. 742 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 743 744 c) In the case that the chosen mechanism uses an odd number of 745 mechanism tokens (namely the initiator sends the last mechanism 746 token), the initiator does the following when emitting the 747 negotiation message containing the last mechanism token: if the 748 negResult state was request_mic in the first reply from the 749 target, a mechlistMIC token MUST be included, otherwise the 750 mechlistMIC token is OPTIONAL. In the case that the optimistic 751 mechanism token is the only mechanism token for the initiator's 752 preferred mechanism, the mechlistMIC token is OPTIONAL. 753 GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED. 754 Initiators that wish to be compatible with legacy Windows SPNEGO 755 implementations as described in Appendix B shall not generate a 756 mechlistMIC token when the MIC token exchange is not required. 757 The acceptor then processes the last mechanism token and does one 758 of the following: 759 760 (I) If a mechlistMIC token was included and is correctly verified, 761 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 762 negotiation message contains a mechlistMIC token and an 763 accept_complete state. The initiator MUST then verify this 764 mechlistMIC token. 765 766 (II) If a mechlistMIC token was included but is incorrect, the 767 negotiation SHALL be terminated. GSS_Accept_sec_context() 768 indicates GSS_S_DEFECTIVE_TOKEN. 769 770 (III) If no mechlistMIC token was included but the mechlistMIC 771 token exchange is not required, GSS_Accept_sec_context() 772 indicates GSS_S_COMPLETE. The output negotiation message 773 contains an accept_complete state. 774 775 (IV) In the case that the optimistic mechanism token is also the 776 last mechanism token (when the initiator's preferred mechanism 777 is accepted by the target) and the target sends a request_mic 778 state but the initiator did not send a mechlistMIC token, the 779 target then MUST include a mechlistMIC token in that first 780 781 782 783Zhu, et al. Expires June 1, 2005 [Page 14] 784 785Internet-Draft GSS-API Negotiation Mechanism December 2004 786 787 788 reply. GSS_Accept_sec_context() indicates 789 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 790 mechlistMIC token and generate a mechlistMIC token to send back 791 to the target. The target SHALL in turn verify the returned 792 mechlistMIC token and complete the negotiation. 793 794 (V) If no mechlistMIC token was included and the acceptor sent a 795 request_mic state in the first reply message (the exchange of 796 MIC tokens is required), the negotiation SHALL be terminated. 797 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 798 799 800 801 802 803 804 805 806 807 808 809 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 837 838 839Zhu, et al. Expires June 1, 2005 [Page 15] 840 841Internet-Draft GSS-API Negotiation Mechanism December 2004 842 843 8446. Extensibility 845 846 Two mechanisms are provided for extensibility. First, the ASN.1 847 structures in this specification MAY be expanded by IETF standards 848 action. Implementations receiving unknown fields MUST ignore these 849 fields. 850 851 Secondly, OIDs corresponding to a desired mechanism attribute may be 852 included in the set of preferred mechanisms by an initiator. The 853 acceptor can choose to honor this request by preferring mechanisms 854 that have the included attributes. Future work within the Kitten 855 working group is expected to standardize common attributes that 856 SPNEGO mechanisms may wish to support. At this time it is sufficient 857 to say that initiators MAY include OIDs that do not correspond to 858 mechanisms but instead correspond to desired mechanism attributes in 859 their requests. Such OIDs MAY influence the acceptor's choice of 860 mechanism. As discussed in Section 5, if there are mechanisms that 861 if present in the initiator's list of mechanisms might be preferred 862 by the acceptor to the initiator's preferred mechanism, the acceptor 863 MUST demand the MIC token exchange. As a consequence, acceptors MUST 864 demand the MIC token exchange if they support negotiation of 865 attributes not available in the initiator's preferred mechanism 866 regardless of whether the initiator actually requested these 867 attributes. 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 894 895Zhu, et al. Expires June 1, 2005 [Page 16] 896 897Internet-Draft GSS-API Negotiation Mechanism December 2004 898 899 9007. Security Considerations 901 902 In order to produce the MIC token for the mechanism list, the 903 mechanism must provide integrity protection. When the selected 904 mechanism does not support integrity protection, the negotiation is 905 vulnerable: an active attacker can force it to use a security 906 mechanism that is not mutually preferred but is acceptable to the 907 target. 908 909 This protocol provides the following guarantees when per-message 910 integrity services are available on the established mechanism context 911 and the mechanism list was altered by an adversary such that a 912 mechanism which is not mutually preferred could be selected: 913 914 o if the last mechanism token is sent by the initiator, both peers 915 shall fail; 916 o if the last mechanism token is sent by the acceptor, the acceptor 917 shall not complete and the initiator at worst shall complete with 918 its preferred mechanism being selected. 919 920 The negotiation may not be terminated if an alteration was made but 921 it had no material impact. 922 923 The protection of the negotiation depends on the strength of the 924 integrity protection. In particular, the strength of SPNEGO is no 925 stronger than the integrity protection of the weakest mechanism 926 acceptable to GSS-API peers. 927 928 In all cases, the communicating peers are exposed to the denial of 929 service threat. 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951Zhu, et al. Expires June 1, 2005 [Page 17] 952 953Internet-Draft GSS-API Negotiation Mechanism December 2004 954 955 9568. IANA Considerations 957 958 This document has no actions for IANA. 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 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 1004 1005 1006 1007Zhu, et al. Expires June 1, 2005 [Page 18] 1008 1009Internet-Draft GSS-API Negotiation Mechanism December 2004 1010 1011 10129. Acknowledgments 1013 1014 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 1015 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments 1016 and suggestions during development of this document. 1017 1018 Luke Howard provided a prototype of this protocol in Heimdal and 1019 resolved several issues in the initial draft. 1020 1021 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 1022 [RFC2478] of which some of the text has been retained in this 1023 document. 1024 102510 Normative References 1026 1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Levels", BCP 14, RFC 2119, March 1997. 1029 1030 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 1031 Negotiation Mechanism", RFC 2478, December 1998. 1032 1033 [RFC2743] Linn, J., "Generic Security Service Application Program 1034 Interface Version 2, Update 1", RFC 2743, January 2000. 1035 1036 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1037 Rules (BER), Canonical Encoding Rules (CER) and 1038 Distinguished Encoding Rules (DER), ITU-T Recommendation 1039 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 1040 1041Authors' Addresses 1042 1043 Larry Zhu 1044 Microsoft Corporation 1045 One Microsoft Way 1046 Redmond, WA 98052 1047 US 1048 1049 EMail: lzhu@microsoft.com 1050 1051 1052 Paul Leach 1053 Microsoft Corporation 1054 One Microsoft Way 1055 Redmond, WA 98052 1056 US 1057 1058 EMail: paulle@microsoft.com 1059 1060 1061 1062 1063 1064 1065 1066 1067Zhu, et al. Expires June 1, 2005 [Page 19] 1068 1069Internet-Draft GSS-API Negotiation Mechanism December 2004 1070 1071 1072 Karthik Jaganathan 1073 Microsoft Corporation 1074 One Microsoft Way 1075 Redmond, WA 98052 1076 US 1077 1078 EMail: karthikj@microsoft.com 1079 1080 1081 Wyllys Ingersoll 1082 Sun Microsystems 1083 1775 Wiehle Avenue, 2nd Floor 1084 Reston, VA 20190 1085 US 1086 1087 EMail: wyllys.ingersoll@sun.com 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 1118 1119 1120 1121 1122 1123Zhu, et al. Expires June 1, 2005 [Page 20] 1124 1125Internet-Draft GSS-API Negotiation Mechanism December 2004 1126 1127 1128Appendix A. GSS-API Negotiation Support API 1129 1130 In order to provide to a GSS-API caller (either the initiator or the 1131 target or both) the ability to choose among the set of supported 1132 mechanisms a reduced set of mechanisms for negotiation, two 1133 additional APIs are defined: 1134 1135 o GSS_Get_neg_mechs() indicates the set of security mechanisms 1136 available on the local system to the caller for negotiation, based 1137 on the credentials being used. 1138 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 1139 used on the local system by the caller for negotiation, for the 1140 given credentials. 1141 1142A.1 GSS_Set_neg_mechs call 1143 1144 Inputs: 1145 1146 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 1147 -- credentials 1148 o mech_set SET OF OBJECT IDENTIFIER 1149 1150 Outputs: 1151 1152 o major_status INTEGER, 1153 o minor_status INTEGER 1154 1155 Return major_status codes: 1156 1157 o GSS_S_COMPLETE indicates that the set of security mechanisms 1158 available for negotiation has been set to mech_set. 1159 o GSS_S_FAILURE indicates that the requested operation could not be 1160 performed for reasons unspecified at the GSS-API level. 1161 1162 Allows callers to specify the set of security mechanisms that may be 1163 negotiated with the credential identified by cred_handle. This call 1164 is intended for support of specialized callers who need to restrict 1165 the set of negotiable security mechanisms from the set of all 1166 security mechanisms available to the caller (based on available 1167 credentials). Note that if more than one mechanism is specified in 1168 mech_set, the order in which those mechanisms are specified implies a 1169 relative preference. 1170 1171A.2 GSS_Get_neg_mechs call 1172 1173 Input: 1174 1175 1176 1177 1178 1179Zhu, et al. Expires June 1, 2005 [Page 21] 1180 1181Internet-Draft GSS-API Negotiation Mechanism December 2004 1182 1183 1184 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 1185 -- credentials 1186 1187 Outputs: 1188 1189 o major_status INTEGER, 1190 o minor_status INTEGER, 1191 o mech_set SET OF OBJECT IDENTIFIER 1192 1193 Return major_status codes: 1194 1195 o GSS_S_COMPLETE indicates that the set of security mechanisms 1196 available for negotiation has been returned in mech_set. 1197 o GSS_S_FAILURE indicates that the requested operation could not be 1198 performed for reasons unspecified at the GSS-API level. 1199 1200 Allows callers to determine the set of security mechanisms available 1201 for negotiation with the credential identified by cred_handle. This 1202 call is intended for support of specialized callers who need to 1203 reduce the set of negotiable security mechanisms from the set of 1204 supported security mechanisms available to the caller (based on 1205 available credentials). 1206 1207 Note: The GSS_Indicate_mechs() function indicates the full set of 1208 mechanism types available on the local system. Since this call has 1209 no input parameter, the returned set is not necessarily available for 1210 all credentials. 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235Zhu, et al. Expires June 1, 2005 [Page 22] 1236 1237Internet-Draft GSS-API Negotiation Mechanism December 2004 1238 1239 1240Appendix B. Changes since RFC2478 1241 1242 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 1243 2003 have the following behavior: no mechlistMIC is produced and 1244 mechlistMIC is not processed if one is provided; if the initiator 1245 sends the last mechanism token, the acceptor will send back a 1246 negotiation token with an accept_complete state and no mechlistMIC 1247 token. In addition, the OID (1.2.840.48018.1.2.2) can be used to 1248 identify the GSS-API Kerberos Version 5 mechanism. 1249 1250 The following changes have been made to be compatible with these 1251 legacy implementations. 1252 1253 * NegTokenTarg is changed to negTokenResp and it is the message 1254 format for all subsequent negotiation tokens. 1255 * NegTokenInit is the message for the initial negotiation message 1256 and that message only. 1257 * mechTypes in negTokenInit is not optional. 1258 * Two MIC tokens are exchanged, one in each direction. 1259 * If the selected mechanism is also the most preferred mechanism 1260 for both peers, it is safe to omit the MIC tokens. 1261 1262 If at least one of the two peers implements the pseudo mechanism 1263 in this document, the negotiation is protected. 1264 1265 The following changes are to address the problems in RFC 2478. 1266 1267 * reqFlags is not protected therefore it should not impact the 1268 negotiation. 1269 * DER encoding is required. 1270 * GSS_GetMIC() input is clarified. 1271 * Per-message integrity services are requested for the negotiated 1272 mechanism. 1273 1274 An implementation that conforms to this specification will not 1275 interoperate with a strict 2748 implementation. Even if the new 1276 implementation always sends a mechlistMIC token, it will still fail 1277 to interoperate. If it is a server, it will fail because it requests 1278 a mechlistMIC token using an option that older implementations simply 1279 do not support. Clients will tend to fail as well. 1280 1281 As an alternative to the approach chosen in this specification, we 1282 could have documented a correct behavior that is fully backward 1283 compatible with RFC 2478 and included an appendix on how to 1284 interoperate with existing incorrect implementations of RFC 2478. 1285 1286 As a practical matter, the SPNEGO implementers within the IETF have 1287 valued interoperability with the Microsoft implementations. We were 1288 1289 1290 1291Zhu, et al. Expires June 1, 2005 [Page 23] 1292 1293Internet-Draft GSS-API Negotiation Mechanism December 2004 1294 1295 1296 unable to choose to maintain reasonable security guarantees, maintain 1297 interoperability with the Microsoft implementations and maintain 1298 interoperability with correct implementations of RFC 2478. The 1299 working group was not aware of any RFC 2478 implementations. Even if 1300 there are RFC 2478 implementations, it is unlikely that they will 1301 interoperate because of a critical flaw in the description of the 1302 encoding of the mechanism list in RFC 2478. 1303 1304 With the approach taken in this specification, we get security 1305 between new implementations all the time while maintaining 1306 interoperability with the implementations we have within the IETF 1307 community. The working group believes that this justifies breaking 1308 compatibility with a correct implementation of RFC 2478. 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 1343 1344 1345 1346 1347Zhu, et al. Expires June 1, 2005 [Page 24] 1348 1349Internet-Draft GSS-API Negotiation Mechanism December 2004 1350 1351 1352Intellectual Property Statement 1353 1354 The IETF takes no position regarding the validity or scope of any 1355 Intellectual Property Rights or other rights that might be claimed to 1356 pertain to the implementation or use of the technology described in 1357 this document or the extent to which any license under such rights 1358 might or might not be available; nor does it represent that it has 1359 made any independent effort to identify any such rights. Information 1360 on the procedures with respect to rights in RFC documents can be 1361 found in BCP 78 and BCP 79. 1362 1363 Copies of IPR disclosures made to the IETF Secretariat and any 1364 assurances of licenses to be made available, or the result of an 1365 attempt made to obtain a general license or permission for the use of 1366 such proprietary rights by implementers or users of this 1367 specification can be obtained from the IETF on-line IPR repository at 1368 http://www.ietf.org/ipr. 1369 1370 The IETF invites any interested party to bring to its attention any 1371 copyrights, patents or patent applications, or other proprietary 1372 rights that may cover technology that may be required to implement 1373 this standard. Please address the information to the IETF at 1374 ietf-ipr@ietf.org. 1375 1376 1377Disclaimer of Validity 1378 1379 This document and the information contained herein are provided on an 1380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1386 1387 1388Copyright Statement 1389 1390 Copyright (C) The Internet Society (2004). This document is subject 1391 to the rights, licenses and restrictions contained in BCP 78, and 1392 except as set forth therein, the authors retain all their rights. 1393 1394 1395Acknowledgment 1396 1397 Funding for the RFC Editor function is currently provided by the 1398 Internet Society. 1399 1400 1401 1402 1403Zhu, et al. Expires June 1, 2005 [Page 25] 1404 1405 1406