Internet DRAFT - draft-perez-abfab-wg-arch-erp
draft-perez-abfab-wg-arch-erp
ABFAB A. Perez-Mendez
Internet-Draft R. Marin-Lopez
Updates: RFC7055 (if approved) G. Lopez-Millan
Intended status: Experimental University of Murcia
Expires: April 30, 2015 F. Pereniguez-Garcia
Catholic University of Murcia
October 27, 2014
ERP extensions for the ABFAB architecture
draft-perez-abfab-wg-arch-erp-00
Abstract
The Application Bridging for Federated Access Beyond Web (ABFAB)
architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform
access control to a wide range of applications. This document
describes the extensions required to incorporate support for the EAP
Extensions for the EAP Re-authentication Protocol (ERP) to this
architecture, in order to provide an enhanced fast re-authentication
and Single Sign-On (SSO) support and a better resource utilization.
Authorization aspects are also described.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 30, 2015.
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
Perez-Mendez, et al. Expires April 30, 2015 [Page 1]
Internet-Draft GSS-ERP October 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Applicability considerations . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivation use case . . . . . . . . . . . . . . . . . . . . . 6
5. Modifications to the ABFAB architecture . . . . . . . . . . . 7
5.1. ERP extensions to GSS-EAP . . . . . . . . . . . . . . . . 7
5.1.1. GSS-EAP initial state . . . . . . . . . . . . . . . . 7
5.1.1.1. ERP-Supported Subtoken . . . . . . . . . . . . . . 8
5.1.2. GSS-EAP authentication state . . . . . . . . . . . . . 9
5.1.3. GSS-EAP extensions state . . . . . . . . . . . . . . . 9
5.2. Authorization Considerations . . . . . . . . . . . . . . . 9
5.3. Updates to the backend (AAA) infrastructure . . . . . . . 10
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. ERP implicit bootstrapping . . . . . . . . . . . . . . . . 11
6.2. ERP explicit bootstrapping . . . . . . . . . . . . . . . . 12
6.3. ERP local operation . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Perez-Mendez, et al. Expires April 30, 2015 [Page 2]
Internet-Draft GSS-ERP October 2014
1. Introduction
The Application Bridging for Federated Access Beyond Web (ABFAB)
architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform
access control to a wide range of applications. This is mainly
achieved by the definition of the GSS-API Mechanism for the
Extensible Authentication Protocol [RFC7055], which can be used with
any application that provides support for the GSS-API or the SASL
framework (through the GS2 family of mechanisms). Since EAP is
mostly used in conjunction with a backend Authentication,
Authorization, and Accounting (AAA) infrastructure, the use of this
mechanism automatically brings federated authentication capabilities
to these applications. Besides, the ABFAB architecture also defines
how attributes about the Client can be transported from the home
organization to the application in order to perform an authorization
process based on this federated identity information. Hence,
altogether the ABFAB architecture provides a consistent federated
access control framework usable in multiple scenarios, as described
in [I-D.ietf-abfab-usecases].
However, neither EAP nor the GSS-EAP mechanism provide any particular
means of performing fast re-authentication. This implies that,
whenever a Client accesses to different applications, regardless they
are deployed in the same organization or in different ones, a
complete EAP authentication process must be performed for each one of
them. Depending on the selected EAP method (e.g. EAP-TTLS, PEAP,
etc.), this exchange may consist of several roundtrips executed
between the Client and her Home organization, with the inherent costs
in terms of network bandwidth consumption and computational resources
used (e.g. to perform asymmetric cryptography operations).
Therefore, in order to provide a better resource utilization,
Clients, organizations, and applications using EAP have to rely on
the fast re-authentication capabilities provided by the selected EAP
method, when possible. There are a number of EAP methods that
already provide some fast re-authentication capabilities (e.g. EAP-
AKA, EAP-TTLS...). However, although they can achieve a reduction of
the required round-trips to complete the authentication process, they
all require the execution of at least two round-trips in the best
case. Besides, these exchanges are always performed between the
Client and the Home AAA server.
The EAP Extensions for the EAP Re-authentication Protocol (ERP)
[RFC6696] modifies certain aspects of the EAP protocol to 1) allow
the execution of a re-authentication process in a single round trip;
and 2) allow performing the re-authentication process in a local
fashion whenever the Client repeatedly accesses to different
applications within the same organization. In particular, ERP allows
Perez-Mendez, et al. Expires April 30, 2015 [Page 3]
Internet-Draft GSS-ERP October 2014
the Client and an AAA server (either in the home or in the visited
organization) to mutually verify proof of possession of key material
from an earlier EAP method run. Although ERP, as EAP, was originally
conceived to be used only in the network access context, the ABFAB WG
extended the EAP applicability statement [RFC7057] to allow its use
for generic application authentication. This fact also enables ERP
to be used to provide fast re-authentication for generic
applications.
The extensions defined by ERP consist of a pair of new EAP codes, and
some updates to the EAP state machines required to generate and
process these codes accordingly. Therefore, adding support for ERP
implies updating the EAP lower layer specifications. This document
describes the modifications to the ABFAB architecture that are
required to incorporate support for the EAP Extensions for the EAP
Re-authentication Protocol (ERP).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
When these words appear in lower case, they have their natural
language meaning.
2. Applicability considerations
Although EAP, and thus ERP, was originally conceived to be used only
in the network access context, the ABFAB WG extended the EAP
applicability statement [RFC7057] to allow its use for generic
application authentication. This fact also enables ERP to be used to
provide fast re-authentication for generic applications when used in
combination with the GSS-EAP mechanism.
3. Terminology
Although this document is not intended to serve as an ERP or ABFAB
guide, this section provides some terminology notes to help the
reader to follow the rest of this document.
o Client. The entity which wants to access a particular service by
means of ABFAB technologies. It plays the role of GSS-API
initiator and EAP/ERP peer.
o RP (Relying party). The application server the Client is trying
to access to. It plays the role of GSS-API acceptor and EAP/ERP
Perez-Mendez, et al. Expires April 30, 2015 [Page 4]
Internet-Draft GSS-ERP October 2014
authenticator.
o Visited organization. The organization where the RP is deployed.
o Home organization. The organization where the Client has a
registration.
o Visited AAA server. The AAA server that connects the Visited
organization to the AAA federation. It plays the role of AAA
proxy and of ERP server for the ERP local operation (see below).
o Home AAA server. The AAA server that connects the Home
organization to the AAA federation. It plays the role of EAP
server and of ERP server for the bootstrapping processes (see
below).
o ERP keys. The keys used to perform authentication in ERP. They
are named rIK/rRK when shared with the Home AAA server, and DS-
rIK/DS-rRK when shared with the Visited AAA server. They are
derived during the bootstrapping processes (see below). Besides,
an rMSK is derived from them to play the role of a typical MSK,
being installed in the RP.
o ERP Bootstrapping. When the Client tries to use ERP with a
particular RP, but she does not share any ERP key with the Visited
organization, a bootstrapping process is required to derive and
install such keys.
* Implicit bootstrapping. It is performed when the Client does
not share any ERP key with the Home AAA server either. The
Client authenticates with the Home AAA server by means of an
EAP method. ERP keys for the Home and Visited organizations
are derived from the cryptographic material generated by this
method, and installed in the Home AAA server and Visited AAA
server respectively.
* Explicit bootstrapping. It is performed when the Client shares
ERP keys with the Home AAA server from a previous implicit
bootstrapping process. The authentication consists on a single
round-trip ERP exchange where both entities prove their
knowledge of these keys. New ERP keys for the Visited
organization are derived and installed in the Visited AAA
server.
o ERP local operation. When the Client tries to use ERP with a
particular RP and she shares ERP keys with the Visited
organization, the ERP authentication is performed locally by the
Visited AAA server in a single round-trip exchange.
Perez-Mendez, et al. Expires April 30, 2015 [Page 5]
Internet-Draft GSS-ERP October 2014
4. Motivation use case
As an example use case let us picture the following situation. Alice
(Client) has a subscription with an organization (Home organization).
This means that Alice has some long-term credentials that allow her
to authenticate with this organization. Let us assume there are also
other organizations, called Organization A and Organization B
(Visited organizations), which have a set of services deployed (RPs).
These three organizations are interconnected through an AAA
federation, and the services they offer support the use of the ABFAB
technologies for access control.
What Alice and the organizations would want is to allow her to access
to any of the services deployed by the different organizations
without requiring her to perform a complete EAP authentication for
each one of them. Instead, only one complete EAP authentication
would be required, at the beginning of the session. The rest of
authentication processes would be based on the cryptographic material
derived from it, regardless whether the organization of the RP being
accessed is different from the one where the first EAP authentication
process was performed. Moreover, whenever possible, the
authentication process should be performed without involving the home
institution.
In this way, Alice avoids being prompted to introduce her long-term
credentials once and again, and goes through the process as fast as
possible to start enjoying the service. On the other hand,
organizations are able to reduce the amount of network traffic
exchanged between them, as well as the computational cost of
performing this process. This should improve scalability and reduce
infrastructure costs.
In this scenario, using the standard mechanism defined within the
IETF to provide fast re-authentication in EAP (i.e. ERP) seems to be
the most reasonable way to proceed. This solution would be valid not
only for any application making use of the ABFAB architecture or the
GSS-EAP mechanism.
This use case is directly applicable within the context of the CLASSe
project [CLASSe], which focuses on allowing GEANT users to access to
cloud services using their home institution credentials. Although
this objective is mainly achieved by the use of ABFAB technologies,
the project is also interested in ways to improve the SSO
capabilities of the ABFAB architecture, in such a way that a Client
moving among a number of different cloud services deployed within the
same federation do not require performing more than one complete EAP
authentication process.
Perez-Mendez, et al. Expires April 30, 2015 [Page 6]
Internet-Draft GSS-ERP October 2014
5. Modifications to the ABFAB architecture
The integration of ERP with the ABFAB architecture requires of some
changes to the GSS-EAP mechanism, some modifications to the
authorization handling, and some updates to the back-end (AAA)
infrastructure. The following subsections describe them with further
detail. Section 6 provides a detailed flow based description of the
overall ABFAB/ERP process.
5.1. ERP extensions to GSS-EAP
ERP follows a different exchange scheme than EAP. Whereas a typical
EAP exchange is a server-initiated flow, ERP may follow a client-
initiated one. Therefore, supporting ERP would require changes on
how these lower layers deal with re-transmissions. However, the GSS-
API (and thus the GSS-EAP mechanism) operation also follows a client-
initiated scheme. This aspect favors the integration of ERP into its
message flow, minimizing the number of adaptations required to
incorporate the ERP functionality. Specifically, this allows an
easier negotiation of ERP capabilities and parameters between the
GSS-EAP initiator (Client) and the GSS-EAP acceptor (RP), and a
simpler handling of error conditions (e.g. re-transmissions).
Following subsections describe how the different states of the GSS-
EAP mechanism must be adapted to enable ERP functionality.
5.1.1. GSS-EAP initial state
As defined in [RFC7055], the Initial State is used to start the
context establishment process. In particular, it is used to exchange
information such as vendor information or acceptor (RP) name. This
document defines a new Subtoken, called ERP-Supported Subtoken, that
is exchanged in this state, and it is used to negotiate ERP-related
parameters. It MUST be included by any compliant Client willing to
start an ERP exchange. The presence of this Subtoken indicates that
the Client supports this specification, and the kind of ERP exchange
to be performed. Section 5.1.1.1 provides further details on this
Subtoken.
When the Client sends an ERP-Supported Subtoken indicating that an
implicit bootstrapping is requested, a compliant RP MUST include an
ERP-Supported Subtoken in the response, indicating that it supports
ERP and the realm name to be used to derive the ERP keys. As the
Subtoken is not marked as critical, non-compliant RPs will ignore
such Subtokens and continue as indicated in [RFC7055].
On the contrary, when an explicit bootstrapping or an ERP local
operation is requested, the RP MUST start the ERP exchange by
Perez-Mendez, et al. Expires April 30, 2015 [Page 7]
Internet-Draft GSS-ERP October 2014
including an EAP-Initiate/Re-auth-Start packet within the first EAP
Request Subtoken. This packet is sent instead of the EAP request/
identity one. The reception of this ERP packet will notify the
Client that the RP supports the ERP extensions, and provide the realm
name to be used to derive the ERP keys.
Although ERP allows the Client to send an EAP-Initiate/Re-auth packet
without having received any EAP-Initiate/Re-auth-Start packet first,
this behavior is not allowed in this specification for two main
reasons. First, the Client might not know the ERP realm of the
application yet, as it could not be inferred from the DNS name or
GSS-API Acceptor Name. Indeed, the RP (acceptor) name is being
negotiated during this state. Hence, the Client must wait until an
EAP-Initiate/Re-auth-start message, or an ERP Supported Subtoken, is
received from the RP, as explained above. Besides, during the GSS-
EAP initial state, neither the Client nor the RP are expected to
perform any authentication processing. That belongs to the
authentication state (see below). Allowing authentication in this
state will require deeper changes to the GSS-EAP state machine,
resulting on a more complex specification.
5.1.1.1. ERP-Supported Subtoken
The ERP-Supported Subtoken is sent from the Client to the RP,
indicating that the former wishes to start an ERP exchange with the
latter, and specifying whether it will be an implicit bootstrapping
or not. Besides, it can be sent from the RP to the Client whenever
an implicit bootstrapping has been requested by the Client, in order
to 1) indicate that ERP is supported; and 2) to provide the Client
with the ERP realm name required to derive they ERP keys at the end
of the EAP authentication process.
The ERP-Supported Subtoken has the structure depicted in Figure 1
+-------------+------------------------------------------------+
| Pos | Description |
+-------------+------------------------------------------------+
| 0..3 | TBD (not critical) |
| | |
| 4..7 | length of token |
| | |
| 8 | implicit bootstrapping? (0x00=no, 0x01=yes) |
| | |
| 9..8+length | Visited organization's realm (sent by RP only) |
+-------------+------------------------------------------------+
Figure 1: ERP-Supported Subtoken
Perez-Mendez, et al. Expires April 30, 2015 [Page 8]
Internet-Draft GSS-ERP October 2014
5.1.2. GSS-EAP authentication state
As defined in [RFC7055], this state is used to perform the exchange
of EAP packets between the Client and the RP. When performing an ERP
implicit bootstrapping, a compliant Client MUST derive and store the
ERP keys associated with its Home organization for later use (i.e rRK
and rIK). Besides, it MUST derive and store the ERP keys associated
to the Visited organization whenever the latter indicates support of
ERP (i.e. DS-rRK and DS-rIK). Both derivation processes are
performed after having completed a successful EAP authentication.
Besides, during an implicit bootstrapping, a compliant RP SHOULD
notify the Visited AAA server whenever an ERP implicit bootstrapping
process has been requested. This notification can be performed by
including an AAA attribute, such as the ERP-Realm one defined in
[RFC6942], to the first request sent to the Home AAA server. This
would trigger the Visited AAA server to request a DSRK from the Home
AAA server. Without this notification, an ERP-capable Visited AAA
server would need to send a DSRK request for every EAP
authentication, regardless the Client supports ERP or not. This
would result into the generation of an amount of useless state in the
Visited and Home AAA servers when the Client does not support ERP.
When performing other types of ERP exchanges (i.e. explicit
bootstrapping or local operation), this specification adds an
additional way to end the EAP conversation to the ones listed in
[RFC7055]. In particular, when an ERP exchange is successfully
executed, the conversation will end with the generation (and
reception) of an EAP-Finish/Re-auth message. The behavior at GSS-EAP
layer associated to this message is identical to the one associated
with the EAP Success message. It also includes the derivation of the
ERP keys associated with the Visited organization, and the rMSK
derived from them by the Client. Note that the rMSK is used as the
MSK for all purposes, including the derivation of the GSS-API Master
Session Key (GMSK) defined in [RFC7055].
5.1.3. GSS-EAP extensions state
This state requires no modifications, and it can be performed as
described in [RFC7055].
5.2. Authorization Considerations
Another important aspect has to do with how authorization should be
handled in ABFAB when ERP is in use. The ABFAB architecture defines
that the Home AAA server generates a SAML assertion with information
about the Client, and delivers it to the RP, after the EAP
authentication has been successfully completed
Perez-Mendez, et al. Expires April 30, 2015 [Page 9]
Internet-Draft GSS-ERP October 2014
[I-D.ietf-abfab-aaa-saml]. Whenever an ERP bootstrapping process
(either implicit or explicit) is performed, no changes are required
to this behavior. That is, when the Home AAA server generates the
EAP-Finish/Re-auth message, it also generates and delivers the SAML
in the same way it would do with an EAP-Success message.
However, there is an important consideration when it comes to the ERP
local operation. Since the Home AAA server is not involved in the
process, in principle, an SAML assertion is not generated as
specified in GSS-EAP. To overcome this limitation, and to take
advantage of the ERP local operation, the Visited AAA server SHOULD
store the SAML assertion received during any of the bootstrapping
processes (either implicit or explicit) executed previously,
associated to the Client's identifiers (e.g. User-Name, CUI...). In
this way, the stored SAML assertion can be delivered to the RP during
the ERP local operation.
5.3. Updates to the backend (AAA) infrastructure
Another architecture element that needs to be updated, in order to
add support for ERP to the ABFAB architecture, is the backend AAA
infrastructure. Basically, the Home AAA server and the Visited AAA
server need to implement ERP as described in [RFC6696]. In
particular, the Home AAA server needs to be updated to support the
different ERP bootstrapping exchanges. This includes the generation
and parsing of ERP messages, as well as the derivation, storage,
distribution and usage of the ERP-related keys (i.e. rIK, rRK, DS-
rIK, rMSK...).
In the same way, the Visited AAA server needs to be updated in order
to be able to request the required ERP key material (i.e. DSRK) from
the Home AAA server during any of the ERP bootstrapping exchanges.
This key material needs to be stored for its use during the ERP local
operation (see below). Besides, the Visited AAA server MAY need to
support the storage of the SAML assertion as described in
Section 5.2.
Finally, the Visited AAA server also needs to be updated to support
the execution of the ERP local operation with the Client, based on
the key material obtained during any of the bootstrapping exchanges
performed before.
When the Visited AAA server does not provide support for ERP, the
Client will only be able to perform bootstrapping processes.
Although this is not optimal, a typical explicit bootstrapping
process will require a single round-trip performed between the Client
and its Home AAA server. The main drawback of not having ERP-capable
AAA proxies is the impossibility of executing the ERP local
Perez-Mendez, et al. Expires April 30, 2015 [Page 10]
Internet-Draft GSS-ERP October 2014
operation, which implies communicating with the home AAA server to
perform the authentication.
6. Operation
Previous section has explained the extensions that are required to
GSS-EAP for supporting ERP. This section provides a detailed
description of how the different ERP exchanges would be executed. In
these descriptions it is assumed that all the participants support
the ERP extensions described in this document.
6.1. ERP implicit bootstrapping
TBD This ERP exchange is performed when the Client wants to use ERP
with a particular RP, but she does not have neither a DS-rRK/DS-rIK
shared with the Visited AAA server nor a rRK/rIK shared with her Home
AAA server. The process is depicted in Figure 2 and described below.
+-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| Client | | RP | | Visited AAA | | Home AAA |
+-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|------ 1 ----->| | |
| | | |
|<----- 2 ------| | |
| | | |
|------ 3 ----->| | |
| |------ 4 ----->| |
| | |------ 5 ----->|
| | | |
|<---------------------- 6 -------------------->|
| | | |
| | | (7)
| | | |
| | |<----- 8 ------|
| | | |
| | (9) |
| | | |
| |<----- 10 -----| |
| | | |
|<----- 11 -----| | |
| | | |
(12) | | |
| | | |
Figure 2: ERP implicit bootstrapping
Perez-Mendez, et al. Expires April 30, 2015 [Page 11]
Internet-Draft GSS-ERP October 2014
1. The Client starts the GSS-EAP mechanism, also including an ERP
Supported Subtoken indicating an implicit bootstrapping is
required.
2. The RP continues with the standard GSS-EAP mechanism, also
including an ERP Supported Subtoken indicating implicit
bootstrapping and the Visited organization's realm.
3. The Client sends the EAP-Response/Identity message.
4. The RP forwards this EAP message to the Visited AAA server, also
including an indication (e.g. ERP-Realm attribute) that an
implicit bootstrapping was requested.
5. The Visited AAA server forwards the EAP message to the Home AAA
server, also including a request for a DSRK key (used to derive
the ERP keys).
6. The Client and the Home AAA run the EAP protocol.
7. The Home AAA server derives the MSK and SAML assertion(as
usual). It also generates the rRK and rIK, and the requested
DSRK.
8. The Home AAA server sends the EAP-Success, MSK, SAML assertion
and DSRK to the Visited AAA server.
9. The Visited AAA server derives the DS-rRK and DS-rIK from the
DSRK, and stores the SAML assertion.
10. The Visited AAA server sends the EAP-Success, the SAML assertion
and the MSK to the RP.
11. The RP sends the EAP-Success to the Client and finalizes the
GSS-EAP mechanism.
12. The Client derives the MSK, rRK, rIK, DS-rRK, and DS-rIK.
6.2. ERP explicit bootstrapping
TBD
6.3. ERP local operation
This ERP exchange is performed when the Client wants to use ERP with
a particular RP, having DS-rRK/DS-rIK shared with the Visited AAA
server. The process is depicted in Figure 3 and described below.
Perez-Mendez, et al. Expires April 30, 2015 [Page 12]
Internet-Draft GSS-ERP October 2014
+-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| Client | | RP | | Visited AAA | | Home AAA |
+-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|------ 1 ----->| | |
| | | |
|<----- 2 ------| | |
| | | |
|------ 3 ----->| | |
| |------ 4 ----->| |
| | | |
| | (5) |
| | | |
| |<------ 6 -----| |
| | | |
|<------ 7 -----| | |
| | | |
(8) | | |
| | | |
Figure 3: ERP local operation
1. The Client starts the GSS-EAP mechanism, also including an ERP
Supported Subtoken indicating an implicit bootstrapping is not
required. At this point the Client does not know whether an
explicit bootstrapping or an ERP local operation will be
performed, as the ERP realm is unknown.
2. The RP continues with the standard GSS-EAP mechanism, sending an
EAP-Initiate/Re-Auth-Start, instead of an EAP-Identity/Request,
indicating the Visited organization's realm.
3. The Client sends an EAP-Initiate/Re-Auth generated using the
available DS-rRK/DS-rIK keys.
4. The RP forwards this EAP message to the Visited AAA server.
5. The Visited AAA server verifies the EAP message using the stored
DS-rRK/DS-rIK keys, and derives the rMSK. It also retrieves the
stored SAML assertion.
6. The Visited AAA server sends the EAP-Finish/Re-Auth, the SAML
assertion and the rMSK to the RP.
7. The RP sends the EAP-Finish/Re-auth to the Client and finalizes
the GSS-EAP mechanism.
Perez-Mendez, et al. Expires April 30, 2015 [Page 13]
Internet-Draft GSS-ERP October 2014
8. The Client derives the rMSK.
7. Security Considerations
TBD
8. IANA Considerations
The authors request that GSS-EAP Subtoken types defined in this
document be registered by the Internet Assigned Numbers Authority
(IANA) from the "Extensible Authentication Protocol Mechanism for the
Generic Security Service Application Programming Interface (GSS-EAP)
Parameters" registry defined in section 7.3 of [RFC7055], in
accordance with BCP 26 [RFC5226].
9. Acknowledgements
This work has been partly funded by the GN3plus OpenCall CLASSe
project [CLASSe] .
10. References
10.1. Normative References
[I-D.ietf-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
Schaad, "Application Bridging for Federated Access Beyond
Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work
in progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP
Extensions for the EAP Re-authentication Protocol (ERP)",
RFC 6696, July 2012.
[RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
Extensible Authentication Protocol", RFC 7055,
December 2013.
Perez-Mendez, et al. Expires April 30, 2015 [Page 14]
Internet-Draft GSS-ERP October 2014
10.2. Informative References
[CLASSe] "CLASSe project home page", <http://www.um.es/classe/>.
[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.
[I-D.ietf-abfab-usecases]
Smith, R., "Application Bridging for Federated Access
Beyond web (ABFAB) Use Cases",
draft-ietf-abfab-usecases-05 (work in progress),
September 2012.
[RFC6942] Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G.
Zorn, "Diameter Support for the EAP Re-authentication
Protocol (ERP)", RFC 6942, May 2013.
[RFC7057] Winter, S. and J. Salowey, "Update to the Extensible
Authentication Protocol (EAP) Applicability Statement for
Application Bridging for Federated Access Beyond Web
(ABFAB)", RFC 7057, December 2013.
Authors' Addresses
Alejandro Perez-Mendez (Ed.)
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 46 44
Email: alex@um.es
Rafa Marin-Lopez
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 85 01
Email: rafa@um.es
Perez-Mendez, et al. Expires April 30, 2015 [Page 15]
Internet-Draft GSS-ERP October 2014
Gabriel Lopez-Millan
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 85 04
Email: gabilm@um.es
Fernando Pereniguez-Garcia
Catholic University of Murcia
Av Jeronimos, 135
Murcia, 30107
Spain
Email: pereniguez@um.es
Perez-Mendez, et al. Expires April 30, 2015 [Page 16]
