1 2 3 4NETWORK WORKING GROUP N. Williams 5Internet-Draft Sun 6Expires: April 19, 2006 October 16, 2005 7 8 9 Stackable Generic Security Service Pseudo-Mechanisms 10 draft-ietf-kitten-stackable-pseudo-mechs-01.txt 11 12Status of this Memo 13 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 23 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 28 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 31 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 35 This Internet-Draft will expire on April 19, 2006. 36 37Copyright Notice 38 39 Copyright (C) The Internet Society (2005). 40 41Abstract 42 43 This document defines and formalizes the concept of stackable pseudo- 44 mechanisms, and associated concept of composite mechanisms, for the 45 Generic Security Service Application Programming Interface (GSS-API), 46 as well as several utility functions. 47 48 Stackable GSS-API pseudo-mechanisms allow for the composition of new 49 mechanisms that combine features from multiple mechanisms. Stackable 50 mechanisms that add support for Perfect Forward Security (PFS), data 51 compression, additional authentication factors, etc... are 52 53 54 55Williams Expires April 19, 2006 [Page 1] 56 57Internet-Draft Stackable GSS Mechs October 2005 58 59 60 facilitated by this document. 61 62 63Table of Contents 64 65 1. Conventions used in this document . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Mechanism Composition Issues . . . . . . . . . . . . . . . 4 69 4. Mechanism Composition . . . . . . . . . . . . . . . . . . 5 70 4.1. Construction of Composed Mechanism OIDs . . . . . . . . . 5 71 4.2. Mechanism Composition Rules . . . . . . . . . . . . . . . 6 72 4.3. Interfacing with Composite Mechanisms . . . . . . . . . . 7 73 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces . . . 7 74 4.5. Processing of Tokens for Composite Mechanisms . . . . . . 8 75 5. New GSS-API Interfaces . . . . . . . . . . . . . . . . . . 8 76 5.1. New GSS-API Function Interfaces . . . . . . . . . . . . . 9 77 5.1.1. GSS_Compose_oid() . . . . . . . . . . . . . . . . . . . . 9 78 5.1.2. GSS_Decompose_oid() . . . . . . . . . . . . . . . . . . . 10 79 5.1.3. GSS_Release_oid() . . . . . . . . . . . . . . . . . . . . 10 80 5.1.4. GSS_Indicate_negotiable_mechs() . . . . . . . . . . . . . 11 81 5.1.5. GSS_Negotiate_mechs() . . . . . . . . . . . . . . . . . . 12 82 5.1.6. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 83 6. Negotiation of Composite Mechanisms . . . . . . . . . . . 13 84 6.1. Negotiation of Composite Mechanisms Through SPNEGO . . . . 14 85 7. Requirements for Mechanism Designers . . . . . . . . . . . 14 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 87 9. Security considerations . . . . . . . . . . . . . . . . . 14 88 10. Normative . . . . . . . . . . . . . . . . . . . . . . . . 15 89 Author's Address . . . . . . . . . . . . . . . . . . . . . 16 90 Intellectual Property and Copyright Statements . . . . . . 17 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Williams Expires April 19, 2006 [Page 2] 112 113Internet-Draft Stackable GSS Mechs October 2005 114 115 1161. Conventions used in this document 117 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 121 122 1232. Introduction 124 125 Recent discussions within the IETF have shown the need for a 126 refactoring of the features that GSS-API mechanisms may provide and a 127 way to compose new mechanisms from smaller components. 128 129 One way to do this is to "stack" multiple mechanisms on top of each 130 other such that the features of all of them are summed into a new, 131 composite mechanism. 132 133 One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially 134 stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not 135 conform to the stackable pseduo-mechanism framework described 136 herein). 137 138 The first truly stackable pseudo-mechanism proposed, CCM [CCM], is 139 intended for signalling, during negotiation of mechanisms, the 140 willingness of an initiator and/or acceptor to utilize channel 141 bindings 142 143 Since then other similar mechanism compositing needs and ideas have 144 come up, along with problems such as "what combinations are possible, 145 useful, reasonable and secure?" This document addresses those 146 problems. It introduces the concepts of stackable pseudo-mechanisms, 147 composite mechanisms and mechanism features or attributes, as well as 148 new inquiry and related interfaces to help in the mechanism 149 compositing. 150 151 (Mechanism features are more formally referred to as "mechanism 152 attributes" below. The terms "feature" and mechanism attribute" are 153 sometimes used interchangeably.) 154 1552.1. Glossary 156 157 Concrete GSS-API mechanism 158 A mechanism which can be used standalone. Examples include: the 159 Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY]. 160 161 GSS-API Pseudo-mechanism 162 A mechanism which uses other mechanisms in the construction of its 163 context and/or per-message tokens and security contexts. SPNEGO 164 165 166 167Williams Expires April 19, 2006 [Page 3] 168 169Internet-Draft Stackable GSS Mechs October 2005 170 171 172 is an example of this. 173 174 Stackable GSS-API pseudo-mechanism 175 A mechanism which uses a single other mechanism in the 176 construction of its tokens such that the OID of the composite 177 result can be constructed by prepending the OID of the stackable 178 pseudo-mechanism to the OID of the mechanism to be used by it. 179 180 Mechanism-negotiation GSS-API pseudo-mechanism 181 A GSS-API mechanism that negotiates the use of GSS-API mechanisms. 182 SPNEGO [SPNEGO] is an example of this. 183 184 1853. Mechanism Composition Issues 186 187 Interfacing with composite mechanisms through the existing GSS-API 188 interfaces and the handling of composite mechanism tokens is 189 straightforward enough and described in Section 4. 190 191 However, the concepts of stackable and composite mechanisms do give 192 rise to several minor problems: 193 194 o How to determine allowable combinations of mechanisms; 195 o How to encode composite mechanism OIDs; 196 o How to decompose the OID of a composite mechanism and process its 197 tokens properly; 198 o Application interfacing issues such as: 199 200 * Whether and/or which composite mechanisms should be listed by 201 GSS_Indicate_mechs(); 202 * Whether and/or which composite mechanisms not listed by 203 GSS_Indicate_mechs() may nonetheless be available for use by 204 applications and how applications can detect their 205 availability; 206 * What additional, if any, interfaces should be provided to help 207 applications select appropriate mechanisms; 208 o 209 210 Mechanism negotiation issues (related to the application interface 211 issues listed above), such as: vspace blankLines='1'/> 212 * Should applications advertise composite mechanisms in SPNEGO or 213 other application-specific mechanism negotiation contexts? 214 * Or should applications implicitly advertise composite 215 mechanisms by advertising concrete and stackable pseudo- 216 mechanisms in SPNEGO or other application-specific mechanism 217 negotiation contexts? 218 219 Section 4 addresses the OID composition, decomposition and encoding 220 221 222 223Williams Expires April 19, 2006 [Page 4] 224 225Internet-Draft Stackable GSS Mechs October 2005 226 227 228 issues, as well as basic interfacing and token handling issues. 229 230 Section 5 addresses interfacing issues more generally through the 231 specification of additional, optional APIs. 232 233 Section 6 addresses mechanism negotiation issues. 234 235 2364. Mechanism Composition 237 238 Mechanism composition by stacking pseudo-mechanisms on a concrete 239 mechanism is conceptually simple: join the OIDs of the several 240 mechanisms in question and process GSS-API tokens and routine calls 241 through the top-most pseudo-mechanism in a stack, which can then, if 242 necessary, recursively call the GSS-API to process any tokens for the 243 remainder of the stack. 244 245 Some stackable pseudo-mechanisms may do nothing more than perform 246 transformations on application data (e.g., compression); such pseudo- 247 mechanisms will generally chain the processing of tokens and routine 248 calls to the mechanisms below them in the stack. 249 250 Other stackable pseudo-mechanisms may utilize the mechanisms below 251 them only during security context setup. For example, a stackable 252 pseudo-mechanism could perform a Diffie-Hellman key exchange and 253 authenticate it by binding a security context established with the 254 mechanism stacked below it; such a mechanism would provide its own 255 per-message tokens. 256 2574.1. Construction of Composed Mechanism OIDs 258 259 Composition of mechanism OIDs is simple: prepend the OID of one 260 pseudo-mechanism to the OID of another mechanism (composite or 261 otherwise), but there MUST always be at least one final mechanism OID 262 and it MUST be useful standalone (i.e., it MUST NOT be a pseudo- 263 mechanism). A composite mechanism OID forms, essentially, a stack. 264 265 The encoding of composed mechanism OIDs is not quite the 266 concatenation of the component OIDs' encodings, however. This is 267 because the first two arcs of ASN.1 OIDs are encoded differently from 268 subsequent arcs (the first two arcs have a limited namespace and are 269 encoded as a single octet), so were composite mechanism OIDs to be 270 encoded as the concatenation of the component OIDs the result would 271 not decode as the concatenation of the component OIDs. To avoid this 272 problem the first two arcs of each component of a composite mechanism 273 OID, other than the leading component, will be encoded as other arcs 274 would. 275 276 277 278 279Williams Expires April 19, 2006 [Page 5] 280 281Internet-Draft Stackable GSS Mechs October 2005 282 283 284 Decomposition of composite mechanism OIDs is similar, with each 285 pseudo-mechanism in the stack being able to determine the OID suffix 286 from knowledge of its own OID(s). 287 288 New pseudo-mechanisms MAY be allocated OIDs from the prefix given 289 below as follows by assignment of a sub-string of OID arcs to be 290 appended to this prefix. This prefix OID is: 291 292 <TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA 293 TBD] 294 295 All OID allocations below this OID MUST be for stackable pseudo- 296 mechanisms and MUST consist of a single arc. This will make it 297 possible to decompose the OIDs of composite mechanisms without 298 necessarily knowing a priori the OIDs of the component stackable 299 pseudo-mechanisms. 300 3014.2. Mechanism Composition Rules 302 303 All new stackable pseudo-mechanisms MUST specify the rules for 304 determining whether they can stack above a given mechanism, composite 305 or otherwise. Such rules may be based on specific mechanism 306 attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs 307 (composite and otherwise). 308 309 All stackable pseudo-mechanisms MUST have the following mechanism 310 composition rule relating to unknown mechanism attributes: 311 312 o composition with mechanisms supporting unknown mechanism 313 attributes MUST NOT be permitted. 314 315 This rule protects against compositions which cannot be considered 316 today but which might nonetheless arise due to the introduction of 317 new mechanisms and which might turn out to be insecure or otherwise 318 undesirable. 319 320 Mechanism composition rules for stackable pseudo-mechanisms MAY and 321 SHOULD be updated as new GSS-API mechanism attributes and mechanisms 322 sporting them are introduced. The specifications of mechanisms that 323 introduce new mechanism attributes or which otherwise should not be 324 combined with others in ways which would be permitted under existing 325 rules SHOULD also update the mechanism composition rules of affected 326 pseudo-mechanisms. 327 328 A RECOMMENDED way to describe the stacking rules for stackable 329 mechanisms is as an ordered sequence of "MAY stack above X 330 mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above 331 Z mechanism," and/or "MUST NOT stack above a mechanism with Z 332 333 334 335Williams Expires April 19, 2006 [Page 6] 336 337Internet-Draft Stackable GSS Mechs October 2005 338 339 340 mechanism feature(s)." 341 342 For example a stackable mechanism that provides its own per-msg 343 tokens and does not use the underlying mechnism's per-msg token 344 facilities might require a rule such as "MUST NOT stack above a 345 mechanism with the GSS_C_MA_COMPRESS mechanism feature." 346 3474.3. Interfacing with Composite Mechanisms 348 349 The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or 350 provide as output the OID of any stackable pseudo-mechanism. 351 Composite mechanisms MUST be treated as concrete mechanisms by the 352 basic GSS-API interfaces [RFC2743]. 353 354 Thus the way in which a composite mechanism is used by applications 355 with the basic GSS-API (version 2, update 1) is straightforward: 356 exactly as if composite mechanisms were normal GSS-API mechanisms. 357 358 This is facilitated by the fact that in all cases where the GSS-API 359 implementation might need to know how to process or create a token it 360 has the necessary contextual information, that is, the mechanism OID, 361 available and can decompose composite mechanism OIDs as necessary. 362 363 For example, for initial GSS_Init_sec_context() calls the 364 implementation knows the desired mechanism OID, and if it should be 365 left unspecified, it can pick a default mechanism given the initiator 366 credentials provided by the application (and if none are provided 367 other default mechanism and credential selections can still be made). 368 For subsequent calls to GSS_Init_sec_context() the implementation 369 knows which mechanism to use from the given [partially established] 370 security context. Similarly for GSS_Accept_sec_context, where on 371 initial calls the mechanism OID can be determined from the given 372 initial context token's framing. 373 374 The manner in which GSS-API implementations and the various 375 mechanisms and pseudo-mechanisms interface with one another is left 376 as an excercise to implementors. 377 3784.4. Compatibility with the Basic GSS-APIv2u1 Interfaces 379 380 In order to preserve backwards compatibility with applications that 381 use only the basic GSS-API interfaces (version 2, update 1), several 382 restrictions are imposed on the use of composite and stackable 383 pseduo-mechanisms with the basic GSS-API interfaces: 384 385 o GSS_Indicate_mechs() MUST NOT indicate support for any stackable 386 pseduo-mechanisms under any circumstance. 387 o GSS_Indicate_mechs() MAY indicate support for some, all or none of 388 389 390 391Williams Expires April 19, 2006 [Page 7] 392 393Internet-Draft Stackable GSS Mechs October 2005 394 395 396 the available composite mechanisms. 397 o Which composite mechanisms, if any, are indicated through 398 GSS_Indicate_mechs() SHOULD be configurable. 399 o Composite mechanisms which are not indicated by 400 GSS_Indicate_mechs() MUST NOT be considered as the default 401 mechanism (GSS_C_NULL_OID) or as part of the default mechanism set 402 (GSS_C_NULL_OID_SET). 403 o The OIDs of *stackable* (not composite) pseudo-mechanisms MUST NOT 404 be accepted as inputs or produced in the output of any of the 405 basic GSS-APIv2, update 1 API functions, except for any OID set 406 construction/iteration functions. And, if present in any OID SET 407 input parameters of GSS-APIv2, update 1 functions, they MUST be 408 ignored. 409 o The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only 410 be used as inputs or produced as outputs of functions whose 411 specification explicitly allows for them or which are concerned 412 with the creation/iteration of OID containters, such as OID SETs. 413 4144.5. Processing of Tokens for Composite Mechanisms 415 416 The initial context token for any standard mechanism, including 417 mechanisms composited from standard pseudo- and concrete mechanisms, 418 MUST be encapsulated as described in section 3.1 of rfc2743 419 [RFC2743], and the OID used in that framing MUST be that of the 420 mechanism, but in the case of composite mechanisms this OID MUST be 421 the OID of the leading component of the composite mechanism. 422 423 Note that this has implications for pluggable multi-mechanism 424 implementations of the GSS-API, namely that acceptors must route 425 initial context tokens to the appropriate mechanism and they must 426 allow that mechanism to determine the composite mechanism OID (such 427 as by allowing that mechanism's GSS_Accept_sec_context() to output 428 the actual mechanism to the application. 429 430 In all other cases the mechanism that produced or is to produce a 431 given token can be determined internally through the given security 432 context. 433 434 4355. New GSS-API Interfaces 436 437 ... 438 439 Utility functions for mechanism OID composition and decomposition are 440 given in sections 5.1.1, 5.1.2 and 5.1.3. 441 442 Two utility functions, GSS_Indicate_negotiable_mechs() and 443 GSS_Negotiate_mechs(), to aid applications in mechanism negotiation 444 445 446 447Williams Expires April 19, 2006 [Page 8] 448 449Internet-Draft Stackable GSS Mechs October 2005 450 451 452 are described in sections 5.1.4 and 5.1.5. These two interfaces may 453 be implemented entirely in terms of the other interfaces described 454 herein. 455 4565.1. New GSS-API Function Interfaces 457 458 Several new interfaces are given by which, for example, GSS-API 459 applications may determine what features are provided by a given 460 mechanism, what mechanisms provide what features and what 461 compositions are legal. 462 463 These new interfaces are all OPTIONAL. 464 465 In order to preserve backwards compatibility with applications that 466 do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate 467 support for any stackable pseduo-mechanisms. GSS_Indicate_mechs() 468 MAY indicate support for some, all or none of the available composite 469 mechanisms; which composite mechanisms, if any, are indicated through 470 GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and 471 GSS_Add_cred() MUST NOT create credentials for composite mechanisms 472 not explicitly requested or, if no desired mechanism or mechanisms 473 are given, for composite mechanisms not indicated by 474 GSS_Indicate_mechs(). 475 476 Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of 477 GSS_Indicate_mechs() wherever possible. 478 479 Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine 480 what, if any, mechanisms provide a given set of features. 481 482 GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as 483 in GSS_Indicate_mechs()) the set of available mechanisms of each type 484 (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo- 485 mechanism and composite mechanisms). 486 487 Applications may use GSS_Inquire_mech_attrs_for_mech() to test 488 whether a given composite mechanism is available and the set of 489 features that it offers. 490 491 GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms 492 such that composite mechanisms need not be advertised but instead be 493 implied by offering stackable pseudo-mechanisms. 494 4955.1.1. GSS_Compose_oid() 496 497 Inputs: 498 o mech1 OBJECT IDENTIFIER, -- mechanism OID 499 o mech2 OBJECT IDENTIFIER -- mechanism OID 500 501 502 503Williams Expires April 19, 2006 [Page 9] 504 505Internet-Draft Stackable GSS Mechs October 2005 506 507 508 Outputs: 509 o major_status INTEGER, 510 o minor_status INTEGER, 511 o composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2 512 ({mech1 mech2}) 513 514 Return major_status codes: 515 o GSS_S_COMPLETE indicates success. 516 o GSS_S_BAD_MECH indicates that mech1 is not supported. 517 o GSS_S_FAILURE indicates that the request failed for some other 518 reason. The minor status will be specific to mech1 and may 519 provide further information. 520 5215.1.2. GSS_Decompose_oid() 522 523 Inputs: 524 o input_mech OBJECT IDENTIFIER, -- mechanism OID. 525 o mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if 526 GSS_C_NULL_OID_SET defaults to the set of stackable pseudo- 527 mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()). 528 529 Outputs: 530 o major_status INTEGER, 531 o minor_status INTEGER, 532 o lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo- 533 mechanism OID. 534 o trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed 535 from the front. 536 537 Return major_status codes: 538 o GSS_S_COMPLETE indicates success. 539 o GSS_S_BAD_MECH indicates that the input_mech could not be 540 decomposed as no stackable pseudo-mechanism is available whose OID 541 is a prefix of the input_mech. 542 o GSS_S_FAILURE indicates that the request failed for some other 543 reason. 544 5455.1.3. GSS_Release_oid() 546 547 The following text is adapted from the obsoleted rfc2078 [RFC2078]. 548 549 Inputs: 550 o oid OBJECT IDENTIFIER 551 552 Outputs: 553 o major_status INTEGER, 554 o minor_status INTEGER 555 556 557 558 559Williams Expires April 19, 2006 [Page 10] 560 561Internet-Draft Stackable GSS Mechs October 2005 562 563 564 Return major_status codes: 565 o GSS_S_COMPLETE indicates successful completion 566 o GSS_S_FAILURE indicates that the operation failed 567 568 Allows the caller to release the storage associated with an OBJECT 569 IDENTIFIER buffer allocated by another GSS-API call, specifically 570 GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific 571 behavior depends on the language and programming environment within 572 which a GSS-API implementation operates, and is therefore detailed 573 within applicable bindings specifications; in particular, this call 574 may be superfluous within bindings where memory management is 575 automatic. 576 5775.1.4. GSS_Indicate_negotiable_mechs() 578 579 Inputs: 580 o input_cred_handle CREDENTIAL HANDLE, -- credential handle to be 581 used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL. 582 o peer_type_known BOOLEAN, -- indicates whether the peer is known to 583 support or not supprot the stackable pseudo-mechanism framework. 584 o peer_has_mech_stacking BOOLEAN -- indicates whether the peer 585 supports the stackable pseudo-mechanism framework; ignore if 586 peer_type_known is FALSE. 587 588 Outputs: 589 o major_status INTEGER, 590 o minor_status INTEGER, 591 o offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer. 592 593 Return major_status codes: 594 o GSS_S_COMPLETE indicates success. 595 o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are 596 expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no 597 credentials could be acquired for GSS_C_NO_NAME. 598 o GSS_S_FAILURE indicates that the request failed for some other 599 reason. 600 601 This function produces a set of mechanism OIDs, optimized for space, 602 that its caller should advertise to peers during mechanism 603 negotiation. 604 605 The output offer_mechs parameter will include all of the mechanisms 606 for which the input_cred_handle has elements (as indicated by 607 GSS_Inquire_cred()), but composite mechanisms will be included either 608 implicitly or implicitly as per the following rules: 609 o if peer_type_known is TRUE and peer_has_mech_stacking is FALSE 610 then no composite mechanisms not indicated by GSS_Indicate_mechs() 611 will be advertised, explictly or implicitly; 612 613 614 615Williams Expires April 19, 2006 [Page 11] 616 617Internet-Draft Stackable GSS Mechs October 2005 618 619 620 o if peer_type_known is FALSE then all composite mechanisms 621 indicated by GSS_Indicate_mechs() for which input_cred_handle has 622 elements will be indicated in offer_mechs explicitly and all 623 others may be indicated in offer_mechs implicitly, by including 624 their component stackable pseduo-mechanism OIDs (see below); 625 o if peer_type_known is TRUE and peer_has_mech_stacking is TRUE 626 composite mechanisms will generally not be advertised explicitly, 627 but will be advertised implicitly, by including their component 628 stackable pseduo-mechanism OIDs (see below); no composite 629 mechanisms will be advertised explicitly 630 o if the input_cred_handle does not have elements for all of the 631 possible composite mechanisms that could be constructed from the 632 its elements' decomposed mechanisms, then all composite mechanisms 633 for which the input_cred_handle does have elements will be 634 advertised explicitly in offer_mechs. 635 6365.1.5. GSS_Negotiate_mechs() 637 638 Inputs: 639 o input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered 640 by the caller. 641 o peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the 642 caller's peer. 643 644 Outputs: 645 o major_status INTEGER, 646 o minor_status INTEGER, 647 o mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the 648 caller's credentials and the caller's peer. 649 650 Return major_status codes: 651 o GSS_S_COMPLETE indicates success; the output mechs parameter MAY 652 be the empty set (GSS_C_NO_OID_SET). 653 o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are 654 expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no 655 credentials could be acquired for GSS_C_NO_NAME. 656 o GSS_S_FAILURE indicates that the request failed for some other 657 reason. 658 659 This function matches the mechanisms for which the caller has 660 credentials with the mechanisms offered by the caller's peer and 661 returns the set of mechanisms in common to both, accounting for any 662 composite mechanisms offered by the peer implicitly. 663 6645.1.6. C-Bindings 665 666 667 OM_uint32 gss_compose_oid( 668 669 670 671Williams Expires April 19, 2006 [Page 12] 672 673Internet-Draft Stackable GSS Mechs October 2005 674 675 676 OM_uint32 *minor_status, 677 const gss_OID mech1, 678 const gss_OID mech2, 679 gss_OID *composite); 680 681 OM_uint32 gss_decompose_oid( 682 OM_uint32 *minor_status, 683 const gss_OID input_mech, 684 const gss_OID_set mechs, 685 gss_OID *lead_mech, 686 gss_OID *trail_mech); 687 688 OM_uint32 gss_release_oid( 689 OM_uint32 *minor_status, 690 gss_OID *oid); 691 692 OM_uint32 gss_indicate_negotiable_mechs( 693 OM_uint32 *minor_status, 694 const gss_cred_id_t input_cred_handle, 695 OM_uint32 peer_type_known, 696 OM_uint32 peer_has_mech_stacking, 697 gss_OID_set *offer_mechs); 698 699 OM_uint32 gss_negotiate_mechs( 700 OM_uint32 *minor_status, 701 const gss_cred_id_t input_cred_handle, 702 const gss_OID_set peer_mechs, 703 const gss_OID_set *mechs); 704 705 706 Figure 1 707 708 7096. Negotiation of Composite Mechanisms 710 711 Where GSS-API implementations do not support the stackable mechanism 712 framework interfaces applications may only negotiate explicitly from 713 a set of concrete and composite mechanism OIDs as indicated by 714 GSS_Indicate_mechs() and for which suitable credentials are 715 available. GSS_Indicate_mechs(), as described in Section 4.4, MUST 716 NOT indicate support for individual stackable pseudo-mechanisms, so 717 there will not be any composite mechanisms implied but not explicitly 718 offered in the mechanism negotiation. 719 720 Applications that support the stackable mechanism framework SHOULD 721 use GSS_Indicate_negotiable_mechs() to construct the set of mechanism 722 OIDs to offer to their peers. GSS_Indicate_negotiable_mechs() 723 optimizes for bandwidth consumption by using decomposed OIDs instead 724 725 726 727Williams Expires April 19, 2006 [Page 13] 728 729Internet-Draft Stackable GSS Mechs October 2005 730 731 732 of composed OIDs, where possible. See Section 5.1.4. 733 734 Peers that support the stackable mechanism framework interfaces 735 SHOULD use GSS_Negotiate_mechs() to select a mechanism as that 736 routine accounts for composite mechanisms implicit in the mechanism 737 offers. 738 7396.1. Negotiation of Composite Mechanisms Through SPNEGO 740 741 SPNEGO applications MUST advertise either the set of mechanism OIDs 742 for which they have suitable credentials or the set of mechanism OIDs 743 produced by calling GSS_Indicate_negotiable_mechs() with the 744 available credentials and the peer_type_known parameter as FALSE. 745 746 7477. Requirements for Mechanism Designers 748 749 Stackable pseudo-mechanisms specifications MUST: 750 o list the set of GSS-API mechanism attributes associated with them 751 o list their initial mechanism composition rules 752 o specify a mechanism for updating their mechanism composition rules 753 754 All other mechanism specifications MUST: 755 o list the set of GSS-API mechanism attributes associated with them 756 757 7588. IANA Considerations 759 760 Allocation of arcs in the namespace of OIDs relative to the base 761 stackable pseduo-mechanism OID specified in Section 4.1 is reserved 762 to the IANA. 763 764 7659. Security considerations 766 767 Some composite mechanisms may well not be secure. The mechanism 768 composition rules of pseudo-mechanisms (including the default 769 composition rule given in Section 4 for unknown mechanism attributes) 770 should be used to prevent the use of unsafe composite mechanisms. 771 772 Designers of pseudo-mechanisms should study the possible combinations 773 of their mechanisms with others and design mechanism composition 774 rules accordingly. 775 776 Similarly, pseudo-mechanism designers MUST specify, and implementors 777 MUST implement, composite mechanism attribute set determination rules 778 appropriate to the subject pseduo-mechanism, as described in section 779 4.2. Failure to do so may lead to inappropriate composite mechanisms 780 781 782 783Williams Expires April 19, 2006 [Page 14] 784 785Internet-Draft Stackable GSS Mechs October 2005 786 787 788 being deemed permissible by programmatic application of flawed 789 mechanism composition rules or to by their application with incorrect 790 mechanism attribute sets. 791 79210. Normative 793 794 [EXTENDED-INQUIRY] 795 Williams, N., "Extended Generic Security Service Mechanism 796 Inquiry APIs", 797 draft-ietf-kitten-extended-mech-inquiry-00.txt (work in 798 progress). 799 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 803 [RFC2743] Linn, J., "Generic Security Service Application Program 804 Interface Version 2, Update 1", RFC 2743, January 2000. 805 806 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 807 C-bindings", RFC 2744, January 2000. 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839Williams Expires April 19, 2006 [Page 15] 840 841Internet-Draft Stackable GSS Mechs October 2005 842 843 844Author's Address 845 846 Nicolas Williams 847 Sun Microsystems 848 5300 Riata Trace Ct 849 Austin, TX 78727 850 US 851 852 Email: Nicolas.Williams@sun.com 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895Williams Expires April 19, 2006 [Page 16] 896 897Internet-Draft Stackable GSS Mechs October 2005 898 899 900Intellectual Property Statement 901 902 The IETF takes no position regarding the validity or scope of any 903 Intellectual Property Rights or other rights that might be claimed to 904 pertain to the implementation or use of the technology described in 905 this document or the extent to which any license under such rights 906 might or might not be available; nor does it represent that it has 907 made any independent effort to identify any such rights. Information 908 on the procedures with respect to rights in RFC documents can be 909 found in BCP 78 and BCP 79. 910 911 Copies of IPR disclosures made to the IETF Secretariat and any 912 assurances of licenses to be made available, or the result of an 913 attempt made to obtain a general license or permission for the use of 914 such proprietary rights by implementers or users of this 915 specification can be obtained from the IETF on-line IPR repository at 916 http://www.ietf.org/ipr. 917 918 The IETF invites any interested party to bring to its attention any 919 copyrights, patents or patent applications, or other proprietary 920 rights that may cover technology that may be required to implement 921 this standard. Please address the information to the IETF at 922 ietf-ipr@ietf.org. 923 924 925Disclaimer of Validity 926 927 This document and the information contained herein are provided on an 928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 930 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 931 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 932 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 934 935 936Copyright Statement 937 938 Copyright (C) The Internet Society (2005). This document is subject 939 to the rights, licenses and restrictions contained in BCP 78, and 940 except as set forth therein, the authors retain all their rights. 941 942 943Acknowledgment 944 945 Funding for the RFC Editor function is currently provided by the 946 Internet Society. 947 948 949 950 951Williams Expires April 19, 2006 [Page 17] 952 953 954