RFC 7401
Host Identity Protocol Version 2 (HIPv2)
Pages: 128
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Part 1 of 5 – Pages 1 to 11
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.
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
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
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
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 ...............................................1281. 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
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.
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].
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.
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
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.
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)