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