idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-13.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 (March 11, 2012) is 4429 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 4 Intended status: Standards Track L. Johansson 5 Expires: September 12, 2012 SUNET 6 S. Hartman 7 Painless Security 8 S. Josefsson 9 SJD AB 10 March 11, 2012 12 GSS-API Naming Extensions 13 draft-ietf-kitten-gssapi-naming-exts-13 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 September 12, 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 . . . . . . . . . . . . . . . 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() . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 18 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 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 Future updates of this specification may involve adding an attribute 131 namespace for attributes that only have application-specific 132 semantics. Note that mechanisms will still need to know how to 133 transport such attributes. The IETF may also wish to add functions 134 by which to inquire whether a mechanism(s) understands a given 135 attribute name or namespace, and to list which attributes or 136 attribute namespaces a mechanism understands. Finally, the IETF may 137 want to consider adding a function by which to determine the name of 138 the issuer of a name attribute. 140 3. Name Attribute Authenticity 141 An attribute is 'authenticated' iff there is a secure association 142 between the attribute (and its values) and the trusted source of the 143 peer credential. Examples of authenticated attributes are (any part 144 of) the signed portion of an X.509 certificate or AD-KDCIssued 145 authorization-data elements in Kerberos V Tickets provided of course 146 that the authenticity of the respective security associations (eg 147 signatures) have been verified. 149 Note that the fact that an attribute is authenticated does not imply 150 anything about the semantics of the attribute nor that the trusted 151 credential source was authorized to assert the attribute. Such 152 interpretations SHOULD be the result of applying local policy to the 153 attribute. 155 An un-authentciated attribute is called _asserted_ in what 156 follows.This is not to be confused with other uses of the word 157 asserted or assertion eg "SAML attribute assertion", the attributes 158 of which may be authenticated in the sense of this document for 159 instance if the SAML attribute assertion was signed by a key trusted 160 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 (RFC 4556). 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 certificate authority. 207 In this case, if the certificate were included in the issued ticket, 208 the KDC would only be making the statement that the certificate was 209 used in the authentication. This statement would be authenticated, 210 but would not imply that the KDC stated particular attributes of the 211 certificate described the initiator. 213 Another aspect of context is encoding of the attribute information. 214 An attribute containing an ASCII or UTF-8 version of an e-mail 215 address could not be interpreted the same as a ASN.1 Distinguished 216 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 certificate 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 (eg 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. If there is no space, the primary component is the 283 entire name, otherwise it defines the interpretation of the remainder 284 of the name.s 286 If the primary component contains an ASCII : (0x3a), then the primary 287 component is a URI. Otherwise, the attribute is a local attribute 288 and the primary component has meaning to the implementation of GSS- 289 API or to the specific configuration of the application. At this 290 time, local attribute names are not standardized; there is debate 291 about whether such standardization will be useful. Any future 292 standardizations will need to balance potential problems resulting 293 from attribute names used before standardization. 295 A sufficient prefix of attribute names needs to be dictated by a 296 mechanism in order to describe the context. For example it would be 297 problematic to represent SAML attribute names as the name format URI, 298 a space, and the remainder of the name. A carefully crafted SAML 299 assertion could appear to be a name from another mechanism or 300 context. Typically a SAML attribute name would include a prefix 301 describing the trust model and other context of the attribute name. 303 Local attribute names under the control of an administrator or a 304 sufficiently trusted part of the platform need not have a prefix to 305 describe context. 307 7. API 309 7.1. SET OF OCTET STRING 311 The construct SET OF OCTET STRING occurs once in RFC 2743 [RFC2743] 312 where it is used to represent a set of status strings in the 313 GSS_Display_status call. The Global Grid Forum has defined SET OF 314 OCTET STRING as a buffer-set type in GFD.024 [GFD.024] which also 315 provides one API for memory management of these structures. The 316 normative reference to GFD.024 [GFD.024] is for the buffer set 317 functions defined in section 2.5 and the associated buffer set C 318 types defined in section 6 (namely gss_buffer_set_desc, 319 gss_buffer_set_t, gss_create_empty_buffer_set, 320 gss_add_buffer_set_member, gss_release_buffer_set). Nothing else 321 from GFD.024 is required to implement this document. In particular, 322 that document specify changes in behaviour existing GSS-API functions 323 in section 3: implementing those changes are not required to 324 implement this document. Any implementation of SET OF OCTET STRING 325 for use by this specification MUST preserve order. 327 7.2. Const types 328 The C bindings for the new APIs uses some types from [RFC5587] to 329 avoid issues with the use of "const". The normative reference to 330 [RFC5587] is for the C types specified in Figure 1 of 3.4.6, nothing 331 else from that document is required to implement this document. 333 7.3. GSS_Display_name_ext() 335 Inputs: 337 o name INTERNAL NAME, 339 o display_as_name_type OBJECT IDENTIFIER 341 Outputs: 343 o major_status INTEGER, 345 o minor_status INTEGER, 347 o display_name OCTET STRING -- caller must release with 348 GSS_Release_buffer() 350 Return major_status codes: 352 o GSS_S_COMPLETE indicates no error. 354 o GSS_S_UNAVAILABLE indicates that the given name could not be 355 displayed using the syntax of the given name type. 357 o GSS_S_FAILURE indicates a general error. 359 This function displays a given name using the given name syntax, if 360 possible. This operation may require mapping Mechanism Names (MNs) 361 to generic name syntaxes or generic name syntaxes to mechanism- 362 specific name syntaxes; such mappings may not always be feasible and 363 MAY be inexact or lossy, therefore this function may fail. 365 7.3.1. C-Bindings 367 The display_name buffer is de-allocated by the caller with 368 gss_release_buffer. 370 OM_uint32 gss_display_name_ext( 371 OM_uint32 *minor_status, 372 gss_const_name_t name, 373 gss_const_OID display_as_name_type, 374 gss_buffer_t display_name 375 ); 377 7.4. GSS_Inquire_name() 379 Inputs: 381 o name INTERNAL NAME 383 Outputs: 385 o major_status INTEGER, 387 o minor_status INTEGER, 389 o name_is_MN BOOLEAN, 391 o mn_mech OBJECT IDENTIFIER, 393 o attrs SET OF OCTET STRING -- the caller is responsible for de- 394 allocating memory using GSS_Release_buffer_set 396 Return major_status codes: 398 o GSS_S_COMPLETE indicates no error. 400 o GSS_S_FAILURE indicates a general error. 402 This function outputs the set of attributes of a name. It also 403 indicates if a given name is an Mechanism Name (MN) or not and, if it 404 is, what mechanism it's an MN of. 406 7.4.1. C-Bindings 408 OM_uint32 gss_inquire_name( 409 OM_uint32 *minor_status, 410 gss_const_name_t name, 411 int *name_is_MN, 412 gss_OID *MN_mech, 413 gss_buffer_set_t *attrs 414 ); 416 The gss_buffer_set_t is used here as the C representation of SET OF 417 OCTET STRING. This type is used to represent a set of attributes and 418 is a NULL-terminated array of gss_buffer_t. The gss_buffer_set_t 419 type and associated API is defined in GFD.024 [GFD.024]. The "attrs" 420 buffer set is de-allocated by the caller using 421 gss_release_buffer_set(). 423 7.5. GSS_Get_name_attribute() 425 Inputs: 427 o name INTERNAL NAME, 429 o attr OCTET STRING 431 Outputs: 433 o major_status INTEGER, 435 o minor_status INTEGER, 437 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 438 peer credential source. 440 o complete BOOLEAN -- TRUE iff this represents a complete set of 441 values for the name. 443 o values SET OF OCTET STRING -- the caller is responsible for de- 444 allocating memory using GSS_Release_buffer_set. 446 o display_values SET OF OCTET STRING -- the caller is responsible 447 for de-allocating memory using GSS_Release_buffer_set 449 Return major_status codes: 451 o GSS_S_COMPLETE indicates no error. 453 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 454 known or set. 456 o GSS_S_FAILURE indicates a general error. 458 This function outputs the value(s) associated with a given GSS name 459 object for a given name attribute. 461 The complete flag denotes that (if TRUE) the set of values represents 462 a complete set of values for this name. The peer being an 463 authoritative source of information for this attribute is a 464 sufficient condition for the complete flag to be set by the peer. 466 In the federated case when several peers may hold some of the 467 attributes about a name this flag may be highly dangerous and SHOULD 468 NOT be used. 470 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 471 for order preservation; this has been discussed on the KITTEN WG 472 mailing list and the consensus seems to be that, indeed, that was 473 always the intention. It should be noted however that the order 474 presented does not always reflect an underlying order of the 475 mechanism specific source of the attribute values. 477 7.5.1. C-Bindings 479 The C-bindings of GSS_Get_name_attribute() requires one function call 480 per-attribute value, for multi-valued name attributes. This is done 481 by using a single gss_buffer_t for each value and an input/output 482 integer parameter to distinguish initial and subsequent calls and to 483 indicate when all values have been obtained. 485 The 'more' input/output parameter should point to an integer variable 486 whose value, on first call to gss_name_attribute_get() MUST be -1, 487 and whose value upon function call return will be non-zero to 488 indicate that additional values remain, or zero to indicate that no 489 values remain. The caller should not modify this parameter after the 490 initial call. The status of the complete and authenticated flags 491 MUST NOT change between multiple calls to iterate over values for an 492 attribute. 494 The output buffers "value" and "display_value" are de-allocated by 495 the caller using gss_release_buffer(). 497 OM_uint32 gss_get_name_attribute( 498 OM_uint32 *minor_status, 499 gss_const_name_t name, 500 gss_const_buffer_t attr, 501 int *authenticated, 502 int *complete, 503 gss_buffer_t value, 504 gss_buffer_t display_value, 505 int *more 506 ); 508 7.6. GSS_Set_name_attribute() 510 Inputs: 512 o name INTERNAL NAME, 513 o complete BOOLEAN, -- TRUE iff this represents a complete set of 514 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 605 Return major_status codes: 607 o GSS_S_COMPLETE indicates no error. 609 o GSS_S_UNAVAILABLE indicates that the given attribute NAME is not 610 known. 612 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 613 attempted eg deleting a negative attribute. 615 o GSS_S_FAILURE indicates a general error. 617 Deletion of negative authenticated attributes from NAME objects MUST 618 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 620 7.7.1. C-Bindings 622 OM_uint32 gss_delete_name_attribute( 623 OM_uint32 *minor_status, 624 gss_const_name_t name, 625 gss_const_buffer_t attr 626 ); 628 7.8. GSS_Export_name_composite() 630 Inputs: 632 o name INTERNAL NAME 634 Outputs: 636 o major_status INTEGER, 638 o minor_status INTEGER, 640 o exp_composite_name OCTET STRING -- the caller is responsible for 641 de-allocating memory using GSS_Release_buffer 643 Return major_status codes: 645 o GSS_S_COMPLETE indicates no error. 647 o GSS_S_FAILURE indicates a general error. 649 This function outputs a token which can be imported with 650 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 651 and which preserves any name attribute information (including the 652 authenticated/complete flags) associated with the input name (which 653 GSS_Export_name() may well not). The token format is not specified 654 here as this facility is intended for inter-process communication 655 only; however, all such tokens MUST start with a two-octet token ID, 656 hex 04 02, in network byte order. 658 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 660 7.8.1. C-Bindings 662 The "exp_composite_name" buffer is de-allocated by the caller with 663 gss_release_buffer. 665 OM_uint32 gss_export_name_composite( 666 OM_uint32 *minor_status, 667 gss_const_name_t name, 668 gss_buffer_t exp_composite_name 669 ); 671 8. IANA Considerations 673 This specification has no actions for IANA. 675 This document creates a namespace of GSS-API name attributes. 676 Attributes are named by URIs, so no single authority is technically 677 needed for allocation. However future deployment experience may 678 indicate the need for an IANA registry for URIs used to reference 679 names specified by IETF standards. It is expected that this will be 680 a registry of URNs but this document provides no further guidance on 681 this registry. 683 9. Security Considerations 685 This document extends the GSS-API naming model to include support for 686 name attributes. The intention is that name attributes are to be 687 used as a basis for (among other things) authorization decisions or 688 personalization for applications relying on GSS-API security 689 contexts. 691 The security of the application may be critically dependent on the 692 security of the attributes. This document classifies attributes as 693 asserted or authenticated. Asserted (non-authenticated) attributes 694 MUST NOT be used if the attribute has security implications for the 695 application (eg authorization decisions) since asserted attributes 696 may easily be controlled by the peer directly. 698 It is important to understand the meaning of 'authenticated' in this 699 setting. Authenticated does not imply that any semantic of the 700 attribute is claimed to be true. The only implication is that a 701 trusted third party has asserted the attribute as opposed to the 702 attribute being asserte by the peer itself. Any additional semantics 703 is always the result of applying policy. For instance in a given 704 deployment the mail attribute of the subject may be authenticated and 705 sourced from an email system where 'authoritive' values are kept. In 706 another situations users may be allowed to modify their mail 707 addresses freely. In both cases the 'mail' attribute may be 708 authenticated by virtue of being included in signed SAML attribute 709 assertions or by other means authenticated by the underlying 710 mechanism. 712 When the underlying security mechanism does not provide a permanent 713 unique identity (e.g., anonymous kerberos), GSS-API naming extensions 714 may be used to provide a permanent unique identity attribute. This 715 may be a globally unique identifier, a value unique within the 716 namespace of the attribute issuer, or a "directed" identifier that is 717 unique per peer acceptor identity. SAML, to use one example 718 technology, offers a number of built-in constructs for this purpose, 719 such as a with a Format of 720 "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". SAML 721 deployments also typically make use of domain-specific attribute 722 types that can serve as identifiers. 724 10. References 726 10.1. Normative References 728 [GFD.024] Argonne National Laboratory, National Center for 729 Supercomputing Applications, Argonne National Laboratory, 730 and Argonne National Laboratory, "GSS-API Extensions", 731 GFD GFD.024, June 2004. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC2743] Linn, J., "Generic Security Service Application Program 737 Interface Version 2, Update 1", RFC 2743, January 2000. 739 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 740 C-bindings", RFC 2744, January 2000. 742 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 743 Inquiry APIs", RFC 5587, July 2009. 745 10.2. Informative References 747 [OASIS.saml-core-2.0-os] 748 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 749 "Assertions and Protocol for the OASIS Security Assertion 750 Markup Language (SAML) V2.0", OASIS Standard saml-core- 751 2.0-os, March 2005. 753 [RFC4768] Hartman, S., "Desired Enhancements to Generic Security 754 Services Application Program Interface (GSS-API) Version 3 755 Naming", RFC 4768, December 2006. 757 Authors' Addresses 759 Nicolas Williams 761 Email: nico@cryptonector.com 763 Leif Johansson 764 Swedish University Network 765 Thulegatan 11 766 Stockholm 767 Sweden 769 Email: leifj@sunet.se 770 URI: http://www.sunet.se 772 Sam Hartman 773 Painless Security 775 Phone: 776 Fax: 777 Email: hartmans-ietf@mit.edu 778 URI: 780 Simon Josefsson 781 SJD AB 782 Hagagatan 24 783 Stockholm 113 47 784 SE 786 Email: simon@josefsson.org 787 URI: http://josefsson.org/