ABFAB Juan Wei Internet Draft Shenzhen University Intended status: Informational Jianyong Chen Expires: March 22, 2014 Shenzhen University Jun Zhang Sun Yat-Sen University September 22, 2013 Application Bridging for Federated Access Beyond Web draft-wei-abfab-usecases-00.txt 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 March 22, 2014. Copyright Notice Copyright (c) 2013 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 Wei Expires March 22, 2014 [Page 1] Internet-Draft ABFAB Use Cases September 2013 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. Abstract Identity Management System plays an important role in Cloud Computing. A good Identity Management System should meet the diverse security requirements from both service providers and users, improve usability for users and protect the resources from unauthorized access. The goal of the document is to document the improvement of Identity Management System to provide users a friendly experience through the use of technologies based on the ABFAB architecture and specifications. Table of Contents 1. Introduction ................................................ 2 2. Context of Use Cases......................................... 3 3. Use Cases ................................................... 3 3.1. Level of Assurance for Authentication .................. 4 3.2. Level of Assurance for Attribute ....................... 4 4. Contributors ................................................ 5 5. Security Considerations ..................................... 5 6. IANA Considerations ......................................... 5 7. References .................................................. 6 7.1. Normative References ................................... 6 7.2. Informative References ................................. 6 8. Acknowledgments ............................................. 6 1. Introduction Generally speaking, the higher the level of assurance for authentication is, the safer the communication between principals. However, it will compromise the usability and feasibility. Therefore to differentiate the assurance for authentication can obtain a balance between usability and strength of authentication. In addition, different identity providers may use different authentication protocols, so it can promote service providers to recognize identity providers to use different authentication protocols by classify the security strength of authentication protocols. In cloud computing, there are all kinds of services which need different authentication mechanisms. So identity management system with differentiated levels of assurance for authentication is extremely reasonable and strong needed in cloud environment. Wei Expires March 22, 2014 [Page 2] Internet-Draft ABFAB Use Cases September 2013 In federated identity management, identity attributes may be distributed in different attribute servers that trustworthiness of attributes is different and furthermore the service provider needs attributes to grant users. However the service provider's desired attributes vary based on business requirements. So classifying the level of assurance for attributes is beneficial to improve the security of service distribution. Furthermore the identity provider, attribute service provider and service provider are typically independent parties, it is necessary to standardize the levels of assurance for both authentication and attributes to achieve interoperation. This document enumerates some of these uses cases, describing how technologies based on the ABFAB architecture [I-D.ietf-abfab-arch] and specifications could be used. 2. Context of Use Cases The use cases described in this document are a result of work led by Jianyong Chen, the professor of Shenzhen University and research the security of network, responding to requirements from its community, and augmented by various inputs from the IETF community. The ABFAB architecture and specifications enables authentication and authorization to occur across organizational boundaries. For many applications, principals need not have pre-instantiated accounts that their federated identity maps to before their first visit to that application; the application can perform this process on the fly. In cases where such accounts are required for particular applications, the pre-provisioning process is out of scope of ABFAB technologies, which assumes any such requirements have already been fulfilled. Standards-based work of note that would assist with this pre-provisioning of accounts includes the standards and specifications produced by the IETF SCIM working group. 3. Use Cases This section describes some of the variety of potential use cases where technologies based on the ABFAB architecture and specifications could help improve the user experience; each includes a brief description of how current technologies attempt to solve the use cases and how this could be improved upon by ABFAB implementations. Wei Expires March 22, 2014 [Page 3] Internet-Draft ABFAB Use Cases September 2013 3.1. Level of Assurance for Authentication Level of assurance for authentication describes the security strength of authentication. It represents the security strength of the way to authenticate, such as single-factor authentication or multi-factor authentication, in-person identity proofing or online identity proofing and so on. With differentiated level of assurance for authentication, services can provide users diverse authentication services without compromising the usability. For instance, when a user connects to a target service via public free Wi-Fi, in response to higher security threats, it needs to sacrifice the usability and use higher level assurance for authentication such as Two-factor authentication mechanism. However, if using the cellular network, it can use lower level of assurance for authentication such as password authentication mechanism so that can improve the user experience. At present, it already has some protocols to support multiple authentication mechanisms. For instance, in the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) [RFC2478], the initiator propose one security mechanism or an ordered list of security mechanisms, the target then make a decision depend on the proposed security mechanism (list) by negotiating with the initiator. Though these mechanism protocols can satisfy the requirement, the scalability is not good. The use of ABFAB technologies in this case via the EAP framework would enable identity providers provide many flexible authentication mechanism including the simple and the complex, which would meet the service providers' diverse requirements and it also has a scalability to support more authentication mechanisms. 3.2. Level of Assurance for Attribute Attribute service is a fine-grained service in identity management. Identity attributes are used to assist service providers to make fine-grained authorization. But as in the real world, the identity attribute information may be not true and fabricated. When granting access protected resources, some services may do not make a mandatory requirement on the trustworthiness of information. For example, when an authenticated person want to buy a bottle of wine in online store, the store need to certify the attribute value of age exceed 18. But if he wants to play game online, he may not be required to be an adult. So a classified level of assurance for attributes can enable service providers to authorize appropriate protected resources to users. when the level of assurance for Wei Expires March 22, 2014 [Page 4] Internet-Draft ABFAB Use Cases September 2013 attributes could not match the required from the service providers, the service providers can give a Denial of Service to the users so that it can prevent unauthorized or illegal accesses to the protected important resources. At present, there are many application protocols support identity attributes exchange between SPs and attribute servers or IdPs. They provide SPs with all the required attribute information to make authorization decision such as SAML [OASIS.saml-profiles-2.0-os] which support arbitrary set of attributes transportation within SAML assertions. Federated identity management via ABFAB technologies would enhance the user experience of accessing different protected resources hosted in servers as well as protect resources from unauthorized access. The Authentication, Authorization and Accounting framework of ABFAB architecture provides transport for attributes. The AAA framework already has an extensible architecture allowing for new attributes to be defined and transported. With the AAA framework in this case context, we can define the levels of assurance for users' identity attributes, and transport them to the service provider then the SP can determine whether the users can get authorization of resources or not according to them. 4. Contributors The following individuals made important contributions to the text of this document: Juan Wei (Shenzhen University), Jianyong Chen (Shenzhen University) and Jun Zhang (Sun Yat-Sen University). 5. Security Considerations This document contains only use cases and defines no protocol operations for ABFAB. Security considerations for the ABFAB architecture are documented in the ABFAB architecture specification, and security considerations for ABFAB technologies and protocols that are discussed in these use cases are documented in the corresponding protocol specifications. 6. IANA Considerations This document does not require actions by IANA. Wei Expires March 22, 2014 [Page 5] Internet-Draft ABFAB Use Cases September 2013 7. References 7.1. Normative References [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., Tschofening, H., Lear, E. and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", draft-ietf-abfab-arch-07 (work in progress), July 2013. 7.2. Informative References [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC2478, December 1998. [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R. and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V.20", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005. 8. Acknowledgments These use-cases have been developed and documented using significant input from Juan Wei (Shenzhen University), Jianyong Chen (Shenzhen University) and Jun Zhang (Sun Yat-Sen University). This document was prepared using 2-Word-v2.0.template.dot. Wei Expires March 22, 2014 [Page 6] Internet-Draft ABFAB Use Cases September 2013 Authors' Addresses Wei Juan 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 Advance Computing China Phone: +86 13570277588 Email: junzhang@ieee.org Wei Expires March 22, 2014 [Page 7]