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]