draft-ietf-abfab-gss-eap-naming-00.txt   draft-ietf-abfab-gss-eap-naming-01.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Intended status: Standards Track J. Howlett Intended status: Standards Track J. Howlett
Expires: April 16, 2011 JANET(UK) Expires: April 23, 2012 JANET(UK)
October 13, 2010 October 21, 2011
Name Attributes for the GSS-API EAP mechanism Name Attributes for the GSS-API EAP mechanism
draft-ietf-abfab-gss-eap-naming-00 draft-ietf-abfab-gss-eap-naming-01
Abstract Abstract
The naming extensions to the Generic Security Services Application The naming extensions to the Generic Security Services Application
Programming interface provide a mechanism for applications to Programming interface provide a mechanism for applications to
discover authorization and personalization information associated 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/Accounting peer to
provide authorization attributes along side an authentication provide authorization attributes along side an authentication
response. It also provides mechanisms to process Security Assertion response. It also provides mechanisms to process Security Assertion
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2011. This Internet-Draft will expire on April 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . 4
3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5 3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5
4. RADIUS and Authenticated Attributes . . . . . . . . . . . . . 6 4. Federated Context . . . . . . . . . . . . . . . . . . . . . . 6
5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 8 5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 7
5.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Names of SAML Attributes in the Federated Context . . . . . . 8
5.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 8 6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 8 6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the
Generic Security Services Application Programming interface (GSS-API) Generic Security Services Application Programming interface (GSS-API)
[RFC2743] provide a mechanism for applications to discover [RFC2743] provide a mechanism for applications to discover
authorization and personalization information associated with GSS-API authorization and personalization information associated with GSS-API
names. The Extensible Authentication Protocol GSS-API mechanism names. The Extensible Authentication Protocol GSS-API mechanism
[I-D.howlett-eap-gss] allows an Authentication/Authorization/ [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/
Accounting peer to provide authorization attributes along side an Accounting peer to provide authorization attributes along side an
authentication response. It also provides mechanisms to process authentication response. It also provides mechanisms to process
Security Assertion Markup Language (SAML) messages provided in the Security Assertion Markup Language (SAML) messages provided in the
AAA response. This document describes the necessary information to AAA response. Other mechanisms such as SAML EC
use the naming extensions API to access that information. [I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and
attributes carried in the GSS-API. This document describes the
necessary information to use the naming extensions API to access SAML
assertions in the federated context and AAA attributes.
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 e-mail address
of a subject. According to Section 8.2 and 2.7.3.1 of [SAMLCORE], of a subject. According to Section 8.2 and 2.7.3.1 of [SAMLCORE],
the name of an attribute has two parts. The first is a URI the name of an attribute has two parts. The first is a URI
describing the format of the name. The second part, whose form describing the format of the name. The second part, whose form
depends on the format URI, is the actual name. As of June 2010, GSS- depends on the format URI, is the actual name. GSS-API name
API name attributes take the form of a single URI. 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.
Administrators may need to type SAML attribute names into SAML attributes carried in GSS-API names are named with three parts.
configuration files or otherwise tell applications how to find The first is a URN indicating that the name is a SAML attribute and
attributes. It is desirable to support accessing these attributes describing the context (Section 4). This URI is followed by a space,
from applications that have no awareness of SAML. So, the GSS-API the URI indicating the format of the SAML name, a space and the SAML
attribute name should be something that an administrator can attribute name. The URI indicating the format of the SAML attribute
reasonably easily construct from a SAML attribute name. In name is not optional and MUST be present.
particular, adding or removing URI escapes, base64 encoding or
similar transformations would significantly decrease usability.
Instead, it seems desirable to extend GSS-API naming extensions to SAML attribute names may not be globally unique. Many names that are
support concepts such as SAML names where the format is specified named by URNs or URIs are likely to have semantics independent of the
separately. The format of GSS-API attribute names should be changed. issuer. However for other name formats, including unspecified name
If no space character is found in the name, then the name is formats, make it easy for two issuers to choose the same name for
interpreted as a URI describing the attribute. Otherwise, the attributes with different semantics. Attributes using the federated
portion from the beginning of the buffer to the first space is context Section 4 are issued by the same party performing the
interpreted as a URI describing the form and interpretation of the authentication. So, based on who is named by the name, the semantics
rest of the buffer; this portion is known as the attribute type URI. of the attribute can be determined.
4. RADIUS and Authenticated Attributes 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 IDP and
home AAA server are assumed to be in the same trust domain. However, 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 this trust domain is not typically the same as the trust domain of
the service. Typically, the IDP is run by another organization in 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, the same federation. The IDP is trusted to make some statements,
particularly related to the context of a federation. For example, an particularly related to the context of a federation. For example, an
academic federation's participants would typically trust an IDP's academic federation's participants would typically trust an IDP's
assertions about whether someone was a student or a professor. assertions about whether someone was a student or a professor.
However that same IDP would not typically be trusted to make However that same IDP would not typically be trusted to make
assertions about local entitlements such as group membership. Thus, assertions about local entitlements such as group membership. Thus,
a service MUST make a policy decision about whether the IDP is 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. asserted value is acceptable.
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 KDC typically indicates group membership information for clients
to a server using KDC-authenticated authorization data. 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 the context. attribute; trust context is an important part of the context. In
Applications will often want to treat an attribute in a federated order for applications to distinguish the context of attributes,
context the same as an attribute in an enterprise context. In order attributes with different context need different names. This
for applications to distinguish the context of attributes, attributes specification defines attribute names for SAML and AA attributes in
with different context need different names. For example, the name the federated context.
of an attribute containing the initiator's e-mail address in a
federated context needs to be different from the name containing the
initiator's e-mail address in a different context. The determination
of trust from this context information can never be exact: Kerberos
typically is used in environments where the KDC is fairly trusted,
but an application could have a key in a realm that it does not fully
trust. Similarly, SAML is typically in a federated context, but an
organization could use SAML for internal authentication as well.
It would be convenient to use the same GSS-API attribute names for These names MUST not be used for attributes issued by a party other
the same information regardless of context. However, when than one closely associated with the source of credentials unless the
considering attribute names it is critical to consider the source of credentials is re-asserting the attributes. For example, a
appropriate interpretation of that name and the distinctions an source of credentials can consult whatever sources of attributes it
application will need to make about the name. As a result, it is chooses, but acceptors can assume attributes in the federated context
often the case that attributes from two different mechanisms will are from the source of credentials.
have different names.
However, the local implementation of the mechanism and layers in the 5. Name Attributes for GSS-EAP
GSS-API implementation above the mechanism can make the job of the
application easier. If local policy permits an attribute to be
trusted, then the attribute can be copied to a name whose context
indicates that local policy has been applied. For example, an
implementation could have an attribute for e-mail address that
received the value both of a SAML mechanism and Kerberos mechanism's
e-mail address attributes after local policy is applied. Such
mechanism-level attributes can also be used to normalize the format
of attribute values.
In the case of GSS-EAP, the attribute names need to be specific to This section describes how RADIUS attributes received with the GSS-
SAML attributes obtained via AAA transport. EAP mechanism are named.
5. Name Attributes for GSS-EAP The first portion of the name is TBD1 (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 2.6 of
[I-D.ietf-radext-radius-extensions]. For example the name of the
User-Name attribute is "TBD 1". The name of extended type 1 within
type 241 would be "TBD 241.1".
This section describes how SAML assertions, SAML attributes and The value of RADIUS attributes is the raw octets of the packet.
RADIUS attributes received with the GSS-EAP mechanism are named. 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.
5.1. Assertions 6. Names of SAML Attributes in the Federated Context
Implementations of GSS-EAP MUST support an attribute with the name 6.1. Assertions
An assertion generated by the credential source is named by
"urn:ietf:params:gss-eap:saml-aaa-assertion". The value of this "urn:ietf:params:gss-eap:saml-aaa-assertion". The value of this
attribute is the assertion carried in the AAA protocol. This attribute is the assertion carried in the AAA protocol or used for
attribute is absent from a given acceptor name if no such assertion authentication in a SAML mechanism. This attribute is absent from a
is present or if the assertion fails local policy checks. This given acceptor name if no such assertion is present or if the
attribute is always authentic when present: authentication only assertion fails local policy checks. This attribute is always
succeeds if the AAA exchange is successfully authenticated. However, authentic when present: authentication only succeeds if the AAA
users of the GSS-API MUST confirm that the attribute is authenticated exchange is successfully authenticated. However, users of the GSS-
because some mechanisms MAY permit an initiator to assert an API MUST confirm that the attribute is authenticated because some
unauthenticated version of this attribute. mechanisms MAY permit an initiator to assert an unauthenticated
version of this attribute.
5.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-eap:saml-attr. The second part is the URI for urn:ietf:params:gss-eap:saml-attr. The second part is the URI for
the SAML attribute name format. The final part is the name of the the SAML attribute name format. The final part is the name of the
SAML attribute. If the mechanism performs an additional attribute SAML attribute.
query, the retrieved attributes SHOULD be GSS-API name attributes
using the same name syntax.
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 sufficiently validated. An implementation MAY AAA protocol SHALL be sufficiently validated. An implementation MAY
apply local policy checks to this assertion and discard it if it is apply local policy checks to this assertion and discard it if it is
unacceptable according to these checks. unacceptable according to these checks.
Attribute query results made based on this assertion also count as 7. Security Considerations
originating with the source of the peer credential. The
implementation MUST validate the authenticity of these results before
they are processed.
5.3. RADIUS Attributes
A mechanism needs to be created to give applications access to AAA
AVPs carried along with an access-accept message.
6. 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.
This needs to be written. 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.
7. IANA Considerations 8. IANA Considerations
This section needs to include URN registrations within the IETF This section needs to include URN registrations within the IETF
namespace for URNs that are used. namespace for URNs that are used.
8. Normative References 9. References
[I-D.howlett-eap-gss] 9.1. Normative References
[I-D.ietf-abfab-gss-eap]
Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
Extensible Authentication Protocol", Extensible Authentication Protocol",
draft-howlett-eap-gss-00 (work in progress), March 2010. draft-ietf-abfab-gss-eap-03 (work in progress),
October 2011.
[I-D.ietf-kitten-gssapi-naming-exts] [I-D.ietf-kitten-gssapi-naming-exts]
Williams, N. and L. Johansson, "GSS-API Naming Williams, N., Johansson, L., Hartman, S., and S.
Extensions", draft-ietf-kitten-gssapi-naming-exts-08 (work Josefsson, "GSS-API Naming Extensions",
in progress), June 2010. draft-ietf-kitten-gssapi-naming-exts-11 (work in
progress), May 2011.
[I-D.ietf-radext-radius-extensions]
DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions",
draft-ietf-radext-radius-extensions-01 (work in progress),
June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
9.2. Informative References
[I-D.ietf-kitten-sasl-saml-ec]
Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL
and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-00
(work in progress), August 2011.
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)
 End of changes. 32 change blocks. 
103 lines changed or deleted 117 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/