Movatterモバイル変換

Internet Engineering Task Force (IETF)                        S. HartmanRequest for Comments: 7056                             Painless SecurityCategory: Standards Track                                     J. HowlettISSN: 2070-1721                                                JANET(UK)                                                           December 2013Name Attributes for the GSS-APIExtensible Authentication Protocol (EAP) MechanismAbstract   The naming extensions to the Generic Security Service Application   Programming Interface (GSS-API) provide a mechanism for applications   to discover authorization and personalization information associated   with GSS-API names.  The Extensible Authentication Protocol GSS-API   mechanism allows an Authentication, Authorization, and Accounting   (AAA) peer to provide authorization attributes alongside an   authentication response.  It also supplies mechanisms to process   Security Assertion Markup Language (SAML) messages provided in the   AAA response.  This document describes how to use the Naming   Extensions API to access that information.Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7056.Hartman & Howlett            Standards Track                    [Page 1]

RFC 7056                 GSS EAP Name Attributes           December 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document must   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.Table of Contents1. Introduction ....................................................32. Requirements Notation ...........................................33. Naming Extensions and SAML ......................................34. Federated Context ...............................................45. Name Attributes for GSS-EAP .....................................56. Names of SAML Attributes in the Federated Context ...............66.1. Assertions .................................................66.2. SAML Attributes ............................................66.3. SAML Name Identifiers ......................................77. Security Considerations .........................................88. IANA Considerations .............................................88.1. Registration of the GSS URN Namespace ......................99. Acknowledgements ................................................910. References ....................................................1010.1. Normative References .....................................1010.2. Informative References ...................................11Hartman & Howlett            Standards Track                    [Page 2]

RFC 7056                 GSS EAP Name Attributes           December 20131.  Introduction   The naming extensions [RFC6680] to the Generic Security Service   Application Programming Interface (GSS-API) [RFC2743] provide a   mechanism for applications to discover authorization and   personalization information associated with GSS-API names.  The   Extensible Authentication Protocol GSS-API mechanism [RFC7055] allows   an Authentication, Authorization, and Accounting (AAA) peer to   provide authorization attributes alongside an authentication   response.  It also supplies mechanisms to process Security Assertion   Markup Language (SAML) messages provided in the AAA response.  Other   mechanisms such as SAML Enhanced Client (EC) [SASL-SAML] also support   SAML assertions and attributes carried in the GSS-API.  This document   describes how to use the Naming Extensions API to access that   information.   The semantics of setting attributes defined in this specification are   undefined and left to future work.2.  Requirements Notation   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in [RFC2119].3.  Naming Extensions and SAML   SAML assertions can carry attributes describing properties of the   subject of the assertion.  For example, an assertion might carry an   attribute describing the organizational affiliation or email address   of a subject.  According to Sections8.2 and2.7.3.1 of [OASIS], the   name of an attribute has two parts.  The first is a Universal   Resource Identifier (URI) describing the format of the name.  The   second part, whose form depends on the format URI, is the actual   name.  GSS-API name attributes may take a form starting with a URI   describing the form of the name; the rest of the name is specified by   that URI.   SAML attributes carried in GSS-API names are named with three parts.   The first is a Universal Resource Name (URN) indicating that the name   is a SAML attribute and describing the context (Section 4).  This URN   is followed by a space, the URI indicating the format of the SAML   name, a space, and the SAML attribute name.  The URI indicating the   format of the SAML attribute name is not optional and MUST be   present.Hartman & Howlett            Standards Track                    [Page 3]

RFC 7056                 GSS EAP Name Attributes           December 2013   SAML attribute names may not be globally unique.  Many names that are   named by URNs or URIs are likely to have semantics independent of the   issuer.  However, other name formats, including unspecified name   formats, make it easy for two issuers to choose the same name for   attributes with different semantics.  Attributes using the federated   context (Section 4) are issued by the same party performing the   authentication.  So, based on who is the subject of the name, the   semantics of the attribute can be determined.4.  Federated Context   GSS-API naming extensions have the concept of an authenticated name   attribute.  The mechanism guarantees that the contents of an   authenticated name attribute are an authenticated statement from the   trusted source of the peer credential.  The fact that an attribute is   authenticated does not imply that the trusted source of the peer   credential is authorized to assert the attribute.   In the federated context, the trusted source of the peer credential   is typically some identity provider.  In the GSS EAP mechanism,   information is combined from AAA and SAML sources.  The SAML Identity   Provider (IdP) and home AAA server are assumed to be in the same   trust domain.  However, this trust domain is not typically the same   as the trust domain of the service.  With other SAML mechanisms using   this specification, the SAML assertion also comes from the party   performing authentication.  Typically, the IdP is run by another   organization in the same federation.  The IdP is trusted to make some   statements, particularly related to the context of a federation.  For   example, an academic federation's participants would typically trust   an IdP's assertions about whether someone was a student or a   professor.  However, that same IdP would not typically be trusted to   make assertions about local entitlements such as group membership.   Thus, a service MUST make a policy decision about whether the IdP is   permitted to assert a particular attribute and about whether the   asserted value is acceptable.  This policy can be implemented as   local configuration on the service, as rules in AAA proxies, or   through other deployment-specific mechanisms.   In contrast, attributes in an enterprise context are often verified   by a central authentication infrastructure that is trusted to assert   most or all attributes.  For example, in a Kerberos infrastructure,   the Key Distribution Center (KDC) typically indicates group   membership information for clients to a server using KDC-   authenticated authorization data.   The context of an attribute is an important property of that   attribute; trust context is an important part of this overall   context.  In order for applications to distinguish the context ofHartman & Howlett            Standards Track                    [Page 4]

RFC 7056                 GSS EAP Name Attributes           December 2013   attributes, attributes with different contexts need different names.   This specification defines attribute names for SAML and AAA   attributes in the federated context.   These names MUST NOT be used for attributes issued by a party other   than one closely associated with the source of credentials unless the   source of credentials is re-asserting the attributes.  For example, a   source of credentials can consult whatever sources of attributes it   chooses, but acceptors can assume attributes in the federated context   are from the source of credentials.  This requirement is typically   enforced in mechanism specifications.  For example, [AAA-SAML]   provides enough information that we know the attributes it carries   today are in the federated context.  Similarly, we know that the   requirements of this paragraph are met by SAML mechanisms where the   assertion is the means of authentication.5.  Name Attributes for GSS-EAP   This section describes how RADIUS attributes received in an access-   accept message by the GSS-EAP [RFC7055] mechanism are named.  The use   of attributes defined in this section for other RADIUS messages or   prior to the access-accept message is undefined at this time.  Future   specifications can explore these areas giving adequate weight to   backward compatibility.  In particular, this specification defines   the meaning of these attributes for the src_name output of   GSS_Accept_sec_context after that function returns GSS_S_COMPLETE.   Attributes MAY be absent or values MAY change in other circumstances;   future specifications MAY define this behavior.   The first portion of the name is urn:ietf:params:gss:radius-attribute   (a URN indicating that this is a GSS-EAP RADIUS AVP).  This is   followed by a space and a numeric RADIUS name as described bySection 2.7 of [RFC6929].  For example, the name of the User-Name   attribute is "urn:ietf:params:gss:radius-attribute 1".  The name of   extended type 1 within type 241 would be   "urn:ietf:params:gss:radius-attribute 241.1".   Consider a case where the RADIUS access-accept response includes the   RADIUS User-Name attribute.  An application wishing to retrieve the   value of this attribute would first wait until   GSS-_Accept_sec_context returned GSS_S_COMPLETE.  Then, the   application would take the src_name output from   GSS_Accept_sec_context and call GSS_Get_name_attribute passing this   name and an attribute of "urn:ietf:params:gss:radius-attribute 1" as   inputs.  After confirming that the authenticated boolean output is   true, the application can find the username in the values output.Hartman & Howlett            Standards Track                    [Page 5]

RFC 7056                 GSS EAP Name Attributes           December 2013   The value of RADIUS attributes is the raw octets of the packet.   Integers are in network byte order.  The display value SHOULD be a   human-readable string; an implementation can only produce this string   if it knows the type of a given RADIUS attribute.  If multiple   attributes are present with a given name in the RADIUS message, then   a multi-valued GSS-API attribute SHOULD be returned.  As an   exception, implementations SHOULD concatenate RADIUS attributes such   as EAP message or large attributes defined in [RFC6929] that use   multiple attributes to carry more than 253 octets of information.6.  Names of SAML Attributes in the Federated Context6.1.  Assertions   An assertion generated by the credential source is named by   "urn:ietf:params:gss:federated-saml-assertion".  The value of this   attribute is the assertion carried in the AAA protocol or used for   authentication in a SAML mechanism.  This attribute is absent from a   given acceptor name if no such assertion is present or if the   assertion fails local policy checks.   When GSS_Get_name_attribute is called, this attribute will be   returned with the authenticated output set to true only if the   mechanism can successfully authenticate the SAML statement.  For the   GSS-EAP mechanism, this is true if the AAA exchange has successfully   authenticated.  However, uses of the GSS-API MUST confirm that the   attribute is marked authenticated as other mechanisms MAY permit an   initiator to provide an unauthenticated SAML statement.   Mechanisms MAY perform additional local policy checks and MAY remove   the attribute corresponding to assertions that fail these checks.6.2.  SAML Attributes   Each attribute carried in the assertion SHOULD also be a GSS name   attribute.  The name of this attribute has three parts, all separated   by an ASCII space character.  The first part is   urn:ietf:params:gss:federated-saml-attribute.  The second part is the   URI for the <saml:Attribute> element's NameFormat XML attribute.  The   final part is the <saml:Attribute> element's Name XML attribute.  The   SAML attribute name may itself contain spaces.  As required by the   URI specification [RFC3986], spaces within a URI are encoded as   "%20".  Spaces within a URI, including either the first or second   part of the name, encoded as "%20" do not separate parts of the   GSS-API attribute name; they are simply part of the URI.Hartman & Howlett            Standards Track                    [Page 6]

RFC 7056                 GSS EAP Name Attributes           December 2013   As an example, if the eduPersonEntitlement attribute is present in an   assertion, then an attribute with the name   "urn:ietf:params:gss:federated-saml-attribute   urn:oasis:names:tc:SAML:2.0:attrname-format:uri   urn:oid:1.3.6.1.4.1.5923.1.1.1.7" could be returned from   GSS_Inquire_Name.  If an application calls GSS_Get_name_attribute   with this attribute in the attr parameter, then the values output   would include one or more URIs of entitlements that were associated   with the authenticated user.   If the content of each <saml:AttributeValue> element is a simple text   node (or nodes), then the raw and "display" values of the GSS name   attribute MUST be the text content of the element(s).  The raw value   MUST be encoded as UTF-8.   If the value is not simple or is empty, then the raw value(s) of the   GSS name attribute MUST be a namespace well-formed serialization   [XMLNS] of the <saml:AttributeValue> element(s) encoded as UTF-8.   The "display" values are implementation defined.   These attributes SHOULD be marked authenticated if they are contained   in SAML assertions that have been successfully validated back to the   trusted source of the peer credential.  In the GSS-EAP mechanism, a   SAML assertion carried in an integrity-protected and authenticated   AAA protocol SHALL be successfully validated; attributes from that   assertion SHALL be returned from GSS_Get_name_attribute with the   authenticated output set to true.  An implementation MAY apply local   policy checks to each attribute in this assertion and discard the   attribute if it is unacceptable according to these checks.6.3.  SAML Name Identifiers   The <saml:NameID> carried in the subject of the assertion SHOULD also   be a GSS name attribute.  The name of this attribute has two parts,   separated by an ASCII space character.  The first part is   urn:ietf:params:gss:federated-saml-nameid.  The second part is the   URI for the <saml:NameID> element's Format XML attribute.   The raw value of the GSS name attribute MUST be the well-formed   serialization of the <saml:NameID> element encoded as UTF-8.  The   "display" value is implementation defined.  For formats defined by   Section 8.3 of [OASIS], missing values of the NameQualifier or   SPNameQualifier XML attributes MUST be populated in accordance with   the definition of the format prior to serialization.  In other words,   the defaulting rules specified for the "persistent" and "transient"   formats MUST be applied prior to serialization.Hartman & Howlett            Standards Track                    [Page 7]

RFC 7056                 GSS EAP Name Attributes           December 2013   This attribute SHOULD be marked authenticated if the name identifier   is contained in a SAML assertion that has been successfully validated   back to the trusted source of the peer credential.  In the GSS-EAP   mechanism, a SAML assertion carried in an integrity-protected and   authenticated AAA protocol SHALL be sufficiently validated.  An   implementation MAY apply local policy checks to this assertion and   discard it if it is unacceptable according to these checks.7.  Security Considerations   This document describes how to access RADIUS attributes, SAML   attributes, and SAML assertions from some GSS-API mechanisms.  These   attributes are typically used for one of two purposes.  The least   sensitive is personalization: a central service MAY provide   information about an authenticated user so they need not enter it   with each acceptor they access.  A more sensitive use is   authorization.   The mechanism is responsible for authentication and integrity   protection of the attributes.  However, the acceptor application is   responsible for making a decision about whether the credential source   is trusted to assert the attribute and validating the asserted value.   Mechanisms are permitted to perform local policy checks on SAML   assertions, attributes, and name identifiers exposed through name   attributes defined in this document.  If there is another way to get   access to the SAML assertion, for example, the mechanism described in   [AAA-SAML], then an application MAY get different results depending   on how the SAML is accessed.  This is intended behavior; applications   who choose to bypass local policy checks SHOULD perform their own   evaluation before relying on information.8.  IANA Considerations   A new top-level registry has been created titled "Generic Security   Service Application Program Interface Parameters".   In this top-level registry, a subregistry titled "GSS-API URN   Parameters" has been created.  Registration in this registry is by   the IETF Review or Expert Review procedures [RFC5226].   This paragraph gives guidance to Designated Experts.  Registrations   in this registry are generally only expected as part of protocols   published as RFCs on the IETF stream; other URIs are expected to be   better choices for non-IETF work.  Expert Review is permitted mainly   to permit early registration related to specifications under   development when the community believes they have reach sufficient   maturity.  The expert SHOULD evaluate the maturity and stability ofHartman & Howlett            Standards Track                    [Page 8]

RFC 7056                 GSS EAP Name Attributes           December 2013   such an IETF-stream specification.  Experts SHOULD review anything   not from the IETF stream for consistency and consensus with current   practice.  Today, such requests would not typically be approved.   If the "paramname" parameter is registered in this registry, then its   URN will be "urn:ietf:params:gss:paramname".  The initial   registrations are as follows:                +--------------------------+-------------+                | Parameter                | Reference   |                +--------------------------+-------------+                | radius-attribute         |Section 5   |                | federated-saml-assertion |Section 6.1 |                | federated-saml-attribute |Section 6.2 |                | federated-saml-nameid    |Section 6.3 |                +--------------------------+-------------+8.1.  Registration of the GSS URN Namespace   IANA has registered the "gss" URN sub-namespace in the IETF URN sub-   namespace for protocol parameters defined in [RFC3553].   Registry Name: gss   Specification:RFC 7056   Repository: GSS-API URN Parameters (Section 8)   Index Value: Sub-parameters MUST be specified in UTF-8 using standard   URI encoding where necessary.9.  Acknowledgements   Scott Cantor contributed significant text and multiple reviews of   this document.   The authors would like to thank Stephen Farrell, Luke Howard, and Jim   Schaad.   Sam Hartman's work on this specification has been funded by Janet.Hartman & Howlett            Standards Track                    [Page 9]

RFC 7056                 GSS EAP Name Attributes           December 201310.  References10.1.  Normative References   [OASIS]     Cantor, S., Kemp, J., Philpott, R., and E. Maler,               "Assertions and Protocol for the OASIS Security Assertion               Markup Language (SAML) V2.0", OASIS Standard               saml-core-2.0-os, March 2005.   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate               Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC2743]   Linn, J., "Generic Security Service Application Program               Interface Version 2, Update 1",RFC 2743, January 2000.   [RFC3553]   Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An               IETF URN Sub-namespace for Registered Protocol               Parameters",BCP 73,RFC 3553, June 2003.   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an               IANA Considerations Section in RFCs",BCP 26,RFC 5226,               May 2008.   [RFC6680]   Williams, N., Johansson, L., Hartman, S., and S.               Josefsson, "Generic Security Service Application               Programming Interface (GSS-API) Naming Extensions",RFC6680, August 2012.   [RFC6929]   DeKok, A. and A. Lior, "Remote Authentication Dial In               User Service (RADIUS) Protocol Extensions",RFC 6929,               April 2013.   [RFC7055]   Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for               the Extensible Authentication Protocol",RFC 7055,               December 2013.   [XMLNS]     W3C, "XML Namespaces Conformance", 2009,               <http://www.w3.org/TR/2009/REC-xml-names-20091208/#Conformance>.Hartman & Howlett            Standards Track                   [Page 10]

RFC 7056                 GSS EAP Name Attributes           December 201310.2.  Informative References   [AAA-SAML]  Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding,               Profiles, Name Identifier Format, and Confirmation               Methods for SAML", Work in Progress, July 2013.   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform               Resource Identifier (URI): Generic Syntax", STD 66,RFC3986, January 2005.   [SASL-SAML] Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL               and GSS-API Mechanisms", Work in Progress, September               2013.Authors' Addresses   Sam Hartman   Painless Security   EMail: hartmans-ietf@mit.edu   Josh Howlett   JANET(UK)   EMail: josh.howlett@ja.netHartman & Howlett            Standards Track                   [Page 11]