idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2010) is 5053 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: December 26, 2010 SUNET 6 June 24, 2010 8 GSS-API Naming Extensions 9 draft-ietf-kitten-gssapi-naming-exts-08.txt 11 Abstract 13 The Generic Security Services API (GSS-API) provides a simple naming 14 architecture that supports name-based authorization. This document 15 introduces new APIs that extend the GSS-API naming model to support 16 name attribute transfer between GSS-API peers. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 26, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Conventions used in this document . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 3 67 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 68 5. Attribute Name Syntax . . . . . . . . . . . . . . . . . . 4 69 6. Mapping Mechanism Facilities to Name Attributes . . . . . 4 70 6.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 71 6.2. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6.2.1. Standard PKIX Certificate Extensions . . . . . . . . . . . 5 73 6.2.2. Other PKIX Certificate Extensions and Attributes . . . . . 5 74 6.3. SAML attribute assertions . . . . . . . . . . . . . . . . 6 75 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 77 7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 79 7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 81 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 9 83 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 85 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 11 87 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 89 9. Security Considerations . . . . . . . . . . . . . . . . . 12 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . 13 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 95 1. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119] . 101 2. Introduction 103 As described in [RFC4768] the GSS-API's naming architecture suffers 104 from certain limitations. This document proposes concrete GSS-API 105 extensions. 107 A number of extensions to the GSS-API [RFC2743] and its C Bindings 108 [RFC2744] are described herein. The goal is to make information 109 modeled as "name attributes" available to applications. Such 110 information MAY for instance be used by applications to make 111 authorization-decisions. For example, Kerberos V authorization data 112 elements, both in their raw forms, as well as mapped to more useful 113 value types, can be made available to GSS-API applications through 114 these interfaces. 116 The model is that GSS names have attributes. The attributes of a 117 name may be authenticated (eg an X509 attribute certificate or signed 118 SAML attribute assertion), or may have been set on a GSS name for the 119 purpose of locally "asserting" the attribute during credential 120 acquisition or security context exchange. Name attributes' values 121 are network representations thereof (e.g., the actual value octets of 122 the contents of an X.509 certificate extension, for example) and are 123 intended to be useful for constructing portable access control 124 facilities. Applications may often require language- or platform- 125 specific data types, rather than network representations of name 126 attributes, so a function is provided to obtain objects of such types 127 associated with names and name attributes. 129 3. Name Attribute Authenticity 131 An attribute is 'authenticated' iff there is a secure association 132 between the attribute (and its values) and the trusted source of the 133 peer credential. Examples of authenticated attributes are (any part 134 of) the signed portion of an X.509 certificate or AD-KDCIssued 135 authorization-data elements in Kerberos V Tickets provided of course 136 that the authenticity of the respective security associations (eg 137 signatures) have been verified. 139 Note that the fact that an attribute is authenticated does not imply 140 anything about the semantics of the attribute nor that the trusted 141 credential source was authorized to assert the attribute. Such 142 interpretations SHOULD be the result of applying local policy to the 143 attribute. 145 An un-authentciated attribute is called _asserted_ in what 146 follows.This is not to be confused with other uses of the word 147 asserted or assertion eg "SAML attribute assertion", the attributes 148 of which may be authenticated in the sense of this document for 149 instance if the SAML attribute assertion was signed by a key trusted 150 by the peer. 152 4. Name Attributes/Values as ACL Subjects 154 To facilitate the development of portable applications that make use 155 of name attributes to construct and evaluate portable ACLs the GSS- 156 API makes name attribute values available in canonical network 157 encodings thereof. 159 5. Attribute Name Syntax 161 Attribute names are represented as opaque STRING elements in the API 162 described below. These attribute names have syntax and semantics 163 that are understood by the application and by the lower-layer 164 implementations (some of which are described below). In order to 165 present a consistent namespace to the application and at the same 166 time impose as few transformation requirements as possible to lower- 167 layer implementations attribute names SHOULD be URIs. 169 Technologies used in lower-layer protocols may of course use 170 attribute naming that are not based on URIs. Notably X.509 171 certificates will use OIDs for most naming purposes. In this case 172 OIDs MUST be mapped into URIs as described in [RFC3061] MUST be used. 173 If for example the OID 1.2.3 denotes an Extended Key Usage (cf 174 below), the corresponding GSS-API attribute name MUST be represented 175 as urn:oid:1.2.3. 177 6. Mapping Mechanism Facilities to Name Attributes 179 In this section we describe two important examples of lower-layer 180 implementations of this API. These examples are not mandatory to 181 implement and are only provided for reference. The use of [RFC2119]- 182 terms in this section is limited to those implementations of the GSS- 183 API naming extensions that choose to implement these lower-layer 184 technologies. Future mappings SHOULD be documented as RFCs. 186 Kerberos V [RFC4120] and the Simple Public-Key GSS-API Mechanism, 187 SPKM described in [RFC2025], both support the concept and encoding of 188 containers of "authorization-data" as described in [RFC4120]. 190 PKIX [RFC5280] supports a number of attribute-like features, like 191 Extended Key Usage values (EKUs) and certificate extensions. 193 6.1. Kerberos V and SPKM Authorization-Data 195 Authorization-data non-container elements asserted in Kerberos V AP- 196 REQ Authenticators MUST be mapped into *asserted* GSS-API name 197 attributes. 199 Authorization-data included in Kerberos V Tickets that is not 200 contained in AD-KDCIssued (with valid signature) MUST be mapped into 201 *asserted* GSS-API name attributes. Conversely, authorization-data 202 elements in Kerberos V Tickets contained by AD-KDCIssued MUST be 203 mapped into *authenticated* GSS-API name attributes. 205 6.2. PKIX 207 6.2.1. Standard PKIX Certificate Extensions 209 PKIX certificate extensions MAY/SHOULD/MUST (see comment above) be 210 represented as *authenticated* GSS-API name attributes named using 211 the _same_ OID mapped to a URN. 213 SubjectAltNames and Extended Key Usage OIDs, specifically, MUST be 214 represented as *authenticated* GSS-API name attributes; see below. 215 Certificate extensions MUST be represented as GSS-API name attributes 216 named using the OIDs used for the extensions (represented as URNs). 217 The value associated with Extended Key Usage attributes MUST have 218 NULL value represented as a zero-length OCTET STRING. 220 The standard PKIX certificate key usage (KUs, but not EKUs), MUST NOT 221 be represented as GSS-API name attributes. 223 PKIX certificate subjectAltNames MUST be mapped as *authenticated* 224 GSS-API name attributes. The values SHOULD be the values of the 225 subjectAltName represented as OCTET STRINGs if the type of the 226 subjectAltName supports a unique loss-less representation as string 227 values. Specifically dnsName, ipAddress, uniformResourceLocator and 228 emailAddress MUST be returned using the corresponding string 229 representation of those data types. 231 6.2.2. Other PKIX Certificate Extensions and Attributes 233 Any X.509 certificate extension not covered above SHOULD be 234 represented as GSS-API name attributes with the OID of the X.509 235 extension and with OCTET STRING values containing the encoded value 236 of the extension. 238 6.3. SAML attribute assertions 240 Attributes contained in SAML attribute assertions MUST be mapped to 241 GSS-API name attributes with the same URIs as used in the SAML 242 attribute name. 244 SAML attributes found in SAML attribute assertions MUST NOT be mapped 245 as authenticated unless the SAML attribute assertion was signed by a 246 key trusted by the peer or otherwise protected from unauthorized 247 modification. 249 7. API 251 7.1. GSS_Display_name_ext() 253 Inputs: 255 o name NAME, 257 o display_as_name_type OBJECT IDENTIFIER 259 Outputs: 261 o major_status INTEGER, 263 o minor_status INTEGER, 265 o display_name STRING 267 Return major_status codes: 269 o GSS_S_COMPLETE indicates no error. 271 o GSS_S_UNAVAILABLE indicates that the given name could not be 272 displayed using the syntax of the given name type. 274 o GSS_S_FAILURE indicates a general error. 276 This function displays a given name using the given name syntax, if 277 possible. This operation may require mapping MNs to generic name 278 syntaxes or generic name syntaxes to mechanism-specific name 279 syntaxes; such mappings may not always be feasible and MAY be inexact 280 or lossy, therefore this function may fail. 282 7.1.1. C-Bindings 284 OM_uint32 GSS_Display_name_ext( 285 OM_uint32 *minor_status, 286 gss_name_t name, 287 gss_OID display_as_name_type, 288 gss_buffer_t display_name 289 ); 291 7.2. GSS_Inquire_name() 293 Inputs: 295 o name NAME 297 Outputs: 299 o major_status INTEGER, 301 o minor_status INTEGER, 303 o name_is_MN BOOLEAN, 305 o mn_mech OBJECT IDENTIFIER, 307 o attrs SET OF OCTET STRING 309 Return major_status codes: 311 o GSS_S_COMPLETE indicates no error. 313 o GSS_S_FAILURE indicates a general error. 315 This function outputs the set (represented as a NULL terminated array 316 of gss_buffer_t) of attributes of a name. It also indicates if a 317 given NAME is an MN or not and, if it is, what mechanism it's an MN 318 of. The gss_buffer_set_t type and associated API is defined in 319 [GFD.024] 321 7.2.1. C-Bindings 323 OM_uint32 gss_inquire_name( 324 OM_uint32 *minor_status, 325 gss_name_t name, 326 int name_is_MN, 327 gss_OID *MN_mech, 328 gss_buffer_set_t *attrs 329 ); 331 7.3. GSS_Get_name_attribute() 333 Inputs: 335 o name NAME, 337 o attr STRING 339 Outputs: 341 o major_status INTEGER, 343 o minor_status INTEGER, 345 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 346 peer credential source. 348 o complete BOOLEAN -- TRUE iff this represents a complete set of 349 values for the name. 351 o values SET OF OCTET STRING, 353 o display_values SET OF STRING 355 Return major_status codes: 357 o GSS_S_COMPLETE indicates no error. 359 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 360 known or set. 362 o GSS_S_FAILURE indicates a general error. 364 This function outputs the value(s) associated with a given GSS name 365 object for a given name attribute. 367 The complete flag denotes that (if TRUE) the set of values represents 368 a complete set of values for this name. The peer being an 369 authoritative source of information for this attribute is a 370 sufficient condition for the complete flag to be set by the peer. 372 In the federated case when several peers may hold some of the 373 attributes about a name this flag may be highly dangerous and SHOULD 374 NOT be used. 376 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 377 for order preservation; this has been discussed on the KITTEN WG 378 mailing list and the consensus seems to be that, indeed, that was 379 always the intention. It should be noted however that the order 380 presented does not always reflect an underlying order of the 381 mechanism specific source of the attribute values. 383 7.3.1. C-Bindings 385 The C-bindings of GSS_Get_name_attribute() requires one function call 386 per-attribute value, for multi-valued name attributes. This is done 387 by using a single gss_buffer_t for each value and an input/output 388 integer parameter to distinguish initial and subsequent calls and to 389 indicate when all values have been obtained. 391 The 'more' input/output parameter should point to an integer variable 392 whose value, on first call to gss_name_attribute_get() MUST be -1, 393 and whose value upon function call return will be non-zero to 394 indicate that additional values remain, or zero to indicate that no 395 values remain. The caller should not modify this parameter after the 396 initial call. The status of the complete and authenticated flags 397 MUST NOT change between multiple calls to iterate over values for an 398 attribute. 400 OM_uint32 gss_get_name_attribute( 401 OM_uint32 *minor_status, 402 gss_name_t name, 403 gss_buffer_t attr, 404 int *authenticated, 405 int *complete, 406 gss_buffer_t value, 407 gss_buffer_t display_value, 408 int *more 409 ); 411 7.4. GSS_Set_name_attribute() 413 Inputs: 415 o name NAME, 417 o complete BOOLEAN, -- TRUE iff this represents a complete set of 418 values for the name. 420 o attr STRING, 422 o values SET OF OCTET STRING 424 Outputs: 426 o major_status INTEGER, 428 o minor_status INTEGER 430 Return major_status codes: 432 o GSS_S_COMPLETE indicates no error. 434 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 435 known or could not be set. 437 o GSS_S_FAILURE indicates a general error. 439 The complete flag denotes that (if TRUE) the set of values represents 440 a complete set of values for this name. The peer being an 441 authoritative source of information for this attribute is a 442 sufficient condition for the complete flag to be set by the peer. 444 In the federated case when several peers may hold some of the 445 attributes about a name this flag may be highly dangerous and SHOULD 446 NOT be used. 448 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 449 for order preservation; this has been discussed on the KITTEN WG 450 mailing list and the consensus seems to be that, indeed, that was 451 always the intention. It should be noted that underlying mechanisms 452 may not respect the given order. 454 7.4.1. C-Bindings 456 The C-bindings of GSS_Set_name_attribute() requires one function call 457 per-attribute value, for multi-valued name attributes -- each call 458 adds one value. To replace an attribute's every value delete the 459 attribute's values first with GSS_Delete_name_attribute(). 461 OM_uint32 gss_set_name_attribute( 462 OM_uint32 *minor_status, 463 gss_name_t name, 464 int complete, 465 gss_buffer_t attr, 466 gss_buffer_t value 468 ); 470 7.5. GSS_Delete_name_attribute() 472 Inputs: 474 o name NAME, 476 o attr STRING, 478 Outputs: 480 o major_status INTEGER, 482 o minor_status INTEGER 484 Return major_status codes: 486 o GSS_S_COMPLETE indicates no error. 488 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 489 known. 491 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 492 attempted eg deleting a negative attribute. 494 o GSS_S_FAILURE indicates a general error. 496 Deletion of negative authenticated attributes from NAME objects MUST 497 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 499 7.5.1. C-Bindings 501 OM_uint32 gss_delete_name_attribute( 502 OM_uint32 *minor_status, 503 gss_name_t name, 504 gss_buffer_t attr 505 ); 507 7.6. GSS_Export_name_composite() 509 Inputs: 511 o name NAME 512 Outputs: 514 o major_status INTEGER, 516 o minor_status INTEGER, 518 o exp_composite_name OCTET STRING 520 Return major_status codes: 522 o GSS_S_COMPLETE indicates no error. 524 o GSS_S_FAILURE indicates a general error. 526 This function outputs a token which can be imported with 527 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 528 and which preserves any name attribute information associated with 529 the input name (which GSS_Export_name() may well not). The token 530 format is no specified here as this facility is intended for inter- 531 process communication only; however, all such tokens MUST start with 532 a two-octet token ID, hex 04 02, in network byte order. 534 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 536 7.6.1. C-Bindings 538 OM_uint32 gss_export_name_composite( 539 OM_uint32 *minor_status, 540 gss_name_t name, 541 gss_buffer_t exp_composite_name 542 ); 544 8. IANA Considerations 546 This document creates a namespace of GSS-API name attributes. 547 Attributes are named by URIs, so no single authority is technically 548 needed for allocation. However future deployment experience may 549 indicate the need for an IANA registry for URIs used to reference 550 names specified by IETF standards. It is expected that this will be 551 a registry of URNs but this document provides no further guidance on 552 this registry. 554 9. Security Considerations 556 This document extends the GSS-API naming model to include support for 557 name attributes. The intention is that name attributes are to be 558 used as a basis for (among other things) authorization decisions or 559 personalization for applications relying on GSS-API security 560 contexts. 562 The security of the application may be critically dependent on the 563 security of the attributes. This document classifies attributes as 564 asserted or authenticated. Asserted (non-authenticated) attributes 565 MUST NOT be used if the attribute has security implications for the 566 application (eg authorization decisions) since asserted attributes 567 may easily be controlled by the peer directly. 569 It is important to understand the meaning of 'authenticated' in this 570 setting. Authenticated does not imply that any semantic of the 571 attribute is claimed to be true. The only implication is that a 572 trusted third party has asserted the attribute as opposed to the 573 attribute being asserte by the peer itself. Any additional semantics 574 is always the result of applying policy. For instance in a given 575 deployment the mail attribute of the subject may be authenticated and 576 sourced from an email system where 'authoritive' values are kept. In 577 another situations users may be allowed to modify their mail 578 addresses freely. In both cases the 'mail' attribute may be 579 authenticated by virtue of being included in signed SAML attribute 580 assertions or by other means authenticated by the underlying 581 mechanism. 583 When the underlying security mechanism does not provide a permanent 584 unique identity (eg anonymous kerberos) the GSS-API naming extensions 585 may be used to provide a replacement permanent unique identity 586 attribute which in this case may be unique for each peer party. This 587 is analogous to the SAML permanentIdentifier attribute and has 588 comparable security and privacy properties and implications. 590 10. References 592 10.1. Normative References 594 [GFD.024] Argonne National Laboratory, National Center for 595 Supercomputing Applications, Argonne National Laboratory, 596 and Argonne National Laboratory, "GSS-API Extensions", 597 GFD GFD.024, June 2004. 599 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 600 (SPKM)", RFC 2025, October 1996. 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 [RFC2743] Linn, J., "Generic Security Service Application Program 606 Interface Version 2, Update 1", RFC 2743, January 2000. 608 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 609 C-bindings", RFC 2744, January 2000. 611 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 612 Kerberos Network Authentication Service (V5)", RFC 4120, 613 July 2005. 615 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 616 Housley, R., and W. Polk, "Internet X.509 Public Key 617 Infrastructure Certificate and Certificate Revocation List 618 (CRL) Profile", RFC 5280, May 2008. 620 10.2. Informative References 622 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 623 RFC 3061, February 2001. 625 [RFC4768] Hartman, S., "Desired Enhancements to Generic Security 626 Services Application Program Interface (GSS-API) Version 3 627 Naming", RFC 4768, December 2006. 629 Authors' Addresses 631 Nicolas Williams 632 Sun Microsystems 633 5300 Riata Trace Ct 634 Austin, TX 78727 635 US 637 Email: Nicolas.Williams@sun.com 639 Leif Johansson 640 Swedish University Network 641 Thulegatan 11 642 Stockholm 643 Sweden 645 Email: leifj@sunet.se 646 URI: http://www.sunet.se