tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7401

 Errata 
Proposed STD
Pages: 128
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: HIP

Host Identity Protocol Version 2 (HIPv2)

Part 1 of 5, p. 1 to 11
None       Next RFC Part

Obsoletes:    5201


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                 R. Moskowitz, Ed.
Request for Comments: 7401                                HTT Consulting
Obsoletes: 5201                                                  T. Heer
Category: Standards Track              Hirschmann Automation and Control
ISSN: 2070-1721                                                P. Jokela
                                            Ericsson Research NomadicLab
                                                            T. Henderson
                                                University of Washington
                                                              April 2015


                Host Identity Protocol Version 2 (HIPv2)

Abstract

   This document specifies the details of the Host Identity Protocol
   (HIP).  HIP allows consenting hosts to securely establish and
   maintain shared IP-layer state, allowing separation of the identifier
   and locator roles of IP addresses, thereby enabling continuity of
   communications across IP address changes.  HIP is based on a Diffie-
   Hellman key exchange, using public key identifiers from a new Host
   Identity namespace for mutual peer authentication.  The protocol is
   designed to be resistant to denial-of-service (DoS) and man-in-the-
   middle (MitM) attacks.  When used together with another suitable
   security protocol, such as the Encapsulating Security Payload (ESP),
   it provides integrity protection and optional encryption for upper-
   layer protocols, such as TCP and UDP.

   This document obsoletes RFC 5201 and addresses the concerns raised by
   the IESG, particularly that of crypto agility.  It also incorporates
   lessons learned from the implementations of RFC 5201.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7401.

Page 2 
Copyright Notice

   Copyright (c) 2015 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................5
      1.1. A New Namespace and Identifiers ............................6
      1.2. The HIP Base Exchange (BEX) ................................6
      1.3. Memo Structure .............................................7
   2. Terms and Definitions ...........................................7
      2.1. Requirements Terminology ...................................7
      2.2. Notation ...................................................8
      2.3. Definitions ................................................8
   3. Host Identity (HI) and Its Structure ............................9
      3.1. Host Identity Tag (HIT) ...................................10
      3.2. Generating a HIT from an HI ...............................11
   4. Protocol Overview ..............................................12
      4.1. Creating a HIP Association ................................12
           4.1.1. HIP Puzzle Mechanism ...............................14
           4.1.2. Puzzle Exchange ....................................15
           4.1.3. Authenticated Diffie-Hellman Protocol with
                  DH Group Negotiation ...............................17
           4.1.4. HIP Replay Protection ..............................18
           4.1.5. Refusing a HIP Base Exchange .......................19
           4.1.6. Aborting a HIP Base Exchange .......................20
           4.1.7. HIP Downgrade Protection ...........................20
           4.1.8. HIP Opportunistic Mode .............................21
      4.2. Updating a HIP Association ................................24
      4.3. Error Processing ..........................................24
      4.4. HIP State Machine .........................................25
           4.4.1. State Machine Terminology ..........................26
           4.4.2. HIP States .........................................27
           4.4.3. HIP State Processes ................................28
           4.4.4. Simplified HIP State Diagram .......................35

Top      ToC       Page 3 
      4.5. User Data Considerations ..................................37
           4.5.1. TCP and UDP Pseudo Header Computation for
                  User Data ..........................................37
           4.5.2. Sending Data on HIP Packets ........................37
           4.5.3. Transport Formats ..................................37
           4.5.4. Reboot, Timeout, and Restart of HIP ................37
      4.6. Certificate Distribution ..................................38
   5. Packet Formats .................................................38
      5.1. Payload Format ............................................38
           5.1.1. Checksum ...........................................40
           5.1.2. HIP Controls .......................................40
           5.1.3. HIP Fragmentation Support ..........................40
      5.2. HIP Parameters ............................................41
           5.2.1. TLV Format .........................................44
           5.2.2. Defining New Parameters ............................46
           5.2.3. R1_COUNTER .........................................47
           5.2.4. PUZZLE .............................................48
           5.2.5. SOLUTION ...........................................49
           5.2.6. DH_GROUP_LIST ......................................50
           5.2.7. DIFFIE_HELLMAN .....................................51
           5.2.8. HIP_CIPHER .........................................52
           5.2.9. HOST_ID ............................................54
           5.2.10. HIT_SUITE_LIST ....................................56
           5.2.11. TRANSPORT_FORMAT_LIST .............................58
           5.2.12. HIP_MAC ...........................................59
           5.2.13. HIP_MAC_2 .........................................59
           5.2.14. HIP_SIGNATURE .....................................60
           5.2.15. HIP_SIGNATURE_2 ...................................61
           5.2.16. SEQ ...............................................61
           5.2.17. ACK ...............................................62
           5.2.18. ENCRYPTED .........................................62
           5.2.19. NOTIFICATION ......................................64
           5.2.20. ECHO_REQUEST_SIGNED ...............................67
           5.2.21. ECHO_REQUEST_UNSIGNED .............................68
           5.2.22. ECHO_RESPONSE_SIGNED ..............................69
           5.2.23. ECHO_RESPONSE_UNSIGNED ............................69
      5.3. HIP Packets ...............................................70
           5.3.1. I1 - the HIP Initiator Packet ......................71
           5.3.2. R1 - the HIP Responder Packet ......................72
           5.3.3. I2 - the Second HIP Initiator Packet ...............75
           5.3.4. R2 - the Second HIP Responder Packet ...............76
           5.3.5. UPDATE - the HIP Update Packet .....................77
           5.3.6. NOTIFY - the HIP Notify Packet .....................78
           5.3.7. CLOSE - the HIP Association Closing Packet .........78
           5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet ..79

Top      ToC       Page 4 
      5.4. ICMP Messages .............................................79
           5.4.1. Invalid Version ....................................79
           5.4.2. Other Problems with the HIP Header and
                  Packet Structure ...................................80
           5.4.3. Invalid Puzzle Solution ............................80
           5.4.4. Non-existing HIP Association .......................80
   6. Packet Processing ..............................................80
      6.1. Processing Outgoing Application Data ......................81
      6.2. Processing Incoming Application Data ......................82
      6.3. Solving the Puzzle ........................................83
      6.4. HIP_MAC and SIGNATURE Calculation and Verification ........84
           6.4.1. HMAC Calculation ...................................84
           6.4.2. Signature Calculation ..............................87
      6.5. HIP KEYMAT Generation .....................................89
      6.6. Initiation of a HIP Base Exchange .........................90
           6.6.1. Sending Multiple I1 Packets in Parallel ............91
           6.6.2. Processing Incoming ICMP Protocol
                  Unreachable Messages ...............................92
      6.7. Processing of Incoming I1 Packets .........................92
           6.7.1. R1 Management ......................................94
           6.7.2. Handling of Malformed Messages .....................94
      6.8. Processing of Incoming R1 Packets .........................94
           6.8.1. Handling of Malformed Messages .....................97
      6.9. Processing of Incoming I2 Packets .........................97
           6.9.1. Handling of Malformed Messages ....................100
      6.10. Processing of Incoming R2 Packets .......................101
      6.11. Sending UPDATE Packets ..................................101
      6.12. Receiving UPDATE Packets ................................102
           6.12.1. Handling a SEQ Parameter in a Received
                   UPDATE Message ...................................103
           6.12.2. Handling an ACK Parameter in a Received
                   UPDATE Packet ....................................104
      6.13. Processing of NOTIFY Packets ............................104
      6.14. Processing of CLOSE Packets .............................105
      6.15. Processing of CLOSE_ACK Packets .........................105
      6.16. Handling State Loss .....................................105
   7. HIP Policies ..................................................106
   8. Security Considerations .......................................106
   9. IANA Considerations ...........................................109
   10. Differences from RFC 5201 ....................................113
   11. References ...................................................117
      11.1. Normative References ....................................117
      11.2. Informative References ..................................119
   Appendix A. Using Responder Puzzles ..............................122
   Appendix B. Generating a Public Key Encoding from an HI ..........123

Top      ToC       Page 5 
   Appendix C. Example Checksums for HIP Packets ....................123
     C.1. IPv6 HIP Example (I1 Packet) ..............................124
     C.2. IPv4 HIP Packet (I1 Packet) ...............................124
     C.3. TCP Segment ...............................................125
   Appendix D. ECDH and ECDSA 160-Bit Groups ........................125
   Appendix E. HIT Suites and HIT Generation ........................125
   Acknowledgments ..................................................127
   Authors' Addresses ...............................................128

1.  Introduction

   This document specifies the details of the Host Identity Protocol
   (HIP).  A high-level description of the protocol and the underlying
   architectural thinking is available in the separate HIP architecture
   description [HIP-ARCH].  Briefly, the HIP architecture proposes an
   alternative to the dual use of IP addresses as "locators" (routing
   labels) and "identifiers" (endpoint, or host, identifiers).  In HIP,
   public cryptographic keys, of a public/private key pair, are used as
   host identifiers, to which higher-layer protocols are bound instead
   of an IP address.  By using public keys (and their representations)
   as host identifiers, dynamic changes to IP address sets can be
   directly authenticated between hosts, and if desired, strong
   authentication between hosts at the TCP/IP stack level can be
   obtained.

   This memo specifies the base HIP protocol ("base exchange") used
   between hosts to establish an IP-layer communications context, called
   a HIP association, prior to communications.  It also defines a packet
   format and procedures for updating and terminating an active HIP
   association.  Other elements of the HIP architecture are specified in
   other documents, such as:

   o  "Using the Encapsulating Security Payload (ESP) Transport Format
      with the Host Identity Protocol (HIP)" [RFC7402]: how to use the
      Encapsulating Security Payload (ESP) for integrity protection and
      optional encryption

   o  "Host Mobility with the Host Identity Protocol" [HIP-HOST-MOB]:
      how to support host mobility in HIP

   o  "Host Identity Protocol (HIP) Domain Name System (DNS) Extension"
      [HIP-DNS-EXT]: how to extend DNS to contain Host Identity
      information

   o  "Host Identity Protocol (HIP) Rendezvous Extension"
      [HIP-REND-EXT]: using a rendezvous mechanism to contact mobile HIP
      hosts

Top      ToC       Page 6 
   Since the HIP base exchange was first developed, there have been a
   few advances in cryptography and attacks against cryptographic
   systems.  As a result, all cryptographic protocols need to be agile.
   That is, the ability to switch from one cryptographic primitive to
   another should be a part of such protocols.  It is important to
   support a reasonable set of mainstream algorithms to cater to
   different use cases and allow moving away from algorithms that are
   later discovered to be vulnerable.  This update to the base exchange
   includes this needed cryptographic agility while addressing the
   downgrade attacks that such flexibility introduces.  In addition,
   Elliptic Curve support via Elliptic Curve DSA (ECDSA) and Elliptic
   Curve Diffie-Hellman (ECDH) has been added.

1.1.  A New Namespace and Identifiers

   The Host Identity Protocol introduces a new namespace, the Host
   Identity namespace.  Some ramifications of this new namespace are
   explained in the HIP architecture description [HIP-ARCH].

   There are two main representations of the Host Identity, the full
   Host Identity (HI) and the Host Identity Tag (HIT).  The HI is a
   public key and directly represents the Identity of a host.  Since
   there are different public key algorithms that can be used with
   different key lengths, the HI, as such, is unsuitable for use as a
   packet identifier, or as an index into the various state-related
   implementation structures needed to support HIP.  Consequently, a
   hash of the HI, the Host Identity Tag (HIT), is used as the
   operational representation.  The HIT is 128 bits long and is used
   in the HIP headers and to index the corresponding state in the
   end hosts.  The HIT has an important security property in that it
   is self-certifying (see Section 3).

1.2.  The HIP Base Exchange (BEX)

   The HIP base exchange is a two-party cryptographic protocol used to
   establish communications context between hosts.  The base exchange is
   a SIGMA-compliant [KRA03] four-packet exchange.  The first party is
   called the Initiator and the second party the Responder.  The
   protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd
   packets, and authenticates the parties in the 3rd and 4th packets.
   The four-packet design helps to make HIP resistant to DoS attacks.
   It allows the Responder to stay stateless until the IP address and
   the cryptographic puzzle are verified.  The Responder starts the
   puzzle exchange in the 2nd packet, with the Initiator completing it
   in the 3rd packet before the Responder stores any state from the
   exchange.

Top      ToC       Page 7 
   The exchange can use the Diffie-Hellman output to encrypt the Host
   Identity of the Initiator in the 3rd packet (although Aura, et al.
   [AUR05] note that such operation may interfere with packet-inspecting
   middleboxes), or the Host Identity may instead be sent unencrypted.
   The Responder's Host Identity is not protected.  It should be noted,
   however, that both the Initiator's and the Responder's HITs are
   transported as such (in cleartext) in the packets, allowing an
   eavesdropper with a priori knowledge about the parties to identify
   them by their HITs.  Hence, encrypting the HI of any party does not
   provide privacy against such an attacker.

   Data packets start to flow after the 4th packet.  The 3rd and 4th HIP
   packets may carry a data payload in the future.  However, the details
   of this may be defined later.

   An existing HIP association can be updated using the update mechanism
   defined in this document, and when the association is no longer
   needed, it can be closed using the defined closing mechanism.

   Finally, HIP is designed as an end-to-end authentication and key
   establishment protocol, to be used with Encapsulating Security
   Payload (ESP) [RFC7402] and other end-to-end security protocols.  The
   base protocol does not cover all the fine-grained policy control
   found in Internet Key Exchange (IKE) [RFC7296] that allows IKE to
   support complex gateway policies.  Thus, HIP is not a complete
   replacement for IKE.

1.3.  Memo Structure

   The rest of this memo is structured as follows.  Section 2 defines
   the central keywords, notation, and terms used throughout the rest of
   the document.  Section 3 defines the structure of the Host Identity
   and its various representations.  Section 4 gives an overview of the
   HIP base exchange protocol.  Sections 5 and 6 define the detailed
   packet formats and rules for packet processing.  Finally, Sections 7,
   8, and 9 discuss policy, security, and IANA considerations,
   respectively.

2.  Terms and Definitions

2.1.  Requirements Terminology

   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].

Top      ToC       Page 8 
2.2.  Notation

   [x]    indicates that x is optional.

   {x}    indicates that x is encrypted.

   X(y)   indicates that y is a parameter of X.

   <x>i   indicates that x exists i times.

   -->    signifies "Initiator to Responder" communication (requests).

   <--    signifies "Responder to Initiator" communication (replies).

   |      signifies concatenation of information (e.g., X | Y is the
          concatenation of X with Y).

   Ltrunc (H(x), #K)
          denotes the lowest-order #K bits of the result of the
          hash function H on the input x.

2.3.  Definitions

   HIP base exchange (BEX):  The handshake for establishing a new HIP
      association.

   Host Identity (HI):  The public key of the signature algorithm that
      represents the identity of the host.  In HIP, a host proves its
      identity by creating a signature with the private key belonging to
      its HI (cf. Section 3).

   Host Identity Tag (HIT):  A shorthand for the HI in IPv6 format.  It
      is generated by hashing the HI (cf. Section 3.1).

   HIT Suite:  A HIT Suite groups all cryptographic algorithms that are
      required to generate and use an HI and its HIT.  In particular,
      these algorithms are 1) the public key signature algorithm, 2) the
      hash function, and 3) the truncation (cf. Appendix E).

   HIP association:  The shared state between two peers after completion
      of the BEX.

   HIP packet:  A control packet carrying a HIP packet header relating
      to the establishment, maintenance, or termination of the HIP
      association.

   Initiator:  The host that initiates the BEX.  This role is typically
      forgotten once the BEX is completed.

Top      ToC       Page 9 
   Responder:  The host that responds to the Initiator in the BEX.  This
      role is typically forgotten once the BEX is completed.

   Responder's HIT hash algorithm (RHASH):  The hash algorithm used for
      various hash calculations in this document.  The algorithm is the
      same as is used to generate the Responder's HIT.  The RHASH is the
      hash function defined by the HIT Suite of the Responder's HIT
      (cf. Section 5.2.10).

   Length of the Responder's HIT hash algorithm (RHASH_len):  The
      natural output length of RHASH in bits.

   Signed data:  Data that is signed is protected by a digital signature
      that was created by the sender of the data by using the private
      key of its HI.

   KDF:  The Key Derivation Function (KDF) is used for deriving the
      symmetric keys from the Diffie-Hellman key exchange.

   KEYMAT:  The keying material derived from the Diffie-Hellman key
      exchange by using the KDF.  Symmetric keys for encryption and
      integrity protection of HIP packets and encrypted user data
      packets are drawn from this keying material.

3.  Host Identity (HI) and Its Structure

   In this section, the properties of the Host Identity and Host
   Identity Tag are discussed, and the exact format for them is defined.
   In HIP, the public key of an asymmetric key pair is used as the Host
   Identity (HI).  Correspondingly, the host itself is defined as the
   entity that holds the private key of the key pair.  See the HIP
   architecture specification [HIP-ARCH] for more details on the
   difference between an identity and the corresponding identifier.

   HIP implementations MUST support the Rivest Shamir Adleman [RSA]
   public key algorithm and the Elliptic Curve Digital Signature
   Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9.
   Additional algorithms MAY be supported.

   A hashed encoding of the HI, the Host Identity Tag (HIT), is used in
   protocols to represent the Host Identity.  The HIT is 128 bits long
   and has the following three key properties: i) it is the same length
   as an IPv6 address and can be used in fixed address-sized fields in
   APIs and protocols; ii) it is self-certifying (i.e., given a HIT, it
   is computationally hard to find a Host Identity key that matches the
   HIT); and iii) the probability of a HIT collision between two hosts

Top      ToC       Page 10 
   is very low; hence, it is infeasible for an attacker to find a
   collision with a HIT that is in use.  For details on the security
   properties of the HIT, see [HIP-ARCH].

   The structure of the HIT is defined in [RFC7343].  The HIT is an
   Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists
   of three parts: first, an IANA-assigned prefix to distinguish it from
   other IPv6 addresses; second, a four-bit encoding of the algorithms
   that were used for generating the HI and the hashed representation of
   HI; third, a 96-bit hashed representation of the Host Identity.  The
   encoding of the ORCHID generation algorithm and the exact algorithm
   for generating the hashed representation are specified in Appendix E
   and [RFC7343].

   Carrying HIs and HITs in the header of user data packets would
   increase the overhead of packets.  Thus, it is not expected that they
   are carried in every packet, but other methods are used to map the
   data packets to the corresponding HIs.  In some cases, this makes it
   possible to use HIP without any additional headers in the user data
   packets.  For example, if ESP is used to protect data traffic, the
   Security Parameter Index (SPI) carried in the ESP header can be used
   to map the encrypted data packet to the correct HIP association.

3.1.  Host Identity Tag (HIT)

   The Host Identity Tag is a 128-bit value -- a hashed encoding of the
   Host Identifier.  There are two advantages of using a hashed encoding
   over the actual variable-sized Host Identity public key in protocols.
   First, the fixed length of the HIT keeps packet sizes manageable and
   eases protocol coding.  Second, it presents a consistent format for
   the protocol, independent of the underlying identity technology
   in use.

   RFC 7343 [RFC7343] specifies 128-bit hash-based identifiers, called
   ORCHIDs.  Their prefix, allocated from the IPv6 address block, is
   defined in [RFC7343].  The Host Identity Tag is one type of ORCHID.

   This document extends the original, experimental HIP specification
   [RFC5201] with measures to support crypto agility.  One of these
   measures allows different hash functions for creating a HIT.  HIT
   Suites group the sets of algorithms that are required to generate and
   use a particular HIT.  The Suites are encoded in HIT Suite IDs.
   These HIT Suite IDs are transmitted in the ORCHID Generation
   Algorithm (OGA) field in the ORCHID.  With the HIT Suite ID in the
   OGA ID field, a host can tell, from another host's HIT, whether it
   supports the necessary hash and signature algorithms to establish a
   HIP association with that host.

Top      ToC       Page 11 
3.2.  Generating a HIT from an HI

   The HIT MUST be generated according to the ORCHID generation method
   described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4
   3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly
   by the editor of this specification), and an input that encodes the
   Host Identity field (see Section 5.2.9) present in a HIP payload
   packet.  The set of hash function, signature algorithm, and the
   algorithm used for generating the HIT from the HI depends on the HIT
   Suite (see Section 5.2.10) and is indicated by the four bits of the
   OGA ID field in the ORCHID.  Currently, truncated SHA-1, truncated
   SHA-384, and truncated SHA-256 [FIPS.180-4.2012] are defined as
   hashes for generating a HIT.

   For identities that are either RSA, Digital Signature Algorithm (DSA)
   [FIPS.186-4.2013], or Elliptic Curve DSA (ECDSA) public keys, the
   ORCHID input consists of the public key encoding as specified for the
   Host Identity field of the HOST_ID parameter (see Section 5.2.9).
   This document defines four algorithm profiles: RSA, DSA, ECDSA, and
   ECDSA_LOW.  The ECDSA_LOW profile is meant for devices with low
   computational capabilities.  Hence, one of the following applies:

      The RSA public key is encoded as defined in [RFC3110], Section 2,
      taking the exponent length (e_len), exponent (e), and modulus (n)
      fields concatenated.  The length (n_len) of the modulus (n) can be
      determined from the total HI Length and the preceding HI fields
      including the exponent (e).  Thus, the data that serves as input
      for the HIT generation has the same length as the HI.  The fields
      MUST be encoded in network byte order, as defined in [RFC3110].

      The DSA public key is encoded as defined in [RFC2536], Section 2,
      taking the fields T, Q, P, G, and Y, concatenated as input.  Thus,
      the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long,
      where T is the size parameter as defined in [RFC2536].  The size
      parameter T, affecting the field lengths, MUST be selected as the
      minimum value that is long enough to accommodate P, G, and Y.  The
      fields MUST be encoded in network byte order, as defined in
      [RFC2536].

      The ECDSA public keys are encoded as defined in Sections 4.2 and 6
      of [RFC6090].

   In Appendix B, the public key encoding process is illustrated using
   pseudo-code.


Next RFC Part