draft-ietf-abfab-gss-eap-naming-07.txt   rfc7056.txt 
Network Working Group S. Hartman Internet Engineering Task Force (IETF) S. Hartman
Internet-Draft Painless Security Request for Comments: 7056 Painless Security
Intended status: Standards Track J. Howlett Category: Standards Track J. Howlett
Expires: May 18, 2013 JANET(UK) ISSN: 2070-1721 JANET(UK)
November 14, 2012 December 2013
Name Attributes for the GSS-API EAP mechanism Name Attributes for the GSS-API
draft-ietf-abfab-gss-eap-naming-07 Extensible Authentication Protocol (EAP) Mechanism
Abstract Abstract
The naming extensions to the Generic Security Services Application The naming extensions to the Generic Security Service Application
Programming interface provide a mechanism for applications to Programming Interface (GSS-API) provide a mechanism for applications
discover authorization and personalization information associated to discover authorization and personalization information associated
with GSS-API names. The Extensible Authentication Protocol GSS-API with GSS-API names. The Extensible Authentication Protocol GSS-API
mechanism allows an Authentication/Authorization/Accounting peer to mechanism allows an Authentication, Authorization, and Accounting
provide authorization attributes along side an authentication (AAA) peer to provide authorization attributes alongside an
response. It also provides mechanisms to process Security Assertion authentication response. It also supplies mechanisms to process
Markup Language (SAML) messages provided in the AAA response. This Security Assertion Markup Language (SAML) messages provided in the
document describes the necessary information to use the naming AAA response. This document describes how to use the Naming
extensions API to access that information. Extensions API to access that information.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 18, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7056.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation ...........................................3
3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5 3. Naming Extensions and SAML ......................................3
4. Federated Context . . . . . . . . . . . . . . . . . . . . . . 6 4. Federated Context ...............................................4
5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 8 5. Name Attributes for GSS-EAP .....................................5
6. Names of SAML Attributes in the Federated Context . . . . . . 9 6. Names of SAML Attributes in the Federated Context ...............6
6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Assertions .................................................6
6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 9 6.2. SAML Attributes ............................................6
6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 10 6.3. SAML Name Identifiers ......................................7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations .........................................8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations .............................................8
8.1. Registration of the GSS URN Namespace . . . . . . . . . . 12 8.1. Registration of the GSS URN Namespace ......................9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements ................................................9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References ....................................................10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References .....................................10
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References ...................................11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The naming extensions [I-D.ietf-kitten-gssapi-naming-exts] to the The naming extensions [RFC6680] to the Generic Security Service
Generic Security Services Application Programming interface (GSS-API) Application Programming Interface (GSS-API) [RFC2743] provide a
[RFC2743] provide a mechanism for applications to discover mechanism for applications to discover authorization and
authorization and personalization information associated with GSS-API personalization information associated with GSS-API names. The
names. The Extensible Authentication Protocol GSS-API mechanism Extensible Authentication Protocol GSS-API mechanism [RFC7055] allows
[I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/ an Authentication, Authorization, and Accounting (AAA) peer to
Accounting (AAA) peer to provide authorization attributes along side provide authorization attributes alongside an authentication
an authentication response. It also provides mechanisms to process response. It also supplies mechanisms to process Security Assertion
Security Assertion Markup Language (SAML) messages provided in the Markup Language (SAML) messages provided in the AAA response. Other
AAA response. Other mechanisms such as SAML EC mechanisms such as SAML Enhanced Client (EC) [SASL-SAML] also support
[I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and SAML assertions and attributes carried in the GSS-API. This document
attributes carried in the GSS-API. This document describes the describes how to use the Naming Extensions API to access that
necessary information to use the naming extensions API to access SAML information.
assertions in the federated context and AAA attributes.
The semantics of setting attributes defined in this specification are The semantics of setting attributes defined in this specification are
undefined and left to future work. undefined and left to future work.
2. Requirements notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Naming Extensions and SAML 3. Naming Extensions and SAML
SAML assertions can carry attributes describing properties of the SAML assertions can carry attributes describing properties of the
subject of the assertion. For example, an assertion might carry an subject of the assertion. For example, an assertion might carry an
attribute describing the organizational affiliation or e-mail address attribute describing the organizational affiliation or email address
of a subject. According to Section 8.2 and 2.7.3.1 of of a subject. According to Sections 8.2 and 2.7.3.1 of [OASIS], the
[OASIS.saml-core-2.0-os], the name of an attribute has two parts. name of an attribute has two parts. The first is a Universal
The first is a Universal Resource Identifier (URI) describing the Resource Identifier (URI) describing the format of the name. The
format of the name. The second part, whose form depends on the second part, whose form depends on the format URI, is the actual
format URI, is the actual name. GSS-API name attributes may take a name. GSS-API name attributes may take a form starting with a URI
form starting with a URI describing the form of the name; the rest of describing the form of the name; the rest of the name is specified by
the name is specified by that URI. that URI.
SAML attributes carried in GSS-API names are named with three parts. SAML attributes carried in GSS-API names are named with three parts.
The first is a Universal Resource Name (URN) indicating that the name 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 a SAML attribute and describing the context (Section 4). This URN
is followed by a space, the URI indicating the format of the SAML 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 name, a space, and the SAML attribute name. The URI indicating the
format of the SAML attribute name is not optional and MUST be format of the SAML attribute name is not optional and MUST be
present. present.
SAML attribute names may not be globally unique. Many names that are 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 named by URNs or URIs are likely to have semantics independent of the
issuer. However other name formats, including unspecified name issuer. However, other name formats, including unspecified name
formats, make it easy for two issuers to choose the same name for formats, make it easy for two issuers to choose the same name for
attributes with different semantics. Attributes using the federated attributes with different semantics. Attributes using the federated
context Section 4 are issued by the same party performing the context (Section 4) are issued by the same party performing the
authentication. So, based on who is the subject of the name, the authentication. So, based on who is the subject of the name, the
semantics of the attribute can be determined. semantics of the attribute can be determined.
4. Federated Context 4. Federated Context
GSS-API naming extensions have the concept of an authenticated name GSS-API naming extensions have the concept of an authenticated name
attribute. The mechanism guarantees that the contents of an attribute. The mechanism guarantees that the contents of an
authenticated name attribute are an authenticated statement from the authenticated name attribute are an authenticated statement from the
trusted source of the peer credential. The fact that an attribute is trusted source of the peer credential. The fact that an attribute is
authenticated does not imply that the trusted source of the peer authenticated does not imply that the trusted source of the peer
credential is authorized to assert the attribute. credential is authorized to assert the attribute.
In the federated context, the trusted source of the peer credential In the federated context, the trusted source of the peer credential
is typically some identity provider. In the GSS EAP mechanism, is typically some identity provider. In the GSS EAP mechanism,
information is combined from AAA and SAML sources. The SAML IDP and information is combined from AAA and SAML sources. The SAML Identity
home AAA server are assumed to be in the same trust domain. However, Provider (IdP) and home AAA server are assumed to be in the same
this trust domain is not typically the same as the trust domain of trust domain. However, this trust domain is not typically the same
the service. With other SAML mechanisms using this specification, as the trust domain of the service. With other SAML mechanisms using
the SAML assertion also comes from the party performing this specification, the SAML assertion also comes from the party
authentication. Typically, the IDP is run by another organization in performing authentication. Typically, the IdP is run by another
the same federation. The IDP is trusted to make some statements, organization in the same federation. The IdP is trusted to make some
particularly related to the context of a federation. For example, an statements, particularly related to the context of a federation. For
academic federation's participants would typically trust an IDP's example, an academic federation's participants would typically trust
assertions about whether someone was a student or a professor. an IdP's assertions about whether someone was a student or a
However that same IDP would not typically be trusted to make professor. However, that same IdP would not typically be trusted to
assertions about local entitlements such as group membership. Thus, make assertions about local entitlements such as group membership.
a service MUST make a policy decision about whether the IDP is Thus, a service MUST make a policy decision about whether the IdP is
permitted to assert a particular attribute and about whether the permitted to assert a particular attribute and about whether the
asserted value is acceptable. This policy can be implemented as asserted value is acceptable. This policy can be implemented as
local configuration on the service, as rules in AAA proxies, or local configuration on the service, as rules in AAA proxies, or
through other deployment-specific mechanisms. through other deployment-specific mechanisms.
In contrast, attributes in an enterprise context are often verified In contrast, attributes in an enterprise context are often verified
by a central authentication infrastructure that is trusted to assert by a central authentication infrastructure that is trusted to assert
most or all attributes. For example, in a Kerberos infrastructure, most or all attributes. For example, in a Kerberos infrastructure,
the KDC typically indicates group membership information for clients the Key Distribution Center (KDC) typically indicates group
to a server using KDC-authenticated authorization data. membership information for clients to a server using KDC-
authenticated authorization data.
The context of an attribute is an important property of that The context of an attribute is an important property of that
attribute; trust context is an important part of this overall attribute; trust context is an important part of this overall
context. In order for applications to distinguish the context of context. In order for applications to distinguish the context of
attributes, attributes with different context need different names. attributes, attributes with different contexts need different names.
This specification defines attribute names for SAML and AAA This specification defines attribute names for SAML and AAA
attributes in the federated context. attributes in the federated context.
These names MUST NOT be used for attributes issued by a party other These names MUST NOT be used for attributes issued by a party other
than one closely associated with the source of credentials unless the 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 is re-asserting the attributes. For example, a
source of credentials can consult whatever sources of attributes it source of credentials can consult whatever sources of attributes it
chooses, but acceptors can assume attributes in the federated context chooses, but acceptors can assume attributes in the federated context
are from the source of credentials. This requirement is typically are from the source of credentials. This requirement is typically
enforced in mechanism specifications. For example enforced in mechanism specifications. For example, [AAA-SAML]
[I-D.ietf-abfab-aaa-saml] provides enough information thatwe know the provides enough information that we know the attributes it carries
attributes it carries today are in the federated context. Similarly, today are in the federated context. Similarly, we know that the
we know that the requirements of this paragraph are met by SAML requirements of this paragraph are met by SAML mechanisms where the
mechanisms where the assertion is the means of authentication. assertion is the means of authentication.
5. Name Attributes for GSS-EAP 5. Name Attributes for GSS-EAP
This section describes how RADIUS attributes received in an access- This section describes how RADIUS attributes received in an access-
accept message by the GSS-EAP [I-D.ietf-abfab-gss-eap] mechanism are accept message by the GSS-EAP [RFC7055] mechanism are named. The use
named. The use of attributes defined in this section for other of attributes defined in this section for other RADIUS messages or
RADIUS messages or prior to the access-accept message is undefined at prior to the access-accept message is undefined at this time. Future
this time. Future specifations can explore these areas giving specifications can explore these areas giving adequate weight to
adequate weight to backward compatibility. In particular, this backward compatibility. In particular, this specification defines
specification defines the meaning of these attributes for the the meaning of these attributes for the src_name output of
src_name output of GSS_Accept_sec_context after that function returns GSS_Accept_sec_context after that function returns GSS_S_COMPLETE.
GSS_S_COMPLETE. Attributes MAY be absent or values MAY change in Attributes MAY be absent or values MAY change in other circumstances;
other circumstances; future specifications MAY define this behavior. future specifications MAY define this behavior.
The first portion of the name is urn:ietf:params:gss:radius-attribute 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 (a URN indicating that this is a GSS-EAP RADIUS AVP). This is
followed by a space and a numeric RADIUS name as described by section followed by a space and a numeric RADIUS name as described by
2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of Section 2.7 of [RFC6929]. For example, the name of the User-Name
the User-Name attribute is "urn:ietf:params:gss:radius-attribute 1". attribute is "urn:ietf:params:gss:radius-attribute 1". The name of
The name of extended type 1 within type 241 would be extended type 1 within type 241 would be
"urn:ietf:params:gss:radius-attribute 241.1". "urn:ietf:params:gss:radius-attribute 241.1".
Consider a case where the RADIUS access-accept response includes the Consider a case where the RADIUS access-accept response includes the
RADIUS username attribute. An application wishing to retrieve the RADIUS User-Name attribute. An application wishing to retrieve the
value of this attribute would first wait until GSS- value of this attribute would first wait until
_Accept_sec_Context returned GSS_S_COMPLETE. Then the application GSS-_Accept_sec_context returned GSS_S_COMPLETE. Then, the
would take the src_name output from GSS_Accept_sec_context and call application would take the src_name output from
GSS_Get_name_attribute passing this name and an attribute of GSS_Accept_sec_context and call GSS_Get_name_attribute passing this
"urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming name and an attribute of "urn:ietf:params:gss:radius-attribute 1" as
that the authenticated boolean output is true, the application can inputs. After confirming that the authenticated boolean output is
find the username in the values output. true, the application can find the username in the values output.
The value of RADIUS attributes is the raw octets of the packet. The value of RADIUS attributes is the raw octets of the packet.
Integers are in network byte order. The display value SHOULD be a Integers are in network byte order. The display value SHOULD be a
human readable string; an implementation can only produce this string human-readable string; an implementation can only produce this string
if it knows the type of a given RADIUS attribute. If multiple if it knows the type of a given RADIUS attribute. If multiple
attributes are present with a given name in the RADIUS message, then attributes are present with a given name in the RADIUS message, then
a multi-valued GSS-API attribute SHOULD be returned. As an a multi-valued GSS-API attribute SHOULD be returned. As an
exception, implementations SHOULD concatenate RADIUS attributes such exception, implementations SHOULD concatenate RADIUS attributes such
as EAP-Message or large attributes defined in as EAP message or large attributes defined in [RFC6929] that use
[I-D.ietf-radext-radius-extensions] that use multiple attributes to multiple attributes to carry more than 253 octets of information.
carry more than 253 octets of information.
6. Names of SAML Attributes in the Federated Context 6. Names of SAML Attributes in the Federated Context
6.1. Assertions 6.1. Assertions
An assertion generated by the credential source is named by An assertion generated by the credential source is named by
"urn:ietf:params:gss:federated-saml-assertion". The value of this "urn:ietf:params:gss:federated-saml-assertion". The value of this
attribute is the assertion carried in the AAA protocol or used for attribute is the assertion carried in the AAA protocol or used for
authentication in a SAML mechanism. This attribute is absent from a authentication in a SAML mechanism. This attribute is absent from a
given acceptor name if no such assertion is present or if the given acceptor name if no such assertion is present or if the
assertion fails local policy checks. assertion fails local policy checks.
When GSS_Get_name_attribute is called, This attribute will be When GSS_Get_name_attribute is called, this attribute will be
returned with the authenticated output set to true only if the returned with the authenticated output set to true only if the
mechanism can successfully authenticate the SAML statement. For the mechanism can successfully authenticate the SAML statement. For the
GSS-EAP mechanism this is true if the AAA exchange has successfully GSS-EAP mechanism, this is true if the AAA exchange has successfully
authenticated. However, uses of the GSS-API MUST confirm that the authenticated. However, uses of the GSS-API MUST confirm that the
attribute is marked authenticated as other mechanisms MAY permit an attribute is marked authenticated as other mechanisms MAY permit an
initiator to provide an unauthenticated SAML statement. initiator to provide an unauthenticated SAML statement.
Mechanisms MAY perform additional local policy checks and MAY remove Mechanisms MAY perform additional local policy checks and MAY remove
the attribute corresponding to assertions that fail these checks. the attribute corresponding to assertions that fail these checks.
6.2. SAML Attributes 6.2. SAML Attributes
Each attribute carried in the assertion SHOULD also be a GSS name Each attribute carried in the assertion SHOULD also be a GSS name
attribute. The name of this attribute has three parts, all separated attribute. The name of this attribute has three parts, all separated
by an ASCII space character. The first part is by an ASCII space character. The first part is
urn:ietf:params:gss:federated-saml-attribute. The second part is the urn:ietf:params:gss:federated-saml-attribute. The second part is the
URI for the <saml:Attribute> element's NameFormat XML attribute. The URI for the <saml:Attribute> element's NameFormat XML attribute. The
final part is the <saml:Attribute> element's Name 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 SAML attribute name may itself contain spaces. As required by the
URI specification, spaces within a URI are encoded as "%20". Spaces URI specification [RFC3986], spaces within a URI are encoded as
within a URI, including either the first or second part of the name, "%20". Spaces within a URI, including either the first or second
encoded as "%20" do not separate parts of the GSS-API attribute name; part of the name, encoded as "%20" do not separate parts of the
they are simply part of the URI. GSS-API attribute name; they are simply part of the URI.
As an example, if the eduPersonEntitlement attribute is present in an As an example, if the eduPersonEntitlement attribute is present in an
assertion, then an attribute with the name assertion, then an attribute with the name
"urn:ietf:params:gss:federated-saml-attribute "urn:ietf:params:gss:federated-saml-attribute
urn:oasis:names:tc:SAML:2.0:attrname-format:uri 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 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 GSS_Inquire_Name. If an application calls GSS_Get_name_attribute
with this attribute in the attr parameter then the values output with this attribute in the attr parameter, then the values output
would include one or more URIs of entitlements that were associated would include one or more URIs of entitlements that were associated
with the authenticated user. with the authenticated user.
If the content of each <saml:AttributeValue> element is a simple text 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 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 attribute MUST be the text content of the element(s). The raw value
MUST be encoded as UTF-8. MUST be encoded as UTF-8.
If the value is not simple or is empty, then the raw value(s) of the 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 GSS name attribute MUST be a namespace well-formed serialization
[XMLNS]of the <saml:AttributeValue> element(s) encoded as UTF-8. The [XMLNS] of the <saml:AttributeValue> element(s) encoded as UTF-8.
"display" values are implementation-defined. The "display" values are implementation defined.
These attributes SHOULD be marked authenticated if they are contained These attributes SHOULD be marked authenticated if they are contained
in SAML assertions that have been successfully validated back to the in SAML assertions that have been successfully validated back to the
trusted source of the peer credential. In the GSS-EAP mechanism, a trusted source of the peer credential. In the GSS-EAP mechanism, a
SAML assertion carried in an integrity-protected and authenticated SAML assertion carried in an integrity-protected and authenticated
AAA protocol SHALL be successfully validated; attributes from that AAA protocol SHALL be successfully validated; attributes from that
assertion SHALL be returned from GSS_Get_name_attribute with the assertion SHALL be returned from GSS_Get_name_attribute with the
authenticated output set to true. An implementation MAY apply local authenticated output set to true. An implementation MAY apply local
policy checks to each attribute in this assertion and discard the policy checks to each attribute in this assertion and discard the
attribute if it is unacceptable according to these checks. attribute if it is unacceptable according to these checks.
skipping to change at page 10, line 32 skipping to change at page 7, line 45
6.3. SAML Name Identifiers 6.3. SAML Name Identifiers
The <saml:NameID> carried in the subject of the assertion SHOULD also 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, be a GSS name attribute. The name of this attribute has two parts,
separated by an ASCII space character. The first part is separated by an ASCII space character. The first part is
urn:ietf:params:gss:federated-saml-nameid. The second part is the urn:ietf:params:gss:federated-saml-nameid. The second part is the
URI for the <saml:NameID> element's Format XML attribute. URI for the <saml:NameID> element's Format XML attribute.
The raw value of the GSS name attribute MUST be the well-formed The raw value of the GSS name attribute MUST be the well-formed
serialization of the <saml:NameID> element encoded as UTF-8. The serialization of the <saml:NameID> element encoded as UTF-8. The
"display" value is implementation-defined. For formats defined by "display" value is implementation defined. For formats defined by
section 8.3 of [OASIS.saml-core-2.0-os], missing values of the Section 8.3 of [OASIS], missing values of the NameQualifier or
NameQualifier or SPNameQualifier XML attributes MUST be populated in SPNameQualifier XML attributes MUST be populated in accordance with
accordance with the definition of the format prior to serialization. the definition of the format prior to serialization. In other words,
In other words, the defaulting rules specified for the "persistent" the defaulting rules specified for the "persistent" and "transient"
and "transient" formats MUST be applied prior to serialization. formats MUST be applied prior to serialization.
This attribute SHOULD be marked authenticated if the name identifier This attribute SHOULD be marked authenticated if the name identifier
is contained in a SAML assertion that has been successfully validated is contained in a SAML assertion that has been successfully validated
back to the trusted source of the peer credential. In the GSS-EAP back to the trusted source of the peer credential. In the GSS-EAP
mechanism, a SAML assertion carried in an integrity-protected and mechanism, a SAML assertion carried in an integrity-protected and
authenticated AAA protocol SHALL be sufficiently validated. An authenticated AAA protocol SHALL be sufficiently validated. An
implementation MAY apply local policy checks to this assertion and implementation MAY apply local policy checks to this assertion and
discard it if it is unacceptable according to these checks. discard it if it is unacceptable according to these checks.
7. Security Considerations 7. Security Considerations
This document describes how to access RADIUS attributes, SAML This document describes how to access RADIUS attributes, SAML
attributes and SAML assertions from some GSS-API mechanisms. These attributes, and SAML assertions from some GSS-API mechanisms. These
attributes are typically used for one of two purposes. The least attributes are typically used for one of two purposes. The least
sensitive is personalization: a central service MAY provide sensitive is personalization: a central service MAY provide
information about an authenticated user so they need not enter it information about an authenticated user so they need not enter it
with each acceptor they access. A more sensitive use is with each acceptor they access. A more sensitive use is
authorization. authorization.
The mechanism is responsible for authentication and integrity The mechanism is responsible for authentication and integrity
protection of the attributes. However, the acceptor application is protection of the attributes. However, the acceptor application is
responsible for making a decision about whether the credential source responsible for making a decision about whether the credential source
is trusted to assert the attribute and validating the asserted value. is trusted to assert the attribute and validating the asserted value.
Mechanisms are permitted to perform local policy checks on SAML Mechanisms are permitted to perform local policy checks on SAML
assertions, attributes and name identifiers exposed through name assertions, attributes, and name identifiers exposed through name
attributes defined in this document. If there is another way to get attributes defined in this document. If there is another way to get
access to the SAML assertion, for example the mechanism described in access to the SAML assertion, for example, the mechanism described in
[I-D.ietf-abfab-aaa-saml], then an application MAY get different [AAA-SAML], then an application MAY get different results depending
results depending on how the SAML is accessed. This is intended on how the SAML is accessed. This is intended behavior; applications
behavior; applications who choose to bypass local policy checks who choose to bypass local policy checks SHOULD perform their own
SHOULD perform their own evaluation before relying on information. evaluation before relying on information.
8. IANA Considerations 8. IANA Considerations
A new top-level registry is created titled "Generic Security Service A new top-level registry has been created titled "Generic Security
Application Program Interface Parameters". Service Application Program Interface Parameters".
In this top-level registry, a sub-registry titled "GSS-API URN In this top-level registry, a subregistry titled "GSS-API URN
Parameters" is created. Registration in this registry is by the IETF Parameters" has been created. Registration in this registry is by
review or expert review procedures [RFC5226]. the IETF Review or Expert Review procedures [RFC5226].
This paragraph gives guidance to designated experts. Registrations This paragraph gives guidance to Designated Experts. Registrations
in this registry are generally only expected as part of protocols in this registry are generally only expected as part of protocols
published as RFCs on the IETF stream; other URIs are expected to be published as RFCs on the IETF stream; other URIs are expected to be
better choices for non-IETf work. Expert review is permitted mainly better choices for non-IETF work. Expert Review is permitted mainly
to permit early registration related to specifications under to permit early registration related to specifications under
development when the community believes they have reach sufficient development when the community believes they have reach sufficient
maturity. The expert SHOULD evaluate the maturity and stability of maturity. The expert SHOULD evaluate the maturity and stability of
such an IETF-stream specification. Experts SHOULD review anything such an IETF-stream specification. Experts SHOULD review anything
not from the IETF stream for consistency and consensus with current not from the IETF stream for consistency and consensus with current
practice. Today such requests would not typically be approved. practice. Today, such requests would not typically be approved.
If the "paramname" parameter is registered in this registry then its If the "paramname" parameter is registered in this registry, then its
URN will be "urn:ietf:params:gss:paramname". The initial URN will be "urn:ietf:params:gss:paramname". The initial
registrations are as follows: registrations are as follows:
+--------------------------+-------------+ +--------------------------+-------------+
| Parameter | Reference | | Parameter | Reference |
+--------------------------+-------------+ +--------------------------+-------------+
| radius-attribute | Section 5 | | radius-attribute | Section 5 |
| | |
| federated-saml-assertion | Section 6.1 | | federated-saml-assertion | Section 6.1 |
| | |
| federated-saml-attribute | Section 6.2 | | federated-saml-attribute | Section 6.2 |
| | |
| federated-saml-nameid | Section 6.3 | | federated-saml-nameid | Section 6.3 |
+--------------------------+-------------+ +--------------------------+-------------+
8.1. Registration of the GSS URN Namespace 8.1. Registration of the GSS URN Namespace
IANA is requested to register the "gss" URN sub-namespace in the IETF IANA has registered the "gss" URN sub-namespace in the IETF URN sub-
URN sub-namespace for protocol parameters defined in [RFC3553]. namespace for protocol parameters defined in [RFC3553].
Registry Name: gss Registry Name: gss
Specification: draft-ietf-abfab-gss-eap-naming Specification: RFC 7056
Repository: GSS-API URN Parameters (Section 8) Repository: GSS-API URN Parameters (Section 8)
Index Value: Sub-parameters MUST be specified in UTF-8 using standard Index Value: Sub-parameters MUST be specified in UTF-8 using standard
URI encoding where necessary. URI encoding where necessary.
9. Acknowledgements 9. Acknowledgements
Scott Cantor contributed significant text and multiple reviews of Scott Cantor contributed significant text and multiple reviews of
this document. this document.
The authors would like to thank Stephen Farrell, Luke Howard, and Jim The authors would like to thank Stephen Farrell, Luke Howard, and Jim
Schaad Schaad.
Sam hartman's work on this specification has been funded by Janet. Sam Hartman's work on this specification has been funded by Janet.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-abfab-gss-eap] [OASIS] Cantor, S., Kemp, J., Philpott, R., and E. Maler,
Hartman, S. and J. Howlett, "A GSS-API Mechanism for the "Assertions and Protocol for the OASIS Security Assertion
Extensible Authentication Protocol", Markup Language (SAML) V2.0", OASIS Standard
draft-ietf-abfab-gss-eap-09 (work in progress), saml-core-2.0-os, March 2005.
August 2012.
[I-D.ietf-kitten-gssapi-naming-exts] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Williams, N., Johansson, L., Hartman, S., and S. Requirement Levels", BCP 14, RFC 2119, March 1997.
Josefsson, "GSS-API Naming Extensions",
draft-ietf-kitten-gssapi-naming-exts-15 (work in
progress), May 2012.
[I-D.ietf-radext-radius-extensions] [RFC2743] Linn, J., "Generic Security Service Application Program
DeKok, A. and A. Lior, "Remote Authentication Dial In User Interface Version 2, Update 1", RFC 2743, January 2000.
Service (RADIUS) Protocol Extensions",
draft-ietf-radext-radius-extensions-06 (work in progress),
June 2012.
[OASIS.saml-core-2.0-os] [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
Cantor, S., Kemp, J., Philpott, R., and E. Maler, IETF URN Sub-namespace for Registered Protocol
"Assertions and Protocol for the OASIS Security Assertion Parameters", BCP 73, RFC 3553, June 2003.
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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Requirement Levels", BCP 14, RFC 2119, March 1997. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
Interface Version 2, Update 1", RFC 2743, January 2000. Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions", RFC
6680, August 2012.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In
IETF URN Sub-namespace for Registered Protocol User Service (RADIUS) Protocol Extensions", RFC 6929,
Parameters", BCP 73, RFC 3553, June 2003. April 2013.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, the Extensible Authentication Protocol", RFC 7055,
May 2008. December 2013.
[XMLNS] W3C, "XML Namespaces Conformance", 2009, <http:// [XMLNS] W3C, "XML Namespaces Conformance", 2009,
www.w3.org/TR/2009/REC-xml-names-20091208/#Conformance>. <http://www.w3.org/TR/2009/REC-xml-names-20091208/
#Conformance>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-abfab-aaa-saml] [AAA-SAML] Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding,
Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding Profiles, Name Identifier Format, and Confirmation
and Profiles for SAML", draft-ietf-abfab-aaa-saml-04 (work Methods for SAML", Work in Progress, July 2013.
in progress), October 2012.
[I-D.ietf-kitten-sasl-saml-ec] [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL Resource Identifier (URI): Generic Syntax", STD 66, RFC
and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-04 3986, January 2005.
(work in progress), October 2012.
[SASL-SAML] Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL
and GSS-API Mechanisms", Work in Progress, September
2013.
Authors' Addresses Authors' Addresses
Sam Hartman Sam Hartman
Painless Security Painless Security
Email: hartmans-ietf@mit.edu EMail: hartmans-ietf@mit.edu
Josh Howlett Josh Howlett
JANET(UK) JANET(UK)
Email: josh.howlett@ja.net EMail: josh.howlett@ja.net
 End of changes. 60 change blocks. 
199 lines changed or deleted 188 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/