idnits 2.17.1 draft-ietf-cat-snego-06.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-26) 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance 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 311: '... mechTypes [0] MechTypeList OPTIONAL...' RFC 2119 keyword, line 312: '... reqFlags [1] ContextFlags OPTIONAL,...' RFC 2119 keyword, line 313: '... preferredToken [2] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 346: '...t (2) } OPTIONAL...' RFC 2119 keyword, line 347: '... supportedMech [1] MechType OPTIONAL...' (3 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 July 1997) is 9775 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 343, but not defined == Missing Reference: '3' is mentioned on line 349, but not defined == Missing Reference: '4' is mentioned on line 350, 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 (~~), 4 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 22 July 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 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 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 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 and Protected GSS-API Negotiation 54 Mechanism allows to negotiate security mechanisms including their 55 options (i.e. variants). Mechanism options can be considered as 56 providing a 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 and protected GSS-API mechanism negotiation is based on the 75 following negotiation model : the initiator proposes one or several 76 security mechanisms, the target either accepts the proposed security 77 mechanism, or chooses one from an offered set, or rejects the proposed 78 value(s). The target informs the initiator of its choice and may also 79 return 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 83 network infrastructure and extra round trips over WAN links, packet 84 radio networks, etc. really make a difference. In order to avoid such 85 an extra round trip the initial security token of the preferred 86 mechanism for the initiator may be embedded in the initial token. 87 If the target preferred mechanism matches the initiator's preferred 88 mechanism, no additional round trips are incurred by using the 89 negotiation protocol. 91 The simple and protected GSS-API mechanism negotiation provides a 92 technique to protect the negotiation that must be used when the 93 underlying mechanism selected by the target is capable of integrity 94 protection. 96 When all the mechanisms proposed by the initiator support integrity 97 protection or when the selected mechanism supports integrity 98 protection, then the negotiation mechanism becomes protected since 99 this guarantees that the appropriate mechanism supported by both 100 peers has been selected. 102 The Simple and Protected GSS-API Negotiation Mechanism uses the 103 concepts developed in GSS-API specification [1], and requires the use 104 of new GSS-API context-level tokens : negotiation tokens. Callers 105 of the GSS-API do not need to be aware of the existence of the 106 negotiation tokens but only of the new pseudo-security mechanism. 107 A failure in the negotiation phase causes a major status code to be 108 returned: GSS_S_BAD_MECH. 110 3. NEGOTIATION MODEL 112 3.1. Negotiation description 114 The model for security mechanism negotiation reuses a subset of the 115 concepts specified in [2]. 117 Each security mechanism represents one basic security mechanism along 118 with one option for this security mechanism (when no option is present 119 the default option is assumed). 121 - When one security mechanism is proposed by the initiator, it 122 represents the only security mechanism option supported or 123 selected (when the additional APIs defined in the Annex A 124 are used) by the initiator. 126 - When several security mechanisms are proposed by the initiator, 127 they represent a set of security mechanisms supported or selected 128 (when the additional APIs defined in the Annex A are used) by the 129 initiator. 131 The first negotiation token sent by the initiator contains an ordered 132 list of mechanisms, a set of options (e.g. deleg, replay, conf flags) 133 that should be supported by the selected mechanism and optionally the 134 initial security token for the desired mechanism of the initiator 135 (i.e. the first of the list). 137 The first negotiation token sent by the target contains the result of 138 the negotiation (accept_completed, accept_incomplete or reject) and, 139 in case of accept, the agreed security mechanism along with optional 140 mechanism specific information. It may also include the response to 141 the initial security token for the desired mechanism of the initiator, 142 when the first proposed mechanism has been selected. Not all targets 143 must be able to respond to the initial security token for the desired 144 mechanism when it is present. The target can simply ignore it and 145 complete the negotiation without it. Implementations that can piggyback 146 the initial token will be rewarded by faster connection setup. 148 In case of a successful negotiation, the security mechanism represents 149 the value suitable for the target, and picked up from the list offered 150 by the initiator. The target selects the value according to a simple 151 selection criteria: it checks if the first entry from its own list is 152 present in the set offered by the initiator. If the entry is present 153 and the set of options is supported by that mechanism then it is 154 the agreed mechanism, if not then the second entry from its own 155 ordered list is checked and the process continues until all entries 156 have been checked. If none of the mechanisms supports all the options, 157 then the set of options is ignored and the list of mechanism is 158 scanned again. Thus, the target's mechanism preferences have 159 precedence when more than one common mechanism supporting the options 160 of the initiator is available between the target and initiator. It is 161 up to the initiator to verify that the requested options are indeed 162 supported when the context is established. 164 3.2. Negotiation procedure 166 The negotiation procedure is summarised as follows: 168 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 169 requests (either explicitly, with the negotiation mechanism, or 170 through accepting a default, when the default is the negotiation 171 mechanism) that the Simple and Protected GSS-API Negotiation Mechanism 172 be used; 174 (b) the initiator GSS-API implementation emits a negotiation token 175 containing the set of supported security mechanism for the credentials 176 used for this context establishment, and optionally the initial 177 security token for the preferred mechanism, and indicates 178 GSS_CONTINUE_NEEDED status; 180 (c) The GSS-API initiator sends the token to the target application; 182 (d) The GSS-API target deposits the token through invoking 183 GSS_Accept_sec_context. The target GSS-API implementation emits a 184 negotiation token containing which if any of the proposed mechanisms 185 it supports (or has selected). 187 If the preferred mechanism selected by the target matches the preferred 188 mechanism identified by the initiator and the initiator provides a 189 preferredToken, the negotiation token response may contain also the 190 initial security token from that mechanism. 192 If the preferred mechanism is accepted, GSS_Accept_sec_context() 193 indicates GSS_COMPLETE when unilateral or mutual authentication has 194 been performed and involves a single token in either direction. 196 If a proposed mechanism other than the preferred mechanism is accepted, 197 or the preferred mechanism is accepted but involves multiple exchanges 198 (e.g. challenge-response authentication), then GSS_Accept_sec_context() 199 indicates GSS_CONTINUE_NEEDED status. 201 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 202 indicates GSS_S_BAD_MECH status. The security context initialisation 203 has failed. 205 (e) The GSS-API target returns the token to the initiator application; 207 (f) The GSS-API initiator deposits the token through invoking 208 GSS_Init_sec_context. 210 GSS_Init_sec_context() may then indicate GSS_CONTINUE_NEEDED, 211 GSS_COMPLETE or GSS_S_BAD_MECH status. 213 The GSS_S_BAD_MECH status is returned when the negotiation token 214 carries a reject result or when the negotiation token carries an 215 accept result and the mechanism selected by the target is not 216 included in the initial list sent by the initiator or the 217 selected mechanism supports a MIC token but the MIC computed over 218 the list of mechanisms sent by the initiator is missing or 219 incorrect. If the negotiation token carries a reject result, the 220 context establishment is impossible. For example, a rejection 221 will occur if the target doesn't support the initiator's proposed 222 mechanism type(s) and/or mechanism option(s). Upon failure of the 223 mechanism negotiation procedure, the mech_type output parameter 224 value is the negotiation mechanism type. 226 The GSS_CONTINUE_NEEDED status is returned when the negotiation 227 token carries an accept result and further tokens must be 228 transferred in order to complete context establishment for the 229 selected mechanism. In that case GSS_Init_sec_context() returns 230 an initial context token as output_token (with the selected 231 mechanism's context token encapsulated within that output_token). 232 The initiator then sends the output_token to the target. The 233 security context initialisation is then continued according to 234 the standard GSS-API conventions for the selected mechanism, 235 where the tokens of the selected mechanism are encapsulated until 236 the GSS_COMPLETE is returned for both the initiator and the 237 target. When GSS_CONTINUE_NEEDED is returned, the mech_type 238 output parameter is not yet valid. 240 When GSS_COMPLETE is returned, the mech_type output parameter 241 indicates the selected mechanism. When the final negotiation token 242 does not contain a MIC, the initiator GSS-API implementation must 243 check the returned/selected mechanism options with its originally 244 submitted list of mechanism options and also verify that the 245 selected mechanism is not able to support a MIC. When the final 246 negotiation token contains a MIC over the initial mechanisms list 247 sent by the initiator, the MIC must be verified. 249 Note that the *_req_flag input parameters for context establishment 250 are relative to the selected mechanism, as are the *_state output 251 parameters. i.e., these parameters are not applicable to the 252 negotiation process per se. 254 The initiator GSS-API calling application may need to know when the 255 negotiation exchanges were protected or not. For this, when 256 GSS_COMPLETE is returned, it can simply test the integ_avail flag. 257 When this flag is set it indicates that the negotiation was protected. 259 On receipt of a negotiation token on the target side, a GSS-API 260 implementation that does not support negotiation would indicate the 261 GSS_FAILURE status as if a particular basic security mechanism had 262 been requested but was not supported. 264 When GSS_Acquire_cred is invoked with the negotiation mechanism as 265 desired_mechs, an implementation-specific default credential is used 266 to carry on the negotiation. A set of mechanisms as specified locally 267 by the system administrator is then available for negotiation. If there 268 is a desire for the caller to make its own choice, then an additional 269 API has to be used (see Appendix A). 271 4. DATA ELEMENTS 273 4.1. Mechanism Type 275 MechType::= OBJECT IDENTIFIER 277 mechType 278 The concept of mechType is extended to specify a basic security 279 mechanism including its options. Each basic security mechanism 280 is as defined in [1], and must provide a single default option 281 which fully specifies the mechanism. The default option is 282 represented by the OID of the mechanism itself (i.e. without any 283 extension). 285 The options are specified by extending the OID. This extension 286 is defined in the same IETF GSS-API mechanism specification as 287 the security mechanism context token specification. 289 4.2. Negotiation Tokens 291 The syntax of the negotiation tokens follows the InitialContextToken 292 syntax defined in [1]. The security mechanism of the initial 293 negotiation token is identified by the Object Identifier 294 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 296 4.2.1. Syntax 298 This section specifies the syntax of the corresponding 299 "innerContextToken" field for the first token and subsequent 300 negotiation tokens. 302 NegotiationToken ::= CHOICE { 303 negTokenInit [0] NegTokenInit, 304 negTokenTarg [1] NegTokenTarg } 306 MechType ::= OBJECT IDENTIFIER 308 MechTypeList ::= SEQUENCE OF MechType 310 NegTokenInit ::= SEQUENCE { 311 mechTypes [0] MechTypeList OPTIONAL 312 reqFlags [1] ContextFlags OPTIONAL, 313 preferredToken [2] OCTET STRING OPTIONAL 314 } 316 ContextFlags ::= BIT STRING { 317 delegFlag (0), 318 mutualFlag (1), 319 replayFlag (2), 320 sequenceFlag (3), 321 anonFlag (4), 322 confFlag (5), 323 > integFlag (6) 324 } 326 negTokenInit 327 Negotiation token sent by the initiator to the target, which 328 contains, for the first token sent, one or more security 329 mechanisms supported by the initiator and the service options 330 (reqFlags) that are requested to establish the the context. 331 The preferredToken is an optional field of the first token sent 332 that all target implementations would not have to support. However 333 for those targets that do support piggybacking the initial 334 preferredToken, an optimistic negotiation response is possible. 336 Further tokens, when needed, contain only the preferredToken 337 which is a token specific to the selected mechanism. 339 The context flags should be filled in from the req_flags parameter 340 of init_sec_context() 342 NegTokenTarg ::= SEQUENCE { 343 negResult [0] ENUMERATED { 344 accept_completed (0), 345 accept_incomplete (1), 346 reject (2) } OPTIONAL 347 supportedMech [1] MechType OPTIONAL 348 MechSpecInfo [2] OCTET STRING OPTIONAL 349 preferredToken [3] OCTET STRING OPTIONAL 350 mechListMIC [4] OCTET STRING OPTIONAL 351 } 353 negTokenTarg 354 Negotiation token returned by the target to the initiator which 355 contains, for the first token returned, a global negotiation 356 result, the security mechanism selected (if any) and optional 357 information specific to the security mechanism selected by the 358 target. The result accept_completed indicates that a context 359 has been successfully established using the preferredToken that 360 was initially sent by the initiator, while the result 361 accept_incomplete indicates that additional token exchanges are 362 needed. 364 Note: For the case where (a) a single-token context setup 365 is used and (b) the preferred mechanism does not support 366 the integrity facility which would cause a mechListMIC to be 367 generated and enclosed, this feature allows to make a 368 difference between a preferredToken sent by the initiator 369 but not processed by the target (accept_incomplete) and 370 a preferredToken sent by the initiator and processed by 371 the target (accept_completed). 373 For those targets that support piggybacking the initial 374 preferredToken, an optimistic negotiation response is possible 375 and includes in that case a preferredToken which may continue 376 the authentication exchange (e.g. when mutual authentication has 377 been requested or when unilateral authentication requires several 378 round trips). Otherwise the preferredToken is used to carry the 379 tokens specific to the mechanism selected. 381 For subsequent tokens (if any) returned by the target, negResult, 382 supportedMech and MechSpecInfo are not present. 384 For the last token returned by the target, the mechListMIC, when 385 present, is a MIC computed over the MechTypes using the selected 386 mechanism. 388 negResult 389 Result of the negotiation exchange, specified by the target. 390 This can be either : 391 accept_completed 392 The target accepts the preferred security mechanism, 393 and the context is established for the target or, 394 accept_incomplete 395 The target accepts one of the proposed security 396 mechanisms and further exchanges are necessary, or, 397 reject 398 The target rejects all the proposed security 399 mechanisms. 401 supportedMech 402 This field has to be present when negResult is "accept_completed" 403 or "accept_incomplete". It is a choice from the mechanisms offered 404 by the initiator. 406 MechSpecInfo 407 This field may be used to transmit mechanism specific 408 information relative to the security mechanism selected 409 by the target. 411 preferredToken 412 This field may be used either to transmit the response to the 413 preferredToken when sent by the initiator and when the first 414 mechanism from the list has been selected by the target or 415 to carry the tokens specific to the selected security mechanism. 417 mechListMIC 418 If the selected mechanism is capable of integrity protection, 419 this field must be present in the last message of the negotiation, 420 (i.e., when the underlying mechanism returns a non-empty token 421 and a major status of GSS_COMPLETE); it contains the result of a 422 GetMIC of the MechTypes field in the initial NegTokenInit. 424 It allows to verify that the list initially sent by the initiator 425 has been received unmodified by the target. 427 4.2.2. Processing of mechListMIC. 429 When the mechanism selected by the negotiation supports integrity 430 protection as a service, the mechListMIC must be used and validated. 432 In particular, the target that sends the last context establishment 433 token must also include the result of a gss_get_mic() of the 434 mechTypeList sent by the initiator in the first token; in addition, 435 the initiator that receives the last token must require that the 436 mechListMIC field be present and valid. In the absence of a valid 437 mechListMIC, the negotiation must fail as if the last context 438 establishment token was invalid. 440 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION 442 Follow some examples of security mechanism options negotiation between 443 an initiator (I) and a target (T). 445 5.1. Initial steps 447 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 448 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 449 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 451 (I) invokes GSS_Init_sec_context() with : 453 Input 454 mech_type = OID for negotiation mechanism or NULL, if the 455 negotiation mechanism is the default mechanism. 457 Output 458 major_status = GSS_CONTINUE_NEEDED 459 output_token = negTokenInit 461 The negotiation token (negTokenInit) contains three security mechanisms 462 with : 463 mechType = GSS-MECH1 or 464 mechType = GSS-MECH2-OPTION1 or 465 mechType = GSS-MECH2-OPTION2 467 (I) sends to (T) the negotiation token. 469 5.2 Successful negotiation steps 471 (T) supports GSS-MECH2-OPTION1. 472 (T) receives the negotiation token (negTokenInit) from (I) 473 (T) invokes GSS_Accept_sec_context() with : 475 Input 476 input_token = negTokenInit 478 Output 479 major_status = GSS_CONTINUE_NEEDED 480 output_token = negTokenTarg 482 The negotiation token (negTokenTarg) contains : 483 negResult = accept (the negotiation result) 484 supportedMech : mechType = GSS-MECH2-OPTION1 486 (T) returns the negotiation token (negTokenTarg) to (I) 487 (I) invokes GSS_Init_sec_context() with : 489 Input 490 input_token = negTokenTarg 492 Output 493 major_status = GSS_COMPLETE 494 output_token = initialContextToken (initial context token 495 for GSS-MECH2-OPTION1) 496 mech_type = GSS-MECH2-OPTION1 498 The subsequent steps are security mechanism specific, and work as 499 specified in [1]. The output tokens from the security mechanism are 500 encapsulated in a NegTokenTarg message (with the supportedMech and 501 MechSpecInfo fields omitted, and the mechListMIC included with the 502 last token). 504 5.3. Failed negotiation steps 506 (T) supports GSS-MECH3. 507 (T) receives the negotiation token (negTokenInit) from (I) 508 (T) invokes GSS_Accept_sec_context() with : 510 Input 511 input_token = negTokenInit 513 Output 514 major_status = GSS_S_BAD_MECH 515 output_token = negTokenTarg 517 The negotiation token (negTokenTarg) contains : 519 negResult = reject (the negotiation result) 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_S_BAD_MECH 530 The security context establishment has failed. 532 5.4 Successful Negotiation with preferred mechanism info 534 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 535 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 536 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 538 (I) invokes GSS_Init_sec_context() with : 540 Input 541 mech_type = OID for negotiation mechanism or NULL, if the 542 negotiation mechanism is the default mechanism. 544 Output 545 major_status = GSS_CONTINUE_NEEDED 546 output_token = negTokenInit 548 The negotiation token (negTokenInit) contains three security mechanisms 549 with : 550 mechType = GSS-MECH1 or 551 mechType = GSS-MECH2-OPTION1 or 552 mechType = GSS-MECH2-OPTION2 554 preferredToken = output_token from GSS_Init_sec_context 555 ( first mechType) as described in [1] 557 (I) sends to (T) the negotiation token. 559 (T) supports GSS-MECH1. 560 (T) receives the negotiation token (negTokenInit) from (I) 561 (T) invokes GSS_Accept_sec_context() with : 563 Input 564 input_token = negTokenInit 566 Output 567 major_status = GSS_CONTINUE_NEEDED 568 output_token = negTokenTarg 570 The negotiation token (negTokenTarg) contains : 571 negResult = accept (the negotiation result) 572 supportedMech : mechType = GSS-MECH1 573 MechSpecInfo = mechanism specific information for 574 the preferred mechanism 575 preferredToken = output_token from 576 GSS_Accept_sec_context(preferredToken ) 578 (T) returns the negotiation token (negTokenTarg) to (I) 579 (I) invokes GSS_Init_sec_context() with : 581 Input 582 input_token = negTokenTarg 584 Output 585 major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed 586 output_token = ContextToken (initial or subsequent context token 587 for GSS-MECH1) 588 mech_type = GSS-MECH1 590 Specific implementations of the protocol can support the optimistic 591 negotiation by completing the security context establishment using the 592 agreed upon mechanism as described in [1]. As described above in 593 section 5.2, the output tokens from the security mechanism are 594 encapsulated in a NegTokenTarg message (with the negResult, 595 supportedMech and MechSpecInfo fields omitted, and the mechListMIC 596 included with the last token). 598 6. ACKNOWLEDGMENTS 600 Acknowledgments are due to Piers McMahon and Tom Parker of ICL, 601 Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of 602 Openvision for reviewing earlier versions of this document and for 603 providing useful inputs. Acknowledgments are also due to Peter Brundrett 604 of Microsoft for his proposal for an optimistic negotiation, and for 605 Bill Sommerfeld of Hewlett-Packard for his proposal for protecting 606 the negotiation. 608 7. SECURITY CONSIDERATIONS 610 The purpose of the generic simple GSS-API mechanism negotiation 611 mechanism is to enable peers to agree on the value for a security 612 mechanism and security related options required for initialising 613 security services. 615 When the mechanism selected by the target from the list supplied by 616 the initiator supports integrity protection, then the negotiation is 617 protected. 619 When one of the mechanisms proposed by the initiator does not support 620 integrity protection, then the negotiation is exposed to all threats a non 621 secured service is exposed. In particular, an active attacker can force to 622 use a security mechanism which is not the common preferred one (when 623 multiple security mechanisms are shared between peers) but which is 624 acceptable anyway to the target. 626 In any case, the communicating peers may be exposed to the denial of 627 service threat. 629 APPENDIX A 631 GSS-API NEGOTIATION SUPPORT API 633 In order to provide to a GSS-API caller (either the initiator or the 634 target or both) the ability to choose among the set of supported 635 mechanisms a reduced set of mechanisms for negotiation, two 636 additional APIs are defined: 638 GSS_Get_neg_mechs() indicates the set of security mechanisms available 639 on the local system to the caller for negotiation. 641 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 642 used on the local system by the caller for negotiation. 644 A.1. GSS_Get_neg_mechs call 646 Input: 647 cred_handle CREDENTIAL HANDLE 648 - NULL specifies default credentials 650 Outputs: 651 major_status INTEGER, 652 minor_status INTEGER, 653 mech_option_set SET OF OBJECT IDENTIFIER 655 Return major_status codes : 656 GSS_S_COMPLETE indicates that the set of security mechanism 657 options available for negotiation has been returned in 658 mech_option_set. 659 GSS_S_FAILURE indicates that the requested operation could not 660 be performed for reasons unspecified at the GSS-API level. 662 Allows callers to determine the set of security mechanism options 663 available for negotiation. This call is intended for support of 664 specialised callers who need to reduce the set of negotiable security 665 mechanism options from the set of supported security mechanisms 666 available to the caller (based on available credentials). 668 Note: The GSS_Indicate_mechs() function indicates the full set of 669 mechanism types available on the local system. Since this call has no 670 input parameter, the returned set is not necessarily available for all 671 credentials. 673 A.2. GSS_Set_neg_mechs call 675 Input: 676 cred_handle CREDENTIAL HANDLE 677 - NULL specifies default credentials 678 mech_option_set SET OF OBJECT IDENTIFIER 680 Outputs: 681 major_status INTEGER, 682 minor_status INTEGER, 684 Return major_status codes : 685 GSS_S_COMPLETE indicates that the set of security mechanisms 686 available for negotiation has been set to mech_option_set. 687 GSS_S_FAILURE indicates that the requested operation could not be 688 performed for reasons unspecified at the GSS-API level. 690 Allows callers to specify the set of security mechanism options that 691 may be negotiated with a particular credential: A NULL mech_option_set 692 specifies that only the default mech_type with the default option is 693 available for the GSS-API implementation. This call is intended for 694 support of specialised callers who need to restrict the set of 695 negotiable security mechanism options from the set of all security 696 mechanism options available to the caller (based on available 697 credentials). Note that if more than one mechanism is specified in 698 mech_option_set, the order in which those mechanisms are specified 699 implies a relative mechanism preference for the target. 701 REFERENCES 703 [1] Linn, J., "Generic Security Service Application Program 704 Interface", RFC 2078, OpenVision, January 1997. Available on 705 ftp://ds.internic.net/rfc/rfc2078.txt 707 [2] Standard ECMA-206, "Association Context Management including 708 Security Context Management", December 1993. Available on 709 http://www.ecma.ch 711 AUTHORS'S ADDRESSES 713 Eric Baize Internet email: E.Baize@ma02.bull.com 714 Bull HN - MA02/211S Phone: +1 508 294 61 37 715 Technology Park Fax: +1 508 294 61 09 716 Billerica, MA 01821 - USA 718 Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr 719 Bull Phone: +33 1 30 80 34 87 720 Rue Jean-Jaures Fax: +33 1 30 80 33 21 721 BP 68 722 78340 Les Clayes-sous-Bois - FRANCE