idnits 2.17.1 draft-ietf-cat-snego-03.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-25) 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 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. ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** 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 268: '... preferredToken[1] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 294: '... supportedMech [1] MechType OPTIONAL...' RFC 2119 keyword, line 295: '... MechSpecInfo [2] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 296: '... preferredToken [3] OCTET STRING OPTIONAL...' 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 (25 March 1997) is 9893 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 293, but not defined == Missing Reference: '3' is mentioned on line 296, but not defined ** Obsolete normative reference: RFC 1508 (ref. '1') (Obsoleted by RFC 2078) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 15 errors (**), 0 flaws (~~), 3 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 25 March 1997 5 Simple 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 context 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 GSS-API Negotiation Mechanism defined here is a pseudo- 43 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 credential 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 As most existing GSS-API security mechanisms can support different 52 options (such as differing cryptographic algorithms due to policy or 53 legislative constraints), the Simple GSS-API Negotiation Mechanism 54 allows to negotiate security mechanisms including their options 55 (i.e. variants). Mechanism options can be considered as providing a 56 type of "quality of protection" for security contexts. 58 To facilitate mechanism negotiation, the OID which currently defines a 59 security mechanism is "extended" to be able to specify options within a 60 security mechanism rather than simply the basic mechanism. When the OID 61 specifies the mechanism only and no explicit option, then this means 62 that the default option is used. The default option and the specific 63 options for a given mechanism are as defined in the IETF GSS-API 64 specification(s) for the mechanism. 66 This allows to negotiate basic security mechanisms, different options 67 within a given security mechanism or different options from several 68 basic security mechanisms. 70 In addition, a given security mechanism may still negotiate mechanism- 71 specific options during the context establishment for that mechanism, 72 i.e. after the mechanism has been selected by the negotiation process. 74 The simple GSS-API mechanism negotiation is based on a two-ways 75 negotiation model : The initiator proposes one or several security 76 mechanisms, the target either accepts the proposed security mechanism, 77 or chooses one from an offered set, or rejects the proposed value(s). 78 The target informs the initiator of its choice and may also return 79 mechanism specific information related to the chosen mechanism. 81 In its basic form this protocol requires an extra-round trip. Network 82 connection setup is a critical performance characteristic of any network 83 infrastructure and extra round trips over WAN links, packet radio networks, 84 etc. really make a difference. In order to avoid such an extra round trip 85 the initial security token of the preferred mechanism for the initiator may 86 be embedded in the initial token. If the target preferred mechanism matches 87 the initiator's preferred mechanism, no additional round trips are incurred 88 by using the negotiation protocol. 90 The simple GSS-API mechanism negotiation does not provide any security 91 feature to protect the initially exchanged values for security context 92 parameters (i.e. during the negotiation process). This implies that all 93 negotiated mechanisms including their options should be of the same 94 strength. 96 The Simple GSS-API Negotiation Mechanism uses the concepts developed 97 in GSS-API specification [1], and requires the use of a new GSS-API 98 context-level token : the negotiation token. Callers of the GSS-API do 99 not need to be aware of the negotiation token but only of the new 100 pseudo-security mechanism. A failure in the negotiation phase causes a 101 major status code to be returned: GSS_S_BAD_MECH. 103 3. NEGOTIATION MODEL 105 3.1. Negotiation description 107 The model for security mechanism negotiation reuses a subset of the 108 concepts specified in [2]. 110 Each security mechanism represents one basic security mechanism along 111 with one option for this security mechanism (when no option is present 112 the default option is assumed). 114 - When one security mechanism is proposed by the initiator, it 115 represents the only security mechanism option supported or 116 selected (when the additional APIs defined in the Annex A 117 are used) by the initiator. 119 - When several security mechanisms are proposed by the initiator, 120 they represent a set of security mechanisms supported or selected 121 (when the additional APIs defined in the Annex A are used) by the 122 initiator. 124 The initiator negotiation token contains an ordered list of mechanisms 125 and optionally the initial security token for the desired mechanism of 126 the initiator (i.e. the first of the list). 128 The target negotiation reply contains the result of the negotiation 129 (accept or reject) and, in case of accept, the agreed security 130 mechanism along with optional mechanism specific information. It may 131 also include the response to the initial security token, when the first 132 proposed mechanism has been selected. Not all targets must be able to 133 respond to the initial security token for the desired mechanism when 134 it is present. The target can simply ignore it and complete the 135 negotiation handshake without it. Implementations that can piggyback 136 the initial token will be rewarded by faster connection setup. 138 In case of a successful negotiation, the security mechanism represents 139 the value suitable for the target, and picked up from the list offered 140 by the initiator. The target selects the value according to a simple 141 selection criteria: it checks if the first entry from its own list is 142 present in the set offered by the initiator. If the entry is present, 143 then it is the agreed mechanism, if not then the second entry from its 144 own ordered list is checked and the process continues until all 145 entries have been checked. Thus, the target's mechanism preferences 146 have precedence when more than one common mechanism is available 147 between the target and initiator. 149 3.2. Negotiation procedure 151 The negotiation procedure is summarised as follows: 153 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 154 requests (either explicitly, with the negotiation mechanism, or 155 through accepting a default, when the default is the negotiation 156 mechanism) that the Simple GSS-API Negotiation Mechanism be used; 157 b) the initiator GSS-API implementation emits a negotion token 158 containing the set of supported security mechanism for the credentials 159 used for this context establishment, and optionally the initial 160 security token for the preferred mechanism, and indicates 161 GSS_CONTINUE_NEEDED status; 163 (c) The GSS-API initiator sends the token to the target application; 165 (d) The GSS-API target deposits the token through invoking 166 GSS_Accept_sec_context. The target GSS-API implementation emits a 167 negotiation token containing which if any of the proposed mechanisms 168 it supports (or has selected). 170 If the preferred mechanism selected by the target matches the preferred 171 mechanism identified by the initiator and the initiator provides a 172 preferredToken, the negotiation token response may contain also the 173 initial security token from that mechanism. 175 If the preferred mechanism is accepted, GSS_Accept_sec_context() 176 indicates GSS_COMPLETE when unilateral authentication has been 177 performed and involves a single token. 179 If the proposed mechanism(s) are accepted, or the preferred mechanism 180 is accepted but involves multiple exchanges (e.g. mutual 181 authentication), then GSS_Accept_sec_context()indicates 182 GSS_CONTINUE_NEEDED status. 184 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 185 indicates GSS_S_BAD_MECH status. The security context initialisation 186 has failed. 188 (e) The GSS-API target returns the token to the initiator application; 190 (f) The GSS-API initiator deposits the token through invoking 191 GSS_Init_sec_context. 193 If the negotiation token carries an accept result, 194 GSS_Init_sec_context() returns an initial context token as 195 output_token, and indicates GSS_CONTINUE_NEEDED or GSS_COMPLETE 196 status. The initiator sends the output_token to the target. The 197 security context initialisation is then performed according to the 198 standard GSS-API conventions for the selected mechanism. When 199 GSS_COMPLETE is returned, the mech_type output parameter indicates the 200 selected mechanism. Since the negotiation exchanges are not crypto- 201 graphically protected, the initiator GSS-API implementation must check 202 the returned/selected mechanism options with its originally submitted 203 list of mechanism options. When GSS_CONTINUE_NEEDED is returned, the 204 mech_type output parameter is not yet valid. 206 Note that the *_req_flag input parameters for context establishment 207 are relative to the selected mechanism, as are the *_state output 208 parameters. i.e., these parameters are not applicable to the 209 negotiation process per se. 211 If the negotiation token carries a reject result, the context 212 establishment is impossible, and GSS_Init_sec_context() indicates 213 GSS_S_BAD_MECH status. For example, a rejection will occur if 214 the target doesn't support the initiator's proposed mechanism type(s) 215 and/or mechanism option(s). Upon failure of the mechanism negotiation 216 procedure, the mech_type output parameter value is the negotiation 217 mechanism type. However, upon failure of the selected mechanism 218 context establishment, the mech_type output parameter value is the 219 selected mechanism type. 221 On receipt of a negotiation token on the target side, a GSS-API 222 implementation that does not support negotiation would indicate the 223 GSS_FAILURE status as if a particular basic security mechanism had 224 been requested but was not supported. 226 When GSS_Acquire_cred is invoked with the negotiation mechanism as 227 desired_mechs, an implementation-specific default credential is used to 228 carry on the negotiation. A set of mechanisms as specified locally by the 229 system administrator is then available for negotiation. If there is a 230 desire for the caller to make its own choice, then an additional API has to 231 be used (see Appendix A). 233 4. DATA ELEMENTS 235 4.1. Mechanism Type 237 MechType::= OBJECT IDENTIFIER 239 mechType 240 The concept of mechType is extended to specify a basic security 241 mechanism including its options. Each basic security mechanism 242 is as defined in [1], and must provide a single default option 243 which fully specifies the mechanism. The default option is 244 represented by the OID of the mechanism itself (i.e. without any 245 extension). 247 The options are specified by extending the OID. This 248 extension is defined in the same IETF GSS-API specification as 249 the security mechanism context token specification. 251 4.2. Negotiation Token 253 The negotiation token syntax follows InitialContextToken syntax 254 defined in [1]. The negotiation token is identified by the Object 255 Identifier iso.org.dod.internet.security.mechanism.snego 256 (1.3.6.1.5.5.2). This section specifies the syntax of the corresponding 257 "innerContextToken" field. 259 NegotiationToken ::= CHOICE { 260 negTokenReq [0] NegTokenReq, 261 negTokenRep [1] NegTokenRep } 263 MechType ::= OBJECT IDENTIFIER 264 MechTypeList ::= SEQUENCE OF MechType 266 NegTokenReq ::= SEQUENCE { 267 mechTypes[0] MechTypeList, 268 preferredToken[1] OCTET STRING OPTIONAL 269 } 271 negTokenReq 272 Negotiation token sent by the initiator to the target, 273 which contains one or more security mechanisms supported 274 by the initiator. The preferredToken is an optional field in 275 the request that all target implementations would not have 276 to support. However for those targets that do support 277 piggybacking the initial preferredToken, an optimistic 278 negotiation response is possible. 280 negTokenRep 281 Negotiation token returned by the target to the 282 initiator which contains a global negotiation result, 283 the security mechanism selected (if any) and optional 284 information specific to the security mechanism 285 selected by the target. For those targets that support 286 piggybacking the initial preferredToken, an optimistic 287 negotiation response is possible and includes in that case 288 a preferredToken which may continue the authentication exchange 289 (e.g. when mutual authentication has been requested or when 290 unilateral authentication requires several round trips). 292 NegTokenRep ::= SEQUENCE { 293 negResult [0] ENUMERATED { accept (0), reject (1) } 294 supportedMech [1] MechType OPTIONAL 295 MechSpecInfo [2] OCTET STRING OPTIONAL 296 preferredToken [3] OCTET STRING OPTIONAL 297 } 299 negResult 300 Result of the negotiation exchange, specified by the target. 301 This can be either : 302 accept 303 The target accepts one of the proposed 304 security mechanisms, or, 305 reject 306 The target rejects all the proposed security 307 mechanisms. 309 supportedMech 310 This field has to be present when negResult is "accept". 311 It is a choice from the mechanisms offered by the initiator. 313 MechSpecInfo 314 This field may be used to transmit mechanism specific 315 information relative to the security mechanism selected 316 by the target. 318 preferredToken 319 This field may be used to transmit the response to the 320 preferedToken when sent by the initiator and when the first 321 mechanism from the list has been selected by the target. 323 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION 325 Follow some examples of security mechanism options negotiation between 326 an initiator (I) and a target (T). 328 5.1. Initial steps 330 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 331 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 332 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 334 (I) invokes GSS_Init_sec_context() with : 336 Input 337 mech_type = OID for negotiation mechanism or NULL, if the 338 negotiation mechanism is the default mechanism. 340 Output 341 major_status = GSS_CONTINUE_NEEDED 342 output_token = negTokenReq 344 The negotiation token (negTokenReq) contains three security mechanisms 345 with : 346 mechType = GSS-MECH1 or 347 mechType = GSS-MECH2-OPTION1 or 348 mechType = GSS-MECH2-OPTION2 350 (I) sends to (T) the negotiation token. 352 5.2 Successful negotiation steps 354 (T) supports GSS-MECH2-OPTION1. 355 (T) receives the negotiation token (negTokenReq) from (I) 356 (T) invokes GSS_Accept_sec_context() with : 358 Input 359 input_token = negTokenReq 361 Output 362 major_status = GSS_CONTINUE_NEEDED 363 output_token = negTokenRep 365 The negotiation token (negTokenRep) contains : 366 negResult = accept (the negotiation result) 367 supportedMech : mechType = GSS-MECH2-OPTION1 369 (T) returns the negotiation token (negTokenRep) to (I) 370 (I) invokes GSS_Init_sec_context() with : 372 Input 373 input_token = negTokenRep 375 Output 376 major_status = GSS_COMPLETE 377 output_token = initialContextToken (initial context token 378 for GSS-MECH2-OPTION1) 379 mech_type = GSS-MECH2-OPTION1 381 The subsequent steps are security mechanism specific, and works as 382 specified in [1]. 384 5.3. Failed negotiation steps 386 (T) supports GSS-MECH3. 387 (T) receives the negotiation token (negTokenReq) from (I) 388 (T) invokes GSS_Accept_sec_context() with : 390 Input 391 input_token = negTokenReq 393 Output 394 major_status = GSS_S_BAD_MECH 395 output_token = negTokenRep 397 The negotiation token (negTokenRep) contains : 399 negResult = reject (the negotiation result) 401 (T) returns the negotiation token (negTokenRep) to (I) 402 (I) invokes GSS_Init_sec_context() with : 404 Input 405 input_token = negTokenRep 407 Output 408 major_status = GSS_S_BAD_MECH 410 The security context establishment has failed. 412 5.4 Successful Negotiation with preferred mechanism info 414 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 415 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 416 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 418 (I) invokes GSS_Init_sec_context() with : 420 Input 421 mech_type = OID for negotiation mechanism or NULL, if the 422 negotiation mechanism is the default mechanism. 424 Output 425 major_status = GSS_CONTINUE_NEEDED 426 output_token = negTokenReq 428 The negotiation token (negTokenReq) contains three security mechanisms 429 with : 430 mechType = GSS-MECH1 or 431 mechType = GSS-MECH2-OPTION1 or 432 mechType = GSS-MECH2-OPTION2 434 preferredToken = output_token from GSS_Init_sec_context 435 ( first mechType) as described in [1] 437 (I) sends to (T) the negotiation token. 439 (T) supports GSS-MECH1. 440 (T) receives the negotiation token (negTokenReq) from (I) 441 (T) invokes GSS_Accept_sec_context() with : 443 Input 444 input_token = negTokenReq 446 Output 447 major_status = GSS_CONTINUE_NEEDED 448 output_token = negTokenRep 450 The negotiation token (negTokenRep) contains : 451 negResult = accept (the negotiation result) 452 supportedMech : mechType = GSS-MECH1 453 MechSpecInfo = mechanism specific information for 454 the preferred mechanism 455 preferredToken = output_token from 456 GSS_Accept_sec_context(preferredToken ) 458 (T) returns the negotiation token (negTokenRep) to (I) 459 (I) invokes GSS_Init_sec_context() with : 461 Input 462 input_token = negTokenRep 464 Output 465 major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed 466 output_token = ContextToken (initial or subsequent context token 467 for GSS-MECH1) 468 mech_type = GSS-MECH1 470 Specific implementations of the protocol can support the optimistic 471 negotiation by completing the security context establishment using the 472 agreed upon mechanism as described in [1] 473 6. ACKNOWLEDGEMENTS 475 Acknowledgement are due to Piers McMahon and Tom Parker of ICL, 476 Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of 477 Openvision for reviewing earlier versions of this document and for 478 providing useful inputs. A special acknowledgment for Peter Brundrett 479 of Microsoft for his proposal for an optimistic negotiation. 481 7. SECURITY CONSIDERATIONS 483 The purpose of the generic simple GSS-API mechanism negotiation 484 mechanism is to enable peers to agree on the value for a security 485 mechanism and security related options required for initialising 486 security services. 488 As this mechanism is called prior to any initialisation of a security 489 service, it cannot make use of any security feature. Therefore it is 490 exposed to all threats a non secured service is exposed. 492 Communicating peers may be exposed to the denial of service threat, or 493 can be forced by an active attacker to use a security mechanism which 494 is not their common preferred one (when multiple security mechanisms 495 are shared between peers) but which is acceptable anyway to the 496 target. This implies that all negotiated mechanisms including their 497 options should be of the same strength. 499 APPENDIX A 501 GSS-API NEGOTIATION SUPPORT API 503 In order to provide to a GSS-API caller (either the initiator or the 504 target or both) the ability to choose among the set of supported 505 mechanisms a reduced set of mechanisms for negotiation, two 506 additionnal APIs are defined: 508 GSS_Get_neg_mechs() indicates the set of security mechanisms available 509 on the local system to the caller for negotiation. 511 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 512 used on the local system by the caller for negotiation. 514 A.1. GSS_Get_neg_mechs call 516 Input: 517 cred_handle OCTET STRING - NULL specifies default credentials 519 Outputs: 520 major_status INTEGER, 521 minor_status INTEGER, 522 mech_option_set SET OF OBJECT IDENTIFIER 524 Return major_status codes : 525 GSS_COMPLETE indicates that the set of security mechanism 526 options available for negotiation has been returned in 527 mech_option_set. 528 GSS_FAILURE indicates that the requested operation could not 529 be performed for reasons unspecified at the GSS-API level. 531 Allows callers to determine the set of security mechanism options 532 available for negotiation. This call is intended for support of 533 specialised callers who need to reduce the set of negotiable security 534 mechanism options from the set of supported security mechanisms 535 available to the caller (based on available credentials). 537 Note: The GSS_Indicate_mechs() function indicates the full set of mechanism 538 types available on the local system. Since this call does not use a 539 credential handle as an input parameter, the returned set is not 540 necessarily available for all credentials. 542 A.2. GSS_Set_neg_mechs call 544 Input: 545 cred_handle OCTET STRING - NULL specifies default credentials 546 mech_option_set SET OF OBJECT IDENTIFIER 548 Outputs: 549 major_status INTEGER, 550 minor_status INTEGER, 552 Return major_status codes : 553 GSS_COMPLETE indicates that the set of security mechanisms 554 available for negotiation has been set to mech_option_set. 555 GSS_FAILURE indicates that the requested operation could not be 556 performed for reasons unspecified at the GSS-API level. 558 Allows callers to specify the set of security mechanism options that 559 may be negotiated: A NULL mech_option_set specifies that only the 560 default mech_type with the default option is available for the GSS-API 561 implementation. This call is intended for support of specialised 562 callers who need to restrict the set of negotiable security mechanism 563 options from the set of all security mechanism options available to 564 the caller (based on available credentials). Note that if more than 565 one mechanism is specified in mech_option_set, the order in which those 566 mechanisms are specified implies a relative mechanism preference for 567 the target. 569 REFERENCES 571 [1] Linn, J., "Generic Security Service Application Program 572 Interface", RFC 1508, OpenVision, September 1993. 574 [2] Standard ECMA-206, "Association Context Management including 575 Security Context Management", December 1993. Available on 576 http://www.ecma.ch 578 AUTHORS'S ADDRESSES 580 Eric Baize Internet email: E.Baize@ma02.bull.com 581 Bull HN - MA02/211S Phone: +1 508 294 61 37 582 Technology Park Fax: +1 508 294 61 09 583 Billerica, MA 01821 - USA 585 Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr 586 Bull Phone: +33 1 30 80 34 87 587 Rue Jean-Jaures Fax: +33 1 30 80 33 21 588 BP 68 589 78340 Les Clayes-sous-Bois - FRANCE