idnits 2.17.1 draft-ietf-kitten-stackable-pseudo-mechs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 699. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 563 has weird spacing: '...OID_set mechs...' -- 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 (October 16, 2005) is 6768 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 section? 'RFC2119' on line 658 looks like a reference -- Missing reference section? 'LIPKEY' on line 122 looks like a reference -- Missing reference section? 'CCM' on line 101 looks like a reference -- Missing reference section? 'CFX' on line 122 looks like a reference -- Missing reference section? 'SPKM' on line 122 looks like a reference -- Missing reference section? 'SPNEGO' on line 137 looks like a reference -- Missing reference section? 'EXTENDED-INQUIRY' on line 652 looks like a reference -- Missing reference section? 'RFC2743' on line 661 looks like a reference -- Missing reference section? 'RFC2078' on line 451 looks like a reference -- Missing reference section? 'RFC2744' on line 664 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: April 19, 2006 October 16, 2005 6 Stackable Generic Security Service Pseudo-Mechanisms 7 draft-ietf-kitten-stackable-pseudo-mechs-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document defines and formalizes the concept of stackable pseudo- 41 mechanisms, and associated concept of composite mechanisms, for the 42 Generic Security Service Application Programming Interface (GSS-API), 43 as well as several utility functions. 45 Stackable GSS-API pseudo-mechanisms allow for the composition of new 46 mechanisms that combine features from multiple mechanisms. Stackable 47 mechanisms that add support for Perfect Forward Security (PFS), data 48 compression, additional authentication factors, etc... are 49 facilitated by this document. 51 Table of Contents 53 1. Conventions used in this document . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Mechanism Composition Issues . . . . . . . . . . . . . . . 4 57 4. Mechanism Composition . . . . . . . . . . . . . . . . . . 5 58 4.1. Construction of Composed Mechanism OIDs . . . . . . . . . 5 59 4.2. Mechanism Composition Rules . . . . . . . . . . . . . . . 6 60 4.3. Interfacing with Composite Mechanisms . . . . . . . . . . 7 61 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces . . . 7 62 4.5. Processing of Tokens for Composite Mechanisms . . . . . . 8 63 5. New GSS-API Interfaces . . . . . . . . . . . . . . . . . . 8 64 5.1. New GSS-API Function Interfaces . . . . . . . . . . . . . 9 65 5.1.1. GSS_Compose_oid() . . . . . . . . . . . . . . . . . . . . 9 66 5.1.2. GSS_Decompose_oid() . . . . . . . . . . . . . . . . . . . 10 67 5.1.3. GSS_Release_oid() . . . . . . . . . . . . . . . . . . . . 10 68 5.1.4. GSS_Indicate_negotiable_mechs() . . . . . . . . . . . . . 11 69 5.1.5. GSS_Negotiate_mechs() . . . . . . . . . . . . . . . . . . 12 70 5.1.6. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Negotiation of Composite Mechanisms . . . . . . . . . . . 13 72 6.1. Negotiation of Composite Mechanisms Through SPNEGO . . . . 14 73 7. Requirements for Mechanism Designers . . . . . . . . . . . 14 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 75 9. Security considerations . . . . . . . . . . . . . . . . . 14 76 10. Normative . . . . . . . . . . . . . . . . . . . . . . . . 15 77 Author's Address . . . . . . . . . . . . . . . . . . . . . 16 78 Intellectual Property and Copyright Statements . . . . . . 17 80 1. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 Recent discussions within the IETF have shown the need for a 89 refactoring of the features that GSS-API mechanisms may provide and a 90 way to compose new mechanisms from smaller components. 92 One way to do this is to "stack" multiple mechanisms on top of each 93 other such that the features of all of them are summed into a new, 94 composite mechanism. 96 One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially 97 stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not 98 conform to the stackable pseduo-mechanism framework described 99 herein). 101 The first truly stackable pseudo-mechanism proposed, CCM [CCM], is 102 intended for signalling, during negotiation of mechanisms, the 103 willingness of an initiator and/or acceptor to utilize channel 104 bindings 106 Since then other similar mechanism compositing needs and ideas have 107 come up, along with problems such as "what combinations are possible, 108 useful, reasonable and secure?" This document addresses those 109 problems. It introduces the concepts of stackable pseudo-mechanisms, 110 composite mechanisms and mechanism features or attributes, as well as 111 new inquiry and related interfaces to help in the mechanism 112 compositing. 114 (Mechanism features are more formally referred to as "mechanism 115 attributes" below. The terms "feature" and mechanism attribute" are 116 sometimes used interchangeably.) 118 2.1. Glossary 120 Concrete GSS-API mechanism 121 A mechanism which can be used standalone. Examples include: the 122 Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY]. 124 GSS-API Pseudo-mechanism 125 A mechanism which uses other mechanisms in the construction of its 126 context and/or per-message tokens and security contexts. SPNEGO 127 is an example of this. 129 Stackable GSS-API pseudo-mechanism 130 A mechanism which uses a single other mechanism in the 131 construction of its tokens such that the OID of the composite 132 result can be constructed by prepending the OID of the stackable 133 pseudo-mechanism to the OID of the mechanism to be used by it. 135 Mechanism-negotiation GSS-API pseudo-mechanism 136 A GSS-API mechanism that negotiates the use of GSS-API mechanisms. 137 SPNEGO [SPNEGO] is an example of this. 139 3. Mechanism Composition Issues 141 Interfacing with composite mechanisms through the existing GSS-API 142 interfaces and the handling of composite mechanism tokens is 143 straightforward enough and described in Section 4. 145 However, the concepts of stackable and composite mechanisms do give 146 rise to several minor problems: 148 o How to determine allowable combinations of mechanisms; 149 o How to encode composite mechanism OIDs; 150 o How to decompose the OID of a composite mechanism and process its 151 tokens properly; 152 o Application interfacing issues such as: 154 * Whether and/or which composite mechanisms should be listed by 155 GSS_Indicate_mechs(); 156 * Whether and/or which composite mechanisms not listed by 157 GSS_Indicate_mechs() may nonetheless be available for use by 158 applications and how applications can detect their 159 availability; 160 * What additional, if any, interfaces should be provided to help 161 applications select appropriate mechanisms; 162 o 164 Mechanism negotiation issues (related to the application interface 165 issues listed above), such as: vspace blankLines='1'/> 166 * Should applications advertise composite mechanisms in SPNEGO or 167 other application-specific mechanism negotiation contexts? 168 * Or should applications implicitly advertise composite 169 mechanisms by advertising concrete and stackable pseudo- 170 mechanisms in SPNEGO or other application-specific mechanism 171 negotiation contexts? 173 Section 4 addresses the OID composition, decomposition and encoding 174 issues, as well as basic interfacing and token handling issues. 176 Section 5 addresses interfacing issues more generally through the 177 specification of additional, optional APIs. 179 Section 6 addresses mechanism negotiation issues. 181 4. Mechanism Composition 183 Mechanism composition by stacking pseudo-mechanisms on a concrete 184 mechanism is conceptually simple: join the OIDs of the several 185 mechanisms in question and process GSS-API tokens and routine calls 186 through the top-most pseudo-mechanism in a stack, which can then, if 187 necessary, recursively call the GSS-API to process any tokens for the 188 remainder of the stack. 190 Some stackable pseudo-mechanisms may do nothing more than perform 191 transformations on application data (e.g., compression); such pseudo- 192 mechanisms will generally chain the processing of tokens and routine 193 calls to the mechanisms below them in the stack. 195 Other stackable pseudo-mechanisms may utilize the mechanisms below 196 them only during security context setup. For example, a stackable 197 pseudo-mechanism could perform a Diffie-Hellman key exchange and 198 authenticate it by binding a security context established with the 199 mechanism stacked below it; such a mechanism would provide its own 200 per-message tokens. 202 4.1. Construction of Composed Mechanism OIDs 204 Composition of mechanism OIDs is simple: prepend the OID of one 205 pseudo-mechanism to the OID of another mechanism (composite or 206 otherwise), but there MUST always be at least one final mechanism OID 207 and it MUST be useful standalone (i.e., it MUST NOT be a pseudo- 208 mechanism). A composite mechanism OID forms, essentially, a stack. 210 The encoding of composed mechanism OIDs is not quite the 211 concatenation of the component OIDs' encodings, however. This is 212 because the first two arcs of ASN.1 OIDs are encoded differently from 213 subsequent arcs (the first two arcs have a limited namespace and are 214 encoded as a single octet), so were composite mechanism OIDs to be 215 encoded as the concatenation of the component OIDs the result would 216 not decode as the concatenation of the component OIDs. To avoid this 217 problem the first two arcs of each component of a composite mechanism 218 OID, other than the leading component, will be encoded as other arcs 219 would. 221 Decomposition of composite mechanism OIDs is similar, with each 222 pseudo-mechanism in the stack being able to determine the OID suffix 223 from knowledge of its own OID(s). 225 New pseudo-mechanisms MAY be allocated OIDs from the prefix given 226 below as follows by assignment of a sub-string of OID arcs to be 227 appended to this prefix. This prefix OID is: 229 [1.3.6.1.5.5.11 appears to be available, registration w/ IANA 230 TBD] 232 All OID allocations below this OID MUST be for stackable pseudo- 233 mechanisms and MUST consist of a single arc. This will make it 234 possible to decompose the OIDs of composite mechanisms without 235 necessarily knowing a priori the OIDs of the component stackable 236 pseudo-mechanisms. 238 4.2. Mechanism Composition Rules 240 All new stackable pseudo-mechanisms MUST specify the rules for 241 determining whether they can stack above a given mechanism, composite 242 or otherwise. Such rules may be based on specific mechanism 243 attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs 244 (composite and otherwise). 246 All stackable pseudo-mechanisms MUST have the following mechanism 247 composition rule relating to unknown mechanism attributes: 249 o composition with mechanisms supporting unknown mechanism 250 attributes MUST NOT be permitted. 252 This rule protects against compositions which cannot be considered 253 today but which might nonetheless arise due to the introduction of 254 new mechanisms and which might turn out to be insecure or otherwise 255 undesirable. 257 Mechanism composition rules for stackable pseudo-mechanisms MAY and 258 SHOULD be updated as new GSS-API mechanism attributes and mechanisms 259 sporting them are introduced. The specifications of mechanisms that 260 introduce new mechanism attributes or which otherwise should not be 261 combined with others in ways which would be permitted under existing 262 rules SHOULD also update the mechanism composition rules of affected 263 pseudo-mechanisms. 265 A RECOMMENDED way to describe the stacking rules for stackable 266 mechanisms is as an ordered sequence of "MAY stack above X 267 mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above 268 Z mechanism," and/or "MUST NOT stack above a mechanism with Z 269 mechanism feature(s)." 271 For example a stackable mechanism that provides its own per-msg 272 tokens and does not use the underlying mechnism's per-msg token 273 facilities might require a rule such as "MUST NOT stack above a 274 mechanism with the GSS_C_MA_COMPRESS mechanism feature." 276 4.3. Interfacing with Composite Mechanisms 278 The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or 279 provide as output the OID of any stackable pseudo-mechanism. 280 Composite mechanisms MUST be treated as concrete mechanisms by the 281 basic GSS-API interfaces [RFC2743]. 283 Thus the way in which a composite mechanism is used by applications 284 with the basic GSS-API (version 2, update 1) is straightforward: 285 exactly as if composite mechanisms were normal GSS-API mechanisms. 287 This is facilitated by the fact that in all cases where the GSS-API 288 implementation might need to know how to process or create a token it 289 has the necessary contextual information, that is, the mechanism OID, 290 available and can decompose composite mechanism OIDs as necessary. 292 For example, for initial GSS_Init_sec_context() calls the 293 implementation knows the desired mechanism OID, and if it should be 294 left unspecified, it can pick a default mechanism given the initiator 295 credentials provided by the application (and if none are provided 296 other default mechanism and credential selections can still be made). 297 For subsequent calls to GSS_Init_sec_context() the implementation 298 knows which mechanism to use from the given [partially established] 299 security context. Similarly for GSS_Accept_sec_context, where on 300 initial calls the mechanism OID can be determined from the given 301 initial context token's framing. 303 The manner in which GSS-API implementations and the various 304 mechanisms and pseudo-mechanisms interface with one another is left 305 as an excercise to implementors. 307 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces 309 In order to preserve backwards compatibility with applications that 310 use only the basic GSS-API interfaces (version 2, update 1), several 311 restrictions are imposed on the use of composite and stackable 312 pseduo-mechanisms with the basic GSS-API interfaces: 314 o GSS_Indicate_mechs() MUST NOT indicate support for any stackable 315 pseduo-mechanisms under any circumstance. 316 o GSS_Indicate_mechs() MAY indicate support for some, all or none of 317 the available composite mechanisms. 318 o Which composite mechanisms, if any, are indicated through 319 GSS_Indicate_mechs() SHOULD be configurable. 320 o Composite mechanisms which are not indicated by 321 GSS_Indicate_mechs() MUST NOT be considered as the default 322 mechanism (GSS_C_NULL_OID) or as part of the default mechanism set 323 (GSS_C_NULL_OID_SET). 324 o The OIDs of *stackable* (not composite) pseudo-mechanisms MUST NOT 325 be accepted as inputs or produced in the output of any of the 326 basic GSS-APIv2, update 1 API functions, except for any OID set 327 construction/iteration functions. And, if present in any OID SET 328 input parameters of GSS-APIv2, update 1 functions, they MUST be 329 ignored. 330 o The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only 331 be used as inputs or produced as outputs of functions whose 332 specification explicitly allows for them or which are concerned 333 with the creation/iteration of OID containters, such as OID SETs. 335 4.5. Processing of Tokens for Composite Mechanisms 337 The initial context token for any standard mechanism, including 338 mechanisms composited from standard pseudo- and concrete mechanisms, 339 MUST be encapsulated as described in section 3.1 of rfc2743 340 [RFC2743], and the OID used in that framing MUST be that of the 341 mechanism, but in the case of composite mechanisms this OID MUST be 342 the OID of the leading component of the composite mechanism. 344 Note that this has implications for pluggable multi-mechanism 345 implementations of the GSS-API, namely that acceptors must route 346 initial context tokens to the appropriate mechanism and they must 347 allow that mechanism to determine the composite mechanism OID (such 348 as by allowing that mechanism's GSS_Accept_sec_context() to output 349 the actual mechanism to the application. 351 In all other cases the mechanism that produced or is to produce a 352 given token can be determined internally through the given security 353 context. 355 5. New GSS-API Interfaces 357 ... 359 Utility functions for mechanism OID composition and decomposition are 360 given in sections 5.1.1, 5.1.2 and 5.1.3. 362 Two utility functions, GSS_Indicate_negotiable_mechs() and 363 GSS_Negotiate_mechs(), to aid applications in mechanism negotiation 364 are described in sections 5.1.4 and 5.1.5. These two interfaces may 365 be implemented entirely in terms of the other interfaces described 366 herein. 368 5.1. New GSS-API Function Interfaces 370 Several new interfaces are given by which, for example, GSS-API 371 applications may determine what features are provided by a given 372 mechanism, what mechanisms provide what features and what 373 compositions are legal. 375 These new interfaces are all OPTIONAL. 377 In order to preserve backwards compatibility with applications that 378 do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate 379 support for any stackable pseduo-mechanisms. GSS_Indicate_mechs() 380 MAY indicate support for some, all or none of the available composite 381 mechanisms; which composite mechanisms, if any, are indicated through 382 GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and 383 GSS_Add_cred() MUST NOT create credentials for composite mechanisms 384 not explicitly requested or, if no desired mechanism or mechanisms 385 are given, for composite mechanisms not indicated by 386 GSS_Indicate_mechs(). 388 Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of 389 GSS_Indicate_mechs() wherever possible. 391 Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine 392 what, if any, mechanisms provide a given set of features. 394 GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as 395 in GSS_Indicate_mechs()) the set of available mechanisms of each type 396 (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo- 397 mechanism and composite mechanisms). 399 Applications may use GSS_Inquire_mech_attrs_for_mech() to test 400 whether a given composite mechanism is available and the set of 401 features that it offers. 403 GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms 404 such that composite mechanisms need not be advertised but instead be 405 implied by offering stackable pseudo-mechanisms. 407 5.1.1. GSS_Compose_oid() 409 Inputs: 410 o mech1 OBJECT IDENTIFIER, -- mechanism OID 411 o mech2 OBJECT IDENTIFIER -- mechanism OID 412 Outputs: 413 o major_status INTEGER, 414 o minor_status INTEGER, 415 o composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2 416 ({mech1 mech2}) 418 Return major_status codes: 419 o GSS_S_COMPLETE indicates success. 420 o GSS_S_BAD_MECH indicates that mech1 is not supported. 421 o GSS_S_FAILURE indicates that the request failed for some other 422 reason. The minor status will be specific to mech1 and may 423 provide further information. 425 5.1.2. GSS_Decompose_oid() 427 Inputs: 428 o input_mech OBJECT IDENTIFIER, -- mechanism OID. 429 o mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if 430 GSS_C_NULL_OID_SET defaults to the set of stackable pseudo- 431 mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()). 433 Outputs: 434 o major_status INTEGER, 435 o minor_status INTEGER, 436 o lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo- 437 mechanism OID. 438 o trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed 439 from the front. 441 Return major_status codes: 442 o GSS_S_COMPLETE indicates success. 443 o GSS_S_BAD_MECH indicates that the input_mech could not be 444 decomposed as no stackable pseudo-mechanism is available whose OID 445 is a prefix of the input_mech. 446 o GSS_S_FAILURE indicates that the request failed for some other 447 reason. 449 5.1.3. GSS_Release_oid() 451 The following text is adapted from the obsoleted rfc2078 [RFC2078]. 453 Inputs: 454 o oid OBJECT IDENTIFIER 456 Outputs: 457 o major_status INTEGER, 458 o minor_status INTEGER 459 Return major_status codes: 460 o GSS_S_COMPLETE indicates successful completion 461 o GSS_S_FAILURE indicates that the operation failed 463 Allows the caller to release the storage associated with an OBJECT 464 IDENTIFIER buffer allocated by another GSS-API call, specifically 465 GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific 466 behavior depends on the language and programming environment within 467 which a GSS-API implementation operates, and is therefore detailed 468 within applicable bindings specifications; in particular, this call 469 may be superfluous within bindings where memory management is 470 automatic. 472 5.1.4. GSS_Indicate_negotiable_mechs() 474 Inputs: 475 o input_cred_handle CREDENTIAL HANDLE, -- credential handle to be 476 used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL. 477 o peer_type_known BOOLEAN, -- indicates whether the peer is known to 478 support or not supprot the stackable pseudo-mechanism framework. 479 o peer_has_mech_stacking BOOLEAN -- indicates whether the peer 480 supports the stackable pseudo-mechanism framework; ignore if 481 peer_type_known is FALSE. 483 Outputs: 484 o major_status INTEGER, 485 o minor_status INTEGER, 486 o offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer. 488 Return major_status codes: 489 o GSS_S_COMPLETE indicates success. 490 o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are 491 expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no 492 credentials could be acquired for GSS_C_NO_NAME. 493 o GSS_S_FAILURE indicates that the request failed for some other 494 reason. 496 This function produces a set of mechanism OIDs, optimized for space, 497 that its caller should advertise to peers during mechanism 498 negotiation. 500 The output offer_mechs parameter will include all of the mechanisms 501 for which the input_cred_handle has elements (as indicated by 502 GSS_Inquire_cred()), but composite mechanisms will be included either 503 implicitly or implicitly as per the following rules: 504 o if peer_type_known is TRUE and peer_has_mech_stacking is FALSE 505 then no composite mechanisms not indicated by GSS_Indicate_mechs() 506 will be advertised, explictly or implicitly; 508 o if peer_type_known is FALSE then all composite mechanisms 509 indicated by GSS_Indicate_mechs() for which input_cred_handle has 510 elements will be indicated in offer_mechs explicitly and all 511 others may be indicated in offer_mechs implicitly, by including 512 their component stackable pseduo-mechanism OIDs (see below); 513 o if peer_type_known is TRUE and peer_has_mech_stacking is TRUE 514 composite mechanisms will generally not be advertised explicitly, 515 but will be advertised implicitly, by including their component 516 stackable pseduo-mechanism OIDs (see below); no composite 517 mechanisms will be advertised explicitly 518 o if the input_cred_handle does not have elements for all of the 519 possible composite mechanisms that could be constructed from the 520 its elements' decomposed mechanisms, then all composite mechanisms 521 for which the input_cred_handle does have elements will be 522 advertised explicitly in offer_mechs. 524 5.1.5. GSS_Negotiate_mechs() 526 Inputs: 527 o input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered 528 by the caller. 529 o peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the 530 caller's peer. 532 Outputs: 533 o major_status INTEGER, 534 o minor_status INTEGER, 535 o mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the 536 caller's credentials and the caller's peer. 538 Return major_status codes: 539 o GSS_S_COMPLETE indicates success; the output mechs parameter MAY 540 be the empty set (GSS_C_NO_OID_SET). 541 o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are 542 expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no 543 credentials could be acquired for GSS_C_NO_NAME. 544 o GSS_S_FAILURE indicates that the request failed for some other 545 reason. 547 This function matches the mechanisms for which the caller has 548 credentials with the mechanisms offered by the caller's peer and 549 returns the set of mechanisms in common to both, accounting for any 550 composite mechanisms offered by the peer implicitly. 552 5.1.6. C-Bindings 554 OM_uint32 gss_compose_oid( 555 OM_uint32 *minor_status, 556 const gss_OID mech1, 557 const gss_OID mech2, 558 gss_OID *composite); 560 OM_uint32 gss_decompose_oid( 561 OM_uint32 *minor_status, 562 const gss_OID input_mech, 563 const gss_OID_set mechs, 564 gss_OID *lead_mech, 565 gss_OID *trail_mech); 567 OM_uint32 gss_release_oid( 568 OM_uint32 *minor_status, 569 gss_OID *oid); 571 OM_uint32 gss_indicate_negotiable_mechs( 572 OM_uint32 *minor_status, 573 const gss_cred_id_t input_cred_handle, 574 OM_uint32 peer_type_known, 575 OM_uint32 peer_has_mech_stacking, 576 gss_OID_set *offer_mechs); 578 OM_uint32 gss_negotiate_mechs( 579 OM_uint32 *minor_status, 580 const gss_cred_id_t input_cred_handle, 581 const gss_OID_set peer_mechs, 582 const gss_OID_set *mechs); 584 Figure 1 586 6. Negotiation of Composite Mechanisms 588 Where GSS-API implementations do not support the stackable mechanism 589 framework interfaces applications may only negotiate explicitly from 590 a set of concrete and composite mechanism OIDs as indicated by 591 GSS_Indicate_mechs() and for which suitable credentials are 592 available. GSS_Indicate_mechs(), as described in Section 4.4, MUST 593 NOT indicate support for individual stackable pseudo-mechanisms, so 594 there will not be any composite mechanisms implied but not explicitly 595 offered in the mechanism negotiation. 597 Applications that support the stackable mechanism framework SHOULD 598 use GSS_Indicate_negotiable_mechs() to construct the set of mechanism 599 OIDs to offer to their peers. GSS_Indicate_negotiable_mechs() 600 optimizes for bandwidth consumption by using decomposed OIDs instead 601 of composed OIDs, where possible. See Section 5.1.4. 603 Peers that support the stackable mechanism framework interfaces 604 SHOULD use GSS_Negotiate_mechs() to select a mechanism as that 605 routine accounts for composite mechanisms implicit in the mechanism 606 offers. 608 6.1. Negotiation of Composite Mechanisms Through SPNEGO 610 SPNEGO applications MUST advertise either the set of mechanism OIDs 611 for which they have suitable credentials or the set of mechanism OIDs 612 produced by calling GSS_Indicate_negotiable_mechs() with the 613 available credentials and the peer_type_known parameter as FALSE. 615 7. Requirements for Mechanism Designers 617 Stackable pseudo-mechanisms specifications MUST: 618 o list the set of GSS-API mechanism attributes associated with them 619 o list their initial mechanism composition rules 620 o specify a mechanism for updating their mechanism composition rules 622 All other mechanism specifications MUST: 623 o list the set of GSS-API mechanism attributes associated with them 625 8. IANA Considerations 627 Allocation of arcs in the namespace of OIDs relative to the base 628 stackable pseduo-mechanism OID specified in Section 4.1 is reserved 629 to the IANA. 631 9. Security considerations 633 Some composite mechanisms may well not be secure. The mechanism 634 composition rules of pseudo-mechanisms (including the default 635 composition rule given in Section 4 for unknown mechanism attributes) 636 should be used to prevent the use of unsafe composite mechanisms. 638 Designers of pseudo-mechanisms should study the possible combinations 639 of their mechanisms with others and design mechanism composition 640 rules accordingly. 642 Similarly, pseudo-mechanism designers MUST specify, and implementors 643 MUST implement, composite mechanism attribute set determination rules 644 appropriate to the subject pseduo-mechanism, as described in section 645 4.2. Failure to do so may lead to inappropriate composite mechanisms 646 being deemed permissible by programmatic application of flawed 647 mechanism composition rules or to by their application with incorrect 648 mechanism attribute sets. 650 10. Normative 652 [EXTENDED-INQUIRY] 653 Williams, N., "Extended Generic Security Service Mechanism 654 Inquiry APIs", 655 draft-ietf-kitten-extended-mech-inquiry-00.txt (work in 656 progress). 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 [RFC2743] Linn, J., "Generic Security Service Application Program 662 Interface Version 2, Update 1", RFC 2743, January 2000. 664 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 665 C-bindings", RFC 2744, January 2000. 667 Author's Address 669 Nicolas Williams 670 Sun Microsystems 671 5300 Riata Trace Ct 672 Austin, TX 78727 673 US 675 Email: Nicolas.Williams@sun.com 677 Intellectual Property Statement 679 The IETF takes no position regarding the validity or scope of any 680 Intellectual Property Rights or other rights that might be claimed to 681 pertain to the implementation or use of the technology described in 682 this document or the extent to which any license under such rights 683 might or might not be available; nor does it represent that it has 684 made any independent effort to identify any such rights. Information 685 on the procedures with respect to rights in RFC documents can be 686 found in BCP 78 and BCP 79. 688 Copies of IPR disclosures made to the IETF Secretariat and any 689 assurances of licenses to be made available, or the result of an 690 attempt made to obtain a general license or permission for the use of 691 such proprietary rights by implementers or users of this 692 specification can be obtained from the IETF on-line IPR repository at 693 http://www.ietf.org/ipr. 695 The IETF invites any interested party to bring to its attention any 696 copyrights, patents or patent applications, or other proprietary 697 rights that may cover technology that may be required to implement 698 this standard. Please address the information to the IETF at 699 ietf-ipr@ietf.org. 701 Disclaimer of Validity 703 This document and the information contained herein are provided on an 704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 706 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 707 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 708 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Copyright Statement 713 Copyright (C) The Internet Society (2005). This document is subject 714 to the rights, licenses and restrictions contained in BCP 78, and 715 except as set forth therein, the authors retain all their rights. 717 Acknowledgment 719 Funding for the RFC Editor function is currently provided by the 720 Internet Society.