[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

 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]
 

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/