idnits 2.17.1 draft-ietf-hip-dex-11.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 -- The document date (October 30, 2019) is 1637 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) ** Downref: Normative reference to an Experimental RFC: RFC 6261 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: May 2, 2020 Hirschmann Automation and Control 6 M. Komu 7 Ericsson 8 October 30, 2019 10 HIP Diet EXchange (DEX) 11 draft-ietf-hip-dex-11 13 Abstract 15 This document specifies the Host Identity Protocol Diet EXchange (HIP 16 DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The 17 HIP DEX protocol design aims at reducing the overhead of the employed 18 cryptographic primitives by omitting public-key signatures and hash 19 functions. 21 The HIP DEX protocol is primarily designed for computation or memory- 22 constrained sensor/actuator devices. Like HIPv2, it is expected to 23 be used together with a suitable security protocol such as the 24 Encapsulated Security Payload (ESP) for the protection of upper layer 25 protocol data. In addition, HIP DEX can also be used as a keying 26 mechanism for security primitives at the MAC layer, e.g., for IEEE 27 802.15.4 networks. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 2, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 65 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6 66 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 6 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 68 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 8 71 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9 72 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9 73 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10 75 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11 76 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12 77 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16 78 4.1.4. User Data Considerations . . . . . . . . . . . . . . 17 79 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 80 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 17 81 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 17 82 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 18 83 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 18 84 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 19 85 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 19 86 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 20 87 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 20 88 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 21 89 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 22 90 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 24 91 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 25 92 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 26 93 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 26 94 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 27 95 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 27 96 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 27 97 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 28 98 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 31 99 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31 100 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32 101 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35 102 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38 103 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39 104 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40 105 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40 106 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40 107 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 41 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 110 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 111 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 44 112 12.1. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 44 113 12.2. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 44 114 12.3. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44 115 12.4. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44 116 12.5. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 45 117 12.6. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 45 118 12.7. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 45 119 12.8. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 45 120 12.9. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45 121 12.10. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 122 12.11. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46 123 12.12. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46 124 12.13. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 47 127 13.2. Informative References . . . . . . . . . . . . . . . . . 48 128 Appendix A. Password-based two-factor authentication during the 129 HIP DEX handshake . . . . . . . . . . . . . . . . . 50 130 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 50 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 133 1. Introduction 135 This document specifies the Host Identity Protocol Diet EXchange (HIP 136 DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity 137 Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol 138 semantics as well as the general packet structure of HIPv2. Hence, 139 it is recommended that [RFC7401] is well-understood before reading 140 this document. 142 The main differences between HIP BEX and HIP DEX are: 144 1. HIP DEX uses a different set of cryptographic primitives compared 145 to HIP BEX with the goal to reduce the protocol overhead: 147 * Peer authentication and key agreement in HIP DEX are based on 148 static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This 149 replaces the use of public-key signatures and ephemeral 150 Diffie-Hellman key pairs in HIPv2. 152 * HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC 153 as its MACing function. In contrast, HIPv2 currently supports 154 AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC- 155 SHA-384 for MACing. 157 * HIP DEX defines a simple fold function to efficiently generate 158 HITs, whereas the HIT generation of HIPv2 is based on SHA-1, 159 SHA-256, or SHA-384. 161 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of 162 HIPv2 due to the removal of the ephemeral Diffie-Hellman key 163 agreement. 165 3. HIP DEX forfeits the use of digital signatures with the removal 166 of a hash function. Peer authentication with HIP DEX, therefore, 167 is based on the use of the ECDH derived key in the HIP_MAC 168 parameter. 170 4. With HIP DEX, the ECDH derived key is only used to protect HIP 171 packets. Separate session key(s) are used to protect the 172 transmission of upper layer protocol data. These session key(s) 173 are established via a new secret exchange during the handshake. 175 5. HIP DEX introduced a new, optional retransmission strategy that 176 is specifically designed to handle potentially extensive 177 processing times of the employed cryptographic operations on 178 computationally constrained devices. 180 By eliminating the need for public-key signatures and the ephemeral 181 DH key agreement, HIP DEX reduces the computational, energy, 182 transmission, and memory requirements for public-key cryptography 183 (see [LN08]) in the HIPv2 protocol design. This makes HIP DEX 184 especially suitable for constrained devices as defined in [RFC7228]. 186 This document focuses on the protocol specifications related to 187 differences between HIP BEX and HIP DEX. Where differences are not 188 called out explicitly, the protocol specification of HIP DEX is the 189 same as defined in [RFC7401]. 191 1.1. The HIP Diet EXchange (DEX) 193 The HIP Diet EXchange is a two-party cryptographic protocol used to 194 establish a secure communication context between hosts. The first 195 party is called the Initiator and the second party the Responder. 196 The four-packet exchange helps to make HIP DEX Denial of Service 197 (DoS) resilient. The Initiator and the Responder exchange their 198 static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2 199 handshake packet. The parties then authenticate each other in the I2 200 and R2 handshake packet based on the ECDH-derived keying material. 201 The Initiator and the Responder additionally transmit keying material 202 for the session key in these last two handshake packets (I2 and R2). 203 This is to prevent overuse of the static ECDH-derived keying 204 material. Moreover, the Responder starts a puzzle exchange in the R1 205 packet and the Initiator completes this exchange in the I2 packet 206 before the Responder performs computationally expensive operations or 207 stores any state from the exchange. Given this handshake structure, 208 HIP DEX operationally is very similar to HIP BEX. Moreover, the 209 employed model is also fairly equivalent to 802.11-2007 210 [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but 211 handled in a single exchange. 213 HIP DEX does not have the option to encrypt the Host Identity of the 214 Initiator in the I2 packet. The Responder's Host Identity also is 215 not protected. Thus, contrary to HIPv2, HIP DEX does not provide for 216 end-point anonymity and any signaling (i.e., HOST_ID parameter 217 contained with an ENCRYPTED parameter) that indicates such anonymity 218 should be ignored. 220 As in [RFC7401], data packets start to flow after the R2 packet. The 221 I2 and R2 packets may carry a data payload in the future. However, 222 the details of this may be defined later. 224 An existing HIP association can be updated with the update mechanism 225 defined in [RFC7401]. Likewise, the association can be torn down 226 with the defined closing mechanism for HIPv2 if it is no longer 227 needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of 228 the original HIPv2 specification. 230 Finally, HIP DEX is designed as an end-to-end authentication and key 231 establishment protocol. As such, it can be used in combination with 232 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 233 end-to-end security protocols. In addition, HIP DEX can also be used 234 as a keying mechanism for security primitives at the MAC layer, e.g., 235 for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth 236 mentioning that the HIP DEX base protocol does not cover all the 237 fine-grained policy control found in Internet Key Exchange Version 2 238 (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway 239 policies. Thus, HIP DEX is not a replacement for IKEv2. 241 1.2. Memo Structure 243 The rest of this memo is structured as follows. Section 2 defines 244 the central keywords, notation, and terms used throughout this 245 document. Section 3 defines the structure of the Host Identity and 246 its various representations. Section 4 gives an overview of the HIP 247 Diet EXchange protocol. Sections 5 and 6 define the detailed packet 248 formats and rules for packet processing. Finally, Sections 7, 8, 9, 249 and 10 discuss policy, interoperability between HIPv2 vs DEX, 250 security, and IANA considerations, respectively. Appendix A defines 251 a two factor authentication scheme and Appendix B highligts some 252 discussions with the IESG. 254 2. Terms, Notation and Definitions 256 2.1. Requirements Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 260 "OPTIONAL" in this document are to be interpreted as described in BCP 261 14 [RFC2119] [RFC8174] when, and only when, they appear in all 262 capitals, as shown here. 264 2.2. Notation 266 [x] indicates that x is optional. 268 {x} indicates that x is encrypted. 270 X(y) indicates that y is a parameter of X. 272 i indicates that x exists i times. 274 --> signifies "Initiator to Responder" communication (requests). 276 <-- signifies "Responder to Initiator" communication (replies). 278 | signifies concatenation of information - e.g., X | Y is the 279 concatenation of X and Y. 281 FOLD (X, K) denotes the partitioning of X into n K-bit segments and 282 the iterative folding of these segments via XOR. I.e., X = x_1, 283 x_2, ..., x_n, where x_i is of length K and the last segment x_n 284 is padded to length K by appending 0 bits. FOLD then is computed 285 as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 287 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 288 the MAC function M on the input x. 290 sort (HIT-I | HIT-R) is defined as the network byte order 291 concatenation of the two HITs, with the smaller HIT preceding the 292 larger HIT, resulting from the numeric comparison of the two HITs 293 interpreted as positive (unsigned) 128-bit integers in network 294 byte order. 296 2.3. Definitions 298 HIP Diet Exchange (DEX): The ECDH-based HIP handshake for 299 establishing a new HIP association. 301 Host Identity (HI): The static ECDH public key that represents the 302 identity of the host. In HIP DEX, a host proves ownership of the 303 private key belonging to its HI by creating a HIP_MAC with the 304 derived ECDH key (see Section 3). 306 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 307 is generated by folding the HI (see Section 3). 309 HIT Suite: A HIT Suite groups all algorithms that are required to 310 generate and use an HI and its HIT. In particular, these 311 algorithms are: 1) ECDH and 2) FOLD. 313 HIP association: The shared state between two peers after completion 314 of the HIP DEX handshake. 316 Initiator: The host that initiates the HIP DEX handshake. This role 317 is typically forgotten once the handshake is completed. 319 Responder: The host that responds to the Initiator in the HIP DEX 320 handshake. This role is typically forgotten once the handshake is 321 completed. 323 Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is 324 redefined as CMAC. Still, note that CMAC is a message 325 authentication code (MAC) and not a cryptographic hash function. 326 Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where 327 RHASH is used. Moreover, RHASH has different security properties 328 in HIP DEX and is not used for HIT generation. 330 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 331 natural output length of RHASH in bits. 333 CMAC: The Cipher-based Message Authentication Code with the 128-bit 334 Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. 336 CKDF: CMAC-based Key Derivation Function. 338 Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE 339 parameter (see section 5.2.4 in [RFC7401]. It is also referred to 340 as "random value #I" in this document. 342 Puzzle difficulty K: The Initiator has to compute a solution for the 343 puzzle. The level of computational difficulty is denoted by the 344 #K field in the puzzle parameter (see section 5.2.4 in [RFC7401]. 346 3. Host Identity (HI) and its Structure 348 In this section, the properties of the Host Identity and Host 349 Identity Tag are discussed, and the exact format for them is defined. 350 In HIP, the public key of an asymmetric key pair is used as the Host 351 Identity (HI). Correspondingly, the host itself is defined as the 352 entity that holds the private key of the key pair. See the HIP 353 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 354 details on the difference between an identity and the corresponding 355 identifier. 357 HIP DEX implementations MUST support the Elliptic Curve Diffie- 358 Hellman (ECDH) [RFC6090] key exchange for generating the HI as 359 defined in Section 5.2.3. No additional algorithms are supported at 360 this time. 362 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 363 in the handshake packets to represent the HI. The DEX Host Identity 364 Tag (HIT) is different from the BEX HIT in two ways: 366 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). 368 o The DEX HIT is not generated via a cryptographic hash. Rather, it 369 is a compression of the HI. 371 Due to the latter property, an attacker may be able to find a 372 collision with a HIT that is in use. Hence, policy decisions such as 373 access control MUST NOT be based solely on the HIT. Instead, the HI 374 of a host SHOULD be considered. 376 Carrying HIs and HITs in the header of user data packets would 377 increase the overhead of packets. Thus, it is not expected that 378 these parameters are carried in every packet, but other methods are 379 used to map the data packets to the corresponding HIs. In some 380 cases, this allows to use HIP DEX without any additional headers in 381 the user data packets. For example, if ESP is used to protect data 382 traffic, the Security Parameter Index (SPI) carried in the ESP header 383 can be used to map the encrypted data packet to the correct HIP DEX 384 association. When other user data packet formats are used, the 385 corresponding extensions need to define a replacement for the 386 ESP_TRANSFORM [RFC7402] parameter along with associated semantics, 387 but this procedure is outside the scope of this document. 389 3.1. Host Identity Tag (HIT) 391 With HIP DEX, the HIT is a 128-bit value - a compression of the HI 392 prepended with a specific prefix. There are two advantages of using 393 a hashed encoding over the actual variable-sized public key in 394 protocols. First, the fixed length of the HIT keeps packet sizes 395 manageable and eases protocol coding. Second, it presents a 396 consistent format for the protocol, independent of the underlying 397 identity technology in use. 399 The structure of the HIT is based on RFC 7343 [RFC7343], called 400 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 401 consists of three parts: first, an IANA assigned prefix to 402 distinguish it from other IPv6 addresses. Second, a four-bit 403 encoding of the algorithms that were used for generating the HI and 404 the compressed representation of the HI. Third, a 96-bit hashed 405 representation of the HI. In contrast to HIPv2, HIP DEX employs HITs 406 that are NOT generated by means of a cryptographic hash. Instead, 407 the HI is compressed to 96 bits as defined in the following section. 409 3.2. Generating a HIT from an HI 411 The HIT does not follow the exact semantics of an ORCHID as there is 412 no hash function in HIP DEX. Still, its structure is strongly 413 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 414 is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used 415 for the four bits of the Orchid Generation Algorithm (OGA) field in 416 the ORCHID. The hash representation in an ORCHID is replaced with 417 FOLD(HI,96). 419 4. Protocol Overview 421 This section gives a simplified overview of the HIP DEX protocol 422 operation and does not contain all the details of the packet formats 423 or the packet processing steps. Section 5 and Section 6 describe 424 these aspects in more detail and are normative in case of any 425 conflicts with this section. Importantly, the information given in 426 this section focuses on the differences between the HIPv2 and HIP DEX 427 protocol specifications. 429 4.1. Creating a HIP Association 431 By definition, the system initiating a HIP Diet EXchange is the 432 Initiator, and the peer is the Responder. This distinction is 433 typically forgotten once the handshake completes, and either party 434 can become the Initiator in future communications. 436 The HIP Diet EXchange serves to manage the establishment of state 437 between an Initiator and a Responder. The first packet, I1, 438 initiates the exchange, and the last three packets, R1, I2, and R2, 439 constitute an authenticated Diffie-Hellman [DH76] key exchange for 440 the Master Key SA generation. This Master Key SA is used by the 441 Initiator and the Responder to wrap secret keying material in the I2 442 and R2 packets. Based on the exchanged keying material, the peers 443 then derive a Pair-wise Key SA if cryptographic keys are needed, 444 e.g., for ESP-based protection of user data. 446 The Initiator first sends a trigger packet, I1, to the Responder. 447 This packet contains the HIT of the Initiator and the HIT of the 448 Responder, if it is known. Moreover, the I1 packet initializes the 449 negotiation of the Diffie-Hellman group that is used for generating 450 the the Master Key SA. Therefore, the I1 packet contains a list of 451 Diffie-Hellman Group IDs supported by the Initiator. Note that in 452 some cases it may be possible to replace this trigger packet by some 453 other form of a trigger, in which case the protocol starts with the 454 Responder sending the R1 packet. In such cases, another mechanism to 455 convey the Initiator's supported DH Groups (e.g., by using a default 456 group) must be specified. 458 The second packet, R1, starts the actual authenticated Diffie-Hellman 459 key exchange. It contains a puzzle - a cryptographic challenge that 460 the Initiator must solve before continuing the exchange. The level 461 of difficulty of the puzzle can be adjusted based on level of trust 462 with the Initiator, current load, or other factors. In addition, the 463 R1 contains the Responder's Diffie-Hellman parameter and lists of 464 cryptographic algorithms supported by the Responder. Based on these 465 lists, the Initiator can continue, abort, or restart the handshake 466 with a different selection of cryptographic algorithms. 468 In the I2 packet, the Initiator MUST display the solution to the 469 received puzzle. Without a correct solution, the I2 packet is 470 discarded. The I2 also contains a key wrap parameter that carries 471 secret keying material of the Initiator. This keying material is 472 only half of the final session key. The packet is authenticated by 473 the sender (Initiator) via a MAC. 475 The R2 packet acknowledges the receipt of the I2 packet and completes 476 the handshake. The R2 contains a key wrap parameter that carries the 477 rest of the keying material of the Responder. The packet is 478 authenticated by the sender (Responder) via a MAC. 480 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 481 and "ENC(DH,y)" refer to the random values x and y that are wrapped 482 based on the Master Key SA (indicated by ENC and DH). Note that x 483 and y each constitute half of the final session key material. The 484 packets also contain other parameters that are not shown in this 485 figure. 487 Initiator Responder 489 I1: 490 ---------------------------------> 491 remain stateless 492 R1: puzzle, HI 493 <-------------------------------- 494 solve puzzle 495 perform ECDH 496 encrypt x 497 I2: solution, HI, ENC(DH,x), mac 498 ---------------------------------> 499 check puzzle 500 perform ECDH 501 check MAC 502 decrypt x 503 encrypt y 504 R2: ENC(DH,y), mac 505 <--------------------------------- 506 check MAC 507 decrypt y 509 Figure 1: High-level overview of the HIP Diet EXchange 511 4.1.1. HIP Puzzle Mechanism 513 The purpose of the HIP puzzle mechanism is to protect the Responder 514 from a number of denial-of-service threats. It allows the Responder 515 to delay state creation until receiving the I2 packet. Furthermore, 516 the puzzle allows the Responder to use a fairly cheap calculation to 517 check that the Initiator is "sincere" in the sense that it has 518 churned enough CPU cycles in solving the puzzle. 520 The puzzle mechanism enables a Responder to immediately reject an I2 521 packet if it does not contain a valid puzzle solution. To verify the 522 puzzle solution, the Responder only has to compute a single CMAC 523 operation. After a successful puzzle verification, the Responder can 524 securely create session-specific state and perform CPU-intensive 525 operations such as a Diffie-Hellman key generation. By varying the 526 difficulty of the puzzle, the Responder can frustrate CPU or memory 527 targeted DoS attacks. Under normal network conditions, the puzzle 528 difficulty SHOULD be zero, thus effectively reverting the puzzle 529 mechanism to a cookie-based DoS protection mechanism. Without 530 setting the puzzle difficulty to zero under normal network 531 conditions, potentially scarce computation resources at the Initiator 532 would be churned unnecessarily. 534 Conceptually, the puzzle mechanism in HIP DEX is the same as in 535 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 536 [RFC7401] for more detailed information about the employed mechanism. 537 Notably, the only differences between the puzzle mechanism in HIP DEX 538 and HIPv2 are that HIP DEX does not employ pre-computation of R1 539 packets and uses CMAC instead of a hash function for solving and 540 verifying a puzzle. The implications of these changes on the puzzle 541 implementation are discussed in Section 6.1. 543 4.1.2. HIP State Machine 545 The HIP DEX state machine has the same states as the HIPv2 state 546 machine (see 4.4. in [RFC7401]). However, HIP DEX features a 547 retransmission strategy with an optional reception acknowledgement 548 for the I2 packet. The goal of this additional acknowledgement is to 549 reduce premature I2 retransmissions in case of devices with low 550 computation resources [HWZ13]. As a result, there are minor changes 551 regarding the transitions in the HIP DEX state machine. The 552 following section documents these differences compared to HIPv2. 554 4.1.2.1. HIP DEX Retransmission Mechanism 556 For the retransmission of I1 and I2 packets, the Initiator adopts the 557 retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). 558 This strategy is based on a timeout that is set to a value larger 559 than the worst-case anticipated round-trip time (RTT). For each 560 received I1 or I2 packet, the Responder sends an R1 or R2 packet, 561 respectively. This design trait enables the Responder to remain 562 stateless until the reception and successful processing of the I2 563 packet. The Initiator stops retransmitting I1 or I2 packets after 564 the reception of the corresponding R1 or R2. If the Initiator did 565 not receive an R1 packet after I1_RETRIES_MAX tries, it stops I1 566 retransmissions. Likewise, it stops retransmitting the I2 packet 567 after I2_RETRIES_MAX unsuccessful tries. 569 For repeatedly received I2 packets, the Responder SHOULD NOT perform 570 operations related to the Diffie-Hellman key exchange or the keying 571 material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD 572 re-use the previously established state to re-create the 573 corresponding R2 packet in order to prevent unnecessary computation 574 overhead. 576 The potentially high processing time of an I2 packet at a (resource- 577 constrained) Responder may cause premature retransmissions if the 578 time required for I2 transmission and processing exceeds the RTT- 579 based retransmission timeout. Thus, the Initiator should also take 580 the processing time of the I2 packet at the Responder into account 581 for retransmission purposes. To this end, the Responder MAY notify 582 the Initiator about the anticipated delay once the puzzle solution 583 was successfully verified and if the remaining I2 packet processing 584 incurs a high processing delay. The Responder MAY therefore send a 585 NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator 586 before the Responder commences the ECDH operation. The NOTIFY packet 587 serves as an acknowledgement for the I2 packet and consists of a 588 NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 589 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 590 contains the anticipated remaining processing time for the I2 packet 591 in milliseconds as two-octet Notification Data. This processing time 592 can, e.g., be estimated by measuring the computation time of the ECDH 593 key derivation operation during the Responder start-up procedure. 594 After the I2 processing has finished, the Responder sends the regular 595 R2 packet. 597 When the Initiator receives the NOTIFY packet, it sets the I2 598 retransmission timeout to the I2 processing time indicated in the 599 NOTIFICATION parameter plus half the RTT-based timeout value. In 600 doing so, the Initiator MUST NOT set the retransmission timeout to a 601 higher value than allowed by a local policy. This is to prevent 602 unauthenticated NOTIFY packets from maliciously delaying the 603 handshake beyond a well-defined upper bound in case of a lost R2 604 packet. At the same time, this extended retransmission timeout 605 enables the Initiator to defer I2 retransmissions until the point in 606 time when the Responder should have completed its I2 packet 607 processing and the network should have delivered the R2 packet 608 according to the employed worst-case estimates. 610 4.1.2.2. HIP State Processes 612 HIP DEX clarifies or introduces the following new transitions. 614 System behavior in state I2-SENT, Table 1. 616 +---------------------+---------------------------------------------+ 617 | Trigger | Action | 618 +---------------------+---------------------------------------------+ 619 | Receive NOTIFY, | Set I2 retransmission timer to value in | 620 | process | I2_ACKNOWLEDGEMENT Notification Data plus | 621 | | 1/2 RTT-based timeout value and stay at | 622 | | I2-SENT | 623 | | | 624 | | | 625 | | | 626 | Timeout | Increment trial counter | 627 | | | 628 | | | 629 | | | 630 | | If counter is less than I2_RETRIES_MAX, | 631 | | send I2, reset timer to RTT-based timeout, | 632 | | and stay at I2-SENT | 633 | | | 634 | | | 635 | | | 636 | | If counter is greater than I2_RETRIES_MAX, | 637 | | go to E-FAILED | 638 +---------------------+---------------------------------------------+ 640 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 642 4.1.2.3. Simplified HIP State Diagram 644 The following diagram shows the major state transitions. Transitions 645 based on received packets implicitly assume that the packets are 646 successfully authenticated or processed. 648 +--+ +----------------------------+ 649 recv I1, send R1 | | | | 650 | v v | 651 +--------------+ recv I2, send R2 | 652 +----------------| UNASSOCIATED |----------------+ | 653 datagram | +--+ +--------------+ | | 654 to send, | | | Alg. not supported, | | 655 send I1 | | | send I1 | | 656 . v | v | | 657 . +---------+ recv I2, send R2 | | 658 +---->| I1-SENT |--------------------------------------+ | | 659 | +---------+ +----------------------+ | | | 660 | | recv R1, | recv I2, send R2 | | | | 661 | v send I2 | v v v | 662 | +---------+----------+ +---------+ | 663 | +--->| I2-SENT |<-------------+ +------------| R2-SENT |<---+ | 664 | | +---------+ recv NOTIFY, | | +---------+ | | 665 | | | | | reset timer | | data or| | | 666 | |recv R1, | | +--------------+ | EC timeout| | | 667 | |send I2 +-|--------------------+ | receive I2,| | 668 | | | | +-------------+ | send R2| | 669 | | | +-------->| ESTABLISHED |<---------+ | | 670 | | | recv R2 +-------------+ | | 671 | | | | | | receive I2, send R2 | | 672 | | +------------+ | +-------------------------------+ | 673 | | | +-----------+ | | 674 | | | no packet sent/received| +---+ | | 675 | | | for UAL min, send CLOSE| | |timeout | | 676 | | | v v |(UAL+MSL) | | 677 | | | +---------+ |retransmit | | 678 +--|----------|------------------------| CLOSING |-+CLOSE | | 679 | | +---------+ | | 680 | | | | | | | | 681 +----------|-------------------------+ | | +----------------+ | 682 | | +-----------+ +------------------|--+ 683 | | |recv CLOSE, recv CLOSE_ACK | | 684 | +-------------+ |send CLOSE_ACK or timeout | | 685 | recv CLOSE, | | (UAL+MSL) | | 686 | send CLOSE_ACK v v | | 687 | +--------+ receive I2, send R2 | | 688 +---------------------| CLOSED |------------------------------+ | 689 +--------+ | 690 ^ | | | 691 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 692 +-+ +------------------------------------+ 694 4.1.3. HIP DEX Security Associations 696 HIP DEX establishes two Security Associations (SA), one for the 697 Diffie-Hellman derived key, or Master Key, and one for the session 698 key, or Pair-wise Key. 700 4.1.3.1. Master Key SA 702 The Master Key SA is used to authenticate HIP packets and to encrypt 703 selected HIP parameters in the HIP DEX packet exchanges. Since only 704 a small amount of data is protected by this SA, it can be long-lived 705 with no need for rekeying. At the latest, the system MUST initiate 706 rekeying when its incoming ESP sequence counter is going to overflow, 707 and he system MUST NOT replace its keying material until the rekeying 708 packet exchange successfully completes as described in Section 6.8 in 709 [RFC7402]. 711 The Master Key SA contains the following elements: 713 o Source HIT 715 o Destination HIT 717 o HIP_Encrypt Key 719 o HIP_MAC Key 721 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 722 Hellman derived key as described in Section 6.3. Their length is 723 determined by the HIP_CIPHER. 725 4.1.3.2. Pair-wise Key SA 727 The Pair-wise Key SA is used to authenticate and to encrypt user 728 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 729 The Pair-wise Key SA elements are defined by the data transform 730 (e.g., ESP_TRANSFORM [RFC7402]). 732 The keys for the Pair-wise Key SA are derived based on the wrapped 733 keying material exchanged in the ENCRYPTED_KEY parameter (see 734 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 735 keying material of the two peers is concatenated. This concatenation 736 forms the input to a Key Derivation Function (KDF). If the data 737 transform does not specify its own KDF, the key derivation function 738 defined in Section 6.3 is used. Even though the concatenated input 739 is randomly distributed, a KDF Extract phase may be needed to get the 740 proper length for the input to the KDF Expand phase. 742 4.1.4. User Data Considerations 744 The User Data Considerations in Section 4.5. of [RFC7401] also apply 745 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 746 Loss of state due to system reboot may be a critical performance 747 issue for resource-constrained devices. Thus, implementors MAY 748 choose to use non-volatile, secure storage for HIP states in order 749 for them to survive a system reboot as discussed in Section 6.11. 750 Using non-volatile storage will limit state loss during reboots to 751 only those situations with an SA timeout. 753 5. Packet Formats 755 5.1. Payload Format 757 HIP DEX employs the same fixed HIP header and payload structure as 758 HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also 759 apply to HIP DEX. 761 5.2. HIP Parameters 763 The HIP parameters carry information that is necessary for 764 establishing and maintaining a HIP association. For example, the 765 peer's public keys as well as the signaling for negotiating ciphers 766 and payload handling are encapsulated in HIP parameters. Additional 767 information, meaningful for end-hosts or middleboxes, may also be 768 included in HIP parameters. The specification of the HIP parameters 769 and their mapping to HIP packets and packet types is flexible to 770 allow HIP extensions to define new parameters and new protocol 771 behavior. 773 In HIP packets, HIP parameters are ordered according to their numeric 774 type number and encoded in TLV format. 776 HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of 777 [RFC7401] where possible. Still, HIP DEX further restricts and/or 778 extends the following existing parameter types: 780 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 782 o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. 784 o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. 786 o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, 787 SOLUTION, and HIP_MAC parameters (see Section 6.1 and 788 Section 6.2). 790 In addition, HIP DEX introduces the following new parameter: 792 +------------------+--------------+----------+----------------------+ 793 | TLV | Type | Length | Data | 794 +------------------+--------------+----------+----------------------+ 795 | ENCRYPTED_KEY | TBD1 | variable | Encrypted container | 796 | | (suggested | | for the session key | 797 | | value 643) | | exchange | 798 +------------------+--------------+----------+----------------------+ 800 5.2.1. DH_GROUP_LIST 802 The DH_GROUP_LIST parameter contains the list of supported DH Group 803 IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With 804 HIP DEX, the DH Group IDs are restricted to: 806 Group KDF Value 808 NIST P-256 [RFC5903] CKDF 7 809 NIST P-384 [RFC5903] CKDF 8 810 NIST P-521 [RFC5903] CKDF 9 811 SECP160R1 [SECG] CKDF 10 812 Curve25519 [RFC7748] CKDF 12 813 Curve448 [RFC7748] CKDF 13 815 The ECDH groups with values 7 - 9 are defined in [RFC5903] and 816 [RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of 817 [RFC7401]. These curves, when used with HIP MUST have a co-factor of 818 1. 820 The ECDH groups with values 12 and 13 are defined in [RFC7748]. 821 These curves have cofactors of 8 and 4 (respectively). 823 5.2.2. HIP_CIPHER 825 The HIP_CIPHER parameter contains the list of supported cipher 826 algorithms to be used for encrypting the contents of the ENCRYPTED 827 and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 828 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited 829 to: 831 Suite ID Value 833 RESERVED 0 834 NULL-ENCRYPT 1 ([RFC2410]) 835 AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) 836 Mandatory implementation: AES-128-CTR. Implementors SHOULD support 837 NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT 838 offer or accept this value unless explicitly configured for testing/ 839 debugging of HIP. 841 5.2.3. HOST_ID 843 The HOST_ID parameter conveys the Host Identity (HI) along with 844 optional information about a host. The HOST_ID parameter is defined 845 in Section 5.2.9 of [RFC7401]. 847 HIP DEX uses the public portion of a host's static ECDH key-pair as 848 the HI. Correspondingly, HIP DEX limits the HI algorithms to the 849 following new profile: 851 Algorithm profiles Value 853 ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) 855 HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 856 Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is 857 encoded in the "ECC curve" field of the HOST_ID parameter. The 858 supported DH Group IDs are defined in Section 5.2.1. 860 5.2.4. HIT_SUITE_LIST 862 The HIT_SUITE_LIST parameter contains a list of the supported HIT 863 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 864 Initiator can determine which source HIT Suite IDs are supported by 865 the Responder. The HIT_SUITE_LIST parameter is defined in 866 Section 5.2.10 of [RFC7401]. 868 The following new HIT Suite ID is defined for HIP DEX, and the 869 relationship between the four-bit ID value used in the OGA ID field 870 and the eight-bit encoding within the HIT_SUITE_LIST ID field is 871 clarified: 873 HIT Suite Four-bit ID Eight-bit encoding 875 ECDH/FOLD TBD2 (suggestion: 4) TBD3 (suggestion: 0x40) 877 Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field 878 allows the peers to distinguish a HIP DEX handshake from a HIPv2 879 handshake. The Responder MUST respond with a HIP DEX HIT suite ID 880 when the HIT of the Initiator is a HIP DEX HIT. 882 5.2.5. ENCRYPTED_KEY 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Type | Length | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 / Encrypted value / 890 / / 891 / +-------------------------------+ 892 / | Padding | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 Type TBD1 (suggested value 643) 896 Length length in octets, excluding Type, Length, and 897 Padding 898 Encrypted The value is encrypted using an encryption algorithm 899 value as defined in the HIP_CIPHER parameter. 901 The ENCRYPTED_KEY parameter encapsulates a random value that is later 902 used in the session key creation process (see Section 6.3). This 903 random value MUST have a length of at least 64 bits. The puzzle 904 value #I and the puzzle solution #J (see Section 4.1.2 in [RFC7401]) 905 are used as the initialization vector (IV) for the encryption 906 process. To this end, the IV is computed as FOLD(I | J, 128). 907 Moreover, a 16 bit counter value, which is initialized to zero on 908 first use, is appended to the IV value in order to guarantee that a 909 non-repeating nonce is fed to the encryption algorithm defined by the 910 HIP_CIPHER. 912 Once this encryption process is completed, the "encrypted value" data 913 field is ready for inclusion in the Parameter. If necessary, 914 additional Padding for 8-byte alignment is then added according to 915 the rules of TLV Format in [RFC7401]. 917 5.3. HIP Packets 919 HIP DEX uses the same eight basic HIP packets as HIPv2 (see 920 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake 921 (I1, R1, I2, and R2), one is for updating an association (UPDATE), 922 one is for sending notifications (NOTIFY), and two are for closing 923 the association (CLOSE and CLOSE_ACK). There are some differences 924 regarding the HIP parameters that are included in the handshake 925 packets concerning HIP BEX and HIP DEX. This section covers these 926 differences for the DEX packets. Packets not discussed here, follow 927 the structure defined in [RFC7401]. 929 An important difference between packets in HIP BEX and HIP DEX is 930 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 931 included in HIP DEX. Thus, the R1 packet is completely unprotected 932 and can be spoofed. As a result, negotiation parameters contained in 933 the R1 packet have to be re-included in later, protected packets in 934 order to detect and prevent potential downgrading attacks. Moreover, 935 the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not 936 covered by a signature and purely rely on the HIP_MAC parameter for 937 packet authentication. The processing of these packets is changed 938 accordingly. 940 In the future, an optional upper-layer payload MAY follow the HIP 941 header. The Next Header field in the header indicates if there is 942 additional data following the HIP header. 944 5.3.1. I1 - the HIP Initiator Packet 946 The HIP header values for the I1 packet: 948 Header: 949 Packet Type = 1 950 SRC HIT = Initiator's HIT 951 DST HIT = Responder's HIT, or NULL 953 IP ( HIP ( DH_GROUP_LIST ) ) 955 Valid control bits: none 957 The I1 packet contains the fixed HIP header and the Initiator's 958 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 959 type as defined in Section 5.2.4. 961 Regarding the Responder's HIT, the Initiator may receive this HIT 962 either from a DNS lookup of the Responder's FQDN, from some other 963 repository, or from a local table. The Responder's HIT also MUST be 964 of a HIP DEX type. If the Initiator does not know the Responder's 965 HIT, it may attempt to use opportunistic mode by using NULL (all 966 zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for 967 detailed information about the "HIP Opportunistic Mode". 969 As the Initiator's and the Responder's HITs are compressions of the 970 employed HIs, they determine the DH Group ID that must be used in 971 order to successfully conclude the triggered handshake. HITs, 972 however, only include the OGA ID identifying the HI algorithm. They 973 do not include information about the specific group ID of the HI. To 974 inform the Responder about its employed and its otherwise supported 975 DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST 976 parameter in the I1 packet. This parameter MUST include the DH group 977 ID that corresponds to the currently employed Initiator HIT as the 978 first list element. With HIP DEX, the DH_GROUP_LIST parameter MUST 979 only include ECDH groups defined in Section 5.2.1. 981 Since this packet is so easy to spoof even if it were protected, no 982 attempt is made to add to its generation or processing cost. As a 983 result, the DH_GROUP_LIST in the I1 packet is not protected. 985 Implementations MUST be able to handle a storm of received I1 986 packets, discarding those with common content that arrive within a 987 small time delta. 989 5.3.2. R1 - the HIP Responder Packet 991 The HIP header values for the R1 packet: 993 Header: 994 Packet Type = 2 995 SRC HIT = Responder's HIT 996 DST HIT = Initiator's HIT 998 IP ( HIP ( [ R1_COUNTER, ] 999 PUZZLE, 1000 DH_GROUP_LIST, 1001 HIP_CIPHER, 1002 HOST_ID, 1003 HIT_SUITE_LIST, 1004 TRANSPORT_FORMAT_LIST, 1005 [ <, ECHO_REQUEST_UNSIGNED >i ]) 1007 Valid control bits: A 1009 If the Responder's HI is an anonymous one, the A control MUST be set. 1011 The Initiator's HIT MUST match the one received in the I1 packet if 1012 the R1 is a response to an I1. If the Responder has multiple HIs, 1013 the Responder's HIT MUST match the Initiator's request. If the 1014 Initiator used opportunistic mode, the Responder may select among its 1015 HIs as described below. See Section 4.1.8 of [RFC7401] for detailed 1016 information about the "HIP Opportunistic Mode". 1018 The R1 packet generation counter is used to determine the currently 1019 valid generation of puzzles. The value is increased periodically, 1020 and it is RECOMMENDED that it is increased at least as often as 1021 solutions to old puzzles are no longer accepted. 1023 The Puzzle contains a Random value #I and the puzzle difficulty K. 1024 The difficulty K indicates the number of lower-order bits, in the 1025 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 1026 SHOULD set K to zero by default and only increase the puzzle 1027 difficulty to protect against a DoS attack targeting the HIP DEX 1028 handshake. A puzzle difficulty of zero effectively turns the puzzle 1029 mechanism into a return-routablility test and is strongly encouraged 1030 during normal operation in order to conserve energy resources as well 1031 as to prevent unnecessary handshake delay in case of a resource- 1032 constrained Initiator. Please also refer to Section 7 for further 1033 recommendations on choosing puzzle difficulty. 1035 The DH_GROUP_LIST parameter contains the Responder's order of 1036 preference based on which the Responder chose the ECDH key contained 1037 in the HOST_ID parameter (see below). This allows the Initiator to 1038 determine whether its own DH_GROUP_LIST in the I1 packet was 1039 manipulated by an attacker. There is a further risk that the 1040 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 1041 packet cannot be authenticated in HI DEX. Thus, this parameter is 1042 repeated in the R2 packet to allow for a final, cryptographically 1043 secured validation. 1045 The HIP_CIPHER contains the encryption algorithms supported by the 1046 Responder to protect the key exchange, in the order of preference. 1047 All implementations MUST support the AES-CTR [RFC3686]. 1049 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 1050 supported and preferred HIT Suites. It enables a Responder to notify 1051 the Initiator about other available HIT suites than the one used in 1052 the current handshake. Based on the received HIT_SUITE_LIST, the 1053 Initiator MAY decide to abort the current handshake and initiate a 1054 new handshake with a different mutually supported HIT suite. This 1055 mechanism can, e.g., be used to move from an initial HIP DEX 1056 handshake to a HIP BEX handshake for peers supporting both protocol 1057 variants. 1059 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 1060 and the Responder HIT in the I1 packet. Specifically, if the I1 1061 contains a Responder HIT, the Responder verifies that this HIT 1062 matches the required DH group based on the received DH_GROUP_LIST 1063 parameter included in the I1. In case of a positive result, the 1064 Responder selects the corresponding HOST_ID for inclusion in the R1 1065 packet. Likewise, if the Responder HIT in the I1 packet is NULL 1066 (i.e., during an opportunistic handshake), the Responder chooses its 1067 HOST_ID according to the Initiator's employed DH group as indicated 1068 in the received DH_GROUP_LIST parameter and sets the source HIT in 1069 the R1 packet accordingly. If the Responder however does not support 1070 the DH group required by the Initiator or if the Responder HIT in the 1071 I1 packet does not match the required DH group, the Responder selects 1072 the mutually preferred and supported DH group based on the 1073 DH_GROUP_LIST parameter in the I1 packet. The Responder then 1074 includes the corresponding ECDH key in the HOST_ID parameter. This 1075 parameter also indicates the selected DH group. Moreover, the 1076 Responder sets the source HIT in the R2 packet based on the 1077 destination HIT from the I1 packet. Based on the deviating DH group 1078 ID in the HOST_ID parameter, the Initiator then SHOULD abort the 1079 current handshake and initiate a new handshake with the mutually 1080 supported DH group as far as local policies (see Section 7) permit. 1082 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 1083 Responder's supported and preferred transport format types. The list 1084 allows the Initiator and the Responder to agree on a common type for 1085 payload protection. The different format types are DEFAULT, ESP and 1086 ESP-TCP as explained in Section 3.1 in [RFC6261]. 1088 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 1089 wants to receive unmodified in the corresponding response packet in 1090 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 1091 or more ECHO_REQUEST_UNSIGNED parameters. 1093 5.3.3. I2 - the Second HIP Initiator Packet 1095 The HIP header values for the I2 packet: 1097 Header: 1098 Type = 3 1099 SRC HIT = Initiator's HIT 1100 DST HIT = Responder's HIT 1102 IP ( HIP ( [R1_COUNTER,] 1103 SOLUTION, 1104 HIP_CIPHER, 1105 ENCRYPTED_KEY, 1106 HOST_ID, 1107 TRANSPORT_FORMAT_LIST, 1108 HIP_MAC 1109 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1111 Valid control bits: A 1113 The HITs MUST match the ones used in the R1 packet. 1115 If the Initiator's HI is an anonymous one, the A control bit MUST be 1116 set. 1118 If present in the R1 packet, the Initiator MUST include an unmodified 1119 copy of the R1_COUNTER parameter into the I2 packet. 1121 The Solution contains the Random #I from the R1 packet and the 1122 computed #J value. The low-order #K bits of the RHASH(I | ... | J) 1123 MUST be zero. 1125 The HIP_CIPHER contains the single encryption transform selected by 1126 the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY 1127 parameters. The chosen cipher MUST correspond to one of the ciphers 1128 offered by the Responder in the R1. All implementations MUST support 1129 the AES-CTR transform [RFC3686]. 1131 The HOST_ID parameter contains the Initiator HI corresponding to the 1132 Initiator HIT. 1134 The ENCRYPTED_KEY parameter contains an Initiator generated random 1135 value that MUST be uniformly distributed. This random value is 1136 encrypted with the Master Key SA using the HIP_CIPHER encryption 1137 algorithm. 1139 The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque 1140 data copied from the corresponding echo request parameter(s). This 1141 parameter can also be used for two-factor password authentication as 1142 shown in Appendix A. 1144 The TRANSPORT_FORMAT_LIST parameter contains the single transport 1145 format type selected by the Initiator. The chosen type MUST 1146 correspond to one of the types offered by the Responder in the R1 1147 packet. The different format types are DEFAULT, ESP and ESP-TCP as 1148 explained in Section 3.1 in [RFC6261]. 1150 The MAC is calculated over the whole HIP envelope, excluding any 1151 parameters after the HIP_MAC parameter as described in Section 6.2. 1152 The Responder MUST validate the HIP_MAC parameter. 1154 5.3.4. R2 - the Second HIP Responder Packet 1156 The HIP header values for the R2 packet: 1158 Header: 1159 Packet Type = 4 1160 SRC HIT = Responder's HIT 1161 DST HIT = Initiator's HIT 1163 IP ( HIP ( DH_GROUP_LIST, 1164 HIP_CIPHER, 1165 ENCRYPTED_KEY, 1166 HIT_SUITE_LIST, 1167 TRANSPORT_FORMAT_LIST, 1168 HIP_MAC) 1170 Valid control bits: none 1172 The HITs used MUST match the ones used in the I2 packet. 1174 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1175 and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These 1176 parameters MUST be the same as included in the R1 packet. The 1177 parameter are re-included here because the R2 packet is MACed and 1178 thus cannot be altered by an attacker. For verification purposes, 1179 the Initiator re-evaluates the selected suites and compares the 1180 results against the chosen ones. If the re-evaluated suites do not 1181 match the chosen ones, the Initiator acts based on its local policy. 1183 The ENCRYPTED_KEY parameter contains an Responder generated random 1184 value that MUST be uniformly distributed. This random value is 1185 encrypted with the Master Key SA using the HIP_CIPHER encryption 1186 algorithm. 1188 The MAC is calculated over the whole HIP envelope, excluding any 1189 parameters after the HIP_MAC, as described in Section 6.2. The 1190 Initiator MUST validate the HIP_MAC parameter. 1192 5.4. ICMP Messages 1194 When a HIP implementation detects a problem with an incoming packet, 1195 and it either cannot determine the identity of the sender of the 1196 packet or does not have any existing HIP association with the sender 1197 of the packet, it MAY respond with an ICMP packet. Any such reply 1198 MUST be rate-limited as described in [RFC4443]. In most cases, the 1199 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1200 ICMPv6), with the Pointer field pointing to the field that caused the 1201 ICMP message to be generated. The problem cases specified in 1202 Section 5.4. of [RFC7401] also apply to HIP DEX. 1204 6. Packet Processing 1206 Due to the adopted protocol semantics and the inherited general 1207 packet structure, the packet processing in HIP DEX only differs from 1208 HIPv2 in very few places. Here, we focus on these differences and 1209 refer to Section 6 in [RFC7401] otherwise. 1211 The processing of outgoing and incoming application data remains the 1212 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1214 It should be noted that many of the packet processing rules are 1215 denoted here with "SHOULD" but may be updated to "MUST" when further 1216 implementation experience provides better guidance. Please refer 1217 also to Appendix B for argumentation about the SHOULDs. 1219 6.1. Solving the Puzzle 1221 The procedures for solving and verifying a puzzle in HIP DEX are 1222 strongly based on the corresponding procedures in HIPv2. The only 1223 exceptions are that HIP DEX does not use pre-computation of R1 1224 packets and that RHASH is set to CMAC. As a result, the pre- 1225 computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. 1227 Moreover, the Initiator solves a puzzle by computing: 1228 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1230 Similarly, the Responder verifies a puzzle by computing: 1231 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1233 Apart from these modifications, the procedures defined in Section 6.3 1234 of [RFC7401] also apply for HIP DEX. 1236 6.2. HIP_MAC Calculation and Verification 1238 The following subsections define the actions for processing the 1239 HIP_MAC parameter. 1241 6.2.1. CMAC Calculation 1243 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1244 cryptographic function. The scope of the calculation for HIP_MAC is: 1246 CMAC: { HIP header | [ Parameters ] } 1248 where Parameters include all HIP parameters of the packet that is 1249 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1250 value - 1) and exclude parameters with Type values greater or equal 1251 to HIP_MAC's Type value. 1253 During HIP_MAC calculation, the following applies: 1255 o In the HIP header, the Checksum field is set to zero. 1257 o In the HIP header, the Header Length field value is calculated to 1258 the beginning of the HIP_MAC parameter. 1260 The parameter order is described in Section 5.2.1 of [RFC7401]. 1262 The CMAC calculation and verification process is as follows: 1264 Packet sender: 1266 1. Create the HIP packet, without the HIP_MAC or any other parameter 1267 with greater Type value than the HIP_MAC parameter has. 1269 2. Calculate the Header Length field in the HIP header. 1271 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1272 retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers 1273 to host with greater HIT value and HIP-lg refers to the host with 1274 smaller HIT value. 1276 4. Add the HIP_MAC parameter to the packet and any parameter with 1277 greater Type value than the HIP_MAC's that may follow. 1279 5. Recalculate the Length field in the HIP header. 1281 Packet receiver: 1283 1. Verify the HIP header Length field. 1285 2. Remove the HIP_MAC parameter, as well as all other parameters 1286 that follow it with greater Type value, saving the contents if 1287 they will be needed later. 1289 3. Recalculate the HIP packet length in the HIP header and clear the 1290 Checksum field (set it to all zeros). 1292 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1293 defined in Section 6.3 and verify it against the received CMAC. 1295 5. Set Checksum and Header Length fields in the HIP header to 1296 original values. Note that the Checksum and Length fields 1297 contain incorrect values after this step. 1299 6.3. HIP DEX KEYMAT Generation 1301 The HIP DEX KEYMAT process is used to derive the keys for the Master 1302 Key SA as well as for the Pair-wise Key SA. The keys for the Master 1303 Key SA are based on the Diffie-Hellman derived key, Kij, which is 1304 produced during the HIP DEX handshake. The Initiator generates Kij 1305 during the creation of the I2 packet and the Responder generates Kij 1306 once it receives the I2 packet. This is why the I2 packet can 1307 already contain authenticated and/or encrypted information. 1309 The keys derived for the Pair-wise Key SA are not used during the HIP 1310 DEX handshake. Instead, these keys are made available as payload 1311 protection keys (e.g., for IPsec). Some payload protection 1312 mechanisms have their own Key Derivation Function, and if so this 1313 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 1314 be used to derive the keys of the Pair-wise Key SA based on the 1315 concatenation of the random values that are contained in the 1316 exchanged ENCRYPTED_KEY parameters. 1318 The HIP DEX KEYMAT process is based on the is the Hash-based Key 1319 Derivation Function (HKDF) defined in [RFC5869] and consists of two 1320 components, CKDF-Extract and CKDF-Expand. The CKDF-Extract function 1321 compresses a non-uniformly distributed key, such as the output of a 1322 Diffie-Hellman key derivation, to extract the key entropy into a 1323 fixed length output. The CKDF-Expand function takes either the 1324 output of the Extract function or directly uses a uniformly 1325 distributed key and expands the length of the key, repeatedly 1326 distributing the key entropy, to produce the keys needed. 1328 The key derivation for the Master Key SA employs always both the 1329 Extract and Expand phases. The Pair-wise Key SA needs only the 1330 Extract phase when key is smaller or equal to 128 bits, but otherwise 1331 requires also the Expand phase. 1333 The CKDF-Extract function is the following operation: 1335 CKDF-Extract(I, IKM, info) -> PRK 1337 Inputs: 1338 I Random #I from the PUZZLE parameter 1339 IKM Input keying material, i.e., the Diffie-Hellman derived 1340 key for the Master Key SA and the concatenation of the 1341 random values of the ENCRYPTED_KEY parameters in the 1342 same order as the HITs with sort(HIT-I | HIT-R) for the 1343 Pair-wise Key SA 1344 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1345 where "CKDF-Extract" is an octet string 1347 Output: 1348 PRK a pseudorandom key (of RHASH_len/8 octets) 1350 The pseudorandom key PRK is calculated as follows: 1352 PRK = CMAC(I, IKM | info) 1354 The CKDF-Expand function is the following operation: 1356 CKDF-Expand(PRK, info, L) -> OKM 1358 Inputs: 1359 PRK a pseudorandom key of at least RHASH_len/8 octets 1360 (either the output from the extract step or the 1361 concatenation of the random values of the 1362 ENCRYPTED_KEY parameters in the same order as the 1363 HITs with sort(HIT-I | HIT-R) in case of no extract) 1364 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1365 where "CKDF-Expand" is an octet string 1366 L length of output keying material in octets 1367 (<= 255*RHASH_len/8) 1369 Output: 1370 OKM output keying material (of L octets) 1372 The output keying material OKM is calculated as follows: 1374 N = ceil(L/(RHASH_len/8)) 1375 T = T(1) | T(2) | T(3) | ... | T(N) 1376 OKM = first L octets of T 1378 where 1380 T(0) = empty string (zero length) 1381 T(1) = CMAC(PRK, T(0) | info | 0x01) 1382 T(2) = CMAC(PRK, T(1) | info | 0x02) 1383 T(3) = CMAC(PRK, T(2) | info | 0x03) 1384 ... 1386 (where the constant concatenated to the end of each T(n) is a 1387 single octet.) 1389 sort(HIT-I | HIT-R) is defined as the network byte order 1390 concatenation of the two HITs, with the smaller HIT preceding the 1391 larger HIT, resulting from the numeric comparison of the two HITs 1392 interpreted as positive (unsigned) 128-bit integers in network byte 1393 order. 1395 The initial keys for the Master Key SA are drawn sequentially in the 1396 order that is determined by the numeric comparison of the two HITs, 1397 with the comparison method described in the previous paragraph. 1398 HOST_g denotes the host with the greater HIT value, and HOST_l the 1399 host with the lower HIT value. 1401 The drawing order for initial keys: 1403 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1404 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1406 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1408 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1410 The number of bits drawn for a given algorithm is the "natural" size 1411 of the keys regarding the algorithm defined in the HIP_CIPHER. For 1412 the mandatory algorithms, the following size applies: 1414 AES 128 bits 1416 If other key sizes are used, they must be treated as different 1417 encryption algorithms and defined separately. 1419 6.4. Initiation of a HIP Diet EXchange 1421 The initiation of a HIP DEX handshake proceeds as described in 1422 Section 6.6 of [RFC7401]. The I1 packet contents are specified in 1423 Section 5.3.1. 1425 6.5. Processing Incoming I1 Packets 1427 I1 packets in HIP DEX are handled almost identical to HIPv2 (see 1428 Section 6.7 of [RFC7401]). The main differences are that the 1429 Responder SHOULD select a HIP DEX HIT Suite in the R1 response. 1430 Moreover, as R1 packets are neither covered by a signature nor incur 1431 the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- 1432 computation of an R1 is only marginally beneficial, but would incur 1433 additional memory resources at the Responder. Hence, the R1 pre- 1434 computation SHOULD be omitted in HIP DEX. 1436 Correspondingly, the modified conceptual processing rules for 1437 responding to an I1 packet are as follows: 1439 1. The Responder MUST check that the Responder's HIT in the received 1440 I1 packet is either one of its own HITs or NULL. Otherwise, it 1441 MUST drop the packet. 1443 2. If the Responder is in ESTABLISHED state, the Responder MAY 1444 respond to this with an R1 packet, prepare to drop an existing 1445 HIP security association with the peer, and stay at ESTABLISHED 1446 state. 1448 3. If the Responder is in I1-SENT state, it MUST make a comparison 1449 between the sender's HIT and its own (i.e., the receiver's) HIT. 1450 If the sender's HIT is greater than its own HIT, it should drop 1451 the I1 packet and stay at I1-SENT. If the sender's HIT is 1452 smaller than its own HIT, it SHOULD send the R1 packet and stay 1453 at I1-SENT. The HIT comparison is performed as defined in 1454 Section 6.3. 1456 4. If the implementation chooses to respond to the I1 packet with an 1457 R1 packet, it creates a new R1 according to the format described 1458 in Section 5.3.2. It chooses the HI based on the destination HIT 1459 and the DH_GROUP_LIST in the I1 packet. If the implementation 1460 does not support the DH group required by the Initiator or if the 1461 destination HIT in the I1 packet does not match the required DH 1462 group, it selects the mutually preferred and supported DH group 1463 based on the DH_GROUP_LIST parameter in the I1 packet. The 1464 implementation includes the corresponding ECDH public key in the 1465 HOST_ID parameter. If no suitable DH Group ID was contained in 1466 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with 1467 any suitable ECDH public key. 1469 5. If the received Responder's HIT in the I1 packet is not NULL, the 1470 Responder's HIT in the R1 packet MUST match the destination HIT 1471 in the I1 packet. Otherwise, the Responder MUST select a HIT 1472 with the same HIT Suite as the Initiator's HIT. If this HIT 1473 Suite is not supported by the Responder, it SHOULD select a 1474 REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is 1475 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 1476 a local policy matter. 1478 6. The Responder expresses its supported HIP transport formats in 1479 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of 1480 [RFC7401]. The Responder MUST provide at least one payload 1481 transport format type. 1483 7. The Responder sends the R1 packet to the source IP address of the 1484 I1 packet. 1486 Note that only steps 4 and 5 have been changed with regard to the 1487 processing rules of HIPv2. The considerations about R1 management 1488 (except pre-computation) and malformed I1 packets in Sections 6.7.1 1489 and 6.7.2 of [RFC7401] likewise apply to HIP DEX. 1491 6.6. Processing Incoming R1 Packets 1493 R1 packets in HIP DEX are handled identically to HIPv2 (see 1494 Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses 1495 ECDH public keys as HIs and does not employ signatures. 1497 The modified conceptual processing rules for responding to an R1 1498 packet are as follows: 1500 1. A system receiving an R1 MUST first check to see if it has sent 1501 an I1 packet to the originator of the R1 packet (i.e., it has a 1502 HIP association that is in state I1-SENT and that is associated 1503 with the HITs in the R1). Unless the I1 packet was sent in 1504 opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP 1505 addresses in the received R1 packet SHOULD be ignored by the R1 1506 processing and, when looking up the correct HIP association, the 1507 received R1 packet SHOULD be matched against the associations 1508 using only the HITs. If a match exists, the system processes 1509 the R1 packet as described below. 1511 2. Otherwise, if the system is in any state other than I1-SENT or 1512 I2-SENT with respect to the HITs included in the R1 packet, it 1513 SHOULD silently drop the R1 packet and remain in the current 1514 state. 1516 3. If the HIP association state is I1-SENT or I2-SENT, the received 1517 Initiator's HIT MUST correspond to the HIT used in the original 1518 I1 packet. Also, the Responder's HIT MUST correspond to the one 1519 used in the I1 packet, unless this packet contained a NULL HIT. 1521 4. If the HIP association state is I1-SENT, and multiple valid R1 1522 packets are present, the system MUST select from among the R1 1523 packets with the largest R1 generation counter. 1525 5. The system MUST check that the Initiator's HIT Suite is 1526 contained in the HIT_SUITE_LIST parameter in the R1 packet 1527 (i.e., the Initiator's HIT Suite is supported by the Responder). 1528 If the HIT Suite is supported by the Responder, the system 1529 proceeds normally. Otherwise, the system MAY stay in state 1530 I1-SENT and restart the HIP DEX handshake by sending a new I1 1531 packet with an Initiator HIT that is supported by the Responder 1532 and hence is contained in the HIT_SUITE_LIST in the R1 packet. 1533 The system MAY abort the handshake if no suitable source HIT is 1534 available. The system SHOULD wait for an acceptable time span 1535 to allow further R1 packets with higher R1 generation counters 1536 or different HIT and HIT Suites to arrive before restarting or 1537 aborting the HIP DEX handshake. 1539 6. The system MUST check that the DH Group ID in the HOST_ID 1540 parameter in the R1 matches the first DH Group ID in the 1541 Responder's DH_GROUP_LIST in the R1 packet, and also that this 1542 Group ID corresponds to a value that was included in the 1543 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 1544 of the HOST_ID parameter does not express the Responder's best 1545 choice, the Initiator can conclude that the DH_GROUP_LIST in the 1546 I1 or R1 packet was adversely modified. In such a case, the 1547 Initiator MAY send a new I1 packet; however, it SHOULD NOT 1548 change its preference in the DH_GROUP_LIST in the new I1 packet. 1549 Alternatively, the Initiator MAY abort the HIP DEX handshake. 1550 Moreover, if the DH Group ID indicated in the HOST_ID parameter 1551 does not match the DH Group ID of the HI employed by the 1552 Initiator, the system SHOULD wait for an acceptable time span to 1553 allow further R1 packets with different DH Group IDs to arrive 1554 before restarting or aborting the HIP DEX handshake. When 1555 restarting the handshake, the Initiator MUST consult local 1556 policies (see Section 7) regarding the use of another, mutually 1557 supported DH group for the subsequent handshake with the 1558 Responder. 1560 7. If the HIP association state is I2-SENT, the system MAY re-enter 1561 state I1-SENT and process the received R1 packet if it has a 1562 larger R1 generation counter than the R1 packet responded to 1563 previously. 1565 8. The R1 packet can have the A-bit set - in this case, the system 1566 MAY choose to refuse it by dropping the R1 packet and returning 1567 to state UNASSOCIATED. The system SHOULD consider dropping the 1568 R1 packet only if it used a NULL HIT in the I1 packet. If the 1569 A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be 1570 stored permanently. 1572 9. The system SHOULD attempt to validate the HIT against the 1573 received Host Identity by using the received Host Identity to 1574 construct a HIT and verify that it matches the Sender's HIT. 1576 10. The system MUST store the received R1 generation counter for 1577 future reference. 1579 11. The system attempts to solve the puzzle in the R1 packet. The 1580 system MUST terminate the search after exceeding the remaining 1581 lifetime of the puzzle. If the puzzle is not successfully 1582 solved, the implementation MAY either resend the I1 packet 1583 within the retry bounds or abandon the HIP base exchange. 1585 12. The system computes standard Diffie-Hellman keying material 1586 according to the public value and Group ID provided in the 1587 HOST_ID parameter. The Diffie-Hellman keying material Kij is 1588 used for key extraction as specified in Section 6.3. 1590 13. The system selects the HIP_CIPHER ID from the choices presented 1591 in the R1 packet and uses the selected values subsequently when 1592 generating and using encryption keys, and when sending the I2 1593 packet. If the proposed alternatives are not acceptable to the 1594 system, it MAY either resend an I1 packet within the retry 1595 bounds or abandon the HIP base exchange. 1597 14. The system chooses one suitable transport format from the 1598 TRANSPORT_FORMAT_LIST and includes the respective transport 1599 format parameter in the subsequent I2 packet. 1601 15. The system initializes the remaining variables in the associated 1602 state, including Update ID counters. 1604 16. The system prepares and sends an I2 packet as described in 1605 Section 5.3.3. 1607 17. The system SHOULD start a timer whose timeout value SHOULD be 1608 larger than the worst-case anticipated RTT, and MUST increment a 1609 trial counter associated with the I2 packet. The sender SHOULD 1610 retransmit the I2 packet upon a timeout and restart the timer, 1611 up to a maximum of I2_RETRIES_MAX tries. 1613 18. If the system is in state I1-SENT, it SHALL transition to state 1614 I2-SENT. If the system is in any other state, it remains in the 1615 current state. 1617 Note that step 4 from the original processing rules of HIPv2 1618 (signature verification) has been removed in the above processing 1619 rules for HIP DEX. Moreover, step 7 of the original processing rules 1620 has been adapted in step 6 above to account for the fact that HIP DEX 1621 uses ECDH public keys as HIs. The considerations about malformed R1 1622 packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX. 1624 6.7. Processing Incoming I2 Packets 1626 The processing of I2 packets follows similar rules as HIPv2 (see 1627 Section 6.9 of [RFC7401]). The main differences to HIPv2 are that 1628 HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY 1629 parameter as well as an I2 reception acknowledgement for 1630 retransmission purposes. Moreover, with HIP DEX the Initiator is 1631 responsible for triggering retransmissions, whereas the Responder 1632 merely replies to received I2 packets. 1634 The modified HIP DEX conceptual processing rules for responding to an 1635 I2 packet are: 1637 1. The system MAY perform checks to verify that the I2 packet 1638 corresponds to a recently sent R1 packet. Such checks are 1639 implementation dependent. See Appendix A in [RFC7401] for a 1640 description of an example implementation. 1642 2. The system MUST check that the Responder's HIT corresponds to 1643 one of its own HITs and MUST drop the packet otherwise. 1645 3. The system MUST further check that the Initiator's HIT Suite is 1646 supported. The Responder SHOULD silently drop I2 packets with 1647 unsupported Initiator HITs. 1649 4. If the system's state machine is in the R2-SENT state, the 1650 system MUST check to see if the newly received I2 packet is 1651 similar to the one that triggered moving to R2-SENT. If so, it 1652 MUST retransmit a previously sent R2 packet and reset the 1653 R2-SENT timer. The system SHOULD re-use the previously 1654 established state to re-create the corresponding R2 packet in 1655 order to prevent unnecessary computation overhead. 1657 5. If the system's state machine is in the I2-SENT state, the 1658 system MUST make a comparison between its local and sender's 1659 HITs (similarly as in Section 6.3). If the local HIT is smaller 1660 than the sender's HIT, it should drop the I2 packet, use the 1661 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1662 #I from the R1 packet received earlier, and get the local 1663 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1664 from the I2 packet sent to the peer earlier. Otherwise, the 1665 system processes the received I2 packet and drops any previously 1666 derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY 1667 keying material it might have generated upon sending the I2 1668 packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY, 1669 and the nonce #J are taken from the just arrived I2 packet. The 1670 local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the 1671 nonce #I are the ones that were sent earlier in the R1 packet. 1673 6. If the system's state machine is in the I1-SENT state, and the 1674 HITs in the I2 packet match those used in the previously sent I1 1675 packet, the system uses this received I2 packet as the basis for 1676 the HIP association it was trying to form, and stops 1677 retransmitting I1 packets (provided that the I2 packet passes 1678 the additional checks below). 1680 7. If the system's state machine is in any state other than 1681 R2-SENT, the system SHOULD check that the echoed R1 generation 1682 counter in the I2 packet is within the acceptable range if the 1683 counter is included. Implementations MUST accept puzzles from 1684 the current generation and MAY accept puzzles from earlier 1685 generations. If the generation counter in the newly received I2 1686 packet is outside the accepted range, the I2 packet is stale 1687 (and perhaps replayed) and SHOULD be dropped. 1689 8. The system MUST validate the solution to the puzzle as described 1690 in Section 6.1. 1692 9. The I2 packet MUST have a single value in the HIP_CIPHER 1693 parameter, which MUST match one of the values offered to the 1694 Initiator in the R1 packet. 1696 10. The system MUST derive Diffie-Hellman keying material Kij based 1697 on the public value and Group ID in the HOST_ID parameter. This 1698 keying material is used to derive the keys of the Master Key SA 1699 as described in Section 6.3. If the Diffie-Hellman Group ID is 1700 unsupported, the I2 packet is silently dropped. If the 1701 processing time for the derivation of the Diffie-Hellman keying 1702 material Kij is likely to cause premature I2 retransmissions by 1703 the Initiator, the system MAY send a NOTIFY packet before 1704 starting the key derivation process. The NOTIFY packet contains 1705 a NOTIFICATION parameter with Notify Message Type 1706 I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the 1707 anticipated remaining processing time for the I2 packet in 1708 milliseconds as two-octet Notification Data. 1710 11. The implementation SHOULD also verify that the Initiator's HIT 1711 in the I2 packet corresponds to the Host Identity sent in the I2 1712 packet. (Note: some middleboxes may not be able to make this 1713 verification.) 1715 12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1716 Other documents specifying transport formats (e.g., [RFC7402]) 1717 contain specifications for handling any specific transport 1718 selected. 1720 13. The system MUST verify the HIP_MAC according to the procedures 1721 in Section 6.2. 1723 14. If the checks above are valid, then the system proceeds with 1724 further I2 processing; otherwise, it discards the I2 and its 1725 state machine remains in the same state. 1727 15. The I2 packet may have the A-bit set - in this case, the system 1728 MAY choose to refuse it by dropping the I2 and the state machine 1729 returns to state UNASSOCIATED. If the A-bit is set, the 1730 Initiator's HIT is anonymous and MUST NOT be stored permanently. 1732 16. The system MUST decrypt the keying material from the 1733 ENCRYPTED_KEY parameter. This keying material is a partial 1734 input to the key derivation process for the Pair-wise Key SA 1735 (see Section 6.3). 1737 17. The system initializes the remaining variables in the associated 1738 state, including Update ID counters. 1740 18. Upon successful processing of an I2 packet when the system's 1741 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 1742 R2-SENT, an R2 packet is sent as described in Section 5.3.4 and 1743 the system's state machine transitions to state R2-SENT. 1745 19. Upon successful processing of an I2 packet when the system's 1746 state machine is in state ESTABLISHED, the old HIP association 1747 is dropped and a new one is installed, an R2 packet is sent as 1748 described in Section 5.3.4, and the system's state machine 1749 transitions to R2-SENT. 1751 20. Upon the system's state machine transitioning to R2-SENT, the 1752 system starts a timer. The state machine transitions to 1753 ESTABLISHED if some data has been received on the incoming HIP 1754 association, or an UPDATE packet has been received (or some 1755 other packet that indicates that the peer system's state machine 1756 has moved to ESTABLISHED). If the timer expires (allowing for a 1757 maximal amount of retransmissions of I2 packets), the state 1758 machine transitions to ESTABLISHED. 1760 Note that steps 11 (encrypted HOST_ID) and 15 (signature 1761 verification) from the original processing rules of HIPv2 have been 1762 removed in the above processing rules for HIP DEX. Moreover, step 10 1763 of the HIPv2 processing rules has been adapted to account for 1764 optional extension of the retransmission mechanism. Step 16 has been 1765 added to the processing rules in this document. The considerations 1766 about malformed I2 packets in Sections 6.9.1 of [RFC7401] also apply 1767 to HIP DEX. 1769 6.8. Processing Incoming R2 Packets 1771 R2 packets in HIP DEX are handled identically to HIPv2 (see 1772 Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX 1773 introduces a new session key exchange via the ENCRYPTED_KEY parameter 1774 and does not employ signatures. 1776 The modified conceptual processing rules for responding to an R2 1777 packet are as follows: 1779 1. If the system is in any other state than I2-SENT, the R2 packet 1780 is silently dropped. 1782 2. The system MUST verify that the HITs in use correspond to the 1783 HITs that were received in the R1 packet that caused the 1784 transition to the I2-SENT state. 1786 3. The system MUST verify the HIP_MAC according to the procedures in 1787 Section 6.2. 1789 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1790 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1791 packet and compare the results against the chosen suites. 1793 5. If any of the checks above fail, there is a high probability of 1794 an ongoing man-in-the-middle or other security attack. The 1795 system SHOULD act accordingly, based on its local policy. 1797 6. The system MUST decrypt the keying material from the 1798 ENCRYPTED_KEY parameter. This keying material is a partial input 1799 to the key derivation process for the Pair-wise Key SA (see 1800 Section 6.3). 1802 7. Upon successful processing of the R2 packet, the state machine 1803 transitions to state ESTABLISHED. 1805 Note that step 4 (signature verification) from the original 1806 processing rules of HIPv2 has been replaced with a negotiation re- 1807 evaluation in the above processing rules for HIP DEX. Moreover, step 1808 6 has been added to the processing rules. 1810 6.9. Processing Incoming NOTIFY Packets 1812 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 1813 in a received NOTIFICATION parameter SHOULD be logged. Received 1814 errors MUST be considered only as informational, and the receiver 1815 SHOULD NOT change its HIP state purely based on the received NOTIFY 1816 packet. 1818 If a NOTIFY packet is received in state I2-SENT, this packet is an I2 1819 reception acknowledgement of the optional retransmission mechanism 1820 extension and SHOULD be processed. The following steps define the 1821 conceptual processing rules for such incoming NOTIFY packets in state 1822 I2-SENT: 1824 1. The system MUST verify that the HITs in use correspond to the 1825 HITs that were received in the R1 packet that caused the 1826 transition to the I2-SENT state. If this check fails, the NOTIFY 1827 packet MUST be dropped silently. 1829 2. If the NOTIFY packet contains a NOTIFICATION parameter with 1830 Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the 1831 I2 retransmission timer to the I2 processing time indicated in 1832 the NOTIFICATION parameter plus half the RTT-based timeout value. 1833 The system MUST NOT set the retransmission timeout to a higher 1834 value than allowed by a local policy. Moreover, the system 1835 SHOULD reset the I2 retransmission timer to the RTT-based timeout 1836 value after the next I2 retransmission. 1838 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 1840 UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 1841 as in HIPv2 (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). 1842 The only difference is the that the HIP_SIGNATURE is never present 1843 and, therefore, is not required to be processed by the receiving 1844 party. 1846 [RFC7402] specifies the rekeying of an existing HIP SA using the 1847 UPDATE message. This rekeying procedure can also be used with HIP 1848 DEX. However, where rekeying involves a new Diffie-Hellman key 1849 exchange, HIP DEX peers MUST establish a new HIP association in order 1850 to create a new Pair-wise Key SA due to the use of static ECDH key- 1851 pairs with HIP DEX. 1853 6.11. Handling State Loss 1855 Implementors MAY choose to use non-volatile, secure storage for HIP 1856 states in order for them to survive a system reboot. If no secure 1857 storage capabilities are available, the system SHOULD delete the 1858 corresponding HIP state, including the keying material. If the 1859 implementation does drop the state (as RECOMMENDED), it MUST also 1860 drop the peer's R1 generation counter value, unless a local policy 1861 explicitly defines that the value of that particular host is stored. 1862 Such storing of the R1 generation counter values MUST be configured 1863 by explicit HITs. 1865 7. HIP Policies 1867 There are a number of variables that will influence the HIP exchanges 1868 that each host must support. The value of puzzle difficulty K used 1869 in the HIP R1 must be chosen with care. Values for the K that are 1870 too high will exclude clients with weak CPUs because these devices 1871 cannot solve the puzzle within a reasonable amount of time. The K 1872 value should only be raised if a Responder is under high load, i.e., 1873 it cannot process all incoming HIP handshakes any more. 1875 If a Responder is not under high load, K SHOULD be 0. 1877 All HIP DEX implementations SHOULD provide for an Access Control List 1878 (ACL), representing for which hosts they accept HIP diet exchanges, 1879 and the preferred transport format and local lifetimes. Wildcarding 1880 SHOULD be supported for such ACLs. 1882 8. Interoperability between HIP DEX and HIPv2 1884 HIP DEX and HIPv2 both use the same protocol number and packet 1885 formats. Hence, an implementation that either supports HIP DEX or 1886 HIPv2 has to be able to detect the dialect that the peer is speaking. 1887 This section outlines how a HIP DEX implementation can achieve such 1888 detection for the two relevant cases where: 1890 1. the Initiator supports HIP DEX and the Responder supports HIP 1891 BEX, 1893 2. the Initiator supports HIP BEX and the Responder supports HIP 1894 DEX. 1896 In the first case, the HIP DEX implementation (Initiator) inspects 1897 the Responder's HIT prior to sending the I1 packet. If the OGA ID 1898 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 1899 DEX implementation cancels the handshake. If the Responder is 1900 unknown prior to sending the I1 packet (i.e., opportunistic mode), 1901 the HIP DEX implementation performs the above check on reception of 1902 the R1 packet and cancels the handshake in case of a negative result. 1903 In both failure scenarios, the implementation should report an error 1904 to the user via appropriate means. 1906 In the second case, the HIP DEX implementation (Responder) inspects 1907 the Initiator's HIT on reception of an I1 packet. If the OGA ID 1908 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 1909 DEX implementation cancels the handshake and sends an ICMP packet 1910 with type Parameter Problem, with the Pointer pointing to the source 1911 HIT, to the Initiator. As an off-path adversary could also send such 1912 an ICMP packet with the aim to prevent the HIP DEX handshake from 1913 completing, the Initiator SHOULD NOT react to an ICMP message before 1914 retransmission counter reaches I1_RETRIES_MAX in its state machine 1915 (see Table 3 in [RFC7401]). 1917 9. Security Considerations 1919 HIP DEX closely resembles HIPv2. As such, the security 1920 considerations discussed in Section 8 of [RFC7401] similarly apply to 1921 HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated 1922 Diffie-Hellman key exchange of HIPv2 with an exchange of random 1923 keying material that is encrypted with a Diffie-Hellman derived key. 1924 Both the Initiator and Responder contribute to this keying material. 1925 As a result, the following additional security considerations apply 1926 to HIP DEX: 1928 o The strength of the keys for the Pair-wise Key SA is based on the 1929 quality of the random keying material generated by the Initiator 1930 and the Responder. As either peer may be a sensor or an actuator 1931 device, there is a natural concern about the quality of its random 1932 number generator. 1934 o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. 1935 Consequently, if an HI is compromised, all previous HIP 1936 connections protected with that HI are compromised as explained in 1937 Section 1. 1939 o The puzzle mechanism using CMAC explained in Section 4.1.1 may 1940 need further study regarding the level of difficulty in order to 1941 establish best practices with current generation of constrained 1942 devices. 1944 o The HIP DEX HIT generation may present new attack opportunities. 1945 Hence, HIP DEX HITs MUST NOT be used as the only means to identify 1946 a peer in an ACL. Instead, the use of the peer's HI is 1947 recommended as explained in Section 3. 1949 o The R1 packet is unauthenticated and offers an adversary a new 1950 attack vector against the Initiator. This is mitigated by only 1951 processing a received R1 packet when the Initiator has previously 1952 sent a corresponding I1 packet. Moreover, the Responder repeats 1953 the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and 1954 TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to 1955 enable the Initiator to verify that these parameters have not been 1956 modified by an attacker in the unprotected R1 packet as explained 1957 in Section 6.8. 1959 o Contrary to HIPv2, HIP DEX does not provide for end-point 1960 anonymity for the Initiator or Responder. Thus, any signaling 1961 that indicates such anonymity should be ignored as explained in 1962 Section 1.1. 1964 The optional retransmission extension of HIP DEX is based on a NOTIFY 1965 packet that the Responder can use to inform the Initiator about the 1966 reception of an I2 packet. The Responder, however, cannot protect 1967 the authenticity of this packet as it did not yet set up the Master 1968 Key SA. Hence, an eavesdropping adversary may send spoofed reception 1969 acknowledgments for an overheard I2 packet and signal an arbitrary I2 1970 processing time to the Initiator. The adversary can, e.g., indicate 1971 a lower I2 processing time than actually required by the Responder in 1972 order to cause premature retransmissions. To protect against this 1973 attack, the Initiator SHOULD set the NOTIFY-based timeout value to 1974 the maximum indicated packet processing time in case of conflicting 1975 NOTIFY packets. This allows the legitimate Responder to extend the 1976 retransmission timeout to the intended length. The adversary, 1977 however, can still arbitrarily delay the protocol handshake beyond 1978 the Responder's actual I2 processing time. To limit the extend of 1979 such a maliciously induced handshake delay, this specification 1980 additionally requires the Initiator not to set the NOTIFY-based 1981 timeout value higher than allowed by a local policy. 1983 Section 5.3.1 mentions that implementations need to be able to handle 1984 storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre- 1985 computated in HIP DEX and also the state machine does not include an 1986 "R1_SENT" state (that would enable caching of R1 packets). 1987 Therefore, an implementation has to cache information (e.g., at least 1988 the HITs) from incoming I1 packets and rate control the incoming I1 1989 packets to avoid unnecessary packet processing during I1 packet 1990 storms. 1992 10. IANA Considerations 1994 The following changes to the "Host Identity Protocol (HIP) 1995 Parameters" registries have been made: 1997 Parameter Type This document defines the new HIP parameter 1998 "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) (see 1999 Section 5.2.5). 2001 HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" 2002 without four-bit ID of TBD2 (suggested: 8) and eight-bit encoding 2003 of TBD3 (suggested: 0x80) (see Section 5.2.4). 2005 HIP Cipher ID This document defines the new HIP Cipher ID "AES- 2006 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2). 2008 HI Algorithm This document defines the new HI Algorithm "ECDH" with 2009 type number TBD5 (suggested: 11) (see Section 5.2.3). 2011 ECC Curve Label This document specifies a new algorithm-specific 2012 subregistry named "ECDH Curve Label". The values for this 2013 subregistry are defined in Section 5.2.1. 2015 11. Acknowledgments 2017 The drive to put HIP on a cryptographic 'Diet' came out of a number 2018 of discussions with sensor vendors at IEEE 802.15 meetings. David 2019 McGrew was very helpful in crafting this document. Special thanks to 2020 Miika Komu for reviewing this document in the context of Convince 2021 Celtic+ project. 2023 12. Changelog 2025 This section summarizes the changes made from draft-moskowitz-hip-rg- 2026 dex-05, which was the first stable version of the draft. Note that 2027 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 2029 The draft was then renamed from draft-moskowitz-hip-dex to draft- 2030 ietf-hip-dex. 2032 12.1. Changes in draft-ietf-hip-dex-09 2034 o Fixed values for 2036 * DH_GROUP_LIST 2038 * HIT_SUITE_LIST 2040 to match [RFC7401]. 2042 12.2. Changes in draft-ietf-hip-dex-05 2044 o Clarified main differences between HIP BEX and HIP DEX in 2045 Section 1. 2047 o Addressed MitM attack in Section 8. 2049 o Minor editorial changes. 2051 12.3. Changes in draft-ietf-hip-dex-04 2053 o Added new paragraph on rekeying procedure with HIP DEX. 2055 o Updated references. 2057 o Editorial changes. 2059 12.4. Changes in draft-ietf-hip-dex-03 2061 o Added new section on HIP DEX/HIPv2 interoperability 2063 o Added reference to RFC4493 for CMAC. 2065 o Added reference to RFC5869 for CKDF. 2067 o Added processing of NOTIFY message in I2-SENT of state diagram. 2069 o Editorial changes. 2071 12.5. Changes in draft-ietf-hip-dex-02 2073 o Author address change. 2075 12.6. Changes in draft-ietf-hip-dex-01 2077 o Added the new ECDH groups of Curve25519 and Curve448 from RFC 2078 7748. 2080 12.7. Changes in draft-ietf-hip-dex-00 2082 o The Internet Draft was adopted by the HIP WG. 2084 12.8. Changes in draft-moskowitz-hip-rg-dex-06 2086 o A major change in the ENCRYPT parameter to use AES-CTR rather than 2087 AES-CBC. 2089 12.9. Changes in draft-moskowitz-hip-dex-00 2091 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 2092 submission. 2094 o Added the change section. 2096 o Added a Definitions section. 2098 o Changed I2 and R2 packets to reflect use of AES-CTR for 2099 ENCRYPTED_KEY parameter. 2101 o Cleaned up KEYMAT Generation text. 2103 o Added Appendix with C code for the ECDH shared secret generation 2104 on an 8 bit processor. 2106 12.10. Changes in draft-moskowitz-hip-dex-01 2108 o Numerous editorial changes. 2110 o New retransmission strategy. 2112 o New HIT generation mechanism. 2114 o Modified layout of ENCRYPTED_KEY parameter. 2116 o Clarify to use puzzle difficulty of zero under normal network 2117 conditions. 2119 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 2120 MUST). 2122 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 2123 and I2). 2125 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 2126 echoed in R2 packet. 2128 o Added new author. 2130 12.11. Changes in draft-moskowitz-hip-dex-02 2132 o Introduced formal definition of FOLD function. 2134 o Clarified use of CMAC for puzzle computation in section "Solving 2135 the Puzzle". 2137 o Several editorial changes. 2139 12.12. Changes in draft-moskowitz-hip-dex-03 2141 o Addressed HI crypto agility. 2143 o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 2145 o Extended the IV in the ENCRYPTED_KEY parameter. 2147 o Introduced forward-references to HIP DEX KEYMAT process and 2148 improved KEYMAT section. 2150 o Replaced Appendix A on "C code for ECC point multiplication" with 2151 short discussion in introduction. 2153 o Updated references. 2155 o Further editorial changes. 2157 12.13. Changes in draft-moskowitz-hip-dex-04 2159 o Improved retransmission extension. 2161 o Updated and strongly revised packet processing rules. 2163 o Updated security considerations. 2165 o Updated IANA considerations. 2167 o Move the HI Algorithm for ECDH to a value of 11. 2169 o Many editorial changes. 2171 13. References 2173 13.1. Normative References 2175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2176 Requirement Levels", BCP 14, RFC 2119, 2177 DOI 10.17487/RFC2119, March 1997, 2178 . 2180 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2181 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 2182 November 1998, . 2184 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2185 Counter Mode With IPsec Encapsulating Security Payload 2186 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2187 . 2189 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2190 Control Message Protocol (ICMPv6) for the Internet 2191 Protocol Version 6 (IPv6) Specification", STD 89, 2192 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2193 . 2195 [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the 2196 Host Identity Protocol", RFC 6261, DOI 10.17487/RFC6261, 2197 May 2011, . 2199 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 2200 Routable Cryptographic Hash Identifiers Version 2 2201 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2202 2014, . 2204 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2205 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2206 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2207 . 2209 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2210 Encapsulating Security Payload (ESP) Transport Format with 2211 the Host Identity Protocol (HIP)", RFC 7402, 2212 DOI 10.17487/RFC7402, April 2015, 2213 . 2215 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2216 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2217 May 2017, . 2219 13.2. Informative References 2221 [DH76] Diffie, W. and M. Hellman, "New Directions in 2222 Cryptography", IEEE Transactions on Information 2223 Theory vol. IT-22, number 6, pages 644-654, Nov 1976. 2225 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 2226 Wehrle, "Tailoring End-to-End IP Security Protocols to the 2227 Internet of Things", in Proceedings of IEEE International 2228 Conference on Network Protocols (ICNP 2013), October 2013. 2230 [I-D.ietf-hip-rfc4423-bis] 2231 Moskowitz, R. and M. Komu, "Host Identity Protocol 2232 Architecture", draft-ietf-hip-rfc4423-bis-20 (work in 2233 progress), February 2019. 2235 [IEEE.802-11.2007] 2236 Engineers, I. O. E. A. E., "Information technology - 2237 Telecommunications and information exchange between 2238 systems - Local and metropolitan area networks - Specific 2239 requirements - Part 11: Wireless LAN Medium Access Control 2240 (MAC) and Physical Layer (PHY) Specifications", 2241 IEEE Standard 802.11, June 2007, 2242 . 2245 [IEEE.802-15-4.2011] 2246 Engineers, I. O. E. A. E., "Information technology - 2247 Telecommunications and information exchange between 2248 systems - Local and metropolitan area networks - Specific 2249 requirements - Part 15.4: Wireless Medium Access Control 2250 (MAC) and Physical Layer (PHY) Specifications for Low-Rate 2251 Wireless Personal Area Networks (WPANs)", IEEE Standard 2252 802.15.4, September 2011, 2253 . 2256 [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for 2257 Elliptic Curve Cryptography in Wireless Sensor Networks", 2258 in Proceedings of International Conference on Information 2259 Processing in Sensor Networks (IPSN 2008), April 2008. 2261 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 2262 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2263 2006, . 2265 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2266 Key Derivation Function (HKDF)", RFC 5869, 2267 DOI 10.17487/RFC5869, May 2010, 2268 . 2270 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2271 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2272 DOI 10.17487/RFC5903, June 2010, 2273 . 2275 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2276 Curve Cryptography Algorithms", RFC 6090, 2277 DOI 10.17487/RFC6090, February 2011, 2278 . 2280 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2281 Constrained-Node Networks", RFC 7228, 2282 DOI 10.17487/RFC7228, May 2014, 2283 . 2285 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2286 Kivinen, "Internet Key Exchange Protocol Version 2 2287 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2288 2014, . 2290 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2291 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2292 2016, . 2294 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2295 2 , 2000, . 2297 Appendix A. Password-based two-factor authentication during the HIP DEX 2298 handshake 2300 HIP DEX allows to identify authorized connections based on a two- 2301 factor authentication mechanism. With two-factor authentication, 2302 devices that are authorized to communicate with each other are 2303 required to be pre-provisioned with a shared (group) key. The 2304 Initiator uses this pre-provisioned key to encrypt the 2305 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 2306 the Responder verifies that its challenge in the 2307 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 2308 with the correct key. If verified successfully, the Responder 2309 proceeds with the handshake. Otherwise, it silently drops the I2 2310 packet. 2312 Note that there is no explicit signaling in the HIP DEX handshake for 2313 this behavior. Thus, knowledge of two-factor authentication must be 2314 configured externally prior to the handshake. 2316 Appendix B. IESG Considerations 2318 During IEDG review, a concern was raised on the number of SHOULDS in 2319 this document. Here is an analysis of the 57 SHOULDS in HIP DEX. 2321 46 of SHOULDS are also in [RFC7401]. Here are the sections with 2322 SHOULDS that match up with [RFC7401]: 2324 5.2.2. HIP_CIPHER (same as 7401) 2326 6.5. Processing Incoming I1 Packets 2327 3. (same as 7401) 2328 5. (same as 7401) 2330 6.6. Processing Incoming R1 Packets (same as 7401) 2332 6.7. Processing Incoming I2 Packets 2333 3. (same as 7401) 2334 7. (same as 7401) 2335 11. (same as 7401) 2337 6.8. Processing Incoming R2 Packets 2338 5. (same as 7401) 2340 6.9. Processing Incoming NOTIFY Packets 2341 1st para (same as 7401) 2343 6.11. Handling State Loss (same as 7401) 2345 7. HIP Policies (1st and 3rd same as 7401) 2347 Many of the other 11 SHOULDS are due to the nature of constrained 2348 devices and in most cases the text points this out: 2350 In Section 4.1.1, this is clearly adjusting for how the puzzle could 2351 actually be an attack against a constrained device. Same situation 2352 in Section 5.3.2. 2354 Section 6, clearly states that: 2356 it should be noted that many of the packet processing rules are 2357 denoted here with "SHOULD" but may be updated to "MUST" when further 2358 implementation experience provides better guidance. 2360 thus the SHOULD here is informative of future guidance. 2362 The SHOULD in Section 6.3, clearly reflects new work with the new 2363 Sponge Function KDFs: 2365 The keys derived for the Pair-wise Key SA are not used during the HIP 2366 DEX handshake. Instead, these keys are made available as payload 2367 protection keys (e.g., for IPsec). Some payload protection 2368 mechanisms have their own Key Derivation Function, and if so this 2369 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 2370 be used to derive the keys of the Pair-wise Key SA based on the 2371 concatenation of the random values that are contained in the 2372 exchanged ENCRYPTED_KEY parameters. 2374 In Section 6.5, the reason why this is a SHOULD should be clear to 2375 any implementer. That is the HIT Suite list in I1 is a desire on 2376 what suite to use. The Responder may have 'different ideas' about 2377 the Suite to use (like what it supports). Thus it is best that the 2378 Responder selects a DEX HIT, but there are good reasons, in an 2379 implementation not to do so. The implementer should know this and 2380 will deal with it appropriately. 2382 The SHOULDS in Section 6.7 and Section 6.9 are there for 2383 considerations for constrained systems. Some constrained systems 2384 need this approach, others may not. 2386 The 2nd SHOULD in Section 7 follows the same as above. ACLs and 2387 constrained systems tend to go together. 2389 Similarly in Section 8 the SHOULD is again is highlighting 2390 constrained system processing considerations. 2392 Authors' Addresses 2394 Robert Moskowitz (editor) 2395 HTT Consulting 2396 Oak Park, MI 2397 USA 2399 EMail: rgm@htt-consult.com 2401 Rene Hummen 2402 Hirschmann Automation and Control 2403 Stuttgarter Strasse 45-51 2404 Neckartenzlingen 72654 2405 Germany 2407 EMail: rene.hummen@belden.com 2409 Miika Komu 2410 Ericsson Research, Finland 2411 Hirsalantie 11 2412 Jorvas 02420 2413 Finland 2415 EMail: miika.komu@ericsson.com