Internet DRAFT - draft-wei-abfab-usecases


ABFAB                                                        Juan Wei
Internet Draft                                     Shenzhen University
Intended status: Informational                           Jianyong Chen
Expires: March 30, 2014                            Shenzhen University
                                                            Jun Zhang
                                                Sun Yat-Sen University
                                                      October 10, 2013

 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 10, 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
   ( 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 30, 2014                 [Page 1]
Internet-Draft             ABFAB Use Cases                October 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.


   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 two kinds of level
   of assurance, one for authentication and the other for attribute, to
   provide users with 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 ......................................... 6
   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 [b-ITU-T
   X.1254] for authentication is, the safer the communication between
   principals is. However, higher LOA 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 strongly needed in cloud

Wei                    Expires March 30, 2014                 [Page 2]
Internet-Draft             ABFAB Use Cases                October 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, so it is
   necessary to standardize the levels of assurance for both
   authentication and attributes to achieve interoperation.

   This document enumerates two use 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

Wei                    Expires March 30, 2014                 [Page 3]
Internet-Draft             ABFAB Use Cases                October 2013

3.1. Level of Assurance for Authentication

   Level of Assurance for authentication describes the security
   strength of authentication. It represents the security strength
   required by target service, which may be guaranteed by many
   authentication methods.

   With differentiated level of assurance for authentication, services
   can provide users diverse services without compromising the
   usability. For instance, when a user accesses a target service from
   a public place such as airport, in order to satisfy the required LOA
   by target service, authentication server needs to use safer
   authentication methods. This way may sacrifice the usability to some
   extent, but it can guarantee the security of accessing the target
   service, especially the services that is related to privacy. However
   when accessing the target service from within a secure organization,
   it can use weaker authentication methods since the environment is
   safe enough to allow weaker authentication methods to be used to
   meet the required LOA for authentication by target service, at the
   same time to improve the user experience. In conclusion, the LOA for
   authentication can meet diverse security requirements of service
   providers and make a tradeoff between security strength and user

   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

Wei                    Expires March 30, 2014                 [Page 4]
Internet-Draft             ABFAB Use Cases                October 2013

   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
   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. But they do not classify the trust of attributes which
   can give a hand to service providers to provide safer services and
   improve the user experience at the same time.

   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.

Wei                    Expires March 30, 2014                 [Page 5]
Internet-Draft             ABFAB Use Cases                October 2013

6. IANA Considerations

   This document does not require actions by IANA.

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

   [b-ITU-T X.1254] Recommendation ITU-T X.1254(2012), Entity
                    authentication assurance framework.

   [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

Wei                    Expires March 30, 2014                 [Page 6]
Internet-Draft             ABFAB Use Cases                October 2013

Authors' Addresses

   Wei Juan
   Shenzhen University
   Dept. of Computer Science and Technology

   Phone: +86 13751039454

   Prof. Jianyong Chen
   Shenzhen University
   Dept. of Computer Science and Technology

   Phone: +86 13823278100

   Prof. Jun Zhang
   Sun Yat-Sen University
   College of Advance Computing

   Phone: +86 13570277588

Wei                    Expires March 30, 2014                 [Page 7]