idnits 2.17.1 draft-ietf-hip-dex-14.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 (March 9, 2020) is 1509 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: September 10, 2020 Hirschmann Automation and Control 6 M. Komu 7 Ericsson 8 March 9, 2020 10 HIP Diet EXchange (DEX) 11 draft-ietf-hip-dex-14 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. Unlike HIPv2, HIP DEX does not support Perfect 26 Forward Secrecy (PFS), and MUST only be used on devices where PFS is 27 prohibitively expensive. In addition, HIP DEX can also be used as a 28 keying mechanism for security primitives at the MAC layer, e.g., for 29 IEEE 802.15.4 networks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 67 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 68 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 69 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7 70 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7 71 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 74 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 75 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10 76 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11 77 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11 79 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 80 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14 81 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18 82 4.1.4. User Data Considerations . . . . . . . . . . . . . . 19 83 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 84 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19 85 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19 86 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20 87 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 20 88 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 21 89 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 21 90 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 22 91 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 23 92 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 24 94 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 25 95 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 27 96 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 28 97 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 29 98 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 30 99 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 30 100 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 30 101 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 30 102 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32 103 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35 104 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35 105 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36 106 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39 107 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42 108 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43 109 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44 110 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44 111 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44 112 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 114 9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 47 115 9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 47 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 117 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 118 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 119 12.1. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49 120 12.2. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 49 121 12.3. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 49 122 12.4. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 49 123 12.5. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 49 124 12.6. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50 125 12.7. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50 126 12.8. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 50 127 12.9. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 50 128 12.10. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 50 129 12.11. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 50 130 12.12. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51 131 12.13. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51 132 12.14. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51 133 12.15. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 51 134 12.16. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52 135 12.17. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52 136 12.18. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 52 137 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 138 13.1. Normative References . . . . . . . . . . . . . . . . . . 53 139 13.2. Informative References . . . . . . . . . . . . . . . . . 54 140 Appendix A. Password-based two-factor authentication during the 141 HIP DEX handshake . . . . . . . . . . . . . . . . . 56 142 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 56 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 145 1. Introduction 147 This document specifies the Host Identity Protocol Diet EXchange (HIP 148 DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity 149 Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol 150 semantics as well as the general packet structure of HIPv2. Hence, 151 it is recommended that [RFC7401] is well-understood before reading 152 this document. 154 The main differences between HIP BEX and HIP DEX are: 156 1. HIP DEX uses a different set of cryptographic primitives compared 157 to HIP BEX with the goal to reduce the protocol overhead: 159 * Peer authentication and key agreement in HIP DEX are based on 160 static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This 161 replaces the use of public-key signatures and ephemeral 162 Diffie-Hellman key pairs in HIPv2. 164 * HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC 165 as its MACing function. In contrast, HIPv2 currently supports 166 AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC- 167 SHA-384 for MACing. 169 * HIP DEX defines a simple fold function to efficiently generate 170 HITs, whereas the HIT generation of HIPv2 is based on SHA-1, 171 SHA-256, or SHA-384. 173 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of 174 HIPv2 due to the removal of the ephemeral Diffie-Hellman key 175 agreement. As this weakens the security properties of HIP DEX, 176 it MUST be used only with constrained devices where this is 177 prohibitively expensive as further explained in Section 1.2. 179 3. HIP DEX forfeits the use of digital signatures with the removal 180 of a hash function. Peer authentication with HIP DEX, therefore, 181 is based on the use of the ECDH derived key in the HIP_MAC 182 parameter. 184 4. With HIP DEX, the ECDH derived key is only used to protect HIP 185 packets. Separate session key(s) are used to protect the 186 transmission of upper layer protocol data. These session key(s) 187 are established via a new secret exchange during the handshake. 189 5. HIP DEX introduced a new, optional retransmission strategy that 190 is specifically designed to handle potentially extensive 191 processing times of the employed cryptographic operations on 192 computationally constrained devices. 194 By eliminating the need for public-key signatures and the ephemeral 195 DH key agreement, HIP DEX reduces the computational, energy, 196 transmission, and memory requirements for public-key cryptography 197 (see [LN08]) in the HIPv2 protocol design. This makes HIP DEX 198 especially suitable for constrained devices as defined in [RFC7228]. 200 This document focuses on the protocol specifications related to 201 differences between HIP BEX and HIP DEX. Where differences are not 202 called out explicitly, the protocol specification of HIP DEX is the 203 same as defined in [RFC7401]. 205 1.1. The HIP Diet EXchange (DEX) 207 The HIP Diet EXchange is a two-party cryptographic protocol used to 208 establish a secure communication context between hosts. The first 209 party is called the Initiator and the second party the Responder. 210 The four-packet exchange helps to make HIP DEX Denial of Service 211 (DoS) resilient. The Initiator and the Responder exchange their 212 static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2 213 handshake packet. The parties then authenticate each other in the I2 214 and R2 handshake packet based on the ECDH-derived keying material. 215 The Initiator and the Responder additionally transmit keying material 216 for the session key in these last two handshake packets (I2 and R2). 217 This is to prevent overuse of the static ECDH-derived keying 218 material. Moreover, the Responder starts a puzzle exchange in the R1 219 packet and the Initiator completes this exchange in the I2 packet 220 before the Responder performs computationally expensive operations or 221 stores any state from the exchange. Given this handshake structure, 222 HIP DEX operationally is very similar to HIP BEX. Moreover, the 223 employed model is also fairly equivalent to 802.11-2007 224 [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but 225 handled in a single exchange. 227 HIP DEX does not have the option to encrypt the Host Identity of the 228 Initiator in the I2 packet. The Responder's Host Identity also is 229 not protected. Thus, contrary to HIPv2, HIP DEX does not provide for 230 end-point anonymity and any signaling (i.e., HOST_ID parameter 231 contained with an ENCRYPTED parameter) that indicates such anonymity 232 should be ignored. 234 As in [RFC7401], data packets start to flow after the R2 packet. The 235 I2 and R2 packets may carry a data payload in the future. The 236 details of this may be defined later. 238 An existing HIP association can be updated with the update mechanism 239 defined in [RFC7401]. Likewise, the association can be torn down 240 with the defined closing mechanism for HIPv2 if it is no longer 241 needed. In doing so, HIP DEX does so even in the absence of the 242 HIP_SIGNATURE that is used in standard HIPv2. 244 Finally, HIP DEX is designed as an end-to-end authentication and key 245 establishment protocol. As such, it can be used in combination with 246 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 247 end-to-end security protocols. In addition, HIP DEX can also be used 248 as a keying mechanism for security primitives at the MAC layer, e.g., 249 for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth 250 mentioning that the HIP DEX base protocol does not cover all the 251 fine-grained policy control found in Internet Key Exchange Version 2 252 (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway 253 policies. Thus, HIP DEX is not a replacement for IKEv2. 255 1.2. Applicability 257 HIP DEX achieves its lightweight nature in large part due to the 258 intentional removal of Forward Secrecy (FS) from the key exchange. 259 Current mechanisms to achieve FS use an authenticated ephemeral 260 Diffie-Hellman exchange (e.g., SIGMA or PAKE). HIP DEX targets usage 261 on devices where even the most lightweight ECDH exchange is 262 prohibitively expensive for recurring (ephemeral) use. For example, 263 experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has 264 shown that EC25519 keypair generation exceeds 10 seconds and consumes 265 significant energy (i.e., battery resources). Even the ECDH 266 multiplication for the HIP DEX static-static key exchange takes 8-9 267 seconds, again with measurable energy consumption. This resource 268 consumption is tolerable as a one-time event during provisioning, but 269 would render the protocol unsuitable for use on these devices if it 270 was required to be a recurring part of the protocol. For devices 271 constrained in this manner, a FS-enabled protocol will likely provide 272 little gain. The resulting "FS" key, likely produced during device 273 provisioning, would typically end up being used for the remainder of 274 the device's lifetime. 276 With such a usage pattern, the inherent benefit of ephemeral keys is 277 not realized. The security properties of such usage are very similar 278 to those of using a statically provisioned symmetric pre-shared key, 279 in that there remains a single PSK in static storage that is 280 susceptible to exfiltration/compromise, and compromise of that key in 281 effect compromises the entire protocol for that node. HIP DEX 282 achieves marginally better security properties by computing the 283 effective long-term PSK from a DH exchange, so that the provisioning 284 service is not required to be part of the risk surface due to also 285 possessing the PSK. 287 Due to the substantially reduced security guarantees of HIP DEX 288 compared to HIP BEX, HIP DEX MUST only be used when at least one of 289 the two endpoints is a class 0 or 1 constrained device defined in 290 Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both 291 endpoints are class 2 devices or unconstrained. 293 1.3. Memo Structure 295 The rest of this memo is structured as follows. Section 2 defines 296 the central keywords, notation, and terms used throughout this 297 document. Section 3 defines the structure of the Host Identity and 298 its various representations. Section 4 gives an overview of the HIP 299 Diet EXchange protocol. Sections 5 and 6 define the detailed packet 300 formats and rules for packet processing. Finally, Sections 7, 8, 9, 301 and 10 discuss policy, interoperability between HIPv2 vs DEX, 302 security, and IANA considerations, respectively. Appendix A defines 303 a two factor authentication scheme and Appendix B highlights some 304 discussions with the IESG. 306 2. Terms, Notation and Definitions 308 2.1. Requirements Terminology 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 312 "OPTIONAL" in this document are to be interpreted as described in BCP 313 14 [RFC2119] [RFC8174] when, and only when, they appear in all 314 capitals, as shown here. 316 2.2. Notation 318 [x] indicates that x is optional. 320 {x} indicates that x is encrypted. 322 X(y) indicates that y is a parameter of X. 324 i indicates that x exists i times. 326 --> signifies "Initiator to Responder" communication (requests). 328 <-- signifies "Responder to Initiator" communication (replies). 330 | signifies concatenation of information - e.g., X | Y is the 331 concatenation of X and Y. 333 FOLD (X, K) denotes the partitioning of X into n K-bit segments and 334 the iterative folding of these segments via XOR. I.e., X = x_1, 335 x_2, ..., x_n, where x_i is of length K and the last segment x_n 336 is padded to length K by appending 0 bits. FOLD then is computed 337 as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 339 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 340 the MAC function M on the input x. 342 sort (HIT-I | HIT-R) is defined as the network byte order 343 concatenation of the two HITs, with the smaller HIT preceding the 344 larger HIT, resulting from the numeric comparison of the two HITs 345 interpreted as positive (unsigned) 128-bit integers in network 346 byte order. 348 2.3. Definitions 350 CKDF: CMAC-based Key Derivation Function. 352 CMAC: The Cipher-based Message Authentication Code with the 128-bit 353 Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. 355 HIP association: The shared state between two peers after completion 356 of the HIP DEX handshake. 358 HIP DEX (Diet EXchange): The ECDH-based HIP handshake for 359 establishing a new HIP association. 361 HIT Suite: A HIT Suite groups all algorithms that are required to 362 generate and use an HI and its HIT. In particular for HIP DEX, 363 these algorithms are: 1) ECDH and 2) FOLD. 365 HI (Host Identity): The static ECDH public key that represents the 366 identity of the host. In HIP DEX, a host proves ownership of the 367 private key belonging to its HI by creating a HIP_MAC with the 368 derived ECDH key (see Section 3). 370 HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It 371 is generated by folding the HI (see Section 3). 373 Initiator: The host that initiates the HIP DEX handshake. This role 374 is typically forgotten once the handshake is completed. 376 KEYMAT: Keying material. That is, the bit string(s) used as 377 cryptographic keys. 379 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 380 natural output length of RHASH in bits. 382 Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE 383 parameter (see section 5.2.4 in [RFC7401]. It is also referred to 384 as "random value #I" in this document. 386 OGA (Orchid Generation Algorithm): Hash function used in generating 387 the ORCHID. 389 ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6 390 addresses intended to be used as endpoint identifiers at 391 applications and Application Programming Interfaces (APIs) and not 392 as identifiers for network location at the IP layer. 394 Puzzle difficulty K: The Initiator has to compute a solution for the 395 puzzle. The level of computational difficulty is denoted by the 396 #K field in the puzzle parameter (see section 5.2.4 in [RFC7401]. 398 Responder: The host that responds to the Initiator in the HIP DEX 399 handshake. This role is typically forgotten once the handshake is 400 completed. 402 RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is 403 redefined as CMAC. Still, note that CMAC is a message 404 authentication code (MAC) and not a cryptographic hash function. 405 Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where 406 RHASH is used. Moreover, RHASH has different security properties 407 in HIP DEX and is not used for HIT generation. 409 3. Host Identity (HI) and its Structure 411 In this section, the properties of the Host Identity and Host 412 Identity Tag are discussed, and the exact format for them is defined. 413 In HIP, the public key of an asymmetric key pair is used as the Host 414 Identity (HI). Correspondingly, the host itself is defined as the 415 entity that holds the private key of the key pair. See the HIP 416 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 417 details on the difference between an identity and the corresponding 418 identifier. 420 HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH) 421 [RFC6090] key exchange for generating the HI as defined in 422 Section 5.2.3. No alternative algorithms are defined at this time. 424 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 425 in the handshake packets to represent the HI. The DEX Host Identity 426 Tag (HIT) is different from the BEX HIT in two ways: 428 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). 430 o The DEX HIT is not generated via a cryptographic hash. Rather, it 431 is a compression of the HI. 433 Due to the latter property, an attacker may be able to find a 434 collision with a HIT that is in use. Hence, policy decisions such as 435 access control MUST NOT be based solely on the HIT. Instead, the HI 436 of a host SHOULD be considered. 438 Carrying HIs or HITs in the header of user data packets would 439 increase the overhead of packets. Thus, it is not expected that 440 these parameters are carried in every packet, but other methods are 441 used to map the data packets to the corresponding HIs. In some 442 cases, this allows use of HIP DEX without any additional headers in 443 the user data packets. For example, if ESP is used to protect data 444 traffic, the Security Parameter Index (SPI) carried in the ESP header 445 can be used to map the encrypted data packet to the correct HIP DEX 446 association. When other user data packet formats are used, the 447 corresponding extensions need to define a replacement for the 448 ESP_TRANSFORM [RFC7402] parameter along with associated semantics, 449 but this procedure is outside the scope of this document. 451 3.1. Host Identity Tag (HIT) 453 With HIP DEX, the HIT is a 128-bit value - a compression of the HI 454 prepended with a specific prefix. There are two advantages of using 455 a hashed encoding over the actual variable-sized public key in 456 protocols. First, the fixed length of the HIT keeps packet sizes 457 manageable and eases protocol coding. Second, it presents a 458 consistent format for the protocol, independent of the underlying 459 identity technology in use. 461 The structure of the HIT is based on RFC 7343 [RFC7343], called 462 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 463 consists of three parts: first, an IANA assigned prefix to 464 distinguish it from other IPv6 addresses. Second, a four-bit 465 encoding of the algorithms that were used for generating the HI and 466 the compressed representation of the HI. Third, a 96-bit hashed 467 representation of the HI. In contrast to HIPv2, HIP DEX employs HITs 468 that are NOT generated by means of a cryptographic hash. Instead, 469 the HI is compressed to 96 bits as defined in the following section. 471 3.2. Generating a HIT from an HI 473 The HIT does not follow the exact semantics of an ORCHID as there is 474 no hash function in HIP DEX. Still, its structure is strongly 475 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 476 is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used 477 for the four bits of the Orchid Generation Algorithm (OGA) field in 478 the ORCHID. The hash representation in an ORCHID is replaced with 479 FOLD(HI,96). 481 3.2.1. Why Introduce FOLD 483 HIP DEX, by design lacks a cryptographic hash function. The 484 generation of the HIT is one of the few places in the protocol where 485 this presents a challenge. CMAC was first considered for this 486 purpose, but to use CMAC for HIT generation would require using a 487 static key, either ZERO or some published value. NIST does not 488 consider CMAC an approved cryptograhic hash as: 490 It is straightforward to demonstrate that CMAC is not collision- 491 resistant for any choice of a published key. 493 Since collision-resistance is not possible with the tools at hand, 494 any reasonable function (e.g. FOLD) that takes the full value of the 495 HI into generating the HIT can be used, provided that collision 496 detection is part of the HIP-DEX deployment design. This is achieved 497 here through either an ACL or some other lookup process that 498 externally binds the HIT and HI. 500 4. Protocol Overview 502 This section gives a simplified overview of the HIP DEX protocol 503 operation and does not contain all the details of the packet formats 504 or the packet processing steps. Section 5 and Section 6 describe 505 these aspects in more detail and are normative in case of any 506 conflicts with this section. Importantly, the information given in 507 this section focuses on the differences between the HIPv2 and HIP DEX 508 protocol specifications. 510 4.1. Creating a HIP Association 512 By definition, the system initiating a HIP Diet EXchange is the 513 Initiator, and the peer is the Responder. This distinction is 514 typically forgotten once the handshake completes, and either party 515 can become the Initiator in future communications. 517 The HIP Diet EXchange serves to manage the establishment of state 518 between an Initiator and a Responder. The first packet, I1, 519 initiates the exchange, and the last three packets, R1, I2, and R2, 520 constitute an authenticated Diffie-Hellman [DH76] key exchange for 521 the Master Key SA generation. This Master Key SA is used by the 522 Initiator and the Responder to wrap secret keying material in the I2 523 and R2 packets. Based on the exchanged keying material, the peers 524 then derive a Pair-wise Key SA if cryptographic keys are needed, 525 e.g., for ESP-based protection of user data. 527 The Initiator first sends a trigger packet, I1, to the Responder. 528 This packet contains the HIT of the Initiator and the HIT of the 529 Responder, if it is known. Moreover, the I1 packet initializes the 530 negotiation of the Diffie-Hellman group that is used for generating 531 the Master Key SA. Therefore, the I1 packet contains a list of 532 Diffie-Hellman Group IDs supported by the Initiator. 534 The second packet, R1, starts the actual authenticated Diffie-Hellman 535 key exchange. It contains a puzzle - a cryptographic challenge that 536 the Initiator must solve before continuing the exchange. The level 537 of difficulty of the puzzle can be adjusted based on level of 538 knowledge of the Initiator, current load, or other factors. In 539 addition, the R1 contains the Responder's Diffie-Hellman parameter 540 and lists of cryptographic algorithms supported by the Responder. 541 Based on these lists, the Initiator can continue, abort, or restart 542 the handshake with a different selection of cryptographic algorithms. 544 In the I2 packet, the Initiator MUST display the solution to the 545 received puzzle. Without a correct solution, the I2 packet is 546 discarded. The I2 also contains a key wrap parameter that carries 547 secret keying material of the Initiator. This keying material is 548 only half of the final session key. The packet is authenticated by 549 the sender (Initiator) via a MAC. 551 The R2 packet acknowledges the receipt of the I2 packet and completes 552 the handshake. The R2 contains a key wrap parameter that carries the 553 rest of the keying material of the Responder. The packet is 554 authenticated by the sender (Responder) via a MAC. 556 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 557 and "ENC(DH,y)" refer to the random values x and y that are wrapped 558 based on the Master Key SA (indicated by ENC and DH). Note that x 559 and y each constitute half of the final session key material. The 560 packets also contain other parameters that are not shown in this 561 figure. 563 Initiator Responder 565 I1: 566 ---------------------------------> 567 remain stateless 568 R1: puzzle, HI 569 <-------------------------------- 570 solve puzzle 571 perform ECDH 572 encrypt x 573 I2: solution, HI, ENC(DH,x), mac 574 ---------------------------------> 575 check puzzle 576 perform ECDH 577 check MAC 578 decrypt x 579 encrypt y 580 R2: ENC(DH,y), mac 581 <--------------------------------- 582 check MAC 583 decrypt y 585 Figure 1: High-level overview of the HIP Diet EXchange 587 4.1.1. HIP Puzzle Mechanism 589 The purpose of the HIP puzzle mechanism is to protect the Responder 590 from a number of denial-of-service threats. It allows the Responder 591 to delay state creation until receiving the I2 packet. Furthermore, 592 the puzzle allows the Responder to use a fairly cheap calculation to 593 check that the Initiator is "sincere" in the sense that it has 594 churned enough CPU cycles in solving the puzzle. 596 The puzzle mechanism enables a Responder to immediately reject an I2 597 packet if it does not contain a valid puzzle solution. To verify the 598 puzzle solution, the Responder only has to compute a single CMAC 599 operation. After a successful puzzle verification, the Responder can 600 securely create session-specific state and perform CPU-intensive 601 operations such as a Diffie-Hellman key generation. By varying the 602 difficulty of the puzzle, the Responder can frustrate CPU or memory 603 targeted DoS attacks. Under normal network conditions, the puzzle 604 difficulty SHOULD be zero, thus effectively reverting the puzzle 605 mechanism to a cookie-based DoS protection mechanism. Without 606 setting the puzzle difficulty to zero under normal network 607 conditions, potentially scarce computation resources at the Initiator 608 would be churned unnecessarily. 610 Conceptually, the puzzle mechanism in HIP DEX is the same as in 611 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 612 [RFC7401] for more detailed information about the employed mechanism. 613 Notably, the only differences between the puzzle mechanism in HIP DEX 614 and HIPv2 are that HIP DEX does not employ pre-computation of R1 615 packets and uses CMAC instead of a hash function for solving and 616 verifying a puzzle. The implications of these changes on the puzzle 617 implementation are discussed in Section 6.1. 619 4.1.2. HIP State Machine 621 The HIP DEX state machine has the same states as the HIPv2 state 622 machine (see Section 4.4. in [RFC7401]). However, HIP DEX features a 623 retransmission strategy with an optional reception acknowledgement 624 for the I2 packet. The goal of this additional acknowledgement is to 625 reduce premature I2 retransmissions in case of devices with low 626 computation resources [HWZ13]. As a result, there are minor changes 627 regarding the transitions in the HIP DEX state machine. The 628 following section documents these differences compared to HIPv2. 630 4.1.2.1. HIP DEX Retransmission Mechanism 632 For the retransmission of I1 and I2 packets, the Initiator adopts the 633 retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). 634 This strategy is based on a timeout that is set to a value larger 635 than the worst-case anticipated round-trip time (RTT). For each 636 received I1 or I2 packet, the Responder sends an R1 or R2 packet, 637 respectively. This design trait enables the Responder to remain 638 stateless until the reception and successful processing of the I2 639 packet. The Initiator stops retransmitting I1 or I2 packets after 640 the reception of the corresponding R1 or R2. If the Initiator did 641 not receive an R1 packet after I1_RETRIES_MAX tries, it stops I1 642 retransmissions. Likewise, it stops retransmitting the I2 packet 643 after I2_RETRIES_MAX unsuccessful tries. 645 For repeatedly received I2 packets, the Responder SHOULD NOT perform 646 operations related to the Diffie-Hellman key exchange or the keying 647 material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD 648 re-use the previously established state to re-create the 649 corresponding R2 packet in order to prevent unnecessary computation 650 overhead. 652 The potentially high processing time of an I2 packet at a (resource- 653 constrained) Responder may cause premature retransmissions if the 654 time required for I2 transmission and processing exceeds the RTT- 655 based retransmission timeout. Thus, the Initiator should also take 656 the processing time of the I2 packet at the Responder into account 657 for retransmission purposes. To this end, the Responder MAY notify 658 the Initiator about the anticipated delay once the puzzle solution 659 was successfully verified and if the remaining I2 packet processing 660 incurs a high processing delay. The Responder MAY therefore send a 661 NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator 662 before the Responder commences the ECDH operation. The NOTIFY packet 663 serves as an acknowledgement for the I2 packet and consists of a 664 NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 665 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 666 contains the anticipated remaining processing time for the I2 packet 667 in milliseconds as two-octet Notification Data. This processing time 668 can, e.g., be estimated by measuring the computation time of the ECDH 669 key derivation operation during the Responder start-up procedure. 670 After the I2 processing has finished, the Responder sends the regular 671 R2 packet. 673 When the Initiator receives the NOTIFY packet, it sets the I2 674 retransmission timeout to the I2 processing time indicated in the 675 NOTIFICATION parameter plus half the RTT-based timeout value. In 676 doing so, the Initiator MUST NOT set the retransmission timeout to a 677 higher value than allowed by a local policy. This is to prevent 678 unauthenticated NOTIFY packets from maliciously delaying the 679 handshake beyond a well-defined upper bound in case of a lost R2 680 packet. At the same time, this extended retransmission timeout 681 enables the Initiator to defer I2 retransmissions until the point in 682 time when the Responder should have completed its I2 packet 683 processing and the network should have delivered the R2 packet 684 according to the employed worst-case estimates. 686 4.1.2.2. HIP State Processes 688 HIP DEX clarifies or introduces the following new transitions. 690 System behavior in state I2-SENT, Table 1. 692 +---------------------+---------------------------------------------+ 693 | Trigger | Action | 694 +---------------------+---------------------------------------------+ 695 | Receive NOTIFY, | Set I2 retransmission timer to value in | 696 | process | I2_ACKNOWLEDGEMENT Notification Data plus | 697 | | 1/2 RTT-based timeout value and stay at | 698 | | I2-SENT | 699 | | | 700 | | | 701 | | | 702 | Timeout | Increment trial counter | 703 | | | 704 | | | 705 | | | 706 | | If counter is less than I2_RETRIES_MAX, | 707 | | send I2, reset timer to RTT-based timeout, | 708 | | and stay at I2-SENT | 709 | | | 710 | | | 711 | | | 712 | | If counter is greater than I2_RETRIES_MAX, | 713 | | go to E-FAILED | 714 +---------------------+---------------------------------------------+ 716 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 718 4.1.2.3. Simplified HIP State Diagram 720 The following diagram shows the major state transitions. Transitions 721 based on received packets implicitly assume that the packets are 722 successfully authenticated or processed. 724 +--+ +----------------------------+ 725 recv I1, send R1 | | | | 726 | v v | 727 +--------------+ recv I2, send R2 | 728 +----------------| UNASSOCIATED |----------------+ | 729 datagram | +--+ +--------------+ | | 730 to send, | | | Alg. not supported, | | 731 send I1 | | | send I1 | | 732 . v | v | | 733 . +---------+ recv I2, send R2 | | 734 +---->| I1-SENT |--------------------------------------+ | | 735 | +---------+ +----------------------+ | | | 736 | | recv R1, | recv I2, send R2 | | | | 737 | v send I2 | v v v | 738 | +---------+----------+ +---------+ | 739 | +--->| I2-SENT |<-------------+ +------------| R2-SENT |<---+ | 740 | | +---------+ recv NOTIFY, | | +---------+ | | 741 | | | | | reset timer | | data or| | | 742 | |recv R1, | | +--------------+ | EC timeout| | | 743 | |send I2 +-|--------------------+ | receive I2,| | 744 | | | | +-------------+ | send R2| | 745 | | | +-------->| ESTABLISHED |<---------+ | | 746 | | | recv R2 +-------------+ | | 747 | | | | | | receive I2, send R2 | | 748 | | +------------+ | +-------------------------------+ | 749 | | | +-----------+ | | 750 | | | no packet sent/received| +---+ | | 751 | | | for UAL min, send CLOSE| | |timeout | | 752 | | | v v |(UAL+MSL) | | 753 | | | +---------+ |retransmit | | 754 +--|----------|------------------------| CLOSING |-+CLOSE | | 755 | | +---------+ | | 756 | | | | | | | | 757 +----------|-------------------------+ | | +----------------+ | 758 | | +-----------+ +------------------|--+ 759 | | |recv CLOSE, recv CLOSE_ACK | | 760 | +-------------+ |send CLOSE_ACK or timeout | | 761 | recv CLOSE, | | (UAL+MSL) | | 762 | send CLOSE_ACK v v | | 763 | +--------+ receive I2, send R2 | | 764 +---------------------| CLOSED |------------------------------+ | 765 +--------+ | 766 ^ | | | 767 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 768 +-+ +------------------------------------+ 770 4.1.3. HIP DEX Security Associations 772 HIP DEX establishes two Security Associations (SA), one for the 773 Diffie-Hellman derived key, or Master Key, and one for the session 774 key, or Pair-wise Key. 776 4.1.3.1. Master Key SA 778 The Master Key SA is used to authenticate HIP packets and to encrypt 779 selected HIP parameters in the HIP DEX packet exchanges. Since only 780 a small amount of data is protected by this SA, it can be long-lived 781 with no need for rekeying. At the latest, the system MUST initiate 782 rekeying when its incoming ESP sequence counter is going to overflow, 783 and the system MUST NOT replace its keying material until the 784 rekeying packet exchange successfully completes as described in 785 Section 6.8 in [RFC7402]. 787 The Master Key SA contains the following elements: 789 o Source HIT 791 o Destination HIT 793 o HIP_Encrypt Key 795 o HIP_MAC Key 797 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 798 Hellman derived key as described in Section 6.3. Their length is 799 determined by the HIP_CIPHER. 801 4.1.3.2. Pair-wise Key SA 803 The Pair-wise Key SA is used to authenticate and to encrypt user 804 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 805 The Pair-wise Key SA elements are defined by the data transform 806 (e.g., ESP_TRANSFORM [RFC7402]). 808 The keys for the Pair-wise Key SA are derived based on the wrapped 809 keying material exchanged in the ENCRYPTED_KEY parameter (see 810 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 811 keying material of the two peers is concatenated. This concatenation 812 forms the input to a Key Derivation Function (KDF). If the data 813 transform does not specify its own KDF, the key derivation function 814 defined in Section 6.3 is used. Even though the concatenated input 815 is randomly distributed, a KDF Extract phase may be needed to get the 816 proper length for the input to the KDF Expand phase. 818 4.1.4. User Data Considerations 820 The User Data Considerations in Section 4.5. of [RFC7401] also apply 821 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 822 Loss of state due to system reboot may be a critical performance 823 issue for resource-constrained devices. Thus, implementors MAY 824 choose to use non-volatile, secure storage for HIP states in order 825 for them to survive a system reboot as discussed in Section 6.11. 826 Using non-volatile storage will limit state loss during reboots to 827 only those situations with an SA timeout. 829 5. Packet Formats 831 5.1. Payload Format 833 HIP DEX employs the same fixed HIP header and payload structure as 834 HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also 835 apply to HIP DEX. 837 5.2. HIP Parameters 839 The HIP parameters carry information that is necessary for 840 establishing and maintaining a HIP association. For example, the 841 peer's public keys as well as the signaling for negotiating ciphers 842 and payload handling are encapsulated in HIP parameters. Additional 843 information, meaningful for end-hosts or middleboxes, may also be 844 included in HIP parameters. The specification of the HIP parameters 845 and their mapping to HIP packets and packet types is flexible to 846 allow HIP extensions to define new parameters and new protocol 847 behavior. 849 In HIP packets, HIP parameters are ordered according to their numeric 850 type number and encoded in TLV format. 852 HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of 853 [RFC7401] where possible. Still, HIP DEX further restricts and/or 854 extends the following existing parameter types: 856 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 858 o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. 860 o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. 862 o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, 863 SOLUTION, and HIP_MAC parameters (see Section 6.1 and 864 Section 6.2). 866 In addition, HIP DEX introduces the following new parameter: 868 +------------------+--------------+----------+----------------------+ 869 | TLV | Type | Length | Data | 870 +------------------+--------------+----------+----------------------+ 871 | ENCRYPTED_KEY | TBD1 | variable | Encrypted container | 872 | | (suggested | | for the session key | 873 | | value 643) | | exchange | 874 | | | | | 875 | I_NONCE | TBD6 | variable | Nonce from Initator | 876 | | (suggested | | for Master Key | 877 | | value 644) | | | 878 +------------------+--------------+----------+----------------------+ 880 5.2.1. DH_GROUP_LIST 882 The DH_GROUP_LIST parameter contains the list of supported DH Group 883 IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With 884 HIP DEX, the DH Group IDs are restricted to: 886 Group KDF Value 888 NIST P-256 [RFC5903] CKDF 7 889 NIST P-384 [RFC5903] CKDF 8 890 NIST P-521 [RFC5903] CKDF 9 891 SECP160R1 [SECG] CKDF 10 892 Curve25519 [RFC7748] CKDF 12 893 Curve448 [RFC7748] CKDF 13 895 The ECDH groups with values 7 - 9 are defined in [RFC5903] and 896 [RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of 897 [RFC7401]. These curves, when used with HIP MUST have a co-factor of 898 1. 900 The ECDH groups with values 12 and 13 are defined in [RFC7748]. 901 These curves have cofactors of 8 and 4 (respectively). 903 5.2.2. HIP_CIPHER 905 The HIP_CIPHER parameter contains the list of supported cipher 906 algorithms to be used for encrypting the contents of the ENCRYPTED 907 and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 908 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited 909 to: 911 Suite ID Value 913 RESERVED 0 914 NULL-ENCRYPT 1 ([RFC2410]) 915 AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) 917 Mandatory implementation: AES-128-CTR. Implementors SHOULD support 918 NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT 919 offer or accept this value unless explicitly configured for testing/ 920 debugging of HIP. 922 5.2.3. HOST_ID 924 The HOST_ID parameter conveys the Host Identity (HI) along with 925 optional information about a host. The HOST_ID parameter is defined 926 in Section 5.2.9 of [RFC7401]. 928 HIP DEX uses the public portion of a host's static ECDH key-pair as 929 the HI. Correspondingly, HIP DEX limits the HI algorithms to the 930 following new profile: 932 Algorithm profiles Value 934 ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) 936 For hosts that implement ECDH as the algorithm, the following curves 937 are required: 939 Group Value 941 NIST P-256 1 [RFC5903] 942 NIST P-384 2 [RFC5903] 943 NIST P-521 3 [RFC5903] 944 SECP160R1 4 [SECG] 945 Curve25519 5 [RFC7748] 946 Curve448 6 [RFC7748] 948 HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 949 Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is 950 encoded in the "ECC curve" field of the HOST_ID parameter. The 951 supported DH Group IDs are defined in Section 5.2.1. 953 5.2.4. HIT_SUITE_LIST 955 The HIT_SUITE_LIST parameter contains a list of the supported HIT 956 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 957 Initiator can determine which source HIT Suite IDs are supported by 958 the Responder. The HIT_SUITE_LIST parameter is defined in 959 Section 5.2.10 of [RFC7401]. 961 The following new HIT Suite ID is defined for HIP DEX, and the 962 relationship between the four-bit ID value used in the OGA ID field 963 and the eight-bit encoding within the HIT_SUITE_LIST ID field is 964 clarified: 966 HIT Suite Four-bit ID Eight-bit encoding 968 ECDH/FOLD TBD2 (suggestion: 4) TBD3 (suggestion: 0x40) 970 Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field 971 allows the peers to distinguish a HIP DEX handshake from a HIPv2 972 handshake. The Responder MUST respond with a HIP DEX HIT suite ID 973 when the HIT of the Initiator is a HIP DEX HIT. 975 5.2.5. ENCRYPTED_KEY 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Type | Length | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 / Encrypted value / 983 / / 984 / +-------------------------------+ 985 / | Padding | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Type TBD1 (suggested value 643) 989 Length length in octets, excluding Type, Length, and 990 Padding 991 Encrypted The value is encrypted using an encryption algorithm 992 value as defined in the HIP_CIPHER parameter. 994 The ENCRYPTED_KEY parameter encapsulates a random value that is later 995 used in the session key creation process (see Section 6.3). This 996 random value MUST have a length of at least 64 bits. The puzzle 997 value #I and the puzzle solution #J (see Section 4.1.2 in [RFC7401]) 998 are used as the initialization vector (IV) for the encryption 999 process. To this end, the IV is computed as FOLD(I | J, 128). 1000 Moreover, a 16 bit counter value, which is initialized to zero on 1001 first use, is appended to the IV value in order to guarantee that a 1002 non-repeating nonce is fed to the encryption algorithm defined by the 1003 HIP_CIPHER. 1005 Once this encryption process is completed, the "encrypted value" data 1006 field is ready for inclusion in the Parameter. If necessary, 1007 additional Padding for 8-byte alignment is then added according to 1008 the rules of TLV Format in [RFC7401]. 1010 5.2.6. I_NONCE 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Type | Length | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 / Initiator Nonce / 1018 / / 1019 / +-------------------------------+ 1020 / | Padding | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Type TBD6 (suggested value 644) 1024 Length length in octets, excluding Type, Length, and 1025 Padding 1026 Initiator Nonce provided by the Initiator for use in the 1027 Nonce Master Key 1029 The I_NONCE parameter encapsulates a random value that is later used 1030 in the Master key creation process (see Section 6.3). This random 1031 value MUST have a length of 2 x RHASH_len. This parameter is sent to 1032 the Responder in I2 which echos it back to the Initiator in R2. 1034 If necessary, additional Padding for 8-byte alignment is added 1035 according to the rules of TLV Format in [RFC7401]. 1037 5.3. HIP Packets 1039 HIP DEX uses the same eight basic HIP packets as HIPv2 (see 1040 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake 1041 (I1, R1, I2, and R2), one is for updating an association (UPDATE), 1042 one is for sending notifications (NOTIFY), and two are for closing 1043 the association (CLOSE and CLOSE_ACK). There are some differences 1044 regarding the HIP parameters that are included in the handshake 1045 packets concerning HIP BEX and HIP DEX. This section covers these 1046 differences for the DEX packets. Packets not discussed here, follow 1047 the structure defined in [RFC7401]. 1049 An important difference between packets in HIP BEX and HIP DEX is 1050 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 1051 included in HIP DEX. Thus, the R1 packet is completely unprotected 1052 and can be spoofed. As a result, negotiation parameters contained in 1053 the R1 packet have to be re-included in later, protected packets in 1054 order to detect and prevent potential downgrading attacks. Moreover, 1055 the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not 1056 covered by a signature and purely rely on the HIP_MAC parameter for 1057 packet authentication. The processing of these packets is changed 1058 accordingly. 1060 In the future, an optional upper-layer payload MAY follow the HIP 1061 header. The Next Header field in the header indicates if there is 1062 additional data following the HIP header. 1064 5.3.1. I1 - the HIP Initiator Packet 1066 The HIP header values for the I1 packet: 1068 Header: 1069 Packet Type = 1 1070 SRC HIT = Initiator's HIT 1071 DST HIT = Responder's HIT, or NULL 1073 IP ( HIP ( DH_GROUP_LIST ) ) 1075 Valid control bits: none 1077 The I1 packet contains the fixed HIP header and the Initiator's 1078 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 1079 type as defined in Section 5.2.4. 1081 Regarding the Responder's HIT, the Initiator may receive this HIT 1082 either from a DNS lookup of the Responder's FQDN, from some other 1083 repository, or from a local table. The Responder's HIT also MUST be 1084 of a HIP DEX type. If the Initiator does not know the Responder's 1085 HIT, it may attempt to use opportunistic mode by using NULL (all 1086 zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for 1087 detailed information about the "HIP Opportunistic Mode". 1089 As the Initiator's and the Responder's HITs are compressions of the 1090 employed HIs, they determine the DH Group ID that must be used in 1091 order to successfully conclude the triggered handshake. HITs, 1092 however, only include the OGA ID identifying the HI algorithm. They 1093 do not include information about the specific group ID of the HI. To 1094 inform the Responder about its employed and its otherwise supported 1095 DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST 1096 parameter in the I1 packet. This parameter MUST include the DH group 1097 ID that corresponds to the currently employed Initiator HIT as the 1098 first list element. With HIP DEX, the DH_GROUP_LIST parameter MUST 1099 only include ECDH groups defined in Section 5.2.1. 1101 Since this packet is so easy to spoof even if it were protected, no 1102 attempt is made to add to its generation or processing cost. As a 1103 result, the DH_GROUP_LIST in the I1 packet is not protected. 1105 Implementations MUST be able to handle a storm of received I1 1106 packets, discarding those with common content that arrive within a 1107 small time delta. 1109 5.3.2. R1 - the HIP Responder Packet 1111 The HIP header values for the R1 packet: 1113 Header: 1114 Packet Type = 2 1115 SRC HIT = Responder's HIT 1116 DST HIT = Initiator's HIT 1118 IP ( HIP ( [ R1_COUNTER, ] 1119 PUZZLE, 1120 DH_GROUP_LIST, 1121 HIP_CIPHER, 1122 HOST_ID, 1123 HIT_SUITE_LIST, 1124 TRANSPORT_FORMAT_LIST, 1125 [ <, ECHO_REQUEST_UNSIGNED >i ]) 1127 Valid control bits: A 1129 If the Responder's HI is an anonymous one, the A control bit MUST be 1130 set. 1132 The Initiator's HIT MUST match the one received in the I1 packet if 1133 the R1 is a response to an I1. If the Responder has multiple HIs, 1134 the Responder's HIT MUST match the Initiator's request. If the 1135 Initiator used opportunistic mode, the Responder may select among its 1136 HIs as described below. See Section 4.1.8 of [RFC7401] for detailed 1137 information about the "HIP Opportunistic Mode". 1139 The R1 packet generation counter is used to determine the currently 1140 valid generation of puzzles. The value is increased periodically, 1141 and it is RECOMMENDED that it is increased at least as often as 1142 solutions to old puzzles are no longer accepted. 1144 The Puzzle contains a Random value #I and the puzzle difficulty K. 1145 The difficulty K indicates the number of lower-order bits, in the 1146 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 1147 SHOULD set K to zero by default and only increase the puzzle 1148 difficulty to protect against a DoS attack targeting the HIP DEX 1149 handshake. A puzzle difficulty of zero effectively turns the puzzle 1150 mechanism into a return-routability test and is strongly encouraged 1151 during normal operation in order to conserve energy resources as well 1152 as to prevent unnecessary handshake delay in case of a resource- 1153 constrained Initiator. Please also refer to Section 7 for further 1154 recommendations on choosing puzzle difficulty. 1156 The DH_GROUP_LIST parameter contains the Responder's order of 1157 preference based on the Responder's choice the ECDH key contained in 1158 the HOST_ID parameter (see below). This allows the Initiator to 1159 determine whether its own DH_GROUP_LIST in the I1 packet was 1160 manipulated by an attacker. There is a further risk that the 1161 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 1162 packet cannot be authenticated in HI DEX. Thus, this parameter is 1163 repeated in the R2 packet to allow for a final, cryptographically 1164 secured validation. 1166 The HIP_CIPHER contains the encryption algorithms supported by the 1167 Responder to protect the key exchange, in the order of preference. 1168 All implementations MUST support the AES-CTR [RFC3686]. 1170 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 1171 supported and preferred HIT Suites. It enables a Responder to notify 1172 the Initiator about other available HIT suites than the one used in 1173 the current handshake. Based on the received HIT_SUITE_LIST, the 1174 Initiator MAY decide to abort the current handshake and initiate a 1175 new handshake with a different mutually supported HIT suite. This 1176 mechanism can, e.g., be used to move from an initial HIP DEX 1177 handshake to a HIP BEX handshake for peers supporting both protocol 1178 variants. 1180 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 1181 and the Responder HIT in the I1 packet. Specifically, if the I1 1182 contains a Responder HIT, the Responder verifies that this HIT 1183 matches the required DH group based on the received DH_GROUP_LIST 1184 parameter included in the I1. In case of a positive result, the 1185 Responder selects the corresponding HOST_ID for inclusion in the R1 1186 packet. Likewise, if the Responder HIT in the I1 packet is NULL 1187 (i.e., during an opportunistic handshake), the Responder chooses its 1188 HOST_ID according to the Initiator's employed DH group as indicated 1189 in the received DH_GROUP_LIST parameter and sets the source HIT in 1190 the R1 packet accordingly. If the Responder however does not support 1191 the DH group required by the Initiator or if the Responder HIT in the 1192 I1 packet does not match the required DH group, the Responder selects 1193 the mutually preferred and supported DH group based on the 1194 DH_GROUP_LIST parameter in the I1 packet. The Responder then 1195 includes the corresponding ECDH key in the HOST_ID parameter. This 1196 parameter also indicates the selected DH group. Moreover, the 1197 Responder sets the source HIT in the R1 packet based on the 1198 destination HIT from the I1 packet. Based on the deviating DH group 1199 ID in the HOST_ID parameter, the Initiator then SHOULD abort the 1200 current handshake and initiate a new handshake with the mutually 1201 supported DH group as far as local policies (see Section 7) permit. 1203 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 1204 Responder's supported and preferred transport format types. The list 1205 allows the Initiator and the Responder to agree on a common type for 1206 payload protection. The different format types are DEFAULT, ESP and 1207 ESP-TCP as explained in Section 3.1 in [RFC6261]. 1209 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 1210 wants to receive unmodified in the corresponding response packet in 1211 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 1212 or more ECHO_REQUEST_UNSIGNED parameters. 1214 5.3.3. I2 - the Second HIP Initiator Packet 1216 The HIP header values for the I2 packet: 1218 Header: 1219 Type = 3 1220 SRC HIT = Initiator's HIT 1221 DST HIT = Responder's HIT 1223 IP ( HIP ( [R1_COUNTER,] 1224 SOLUTION, 1225 HIP_CIPHER, 1226 ENCRYPTED_KEY, 1227 HOST_ID, 1228 TRANSPORT_FORMAT_LIST, 1229 I_NONCE, 1230 HIP_MAC 1231 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1233 Valid control bits: A 1235 The HITs MUST match the ones used in the R1 packet. 1237 If the Initiator's HI is an anonymous one, the A control bit MUST be 1238 set. 1240 If present in the R1 packet, the Initiator MUST include an unmodified 1241 copy of the R1_COUNTER parameter into the I2 packet. 1243 The Solution contains the Random #I from the R1 packet and the 1244 computed #J value. The low-order #K bits of the RHASH(I | ... | J) 1245 MUST be zero. 1247 The HIP_CIPHER contains the single encryption transform selected by 1248 the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY 1249 parameters. The chosen cipher MUST correspond to one of the ciphers 1250 offered by the Responder in the R1. All implementations MUST support 1251 the AES-CTR transform [RFC3686]. 1253 The HOST_ID parameter contains the Initiator HI corresponding to the 1254 Initiator HIT. 1256 The ENCRYPTED_KEY parameter contains an Initiator generated random 1257 value that MUST be uniformly distributed. This random value is 1258 encrypted with the Master Key SA using the HIP_CIPHER encryption 1259 algorithm. 1261 The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque 1262 data copied from the corresponding echo request parameter(s). This 1263 parameter can also be used for two-factor password authentication as 1264 shown in Appendix A. 1266 The TRANSPORT_FORMAT_LIST parameter contains the single transport 1267 format type selected by the Initiator. The chosen type MUST 1268 correspond to one of the types offered by the Responder in the R1 1269 packet. The different format types are DEFAULT, ESP and ESP-TCP as 1270 explained in Section 3.1 in [RFC6261]. 1272 The I_NONCE parameter contains the nonce, supplied by the Initiator 1273 for the Master Key generation as shown in Section 6.3. This is 1274 echoed back to the Initiator in the R2 packet. 1276 The MAC is calculated over the whole HIP envelope, excluding any 1277 parameters after the HIP_MAC parameter as described in Section 6.2. 1278 The Responder MUST validate the HIP_MAC parameter. 1280 5.3.4. R2 - the Second HIP Responder Packet 1282 The HIP header values for the R2 packet: 1284 Header: 1285 Packet Type = 4 1286 SRC HIT = Responder's HIT 1287 DST HIT = Initiator's HIT 1289 IP ( HIP ( DH_GROUP_LIST, 1290 HIP_CIPHER, 1291 ENCRYPTED_KEY, 1292 HIT_SUITE_LIST, 1293 TRANSPORT_FORMAT_LIST, 1294 I_NONCE, 1295 HIP_MAC) 1297 Valid control bits: none 1299 The HITs used MUST match the ones used in the I2 packet. 1301 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1302 and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These 1303 parameters MUST be the same as included in the R1 packet. The 1304 parameter are re-included here because the R2 packet is MACed and 1305 thus cannot be altered by an attacker. For verification purposes, 1306 the Initiator re-evaluates the selected suites and compares the 1307 results against the chosen ones. If the re-evaluated suites do not 1308 match the chosen ones, the Initiator acts based on its local policy. 1310 The ENCRYPTED_KEY parameter contains an Responder generated random 1311 value that MUST be uniformly distributed. This random value is 1312 encrypted with the Master Key SA using the HIP_CIPHER encryption 1313 algorithm. 1315 The I_NONCE parameter contains the nonce, supplied by the Initiator 1316 for the Master Key generation as shown in Section 6.3. The Responder 1317 is echoing the value back to the Initiator to show it used the 1318 Initiator provided nonce. 1320 The MAC is calculated over the whole HIP envelope, excluding any 1321 parameters after the HIP_MAC, as described in Section 6.2. The 1322 Initiator MUST validate the HIP_MAC parameter. 1324 5.4. ICMP Messages 1326 When a HIP implementation detects a problem with an incoming packet, 1327 and it either cannot determine the identity of the sender of the 1328 packet or does not have any existing HIP association with the sender 1329 of the packet, it MAY respond with an ICMP packet. Any such reply 1330 MUST be rate-limited as described in [RFC4443]. In most cases, the 1331 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1332 ICMPv6) and Code of 0. The Pointer field pointing to the field that 1333 caused the ICMP message to be generated, for example to the first 8 1334 bytes of a UDP payload for "SPI is Unknown". The problem cases 1335 specified in Section 5.4. of [RFC7401] also apply to HIP DEX. 1337 6. Packet Processing 1339 Due to the adopted protocol semantics and the inherited general 1340 packet structure, the packet processing in HIP DEX only differs from 1341 HIPv2 in very few places. Here, we focus on these differences and 1342 refer to Section 6 in [RFC7401] otherwise. 1344 The processing of outgoing and incoming application data remains the 1345 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1347 It should be noted that many of the packet processing rules are 1348 denoted here with "SHOULD" but may be updated to "MUST" when further 1349 implementation experience provides better guidance. Please refer 1350 also to Appendix B for argumentation about the SHOULDs. 1352 6.1. Solving the Puzzle 1354 The procedures for solving and verifying a puzzle in HIP DEX are 1355 strongly based on the corresponding procedures in HIPv2. The only 1356 exceptions are that HIP DEX does not use pre-computation of R1 1357 packets and that RHASH is set to CMAC. As a result, the pre- 1358 computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. 1360 Moreover, the Initiator solves a puzzle by computing: 1361 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1363 Similarly, the Responder verifies a puzzle by computing: 1364 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1366 Apart from these modifications, the procedures defined in Section 6.3 1367 of [RFC7401] also apply for HIP DEX. 1369 6.2. HIP_MAC Calculation and Verification 1371 The following subsections define the actions for processing the 1372 HIP_MAC parameter. 1374 6.2.1. CMAC Calculation 1376 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1377 cryptographic function. The scope of the calculation for HIP_MAC is: 1379 CMAC: { HIP header | [ Parameters ] } 1380 where Parameters include all HIP parameters of the packet that is 1381 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1382 value - 1) and exclude parameters with Type values greater or equal 1383 to HIP_MAC's Type value. 1385 During HIP_MAC calculation, the following applies: 1387 o In the HIP header, the Checksum field is set to zero. 1389 o In the HIP header, the Header Length field value is calculated to 1390 the beginning of the HIP_MAC parameter. 1392 The parameter order is described in Section 5.2.1 of [RFC7401]. 1394 The CMAC calculation and verification process is as follows: 1396 Packet sender: 1398 1. Create the HIP packet, without the HIP_MAC or any other parameter 1399 with greater Type value than the HIP_MAC parameter has. 1401 2. Calculate the Header Length field in the HIP header. 1403 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1404 retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers 1405 to host with greater HIT value and HIP-lg refers to the host with 1406 smaller HIT value. 1408 4. Add the HIP_MAC parameter to the packet and any parameter with 1409 greater Type value than the HIP_MAC's that may follow. 1411 5. Recalculate the Length field in the HIP header. 1413 Packet receiver: 1415 1. Verify the HIP header Length field. 1417 2. Remove the HIP_MAC parameter, as well as all other parameters 1418 that follow it with greater Type value, saving the contents if 1419 they will be needed later. 1421 3. Recalculate the HIP packet length in the HIP header and clear the 1422 Checksum field (set it to all zeros). 1424 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1425 defined in Section 6.3 and verify it against the received CMAC. 1427 5. Set Checksum and Header Length fields in the HIP header to 1428 original values. Note that the Checksum and Length fields 1429 contain incorrect values after this step. 1431 6.3. HIP DEX KEYMAT Generation 1433 The HIP DEX KEYMAT process is used to derive the keys for the Master 1434 Key SA as well as for the Pair-wise Key SA. The keys for the Master 1435 Key SA are based on the Diffie-Hellman derived key, Kij, which is 1436 produced during the HIP DEX handshake. The Initiator generates Kij 1437 during the creation of the I2 packet and the Responder generates Kij 1438 once it receives the I2 packet. This is why the I2 packet can 1439 already contain authenticated and/or encrypted information. 1441 The keys derived for the Pair-wise Key SA are not used during the HIP 1442 DEX handshake. Instead, these keys are made available as payload 1443 protection keys (e.g., for IPsec). Some payload protection 1444 mechanisms have their own Key Derivation Function, and if so this 1445 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 1446 be used to derive the keys of the Pair-wise Key SA based on the 1447 concatenation of the random values that are contained in the 1448 exchanged ENCRYPTED_KEY parameters. 1450 The HIP DEX KEYMAT process is based on the Hash-based Key Derivation 1451 Function (HKDF) defined in [RFC5869] and consists of two components, 1452 CKDF-Extract and CKDF-Expand. The CKDF-Extract function compresses a 1453 non-uniformly distributed key, such as the output of a Diffie-Hellman 1454 key derivation, to extract the key entropy into a fixed length 1455 output. The CKDF-Expand function takes either the output of the 1456 Extract function or directly uses a uniformly distributed key and 1457 expands the length of the key, repeatedly distributing the key 1458 entropy, to produce the keys needed. 1460 The key derivation for the Master Key SA employs always both the 1461 Extract and Expand phases. The Pair-wise Key SA needs only the 1462 Extract phase when the key is smaller or equal to 128 bits, but 1463 otherwise requires also the Expand phase. 1465 The CKDF-Extract function is the following operation: 1467 CKDF-Extract(I, IKM, info) -> PRK 1469 Inputs: 1470 I Random #I, provided by the Responder, from the PUZZLE 1471 parameter 1472 IKM Input keying material 1473 the Diffie-Hellman derived key, concatenated with the 1474 random I_NONCE value for the Master Key SA 1475 the Diffie-Hellman derived key, concatenated with the 1476 random values of the ENCRYPTED_KEY parameters in 1477 the same order as the HITs with sort(HIT-I | HIT-R) 1478 for the Pair-wise Key SA 1480 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1481 where "CKDF-Extract" is an octet string 1483 Output: 1484 PRK a pseudorandom key (of RHASH_len/8 octets) 1486 The pseudorandom key PRK is calculated as follows: 1488 PRK = CMAC(I, IKM | info) 1490 The CKDF-Expand function is the following operation: 1492 CKDF-Expand(PRK, info, L) -> OKM 1494 Inputs: 1495 PRK a pseudorandom key of at least RHASH_len/8 octets 1496 (either the output from the extract step or the 1497 concatenation of the random values of the 1498 ENCRYPTED_KEY parameters in the same order as the 1499 HITs with sort(HIT-I | HIT-R) in case of no extract) 1500 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1501 where "CKDF-Expand" is an octet string 1502 L length of output keying material in octets 1503 (<= 255*RHASH_len/8) 1505 Output: 1506 OKM output keying material (of L octets) 1508 The output keying material OKM is calculated as follows: 1510 N = ceil(L/(RHASH_len/8)) 1511 T = T(1) | T(2) | T(3) | ... | T(N) 1512 OKM = first L octets of T 1514 where 1516 T(0) = empty string (zero length) 1517 T(1) = CMAC(PRK, T(0) | info | 0x01) 1518 T(2) = CMAC(PRK, T(1) | info | 0x02) 1519 T(3) = CMAC(PRK, T(2) | info | 0x03) 1520 ... 1522 (where the constant concatenated to the end of each T(n) is a 1523 single octet.) 1525 sort(HIT-I | HIT-R) is defined as the network byte order 1526 concatenation of the two HITs, with the smaller HIT preceding the 1527 larger HIT, resulting from the numeric comparison of the two HITs 1528 interpreted as positive (unsigned) 128-bit integers in network byte 1529 order. 1531 The initial keys for the Master Key SA are drawn sequentially in the 1532 order that is determined by the numeric comparison of the two HITs, 1533 with the comparison method described in the previous paragraph. 1534 HOST_g denotes the host with the greater HIT value, and HOST_l the 1535 host with the lower HIT value. 1537 The drawing order for initial keys: 1539 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1540 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1542 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1544 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1546 The number of bits drawn for a given algorithm is the "natural" size 1547 of the keys regarding the algorithm defined in the HIP_CIPHER. For 1548 the mandatory algorithms, the following size applies: 1550 AES 128 bits 1552 If other key sizes are used, they must be treated as different 1553 encryption algorithms and defined separately. 1555 6.4. Initiation of a HIP Diet EXchange 1557 The initiation of a HIP DEX handshake proceeds as described in 1558 Section 6.6 of [RFC7401]. The I1 packet contents are specified in 1559 Section 5.3.1. 1561 6.5. Processing Incoming I1 Packets 1563 I1 packets in HIP DEX are handled almost identical to HIPv2 (see 1564 Section 6.7 of [RFC7401]). The main differences are that the 1565 Responder SHOULD select a HIP DEX HIT Suite in the R1 response. 1566 Moreover, as R1 packets are neither covered by a signature nor incur 1567 the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- 1568 computation of an R1 is only marginally beneficial, but would incur 1569 additional memory resources at the Responder. Hence, the R1 pre- 1570 computation SHOULD be omitted in HIP DEX. 1572 Correspondingly, the modified conceptual processing rules for 1573 responding to an I1 packet are as follows: 1575 1. The Responder MUST check that the Responder's HIT in the received 1576 I1 packet is either one of its own HITs or NULL. Otherwise, it 1577 MUST drop the packet. 1579 2. If the Responder is in ESTABLISHED state, the Responder MAY 1580 respond to this with an R1 packet, prepare to drop an existing 1581 HIP security association with the peer, and stay at ESTABLISHED 1582 state. 1584 3. If the Responder is in I1-SENT state, it MUST make a comparison 1585 between the sender's HIT and its own (i.e., the receiver's) HIT. 1586 If the sender's HIT is greater than its own HIT, it should drop 1587 the I1 packet and stay at I1-SENT. If the sender's HIT is 1588 smaller than its own HIT, it SHOULD send the R1 packet and stay 1589 at I1-SENT. The HIT comparison is performed as defined in 1590 Section 6.3. 1592 4. If the implementation chooses to respond to the I1 packet with an 1593 R1 packet, it creates a new R1 according to the format described 1594 in Section 5.3.2. It chooses the HI based on the destination HIT 1595 and the DH_GROUP_LIST in the I1 packet. If the implementation 1596 does not support the DH group required by the Initiator or if the 1597 destination HIT in the I1 packet does not match the required DH 1598 group, it selects the mutually preferred and supported DH group 1599 based on the DH_GROUP_LIST parameter in the I1 packet. The 1600 implementation includes the corresponding ECDH public key in the 1601 HOST_ID parameter. If no suitable DH Group ID was contained in 1602 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with 1603 any suitable ECDH public key. 1605 5. If the received Responder's HIT in the I1 packet is not NULL, the 1606 Responder's HIT in the R1 packet MUST match the destination HIT 1607 in the I1 packet. Otherwise, the Responder MUST select a HIT 1608 with the same HIT Suite as the Initiator's HIT. If this HIT 1609 Suite is not supported by the Responder, it SHOULD select a 1610 REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is 1611 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 1612 a local policy matter. 1614 6. The Responder expresses its supported HIP transport formats in 1615 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of 1616 [RFC7401]. The Responder MUST provide at least one payload 1617 transport format type. 1619 7. The Responder sends the R1 packet to the source IP address of the 1620 I1 packet. 1622 Note that only steps 4 and 5 have been changed with regard to the 1623 processing rules of HIPv2. The considerations about R1 management 1624 (except pre-computation) and malformed I1 packets in Sections 6.7.1 1625 and 6.7.2 of [RFC7401] likewise apply to HIP DEX. 1627 6.6. Processing Incoming R1 Packets 1629 R1 packets in HIP DEX are handled identically to HIPv2 (see 1630 Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses 1631 ECDH public keys as HIs and does not employ signatures. 1633 The modified conceptual processing rules for responding to an R1 1634 packet are as follows: 1636 1. A system receiving an R1 MUST first check to see if it has sent 1637 an I1 packet to the originator of the R1 packet (i.e., it has a 1638 HIP association that is in state I1-SENT and that is associated 1639 with the HITs in the R1). Unless the I1 packet was sent in 1640 opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP 1641 addresses in the received R1 packet SHOULD be ignored by the R1 1642 processing and, when looking up the correct HIP association, the 1643 received R1 packet SHOULD be matched against the associations 1644 using only the HITs. If a match exists, the system processes 1645 the R1 packet as described below. 1647 2. Otherwise, if the system is in any state other than I1-SENT or 1648 I2-SENT with respect to the HITs included in the R1 packet, it 1649 SHOULD silently drop the R1 packet and remain in the current 1650 state. 1652 3. If the HIP association state is I1-SENT or I2-SENT, the received 1653 Initiator's HIT MUST correspond to the HIT used in the original 1654 I1 packet. Also, the Responder's HIT MUST correspond to the one 1655 used in the I1 packet, unless this packet contained a NULL HIT. 1657 4. If the HIP association state is I1-SENT, and multiple valid R1 1658 packets are present, the system MUST select from among the R1 1659 packets with the largest R1 generation counter. 1661 5. The system MUST check that the Initiator's HIT Suite is 1662 contained in the HIT_SUITE_LIST parameter in the R1 packet 1663 (i.e., the Initiator's HIT Suite is supported by the Responder). 1664 If the HIT Suite is supported by the Responder, the system 1665 proceeds normally. Otherwise, the system MAY stay in state 1666 I1-SENT and restart the HIP DEX handshake by sending a new I1 1667 packet with an Initiator HIT that is supported by the Responder 1668 and hence is contained in the HIT_SUITE_LIST in the R1 packet. 1669 The system MAY abort the handshake if no suitable source HIT is 1670 available. The system SHOULD wait for an acceptable time span 1671 to allow further R1 packets with higher R1 generation counters 1672 or different HIT and HIT Suites to arrive before restarting or 1673 aborting the HIP DEX handshake. 1675 6. The system MUST check that the DH Group ID in the HOST_ID 1676 parameter in the R1 matches the first DH Group ID in the 1677 Responder's DH_GROUP_LIST in the R1 packet, and also that this 1678 Group ID corresponds to a value that was included in the 1679 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 1680 of the HOST_ID parameter does not express the Responder's best 1681 choice, the Initiator can conclude that the DH_GROUP_LIST in the 1682 I1 or R1 packet was adversely modified. In such a case, the 1683 Initiator MAY send a new I1 packet; however, it SHOULD NOT 1684 change its preference in the DH_GROUP_LIST in the new I1 packet. 1685 Alternatively, the Initiator MAY abort the HIP DEX handshake. 1686 Moreover, if the DH Group ID indicated in the HOST_ID parameter 1687 does not match the DH Group ID of the HI employed by the 1688 Initiator, the system SHOULD wait for an acceptable time span to 1689 allow further R1 packets with different DH Group IDs to arrive 1690 before restarting or aborting the HIP DEX handshake. When 1691 restarting the handshake, the Initiator MUST consult local 1692 policies (see Section 7) regarding the use of another, mutually 1693 supported DH group for the subsequent handshake with the 1694 Responder. 1696 7. If the HIP association state is I2-SENT, the system MAY re-enter 1697 state I1-SENT and process the received R1 packet if it has a 1698 larger R1 generation counter than the R1 packet responded to 1699 previously. 1701 8. The R1 packet can have the A-bit set - in this case, the system 1702 MAY choose to refuse it by dropping the R1 packet and returning 1703 to state UNASSOCIATED. The system SHOULD consider dropping the 1704 R1 packet only if it used a NULL HIT in the I1 packet. If the 1705 A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be 1706 stored permanently. 1708 9. The system SHOULD attempt to validate the HIT against the 1709 received Host Identity by using the received Host Identity to 1710 construct a HIT and verify that it matches the Sender's HIT. 1712 10. The system MUST store the received R1 generation counter for 1713 future reference. 1715 11. The system attempts to solve the puzzle in the R1 packet. The 1716 system MUST terminate the search after exceeding the remaining 1717 lifetime of the puzzle. If the puzzle is not successfully 1718 solved, the implementation MAY either resend the I1 packet 1719 within the retry bounds or abandon the HIP base exchange. 1721 12. The system computes standard Diffie-Hellman keying material 1722 according to the public value and Group ID provided in the 1723 HOST_ID parameter. The Diffie-Hellman keying material Kij is 1724 used for key extraction as specified in Section 6.3. 1726 13. The system selects the HIP_CIPHER ID from the choices presented 1727 in the R1 packet and uses the selected values subsequently when 1728 generating and using encryption keys, and when sending the I2 1729 packet. If the proposed alternatives are not acceptable to the 1730 system, it MAY either resend an I1 packet within the retry 1731 bounds or abandon the HIP base exchange. 1733 14. The system chooses one suitable transport format from the 1734 TRANSPORT_FORMAT_LIST and includes the respective transport 1735 format parameter in the subsequent I2 packet. 1737 15. The system initializes the remaining variables in the associated 1738 state, including Update ID counters. 1740 16. The system prepares and sends an I2 packet as described in 1741 Section 5.3.3. 1743 17. The system SHOULD start a timer whose timeout value SHOULD be 1744 larger than the worst-case anticipated RTT, and MUST increment a 1745 trial counter associated with the I2 packet. The sender SHOULD 1746 retransmit the I2 packet upon a timeout and restart the timer, 1747 up to a maximum of I2_RETRIES_MAX tries. 1749 18. If the system is in state I1-SENT, it SHALL transition to state 1750 I2-SENT. If the system is in any other state, it remains in the 1751 current state. 1753 Note that step 4 from the original processing rules of HIPv2 1754 (signature verification) has been removed in the above processing 1755 rules for HIP DEX. Moreover, step 7 of the original processing rules 1756 has been adapted in step 6 above to account for the fact that HIP DEX 1757 uses ECDH public keys as HIs. The considerations about malformed R1 1758 packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX. 1760 6.7. Processing Incoming I2 Packets 1762 The processing of I2 packets follows similar rules as HIPv2 (see 1763 Section 6.9 of [RFC7401]). The main differences to HIPv2 are that 1764 HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY 1765 parameter as well as an I2 reception acknowledgement for 1766 retransmission purposes. Moreover, with HIP DEX the Initiator is 1767 responsible for triggering retransmissions, whereas the Responder 1768 merely replies to received I2 packets. 1770 The modified HIP DEX conceptual processing rules for responding to an 1771 I2 packet are: 1773 1. The system MAY perform checks to verify that the I2 packet 1774 corresponds to a recently sent R1 packet. Such checks are 1775 implementation dependent. See Appendix A in [RFC7401] for a 1776 description of an example implementation. 1778 2. The system MUST check that the Responder's HIT corresponds to 1779 one of its own HITs and MUST drop the packet otherwise. 1781 3. The system MUST further check that the Initiator's HIT Suite is 1782 supported. The Responder SHOULD silently drop I2 packets with 1783 unsupported Initiator HITs. 1785 4. If the system's state machine is in the R2-SENT state, the 1786 system MUST check to see if the newly received I2 packet is 1787 similar to the one that triggered moving to R2-SENT. If so, it 1788 MUST retransmit a previously sent R2 packet and reset the 1789 R2-SENT timer. The system SHOULD re-use the previously 1790 established state to re-create the corresponding R2 packet in 1791 order to prevent unnecessary computation overhead. 1793 5. If the system's state machine is in the I2-SENT state, the 1794 system MUST make a comparison between its local and sender's 1795 HITs (similarly as in Section 6.3). If the local HIT is smaller 1796 than the sender's HIT, it should drop the I2 packet, use the 1797 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1798 #I from the R1 packet received earlier, and get the local 1799 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1800 from the I2 packet sent to the peer earlier. Otherwise, the 1801 system processes the received I2 packet and drops any previously 1802 derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY 1803 keying material it might have generated upon sending the I2 1804 packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY, 1805 and the nonce #J are taken from the just arrived I2 packet. The 1806 local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the 1807 nonce #I are the ones that were sent earlier in the R1 packet. 1809 6. If the system's state machine is in the I1-SENT state, and the 1810 HITs in the I2 packet match those used in the previously sent I1 1811 packet, the system uses this received I2 packet as the basis for 1812 the HIP association it was trying to form, and stops 1813 retransmitting I1 packets (provided that the I2 packet passes 1814 the additional checks below). 1816 7. If the system's state machine is in any state other than 1817 R2-SENT, the system SHOULD check that the echoed R1 generation 1818 counter in the I2 packet is within the acceptable range if the 1819 counter is included. Implementations MUST accept puzzles from 1820 the current generation and MAY accept puzzles from earlier 1821 generations. If the generation counter in the newly received I2 1822 packet is outside the accepted range, the I2 packet is stale 1823 (and perhaps replayed) and SHOULD be dropped. 1825 8. The system MUST validate the solution to the puzzle as described 1826 in Section 6.1. 1828 9. The I2 packet MUST have a single value in the HIP_CIPHER 1829 parameter, which MUST match one of the values offered to the 1830 Initiator in the R1 packet. 1832 10. The system MUST derive Diffie-Hellman keying material Kij based 1833 on the public value and Group ID in the HOST_ID parameter. This 1834 keying material is used to derive the keys of the Master Key SA 1835 as described in Section 6.3. If the Diffie-Hellman Group ID is 1836 unsupported, the I2 packet is silently dropped. If the 1837 processing time for the derivation of the Diffie-Hellman keying 1838 material Kij is likely to cause premature I2 retransmissions by 1839 the Initiator, the system MAY send a NOTIFY packet before 1840 starting the key derivation process. The NOTIFY packet contains 1841 a NOTIFICATION parameter with Notify Message Type 1842 I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the 1843 anticipated remaining processing time for the I2 packet in 1844 milliseconds as two-octet Notification Data. 1846 11. The implementation SHOULD also verify that the Initiator's HIT 1847 in the I2 packet corresponds to the Host Identity sent in the I2 1848 packet. (Note: some middleboxes may not be able to make this 1849 verification.) 1851 12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1852 Other documents specifying transport formats (e.g., [RFC7402]) 1853 contain specifications for handling any specific transport 1854 selected. 1856 13. The system MUST verify the HIP_MAC according to the procedures 1857 in Section 6.2. 1859 14. If the checks above are valid, then the system proceeds with 1860 further I2 processing; otherwise, it discards the I2 and its 1861 state machine remains in the same state. 1863 15. The I2 packet may have the A-bit set - in this case, the system 1864 MAY choose to refuse it by dropping the I2 and the state machine 1865 returns to state UNASSOCIATED. If the A-bit is set, the 1866 Initiator's HIT is anonymous and MUST NOT be stored permanently. 1868 16. The system MUST decrypt the keying material from the 1869 ENCRYPTED_KEY parameter. This keying material is a partial 1870 input to the key derivation process for the Pair-wise Key SA 1871 (see Section 6.3). 1873 17. The system initializes the remaining variables in the associated 1874 state, including Update ID counters. 1876 18. Upon successful processing of an I2 packet when the system's 1877 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 1878 R2-SENT, an R2 packet is sent as described in Section 5.3.4 and 1879 the system's state machine transitions to state R2-SENT. 1881 19. Upon successful processing of an I2 packet when the system's 1882 state machine is in state ESTABLISHED, the old HIP association 1883 is dropped and a new one is installed, an R2 packet is sent as 1884 described in Section 5.3.4, and the system's state machine 1885 transitions to R2-SENT. 1887 20. Upon the system's state machine transitioning to R2-SENT, the 1888 system starts a timer. The state machine transitions to 1889 ESTABLISHED if some data has been received on the incoming HIP 1890 association, or an UPDATE packet has been received (or some 1891 other packet that indicates that the peer system's state machine 1892 has moved to ESTABLISHED). If the timer expires (allowing for a 1893 maximal amount of retransmissions of I2 packets), the state 1894 machine transitions to ESTABLISHED. 1896 Note that steps 11 (encrypted HOST_ID) and 15 (signature 1897 verification) from the original processing rules of HIPv2 have been 1898 removed in the above processing rules for HIP DEX. Moreover, step 10 1899 of the HIPv2 processing rules has been adapted to account for 1900 optional extension of the retransmission mechanism. Step 16 has been 1901 added to the processing rules in this document. The considerations 1902 about malformed I2 packets in Sections 6.9.1 of [RFC7401] also apply 1903 to HIP DEX. 1905 6.8. Processing Incoming R2 Packets 1907 R2 packets in HIP DEX are handled identically to HIPv2 (see 1908 Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX 1909 introduces a new session key exchange via the ENCRYPTED_KEY parameter 1910 and does not employ signatures. 1912 The modified conceptual processing rules for responding to an R2 1913 packet are as follows: 1915 1. If the system is in any other state than I2-SENT, the R2 packet 1916 is silently dropped. 1918 2. The system MUST verify that the HITs in use correspond to the 1919 HITs that were received in the R1 packet that caused the 1920 transition to the I2-SENT state. 1922 3. The system MUST verify the HIP_MAC according to the procedures in 1923 Section 6.2. 1925 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1926 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1927 packet and compare the results against the chosen suites. 1929 5. If any of the checks above fail, there is a high probability of 1930 an ongoing man-in-the-middle or other security attack. The 1931 system SHOULD act accordingly, based on its local policy. 1933 6. The system MUST decrypt the keying material from the 1934 ENCRYPTED_KEY parameter. This keying material is a partial input 1935 to the key derivation process for the Pair-wise Key SA (see 1936 Section 6.3). 1938 7. Upon successful processing of the R2 packet, the state machine 1939 transitions to state ESTABLISHED. 1941 Note that step 4 (signature verification) from the original 1942 processing rules of HIPv2 has been replaced with a negotiation re- 1943 evaluation in the above processing rules for HIP DEX. Moreover, step 1944 6 has been added to the processing rules. 1946 6.9. Processing Incoming NOTIFY Packets 1948 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 1949 in a received NOTIFICATION parameter SHOULD be logged. Received 1950 errors MUST be considered only as informational, and the receiver 1951 SHOULD NOT change its HIP state purely based on the received NOTIFY 1952 packet. 1954 If a NOTIFY packet is received in state I2-SENT, this packet is an I2 1955 reception acknowledgement of the optional retransmission mechanism 1956 extension and SHOULD be processed. The following steps define the 1957 conceptual processing rules for such incoming NOTIFY packets in state 1958 I2-SENT: 1960 1. The system MUST verify that the HITs in use correspond to the 1961 HITs that were received in the R1 packet that caused the 1962 transition to the I2-SENT state. If this check fails, the NOTIFY 1963 packet MUST be dropped silently. 1965 2. If the NOTIFY packet contains a NOTIFICATION parameter with 1966 Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the 1967 I2 retransmission timer to the I2 processing time indicated in 1968 the NOTIFICATION parameter plus half the RTT-based timeout value. 1969 The system MUST NOT set the retransmission timeout to a higher 1970 value than allowed by a local policy. Moreover, the system 1971 SHOULD reset the I2 retransmission timer to the RTT-based timeout 1972 value after the next I2 retransmission. 1974 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 1976 UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 1977 as in HIPv2 (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). 1978 The only difference is the that the HIP_SIGNATURE is never present 1979 and, therefore, is not required to be processed by the receiving 1980 party. 1982 [RFC7402] specifies the rekeying of an existing HIP SA using the 1983 UPDATE message. This rekeying procedure can also be used with HIP 1984 DEX. However, where rekeying involves a new Diffie-Hellman key 1985 exchange, HIP DEX peers MUST establish a new HIP association in order 1986 to create a new Pair-wise Key SA due to the use of static ECDH key- 1987 pairs with HIP DEX. 1989 6.11. Handling State Loss 1991 Implementors MAY choose to use non-volatile, secure storage for HIP 1992 states in order for them to survive a system reboot. If no secure 1993 storage capabilities are available, the system SHOULD delete the 1994 corresponding HIP state, including the keying material. If the 1995 implementation does drop the state (as RECOMMENDED), it MUST also 1996 drop the peer's R1 generation counter value, unless a local policy 1997 explicitly defines that the value of that particular host is stored. 1998 Such storing of the R1 generation counter values MUST be configured 1999 by explicit HITs. 2001 7. HIP Policies 2003 There are a number of variables that will influence the HIP exchanges 2004 that each host must support. The value of puzzle difficulty K used 2005 in the HIP R1 must be chosen with care. Values for the K that are 2006 too high will exclude clients with weak CPUs because these devices 2007 cannot solve the puzzle within a reasonable amount of time. The K 2008 value should only be raised if a Responder is under high load, i.e., 2009 it cannot process all incoming HIP handshakes any more. 2011 If a Responder is not under high load, K SHOULD be 0. 2013 All HIP DEX implementations SHOULD provide for an Access Control List 2014 (ACL), representing for which hosts they accept HIP diet exchanges, 2015 and the preferred transport format and local lifetimes. Wildcarding 2016 SHOULD be supported for such ACLs. 2018 8. Interoperability between HIP DEX and HIPv2 2020 HIP DEX and HIPv2 both use the same protocol number and packet 2021 formats. Hence, an implementation that either supports HIP DEX or 2022 HIPv2 has to be able to detect the dialect that the peer is speaking. 2023 This section outlines how a HIP DEX implementation can achieve such 2024 detection for the two relevant cases where: 2026 1. the Initiator supports HIP DEX and the Responder supports HIP 2027 BEX, 2029 2. the Initiator supports HIP BEX and the Responder supports HIP 2030 DEX. 2032 In the first case, the HIP DEX implementation (Initiator) inspects 2033 the Responder's HIT prior to sending the I1 packet. If the OGA ID 2034 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 2035 DEX implementation cancels the handshake. If the Responder is 2036 unknown prior to sending the I1 packet (i.e., opportunistic mode), 2037 the HIP DEX implementation performs the above check on reception of 2038 the R1 packet and cancels the handshake in case of a negative result. 2039 In both failure scenarios, the implementation should report an error 2040 to the user via appropriate means. 2042 In the second case, the HIP DEX implementation (Responder) inspects 2043 the Initiator's HIT on reception of an I1 packet. If the OGA ID 2044 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 2045 DEX implementation cancels the handshake and sends an ICMP packet 2046 with type Parameter Problem, with the Pointer pointing to the source 2047 HIT, to the Initiator. As an off-path adversary could also send such 2048 an ICMP packet with the aim to prevent the HIP DEX handshake from 2049 completing, the Initiator SHOULD NOT react to an ICMP message before 2050 retransmission counter reaches I1_RETRIES_MAX in its state machine 2051 (see Table 3 in [RFC7401]). 2053 9. Security Considerations 2055 HIP DEX closely resembles HIPv2. As such, the security 2056 considerations discussed in Section 8 of [RFC7401] similarly apply to 2057 HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated 2058 Diffie-Hellman key exchange of HIPv2 with an exchange of random 2059 keying material that is encrypted with a Diffie-Hellman derived key. 2060 Both the Initiator and Responder contribute to this keying material. 2061 As a result, the following additional security considerations apply 2062 to HIP DEX: 2064 o The strength of the keys for both the Master and Pair-wise Key SAs 2065 is based on the quality of the random keying material generated by 2066 the Initiator and the Responder. As either peer may be a sensor 2067 or an actuator device, there is a natural concern about the 2068 quality of its random number generator. Thus at least a CSPRNG 2069 SHOULD be used. 2071 o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. 2072 Consequently, if an HI is compromised, all previous HIP 2073 connections protected with that HI are compromised as explained in 2074 Section 1. 2076 o The puzzle mechanism using CMAC explained in Section 4.1.1 may 2077 need further study regarding the level of difficulty in order to 2078 establish best practices with current generation of constrained 2079 devices. 2081 o The HIP DEX HIT generation may present new attack opportunities. 2082 Hence, HIP DEX HITs MUST NOT be used as the only means to identify 2083 a peer in an ACL. Instead, the use of the peer's HI is 2084 recommended as explained in Section 3. 2086 o The R1 packet is unauthenticated and offers an adversary a new 2087 attack vector against the Initiator. This is mitigated by only 2088 processing a received R1 packet when the Initiator has previously 2089 sent a corresponding I1 packet. Moreover, the Responder repeats 2090 the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and 2091 TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to 2092 enable the Initiator to verify that these parameters have not been 2093 modified by an attacker in the unprotected R1 packet as explained 2094 in Section 6.8. 2096 o Contrary to HIPv2, HIP DEX does not provide for end-point 2097 anonymity for the Initiator or Responder. Thus, any signaling 2098 that indicates such anonymity should be ignored as explained in 2099 Section 1.1. 2101 The optional retransmission extension of HIP DEX is based on a NOTIFY 2102 packet that the Responder can use to inform the Initiator about the 2103 reception of an I2 packet. The Responder, however, cannot protect 2104 the authenticity of this packet as it did not yet set up the Master 2105 Key SA. Hence, an eavesdropping adversary may send spoofed reception 2106 acknowledgements for an overheard I2 packet and signal an arbitrary 2107 I2 processing time to the Initiator. The adversary can, e.g., 2108 indicate a lower I2 processing time than actually required by the 2109 Responder in order to cause premature retransmissions. To protect 2110 against this attack, the Initiator SHOULD set the NOTIFY-based 2111 timeout value to the maximum indicated packet processing time in case 2112 of conflicting NOTIFY packets. This allows the legitimate Responder 2113 to extend the retransmission timeout to the intended length. The 2114 adversary, however, can still arbitrarily delay the protocol 2115 handshake beyond the Responder's actual I2 processing time. To limit 2116 the extend of such a maliciously induced handshake delay, this 2117 specification additionally requires the Initiator not to set the 2118 NOTIFY-based timeout value higher than allowed by a local policy. 2120 Section 5.3.1 mentions that implementations need to be able to handle 2121 storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre- 2122 computed in HIP DEX and also the state machine does not include an 2123 "R1_SENT" state (that would enable caching of R1 packets). 2124 Therefore, an implementation has to cache information (e.g., at least 2125 the HITs) from incoming I1 packets and rate control the incoming I1 2126 packets to avoid unnecessary packet processing during I1 packet 2127 storms. 2129 9.1. SECP160R1 Considered Unsafe 2131 The SECP160R1 curve is included more for historical reasons than a 2132 demostrated need for a lightweight curve for constrained systems. 2133 Until it is deprecated from [RFC7401], it is included, but 2134 implementors should carefully weigh any advantages actual or 2135 perceived over EC25519. Actual implementations of EC25519 on an 8501 2136 show that it can be used on very constrained hardware. The over-the- 2137 air and storage costs for EC25519 are also closely comparable with 2138 SECP160R1. 2140 Thus the security risk of the weak SECP160R1 must be shown to be of 2141 value over any slight costs of using EC25519 instead. 2143 9.2. Need to Validate Public Keys 2145 With the curves specified here, there is a straightforward key 2146 extraction attack, which is a very serious problem with the use of 2147 static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's 2148 Public Key. 2150 For the curve SECP160R1, peers MUST validate each other's public 2151 value Q by ensuring that the point is a valid point on the elliptic 2152 curve. This process consists of three steps: (1) verify that Q is 2153 not the point at infinity (O), (2) verify that for Q = (x, y) both 2154 integers x and y are in the correct interval, and (3) ensure that (x, 2155 y) is a correct solution to the elliptic curve equation. For this 2156 curve, implementors do not need to verify membership in the correct 2157 subgroup. 2159 With the NIST curves, there are no internal length markers, so each 2160 number representation occupies as many octets as implied by the curve 2161 parameters. For P-256, this means that each of X and Y use 32 2162 octets, padded on the left by zeros if necessary. For P-384, they 2163 take 48 octets each. For P-521, they take 66 octets each. 2165 For Curve25519 and Curve448, the contents of the public value are the 2166 byte string inputs and outputs of the corresponding functions defined 2167 in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. 2169 10. IANA Considerations 2171 The following changes to the "Host Identity Protocol (HIP) 2172 Parameters" registries have been made: 2174 ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) 2175 (see Section 5.2.5) in the "Parameter Types" subregistry of the 2176 "Host Identity Protocol (HIP) Parameters" registry. 2178 I_NONCE "I_NONCE" with type number TBD6 (suggested: 644) (see 2179 Section 5.2.6) in the "Parameter Types" subregistry of the "Host 2180 Identity Protocol (HIP) Parameters" registry. 2182 HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" 2183 without four-bit ID of TBD2 (suggested: 4) and eight-bit encoding 2184 of TBD3 (suggested: 0x40) (see Section 5.2.4) in the "HIT Suite 2185 ID" subregistry of the "Host Identity Protocol (HIP) Parameters" 2186 registry. 2188 HIP Cipher ID This document defines the new HIP Cipher ID "AES- 2189 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2) 2190 in the "HIP Cipher ID" subregistry of the "Host Identity Protocol 2191 (HIP) Parameters" registry. 2193 HI Algorithm This document defines the new HI Algorithm "ECDH" with 2194 type number TBD5 (suggested: 11) (see Section 5.2.3) in the "HI 2195 Algorithm" subregistry of the "Host Identity Protocol (HIP) 2196 Parameters" registry. 2198 ECC Curve Label This document specifies a new algorithm-specific 2199 subregistry named "ECDH Curve Label". The values for this 2200 subregistry are defined in Section 5.2.1. The complete list of 2201 algorithms for the DH_GROUP_LIST parameter are listed in the 2202 "Group IDs" subregistry of the "Host Identity Protocol (HIP) 2203 Parameters" registry. 2205 11. Acknowledgements 2207 The drive to put HIP on a cryptographic 'Diet' came out of a number 2208 of discussions with sensor vendors at IEEE 802.15 meetings. David 2209 McGrew was very helpful in crafting this document. Special thanks to 2210 Mohit Sethi in helping with the draft during IESG process. 2212 12. Changelog 2214 This section summarizes the changes made from draft-moskowitz-hip-rg- 2215 dex-05, which was the first stable version of the draft. Note that 2216 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 2218 The draft was then renamed from draft-moskowitz-hip-dex to draft- 2219 ietf-hip-dex. 2221 12.1. Changes in draft-ietf-hip-dex-14 2223 o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan 2224 comment 2226 12.2. Changes in draft-ietf-hip-dex-12 and 13 2228 o Nits from Jeff Ahrenholz (including some formatting issues) 2230 12.3. Changes in draft-ietf-hip-dex-11 and 12 2232 o Included more precise references to the IANA subregistries 2234 o Addressed GEN-ART feedback from Francis Dupont 2236 o Added reasoning for PFS in a separate section, and it is mentioned 2237 also in the abstract and intro. 2239 o Donald Eastlake's (secdir) nits addressed 2241 o Resolved IANA nits from Amanda Baber. 2243 o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 2244 Considered Unsafe" (Section 9.1), "Need to Validate Public Keys" 2245 (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric 2246 Rescorla's concerns. 2248 12.4. Changes in draft-ietf-hip-dex-11 2250 o Update IANA considerations as requested by Eric Envyncke 2252 12.5. Changes in draft-ietf-hip-dex-10 2254 o Explanations on why the document includes so many SHOULDs 2256 12.6. Changes in draft-ietf-hip-dex-09 2258 o Fixed values for 2260 * DH_GROUP_LIST 2262 * HIT_SUITE_LIST 2264 to match [RFC7401]. 2266 12.7. Changes in draft-ietf-hip-dex-05 2268 o Clarified main differences between HIP BEX and HIP DEX in 2269 Section 1. 2271 o Addressed MitM attack in Section 8. 2273 o Minor editorial changes. 2275 12.8. Changes in draft-ietf-hip-dex-04 2277 o Added new paragraph on rekeying procedure with HIP DEX. 2279 o Updated references. 2281 o Editorial changes. 2283 12.9. Changes in draft-ietf-hip-dex-03 2285 o Added new section on HIP DEX/HIPv2 interoperability 2287 o Added reference to RFC4493 for CMAC. 2289 o Added reference to RFC5869 for CKDF. 2291 o Added processing of NOTIFY message in I2-SENT of state diagram. 2293 o Editorial changes. 2295 12.10. Changes in draft-ietf-hip-dex-02 2297 o Author address change. 2299 12.11. Changes in draft-ietf-hip-dex-01 2301 o Added the new ECDH groups of Curve25519 and Curve448 from RFC 2302 7748. 2304 12.12. Changes in draft-ietf-hip-dex-00 2306 o The Internet Draft was adopted by the HIP WG. 2308 12.13. Changes in draft-moskowitz-hip-rg-dex-06 2310 o A major change in the ENCRYPT parameter to use AES-CTR rather than 2311 AES-CBC. 2313 12.14. Changes in draft-moskowitz-hip-dex-00 2315 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 2316 submission. 2318 o Added the change section. 2320 o Added a Definitions section. 2322 o Changed I2 and R2 packets to reflect use of AES-CTR for 2323 ENCRYPTED_KEY parameter. 2325 o Cleaned up KEYMAT Generation text. 2327 o Added Appendix with C code for the ECDH shared secret generation 2328 on an 8 bit processor. 2330 12.15. Changes in draft-moskowitz-hip-dex-01 2332 o Numerous editorial changes. 2334 o New retransmission strategy. 2336 o New HIT generation mechanism. 2338 o Modified layout of ENCRYPTED_KEY parameter. 2340 o Clarify use puzzle difficulty of zero under normal network 2341 conditions. 2343 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 2344 MUST). 2346 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 2347 and I2). 2349 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 2350 echoed in R2 packet. 2352 o Added new author. 2354 12.16. Changes in draft-moskowitz-hip-dex-02 2356 o Introduced formal definition of FOLD function. 2358 o Clarified use of CMAC for puzzle computation in section "Solving 2359 the Puzzle". 2361 o Several editorial changes. 2363 12.17. Changes in draft-moskowitz-hip-dex-03 2365 o Addressed HI crypto agility. 2367 o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 2369 o Extended the IV in the ENCRYPTED_KEY parameter. 2371 o Introduced forward-references to HIP DEX KEYMAT process and 2372 improved KEYMAT section. 2374 o Replaced Appendix A on "C code for ECC point multiplication" with 2375 short discussion in introduction. 2377 o Updated references. 2379 o Further editorial changes. 2381 12.18. Changes in draft-moskowitz-hip-dex-04 2383 o Improved retransmission extension. 2385 o Updated and strongly revised packet processing rules. 2387 o Updated security considerations. 2389 o Updated IANA considerations. 2391 o Move the HI Algorithm for ECDH to a value of 11. 2393 o Many editorial changes. 2395 13. References 2396 13.1. Normative References 2398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2399 Requirement Levels", BCP 14, RFC 2119, 2400 DOI 10.17487/RFC2119, March 1997, 2401 . 2403 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2404 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 2405 November 1998, . 2407 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2408 Counter Mode With IPsec Encapsulating Security Payload 2409 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2410 . 2412 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2413 Control Message Protocol (ICMPv6) for the Internet 2414 Protocol Version 6 (IPv6) Specification", STD 89, 2415 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2416 . 2418 [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the 2419 Host Identity Protocol", RFC 6261, DOI 10.17487/RFC6261, 2420 May 2011, . 2422 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 2423 Routable Cryptographic Hash Identifiers Version 2 2424 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2425 2014, . 2427 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2428 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2429 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2430 . 2432 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2433 Encapsulating Security Payload (ESP) Transport Format with 2434 the Host Identity Protocol (HIP)", RFC 7402, 2435 DOI 10.17487/RFC7402, April 2015, 2436 . 2438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2440 May 2017, . 2442 13.2. Informative References 2444 [DH76] Diffie, W. and M. Hellman, "New Directions in 2445 Cryptography", IEEE Transactions on Information 2446 Theory vol. IT-22, number 6, pages 644-654, Nov 1976. 2448 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 2449 Wehrle, "Tailoring End-to-End IP Security Protocols to the 2450 Internet of Things", in Proceedings of IEEE International 2451 Conference on Network Protocols (ICNP 2013), October 2013. 2453 [I-D.ietf-hip-rfc4423-bis] 2454 Moskowitz, R. and M. Komu, "Host Identity Protocol 2455 Architecture", draft-ietf-hip-rfc4423-bis-20 (work in 2456 progress), February 2019. 2458 [IEEE.802-11.2007] 2459 Engineers, I. O. E. A. E., "Information technology - 2460 Telecommunications and information exchange between 2461 systems - Local and metropolitan area networks - Specific 2462 requirements - Part 11: Wireless LAN Medium Access Control 2463 (MAC) and Physical Layer (PHY) Specifications", 2464 IEEE Standard 802.11, June 2007, 2465 . 2468 [IEEE.802-15-4.2011] 2469 Engineers, I. O. E. A. E., "Information technology - 2470 Telecommunications and information exchange between 2471 systems - Local and metropolitan area networks - Specific 2472 requirements - Part 15.4: Wireless Medium Access Control 2473 (MAC) and Physical Layer (PHY) Specifications for Low-Rate 2474 Wireless Personal Area Networks (WPANs)", IEEE Standard 2475 802.15.4, September 2011, 2476 . 2479 [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for 2480 Elliptic Curve Cryptography in Wireless Sensor Networks", 2481 in Proceedings of International Conference on Information 2482 Processing in Sensor Networks (IPSN 2008), April 2008. 2484 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 2485 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2486 2006, . 2488 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2489 Key Derivation Function (HKDF)", RFC 5869, 2490 DOI 10.17487/RFC5869, May 2010, 2491 . 2493 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2494 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2495 DOI 10.17487/RFC5903, June 2010, 2496 . 2498 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2499 Curve Cryptography Algorithms", RFC 6090, 2500 DOI 10.17487/RFC6090, February 2011, 2501 . 2503 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2504 Constrained-Node Networks", RFC 7228, 2505 DOI 10.17487/RFC7228, May 2014, 2506 . 2508 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2509 Kivinen, "Internet Key Exchange Protocol Version 2 2510 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2511 2014, . 2513 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2514 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2515 2016, . 2517 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2518 2 , 2000, . 2520 Appendix A. Password-based two-factor authentication during the HIP DEX 2521 handshake 2523 HIP DEX allows identifying authorized connections based on a two- 2524 factor authentication mechanism. With two-factor authentication, 2525 devices that are authorized to communicate with each other are 2526 required to be pre-provisioned with a shared (group) key. The 2527 Initiator uses this pre-provisioned key to encrypt the 2528 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 2529 the Responder verifies that its challenge in the 2530 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 2531 with the correct key. If verified successfully, the Responder 2532 proceeds with the handshake. Otherwise, it silently drops the I2 2533 packet. 2535 Note that there is no explicit signaling in the HIP DEX handshake for 2536 this behavior. Thus, knowledge of two-factor authentication must be 2537 configured externally prior to the handshake. 2539 Appendix B. IESG Considerations 2541 During IESG review, a concern was raised on the number of SHOULDS in 2542 this document. Here is an analysis of the 57 SHOULDS in HIP DEX. 2544 46 of SHOULDS are also in [RFC7401]. Here are the sections with 2545 SHOULDS that match up with [RFC7401]: 2547 5.2.2. HIP_CIPHER (same as 7401) 2549 6.5. Processing Incoming I1 Packets 2550 3. (same as 7401) 2551 5. (same as 7401) 2553 6.6. Processing Incoming R1 Packets (same as 7401) 2555 6.7. Processing Incoming I2 Packets 2556 3. (same as 7401) 2557 7. (same as 7401) 2558 11. (same as 7401) 2560 6.8. Processing Incoming R2 Packets 2561 5. (same as 7401) 2563 6.9. Processing Incoming NOTIFY Packets 2564 1st para (same as 7401) 2566 6.11. Handling State Loss (same as 7401) 2568 7. HIP Policies (1st and 3rd same as 7401) 2570 Many of the other 11 SHOULDS are due to the nature of constrained 2571 devices and in most cases the text points this out: 2573 In Section 4.1.1, this is clearly adjusting for how the puzzle could 2574 actually be an attack against a constrained device. Same situation 2575 in Section 5.3.2. 2577 Section 6, clearly states that: 2579 it should be noted that many of the packet processing rules are 2580 denoted here with "SHOULD" but may be updated to "MUST" when 2581 further implementation experience provides better guidance. 2583 thus the SHOULD here is informative of future guidance. 2585 The SHOULD in Section 6.3, clearly reflects new work with the new 2586 Sponge Function KDFs: 2588 The keys derived for the Pair-wise Key SA are not used during the HIP 2589 DEX handshake. Instead, these keys are made available as payload 2590 protection keys (e.g., for IPsec). Some payload protection 2591 mechanisms have their own Key Derivation Function, and if so this 2592 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 2593 be used to derive the keys of the Pair-wise Key SA based on the 2594 concatenation of the random values that are contained in the 2595 exchanged ENCRYPTED_KEY parameters. 2597 In Section 6.5, the reason why this is a SHOULD should be clear to 2598 any implementer. That is the HIT Suite list in I1 is a desire on 2599 what suite to use. The Responder may have 'different ideas' about 2600 the Suite to use (like what it supports). Thus it is best that the 2601 Responder selects a DEX HIT, but there are good reasons, in an 2602 implementation not to do so. The implementer should know this and 2603 will deal with it appropriately. 2605 The SHOULDs in Section 6.7 and Section 6.9 are there for 2606 considerations for constrained systems. Some constrained systems 2607 need this approach, others may not. 2609 The 2nd SHOULD in Section 7 follows the same as above. ACLs and 2610 constrained systems tend to go together. 2612 Similarly in Section 8 the SHOULD is again is highlighting 2613 constrained system processing considerations. 2615 Authors' Addresses 2617 Robert Moskowitz (editor) 2618 HTT Consulting 2619 Oak Park, MI 2620 USA 2622 EMail: rgm@htt-consult.com 2624 Rene Hummen 2625 Hirschmann Automation and Control 2626 Stuttgarter Strasse 45-51 2627 Neckartenzlingen 72654 2628 Germany 2630 EMail: rene.hummen@belden.com 2632 Miika Komu 2633 Ericsson Research, Finland 2634 Hirsalantie 11 2635 Jorvas 02420 2636 Finland 2638 EMail: miika.komu@ericsson.com