MIP6 Lu Hongmei Internet Draft Zhang Hongke Expires: December, 2006 NGI Research Center Beijing Jiaotong University July 29, 2006 Privacy Identifier in MIPv6 draft-zhang-mip6-pid-00.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 December 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document proposes a solution on Mobile IPv6 home address privacy, which prevents an eavesdropper from tracking a MN during route optimization. Zhang Expires December 29, 2007 [Page 1] Internet-Draft Privacy Identifier in MIPv6 July 2006 Conventions used in this document The key words "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 Table of Contents 1. Introduction................................................2 2. Assumptions.................................................3 3. Privacy Identifier Proposal..................................3 3.1. Return Routability Process..............................5 3.2. Binding Update.........................................5 3.3. PID packet format.......................................8 3.4. WORD Option............................................8 4. Security Considerations......................................9 5. IANA Considerations.........................................9 6. Acknowledgments.............................................9 7. References..................................................9 Author's Addresses............................................10 Intellectual Property Statement................................10 Disclaimer of Validity........................................11 Copyright Statement...........................................11 Acknowledgment................................................11 1. Introduction HoA uniquely identifies a MN, in MIPv6. The HoA of a MN is included in packets it sends and receives. In fact, packets sent by a MN include a Home Address option that contains its HoA. Packets sent by a CN to a given MN contain a type 2 routing header that includes the mobile HoA. Thus any eavesdropper within the network can easily identify packets that a particular MN sends, and then continue to track it. MIPv6 allows a MN move from one network to another, while maintains optimal routing mode. A MN can keep exchanging data packets with CN When moving outside of the home network. Therefore when a MN roams to a foreign network, it is allocated a CoA, and then sends binding update message to update its binding cache entry with MN's new location i.e. CoA. Since there is location information of its current foreign network (prefix of the subnet) in the CoA and the binding update message and subsequent data packets both HoA and CoA, it is Zhang Expires December 29, 2006 [Page 2] Internet-Draft Privacy Identifier in MIPv6 July 2006 easy to find out the location of a MN by keeping track of messages by HoA. Therefore, once a MN moves outside of home network, MIPv6 discloses home address that used to identify, locate and track its target during optimal routing mode. In order to prevent the attack on HoA, a MN can avoid using the same HoA during a long time. There are mostly two methods: o MN can use substituted identifier as HoA, packets sent and received by a MN will contain substituted identifier instead of HoA, but it must be transmitted securely and must not become a target of attack. o MN is collocated temporary Home Address that is periodically changed; This document proposes a mechanism for preventing the eavesdropper from tracking of MN during optimal routing mode. 2. Assumptions The methods discussed in this document depend upon the following assumptions: o The MN and the HA shares one secret key Kbm. o MN's identity is not revealed by other protocols such as AAA etc. o PID can be used as indexes for IPsec SAs between MN and HA. o MN communicate using PID instead of HoA, in fact, using HoA to communication is reachable. 3. Privacy Identifier Proposal Here we propose a HoA privacy solution that meets the following requirements: o The privacy identifier substituting HoA can be changed, but not frequently; the privacy identifier must change only when the CoA changes, and the privacy identifier itself must not become a target of attack. Zhang Expires December 29, 2006 [Page 3] Internet-Draft Privacy Identifier in MIPv6 July 2006 o Continuous reachability at all times. o It is impossible for a eavesdropper to reckon the relationship between a privacy identifier and a HoA; o As less dependency as possible to other protocols such as IPsec. In the solution privacy identifier is used to substitute HoA. If the MN decides to use route optimization mode, it must sends a binding update to its CN. This binding update contains the privacy identifier in its Home Address option and the actual HoA is concealed by being encoded in a newly defined sub-option. In order to preserve privacy the binding update must be encrypted Thus the following packets between the MN and the CN contains the privacy identifier in the Home Address option and routing header 2 instead of the actual HoA. As a result, an eavesdropper is not able to identify the packets sent or received by a particular node. During the period of communication process, the following requirement is necessary: o To prevent disclosing the MN's HoA in any binding update message. o To avoid using the same privacy identifier in binding update message. Privacy Identifier(PID) changes while CoA changing, and is used to replace CoA in destination option. CN use this privacy identifier to recover the HoA from binding update packets. This solution ensures that the update of PID and CoA is synchronous. The definition of PID is as follows: PID = Clearword XOR HoA Clearword = First(128 HMAC_SHA1(Seed,CN|HoA|CoA)) ''Seed'' is a random number that generated by MN. Because of ''seed'' is not transmitted in plain text, MN can use the same SEED for communication with all the CN and HA. The introduction of seed can ensure that the ''clearword'' is random enough. Adding the address of CN to the computation of ''clearword'' is to guarantee each ''clearword'' correspond with one and only CN, and CoA is used to make sure that the ''clearword'' updated synchronously with the new CoA. Zhang Expires December 29, 2006 [Page 4] Internet-Draft Privacy Identifier in MIPv6 July 2006 3.1. Return Routability Process In Return Routability Process, Home Test Init (HoTI) and Home Test (HoT) using the address of HA and PID, but not HoA. Home Test Init to the HA in the following form: IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init Home Test Init from the MN in the following form: IPv6 header (source = home agent, destination = correspondent node) Destination Options header Home Address option (PID) Mobility header Home Test Init Home Test to the MN in the following form: IPv6 header (source = correspondent node, destination =home agent) Routing header (type 2) PID Mobility header Home Test Home Test from the HA in the following form: IPv6 header (source = home agent, destination =care-of address) ESP header in tunneling mode IPv6 header (source = correspondent node, destination = home address) Mobility header Home Test 3.2. Binding Update After receiving the HoT and Care of Test, the MN sends binding update to the CN in the following form: Binding Update from MN: Zhang Expires December 29, 2006 [Page 5] Internet-Draft Privacy Identifier in MIPv6 July 2006 IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (PID) Mobility header Binding Update Binding Update to HA: IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (PID) Mobility header Binding Update Binding Acknowledgement from HA: IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) PID Mobility header Binding Acknowledgement Binding Acknowledgement to MN; IPv6 header (source = home agent, destination = home address) Routing header (type 2) PID Mobility header Binding Acknowledgement Adding ''word'' option to binding update message, the content of which is ''clearword'' or ''EncryptedWord''. The MN immediately computes and uses the new PID when it obtains the new CoA, which means that the PID is updated synchronously with the new CoA. In the course of binding update for HA, PID is in the Home Address option (substitute the place of HoA), Clearword is in the Word option of BU, and Word option is protected by IPsec. At HA, BU messages are protected by ESP (transmit mode) which can ensure the security of Clearword. PID is work as source address through SA is setup with HA in the transmit mode, thus the new PID does not impact on the IPsec Zhang Expires December 29, 2006 [Page 6] Internet-Draft Privacy Identifier in MIPv6 July 2006 operation. HA can obtain the Clearword in Word option after decryption, and then recover HoA, HoA=PID XOR Clearword. During the time of binding update of CN, at the beginning of RR, the MN uses the new PID and the CN is unnecessary to verify the validity of PID. At the end of RR, MN will obtain a binding management key (Kbm), with which MN encrypts ''clearword''. EncryptedWord = Encrypt(ClearWord) Encrypt()is the encrypted content of () with Kbm. Then send the BU message that contains the EncryptedWord in the Word option to the CN. After receiving a BU message, CN must compute Kbm and verify the validity of Message Authentication Code (MAC). If the verification is successful and the PID is valid, ''EncryptedWord'' t is decrypted to recover ''clearword''. With PID and clearword, CN can recover HoA. After that, the CN keeps both HoA and PID in its binding cache. The process of communication is the same as RFC3775 except that the PID substitutes the HoA. The involved arithmetic is as follows: HoA=PID XOR clearword Clearword=Decrypt(EncryptedWord) Decrypt() is the decrypted content of () with Kbm. When MN and CN communicate via reverse tunneling, the procedure is the same as above. During the whole process of communication, this technique conceals the HoA by this way. Furthermore, it can prevent the RR related attack from eavesdropper, since the CoA updates synchronously with privacy identifier. Zhang Expires December 29, 2006 [Page 7] Internet-Draft Privacy Identifier in MIPv6 July 2006 3.3. PID packet format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + PID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type IANA is requested to assign a new type Option Length 8 bit unsigned integer indicating the length of the option excluding the type and length fields. PID The PID as above 3.4. WORD Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + WORD + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Zhang Expires December 29, 2006 [Page 8] Internet-Draft Privacy Identifier in MIPv6 July 2006 IANA is requested to assign a new type Option Length 8 bit unsigned integer indicating the length of the option excluding the type and length fields. WORD ClearWord or EncryptedWord 4. Security Considerations We assume that the communications between a MN and its HA are protected by IPsec Security Associations (SA) as in Mobility support in IPv6 RFC3775. 5. IANA Considerations The PID destination option introduced in requires IANA assignment from the destinations options space. The Option Type value for the WORD Option within the option numbering space will be assigned by IANA. 6. Acknowledgments This document is a collaborative effort of our entire NGI Research Center. Many thanks to them who are Yang Shen, Zhang Sidong, Chen Jian, Ren Yan, Zhang Hui, Zhang Bingyi. 7. References [1] D. B. Johson and C. Perkins, "Mobility Support in IPv6", RFC 3775, June 2004. [2] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",RFC 3776, June 2004. [3] Haddad, W., Ed., "Anonymity and Unlinkability Extension for OMIPv6-CGA", draft-haddad-privacy-omipv6-anonymity-00.txt (work in progress), June 2005. [4] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple Privacy Extension to Mobile IPv6", IEEE/IFIP International Zhang Expires December 29, 2006 [Page 9] Internet-Draft Privacy Identifier in MIPv6 July 2006 Conference on Mobile and Wireless Communication Networks (MWCN), October 2004. [5] R. Koodli. Solutions for IP Address Location Privacy in the presence of IP Mobility. Internet Draft, Internet Engineering Task Force. draft-koodli-location-privacy-00.txt, February 2005. [6] W. Haddad, E. Nordmark, F. Dupont, M. Bagnulo, S. Park, B. Patil, "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", draft-haddad-momipriv-problem-statement-01, February 2005. Author's Addresses Long Hongmei Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 Email:lu_922@163.com Zhang Hongke Tel: +86 10 5168 5677 NGI Research Center Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 Email: hkzhang@center.njtu.edu.cn 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 Zhang Expires December 29, 2006 [Page 10] Internet-Draft Privacy Identifier in MIPv6 July 2006 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. Zhang Expires December 29, 2006 [Page 11]