idnits 2.17.1 draft-moskowitz-hip-dex-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 117 has weird spacing: '...ication dur...' -- The document date (June 19, 2015) is 3233 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-11 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz, Ed. 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track R. Hummen 5 Expires: December 21, 2015 COMSYS, RWTH Aachen 6 June 19, 2015 8 HIP Diet EXchange (DEX) 9 draft-moskowitz-hip-dex-03 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 December 21, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4 64 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 67 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 70 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 71 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 8 72 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9 74 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 10 75 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 11 76 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 14 77 4.1.4. User Data Considerations . . . . . . . . . . . . . . 15 78 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 15 80 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 15 81 5.2.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 16 82 5.2.2. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 16 83 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 17 84 5.2.4. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 17 85 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 17 86 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 18 87 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 19 88 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 20 89 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 22 90 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 23 91 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 24 92 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 24 93 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 24 94 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 25 95 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 25 96 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 26 97 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 29 98 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 29 99 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 29 100 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 29 101 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 32 102 6.9. Processing UPDATE, NOTIFY, CLOSE, and CLOSE_ACK Packets . 33 103 6.10. Handling State Loss . . . . . . . . . . . . . . . . . . . 33 104 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 33 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 108 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 35 109 11.1. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 35 110 11.2. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 35 111 11.3. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 35 112 11.4. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 36 113 11.5. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 36 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 116 12.2. Informative References . . . . . . . . . . . . . . . . . 37 117 Appendix A. Password-based two-factor authentication during 118 the HIP DEX handshake . . . . . . . . . . . . . . . 39 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 121 1. Introduction 123 This document specifies the Host Identity Protocol Diet EXchange (HIP 124 DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity 125 Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol 126 semantics as well as the general packet structure of HIPv2. Hence, 127 it is recommended that [RFC7401] is well-understood before reading 128 this document. 130 The main differences between HIP BEX and HIP DEX are: 132 1. Minimum collection of cryptographic primitives to reduce the 133 protocol overhead. 135 * Static Elliptic Curve Diffie-Hellman key pairs for peer 136 authentication and encryption of the session key. 138 * AES-CTR for symmetric encryption and AES-CMAC for MACing 139 function. 141 * A simple fold function for HIT generation. 143 2. Forfeit of Perfect Forward Secrecy with the dropping of ephemeral 144 Diffie-Hellman. 146 3. Forfeit of digital signatures with the removal of a hash 147 function. Reliance on ECDH derived key used in HIP_MAC to prove 148 ownership of the private key. 150 4. Diffie-Hellman derived key ONLY used to protect the HIP packets. 151 A separate secret exchange within the HIP packets creates the 152 session key(s). 154 5. Optional retransmission strategy tailored to handle the 155 potentially extensive processing time of the employed 156 cryptographic operations on computationally constrained devices. 158 By eliminating the need for public-key signatures and the ephemeral 159 DH key agreement, HIP DEX reduces the computation, energy, 160 transmission, and memory requirements for public-key cryptography 161 (see [LN08]) in the HIPv2 protocol design. Moreover, by dropping the 162 cryptographic hash function, HIP DEX affords a more efficient 163 protocol implementation than HIP BEX with respect to the 164 corresponding computation and memory requirements. This makes HIP 165 DEX especially suitable for constrained devices as defined in 166 [RFC7228]. 168 In this document, we focus on the protocol specifications related to 169 these differences. Where differences are not called out explicitly, 170 HIP DEX is the same as specified in [RFC7401]. 172 1.1. The HIP Diet EXchange (DEX) 174 The HIP Diet EXchange is a two-party cryptographic protocol used to 175 establish a secure communication context between hosts. The first 176 party is called the Initiator and the second party the Responder. 177 The four-packet exchange helps to make HIP DoS resilient. The 178 Initiator and the Responder exchange their static Elliptic Curve 179 Diffie-Hellman (ECDH) keys in the 2nd and 3rd handshake packet. The 180 parties then authenticate each other in the 3rd and 4th handshake 181 packet based on the ECDH-derived keying material. The Initiator and 182 the Responder additionally transmit keying material for the session 183 key in these last two handshake packets. This is to prevent overuse 184 of the static ECDH-derived keying material. Moreover, the Responder 185 starts a puzzle exchange in the 2nd packet, with the Initiator 186 completing it in the 3rd packet before the Responder performs 187 computationally expensive operations or stores any state from the 188 exchange. Hence, HIP DEX operationally is very similar to HIP BEX. 190 The model is also fairly equivalent to 802.11-2007 [IEEE.802-11.2007] 191 Master Key and Pair-wise Transient Key, but handled in a single 192 exchange. 194 HIP DEX does not have the option to encrypt the Host Identity of the 195 Initiator in the 3rd packet. The Responder's Host Identity also is 196 not protected. Thus, contrary to HIPv2, there is no attempt at 197 anonymity. 199 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 200 packets may carry a data payload in the future. However, the details 201 of this may be defined later. 203 An existing HIP association can be updated with the update mechanism 204 defined in [RFC7401]. Likewise, the association can be torn down 205 with the defined closing mechanism for HIPv2 if it is no longer 206 needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the 207 original HIPv2 specification. 209 Finally, HIP DEX is designed as an end-to-end authentication and key 210 establishment protocol. As such, it can be used in combination with 211 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 212 end-to-end security protocols. In addition, HIP DEX can also be used 213 as a keying mechanism for security primitives at the MAC layer, e.g., 214 for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth 215 mentioning that the HIP DEX base protocol does not cover all the 216 fine-grained policy control found in Internet Key Exchange Version 2 217 (IKEv2) [RFC5996] that allows IKEv2 to support complex gateway 218 policies. Thus, HIP DEX is not a replacement for IKEv2. 220 1.2. Memo Structure 222 The rest of this memo is structured as follows. Section 2 defines 223 the central keywords, notation, and terms used throughout the rest of 224 the document. Section 3 defines the structure of the Host Identity 225 and its various representations. Section 4 gives an overview of the 226 HIP Diet EXchange protocol. Sections 5 and 6 define the detailed 227 packet formats and rules for packet processing. Finally, Sections 7, 228 8, and 9 discuss policy, security, and IANA considerations, 229 respectively. 231 2. Terms and Definitions 233 2.1. Requirements Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119 [RFC2119]. 239 2.2. Notation 241 [x] indicates that x is optional. 243 {x} indicates that x is encrypted. 245 X(y) indicates that y is a parameter of X. 247 i indicates that x exists i times. 249 --> signifies "Initiator to Responder" communication (requests). 251 <-- signifies "Responder to Initiator" communication (replies). 253 | signifies concatenation of information-- e.g., X | Y is the 254 concatenation of X and Y. 256 FOLD (X, K) denotes the partitioning of X into n K-bit fragments 257 and the iterative folding of these fragments via XOR. The last 258 fragment thereby is padded to K bit by appending 0 bits. Hence, X 259 = x_1, x_2, ..., x_n, where x_i is of length K and x_n is padded 260 to length K by appending 0 bits. FOLD then is computed as FOLD(X, 261 K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 263 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 264 the MAC function M on the input x. 266 2.3. Definitions 268 HIP Diet Exchange (DEX): The ECDH-based HIP handshake for 269 establishing a new HIP association. 271 Host Identity (HI): The static ECDH public key that represents the 272 identity of the host. In HIP DEX, a host proves ownership of the 273 private key belonging to its HI by creating a HIP_MAC with the 274 derived ECDH key (c.f. Section 3). 276 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 277 is generated by folding the HI (c.f. Section 3). 279 HIT Suite: A HIT Suite groups all algorithms that are required to 280 generate and use an HI and its HIT. In particular, these 281 algorithms are: 1) ECDH and 2) FOLD. 283 HIP association: The shared state between two peers after completion 284 of the DEX. 286 Initiator: The host that initiates the DEX. This role is typically 287 forgotten once the DEX is completed. 289 Responder: The host that responds to the Initiator in the DEX. This 290 role is typically forgotten once the DEX is completed. 292 Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is 293 redefined as CMAC. Still, note that CMAC is a message 294 authentication code and not a cryptographic hash function. Thus, 295 a mapping from CMAC(x,y) to RHASH(z) must be defined where RHASH 296 is used. Moreover, RHASH has different security properties in HIT 297 DEX and is not used for HIT generation. 299 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 300 natural output length of RHASH in bits. 302 CKDF: CMAC-based Key Derivation Function. 304 3. Host Identity (HI) and its Structure 306 In this section, the properties of the Host Identity and Host 307 Identity Tag are discussed, and the exact format for them is defined. 308 In HIP, the public key of an asymmetric key pair is used as the Host 309 Identity (HI). Correspondingly, the host itself is defined as the 310 entity that holds the private key of the key pair. See the HIP 311 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 312 details on the difference between an identity and the corresponding 313 identifier. 315 HIP DEX implementations MUST support the Elliptic Curve Diffie- 316 Hellman (ECDH) [RFC6090] key exchange for generating the HI as 317 defined in Section 5.2.3. No additional algorithms are supported at 318 this time. 320 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 321 in the handshake to represent the Host Identity. The DEX Host 322 Identity Tag (HIT) is different from the BEX HIT in two ways: 324 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.1). 326 o The DEX HIT is not generated via a cryptographic hash. Rather, it 327 is a compression of the Host Identity. 329 Due to the latter property, an attacker may be able to find a 330 collision with a HIT that is in use. Hence, policy decisions such as 331 access control MUST NOT be based solely on the HIT. Instead, the HI 332 of a host SHOULD be considered. 334 Carrying HIs and HITs in the header of user data packets would 335 increase the overhead of packets. Thus, it is not expected that 336 these parameters are carried in every packet, but other methods are 337 used to map the data packets to the corresponding HIs. In some 338 cases, this allows to use HIP DEX without any additional headers in 339 the user data packets. For example, if ESP is used to protect data 340 traffic, the Security Parameter Index (SPI) carried in the ESP header 341 can be used to map the encrypted data packet to the correct HIP DEX 342 association. 344 3.1. Host Identity Tag (HIT) 346 With HIP DEX, the Host Identity Tag is a 128-bit value - a 347 compression of the HI prepended with a specific prefix. There are 348 two advantages of using a hashed encoding over the actual variable- 349 sized Host Identity public key in protocols. First, the fixed length 350 of the HIT keeps packet sizes manageable and eases protocol coding. 351 Second, it presents a consistent format for the protocol, independent 352 of the underlying identity technology in use. 354 The structure of the HIT is based on RFC 7343 [RFC7343], called 355 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 356 consists of three parts: first, an IANA assigned prefix to 357 distinguish it from other IPv6 addresses. Second, a four-bit 358 encoding of the algorithms that were used for generating the HI and 359 the compressed representation of HI. Third, a 96-bit hashed 360 representation of the Host Identity. In contrast to HIPv2, HIP DEX 361 employs HITs that are NOT generated by means of a cryptographic hash. 362 Instead, the HI is compressed to 96 bits as defined in the following 363 section. 365 3.2. Generating a HIT from an HI 367 The HIT does not follow the exact semantics of an ORCHID as there is 368 no hash function in HIP DEX. Still, its structure is strongly 369 aligned with the ORCHID design. The same IPv6 prefix used in BEX is 370 used for DEX. The DEX HIT suite (see Section 9) is used for the four 371 bits of the Orchid Generation Algorithm (OGA) field in the ORCHID. 372 The hash representation in an ORCHID is replaced with FOLD(HI,96). 374 4. Protocol Overview 376 This section gives a simplified overview of the HIP DEX protocol 377 operation and does not contain all the details of the packet formats 378 or the packet processing steps. Section 5 and Section 6 describe 379 these aspects in more detail and are normative in case of any 380 conflicts with this section. Importantly, the information given in 381 this section focuses on the differences between the HIPv2 and HIP DEX 382 protocol specifications. 384 4.1. Creating a HIP Association 386 By definition, the system initiating a HIP Diet EXchange is the 387 Initiator, and the peer is the Responder. This distinction is 388 typically forgotten once the base exchange completes, and either 389 party can become the Initiator in future communications. 391 The HIP Diet EXchange serves to manage the establishment of state 392 between an Initiator and a Responder. The first packet, I1, 393 initiates the exchange, and the last three packets, R1, I2, and R2, 394 constitute an authenticated Diffie-Hellman [DH76] key exchange for 395 the Master Key SA generation. This Master Key SA is used by the 396 Initiator and the Responder to wrap secret keying material in the I2 397 and R2 packets. Based on the exchanged keying material, the peers 398 then derive a Pair-wise Key SA if cryptographic keys are needed, 399 e.g., for an ESP-based protection of user data. 401 The Initiator first sends a trigger packet, I1, to the Responder. 402 The packet contains the HIT of the Initiator and possibly the HIT of 403 the Responder, if it is known. Moreover, the I1 packet initializes 404 the negotiation of the Diffie-Hellman group that is used for 405 generating the the Master Key SA. Therefore, the I1 packet contains 406 a list of Diffie Hellman Group IDs supported by the Initiator. Note 407 that in some cases it may be possible to replace this trigger packet 408 by some other form of a trigger, in which case the protocol starts 409 with the Responder sending the R1 packet. In such cases, another 410 mechanism to convey the Initiator's supported DH Groups (e.g., by 411 using a default group) must be specified. 413 The second packet, R1, starts the actual authenticated Diffie-Hellman 414 exchange. It contains a puzzle -- a cryptographic challenge that the 415 Initiator must solve before continuing the exchange. The level of 416 difficulty of the puzzle can be adjusted based on level of trust with 417 the Initiator, current load, or other factors. In addition, the R1 418 contains the Responder's Diffie-Hellman parameter and lists of 419 cryptographic algorithms supported by the Responder. Based on these 420 lists, the Initiator can continue, abort, or restart the base 421 exchange with a different selection of cryptographic algorithms. 423 In the I2 packet, the Initiator MUST display the solution to the 424 received puzzle. Without a correct solution, the I2 message is 425 discarded. The I2 also contains a key wrap parameter that carries a 426 secret keying material of the Initiator. This keying material is 427 only half the final session key. The packet is authenticated by the 428 sender (Initiator) via a MAC. 430 The R2 packet acknowledges the receipt of the I2 packet and completes 431 the handshake. The R2 contains a key wrap parameter that carries the 432 rest of the keying material of the Responder. The packet is 433 authenticated by the sender (Responder) via a MAC. 435 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 436 and "ENC(DH,y)" refer to the random values x and y that are wrapped 437 based on the Master Key SA (indicated by ENC and DH). Note that x 438 and y each constitute half the final session key material. The 439 packets also contain other parameters that are not shown in this 440 figure. 442 Initiator Responder 444 I1: 445 ---------------------------------> 446 remain stateless 447 R1: puzzle, HI 448 <-------------------------------- 449 solve puzzle 450 perform ECDH 451 encrypt x 452 I2: solution, HI, ENC(DH,x), mac 453 ---------------------------------> 454 check puzzle 455 perform ECDH 456 check mac 457 decrypt x 458 encrypt y 459 R2: ENC(DH,y), mac 460 <--------------------------------- 461 check mac 462 decrypt y 464 4.1.1. HIP Puzzle Mechanism 466 The purpose of the HIP puzzle mechanism is to protect the Responder 467 from a number of denial-of-service threats. It allows the Responder 468 to delay state creation until receiving the I2 packet. Furthermore, 469 the puzzle allows the Responder to use a fairly cheap calculation to 470 check that the Initiator is "sincere" in the sense that it has 471 churned enough CPU cycles in solving the puzzle. 473 The puzzle mechanism enables a Responder to immediately reject an I2 474 packet if it does not contain a valid puzzle solution. To verify the 475 puzzle solution, the Responder only has to compute a single CMAC 476 operation. After a successful puzzle verification, the Responder can 477 securely create session-specific state and perform CPU-intensive 478 operations such as a Diffie-Hellman key generation. By varying the 479 difficulty of the puzzle, the Responder can frustrate CPU or memory 480 targeted DoS attacks. Under normal network conditions, the puzzle 481 difficulty SHOULD be zero, thus effectively reverting the puzzle 482 mechanism to a cookie-based DoS protection mechanism. Without 483 setting the puzzle difficulty to zero under normal network 484 conditions, potentially scarce computation resources at the Initiator 485 would be churned unnecessarily. 487 Conceptually, the puzzle mechanism in HIP DEX is the same as in 488 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 489 [RFC7401] for more detailed information about the employed mechanism. 490 Notably, the only difference between the puzzle mechanism in HIP DEX 491 and HIPv2 is that HIP DEX uses CMAC instead of a hash function for 492 solving and verifying a puzzle. The implications of this change on 493 the puzzle implementation are discussed in Section 6.1. 495 4.1.2. HIP State Machine 497 The HIP DEX state machine has the same states as the BEX state 498 machine (see 4.4. in [RFC7401]). However, HIP DEX features an 499 retransmission strategy with an optional packet receipt for the I2. 500 The goal of this packet receipt is reducing premature I2 501 retransmissions in sensor networks with low computation resources and 502 high packet loss [HWZ13]. As a result, there are minor changes to 503 the transitioning steps between specific states. The following 504 section documents these differences in the HIP DEX state machine 505 compared to HIP BEX. 507 4.1.2.1. HIP DEX Retransmission Mechanism 509 For the retransmission of I1 and I2 packets, the Initiator adopts the 510 retransmission strategy of HIP BEX (see Section 4.4.3. in [RFC7401]). 511 This strategy is based on a timeout value that is set to the worst- 512 case anticipated round-trip time (RTT). For each received I1 or I2, 513 the Responder sends an R1 or R2, respectively. This design trait 514 enables the Responder to remain stateless until the reception of the 515 I2. The Initiator stops retransmitting I1 or I2 packets after the 516 reception of the corresponding R1 or R2. If the Initiator did not 517 receive an R1 after I1_RETRIES_MAX tries, it stops I1 518 retransmissions. Likewise, it stops retransmitting I2 packets after 519 I2_RETRIES_MAX unsuccessful tries. 521 The Responder SHOULD NOT perform operations related to the Diffie- 522 Hellman key exchange or the keying material wrapped in the 523 ENCRYPTED_KEY parameters for retransmitted I2 packets. Instead, it 524 SHOULD re-use the previously established state to re-create the R2. 526 The potentially high processing time of an I2 packet at the Responder 527 may cause retransmissions if the time required for I2 transmission 528 and processing exceeds the RTT-based retransmission timeout. Thus, 529 the Initiator should also take the processing time of I2 packets into 530 account. To this end, the Responder MAY optionally notify the 531 Initiator about the anticipated delay if the I2 incurs a considerable 532 processing overhead. The Responder MAY therefore send a NOTIFY 533 packet to the Initiator before it commences the ECDH operation. The 534 NOTIFY packet serves as an acknowledgement for the I2 and consists of 535 a NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 536 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 537 contains the anticipated remaining processing time for the I2 packet 538 in milliseconds as Notification Data . This processing time can, 539 e.g., be estimated by measuring the computation time of the ECDH key 540 derivation operation at Responder boot-up. After the I2 processing 541 has finished, the Responder sends the regular R2. 543 When the Initiator receives the NOTIFY packet, it resets the I2 544 retransmission timer to the processing time indicated by the 545 Responder in the NOTIFICATION parameter. If the indicated processing 546 time is shorter than the RTT-based timeout, the Initiator MUST set 547 the retransmission timer to the RTT-based timeout. Additionally, the 548 Initiator MUST NOT set a higher retransmission timeout than allowed 549 by a local policy. Hence, I2 retransmissions are never triggered in 550 shorter succession than without this optional retransmission 551 extension. Moreover, there is a defined upper bound to which 552 unauthenticated NOTIFY messages can delay the handshake in case of 553 lost R2 packets. 555 4.1.2.2. HIP State Processes 557 HIP DEX clarifies or introduces the following new transitions. 559 System behavior in state I2-SENT, Table 1. 561 +---------------------+---------------------------------------------+ 562 | Trigger | Action | 563 +---------------------+---------------------------------------------+ 564 | Receive NOTIFY, | Set I2 retransmission timer according to | 565 | process | NOTIFY payload and stay at I2-SENT | 566 | | | 567 | Timeout | Increment timeout counter | 568 | | | 569 | | If counter is less than I2_RETRIES_MAX, | 570 | | send I2, reset timer to RTT and stay at | 571 | | I2-SENT | 572 | | | 573 | | If counter is greater than I2_RETRIES_MAX, | 574 | | go to E-FAILED | 575 +---------------------+---------------------------------------------+ 577 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 579 4.1.2.3. Simplified HIP State Diagram 581 The following diagram shows the major state transitions. Transitions 582 based on received packets implicitly assume that the packets are 583 successfully authenticated or processed. 585 +-+ +------------------------------+ 586 I1 received, send R1 | | | | 587 | v v | 588 Datagram to send +--------------+ I2 received, send R2 | 589 Send I1 +--------------| UNASSOCIATED |--------------+ | 590 +-+ | +-+ +--------------+ | | 591 send | | | | | | | 592 I1 t | | | | | Alg. not supported, send I1 | | 593 msec v | v | v | | 594 +---------+ I2 received, send R2 | | 595 +---->| I1-SENT |-------------------------------------+ | | 596 | +---------+ | | | 597 | | +----------------------+ | | +-+receive | 598 | send I2+-+ | R1 received, | I2 received, send R2 | | | | |I2, | 599 | t msec | v v send I2 | v v v | v send R2 | 600 | +---------+ | +---------+ | 601 | +->| I2-SENT |------------+ | R2-SENT |<--+ | 602 | | +---------+ +---------+ | | 603 | | | | | | 604 | | | data| | | 605 | |receive | or| | | 606 | |R1, send | EC timeout| receive I2,| | 607 | |I2 |R2 received +--------------+ | send R2| | 608 | | +----------->| ESTABLISHED |<--------+ | | 609 | | +--------------+ | | 610 | | | | | receive I2, send R2 | | 611 | | recv+------------+ | +------------------------+ | 612 | | CLOSE,| | | | 613 | | send| No packet sent| | | 614 | | CLOSE_ACK| /received for | timeout | | 615 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 616 | | | CLOSE +--->| CLOSING |--+ retransmit | | 617 | | | +---------+ CLOSE | | 618 +--|------------|----------------------+| | | | | | 619 +------------|-----------------------+ | | +-----------------+ | 620 | | +-----------+ +-------------------|----+ 621 | +-----------+ | receive CLOSE, CLOSE_ACK | | 622 | | | send CLOSE_ACK received or | | 623 | | | timeout | | 624 | | | (UAL+MSL) | | 625 | v v | | 626 | +--------+ receive I2, send R2 | | 627 +-----------------------| CLOSED |----------------------------+ | 628 +--------+ /-------------------------+ 629 ^ | \-------/ timeout (UAL+2MSL), 630 | | move to UNASSOCIATED 631 +-+ 632 CLOSE received, send CLOSE_ACK 634 4.1.3. HIP DEX Security Associations 636 HIP DEX establishes two Security Associations (SA), one for the 637 Diffie-Hellman derived key, or Master Key, and one for the session 638 key, or Pair-wise Key. 640 4.1.3.1. Master Key SA 642 The Master Key SA is used to authenticate HIP packets and to encrypt 643 selected HIP parameters in HIP DEX packet exchanges. Since only 644 little data is protected by this SA, it can be long-lived with no 645 need for rekeying. 647 The Master Key SA contains the following elements: 649 o Source HIT 651 o Destination HIT 653 o HIP_Encrypt Key 654 o HIP_MAC Key 656 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 657 Hellman derived key as described in Section 6.3. Their length is 658 determined by the HIP_CIPHER. 660 4.1.3.2. Pair-wise Key SA 662 The Pair-wise Key SA is used to authenticate and to encrypt user 663 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 664 The Pair-wise Key SA elements are defined by the data transform (e.g. 665 ESP_TRANSFORM [RFC7402]). 667 The keys for the Pair-wise Key SA are derived based on the wrapped 668 keying material exchanged in the ENCRYPTED_KEY parameter (see 669 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 670 keying material of the two peers is concatenated. This concatenation 671 forms the input to a Key Derivation Function (KDF). If the data 672 transform does not specify its own KDF, the key derivation function 673 defined in Section 6.3 is used. Even though this input is randomly 674 distributed, a KDF Extract phase may be needed to get the proper 675 length for the input to the KDF Expand phase. 677 4.1.4. User Data Considerations 679 The User Data Considerations in Section 4.5. of [RFC7401] also apply 680 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 681 Loss of state due to system reboot may be a critical performance 682 issue for constrained sensor/actuator devices. Thus, implementors 683 MAY choose to use non-volatile, secure storage for HIP states in 684 order for them to survive a system reboot. This will limit state 685 loss during reboots to only those situations with an SA timeout. 687 5. Packet Formats 689 5.1. Payload Format 691 HIP DEX employs the same fixed HIP header and payload structure as 692 HIP BEX. As such, the specifications in Section 5.1 of [RFC7401] 693 also apply to HIP DEX. 695 5.2. HIP Parameters 697 The HIP parameters carry information that is necessary for 698 establishing and maintaining a HIP association. For example, the 699 peer's public keys as well as the signaling for negotiating ciphers 700 and payload handling are encapsulated in HIP parameters. Additional 701 information, meaningful for end-hosts or middleboxes, may also be 702 included in HIP parameters. The specification of the HIP parameters 703 and their mapping to HIP packets and packet types is flexible to 704 allow HIP extensions to define new parameters and new protocol 705 behavior. 707 In HIP packets, HIP parameters are ordered according to their numeric 708 type number and encoded in TLV format. 710 HIP DEX reuses the HIP parameters of HIP BEX defined in Section 5.2. 711 of [RFC7401] where possible. Still, HIP DEX further restricts and/or 712 extends the following existing parameter types: 714 o HIT_SUITE_LIST is limited to HIT suite ECDH/FOLD. 716 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 718 o HIP_CIPHER is restricted to NULL-ENCRYPT and AES-128-CTR. 720 o RHASH and RHASH_len are redefined to CMAC for PUZZLE, SOLUTION, 721 HIP_MAC (see Section 6.1 and Section 6.2). 723 In addition, HIP DEX introduces the following new parameter: 725 +------------------+------+----------+------------------------------+ 726 | TLV | Type | Length | Data | 727 +------------------+------+----------+------------------------------+ 728 | ENCRYPTED_KEY | 643 | variable | Encrypted container for key | 729 | | | | generation exchange | 730 +------------------+------+----------+------------------------------+ 732 5.2.1. HIT_SUITE_LIST 734 The HIT_SUITE_LIST parameter contains a list of the supported HIT 735 suite IDs of the Responder. The HIT suites in DEX are limited to: 737 HIT suite ID 738 ECDH/FOLD 8 740 Since the HIT of the Initiator is a DEX HIT, the Responder MUST only 741 respond with a DEX HIT suite ID. 743 5.2.2. DH_GROUP_LIST 745 The DH_GROUP_LIST parameter contains the list of supported DH Group 746 IDs of a host. The following ECC curves are supported in HIP DEX: 748 Group KDF Value 749 NIST P-256 [RFC5903] CKDF 7 750 NIST P-384 [RFC5903] CKDF 8 751 NIST P-521 [RFC5903] CKDF 9 752 SECP160R1 [SECG] CKDF 10 754 The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH 755 group 10 is covered in [SECG]. 757 5.2.3. HOST_ID 759 The HI Algorithms in DEX are limited to: 761 Algorithm 762 profiles Values 763 ECDH 1 765 ECC-based Host Identities are serialized as described in 766 Section 5.2.9. of [RFC7401]. The supported curves for the HI in HIP 767 DEX are defined in Section 5.2.2. 769 5.2.4. HIP_CIPHER 771 The HIP ciphers in DEX are limited to: 773 Suite ID Value 775 RESERVED 0 776 NULL-ENCRYPT 1 ([RFC2410]) 777 AES-128-CTR 5 ([RFC3686]) 779 Mandatory implementation: AES-128-CTR. NULL-ENCRYPTION [RFC2410] is 780 included for testing purposes. 782 5.2.5. ENCRYPTED_KEY 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type | Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 / Encrypted value / 789 / / 790 / +-------------------------------+ 791 / | Padding | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Type 643 795 Length length in octets, excluding Type, Length, and 796 Padding 797 Encrypted The value is encrypted using an encryption algorithm 798 value as defined in the HIP_CIPHER parameter. 800 The ENCRYPTED_KEY parameter encapsulates a random value that is later 801 used in the session key creation process (see Section 6.3). This 802 random value MUST have a length of at least 64 bit. The puzzle value 803 #I and the puzzle solution #J (see [RFC7401]) is used as the 804 initialization vector (IV) for the encryption process. To this end, 805 the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16 806 bit value that is initialized to zero with the first use. 808 Once this encryption process is completed, the "encrypted value" data 809 field is ready for inclusion in the Parameter. If necessary, 810 additional Padding for 8-byte alignment is then added according to 811 the rules of TLV Format in [RFC7401]. 813 5.3. HIP Packets 815 DEX uses the same eight basic HIP packets as in BEX (see [RFC7401]). 816 Four are for the HIP handshake (I1, R1, I2, and R2), one is for 817 updating (UPDATE), one is for sending notifications (NOTIFY), and two 818 are for closing a HIP association (CLOSE and CLOSE_ACK). There are 819 some differences regarding the included HIP parameters in the 820 exchange packets of BEX and DEX. This section covers these 821 differences for the DEX packets. Packets not discussed here, follow 822 the structure defined in [RFC7401]. 824 An important difference between packets in HIP BEX and HIP DEX is 825 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 826 included in DEX. Thus, the R1 packet is completely unprotected and 827 can be spoofed. As a result, negotiation parameters contained in the 828 R1 packet have to be re-included in later, protected packets in order 829 to detect and prevent potential downgrading attacks. Moreover, the 830 I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not covered 831 by a signature and purely rely on the HIP_MAC parameter for packet 832 authentication. The processing of these packets is changed 833 accordingly. 835 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 836 header. The Next Header field in the header indicates if there is 837 additional data following the HIP header. 839 5.3.1. I1 - the HIP Initiator Packet 841 The HIP header values for the I1 packet: 843 Header: 844 Packet Type = 1 845 SRC HIT = Initiator's HIT 846 DST HIT = Responder's HIT, or NULL 848 IP ( HIP ( DH_GROUP_LIST ) ) 850 Minimum size = 48 bytes 852 Valid control bits: none 854 The I1 packet contains the fixed HIP header and the Initiator's 855 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 856 type as defined in Section 5.2.1. 858 Regarding the Responder's HIT, the Initiator may receive this HIT 859 either from a DNS lookup of the Responder's FQDN, from some other 860 repository, or from a local table. The Responder's HIT also MUST be 861 of a HIP DEX type. If the Initiator does not know the Responder's 862 HIT, it may attempt to use opportunistic mode by using NULL (all 863 zeros) as the Responder's HIT. See also "HIP Opportunistic Mode" 864 [RFC7401]. 866 The Initiator's and the Responder's HITs both determine the DH group 867 ID that must be used in order to successfully conclude the triggered 868 handshake. HITs, however, do not include a hint about the DH group 869 ID of the ECDH-based Host Identity (HI). To inform the Responder 870 about its employed and its otherwise supported DH Group IDs, the 871 Initiator therefore includes a DH_GROUP_LIST parameter in the I1 872 packet. This parameter MUST include the DH group ID that corresponds 873 to the currently employed Initiator HIT as the first list element. 874 With HIP DEX, the DH_GROUP_LIST parameter MUST only include ECDH 875 groups defined in Section 5.2.2. 877 Since this packet is so easy to spoof even if it were protected, no 878 attempt is made to add to its generation or processing cost. As a 879 result, the DH_GROUP_LIST in the I1 packet is not protected. 881 Implementations MUST be able to handle a storm of received I1 882 packets, discarding those with common content that arrive within a 883 small time delta. 885 5.3.2. R1 - the HIP Responder Packet 887 The HIP header values for the R1 packet: 889 Header: 890 Packet Type = 2 891 SRC HIT = Responder's HIT 892 DST HIT = Initiator's HIT 894 IP ( HIP ( [ R1_COUNTER, ] 895 PUZZLE, 896 DH_GROUP_LIST, 897 HIP_CIPHER, 898 HOST_ID, 899 HIT_SUITE_LIST, 900 TRANSPORT_FORMAT_LIST, 901 [ <, ECHO_REQUEST_UNSIGNED >i ]) 903 Minimum size = 120 bytes 905 Valid control bits: A 907 If the Responder's HI is an anonymous one, the A control MUST be set. 909 The Initiator's HIT MUST match the one received in the I1 packet if 910 the R1 is a response to an I1. If the Responder has multiple HIs, 911 the Responder's HIT MUST match the Initiator's request. If the 912 Initiator used opportunistic mode, the Responder may select among its 913 HIs as described below. See also "HIP Opportunistic Mode" [RFC7401]. 915 The R1 packet generation counter is used to determine the currently 916 valid generation of puzzles. The value is increased periodically, 917 and it is RECOMMENDED that it is increased at least as often as 918 solutions to old puzzles are no longer accepted. 920 The Puzzle contains a Random value #I and the puzzle difficulty K. 921 The difficulty K indicates the number of lower-order bits, in the 922 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 923 SHOULD set K to zero by default and only increase the puzzle 924 difficulty to protect against a DoS attack targeting the DEX 925 handshake. A puzzle difficulty of zero effectively turns the puzzle 926 mechanism into a return-routablility test and is strongly encouraged 927 to conserve energy resources as well as to prevent unnecessary 928 handshake delay in case of a resource-constrained Initiator during 929 normal operation. 931 The DH_GROUP_LIST parameter contains the Responder's order of 932 preference based on which it chose ECDH key contained in the HOST_ID 933 parameter (see below). This allows the Initiator to determine 934 whether its own DH_GROUP_LIST in the I1 packet was manipulated by an 935 attacker. There is a further risk that the Responder's DH_GROUP_LIST 936 was manipulated by an attacker, as the R1 packet cannot be 937 authenticated in DEX as it can in BEX. Thus, it is repeated in the 938 R2 allowing for a final check at that point. 940 The HIP_CIPHER contains the encryption algorithms supported by the 941 Responder to protect the key exchange, in the order of preference. 942 All implementations MUST support the AES-CTR [RFC3686]. 944 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 945 supported and preferred HIT Suites. It enables a Responder to notify 946 the Initiator about other available HIT suites than the one used in 947 the current handshake. Based on the received HIT_SUITE_LIST, the 948 Initiator MAY decide to abort the current handshake and initiate a 949 new handshake with a different mutually supported HIT suite. This 950 mechanism can, e.g., be used to move from an initial HIP DEX 951 handshake to a HIP BEX handshake for peers supporting both protocol 952 variants. 954 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 955 and the Responder HIT in the I1 packet. Specifically, if the I1 956 contains a Responder HIT, the Responder verifies that this HIT 957 matches the required DH group based on the received DH_GROUP_LIST 958 parameter. In case of a positive result, the Responder then selects 959 the corresponding HOST_ID for inclusion in the R1 packet. Likewise, 960 if the Responder HIT in the I1 packet is NULL (i.e., during an 961 opportunistic handshake), the Responder chooses its HOST_ID according 962 to the Initiator's employed DH group as indicated in the received 963 DH_GROUP_LIST parameter and sets the source HIT in the R1 packet 964 accordingly. If the Responder however does not support the DH group 965 required by the Initiator or if the Responder HIT in the I1 packet 966 does not match the required DH group, the Responder selects the 967 mutually preferred and supported DH group based on the DH_GROUP_LIST 968 parameter of the I1. The Responder then includes the corresponding 969 ECDH key in the HOST_ID parameter. This parameter also indicates the 970 selected DH group. Moreover, the Responder sets the source HIT in 971 the R2 based on the destination HIT from the I1 packet. Based on the 972 deviating DH group ID in the HOST_ID parameter, the Initiator then 973 SHOULD abort the current handshake and initiate a new handshake with 974 the mutually supported DH group as far as local policies (see 975 Section 7) permit. 977 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 978 Responder's supported and preferred transport format types. The list 979 allows the Initiator and the Responder to agree on a common type for 980 payload protection. Currently, the only transport format defined is 981 IPsec ESP [RFC7402]. 983 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 984 wants to receive unmodified in the corresponding response packet in 985 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 986 or more ECHO_REQUEST_UNSIGNED parameters. 988 5.3.3. I2 - the Second HIP Initiator Packet 990 The HIP header values for the I2 packet: 992 Header: 993 Type = 3 994 SRC HIT = Initiator's HIT 995 DST HIT = Responder's HIT 997 IP ( HIP ( [R1_COUNTER,] 998 SOLUTION, 999 HIP_CIPHER, 1000 ENCRYPTED_KEY, 1001 HOST_ID, 1002 TRANSPORT_FORMAT_LIST, 1003 HIP_MAC, 1004 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1006 Minimum size = 180 bytes 1008 Valid control bits: A 1010 The HITs used MUST match the ones used in the R1. 1012 If the Initiator's HI is an anonymous one, the A control bit MUST be 1013 set. 1015 If present in the I1 packet, the Initiator MUST include an unmodified 1016 copy of the R1_COUNTER parameter received in the corresponding R1 1017 packet into the I2 packet. 1019 The Solution contains the Random #I from R1 and the computed #J. The 1020 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 1022 The HIP_CIPHER contains the single encryption transform selected by 1023 the Initiator, that it uses to encrypt the ENCRYPTED and 1024 ENCRYPTED_KEY parameters. The chosen cipher MUST correspond to one 1025 of the ciphers offered by the Responder in the R1. All 1026 implementations MUST support the AES-CTR transform [RFC3686]. 1028 The HOST_ID parameter contains the Initiator HI corresponding to the 1029 Initiator HIT. 1031 The ENCRYPTED_KEY contains an Initiator generated random value that 1032 MUST be uniformly distributed. This random value is encrypted with 1033 the Master Key SA using the HIP_CIPHER encryption algorithm. 1035 The ECHO_RESPONSE_UNSIGNED contains the unmodified Opaque data copied 1036 from the corresponding echo request parameter(s). This parameter can 1037 also be used for two-factor password authentication as shown in 1038 Appendix A. 1040 The TRANSPORT_FORMAT_LIST contains the single transport format type 1041 selected by the Initiator. The chosen type MUST correspond to one of 1042 the types offered by the Responder in the R1. Currently, the only 1043 transport format defined is the ESP transport format [RFC7402]. 1045 The MAC is calculated over the whole HIP envelope, excluding any 1046 parameters after the HIP_MAC, as described in Section 6.2. The 1047 Responder MUST validate the HIP_MAC. 1049 5.3.4. R2 - the Second HIP Responder Packet 1051 The HIP header values for the R2 packet: 1053 Header: 1054 Packet Type = 4 1055 SRC HIT = Responder's HIT 1056 DST HIT = Initiator's HIT 1058 IP ( HIP ( DH_GROUP_LIST, 1059 HIP_CIPHER, 1060 ENCRYPTED_KEY, 1061 HIT_SUITE_LIST, 1062 TRANSPORT_FORMAT_LIST, 1063 HIP_MAC) 1065 Minimum size = 108 bytes 1067 Valid control bits: none 1069 The HITs used MUST match the ones used in the I2. 1071 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1072 and TRANSPORT_FORMAT_LIST parameters in R2. These parameters MUST be 1073 the same as included in R1. The parameter are re-included here 1074 because R2 is MACed and thus cannot be altered by an attacker. For 1075 verification purposes, the Initiator re-evaluates the selected suites 1076 and compares the results against the chosen ones. If the re- 1077 evaluated suites do not match the chosen ones, the Initiator acts 1078 based on its local policy. 1080 The ENCRYPTED_KEY contains an Responder generated random value that 1081 MUST be uniformly distributed. This random value is encrypted with 1082 the Master Key SA using the HIP_CIPHER encryption algorithm. 1084 The MAC is calculated over the whole HIP envelope, excluding any 1085 parameters after the HIP_MAC, as described in Section 6.2. The 1086 Initiator MUST validate the HIP_MAC. 1088 5.4. ICMP Messages 1090 When a HIP implementation detects a problem with an incoming packet, 1091 and it either cannot determine the identity of the sender of the 1092 packet or does not have any existing HIP association with the sender 1093 of the packet, it MAY respond with an ICMP packet. Any such reply 1094 MUST be rate-limited as described in [RFC4443]. In most cases, the 1095 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1096 ICMPv6), with the Pointer field pointing to the field that caused the 1097 ICMP message to be generated. The problem cases specified in 1098 Section 5.4. of [RFC7401] also apply to HIP DEX. 1100 6. Packet Processing 1102 Due to the adopted protocol semantics and the inherited general 1103 packet structure, packet processing in HIP DEX only differs from HIP 1104 BEX in very few places. Here, we focus on these differences and 1105 refer to Section 6 in [RFC7401] otherwise. 1107 The processing of outgoing and incoming application data remains the 1108 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1110 6.1. Solving the Puzzle 1112 The procedures for solving and verifying a puzzle in HIP DEX are 1113 strongly based on the corresponding procedures in HIPv2. The only 1114 exceptions are that HIP DEX does not use pre-computation of R1 1115 packets and that RHASH is set to CMAC. As a result, the pre- 1116 computation step in in Section 6.3 of [RFC7401] is skipped in HIP 1117 DEX. 1119 Moreover, the Initiator solves a puzzle by computing: 1120 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1122 Similarly, the Responder verifies a puzzle by computing: 1123 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1125 Apart from these modifications, the procedures defined in Section 6.3 1126 of [RFC7401] also apply for HIP DEX. 1128 6.2. HIP_MAC Calculation and Verification 1130 The following subsections define the actions for processing the 1131 HIP_MAC parameter. 1133 6.2.1. CMAC Calculation 1135 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1136 cryptographic function. The scope of the calculation for HIP_MAC is: 1138 CMAC: { HIP header | [ Parameters ] } 1140 where Parameters include all HIP parameters of the packet that is 1141 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1142 value - 1) and exclude parameters with Type values greater or equal 1143 to HIP_MAC's Type value. 1145 During HIP_MAC calculation, the following applies: 1147 o In the HIP header, the Checksum field is set to zero. 1149 o In the HIP header, the Header Length field value is calculated to 1150 the beginning of the HIP_MAC parameter. 1152 Parameter order is described in [RFC7401]. 1154 The CMAC calculation and verification process is as follows: 1156 Packet sender: 1158 1. Create the HIP packet, without the HIP_MAC or any other parameter 1159 with greater Type value than the HIP_MAC parameter has. 1161 2. Calculate the Header Length field in the HIP header. 1163 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1164 retrieved from KEYMAT as defined in Section 6.3. 1166 4. Add the HIP_MAC parameter to the packet and any parameter with 1167 greater Type value than the HIP_MAC's that may follow. 1169 5. Recalculate the Length field in the HIP header. 1171 Packet receiver: 1173 1. Verify the HIP header Length field. 1175 2. Remove the HIP_MAC parameter, as well as all other parameters 1176 that follow it with greater Type value, saving the contents if 1177 they will be needed later. 1179 3. Recalculate the HIP packet length in the HIP header and clear the 1180 Checksum field (set it to all zeros). 1182 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1183 defined in Section 6.3 and verify it against the received CMAC. 1185 5. Set Checksum and Header Length fields in the HIP header to 1186 original values. 1188 6.3. HIP DEX KEYMAT Generation 1190 The HIP DEX KEYMAT process is used to derive the keys for Master Key 1191 SA as well as for the Pair-wise Key SA. The keys for the Master Key 1192 SA are based from the Diffie-Hellman derived key, Kij, produced 1193 during the HIP Diet EXchange. The Initiator generates Kij during the 1194 creation of the I2 packet and the Responder generates Kij once it 1195 receives the I2 packet. Hence, I2, R2, UPDATE, CLOSE, and CLOSE_ACK 1196 packets can contain authenticated and/or encrypted information. 1198 The keys of the Pair-wise Key SA are not directly used in the HIP DEX 1199 handshake. Instead, these keys are made available as payload 1200 protection keys. Some payload protection mechanisms have their own 1201 Key Derivation Function, and if so this mechanism SHOULD be used. 1202 Otherwise, the HIP DEX KEYMAT process MUST be used to derive the keys 1203 of the Pair-wise Key SA based on the concatenation of the random 1204 values that are contained in the exchanged ENCRYPTED_KEY parameters. 1206 The HIP DEX KEYMAT process consists of two components, CKDF-Extract 1207 and CKDF-Expand. The Extract function COMPRESSES a non-uniformly 1208 distributed key, as is the output of a Diffie-Hellman key derivation, 1209 to EXTRACT the key entropy into a fixed length output. The Expand 1210 function takes either the output of the Extract function or directly 1211 uses a uniformly distributed key and EXPANDS the length of the key, 1212 repeatedly distributing the key entropy, to produce the keys needed. 1214 The key derivation for the Master Key SA employs both the Extract and 1215 Expand phases, whereas the Pair-wise Key SA MAY need both the Extract 1216 and Expand phases if the key is longer than 128 bits. Otherwise, it 1217 only requires the Expand phase. 1219 The CKDF-Extract function is the following operation: 1221 CKDF-Extract(I, IKM, info) -> PRK 1223 where 1225 I Random #I from the PUZZLE parameter 1226 IKM Input input keying material, i.e., either the 1227 Diffie-Hellman derived key or the concatenation of 1228 the random values of the ENCRYPTED_KEY parameters in 1229 the same order as the HITs with sort(HIT-I | HIT-R) 1230 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1231 PRK a pseudorandom key (of RHASH_len/8 octets) 1232 | denotes the concatenation 1234 The pseudorandom key PRK is calculated as follows: 1236 PRK = CMAC(I, IKM | info) 1238 The CKDF-Expand function is the following operation: 1240 CKDF-Expand(PRK, info, L) -> OKM 1242 PRK a pseudorandom key of at least RHASH_len/8 octets 1243 (either the output from the extract step or the 1244 concatenation of the random values of the 1245 ENCRYPTED_KEY parameters in the same order as the 1246 HITs with sort(HIT-I | HIT-R)) 1247 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1248 L length of output keying material in octets 1249 (<= 255*RHASH_len/8) 1250 | denotes the concatenation 1252 The output keying material OKM is calculated as follows: 1254 N = ceil(L/RHASH_len/8) 1255 T = T(1) | T(2) | T(3) | ... | T(N) 1256 OKM = first L octets of T 1258 where 1260 T(0) = empty string (zero length) 1261 T(1) = CMAC(PRK, T(0) | info | 0x01) 1262 T(2) = CMAC(PRK, T(1) | info | 0x02) 1263 T(3) = CMAC(PRK, T(2) | info | 0x03) 1264 ... 1266 (where the constant concatenated to the end of each T(n) is a 1267 single octet.) 1269 sort(HIT-I | HIT-R) is defined as the network byte order 1270 concatenation of the two HITs, with the smaller HIT preceding the 1271 larger HIT, resulting from the numeric comparison of the two HITs 1272 interpreted as positive (unsigned) 128-bit integers in network byte 1273 order. 1275 The initial keys are drawn sequentially in the order that is 1276 determined by the numeric comparison of the two HITs, with comparison 1277 method described in the previous paragraph. HOST_g denotes the host 1278 with the greater HIT value, and HOST_l the host with the lower HIT 1279 value. 1281 The drawing order for initial keys: 1283 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1285 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1287 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1288 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1290 The number of bits drawn for a given algorithm is the "natural" size 1291 of the keys. For the mandatory algorithms, the following sizes 1292 apply: 1294 AES 128 or 256 bits 1296 If other key sizes are used, they must be treated as different 1297 encryption algorithms and defined separately. 1299 6.4. Initiation of a HIP Diet EXchange 1301 The initiation of a HIP DEX handshake proceeds as described in 1302 Section 6.6. of [RFC7401]. 1304 6.5. Processing Incoming I1 Packets 1306 I1 packets in HIP DEX are handled identically to HIP BEX (see 1307 Section 6.7. in [RFC7401]). The only differences are that the 1308 Responder SHOULD select a DEX HIT in the R1 response. Moreover, as 1309 R1 packets are neither covered by a signature nor incur the overhead 1310 of generating an ephemeral Diffie-Hellman key-pair, pre-computation 1311 of an R1 is only marginally beneficial, but would incur additional 1312 memory resources. Hence, the R1 pre-computation is omitted in HIP 1313 DEX. 1315 6.6. Processing Incoming R1 Packets 1317 R1 packets in HIP DEX are handled identically to HIP BEX with the 1318 following differences (see Section 6.8. in [RFC7401]). Only step 4 1319 is omitted in HIP DEX as there is no HIP_SIGNATURE in the R1 packet. 1321 6.7. Processing Incoming I2 Packets 1323 Upon receipt of an I2 packet, the system MAY perform initial checks 1324 to determine whether the I2 packet corresponds to a recent R1 packet 1325 that has been sent out, if the Responder keeps such state. For 1326 example, the sender could check whether the I2 packet is from an 1327 address or HIT for which the Responder has recently received an I1. 1328 To this end, the R1 packet may have had Opaque data included that was 1329 echoed back in the I2 packet. If the I2 packet is considered to be 1330 suspect, it MAY be silently discarded by the system. 1332 Otherwise, the HIP implementation SHOULD process the I2 packet. This 1333 includes validation of the puzzle solution, generating the Diffie- 1334 Hellman key, verifying the MAC, extracting the ENCRYPTED_KEY, 1335 creating state, and finally sending an R2 packet. 1337 The following steps define the conceptual processing rules for 1338 responding to an I2 packet: 1340 1. The system MAY perform checks to verify that the I2 packet 1341 corresponds to a recently sent R1 packet. Such checks are 1342 implementation dependent. See Appendix A in [RFC7401] for a 1343 description of an example implementation. 1345 2. The system MUST check that the Responder's HIT corresponds to 1346 one of its own HITs and MUST drop the packet otherwise. 1348 3. The system MUST further check that the Initiator's HIT Suite is 1349 supported. The Responder SHOULD silently drop I2 packets with 1350 unsupported Initiator HITs. 1352 4. If the system's state machine is in the R2-SENT state, the 1353 system MUST check if the newly received I2 packet is similar to 1354 the one that triggered moving to R2-SENT. If so, it MUST 1355 retransmit a previously sent R2 packet and the state machine 1356 stays in R2-SENT. 1358 5. If the system's state machine is in the I2-SENT state, the 1359 system MUST make a comparison between its local and sender's 1360 HITs (similarly as in Section 6.3). If the local HIT is smaller 1361 than the sender's HIT, it should drop the I2 packet, use the 1362 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1363 #I from the R1 packet received earlier, and get the local 1364 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1365 from the I2 packet sent to the peer earlier. Otherwise, the 1366 system should process the received I2 packet and drop any 1367 previously derived Diffie-Hellman keying material Kij and 1368 ENCRYPTED_KEY keying material it might have generated upon 1369 sending the I2 packet previously. The peer Diffie-Hellman key, 1370 ENCRYPTED_KEY, and the nonce #J are taken from the just arrived 1371 I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying 1372 material, and the nonce I are the ones that were sent earlier in 1373 the R1 packet. 1375 6. If the system's state machine is in the I1-SENT state, and the 1376 HITs in the I2 packet match those used in the previously sent I1 1377 packet, the system uses this received I2 packet as the basis for 1378 the HIP association it was trying to form, and stops 1379 retransmitting I1 packets (provided that the I2 packet passes 1380 the additional checks below). 1382 7. If the system's state machine is in any other state than R2- 1383 SENT, the system SHOULD check that the echoed R1 generation 1384 counter in the I2 packet is within the acceptable range if the 1385 counter is included. Implementations MUST accept puzzles from 1386 the current generation and MAY accept puzzles from earlier 1387 generations. If the generation counter in the newly received I2 1388 packet is outside the accepted range, the I2 packet is stale 1389 (and perhaps replayed) and SHOULD be dropped. 1391 8. The system MUST validate the solution to the puzzle as described 1392 in Section 6. 1394 9. The I2 packet MUST have a single value in the HIP_CIPHER 1395 parameter, which MUST match one of the values offered to the 1396 Initiator in the R1 packet. 1398 10. The system must derive Diffie-Hellman keying material Kij based 1399 on the public value and Group ID in the HOST_ID parameter. This 1400 key is used to derive the keys of the Master Key SA as described 1401 in Section 6.3. If the Diffie-Hellman Group ID is unsupported, 1402 the I2 packet is silently dropped. 1404 11. The implementation SHOULD also verify that the Initiator's HIT 1405 in the I2 packet corresponds to the Host Identity sent in the I2 1406 packet. (Note: some middleboxes may not able to make this 1407 verification.) 1409 12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1410 Other documents specifying transport formats (e.g. [RFC7402]) 1411 contain specifications for handling any specific transport 1412 selected. 1414 13. The system MUST verify the HIP_MAC according to the procedures 1415 in Section 5.2.12. 1417 14. If the checks above are valid, then the system proceeds with 1418 further I2 processing; otherwise, it discards the I2 and its 1419 state machine remains in the same state. 1421 15. The I2 packet may have the A bit set -- in this case, the system 1422 MAY choose to refuse it by dropping the I2 and the state machine 1423 returns to state UNASSOCIATED. If the A bit is set, the 1424 Initiator's HIT is anonymous and should not be stored 1425 permanently. 1427 16. The system MUST extract the keying material from the 1428 ENCRYPTED_KEY parameter. This keying material is a partial 1429 input to the key derivation process for the Pair-wise Key SA 1430 (see Section 6.3). 1432 17. The system initializes the remaining variables in the associated 1433 state, including Update ID counters. 1435 18. Upon successful processing of an I2 message when the system's 1436 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 1437 SENT, an R2 packet is sent and the system's state machine 1438 transitions to state R2-SENT. 1440 19. Upon successful processing of an I2 packet when the system's 1441 state machine is in state ESTABLISHED, the old HIP association 1442 is dropped and a new one is installed, an R2 packet is sent, and 1443 the system's state machine transitions to R2-SENT. 1445 20. Upon the system's state machine transitioning to R2-SENT, the 1446 system starts a timer. The state machine transitions to 1447 ESTABLISHED if some data has been received on the incoming HIP 1448 association, or an UPDATE packet has been received (or some 1449 other packet that indicates that the peer system's state machine 1450 has moved to ESTABLISHED). If the timer expires (allowing for 1451 maximal amount of retransmissions of I2 packets), the state 1452 machine transitions to ESTABLISHED. 1454 6.8. Processing Incoming R2 Packets 1456 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1457 results in the R2 packet being dropped and the state machine staying 1458 in the same state. If an R2 packet is received in state I2-SENT, it 1459 MUST be processed. 1461 The following steps define the conceptual processing rules for an 1462 incoming R2 packet: 1464 1. If the system is in any other state than I2-SENT, the R2 packet 1465 is silently dropped. 1467 2. The system MUST verify that the HITs in use correspond to the 1468 HITs that were received in the R1 packet that caused the 1469 transition to the I1-SENT state. 1471 3. The system MUST verify the HIP_MAC according to the procedures in 1472 Section 6.2. 1474 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1475 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1476 and compare the results against the chosen suites. 1478 5. If any of the checks above fail, there is a high probability of 1479 an ongoing man-in-the-middle or other security attack. The 1480 system SHOULD act accordingly, based on its local policy. 1482 6. The system MUST extract the keying material from the 1483 ENCRYPTED_KEY parameter. This keying material is a partial input 1484 to the key derivation process for the Pair-wise Key SA (see 1485 Section 6.3). 1487 7. Upon successful processing of the R2 packet, the state machine 1488 transitions to state ESTABLISHED. 1490 6.9. Processing UPDATE, NOTIFY, CLOSE, and CLOSE_ACK Packets 1492 UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are handled similarly in 1493 HIP DEX as in HIP BEX (see Sections 6.11. - 6.15. in [RFC7401]). The 1494 only difference is the that the HIP_SIGNATURE is never present and, 1495 therefore, is not required to be processed by the receiving party. 1497 6.10. Handling State Loss 1499 Implementors MAY choose to use non-volatile, secure storage for HIP 1500 states in order for them to survive a system reboot. If no secure 1501 storage capabilities are available, the system SHOULD delete the 1502 corresponding HIP state, including the keying material. If the 1503 implementation does drop the state (as RECOMMENDED), it MUST also 1504 drop the peer's R1 generation counter value, unless a local policy 1505 explicitly defines that the value of that particular host is stored. 1506 An implementation MUST NOT store a peer's R1 generation counters by 1507 default, but storing R1 generation counter values, if done, MUST be 1508 configured by explicit HITs. 1510 7. HIP Policies 1512 There are a number of variables that will influence the HIP exchanges 1513 that each host must support. All HIP DEX implementations SHOULD 1514 provide for an ACL of Initiator's HI to Responder's HI. This ACL 1515 SHOULD also include preferred transform and local lifetimes. 1516 Wildcards SHOULD also be supported for this ACL. 1518 The value of the puzzle difficulty #K used in the HIP R1 must be 1519 chosen with care. Too high numbers of #K will exclude clients with 1520 weak CPUs because these devices cannot solve the puzzle within 1521 reasonable time. #K SHOULD only be raised if a Responder is under 1522 high load, i.e., it can no longer process all incoming HIP 1523 handshakes. Otherwise, the responder SHOULD set #K to 0. 1525 8. Security Considerations 1527 HIP DEX replaces the SIGMA-based authenticated Diffie-Hellman key 1528 exchange of HIPv2 with an exchange of random keying material that is 1529 encrypted by a Diffie-Hellman derived key. Both the Initiator and 1530 Responder contribute to this keying material. 1532 o The strength of the keys for the Pair-wise Key SA is based on the 1533 quality of the random keying material generated by the Initiator 1534 and Responder. Since the Initiator is expected to be a sensor/ 1535 actuator device, there is a natural concern about the quality of 1536 its random number generator. 1538 o DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1539 compromised, ALL HIP connections protected with that HI are 1540 compromised. 1542 o The puzzle mechanism using CMAC may need further study that it 1543 does present the desired level of difficulty. 1545 o The DEX HIT generation MAY present new attack opportunities; 1546 further study is needed. 1548 The R1 packet is unprotected and offers an attacker new resource 1549 attacks against the Initiator. This is mitigated by only processing 1550 a received R1 when the Initiator has previously sent a corresponding 1551 I1. Moreover, the Responder repeats the DH_GROUP_LIST, HIP_CIPHER, 1552 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in R2 in order 1553 to verify that these parameters have not been modified by an attacker 1554 in the R1 packet. 1556 9. IANA Considerations 1558 HIP DEX introduces the following new HIP HIT suite: 1560 +-------+-------------+----------------------+----------------------+ 1561 | Index | Hash | Signature algorithm | Description | 1562 | | function | family | | 1563 +-------+-------------+----------------------+----------------------+ 1564 | 5 | FOLD | ECDH | ECDH HI folded to 96 | 1565 | | | | bits | 1566 +-------+-------------+----------------------+----------------------+ 1568 Table 2: HIT Suites 1570 In addition, this document specified a new HIP Parameter Type defined 1571 in Section 5.2.5. 1573 Moreover, a new HIP Cipher ID is defined in Section 5.2.4. 1575 10. Acknowledgments 1577 The drive to put HIP on a cryptographic 'Diet' came out of a number 1578 of discussions with sensor vendors at IEEE 802.15 meetings. David 1579 McGrew was very helpful in crafting this document. 1581 11. Changelog 1583 This section summarizes the changes made from draft-moskowitz-hip-rg- 1584 dex-05, which was the first stable version of the draft. Note that 1585 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 1587 11.1. Changes in draft-moskowitz-hip-rg-dex-06 1589 o A major change in the ENCRYPT parameter to use AES-CTR rather than 1590 AES-CBC. 1592 11.2. Changes in draft-moskowitz-hip-dex-00 1594 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 1595 submission. 1597 o Added the change section. 1599 o Added a Definitions section. 1601 o Changed I2 and R2 packets to reflect use of AES-CTR for 1602 ENCRYPTED_KEY parameter. 1604 o Cleaned up KEYMAT Generation text. 1606 o Added Appendix with C code for the ECDH shared secret generation 1607 on an 8 bit processor. 1609 11.3. Changes in draft-moskowitz-hip-dex-01 1611 o Numerous editorial changes. 1613 o New retransmission strategy. 1615 o New HIT generation mechanism. 1617 o Modified layout of ENCRYPTED_KEY parameter. 1619 o Clarify to use puzzle difficulty of zero under normal network 1620 conditions. 1622 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 1623 MUST). 1625 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 1626 and I2). 1628 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 1629 echoed in R2 packet. 1631 o Added new author. 1633 11.4. Changes in draft-moskowitz-hip-dex-02 1635 o Introduced formal definition of FOLD function. 1637 o Clarified use of CMAC for puzzle computation in section "Solving 1638 the Puzzle". 1640 o Several editorial changes. 1642 11.5. Changes in draft-moskowitz-hip-dex-03 1644 o Addressed HI crypto agility. 1646 o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 1648 o Extended the IV in the ENCRYPTED_KEY parameter. 1650 o Introduced forward-references to HIP DEX KEYMAT process and 1651 improved KEYMAT section. 1653 o Replaced Appendix A on "C code for ECC point multiplication" with 1654 short discussion in introduction. 1656 o Updated references. 1658 o Further editorial changes. 1660 12. References 1662 12.1. Normative References 1664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1665 Requirement Levels", BCP 14, RFC 2119, March 1997. 1667 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1668 Its Use With IPsec", RFC 2410, November 1998. 1670 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1671 Counter Mode With IPsec Encapsulating Security Payload 1672 (ESP)", RFC 3686, January 2004. 1674 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1675 Message Protocol (ICMPv6) for the Internet Protocol 1676 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1678 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 1679 Routable Cryptographic Hash Identifiers Version 2 1680 (ORCHIDv2)", RFC 7343, September 2014. 1682 [RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 1683 "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, 1684 April 2015. 1686 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 1687 Encapsulating Security Payload (ESP) Transport Format with 1688 the Host Identity Protocol (HIP)", RFC 7402, April 2015. 1690 12.2. Informative References 1692 [DH76] Diffie, W. and M. Hellman, "New Directions in 1693 Cryptography", IEEE Transactions on Information Theory 1694 vol. IT-22, number 6, pages 644-654, Nov 1976. 1696 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 1697 Wehrle, "Tailoring End-to-End IP Security Protocols to the 1698 Internet of Things", in Proceedings of IEEE International 1699 Conference on Network Protocols (ICNP 2013), October 2013. 1701 [I-D.ietf-hip-rfc4423-bis] 1702 Moskowitz, R. and M. Komu, "Host Identity Protocol 1703 Architecture", draft-ietf-hip-rfc4423-bis-11 (work in 1704 progress), April 2015. 1706 [IEEE.802-11.2007] 1707 "Information technology - Telecommunications and 1708 information exchange between systems - Local and 1709 metropolitan area networks - Specific requirements - Part 1710 11: Wireless LAN Medium Access Control (MAC) and Physical 1711 Layer (PHY) Specifications", IEEE Standard 802.11, June 1712 2007, . 1715 [IEEE.802-15-4.2011] 1716 "Information technology - Telecommunications and 1717 information exchange between systems - Local and 1718 metropolitan area networks - Specific requirements - Part 1719 15.4: Wireless Medium Access Control (MAC) and Physical 1720 Layer (PHY) Specifications for Low-Rate Wireless Personal 1721 Area Networks (WPANs)", IEEE Standard 802.15.4, September 1722 2011, . 1725 [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for 1726 Elliptic Curve Cryptography in Wireless Sensor Networks", 1727 in Proceedings of International Conference on Information 1728 Processing in Sensor Networks (IPSN 2008), April 2008. 1730 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 1731 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 1732 2010. 1734 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1735 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1736 5996, September 2010. 1738 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1739 Curve Cryptography Algorithms", RFC 6090, February 2011. 1741 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1742 Constrained-Node Networks", RFC 7228, May 2014. 1744 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 1745 2 , 2000, . 1747 Appendix A. Password-based two-factor authentication during the HIP DEX 1748 handshake 1750 HIP DEX allows to identify authorized connections based on a two- 1751 factor authentication mechanism. With two-factor authentication, 1752 devices that are authorized to communicate with each other are 1753 required to be pre-provisioned with a shared (group) key. The 1754 Initiator uses this pre-provisioned key to encrypt the 1755 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 1756 the Responder verifies that its challenge in the 1757 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 1758 with the correct key. If verified successfully, the Responder 1759 proceeds with the handshake. Otherwise, it silently drops the I2 1760 packet. 1762 Note that there is no explicit signaling in the HIP DEX handshake for 1763 this behavior. Thus, knowledge of two-factor authentication must be 1764 configured externally prior to the handshake. 1766 Authors' Addresses 1768 Robert Moskowitz (editor) 1769 HTT Consulting 1770 Oak Park, MI 1771 USA 1773 EMail: rgm@htt-consult.com 1775 Rene Hummen 1776 Chair of Communication and Distributed Systems, RWTH Aachen 1777 Ahornstrasse 55 1778 Aachen 52074 1779 Germany 1781 EMail: hummen@comsys.rwth-aachen.de 1782 URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/