ABFAB Juan Wei Internet Draft Shenzhen University Intended status: Informational Jianyong Chen Expires: December 12, 2014 Shenzhen University Jun Zhang Sun Yat-Sen University June 10, 2014 Differentiation authentication for ABFAB draft-wei-abfab-differentiation-authn-01.txt Abstract This document describes how to implement the differentiation authentication with Level of Assurance (LOA). In order to achieve the goal, we define a new authentication context class schema for SAML V2.0 which is used to specify the LOA requirement of Relying Provider (RP), a function which is used by Identity Provider (IdP) to transform the required LOA to specific authentication method(s), and a profile which describes the application of this new authentication context. 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), 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 December 10, 2014. Wei Expires December 10, 2014 [Page 1] Internet-Draft Differentiation authentication June 2014 Copyright Notice Copyright (c) 2014 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. A new authentication context with LOA ....................... 3 3. Transform function .......................................... 3 4. Differentiation authentication profile ...................... 4 4.1. Profile overview ....................................... 4 5. Security Considerations ..................................... 6 6. IANA Considerations ......................................... 6 7. Acknowledgements ............................................ 6 8. References .................................................. 7 8.1. Normative References ................................... 7 8.2. Informative References ................................. 7 Appendix A. XML Schema ......................................... 8 1. Introduction This document describes how to realize the differentiation authentication with Level of Assurance (LOA) [b-ITU-T X.1254]. In order to achieve the goal, we define a new authentication context class schema for SAML V2.0 which is used to specify the LOA requirement of Relying Provider (RP), and a function which is used by Identity Provider (IdP) to transform the required LOA to specific authentication method(s) and a profile which describes the application of this new authentication context. In the federation identity management, the Relying Party (RP) typically delegates the authentication service to a third party, Identity Provider (IdP). The RP itself is mainly responsible for the authorization service based on the authentication result from the IdP. Authentication methods which an IdP uses to identify users, are Wei Expires December 12, 2014 [Page 2] Internet-Draft Differentiation authentication June 2014 either specified by the RP or decided by the IdP. In the former way, the RP can specify authentication methods by some attributes. For example, in SAML, the RP can impose the method by setting the value of element in [OASIS-saml-core-2.0-os]. But this way requires the RP to know the detail authentication methods that IdP supports. The latter way can be realized by a null value of the element in SAML. In this way, the IdP does not take the security requirements of a particular service into consideration when it negotiates authentication methods with client users. In this document, we define: o A new authentication context class that is used to provide a new SAML authentication context to identify users. o A function which is used to transmit the LOA requirement to authentication methods. o A profile that uses the LOA for authentication to affect SAML- based authentication and authorization. 2. A new authentication context with LOA The authentication context classes defined in [OASIS-saml-authn- context-2.0-os] are initial authentication context classes for using with SAML. The SAML requester can use the element of element to specify an authentication context class with a specific authentication mechanism, such as Kerberos, Public Key-X.509 etc. The IdP can choose its own authentication methods when the SP does not provide one. In the new authentication context with LOA, we define a new authentication context class "urn:oasis:names:tc:SAML:2.0:ac:classes:SpecificLOA" [Appendix A.] with a new attribute for , "requiredLOA", which represents the security requirement from RP. The new context can make the SP express its security requirement as well as need not know what authentication mechanisms the IdP supports. 3. Transform function This section specifies a transform function, S=f(LOA,E,H),used by the IdP to pass the LOA to actual authentication method(s). The function has three parameters, one is S which represents the security strength of the authentication algorithm; one is E which expresses security threat from access network that user terminal Wei Expires December 12, 2014 [Page 3] Internet-Draft Differentiation authentication June 2014 connect to; another is H which represents the threat history of the user recorded in IdP. The parameter S describes the security strength that authentication algorithms can guarantee. For example, the simple password authentication mechanism typically provides a lower security level than that the certificate-based SSL provides. The parameter LOA represents the security expectation of RP, and the higher the value is, the more secure the RP's security requirement is. For instance, the 4-LOA is safer than 1-LOA. The E parameter describes the security threat of network environment. When a user accesses network resource in public places such as airport or coffeehouse, the network security threat is serious. While when he or she is in a private or protected place, such as a campus or an enterprise context, the security threat mitigates evidently. The H parameter indicates the history records of being attacked to a user. Such as the number of attacks, the geographical location of each attack etc. With these records from IdP, the IdP can provides a customized authentication service. 4. Differentiation authentication profile In the scenario supported by the differentiation authentication, a Principal controlling a User Agent requests access to a Relying Party. The Relying Party uses SAML to request Principal's Identity Provider to authenticate the Principal. In the authentication request, the RP sends the LOA for authentication to IdP by the "requiredLOA" attribute in element. If the Identity Provider successfully authenticates the Principal, it produces an authentication assertion which is consumed by the Relying Party. 4.1. Profile overview This profile is based on the ABFAB Authentication Profile [I-D.ietf- abfab-aaa-saml]. There are some important differences, specifically: Authentication: This profile does not require the use of any particular authentication method. The ABFAB architecture does require the use of EAP [RFC3579], but this specification indicates the LOA for authentication in order to provide a more targeted certification service. And it may be used in non-ABFAB scenarios. Wei Expires December 12, 2014 [Page 4] Internet-Draft Differentiation authentication June 2014 Requests: The profile requires the use of the new authentication context class in order to pass the LOA requirement of RP to IdP, and at the same time it does not require any particular authentication method. Figure 1 below describes the flow of messages within this profile. User Agent Relying Party Identity Provider + + + | (1) | | |+-------------->| | | | | | | (2) | | |+------------------->| | | | | (3) | | |<------------------------------------>| | | | | | (4) | | |<-------------------+| | (5) | | |<--------------+| | | | | | | | | | | v v v Figure 1 The following steps are described by the profile. Within an individual step, there may be one or more actual message exchanges. 1. User Agent Request to Relying Party: In step 1, the Principal, via User Agent, makes a Request for a service at the Relying Party. The Relying Party determines that no authentication context for the User Agent exists and initiates authentication of the Principal. 2. Relying Party issues to Identity Provider. In step 2, the Relying Party should set the element to be the new authentication context class, in which "requiredLOA" attribute is the LOA. 3. Identity Provider identifies Principal. In step 3, the Identity Provider obtains the LOA requirement from the "requiredLOA" ,which is defined in the new authentication context class and imposed by Wei Expires December 12, 2014 [Page 5] Internet-Draft Differentiation authentication June 2014 Relying Party, and computes the security strength with the transform function (Section 3), which will take the location environment and history records into consideration so that it can provide a customized authentication services. Then the IdP negotiates authentication methods with the Principal according to the resulted strength, and at last authenticates the Principal with the selected method if negotiation is successful, or returns an error when negotiation fails. 4. Identity Provider issues to Relying Party. In step 4, the response either includes an authentication statement in exact one assertion or indicates an error. 5. Relying Party grants or denies access from Principal. In step 5, once having received the response from the Identity Provider, the Relying Party can establish its own security context for the principal and return the requested resource, or response to the Principal's user agent with its own error. 5. Security Considerations The document is based on SAML specification document, so it has the security considerations of SAML protocols. Another security consideration is that in the mechanism proposed in this document, the LOA requirement is based on XML syntax, and the selection of final authentication method is based on it. So when the parameter is faked, the overall security will be compromised. Therefore it suggests that much more attention should be taken to the LOA transmitted between RP and IdP. 6. IANA Considerations The XML schema of authentication context class defined in this document will be processed as described in [OASIS-saml-authn- context-2.0-os], subjected to the additional requirements of a published specification. And the detailed definition is in Appendix A. 7. Acknowledgements Need to acknowledge Jianyong Chen and Jun Zhang. Wei Expires December 12, 2014 [Page 6] Internet-Draft Differentiation authentication June 2014 8. References 8.1. Normative References [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. [OASIS-saml-authn-context-2.0-os] Kemp, J., Cantor, S., Mishra, P., Philpott, R., and E. Maler, "Authentication Context for Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-authn- context-2.0-os, March 2005. [I-D.ietf-abfab-aaa-saml] Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", draft-ietf-abfab-aaa-saml-09 (work in progress), February 2014. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication (EAP)", RFC 3579, September 2003. 8.2. Informative References [b-ITU-T X.1254] Recommendation ITU-T X.1254(2012), Entity authentication assurance framework. Wei Expires December 12, 2014 [Page 7] Internet-Draft Differentiation authentication June 2014 Appendix A. XML Schema The following schema formally defines the "urn:oasis:names:tc:SAML:2.0:ac:classes:SpecificLOA" namespace. While XML validation is optional, the schema that follows is the normative definition of the constructs it defines. Class identifier: urn:oasis:names:tc:SAML:2.0:ac:classes:SpecificLOA Document identifier: saml-schema-authn-context- specificloa-2.0 Location: http://docs.oasis-open.org/security/saml/v2.0/ Revision history: V2.0 (March, 2005): New core authentication context schema for SAML V2.0. Wei Expires December 12, 2014 [Page 8] Internet-Draft Differentiation authentication June 2014 Wei Expires December 12, 2014 [Page 9] Internet-Draft Differentiation authentication June 2014 Authors' Addresses Juan Wei Shenzhen University Dept. of Computer Science and Technology China Phone: +86 13751039454 Email: juanwei2012@gmail.com Prof. Jianyong Chen Shenzhen University Dept. of Computer Science and Technology China Phone: +86 13823278100 Email: jychen@szu.edu.cn Prof. Jun Zhang Sun Yat-Sen University College of Advanced Computing China Phone: +86 13570277588 Email: junzhang@ieee.org Wei Expires December 12, 2014 [Page 10]