idnits 2.17.1 draft-ietf-hip-dex-24.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (19 January 2021) is 1192 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 (~~), 2 warnings (==), 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: 23 July 2021 Hirschmann Automation and Control 6 M. Komu 7 Ericsson 8 19 January 2021 10 HIP Diet EXchange (DEX) 11 draft-ietf-hip-dex-24 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) and 17 specifically developed for use on low end processors. The HIP DEX 18 protocol design aims at reducing the overhead of the employed 19 cryptographic primitives by omitting public-key signatures and 20 cryptographic hash functions. 22 The HIP DEX protocol is primarily designed for computation or memory- 23 constrained sensor/actuator devices. Like HIPv2, it is expected to 24 be used together with a suitable security protocol such as the 25 Encapsulated Security Payload (ESP) for the protection of upper layer 26 protocol data. Unlike HIPv2, HIP DEX does not support Forward 27 Secrecy (FS), and MUST only be used on devices where FS is 28 prohibitively expensive. In addition, HIP DEX can also be used as a 29 keying mechanism for security primitives at the MAC layer, e.g., for 30 IEEE 802.15.4 networks. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 23 July 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 6 67 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 68 1.2.1. Partial Computational Cost of FS via SIGMA . . . . . 8 69 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 9 70 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 9 71 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 9 72 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 9 73 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 74 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11 75 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12 76 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 13 77 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 13 78 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 79 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 14 80 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 16 81 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 17 82 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 21 83 4.1.4. User Data Considerations . . . . . . . . . . . . . . 22 84 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 22 85 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 22 86 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 22 87 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 23 88 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 23 89 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 24 90 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 25 91 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 25 92 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 26 93 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 26 94 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 27 95 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 28 96 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 30 97 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 31 98 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 32 99 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 33 100 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 33 101 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 33 102 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 33 103 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 35 104 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 38 105 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 38 106 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 39 107 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 42 108 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 45 109 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 46 110 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 47 111 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 47 112 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 47 113 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 48 114 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 48 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 116 9.1. Caution on using HIP DEX rather than HIP BEX . . . . . . 51 117 9.2. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 51 118 9.3. Need to Validate Public Keys . . . . . . . . . . . . . . 51 119 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 120 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 121 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 53 122 12.1. Changes in draft-ietf-hip-dex-24 . . . . . . . . . . . . 53 123 12.2. Changes in draft-ietf-hip-dex-23 . . . . . . . . . . . . 53 124 12.3. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 53 125 12.4. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 53 126 12.5. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 54 127 12.6. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 54 128 12.7. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 54 129 12.8. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 54 130 12.9. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 54 131 12.10. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 55 132 12.11. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 55 133 12.12. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 55 134 12.13. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 55 135 12.14. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 55 136 12.15. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 55 137 12.16. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 55 138 12.17. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 56 139 12.18. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 56 140 12.19. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 56 141 12.20. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 56 142 12.21. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 56 143 12.22. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 56 144 12.23. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 56 145 12.24. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 57 146 12.25. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 57 147 12.26. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 57 148 12.27. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 58 149 12.28. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 58 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 151 13.1. Normative References . . . . . . . . . . . . . . . . . . 58 152 13.2. Informative References . . . . . . . . . . . . . . . . . 59 153 Appendix A. Calculating Collision Probabilities . . . . . . . . 62 154 Appendix B. Password-based two-factor authentication during the 155 HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 62 156 Appendix C. IESG Considerations . . . . . . . . . . . . . . . . 62 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 159 1. Introduction 161 This document specifies the Host Identity Protocol Diet EXchange (HIP 162 DEX), specifically developed for use on low end processors that 163 cannot support the cryptographic requirements of HIP Base EXchange 164 (HIP BEX). HIP DEX is derived from HIP BEX, which is defined in the 165 Host Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX 166 preserves the protocol semantics as well as the general packet 167 structure of HIPv2. Hence, it is recommended that [RFC7401] is well- 168 understood before reading this document. 170 The main differences between HIP BEX and HIP DEX are: 172 1. HIP DEX uses a different set of cryptographic primitives compared 173 to HIP BEX with the goal to reduce the protocol overhead: 175 * Peer authentication and key agreement in HIP DEX are based on 176 static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This 177 replaces the use of public-key signatures and ephemeral 178 Diffie-Hellman key pairs in HIPv2. 180 * HIP DEX uses AES-CTR for symmetric-key encryption of HIP 181 payloads and AES-CMAC as its MACing function. In contrast, 182 HIPv2 currently supports AES-CBC for encryption and HMAC-SHA- 183 1, HMAC-SHA-256, or HMAC-SHA-384 for MACing. 185 * HIP DEX defines a simple fold function to efficiently generate 186 HITs, whereas the HIT generation of HIPv2 is based on SHA-1, 187 SHA-256, or SHA-384. 189 2. HIP DEX forfeits the HIPv2 Forward Secrecy property due to the 190 removal of the ephemeral Diffie-Hellman key agreement. As this 191 weakens the security properties of HIP DEX, it MUST be used only 192 with constrained devices where this is prohibitively expensive as 193 further explained in Section 1.2. 195 3. HIP DEX forfeits the use of digital signatures with the removal 196 of a hash function. Peer authentication with HIP DEX, therefore, 197 is based on the use of the ECDH derived key in the CMAC-based 198 HIP_MAC parameter. 200 4. The forfeiture of the use of digital signatures leaves the R1 201 packet open to a MITM attack. Such an attack is managed in the 202 R2 packet validation and is yet another DOS attack mitigated 203 through the HIP state machine. This state machine mitigation is 204 augmented by HIT,HI ACL controls, Section 7.1. 206 5. The forfeiture of a cryptographic hash leaves the HIT generated 207 by a fold function vulnerable to pre-image attacks. This MUST be 208 mitigated through a HIT,HI pairing as in an ACL control mechanism 209 Section 7.1. 211 6. With HIP DEX, the ECDH derived key is only used to protect HIP 212 packets. Separate session key(s) are used to protect the 213 transmission of upper layer protocol data. These session key(s) 214 are established via a new secret exchange during the handshake. 216 7. HIP DEX introduces a new, optional retransmission strategy that 217 is specifically designed to handle potentially extensive 218 processing times of the employed cryptographic operations on 219 computationally constrained devices. 221 By eliminating the need for public-key signatures and the ephemeral 222 DH key agreement, HIP DEX reduces the computational, energy, 223 transmission, and memory requirements for public-key cryptography 224 (see [LN08]) in the HIPv2 protocol design. This makes HIP DEX 225 especially suitable for constrained devices as defined in [RFC7228]. 227 Cryptographic hashing was eliminated due to the memory/code space or 228 gate cost for a hash. This is based on actual implementation efforts 229 on 8-bit CPU sensors with 16KB memory and 64KB flash for code. 231 This document focuses on the protocol specifications related to 232 differences between HIP BEX and HIP DEX. Where differences are not 233 called out explicitly, the protocol specification of HIP DEX is the 234 same as defined in [RFC7401]. 236 1.1. The HIP Diet EXchange (DEX) 238 The HIP Diet EXchange is a two-party cryptographic protocol used to 239 establish a secure communication context between hosts. The first 240 party is called the Initiator and the second party the Responder. 241 The four-packet exchange helps to make HIP DEX Denial of Service 242 (DoS) resilient. The Initiator and the Responder exchange their 243 static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2 244 handshake packet. The parties then authenticate each other in the I2 245 and R2 handshake packets based on the ECDH-derived keying material. 246 The Initiator and the Responder additionally transmit keying material 247 for the session key in these last two handshake packets (I2 and R2). 248 This is to prevent overuse of the static ECDH-derived keying 249 material. Moreover, the Responder starts a puzzle exchange in the R1 250 packet and the Initiator completes this exchange in the I2 packet 251 before the Responder performs computationally expensive operations or 252 stores any state from the exchange. Given this handshake structure, 253 HIP DEX operationally is very similar to HIP BEX. Moreover, the 254 employed model is also fairly equivalent to 802.11-2016 255 [IEEE.802-11.2016] Master Key and Pair-wise Transient Key, but 256 handled in a single exchange. 258 HIP DEX does not have the option to encrypt the Host Identity of the 259 Initiator in the I2 packet. The Responder's Host Identity also is 260 not protected. Thus, contrary to HIPv2, HIP DEX does not provide for 261 end-point anonymity and any signaling (i.e., HOST_ID parameter 262 contained with an ENCRYPTED parameter) that indicates such anonymity 263 should be ignored. 265 As in [RFC7401], data packets start to flow after the R2 packet. The 266 I2 and R2 packets may carry a data payload in the future. The 267 details of this may be defined later. 269 An existing HIP association can be updated with the update mechanism 270 defined in [RFC7401]. Likewise, the association can be torn down 271 with the defined closing mechanism for HIPv2 if it is no longer 272 needed. Standard HIPv2 uses a HIP_SIGNATURE to authenticate the 273 association close operation, but since DEX does not provide for 274 signatures, the usual per-message MAC suffices. 276 Finally, HIP DEX is designed as an end-to-end authentication and key 277 establishment protocol. As such, it can be used in combination with 278 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 279 end-to-end security protocols. In addition, HIP DEX can also be used 280 as a keying mechanism for security primitives at the MAC layer, e.g., 281 for IEEE 802.15.4 networks [IEEE.802-15-4.2015]. It is worth 282 mentioning that the HIP DEX base protocol does not cover all the 283 fine-grained policy control found in Internet Key Exchange Version 2 284 (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway 285 policies. Thus, HIP DEX is not a replacement for IKEv2. 287 1.2. Applicability 289 HIP DEX achieves its lightweight nature in large part due to the 290 intentional removal of Forward Secrecy (FS) from the key exchange. 291 Current mechanisms to achieve FS use an authenticated ephemeral 292 Diffie-Hellman exchange (e.g., SIGn-and-MAc Approach, SIGMA or 293 Password-Authenticated Key Agreement, PAKE). HIP DEX targets usage 294 on devices where even the most lightweight ECDH exchange is 295 prohibitively expensive for recurring (ephemeral) use. For example, 296 experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has 297 shown that EC25519 keypair generation exceeds 10 seconds and consumes 298 significant energy (i.e., battery resources). Even the ECDH 299 multiplication for the HIP DEX static-static key exchange takes 8-9 300 seconds, again with measurable energy consumption. The ECDH 301 multiplication resource consumption via a static EC25519 keypair is 302 tolerable as a one-time event during provisioning, but would render 303 the protocol unsuitable for use on these devices if it was required 304 to be a recurring part of the protocol. Further, for devices 305 constrained in this manner, a FS-enabled protocol's cost will likely 306 provide little gain. Since the resulting "FS" key, likely produced 307 during device deployment, would typically end up being used for the 308 remainder of the device's lifetime. Since this key (or the 309 information needed to regenerate it) persists for the device's 310 lifetime, the key step of 'throw away old keys' in achieving forward 311 secrecy does not occur, thus the forward secrecy would not be 312 obtained in practice. 314 With such a usage pattern, the inherent benefit of ephemeral keys is 315 not realized. The security properties of such usage are very similar 316 to those of using a statically provisioned symmetric pre-shared key, 317 in that there remains a single PSK in static storage that is 318 susceptible to exfiltration/compromise, and compromise of that key in 319 effect compromises the entire protocol for that node. HIP DEX 320 achieves marginally better security properties by computing the 321 effective long-term PSK from a DH exchange, so that the provisioning 322 service is not required to be part of the risk surface due to also 323 possessing the PSK. 325 If the device is not able to generate the ECDH keypair, the 326 provisioning service can generate and install the ECDH keypair 327 provided it wipes knowledge of the private key. Typically, the 328 provisioning service will make the public key (HI) and PSK available 329 for the deployment step. 331 Due to the substantially reduced security guarantees of HIP DEX 332 compared to HIP BEX, HIP DEX MUST only be used when at least one of 333 the two endpoints is a class 0 or 1 constrained device defined in 334 Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both 335 endpoints are class 2 devices or unconstrained. 337 It is inevitable that both HIP BEX and DEX will be available on some 338 systems, most noticeably sensor gateways. HIP DEX MUST NOT be used 339 between systems capable of HIP BEX. This may be controlled by 340 limiting the use of DEX to an "internal" interface, or for such 341 systems to first offer a BEX HIT in an I1 and only if that fails to 342 try a DEX HIT. Note that such a downgrade (from BEX to DEX) offer 343 approach is open to attack, requiring additional mitigation (e.g. 344 ACL controls). 346 1.2.1. Partial Computational Cost of FS via SIGMA 348 From the Initator's process, FS via SIGMA [SIGMA] in HIP BEX comes at 349 a prohibitive cost for constrained, 8-bit devices. In BEX, the 350 Initator has: 352 a. Public key operations 354 2 Public Key signing verifications, 356 1 Public Key signing, 358 b. Key generation 360 1 Diffie-Hellman ephemeral keypair generation, and 362 1 Diffie-Hellman shared secret generation. 364 Whereas HIP DEX only has the Diffie-Hellman shared secret generation 365 cost. 367 Papers like [EfficientECC] show on the ATmega328P [ATmega328P] an 368 EdDSA25519 signature generation of 19M cycles and verification of 31M 369 cycles. Thus the SIGMA Public Key operations come at a cost of 81M 370 cycles. Actual wallclock time and energy consumption are not 371 provided in this paper, nor is the Curve25519 keypair generation 372 time. 374 This is just the cost of the Public Key operations, excluding 375 additional BEX over DEX processing. The added cost of HIP BEX (over 376 HIP DEX) has been a blocking factor to adoption of SIGMA based key 377 establishment on 8-bit processors with limited power. 379 1.3. Memo Structure 381 The rest of this memo is structured as follows. Section 2 defines 382 the central keywords, notation, and terms used throughout this 383 document. Section 3 defines the structure of the Host Identity and 384 its various representations. Section 4 gives an overview of the HIP 385 Diet EXchange protocol. Sections 5 and 6 define the detailed packet 386 formats and rules for packet processing. Finally, Sections 7, 8, 9, 387 and 10 discuss policy, interoperability between HIPv2 vs DEX, 388 security, and IANA considerations, respectively. Appendix B defines 389 a two factor authentication scheme and Appendix C highlights some 390 discussions with the IESG. 392 2. Terms, Notation and Definitions 394 2.1. Requirements Terminology 396 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 397 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 398 "OPTIONAL" in this document are to be interpreted as described in BCP 399 14 [RFC2119] [RFC8174] when, and only when, they appear in all 400 capitals, as shown here. 402 2.2. Notation 404 [x] indicates that x is optional. 406 {x} indicates that x is encrypted. 408 X(y) indicates that y is a parameter of X. 410 i indicates that x exists i times. 412 --> signifies "Initiator to Responder" communication (requests). 414 <-- signifies "Responder to Initiator" communication (replies). 416 | signifies concatenation of information - e.g., X | Y is the 417 concatenation of X and Y. 419 FOLD (X, K) denotes the partitioning of X into n K-bit segments and 420 the iterative folding of these segments via XOR. I.e., X = x_1, 421 x_2, ..., x_n, where x_i is of length K and the last segment x_n 422 is padded to length K by appending 0 bits. FOLD then is computed 423 as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 425 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 426 the MAC function M on the input x. 428 sort (HIT-I | HIT-R) is defined as the network byte order 429 concatenation of the two HITs, with the smaller HIT preceding the 430 larger HIT, resulting from the numeric comparison of the two HITs 431 interpreted as positive (unsigned) 128-bit integers in network 432 byte order. 434 2.3. Definitions 436 CKDF: CMAC-based Key Derivation Function. 438 CMAC: The Cipher-based Message Authentication Code with the 128-bit 439 Advanced Encryption Standard (AES) defined in [NIST.SP.800-38B]. 441 HIP association: The shared state between two peers after completion 442 of the HIP handshake. 444 HIP DEX (Diet EXchange): The ECDH-based HIP handshake for 445 establishing a new HIP association. 447 HIT Suite: A HIT Suite groups all algorithms that are required to 448 generate and use an HI and its HIT. In particular for HIP DEX, 449 these algorithms are: 1) ECDH and 2) FOLD. 451 HI (Host Identity): The static ECDH public key that represents the 452 identity of the host. In HIP DEX, a host proves ownership of the 453 private key belonging to its HI by creating a HIP_MAC with the 454 derived ECDH key (see Section 3) in the appropriate I2 or R2 455 packet. 457 HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It 458 is generated by folding the HI (see Section 3). 460 Initiator: The host that initiates the HIP DEX handshake. This role 461 is typically forgotten once the handshake is completed. 463 KEYMAT: Keying material. That is, the bit string(s) used as 464 cryptographic keys. 466 RHASH_len: The natural output length of the RHASH Algorithm in bits. 468 Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE 469 parameter (see section 5.2.4 in [RFC7401]. It is also referred to 470 as "random value #I" in this document. 472 OGA (Orchid Generation Algorithm): Hash function used in generating 473 the ORCHID. 475 ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6 476 addresses intended to be used as endpoint identifiers at 477 applications and Application Programming Interfaces (APIs) and not 478 as identifiers for network location at the IP layer. 480 Puzzle difficulty K: The Initiator has to compute a solution for the 481 puzzle. The level of computational difficulty is denoted by the 482 #K field in the puzzle parameter (see section 5.2.4 in [RFC7401]. 484 Responder: The host that responds to the Initiator in the HIP DEX 485 handshake. This role is typically forgotten once the handshake is 486 completed. 488 RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is 489 redefined as CMAC. Still, note that CMAC is a message 490 authentication code (MAC) and not a cryptographic hash function. 491 Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where 492 RHASH is used. Moreover, RHASH has different security properties 493 in HIP DEX and is not used for HIT generation. 495 Security Association (SA): An SA is a simplex "connection" that 496 affords security services to the traffic carried by it. HIP DEX 497 has two forms of SAs, a Master Key SA for the actual HIP traffic, 498 and a Pair-wise Key SA for use by a data transport service. 500 3. Host Identity (HI) and its Structure 502 In this section, the properties of the Host Identity and Host 503 Identity Tag are discussed, and the exact format for them is defined. 504 In HIP, the public key of an asymmetric key pair is used as the Host 505 Identity (HI). Correspondingly, the host itself is defined as the 506 entity that holds the private key of the key pair. See the HIP 507 architecture specification [hip-rfc4423-bis] for more details on the 508 difference between an identity and the corresponding identifier. 510 HIP DEX implementations use Elliptic Curve Diffie-Hellman (ECDH) 511 [RFC6090] key exchange for generating the HI as defined in 512 Section 5.2.3. No alternative algorithms are defined at this time. 514 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 515 in the handshake packets to represent the HI. The DEX Host Identity 516 Tag (HIT) is different from the BEX HIT in two ways: 518 * The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). 520 * The DEX HIT is not generated via a cryptographic hash. Rather, it 521 is a compression of the HI. 523 Due to the latter property, an attacker may be able to find a 524 collision with a HIT that is in use. Hence, policy decisions such as 525 access control MUST NOT use an unverified HIT as input. The full HI 526 of a host SHOULD be considered, and the HIT MAY be used as a hint for 527 locating the full HI (see Section 7.1). 529 Carrying HIs or HITs in the header of user data packets would 530 increase the overhead of packets. Thus, it is not expected that 531 these parameters are carried in every packet, but other methods are 532 used to map the data packets to the corresponding HIs. In some 533 cases, this allows use of HIP DEX without any additional headers in 534 the user data packets. For example, if ESP is used to protect data 535 traffic, the Security Parameter Index (SPI) carried in the ESP header 536 can be used to map the encrypted data packet to the correct HIP DEX 537 association. When other user data packet formats are used, the 538 corresponding extensions need to define a replacement for the 539 ESP_TRANSFORM [RFC7402] parameter along with associated semantics, 540 but this procedure is outside the scope of this document. 542 3.1. Host Identity Tag (HIT) 544 With HIP DEX, the HIT is a 128-bit value - a compression of the HI 545 prepended with a specific prefix. There are two advantages of using 546 this compressed encoding over the actual variable-sized public key in 547 protocols. First, the fixed length of the HIT keeps packet sizes 548 manageable and eases protocol coding. Second, it presents a 549 consistent format for the protocol, independent of the underlying 550 identity technology in use. 552 The structure of the HIT is based on RFC 7343 [RFC7343], called 553 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 554 consists of three parts: first, an IANA assigned prefix to 555 distinguish it from other IPv6 addresses. Second, a four-bit 556 encoding of the algorithms that were used for generating the HI and 557 the compressed representation of the HI. Third, the 96-bit 558 compressed representation of the HI. In contrast to HIPv2, HIP DEX 559 employs HITs that are NOT generated by means of a cryptographic hash. 560 Instead, the HI is compressed to 96 bits as defined in the following 561 section. 563 3.2. Generating a HIT from an HI 565 The HIT does not follow the exact semantics of an ORCHID as there is 566 no hash function in HIP DEX. Still, its structure is strongly 567 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 568 is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used 569 for the four bits of the Orchid Generation Algorithm (OGA) field in 570 the ORCHID. The hash representation in an ORCHID is replaced with 571 FOLD((Context ID | HI),96) see Section 2.2 for the FOLD function. 572 The Context ID is the same as in HIP BEX, sec 3.2 RFC 7401 [RFC7401]. 574 3.2.1. Why Introduce FOLD 576 HIP DEX by design lacks a cryptographic hash function. The 577 generation of the HIT is one of the few places in the protocol where 578 this presents a challenge. CMAC was first considered for this 579 purpose, but to use CMAC for HIT generation would require using a 580 static key, either ZERO or some published value. NIST does not 581 consider CMAC an approved cryptographic hash as: 583 It is straightforward to demonstrate that CMAC is not collision- 584 resistant for any choice of a published key. 586 Since collision-resistance is not possible with the tools at hand, 587 any reasonable function (e.g. FOLD) that takes the full value of the 588 HI into generating the HIT can be used, provided that collision 589 detection is part of the HIP-DEX deployment design. This is achieved 590 here through either an ACL, Section 7.1, or some other lookup process 591 that externally binds the HIT and HI. 593 Even without collision-resistance, it is not trivial to create 594 duplicate FOLD generated HITs, as FOLD is starting out with a random 595 input (the HI). Although there is a set, {N}, of HIs that will have 596 duplicate FOLD HITs, even randomly generating duplicate HITs is 597 unlikely. Per Appendix A, 4T BEX HITs need be generated for a .01% 598 probability of a collision. The size of set above is not known, but 599 will not be large. In a test of 1M randomly generated FOLD HITs, no 600 duplicates were produced. 602 Note that HIT collisions have always been a statistical possibility 603 in BEX and thus the HI has always been a part of the R1 and I2 604 packets for HI validation. 606 4. Protocol Overview 608 This section gives a simplified overview of the HIP DEX protocol 609 operation and does not contain all the details of the packet formats 610 or the packet processing steps. Section 5 and Section 6 describe 611 these aspects in more detail and are normative in case of any 612 conflicts with this section. Importantly, the information given in 613 this section focuses on the differences between the HIPv2 and HIP DEX 614 protocol specifications. 616 4.1. Creating a HIP Association 618 By definition, the system initiating a HIP Diet EXchange is the 619 Initiator, and the peer is the Responder. This distinction is 620 typically forgotten once the handshake completes, and either party 621 can become the Initiator in future communications. 623 The HIP Diet EXchange serves to manage the establishment of state 624 between an Initiator and a Responder. The first packet, I1, 625 initiates the exchange, and the last three packets, R1, I2, and R2, 626 constitute an authenticated Diffie-Hellman [DH76] key exchange for 627 the Master Key Security Association (SA) generation. This Master Key 628 SA is used by the Initiator and the Responder to wrap secret keying 629 material in the I2 and R2 packets. Based on the exchanged keying 630 material, the peers then derive a Pair-wise Key SA if cryptographic 631 keys are needed, e.g., for ESP-based protection of user data. 633 The Initiator first sends a trigger packet, I1, to the Responder. 634 This packet contains the HIT of the Initiator and the HIT of the 635 Responder, if it is known. Moreover, the I1 packet initializes the 636 negotiation of the Diffie-Hellman group that is used for generating 637 the Master Key SA by including a list of Diffie-Hellman Group IDs 638 supported by the Initiator. 640 The second packet, R1, starts the actual authenticated Diffie-Hellman 641 key exchange. It contains a puzzle - a cryptographic challenge that 642 the Initiator must solve before continuing the exchange. The level 643 of difficulty of the puzzle can be adjusted based on level of 644 knowledge of the Initiator, current load, or other factors. In 645 addition, the R1 contains the Responder's Diffie-Hellman parameter 646 and lists of cryptographic algorithms supported by the Responder. 647 Based on these lists, the Initiator can continue, abort, or restart 648 the handshake with a different selection of cryptographic algorithms. 650 Unlike in HIP BEX, the R1 packet in DEX is not signed. Thus the 651 Initiator MUST compare the content of R1 with that it later gets in 652 R2 to ensure there was no MITM attack on R1. 654 In the I2 packet, the Initiator MUST display the solution to the 655 received puzzle. Without a correct solution, the I2 packet is 656 discarded. The I2 also contains a nonce and key wrap parameter that 657 carries secret keying material of the Initiator. This keying 658 material is only half of the final session (pair-wise) key. The 659 packet is authenticated by the sender (Initiator) via a MAC. 661 The R2 packet acknowledges the receipt of the I2 packet and completes 662 the handshake. The R2 echos the nonce from I2 and contains a key 663 wrap parameter that carries the rest of the keying material of the 664 Responder. The packet is authenticated by the sender (Responder) via 665 a MAC. The R2 repeats the lists from R1 for signed validation to 666 defend them against a MITM attack. 668 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 669 and "ENC(DH,y)" refer to the random values x and y that are wrapped 670 based on the Master Key SA (indicated by ENC and DH). Note that x 671 and y each constitute half of the final session key material. The 672 packets also contain other parameters that are not shown in this 673 figure. 675 Initiator Responder 677 I1: DH List 678 --------------------------------------> 680 remain stateless 682 R1: puzzle, (DH, Suite, Trans) Lists, 683 HI 684 <------------------------------------- 686 solve puzzle 687 perform ECDH 688 encrypt x 690 I2: solution, HI, ENC(DH,x), Trans List, 691 I_Nonce, mac 692 --------------------------------------> 694 check puzzle 695 perform ECDH 696 check MAC 697 decrypt x 698 encrypt y 700 R2: (DH, Suite, Trans) Lists, ENC(DH,y), 701 I_Nonce, mac 702 <-------------------------------------- 704 check MAC 705 validate lists in R1 706 decrypt y 708 Figure 1: High-level overview of the HIP Diet EXchange 710 4.1.1. HIP Puzzle Mechanism 712 The purpose of the HIP puzzle mechanism is to protect the Responder 713 from a number of denial-of-service threats. It allows the Responder 714 to delay state creation until receiving the I2 packet. Furthermore, 715 the puzzle allows the Responder to use a fairly cheap calculation to 716 check that the Initiator is "sincere" in the sense that it has 717 churned enough CPU cycles in solving the puzzle. 719 The puzzle mechanism enables a Responder to immediately reject an I2 720 packet if it does not contain a valid puzzle solution. To verify the 721 puzzle solution, the Responder only has to compute a single CMAC 722 operation. After a successful puzzle verification, the Responder can 723 securely create session-specific state and perform CPU-intensive 724 operations such as a Diffie-Hellman key generation. By varying the 725 difficulty of the puzzle, the Responder can frustrate CPU or memory 726 targeted DoS attacks. Under normal network conditions, the puzzle 727 difficulty SHOULD be zero, thus effectively reverting the puzzle 728 mechanism to a cookie-based DoS protection mechanism. Without 729 setting the puzzle difficulty to zero under normal network 730 conditions, potentially scarce computation resources at the Initiator 731 would be churned unnecessarily. 733 Conceptually, the puzzle mechanism in HIP DEX is the same as in 734 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 735 [RFC7401] for more detailed information about the employed mechanism. 736 Notably, the only differences between the puzzle mechanism in HIP DEX 737 and HIPv2 are that HIP DEX does not employ pre-computation of R1 738 packets and uses CMAC instead of a hash function for solving and 739 verifying a puzzle. The implications of these changes on the puzzle 740 implementation are discussed in Section 6.1. 742 4.1.2. HIP State Machine 744 The HIP DEX state machine has the same states as the HIPv2 state 745 machine (see Section 4.4. in [RFC7401]); this is for easier 746 comparison between the two Exchanges. However, HIP DEX features a 747 retransmission strategy with an optional reception acknowledgement 748 for the I2 packet. The goal of this additional acknowledgement is to 749 reduce premature I2 retransmissions in case of devices with low 750 computation resources [HWZ13]. As a result, there are minor changes 751 regarding the transitions in the HIP DEX state machine. The 752 following section documents these differences compared to HIPv2. 754 4.1.2.1. HIP DEX Retransmission Mechanism 756 For the retransmission of I1 and I2 packets, the Initiator adopts the 757 retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). 758 This strategy is based on a timeout that is set to a value larger 759 than the worst-case anticipated round-trip time (RTT). For each 760 received I1 or I2 packet, the Responder sends an R1 or R2 packet, 761 respectively. This design trait to always send an R1 after an I1 762 enables the Responder to remain stateless until the reception and 763 successful processing of the I2 packet. The Initiator stops 764 retransmitting I1 or I2 packets after the reception of the 765 corresponding R1 or R2. If the Initiator did not receive an R1 766 packet after I1_RETRIES_MAX tries, it stops I1 retransmissions. 767 Likewise, it stops retransmitting the I2 packet after I2_RETRIES_MAX 768 unsuccessful tries. 770 For repeatedly received I2 packets, the Responder SHOULD NOT perform 771 operations related to the Diffie-Hellman key exchange or the keying 772 material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD 773 re-use the previously established state to re-create the 774 corresponding R2 packet in order to prevent unnecessary computation 775 overhead. 777 The potentially high processing time of an I2 packet at a (resource- 778 constrained) Responder may cause premature retransmissions if the 779 time required for I2 transmission and processing exceeds the RTT- 780 based retransmission timeout. Thus, the Initiator should also take 781 the processing time of the I2 packet at the Responder into account 782 for retransmission purposes. To this end, the Responder MAY notify 783 the Initiator about the anticipated delay once the puzzle solution 784 was successfully verified that the remaining I2 packet processing 785 will incur a high processing delay. The Responder MAY therefore send 786 a NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator 787 before the Responder commences the ECDH operation. The NOTIFY packet 788 serves as an acknowledgement for the I2 packet and consists of a 789 NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 790 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 791 contains the anticipated remaining processing time for the I2 packet 792 in milliseconds as two-octet Notification Data. This processing time 793 can, e.g., be estimated by measuring the computation time of the ECDH 794 key derivation operation during the Responder start-up procedure. 795 After the I2 processing has finished, the Responder sends the regular 796 R2 packet. 798 When the Initiator receives the NOTIFY packet, it sets the I2 799 retransmission timeout to the I2 processing time indicated in the 800 NOTIFICATION parameter plus half the RTT-based timeout value. In 801 doing so, the Initiator MUST NOT set the retransmission timeout to a 802 higher value than allowed by a local policy. This is to prevent 803 unauthenticated NOTIFY packets from maliciously delaying the 804 handshake beyond a well-defined upper bound in case of a lost R2 805 packet. At the same time, this extended retransmission timeout 806 enables the Initiator to defer I2 retransmissions until the point in 807 time when the Responder should have completed its I2 packet 808 processing and the network should have delivered the R2 packet 809 according to the employed worst-case estimates. 811 4.1.2.2. HIP State Processes 813 HIP DEX clarifies or introduces the following new transitions. 815 System behavior in state I2-SENT, Table 1. 817 +=================+===============================================+ 818 | Trigger | Action | 819 +=================+===============================================+ 820 | Receive NOTIFY, | Set I2 retransmission timer to value in | 821 | process | I2_ACKNOWLEDGEMENT Notification Data plus 1/2 | 822 | | RTT-based timeout value and stay at I2-SENT | 823 +-----------------+-----------------------------------------------+ 824 +-----------------+-----------------------------------------------+ 825 | Timeout | Increment trial counter | 826 +-----------------+-----------------------------------------------+ 827 +-----------------+-----------------------------------------------+ 828 | | If counter is less than I2_RETRIES_MAX, send | 829 | | I2, reset timer to RTT-based timeout, and | 830 | | stay at I2-SENT | 831 +-----------------+-----------------------------------------------+ 832 +-----------------+-----------------------------------------------+ 833 | | If counter is greater than I2_RETRIES_MAX, go | 834 | | to E-FAILED | 835 +-----------------+-----------------------------------------------+ 837 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 839 4.1.2.3. Simplified HIP State Diagram 841 The following diagram shows the major state transitions. Transitions 842 based on received packets implicitly assume that the packets are 843 successfully authenticated or processed. 845 +--+ +----------------------------+ 846 recv I1, send R1 | | | | 847 | v v | 848 +--------------+ recv I2, send R2 | 849 +----------------| UNASSOCIATED |----------------+ | 850 datagram | +--+ +--------------+ | | 851 to send, | | | Alg. not supported, | | 852 send I1 | | | send I1 | | 853 . v | v | | 854 . +---------+ recv I2, send R2 | | 855 +---->| I1-SENT |--------------------------------------+ | | 856 | +---------+ +----------------------+ | | | 857 | | recv R1, | recv I2, send R2 | | | | 858 | v send I2 | v v v | 859 | +---------+----------+ +---------+ | 860 | +--->| I2-SENT |<-------------+ +------------| R2-SENT |<---+ | 861 | | +---------+ recv NOTIFY, | | +---------+ | | 862 | | | | | reset timer | | data or| | | 863 | |recv R1, | | +--------------+ | EC timeout| | | 864 | |send I2 +-|--------------------+ | receive I2,| | 865 | | | | +-------------+ | send R2| | 866 | | | +-------->| ESTABLISHED |<---------+ | | 867 | | | recv R2 +-------------+ | | 868 | | | | | | receive I2, send R2 | | 869 | | +------------+ | +-------------------------------+ | 870 | | | +-----------+ | | 871 | | | no packet sent/received| +---+ | | 872 | | | for UAL min, send CLOSE| | |timeout | | 873 | | | v v |(UAL+MSL) | | 874 | | | +---------+ |retransmit | | 875 +--|----------|------------------------| CLOSING |-+CLOSE | | 876 | | +---------+ | | 877 | | | | | | | | 878 +----------|-------------------------+ | | +----------------+ | 879 | | +-----------+ +------------------|--+ 880 | | |recv CLOSE, recv CLOSE_ACK | | 881 | +-------------+ |send CLOSE_ACK or timeout | | 882 | recv CLOSE, | | (UAL+MSL) | | 883 | send CLOSE_ACK v v | | 884 | +--------+ receive I2, send R2 | | 885 +---------------------| CLOSED |------------------------------+ | 886 +--------+ | 887 ^ | | | 888 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 889 +-+ +------------------------------------+ 891 4.1.3. HIP DEX Security Associations 893 HIP DEX establishes two Security Associations (SA), one for the 894 Diffie-Hellman derived key, or Master Key, and one for the session 895 key, or Pair-wise Key. 897 4.1.3.1. Master Key SA 899 The Master Key SA is used to authenticate HIP packets and to encrypt 900 selected HIP parameters in the HIP DEX packet exchanges. Since only 901 a small amount of data is protected by this SA, it can be long-lived 902 with no need for rekeying. At the latest, the system MUST initiate 903 rekeying when its incoming ESP sequence counter is going to overflow, 904 and the system MUST NOT replace its keying material until the 905 rekeying packet exchange successfully completes as described in 906 Section 6.8 in [RFC7402]. 908 The Master Key SA contains the following elements: 910 * Source HIT 912 * Destination HIT 914 * HIP_Encrypt Key 916 * HIP_MAC Key 918 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 919 Hellman derived key as described in Section 6.3. Their length is 920 determined by the HIP_CIPHER. 922 4.1.3.2. Pair-wise Key SA 924 The Pair-wise Key SA is used to authenticate and to encrypt user 925 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 926 The Pair-wise Key SA elements are defined by the data transform 927 (e.g., ESP_TRANSFORM [RFC7402]). 929 The keys for the Pair-wise Key SA are derived based on the wrapped 930 keying material exchanged in the ENCRYPTED_KEY parameter (see 931 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 932 keying material of the two peers is concatenated. This concatenation 933 forms the input to a Key Derivation Function (KDF). If the data 934 transform does not specify its own KDF, the key derivation function 935 defined in Section 6.3 is used. Even though the concatenated input 936 is randomly distributed, a KDF Extract phase may be needed to get the 937 proper length for the input to the KDF Expand phase. 939 4.1.4. User Data Considerations 941 The User Data Considerations in Section 4.5. of [RFC7401] also apply 942 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 943 Loss of state due to system reboot may be a critical performance 944 issue for resource-constrained devices. Thus, implementors MAY 945 choose to use non-volatile, secure storage for HIP states in order 946 for them to survive a system reboot as discussed in Section 6.11. 947 Using non-volatile storage will limit state loss during reboots to 948 only those situations with an SA timeout. 950 5. Packet Formats 952 5.1. Payload Format 954 HIP DEX employs the same fixed HIP header and payload structure as 955 HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also 956 apply to HIP DEX. 958 5.2. HIP Parameters 960 The HIP parameters carry information that is necessary for 961 establishing and maintaining a HIP association. For example, the 962 peer's public keys as well as the signaling for negotiating ciphers 963 and payload handling are encapsulated in HIP parameters. Additional 964 information, meaningful for end-hosts or middleboxes, may also be 965 included in HIP parameters. The specification of the HIP parameters 966 and their mapping to HIP packets and packet types is flexible to 967 allow HIP extensions to define new parameters and new protocol 968 behavior. 970 In HIP packets, HIP parameters are ordered according to their numeric 971 type number and encoded in TLV format. 973 HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of 974 [RFC7401] where possible. Still, HIP DEX further restricts and/or 975 extends the following existing parameter types: 977 * DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 979 * HIP_CIPHER is restricted to AES-128-CTR. 981 * HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. 983 * PUZZLE, SOLUTION, and HIP_MAC parameter processing is altered to 984 support CMAC in RHASH and RHASH_len (see Section 6.1 and 985 Section 6.2). 987 In addition, HIP DEX introduces the following new parameters: 989 +===============+=================+==========+=====================+ 990 | TLV | Type | Length | Data | 991 +===============+=================+==========+=====================+ 992 | ENCRYPTED_KEY | TBD1 (suggested | variable | Encrypted container | 993 | | value 643) | | for the session key | 994 | | | | exchange | 995 +---------------+-----------------+----------+---------------------+ 996 | I_NONCE | TBD6 (suggested | variable | Nonce from Initator | 997 | | value 644) | | for Master Key | 998 +---------------+-----------------+----------+---------------------+ 1000 Table 2 1002 5.2.1. DH_GROUP_LIST 1004 The DH_GROUP_LIST parameter contains the list of supported DH Group 1005 IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With 1006 HIP DEX, the DH Group IDs are restricted to: 1008 Group KDF Value 1010 Curve25519 [RFC7748] CKDF TBD7 (suggested value 12) 1011 Curve448 [RFC7748] CKDF TBD8 (suggested value 13) 1013 The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748]. 1014 These curves have cofactors of 8 and 4 (respectively). 1016 It is not known if Curve448 Diffie Hellman can meet the performance 1017 requirements on 8-bit CPUs. It is included for "completeness". An 1018 implementor should ensure they can get the needed performance for 1019 their target platform before committing to support this group. 1021 5.2.2. HIP_CIPHER 1023 The HIP_CIPHER parameter contains the list of supported cipher 1024 algorithms to be used for encrypting the contents of the ENCRYPTED 1025 and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 1026 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited 1027 to: 1029 Suite ID Value 1031 RESERVED 0 1032 AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) 1033 Mandatory implementation: AES-128-CTR. 1035 The counter for AES-128-CTR MUST have a length of 128 bits. The 1036 puzzle value #I and the puzzle solution #J (see Section 4.1.2 in 1037 [RFC7401]) are used to construct the initialization vector (IV) as 1038 FOLD(I | J, 112) which are the high-order bits of the CTR counter. A 1039 16 bit value as a block counter, which is initialized to zero on 1040 first use, is appended to the IV in order to guarantee that a non- 1041 repeating nonce is fed to the AES-CTR encryption algorithm. 1043 This counter is incremented as it is used for all encrypted HIP 1044 parameters. That is a single AES-129-CTR counter associated with the 1045 Master Key SA. 1047 5.2.3. HOST_ID 1049 The HOST_ID parameter conveys the Host Identity (HI) along with 1050 optional information about a host. The HOST_ID parameter is defined 1051 in Section 5.2.9 of [RFC7401]. 1053 HIP DEX uses the public portion of a host's static ECDH key-pair as 1054 the HI. Correspondingly, HIP DEX limits the HI algorithms to the 1055 following new profile: 1057 Algorithm profiles Value 1059 ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) 1061 For hosts that implement ECDH as the algorithm, the following curves 1062 are required: 1064 Group Value 1066 Curve25519 5 [RFC7748] 1067 Curve448 6 [RFC7748] 1069 HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 1070 Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is 1071 encoded in the "ECC curve" field of the HOST_ID parameter. The 1072 supported DH Group IDs are defined in Section 5.2.1. 1074 5.2.4. HIT_SUITE_LIST 1076 The HIT_SUITE_LIST parameter contains a list of the supported HIT 1077 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 1078 Initiator can determine which source HIT Suite IDs are supported by 1079 the Responder. The HIT_SUITE_LIST parameter is defined in 1080 Section 5.2.10 of [RFC7401]. 1082 The following new HIT Suite ID is defined for HIP DEX, and the 1083 relationship between the four-bit ID value used in the OGA ID field 1084 and the eight-bit encoding within the HIT_SUITE_LIST ID field is 1085 clarified: 1087 HIT Suite Four-bit ID Eight-bit encoding 1089 ECDH/FOLD TBD2 (suggestion: 4) TBD3 (suggestion: 0x40) 1091 Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field 1092 allows the peers to distinguish a HIP DEX handshake from a HIPv2 1093 handshake. The Responder MUST respond with a HIP DEX HIT suite ID 1094 when the HIT of the Initiator is a HIP DEX HIT. 1096 5.2.5. ENCRYPTED_KEY 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Type | Length | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 / Encrypted value / 1104 / / 1105 / +-------------------------------+ 1106 / | Padding | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Type TBD1 (suggested value 643) 1110 Length length in octets, excluding Type, Length, and 1111 Padding 1112 Encrypted The value is encrypted using an encryption algorithm 1113 value as defined in the HIP_CIPHER parameter. 1115 The ENCRYPTED_KEY parameter encapsulates a random value that is later 1116 used in the session key creation process (see Section 6.3). This 1117 random value MUST have a length of at least 64 bits. The HIP_CIPHER 1118 is used for the encryption. 1120 Once this encryption process is completed, the "encrypted value" data 1121 field is ready for inclusion in the Parameter. If necessary, 1122 additional Padding for 8-byte alignment is then added according to 1123 the rules of TLV Format in [RFC7401]. 1125 5.2.6. I_NONCE 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Type | Length | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 / Initiator Nonce / 1133 / / 1134 / +-------------------------------+ 1135 / | Padding | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 Type TBD6 (suggested value 644) 1139 Length length in octets, excluding Type, Length, and 1140 Padding 1141 Initiator Nonce provided by the Initiator for use in the 1142 Nonce Master Key 1144 The I_NONCE parameter encapsulates a random value that is later used 1145 in the Master key creation process (see Section 6.3). This random 1146 value MUST have a length of 2 x RHASH_len. This parameter is sent to 1147 the Responder in I2 which echos it back to the Initiator in R2. 1149 If necessary, additional Padding for 8-byte alignment is added 1150 according to the rules of TLV Format in [RFC7401]. 1152 5.3. HIP Packets 1154 HIP DEX uses the same eight basic HIP packets as HIPv2 (see 1155 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake 1156 (I1, R1, I2, and R2), one is for updating an association (UPDATE), 1157 one is for sending notifications (NOTIFY), and two are for closing 1158 the association (CLOSE and CLOSE_ACK). There are some differences 1159 regarding the HIP parameters that are included in the handshake 1160 packets concerning HIP BEX and HIP DEX. This section covers these 1161 differences for the DEX packets. Packets not discussed here, follow 1162 the structure defined in [RFC7401]. 1164 An important difference between packets in HIP BEX and HIP DEX is 1165 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 1166 included in HIP DEX. Thus, the R1 packet is completely unprotected 1167 and can be spoofed. As a result, negotiation parameters contained in 1168 the R1 packet have to be re-included in later, protected packets in 1169 order to detect and prevent potential downgrading attacks. Moreover, 1170 the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not 1171 covered by a signature and purely rely on the HIP_MAC parameter for 1172 packet authentication. The processing of these packets is changed 1173 accordingly. 1175 In the future, an optional upper-layer payload MAY follow the HIP 1176 header. The Next Header field in the header indicates if there is 1177 additional data following the HIP header. 1179 5.3.1. I1 - the HIP Initiator Packet 1181 The HIP header values for the I1 packet: 1183 Header: 1184 Packet Type = 1 1185 SRC HIT = Initiator's HIT 1186 DST HIT = Responder's HIT, or NULL 1188 IP ( HIP ( DH_GROUP_LIST ) ) 1190 Valid control bits: none 1192 The I1 packet contains the fixed HIP header and the Initiator's 1193 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 1194 type as defined in Section 5.2.4. 1196 Regarding the Responder's HIT, the Initiator may receive this HIT 1197 either from a DNS lookup of the Responder's FQDN (see [RFC8005]), 1198 from some other repository, or from a local table. The Responder's 1199 HIT also MUST be of a HIP DEX type. If the Initiator does not know 1200 the Responder's HIT, it may attempt to use opportunistic mode by 1201 using NULL (all zeros) as the Responder's HIT. See Section 4.1.8 of 1202 [RFC7401] for detailed information about the "HIP Opportunistic 1203 Mode". 1205 As the Initiator's and the Responder's HITs are compressions of the 1206 employed HIs, they determine the DH Group ID that must be used in 1207 order to successfully conclude the triggered handshake. HITs, 1208 however, only include the OGA ID identifying the HI algorithm. They 1209 do not include information about the specific group ID of the HI. To 1210 inform the Responder about its employed and its otherwise supported 1211 DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST 1212 parameter in the I1 packet. This parameter MUST include the DH group 1213 ID that corresponds to the currently employed Initiator HIT as the 1214 first list element. With HIP DEX, the DH_GROUP_LIST parameter MUST 1215 only include ECDH groups defined in Section 5.2.1. 1217 Since this packet is so easy to spoof even if it were protected, no 1218 attempt is made to add to its generation or processing cost. As a 1219 result, the DH_GROUP_LIST in the I1 packet is not protected. 1221 Implementations MUST be able to handle a storm of received I1 1222 packets, discarding those with common content that arrive within a 1223 small time delta. 1225 5.3.2. R1 - the HIP Responder Packet 1227 The HIP header values for the R1 packet: 1229 Header: 1230 Packet Type = 2 1231 SRC HIT = Responder's HIT 1232 DST HIT = Initiator's HIT 1234 IP ( HIP ( [ R1_COUNTER, ] 1235 PUZZLE, 1236 DH_GROUP_LIST, 1237 HIP_CIPHER, 1238 HOST_ID, 1239 HIT_SUITE_LIST, 1240 TRANSPORT_FORMAT_LIST, 1241 [ <, ECHO_REQUEST_UNSIGNED >i ]) 1243 Valid control bits: none 1245 The Initiator's HIT MUST match the one received in the I1 packet if 1246 the R1 is a response to an I1. If the Responder has multiple HIs, 1247 the Responder's HIT MUST match the Initiator's request. If the 1248 Initiator used opportunistic mode, the Responder may select among its 1249 HIs as described below. See Section 4.1.8 of [RFC7401] for detailed 1250 information about the "HIP Opportunistic Mode". 1252 The R1 packet generation counter is used to determine the currently 1253 valid generation of puzzles. The value is increased periodically, 1254 and it is RECOMMENDED that it is increased at least as often as 1255 solutions to old puzzles are no longer accepted. 1257 The Puzzle contains a Random value #I and the puzzle difficulty K. 1258 The difficulty K indicates the number of lower-order bits, in the 1259 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 1260 SHOULD set K to zero by default and only increase the puzzle 1261 difficulty to protect against a DoS attack targeting the HIP DEX 1262 handshake. A puzzle difficulty of zero effectively turns the puzzle 1263 mechanism into a return-routability test and is strongly encouraged 1264 during normal operation in order to conserve energy resources as well 1265 as to prevent unnecessary handshake delay in case of a resource- 1266 constrained Initiator. Please also refer to Section 7 for further 1267 recommendations on choosing puzzle difficulty. 1269 The HIP_CIPHER contains the encryption algorithms supported by the 1270 Responder to protect the key exchange, in the order of preference. 1271 All implementations MUST support the AES-CTR [RFC3686]. 1273 The DH_GROUP_LIST parameter contains the Responder's order of 1274 preference based on the Responder's choice the ECDH key contained in 1275 the HOST_ID parameter (see below). This allows the Initiator to 1276 begin to determine whether its own DH_GROUP_LIST in the I1 packet was 1277 manipulated by an attacker. There is a further risk that the 1278 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 1279 packet cannot be authenticated in HIP DEX. Thus, this parameter is 1280 repeated in the R2 packet to allow for a final, cryptographically 1281 secured validation. 1283 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 1284 supported and preferred HIT Suites. It enables a Responder to notify 1285 the Initiator about other available HIT suites than the one used in 1286 the current handshake. Based on the received HIT_SUITE_LIST, the 1287 Initiator MAY decide to abort the current handshake and initiate a 1288 new handshake with a different mutually supported HIT suite. This 1289 mechanism can, e.g., be used to move from an initial HIP DEX 1290 handshake to a HIP BEX handshake for peers supporting both protocol 1291 variants. 1293 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 1294 and the Responder HIT in the I1 packet. Specifically, if the I1 1295 contains a Responder HIT, the Responder verifies that this HIT 1296 matches the preferred DH group based on the received DH_GROUP_LIST 1297 parameter included in the I1. In case of a positive result, the 1298 Responder selects the corresponding HOST_ID for inclusion in the R1 1299 packet. Likewise, if the Responder HIT in the I1 packet is NULL 1300 (i.e., during an opportunistic handshake), the Responder chooses its 1301 HOST_ID according to the Initiator's employed DH group as indicated 1302 in the received DH_GROUP_LIST parameter and sets the source HIT in 1303 the R1 packet accordingly. If the Responder however does not support 1304 the DH group required by the Initiator or if the Responder HIT in the 1305 I1 packet does not match the required DH group, the Responder selects 1306 the mutually preferred and supported DH group based on the 1307 DH_GROUP_LIST parameter in the I1 packet. The Responder then 1308 includes the corresponding ECDH key in the HOST_ID parameter. This 1309 parameter also indicates the selected DH group. Moreover, the 1310 Responder sets the source HIT in the R1 packet based on the 1311 destination HIT from the I1 packet. Based on the deviating DH group 1312 ID in the HOST_ID parameter, the Initiator then MUST abort the 1313 current handshake and SHOULD initiate a new handshake with the 1314 mutually supported DH group as far as local policies (see Section 7) 1315 permit. 1317 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 1318 Responder's supported and preferred transport format types. The list 1319 allows the Initiator and the Responder to agree on a common type for 1320 payload protection. The different format types are DEFAULT, ESP 1321 (Mandatory to Implement) and ESP-TCP (Experimental, as explained in 1322 Section 3.1 in [RFC6261]). 1324 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 1325 wants to receive unmodified in the corresponding response packet in 1326 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 1327 or more ECHO_REQUEST_UNSIGNED parameters. 1329 5.3.3. I2 - the Second HIP Initiator Packet 1331 The HIP header values for the I2 packet: 1333 Header: 1334 Type = 3 1335 SRC HIT = Initiator's HIT 1336 DST HIT = Responder's HIT 1338 IP ( HIP ( [R1_COUNTER,] 1339 SOLUTION, 1340 HIP_CIPHER, 1341 ENCRYPTED_KEY, 1342 HOST_ID, 1343 TRANSPORT_FORMAT_LIST, 1344 I_NONCE, 1345 HIP_MAC 1346 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1348 Valid control bits: none 1350 The HITs MUST match the ones used in the R1 packet. 1352 If present in the R1 packet, the Initiator MUST include an unmodified 1353 copy of the R1_COUNTER parameter into the I2 packet. 1355 The Solution contains the Random #I from the R1 packet and the 1356 computed #J value. The low-order #K bits of the RHASH(I | ... | J) 1357 MUST be zero. 1359 The HIP_CIPHER contains the single encryption transform selected by 1360 the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY 1361 parameters. The chosen cipher MUST correspond to one of the ciphers 1362 offered by the Responder in the R1. All implementations MUST support 1363 the AES-CTR transform [RFC3686]. 1365 The HOST_ID parameter contains the Initiator HI corresponding to the 1366 Initiator HIT. 1368 The ENCRYPTED_KEY parameter contains an Initiator generated random 1369 value that MUST be uniformly distributed. This random value is 1370 encrypted with the Master Key SA using the HIP_CIPHER encryption 1371 algorithm. 1373 The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque 1374 data copied from the corresponding echo request parameter(s). This 1375 parameter can also be used for two-factor password authentication as 1376 shown in Appendix B. 1378 The TRANSPORT_FORMAT_LIST parameter contains the single transport 1379 format type selected by the Initiator. The chosen type MUST 1380 correspond to one of the types offered by the Responder in the R1 1381 packet. The different format types are DEFAULT, ESP and ESP-TCP as 1382 explained in Section 3.1 in [RFC6261]. 1384 The I_NONCE parameter contains the nonce, supplied by the Initiator 1385 for the Master Key generation as shown in Section 6.3. This is 1386 echoed back to the Initiator in the R2 packet. 1388 The MAC is calculated over the whole HIP envelope, excluding any 1389 parameters after the HIP_MAC parameter as described in Section 6.2. 1390 The Responder MUST validate the HIP_MAC parameter. 1392 5.3.4. R2 - the Second HIP Responder Packet 1394 The HIP header values for the R2 packet: 1396 Header: 1397 Packet Type = 4 1398 SRC HIT = Responder's HIT 1399 DST HIT = Initiator's HIT 1401 IP ( HIP ( DH_GROUP_LIST, 1402 HIP_CIPHER, 1403 ENCRYPTED_KEY, 1404 HIT_SUITE_LIST, 1405 TRANSPORT_FORMAT_LIST, 1406 I_NONCE, 1407 HIP_MAC) 1409 Valid control bits: none 1411 The HITs used MUST match the ones used in the I2 packet. 1413 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1414 and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These 1415 parameters MUST be the same as included in the R1 packet. The 1416 parameter are re-included here because the R2 packet is MACed and 1417 thus cannot be altered by an attacker. For verification purposes, 1418 the Initiator re-evaluates the selected suites and compares the 1419 results against the chosen ones. If the re-evaluated suites do not 1420 match the chosen ones, the Initiator acts based on its local policy. 1422 The ENCRYPTED_KEY parameter contains an Responder generated random 1423 value that MUST be uniformly distributed. This random value is 1424 encrypted with the Master Key SA using the HIP_CIPHER encryption 1425 algorithm. 1427 The I_NONCE parameter contains the nonce, supplied by the Initiator 1428 for the Master Key generation as shown in Section 6.3. The Responder 1429 is echoing the value back to the Initiator to show it used the 1430 Initiator provided nonce. 1432 The MAC is calculated over the whole HIP envelope, excluding any 1433 parameters after the HIP_MAC, as described in Section 6.2. The 1434 Initiator MUST validate the HIP_MAC parameter. 1436 5.4. ICMP Messages 1438 When a HIP implementation detects a problem with an incoming packet, 1439 and it either cannot determine the identity of the sender of the 1440 packet or does not have any existing HIP association with the sender 1441 of the packet, it MAY respond with an ICMP packet. Any such reply 1442 MUST be rate-limited as described in [RFC4443]. In most cases, the 1443 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1444 ICMPv6) and Code of 0. The Pointer field pointing to the field that 1445 caused the ICMP message to be generated, for example to the first 8 1446 bytes of a UDP payload for "SPI is Unknown". The problem cases 1447 specified in Section 5.4. of [RFC7401] also apply to HIP DEX. 1449 6. Packet Processing 1451 Due to the adopted protocol semantics and the inherited general 1452 packet structure, the packet processing in HIP DEX only differs from 1453 HIPv2 in very few places. Here, we focus on these differences and 1454 refer to Section 6 in [RFC7401] otherwise. 1456 The processing of outgoing and incoming application data remains the 1457 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1459 6.1. Solving the Puzzle 1461 The procedures for solving and verifying a puzzle in HIP DEX are 1462 strongly based on the corresponding procedures in HIPv2. The only 1463 exceptions are that HIP DEX does not use pre-computation of R1 1464 packets and that RHASH is set to CMAC. As a result, the pre- 1465 computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. 1467 Moreover, the Initiator solves a puzzle by computing: 1468 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1470 Similarly, the Responder verifies a puzzle by computing: 1471 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1473 Apart from these modifications, the procedures defined in Section 6.3 1474 of [RFC7401] also apply for HIP DEX. 1476 6.2. HIP_MAC Calculation and Verification 1478 The following subsections define the actions for processing the 1479 HIP_MAC parameter. 1481 6.2.1. CMAC Calculation 1483 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1484 cryptographic function. The scope of the calculation for HIP_MAC is: 1486 CMAC: { HIP header | [ Parameters ] } 1488 where Parameters include all HIP parameters of the packet that is 1489 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1490 value - 1) and exclude parameters with Type values greater or equal 1491 to HIP_MAC's Type value. 1493 During HIP_MAC calculation, the following applies: 1495 * In the HIP header, the Checksum field is set to zero. 1497 * In the HIP header, the Header Length field value is calculated to 1498 the beginning of the HIP_MAC parameter. 1500 The parameter order is described in Section 5.2.1 of [RFC7401]. 1502 The CMAC calculation and verification process is as follows: 1504 Packet sender: 1506 1. Create the HIP packet, without the HIP_MAC or any other parameter 1507 with greater Type value than the HIP_MAC parameter has. 1509 2. Calculate the Header Length field in the HIP header. 1511 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1512 retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers 1513 to host with greater HIT value and HIP-lg refers to the host with 1514 smaller HIT value. 1516 4. Add the HIP_MAC parameter to the packet and any parameter with 1517 greater Type value than the HIP_MAC's that may follow. 1519 5. Recalculate the Length field in the HIP header. 1521 Packet receiver: 1523 1. Verify the HIP header Length field. 1525 2. Remove the HIP_MAC parameter, as well as all other parameters 1526 that follow it with greater Type value, saving the contents if 1527 they will be needed later. 1529 3. Recalculate the HIP packet length in the HIP header and clear the 1530 Checksum field (set it to all zeros). 1532 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1533 defined in Section 6.3 and verify it against the received CMAC. 1535 5. Set Checksum and Header Length fields in the HIP header to 1536 original values. Note that the Checksum and Length fields 1537 contain incorrect values after this step. 1539 6.3. HIP DEX KEYMAT Generation 1541 The HIP DEX KEYMAT process is used to derive the keys for the Master 1542 Key SA as well as for the Pair-wise Key SA. The keys for the Master 1543 Key SA are based on the Diffie-Hellman derived key, Kij, which is 1544 produced during the HIP DEX handshake. The Initiator generates Kij 1545 during the creation of the I2 packet and the Responder generates Kij 1546 once it receives the I2 packet. This is why the I2 packet can 1547 already contain authenticated and/or encrypted information. 1549 The keys derived for the Pair-wise Key SA are not used during the HIP 1550 DEX handshake. Instead, these keys are made available as payload 1551 protection keys (e.g., for IPsec's ESP). 1553 The HIP DEX KEYMAT process is similar to the Hash-based Key 1554 Derivation Function (HKDF) defined in [RFC5869], but uses CMAC in 1555 place of a cryptographic hash. DEX KEYMAT follows the CMAC usage 1556 guidance for a KDF construct provided in [NIST.SP.800-56C], 1557 [NIST.SP.800-108] and [KeyDerivation]. This CMAC Key Derivation 1558 Function (CKDF) consists of two components, CKDF-Extract and CKDF- 1559 Expand. The CKDF-Extract function compresses a non-uniformly 1560 distributed key, such as the output of a Diffie-Hellman key 1561 derivation, to extract the key entropy into a fixed length output. 1562 The CKDF-Expand function takes either the output of the Extract 1563 function or directly uses a uniformly distributed key and expands the 1564 length of the key, repeatedly distributing the key entropy, to 1565 produce the keys needed. 1567 The key derivation for the Master Key SA employs always both the 1568 Extract and Expand phases. The Pair-wise Key SA needs only the 1569 Extract phase when the key is smaller or equal to 128 bits, but 1570 otherwise requires also the Expand phase. 1572 The CKDF-Extract function is the following operation: 1574 CKDF-Extract(I, IKM, info) -> PRK 1576 Inputs: 1577 I Random #I, provided by the Responder, from the PUZZLE 1578 parameter 1579 Kij Diffie-Hellman derived key 1580 IKM IKMm for Master Key SA Input keying material 1581 or 1582 IKMp for Pair-wise Key SA Input keying material 1584 IKMm Kij | I_NONCE 1585 IKMp Kij | I_NONCE | (concatenated random values of the 1586 ENCRYPTED_KEY parameters in the same order as 1587 the HITs with sort(HIT-I | HIT-R)) 1589 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1590 Where the input text: "CKDF-Extract" 1591 Is the hex string: 0x434b44462d45787472616374 1593 Output: 1594 PRK a pseudorandom key (of RHASH_len/8 octets) 1596 The pseudorandom key PRK is calculated as follows: 1598 PRK = CMAC(I, IKM | info) 1600 The CKDF-Expand function is the following operation: 1602 CKDF-Expand(PRK, info, L) -> OKM 1604 Inputs: 1605 PRK a pseudorandom key of at least RHASH_len/8 octets 1606 (either the output from the extract step or the 1607 concatenation of the random values of the 1608 ENCRYPTED_KEY parameters in the same order as the 1609 HITs with sort(HIT-I | HIT-R) in case of no extract) 1610 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1611 Where the input text: "CKDF-Expand" 1612 Is the hex string: 0x434b44462d457870616e64 1613 L length of output keying material in octets 1614 (<= 255*RHASH_len/8) 1616 Output: 1617 OKM output keying material (of L octets) 1619 The output keying material OKM is calculated as follows: 1621 N = ceil(L/(RHASH_len/8)) 1622 T = T(1) | T(2) | T(3) | ... | T(N) 1623 OKM = first L octets of T 1625 where 1627 T(0) = empty string (zero length) 1628 T(1) = CMAC(PRK, T(0) | info | 0x01) 1629 T(2) = CMAC(PRK, T(1) | info | 0x02) 1630 T(3) = CMAC(PRK, T(2) | info | 0x03) 1631 ... 1633 (where the constant concatenated to the end of each T(n) is a 1634 single octet.) 1636 sort(HIT-I | HIT-R) is defined as the network byte order 1637 concatenation of the two HITs, with the smaller HIT preceding the 1638 larger HIT, resulting from the numeric comparison of the two HITs 1639 interpreted as positive (unsigned) 128-bit integers in network byte 1640 order. 1642 The initial keys for the Master Key SA are drawn sequentially in the 1643 order that is determined by the numeric comparison of the two HITs, 1644 with the comparison method described in the previous paragraph. 1645 HOST_g denotes the host with the greater HIT value, and HOST_l the 1646 host with the lower HIT value. 1648 The drawing order for initial keys: 1650 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1652 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1654 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1656 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1658 The number of bits drawn for a given algorithm is the "natural" size 1659 of the keys regarding the algorithm defined in the HIP_CIPHER. For 1660 the mandatory algorithms, the following size applies: 1662 AES 128 bits 1664 If other key sizes are used, they must be treated as different 1665 encryption algorithms and defined separately. 1667 6.4. Initiation of a HIP Diet EXchange 1669 The initiation of a HIP DEX handshake proceeds as described in 1670 Section 6.6 of [RFC7401]. The I1 packet contents are specified in 1671 Section 5.3.1. 1673 6.5. Processing Incoming I1 Packets 1675 I1 packets in HIP DEX are handled almost identical to HIPv2 (see 1676 Section 6.7 of [RFC7401]). The main differences are that the 1677 Responder SHOULD select a HIP DEX HIT Suite in the R1 response. 1678 Moreover, as R1 packets are neither covered by a signature nor incur 1679 the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- 1680 computation of an R1 is only marginally beneficial, but would incur 1681 additional memory resources at the Responder. Hence, the R1 pre- 1682 computation SHOULD be omitted in HIP DEX. 1684 Correspondingly, the modified conceptual processing rules for 1685 responding to an I1 packet are as follows: 1687 1. The Responder MUST check that the Responder's HIT in the received 1688 I1 packet is either one of its own HITs or NULL. Otherwise, it 1689 MUST drop the packet. 1691 2. If the Responder is in ESTABLISHED state, the Responder MAY 1692 respond to this with an R1 packet, prepare to drop an existing 1693 HIP security association with the peer, and stay at ESTABLISHED 1694 state. 1696 3. If the Responder is in I1-SENT state, it MUST make a comparison 1697 between the sender's HIT and its own (i.e., the receiver's) HIT. 1698 If the sender's HIT is greater than its own HIT, it should drop 1699 the I1 packet and stay at I1-SENT. If the sender's HIT is 1700 smaller than its own HIT, it SHOULD send the R1 packet and stay 1701 at I1-SENT. The HIT comparison is performed as defined in 1702 Section 6.3. 1704 4. If the implementation chooses to respond to the I1 packet with an 1705 R1 packet, it creates a new R1 according to the format described 1706 in Section 5.3.2. It chooses the HI based on the destination HIT 1707 and the DH_GROUP_LIST in the I1 packet. If the implementation 1708 does not support the DH group required by the Initiator or if the 1709 destination HIT in the I1 packet does not match the required DH 1710 group, it selects the mutually preferred and supported DH group 1711 based on the DH_GROUP_LIST parameter in the I1 packet. The 1712 implementation includes the corresponding ECDH public key in the 1713 HOST_ID parameter. If no suitable DH Group ID was contained in 1714 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with 1715 any suitable ECDH public key. 1717 5. If the received Responder's HIT in the I1 packet is not NULL, the 1718 Responder's HIT in the R1 packet MUST match the destination HIT 1719 in the I1 packet. Otherwise, the Responder MUST select a HIT 1720 with the same HIT Suite as the Initiator's HIT. If this HIT 1721 Suite is not supported by the Responder, it SHOULD select a 1722 REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is 1723 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 1724 a local policy matter. 1726 6. The Responder expresses its supported HIP transport formats in 1727 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of 1728 [RFC7401]. The Responder MUST provide at least one payload 1729 transport format type. 1731 7. The Responder sends the R1 packet to the source IP address of the 1732 I1 packet. 1734 Note that only steps 4 and 5 have been changed with regard to the 1735 processing rules of HIPv2. The considerations about R1 management 1736 (except pre-computation) and malformed I1 packets in Sections 6.7.1 1737 and 6.7.2 of [RFC7401] likewise apply to HIP DEX. 1739 6.6. Processing Incoming R1 Packets 1741 R1 packets in HIP DEX are handled identically to HIPv2 (see 1742 Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses 1743 ECDH public keys as HIs and does not employ signatures. 1745 As R1 is not signed and no proof is possible in the authenticity of 1746 its contents, all processing of the R1 is provisional until verified 1747 by the R2 processing. 1749 The modified conceptual processing rules for responding to an R1 1750 packet are as follows: 1752 1. A system receiving an R1 MUST first check to see if it has sent 1753 an I1 packet to the originator of the R1 packet (i.e., it has a 1754 HIP association that is in state I1-SENT and that is associated 1755 with the HITs in the R1). Unless the I1 packet was sent in 1756 opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP 1757 addresses in the received R1 packet SHOULD be ignored by the R1 1758 processing and, when looking up the correct HIP association, the 1759 received R1 packet SHOULD be matched against the associations 1760 using only the HITs. If a match exists, the system processes 1761 the R1 packet as described below. 1763 2. Otherwise, if the system is in any state other than I1-SENT or 1764 I2-SENT with respect to the HITs included in the R1 packet, it 1765 SHOULD silently drop the R1 packet and remain in the current 1766 state. 1768 3. If the HIP association state is I1-SENT or I2-SENT, the received 1769 Initiator's HIT MUST correspond to the HIT used in the original 1770 I1 packet. Also, the Responder's HIT MUST correspond to the one 1771 used in the I1 packet, unless this packet contained a NULL HIT. 1773 4. If the HIP association state is I1-SENT, and multiple valid R1 1774 packets are present, the system MUST select from among the R1 1775 packets with the largest R1 generation counter. 1777 5. The system MUST check that the Initiator's HIT Suite is 1778 contained in the HIT_SUITE_LIST parameter in the R1 packet 1779 (i.e., the Initiator's HIT Suite is supported by the Responder). 1780 If the HIT Suite is supported by the Responder, the system 1781 proceeds normally. Otherwise, the system MAY stay in state 1782 I1-SENT and restart the HIP DEX handshake by sending a new I1 1783 packet with an Initiator HIT that is supported by the Responder 1784 and hence is contained in the HIT_SUITE_LIST in the R1 packet. 1785 The system MAY abort the handshake if no suitable source HIT is 1786 available. The system SHOULD wait for an acceptable time span 1787 to allow further R1 packets with higher R1 generation counters 1788 or different HIT and HIT Suites to arrive before restarting or 1789 aborting the HIP DEX handshake. 1791 6. The system MUST check that the DH Group ID in the HOST_ID 1792 parameter in the R1 matches the first DH Group ID in the 1793 Responder's DH_GROUP_LIST in the R1 packet, and also that this 1794 Group ID corresponds to a value that was included in the 1795 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 1796 of the HOST_ID parameter does not express the Responder's best 1797 choice, the Initiator can conclude that the DH_GROUP_LIST in the 1798 I1 or R1 packet was adversely modified. In such a case, the 1799 Initiator MAY send a new I1 packet; however, it SHOULD NOT 1800 change its preference in the DH_GROUP_LIST in the new I1 packet. 1801 Alternatively, the Initiator MAY abort the HIP DEX handshake. 1802 Moreover, if the DH Group ID indicated in the HOST_ID parameter 1803 does not match the DH Group ID of the HI employed by the 1804 Initiator, the system SHOULD wait for an acceptable time span to 1805 allow further R1 packets with different DH Group IDs to arrive 1806 before restarting or aborting the HIP DEX handshake. When 1807 restarting the handshake, the Initiator MUST consult local 1808 policies (see Section 7) regarding the use of another, mutually 1809 supported DH group for the subsequent handshake with the 1810 Responder. 1812 7. If the HIP association state is I2-SENT, the system MAY re-enter 1813 state I1-SENT and process the received R1 packet if it has a 1814 larger R1 generation counter than the R1 packet responded to 1815 previously. 1817 8. The system SHOULD attempt to validate the HIT against the 1818 received Host Identity by using the received Host Identity to 1819 construct a HIT and verify that it matches the Sender's HIT. 1821 9. The system MUST store the received R1 generation counter for 1822 future reference. 1824 10. The system attempts to solve the puzzle in the R1 packet. The 1825 system MUST terminate the search after exceeding the remaining 1826 lifetime of the puzzle. If the puzzle is not successfully 1827 solved, the implementation MAY either resend the I1 packet 1828 within the retry bounds or abandon the HIP base exchange. 1830 11. The system computes standard Diffie-Hellman keying material 1831 according to the public value and Group ID provided in the 1832 HOST_ID parameter. The Diffie-Hellman keying material Kij is 1833 used for key extraction as specified in Section 6.3. 1835 12. The system selects the HIP_CIPHER ID from the choices presented 1836 in the R1 packet and uses the selected values subsequently when 1837 generating and using encryption keys, and when sending the I2 1838 packet. If the proposed alternatives are not acceptable to the 1839 system, it MAY either resend an I1 packet within the retry 1840 bounds or abandon the HIP base exchange. 1842 13. The system chooses one suitable transport format from the 1843 TRANSPORT_FORMAT_LIST and includes the respective transport 1844 format parameter in the subsequent I2 packet. 1846 14. The system initializes the remaining variables in the associated 1847 state, including Update ID counters. 1849 15. The system prepares and sends an I2 packet as described in 1850 Section 5.3.3. 1852 16. The system SHOULD start a timer whose timeout value SHOULD be 1853 larger than the worst-case anticipated RTT, and MUST increment a 1854 trial counter associated with the I2 packet. The sender SHOULD 1855 retransmit the I2 packet upon a timeout and restart the timer, 1856 up to a maximum of I2_RETRIES_MAX tries. 1858 17. If the system is in state I1-SENT, it SHALL transition to state 1859 I2-SENT. If the system is in any other state, it remains in the 1860 current state. 1862 Note that step 4 from the original processing rules of HIPv2 1863 (signature verification) has been removed in the above processing 1864 rules for HIP DEX. Moreover, step 7 of the original processing rules 1865 has been adapted in step 6 above to account for the fact that HIP DEX 1866 uses ECDH public keys as HIs. The considerations about malformed R1 1867 packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX. 1869 6.7. Processing Incoming I2 Packets 1871 The processing of I2 packets follows similar rules as HIPv2 (see 1872 Section 6.9 of [RFC7401]). The main differences to HIPv2 are that 1873 HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY 1874 parameter as well as an I2 reception acknowledgement for 1875 retransmission purposes. Moreover, with HIP DEX the Initiator is 1876 responsible for triggering retransmissions, whereas the Responder 1877 merely replies to received I2 packets. 1879 The modified HIP DEX conceptual processing rules for responding to an 1880 I2 packet are: 1882 1. The system MAY perform checks to verify that the I2 packet 1883 corresponds to a recently sent R1 packet. Such checks are 1884 implementation dependent. See Appendix A in [RFC7401] for a 1885 description of an example implementation. 1887 2. The system MUST check that the Responder's HIT corresponds to 1888 one of its own HITs and MUST drop the packet otherwise. 1890 3. The system MUST further check that the Initiator's HIT Suite is 1891 supported. The Responder SHOULD silently drop I2 packets with 1892 unsupported Initiator HITs. 1894 4. The system MUST validate the Initiator's HI per Section 9.3. 1896 5. If the system's state machine is in the R2-SENT state, the 1897 system MUST check to see if the newly received I2 packet is 1898 similar to the one that triggered moving to R2-SENT. If so, it 1899 MUST retransmit a previously sent R2 packet and reset the 1900 R2-SENT timer. The system SHOULD re-use the previously 1901 established state to re-create the corresponding R2 packet in 1902 order to prevent unnecessary computation overhead. 1904 6. If the system's state machine is in the I2-SENT state, the 1905 system MUST make a comparison between its local and sender's 1906 HITs (similarly as in Section 6.3). If the local HIT is smaller 1907 than the sender's HIT, it should drop the I2 packet, use the 1908 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1909 #I from the R1 packet received earlier, and get the local 1910 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1911 from the I2 packet sent to the peer earlier. Otherwise, the 1912 system processes the received I2 packet and drops any previously 1913 derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY 1914 keying material it might have generated upon sending the I2 1915 packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY, 1916 and the nonce #J are taken from the just arrived I2 packet. The 1917 local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the 1918 nonce #I are the ones that were sent earlier in the R1 packet. 1920 7. If the system's state machine is in the I1-SENT state, and the 1921 HITs in the I2 packet match those used in the previously sent I1 1922 packet, the system uses this received I2 packet as the basis for 1923 the HIP association it was trying to form, and stops 1924 retransmitting I1 packets (provided that the I2 packet passes 1925 the additional checks below). 1927 8. If the system's state machine is in any state other than 1928 R2-SENT, the system SHOULD check that the echoed R1 generation 1929 counter in the I2 packet is within the acceptable range if the 1930 counter is included. Implementations MUST accept puzzles from 1931 the current generation and MAY accept puzzles from earlier 1932 generations. If the generation counter in the newly received I2 1933 packet is outside the accepted range, the I2 packet is stale 1934 (and perhaps replayed) and SHOULD be dropped. 1936 9. The system MUST validate the solution to the puzzle as described 1937 in Section 6.1. 1939 10. The I2 packet MUST have a single value in the HIP_CIPHER 1940 parameter, which MUST match one of the values offered to the 1941 Initiator in the R1 packet. 1943 11. The system MUST derive Diffie-Hellman keying material Kij based 1944 on the public value and Group ID in the HOST_ID parameter. This 1945 keying material is used to derive the keys of the Master Key SA 1946 as described in Section 6.3. If the Diffie-Hellman Group ID is 1947 unsupported, the I2 packet is silently dropped. If the 1948 processing time for the derivation of the Diffie-Hellman keying 1949 material Kij is likely to cause premature I2 retransmissions by 1950 the Initiator, the system MAY send a NOTIFY packet before 1951 starting the key derivation process. The NOTIFY packet contains 1952 a NOTIFICATION parameter with Notify Message Type 1953 I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the 1954 anticipated remaining processing time for the I2 packet in 1955 milliseconds as two-octet Notification Data. 1957 12. The implementation SHOULD also verify that the Initiator's HIT 1958 in the I2 packet corresponds to the Host Identity sent in the I2 1959 packet. (Note: some middleboxes may not be able to make this 1960 verification.) 1962 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1963 Other documents specifying transport formats (e.g., [RFC7402]) 1964 contain specifications for handling any specific transport 1965 selected. 1967 14. The system MUST verify the HIP_MAC according to the procedures 1968 in Section 6.2. 1970 15. If the checks above are valid, then the system proceeds with 1971 further I2 processing; otherwise, it discards the I2 and its 1972 state machine remains in the same state. 1974 16. The system MUST decrypt the keying material from the 1975 ENCRYPTED_KEY parameter. This keying material is a partial 1976 input to the key derivation process for the Pair-wise Key SA 1977 (see Section 6.3). 1979 17. The system initializes the remaining variables in the associated 1980 state, including Update ID counters. 1982 18. Upon successful processing of an I2 packet when the system's 1983 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 1984 R2-SENT, an R2 packet is sent as described in Section 5.3.4 and 1985 the system's state machine transitions to state R2-SENT. 1987 19. Upon successful processing of an I2 packet when the system's 1988 state machine is in state ESTABLISHED, the old HIP association 1989 is dropped and a new one is installed, an R2 packet is sent as 1990 described in Section 5.3.4, and the system's state machine 1991 transitions to R2-SENT. 1993 20. Upon the system's state machine transitioning to R2-SENT, the 1994 system starts a timer. The state machine transitions to 1995 ESTABLISHED if some data has been received on the incoming HIP 1996 association, or an UPDATE packet has been received (or some 1997 other packet that indicates that the peer system's state machine 1998 has moved to ESTABLISHED). If the timer expires (allowing for a 1999 maximal amount of retransmissions of I2 packets), the state 2000 machine transitions to ESTABLISHED. 2002 Note that steps 11 (encrypted HOST_ID) and 15 (signature 2003 verification) from the original processing rules of HIPv2 have been 2004 removed in the above processing rules for HIP DEX. Moreover, step 10 2005 of the HIPv2 processing rules has been adapted to account for 2006 optional extension of the retransmission mechanism. Step 16 has been 2007 added to the processing rules in this document. The considerations 2008 about malformed I2 packets in Sections 6.9.1 of [RFC7401] also apply 2009 to HIP DEX. 2011 6.8. Processing Incoming R2 Packets 2013 R2 packets in HIP DEX are handled identically to HIPv2 (see 2014 Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX 2015 introduces a new session key exchange via the ENCRYPTED_KEY parameter 2016 and does not employ signatures. 2018 The modified conceptual processing rules for responding to an R2 2019 packet are as follows: 2021 1. If the system is in any other state than I2-SENT, the R2 packet 2022 is silently dropped. 2024 2. The system MUST verify that the HITs in use correspond to the 2025 HITs that were received in the R1 packet that caused the 2026 transition to the I2-SENT state. 2028 3. The system MUST verify the HIP_MAC according to the procedures in 2029 Section 6.2. 2031 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 2032 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 2033 packet and compare the results against the chosen suites. 2035 5. The system MUST validate the Responder's HI per Section 9.3. 2037 6. If any of the checks above fail, there is a high probability of 2038 an ongoing man-in-the-middle or other security attack. The 2039 system SHOULD act accordingly (e.g. aborting with logging), 2040 based on its local policy. 2042 7. The system MUST decrypt the keying material from the 2043 ENCRYPTED_KEY parameter. This keying material is a partial input 2044 to the key derivation process for the Pair-wise Key SA (see 2045 Section 6.3). 2047 8. Upon successful processing of the R2 packet, the state machine 2048 transitions to state ESTABLISHED. 2050 Note that step 4 (signature verification) from the original 2051 processing rules of HIPv2 has been replaced with a negotiation re- 2052 evaluation in the above processing rules for HIP DEX. Moreover, step 2053 6 has been added to the processing rules. 2055 6.9. Processing Incoming NOTIFY Packets 2057 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 2058 in a received NOTIFICATION parameter SHOULD be logged. Received 2059 errors MUST be considered only as informational, and the receiver 2060 SHOULD NOT change its HIP state purely based on the received NOTIFY 2061 packet. 2063 If a NOTIFY packet is received in state I2-SENT, this packet is an I2 2064 reception acknowledgement of the optional retransmission mechanism 2065 extension and SHOULD be processed. The following steps define the 2066 conceptual processing rules for such incoming NOTIFY packets in state 2067 I2-SENT: 2069 1. The system MUST verify that the HITs in use correspond to the 2070 HITs that were received in the R1 packet that caused the 2071 transition to the I2-SENT state. If this check fails, the NOTIFY 2072 packet MUST be dropped silently. 2074 2. If the NOTIFY packet contains a NOTIFICATION parameter with 2075 Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the 2076 I2 retransmission timer to the I2 processing time indicated in 2077 the NOTIFICATION parameter plus half the RTT-based timeout value. 2078 The system MUST NOT set the retransmission timeout to a higher 2079 value than allowed by a local policy. Moreover, the system 2080 SHOULD reset the I2 retransmission timer to the RTT-based timeout 2081 value after the next I2 retransmission. 2083 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 2085 UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 2086 as in HIPv2 (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). 2087 The only difference is the that the HIP_SIGNATURE is never present 2088 and, therefore, is not required to be processed by the receiving 2089 party. 2091 [RFC7402] specifies the rekeying of an existing HIP SA using the 2092 UPDATE message. This rekeying procedure can also be used with HIP 2093 DEX. However, where rekeying involves a new Diffie-Hellman key 2094 exchange, HIP DEX peers MUST establish a new HIP association in order 2095 to create a new Pair-wise Key SA due to the use of static ECDH key- 2096 pairs with HIP DEX. 2098 6.11. Handling State Loss 2100 Implementors MAY choose to use non-volatile, secure storage for HIP 2101 states in order for them to survive a system reboot. If no secure 2102 storage capabilities are available, the system SHOULD delete the 2103 corresponding HIP state, including the keying material. If the 2104 implementation does drop the state (as RECOMMENDED), it MUST also 2105 drop the peer's R1 generation counter value, unless a local policy 2106 explicitly defines that the value of that particular host is stored. 2108 Storing of the R1 generation counter values and ENCRYPTED_KEY counter 2109 (Section 5.2.5) MUST be configured by explicit HITs. 2111 7. HIP Policies 2113 There are a number of variables that will influence the HIP exchanges 2114 that each host must support. The value of puzzle difficulty K used 2115 in the HIP R1 must be chosen with care. Values for the K that are 2116 too high will exclude clients with weak CPUs because these devices 2117 cannot solve the puzzle within a reasonable amount of time. The K 2118 value should only be raised if a Responder is under high load, i.e., 2119 it cannot process all incoming HIP handshakes any more. 2121 If a Responder is not under high load, K SHOULD be 0. 2123 All HIP DEX implementations SHOULD provide for an Access Control List 2124 (ACL), representing for which hosts they accept HIP diet exchanges, 2125 and the preferred transport format and local lifetimes. Wildcarding 2126 SHOULD be supported for such ACLs. 2128 7.1. HIT/HI ACL 2130 Both the Initiator and Responder SHOULD implement an ACL. Minimally, 2131 these ACLs will be a list of trusted HIT/HIs. They may also contain 2132 the password used in the password-based two-factor authentication 2133 (Appendix B) and preferred HIT Suite. 2135 ACL processing is applied to all HIP packets. A HIP peer MAY reject 2136 any packet where the Receiver's HIT is not in the ACL. The HI (in 2137 the R1, I2, and optionally NOTIFY packets) MUST be validated as well, 2138 when present in the ACL. This is the defense against collision and 2139 second-image attacks on the HIT generation. 2141 Devices with no input mechanism (e.g. sensors) SHOULD accept R1 2142 packets from unknown HITs. These R1 packets SHOULD contain the start 2143 of the password-based two-factor authentication . If the R2 for this 2144 HIT indicates success, then the device may add this HIT/HI to its ACL 2145 for future use. 2147 Devices unable to manage an ACL (e.g. sensors) are subject to MITM 2148 attacks, even with the use of the password authentication (password 2149 theft by attacker). As long as the other peer (e.g. sensor 2150 controller) does use an ACL, the attack can be recognized there and 2151 addressed. This is often seen where the sensor does not appear as 2152 properly operating with the controller, as the attacker cannot 2153 impersonate information in the ACL. 2155 8. Interoperability between HIP DEX and HIPv2 2157 HIP DEX and HIPv2 both use the same protocol number and packet 2158 formats. Hence, an implementation that either supports HIP DEX or 2159 HIPv2 has to be able to detect the dialect that the peer is speaking. 2160 This section outlines how a HIP DEX implementation can achieve such 2161 detection for the two relevant cases where: 2163 1. the Initiator supports HIP DEX and the Responder supports HIP 2164 BEX, 2166 2. the Initiator supports HIP BEX and the Responder supports HIP 2167 DEX. 2169 In the first case, the HIP DEX implementation (Initiator) inspects 2170 the Responder's HIT prior to sending the I1 packet. If the OGA ID 2171 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 2172 DEX implementation cancels the handshake. If the Responder is 2173 unknown prior to sending the I1 packet (i.e., opportunistic mode), 2174 the HIP DEX implementation performs the above check on reception of 2175 the R1 packet and cancels the handshake in case of a negative result. 2176 In both failure scenarios, the implementation should report an error 2177 to the user via appropriate means. 2179 In the second case, the HIP DEX implementation (Responder) inspects 2180 the Initiator's HIT on reception of an I1 packet. If the OGA ID 2181 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 2182 DEX implementation cancels the handshake and sends an ICMP packet 2183 with type Parameter Problem, with the Pointer pointing to the source 2184 HIT, to the Initiator. As an off-path adversary could also send such 2185 an ICMP packet with the aim to prevent the HIP DEX handshake from 2186 completing, the Initiator SHOULD NOT react to an ICMP message before 2187 retransmission counter reaches I1_RETRIES_MAX in its state machine 2188 (see Table 3 in [RFC7401]). 2190 9. Security Considerations 2192 HIP DEX closely resembles HIPv2. As such, the security 2193 considerations discussed in Section 8 of [RFC7401] similarly apply to 2194 HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated 2195 Diffie-Hellman key exchange of HIPv2 with an exchange of random 2196 keying material that is encrypted with a Diffie-Hellman derived key. 2197 Both the Initiator and Responder contribute to this keying material. 2198 As a result, the following additional security considerations apply 2199 to HIP DEX: 2201 * The strength of the keys for both the Master and Pair-wise Key SAs 2202 is based on the quality of the random keying material generated by 2203 the Initiator and the Responder. As either peer may be a sensor 2204 or an actuator device, there is a natural concern about the 2205 quality of its random number generator. Thus at least a CSPRNG 2206 SHOULD be used. 2208 * HIP DEX lacks the Forward Secrecy (FS) property of HIPv2. 2209 Consequently, if an HI is compromised, all previous HIP 2210 connections protected with that HI are compromised as explained in 2211 Section 1. 2213 * The HIP DEX HIT generation may present new attack opportunities. 2214 Hence, HIP DEX HITs MUST NOT be used as the only means to identify 2215 a peer in an ACL. Instead, the use of the peer's HI is 2216 recommended as explained in Section 3. 2218 * The R1 packet is unauthenticated and offers an adversary a new 2219 attack vector against the Initiator. This is mitigated by only 2220 processing a received R1 packet when the Initiator has previously 2221 sent a corresponding I1 packet. Moreover, the Responder repeats 2222 the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and 2223 TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to 2224 enable the Initiator to verify that these parameters have not been 2225 modified by an attacker in the unprotected R1 packet as explained 2226 in Section 6.8. 2228 * Contrary to HIPv2, HIP DEX does not provide for end-point 2229 anonymity for the Initiator or Responder. Thus, any signaling 2230 that indicates such anonymity should be ignored as explained in 2231 Section 1.1. 2233 * It is critical to properly manage the ENCRYPTED_KEY counter 2234 (Section 5.2.5). If non-volatile store is used to maintain HIP 2235 state across system resets, then this counter MUST be part of the 2236 state store. 2238 The optional retransmission extension of HIP DEX is based on a NOTIFY 2239 packet that the Responder can use to inform the Initiator about the 2240 reception of an I2 packet. The Responder, however, cannot protect 2241 the authenticity of this packet as it did not yet set up the Master 2242 Key SA. Hence, an eavesdropping adversary may send spoofed reception 2243 acknowledgements for an overheard I2 packet and signal an arbitrary 2244 I2 processing time to the Initiator. The adversary can, e.g., 2245 indicate a lower I2 processing time than actually required by the 2246 Responder in order to cause premature retransmissions. To protect 2247 against this attack, the Initiator SHOULD set the NOTIFY-based 2248 timeout value to the maximum indicated packet processing time in case 2249 of conflicting NOTIFY packets. This allows the legitimate Responder 2250 to extend the retransmission timeout to the intended length. The 2251 adversary, however, can still arbitrarily delay the protocol 2252 handshake beyond the Responder's actual I2 processing time. To limit 2253 the extend of such a maliciously induced handshake delay, this 2254 specification additionally requires the Initiator not to set the 2255 NOTIFY-based timeout value higher than allowed by a local policy. 2257 Section 5.3.1 mentions that implementations need to be able to handle 2258 storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre- 2259 computed in HIP DEX and also the state machine does not include an 2260 "R1_SENT" state (that would enable caching of R1 packets). 2261 Therefore, an implementation has to cache information (e.g., at least 2262 the HITs) from incoming I1 packets and rate control the incoming I1 2263 packets to avoid unnecessary packet processing during I1 packet 2264 storms. 2266 9.1. Caution on using HIP DEX rather than HIP BEX 2268 Due to the substantially reduced security guarantees of HIP DEX 2269 compared to HIP BEX, HIP DEX MUST only be used when at least one of 2270 the two endpoints is a class 0 or 1 constrained device defined in 2271 Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both 2272 endpoints are class 2 devices or unconstrained. 2274 9.2. Use of AES-CTR for HIP Parameter Encryption 2276 AES-CTR is a basic cipher mode that does not accept an initialization 2277 vector to allow for key re-use. In essence, it stretches the initial 2278 key into a much longer keystream (akin to a stream cipher) that is 2279 used like a one-time pad. Any reuse of that keystream breaks the 2280 confidentiality of the protected data, so when using AES-CTR, care 2281 must be taken to ensure that within a given keystream the counter 2282 value is never reused, and that any given key is only used to 2283 generate a single keystream. The integration of AES-CTR into IPsec 2284 ESP (RFC 3686) used by HIP (and, thus, by HIP-DEX) improves on the 2285 situation by partitioning the 128-bit counter space into a 32-bit 2286 nonce, 64-bit IV, and 32-bits of counter. The counter is incremented 2287 to provide a keystream for protecting a given packet, the IV is 2288 chosen by the encryptor in a "manner that ensures uniqueness", and 2289 the nonce persists for the lifetime of a given SA. In particular, in 2290 this usage the nonce must be unpredictable, not just single-use. In 2291 HIP-DEX, the properties of nonce uniqueness/unpredictability and per- 2292 packet IV uniqueness are defined in Section 5.2.2. 2294 9.3. Need to Validate Public Keys 2296 With the curves specified here, there is a straightforward key 2297 extraction attack, which is a very serious problem with the use of 2298 static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's 2299 Public Key. 2301 For Curve25519 and Curve448, the contents of the public value are the 2302 byte string inputs and outputs of the corresponding functions defined 2303 in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. 2305 The validation is done in Section 6.7, step 4 and Section 6.8, step 2306 5. 2308 10. IANA Considerations 2310 The following changes to the "Host Identity Protocol (HIP) 2311 Parameters" registries have been made: 2313 ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) 2314 (see Section 5.2.5) in the "Parameter Types" subregistry of the 2315 "Host Identity Protocol (HIP) Parameters" registry. 2317 DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519 2318 with value TBD7 (suggested: 12) and Curve448 with value TBD8 2319 (suggested: 13) (see Section 5.2.1) in the "Group IDs" subregistry 2320 of the "Host Identity Protocol (HIP) Parameters" registry. 2322 HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" 2323 without four-bit ID of TBD2 (suggested: 4) and eight-bit encoding 2324 of TBD3 (suggested: 0x40) (see Section 5.2.4) in the "HIT Suite 2325 ID" subregistry of the "Host Identity Protocol (HIP) Parameters" 2326 registry. 2328 HIP Cipher ID This document defines the new HIP Cipher ID "AES- 2329 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2) 2330 in the "HIP Cipher ID" subregistry of the "Host Identity Protocol 2331 (HIP) Parameters" registry. 2333 HI Algorithm This document defines the new HI Algorithm "ECDH" with 2334 type number TBD5 (suggested: 11) (see Section 5.2.3) in the "HI 2335 Algorithm" subregistry of the "Host Identity Protocol (HIP) 2336 Parameters" registry. 2338 I_NONCE "I_NONCE" with type number TBD6 (suggested: 644) (see 2339 Section 5.2.6) in the "Parameter Types" subregistry of the "Host 2340 Identity Protocol (HIP) Parameters" registry. 2342 ECC Curve Label This document specifies a new algorithm-specific 2343 subregistry named "ECDH Curve Label". The values for this 2344 subregistry are defined in Section 5.2.1. The complete list of 2345 algorithms for the DH_GROUP_LIST parameter are listed in the 2346 "Group IDs" subregistry of the "Host Identity Protocol (HIP) 2347 Parameters" registry. 2349 11. Acknowledgements 2351 The drive to put HIP on a cryptographic 'Diet' came out of a number 2352 of discussions with sensor vendors at IEEE 802.15 meetings. David 2353 McGrew was very helpful in crafting this document. Special thanks to 2354 Mohit Sethi in helping with the draft during IESG process. 2356 Special thanks to Dr. Hugo Krawczyk for early guidance on the IRTF 2357 CFRG list on how to safely use CMAC in a key derivation function. 2358 And Dr. Lily Chen of NIST who spent time discussing CKDF at IEEE 802 2359 and IETF meetings. 2361 12. Changelog 2363 This section summarizes the changes made from draft-moskowitz-hip-rg- 2364 dex-05, which was the first stable version of the draft. Note that 2365 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 2367 The draft was then renamed from draft-moskowitz-hip-dex to draft- 2368 ietf-hip-dex. 2370 12.1. Changes in draft-ietf-hip-dex-24 2372 * Apply editorial comments from Eric Vyncke in Section 1.2 2374 * Added SIGMA and ATmega328P references 2376 * Added non-paywall URL for EfficientECC reference 2378 * Added Section 9.1 and removed last NIST P-384 text. 2380 12.2. Changes in draft-ietf-hip-dex-23 2382 * Apply editorial comment from Eric Vyncke 2384 * Added concatenating Context ID with HI in FOLD to mirror HIPv2 2385 ORCHID construction 2387 * Added Partial Computational Cost of FS via SIGMA, Section 1.2.1 2389 * Added further text to Section 3.2.1 2391 12.3. Changes in draft-ietf-hip-dex-22 2393 * Apply editorial comment from Roman Danyliw 2395 * Clarify IKM content for Master SA and Pairwise SA in Section 6.3 2397 * Add behavior on BEX before DEX to Section 1.2 2399 * Added [NIST.SP.800-56C], [NIST.SP.800-108], and [KeyDerivation] as 2400 source guidance for CKDF to Section 6.3 2402 * Removed NIST curves from Section 5.2.1 and Section 5.2.3 as too 2403 slow for 8-bit CPUs 2405 12.4. Changes in draft-ietf-hip-dex-21 2407 * Clarified on security concerns of using AES-CTR in Section 9.2 2408 * Edits for SECDIR comments 2410 12.5. Changes in draft-ietf-hip-dex-20 2412 * Clarified text on AES-CTR for HIP parameter encryption. This 2413 includes Section 9.2 2415 * Clarified text on R2 processing to validate content of R1. 2417 * Clarified Applicability section. 2419 * Expanded Fig 1. 2421 * Clarified differences between BEX and DEX state machines. 2423 * ESP transform is MTI and ESP-TCP is Experimental. 2425 12.6. Changes in draft-ietf-hip-dex-19 2427 * Replaced reference to RFC4493 for CMAC with NIST SP800-38B. 2429 * Remove NIST P-521 from DH_GROUP_LIST. 2431 * Remove NULL-ENCRYPT. 2433 * Added reference to rfc8005 for HIT lookup in DNS. 2435 * Remove setting Control bit: A. 2437 * Many textual improvements per Benjamin Kaduk comments. 2439 12.7. Changes in draft-ietf-hip-dex-18 2441 * Changed Perfect Forward Secrecy to Forward Secrecy. 2443 12.8. Changes in draft-ietf-hip-dex-17 2445 * Added hex values for strings CKDF-Extract and CKDF-Expand. 2447 * Replace Perfect Forward Secrecy with Forward Secrecy. 2449 12.9. Changes in draft-ietf-hip-dex-16 2451 * Remove old placeholder text. 2453 * Remove SECP160R1. Experience has shown EC25519 performance equal 2454 enough to not need it. 2456 12.10. Changes in draft-ietf-hip-dex-15 2458 * Added Public Key validation in I2 and R2 processing. 2460 * Added ACL processing (Section 7.1). 2462 * Added IANA instructions for DH_GROUP_LIST. 2464 12.11. Changes in draft-ietf-hip-dex-14 2466 * Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan 2467 comment 2469 12.12. Changes in draft-ietf-hip-dex-12 and 13 2471 * Nits from Jeff Ahrenholz (including some formatting issues) 2473 12.13. Changes in draft-ietf-hip-dex-11 and 12 2475 * Included more precise references to the IANA subregistries 2477 * Addressed GEN-ART feedback from Francis Dupont 2479 * Added reasoning for FS in a separate section, and it is mentioned 2480 also in the abstract and intro. 2482 * Donald Eastlake's (secdir) nits addressed 2484 * Resolved IANA nits from Amanda Baber. 2486 * New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 2487 Considered Unsafe" (removed in ver 16), "Need to Validate Public 2488 Keys" (Section 9.3), and "I_NONCE" (Section 5.2.6) to address Eric 2489 Rescorla's concerns. 2491 12.14. Changes in draft-ietf-hip-dex-11 2493 * Update IANA considerations as requested by Eric Envyncke 2495 12.15. Changes in draft-ietf-hip-dex-10 2497 * Explanations on why the document includes so many SHOULDs 2499 12.16. Changes in draft-ietf-hip-dex-09 2501 * Fixed values for 2503 - DH_GROUP_LIST 2504 - HIT_SUITE_LIST 2506 to match [RFC7401]. 2508 12.17. Changes in draft-ietf-hip-dex-05 2510 * Clarified main differences between HIP BEX and HIP DEX in 2511 Section 1. 2513 * Addressed MitM attack in Section 8. 2515 * Minor editorial changes. 2517 12.18. Changes in draft-ietf-hip-dex-04 2519 * Added new paragraph on rekeying procedure with HIP DEX. 2521 * Updated references. 2523 * Editorial changes. 2525 12.19. Changes in draft-ietf-hip-dex-03 2527 * Added new section on HIP DEX/HIPv2 interoperability 2529 * Added reference to RFC4493 for CMAC. 2531 * Added reference to RFC5869 for CKDF. 2533 * Added processing of NOTIFY message in I2-SENT of state diagram. 2535 * Editorial changes. 2537 12.20. Changes in draft-ietf-hip-dex-02 2539 * Author address change. 2541 12.21. Changes in draft-ietf-hip-dex-01 2543 * Added the new ECDH groups of Curve25519 and Curve448 from RFC 2544 7748. 2546 12.22. Changes in draft-ietf-hip-dex-00 2548 * The Internet Draft was adopted by the HIP WG. 2550 12.23. Changes in draft-moskowitz-hip-rg-dex-06 2551 * A major change in the ENCRYPT parameter to use AES-CTR rather than 2552 AES-CBC. 2554 12.24. Changes in draft-moskowitz-hip-dex-00 2556 * Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 2557 submission. 2559 * Added the change section. 2561 * Added a Definitions section. 2563 * Changed I2 and R2 packets to reflect use of AES-CTR for 2564 ENCRYPTED_KEY parameter. 2566 * Cleaned up KEYMAT Generation text. 2568 * Added Appendix with C code for the ECDH shared secret generation 2569 on an 8 bit processor. 2571 12.25. Changes in draft-moskowitz-hip-dex-01 2573 * Numerous editorial changes. 2575 * New retransmission strategy. 2577 * New HIT generation mechanism. 2579 * Modified layout of ENCRYPTED_KEY parameter. 2581 * Clarify use puzzle difficulty of zero under normal network 2582 conditions. 2584 * Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 2585 MUST). 2587 * Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 2588 and I2). 2590 * HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 2591 echoed in R2 packet. 2593 * Added new author. 2595 12.26. Changes in draft-moskowitz-hip-dex-02 2597 * Introduced formal definition of FOLD function. 2599 * Clarified use of CMAC for puzzle computation in section "Solving 2600 the Puzzle". 2602 * Several editorial changes. 2604 12.27. Changes in draft-moskowitz-hip-dex-03 2606 * Addressed HI crypto agility. 2608 * Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 2610 * Extended the IV in the ENCRYPTED_KEY parameter. 2612 * Introduced forward-references to HIP DEX KEYMAT process and 2613 improved KEYMAT section. 2615 * Replaced Appendix A on "C code for ECC point multiplication" with 2616 short discussion in introduction. 2618 * Updated references. 2620 * Further editorial changes. 2622 12.28. Changes in draft-moskowitz-hip-dex-04 2624 * Improved retransmission extension. 2626 * Updated and strongly revised packet processing rules. 2628 * Updated security considerations. 2630 * Updated IANA considerations. 2632 * Move the HI Algorithm for ECDH to a value of 11. 2634 * Many editorial changes. 2636 13. References 2638 13.1. Normative References 2640 [NIST.SP.800-38B] 2641 Dworkin, M., "Recommendation for block cipher modes of 2642 operation :: the CMAC mode for authentication", National 2643 Institute of Standards and Technology report, 2644 DOI 10.6028/nist.sp.800-38b, 2016, 2645 . 2647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2648 Requirement Levels", BCP 14, RFC 2119, 2649 DOI 10.17487/RFC2119, March 1997, 2650 . 2652 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2653 Counter Mode With IPsec Encapsulating Security Payload 2654 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2655 . 2657 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2658 Control Message Protocol (ICMPv6) for the Internet 2659 Protocol Version 6 (IPv6) Specification", STD 89, 2660 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2661 . 2663 [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the 2664 Host Identity Protocol", RFC 6261, DOI 10.17487/RFC6261, 2665 May 2011, . 2667 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 2668 Routable Cryptographic Hash Identifiers Version 2 2669 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2670 2014, . 2672 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2673 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2674 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2675 . 2677 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2678 Encapsulating Security Payload (ESP) Transport Format with 2679 the Host Identity Protocol (HIP)", RFC 7402, 2680 DOI 10.17487/RFC7402, April 2015, 2681 . 2683 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2684 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2685 May 2017, . 2687 13.2. Informative References 2689 [ATmega328P] 2690 Atmel, "ATmega328P 8-bit AVR Microcontroller with 32K 2691 Bytes In-System Programmable Flash", SEC 2 , 2015, 2692 . 2696 [DH76] Diffie, W. and M. Hellman, "New directions in 2697 cryptography", IEEE Transactions on Information 2698 Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638, 2699 November 1976, . 2701 [EfficientECC] 2702 Nascimento, E., Lopez, J., and R. Dahab, "Efficient and 2703 Secure Elliptic Curve Cryptography for 8-bit AVR 2704 Microcontrollers", Security, Privacy, and Applied 2705 Cryptography Engineering pp. 289-309, 2706 DOI 10.1007/978-3-319-24126-5_17, 2015, 2707 . 2711 [hip-rfc4423-bis] 2712 Moskowitz, R. and M. Komu, "Host Identity Protocol 2713 Architecture", Work in Progress, Internet-Draft, draft- 2714 ietf-hip-rfc4423-bis-20, 14 February 2019, 2715 . 2718 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 2719 Wehrle, "Tailoring end-to-end IP security protocols to the 2720 Internet of Things", 2013 21st IEEE International 2721 Conference on Network Protocols (ICNP), 2722 DOI 10.1109/icnp.2013.6733571, October 2013, 2723 . 2725 [IEEE.802-11.2016] 2726 "IEEE Standard for Information technology-- 2727 Telecommunications and information exchange between 2728 systems Local and metropolitan area networks--Specific 2729 requirements - Part 11: Wireless LAN Medium Access Control 2730 (MAC) and Physical Layer (PHY) Specifications", 2731 IEEE standard, DOI 10.1109/ieeestd.2016.7786995, n.d., 2732 . 2734 [IEEE.802-15-4.2015] 2735 Engineers, I. O. E. A. E., "Information technology - 2736 Telecommunications and information exchange between 2737 systems - Local and metropolitan area networks - Specific 2738 requirements - Part 15.4: Wireless Medium Access Control 2739 (MAC) and Physical Layer (PHY) Specifications for Low-Rate 2740 Wireless Personal Area Networks (WPANs)", IEEE Standard 2741 802.15.4, December 2015, 2742 . 2745 [KeyDerivation] 2746 Dodis, Y., Gennaro, R., Håstad, J., Krawczyk, H., and T. 2747 Rabin, "Randomness Extraction and Key Derivation Using the 2748 CBC, Cascade and HMAC Modes", Advances in Cryptology - 2749 CRYPTO 2004 pp. 494-510, DOI 10.1007/978-3-540-28628-8_30, 2750 2004, . 2752 [LN08] Liu, A. and P. Ning, "TinyECC: A Configurable Library for 2753 Elliptic Curve Cryptography in Wireless Sensor Networks", 2754 2008 International Conference on Information Processing in 2755 Sensor Networks (ipsn 2008), DOI 10.1109/ipsn.2008.47, 2756 April 2008, . 2758 [NIST.SP.800-108] 2759 Chen, L., "Recommendation for key derivation using 2760 pseudorandom functions (revised)", National Institute of 2761 Standards and Technology report, 2762 DOI 10.6028/nist.sp.800-108, 2009, 2763 . 2765 [NIST.SP.800-56C] 2766 Chen, L., "Recommendation for key derivation through 2767 extraction-then-expansion", National Institute of 2768 Standards and Technology report, 2769 DOI 10.6028/nist.sp.800-56c, 2011, 2770 . 2772 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2773 Key Derivation Function (HKDF)", RFC 5869, 2774 DOI 10.17487/RFC5869, May 2010, 2775 . 2777 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2778 Curve Cryptography Algorithms", RFC 6090, 2779 DOI 10.17487/RFC6090, February 2011, 2780 . 2782 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2783 Constrained-Node Networks", RFC 7228, 2784 DOI 10.17487/RFC7228, May 2014, 2785 . 2787 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2788 Kivinen, "Internet Key Exchange Protocol Version 2 2789 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2790 2014, . 2792 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2793 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2794 2016, . 2796 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 2797 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 2798 October 2016, . 2800 [SIGMA] Krawczyk, H., "SIGMA: the ‘SIGn-and-MAc’ Approach to 2801 Authenticated Diffie-Hellman and its Use in the IKE 2802 Protocols", 2003, 2803 . 2805 Appendix A. Calculating Collision Probabilities 2807 The accepted formula for calculating the probability of a collision 2808 is: 2810 p = 1 - e^{-k^2/(2n)} 2812 P Collision Probability 2813 n Total possible population 2814 k Actual population 2816 Appendix B. Password-based two-factor authentication during the HIP DEX 2817 handshake 2819 HIP DEX allows identifying authorized connections based on a two- 2820 factor authentication mechanism. With two-factor authentication, 2821 devices that are authorized to communicate with each other are 2822 required to be pre-provisioned with a shared (group) key. The 2823 Initiator uses this pre-provisioned key to encrypt the 2824 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 2825 the Responder verifies that its challenge in the 2826 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 2827 with the correct key. If verified successfully, the Responder 2828 proceeds with the handshake. Otherwise, it silently drops the I2 2829 packet. 2831 Note that there is no explicit signaling in the HIP DEX handshake for 2832 this behavior. Thus, knowledge of two-factor authentication must be 2833 configured externally prior to the handshake. 2835 Appendix C. IESG Considerations 2837 During IESG review, a concern was raised on the number of SHOULDs in 2838 this document. Here is an analysis of the 57 SHOULDs in HIP DEX. 2840 46 of SHOULDs are also in [RFC7401]. Here are the sections with 2841 SHOULDs that match up with [RFC7401]: 2843 5.2.2. HIP_CIPHER (same as 7401) 2845 6.5. Processing Incoming I1 Packets 2846 3. (same as 7401) 2847 5. (same as 7401) 2849 6.6. Processing Incoming R1 Packets (same as 7401) 2851 6.7. Processing Incoming I2 Packets 2852 3. (same as 7401) 2853 7. (same as 7401) 2854 11. (same as 7401) 2856 6.8. Processing Incoming R2 Packets 2857 5. (same as 7401) 2859 6.9. Processing Incoming NOTIFY Packets 2860 1st para (same as 7401) 2862 6.11. Handling State Loss (same as 7401) 2864 7. HIP Policies (1st and 3rd same as 7401) 2866 Many of the other 11 SHOULDs are due to the nature of constrained 2867 devices and in most cases the text points this out: 2869 In Section 4.1.1, this is clearly adjusting for how the puzzle could 2870 actually be an attack against a constrained device. Same situation 2871 in Section 5.3.2. 2873 The SHOULD in Section 6.3, clearly reflects new work with the new 2874 Sponge Function KDFs: 2876 The keys derived for the Pair-wise Key SA are not used during the HIP 2877 DEX handshake. Instead, these keys are made available as payload 2878 protection keys (e.g., for IPsec). Some payload protection 2879 mechanisms have their own Key Derivation Function, and if so this 2880 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 2881 be used to derive the keys of the Pair-wise Key SA based on the 2882 concatenation of the random values that are contained in the 2883 exchanged ENCRYPTED_KEY parameters. 2885 In Section 6.5, the reason why this is a SHOULD should be clear to 2886 any implementer. That is the HIT Suite list in I1 is a desire on 2887 what suite to use. The Responder may have 'different ideas' about 2888 the Suite to use (like what it supports). Thus it is best that the 2889 Responder selects a DEX HIT, but there are good reasons, in an 2890 implementation not to do so. The implementer should know this and 2891 will deal with it appropriately. 2893 The SHOULDs in Section 6.7 and Section 6.9 are there for 2894 considerations for constrained systems. Some constrained systems 2895 need this approach, others may not. 2897 The 2nd SHOULD in Section 7 follows the same as above. ACLs and 2898 constrained systems tend to go together. 2900 Similarly in Section 8 the SHOULD is again is highlighting 2901 constrained system processing considerations. 2903 Authors' Addresses 2905 Robert Moskowitz (editor) 2906 HTT Consulting 2907 Oak Park, MI 2908 United States of America 2910 Email: rgm@htt-consult.com 2912 Rene Hummen 2913 Hirschmann Automation and Control 2914 Stuttgarter Strasse 45-51 2915 72654 Neckartenzlingen 2916 Germany 2918 Email: rene.hummen@belden.com 2920 Miika Komu 2921 Ericsson Research, Finland 2922 Hirsalantie 11 2923 FI-02420 Jorvas 2924 Finland 2926 Email: miika.komu@ericsson.com