[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
ABFAB                                                    A. Perez-Mendez
Internet-Draft                                            R. Marin-Lopez
Intended status: Informational                           G. Lopez-Millan
Expires: April 7, 2016                              University of Murcia
                                                         October 5, 2015


      Retrieving remote attributes using GSS-API naming extensions
                  draft-perez-abfab-gss-remote-attr-00

Abstract

   The GSS-API Naming Extensions define new APIs that extend the GSS-API
   naming model to support name attribute transfer between GSS-API
   peers.  Historically, this set of functions has been used to obtain
   the authorization information contained in some sort of authorization
   token provided to the GSS acceptor during the context establishment
   process, such as a Kerberos ticket, a SAML assertion, or an X.509
   attribute certificate.  However, some scenarios require to allow the
   GSS acceptor to request additional attributes after context
   establishment.  If these attributes are not locally stored by the GSS
   mechanism they have to be retrieved from an external source (e.g.
   SQL database, LDAP directory, external IdP, etc.).  This document
   describes how current GSS-API extensions are able to encompass such
   functionality without requiring of any change, neither on the
   existing calls nor on the way applications use the API.

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 7, 2016.








Perez-Mendez, et al.      Expires April 7, 2016                 [Page 1]


Internet-Draft            GSS remote attributes             October 2015


Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  General operation . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Example using draft-ietf-abfab-aaa-saml, GSS-EAP and RFC7056    5
   6.  Considerations on blocking calls  . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Generic Security Service Application Programming Interface (GSS-
   API) Naming Extensions [RFC6680] define new APIs that extend the GSS-
   API naming model to support name attribute transfer between GSS-API
   peers.  Historically, this set of functions has been used to obtain
   the authorization information contained in some sort of authorization
   token provided to the GSS acceptor during the context establishment
   process, such as a Kerberos ticket, a SAML assertion, or an X.509
   attribute certificate.  Therefore, after context establishment, the
   GSS mechanism could provide any of the available name attributes to
   the application (GSS acceptor) without requiring any further
   interaction with any external entity.

   However, some scenarios require to allow the GSS acceptor to request
   additional attributes after context establishment.  In those cases,
   it is possible that these attributes are not locally stored by the
   GSS mechanism and, therefore, they have to be retrieved from an



Perez-Mendez, et al.      Expires April 7, 2016                 [Page 2]


Internet-Draft            GSS remote attributes             October 2015


   external source (e.g.  SQL database, LDAP directory, external IdP,
   etc.).  This document describes how current GSS-API extensions are
   able to encompass such functionality without requiring of any change,
   neither on the existing calls nor on the way applications use the
   API.

2.  Conventions

   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 RFC 2119 [RFC2119].

3.  Motivation

   This document is motivated by the work being done in the IETF ABFAB
   WG.  In particular, the ABFAB architecture [I-D.ietf-abfab-arch]
   defines a way by which a federated end user can authenticate with a
   particular application by using a new GSS-API mechanism called GSS-
   EAP [RFC7055].  This mechanism conveys EAP packets between the end
   user (acting as EAP peer and GSS initiator), the application (acting
   as EAP authenticator and GSS acceptor), and the RADIUS server (acting
   as EAP server).  Moreover, the ABFAB architecture also defines how a
   SAML assertion containing information about the end user is delivered
   to the GSS acceptor after the successful authentication of the end
   user.  This latter process is described in the ABFAB Authentication
   Profile of [I-D.ietf-abfab-aaa-saml].

   To this point, the GSS-EAP mechanism can make the information
   contained in the SAML assertion available to the application, by
   using the standard GSS-API Naming Extensions calls [RFC7056].  That
   is, the GSS_Inquire_Name() call returns the list of attributes
   available in the SAML assertion, whereas the GSS_Get_Name_Attribute()
   one returns the value of each specific attribute.

   However, [I-D.ietf-abfab-aaa-saml] also defines the ABFAB Assertion
   Query/Request Profile.  Using it, the GSS acceptor can send
   additional SAML Attribute Queries to the IDP after the end user has
   been authenticated, in order to obtain attributes that were not
   obtained before (i.e. not listed by GSS_Inquire_Name()).  It was not
   clear for the ABFAB WG whether this behaviour was possible using
   current GSS-API calls, so this document intends to shed some light on
   the subject.

4.  General operation

   Despite its typical usage, the GSS-API naming extensions document
   [RFC6680] takes no assumption on how a particular GSS mechanism
   obtains the attributes associated to a name.  Indeed, as any other



Perez-Mendez, et al.      Expires April 7, 2016                 [Page 3]


Internet-Draft            GSS remote attributes             October 2015


   API, the GSS-API works as a "black box", where only inputs and
   outputs are specified.  Hence, it is irrelevant whether the GSS
   mechanism has the attributes locally stored, or it has to retrieve
   this information from an external source.  Moreover, [RFC6680] does
   not forbid the usage of the GSS_Get_Name_Attribute() call to request
   the value of an attribute that is not listed in the output of the
   GSS_Inquire_Name() call.

   Taking the previous considerations into account, the following steps
   describe a proposal by which any GSS-API mechanism implementation can
   retrieve remote attributes and provide them to the application in a
   transparent way:

   1.  The application gets the list of attribute names by invoking
       GSS_Inquire_Name().

   2.  The application is interested on a particular attribute (called
       "ATTR") that is not included in the results from step 1.

   3.  The application requests the value of attribute "ATTR" by
       invoking GSS_Get_Name_Attribute().

   4.  The GSS mechanism processes the request and realizes the
       attribute is not available into its local storage.  Instead of
       generating an GSS_S_UNAVAILABLE error, the mechanism checks its
       configuration to see whether it can retrieve the attribute from
       an external source (e.g.  SQL database, LDAP directory, SAML
       IDP...).  There are two possible outcomes for this process:

       a.  If the attribute is successfully retrieved from the remote
           source, the GSS mechanism adds it to the local storage so it
           will be listed by future invocations of GSS_Inquire_Name().
           This process is similar as if the GSS_Set_Name_Attribute()
           would have been called with the retrieved attribute data.
           Finally, the attribute value is provided to the application
           as if the attribute would have been located into the local
           storage.  Note that the application is unaware of this whole
           process.

       b.  If the attribute cannot be retrieved, the GSS mechanism
           returns the GSS_S_UNAVAILABLE error major code.  The minor
           code might provide additional information (e.g. connection
           refused, timeout, invalid SAML attribute format...) if
           desired.

   5.  The application makes use of the obtained attribute, or take the
       associated countermeasures if the attribute was not provided.




Perez-Mendez, et al.      Expires April 7, 2016                 [Page 4]


Internet-Draft            GSS remote attributes             October 2015


5.  Example using draft-ietf-abfab-aaa-saml, GSS-EAP and RFC7056

   The following example follows the steps described in the previous
   section, with actual examples using draft-ietf-abfab-aaa-saml, GSS-
   EAP and [RFC7056].

   1.  The application gets the list of attribute names by invoking
       GSS_Inquire_Name().  The list returns the following attribute
       names:

       *  urn:ietf:params:gss:radius-attribute 79 (RADIUS EAP-Message)

       *  urn:ietf:params:gss:radius-attribute 80 (RADIUS Message-
          Authenticator attribute)

       *  urn:ietf:params:gss:radius-attribute 1 (RADIUS User-Name
          attribute)

       *  urn:ietf:params:gss:radius-attribute 24 (RADIUS State
          attribute)

       *  urn:ietf:params:gss:federated-saml-assertion (Complete SAML
          assertion)

       *  urn:ietf:params:gss:federated-saml-attribute
          urn:oasis:names:tc:SAML:2.0:attrname-format:uri
          urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonAffiliation
          attribute)

       These attribute names follow the format described in [RFC7056].

   2.  The application is interested on getting the value of a standard
       federated SAML attribute called eduPersonAffiliation.  The format
       of the attribute name following [RFC7056] is
       "urn:ietf:params:gss:federated-saml-attribute
       urn:oasis:names:tc:SAML:2.0:attrname-format:uri
       urn:oid:1.3.6.1.4.1.5923.1.1.1.1".

   3.  The application requests the value of the attribute by invoking
       GSS_Get_Name_Attribute().

   4.  The GSS-EAP mechanism implementation processes the request, and
       realizes the attribute is not available into its local storage.
       Then, it generates a new SAML Attribute Query for that attribute,
       sending it to the IdP using the ABFAB Assertion Query/Request
       Profile described in section 8 of [I-D.ietf-abfab-aaa-saml].  As
       a result, it obtains a SAML Response with a SAML Attribute
       Statement for the requested attribute.  Finally, the GSS-EAP



Perez-Mendez, et al.      Expires April 7, 2016                 [Page 5]


Internet-Draft            GSS remote attributes             October 2015


       mechanism implementation stores the attribute into its local
       storage, and provides the output of the GSS_Get_Name_Attribute()
       call with the value of the attribute.

   5.  The application uses the attribute to perform authorization
       tasks.

   6.  If the application invokes GSS_Inquire_Name() again, the result
       would contain the following attribute names:

       *  urn:ietf:params:gss:radius-attribute 79 (RADIUS EAP-Message)

       *  urn:ietf:params:gss:radius-attribute 80 (RADIUS Message-
          Authenticator attribute)

       *  urn:ietf:params:gss:radius-attribute 1 (RADIUS User-Name
          attribute)

       *  urn:ietf:params:gss:radius-attribute 24 (RADIUS State
          attribute)

       *  urn:ietf:params:gss:federated-saml-assertion (Complete SAML
          assertion)

       *  urn:ietf:params:gss:federated-saml-attribute
          urn:oasis:names:tc:SAML:2.0:attrname-format:uri
          urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonAffiliation
          attribute)

       *  urn:ietf:params:gss:federated-saml-attribute
          urn:oasis:names:tc:SAML:2.0:attrname-format:uri
          urn:oid:1.3.6.1.4.1.5923.1.1.1.1 (SAML eduPersonEntitlement
          attribute)

6.  Considerations on blocking calls

   The fact of performing network interactions within the implementation
   of an API call may lead to blocking situations, where the GSS
   mechanism needs to wait for a third entity to provide a result.  This
   behaviour is allowed by current specification [RFC6680], although it
   may not be foreseen by some applications that (wrongly) assume GSS-
   API calls will return immediately.

   After a discussion on the Kitten WG mailing list [KITTENDIS], it was
   concluded that it would be reasonable for an application to assume
   that the calls to GSS_Inquire_Name() and to GSS_Get_Name_Attribute()
   for attributes listed by the former will be faster (i.e. non-




Perez-Mendez, et al.      Expires April 7, 2016                 [Page 6]


Internet-Draft            GSS remote attributes             October 2015


   blocking) than the calls to GSS_Get_Name_Attribute() for non-listed
   attributes (i.e. require network interaction).

   Furthermore, it would be desirable that new definitions of GSS naming
   attributes explicitly declare whether a network interaction is
   possible to be triggered, so applications are aware that the results
   may take some time to be returned.

   Finally, this document recommends GSS mechanism to implement timers
   to prevent a call to GSS_Get_Name_Attribute() keeps blocked if the
   external entity does not reply in a reasonable amount of time.  If
   the timer expires, GSS_Get_Name_Attribute() returns with the
   GSS_S_UNAVAILABLE code, as if the attribute was not available at all.
   The returned minor code might provide some information about the
   actual cause of the error (i.e. timeout).

7.  IANA Considerations

   There are no IANA Considerations.

8.  Acknowledgements

   Authors thank JISC for their support.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6680]  Williams, N., Johansson, L., Hartman, S., and S.
              Josefsson, "Generic Security Service Application
              Programming Interface (GSS-API) Naming Extensions",
              RFC 6680, DOI 10.17487/RFC6680, August 2012,
              <http://www.rfc-editor.org/info/rfc6680>.

9.2.  Informative References

   [RFC7055]  Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for
              the Extensible Authentication Protocol", RFC 7055,
              DOI 10.17487/RFC7055, December 2013,
              <http://www.rfc-editor.org/info/rfc7055>.






Perez-Mendez, et al.      Expires April 7, 2016                 [Page 7]


Internet-Draft            GSS remote attributes             October 2015


   [RFC7056]  Hartman, S. and J. Howlett, "Name Attributes for the GSS-
              API Extensible Authentication Protocol (EAP) Mechanism",
              RFC 7056, DOI 10.17487/RFC7056, December 2013,
              <http://www.rfc-editor.org/info/rfc7056>.

   [KITTENDIS]
              Perez-Mendez, A., "Use of GSS_Get_name_attribute() to
              obtain further attributes. https://www.ietf.org/mail-
              archive/web/kitten/current/msg05550.html", April 2015.

   [I-D.ietf-abfab-arch]
              Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
              Schaad, "Application Bridging for Federated Access Beyond
              Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work
              in progress), July 2014.

   [I-D.ietf-abfab-aaa-saml]
              Howlett, J., Hartman, S., and A. Perez-Mendez, "A RADIUS
              Attribute, Binding, Profiles, Name Identifier Format, and
              Confirmation Methods for SAML", draft-ietf-abfab-aaa-
              saml-11 (work in progress), August 2015.

Authors' Addresses

   Alejandro Perez-Mendez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 46 44
   EMail: alex@um.es


   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 01
   EMail: rafa@um.es









Perez-Mendez, et al.      Expires April 7, 2016                 [Page 8]


Internet-Draft            GSS remote attributes             October 2015


   Gabriel Lopez-Millan
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 04
   EMail: gabilm@um.es











































Perez-Mendez, et al.      Expires April 7, 2016                 [Page 9]