idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 8, 2009) is 5527 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 724, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'RFC2478' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'RFC3008' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 760, 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 (==), 2 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: September 9, 2009 Stockholm university 6 March 8, 2009 8 GSS-API Naming Extensions 9 draft-ietf-kitten-gssapi-naming-exts-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 September 9, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Generic Security Services API (GSS-API) provides a simple naming 48 architecture that supports name-based authorization. This document 49 introduces new APIs that extend the GSS-API naming model to support 50 name attribute transfer between GSS-API peers. 52 Table of Contents 54 1. Conventions used in this document . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Name Attribute Sources and Criticality . . . . . . . . . . 3 57 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 58 5. Mapping Mechanism Facilities to Name Attributes . . . . . 4 59 5.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 60 5.2. PKIX Certificate Extensions . . . . . . . . . . . . . . . 5 61 5.2.1. PKIX EKUs . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.2.2. PKIX Certificate Alternative Names . . . . . . . . . . . . 6 63 5.2.3. Other PKIX Certificate Extensions and Attributes . . . . . 6 64 5.2.4. SAML attribute assertions . . . . . . . . . . . . . . . . 6 65 6. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 66 6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 68 7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 70 8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10 72 9.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 74 10.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12 76 11.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 77 12. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 13 78 12.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 79 13. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 14 80 13.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15 81 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 82 15. Security Considerations . . . . . . . . . . . . . . . . . 15 83 16. Normative References . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 86 1. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 As described in [I-D.GSS-NAMING] the GSS-API's naming architecture 95 suffers from certain limitations. This document proposes concrete 96 GSS-API extensions as outlined in [I-D.GSS-NAMING]. 98 A number of extensions to the GSS-API [RFC2743] and its C Bindings 99 [RFC2744] are described herein with the goal of making authorization 100 information, and other information that can be modeled as "name 101 attributes" available as such to applications. For example, Kerberos 102 V authorization data elements, both, in their raw forms as well as 103 mapped to more useful value types, can be made available to GSS-API 104 applications through these interfaces. 106 The model is that GSS names have attributes. The attributes of a 107 name may be authenticated by the credential whence the name comes, or 108 may have been set locally on a GSS name for the purpose of 109 "asserting" the attribute during credential acquisition or security 110 context exchange. Name attributes' values are network 111 representations thereof (e.g., the actual value octets of the 112 contents of an X.509 certificate extension, for example) and are 113 intended to be useful for constructing portable access control 114 facilities. Applications may often require language- or platform- 115 specific data types, rather than network representations of name 116 attributes, so a function is provided to obtain objects of such types 117 associated with names and name attributes. 119 3. Name Attribute Sources and Criticality 121 A given GSS name object's name attributes may be authenticated, 122 mapped and/or critical. These flags are explained below. 124 An attribute is 'authenticated' iff there is a secure association 125 between the attribute (and its values) and the trusted source of the 126 peer credential. Examples of authenticated attributes are (any part 127 of) the signed portion of an X.509 certificate or AD-KDCIssued 128 authorization-data elements in Kerberos V Tickets. Note that the 129 fact that an attribute is authenticated does not imply anything about 130 the semantics of the attribute nor that the trusted credential source 131 authorized any one semantic of the attribute. Such interpretations 132 MAY be the result of applying local policy to the attribute. 134 That a given name's given attribute is 'mapped' means that it was 135 obtained through some mapping mechanism applied to another attribute 136 of the name that was not, itself, mapped. For example, such 137 attributes as platform-specific internal identifiers may sometimes be 138 mapped from other name attributes. 140 Name attributes may be "critical," meaning that applications that do 141 not understand them MUST reject security contexts where the peer has 142 such unknown, critical attributes. 144 [NOTE(leifj): The criticality flag seems to have limited 145 applicability in practice. As written the security context should 146 not be established unless all critically marked naming attributes are 147 supported and understood. But what happens if the peer doesn't 148 understand naming extensions at all. It seems more reasonable to 149 state that name attribute extensions MUST only be used to as a basis 150 for authorization decisions.] 152 [NOTE(leifj): The mapped flag also seems to have limited 153 applicability in practice - interpretation of the attribute will be 154 entierly up to the peer anyway which will need to know much more 155 about the attribute than the fact than its value is derived.] 157 4. Name Attributes/Values as ACL Subjects 159 Some name attributes (e.g., numeric user or group identifiers) may be 160 useful as subjects of access control list (ACL) entries, some may not 161 (e.g., time of day login restrictions). The 162 GSS_Inquire_name_attribute() function indicates this. 164 To facilitate the development of portable applications that make use 165 of name attributes to construct and evaluate portable ACLs the GSS- 166 API makes name attribute values available in canonical network 167 encodings thereof. 169 To facilitate the development of platform- or language-specific 170 applications that need access to native types of representations of 171 name attributes an optional facility is provided, 172 GSS_Map_name_to_any(). 174 5. Mapping Mechanism Facilities to Name Attributes 176 [NOTE: This entire section should probably be split into one or more 177 separate Internet-Drafts. It is here in the -00 of this I-D to help 178 readers understand how to mechanism-specific name attributes would be 179 accessed through these GSS-API extensions.] 181 Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple 182 Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the 183 concept and encoding of containers of "authorization-data" as 184 described in [I-D.ietf-krb-wg-kerberos-clarifications]. 186 PKIX [RFC3280] supports a number of authorization-data-like features, 187 like Extended Key Usage values (EKUs) and certificate extensions. 189 The authorization data can be accessed through the GSS-API name 190 attributes facility defined herein. 192 5.1. Kerberos V and SPKM Authorization-Data 194 Authorization-data non-container elements asserted in Kerberos V AP- 195 REQ Authenticators MUST be mapped into *asserted* GSS-API name 196 attributes; if not contained in AD-IF-RELEVANT then they MUST be 197 mapped into *critical* GSS-API name attributes. AD-AND-OR 198 authorization-data elements MUST be mapped into a single *critical* 199 attribute, (TBD). 201 Authorization-data included in Kerberos V Tickets that is not 202 contained in AD-KDCIssued (with valid signature) MUST be mapped into 203 *asserted* GSS-API name attributes. Conversely, authorization-data 204 elements in Kerberos V Tickets contained by AD-KDCIssued MUST be 205 mapped into *authenticated* GSS-API name attributes 207 As with authorization-data elements in Authenticators, authorization- 208 data elements in Tickets not contained in AD-IF-RELEVANT are to be 209 mapped to *critical* name attributes, and similarly with AD-AND-OR 210 (see above). 212 The OIDs for authorization-data elements are to be the authorization- 213 data element's 'ad-type' positive integer ID, relative to the base 214 OID Negative values are reserved for local experiments. [NOTE: 215 what about negative ad-type's? OID arcs are positive integers... ad- 216 type is an Int32, so clearly something can be done.] 218 5.2. PKIX Certificate Extensions 220 PKI certificate extensions MAY/SHOULD/MUST (see comment above) be 221 represented as *authenticated* GSS-API name attributes with the 222 _same_ OIDs, and if they be marked critical in the certificate then 223 they MUST be mapped as *critical* GSS-API name attributes. 224 SubjectAltNames and EKUs, specifically, MUST be represented as 225 *authenticated* GSS-API name attributes; see below. Certificate 226 extensions MUST be represented as GSS-API name attributes whose OIDs 227 are the same as the extensions' 229 5.2.1. PKIX EKUs 231 Extended Key Usage extensions, specifically, MUST be mapped as 232 described above, except that GSS-API name attributes for EKUs MUST 233 have NULL values (i.e., zero-length OCTET STRINGs). 235 PKI certificate key usages (KUs, but not EKUs), MUST NOT be 236 represented as GSS-API name attributes. 238 5.2.2. PKIX Certificate Alternative Names 240 PKI certificate subjectAltNames MUST be mapped as *authenticated*, 241 *non-critical* GSS-API name attributes. 243 PKI certificate extensions MUST be represented as *authenticated* 244 GSS-API name attributes with the _same_ OIDs, and if they be marked 245 critical in the certificate then they MUST be mapped as *critical* 246 GSS-API name attributes. 248 Extended Key Usage extensions, specifically, MUST be mapped as 249 described above, except that GSS-API name attributes for EKUs MUST 250 have NULL values (i.e., zero-length OCTET STRINGs). 252 5.2.3. Other PKIX Certificate Extensions and Attributes 254 Any X.509 certificate extension not covered above SHOULD be 255 represented as GSS-AOI name attributes with the OID of the X.509 256 extension and with OCTET STRING values containing the encoded value 257 of the extension. 259 5.2.4. SAML attribute assertions 261 Attributes contained in SAML attribute assertions are mapped to GSS- 262 API name attributes with OIDs derived from the SAML attributes: 264 If the SAML attribute is an OID the same OID is used. 266 If the SAML attribute is a URN or a URI then the name MUST be 267 mapped to a corresponding OID by means of an IANA registry. 269 6. GSS_Display_name_ext() 271 Inputs: 273 o name NAME, 275 o display_as_name_type OBJECT IDENTIFIER 277 Outputs: 279 o major_status INTEGER, 281 o minor_status INTEGER, 283 o display_name STRING 285 Return major_status codes: 287 o GSS_S_COMPLETE indicates no error. 289 o GSS_S_UNAVAILABLE indicates that the given name could not be 290 displayed using the syntax of the given name type. 292 o GSS_S_FAILURE indicates a general error. 294 This function displays a given name using the given name syntax, if 295 possible. This operation may require mapping MNs to generic name 296 syntaxes or generic name syntaxes to mechanism-specific name 297 syntaxes; such mappings may not always be feasible and MAY be inexact 298 or lossy, therefore this function may fail. 300 6.1. C-Bindings 302 OM_uint32 GSS_Display_name_ext( 303 OM_uint32 *minor_status, 304 gss_name_t name, 305 gss_OID display_as_name_type, 306 gss_buffer_t display_name 307 ); 309 7. GSS_Inquire_name() 311 Inputs: 313 o name NAME 315 Outputs: 317 o major_status INTEGER, 319 o minor_status INTEGER, 321 o name_is_MN BOOLEAN, 323 o mn_mech OBJECT IDENTIFIER, 325 o asserted_attrs SET OF OBJECT IDENTIFIER, 327 o authenticated_attrs SET OF OBJECT IDENTIFIER, 329 o critical_attrs SET OF OBJECT IDENTIFIER, 331 o all_attrs SET OF OBJECT IDENTIFIER, 333 Return major_status codes: 335 o GSS_S_COMPLETE indicates no error. 337 o GSS_S_FAILURE indicates a general error. 339 This function outputs the sets of attributes of a name, that are 340 authenticated, asserted or critical. It also indicates if a given 341 NAME is an MN or not and, if it is, what mechanism it's an MN of. 343 7.1. C-Bindings 345 OM_uint32 gss_inquire_name( 346 OM_uint32 *minor_status, 347 gss_name_t name, 348 int name_is_MN, 349 gss_OID *MN_mech, 350 gss_OID_set *authenticated, 351 gss_OID_set *asserted, 352 gss_OID_set *critical, 353 gss_OID_set *all_attrs 354 ); 356 8. GSS_Get_name_attribute() 358 Inputs: 360 o name NAME, 362 o attr OBJECT IDENTIFIER 363 Outputs: 365 o major_status INTEGER, 367 o minor_status INTEGER, 369 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 370 peer credential source. 372 o negative BOOLEAN, 374 o mapped BOOLEAN, 376 o critical BOOLEAN, 378 o values SET OF OCTET STRING, 380 o display_values SET OF STRING 382 Return major_status codes: 384 o GSS_S_COMPLETE indicates no error. 386 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 387 known or set. 389 o GSS_S_FAILURE indicates a general error. 391 This function outputs the value(s) associated with a given GSS name 392 object for a given name attribute. 394 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 395 for order preservation; this has been discussed on the KITTEN WG 396 mailing list and the consensus seems to be that, indeed, that was 397 always the intention. It should be noted however that the order 398 presented does not always reflect an underlying order of the 399 mechanism specific source of the attribute values. 401 8.1. C-Bindings 403 The C-bindings of GSS_Get_name_attribute() requires one function call 404 per-attribute value, for multi-valued name attributes. This is done 405 by using a single gss_buffer_t for each value and an input/output 406 integer parameter to distinguish initial and subsequent calls and to 407 indicate when all values have been obtained. 409 The 'more' input/output parameter should point to an integer variable 410 whose value, on first call to gss_name_attribute_get() MUST be -1, 411 and whose value upon function call return will be non-zero to 412 indicate that additional values remain, or zero to indicate that no 413 values remain. The caller should not modify this parameter after the 414 initial call. 416 OM_uint32 gss_get_name_attribute( 417 OM_uint32 *minor_status, 418 gss_name_t name, 419 gss_OID attr, 420 int *authenticated, 421 int *negative, 422 int *mapped, 423 int *critical, 424 gss_buffer_t value, 425 gss_buffer_t display_value, 426 int *more 427 ); 429 9. GSS_Set_name_attribute() 431 Inputs: 433 o name NAME, 435 o critical BOOLEAN, 437 o negative BOOLEAN, 439 o attr OBJECT IDENTIFIER, 441 o values SET OF OCTET STRING 443 Outputs: 445 o major_status INTEGER, 447 o minor_status INTEGER 449 Return major_status codes: 451 o GSS_S_COMPLETE indicates no error. 453 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 454 known or could not be set. 456 o GSS_S_FAILURE indicates a general error. 458 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 459 for order preservation; this has been discussed on the KITTEN WG 460 mailing list and the consensus seems to be that, indeed, that was 461 always the intention. It should be noted that underlying mechanisms 462 may not respect the given order. 464 9.1. C-Bindings 466 The C-bindings of GSS_Set_name_attribute() requires one function call 467 per-attribute value, for multi-valued name attributes -- each call 468 adds one value. To replace an attribute's every value delete the 469 attribute's values first with GSS_Delete_name_attribute(). 471 OM_uint32 gss_set_name_attribute( 472 OM_uint32 *minor_status, 473 gss_name_t name, 474 int critical, 475 int negative, 476 gss_OID attr, 477 gss_buffer_t value 478 ); 480 10. GSS_Delete_name_attribute() 482 Inputs: 484 o name NAME, 486 o attr OBJECT IDENTIFIER, 488 Outputs: 490 o major_status INTEGER, 492 o minor_status INTEGER 494 Return major_status codes: 496 o GSS_S_COMPLETE indicates no error. 498 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 499 known. 501 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 502 attempted eg deleting a negative attribute. 504 o GSS_S_FAILURE indicates a general error. 506 Deletion of negative authenticated attributes from NAME objects MUST 507 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 509 10.1. C-Bindings 511 OM_uint32 gss_delete_name_attribute( 512 OM_uint32 *minor_status, 513 gss_name_t name, 514 gss_OID attr 515 ); 517 11. GSS_Export_name_composite() 519 Inputs: 521 o name NAME 523 Outputs: 525 o major_status INTEGER, 527 o minor_status INTEGER, 529 o exp_composite_name OCTET STRING 531 Return major_status codes: 533 o GSS_S_COMPLETE indicates no error. 535 o GSS_S_FAILURE indicates a general error. 537 This function outputs a token which can be imported with 538 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 539 and which preserves any name attribute information associated with 540 the input name (which GSS_Export_name() may well not). The token 541 format is no specified here as this facility is intended for inter- 542 process communication only; however, all such tokens MUST start with 543 a two-octet token ID, hex 04 02, in network byte order. 545 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 547 11.1. C-Bindings 549 OM_uint32 gss_export_name_composite( 550 OM_uint32 *minor_status, 551 gss_name_t name, 552 gss_buffer_t exp_composite_name 553 ); 555 12. GSS_Map_name_to_any() 557 Inputs: 559 o name NAME, 561 o authenticated BOOLEAN, -- if TRUE only authenticated attributes 562 will be included 564 o type_id OBJECT IDENTIFIER 566 Outputs: 568 o major_status INTEGER, 570 o minor_status INTEGER, 572 o output ANY DEFINED BY type_id 574 Return major_status codes: 576 o GSS_S_COMPLETE indicates no error. 578 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 579 not be done. The minor status code may provide additional 580 information. 582 o GSS_S_FAILURE indicates a general error. The minor status code 583 may provide additional information. 585 Whereas name attribute's values are encoded in some network 586 representation applications often require native, language- and/or 587 platform-specific data types. This function provides access to such 588 types. 590 12.1. C-Bindings 591 typedef struct gss_any *gss_any_t; 592 OM_uint32 gss_map_name_to_any( 593 OM_uint32 *minor_status, 594 gss_name_t name, 595 int authenticated, 596 gss_OID type_id, 597 gss_any_t output 598 ); 600 Note the new C bindings type, gss_any_t. We define it as a pointer 601 to an incompletely declared struct. 603 13. GSS_Release_any_name_mapping() 605 Inputs: 607 o name NAME, 609 o type_id OBJECT IDENTIFIER, 611 o input ANY DEFINED BY type_id 613 Outputs: 615 o major_status INTEGER, 617 o minor_status INTEGER, 619 Return major_status codes: 621 o GSS_S_COMPLETE indicates no error. 623 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 624 not be done. The minor status code may provide additional 625 information. 627 o GSS_S_FAILURE indicates a general error. The minor status code 628 may provide additional information. 630 This function releases, if possible, the objects of language- and/or 631 platform-specific types output by GSS_Map_name_to_any(). If such 632 types have native release functions applications MAY use either those 633 or this function to release the given object. 635 13.1. C-Bindings 636 typedef struct gss_any *gss_any_t; 637 OM_uint32 gss_release_any_name_mapping( 638 OM_uint32 *minor_status, 639 gss_name_t name, 640 gss_OID type_id, 641 gss_any_t *input 642 ); 644 14. IANA Considerations 646 This document creates a namespace of GSS-API name attributes. 647 Attributes are named by OID, so no single authority might be needed 648 for allocation, however, in the interest of providing the community 649 with an authority for name attribute OID allocation and a way to find 650 the existing set of name attributes, the IANA should establish both, 651 a single OID off of which name attributes could be allocated, and a 652 registry of known GSS name attributes. 654 GSS-API name attribute registry entries should contain all the 655 information that GSS_Inquire_name_attribute() may return about the 656 given name attributes and their OIDs: 658 o a name attribute OID (this is a unique key) 660 o a name attribute symbolic name, starting with "GSS_C_NA_" (this is 661 a unique key) 663 o a brief description, in English 665 o whether the attribute is useful as the subject of access control 666 list entries 668 o whether the attribute is useful as an indicator of trust 670 o an optional normative reference to documentation for the given 671 name attribute 673 The allocation and registration policy should be first come, first 674 served. Registry entries' OIDs need not be based on the base OID 675 given above. 677 15. Security Considerations 679 This document extends the GSS-API naming model to include support for 680 name attributes. The intention is that name attributes are to be 681 used as a basis for (among other things) authorization decisions or 682 application personalization for applications relying on GSS-API 683 security contexts. 685 The security of the application may be critically dependent on the 686 security of the attributes. This document classifies attributes as 687 asserted or authenticated. Only authenticated attributes MUST be 688 used if the attribute has security implications for the application 689 (eg authorization decisions) since asserted attributes may easily be 690 controlled by the peer directly. 692 It is important to understand the meaning of 'authenticated' in this 693 setting. It does not mean that any semantic of the attribute is 694 claimed to be true. The only implication is that a trusted third 695 party has asserted the attribute as opposed to the attribute being 696 asserte by the peer itself. Any additional semantics is always the 697 result of applying policy. For instance in a given deployment the 698 mail attribute of the subject may be authenticated and sourced from 699 an email system where 'correct' values are kept. In another setting 700 users may be allowed to modify their mail addresses freely. In both 701 cases the 'mail' attribute may be authenticated by virtue of being 702 included in signed SAML attribute assertions lor by other means 703 authenticated by the underlying mechanism. 705 When the underlying security mechanism does not provide a permanent 706 unique identity (eg anonymous kerberos) the GSS-API naming extensions 707 may be used to provide a replacement permanent unique identity 708 attribute which in this case may be unique for each relying party. 709 This is analogous to the Liberty Alliance targetedID attribute and 710 has similar security implications. 712 16. Normative References 714 [I-D.GSS-NAMING] 715 Hartman, S., "Desired Enhancements to GSSAPI Naming", 716 draft-ietf-kitten-gss-naming-01.txt (work in progress), 717 February 2005. 719 [I-D.ietf-krb-wg-kerberos-clarifications] 720 Neuman, C., "The Kerberos Network Authentication Service 721 (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work 722 in progress), September 2004. 724 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 725 Specification", STD 8, RFC 854, May 1983. 727 [RFC1035] Mockapetris, P., "Domain names - implementation and 728 specification", STD 13, RFC 1035, November 1987. 730 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 731 (SPKM)", RFC 2025, October 1996. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 737 Specification", RFC 2203, September 1997. 739 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 740 Negotiation Mechanism", RFC 2478, December 1998. 742 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 743 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 744 RFC 2623, June 1999. 746 [RFC2743] Linn, J., "Generic Security Service Application Program 747 Interface Version 2, Update 1", RFC 2743, January 2000. 749 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 750 C-bindings", RFC 2744, January 2000. 752 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 753 Signing Authority", RFC 3008, November 2000. 755 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 756 X.509 Public Key Infrastructure Certificate and 757 Certificate Revocation List (CRL) Profile", RFC 3280, 758 April 2002. 760 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 761 Beame, C., Eisler, M., and D. Noveck, "Network File System 762 (NFS) version 4 Protocol", RFC 3530, April 2003. 764 Authors' Addresses 766 Nicolas Williams 767 Sun Microsystems 768 5300 Riata Trace Ct 769 Austin, TX 78727 770 US 772 Email: Nicolas.Williams@sun.com 774 Leif Johansson 775 Stockholm university 776 Avdelningen foer IT och Media 777 Stockholm SE-106 91 779 Email: leifj@it.su.se 780 URI: http://people.su.se/~leifj/