idnits 2.17.1 draft-ietf-hip-dex-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 121 has weird spacing: '...ication dur...' -- The document date (March 21, 2016) is 2958 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-13 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP WG R. Moskowitz, Ed. 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track R. Hummen 5 Expires: September 22, 2016 COMSYS, RWTH Aachen 6 March 21, 2016 8 HIP Diet EXchange (DEX) 9 draft-ietf-hip-dex-01 11 Abstract 13 This document specifies the Host Identity Protocol Diet EXchange (HIP 14 DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The 15 HIP DEX protocol design aims at reducing the overhead of the employed 16 cryptographic primitives by omitting public-key signatures and hash 17 functions. In doing so, the main goal is to still deliver similar 18 security properties to HIPv2. 20 The HIP DEX protocol is primarily designed for computation or memory- 21 constrained sensor/actuator devices. Like HIPv2, it is expected to 22 be used together with a suitable security protocol such as the 23 Encapsulated Security Payload (ESP) for the protection of upper layer 24 protocol data. In addition, HIP DEX can also be used as a keying 25 mechanism for security primitives at the MAC layer, e.g., for IEEE 26 802.15.4 networks. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 22, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4 64 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 67 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 70 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 71 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 8 72 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9 74 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 10 75 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 11 76 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 15 77 4.1.4. User Data Considerations . . . . . . . . . . . . . . 16 78 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 16 80 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 16 81 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 17 82 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 17 83 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 18 84 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 18 85 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 18 86 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 19 87 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 20 88 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 21 89 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 23 90 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 24 91 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 25 92 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 25 93 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 25 94 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 26 95 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 26 96 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 27 97 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 30 98 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 30 99 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 31 100 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 34 101 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 37 102 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 38 103 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 39 104 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 39 105 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 39 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 108 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 109 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 41 110 11.1. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 41 111 11.2. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 41 112 11.3. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 41 113 11.4. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 42 114 11.5. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 42 115 11.6. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 42 116 11.7. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 43 117 11.8. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 43 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 119 12.1. Normative References . . . . . . . . . . . . . . . . . . 43 120 12.2. Informative References . . . . . . . . . . . . . . . . . 44 121 Appendix A. Password-based two-factor authentication during 122 the HIP DEX handshake . . . . . . . . . . . . . . . 47 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 125 1. Introduction 127 This document specifies the Host Identity Protocol Diet EXchange (HIP 128 DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity 129 Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol 130 semantics as well as the general packet structure of HIPv2. Hence, 131 it is recommended that [RFC7401] is well-understood before reading 132 this document. 134 The main differences between HIP BEX and HIP DEX are: 136 1. Minimum collection of cryptographic primitives to reduce the 137 protocol overhead. 139 * Static Elliptic Curve Diffie-Hellman key pairs for peer 140 authentication and encryption of the session key. 142 * AES-CTR for symmetric encryption and AES-CMAC for MACing 143 function. 145 * A simple fold function for HIT generation. 147 2. Forfeit of Perfect Forward Secrecy with the dropping of an 148 ephemeral Diffie-Hellman key agreement. 150 3. Forfeit of digital signatures with the removal of a hash 151 function. Reliance on ECDH derived key used in HIP_MAC to prove 152 ownership of the private key. 154 4. Diffie-Hellman derived key ONLY used to protect the HIP packets. 155 A separate secret exchange within the HIP packets creates the 156 session key(s). 158 5. Optional retransmission strategy tailored to handle the 159 potentially extensive processing time of the employed 160 cryptographic operations on computationally constrained devices. 162 By eliminating the need for public-key signatures and the ephemeral 163 DH key agreement, HIP DEX reduces the computation, energy, 164 transmission, and memory requirements for public-key cryptography 165 (see [LN08]) in the HIPv2 protocol design. Moreover, by dropping the 166 cryptographic hash function, HIP DEX affords a more efficient 167 protocol implementation than HIP BEX with respect to the 168 corresponding computation and memory requirements. This makes HIP 169 DEX especially suitable for constrained devices as defined in 170 [RFC7228]. 172 This document focuses on the protocol specifications related to 173 differences between HIP BEX and HIP DEX. Where differences are not 174 called out explicitly, the protocol specification of HIP DEX is the 175 same as defined in [RFC7401]. 177 1.1. The HIP Diet EXchange (DEX) 179 The HIP Diet EXchange is a two-party cryptographic protocol used to 180 establish a secure communication context between hosts. The first 181 party is called the Initiator and the second party the Responder. 182 The four-packet exchange helps to make HIP DEX DoS resilient. The 183 Initiator and the Responder exchange their static Elliptic Curve 184 Diffie-Hellman (ECDH) keys in the 2nd and 3rd handshake packet. The 185 parties then authenticate each other in the 3rd and 4th handshake 186 packet based on the ECDH-derived keying material. The Initiator and 187 the Responder additionally transmit keying material for the session 188 key in these last two handshake packets. This is to prevent overuse 189 of the static ECDH-derived keying material. Moreover, the Responder 190 starts a puzzle exchange in the 2nd packet and the Initiator 191 completes this exchange in the 3rd packet before the Responder 192 performs computationally expensive operations or stores any state 193 from the exchange. Given this handshake structure, HIP DEX 194 operationally is very similar to HIP BEX. Moreover, the employed 195 model is also fairly equivalent to 802.11-2007 [IEEE.802-11.2007] 196 Master Key and Pair-wise Transient Key, but handled in a single 197 exchange. 199 HIP DEX does not have the option to encrypt the Host Identity of the 200 Initiator in the 3rd packet. The Responder's Host Identity also is 201 not protected. Thus, contrary to HIPv2, there is no attempt at 202 anonymity. 204 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 205 packets may carry data payload in the future. However, the details 206 of this may be defined later. 208 An existing HIP association can be updated with the update mechanism 209 defined in [RFC7401]. Likewise, the association can be torn down 210 with the defined closing mechanism for HIPv2 if it is no longer 211 needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the 212 original HIPv2 specification. 214 Finally, HIP DEX is designed as an end-to-end authentication and key 215 establishment protocol. As such, it can be used in combination with 216 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 217 end-to-end security protocols. In addition, HIP DEX can also be used 218 as a keying mechanism for security primitives at the MAC layer, e.g., 219 for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth 220 mentioning that the HIP DEX base protocol does not cover all the 221 fine-grained policy control found in Internet Key Exchange Version 2 222 (IKEv2) [RFC5996] that allows IKEv2 to support complex gateway 223 policies. Thus, HIP DEX is not a replacement for IKEv2. 225 1.2. Memo Structure 227 The rest of this memo is structured as follows. Section 2 defines 228 the central keywords, notation, and terms used throughout this 229 document. Section 3 defines the structure of the Host Identity and 230 its various representations. Section 4 gives an overview of the HIP 231 Diet EXchange protocol. Sections 5 and 6 define the detailed packet 232 formats and rules for packet processing. Finally, Sections 7, 8, and 233 9 discuss policy, security, and IANA considerations, respectively. 235 2. Terms and Definitions 237 2.1. Requirements Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in RFC 2119 [RFC2119]. 243 2.2. Notation 245 [x] indicates that x is optional. 247 {x} indicates that x is encrypted. 249 X(y) indicates that y is a parameter of X. 251 i indicates that x exists i times. 253 --> signifies "Initiator to Responder" communication (requests). 255 <-- signifies "Responder to Initiator" communication (replies). 257 | signifies concatenation of information - e.g., X | Y is the 258 concatenation of X and Y. 260 FOLD (X, K) denotes the partitioning of X into n K-bit segments and 261 the iterative folding of these segments via XOR. I.e., X = x_1, 262 x_2, ..., x_n, where x_i is of length K and the last segment x_n 263 is padded to length K by appending 0 bits. FOLD then is computed 264 as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 266 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 267 the MAC function M on the input x. 269 2.3. Definitions 271 HIP Diet Exchange (DEX): The ECDH-based HIP handshake for 272 establishing a new HIP association. 274 Host Identity (HI): The static ECDH public key that represents the 275 identity of the host. In HIP DEX, a host proves ownership of the 276 private key belonging to its HI by creating a HIP_MAC with the 277 derived ECDH key (c.f. Section 3). 279 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 280 is generated by folding the HI (c.f. Section 3). 282 HIT Suite: A HIT Suite groups all algorithms that are required to 283 generate and use an HI and its HIT. In particular, these 284 algorithms are: 1) ECDH and 2) FOLD. 286 HIP association: The shared state between two peers after completion 287 of the HIP DEX handshake. 289 Initiator: The host that initiates the HIP DEX handshake. This role 290 is typically forgotten once the handshake is completed. 292 Responder: The host that responds to the Initiator in the HIP DEX 293 handshake. This role is typically forgotten once the handshake is 294 completed. 296 Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is 297 redefined as CMAC. Still, note that CMAC is a message 298 authentication code and not a cryptographic hash function. Thus, 299 a mapping from CMAC(x,y) to RHASH(z) must be defined where RHASH 300 is used. Moreover, RHASH has different security properties in HIP 301 DEX and is not used for HIT generation. 303 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 304 natural output length of RHASH in bits. 306 CKDF: CMAC-based Key Derivation Function. 308 3. Host Identity (HI) and its Structure 310 In this section, the properties of the Host Identity and Host 311 Identity Tag are discussed, and the exact format for them is defined. 312 In HIP, the public key of an asymmetric key pair is used as the Host 313 Identity (HI). Correspondingly, the host itself is defined as the 314 entity that holds the private key of the key pair. See the HIP 315 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 316 details on the difference between an identity and the corresponding 317 identifier. 319 HIP DEX implementations MUST support the Elliptic Curve Diffie- 320 Hellman (ECDH) [RFC6090] key exchange for generating the HI as 321 defined in Section 5.2.3. No additional algorithms are supported at 322 this time. 324 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 325 in the handshake packets to represent the HI. The DEX Host Identity 326 Tag (HIT) is different from the BEX HIT in two ways: 328 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). 330 o The DEX HIT is not generated via a cryptographic hash. Rather, it 331 is a compression of the HI. 333 Due to the latter property, an attacker may be able to find a 334 collision with a HIT that is in use. Hence, policy decisions such as 335 access control MUST NOT be based solely on the HIT. Instead, the HI 336 of a host SHOULD be considered. 338 Carrying HIs and HITs in the header of user data packets would 339 increase the overhead of packets. Thus, it is not expected that 340 these parameters are carried in every packet, but other methods are 341 used to map the data packets to the corresponding HIs. In some 342 cases, this allows to use HIP DEX without any additional headers in 343 the user data packets. For example, if ESP is used to protect data 344 traffic, the Security Parameter Index (SPI) carried in the ESP header 345 can be used to map the encrypted data packet to the correct HIP DEX 346 association. 348 3.1. Host Identity Tag (HIT) 350 With HIP DEX, the HIT is a 128-bit value - a compression of the HI 351 prepended with a specific prefix. There are two advantages of using 352 a hashed encoding over the actual variable-sized public key in 353 protocols. First, the fixed length of the HIT keeps packet sizes 354 manageable and eases protocol coding. Second, it presents a 355 consistent format for the protocol, independent of the underlying 356 identity technology in use. 358 The structure of the HIT is based on RFC 7343 [RFC7343], called 359 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 360 consists of three parts: first, an IANA assigned prefix to 361 distinguish it from other IPv6 addresses. Second, a four-bit 362 encoding of the algorithms that were used for generating the HI and 363 the compressed representation of the HI. Third, a 96-bit hashed 364 representation of the HI. In contrast to HIPv2, HIP DEX employs HITs 365 that are NOT generated by means of a cryptographic hash. Instead, 366 the HI is compressed to 96 bits as defined in the following section. 368 3.2. Generating a HIT from an HI 370 The HIT does not follow the exact semantics of an ORCHID as there is 371 no hash function in HIP DEX. Still, its structure is strongly 372 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 373 is used for HIP DEX. The HIP DEX HIT suite (see Section 9) is used 374 for the four bits of the Orchid Generation Algorithm (OGA) field in 375 the ORCHID. The hash representation in an ORCHID is replaced with 376 FOLD(HI,96). 378 4. Protocol Overview 380 This section gives a simplified overview of the HIP DEX protocol 381 operation and does not contain all the details of the packet formats 382 or the packet processing steps. Section 5 and Section 6 describe 383 these aspects in more detail and are normative in case of any 384 conflicts with this section. Importantly, the information given in 385 this section focuses on the differences between the HIPv2 and HIP DEX 386 protocol specifications. 388 4.1. Creating a HIP Association 390 By definition, the system initiating a HIP Diet EXchange is the 391 Initiator, and the peer is the Responder. This distinction is 392 typically forgotten once the handshake completes, and either party 393 can become the Initiator in future communications. 395 The HIP Diet EXchange serves to manage the establishment of state 396 between an Initiator and a Responder. The first packet, I1, 397 initiates the exchange, and the last three packets, R1, I2, and R2, 398 constitute an authenticated Diffie-Hellman [DH76] key exchange for 399 the Master Key SA generation. This Master Key SA is used by the 400 Initiator and the Responder to wrap secret keying material in the I2 401 and R2 packets. Based on the exchanged keying material, the peers 402 then derive a Pair-wise Key SA if cryptographic keys are needed, 403 e.g., for ESP-based protection of user data. 405 The Initiator first sends a trigger packet, I1, to the Responder. 406 This packet contains the HIT of the Initiator and the HIT of the 407 Responder, if it is known. Moreover, the I1 packet initializes the 408 negotiation of the Diffie-Hellman group that is used for generating 409 the the Master Key SA. Therefore, the I1 packet contains a list of 410 Diffie-Hellman Group IDs supported by the Initiator. Note that in 411 some cases it may be possible to replace this trigger packet by some 412 other form of a trigger, in which case the protocol starts with the 413 Responder sending the R1 packet. In such cases, another mechanism to 414 convey the Initiator's supported DH Groups (e.g., by using a default 415 group) must be specified. 417 The second packet, R1, starts the actual authenticated Diffie-Hellman 418 key exchange. It contains a puzzle - a cryptographic challenge that 419 the Initiator must solve before continuing the exchange. The level 420 of difficulty of the puzzle can be adjusted based on level of trust 421 with the Initiator, current load, or other factors. In addition, the 422 R1 contains the Responder's Diffie-Hellman parameter and lists of 423 cryptographic algorithms supported by the Responder. Based on these 424 lists, the Initiator can continue, abort, or restart the handshake 425 with a different selection of cryptographic algorithms. 427 In the I2 packet, the Initiator MUST display the solution to the 428 received puzzle. Without a correct solution, the I2 packet is 429 discarded. The I2 also contains a key wrap parameter that carries a 430 secret keying material of the Initiator. This keying material is 431 only half the final session key. The packet is authenticated by the 432 sender (Initiator) via a MAC. 434 The R2 packet acknowledges the receipt of the I2 packet and completes 435 the handshake. The R2 contains a key wrap parameter that carries the 436 rest of the keying material of the Responder. The packet is 437 authenticated by the sender (Responder) via a MAC. 439 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 440 and "ENC(DH,y)" refer to the random values x and y that are wrapped 441 based on the Master Key SA (indicated by ENC and DH). Note that x 442 and y each constitute half the final session key material. The 443 packets also contain other parameters that are not shown in this 444 figure. 446 Initiator Responder 448 I1: 449 ---------------------------------> 450 remain stateless 451 R1: puzzle, HI 452 <-------------------------------- 453 solve puzzle 454 perform ECDH 455 encrypt x 456 I2: solution, HI, ENC(DH,x), mac 457 ---------------------------------> 458 check puzzle 459 perform ECDH 460 check mac 461 decrypt x 462 encrypt y 463 R2: ENC(DH,y), mac 464 <--------------------------------- 465 check mac 466 decrypt y 468 4.1.1. HIP Puzzle Mechanism 470 The purpose of the HIP puzzle mechanism is to protect the Responder 471 from a number of denial-of-service threats. It allows the Responder 472 to delay state creation until receiving the I2 packet. Furthermore, 473 the puzzle allows the Responder to use a fairly cheap calculation to 474 check that the Initiator is "sincere" in the sense that it has 475 churned enough CPU cycles in solving the puzzle. 477 The puzzle mechanism enables a Responder to immediately reject an I2 478 packet if it does not contain a valid puzzle solution. To verify the 479 puzzle solution, the Responder only has to compute a single CMAC 480 operation. After a successful puzzle verification, the Responder can 481 securely create session-specific state and perform CPU-intensive 482 operations such as a Diffie-Hellman key generation. By varying the 483 difficulty of the puzzle, the Responder can frustrate CPU or memory 484 targeted DoS attacks. Under normal network conditions, the puzzle 485 difficulty SHOULD be zero, thus effectively reverting the puzzle 486 mechanism to a cookie-based DoS protection mechanism. Without 487 setting the puzzle difficulty to zero under normal network 488 conditions, potentially scarce computation resources at the Initiator 489 would be churned unnecessarily. 491 Conceptually, the puzzle mechanism in HIP DEX is the same as in 492 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 493 [RFC7401] for more detailed information about the employed mechanism. 494 Notably, the only difference between the puzzle mechanism in HIP DEX 495 and HIPv2 is that HIP DEX uses CMAC instead of a hash function for 496 solving and verifying a puzzle. The implications of this change on 497 the puzzle implementation are discussed in Section 6.1. 499 4.1.2. HIP State Machine 501 The HIP DEX state machine has the same states as the HIPv2 state 502 machine (see 4.4. in [RFC7401]). However, HIP DEX features a 503 retransmission strategy with an optional reception acknowledgement 504 for the I2 packet. The goal of this additional acknowledgement is to 505 reduce premature I2 retransmissions in case of devices with low 506 computation resources [HWZ13]. As a result, there are minor changes 507 regarding the transitions in the HIP DEX state machine. The 508 following section documents these differences compared to HIPv2. 510 4.1.2.1. HIP DEX Retransmission Mechanism 512 For the retransmission of I1 and I2 packets, the Initiator adopts the 513 retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). 514 This strategy is based on a timeout that is set to a value larger 515 than the worst-case anticipated round-trip time (RTT). For each 516 received I1 or I2 packet, the Responder sends an R1 or R2 packet, 517 respectively. This design trait enables the Responder to remain 518 stateless until the reception and successful processing of the I2 519 packet. The Initiator stops retransmitting I1 or I2 packets after 520 the reception of the corresponding R1 or R2. If the Initiator did 521 not receive an R1 packet after I1_RETRIES_MAX tries, it stops I1 522 retransmissions. Likewise, it stops retransmitting the I2 packet 523 after I2_RETRIES_MAX unsuccessful tries. 525 For repeatedly received I2 packets, the Responder SHOULD NOT perform 526 operations related to the Diffie-Hellman key exchange or the keying 527 material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD 528 re-use the previously established state to re-create the 529 corresponding R2 packet in order to prevent unnecessary computation 530 overhead. 532 The potentially high processing time of an I2 packet at a (resource- 533 constrained) Responder may cause premature retransmissions if the 534 time required for I2 transmission and processing exceeds the RTT- 535 based retransmission timeout. Thus, the Initiator should also take 536 the processing time of the I2 packet at the Responder into account 537 for retransmission purposes. To this end, the Responder MAY notify 538 the Initiator about the anticipated delay once the puzzle solution 539 was successfully verified and if the remaining I2 packet processing 540 incurs a high processing delay. The Responder MAY therefore send a 541 NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator 542 before the Responder commences the ECDH operation. The NOTIFY packet 543 serves as an acknowledgement for the I2 packet and consists of a 544 NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 545 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 546 contains the anticipated remaining processing time for the I2 packet 547 in milliseconds as two-octet Notification Data. This processing time 548 can, e.g., be estimated by measuring the computation time of the ECDH 549 key derivation operation at Responder boot-up. After the I2 550 processing has finished, the Responder sends the regular R2 packet. 552 When the Initiator receives the NOTIFY packet, it sets the I2 553 retransmission timeout to the I2 processing time indicated in the 554 NOTIFICATION parameter plus half the RTT-based timeout value. In 555 doing so, the Initiator MUST NOT set the retransmission timeout to a 556 higher value than allowed by a local policy. This is to prevent 557 unauthenticated NOTIFY packets from maliciously delaying the 558 handshake beyond a well-defined upper bound in case of a lost R2 559 packet. At the same time, this extended retransmission timeout 560 enables the Initiator to defer I2 retransmissions until the point in 561 time when the Responder should have completed its I2 packet 562 processing and the network should have delivered the R2 packet 563 according to the employed worst-case estimates. 565 4.1.2.2. HIP State Processes 567 HIP DEX clarifies or introduces the following new transitions. 569 System behavior in state I2-SENT, Table 1. 571 +---------------------+---------------------------------------------+ 572 | Trigger | Action | 573 +---------------------+---------------------------------------------+ 574 | Receive NOTIFY, | Set I2 retransmission timer to value in | 575 | process | I2_ACKNOWLEDGEMENT Notification Data plus | 576 | | 1/2 RTT-based timeout value and stay at | 577 | | I2-SENT | 578 | | | 579 | Timeout | Increment trial counter | 580 | | | 581 | | If counter is less than I2_RETRIES_MAX, | 582 | | send I2, reset timer to RTT-based timeout, | 583 | | and stay at I2-SENT | 584 | | | 585 | | If counter is greater than I2_RETRIES_MAX, | 586 | | go to E-FAILED | 587 +---------------------+---------------------------------------------+ 589 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 591 4.1.2.3. Simplified HIP State Diagram 593 The following diagram shows the major state transitions. Transitions 594 based on received packets implicitly assume that the packets are 595 successfully authenticated or processed. 597 +--+ +----------------------------+ 598 recv I1, send R1 | | | | 599 | v v | 600 +--------------+ recv I2, send R2 | 601 +----------------| UNASSOCIATED |----------------+ | 602 datagram | +--+ +--------------+ | | 603 to send, | | | Alg. not supported, | | 604 send I1 | | | send I1 | | 605 . v | v | | 606 . +---------+ recv I2, send R2 | | 607 +---->| I1-SENT |--------------------------------------+ | | 608 | +---------+ +----------------------+ | | | 609 | | recv R1, | recv I2, send R2 | | | | 610 | v send I2 | v v v | 611 | +---------+ | +---------+ | 612 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 613 | | +---------+ | +---------+ | | 614 | | | |recv R2 | data or| | | 615 | |recv R1, | | | EC timeout| | | 616 | |send I2 +--|-----------------+ | receive I2,| | 617 | | | | +-------------+ | send R2| | 618 | | | +------>| ESTABLISHED |<----------+ | | 619 | | | +-------------+ | | 620 | | | | | | receive I2, send R2 | | 621 | | +------------+ | +-------------------------------+ | 622 | | | +-----------+ | | 623 | | | no packet sent/received| +---+ | | 624 | | | for UAL min, send CLOSE| | |timeout | | 625 | | | v v |(UAL+MSL) | | 626 | | | +---------+ |retransmit | | 627 +--|----------|------------------------| CLOSING |-+CLOSE | | 628 | | +---------+ | | 629 | | | | | | | | 630 +----------|-------------------------+ | | +----------------+ | 631 | | +-----------+ +------------------|--+ 632 | | |recv CLOSE, recv CLOSE_ACK | | 633 | +-------------+ |send CLOSE_ACK or timeout | | 634 | recv CLOSE, | | (UAL+MSL) | | 635 | send CLOSE_ACK v v | | 636 | +--------+ receive I2, send R2 | | 637 +---------------------| CLOSED |------------------------------+ | 638 +--------+ | 639 ^ | | | 640 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 641 +-+ +------------------------------------+ 643 4.1.3. HIP DEX Security Associations 645 HIP DEX establishes two Security Associations (SA), one for the 646 Diffie-Hellman derived key, or Master Key, and one for the session 647 key, or Pair-wise Key. 649 4.1.3.1. Master Key SA 651 The Master Key SA is used to authenticate HIP packets and to encrypt 652 selected HIP parameters in the HIP DEX packet exchanges. Since only 653 little data is protected by this SA, it can be long-lived with no 654 need for rekeying. 656 The Master Key SA contains the following elements: 658 o Source HIT 660 o Destination HIT 662 o HIP_Encrypt Key 664 o HIP_MAC Key 666 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 667 Hellman derived key as described in Section 6.3. Their length is 668 determined by the HIP_CIPHER. 670 4.1.3.2. Pair-wise Key SA 672 The Pair-wise Key SA is used to authenticate and to encrypt user 673 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 674 The Pair-wise Key SA elements are defined by the data transform (e.g. 675 ESP_TRANSFORM [RFC7402]). 677 The keys for the Pair-wise Key SA are derived based on the wrapped 678 keying material exchanged in the ENCRYPTED_KEY parameter (see 679 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 680 keying material of the two peers is concatenated. This concatenation 681 forms the input to a Key Derivation Function (KDF). If the data 682 transform does not specify its own KDF, the key derivation function 683 defined in Section 6.3 is used. Even though this input is randomly 684 distributed, a KDF Extract phase may be needed to get the proper 685 length for the input to the KDF Expand phase. 687 4.1.4. User Data Considerations 689 The User Data Considerations in Section 4.5. of [RFC7401] also apply 690 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 691 Loss of state due to system reboot may be a critical performance 692 issue for resource-constrained devices. Thus, implementors MAY 693 choose to use non-volatile, secure storage for HIP states in order 694 for them to survive a system reboot. This will limit state loss 695 during reboots to only those situations with an SA timeout. 697 5. Packet Formats 699 5.1. Payload Format 701 HIP DEX employs the same fixed HIP header and payload structure as 702 HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also 703 apply to HIP DEX. 705 5.2. HIP Parameters 707 The HIP parameters carry information that is necessary for 708 establishing and maintaining a HIP association. For example, the 709 peer's public keys as well as the signaling for negotiating ciphers 710 and payload handling are encapsulated in HIP parameters. Additional 711 information, meaningful for end-hosts or middleboxes, may also be 712 included in HIP parameters. The specification of the HIP parameters 713 and their mapping to HIP packets and packet types is flexible to 714 allow HIP extensions to define new parameters and new protocol 715 behavior. 717 In HIP packets, HIP parameters are ordered according to their numeric 718 type number and encoded in TLV format. 720 HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of 721 [RFC7401] where possible. Still, HIP DEX further restricts and/or 722 extends the following existing parameter types: 724 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 726 o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. 728 o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. 730 o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, 731 SOLUTION, and HIP_MAC parameters (see Section 6.1 and 732 Section 6.2). 734 In addition, HIP DEX introduces the following new parameter: 736 +------------------+------+----------+------------------------------+ 737 | TLV | Type | Length | Data | 738 +------------------+------+----------+------------------------------+ 739 | ENCRYPTED_KEY | 643 | variable | Encrypted container for the | 740 | | | | session key exchange | 741 +------------------+------+----------+------------------------------+ 743 5.2.1. DH_GROUP_LIST 745 The DH_GROUP_LIST parameter contains the list of supported DH Group 746 IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With 747 HIP DEX, the DH Group IDs are restricted to: 749 Group KDF Value 751 NIST P-256 [RFC5903] CKDF 7 752 NIST P-384 [RFC5903] CKDF 8 753 NIST P-521 [RFC5903] CKDF 9 754 SECP160R1 [SECG] CKDF 10 755 Curve25519 [RFC7748] CKDF 11 756 Curve448 [RFC7748] CKDF 12 758 The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH 759 group 10 is covered in [SECG] and Appendix D of [RFC7401]. These 760 curves, when used with HIP MUST have a co-factor of 1. 762 The ECDH groups 11 and 12 are defined in [RFC7748]. These curves 763 have cofactors of 8 and 4 (respectively). 765 5.2.2. HIP_CIPHER 767 The HIP_CIPHER parameter contains the list of supported cipher 768 algorithms to be used for encrypting the contents of the ENCRYPTED 769 and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 770 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited 771 to: 773 Suite ID Value 775 RESERVED 0 776 NULL-ENCRYPT 1 ([RFC2410]) 777 AES-128-CTR 5 ([RFC3686]) 779 Mandatory implementation: AES-128-CTR. Implementors SHOULD support 780 NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT 781 offer or accept this value unless explicitly configured for testing/ 782 debugging of HIP. 784 5.2.3. HOST_ID 786 The HOST_ID parameter conveys the Host Identity (HI) along with 787 optional information about a host. It is defined in Section 5.2.9 of 788 [RFC7401]. 790 HIP DEX uses the public portion of a host's static ECDH key-pair as 791 the HI. Correspondingly, HIP DEX limits the HI algorithms to the 792 following profile: 794 Algorithm profiles Value 796 ECDH 11 [RFC6090] (REQUIRED) 798 HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 799 Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is 800 encoded in the "ECC curve" field of the HOST_ID parameter. The 801 supported DH Group IDs are defined in Section 5.2.1. 803 5.2.4. HIT_SUITE_LIST 805 The HIT_SUITE_LIST parameter contains a list of the supported HIT 806 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 807 Initiator can determine which source HIT Suite IDs are supported by 808 the Responder. The HIT_SUITE_LIST parameter is defined in 809 Section 5.2.10 of [RFC7401]. 811 The following HIT Suite IDs are defined for HIP DEX, and the 812 relationship between the four-bit ID value used in the OGA ID field 813 and the eight-bit encoding within the HIT_SUITE_LIST ID field is 814 clarified: 816 HIT Suite Four-bit ID Eight-bit encoding 818 ECDH/FOLD 8 0x80 820 Note that the HIP DEX HIT Suite ID allows the peers to distinguish a 821 HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond 822 with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP 823 DEX HIT. 825 5.2.5. ENCRYPTED_KEY 826 0 1 2 3 827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type | Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 / Encrypted value / 832 / / 833 / +-------------------------------+ 834 / | Padding | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Type 643 838 Length length in octets, excluding Type, Length, and 839 Padding 840 Encrypted The value is encrypted using an encryption algorithm 841 value as defined in the HIP_CIPHER parameter. 843 The ENCRYPTED_KEY parameter encapsulates a random value that is later 844 used in the session key creation process (see Section 6.3). This 845 random value MUST have a length of at least 64 bit. The puzzle value 846 #I and the puzzle solution #J (see [RFC7401]) are used as the 847 initialization vector (IV) for the encryption process. To this end, 848 the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16 849 bit value that is initialized to zero with the first use. 851 Once this encryption process is completed, the "encrypted value" data 852 field is ready for inclusion in the Parameter. If necessary, 853 additional Padding for 8-byte alignment is then added according to 854 the rules of TLV Format in [RFC7401]. 856 5.3. HIP Packets 858 HIP DEX uses the same eight basic HIP packets as HIPv2 (see 859 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake 860 (I1, R1, I2, and R2), one is for updating an association (UPDATE), 861 one is for sending notifications (NOTIFY), and two are for closing 862 the association (CLOSE and CLOSE_ACK). There are some differences 863 regarding the HIP parameters that are included in the handshake 864 packets concerning HIP BEX and HIP DEX. This section covers these 865 differences for the DEX packets. Packets not discussed here, follow 866 the structure defined in [RFC7401]. 868 An important difference between packets in HIP BEX and HIP DEX is 869 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 870 included in HIP DEX. Thus, the R1 packet is completely unprotected 871 and can be spoofed. As a result, negotiation parameters contained in 872 the R1 packet have to be re-included in later, protected packets in 873 order to detect and prevent potential downgrading attacks. Moreover, 874 the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not 875 covered by a signature and purely rely on the HIP_MAC parameter for 876 packet authentication. The processing of these packets is changed 877 accordingly. 879 In the future, an optional upper-layer payload MAY follow the HIP 880 header. The Next Header field in the header indicates if there is 881 additional data following the HIP header. 883 5.3.1. I1 - the HIP Initiator Packet 885 The HIP header values for the I1 packet: 887 Header: 888 Packet Type = 1 889 SRC HIT = Initiator's HIT 890 DST HIT = Responder's HIT, or NULL 892 IP ( HIP ( DH_GROUP_LIST ) ) 894 Valid control bits: none 896 The I1 packet contains the fixed HIP header and the Initiator's 897 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 898 type as defined in Section 5.2.4. 900 Regarding the Responder's HIT, the Initiator may receive this HIT 901 either from a DNS lookup of the Responder's FQDN, from some other 902 repository, or from a local table. The Responder's HIT also MUST be 903 of a HIP DEX type. If the Initiator does not know the Responder's 904 HIT, it may attempt to use opportunistic mode by using NULL (all 905 zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for 906 detailed information about the "HIP Opportunistic Mode". 908 As a compression of the employed HIs, the Initiator's and the 909 Responder's HITs both determine the DH group ID that must be used in 910 order to successfully conclude the triggered handshake. HITs, 911 however, only include the OGA ID identifying a HIP DEX HIT. They do 912 not include information about the specific DH group ID of the 913 corresponding HI. To inform the Responder about its employed and its 914 otherwise supported DH Group IDs, the Initiator therefore includes 915 the DH_GROUP_LIST parameter in the I1 packet. This parameter MUST 916 include the DH group ID that corresponds to the currently employed 917 Initiator HIT as the first list element. With HIP DEX, the 918 DH_GROUP_LIST parameter MUST only include ECDH groups defined in 919 Section 5.2.1. 921 Since this packet is so easy to spoof even if it were protected, no 922 attempt is made to add to its generation or processing cost. As a 923 result, the DH_GROUP_LIST in the I1 packet is not protected. 925 Implementations MUST be able to handle a storm of received I1 926 packets, discarding those with common content that arrive within a 927 small time delta. 929 5.3.2. R1 - the HIP Responder Packet 931 The HIP header values for the R1 packet: 933 Header: 934 Packet Type = 2 935 SRC HIT = Responder's HIT 936 DST HIT = Initiator's HIT 938 IP ( HIP ( [ R1_COUNTER, ] 939 PUZZLE, 940 DH_GROUP_LIST, 941 HIP_CIPHER, 942 HOST_ID, 943 HIT_SUITE_LIST, 944 TRANSPORT_FORMAT_LIST, 945 [ <, ECHO_REQUEST_UNSIGNED >i ]) 947 Valid control bits: A 949 If the Responder's HI is an anonymous one, the A control MUST be set. 951 The Initiator's HIT MUST match the one received in the I1 packet if 952 the R1 is a response to an I1. If the Responder has multiple HIs, 953 the Responder's HIT MUST match the Initiator's request. If the 954 Initiator used opportunistic mode, the Responder may select among its 955 HIs as described below. See Section 4.1.8 of [RFC7401] for detailed 956 information about the "HIP Opportunistic Mode". 958 The R1 packet generation counter is used to determine the currently 959 valid generation of puzzles. The value is increased periodically, 960 and it is RECOMMENDED that it is increased at least as often as 961 solutions to old puzzles are no longer accepted. 963 The Puzzle contains a Random value #I and the puzzle difficulty K. 964 The difficulty K indicates the number of lower-order bits, in the 965 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 966 SHOULD set K to zero by default and only increase the puzzle 967 difficulty to protect against a DoS attack targeting the HIP DEX 968 handshake. A puzzle difficulty of zero effectively turns the puzzle 969 mechanism into a return-routablility test and is strongly encouraged 970 during normal operation in order to conserve energy resources as well 971 as to prevent unnecessary handshake delay in case of a resource- 972 constrained Initiator. 974 The DH_GROUP_LIST parameter contains the Responder's order of 975 preference based on which it chose the ECDH key contained in the 976 HOST_ID parameter (see below). This allows the Initiator to 977 determine whether its own DH_GROUP_LIST in the I1 packet was 978 manipulated by an attacker. There is a further risk that the 979 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 980 packet cannot be authenticated in HI DEX. Thus, this parameter is 981 repeated in the R2 packet to allow for a final, cryptographically 982 secured validation. 984 The HIP_CIPHER contains the encryption algorithms supported by the 985 Responder to protect the key exchange, in the order of preference. 986 All implementations MUST support the AES-CTR [RFC3686]. 988 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 989 supported and preferred HIT Suites. It enables a Responder to notify 990 the Initiator about other available HIT suites than the one used in 991 the current handshake. Based on the received HIT_SUITE_LIST, the 992 Initiator MAY decide to abort the current handshake and initiate a 993 new handshake with a different mutually supported HIT suite. This 994 mechanism can, e.g., be used to move from an initial HIP DEX 995 handshake to a HIP BEX handshake for peers supporting both protocol 996 variants. 998 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 999 and the Responder HIT in the I1 packet. Specifically, if the I1 1000 contains a Responder HIT, the Responder verifies that this HIT 1001 matches the required DH group based on the received DH_GROUP_LIST 1002 parameter. In case of a positive result, the Responder selects the 1003 corresponding HOST_ID for inclusion in the R1 packet. Likewise, if 1004 the Responder HIT in the I1 packet is NULL (i.e., during an 1005 opportunistic handshake), the Responder chooses its HOST_ID according 1006 to the Initiator's employed DH group as indicated in the received 1007 DH_GROUP_LIST parameter and sets the source HIT in the R1 packet 1008 accordingly. If the Responder however does not support the DH group 1009 required by the Initiator or if the Responder HIT in the I1 packet 1010 does not match the required DH group, the Responder selects the 1011 mutually preferred and supported DH group based on the DH_GROUP_LIST 1012 parameter in the I1 packet. The Responder then includes the 1013 corresponding ECDH key in the HOST_ID parameter. This parameter also 1014 indicates the selected DH group. Moreover, the Responder sets the 1015 source HIT in the R2 packet based on the destination HIT from the I1 1016 packet. Based on the deviating DH group ID in the HOST_ID parameter, 1017 the Initiator then SHOULD abort the current handshake and initiate a 1018 new handshake with the mutually supported DH group as far as local 1019 policies (see Section 7) permit. 1021 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 1022 Responder's supported and preferred transport format types. The list 1023 allows the Initiator and the Responder to agree on a common type for 1024 payload protection. Currently, the only transport format defined is 1025 IPsec ESP [RFC7402]. 1027 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 1028 wants to receive unmodified in the corresponding response packet in 1029 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 1030 or more ECHO_REQUEST_UNSIGNED parameters. 1032 5.3.3. I2 - the Second HIP Initiator Packet 1034 The HIP header values for the I2 packet: 1036 Header: 1037 Type = 3 1038 SRC HIT = Initiator's HIT 1039 DST HIT = Responder's HIT 1041 IP ( HIP ( [R1_COUNTER,] 1042 SOLUTION, 1043 HIP_CIPHER, 1044 ENCRYPTED_KEY, 1045 HOST_ID, 1046 TRANSPORT_FORMAT_LIST, 1047 HIP_MAC, 1048 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1050 Valid control bits: A 1052 The HITs MUST match the ones used in the R1 packet. 1054 If the Initiator's HI is an anonymous one, the A control bit MUST be 1055 set. 1057 If present in the R1 packet, the Initiator MUST include an unmodified 1058 copy of the R1_COUNTER parameter into the I2 packet. 1060 The Solution contains the Random #I from the R1 packet and the 1061 computed #J value. The low-order #K bits of the RHASH(I | ... | J) 1062 MUST be zero. 1064 The HIP_CIPHER contains the single encryption transform selected by 1065 the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY 1066 parameters. The chosen cipher MUST correspond to one of the ciphers 1067 offered by the Responder in the R1. All implementations MUST support 1068 the AES-CTR transform [RFC3686]. 1070 The HOST_ID parameter contains the Initiator HI corresponding to the 1071 Initiator HIT. 1073 The ENCRYPTED_KEY parameter contains an Initiator generated random 1074 value that MUST be uniformly distributed. This random value is 1075 encrypted with the Master Key SA using the HIP_CIPHER encryption 1076 algorithm. 1078 The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque 1079 data copied from the corresponding echo request parameter(s). This 1080 parameter can also be used for two-factor password authentication as 1081 shown in Appendix A. 1083 The TRANSPORT_FORMAT_LIST parameter contains the single transport 1084 format type selected by the Initiator. The chosen type MUST 1085 correspond to one of the types offered by the Responder in the R1 1086 packet. Currently, the only transport format defined is the ESP 1087 transport format [RFC7402]. 1089 The MAC is calculated over the whole HIP envelope, excluding any 1090 parameters after the HIP_MAC parameter as described in Section 6.2. 1091 The Responder MUST validate the HIP_MAC parameter. 1093 5.3.4. R2 - the Second HIP Responder Packet 1095 The HIP header values for the R2 packet: 1097 Header: 1098 Packet Type = 4 1099 SRC HIT = Responder's HIT 1100 DST HIT = Initiator's HIT 1102 IP ( HIP ( DH_GROUP_LIST, 1103 HIP_CIPHER, 1104 ENCRYPTED_KEY, 1105 HIT_SUITE_LIST, 1106 TRANSPORT_FORMAT_LIST, 1107 HIP_MAC) 1109 Valid control bits: none 1111 The HITs used MUST match the ones used in the I2 packet. 1113 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1114 and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These 1115 parameters MUST be the same as included in the R1 packet. The 1116 parameter are re-included here because the R2 packet is MACed and 1117 thus cannot be altered by an attacker. For verification purposes, 1118 the Initiator re-evaluates the selected suites and compares the 1119 results against the chosen ones. If the re-evaluated suites do not 1120 match the chosen ones, the Initiator acts based on its local policy. 1122 The ENCRYPTED_KEY parameter contains an Responder generated random 1123 value that MUST be uniformly distributed. This random value is 1124 encrypted with the Master Key SA using the HIP_CIPHER encryption 1125 algorithm. 1127 The MAC is calculated over the whole HIP envelope, excluding any 1128 parameters after the HIP_MAC, as described in Section 6.2. The 1129 Initiator MUST validate the HIP_MAC parameter. 1131 5.4. ICMP Messages 1133 When a HIP implementation detects a problem with an incoming packet, 1134 and it either cannot determine the identity of the sender of the 1135 packet or does not have any existing HIP association with the sender 1136 of the packet, it MAY respond with an ICMP packet. Any such reply 1137 MUST be rate-limited as described in [RFC4443]. In most cases, the 1138 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1139 ICMPv6), with the Pointer field pointing to the field that caused the 1140 ICMP message to be generated. The problem cases specified in 1141 Section 5.4. of [RFC7401] also apply to HIP DEX. 1143 6. Packet Processing 1145 Due to the adopted protocol semantics and the inherited general 1146 packet structure, the packet processing in HIP DEX only differs from 1147 HIPv2 in very few places. Here, we focus on these differences and 1148 refer to Section 6 in [RFC7401] otherwise. 1150 The processing of outgoing and incoming application data remains the 1151 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1153 6.1. Solving the Puzzle 1155 The procedures for solving and verifying a puzzle in HIP DEX are 1156 strongly based on the corresponding procedures in HIPv2. The only 1157 exceptions are that HIP DEX does not use pre-computation of R1 1158 packets and that RHASH is set to CMAC. As a result, the pre- 1159 computation step in in Section 6.3 of [RFC7401] is skipped in HIP 1160 DEX. 1162 Moreover, the Initiator solves a puzzle by computing: 1163 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1165 Similarly, the Responder verifies a puzzle by computing: 1166 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1168 Apart from these modifications, the procedures defined in Section 6.3 1169 of [RFC7401] also apply for HIP DEX. 1171 6.2. HIP_MAC Calculation and Verification 1173 The following subsections define the actions for processing the 1174 HIP_MAC parameter. 1176 6.2.1. CMAC Calculation 1178 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1179 cryptographic function. The scope of the calculation for HIP_MAC is: 1181 CMAC: { HIP header | [ Parameters ] } 1183 where Parameters include all HIP parameters of the packet that is 1184 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1185 value - 1) and exclude parameters with Type values greater or equal 1186 to HIP_MAC's Type value. 1188 During HIP_MAC calculation, the following applies: 1190 o In the HIP header, the Checksum field is set to zero. 1192 o In the HIP header, the Header Length field value is calculated to 1193 the beginning of the HIP_MAC parameter. 1195 The parameter order is described in Section 5.2.1 of [RFC7401]. 1197 The CMAC calculation and verification process is as follows: 1199 Packet sender: 1201 1. Create the HIP packet, without the HIP_MAC or any other parameter 1202 with greater Type value than the HIP_MAC parameter has. 1204 2. Calculate the Header Length field in the HIP header. 1206 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1207 retrieved from KEYMAT as defined in Section 6.3. 1209 4. Add the HIP_MAC parameter to the packet and any parameter with 1210 greater Type value than the HIP_MAC's that may follow. 1212 5. Recalculate the Length field in the HIP header. 1214 Packet receiver: 1216 1. Verify the HIP header Length field. 1218 2. Remove the HIP_MAC parameter, as well as all other parameters 1219 that follow it with greater Type value, saving the contents if 1220 they will be needed later. 1222 3. Recalculate the HIP packet length in the HIP header and clear the 1223 Checksum field (set it to all zeros). 1225 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1226 defined in Section 6.3 and verify it against the received CMAC. 1228 5. Set Checksum and Header Length fields in the HIP header to 1229 original values. Note that the Checksum and Length fields 1230 contain incorrect values after this step. 1232 6.3. HIP DEX KEYMAT Generation 1234 The HIP DEX KEYMAT process is used to derive the keys for the Master 1235 Key SA as well as for the Pair-wise Key SA. The keys for the Master 1236 Key SA are based from the Diffie-Hellman derived key, Kij, produced 1237 during the HIP DEX handshake. The Initiator generates Kij during the 1238 creation of the I2 packet and the Responder generates Kij once it 1239 receives the I2 packet. Hence, I2, R2, UPDATE, CLOSE, and CLOSE_ACK 1240 packets can contain authenticated and/or encrypted information. 1242 The keys of the Pair-wise Key SA are not directly used in the HIP DEX 1243 handshake. Instead, these keys are made available as payload 1244 protection keys. Some payload protection mechanisms have their own 1245 Key Derivation Function, and if so this mechanism SHOULD be used. 1246 Otherwise, the HIP DEX KEYMAT process MUST be used to derive the keys 1247 of the Pair-wise Key SA based on the concatenation of the random 1248 values that are contained in the exchanged ENCRYPTED_KEY parameters. 1250 The HIP DEX KEYMAT process consists of two components, CKDF-Extract 1251 and CKDF-Expand. The Extract function compresses a non-uniformly 1252 distributed key, as is the output of a Diffie-Hellman key derivation, 1253 to extract the key entropy into a fixed length output. The Expand 1254 function takes either the output of the Extract function or directly 1255 uses a uniformly distributed key and expands the length of the key, 1256 repeatedly distributing the key entropy, to produce the keys needed. 1258 The key derivation for the Master Key SA employs both the Extract and 1259 Expand phases, whereas the Pair-wise Key SA MAY need both the Extract 1260 and Expand phases if the key is longer than 128 bits. Otherwise, it 1261 only requires the Expand phase. 1263 The CKDF-Extract function is the following operation: 1265 CKDF-Extract(I, IKM, info) -> PRK 1267 where 1269 I Random #I from the PUZZLE parameter 1270 IKM Input keying material, i.e., either the Diffie-Hellman 1271 derived key or the concatenation of the random values 1272 of the ENCRYPTED_KEY parameters in the same order as 1273 the HITs with sort(HIT-I | HIT-R) 1274 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1275 PRK a pseudorandom key (of RHASH_len/8 octets) 1276 | denotes the concatenation 1278 The pseudorandom key PRK is calculated as follows: 1280 PRK = CMAC(I, IKM | info) 1282 The CKDF-Expand function is the following operation: 1284 CKDF-Expand(PRK, info, L) -> OKM 1286 where 1288 PRK a pseudorandom key of at least RHASH_len/8 octets 1289 (either the output from the extract step or the 1290 concatenation of the random values of the 1291 ENCRYPTED_KEY parameters in the same order as the 1292 HITs with sort(HIT-I | HIT-R)) 1293 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1294 L length of output keying material in octets 1295 (<= 255*RHASH_len/8) 1296 | denotes the concatenation 1298 The output keying material OKM is calculated as follows: 1300 N = ceil(L/RHASH_len/8) 1301 T = T(1) | T(2) | T(3) | ... | T(N) 1302 OKM = first L octets of T 1304 where 1306 T(0) = empty string (zero length) 1307 T(1) = CMAC(PRK, T(0) | info | 0x01) 1308 T(2) = CMAC(PRK, T(1) | info | 0x02) 1309 T(3) = CMAC(PRK, T(2) | info | 0x03) 1310 ... 1312 (where the constant concatenated to the end of each T(n) is a 1313 single octet.) 1315 sort(HIT-I | HIT-R) is defined as the network byte order 1316 concatenation of the two HITs, with the smaller HIT preceding the 1317 larger HIT, resulting from the numeric comparison of the two HITs 1318 interpreted as positive (unsigned) 128-bit integers in network byte 1319 order. 1321 The initial keys are drawn sequentially in the order that is 1322 determined by the numeric comparison of the two HITs, with the 1323 comparison method described in the previous paragraph. HOST_g 1324 denotes the host with the greater HIT value, and HOST_l the host with 1325 the lower HIT value. 1327 The drawing order for initial keys: 1329 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1331 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1332 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1334 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1336 The number of bits drawn for a given algorithm is the "natural" size 1337 of the keys. For the mandatory algorithms, the following sizes 1338 apply: 1340 AES 128 or 256 bits 1342 If other key sizes are used, they must be treated as different 1343 encryption algorithms and defined separately. 1345 6.4. Initiation of a HIP Diet EXchange 1347 The initiation of a HIP DEX handshake proceeds as described in 1348 Section 6.6 of [RFC7401]. The I1 packet contents are specified in 1349 Section 5.3.1. 1351 6.5. Processing Incoming I1 Packets 1353 I1 packets in HIP DEX are handled almost identical to HIPv2 (see 1354 Section 6.7 of [RFC7401]). The main differences are that the 1355 Responder SHOULD select a HIP DEX HIT Suite in the R1 response. 1356 Moreover, as R1 packets are neither covered by a signature nor incur 1357 the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- 1358 computation of an R1 is only marginally beneficial, but would incur 1359 additional memory resources at the Responder. Hence, the R1 pre- 1360 computation SHOULD be omitted in HIP DEX. 1362 Correspondingly, the modified conceptual processing rules for 1363 responding to an I1 packet are as follows: 1365 1. The Responder MUST check that the Responder's HIT in the received 1366 I1 packet is either one of its own HITs or NULL. Otherwise, it 1367 must drop the packet. 1369 2. If the Responder is in ESTABLISHED state, the Responder MAY 1370 respond to this with an R1 packet, prepare to drop an existing 1371 HIP security association with the peer, and stay at ESTABLISHED 1372 state. 1374 3. If the Responder is in I1-SENT state, it MUST make a comparison 1375 between the sender's HIT and its own (i.e., the receiver's) HIT. 1376 If the sender's HIT is greater than its own HIT, it should drop 1377 the I1 packet and stay at I1-SENT. If the sender's HIT is 1378 smaller than its own HIT, it SHOULD send the R1 packet and stay 1379 at I1-SENT. The HIT comparison is performed as defined in 1380 Section 6.3. 1382 4. If the implementation chooses to respond to the I1 packet with an 1383 R1 packet, it creates a new R1 according to the format described 1384 in Section 5.3.2. It chooses the HI based on the destination HIT 1385 and the DH_GROUP_LIST in the I1 packet. If the implementation 1386 does not support the DH group required by the Initiator or if the 1387 destination HIT in the I1 packet does not match the required DH 1388 group, it selects the mutually preferred and supported DH group 1389 based on the DH_GROUP_LIST parameter in the I1 packet. The 1390 implementation includes the corresponding ECDH public key in the 1391 HOST_ID parameter. If no suitable DH Group ID was contained in 1392 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with 1393 any suitable ECDH public key. 1395 5. If the received Responder's HIT in the I1 packet is not NULL, the 1396 Responder's in the R1 packet HIT MUST match the destination HIT 1397 in the I1 packet. Otherwise, the Responder MUST select a HIT 1398 with the same HIT Suite as the Initiator's HIT. If this HIT 1399 Suite is not supported by the Responder, it SHOULD select a 1400 REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is 1401 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 1402 a local policy matter. 1404 6. The Responder expresses its supported HIP transport formats in 1405 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of 1406 [RFC7401]. The Responder MUST provide at least one payload 1407 transport format type. 1409 7. The Responder sends the R1 packet to the source IP address of the 1410 I1 packet. 1412 Note that only steps 4 and 5 have been changed with regard to the 1413 processing rules of HIPv2. The considerations about R1 management 1414 (except pre-computation) and malformed I1 packets in Sections 6.7.1 1415 and 6.7.2 of [RFC7401] likewise apply to HIP DEX. 1417 6.6. Processing Incoming R1 Packets 1419 R1 packets in HIP DEX are handled identically to HIPv2 (see 1420 Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses 1421 ECDH public keys as HIs and does not employ signatures. 1423 The modified conceptual processing rules for responding to an R1 1424 packet are as follows: 1426 1. A system receiving an R1 MUST first check to see if it has sent 1427 an I1 packet to the originator of the R1 packet (i.e., it has a 1428 HIP association that is in state I1-SENT and that is associated 1429 with the HITs in the R1). Unless the I1 packet was sent in 1430 opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP 1431 addresses in the received R1 packet SHOULD be ignored by the R1 1432 processing and, when looking up the right HIP association, the 1433 received R1 packet SHOULD be matched against the associations 1434 using only the HITs. If a match exists, the system should 1435 process the R1 packet as described below. 1437 2. Otherwise, if the system is in any state other than I1-SENT or 1438 I2-SENT with respect to the HITs included in the R1 packet, it 1439 SHOULD silently drop the R1 packet and remain in the current 1440 state. 1442 3. If the HIP association state is I1-SENT or I2-SENT, the received 1443 Initiator's HIT MUST correspond to the HIT used in the original 1444 I1 packet. Also, the Responder's HIT MUST correspond to the one 1445 used in the I1 packet, unless this packet contained a NULL HIT. 1447 4. If the HIP association state is I1-SENT, and multiple valid R1 1448 packets are present, the system MUST select from among the R1 1449 packets with the largest R1 generation counter. 1451 5. The system MUST check that the Initiator's HIT Suite is 1452 contained in the HIT_SUITE_LIST parameter in the R1 packet 1453 (i.e., the Initiator's HIT Suite is supported by the Responder). 1454 If the HIT Suite is supported by the Responder, the system 1455 proceeds normally. Otherwise, the system MAY stay in state 1456 I1-SENT and restart the HIP DEX handshake by sending a new I1 1457 packet with an Initiator HIT that is supported by the Responder 1458 and hence is contained in the HIT_SUITE_LIST in the R1 packet. 1459 The system MAY abort the handshake if no suitable source HIT is 1460 available. The system SHOULD wait for an acceptable time span 1461 to allow further R1 packets with higher R1 generation counters 1462 or different HIT and HIT Suites to arrive before restarting or 1463 aborting the HIP DEX handshake. 1465 6. The system MUST check that the DH Group ID in the HOST_ID 1466 parameter in the R1 matches the first DH Group ID in the 1467 Responder's DH_GROUP_LIST in the R1 packet, and also that this 1468 Group ID corresponds to a value that was included in the 1469 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 1470 of the HOST_ID parameter does not express the Responder's best 1471 choice, the Initiator can conclude that the DH_GROUP_LIST in the 1472 I1 or R1 packet was adversely modified. In such a case, the 1473 Initiator MAY send a new I1 packet; however, it SHOULD NOT 1474 change its preference in the DH_GROUP_LIST in the new I1 packet. 1475 Alternatively, the Initiator MAY abort the HIP DEX handshake. 1476 Moreover, if the DH Group ID indicated in the HOST_ID parameter 1477 does not match the DH Group ID of the HI employed by the 1478 Initiator, the system SHOULD wait for an acceptable time span to 1479 allow further R1 packets with different DH Group IDs to arrive 1480 before restarting or aborting the HIP DEX handshake. When 1481 restarting the handshake, the Initiator MUST consult local 1482 policies (see Section 7) regarding the use of another, mutually 1483 supported DH group for the subsequent handshake with the 1484 Responder. 1486 7. If the HIP association state is I2-SENT, the system MAY re-enter 1487 state I1-SENT and process the received R1 packet if it has a 1488 larger R1 generation counter than the R1 packet responded to 1489 previously. 1491 8. The R1 packet may have the A-bit set - in this case, the system 1492 MAY choose to refuse it by dropping the R1 packet and returning 1493 to state UNASSOCIATED. The system SHOULD consider dropping the 1494 R1 packet only if it used a NULL HIT in the I1 packet. If the 1495 A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be 1496 stored permanently. 1498 9. The system SHOULD attempt to validate the HIT against the 1499 received Host Identity by using the received Host Identity to 1500 construct a HIT and verify that it matches the Sender's HIT. 1502 10. The system MUST store the received R1 generation counter for 1503 future reference. 1505 11. The system attempts to solve the puzzle in the R1 packet. The 1506 system MUST terminate the search after exceeding the remaining 1507 lifetime of the puzzle. If the puzzle is not successfully 1508 solved, the implementation MAY either resend the I1 packet 1509 within the retry bounds or abandon the HIP base exchange. 1511 12. The system computes standard Diffie-Hellman keying material 1512 according to the public value and Group ID provided in the 1513 HOST_ID parameter. The Diffie-Hellman keying material Kij is 1514 used for key extraction as specified in Section 6.3. 1516 13. The system selects the HIP_CIPHER ID from the choices presented 1517 in the R1 packet and uses the selected values subsequently when 1518 generating and using encryption keys, and when sending the I2 1519 packet. If the proposed alternatives are not acceptable to the 1520 system, it may either resend an I1 packet within the retry 1521 bounds or abandon the HIP base exchange. 1523 14. The system chooses one suitable transport format from the 1524 TRANSPORT_FORMAT_LIST and includes the respective transport 1525 format parameter in the subsequent I2 packet. 1527 15. The system initializes the remaining variables in the associated 1528 state, including Update ID counters. 1530 16. The system prepares and sends an I2 packet as described in 1531 Section 5.3.3. 1533 17. The system SHOULD start a timer whose timeout value SHOULD be 1534 larger than the worst-case anticipated RTT, and MUST increment a 1535 trial counter associated with the I2 packet. The sender SHOULD 1536 retransmit the I2 packet upon a timeout and restart the timer, 1537 up to a maximum of I2_RETRIES_MAX tries. 1539 18. If the system is in state I1-SENT, it SHALL transition to state 1540 I2-SENT. If the system is in any other state, it remains in the 1541 current state. 1543 Note that step 4 from the original processing rules of HIPv2 1544 (signature verification) has been removed in the above processing 1545 rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules 1546 has been adapted to account for the fact that HIP DEX uses ECDH 1547 public keys as HIs. The considerations about malformed R1 packets in 1548 Sections 6.8.1 of [RFC7401] also apply to HIP DEX. 1550 6.7. Processing Incoming I2 Packets 1552 The processing of I2 packets follows similar rules as HIPv2 (see 1553 Section 6.9 of [RFC7401]). The main differences to HIPv2 are that 1554 HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY 1555 parameter as well as an I2 reception acknowledgement for 1556 retransmission purposes. Moreover, with HIP DEX the Initiator is 1557 responsible for triggering retransmissions, whereas the Responder 1558 merely replies to received I2 packets. 1560 The modified HIP DEX conceptual processing rules for responding to an 1561 I2 packet are: 1563 1. The system MAY perform checks to verify that the I2 packet 1564 corresponds to a recently sent R1 packet. Such checks are 1565 implementation dependent. See Appendix A in [RFC7401] for a 1566 description of an example implementation. 1568 2. The system MUST check that the Responder's HIT corresponds to 1569 one of its own HITs and MUST drop the packet otherwise. 1571 3. The system MUST further check that the Initiator's HIT Suite is 1572 supported. The Responder SHOULD silently drop I2 packets with 1573 unsupported Initiator HITs. 1575 4. If the system's state machine is in the R2-SENT state, the 1576 system MUST check to see if the newly received I2 packet is 1577 similar to the one that triggered moving to R2-SENT. If so, it 1578 MUST retransmit a previously sent R2 packet and reset the 1579 R2-SENT timer. The system SHOULD re-use the previously 1580 established state to re-create the corresponding R2 packet in 1581 order to prevent unnecessary computation overhead. 1583 5. If the system's state machine is in the I2-SENT state, the 1584 system MUST make a comparison between its local and sender's 1585 HITs (similarly as in Section 6.3). If the local HIT is smaller 1586 than the sender's HIT, it should drop the I2 packet, use the 1587 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1588 #I from the R1 packet received earlier, and get the local 1589 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1590 from the I2 packet sent to the peer earlier. Otherwise, the 1591 system should process the received I2 packet and drop any 1592 previously derived Diffie-Hellman keying material Kij and 1593 ENCRYPTED_KEY keying material it might have generated upon 1594 sending the I2 packet previously. The peer Diffie-Hellman key, 1595 ENCRYPTED_KEY, and the nonce #J are taken from the just arrived 1596 I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying 1597 material, and the nonce #I are the ones that were sent earlier 1598 in the R1 packet. 1600 6. If the system's state machine is in the I1-SENT state, and the 1601 HITs in the I2 packet match those used in the previously sent I1 1602 packet, the system uses this received I2 packet as the basis for 1603 the HIP association it was trying to form, and stops 1604 retransmitting I1 packets (provided that the I2 packet passes 1605 the additional checks below). 1607 7. If the system's state machine is in any state other than 1608 R2-SENT, the system SHOULD check that the echoed R1 generation 1609 counter in the I2 packet is within the acceptable range if the 1610 counter is included. Implementations MUST accept puzzles from 1611 the current generation and MAY accept puzzles from earlier 1612 generations. If the generation counter in the newly received I2 1613 packet is outside the accepted range, the I2 packet is stale 1614 (and perhaps replayed) and SHOULD be dropped. 1616 8. The system MUST validate the solution to the puzzle as described 1617 in Section 6.1. 1619 9. The I2 packet MUST have a single value in the HIP_CIPHER 1620 parameter, which MUST match one of the values offered to the 1621 Initiator in the R1 packet. 1623 10. The system MUST derive Diffie-Hellman keying material Kij based 1624 on the public value and Group ID in the HOST_ID parameter. This 1625 keying material is used to derive the keys of the Master Key SA 1626 as described in Section 6.3. If the Diffie-Hellman Group ID is 1627 unsupported, the I2 packet is silently dropped. If the 1628 processing time for the derivation of the Diffie-Hellman keying 1629 material Kij is likely to cause premature I2 retransmissions by 1630 the Initiator, the system MAY send a NOTIFY packet before 1631 starting the key derivation process. The NOTIFY packet contains 1632 a NOTIFICATION parameter with Notify Message Type 1633 I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the 1634 anticipated remaining processing time for the I2 packet in 1635 milliseconds as two-octet Notification Data. 1637 11. The implementation SHOULD also verify that the Initiator's HIT 1638 in the I2 packet corresponds to the Host Identity sent in the I2 1639 packet. (Note: some middleboxes may not be able to make this 1640 verification.) 1642 12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1643 Other documents specifying transport formats (e.g., [RFC7402]) 1644 contain specifications for handling any specific transport 1645 selected. 1647 13. The system MUST verify the HIP_MAC according to the procedures 1648 in Section 6.2. 1650 14. If the checks above are valid, then the system proceeds with 1651 further I2 processing; otherwise, it discards the I2 and its 1652 state machine remains in the same state. 1654 15. The I2 packet may have the A-bit set - in this case, the system 1655 MAY choose to refuse it by dropping the I2 and the state machine 1656 returns to state UNASSOCIATED. If the A-bit is set, the 1657 Initiator's HIT is anonymous and should not be stored 1658 permanently. 1660 16. The system MUST decrypt the keying material from the 1661 ENCRYPTED_KEY parameter. This keying material is a partial 1662 input to the key derivation process for the Pair-wise Key SA 1663 (see Section 6.3). 1665 17. The system initializes the remaining variables in the associated 1666 state, including Update ID counters. 1668 18. Upon successful processing of an I2 packet when the system's 1669 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 1670 R2-SENT, an R2 packet is sent as described in Section 5.3.4 and 1671 the system's state machine transitions to state R2-SENT. 1673 19. Upon successful processing of an I2 packet when the system's 1674 state machine is in state ESTABLISHED, the old HIP association 1675 is dropped and a new one is installed, an R2 packet is sent as 1676 described in Section 5.3.4, and the system's state machine 1677 transitions to R2-SENT. 1679 20. Upon the system's state machine transitioning to R2-SENT, the 1680 system starts a timer. The state machine transitions to 1681 ESTABLISHED if some data has been received on the incoming HIP 1682 association, or an UPDATE packet has been received (or some 1683 other packet that indicates that the peer system's state machine 1684 has moved to ESTABLISHED). If the timer expires (allowing for a 1685 maximal amount of retransmissions of I2 packets), the state 1686 machine transitions to ESTABLISHED. 1688 Note that steps 11 (encrypted HOST_ID) and 15 (signature 1689 verification) from the original processing rules of HIPv2 have been 1690 removed in the above processing rules for HIP DEX. Moreover, step 10 1691 of the HIPv2 processing rules has been adapted to account for 1692 optional extension of the retransmission mechanism. Step 16 has been 1693 added to the processing rules. The considerations about malformed I2 1694 packets in Sections 6.9.1 of [RFC7401] also apply to HIP DEX. 1696 6.8. Processing Incoming R2 Packets 1698 R2 packets in HIP DEX are handled identically to HIPv2 (see 1699 Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX 1700 introduces a new session key exchange via the ENCRYPTED_KEY parameter 1701 and does not employ signatures. 1703 The modified conceptual processing rules for responding to an R2 1704 packet are as follows: 1706 1. If the system is in any other state than I2-SENT, the R2 packet 1707 is silently dropped. 1709 2. The system MUST verify that the HITs in use correspond to the 1710 HITs that were received in the R1 packet that caused the 1711 transition to the I2-SENT state. 1713 3. The system MUST verify the HIP_MAC according to the procedures in 1714 Section 6.2. 1716 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1717 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1718 packet and compare the results against the chosen suites. 1720 5. If any of the checks above fail, there is a high probability of 1721 an ongoing man-in-the-middle or other security attack. The 1722 system SHOULD act accordingly, based on its local policy. 1724 6. The system MUST decrypt the keying material from the 1725 ENCRYPTED_KEY parameter. This keying material is a partial input 1726 to the key derivation process for the Pair-wise Key SA (see 1727 Section 6.3). 1729 7. Upon successful processing of the R2 packet, the state machine 1730 transitions to state ESTABLISHED. 1732 Note that step 4 (signature verification) from the original 1733 processing rules of HIPv2 has been replaced with a negotiation re- 1734 evaluation in the above processing rules for HIP DEX. Moreover, step 1735 6 has been added to the processing rules. 1737 6.9. Processing Incoming NOTIFY Packets 1739 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 1740 in a received NOTIFICATION parameter SHOULD be logged. Received 1741 errors MUST be considered only as informational, and the receiver 1742 SHOULD NOT change its HIP state purely based on the received NOTIFY 1743 packet. 1745 If a NOTIFY packet is received in state I2-SENT, this packet may be 1746 an I2 reception acknowledgement of the optional retransmission 1747 mechanism extension and SHOULD be processed. The following steps 1748 define the conceptual processing rules for such incoming NOTIFY 1749 packets in state I2-SENT: 1751 1. The system MUST verify that the HITs in use correspond to the 1752 HITs that were received in the R1 packet that caused the 1753 transition to the I2-SENT state. If this check fails, the NOTIFY 1754 packet SHOULD be dropped silently. 1756 2. If the NOTIFY packet contains a NOTIFICATION parameter with 1757 Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the 1758 I2 retransmission timer to the I2 processing time indicated in 1759 the NOTIFICATION parameter plus half the RTT-based timeout value. 1760 The system MUST NOT set the retransmission timeout to a higher 1761 value than allowed by a local policy. Moreover, the system 1762 SHOULD reset the I2 retransmission timer to the RTT-based timeout 1763 value after the next I2 retransmission. 1765 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 1767 UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 1768 as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). 1769 The only difference is the that the HIP_SIGNATURE is never present 1770 and, therefore, is not required to be processed by the receiving 1771 party. 1773 6.11. Handling State Loss 1775 Implementors MAY choose to use non-volatile, secure storage for HIP 1776 states in order for them to survive a system reboot. If no secure 1777 storage capabilities are available, the system SHOULD delete the 1778 corresponding HIP state, including the keying material. If the 1779 implementation does drop the state (as RECOMMENDED), it MUST also 1780 drop the peer's R1 generation counter value, unless a local policy 1781 explicitly defines that the value of that particular host is stored. 1782 An implementation MUST NOT store a peer's R1 generation counters by 1783 default, but storing R1 generation counter values, if done, MUST be 1784 configured by explicit HITs. 1786 7. HIP Policies 1788 There are a number of variables that will influence the HIP exchanges 1789 that each host must support. All HIP DEX implementations SHOULD 1790 provide for an ACL of Initiator's HI to Responder's HI. This ACL 1791 SHOULD also include preferred transform and local lifetimes. 1792 Wildcards SHOULD also be supported for this ACL. 1794 The value of #K used in the HIP R1 must be chosen with care. Values 1795 of #K that are too high will exclude clients with weak CPUs because 1796 these devices cannot solve the puzzle within a reasonable amount of 1797 time. #K should only be raised if a Responder is under high load, 1798 i.e., it cannot process all incoming HIP handshakes any more. If a 1799 Responder is not under high load, #K SHOULD be 0. 1801 8. Security Considerations 1803 HIP DEX closely resembles HIPv2. As such, the security 1804 considerations discussed in Section 8 of [RFC7401] similarly apply to 1805 HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated 1806 Diffie-Hellman key exchange of HIPv2 with an exchange of random 1807 keying material that is encrypted by a Diffie-Hellman derived key. 1808 Both the Initiator and Responder contribute to this keying material. 1809 As a result, the following additional security considerations apply 1810 to HIP DEX: 1812 o The strength of the keys for the Pair-wise Key SA is based on the 1813 quality of the random keying material generated by the Initiator 1814 and the Responder. Since the Initiator is expected to be a sensor 1815 or an actuator device, there is a natural concern about the 1816 quality of its random number generator. 1818 o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. 1819 Consequently, if an HI is compromised, all HIP connections 1820 protected with that HI are compromised. 1822 o The puzzle mechanism using CMAC may need further study regarding 1823 the level of difficulty. 1825 o The HIP DEX HIT generation may present new attack opportunities. 1827 o The R1 packet is unauthenticated and offers an adversary a new 1828 attack vector against the Initiator. This is mitigated by only 1829 processing a received R1 packet when the Initiator has previously 1830 sent a corresponding I1 packet. Moreover, the Responder repeats 1831 the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and 1832 TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to 1833 enable the Initiator to verify that these parameters have not been 1834 modified by an attacker in the unprotected R1 packet. 1836 The optional retransmission extension of HIP DEX is based on a NOTIFY 1837 packet that the Responder can use to inform the Initiator about the 1838 reception of an I2 packet. The Responder, however, cannot protect 1839 the authenticity of this packet as it did not yet set up the Master 1840 Key SA. Hence, an eavesdropping adversary may send spoofed reception 1841 acknowledgements for an overheard I2 packet and signal an arbitrary 1842 I2 processing time to the Initiator. The adversary can, e.g., 1843 indicate a lower I2 processing time than actually required by the 1844 Responder in order to cause premature retransmissions. To protect 1845 against this attack, the Initiator SHOULD set the NOTIFY-based 1846 timeout value to the maximum indicated packet processing time in case 1847 of conflicting NOTIFY packets. This allows the legitimate Responder 1848 to extend the retransmission timeout to the intended length. The 1849 adversary, however, can still arbitrarily delay the protocol 1850 handshake beyond the Responder's actual I2 processing time. To limit 1851 the extend of such a maliciously induced handshake delay, this 1852 specification additionally requires the Initiator not to set the 1853 NOTIFY-based timeout value higher than allowed by a local policy. 1855 9. IANA Considerations 1857 The following changes to the "Host Identity Protocol (HIP) 1858 Parameters" registries have been made: 1860 HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" 1861 (see Section 5.2.4). 1863 Parameter Type This document defines the new HIP parameter 1864 "ENCRYPTED_KEY" with type number 643 (see Section 5.2.5). 1866 HIP Cipher ID This document defines the new HIP Cipher ID "AES- 1867 128-CTR" (see Section 5.2.2). 1869 HI Algorithm This document defines the new HI Algorithm "ECDH" (see 1870 Section 5.2.3). 1872 ECC Curve Label This document specifies a new algorithm-specific 1873 subregistry named "ECDH Curve Label". The values for this 1874 subregistry are defined in Section 5.2.1. 1876 10. Acknowledgments 1878 The drive to put HIP on a cryptographic 'Diet' came out of a number 1879 of discussions with sensor vendors at IEEE 802.15 meetings. David 1880 McGrew was very helpful in crafting this document. 1882 11. Changelog 1884 This section summarizes the changes made from draft-moskowitz-hip-rg- 1885 dex-05, which was the first stable version of the draft. Note that 1886 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 1888 The draft was then renamed from draft-moskowitz-hip-dex to draft- 1889 ietf-hip-dex. 1891 11.1. Changes in draft-ietf-hip-dex-01 1893 o Added the new ECDH groups of Curve2519 and Curve448 from RFC 7748. 1895 11.2. Changes in draft-ietf-hip-dex-00 1897 o The Internet Draft was adopted by the HIP WG. 1899 11.3. Changes in draft-moskowitz-hip-rg-dex-06 1901 o A major change in the ENCRYPT parameter to use AES-CTR rather than 1902 AES-CBC. 1904 11.4. Changes in draft-moskowitz-hip-dex-00 1906 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 1907 submission. 1909 o Added the change section. 1911 o Added a Definitions section. 1913 o Changed I2 and R2 packets to reflect use of AES-CTR for 1914 ENCRYPTED_KEY parameter. 1916 o Cleaned up KEYMAT Generation text. 1918 o Added Appendix with C code for the ECDH shared secret generation 1919 on an 8 bit processor. 1921 11.5. Changes in draft-moskowitz-hip-dex-01 1923 o Numerous editorial changes. 1925 o New retransmission strategy. 1927 o New HIT generation mechanism. 1929 o Modified layout of ENCRYPTED_KEY parameter. 1931 o Clarify to use puzzle difficulty of zero under normal network 1932 conditions. 1934 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 1935 MUST). 1937 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 1938 and I2). 1940 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 1941 echoed in R2 packet. 1943 o Added new author. 1945 11.6. Changes in draft-moskowitz-hip-dex-02 1947 o Introduced formal definition of FOLD function. 1949 o Clarified use of CMAC for puzzle computation in section "Solving 1950 the Puzzle". 1952 o Several editorial changes. 1954 11.7. Changes in draft-moskowitz-hip-dex-03 1956 o Addressed HI crypto agility. 1958 o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 1960 o Extended the IV in the ENCRYPTED_KEY parameter. 1962 o Introduced forward-references to HIP DEX KEYMAT process and 1963 improved KEYMAT section. 1965 o Replaced Appendix A on "C code for ECC point multiplication" with 1966 short discussion in introduction. 1968 o Updated references. 1970 o Further editorial changes. 1972 11.8. Changes in draft-moskowitz-hip-dex-04 1974 o Improved retransmission extension. 1976 o Updated and strongly revised packet processing rules. 1978 o Updated security considerations. 1980 o Updated IANA considerations. 1982 o Move the HI Algorithm for ECDH to a value of 11. 1984 o Many editorial changes. 1986 12. References 1988 12.1. Normative References 1990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1991 Requirement Levels", BCP 14, RFC 2119, 1992 DOI 10.17487/RFC2119, March 1997, 1993 . 1995 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1996 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 1997 November 1998, . 1999 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2000 Counter Mode With IPsec Encapsulating Security Payload 2001 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2002 . 2004 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2005 Control Message Protocol (ICMPv6) for the Internet 2006 Protocol Version 6 (IPv6) Specification", RFC 4443, 2007 DOI 10.17487/RFC4443, March 2006, 2008 . 2010 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 2011 Routable Cryptographic Hash Identifiers Version 2 2012 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2013 2014, . 2015 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2016 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2017 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2018 . 2020 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2021 Encapsulating Security Payload (ESP) Transport Format with 2022 the Host Identity Protocol (HIP)", RFC 7402, 2023 DOI 10.17487/RFC7402, April 2015, 2024 . 2026 12.2. Informative References 2028 [DH76] Diffie, W. and M. Hellman, "New Directions in 2029 Cryptography", IEEE Transactions on Information 2030 Theory vol. IT-22, number 6, pages 644-654, Nov 1976. 2032 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 2033 Wehrle, "Tailoring End-to-End IP Security Protocols to the 2034 Internet of Things", in Proceedings of IEEE International 2035 Conference on Network Protocols (ICNP 2013), October 2013. 2037 [I-D.ietf-hip-rfc4423-bis] 2038 Moskowitz, R. and M. Komu, "Host Identity Protocol 2039 Architecture", draft-ietf-hip-rfc4423-bis-13 (work in 2040 progress), December 2015. 2042 [IEEE.802-11.2007] 2043 "Information technology - Telecommunications and 2044 information exchange between systems - Local and 2045 metropolitan area networks - Specific requirements - Part 2046 11: Wireless LAN Medium Access Control (MAC) and Physical 2047 Layer (PHY) Specifications", IEEE Standard 802.11, June 2048 2007, . 2051 [IEEE.802-15-4.2011] 2052 "Information technology - Telecommunications and 2053 information exchange between systems - Local and 2054 metropolitan area networks - Specific requirements - Part 2055 15.4: Wireless Medium Access Control (MAC) and Physical 2056 Layer (PHY) Specifications for Low-Rate Wireless Personal 2057 Area Networks (WPANs)", IEEE Standard 802.15.4, September 2058 2011, . 2061 [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for 2062 Elliptic Curve Cryptography in Wireless Sensor Networks", 2063 in Proceedings of International Conference on Information 2064 Processing in Sensor Networks (IPSN 2008), April 2008. 2066 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2067 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2068 DOI 10.17487/RFC5903, June 2010, 2069 . 2071 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2072 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2073 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2074 . 2076 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2077 Curve Cryptography Algorithms", RFC 6090, 2078 DOI 10.17487/RFC6090, February 2011, 2079 . 2081 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2082 Constrained-Node Networks", RFC 7228, 2083 DOI 10.17487/RFC7228, May 2014, 2084 . 2086 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2087 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2088 2016, . 2090 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2091 2 , 2000, . 2093 Appendix A. Password-based two-factor authentication during the HIP DEX 2094 handshake 2096 HIP DEX allows to identify authorized connections based on a two- 2097 factor authentication mechanism. With two-factor authentication, 2098 devices that are authorized to communicate with each other are 2099 required to be pre-provisioned with a shared (group) key. The 2100 Initiator uses this pre-provisioned key to encrypt the 2101 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 2102 the Responder verifies that its challenge in the 2103 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 2104 with the correct key. If verified successfully, the Responder 2105 proceeds with the handshake. Otherwise, it silently drops the I2 2106 packet. 2108 Note that there is no explicit signaling in the HIP DEX handshake for 2109 this behavior. Thus, knowledge of two-factor authentication must be 2110 configured externally prior to the handshake. 2112 Authors' Addresses 2114 Robert Moskowitz (editor) 2115 HTT Consulting 2116 Oak Park, MI 2117 USA 2119 EMail: rgm@htt-consult.com 2121 Rene Hummen 2122 Chair of Communication and Distributed Systems, RWTH Aachen 2123 Ahornstrasse 55 2124 Aachen 52074 2125 Germany 2127 EMail: hummen@comsys.rwth-aachen.de 2128 URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/