Network Working Group                                         S. Hartman
Internet-Draft                                         Painless Security
Intended status: Standards Track                              J. Howlett
Expires: April 16, 2011 23, 2012                                        JANET(UK)
                                                        October 13, 2010 21, 2011

             Name Attributes for the GSS-API EAP mechanism
                   draft-ietf-abfab-gss-eap-naming-00
                   draft-ietf-abfab-gss-eap-naming-01

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 in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 16, 2011. 23, 2012.

Copyright Notice

   Copyright (c) 2010 2011 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 Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Naming Extensions and SAML . . . . . . . . . . . . . . . . . .  5
   4.  RADIUS and Authenticated Attributes  Federated Context  . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Name Attributes for GSS-EAP  . . . . . . . . . . . . . . . . .  7
   6.  Names of SAML Attributes in the Federated Context  . . . . . .  8
     5.1.
     6.1.  Assertions . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.
     6.2.  SAML Attributes  . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  RADIUS Attributes  .
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  Security  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations . . 10
   9.  References . . . . . . . . . . . . . . . . . . . 10
   8. . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

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]
   [I-D.ietf-abfab-gss-eap] 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.  Other mechanisms such as SAML EC
   [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 that information. SAML
   assertions in the federated context and AAA attributes.

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].

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  GSS-API name
   attributes may take a form starting with a URI describing 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
   the name; the rest of SAML.  So, the GSS-API
   attribute name should be something is specified by that an administrator can
   reasonably easily construct from a URI.

   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 attributes carried in GSS-API naming extensions to
   support concepts such as SAML names where the format is specified
   separately. are named with three parts.
   The format of GSS-API attribute names should be changed.
   If no space character first is found in the name, then a URN indicating that the name is
   interpreted as a URI SAML attribute and
   describing the attribute.  Otherwise, the
   portion from the beginning of the buffer to the first space context (Section 4).  This URI is
   interpreted as followed by a URI describing space,
   the form and interpretation of URI indicating the
   rest format of the buffer; this portion is known as SAML name, a space and the SAML
   attribute type URI.

4.  RADIUS and Authenticated Attributes

   GSS-API naming extensions have name.  The URI indicating the concept format of an authenticated name
   attribute.  The mechanism guarantees that the SAML attribute
   name is not optional and MUST be present.

   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
   issuer.  However for other name formats, including unspecified name
   formats, make it easy for two issuers to choose the same name for
   attributes with different semantics.  Attributes using the federated
   context Section 4 are issued by the same party performing the
   authentication.  So, based on who is named by the name, the semantics
   of the attribute can be determined.

4.  Federated Context

   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.  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,
   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  This
   specification defines attribute containing the initiator's e-mail address names for SAML and AA attributes in a
   the federated context needs to context.

   These names MUST not be different from used for attributes issued by a party other
   than one closely associated with the name containing source of credentials unless the
   initiator's e-mail address in a different context.  The determination
   source of trust from this context information can never be exact: Kerberos
   typically credentials is used in environments where re-asserting the KDC is fairly trusted,
   but an application could have a key in attributes.  For example, a realm that
   source of credentials can consult whatever sources of attributes it does not fully
   trust.  Similarly, SAML is typically
   chooses, but acceptors can assume attributes in a the federated context, but an
   organization could use SAML for internal authentication as well.

   It would be convenient to use context
   are from the same GSS-API attribute names source of credentials.

5.  Name Attributes for GSS-EAP

   This section describes how RADIUS attributes received with the same information regardless GSS-
   EAP mechanism are named.

   The first portion of context.  However, when
   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 TBD1 (a URN indicating that attributes from two different mechanisms will
   have different names.

   However, the local implementation of the mechanism this is
   a GSS-EAP RADIUS AVP).  This is followed by a space and layers in the
   GSS-API implementation above the mechanism can make the job a numeric
   RADIUS name as described by section 2.6 of
   [I-D.ietf-radext-radius-extensions].  For example the
   application easier.  If local policy permits an attribute to be
   trusted, then name of the
   User-Name attribute can be copied to a is "TBD 1".  The 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 of extended type 1 within
   type 241 would be "TBD 241.1".

   The value both of a SAML mechanism and Kerberos mechanism's
   e-mail address RADIUS attributes after local policy is applied.  Such
   mechanism-level attributes can also be used to normalize the format
   of attribute values.

   In the case raw octets of GSS-EAP, the attribute names need to packet.
   Integers are in network byte order.  The display value SHOULD be specific to a
   human readable string; an implementation can only produce this string
   if it knows the type of a given RADIUS attribute.

6.  Names of SAML attributes obtained via AAA transport.

5.  Name Attributes for GSS-EAP

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

5.1. Federated Context

6.1.  Assertions

   Implementations of GSS-EAP MUST support an attribute with

   An assertion generated by the name credential source is named by
   "urn:ietf:params:gss-eap:saml-aaa-assertion".  The value of this
   attribute is the assertion carried in the AAA protocol. protocol or used for
   authentication in a SAML mechanism.  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 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.

6.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

7.  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 the peer credential. two purposes.  The
   implementation MUST validate the authenticity of these results before least
   sensitive is personalization: a central service MAY provide
   information about an authenticated user so they are processed.

5.3.  RADIUS Attributes need not enter it
   with each acceptor they access.  A more sensitive use is
   authorization.

   The mechanism needs to be created to give applications access to AAA
   AVPs carried along with an access-accept message.

6.  Security Considerations

   This needs 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 be written.

7. assert the attribute and validating the asserted value.

8.  IANA Considerations

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

8.

9.  References

9.1.  Normative References

   [I-D.howlett-eap-gss]

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

   [I-D.ietf-kitten-gssapi-naming-exts]
              Williams, N. and L. N., Johansson, L., Hartman, S., and S.
              Josefsson, "GSS-API Naming Extensions", draft-ietf-kitten-gssapi-naming-exts-08
              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 2010. 2011.

   [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.

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

   Sam Hartman
   Painless Security

   Email: hartmans-ietf@mit.edu

   Josh Howlett
   JANET(UK)

   Email: josh.howlett@ja.net