idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2009) is 5376 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) == Outdated reference: A later version (-05) exists of draft-ietf-kitten-gss-naming-01 ** Downref: Normative reference to an Informational draft: draft-ietf-kitten-gss-naming (ref. 'I-D.GSS-NAMING') ** Obsolete normative reference: RFC 3001 (Obsoleted by RFC 3061) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KITTEN WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track L. Johansson 5 Expires: January 31, 2010 SUNET 6 July 30, 2009 8 GSS-API Naming Extensions 9 draft-ietf-kitten-gssapi-naming-exts-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 31, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Generic Security Services API (GSS-API) provides a simple naming 48 architecture that supports name-based authorization. This document 49 introduces new APIs that extend the GSS-API naming model to support 50 name attribute transfer between GSS-API peers. 52 Table of Contents 54 1. Conventions used in this document . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 3 57 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 58 5. Attribute Name Syntax . . . . . . . . . . . . . . . . . . 4 59 6. Mapping Mechanism Facilities to Name Attributes . . . . . 5 60 6.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 61 6.2. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.2.1. Standard PKIX Certificate Extensions . . . . . . . . . . . 5 63 6.2.2. Other PKIX Certificate Extensions and Attributes . . . . . 6 64 6.3. SAML attribute assertions . . . . . . . . . . . . . . . . 6 65 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 67 7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 69 7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 71 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10 73 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 75 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12 77 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.7. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 12 79 7.7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7.8. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 13 81 7.8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 83 9. Security Considerations . . . . . . . . . . . . . . . . . 15 84 10. Normative References . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16 87 1. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119] . 93 2. Introduction 95 As described in [I-D.GSS-NAMING] the GSS-API's naming architecture 96 suffers from certain limitations. This document proposes concrete 97 GSS-API extensions as outlined in [I-D.GSS-NAMING]. 99 A number of extensions to the GSS-API [RFC2743] and its C Bindings 100 [RFC2744] are described herein. The goal is to make information 101 modeled as "name attributes" available to applications. Such 102 information MAY for instance be used by applications to make 103 authorization-decisions. For example, Kerberos V authorization data 104 elements, both, in their raw forms as well as mapped to more useful 105 value types, can be made available to GSS-API applications through 106 these interfaces. 108 The model is that GSS names have attributes. The attributes of a 109 name may be authenticated (eg an X509 attribute certificate or signed 110 SAML attribute assertion), or may have been set on a GSS name for the 111 purpose of locally "asserting" the attribute during credential 112 acquisition or security context exchange. Name attributes' values 113 are network representations thereof (e.g., the actual value octets of 114 the contents of an X.509 certificate extension, for example) and are 115 intended to be useful for constructing portable access control 116 facilities. Applications may often require language- or platform- 117 specific data types, rather than network representations of name 118 attributes, so a function is provided to obtain objects of such types 119 associated with names and name attributes. 121 3. Name Attribute Authenticity 123 An attribute is 'authenticated' iff there is a secure association 124 between the attribute (and its values) and the trusted source of the 125 peer credential. Examples of authenticated attributes are (any part 126 of) the signed portion of an X.509 certificate or AD-KDCIssued 127 authorization-data elements in Kerberos V Tickets provided of course 128 that the authenticity of the respective security associations (eg 129 signatures) have been verified. 131 Note that the fact that an attribute is authenticated does not imply 132 anything about the semantics of the attribute nor that the trusted 133 credential source authorized any one semantic of the attribute. Such 134 interpretations MAY be the result of applying local policy to the 135 attribute. 137 An un-authentciated attribute is called _asserted_ in what 138 follows.This is not to be confused with other uses of the word 139 asserted or assertion eg "SAML attribute assertion", the attributes 140 of which may be authenticated in the sense of this document if the 141 SAML attribute assertion was signed by a key trusted by the peer. 143 4. Name Attributes/Values as ACL Subjects 145 Some name attributes (e.g., numeric user or group identifiers) may be 146 useful as subjects of access control list (ACL) entries, some may not 147 (e.g., time of day login restrictions). The 148 GSS_Inquire_name_attribute() function indicates this. 150 To facilitate the development of portable applications that make use 151 of name attributes to construct and evaluate portable ACLs the GSS- 152 API makes name attribute values available in canonical network 153 encodings thereof. 155 To facilitate the development of platform- or language-specific 156 applications that need access to native types of representations of 157 name attributes an optional facility is provided, 158 GSS_Map_name_to_any(). 160 5. Attribute Name Syntax 162 Attribute names are represented as opaque STRING elements in the API 163 described below. These attribute names have syntax and semantics 164 that are understood by the application and by the lower-layer 165 implementations (some of which are described below). In order to 166 present a consistent namespace to the application and at the same 167 time impose as few transformation requirements as possible to lower- 168 layer implementations attribute names SHOULD be URIs. 170 Technologies used in lower-layer protocols may of course use 171 attribute naming that are not based on URIs. Notably X.509 172 certificates will use OIDs for most naming purposes. In this case 173 OIDs MUST be mapped into URIs. 175 When mapping entities named by OIDs into this API [RFC3001] MUST be 176 used. For example if the OID 1.2.3 denotes an Extended Key Usage, 177 the corresponding GSS-API attribute MUST be represented as 178 urn:oid:1.2.3. 180 6. Mapping Mechanism Facilities to Name Attributes 182 In this section we describe two important examples of lower-layer 183 implementations of this API. These examples are not mandatory to 184 implement and are only provided for reference. The use of [RFC2119]- 185 terms in this section is limited to those implementations of the GSS- 186 API naming extensions that choose to implement these lower-layer 187 technologies. 189 Kerberos V [RFC4120] and the Simple Public-Key GSS-API Mechanism, 190 SPKM described in [RFC2025], both support the concept and encoding of 191 containers of "authorization-data" as described in [RFC4120]. 193 PKIX [RFC5280] supports a number of attribute-like features, like 194 Extended Key Usage values (EKUs) and certificate extensions. 196 6.1. Kerberos V and SPKM Authorization-Data 198 Authorization-data non-container elements asserted in Kerberos V AP- 199 REQ Authenticators MUST be mapped into *asserted* GSS-API name 200 attributes. 202 Authorization-data included in Kerberos V Tickets that is not 203 contained in AD-KDCIssued (with valid signature) MUST be mapped into 204 *asserted* GSS-API name attributes. Conversely, authorization-data 205 elements in Kerberos V Tickets contained by AD-KDCIssued MUST be 206 mapped into *authenticated* GSS-API name attributes. 208 The URIs for authorization-data elements MUST be the authorization- 209 data elements 'ad-type' prefixed by the IANA-allocated URN prefix 210 () 212 6.2. PKIX 214 6.2.1. Standard PKIX Certificate Extensions 216 PKI certificate extensions MAY/SHOULD/MUST (see comment above) be 217 represented as *authenticated* GSS-API name attributes named using 218 the _same_. 220 SubjectAltNames and EKUs, specifically, MUST be represented as 221 *authenticated* GSS-API name attributes; see below. Certificate 222 extensions MUST be represented as GSS-API name attributes named using 223 the OIDs used for the extensions (represented as URNs) 225 Extended Key Usage extensions, specifically, MUST be mapped as 226 described above, except that GSS-API name attributes for EKUs MUST 227 have NULL values (i.e., zero-length OCTET STRINGs). 229 PKI certificate key usages (KUs, but not EKUs), MUST NOT be 230 represented as GSS-API name attributes. 232 PKI certificate subjectAltNames MUST be mapped as *authenticated*. 234 6.2.2. Other PKIX Certificate Extensions and Attributes 236 Any X.509 certificate extension not covered above SHOULD be 237 represented as GSS-AOI name attributes with the OID of the X.509 238 extension and with OCTET STRING values containing the encoded value 239 of the extension. 241 6.3. SAML attribute assertions 243 Attributes contained in SAML attribute assertions are mapped to GSS- 244 API name attributes with the same URIs as used in the SAML attribute 245 names (subject to representing OIDs to URIs). 247 SAML attributes found in SAML attribute assertions MUST NOT be mapped 248 as authenticated unless the SAML attribute assertion was signed by a 249 key trusted by the peer or otherwise protected from unauthorized 250 modification. 252 7. API 254 7.1. GSS_Display_name_ext() 256 Inputs: 258 o name NAME, 260 o display_as_name_type OBJECT IDENTIFIER 262 Outputs: 264 o major_status INTEGER, 266 o minor_status INTEGER, 268 o display_name STRING 270 Return major_status codes: 272 o GSS_S_COMPLETE indicates no error. 274 o GSS_S_UNAVAILABLE indicates that the given name could not be 275 displayed using the syntax of the given name type. 277 o GSS_S_FAILURE indicates a general error. 279 This function displays a given name using the given name syntax, if 280 possible. This operation may require mapping MNs to generic name 281 syntaxes or generic name syntaxes to mechanism-specific name 282 syntaxes; such mappings may not always be feasible and MAY be inexact 283 or lossy, therefore this function may fail. 285 7.1.1. C-Bindings 287 OM_uint32 GSS_Display_name_ext( 288 OM_uint32 *minor_status, 289 gss_name_t name, 290 gss_OID display_as_name_type, 291 gss_buffer_t display_name 292 ); 294 7.2. GSS_Inquire_name() 296 Inputs: 298 o name NAME 300 Outputs: 302 o major_status INTEGER, 304 o minor_status INTEGER, 306 o name_is_MN BOOLEAN, 308 o mn_mech OBJECT IDENTIFIER, 310 o asserted_attrs SET OF STRING, 312 o authenticated_attrs SET OF STRING, 314 o all_attrs SET OF STRING, 316 Return major_status codes: 318 o GSS_S_COMPLETE indicates no error. 320 o GSS_S_FAILURE indicates a general error. 322 This function outputs the sets (represented as a NULL terminated 323 array of gss_buffer_t) of attributes of a name, that are 324 authenticated or asserted. It also indicates if a given NAME is an 325 MN or not and, if it is, what mechanism it's an MN of. 327 7.2.1. C-Bindings 329 OM_uint32 gss_inquire_name( 330 OM_uint32 *minor_status, 331 gss_name_t name, 332 int name_is_MN, 333 gss_OID *MN_mech, 334 gss_buffer_t *authenticated, 335 gss_buffer_t *asserted, 336 gss_buffer_t *all_attrs 337 ); 339 7.3. GSS_Get_name_attribute() 341 Inputs: 343 o name NAME, 345 o attr STRING 347 Outputs: 349 o major_status INTEGER, 351 o minor_status INTEGER, 353 o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted 354 peer credential source. 356 o complete BOOLEAN -- TRUE iff this represents a complete set of 357 values for the name. 359 o values SET OF OCTET STRING, 361 o display_values SET OF STRING 363 Return major_status codes: 365 o GSS_S_COMPLETE indicates no error. 367 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 368 known or set. 370 o GSS_S_FAILURE indicates a general error. 372 This function outputs the value(s) associated with a given GSS name 373 object for a given name attribute. 375 The complete flag denotes that (if TRUE) the set of values represents 376 a complete set of values for this name. The peer being an 377 authoritative source of information for this attribute is a 378 sufficient condition for the complete flag to be set by the peer. 380 In the federated case when several peers may hold some of the 381 attributes about a name this flag may be highly dangerous and SHOULD 382 NOT be used. 384 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 385 for order preservation; this has been discussed on the KITTEN WG 386 mailing list and the consensus seems to be that, indeed, that was 387 always the intention. It should be noted however that the order 388 presented does not always reflect an underlying order of the 389 mechanism specific source of the attribute values. 391 7.3.1. C-Bindings 393 The C-bindings of GSS_Get_name_attribute() requires one function call 394 per-attribute value, for multi-valued name attributes. This is done 395 by using a single gss_buffer_t for each value and an input/output 396 integer parameter to distinguish initial and subsequent calls and to 397 indicate when all values have been obtained. 399 The 'more' input/output parameter should point to an integer variable 400 whose value, on first call to gss_name_attribute_get() MUST be -1, 401 and whose value upon function call return will be non-zero to 402 indicate that additional values remain, or zero to indicate that no 403 values remain. The caller should not modify this parameter after the 404 initial call. 406 OM_uint32 gss_get_name_attribute( 407 OM_uint32 *minor_status, 408 gss_name_t name, 409 gss_buffer_t attr, 410 int *authenticated, 411 int *complete, 412 gss_buffer_t value, 413 gss_buffer_t display_value, 414 int *more 416 ); 418 7.4. GSS_Set_name_attribute() 420 Inputs: 422 o name NAME, 424 o complete BOOLEAN, -- TRUE iff this represents a complete set of 425 values for the name. 427 o attr STRING, 429 o values SET OF OCTET STRING 431 Outputs: 433 o major_status INTEGER, 435 o minor_status INTEGER 437 Return major_status codes: 439 o GSS_S_COMPLETE indicates no error. 441 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 442 known or could not be set. 444 o GSS_S_FAILURE indicates a general error. 446 The complete flag denotes that (if TRUE) the set of values represents 447 a complete set of values for this name. The peer being an 448 authoritative source of information for this attribute is a 449 sufficient condition for the complete flag to be set by the peer. 451 In the federated case when several peers may hold some of the 452 attributes about a name this flag may be highly dangerous and SHOULD 453 NOT be used. 455 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 456 for order preservation; this has been discussed on the KITTEN WG 457 mailing list and the consensus seems to be that, indeed, that was 458 always the intention. It should be noted that underlying mechanisms 459 may not respect the given order. 461 7.4.1. C-Bindings 462 The C-bindings of GSS_Set_name_attribute() requires one function call 463 per-attribute value, for multi-valued name attributes -- each call 464 adds one value. To replace an attribute's every value delete the 465 attribute's values first with GSS_Delete_name_attribute(). 467 OM_uint32 gss_set_name_attribute( 468 OM_uint32 *minor_status, 469 gss_name_t name, 470 int complete, 471 gss_buffer_t attr, 472 gss_buffer_t value 473 ); 475 7.5. GSS_Delete_name_attribute() 477 Inputs: 479 o name NAME, 481 o attr STRING, 483 Outputs: 485 o major_status INTEGER, 487 o minor_status INTEGER 489 Return major_status codes: 491 o GSS_S_COMPLETE indicates no error. 493 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 494 known. 496 o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was 497 attempted eg deleting a negative attribute. 499 o GSS_S_FAILURE indicates a general error. 501 Deletion of negative authenticated attributes from NAME objects MUST 502 NOT be allowed and must result in a GSS_S_UNAUTHORIZED. 504 7.5.1. C-Bindings 506 OM_uint32 gss_delete_name_attribute( 507 OM_uint32 *minor_status, 508 gss_name_t name, 509 gss_buffer_t attr 510 ); 512 7.6. GSS_Export_name_composite() 514 Inputs: 516 o name NAME 518 Outputs: 520 o major_status INTEGER, 522 o minor_status INTEGER, 524 o exp_composite_name OCTET STRING 526 Return major_status codes: 528 o GSS_S_COMPLETE indicates no error. 530 o GSS_S_FAILURE indicates a general error. 532 This function outputs a token which can be imported with 533 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 534 and which preserves any name attribute information associated with 535 the input name (which GSS_Export_name() may well not). The token 536 format is no specified here as this facility is intended for inter- 537 process communication only; however, all such tokens MUST start with 538 a two-octet token ID, hex 04 02, in network byte order. 540 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 542 7.6.1. C-Bindings 544 OM_uint32 gss_export_name_composite( 545 OM_uint32 *minor_status, 546 gss_name_t name, 547 gss_buffer_t exp_composite_name 548 ); 550 7.7. GSS_Map_name_to_any() 552 Inputs: 554 o name NAME, 556 o authenticated BOOLEAN, -- if TRUE only authenticated attributes 557 will be included 559 o type_id STRING 561 Outputs: 563 o major_status INTEGER, 565 o minor_status INTEGER, 567 o output ANY DEFINED BY type_id 569 Return major_status codes: 571 o GSS_S_COMPLETE indicates no error. 573 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 574 not be done. The minor status code may provide additional 575 information. 577 o GSS_S_FAILURE indicates a general error. The minor status code 578 may provide additional information. 580 Whereas name attribute's values are encoded in some network 581 representation applications often require native, language- and/or 582 platform-specific data types. This function provides access to such 583 types. 585 7.7.1. C-Bindings 587 typedef struct gss_any *gss_any_t; 588 OM_uint32 gss_map_name_to_any( 589 OM_uint32 *minor_status, 590 gss_name_t name, 591 int authenticated, 592 gss_buffer_t type_id, // why isn't this 'name'? 593 gss_any_t output 594 ); 596 Note the new C bindings type, gss_any_t. We define it as a pointer 597 to an incompletely declared struct. 599 7.8. GSS_Release_any_name_mapping() 600 Inputs: 602 o name NAME, 604 o type_id STRING, 606 o input ANY DEFINED BY type_id 608 Outputs: 610 o major_status INTEGER, 612 o minor_status INTEGER, 614 Return major_status codes: 616 o GSS_S_COMPLETE indicates no error. 618 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 619 not be done. The minor status code may provide additional 620 information. 622 o GSS_S_FAILURE indicates a general error. The minor status code 623 may provide additional information. 625 This function releases, if possible, the objects of language- and/or 626 platform-specific types output by GSS_Map_name_to_any(). If such 627 types have native release functions applications MAY use either those 628 or this function to release the given object. 630 7.8.1. C-Bindings 632 typedef struct gss_any *gss_any_t; 633 OM_uint32 gss_release_any_name_mapping( 634 OM_uint32 *minor_status, 635 gss_name_t name, 636 gss_buffer_t type_id, 637 gss_any_t *input 638 ); 640 8. IANA Considerations 642 This document creates a namespace of GSS-API name attributes. 643 Attributes are named by URIs, so no single authority is technically 644 needed for allocation. However future deployment experience may 645 indicate the need for an IANA registry for URIs used to reference 646 names specified by IETF standards. It is expected that this will be 647 a registry of URNs but this document provides no further guidance on 648 this registry. 650 9. Security Considerations 652 This document extends the GSS-API naming model to include support for 653 name attributes. The intention is that name attributes are to be 654 used as a basis for (among other things) authorization decisions or 655 application personalization for applications relying on GSS-API 656 security contexts. 658 The security of the application may be critically dependent on the 659 security of the attributes. This document classifies attributes as 660 asserted or authenticated. Only authenticated attributes MUST be 661 used if the attribute has security implications for the application 662 (eg authorization decisions) since asserted attributes may easily be 663 controlled by the peer directly. 665 It is important to understand the meaning of 'authenticated' in this 666 setting. It does not mean that any semantic of the attribute is 667 claimed to be true. The only implication is that a trusted third 668 party has asserted the attribute as opposed to the attribute being 669 asserte by the peer itself. Any additional semantics is always the 670 result of applying policy. For instance in a given deployment the 671 mail attribute of the subject may be authenticated and sourced from 672 an email system where 'correct' values are kept. In another setting 673 users may be allowed to modify their mail addresses freely. In both 674 cases the 'mail' attribute may be authenticated by virtue of being 675 included in signed SAML attribute assertions lor by other means 676 authenticated by the underlying mechanism. 678 When the underlying security mechanism does not provide a permanent 679 unique identity (eg anonymous kerberos) the GSS-API naming extensions 680 may be used to provide a replacement permanent unique identity 681 attribute which in this case may be unique for each relying party. 682 This is analogous to the Liberty Alliance targetedID attribute and 683 has similar security implications. 685 10. Normative References 687 [I-D.GSS-NAMING] 688 Hartman, S., "Desired Enhancements to GSSAPI Naming", 689 draft-ietf-kitten-gss-naming-01.txt (work in progress), 690 February 2005. 692 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 693 (SPKM)", RFC 2025, October 1996. 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 [RFC2743] Linn, J., "Generic Security Service Application Program 699 Interface Version 2, Update 1", RFC 2743, January 2000. 701 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 702 C-bindings", RFC 2744, January 2000. 704 [RFC3001] Mealling, M., "A URN Namespace of Object Identifiers", 705 RFC 3001, November 2000. 707 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 708 Kerberos Network Authentication Service (V5)", RFC 4120, 709 July 2005. 711 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 712 Housley, R., and W. Polk, "Internet X.509 Public Key 713 Infrastructure Certificate and Certificate Revocation List 714 (CRL) Profile", RFC 5280, May 2008. 716 Authors' Addresses 718 Nicolas Williams 719 Sun Microsystems 720 5300 Riata Trace Ct 721 Austin, TX 78727 722 US 724 Email: Nicolas.Williams@sun.com 726 Leif Johansson 727 Swedish University Network 728 Thulegatan 11 729 Stockholm 730 Sweden 732 Email: leifj@sunet.se 733 URI: http://www.sunet.se