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]