Network Working Group R. Marin-Lopez(Ed.) Internet-Draft F. Pereniguez-Garcia(Ed.) Intended status: Experimental F. Bernal-Hidalgo Expires: January 27, 2011 A. Gomez-Skarmeta University of Murcia July 26, 2010 Architecture for Fast EAP Re-authentication based on a new EAP method (EAP-FRM) working on standalone mode draft-marin-eap-frm-fastreauth-02 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 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 27, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 1] Internet-Draft EAP-FRM July 2010 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 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 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 . . . . . . . . . . . . . . . 7 3. EAP-FRM Format . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . 15 Appendix B. Use Case Example 1: 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. Use Case Example 2: Kerberos-based Fast Re-authentication Protocol with EAP-FRM and RADIUS . 21 Appendix D. Prototype Implementation . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 2] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 3] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 4] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 5] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 6] Internet-Draft EAP-FRM July 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 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. Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 7] Internet-Draft EAP-FRM July 2010 3. EAP-FRM Format 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 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: Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 8] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 9] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 10] Internet-Draft EAP-FRM July 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-1|0-1| 0 |0-1|0-1| | Integrity-Algorithm | 0 |0-1|0-1| 0 |0-1|0-1| | KDF |0-1| 0 | 0 |0-1| 0 | 0 | +---------------------+---+---+---+---+---+---+ Figure 4: TLVs defined in EAP-FRM Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 11] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 12] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 13] Internet-Draft EAP-FRM July 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. [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. [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/". [monet-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. [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/". Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 14] Internet-Draft EAP-FRM July 2010 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 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 Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 15] Internet-Draft EAP-FRM July 2010 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 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. Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 16] Internet-Draft EAP-FRM July 2010 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 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 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 January 27, 2011 [Page 17] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 18] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 19] Internet-Draft EAP-FRM July 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 January 27, 2011 [Page 20] Internet-Draft EAP-FRM July 2010 Figure 13: 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. Therefore, 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 [monet-krb] Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 21] Internet-Draft EAP-FRM July 2010 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 14: 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 15 shows the testbed used for running the implementation. Moreover, Figure 16 shows an Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 22] Internet-Draft EAP-FRM July 2010 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 15: 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 16: 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]. Marin-Lopez(Ed.), et al. Expires January 27, 2011 [Page 23] Internet-Draft EAP-FRM July 2010 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 January 27, 2011 [Page 24]