1NETWORK WORKING GROUP L. Zhu 2Internet-Draft K. Jaganathan 3Obsoletes: 2478 (if approved) R. Ward 4Expires: April 18, 2005 Microsoft Corporation 5 October 18, 2004 6 7 8 9 The Simple and Protected GSS-API Negotiation Mechanism 10 draft-zhu-spnego-2478bis-00 11 12 13Status of this Memo 14 15 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 22 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 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 34 35 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 38 39 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 42 43 44 This Internet-Draft will expire on April 18, 2005. 45 46 47Copyright Notice 48 49 50 Copyright (C) The Internet Society (2004). 51 52 53Abstract 54 55 56 This document specifies a security negotiation mechanism for the 57 Generic Security Service Application Program Interface (GSS-API) 58 which is described in RFC 2743. 59 60 61 This mechanism allows negotiating and choosing one security mechanism 62 from a common set of security mechanisms shared by GSS-API peers. 63 64 65 66 67Zhu, et al. Expires April 18, 2005 [Page 1] 68Internet-Draft GSS-API Negotiation Mechanism October 2004 69 70 71 72 Once the common security mechanism is identified, the security 73 mechanism MAY also negotiate mechanism-specific options during its 74 context establishment, but that will be inside the mechanism tokens, 75 and invisible to this protocol. 76 77 78Table of Contents 79 80 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 83 3. Negotiation Model . . . . . . . . . . . . . . . . . . . . . . 5 84 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 5 85 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 6 86 4. Data Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.1 Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 11 88 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 11 89 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 12 90 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 13 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 95 A. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 17 96 Intellectual Property and Copyright Statements . . . . . . . . 18 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126Zhu, et al. Expires April 18, 2005 [Page 2] 127Internet-Draft GSS-API Negotiation Mechanism October 2004 128 129 130 1311. Introduction 132 133 134 The GSS-API [RFC2743] provides a generic interface which can be 135 layered atop different security mechanisms such that if communicating 136 peers acquire GSS-API credentials for the same security mechanism, 137 then a security context MAY be established between them (subject to 138 policy). However, GSS-API doesn't prescribe the method by which 139 GSS-API peers can establish whether they have a common security 140 mechanism. 141 142 143 The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism 144 defined here is a pseudo-security mechanism, represented by the 145 object identifier iso.org.dod.internet.security.mechanism.snego 146 (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band 147 whether their credentials share common GSS-API security mechanism(s), 148 and if so, to invoke normal security context establishment for a 149 selected common security mechanism. This is most useful for 150 applications that are based on GSS-API implementations which support 151 multiple security mechanisms. 152 153 154 The simple and protected GSS-API mechanism negotiation is based on 155 the following negotiation model: the initiator proposes one security 156 mechanism or a list of security mechanisms in its preference order 157 (favorite choice first), the acceptor (the target) either accepts the 158 proposed security mechanism, or chooses one from the offered list, or 159 rejects the proposed value(s). The target then informs the initiator 160 of its choice. 161 162 163 In order to avoid an extra round trip, the initial security token of 164 the preferred mechanism for the initiator SHOULD be embedded in the 165 initial negotiation token (as defined in Section 4.2). If the target 166 preferred mechanism matches the initiator's preferred mechanism, no 167 additional round trips may be incurred by using the negotiation 168 protocol. 169 170 171 The negotiation is protected and all the underlying mechanisms 172 offered by the initiator MUST be capable of integrity protection. 173 174 175 The Simple and Protected GSS-API Negotiation Mechanism uses the 176 concepts developed in the GSS-API specification [RFC2743]. The 177 negotiation data is encapsulated in context-level tokens. Therefore, 178 callers of the GSS-API do not need to be aware of the existence of 179 the negotiation tokens but only of the new pseudo-security mechanism. 180 A failure in the negotiation phase causes a major status code to be 181 returned: GSS_S_BAD_MECH. 182 183 184 185 186 187 188 189Zhu, et al. Expires April 18, 2005 [Page 3] 190Internet-Draft GSS-API Negotiation Mechanism October 2004 191 192 193 1942. Conventions Used in This Document 195 196 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247Zhu, et al. Expires April 18, 2005 [Page 4] 248Internet-Draft GSS-API Negotiation Mechanism October 2004 249 250 251 2523. Negotiation Model 253 254 2553.1 Negotiation Description 256 257 258 Each OID represents one GSS-API mechanism or one variant of it. 259 260 261 The first negotiation token sent by the initiator contains an ordered 262 list of mechanisms (in preference order, favorite choice first), and 263 OPTIONALLY the initial security token for the preferred mechanism of 264 the initiator (i.e. the first of the list). 265 266 267 The target then processes the token from the initiator. This will 268 result in one of three possible states (as defined in Section 4.2.2): 269 accept_completed, accept_incomplete, or reject. A reject state will 270 terminate the negotiation. An accept_completed state indicates that 271 not only was the initiator-selected mechanism acceptable to the 272 target, but that the initial token was sufficient to complete the 273 authentication. An accept_incomplete state indicates that the target 274 has selected a different mechanism or the preferred mechanism is 275 acceptable, but this mechanism requires at least one additional 276 message to complete the authentication. The target MAY produce a 277 context level token for a reject state. 278 279 280 The first negotiation token sent by the acceptor contains the result 281 of the negotiation (accept_completed, accept_incomplete or reject) 282 and, in case of accept, the agreed security mechanism. It MUST also 283 include the response mechanism token to the initial mechanism token 284 from the initiator, when the first proposed mechanism of the 285 initiator has been selected and an initial mechanism token was 286 provided by the initiator. However, if the initiator's preferred 287 mechanism is not possible, the target will not emit a response 288 mechanism token in the first reply. 289 290 291 The policy by which the target chooses a mechanism is an 292 implementation-specific local matter. In the absence of other 293 policy, the target MUST choose the first mechanism in the list for 294 which valid credentials are available. 295 296 297 The first negotiation token is the negTokenInit message and all 298 subsequent negotiation tokens are the negTokenResp message, as 299 defined in Section 4.2. 300 301 302 The use of partially-established contexts (as indicated by the 303 prot_ready_state in [RFC2743]), either for this mechanism or 304 mechanisms negotiated using this mechanism, is prohibited. 305 306 307 308 309 310 311 312Zhu, et al. Expires April 18, 2005 [Page 5] 313Internet-Draft GSS-API Negotiation Mechanism October 2004 314 315 316 3173.2 Negotiation Procedure 318 319 320 The negotiation procedure is summarized as follows: 321 322 323 (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, 324 but requests (either explicitly, with the negotiation mechanism, 325 or through accepting a default, when the default is the 326 negotiation mechanism) that the Simple and Protected GSS-API 327 Negotiation Mechanism is used; 328 329 330 (b) The initiator GSS-API implementation emits a negotiation token 331 containing a list of supported security mechanisms for the 332 credentials used for this context establishment, and OPTIONALLY an 333 initial security token for the first mechanism from that list 334 (i.e. the preferred mechanism), and indicates 335 GSS_S_CONTINUE_NEEDED status; 336 337 338 (c) The GSS-API initiator application sends the token to the target 339 application; 340 341 342 (d) The GSS-API target application deposits the token through 343 invoking GSS_Accept_sec_context. The target GSS-API application 344 will do one of the following: 345 346 347 (I) If the initiator's preferred mechanism is accepted by the 348 target, an initial token is included in the first token from 349 the initiator, no further mechanism token from the initiator is 350 needed for the chosen mechanism to establish the security 351 context, (e.g. when the authentication mechanism is unilateral 352 or mutual authentication has been performed and involves a 353 single token in either direction), and the initiator has not 354 sent a MIC token (the output token of the GSS_GetMIC() call 355 [RFC2743], the input to GSS_GetMIC() is the OTCET STRING field 356 representing the MechTypes in the initial NegTokenInit token), 357 of the mechanism list, the acceptor will do one of the 358 following: 359 360 361 1) If the initiator's preferred mechanism is accepted and there 362 is no policy on the target such that a different mechanism 363 other than the initiator's preferred mechanism could have 364 been selected given a different list of mechanisms, 365 GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE and it 366 MUST produce a negotiation token with the accept_completed 367 state, and with no MIC of the mechanism list. This is 368 referred in this document as the Safe to Omit MIC (SOMIC) 369 rule number 1. The resulting negotiation token MUST include 370 the security token if one is returned by the selected 371 mechanism; 372 373 374 375 376Zhu, et al. Expires April 18, 2005 [Page 6] 377 378 379 2) If the initiator's preferred mechanism is accepted and there 380 is policy exists on the target such that a different 381 mechanism other than the initiator's preferred mechanism 382 could have been selected given a different list of 383 mechanisms, GSS_Accept_sec_context() MUST indicate 384 GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and 385 a MIC MUST be generated by the target. This MIC is to be 386 verified by the initiator and the result will be sent back 387 to the acceptor. This is referred in this document as the 388 Safe to Omit MIC (SOMIC) rule number 2. The resulting 389 negotiation token MUST include the security token if one is 390 returned by the selected mechanism. 391 392 393 3) If there is a MIC token and it is correct, 394 GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE with 395 no output token; If there is an incorrect MIC token, 396 GSS_Accept_sec_context() must indicate GSS_S_BAD_MIC status, 397 OPTIONALLY returning a negotiation token with the reject 398 state. 399 400 401 (II) If the initiator's preferred mechanism is accepted, and an 402 initial token from this mechanism is sent by the initiator, but 403 a failure is returned by the chosen mechanism, 404 GSS_Accept_sec_context() MUST report the failure and the 405 mech_type output parameter indicates the selected mechanism. 406 The target MUST produce a negotiation token with the reject 407 state if the selected mechanism returns a response token (e.g. 408 a KRB_ERROR when the Kerberos Version 5 GSS-API mechanism is 409 chosen [GSSAPICFX]); 410 411 412 (III) If the initiator's preferred mechanism is accepted, and an 413 initial token from this mechanism is sent by the initiator, but 414 at last one more initiator token need to be transferred to 415 establish the context, GSS_Accept_sec_context() MUST indicate 416 GSS_S_CONTINUE_NEEDED status, returning a negotiation token 417 with the accept_incomplete state, the response mechanism token, 418 and no MIC token. 419 420 421 (IV) If the initiator's preferred mechanism is accepted, but no 422 initial token from this mechanism is sent by the initiator, 423 GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED 424 status, returning a negotiation token with the 425 accept_incomplete state, the selected mechanism, no response 426 mechanism token or MIC token. 427 428 429 (V) If a proposed mechanism is accepted, and it is not the 430 initiator's preferred mechanism, GSS_Accept_sec_context() MUST 431 indicate GSS_S_CONTINUE_NEEDED status, returning a negotiation 432 token with the accept_incomplete state, the selected mechanism, 433 no response mechanism token or MIC token. The negotiation will 434 435 436 437 438Zhu, et al. Expires April 18, 2005 [Page 7] 439Internet-Draft GSS-API Negotiation Mechanism October 2004 440 441 442 443 be the agreed security mechanism if the negotiation is 444 successful. 445 446 447 (e) The GSS-API target application returns the negotiation token to 448 the initiator application; 449 450 451 (f) The GSS-API initiator application deposits the token through 452 invoking GSS_Init_sec_context(). The initiator will do one of the 453 following: 454 455 456 (I) When the negotiation token carries an accept_completed result, 457 the initiator MUST do one of the following: 458 459 460 1) If the selected mechanism is the initiator's preferred 461 mechanism, the initiator SHALL NOT reject the negotiation if 462 no MIC token is present. This is referred in this document 463 as the Safe to Omit MIC ("SOMIC") rule number 3. The 464 initiator MUST deposit the security token if one is 465 included, GSS_Init_sec_context() MUST indicate 466 GSS_S_BAD_MECH status if the context is not established 467 after this GSS_Init_sec_context() call. If a MIC token is 468 present, the initiator MUST verify it and a GSS_S_BAD_MIC 469 must be returned if the MIC is incorrect; 470 471 472 2) If the selected mechanism is not the initiator's preferred 473 mechanism, and there is no or an incorrect MIC token, 474 GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC status. 475 This is referred in this document as the Safe to Omit MIC 476 ("SOMIC") rule number 4. 477 478 479 (II) When the negotiation token carries a reject result without a 480 response security token, GSS_Init_sec_context() MUST indicate 481 GSS_S_BAD_MECH status; 482 483 484 (III) When the negotiation token carries a reject result with a 485 response security token, the initiator MUST deposit the 486 security token, and GSS_Init_sec_context() MUST indicate a 487 failure status reported by the underlying mechanism, and the 488 output mech_type indicates the selected mechanism; 489 490 491 (IV) When the negotiation token carries an accept_incomplete 492 result and further mechanism tokens from the acceptor must be 493 transferred in order to complete context establishment, 494 GSS_Init_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED 495 status, returning an output token with the accept_incomplete, 496 and the selected mechanism's context level token; 497 498 499 500 501 502 503Zhu, et al. Expires April 18, 2005 [Page 8] 504Internet-Draft GSS-API Negotiation Mechanism October 2004 505 506 507 508 (V) When the negotiation token carries an accept_incomplete 509 result, no further mechanism token need to be transferred from 510 the acceptor to complete the context establishment, the 511 initiator MUST do one of the following: 512 513 514 1) If a MIC token was included, the initiator MUST verify it 515 and GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC if 516 the MIC is incorrect; GSS_Init_sec_context() MUST indicate 517 GSS_S_COMPLETE and produce a negotiation with the 518 accept_completed state if the MIC is correct. This is 519 referred in this document as the Safe to Omit MIC ("SOMIC") 520 rule number 5; 521 522 523 2) If no MIC token was present, GSS_Init_sec_context() MUST 524 indicate GSS_S_BAD_MIC statue, This is referred in this 525 document as the Safe to Omit MIC ("SOMIC") rule number 6. 526 527 528 (g) The initiator application then sends the output_token to the 529 target if one is returned. The security context initialization is 530 then continued according to the standard GSS-API conventions for 531 the selected mechanism, where the tokens of the selected mechanism 532 are encapsulated until the GSS_S_COMPLETE is returned for both the 533 initiator and the target. When no further mechanism token is 534 needed to be transferred and the context for the chosen mechanism 535 is established, the initiator and the acceptor will need to either 536 apply the "SOMIC" rules above and skip MIC generation and 537 verification, or generate and verify the MIC token to protect the 538 negotiation. 539 540 541 (h) When GSS_S_CONTINUE_NEEDED is returned, the mech_type output 542 parameter is not yet valid. When GSS_S_COMPLETE is returned, the 543 mech_type output parameter indicates the selected mechanism. 544 545 546 Note that the *_req_flag input parameters for context establishment 547 are relative to the selected mechanism, as are the *_state output 548 parameters. i.e., these parameters are not applicable to the 549 negotiation process per se. 550 551 552 On receipt of a negotiation token on the target side, a GSS-API 553 implementation that does not support negotiation would indicate the 554 GSS_S_BAD_MECH status as if a particular basic security mechanism had 555 been requested but was not supported. 556 557 558 When GSS_Acquire_cred is invoked with the negotiation mechanism as 559 desired_mechs, an implementation-specific default credential is used 560 to carry on the negotiation. A set of mechanisms as specified 561 locally by the system administrator is then available for 562 negotiation. If there is a desire for the caller to make its own 563 564 565 566 567Zhu, et al. Expires April 18, 2005 [Page 9] 568Internet-Draft GSS-API Negotiation Mechanism October 2004 569 570 571 572 choice, then an additional API has to be used as defined in [PRTSTK]. 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624Zhu, et al. Expires April 18, 2005 [Page 10] 625Internet-Draft GSS-API Negotiation Mechanism October 2004 626 627 628 6294. Data Elements 630 631 632 The type definitions in this section assume an ASN.1 module 633 definition of the following form: 634 635 636 SPNEGOASNOneSpec { 637 iso(1) identified-organization(3) dod(6) internet(1) 638 security(5) mechanism(5) snego (2) 639 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 640 641 642 -- rest of definitions here 643 644 645 END 646 647 648 This specifies that the tagging context for the module will be 649 explicit and non-automatic. 650 651 652 The encoding of SPNEGO protocol messages shall obey the Distinguished 653 Encoding Rules (DER) of ASN.1 as described in [X690]. 654 655 6564.1 Mechanism Type 657 658 659 MechType ::= OBJECT IDENTIFIER 660 -- OID represents each security mechanism as suggested by 661 -- [RFC2743] 662 663 664 6654.2 Negotiation Tokens 666 667 668 The syntax of the initial negotiation tokens follows the 669 InitialContextToken syntax defined in [RFC2743]. The security 670 mechanism of the initial negotiation token is identified by the 671 Object Identifier in Section 1. All subsequent tokens are not 672 encapsulated in the above generic token framing. 673 674 675 This section specifies the syntax of initial and subsequent context 676 level tokens. 677 678 679 NegotiationToken ::= CHOICE { 680 negTokenInit [0] NegTokenInit, 681 negTokenResp [1] negTokenResp 682 } 683 684 685 MechTypeList ::= SEQUENCE OF MechType 686 687 688 689 690 691 692 693 694Zhu, et al. Expires April 18, 2005 [Page 11] 695Internet-Draft GSS-API Negotiation Mechanism October 2004 696 697 698 6994.2.1 negTokenInit 700 701 702 NegTokenInit ::= SEQUENCE { 703 mechTypes [0] MechTypeList, 704 reqFlags [1] ContextFlags OPTIONAL, 705 mechToken [2] OCTET STRING OPTIONAL, 706 mechListMIC [3] OCTET STRING OPTIONAL, 707 ... 708 } 709 710 711 ContextFlags ::= BIT STRING { 712 delegFlag (0), 713 mutualFlag (1), 714 replayFlag (2), 715 sequenceFlag (3), 716 anonFlag (4), 717 confFlag (5), 718 integFlag (6) 719 } 720 721 722 This is the message for the initial negotiation token. 723 724 725 mechTypes 726 727 728 This field contains one or more security mechanisms in the 729 preference order (favorite choice first) supported by the 730 initiator (as indicated in the field mechTypes). 731 732 733 reqFlags 734 735 736 This field, if present, contains the service options that are 737 requested to establish the context. The context flags SHOULD 738 be filled in from the req_flags parameter of 739 GSS_Init_sec_context(). This field SHALL NOT influence the 740 outcome of the negotiation. 741 742 743 mechToken 744 745 746 This field, is present, contains an optimistic negotiation 747 response. 748 749 750 mechListMIC 751 752 753 This field, if present, contains the result of a GSS_GetMIC() 754 [RFC2743] of the MechTypes field in the initial NegTokenInit 755 token. It allows verifying that the list initially sent by the 756 initiator has been received unmodified by the target. 757 758 759 760 761 762Zhu, et al. Expires April 18, 2005 [Page 12] 763Internet-Draft GSS-API Negotiation Mechanism October 2004 764 765 766 7674.2.2 negTokenResp 768 769 770 NegTokenResp ::= SEQUENCE { 771 negResult [0] ENUMERATED { 772 accept_completed (0), 773 accept_incomplete (1), 774 reject (2) 775 }, 776 supportedMech [1] MechType OPTIONAL, 777 responseToken [2] OCTET STRING OPTIONAL, 778 mechListMIC [3] OCTET STRING OPTIONAL, 779 -- used only by the acceptor 780 ... 781 } 782 783 784 This is the message for all the subsequent tokens. 785 786 787 negResult 788 789 790 Result of the negotiation exchange, specified by the target. 791 This can be: 792 793 794 accept_completed 795 A security mechanism is selected, and the context is 796 established for the sender; 797 798 799 accept_incomplete 800 Further exchanges are necessary; 801 802 803 reject 804 The sender reject the proposed security mechanism(s). 805 806 807 accept_completed indicates that a context has been successfully 808 established, while the result accept_incomplete indicates that 809 additional token exchanges are needed. 810 811 812 For those targets that support piggybacking the initial 813 mechToken, an optimistic negotiation response is possible and 814 includes in that case a responseToken which MAY continue the 815 authentication exchange (e.g. when mutual authentication has 816 been requested or when unilateral authentication requires 817 several round trips). Otherwise the responseToken is used to 818 carry the tokens specific to the mechanism selected. 819 820 821 The mechListMIC, when present, is a MIC computed over the 822 MechTypes using the mechanism list field in the initial token 823 (encoded in DER). 824 825 826 827 828 829Zhu, et al. Expires April 18, 2005 [Page 13] 830Internet-Draft GSS-API Negotiation Mechanism October 2004 831 832 833 834 supportedMech 835 836 837 This field is present and only present in the first 838 negTokenResp token. It is a choice from the mechanisms offered 839 by the initiator. 840 841 842 responseToken 843 844 845 This field, if present, contains the security token of the 846 selected mechanism. 847 848 849 mechListMIC 850 851 852 This field, if present, contains the result of a GSS_GetMIC() 853 [RFC2743] of the MechTypes field in the initial NegTokenInit 854 token. It allows verifying that the list initially sent by the 855 initiator has been received unmodified by the target. 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891Zhu, et al. Expires April 18, 2005 [Page 14] 892Internet-Draft GSS-API Negotiation Mechanism October 2004 893 894 895 8965. Security Considerations 897 898 899 In order to produce the MIC for the mechanism list, the mechanism 900 MUST provide integirty protection. When one of the mechanisms 901 proposed by the initiator does not support integrity protection, then 902 the negotiation is exposed to all threats a non secured service is 903 exposed. In particular, an active attacker can force to use a 904 security mechanism which is not the common preferred one (when 905 multiple security mechanisms are shared between peers) but which is 906 acceptable anyway to the target, thus this mechanism does not support 907 selecting a mechanism that does not support integrity protection. 908 909 910 In any case, the communicating peers MAY be exposed to the denial of 911 service threat. 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950Zhu, et al. Expires April 18, 2005 [Page 15] 951Internet-Draft GSS-API Negotiation Mechanism October 2004 952 953 954 9556. Acknowledgments 956 957 958 The authors wish to thank Paul Leach and Todd Stecher for theirs 959 comments and suggestions on earlier versions of this document. 960 961 962 Eric Baize and Denis Pinkas wrote the original SPNEGO specification 963 [RFC2478], of which some of the text has been retained in this 964 document. 965 966 9677 References 968 969 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, March 1997. 972 973 974 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 975 Negotiation Mechanism", RFC 2478, December 1998. 976 977 978 [RFC2743] Linn, J., "Generic Security Service Application Program 979 Interface Version 2, Update 1", RFC 2743, January 2000. 980 981 982 [PRTSTK] RFC-Editor: To be replaced by RFC number for draft-williams 983 -gssapi-stackable-pseudo-mechs. Work in progress. 984 985 [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules 986 (BER), Canonical Encoding Rules (CER) and Distinguished 987 Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 988 ISO/IEC International Standard 8825-1:1998. 989 990 991Authors' Addresses 992 993 994 Larry Zhu 995 Microsoft Corporation 996 One Microsoft Way 997 Redmond, WA 98052 998 US 999 1000 1001 EMail: lzhu@microsoft.com 1002 1003 1004 1005 Karthik Jaganathan 1006 Microsoft Corporation 1007 One Microsoft Way 1008 Redmond, WA 98052 1009 US 1010 1011 1012 EMail: karthikj@microsoft.com 1013 1014 1015 1016 Richard B. Ward 1017 Microsoft Corporation 1018 One Microsoft Way 1019 Redmond, WA 98052 1020 US 1021 1022 1023 EMail: richardw@microsoft.com 1024 1025 1026 1027 1028Zhu, et al. Expires April 18, 2005 [Page 16] 1029Internet-Draft GSS-API Negotiation Mechanism October 2004 1030 1031 1032 1033Appendix A. Changes since RFC2478 1034 1035 1036 The following changes are designed to be compatible with an 1037 incorrect implementation of RFC 2478 shipped in Windows 2000. A 1038 correct implementation of this protocol that negotiates the 2 leg 1039 Kerberos GSS-API mechanism as the only available security 1040 mechanism should be ale to interoperate with the implementation of 1041 Windows 2000 when the mangled OID (1.2.840.48018.1.2.2) can be 1042 used to identify Kerberos. 1043 1044 1045 * The negTokenTarg is changed to negTokenResp and it is now the 1046 format for all subsequent negotiation messages. 1047 * negTokenInit is the message for the initial token and that 1048 token only. 1049 * mechTypes in negTokenInit is no longer optional. 1050 * negResult is no longer optional in the negTokenResp token. 1051 * The initiator does not send the MIC token. 1052 * Add rules when it is safe to omit the MIC token. Search for 1053 SOMIC. 1054 1055 1056 The following changes are to address the problems in RFC 2478. 1057 1058 1059 * reqFlags is not protected therefore it should not impact the 1060 negotiation. 1061 * BER encoding is required. 1062 * GSS_GetMIC() input is clarified. 1063 * Nico's stackable pseudo mechanism draft is used to replace the 1064 support APIs. 1065 * We no longer support negotiating mechanisms that do not provide 1066 for integrity. That support does not add security values but 1067 blows up the interoperability test matrix. 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089Zhu, et al. Expires April 18, 2005 [Page 17] 1090Internet-Draft GSS-API Negotiation Mechanism October 2004 1091 1092 1093 1094Intellectual Property Statement 1095 1096 1097 The IETF takes no position regarding the validity or scope of any 1098 Intellectual Property Rights or other rights that might be claimed to 1099 pertain to the implementation or use of the technology described in 1100 this document or the extent to which any license under such rights 1101 might or might not be available; nor does it represent that it has 1102 made any independent effort to identify any such rights. Information 1103 on the procedures with respect to rights in RFC documents can be 1104 found in BCP 78 and BCP 79. 1105 1106 1107 Copies of IPR disclosures made to the IETF Secretariat and any 1108 assurances of licenses to be made available, or the result of an 1109 attempt made to obtain a general license or permission for the use of 1110 such proprietary rights by implementers or users of this 1111 specification can be obtained from the IETF on-line IPR repository at 1112 http://www.ietf.org/ipr. 1113 1114 1115 The IETF invites any interested party to bring to its attention any 1116 copyrights, patents or patent applications, or other proprietary 1117 rights that may cover technology that may be required to implement 1118 this standard. Please address the information to the IETF at 1119 ietf-ipr@ietf.org. 1120 1121 1122 1123Disclaimer of Validity 1124 1125 1126 This document and the information contained herein are provided on an 1127 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1128 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1129 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1130 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1131 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1132 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1133 1134 1135 1136Copyright Statement 1137 1138 1139 Copyright (C) The Internet Society (2004). This document is subject 1140 to the rights, licenses and restrictions contained in BCP 78, and 1141 except as set forth therein, the authors retain all their rights. 1142 1143 1144 1145Acknowledgment 1146 1147 1148 Funding for the RFC Editor function is currently provided by the 1149 Internet Society. 1150 1151 1152 1153 1154 1155Zhu, et al. Expires April 18, 2005 [Page 18]