idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-15.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 31, 2012) is 4346 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 (~~), 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 Cryptonector, LLC 4 Intended status: Standards Track L. Johansson 5 Expires: December 2, 2012 SUNET 6 S. Hartman 7 Painless Security 8 S. Josefsson 9 SJD AB 10 May 31, 2012 12 GSS-API Naming Extensions 13 draft-ietf-kitten-gssapi-naming-exts-15 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 December 2, 2012. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . 5 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() . . . . . . . . . . . . . . . . . . 9 78 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.4. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 10 80 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.5. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 11 82 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.6. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 12 84 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 85 7.7. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 14 86 7.7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.8. GSS_Export_name_composite() . . . . . . . . . . . . . . . 15 88 7.8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 16 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 16 90 9. Security Considerations . . . . . . . . . . . . . . . . . 16 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . 17 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 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 defines 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 (e.g., an X509 attribute certificate or 119 signed SAML attribute assertion), or may have been set on a GSS name 120 for the purpose of locally "asserting" the attribute during 121 credential acquisition or security context exchange. Name 122 attributes' values are network representations thereof (e.g., the 123 actual value octets of the contents of an X.509 certificate 124 extension, for example) and are intended to be useful for 125 constructing portable access control facilities. Applications may 126 often require language- or platform-specific data types, rather than 127 network representations of name attributes, so a function is provided 128 to obtain objects of such types associated with names and name 129 attributes. 131 Future updates of this specification may involve adding an attribute 132 namespace for attributes that only have application-specific 133 semantics. Note that mechanisms will still need to know how to 134 transport such attributes. The IETF may also wish to add functions 135 by which to inquire whether a mechanism(s) understands a given 136 attribute name or namespace, and to list which attributes or 137 attribute namespaces a mechanism understands. Finally, the IETF may 138 want to consider adding a function by which to determine the name of 139 the issuer of a name attribute. 141 3. Name Attribute Authenticity 142 An attribute is 'authenticated' if and only if there is a secure 143 association between the attribute (and its values) and the trusted 144 source of the peer credential. Examples of authenticated attributes 145 are (any part of) the signed portion of an X.509 certificate or AD- 146 KDCIssued authorization-data elements in Kerberos V Tickets provided 147 of course that the authenticity of the respective security 148 associations (e.g., signatures) have been verified. 150 Note that the fact that an attribute is authenticated does not imply 151 anything about the semantics of the attribute nor that the trusted 152 credential source was authorized to assert the attribute. Such 153 interpretations SHOULD be the result of applying local policy to the 154 attribute. 156 An un-authenticated attribute is called _asserted_ in what follows. 157 This is not to be confused with other uses of the word asserted or 158 assertion such as "SAML attribute assertion", the attributes of which 159 may be authenticated in the sense of this document for instance if 160 the SAML attribute assertion was signed by a key trusted by the peer. 162 4. Name Attributes/Values as ACL Subjects 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 5. Naming Contexts 171 Several factors influence the context in which a name attribute is 172 interpreted. One is the trust context. 174 As discussed previously, applications apply local policy to determine 175 whether a particular peer credential issuer is trusted to make a 176 given statement. Different GSS-API mechanisms and deployments have 177 different trust models surrounding attributes they provide about a 178 name. 180 For example, Kerberos deployments in the enterprise typically trust a 181 KDC to make any statement about principals in a realm. This includes 182 attributes such as group membership. 184 In contrast, in a federated SAML environment, the identity provider 185 typically exists in a different organization than the acceptor. In 186 this case, the set of group memberships or entitlements that the IDP 187 is permitted to make needs to be filtered by the policy of the 188 acceptor and federation. 190 So even an attribute containing the same information such as e-mail 191 address would need to be treated differently by the application in 192 the context of an enterprise deployment from the context of a 193 federation. 195 Another aspect related to trust is the role of the credential issuer 196 in providing the attribute. Consider Kerberos PKINIT [RFC4556]. In 197 this protocol, a public key and associated certificate are used to 198 authenticate to a Kerberos KDC. Consider how attributes related to a 199 pkinit certificate should be made available in GSS-API 200 authentications based on the Kerberos ticket. In some deployments 201 the certificate may be fully trusted; in including the certificate 202 information in the ticket, the KDC permits the acceptor to trust the 203 information in the certificate just as if the KDC itself had made 204 these statements. In other deployments, the KDC may have authorized 205 a hash of the certificate without evaluating the content of the 206 certificate or generally trusting the issuing certification 207 authority. In this case, if the certificate were included in the 208 issued ticket, the KDC would only be making the statement that the 209 certificate was used in the authentication. This statement would be 210 authenticated, but would not imply that the KDC stated particular 211 attributes of the certificate described the initiator. 213 Another aspect of context is encoding of the attribute information. 214 An attribute containing an ASCII [ANSI.X3-4.1986] or UTF-8 [RFC3629] 215 version of an e-mail address could not be interpreted the same as a 216 ASN.1 Distinguished Encoding Rules e-mail address in a certificate. 218 All of these contextual aspects of a name attribute affect whether 219 two attributes can be treated the same by an application and thus 220 whether they should be considered the same name attribute. In the 221 GSS-API naming extensions, attributes that have different contexts 222 MUST have different names so they can be distinguished by 223 applications. As an unfortunate consequence of this requirement, 224 multiple attribute names will exist for the same basic information. 225 That is, there is no single attribute name for the e-mail address of 226 an initiator. Other aspects of how mechanisms describe information 227 about subjects would already make this true. For example, some 228 mechanisms use OIDs to name attributes; others use URIs. 230 Local implementations or platforms are likely to have sufficient 231 policy and information to know when contexts can be treated as the 232 same. For example the GSS-API implementation may know that a 233 particular certification authority can be trusted in the context of a 234 pkinit authentication. The local implementation may have sufficient 235 policy to know that a particular credential issuer is trusted to make 236 a given statement. In order to take advantage of this local 237 knowledge within the GSS-API implementation, naming extensions 238 support the concept of local attributes in addition to standard 239 attributes. For example, an implementation might provide a local 240 attribute for e-mail address. The implementation would specify the 241 encoding and representation of this attribute; mechanism-specific 242 standards attributes would be re-encoded if necessary to meet this 243 representation. Only e-mail addresses in contexts that meet the 244 requirements of local policy would be mapped into this local 245 attribute. 247 Such local attributes inherently expose a tradeoff between 248 interoperability and usability. Using a local attribute in an 249 application requires knowledge of the local implementation. However 250 using a standardized attribute in an application requires more 251 knowledge of policy and more validation logic in the application. 252 Sharing this logic in the local platform provides more consistency 253 across applications as well as reducing implementation costs. Both 254 options are needed. 256 6. Representation of Attribute Names 258 Different underlying mechanisms (e.g., SAML or X.509 certificates) 259 provide different representations for the names of their attribute. 260 In X.509 certificates, most objects are named by object identifiers 261 (OIDs). The type of object (certificate extension, name constraint, 262 keyPurposeID, etc) along with the OID is sufficient to identify the 263 attribute. By contrast, according to Section 8.2 and 2.7.3.1 of 264 [OASIS.saml-core-2.0-os], the name of an attribute has two parts. 265 The first is a URI describing the format of the name. The second 266 part, whose form depends on the format URI, is the actual name. In 267 other cases an attribute might represent a certificate that plays 268 some particular role in a GSS-API mechanism; such attributes might 269 have a simple mechanism-defined name. 271 Attribute names MUST support multiple components. If there are more 272 than one component in an attribute name, the more significant 273 components define the semantics of the less significant components. 275 Attribute names are represented as OCTET STRING elements in the API 276 described below. These attribute names have syntax and semantics 277 that are understood by the application and by the lower-layer 278 implementations (some of which are described below). 280 If an attribute name contains a space (ASCII 0x20), the first space 281 separates the most significant or primary component of the name from 282 the remainder. We may refer to the primary component of the 283 attribute name as the attribute name's "prefix". If there is no 284 space, the primary component is the entire name, otherwise it defines 285 the interpretation of the remainder of the name.s 287 If the primary component contains an ASCII : (0x3a), then the primary 288 component is a URI. Otherwise, the attribute is a local attribute 289 and the primary component has meaning to the implementation of GSS- 290 API or to the specific configuration of the application. Local 291 attribute names with an at-sign ('@') in them are reserved for future 292 allocation by the IETF. 294 Since attribute names are split at the first space into prefix and 295 suffix, there is a potential for ambiguity if a mechanism blindly 296 passes through a name attribute whose name it does not understand. 297 In order to prevent such ambiguities the mechanism MUST always prefix 298 raw name attributes with a prefix that reflects the context of the 299 attribute. 301 Local attribute names under the control of an administrator or a 302 sufficiently trusted part of the platform need not have a prefix to 303 describe context. 305 7. API 307 7.1. SET OF OCTET STRING 309 The construct SET OF OCTET STRING occurs once in RFC 2743 [RFC2743] 310 where it is used to represent a set of status strings in the 311 GSS_Display_status call. The Global Grid Forum has defined SET OF 312 OCTET STRING as a buffer-set type in GFD.024 [GFD.024] which also 313 provides one API for memory management of these structures. The 314 normative reference to GFD.024 [GFD.024] is for the buffer set 315 functions defined in section 2.5 and the associated buffer set C 316 types defined in section 6 (namely gss_buffer_set_desc, 317 gss_buffer_set_t, gss_create_empty_buffer_set, 318 gss_add_buffer_set_member, gss_release_buffer_set). Nothing else 319 from GFD.024 is required to implement this document. In particular, 320 that document specify changes in behaviour existing GSS-API functions 321 in section 3: implementing those changes are not required to 322 implement this document. Any implementation of SET OF OCTET STRING 323 for use by this specification MUST preserve order. 325 7.2. Const types 327 The C bindings for the new APIs uses some types from [RFC5587] to 328 avoid issues with the use of "const". The normative reference to 329 [RFC5587] is for the C types specified in Figure 1 of 3.4.6, nothing 330 else from that document is required to implement this document. 332 7.3. GSS_Display_name_ext() 334 Inputs: 336 o name INTERNAL NAME, 338 o display_as_name_type OBJECT IDENTIFIER 340 Outputs: 342 o major_status INTEGER, 344 o minor_status INTEGER, 346 o display_name OCTET STRING -- caller must release with 347 GSS_Release_buffer() 349 Return major_status codes: 351 o GSS_S_COMPLETE indicates no error. 353 o GSS_S_UNAVAILABLE indicates that the given name could not be 354 displayed using the syntax of the given name type. 356 o GSS_S_FAILURE indicates a general error. 358 This function displays a given name using the given name syntax, if 359 possible. This operation may require mapping Mechanism Names (MNs) 360 to generic name syntaxes or generic name syntaxes to mechanism- 361 specific name syntaxes; such mappings may not always be feasible and 362 MAY be inexact or lossy, therefore this function may fail. 364 7.3.1. C-Bindings 366 The display_name buffer is de-allocated by the caller with 367 gss_release_buffer. 369 OM_uint32 gss_display_name_ext( 370 OM_uint32 *minor_status, 371 gss_const_name_t name, 372 gss_const_OID display_as_name_type, 373 gss_buffer_t display_name 374 ); 376 7.4. GSS_Inquire_name() 378 Inputs: 380 o name INTERNAL NAME 382 Outputs: 384 o major_status INTEGER, 386 o minor_status INTEGER, 388 o name_is_MN BOOLEAN, 390 o mn_mech OBJECT IDENTIFIER, 392 o attrs SET OF OCTET STRING -- the caller is responsible for de- 393 allocating memory using GSS_Release_buffer_set 395 Return major_status codes: 397 o GSS_S_COMPLETE indicates no error. 399 o GSS_S_FAILURE indicates a general error. 401 This function outputs the set of attributes of a name. It also 402 indicates if a given name is an Mechanism Name (MN) or not and, if it 403 is, what mechanism it's an MN of. 405 7.4.1. C-Bindings 407 OM_uint32 gss_inquire_name( 408 OM_uint32 *minor_status, 409 gss_const_name_t name, 410 int *name_is_MN, 411 gss_OID *MN_mech, 412 gss_buffer_set_t *attrs 413 ); 415 The gss_buffer_set_t is used here as the C representation of SET OF 416 OCTET STRING. This type is used to represent a set of attributes and 417 is a NULL-terminated array of gss_buffer_t. The gss_buffer_set_t 418 type and associated API is defined in GFD.024 [GFD.024]. The "attrs" 419 buffer set is de-allocated by the caller using 420 gss_release_buffer_set(). 422 7.5. GSS_Get_name_attribute() 424 Inputs: 426 o name INTERNAL NAME, 428 o attr OCTET STRING 430 Outputs: 432 o major_status INTEGER, 434 o minor_status INTEGER, 436 o authenticated BOOLEAN, -- TRUE if and only if authenticated by the 437 trusted peer credential source. 439 o complete BOOLEAN -- TRUE if and only if this represents a complete 440 set of values for the name. 442 o values SET OF OCTET STRING -- the caller is responsible for de- 443 allocating memory using GSS_Release_buffer_set. 445 o display_values SET OF OCTET STRING -- the caller is responsible 446 for de-allocating memory using GSS_Release_buffer_set 448 Return major_status codes: 450 o GSS_S_COMPLETE indicates no error. 452 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 453 known or set. 455 o GSS_S_FAILURE indicates a general error. 457 This function outputs the value(s) associated with a given GSS name 458 object for a given name attribute. 460 The complete flag denotes that (if TRUE) the set of values represents 461 a complete set of values for this name. The peer being an 462 authoritative source of information for this attribute is a 463 sufficient condition for the complete flag to be set by the peer. 465 In the federated case when several peers may hold some of the 466 attributes about a name this flag may be highly dangerous and SHOULD 467 NOT be used. 469 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 470 for order preservation; this has been discussed on the KITTEN WG 471 mailing list and the consensus seems to be that, indeed, that was 472 always the intention. It should be noted however that the order 473 presented does not always reflect an underlying order of the 474 mechanism specific source of the attribute values. 476 7.5.1. C-Bindings 478 The C-bindings of GSS_Get_name_attribute() requires one function call 479 per-attribute value, for multi-valued name attributes. This is done 480 by using a single gss_buffer_t for each value and an input/output 481 integer parameter to distinguish initial and subsequent calls and to 482 indicate when all values have been obtained. 484 The 'more' input/output parameter should point to an integer variable 485 whose value, on first call to gss_get_name_attribute() MUST be -1, 486 and whose value upon function call return will be non-zero to 487 indicate that additional values remain, or zero to indicate that no 488 values remain. The caller should not modify this parameter after the 489 initial call. The status of the complete and authenticated flags 490 MUST NOT change between multiple calls to iterate over values for an 491 attribute. 493 The output buffers "value" and "display_value" are de-allocated by 494 the caller using gss_release_buffer(). 496 OM_uint32 gss_get_name_attribute( 497 OM_uint32 *minor_status, 498 gss_const_name_t name, 499 gss_const_buffer_t attr, 500 int *authenticated, 501 int *complete, 502 gss_buffer_t value, 503 gss_buffer_t display_value, 504 int *more 505 ); 507 7.6. GSS_Set_name_attribute() 509 Inputs: 511 o name INTERNAL NAME, 513 o complete BOOLEAN, -- TRUE if and only if this represents a 514 complete set of values for the name. 516 o attr OCTET STRING, 518 o values SET OF OCTET STRING 520 Outputs: 522 o major_status INTEGER, 524 o minor_status INTEGER 526 Return major_status codes: 528 o GSS_S_COMPLETE indicates no error. 530 o GSS_S_UNAVAILABLE indicates that the given attribute NAME is not 531 known or could not be set. 533 o GSS_S_FAILURE indicates a general error. 535 When the given NAME object is an MN this function MUST fail (with 536 GSS_S_FAILURE) if the mechanism for which the name is an MN does not 537 recognize the attribute name or the namespace it belongs to. This is 538 because name attributes generally have some semantics that mechanisms 539 must understand. 541 On the other hand, when the given name is not an MN this function MAY 542 succeed even if none of the available mechanisms understand the given 543 attribute, in which subsequent credential acquisition attempts (via 544 GSS_Acquire_cred() or GSS_Add_cred()) with the resulting name MUST 545 fail for mechanisms that do not understand any one or more name 546 attributes set with this function. Applications may wish to use a 547 non-MN, then acquire a credential with that name as the desired name. 548 The acquired credentials will have elements only for the mechanisms 549 that can carry the name attributes set on the name. 551 Note that this means that all name attributes are locally critical: 552 the mechanism(s) must understand them. The reason for this is that 553 name attributes must necessarily have some meaning that the mechanism 554 must understand, even in the case of application-specific attributes 555 (in which case the mechanism must know to transport the attribute to 556 any peer). However, there is no provision to ensure that peers 557 understand any given name attribute. Individual name attributes may 558 be critical with respect to peers, and the specification of the 559 attribute will have to indicate which of the mechanism's protocol or 560 the application is expected to enforce criticality. 562 The complete flag denotes that (if TRUE) the set of values represents 563 a complete set of values for this name. The peer being an 564 authoritative source of information for this attribute is a 565 sufficient condition for the complete flag to be set by the peer. 567 In the federated case when several peers may hold some of the 568 attributes about a name this flag may be highly dangerous and SHOULD 569 NOT be used. 571 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 572 for order preservation; this has been discussed on the KITTEN WG 573 mailing list and the consensus seems to be that, indeed, that was 574 always the intention. It should be noted that underlying mechanisms 575 may not respect the given order. 577 7.6.1. C-Bindings 579 The C-bindings of GSS_Set_name_attribute() requires one function call 580 per-attribute value, for multi-valued name attributes -- each call 581 adds one value. To replace an attribute's every value delete the 582 attribute's values first with GSS_Delete_name_attribute(). 584 OM_uint32 gss_set_name_attribute( 585 OM_uint32 *minor_status, 586 gss_const_name_t name, 587 int complete, 588 gss_const_buffer_t attr, 589 gss_const_buffer_t value 590 ); 592 7.7. GSS_Delete_name_attribute() 594 Inputs: 596 o name INTERNAL NAME, 598 o attr OCTET STRING, 600 Outputs: 602 o major_status INTEGER, 604 o minor_status INTEGER 606 Return major_status codes: 608 o GSS_S_COMPLETE indicates no error. 610 o GSS_S_UNAVAILABLE indicates that the given attribute NAME is not 611 known. 613 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 614 attempted, such as deleting a negative attribute. 616 o GSS_S_FAILURE indicates a general error. 618 Deletion of negative authenticated attributes from NAME objects MUST 619 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 621 7.7.1. C-Bindings 623 OM_uint32 gss_delete_name_attribute( 624 OM_uint32 *minor_status, 625 gss_const_name_t name, 626 gss_const_buffer_t attr 627 ); 629 7.8. GSS_Export_name_composite() 631 Inputs: 633 o name INTERNAL NAME 635 Outputs: 637 o major_status INTEGER, 639 o minor_status INTEGER, 641 o exp_composite_name OCTET STRING -- the caller is responsible for 642 de-allocating memory using GSS_Release_buffer 644 Return major_status codes: 646 o GSS_S_COMPLETE indicates no error. 648 o GSS_S_FAILURE indicates a general error. 650 This function outputs a token which can be imported with 651 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 652 and which preserves any name attribute information (including the 653 authenticated/complete flags) associated with the input name (which 654 GSS_Export_name() may well not). The token format is not specified 655 here as this facility is intended for inter-process communication 656 only; however, all such tokens MUST start with a two-octet token ID, 657 hex 04 02, in network byte order. 659 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 661 7.8.1. C-Bindings 663 The "exp_composite_name" buffer is de-allocated by the caller with 664 gss_release_buffer. 666 OM_uint32 gss_export_name_composite( 667 OM_uint32 *minor_status, 668 gss_const_name_t name, 669 gss_buffer_t exp_composite_name 670 ); 672 8. IANA Considerations 674 This specification has no actions for IANA. 676 This document creates a namespace of GSS-API name attributes. 677 Attributes are named by URIs, so no single authority is technically 678 needed for allocation. However future deployment experience may 679 indicate the need for an IANA registry for URIs used to reference 680 names specified by IETF standards. It is expected that this will be 681 a registry of URNs but this document provides no further guidance on 682 this registry. 684 9. Security Considerations 686 This document extends the GSS-API naming model to include support for 687 name attributes. The intention is that name attributes are to be 688 used as a basis for (among other things) authorization decisions or 689 personalization for applications relying on GSS-API security 690 contexts. 692 The security of the application may be critically dependent on the 693 security of the attributes. This document classifies attributes as 694 asserted or authenticated. Asserted (non-authenticated) attributes 695 MUST NOT be used if the attribute has security implications for the 696 application (e.g., authorization decisions) since asserted attributes 697 may easily be controlled by the peer directly. 699 It is important to understand the meaning of 'authenticated' in this 700 setting. Authenticated does not imply that any semantic of the 701 attribute is claimed to be true. The only implication is that a 702 trusted third party has asserted the attribute as opposed to the 703 attribute being asserted by the peer itself. Any additional 704 semantics are always the result of applying policy. For instance in 705 a given deployment the mail attribute of the subject may be 706 authenticated and sourced from an email system where 'authoritive' 707 values are kept. In another situation users may be allowed to modify 708 their mail addresses freely. In both cases the 'mail' attribute may 709 be authenticated by virtue of being included in signed SAML attribute 710 assertions or by other means authenticated by the underlying 711 mechanism. 713 When the underlying security mechanism does not provide a permanent 714 unique identity (e.g., anonymous kerberos), GSS-API naming extensions 715 may be used to provide a permanent unique identity attribute. This 716 may be a globally unique identifier, a value unique within the 717 namespace of the attribute issuer, or a "directed" identifier that is 718 unique per peer acceptor identity. SAML, to use one example 719 technology, offers a number of built-in constructs for this purpose, 720 such as a with a Format of 721 "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". SAML 722 deployments also typically make use of domain-specific attribute 723 types that can serve as identifiers. 725 10. References 727 10.1. Normative References 729 [GFD.024] Argonne National Laboratory, National Center for 730 Supercomputing Applications, Argonne National Laboratory, 731 and Argonne National Laboratory, "GSS-API Extensions", 732 GFD GFD.024, June 2004. 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 [RFC2743] Linn, J., "Generic Security Service Application Program 738 Interface Version 2, Update 1", RFC 2743, January 2000. 740 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 741 C-bindings", RFC 2744, January 2000. 743 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 744 Inquiry APIs", RFC 5587, July 2009. 746 10.2. Informative References 748 [ANSI.X3-4.1986] 749 American National Standards Institute, "Coded Character 750 Set - 7-bit American Standard Code for Information 751 Interchange", ANSI X3.4, 1986. 753 [OASIS.saml-bindings-2.0-os] 754 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 755 Maler, "Bindings for the OASIS Security Assertion Markup 756 Language (SAML) V2.0", OASIS 757 Standard saml-bindings-2.0-os, March 2005. 759 [OASIS.saml-core-2.0-os] 760 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 761 "Assertions and Protocol for the OASIS Security Assertion 762 Markup Language (SAML) V2.0", OASIS Standard saml-core- 763 2.0-os, March 2005. 765 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 766 10646", STD 63, RFC 3629, November 2003. 768 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 769 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 771 [RFC4768] Hartman, S., "Desired Enhancements to Generic Security 772 Services Application Program Interface (GSS-API) Version 3 773 Naming", RFC 4768, December 2006. 775 Authors' Addresses 777 Nicolas Williams 778 Cryptonector, LLC 780 Email: nico@cryptonector.com 782 Leif Johansson 783 Swedish University Network 784 Thulegatan 11 785 Stockholm 786 Sweden 788 Email: leifj@sunet.se 789 URI: http://www.sunet.se 791 Sam Hartman 792 Painless Security 793 Phone: 794 Fax: 795 Email: hartmans-ietf@mit.edu 796 URI: 798 Simon Josefsson 799 SJD AB 800 Hagagatan 24 801 Stockholm 113 47 802 SE 804 Email: simon@josefsson.org 805 URI: http://josefsson.org/