draft-ietf-abfab-gss-eap-naming-02.txt   draft-ietf-abfab-gss-eap-naming-03.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: September 13, 2012 JANET(UK) Expires: January 12, 2013 JANET(UK)
March 12, 2012 July 11, 2012
Name Attributes for the GSS-API EAP mechanism Name Attributes for the GSS-API EAP mechanism
draft-ietf-abfab-gss-eap-naming-02 draft-ietf-abfab-gss-eap-naming-03
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 September 13, 2012. This Internet-Draft will expire on January 12, 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 24 skipping to change at page 2, line 24
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 7 5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 7
6. Names of SAML Attributes in the Federated Context . . . . . . 8 6. Names of SAML Attributes in the Federated Context . . . . . . 8
6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 8 6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 8
6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 8 6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. Registration of the GSS URN Namespace . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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)
skipping to change at page 4, line 5 skipping to change at page 3, line 22
[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 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. 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 definied in this specification
are 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
skipping to change at page 6, line 45 skipping to change at page 6, line 45
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 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 context 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. are from the source of credentials.
5. Name Attributes for GSS-EAP 5. Name Attributes for GSS-EAP
This section describes how RADIUS attributes received with the GSS- This section describes how RADIUS attributes received in an access-
EAP mechanism are named. accept message by the GSS-EAP mechanism are named.
The first portion of the name is urn:ietf:params:gss:radius-attr (a The first portion of the name is urn:ietf:params:gss:radius-attribute
URN indicating that this is a GSS-EAP RADIUS AVP). This is followed (a URN indicating that this is a GSS-EAP RADIUS AVP). This is
by a space and a numeric RADIUS name as described by section 2.6 of followed by a space and a numeric RADIUS name as described by section
[I-D.ietf-radext-radius-extensions]. For example the name of the 2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of
User-Name attribute is "urn:ietf:gss:radius-attr 1". The name of the User-Name attribute is "urn:ietf:gss:radius-attribute 1". The
extended type 1 within type 241 would be "urn:ietf:gss:radius-attr name of extended type 1 within type 241 would be
241.1". "urn:ietf:gss:radius-attribute 241.1".
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 it knows the type of a given RADIUS attribute. If multiple
attributes are present with a given name in the RADIUS message, then
a multi-valued GSS-API attribute SHOULD be returned. As an
exception, implementations SHOULD concatenate RADIUS attributes such
as EAP-Message or large attributes defined in
[I-D.ietf-radext-radius-extensions] that use multiple attributes to
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:fed-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. This attribute is always assertion fails local policy checks. This attribute is always
authentic when present: authentication only succeeds if the AAA authentic when present: authentication only succeeds if the AAA
exchange is successfully authenticated. However, users of the GSS- exchange is successfully authenticated. However, users of the GSS-
API MUST confirm that the attribute is authenticated because some API MUST confirm that the attribute is authenticated because some
mechanisms MAY permit an initiator to assert an unauthenticated mechanisms MAY permit an initiator to assert an unauthenticated
version of this attribute. version of this attribute.
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:fed-saml-attr. The second part is the URI for urn:ietf:params:gss:federated-saml-attribute. The second part is the
the <saml:Attribute> element's NameFormat XML attribute. The final URI for the <saml:Attribute> element's NameFormat XML attribute. The
part is the <saml:Attribute> element's Name XML attribute. final part is the <saml:Attribute> element's Name XML attribute.
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, then the raw value(s) of the GSS name If the value is not simple or is empty, then the raw value(s) of the
attribute MUST be the well-formed serialization of the <saml: GSS name attribute MUST be the well-formed serialization of the
AttributeValue> element(s) encoded as UTF-8. The "display" values <saml:AttributeValue> element(s) encoded as UTF-8. The "display"
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 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.
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:fed-saml-nameid. The second part is the URI for urn:ietf:params:gss:federated-saml-nameid. The second part is the
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 [SAMLCORE], missing values of the NameQualifier or section 8.3 of [SAMLCORE], missing values of the NameQualifier or
SPNameQualifier XML attributes MUST be populated in accordance with SPNameQualifier XML attributes MUST be populated in accordance with
the definition of the format prior to serialization. In other words, the definition of the format prior to serialization. In other words,
the defaulting rules specified for the "persistent" and "transient" the defaulting rules specified for the "persistent" and "transient"
formats MUST be applied prior to serialization. formats MUST be applied prior to serialization.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
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.
8. IANA Considerations 8. IANA Considerations
First, a new registry needs to be created for GSS URNs. Then, this A new top-level registry is created titled "Generic Security Service
needs to be registered in the IETF's URN registry. Then this Application Program Interface Parameters". There doesn't seem to be
registry needs to be populated with URN items from this spec. an existing top-level registry that can be used. There are
Parameters for the Kerberos V mechanism; parameters for the GSS-API
EAP mechanism; and GSS-API/SASL/Kerberos service names. However none
of these are the right place.
In this top-level registry, a sub-registry titled "GSS-API URN
Parameters" is created. Registration in this registry is by the IETF
review or expert review procedures [RFC5226]. Registrations in this
registry are generally only expected as part of protocols published
as RFCs on the IETF stream; other URIs are expected to be better
choices for non-IETf work. Expert review is permitted mainly to
permit early registration related to specifications under development
when the community believes they have reach sufficient maturity.
If the "paramname" parameter is registered in this registry then its
URN will be "urn:ietf:gss:paramname". The initial registrations are
as follows:
+--------------------------+-------------+
| Parameter | Reference |
+--------------------------+-------------+
| radius-attribute | Section 5 |
| | |
| federated-saml-assertion | Section 6.1 |
| | |
| federated-saml-attribute | Section 6.2 |
| | |
| federated-saml-nameid | Section 6.3 |
+--------------------------+-------------+
8.1. Registration of the GSS URN Namespace
IANA is requested to register the "gss" URN sub-namespace in the IETF
URN sub-namespace for protocol parameters defined in [RFC3553].
Registry Name: gss
Specification: draft-ietf-abfab-gss-eap-naming
Repository: GSS-API URN Parameters (Section 8)
Index Value: Sub-parameters MUST be specified in UTF-8 using standard
URI encoding where necessary.
9. Acknowledgements 9. Acknowledgements
Scott Cantor contributed significant text and multiple reviews of Scott Cantor contributed significant text and multiple reviews of
this document. this document.
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-05 (work in progress), draft-ietf-abfab-gss-eap-08 (work in progress), June 2012.
March 2012.
[I-D.ietf-kitten-gssapi-naming-exts] [I-D.ietf-kitten-gssapi-naming-exts]
Williams, N., Johansson, L., Hartman, S., and S. Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "GSS-API Naming Extensions", Josefsson, "GSS-API Naming Extensions",
draft-ietf-kitten-gssapi-naming-exts-13 (work in draft-ietf-kitten-gssapi-naming-exts-15 (work in
progress), March 2012. progress), May 2012.
[I-D.ietf-radext-radius-extensions] [I-D.ietf-radext-radius-extensions]
DeKok, A. and A. Lior, "Remote Authentication Dial In User DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", Service (RADIUS) Protocol Extensions",
draft-ietf-radext-radius-extensions-04 (work in progress), draft-ietf-radext-radius-extensions-06 (work in progress),
January 2012. June 2012.
[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.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-kitten-sasl-saml-ec] [I-D.ietf-kitten-sasl-saml-ec]
Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL
and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-01 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-01
(work in progress), February 2012. (work in progress), February 2012.
Authors' Addresses Authors' Addresses
Sam Hartman Sam Hartman
 End of changes. 19 change blocks. 
34 lines changed or deleted 95 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/