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]