Mobopts Working Group Y. Qiu Internet-Draft J. Zhou Expires: August 27, 2009 Institute for Infocomm Research February 23, 2009 Authentication Between Mobile Node and Home Agent draft-qiu-mext-mn-ha-secure-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Qiu & Zhou Expires August 27, 2009 [Page 1] Internet-Draft MN-HA authentication February 2009 Abstract Mobile IPv6 (and DSMIP6) rely on IPsec for securing the signaling between the MN and HA. However, the tight coupling of the mobility protocol with IPsec is detrimental to broader implementation and deployment. This draft propose a scheme to authenticate the mobile node and signaling of home biding update to home agent as well as avoid the use of IPsec. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Brief Overview of Secure Signaling between Mobile Node and the Home Agent in MIP6 . . . . . . . . . . . . . . . . . . . . 4 4. ID based authentication . . . . . . . . . . . . . . . . . . . 5 4.1. ID based requirement . . . . . . . . . . . . . . . . . . . 5 4.2. ID based solution . . . . . . . . . . . . . . . . . . . . 6 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 5.1. Home Binding Update Procedure . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Qiu & Zhou Expires August 27, 2009 [Page 2] Internet-Draft MN-HA authentication February 2009 1. Introduction The choice of IPsec as the security mechanism for MIP6 was based on : 1) the IPv6 design philosophy which intended IPsec as being the IP layer security protocol for other protocols; 2) IPsec being an integral part of every IPv6 node. While the idea of reusing IPsec for mobility signaling may have been sound, IPsec itself is not a good fit for various reasons: A MIP6 host implementation must also ensure that IPsec and IKEv2 are part of the stack to begin with "C Unnecessary dependency. Use of IPsec in most hosts today is for VPN connectivity: IPsec has not evolved into a generic security mechanism for hosts. With IPsec, HA scalability (in terms of number of connections/BCEs) is limited by the number of IPsec SAs that can be terminated. Implementation complexity: While MIP6 by itself is straightforward to implement on the MN and HA, the interactions that are needed with IPsec and IKEv2 make the protocol unexpectedly difficult. 2. Terminology Throughout this document we use the commonly adopted terminology defined in [1] and [2]. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Qiu & Zhou Expires August 27, 2009 [Page 3] Internet-Draft MN-HA authentication February 2009 3. Brief Overview of Secure Signaling between Mobile Node and the Home Agent in MIP6 The current MIP6 specification lacks location privacy considerations. For example, both the home address and the care-of address are available in the following packets: o Home Binding Updates and Acknowledgements o Return Routability packets o Correspondent Binding Updates and Acknowledgements o Prefix Discovery messages o Data packets between mobile nodes and correspondent nodes in the Route Optimization mode Hence, correspondent nodes, eavesdroppers and of course the home agent(s) can learn the complete location information deterministically without authorization from a mobile node. In Route Optimization mode, the mobile node discloses its care-of address in order to receive the packets through the optimized route, thus it must conceal the real home address. If the mobile node is the initiator of the communication, it can conceal its home address from both correspondent nodes and eavesdroppers. When the correspondent node is the initiator, it may already know the real home address depending on how the mobile node publishes its real home address; in such a case, the mobile node can conceal its home address only from eavesdroppers. In Reverse Tunneling mode, a mobile node can hide its current location from its correspondent node and eavesdroppers along the HA-CN path. In the meanwhile, IPsec tunnel mode enables the mobile node to conceal its home address from any eavesdropper along the MN-HA path. Qiu & Zhou Expires August 27, 2009 [Page 4] Internet-Draft MN-HA authentication February 2009 4. ID based authentication In this section, we describe how to generate a pseudo home address by making use of information exchanged during the Return Routability procedure. This could provide an easier transition to MIP6 with location privacy. In this solution, there is no need to derive a pseudo home address with the home agent. The basic idea is that both the correspondent node and the mobile node derive a shared privacy management key, Kpm, from the keygen tokens exchanged in the home address and care-of address test procedures. Afterwards, the mobile node uses Kpm to hide its home address in the Binding Update to the correspondent node, and finally the correspondent node authenticates the received Binding Update and restores the mobile node'S home address therein. We describe this in the following sections. 4.1. ID based requirement In the original Return Routability procedure, the home address is visible in the Binding Update to the correspondent node. The mobile node can make the home address invisible to eavesdroppers by replacing the real home address with a pseudo home address generated as follows. The mobile node sets a 'P' bit in the reserved field of the HoTI message to indicate it wishes to use a pseudo home address in place of the home address. The correspondent node, if it supports the 'P' bit, computes a privacy keygen token as follows: privacy keygen token = First (64, Kcn(home address set to all zeros | nonce | 2)) This computation is similar to computing the home keygen token except that the home address is set to all zeros. The privacy keygen token is returned in the HoT message as a Mobility Header Option along with the home keygen token. The care-of address test procedure is exactly the same as specified in MIP6 protocol [1]. The mobile node computes Kpm and the pseudo home address after the Return Routability procedure as follows: Kpm = SHA1 (privacy keygen token | care-of keygen token) pseudo home address = string XOR HoA Qiu & Zhou Expires August 27, 2009 [Page 5] Internet-Draft MN-HA authentication February 2009 where String = First (128, HMAC_SHA1 (Kpm, (care-of address | Home nonce index | Care-of nonce index))) The mobile node then sends the following Binding Update to the correspondent node: o IPv6 header (source = care-of address, destination = correspondent node) o Destination Option * pseudo home address o Mobility header * Binding Update = (sequence number, home nonce index, care-of nonce index) * First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | Binding Update))) When a correspondent node receives a Binding Update with a new destination option carrying the pseudo home address, it must first compute Kpm as above. The computation is similar to how it would compute Kbm, except that the privacy keygen token is computed with the home address set to all zeros. With Kpm, the correspondent node computes the String and recovers the home address. It can then compute the home keygen token and Kbm, and verify the MAC for the Binding Update. If the Binding Update processing is successful, the pseudo home address is considered valid. The correspondent node then stores the nonce indices, and Kbm itself. It may also send a normal Binding Acknowledgment to the mobile node. The String is computed once by both the mobile node and the correspondent node, and hence the pseudo home address as computed above remains constant, until one of the address cookies expires or the mobile node undergoes a handover. 4.2. ID based solution The mobile node may send the Binding Update not directly to the correspondent node, but via the home agent. No extension to the Return Routability signaling packets is required with reverse- tunneled Binding Updates. The privacy management key Kpm can be the same as the binding management key Kbm and the mobile node generates the pseudo home address as follows: Qiu & Zhou Expires August 27, 2009 [Page 6] Internet-Draft MN-HA authentication February 2009 pseudo home address = Enc(Kpm, home address) Where Enc(.) is a symmetric key encryption algorithm, for example, AES. The format of the Correspondent Binding Update is as follows: o IPv6 header (source = care-of address, destination = home agent) o ESP header in tunnel mode o IPv6 header (source = home address, destination = correspondent node) o Destination Option * pseudo home address o Mobility header * Binding Update * Alternate Care-of Address option (care-of address) When the correspondent node receives a Binding Update with an Alternate Care-of Address option and a Pseudo Home Address option, it first computes Kbm, verifies the MAC for the Binding Update, and then recovers the home address from the pseudo home address, and verifies whether it is actually the same home address present as the source IP address. With this mechanism, the home address is visible as the source IP address along the HA-CN path. However the eavesdroppers on the HA-CN path can launch the attack to compromise the Return Routability procedure anyway. So, within the limitations of the existing Return Routability mechanism, this approach only requires a new destination option type and the associated processing to hide the home address from eavesdroppers. In the subsequent data packets that take the optimized route, only the care-of address and the pseudo home address are visible. Qiu & Zhou Expires August 27, 2009 [Page 7] Internet-Draft MN-HA authentication February 2009 5. Security Consideration This document addresses a security issue in the mobile environment, location privacy. The proposed solutions do not introduce any new vulnerability. 5.1. Home Binding Update Procedure When the mobile node roams to a new foreign subnet, it sends the modified Home Binding Update to its home agent and receives the modified Home Binding Acknowledgement from its home agent. In both messages, the pseudo home address is used in place of the home address. Eavesdroppers is unable to derive the real home address from the pseudo home address and thus to correlate the care-of address with the home address. Moreover, the pseudo home address can be updated to prevent eavesdroppers linking the mobile node's ongoing activities together. The home agent can derive the real home address from the received pseudo home address efficiently because the encryption/decryption operation is done over a small amount of data (in this case, less than 128 bits), thus the home agent could resist the Denial-of- Service attack when attackers flood with the forged Home Binding Updates. Qiu & Zhou Expires August 27, 2009 [Page 8] Internet-Draft MN-HA authentication February 2009 6. IANA Considerations This document may specify IANA Type assignment(s) in subsequent versions. 7. Conclusion In this document, we introduced efficient and secure solutions to protect location privacy of a mobile node. The central idea is to use a pseudo home address instead of the mobile node's real home address in IP packets of this mobile node. It is possible to update this pseudo home address whenever the mobile node moves to a new location or starts a communication with a new correspondent node. This results in the binding between the care-of address and the home address is hidden to eavesdroppers or even correspondent nodes in some scenarios. Moreover, this pseudo home address is routable, thus the security of this proposed return routeability test is not weakened. We intend to make the best tradeoffs among many related factors during the design. Also we present the thorough analyses of MIP6 location privacy issues and also some best practices to enhance the location privacy. This would help design alternative solutions when a different tradeoff is desired. Furthermore, the mobile node may also desire to hide its movement to the home agent in some cases; the details are beyond the scope of this document. 8. Acknowledgement . 9. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", draft-ietf-mip6-location-privacy-ps-01 (work in progress), March 2006. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Qiu & Zhou Expires August 27, 2009 [Page 9] Internet-Draft MN-HA authentication February 2009 [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [11] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [12] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [14] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [15] Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins, "Solutions for IP Address Location Privacy in the presence of IP Mobility", draft-koodli-mip6-location-privacy-solutions-00 (work in progress), February 2005. [16] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", draft-qiu-mip6-mnprivacy-00 (work in progress), March 2005. [17] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", draft-qiu-mip6-hiding-movement-00 (work in progress), March 2005. [18] Castelluccia, C., Dupont, F., and G. Montenegro, "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", draft-dupont-mip6-privacyext-02 (work in progress), July 2005. Qiu & Zhou Expires August 27, 2009 [Page 10] Internet-Draft MN-HA authentication February 2009 [19] Daley, G., "Location Privacy and Mobile IPv6", draft-daley-mip6-locpriv-00 (work in progress), January 2004. [20] Weniger, K. and T. Aramaki, "Route Optimization and Location Privacy using Tunneling Agents (ROTA)", draft-weniger-rota-01 (work in progress), October 2005. [21] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. Authors' Addresses Ying Qiu Institute for Infocomm Research 1 Fusionopolis Way, #21-01 Connexis Singapore 138632 Phone: +65-6408-2053 Email: qiuying@i2r.a-star.edu.sg Jianying Zhou Institute for Infocomm Research 1 Fusionopolis Way, #21-01 Connexis Singapore 138632 Phone: +65-6408-2053 Email: eaglechiou@gmail.com Qiu & Zhou Expires August 27, 2009 [Page 11]