idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 13, 2008) is 5737 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) == Unused Reference: 'RFC0854' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC2478' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'RFC3008' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 752, but no explicit reference was found in the text == 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 2478 (Obsoleted by RFC 4178) ** Obsolete normative reference: RFC 3008 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KITTEN WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track L. Johansson 5 Expires: January 14, 2009 Stockholm university 6 July 13, 2008 8 GSS-API Naming Extensions 9 draft-ietf-kitten-gssapi-naming-exts-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2009. 36 Abstract 38 The Generic Security Services API (GSS-API) provides a simple naming 39 architecture that supports name-based authorization. This document 40 introduces new APIs that extend the GSS-API naming model to support 41 name attribute transfer between GSS-API peers. 43 Table of Contents 45 1. Conventions used in this document . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Name Attribute Sources and Criticality . . . . . . . . . . 3 48 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 49 5. Mapping Mechanism Facilities to Name Attributes . . . . . 4 50 5.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 51 5.2. PKIX Certificate Extensions . . . . . . . . . . . . . . . 5 52 5.2.1. PKIX EKUs . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5.2.2. PKIX Certificate Alternative Names . . . . . . . . . . . . 6 54 5.2.3. Other PKIX Certificate Extensions and Attributes . . . . . 6 55 5.2.4. SAML attribute assertions . . . . . . . . . . . . . . . . 6 56 6. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 57 6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 59 7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 60 8. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 61 8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 62 9. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10 63 9.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 64 10. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 65 10.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 66 11. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12 67 11.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 68 12. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 13 69 12.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 70 13. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 14 71 13.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15 72 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 73 15. Security Considerations . . . . . . . . . . . . . . . . . 15 74 16. Normative References . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . 19 78 1. Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 As described in [I-D.GSS-NAMING] the GSS-API's naming architecture 87 suffers from certain limitations. This document proposes concrete 88 GSS-API extensions as outlined in [I-D.GSS-NAMING]. 90 A number of extensions to the GSS-API [RFC2743] and its C Bindings 91 [RFC2744] are described herein with the goal of making authorization 92 information, and other information that can be modeled as "name 93 attributes" available as such to applications. For example, Kerberos 94 V authorization data elements, both, in their raw forms as well as 95 mapped to more useful value types, can be made available to GSS-API 96 applications through these interfaces. 98 The model is that GSS names have attributes. The attributes of a 99 name may be authenticated by the credential whence the name comes, or 100 may have been set locally on a GSS name for the purpose of 101 "asserting" the attribute during credential acquisition or security 102 context exchange. Name attributes' values are network 103 representations thereof (e.g., the actual value octets of the 104 contents of an X.509 certificate extension, for example) and are 105 intended to be useful for constructing portable access control 106 facilities. Applications may often require language- or platform- 107 specific data types, rather than network representations of name 108 attributes, so a function is provided to obtain objects of such types 109 associated with names and name attributes. 111 3. Name Attribute Sources and Criticality 113 A given GSS name object's name attributes may be authenticated, 114 mapped and/or critical. These flags are explained below. 116 An attribute is 'authenticated' iff there is a secure association 117 between the attribute (and its values) and the trusted source of the 118 peer credential. Examples of authenticated attributes are (any part 119 of) the signed portion of an X.509 certificate or AD-KDCIssued 120 authorization-data elements in Kerberos V Tickets. Note that the 121 fact that an attribute is authenticated does not imply anything about 122 the semantics of the attribute nor that the trusted credential source 123 authorized any one semantic of the attribute. Such interpretations 124 MAY be the result of applying local policy to the attribute. 126 That a given name's given attribute is 'mapped' means that it was 127 obtained through some mapping mechanism applied to another attribute 128 of the name that was not, itself, mapped. For example, such 129 attributes as platform-specific internal identifiers may sometimes be 130 mapped from other name attributes. 132 Name attributes may be "critical," meaning that applications that do 133 not understand them MUST reject security contexts where the peer has 134 such unknown, critical attributes. 136 [NOTE(leifj): The criticality flag seems to have limited 137 applicability in practice. As written the security context should 138 not be established unless all critically marked naming attributes are 139 supported and understood. But what happens if the peer doesn't 140 understand naming extensions at all. It seems more reasonable to 141 state that name attribute extensions MUST only be used to as a basis 142 for authorization decisions.] 144 [NOTE(leifj): The mapped flag also seems to have limited 145 applicability in practice - interpretation of the attribute will be 146 entierly up to the peer anyway which will need to know much more 147 about the attribute than the fact than its value is derived.] 149 4. Name Attributes/Values as ACL Subjects 151 Some name attributes (e.g., numeric user or group identifiers) may be 152 useful as subjects of access control list (ACL) entries, some may not 153 (e.g., time of day login restrictions). The 154 GSS_Inquire_name_attribute() function indicates this. 156 To facilitate the development of portable applications that make use 157 of name attributes to construct and evaluate portable ACLs the GSS- 158 API makes name attribute values available in canonical network 159 encodings thereof. 161 To facilitate the development of platform- or language-specific 162 applications that need access to native types of representations of 163 name attributes an optional facility is provided, 164 GSS_Map_name_to_any(). 166 5. Mapping Mechanism Facilities to Name Attributes 168 [NOTE: This entire section should probably be split into one or more 169 separate Internet-Drafts. It is here in the -00 of this I-D to help 170 readers understand how to mechanism-specific name attributes would be 171 accessed through these GSS-API extensions.] 173 Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple 174 Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the 175 concept and encoding of containers of "authorization-data" as 176 described in [I-D.ietf-krb-wg-kerberos-clarifications]. 178 PKIX [RFC3280] supports a number of authorization-data-like features, 179 like Extended Key Usage values (EKUs) and certificate extensions. 181 The authorization data can be accessed through the GSS-API name 182 attributes facility defined herein. 184 5.1. Kerberos V and SPKM Authorization-Data 186 Authorization-data non-container elements asserted in Kerberos V AP- 187 REQ Authenticators MUST be mapped into *asserted* GSS-API name 188 attributes; if not contained in AD-IF-RELEVANT then they MUST be 189 mapped into *critical* GSS-API name attributes. AD-AND-OR 190 authorization-data elements MUST be mapped into a single *critical* 191 attribute, (TBD). 193 Authorization-data included in Kerberos V Tickets that is not 194 contained in AD-KDCIssued (with valid signature) MUST be mapped into 195 *asserted* GSS-API name attributes. Conversely, authorization-data 196 elements in Kerberos V Tickets contained by AD-KDCIssued MUST be 197 mapped into *authenticated* GSS-API name attributes 199 As with authorization-data elements in Authenticators, authorization- 200 data elements in Tickets not contained in AD-IF-RELEVANT are to be 201 mapped to *critical* name attributes, and similarly with AD-AND-OR 202 (see above). 204 The OIDs for authorization-data elements are to be the authorization- 205 data element's 'ad-type' positive integer ID, relative to the base 206 OID Negative values are reserved for local experiments. [NOTE: 207 what about negative ad-type's? OID arcs are positive integers... ad- 208 type is an Int32, so clearly something can be done.] 210 5.2. PKIX Certificate Extensions 212 PKI certificate extensions MAY/SHOULD/MUST (see comment above) be 213 represented as *authenticated* GSS-API name attributes with the 214 _same_ OIDs, and if they be marked critical in the certificate then 215 they MUST be mapped as *critical* GSS-API name attributes. 216 SubjectAltNames and EKUs, specifically, MUST be represented as 217 *authenticated* GSS-API name attributes; see below. Certificate 218 extensions MUST be represented as GSS-API name attributes whose OIDs 219 are the same as the extensions' 221 5.2.1. PKIX EKUs 223 Extended Key Usage extensions, specifically, MUST be mapped as 224 described above, except that GSS-API name attributes for EKUs MUST 225 have NULL values (i.e., zero-length OCTET STRINGs). 227 PKI certificate key usages (KUs, but not EKUs), MUST NOT be 228 represented as GSS-API name attributes. 230 5.2.2. PKIX Certificate Alternative Names 232 PKI certificate subjectAltNames MUST be mapped as *authenticated*, 233 *non-critical* GSS-API name attributes. 235 PKI certificate extensions MUST be represented as *authenticated* 236 GSS-API name attributes with the _same_ OIDs, and if they be marked 237 critical in the certificate then they MUST be mapped as *critical* 238 GSS-API name attributes. 240 Extended Key Usage extensions, specifically, MUST be mapped as 241 described above, except that GSS-API name attributes for EKUs MUST 242 have NULL values (i.e., zero-length OCTET STRINGs). 244 5.2.3. Other PKIX Certificate Extensions and Attributes 246 Any X.509 certificate extension not covered above SHOULD be 247 represented as GSS-AOI name attributes with the OID of the X.509 248 extension and with OCTET STRING values containing the encoded value 249 of the extension. 251 5.2.4. SAML attribute assertions 253 Attributes contained in SAML attribute assertions are mapped to GSS- 254 API name attributes with OIDs derived from the SAML attributes: 256 If the SAML attribute is an OID the same OID is used. 258 If the SAML attribute is a URN or a URI then the name MUST be 259 mapped to a corresponding OID by means of an IANA registry. 261 6. GSS_Display_name_ext() 263 Inputs: 265 o name NAME, 267 o display_as_name_type OBJECT IDENTIFIER 269 Outputs: 271 o major_status INTEGER, 273 o minor_status INTEGER, 275 o display_name STRING 277 Return major_status codes: 279 o GSS_S_COMPLETE indicates no error. 281 o GSS_S_UNAVAILABLE indicates that the given name could not be 282 displayed using the syntax of the given name type. 284 o GSS_S_FAILURE indicates a general error. 286 This function displays a given name using the given name syntax, if 287 possible. This operation may require mapping MNs to generic name 288 syntaxes or generic name syntaxes to mechanism-specific name 289 syntaxes; such mappings may not always be feasible and MAY be inexact 290 or lossy, therefore this function may fail. 292 6.1. C-Bindings 294 OM_uint32 GSS_Display_name_ext( 295 OM_uint32 *minor_status, 296 gss_name_t name, 297 gss_OID display_as_name_type, 298 gss_buffer_t display_name 299 ); 301 7. GSS_Inquire_name() 303 Inputs: 305 o name NAME 307 Outputs: 309 o major_status INTEGER, 311 o minor_status INTEGER, 313 o name_is_MN BOOLEAN, 315 o mn_mech OBJECT IDENTIFIER, 317 o asserted_attrs SET OF OBJECT IDENTIFIER, 319 o authenticated_attrs SET OF OBJECT IDENTIFIER, 321 o critical_attrs SET OF OBJECT IDENTIFIER, 323 o all_attrs SET OF OBJECT IDENTIFIER, 325 Return major_status codes: 327 o GSS_S_COMPLETE indicates no error. 329 o GSS_S_FAILURE indicates a general error. 331 This function outputs the sets of attributes of a name, that are 332 authenticated, asserted or critical. It also indicates if a given 333 NAME is an MN or not and, if it is, what mechanism it's an MN of. 335 7.1. C-Bindings 337 OM_uint32 gss_inquire_name( 338 OM_uint32 *minor_status, 339 gss_name_t name, 340 int name_is_MN, 341 gss_OID *MN_mech, 342 gss_OID_set *authenticated, 343 gss_OID_set *asserted, 344 gss_OID_set *critical, 345 gss_OID_set *all_attrs 346 ); 348 8. GSS_Get_name_attribute() 350 Inputs: 352 o name NAME, 354 o attr OBJECT IDENTIFIER 355 Outputs: 357 o major_status INTEGER, 359 o minor_status INTEGER, 361 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 362 peer credential source. 364 o negative BOOLEAN, 366 o mapped BOOLEAN, 368 o critical BOOLEAN, 370 o values SET OF OCTET STRING, 372 o display_values SET OF STRING 374 Return major_status codes: 376 o GSS_S_COMPLETE indicates no error. 378 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 379 known or set. 381 o GSS_S_FAILURE indicates a general error. 383 This function outputs the value(s) associated with a given GSS name 384 object for a given name attribute. 386 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 387 for order preservation; this has been discussed on the KITTEN WG 388 mailing list and the consensus seems to be that, indeed, that was 389 always the intention. It should be noted however that the order 390 presented does not always reflect an underlying order of the 391 mechanism specific source of the attribute values. 393 8.1. C-Bindings 395 The C-bindings of GSS_Get_name_attribute() requires one function call 396 per-attribute value, for multi-valued name attributes. This is done 397 by using a single gss_buffer_t for each value and an input/output 398 integer parameter to distinguish initial and subsequent calls and to 399 indicate when all values have been obtained. 401 The 'more' input/output parameter should point to an integer variable 402 whose value, on first call to gss_name_attribute_get() MUST be -1, 403 and whose value upon function call return will be non-zero to 404 indicate that additional values remain, or zero to indicate that no 405 values remain. The caller should not modify this parameter after the 406 initial call. 408 OM_uint32 gss_get_name_attribute( 409 OM_uint32 *minor_status, 410 gss_name_t name, 411 gss_OID attr, 412 int *authenticated, 413 int *negative, 414 int *mapped, 415 int *critical, 416 gss_buffer_t value, 417 gss_buffer_t display_value, 418 int *more 419 ); 421 9. GSS_Set_name_attribute() 423 Inputs: 425 o name NAME, 427 o critical BOOLEAN, 429 o negative BOOLEAN, 431 o attr OBJECT IDENTIFIER, 433 o values SET OF OCTET STRING 435 Outputs: 437 o major_status INTEGER, 439 o minor_status INTEGER 441 Return major_status codes: 443 o GSS_S_COMPLETE indicates no error. 445 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 446 known or could not be set. 448 o GSS_S_FAILURE indicates a general error. 450 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 451 for order preservation; this has been discussed on the KITTEN WG 452 mailing list and the consensus seems to be that, indeed, that was 453 always the intention. It should be noted that underlying mechanisms 454 may not respect the given order. 456 9.1. C-Bindings 458 The C-bindings of GSS_Set_name_attribute() requires one function call 459 per-attribute value, for multi-valued name attributes -- each call 460 adds one value. To replace an attribute's every value delete the 461 attribute's values first with GSS_Delete_name_attribute(). 463 OM_uint32 gss_set_name_attribute( 464 OM_uint32 *minor_status, 465 gss_name_t name, 466 int critical, 467 int negative, 468 gss_OID attr, 469 gss_buffer_t value 470 ); 472 10. GSS_Delete_name_attribute() 474 Inputs: 476 o name NAME, 478 o attr OBJECT IDENTIFIER, 480 Outputs: 482 o major_status INTEGER, 484 o minor_status INTEGER 486 Return major_status codes: 488 o GSS_S_COMPLETE indicates no error. 490 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 491 known. 493 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 494 attempted eg deleting a negative attribute. 496 o GSS_S_FAILURE indicates a general error. 498 Deletion of negative authenticated attributes from NAME objects MUST 499 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 501 10.1. C-Bindings 503 OM_uint32 gss_delete_name_attribute( 504 OM_uint32 *minor_status, 505 gss_name_t name, 506 gss_OID attr 507 ); 509 11. GSS_Export_name_composite() 511 Inputs: 513 o name NAME 515 Outputs: 517 o major_status INTEGER, 519 o minor_status INTEGER, 521 o exp_composite_name OCTET STRING 523 Return major_status codes: 525 o GSS_S_COMPLETE indicates no error. 527 o GSS_S_FAILURE indicates a general error. 529 This function outputs a token which can be imported with 530 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 531 and which preserves any name attribute information associated with 532 the input name (which GSS_Export_name() may well not). The token 533 format is no specified here as this facility is intended for inter- 534 process communication only; however, all such tokens MUST start with 535 a two-octet token ID, hex 04 02, in network byte order. 537 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 539 11.1. C-Bindings 541 OM_uint32 gss_export_name_composite( 542 OM_uint32 *minor_status, 543 gss_name_t name, 544 gss_buffer_t exp_composite_name 545 ); 547 12. GSS_Map_name_to_any() 549 Inputs: 551 o name NAME, 553 o authenticated BOOLEAN, -- if TRUE only authenticated attributes 554 will be included 556 o type_id OBJECT IDENTIFIER 558 Outputs: 560 o major_status INTEGER, 562 o minor_status INTEGER, 564 o output ANY DEFINED BY type_id 566 Return major_status codes: 568 o GSS_S_COMPLETE indicates no error. 570 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 571 not be done. The minor status code may provide additional 572 information. 574 o GSS_S_FAILURE indicates a general error. The minor status code 575 may provide additional information. 577 Whereas name attribute's values are encoded in some network 578 representation applications often require native, language- and/or 579 platform-specific data types. This function provides access to such 580 types. 582 12.1. C-Bindings 583 typedef struct gss_any *gss_any_t; 584 OM_uint32 gss_map_name_to_any( 585 OM_uint32 *minor_status, 586 gss_name_t name, 587 int authenticated, 588 gss_OID type_id, 589 gss_any_t output 590 ); 592 Note the new C bindings type, gss_any_t. We define it as a pointer 593 to an incompletely declared struct. 595 13. GSS_Release_any_name_mapping() 597 Inputs: 599 o name NAME, 601 o type_id OBJECT IDENTIFIER, 603 o input ANY DEFINED BY type_id 605 Outputs: 607 o major_status INTEGER, 609 o minor_status INTEGER, 611 Return major_status codes: 613 o GSS_S_COMPLETE indicates no error. 615 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 616 not be done. The minor status code may provide additional 617 information. 619 o GSS_S_FAILURE indicates a general error. The minor status code 620 may provide additional information. 622 This function releases, if possible, the objects of language- and/or 623 platform-specific types output by GSS_Map_name_to_any(). If such 624 types have native release functions applications MAY use either those 625 or this function to release the given object. 627 13.1. C-Bindings 628 typedef struct gss_any *gss_any_t; 629 OM_uint32 gss_release_any_name_mapping( 630 OM_uint32 *minor_status, 631 gss_name_t name, 632 gss_OID type_id, 633 gss_any_t *input 634 ); 636 14. IANA Considerations 638 This document creates a namespace of GSS-API name attributes. 639 Attributes are named by OID, so no single authority might be needed 640 for allocation, however, in the interest of providing the community 641 with an authority for name attribute OID allocation and a way to find 642 the existing set of name attributes, the IANA should establish both, 643 a single OID off of which name attributes could be allocated, and a 644 registry of known GSS name attributes. 646 GSS-API name attribute registry entries should contain all the 647 information that GSS_Inquire_name_attribute() may return about the 648 given name attributes and their OIDs: 650 o a name attribute OID (this is a unique key) 652 o a name attribute symbolic name, starting with "GSS_C_NA_" (this is 653 a unique key) 655 o a brief description, in English 657 o whether the attribute is useful as the subject of access control 658 list entries 660 o whether the attribute is useful as an indicator of trust 662 o an optional normative reference to documentation for the given 663 name attribute 665 The allocation and registration policy should be first come, first 666 served. Registry entries' OIDs need not be based on the base OID 667 given above. 669 15. Security Considerations 671 This document extends the GSS-API naming model to include support for 672 name attributes. The intention is that name attributes are to be 673 used as a basis for (among other things) authorization decisions or 674 application personalization for applications relying on GSS-API 675 security contexts. 677 The security of the application may be critically dependent on the 678 security of the attributes. This document classifies attributes as 679 asserted or authenticated. Only authenticated attributes MUST be 680 used if the attribute has security implications for the application 681 (eg authorization decisions) since asserted attributes may easily be 682 controlled by the peer directly. 684 It is important to understand the meaning of 'authenticated' in this 685 setting. It does not mean that any semantic of the attribute is 686 claimed to be true. The only implication is that a trusted third 687 party has asserted the attribute as opposed to the attribute being 688 asserte by the peer itself. Any additional semantics is always the 689 result of applying policy. For instance in a given deployment the 690 mail attribute of the subject may be authenticated and sourced from 691 an email system where 'correct' values are kept. In another setting 692 users may be allowed to modify their mail addresses freely. In both 693 cases the 'mail' attribute may be authenticated by virtue of being 694 included in signed SAML attribute assertions or by other means 695 authenticated by the underlying mechanism. 697 When the underlying security mechanism does not provide a permanent 698 unique identity (eg anonymous kerberos) the GSS-API naming extensions 699 may be used to provide a replacement permanent unique identity 700 attribute which in this case may be unique for each relying party. 701 This is analogous to the Liberty Alliance targetedID attribute and 702 has similar security implications. 704 16. Normative References 706 [I-D.GSS-NAMING] 707 Hartman, S., "Desired Enhancements to GSSAPI Naming", 708 draft-ietf-kitten-gss-naming-01.txt (work in progress), 709 February 2005. 711 [I-D.ietf-krb-wg-kerberos-clarifications] 712 Neuman, C., "The Kerberos Network Authentication Service 713 (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work 714 in progress), September 2004. 716 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 717 Specification", STD 8, RFC 854, May 1983. 719 [RFC1035] Mockapetris, P., "Domain names - implementation and 720 specification", STD 13, RFC 1035, November 1987. 722 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 723 (SPKM)", RFC 2025, October 1996. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, March 1997. 728 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 729 Specification", RFC 2203, September 1997. 731 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 732 Negotiation Mechanism", RFC 2478, December 1998. 734 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 735 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 736 RFC 2623, June 1999. 738 [RFC2743] Linn, J., "Generic Security Service Application Program 739 Interface Version 2, Update 1", RFC 2743, January 2000. 741 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 742 C-bindings", RFC 2744, January 2000. 744 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 745 Signing Authority", RFC 3008, November 2000. 747 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 748 X.509 Public Key Infrastructure Certificate and 749 Certificate Revocation List (CRL) Profile", RFC 3280, 750 April 2002. 752 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 753 Beame, C., Eisler, M., and D. Noveck, "Network File System 754 (NFS) version 4 Protocol", RFC 3530, April 2003. 756 Authors' Addresses 758 Nicolas Williams 759 Sun Microsystems 760 5300 Riata Trace Ct 761 Austin, TX 78727 762 US 764 Email: Nicolas.Williams@sun.com 766 Leif Johansson 767 Stockholm university 768 Avdelningen foer IT och Media 769 Stockholm SE-106 91 771 Email: leifj@it.su.se 772 URI: http://people.su.se/~leifj/ 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2008). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org.