Network Working Group R. Marin-Lopez(Ed.)
Internet-Draft F. Pereniguez-Garcia(Ed.)
Intended status: Experimental F. Bernal-Hidalgo
Expires: September 29, 2011 A. Gomez-Skarmeta
University of Murcia
March 28, 2011
Architecture for Fast EAP Re-authentication based on a new EAP method
(EAP-FRM) working on standalone mode
draft-marin-eap-frm-fastreauth-03
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.
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 September 29, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 1]
Internet-Draft EAP-FRM March 2011
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. Overview of the Architecture . . . . . . . . . . . . . . . . . 4
2.1. General bootstrapping phase . . . . . . . . . . . . . . . 6
2.2. Fast re-authentication phase . . . . . . . . . . . . . . . 6
3. EAP-FRM Format . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. EAP-FRM Packet Format . . . . . . . . . . . . . . . . . . 9
4. MSK and EMSK Derivation . . . . . . . . . . . . . . . . . . . 11
5. Message Authentication . . . . . . . . . . . . . . . . . . . . 11
6. Capabilities negotiation . . . . . . . . . . . . . . . . . . . 12
7. TLVs Defined in EAP-FRM . . . . . . . . . . . . . . . . . . . 12
8. Implementation Framework . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. RADIUS and Diameter Extensions . . . . . . . . . . . 17
Appendix B. Use Case Example 1: ERP-based Fast
Re-authentication Protocol with EAP-FRM and RADIUS . 19
B.1. Fast re-authentication phase . . . . . . . . . . . . . . . 19
B.2. Bootstrapping phase . . . . . . . . . . . . . . . . . . . 21
Appendix C. Use Case Example 2: Kerberos-based Fast
Re-authentication Protocol with EAP-FRM and RADIUS . 23
Appendix D. Prototype Implementation . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 2]
Internet-Draft EAP-FRM March 2011
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 September 29, 2011 [Page 3]
Internet-Draft EAP-FRM March 2011
architecture for fast EAP re-authentication based on the design of a
new EAP method named EAP-FRM (EAP Fast Re-authentication Method).
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 offers the
following benefits:
o No modification to EAP is required because the definition of new
EAP methods is the extensibility mechanism offered by EAP.
o No modification to existing lower-layer specifications is required
because EAP has the media independence property.
o No modification to the EAP Key Management 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 EAP-FRM method is executed between the EAP peer
and the EAP authenticator which also implements the EAP server
functionality. EAP-FRM is destined to transport authentication
information between the peer and the authenticator. More precisely,
a PDU (Protocol Data Unit) of any fast re-authentication protocol can
be the authentication information encapsulated in EAP-FRM. In the
standalone mode, the EAP conversation takes place between the EAP
peer and the EAP authenticator which also implements the EAP server.
Typically, an EAP authenticator working on standalone configuration
for a specific EAP method, is expected to locally process the
authentication data received from the peer. Nevertheless, if
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 4]
Internet-Draft EAP-FRM March 2011
necessary, the EAP-FRM method implementation executed by the
standalone authenticator can communicate with an backend
authentication server (e.g., an AAA server) for verification of the
authentication information originated by the peer and encapsulated in
EAP-FRM messages. It is important to note that this operation does
not change the standard EAP operation model. 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
EAP-FRM assumes that the execution of the FRP will generate
cryptographic material. In particular, the FRP is expected to export
a key which, for generality, we denote as re-authentication Master
Session Key (rMSK). With this cryptographic material, the EAP-FRM
method will derive the MSK and the EMSK that will be exported to the
lower-layers. The details of derivation of both keys are explained
in Section 4.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 5]
Internet-Draft EAP-FRM March 2011
The architecture assumes that some cryptographic material is shared
between the EAP peer and the backend authentication server prior to
the EAP-FRM execution. 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 will 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
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. This EMSK is used for generating
the credentials needed by the FRP in the fast re-authentication
phase. The use of EAP-FRM and related parameters may be negotiated
between the peer and the authentication server in the bootstrapping
phase.
2.2. Fast re-authentication phase
As Figure 1 depicts, after the handoff (or even before the movement
through an EAP early authentication [RFC5836]), the peer 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, the authenticator extracts
this information from the EAP-Response/FRM and either processes it to
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 6]
Internet-Draft EAP-FRM March 2011
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.
Assuming a FRP that involves, for example, two messages (FRP_1 and
FRP_2) to re-authenticate a user, Figure 2 and Figure 3 show two
general usage examples of EAP-FRM depending on whether a backend
authentication server needs to be contacted by the authenticator or
not. For the first case (Figure 2), the authenticator starts the
fast re-authentication process by sending an EAP-Request/FRM to the
peer, which answers with an EAP-Response/FRM containing the first
message of the FRP (FRP_1). When the authenticator receives this
message, extracts the authentication information and processes it
locally. Once the information is successfully validated, the
authenticator answers the peer with the final FRP message (FRP_2)
transported within an EAP-Request/FRM. At this point, the execution
of the FRP has been successfully completed and an rMSK is locally
exported by the FRP to the EAP-FRM method in both the peer and the
authenticator. Nevertheless, to conclude the EAP conversation, a
final EAP-Response/FRM and EAP-Success exchange is required in order
to maintain compatibility with current EAP specification and avoid
any modification to existing EAP lower-layers.
Mobile Authenticator
(EAP Peer) (EAP Auth/Serv.)
----------- -------------
| |
| EAP-Request/FRM() |
|<----------------------------|
| EAP-Response/FRM(FRP_1) |
|---------------------------->|
| EAP-Request/FRM(FRP_2) |
|<----------------------------|
| |
| EAP-Response/FRM() |
|---------------------------->|
| EAP-Success() |
|<----------------------------|
| |
Figure 2: EAP-FRM Exchange when a Backend Server is not required
If the FRP needs a backend authentication server to verify the
authentication data sent by the peer, the fast re-authentication
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 7]
Internet-Draft EAP-FRM March 2011
process is slightly different. As observed in Figure 3 , the
authenticator forwards FRP_1 to a backend authentication server by
using an AAA protocol. After processing the received FRP message,
the backend server generates FRP_2 and computes the rMSK. Both
pieces of information are sent within the AAA response to the EAP
authenticator. While FRP_2 is forwarded to the peer through an EAP-
Request/FRM, the rMSK is processed by the EAP-FRM method
implementation on the authenticator to derive the MSK and EMSK keys
that will be exported to the lower layers.
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 3: EAP-FRM Exchange when a Backend Server is required
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.
It is worthy noting that, whereas EAP-FRM enables the transport of
authentication data, the conveyed authentication information is
required to provide a fast processing and reduced number of messages
in order to obtain a single round-trip between the authenticator and
the backend server in the worst case.
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.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 8]
Internet-Draft EAP-FRM March 2011
Additionally, in Appendix B and Appendix C, we describe an example
about how EAP-FRM can transport a FRP whose design is based on ERP
and another example based on Kerberos [RFC4120] as FRP, respectively.
3. EAP-FRM Format
3.1. EAP-FRM Packet Format
The packet format for the EAP-FRM messages (depicted in Figure 4)
follows the EAP packet format defined in [RFC3748]. The Code,
Identifier and Length fields are common to any EAP message. The Type
field contains the EAP method type value (TBD) corresponding to EAP-
FRM. Following, the data field includes a single-octet FRP-Type
field which identifies the transported FRP followed by an optional
payload field consisting of a set of TLVs (Type-Length-Value field)
which, for example, contains the specific data of the FRP.
Next, we provide a detailed description of each field and detail the
different values that can be used.
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 4: 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.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 9]
Internet-Draft EAP-FRM March 2011
o FRP-Type: The FRP-Type is 1-octet field which identifies the
transported fast re-authentication protocol. So far next FRPs
have 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:
* 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 PDU of the FRP.
* Auth-Server TLV. It contains the backend server's NAI or FDQN
that manages the current EAP authenticator.
* User-Id TLV. This TLV, destined to transport the user's NAI,
is primarily used for routing purposes. The user's NAI is
allowed to be truncated or modified by, for example, omitting
the name portion of the 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
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 10]
Internet-Draft EAP-FRM March 2011
* KDF TLV. This TLV contains the KDF that the 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.
(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 within 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
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 11]
Internet-Draft EAP-FRM March 2011
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.
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 5 summarizes the TLVs defined in EAP-FRM and
indicates which TLVs MAY or MAY NOT be found in the EAP-FRM messages,
and the quantity. In both EAP-Request/FRM and EAP-Response/FRM, 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.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 12]
Internet-Draft EAP-FRM March 2011
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 |0-1| 0 | 0 | 0 | 0 | 0 |
| User-Id | 0 | 0 | 0 |0-1|0-1|0-1|
| Auth | 0 |0-1|0-1| 0 |0-1|0-1|
| Integrity-Algorithm |0-1| 0 | 0 |0-1| 0 | 0 |
| KDF |0-1| 0 | 0 |0-1| 0 | 0 |
+---------------------+---+---+---+---+---+---+
Figure 5: TLVs defined in EAP-FRM
As observed, the first EAP-Request/FRM message sent by the EAP server
is expected to contain a pseudo-random value generated by the EAP
server within the Nonce TLV. Optionally, this initial message may
contain the following TLVs: a FRP-Payload TLV transporting the first
FRP message; an Auth-Server TLV indicating the NAI or FQDN of the
backend server controlling the target authenticator; an Integrity-
Algorithm TLV used by the authenticator to indicate the integrity
algorithm that will be used to compute the AUTH TLV in future
messages, and a KDF TLV used by the authenticator to suggest a
specific function to generate the EAP-FRM key hierarchy.
The first EAP-Response/FRM message is also expected to contain a
nonce generated by the peer in the Nonce TLV. Recall that, as
explained in Section 4, the nonces exchanged in the first EAP-
Request/FRM and EAP-Response/FRM are used to generate the Method-Id
identifier which, in turn, is necessary to generate the EAP-FRM key
hierarchy. Similarly to the first EAP-Request/FRM message, the first
EAP-Response/FRM message can optionally contain the following TLVs: a
FRP-Payload TLV containing the first FRP payload generated by the
peer; an User-Id TLV to indicate the authenticator the specific
domain to which the authentication data should be routed; an
Integrity-Algorithm TLV used by the authenticator to confirm the
integrity algorithm that will be used to compute the AUTH TLV in
future messages, and a KDF TLV used by the peer to confirm the key
derivation function that will be used to generate the EAP-FRM key
hierarchy.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 13]
Internet-Draft EAP-FRM March 2011
After these initial messages, a set of intermediary EAP-Request/FRM
and EAP-Response/FRM messages are exchanged between the peer and
server. On the one hand, intermediary EAP-Request/FRM messages may
contain a FRP-Payload TLV. On the other hand, intermediary EAP-
Response/FRM messages may contain not only FRP-Payload TLV but also
User-Id TLV to specify where the FRP message should be routed.
Additionally, once the FRP exports a valid rMSK, the Auth TLV may be
used to integrity protect EAP-FRM messages. As depicted in Figure 5,
the same behaviour described for the intermediary EAP-Request/FRM and
EAP-Response/FRM messages is also valid for the final ones.
8. Implementation Framework
In the following we show the implementation framework of our
solution. Basically, as Figure 6 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
authentication 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 |
| | | | | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+- +-+-++-+-+
| | | |
+----------->-----------+ +------>------+
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 14]
Internet-Draft EAP-FRM March 2011
Figure 6: 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.
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 2010. Thanks also to
the Funding Program for Research Groups of Excellence with code
04552/GERM/06 also granted by the Seneca Foundation. We would also
like to thank Yoshihiro Ohba for his review and valuable comments.
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.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 15]
Internet-Draft EAP-FRM March 2011
12.2. Informative References
[3PFH] Marin-Lopez, R., Pereniguez GarcAa, F., Bernal-Hidalgo,
F., and A. Gomez, "Secure three-party key distribution
protocol for fast network access in EAP-based wireless
networks. Elservier Computer Networks, Volume 54, Issue
15, October 2010 pp. 2651-2673", 2010.
[KRB] Marin-Lopez, R., Pereniguez GarcAa, F., Ohba, Y., Bernal-
Hidalgo, F., and A. Gomez, "A Kerberized Architecture for
Fast Re-authentication in Heterogeneous Wireless Networks.
Springer Mobile Networks and Applications, Volume 15,
Number 3 June 2010 pp. 392-412", 2010.
[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
Ubiquitous Systems: Computing, Networking and Services
(MOBIQUITOUS 2007) , 2007.", 2007.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[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.
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication
Protocol (EAP) Early Authentication Problem Statement",
RFC 5836, April 2010.
[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/".
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 16]
Internet-Draft EAP-FRM March 2011
[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, three new attributes are defined: 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 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 7: 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 8: RADIUS FRP-Id Attribute
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 17]
Internet-Draft EAP-FRM March 2011
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 9: 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
FRP-Payload-Attr) which transport 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 10: 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 |
+-+-+-+-+-+-+-+-+
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 18]
Internet-Draft EAP-FRM March 2011
Figure 11: 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 12: Diameter FRP-Payload-Attr AVP
Appendix B. Use Case Example 1: 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 13 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 September 29, 2011 [Page 19]
Internet-Draft EAP-FRM March 2011
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 13: 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 September 29, 2011 [Page 20]
Internet-Draft EAP-FRM March 2011
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 signaling shown in
previous section, except that now the home ER server must be
contacted. Figure 14 shows the signaling involved in our
architecture taking into account an ERP-based FRP that includes
explicit bootstrapping.
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 21]
Internet-Draft EAP-FRM March 2011
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, | | |
| 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 September 29, 2011 [Page 22]
Internet-Draft EAP-FRM March 2011
Figure 14: ERP-based FRP with EAP-FRM (Explicit Bootstrapping)
Appendix C. Use Case Example 2: Kerberos-based Fast Re-authentication
Protocol with EAP-FRM and RADIUS
Basically, in this model, the mobile requests a Kerberos service
ticket (ST) to access the authenticator. As depicted in Figure 15 ,
the authenticator acts as "application service" in the context of
Kerberos. The ST is requested by the mobile to the KDC by means of
KRB_AS_REQ/KRB_AS_REP (1) and KRB_TGS_REQ/KRB_TGS_REP (2) exchanges.
Once the mobile obtains a ST, it moves to the authenticator (3),
which starts EAP-FRM. After the first EAP-Req./FRM message, the
mobile answers with EAP-Resp./FRM including a FRP-Payload with a
KRB_AP_REQ message which contains the ST. If the authenticator
correctly verifies the ST, it sends the EAP Success.
As observed, the authenticator does not need to contact any backend
authentication server in this case, saving the latency involved in
contacting it.
Some performance measurements and different mode of operations are
described in [KRB]
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 23]
Internet-Draft EAP-FRM March 2011
Mobile KDC Authenticator
(EAP Peer) (EAP Server)
----------- ---------------- --------
| (1) KRB_AS_REQ/KRB_AS_REP | |
|<--------------------------> | |
| | |
| (2)KRB_TGS_REQ/KRB_TGS_REP | |
|<--------------------------> | |
| | |
---------------------- | |
| ST for Authenticator | | |
---------------------- |
| |
--------- |
| Handoff | (3) |
--------- |
| |
| EAP-Req./FRM(Nonce) |
|<---------------------------------------------- |
| EAP-Resp./FRM(Nonce, User-Id[cname@crealm], |
| FRP-Payload[KRB_AP_REQ(ST)]) |
|----------------------------------------------->|
| EAP-Success() |
|<-----------------------------------------------|
| |
Figure 15: Kerberos-based FRP with EAP-FRM. Handoff Operation.
Appendix D. 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 16 shows the testbed used
for running the implementation. Moreover, Figure 17 shows an
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 24]
Internet-Draft EAP-FRM March 2011
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 16: EAP-FRM Deployed Testbed
+--------+----------------+----------------+------------------------+
| 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 17: Execution Output (Authenticator View)
NOTE: For the prototype, the FRP described in [3PFH] 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].
Marin-Lopez(Ed.), et al. Expires September 29, 2011 [Page 25]
Internet-Draft EAP-FRM March 2011
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
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 September 29, 2011 [Page 26]