Network Working Group Y. El Mghazli Internet-Draft Alcatel Expires: December 10, 2006 J. Bournelle GET/INT J. Laganier DoCoMo Euro-Labs June 8, 2006 MPA using IKEv2 and MOBIKE draft-yacine-preauth-ipsec-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 10, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes how to achieve media-independent pre- authentication (MPA) in the context of network accesses protected by IPsec. In such environments, access is protected by an IPsec tunnel mode security association (SA) established between a client of the network and an access gateway. This SA normally needs to be El Mghazli, et al. Expires December 10, 2006 [Page 1] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 established by running an IKE exchange between the two SA endpoints. The duration of this IKE exchange make it impractical to use when the node is mobile and frequently change either its location or its access gateway during a handover. In most case it is expected that real time traffic will be impacted by the handover. This note describes a method that alleviate this issue by leveraging on the IKEv2 Mobility and Multihoming Protocol (MOBIKE). The described method supresses the need to run a full IKE exchange after each handover, thereby greatly reducing the impacts of handovers on real- time traffic. Table of Contents 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Media Pre-Authentication Framework . . . . . . . . . . . . 5 2.2. IKEv2 and MOBIKE overview . . . . . . . . . . . . . . . . 5 2.2.1. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. IPsec protection in the access network . . . . . . . . . . 6 3. MPA with IKEv2 and MOBIKE . . . . . . . . . . . . . . . . . . 7 3.1. First Step: IKEv2 pre-authentication . . . . . . . . . . . 7 3.2. Completing MPA with MOBIKE . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 El Mghazli, et al. Expires December 10, 2006 [Page 2] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 1. Terminology and Definitions Most of the terms are extracted from [I-D.ohba-mobopts-mpa-framework] and [I-D.ietf-mobike-protocol]. Media-independent Pre-Authentication Mobile Node (MN): A mobile terminal of media-independent pre-authentication (MPA) which is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. An MPA mobile node is an IP node. In this document, the term "mobile node" or "MN" without a modifier refers to "MPA mobile node". An MPA mobile node usually has a functionality of a mobile node of a mobility management protocol as well. Candidate Target Network (CTN): A network to which the mobile may move in the near future. Gateway (GW): In this document, a Gateway is an Access Router using IKEv2. IPsec TIA Inner Address of the IPsec Tunnel. IPsec TOA Outer Address of the IPsec Tunnel. Target Network (TN): The network to which the mobile has decided to move. The target network is selected from one or more candidate target network. Proactive Handover Tunnel: A bidirectional IP tunnel that is established between the MPA mobile node and an access router of a candidate target network. In this document, the term "tunnel" without a modifier refers to "proactive handover tunnel". Care-of Address: El Mghazli, et al. Expires December 10, 2006 [Page 3] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 An IP address used by a mobility management protocol as a locator of the MPA mobile node. El Mghazli, et al. Expires December 10, 2006 [Page 4] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 2. Introduction 2.1. Media Pre-Authentication Framework One of the current goal in IP based network is to achieve seamless handover. While it exists solutions at layer 2 or IP level, the authentication process is most of the time not considered. The document [I-D.ohba-mobopts-mpa-framework] introduces a framework to achieve this goal by relying on pre-authentication. This means the mobile authenticates to a candidate target network before attaching to it. The proposed framework is the following (extracted from [I-D.ohba- mobopts-mpa-framework]): 1. The Mobile establish a Security Association with a Candidate Target Network (CTN) to secure subsequent protocol signalling. 2. It securely executes a configuration protocol to obtain an IP address and other parameters from the CTN. 3. It executes a tunnel management protocol to establish a Proactive Handover Tunnel (PHT) (i.e. a bidirectionnal tunnel between the MN and an access router of the CTN). 4. Through this PHT, the MN can send and receives IP packets including signaling messages for the Mobility Management Protocol. As a consequence, it can receives IP data packets resulting from this new binding. 5. Finally, it deletes or disables the PHT immediatly before attaching to the CTN. Then it reassigns the inner address of the PHT to the physical interface immediatly after the MN is attached to the CTN. In this document, we propose a solution for MPA based on IKEv2 and MOBIKE. 2.2. IKEv2 and MOBIKE overview 2.2.1. IKEv2 The IKEv2 protocol [RFC4306] mutually authenticate two peers (named Initiator and Responder) in order to dynamically and securely establish IPsec SAs. It can be divided in two main phases. In the first phase called IKE_SA_INIT, the two peers establish an IKE SA (Security Association) to protect subsequent messages. In the second phase, called IKE_AUTH, the two peers authenticate each other and El Mghazli, et al. Expires December 10, 2006 [Page 5] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 start to configure IPsec SAs. If others IPsec SAs are needed, they use the CREATE_CHILD_SA exchange which relies on previous authenticated IKE SA. The two main features of interest for this document are: 1. The IKEv2 specification allows the Responder to authenticate Initiator by using the EAP protocol [RFC3748]. This permits to the Responder to rely on a AAA server to authenticate the Initiator. Note that Initiator authenticates the responder based on public-key based mechanism. 2. The IKEv2 allows to establish an IPsec tunnel between the Initiator and the Responder to protect data traffic. 2.2.2. MOBIKE The MOBIKE protocol [I-D.ietf-mobike-protocol] is an extension of IKEv2. It allows to change an IP address associated with IKEv2 and an IPsec tunnel to change without reusing IKEv2 from scratch. This feature is particulary useful to achieve an efficient MPA with IKEv2. 2.3. IPsec protection in the access network In such environments, access is protected by an IPsec tunnel mode security association (SA) established between a client of the network and an access gateway. This SA normally needs to be established by running an IKE exchange between the two SA endpoints. The duration of this IKE exchange make it impractical to use when the node is mobile and frequently change either its location or its access gateway during a handover. In most case it is expected that real time traffic will be impacted by the handover. Examples of access networks typically protected by IPsec are 3G/WLAN interworking technologies, namely UMA [UMA] and I-WLAN [I-WLAN]. El Mghazli, et al. Expires December 10, 2006 [Page 6] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 3. MPA with IKEv2 and MOBIKE This document describes a method to achieve media-independent pre- authentication (MPA) in the context of network accesses protected by IPsec. This method alleviates the issues of long delays involved with running a complete IKE exchange after handover by leveraging on the IKEv2 Mobility and Multihoming Protocol (MOBIKE). It does so by supressing the need to run a full IKE exchange after each handover, thereby greatly reducing the impacts of handovers on real-time traffic. The solution is to pre-establish a pre-handover IPsec tunnel mode (PHT) SA with the access gateway; When a handover occurs, the mobile node use MOBIKE to update the outer address of the tunnel, thereby transforming the PHT into a regular Access Tunnel. Thus, combining MOBIKE and Pre-Authentication allows in this context to reduce the overall IP connectivity re-establishment delay to the L2 handoff only. The MPA framework considers the 3 following entities: 1. The Authentication Agent: this entity is responsible of the pre- authentication. 2. The Configuration Agent: this entity is responsible to securely deliver an IP address and other configuration parameters to the mobile node. 3. The Access Router: It is the router with which the Mobile Node establishes a proactive handover tunnel. In the proposed approach, the three following functionalities are handled by the IKEv2 Responder colocated with the Access Router. 3.1. First Step: IKEv2 pre-authentication Initially, the Mobile Node obtains IP connectivity in a access domain. Thanks to a mechanism out-of scope of this document, the Mobile Node discovers a new GW to which it may attach. It starts a pre-authentication procedure with this nGW using IKEv2. This IKEv2 preauthentication procedure has the following goals: o Establish an IPsec tunnel between MN and the nGW. El Mghazli, et al. Expires December 10, 2006 [Page 7] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 o Obtains an address valid in the Candidate Target Network. This is achieved thanks to CFG_REQUEST/CFG_REPLY of IKEv2. This address will be be attached to the physical interface after the Mobile Node attaches to the new access network. As a consequence, after attachment, this new address will be used as the outer address of the tunnel between MN and the nGW and thus must be valid in the new visited access network. The following IKEv2 messages are exchanged between MN and the nGW. These exchanges occur while the Mobile Node is still in the previous access network. Mobile Node new GW ----------- ------ (coa:500 -> nGW:500) ----------------------------------> HDR, SAi1, KEi, Ni (nGW:500 -> coa:500) <---------------------------------- HDR, SAr1, KEr, Nr ----------------------------------> HDR, SK{IDi, [CERTREQ,], CP(CFG_REQUEST) SAi2, TSi, TSr, N(MOBIKE_SUPPORTED)} (MN does not include AUTH to be authenticated by EAP) <---------------------------------- HDR, SK{IDr, [CERT,], AUTH, EAP} ... <---------------------------------- HDR, SK{ EAP (success)} -----------------------------------> HDR, SK{AUTH} <----------------------------------- HDR, SK{AUTH, CP(CFG_REPLY), SAr2, TSi, TSr, N(MOBIKE_SUPPORTED) After IKEv2 preauthentication, the Mobile Node has an IPsec tunnel with the nGW. The IPsec tunnel with nGW has the following header: o IPsec TOA: CoA and nGW El Mghazli, et al. Expires December 10, 2006 [Page 8] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 o IPsec TIA: nCoA and Correspondent Node This IPsec tunnel corresponds to the secure Proactive Tunnel. The Mobile Node can use its Mobility Management Protocol inside this tunnel to indicate its future new location (nCoA). When the MN changes of visited network, the source outer adress is no longer valid. The next section explains how MOBIKE can be used to achieve an efficient handover. The new GW has allocated the nCoA for the Mobile Node which is not yet in its access network. However, it knows that the Mobile Node is supposed to come in its access network. At this point of time, it is not clear if the Mobile Node must indicate in this IKEv2 exchange that it is a pre-authentication. 3.2. Completing MPA with MOBIKE As a result of the IKEv2 preauthentication with nGW, the Mobile has an IKE_SA with the nGW. However, the source outer address of the IPsec tunnel is not valid in nGW's access network. To avoid a complete reauthentication procedure with nGW, we propose to use the MOBIKE protocol. For this purpose, the Mobile Node sends an INFORMATIONAL IKEv2 messages containg an UPDATE_SA_ADDRESSES: Mobile Node nGW ----------- ----------- HDR, SK { N(UPDATE_SA_ADDRESSES), [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)], [N(NO_NATS_ALLOWED)], [N(COOKIE2)] } --> Note that this packet is sent right after the Mobile Node has performed its IP handover and as such the Mobile Node uses its nCoA as source IP address. As it is the nGW which has allocated this nCoA, it can validate this request. Then it updates its IKE_SA with the IP address of the IP header of the IKEv2 message. It replies with an IKEv2 INFORMATIONAL message and finally it updates the IPsec SAs associated with this IKE_SA with the new addresses. If the MOBIKE exchange is successfull, the Mobile Node now has the El Mghazli, et al. Expires December 10, 2006 [Page 9] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 following tunnel with the nGW: o IPsec TOA: nCoA and nGW o IPsec TIA: nCoA and CN This optimized approach recycles the PHT as the IPsec tunnel, which protects the data flows in an IPsec-protected access environment. This avoids the need to re-authenticate with the nGW and re-establish an IPsec tunnel for this purpose. El Mghazli, et al. Expires December 10, 2006 [Page 10] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 4. Security Considerations The security considerations on this proposal need to be further studied. However, because the proposal uses unmodified IKEv2 and MOBIKE protocols in the context of pre-authentication with IPsec protected network accesses, it is believed by the authors that the proposal does not introduce any additional threats neither to the existing IKEv2 and MOBIKE protocols, nor to the architecture which relies on them for network access authentication (e.g. 3GPP IWLAN, UMA). El Mghazli, et al. Expires December 10, 2006 [Page 11] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 5. IANA Considerations This document has no IANA considerations. El Mghazli, et al. Expires December 10, 2006 [Page 12] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 6. Acknowledgements The authors would like to thank Maryline Laurent-Maknavicius and Olivier Marce for useful discussions on this topic. El Mghazli, et al. Expires December 10, 2006 [Page 13] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 7. References 7.1. Normative References [I-D.ietf-mobike-protocol] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", draft-ietf-mobike-protocol-08 (work in progress), February 2006. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 7.2. Informative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.ietf-mobike-design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", draft-ietf-mobike-design-08 (work in progress), March 2006. [I-D.ohba-mobopts-mpa-framework] Ohba, Y., "A Framework of Media-Independent Pre- Authentication (MPA)", draft-ohba-mobopts-mpa-framework-02 (work in progress), March 2006. [I-D.ohba-mobopts-mpa-implementation] Ohba, Y., "Media-Independent Pre-Authentication (MPA) Implementation Results", draft-ohba-mobopts-mpa-implementation-02 (work in progress), March 2006. [I-D.ohba-mobopts-heterogeneous-requirement] Dutta, A., "Problem Statement for Heterogeneous Handover", draft-ohba-mobopts-heterogeneous-requirement-01 (work in progress), March 2006. [I-D.ietf-pana-preauth] Ohba, Y., "Pre-authentication Support for PANA", draft-ietf-pana-preauth-01 (work in progress), March 2006. El Mghazli, et al. Expires December 10, 2006 [Page 14] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 [I-WLAN] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; System description", TS 23.234, December 2005. [UMA] UMA technology, "Unlicensed Mobile Access", Stage 2 Specifications R1.0.4, May 2005. El Mghazli, et al. Expires December 10, 2006 [Page 15] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 Authors' Addresses Yacine El Mghazli Alcatel Route de Nozay Marcoussis 91460 France Email: yacine.el_mghazli@alcatel.fr Julien Bournelle GET/INT 9, rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ El Mghazli, et al. Expires December 10, 2006 [Page 16] Internet-Draft MPA using IKEv2 and MOBIKE June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. El Mghazli, et al. Expires December 10, 2006 [Page 17]