draft-ietf-abfab-gss-eap-naming-03.txt   draft-ietf-abfab-gss-eap-naming-04.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: January 12, 2013 JANET(UK) Expires: February 15, 2013 JANET(UK)
July 11, 2012 August 14, 2012
Name Attributes for the GSS-API EAP mechanism Name Attributes for the GSS-API EAP mechanism
draft-ietf-abfab-gss-eap-naming-03 draft-ietf-abfab-gss-eap-naming-04
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 January 12, 2013. This Internet-Draft will expire on February 15, 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 29 skipping to change at page 2, line 29
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 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 . . . . . . . . . . . . . . . . . . . . . . . . 15
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 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 The semantics of setting attributes defined in this specification are
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 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
the name of an attribute has two parts. The first is a URI [OASIS.saml-core-2.0-os], the name of an attribute has two parts.
describing the format of the name. The second part, whose form The first is a URI describing the format of the name. The second
depends on the format URI, is the actual name. GSS-API name part, whose form depends on the format URI, is the actual name. GSS-
attributes may take a form starting with a URI describing the form of API name attributes may take a form starting with a URI describing
the name; the rest of the name is specified by that URI. 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 URN indicating that the name is a SAML attribute and
describing the context (Section 4). This URI is followed by a space, describing the context (Section 4). This URN is followed by a space,
the URI indicating the format of the SAML name, a space and the SAML the URI indicating the format of the SAML name, a space and the SAML
attribute name. The URI indicating the format of the SAML attribute attribute name. The URI indicating the format of the SAML attribute
name is not optional and MUST be present. 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
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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 in an access- This section describes how RADIUS attributes received in an access-
accept message by the GSS-EAP mechanism are named. 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
RADIUS messages or prior to the access-accept message is undefined at
this time. Future specifations can explore these areas giving
adequate weight to backward compatibility.
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:gss:radius-attribute 1". The the User-Name attribute is "urn:ietf:gss:radius-attribute 1". The
name of extended type 1 within type 241 would be name of extended type 1 within type 241 would be
"urn:ietf:gss:radius-attribute 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.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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. This attribute is always assertion fails local policy checks. This attribute is always
authentic when present: authentication only succeeds if the AAA authenticated when present in mechanism names for mechanisms
exchange is successfully authenticated. However, users of the GSS- complying with this specification: authentication only succeeds if
API MUST confirm that the attribute is authenticated because some the SAML or AAA exchange is successfully authenticated. However,
mechanisms MAY permit an initiator to assert an unauthenticated users of the GSS-API MUST confirm that the attribute is authenticated
version of this attribute. because some other mechanisms MAY permit an initiator to assert an
unauthenticated 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: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. final part is the <saml:Attribute> element's Name XML attribute.
skipping to change at page 9, line 10 skipping to change at page 9, line 11
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 [SAMLCORE], missing values of the NameQualifier or section 8.3 of [OASIS.saml-core-2.0-os], missing values of the
SPNameQualifier XML attributes MUST be populated in accordance with NameQualifier or SPNameQualifier XML attributes MUST be populated in
the definition of the format prior to serialization. In other words, accordance with the definition of the format prior to serialization.
the defaulting rules specified for the "persistent" and "transient" In other words, the defaulting rules specified for the "persistent"
formats MUST be applied prior to serialization. and "transient" 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
skipping to change at page 11, line 5 skipping to change at page 10, 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
assertions, attributes and name identifiers exposed through name
attributes defined in this document. If there is another way to get
access to the SAML assertion, for example the mechanism described in
[I-D.ietf-abfab-aaa-saml], then an application MAY get different
results depending on how the SAML is accessed. This is intended
behavior; applications who choose to bypass local policy checks
SHOULD perform their own evaluation before relying on information.
8. IANA Considerations 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". There doesn't seem to be Application Program Interface Parameters". There doesn't seem to be
an existing top-level registry that can be used. There are an existing top-level registry that can be used. There are
Parameters for the Kerberos V mechanism; parameters for the GSS-API Parameters for the Kerberos V mechanism; parameters for the GSS-API
EAP mechanism; and GSS-API/SASL/Kerberos service names. However none EAP mechanism; and GSS-API/SASL/Kerberos service names. However none
of these are the right place. of these are the right place.
In this top-level registry, a sub-registry titled "GSS-API URN In this top-level registry, a sub-registry titled "GSS-API URN
skipping to change at page 13, line 12 skipping to change at page 13, line 12
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-08 (work in progress), June 2012. draft-ietf-abfab-gss-eap-09 (work in progress),
August 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-15 (work in draft-ietf-kitten-gssapi-naming-exts-15 (work in
progress), May 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-06 (work in progress), draft-ietf-radext-radius-extensions-06 (work in progress),
June 2012. June 2012.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [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 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003. Parameters", BCP 73, RFC 3553, June 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-abfab-aaa-saml]
Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding
and Profiles for SAML", draft-ietf-abfab-aaa-saml-03 (work
in progress), March 2012.
[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-02
(work in progress), February 2012. (work in progress), August 2012.
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. 15 change blocks. 
28 lines changed or deleted 54 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/