idnits 2.17.1 draft-ietf-cat-snego-04.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-24) 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 1 longer page, the longest (page 6) being 60 lines 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 5 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 302: '... mechTypes [0] MechTypeList OPTIONAL...' RFC 2119 keyword, line 303: '... preferredToken [1] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 316: '... negResult [0] ENUMERATED { accept (0), reject (1) } OPTIONAL...' RFC 2119 keyword, line 317: '... supportedMech [1] MechType OPTIONAL...' RFC 2119 keyword, line 318: '... MechSpecInfo [2] OCTET STRING 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 (22 April 1997) is 9864 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 316, but not defined == Missing Reference: '3' is mentioned on line 319, but not defined == Missing Reference: '4' is mentioned on line 320, but not defined ** Obsolete normative reference: RFC 2078 (ref. '1') (Obsoleted by RFC 2743) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Eric Baize, Denis Pinkas 3 IETF Common Authentication Technology WG Bull 4 22 April 1997 6 The Simple and Protected GSS-API Negotiation Mechanism 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Comments on this document should be sent to "cat-ietf@mit.edu", the 27 IETF Common Authentication Technology WG discussion list. Distribution 28 of this document is unlimited. 30 2. ABSTRACT 32 This draft document specifies a Security Negotiation Mechanism for the 33 Generic Security Service Application Program Interface (GSS-API) which 34 is described in [1]. 36 The GSS-API provides a generic interface which can be layered atop 37 different security mechanisms such that if communicating peers acquire 38 GSS-API credentials for the same security mechanism, then a security 39 context may be established between them (subject to policy). However, 40 GSS-API doesn't prescribe the method by which GSS-API peers can 41 establish whether they have a common security mechanism. 43 The Simple and Protected GSS-API Negotiation Mechanism defined here 44 is a pseudo-security mechanism, represented by the object identifier 45 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which 46 enables GSS-API peers to determine in-band whether their credentials 47 share common GSS-API security mechanism(s), and if so, to invoke 48 normal security context establishment for a selected common security 49 mechanism. This is most useful for applications that are based on 50 GSS-API implementations which support multiple security mechanisms. 52 As most existing GSS-API security mechanisms can support different 53 options (such as differing cryptographic algorithms due to policy or 54 legislative constraints), the Simple and Protected GSS-API Negotiation 55 Mechanism allows to negotiate security mechanisms including their 56 options (i.e. variants). Mechanism options can be considered as 57 providing a type of "quality of protection" for security contexts. 59 To facilitate mechanism negotiation, the OID which currently defines a 60 security mechanism is "extended" to be able to specify options within a 61 security mechanism rather than simply the basic mechanism. When the OID 62 specifies the mechanism only and no explicit option, then this means 63 that the default option is used. The default option and the specific 64 options for a given mechanism are as defined in the IETF GSS-API 65 specification(s) for the mechanism. 67 This allows to negotiate basic security mechanisms, different options 68 within a given security mechanism or different options from several 69 basic security mechanisms. 71 In addition, a given security mechanism may still negotiate mechanism- 72 specific options during the context establishment for that mechanism, 73 i.e. after the mechanism has been selected by the negotiation process. 75 The simple and protected GSS-API mechanism negotiation is based on the 76 following negotiation model : the initiator proposes one or several 77 security mechanisms, the target either accepts the proposed security 78 mechanism, or chooses one from an offered set, or rejects the proposed 79 value(s). The target informs the initiator of its choice and may also 80 return mechanism specific information related to the chosen mechanism. 82 In its basic form this protocol requires an extra-round trip. Network 83 connection setup is a critical performance characteristic of any 84 network infrastructure and extra round trips over WAN links, packet 85 radio networks, etc. really make a difference. In order to avoid such 86 an extra round trip the initial security token of the preferred 87 mechanism for the initiator may be embedded in the initial token. 88 If the target preferred mechanism matches the initiator's preferred 89 mechanism, no additional round trips are incurred by using the 90 negotiation protocol. 92 The simple and protected GSS-API mechanism negotiation provides a 93 technique to protect the negotiation that must be used when the 94 underlying mechanism selected by the target is capable of integrity 95 protection. 97 When all the mechanisms proposed by the initiator support integrity 98 protection or when the selected mechanism supports integrity 99 protection, then the negotiation mechanism becomes protected since 100 this guarantees that the appropriate mechanism supported by both 101 peers has been selected. 103 The Simple and Protected GSS-API Negotiation Mechanism uses the 104 concepts developed in GSS-API specification [1], and requires the use 105 of new GSS-API context-level tokens : negotiation tokens. Callers 106 of the GSS-API do not need to be aware of the existence of the 107 negotiation tokens but only of the new pseudo-security mechanism. 108 A failure in the negotiation phase causes a major status code to be 109 returned: GSS_S_BAD_MECH. 111 3. NEGOTIATION MODEL 113 3.1. Negotiation description 115 The model for security mechanism negotiation reuses a subset of the 116 concepts specified in [2]. 118 Each security mechanism represents one basic security mechanism along 119 with one option for this security mechanism (when no option is present 120 the default option is assumed). 122 - When one security mechanism is proposed by the initiator, it 123 represents the only security mechanism option supported or 124 selected (when the additional APIs defined in the Annex A 125 are used) by the initiator. 127 - When several security mechanisms are proposed by the initiator, 128 they represent a set of security mechanisms supported or selected 129 (when the additional APIs defined in the Annex A are used) by the 130 initiator. 132 The first negotiation token sent by the initiator contains an ordered 133 list of mechanisms and optionally the initial security token for the 134 desired mechanism of the initiator (i.e. the first of the list). 136 The first negotiation token sent by the target contains the result of 137 the negotiation (accept or reject) and, in case of accept, the agreed 138 security mechanism along with optional mechanism specific information. 139 It may also include the response to the initial security token for the 140 desired mechanism of the initiator, when the first proposed mechanism 141 has been selected. Not all targets must be able to respond to the 142 initial security token for the desired mechanism when it is present. 143 The target can simply ignore it and complete the negotiation without 144 it. Implementations that can piggyback the initial token will be 145 rewarded by faster connection setup. 147 In case of a successful negotiation, the security mechanism represents 148 the value suitable for the target, and picked up from the list offered 149 by the initiator. The target selects the value according to a simple 150 selection criteria: it checks if the first entry from its own list is 151 present in the set offered by the initiator. If the entry is present, 152 then it is the agreed mechanism, if not then the second entry from its 153 own ordered list is checked and the process continues until all 154 entries have been checked. Thus, the target's mechanism preferences 155 have precedence when more than one common mechanism is available 156 between the target and initiator. 158 3.2. Negotiation procedure 160 The negotiation procedure is summarised as follows: 162 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 163 requests (either explicitly, with the negotiation mechanism, or 164 through accepting a default, when the default is the negotiation 165 mechanism) that the Simple and Protected GSS-API Negotiation Mechanism 166 be used; 168 b) the initiator GSS-API implementation emits a negotiation token 169 containing the set of supported security mechanism for the credentials 170 used for this context establishment, and optionally the initial 171 security token for the preferred mechanism, and indicates 172 GSS_CONTINUE_NEEDED status; 174 (c) The GSS-API initiator sends the token to the target application; 176 (d) The GSS-API target deposits the token through invoking 177 GSS_Accept_sec_context. The target GSS-API implementation emits a 178 negotiation token containing which if any of the proposed mechanisms 179 it supports (or has selected). 181 If the preferred mechanism selected by the target matches the preferred 182 mechanism identified by the initiator and the initiator provides a 183 preferredToken, the negotiation token response may contain also the 184 initial security token from that mechanism. 186 If the preferred mechanism is accepted, GSS_Accept_sec_context() 187 indicates GSS_COMPLETE when unilateral or mutual authentication has 188 been performed and involves a single token in either direction. 190 If the proposed mechanism(s) are accepted, or the preferred mechanism 191 is accepted but involves multiple exchanges (e.g. challenge-response 192 authentication), then GSS_Accept_sec_context()indicates 193 GSS_CONTINUE_NEEDED status. 195 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 196 indicates GSS_S_BAD_MECH status. The security context initialisation 197 has failed. 199 (e) The GSS-API target returns the token to the initiator application; 201 (f) The GSS-API initiator deposits the token through invoking 202 GSS_Init_sec_context. 204 GSS_Init_sec_context() may then indicate GSS_CONTINUE_NEEDED, 205 GSS_COMPLETE or GSS_S_BAD_MECH status. 207 The GSS_S_BAD_MECH status is returned when the negotiation token 208 carries a reject result or when the negotiation token carries an 209 accept result and the mechanism selected by the target is not 210 included in the initial list sent by the initiator or the 211 selected mechanism supports a MIC token but the MIC computed over 212 the list of mechanisms sent by the initiator is missing or 213 incorrect. If the negotiation token carries a reject result, the 214 context establishment is impossible. For example, a rejection 215 will occur if the target doesn't support the initiator's proposed 216 mechanism type(s) and/or mechanism option(s). Upon failure of the 217 mechanism negotiation procedure, the mech_type output parameter 218 value is the negotiation mechanism type. 220 The GSS_CONTINUE_NEEDED status is returned when the negotiation 221 token carries an accept result. In that case 222 GSS_Init_sec_context() returns an initial context token as 223 output_token. The initiator then sends the output_token to the 224 target. The security context initialisation is then continued 225 according to the standard GSS-API conventions for the selected 226 mechanism, where the tokens of the selected mechanism are 227 encapsulated until the GSS_COMPLETE is returned for both the 228 initiator and the target. When GSS_CONTINUE_NEEDED is returned, 229 the mech_type output parameter is not yet valid. 231 When GSS_COMPLETE is returned, the mech_type output parameter 232 indicates the selected mechanism. When the final negotiation token 233 does not contain a MIC, the initiator GSS-API implementation must 234 check the returned/selected mechanism options with its originally 235 submitted list of mechanism options and also verify that the 236 selected mechanism is not able to support a MIC. When the final 237 negotiation token contains a MIC over the initial mechanisms list 238 sent by the initiator, the MIC must be verified. 240 Note that the *_req_flag input parameters for context establishment 241 are relative to the selected mechanism, as are the *_state output 242 parameters. i.e., these parameters are not applicable to the 243 negotiation process per se. 245 The initiator GSS-API calling application may know when the 246 negotiation exchanges were protected or not. For this, when 247 GSS_COMPLETE is returned, it can simply test the integ_avail flag. 248 When this flag is set it indicates that the negotiation was protected. 250 On receipt of a negotiation token on the target side, a GSS-API 251 implementation that does not support negotiation would indicate the 252 GSS_FAILURE status as if a particular basic security mechanism had 253 been requested but was not supported. 255 When GSS_Acquire_cred is invoked with the negotiation mechanism as 256 desired_mechs, an implementation-specific default credential is used to 257 carry on the negotiation. A set of mechanisms as specified locally by the 258 system administrator is then available for negotiation. If there is a 259 desire for the caller to make its own choice, then an additional API has to 260 be used (see Appendix A). 262 4. DATA ELEMENTS 264 4.1. Mechanism Type 266 MechType::= OBJECT IDENTIFIER 268 mechType 269 The concept of mechType is extended to specify a basic security 270 mechanism including its options. Each basic security mechanism 271 is as defined in [1], and must provide a single default option 272 which fully specifies the mechanism. The default option is 273 represented by the OID of the mechanism itself (i.e. without any 274 extension). 276 The options are specified by extending the OID. This 277 extension is defined in the same IETF GSS-API specification as 278 the security mechanism context token specification. 280 4.2. Negotiation Tokens 282 The syntax of the negotiation tokens follows the InitialContextToken 283 syntax defined in [1]. The security mechanism of the initial 284 negotiation token is identified by the Object Identifier 285 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 287 4.2.1. Syntax 289 This section specifies the syntax of the corresponding 290 "innerContextToken" field for the first token and subsequent 291 negotiation tokens. 293 NegotiationToken ::= CHOICE { 294 negTokenInit [0] NegTokenInit, 295 negTokenTarg [1] NegTokenTarg } 297 MechType ::= OBJECT IDENTIFIER 299 MechTypeList ::= SEQUENCE OF MechType 301 NegTokenInit ::= SEQUENCE { 302 mechTypes [0] MechTypeList OPTIONAL 303 preferredToken [1] OCTET STRING OPTIONAL 304 } 306 negTokenInit 307 Negotiation token sent by the initiator to the target, which 308 contains, for the first token sent, one or more security 309 mechanisms supported by the initiator. The preferredToken is an 310 optional field of the first token sent that all target 311 implementations would not have to support. However for those 312 targets that do support piggybacking the initial preferredToken, 313 an optimistic negotiation response is possible. 315 NegTokenTarg ::= SEQUENCE { 316 negResult [0] ENUMERATED { accept (0), reject (1) } OPTIONAL 317 supportedMech [1] MechType OPTIONAL 318 MechSpecInfo [2] OCTET STRING OPTIONAL 319 preferredToken [3] OCTET STRING OPTIONAL 320 mechListMIC [4] OCTET STRING OPTIONAL 321 } 323 negTokenTarg 324 Negotiation token returned by the target to the initiator which 325 contains, for the first token returned, a global negotiation 326 result, the security mechanism selected (if any) and optional 327 information specific to the security mechanism selected by the 328 target. For those targets that support piggybacking the initial 329 preferredToken, an optimistic negotiation response is possible 330 and includes in that case a preferredToken which may continue 331 the authentication exchange (e.g. when mutual authentication has 332 been requested or when unilateral authentication requires several 333 round trips). Otherwise the preferredToken is used to carry the 334 tokens specific to the mechanism selected. For the last token 335 returned by the target, the mechListMIC is a MIC computed over 336 the MechTypes using the selected mechanism. 338 negResult 339 Result of the negotiation exchange, specified by the target. 340 This can be either : 341 accept 342 The target accepts one of the proposed 343 security mechanisms, or, 344 reject 345 The target rejects all the proposed security 346 mechanisms. 348 supportedMech 349 This field has to be present when negResult is "accept". 350 It is a choice from the mechanisms offered by the initiator. 352 MechSpecInfo 353 This field may be used to transmit mechanism specific 354 information relative to the security mechanism selected 355 by the target. 357 preferredToken 358 This field may be used either to transmit the response to the 359 preferredToken when sent by the initiator and when the first 360 mechanism from the list has been selected by the target or 361 to carry the tokens specific to the selected security mechanism. 363 mechListMIC 364 If the selected mechanism is capable of integrity protection, 365 this field must be present in the last message of the negotiation, 366 (i.e., when the underlying mechanism returns a non-empty token 367 and a major status of GSS_COMPLETE); it contains the result of a 368 GetMIC of the MechTypes field in the initial NegTokenInit. 370 4.2.2. Processing of mechListMIC. 372 When the mechanism selected by the negotiation supports integrity 373 protection as a service, the mechListMIC must be used and validated. 375 In particular, the target that sends the last context establishment 376 token must also include the result of a gss_get_mic() of the 377 mechTypeList sent by the initiator in the first token; in addition, 378 the initiator that receives the last token must require that the 379 mechListMIC field be present and valid. In the absence of a valid 380 mechListMIC, the negotiation must fail as if the last context 381 establishment token was invalid. 383 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION 385 Follow some examples of security mechanism options negotiation between 386 an initiator (I) and a target (T). 388 5.1. Initial steps 390 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 391 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 392 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 394 (I) invokes GSS_Init_sec_context() with : 396 Input 397 mech_type = OID for negotiation mechanism or NULL, if the 398 negotiation mechanism is the default mechanism. 400 Output 401 major_status = GSS_CONTINUE_NEEDED 402 output_token = negTokenInit 404 The negotiation token (negTokenInit) contains three security mechanisms 405 with : 406 mechType = GSS-MECH1 or 407 mechType = GSS-MECH2-OPTION1 or 408 mechType = GSS-MECH2-OPTION2 410 (I) sends to (T) the negotiation token. 412 5.2 Successful negotiation steps 414 (T) supports GSS-MECH2-OPTION1. 415 (T) receives the negotiation token (negTokenInit) from (I) 416 (T) invokes GSS_Accept_sec_context() with : 418 Input 419 input_token = negTokenInit 421 Output 422 major_status = GSS_CONTINUE_NEEDED 423 output_token = negTokenTarg 425 The negotiation token (negTokenTarg) contains : 426 negResult = accept (the negotiation result) 427 supportedMech : mechType = GSS-MECH2-OPTION1 429 (T) returns the negotiation token (negTokenTarg) to (I) 430 (I) invokes GSS_Init_sec_context() with : 432 Input 433 input_token = negTokenTarg 435 Output 436 major_status = GSS_COMPLETE 437 output_token = initialContextToken (initial context token 438 for GSS-MECH2-OPTION1) 439 mech_type = GSS-MECH2-OPTION1 441 The subsequent steps are security mechanism specific, and work as 442 specified in [1]. The output tokens from the security mechanism are 443 encapsulated in a NegTokenTarg message (with the supportedMech and 444 MechSpecInfo fields omitted, and the mechListMIC included with the 445 last token). 447 5.3. Failed negotiation steps 449 (T) supports GSS-MECH3. 450 (T) receives the negotiation token (negTokenInit) from (I) 451 (T) invokes GSS_Accept_sec_context() with : 453 Input 454 input_token = negTokenInit 456 Output 457 major_status = GSS_S_BAD_MECH 458 output_token = negTokenTarg 460 The negotiation token (negTokenTarg) contains : 462 negResult = reject (the negotiation result) 464 (T) returns the negotiation token (negTokenTarg) to (I) 465 (I) invokes GSS_Init_sec_context() with : 467 Input 468 input_token = negTokenTarg 470 Output 471 major_status = GSS_S_BAD_MECH 473 The security context establishment has failed. 475 5.4 Successful Negotiation with preferred mechanism info 477 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 478 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 479 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 481 (I) invokes GSS_Init_sec_context() with : 483 Input 484 mech_type = OID for negotiation mechanism or NULL, if the 485 negotiation mechanism is the default mechanism. 487 Output 488 major_status = GSS_CONTINUE_NEEDED 489 output_token = negTokenInit 491 The negotiation token (negTokenInit) contains three security mechanisms 492 with : 493 mechType = GSS-MECH1 or 494 mechType = GSS-MECH2-OPTION1 or 495 mechType = GSS-MECH2-OPTION2 497 preferredToken = output_token from GSS_Init_sec_context 498 ( first mechType) as described in [1] 500 (I) sends to (T) the negotiation token. 502 (T) supports GSS-MECH1. 503 (T) receives the negotiation token (negTokenInit) from (I) 504 (T) invokes GSS_Accept_sec_context() with : 506 Input 507 input_token = negTokenInit 509 Output 510 major_status = GSS_CONTINUE_NEEDED 511 output_token = negTokenTarg 513 The negotiation token (negTokenTarg) contains : 514 negResult = accept (the negotiation result) 515 supportedMech : mechType = GSS-MECH1 516 MechSpecInfo = mechanism specific information for 517 the preferred mechanism 518 preferredToken = output_token from 519 GSS_Accept_sec_context(preferredToken ) 521 (T) returns the negotiation token (negTokenTarg) to (I) 522 (I) invokes GSS_Init_sec_context() with : 524 Input 525 input_token = negTokenTarg 527 Output 528 major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed 529 output_token = ContextToken (initial or subsequent context token 530 for GSS-MECH1) 531 mech_type = GSS-MECH1 533 Specific implementations of the protocol can support the optimistic 534 negotiation by completing the security context establishment using the 535 agreed upon mechanism as described in [1]. As described above in 536 section 5.2, the output tokens from the security mechanism are 537 encapsulated in a NegTokenTarg message (with the negResult, 538 supportedMech and MechSpecInfo fields omitted, and the mechListMIC 539 included with the last token). 541 6. ACKNOWLEDGMENTS 543 Acknowledgments are due to Piers McMahon and Tom Parker of ICL, 544 Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of 545 Openvision for reviewing earlier versions of this document and for 546 providing useful inputs. Acknowledgments are also due to Peter Brundrett 547 of Microsoft for his proposal for an optimistic negotiation, and for 548 Bill Sommerfeld of Hewlett-Packard for his proposal for protecting 549 the negotiation. 551 7. SECURITY CONSIDERATIONS 553 The purpose of the generic simple GSS-API mechanism negotiation 554 mechanism is to enable peers to agree on the value for a security 555 mechanism and security related options required for initialising 556 security services. 558 When the mechanism selected by the target from the list supplied by 559 the initiator supports integrity protection, then the negotiation is 560 protected. 562 When one of the mechanisms proposed by the initiator does not support 563 integrity protection, then the negotiation is exposed to all threats a non 564 secured service is exposed. In particular, an active attacker can force to 565 use a security mechanism which is not the common preferred one (when 566 multiple security mechanisms are shared between peers) but which is 567 acceptable anyway to the target. 569 In any case, the communicating peers may be exposed to the denial of 570 service threat. 572 APPENDIX A 574 GSS-API NEGOTIATION SUPPORT API 576 In order to provide to a GSS-API caller (either the initiator or the 577 target or both) the ability to choose among the set of supported 578 mechanisms a reduced set of mechanisms for negotiation, two 579 additional APIs are defined: 581 GSS_Get_neg_mechs() indicates the set of security mechanisms available 582 on the local system to the caller for negotiation. 584 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 585 used on the local system by the caller for negotiation. 587 A.1. GSS_Get_neg_mechs call 589 Input: 590 cred_handle OCTET STRING - NULL specifies default credentials 592 Outputs: 593 major_status INTEGER, 594 minor_status INTEGER, 595 mech_option_set SET OF OBJECT IDENTIFIER 597 Return major_status codes : 598 GSS_COMPLETE indicates that the set of security mechanism 599 options available for negotiation has been returned in 600 mech_option_set. 601 GSS_FAILURE indicates that the requested operation could not 602 be performed for reasons unspecified at the GSS-API level. 604 Allows callers to determine the set of security mechanism options 605 available for negotiation. This call is intended for support of 606 specialised callers who need to reduce the set of negotiable security 607 mechanism options from the set of supported security mechanisms 608 available to the caller (based on available credentials). 610 Note: The GSS_Indicate_mechs() function indicates the full set of mechanism 611 types available on the local system. Since this call does not use a 612 credential handle as an input parameter, the returned set is not 613 necessarily available for all credentials. 615 A.2. GSS_Set_neg_mechs call 617 Input: 618 cred_handle OCTET STRING - NULL specifies default credentials 619 mech_option_set SET OF OBJECT IDENTIFIER 621 Outputs: 622 major_status INTEGER, 623 minor_status INTEGER, 625 Return major_status codes : 626 GSS_COMPLETE indicates that the set of security mechanisms 627 available for negotiation has been set to mech_option_set. 628 GSS_FAILURE indicates that the requested operation could not be 629 performed for reasons unspecified at the GSS-API level. 631 Allows callers to specify the set of security mechanism options that 632 may be negotiated with a particular credential: A NULL mech_option_set 633 specifies that only the default mech_type with the default option is 634 available for the GSS-API implementation. This call is intended for 635 support of specialised callers who need to restrict the set of 636 negotiable security mechanism options from the set of all security 637 mechanism options available to the caller (based on available 638 credentials). Note that if more than one mechanism is specified in 639 mech_option_set, the order in which those mechanisms are specified 640 implies a relative mechanism preference for the target. 642 REFERENCES 644 [1] Linn, J., "Generic Security Service Application Program 645 Interface", RFC 2078, OpenVision, January 1997. Available on 646 ftp://ds.internic.net/rfc/rfc2078.txt 648 [2] Standard ECMA-206, "Association Context Management including 649 Security Context Management", December 1993. Available on 650 http://www.ecma.ch 652 AUTHORS'S ADDRESSES 654 Eric Baize Internet email: E.Baize@ma02.bull.com 655 Bull HN - MA02/211S Phone: +1 508 294 61 37 656 Technology Park Fax: +1 508 294 61 09 657 Billerica, MA 01821 - USA 659 Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr 660 Bull Phone: +33 1 30 80 34 87 661 Rue Jean-Jaures Fax: +33 1 30 80 33 21 662 BP 68 663 78340 Les Clayes-sous-Bois - FRANCE