idnits 2.17.1 draft-ietf-hip-dex-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2017) is 2638 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-15 Summary: 0 errors (**), 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: August 9, 2017 Hirschmann Automation and Control 6 February 5, 2017 8 HIP Diet EXchange (DEX) 9 draft-ietf-hip-dex-05 11 Abstract 13 This document specifies the Host Identity Protocol Diet EXchange (HIP 14 DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The 15 HIP DEX protocol design aims at reducing the overhead of the employed 16 cryptographic primitives by omitting public-key signatures and hash 17 functions. In doing so, the main goal is to still deliver similar 18 security properties to HIPv2. 20 The HIP DEX protocol is primarily designed for computation or memory- 21 constrained sensor/actuator devices. Like HIPv2, it is expected to 22 be used together with a suitable security protocol such as the 23 Encapsulated Security Payload (ESP) for the protection of upper layer 24 protocol data. In addition, HIP DEX can also be used as a keying 25 mechanism for security primitives at the MAC layer, e.g., for IEEE 26 802.15.4 networks. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 9, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 64 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 67 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 70 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 71 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9 72 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9 74 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11 75 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12 76 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16 77 4.1.4. User Data Considerations . . . . . . . . . . . . . . 17 78 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 79 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 17 80 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 17 81 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 18 82 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 18 83 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 19 84 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 19 85 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 19 86 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 20 87 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 21 88 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 22 89 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 24 90 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 25 91 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 26 92 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 26 93 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 26 94 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 27 95 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 27 96 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 28 97 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 31 98 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31 99 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32 100 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35 101 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38 102 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39 103 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40 104 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40 105 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40 106 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 40 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 109 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 110 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 43 111 12.1. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 43 112 12.2. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44 113 12.3. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44 114 12.4. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44 115 12.5. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44 116 12.6. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 44 117 12.7. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 44 118 12.8. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 44 119 12.9. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 120 12.10. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 45 121 12.11. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 45 122 12.12. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 123 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 124 13.1. Normative References . . . . . . . . . . . . . . . . . . 46 125 13.2. Informative References . . . . . . . . . . . . . . . . . 47 126 Appendix A. Password-based two-factor authentication during the 127 HIP DEX handshake . . . . . . . . . . . . . . . . . 50 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 130 1. Introduction 132 This document specifies the Host Identity Protocol Diet EXchange (HIP 133 DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity 134 Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol 135 semantics as well as the general packet structure of HIPv2. Hence, 136 it is recommended that [RFC7401] is well-understood before reading 137 this document. 139 The main differences between HIP BEX and HIP DEX are: 141 1. HIP DEX uses a different set of cryptographic primitives compared 142 to HIP BEX with the goal to reduce the protocol overhead: 144 * Peer authentication and key agreement in HIP DEX are based on 145 static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This 146 replaces the use of public-key signatures and ephemeral 147 Diffie-Hellman key pairs in HIPv2. 149 * HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC 150 as its MACing function. In contrast, HIPv2 currently supports 151 AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC- 152 SHA-384 for MACing. 154 * HIP DEX defines a simple fold function to efficiently generate 155 HITs, whereas the HIT generation of HIPv2 is based on SHA-1, 156 SHA-256, or SHA-384. 158 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of 159 HIPv2 due to the removal of the ephemeral Diffie-Hellman key 160 agreement. 162 3. HIP DEX forfeits the use of digital signatures with the removal 163 of a hash function. Peer authentication with HIP DEX, therefore, 164 is based on the use of the ECDH derived key in the HIP_MAC 165 parameter. 167 4. With HIP DEX, the ECDH derived key is only used to protect HIP 168 packets. Separate session key(s) are used to protect the 169 transmission of upper layer protocol data. These session key(s) 170 are established via a new secret exchange during the handshake. 172 5. HIP DEX introduced a new, optional retransmission strategy that 173 is specifically designed to handle potentially extensive 174 processing times of the employed cryptographic operations on 175 computationally constrained devices. 177 By eliminating the need for public-key signatures and the ephemeral 178 DH key agreement, HIP DEX reduces the computation, energy, 179 transmission, and memory requirements for public-key cryptography 180 (see [LN08]) in the HIPv2 protocol design. Moreover, by dropping the 181 cryptographic hash function, HIP DEX affords a more efficient 182 protocol implementation than HIP BEX with respect to the 183 corresponding computation and memory requirements. This makes HIP 184 DEX especially suitable for constrained devices as defined in 185 [RFC7228]. 187 This document focuses on the protocol specifications related to 188 differences between HIP BEX and HIP DEX. Where differences are not 189 called out explicitly, the protocol specification of HIP DEX is the 190 same as defined in [RFC7401]. 192 1.1. The HIP Diet EXchange (DEX) 194 The HIP Diet EXchange is a two-party cryptographic protocol used to 195 establish a secure communication context between hosts. The first 196 party is called the Initiator and the second party the Responder. 197 The four-packet exchange helps to make HIP DEX Denial of Service 198 (DoS) resilient. The Initiator and the Responder exchange their 199 static Elliptic Curve Diffie-Hellman (ECDH) keys in the 2nd and 3rd 200 handshake packet. The parties then authenticate each other in the 201 3rd and 4th handshake packet based on the ECDH-derived keying 202 material. The Initiator and the Responder additionally transmit 203 keying material for the session key in these last two handshake 204 packets. This is to prevent overuse of the static ECDH-derived 205 keying material. Moreover, the Responder starts a puzzle exchange in 206 the 2nd packet and the Initiator completes this exchange in the 3rd 207 packet before the Responder performs computationally expensive 208 operations or stores any state from the exchange. Given this 209 handshake structure, HIP DEX operationally is very similar to HIP 210 BEX. Moreover, the employed model is also fairly equivalent to 211 802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise Transient 212 Key, but handled in a single exchange. 214 HIP DEX does not have the option to encrypt the Host Identity of the 215 Initiator in the 3rd packet. The Responder's Host Identity also is 216 not protected. Thus, contrary to HIPv2, HIP DEX does not provide for 217 end-point anonymity and any signaling that indicates such anonymity 218 should be ignored. 220 As in [RFC7401], data packets start to flow after the 4th packet. 221 The 3rd and 4th HIP packets may carry data payload in the future. 222 However, the details of this may be defined later. 224 An existing HIP association can be updated with the update mechanism 225 defined in [RFC7401]. Likewise, the association can be torn down 226 with the defined closing mechanism for HIPv2 if it is no longer 227 needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of 228 the original HIPv2 specification. 230 Finally, HIP DEX is designed as an end-to-end authentication and key 231 establishment protocol. As such, it can be used in combination with 232 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 233 end-to-end security protocols. In addition, HIP DEX can also be used 234 as a keying mechanism for security primitives at the MAC layer, e.g., 235 for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth 236 mentioning that the HIP DEX base protocol does not cover all the 237 fine-grained policy control found in Internet Key Exchange Version 2 238 (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway 239 policies. Thus, HIP DEX is not a replacement for IKEv2. 241 1.2. Memo Structure 243 The rest of this memo is structured as follows. Section 2 defines 244 the central keywords, notation, and terms used throughout this 245 document. Section 3 defines the structure of the Host Identity and 246 its various representations. Section 4 gives an overview of the HIP 247 Diet EXchange protocol. Sections 5 and 6 define the detailed packet 248 formats and rules for packet processing. Finally, Sections 7, 9, and 249 10 discuss policy, security, and IANA considerations, respectively. 251 2. Terms and Definitions 253 2.1. Requirements Terminology 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in RFC 2119 [RFC2119]. 259 2.2. Notation 261 [x] indicates that x is optional. 263 {x} indicates that x is encrypted. 265 X(y) indicates that y is a parameter of X. 267 i indicates that x exists i times. 269 --> signifies "Initiator to Responder" communication (requests). 271 <-- signifies "Responder to Initiator" communication (replies). 273 | signifies concatenation of information - e.g., X | Y is the 274 concatenation of X and Y. 276 FOLD (X, K) denotes the partitioning of X into n K-bit segments and 277 the iterative folding of these segments via XOR. I.e., X = x_1, 278 x_2, ..., x_n, where x_i is of length K and the last segment x_n 279 is padded to length K by appending 0 bits. FOLD then is computed 280 as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 282 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 283 the MAC function M on the input x. 285 2.3. Definitions 287 HIP Diet Exchange (DEX): The ECDH-based HIP handshake for 288 establishing a new HIP association. 290 Host Identity (HI): The static ECDH public key that represents the 291 identity of the host. In HIP DEX, a host proves ownership of the 292 private key belonging to its HI by creating a HIP_MAC with the 293 derived ECDH key (c.f. Section 3). 295 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 296 is generated by folding the HI (c.f. Section 3). 298 HIT Suite: A HIT Suite groups all algorithms that are required to 299 generate and use an HI and its HIT. In particular, these 300 algorithms are: 1) ECDH and 2) FOLD. 302 HIP association: The shared state between two peers after completion 303 of the HIP DEX handshake. 305 Initiator: The host that initiates the HIP DEX handshake. This role 306 is typically forgotten once the handshake is completed. 308 Responder: The host that responds to the Initiator in the HIP DEX 309 handshake. This role is typically forgotten once the handshake is 310 completed. 312 Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is 313 redefined as CMAC. Still, note that CMAC is a message 314 authentication code (MAC) and not a cryptographic hash function. 315 Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where 316 RHASH is used. Moreover, RHASH has different security properties 317 in HIP DEX and is not used for HIT generation. 319 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 320 natural output length of RHASH in bits. 322 CMAC: The Cipher-based Message Authentication Code with the 128-bit 323 Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. 325 CKDF: CMAC-based Key Derivation Function. 327 3. Host Identity (HI) and its Structure 329 In this section, the properties of the Host Identity and Host 330 Identity Tag are discussed, and the exact format for them is defined. 331 In HIP, the public key of an asymmetric key pair is used as the Host 332 Identity (HI). Correspondingly, the host itself is defined as the 333 entity that holds the private key of the key pair. See the HIP 334 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 335 details on the difference between an identity and the corresponding 336 identifier. 338 HIP DEX implementations MUST support the Elliptic Curve Diffie- 339 Hellman (ECDH) [RFC6090] key exchange for generating the HI as 340 defined in Section 5.2.3. No additional algorithms are supported at 341 this time. 343 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 344 in the handshake packets to represent the HI. The DEX Host Identity 345 Tag (HIT) is different from the BEX HIT in two ways: 347 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). 349 o The DEX HIT is not generated via a cryptographic hash. Rather, it 350 is a compression of the HI. 352 Due to the latter property, an attacker may be able to find a 353 collision with a HIT that is in use. Hence, policy decisions such as 354 access control MUST NOT be based solely on the HIT. Instead, the HI 355 of a host SHOULD be considered. 357 Carrying HIs and HITs in the header of user data packets would 358 increase the overhead of packets. Thus, it is not expected that 359 these parameters are carried in every packet, but other methods are 360 used to map the data packets to the corresponding HIs. In some 361 cases, this allows to use HIP DEX without any additional headers in 362 the user data packets. For example, if ESP is used to protect data 363 traffic, the Security Parameter Index (SPI) carried in the ESP header 364 can be used to map the encrypted data packet to the correct HIP DEX 365 association. 367 3.1. Host Identity Tag (HIT) 369 With HIP DEX, the HIT is a 128-bit value - a compression of the HI 370 prepended with a specific prefix. There are two advantages of using 371 a hashed encoding over the actual variable-sized public key in 372 protocols. First, the fixed length of the HIT keeps packet sizes 373 manageable and eases protocol coding. Second, it presents a 374 consistent format for the protocol, independent of the underlying 375 identity technology in use. 377 The structure of the HIT is based on RFC 7343 [RFC7343], called 378 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 379 consists of three parts: first, an IANA assigned prefix to 380 distinguish it from other IPv6 addresses. Second, a four-bit 381 encoding of the algorithms that were used for generating the HI and 382 the compressed representation of the HI. Third, a 96-bit hashed 383 representation of the HI. In contrast to HIPv2, HIP DEX employs HITs 384 that are NOT generated by means of a cryptographic hash. Instead, 385 the HI is compressed to 96 bits as defined in the following section. 387 3.2. Generating a HIT from an HI 389 The HIT does not follow the exact semantics of an ORCHID as there is 390 no hash function in HIP DEX. Still, its structure is strongly 391 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 392 is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used 393 for the four bits of the Orchid Generation Algorithm (OGA) field in 394 the ORCHID. The hash representation in an ORCHID is replaced with 395 FOLD(HI,96). 397 4. Protocol Overview 399 This section gives a simplified overview of the HIP DEX protocol 400 operation and does not contain all the details of the packet formats 401 or the packet processing steps. Section 5 and Section 6 describe 402 these aspects in more detail and are normative in case of any 403 conflicts with this section. Importantly, the information given in 404 this section focuses on the differences between the HIPv2 and HIP DEX 405 protocol specifications. 407 4.1. Creating a HIP Association 409 By definition, the system initiating a HIP Diet EXchange is the 410 Initiator, and the peer is the Responder. This distinction is 411 typically forgotten once the handshake completes, and either party 412 can become the Initiator in future communications. 414 The HIP Diet EXchange serves to manage the establishment of state 415 between an Initiator and a Responder. The first packet, I1, 416 initiates the exchange, and the last three packets, R1, I2, and R2, 417 constitute an authenticated Diffie-Hellman [DH76] key exchange for 418 the Master Key SA generation. This Master Key SA is used by the 419 Initiator and the Responder to wrap secret keying material in the I2 420 and R2 packets. Based on the exchanged keying material, the peers 421 then derive a Pair-wise Key SA if cryptographic keys are needed, 422 e.g., for ESP-based protection of user data. 424 The Initiator first sends a trigger packet, I1, to the Responder. 425 This packet contains the HIT of the Initiator and the HIT of the 426 Responder, if it is known. Moreover, the I1 packet initializes the 427 negotiation of the Diffie-Hellman group that is used for generating 428 the the Master Key SA. Therefore, the I1 packet contains a list of 429 Diffie-Hellman Group IDs supported by the Initiator. Note that in 430 some cases it may be possible to replace this trigger packet by some 431 other form of a trigger, in which case the protocol starts with the 432 Responder sending the R1 packet. In such cases, another mechanism to 433 convey the Initiator's supported DH Groups (e.g., by using a default 434 group) must be specified. 436 The second packet, R1, starts the actual authenticated Diffie-Hellman 437 key exchange. It contains a puzzle - a cryptographic challenge that 438 the Initiator must solve before continuing the exchange. The level 439 of difficulty of the puzzle can be adjusted based on level of trust 440 with the Initiator, current load, or other factors. In addition, the 441 R1 contains the Responder's Diffie-Hellman parameter and lists of 442 cryptographic algorithms supported by the Responder. Based on these 443 lists, the Initiator can continue, abort, or restart the handshake 444 with a different selection of cryptographic algorithms. 446 In the I2 packet, the Initiator MUST display the solution to the 447 received puzzle. Without a correct solution, the I2 packet is 448 discarded. The I2 also contains a key wrap parameter that carries 449 secret keying material of the Initiator. This keying material is 450 only half of the final session key. The packet is authenticated by 451 the sender (Initiator) via a MAC. 453 The R2 packet acknowledges the receipt of the I2 packet and completes 454 the handshake. The R2 contains a key wrap parameter that carries the 455 rest of the keying material of the Responder. The packet is 456 authenticated by the sender (Responder) via a MAC. 458 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 459 and "ENC(DH,y)" refer to the random values x and y that are wrapped 460 based on the Master Key SA (indicated by ENC and DH). Note that x 461 and y each constitute half of the final session key material. The 462 packets also contain other parameters that are not shown in this 463 figure. 465 Initiator Responder 467 I1: 468 ---------------------------------> 469 remain stateless 470 R1: puzzle, HI 471 <-------------------------------- 472 solve puzzle 473 perform ECDH 474 encrypt x 475 I2: solution, HI, ENC(DH,x), mac 476 ---------------------------------> 477 check puzzle 478 perform ECDH 479 check MAC 480 decrypt x 481 encrypt y 482 R2: ENC(DH,y), mac 483 <--------------------------------- 484 check MAC 485 decrypt y 487 Figure 1: High-level overview of the HIP Diet EXchange 489 4.1.1. HIP Puzzle Mechanism 491 The purpose of the HIP puzzle mechanism is to protect the Responder 492 from a number of denial-of-service threats. It allows the Responder 493 to delay state creation until receiving the I2 packet. Furthermore, 494 the puzzle allows the Responder to use a fairly cheap calculation to 495 check that the Initiator is "sincere" in the sense that it has 496 churned enough CPU cycles in solving the puzzle. 498 The puzzle mechanism enables a Responder to immediately reject an I2 499 packet if it does not contain a valid puzzle solution. To verify the 500 puzzle solution, the Responder only has to compute a single CMAC 501 operation. After a successful puzzle verification, the Responder can 502 securely create session-specific state and perform CPU-intensive 503 operations such as a Diffie-Hellman key generation. By varying the 504 difficulty of the puzzle, the Responder can frustrate CPU or memory 505 targeted DoS attacks. Under normal network conditions, the puzzle 506 difficulty SHOULD be zero, thus effectively reverting the puzzle 507 mechanism to a cookie-based DoS protection mechanism. Without 508 setting the puzzle difficulty to zero under normal network 509 conditions, potentially scarce computation resources at the Initiator 510 would be churned unnecessarily. 512 Conceptually, the puzzle mechanism in HIP DEX is the same as in 513 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 514 [RFC7401] for more detailed information about the employed mechanism. 515 Notably, the only differences between the puzzle mechanism in HIP DEX 516 and HIPv2 are that HIP DEX does not employ pre-computation of R1 517 packets and uses CMAC instead of a hash function for solving and 518 verifying a puzzle. The implications of these changes on the puzzle 519 implementation are discussed in Section 6.1. 521 4.1.2. HIP State Machine 523 The HIP DEX state machine has the same states as the HIPv2 state 524 machine (see 4.4. in [RFC7401]). However, HIP DEX features a 525 retransmission strategy with an optional reception acknowledgement 526 for the I2 packet. The goal of this additional acknowledgement is to 527 reduce premature I2 retransmissions in case of devices with low 528 computation resources [HWZ13]. As a result, there are minor changes 529 regarding the transitions in the HIP DEX state machine. The 530 following section documents these differences compared to HIPv2. 532 4.1.2.1. HIP DEX Retransmission Mechanism 534 For the retransmission of I1 and I2 packets, the Initiator adopts the 535 retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). 536 This strategy is based on a timeout that is set to a value larger 537 than the worst-case anticipated round-trip time (RTT). For each 538 received I1 or I2 packet, the Responder sends an R1 or R2 packet, 539 respectively. This design trait enables the Responder to remain 540 stateless until the reception and successful processing of the I2 541 packet. The Initiator stops retransmitting I1 or I2 packets after 542 the reception of the corresponding R1 or R2. If the Initiator did 543 not receive an R1 packet after I1_RETRIES_MAX tries, it stops I1 544 retransmissions. Likewise, it stops retransmitting the I2 packet 545 after I2_RETRIES_MAX unsuccessful tries. 547 For repeatedly received I2 packets, the Responder SHOULD NOT perform 548 operations related to the Diffie-Hellman key exchange or the keying 549 material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD 550 re-use the previously established state to re-create the 551 corresponding R2 packet in order to prevent unnecessary computation 552 overhead. 554 The potentially high processing time of an I2 packet at a (resource- 555 constrained) Responder may cause premature retransmissions if the 556 time required for I2 transmission and processing exceeds the RTT- 557 based retransmission timeout. Thus, the Initiator should also take 558 the processing time of the I2 packet at the Responder into account 559 for retransmission purposes. To this end, the Responder MAY notify 560 the Initiator about the anticipated delay once the puzzle solution 561 was successfully verified and if the remaining I2 packet processing 562 incurs a high processing delay. The Responder MAY therefore send a 563 NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator 564 before the Responder commences the ECDH operation. The NOTIFY packet 565 serves as an acknowledgement for the I2 packet and consists of a 566 NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 567 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 568 contains the anticipated remaining processing time for the I2 packet 569 in milliseconds as two-octet Notification Data. This processing time 570 can, e.g., be estimated by measuring the computation time of the ECDH 571 key derivation operation during the Responder start-up procedure. 572 After the I2 processing has finished, the Responder sends the regular 573 R2 packet. 575 When the Initiator receives the NOTIFY packet, it sets the I2 576 retransmission timeout to the I2 processing time indicated in the 577 NOTIFICATION parameter plus half the RTT-based timeout value. In 578 doing so, the Initiator MUST NOT set the retransmission timeout to a 579 higher value than allowed by a local policy. This is to prevent 580 unauthenticated NOTIFY packets from maliciously delaying the 581 handshake beyond a well-defined upper bound in case of a lost R2 582 packet. At the same time, this extended retransmission timeout 583 enables the Initiator to defer I2 retransmissions until the point in 584 time when the Responder should have completed its I2 packet 585 processing and the network should have delivered the R2 packet 586 according to the employed worst-case estimates. 588 4.1.2.2. HIP State Processes 590 HIP DEX clarifies or introduces the following new transitions. 592 System behavior in state I2-SENT, Table 1. 594 +---------------------+---------------------------------------------+ 595 | Trigger | Action | 596 +---------------------+---------------------------------------------+ 597 | Receive NOTIFY, | Set I2 retransmission timer to value in | 598 | process | I2_ACKNOWLEDGEMENT Notification Data plus | 599 | | 1/2 RTT-based timeout value and stay at | 600 | | I2-SENT | 601 | | | 602 | Timeout | Increment trial counter | 603 | | | 604 | | If counter is less than I2_RETRIES_MAX, | 605 | | send I2, reset timer to RTT-based timeout, | 606 | | and stay at I2-SENT | 607 | | | 608 | | If counter is greater than I2_RETRIES_MAX, | 609 | | go to E-FAILED | 610 +---------------------+---------------------------------------------+ 612 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 614 4.1.2.3. Simplified HIP State Diagram 616 The following diagram shows the major state transitions. Transitions 617 based on received packets implicitly assume that the packets are 618 successfully authenticated or processed. 620 +--+ +----------------------------+ 621 recv I1, send R1 | | | | 622 | v v | 623 +--------------+ recv I2, send R2 | 624 +----------------| UNASSOCIATED |----------------+ | 625 datagram | +--+ +--------------+ | | 626 to send, | | | Alg. not supported, | | 627 send I1 | | | send I1 | | 628 . v | v | | 629 . +---------+ recv I2, send R2 | | 630 +---->| I1-SENT |--------------------------------------+ | | 631 | +---------+ +----------------------+ | | | 632 | | recv R1, | recv I2, send R2 | | | | 633 | v send I2 | v v v | 634 | +---------+----------+ +---------+ | 635 | +--->| I2-SENT |<-------------+ +------------| R2-SENT |<---+ | 636 | | +---------+ recv NOTIFY, | | +---------+ | | 637 | | | | | reset timer | | data or| | | 638 | |recv R1, | | +--------------+ | EC timeout| | | 639 | |send I2 +-|--------------------+ | receive I2,| | 640 | | | | +-------------+ | send R2| | 641 | | | +-------->| ESTABLISHED |<---------+ | | 642 | | | recv R2 +-------------+ | | 643 | | | | | | receive I2, send R2 | | 644 | | +------------+ | +-------------------------------+ | 645 | | | +-----------+ | | 646 | | | no packet sent/received| +---+ | | 647 | | | for UAL min, send CLOSE| | |timeout | | 648 | | | v v |(UAL+MSL) | | 649 | | | +---------+ |retransmit | | 650 +--|----------|------------------------| CLOSING |-+CLOSE | | 651 | | +---------+ | | 652 | | | | | | | | 653 +----------|-------------------------+ | | +----------------+ | 654 | | +-----------+ +------------------|--+ 655 | | |recv CLOSE, recv CLOSE_ACK | | 656 | +-------------+ |send CLOSE_ACK or timeout | | 657 | recv CLOSE, | | (UAL+MSL) | | 658 | send CLOSE_ACK v v | | 659 | +--------+ receive I2, send R2 | | 660 +---------------------| CLOSED |------------------------------+ | 661 +--------+ | 662 ^ | | | 663 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 664 +-+ +------------------------------------+ 666 4.1.3. HIP DEX Security Associations 668 HIP DEX establishes two Security Associations (SA), one for the 669 Diffie-Hellman derived key, or Master Key, and one for the session 670 key, or Pair-wise Key. 672 4.1.3.1. Master Key SA 674 The Master Key SA is used to authenticate HIP packets and to encrypt 675 selected HIP parameters in the HIP DEX packet exchanges. Since only 676 a small amount of data is protected by this SA, it can be long-lived 677 with no need for rekeying. 679 The Master Key SA contains the following elements: 681 o Source HIT 683 o Destination HIT 685 o HIP_Encrypt Key 687 o HIP_MAC Key 689 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 690 Hellman derived key as described in Section 6.3. Their length is 691 determined by the HIP_CIPHER. 693 4.1.3.2. Pair-wise Key SA 695 The Pair-wise Key SA is used to authenticate and to encrypt user 696 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 697 The Pair-wise Key SA elements are defined by the data transform (e.g. 698 ESP_TRANSFORM [RFC7402]). 700 The keys for the Pair-wise Key SA are derived based on the wrapped 701 keying material exchanged in the ENCRYPTED_KEY parameter (see 702 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 703 keying material of the two peers is concatenated. This concatenation 704 forms the input to a Key Derivation Function (KDF). If the data 705 transform does not specify its own KDF, the key derivation function 706 defined in Section 6.3 is used. Even though this input is randomly 707 distributed, a KDF Extract phase may be needed to get the proper 708 length for the input to the KDF Expand phase. 710 4.1.4. User Data Considerations 712 The User Data Considerations in Section 4.5. of [RFC7401] also apply 713 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 714 Loss of state due to system reboot may be a critical performance 715 issue for resource-constrained devices. Thus, implementors MAY 716 choose to use non-volatile, secure storage for HIP states in order 717 for them to survive a system reboot. This will limit state loss 718 during reboots to only those situations with an SA timeout. 720 5. Packet Formats 722 5.1. Payload Format 724 HIP DEX employs the same fixed HIP header and payload structure as 725 HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also 726 apply to HIP DEX. 728 5.2. HIP Parameters 730 The HIP parameters carry information that is necessary for 731 establishing and maintaining a HIP association. For example, the 732 peer's public keys as well as the signaling for negotiating ciphers 733 and payload handling are encapsulated in HIP parameters. Additional 734 information, meaningful for end-hosts or middleboxes, may also be 735 included in HIP parameters. The specification of the HIP parameters 736 and their mapping to HIP packets and packet types is flexible to 737 allow HIP extensions to define new parameters and new protocol 738 behavior. 740 In HIP packets, HIP parameters are ordered according to their numeric 741 type number and encoded in TLV format. 743 HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of 744 [RFC7401] where possible. Still, HIP DEX further restricts and/or 745 extends the following existing parameter types: 747 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 749 o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. 751 o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. 753 o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, 754 SOLUTION, and HIP_MAC parameters (see Section 6.1 and 755 Section 6.2). 757 In addition, HIP DEX introduces the following new parameter: 759 +------------------+------+----------+------------------------------+ 760 | TLV | Type | Length | Data | 761 +------------------+------+----------+------------------------------+ 762 | ENCRYPTED_KEY | 643 | variable | Encrypted container for the | 763 | | | | session key exchange | 764 +------------------+------+----------+------------------------------+ 766 5.2.1. DH_GROUP_LIST 768 The DH_GROUP_LIST parameter contains the list of supported DH Group 769 IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With 770 HIP DEX, the DH Group IDs are restricted to: 772 Group KDF Value 774 NIST P-256 [RFC5903] CKDF 7 775 NIST P-384 [RFC5903] CKDF 8 776 NIST P-521 [RFC5903] CKDF 9 777 SECP160R1 [SECG] CKDF 10 778 Curve25519 [RFC7748] CKDF 11 779 Curve448 [RFC7748] CKDF 12 781 The ECDH groups with values 7 - 9 are defined in [RFC5903] and 782 [RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of 783 [RFC7401]. These curves, when used with HIP MUST have a co-factor of 784 1. 786 The ECDH groups with values 11 and 12 are defined in [RFC7748]. 787 These curves have cofactors of 8 and 4 (respectively). 789 5.2.2. HIP_CIPHER 791 The HIP_CIPHER parameter contains the list of supported cipher 792 algorithms to be used for encrypting the contents of the ENCRYPTED 793 and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 794 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited 795 to: 797 Suite ID Value 799 RESERVED 0 800 NULL-ENCRYPT 1 ([RFC2410]) 801 AES-128-CTR 5 ([RFC3686]) 803 Mandatory implementation: AES-128-CTR. Implementors SHOULD support 804 NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT 805 offer or accept this value unless explicitly configured for testing/ 806 debugging of HIP. 808 5.2.3. HOST_ID 810 The HOST_ID parameter conveys the Host Identity (HI) along with 811 optional information about a host. It is defined in Section 5.2.9 of 812 [RFC7401]. 814 HIP DEX uses the public portion of a host's static ECDH key-pair as 815 the HI. Correspondingly, HIP DEX limits the HI algorithms to the 816 following new profile: 818 Algorithm profiles Value 820 ECDH 11 [RFC6090] (REQUIRED) 822 HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 823 Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is 824 encoded in the "ECC curve" field of the HOST_ID parameter. The 825 supported DH Group IDs are defined in Section 5.2.1. 827 5.2.4. HIT_SUITE_LIST 829 The HIT_SUITE_LIST parameter contains a list of the supported HIT 830 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 831 Initiator can determine which source HIT Suite IDs are supported by 832 the Responder. The HIT_SUITE_LIST parameter is defined in 833 Section 5.2.10 of [RFC7401]. 835 The following new HIT Suite ID is defined for HIP DEX, and the 836 relationship between the four-bit ID value used in the OGA ID field 837 and the eight-bit encoding within the HIT_SUITE_LIST ID field is 838 clarified: 840 HIT Suite Four-bit ID Eight-bit encoding 842 ECDH/FOLD 8 0x80 844 Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field 845 allows the peers to distinguish a HIP DEX handshake from a HIPv2 846 handshake. The Responder MUST respond with a HIP DEX HIT suite ID 847 when the HIT of the Initiator is a HIP DEX HIT. 849 5.2.5. ENCRYPTED_KEY 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 / Encrypted value / 856 / / 857 / +-------------------------------+ 858 / | Padding | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Type 643 862 Length length in octets, excluding Type, Length, and 863 Padding 864 Encrypted The value is encrypted using an encryption algorithm 865 value as defined in the HIP_CIPHER parameter. 867 The ENCRYPTED_KEY parameter encapsulates a random value that is later 868 used in the session key creation process (see Section 6.3). This 869 random value MUST have a length of at least 64 bit. The puzzle value 870 #I and the puzzle solution #J (see [RFC7401]) are used as the 871 initialization vector (IV) for the encryption process. To this end, 872 the IV is computed as FOLD(I | J, 128). Moreover, a 16 bit counter 873 value, which is initialized to zero on first use, is appended to the 874 IV value in order to guarantee that a non-repeating nonce is fed to 875 the encryption algorithm defined by the HIP_CIPHER. 877 Once this encryption process is completed, the "encrypted value" data 878 field is ready for inclusion in the Parameter. If necessary, 879 additional Padding for 8-byte alignment is then added according to 880 the rules of TLV Format in [RFC7401]. 882 5.3. HIP Packets 884 HIP DEX uses the same eight basic HIP packets as HIPv2 (see 885 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake 886 (I1, R1, I2, and R2), one is for updating an association (UPDATE), 887 one is for sending notifications (NOTIFY), and two are for closing 888 the association (CLOSE and CLOSE_ACK). There are some differences 889 regarding the HIP parameters that are included in the handshake 890 packets concerning HIP BEX and HIP DEX. This section covers these 891 differences for the DEX packets. Packets not discussed here, follow 892 the structure defined in [RFC7401]. 894 An important difference between packets in HIP BEX and HIP DEX is 895 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 896 included in HIP DEX. Thus, the R1 packet is completely unprotected 897 and can be spoofed. As a result, negotiation parameters contained in 898 the R1 packet have to be re-included in later, protected packets in 899 order to detect and prevent potential downgrading attacks. Moreover, 900 the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not 901 covered by a signature and purely rely on the HIP_MAC parameter for 902 packet authentication. The processing of these packets is changed 903 accordingly. 905 In the future, an optional upper-layer payload MAY follow the HIP 906 header. The Next Header field in the header indicates if there is 907 additional data following the HIP header. 909 5.3.1. I1 - the HIP Initiator Packet 911 The HIP header values for the I1 packet: 913 Header: 914 Packet Type = 1 915 SRC HIT = Initiator's HIT 916 DST HIT = Responder's HIT, or NULL 918 IP ( HIP ( DH_GROUP_LIST ) ) 920 Valid control bits: none 922 The I1 packet contains the fixed HIP header and the Initiator's 923 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 924 type as defined in Section 5.2.4. 926 Regarding the Responder's HIT, the Initiator may receive this HIT 927 either from a DNS lookup of the Responder's FQDN, from some other 928 repository, or from a local table. The Responder's HIT also MUST be 929 of a HIP DEX type. If the Initiator does not know the Responder's 930 HIT, it may attempt to use opportunistic mode by using NULL (all 931 zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for 932 detailed information about the "HIP Opportunistic Mode". 934 As the Initiator's and the Responder's HITs are compressions of the 935 employed HIs, they determine the DH Group ID that must be used in 936 order to successfully conclude the triggered handshake. HITs, 937 however, only include the OGA ID identifying the HI algorithm. They 938 do not include information about the specific group ID of the HI. To 939 inform the Responder about its employed and its otherwise supported 940 DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST 941 parameter in the I1 packet. This parameter MUST include the DH group 942 ID that corresponds to the currently employed Initiator HIT as the 943 first list element. With HIP DEX, the DH_GROUP_LIST parameter MUST 944 only include ECDH groups defined in Section 5.2.1. 946 Since this packet is so easy to spoof even if it were protected, no 947 attempt is made to add to its generation or processing cost. As a 948 result, the DH_GROUP_LIST in the I1 packet is not protected. 950 Implementations MUST be able to handle a storm of received I1 951 packets, discarding those with common content that arrive within a 952 small time delta. 954 5.3.2. R1 - the HIP Responder Packet 956 The HIP header values for the R1 packet: 958 Header: 959 Packet Type = 2 960 SRC HIT = Responder's HIT 961 DST HIT = Initiator's HIT 963 IP ( HIP ( [ R1_COUNTER, ] 964 PUZZLE, 965 DH_GROUP_LIST, 966 HIP_CIPHER, 967 HOST_ID, 968 HIT_SUITE_LIST, 969 TRANSPORT_FORMAT_LIST, 970 [ <, ECHO_REQUEST_UNSIGNED >i ]) 972 Valid control bits: A 974 If the Responder's HI is an anonymous one, the A control MUST be set. 976 The Initiator's HIT MUST match the one received in the I1 packet if 977 the R1 is a response to an I1. If the Responder has multiple HIs, 978 the Responder's HIT MUST match the Initiator's request. If the 979 Initiator used opportunistic mode, the Responder may select among its 980 HIs as described below. See Section 4.1.8 of [RFC7401] for detailed 981 information about the "HIP Opportunistic Mode". 983 The R1 packet generation counter is used to determine the currently 984 valid generation of puzzles. The value is increased periodically, 985 and it is RECOMMENDED that it is increased at least as often as 986 solutions to old puzzles are no longer accepted. 988 The Puzzle contains a Random value #I and the puzzle difficulty K. 989 The difficulty K indicates the number of lower-order bits, in the 990 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 991 SHOULD set K to zero by default and only increase the puzzle 992 difficulty to protect against a DoS attack targeting the HIP DEX 993 handshake. A puzzle difficulty of zero effectively turns the puzzle 994 mechanism into a return-routablility test and is strongly encouraged 995 during normal operation in order to conserve energy resources as well 996 as to prevent unnecessary handshake delay in case of a resource- 997 constrained Initiator. 999 The DH_GROUP_LIST parameter contains the Responder's order of 1000 preference based on which it chose the ECDH key contained in the 1001 HOST_ID parameter (see below). This allows the Initiator to 1002 determine whether its own DH_GROUP_LIST in the I1 packet was 1003 manipulated by an attacker. There is a further risk that the 1004 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 1005 packet cannot be authenticated in HI DEX. Thus, this parameter is 1006 repeated in the R2 packet to allow for a final, cryptographically 1007 secured validation. 1009 The HIP_CIPHER contains the encryption algorithms supported by the 1010 Responder to protect the key exchange, in the order of preference. 1011 All implementations MUST support the AES-CTR [RFC3686]. 1013 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 1014 supported and preferred HIT Suites. It enables a Responder to notify 1015 the Initiator about other available HIT suites than the one used in 1016 the current handshake. Based on the received HIT_SUITE_LIST, the 1017 Initiator MAY decide to abort the current handshake and initiate a 1018 new handshake with a different mutually supported HIT suite. This 1019 mechanism can, e.g., be used to move from an initial HIP DEX 1020 handshake to a HIP BEX handshake for peers supporting both protocol 1021 variants. 1023 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 1024 and the Responder HIT in the I1 packet. Specifically, if the I1 1025 contains a Responder HIT, the Responder verifies that this HIT 1026 matches the required DH group based on the received DH_GROUP_LIST 1027 parameter included in the I1. In case of a positive result, the 1028 Responder selects the corresponding HOST_ID for inclusion in the R1 1029 packet. Likewise, if the Responder HIT in the I1 packet is NULL 1030 (i.e., during an opportunistic handshake), the Responder chooses its 1031 HOST_ID according to the Initiator's employed DH group as indicated 1032 in the received DH_GROUP_LIST parameter and sets the source HIT in 1033 the R1 packet accordingly. If the Responder however does not support 1034 the DH group required by the Initiator or if the Responder HIT in the 1035 I1 packet does not match the required DH group, the Responder selects 1036 the mutually preferred and supported DH group based on the 1037 DH_GROUP_LIST parameter in the I1 packet. The Responder then 1038 includes the corresponding ECDH key in the HOST_ID parameter. This 1039 parameter also indicates the selected DH group. Moreover, the 1040 Responder sets the source HIT in the R2 packet based on the 1041 destination HIT from the I1 packet. Based on the deviating DH group 1042 ID in the HOST_ID parameter, the Initiator then SHOULD abort the 1043 current handshake and initiate a new handshake with the mutually 1044 supported DH group as far as local policies (see Section 7) permit. 1046 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 1047 Responder's supported and preferred transport format types. The list 1048 allows the Initiator and the Responder to agree on a common type for 1049 payload protection. Currently, the only transport format defined is 1050 IPsec ESP [RFC7402]. 1052 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 1053 wants to receive unmodified in the corresponding response packet in 1054 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 1055 or more ECHO_REQUEST_UNSIGNED parameters. 1057 5.3.3. I2 - the Second HIP Initiator Packet 1059 The HIP header values for the I2 packet: 1061 Header: 1062 Type = 3 1063 SRC HIT = Initiator's HIT 1064 DST HIT = Responder's HIT 1066 IP ( HIP ( [R1_COUNTER,] 1067 SOLUTION, 1068 HIP_CIPHER, 1069 ENCRYPTED_KEY, 1070 HOST_ID, 1071 TRANSPORT_FORMAT_LIST, 1072 HIP_MAC, 1073 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1075 Valid control bits: A 1077 The HITs MUST match the ones used in the R1 packet. 1079 If the Initiator's HI is an anonymous one, the A control bit MUST be 1080 set. 1082 If present in the R1 packet, the Initiator MUST include an unmodified 1083 copy of the R1_COUNTER parameter into the I2 packet. 1085 The Solution contains the Random #I from the R1 packet and the 1086 computed #J value. The low-order #K bits of the RHASH(I | ... | J) 1087 MUST be zero. 1089 The HIP_CIPHER contains the single encryption transform selected by 1090 the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY 1091 parameters. The chosen cipher MUST correspond to one of the ciphers 1092 offered by the Responder in the R1. All implementations MUST support 1093 the AES-CTR transform [RFC3686]. 1095 The HOST_ID parameter contains the Initiator HI corresponding to the 1096 Initiator HIT. 1098 The ENCRYPTED_KEY parameter contains an Initiator generated random 1099 value that MUST be uniformly distributed. This random value is 1100 encrypted with the Master Key SA using the HIP_CIPHER encryption 1101 algorithm. 1103 The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque 1104 data copied from the corresponding echo request parameter(s). This 1105 parameter can also be used for two-factor password authentication as 1106 shown in Appendix A. 1108 The TRANSPORT_FORMAT_LIST parameter contains the single transport 1109 format type selected by the Initiator. The chosen type MUST 1110 correspond to one of the types offered by the Responder in the R1 1111 packet. Currently, the only transport format defined is the ESP 1112 transport format [RFC7402]. 1114 The MAC is calculated over the whole HIP envelope, excluding any 1115 parameters after the HIP_MAC parameter as described in Section 6.2. 1116 The Responder MUST validate the HIP_MAC parameter. 1118 5.3.4. R2 - the Second HIP Responder Packet 1120 The HIP header values for the R2 packet: 1122 Header: 1123 Packet Type = 4 1124 SRC HIT = Responder's HIT 1125 DST HIT = Initiator's HIT 1127 IP ( HIP ( DH_GROUP_LIST, 1128 HIP_CIPHER, 1129 ENCRYPTED_KEY, 1130 HIT_SUITE_LIST, 1131 TRANSPORT_FORMAT_LIST, 1132 HIP_MAC) 1134 Valid control bits: none 1136 The HITs used MUST match the ones used in the I2 packet. 1138 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1139 and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These 1140 parameters MUST be the same as included in the R1 packet. The 1141 parameter are re-included here because the R2 packet is MACed and 1142 thus cannot be altered by an attacker. For verification purposes, 1143 the Initiator re-evaluates the selected suites and compares the 1144 results against the chosen ones. If the re-evaluated suites do not 1145 match the chosen ones, the Initiator acts based on its local policy. 1147 The ENCRYPTED_KEY parameter contains an Responder generated random 1148 value that MUST be uniformly distributed. This random value is 1149 encrypted with the Master Key SA using the HIP_CIPHER encryption 1150 algorithm. 1152 The MAC is calculated over the whole HIP envelope, excluding any 1153 parameters after the HIP_MAC, as described in Section 6.2. The 1154 Initiator MUST validate the HIP_MAC parameter. 1156 5.4. ICMP Messages 1158 When a HIP implementation detects a problem with an incoming packet, 1159 and it either cannot determine the identity of the sender of the 1160 packet or does not have any existing HIP association with the sender 1161 of the packet, it MAY respond with an ICMP packet. Any such reply 1162 MUST be rate-limited as described in [RFC4443]. In most cases, the 1163 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1164 ICMPv6), with the Pointer field pointing to the field that caused the 1165 ICMP message to be generated. The problem cases specified in 1166 Section 5.4. of [RFC7401] also apply to HIP DEX. 1168 6. Packet Processing 1170 Due to the adopted protocol semantics and the inherited general 1171 packet structure, the packet processing in HIP DEX only differs from 1172 HIPv2 in very few places. Here, we focus on these differences and 1173 refer to Section 6 in [RFC7401] otherwise. 1175 The processing of outgoing and incoming application data remains the 1176 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1178 6.1. Solving the Puzzle 1180 The procedures for solving and verifying a puzzle in HIP DEX are 1181 strongly based on the corresponding procedures in HIPv2. The only 1182 exceptions are that HIP DEX does not use pre-computation of R1 1183 packets and that RHASH is set to CMAC. As a result, the pre- 1184 computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. 1186 Moreover, the Initiator solves a puzzle by computing: 1187 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1189 Similarly, the Responder verifies a puzzle by computing: 1190 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1192 Apart from these modifications, the procedures defined in Section 6.3 1193 of [RFC7401] also apply for HIP DEX. 1195 6.2. HIP_MAC Calculation and Verification 1197 The following subsections define the actions for processing the 1198 HIP_MAC parameter. 1200 6.2.1. CMAC Calculation 1202 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1203 cryptographic function. The scope of the calculation for HIP_MAC is: 1205 CMAC: { HIP header | [ Parameters ] } 1207 where Parameters include all HIP parameters of the packet that is 1208 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1209 value - 1) and exclude parameters with Type values greater or equal 1210 to HIP_MAC's Type value. 1212 During HIP_MAC calculation, the following applies: 1214 o In the HIP header, the Checksum field is set to zero. 1216 o In the HIP header, the Header Length field value is calculated to 1217 the beginning of the HIP_MAC parameter. 1219 The parameter order is described in Section 5.2.1 of [RFC7401]. 1221 The CMAC calculation and verification process is as follows: 1223 Packet sender: 1225 1. Create the HIP packet, without the HIP_MAC or any other parameter 1226 with greater Type value than the HIP_MAC parameter has. 1228 2. Calculate the Header Length field in the HIP header. 1230 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1231 retrieved from KEYMAT as defined in Section 6.3. 1233 4. Add the HIP_MAC parameter to the packet and any parameter with 1234 greater Type value than the HIP_MAC's that may follow. 1236 5. Recalculate the Length field in the HIP header. 1238 Packet receiver: 1240 1. Verify the HIP header Length field. 1242 2. Remove the HIP_MAC parameter, as well as all other parameters 1243 that follow it with greater Type value, saving the contents if 1244 they will be needed later. 1246 3. Recalculate the HIP packet length in the HIP header and clear the 1247 Checksum field (set it to all zeros). 1249 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1250 defined in Section 6.3 and verify it against the received CMAC. 1252 5. Set Checksum and Header Length fields in the HIP header to 1253 original values. Note that the Checksum and Length fields 1254 contain incorrect values after this step. 1256 6.3. HIP DEX KEYMAT Generation 1258 The HIP DEX KEYMAT process is used to derive the keys for the Master 1259 Key SA as well as for the Pair-wise Key SA. The keys for the Master 1260 Key SA are based on the Diffie-Hellman derived key, Kij, which is 1261 produced during the HIP DEX handshake. The Initiator generates Kij 1262 during the creation of the I2 packet and the Responder generates Kij 1263 once it receives the I2 packet. This is why the I2 packet can 1264 already contain authenticated and/or encrypted information. 1266 The keys derived for the Pair-wise Key SA are not used during the HIP 1267 DEX handshake. Instead, these keys are made available as payload 1268 protection keys (e.g., for IPsec). Some payload protection 1269 mechanisms have their own Key Derivation Function, and if so this 1270 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 1271 be used to derive the keys of the Pair-wise Key SA based on the 1272 concatenation of the random values that are contained in the 1273 exchanged ENCRYPTED_KEY parameters. 1275 The HIP DEX KEYMAT process is based on the is the Hash-based Key 1276 Derivation Function (HKDF) defined in [RFC5869] and consists of two 1277 components, CKDF-Extract and CKDF-Expand. The CKDF-Extract function 1278 compresses a non-uniformly distributed key, such as the output of a 1279 Diffie-Hellman key derivation, to extract the key entropy into a 1280 fixed length output. The CKDF-Expand function takes either the 1281 output of the Extract function or directly uses a uniformly 1282 distributed key and expands the length of the key, repeatedly 1283 distributing the key entropy, to produce the keys needed. 1285 The key derivation for the Master Key SA employs always both the 1286 Extract and Expand phases. The Pair-wise Key SA needs only the 1287 Extract phase when key is smaller or equal to 128 bits, but otherwise 1288 requires also the Expand phase. 1290 The CKDF-Extract function is the following operation: 1292 CKDF-Extract(I, IKM, info) -> PRK 1294 Inputs: 1295 I Random #I from the PUZZLE parameter 1296 IKM Input keying material, i.e., the Diffie-Hellman derived 1297 key for the Master Key SA and the concatenation of the 1298 random values of the ENCRYPTED_KEY parameters in the 1299 same order as the HITs with sort(HIT-I | HIT-R) for the 1300 Pair-wise Key SA 1301 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1302 where "CKDF-Extract" is an octet string 1304 Output: 1305 PRK a pseudorandom key (of RHASH_len/8 octets) 1307 The pseudorandom key PRK is calculated as follows: 1309 PRK = CMAC(I, IKM | info) 1311 The CKDF-Expand function is the following operation: 1313 CKDF-Expand(PRK, info, L) -> OKM 1315 Inputs: 1316 PRK a pseudorandom key of at least RHASH_len/8 octets 1317 (either the output from the extract step or the 1318 concatenation of the random values of the 1319 ENCRYPTED_KEY parameters in the same order as the 1320 HITs with sort(HIT-I | HIT-R) in case of no extract) 1321 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1322 where "CKDF-Expand" is an octet string 1323 L length of output keying material in octets 1324 (<= 255*RHASH_len/8) 1326 Output: 1327 OKM output keying material (of L octets) 1329 The output keying material OKM is calculated as follows: 1331 N = ceil(L/RHASH_len/8) 1332 T = T(1) | T(2) | T(3) | ... | T(N) 1333 OKM = first L octets of T 1335 where 1337 T(0) = empty string (zero length) 1338 T(1) = CMAC(PRK, T(0) | info | 0x01) 1339 T(2) = CMAC(PRK, T(1) | info | 0x02) 1340 T(3) = CMAC(PRK, T(2) | info | 0x03) 1341 ... 1343 (where the constant concatenated to the end of each T(n) is a 1344 single octet.) 1346 sort(HIT-I | HIT-R) is defined as the network byte order 1347 concatenation of the two HITs, with the smaller HIT preceding the 1348 larger HIT, resulting from the numeric comparison of the two HITs 1349 interpreted as positive (unsigned) 128-bit integers in network byte 1350 order. 1352 The initial keys for the Master Key SA are drawn sequentially in the 1353 order that is determined by the numeric comparison of the two HITs, 1354 with the comparison method described in the previous paragraph. 1355 HOST_g denotes the host with the greater HIT value, and HOST_l the 1356 host with the lower HIT value. 1358 The drawing order for initial keys: 1360 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1361 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1363 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1365 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1367 The number of bits drawn for a given algorithm is the "natural" size 1368 of the keys regarding the algorithm defined in the HIP_CIPHER. For 1369 the mandatory algorithms, the following size applies: 1371 AES 128 bits 1373 If other key sizes are used, they must be treated as different 1374 encryption algorithms and defined separately. 1376 6.4. Initiation of a HIP Diet EXchange 1378 The initiation of a HIP DEX handshake proceeds as described in 1379 Section 6.6 of [RFC7401]. The I1 packet contents are specified in 1380 Section 5.3.1. 1382 6.5. Processing Incoming I1 Packets 1384 I1 packets in HIP DEX are handled almost identical to HIPv2 (see 1385 Section 6.7 of [RFC7401]). The main differences are that the 1386 Responder SHOULD select a HIP DEX HIT Suite in the R1 response. 1387 Moreover, as R1 packets are neither covered by a signature nor incur 1388 the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- 1389 computation of an R1 is only marginally beneficial, but would incur 1390 additional memory resources at the Responder. Hence, the R1 pre- 1391 computation SHOULD be omitted in HIP DEX. 1393 Correspondingly, the modified conceptual processing rules for 1394 responding to an I1 packet are as follows: 1396 1. The Responder MUST check that the Responder's HIT in the received 1397 I1 packet is either one of its own HITs or NULL. Otherwise, it 1398 must drop the packet. 1400 2. If the Responder is in ESTABLISHED state, the Responder MAY 1401 respond to this with an R1 packet, prepare to drop an existing 1402 HIP security association with the peer, and stay at ESTABLISHED 1403 state. 1405 3. If the Responder is in I1-SENT state, it MUST make a comparison 1406 between the sender's HIT and its own (i.e., the receiver's) HIT. 1407 If the sender's HIT is greater than its own HIT, it should drop 1408 the I1 packet and stay at I1-SENT. If the sender's HIT is 1409 smaller than its own HIT, it SHOULD send the R1 packet and stay 1410 at I1-SENT. The HIT comparison is performed as defined in 1411 Section 6.3. 1413 4. If the implementation chooses to respond to the I1 packet with an 1414 R1 packet, it creates a new R1 according to the format described 1415 in Section 5.3.2. It chooses the HI based on the destination HIT 1416 and the DH_GROUP_LIST in the I1 packet. If the implementation 1417 does not support the DH group required by the Initiator or if the 1418 destination HIT in the I1 packet does not match the required DH 1419 group, it selects the mutually preferred and supported DH group 1420 based on the DH_GROUP_LIST parameter in the I1 packet. The 1421 implementation includes the corresponding ECDH public key in the 1422 HOST_ID parameter. If no suitable DH Group ID was contained in 1423 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with 1424 any suitable ECDH public key. 1426 5. If the received Responder's HIT in the I1 packet is not NULL, the 1427 Responder's HIT in the R1 packet MUST match the destination HIT 1428 in the I1 packet. Otherwise, the Responder MUST select a HIT 1429 with the same HIT Suite as the Initiator's HIT. If this HIT 1430 Suite is not supported by the Responder, it SHOULD select a 1431 REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is 1432 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 1433 a local policy matter. 1435 6. The Responder expresses its supported HIP transport formats in 1436 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of 1437 [RFC7401]. The Responder MUST provide at least one payload 1438 transport format type. 1440 7. The Responder sends the R1 packet to the source IP address of the 1441 I1 packet. 1443 Note that only steps 4 and 5 have been changed with regard to the 1444 processing rules of HIPv2. The considerations about R1 management 1445 (except pre-computation) and malformed I1 packets in Sections 6.7.1 1446 and 6.7.2 of [RFC7401] likewise apply to HIP DEX. 1448 6.6. Processing Incoming R1 Packets 1450 R1 packets in HIP DEX are handled identically to HIPv2 (see 1451 Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses 1452 ECDH public keys as HIs and does not employ signatures. 1454 The modified conceptual processing rules for responding to an R1 1455 packet are as follows: 1457 1. A system receiving an R1 MUST first check to see if it has sent 1458 an I1 packet to the originator of the R1 packet (i.e., it has a 1459 HIP association that is in state I1-SENT and that is associated 1460 with the HITs in the R1). Unless the I1 packet was sent in 1461 opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP 1462 addresses in the received R1 packet SHOULD be ignored by the R1 1463 processing and, when looking up the correct HIP association, the 1464 received R1 packet SHOULD be matched against the associations 1465 using only the HITs. If a match exists, the system should 1466 process the R1 packet as described below. 1468 2. Otherwise, if the system is in any state other than I1-SENT or 1469 I2-SENT with respect to the HITs included in the R1 packet, it 1470 SHOULD silently drop the R1 packet and remain in the current 1471 state. 1473 3. If the HIP association state is I1-SENT or I2-SENT, the received 1474 Initiator's HIT MUST correspond to the HIT used in the original 1475 I1 packet. Also, the Responder's HIT MUST correspond to the one 1476 used in the I1 packet, unless this packet contained a NULL HIT. 1478 4. If the HIP association state is I1-SENT, and multiple valid R1 1479 packets are present, the system MUST select from among the R1 1480 packets with the largest R1 generation counter. 1482 5. The system MUST check that the Initiator's HIT Suite is 1483 contained in the HIT_SUITE_LIST parameter in the R1 packet 1484 (i.e., the Initiator's HIT Suite is supported by the Responder). 1485 If the HIT Suite is supported by the Responder, the system 1486 proceeds normally. Otherwise, the system MAY stay in state 1487 I1-SENT and restart the HIP DEX handshake by sending a new I1 1488 packet with an Initiator HIT that is supported by the Responder 1489 and hence is contained in the HIT_SUITE_LIST in the R1 packet. 1490 The system MAY abort the handshake if no suitable source HIT is 1491 available. The system SHOULD wait for an acceptable time span 1492 to allow further R1 packets with higher R1 generation counters 1493 or different HIT and HIT Suites to arrive before restarting or 1494 aborting the HIP DEX handshake. 1496 6. The system MUST check that the DH Group ID in the HOST_ID 1497 parameter in the R1 matches the first DH Group ID in the 1498 Responder's DH_GROUP_LIST in the R1 packet, and also that this 1499 Group ID corresponds to a value that was included in the 1500 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 1501 of the HOST_ID parameter does not express the Responder's best 1502 choice, the Initiator can conclude that the DH_GROUP_LIST in the 1503 I1 or R1 packet was adversely modified. In such a case, the 1504 Initiator MAY send a new I1 packet; however, it SHOULD NOT 1505 change its preference in the DH_GROUP_LIST in the new I1 packet. 1506 Alternatively, the Initiator MAY abort the HIP DEX handshake. 1507 Moreover, if the DH Group ID indicated in the HOST_ID parameter 1508 does not match the DH Group ID of the HI employed by the 1509 Initiator, the system SHOULD wait for an acceptable time span to 1510 allow further R1 packets with different DH Group IDs to arrive 1511 before restarting or aborting the HIP DEX handshake. When 1512 restarting the handshake, the Initiator MUST consult local 1513 policies (see Section 7) regarding the use of another, mutually 1514 supported DH group for the subsequent handshake with the 1515 Responder. 1517 7. If the HIP association state is I2-SENT, the system MAY re-enter 1518 state I1-SENT and process the received R1 packet if it has a 1519 larger R1 generation counter than the R1 packet responded to 1520 previously. 1522 8. The R1 packet may have the A-bit set - in this case, the system 1523 MAY choose to refuse it by dropping the R1 packet and returning 1524 to state UNASSOCIATED. The system SHOULD consider dropping the 1525 R1 packet only if it used a NULL HIT in the I1 packet. If the 1526 A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be 1527 stored permanently. 1529 9. The system SHOULD attempt to validate the HIT against the 1530 received Host Identity by using the received Host Identity to 1531 construct a HIT and verify that it matches the Sender's HIT. 1533 10. The system MUST store the received R1 generation counter for 1534 future reference. 1536 11. The system attempts to solve the puzzle in the R1 packet. The 1537 system MUST terminate the search after exceeding the remaining 1538 lifetime of the puzzle. If the puzzle is not successfully 1539 solved, the implementation MAY either resend the I1 packet 1540 within the retry bounds or abandon the HIP base exchange. 1542 12. The system computes standard Diffie-Hellman keying material 1543 according to the public value and Group ID provided in the 1544 HOST_ID parameter. The Diffie-Hellman keying material Kij is 1545 used for key extraction as specified in Section 6.3. 1547 13. The system selects the HIP_CIPHER ID from the choices presented 1548 in the R1 packet and uses the selected values subsequently when 1549 generating and using encryption keys, and when sending the I2 1550 packet. If the proposed alternatives are not acceptable to the 1551 system, it may either resend an I1 packet within the retry 1552 bounds or abandon the HIP base exchange. 1554 14. The system chooses one suitable transport format from the 1555 TRANSPORT_FORMAT_LIST and includes the respective transport 1556 format parameter in the subsequent I2 packet. 1558 15. The system initializes the remaining variables in the associated 1559 state, including Update ID counters. 1561 16. The system prepares and sends an I2 packet as described in 1562 Section 5.3.3. 1564 17. The system SHOULD start a timer whose timeout value SHOULD be 1565 larger than the worst-case anticipated RTT, and MUST increment a 1566 trial counter associated with the I2 packet. The sender SHOULD 1567 retransmit the I2 packet upon a timeout and restart the timer, 1568 up to a maximum of I2_RETRIES_MAX tries. 1570 18. If the system is in state I1-SENT, it SHALL transition to state 1571 I2-SENT. If the system is in any other state, it remains in the 1572 current state. 1574 Note that step 4 from the original processing rules of HIPv2 1575 (signature verification) has been removed in the above processing 1576 rules for HIP DEX. Moreover, step 7 of the original processing rules 1577 has been adapted in step 6 above to account for the fact that HIP DEX 1578 uses ECDH public keys as HIs. The considerations about malformed R1 1579 packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX. 1581 6.7. Processing Incoming I2 Packets 1583 The processing of I2 packets follows similar rules as HIPv2 (see 1584 Section 6.9 of [RFC7401]). The main differences to HIPv2 are that 1585 HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY 1586 parameter as well as an I2 reception acknowledgement for 1587 retransmission purposes. Moreover, with HIP DEX the Initiator is 1588 responsible for triggering retransmissions, whereas the Responder 1589 merely replies to received I2 packets. 1591 The modified HIP DEX conceptual processing rules for responding to an 1592 I2 packet are: 1594 1. The system MAY perform checks to verify that the I2 packet 1595 corresponds to a recently sent R1 packet. Such checks are 1596 implementation dependent. See Appendix A in [RFC7401] for a 1597 description of an example implementation. 1599 2. The system MUST check that the Responder's HIT corresponds to 1600 one of its own HITs and MUST drop the packet otherwise. 1602 3. The system MUST further check that the Initiator's HIT Suite is 1603 supported. The Responder SHOULD silently drop I2 packets with 1604 unsupported Initiator HITs. 1606 4. If the system's state machine is in the R2-SENT state, the 1607 system MUST check to see if the newly received I2 packet is 1608 similar to the one that triggered moving to R2-SENT. If so, it 1609 MUST retransmit a previously sent R2 packet and reset the 1610 R2-SENT timer. The system SHOULD re-use the previously 1611 established state to re-create the corresponding R2 packet in 1612 order to prevent unnecessary computation overhead. 1614 5. If the system's state machine is in the I2-SENT state, the 1615 system MUST make a comparison between its local and sender's 1616 HITs (similarly as in Section 6.3). If the local HIT is smaller 1617 than the sender's HIT, it should drop the I2 packet, use the 1618 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1619 #I from the R1 packet received earlier, and get the local 1620 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1621 from the I2 packet sent to the peer earlier. Otherwise, the 1622 system should process the received I2 packet and drop any 1623 previously derived Diffie-Hellman keying material Kij and 1624 ENCRYPTED_KEY keying material it might have generated upon 1625 sending the I2 packet previously. The peer Diffie-Hellman key, 1626 ENCRYPTED_KEY, and the nonce #J are taken from the just arrived 1627 I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying 1628 material, and the nonce #I are the ones that were sent earlier 1629 in the R1 packet. 1631 6. If the system's state machine is in the I1-SENT state, and the 1632 HITs in the I2 packet match those used in the previously sent I1 1633 packet, the system uses this received I2 packet as the basis for 1634 the HIP association it was trying to form, and stops 1635 retransmitting I1 packets (provided that the I2 packet passes 1636 the additional checks below). 1638 7. If the system's state machine is in any state other than 1639 R2-SENT, the system SHOULD check that the echoed R1 generation 1640 counter in the I2 packet is within the acceptable range if the 1641 counter is included. Implementations MUST accept puzzles from 1642 the current generation and MAY accept puzzles from earlier 1643 generations. If the generation counter in the newly received I2 1644 packet is outside the accepted range, the I2 packet is stale 1645 (and perhaps replayed) and SHOULD be dropped. 1647 8. The system MUST validate the solution to the puzzle as described 1648 in Section 6.1. 1650 9. The I2 packet MUST have a single value in the HIP_CIPHER 1651 parameter, which MUST match one of the values offered to the 1652 Initiator in the R1 packet. 1654 10. The system MUST derive Diffie-Hellman keying material Kij based 1655 on the public value and Group ID in the HOST_ID parameter. This 1656 keying material is used to derive the keys of the Master Key SA 1657 as described in Section 6.3. If the Diffie-Hellman Group ID is 1658 unsupported, the I2 packet is silently dropped. If the 1659 processing time for the derivation of the Diffie-Hellman keying 1660 material Kij is likely to cause premature I2 retransmissions by 1661 the Initiator, the system MAY send a NOTIFY packet before 1662 starting the key derivation process. The NOTIFY packet contains 1663 a NOTIFICATION parameter with Notify Message Type 1664 I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the 1665 anticipated remaining processing time for the I2 packet in 1666 milliseconds as two-octet Notification Data. 1668 11. The implementation SHOULD also verify that the Initiator's HIT 1669 in the I2 packet corresponds to the Host Identity sent in the I2 1670 packet. (Note: some middleboxes may not be able to make this 1671 verification.) 1673 12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1674 Other documents specifying transport formats (e.g., [RFC7402]) 1675 contain specifications for handling any specific transport 1676 selected. 1678 13. The system MUST verify the HIP_MAC according to the procedures 1679 in Section 6.2. 1681 14. If the checks above are valid, then the system proceeds with 1682 further I2 processing; otherwise, it discards the I2 and its 1683 state machine remains in the same state. 1685 15. The I2 packet may have the A-bit set - in this case, the system 1686 MAY choose to refuse it by dropping the I2 and the state machine 1687 returns to state UNASSOCIATED. If the A-bit is set, the 1688 Initiator's HIT is anonymous and should not be stored 1689 permanently. 1691 16. The system MUST decrypt the keying material from the 1692 ENCRYPTED_KEY parameter. This keying material is a partial 1693 input to the key derivation process for the Pair-wise Key SA 1694 (see Section 6.3). 1696 17. The system initializes the remaining variables in the associated 1697 state, including Update ID counters. 1699 18. Upon successful processing of an I2 packet when the system's 1700 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 1701 R2-SENT, an R2 packet is sent as described in Section 5.3.4 and 1702 the system's state machine transitions to state R2-SENT. 1704 19. Upon successful processing of an I2 packet when the system's 1705 state machine is in state ESTABLISHED, the old HIP association 1706 is dropped and a new one is installed, an R2 packet is sent as 1707 described in Section 5.3.4, and the system's state machine 1708 transitions to R2-SENT. 1710 20. Upon the system's state machine transitioning to R2-SENT, the 1711 system starts a timer. The state machine transitions to 1712 ESTABLISHED if some data has been received on the incoming HIP 1713 association, or an UPDATE packet has been received (or some 1714 other packet that indicates that the peer system's state machine 1715 has moved to ESTABLISHED). If the timer expires (allowing for a 1716 maximal amount of retransmissions of I2 packets), the state 1717 machine transitions to ESTABLISHED. 1719 Note that steps 11 (encrypted HOST_ID) and 15 (signature 1720 verification) from the original processing rules of HIPv2 have been 1721 removed in the above processing rules for HIP DEX. Moreover, step 10 1722 of the HIPv2 processing rules has been adapted to account for 1723 optional extension of the retransmission mechanism. Step 16 has been 1724 added to the processing rules in this document. The considerations 1725 about malformed I2 packets in Sections 6.9.1 of [RFC7401] also apply 1726 to HIP DEX. 1728 6.8. Processing Incoming R2 Packets 1730 R2 packets in HIP DEX are handled identically to HIPv2 (see 1731 Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX 1732 introduces a new session key exchange via the ENCRYPTED_KEY parameter 1733 and does not employ signatures. 1735 The modified conceptual processing rules for responding to an R2 1736 packet are as follows: 1738 1. If the system is in any other state than I2-SENT, the R2 packet 1739 is silently dropped. 1741 2. The system MUST verify that the HITs in use correspond to the 1742 HITs that were received in the R1 packet that caused the 1743 transition to the I2-SENT state. 1745 3. The system MUST verify the HIP_MAC according to the procedures in 1746 Section 6.2. 1748 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1749 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1750 packet and compare the results against the chosen suites. 1752 5. If any of the checks above fail, there is a high probability of 1753 an ongoing man-in-the-middle or other security attack. The 1754 system SHOULD act accordingly, based on its local policy. 1756 6. The system MUST decrypt the keying material from the 1757 ENCRYPTED_KEY parameter. This keying material is a partial input 1758 to the key derivation process for the Pair-wise Key SA (see 1759 Section 6.3). 1761 7. Upon successful processing of the R2 packet, the state machine 1762 transitions to state ESTABLISHED. 1764 Note that step 4 (signature verification) from the original 1765 processing rules of HIPv2 has been replaced with a negotiation re- 1766 evaluation in the above processing rules for HIP DEX. Moreover, step 1767 6 has been added to the processing rules. 1769 6.9. Processing Incoming NOTIFY Packets 1771 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 1772 in a received NOTIFICATION parameter SHOULD be logged. Received 1773 errors MUST be considered only as informational, and the receiver 1774 SHOULD NOT change its HIP state purely based on the received NOTIFY 1775 packet. 1777 If a NOTIFY packet is received in state I2-SENT, this packet may be 1778 an I2 reception acknowledgement of the optional retransmission 1779 mechanism extension and SHOULD be processed. The following steps 1780 define the conceptual processing rules for such incoming NOTIFY 1781 packets in state I2-SENT: 1783 1. The system MUST verify that the HITs in use correspond to the 1784 HITs that were received in the R1 packet that caused the 1785 transition to the I2-SENT state. If this check fails, the NOTIFY 1786 packet SHOULD be dropped silently. 1788 2. If the NOTIFY packet contains a NOTIFICATION parameter with 1789 Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the 1790 I2 retransmission timer to the I2 processing time indicated in 1791 the NOTIFICATION parameter plus half the RTT-based timeout value. 1792 The system MUST NOT set the retransmission timeout to a higher 1793 value than allowed by a local policy. Moreover, the system 1794 SHOULD reset the I2 retransmission timer to the RTT-based timeout 1795 value after the next I2 retransmission. 1797 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 1799 UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 1800 as in HIPv2 (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). 1801 The only difference is the that the HIP_SIGNATURE is never present 1802 and, therefore, is not required to be processed by the receiving 1803 party. 1805 [RFC7402] specifies the rekeying of an existing HIP SA using the 1806 UPDATE message. This rekeying procedure can also be used with HIP 1807 DEX. However, where rekeying involves a new Diffie-Hellman key 1808 exchange, HIP DEX peers MUST establish a new HIP association in order 1809 to create a new Pair-wise Key SA due to the use of static ECDH key- 1810 pairs with HIP DEX. 1812 6.11. Handling State Loss 1814 Implementors MAY choose to use non-volatile, secure storage for HIP 1815 states in order for them to survive a system reboot. If no secure 1816 storage capabilities are available, the system SHOULD delete the 1817 corresponding HIP state, including the keying material. If the 1818 implementation does drop the state (as RECOMMENDED), it MUST also 1819 drop the peer's R1 generation counter value, unless a local policy 1820 explicitly defines that the value of that particular host is stored. 1821 Such storing of the R1 generation counter values MUST be configured 1822 by explicit HITs. 1824 7. HIP Policies 1826 There are a number of variables that will influence the HIP exchanges 1827 that each host must support. The value of #K used in the HIP R1 must 1828 be chosen with care. Values of #K that are too high will exclude 1829 clients with weak CPUs because these devices cannot solve the puzzle 1830 within a reasonable amount of time. #K should only be raised if a 1831 Responder is under high load, i.e., it cannot process all incoming 1832 HIP handshakes any more. If a Responder is not under high load, #K 1833 SHOULD be 0. 1835 All HIP DEX implementations SHOULD provide for an Access Control List 1836 (ACL), representing for which hosts they accept HIP diet exchanges, 1837 and the preferred transport format and local lifetimes. Wildcarding 1838 SHOULD be supported for such ACLs. 1840 8. Interoperability between HIP DEX and HIPv2 1842 HIP DEX and HIPv2 both use the same protocol number and packet 1843 formats. Hence, an implementation that either supports HIP DEX or 1844 HIPv2 must be able to detect the dialect that the peer is speaking. 1846 This section outlines how a HIP DEX implementation can achieve such 1847 detection for the two relevant cases where: 1849 1. the Initiator supports HIP DEX and the Responder supports HIP 1850 BEX, 1852 2. the Initiator supports HIP BEX and the Responder supports HIP 1853 DEX. 1855 In the first case, the HIP DEX implementation (Initiator) inspects 1856 the Responder's HIT prior to sending the I1 packet. If the OGA ID 1857 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 1858 DEX implementation cancels the handshake. If the Responder is 1859 unknown prior to sending the I1 packet (i.e., opportunistic mode), 1860 the HIP DEX implementation performs the above check on reception of 1861 the R1 packet and cancels the handshake in case of a negative result. 1862 In both failure scenarios, the implementation should report an error 1863 to the user via appropriate means. 1865 In the second case, the HIP DEX implementation (Responder) inspects 1866 the Initiator's HIT on reception of an I1 packet. If the OGA ID 1867 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 1868 DEX implementation cancels the handshake and sends an ICMP packet 1869 with type Parameter Problem, with the Pointer pointing to the source 1870 HIT, to the Initiator. As an adversary could also send such an ICMP 1871 packet in a man-in-the-middle attack with the aim to prevent the HIP 1872 DEX handshake from completing, the Initiator SHOULD NOT react to an 1873 ICMP message after sending the I1 until a reasonable delta time to 1874 get the real Responder's R1 HIP packet. 1876 Note that an implementation may also support both HIP DEX and HIPv2. 1877 It then uses the above procedure to determine the protocol variant 1878 that is supported by its handshake peer and performs the 1879 corresponding handshake. 1881 9. Security Considerations 1883 HIP DEX closely resembles HIPv2. As such, the security 1884 considerations discussed in Section 8 of [RFC7401] similarly apply to 1885 HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated 1886 Diffie-Hellman key exchange of HIPv2 with an exchange of random 1887 keying material that is encrypted with a Diffie-Hellman derived key. 1888 Both the Initiator and Responder contribute to this keying material. 1889 As a result, the following additional security considerations apply 1890 to HIP DEX: 1892 o The strength of the keys for the Pair-wise Key SA is based on the 1893 quality of the random keying material generated by the Initiator 1894 and the Responder. As either peer may be a sensor or an actuator 1895 device, there is a natural concern about the quality of its random 1896 number generator. 1898 o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. 1899 Consequently, if an HI is compromised, all HIP connections 1900 protected with that HI are compromised. 1902 o The puzzle mechanism using CMAC may need further study regarding 1903 the level of difficulty. 1905 o The HIP DEX HIT generation may present new attack opportunities. 1906 Hence, HIP DEX HITs should not be use as the only means to 1907 identify a peer in an ACL. Instead, the use of the peer's HI is 1908 recommended. 1910 o The R1 packet is unauthenticated and offers an adversary a new 1911 attack vector against the Initiator. This is mitigated by only 1912 processing a received R1 packet when the Initiator has previously 1913 sent a corresponding I1 packet. Moreover, the Responder repeats 1914 the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and 1915 TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to 1916 enable the Initiator to verify that these parameters have not been 1917 modified by an attacker in the unprotected R1 packet. 1919 The optional retransmission extension of HIP DEX is based on a NOTIFY 1920 packet that the Responder can use to inform the Initiator about the 1921 reception of an I2 packet. The Responder, however, cannot protect 1922 the authenticity of this packet as it did not yet set up the Master 1923 Key SA. Hence, an eavesdropping adversary may send spoofed reception 1924 acknowledgements for an overheard I2 packet and signal an arbitrary 1925 I2 processing time to the Initiator. The adversary can, e.g., 1926 indicate a lower I2 processing time than actually required by the 1927 Responder in order to cause premature retransmissions. To protect 1928 against this attack, the Initiator SHOULD set the NOTIFY-based 1929 timeout value to the maximum indicated packet processing time in case 1930 of conflicting NOTIFY packets. This allows the legitimate Responder 1931 to extend the retransmission timeout to the intended length. The 1932 adversary, however, can still arbitrarily delay the protocol 1933 handshake beyond the Responder's actual I2 processing time. To limit 1934 the extend of such a maliciously induced handshake delay, this 1935 specification additionally requires the Initiator not to set the 1936 NOTIFY-based timeout value higher than allowed by a local policy. 1938 10. IANA Considerations 1940 The following changes to the "Host Identity Protocol (HIP) 1941 Parameters" registries have been made: 1943 HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" 1944 (see Section 5.2.4). 1946 Parameter Type This document defines the new HIP parameter 1947 "ENCRYPTED_KEY" with type number 643 (see Section 5.2.5). 1949 HIP Cipher ID This document defines the new HIP Cipher ID "AES- 1950 128-CTR" (see Section 5.2.2). 1952 HI Algorithm This document defines the new HI Algorithm "ECDH" (see 1953 Section 5.2.3). 1955 ECC Curve Label This document specifies a new algorithm-specific 1956 subregistry named "ECDH Curve Label". The values for this 1957 subregistry are defined in Section 5.2.1. 1959 11. Acknowledgments 1961 The drive to put HIP on a cryptographic 'Diet' came out of a number 1962 of discussions with sensor vendors at IEEE 802.15 meetings. David 1963 McGrew was very helpful in crafting this document. Special thanks to 1964 Miika Komu for reviewing this document in the context of Convince 1965 Celtic+ project. 1967 12. Changelog 1969 This section summarizes the changes made from draft-moskowitz-hip-rg- 1970 dex-05, which was the first stable version of the draft. Note that 1971 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 1973 The draft was then renamed from draft-moskowitz-hip-dex to draft- 1974 ietf-hip-dex. 1976 12.1. Changes in draft-ietf-hip-dex-05 1978 o Clarified main differences between HIP BEX and HIP DEX in 1979 Section 1. 1981 o Addressed MitM attack in Section 8. 1983 o Minor editorial changes. 1985 12.2. Changes in draft-ietf-hip-dex-04 1987 o Added new paragraph on rekeying procedure with HIP DEX. 1989 o Updated references. 1991 o Editorial changes. 1993 12.3. Changes in draft-ietf-hip-dex-03 1995 o Added new section on HIP DEX/HIPv2 interoperability 1997 o Added reference to RFC4493 for CMAC. 1999 o Added reference to RFC5869 for CKDF. 2001 o Added processing of NOTIFY message in I2-SENT of state diagram. 2003 o Editorial changes. 2005 12.4. Changes in draft-ietf-hip-dex-02 2007 o Author address change. 2009 12.5. Changes in draft-ietf-hip-dex-01 2011 o Added the new ECDH groups of Curve25519 and Curve448 from RFC 2012 7748. 2014 12.6. Changes in draft-ietf-hip-dex-00 2016 o The Internet Draft was adopted by the HIP WG. 2018 12.7. Changes in draft-moskowitz-hip-rg-dex-06 2020 o A major change in the ENCRYPT parameter to use AES-CTR rather than 2021 AES-CBC. 2023 12.8. Changes in draft-moskowitz-hip-dex-00 2025 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 2026 submission. 2028 o Added the change section. 2030 o Added a Definitions section. 2032 o Changed I2 and R2 packets to reflect use of AES-CTR for 2033 ENCRYPTED_KEY parameter. 2035 o Cleaned up KEYMAT Generation text. 2037 o Added Appendix with C code for the ECDH shared secret generation 2038 on an 8 bit processor. 2040 12.9. Changes in draft-moskowitz-hip-dex-01 2042 o Numerous editorial changes. 2044 o New retransmission strategy. 2046 o New HIT generation mechanism. 2048 o Modified layout of ENCRYPTED_KEY parameter. 2050 o Clarify to use puzzle difficulty of zero under normal network 2051 conditions. 2053 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 2054 MUST). 2056 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 2057 and I2). 2059 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 2060 echoed in R2 packet. 2062 o Added new author. 2064 12.10. Changes in draft-moskowitz-hip-dex-02 2066 o Introduced formal definition of FOLD function. 2068 o Clarified use of CMAC for puzzle computation in section "Solving 2069 the Puzzle". 2071 o Several editorial changes. 2073 12.11. Changes in draft-moskowitz-hip-dex-03 2075 o Addressed HI crypto agility. 2077 o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 2079 o Extended the IV in the ENCRYPTED_KEY parameter. 2081 o Introduced forward-references to HIP DEX KEYMAT process and 2082 improved KEYMAT section. 2084 o Replaced Appendix A on "C code for ECC point multiplication" with 2085 short discussion in introduction. 2087 o Updated references. 2089 o Further editorial changes. 2091 12.12. Changes in draft-moskowitz-hip-dex-04 2093 o Improved retransmission extension. 2095 o Updated and strongly revised packet processing rules. 2097 o Updated security considerations. 2099 o Updated IANA considerations. 2101 o Move the HI Algorithm for ECDH to a value of 11. 2103 o Many editorial changes. 2105 13. References 2107 13.1. Normative References 2109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2110 Requirement Levels", BCP 14, RFC 2119, 2111 DOI 10.17487/RFC2119, March 1997, 2112 . 2114 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2115 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 2116 November 1998, . 2118 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2119 Counter Mode With IPsec Encapsulating Security Payload 2120 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2121 . 2123 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2124 Control Message Protocol (ICMPv6) for the Internet 2125 Protocol Version 6 (IPv6) Specification", RFC 4443, 2126 DOI 10.17487/RFC4443, March 2006, 2127 . 2129 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 2130 Routable Cryptographic Hash Identifiers Version 2 2131 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2132 2014, . 2134 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2135 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2136 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2137 . 2139 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2140 Encapsulating Security Payload (ESP) Transport Format with 2141 the Host Identity Protocol (HIP)", RFC 7402, 2142 DOI 10.17487/RFC7402, April 2015, 2143 . 2145 13.2. Informative References 2147 [DH76] Diffie, W. and M. Hellman, "New Directions in 2148 Cryptography", IEEE Transactions on Information 2149 Theory vol. IT-22, number 6, pages 644-654, Nov 1976. 2151 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 2152 Wehrle, "Tailoring End-to-End IP Security Protocols to the 2153 Internet of Things", in Proceedings of IEEE International 2154 Conference on Network Protocols (ICNP 2013), October 2013. 2156 [I-D.ietf-hip-rfc4423-bis] 2157 Moskowitz, R. and M. Komu, "Host Identity Protocol 2158 Architecture", draft-ietf-hip-rfc4423-bis-15 (work in 2159 progress), November 2016. 2161 [IEEE.802-11.2007] 2162 "Information technology - Telecommunications and 2163 information exchange between systems - Local and 2164 metropolitan area networks - Specific requirements - Part 2165 11: Wireless LAN Medium Access Control (MAC) and Physical 2166 Layer (PHY) Specifications", IEEE Standard 802.11, June 2167 2007, . 2170 [IEEE.802-15-4.2011] 2171 "Information technology - Telecommunications and 2172 information exchange between systems - Local and 2173 metropolitan area networks - Specific requirements - Part 2174 15.4: Wireless Medium Access Control (MAC) and Physical 2175 Layer (PHY) Specifications for Low-Rate Wireless Personal 2176 Area Networks (WPANs)", IEEE Standard 802.15.4, September 2177 2011, . 2180 [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for 2181 Elliptic Curve Cryptography in Wireless Sensor Networks", 2182 in Proceedings of International Conference on Information 2183 Processing in Sensor Networks (IPSN 2008), April 2008. 2185 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 2186 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2187 2006, . 2189 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2190 Key Derivation Function (HKDF)", RFC 5869, 2191 DOI 10.17487/RFC5869, May 2010, 2192 . 2194 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2195 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2196 DOI 10.17487/RFC5903, June 2010, 2197 . 2199 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2200 Curve Cryptography Algorithms", RFC 6090, 2201 DOI 10.17487/RFC6090, February 2011, 2202 . 2204 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2205 Constrained-Node Networks", RFC 7228, 2206 DOI 10.17487/RFC7228, May 2014, 2207 . 2209 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2210 Kivinen, "Internet Key Exchange Protocol Version 2 2211 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2212 2014, . 2214 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2215 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2216 2016, . 2218 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2219 2 , 2000, . 2221 Appendix A. Password-based two-factor authentication during the HIP DEX 2222 handshake 2224 HIP DEX allows to identify authorized connections based on a two- 2225 factor authentication mechanism. With two-factor authentication, 2226 devices that are authorized to communicate with each other are 2227 required to be pre-provisioned with a shared (group) key. The 2228 Initiator uses this pre-provisioned key to encrypt the 2229 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 2230 the Responder verifies that its challenge in the 2231 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 2232 with the correct key. If verified successfully, the Responder 2233 proceeds with the handshake. Otherwise, it silently drops the I2 2234 packet. 2236 Note that there is no explicit signaling in the HIP DEX handshake for 2237 this behavior. Thus, knowledge of two-factor authentication must be 2238 configured externally prior to the handshake. 2240 Authors' Addresses 2242 Robert Moskowitz (editor) 2243 HTT Consulting 2244 Oak Park, MI 2245 USA 2247 EMail: rgm@htt-consult.com 2249 Rene Hummen 2250 Hirschmann Automation and Control 2251 Stuttgarter Strasse 45-51 2252 Neckartenzlingen 72654 2253 Germany 2255 EMail: rene.hummen@belden.com