idnits 2.17.1 draft-ietf-cat-snego-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 278: '... mechTypes [0] MechTypeList OPTIONAL...' RFC 2119 keyword, line 279: '... reqFlags [1] ContextFlags OPTIONAL,...' RFC 2119 keyword, line 280: '... preferredToken [2] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 310: '...t (2) } OPTIONAL...' RFC 2119 keyword, line 311: '... supportedMech [1] MechType OPTIONAL...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 November 1997) is 9650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 307, but not defined == Missing Reference: '3' is mentioned on line 313, but not defined ** Obsolete normative reference: RFC 2078 (ref. '1') (Obsoleted by RFC 2743) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Eric Baize, Denis Pinkas 2 IETF Common Authentication Technology WG Bull 3 18 November 1997 5 The Simple and Protected GSS-API Negotiation Mechanism 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Comments on this document should be sent to "cat-ietf@mit.edu", the 26 IETF Common Authentication Technology WG discussion list. Distribution 27 of this document is unlimited. 29 2. ABSTRACT 31 This draft document specifies a Security Negotiation Mechanism for the 32 Generic Security Service Application Program Interface (GSS-API) which 33 is described in [1]. 35 The GSS-API provides a generic interface which can be layered atop 36 different security mechanisms such that if communicating peers acquire 37 GSS-API credentials for the same security mechanism, then a security 38 7context may be established between them (subject to policy). However, 39 GSS-API doesn't prescribe the method by which GSS-API peers can 40 establish whether they have a common security mechanism. 42 The Simple and Protected GSS-API Negotiation Mechanism defined here 43 is a pseudo-security mechanism, represented by the object identifier 44 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which 45 enables GSS-API peers to determine in-band whether their credentials 46 share common GSS-API security mechanism(s), and if so, to invoke 47 normal security context establishment for a selected common security 48 mechanism. This is most useful for applications that are based on 49 GSS-API implementations which support multiple security mechanisms. 51 This allows to negotiate different security mechanisms, different 52 options within a given security mechanism (such as different 53 cryptographic algorithms due to policy or legislative constraints) 54 or different options from several security mechanisms. 56 Once the common security mechanism is identified, the mechanism may 57 then negotiate mechanism-specific options during its context 58 establishment. This will be inside the mechanism tokens, and 59 invisible to the SPNEGO protocol. 61 The simple and protected GSS-API mechanism negotiation is based on the 62 following negotiation model : the initiator proposes one security 63 mechanism or an ordered list of security mechanisms, the target either 64 accepts the proposed security mechanism, or chooses one from an 65 offered set, or rejects the proposed value(s). The target then informs 66 the initiator of its choice. 68 In its basic form this protocol requires an extra-round trip. Network 69 connection setup is a critical performance characteristic of any 70 network infrastructure and extra round trips over WAN links, packet 71 radio networks, etc. really make a difference. In order to avoid such 72 an extra round trip the initial security token of the preferred 73 mechanism for the initiator may be embedded in the initial token. 74 If the target preferred mechanism matches the initiator's preferred 75 mechanism, no additional round trips are incurred by using the 76 negotiation protocol. 78 The simple and protected GSS-API mechanism negotiation provides a 79 technique to protect the negotiation that must be used when the 80 underlying mechanism selected by the target is capable of integrity 81 protection. 83 When all the mechanisms proposed by the initiator support integrity 84 protection or when the selected mechanism supports integrity 85 protection, then the negotiation mechanism becomes protected since 86 this guarantees that the appropriate mechanism supported by both 87 peers has been selected. 89 The Simple and Protected GSS-API Negotiation Mechanism uses the 90 concepts developed in the GSS-API specification [1]. The negotiation 91 data is encapsulated in context-level tokens. Therefore, callers of 92 the GSS-API do not need to be aware of the existence of the 93 negotiation tokens but only of the new pseudo-security mechanism. 94 A failure in the negotiation phase causes a major status code to be 95 returned: GSS_S_BAD_MECH. 97 3. NEGOTIATION MODEL 99 3.1. Negotiation description 101 The model for security mechanism negotiation reuses a subset of the 102 concepts specified in [2]. 104 Each OID represents one GSS-API mechanism or one variant of it. 106 - When one security mechanism is proposed by the initiator, it 107 represents the only security mechanism supported or 108 selected (when the additional APIs defined in the Annex A 109 are used) by the initiator. 111 - When several security mechanisms are proposed by the initiator, 112 they represent a set of security mechanisms supported or selected 113 (when the additional APIs defined in the Annex A are used) by the 114 initiator. 116 The first negotiation token sent by the initiator contains an ordered 117 list of mechanisms, a set of options (e.g. deleg, replay, conf flags) 118 that should be supported by the selected mechanism and optionally the 119 initial security token for the desired mechanism of the initiator 120 (i.e. the first of the list). 122 The first negotiation token sent by the target contains the result of 123 the negotiation (accept_completed, accept_incomplete or reject) and, 124 in case of accept, the agreed security mechanism. It may also include 125 the response to the initial security token from the initiator, when 126 the first proposed mechanism of the initiator has been selected. When 127 the first mechanism is acceptable to the target,it should respond to 128 the initial security token for the desired mechanism of the initiator 129 when it is present. However, if this is not possible, they can simply 130 ignore it and omit the preferredToken from the reply. Implementations 131 that can piggyback the initial token will be rewarded by faster 132 connection setup. 134 In case of a successful negotiation, the security mechanism represents 135 the value suitable for the target, and picked up from the list offered 136 by the initiator. The policy by which the target chooses a mechanism 137 is an implementation-specific local matter. In the absence of other 138 policy, the target should chose the first mechanism in the list for 139 which valid credentials are available. 141 3.2. Negotiation procedure 143 The negotiation procedure is summarised as follows: 145 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 146 requests (either explicitly, with the negotiation mechanism, or 147 through accepting a default, when the default is the negotiation 148 mechanism) that the Simple and Protected GSS-API Negotiation Mechanism 149 be used; 151 (b) the initiator GSS-API implementation emits a negotiation token 152 containing the set of supported security mechanism for the credentials 153 used for this context establishment, and optionally the initial 154 security token for the preferred mechanism, and indicates 155 GSS_S_CONTINUE_NEEDED status; 157 (c) The GSS-API initiator sends the token to the target application; 158 (d) The GSS-API target deposits the token through invoking 159 GSS_Accept_sec_context. The target GSS-API implementation emits a 160 negotiation token containing which if any of the proposed mechanisms 161 it supports (or has selected). 163 If the preferred mechanism selected by the target matches the preferred 164 mechanism identified by the initiator and the initiator provides a 165 preferredToken, the negotiation token response may contain also the 166 initial security token from that mechanism. 168 If the preferred mechanism is accepted, GSS_Accept_sec_context() 169 indicates GSS_S_COMPLETE when unilateral or mutual authentication has 170 been performed and involves a single token in either direction. 172 If a proposed mechanism other than the preferred mechanism is accepted, 173 or the preferred mechanism is accepted but involves multiple exchanges 174 (e.g. challenge-response authentication), then GSS_Accept_sec_context() 175 indicates GSS_S_CONTINUE_NEEDED status. 177 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 178 indicates GSS_S_BAD_MECH status. The security context initialisation 179 has failed. 181 (e) The GSS-API target returns the token to the initiator application; 183 (f) The GSS-API initiator deposits the token through invoking 184 GSS_Init_sec_context. 186 GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, 187 GSS_S_COMPLETE or GSS_S_BAD_MECH status. 189 The GSS_S_BAD_MECH status is returned when the negotiation token 190 carries a reject result or when the negotiation token carries an 191 accept result and the mechanism selected by the target is not 192 included in the initial list sent by the initiator or the 193 selected mechanism supports a MIC token but the MIC computed over 194 the list of mechanisms sent by the initiator is missing or 195 incorrect. If the negotiation token carries a reject result, the 196 context establishment is impossible. For example, a rejection 197 will occur if the target doesn't support the initiator's proposed 198 mechanism type(s). Upon failure of the 199 mechanism negotiation procedure, the mech_type output parameter 200 value is the negotiation mechanism type. 202 The GSS_S_CONTINUE_NEEDED status is returned when the negotiation 203 token carries an accept result and further tokens must be 204 transferred in order to complete context establishment for the 205 selected mechanism. In that case GSS_Init_sec_context() returns 206 an initial context token as output_token (with the selected 207 mechanism's context token encapsulated within that output_token). 208 The initiator then sends the output_token to the target. The 209 security context initialisation is then continued according to 210 the standard GSS-API conventions for the selected mechanism, 211 where the tokens of the selected mechanism are encapsulated until 212 the GSS_S_COMPLETE is returned for both the initiator and the 213 target. When GSS_S_CONTINUE_NEEDED is returned, the mech_type 214 output parameter is not yet valid. 216 When GSS_S_COMPLETE is returned, the mech_type output parameter 217 indicates the selected mechanism. When the final negotiation token 218 does not contain a MIC, the initiator GSS-API implementation must 219 check the returned/selected mechanism is on the originally 220 submitted list of mechanisms and also verify that the 221 selected mechanism is not able to support a MIC. When the final 222 negotiation token contains a MIC over the initial mechanisms list 223 sent by the initiator, the MIC must be verified. 225 Note that the *_req_flag input parameters for context establishment 226 are relative to the selected mechanism, as are the *_state output 227 parameters. i.e., these parameters are not applicable to the 228 negotiation process per se. 230 The initiator GSS-API calling application may need to know when the 231 negotiation exchanges were protected or not. For this, when 232 GSS_S_COMPLETE is returned, it can simply test the integ_avail flag. 233 When this flag is set it indicates that the negotiation was protected. 235 On receipt of a negotiation token on the target side, a GSS-API 236 implementation that does not support negotiation would indicate the 237 GSS_S_BAD_MECH status as if a particular basic security mechanism had 238 been requested but was not supported. 240 When GSS_Acquire_cred is invoked with the negotiation mechanism as 241 desired_mechs, an implementation-specific default credential is used 242 to carry on the negotiation. A set of mechanisms as specified locally 243 by the system administrator is then available for negotiation. If there 244 is a desire for the caller to make its own choice, then an additional 245 API has to be used (see Appendix A). 247 4. DATA ELEMENTS 249 4.1. Mechanism Type 251 MechType::= OBJECT IDENTIFIER 253 mechType 254 Each security mechanism is as defined in [1]. 256 4.2. Negotiation Tokens 258 The syntax of the negotiation tokens follows the InitialContextToken 259 syntax defined in [1]. The security mechanism of the initial 260 negotiation token is identified by the Object Identifier 261 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 263 4.2.1. Syntax 265 This section specifies the syntax of the corresponding 266 "innerContextToken" field for the first token and subsequent 267 negotiation tokens. 269 NegotiationToken ::= CHOICE { 270 negTokenInit [0] NegTokenInit, 271 negTokenTarg [1] NegTokenTarg } 273 MechType ::= OBJECT IDENTIFIER 275 MechTypeList ::= SEQUENCE OF MechType 277 NegTokenInit ::= SEQUENCE { 278 mechTypes [0] MechTypeList OPTIONAL 279 reqFlags [1] ContextFlags OPTIONAL, 280 preferredToken [2] OCTET STRING OPTIONAL 281 } 283 ContextFlags ::= BIT STRING { 284 delegFlag (0), 285 mutualFlag (1), 286 replayFlag (2), 287 sequenceFlag (3), 288 anonFlag (4), 289 confFlag (5), 290 > integFlag (6) 291 } 293 negTokenInit 294 Negotiation token sent by the initiator to the target, which 295 contains, for the first token sent, one or more security 296 mechanisms supported by the initiator and the service options 297 (reqFlags) that are requested to establish the context. The 298 preferredToken is an optional field of the first token sent that 299 all target implementations would not have to support. However 300 for those targets that do support piggybacking the initial 301 preferredToken, an optimistic negotiation response is possible. 303 The context flags should be filled in from the req_flags parameter 304 of init_sec_context() 306 NegTokenTarg ::= SEQUENCE { 307 negResult [0] ENUMERATED { 308 accept_completed (0), 309 accept_incomplete (1), 310 reject (2) } OPTIONAL 311 supportedMech [1] MechType OPTIONAL 312 responseToken [2] OCTET STRING OPTIONAL 313 mechListMIC [3] OCTET STRING OPTIONAL 314 } 315 negTokenTarg 316 Negotiation token returned by the target to the initiator which 317 contains, for the first token returned, a global negotiation 318 result and the security mechanism selected (if any). 319 The result accept_completed indicates that a context 320 has been successfully established using the preferredToken that 321 was initially sent by the initiator, while the result 322 accept_incomplete indicates that additional token exchanges are 323 needed. 325 Note: For the case where (a) a single-token context setup 326 is used and (b) the preferred mechanism does not support 327 the integrity facility which would cause a mechListMIC to be 328 generated and enclosed, this feature allows to make a 329 difference between a preferredToken sent by the initiator 330 but not processed by the target (accept_incomplete) and 331 a preferredToken sent by the initiator and processed by 332 the target (accept_completed). 334 For those targets that support piggybacking the initial 335 preferredToken, an optimistic negotiation response is possible 336 and includes in that case a responseToken which may continue 337 the authentication exchange (e.g. when mutual authentication has 338 been requested or when unilateral authentication requires several 339 round trips). Otherwise the responseToken is used to carry the 340 tokens specific to the mechanism selected. 342 For subsequent tokens (if any) returned by the target, negResult, 343 and supportedMech are not present. 345 For the last token returned by the target, the mechListMIC, when 346 present, is a MIC computed over the MechTypes using the selected 347 mechanism. 349 negResult 350 Result of the negotiation exchange, specified by the target. 351 This can be either : 352 accept_completed 353 The target accepts the preferred security mechanism, 354 and the context is established for the target or, 355 accept_incomplete 356 The target accepts one of the proposed security 357 mechanisms and further exchanges are necessary, or, 358 reject 359 The target rejects all the proposed security 360 mechanisms. 362 supportedMech 363 This field has to be present when negResult is "accept_completed" 364 or "accept_incomplete". It is a choice from the mechanisms offered 365 by the initiator. 367 responseToken 368 This field may be used either to transmit the response to the 369 preferredToken when sent by the initiator and when the first 370 mechanism from the list has been selected by the target or 371 to carry the tokens specific to the selected security mechanism. 373 mechListMIC 374 If the selected mechanism is capable of integrity protection, 375 this field must be present in the last message of the negotiation, 376 (i.e., when the underlying mechanism returns a non-empty token 377 and a major status of GSS_S_COMPLETE); it contains the result of a 378 GetMIC of the MechTypes field in the initial NegTokenInit. 379 It allows to verify that the list initially sent by the initiator 380 has been received unmodified by the target. 382 4.2.2. Processing of mechListMIC. 384 When the mechanism selected by the negotiation supports integrity 385 protection as a service, the mechListMIC must be used and validated. 387 In particular, the target that sends the last context establishment 388 token must also include the result of a gss_get_mic() of the 389 mechTypeList sent by the initiator in the first token; in addition, 390 the initiator that receives the last token must require that the 391 mechListMIC field be present and valid. In the absence of a valid 392 mechListMIC, the negotiation must fail as if the last context 393 establishment token was invalid. 395 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION 397 Here are some examples of security mechanism negotiation between an 398 initiator (I) and a target (T). 400 5.1. Initial steps 402 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). 404 (I) invokes GSS_Init_sec_context() with : 406 Input 407 mech_type = OID for negotiation mechanism or NULL, if the 408 negotiation mechanism is the default mechanism. 410 Output 411 major_status = GSS_S_CONTINUE_NEEDED 412 output_token = negTokenInit 414 The negotiation token (negTokenInit) contains two security mechanisms 415 with : 416 mechType = GSS-MECH1 or 417 mechType = GSS-MECH2 419 (I) sends to (T) the negotiation token. 421 5.2 Successful negotiation steps 423 (T) supports GSS-MECH2 424 (T) receives the negotiation token (negTokenInit) from (I) 425 (T) invokes GSS_Accept_sec_context() with : 427 Input 428 input_token = negTokenInit 430 Output 431 major_status = GSS_S_CONTINUE_NEEDED 432 output_token = negTokenTarg 434 The negotiation token (negTokenTarg) contains : 435 negResult = accept (the negotiation result) 436 supportedMech : mechType = GSS-MECH2 438 (T) returns the negotiation token (negTokenTarg) to (I) 439 (I) invokes GSS_Init_sec_context() with : 441 Input 442 input_token = negTokenTarg 444 Output 445 major_status = GSS_S_COMPLETE 446 output_token = initialContextToken (initial context token 447 for GSS-MECH2) 448 mech_type = GSS-MECH2 450 The subsequent steps are security mechanism specific, and work as 451 specified in [1]. The output tokens from the security mechanism are 452 encapsulated in a NegTokenTarg message (with the supportedMech field 453 omitted, and the mechListMIC included with the last token). 455 5.3. Failed negotiation steps 457 (T) supports GSS-MECH3. 458 (T) receives the negotiation token (negTokenInit) from (I) 459 (T) invokes GSS_Accept_sec_context() with : 461 Input 462 input_token = negTokenInit 464 Output 465 major_status = GSS_S_BAD_MECH 466 output_token = negTokenTarg 468 The negotiation token (negTokenTarg) contains : 470 negResult = reject (the negotiation result) 472 (T) returns the negotiation token (negTokenTarg) to (I) 473 (I) invokes GSS_Init_sec_context() with : 475 Input 476 input_token = negTokenTarg 478 Output 479 major_status = GSS_S_BAD_MECH 481 The security context establishment has failed. 483 5.4 Successful Negotiation with preferred mechanism info 485 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). 487 (I) invokes GSS_Init_sec_context() with : 489 Input 490 mech_type = OID for negotiation mechanism or NULL, if the 491 negotiation mechanism is the default mechanism. 493 Output 494 major_status = GSS_S_CONTINUE_NEEDED 495 output_token = negTokenInit 497 The negotiation token (negTokenInit) contains two security mechanisms 498 with : 499 mechType = GSS-MECH1 or 500 mechType = GSS-MECH2 502 preferredToken = output_token from GSS_Init_sec_context 503 ( first mechType) as described in [1] 505 (I) sends to (T) the negotiation token. 507 (T) supports GSS-MECH1. 508 (T) receives the negotiation token (negTokenInit) from (I) 509 (T) invokes GSS_Accept_sec_context() with : 511 Input 512 input_token = negTokenInit 514 Output 515 major_status = GSS_S_CONTINUE_NEEDED 516 output_token = negTokenTarg 518 The negotiation token (negTokenTarg) contains : 519 negResult = accept (the negotiation result) 520 supportedMech : mechType = GSS-MECH1 521 preferredToken = output_token from 522 GSS_Accept_sec_context(preferredToken ) 524 (T) returns the negotiation token (negTokenTarg) to (I) 525 (I) invokes GSS_Init_sec_context() with : 527 Input 528 input_token = negTokenTarg 530 Output 531 major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed 532 output_token = ContextToken (initial or subsequent context token 533 for GSS-MECH1) 534 mech_type = GSS-MECH1 536 Specific implementations of the protocol can support the optimistic 537 negotiation by completing the security context establishment using the 538 agreed upon mechanism as described in [1]. As described above in 539 section 5.2, the output tokens from the security mechanisms are 540 encapsulated in a NegTokenTarg message (with the negResult and 541 supportedMech fields omitted, and the mechListMIC included with the 542 last token). 544 6. ACKNOWLEDGMENTS 546 Acknowledgments are due to Piers McMahon and Tom Parker of ICL, 547 Stephen Farrell of SSE, Doug Rosenthal of EINet, John Linn of 548 RSA Laboratories, and Marc Horowitz of Cygnus Solutions for reviewing 549 earlier versions of this document and for providing useful inputs. 550 Acknowledgments are also due to Peter Brundrett of Microsoft for 551 his proposal for an optimistic negotiation, and for Bill Sommerfeld 552 of Hewlett-Packard for his proposal for protecting the negotiation. 554 7. SECURITY CONSIDERATIONS 556 The purpose of the generic simple GSS-API mechanism negotiation 557 mechanism is to enable peers to agree on the value for a security 558 mechanism for initialising security services. 560 When the mechanism selected by the target from the list supplied by 561 the initiator supports integrity protection, then the negotiation is 562 protected. 564 When one of the mechanisms proposed by the initiator does not support 565 integrity protection, then the negotiation is exposed to all threats 566 a non secured service is exposed. In particular, an active attacker 567 can force to use a security mechanism which is not the common 568 preferred one (when multiple security mechanisms are shared between 569 peers) but which is acceptable anyway to the target. 571 In any case, the communicating peers may be exposed to the denial of 572 service threat. 574 APPENDIX A 576 GSS-API NEGOTIATION SUPPORT API 578 In order to provide to a GSS-API caller (either the initiator or the 579 target or both) the ability to choose among the set of supported 580 mechanisms a reduced set of mechanisms for negotiation, two 581 additional APIs are defined: 583 GSS_Get_neg_mechs() indicates the set of security mechanisms available 584 on the local system to the caller for negotiation. 586 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 587 used on the local system by the caller for negotiation. 589 A.1. GSS_Set_neg_mechs call 591 Input: 592 cred_handle CREDENTIAL HANDLE 593 - NULL specifies default credentials 594 mech_set SET OF OBJECT IDENTIFIER 596 Outputs: 597 major_status INTEGER, 598 minor_status INTEGER, 600 Return major_status codes : 601 GSS_S_COMPLETE indicates that the set of security mechanisms 602 available for negotiation has been set to mech_set. 603 GSS_S_FAILURE indicates that the requested operation could not be 604 performed for reasons unspecified at the GSS-API level. 606 Allows callers to specify the set of security mechanisms that 607 may be negotiated with the credential identified by cred_handle. 608 This call is intended for support of specialised callers who need 609 to restrict the set of negotiable security mechanisms from the set 610 of all security mechanisms available to the caller (based on 611 available credentials). Note that if more than one mechanism is 612 specified in mech_set, the order in which those mechanisms are 613 specified implies a relative mechanism preference for the target. 615 A.2. GSS_Get_neg_mechs call 617 Input: 618 cred_handle CREDENTIAL HANDLE 619 - NULL specifies default credentials 621 Outputs: 622 major_status INTEGER, 623 minor_status INTEGER, 624 mech_set SET OF OBJECT IDENTIFIER 626 Return major_status codes : 627 GSS_S_COMPLETE indicates that the set of security mechanisms 628 available for negotiation has been returned in 629 mech_option_set. 630 GSS_S_FAILURE indicates that the requested operation could not 631 be performed for reasons unspecified at the GSS-API level. 633 Allows callers to determine the set of security mechanisms available 634 for negotiation with the credential identified by cred_handle. This 635 call is intended for support of specialised callers who need to 636 reduce the set of negotiable security mechanisms from the set of 637 supported security mechanisms available to the caller (based on 638 available credentials). 640 Note: The GSS_Indicate_mechs() function indicates the full set of 641 mechanism types available on the local system. Since this call has no 642 input parameter, the returned set is not necessarily available for all 643 credentials. 645 REFERENCES 647 [1] Linn, J., "Generic Security Service Application Program 648 Interface", RFC 2078, OpenVision, January 1997. Available on 649 ftp://ds.internic.net/rfc/rfc2078.txt 651 [2] Standard ECMA-206, "Association Context Management including 652 Security Context Management", December 1993. Available on 653 http://www.ecma.ch 655 AUTHORS'S ADDRESSES 657 Eric Baize Internet email: E.Baize@ma02.bull.com 658 Bull HN - MA02/211S Phone: +1 508 294 61 37 659 Technology Park Fax: +1 508 294 61 09 660 Billerica, MA 01821 - USA 662 Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr 663 Bull Phone: +33 1 30 80 34 87 664 Rue Jean-Jaures Fax: +33 1 30 80 33 21 665 BP 68 666 78340 Les Clayes-sous-Bois - FRANCE