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