idnits 2.17.1 draft-ietf-cat-snego-02.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-19) 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 3 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 246: '... supportedMech [1] MechType 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 (17 October 1996) is 10046 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 245, 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 (~~), 2 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 17 October 1996 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. 80 The simple GSS-API mechanism negotiation does not provide any security 81 feature to protect the initially exchanged values for security context 82 parameters (i.e. during the negotiation process). 84 The Simple GSS-API Negotiation Mechanism uses the concepts developed 85 in GSS-API specification [1], and requires the use of a new GSS-API 86 context-level token : the negotiation token. Callers of the GSS-API do 87 not need to be aware of the negotiation token but only of the new 88 pseudo-security mechanism. A failure in the negotiation phase causes a 89 major status code to be returned: GSS_S_BAD_MECH. 91 3. NEGOTIATION MODEL 93 3.1. Negotiation description 95 The model for security mechanism negotiation reuses a subset of the 96 concepts specified in [2]. 98 Each security mechanism represents one basic security mechanism along 99 with one option for this security mechanism (when no option is present 100 the default option is assumed). 102 - When one security mechanism is proposed by the initiator, it 103 represents the only security mechanism option supported or 104 selected (when the additional APIs defined in the Annex A 105 are used) by the initiator. 107 - When several security mechanisms are proposed by the initiator, 108 they represent a set of security mechanisms supported or selected 109 (when the additional APIs defined in the Annex A are used) by the 110 initiator. 112 The target negotiation reply contains the result of the negotiation 113 (accept or reject) and, in case of accept, the agreed security 114 mechanism along with optional mechanism specific information. 116 In case of a successful negotiation, the security mechanism represents 117 the value suitable for the target, and picked up from the list offered 118 by the initiator. The target selects the value according to a simple 120 selection criteria: it checks if the first entry from its own list is 121 present in the set offered by the initiator. If the entry is present, 122 then it is the agreed mechanism, if not then the second entry from its 123 own ordered list is checked and the process continues until all 124 entries have been checked. Thus, the target's mechanism preferences 125 have precedence when more than one common mechanism is available 126 between the target and initiator. 128 3.2. Negotiation procedure 130 The negotiation procedure is summarised as follows: 132 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 133 requests (either explicitly, with the negotiation mechanism, or 134 through accepting a default, when the default is the negotiation 135 mechanism) that the Simple GSS-API Negotiation Mechanism be used; 137 (b) the initiator GSS-API implementation emits a negotiation token 138 containing the set of supported security mechanisms for the credentials 139 used for this context establishment, and indicates GSS_CONTINUE_NEEDED 140 status; 142 (c) The GSS-API initiator sends the token to the target application; 144 (d) The GSS-API target deposits the token through invoking 145 GSS_Accept_sec_context. The target GSS-API implementation emits a 146 negotiation token containing which if any of the proposed mechanisms 147 it supports (or has selected). 149 If the proposed mechanism(s) are accepted, GSS_Accept_sec_context() 150 indicates GSS_CONTINUE_NEEDED status. 152 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 153 indicates GSS_S_BAD_MECH status. The security context initialisation 154 has failed. 156 (e) The GSS-API target returns the token to the initiator application; 158 (f) The GSS-API initiator deposits the token through invoking 159 GSS_Init_sec_context. 161 If the negotiation token carries an accept result, 162 GSS_Init_sec_context() returns an initial context token as 163 output_token, and indicates GSS_CONTINUE_NEEDED or GSS_COMPLETE 164 status. The initiator sends the output_token to the target. The 165 security context initialisation is then performed according to the 166 standard GSS-API conventions for the selected mechanism. When 167 GSS_COMPLETE is returned, the mech_type output parameter indicates the 168 selected mechanism. Since the negotiation exchanges are not crypto- 169 graphically protected, the initiator GSS-API implementation must check 170 the returned/selected mechanism options with its originally submitted 171 list of mechanism options. When GSS_CONTINUE_NEEDED is returned, the 172 mech_type output parameter is not yet valid. 174 Note that the *_req_flag input parameters for context establishment 175 are relative to the selected mechanism, as are the *_state output 176 parameters. i.e., these parameters are not applicable to the 177 negotiation process per se. 179 If the negotiation token carries a reject result, the context 180 establishment is impossible, and GSS_Init_sec_context() indicates 181 GSS_S_BAD_MECH status. For example, a rejection will occur if 182 the target doesn't support the initiator's proposed mechanism type(s) 183 and/or mechanism option(s). Upon failure of the mechanism negotiation 184 procedure, the mech_type output parameter value is the negotiation 185 mechanism type. However, upon failure of the selected mechanism 186 context establishment, the mech_type output parameter value is the 187 selected mechanism type. 189 On receipt of a negotiation token on the target side, a GSS-API 190 implementation that does not support negotiation would indicate the 191 GSS_FAILURE status as if a particular basic security mechanism had 192 been requested but was not supported. 194 When GSS_Acquire_cred is invoked with the negotiation mechanism as 195 desired_mechs, an implementation-specific default credential is used to 196 carry on the negotiation. A set of mechanisms as specified locally by the 197 system administrator is then available for negotiation. If there is a 198 desire for the caller to make its own choice, then an additional API has to 199 be used (see Appendix A). 201 4. DATA ELEMENTS 203 4.1. Mechanism Type 205 MechType::= OBJECT IDENTIFIER 207 mechType 208 The concept of mechType is extended to specify a basic security 209 mechanism including its options. Each basic security mechanism 210 is as defined in [1], and must provide a single default option 211 which fully specifies the mechanism. The default option is 212 represented by the OID of the mechanism itself (i.e. without any 213 extension). 215 The options are specified by extending the OID. This 216 extension is defined in the same IETF GSS-API specification as 217 the security mechanism context token specification. 219 4.2. Negotiation Token 221 The negotiation token syntax follows InitialContextToken syntax 222 defined in [1]. The negotiation token is identified by an Object 223 Identifier (tbd). This section specifies the syntax of the 224 corresponding "innerContextToken" field. 226 NegotiationToken ::= CHOICE { 227 negTokenReq [0] NegTokenReq, 228 negTokenRep [1] NegTokenRep } 230 NegTokenReq ::= SEQUENCE of MechType 232 negTokenReq 233 Negotiation token sent by the initiator to the 234 target, which contains one or more security mechanisms 235 supported by the initiator. 237 negTokenRep 238 Negotiation token returned by the target to the 239 initiator which contains a global negotiation result, 240 the security mechanism selected (if any) and optional 241 information specific to the security mechanism 242 selected by the target. 244 NegTokenRep ::= SEQUENCE { 245 negResult [0] ENUMERATED { accept (0), reject (1) } 246 supportedMech [1] MechType OPTIONAL 247 MechSpecInfo [2] OCTET STRING OPTIONAL} 249 negResult 250 Result of the negotiation exchange, specified by the target. 251 This can be either : 252 accept 253 The target accepts one of the proposed 254 security mechanisms, or, 255 reject 256 The target rejects all the proposed security 257 mechanisms. 259 supportedMech 260 This field has to be present when negResult is "accept". 261 It is a choice from the mechanisms offered by the initiator. 263 MechSpecInfo 264 This field may be used to transmit mechanism specific 265 information relative to the security mechanism selected 266 by the target. 268 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION 270 Follow some examples of security mechanism options negotiation between 271 an initiator (I) and a target (T). 273 5.1. Initial steps 275 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), 276 and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- 277 OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 279 (I) invokes GSS_Init_sec_context() with : 281 Input 282 mech_type = OID for negotiation mechanism or NULL, if the 283 negotiation mechanism is the default mechanism. 285 Output 286 major_status = GSS_CONTINUE_NEEDED 287 output_token = negTokenReq 289 The negotiation token (negTokenReq) contains three security mechanisms 290 with : 291 mechType = GSS-MECH1 or 292 mechType = GSS-MECH2-OPTION1 or 293 mechType = GSS-MECH2-OPTION2 295 (I) sends to (T) the negotiation token. 297 5.2 Successful negotiation steps 299 (T) supports GSS-MECH2-OPTION1. 300 (T) receives the negotiation token (negTokenReq) from (I) 301 (T) invokes GSS_Accept_sec_context() with : 303 Input 304 input_token = negTokenReq 306 Output 307 major_status = GSS_CONTINUE_NEEDED 308 output_token = negTokenRep 310 The negotiation token (negTokenRep) contains : 311 negResult = accept (the negotiation result) 312 supportedMech : mechType = GSS-MECH2-OPTION1 314 (T) returns the negotiation token (negTokenRep) to (I) 315 (I) invokes GSS_Init_sec_context() with : 317 Input 318 input_token = negTokenRep 320 Output 321 major_status = GSS_COMPLETE 322 output_token = initialContextToken (initial context token 323 for GSS-MECH2-OPTION1) 324 mech_type = GSS-MECH2-OPTION1 326 The subsequent steps are security mechanism specific, and works as 327 specified in [1]. 329 5.3. Failed negotiation steps 331 (T) supports GSS-MECH3. 332 (T) receives the negotiation token (negTokenReq) from (I) 333 (T) invokes GSS_Accept_sec_context() with : 335 Input 336 input_token = negTokenReq 338 Output 339 major_status = GSS_S_BAD_MECH 340 output_token = negTokenRep 342 The negotiation token (negTokenRep) contains : 344 negResult = reject (the negotiation result) 346 (T) returns the negotiation token (negTokenRep) to (I) 347 (I) invokes GSS_Init_sec_context() with : 349 Input 350 input_token = negTokenRep 352 Output 353 major_status = GSS_S_BAD_MECH 355 The security context establishment has failed. 357 6. ACKNOWLEDGEMENTS 359 Acknowledgement are due to Piers McMahon and Tom Parker of ICL, 360 Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of 361 Openvision for reviewing earlier versions of this document and for 362 providing useful inputs. 364 7. SECURITY CONSIDERATIONS 366 The purpose of the generic simple GSS-API mechanism negotiation 367 mechanism is to enable peers to agree on the value for a security 368 mechanism and security related options required for initialising 369 security services. 371 As this mechanism is called prior to any initialisation of a security 372 service, it cannot make use of any security feature. Therefore it is 373 exposed to all threats a non secured service is exposed. Thus 374 communicating peers may be exposed to the denial of service threat, or 375 can be forced by an active attacker to use a security mechanism which 376 is not their common preferred one (when multiple security mechanisms 377 are shared between peers) but which is acceptable anyway to the 378 target. 380 APPENDIX A 382 GSS-API NEGOTIATION SUPPORT API 384 In order to provide to a GSS-API caller (either the initiator or the 385 target or both) the ability to choose among the set of supported 386 mechanisms a reduced set of mechanisms for negotiation, two 387 additionnal APIs are defined: 389 GSS_Get_neg_mechs() indicates the set of security mechanisms available 390 on the local system to the caller for negotiation. 392 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 393 used on the local system by the caller for negotiation. 395 A.1. GSS_Get_neg_mechs call 397 Input: 398 cred_handle OCTET STRING - NULL specifies default credentials 400 Outputs: 401 major_status INTEGER, 402 minor_status INTEGER, 403 mech_option_set SET OF OBJECT IDENTIFIER 405 Return major_status codes : 406 GSS_COMPLETE indicates that the set of security mechanism 407 options available for negotiation has been returned in 408 mech_option_set. 409 GSS_FAILURE indicates that the requested operation could not 410 be performed for reasons unspecified at the GSS-API level. 412 Allows callers to determine the set of security mechanism options 413 available for negotiation. This call is intended for support of 414 specialised callers who need to reduce the set of negotiable security 415 mechanism options from the set of supported security mechanisms 416 available to the caller (based on available credentials). 418 Note: The GSS_Indicate_mechs() function indicates the full set of mechanism 419 types available on the local system. Since this call does not use a 420 credential handle as an input parameter, the returned set is not 421 necessarily available for all credentials. 423 A.2. GSS_Set_neg_mechs call 425 Input: 426 cred_handle OCTET STRING - NULL specifies default credentials 427 mech_option_set SET OF OBJECT IDENTIFIER 429 Outputs: 430 major_status INTEGER, 431 minor_status INTEGER, 433 Return major_status codes : 434 GSS_COMPLETE indicates that the set of security mechanisms 435 available for negotiation has been set to mech_option_set. 436 GSS_FAILURE indicates that the requested operation could not be 437 performed for reasons unspecified at the GSS-API level. 439 Allows callers to specify the set of security mechanism options that 440 may be negotiated: A NULL mech_option_set specifies that only the 441 default mech_type with the default option is available for the GSS-API 442 implementation. This call is intended for support of specialised 443 callers who need to restrict the set of negotiable security mechanism 444 options from the set of all security mechanism options available to 445 the caller (based on available credentials). Note that if more than 446 one mechanism is specified in mech_option_set, the order in which those 447 mechanisms are specified implies a relative mechanism preference for 448 the target. 450 REFERENCES 452 [1] Linn, J., "Generic Security Service Application Program 453 Interface", RFC 1508, OpenVision, September 1993. 455 [2] Standard ECMA-206, "Association Context Management including 456 Security Context Management", December 1993. Available on 457 http://www.ecma.ch 459 AUTHORS'S ADDRESSES 461 Eric Baize Internet email: E.Baize@ma02.bull.com 462 Bull HN - MA02/211S Phone: +1 508 294 61 37 463 Technology Park Fax: +1 508 294 61 09 464 Billerica, MA 01821 - USA 466 Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr 467 Bull Phone: +33 1 30 80 34 87 468 Rue Jean-Jaures Fax: +33 1 30 80 34 70 469 BP 68 470 78340 Les Clayes-sous-Bois - FRANCE