1 2 3 4 5 6 7Network Working Group E. Baize 8Request for Comments: 2478 D. Pinkas 9Category: Standards Track Bull 10 December 1998 11 12 13 The Simple and Protected GSS-API Negotiation Mechanism 14 15Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (1998). All Rights Reserved. 26 271. ABSTRACT 28 29 This document specifies a Security Negotiation Mechanism for the 30 Generic Security Service Application Program Interface (GSS-API) 31 which is described in [1]. 32 33 The GSS-API provides a generic interface which can be layered atop 34 different security mechanisms such that if communicating peers 35 acquire GSS-API credentials for the same security mechanism, then a 36 security context may be established between them (subject to policy). 37 However, GSS-API doesn't prescribe the method by which GSS-API peers 38 can establish whether they have a common security mechanism. 39 40 The Simple and Protected GSS-API Negotiation Mechanism defined here 41 is a pseudo-security mechanism, represented by the object identifier 42 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which 43 enables GSS-API peers to determine in-band whether their credentials 44 share common GSS-API security mechanism(s), and if so, to invoke 45 normal security context establishment for a selected common security 46 mechanism. This is most useful for applications that are based on 47 GSS-API implementations which support multiple security mechanisms. 48 49 This allows to negotiate different security mechanisms, different 50 options within a given security mechanism or different options from 51 several security mechanisms. 52 53 54 55 56 57 58Baize & Pinkas Standards Track [Page 1] 59 60RFC 2478 GSS-API Negotiation Mechanism December 1998 61 62 63 Once the common security mechanism is identified, the security 64 mechanism may also negotiate mechanism-specific options during its 65 context establishment. This will be inside the mechanism tokens, and 66 invisible to the SPNEGO protocol. 67 68 The simple and protected GSS-API mechanism negotiation is based on 69 the following negotiation model : the initiator proposes one security 70 mechanism or an ordered list of security mechanisms, the target 71 either accepts the proposed security mechanism, or chooses one from 72 an offered set, or rejects the proposed value(s). The target then 73 informs the initiator of its choice. 74 75 In its basic form this protocol requires an extra-round trip. Network 76 connection setup is a critical performance characteristic of any 77 network infrastructure and extra round trips over WAN links, packet 78 radio networks, etc. really make a difference. In order to avoid such 79 an extra round trip the initial security token of the preferred 80 mechanism for the initiator may be embedded in the initial token. If 81 the target preferred mechanism matches the initiator's preferred 82 mechanism, no additional round trips are incurred by using the 83 negotiation protocol. 84 85 The simple and protected GSS-API mechanism negotiation provides a 86 technique to protect the negotiation that must be used when the 87 underlying mechanism selected by the target is capable of integrity 88 protection. 89 90 When all the mechanisms proposed by the initiator support integrity 91 protection or when the selected mechanism supports integrity 92 protection, then the negotiation mechanism becomes protected since 93 this guarantees that the appropriate mechanism supported by both 94 peers has been selected. 95 96 The Simple and Protected GSS-API Negotiation Mechanism uses the 97 concepts developed in the GSS-API specification [1]. The negotiation 98 data is encapsulated in context-level tokens. Therefore, callers of 99 the GSS-API do not need to be aware of the existence of the 100 negotiation tokens but only of the new pseudo-security mechanism. A 101 failure in the negotiation phase causes a major status code to be 102 returned: GSS_S_BAD_MECH. 103 104 105 106 107 108 109 110 111 112 113 114Baize & Pinkas Standards Track [Page 2] 115 116RFC 2478 GSS-API Negotiation Mechanism December 1998 117 118 1192. NEGOTIATION MODEL 120 1212.1. Negotiation description 122 123 The model for security mechanism negotiation reuses a subset of the 124 concepts specified in [2]. 125 126 Each OID represents one GSS-API mechanism or one variant of it. 127 128 - When one security mechanism is proposed by the initiator, it 129 represents the only security mechanism supported or selected 130 (when the additional APIs defined in the Annex A are used) by the 131 initiator. 132 133 - When several security mechanisms are proposed by the initiator, 134 they represent a set of security mechanisms supported or selected 135 (when the additional APIs defined in the Annex A are used) by the 136 initiator. 137 138 The first negotiation token sent by the initiator contains an ordered 139 list of mechanisms, a set of options (e.g. deleg, replay, conf flags) 140 that should be supported by the selected mechanism and optionally the 141 initial security token for the desired mechanism of the initiator 142 (i.e. the first of the list). 143 144 The first negotiation token sent by the target contains the result of 145 the negotiation (accept_completed, accept_incomplete or reject) and, 146 in case of accept, the agreed security mechanism. It may also include 147 the response to the initial security token from the initiator, when 148 the first proposed mechanism of the initiator has been selected. When 149 the first mechanism is acceptable to the target,it should respond to 150 the initial security token for the desired mechanism of the initiator 151 when it is present. However, if this is not possible, the target can 152 simply ignore it and omit the responseToken from the first reply. 153 154 Implementations that can piggyback the initial token will be rewarded 155 by faster connection setup. 156 157 In case of a successful negotiation, the security mechanism 158 represents the value suitable for the target, and picked up from the 159 list offered by the initiator. The policy by which the target 160 chooses a mechanism is an implementation-specific local matter. In 161 the absence of other policy, the target should chose the first 162 mechanism in the list for which valid credentials are available. 163 164 Once a mechanism has been selected, the tokens specific to the 165 selected mechanism are carried within the negotiation tokens (in the 166 mechToken for the initiator and in the responseToken for the target). 167 168 169 170Baize & Pinkas Standards Track [Page 3] 171 172RFC 2478 GSS-API Negotiation Mechanism December 1998 173 174 1752.2. Negotiation procedure 176 177 The negotiation procedure is summarised as follows: 178 179 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 180 requests (either explicitly, with the negotiation mechanism, or 181 through accepting a default, when the default is the negotiation 182 mechanism) that the Simple and Protected GSS-API Negotiation 183 Mechanism be used; 184 185 (b) the initiator GSS-API implementation emits a negotiation token 186 containing a list of supported security mechanisms for the 187 credentials used for this context establishment, and optionally 188 an initial security token for the first mechanism from that list 189 (i.e. the preferred mechanism), and indicates 190 GSS_S_CONTINUE_NEEDED status; 191 192 (c) The GSS-API initiator sends the token to the target application; 193 194 (d) The GSS-API target deposits the token through invoking 195 GSS_Accept_sec_context. The target GSS-API implementation emits a 196 negotiation token containing which if any of the proposed 197 mechanisms it supports (or has selected). 198 199 If the mechanism selected by the target matches the preferred 200 mechanism identified by the initiator and the initiator provides a 201 mechToken, the negotiation token response may contain also an initial 202 security token from that mechanism. 203 204 If the preferred mechanism is accepted, GSS_Accept_sec_context() 205 indicates GSS_S_COMPLETE when unilateral or mutual authentication has 206 been performed and involves a single token in either direction. 207 208 If a proposed mechanism is accepted, and it was not the preferred 209 mechanism, or if the first negotiation token sent by the initiator 210 did not included a mechToken, then the negotiation token response 211 sent by the target may contain also a response token from that 212 mechanism which transmits mechanism-specific information (e.g. to 213 transmit a certificate). The initiator may ignore such an initial 214 token if it is not prepared to process it. 215 216 If a proposed mechanism other than the preferred mechanism is 217 accepted, or the preferred mechanism is accepted but involves 218 multiple exchanges (e.g. challenge-response authentication), then 219 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status. 220 221 222 223 224 225 226Baize & Pinkas Standards Track [Page 4] 227 228RFC 2478 GSS-API Negotiation Mechanism December 1998 229 230 231 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 232 indicates GSS_S_BAD_MECH status. The security context initialisation 233 has failed. 234 235 (e) The GSS-API target returns the token to the initiator 236 application; 237 238 (f) The GSS-API initiator deposits the token through invoking 239 GSS_Init_sec_context. 240 241 GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, 242 GSS_S_COMPLETE or GSS_S_BAD_MECH status. 243 244 The GSS_S_BAD_MECH status is returned when the negotiation token 245 carries a reject result or when the negotiation token carries an 246 accept result and the mechanism selected by the target is not 247 included in the initial list sent by the initiator. 248 249 The GSS_S_BAD_MIC status is returned when the selected mechanism 250 supports a MIC token but the MIC computed over the list of 251 mechanisms sent by the initiator is missing or incorrect. 252 253 If the negotiation token carries a reject result, the context 254 establishment is impossible. For example, a rejection will occur 255 if the target doesn't support the initiator's proposed mechanism 256 type(s). Upon failure of the mechanism negotiation procedure, the 257 mech_type output parameter value is the negotiation mechanism 258 type. 259 260 The GSS_S_CONTINUE_NEEDED status is returned when the negotiation 261 token carries an accept result and further tokens must be 262 transferred in order to complete context establishment for the 263 selected mechanism. In that case GSS_Init_sec_context() returns an 264 initial context token as output_token (with the selected 265 mechanism's context token encapsulated within that output_token). 266 267 The initiator then sends the output_token to the target. The 268 security context initialisation is then continued according to the 269 standard GSS-API conventions for the selected mechanism, where the 270 tokens of the selected mechanism are encapsulated until the 271 GSS_S_COMPLETE is returned for both the initiator and the target. 272 When GSS_S_CONTINUE_NEEDED is returned, the mech_type output 273 parameter is not yet valid. 274 275 When GSS_S_COMPLETE is returned, the mech_type output parameter 276 indicates the selected mechanism. When the final negotiation token 277 does not contain a MIC, the initiator GSS-API implementation must 278 check the returned/selected mechanism is on the originally 279 280 281 282Baize & Pinkas Standards Track [Page 5] 283 284RFC 2478 GSS-API Negotiation Mechanism December 1998 285 286 287 submitted list of mechanisms and also verify that the selected 288 mechanism is not able to support a MIC. When the final negotiation 289 token contains a MIC over the initial mechanisms list sent by the 290 initiator, the MIC must be verified. 291 292 Note that the *_req_flag input parameters for context establishment 293 are relative to the selected mechanism, as are the *_state output 294 parameters. i.e., these parameters are not applicable to the 295 negotiation process per se. 296 297 The initiator GSS-API calling application may need to know when the 298 negotiation exchanges were protected or not. For this, when 299 GSS_S_COMPLETE is returned, it can simply test the integ_avail flag. 300 When this flag is set it indicates that the negotiation was 301 protected. 302 303 On receipt of a negotiation token on the target side, a GSS-API 304 implementation that does not support negotiation would indicate the 305 GSS_S_BAD_MECH status as if a particular basic security mechanism had 306 been requested but was not supported. 307 308 When GSS_Acquire_cred is invoked with the negotiation mechanism as 309 desired_mechs, an implementation-specific default credential is used 310 to carry on the negotiation. A set of mechanisms as specified locally 311 by the system administrator is then available for negotiation. If 312 there is a desire for the caller to make its own choice, then an 313 additional API has to be used (see Appendix A). 314 3153. DATA ELEMENTS 316 3173.1. Mechanism Type 318 319 MechType::= OBJECT IDENTIFIER 320 321 mechType 322 Each security mechanism is as defined in [1]. 323 3243.2. Negotiation Tokens 325 326 The syntax of the negotiation tokens follows the InitialContextToken 327 syntax defined in [1]. The security mechanism of the initial 328 negotiation token is identified by the Object Identifier 329 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 330 331 332 333 334 335 336 337 338Baize & Pinkas Standards Track [Page 6] 339 340RFC 2478 GSS-API Negotiation Mechanism December 1998 341 342 3433.2.1. Syntax 344 345 This section specifies the syntax of the corresponding 346 "innerContextToken" field for the first token and subsequent 347 negotiation tokens. During the mechanism negociation, the 348 "innerContextToken" field contains the ASN.1 structure 349 "NegociationToken" given below, encoded using the DER encoding 350 conventions. 351 352NegotiationToken ::= CHOICE { 353 negTokenInit [0] NegTokenInit, 354 negTokenTarg [1] NegTokenTarg } 355 356MechTypeList ::= SEQUENCE OF MechType 357 358NegTokenInit ::= SEQUENCE { 359 mechTypes [0] MechTypeList OPTIONAL, 360 reqFlags [1] ContextFlags OPTIONAL, 361 mechToken [2] OCTET STRING OPTIONAL, 362 mechListMIC [3] OCTET STRING OPTIONAL 363 } 364 365ContextFlags ::= BIT STRING { 366 delegFlag (0), 367 mutualFlag (1), 368 replayFlag (2), 369 sequenceFlag (3), 370 anonFlag (4), 371 confFlag (5), 372 integFlag (6) 373} 374 375negTokenInit 376 Negotiation token sent by the initiator to the target, which 377 contains, for the first token sent, one or more security mechanisms 378 supported by the initiator (as indicated in the field mechTypes) 379 and the service options (reqFlags) that are requested to establish 380 the context. The context flags should be filled in from the 381 req_flags parameter of init_sec_context(). 382 383 The mechToken field is optional for the first token sent that all 384 target implementations would not have to support. However for those 385 targets that do support piggybacking the initial mechToken, an 386 optimistic negotiation response is possible. Otherwise the 387 mechToken is used to carry the tokens specific to the mechanism 388 selected. 389 390 391 392 393 394Baize & Pinkas Standards Track [Page 7] 395 396RFC 2478 GSS-API Negotiation Mechanism December 1998 397 398 399 The mechListMIC is an optional field. In the case that the chosen 400 mechanism supports integrity, the initiator may optionally include 401 a mechListMIC which is the result of a GetMIC of the MechTypes in 402 the initial NegTokenInit and return GSS_S_COMPLETE. 403 404 When the chosen mechanism uses an odd number of messages, the final 405 mechanism token will be sent from the initiator to the acceptor. In 406 this case, there is a tradeoff between using the optimal number of 407 messages, or using an additional message from the acceptor to the 408 initiator in order to give the initiator assurance that no 409 modification of the initiator's mechanism list occurred. The 410 implementation can choose which tradeoff to make (see section 4.2.2 411 for further details for the processing of that field). 412 413NegTokenTarg ::= SEQUENCE { 414 negResult [0] ENUMERATED { 415 accept_completed (0), 416 accept_incomplete (1), 417 reject (2) } OPTIONAL, 418 supportedMech [1] MechType OPTIONAL, 419 responseToken [2] OCTET STRING OPTIONAL, 420 mechListMIC [3] OCTET STRING OPTIONAL 421} 422 423negTokenTarg 424 Negotiation token returned by the target to the initiator which 425 contains, for the first token returned, a global negotiation result 426 and the security mechanism selected (if any). 427 428negResult 429 The result accept_completed indicates that a context has been 430 successfully established, while the result accept_incomplete 431 indicates that additional token exchanges are needed. 432 433 Note: For the case where (a) a single-token context setup is 434 used and (b) the preferred mechanism does not support the 435 integrity facility which would cause a mechListMIC to be 436 generated and enclosed, this feature allows to make a 437 difference between a mechToken sent by the initiator but not 438 processed by the target (accept_incomplete) and a mechToken 439 sent by the initiator and processed by the target 440 (accept_completed). 441 442 For those targets that support piggybacking the initial mechToken, 443 an optimistic negotiation response is possible and includes in that 444 case a responseToken which may continue the authentication exchange 445 (e.g. when mutual authentication has been requested or when 446 unilateral authentication requires several round trips). Otherwise 447 448 449 450Baize & Pinkas Standards Track [Page 8] 451 452RFC 2478 GSS-API Negotiation Mechanism December 1998 453 454 455 the responseToken is used to carry the tokens specific to the 456 mechanism selected. For subsequent tokens (if any) returned by the 457 target, negResult, and supportedMech are not present. 458 459 For the last token returned by the target, the mechListMIC, when 460 present, is a MIC computed over the MechTypes using the selected 461 mechanism. 462 463negResult 464 Result of the negotiation exchange, specified by the target. 465 466 This can be either : 467 468 accept_completed 469 The target accepts the preferred security mechanism, 470 and the context is established for the target or, 471 472 accept_incomplete 473 The target accepts one of the proposed security 474 mechanisms and further exchanges are necessary, or, 475 476 reject 477 The target rejects all the proposed security 478 mechanisms. 479 480supportedMech 481 This field has to be present when negResult is "accept_completed" 482 or "accept_incomplete". It is a choice from the mechanisms offered 483 by the initiator. 484 485responseToken 486 This field may be used either to transmit the response to the 487 mechToken when sent by the initiator and when the first mechanism 488 from the list has been selected by the target or to carry the 489 tokens specific to the selected security mechanism. 490 491mechListMIC 492 If the selected mechanism is capable of integrity protection, this 493 field must be present in the last message of the negotiation, 494 (i.e., when the underlying mechanism returns a non-empty token and 495 a major status of GSS_S_COMPLETE); it contains the result of a 496 GetMIC of the MechTypes field in the initial NegTokenInit. It 497 allows to verify that the list initially sent by the initiator has 498 been received unmodified by the target. 499 500 501 502 503 504 505 506Baize & Pinkas Standards Track [Page 9] 507 508RFC 2478 GSS-API Negotiation Mechanism December 1998 509 510 5113.2.2. Processing of mechListMIC. 512 513 If the mechanism selected by the negotiation does not support 514 integrity, then no mechListMIC is included, otherwise a mechListMIC 515 must be used and validated as indicated below. 516 517 If the mechanism supports integrity and uses an even number of 518 messages, then the target must compute a MIC as described above, and 519 send this in the final NegTokenTarg along with the final mechToken. 520 The initiator when receiving the last token must require that the 521 mechListMIC field be present and valid. In the absence of a valid 522 mechListMIC, the negotiation must fail as if the last context 523 establishment token was invalid. 524 525 In the case that the chosen mechanism supports integrity and uses an 526 odd number of messages, the final mechanism token will be sent from 527 the initiator to the target. In this case, there is a tradeoff 528 between using the optimal number of messages, or using an additional 529 message from the target to the initiator in order to give the 530 initiator assurance that no modification of the initiator's mechanism 531 list occurred. The implementation can choose which tradeoff to make. 532 533 When generating the final NegTokenInit message, the NegTokenInit may 534 optionally include a mechListMIC which is the result of a GetMIC of 535 the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE. 536 The target must check the presence of the MIC computed over the 537 mechList sent in the initial NegTokenInit. Three cases may then be 538 considered: 539 540 1) If the mechListMIC is present and correct, then 541 GSS_S_COMPLETE is returned to the target with no token; the 542 context is established by the target. 543 544 2) If the mechListMIC is present but invalid, then the context 545 establishment must fail. An error major status code is 546 returned to the target. 547 548 3) If the mechListMIC is not included in the final NegTokenInit, 549 then GSS_S_COMPLETE must be returned to the target with a 550 token. This token must be a NegTokenTarg, with a MIC included 551 as described above, and no responseToken. The application will 552 then send this token back to the initiator, which must verify 553 that the mechListMIC field is present and valid. 554 555 556 557 558 559 560 561 562Baize & Pinkas Standards Track [Page 10] 563 564RFC 2478 GSS-API Negotiation Mechanism December 1998 565 566 567 Note: If the MIC was originally sent by the initiator, but 568 thenafter deleted by an attacker, the target will send 569 back a token according to the description above, but the 570 initiator will be unable to process that returned token 571 and the context establishment must then fail. 572 5734. EXAMPLES : SECURITY MECHANISM NEGOTIATION 574 575 Here are some examples of security mechanism negotiation between an 576 initiator (I) and a target (T). 577 5784.1. Initial steps 579 580 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). 581 582 (I) invokes GSS_Init_sec_context() with : 583 584 Input 585 mech_type = OID for negotiation mechanism or NULL, if the 586 negotiation mechanism is the default mechanism. 587 588 Output 589 major_status = GSS_S_CONTINUE_NEEDED 590 output_token = negTokenInit 591 592 The negotiation token (negTokenInit) contains two security mechanisms 593 with : 594 mechType = GSS-MECH1 or 595 mechType = GSS-MECH2 596 597 (I) sends to (T) the negotiation token. 598 5994.2 Successful negotiation steps 600 601 (T) supports GSS-MECH2 602 (T) receives the negotiation token (negTokenInit) from (I) 603 (T) invokes GSS_Accept_sec_context() with : 604 605 Input 606 input_token = negTokenInit 607 608 Output 609 major_status = GSS_S_CONTINUE_NEEDED 610 output_token = negTokenTarg 611 612 The negotiation token (negTokenTarg) contains : 613 negResult = accept (the negotiation result) 614 supportedMech : mechType = GSS-MECH2 615 616 617 618Baize & Pinkas Standards Track [Page 11] 619 620RFC 2478 GSS-API Negotiation Mechanism December 1998 621 622 623 (T) returns the negotiation token (negTokenTarg) to (I) 624 (I) invokes GSS_Init_sec_context() with : 625 626 Input 627 input_token = negTokenTarg 628 629 Output 630 major_status = GSS_S_COMPLETE 631 output_token = initialContextToken (initial context token 632 for GSS-MECH2) 633 mech_type = GSS-MECH2 634 635 The subsequent steps are security mechanism specific, and work as 636 specified in [1]. The output tokens from the security mechanism are 637 encapsulated in a NegTokenTarg message (with the supportedMech field 638 omitted, and the mechListMIC included with the last token). 639 6404.3. Failed negotiation steps 641 642 (T) supports GSS-MECH3. 643 (T) receives the negotiation token (negTokenInit) from (I) 644 (T) invokes GSS_Accept_sec_context() with : 645 646 Input 647 input_token = negTokenInit 648 649 Output 650 major_status = GSS_S_BAD_MECH 651 output_token = negTokenTarg 652 653 The negotiation token (negTokenTarg) contains : 654 655 negResult = reject (the negotiation result) 656 657 (T) returns the negotiation token (negTokenTarg) to (I) 658 (I) invokes GSS_Init_sec_context() with : 659 660 Input 661 input_token = negTokenTarg 662 663 Output 664 major_status = GSS_S_BAD_MECH 665 666 The security context establishment has failed. 667 668 669 670 671 672 673 674Baize & Pinkas Standards Track [Page 12] 675 676RFC 2478 GSS-API Negotiation Mechanism December 1998 677 678 6794.4 Successful Negotiation with preferred mechanism info 680 681 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). 682 683 (I) invokes GSS_Init_sec_context() with : 684 685 Input 686 mech_type = OID for negotiation mechanism or NULL, if the 687 negotiation mechanism is the default mechanism. 688 689 Output 690 major_status = GSS_S_CONTINUE_NEEDED 691 output_token = negTokenInit 692 693 The negotiation token (negTokenInit) contains two security mechanisms 694 with : 695 mechType = GSS-MECH1 or 696 mechType = GSS-MECH2 697 698 mechToken = output_token from GSS_Init_sec_context 699 ( first mechType) as described in [1] 700 701 (I) sends to (T) the negotiation token. 702 703 (T) supports GSS-MECH1. 704 (T) receives the negotiation token (negTokenInit) from (I) 705 (T) invokes GSS_Accept_sec_context() with : 706 707 Input 708 input_token = negTokenInit 709 710 Output 711 major_status = GSS_S_CONTINUE_NEEDED 712 output_token = negTokenTarg 713 714 The negotiation token (negTokenTarg) contains : 715 negResult = accept (the negotiation result) 716 supportedMech : mechType = GSS-MECH1 717 718 mechToken = output_token from 719 GSS_Accept_sec_context(mechToken ) 720 721 (T) returns the negotiation token (negTokenTarg) to (I) 722 (I) invokes GSS_Init_sec_context() with : 723 724 Input 725 input_token = negTokenTarg 726 727 728 729 730Baize & Pinkas Standards Track [Page 13] 731 732RFC 2478 GSS-API Negotiation Mechanism December 1998 733 734 735 Output 736 major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed 737 output_token = ContextToken (initial or subsequent context token 738 for GSS-MECH1) 739 mech_type = GSS-MECH1 740 741 Specific implementations of the protocol can support the optimistic 742 negotiation by completing the security context establishment using the 743 agreed upon mechanism as described in [1]. As described above in 744 section 5.2, the output tokens from the security mechanisms are 745 encapsulated in a NegTokenTarg message (with the negResult and 746 supportedMech fields omitted, and the mechListMIC included with the 747 last token). 748 7495. SECURITY CONSIDERATIONS 750 751 When the mechanism selected by the target from the list supplied by 752 the initiator supports integrity protection, then the negotiation is 753 protected. 754 755 When one of the mechanisms proposed by the initiator does not support 756 integrity protection, then the negotiation is exposed to all threats 757 a non secured service is exposed. In particular, an active attacker 758 can force to use a security mechanism which is not the common 759 preferred one (when multiple security mechanisms are shared between 760 peers) but which is acceptable anyway to the target. 761 762 In any case, the communicating peers may be exposed to the denial of 763 service threat. 764 7656. ACKNOWLEDGMENTS 766 767 Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of 768 Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum 769 Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for 770 reviewing earlier versions of this document and for providing useful 771 inputs. Acknowledgments are also due to Peter Brundrett of Microsoft 772 for his proposal for an optimistic negotiation, and for Bill 773 Sommerfeld of Epilogue Technology for his proposal for protecting the 774 negotiation. 775 776 777 778 779 780 781 782 783 784 785 786Baize & Pinkas Standards Track [Page 14] 787 788RFC 2478 GSS-API Negotiation Mechanism December 1998 789 790 791APPENDIX A 792 793 794 GSS-API NEGOTIATION SUPPORT API 795 796 In order to provide to a GSS-API caller (either the initiator or the 797 target or both) the ability to choose among the set of supported 798 mechanisms a reduced set of mechanisms for negotiation, two 799 additional APIs are defined: 800 801 GSS_Get_neg_mechs() indicates the set of security mechanisms 802 available on the local system to the caller for negotiation. 803 804 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 805 used on the local system by the caller for negotiation. 806 807A.1. GSS_Set_neg_mechs call 808 809 Input: 810 cred_handle CREDENTIAL HANDLE 811 - NULL specifies default credentials 812 mech_set SET OF OBJECT IDENTIFIER 813 814 Outputs: 815 major_status INTEGER, 816 minor_status INTEGER, 817 818 Return major_status codes : 819 GSS_S_COMPLETE indicates that the set of security mechanisms 820 available for negotiation has been set to mech_set. GSS_S_FAILURE 821 indicates that the requested operation could not be performed for 822 reasons unspecified at the GSS-API level. 823 824 Allows callers to specify the set of security mechanisms that may be 825 negotiated with the credential identified by cred_handle. This call 826 is intended for support of specialised callers who need to restrict 827 the set of negotiable security mechanisms from the set of all 828 security mechanisms available to the caller (based on available 829 credentials). Note that if more than one mechanism is specified in 830 mech_set, the order in which those mechanisms are specified implies a 831 relative mechanism preference for the target. 832 833 834 835 836 837 838 839 840 841 842Baize & Pinkas Standards Track [Page 15] 843 844RFC 2478 GSS-API Negotiation Mechanism December 1998 845 846 847A.2. GSS_Get_neg_mechs call 848 849 Input: 850 cred_handle CREDENTIAL HANDLE 851 - NULL specifies default credentials 852 853 Outputs: 854 major_status INTEGER, 855 minor_status INTEGER, 856 mech_set SET OF OBJECT IDENTIFIER 857 858 Return major_status codes : 859 GSS_S_COMPLETE indicates that the set of security mechanisms 860 available for negotiation has been returned in 861 mech_option_set. 862 GSS_S_FAILURE indicates that the requested operation could not 863 be performed for reasons unspecified at the GSS-API level. 864 865 Allows callers to determine the set of security mechanisms available 866 for negotiation with the credential identified by cred_handle. This 867 call is intended for support of specialised callers who need to 868 reduce the set of negotiable security mechanisms from the set of 869 supported security mechanisms available to the caller (based on 870 available credentials). 871 872 Note: The GSS_Indicate_mechs() function indicates the full set of 873 mechanism types available on the local system. Since this call has no 874 input parameter, the returned set is not necessarily available for 875 all credentials. 876 877REFERENCES 878 879 [1] Linn, J., "Generic Security Service Application Program 880 Interface", RFC 2078, January 1997. 881 882 [2] Standard ECMA-206, "Association Context Management including 883 Security Context Management", December 1993. Available on 884 http://www.ecma.ch 885 886 887 888 889 890 891 892 893 894 895 896 897 898Baize & Pinkas Standards Track [Page 16] 899 900RFC 2478 GSS-API Negotiation Mechanism December 1998 901 902 903AUTHORS' ADDRESSES 904 905 Eric Baize 906 Bull - 300 Concord Road 907 Billerica, MA 01821 - USA 908 909 Phone: +1 978 294 61 37 910 Fax: +1 978 294 61 09 911 EMail: Eric.Baize@bull.com 912 913 914 Denis Pinkas 915 Bull 916 Rue Jean-Jaures 917 BP 68 918 78340 Les Clayes-sous-Bois - FRANCE 919 920 Phone: +33 1 30 80 34 87 921 Fax: +33 1 30 80 33 21 922 EMail: Denis.Pinkas@bull.net 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 951 952 953 954Baize & Pinkas Standards Track [Page 17] 955 956RFC 2478 GSS-API Negotiation Mechanism December 1998 957 958 959Full Copyright Statement 960 961 Copyright (C) The Internet Society (1998). All Rights Reserved. 962 963 This document and translations of it may be copied and furnished to 964 others, and derivative works that comment on or otherwise explain it 965 or assist in its implementation may be prepared, copied, published 966 and distributed, in whole or in part, without restriction of any 967 kind, provided that the above copyright notice and this paragraph are 968 included on all such copies and derivative works. However, this 969 document itself may not be modified in any way, such as by removing 970 the copyright notice or references to the Internet Society or other 971 Internet organizations, except as needed for the purpose of 972 developing Internet standards in which case the procedures for 973 copyrights defined in the Internet Standards process must be 974 followed, or as required to translate it into languages other than 975 English. 976 977 The limited permissions granted above are perpetual and will not be 978 revoked by the Internet Society or its successors or assigns. 979 980 This document and the information contained herein is provided on an 981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Baize & Pinkas Standards Track [Page 18] 1011 1012