draft-ietf-abfab-gss-eap-naming-05.txt   draft-ietf-abfab-gss-eap-naming-06.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: March 23, 2013 JANET(UK) Expires: April 7, 2013 JANET(UK)
September 19, 2012 October 4, 2012
Name Attributes for the GSS-API EAP mechanism Name Attributes for the GSS-API EAP mechanism
draft-ietf-abfab-gss-eap-naming-05 draft-ietf-abfab-gss-eap-naming-06
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 March 23, 2013. This Internet-Draft will expire on April 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5 3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5
4. Federated Context . . . . . . . . . . . . . . . . . . . . . . 6 4. Federated Context . . . . . . . . . . . . . . . . . . . . . . 6
5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 8 5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 8
6. Names of SAML Attributes in the Federated Context . . . . . . 9 6. Names of SAML Attributes in the Federated Context . . . . . . 9
6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 9 6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 9
6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 10 6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Registration of the GSS URN Namespace . . . . . . . . . . 12 8.1. Registration of the GSS URN Namespace . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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.ietf-abfab-gss-eap] allows an Authentication/Authorization/ [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/
Accounting peer to provide authorization attributes along side an Accounting (AAA) peer to provide authorization attributes along side
authentication response. It also provides mechanisms to process an 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. Other mechanisms such as SAML EC AAA response. Other mechanisms such as SAML EC
[I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and [I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and
attributes carried in the GSS-API. This document describes the attributes carried in the GSS-API. This document describes the
necessary information to use the naming extensions API to access SAML necessary information to use the naming extensions API to access SAML
assertions in the federated context and AAA attributes. 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.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
"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 of a subject. According to Section 8.2 and 2.7.3.1 of
[OASIS.saml-core-2.0-os], the name of an attribute has two parts. [OASIS.saml-core-2.0-os], the name of an attribute has two parts.
The first is a URI describing the format of the name. The second The first is a Universal Resource Identifier (URI) describing the
part, whose form depends on the format URI, is the actual name. GSS- format of the name. The second part, whose form depends on the
API name attributes may take a form starting with a URI describing format URI, is the actual name. GSS-API name attributes may take a
the form of the name; the rest of the name is specified by that URI. 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. SAML attributes carried in GSS-API names are named with three parts.
The first is a URN indicating that the name is a SAML attribute and The first is a Universal Resource Name (URN) indicating that the name
describing the context (Section 4). This URN is followed by a space, is a SAML attribute and describing the context (Section 4). This URN
the URI indicating the format of the SAML name, a space and the SAML is followed by a space, the URI indicating the format of the SAML
attribute name. The URI indicating the format of the SAML attribute name, a space and the SAML attribute name. The URI indicating the
name is not optional and MUST be present. format of the SAML attribute name is not optional and MUST be
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.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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 [I-D.ietf-abfab-gss-eap] mechanism are
named. The use of attributes defined in this section for other named. The use of attributes defined in this section for other
RADIUS messages or prior to the access-accept message is undefined at RADIUS messages or prior to the access-accept message is undefined at
this time. Future specifations can explore these areas giving this time. Future specifations can explore these areas giving
adequate weight to backward compatibility. In particular, this adequate weight to backward compatibility. In particular, this
specification defines the meaning of these attributes for the specification defines the meaning of these attributes for the
src_name output of GSS_Accept_sec_context after that function returns src_name output of GSS_Accept_sec_context after that function returns
GSS_S_COMPLETE. Attributes MAy be absent or values MAY change in GSS_S_COMPLETE. Attributes MAY be absent or values MAY change in
other circumstances; future specifications MAY define this behavior. other circumstances; 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 section
2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of 2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of
the User-Name attribute is "urn:ietf:params:gss:radius-attribute 1". the User-Name attribute is "urn:ietf:params:gss:radius-attribute 1".
The name of extended type 1 within type 241 would be The name of 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 username attribute. An application wishing to retrieve the
value of this attribute would first wait until GSS- value of this attribute would first wait until GSS-
_Accept_sec_Context returned GSS_S_COMPLETE. Then the application _Accept_sec_Context returned GSS_S_COMPLETE. Then the application
would take the src_name output from GSS_Accept_Sec_context and call would take the src_name output from GSS_Accept_sec_context and call
GSS_Get_Name_attribute passing this name and an attribute of GSS_Get_name_attribute passing this name and an attribute of
"urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming "urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming
that the authenticated boolean output is true, the application can that the authenticated boolean output is true, the application can
find the username in the values output. 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
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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.
This attribute is returned with the authenticatedoutput of This attribute is returned with the authenticated output of
GSS_Get_name_attribute true only when the mechanism can successfully GSS_Get_name_attribute true only when the mechanism can successfully
authenticated the SAML statement. For the GSS-EAP mechanism this is authenticated the SAML statement. For the GSS-EAP mechanism this is
true if the AAA exchange has successfully authenticated. However, true if the AAA exchange has successfully authenticated. However,
uses of the GSS-API MUST confirm that the attribute is marked uses of the GSS-API MUST confirm that the attribute is marked
authenticated as other mechanisms MAY permit an initiator to provide authenticated as other mechanisms MAY permit an initiator to provide
an unauthenticated SAML statement. 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.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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, spaces within a URI are encoded as "%20". Spaces
within a URI, including either the first or second part of the name, within a URI, including either the first or second part of the name,
encoding as "%20" do not separate parts of the GSS-API attribute encoding as "%20" do not separate parts of the GSS-API attribute
name; they are simply part of the URI. 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 the well-formed serialization of the GSS name attribute MUST be the well-formed serialization of the
<saml:AttributeValue> element(s) encoded as UTF-8. The "display" <saml:AttributeValue> element(s) encoded as UTF-8. The "display"
values are implementation-defined. 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.
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
skipping to change at page 11, line 20 skipping to change at page 11, line 20
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 [I-D.ietf-abfab-aaa-saml], then an application MAY get different
results depending on how the SAML is accessed. This is intended results depending on how the SAML is accessed. This is intended
behavior; applications who choose to bypass local policy checks behavior; applications who choose to bypass local policy checks
SHOULD perform their own evaluation before relying on information. SHOULD perform their own 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 is created titled "Generic Security Service
Application Program Interface Parameters". Application Program Interface Parameters".
In this top-level registry, a sub-registry titled "GSS-API URN In this top-level registry, a sub-registry titled "GSS-API URN
Parameters" is created. Registration in this registry is by the IETF Parameters" is created. Registration in this registry is by the IETF
review or expert review procedures [RFC5226]. Registrations in this review or expert review procedures [RFC5226].
registry are generally only expected as part of protocols published
as RFCs on the IETF stream; other URIs are expected to be better This paragraph gives guidance to designated experts. Registrations
choices for non-IETf work. Expert review is permitted mainly to in this registry are generally only expected as part of protocols
permit early registration related to specifications under development published as RFCs on the IETF stream; other URIs are expected to be
when the community believes they have reach sufficient maturity. 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 of
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 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 |
| | | | | |
skipping to change at page 13, line 10 skipping to change at page 14, line 10
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
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] [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-ietf-abfab-gss-eap-09 (work in progress), draft-ietf-abfab-gss-eap-09 (work in progress),
 End of changes. 17 change blocks. 
36 lines changed or deleted 47 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/