[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-abfab-gss-eap-naming

Network Working Group                                         S. Hartman
Internet-Draft                                         Painless Security
Intended status: Standards Track                              J. Howlett
Expires: January 6, 2011                                       JANET(UK)
                                                            July 5, 2010


             Name Attributes for the GSS-API EAP mechanism
                    draft-hartman-gss-eap-naming-00

Abstract

   The naming extensions to the Generic Security Services Application
   Programming interface provide a mechanism for applications to
   discover authorization and personalization information associated
   with GSS-API names.  The Extensible Authentication Protocol GSS-API
   mechanism allows an Authentication/Authorization/Accounting peer to
   provide authorization attributes along side an authentication
   response.  It also provides mechanisms to process Security Assertion
   Markup Language (SAML) messages provided in the AAA response.  This
   document describes the necessary information to use the naming
   extensions API to access that information.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 6, 2011.

Copyright Notice




Hartman & Howlett        Expires January 6, 2011                [Page 1]


Internet-Draft           GSS EAP Name Attributes               July 2010


   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Naming Extensions and SAML . . . . . . . . . . . . . . . . . .  5
   4.  RADIUS and Authenticated Attributes  . . . . . . . . . . . . .  6
   5.  Name Attributes for GSS-EAP  . . . . . . . . . . . . . . . . .  8
     5.1.  Assertions . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  SAML Attributes  . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  RADIUS Attributes  . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12























Hartman & Howlett        Expires January 6, 2011                [Page 2]


Internet-Draft           GSS EAP Name Attributes               July 2010


1.  Introduction

   The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the
   Generic Security Services Application Programming interface (GSS-API)
   [RFC2743] provide a mechanism for applications to discover
   authorization and personalization information associated with GSS-API
   names.  The Extensible Authentication Protocol GSS-API mechanism
   [I-D.howlett-eap-gss] allows an Authentication/Authorization/
   Accounting peer to provide authorization attributes along side an
   authentication response.  It also provides mechanisms to process
   Security Assertion Markup Language (SAML) messages provided in the
   AAA response.  This document describes the necessary information to
   use the naming extensions API to access that information.






































Hartman & Howlett        Expires January 6, 2011                [Page 3]


Internet-Draft           GSS EAP Name Attributes               July 2010


2.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Hartman & Howlett        Expires January 6, 2011                [Page 4]


Internet-Draft           GSS EAP Name Attributes               July 2010


3.  Naming Extensions and SAML

   SAML assertions can carry attributes describing properties of the
   subject of the assertion.  For example, an assertion might carry an
   attribute describing the organizational affiliation or e-mail address
   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
   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-
   API name attributes take the form of a single URI.

   Administrators may need to type SAML attribute names into
   configuration files or otherwise tell applications how to find
   attributes.  It is desirable to support accessing these attributes
   from applications that have no awareness of SAML.  So, the GSS-API
   attribute name should be something that an administrator can
   reasonably easily construct from a SAML attribute name.  In
   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
   support concepts such as SAML names where the format is specified
   separately.  The format of GSS-API attribute names should be changed.
   If no space character is found in the name, then the name is
   interpreted as a URI describing the attribute.  Otherwise, the
   portion from the beginning of the buffer to the first space is
   interpreted as a URI describing the form and interpretation of the
   rest of the buffer; this portion is known as the attribute type URI.























Hartman & Howlett        Expires January 6, 2011                [Page 5]


Internet-Draft           GSS EAP Name Attributes               July 2010


4.  RADIUS and Authenticated Attributes

   GSS-API naming extensions have the concept of an authenticated name
   attribute.  The mechanism guarantees that the contents of an
   authenticated name attribute are an authenticated statement from the
   trusted source of the peer credential.  The fact that an attribute is
   authenticated does not imply that the trusted source of the peer
   credential is authorized to assert the attribute.

   In the federated context, the trusted source of the peer credential
   is typically some identity provider.  In the GSS EAP mechanism,
   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,
   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 same federation.  The IDP is trusted to make some statements,
   particularly related to the context of a federation.  For example, an
   academic federation's participants would typically trust an IDP's
   assertions about whether someone was a student or a professor.
   However that same IDP would not typically be trusted to make
   assertions about local entitlements such as group membership.  Thus,
   a service MUST make a policy decision about whether the IDP is
   permitted to assert a particular attribute and about whether the
   asserted value is acceptable.

   In contrast, attributes in an enterprise context are often verified
   by a central authentication infrastructure that is trusted to assert
   most or all attributes.  For example, in a Kerberos infrastructure,
   the KDC typically indicates group membership information for clients
   to a server using KDC-authenticated authorization data.

   The context of an attribute is an important property of that
   attribute; trust context is an important part of the context.
   Applications will often want to treat an attribute in a federated
   context the same as an attribute in an enterprise context.  In order
   for applications to distinguish the context of attributes, attributes
   with different context need different names.  For example, the name
   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
   the same information regardless of context.  However, when



Hartman & Howlett        Expires January 6, 2011                [Page 6]


Internet-Draft           GSS EAP Name Attributes               July 2010


   considering attribute names it is critical to consider the
   appropriate interpretation of that name and the distinctions an
   application will need to make about the name.  As a result, it is
   often the case that attributes from two different mechanisms will
   have different names.

   However, the local implementation of the mechanism and layers in the
   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
   SAML attributes obtained via AAA transport.
































Hartman & Howlett        Expires January 6, 2011                [Page 7]


Internet-Draft           GSS EAP Name Attributes               July 2010


5.  Name Attributes for GSS-EAP

   This section describes how SAML assertions, SAML attributes and
   RADIUS attributes received with the GSS-EAP mechanism are named.

5.1.  Assertions

   Implementations of GSS-EAP MUST support an attribute with the name
   "urn:ietf:params:gss-eap:saml-aaa-assertion".  The value of this
   attribute is the assertion carried in the AAA protocol.  This
   attribute is absent from a given acceptor name if no such assertion
   is present or if the assertion fails local policy checks.  This
   attribute is always authentic when present: authentication only
   succeeds if the AAA exchange is successfully authenticated.  However,
   users of the GSS-API MUST confirm that the attribute is authenticated
   because some mechanisms MAY permit an initiator to assert an
   unauthenticated version of this attribute.

5.2.  SAML Attributes

   Each attribute carried in the assertion SHOULD also be a GSS name
   attribute.  The name of this attribute has three parts, all separated
   by an ASCII space character.  The first part is
   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
   SAML attribute.  If the mechanism performs an additional 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
   in SAML assertions that have been successfully validated back to the
   trusted source of the peer credential.  In the GSS-EAP mechanism, a
   SAML assertion carried in an integrity-protected and authenticated
   AAA protocol SHALL be sufficiently validated.  An implementation MAY
   apply local policy checks to this assertion and discard it if it is
   unacceptable according to these checks.

   Attribute query results made based on this assertion also count as
   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.





Hartman & Howlett        Expires January 6, 2011                [Page 8]


Internet-Draft           GSS EAP Name Attributes               July 2010


6.  Security Considerations

   This needs to be written.
















































Hartman & Howlett        Expires January 6, 2011                [Page 9]


Internet-Draft           GSS EAP Name Attributes               July 2010


7.  IANA Considerations

   This section needs to include URN registrations within the IETF
   namespace for URNs that are used.















































Hartman & Howlett        Expires January 6, 2011               [Page 10]


Internet-Draft           GSS EAP Name Attributes               July 2010


8.  Normative References

   [I-D.howlett-eap-gss]
              Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
              Extensible Authentication Protocol",
              draft-howlett-eap-gss-00 (work in progress), March 2010.

   [I-D.ietf-kitten-gssapi-naming-exts]
              Williams, N. and L. Johansson, "GSS-API Naming
              Extensions", draft-ietf-kitten-gssapi-naming-exts-08 (work
              in progress), June 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.


































Hartman & Howlett        Expires January 6, 2011               [Page 11]


Internet-Draft           GSS EAP Name Attributes               July 2010


Authors' Addresses

   Sam Hartman
   Painless Security

   Email: hartmans-ietf@mit.edu


   Josh Howlett
   JANET(UK)

   Email: josh.howlett@ja.net







































Hartman & Howlett        Expires January 6, 2011               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/