Network working group Dacheng Zhang Internet Draft Huawei Technologies Co.,Ltd Category: Standard Track Miika Komu Expires: September 2010 Aalto University March 1, 2010 An Extension of HIP Base Exchange to Support Identity Privacy draft-zhang-hip-privacy-protection-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 1, 2010. Zhang, et al. Expires September 1, 2010 [Page 1] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy Copyright Notice Copyright (c) 2010 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. Abstract In this document, we propose an extension of HIP Base Exchange (BEX) which facilitates HIP hosts to protect their identity privacy. Apart from describing the protocol and packet formats, we also attempt to analyze the applicability and the security strength of the proposed approach. This work is original from BLIND [YLI04]. 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 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Terminologies..................................................4 3. Overview of the Protocol.......................................4 4. Protocol Description...........................................4 4.1. Base Exchange Extensions..................................5 4.1.1. Blind Initiator and Responder........................5 4.1.2. Blind Initiator......................................6 4.1.3. Blind Responder......................................7 4.1.4. Blind not Supported at Initiator or Responder........7 4.2. UPDATE Extensions.........................................8 5. Packet Formats.................................................8 5.1. Control header flags......................................8 5.2. NOTIFY....................................................8 6. Applicability Consideration....................................8 6.1. Opportunistic base exchange...............................8 6.2. Comparison of Disposable Identities vs. Blind.............9 6.3. HIP-based Middleboxes.....................................9 Zhang, et al. Expires September 1, 2010 [Page 2] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy 6.3.1. Firewalls............................................9 6.3.2. Registration.........................................9 6.3.3. Middlebox Nonces....................................10 6.3.4. Immediate Carriage and Conveyance of Upper-layer Protocol...................................................10 7. Signaling (HICCUPS)...........................................10 8. Security Considerations.......................................10 9. IANA Considerations...........................................10 10. Acknowledgments..............................................10 11. References...................................................10 Authors' Addresses...............................................11 1. Introduction The Host Identity Protocol (HIP) [RFC5201] was proposed as a comprehensive solution to address multiple critical issues (e.g., mobility, multi-homing, and security) which the current Internet infrastructure suffers from. In order to achieve this objective, HIP separates the semantics of host identifier from IP addresses by intercepting an "ID" layer in the middle of the network layer and the transport layer. Compared with other ID/Locator separating solutions (e.g., LISP, GSE, ILNP, etc.), HIP is security-inherent. Each HIP host has a public key pair; the public key is used as the Host Identifier (HI) transported over the Internet while the private key is maintained locally. Additionally, a HIP host also needs to generate a 128-bits long Host Identity Tag (HIT) by hashing its HI. HITs are transported in the common parts of HIP headers and regarded by upper layer protocols (e.g., TCP) as ordinary IPv6 addresses. Before two HIP hosts communicate with each other, they use the HIP Base Exchange protocol (HIP BEX) to verify each other's identity and distribute secret materials for subsequent communications. Normally, the HIT and HI of a host are supposed to be steadier than its locator (i.e., IP address). Therefore, the changes in the location of a host will not be detected by upper layer protocols. In the current version of HIP BEX, the identities (i.e., HITs and HIs) of communicating partners are transported in plaintexts. This caused an identity privacy issue. In many scenarios, a user may want to keep its identity confidential to other unrelated principals. However, by eavesdropping HIP BEXs, it is possible for a third party to identify a HIP host even when the host is attached to different locations in the network. As a consequence, the activities of the host can be glued to reason more useful information. The identity privacy issue mentioned here is closely related with the location privacy issues. As illustrated in [RFC4882], the roam of a mobile host can be detected if any constant information related with the Zhang, et al. Expires September 1, 2010 [Page 3] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy host is detected by a third party. Such information can be a Security Parameter Index (SPI) in an IPsec [RFC4301] header, an Interface Identifier (IID) [RFC2462] in an IPv6 address that remains unchanged across networks, the home address of a host supporting mobile IP, the MAC address of a mobile host, an identifier of a mobile host adopted in a upper layer protocol, and so on. Therefore, in order to protect the privacy of a mobile host, a comprehensive solution which cover multiple layers must be provided. However, rather than attempting to address the overall privacy problem, the solution specified in this document is only considered with the identity privacy in the context of HIP, that is, it should provide protection against the attempts to track HIP hosts by inspecting the HITs and HIs transported in HIP BEXs. 2. Terminologies BEX: Base Exchange HIP: Host Identity Protocol HI: Host Identifier HIT: Host Identity Tag 3. Overview of the Protocol The proposed solution is an extension of BLIND, a framework for protecting the identity privacy of hosts that are identified with their public keys. In our solution, if an initiator of a HIP base exchange intends to protect its identity privacy, it will not transport its HI and HIT in plaintexts over the network. Instead, it generates a scramble HIT, called the blinded HIT, for itself. If the initiator intends to protect the identity privacy of its communicating partner, it also needs to generate a blinded HIT for the partner as well. A blinded HIT is generated by hashing the concatenation of a nonce and the associated HIT. In an extended HIP BEX, blinded HITs are transported in plaintext to distribute keying materials, while the permanent HITs and HIs are transported only after being encrypted with the symmetric keys shared between communicating hosts. 4. Protocol Description In order to benefit the discussion, assume there is a HIP host called Initiator which intends to communicate with a HIP host called Zhang, et al. Expires September 1, 2010 [Page 4] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy Responder. The HITs of Initiator are referred to as HIT-Is, and the HITs of Responder are referred to as HIT-Rs. Additionally, the blinded HITs of Initiator and Responder are referred to as B-HIT-Is and B-HIT-Rs respectively. It is assumed that Initiator has got a HIT-R and the associated public key through an out-of-band method before initiating a BEX. 4.1. Base Exchange Extensions In order to distinguish the proposed approach from the ordinary BEX protocol, two control header bits, S and R are introduced. S indicates that the unencrypted HI and HIT of the sender transported in the HIP header are scrambled. R indicates that the unencrypted HI and HIT of the sender transported in the HIP header are scrambled. 4.1.1. Blind Initiator and Responder In the scenarios where the identity privacy of both communicating partners needs to be protected, Initiator needs to generate a blind HIT for itself and blind HIT for Responder before initiating a BEX. In order to achieve this, Initiator first selects a random number nonce, N. Then, Initiator generates a B-HIT-I by SHA-1 hashing the concatenation of N and HIT-I, that is, B-HIT-I=SHA-1(N, HIT-I). In the same way, Initiator generates a B-HIT-I for Responder. B-HIT- R=SHA-1(N, HIT-R). An extended BEX handshake is illustrated in Figure 1. In the I1 packet, the blinded HITs of Initiator and Responder, and the nonce, N, are transported in plaintexts. After receiving I1 packet, Responder needs to calculate an SHA-1 hash value from the concatenation of N and HIT-R, and compare it with the B-HIT-R transported in the I1 packet. Note that if the Responder has multiple HITs, this process may need to be performed recursively. If there is no hash identical to the B-HIT-R, I1 packet will be discarded. If a hash value matches the B-HIT-R, Responder sends a pre-generated R1 packet of the associated HI to Initiator. In order to protect the identity privacy, the HOST_ID parameter of the R1 packet contains a pseudonym (i.e., a random number) instead of the HI. Responder needs to maintain the mapping from the pseudonym and the associated HI. Because Initiator has already obtained an HI of Responder, it can use the HI to assess the validity of the signature of the R1 packet. If the signature is valid, Initiator generates a symmetric key, KDH, using the Diffie-Hellman algorithm and adopts it to calculate the keying material with the HIT-R and B-HIT-I: Zhang, et al. Expires September 1, 2010 [Page 5] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy Key1=SHA1 (KDH, HIT-R, B-HIT-I, 1), ... Keyn=SHA1 (KDH, HIT-R, B-HIT-I, n), Keying material=Key1 XOR ... XOR Keyn. The keying material is then used to generate a symmetric key to encrypt the HIT-I and the associated identifier. The encrypted information is sent to Responder in an I2 packet. Additionally, the I2 packet also contains the nonce used to be transported in I1 and the pseudonym used to be transported in R1. After receiving the I2 packet, Responder computes a key in the same way as the Initiator. Using the key, Responder decrypts the HIT and HI information of Initiator, and verifies the correctness of B-HIT-I. Moreover, Responder encrypts its HI and transported it to Initiator in a R2 packet. After Initiator receives the R2 packets, it decrypts and verifies Responder's HI. To this step, the whole BEX handshake completes successfully. In the packets transported in the exchange, both R and S are set. +-----+ +------+ | | I1: B-HIT-I, B-HIT-R, Nonce | | | |---------------------------------------------------->| | | | R1: B-HIT-I, B-HIT-R, puzzle, DH(r), Pseudonym, Sig.| | | |<----------------------------------------------------| | | I | I2: B-HIT-I, B-HIT-R, Nonce, DH(i), Puzzle Solution,| R | | | SPI Encrypt {HIT-I, HI-I}, Pseudonym, Signature | | | |---------------------------------------------------->| | | | R2: B-HIT-I, B-HIT-R, Encrypt {HIT-R,HI-R}, | | | | SPI, HMAC, Sig. | | | |<----------------------------------------------------| | +-----+ +------+ Figure 1 an extended HIP base exchange 4.1.2. Blind Initiator In the many circumstances, only the identity privacy of Initiator needs to be protected. For instance, a client may want to keep its identity untraceable to any third party, while a public server needs not to. In this case, Initiator only needs to generate a blind HIT for itself before initiating a BEX. The process of generating B-HIT- I is as same as that illustrated in section 4.1.1. Then Initiator sends an I1 packet to Responder (see Figure 2). The packet consists of B-HIT-I, the actual HIT of Responder (HIT-R), and the nonce used Zhang, et al. Expires September 1, 2010 [Page 6] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy in generating B-HIT-I. After receiving I1, Responder sends back Initiator a R1 packet. The process of generating the R1 packet is identical to what has specified in the ordinary BEX. Upon receiving R1, Initiator verifies the validity of R1 and calculates the keying material in the same way illustrated in section 4.1.1. In addition, Initiator encrypts its HIT and HI using a key derived from the keying material and transports the encrypted information in I2. Therefore, after receiving I2, Responder can compute a symmetric key to verify the correctness of B-HIT-I. The symmetric key is also used to calculate the HMAC of the R2 packet sent to Initiator. Therefore, by verifying the HMAC of R2, Initiator can prove that Responder has share a symmetric key with it. In this exchange, the control flag S of I1 and I2 is set while the control flag R of R1 and R2 is set. +-----+ +------+ | |I1: B-HIT-I, HIT-R, Nonce | | | |------------------------------------------------->| | | |R1: B-HIT-I, HIT-R, puzzle, DH(r), HI-R, Sig. | | | |<-------------------------------------------------| | | I |I2: B-HIT-I, HIT-R, Nonce, DH(i), Puzzle Solution,| R | | | SPI, Encrypt {HIT-I, HI-I}, HI-R, Signature | | | |------------------------------------------------->| | | |R2: B-HIT-I, HIT-R, SPI, HMAC, Sig. | | | |<------------------------------------------------ | | +-----+ +------+ Figure 2 an extended HIP base exchange 4.1.3. Blind Responder TBD 4.1.4. Blind not Supported at Initiator or Responder If Initiator uncovers the HIT or HI of Responder in I1, there is no opportunity left for Responder to decide whether to protect its identity privacy. Thus, if Initiator does not know whether its communicating partner needs to keep its identity private or not, it can generate a blind HIT for the partner and transport it in I1. If the partner does not need to protect the privacy of its identity, it finds out the associated HIT and HI, and sends them back in R1 without encryption. In R1, only the control flag R in R1 is set. Thus, the overheads in encrypting and transporting the HIT and HI in R2 are avoided. Zhang, et al. Expires September 1, 2010 [Page 7] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy In some circumstances, the responder in a BEX may expect the identity of the initiator to be kept unrevealed. Such a host can discard the I1 packets whose control flag bit S is zero and reply with ICMP messages or notifications. 4.2. UPDATE Extensions TBD 5. Packet Formats 5.1. Control header flags In order to distinguish the packets in extended BEX from those in ordinary BEX, two control header flags are defined here: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | |R|S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S: if this bit is set to 1, the sender's HIT and HI in this packet are not transported in plaintexts. Otherwise, the sender sends its ordinary HIT and HI in the common part of the packet header in plaintext. R: if this bit is set to 1, the receiver's HIT and HI in this packet are not transported in plaintexts. Otherwise, the receiver's HIT and HI are transported in the common part of the packet header without encryption. 5.2. NOTIFY TBD 6. Applicability Consideration 6.1. Opportunistic base exchange TBD Zhang, et al. Expires September 1, 2010 [Page 8] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy 6.2. Comparison of Disposable Identities vs. Blind During the design of the proposed approach, the solutions using ephemeral identities are also considered. A host can attempt to prevent itself from being tracked by using different HIs in different BEXs. However, some upper layer server applications may use HIs or HITs to identify hosts. When a host uses ephemeral HI, it may be difficult for the applications to find proper state to provide service correctly. To avoid this problem, the Initiator can use an ephemeral HIT to initiate a HIT to transport its permanent HI an HIT in the encrypted part of I2. The Responder in the BEX can also use an ephemeral HIT to distribute keying material securely and transport its permanent HI an HIT in the encrypted part of R2, in order to protect its identity privacy. Compared with our approach, this solution is also effective in protecting identity privacy but relatively inefficient. This solution needs to keep generating ephemeral public key pairs, which is much more cumbersome than our hash based approach. In addition, in this solution a host may have to maintain multiple public key pairs when it simultaneously communicates with different hosts. In our solution, a host can use a single key pair to communicate with different hosts while keeping the identity private, which largely simplifies key management. Moreover, in our approach, communicating partners can use their permanent private keys to sign the packets transported within a BEX. Therefore, a host can easily verify whether its communicating partner possesses the HI and HIT as it claimed in BEX. In this solution, however, communicating partners use their ephemeral private keys to sign such packets. Because the ephemeral HI key pairs and permanent HI key pairs are cryptographically unassociated, a host needs to spend additional efforts to prove its possession on the permanent HI transported in the encrypted part of HIP packets. 6.3. HIP-based Middleboxes TBD 6.3.1. Firewalls TBD 6.3.2. Registration TBD Zhang, et al. Expires September 1, 2010 [Page 9] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy 6.3.3. Middlebox Nonces TBD 6.3.4. Immediate Carriage and Conveyance of Upper-layer Protocol TBD 7. Signaling (HICCUPS) TBD 8. Security Considerations TBD 9. IANA Considerations No such considerations. 10. Acknowledgments Much thank to Jukka Ylitalo for his kindly help in writing this document. 11. References Normative references [RFC2462] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration," RFC2462, December 1998. [RFC4301] S. Kent, and K. Seo, "Security Architecture for the Internet Protocol," RFC 4301, December 2005. [RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement," RFC 4882, March 2007. [RFC5201] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson, "Host Identity Protocol," RFC 5201, April 2008. Informative references Zhang, et al. Expires September 1, 2010 [Page 10] Internet-Draft An Extension of HIP Base Exchange March 2010 to Support Identity Privacy [YLI04] J. Ylitalo and P. Nikander, "BLIND: A Complete Identity Protection Framework for End-points." Proc. Twelfth International Workshop on Security Protocols, Cambridge, England, April 26-28, 2004. Authors' Addresses Dacheng Zhang Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Miika Komu Laboratory of Software Technology Department of Computer Science and Engineering Aalto University Finland Email: miika@iki.fi Zhang, et al. Expires September 1, 2010 [Page 11]