idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-11.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (May 24, 2011) is 4719 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: 'RFC2025' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC3061' is defined on line 722, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 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 25, 2011 SUNET 6 S. Hartman 7 Painless Security 8 S. Josefsson 9 SJD AB 10 May 24, 2011 12 GSS-API Naming Extensions 13 draft-ietf-kitten-gssapi-naming-exts-11 15 Abstract 17 The Generic Security Services API (GSS-API) provides a simple naming 18 architecture that supports name-based authorization. This document 19 introduces new APIs that extend the GSS-API naming model to support 20 name attribute transfer between GSS-API peers. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 25, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Conventions used in this document . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 4 71 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 5 72 5. Naming Contexts . . . . . . . . . . . . . . . . . . . . . 5 73 6. Representation of Attribute Names . . . . . . . . . . . . 7 74 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.1. SET OF OCTET STRING . . . . . . . . . . . . . . . . . . . 8 76 7.2. Const types . . . . . . . . . . . . . . . . . . . . . . . 8 77 7.3. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 8 78 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.4. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 9 80 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.5. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 10 82 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.6. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 12 84 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.7. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 13 86 7.7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.8. GSS_Export_name_composite() . . . . . . . . . . . . . . . 14 88 7.8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 90 9. Security Considerations . . . . . . . . . . . . . . . . . 15 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . 16 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 96 1. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119] . 102 2. Introduction 104 As described in [RFC4768] the GSS-API's naming architecture suffers 105 from certain limitations. This document proposes concrete GSS-API 106 extensions. 108 A number of extensions to the GSS-API [RFC2743] and its C Bindings 109 [RFC2744] are described herein. The goal is to make information 110 modeled as "name attributes" available to applications. Such 111 information MAY for instance be used by applications to make 112 authorization-decisions. For example, Kerberos V authorization data 113 elements, both in their raw forms, as well as mapped to more useful 114 value types, can be made available to GSS-API applications through 115 these interfaces. 117 The model is that GSS names have attributes. The attributes of a 118 name may be authenticated (eg an X509 attribute certificate or signed 119 SAML attribute assertion), or may have been set on a GSS name for the 120 purpose of locally "asserting" the attribute during credential 121 acquisition or security context exchange. Name attributes' values 122 are network representations thereof (e.g., the actual value octets of 123 the contents of an X.509 certificate extension, for example) and are 124 intended to be useful for constructing portable access control 125 facilities. Applications may often require language- or platform- 126 specific data types, rather than network representations of name 127 attributes, so a function is provided to obtain objects of such types 128 associated with names and name attributes. 130 3. Name Attribute Authenticity 132 An attribute is 'authenticated' iff there is a secure association 133 between the attribute (and its values) and the trusted source of the 134 peer credential. Examples of authenticated attributes are (any part 135 of) the signed portion of an X.509 certificate or AD-KDCIssued 136 authorization-data elements in Kerberos V Tickets provided of course 137 that the authenticity of the respective security associations (eg 138 signatures) have been verified. 140 Note that the fact that an attribute is authenticated does not imply 141 anything about the semantics of the attribute nor that the trusted 142 credential source was authorized to assert the attribute. Such 143 interpretations SHOULD be the result of applying local policy to the 144 attribute. 146 An un-authentciated attribute is called _asserted_ in what 147 follows.This is not to be confused with other uses of the word 148 asserted or assertion eg "SAML attribute assertion", the attributes 149 of which may be authenticated in the sense of this document for 150 instance if the SAML attribute assertion was signed by a key trusted 151 by the peer. 153 4. Name Attributes/Values as ACL Subjects 155 To facilitate the development of portable applications that make use 156 of name attributes to construct and evaluate portable ACLs the GSS- 157 API makes name attribute values available in canonical network 158 encodings thereof. 160 5. Naming Contexts 162 Several factors influence the context in which a name attribute is 163 interpreted. One is the trust context. 165 As discussed previously, applications apply local policy to determine 166 whether a particular peer credential issuer is trusted to make a 167 given statement. Different GSS-API mechanisms and deployments have 168 different trust models surrounding attributes they provide about a 169 name. 171 For example, Kerberos deployments in the enterprise typically trust a 172 KDC to make any statement about principals in a realm. This includes 173 attributes such as group membership. 175 In contrast, in a federated SAML environment, the identity provider 176 typically exists in a different organization than the acceptor. In 177 this case, the set of group memberships or entitlements that the IDP 178 is permitted to make needs to be filtered by the policy of the 179 acceptor and federation. 181 So even an attribute containing the same information such as e-mail 182 address would need to be treated differently by the application in 183 the context of an enterprise deployment from the context of a 184 federation. 186 Another aspect related to trust is the role of the credential issuer 187 in providing the attribute. Consider Kerberos PKINIT (RFC 4556). In 188 this protocol, a public key and associated certificate are used to 189 authenticate to a Kerberos KDC. Consider how attributes related to a 190 pkinit certificate should be made available in GSS-API 191 authentications based on the Kerberos ticket. In some deployments 192 the certificate may be fully trusted; in including the certificate 193 information in the ticket, the KDC permits the acceptor to trust the 194 information in the certificate just as if the KDC itself had made 195 these statements. In other deployments, the KDC may have authorized 196 a hash of the certificate without evaluating the content of the 197 certificate or generally trusting the issuing certificate authority. 198 In this case, if the certificate were included in the issued ticket, 199 the KDC would only be making the statement that the certificate was 200 used in the authentication. This statement would be authenticated, 201 but would not imply that the KDC stated particular attributes of the 202 certificate described the initiator. 204 Another aspect of context is encoding of the attribute information. 205 An attribute containing an ASCII or UTF-8 version of an e-mail 206 address could not be interpreted the same as a ASN.1 Distinguished 207 Encoding Rules e-mail address in a certificate. 209 All of these contextual aspects of a name attribute affect whether 210 two attributes can be treated the same by an application and thus 211 whether they should be considered the same name attribute. In the 212 GSS-API naming extensions, attributes that have different contexts 213 MUST have different names so they can be distinguished by 214 applications. As an unfortunate consequence of this requirement, 215 multiple attribute names will exist for the same basic information. 216 That is, there is no single attribute name for the e-mail address of 217 an initiator. Other aspects of how mechanisms describe information 218 about subjects would already make this true. For example, some 219 mechanisms use OIDs to name attributes; others use URIs. 221 Local implementations or platforms are likely to have sufficient 222 policy and information to know when contexts can be treated as the 223 same. For example the GSS-API implementation may know that a 224 particular certificate authority can be trusted in the context of a 225 pkinit authentication. The local implementation may have sufficient 226 policy to know that a particular credential issuer is trusted to make 227 a given statement. In order to take advantage of this local 228 knowledge within the GSS-API implementation, naming extensions 229 support the concept of local attributes in addition to standard 230 attributes. For example, an implementation might provide a local 231 attribute for e-mail address. The implementation would specify the 232 encoding and representation of this attribute; mechanism-specific 233 standards attributes would be re-encoded if necessary to meet this 234 representation. Only e-mail addresses in contexts that meet the 235 requirements of local policy would be mapped into this local 236 attribute. 238 Such local attributes inherently expose a tradeoff between 239 interoperability and usability. Using a local attribute in an 240 application requires knowledge of the local implementation. However 241 using a standardized attribute in an application requires more 242 knowledge of policy and more validation logic in the application. 243 Sharing this logic in the local platform provides more consistency 244 across applications as well as reducing implementation costs. Both 245 options are needed. 247 6. Representation of Attribute Names 249 Different underlying mechanisms (eg SAML or X.509 certificates) 250 provide different representations for the names of their attribute. 251 In X.509 certificates, most objects are named by object identifiers 252 (OIDs). The type of object (certificate extension, name constraint, 253 keyPurposeID, etc) along with the OID is sufficient to identify the 254 attribute. By contrast, according to Section 8.2 and 2.7.3.1 of 255 [OASIS.saml-core-2.0-os], the name of an attribute has two parts. 256 The first is a URI describing the format of the name. The second 257 part, whose form depends on the format URI, is the actual name. In 258 other cases an attribute might represent a certificate that plays 259 some particular role in a GSS-API mechanism; such attributes might 260 have a simple mechanism-defined name. 262 Attribute names MUST support multiple components. If there are more 263 than one component in an attribute name, the more significant 264 components define the semantics of the less significant components. 266 Attribute names are represented as OCTET STRING elements in the API 267 described below. These attribute names have syntax and semantics 268 that are understood by the application and by the lower-layer 269 implementations (some of which are described below). 271 If an attribute name contains a space (ASCII 0x20), the first space 272 separates the most significant or primary component of the name from 273 the remainder. If there is no space, the primary component is the 274 entire name, otherwise it defines the interpretation of the remainder 275 of the name.s 277 If the primary component contains an ASCII : (0x3a), then the primary 278 component is a URI. Otherwise, the attribute is a local attribute 279 and the primary component has meaning to the implementation of GSS- 280 API or to the specific configuration of the application. At this 281 time, local attribute names are not standardized; there is debate 282 about whether such standardization will be useful. Any future 283 standardizations will need to balance potential problems resulting 284 from attribute names used before standardization. 286 A sufficient prefix of attribute names needs to be dictated by a 287 mechanism in order to describe the context. For example it would be 288 problematic to represent SAML attribute names as the name format URI, 289 a space, and the remainder of the name. A carefully crafted SAML 290 assertion could appear to be a name from another mechanism or 291 context. Typically a SAML attribute name would include a prefix 292 describing the trust model and other context of the attribute name. 294 Local attribute names under the control of an administrator or a 295 sufficiently trusted part of the platform need not have a prefix to 296 describe context. 298 7. API 300 7.1. SET OF OCTET STRING 302 The construct SET OF OCTET STRING occurs once in RFC 2743 [RFC2743] 303 where it is used to represent a set of status strings in the 304 GSS_Display_status call. The Global Grid Forum has defined SET OF 305 OCTET STRING as a buffer-set type in GFD.024 [GFD.024] which also 306 provides one API for memory management of these structures. The 307 normative reference to GFD.024 [GFD.024] is for the buffer set 308 functions defined in section 2.5 and the associated buffer set C 309 types defined in section 6 (namely gss_buffer_set_desc, 310 gss_buffer_set_t, gss_create_empty_buffer_set, 311 gss_add_buffer_set_member, gss_release_buffer_set). Nothing else 312 from GFD.024 is required to implement this document. In particular, 313 that document specify changes in behaviour existing GSS-API functions 314 in section 3: implementing those changes are not required to 315 implement this document. Note that this document assumes buffer sets 316 allows for order preservation. 318 7.2. Const types 320 The C bindings for the new APIs uses some types from [RFC5587] to 321 avoid issues with the use of "const". The normative reference to 322 [RFC5587] is for the C types specified in Figure 1 of 3.4.6, nothing 323 else from that document is required to implement this document. 325 7.3. GSS_Display_name_ext() 327 Inputs: 329 o name INTERNAL NAME, 331 o display_as_name_type OBJECT IDENTIFIER 333 Outputs: 335 o major_status INTEGER, 337 o minor_status INTEGER, 339 o display_name OCTET STRING -- caller must release with 340 GSS_Release_buffer() 342 Return major_status codes: 344 o GSS_S_COMPLETE indicates no error. 346 o GSS_S_UNAVAILABLE indicates that the given name could not be 347 displayed using the syntax of the given name type. 349 o GSS_S_FAILURE indicates a general error. 351 This function displays a given name using the given name syntax, if 352 possible. This operation may require mapping Mechanism Names (MNs) 353 to generic name syntaxes or generic name syntaxes to mechanism- 354 specific name syntaxes; such mappings may not always be feasible and 355 MAY be inexact or lossy, therefore this function may fail. 357 7.3.1. C-Bindings 359 The display_name buffer is de-allocated by the caller with 360 gss_release_buffer. 362 OM_uint32 gss_display_name_ext( 363 OM_uint32 *minor_status, 364 gss_const_name_t name, 365 gss_const_OID display_as_name_type, 366 gss_buffer_t display_name 367 ); 369 7.4. GSS_Inquire_name() 371 Inputs: 373 o name INTERNAL NAME 374 Outputs: 376 o major_status INTEGER, 378 o minor_status INTEGER, 380 o name_is_MN BOOLEAN, 382 o mn_mech OBJECT IDENTIFIER, 384 o attrs SET OF OCTET STRING -- the caller is responsible for de- 385 allocating memory using GSS_Release_buffer_set 387 Return major_status codes: 389 o GSS_S_COMPLETE indicates no error. 391 o GSS_S_FAILURE indicates a general error. 393 This function outputs the set of attributes of a name. It also 394 indicates if a given name is an Mechanism Name (MN) or not and, if it 395 is, what mechanism it's an MN of. 397 7.4.1. C-Bindings 399 OM_uint32 gss_inquire_name( 400 OM_uint32 *minor_status, 401 gss_const_name_t name, 402 int *name_is_MN, 403 gss_OID *MN_mech, 404 gss_buffer_set_t *attrs 405 ); 407 The gss_buffer_set_t is used here as the C representation of SET OF 408 OCTET STRING. This type is used to represent a set of attributes and 409 is a NULL-terminated array of gss_buffer_t. The gss_buffer_set_t 410 type and associated API is defined in GFD.024 [GFD.024]. The "attrs" 411 buffer set is de-allocated by the caller using 412 gss_release_buffer_set(). 414 7.5. GSS_Get_name_attribute() 416 Inputs: 418 o name INTERNAL NAME, 419 o attr OCTET STRING 421 Outputs: 423 o major_status INTEGER, 425 o minor_status INTEGER, 427 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 428 peer credential source. 430 o complete BOOLEAN -- TRUE iff this represents a complete set of 431 values for the name. 433 o values SET OF OCTET STRING -- the caller is responsible for de- 434 allocating memory using GSS_Release_buffer_set. 436 o display_values SET OF OCTET STRING -- the caller is responsible 437 for de-allocating memory using GSS_Release_buffer_set 439 Return major_status codes: 441 o GSS_S_COMPLETE indicates no error. 443 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 444 known or set. 446 o GSS_S_FAILURE indicates a general error. 448 This function outputs the value(s) associated with a given GSS name 449 object for a given name attribute. 451 The complete flag denotes that (if TRUE) the set of values represents 452 a complete set of values for this name. The peer being an 453 authoritative source of information for this attribute is a 454 sufficient condition for the complete flag to be set by the peer. 456 In the federated case when several peers may hold some of the 457 attributes about a name this flag may be highly dangerous and SHOULD 458 NOT be used. 460 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 461 for order preservation; this has been discussed on the KITTEN WG 462 mailing list and the consensus seems to be that, indeed, that was 463 always the intention. It should be noted however that the order 464 presented does not always reflect an underlying order of the 465 mechanism specific source of the attribute values. 467 7.5.1. C-Bindings 469 The C-bindings of GSS_Get_name_attribute() requires one function call 470 per-attribute value, for multi-valued name attributes. This is done 471 by using a single gss_buffer_t for each value and an input/output 472 integer parameter to distinguish initial and subsequent calls and to 473 indicate when all values have been obtained. 475 The 'more' input/output parameter should point to an integer variable 476 whose value, on first call to gss_name_attribute_get() MUST be -1, 477 and whose value upon function call return will be non-zero to 478 indicate that additional values remain, or zero to indicate that no 479 values remain. The caller should not modify this parameter after the 480 initial call. The status of the complete and authenticated flags 481 MUST NOT change between multiple calls to iterate over values for an 482 attribute. 484 The output buffers "value" and "display_value" are de-allocated by 485 the caller using gss_release_buffer(). 487 OM_uint32 gss_get_name_attribute( 488 OM_uint32 *minor_status, 489 gss_const_name_t name, 490 gss_const_buffer_t attr, 491 int *authenticated, 492 int *complete, 493 gss_buffer_t value, 494 gss_buffer_t display_value, 495 int *more 496 ); 498 7.6. GSS_Set_name_attribute() 500 Inputs: 502 o name INTERNAL NAME, 504 o complete BOOLEAN, -- TRUE iff this represents a complete set of 505 values for the name. 507 o attr OCTET STRING, 509 o values SET OF OCTET STRING 511 Outputs: 513 o major_status INTEGER, 515 o minor_status INTEGER 517 Return major_status codes: 519 o GSS_S_COMPLETE indicates no error. 521 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 522 known or could not be set. 524 o GSS_S_FAILURE indicates a general error. 526 The complete flag denotes that (if TRUE) the set of values represents 527 a complete set of values for this name. The peer being an 528 authoritative source of information for this attribute is a 529 sufficient condition for the complete flag to be set by the peer. 531 In the federated case when several peers may hold some of the 532 attributes about a name this flag may be highly dangerous and SHOULD 533 NOT be used. 535 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 536 for order preservation; this has been discussed on the KITTEN WG 537 mailing list and the consensus seems to be that, indeed, that was 538 always the intention. It should be noted that underlying mechanisms 539 may not respect the given order. 541 7.6.1. C-Bindings 543 The C-bindings of GSS_Set_name_attribute() requires one function call 544 per-attribute value, for multi-valued name attributes -- each call 545 adds one value. To replace an attribute's every value delete the 546 attribute's values first with GSS_Delete_name_attribute(). 548 OM_uint32 gss_set_name_attribute( 549 OM_uint32 *minor_status, 550 gss_const_name_t name, 551 int complete, 552 gss_const_buffer_t attr, 553 gss_const_buffer_t value 554 ); 556 7.7. GSS_Delete_name_attribute() 558 Inputs: 560 o name INTERNAL NAME, 562 o attr OCTET STRING, 564 Outputs: 566 o major_status INTEGER, 568 o minor_status INTEGER 570 Return major_status codes: 572 o GSS_S_COMPLETE indicates no error. 574 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 575 known. 577 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 578 attempted eg deleting a negative attribute. 580 o GSS_S_FAILURE indicates a general error. 582 Deletion of negative authenticated attributes from NAME objects MUST 583 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 585 7.7.1. C-Bindings 587 OM_uint32 gss_delete_name_attribute( 588 OM_uint32 *minor_status, 589 gss_const_name_t name, 590 gss_const_buffer_t attr 591 ); 593 7.8. GSS_Export_name_composite() 595 Inputs: 597 o name INTERNAL NAME 599 Outputs: 601 o major_status INTEGER, 603 o minor_status INTEGER, 604 o exp_composite_name OCTET STRING -- the caller is responsible for 605 de-allocating memory using GSS_Release_buffer 607 Return major_status codes: 609 o GSS_S_COMPLETE indicates no error. 611 o GSS_S_FAILURE indicates a general error. 613 This function outputs a token which can be imported with 614 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 615 and which preserves any name attribute information (including the 616 authenticated/complete flags) associated with the input name (which 617 GSS_Export_name() may well not). The token format is not specified 618 here as this facility is intended for inter-process communication 619 only; however, all such tokens MUST start with a two-octet token ID, 620 hex 04 02, in network byte order. 622 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 624 7.8.1. C-Bindings 626 The "exp_composite_name" buffer is de-allocated by the caller with 627 gss_release_buffer. 629 OM_uint32 gss_export_name_composite( 630 OM_uint32 *minor_status, 631 gss_const_name_t name, 632 gss_buffer_t exp_composite_name 633 ); 635 8. IANA Considerations 637 This document creates a namespace of GSS-API name attributes. 638 Attributes are named by URIs, so no single authority is technically 639 needed for allocation. However future deployment experience may 640 indicate the need for an IANA registry for URIs used to reference 641 names specified by IETF standards. It is expected that this will be 642 a registry of URNs but this document provides no further guidance on 643 this registry. 645 9. Security Considerations 647 This document extends the GSS-API naming model to include support for 648 name attributes. The intention is that name attributes are to be 649 used as a basis for (among other things) authorization decisions or 650 personalization for applications relying on GSS-API security 651 contexts. 653 The security of the application may be critically dependent on the 654 security of the attributes. This document classifies attributes as 655 asserted or authenticated. Asserted (non-authenticated) attributes 656 MUST NOT be used if the attribute has security implications for the 657 application (eg authorization decisions) since asserted attributes 658 may easily be controlled by the peer directly. 660 It is important to understand the meaning of 'authenticated' in this 661 setting. Authenticated does not imply that any semantic of the 662 attribute is claimed to be true. The only implication is that a 663 trusted third party has asserted the attribute as opposed to the 664 attribute being asserte by the peer itself. Any additional semantics 665 is always the result of applying policy. For instance in a given 666 deployment the mail attribute of the subject may be authenticated and 667 sourced from an email system where 'authoritive' values are kept. In 668 another situations users may be allowed to modify their mail 669 addresses freely. In both cases the 'mail' attribute may be 670 authenticated by virtue of being included in signed SAML attribute 671 assertions or by other means authenticated by the underlying 672 mechanism. 674 When the underlying security mechanism does not provide a permanent 675 unique identity (eg anonymous kerberos) the GSS-API naming extensions 676 may be used to provide a replacement permanent unique identity 677 attribute which in this case may be unique for each peer party. This 678 is analogous to the SAML permanentIdentifier attribute and has 679 comparable security and privacy properties and implications. 681 10. References 683 10.1. Normative References 685 [GFD.024] Argonne National Laboratory, National Center for 686 Supercomputing Applications, Argonne National Laboratory, 687 and Argonne National Laboratory, "GSS-API Extensions", 688 GFD GFD.024, June 2004. 690 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 691 (SPKM)", RFC 2025, October 1996. 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, March 1997. 696 [RFC2743] Linn, J., "Generic Security Service Application Program 697 Interface Version 2, Update 1", RFC 2743, January 2000. 699 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 700 C-bindings", RFC 2744, January 2000. 702 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 703 Kerberos Network Authentication Service (V5)", RFC 4120, 704 July 2005. 706 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 707 Housley, R., and W. Polk, "Internet X.509 Public Key 708 Infrastructure Certificate and Certificate Revocation List 709 (CRL) Profile", RFC 5280, May 2008. 711 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 712 Inquiry APIs", RFC 5587, July 2009. 714 10.2. Informative References 716 [OASIS.saml-core-2.0-os] 717 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 718 "Assertions and Protocol for the OASIS Security Assertion 719 Markup Language (SAML) V2.0", OASIS Standard saml-core- 720 2.0-os, March 2005. 722 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 723 RFC 3061, February 2001. 725 [RFC4768] Hartman, S., "Desired Enhancements to Generic Security 726 Services Application Program Interface (GSS-API) Version 3 727 Naming", RFC 4768, December 2006. 729 Authors' Addresses 731 Nicolas Williams 732 Sun Microsystems 733 5300 Riata Trace Ct 734 Austin, TX 78727 735 US 737 Email: Nicolas.Williams@sun.com 739 Leif Johansson 740 Swedish University Network 741 Thulegatan 11 742 Stockholm 743 Sweden 745 Email: leifj@sunet.se 746 URI: http://www.sunet.se 748 Sam Hartman 749 Painless Security 751 Phone: 752 Fax: 753 Email: hartmans-ietf@mit.edu 754 URI: 756 Simon Josefsson 757 SJD AB 758 Hagagatan 24 759 Stockholm 113 47 760 SE 762 Email: simon@josefsson.org 763 URI: http://josefsson.org/