idnits 2.17.1 draft-moskowitz-hip-dex-00.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 == 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 (August 14, 2012) is 4272 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: 'RFC2410' is mentioned on line 661, but not defined == Unused Reference: 'RFC2460' is defined on line 1498, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 1512, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'RFC6090' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'AUR03' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft Verizon 4 Intended status: Standards Track August 14, 2012 5 Expires: February 15, 2013 7 HIP Diet EXchange (DEX) 8 draft-moskowitz-hip-dex-00 10 Abstract 12 This document specifies the details of the Host Identity Protocol 13 Diet EXchange (HIP DEX). HIP DEX is a variant of the HIP Base 14 EXchange (HIP BEX) [rfc5201-bis] specifically designed to use as few 15 crypto primitives as possible yet still deliver the same class of 16 security features as HIP BEX. 18 The design goal of HIP DEX is to be usable by sensor devices that are 19 memory and processor constrained. Like HIP BEX it is expected to be 20 used together with another suitable security protocol, such as the 21 Encapsulated Security Payload (ESP). HIP DEX can also be used 22 directly as a keying mechanism for a MAC layer security protocol as 23 is supported by IEEE 802.15.4 [IEEE.802-15-4.2011]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 15, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4 73 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 75 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 6 76 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. The DEX Host Identifier Tag (HIT) and Its Representations . . 6 79 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 7 80 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 7 81 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 82 4.1. Creating a HIP Association . . . . . . . . . . . . . . . . 7 83 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . . 9 84 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 9 85 4.1.3. HIP State Machine . . . . . . . . . . . . . . . . . . 10 86 4.1.4. HIP DEX Security Associations . . . . . . . . . . . . 14 87 4.1.5. User Data Considerations . . . . . . . . . . . . . . . 14 88 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 89 5.1. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 15 90 5.1.1. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . . 15 91 5.1.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . 16 92 5.1.3. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 16 93 5.1.4. HIP_MAC_3 . . . . . . . . . . . . . . . . . . . . . . 18 94 5.2. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 18 95 5.2.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 19 96 5.2.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 20 97 5.2.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 21 98 5.2.4. R2 - the Second HIP Responder Packet . . . . . . . . . 22 99 5.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 23 100 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 23 101 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 24 102 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . . 25 103 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . . 25 104 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 26 105 6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . . 29 106 6.4.1. R1 Management . . . . . . . . . . . . . . . . . . . . 29 107 6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . . 29 108 6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . . 30 109 6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . . 31 110 6.8. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 31 111 6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 31 112 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 115 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 116 11. Changes from draft-moskowitz-hip-rg-dex-05 . . . . . . . . . . 33 117 11.1. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . . 33 118 11.2. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . . 33 119 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 120 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 121 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 122 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 36 123 Appendix B. Generating a Public Key Encoding from an HI . . . . . 37 124 Appendix C. C code for ECDH point multiplication on an 8 bit 125 processor . . . . . . . . . . . . . . . . . . . . . . 37 127 1. Introduction 129 This memo specifies the details of the Host Identity Protocol Diet 130 EXchange (HIP DEX). HIP DEX uses the smallest possible set of 131 established cryptographic primitives, in such a manner that does not 132 change our understanding of their behaviour, yet in a different 133 formulation to achieve assertions normally met with different 134 primitives. 136 HIP DEX builds on the HIP Base EXchange (HIP BEX) [rfc5201-bis], and 137 only the differences between BEX and DEX are documented here. 139 There are a few key differences between BEX and DEX. 141 Minimum collection of cryptographic primitives. 143 Static Elliptic Curve Diffie-Hellman key pairs used to encrypt 144 the session key. 146 AES-CTR for symmetric encryption and AES-CMAC for MACing 147 functions. 149 A simple truncation function for HIT generation. 151 Forfeit of Perfect Forward Secrecy with the dropping of ephemeral 152 Diffie-Hellman. 154 Forfeit of digital signatures with the removal of a hash function. 155 Reliance of ECDH derived key used in HIP_MAC to prove ownership of 156 the private key. 158 Provide a Password Authentication within the exchange. This may 159 be supported by BEX as well, but not defined there. 161 Diffie-Hellman derived key ONLY used to protect the HIP packets. 162 A separate secret exchange within the HIP packets create the 163 session key(s). 165 Operate in an aggressive retransmission manner to deal with the 166 high packet loss nature of sensor networks. 168 1.1. The HIP Diet EXchange (DEX) 170 The HIP diet exchange is a two-party cryptographic protocol used to 171 establish communications context between hosts. The first party is 172 called the Initiator and the second party the Responder. The four- 173 packet design helps to make HIP DoS resilient. The protocol 174 exchanges Static Elliptic Curve Diffie-Hellman keys in the 2nd and 175 3rd packets, transmits session secrets in and authenticates the 176 parties in the 3rd and 4th packets. Additionally, the Responder 177 starts a puzzle exchange in the 2nd packet, with the Initiator 178 completing it in the 3rd packet before the Responder stores any state 179 from the exchange. 181 Thus DEX is operationally similar to BEX. The model is fairly 182 equivalent to 802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise 183 Transient Key, but handled in a single exchange. 185 HIP DEX does not have the option of encrypting the Host Identity of 186 the Initiator in the 3rd packet. The Responder's Host Identity is 187 also not protected. Thus there is no attempt at anonymity as in BEX. 189 Data packets start to flow after the 4th packet. Simiarly to HIP 190 BEX, DEX does not have an explicit transition to connected state for 191 the Responder. 193 When the Responder starts receiving protected datagrams, indicating 194 that the Initiator received the R2 packet, it shifts to connected 195 state. As such the Intitator should take care to NOT send the first 196 data packet until some delta time after it received the R2 packet. 197 This is to provide time for the Responder to process any aggressively 198 retransmitted I2 packets. 200 An existing HIP association can be updated using the update mechanism 201 defined in this document, and when the association is no longer 202 needed, it can be closed using the defined closing mechanism. 204 Finally, HIP is designed as an end-to-end authentication and key 205 establishment protocol, it can be used with Encapsulated Security 206 Payload (ESP) [rfc5202-bis] and other end-to-end security protocols. 207 The base protocol does not cover all the fine-grained policy control 208 found in Internet Key Exchange (IKE) [RFC4306] that allows IKE to 209 support complex gateway policies. Thus, HIP is not a replacement for 210 IKE. 212 1.2. Memo Structure 214 The rest of this memo is structured as follows. Section 2 defines 215 the central keywords, notation, and terms used throughout the rest of 216 the document. Section 4 gives an overview of the HIP base exchange 217 protocol. Section 6 define the rules for packet processing. 218 Finally, Sections 7, 8, and 9 discuss policy, security, and IANA 219 considerations, respectively. 221 2. Terms and Definitions 223 2.1. Requirements Terminology 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in RFC 2119 [RFC2119]. 229 2.2. Notation 231 [x] indicates that x is optional. 233 {x} indicates that x is encrypted. 235 X(y) indicates that y is a parameter of X. 237 i indicates that x exists i times. 239 --> signifies "Initiator to Responder" communication (requests). 241 <-- signifies "Responder to Initiator" communication (replies). 243 | signifies concatenation of information-- e.g., X | Y is the 244 concatenation of X with Y. 246 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 247 the mac function M on the input x. 249 2.3. Definitions 251 HIP Diet Exchange (DEX): the ECDH based handshake for establishing a 252 new HIP association. 254 CKDF: CMAC based Key Derivation Function. 256 3. The DEX Host Identifier Tag (HIT) and Its Representations 258 The DEX Host Identity Tag (HIT) is distinguished in two ways from the 259 BEX HIT: 261 The HIT SUITE ID Section 5.1.2 is ONLY a DEX ID. 263 The HIT DEX HIT is not generated via a cryptographic hash. Rather 264 it is a truncation of the Elliptic Curve Host Identity. 266 3.1. Host Identity Tag (HIT) 268 The DEX Host Identity Tag is a 128-bit value -- a truncation of the 269 Host Identifier appended with a prefix. There are two advantages of 270 using a Host Identity Tag over the actual Host Identity public key in 271 protocols. Firstly, its fixed length makes for easier protocol 272 coding and also better manages the packet size cost of this 273 technology. Secondly, it presents a consistent format to the 274 protocol whatever underlying identity technology is used. 276 BEX uses RFC 4843-bis [rfc4843-bis] specified 128-bit hash-based 277 identifiers, called Overlay Routable Cryptographic Hash Identifiers 278 (ORCHIDs). Their prefix, allocated from the IPv6 address block, is 279 defined in [rfc4843-bis]. 281 In DEX, a cryptographic hash is NOT used to form the HIT. Rather the 282 HI is truncated to 96 bits. 284 3.2. Generating a HIT from an HI 286 The DEX HIT is not an ORCHID, as there is no hash function in DEX. 287 Since a HI that is an ECDH key is directly computed from a random 288 number it is already collision resistant. The DEX HIT is the left- 289 truncated 96 bits of the HI. This 96 bit value is used in place of 290 the hash in the ORCHID. The HIT suite (see Section 9) is used for 291 the four bits of the Orchid Generation Algorithm (OGA) field in the 292 ORCHID. The same IPv6 prefix used in BEX is used for DEX. 294 4. Protocol Overview 296 The following material is an overview of the differences between the 297 BEX and DEX implementations of the HIP protocol. It is expected that 298 [rfc5201-bis] is well understood first. 300 4.1. Creating a HIP Association 302 By definition, the system initiating a HIP exchange is the Initiator, 303 and the peer is the Responder. This distinction is forgotten once 304 the base exchange completes, and either party can become the 305 Initiator in future communications. 307 The HIP Diet EXchange serves to manage the establishment of state 308 between an Initiator and a Responder. The first packet, I1, 309 initiates the exchange, and the last three packets, R1, I2, and R2, 310 constitute an authenticated secret key wrapped by a Diffie-Hellman 311 derived key for session key generation. The HIP association keys are 312 drawn from this keying material. If other cryptographic keys are 313 needed, e.g., to be used with ESP, they are expected to be drawn from 314 the same keying material. 316 The second packet, R1, starts the actual exchange. It contains a 317 puzzle -- a cryptographic challenge that the Initiator must solve 318 before continuing the exchange. The level of difficulty of the 319 puzzle can be adjusted based on level of trust with the Initiator, 320 current load, or other factors. The R1 also contains lists of 321 cryptographic algorithms supported by the Responder. Based on these 322 lists, the Initiator can continue, abort, or restart the base 323 exchange with a different selection of cryptographic algorithms. 325 In the I2 packet, the Initiator must display the solution to the 326 received puzzle. Without a correct solution, the I2 message is 327 discarded. The I2 also contains a key wrap parameter that carries 328 the key for the Responder. This key is only half the final session 329 key. The packet is authenticated by the sender (Initiator). 331 The R2 packet finalizes the base exchange. The R2 contains a key 332 wrap parameter that carries the rest of the key for the Initiator. 333 The packet is authenticated by the sender (Initiator). 335 The base exchange is illustrated below. The term "key" refers to the 336 Host Identity public key, "secret" refers to a random value encrypted 337 by a public key, and "sig" represents a signature using such a key. 338 The packets contain other parameters not shown in this figure. 340 Initiator Responder 342 I1: 343 --------------------------> 344 select precomputed R1 345 R1: puzzle, PK 346 <------------------------- 347 solve puzzle remain stateless 348 PK Encrypt x 349 I2: solution, PK, ECR(DH,secret x), mac 350 --------------------------> 351 check puzzle 352 check mac 353 PK Encrypt y 354 R2: PK, ECR(DH,secret y), mac 355 <-------------------------- 356 check mac 358 4.1.1. HIP Puzzle Mechanism 360 The purpose of the HIP puzzle mechanism is to protect the Responder 361 from a number of denial-of-service threats. It allows the Responder 362 to delay state creation until receiving I2. Furthermore, the puzzle 363 allows the Responder to use a fairly cheap calculation to check that 364 the Initiator is "sincere" in the sense that it has churned CPU 365 cycles in solving the puzzle. 367 DEX uses the CMAC function instead of a hash function as in BEX. 369 The puzzle mechanism has been explicitly designed to give space for 370 various implementation options. It allows a Responder implementation 371 to completely delay session-specific state creation until a valid I2 372 is received. In such a case, a correctly formatted I2 can be 373 rejected only once the Responder has checked its validity by 374 computing one CMAC function. On the other hand, the design also 375 allows a Responder implementation to keep state about received I1s, 376 and match the received I2s against the state, thereby allowing the 377 implementation to avoid the computational cost of the CMAC function. 378 The drawback of this latter approach is the requirement of creating 379 state. Finally, it also allows an implementation to use other 380 combinations of the space-saving and computation-saving mechanisms. 382 Generally speaking, the puzzle mechanism works in DEX the same as in 383 BEX. There are some implementation differences, using CMAC rather 384 than a hash. 386 See Appendix A for one possible implementation. Implementations 387 SHOULD include sufficient randomness to the algorithm so that 388 algorithmic complexity attacks become impossible [CRO03]. 390 4.1.2. Puzzle Exchange 392 The Responder starts the puzzle exchange when it receives an I1. The 393 Responder supplies a random number I, and requires the Initiator to 394 find a number J. To select a proper J, the Initiator must create the 395 concatenation of the HITs of the parties and J, and feed this 396 concatenation using I as the key into the CMAC algorithm. The lowest 397 order K bits of the result MUST be zeros. The value K sets the 398 difficulty of the puzzle. 400 To generate a proper number J, the Initiator will have to generate a 401 number of Js until one produces the CMAC target of zeros. The 402 Initiator SHOULD give up after exceeding the puzzle lifetime in the 403 PUZZLE parameter ([rfc5201-bis]). The Responder needs to re-create 404 the concatenation of the HITs and the provided J, and compute the 405 CMAC using I once to prove that the Initiator did its assigned task. 407 To prevent precomputation attacks, the Responder MUST select the 408 number I in such a way that the Initiator cannot guess it. 409 Furthermore, the construction MUST allow the Responder to verify that 410 the value was indeed selected by it and not by the Initiator. See 411 Appendix A for an example on how to implement this. 413 Using the Opaque data field in an ECHO_REQUEST_UNSIGNED parameter 414 ([rfc5201-bis]), the Responder can include some data in R1 that the 415 Initiator must copy unmodified in the corresponding I2 packet. The 416 Responder can generate the Opaque data in various ways; e.g., using 417 some secret, the sent I, and possibly other related data. Using the 418 same secret, the received I (from the I2), and the other related data 419 (if any), the Receiver can verify that it has itself sent the I to 420 the Initiator. The Responder MUST periodically change such a used 421 secret. 423 It is RECOMMENDED that the Responder generates a new puzzle and a new 424 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 425 Responder remembers an old puzzle at least 2*Lifetime seconds after 426 the puzzle has been deprecated. These time values allow a slower 427 Initiator to solve the puzzle while limiting the usability that an 428 old, solved puzzle has to an attacker. 430 4.1.3. HIP State Machine 432 The HIP protocol itself has little state. In HIP DEX, as in BEX, 433 there is an Initiator and a Responder. Once the security 434 associations (SAs) are established, this distinction is lost. If the 435 HIP state needs to be re-established, the controlling parameters are 436 which peer still has state and which has a datagram to send to its 437 peer. 439 The HIP DEX state machine has the same states as the BEX state 440 machine. However, there is an optional aggressive transmission 441 feature to provide better performance in sensor networks with high 442 packet loss. The following section documents the few differences in 443 the DEX state machine. 445 4.1.3.1. HIP Aggressive Transmission Mechanism 447 HIP DEX may be used on networks with high packet loss. DEX deals 448 with this by using an aggressive transmission practice for I1 and I2 449 packets. The Initiator SHOULD continually send I1 and I2 packets at 450 some short interval t msec, based on local policy. The transmission 451 stops on receipt of the corresponding R1 or R2 packet, which acts as 452 an acknowledgment receipt. 454 Since the Responder is stateless until it receives an I2, it does not 455 need any special behaviour on sending R1 other than to send one 456 whenever it receives an I1. The Responder sends an R2 after receipt 457 every I2. The Responder does need to know that R2 was received by 458 the Initiator. Like in BEX, the Responder can learn this when it 459 starts receiving datagrams. 461 4.1.3.2. HIP States 463 +---------------------+---------------------------------------------+ 464 | State | Explanation | 465 +---------------------+---------------------------------------------+ 466 | UNASSOCIATED | State machine start | 467 | | | 468 | I1-SENT | Initiating base exchange | 469 | | | 470 | I2-SENT | Waiting to complete base exchange | 471 | | | 472 | R2-SENT | Waiting to complete base exchange | 473 | | | 474 | ESTABLISHED | HIP association established | 475 | | | 476 | CLOSING | HIP association closing, no data can be | 477 | | sent | 478 | | | 479 | CLOSED | HIP association closed, no data can be sent | 480 | | | 481 | E-FAILED | HIP exchange failed | 482 +---------------------+---------------------------------------------+ 484 Table 1: HIP States 486 4.1.3.3. HIP State Processes 488 System behavior in state I1-SENT, Table 2. 490 +---------------------+-----------------------------+ 491 | Trigger | Action | 492 +---------------------+-----------------------------+ 493 | t msec | Send I1 and stay at I1-SENT | 494 +---------------------+-----------------------------+ 496 Table 2: I1-SENT - Initiating HIP 498 System behavior in state I2-SENT, Table 3. 500 +---------------------+-----------------------------+ 501 | Trigger | Action | 502 +---------------------+-----------------------------+ 503 | t msec | Send I2 and stay at I2-SENT | 504 +---------------------+-----------------------------+ 506 Table 3: I2-SENT - Waiting to finish HIP 508 System behavior in state R2-SENT, Table 4. 510 +----------------------+-----------------------------+ 511 | Trigger | Action | 512 +----------------------+-----------------------------+ 513 | Receive duplicate I2 | Send R2 and stay at R2-SENT | 514 +----------------------+-----------------------------+ 516 Table 4: R2-SENT - Waiting to finish HIP 518 4.1.3.4. Simplified HIP State Diagram 520 The following diagram shows the major state transitions. Transitions 521 based on received packets implicitly assume that the packets are 522 successfully authenticated or processed. 524 +-+ +------------------------------+ 525 I1 received, send R1 | | | | 526 | v v | 527 Datagram to send +--------------+ I2 received, send R2 | 528 Send I1 +--------------| UNASSOCIATED |--------------+ | 529 +-+ | +-+ +--------------+ | | 530 send | | | | | | | 531 I1 t | | | | | Alg. not supported, send I1 | | 532 msec v | v | v | | 533 +---------+ I2 received, send R2 | | 534 +---->| I1-SENT |-------------------------------------+ | | 535 | +---------+ | | | 536 | | +----------------------+ | | +-+receive | 537 | send I2+-+ | R1 received, | I2 received, send R2 | | | | |I2, | 538 | t msec | v v send I2 | v v v | v send R2 | 539 | +---------+ | +---------+ | 540 | +->| I2-SENT |------------+ | R2-SENT |<--+ | 541 | | +---------+ +---------+ | | 542 | | | | | | 543 | | | data| | | 544 | |receive | or| | | 545 | |R1, send | EC timeout| receive I2,| | 546 | |I2 |R2 received +--------------+ | send R2| | 547 | | +----------->| ESTABLISHED |<--------+ | | 548 | | +--------------+ | | 549 | | | | | receive I2, send R2 | | 550 | | recv+------------+ | +------------------------+ | 551 | | CLOSE,| | | | 552 | | send| No packet sent| | | 553 | | CLOSE_ACK| /received for | timeout | | 554 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 555 | | | CLOSE +--->| CLOSING |--+ retransmit | | 556 | | | +---------+ CLOSE | | 557 +--|------------|----------------------+| | | | | | 558 +------------|-----------------------+ | | +-----------------+ | 559 | | +-----------+ +-------------------|----+ 560 | +-----------+ | receive CLOSE, CLOSE_ACK | | 561 | | | send CLOSE_ACK received or | | 562 | | | timeout | | 563 | | | (UAL+MSL) | | 564 | v v | | 565 | +--------+ receive I2, send R2 | | 566 +-----------------------| CLOSED |----------------------------+ | 567 +--------+ /-------------------------+ 568 ^ | \-------/ timeout (UAL+2MSL), 569 | | move to UNASSOCIATED 570 +-+ 571 CLOSE received, send CLOSE_ACK 573 4.1.4. HIP DEX Security Associations 575 HIP DEX establishes two Security Associations (SA), one for the 576 Diffie-Hellman derived key, or Master Key, and one for session or 577 Pair-wise Key. 579 4.1.4.1. Master Key SA 581 The Master Key SA is used to secure DEX parameters and authenticate 582 HIP packets. Since so little data will be protected by this SA it 583 can be very longed lived. 585 The Master Key SA contains the following elements. 587 Source HIT 589 Destination HIT 591 HIP_Encrypt Key 593 HIP_MAC Key 595 Both keys are extracted from the Diffie-Hellman derived key via 596 Section 6.3. Their length is determined by HIP_CIPHER. 598 4.1.4.2. Pair-wise Key SA 600 The Pair-wise Key SA is used to secure and authenticate user data. 601 It is refreshed (or rekeyed) using the UPDATE packet exchange. 603 The Pair-wise Key SA elements are defined by the data transform (e.g. 604 ESP_TRANSFORM [rfc5202-bis]). 606 The secrets in ENCRYPTED_KEY from I2 and R2 are concatenated to form 607 the input to a Key Derivation Function (KDF). If the data transform 608 does not have its own KDF, then Section 6.3 is used. Even though 609 this input is randomly distributed, a KDF Extract phase may be needed 610 to get the proper length for input to the KDF Expand phase. 612 4.1.5. User Data Considerations 614 There is only one difference in User Data Considerations between BEX 615 and DEX. Loss of state due to system reboot may be a critical 616 performance issue. Thus implementors MAY choose to use non-volatile, 617 secure storage for HIP state so that it survives system reboot. This 618 will limit state loss during reboots to only those situtations that 619 there is an SA timeout. 621 5. Packet Formats 623 5.1. HIP Parameters 625 The HIP Parameters are used to carry the public key associated with 626 the sender's HIT, together with related security and other 627 information. They consist of parameters, ordered according to their 628 numeric type number and encoded in TLV format. 630 The following new parameter types are currently defined for DEX, in 631 addition to those defined for BEX. Also listed are BEX parameters 632 that have additional values for DEX. 634 For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID, 635 only the ECC values are valid in DEX. 637 +------------------+-------+----------+-----------------------------+ 638 | TLV | Type | Length | Data | 639 +------------------+-------+----------+-----------------------------+ 640 | ENCRYPTED_KEY | 643 | variable | Encrypted container for key | 641 | | | | generation exchange | 642 | | | | | 643 | HIP_MAC_3 | 61507 | variable | CMAC-based message | 644 | | | | authentication code | 645 | | | | | 646 | HIP_CIPHER | 579 | variable | List of HIP encryption | 647 | | | | algorithms | 648 | | | | | 649 | HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT | 650 | | | | suites supported by the | 651 | | | | Responder | 652 +------------------+-------+----------+-----------------------------+ 654 5.1.1. HIP_CIPHER 656 The HIP ciphers in DEX are limited to: 658 Suite ID Value 660 RESERVED 0 661 NULL-ENCRYPT 1 ([RFC2410]) 662 AES-128-CTR 5 ([RFC3686]) 664 The HIP_CIPHER parameter is limited to NULL or AES-CTR. 666 5.1.2. HIT_SUITE_LIST 668 The HIT suites in DEX are limited to: 670 HIT suite ID 671 ECDH/DEX 8 673 The HIT_SUITE_LIST parameter contains a list of the supported HIT 674 suite IDs of the Responder. Since the HIT of the Initiator is a DEX 675 HIT, the Responder MUST only respond with a DEX HIT suite ID. 676 Currently, only one such suite ID has been defined. 678 5.1.3. ENCRYPTED_KEY 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Reserved | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 / Encrypted value / 688 / / 689 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 691 / Nonce / 692 / +-------------------------------+ 693 / | Padding | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Type 643 697 Length length in octets, excluding Type, Length, and 698 Padding 699 Encrypted The value is encrypted using an encryption algorithm 700 value as defined in the HIP_CIPHER parameter. 701 Nonce Nonce included in encrypted text. 703 The ENCRYPTED parameter encapsulates a value and a nonce. The value 704 is typically a random number used in a key creation process and the 705 nonce is known to the receiver to validate successful decryption. 707 Some encryption algorithms require an IV (initialization vector). 708 The IV MUST be known to the receiver through some source other than 709 within the Encrypted_key block. For example the Puzzle value, I, can 710 be used as an IV. 712 For AES-CTR a 16 bit counter can be used that is initized to zero 713 with the first use. 16 bits is considered a large enough counter as 714 it is only used for this parameter. 716 Some encryption algorithms require that the data to be encrypted must 717 be a multiple of the cipher algorithm block size. In this case, the 718 above block of data MUST include additional padding, as specified by 719 the encryption algorithm. The size of the extra padding is selected 720 so that the length of the unencrypted data block is a multiple of the 721 cipher block size. The encryption algorithm may specify padding 722 bytes other than zero; for example, AES [FIPS.197.2001] uses the 723 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 724 remaining n bytes to fill the block each have the value n. This 725 yields an "unencrypted data" block that is transformed to an 726 "encrypted data" block by the cipher suite. This extra padding added 727 to the set of parameters to satisfy the cipher block alignment rules 728 is not counted in HIP TLV length fields, and this extra padding 729 should be removed by the cipher suite upon decryption. 731 Note that the length of the cipher suite output may be smaller or 732 larger than the length of the value and nonce to be encrypted, since 733 the encryption process may compress the data or add additional 734 padding to the data. 736 Once this encryption process is completed, the Encrypted_key data 737 field is ready for inclusion in the Parameter. If necessary, 738 additional Padding for 8-byte alignment is then added according to 739 the rules of TLV Format in [rfc5201-bis]. 741 5.1.4. HIP_MAC_3 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Type | Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 | CMAC | 750 / / 751 / +-------------------------------+ 752 | | Padding | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Type 61507 756 Length length in octets, excluding Type, Length, and 757 Padding 758 CMAC CMAC computed over the HIP packet, excluding the 759 HIP_MAC parameter itself. The checksum field MUST 760 be set to zero and the HIP header length in the HIP 761 common header MUST be calculated not to cover any 762 excluded parameters when the CMAC is calculated. The 763 size of the CMAC is the natural size of the AES block 764 depending on the AES key size. 766 The CMAC calculation and verification process is presented in 767 Section 6.2.1. 769 5.2. HIP Packets 771 DEX uses the same eight basic HIP packets (see [rfc5201-bis]) as in 772 BEX. Four are for the HIP exchange, one is for updating, one is for 773 sending notifications, and two are for closing a HIP association. 774 There are some differences in the HIP parameters in the exchange 775 packets between BEX and DEX. This section will cover the DEX 776 packets. 778 An important difference between BEX and DEX HIP packets is that there 779 is no HIP_SIGNATURE parameter available in DEX. Thus R1 is 780 completely unprotected and can be spoofed. The I2, R2, UPDATE, 781 NOTIFY, CLOSE, and CLOSE_ACK parameters only have a HIP_MAC_3 782 parameter for packet authentication. The processing of these packets 783 are changed accordingly. 785 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 786 header. The Next Header field in the header indicates if there is 787 additional data following the HIP header. The HIP packet, however, 788 MUST NOT be fragmented. This limits the size of the possible 789 additional data in the packet. 791 5.2.1. I1 - the HIP Initiator Packet 793 The HIP header values for the I1 packet: 795 Header: 796 Packet Type = 1 797 SRC HIT = Initiator's HIT 798 DST HIT = Responder's HIT, or NULL 800 IP ( HIP ( DH_GROUP_LIST ) ) 802 Minimum size = 40 bytes 804 The I1 packet contains the fixed HIP header and the Initiator's 805 DH_GROUP_LIST. 807 Valid control bits: none 809 The Initiator HIT MUST be a DEX HIT. The HIT Suite ID MUST be of a 810 DEX type. Currently only ECDH/DEX is defined. 812 The Initiator receives the Responder's HIT either from a DNS lookup 813 of the Responder's FQDN, from some other repository, or from a local 814 table. The Responder's HIT MUST be a DEX HIT. If the Initiator does 815 not know the Responder's HIT, it may attempt to use opportunistic 816 mode by using NULL (all zeros) as the Responder's HIT. See also "HIP 817 Opportunistic Mode" [rfc5201-bis]. 819 Since this packet is so easy to spoof even if it were signed, no 820 attempt is made to add to its generation or processing cost. 822 The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform 823 the Responder of its preferred DH Group IDs. Only ECDH Groups may be 824 included in this list. Note that the DH_GROUP_LIST in the I1 packet 825 is not protected by a MAC. 827 Implementations MUST be able to handle a storm of received I1 828 packets, discarding those with common content that arrive within a 829 small time delta, but distinguishing this from arriving at a set time 830 delta. This behaviour is the expected behaviour for an Initiator on 831 a network with high packet loss. The HIP state machine calls out 832 this behaviour in this case and the Initiator will stop sending I1 833 packets after it receives an R1 packet. 835 5.2.2. R1 - the HIP Responder Packet 837 The HIP header values for the R1 packet: 839 Header: 840 Packet Type = 2 841 SRC HIT = Responder's HIT 842 DST HIT = Initiator's HIT 844 IP ( HIP ( [ R1_COUNTER, ] 845 PUZZLE, 846 HIP_CIPHER, 847 HOST_ID, 848 HIT_SUITE_LIST, 849 DH_GROUP_LIST, 850 [ <, ECHO_REQUEST_UNSIGNED >i ]) 852 Minimum size = 120 bytes 854 Valid control bits: A 856 If the Responder's HI is an anonymous one, the A control MUST be set. 858 The Initiator's HIT MUST match the one received in I1. If the 859 Responder has multiple HIs, the Responder's HIT used MUST match 860 Initiator's request. If the Initiator used opportunistic mode, the 861 Responder may select freely among its HIs. See also "HIP 862 Opportunistic Mode" [rfc5201-bis]. 864 The R1 generation counter is used to determine the currently valid 865 generation of puzzles. The value is increased periodically, and it 866 is RECOMMENDED that it is increased at least as often as solutions to 867 old puzzles are no longer accepted. 869 The Puzzle contains a Random #I and the difficulty K. The difficulty 870 K indicates the number of lower-order bits, in the puzzle CMAC 871 result, that MUST be zeros; see Section 4.1.2. 873 If the Responder is sensor controller and the Initiator is a sensor, 874 then K may be 0. This is to conserve power on the sensor. 876 The Initiator HIT does not provide the HOST_ID key size. The 877 Responder selects its HOST_ID based on the Initiator's preference 878 expressed in the DH_GROUP_LIST parameter in the I1. The Responder 879 sends back its own preference based on which it chose the HOST_ID as 880 DH_GROUP_LIST. This allows the Initiator to determine whether its 881 own DH_GROUP_LIST in the I1 was manipulated by an attacker. There is 882 a further risk that the Responder's DH_GROUP_LIST was manipulated by 883 an attacker, as R1 cannot be authenticated in DEX as it can in BEX. 884 Thus it is repeated in R2 allowing for a final check at that point. 886 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 887 discarded. 889 The HIP_CIPHER contains the encryption algorithms supported by the 890 Responder to protect the key exchange, in the order of preference. 891 All implementations MUST support the AES-CTR [RFC3686]. 893 The ECHO_REQUEST_UNSIGNED contains data that the sender wants to 894 receive unmodified in the corresponding response packet in the 895 ECHO_RESPONSE_UNSIGNED parameter. 897 5.2.3. I2 - the Second HIP Initiator Packet 899 The HIP header values for the I2 packet: 901 Header: 902 Type = 3 903 SRC HIT = Initiator's HIT 904 DST HIT = Responder's HIT 906 IP ( HIP ( [R1_COUNTER,] 907 SOLUTION, 908 HIP_CIPHER, 909 HOST_ID, 910 ENCRYPTED_KEY {DH, secret-x|I}, 911 [ ENCRYPTED {DH, ENCRYPTED_KEY {passwd, challenge } },] 912 HIP_MAC_3, 913 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 915 Minimum size = 180 bytes 917 Valid control bits: A 919 The HITs used MUST match the ones used previously. 921 If the Initiator's HI is an anonymous one, the A control MUST be set. 923 The Initiator MAY include an unmodified copy of the R1_COUNTER 924 parameter received in the corresponding R1 packet into the I2 packet. 926 The Solution contains the Random #I from R1 and the computed #J. The 927 low-order K bits of the CMAC(S, | ... | J) MUST be zero. 929 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 930 discarded. 932 The HIP_CIPHER contains the single encryption transform selected by 933 the Initiator, that will be used to protect the HI exchange. The 934 chosen transform MUST correspond to one offered by the Responder in 935 the R1. All implementations MUST support the AES-CTR transform 936 [RFC3686]. 938 The ECHO_RESPONSE_UNSIGNED contain the unmodified Opaque data copied 939 from the corresponding echo request parameter. 941 The ENCRYPTED_KEY contains an Initiator generated random secret x 942 that MUST be uniformly distributed. X is concatenated with I from 943 the puzzle. The secret x's length matches the keysize of the 944 selected encryption transform. AES-CTR MUST be used as the HIP 945 transform for this parameter. The key is the HIP_Encrypt key, the 946 output of the CKDF on the ECDH shared secret. The counter is 947 initialized at zero for the first I2 packet. Note that this counter 948 MUST NOT be reset until a new puzzle with a new I is received from 949 the Responder. I in the ENCRYPTED block enables the Responder to 950 validate a proper decryption of the block and acts as a nonce from 951 the Responder to prove freshness of the secret wrapping from the 952 Initiator. 954 If the Initiator has prior knowledge that the Responder is expecting 955 a password authenication, the Initiator encrypts the 956 ECHO_REQUEST_UNSIGNED with the password, then wraps the ENCRYPTED 957 parameter in the HIP_Encrypt key. There is no signal within R1 for 958 this behaviour. Knowledge of password authencation must be 959 externally configured. 961 The MAC is calculated over the whole HIP envelope, excluding any 962 parameters after the HIP_MAC_3, as described in Section 6.2.1. The 963 Responder MUST validate the HIP_MAC_3. 965 5.2.4. R2 - the Second HIP Responder Packet 967 The HIP header values for the R2 packet: 969 Header: 970 Packet Type = 4 971 SRC HIT = Responder's HIT 972 DST HIT = Initiator's HIT 974 IP ( HIP ( DH_GROUP_LIST, 975 ENCRYPTED_KEY {DH, secret-y|I}, 976 HIP_MAC_3) 978 Minimum size = 108 bytes 980 Valid control bits: none 982 The Responder repeats the DH_GROUP_LIST parameter in R2. This MUST 983 be the same list as included in R1. The DH_GROUP_LIST parameter is 984 repeated here because R2 is MACed and thus cannot be altered by an 985 attacker. This allows the Initiator to determine whether its own 986 DH_GROUP_LIST in the I1 was manipulated by an attacker. 988 The ENCRYPTED contains a Responder generated random secret y that 989 MUST be uniformly distributed. Y is concatenated with I from the 990 puzzle. The secret y's length matches the keysize of the selected 991 encryption transform. AES-CTR MUST be used as the HIP transform for 992 this parameter. The key is the HIP_Encrypt key, the output of the 993 CKDF on the ECDH shared secret. The counter is initialized at zero 994 for the first R2 packet. Note that this counter MUST NOT be reset 995 until a new puzzle with a new I. I is the Solution in I2. I in the 996 ENCRYPTED block enables the Initiator to validate a proper decryption 997 of the block and acts as a nonce from the Initiator to prove 998 freshness of the secret wrapping from the Initiator. 1000 The HIP_MAC_3 is calculated over the whole HIP envelope, with 1001 Responder's HOST_ID parameter concatenated with the HIP envelope. 1002 The HOST_ID parameter is removed after the CMAC calculation. The 1003 procedure is described in Section 6.2.1. 1005 The Initiator MUST validate the HIP_MAC_3. 1007 5.3. ICMP Messages 1009 When a HIP implementation detects a problem with an incoming packet, 1010 and it either cannot determine the identity of the sender of the 1011 packet or does not have any existing HIP association with the sender 1012 of the packet, it MAY respond with an ICMP packet. Any such replies 1013 MUST be rate-limited as described in [RFC2463]. In most cases, the 1014 ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 1015 for ICMPv6), with the Pointer field pointing to the field that caused 1016 the ICMP message to be generated. 1018 6. Packet Processing 1020 Each host is assumed to have a single HIP protocol implementation 1021 that manages the host's HIP associations and handles requests for new 1022 ones. Each HIP association is governed by a conceptual state 1023 machine, with states defined above in Section 4.1.3. The HIP 1024 implementation can simultaneously maintain HIP associations with more 1025 than one host. Furthermore, the HIP implementation may have more 1026 than one active HIP association with another host; in this case, HIP 1027 associations are distinguished by their respective HITs. It is not 1028 possible to have more than one HIP association between any given pair 1029 of HITs. Consequently, the only way for two hosts to have more than 1030 one parallel association is to use different HITs, at least at one 1031 end. 1033 6.1. Solving the Puzzle 1035 This subsection describes the puzzle-solving details. 1037 In R1, the values I and K are sent in network byte order. Similarly, 1038 in I2, the values I and J are sent in network byte order. The MAC is 1039 created by concatenating, in network byte order, the following data, 1040 in the following order and using the CMAC algorithm with I as the 1041 key: 1043 128-bit Initiator's HIT, in network byte order, as appearing in 1044 the HIP Payload in R1 and I2. 1046 128-bit Responder's HIT, in network byte order, as appearing in 1047 the HIP Payload in R1 and I2. 1049 n-bit random value J (where n is CMAC-len), in network byte order, 1050 as appearing in I2. 1052 In order to be a valid response puzzle, the K low-order bits of the 1053 resulting CMAC MUST be zero. 1055 Notes: 1057 i) All the data in the CMAC input MUST be in network byte order. 1059 ii) The order of the Initiator's and Responder's HITs are 1060 different in the R1 and I2 packets; see [rfc5201-bis]. Care must 1061 be taken to copy the values in the right order to the CMAC input. 1063 The following procedure describes the processing steps involved, 1064 assuming that the Responder chooses to precompute the R1 packets: 1066 Precomputation by the Responder: 1067 Sets up the puzzle difficulty K. 1068 Creates a R1 and caches it. 1070 Responder: 1071 Selects a suitable cached R1. 1072 Generates a random number I. 1073 Sends I and K in an R1. 1074 Saves I and K for a Delta time. 1076 Initiator: 1077 Generates repeated attempts to solve the puzzle until a matching J 1078 is found: 1079 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1080 Sends I and J in an I2. 1082 Responder: 1083 Verifies that the received I is a saved one. 1084 Finds the right K based on I. 1085 Computes V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1086 Rejects if V != 0 1087 Accept if V == 0 1089 6.2. HIP_MAC Calculation and Verification 1091 The following subsections define the actions for processing the 1092 HIP_MAC_3 parameter. 1094 6.2.1. CMAC Calculation 1096 Both the Initiator and the Responder should take some care when 1097 verifying or calculating the HIP_MAC_3. Specifically, the Responder 1098 should preserve other parameters than the HOST_ID when sending the 1099 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 1100 was received in the R1 packet. 1102 The scope of the calculation for HIP_MAC_3 is: 1104 CMAC: { HIP header | [ Parameters ] } 1106 where Parameters include all HIP parameters of the packet that is 1107 being calculated with Type values from 1 to (HIP_MAC's Type value - 1108 1) and exclude parameters with Type values greater or equal to 1109 HIP_MAC's Type value. 1111 During HIP_MAC calculation, the following applies: 1113 o In the HIP header, the Checksum field is set to zero. 1115 o In the HIP header, the Header Length field value is calculated to 1116 the beginning of the HIP_MAC parameter. 1118 Parameter order is described in [rfc5201-bis]. 1120 The HIP_MAC parameter is defined in Section 5.1.4. The CMAC 1121 calculation and verification process is as follows: 1123 Packet sender: 1125 1. Create the HIP packet, without the HIP_MAC or any other parameter 1126 with greater Type value than the HIP_MAC parameter has. 1128 2. Calculate the Header Length field in the HIP header. 1130 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1131 retrieved from KEYMAT as defined in Section 6.3. 1133 4. Add the HIP_MAC_3 parameter to the packet and any parameter with 1134 greater Type value than the HIP_MAC's (HIP_MAC_3's) that may 1135 follow. 1137 5. Recalculate the Length field in the HIP header. 1139 Packet receiver: 1141 1. Verify the HIP header Length field. 1143 2. Remove the HIP_MAC_3 parameter, as well as all other parameters 1144 that follow it with greater Type value, saving the contents if 1145 they will be needed later. 1147 3. Recalculate the HIP packet length in the HIP header and clear the 1148 Checksum field (set it to all zeros). 1150 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1151 defined in Section 6.3 and verify it against the received CMAC. 1153 5. Set Checksum and Header Length field in the HIP header to 1154 original values. 1156 6.3. HIP DEX KEYMAT Generation 1158 The HIP DEX KEYMAT process is used for both the Diffie-Hellman 1159 Derived Master key and the Encrypted secrets Pair-wise key. The 1160 former uses both the Extract and Expand phases, while the later MAY 1161 need the Extract and Expand phases if the key is longer than 128 1162 bits. Othewise it only needs the Expand phase. 1164 The Diffie-Hellman Derived Master key is exchanged in R1 and I2 and 1165 used in I2, R2. UPDATE, NOTIFY, and ACK packets. The Encrypted 1166 secrets Pair-wise key is not used in HIP, but is available as the 1167 datagram protection key. Some datagram protection mechanisms have 1168 their own Key Derivation Function, and if so that SHOULD be used 1169 rather than the HIP DEX KEYMAT. 1171 The KEYMAT has two components, CKDF-Extract and CKDF-Expand. The 1172 Extract function COMPRESSES a non-uniformly distributed key, as is 1173 the output of a Diffie-Hellman key derivation, to EXTRACT all the key 1174 entropy into a fixed length output. The Expand function takes either 1175 the output of the Extract function or directly uses a uniformly 1176 distributed key and EXPANDS the length of the key, repeatedly 1177 distributing the key entropy, to produce the keys needed. 1179 The CKDF-Extract function is following operation; the | operation 1180 denotes concatenation. 1182 CKDF-Extract(BigK, I, info, L) -> CK 1184 The output CK is calculated as follows: 1186 CK = CMAC(I, BigK | info) 1188 where 1190 info = sort(HIT-I | HIT-R) | "CKDF-Extract" 1191 BigK = Diffie-Hellman Derived or Session (x | y) Key 1192 I = I from PUZZLE Parameter 1194 The CKDF-Expand function is following operation; the | operation 1195 denotes concatenation. 1197 CKDF-Expand(CK, info, L) -> OKM 1199 The output OKM is calculated as follows: 1201 CK a pseudorandom key of at least macLen octets 1202 (usually, the output from the extract step) 1203 N = ceil(L/macLen) 1204 T = T(1) | T(2) | T(3) | ... | T(N) 1205 OKM = first L octets of T 1207 where 1209 info = sort(HIT-I | HIT-R) | "CKDF-Expand" 1210 CK = CK from CKDF-Extract or (x | y) 1211 macLen = Length of CMAC in octets = 128/8 = 16 1212 L length of output keying material in octets 1213 (<= 255*macLen) 1215 where: 1217 T(0) = empty string (zero length) 1218 T(1) = CMAC(CK, T(0) | info | 0x01) 1219 T(2) = CMAC(CK, T(1) | info | 0x02) 1220 T(3) = CMAC(CK, T(2) | info | 0x03) 1221 ... 1223 (where the constant concatenated to the end of each T(n) is a 1224 single octet.) 1226 Sort(HIT-I | HIT-R) is defined as the network byte order 1227 concatenation of the two HITs, with the smaller HIT preceding the 1228 larger HIT, resulting from the numeric comparison of the two HITs 1229 interpreted as positive (unsigned) 128-bit integers in network byte 1230 order. 1232 x and y values are from the ENCRYPTED parameters from I2 and R2 1233 respectively. 1235 The initial keys are drawn sequentially in the order that is 1236 determined by the numeric comparison of the two HITs, with comparison 1237 method described in the previous paragraph. HOST_g denotes the host 1238 with the greater HIT value, and HOST_l the host with the lower HIT 1239 value. 1241 The drawing order for initial keys: 1243 HIP-gl encryption key for HOST_g's outgoing HIP packets 1245 HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1247 HIP-lg encryption key for HOST_l's outgoing HIP packets 1249 HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1251 The number of bits drawn for a given algorithm is the "natural" size 1252 of the keys. For the mandatory algorithms, the following sizes 1253 apply: 1255 AES 128 or 256 bits 1257 If other key sizes are used, they must be treated as different 1258 encryption algorithms and defined separately. 1260 6.4. Processing Incoming I1 Packets 1262 An implementation SHOULD reply to an I1 with an R1 packet, unless the 1263 implementation is unable or unwilling to set up a HIP association. 1264 An I1 in DEX is handled identically to BEX with the exception that in 1265 constructing the R1, the Responder SHOULD select a HIT that is 1266 constructed with the MUST algorithm, which is currently ECDH. 1268 6.4.1. R1 Management 1270 All compliant implementations MUST produce R1 packets. An R1 in DEX 1271 is handled identically to BEX. 1273 6.5. Processing Incoming R1 Packets 1275 A system receiving an R1 MUST first check to see if it has sent an I1 1276 to the originator of the R1 (i.e., it is in state I1-SENT). An R1 in 1277 DEX is handled identically to BEX with the following differences. 1279 If the system has been sending out a stream of I1 packets to work 1280 around high packet loss on a network, it stops sending the I1 packets 1281 AFTER successfully processing a R1 packet. 1283 There is no HIP_SIGNATURE in the R1 packet. It is an unauthenticated 1284 packet. 1286 The following steps define the conceptual processing rules for 1287 responding to an R1 packet that are different than in BEX: 1289 1. If the system is configured with an authentication password for 1290 the responder, it constructs the authentication response to 1291 include in the I2. 1293 2. The system prepares and sends an I2, as described in 1294 Section 5.2.3. The system MAY be configured to continually send 1295 this I2 until it receives and validates an R2. 1297 6.6. Processing Incoming I2 Packets 1299 Upon receipt of an I2, the system MAY perform initial checks to 1300 determine whether the I2 corresponds to a recent R1 that has been 1301 sent out, if the Responder keeps such state. An I2 in DEX is handled 1302 identically to BEX with the following differences. 1304 The HIP implementation SHOULD process the I2. This includes 1305 validation of the puzzle solution, extracting the ENCRYPTED key for 1306 processing I2, decrypting the Initiator's Host Identity, verifying 1307 the mac, creating state, and finally sending an R2. 1309 There is no HIP_SIGNATURE on this packet. Authentication is 1310 completely based on the HIP_MAC_3 parameter. 1312 The following steps define the conceptual processing rules for 1313 responding to an I2 packet: 1315 1. If the system's state machine is in the I2-SENT state, the system 1316 makes a comparison between its local and sender's HITs (similarly 1317 as in Section 6.3). If the local HIT is smaller than the 1318 sender's HIT, it should drop the I2 packet, and continue using 1319 the R1 received and I2 sent to the peer earlier. Otherwise, the 1320 system should process the received I2 packet and drop any 1321 previously derived Diffie-Hellman keying material and ENCRYPTED 1322 keying material it might have formed upon sending the I2 1323 previously. The peer Diffie-Hellman key, ENCRYPTED keying 1324 material and the nonce J are taken from the just arrived I2 1325 packet. The local Diffie-Hellman key and the nonce I are the 1326 ones that were earlier sent in the R1 packet. 1328 2. The system MUST validate the solution to the puzzle by computing 1329 the mac described in Section 5.2.3 using the CMAC algorithm. 1331 3. The system must extract the keying material from the ENCRYPTED 1332 parameter. This key is used to derive the HIP data keys. 1334 4. If the checks above are valid, then the system proceeds with 1335 further I2 processing; otherwise, it discards the I2 and its 1336 state machine remains in the same state. If the system has been 1337 sending a stream of R1 packets to the HIT in the I2 the system 1338 stops sending the R1s. 1340 6.7. Processing Incoming R2 Packets 1342 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1343 results in the R2 being dropped and the state machine staying in the 1344 same state. If an R2 is received in state I2-SENT, it SHOULD be 1345 processed. 1347 There is no HIP_SIGNATURE on this packet. Authentication is 1348 completely based on the HIP_MAC_3 parameter. 1350 The conceptual processing rules for an incoming R2 packet in DEX are 1351 identical to BEX with the following differences. 1353 1. The system checks the DH_GROUP_LIST as in R1 packet processing. 1354 If the list is different from R1's there may have been a DH 1355 downgrade attack against the unprotected R1 packet. If the 1356 DH_GROUP_LIST presents a better list than recieved in the R1 1357 packet, the system may either resend I1 within the retry bounds 1358 or abandon the HIP exchange. 1360 2. The system must extract the keying material from the ENCRYPTED 1361 parameter. This key is concatanated with that sent in the I2 1362 packet to form the HIP data keys. 1364 6.8. Sending UPDATE Packets 1366 A host sends an UPDATE packet when it updates some information 1367 related to a HIP association. DEX UPDATE handling is the similar in 1368 DEX as in BEX. The key difference is the HIP_SIGNATURE is not 1369 present. 1371 6.9. Handling State Loss 1373 In the case of system crash and unanticipated state loss, the system 1374 SHOULD delete the corresponding HIP state, including the keying 1375 material. That is, the state SHOULD NOT be stored on stable storage. 1376 If the implementation does drop the state (as RECOMMENDED), it MUST 1377 also drop the peer's R1 generation counter value, unless a local 1378 policy explicitly defines that the value of that particular host is 1379 stored. An implementation MUST NOT store R1 generation counters by 1380 default, but storing R1 generation counter values, if done, MUST be 1381 configured by explicit HITs. 1383 7. HIP Policies 1385 There are a number of variables that will influence the HIP exchanges 1386 that each host must support. All HIP implementations MUST support 1387 more than one simultaneous HI, at least one of which SHOULD be 1388 reserved for anonymous usage. Although anonymous HIs will be rarely 1389 used as Responders' HIs, they will be common for Initiators. Support 1390 for more than two HIs is RECOMMENDED. 1392 Many Initiators would want to use a different HI for different 1393 Responders. The implementations SHOULD provide for an ACL of 1394 Initiator's HIT to Responder's HIT. This ACL SHOULD also include 1395 preferred transform and local lifetimes. 1397 The value of K used in the HIP R1 packet can also vary by policy. K 1398 should never be greater than 20, but for trusted partners it could be 1399 as low as 0. 1401 Responders would need a similar ACL, representing which hosts they 1402 accept HIP exchanges, and the preferred transform and local 1403 lifetimes. Wildcarding SHOULD be supported for this ACL also. 1405 8. Security Considerations 1407 HIP is designed to provide secure authentication of hosts. HIP also 1408 attempts to limit the exposure of the host to various denial-of- 1409 service and man-in-the-middle (MitM) attacks. In so doing, HIP 1410 itself is subject to its own DoS and MitM attacks that potentially 1411 could be more damaging to a host's ability to conduct business as 1412 usual. 1414 HIP DEX replaces the SIGMA authenticated Diffie-Hellman key exchange 1415 of BEX with a random generated key exchange encrypted by a Diffie- 1416 Hellman derived key. Both the Initiator and Responder contribute to 1417 this key. 1419 The strength of the key is based on the quality of the secrets 1420 generated by the Initiator and Responder. Since the Initiator is 1421 commonly a sensor there is a natural concern about the quality of 1422 its random number generator. 1424 DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1425 compromised, ALL HIP connections protected with that HI are 1426 compromised. 1428 The puzzle mechanism using CMAC may need further study that it 1429 does present the desired level of difficulty. 1431 The DEX HIT extraction MAY present new attack opportunities; 1432 further study is needed. 1434 The R1 packet is unprotected and offers an attacker new resource 1435 attacks against the Initiator. This is mitigated by the Initator 1436 only processing a received R1 when it has sent an I1. This is 1437 another DoS attack, but for battery powered Initiators, it could be a 1438 concern. 1440 9. IANA Considerations 1442 IANA has reserved protocol number 139 for the Host Identity Protocol. 1444 The following HIT suites are defined for DEX HIT generation. 1446 +-------+------------+----------------------+-----------------------+ 1447 | Index | Hash | Signature algorithm | Description | 1448 | | function | family | | 1449 +-------+------------+----------------------+-----------------------+ 1450 | 5 | LTRUNC | ECDH | ECDH HI truncated to | 1451 | | | | 96 bits | 1452 +-------+------------+----------------------+-----------------------+ 1454 Table 5: HIT Suites 1456 10. Acknowledgments 1458 The drive to put HIP on a cryptographic 'Diet' came out of a number 1459 of discussions with sensor vendors at IEEE 802.15 meetings. David 1460 McGrew was very 1462 11. Changes from draft-moskowitz-hip-rg-dex-05 1464 This section summarizes the changes made from 1465 draft-moskowitz-hip-rg-dex-05, which was the first last stable 1466 version of the draft. 1468 11.1. Changes in draft-moskowitz-hip-rg-dex-06 1470 o A major change in the ENCRYPT parameter to use AES-CTR rather than 1471 AES-CBC. 1473 11.2. Changes in draft-moskowitz-hip-dex-00 1475 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 1476 submission. 1478 o Added the change section. 1480 o Added a Definitions section. 1482 o Changed I2 and R2 packets to reflect use of AES-CTR for 1483 ENCRYPTED_KEY parameter. 1485 o Cleaned up KEYMAT Generation text. 1487 o Added Appendix with C code for the ECDH shared secret generation 1488 on an 8 bit processor. 1490 12. References 1492 12.1. Normative References 1494 [RFC2119] Bradner, S., "Key words for use in RFCs to 1495 Indicate Requirement Levels", BCP 14, RFC 2119, 1496 March 1997. 1498 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 1499 Version 6 (IPv6) Specification", RFC 2460, 1500 December 1998. 1502 [RFC2463] Conta, A. and S. Deering, "Internet Control 1503 Message Protocol (ICMPv6) for the Internet 1504 Protocol Version 6 (IPv6) Specification", 1505 RFC 2463, December 1998. 1507 [RFC3686] Housley, R., "Using Advanced Encryption 1508 Standard (AES) Counter Mode With IPsec 1509 Encapsulating Security Payload (ESP)", 1510 RFC 3686, January 2004. 1512 [RFC3972] Aura, T., "Cryptographically Generated 1513 Addresses (CGA)", RFC 3972, March 2005. 1515 [RFC4309] Housley, R., "Using Advanced Encryption 1516 Standard (AES) CCM Mode with IPsec 1517 Encapsulating Security Payload (ESP)", 1518 RFC 4309, December 2005. 1520 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 1521 "Fundamental Elliptic Curve Cryptography 1522 Algorithms", RFC 6090, February 2011. 1524 [rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 Prefix for 1525 Overlay Routable Cryptographic Hash Identifiers 1526 (ORCHID)", draft-ietf-hip-rfc4843-bis-01 (work 1527 in progress), March 2011. 1529 [rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and T. 1530 Henderson, "Host Identity Protocol Version 2 1531 (HIPv2)", draft-ietf-hip-rfc5201-bis-09 (work 1532 in progress), July 2012. 1534 [rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., and J. 1535 Melen, "Using the Encapsulating Security 1536 Payload (ESP) Transport Format with the Host 1537 Identity Protocol (HIP)", 1538 draft-ietf-hip-rfc5202-bis-00 (work in 1539 progress), September 2010. 1541 12.2. Informative References 1543 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 1544 "Analysis of the HIP Base Exchange Protocol", 1545 in Proceedings of 10th Australasian Conference 1546 on Information Security and Privacy, July 2003. 1548 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service 1549 via Algorithmic Complexity Attacks", in 1550 Proceedings of Usenix Security Symposium 2003, 1551 Washington, DC., August 2003. 1553 [FIPS.197.2001] National Institute of Standards and Technology, 1554 "Advanced Encryption Standard (AES)", FIPS PUB 1555 197, November 2001, . 1558 [IEEE.802-11.2007] "Information technology - Telecommunications 1559 and information exchange between systems - 1560 Local and metropolitan area networks - Specific 1561 requirements - Part 11: Wireless LAN Medium 1562 Access Control (MAC) and Physical Layer (PHY) 1563 Specifications", IEEE Standard 802.11, 1564 June 2007, . 1567 [IEEE.802-15-4.2011] "Information technology - Telecommunications 1568 and information exchange between systems - 1569 Local and metropolitan area networks - Specific 1570 requirements - Part 15.4: Wireless Medium 1571 Access Control (MAC) and Physical Layer (PHY) 1572 Specifications for Low-Rate Wireless Personal 1573 Area Networks (WPANs)", IEEE Standard 802.15.4, 1574 September 2011, . 1577 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for 1578 Writing an IANA Considerations Section in 1579 RFCs", BCP 26, RFC 2434, October 1998. 1581 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 1582 Cryptography Specification Version 2.0", 1583 RFC 2898, September 2000. 1585 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) 1586 Protocol", RFC 4306, December 2005. 1588 [rfc4423-bis] Moskowitz, R., "Host Identity Protocol 1589 Architecture", draft-ietf-hip-rfc4423-bis-04 1590 (work in progress), July 2012. 1592 Appendix A. Using Responder Puzzles 1594 As mentioned in Section 4.1.1, the Responder may delay state creation 1595 and still reject most spoofed I2s by using a number of pre-calculated 1596 R1s and a local selection function. This appendix defines one 1597 possible implementation in detail. The purpose of this appendix is 1598 to give the implementors an idea on how to implement the mechanism. 1599 If the implementation is based on this appendix, it MAY contain some 1600 local modification that makes an attacker's task harder. 1602 The Responder creates a secret value S, that it regenerates 1603 periodically. The Responder needs to remember the two latest values 1604 of S. Each time the S is regenerated, the R1 generation counter 1605 value is incremented by one and the Responder generates an R1 packet. 1607 When the Initiator sends the I1 packet for initializing a connection, 1608 the Responder gets the HIT and IP address from the packet, and 1609 generates an I value for the puzzle. 1611 I value calculation: 1612 I = Ltrunc( CMAC ( S, HIT-I | HIT-R | IP-I | IP-R ), n) 1613 where n = CMAC-len 1615 From an incoming I2 packet, the Responder gets the required 1616 information to validate the puzzle: HITs, IP addresses, and the 1617 information of the used S value from the R1_COUNTER. Using these 1618 values, the Responder can regenerate the I, and verify it against the 1619 I received in the I2 packet. If the I values match, it can verify 1620 the solution using I, J, and difficulty K. If the I values do not 1621 match, the I2 is dropped. 1623 puzzle_check: 1624 V := Ltrunc( CMAC( I2.I | I2.I, I2.hit_i | I2.hit_r | I2.J ), K ) 1625 if V != 0, drop the packet 1627 If the puzzle solution is correct, the I and J values are stored for 1628 later use. They are used as input material when keying material is 1629 generated. 1631 Keeping state about failed puzzle solutions depends on the 1632 implementation. Although it is possible for the Responder not to 1633 keep any state information, it still may do so to protect itself 1634 against certain attacks (see Section 4.1.1). 1636 Appendix B. Generating a Public Key Encoding from an HI 1638 The following pseudo-code illustrates the process to generate a 1639 public key encoding from an HI for ECDH. 1641 Appendix C. C code for ECDH point multiplication on an 8 bit processor 1643 The following code illustrates the process to generate the shared 1644 secret key from ECDH exchange. 1646 // The following code is taken from the 1647 // Relic library (http://code.google.com/p/relic-toolkit/) 1648 // This code includes the function for point multiplication over 1649 // prime fields 1651 /** 1652 * The following function multiplies a prime elliptic point by an 1653 * integer using the binary method. 1654 * 1655 * @param[out] r - the result. 1656 * @param[in] p - the point to multiply. 1657 * @param[in] k - the integer. 1658 */ 1660 /** 1661 * ep_t is library specific representation for an elliptic curve 1662 * point 1663 * bn_t is library specific representation for a multiple precision 1664 * integer structure 1665 */ 1667 void ep_mul_basic(ep_t r, ep_t p, bn_t k) { 1668 int i, l; 1669 ep_t t; 1671 ep_null(t); 1673 if (bn_is_zero(k)) { 1674 //If k is 0 then assign the prime elliptic curve point to a point 1675 // at the infinity 1676 ep_set_infty(r); 1677 return; 1678 } 1680 TRY { 1681 //ep_new allocates memory for the point and may throw ERR_NO_MEMORY 1682 // incase of insufficient memory 1683 ep_new(t); 1684 //bn_bits returns the number of bits of a multiple precision 1685 // integer l = bn_bits(k); 1686 //bn_test_bit returns 0 if the bit at the given location is 0 and 1687 // returns non zero otherwise 1688 if (bn_test_bit(k, l - 1)) { 1689 ep_copy(t, p); 1690 } else { 1691 ep_set_infty(t); 1692 } 1694 for (i = l - 2; i >= 0; i--) { 1695 //ep_dbl doubles a prime elliptic curve point 1696 ep_dbl(t, t); 1697 if (bn_test_bit(k, i)) { 1698 //ep_add adds two prime elliptic curve points 1699 ep_add(t, t, p); 1700 } 1701 } 1703 ep_copy(r, t); 1704 //ep_norm converts a point to affine coordinates 1705 ep_norm(r, r); 1706 } 1707 CATCH_ANY { 1708 THROW(ERR_CAUGHT); 1709 } 1710 FINALLY { 1711 ep_free(t); 1712 } 1713 } 1715 Author's Address 1717 Robert Moskowitz 1718 Verizon 1719 1000 Bent Creek Blvd, Suite 200 1720 Mechanicsburg, PA 1721 USA 1723 EMail: robert.moskowitz@verizon.com