Network-based Mobility Management W. Haddad (Netlmm) S. Krishnan Internet-Draft Ericsson Research Intended status: Standards Track November 11, 2007 Expires: May 11, 2008 On Providing Light SeND and Privacy Extensions for Proxy MIPv6 (PMIPv6) draft-haddad-netlmm-pmipv6-privacy-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 May 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Haddad & Krishnan Expires May 11, 2008 [Page 1] Internet-Draft Proxy MIPv6 Privacy November 2007 Abstract This document describes a light and CGA free version of the secure neighbor discovery protocol combined with a privacy extension for the Proxy Mobile IPv6 protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Background and Motivation . . . . . . . . . . . . . . . . . . 6 5. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Solution for On-path attacks . . . . . . . . . . . . . . . 8 5.2. Solution for On-link attacks . . . . . . . . . . . . . . . 8 5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Future work . . . . . . . . . . . . . . . . . . . . . . . 10 6. New Option Format . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Haddad & Krishnan Expires May 11, 2008 [Page 2] Internet-Draft Proxy MIPv6 Privacy November 2007 1. Introduction Proxy Mobile IPv6 protocol (described in [PMIPv6]) is an ongoing activity, which aims essentially to provide network based mobility. The main concept is to trick the mobile node (MN) into believing that it is always attached to its home network even when in reality, it has switched to foreign network(s). Consequently, the MN can keep using it IP home address (HoA) while being located away from its home network. This document describes a mechanism which combines a light and CGA free version of the secure neighbor discovery (described in [SeND]) combined with a privacy extension for PMIPv6 protocol. At this stage, the light SeND (LiSeND) protocol enables the MN and its access router, i.e., the mobility access gateway (MAG), to authenticate the exchange of router solicitation (RtSol) and advertisement (RtAdv) messages and removes the need for running duplicate address detection (DAD) on the MN side (for more details on RtAdv/RtSol and DAD, please refer to the Neighbor Discovery Protocol described in [NDP]). Another key feature lies in the fact that LiSeND does not require the crypto generated address technique (described in [CGA]) deployment on both the infrastructure and the MN sides. Building on LiSeND, we then describe a simple privacy extension which enables to mask the MN's HoA in a visited network(s) and thus, prevents an eavesdropper from learning, identifying and tracing the MN. A side effect of the suggested proposal is a mechanism which removes the harmful impact on the MN's ongoing sessions in case of a possible duplicate address detection (DAD) failure. Haddad & Krishnan Expires May 11, 2008 [Page 3] Internet-Draft Proxy MIPv6 Privacy November 2007 2. 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 [TERM]. Haddad & Krishnan Expires May 11, 2008 [Page 4] Internet-Draft Proxy MIPv6 Privacy November 2007 3. Terminology Since our proposal is mainly designed for network-based mobility, we borrow the terminology used in PMIPv6 and refer to a mobility (un)aware by MN. The main privacy aspects definitions are defined in [PRITERM]. Finally, we reuse the tunneling optimization mechanism and terminology that we have introduced earlier in [TOM]. Haddad & Krishnan Expires May 11, 2008 [Page 5] Internet-Draft Proxy MIPv6 Privacy November 2007 4. Background and Motivation Being a network-base mobility, PMIPv6 achieves its goal by enabling the MN to retain the same IP address while roaming between different foreign networks and delegates the task of securely discovering and updating the MN's Local Mobility Anchor (LMA) to the MAG. The MAG fulfills its task by sending a proxy binding update (PBU) message to request binding (and potentially assigning) the MN's home network prefix (HNP) to its own egress interface address as being the MN's care-of address (CoA). Following a successful update, the MN's LMA starts tunneling data packets sent from the correspondent node(s) (CN) (i.e., which is kept totally unaware about the MN's mobility) to the MN's CoA, i.e., MAG's egress interface address. The MAG then decapsulates each data packet sent to the MN's CoA and forwards it to the MN. It follows, as mentioned earlier, that the MN will always believe that it is still attached to its home network, especially that the MAG takes great care of nurturing the MN's belief by advertising in unicast mode its home prefix in order to convince it to (re)-configure its HoA. Our motivation is mainly guided by a requirement in EU and some Asian countries and from a general desire in others (!!), to protect the MN's privacy while switching to and moving across foreign networks. Such protection should enable to provide anonymity and unlinkability aspects whenever possible. Consequently, privacy protection in a PMIPv6 environment means first and foremost preventing the MN from disclosing its HoA within any foreign network and removing any "linkability" when switching to a new MAG. It follows that an efficient privacy protection should enable the MN to mask its HoA and to update the mask each time it switches to a new MAG. It is noteworthy that updating the mask becomes more efficient for protecting the MN's privacy if it is applied at higher frequency than just when switching to a new MAG. While the suggested proposal enables such enhancement, we don't detail it in this version. A malicious node (acting independently), has two topological locations from which, it can learn/detect the MN's HoA (or maybe the HNP only) and use it to trace the MN's subsequent movements. The first location is anywhere on-path between the MAG and the MN's LMA. In such location, the eavesdropper is able to check the inner header carried in each data packet sent by the MN's HA to its current MAG. The data packet inner header carries the MN's HoA and the CN's IP address. With such ability, the eavesdropper can rely for example, on som prior knowledge/hint to uncover the targeted MN's current whereabout and even "lock" on it. The second location is the link to which the MN is attached. In such Haddad & Krishnan Expires May 11, 2008 [Page 6] Internet-Draft Proxy MIPv6 Privacy November 2007 location, the eavesdropper is also able to identify the MN and trace its movements. In addition, other static identifier(s), e.g., the MN's MAC address, become available and may significantly contribute in detecting and tracing the MN. However, we consider out of scope all parameters below the IP layer but we carefully note that our proposal can also be extended to cover the MAC address, i.e., by extending the scope of the mask. Privacy issues related to the MAC layer are detailed in [ANON]. The unlinkability protection can be seriously endangered each time the MN switches to a foreign network and keeps using its CGA public key from which, it has generated its HoA. In fact, the requirement behind PMIPv6 design to enable the MN to retain its HoA means also that the MN won't be able to change its CGA public key as its HoA won't remain the same. Consequently, if an eavesdropper learns the MN's public key (which is far from being a problem!), then it will always be able to trace the MN after switching to a new MAG(s). In addition, as applying the mask will generate a pseudo-IPv6 (pIPv6) address, it is of high importance to make sure that pIPv6 won't be reused when switching to a new MAG. The picture of the two separate threats scenarios described above becomes rapidly more complicated when they are combined. This is the case where at least two malicious nodes with each following one of the two scenarios, are coordinating their "search, identify and trace" activities. In such case, an efficient anonymity and unlinkability protection can be obtained by simply merging the two solutions addressing each of the the two scenarios. In other words, the MN's HoA MUST NOT be disclosed neither on the link between the MN and its MAG nor anywhere between the MAG and the MN's LMA. Also, the MN MUST avoid (re)-using its CGA public key and the pIPv6 MUST be refreshed after the handoff. In the following section, we address the above scenarios separately and describe two mechanisms to reduce the eavesdropper's ability to learn the MN's HoA and/or trace its movements. The combination of the two protections is highlighted in the last section. Haddad & Krishnan Expires May 11, 2008 [Page 7] Internet-Draft Proxy MIPv6 Privacy November 2007 5. Proposed Solutions 5.1. Solution for On-path attacks Our proposed mechanism addresses the first scenario where an eavesdropper is located on-path between the MN's MAG and the LMA by completely eliminating the need for disclosing the MN's HoA in any data packet sent to the MN's PMA. This is achieved by removing it from each data packet exchanged between the MN's LMA and its current MAG, via applying the tunneling optimization (TO) mechanism. As in the Mobile IPv6 case [MIP6], the TO mechanism can be securely applied during the PBU/PBA messages exchange between the MAG and the LMA nodes. In this case, the PMIPv6 signaling exchange should lead both sides to create a PaT, which can be immediately applied on each data packet sent by the MN to the correspondent node (CN) and/or tunneled from the HA to the MN's CoA, i.e., the MAG. This results in a complete removal of the MN's HoA from the path between the MAG and the LMA. Consequently, implementing such optimization significantly complicates the eavesdropper's task of identifying the targeted MN from snooping into data packets flow(s) exchanged between the MN's MAG and its LMA. Note that if the MN is using multiple HoAs as it may be talking to different CNs, then the PMA and HA will have to generate one PaT for each HoA. In addition to removing the MN's HoA from data packets and in order to enhance the unlinkability aspect, it is highly recommended that the MAG refreshes periodically the MN's CoA, i.e., its own IP egress interface address, and updates all associated PaT(s) accordingly. This can be done by re-sending PBU message(s) to the LMA to update its binding cache entries table. 5.2. Solution for On-link attacks As mentioned in the second threat scenario, when an eavesdropper is attached to the same link than the MN, it can easily detect the unicast RtAdv message sent by the MAG to the MN following a successful authentication and the receipt of a PBA message (unless the HNP is obtained via another way, e.g., from the AAA). However, as disclosing the MN's home network prefix (HNP) alone may be very sufficient for an eavesdropper to identify the MN, providing privacy protection to the MN requires a complete "blackout" on its HNP on any foreign link. Such requirement may also be raised within the MN's home network as it blocks malicious nodes from learning the MN's HoA even when it is still attached to its home network. Imposing an HNP blackout requires the MAG and/or LMA to send special parameters to the MN in order to enable it to (re)-configure its HoA and at the same time, generate a special PaT to translate its HoA to another pIPv6 address in each IP packet sent by the MN as well as in each IP Haddad & Krishnan Expires May 11, 2008 [Page 8] Internet-Draft Proxy MIPv6 Privacy November 2007 packet forwarded by the LMA/MAG to the MN. In addition, these parameters MUST be sent encrypted, which makes it tempting at this stage to turn to the CGA technique to achieve this particular goal (i.e., using the MN's CGA public key), then send them in the unicast RtAdv message. However, as mentioned earlier, using the MN's CGA public key provides the eavesdropper just another valuable tool to identify and trace the MN. In order to avoid the CGA impasse, a new secret called "privacy key (Kp)" should be computed and stored in the AAA. Computing Kp should be performed when authenticating the MN for the first time. Note that generating Kp can occur when the MN is attached to a foreign network. The mechanism(s) to be used to compute Kp is out of scope of this document. 5.3. Operation After generating and storing Kp, the AAA may decide to share it with the MN's LMA. But, in general, Kp is used by the MN and the AAA to derive the "transient handoff key (THK)", which is then sent to the MN's current MAG. THK can be sent to the MAG directly by the AAA, following a successful authentication or by the LMA in the PBA message. This means that each time the MN has to perform an authentication, a new THK is computed and sent to the current MAG. In addition to refreshing THK, the AAA and the MN SHOULD also generate a pseudo-NAI (pNAI) and bind it to the new TKh to be used. The new pNAI is used by the MN during the next authentication and is carried by the PBU message sent by the MAG to the LMA. It follows that the pNAI MUST be sent to the LMA prior to receiving a PBU message (e.g., after a successful authentication). Upon receiving a THK, the MAG SHOULD use it to derive a PaT and to encrypt the HNP sent by the LMA in order to be advertised to the MN. For this purpose, the MAG has to signal to the MN its capability to offer anonymity and unlinkability services. This is done by setting a new bit called "Privacy (P)" bit in the unicast RtAdv message sent to the MN. The presence of the "P" bit also indicates to the MN that it has to generate the PaT which corresponds to the THK computed by the MN. One way to handle the "P" bit is to set it in the same new option (called "Unicast RtAdv Authentication (URA)") carrying the message authentication. Moreover, the MAG MUST use THK to authenticate all unicast RtAdv messages sent to the MN. Similarly, the MN MUST use THK to authenticate any RtSol message sent to the MAG. Upon receiving a RtAdv message carrying a URA (i.e., following a successful authentication), the MN proceeds first to check the message validity with its own THK. If the message is valid then the MN decrypts the HNP, configures its HoA and generates the corresponding PaT. Otherwise, the MN should silently discard the Haddad & Krishnan Expires May 11, 2008 [Page 9] Internet-Draft Proxy MIPv6 Privacy November 2007 message. The PaT SHOULD be applied by the MN on each data packet sent to the CN. The MAG SHOULD apply the PaT on each IP packet sent to the MN's HoA and on each data packet sent by the MN. It follows that the MN's HNP is never disclosed on the link. It should be noted that for the purpose of enhancing the unlinkability while being attached to the same link, it is highly recommended to periodically refresh the PaT. In addition to hiding the HNP advertised to the MN, the MAG SHOULD also run the DAD procedure on the MN's new pIPv6 address before advertising the HNP to the MN. In case of a collision, the MAG SHOULD randomly generate a unique pseudo-HNP then share it with the MN. This is achieved by XORing a random 64-bit parameter with the corresponding PaT then with the HNP and testing its uniqueness. The MAG SHOULD then send the 64-bit parameter to the MN in a new option (called "Pseudo Home Network Prefix (PHNP)") carried by the RtAdv message. Note that the PHNP MUST be encrypted with THK. In the unlikely event leading to inserting a PHNP option in the RtAdv message, the MN MUST use the 64-bit pseudo-HNP to update the PaT generated from THK. This is done by XORing the 64-bit pseudo-HNP with the PaT in order to enable generating a new pIPv6 when the data packet header is XORed with the updated PaT. It follows from the above, that in order to avoid breaking the MN's anonymity during an NDP exchange between two MNs, the MAG SHOULD also act as the "reference" node for any NDP queries. Such enhancement will enable LiSeND to provide most of features provided by SeND protocol. In order to address merging privacy threats scenarios described earlier, the two mechanisms have to be combined in order to protect the path between the MAG and the LMA and at the same time, the one between the MN and the MAG against malicious eavesdroppings. Doing so provides anonymity and unlinkability features to the MN on the path between the MN to its LMA. This means that the MN's MAG SHOULD apply a PaT when dealing with the corresponding LMA and another one when dealing with the MN in order to mask the MN's HoA or its HNP from each data packet exchanged between the MN and the CN and/or from signaling messages exchanged between the MAG and the LMA. 5.4. Future work Future versions of this work will probe further enhancements for the LiSeND protocol and possible stretching of anonymity and unlinkability extensions down to the MAC layer. Haddad & Krishnan Expires May 11, 2008 [Page 10] Internet-Draft Proxy MIPv6 Privacy November 2007 6. New Option Format TBD Haddad & Krishnan Expires May 11, 2008 [Page 11] Internet-Draft Proxy MIPv6 Privacy November 2007 7. Security Considerations This document introduces first LiSeND protocol which is a light and CGA free version of SeND protocol. LiSeND is shown to be adapted to the concept of network based mobility where PMIPv6 protocol is a leading candidate. We describe next how key privacy aspects can be build on top of LiSeND in a seamless way which does not affect the MN's unawareness about its mobility. Our proposal relies on sharing a different "privacy key" between the MN and each MAG visited by the mobility unaware MN. For this purpose, and considering the main clients for deploying PMIPv6, we adopt a realistic approach centered around the existence of a AAA infrastructure which will enable the MN to be authenticated upon attachment to foreign network(s). We also consider that the MN is able to derive the corresponding transient handoff key (THK) after each successful authentication. However, in order to avoid sharing the same THK between three different nodes (i.e., MN, LMA and MAG), and in order to enable LiSeND to protect the MN against compromised MAG, we suggest sending a hash of the current THK (H_THK) to the MN's LMA. It follows that each MAG MUST include H_THK in the PBU message sent to the LMA following a successful authentication of the MN. Haddad & Krishnan Expires May 11, 2008 [Page 12] Internet-Draft Proxy MIPv6 Privacy November 2007 8. References 8.1. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3792, March 2005. [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support for IPv6", RFC 3775, June 2004. [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971, March 2005. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, BCP , March 1997. 8.2. Informative References [ANON] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Patil, B., and H. Tschofenig, "Anonymous Identifiers (ALIEN): Privacy Threat Model for Mobile and Multi-Homed Nodes", Internet Draft, draft-haddad-alien-threat-model-00.txt, January 2007. [PMIPv6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Internet Draft, draft-ietf-netlmm-proxymip6-06.txt, september 2007. [PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology", Internet Draft, draft-haddad-alien-privacy-terminology-03.txt, October 2007. [TOM] Haddad, W., Naslund, M., and P. Nikander, "IP Tunneling Optimization in a Mobile Environment", Internet- Draft, draft-haddad-mip6-tunneling-optimization-01.txt, July 2007. Haddad & Krishnan Expires May 11, 2008 [Page 13] Internet-Draft Proxy MIPv6 Privacy November 2007 Authors' Addresses Wassim Haddad Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden Phone: +46 8 4044079 Email: Wassim.Haddad@ericsson.com Suresh Krishnan Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 Email: Suresh.Krishnan@ericsson.com Haddad & Krishnan Expires May 11, 2008 [Page 14] Internet-Draft Proxy MIPv6 Privacy November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Haddad & Krishnan Expires May 11, 2008 [Page 15]