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