idnits 2.17.1 draft-moskowitz-hip-rg-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 ([RFC5201-bis], [IEEE.802-15-4.2006]), 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 (July 7, 2010) is 5041 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 1304, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1368, 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) -- No information found for draft-laganier-rfc4843-bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC4843-bis' == Outdated reference: A later version (-02) exists of draft-moskowitz-hip-rfc5201-bis-01 ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 7 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 ICSA labs 4 Intended status: Standards Track July 7, 2010 5 Expires: January 8, 2011 7 HIP Diet EXchange (DEX) 8 draft-moskowitz-hip-rg-dex-01 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 primatives 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 code 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.2006]. 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 January 8, 2011. 42 Copyright Notice 44 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . 5 75 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 6 76 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. The DEX Host Identifier Tag (HIT) and Its Representations . . 6 78 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 6 79 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 7 80 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Creating a HIP Association . . . . . . . . . . . . . . . . 7 82 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . . 8 83 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 9 84 4.1.3. HIP State Machine . . . . . . . . . . . . . . . . . . 10 85 4.1.4. User Data Considerations . . . . . . . . . . . . . . . 14 86 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.1. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . 15 89 5.1.2. HIP_MAC_3 . . . . . . . . . . . . . . . . . . . . . . 16 90 5.2. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 16 91 5.2.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 17 92 5.2.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 17 93 5.2.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 19 94 5.2.4. R2 - the Second HIP Responder Packet . . . . . . . . . 20 95 5.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 21 96 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 21 97 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 22 98 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . . 23 99 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . . 23 100 6.3. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 24 101 6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . . 26 102 6.4.1. R1 Management . . . . . . . . . . . . . . . . . . . . 26 103 6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . . 26 104 6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . . 27 105 6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . . 28 106 6.8. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 28 107 6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 28 108 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 111 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 114 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 115 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 32 116 Appendix B. Generating a Public Key Encoding from an HI . . . . . 33 118 1. Introduction 120 This memo specifies the details of the Host Identity Protocol Diet 121 EXchange (HIP DEX). HIP DEX uses the smallest possible set of 122 established cryptographic primitives, in such a manner that does not 123 change our understanding of their behaviour, yet in a different 124 formulation to achieve assertions normally met with different 125 primatives. 127 HIP DEX builds on HIP BEX [RFC5201-bis], and only the differences 128 between BEX and DEX are documented here. 130 There are a few key differences between BEX and DEX. 132 Minimum collection of cryptographic primatives. 134 AES-CBC for symmetric encryption and to provide CMAC for MACing 135 functions. 137 Static/Static Elliptic Curve Diffie-Hellman keys used to 138 encrypt the session key. 140 A simple trunctation function for HIT generation. 142 Forfeit of Perfect Forward Secrecy with the dropping of ephemeral 143 Diffie-Hellman. DEX provides of form of PFS. 145 Forfeit of digital signatures with the removal of a hash function. 146 Reliance of DH encryption of MAC key to prove ownership of the 147 private key. 149 Provide a Password Authentication within the exchange. This may 150 be supported by BEX as well, but not defined there. 152 Operate in an aggressive retransmission manner to deal with the 153 high packet loss nature of sensor networks. This retransmission 154 also provides an indirect acknowledgement of exchange completion. 156 1.1. The HIP Diet EXchange (DEX) 158 The HIP diet exchange is a two-party cryptographic protocol used to 159 establish communications context between hosts. The first party is 160 called the Initiator and the second party the Responder. The four- 161 packet design helps to make HIP DoS resilient. The protocol 162 transmits an Elliptic Curve encrypted key in the 3rd and 4th packets, 163 and authenticates the parties also in the 3rd and 4th packets. 164 Additionally, the Responder starts a puzzle exchange in the 2nd 165 packet, with the Initiator completing it in the 3rd packet before the 166 Responder stores any state from the exchange. 168 Thus DEX is operationally similar to BEX, just keyed more along the 169 lines of TLS. 171 The exchange can use the wrapped key to encrypt the Host Identity of 172 the Initiator in the 3rd packet (although Aura, et al., [AUR03] notes 173 that such operation may interfere with packet-inspecting 174 middleboxes), or the Host Identity may instead be sent unencrypted. 175 The Responder's Host Identity is not protected. It should be noted, 176 however, that both the Initiator's and the Responder's HITs are 177 transported as such (in cleartext) in the packets, allowing an 178 eavesdropper with a priori knowledge about the parties to verify 179 their identities. 181 Data packets start to flow after the 4th packet. HIP DEX does not 182 have an explicit transition for the Responder to connected state. 183 This is learned when the Responder starts receiving protected 184 datagrams, indicating that the Initiator received the R2 packet. As 185 such the Intiator should take care to NOT send the first data packet 186 until some delta time after it received the R2 packet. This is to 187 provide time for the Responder to process the R2 packet. 189 An existing HIP association can be updated using the update mechanism 190 defined in the BEX document [RFC5201-bis], and when the association 191 is no longer needed, it can be closed using the defined closing 192 mechanism. 194 Finally, HIP is designed as an end-to-end authentication and key 195 establishment protocol, to be used with Encapsulated Security Payload 196 (ESP) [RFC5202] and other end-to-end security protocols. The base 197 protocol does not cover all the fine-grained policy control found in 198 Internet Key Exchange (IKE) [RFC4306] that allows IKE to support 199 complex gateway policies. Thus, HIP is not a replacement for IKE. 201 1.2. Memo Structure 203 The rest of this memo is structured as follows. Section 2 defines 204 the central keywords, notation, and terms used throughout the rest of 205 the document. Section 4 gives an overview of the HIP base exchange 206 protocol. Section 6 define the rules for packet processing. 207 Finally, Sections 7, 8, and 9 discuss policy, security, and IANA 208 considerations, respectively. 210 2. Terms and Definitions 211 2.1. Requirements Terminology 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in RFC 2119 [RFC2119]. 217 2.2. Notation 219 [x] indicates that x is optional. 221 {x} indicates that x is encrypted. 223 X(y) indicates that y is a parameter of X. 225 i indicates that x exists i times. 227 --> signifies "Initiator to Responder" communication (requests). 229 <-- signifies "Responder to Initiator" communication (replies). 231 | signifies concatenation of information-- e.g., X | Y is the 232 concatenation of X with Y. 234 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 235 the mac function M on the input x. 237 3. The DEX Host Identifier Tag (HIT) and Its Representations 239 The DEX Host Identity Tag (HIT) is distinguished in two ways from the 240 BEX HIT: 242 The HIT SUITE ID Section 5.1.1 is ONLY a DEX ID. 244 The HIT DEX hit is not generated via a cryptographic hash. Rather 245 it is a truncation of the Elliptic Curve Host Identity. 247 3.1. Host Identity Tag (HIT) 249 The DEX Host Identity Tag is a 128-bit value -- a truncation of the 250 Host Identifier. There are two advantages of using a Host Identity 251 Tag over the actual Host Identity public key in protocols. Firstly, 252 its fixed length makes for easier protocol coding and also better 253 manages the packet size cost of this technology. Secondly, it 254 presents a consistent format to the protocol whatever underlying 255 identity technology is used. 257 BEX uses RFC 4843-bis [RFC4843-bis] specified 128-bit hash-based 258 identifiers, called Overlay Routable Cryptographic Hash Identifiers 259 (ORCHIDs). Their prefix, allocated from the IPv6 address block, is 260 defined in [RFC4843-bis]. 262 In DEX, a cryptographic hash is NOT used to form the HIT. Rather the 263 HI is truncated to 96 bits. 265 3.2. Generating a HIT from an HI 267 The DEX HIT is not an ORCHID, as there is no hash function in DEX. 268 Since a HI that is an ECDH key is directly computed from a random 269 number it is already collision resistant. The DEX HIT is the left- 270 truncated 96 bits of the HI. This 96 bit value is used in place of 271 the hash in the ORCHID. The HIT suite (see Section 9) is used for 272 the four bits of the Orchid Generation Algorithm (OGA) field in the 273 ORCHID. The same IPv6 prefix used in BEX is used for DEX. 275 4. Protocol Overview 277 The following material is an overview of the differences between the 278 BEX and DEX implementations of the HIP protocol. It is expected that 279 [RFC5201-bis] is well understood first. 281 4.1. Creating a HIP Association 283 By definition, the system initiating a HIP exchange is the Initiator, 284 and the peer is the Responder. This distinction is forgotten once 285 the base exchange completes, and either party can become the 286 Initiator in future communications. 288 The HIP Diet EXchange serves to manage the establishment of state 289 between an Initiator and a Responder. The first packet, I1, 290 initiates the exchange, and the last three packets, R1, I2, and R2, 291 constitute an authenticated secret key wrapped by a Diffie-Hellman 292 derived key for session key generation. The HIP association keys are 293 drawn from this keying material. If other cryptographic keys are 294 needed, e.g., to be used with ESP, they are expected to be drawn from 295 the same keying material. 297 The second packet, R1, starts the actual exchange. It contains a 298 puzzle -- a cryptographic challenge that the Initiator must solve 299 before continuing the exchange. The level of difficulty of the 300 puzzle can be adjusted based on level of trust with the Initiator, 301 current load, or other factors. The R1 also contains lists of 302 cryptographic algorithms supported by the Responder. Based on these 303 lists, the Initiator can continue, abort, or restart the base 304 exchange with a different selection of cryptographic algorithms. 306 In the I2 packet, the Initiator must display the solution to the 307 received puzzle. Without a correct solution, the I2 message is 308 discarded. The I2 also contains a key wrap parameter that carries 309 the key for the Responder. This key is only half the final session 310 key. The packet is MACed by the sender (Initiator). 312 The R2 packet finalizes the base exchange. The R2 contains a key 313 wrap parameter that carries the rest of the key for the Initiator. 314 The packet is MACed by the sender (Initiator). 316 The base exchange is illustrated below. The term "key" refers to the 317 Host Identity public key, "secret" refers to a random value encrypted 318 by a public key, and "sig" represents a signature using such a key. 319 The packets contain other parameters not shown in this figure. 321 Initiator Responder 323 I1: 324 --------------------------> 325 select precomputed R1 326 R1: puzzle, PK 327 <------------------------- 328 solve puzzle remain stateless 329 PK Encrypt x 330 I2: solution, PK, ECR(DH,secret x), mac 331 --------------------------> 332 check puzzle 333 check mac 334 PK Encrypt y 335 R2: PK, ECR(DH,secret y), mac 336 <-------------------------- 337 check mac 339 4.1.1. HIP Puzzle Mechanism 341 The purpose of the HIP puzzle mechanism is to protect the Responder 342 from a number of denial-of-service threats. It allows the Responder 343 to delay state creation until receiving I2. Furthermore, the puzzle 344 allows the Responder to use a fairly cheap calculation to check that 345 the Initiator is "sincere" in the sense that it has churned CPU 346 cycles in solving the puzzle. 348 DEX uses the CMAC function instead of a hash function as in BEX. 350 The puzzle mechanism has been explicitly designed to give space for 351 various implementation options. It allows a Responder implementation 352 to completely delay session-specific state creation until a valid I2 353 is received. In such a case, a correctly formatted I2 can be 354 rejected only once the Responder has checked its validity by 355 computing one CMAC function. On the other hand, the design also 356 allows a Responder implementation to keep state about received I1s, 357 and match the received I2s against the state, thereby allowing the 358 implementation to avoid the computational cost of the CMAC function. 359 The drawback of this latter approach is the requirement of creating 360 state. Finally, it also allows an implementation to use other 361 combinations of the space-saving and computation-saving mechanisms. 363 Generally speaking, the puzzle mechanism works in DEX the same as in 364 BEX. There are some implementation differences, using CMAC rather 365 than a hash. 367 See Appendix A for one possible implementation. Implementations 368 SHOULD include sufficient randomness to the algorithm so that 369 algorithmic complexity attacks become impossible [CRO03]. 371 4.1.2. Puzzle Exchange 373 The Responder starts the puzzle exchange when it receives an I1. The 374 Responder supplies a random number I, and requires the Initiator to 375 find a number J. To select a proper J, the Initiator must create the 376 concatenation of the HITs of the parties and J, and feed this 377 concatenation using I as the key into the CMAC algorithm. The lowest 378 order K bits of the result MUST be zeros. The value K sets the 379 difficulty of the puzzle. 381 To generate a proper number J, the Initiator will have to generate a 382 number of Js until one produces the CMAC target of zeros. The 383 Initiator SHOULD give up after exceeding the puzzle lifetime in the 384 PUZZLE parameter ([RFC5201-bis]). The Responder needs to re-create 385 the concatenation of the HITs and the provided J, and compute the 386 CMAC using I once to prove that the Initiator did its assigned task. 388 To prevent precomputation attacks, the Responder MUST select the 389 number I in such a way that the Initiator cannot guess it. 390 Furthermore, the construction MUST allow the Responder to verify that 391 the value was indeed selected by it and not by the Initiator. See 392 Appendix A for an example on how to implement this. 394 Using the Opaque data field in an ECHO_REQUEST_UNSIGNED parameter 395 ([RFC5201-bis]), the Responder can include some data in R1 that the 396 Initiator must copy unmodified in the corresponding I2 packet. The 397 Responder can generate the Opaque data in various ways; e.g., using 398 some secret, the sent I, and possibly other related data. Using the 399 same secret, the received I (from the I2), and the other related data 400 (if any), the Receiver can verify that it has itself sent the I to 401 the Initiator. The Responder MUST periodically change such a used 402 secret. 404 It is RECOMMENDED that the Responder generates a new puzzle and a new 405 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 406 Responder remembers an old puzzle at least 2*Lifetime seconds after 407 the puzzle has been deprecated. These time values allow a slower 408 Initiator to solve the puzzle while limiting the usability that an 409 old, solved puzzle has to an attacker. 411 4.1.3. HIP State Machine 413 The HIP protocol itself has little state. In HIP DEX, as in BEX, 414 there is an Initiator and a Responder. Once the security 415 associations (SAs) are established, this distinction is lost. If the 416 HIP state needs to be re-established, the controlling parameters are 417 which peer still has state and which has a datagram to send to its 418 peer. 420 The HIP DEX state machine has the same states as the BEX state 421 machine. However, there is an optional to implement aggresive 422 transmission feature to provide better performance in sensor networks 423 with high packet loss. the following documents the few differences in 424 the DEX state machine. 426 4.1.3.1. HIP Aggresive Transmission Mechanism 428 HIP DEX may be used on networks with high packet loss. DEX deals 429 with this by using an aggressive transmission practice for I1 and I2 430 packets. The Initiator SHOULD continually send I1 and I2 packets at 431 some short interval t msec, based on local policy. The transmission 432 stops on receipt of the corresponding R1 or R2 packet, which acts as 433 an acknowledgment receipt. 435 Since the Responder is stateless until it receives an I2, it does not 436 need any special behaviour on sending R1 other than to send one 437 whenever it receives an I1. The Responder sends an R2 after receipt 438 every I2. The Responder does need to know that R2 was received by 439 the Initiator. Like in BEX, the Responder can learn this when it 440 starts receiving datagrams. 442 4.1.3.2. HIP States 444 +---------------------+---------------------------------------------+ 445 | State | Explanation | 446 +---------------------+---------------------------------------------+ 447 | UNASSOCIATED | State machine start | 448 | | | 449 | I1-SENT | Initiating base exchange | 450 | | | 451 | I2-SENT | Waiting to complete base exchange | 452 | | | 453 | R2-SENT | Waiting to complete base exchange | 454 | | | 455 | ESTABLISHED | HIP association established | 456 | | | 457 | CLOSING | HIP association closing, no data can be | 458 | | sent | 459 | | | 460 | CLOSED | HIP association closed, no data can be sent | 461 | | | 462 | E-FAILED | HIP exchange failed | 463 +---------------------+---------------------------------------------+ 465 Table 1: HIP States 467 4.1.3.3. HIP State Processes 469 System behavior in state I1-SENT, Table 2. 471 +---------------------+-----------------------------+ 472 | Trigger | Action | 473 +---------------------+-----------------------------+ 474 | t msec | Send I1 and stay at I1-SENT | 475 +---------------------+-----------------------------+ 477 Table 2: I1-SENT - Initiating HIP 479 System behavior in state I2-SENT, Table 3. 481 +---------------------+-----------------------------+ 482 | Trigger | Action | 483 +---------------------+-----------------------------+ 484 | t msec | Send I2 and stay at I2-SENT | 485 +---------------------+-----------------------------+ 487 Table 3: I2-SENT - Waiting to finish HIP 489 System behavior in state R2-SENT, Table 4. 491 +----------------------+-----------------------------+ 492 | Trigger | Action | 493 +----------------------+-----------------------------+ 494 | Receive duplicate I2 | Send R2 and stay at R2-SENT | 495 +----------------------+-----------------------------+ 497 Table 4: R2-SENT - Waiting to finish HIP 499 4.1.3.4. Simplified HIP State Diagram 501 The following diagram shows the major state transitions. Transitions 502 based on received packets implicitly assume that the packets are 503 successfully authenticated or processed. 505 +-+ +------------------------------+ 506 I1 received, send R1 | | | | 507 | v v | 508 Datagram to send +--------------+ I2 received, send R2 | 509 Send I1 +--------------| UNASSOCIATED |--------------+ | 510 +-+ | +-+ +--------------+ | | 511 send | | | | | | | 512 I1 t | | | | | Alg. not supported, send I1 | | 513 msec v | v | v | | 514 +---------+ I2 received, send R2 | | 515 +---->| I1-SENT |-------------------------------------+ | | 516 | +---------+ | | | 517 | | +----------------------+ | | +-+receive | 518 | send I2+-+ | R1 received, | I2 received, send R2 | | | | |I2, | 519 | t msec | v v send I2 | v v v | v send R2 | 520 | +---------+ | +---------+ | 521 | +->| I2-SENT |------------+ | R2-SENT |<--+ | 522 | | +---------+ +---------+ | | 523 | | | | | | 524 | | | data| | | 525 | |receive | or| | | 526 | |R1, send | EC timeout| receive I2,| | 527 | |I2 |R2 received +--------------+ | send R2| | 528 | | +----------->| ESTABLISHED |<--------+ | | 529 | | +--------------+ | | 530 | | | | | receive I2, send R2 | | 531 | | recv+------------+ | +------------------------+ | 532 | | CLOSE,| | | | 533 | | send| No packet sent| | | 534 | | CLOSE_ACK| /received for | timeout | | 535 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 536 | | | CLOSE +--->| CLOSING |--+ retransmit | | 537 | | | +---------+ CLOSE | | 538 +--|------------|----------------------+| | | | | | 539 +------------|-----------------------+ | | +-----------------+ | 540 | | +-----------+ +-------------------|----+ 541 | +-----------+ | receive CLOSE, CLOSE_ACK | | 542 | | | send CLOSE_ACK received or | | 543 | | | timeout | | 544 | | | (UAL+MSL) | | 545 | v v | | 546 | +--------+ receive I2, send R2 | | 547 +-----------------------| CLOSED |----------------------------+ | 548 +--------+ /-------------------------+ 549 ^ | \-------/ timeout (UAL+2MSL), 550 | | move to UNASSOCIATED 551 +-+ 552 CLOSE received, send CLOSE_ACK 554 4.1.4. User Data Considerations 556 There is no difference in User Data Considerations between BEX and 557 DEX with one exception. Loss of state due to system reboot may be a 558 critical performance issue. Thus implementors MAY choose to use non- 559 volatile, secure storage for HIP state so it will survive system 560 reboot. This will limit state loss during reboots to only those 561 situtations that there is an SA timeout. 563 5. Packet Formats 565 5.1. HIP Parameters 567 The HIP Parameters are used to carry the public key associated with 568 the sender's HIT, together with related security and other 569 information. They consist of ordered parameters, encoded in TLV 570 format. 572 The following new parameter types are currently defined for DEX, in 573 addition to those defined for BEX. Also listed are BEX parameters 574 that have additional values for DEX. 576 For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and HOST_ID, 577 only the ECC values are valid in DEX. 579 +------------------+-------+----------+-----------------------------+ 580 | TLV | Type | Length | Data | 581 +------------------+-------+----------+-----------------------------+ 582 | HIP_MAC_3 | 61506 | variable | CMAC-based message | 583 | | | | authentication code, with | 584 | | | | key material from KEYMAT | 585 | | | | | 586 | HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT | 587 | | | | suites supported by the | 588 | | | | Responder | 589 +------------------+-------+----------+-----------------------------+ 591 5.1.1. HIT_SUITE_LIST 593 The HIT suites in DEX are limited to: 595 HIT suite ID 596 ECDH/DEX 8 598 The HIT_SUITE_LIST parameter contains a list of the supported HIT 599 suite IDs of the Responder. Since the HIT of the Initiator is a DEX 600 HIT, the Responder MUST only respond with a DEX HIT suite ID. 601 Currently, only one such suite ID has been defined. 603 5.1.2. HIP_MAC_3 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 | CMAC | 612 / / 613 / +-------------------------------+ 614 | | Padding | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Type 61506 618 Length length in octets, excluding Type, Length, and 619 Padding 620 CMAC CMAC computed over the HIP packet, excluding the 621 HIP_MAC parameter itself. The checksum field MUST 622 be set to zero and the HIP header length in the HIP 623 common header MUST be calculated not to cover any 624 excluded parameters when the CMAC is calculated. The 625 size of the CMAC is the natural size of the AES block 626 depending on the AES key size. 628 The CMAC calculation and verification process is presented in 629 Section 6.2.1. 631 5.2. HIP Packets 633 DEX uses the same eight basic HIP packets (see [RFC5201-bis]) as BEX. 634 Four are for the HIP exchange, one is for updating, one is for 635 sending notifications, and two are for closing a HIP association. 636 There are some differences in the HIP parameters in the exchange 637 packets between BEX and DEX. This section will cover the DEX 638 packets. 640 An important difference between BEX and DEX HIP packets is that there 641 is NO HIP_SIGNATURE available in DEX. Thus R1 is completely 642 unprotected and can be spoof. The I2, R2, UPDATE, NOTIFY, CLOSE, and 643 CLOSE_ACK only have HIP_MAC_3 for packet authentication The 644 processing of these packets are changed accordingly. 646 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 647 header. The Next Header field in the header indicates if there is 648 additional data following the HIP header. The HIP packet, however, 649 MUST NOT be fragmented. This limits the size of the possible 650 additional data in the packet. 652 5.2.1. I1 - the HIP Initiator Packet 654 The HIP header values for the I1 packet: 656 Header: 657 Packet Type = 1 658 SRC HIT = Initiator's HIT 659 DST HIT = Responder's HIT, or NULL 661 IP ( HIP ( DH_GROUP_LIST ) ) 663 Minimum size = 40 bytes 665 The I1 packet contains the fixed HIP header and the Initiator's 666 DH_GROUP_LIST. 668 Valid control bits: none 670 The Initiator HIT MUST be a DEX HIT. That is the HIT Suite ID MUST 671 be of a DEX type. Currently only ECDH/DEX is defined. 673 The Initiator gets the Responder's HIT either from a DNS lookup of 674 the Responder's FQDN, from some other repository, or from a local 675 table. The Responder's HIT MUST be a DEX HIT. If the Initiator does 676 not know the Responder's HIT, it may attempt to use opportunistic 677 mode by using NULL (all zeros) as the Responder's HIT. See also "HIP 678 Opportunistic Mode" [RFC5201-bis]. 680 Since this packet is so easy to spoof even if it were signed, no 681 attempt is made to add to its generation or processing cost. 683 The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform 684 the Responder of its preferred DH Group IDs. Only ECDH Groups may be 685 included in this list. Note that the DH_GROUP_LIST in the I1 packet 686 is not protected by a MAC. 688 Implementations MUST be able to handle a storm of received I1 689 packets, discarding those with common content that arrive within a 690 small time delta, but distinguishing this from arriving at a set time 691 delta. This behaviour is the expected behaviour for an Initiator on 692 a network with high packet loss. The HIP state machine calls out 693 this behaviour in this case and the Initiator will stop sending I1 694 packets after it receives an R1 packet. 696 5.2.2. R1 - the HIP Responder Packet 698 The HIP header values for the R1 packet: 700 Header: 701 Packet Type = 2 702 SRC HIT = Responder's HIT 703 DST HIT = Initiator's HIT 705 IP ( HIP ( [ R1_COUNTER, ] 706 PUZZLE, 707 HIP_CIPHER, 708 HOST_ID, 709 HIT_SUITE_LIST, 710 DH_GROUP_LIST, 711 [ <, ECHO_REQUEST_UNSIGNED >i ]) 713 Minimum size = 120 bytes 715 Valid control bits: A 717 If the Responder's HI is an anonymous one, the A control MUST be set. 719 The Initiator's HIT MUST match the one received in I1. If the 720 Responder has multiple HIs, the Responder's HIT used MUST match 721 Initiator's request. If the Initiator used opportunistic mode, the 722 Responder may select freely among its HIs. See also "HIP 723 Opportunistic Mode" [RFC5201-bis]. 725 The R1 generation counter is used to determine the currently valid 726 generation of puzzles. The value is increased periodically, and it 727 is RECOMMENDED that it is increased at least as often as solutions to 728 old puzzles are no longer accepted. 730 The Puzzle contains a Random #I and the difficulty K. The difficulty 731 K indicates the number of lower-order bits, in the puzzle CMAC 732 result, that must be zeros; see Section 4.1.2. 734 The Initiator HIT does not provide the HOST_ID key size. The 735 Responder selects its HOST_ID based on the Initiator's preference 736 expressed in the DH_GROUP_LIST parameter in the I1. The Responder 737 sends back its own preference based on which it chose the HOST_ID as 738 DH_GROUP_LIST. This allows the Initiator to determine whether its 739 own DH_GROUP_LIST in the I1 was manipulated by an attacker. There is 740 a further risk that the Responder's DH_GROUP_LIST was manipulated by 741 an attacker, as R1 cannot be authenticated in DEX as it can in BEX. 742 Thus it is repeated in R2 allowing for a final check at that point. 744 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 745 discarded. 747 The HIP_CIPHER contains the encryption algorithms supported by the 748 Responder to protect the key exchange, in the order of preference. 749 All implementations MUST support the AES-CBC [RFC3602]. 751 The ECHO_REQUEST_UNSIGNED contains data that the sender wants to 752 receive unmodified in the corresponding response packet in the 753 ECHO_RESPONSE_UNSIGNED parameter. 755 5.2.3. I2 - the Second HIP Initiator Packet 757 The HIP header values for the I2 packet: 759 Header: 760 Type = 3 761 SRC HIT = Initiator's HIT 762 DST HIT = Responder's HIT 764 IP ( HIP ( [R1_COUNTER,] 765 SOLUTION, 766 HIP_CIPHER, 767 HOST_ID, 768 ENCRYPTED {DH, secret-x|I}, 769 [ ENCRYPTED {secret, ENCRYPTED {passwd, challenge } },] 770 HIP_MAC_3, 771 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 773 Minimum size = 180 bytes 775 Valid control bits: A 777 The HITs used MUST match the ones used previously. 779 If the Initiator's HI is an anonymous one, the A control MUST be set. 781 The Initiator MAY include an unmodified copy of the R1_COUNTER 782 parameter received in the corresponding R1 packet into the I2 packet. 784 The Solution contains the Random #I from R1 and the computed #J. The 785 low-order K bits of the CMAC(S, | ... | J) MUST be zero. 787 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 788 discarded. 790 The HIP_CIPHER contains the single encryption transform selected by 791 the Initiator, that will be used to protect the HI exchange. The 792 chosen transform MUST correspond to one offered by the Responder in 793 the R1. All implementations MUST support the AES-CBC transform 794 [RFC3602]. 796 The ECHO_RESPONSE_UNSIGNED contain the unmodified Opaque data copied 797 from the corresponding echo request parameter. 799 The ENCRYPTED contains an Initiator generated random secret x that 800 MUST be uniformly distributed that is concatenated with I from the 801 puzzle. The secret x's length matches the keysize of the selected 802 encryption transform. I from the puzzle is used as the IV in the 803 encryption transform. This acts as a nonce from the Responder to 804 prove freshness of the secret wrapping from the Initiator. I in the 805 ENCRYPTED block enables the Responder to validate a proper decryption 806 of the block. The key for the encryption is the Diffie-Hellman 807 derived key. It is converted to the size needed for the encryption 808 transform by using CMAC(0^n, DH|I) where n is the needed key size. 809 Including I as a nonce in the key construction is similar to the 810 recommendation in NIST 800-56A, section 6.3.2 for making a unique 811 derived key with each use of a Static/Static Diffie-Hellman exchange. 813 If the Initiator has prior knowledge that the Responder is expecting 814 a password authenication, the Initiator encrypts the 815 ECHO_REQUEST_UNSIGNED with the password, then wraps the ENCRYPTED 816 parameter in the secret x. I from the puzzle is used as the nonce 817 here as well. There is no signal within R1 for this behaviour. 818 Knowledge of password authencation must be externally configured. 820 The MAC is calculated over the whole HIP envelope, excluding any 821 parameters after the HIP_MAC_3, as described in Section 6.2.1. The 822 Responder MUST validate the HIP_MAC_3. 824 5.2.4. R2 - the Second HIP Responder Packet 826 The HIP header values for the R2 packet: 828 Header: 829 Packet Type = 4 830 SRC HIT = Responder's HIT 831 DST HIT = Initiator's HIT 833 IP ( HIP ( DH_GROUP_LIST, 834 ENCRYPTED {DH, secret-y|I}, 835 HIP_MAC_3) 837 Minimum size = 108 bytes 839 Valid control bits: none 841 The Responder repeats the DH_GROUP_LIST parameter in R2. This MUST 842 be the same list as included in R1. The DH_GROUP_LIST parameter is 843 repeated here because R2 is MACed and thus cannot be altered by an 844 attacker. This allows the Initiator to determine whether its own 845 DH_GROUP_LIST in the I1 was manipulated by an attacker. 847 The ENCRYPTED contains an Responder generated random secret y that 848 MUST be uniformly distributed that is concatenated with I from the 849 puzzle. The secret y's length matches the keysize of the selected 850 encryption transform. I from the puzzle is used as the IV in the 851 encryption transform. This acts as a nonce from the Initiator to 852 prove freshness of the secret wrapping from the Responder. I in the 853 ENCRYPTED block enables the Responder to validate a proper decryption 854 of the block. The key for the encryption is the Diffie-Hellman 855 derived key. It is converted to the size needed for the encryption 856 transform by using CMAC(0^n, DH|I) where n is the needed key size. 857 Including I as a nonce in the key construction is similar to the 858 recommendation in NIST 800-56A, section 6.3.2 for making a unique 859 derived key with each use of a Static/Static Diffie-Hellman exchange. 861 The HIP_MAC_3 is calculated over the whole HIP envelope, with 862 Responder's HOST_ID parameter concatenated with the HIP envelope. 863 The HOST_ID parameter is removed after the CMAC calculation. The 864 procedure is described in Section 6.2.1. 866 The Initiator MUST validate the HIP_MAC_3. 868 5.3. ICMP Messages 870 When a HIP implementation detects a problem with an incoming packet, 871 and it either cannot determine the identity of the sender of the 872 packet or does not have any existing HIP association with the sender 873 of the packet, it MAY respond with an ICMP packet. Any such replies 874 MUST be rate-limited as described in [RFC2463]. In most cases, the 875 ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 876 for ICMPv6), with the Pointer field pointing to the field that caused 877 the ICMP message to be generated. 879 6. Packet Processing 881 Each host is assumed to have a single HIP protocol implementation 882 that manages the host's HIP associations and handles requests for new 883 ones. Each HIP association is governed by a conceptual state 884 machine, with states defined above in Section 4.1.3. The HIP 885 implementation can simultaneously maintain HIP associations with more 886 than one host. Furthermore, the HIP implementation may have more 887 than one active HIP association with another host; in this case, HIP 888 associations are distinguished by their respective HITs. It is not 889 possible to have more than one HIP association between any given pair 890 of HITs. Consequently, the only way for two hosts to have more than 891 one parallel association is to use different HITs, at least at one 892 end. 894 6.1. Solving the Puzzle 896 This subsection describes the puzzle-solving details. 898 In R1, the values I and K are sent in network byte order. Similarly, 899 in I2, the values I and J are sent in network byte order. The mac is 900 created by concatenating, in network byte order, the following data, 901 in the following order and using the CMAC algorithm with I as the 902 key: 904 128-bit Initiator's HIT, in network byte order, as appearing in 905 the HIP Payload in R1 and I2. 907 128-bit Responder's HIT, in network byte order, as appearing in 908 the HIP Payload in R1 and I2. 910 n-bit random value J (where n is CMAC-len), in network byte order, 911 as appearing in I2. 913 In order to be a valid response puzzle, the K low-order bits of the 914 resulting CMAC must be zero. 916 Notes: 918 i) All the data in the CMAC input MUST be in network byte order. 920 ii) The order of the Initiator's and Responder's HITs are 921 different in the R1 and I2 packets; see [RFC5201-bis]. Care must 922 be taken to copy the values in the right order to the CMAC input. 924 The following procedure describes the processing steps involved, 925 assuming that the Responder chooses to precompute the R1 packets: 927 Precomputation by the Responder: 928 Sets up the puzzle difficulty K. 929 Creates a R1 and caches it. 931 Responder: 932 Selects a suitable cached R1. 933 Generates a random number I. 934 Sends I and K in an R1. 935 Saves I and K for a Delta time. 937 Initiator: 938 Generates repeated attempts to solve the puzzle until a matching J 939 is found: 940 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 941 Sends I and J in an I2. 943 Responder: 944 Verifies that the received I is a saved one. 945 Finds the right K based on I. 946 Computes V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 947 Rejects if V != 0 948 Accept if V == 0 950 6.2. HIP_MAC Calculation and Verification 952 The following subsections define the actions for processing the 953 HIP_MAC_3 parameter. 955 6.2.1. CMAC Calculation 957 Both the Initiator and the Responder should take some care when 958 verifying or calculating the HIP_MAC_3. Specifically, the Responder 959 should preserve other parameters than the HOST_ID when sending the 960 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 961 was received in the R1 packet. 963 The scope of the calculation for HIP_MAC_3 is: 965 CMAC: { HIP header | [ Parameters ] } 967 where Parameters include all HIP parameters of the packet that is 968 being calculated with Type values from 1 to (HIP_MAC's Type value - 969 1) and exclude parameters with Type values greater or equal to 970 HIP_MAC's Type value. 972 During HIP_MAC calculation, the following applies: 974 o In the HIP header, the Checksum field is set to zero. 976 o In the HIP header, the Header Length field value is calculated to 977 the beginning of the HIP_MAC parameter. 979 Parameter order is described in [RFC5201-bis]. 981 The HIP_MAC parameter is defined in Section 5.1.2. The CMAC 982 calculation and verification process is as follows: 984 Packet sender: 986 1. Create the HIP packet, without the HIP_MAC or any other parameter 987 with greater Type value than the HIP_MAC parameter has. 989 2. Calculate the Header Length field in the HIP header. 991 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 992 retrieved from KEYMAT as defined in Section 6.3. 994 4. Add the HIP_MAC_3 parameter to the packet and any parameter with 995 greater Type value than the HIP_MAC's (HIP_MAC_3's) that may 996 follow. 998 5. Recalculate the Length field in the HIP header. 1000 Packet receiver: 1002 1. Verify the HIP header Length field. 1004 2. Remove the HIP_MAC_3 parameter, as well as all other parameters 1005 that follow it with greater Type value, saving the contents if 1006 they will be needed later. 1008 3. Recalculate the HIP packet length in the HIP header and clear the 1009 Checksum field (set it to all zeros). 1011 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1012 defined in Section 6.3 and verify it against the received CMAC. 1014 5. Set Checksum and Header Length field in the HIP header to 1015 original values. 1017 6.3. HIP KEYMAT Generation 1019 HIP DEX keying material is derived from encrypted secrets in I2 and 1020 R2. The Responder has the keying material during the creation of the 1021 R2 packet, and the Initiator has it once it receives the R2 packet. 1022 This is why R2 can already contain encrypted information. 1024 The KEYMAT is derived by feeding the keying material into the 1025 following operation; the | operation denotes concatenation. 1027 CKDF-Expand(PRK, info, L) -> OKM 1029 where 1031 info = sort(HIT-I | HIT-R) 1032 PRK = x | y 1033 PRKlen = Length of PRK in octets 1034 maclen = Length of CMAC in octets 1035 L length of output keying material in octets 1036 (<= 255*macLen) 1038 If PRKlen != macLen then PRK = CMAC(0^128, PRK) 1040 The output OKM is calculated as follows: 1042 N = ceil(L/macLen) 1043 T = T(1) | T(2) | T(3) | ... | T(N) 1044 OKM = first L octets of T 1046 where: 1048 T(0) = empty string (zero length) 1049 T(1) = CMAC(PRK, T(0) | info | 0x01) 1050 T(2) = CMAC(PRK, T(1) | info | 0x02) 1051 T(3) = CMAC(PRK, T(2) | info | 0x03) 1052 ... 1054 (where the constant concatenated to the end of each T(n) is a 1055 single octet.) 1057 Sort(HIT-I | HIT-R) is defined as the network byte order 1058 concatenation of the two HITs, with the smaller HIT preceding the 1059 larger HIT, resulting from the numeric comparison of the two HITs 1060 interpreted as positive (unsigned) 128-bit integers in network byte 1061 order. 1063 x and y values are from the ENCRYPTED parameters from I2 and R2 1064 respectively when this HIP association was set up. For the I2 1065 packet, value y is NULL. 1067 The initial keys are drawn sequentially in the order that is 1068 determined by the numeric comparison of the two HITs, with comparison 1069 method described in the previous paragraph. HOST_g denotes the host 1070 with the greater HIT value, and HOST_l the host with the lower HIT 1071 value. 1073 The drawing order for initial keys: 1075 HIP-gl encryption key for HOST_g's outgoing HIP packets 1077 HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1079 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 1080 packets 1082 HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1084 The number of bits drawn for a given algorithm is the "natural" size 1085 of the keys. For the mandatory algorithms, the following sizes 1086 apply: 1088 AES 128 or 256 bits 1090 If other key sizes are used, they must be treated as different 1091 encryption algorithms and defined separately. 1093 6.4. Processing Incoming I1 Packets 1095 An implementation SHOULD reply to an I1 with an R1 packet, unless the 1096 implementation is unable or unwilling to set up a HIP association. 1097 An I1 in DEX is handled identically to BEX with the exception that in 1098 constructing the R1, the Responder SHOULD select a HIT that is 1099 constructed with the MUST algorithm, which is currently ECDH. 1101 6.4.1. R1 Management 1103 All compliant implementations MUST produce R1 packets. An R1 in DEX 1104 is handled identically to BEX. 1106 6.5. Processing Incoming R1 Packets 1108 A system receiving an R1 MUST first check to see if it has sent an I1 1109 to the originator of the R1 (i.e., it is in state I1-SENT). An R1 in 1110 DEX is handled identically to BEX with the following differences. 1112 If the system has been sending out a stream of I1 packets to work 1113 around high packet loss on a network, it stops sending the I1 packets 1114 AFTER successfully processing the R1 packet. 1116 There is no HIP_SIGNATURE on this packet. This is an 1117 unauthentication packet. 1119 The following steps define the conceptual processing rules for 1120 responding to an R1 packet that are different than in BEX: 1122 1. If the system is configured with a authentication password for 1123 the responder, it constructs the autentication response to 1124 include in the I2. 1126 2. The system prepares and sends an I2, as described in 1127 Section 5.2.3. The system MAY be configured to continually send 1128 this I2 until it receives and validates an R2. 1130 6.6. Processing Incoming I2 Packets 1132 Upon receipt of an I2, the system MAY perform initial checks to 1133 determine whether the I2 corresponds to a recent R1 that has been 1134 sent out, if the Responder keeps such state. An I2 in DEX is handled 1135 identically to BEX with the following differences. 1137 The HIP implementation SHOULD process the I2. This includes 1138 validation of the puzzle solution, extracting the ENCRYPTED key for 1139 processing I2, decrypting the Initiator's Host Identity, verifying 1140 the mac, creating state, and finally sending an R2. 1142 There is no HIP_SIGNATURE on this packet. Authentication is 1143 completely based on the HIP_MAC_3 parameter. 1145 The following steps define the conceptual processing rules for 1146 responding to an I2 packet: 1148 1. If the system's state machine is in the I2-SENT state, the system 1149 makes a comparison between its local and sender's HITs (similarly 1150 as in Section 6.3). If the local HIT is smaller than the 1151 sender's HIT, it should drop the I2 packet, and continue using 1152 the R1 received and I2 sent to the peer earlier. Otherwise, the 1153 system should process the received I2 packet and drop any 1154 previously derived Diffie-Hellman keying material Kij and 1155 ENCRYPTED keying material it might have formed upon sending the 1156 I2 previously. The peer Diffie-Hellman key, ENCRYPTED keying 1157 material and the nonce J are taken from the just arrived I2 1158 packet. The local Diffie-Hellman key and the nonce I are the 1159 ones that were earlier sent in the R1 packet. 1161 2. The system MUST validate the solution to the puzzle by computing 1162 the mac described in Section 5.2.3 using the CMAC algorithm. 1164 3. The system must extract the keying material from the ENCRYPTED 1165 parameter. This key is used to derive the I2 HIP association 1166 keys, as described in Section 6.3. 1168 4. If the checks above are valid, then the system proceeds with 1169 further I2 processing; otherwise, it discards the I2 and its 1170 state machine remains in the same state. If the system has been 1171 sending a stream of R1 packets to the HIT in the I2 the system 1172 stops sending the R1s. 1174 6.7. Processing Incoming R2 Packets 1176 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1177 results in the R2 being dropped and the state machine staying in the 1178 same state. If an R2 is received in state I2-SENT, it SHOULD be 1179 processed. 1181 There is no HIP_SIGNATURE on this packet. Authentication is 1182 completely based on the HIP_MAC_3 parameter. 1184 The conceptual processing rules for an incoming R2 packet in DEX are 1185 identical to BEX with the following differences. 1187 1. The system checks the DH_GROUP_LIST as in R1 packet processing. 1188 If the list is different from R1's there may have been a DH 1189 downgrade attack against the unprotected R1 packet. If the 1190 DH_GROUP_LIST presents a better list than recieved in the R1 1191 packet, the system may either resend I1 within the retry bounds 1192 or abandon the HIP exchange. 1194 2. The system must extract the keying material from the ENCRYPTED 1195 parameter. This key is concatanated with that sent in the I2 1196 packet to form the HIP association keys, as described in 1197 Section 6.3. 1199 6.8. Sending UPDATE Packets 1201 A host sends an UPDATE packet when it wants to update some 1202 information related to a HIP association. DEX UPDATE handling is the 1203 similar in DEX as in BEX. The key difference is NO HIP_SIGNATURE. 1205 6.9. Handling State Loss 1207 In the case of system crash and unanticipated state loss, the system 1208 SHOULD delete the corresponding HIP state, including the keying 1209 material. That is, the state SHOULD NOT be stored on stable storage. 1210 If the implementation does drop the state (as RECOMMENDED), it MUST 1211 also drop the peer's R1 generation counter value, unless a local 1212 policy explicitly defines that the value of that particular host is 1213 stored. An implementation MUST NOT store R1 generation counters by 1214 default, but storing R1 generation counter values, if done, MUST be 1215 configured by explicit HITs. 1217 7. HIP Policies 1219 There are a number of variables that will influence the HIP exchanges 1220 that each host must support. All HIP implementations MUST support 1221 more than one simultaneous HI, at least one of which SHOULD be 1222 reserved for anonymous usage. Although anonymous HIs will be rarely 1223 used as Responders' HIs, they will be common for Initiators. Support 1224 for more than two HIs is RECOMMENDED. 1226 Many Initiators would want to use a different HI for different 1227 Responders. The implementations SHOULD provide for an ACL of 1228 Initiator's HIT to Responder's HIT. This ACL SHOULD also include 1229 preferred transform and local lifetimes. 1231 The value of K used in the HIP R1 packet can also vary by policy. K 1232 should never be greater than 20, but for trusted partners it could be 1233 as low as 0. 1235 Responders would need a similar ACL, representing which hosts they 1236 accept HIP exchanges, and the preferred transform and local 1237 lifetimes. Wildcarding SHOULD be supported for this ACL also. 1239 8. Security Considerations 1241 HIP is designed to provide secure authentication of hosts. HIP also 1242 attempts to limit the exposure of the host to various denial-of- 1243 service and man-in-the-middle (MitM) attacks. In so doing, HIP 1244 itself is subject to its own DoS and MitM attacks that potentially 1245 could be more damaging to a host's ability to conduct business as 1246 usual. 1248 HIP DEX replaces the SIGMA authenticated Diffie-Hellman key exchange 1249 of BEX with a random generated key exchange encrypted by a Diffie- 1250 Hellman derived key. Both the Initiator and Responder contribute to 1251 this key. 1253 The strength of the key is based on the quality of the secrets 1254 generated the Initiator and Responder. Since the Initiator is 1255 commonly a sensor there is a natural concern about the quality of 1256 its random number generator. 1258 DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1259 compromised, ALL HIP connections protected with that HI are 1260 compromised. 1262 The puzzle mechanism using CMAC may need further study that it 1263 does present the desired level of difficulty. 1265 The DEX HIT extraction MAY present new attack opportunities; 1266 further study is needed. 1268 The R1 packet is unprotected and offers an attacker new resource 1269 attacks against the Initiator. This is mitigated by the Initator 1270 only processing a received R1 when it has sent an I1. This is 1271 another DoS attack, but for battery powered Initiators, it could be a 1272 concern. 1274 9. IANA Considerations 1276 IANA has reserved protocol number 139 for the Host Identity Protocol. 1278 The following HIT suites are defined for DEX HIT generation. 1280 +-------+------------+----------------------+-----------------------+ 1281 | Index | Hash | Signature algorithm | Description | 1282 | | function | family | | 1283 +-------+------------+----------------------+-----------------------+ 1284 | 5 | LTRUNC | ECDH | ECDH HI truncated to | 1285 | | | | 96 bits | 1286 +-------+------------+----------------------+-----------------------+ 1288 Table 5: HIT Suites 1290 10. Acknowledgments 1292 The drive to put HIP on a cryptographic 'Diet' came out of a number 1293 of discussions with sensor vendors at IEEE 802.15 meetings. David 1294 McGrew was very 1296 11. References 1298 11.1. Normative References 1300 [RFC2119] Bradner, S., "Key words for use in RFCs to 1301 Indicate Requirement Levels", BCP 14, RFC 2119, 1302 March 1997. 1304 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 1305 Version 6 (IPv6) Specification", RFC 2460, 1306 December 1998. 1308 [RFC2463] Conta, A. and S. Deering, "Internet Control 1309 Message Protocol (ICMPv6) for the Internet 1310 Protocol Version 6 (IPv6) Specification", 1311 RFC 2463, December 1998. 1313 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES- 1314 CBC Cipher Algorithm and Its Use with IPsec", 1315 RFC 3602, September 2003. 1317 [RFC3972] Aura, T., "Cryptographically Generated 1318 Addresses (CGA)", RFC 3972, March 2005. 1320 [RFC4309] Housley, R., "Using Advanced Encryption 1321 Standard (AES) CCM Mode with IPsec 1322 Encapsulating Security Payload (ESP)", 1323 RFC 4309, December 2005. 1325 [RFC4843-bis] Nikander, P., Laganier, J., and F. Dupont, 1326 "STUB: An IPv6 Prefix for Overlay Routable 1327 Cryptographic Hash Identifiers (ORCHID)", 1328 draft-laganier-rfc4843-bis-00 (work in 1329 progress), February 2010. 1331 [RFC5201-bis] Moskowitz, R., Jokela, P., Henderson, T., and 1332 T. Heer, "Host Identity Protocol", 1333 draft-moskowitz-hip-rfc5201-bis-01 (work in 1334 progress), July 2010. 1336 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, 1337 "Using the Encapsulating Security Payload (ESP) 1338 Transport Format with the Host Identity 1339 Protocol (HIP)", RFC 5202, April 2008. 1341 [fundamental-ecc] McGrew, D. and K. Igoe, "Fundamental Elliptic 1342 Curve Cryptography Algorithms", 1343 draft-mcgrew-fundamental-ecc-02 (work in 1344 progress), February 2010. 1346 11.2. Informative References 1348 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 1349 "Analysis of the HIP Base Exchange Protocol", 1350 in Proceedings of 10th Australasian Conference 1351 on Information Security and Privacy, July 2003. 1353 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service 1354 via Algorithmic Complexity Attacks", in 1355 Proceedings of Usenix Security Symposium 2003, 1356 Washington, DC., August 2003. 1358 [IEEE.802-15-4.2006] "Information technology - Telecommunications 1359 and information exchange between systems - 1360 Local and metropolitan area networks - Specific 1361 requirements - Part 15.4: Wireless Medium 1362 Access Control (MAC) and Physical Layer (PHY) 1363 Specifications for Low-Rate Wireless Personal 1364 Area Networks (WPANs)", IEEE Standard 802.15.4, 1365 September 2006, . 1368 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for 1369 Writing an IANA Considerations Section in 1370 RFCs", BCP 26, RFC 2434, October 1998. 1372 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) 1373 Protocol", RFC 4306, December 2005. 1375 [rfc4423-bis] Moskowitz, R., "Host Identity Protocol 1376 Architecture", 1377 draft-moskowitz-hip-rfc4423-bis-01 (work in 1378 progress), June 2010. 1380 Appendix A. Using Responder Puzzles 1382 As mentioned in Section 4.1.1, the Responder may delay state creation 1383 and still reject most spoofed I2s by using a number of pre-calculated 1384 R1s and a local selection function. This appendix defines one 1385 possible implementation in detail. The purpose of this appendix is 1386 to give the implementors an idea on how to implement the mechanism. 1387 If the implementation is based on this appendix, it MAY contain some 1388 local modification that makes an attacker's task harder. 1390 The Responder creates a secret value S, that it regenerates 1391 periodically. The Responder needs to remember the two latest values 1392 of S. Each time the S is regenerated, the R1 generation counter 1393 value is incremented by one and the Responder generates an R1 packet. 1395 When the Initiator sends the I1 packet for initializing a connection, 1396 the Responder gets the HIT and IP address from the packet, and 1397 generates an I value for the puzzle. 1399 I value calculation: 1400 I = Ltrunc( CMAC ( S, HIT-I | HIT-R | IP-I | IP-R ), n) 1401 where n = CMAC-len 1403 From an incoming I2 packet, the Responder gets the required 1404 information to validate the puzzle: HITs, IP addresses, and the 1405 information of the used S value from the R1_COUNTER. Using these 1406 values, the Responder can regenerate the I, and verify it against the 1407 I received in the I2 packet. If the I values match, it can verify 1408 the solution using I, J, and difficulty K. If the I values do not 1409 match, the I2 is dropped. 1411 puzzle_check: 1412 V := Ltrunc( CMAC( I2.I | I2.I, I2.hit_i | I2.hit_r | I2.J ), K ) 1413 if V != 0, drop the packet 1415 If the puzzle solution is correct, the I and J values are stored for 1416 later use. They are used as input material when keying material is 1417 generated. 1419 Keeping state about failed puzzle solutions depends on the 1420 implementation. Although it is possible for the Responder not to 1421 keep any state information, it still may do so to protect itself 1422 against certain attacks (see Section 4.1.1). 1424 Appendix B. Generating a Public Key Encoding from an HI 1426 The following pseudo-code illustrates the process to generate a 1427 public key encoding from an HI for ECDH. 1429 Author's Address 1431 Robert Moskowitz 1432 ICSA labs, An Independent Division of Verizon Business 1433 1000 Bent Creek Blvd, Suite 200 1434 Mechanicsburg, PA 1435 USA 1437 EMail: robert.moskowitz@icsalabs.com