Internet Engineering Task Force Wassim Haddad Internet Draft Helsinki University of Technology Expires in February 2004 Ericsson Research Canada Suresh Krishnan Ericsson Research Canada September 2003 Optimizing Mobile IPv6 (OMIPv6) Status of this memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited Abstract Mobile IPv6 [1] is supposed to solve the mobility problem and offers a new mode, which allows the flows of data packets between a mobile node (MN) and a correspondent node (CN) to be exchanged via the direct path between them. However this efficiency comes at high price in terms of security needs and excessive mobility signaling messages. This draft introduces a proposal to make Mobile IPv6 more optimized with regards to security needs and less redundant in signaling messages. Haddad, Krishnan Expires February 2004 [Page 1] INTERNET-DRAFT OMIPv6 September 2003 1. Introduction Mobile IPv6 defines the route optimization (RO) mode as one way of exchanging data packets between a mobile node and a correspondent node, via the direct path between them. While this mode is very efficient, it raises many security concerns and leads to high redundancy in mobility signaling messages. According to [1], these signaling messages are needed to keep creating shared secrets between the two entities talking to each other and testing the reachability of MN's IP addresses. This draft suggests an optimization to the RO mode, which aims to enhance its efficiency by making it less vulnerable and reducing the high number of signaling messages involved in the session. 2. Terminology The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" in this document are to be interpreted as described in RFC 2219 [2]. 3. Motivation The RO mode allows one MN to talk directly to the CN, i.e, by using the direct path between them. For this to happen, the MN needs to create a shared secret (i.e., Kbm) with the CN in order to authenticate the binding updates (BUs) messages and let the CN authenticates the binding acknowledgements (BAs) messages with the same shared key. For security reasons, it is required that the lifetime of the shared secret be reduced to few minutes, thus obliging both entities to re-create a new Kbm at a high frequency. For more information about the security concerns related to the RO mode, please refer to [3]. Each time the MN needs to update its Kbm, it needs to exchange four messages with the CN (i.e., the return routability (RR) procedure). Note that for security reasons, the MN's home agent (HA)must get involved each time the RR test is launched. The loss of any of the four messages requires the MN to exchange at least two additional messages with the CN. If the RR test succeeds (i.e., the MN and the CN compute a shared secret), the MN must send a BU message to its HA and waits for a BA. Upon receiving a BA from its HA, the MN sends a BU to its CN to update its binding cache entry (BCE) about its new location (i.e., care-of address (Co@)) and waits for a BA. Haddad, Krishnan Expires February 2004 [Page 2] INTERNET-DRAFT OMIPv6 September 2003 Note that authenticating BUs requires approximately 1.5 round trip times between the mobile node and each correspondent node (for the entire RR procedure in a best case scenario, i.e, no packet losses) and one round trip time between the MN and the HA. Such redundancy is not acceptable for time sensitive applications. It becomes clear from the above that the RO mode introduces an expensive efficiency in terms of excessive mobility messages, high latency and many security concerns. This draft describes one way to make the exchange of BUs/BAs more safe and substantially reduce the number of mobility signaling messages as well as the latency of the handover. 4. Overview of OMIPv6 The suggested solution does not introduce nor replace any new or existing signaling messages. It is to be implemented on top of what has been accepted as the most efficient solution to the mobility problem. OMIPv6 exploits the RR test procedure, which has been designed in [1]. OMIPv6 MUST NOT be used alone. One of the main advantages behind using OMIPv6 is that it gives a malicious node only "one" chance to exploit spoofing, if and when it is possible, the HoT and CoT messages together, thus narrowing the window of vulnerability to the minimum. The second advantage of OMIPv6 is that it does not require the deployment of an infrastructure to distribute keys, thus eliminating any scalability problems. Another advantage behind using OMIPv6 lies in the possibility of deriving a longer shared secret key making it more difficult to crack. Finally, OMIPv6 substantially reduces the amount of mobility signaling messages and makes the exchange, if and when needed, of the HoTI/HoT and CoTI/CoT messages independant from the handover process. OMIPv6 consists on deriving a long shared secret key which will be used by both entities to authenticate the BUs/BAs messages. The new shared secret is derived from a DH exchange, which will be launched by the MN after successfully testing its new and home IP addresses with the CN's address (i.e., the RR test). The DH messages exchanged between the CN and the MN MUST BE authenticated by the Kbm key derived from the latest RR test. Haddad, Krishnan Expires February 2004 [Page 3] INTERNET-DRAFT OMIPv6 September 2003 The DH exchange will allow both entities to establish a bidirectional security association (SA) between them without the need to rely on any exisiting public key infrastructure. The DH messages MUST BE exchanged on the same paths used to exchange the RR test messages. For this purpose, the MN MUST use the Kbm to sign the first DH message and send it to the CN via the direct path. The MN MUST include its home address by using a home address option (HAO). The CN's reply to the first message MUST be signed with the Kbm and duplicated. One copy of the second DH message MUST BE send via the direct path and the second copy via the path going through the MN's HA. If the two messages are identical, the MN pursues the DH exchange and sends the third message via the direct path. The CN replies by sending the fourth DH message on the same path. Note that the main objective of duplicating the second message is the potential ability to reveal a possible MiTM attack on the first one (i.e., the malicious node knows the Kbm). By duplicating the second DH message, a successful MiTM attack will consist on attacking two duplicated messages sent on two different paths at the same time, which probably makes such kind of attack more difficult. The DH process will enable both entities (i.e., the MN and the CN) to compute a long shared secret called "authenticated binding management key" (Kabm). The Kabm will be used to authenticate the BU/BA messages exchanged via the direct path between the MN and the CN. In this case, the exchange of BU/BA messages will allow the two endpoints to test the reachability of the new direct path in both directions prior to injecting any new data packets on the new path. The DH exchange can be launched at any time during the ongoing session. In order to reduce the amount of signaling messages to the minimum, it MAY be launched, for example, immediately after running the first RR test. After running the DH procedure, any new mobility signaling message MUST be signed with the new Kabm computed from the DH exchange. The two endpoints SHOULD silently drop any mobility message related to the MN's home/care-of address or the CN's address and not signed with the Kabm. If the MN needs to exchange CoTI/CoT messages with the CN, it may be possible to send the CoTI message in parallel with the BU. The scheme below shows the different paths taken by the four messages of a DH exchange between a MN and the CN: Haddad, Krishnan Expires February 2004 [Page 4] INTERNET-DRAFT OMIPv6 September 2003 +------------+ +------+ | | | | | MN |<----------------------| HA | | | DH2 | | +------------+ +------+ | ^ ^ | ^ | | DH2| |DH1 / | | | | / DH3| |DH4 | | / V | | V / +------------+ / | | / | CN |-------------------/ | | DH2 +------------+ As it has been mentioned, the DH messages MUST be authenticated from both sides by using the Kbm. The contents and the signature associated with each DH message has been detailed in [4]. In OMIPv6, the DH messages exchanged between the two MNs are described in the following: sid , gX, N , info MN MN MN MN CN ---------------------------------------------------------------> sid , sid , gY, N , info MN MN CN CN CN CN <--------------------------------------------------------------- sid ,sid ,MN, SIG (N , sid ,gX, info , info ), MAC(MN) MN CN Kbm CN MN MN CN Km CN ---------------------------------------------------------------> sid ,sid, ,info ,CN, SIG (N ,sid ,gY,info, info), MAC(CN) MN CN CN Kbm MN CN CN MN Km CN <--------------------------------------------------------------- In the above scheme, the following abbreviations have been adopted: Haddad, Krishnan Expires February 2004 [Page 5] INTERNET-DRAFT OMIPv6 September 2003 -gX = shared part of MN's secret -gY = shared part of CN's secret -sid = session identifier used to specify the ongoing session. -N = nonce -info = additional information carried in the protocol messages -MN = Identity of MN (e.g., MN's Home IP address) -CN = Identity of CN (e.g., CN's IP address) -Kbm = key generated from the RR test -SIG(msg) = denotes the signature of "msg" using the Kbm. -Km = key generated from DH (known only by the MN and the CN) -MAC(msg) = denotes a message authenticated code computed from Km "msg" and signed by Km. 5. Security considerations The draft describes a method to make the route optimization mode more efficient. 6. Acknowledgements Authors would like to thank Laurent Marchand for reviewing the draft. Many thanks for Francis Dupont, Erik Nordmark, and Yuri Ismailov for their inputs on the idea. 7. Normative References [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119. Haddad, Krishnan Expires February 2004 [Page 6] INTERNET-DRAFT OMIPv6 September 2003 8. Informative References [3] P. Nikander, T. Aura, J. Arkko, G.Montenegro and E. Nordmark "Mobile IP version 6 Route Optimization Security Design Background", draft-nikander-mobileip-v6-ro-sec-01. [4] Krawczyk, H., "SIGMA: the 'SIGn-and-MAC'Approach to Authenticated Diffie-Hellman and its use in the IKE Protocols", in Advanceds in Cryptography - CRYPTO 2003 Proceedings, LNCS 2729, Springer, 2003. Available at: http://www.ee.technion.ac.il/~hugo/sigma.html 9. Author's Addresses Wassim Haddad Ericsson Research Canada 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2 Canada Tel: +1 514 345 7900 Fax: +1 514 345 7900 E-mail: Wassim.Haddad@lmc.ericsson.se Suresh Krishnan Ericsson Research Canada 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2 Canada Tel: +1 514 345 7900 Fax: +1 514 345 7900 E-mail: Suresh.Krishnan@lmc.ericsson.se 10. 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 Haddad, Krishnan Expires February 2004 [Page 7] INTERNET-DRAFT OMIPv6 September 2003 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. Haddad, Krishnan Expires February 2004 [Page 8]