Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7401

Host Identity Protocol Version 2 (HIPv2)

Pages: 128
Proposed Standard
Errata
Obsoletes:  5201
Updated by:  80029374
Part 1 of 5 – Pages 1 to 11
None   None   Next

Top   ToC   RFC7401 - 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.
Top   ToC   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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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   RFC7401 - 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 page on part 2)

Next Section