idnits 2.17.1 draft-moskowitz-hip-dex-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE.802-15-4.2011]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 129 has weird spacing: '...ication dur...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 04, 2014) is 3704 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) == Missing Reference: 'SECG' is mentioned on line 728, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5903 ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 4 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 Verizon 4 Intended status: Standards Track R. Hummen 5 Expires: September 5, 2014 COMSYS, RWTH Aachen 6 March 04, 2014 8 HIP Diet EXchange (DEX) 9 draft-moskowitz-hip-dex-01 11 Abstract 13 This document specifies the Host Identity Protocol Diet EXchange (HIP 14 DEX), a variant of the HIP Base EXchange (HIP BEX) [rfc5201-bis]. 15 The HIP DEX protocol design aims at reducing the overhead of the 16 employed cryptographic primitives by omitting public-key signatures 17 and hash functions. In doing so, the main goal is to still deliver 18 similar security properties to HIP BEX. 20 The HIP DEX protocol is primarily targeted at computation or memory- 21 constrained sensor devices. Like HIP BEX, it is expected to be used 22 together with another suitable security protocol such as the 23 Encapsulated Security Payload (ESP) [rfc5202-bis] for the protection 24 of upper layer protocols. HIP DEX can also be used as a keying 25 mechanism for a MAC layer security protocol as is supported by IEEE 26 802.15.4 [IEEE.802-15-4.2011]. 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 September 5, 2014. 45 Copyright Notice 47 Copyright (c) 2014 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 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4 76 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5 77 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 78 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 79 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 81 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 82 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 83 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 8 84 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 85 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 8 86 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 10 87 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 11 88 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 14 89 4.1.4. User Data Considerations . . . . . . . . . . . . . . 14 90 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 15 91 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 15 92 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 15 93 5.2.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 16 94 5.2.2. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 16 95 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 16 96 5.2.4. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 16 97 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 17 99 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 17 100 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 18 101 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 19 102 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 21 103 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 22 104 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 23 105 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 23 106 6.1. HIP_MAC Calculation and Verification . . . . . . . . . . 23 107 6.1.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 23 108 6.2. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 25 109 6.3. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 28 110 6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . 28 111 6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . 28 112 6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . 28 113 6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . 31 114 6.8. Processing UPDATE, NOTIFY, CLOSE, and CLOSE_ACK Packets . 32 115 6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 32 116 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 32 117 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 118 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 119 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 120 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 34 121 11.1. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 34 122 11.2. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 34 123 11.3. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 34 124 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 125 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 126 12.2. Informative References . . . . . . . . . . . . . . . . . 36 127 Appendix A. C code for ECDH point multiplication on an 8 128 bit processor . . . . . . . . . . . . . . . . . . . 36 129 Appendix B. Password-based two-factor authentication during 130 the HIP DEX handshake . . . . . . . . . . . . . . . 38 132 1. Introduction 134 This memo specifies the Host Identity Protocol Diet EXchange (HIP 135 DEX). HIP DEX builds on the HIP Base EXchange (HIP BEX) 136 [rfc5201-bis]. Notably, HIP DEX preserves the protocol semantics as 137 well as the general packet structure of HIP BEX. It is therefore 138 recommended that [rfc5201-bis] is well-understood before reading this 139 document. 141 The main differences between HIP BEX and HIP DEX are: 143 1. Minimum collection of cryptographic primitives. 145 * Static Elliptic Curve Diffie-Hellman key pairs for encryption 146 of the session key. 148 * AES-CTR for symmetric encryption and AES-CMAC for MACing 149 functions. 151 * A simple fold function for HIT generation. 153 2. Forfeit of Perfect Forward Secrecy with the dropping of ephemeral 154 Diffie-Hellman. 156 3. Forfeit of digital signatures with the removal of a hash 157 function. Reliance on ECDH derived key used in HIP_MAC to prove 158 ownership of the private key. 160 4. Diffie-Hellman derived key ONLY used to protect the HIP packets. 161 A separate secret exchange within the HIP packets creates the 162 session key(s). 164 5. Optional retransmission strategy tailored to handle the 165 potentially extensive processing time of the cryptographic 166 operations and the lossy nature of the communication links in 167 sensor networks. 169 In this document, we focus on the protocol specifications related to 170 these differences. Where differences are not call out explicitly, 171 HIP DEX is the same as specified in [rfc5201-bis]. 173 1.1. The HIP Diet EXchange (DEX) 175 The HIP Diet EXchange is a two-party cryptographic protocol used to 176 establish a secure communication context between hosts. The first 177 party is called the Initiator and the second party the Responder. 178 The four-packet exchange helps to make HIP DoS resilient. The 179 protocol exchanges Static Elliptic Curve Diffie-Hellman keys in the 180 2nd and 3rd packets and transmits keying material for the session key 181 and authenticates the parties in the 3rd and 4th packets. 182 Additionally, the Responder starts a puzzle exchange in the 2nd 183 packet, with the Initiator completing it in the 3rd packet before the 184 Responder performs computationally expensive operations or stores any 185 state from the exchange. Thus, DEX is operationally very similar to 186 BEX. The model is also fairly equivalent to 802.11-2007 187 [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but 188 handled in a single exchange. 190 HIP DEX does not have the option to encrypt the Host Identity of the 191 Initiator in the 3rd packet. The Responder's Host Identity is also 192 not protected. Thus, there is no attempt at anonymity as in HIP BEX. 194 Data packets start to flow after the 4th packet. Similarly to HIP 195 BEX, DEX does not have an explicit transition to connected state for 196 the Responder. When the Responder starts receiving protected 197 datagrams, indicating that the Initiator received the R2 packet, it 198 shifts to connected state. As such the Initiator should take care to 199 NOT send the first data packet until some delta time after it 200 received the R2 packet. This is to provide time for the Responder to 201 process any aggressively retransmitted I2 packets. 203 An existing HIP association can be updated with the update mechanism 204 defined [rfc5201-bis]. Likewise, the association can be torn down 205 with the defined closing mechanism for HIP BEX if it is no longer 206 needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the 207 original HIP BEX 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) [rfc5202-bis] and other end-to- 212 end security protocols. The base protocol does not cover all the 213 fine-grained policy control found in Internet Key Exchange (IKE) 214 [RFC4306] that allows IKE to support complex gateway policies. Thus, 215 HIP DEX is not a replacement for IKEv2. 217 1.2. Memo Structure 219 The rest of this memo is structured as follows. Section 2 defines 220 the central keywords, notation, and terms used throughout the rest of 221 the document. Section 3 defines the structure of the Host Identity 222 and its various representations. Section 4 gives an overview of the 223 HIP Diet EXchange protocol. Sections 5 and 6 define the detailed 224 packet formats and rules for packet processing. Finally, Sections 7, 225 8, and 9 discuss policy, security, and IANA considerations, 226 respectively. 228 2. Terms and Definitions 230 2.1. Requirements Terminology 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in RFC 2119 [RFC2119]. 236 2.2. Notation 238 [x] indicates that x is optional. 240 {x} indicates that x is encrypted. 242 X(y) indicates that y is a parameter of X. 244 i indicates that x exists i times. 246 --> signifies "Initiator to Responder" communication (requests). 248 <-- signifies "Responder to Initiator" communication (replies). 250 | signifies concatenation of information-- e.g., X | Y is the 251 concatenation of X with Y. 253 FOLD (x, K) denotes dividing x into n fragments of K length and 254 XORing them together. The last fragment is padded to K bit by 255 appending 0 bits. 257 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 258 the mac function M on the input x. 260 2.3. Definitions 262 HIP Diet Exchange (DEX): The ECDH-based HIP handshake for 263 establishing a new HIP association. 265 Host Identity (HI): The static ECDH public key that represents the 266 identity of the host. In HIP DEX, a host proves ownership of the 267 private key belonging to its HI by creating a HIP_MAC with the 268 derived ECDH key (c.f. Section 3). 270 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 271 is generated by folding the HI (c.f. Section 3). 273 HIT Suite: A HIT Suite groups all algorithms that are required to 274 generate and use an HI and its HIT. In particular, these 275 algorithms are: 1) ECDH and 2) FOLD. 277 HIP association: The shared state between two peers after completion 278 of the DEX. 280 Initiator: The host that initiates the DEX. This role is typically 281 forgotten once the DEX is completed. 283 Responder: The host that responds to the Initiator in the DEX. This 284 role is typically forgotten once the DEX is completed. 286 Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is 287 redefined as CMAC. Note that CMAC is a message authentication 288 code and not a cryptographic hash function. As such, RHASH has 289 different security properties in DEX and is not used for HIT 290 generation. 292 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 293 natural output length of RHASH in bits. 295 CKDF: CMAC-based Key Derivation Function. 297 3. Host Identity (HI) and its Structure 299 In this section, the properties of the Host Identity and Host 300 Identity Tag are discussed, and the exact format for them is defined. 301 In HIP, the public key of an asymmetric key pair is used as the Host 302 Identity (HI). Correspondingly, the host itself is defined as the 303 entity that holds the private key of the key pair. See the HIP 304 architecture specification [rfc4423-bis] for more details on the 305 difference between an identity and the corresponding identifier. 307 HIP DEX implementations MUST support the Elliptic Curve Diffie- 308 Hellman (ECDH) [RFC6090] key exchange for generating the HI as 309 defined in Section 5.2.3. No additional algorithms are supported at 310 this time. 312 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 313 in the handshake to represent the Host Identity. The DEX Host 314 Identity Tag (HIT) is different from the BEX HIT in two ways: 316 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.1). 318 o The DEX HIT is not generated via a cryptographic hash. Rather, it 319 is a compression of the Host Identity. 321 Due to the latter property, an attacker may be able to find a 322 collision with a HIT that is in use. Hence, policy decisions such as 323 access control MUST NOT be based on the HIT. Instead, the HI of a 324 host SHOULD be considered. 326 Carrying HIs and HITs in the header of user data packets would 327 increase the overhead of packets. Thus, it is not expected that they 328 are carried in every packet, but other methods are used to map the 329 data packets to the corresponding HIs. In some cases, this makes it 330 possible to use HIP without any additional headers in the user data 331 packets. For example, if ESP is used to protect data traffic, the 332 Security Parameter Index (SPI) carried in the ESP header can be used 333 to map the encrypted data packet to the correct HIP association. 335 3.1. Host Identity Tag (HIT) 337 The DEX Host Identity Tag is a 128-bit value - a compression of the 338 HI prepended with a specific prefix. There are two advantages of 339 using a Host Identity Tag over the actual Host Identity public key in 340 protocols. Firstly, its fixed length makes for easier protocol 341 coding and also better manages the packet size cost of this 342 technology. Secondly, it presents a consistent format to the 343 protocol whatever underlying identity technology and Host Identifier 344 size is used. 346 The structure of the HIT is based on RFC 4843-bis [rfc4843-bis], 347 called Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 348 consists of three parts: first, an IANA assigned prefix to 349 distinguish it from other IPv6 addresses. Second, a four-bit 350 encoding of the algorithms that were used for generating the HI and 351 the compressed representation of HI. Third, a 96-bit hashed 352 representation of the Host Identity. In contrast to BEX HITs, DEX 353 HITs are NOT generated by means of a cryptographic hash. Instead, 354 the HI is compressed to 96 bits. 356 3.2. Generating a HIT from an HI 358 The DEX HIT does not follow the exact semantics of an ORCHID as there 359 is no hash function in DEX. However, its structure is strongly 360 aligned with the ORCHID design. The same IPv6 prefix used in BEX is 361 used for DEX. The DEX HIT suite (see Section 9) is used for the four 362 bits of the Orchid Generation Algorithm (OGA) field in the ORCHID. 363 The hash representation in an ORCHID is replaced with a FOLD(HI,96). 365 4. Protocol Overview 367 This section gives a simplified overview of the HIP DEX protocol 368 operation and does not contain all the details of the packet formats 369 or the packet processing steps. Section 5 and Section 6 describe 370 these aspects in more detail and are normative in case of any 371 conflicts with this section. Importantly, the information given in 372 this section focuses on the differences between the BEX and DEX 373 specifications of the HIP protocol. 375 4.1. Creating a HIP Association 377 By definition, the system initiating a HIP handshake is the Initiator 378 and the peer is the Responder. This distinction is forgotten once 379 the handshake completes and either party can become the Initiator in 380 future communications. 382 The HIP Diet EXchange serves to manage the establishment of state 383 between an Initiator and a Responder. The first packet, I1, 384 initiates the handshake, and the last three packets, R1, I2, and R2, 385 constitute an authenticated Diffie-Hellman key exchange for the 386 Master Key SA generation. This Master Key SA is used by the 387 Initiator and the Responder to wrap secret keying material. Based on 388 the exchanged keying material, the peers then derive a Pair-wise Key 389 SA. If cryptographic keys are needed, e.g., for ESP, these keys are 390 expected to be drawn from the wrapped keying material. 392 The second packet, R1, starts the actual exchange. It contains a 393 puzzle - a cryptographic challenge that the Initiator must solve 394 before continuing the exchange. The level of difficulty of the 395 puzzle can be adjusted based on level of trust with the Initiator, 396 current load, or other factors. The R1 also contains lists of 397 cryptographic algorithms supported by the Responder. Based on these 398 lists, the Initiator can continue, abort, or restart the handshake 399 with a different selection of cryptographic algorithms. 401 In the I2 packet, the Initiator must display the solution to the 402 received puzzle. Without a correct solution, the I2 packet is 403 discarded. The I2 also contains a key wrap parameter that carries a 404 secret keying material of the Initiator. This keying material is 405 only half the final session key. The packet is authenticated by the 406 sender (Initiator) via a MAC. 408 The R2 packet finalizes the handshake. The R2 contains a key wrap 409 parameter that carries the rest of the keying material of the 410 Responder. The packet is authenticated by the sender (Initiator) via 411 a MAC. 413 The HIP DEX handshake is illustrated below. The terms "ECR(DH,x)" 414 and "ECR(DH,y)" refer to the wrapped random values that each 415 constitute half the final session key. The packets contain other 416 parameters not shown in this figure. 418 Initiator Responder 420 I1: 421 ---------------------------------> 422 remain stateless 423 R1: puzzle, HI 424 <-------------------------------- 425 solve puzzle 426 perform ECDH 427 encrypt x 428 I2: solution, HI, ECR(DH,x), mac 429 ---------------------------------> 430 check puzzle 431 check mac 432 perform ECDH 433 encrypt y 434 R2: ECR(DH,y), mac 435 <--------------------------------- 436 check mac 438 4.1.1. HIP Puzzle Mechanism 440 The purpose of the HIP puzzle mechanism is to protect the Responder 441 from a number of denial-of-service threats. It allows the Responder 442 to delay state creation until receiving the I2 packet. Furthermore, 443 the puzzle allows the Responder to use a fairly cheap calculation to 444 check that the Initiator is "sincere" in the sense that it has 445 churned enough CPU cycles in solving the puzzle. 447 The puzzle mechanism enables a Responder to immediately reject an I2 448 packet if it does not contain a valid puzzle solution. To verify the 449 puzzle solution, the Responder only has to compute a single CMAC 450 function. After a successful puzzle verification, the Responder can 451 securely create session-specific state and perform CPU-intensive 452 operations such as a Diffie-Hellman key generation. By varying the 453 difficulty of the puzzle, the Responder can frustrate CPU or memory 454 targeted DoS attacks. Under normal conditions, the puzzle difficulty 455 SHOULD be zero, thus effectively disabling the puzzle-based DoS 456 protection mechanism. Otherwise, computation resources at the 457 Initiator would be churned unnecessarily. 459 Conceptually, the puzzle mechanism is the same in HIP DEX as in HIP 460 BEX. The only difference is that DEX uses the CMAC function instead 461 of a hash function for solving and verifying a cryptographic puzzle. 462 Implementations SHOULD include sufficient randomness to the algorithm 463 so that algorithmic complexity attacks become impossible [CRO03]. 464 See Appendix A in [rfc5201-bis] for one possible implementation. 466 The signaling information of the puzzle exchange is the same as in 467 HIP BEX. Hence, this document refers to 4.1.2. in [rfc5201-bis] for 468 detailed information about the puzzle exchange. 470 4.1.2. HIP State Machine 472 The HIP DEX state machine has the same states as the BEX state 473 machine (see 4.4. in [rfc5201-bis]). However, HIP DEX features an 474 retransmission strategy with an optional packet receipt for the I2. 475 The goal of this packet receipt is reducing premature I2 476 retransmissions in sensor networks with low computation resources and 477 high packet loss [hummen2013tailoring]. As a result, there are minor 478 changes to the transitioning steps between specific states. The 479 following section documents these differences in the HIP DEX state 480 machine compared to HIP BEX. 482 4.1.2.1. HIP DEX Retransmission Mechanism 484 For the retransmission of I1 and I2 packets, the Initiator adopts the 485 retransmission strategy of HIP BEX (see Section 4.4.3. in 486 [rfc5201-bis]). This strategy is based on a timeout value that is 487 set to the worst-case anticipated round-trip time (RTT). For each 488 received I1 or I2, the Responder sends an R1 or R2, respectively. 489 This design trait enables the Responder to remain stateless until the 490 reception of the I2. The Initiator stops retransmitting I1 or I2 491 packets after the reception of the corresponding R1 or R2. If the 492 Initiator did not receive an R1 after I1_RETRIES_MAX tries, it stops 493 I1 retransmissions. Likewise, it stops retransmitting I2 packets 494 after I2_RETRIES_MAX unsuccessful tries. 496 The Responder SHOULD NOT perform operations related to the Diffie- 497 Hellman key exchange or the keying material wrapped in the 498 ENCRYPTED_KEY parameters for retransmitted I2 packets. Instead, it 499 SHOULD re-use the previously established state to re-create the R2. 501 The potentially high processing time of an I2 packet at the Responder 502 may cause retransmissions if the time required for I2 transmission 503 and processing exceeds the RTT-based retransmission timeout. Thus, 504 the Initiator should also take the processing time of I2 packets into 505 account. To this end, the Responder MAY optionally notify the 506 Initiator about the anticipated delay if the I2 incurs a considerable 507 processing overhead. The Responder MAY therefore send a NOTIFY 508 packet to the Initiator before it commences the ECDH operation. The 509 NOTIFY packet serves as an acknowledgement for the I2 and consists of 510 a NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 511 (see Section 5.2.19. in [rfc5201-bis]). The NOTIFICATION parameter 512 contains the anticipated remaining processing time for the I2 packet 513 in milliseconds as Notification Data . This processing time can, 514 e.g., be estimated by measuring the computation time of the ECDH key 515 derivation operation at Responder boot-up. After the I2 processing 516 has finished, the Responder sends the regular R2. 518 When the Initiator receives the NOTIFY packet, it resets the I2 519 retransmission timer to the processing time indicated by the 520 Responder in the NOTIFICATION parameter. If the indicated processing 521 time is shorter than the RTT-based timeout, the Initiator MUST set 522 the retransmission timer to the RTT-based timeout. Additionally, the 523 Initiator MUST NOT set a higher retransmission timeout than allowed 524 by a local policy. Hence, I2 retransmissions are never triggered in 525 shorter succession than without this optional retransmission 526 extension. Moreover, there is a defined upper bound to which 527 unauthenticated NOTIFY messages can delay the handshake in case of 528 lost R2 packets. 530 4.1.2.2. HIP State Processes 532 HIP DEX clarifies or introduces the following new transitions. 534 System behavior in state I2-SENT, Table 1. 536 +---------------------+---------------------------------------------+ 537 | Trigger | Action | 538 +---------------------+---------------------------------------------+ 539 | Receive NOTIFY, | Set I2 retransmission timer according to | 540 | process | NOTIFY payload and stay at I2-SENT | 541 | | | 542 | Timeout | Increment timeout counter | 543 | | | 544 | | If counter is less than I2_RETRIES_MAX, | 545 | | send I2, reset timer to RTT and stay at | 546 | | I2-SENT | 547 | | | 548 | | If counter is greater than I2_RETRIES_MAX, | 549 | | go to E-FAILED | 550 +---------------------+---------------------------------------------+ 552 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 554 4.1.2.3. Simplified HIP State Diagram 556 The following diagram shows the major state transitions. Transitions 557 based on received packets implicitly assume that the packets are 558 successfully authenticated or processed. 560 +-+ +------------------------------+ 561 I1 received, send R1 | | | | 562 | v v | 563 Datagram to send +--------------+ I2 received, send R2 | 564 Send I1 +--------------| UNASSOCIATED |--------------+ | 565 +-+ | +-+ +--------------+ | | 566 send | | | | | | | 567 I1 t | | | | | Alg. not supported, send I1 | | 568 msec v | v | v | | 569 +---------+ I2 received, send R2 | | 570 +---->| I1-SENT |-------------------------------------+ | | 571 | +---------+ | | | 572 | | +----------------------+ | | +-+receive | 573 | send I2+-+ | R1 received, | I2 received, send R2 | | | | |I2, | 574 | t msec | v v send I2 | v v v | v send R2 | 575 | +---------+ | +---------+ | 576 | +->| I2-SENT |------------+ | R2-SENT |<--+ | 577 | | +---------+ +---------+ | | 578 | | | | | | 579 | | | data| | | 580 | |receive | or| | | 581 | |R1, send | EC timeout| receive I2,| | 582 | |I2 |R2 received +--------------+ | send R2| | 583 | | +----------->| ESTABLISHED |<--------+ | | 584 | | +--------------+ | | 585 | | | | | receive I2, send R2 | | 586 | | recv+------------+ | +------------------------+ | 587 | | CLOSE,| | | | 588 | | send| No packet sent| | | 589 | | CLOSE_ACK| /received for | timeout | | 590 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 591 | | | CLOSE +--->| CLOSING |--+ retransmit | | 592 | | | +---------+ CLOSE | | 593 +--|------------|----------------------+| | | | | | 594 +------------|-----------------------+ | | +-----------------+ | 595 | | +-----------+ +-------------------|----+ 596 | +-----------+ | receive CLOSE, CLOSE_ACK | | 597 | | | send CLOSE_ACK received or | | 598 | | | timeout | | 599 | | | (UAL+MSL) | | 600 | v v | | 601 | +--------+ receive I2, send R2 | | 602 +-----------------------| CLOSED |----------------------------+ | 603 +--------+ /-------------------------+ 604 ^ | \-------/ timeout (UAL+2MSL), 605 | | move to UNASSOCIATED 606 +-+ 607 CLOSE received, send CLOSE_ACK 609 4.1.3. HIP DEX Security Associations 611 HIP DEX establishes two Security Associations (SA), one for the 612 Diffie-Hellman derived key, or Master Key, and one for the session 613 key, or Pair-wise Key. 615 4.1.3.1. Master Key SA 617 The Master Key SA is used to authenticate HIP packets and to encrypt 618 selected HIP parameters in HIP DEX packet exchanges. Since only 619 little data is protected by this SA, it can be long-lived with no 620 need for rekeying. 622 The Master Key SA contains the following elements: 624 o Source HIT 626 o Destination HIT 628 o HIP_Encrypt Key 630 o HIP_MAC Key 632 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 633 Hellman derived key as described in Section 6.2. Their length is 634 determined by the HIP_CIPHER. 636 4.1.3.2. Pair-wise Key SA 638 The Pair-wise Key SA is used to authenticate and to encrypt user 639 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 640 The Pair-wise Key SA elements are defined by the data transform (e.g. 641 ESP_TRANSFORM [rfc5202-bis]). 643 The keys for the Pair-wise Key SA are derived based on the wrapped 644 keying material exchanged in the ENCRYPTED_KEY parameter (see 645 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 646 keying material of the two peers is concatenated. This concatenation 647 forms the input to a Key Derivation Function (KDF). If the data 648 transform does not specify its own KDF, then the key derivation 649 function defined in Section 6.2 is used. Even though this input is 650 randomly distributed, a KDF Extract phase may be needed to get the 651 proper length for the input to the KDF Expand phase. 653 4.1.4. User Data Considerations 655 The User Data Considerations in Section 4.5. of [rfc5201-bis] also 656 apply to HIP DEX. There is only one difference between HIP BEX and 657 HIP DEX. Loss of state due to system reboot may be a critical 658 performance issue for constrained sensor devices. Thus, implementors 659 MAY choose to use non-volatile, secure storage for HIP states in 660 order for them to survive a system reboot. This will limit state 661 loss during reboots to only those situations with an SA timeout. 663 5. Packet Formats 665 5.1. Payload Format 667 HIP DEX employs the same fixed HIP header and payload structure as 668 HIP BEX. As such, the specifications in Section 5.1 of [rfc5201-bis] 669 also apply to HIP DEX. 671 5.2. HIP Parameters 673 The HIP parameters carry information that is necessary for 674 establishing and maintaining a HIP association. For example, the 675 peer's public keys as well as the signaling for negotiating ciphers 676 and payload handling are encapsulated in HIP parameters. Additional 677 information, meaningful for end-hosts or middleboxes, may also be 678 included in HIP parameters. The specification of the HIP parameters 679 and their mapping to HIP packets and packet types is flexible to 680 allow HIP extensions to define new parameters and new protocol 681 behavior. 683 In HIP packets, HIP parameters are ordered according to their numeric 684 type number and encoded in TLV format. 686 HIP DEX reuses the HIP parameters of HIP BEX defined in Section 5.2. 687 of [rfc5201-bis] where possible. Still, HIP DEX further restricts 688 and/or extends the following existing parameter types: 690 o HIT_SUITE_LIST is limited to HIT suite ECDH/FOLD. 692 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 694 o HIP_CIPHER is restricted to NULL-ENCRYPT and AES-128-CTR. 696 o RHASH and RHASH_len are redefined to CMAC for PUZZLE, SOLUTION, 697 HIP_MAC (see Section 6 and Section 6.1). 699 In addition, HIP DEX introduces the following new parameter: 701 +------------------+------+----------+------------------------------+ 702 | TLV | Type | Length | Data | 703 +------------------+------+----------+------------------------------+ 704 | ENCRYPTED_KEY | 643 | variable | Encrypted container for key | 705 | | | | generation exchange | 706 +------------------+------+----------+------------------------------+ 708 5.2.1. HIT_SUITE_LIST 710 The HIT_SUITE_LIST parameter contains a list of the supported HIT 711 suite IDs of the Responder. The HIT suites in DEX are limited to: 713 HIT suite ID 714 ECDH/FOLD 8 716 Since the HIT of the Initiator is a DEX HIT, the Responder MUST only 717 respond with a DEX HIT suite ID. 719 5.2.2. DH_GROUP_LIST 721 The DH_GROUP_LIST parameter contains the list of supported DH Group 722 IDs of a host. The following ECC curves are supported in HIP DEX: 724 Group KDF Value 725 NIST P-256 [RFC5903] CKDF 7 726 NIST P-384 [RFC5903] CKDF 8 727 NIST P-521 [RFC5903] CKDF 9 728 SECP160R1 [SECG] CKDF 10 730 The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH 731 group 10 is covered in [rfc5201-bis]. 733 5.2.3. HOST_ID 735 The HI Algorithms in DEX are limited to: 737 Algorithm 738 profiles Values 739 ECDH 1 741 ECC-based Host Identities are serialized as described in 742 Section 5.2.9. of [rfc5201-bis]. The supported curves for the HI in 743 HIP DEX are defined in Section 5.2.2. 745 5.2.4. HIP_CIPHER 747 The HIP ciphers in DEX are limited to: 749 Suite ID Value 751 RESERVED 0 752 NULL-ENCRYPT 1 ([RFC2410]) 753 AES-128-CTR 5 ([RFC3686]) 755 Mandatory implementation: AES-128-CTR. NULL-ENCRYPTION [RFC2410] is 756 included for testing purposes. 758 5.2.5. ENCRYPTED_KEY 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type | Length | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 / Encrypted value / 766 / / 767 / +-------------------------------+ 768 / | Padding | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Type 643 772 Length length in octets, excluding Type, Length, and 773 Padding 774 Encrypted The value is encrypted using an encryption algorithm 775 value as defined in the HIP_CIPHER parameter. 777 The ENCRYPTED_KEY parameter encapsulates a random value that is later 778 used in the session key creation process. The Puzzle value I (see 779 [rfc5201-bis]) is used as the initialization vector (IV) for the 780 encryption process. The AES-CTR counter is a 16 bit value that is 781 initialized to zero with the first use. 783 Once this encryption process is completed, the "encrypted value" data 784 field is ready for inclusion in the Parameter. If necessary, 785 additional Padding for 8-byte alignment is then added according to 786 the rules of TLV Format in [rfc5201-bis]. 788 5.3. HIP Packets 789 DEX uses the same eight basic HIP packets as in BEX (see 790 [rfc5201-bis]). Four are for the HIP handshake (I1, R1, I2, and R2), 791 one is for updating (UPDATE), one is for sending notifications 792 (NOTIFY), and two are for closing a HIP association (CLOSE and 793 CLOSE_ACK). There are some differences regarding the included HIP 794 parameters in the exchange packets of BEX and DEX. This section 795 covers these differences for the DEX packets. Packets not discussed 796 here, follow the structure defined in [rfc5201-bis]. 798 An important difference between packets in HIP BEX and HIP DEX is 799 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 800 included in DEX. Thus, the R1 packet is completely unprotected and 801 can be spoofed. As a result, negotiation parameters contained in the 802 R1 packet have to be re-included in later, protected packets in order 803 to detect and prevent potential downgrading attacks. Moreover, the 804 I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not covered 805 by a signature and purely rely on the HIP_MAC parameter for packet 806 authentication. The processing of these packets is changed 807 accordingly. 809 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 810 header. The Next Header field in the header indicates if there is 811 additional data following the HIP header. 813 5.3.1. I1 - the HIP Initiator Packet 815 The HIP header values for the I1 packet: 817 Header: 818 Packet Type = 1 819 SRC HIT = Initiator's HIT 820 DST HIT = Responder's HIT, or NULL 822 IP ( HIP ( DH_GROUP_LIST ) ) 824 Minimum size = 48 bytes 826 Valid control bits: none 828 The I1 packet contains the fixed HIP header and the Initiator's 829 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a DEX type. 831 The Initiator receives the Responder's HIT either from a DNS lookup 832 of the Responder's FQDN, from some other repository, or from a local 833 table. The Responder's HIT MUST be a DEX HIT. If the Initiator does 834 not know the Responder's HIT, it may attempt to use opportunistic 835 mode by using NULL (all zeros) as the Responder's HIT. See also "HIP 836 Opportunistic Mode" [rfc5201-bis]. 838 The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform 839 the Responder of its preferred DH Group IDs. Only ECDH groups may be 840 included in this list. The group ID corresponding to the current 841 Initiator HIT MUST be listed first in this DH_GROUP_LIST parameter to 842 notify the Responder about the DH group that must be used to 843 successfully complete the handshake. 845 Since this packet is so easy to spoof even if it were protected, no 846 attempt is made to add to its generation or processing cost. As a 847 result, the DH_GROUP_LIST in the I1 packet is not protected. 849 Implementations MUST be able to handle a storm of received I1 850 packets, discarding those with common content that arrive within a 851 small time delta. 853 5.3.2. R1 - the HIP Responder Packet 855 The HIP header values for the R1 packet: 857 Header: 858 Packet Type = 2 859 SRC HIT = Responder's HIT 860 DST HIT = Initiator's HIT 862 IP ( HIP ( [ R1_COUNTER, ] 863 PUZZLE, 864 DH_GROUP_LIST, 865 HIP_CIPHER, 866 HOST_ID, 867 HIT_SUITE_LIST, 868 TRANSPORT_FORMAT_LIST, 869 [ <, ECHO_REQUEST_UNSIGNED >i ]) 871 Minimum size = 120 bytes 873 Valid control bits: A 875 If the Responder's HI is an anonymous one, the A control MUST be set. 877 The Initiator's HIT MUST match the one received in the I1 packet if 878 the R1 is a response to an I1. If the Responder has multiple HIs, 879 the Responder's HIT MUST match the Initiator's request. If the 880 Initiator used opportunistic mode, the Responder may select among its 881 HIs as described below. See also "HIP Opportunistic Mode" 882 [rfc5201-bis]. 884 The R1 packet generation counter is used to determine the currently 885 valid generation of puzzles. The value is increased periodically, 886 and it is RECOMMENDED that it is increased at least as often as 887 solutions to old puzzles are no longer accepted. 889 The Puzzle contains a Random value #I and the puzzle difficulty K. 890 The difficulty K indicates the number of lower-order bits, in the 891 puzzle CMAC result, that MUST be zeros (see [rfc5201-bis]). 892 Responders SHOULD set K to zero by default and only increase the 893 puzzle difficulty to protect against a DoS attack targeting the DEX 894 handshake. A puzzle difficulty of zero effectively disables the 895 puzzle mechanism and is strongly encouraged to conserve energy 896 resources as well as to prevent unnecessary handshake delay in case 897 of a resource-constrained Initiator during normal operation. 899 The HIP_CIPHER contains the encryption algorithms supported by the 900 Responder to protect the key exchange, in the order of preference. 901 All implementations MUST support the AES-CTR [RFC3686]. 903 The used Initiator HIT already determines the DH group that must be 904 used to successfully conclude the handshake. However, while the 905 Initiator HIT conveys that ECDH keys must be used for the HOST_ID, it 906 does not provide information about the employed DH group. Still, the 907 Responder can determine the DH Group ID based on the DH_GROUP_LIST 908 parameter in the I1. If the I1 contains a Responder HIT, the 909 Responder verifies that its Responder HIT matches the required DH 910 group of the Initiator. The Responder then selects the corresponding 911 HOST_ID for inclusion in the R1. If the Responder HIT is NULL (i.e., 912 during an opportunistic handshake) the Responder chooses its HOST_ID 913 according to the Initiator's preference expressed in the 914 DH_GROUP_LIST parameter in the I1. The Responder sends back its own 915 preference based on which it chose the HOST_ID as DH_GROUP_LIST. 916 This allows the Initiator to determine whether its own DH_GROUP_LIST 917 in the I1 was manipulated by an attacker. There is a further risk 918 that the Responder's DH_GROUP_LIST was manipulated by an attacker, as 919 R1 cannot be authenticated in DEX as it can in BEX. Thus, it is 920 repeated in R2 allowing for a final check at that point. 922 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 923 supported and preferred HIT Suites. It enables a Responder to notify 924 the Initiator about other available HIT suites than the one used in 925 the current handshake. Based on the received HIT_SUITE_LIST, the 926 Initiator MAY decide to abort the current handshake and initiate a 927 new handshake based on a different mutually supported HIT suite. 928 This mechanism can, e.g., be used to move from an initial HIP DEX 929 handshake to a HIP BEX handshake for peers supporting both protocol 930 variants. 932 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 933 Responder's supported and preferred transport format types. The list 934 allows the Initiator and the Responder to agree on a common type for 935 payload protection. 937 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 938 wants to receive unmodified in the corresponding response packet in 939 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 940 or more ECHO_REQUEST_UNSIGNED parameters. 942 5.3.3. I2 - the Second HIP Initiator Packet 944 The HIP header values for the I2 packet: 946 Header: 947 Type = 3 948 SRC HIT = Initiator's HIT 949 DST HIT = Responder's HIT 951 IP ( HIP ( [R1_COUNTER,] 952 SOLUTION, 953 HIP_CIPHER, 954 ENCRYPTED_KEY, 955 HOST_ID, 956 TRANSPORT_FORMAT_LIST, 957 HIP_MAC, 958 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 960 Minimum size = 180 bytes 962 Valid control bits: A 964 The HITs used MUST match the ones used in the R1. 966 If the Initiator's HI is an anonymous one, the A control bit MUST be 967 set. 969 If present in the I1 packet, the Initiator MUST include an unmodified 970 copy of the R1_COUNTER parameter received in the corresponding R1 971 packet into the I2 packet. 973 The Solution contains the Random #I from R1 and the computed #J. The 974 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 976 The HIP_CIPHER contains the single encryption transform selected by 977 the Initiator, that it uses to encrypt the ENCRYPTED and 978 ENCRYPTED_KEY parameters. The chosen cipher MUST correspond to one 979 of the ciphers offered by the Responder in the R1. All 980 implementations MUST support the AES-CTR transform [RFC3686]. 982 The HOST_ID parameter contains the Initiator HI corresponding to the 983 Initiator HIT. 985 The ENCRYPTED_KEY contains an Initiator generated random value that 986 MUST be uniformly distributed. This random value is encrypted with 987 the Master Key SA using the HIP_CIPHER encryption algorithm. 989 The ECHO_RESPONSE_UNSIGNED contains the unmodified Opaque data copied 990 from the corresponding echo request parameter(s). This parameter can 991 also be used for two-factor password authentication as shown in 992 Appendix B. 994 The TRANSPORT_FORMAT_LIST contains the single transport format type 995 selected by the Initiator. The chosen type MUST correspond to one of 996 the types offered by the Responder in the R1. Currently, the only 997 transport format defined is the ESP transport format [rfc5202-bis]. 999 The MAC is calculated over the whole HIP envelope, excluding any 1000 parameters after the HIP_MAC, as described in Section 6.1. The 1001 Responder MUST validate the HIP_MAC. 1003 5.3.4. R2 - the Second HIP Responder Packet 1005 The HIP header values for the R2 packet: 1007 Header: 1008 Packet Type = 4 1009 SRC HIT = Responder's HIT 1010 DST HIT = Initiator's HIT 1012 IP ( HIP ( DH_GROUP_LIST, 1013 HIP_CIPHER, 1014 ENCRYPTED_KEY, 1015 HIT_SUITE_LIST, 1016 TRANSPORT_FORMAT_LIST, 1017 HIP_MAC) 1019 Minimum size = 108 bytes 1021 Valid control bits: none 1023 The HITs used MUST match the ones used in the I2. 1025 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1026 and TRANSPORT_FORMAT_LIST parameters in R2. These parameters MUST be 1027 the same as included in R1. The parameter are re-included here 1028 because R2 is MACed and thus cannot be altered by an attacker. For 1029 verification purposes, the Initiator re-evaluates the selected suites 1030 and compares the results against the chosen ones. If the re- 1031 evaluated suites do not match the chosen ones, the Initiator acts 1032 based on its local policy. 1034 The ENCRYPTED_KEY contains an Responder generated random value that 1035 MUST be uniformly distributed. This random value is encrypted with 1036 the Master Key SA using the HIP_CIPHER encryption algorithm. 1038 The MAC is calculated over the whole HIP envelope, excluding any 1039 parameters after the HIP_MAC, as described in Section 6.1. The 1040 Initiator MUST validate the HIP_MAC. 1042 5.4. ICMP Messages 1044 When a HIP implementation detects a problem with an incoming packet, 1045 and it either cannot determine the identity of the sender of the 1046 packet or does not have any existing HIP association with the sender 1047 of the packet, it MAY respond with an ICMP packet. Any such reply 1048 MUST be rate-limited as described in [RFC4443]. In most cases, the 1049 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1050 ICMPv6), with the Pointer field pointing to the field that caused the 1051 ICMP message to be generated. The problem cases specified in 1052 Section 5.4. of [rfc5201-bis] also apply to HIP DEX. 1054 6. Packet Processing 1056 Due to the adopted protocol semantics and the inherited general 1057 packet structure, packet processing in HIP DEX only differs from HIP 1058 BEX in very few places. Here, we focus on these differences and 1059 refer to Section 6 in [rfc5201-bis] otherwise. 1061 The processing of outgoing and incoming application data remains the 1062 same as in HIP BEX (see Sections 6.1 and 6.2 in [rfc5201-bis]). 1064 Puzzle solving and verification is very similar to HIP BEX with the 1065 exception that RHASH is replaced with CMAC in HIP DEX. Furthermore, 1066 R1 packets are not pre-computed in HIP DEX. The remaining procedure 1067 in Section 6.3 of [rfc5201-bis] is unchanged. 1069 6.1. HIP_MAC Calculation and Verification 1071 The following subsections define the actions for processing the 1072 HIP_MAC parameter. 1074 6.1.1. CMAC Calculation 1076 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1077 cryptographic function. The scope of the calculation for HIP_MAC is: 1079 CMAC: { HIP header | [ Parameters ] } 1081 where Parameters include all HIP parameters of the packet that is 1082 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1083 value - 1) and exclude parameters with Type values greater or equal 1084 to HIP_MAC's Type value. 1086 During HIP_MAC calculation, the following applies: 1088 o In the HIP header, the Checksum field is set to zero. 1090 o In the HIP header, the Header Length field value is calculated to 1091 the beginning of the HIP_MAC parameter. 1093 Parameter order is described in [rfc5201-bis]. 1095 The CMAC calculation and verification process is as follows: 1097 Packet sender: 1099 1. Create the HIP packet, without the HIP_MAC or any other parameter 1100 with greater Type value than the HIP_MAC parameter has. 1102 2. Calculate the Header Length field in the HIP header. 1104 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1105 retrieved from KEYMAT as defined in Section 6.2. 1107 4. Add the HIP_MAC parameter to the packet and any parameter with 1108 greater Type value than the HIP_MAC's that may follow. 1110 5. Recalculate the Length field in the HIP header. 1112 Packet receiver: 1114 1. Verify the HIP header Length field. 1116 2. Remove the HIP_MAC parameter, as well as all other parameters 1117 that follow it with greater Type value, saving the contents if 1118 they will be needed later. 1120 3. Recalculate the HIP packet length in the HIP header and clear the 1121 Checksum field (set it to all zeros). 1123 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1124 defined in Section 6.2 and verify it against the received CMAC. 1126 5. Set Checksum and Header Length fields in the HIP header to 1127 original values. 1129 6.2. HIP DEX KEYMAT Generation 1131 The HIP DEX KEYMAT process is used to derive the keys for Master Key 1132 SA as well as for the Pair-wise Key SA. The keys for the Master Key 1133 SA are based from the Diffie-Hellman derived key, Kij, produced 1134 during the HIP Diet EXchange. The Initiator generates Kij during the 1135 creation of the I2 packet and the Responder generates Kij once it 1136 receives the I2 packet. Hence, I2, R2, UPDATE, CLOSE, and CLOSE_ACK 1137 packets can contain authenticated and/or encrypted information. 1139 The keys of the Pair-wise Key SA are not directly used in the HIP DEX 1140 handshake. Instead, these keys are made available as payload 1141 protection keys. Some payload protection mechanisms have their own 1142 Key Derivation Function, and if so this mechanism SHOULD be used. 1143 Otherwise, the HIP DEX KEYMAT process MUST be used. 1145 The HIP DEX KEYMAT process consists of two components, CKDF-Extract 1146 and CKDF-Expand. The Extract function COMPRESSES a non-uniformly 1147 distributed key, as is the output of a Diffie-Hellman key derivation, 1148 to EXTRACT the key entropy into a fixed length output. The Expand 1149 function takes either the output of the Extract function or directly 1150 uses a uniformly distributed key and EXPANDS the length of the key, 1151 repeatedly distributing the key entropy, to produce the keys needed. 1153 The key derivation for Master Key SA employs both the Extract and 1154 Expand phases, while the Pair-wise Key SA MAY need the Extract and 1155 Expand phases if the key is longer than 128 bits. Otherwise, it only 1156 needs the Expand phase. 1158 The CKDF-Extract function is the following operation, where | denotes 1159 the concatenation. 1161 CKDF-Extract(I, BigK, info) -> PRK 1163 where 1165 I I from the PUZZLE parameter 1166 BigK Diffie-Hellman derived key or concatenation of the 1167 keying material exchanged in the ENCRYPTED_KEY 1168 parameters in the same order as the HITs for the info 1169 input (i.e., if HIT-I < HIT-R, then the keying 1170 material of the Initiator precedes the keying 1171 material of the Responder) 1172 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1173 PRK a pseudorandom key (of RHASH_len/8 octets) 1174 | denotes the concatenation 1176 The pseudorandom key PRK is calculated as follows: 1178 PRK = CMAC(I, BigK | info) 1180 The CKDF-Expand function is the following operation: 1182 CKDF-Expand(PRK, info, L) -> OKM 1184 PRK a pseudorandom key of at least RHASH_len/8 octets 1185 (usually, the output from the extract step or 1186 concatenation of the keying material exchanged 1187 in the ENCRYPTED_KEY parameters in the same order 1188 as the HITs for the info input, i.e., if 1189 HIT-I < HIT-R, then the keying material of the 1190 Initiator precedes the keying material of the 1191 Responder) 1192 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1193 L length of output keying material in octets 1194 (<= 255*RHASH_len/8) 1195 | denotes the concatenation 1197 The output keying material OKM is calculated as follows: 1199 N = ceil(L/RHASH_len/8) 1200 T = T(1) | T(2) | T(3) | ... | T(N) 1201 OKM = first L octets of T 1203 where 1205 T(0) = empty string (zero length) 1206 T(1) = CMAC(PRK, T(0) | info | 0x01) 1207 T(2) = CMAC(PRK, T(1) | info | 0x02) 1208 T(3) = CMAC(PRK, T(2) | info | 0x03) 1209 ... 1211 (where the constant concatenated to the end of each T(n) is a 1212 single octet.) 1214 sort(HIT-I | HIT-R) is defined as the network byte order 1215 concatenation of the two HITs, with the smaller HIT preceding the 1216 larger HIT, resulting from the numeric comparison of the two HITs 1217 interpreted as positive (unsigned) 128-bit integers in network byte 1218 order. 1220 The initial keys are drawn sequentially in the order that is 1221 determined by the numeric comparison of the two HITs, with comparison 1222 method described in the previous paragraph. HOST_g denotes the host 1223 with the greater HIT value, and HOST_l the host with the lower HIT 1224 value. 1226 The drawing order for initial keys: 1228 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1229 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1231 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1233 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1235 The number of bits drawn for a given algorithm is the "natural" size 1236 of the keys. For the mandatory algorithms, the following sizes 1237 apply: 1239 AES 128 or 256 bits 1241 If other key sizes are used, they must be treated as different 1242 encryption algorithms and defined separately. 1244 6.3. Initiation of a HIP Diet EXchange 1246 The initiation of a HIP DEX handshake proceeds as described in 1247 Section 6.6. of [rfc5201-bis]. 1249 6.4. Processing Incoming I1 Packets 1251 I1 packets in HIP DEX are handled identically to HIP BEX (see 1252 Section 6.7. in [rfc5201-bis]). The only differences are that the 1253 Responder SHOULD select a DEX HIT in the R1 response. Moreover, as 1254 R1 packets are neither covered by a signature nor incur the overhead 1255 of generating an ephemeral Diffie-Hellman key-pair, pre-computation 1256 of an R1 is only marginally beneficial, but would incur additional 1257 memory resources. Hence, the R1 pre-computation is omitted in HIP 1258 DEX. 1260 6.5. Processing Incoming R1 Packets 1262 R1 packets in HIP DEX are handled identically to HIP BEX with the 1263 following differences (see Section 6.8. in [rfc5201-bis]). Only step 1264 4 is omitted in HIP DEX as there is no HIP_SIGNATURE in the R1 1265 packet. 1267 6.6. Processing Incoming I2 Packets 1269 Upon receipt of an I2 packet, the system MAY perform initial checks 1270 to determine whether the I2 packet corresponds to a recent R1 packet 1271 that has been sent out, if the Responder keeps such state. For 1272 example, the sender could check whether the I2 packet is from an 1273 address or HIT for which the Responder has recently received an I1. 1274 To this end, the R1 packet may have had Opaque data included that was 1275 echoed back in the I2 packet. If the I2 packet is considered to be 1276 suspect, it MAY be silently discarded by the system. 1278 Otherwise, the HIP implementation SHOULD process the I2 packet. This 1279 includes validation of the puzzle solution, generating the Diffie- 1280 Hellman key, verifying the MAC, extracting the ENCRYPTED_KEY, 1281 creating state, and finally sending an R2 packet. 1283 The following steps define the conceptual processing rules for 1284 responding to an I2 packet: 1286 1. The system MAY perform checks to verify that the I2 packet 1287 corresponds to a recently sent R1 packet. Such checks are 1288 implementation dependent. See Appendix A in [rfc5201-bis] for a 1289 description of an example implementation. 1291 2. The system MUST check that the Responder's HIT corresponds to 1292 one of its own HITs and MUST drop the packet otherwise. 1294 3. The system MUST further check that the Initiator's HIT Suite is 1295 supported. The Responder SHOULD silently drop I2 packets with 1296 unsupported Initiator HITs. 1298 4. If the system's state machine is in the R2-SENT state, the 1299 system MUST check if the newly received I2 packet is similar to 1300 the one that triggered moving to R2-SENT. If so, it MUST 1301 retransmit a previously sent R2 packet and the state machine 1302 stays in R2-SENT. 1304 5. If the system's state machine is in the I2-SENT state, the 1305 system MUST make a comparison between its local and sender's 1306 HITs (similarly as in Section 6.2). If the local HIT is smaller 1307 than the sender's HIT, it should drop the I2 packet, use the 1308 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1309 #I from the R1 packet received earlier, and get the local 1310 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1311 from the I2 packet sent to the peer earlier. Otherwise, the 1312 system should process the received I2 packet and drop any 1313 previously derived Diffie-Hellman keying material Kij and 1314 ENCRYPTED_KEY keying material it might have generated upon 1315 sending the I2 packet previously. The peer Diffie-Hellman key, 1316 ENCRYPTED_KEY, and the nonce #J are taken from the just arrived 1317 I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying 1318 material, and the nonce I are the ones that were sent earlier in 1319 the R1 packet. 1321 6. If the system's state machine is in the I1-SENT state, and the 1322 HITs in the I2 packet match those used in the previously sent I1 1323 packet, the system uses this received I2 packet as the basis for 1324 the HIP association it was trying to form, and stops 1325 retransmitting I1 packets (provided that the I2 packet passes 1326 the additional checks below). 1328 7. If the system's state machine is in any other state than R2- 1329 SENT, the system SHOULD check that the echoed R1 generation 1330 counter in the I2 packet is within the acceptable range if the 1331 counter is included. Implementations MUST accept puzzles from 1332 the current generation and MAY accept puzzles from earlier 1333 generations. If the generation counter in the newly received I2 1334 packet is outside the accepted range, the I2 packet is stale 1335 (and perhaps replayed) and SHOULD be dropped. 1337 8. The system MUST validate the solution to the puzzle as described 1338 in Section 6. 1340 9. The I2 packet MUST have a single value in the HIP_CIPHER 1341 parameter, which MUST match one of the values offered to the 1342 Initiator in the R1 packet. 1344 10. The system must derive Diffie-Hellman keying material Kij based 1345 on the public value and Group ID in the HOST_ID parameter. This 1346 key is used to derive the keys of the Master Key SA as described 1347 in Section 6.2. If the Diffie-Hellman Group ID is unsupported, 1348 the I2 packet is silently dropped. 1350 11. The implementation SHOULD also verify that the Initiator's HIT 1351 in the I2 packet corresponds to the Host Identity sent in the I2 1352 packet. (Note: some middleboxes may not able to make this 1353 verification.) 1355 12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1356 Other documents specifying transport formats (e.g. 1357 [rfc5202-bis]) contain specifications for handling any specific 1358 transport selected. 1360 13. The system MUST verify the HIP_MAC according to the procedures 1361 in Section 5.2.12. 1363 14. If the checks above are valid, then the system proceeds with 1364 further I2 processing; otherwise, it discards the I2 and its 1365 state machine remains in the same state. 1367 15. The I2 packet may have the A bit set -- in this case, the system 1368 MAY choose to refuse it by dropping the I2 and the state machine 1369 returns to state UNASSOCIATED. If the A bit is set, the 1370 Initiator's HIT is anonymous and should not be stored 1371 permanently. 1373 16. The system MUST extract the keying material from the 1374 ENCRYPTED_KEY parameter. This keying material is a partial 1375 input to the key derivation process for the Pair-wise Key SA 1376 (see Section 6.2). 1378 17. The system initializes the remaining variables in the associated 1379 state, including Update ID counters. 1381 18. Upon successful processing of an I2 message when the system's 1382 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 1383 SENT, an R2 packet is sent and the system's state machine 1384 transitions to state R2-SENT. 1386 19. Upon successful processing of an I2 packet when the system's 1387 state machine is in state ESTABLISHED, the old HIP association 1388 is dropped and a new one is installed, an R2 packet is sent, and 1389 the system's state machine transitions to R2-SENT. 1391 20. Upon the system's state machine transitioning to R2-SENT, the 1392 system starts a timer. The state machine transitions to 1393 ESTABLISHED if some data has been received on the incoming HIP 1394 association, or an UPDATE packet has been received (or some 1395 other packet that indicates that the peer system's state machine 1396 has moved to ESTABLISHED). If the timer expires (allowing for 1397 maximal amount of retransmissions of I2 packets), the state 1398 machine transitions to ESTABLISHED. 1400 6.7. Processing Incoming R2 Packets 1402 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1403 results in the R2 packet being dropped and the state machine staying 1404 in the same state. If an R2 packet is received in state I2-SENT, it 1405 MUST be processed. 1407 The following steps define the conceptual processing rules for an 1408 incoming R2 packet: 1410 1. If the system is in any other state than I2-SENT, the R2 packet 1411 is silently dropped. 1413 2. The system MUST verify that the HITs in use correspond to the 1414 HITs that were received in the R1 packet that caused the 1415 transition to the I1-SENT state. 1417 3. The system MUST verify the HIP_MAC according to the procedures in 1418 Section 6.1. 1420 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1421 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1422 and compare the results against the chosen suites. 1424 5. If any of the checks above fail, there is a high probability of 1425 an ongoing man-in-the-middle or other security attack. The 1426 system SHOULD act accordingly, based on its local policy. 1428 6. The system MUST extract the keying material from the 1429 ENCRYPTED_KEY parameter. This keying material is a partial input 1430 to the key derivation process for the Pair-wise Key SA (see 1431 Section 6.2). 1433 7. Upon successful processing of the R2 packet, the state machine 1434 transitions to state ESTABLISHED. 1436 6.8. Processing UPDATE, NOTIFY, CLOSE, and CLOSE_ACK Packets 1438 UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are handled similarly in 1439 HIP DEX as in HIP BEX (see Sections 6.11. - 6.15. in [rfc5201-bis]). 1440 The only difference is the that the HIP_SIGNATURE is never present 1441 and, therefore, is not needed be processed. 1443 6.9. Handling State Loss 1445 Implementors MAY choose to use non-volatile, secure storage for HIP 1446 states in order for them to survive a system reboot. If no secure 1447 storage capabilities are available, the system SHOULD delete the 1448 corresponding HIP state, including the keying material. If the 1449 implementation does drop the state (as RECOMMENDED), it MUST also 1450 drop the peer's R1 generation counter value, unless a local policy 1451 explicitly defines that the value of that particular host is stored. 1452 An implementation MUST NOT store a peer's R1 generation counters by 1453 default, but storing R1 generation counter values, if done, MUST be 1454 configured by explicit HITs. 1456 7. HIP Policies 1458 There are a number of variables that will influence the HIP exchanges 1459 that each host must support. All HIP DEX implementations SHOULD 1460 provide for an ACL of Initiator's HI to Responder's HI. This ACL 1461 SHOULD also include preferred transform and local lifetimes. 1462 Wildcards SHOULD also be supported for this ACL. 1464 The value of the puzzle difficulty #K used in the HIP R1 must be 1465 chosen with care. Too high numbers of #K will exclude clients with 1466 weak CPUs because these devices cannot solve the puzzle within 1467 reasonable time. #K should only be raised if a Responder is under 1468 high load, i.e., it cannot process all incoming HIP handshakes any 1469 more. If a responder is not under high load, K SHOULD be 0. 1471 8. Security Considerations 1473 HIP DEX replaces the SIGMA-based authenticated Diffie-Hellman key 1474 exchange of HIP BEX with a exchange of random keying material that is 1475 encrypted by a Diffie-Hellman derived key. Both the Initiator and 1476 Responder contribute to this keying material. 1478 o The strength of the keys for the Pair-wise Key SA is based on the 1479 quality of the random keying material generated by the Initiator 1480 and Responder. Since the Initiator is commonly a sensor there is 1481 a natural concern about the quality of its random number 1482 generator. 1484 o DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1485 compromised, ALL HIP connections protected with that HI are 1486 compromised. 1488 o The puzzle mechanism using CMAC may need further study that it 1489 does present the desired level of difficulty. 1491 o The DEX HIT generation MAY present new attack opportunities; 1492 further study is needed. 1494 The R1 packet is unprotected and offers an attacker new resource 1495 attacks against the Initiator. This is mitigated by only processing 1496 a received R1 when the Initiator has previously sent a corresponding 1497 I1. 1499 9. IANA Considerations 1501 HIP DEX introduces the following new HIP HIT suite: 1503 +-------+-------------+----------------------+----------------------+ 1504 | Index | Hash | Signature algorithm | Description | 1505 | | function | family | | 1506 +-------+-------------+----------------------+----------------------+ 1507 | 5 | FOLD | ECDH | ECDH HI folded to 96 | 1508 | | | | bits | 1509 +-------+-------------+----------------------+----------------------+ 1511 Table 2: HIT Suites 1513 In addition, this document specified a new HIP Parameter Type defined 1514 in Section 5.2.5. 1516 Moreover, a new HIP Cipher ID is defined in Section 5.2.4. 1518 10. Acknowledgments 1520 The drive to put HIP on a cryptographic 'Diet' came out of a number 1521 of discussions with sensor vendors at IEEE 802.15 meetings. David 1522 McGrew was very helpful in crafting this document. 1524 11. Changelog 1526 This section summarizes the changes made from draft-moskowitz-hip-rg- 1527 dex-05, which was the first stable version of the draft. Note that 1528 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 1530 11.1. Changes in draft-moskowitz-hip-rg-dex-06 1532 o A major change in the ENCRYPT parameter to use AES-CTR rather than 1533 AES-CBC. 1535 11.2. Changes in draft-moskowitz-hip-dex-00 1537 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 1538 submission. 1540 o Added the change section. 1542 o Added a Definitions section. 1544 o Changed I2 and R2 packets to reflect use of AES-CTR for 1545 ENCRYPTED_KEY parameter. 1547 o Cleaned up KEYMAT Generation text. 1549 o Added Appendix with C code for the ECDH shared secret generation 1550 on an 8 bit processor. 1552 11.3. Changes in draft-moskowitz-hip-dex-01 1554 o Numerous editorial changes. 1556 o New retransmission strategy. 1558 o New HIT generation mechanism. 1560 o Modified layout of ENCRYPTED_KEY parameter. 1562 o Clarify to use puzzle difficulty of zero under normal network 1563 conditions. 1565 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 1566 MUST). 1568 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 1569 and I2). 1571 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 1572 echoed in R2 packet. 1574 o Added new author. 1576 12. References 1578 12.1. Normative References 1580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1581 Requirement Levels", BCP 14, RFC 2119, March 1997. 1583 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1584 Its Use With IPsec", RFC 2410, November 1998. 1586 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1587 Counter Mode With IPsec Encapsulating Security Payload 1588 (ESP)", RFC 3686, January 2004. 1590 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1591 Message Protocol (ICMPv6) for the Internet Protocol 1592 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1594 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 1595 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 1596 2010. 1598 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1599 Curve Cryptography Algorithms", RFC 6090, February 2011. 1601 [rfc4843-bis] 1602 Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 1603 Routable Cryptographic Hash Identifiers (ORCHID)", draft- 1604 ietf-hip-rfc4843-bis-01 (work in progress), March 2011. 1606 [rfc5201-bis] 1607 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 1608 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 1609 hip-rfc5201-bis-09 (work in progress), July 2012. 1611 [rfc5202-bis] 1612 Jokela, P., Moskowitz, R., Nikander, P., and J. Melen, 1613 "Using the Encapsulating Security Payload (ESP) Transport 1614 Format with the Host Identity Protocol (HIP)", draft-ietf- 1615 hip-rfc5202-bis-00 (work in progress), September 2010. 1617 12.2. Informative References 1619 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 1620 Algorithmic Complexity Attacks", in Proceedings of Usenix 1621 Security Symposium 2003, Washington, DC., August 2003. 1623 [IEEE.802-11.2007] 1624 "Information technology - Telecommunications and 1625 information exchange between systems - Local and 1626 metropolitan area networks - Specific requirements - Part 1627 11: Wireless LAN Medium Access Control (MAC) and Physical 1628 Layer (PHY) Specifications", IEEE Standard 802.11, June 1629 2007, . 1632 [IEEE.802-15-4.2011] 1633 "Information technology - Telecommunications and 1634 information exchange between systems - Local and 1635 metropolitan area networks - Specific requirements - Part 1636 15.4: Wireless Medium Access Control (MAC) and Physical 1637 Layer (PHY) Specifications for Low-Rate Wireless Personal 1638 Area Networks (WPANs)", IEEE Standard 802.15.4, September 1639 2011, . 1642 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1643 4306, December 2005. 1645 [hummen2013tailoring] 1646 Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 1647 Wehrle, "Tailoring End-to-End IP Security Protocols to the 1648 Internet of Things", in Proceedings of IEEE International 1649 Conference on Network Protocols (ICNP 2013), October 2013. 1651 [rfc4423-bis] 1652 Moskowitz, R., "Host Identity Protocol Architecture", 1653 draft-ietf-hip-rfc4423-bis-04 (work in progress), July 1654 2012. 1656 Appendix A. C code for ECDH point multiplication on an 8 bit processor 1657 The following code illustrates the process to generate the shared 1658 secret key from ECDH exchange. 1660 // The following code is taken from the 1661 // Relic library (http://code.google.com/p/relic-toolkit/) 1662 // This code includes the function for point multiplication over 1663 // prime fields 1665 /** 1666 * The following function multiplies a prime elliptic point by an 1667 * integer using the binary method. 1668 * 1669 * @param[out] r - the result. 1670 * @param[in] p - the point to multiply. 1671 * @param[in] k - the integer. 1672 */ 1674 /** 1675 * ep_t is library specific representation for an elliptic curve 1676 * point 1677 * bn_t is library specific representation for a multiple precision 1678 * integer structure 1679 */ 1681 void ep_mul_basic(ep_t r, ep_t p, bn_t k) { 1682 int i, l; 1683 ep_t t; 1685 ep_null(t); 1687 if (bn_is_zero(k)) { 1688 //If k is 0 then assign the prime elliptic curve point to a point 1689 // at the infinity 1690 ep_set_infty(r); 1691 return; 1692 } 1694 TRY { 1695 //ep_new allocates memory for the point and may throw ERR_NO_MEMORY 1696 // incase of insufficient memory 1697 ep_new(t); 1698 //bn_bits returns the number of bits of a multiple precision 1699 // integer l = bn_bits(k); 1700 //bn_test_bit returns 0 if the bit at the given location is 0 and 1701 // returns non zero otherwise 1702 if (bn_test_bit(k, l - 1)) { 1703 ep_copy(t, p); 1704 } else { 1705 ep_set_infty(t); 1706 } 1708 for (i = l - 2; i >= 0; i--) { 1709 //ep_dbl doubles a prime elliptic curve point 1710 ep_dbl(t, t); 1711 if (bn_test_bit(k, i)) { 1712 //ep_add adds two prime elliptic curve points 1713 ep_add(t, t, p); 1714 } 1715 } 1717 ep_copy(r, t); 1718 //ep_norm converts a point to affine coordinates 1719 ep_norm(r, r); 1720 } 1721 CATCH_ANY { 1722 THROW(ERR_CAUGHT); 1723 } 1724 FINALLY { 1725 ep_free(t); 1726 } 1727 } 1729 Appendix B. Password-based two-factor authentication during the HIP DEX 1730 handshake 1732 HIP DEX allows to identify authorized connections based on a two- 1733 factor authentication mechanism. With two-factor authentication, 1734 devices that are authorized to communicate with each other are 1735 required to be pre-provisioned with a shared (group) key. The 1736 Initiator uses this pre-provisioned key to encrypt the 1737 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 1738 the Responder verifies that its challenge in the 1739 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 1740 with the correct key. If verified successfully, the Responder 1741 proceeds with the handshake. Otherwise, it silently drops the I2 1742 packet. 1744 Note that there is no explicit signaling in the HIP DEX handshake for 1745 this behavior. Thus, knowledge of two-factor authentication must be 1746 configured externally prior to the handshake. 1748 Authors' Addresses 1749 Robert Moskowitz (editor) 1750 Verizon 1751 1000 Bent Creek Blvd, Suite 200 1752 Mechanicsburg, PA 1753 USA 1755 EMail: robert.moskowitz@verizon.com 1757 Rene Hummen 1758 Chair of Communication and Distributed Systems, RWTH Aachen 1759 Ahornstrasse 55 1760 Aachen 52074 1761 Germany 1763 EMail: hummen@comsys.rwth-aachen.de 1764 URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/