Mobopts Working Group Y. Qiu Internet-Draft Institute for Infocomm Research Expires: August 31, 2006 F. Zhao UC Davis R. Koodli Nokia Research Center February 27, 2006 Mobile IPv6 Location Privacy Solutions draft-irtf-mobopts-location-privacy-solutions-01.txt 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 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile IPv6 [1] is an IP layer mobility protocol which allows mobile nodes to remain reachable while moving around on the Internet. With the existing specification, a mobile node's movement can be tracked by simply monitoring the IP addresses in communication involving the mobile node. In this document, we propose techniques for hiding a Qiu, et al. Expires August 31, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions February 2006 mobile node's location information from eavesdroppers as well as from correspondent nodes. The proposed techniques are efficient and fully compatible with the base Mobile IPv6 operation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Analysis of Location Privacy in MIP6 . . . . . . . . . . . . . 4 3. Hiding Mobile Node's Location Movement Information . . . . . . 5 3.1. Pseudo Home Address . . . . . . . . . . . . . . . . . . . 5 3.2. Hiding HoA within Home Binding Update . . . . . . . . . . 5 3.3. Hiding CoA via Reverse Tunneling Mode . . . . . . . . . . 6 3.4. Hiding HoA from an Eavesdropper in Route Optimization . . 7 3.4.1. Home Test Init from the Mobile Node . . . . . . . . . 7 3.4.2. Home Test from Correspondent Node . . . . . . . . . . 8 3.4.3. Correspondent Binding Update . . . . . . . . . . . . . 8 3.4.4. The increment of Sequence Numbers . . . . . . . . . . 9 3.4.5. Traffic Packets between Mobile Node and Correspondent Node . . . . . . . . . . . . . . . . . . 10 4. Location Privacy with Unmodified RR Signaling . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5.1. Hiding a MN's Location Information from its CN and from an Eavesdropper in Reverse Tunneling Mode . . . . . 13 5.2. Hiding a MN's Location Movement Information from an Eavesdropper in Route Optimization . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Qiu, et al. Expires August 31, 2006 [Page 2] Internet-Draft MIP6 location privacy solutions February 2006 1. Introduction IP Address Location Privacy in the presence of IP Mobility is an important problem for which some solutions are already frequently discussed. However, details are not documented. Furthermore, solutions for Home Address profiling may benefit from more investigation. In this document, we briefly discuss the problem and then specify the details of solutions. We introduce a "Pseudo Home Address" as a mechanism to hide Home Address during route-optimized communication. The IP address location privacy problem is specified in detail in [2]. In the protocol, we focus on the threats to location privacy posed by the passive entities. In order to compromise the location privacy successfully, the passive entities are usually required to be at certain locations, for example, an eavesdropper along certain paths taken by the traffic between MN, HA and CN. The threats posed by the active attackers are out of scope for now. Also we only consider the location privacy of MN; thus we assume both CN and HA are fixed node in order to simplify the scenarios. While in the real deployment, CN or HA might be mobile as well, the same analysis and solution for MN may also apply in these cases. We categorize the threats related to location privacy in MIP6 from the passive entities into the following two kinds: IP address location privacy and profiling attacks. The issue of IP address location privacy means that other entities can learn the location information of MN from its IP addresses without authorization. In the presence of mobility, there are two problems related to IP address location privacy: Disclosing a new IP address (CoA) to a correspondent, and revealing a fixed IP address (HoA) to an eavesdropper. So, a MN may not mind using a fixed Home Address with a correspondent but may not wish to disclose its new Care-of Address, whereas it may not wish to reveal its Home Address to an on-looker, but has to use the CoA from its visited network. The issue of profiling attacks means that other entities can enrich its knowledge about MN, for example by linking the activities of MN and then analyzing the collected information. With the enlarged knowledge base together with other additional background information about MN, other entity can compromise the location privacy of MN with a higher probability. The scope of this protocol will be limited the issue of IP address location privacy. And we use the commonly adopted terminology defined in [1] and [2] in this document. Qiu, et al. Expires August 31, 2006 [Page 3] Internet-Draft MIP6 location privacy solutions February 2006 2. Analysis of Location Privacy in MIP6 Current MIP6 specification does not consider location privacy. For example, both CoA and HoA are available to on-lookers in the following messages: o Home Binding Update and Acknowledgement o Correspondent Binding Update and Acknowledgement o Prefix Discovery o Data packets between MN and CN in the Route Optimization mode Also HoA is available in the HoTi/HoT message on the HA-CN path. Hence, the CN, on-lookers and even the HA can inspect copies of packets from MN, and learn the complete location information deterministically without MN's authorization. In Route Optimization Mode, where the MN must use CoA as the source IP address in the communication with HA and CN, both its peers and eavesdropper can learn CoA. In order to protect the location privacy, MN must use some way to conceal its real HoA. If the MN is always the initiator of a communication, MN can conceal its HoA from both the CN and the on-looker. However, if the CN is the initiator of a communication, the CN certainly knows the MN's HoA, and then MN's CoA. Therefore, in this case, MN can only conceal its HoA from the on-lookers. In Reverse Tunneling Mode, a MN can hide its current location from the CN by reverse tunneling all its traffic through the Home Agent. The MN, in addition can hide its Home Address from any eavesdroppers on the access network by also reverse tunneling IPsec-encrypted Mobile IP signaling and data traffic with its Home Agent. Qiu, et al. Expires August 31, 2006 [Page 4] Internet-Draft MIP6 location privacy solutions February 2006 3. Hiding Mobile Node's Location Movement Information 3.1. Pseudo Home Address It is desirable not to reveal the real Home Address at all in the mobile node's communication. So, some other field can be used to substitute the real HoA, but such a field must be communicated securely and the field itself must not become a target of profiling. We define a field called a "Pseudo Home Address", which is sent as a destination option in place of the Home Address. The field is used by the home agent and correspondent to recover the real Home Address from the Pseudo Home Address in packets among MN, HA and CNs. The computation of Pseudo Home Address is as follows: Pseudo_HoA = HMAC_SHA1(Kph, Previous Pseudo_HoA)) Where the Kph could be derived from the secret key pre-established manually between the MN and HA or derived from the secret key set up during IKE phase 1 between the MN and the HA. 3.2. Hiding HoA within Home Binding Update When MN moves to a new foreign subnet, it sends the following modified Home Binding Update to its HA: o IPv6 header (source = CoA, destination = HA) o Destination option header * Home Address option (Pseudo_HoA) o ESP header in transport mode o Mobility header * Home Binding Update * Alternative CoA option (CoA) And HA replies to MN with the following modified Home Binding Acknowledgement: o IPv6 header (source = HA, destination = CoA) o Destination option header Qiu, et al. Expires August 31, 2006 [Page 5] Internet-Draft MIP6 location privacy solutions February 2006 * Home Address option (Pseudo_HoA) o ESP header in transport mode o Mobility header * Home Binding Acknowledgement Note that Pseudo_HoA is used instead of the real HoA in above messages. In case MN fails to receive the Binding Acknowledgement, it will retransmit the Binding Update but with a new sequence number in order to detect a replay attack. Upon the successful binding update, MN and HA each computes a new PseudoHoA as described in above section. They then replace the previous Pseudo_HoA with the new one in their respective data record and in their respective Home BU cache: PseudoHoA (as the index of the entry) HoA (as the index of the entry) CoA Lifetime ...... 3.3. Hiding CoA via Reverse Tunneling Mode To hide its CoA from the CN and its HoA from an eavesdropper, the MN communicates Mobile IP signaling and IP data packets with its HA via reverse tunneling. When the MN sends a Home Binding Update from a visited network to its HA, it uses the following packet form to hide its HoA from being monitored on the access network: o IPv6 header (source = CoA, destination = HA) o Destination option header * Home Address option (Pseudo_HoA) o ESP header in transport mode o Mobility header Qiu, et al. Expires August 31, 2006 [Page 6] Internet-Draft MIP6 location privacy solutions February 2006 * Binding Update * Alternative CoA option (CoA) The HA uses the following packet form to reply a Binding Acknowledgement to the MN that is not on the home link: o IPv6 header (source = HA, destination = CoA) o Routing header (type 2) * Pseudo_HoA o ESP header in transport mode o Mobility header * Binding Acknowledgement In case the MN fails to receive the Binding Acknowledgement, the MN will retranismit the Binding Update but with a new sequence number in order to detect replay attack. The MN and HA each computes a new Pseudo HoA as described in Section 3.1. The MN and HA then each replace the old Pseudo_HoA with the new one in their respective databases. This updating of Pseudo_HoA is only performed once right after the successful home binding update and acknowledgement. 3.4. Hiding HoA from an Eavesdropper in Route Optimization 3.4.1. Home Test Init from the Mobile Node The MN sends HoTI to HA with the following packet form: o IPv6 header (source = CoA, destination = HA) o ESP header in tunneling mode o IPv6 header (source = HoA, destination = CN) o Mobility header * HoTI The HoTI is then forwarded to the CN in the following form: Qiu, et al. Expires August 31, 2006 [Page 7] Internet-Draft MIP6 location privacy solutions February 2006 o IPv6 header (source = HA, destination = CN) o Destination option * Pseudo_HoA o Mobility header * HoTI 3.4.2. Home Test from Correspondent Node Upon receiving the HoTI from HA, the CN replies with HoT in the following form: o IPv6 header (source = CN, destination = HA) o Destination option * Pseudo_HoA o Mobility header * HoT = (home init cookie, home keygen token, home nonce index) where home keygen token = First (64, HMAC_SHA1(Kcn, (Pseudo_HoA | nonce | 0))) and Kcn is the CN's local secret [1]. Upon receiving the packet, HA, using Pseudo_HoA as an index, retrieves HoA and CoA from the Home BU cache, generates a new HoT packet and forwards the packet to MN: o IPv6 header (source = HA, destination = CoA) o ESP header in tunneling mode o IPv6 header (source = CN, destination = HoA) o Mobility header * HoT = (home init cookie, home keygen token, home nonce index) 3.4.3. Correspondent Binding Update The MN sends the CoTI to the CN and the CN replies to the MN with CoT, in exactly the same ways as specified in the RR test [1]. After receiving the HoT and CoT, the MN sends the Binding Update to Qiu, et al. Expires August 31, 2006 [Page 8] Internet-Draft MIP6 location privacy solutions February 2006 the CN in the following packet form: o IPv6 header (source = CoA, destination = CN) o Destination Option * E(Kbm, HoA) o Mobility header * Binding Update = (Pseudo_HoA, home nonce index, ...) where Kbm is the binding update key given by o Kbm = SHA1 (home keygen token | care-of keygen token) o home keygen token = First (64, HMAC_SHA1(Kcn, (Pseudo_HoA | nonce | 0))) o care-of keygen token = First (64, HMAC_SHA1(Kcn, (CoA | nonce | 1))) and E(Kbm, HoA) is a symmetric key encryption of the HoA under the secret binding update key Kbm. After receiving the BU, the CN first computes home keygen token and care-of keygen token. The CN then computes Kbm and decrypts E(Kbm, HoA) to recover HoA. The CN then keeps both HoA and Pseudo HoA in its binding cache table. The subsequent data traffic between the MN and the CN will follow the same procedure and packet format as specified in [1] except that the Pseudo HoA is used in place of the HoA. 3.4.4. The increment of Sequence Numbers RFC 3775 [1] only requires that the sequence number field in the Binding Update is greater than the Sequence Number received in the previous valid Binding Update for this home address. However, if the increment of sequence number is fixed, an eavesdropper is also able to guess the MN's movement by monitoring a series of BU messages. Here the increment of sequence number is defined as seq#_increment = First(8, HMAC_SHA1(Kbm, home nonce index | care nonce index)); then Qiu, et al. Expires August 31, 2006 [Page 9] Internet-Draft MIP6 location privacy solutions February 2006 Seq# = previous Seq# + seq#_increment. In order to avoid exceeding easily the 16 bit range of se-quence number and keep enough random numbers, we pick up the first 8 bits from the result of the keyed pseudo function. If seq#_increment = 0, then set seq#_increment = 1. As the increment of sequence number is not fixed now, MN needs to deal with the case when it reaches 2^16-1. If the new Seq# > 2^16-1, then MN sets the new Seq# to 2^16-1. 3.4.5. Traffic Packets between Mobile Node and Correspondent Node The subsequent data traffic between MN and CN will follow the same procedure and packet format as specified in [1] except that Pseudo_HoA is used in place of HoA: Packets from MN to CN: o IPv6 header (source = CoA, destination = CN) o Destination option * Pseudo_HoA o Payload Packets from CN to MN: o IPv6 header (source = CN, destination = CoA) o Routing Header * Pseudo_HoA o Payload Qiu, et al. Expires August 31, 2006 [Page 10] Internet-Draft MIP6 location privacy solutions February 2006 4. Location Privacy with Unmodified RR Signaling In this section, we present an IP address location privacy mechanism without any modification on the original RR test, which would help ease the transition to a Mobile IPv6 management solution with the support of location privacy. The basic idea is that both CN and MN derive a shared privacy management key, Kpm, from the keygen tokens achieved in the home address and care-of address test procedures; afterwards, MN uses Kpm to hide its home address in the Binding Update to CN; and finally CN authenticates the received Binding Update and restores the MN'S home address therein. Following is another scheme to hide the real Home Address. 4.1. Route-Optimized Binding Update to CN In the original RR test, the home address is visible in the Binding Update to CN. MN can make the home address invisible to on-lookers by replacing the real Home Address with a Pseudo Home Address generated as follows. The MN 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 CN, if it supports the 'P' bit, computes a Privacy Keygen Token as follows: Privacy_Keygen_Token = First (64, Kcn(HoA set to all zeros | nonce |0)) This computation is similar to computing the home keygen token except that the HoA 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 MN computes a session key Kpm after the return routability procedure as follows: Kpm = SHA1 (Privacy_Keygen_Token | care-of keygen token) and the Psuedo Home Address Pseudo_Home_Address = String XOR HoA where, String = First (128, HMAC_SHA1 (Kpm, (CoA | Home Nonce Index | Care-of Nonce Index))) Qiu, et al. Expires August 31, 2006 [Page 11] Internet-Draft MIP6 location privacy solutions February 2006 When a CN 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 HoA set to all zeros. With Kpm, the CN computes the String and recovers the HoA. It can then compute the home keygen token, the Kbm, and verify the MAC for the Binding Update. If Binding Update processing is successful, the Pseudo Home Address is considered valid. The CN then stores the nonce indices, and the Kbm itself. The CN sends a normal Binding Acknowledgment to the MN. The String is computed once by both the MN and the CN, and hence the Pseudo Home Address as computed above remains constant, until one of the address cookies expires or the MN undergoes a handover. 4.2. Reverse-tunneled Binding Update to CN MN may send the BU not directly to CN, but via HA. In this case, the packet header format 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) The privacy management key Kpm is the same as the binding management key Kbm. When a CN receives a BU with an alternate-CoA option and a new destination option containing the Pseudo Home Address, it first computes the Kbm, verifies the MAC for the Binding Update, and then recovers the Home Address from the Pseudo Home Address, and verifies if it is actually the Home Address present in the source IP address. When the Binding Update is reverse-tunneled through the Home Agent, the Home Address is visible as the source IP address along the HA-CN path. However the on-lookers on the HA-CN path can launch the attack to compromise the RR test anyway. Qiu, et al. Expires August 31, 2006 [Page 12] Internet-Draft MIP6 location privacy solutions February 2006 5. Security Considerations The modified binding update procedures and data packets presented above can be explored to achieve two objectives: 1) hiding the location information of a mobile node from its correspondent node as well as from an eavesdropper when data packets are communicated in the reverse tunneling mode, and 2) hiding a mobile node's location movement information from an eavesdropper during route optimization. 5.1. Hiding a MN's Location Information from its CN and from an Eavesdropper in Reverse Tunneling Mode When MN roams to a new foreign subnet, it sends the modified home binding update (BU) to its HA and the HA replies with the modified home binding acknowledgement (BA). Note that in both BU and BA, Pseudo_HoA is used in place of HoA; hence an eavesdropper will not be able to relate CoA to HoA. Moreover, the value of Pseudo_HoA is updated continually whenever MN moves to a new subnet. As a result, the eavesdropper is not able to link past Pseudo_HoA values. In the reverse tunneling mode, CN continues to send data packets to MN's HoA since it is not aware of the movement of MN. Data packets from CN are intercepted by HA and are tunneled to MN's CoA. To tunnel intercepted packets, HA encapsulates the packets using IPsec ESP tunneling mode which encrypts the inner IPv6 header where HoA is used in destination option, with the outer IPv6 header addressed to MN's CoA. 5.2. Hiding a MN's Location Movement Information from an Eavesdropper in Route Optimization In the route optimization mode, since MN and CN communicate with each other directly, obviously it is not possible to hide MN's location (i.e., CoA) from CN. The best we can hope for is to hide MN's location movement from an eavesdropper. This is accomplished as follows. When MN moves to a new foreign subnet, it first performs the modified home binding update procedure given in section 3. As discussed before, this procedure does not disclose the relationship between HoA and CoA and therefore prevents an eavesdropper from learning the current location of MN. The procedure also updates Pseudo_HoA values whenever MN enters a new subnet in order to avoid the eavesdropper from tracing MN's movement from one subnet to another. To initiate the route optimization mode, MN next performs the modified correspondent binding update procedure described in section 3. It is easy to see that none of these messages relates HoA with Qiu, et al. Expires August 31, 2006 [Page 13] Internet-Draft MIP6 location privacy solutions February 2006 CoA. Hence, the eavesdropper, observing all the message flows, may learn that a node is at CoA but is not able to relate it to the target MN. The same observation applies to the data packets. 6. IANA Considerations This document may specify IANA Type assignment(s) in subsequent versions. Qiu, et al. Expires August 31, 2006 [Page 14] Internet-Draft MIP6 location privacy solutions February 2006 7. Conclusion In this document, we introduced solutions to protect location information of mobile node. The proposed techniques are efficient and fully compatible with the base Mobile IPv6 operation. With our techniques, a mobile node's location information can be hidden from eavesdroppers during route optimization and further hidden from its correspondent node during reverse tunneling. The basic idea is that a pseudo HoA is used in place of the MN's real HoA for all packets to and from the MN, and the pseudo HoA is updated whenever MN moves to a new location. As a result, the binding between the CoA and the HoA cannot be derived by an eavesdropper (or even by the correspondent node in the reverse tunneling mode). Moreover, as the pseudo HoA is never used as a communicating address, the process of IP reachable checking and DNS updates could be avoided. 8. 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-irtf-mobopts-location-privacy-ps-00 (work in progress), July 2005. Qiu, et al. Expires August 31, 2006 [Page 15] Internet-Draft MIP6 location privacy solutions February 2006 Authors' Addresses Ying Qiu Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 Email: qiuying@i2r.a-star.edu.sg Fan Zhao University of California Davis One Shields Avenue Davis, CA 95616 US Phone: +1 530 752 3128 Email: fanzhao@ucdavis.edu Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 US Email: rajeev.koodl@nokia.com Qiu, et al. Expires August 31, 2006 [Page 16] Internet-Draft MIP6 location privacy solutions 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. Qiu, et al. Expires August 31, 2006 [Page 17]