MIP6 Working Group G. Giaretta Internet Draft I. Guardini Expires: August 2004 E. Demaria TILab February 2004 MIPv6 Authorization and Configuration based on EAP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This draft defines an architecture, and related protocols, for performing dynamic Mobile IPv6 authorization and configuration relaying on a AAA infrastructure. The necessary interaction between the AAA server of the home provider and the mobile node is realized using EAP, exploiting the capability of some EAP methods to convey generic information items together with authentication data. This approach has the advantage that the access equipment acts just as a pass-through for EAP messages and therefore does not play any active role in the Mobile IPv6 negotiation procedure, which makes the solution easier to deploy and maintain. The same approach can be ported also to environments performing user authentication with methods other than EAP (e.g. GSM, UMTS or CDMA), by simply using PANA with null authentication to undertake MIPv6 negotiation after the user has gained IP access to the network. Giaretta Guardini Demaria Expires - August 2004 [Page 1] Internet-Draft MIPv6 Authorization based on EAP January 2004 Table of Contents 1. Introduction................................................2 2. Protocol Overview...........................................3 3. Detailed Description of the Protocol........................6 3.1 Mobile Node bootstrap....................................7 3.2 Management of reauthentication events...................15 3.3 Session Termination.....................................16 4. Home Agent considerations..................................19 4.1 Service Authorization Cache (SAC).......................19 4.2 Management of Binding Cache entries.....................19 5. Protocol Applicability in Cellular Networks................20 6. New Messages and Attributes................................24 6.1 New EAP-TLVs............................................24 6.2 New Diameter messages and AVPs..........................29 7. Open Issues................................................31 8. Security Considerations....................................32 Acknowledgments.................................................32 References......................................................32 Appendix A - Home Agent allocation in a foreign domain..........34 Authors' Addresses..............................................37 Intellectual Property Statement.................................37 1. Introduction Mobile IPv6 [1] requires that Mobile Nodes (MNs) and Home Agents (HAs) share a set of configuration parameters: for example, the MN must know its Home Address, the Home Agent Address and the cryptographic material needed to protect MIPv6 signaling (e.g. shared keys or certificates to setup an IPsec security association). MIPv6 base protocol does not specify any method to automatically acquire this information; which means that network administrators are normally required to manually set configuration data on MNs and HAs. Manual configuration of Home Agents and Mobile Nodes also works as an implicit method for Mobile IPv6 authorization, because only the users that have been administratively enabled on a specific Home Agent are allowed to exploit Mobile IPv6 and its features. However, in a large network (e.g. the network of a mobile operator), which may include millions of users and many Home Agents, the operational and administrative burden of this procedure may easily become overwhelming. In addition, the extensive use of manual and static configurations limits the flexibility and reliability of the system, in that it is not possible to dynamically assign the HA when the user enters the network, which would help to optimize performance Giaretta Guardini Demaria Expires - August 2004 [Page 2] Internet-Draft MIPv6 Authorization based on EAP January 2004 and resource utilization (e.g. assignment of the HA closest to the MN's point of attachment). With the objective to solve the limitations described above, this draft defines an architecture, and related protocols, for performing dynamic Mobile IPv6 authorization and configuration relaying on a AAA infrastructure. The necessary interaction between the AAA server of the home provider and the mobile node is realized using EAP, exploiting the capability of some EAP methods, and in particular PEAPv2 [2], to convey generic information items together with authentication data. The suggested approach can be deployed, with no changes to existing access equipment (Access Points, Access Gateways, etc.), in any network supporting EAP-based authentication (e.g. IEEE 802.1x Wireless LANs), but can be ported also to environments performing user authentication with methods other than EAP (e.g. GSM, UMTS or CDMA), by simply using PANA [9] with null authentication to undertake MIPv6 negotiation after the user has gained IP access to the network. 2. Protocol Overview The basic idea behind the solution proposed herewith is to perform Mobile IPv6 authorization and configuration during the authentication procedure undertaken by the Mobile Node to gain network access. In particular, this draft defines a method to: - explicitly authorize the use of Mobile IPv6 based on the service profile of the user, its position within the network, etc. - dynamically allocate a Home Agent to the Mobile Node; - dynamically configure Mobile IPv6 start-up parameters on both the Home Agent and the Mobile Node. These parameters include the Home Address and the cryptographic material needed to set-up the IPsec Security Association used to protect Mobile IPv6 signaling (i.e. Binding Updates and Binding Acknowledges); - allow the MN to negotiate additional Mobile IPv6 service options, such as the possibility to use multiple access networks at the same time (i.e. registration of multiple Care-of Addresses), the assignment of a HA within the visited domain, etc. Figure 1 shows the overall architecture of the solution proposed in this draft. The central element of the architecture is the AAA server of the Home Domain (i.e. AAAH), which interacts with both the MN and the selected HA to perform service authorization and configuration. Giaretta Guardini Demaria Expires - August 2004 [Page 3] Internet-Draft MIPv6 Authorization based on EAP January 2004 AAA Client IEEE 802.1x +------+ RADIUS or PANA | | or Diameter +--------+ /---------------TLS Tunnel------------------\ +--------+ | Mobile |/ <------------Authentication---------------> \| AAAH | | Node |\ <--MIPv6 authorization and configuration--> /| Server | +--------+ \-------------------------------------------/ +--------+ | | /\ +------+ /||\ Router || or AP Diameter || (pass-through) HA Appl. || \||/ \/ +--------+ | Home | | Agent | +--------+ Figure 1 - Solution architecture The solution can be deployed in any access network where EAP [3] and, in particular, PEAPv2 [2] are used to perform user authentication; this is because the messages exchanged between the MN and the AAAH server to achieve dynamic Mobile IPv6 authorization and configuration are carried in EAP-TLVs (i.e. information fields in the form of Type Length Value) delivered within the TLS tunnel created in the phase 1 of PEAPv2. Anyway, the same approach could be ported to any other EAP method having the capability to establish a secure tunnel between the MN and the AAAH server (e.g. EAP-TTLS [4]). Figure 2 shows an overview of the procedure defined to handle MIPv6 bootstrap on the Mobile Node. The whole procedure can be divided in five steps: 1.EAP identity exchange (i.e. exchange of EAP Request Identity and EAP Response Identity messages); 2.PEAPv2 Phase 1: MN and AAAH establish a TLS tunnel to protect subsequent authentication data. This phase is completely conformant to [2]; 3.PEAPv2 Phase 2: MN and AAAH negotiate an EAP method (e.g. EAP-MD5, EAP-SIM, EAP-AKA) and undertake the authentication phase. Then, within the TLS tunnel, MN and AAAH exchange a sequence of EAP-TLVs to authorize and configure Mobile IPv6. During this phase, AAAH selects a suitable Home Agent for the MN and exchanges Giaretta Guardini Demaria Expires - August 2004 [Page 4] Internet-Draft MIPv6 Authorization based on EAP January 2004 authorization and configuration data with it using a new Diameter Application. At the end of this phase, the MN knows its own Home Address, the address of the correspondent Home Agent and the cryptographic material (e.g. pre-shared key) needed to set-up an IPsec security association with IKE; 4.EAP session termination (EAP Success/Failure); 5.set-up of IPsec Security Association and MIPv6 registration: at the end of the EAP communication, the MN gains network access and acquires a valid Care-of Address within the visited subnet (e.g. stateless autoconfiguration); then, using the cryptographic material collected in PEAPv2 phase 2, it performs an IKE exchange to establish the IPsec Security Association with the HA. Finally, the MN performs MIPv6 registration, sending a Binding Update (protected with IPsec) to the HA. EAP over IEEE 802.1x EAP over Diameter Diameter (or PANA) (or RADIUS) AAAH HA Application MN +----------+ AP +-----------------+ Server +-----------------+ HA 1) <--Req. Id.--- --Identity---> --Diameter EAP Req.--> /----------------------------------\ 2) / PEAPv2 Phase 1: \ \ set-up of TLS tunnel / \----------------------------------/ /----------------------------------\ +-+ /------------------\ +-+ 3) / PEAPv2 Phase 2: authentication \| |/ Home Address \| | \ and Mobile IPv6 negotiation /| |\ Selection /| | \----------------------------------/ +-+ \------------------/ +-+ Home Agent DAD Selection 4) <-----EAP----- <-----Diameter EAP---- Success/Failure Answer (Success/Failure and authorization AVPs) /-----------------------------------------------------------\ 5) / Set-up Security Association MN-HA and \ \ Mobile IPv6 registration (BU, BA) / \-----------------------------------------------------------/ Figure 2 - Overview of Mobile IPv6 bootstrap procedure This draft also defines the procedures to handle re-authentication events and to manage the termination of the Mobile IPv6 session. Giaretta Guardini Demaria Expires - August 2004 [Page 5] Internet-Draft MIPv6 Authorization based on EAP January 2004 In summary, the proposed architecture has the following advantages: - allows the operator to maintain a centralized management (on the AAA server) of the user profiles and the authentication, authorization and accounting procedures for any type of service, including Mobile IPv6; - improves the reliability and performance of the Mobile IPv6 protocol, in that the HA to be dynamically assigned to the MN can be freely chosen among those that are closest to the user's point of attachment, thus optimizing network usage and reducing the transfer delay for data traffic in bi-directional tunneling; - can be deployed, or extended with new features, without having to update the access equipment and the AAA protocols in use. Only minor changes in the AAA servers, the Home Agents and the mobile terminals are required, in that the AAA client does not play any active role in MIPv6 negotiation (i.e. it is a pass-through for EAP signaling). This reduces the deployment costs and makes the solution easy to use even when a Mobile Node is roaming with a provider different from its own; - allows the usage of any AAA protocol supporting the transport of EAP messages for the communication between the AAA client and server (i.e. not just Diameter, but also RADIUS). This significantly simplifies the deployment of the arrangement described herein in existing communication networks, where support for Diameter protocol in access equipment is not so extensive. Conversely, the drawback of the solution is the high number of RTTs needed for the completion of the entire procedure. This limitation is mainly due to the choice of relaying on a tunneled EAP method (such as PEAPv2) for exchanging protected signaling related to MIPv6 during the authentication phase. Nevertheless, it should be noted that the full procedure can be undertaken by the MN only during its initial bootstrap, and therefore the performance requirements are not so strict. 3. Detailed Description of the Protocol This section details all the procedures and message exchanges that can be used by the network operator to explicitly authorize the activation of Mobile IPv6 support for a specific user as well as enable dynamic negotiation of MIPv6 protocol parameters (e.g. Home Address, Home Agent Address). Giaretta Guardini Demaria Expires - August 2004 [Page 6] Internet-Draft MIPv6 Authorization based on EAP January 2004 For the sake of simplicity, protocol description is carried out assuming that the access network is a Wireless LAN IEEE 802.11 where user authentication is performed at Layer 2 through IEEE 802.1x and EAP. However, the same approach can be deployed in any other network using EAP for access control. 3.1 Mobile Node bootstrap In a WLAN where IEEE 802.1x and EAP are used for access control, when the MN enters the network it immediately receives an EAP Request Identity message. This message is used to start the EAP communication. The MN replies sending its identity, in the form of a NAI (Network Access Identifier), within an EAP Response Identity message, that is received by a local attendant (i.e. the Access Point in the case of a WLAN) and forwarded to AAAH using the Diameter EAP Application (or the RADIUS EAP extensions). Then the AAAH server selects an EAP method (e.g. based on the user service profile) and proposes it to the MN in subsequent EAP messages. In order to use the MIPv6 negotiation procedure defined in this document, the EAP method chosen by the AAAH server must be PEAPv2 or another tunneled EAP method supporting the transport of optional information fields. After this initial handshake, MN and AAAH establish a TLS tunnel exchanging PEAPv2 phase 1 messages. The procedure is the same specified in [2] and the Access Point acts as a simple pass-through for all the signaling transferred, on an end-to-end basis, between the MN and the AAA server. As soon as the TLS tunnel is established, the actual authentication phase takes place and all messages exchanged between MN and AAAH are encrypted through the TLS Security Association. The authentication can be based on any EAP method (e.g. EAP-MD5, EAP-SIM, EAP-AKA): the choice can be done based on the desired security level and keeping in mind that the EAP method affects the number of RTTs needed to accomplish the authentication. The authentication procedure performed within the TLS tunnel (i.e. inner authentication) can be divided in three main steps: 1.Identity Exchange: exchange of EAP Identity Request/Reply messages; 2.Authentication Algorithm: this is the real authentication procedure. The number of round trips (RTTs) needed to complete this phase depends on the EAP method chosen to perform inner authentication; Giaretta Guardini Demaria Expires - August 2004 [Page 7] Internet-Draft MIPv6 Authorization based on EAP January 2004 3.Authentication Result: in the last round trip, AAAH sends to the MN the result of the authentication procedure (success/failure) and the MN confirms the reception of this notification. PEAPv2 phase 2 messages exchanged within the TLS tunnel are conveyed in EAP-TLVs, according to the latest version of PEAPv2 specification. As soon as the authentication phase is completed (i.e. MN has received an EAP Response message containing an Intermediate-Result- TLV), the procedure for Mobile IPv6 authorization and parameter negotiation takes place. This is achieved exploiting the TLS tunnel to exchange a sequence of EAP messages containing a new TLV, called MIPv6-Authorization-TLV (see section 6.1), that is a very generic TLV containing other, more specific, TLVs. AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- Authorization-TLV including the following TLVs: - Service-Status-TLV: used to communicate to the MN whether the Mobile IPv6 service is actually available, or unavailable, in the visited location; this might depend on characteristics of the visited domain, on the user service profile or on other administrative rules (e.g. service accountability); - Service-Options-TLV (optional): used to specify other service options the MN can ask for (possibility to register multiple CoAs, allocation of a HA in the visited domain, etc.). See Appendix A for an example. MN replies to this first message confirming its intention to start Mobile IPv6 and, optionally, providing a set of hints on the desired service capabilities; this is achieved delivering a MIPv6- Authorization-TLV including the following TLVs: - Service-Selection-TLV: used by the MN to specify if it is willing to activate Mobile IPv6 protocol operation; - Service-Options-TLV (optional): used by the MN to communicate which service options, among those previously advertised by AAAH, it would like make use of; - Home-Agent-Address-TLV (optional): used by the MN to suggest a preferred Home Agent (e.g. a HA with whom the MN has a pre- configured Security Association). The AAAH server treats this indication just as a hint, which means that, for administrative reasons, the MN may be assigned a Home Agent different from the one previously requested; Giaretta Guardini Demaria Expires - August 2004 [Page 8] Internet-Draft MIPv6 Authorization based on EAP January 2004 - Home-Address-TLV (optional): used by the MN to suggest a preferred Home Address (e.g. an address pre-configured on one of its network interfaces); like the previous TLV, this indication is considered only as a hint by the AAAH; - Interface-Identifier-TLV (optional): through this TLV, the MN can suggest a preferred Interface Identifier (selected according to [5] or following other criteria) to be used by the AAA infrastructure to build the Home Address starting from the selected home prefix. Also in this case, this information, if present, is treated as a pure hint by AAAH. The whole message exchange is depicted in Figure 3. For the sake of simplicity, the diagram shows only the content of the EAP-TLVs exchanged within the TLS tunnel in place between the MN and AAAH server. PEAPv2 Diameter TLS Tunnel AAAH HA Application MN +----------------------------+ Server +---------------------+ HA <--------------------- EAP-TLV(MIPv6-Authorization-TLV( Service-Status, [Service-Options])) -----------------------> EAP-TLV(MIPv6-Authorization-TLV( Service-Selection, [Service-Options], [Home-Agent-Address], [Home-Address], [Interface-Identifier])) Figure 3 - Mobile IPv6 authorization: initial handshake If in the Service-Selection-TLV the MN has chosen not to make use of Mobile IPv6, AAAH immediately terminates the EAP communication skipping any further MIPv6 negotiation. Otherwise, if the MN has confirmed its willingness to start MIPv6 service, AAAH selects a suitable Home Agent through a Home Agent Selection Algorithm. Possible parameters to be taken into account by this algorithm include: current load of available HAs, location of the MN and, eventually, the preferences provided by the MN itself in the previous message exchange (i.e. Service-Options-TLV, Home-Agent- Address-TLV, Home-Address-TLV). However, the detailed definition of a Home Agent Selection Algorithm is out of the scope of this document. As soon as a suitable HA has been identified, AAAH interacts with it to dynamically configure all the state needed to enable subsequent Giaretta Guardini Demaria Expires - August 2004 [Page 9] Internet-Draft MIPv6 Authorization based on EAP January 2004 MIPv6 protocol operations. The communication between AAAH and HA is achieved through a new Diameter Application defined in this document, that is called Diameter Home Agent Application and is similar to the one specified in [6]. AAAH starts the handshake sending to the designated HA a Diameter Home Address Request (HAR) message containing the following AVPs: - User-Name-AVP: specifies the MN's identity, that is the NAI provided by the user while executing the inner EAP method; - Home-Address-AVP or Interface-Identifier-AVP (optional): specify the Home Address, or the Interface Identifier, provided by the MN in the correspondent TLVs (i.e. Home-Address-TLV and Interface- Identifier-TLV); - HA-Features-AVP (optional): lists the additional features that the HA is required to provide to the mobile node (e.g. support for the registration of multiple CoAs). The content of this AVP is set by the AAAH server based on the negotiation undertaken with the MN through the Service-Options-TLV. When the HA receives the message, it picks up a Home Address for the MN, generating an Interface Identifier based on [5] or using the hints included in the Home-Address-AVP (or in the Interface- Identifier-AVP). Then the HA undertakes the Duplicate Address Detection (DAD) procedure to verify the uniqueness of the selected Home Address. If DAD fails (i.e. an address duplication is detected on the home link), the HA selects another Home Address for the MN and repeats the whole DAD procedure. If this operation fails for three times in a row, the Home Agent sends to the AAAH a Diameter Home Address Answer (HAA) message with Result-Code equal to FAILURE. At this stage, AAAH can try to assign another HA or close the negotiation sending to the MN a Service-Status-TLV stating that the Mobile IPv6 service is not active and not available (see section 6.1). If DAD is completed successfully, the HA uses proxy Neighbor Discovery to defend the Home Address on the home link but does not begin to intercept data packets addressed to it until a valid Binding Update (BU) is received from the MN (see section 4). Then the HA replies to AAAH delivering a Diameter Home Address Answer (HAA) containing the following AVPs: - User-Name-AVP: as usual it includes the NAI of the MN; - Home-Address-AVP: specifies the Home Address that the Home Agent has allocated to the MN. Giaretta Guardini Demaria Expires - August 2004 [Page 10] Internet-Draft MIPv6 Authorization based on EAP January 2004 Figure 4 depicts the exchange of HAR and HAA messages in the case the Home Address selection procedure carried out by the HA terminates without errors. PEAPv2 Diameter TLS Tunnel AAAH HA Application MN +----------------------------+ Server +---------------------+ HA +-+ |O| +-+ Home Agent Selection ----------------------> Home-Address-Request( User-Name, [HA-Features], [Home-Address], [Interface-ID]) <----------------------- Home-Address-Answer( User-Name, Home-Address) Figure 4 - Mobile IPv6 authorization: Home Address selection AAAH also acts as Key Distribution Center, delivering to MN and HA the cryptographic data needed to bootstrap the IPsec Security Association for protecting subsequent Mobile IPv6 signaling. For this reason, after the reception of the designated Home Address from the HA, AAAH continues the handshake sending to the HA a Diameter Home Agent Configuration Request (HACR) message containing the following AVPs: - User-Name-AVP: the NAI of the MN; - Authorization-Lifetime-AVP: it is the authorization lifetime (in seconds) of the Mobile IPv6 service granted to the MN; - IKE-Bootstrap-Information-AVP: this AVP specifies the peer authentication method to be used for IKE phase 1 (Pre-Shared key, certificates, etc.) and the related parameters (e.g. value of the pre-shared key and its lifetime). This is all the information the HA needs to negotiate the IPsec Security Association with the MN. This draft specifies in detail only the approach based on a Pre- shared Key (PSK); Giaretta Guardini Demaria Expires - August 2004 [Page 11] Internet-Draft MIPv6 Authorization based on EAP January 2004 - Policy-AVP (optional): contains some filtering rules (e.g. access lists) to be enforced by the HA on the traffic the MN transmits and/or receives in bi-directional tunneling. Once the HA has stored these data in its Service Authorization Cache (see section 4.1), it sends to AAAH a Diameter Home Agent Configuration Answer (HACA) containing a Result-Code-AVP used to confirm the success (or failure) of the procedure (see Figure 5). PEAPv2 Diameter TLS Tunnel AAA HA Application MN +---------------------------+ Server +----------------------+ HA +-+ |O| +-+ IKE Configuration Selection -----------------------> HA-Configuration-Request( User-Name, Auth. Lifetime, IKE-Bootstrap-Info, [Policy]) <----------------------- HA-Configuration-Answer( User-Name, Result-Code) Figure 5 - Mobile IPv6 authorization: HA configuration At this stage, the HA is ready to accept future MIPv6 registrations coming from the MN. Therefore, AAAH can restart the EAP session with the MN communicating to it all the MIPv6 configuration data it is waiting for. This is achieved delivering to the MN an EAP Request containing a MIPv6-Authorization-TLV including the following TLVs: Home-Address-TLV (i.e. the home address), Home-Agent-Address-TLV (i.e. the address of the HA), IKE-Bootstrap-Information-TLV (i.e. the information needed to bootstrap the IKE session with the HA). As soon as it receives this message, the MN stores all the configuration data and sends back an EAP Reply containing a Negotiation-Result-TLV, stating whether it accepts, or refuses, the proposed configuration (see Figure 6). If the MN refuses the configuration, AAAH should immediately release the resources previously allocated on the HA. To complete this task, AAAH sends a Diameter Abort Session Request (ASR) message to the Home Agent (see paragraph 3.3). Giaretta Guardini Demaria Expires - August 2004 [Page 12] Internet-Draft MIPv6 Authorization based on EAP January 2004 PEAPv2 Diameter TLS Tunnel AAAH HA Application MN +----------------------------+ Server +---------------------+ HA <--------------------- EAP-TLV(Result-TLV, Crypto-Binding-TLV, MIPv6-Authorization-TLV( Home-Address, HA-Address, IKE-Bootstrap-Info)) -----------------------> EAP-TLV(Result-TLV, Crypto-Binding-TLV, MIPv6-Authorization-TLV( Negotiation-Result)) Figure 6 - Mobile IPv6 authorization: MN configuration To terminate the EAP session, AAAH sends to the Access Point a Diameter EAP Answer message with Result-Code equal to SUCCESS and, optionally, other authorization AVPs containing some filtering rules to be enforced on MN's traffic (see Figure 7). EAP Over EAP over Diameter 802.1x Diameter AAA HA Application MN +---------+ AP +------------+ Server +----------------------+ HA <------------------- Diameter-EAP-Answer( Result-Code-AVP(Success), EAP-Payload-AVP(EAP-Success), [Authorization AVPs]) +-+ |O| Enforcement of +-+ authorization rules <------------- EAP-Success Figure 7 - Termination of the EAP session After the completion of the EAP session, MN holds all data needed to perform Mobile IPv6 registrations: the MN knows its Home Address, the address of the correspondent Home Agent and all cryptographic material needed to establish the IPsec security association with it; furthermore, since it has been successfully authenticated, the MN is receiving Router Advertisements on the visited subnet and can build its Care-of Address through IPv6 stateless autoconfiguration. Giaretta Guardini Demaria Expires - August 2004 [Page 13] Internet-Draft MIPv6 Authorization based on EAP January 2004 The first operation carried out by the MN after the acquisition of the Care-of Address is the establishment of the IPsec Security Association with the HA, that is mandated by [1] to protect MIPv6 location update signaling. Set-up of the IPsec SA can be accomplished following the procedure detailed in [7]. In this regard, it is important to note that: - if the mutual authentication in IKE Phase 1 is based on a Pre- Shared Key (PSK), Aggressive Mode must be used. This is because Aggressive Mode is the only way to use PSK authentication with a NAI as peer identifier [8]. Indeed, the NAI of the MN is the only identity information stored in the Service Authorization Cache of the HA; - in IKE phase 1 messages, the source address used by the MN has to be the Care-of Address, as described in [7]; the Home Address is used only in IKE phase 2; - in IKE phase 2 (Quick Mode), while still using the CoA as source address of IKE messages, the MN has to use the Home Address as its peer identifier, so that the HA can correctly set the MN entries in its Security Policy Database (SPD) and in the Security Association Database (SAD). As soon as the IPsec Security Association is established, MN can send a Binding Update to the HA, thus starting up Mobile IPv6 service (Figure 8). AAA MN +--------+ AP +--------------+ Server +---------------------+ HA /------------------------------------------------------------\ / IKE Phase 1 \ \ Aggressive Mode (2 RTT) / \------------------------------------------------------------/ /------------------------------------------------------------\ / IKE Phase 2 \ \ Quick Mode (1 + 1/2 RTT) / \------------------------------------------------------------/ --------------------------------------------------> MIPv6 Binding Update <-------------------------------------------------- MIPv6 Binding Acknowledge Figure 8 - IKE Negotiation and MIPv6 Registration Giaretta Guardini Demaria Expires - August 2004 [Page 14] Internet-Draft MIPv6 Authorization based on EAP January 2004 Considering the usage of an inner EAP method involving 2 round trips (e.g. EAP-AKA), the bootstrap procedure described in the foregoing requires a total of 13.5 round trips (RTTs) to be completed: 9 RTTs for authentication and Mobile IPv6 negotiation, 3.5 RTTs for setting up the IPsec SA (i.e. IKE) and 1 RTT for MIPv6 registration (i.e. BU, BA). However, since the whole procedure may be performed only at the MN bootstrap (e.g. when the terminal is switched on), the time requirements are not critical. Nonetheless, a number of optimization steps can be introduced in order to make the whole procedure faster. The PEAPv2 protocol provides for several tasks to be performed simultaneously by conveying the correspondent message exchanges in different TLV types, all delivered through the TLS tunnel in place between MN and AAAH. Exploiting this feature, the negotiation procedure for the MIPv6 service can be performed in partial or complete superposition with the authentication procedure. This optimization leads to saving 2 round trips. Additionally, the time for the HA to complete the DAD procedure may be partially or totally absorbed within the authentication procedure. 3.2 Management of reauthentication events At the expiration of AAA session time-outs or after a change in the point of attachment to the network (involving or not involving an IP handoff), a re-authentication procedure is performed leading to the user identity to be checked again along with its right to continue exploitation of network resources. To that purpose the AAAH server may repeat a full authentication or, alternatively, decide to use optimizations in order to make the procedure faster. Once this phase is completed the AAA server also undertakes the re-negotiation of the Mobile IPv6 service, communicating with the MN through the TLS tunnels established in PEAPv2 phase 1. The actual protocol behavior and message exchange may vary depending on the service state of the mobile node. If the MIPv6 service is not currently active for the MN, AAAH behaves exactly as in the bootstrap phase (see section 3.1) and proposes the activation of the service from scratch as if the MN was performing its first authentication within the visited network. Instead, if the MIPv6 service is already active, AAAH informs the MN about the current MIPv6 service status, including the respective service options negotiated during the bootstrap phase. AAAH performs this operation delivering a MIPv6-Authorization-TLV including the Service-Status-TLV and the Service-Options-TLV. The mobile node may respond in two different ways: Giaretta Guardini Demaria Expires - August 2004 [Page 15] Internet-Draft MIPv6 Authorization based on EAP January 2004 - by means of a Negotiation-Result-TLV with result code equal to SUCCESS, to indicate that the service configuration is wished to be maintained unchanged, - or by means of a MIPv6-Authorization-TLV with the desired modifications (including the eventual request to stop the MIPv6 service), to undertake the full or partial re-negotiation of the MIPv6 service. As a whole, the described re-authentication procedure takes 10 round trips, assuming that the employed EAP method requires 2 round trips (e.g. EAP-AKA) and the Mobile Node has undertaken an IP handoff without asking for any change in the service configuration. Consequently, 3.5 round trips are saved in comparison with the bootstrap phase, in that the MN already shares an IPsec Security Association with the HA and therefore does not need to repeat the IKE negotiation. The delay involved in completing the re-authentication procedure may be reduced by resorting to the optimization steps already described in the foregoing with reference to the bootstrap phase and, possibly, by exploiting some additional optimizations supported by the PEAPv2 protocol: fast resume of the TLS tunnel and fast reconnect. 3.3 Session Termination Session termination may be triggered by the AAA server or the mobile node. The result is normally the disconnection of the user from the visited network, and, consequently, the release of Mobile IPv6 service and related resources (Home Agent, Home Address, etc.). The AAA server may decide to close the session at any moment, for instance due to credit exhaustion. In general, to interrupt the service, the AAA server delivers to the correspondent AAA client a Diameter Abort Session Request (ASR) message; the AAA client disconnects the user, releases the resources previously allocated to it and confirms the session termination through a Diameter Abort Session Answer (ASA) message. If a plurality of clients are involved in the service provision, the ASR message is sent to all of them. In the specific case of the Mobile IPv6 service, the two Diameter clients involved are the HA and the equipment that is providing access to the network (i.e. the Access Point in case of a Wireless LAN), therefore both receive an ASR message from AAAH (see Figure 9) and enforce immediate user disconnection. Giaretta Guardini Demaria Expires - August 2004 [Page 16] Internet-Draft MIPv6 Authorization based on EAP January 2004 Diameter AAA HA Application MN +--------+ AP +-------------+ Server +----------------------+ HA <------------------- Diameter-Abort-Session-Request( User-Name-AVP) --------------------> Diameter-Abort-Session-Request( User-Name-AVP) ------------------> Diameter-Abort-Session-Answer( Result-Code-AVP) <------------------------ Diameter-Abort-Session-Answer( Result-Code-AVP) Figure 9 - MIPv6 service termination triggered by AAAH In the case the MN wishes to disconnect, it sends an EAPOL-Logoff message toward the Access Point which in turn communicates the end of the session to the AAA server via the Diameter Session Termination Request (STR) message, while simultaneously releasing the resources involved. At the reception of the STR message, the AAA server releases the resources allocated on the HA exchanging Abort Session Request and Answer messages with it, while sending a corresponding Diameter Session Termination Answer message toward the AP. The AAA server may possibly decide to adopt different policies for releasing the resources (e.g. depending the user service profile). For instance, the AAA server may decide not to release the resources on the HA in order to allow the MN to exploit the Mobile IPv6 service even when it moves to network for which no roaming agreements exist (e.g. a corporate network or a network providing free and cost-free access). In that case, the MN can continue to use the IPsec SA previously negotiated with the HA and respective authorization is managed by means of the MIPv6 Authorization Lifetime (see Diameter HACR message). Once this lifetime expires (but it may even be infinite), the HA should send a Diameter Authorization Refresh Request message to the AAAH server asking for a confirmation of the authorization (see Figure 10). Giaretta Guardini Demaria Expires - August 2004 [Page 17] Internet-Draft MIPv6 Authorization based on EAP January 2004 Diameter AAA HA Application MN +--------+ AP +-------------+ Server +----------------------+ HA +-+ |O| +-+ Authorization Lifetime Expiration <------------------- Diameter-Authorization- Refresh-Request(User- Name-AVP) --------------------> Diameter-Authorization- Refresh-Answer(User-Name-AVP, Result-Code-AVP, [Authorization-Lifetime-AVP]) Figure 10 - Diameter Authorization Refresh Request/Answer In some circumstances, it might be desirable for the mobile node to terminate the MIPv6 service only (and stop being charged for that), while maintaining uninterrupted access to the visited network. Relaying on the architecture described in the previous sections, this result can be achieved in two different ways: - the MN can wait till the next re-authentication event (usually triggered by the network) and perform the re-negotiation of the whole MIPv6 protocol operation (see section 3.2), - or the MN can decide to stop sending Binding Updates to the HA, causing the expiration of the correspondent entry in the Binding Cache. This is interpreted by the HA as the MN's willingness to stop using the Mobile IPv6 protocol. Therefore, the HA, behaving similarly to a standard Network Access Server (NAS), sends a Diameter Session Termination Request to the AAA server and, after the reception of the correspondent Session Termination Answer, releases all the resources previously allocated to the MN (i.e. the Home Address and the entry in its Service Authorization Cache). Giaretta Guardini Demaria Expires - August 2004 [Page 18] Internet-Draft MIPv6 Authorization based on EAP January 2004 4. Home Agent considerations This section details some specific features and data structures that have to be supported by the Home Agent to allow dynamic negotiation of Mobile IPv6 protocol parameters during mobile node network attachment. 4.1 Service Authorization Cache (SAC) The Home Agent is required to store some authorization data for each of the MNs it is serving. A new data structure, called Service Authorization Cache (SAC), is used for this purpose. Each entry in the SAC should contain at least the following fields: - NAI of the user: it is derived from the User-Name-AVP included by AAAH in all the Diameter messages addressed to the HA; - Home Address: it is the Home Address (checked against DAD) that the HA has dynamically assigned to the MN during the Mobile IPv6 bootstrap phase; - Authorization Lifetime: it is the authorization lifetime of the Mobile IPv6 service granted to the MN. AAAH selects this lifetime according to administrative rules and specifies it in the Authorization-Lifetime-AVP. Before the expiration of this lifetime, the HA may send a Diameter Authorization Refresh Request (ARR) message to AAAH asking for an extension (i.e. renewal) of the authorization; - Authentication Mode: it is the authentication mode to be used in IKE Phase 1 for setting up the IPsec SA with the MN. This draft specifies in detail only the approach based on a Pre-shared Key (PSK); - Cryptographic Data: this field includes all the information to be used for IKE bootstrap. The actual content of this record depends on the Authentication Mode chosen for IKE Phase 1: if Pre-shared Key is used for this purpose, this field includes the PSK value and its lifetime. 4.2 Management of Binding Cache entries The selection of the Home Address to be assigned to the MN at the end of the MIPv6 bootstrap phase is performed by the designated Home Agent at the reception of the Diameter Home Address Request (HAR) message from the AAAH server. Immediately after the completion of this procedure, the HA is required to start defending the Home Giaretta Guardini Demaria Expires - August 2004 [Page 19] Internet-Draft MIPv6 Authorization based on EAP January 2004 Address (i.e. proxy Neighbor Discovery), even if it has not yet received any Binding Update from the MN. This behavior is not completely conformant with the Mobile IPv6 specification and has to be treated carefully to avoid protocol failures on the HA. In particular, the following anomaly might happen: - at the end of the MIPv6 authorization and negotiation process (i.e. the MN has completed the EAP communication and has been explicitly authorized to use MIPv6 from its current point of attachment), the MN sends a Binding Update (BU) message to register its Care-of Address on the HA; - the Home Agent receives the BU from the MN and, following the MIPv6 protocol standard, checks the Home Address included in it against DAD. Since the HA is already defending that Home Address, DAD might happen to fail, blocking Mobile IPv6 functionality on the MN. To avoid this problem, when the HA starts defending the Home Address allocated to the MN (i.e. immediately before replying to AAAH with the Diameter Home Address Answer message), it should also register it in its binding cache, creating a new entry where the Care-of Address, that is still unknown, is initially set to unspecified (::) and the correspondent lifetime is set to the MIPv6 authorization lifetime. In this way, when the HA receives the first Binding Update from the MN, the message is treated as an update of an existing entry in the Binding Cache and therefore DAD is not performed. In order for this procedure to work properly, the MN has to send a BU to the HA as soon as it is granted IPv6 access to the visited subnet (i.e. at the end of EAP authentication). If the visited subnet happens to be on the home link, the MN should send to the HA a BU with binding lifetime equal to 0, to make sure it cleans up the dummy entry in its binding cache and stops defending the home address. 5. Protocol Applicability in Cellular Networks Using the Mobile IPv6 protocol and the services offered thereby may be desirable particularly to handle mobile node movements across a multi-access environment, involving both WLANs and 3GPP radio networks (i.e. vertical handoff). This scenario, in fact, is becoming increasingly popular, due to the massive deployment of WLAN hot-spots in public indoor areas like airports and hotels. In cellular networks (e.g. GPRS, UMTS), access control and IP address assignment are managed relaying on protocols that are specific of cellular infrastructures (for instance, SS7/MAP), and therefore do not natively support the use of EAP. For this reason, in such Giaretta Guardini Demaria Expires - August 2004 [Page 20] Internet-Draft MIPv6 Authorization based on EAP January 2004 environments the Mobile IPv6 authorization and configuration procedure described in the previous sections can not be employed as is, but must be properly adapted. The proposed solution is based on the assumption that the MN performs Mobile IPv6 service negotiation interacting with a AAA server supporting Diameter, which remains logically unchanged regardless of the access technology being used (i.e. WLAN or cellular). Additionally, this AAA server must support a communication interface towards the authentication center of the cellular operator (i.e. HLR/AuC), but the details about this interaction are outside the scope of this document. When the MN enters a GPRS or UMTS data network, based on layer 2 signaling procedures specific of cellular environments, it is assigned an IP address (v4 or v6) by activating a so called PDP Context. This corresponds to establishing a direct layer 3 communication channel between the MN and the GGSN (GPRS Gateway Support Node), that is basically the first router on the path towards any external IP cloud (e.g. the Internet). At this stage, to perform MIPv6 negotiation as described in the previous sections, it is necessary to establish an additional communication channel based on EAP over the existing IP transport (i.e. over the PDP Context). This can be achieved activating a PANA [9] session between the MN and the GGSN, used for the sole purpose of authorizing and configuring (or re-negotiating, if it was already active) the Mobile IPv6 service. This procedure consists of the exchange of MIPv6 TLVs transported directly over EAP (i.e. exchange of EAP messages with EAP-Type equal to EAP-TLV). In this case, there is no need to protect this signaling establishing a TLS tunnel through PEAP, because there is already a secure channel in place between MN and GGSN, provided by the PDP Context. Moreover, it is not necessary to carry out any further authentication procedures, because the user has already been authenticated via HLR/AuC and SS7/MAP. The whole procedure includes the following steps (Figure 11): - GGSN and MN establish a PANA session (PANA-Start-Request/Answer). The communication is triggered by the GGSN message as soon as the PDP Context activation is complete; - GGSN sends to the AAA server a Diameter EAP Request message containing the user identifier (NAI) and an empty EAP packet, indicating the need of starting an EAP exchange. The NAI is constructed directly by the GGSN, that is a trusted node, using the MN credentials collected during the PDP Context activation. Giaretta Guardini Demaria Expires - August 2004 [Page 21] Internet-Draft MIPv6 Authorization based on EAP January 2004 Since these credentials (i.e. essentially the data contained in the SIM/USIM) have already been verified using protocols specific of cellular networks (e.g. SS7/MAP), there is no need to undertake a new authentication phase; - at the reception of the Diameter EAP Request message from the GGSN, the AAA server understands that the MN is already authenticated (e.g. interacting with the HLR/AuC) and starts directly the Mobile IPv6 negotiation phase, sending EAP messages containing solely the MIPv6-Authorization-TLV. The negotiation goes on as already described in section 3.1 for WLAN access. - if the negotiation terminates successfully, the AAA server sends to the GGSN an EAP Success message conveyed within a Diameter EAP Answer; the GGSN forwards this notification to the MN through a PANA-Bind-Request message. Finally, MN closes the exchange replying with a PANA-Bind-Answer. At any time, the MN may request the termination of the PANA session, and consequently the release of the MIPv6 service, by means of a PANA-Termination-Request message sent to the GGSN node. Conversely, the AAA server may discontinue the delivery of the service sending a Diameter Abort Session Request message to the Home Agent. The main advantage of this procedure lies in the possibility of re- using those messages and TLVs defined in section 3.1 even when the MN accesses a cellular network, or, in general, any IP network (wireless or wired) performing user authentication with methods other than EAP. Instead, the drawback is that the GGSN, or, in general, the first router on the outbound routing path, has to support a new feature (i.e. the PANA protocol) and the MIPv6 service negotiation is not carried out together with the user authentication, but as an additional procedure following the MN network attachment. Giaretta Guardini Demaria Expires - August 2004 [Page 22] Internet-Draft MIPv6 Authorization based on EAP January 2004 MN +-------------------------+ GGSN +--------------------------+ AAA /-----PDP Context Act. ------\ \----------------------------/ <----------------- PANA-Start-Request ------------------> PANA-Start-Answer -----------------------> Diameter-EAP-Request( EAP-Payload-AVP(empty), User-Name-AVP) <--------------------------------- Diameter-EAP-Answer(EAP-Payload-AVP(EAP- Request/EAP-Type=EAP-TLV(MIPv6-Authorization-TLV (Service-Status,[Service-Options])))) <---------------------- PANA-Auth-Request(EAP-Request) --------------------------> PANA-Auth-Answer(EAP-Response/EAP-Type=EAP-TLV (MIPv6-Authorization-TLV(Service-Selection, [Service-Options]))) -------------------> Diameter-EAP-Request +-+ HA select. |O| and config. +-+ <--------------------------------- Diameter-EAP-Answer(EAP-Payload-AVP( EAP-Request/EAP-Type=EAP-TLV(MIPv6 Authorization-TLV(Home-Address HA-Address,IKE-Bootstrap-Info)))) <----------------- PANA-Auth-Request( EAP-Request) ------------------> PANA-Auth-Answer(EAP-Response/EAP-Type= EAP-TLV(MIPv6-Authorization-TLV (Negotiation-Result))) -------------------> Diameter-EAP-Request <-------------------------- Diameter-EAP-Answer( EAP-Payload-AVP(EAP-Success)) <--------------------- PANA-Bind-Request(EAP-Success) ------------------> PANA-Bind-Answer Figure 11 - MIPv6 service authorization in 3GPP networks Giaretta Guardini Demaria Expires - August 2004 [Page 23] Internet-Draft MIPv6 Authorization based on EAP January 2004 6. New Messages and Attributes 6.1 New EAP-TLVs The general format of an EAP-TLV is depicted in Figure 12 [10]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 - Generic TLV format TLVs defined in this draft are: - MIPv6-Authorization-TLV. This is a generic TLV which carries all TLVs related to MIPv6 authorization and configuration. It is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 - Non-mandatory TLV R Reserved, set to zero (0) Type TBD - MIPv6-Authorization Length The length of the Value field in octets Value This field carries the subsequent TLVs Giaretta Guardini Demaria Expires - August 2004 [Page 24] Internet-Draft MIPv6 Authorization based on EAP January 2004 - Service-Status-TLV. This TLV is sent by the AAAH to inform the MN about the status of Mobile IPv6 service. It is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Service-Status | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | +-+-+-+-+-+-+-+-+ Type TBD - Service-Status Length 1 Code 0 = MIPv6 service is not active and not available 1 = MIPv6 service is not active but available 2 = MIPv6 service is active but no more available 3 = MIPv6 service is active and available - Service-Selection-TLV. This TLV is sent by the MN to inform the AAAH whether it accepts the AAAH proposal. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Service-Selection | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | +-+-+-+-+-+-+-+-+ Type TBD - Service-Selection Length 1 Code 0 = MN accepts configuration options proposed by AAAH 1 = activate MIPv6 service Giaretta Guardini Demaria Expires - August 2004 [Page 25] Internet-Draft MIPv6 Authorization based on EAP January 2004 2 = re-negotiate MIPv6 service 3 = deactivate MIPv6 service - Service-Options-TLV. So far only two service options are defined: the multiple registration option and the HA in visited network option. This TLV is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Service-Options | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Service-Options Length 2 H 1 - The MN is requesting a HA in the visited network M 1 - The MN is requesting multiple registration functionalities Reserved 14 bit reserved set to 0 - Home-Agent-Address-TLV. It is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=HA-Address | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Home Agent Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Giaretta Guardini Demaria Expires - August 2004 [Page 26] Internet-Draft MIPv6 Authorization based on EAP January 2004 Type TBD - Home-Agent-Address Length 16 Value Home Agent Address - Home-Address-TLV. It is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Home-Address | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Home Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Home-Address Length 16 Value Home Address - IKE-Bootstrap-Information-TLV. This TLV carries data related to IKE bootstrap; the generic format is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=IKE-Bootstrap-Info | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth. Type | IKE Phase 1 Mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Information... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Giaretta Guardini Demaria Expires - August 2004 [Page 27] Internet-Draft MIPv6 Authorization based on EAP January 2004 Type TBD - IKE-Bootstrap-Information Length Depending on Authentication Type Value Authentication Type The authentication method to be used in IKE Phase 1 IKE Phase 1 Mode The mode to be used in IKE Phase 1 Authentication Information This field contains cryptographic material to setup the security association. The figure below depicts the IKE-Bootstrap-Information-TLV when PSK is used as Authentication Type. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=IKE-Bootstrap-Info | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSK | Aggressive Mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - IKE-Bootstrap-Information Length 8 + Key length Giaretta Guardini Demaria Expires - August 2004 [Page 28] Internet-Draft MIPv6 Authorization based on EAP January 2004 Value Authentication Type PSK IKE Phase 1 Mode Aggressive Mode Authentication Information Key Lifetime - the lifetime of the PSK Key Value - the value of the PSK - Negotiation-Result-TLV. It is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Result | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result-Code | +-+-+-+-+-+-+-+-+ Type TBD - Result Length 1 Value 0 - Success 128 - Failure 6.2 New Diameter messages and AVPs In this draft a new Diameter Application, called Home Agent Diameter Application, is proposed. The complete and detailed definition of the application is outside the scope of this document; even so, this section lists all new Diameter messages and AVPs introduced. Giaretta Guardini Demaria Expires - August 2004 [Page 29] Internet-Draft MIPv6 Authorization based on EAP January 2004 The Diameter messages defined are: - Home Address Request. This message is sent by AAAH to the HA to request a Home Address; it includes these AVPs: o User-Name-AVP o Home-Address-AVP (optional) o Interface-Identifier-AVP (optional) o HA-Features-AVP (optional) - Home Address Answer. Through this message the Home Agent sends to AAAH the parameters it has reserved for a particular MN; it includes these AVPs: o User-Name-AVP o Home-Address-AVP - Home Agent Configuration Request. AAAH sends this message to the HA to give some information related to MIPv6 service activation; it includes these AVPs: o User-Name-AVP o Authorization-Lifetime-AVP o IKE-Bootstrap-Information-AVP o Policy-AVP (optional) - Home Agent Configuration Answer. Through this message the HA gives to AAAH the result of MIPv6 configuration procedure; it includes these AVPs: o User-Name-AVP o Result-Code-AVP - Authorization Refresh Request. The HA sends this message to AAAH when the Authorization Lifetime is going to elapse, requesting whether the user is still authorized to use MIPv6. It includes these AVPs: o User-Name-AVP - Authorization Refresh Answer. Through this message, AAAH specifies whether the MN is still authorized to use MIPv6. If the user is no longer authorized, the lifetime in Authorization-Lifetime-AVP is set to 0. It includes these AVPs: o User-Name-AVP o Result-Code-AVP o Authorization-Lifetime-AVP (optional) - Foreign Home Agent Request. AAAH sends this message to AAAF to request a Home Agent allocation. o User-Name-AVP o Home-Agent-Address-AVP (optional) o HA-Features-AVP (optional) o Home-Address-AVP (optional) Giaretta Guardini Demaria Expires - August 2004 [Page 30] Internet-Draft MIPv6 Authorization based on EAP January 2004 o Interface-Identifier-AVP (optional) o Authorization-Lifetime-AVP (optional) o Policy-AVP (optional) - Foreign Home Agent Answer. AAAF sends this message to AAAH to give it the parameters related to MIPv6 activation. o User-Name-AVP o Home-Agent-Address-AVP o Home-Address-AVP o Authorization-Lifetime-AVP o IKE-Bootstrap-Information-AVP Diameter AVPs defined in this document are: - Home-Address-AVP. This AVP is of type IPAddress and the Data field contains a Home Address. - Home-Agent-Address-AVP. This AVP is of type IPAddress and the Data field contains the address of a Home Agent. - Interface-Identifier-AVP. This AVP is of type OctetString and the Data field contains an Interface Identifier that the MN can provide as a hint for Home Address selection on the HA. - IKE-Bootstrap-Information-AVP. This AVP is of type OctetString and contains data related to IKE bootstrap. The Data field has the same structure of the Value field defined for the IKE-Bootstrap- Information-TLV. - HA-Features-AVP. This AVP (type to be defined) carries information about specific features requested on the designated Home Agent (e.g. support for registration of multiple CoAs). - Policy-AVP. This AVP is of type IPFilterRule and defines a set of access lists to be enforced by the HA on the traffic generated by the mobile node. 7. Open Issues Possible areas for future work are: - the usage of the AAA infrastructure, in place of IKE, to bootstrap the IPsec SA between the MN and the HA. This could be useful to reduce the number of round trips required for the completion of the MIPv6 negotiation procedure; - the exploitation of the EAP Key Management Framework [11] to allow the mobile node to derive the Pre-Shared Key used for IKE phase 1. Giaretta Guardini Demaria Expires - August 2004 [Page 31] Internet-Draft MIPv6 Authorization based on EAP January 2004 This might improve the security of the architecture, in that it would not be necessary any more for the AAA server to send the PSK over the air (even if within a protected TLS tunnel); - the extension of the architecture to support the usage of digital certificates, in addition to PSK, for peer authentication in IKE phase 1; - a deeper analysis of the issues related to the interface between AAA server and HLR/AuC for the execution of the MIPv6 negotiation procedure in cellular networks. 8. Security Considerations The Mobile IPv6 authorization and configuration exchange between the mobile node and the AAA server of the home domain is protected by a TLS tunnel established using PEAPv2. Therefore the level of security of this communication is the same of PEAPv2 message exchanges. The interaction between the AAA server and the designated Home Agent is based on Diameter, which means that it is protected using IPsec or TLS, as specified by the Diameter base protocol. Acknowledgments The authors would like to thank Simone Ruffino (of Telecom Italia Lab) for his feedback and suggestions. References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. [2] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2", draft-josefsson-pppext-eap-tls-eap-07 (work in progress), October 2003. [3] Blunk, L. et al., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-07 (work in progress), November 2003. Giaretta Guardini Demaria Expires - August 2004 [Page 32] Internet-Draft MIPv6 Authorization based on EAP January 2004 [4] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-03 (work in progress), August 2003. [5] Narten, T., Draves, R., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [6] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter Mobile IPv6 Application", draft-le-aaa-diameter- mobileipv6-03 (expired), April 2003. [7] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June 2003. [8] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [9] Forsberg, D. et al., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-02 (work in progress), October 2003. [10] Hiller, T., Palekar, A., Zorn, G., "A Container Type for the Extensible Authentication Protocol (EAP)", draft-hiller-eap- tlv-01, May 2003. [11] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., " EAP Key Management Framework", draft-ietf-eap-keying-01.txt, October 2003. Giaretta Guardini Demaria Expires - August 2004 [Page 33] Internet-Draft MIPv6 Authorization based on EAP January 2004 Appendix A - Home Agent allocation in a foreign domain Whenever the mobile node is switched on inside a foreign domain (i.e. roaming scenario), it may be worthwhile assigning it a local Home Agent provided by the visited provider, rather than allocating a distant HA in the home domain. This may be useful to optimize network usage and reduce transfer delay for data traffic in bi-directional tunneling. The decision on the preferred position of the HA is taken by the AAAH server, either autonomously (e.g. based on the user profile or on other administrative policies) or negotiating with the MN through the Service-Options-TLV. In the latter case, the negotiation procedure is undertaken as follows: - in the first MIPv6-Authorization-TLV sent over the TLS tunnel established with PEAPv2, the AAAH server includes, together with the Service-Status-TLV, a Service-Options-TLV with the bit H set to 1, meaning that the allocation of a HA within the foreign domain is actually supported by the home provider; - if the MN wants to exploit this feature, it responds sending a MIPv6-Authorization-TLV including, in addition to the mandatory Service-Selection-TLV, a Service-Options-TLV with the bit H set to 1, as a confirmation of its preference for the assignment of a local HA within the foreign domain. The rest of the procedure for bootstrapping MIPv6 protocol operation on the MN is carried out essentially as already described for the allocation of a HA inside the home domain (see section 3.1). The only major difference is that the AAAH server cannot perform HA selection and configuration by its own but has to interact with the AAA server of the foreign domain (i.e. AAAF). As a whole, the procedure undertaken by the AAAH server to obtain and configure a HA inside the foreign domain is based on the following steps (see Figure 13): - AAAH sends a Diameter Foreign Home Agent Request (FHAR) message to AAAF, indicating the user's NAI in the User-Name-AVP. Optionally, AAAH may insert other AVPs including the configuration hints eventually provided by the MN (HA-Address-AVP, Home-Address-AVP and Interface-Identifier-AVP), the additional features required on the HA (HA-Features-AVP), the desired authorization lifetime to be set on the designated HA (Authorization-Lifetime-AVP) and the filtering rules to be enforced on the traffic generated by the mobile node (Policy-AVP); Giaretta Guardini Demaria Expires - August 2004 [Page 34] Internet-Draft MIPv6 Authorization based on EAP January 2004 - based on the information included in the request message, AAAF determines whether it can assign a HA within the local domain. In case the allocation is not possible (e.g. for administrative policies), or none of the available HAs actually supports the requested features (e.g. possibility to register multiple CoAs), AAAF replies with a Diameter Foreign Home Agent Answer (FHAA) message including a Result-Code-AVP set to FAILURE. In that case AAAH continues MIPv6 negotiation allocating a HA within the home domain. Instead, if AAAF can satisfy the request, it immediately determines a suitable Home Agent to be allocated to the MN using a Home Agent Selection Algorithm; - at this stage AAAF communicates with the selected HA using the same approach already described in section 3.1, based on the usage of Diameter Home Agent Request/Answer and Home Agent Configuration Request/Answer messages; - once the designated HA is properly configured (i.e. at the reception of the HACA message), AAAF delivers to AAAH a Diameter Foreign Home Agent Answer message including, in correspondent AVPs, all the information needed to activate the MIPv6 protocol operation on the MN (i.e. HA address, Home Address, Authorization Lifetime and IKE bootstrap information). Giaretta Guardini Demaria Expires - August 2004 [Page 35] Internet-Draft MIPv6 Authorization based on EAP January 2004 Diameter Diameter AAAH HA Application AAAF HA Application Server +-----------------------+ Server +----------------------+ HA ------------------> Foreign-Home-Agent-Request(User-Name, [Home-Agent-Address],[Home-Address], [Interface-ID],[HA-Features], [Auth. Lifetime],[Policy]) +-+ |O| +-+ Home Agent Selection ----------------------> Home-Address-Request( User-Name, [HA-Features], [Home-Address], [Interface-ID]) <----------------------- Home-Address-Answer( User-Name, Home-Address, [IKE-Bootstrap-Info]) +-+ |O| +-+ IKE Configuration Selection -----------------------> HA-Configuration-Request( User-Name, Auth. Lifetime, IKE-Bootstrap-Info, [Policy]) <----------------------- HA-Configuration-Answer( User-Name, Result-Code) <------------------ Foreign-Home-Agent-Answer(User-Name, Home-Agent-Address,Home-Address, Auth. Lifetime,IKE-Bootstrap-Info, [Policy]) Figure 13 - Allocation of a Home Agent in the foreign domain Giaretta Guardini Demaria Expires - August 2004 [Page 36] Internet-Draft MIPv6 Authorization based on EAP January 2004 Authors' Addresses Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2286904 Email: gerardo.giaretta@telecomitalia.it Ivano Guardini Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2285424 Email: ivano.guardini@telecomitalia.it Elena Demaria Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2285403 Email: elena.demaria@telecomitalia.it Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Giaretta Guardini Demaria Expires - August 2004 [Page 37] Internet-Draft MIPv6 Authorization based on EAP January 2004 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Giaretta Guardini Demaria Expires - August 2004 [Page 38]