idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (May 18, 2010) is 5091 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) ** Obsolete normative reference: RFC 3001 (Obsoleted by RFC 3061) == Outdated reference: A later version (-05) exists of draft-ietf-kitten-gss-naming-01 Summary: 2 errors (**), 0 flaws (~~), 2 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: November 19, 2010 SUNET 6 May 18, 2010 8 GSS-API Naming Extensions 9 draft-ietf-kitten-gssapi-naming-exts-07.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 to IETF 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), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on November 19, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Conventions used in this document . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 3 61 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 62 5. Attribute Name Syntax . . . . . . . . . . . . . . . . . . 4 63 6. Mapping Mechanism Facilities to Name Attributes . . . . . 4 64 6.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 65 6.2. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.2.1. Standard PKIX Certificate Extensions . . . . . . . . . . . 5 67 6.2.2. Other PKIX Certificate Extensions and Attributes . . . . . 5 68 6.3. SAML attribute assertions . . . . . . . . . . . . . . . . 6 69 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 71 7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 73 7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 75 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 9 77 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 79 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 11 81 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 83 9. Security Considerations . . . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . 13 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 89 1. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119] . 95 2. Introduction 97 As described in [I-D.GSS-NAMING] the GSS-API's naming architecture 98 suffers from certain limitations. This document proposes concrete 99 GSS-API extensions as outlined in [I-D.GSS-NAMING]. 101 A number of extensions to the GSS-API [RFC2743] and its C Bindings 102 [RFC2744] are described herein. The goal is to make information 103 modeled as "name attributes" available to applications. Such 104 information MAY for instance be used by applications to make 105 authorization-decisions. For example, Kerberos V authorization data 106 elements, both in their raw forms, as well as mapped to more useful 107 value types, can be made available to GSS-API applications through 108 these interfaces. 110 The model is that GSS names have attributes. The attributes of a 111 name may be authenticated (eg an X509 attribute certificate or signed 112 SAML attribute assertion), or may have been set on a GSS name for the 113 purpose of locally "asserting" the attribute during credential 114 acquisition or security context exchange. Name attributes' values 115 are network representations thereof (e.g., the actual value octets of 116 the contents of an X.509 certificate extension, for example) and are 117 intended to be useful for constructing portable access control 118 facilities. Applications may often require language- or platform- 119 specific data types, rather than network representations of name 120 attributes, so a function is provided to obtain objects of such types 121 associated with names and name attributes. 123 3. Name Attribute Authenticity 125 An attribute is 'authenticated' iff there is a secure association 126 between the attribute (and its values) and the trusted source of the 127 peer credential. Examples of authenticated attributes are (any part 128 of) the signed portion of an X.509 certificate or AD-KDCIssued 129 authorization-data elements in Kerberos V Tickets provided of course 130 that the authenticity of the respective security associations (eg 131 signatures) have been verified. 133 Note that the fact that an attribute is authenticated does not imply 134 anything about the semantics of the attribute nor that the trusted 135 credential source was authorized to assert the attribute. Such 136 interpretations SHOULD be the result of applying local policy to the 137 attribute. 139 An un-authentciated attribute is called _asserted_ in what 140 follows.This is not to be confused with other uses of the word 141 asserted or assertion eg "SAML attribute assertion", the attributes 142 of which may be authenticated in the sense of this document for 143 instance if the SAML attribute assertion was signed by a key trusted 144 by the peer. 146 4. Name Attributes/Values as ACL Subjects 148 To facilitate the development of portable applications that make use 149 of name attributes to construct and evaluate portable ACLs the GSS- 150 API makes name attribute values available in canonical network 151 encodings thereof. 153 5. Attribute Name Syntax 155 Attribute names are represented as opaque STRING elements in the API 156 described below. These attribute names have syntax and semantics 157 that are understood by the application and by the lower-layer 158 implementations (some of which are described below). In order to 159 present a consistent namespace to the application and at the same 160 time impose as few transformation requirements as possible to lower- 161 layer implementations attribute names SHOULD be URIs. 163 Technologies used in lower-layer protocols may of course use 164 attribute naming that are not based on URIs. Notably X.509 165 certificates will use OIDs for most naming purposes. In this case 166 OIDs MUST be mapped into URIs as described in [RFC3001] MUST be used. 167 If for example the OID 1.2.3 denotes an Extended Key Usage (cf 168 below), the corresponding GSS-API attribute name MUST be represented 169 as urn:oid:1.2.3. 171 6. Mapping Mechanism Facilities to Name Attributes 173 In this section we describe two important examples of lower-layer 174 implementations of this API. These examples are not mandatory to 175 implement and are only provided for reference. The use of [RFC2119]- 176 terms in this section is limited to those implementations of the GSS- 177 API naming extensions that choose to implement these lower-layer 178 technologies. Future mappings SHOULD be documented as RFCs. 180 Kerberos V [RFC4120] and the Simple Public-Key GSS-API Mechanism, 181 SPKM described in [RFC2025], both support the concept and encoding of 182 containers of "authorization-data" as described in [RFC4120]. 184 PKIX [RFC5280] supports a number of attribute-like features, like 185 Extended Key Usage values (EKUs) and certificate extensions. 187 6.1. Kerberos V and SPKM Authorization-Data 189 Authorization-data non-container elements asserted in Kerberos V AP- 190 REQ Authenticators MUST be mapped into *asserted* GSS-API name 191 attributes. 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 6.2. PKIX 201 6.2.1. Standard PKIX Certificate Extensions 203 PKIX certificate extensions MAY/SHOULD/MUST (see comment above) be 204 represented as *authenticated* GSS-API name attributes named using 205 the _same_ OID mapped to a URN. 207 SubjectAltNames and Extended Key Usage OIDs, specifically, MUST be 208 represented as *authenticated* GSS-API name attributes; see below. 209 Certificate extensions MUST be represented as GSS-API name attributes 210 named using the OIDs used for the extensions (represented as URNs). 211 The value associated with Extended Key Usage attributes MUST have 212 NULL value represented as a zero-length OCTET STRING. 214 The standard PKIX certificate key usage (KUs, but not EKUs), MUST NOT 215 be represented as GSS-API name attributes. 217 PKIX certificate subjectAltNames MUST be mapped as *authenticated* 218 GSS-API name attributes. The values SHOULD be the values of the 219 subjectAltName represented as OCTET STRINGs if the type of the 220 subjectAltName supports a unique loss-less representation as string 221 values. Specifically dnsName, ipAddress, uniformResourceLocator and 222 emailAddress MUST be returned using the corresponding string 223 representation of those data types. 225 6.2.2. Other PKIX Certificate Extensions and Attributes 227 Any X.509 certificate extension not covered above SHOULD be 228 represented as GSS-API name attributes with the OID of the X.509 229 extension and with OCTET STRING values containing the encoded value 230 of the extension. 232 6.3. SAML attribute assertions 234 Attributes contained in SAML attribute assertions MUST be mapped to 235 GSS-API name attributes with the same URIs as used in the SAML 236 attribute name. 238 SAML attributes found in SAML attribute assertions MUST NOT be mapped 239 as authenticated unless the SAML attribute assertion was signed by a 240 key trusted by the peer or otherwise protected from unauthorized 241 modification. 243 7. API 245 7.1. GSS_Display_name_ext() 247 Inputs: 249 o name NAME, 251 o display_as_name_type OBJECT IDENTIFIER 253 Outputs: 255 o major_status INTEGER, 257 o minor_status INTEGER, 259 o display_name STRING 261 Return major_status codes: 263 o GSS_S_COMPLETE indicates no error. 265 o GSS_S_UNAVAILABLE indicates that the given name could not be 266 displayed using the syntax of the given name type. 268 o GSS_S_FAILURE indicates a general error. 270 This function displays a given name using the given name syntax, if 271 possible. This operation may require mapping MNs to generic name 272 syntaxes or generic name syntaxes to mechanism-specific name 273 syntaxes; such mappings may not always be feasible and MAY be inexact 274 or lossy, therefore this function may fail. 276 7.1.1. C-Bindings 278 OM_uint32 GSS_Display_name_ext( 279 OM_uint32 *minor_status, 280 gss_name_t name, 281 gss_OID display_as_name_type, 282 gss_buffer_t display_name 283 ); 285 7.2. GSS_Inquire_name() 287 Inputs: 289 o name NAME 291 Outputs: 293 o major_status INTEGER, 295 o minor_status INTEGER, 297 o name_is_MN BOOLEAN, 299 o mn_mech OBJECT IDENTIFIER, 301 o attrs SET OF OCTET STRING 303 Return major_status codes: 305 o GSS_S_COMPLETE indicates no error. 307 o GSS_S_FAILURE indicates a general error. 309 This function outputs the set (represented as a NULL terminated array 310 of gss_buffer_t) of attributes of a name. It also indicates if a 311 given NAME is an MN or not and, if it is, what mechanism it's an MN 312 of. The gss_buffer_set_t type and associated API is defined in 313 [GFD.024] 315 7.2.1. C-Bindings 317 OM_uint32 gss_inquire_name( 318 OM_uint32 *minor_status, 319 gss_name_t name, 320 int name_is_MN, 321 gss_OID *MN_mech, 322 gss_buffer_set_t *attrs 323 ); 325 7.3. GSS_Get_name_attribute() 327 Inputs: 329 o name NAME, 331 o attr STRING 333 Outputs: 335 o major_status INTEGER, 337 o minor_status INTEGER, 339 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 340 peer credential source. 342 o complete BOOLEAN -- TRUE iff this represents a complete set of 343 values for the name. 345 o values SET OF OCTET STRING, 347 o display_values SET OF STRING 349 Return major_status codes: 351 o GSS_S_COMPLETE indicates no error. 353 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 354 known or set. 356 o GSS_S_FAILURE indicates a general error. 358 This function outputs the value(s) associated with a given GSS name 359 object for a given name attribute. 361 The complete flag denotes that (if TRUE) the set of values represents 362 a complete set of values for this name. The peer being an 363 authoritative source of information for this attribute is a 364 sufficient condition for the complete flag to be set by the peer. 366 In the federated case when several peers may hold some of the 367 attributes about a name this flag may be highly dangerous and SHOULD 368 NOT be used. 370 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 371 for order preservation; this has been discussed on the KITTEN WG 372 mailing list and the consensus seems to be that, indeed, that was 373 always the intention. It should be noted however that the order 374 presented does not always reflect an underlying order of the 375 mechanism specific source of the attribute values. 377 7.3.1. C-Bindings 379 The C-bindings of GSS_Get_name_attribute() requires one function call 380 per-attribute value, for multi-valued name attributes. This is done 381 by using a single gss_buffer_t for each value and an input/output 382 integer parameter to distinguish initial and subsequent calls and to 383 indicate when all values have been obtained. 385 The 'more' input/output parameter should point to an integer variable 386 whose value, on first call to gss_name_attribute_get() MUST be -1, 387 and whose value upon function call return will be non-zero to 388 indicate that additional values remain, or zero to indicate that no 389 values remain. The caller should not modify this parameter after the 390 initial call. The status of the complete and authenticated flags 391 MUST NOT change between multiple calls to iterate over values for an 392 attribute. 394 OM_uint32 gss_get_name_attribute( 395 OM_uint32 *minor_status, 396 gss_name_t name, 397 gss_buffer_t attr, 398 int *authenticated, 399 int *complete, 400 gss_buffer_t value, 401 gss_buffer_t display_value, 402 int *more 403 ); 405 7.4. GSS_Set_name_attribute() 407 Inputs: 409 o name NAME, 411 o complete BOOLEAN, -- TRUE iff this represents a complete set of 412 values for the name. 414 o attr STRING, 416 o values SET OF OCTET STRING 418 Outputs: 420 o major_status INTEGER, 422 o minor_status INTEGER 424 Return major_status codes: 426 o GSS_S_COMPLETE indicates no error. 428 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 429 known or could not be set. 431 o GSS_S_FAILURE indicates a general error. 433 The complete flag denotes that (if TRUE) the set of values represents 434 a complete set of values for this name. The peer being an 435 authoritative source of information for this attribute is a 436 sufficient condition for the complete flag to be set by the peer. 438 In the federated case when several peers may hold some of the 439 attributes about a name this flag may be highly dangerous and SHOULD 440 NOT be used. 442 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 443 for order preservation; this has been discussed on the KITTEN WG 444 mailing list and the consensus seems to be that, indeed, that was 445 always the intention. It should be noted that underlying mechanisms 446 may not respect the given order. 448 7.4.1. C-Bindings 450 The C-bindings of GSS_Set_name_attribute() requires one function call 451 per-attribute value, for multi-valued name attributes -- each call 452 adds one value. To replace an attribute's every value delete the 453 attribute's values first with GSS_Delete_name_attribute(). 455 OM_uint32 gss_set_name_attribute( 456 OM_uint32 *minor_status, 457 gss_name_t name, 458 int complete, 459 gss_buffer_t attr, 460 gss_buffer_t value 462 ); 464 7.5. GSS_Delete_name_attribute() 466 Inputs: 468 o name NAME, 470 o attr STRING, 472 Outputs: 474 o major_status INTEGER, 476 o minor_status INTEGER 478 Return major_status codes: 480 o GSS_S_COMPLETE indicates no error. 482 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 483 known. 485 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 486 attempted eg deleting a negative attribute. 488 o GSS_S_FAILURE indicates a general error. 490 Deletion of negative authenticated attributes from NAME objects MUST 491 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 493 7.5.1. C-Bindings 495 OM_uint32 gss_delete_name_attribute( 496 OM_uint32 *minor_status, 497 gss_name_t name, 498 gss_buffer_t attr 499 ); 501 7.6. GSS_Export_name_composite() 503 Inputs: 505 o name NAME 506 Outputs: 508 o major_status INTEGER, 510 o minor_status INTEGER, 512 o exp_composite_name OCTET STRING 514 Return major_status codes: 516 o GSS_S_COMPLETE indicates no error. 518 o GSS_S_FAILURE indicates a general error. 520 This function outputs a token which can be imported with 521 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 522 and which preserves any name attribute information associated with 523 the input name (which GSS_Export_name() may well not). The token 524 format is no specified here as this facility is intended for inter- 525 process communication only; however, all such tokens MUST start with 526 a two-octet token ID, hex 04 02, in network byte order. 528 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 530 7.6.1. C-Bindings 532 OM_uint32 gss_export_name_composite( 533 OM_uint32 *minor_status, 534 gss_name_t name, 535 gss_buffer_t exp_composite_name 536 ); 538 8. IANA Considerations 540 This document creates a namespace of GSS-API name attributes. 541 Attributes are named by URIs, so no single authority is technically 542 needed for allocation. However future deployment experience may 543 indicate the need for an IANA registry for URIs used to reference 544 names specified by IETF standards. It is expected that this will be 545 a registry of URNs but this document provides no further guidance on 546 this registry. 548 9. Security Considerations 550 This document extends the GSS-API naming model to include support for 551 name attributes. The intention is that name attributes are to be 552 used as a basis for (among other things) authorization decisions or 553 personalization for applications relying on GSS-API security 554 contexts. 556 The security of the application may be critically dependent on the 557 security of the attributes. This document classifies attributes as 558 asserted or authenticated. Asserted (non-authenticated) attributes 559 MUST NOT be used if the attribute has security implications for the 560 application (eg authorization decisions) since asserted attributes 561 may easily be controlled by the peer directly. 563 It is important to understand the meaning of 'authenticated' in this 564 setting. Authenticated does not imply that any semantic of the 565 attribute is claimed to be true. The only implication is that a 566 trusted third party has asserted the attribute as opposed to the 567 attribute being asserte by the peer itself. Any additional semantics 568 is always the result of applying policy. For instance in a given 569 deployment the mail attribute of the subject may be authenticated and 570 sourced from an email system where 'authoritive' values are kept. In 571 another situations users may be allowed to modify their mail 572 addresses freely. In both cases the 'mail' attribute may be 573 authenticated by virtue of being included in signed SAML attribute 574 assertions or by other means authenticated by the underlying 575 mechanism. 577 When the underlying security mechanism does not provide a permanent 578 unique identity (eg anonymous kerberos) the GSS-API naming extensions 579 may be used to provide a replacement permanent unique identity 580 attribute which in this case may be unique for each peer party. This 581 is analogous to the SAML permanentIdentifier attribute and has 582 comparable security and privacy properties and implications. 584 10. References 586 10.1. Normative References 588 [GFD.024] Argonne National Laboratory, National Center for 589 Supercomputing Applications, Argonne National Laboratory, 590 and Argonne National Laboratory, "GSS-API Extensions", 591 GFD GFD.024, June 2004. 593 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 594 (SPKM)", RFC 2025, October 1996. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC2743] Linn, J., "Generic Security Service Application Program 600 Interface Version 2, Update 1", RFC 2743, January 2000. 602 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 603 C-bindings", RFC 2744, January 2000. 605 [RFC3001] Mealling, M., "A URN Namespace of Object Identifiers", 606 RFC 3001, November 2000. 608 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 609 Kerberos Network Authentication Service (V5)", RFC 4120, 610 July 2005. 612 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 613 Housley, R., and W. Polk, "Internet X.509 Public Key 614 Infrastructure Certificate and Certificate Revocation List 615 (CRL) Profile", RFC 5280, May 2008. 617 10.2. Informative References 619 [I-D.GSS-NAMING] 620 Hartman, S., "Desired Enhancements to GSSAPI Naming", 621 draft-ietf-kitten-gss-naming-01.txt (work in progress), 622 February 2005. 624 Authors' Addresses 626 Nicolas Williams 627 Sun Microsystems 628 5300 Riata Trace Ct 629 Austin, TX 78727 630 US 632 Email: Nicolas.Williams@sun.com 634 Leif Johansson 635 Swedish University Network 636 Thulegatan 11 637 Stockholm 638 Sweden 640 Email: leifj@sunet.se 641 URI: http://www.sunet.se