Internet DRAFT - draft-wei-abfab-usecases
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
draft-wei-abfab-usecases-01.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 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
(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 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.
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 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
environment.
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
implementations.
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
usability.
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 2-Word-v2.0.template.dot.
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
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 30, 2014 [Page 7]
