idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-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 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 802. ** 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 -- 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 14, 2005) is 6741 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) == Outdated reference: A later version (-05) exists of draft-ietf-kitten-gss-naming-01 ** Downref: Normative reference to an Informational draft: draft-ietf-kitten-gss-naming (ref. 'I-D.GSS-NAMING') ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 17, 2006 October 14, 2005 6 GSS-API Naming Extensions 7 draft-ietf-kitten-gssapi-naming-exts-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 17, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The Generic Security Services API (GSS-API) provides a simple naming 41 architecture that supports name-based authorization. This document 42 introduces new APIs that extend the GSS-API naming and authorization 43 model. 45 Table of Contents 47 1. Conventions used in this document . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Name Attribute Sources and Criticality . . . . . . . . . . 3 50 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 51 5. Mapping Mechanism Facilities to Name Attributes . . . . . 4 52 5.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 4 53 5.2. Kerberos V Cross-Realm Transit Paths . . . . . . . . . . . 5 54 5.3. PKIX Certificate Extensions . . . . . . . . . . . . . . . 5 55 5.3.1. PKIX EKUs . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5.3.2. PKIX Certificate Alternative Names . . . . . . . . . . . . 6 57 5.3.3. Other PKIX Certificate Extensions and Attributes . . . . . 6 58 5.4. PKIX Certificate CA Paths and Trust Anchors . . . . . . . 6 59 6. GSS_Inquire_name_attribute() . . . . . . . . . . . . . . . 6 60 6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 8 62 7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 9 64 8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 10 66 9.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 11 68 10.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 69 11. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 12 70 11.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 71 12. GSS_Export_name_composite() . . . . . . . . . . . . . . . 13 72 12.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 73 13. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 14 74 13.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15 75 14. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 15 76 14.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 16 77 15. IANA Considerations . . . . . . . . . . . . . . . . . . . 16 78 16. Security Considerations . . . . . . . . . . . . . . . . . 17 79 17. Normative References . . . . . . . . . . . . . . . . . . . 17 80 Author's Address . . . . . . . . . . . . . . . . . . . . . 18 81 Intellectual Property and Copyright Statements . . . . . . 19 83 1. Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 As described in [I-D.GSS-NAMING] the GSS-API's naming architecture 92 suffers from certain limitations. This document proposes concrete 93 GSS-API extensions as outlined in [I-D.GSS-NAMING]. 95 A number of extensions to the GSS-API [RFC2743] and its C Bindings 96 [RFC2744] are described herein with the goal of making authorization 97 information, and other information that can be modelled as "name 98 attributes" available as such to applications. For example, Kerberos 99 V authorization data elements, both, in their raw forms as well as 100 mapped to more useful value types, can be made available to GSS-API 101 applications through these interfaces. 103 The model is that GSS names have attributes. The attributes of a 104 name may be authenticated by the credential whence the name comes, or 105 may have been set locally on a GSS name for the purpose of 106 "asserting" the attribute during credential acquisition or security 107 context exchange. Name attributes' values are network 108 representations thereof (e.g., the actual value octets of the 109 contents of an X.509 certificate extension, for example) and are 110 intended to be useful for constructing portable access control 111 facilities. Applications may often require language- or platform- 112 specific data types, rather than network representations of name 113 attributes, so a function is provided to obtain objects of such types 114 associated with names and name attributes. 116 3. Name Attribute Sources and Criticality 118 A given GSS name object's name attributes may be authenticated or 119 asserted by an associated credential, or it may be mapped or derived 120 from another attribute of the same name. 122 That a given name's given attribute is 'mapped' means that it was 123 obtained through some mapping mechanism applied to another attribute 124 of the name that was not, itself, mapped. For example, such 125 attributes as platform-specific internal identifiers may sometimes be 126 mapped from other name attributes. 128 Name attributes may be "critical," meaning that applications that do 129 not understand them MUST reject security contexts where the peer has 130 such unknown, critical attributes. 132 4. Name Attributes/Values as ACL Subjects 134 Some name attributes (e.g., numeric user or group identifiers) may be 135 useful as subjects of access control list (ACL) entries, some may not 136 (e.g., time of day login restrictions). The 137 GSS_Inquire_name_attribute() function indicates this. 139 To facilitate the development of portable applications that make use 140 of name attributes to construct and evaluate portable ACLs the GSS- 141 API makes name attribute values available in canonical network 142 encodings thereof. 144 To facilitate the development of platform- or language-specific 145 applications that need access to native types of representations of 146 name attributes an optional facility is provided, 147 GSS_Map_name_to_any(). 149 5. Mapping Mechanism Facilities to Name Attributes 151 [NOTE: This entire section should probably be split into one or more 152 separate Internet-Drafts. It is here in the -00 of this I-D to help 153 readers understand how to mechanism-specific name attributes would be 154 accessed through these GSS-API extensions.] 156 Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple 157 Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the 158 concept and encoding of containers of "authorization-data" as 159 described in [I-D.ietf-krb-wg-kerberos-clarifications]. 161 PKIX [RFC3280] supports a number of authorization-data-like features, 162 like Extended Key Usage values (EKUs) and certificate extensions. 164 The authorization data can be accessed through the GSS-API name 165 attributes facility defined herein. 167 5.1. Kerberos V and SPKM Authorization-Data 169 Authorization-data non-container elements asserted in Kerberos V AP- 170 REQ Authenticators MUST be mapped into *asserted* GSS-API name 171 attributes; if not contained in AD-IF-RELEVANT then they MUST be 172 mapped into *critical* GSS-API name attributes. AD-AND-OR 173 authorization-data elements MUST be mapped into a single *critical* 174 attribute, (TBD). 176 Authorization-data included in Kerberos V Tickets that is not 177 contained in AD-KDCIssued (with valid signature) MUST be mapped into 178 *asserted* GSS-API name attributes. Conversely, authorization-data 179 elements in Kerberos V Tickets contained by AD-KDCIssued MUST be 180 mapped into *authenticated* GSS-API name attributes 182 As with authorization-data elements in Authenticators, authorization- 183 data elements in Tickets not contained in AD-IF-RELEVANT are to be 184 mapped to *critical* name attributes, and similarly with AD-AND-OR 185 (see above). 187 The OIDs for authorization-data elements are to be the authorization- 188 data element's 'ad-type' integer ID, relative to the base OID 189 [NOTE: what about negative ad-type's? OID arcs are positive 190 integers... ad-type is an Int32, so clearly something can be done.] 192 5.2. Kerberos V Cross-Realm Transit Paths 194 [Add text on how to represent/encode/interpret krb5 realm transit 195 paths as name attribute values. And text on PKINIT too... Basically 196 Ticket's 'transited' field should be exposed as an authenticated name 197 attribute, with some uncompressed encoding, possibly encompassing 198 certificate validation paths of client certs used for PKINIT, with 199 criticality determined by the presence of the transit-policy-checked 200 flag.] 202 5.3. PKIX Certificate Extensions 204 [NOTE: In the Kerberos V authorization-data case we can tell when AD 205 elements are "authenticated" and when the are asserted, but what 206 about x.509 certificate extensions? Clearly KU, EKUs and 207 subjectAltNames are authenticated in that no CA should sign a cert 208 with, say, arbitrary subjectAltNames not understood by the CA, but, 209 does that also apply to all other x.509 certificate extensions? The 210 answer may depend on actual CA operator practices... At worst a new 211 extension may be needed, like Kerberos V's AD-KDCIssued AD container 212 element; at best this text can just say "all cert extensions MUST be 213 mapped to authenticated..." below.] 215 PKI certificate extensions MAY/SHOULD/MUST (see comment above) be 216 mapped to *authenticated* GSS-API name attributes with the _same_ 217 OIDs, and if they be marked critical in the certificate then they 218 MUST be mapped as *critical* GSS-API name attributes. 219 SubjectAltNames and EKUs, specifically, MUST be mapped to 220 *authenticated* GSS-API name attributes; see below. Certificate 221 extensions MUST be mapped to GSS-API name attributes whose OIDs are 222 the same as the extensions' 224 5.3.1. PKIX EKUs 226 Extended Key Usage extensions, specifically, MUST be mapped as 227 described above, except that GSS-API name attributes for EKUs MUST 228 have NULL values (i.e., zero-length OCTET STRINGs). 230 PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to 231 GSS-API name attributes. 233 5.3.2. PKIX Certificate Alternative Names 235 PKI certificate subjectAltNames MUST be mapped as *authenticated*, 236 *non-critical* GSS-API name attributes. 238 PKI certificate extensions MUST be mapped to *authenticated* GSS-API 239 name attributes with the _same_ OIDs, and if they be marked critical 240 in the certificate then they MUST be mapped as *critical* GSS-API 241 name attributes. 243 Extended Key Usage extensions, specifically, MUST be mapped as 244 described above, except that GSS-API name attributes for EKUs MUST 245 have NULL values (i.e., zero-length OCTET STRINGs). 247 5.3.3. Other PKIX Certificate Extensions and Attributes 249 [Add text...] 251 5.4. PKIX Certificate CA Paths and Trust Anchors 253 [Add text on how to represent/encode/interpret PKI certificate 254 validation CA paths as name attribute values, much as with Kerberos V 255 transited paths.] 257 6. GSS_Inquire_name_attribute() 259 [NOTE: This function was somewhat controversial at IETF63; we should 260 decide whether to remove it at IETF64. The controversy was, as I 261 recall over whether reflection functionality might not be dangerous, 262 leading to construction of inappropriate ACLs through dumb UIs. For 263 now I am making some changes to it: adding a NAME object as an input 264 parameter and some output parameters.] 266 Inputs: 268 o name NAME 269 o attr OBJECT IDENTIFIER 271 Outputs: 273 o major_status INTEGER, 275 o minor_status INTEGER, 277 o attr_name OCTET STRING, -- display name of the attribute 279 o attr_description OCTET STRING, -- description of the attribute 281 o attr_values_ordered BOOLEAN, -- whether the attribute's values are 282 an ordered set 284 o attr_is_a_name BOOLEAN, -- whether the attribute's values can be 285 used as subjects of access control list entries 287 o attr_is_trust_indicator BOOLEAN -- whether the attribute's values 288 represent nodes in trust paths 290 Return major_status codes: 292 o GSS_S_COMPLETE indicates no error. 294 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 295 known (even if present as a name's attribute). 297 o GSS_S_FAILURE indicates a general error. 299 This function outputs a name for the given name attribute, 300 description for display to users, and indicates whether the 301 attribute's values are ordered sets, whether the given name 302 attribute's values are useful as the subject of an access control 303 list entry and/or whether the given name attribute's values are 304 useful as indicators of trust (for example, whether they name PKIX 305 trust anchors). 307 6.1. C-Bindings 309 OM_uint32 gss_inquire_name_attribute( 310 OM_uint32 *minor_status, 311 gss_name_t name, 312 gss_OID attr, 313 gss_buffer_t attr_name, 314 gss_buffer_t attr_description, 315 int attr_values_ordered, 316 int *attr_is_a_name, 317 int *attr_is_trust_indicator 318 ); 320 7. GSS_Display_name_ext() 322 Inputs: 324 o name NAME, 326 o display_as_name_type OBJECT IDENTIFIER 328 Outputs: 330 o major_status INTEGER, 332 o minor_status INTEGER, 334 o display_name STRING 336 Return major_status codes: 338 o GSS_S_COMPLETE indicates no error. 340 o GSS_S_UNAVAILABLE indicates that the given name could not be 341 displayed using the syntax of the given name type. 343 o GSS_S_FAILURE indicates a general error. 345 This function displays a given name using the given name syntax, if 346 possible. This operation may require mapping MNs to generic name 347 syntaxes or generic name syntaxes to mechanism-specific name 348 syntaxes; such mappings may not always be feasible and MAY be inexact 349 or lossy. 351 7.1. C-Bindings 353 OM_uint32 GSS_Display_name_ext( 354 OM_uint32 *minor_status, 355 gss_name_t name, 356 gss_OID display_as_name_type, 357 gss_buffer_t display_name 358 ); 360 8. GSS_Inquire_name() 362 Inputs: 364 o name NAME 366 Outputs: 368 o major_status INTEGER, 370 o minor_status INTEGER, 372 o name_is_MN BOOLEAN, 374 o mn_mech OBJECT IDENTIFIER, 376 o asserted_attrs SET OF OBJECT IDENTIFIER, 378 o authenticated_attrs SET OF OBJECT IDENTIFIER, 380 o critical_attrs SET OF OBJECT IDENTIFIER, 382 o all_attrs SET OF OBJECT IDENTIFIER, 384 o [NOTE: Perhaps this function should also output an indicator as to 385 the provenance of the name, of which, in the GSS-API, there are 386 three: imported, inquired from a credential, and a peer's name 387 inquired from a security context.] 389 Return major_status codes: 391 o GSS_S_COMPLETE indicates no error. 393 o GSS_S_FAILURE indicates a general error. 395 This function outputs the sets of attributes of a name, that are 396 authenticated, asserted or critical. It also indicates if a given 397 NAME is an MN or not and, if it is, what mechanism it's an MN of. 399 8.1. C-Bindings 401 OM_uint32 gss_inquire_name( 402 OM_uint32 *minor_status, 403 gss_name_t name, 404 int name_is_MN, 405 gss_OID *MN_mech, 406 gss_OID_set *authenticated, 407 gss_OID_set *asserted, 408 gss_OID_set *critical, 409 gss_OID_set *all_attrs 410 ); 412 9. GSS_Get_name_attribute() 414 Inputs: 416 o name NAME, 418 o attr OBJECT IDENTIFIER 420 Outputs: 422 o major_status INTEGER, 424 o minor_status INTEGER, 426 o authenticated BOOLEAN, -- FALSE if asserted but not authenticated 427 by a trusted entity 429 o negative BOOLEAN, 431 o mapped BOOLEAN, 433 o critical BOOLEAN, 435 o values SET OF OCTET STRING, 437 o display_values SET OF STRING 439 Return major_status codes: 441 o GSS_S_COMPLETE indicates no error. 443 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 444 known or set. 446 o GSS_S_FAILURE indicates a general error. 448 This function outputs the value(s) associated with a given GSS name 449 object for a given name attribute. 451 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 452 for order preservation; this has been discussed on the KITTEN WG 453 mailing list and the consensus seems to be that, indeed, that was 454 always the intention. 456 9.1. C-Bindings 458 The C-bindings of GSS_Get_name_attribute() requires one function call 459 per-attribute value, for multi-valued name attributes. This is done 460 by using a single gss_buffer_t for each value and an input/output 461 integer parameter to distinguish initial and subsequent calls and to 462 indicate when all values have been obtained. 464 The 'more' input/output parameter should point to an integer variable 465 whose value, on first call to gss_name_attribute_get() MUST be -1, 466 and whose value upon function call return will be non-zero to 467 indicate that additional values remain, or zero to indicate that no 468 values remain. The caller should not modify this parameter after the 469 initial call. 471 OM_uint32 gss_get_name_attribute( 472 OM_uint32 *minor_status, 473 gss_name_t name, 474 gss_OID attr, 475 int *authenticated, 476 int *negative, 477 int *mapped, 478 int *critical, 479 gss_buffer_t value, 480 gss_buffer_t display_value, 481 int *more 482 ); 484 10. GSS_Set_name_attribute() 486 Inputs: 488 o name NAME, 490 o critical BOOLEAN, 492 o negative BOOLEAN, 494 o attr OBJECT IDENTIFIER, 496 o values SET OF OCTET STRING 497 Outputs: 499 o major_status INTEGER, 501 o minor_status INTEGER 503 Return major_status codes: 505 o GSS_S_COMPLETE indicates no error. 507 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 508 known or could not be set. 510 o GSS_S_FAILURE indicates a general error. 512 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 513 for order preservation; this has been discussed on the KITTEN WG 514 mailing list and the consensus seems to be that, indeed, that was 515 always the intention. 517 10.1. C-Bindings 519 The C-bindings of GSS_Set_name_attribute() requires one function call 520 per-attribute value, for multi-valued name attributes -- each call 521 adds one value. To replace an attribute's every value delete the 522 attribute's values first with GSS_Delete_name_attribute(). 524 OM_uint32 gss_set_name_attribute( 525 OM_uint32 *minor_status, 526 gss_name_t name, 527 int critical, 528 int negative, 529 gss_OID attr, 530 gss_buffer_t value 531 ); 533 11. GSS_Delete_name_attribute() 535 Inputs: 537 o name NAME, 539 o attr OBJECT IDENTIFIER, 541 Outputs: 543 o major_status INTEGER, 545 o minor_status INTEGER 547 Return major_status codes: 549 o GSS_S_COMPLETE indicates no error. 551 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 552 known. 554 o GSS_S_FAILURE indicates a general error. 556 Deletion of negative authenticated attributes from NAME objects MUST 557 NOT be allowed. [Do we need a new major status code for "permission 558 denied"?] 560 11.1. C-Bindings 562 OM_uint32 gss_delete_name_attribute( 563 OM_uint32 *minor_status, 564 gss_name_t name, 565 gss_OID attr 566 ); 568 12. GSS_Export_name_composite() 570 Inputs: 572 o name NAME 574 Outputs: 576 o major_status INTEGER, 578 o minor_status INTEGER, 580 o exp_composite_name OCTET STRING 582 Return major_status codes: 584 o GSS_S_COMPLETE indicates no error. 586 o GSS_S_FAILURE indicates a general error. 588 This function outputs a token which can be imported with 589 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 590 and which preserves any name attribute information associated with 591 the input name (which GSS_Export_name() may well not). The token 592 format is no specified here as this facility is intended for inter- 593 process communication only; however, all such tokens MUST start with 594 a two-octet token ID, hex 04 02, in network byte order. 596 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 598 12.1. C-Bindings 600 OM_uint32 gss_export_name_composite( 601 OM_uint32 *minor_status, 602 gss_name_t name, 603 gss_buffer_t exp_composite_name 604 ); 606 13. GSS_Map_name_to_any() 608 Inputs: 610 o name NAME, 612 o authenticated BOOLEAN, -- if TRUE no data will be output unless it 613 is authenticated 615 o type_id OBJECT IDENTIFIER 617 Outputs: 619 o major_status INTEGER, 621 o minor_status INTEGER, 623 o output ANY DEFINED BY type_id 625 Return major_status codes: 627 o GSS_S_COMPLETE indicates no error. 629 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 630 not be done. The minor status code may provide additional 631 information. 633 o GSS_S_FAILURE indicates a general error. The minor status code 634 may provide additional information. 636 Whereas name attribute's values are encoded in some network 637 representation applications often require native, language- and/or 638 platform-specific data types. This function provides access to such 639 types. 641 13.1. C-Bindings 643 typedef struct gss_any *gss_any_t; 644 OM_uint32 gss_map_name_to_any( 645 OM_uint32 *minor_status, 646 gss_name_t name, 647 int authenticated, 648 gss_OID type_id, 649 gss_any_t output 650 ); 652 Note the new C bindings type, gss_any_t. We define it as a pointer 653 to an incompletely declared struct. 655 14. GSS_Release_any_name_mapping() 657 Inputs: 659 o name NAME, 661 o type_id OBJECT IDENTIFIER, 663 o input ANY DEFINED BY type_id 665 Outputs: 667 o major_status INTEGER, 669 o minor_status INTEGER, 671 Return major_status codes: 673 o GSS_S_COMPLETE indicates no error. 675 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 676 not be done. The minor status code may provide additional 677 information. 679 o GSS_S_FAILURE indicates a general error. The minor status code 680 may provide additional information. 682 This function releases, if possible, the objects of language- and/or 683 platform-specific types output by GSS_Map_name_to_any(). If such 684 types have native release functions applications MAY use either those 685 or this function to release the given object. 687 14.1. C-Bindings 689 typedef struct gss_any *gss_any_t; 690 OM_uint32 gss_release_any_name_mapping( 691 OM_uint32 *minor_status, 692 gss_name_t name, 693 gss_OID type_id, 694 gss_any_t *input 695 ); 697 15. IANA Considerations 699 This document creates a namespace of GSS-API name attributes. 700 Attributes are named by OID, so no single authority might be needed 701 for allocation, however, in the interest of providing the community 702 with an authority for name attribute OID allocation and a way to find 703 the existing set of name attributes, the IANA should establish both, 704 a single OID off of which name attributes could be allocated, and a 705 registry of known GSS name attributes. 707 GSS-API name attribute registry entries should contain all the 708 information that GSS_Inquire_name_attribute() may return about the 709 given name attributes and their OIDs: 711 o a name attribute OID (this is a unique key) 713 o a name attribute symbolic name, starting with "GSS_C_NA_" (this is 714 a unique key) 716 o a brief description, in English 718 o whether the attribute is useful as the subject of access control 719 list entries 721 o whether the attribute is useful as an indicator of trust 723 o an optional normative reference to documentation for the given 724 name attribute 726 The allocation and registration policy should be first come, first 727 served. Registry entries' OIDs need not be based on the base OID 728 given above. 730 16. Security Considerations 732 734 [In particular, the status of a name attribute as "authenticated" vs. 735 "asserted" requires close review, particularly with respect to PKIX 736 certificate extensions.] 738 [Also, we need to work out the security considerations of (and 739 possibly remove) negative attributes.] 741 17. Normative References 743 [I-D.GSS-NAMING] 744 Hartman, S., "Desired Enhancements to GSSAPI Naming", 745 draft-ietf-kitten-gss-naming-01.txt (work in progress), 746 February 2005. 748 [I-D.ietf-krb-wg-kerberos-clarifications] 749 Neuman, C., "The Kerberos Network Authentication Service 750 (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work 751 in progress), September 2004. 753 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 754 (SPKM)", RFC 2025, October 1996. 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC2743] Linn, J., "Generic Security Service Application Program 760 Interface Version 2, Update 1", RFC 2743, January 2000. 762 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 763 C-bindings", RFC 2744, January 2000. 765 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 766 X.509 Public Key Infrastructure Certificate and 767 Certificate Revocation List (CRL) Profile", RFC 3280, 768 April 2002. 770 Author's Address 772 Nicolas Williams 773 Sun Microsystems 774 5300 Riata Trace Ct 775 Austin, TX 78727 776 US 778 Email: Nicolas.Williams@sun.com 780 Intellectual Property Statement 782 The IETF takes no position regarding the validity or scope of any 783 Intellectual Property Rights or other rights that might be claimed to 784 pertain to the implementation or use of the technology described in 785 this document or the extent to which any license under such rights 786 might or might not be available; nor does it represent that it has 787 made any independent effort to identify any such rights. Information 788 on the procedures with respect to rights in RFC documents can be 789 found in BCP 78 and BCP 79. 791 Copies of IPR disclosures made to the IETF Secretariat and any 792 assurances of licenses to be made available, or the result of an 793 attempt made to obtain a general license or permission for the use of 794 such proprietary rights by implementers or users of this 795 specification can be obtained from the IETF on-line IPR repository at 796 http://www.ietf.org/ipr. 798 The IETF invites any interested party to bring to its attention any 799 copyrights, patents or patent applications, or other proprietary 800 rights that may cover technology that may be required to implement 801 this standard. Please address the information to the IETF at 802 ietf-ipr@ietf.org. 804 Disclaimer of Validity 806 This document and the information contained herein are provided on an 807 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 808 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 809 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 810 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 811 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 812 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 814 Copyright Statement 816 Copyright (C) The Internet Society (2005). This document is subject 817 to the rights, licenses and restrictions contained in BCP 78, and 818 except as set forth therein, the authors retain all their rights. 820 Acknowledgment 822 Funding for the RFC Editor function is currently provided by the 823 Internet Society.