Network Working Group R. Marin-Lopez Internet-Draft F. Pereniguez-Garcia Intended status: Experimental F. Bernal-Hidalgo Expires: January 7, 2010 A. Gomez-Skarmeta University of Murcia July 6, 2009 Architecture for Fast EAP Re-authentication based on a new EAP method (EAP-FRM) working on standalone mode draft-marin-eap-frm-fastreauth-00 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 January 7, 2010. Copyright Notice Copyright (c) 2009 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, et al. Expires January 7, 2010 [Page 1] Internet-Draft EAP-FRM July 2009 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 and AAA Protocol Extensions . . . . . . . . . . 7 3.1. EAP-FRM packet format . . . . . . . . . . . . . . . . . . 7 3.2. AAA extensions . . . . . . . . . . . . . . . . . . . . . . 8 4. Capabilities negotiation . . . . . . . . . . . . . . . . . . . 11 5. Use Case Example: ERP-based Fast Re-authentication Protocol with EAP-FRM . . . . . . . . . . . . . . . . . . . . 11 5.1. Fast re-authentication phase . . . . . . . . . . . . . . . 11 5.2. Bootstrapping phase . . . . . . . . . . . . . . . . . . . 13 6. Some implementation details . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Marin-Lopez, et al. Expires January 7, 2010 [Page 2] Internet-Draft EAP-FRM July 2009 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 provoke 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 Marin-Lopez, et al. Expires January 7, 2010 [Page 3] Internet-Draft EAP-FRM July 2009 propose an architecture for fast EAP re-authentication based on the design of a new EAP method named EAP-FRM. These 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 media independence property. o Minimum extension to AAA protocols is needed. When an AAA protocol is used between the authenticator and a backend authentication server, a new AAA attribute needs to be defined 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 it 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 server sends key material and other information associated with the key material back to the authenticator. The protocol used for conveying the FRP messages between the authenticator and the backend Marin-Lopez, et al. Expires January 7, 2010 [Page 4] Internet-Draft EAP-FRM July 2009 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 is processed by the authenticator. Figure 1: EAP-FRM Architecture Figure 2 shows a general example asumming 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 any FRP designed will generate cryptographic material. If the FRP is performed in the backend authentication server, the backend authentication server will send the generated cryptographic material to the authenticator. In particular, this cryptographic material 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 that will be exported to the lower-layers. Note that a well designed FRP should only involve one roundtrip with the backed authenticator server at the most. Marin-Lopez, et al. Expires January 7, 2010 [Page 5] Internet-Draft EAP-FRM July 2009 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) | | |<----------------------------| | | | | | | | 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 bootstrapped after performing an initial EAP authentication with any EAP method that is able to export the MSK and EMSK. This is called bootstrapping phase. The FRP designed 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 cryptographic material used by 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 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. Marin-Lopez, et al. Expires January 7, 2010 [Page 6] Internet-Draft EAP-FRM July 2009 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 Figure 1 shows how the fast re-authentication process works with EAP- FRM. 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, 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 the 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-Response/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. Additionally, we explain the extensions which are required in RADIUS and Diameter to transport the FRP between the authenticator and the backend authentication server. Additionally, in Section 5, we describe an example about how EAP-FRM can transport a FRP whose design is based on ERP. 3. EAP-FRM Format and AAA Protocol Extensions 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]. Marin-Lopez, et al. Expires January 7, 2010 [Page 7] Internet-Draft EAP-FRM July 2009 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. TBD. o FRP-Type: The FRP-Type is 1-octet field which identifies the transported fast re-authentication protocol (TBD). 0. Reserved 1. ERP-based 2. ... 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 data field. The length field indicates the length of the data field in number of octets. Next, there are some TLVs initially considered: * FRP-Payload TLV. It contains the specific payload of the FRP. * Auth-Server TLV. It contains a backend server's NAI or FDQN. Included in first EAP-Request/FRM message, it refers to the backend authentication server that manages the current EAP authenticator. * User-Id TLV. It contains the user's NAI. 3.2. AAA extensions If the authenticator is not able to process the FRP payload sent by the peer within an EAP-Response/FRM, it needs to contact an AAA server to process the FRP. Thus, the FRP must be carried from the Marin-Lopez, et al. Expires January 7, 2010 [Page 8] Internet-Draft EAP-FRM July 2009 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 attribute RADIUS: 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 and the third carries the FRP payload. 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 4: 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 5: RADIUS FRP-Id attribute The FRP-Id will one of the numbers defined for FRP-Type in the EAP- FRM packet. 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 6: RADIUS FRP-Payload-Attr attribute These attributes are included in RADIUS Access-Request and RADIUS Access-Accept. For Diameter, the definition of a new application (Diameter Fast Re- authentication Application) may be required. This application Marin-Lopez, et al. Expires January 7, 2010 [Page 9] Internet-Draft EAP-FRM July 2009 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 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 the new AVPs we have defined. 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 7: 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 8: Diameter FRP-Id AVP The FRP-Id will one of the numbers defined for FRP-Type in the EAP- FRM packet. Marin-Lopez, et al. Expires January 7, 2010 [Page 10] Internet-Draft EAP-FRM July 2009 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 9: Diameter FRP-Payload-Attr AVP 4. 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 negotation in the architecture in future version of this document. 5. Use Case Example: ERP-based Fast Re-authentication Protocol with EAP-FRM 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 in ERP messages 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. 5.1. Fast re-authentication phase Figure 10 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 code) to the peer, containing an Auth-Server TLV. In this example, this TLV Marin-Lopez, et al. Expires January 7, 2010 [Page 11] Internet-Draft EAP-FRM July 2009 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". Mobile Authenticator ER Server (EAP Peer) (EAP Server) (srv.local) ----------- ------------- ------------------ | | | |<--------------------------| | | EAP-Req./FRM(Auth-Server[ | | | local], | | | FRP-Payload[IRS*]) | | | | | |-------------------------->| | | EAP-Resp./FRM(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 10: 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 Marin-Lopez, et al. Expires January 7, 2010 [Page 12] Internet-Draft EAP-FRM July 2009 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. 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 in the authenticator, and the EAP- FRM method will export the rMSK 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 succesful 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 export it 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. 5.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 11 shows the signalling involved in our architecture taking into account an ERP-based FRP that includes explicit bootstrapping. Marin-Lopez, et al. Expires January 7, 2010 [Page 13] Internet-Draft EAP-FRM July 2009 Mobile Authenticator Local Auth. Serv. Home Auth. Serv. (EAP Peer) (EAP Server) (local) (home) ----------- ------------- ----------------- ------------- | | | | |<--------------| | | | EAP-Req/FRM( | | | | Auth-Server[local], | | | FRP-Payload[IRS*]) | | |-------------->| | | |EAP-Resp/FRM( | | | |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()| | | | | | | Figure 11: ERP-based FRP with EAP-FRM (explicit bootstrapping) Marin-Lopez, et al. Expires January 7, 2010 [Page 14] Internet-Draft EAP-FRM July 2009 6. Some implementation details 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 peer EAP Auth Backend Auth. +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Server | (MSK) | | (MSK) |<----+ |EAP-FRM method | |EAP-FRM method |--+ | | | | | | | ! | +-+-+-+-!+-+-+-+- +-+-+-+-+-+-+-+-+ ! | | | | | | | ! MSK | | | | | | ! | | EAP peer | | EAP Auth. | API | | | | | | | ! | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ! | | | | | | | ! | | EAP layer | | EAP layer | ! | | | | | | | V | +-+-+-+-!+-+-+-+- +-+-+-+-++-+-+-+-+-+-+-+ +-+-+-+-+- | V | | V | | MSK | | | Lower layer | | Lower Layer |AAA/IP|<----| AAA/IP | | | | | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+- +-+-++-+-+ | | | | +----------->-----------+ +------>------+ Figure 12: EAP-FRM Implementation Details 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 implementation as Figure 12 shows. 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, a new module has been developed in Free RADIUS. Figure 13 shows the testbed used for running the implementation. Moreover, Figure 14 shows an ethereal trace of an execution. (NOTE: As ethereal has not registered EAP-FRM, it shows the Unknown type). Marin-Lopez, et al. Expires January 7, 2010 [Page 15] Internet-Draft EAP-FRM July 2009 wpa_supplicant (EAP peer) Free RADIUS +------+ +-----+ +-----+ +-----+ | Peer |<------->| pAP |<------->| AR | <-------> | AAA | +------+ +-----+ +-----+ +-----+ ^ | +-----+ | | nAP |<-----------+ +-----+ hostapd (WPA2-802.11i) (EAP auth/server) Figure 13: 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 14: Execution output (authenticator view) NOTE: For the prototype, the FRP described in [Marin07] has been implementated 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, et al. Expires January 7, 2010 [Page 16] Internet-Draft EAP-FRM July 2009 7. 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 tranported fast re- authentication protocol with suitable security properties. 8. IANA Considerations This document has no actions for IANA. 9. 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. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 10.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-08 (work in progress), June 2009. [MQ07] Marin-Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and Marin-Lopez, et al. Expires January 7, 2010 [Page 17] Internet-Draft EAP-FRM July 2009 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. [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/". [wpa_supplicant] "http://hostap.epitest.fi/wpa_supplicant/". 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, et al. Expires January 7, 2010 [Page 18] Internet-Draft EAP-FRM July 2009 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, et al. Expires January 7, 2010 [Page 19]