Network Working Group M. Bagnulo Internet-Draft UC3M Intended status: Informational October 20, 2006 Expires: April 23, 2007 Privacy Analysis for the SHIM6 protocol draft-bagnulo-shim6-privacy-01 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 April 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This note presents a privacy analysis for the SHIM6 protocol for IPv6 site multihoming support and the failure detection extensions for the SHIM6 protocol.This note does not attempt to provide a solution for providing SHIM6 protocol privacy. Bagnulo Expires April 23, 2007 [Page 1] Internet-Draft SHIM6 Privacy Analysis October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Privacy of the ULID-pair context establishment exchange . . . . 3 3. Payload packets . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Other Signalling messages . . . . . . . . . . . . . . . . . . . 6 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security considerations . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Bagnulo Expires April 23, 2007 [Page 2] Internet-Draft SHIM6 Privacy Analysis October 2006 1. Introduction This note presents a privacy analysis for the SHIM6 protocol as defined in [1] and the failure detection extensions for the SHIM6 protocol defined in [2]. The scenario considered is the following: two nodes are communicating using the SHIM6 protocol to achieve enhanced fault tolerance capabilities. The potential attackers are located along the path and their goal is to obtain relevant information by observing the exchanged packets. In particular, we consider that information harvesters may be interested in determining whether a set of addresses belongs to a single host or if a set of packets exchanged using different address pairs belong to the same communication. In the following sections we will analyze the information contained in the SHIM6 protocol messages that can be used to obtain such information. It should be noted that this analysis is limited to malicious third parties that are located along one or several of the available paths between the communication parties and that it is out of the scope of the analysis the case where the potential attacker is one of the parties involved in the communication i.e. the goal is not to avoid the disclosure of locator information from the peer. The remaining of this note is structured as follows: in the next section we will perform a privacy analysis of the SHIM6 4-way exchange to establish ULID-pair contexts. Next, we will analyze the privacy aspects of the payload packet exchange and finally we consider the privacy implications of other protocol messages, including the failure detection protocol for the SHIM6 protocol. 2. Privacy of the ULID-pair context establishment exchange The ULID-pair context establishment exchange consists of 4 messages: I1, R1, I2 and R2. We will next analyze the privacy implications of each of them. The I1 message is exchanged using a valid locator pair in the IPv6 address fields. In addition, the I1 message contains the Initiator context tag and nonce. Besides it can carry additional options. In particular, in case that the locator pair used differs from the ULID pair for the context, an ULID-pair option must be carried in the I1 message. Among the information carried in the I1 message we consider that the following may have privacy implications if it can be observed by a Bagnulo Expires April 23, 2007 [Page 3] Internet-Draft SHIM6 Privacy Analysis October 2006 third party: o The binding between a locator pair and ULID pair if the ULID-pair option is carried in clear text o The Context Tag information can be used by an attacker in order to correlate different packets containing different locator pairs. Through this mean, the attacker can learn that multiple locators belong to the same endpoint and that the different packets carrying different address pairs belong to the same communication. In order to achieve privacy protection, it is required to conceal all this information. The next message to be exchanged is R1. This message contains a pair of valid locators in the IPv6 address fields and in the message itself, it contains the Initiator nonce and the Responder nonce. In addition, the R1 message support the Validator option, which contain cryptographic information. The disclosure of any of these elements doesn't seems to raise any privacy concerns, so there does not seem to be any requirement to conceal the information carried in the R1 message. After the R1 message the ULID-pair context establishment continues with the I2 message. The I2 message is carried in a packet containing again a valid locator pair in the IPv6 header address fields and, in the I2 message itself the Initiator context tag, the Initiator and Responder nonces are conveyed. The I2 message can carry also the following options: ULID pair, Forked Instance Identifier, Locator list, Locator Preferences, CGA Parameter Data Structure and CGA Signature. Of all the aforementioned information conveyed in the I2 message, we identify the following items that may imply privacy concerns: o The Initiator Context tag, for the same reasons than in the I1 message o The ULID-pair option, for the same reasons than in the I1 message o The locator list option, since it carries the list of locator which disclosure would clearly result in allowing the attacker to identify the multiple locator associated with a single endpoint o The CGA parameter data structure option. In this case, it depends of which information is carried in the data structure. If a multiprefix extension is carried i.e. HBA are used, then the information is critical from a privacy perspective, since the information about multiple prefixes and hence about multiple locators is included in the data structure. If the multiprefix extension is not included, then the CGA parameter data structure could be used by an attacker to obtain identifier information (since there is enough information in the data structure to re- Bagnulo Expires April 23, 2007 [Page 4] Internet-Draft SHIM6 Privacy Analysis October 2006 create the associated CGA). So if the CGA is being used as locator in the packet (and no multiprefix extension is being used), then the CGA parameter data structure is not critical from a privacy perspective. The other information carried in the I2 message is not considered to be critical for preserving the privacy. In particular, the Forked Instance Identifier could be used to correlate different packets, but without knowing the Context tag, the attack seems not very practical. The Locator preference option may inform about the number of locators available and the relative preference between them, but without knowing the actual locators, this information does not seem to be very relevant neither. Finally, the CGA signature information does not seem to provide any useful information for an attacker. The last packet of the initial exchange is the R2 packet that contains the Responder context tag, and the following potential options: Locator List, Locator Preferences, CGA Parameter Data Structure, CGA Signature. Analogously to the I2 case, the following information needs to be concealed: the Responder context tag, the Locator list option, the CGA Parameter Data structure. In addition to the four messages of the basic ULID-pair context establishment exchange, there are also two additional messages defined, that need to be analyzed also these are the R1bis packet and the I2bis packet. The R1bis message is carried in a packet that carries valid locators in the IPv6 address fields and the message itself contains the Packet context tag and the Responder nonce. In addition, it also can carry the Validator option. Similarly to the R1 packet, the R1bis packet does not carries any critical information from a privacy point of view. The I2bis message is also carried in a packet that contains valid locators in the IPv6 address fields and it carries the following information in the message: Initiator context tag, the Initiator and Responder nonces and the Packet context tag. In addition it allows the following options: Responder Validator, ULID pair, Forked Instance Identifier, Locator list, Locator Preferences, CGA Parameter Data Structure and the CGA Signature. Similarly to the previous cases, the following information needs to be concealed in order to preserve privacy: Initiator context Tag, ULID pair option, Locator List option, CGA Parameter Data Structure. Bagnulo Expires April 23, 2007 [Page 5] Internet-Draft SHIM6 Privacy Analysis October 2006 3. Payload packets Payload packets are data packets that carry the SHIM6 header containing the Payload option. This option carries the Receiver context tag. The main privacy issue related to the Payload packets is that they may change the locator pair used while keeping the Context tag unchanged. The problem with this approach is that an attacker located along the different paths can correlate different packets carrying different locator pairs through the constant context tag included in the payload header. Through this mean, the attacker can determine different locators of the locator set and determine that different packets exchanged belong to a single communication. In order to prevent this privacy breach, it is required that different unrelated context tags are used when the locator pair is changed. 4. Other Signalling messages In addition to the messages previously analyzed, the SHIM6 protocol also defines the Update Request and Ack messages and the Keepalive and Probe messages. We will next perform the privacy analysis for these messages. The Update Request carries the Context tag and the request nonce and it supports the following options: Locator List, Locator Preferences, CGA Parameter Data Structure, CGA Signature. As for the prior analysis, the critical information from a privacy perspective is the following: the context tag (if a different locator pair is being used), the Locator List option, and the CGA parameter data structure (with the considerations described above). The Update Ack message contains the context tag and the request nonce. If different locator pair is used, the context tag and the request nonce can be used to correlate different packets with different locator pairs. In this case, the context tag and nonce information need to be concealed to protect privacy. With respect to Keepalive and Probe messages, the critical information contained in those messages is the following: the context tag and the identifier information carried in different options available. The considerations with respect to the context tag information are similar to the ones already discussed for other messages. With respect to the Identifier information, this information would Bagnulo Expires April 23, 2007 [Page 6] Internet-Draft SHIM6 Privacy Analysis October 2006 allow the correlation of different Keepalive and Probe packets, allowing then to bind different locators used in different packets. In order to preserve privacy, the Identifier information need to be concealed. 5. Conclusion It is clear that there is quite a few information included in the SHIM6 protocol that need to be concealed in order to provide privacy support for the SHIM6 protocol. However, it is likely that encrypting the critical information using a shared secret generated through a Diffie Hellman exchange would provide enough protection for most of the cases. There are however two cases that would require additional study: one is the case of the information exchanged in the I1 packet, which is the first message to be exchanged implying that no previous shared secret can possible be exchanged. In order to address this case, or additional prior message exchange is included in the protocol to provide privacy or the critical information is removed from the I1 message. Another case that would require further analysis is the case of the context tag. The context tag is used to demultiplex incoming packet. In order for this to be useful, the context tag needs to be known beforehand by both ends and in order to provide privacy support, the context tag needs to be changed when the locator pair is changed. Mechanisms for changing the context tag depending on the locator pair used can be defined, keeping in mind that the relation between the locator pair and the context tag must remain untraceable for an external observer. 6. Security considerations This note analyzes the privacy issues of the SHIM6 protocol. Additional security considerations of the SHIM6 protocol are addressed in the protocol specification itself 7. References [1] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", draft-ietf-shim6-l3shim-00 (work in progress), July 2005. [2] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", draft-ietf-shim6-failure-detection-03 (work in progress), December 2005. Bagnulo Expires April 23, 2007 [Page 7] Internet-Draft SHIM6 Privacy Analysis October 2006 Author's Address Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires April 23, 2007 [Page 8] Internet-Draft SHIM6 Privacy Analysis October 2006 Full 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. 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. 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). Bagnulo Expires April 23, 2007 [Page 9]