1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft P. Leach 5Obsoletes: 2478 (if approved) K. Jaganathan 6Expires: June 15, 2005 Microsoft Corporation 7 W. Ingersoll 8 Sun Microsystems 9 December 15, 2004 10 11 12 The Simple and Protected GSS-API Negotiation Mechanism 13 draft-ietf-kitten-2478bis-04 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 15, 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 15, 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 63 If per-message integrity services are available on the established 64 mechanism context, then the negotiation is protected against an 65 attacker forcing the selection of a mechanism not desired by the 66 peers. 67 68 This mechanism replaces RFC 2478 in order to fix defects in that 69 specification and to describe how to interoperate with 70 implementations of that specification commonly deployed on the 71 Internet. 72 73Table of Contents 74 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 77 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6 78 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6 79 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7 80 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10 82 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10 83 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11 84 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12 85 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14 86 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 92 10.2 Informative References . . . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 94 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 23 95 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23 96 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23 97 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 25 98 C. mechListMIC Computation Example . . . . . . . . . . . . . . . 27 99 Intellectual Property and Copyright Statements . . . . . . . . 28 100 101 102 103 104 105 106 107 108 109 110 111Zhu, et al. Expires June 15, 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 support a common set of one or more GSS-API 131 security mechanisms, and if so, to invoke the normal security context 132 establishment for a selected common security mechanism. This is most 133 useful for applications which depend on GSS-API implementations and 134 share multiple mechanisms between the peers. 135 136 The SPNEGO mechanism negotiation is based on the following model: the 137 initiator proposes a list of security mechanism(s), in decreasing 138 preference order (favorite choice first), the acceptor (also known as 139 the target) either accepts the initiator's preferred security 140 mechanism (the first in the list), or chooses one that is available 141 from the offered list, or rejects the proposed value(s). The target 142 then informs the initiator of its choice. 143 144 Once a common security mechanism is chosen, mechanism-specific 145 options MAY be negotiated as part of the selected mechanism's context 146 establishment. These negotiations (if any) are internal to the 147 mechanism and opaque to the SPNEGO protocol. As such they are 148 outside the scope of this document. 149 150 If per-message integrity services are available on the established 151 mechanism security context, then the negotiation is protected to 152 ensure that the mechanism list has not been modified. In cases where 153 an attacker could have materially influenced the negotiation, peers 154 exchange message integrity code (MIC) tokens to confirm the mechanism 155 list has not been modified. If no action of an attacker could have 156 materially modified the outcome of the negotiation, the exchange of 157 MIC tokens is optional (see Section 5). Allowing MIC tokens to be 158 optional in this case provides interoperability with existing 159 implementations while still protecting the negotiation. This 160 interoperability comes at the cost of increased complexity. 161 162 In order to avoid an extra round trip, the first context 163 establishment token of the initiator's preferred mechanism SHOULD be 164 165 166 167Zhu, et al. Expires June 15, 2005 [Page 3] 168 169Internet-Draft GSS-API Negotiation Mechanism December 2004 170 171 172 embedded in the initial negotiation message (as defined in Section 173 4.2). (This mechanism token is referred to as the optimistic 174 mechanism token in this document.) In addition, using the optimistic 175 mechanism token allows the initiator to recover from non-fatal errors 176 encountered trying to produce the first mechanism token before a 177 mechanism can be selected. Implementations MAY omit the optimistic 178 mechanism token in cases where the likelihood of the initiator's 179 preferred mechanism not being selected by the acceptor is significant 180 given the cost of generating it. 181 182 SPNEGO relies on the concepts developed in the GSS-API specification 183 [RFC2743]. The negotiation data is encapsulated in context-level 184 tokens. Therefore, callers of the GSS-API do not need to be aware of 185 the existence of the negotiation tokens but only of the new 186 pseudo-security mechanism. A failure in the negotiation phase causes 187 a major status code to be returned: GSS_S_BAD_MECH. 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 15, 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 15, 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 mechanism 301 first), and optionally the initial mechanism token for the preferred 302 mechanism of the initiator (i.e., the first in the list). (Note that 303 the list MUST NOT contain mechanisms for which the client does not 304 have appropriate 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 optimistic mechanism token was sufficient 313 to complete the authentication; an accept_incomplete state indicates 314 that further message exchange is needed but the MIC token exchange as 315 described in Section 5 is OPTIONAL; a request_mic state (this state 316 can only be present in the first reply message from the target) 317 indicates the MIC token exchange is REQUIRED if per-message integrity 318 services are available. 319 320 Unless the preference order is specified by the application, the 321 policy by which the target chooses a mechanism is an 322 implementation-specific local matter. In the absence of an 323 application specified preference order or other policy, the target 324 SHALL choose the first mechanism in the initiator proposed list for 325 which it has valid credentials. 326 327 In case of a successful negotiation, the security mechanism in the 328 first reply message represents the value suitable for the target, 329 chosen from the list offered by the initiator. 330 331 In case of an unsuccessful negotiation, the reject state is returned 332 333 334 335Zhu, et al. Expires June 15, 2005 [Page 6] 336 337Internet-Draft GSS-API Negotiation Mechanism December 2004 338 339 340 and it is OPTIONAL to emit a context level negotiation token. 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 3563.2 Negotiation Procedure 357 358 The basic form of the procedure assumes that per-message integrity 359 services are available on the established mechanism context, and it 360 is summarized as follows: 361 362 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 363 but requests that SPNEGO be used. SPNEGO can either be explicity 364 requested or accepted as the default mechanism. 365 366 (b) The initiator GSS-API implementation emits a negotiation token 367 containing a list of one or more security mechanisms that are 368 available based on the credentials used for this context 369 establishment, and optionally the initial mechanism token for the 370 first mechanism in the list. 371 372 (c) The GSS-API initiator application sends the token to the target 373 application. The GSS-API target application deposits the token by 374 invoking GSS_Accept_sec_context(). The acceptor will do one of 375 the following: 376 377 378 (I) If none of the proposed mechanisms are acceptable, the 379 negotiation SHALL be terminated. GSS_Accept_sec_context 380 indicates GSS_S_BAD_MECH. The acceptor MAY output a 381 negotiation token containing a reject state. 382 383 (II) If either the initiator's preferred mechanism is not 384 accepted by the target or this mechanism is accepted but it 385 is not the acceptor's most preferred mechanism (i.e., the 386 MIC token exchange as described in Section 5 is required), 387 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. 388 389 390 391Zhu, et al. Expires June 15, 2005 [Page 7] 392 393Internet-Draft GSS-API Negotiation Mechanism December 2004 394 395 396 The acceptor MUST output a negotiation token containing a 397 request_mic state. 398 399 (III) Otherwise if at least one additional negotiation token 400 from the initiator is needed to establish this context, 401 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and 402 outputs a negotiation token containing an accept_incomplete 403 state. 404 405 (IV) Otherwise no additional negotiation token from the 406 initiator is needed to establish this context, 407 GSS_Accept_sec_context() indicates GSS_S_COMPLETE and 408 outputs a negotiation token containing an accept_complete 409 state. 410 411 If the initiator's preferred mechanism is accepted, and an 412 optimistic mechanism token was included, this mechanism token MUST 413 be deposited to the selected mechanism by invoking 414 GSS_Accept_sec_context() and if a response mechanism token is 415 emitted, it MUST be included in the response negotiation token. 416 Otherwise, the target will not emit a response mechanism token in 417 the first reply. 418 419 (d) The GSS-API target application returns the negotiation token to 420 the initiator application. The GSS-API initiator application 421 deposits the token by invoking GSS_Init_sec_context(). The 422 security context initialization is then continued according to the 423 standard GSS-API conventions for the selected mechanism, where the 424 tokens of the selected mechanism are encapsulated in negotiation 425 messages (see Section 4) until the GSS_S_COMPLETE is returned for 426 both the initiator and the target by the selected security 427 mechanism. 428 429 (e) MIC tokens are then either skipped or exchanged according to 430 Section 5. 431 432 Note that the *_req_flag input parameters for context establishment 433 are relative to the selected mechanism, as are the *_state output 434 parameters. i.e., these parameters are not applicable to the 435 negotiation process per se. 436 437 On receipt of a negotiation token on the target side, a GSS-API 438 implementation that does not support negotiation would indicate the 439 GSS_S_BAD_MECH status as if a particular basic security mechanism had 440 been requested and was not supported. 441 442 When a GSS-API credential is acquired for the SPNEGO mechanism the 443 implementation SHOULD produce a credential element for the SPNEGO 444 445 446 447Zhu, et al. Expires June 15, 2005 [Page 8] 448 449Internet-Draft GSS-API Negotiation Mechanism December 2004 450 451 452 mechanism which internally contains GSS-API credential elements for 453 all mechanisms for which the principal has credentials available, 454 except for any mechanisms which are not to be negotiated, either as 455 per implementation-, site- or application-specific policy. See 456 Appendix A for interfaces for expressing application policy. 457 458 459 460 461 462 463 464 465 466 467 468 469 470 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 502 503Zhu, et al. Expires June 15, 2005 [Page 9] 504 505Internet-Draft GSS-API Negotiation Mechanism December 2004 506 507 5084. Token Definitions 509 510 The type definitions in this section assume an ASN.1 module 511 definition of the following form: 512 513 514 SPNEGOASNOneSpec { 515 iso(1) identified-organization(3) dod(6) internet(1) 516 security(5) mechanism(5) snego (2) modules(4) spec2(2) 517 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 518 519 -- rest of definitions here 520 521 END 522 523 524 This specifies that the tagging context for the module will be 525 explicit and non-automatic. 526 527 The encoding of SPNEGO protocol messages shall obey the Distinguished 528 Encoding Rules (DER) of ASN.1 as described in [X690]. 529 5304.1 Mechanism Types 531 532 In this negotiation model, each OID represents one GSS-API mechanism 533 or one variant (see Section 6) of it according to [RFC2743]. 534 535 536 MechType ::= OBJECT IDENTIFIER 537 -- OID represents each security mechanism as suggested by 538 -- [RFC2743] 539 540 MechTypeList ::= SEQUENCE OF MechType 541 542 5434.2 Negotiation Tokens 544 545 The syntax of the initial negotiation tokens follows the 546 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The 547 SPNEGO pseudo mechanism is identified by the Object Identifier 548 specified in Section 1. Subsequent tokens MUST NOT be encapsulated 549 in this GSS-API generic 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 NegotiationToken ::= CHOICE { 555 negTokenInit [0] NegTokenInit, 556 557 558 559Zhu, et al. Expires June 15, 2005 [Page 10] 560 561Internet-Draft GSS-API Negotiation Mechanism December 2004 562 563 564 negTokenResp [1] negTokenResp 565 } 566 567 568 5694.2.1 negTokenInit 570 571 NegTokenInit ::= SEQUENCE { 572 mechTypes [0] MechTypeList, 573 reqFlags [1] ContextFlags OPTIONAL, 574 -- maintained from RFC 2478 for backward compatibility, 575 -- RECOMMENDED to be left out 576 mechToken [2] OCTET STRING OPTIONAL, 577 mechListMIC [3] OCTET STRING OPTIONAL, 578 ... 579 } 580 ContextFlags ::= BIT STRING { 581 delegFlag (0), 582 mutualFlag (1), 583 replayFlag (2), 584 sequenceFlag (3), 585 anonFlag (4), 586 confFlag (5), 587 integFlag (6) 588 } 589 590 This is the syntax for the inner token of the initial negotiation 591 message. 592 593 mechTypes 594 595 This field contains one or more security mechanisms available 596 for the initiator in decreasing preference order (favorite 597 choice first). 598 599 reqFlags 600 601 This field, if present, contains the service options that are 602 requested to establish the context. The context flags SHOULD 603 be filled in from the req_flags parameter of 604 GSS_Init_sec_context(). This field SHALL NOT have impact on 605 the negotiation. 606 607 mechToken 608 609 This field, if present, contains the optimistic mechanism 610 token. 611 612 613 614 615Zhu, et al. Expires June 15, 2005 [Page 11] 616 617Internet-Draft GSS-API Negotiation Mechanism December 2004 618 619 620 mechlistMIC 621 622 This field, if present, contains a MIC token for the mechanism 623 list in the initial negotiation message. This MIC token is 624 computed according to Section 5. 625 626 6274.2.2 negTokenResp 628 629 NegTokenResp ::= SEQUENCE { 630 negState [0] ENUMERATED { 631 accept_completed (0), 632 accept_incomplete (1), 633 reject (2), 634 request_mic (3) 635 } OPTIONAL, 636 -- REQUIRED in the first reply from the target 637 supportedMech [1] MechType OPTIONAL, 638 -- present only in the first reply from the target 639 responseToken [2] OCTET STRING OPTIONAL, 640 mechListMIC [3] OCTET STRING OPTIONAL, 641 ... 642 } 643 644 This is the syntax for all subsequent negotiation messages. 645 646 negState 647 648 This field, if present, contains the state of the negotiation. 649 This can be: 650 651 accept_completed 652 653 No further negotiation message from the peer is expected, 654 and the security context is established for the sender. 655 656 accept_incomplete 657 658 At least one more negotiation message from the peer is 659 needed to establish the security context. 660 661 reject 662 663 The sender terminates the negotiation. 664 665 666 667 668 669 670 671Zhu, et al. Expires June 15, 2005 [Page 12] 672 673Internet-Draft GSS-API Negotiation Mechanism December 2004 674 675 676 request_mic 677 678 The sender indicates that the exchange of MIC tokens, as 679 described in Section 5, will be REQUIRED if per-message 680 integrity services are available on the mechanism context to 681 be established. This value SHALL only be present in the 682 first reply from the target. 683 684 This field is REQUIRED in the first reply from the target, and 685 it is OPTIONAL thereafter. When negState is absent the actual 686 state should be inferred from the state of the negotiated 687 mechanism context. 688 689 supportedMech 690 691 This field SHALL only be present in the first reply from the 692 target. It MUST be one of the mechanism(s) offered by the 693 initiator. 694 695 ResponseToken 696 697 This field, if present, contains tokens specific to the 698 mechanism selected. 699 700 mechlistMIC 701 702 This field, if present, contains a MIC token for the mechanism 703 list in the initial negotiation message. This MIC token is 704 computed according to Section 5. 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727Zhu, et al. Expires June 15, 2005 [Page 13] 728 729Internet-Draft GSS-API Negotiation Mechanism December 2004 730 731 7325. Processing of mechListMIC 733 734 If the mechanism selected by the negotiation does not support 735 integrity protection, then no mechlistMIC token is used. 736 737 Otherwise, if the accepted mechanism is the most preferred mechanism 738 of both the initiator and the acceptor, then the MIC token exchange, 739 as described later in this section, is OPTIONAL. A mechanism is the 740 acceptor's most preferred mechanism if there is no other mechanism 741 which, had it been present in the mechanism list, the acceptor would 742 have preferred over the accepted mechanism. 743 744 In all other cases, MIC tokens MUST be exchanged after the mechanism 745 context is fully established. 746 747 a) The mechlistMIC token (or simply the MIC token) is computed over 748 the mechanism list in the initial negotiation message by invoking 749 GSS_GetMIC() as follows: the input context_handle is the 750 established mechanism context, the input qop_req is 0, and the 751 input message is the DER encoding of the value of type 752 MechTypeList which is contained in the "mechTypes" field of the 753 NegTokenInit. The input message is NOT the DER encoding of the 754 type "[0] MechTypeList". 755 756 b) If the selected mechanism exchanges an even number of mechanism 757 tokens (i.e., the acceptor sends the last mechanism token), the 758 acceptor does the following when emitting the negotiation message 759 containing the last mechanism token: if the MIC token exchange is 760 optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE 761 and does not include a mechlistMIC token, or indicates 762 GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an 763 accept_incomplete state; if the MIC token exchange is required, 764 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and 765 includes a mechlistMIC token. Acceptors that wish to be 766 compatible with legacy Windows SPNEGO implementations as described 767 in Appendix B should not generate a mechlistMIC token when the MIC 768 token exchange is not required. The initiator then processes the 769 last mechanism token, and does 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 782 783Zhu, et al. Expires June 15, 2005 [Page 14] 784 785Internet-Draft GSS-API Negotiation Mechanism December 2004 786 787 788 (II) If a mechlistMIC token was included but is incorrect, the 789 negotiation SHALL be terminated. GSS_Init_sec_context() 790 indicates GSS_S_DEFECTIVE_TOKEN. 791 792 (III) If no mechlistMIC token was included, and the MIC token 793 exchange is not required, GSS_Init_sec_context() indicates 794 GSS_S_COMPLETE with no output token. 795 796 (IV) If no mechlistMIC token was included, but the MIC token 797 exchange is required, the negotiation SHALL be terminated. 798 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 799 800 c) In the case that the chosen mechanism exchanges an odd number of 801 mechanism tokens (i.e., the initiator sends the last mechanism 802 token), the initiator does the following when emitting the 803 negotiation message containing the last mechanism token: if the 804 negState was request_mic in the first reply from the target, a 805 mechlistMIC token MUST be included, otherwise the mechlistMIC 806 token is OPTIONAL. (Note that the MIC token exchange is required 807 if a mechanism other than the initiator's first choice is chosen.) 808 In the case that the optimistic mechanism token is the only 809 mechanism token for the initiator's preferred mechanism, the 810 mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC 811 token is included, GSS_Init_sec_context() indicates 812 GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with 813 legacy Windows SPNEGO implementations as described in Appendix B 814 should not generate a mechlistMIC token when the MIC token 815 exchange is not required. The acceptor then processes the last 816 mechanism token and does one of the following: 817 818 (I) If a mechlistMIC token was included and is correctly verified, 819 GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output 820 negotiation message contains a mechlistMIC token and an 821 accept_complete state. The initiator MUST then verify this 822 mechlistMIC token. 823 824 (II) If a mechlistMIC token was included but is incorrect, the 825 negotiation SHALL be terminated. GSS_Accept_sec_context() 826 indicates GSS_S_DEFECTIVE_TOKEN. 827 828 (III) If no mechlistMIC token was included but the mechlistMIC 829 token exchange is not required, GSS_Accept_sec_context() 830 indicates GSS_S_COMPLETE. The output negotiation message 831 contains an accept_complete state. 832 833 834 835 836 837 838 839Zhu, et al. Expires June 15, 2005 [Page 15] 840 841Internet-Draft GSS-API Negotiation Mechanism December 2004 842 843 844 (IV) In the case that the optimistic mechanism token is also the 845 last mechanism token (when the initiator's preferred mechanism 846 is accepted by the target) and the target sends a request_mic 847 state but the initiator did not send a mechlistMIC token, the 848 target then MUST include a mechlistMIC token in that first 849 reply. GSS_Accept_sec_context() indicates 850 GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received 851 mechlistMIC token and generate a mechlistMIC token to send back 852 to the target. The target SHALL in turn verify the returned 853 mechlistMIC token and complete the negotiation. 854 855 (V) If no mechlistMIC token was included and the acceptor sent a 856 request_mic state in the first reply message (the exchange of 857 MIC tokens is required), the negotiation SHALL be terminated. 858 GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. 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 894 895Zhu, et al. Expires June 15, 2005 [Page 16] 896 897Internet-Draft GSS-API Negotiation Mechanism December 2004 898 899 9006. Extensibility 901 902 Two mechanisms are provided for extensibility. First, the ASN.1 903 structures in this specification MAY be expanded by IETF standards 904 action. Implementations receiving unknown fields MUST ignore these 905 fields. 906 907 Secondly, OIDs corresponding to a desired mechanism attribute (i.e., 908 mechanism variants) may be included in the set of preferred 909 mechanisms by an initiator. The acceptor can choose to honor this 910 request by preferring mechanisms that have the included attributes. 911 Future work within the Kitten working group is expected to 912 standardize common attributes that SPNEGO mechanisms may wish to 913 support. At this time it is sufficient to say that initiators MAY 914 include OIDs that do not correspond to mechanisms. Such OIDs MAY 915 influence the acceptor's choice of mechanism. As discussed in 916 Section 5, if there are mechanisms that if present in the initiator's 917 list of mechanisms might be preferred by the acceptor to the 918 initiator's preferred mechanism, the acceptor MUST demand the MIC 919 token exchange. As a consequence, acceptors MUST demand the MIC 920 token exchange if they support negotiation of attributes not 921 available in the initiator's preferred mechanism regardless of 922 whether the initiator actually requested these attributes. 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 950 951Zhu, et al. Expires June 15, 2005 [Page 17] 952 953Internet-Draft GSS-API Negotiation Mechanism December 2004 954 955 9567. Security Considerations 957 958 In order to produce the MIC token for the mechanism list, the 959 mechanism must provide integrity protection. When the selected 960 mechanism does not support integrity protection, the negotiation is 961 vulnerable: an active attacker can force it to use a security 962 mechanism that is not mutually preferred but is acceptable to the 963 target. 964 965 This protocol provides the following guarantees when per-message 966 integrity services are available on the established mechanism context 967 and the mechanism list was altered by an adversary such that a 968 mechanism which is not mutually preferred could be selected: 969 970 a) If the last mechanism token is sent by the initiator, both peers 971 shall fail; 972 b) If the last mechanism token is sent by the acceptor, the acceptor 973 shall not complete and the initiator at worst shall complete with 974 its preferred mechanism being selected. 975 976 The negotiation may not be terminated if an alteration was made but 977 it had no material impact. 978 979 The protection of the negotiation depends on the strength of the 980 integrity protection. In particular, the strength of SPNEGO is no 981 stronger than the integrity protection of the weakest mechanism 982 acceptable to GSS-API peers. 983 984 In all cases, the communicating peers are exposed to the denial of 985 service threat. 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 15, 2005 [Page 18] 1008 1009Internet-Draft GSS-API Negotiation Mechanism December 2004 1010 1011 10128. IANA Considerations 1013 1014 This document has no actions for IANA. 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 1062 1063Zhu, et al. Expires June 15, 2005 [Page 19] 1064 1065Internet-Draft GSS-API Negotiation Mechanism December 2004 1066 1067 10689. Acknowledgments 1069 1070 The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, 1071 Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments 1072 and suggestions during development of 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 1118 1119Zhu, et al. Expires June 15, 2005 [Page 20] 1120 1121Internet-Draft GSS-API Negotiation Mechanism December 2004 1122 1123 112410. References 1125 112610.1 Normative References 1127 1128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1129 Requirement Levels", BCP 14, RFC 2119, March 1997. 1130 1131 [RFC2743] Linn, J., "Generic Security Service Application Program 1132 Interface Version 2, Update 1", RFC 2743, January 2000. 1133 1134 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1135 Rules (BER), Canonical Encoding Rules (CER) and 1136 Distinguished Encoding Rules (DER), ITU-T Recommendation 1137 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 1138 113910.2 Informative References 1140 1141 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 1142 Negotiation Mechanism", RFC 2478, December 1998. 1143 1144 1145Authors' Addresses 1146 1147 Larry Zhu 1148 Microsoft Corporation 1149 One Microsoft Way 1150 Redmond, WA 98052 1151 US 1152 1153 EMail: lzhu@microsoft.com 1154 1155 1156 Paul Leach 1157 Microsoft Corporation 1158 One Microsoft Way 1159 Redmond, WA 98052 1160 US 1161 1162 EMail: paulle@microsoft.com 1163 1164 1165 Karthik Jaganathan 1166 Microsoft Corporation 1167 One Microsoft Way 1168 Redmond, WA 98052 1169 US 1170 1171 EMail: karthikj@microsoft.com 1172 1173 1174 1175 1176Zhu, et al. Expires June 15, 2005 [Page 21] 1177 1178Internet-Draft GSS-API Negotiation Mechanism December 2004 1179 1180 1181 Wyllys Ingersoll 1182 Sun Microsystems 1183 1775 Wiehle Avenue, 2nd Floor 1184 Reston, VA 20190 1185 US 1186 1187 EMail: wyllys.ingersoll@sun.com 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 1231 1232Zhu, et al. Expires June 15, 2005 [Page 22] 1233 1234Internet-Draft GSS-API Negotiation Mechanism December 2004 1235 1236 1237Appendix A. GSS-API Negotiation Support API 1238 1239 In order to provide to a GSS-API caller (either the initiator or the 1240 target or both) the ability to choose among the set of supported 1241 mechanisms a reduced set of mechanisms for negotiation, two 1242 additional APIs are defined: 1243 1244 o GSS_Get_neg_mechs() indicates the set of security mechanisms 1245 available on the local system to the caller for negotiation, for 1246 which appropriate credentials are available. 1247 o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 1248 used on the local system by the caller for negotiation, for the 1249 given credentials. 1250 1251A.1 GSS_Set_neg_mechs call 1252 1253 Inputs: 1254 1255 o cred_handle CREDENTIAL HANDLE, -- NULL specifies default 1256 -- credentials 1257 o mech_set SET OF OBJECT IDENTIFIER 1258 1259 Outputs: 1260 1261 o major_status INTEGER, 1262 o minor_status INTEGER 1263 1264 Return major_status codes: 1265 1266 o GSS_S_COMPLETE indicates that the set of security mechanisms 1267 available for negotiation has been set to mech_set. 1268 o GSS_S_FAILURE indicates that the requested operation could not be 1269 performed for reasons unspecified at the GSS-API level. 1270 1271 Allows callers to specify the set of security mechanisms that may be 1272 negotiated with the credential identified by cred_handle. This call 1273 is intended for support of specialized callers who need to restrict 1274 the set of negotiable security mechanisms from the set of all 1275 security mechanisms available to the caller (based on available 1276 credentials). Note that if more than one mechanism is specified in 1277 mech_set, the order in which those mechanisms are specified implies a 1278 relative preference. 1279 1280A.2 GSS_Get_neg_mechs call 1281 1282 Input: 1283 1284 1285 1286 1287 1288Zhu, et al. Expires June 15, 2005 [Page 23] 1289 1290Internet-Draft GSS-API Negotiation Mechanism December 2004 1291 1292 1293 o cred_handle CREDENTIAL HANDLE -- NULL specifies default 1294 -- credentials 1295 1296 Outputs: 1297 1298 o major_status INTEGER, 1299 o minor_status INTEGER, 1300 o mech_set SET OF OBJECT IDENTIFIER 1301 1302 Return major_status codes: 1303 1304 o GSS_S_COMPLETE indicates that the set of security mechanisms 1305 available for negotiation has been returned in mech_set. 1306 o GSS_S_FAILURE indicates that the requested operation could not be 1307 performed for reasons unspecified at the GSS-API level. 1308 1309 Allows callers to determine the set of security mechanisms available 1310 for negotiation with the credential identified by cred_handle. This 1311 call is intended for support of specialized callers who need to 1312 reduce the set of negotiable security mechanisms from the set of 1313 supported security mechanisms available to the caller (based on 1314 available credentials). 1315 1316 Note: The GSS_Indicate_mechs() function indicates the full set of 1317 mechanism types available on the local system. Since this call has 1318 no input parameter, the returned set is not necessarily available for 1319 all credentials. 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344Zhu, et al. Expires June 15, 2005 [Page 24] 1345 1346Internet-Draft GSS-API Negotiation Mechanism December 2004 1347 1348 1349Appendix B. Changes since RFC2478 1350 1351 SPNEGO implementations in Windows 2000/Windows XP/Windows Server 1352 2003 have the following behavior: no mechlistMIC is produced and 1353 mechlistMIC is not processed if one is provided; if the initiator 1354 sends the last mechanism token, the acceptor will send back a 1355 negotiation token with an accept_complete state and no mechlistMIC 1356 token. In addition, an incorrect OID (1.2.840.48018.1.2.2) can be 1357 used to identify the GSS-API Kerberos Version 5 mechanism. 1358 1359 The following changes have been made to be compatible with these 1360 legacy implementations. 1361 1362 * NegTokenTarg is changed to negTokenResp and it is the message 1363 format for all subsequent negotiation tokens. 1364 * NegTokenInit is the message for the initial negotiation message 1365 and that message only. 1366 * mechTypes in negTokenInit is not optional. 1367 * If the selected mechanism is also the most preferred mechanism 1368 for both peers, it is safe to omit the MIC tokens. 1369 1370 If at least one of the two peers implements the updated pseudo 1371 mechanism in this document, the negotiation is protected. 1372 1373 The following changes are to address the problems in RFC 2478. 1374 1375 * reqFlags is not protected therefore it should not impact the 1376 negotiation. 1377 * DER encoding is required. 1378 * GSS_GetMIC() input is clarified. 1379 * Per-message integrity services are requested for the negotiated 1380 mechanism. 1381 * Two MIC tokens are exchanged, one in each direction. 1382 1383 An implementation that conforms to this specification will not 1384 interoperate with a strict 2748 implementation. Even if the new 1385 implementation always sends a mechlistMIC token, it will still fail 1386 to interoperate. If it is a server, it will fail because it requests 1387 a mechlistMIC token using an option that older implementations simply 1388 do not support. Clients will tend to fail as well. 1389 1390 As an alternative to the approach chosen in this specification, we 1391 could have documented a correct behavior that is fully backward 1392 compatible with RFC 2478 and included an appendix on how to 1393 interoperate with existing incorrect implementations of RFC 2478. 1394 1395 As a practical matter, the SPNEGO implementers within the IETF have 1396 valued interoperability with the Microsoft implementations. We were 1397 1398 1399 1400Zhu, et al. Expires June 15, 2005 [Page 25] 1401 1402Internet-Draft GSS-API Negotiation Mechanism December 2004 1403 1404 1405 unable to choose to maintain reasonable security guarantees, maintain 1406 interoperability with the Microsoft implementations and maintain 1407 interoperability with correct implementations of RFC 2478. The 1408 working group was not aware of any RFC 2478 implementations deployed 1409 on the Internet. Even if there are such implementations, it is 1410 unlikely that they will interoperate because of a critical flaw in 1411 the description of the encoding of the mechanism list in RFC 2478. 1412 1413 With the approach taken in this specification, security is ensured 1414 between new implementations all the time while maintaining 1415 interoperability with the implementations deployed within the IETF 1416 community. The working group believes that this justifies breaking 1417 compatibility with a correct implementation of RFC 2478. 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456Zhu, et al. Expires June 15, 2005 [Page 26] 1457 1458Internet-Draft GSS-API Negotiation Mechanism December 2004 1459 1460 1461Appendix C. mechListMIC Computation Example 1462 1463 The following is an example to illustrate how the mechListMIC field 1464 would be computed. 1465 1466 The initial part of the DER encoding of NegTokenInit is constructed 1467 as follows (the "nn" are length encodings, possibly longer than one 1468 octet): 1469 1470 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) 1471 nn -- length 1472 1473 -- contents octets of the SEQUENCE begin with 1474 -- DER encoding of "[0] MechTypeList": 1475 A0 -- identifier octet for constructed [0] 1476 nn -- length 1477 1478 -- contents of the constructed [0] are DER encoding 1479 -- of MechTypeList (which is a SEQUENCE): 1480 30 -- identifier octet for constructed SEQUENCE 1481 nn -- length 1482 1483 -- contents octets of the SEQUENCE begin with 1484 -- DER encoding of OBJECT IDENTIFIER: 1485 06 -- identifier octet for primitive OBJECT IDENTIFIER 1486 09 -- length 1487 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 1488 -- {1 2 840 113554 1 2 2} 1489 1490 If a mechlistMIC needs to be generated (according to the rules in 1491 Section 5), it is computed by using the DER encoding of the type 1492 MechTypeList data from the initiator's NegTokenInit token as input to 1493 the GSS_GetMIC() function. In this case, the MIC would be computed 1494 over the following octets: 1495 1496 DER encoding of MechTypeList: 1497 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... 1498 1499 Note that the identifier octet and lengh octet(s) for constructed [0] 1500 (A0 nn) are not included in the MIC computation. 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512Zhu, et al. Expires June 15, 2005 [Page 27] 1513 1514Internet-Draft GSS-API Negotiation Mechanism December 2004 1515 1516 1517Intellectual Property Statement 1518 1519 The IETF takes no position regarding the validity or scope of any 1520 Intellectual Property Rights or other rights that might be claimed to 1521 pertain to the implementation or use of the technology described in 1522 this document or the extent to which any license under such rights 1523 might or might not be available; nor does it represent that it has 1524 made any independent effort to identify any such rights. Information 1525 on the procedures with respect to rights in RFC documents can be 1526 found in BCP 78 and BCP 79. 1527 1528 Copies of IPR disclosures made to the IETF Secretariat and any 1529 assurances of licenses to be made available, or the result of an 1530 attempt made to obtain a general license or permission for the use of 1531 such proprietary rights by implementers or users of this 1532 specification can be obtained from the IETF on-line IPR repository at 1533 http://www.ietf.org/ipr. 1534 1535 The IETF invites any interested party to bring to its attention any 1536 copyrights, patents or patent applications, or other proprietary 1537 rights that may cover technology that may be required to implement 1538 this standard. Please address the information to the IETF at 1539 ietf-ipr@ietf.org. 1540 1541 1542Disclaimer of Validity 1543 1544 This document and the information contained herein are provided on an 1545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1547 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1548 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1549 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1551 1552 1553Copyright Statement 1554 1555 Copyright (C) The Internet Society (2004). This document is subject 1556 to the rights, licenses and restrictions contained in BCP 78, and 1557 except as set forth therein, the authors retain all their rights. 1558 1559 1560Acknowledgment 1561 1562 Funding for the RFC Editor function is currently provided by the 1563 Internet Society. 1564 1565 1566 1567 1568Zhu, et al. Expires June 15, 2005 [Page 28] 1569 1570 1571