Network Working Group Y. El Mghazli Internet-Draft Alcatel Expires: August 27, 2006 J. Bournelle GET/INT February 23, 2006 MPA using IKEv2 and MOBIKE draft-yacine-preauth-ipsec-00 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 August 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses the details of pre-authentication in a IPsec protected access environment. It describes an optimized solution that avoids re-establishing an IPsec tunnel after the handover, leveraging on IKEv2 and MOBIKE protocol. El Mghazli & Bournelle Expires August 27, 2006 [Page 1] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 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. Initial Step: IKEv2 authentication . . . . . . . . . . . . 7 3.2. First Step: IKEv2 pre-authentication . . . . . . . . . . . 7 3.3. 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 & Bournelle Expires August 27, 2006 [Page 2] Internet-Draft MPA using IKEv2 and MOBIKE February 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 & Bournelle Expires August 27, 2006 [Page 3] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 An IP address used by a mobility management protocol as a locator of the MPA mobile node. El Mghazli & Bournelle Expires August 27, 2006 [Page 4] Internet-Draft MPA using IKEv2 and MOBIKE February 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 & Bournelle Expires August 27, 2006 [Page 5] Internet-Draft MPA using IKEv2 and MOBIKE February 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 This document discusses the specific case where IPsec protection is used systematically in the access segment. This is typically the case in 3G/WLAN interworking technologies, namely UMA [UMA] and I-WLAN [I-WLAN]. Here one or several IPsec tunnels are used to connect the terminal to the mobile operators network. El Mghazli & Bournelle Expires August 27, 2006 [Page 6] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 3. MPA with IKEv2 and MOBIKE The solution described here leverage on MOBIKE extensions to IKEv2 in order to keep the PHT SA for the Access Tunnel. This avoids the need to re-establish new SA after the handover. When coupled with a seamless handover mechanism in the Access network, combining the benefits of MOBIKE and Pre-Authentication in such specific contexts enables to reduce the overall IP connectivity establishment delay to 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. Initial Step: IKEv2 authentication At the beginning, the Mobile Node establish an IPsec tunnel with a Gateway (GW). This GW is located in the Access Router and is collocated with the IKEv2 Responder. In this access network, the mobile node uses the CoA as the address attached to its physical interface. The IPsec tunnel has the following header: o IPsec TOA: CoA and GW o IPsec TIA: CoA and Correspondant Node 3.2. First Step: IKEv2 pre-authentication 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: El Mghazli & Bournelle Expires August 27, 2006 [Page 7] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 o Establish an IPsec tunnel between MN and the nGW. 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: El Mghazli & Bournelle Expires August 27, 2006 [Page 8] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 o IPsec TOA: CoA and nGW 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). Thus, at this point of time, the Mobile Node owns 2 tunnels: one with the current Gateway and one with the new Gateway. While the binding is executed, the Mobile Node is ready to moves in the CTN. 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.3. 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 El Mghazli & Bournelle Expires August 27, 2006 [Page 9] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 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 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 & Bournelle Expires August 27, 2006 [Page 10] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 4. Security Considerations TBD El Mghazli & Bournelle Expires August 27, 2006 [Page 11] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 5. IANA Considerations El Mghazli & Bournelle Expires August 27, 2006 [Page 12] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 6. Acknowledgements The authors would like to thank Maryline Laurent-Maknavicius and Olivier Marce for useful discussions on this topic. El Mghazli & Bournelle Expires August 27, 2006 [Page 13] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 7. References 7.1. Normative References [I-D.ietf-mobike-protocol] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", draft-ietf-mobike-protocol-07 (work in progress), December 2005. [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-07 (work in progress), January 2006. [I-D.ohba-mobopts-mpa-framework] Ohba, Y., "A Framework of Media-Independent Pre- Authentication (MPA)", draft-ohba-mobopts-mpa-framework-01 (work in progress), July 2005. [I-D.ohba-mobopts-mpa-implementation] Ohba, Y., "Media-Independent Pre-Authentication (MPA) Implementation Results", draft-ohba-mobopts-mpa-implementation-01 (work in progress), July 2005. [I-D.ohba-mobopts-heterogeneous-requirement] Dutta, A., "Problem Statement for Heterogeneous Handover", draft-ohba-mobopts-heterogeneous-requirement-00 (work in progress), October 2005. [I-D.ietf-pana-preauth] Ohba, Y., "Pre-authentication Support for PANA", draft-ietf-pana-preauth-00 (work in progress), El Mghazli & Bournelle Expires August 27, 2006 [Page 14] Internet-Draft MPA using IKEv2 and MOBIKE February 2006 October 2005. [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 & Bournelle Expires August 27, 2006 [Page 15] Internet-Draft MPA using IKEv2 and MOBIKE February 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 El Mghazli & Bournelle Expires August 27, 2006 [Page 16] Internet-Draft MPA using IKEv2 and MOBIKE February 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 & Bournelle Expires August 27, 2006 [Page 17]