Internet DRAFT - draft-wei-abfab-differentiation-authn
draft-wei-abfab-differentiation-authn
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 <RequestedAuthnContext> 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
<samlp:AuthnContextClassesRef> element of <RequestedAuthnContext>
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 <PrincipalAuthenticationMechanismType>,
"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 <samlp:AuthnContextClassesRef> 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 <samlp:AuthnRequest> to Identity Provider. In
step 2, the Relying Party should set the
<saml:AuthnContextClassesRef> 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 <samlp:Response> 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.
<xs:schema
targetNamespace="urn:oasis:names:tc:SAML:2.0:ac:classes:SpecificLO
A"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:oasis:names:tc:SAML:2.0:ac:classes:SpecificLOA"
finalDefault="extension"
blockDefault="substitution"
version="2.0">
<xs:redefine
schemaLocation="saml-schema-authn-context-types-2.0.xsd">
<xs:annotation>
<xs:documentation>
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.
</xs:documentation>
</xs:annotation>
<xs:complexType name="AuthnContextDeclarationBaseType">
<xs:complexContent>
<xs:restriction base="AuthnContextDeclarationBaseType">
<xs:sequence>
<xs:element ref="Identification" minOccurs="0" />
<xs:element ref="TechnicalProtection" minOccurs="0" />
<xs:element ref="OperationalProtection" minOccurs="0" />
<xs:element ref="AuthnMethod" />
<xs:element ref="GoverningAgreement" minOccurs="0" />
<xs:element ref="Extension" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:ID" use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
Wei Expires December 12, 2014 [Page 8]
Internet-Draft Differentiation authentication June 2014
<xs:complexType name="AuthnMethodBaseType">
<xs:complexContent>
<xs:restriction base="AuthnMethodBaseType">
<xs:sequence>
<xs:element ref="PrincipalAuthenticationMechanism" />
<xs:element ref="Authenticator" minOccurs="0"/>
<xs:element ref="AuthenticatorTransportProtocol"
minOccurs="0"/>
<xs:element ref="Extension" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="PrincipalAuthenticationMechanismType">
<xs:complexContent>
<xs:restriction base="PrincipalAuthenticationMechanismType">
<xs:attribute name="requiredLOA" type="xs:integer"
use="required" />
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
</xs:schema>
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]
