Network Working Group                                R. Marin-Lopez(Ed.)
Internet-Draft                                 F. Pereniguez-Garcia(Ed.)
Intended status: Experimental                          F. Bernal-Hidalgo
Expires: July 23, 2010                                 A. Gomez-Skarmeta
                                                    University of Murcia
                                                        January 19, 2010


 Architecture for Fast EAP Re-authentication based on a new EAP method
                  (EAP-FRM) working on standalone mode
                   draft-marin-eap-frm-fastreauth-01

Status of this Memo

   This Internet-Draft is submitted to IETF 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 July 23, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 1]

Internet-Draft                   EAP-FRM                    January 2010


Abstract

   This document describes an architecture aimed for reducing the
   latency of network access authentication based on the Extensible
   Authentication Protocol (EAP).  The architecture is based on the
   design of a new EAP method for which a standalone authenticator is
   used, and does not require any change to the EAP specification or the
   specifications of existing EAP lower-layers.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Overview of the Architecture . . . . . . . . . . . . . . . . .  4
     2.1.  General bootstrapping phase  . . . . . . . . . . . . . . .  6
     2.2.  Fast re-authentication phase . . . . . . . . . . . . . . .  7
   3.  EAP-FRM Format . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  EAP-FRM packet format  . . . . . . . . . . . . . . . . . .  8
   4.  MSK and EMSK derivation  . . . . . . . . . . . . . . . . . . .  9
   5.  Message Authentication . . . . . . . . . . . . . . . . . . . . 10
   6.  Capabilities negotiation . . . . . . . . . . . . . . . . . . . 11
   7.  TLVs defined in EAP-FRM  . . . . . . . . . . . . . . . . . . . 11
   8.  Implementation Framework . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     12.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  RADIUS and Diameter extensions  . . . . . . . . . . . 14
   Appendix B.  Use Case Example: ERP-based Fast
                Re-authentication Protocol with EAP-FRM and RADIUS  . 17
     B.1.  Fast re-authentication phase . . . . . . . . . . . . . . . 17
     B.2.  Bootstrapping phase  . . . . . . . . . . . . . . . . . . . 19
   Appendix C.  Prototype Implementation  . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22














Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 2]

Internet-Draft                   EAP-FRM                    January 2010


1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC5247] has been
   designed to permit different types of authentication mechanisms
   through the so-called EAP methods.  These are performed between an
   EAP peer and an EAP server, through an EAP authenticator.  Whereas
   the EAP peer is located with the mobile and the EAP authenticator is
   commonly placed on the Network Access Server (NAS) (e.g. an access
   point or an access router), the EAP server can be placed either with
   a backend AAA server (pass-through configuration) or co-located with
   the EAP authenticator (standalone configuration).

   In order to deliver EAP packets between the EAP peer and the EAP
   authenticator, an EAP lower-layer is used.  In case of pass-through
   configuration, an AAA protocol such as RADIUS or Diameter is used for
   the same purpose between the EAP authenticator and the EAP server.

   Taking into account mobile environments, EAP has shown some drawbacks
   where a reduced handover latency, including the latency in network
   access authentication and key establishment, is required [RFC5169].
   Indeed, a complete EAP authentication with use of long-term
   authentication credentials requires a considerable amount of time and
   number of message exchanges [MQ07].  The latency of the complete EAP
   authentication can be even longer when the EAP peer and EAP server
   are geographically far apart.  For instance, the EAP server may be
   located in the home AAA domain of the subscriber, whereas the
   subscriber is currently located in a visited AAA domain, residing the
   home and visited AAA domains in different geographical areas (e.g.,
   different countries or different states in the same country).  In the
   worst case, a full EAP authentication can happen each time the peer
   changes its point of attachment.

   To solve these problems, the ERP (EAP Extensions for EAP Re-
   authentication Protocol) [RFC5296] protocol has been standardized in
   HOKEY WG.  Nevertheless, ERP is based on the following assumptions:

   o  It requires modifications in current EAP peers, EAP authenticators
      and EAP/AAA servers.

   o  It modifies the standard EAP state machines.

   o  Current EAP lower-layers require modifications.  Standard wireless
      technologies and protocols that currently use EAP need to be
      updated.

   These assumptions may cause a harder deployment of the solution.  In
   order to alleviate the impact of these potential problems and keeping
   a reduced latency for network access authentication, we propose an



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 3]

Internet-Draft                   EAP-FRM                    January 2010


   architecture for fast EAP re-authentication based on the design of a
   new EAP method named EAP-FRM.  This EAP method works on standalone
   EAP authenticators but the method itself can contact a backend
   authentication server.  The EAP-FRM can transport the payload of any
   fast re-authentication protocol (hereafter FRP).  As we will show,
   this new architecture allows:

   o  No modification to EAP is required because EAP is designed to
      carry any EAP method.

   o  No modification to lower-layer specifications is required because
      EAP has the media independence property.

   o  No modification to the EAP Key Managament Framework defined in
      [RFC5247] is required.

   o  Minimum extension to AAA protocols is needed.  When an AAA
      protocol is used between the authenticator and a backend
      authentication server, new AAA attributes may be needed to carry
      the authentication information between an authenticator and the
      backend authentication server.

   o  Assuming a well designed FRP, only one roundtrip beyond access
      network is needed at the most.

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].


2.  Overview of the Architecture

   The proposed architecture for fast re-authentication uses a new EAP
   method named EAP-FRM that operates in the standalone authenticator
   mode.  That is, the end points for EAP-FRM method are the EAP peer
   and the EAP authenticator.  However, unlike other EAP methods working
   on standalone mode, EAP-FRM itself may communicate with a backend
   authentication server (e.g., an AAA server), using a protocol for
   verification of the authentication information originated by the EAP
   peer and sent to the EAP authenticator by means of EAP-FRM messages.
   A PDU of any FRP can be encapsulated in EAP-FRM.  Nevertheless, it is
   important to note that this operation does not change the standard
   model of EAP operation.

   In case the backend authentication server is contacted to process the
   FRP, upon successful authentication, the backend authentication



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 4]

Internet-Draft                   EAP-FRM                    January 2010


   server sends key material and other information associated with the
   key material back to the authenticator.  The protocol used to convey
   the FRP messages between the authenticator and the backend
   authentication server is referred as backend protocol.  Figure 1
   shows a general overview of the proposed architecture in which an AAA
   protocol such as RADIUS or Diameter is used as the backend protocol.

         Mobile                Authenticator            Backend Auth.
      (EAP Peer)              (EAP Auth/Serv.)              Server
      -----------              -------------             ------------
       |                             |                             |
       |     EAP-Request/FRM()       |                             |
       |<----------------------------|                             |
       |     EAP-Response/FRM()      |                             |
       |---------------------------->|         AAA-Request*()      |
       |                             |---------------------------->|
       |                             |         AAA-Response*()     |
       |             .               |<----------------------------|
       |             .               |                             |
       |                             |                             |
       |     EAP-Request/FRM()       |                             |
       |<----------------------------|                             |
       |     EAP-Response/FRM()      |                             |
       |---------------------------->|                             |
       |       EAP-Success()         |                             |
       |<----------------------------|                             |
       |                             |                             |
       |                             |                             |
       | <-- EAP Transport Based --> | <-- Transport Protocol -->  |
       |         in EAP-FRM          |    (e.g.AAA Protocol)       |
       |                             |                             |


        *Optional if the FRP can be processed by the authenticator.

                      Figure 1: EAP-FRM Architecture

   Figure 2 shows a general example assuming a FRP that involves two
   messages FRP_1 and FRP_2.  In this example, it is assumed that FRP_1
   can only be processed by the backend authentication server.
   Moreover, it is assumed that the execution of the FRP will generate
   cryptographic material.  In the case where the FRP is performed in
   the backend authentication server, it will send the generated key to
   the authenticator.  Let us denote this key as rMSK (re-authentication
   master session-key) for generality.  In particular, this rMSK will
   arrive to the authenticator and will be processed by EAP-FRM method.
   With this cryptographic material, the EAP-FRM method will derive the
   MSK and the EMSK that will be exported to the lower-layers.  The



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 5]

Internet-Draft                   EAP-FRM                    January 2010


   details of derivation of both keys are explained in Section 4.  Note
   that a well designed FRP should only involve one roundtrip with the
   backed authenticator server at the most.

         Mobile                Authenticator            Backend Auth.
      (EAP Peer)              (EAP Auth/Serv.)              Server
      -----------              -------------             ------------
       |                             |                             |
       |     EAP-Request/FRM()       |                             |
       |<----------------------------|                             |
       |    EAP-Response/FRM(FRP_1)  |                             |
       |---------------------------->|       AAA-Request(FRP_1)    |
       |                             |---------------------------->|
       |                             |    AAA-Response(FRP_2,rMSK) |
       |                             |<----------------------------|
       |                             |                             |
       |                             |                             |
       |    EAP-Request/FRM(FRP_2)   |                             |
       |<----------------------------|                             |
       |     EAP-Response/FRM()      |                             |
       |---------------------------->|                             |
       |       EAP-Success()         |                             |
       |<----------------------------|                             |
       |                             |                             |


                 Figure 2: General Example of EAP-FRM use

   The architecture assumes that some cryptographic material is shared
   between the EAP peer and the backend authentication server.  This
   cryptographic material may be established in an earlier EAP execution
   during the so-called bootstrapping phase.  This phase can be
   performed through any EAP method able to export the EMSK and MSK.
   The designed FRP may use the EMSK as root of a key hierarchy to
   create some shared cryptographic key material as [RFC5295] describes.
   This cryptographic material will be used by the FRP during the fast
   re-authentication phase each time the peer wants to authenticate with
   a new EAP-FRM capable EAP authenticator.

2.1.  General bootstrapping phase

   If the cryptographic material used by the FRP is derived from the
   EMSK, it is required to use a bootstrapping EAP method (e.g.  EAP-
   TLS) to derive the EMSK before using EAP-FRM.  The bootstrapping EAP
   method requires the use of long-term credentials of the peer or
   Transient EAP Keys (TEKs) derived from the long-term credentials
   [RFC5247].  Given that the bootstrapping EAP method is typically
   executed in a pass-through configuration mode, the EAP server for the



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 6]

Internet-Draft                   EAP-FRM                    January 2010


   bootstrapping EAP method resides in the backend authentication
   server.

   When the EAP authentication for the bootstrapping EAP method
   succeeds, a MSK and an EMSK are generated as the EAP keying material.
   While the MSK is sent to the authenticator to establish a security
   association with the peer, the EMSK is held by the backend
   authentication server and the peer and used for generating the
   credentials needed by the FRP in the fast re-authentication phase.

2.2.  Fast re-authentication phase

   As Figure 2 depicts, the peer after the handoff (or even before the
   movement through an EAP early authentication
   [I-D.ietf-hokey-preauth-ps]) engages an EAP-FRM exchange with the EAP
   authenticator.  The EAP authenticator MUST be configured to start
   EAP-FRM, in such a way that the EAP authenticator sends automatically
   an EAP-Request/FRM message instead of EAP Request/Id.  If the peer
   does not support EAP-FRM, it can send an EAP-Response/Nak message.
   This shall provoke that the authenticator sends EAP-Request/Id in
   order to start a traditional EAP authentication process.  In this
   way, we allow to support authentication for non EAP-FRM peers.
   Alternatively, if the peer answers EAP-Response/FRM with FRP data
   (e.g., FRP_1), the authenticator extracts this information from the
   EAP-Response/FRM and either processes it to provide access or
   forwards it (e.g., through an AAA protocol) for verification to the
   backend authentication server.  This will depend on the specific FRP
   used.  If a backend authenticator server has to verify the FRP and it
   is correctly verified, the backend authentication server answers to
   the authenticator with the response obtained as a consequence of
   processing the FRP.  That FRP answer message is forwarded to the peer
   through an EAP-Request/FRM.

   Note that only one FRP protocol can be executed in an execution of
   EAP-FRM.  Once the specific FRP has finished the authenticator sends
   the EAP success.

   In the following section, we describe the EAP-FRM method employed
   between peer and authenticator.  Appendix A explains the extensions
   which are required in RADIUS and Diameter to transport the FRP
   between the authenticator and the backend authentication server.
   Additionally, in Appendix B, we describe an example about how EAP-FRM
   can transport a FRP whose design is based on ERP.


3.  EAP-FRM Format





Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 7]

Internet-Draft                   EAP-FRM                    January 2010


3.1.  EAP-FRM packet format

   Figure 3 shows the EAP-FRM packet format.  The packet format for the
   EAP-FRM messages follows the EAP packet format defined in [RFC3748].

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |  Identifier   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type=EAP-FRM |     Flags     |    FRP-Type   |  Payload TLVs |
     |               |               |               |  (optional)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 3: EAP-FRM Packet

   o  Code, Identifier, Length: Common fields to all EAP messages (see
      [RFC3748])

   o  Type field: This field (1-octet) contains the value of the EAP
      method type corresponding to EAP-FRM (TBD).

   o  Flags: A 1-octet options field reserved for flags.

         'P' - The P flag is used as pre-authentication flag.  If the
         flag is turned on, the EAP-FRM message is part of a pre-
         authentication prior to the handoff operation.

         The rest of the 7 bits are set to 0 and ignored by
         authenticator on reception.

   o  FRP-Type: The FRP-Type is 1-octet field which identifies the
      transported fast re-authentication protocol.  So far next FRP has
      been defined in EAP-FRM:

         0.  Reserved

         1.  ERP-based

         2.  Kerberos

   o  Payload TLVs: the rest of the EAP-FRM packet is optionally
      composed of a set of TLVs.  Each TLV is formed by 1-octet type
      field, two octet length field and n-octect data field.  The length
      field indicates the length of the data field in number of octets.
      Next, there are some TLVs initially considered:





Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 8]

Internet-Draft                   EAP-FRM                    January 2010


      *  Nonce TLV.  It contains a pseudo-random nonce sent by the EAP-
         FRM peer or the EAP-FRM server.  When included in the first
         EAP-Request/FRM, it contains a pseudo-random nonce generated by
         the EAP-FRM server.  Otherwise, when included in the first EAP-
         Response/FRM, it contains a pseudo-random nonce generated by
         the EAP-FRM peer.

      *  FRP-Payload TLV.  It contains the specific payload of the FRP.

      *  Auth-Server TLV.  It contains the backend server's NAI or FDQN
         that manages the current EAP authenticator.

      *  User-Id TLV.  It contains the user's NAI.

      *  Auth TLV.  It is included to integrity protect an EAP-FRM
         message.

      *  Integrity-Algorithm TLV.  It indicates the integrity algorithm
         used for the AUTH TLV.  We specify some cryptosuites below:

         +  0 Reserved

         +  1 HMAC-SHA256-64

         +  2 HMAC-SHA256-128 (default)

         +  3 HMAC-SHA256-256

      *  KDF TLV.  It is included in the first EAP-Request/FRM to
         contain the KDF that EAP peer has to use to generate MSK, EMSK
         and TEKs.  If it is not included it means that the default
         value is used.

         +  0 Reserved

         +  1 PRF+ key expansion specified in [RFC4306] based on HMAC-
            SHA-256 [sha256] (default)


4.  MSK and EMSK derivation

   Let us assume that, after performing the FRP, a re-authentication
   master session key (rMSK) is obtained by the EAP-FRM method.  The
   EAP-FRM method will derive the MSK and the EMSK from that rMSK.  A
   set of 64-octet MSK and 64-octet EMSK to be exported from EAP-FRM are
   derived from the rMSK generated after performing the FRP.  EAP-FRM
   uses the Key Derivation Function (KDF) defined in [RFC5295] in the
   following way.



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                 [Page 9]

Internet-Draft                   EAP-FRM                    January 2010


      (MSK, EMSK) = KDF(rMSK, Session-Id || "EAP-FRM-EAP-Keying-
      Material", 128)

   The Session-Id is defined in [RFC5247] as:

      Session-Id = Type-Code || Method-Id

   where Method-Id is defined in EAP-FRM as:

      Method-Id = Nonce-Peer || Nonce-Server

   Finally, Nonce-Peer and Nonce-Server denote the nonce sent by the
   EAP-FRM peer and the EAP-FRM server, respectively.


5.  Message Authentication

   If the EAP-FRM peer or the EAP-FRM server require integrity
   protection for some of the EAP-FRM messages, an Auth TLV can be
   included.  The EAP-FRM-IK is used to compute Auth TLVs.  This key is
   used withing EAP-FRM only and is never exported.  The EAP-FRM-IK is
   derived from the rMSK, using the prf+ defined in [RFC4306] in the
   following way.

      EAP-FRM-IK = prf+(rMSK, Session-Id || "EAP-FRM-Integrity-
      Key",length);

   The default hash algorithm for prf+ is PRF_HMAC_SHA2_256.  The field
   length will depend upon the integrity algorithm selected by the EAP
   server during the EAP-FRM exchange.  For example, when HMAC-SHA-256
   [sha256] is used for the integrity algorithm, length=32.

   The value of the Auth TLV can be generated once the EAP-FRM-IK is
   derived, in the following way:

      Auth AVP value = Integrity-Algorithm(EAP-FRM-IK, EAP-FRM-Packet)

   The value field in the TLV contains an authentication tag computed
   over the entire EAP-FRM packet (EAP-FRM-Packet), starting from the
   first bit of the code field to the last bit of the Auth TLV with the
   value field of the Auth TLV filled with all 0s for the computation.
   The Integrity-Algorithm used to create the Auth TLV value is
   specified in the Integrity-Algorithm TLV sent in the first EAP-
   Request/FRM message.







Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 10]

Internet-Draft                   EAP-FRM                    January 2010


6.  Capabilities negotiation

   Although the proposed solution is able to transport any FRP, current
   specification of EAP-FRM does not allow the negotiation of the FRP.
   The authenticator sets the specific FRP that is going to be used in
   the EAP-Request/FRM.  If the peer supports EAP-FRM but it does not
   support such FRP, it must respond with an EAP-Response/Nak message.

   NOTE: Nevertheless, authors are evaluating the inclusion of a FRP
   negotiation in the architecture in a future version of this document.


7.  TLVs defined in EAP-FRM

   The following Figure 4 summarizes the TLVs defined in EAP-FRM and
   indicates which TLVs MAY or MAY NOT be found in which kinds of EAP-
   FRM messages, and in what quantity.  Both in EAP-FRM Request and EAP-
   FRM Response messages, we distinguish between the first (F) and last
   (L) messages, referring to the remaining exchanged messages as
   intermediate (I) messages.  The table uses the following symbols:

   0  The TLV MUST NOT be present in the message.

   0-1  Zero or one instance of the TLV MAY be present in the message.
      It is considered an error if there is more than one instance of
      the TLV.

   1  One instance of the TLV MUST be present in the message.


                            +-----------------------+
                            |      Message Type     |
                            +-----------------------+
                            |  EAP-FRM  |  EAP-FRM  |
                            |   Req.    |    Resp.  |
      +---------------------+---+---+---+---+---+---+
      | TLV Name            | F | I | L | F | I | L |
      +---------------------+---+---+---+---+---+---+
      | Nonce               | 1 | 0 | 0 | 1 | 0 | 0 |
      | FRP-Payload         |0-1|0-1|0-1|0-1|0-1|0-1|
      | Auth-Server         | 1 | 0 | 0 | 0 | 0 | 0 |
      | User-Id             | 0 | 0 | 0 |0-1|0-1|0-1|
      | Auth                | 0 | 0 |0-1| 0 | 0 |0-1|
      | Integrity-Algorithm | 0 | 0 | 1 | 0 | 0 | 1 |
      | KDF                 |0-1| 0 | 0 |0-1| 0 | 0 |
      +---------------------+---+---+---+---+---+---+

                     Figure 4: TLVs defined in EAP-FRM



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 11]

Internet-Draft                   EAP-FRM                    January 2010


8.  Implementation Framework

   In the following we show the implementation framework of our
   solution.  Basically, as Figure 5 depicts, the EAP-FRM method
   implementation in the EAP Auth/Server MAY call an API to interact
   with AAA client implementation in order to contact with the backend
   auth. server, if it is required for the specific FRP.  After
   performing the FRP, cryptographic material (rMSK) is held by the EAP-
   FRM implementation for key derivation in the peer and the server.  If
   EAP-FRM server has contacted a backend authentication server then the
   AAA implementation provides the distributed rMSK to the EAP-FRM
   implementation in the EAP Auth/Server.


             EAP peer              EAP Auth/Server         Backend Auth.
         +-+-+-+-+-+-+-+-+       +-+-+-+-+-+-+-+-+             Server
         |   (rMSK)      |       |  (rMSK)       |<----+
         |EAP-FRM method |       |EAP-FRM method |--+  |
         |   |           |       |   |           |  !  |
         +-+-+-+-!+-+-+-+-       +-+-+-+-+-+-+-+-+  !  |
         |   |           |       |   |           |  !  rMSK
         |   |           |       |   |           |  !  |
         |  EAP    peer  |       |  EAP    Auth. | API |
         |   |           |       |   |           |  !  |
         +-+-+-+-+-+-+-+-+       +-+-+-+-+-+-+-+-+  !  |
         |   |           |       |   |           |  !  |
         |  EAP   layer  |       |  EAP    layer |  !  |
         |   |           |       |   |           |  V  |
         +-+-+-+-!+-+-+-+-       +-+-+-+-++-+-+-+-+-+-+-+     +-+-+-+-+-
         |   V           |       |   V           |      |rMSK |        |
         | Lower   layer |       | Lower   Layer |AAA/IP|<----| AAA/IP |
         |               |       |               |      |     |        |
         +-+-+-+-+-+-+-+-+       +-+-+-+-+-+-+-+-+-+-+-+-     +-+-++-+-+
                 |                       |           |             |
                 +----------->-----------+           +------>------+

                 Figure 5: EAP-FRM Implementation Details

   Note that in Appendix B it is explained a specific prototype that we
   have implemented based on this framework.


9.  Security Considerations

   EAP-FRM can carry different fast re-authentication protocols.  Thus,
   the security of the overall EAP-FRM process strongly depends on the
   inherent security of the fast re-authentication protocol in use.
   EAP-FRM itself does not introduce any new vulnerability to EAP.



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 12]

Internet-Draft                   EAP-FRM                    January 2010


   Thus, it is highly recommendable to design the transported fast re-
   authentication protocol with suitable security properties.


10.  IANA Considerations

   This document has no actions for IANA.


11.  Acknowledgements

   This work has been supported by a Seneca Foundation grant within the
   Human Resources Researching Training Program 2007.  Thanks also to
   the Funding Program for Research Groups of Excellence with code
   04552/GERM/06 also granted by the Seneca Foundation.


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, August 2008.

   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              August 2008.

12.2.  Informative References

   [I-D.ietf-hokey-preauth-ps]
              Ohba, Y. and G. Zorn, "Extensible Authentication Protocol
              (EAP) Early Authentication Problem Statement",
              draft-ietf-hokey-preauth-ps-09 (work in progress),
              July 2009.

   [MQ07]     Marin-Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and
              A. Gomez, "Network-layer Assisted Mechanism to Optimize
              Authentication Delay During Handoff in 802.11 Networks,
              The 4th Annual International Conference on Mobile and



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 13]

Internet-Draft                   EAP-FRM                    January 2010


              Ubiquitous Systems: Computing, Networking and Services
              (MOBIQUITOUS 2007) , 2007.", 2007.

   [Marin07]  Marin, R., Fernandez, P., and A. Gomez, "3-Party Approach
              for Fast Handover in EAP-Based Wireless Networks. On the
              Move (OTM) Conferences, IS 2007. Springer, pp. 1764-1751",
              2007.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC5169]  Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
              "Handover Key Management and Re-Authentication Problem
              Statement", RFC 5169, March 2008.

   [RFC5296]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
              authentication Protocol (ERP)", RFC 5296, August 2008.

   [eap-frm]  Marin, R., Pereniguez, F., Ohba, Y., Bernal, F., and A.
              Gomez, "A Transport-Based Architecture for Fast Re-
              Authentication in Wireless Networks. IEEE Sarnoff 2009.".

   [freeradius]
              "http://freeradius.org/".

   [hostap]   "http://hostap.epitest.fi/hostapd/".

   [sha256]   "National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS 180-2, With Change Notice 1 dated
              February 2004, August 2002.".

   [wpa_supplicant]
              "http://hostap.epitest.fi/wpa_supplicant/".


Appendix A.  RADIUS and Diameter extensions

   If the authenticator is not able to process the FRP payload sent by
   the peer within an EAP-Response/FRM, it may need to contact an AAA
   server to process the FRP.  Thus, the FRP may need to be carried from
   the authenticator to the AAA server by means of an AAA protocol such
   as RADIUS or Diameter.

   For RADIUS, it is required (at least) three new attributes: RADIUS
   FRM-Flags, RADIUS FRP-Id and RADIUS FRP-Payload-Attr.  The first
   transports one octet with the content of the flag field in EAP-FRM
   packet; the second transports the FRP type (one of the numbers



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 14]

Internet-Draft                   EAP-FRM                    January 2010


   defined for the FRP-Type in the EAP-FRM packet) and the third carries
   the FRP payload.  These attributes are included in RADIUS Access-
   Request and RADIUS Access-Accept.  It is important to note that the
   FRP-Id attribute allows the backend authentication server to
   determine which specific FRP is contained in the attribute FRP-
   Payload-Attr.  These attributes are defined as follows:


               0                   1                   2
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |    FRM-Flags  |  Length=1     | EAP-FRM Flags |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 6: RADIUS FRM-Flags attribute



               0                   1                   2
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |    FRP-Id     |  Length=1     |   FRP Type    |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 7: RADIUS FRP-Id attribute


               0                   1                   2
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
              |FRP-Payl.-Attr |    Length     |    Payload ...
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

                Figure 8: RADIUS FRP-Payload-Attr attribute

   For Diameter, the definition of a new application (Diameter Fast Re-
   authentication Application) may be required.  This application
   defines two commands:

   o  Diameter-FR-Request: to carry an EAP-FRM payload from the
      authenticator to the AAA server.

   o  Diameter-FR-Answer: for the same purpose in the opposite
      direction.

   Both messages include three new Diameter AVPs (FRM-Flags, FRP-Id and



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 15]

Internet-Draft                   EAP-FRM                    January 2010


   FRP-Payload-Attr) which transports the flags field in EAP-FRM, the
   FRP type and the FRP payload, respectively.  Nevertheless, other
   existing applications (e.g.  Diameter NASREQ application) could be
   extended to carry these new AVPs.  This needs further study though.
   These AVPs are defined as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 AVP Code: FRM-Flags                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V M P r r r r r|                  AVP Length = 1               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   FRM Flags   |
      +-+-+-+-+-+-+-+-+

                     Figure 9: Diameter FRM-Flags AVP


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 AVP Code: FRP-Id                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V M P r r r r r|                  AVP Length = 1               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    FRP Id     |
      +-+-+-+-+-+-+-+-+

                      Figure 10: Diameter FRP-Id AVP

   The FRP-Id will one of the numbers defined for FRP-Type in the EAP-
   FRM packet.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 AVP Code: FRP-Payload-Attr                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V M P r r r r r|                  AVP Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    FRP Payload Data...
      +-+-+-+-+-+-+-+-+

                 Figure 11: Diameter FRP-Payload-Attr AVP






Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 16]

Internet-Draft                   EAP-FRM                    January 2010


Appendix B.  Use Case Example: ERP-based Fast Re-authentication Protocol
             with EAP-FRM and RADIUS

   In the following, we present an example where the proposed
   architecture for fast re-authentication is used to transport a FRP
   based on the ERP protocol defined in [RFC5296].  In particular, for
   this example, the FRP payload is composed by the fields defined in
   ERP messages, starting from the Type field to the end.  Since there
   are three messages in ERP (EAP-Initiate/Re-auth-Start, EAP-Initiate/
   Re-auth and EAP-Finish/Re-auth) three different payloads are
   transported as the FRP payload: IRS* (fields of EAP-Initiate/
   Re-auth-Start from the Type field), IR* (fields of the EAP-Initiate/
   Re-auth from the Type field) and FR* (fields of the payload EAP-
   Finish/Re-auth from the Type field).  In terms of this example, the
   backend authentication server is called ER server.

B.1.  Fast re-authentication phase

   Figure 12 shows the protocol exchange that takes place when a peer
   performs a handoff between authenticators that are under the control
   of the same ER server.  The process starts when the authenticator
   sends an EAP-Request/FRM (with the FRP-Type field set to ERP-based
   code) to the peer, containing an Auth-Server TLV.  In this example,
   this TLV can carry the same value that the Domain-Name TLV carries in
   ERP.  Moreover, a FRP-Payload is included to contain the IRS*
   payload.  On the reception of this message the peer knows that is
   under an authenticator of the domain "local".
























Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 17]

Internet-Draft                   EAP-FRM                    January 2010


           Mobile               Authenticator             ER Server
        (EAP Peer)               (EAP Server)            (srv.local)
        -----------             -------------         ------------------
         |                           |                                 |
         |<--------------------------|                                 |
         | EAP-Req./FRM(Nonce,       |                                 |
         |             Auth-Server[  |                                 |
         |         local],           |                                 |
         |   FRP-Payload[IRS*])      |                                 |
         |-------------------------->|                                 |
         | EAP-Resp./FRM(Nonce,      |                                 |
         |              User-Id[     |                                 |
         |         EMSKname@local],  |                                 |
         |   FRP-Payload[IR*])       |                                 |
         |                           |                                 |
         |                           |-------------------------------->|
         |                           |  RADIUS Access-Req(User-Name[   |
         |                           |         EMSKname@local],        |
         |                           |          FRP-Id[ERP],           |
         |                           |      FRP-Payload-Attr[IR*])     |
         |                           |                                 |
         |                           |<--------------------------------|
         |                           |RADIUS Access-Accept(FRP-Id[ERP],|
         |                           |   FRP-Payload-Attr[FR*],rMSK)   |
         |                           |                                 |
         |<--------------------------|                                 |
         |    EAP-Req./FRM(          |                                 |
         |    FRP-Payload[FR*])      |                                 |
         |                           |                                 |
         |-------------------------->|                                 |
         |    EAP-Resp./FRM()        |                                 |
         |                           |                                 |
         |<--------------------------|                                 |
         |      EAP-Success()        |                                 |
         |                           |                                 |


         Figure 12: ERP-based FRP with EAP-FRM. Handoff operation.

   Then, the peer sends an EAP-Response/FRM containing the IR* payload.
   The message includes an User-Id TLV that has the value of the
   keyName-NAI (e.g.  EMSKname@local).  On the reception, the
   authenticator creates a RADIUS Access-Request that includes the User-
   Name attribute carrying the content of the User-Id TLV ; the FRP-Id
   attribute indicating the ERP-based protocol as the FRP; and the FRP-
   Payload-Attr containing the ERP payload (IR*).  Note that, in this
   case, the authenticator is not required to understand the data
   contained in the FRP-Payload TLV.



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 18]

Internet-Draft                   EAP-FRM                    January 2010


   When the ER server performs a successful re-authentication based on
   the information contained in the FRP-Payload-Attr, it generates the
   associated RADIUS Access-Accept.  This message includes: the FRP-Id
   attribute (indicating ERP as FRP); the FRP response message (FR*)
   that is included in a FRP-Payload-Attr attribute; and the rMSK.  The
   rMSK will reach the EAP-FRM method at the authenticator, and the EAP-
   FRM method engine will derive the MSK and EMSK from the rMSK and will
   export them to the lower-layer.  Additionally, the authenticator
   forwards the content of the FRP response message (FR*) to the peer
   through an EAP-Request/FRM message.  When the peer processes the FR*
   payload contained in the received FRP-Payload TLV, the execution of
   the FRP (in this case an ERP-based protocol) ends.  As a consequence
   of a successful ERP-based FRP execution, the EAP-FRM method in the
   peer will obtain the same rMSK that the one received in the
   authenticator and will derive and export the same MSK and EMSK to the
   lower-layer.  The EAP-FRM method concludes through an additional EAP-
   Resp./FRM and EAP-Success messages to maintain backward compatibility
   with current EAP specification.

   It is worth noting that, usually, the link between the authenticator
   and the backend authentication server represents the bottleneck
   during fast re-authentication process.  However, as observed, only
   one roundtrip is required between the authenticator and the ER
   server.

B.2.  Bootstrapping phase

   The ERP specification defines the so-called explicit bootstrapping.
   As described in [RFC5296], this operation is intended to support
   those situations where, for example, a local ER server needs to
   request a DSRK from the home ER server.  In terms of our
   architecture, nothing changes with respect to the signalling showed
   in previous section, except that now the home ER server must be
   contacted.  Figure 13 shows the signalling involved in our
   architecture taking into account an ERP-based FRP that includes
   explicit bootstrapping.















Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 19]

Internet-Draft                   EAP-FRM                    January 2010


           Mobile     Authenticator   Local Auth. Serv. Home Auth. Serv.
        (EAP Peer)    (EAP Server)          (local)         (home)
        -----------   -------------   -----------------  -------------
            |               |                 |                   |
            |<--------------|                 |                   |
            | EAP-Req/FRM(  |                 |                   |
            | Nonce,        |                 |                   |
            | Auth-Server[local],             |                   |
            | FRP-Payload[IRS*])              |                   |
            |-------------->|                 |                   |
            |EAP-Resp/FRM(  |                 |                   |
            | Nonce,        |                 |A                   |
            | User-Id[EMSKname@home],         |                   |
            | FRP-Payload[IR*])               |                   |
            |               |                 |                   |
            |               |---------------->|                   |
            |               |RADIUS Access-Req(                   |
            |               |User-Name[EMSKname@home],            |
            |               |FRP-Id[ERP],                         |
            |               |FRP-Payload-Attr[IR*])               |
            |               |                 |                   |
            |               |                 |------------------>|
            |               |                 |RADIUS Access-Req( |
            |               |                 |User-Name[EMSKname@home],
            |               |                 |FRP-Id[ERP],       |
            |               |                 |FRP-Payload-Attr[IR*],
            |               |                 |DSRK-Request)      |
            |               |                 |<------------------|
            |               |    RADIUS Access-Accept(FRP-Id[ERP],|
            |               |               FRP-Payload-Attr[FR*],|
            |               |                 DSRK,EMSKname,rMSK) |
            |               |<----------------|                   |
            |           RADIUS Access-Accept( |                   |
            |               |     FRP-Id[ERP],|                   |
            |           FRP-Payload-Attr[FR*],|                   |
            |               |          rMSK)  |                   |
            |<--------------|                 |                   |
            | EAP-Req/FRM(  |                 |                   |
            | FRP-Payload[FR*])               |                   |
            |               |                 |                   |
            |               |                 |                   |
            |               |                 |                   |
            |-------------->|                 |                   |
            |EAP-Response/FRM()               |                   |
            |               |                 |                   |
            |<--------------|                 |                   |
            |  EAP-Success()|                 |                   |
            |               |                 |                   |



Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 20]

Internet-Draft                   EAP-FRM                    January 2010


      Figure 13: ERP-based FRP with EAP-FRM (explicit bootstrapping)


Appendix C.  Prototype Implementation

   In the following we show some implementation details of a prototype
   we have developed to implement our architecture.  So far, the
   prototype uses RADIUS as AAA protocol between EAP authenticator and
   backend authentication server.

   EAP-FRM implementation for both peer and authenticator is based on
   wpa_supplicant version 0.6.4 [wpa_supplicant] and hostapd version
   0.6.4[hostap] respectively.

   The RADIUS client implementation has been run by using the API
   provided by hostapd.  This API allows the creation of the RADIUS
   messages.  This API is called from the EAP-FRM server implementation.
   The backend authentication server is a RADIUS server implemented with
   Free RADIUS version 2.0.2 [freeradius].  For managing the information
   carried by the FRP-Payload-Attr attribute described in , a new module
   has been developed in Free RADIUS.  Figure 14 shows the testbed used
   for running the implementation.  Moreover, Figure 15 shows an
   ethereal trace of an execution.  (NOTE: Since ethereal has not
   registered EAP-FRM, it shows the Unknown type).

          wpa_supplicant
            (EAP peer)                                       Free RADIUS
             +------+         +-----+         +-----+           +-----+
             | Peer |<------->| pAP |<------->| AR  | <-------> | AAA |
             +------+         +-----+         +-----+           +-----+
                                                 ^
                                                 |
                              +-----+            |
                              | nAP |<-----------+
                              +-----+
                              hostapd (WPA2-802.11i)
                          (EAP auth/server)

                    Figure 14: EAP-FRM Deployed Testbed












Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 21]

Internet-Draft                   EAP-FRM                    January 2010


   +--------+----------------+----------------+------------------------+
   |  Time  |     Source     |   Destination  |      Protocol Info     |
   +--------+----------------+----------------+------------------------+
   |98.07528|Aironet_b2:18:7b|Aironet_b2:13:4e|EAP Request,Unknown type|
   |        |                |                |                        |
   |98.07729|Aironet_b2:13:4e|Aironet_b2:18:7b|EAP Resp., Unknown type |
   |        |                |                |                        |
   |98.07963|  192.168.1.5   |   192.168.1.3  |  RADIUS Access-Request |
   |        |                |                |                        |
   |98.08071|  192.168.1.3   |   192.168.1.5  |  RADIUS Access-Accept  |
   |        |                |                |                        |
   |98.08121|Aironet_b2:18:7b|Aironet_b2:13:4e|EAP Request,Unknown type|
   |        |                |                |                        |
   |98.08188|Aironet_b2:13:4e|Aironet_b2:18:7b| EAP Resp.,Unknown type |
   |        |                |                |                        |
   |98.08239|Aironet_b2:18:7b|Aironet_b2:13:4e|     EAP Success        |
   +--------+----------------+----------------+------------------------+

             Figure 15: Execution output (authenticator view)

   NOTE: For the prototype, the FRP described in [Marin07] has been
   implemented in this example.

   As we may see, there is only one roundtrip between authenticator and
   backend authentication server (as happens with ERP).  EAP-FRM adds
   the last exchange in the sequence is to maintain compatibility with
   the current EAP specification.  However, we have measured that they
   take only around 3.4 ms (+/- 1.37 ms) in average to complete.  For
   further information about these results see [eap-frm].


Authors' Addresses

   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +36 868 88 85 01
   Email: rafa@um.es










Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 22]

Internet-Draft                   EAP-FRM                    January 2010


   Fernando Pereniguez-Garcia
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +36 868 88 78 82
   Email: pereniguez@um.es


   Fernando Bernal-Hidalgo
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +36 868 88 86 67
   Email: fbernal@um.es


   Antonio Gomez-Skarmeta
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +36 868 88 46 07
   Email: skarmeta@um.es























Marin-Lopez(Ed.), et al.  Expires July 23, 2010                [Page 23]