idnits 2.17.1 draft-moskowitz-hip-rg-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 ([RFC5201-bis]), 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 (June 29, 2010) is 5050 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 1305, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 1318, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1358, 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 ICSAlabs 4 Intended status: Standards Track June 29, 2010 5 Expires: December 31, 2010 7 HIP Diet EXchange (DEX) 8 draft-moskowitz-hip-rg-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 primatives as possible yet still deliver the same class of 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 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 December 31, 2010. 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 . . . . . . . . . . . . . . . . . . . . 6 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-CCM 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 More intro. 158 1.1. The HIP Diet EXchange (DEX) 160 The HIP diet exchange is a two-party cryptographic protocol used to 161 establish communications context between hosts. The first party is 162 called the Initiator and the second party the Responder. The four- 163 packet design helps to make HIP DoS resilient. The protocol 164 transmits an Elliptic Curve encrypted key in the 3rd and 4th packets, 165 and authenticates the parties also in the 3rd and 4th packets. 167 Additionally, the Responder starts a puzzle exchange in the 2nd 168 packet, with the Initiator completing it in the 3rd packet before the 169 Responder stores any state from the exchange. 171 Thus DEX is operationally similar to BEX, just keyed more along the 172 lines of TLS. 174 The exchange can use the wrapped key to encrypt the Host Identity of 175 the Initiator in the 3rd packet (although Aura, et al., [AUR03] notes 176 that such operation may interfere with packet-inspecting 177 middleboxes), or the Host Identity may instead be sent unencrypted. 178 The Responder's Host Identity is not protected. It should be noted, 179 however, that both the Initiator's and the Responder's HITs are 180 transported as such (in cleartext) in the packets, allowing an 181 eavesdropper with a priori knowledge about the parties to verify 182 their identities. 184 Data packets start to flow after the 4th packet. HIP DEX does not 185 have an explicit transition for the Responder to connected state. 186 This is learned when the Responder starts receiving protected 187 datagrams, indicating that the Initiator recieved the R2 packet. As 188 such the Intiator should take care to NOT send the first data packet 189 until some delta time after it received the R2 packet. This is to 190 provide time for the Responder to process the R2 packet. 192 An existing HIP association can be updated using the update mechanism 193 defined in the BEX document [RFC5201-bis], and when the association 194 is no longer needed, it can be closed using the defined closing 195 mechanism. 197 Finally, HIP is designed as an end-to-end authentication and key 198 establishment protocol, to be used with Encapsulated Security Payload 199 (ESP) [RFC5202] and other end-to-end security protocols. The base 200 protocol does not cover all the fine-grained policy control found in 201 Internet Key Exchange (IKE) [RFC4306] that allows IKE to support 202 complex gateway policies. Thus, HIP is not a replacement for IKE. 204 1.2. Memo Structure 206 The rest of this memo is structured as follows. Section 2 defines 207 the central keywords, notation, and terms used throughout the rest of 208 the document. Section 4 gives an overview of the HIP base exchange 209 protocol. Section 6 define the rules for packet processing. 210 Finally, Sections 7, 8, and 9 discuss policy, security, and IANA 211 considerations, respectively. 213 2. Terms and Definitions 215 2.1. Requirements Terminology 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in RFC 2119 [RFC2119]. 221 2.2. Notation 223 [x] indicates that x is optional. 225 {x} indicates that x is encrypted. 227 X(y) indicates that y is a parameter of X. 229 i indicates that x exists i times. 231 --> signifies "Initiator to Responder" communication (requests). 233 <-- signifies "Responder to Initiator" communication (replies). 235 | signifies concatenation of information-- e.g., X | Y is the 236 concatenation of X with Y. 238 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 239 the mac function M on the input x. 241 3. The DEX Host Identifier Tag (HIT) and Its Representations 243 The DEX Host Identity Tag (HIT) is distinguished in two ways from the 244 BEX HIT: 246 The HIT SUITE ID Section 5.1.1 is ONLY a DEX ID. 248 The HIT DEX hit is not generated via a cryptographic hash. Rather 249 it is a truncation of the Elliptic Curve Host Identity. 251 3.1. Host Identity Tag (HIT) 253 The DEX Host Identity Tag is a 128-bit value -- an encryption of a 254 known randon number by the Host Identifier. There are two advantages 255 of using a Host Identity Tag over the actual Host Identity public key 256 in protocols. Firstly, its fixed length makes for easier protocol 257 coding and also better manages the packet size cost of this 258 technology. Secondly, it presents a consistent format to the 259 protocol whatever underlying identity technology is used. 261 BEX uses RFC 4843-bis [RFC4843-bis] specified 128-bit hash-based 262 identifiers, called Overlay Routable Cryptographic Hash Identifiers 263 (ORCHIDs). Their prefix, allocated from the IPv6 address block, is 264 defined in [RFC4843-bis]. 266 In DEX, a cryptographic hash is NOT used to form the HIT. Rather the 267 HI is truncated to 96 bits. 269 3.2. Generating a HIT from an HI 271 The DEX HIT, unlike the BEX HIT, is generated similarly to the ORCHID 272 generation method described in [RFC4843-bis]. Since a HI that is an 273 ECDH key is directly computed from a random number it is already 274 collision resistant. Thus the HI is left-truncated at 96 bits. This 275 96 bit value is used in place of the hash in the ORCHID. The HIT 276 suite (see Section 9) is used for the four bits of the Orchid 277 Generation Algorithm (OGA) field in the ORCHID. 279 4. Protocol Overview 281 The following material is an overview of the differences between the 282 BEX and DEX implementations of the HIP protocol. It is expected that 283 [RFC5201-bis] is well understood first. 285 4.1. Creating a HIP Association 287 By definition, the system initiating a HIP exchange is the Initiator, 288 and the peer is the Responder. This distinction is forgotten once 289 the base exchange completes, and either party can become the 290 Initiator in future communications. 292 The HIP Diet EXchange serves to manage the establishment of state 293 between an Initiator and a Responder. The first packet, I1, 294 initiates the exchange, and the last three packets, R1, I2, and R2, 295 constitute an authenticated secret key wrapped by a Diffie-Hellman 296 derived key for session key generation. The HIP association keys are 297 drawn from this keying material. If other cryptographic keys are 298 needed, e.g., to be used with ESP, they are expected to be drawn from 299 the same keying material. 301 The second packet, R1, starts the actual exchange. It contains a 302 puzzle -- a cryptographic challenge that the Initiator must solve 303 before continuing the exchange. The level of difficulty of the 304 puzzle can be adjusted based on level of trust with the Initiator, 305 current load, or other factors. The R1 also contains lists of 306 cryptographic algorithms supported by the Responder. Based on these 307 lists, the Initiator can continue, abort, or restart the base 308 exchange with a different selection of cryptographic algorithms. 310 In the I2 packet, the Initiator must display the solution to the 311 received puzzle. Without a correct solution, the I2 message is 312 discarded. The I2 also contains a key wrap parameter that carries 313 the key for the Responder. This key is only half the final session 314 key. The packet is MACed by the sender (Initiator). 316 The R2 packet finalizes the base exchange. The R2 contains a key 317 wrap parameter that carries the rest of the key for the Initiator. 318 The packet is MACed by the sender (Initiator). 320 The base exchange is illustrated below. The term "key" refers to the 321 Host Identity public key, "secret" refers to a random value encrypted 322 by a public key, and "sig" represents a signature using such a key. 323 The packets contain other parameters not shown in this figure. 325 Initiator Responder 327 I1: 328 --------------------------> 329 select precomputed R1 330 R1: puzzle, PK 331 <------------------------- 332 solve puzzle remain stateless 333 PK Encrypt x 334 I2: solution, PK, ECR(DH,secret x), mac 335 --------------------------> 336 check puzzle 337 check mac 338 PK Encrypt y 339 R2: PK, ECR(DH,secret y), mac 340 <-------------------------- 341 check mac 343 4.1.1. HIP Puzzle Mechanism 345 The purpose of the HIP puzzle mechanism is to protect the Responder 346 from a number of denial-of-service threats. It allows the Responder 347 to delay state creation until receiving I2. Furthermore, the puzzle 348 allows the Responder to use a fairly cheap calculation to check that 349 the Initiator is "sincere" in the sense that it has churned CPU 350 cycles in solving the puzzle. 352 DEX uses the CMAC function instead of a hash function as in BEX. 354 The puzzle mechanism has been explicitly designed to give space for 355 various implementation options. It allows a Responder implementation 356 to completely delay session-specific state creation until a valid I2 357 is received. In such a case, a correctly formatted I2 can be 358 rejected only once the Responder has checked its validity by 359 computing one CMAC function. On the other hand, the design also 360 allows a Responder implementation to keep state about received I1s, 361 and match the received I2s against the state, thereby allowing the 362 implementation to avoid the computational cost of the CMAC function. 363 The drawback of this latter approach is the requirement of creating 364 state. Finally, it also allows an implementation to use other 365 combinations of the space-saving and computation-saving mechanisms. 367 Generally speaking, the puzzle mechanism works in DEX the same as in 368 BEX. There are some implementation differences, using CMAC rather 369 than a hash. 371 See Appendix A for one possible implementation. Implementations 372 SHOULD include sufficient randomness to the algorithm so that 373 algorithmic complexity attacks become impossible [CRO03]. 375 4.1.2. Puzzle Exchange 377 The Responder starts the puzzle exchange when it receives an I1. The 378 Responder supplies a random number I, and requires the Initiator to 379 find a number J. To select a proper J, the Initiator must create the 380 concatenation of the HITs of the parties and J, and feed this 381 concatenation using I as the key into the CMAC algorithm. The lowest 382 order K bits of the result MUST be zeros. The value K sets the 383 difficulty of the puzzle. 385 To generate a proper number J, the Initiator will have to generate a 386 number of Js until one produces the CMAC target of zeros. The 387 Initiator SHOULD give up after exceeding the puzzle lifetime in the 388 PUZZLE parameter ([RFC5201-bis]). The Responder needs to re-create 389 the concatenation of the HITs and the provided J, and compute the 390 CMAC using I once to prove that the Initiator did its assigned task. 392 To prevent precomputation attacks, the Responder MUST select the 393 number I in such a way that the Initiator cannot guess it. 394 Furthermore, the construction MUST allow the Responder to verify that 395 the value was indeed selected by it and not by the Initiator. See 396 Appendix A for an example on how to implement this. 398 Using the Opaque data field in an ECHO_REQUEST_UNSIGNED parameter 399 ([RFC5201-bis]), the Responder can include some data in R1 that the 400 Initiator must copy unmodified in the corresponding I2 packet. The 401 Responder can generate the Opaque data in various ways; e.g., using 402 some secret, the sent I, and possibly other related data. Using the 403 same secret, the received I (from the I2), and the other related data 404 (if any), the Receiver can verify that it has itself sent the I to 405 the Initiator. The Responder MUST periodically change such a used 406 secret. 408 It is RECOMMENDED that the Responder generates a new puzzle and a new 409 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 410 Responder remembers an old puzzle at least 2*Lifetime seconds after 411 the puzzle has been deprecated. These time values allow a slower 412 Initiator to solve the puzzle while limiting the usability that an 413 old, solved puzzle has to an attacker. 415 4.1.3. HIP State Machine 417 The HIP protocol itself has little state. In HIP DEX, as in BEX, 418 there is an Initiator and a Responder. Once the security 419 associations (SAs) are established, this distinction is lost. If the 420 HIP state needs to be re-established, the controlling parameters are 421 which peer still has state and which has a datagram to send to its 422 peer. 424 The HIP DEX state machine has the same states as the BEX state 425 machine. However, there is an optional to implement aggresive 426 transmission feature to provide better performance in sensor networks 427 with high packet loss. the following documents the few differences in 428 the DEX state machine. 430 4.1.3.1. HIP Aggresive Transmission Mechanism 432 HIP DEX may be used on networks with high packet loss. DEX deals 433 with this by using an aggressive transmission practice for I1 and I2 434 packets. The Initiator SHOULD continually send I1 and I2 packets at 435 some short interval t msec, based on local policy. The transmission 436 stops on receipt of the corresponding R1 or R2 packet, which acts as 437 an acknowledgment receipt. 439 Since the Responder is stateless until it receives an I2, it does not 440 need any special behaviour on sending R1 other than to send one 441 whenever it receives an I1. The Responder sends an R2 after receipt 442 every I2. The Responder does need to know that R2 was received by 443 the Initiator. Like in BEX, the Responder can learn this when it 444 starts receiving datagrams. 446 4.1.3.2. HIP States 448 +---------------------+---------------------------------------------+ 449 | State | Explanation | 450 +---------------------+---------------------------------------------+ 451 | UNASSOCIATED | State machine start | 452 | | | 453 | I1-SENT | Initiating base exchange | 454 | | | 455 | I2-SENT | Waiting to complete base exchange | 456 | | | 457 | R2-SENT | Waiting to complete base exchange | 458 | | | 459 | ESTABLISHED | HIP association established | 460 | | | 461 | CLOSING | HIP association closing, no data can be | 462 | | sent | 463 | | | 464 | CLOSED | HIP association closed, no data can be sent | 465 | | | 466 | E-FAILED | HIP exchange failed | 467 +---------------------+---------------------------------------------+ 469 Table 1: HIP States 471 4.1.3.3. HIP State Processes 473 System behavior in state I1-SENT, Table 2. 475 +---------------------+-----------------------------+ 476 | Trigger | Action | 477 +---------------------+-----------------------------+ 478 | t msec | Send I1 and stay at I1-SENT | 479 +---------------------+-----------------------------+ 481 Table 2: I1-SENT - Initiating HIP 483 System behavior in state I2-SENT, Table 3. 485 +---------------------+-----------------------------+ 486 | Trigger | Action | 487 +---------------------+-----------------------------+ 488 | t msec | Send I2 and stay at I2-SENT | 489 +---------------------+-----------------------------+ 491 Table 3: I2-SENT - Waiting to finish HIP 493 System behavior in state R2-SENT, Table 4. 495 +----------------------+-----------------------------+ 496 | Trigger | Action | 497 +----------------------+-----------------------------+ 498 | Receive duplicate I2 | Send R2 and stay at R2-SENT | 499 +----------------------+-----------------------------+ 501 Table 4: R2-SENT - Waiting to finish HIP 503 4.1.3.4. Simplified HIP State Diagram 505 The following diagram shows the major state transitions. Transitions 506 based on received packets implicitly assume that the packets are 507 successfully authenticated or processed. 509 +-+ +------------------------------+ 510 I1 received, send R1 | | | | 511 | v v | 512 Datagram to send +--------------+ I2 received, send R2 | 513 Send I1 +--------------| UNASSOCIATED |--------------+ | 514 +-+ | +-+ +--------------+ | | 515 send | | | | | | | 516 I1 t | | | | | Alg. not supported, send I1 | | 517 msec v | v | v | | 518 +---------+ I2 received, send R2 | | 519 +---->| I1-SENT |-------------------------------------+ | | 520 | +---------+ | | | 521 | | +----------------------+ | | +-+receive | 522 | send I2+-+ | R1 received, | I2 received, send R2 | | | | |I2, | 523 | t msec | v v send I2 | v v v | v send R2 | 524 | +---------+ | +---------+ | 525 | +->| I2-SENT |------------+ | R2-SENT |<--+ | 526 | | +---------+ +---------+ | | 527 | | | | | | 528 | | | data| | | 529 | |receive | or| | | 530 | |R1, send | EC timeout| receive I2,| | 531 | |I2 |R2 received +--------------+ | send R2| | 532 | | +----------->| ESTABLISHED |<--------+ | | 533 | | +--------------+ | | 534 | | | | | receive I2, send R2 | | 535 | | recv+------------+ | +------------------------+ | 536 | | CLOSE,| | | | 537 | | send| No packet sent| | | 538 | | CLOSE_ACK| /received for | timeout | | 539 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 540 | | | CLOSE +--->| CLOSING |--+ retransmit | | 541 | | | +---------+ CLOSE | | 542 +--|------------|----------------------+| | | | | | 543 +------------|-----------------------+ | | +-----------------+ | 544 | | +-----------+ +-------------------|----+ 545 | +-----------+ | receive CLOSE, CLOSE_ACK | | 546 | | | send CLOSE_ACK received or | | 547 | | | timeout | | 548 | | | (UAL+MSL) | | 549 | v v | | 550 | +--------+ receive I2, send R2 | | 551 +-----------------------| CLOSED |----------------------------+ | 552 +--------+ /-------------------------+ 553 ^ | \-------/ timeout (UAL+2MSL), 554 | | move to UNASSOCIATED 555 +-+ 556 CLOSE received, send CLOSE_ACK 558 4.1.4. User Data Considerations 560 There is no difference in User Data Considerations between BEX and 561 DEX with one exception. Loss of state due to system reboot may be a 562 critical performance issue. Thus implementors MAY choose to use non- 563 volatile, secure storage for HIP state so it will survive system 564 reboot. This will limit state loss during reboots to only those 565 situtations that there is an SA timeout. 567 5. Packet Formats 569 5.1. HIP Parameters 571 The HIP Parameters are used to carry the public key associated with 572 the sender's HIT, together with related security and other 573 information. They consist of ordered parameters, encoded in TLV 574 format. 576 The following new parameter types are currently defined for DEX, in 577 addition to those defined for BEX. Also listed are BEX parameters 578 that have additional values for DEX. 580 +------------------+-------+----------+-----------------------------+ 581 | TLV | Type | Length | Data | 582 +------------------+-------+----------+-----------------------------+ 583 | HIP_MAC_3 | 61506 | variable | CMAC-based message | 584 | | | | authentication code, with | 585 | | | | key material from KEYMAT | 586 | | | | | 587 | HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT | 588 | | | | suites supported by the | 589 | | | | Responder | 590 +------------------+-------+----------+-----------------------------+ 592 5.1.1. HIT_SUITE_LIST 594 The HIT suites in DEX are limited to: 596 HIT suite ID 597 ECDH/DEX 8 599 The HIT_SUITE_LIST parameter contains a list of the supported HIT 600 suite IDs of the Responder. Since the HIT of the Initiator is a DEX 601 HIT, the Responder MUST only respond with a DEX HIT suite ID. 602 Currently, only one such suite ID has been defined. 604 5.1.2. HIP_MAC_3 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 | CMAC | 613 / / 614 / +-------------------------------+ 615 | | Padding | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Type 61506 619 Length length in octets, excluding Type, Length, and 620 Padding 621 CMAC CMAC computed over the HIP packet, excluding the 622 HIP_MAC parameter itself. The checksum field MUST 623 be set to zero and the HIP header length in the HIP 624 common header MUST be calculated not to cover any 625 excluded parameters when the CMAC is calculated. The 626 size of the CMAC is the natural size of the AES block 627 depending on the AES key size. 629 The CMAC calculation and verification process is presented in 630 Section 6.2.1. 632 5.2. HIP Packets 634 DEX uses the same eight basic HIP packets (see [RFC5201-bis]) as BEX. 635 Four are for the HIP exchange, one is for updating, one is for 636 sending notifications, and two are for closing a HIP association. 637 There are some differences in the HIP parameters in the exchange 638 packets between BEX and DEX. This section will cover the DEX 639 packets. 641 An important difference between BEX and DEX HIP packets is that there 642 is NO HIP_SIGNATURE available in DEX. Thus R1 is completely 643 unprotected and can be spoof. The I2, R2, UPDATE, NOTIFY, CLOSE, and 644 CLOSE_ACK only have HIP_MAC_3 for packet authentication The 645 processing of these packets are changed accordingly. 647 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 648 header. The Next Header field in the header indicates if there is 649 additional data following the HIP header. The HIP packet, however, 650 MUST NOT be fragmented. This limits the size of the possible 651 additional data in the packet. 653 5.2.1. I1 - the HIP Initiator Packet 655 The HIP header values for the I1 packet: 657 Header: 658 Packet Type = 1 659 SRC HIT = Initiator's HIT 660 DST HIT = Responder's HIT, or NULL 662 IP ( HIP ( DH_GROUP_LIST ) ) 664 The I1 packet contains the fixed HIP header and the Initiator's 665 DH_GROUP_LIST. 667 Valid control bits: none 669 The Initiator HIT MUST be a DEX HIT. That is the HIT Suite ID MUST 670 be of a DEX type. Currently only ECDH/DEX is defined. 672 The Initiator gets the Responder's HIT either from a DNS lookup of 673 the Responder's FQDN, from some other repository, or from a local 674 table. The Responder's HIT MUST be a DEX HIT. If the Initiator does 675 not know the Responder's HIT, it may attempt to use opportunistic 676 mode by using NULL (all zeros) as the Responder's HIT. See also "HIP 677 Opportunistic Mode" [RFC5201-bis]. 679 Since this packet is so easy to spoof even if it were signed, no 680 attempt is made to add to its generation or processing cost. 682 The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform 683 the Responder of its preferred DH Group IDs. Only ECDH Groups may be 684 included in this list. Note that the DH_GROUP_LIST in the I1 packet 685 is not protected by a mac. 687 Implementations MUST be able to handle a storm of received I1 688 packets, discarding those with common content that arrive within a 689 small time delta, but distinguishing this from arriving at a set time 690 delta. This behaviour is the expected behaviour for an Initiator on 691 a network with high packet loss. The HIP state machine calls out 692 this behaviour in this case and the Initiator will stop sending I1 693 packets after it receives an R1 packet. 695 5.2.2. R1 - the HIP Responder Packet 697 The HIP header values for the R1 packet: 699 Header: 700 Packet Type = 2 701 SRC HIT = Responder's HIT 702 DST HIT = Initiator's HIT 704 IP ( HIP ( [ R1_COUNTER, ] 705 PUZZLE, 706 DIFFIE_HELLMAN, 707 HIP_CIPHER, 708 HOST_ID, 709 HIT_SUITE_LIST, 710 DH_GROUP_LIST, 711 <, ECHO_REQUEST_UNSIGNED >i) 713 Valid control bits: A 715 If the Responder's HI is an anonymous one, the A control MUST be set. 717 The Initiator's HIT MUST match the one received in I1. If the 718 Responder has multiple HIs, the Responder's HIT used MUST match 719 Initiator's request. If the Initiator used opportunistic mode, the 720 Responder may select freely among its HIs. See also "HIP 721 Opportunistic Mode" [RFC5201-bis]. 723 The R1 generation counter is used to determine the currently valid 724 generation of puzzles. The value is increased periodically, and it 725 is RECOMMENDED that it is increased at least as often as solutions to 726 old puzzles are no longer accepted. 728 The Puzzle contains a Random #I and the difficulty K. The difficulty 729 K indicates the number of lower-order bits, in the puzzle CMAC 730 result, that must be zeros; see Section 4.1.2. 732 The Responder selects the Diffie-Hellman public value based on the 733 Initiator's preference expressed in the DH_GROUP_LIST parameter in 734 the I1. The Responder sends back its own preference based on which 735 it chose the DH public value as DH_GROUP_LIST. This allows the 736 Initiator to determine whether its own DH_GROUP_LIST in the I1 was 737 manipulated by an attacker. There is a further risk that the 738 Responder's DH_GROUP_LIST was manipulated by an attacker, as R1 739 cannot be authenticated in DEX as it can in BEX. Thus it is repeated 740 in R2 allowing for a final check at that point. 742 In DEX, the Diffie-Hellman values are static. They are NOT 743 discarded. 745 The HIP_CIPHER contains the encryption algorithms supported by the 746 Responder to protect the key exchange, in the order of preference. 748 All implementations MUST support the AES-CBC [RFC3602]. 750 The ECHO_REQUEST_UNSIGNED contains data that the sender wants to 751 receive unmodified in the corresponding response packet in the 752 ECHO_RESPONSE_UNSIGNED parameter. 754 5.2.3. I2 - the Second HIP Initiator Packet 756 The HIP header values for the I2 packet: 758 Header: 759 Type = 3 760 SRC HIT = Initiator's HIT 761 DST HIT = Responder's HIT 763 IP ( HIP ( [R1_COUNTER,] 764 SOLUTION, 765 DIFFIE_HELLMAN, 766 HIP_CIPHER, 767 ENCRYPTED {secret, HOST_ID } or HOST_ID, 768 ENCRYPTED {DH, secret x}, 769 [ ENCRYPTED {secret, ENCRYPTED {passwd, challenge } },] 770 HIP_MAC_3, 771 <, ECHO_RESPONSE_UNSIGNED>i ) ) 773 Valid control bits: A 775 The HITs used MUST match the ones used previously. 777 If the Initiator's HI is an anonymous one, the A control MUST be set. 779 The Initiator MAY include an unmodified copy of the R1_COUNTER 780 parameter received in the corresponding R1 packet into the I2 packet. 782 The Solution contains the Random #I from R1 and the computed #J. The 783 low-order K bits of the CMAC(S, | ... | J) MUST be zero. 785 In DEX, the Diffie-Hellman values are static. They are NOT 786 discarded. 788 The HIP_CIPHER contains the single encryption transform selected by 789 the Initiator, that will be used to protect the HI exchange. The 790 chosen transform MUST correspond to one offered by the Responder in 791 the R1. All implementations MUST support the AES-CBC transform 792 [RFC3602]. 794 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 795 algorithm. The keying material is derived from the ENCRYPTed 796 exchanged secrets as defined in Section 6.3. 798 The ECHO_RESPONSE_UNSIGNED contain the unmodified Opaque data copied 799 from the corresponding echo request parameter. 801 The ENCRYPTED contains an Initiator generated random secret x that 802 MUST be uniformly distributed. The secret x's length matches the 803 keysize of the selected encryption transform. I from the puzzle is 804 used as the IV in the encryption transform. This acts as a nonce 805 from the Responder to prove freshness of the secret wrapping from the 806 Initiator. If I is larger than the IV size it is left truncated to 807 size. If I is smaller than the IV size it is concatanated to itself 808 until large enough. The key for the encryption is the Diffie-Hellman 809 serived key. It is converted to the size needed for the encryption 810 transform by using CMAC(0^n, DH|I) where n is the needed key size. 811 Including I as a nonce in the key construction is similar to the 812 recommendation in NIST 800-56A, section 6.3.2 for making a unique 813 derived key with each use of a Static/Static Diffie-Hellman exchange. 815 If the Initiator has prior knowledge that the Responder is expecting 816 a password authenication, the Initiator encrypts the 817 ECHO_REQUEST_UNSIGNED with the password, then wraps the ENCRYPTED 818 parameter in the secret x. I from the puzzle is used as the nonce 819 here as well. There is no signal within R1 for this behaviour. 820 Knowledge of password authencation must be externally configured. 822 The MAC is calculated over the whole HIP envelope, excluding any 823 parameters after the HIP_MAC, as described in Section 6.2.1. The 824 Responder MUST validate the HIP_MAC_3. 826 5.2.4. R2 - the Second HIP Responder Packet 828 The HIP header values for the R2 packet: 830 Header: 831 Packet Type = 4 832 SRC HIT = Responder's HIT 833 DST HIT = Initiator's HIT 835 IP ( HIP ( DH_GROUP_LIST, 836 ENCRYPTED {DH, secret}, 837 HIP_MAC_3) 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 a Responder generated random secret y that 848 MUST be uniformly distributed. The secret y's length matches the 849 keysize of the selected encryption transform. I from the puzzle 850 (that was returned in SOLUTION) is used as the IV in the encryption 851 transform. This acts as a nonce from the Responder to prove 852 freshness of the secret wrapping from the Initiator. If I is larger 853 than the IV size it is left truncated to size. If I is smaller than 854 the IV size it is concatanated to itself until large enough. The key 855 for the encryption is the Diffie-Hellman serived key. It is 856 converted to the size needed for the encryption transform by using 857 CMAC(0^n, DH|I) where n is the needed key size. Including I as a 858 nonce in the key construction is similar to the recommendation in 859 NIST 800-56A, section 6.3.2 for making a unique derived key with each 860 use of a Static/Static Diffie-Hellman exchange. 862 The HIP_MAC_3 is calculated over the whole HIP envelope, with 863 Responder's HOST_ID parameter concatenated with the HIP envelope. 864 The HOST_ID parameter is removed after the CMAC calculation. The 865 procedure is described in Section 6.2.1. 867 The Initiator MUST validate the HIP_MAC_3. 869 5.3. ICMP Messages 871 When a HIP implementation detects a problem with an incoming packet, 872 and it either cannot determine the identity of the sender of the 873 packet or does not have any existing HIP association with the sender 874 of the packet, it MAY respond with an ICMP packet. Any such replies 875 MUST be rate-limited as described in [RFC2463]. In most cases, the 876 ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 877 for ICMPv6), with the Pointer field pointing to the field that caused 878 the ICMP message to be generated. 880 6. Packet Processing 882 Each host is assumed to have a single HIP protocol implementation 883 that manages the host's HIP associations and handles requests for new 884 ones. Each HIP association is governed by a conceptual state 885 machine, with states defined above in Section 4.1.3. The HIP 886 implementation can simultaneously maintain HIP associations with more 887 than one host. Furthermore, the HIP implementation may have more 888 than one active HIP association with another host; in this case, HIP 889 associations are distinguished by their respective HITs. It is not 890 possible to have more than one HIP association between any given pair 891 of HITs. Consequently, the only way for two hosts to have more than 892 one parallel association is to use different HITs, at least at one 893 end. 895 6.1. Solving the Puzzle 897 This subsection describes the puzzle-solving details. 899 In R1, the values I and K are sent in network byte order. Similarly, 900 in I2, the values I and J are sent in network byte order. The mac is 901 created by concatenating, in network byte order, the following data, 902 in the following order and using the CMAC algorithm with I|I as the 903 key: 905 128-bit Initiator's HIT, in network byte order, as appearing in 906 the HIP Payload in R1 and I2. 908 128-bit Responder's HIT, in network byte order, as appearing in 909 the HIP Payload in R1 and I2. 911 n-bit random value J (where n is CMAC-len/2), in network byte 912 order, as appearing in I2. 914 In order to be a valid response puzzle, the K low-order bits of the 915 resulting CMAC must be zero. 917 Notes: 919 i) All the data in the CMAC input MUST be in network byte order. 921 ii) The order of the Initiator's and Responder's HITs are 922 different in the R1 and I2 packets; see [RFC5201-bis]. Care must 923 be taken to copy the values in the right order to the CMAC input. 925 The following procedure describes the processing steps involved, 926 assuming that the Responder chooses to precompute the R1 packets: 928 Precomputation by the Responder: 929 Sets up the puzzle difficulty K. 930 Creates a R1 and caches it. 932 Responder: 933 Selects a suitable cached R1. 934 Generates a random number I. 935 Sends I and K in an R1. 936 Saves I and K for a Delta time. 938 Initiator: 939 Generates repeated attempts to solve the puzzle until a matching J 940 is found: 941 Ltrunc( CMAC( I | I, HIT-I | HIT-R | J ), K ) == 0 942 Sends I and J in an I2. 944 Responder: 945 Verifies that the received I is a saved one. 946 Finds the right K based on I. 947 Computes V := Ltrunc( CMAC( I | I, HIT-I | HIT-R | J ), K ) 948 Rejects if V != 0 949 Accept if V == 0 951 6.2. HIP_MAC Calculation and Verification 953 The following subsections define the actions for processing the 954 HIP_MAC_3 parameter. 956 6.2.1. CMAC Calculation 958 Both the Initiator and the Responder should take some care when 959 verifying or calculating the HIP_MAC_3. Specifically, the Responder 960 should preserve other parameters than the HOST_ID when sending the 961 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 962 was received in the R1 packet. 964 The scope of the calculation for HIP_MAC_3 is: 966 CMAC: { HIP header | [ Parameters ] } 968 where Parameters include all HIP parameters of the packet that is 969 being calculated with Type values from 1 to (HIP_MAC's Type value - 970 1) and exclude parameters with Type values greater or equal to 971 HIP_MAC's Type value. 973 During HIP_MAC calculation, the following applies: 975 o In the HIP header, the Checksum field is set to zero. 977 o In the HIP header, the Header Length field value is calculated to 978 the beginning of the HIP_MAC parameter. 980 Parameter order is described in [RFC5201-bis]. 982 The HIP_MAC parameter is defined in Section 5.1.2. The CMAC 983 calculation and verification process is as follows: 985 Packet sender: 987 1. Create the HIP packet, without the HIP_MAC or any other parameter 988 with greater Type value than the HIP_MAC parameter has. 990 2. Calculate the Header Length field in the HIP header. 992 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 993 retrieved from KEYMAT as defined in Section 6.3. 995 4. Add the HIP_MAC_3 parameter to the packet and any parameter with 996 greater Type value than the HIP_MAC's (HIP_MAC_3's) that may 997 follow. 999 5. Recalculate the Length field in the HIP header. 1001 Packet receiver: 1003 1. Verify the HIP header Length field. 1005 2. Remove the HIP_MAC_3 parameter, as well as all other parameters 1006 that follow it with greater Type value, saving the contents if 1007 they will be needed later. 1009 3. Recalculate the HIP packet length in the HIP header and clear the 1010 Checksum field (set it to all zeros). 1012 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1013 defined in Section 6.3 and verify it against the received CMAC. 1015 5. Set Checksum and Header Length field in the HIP header to 1016 original values. 1018 6.3. HIP KEYMAT Generation 1020 HIP DEX keying material is derived from encrypted secrets in I2 and 1021 R2. The Responder has the keying material during the creation of the 1022 R2 packet, and the Initiator has it once it receives the R2 packet. 1023 This is why R2 can already contain encrypted information. 1025 The KEYMAT is derived by feeding the keying material into the 1026 following operation; the | operation denotes concatenation. 1028 CKDF-Expand(PRK, info, L) -> OKM 1030 where 1032 info = sort(HIT-I | HIT-R) 1033 PRK = x | y 1034 PRKlen = Length of PRK in octets 1035 maclen = Length of CMAC in octets 1036 L length of output keying material in octets 1037 (<= 255*macLen) 1039 If PRKlen != macLen then PRK = CMAC(0^128, PRK) 1041 The output OKM is calculated as follows: 1043 N = ceil(L/macLen) 1044 T = T(1) | T(2) | T(3) | ... | T(N) 1045 OKM = first L octets of T 1047 where: 1049 T(0) = empty string (zero length) 1050 T(1) = CMAC(PRK, T(0) | info | 0x01) 1051 T(2) = CMAC(PRK, T(1) | info | 0x02) 1052 T(3) = CMAC(PRK, T(2) | info | 0x03) 1053 ... 1055 (where the constant concatenated to the end of each T(n) is a 1056 single octet.) 1058 Sort(HIT-I | HIT-R) is defined as the network byte order 1059 concatenation of the two HITs, with the smaller HIT preceding the 1060 larger HIT, resulting from the numeric comparison of the two HITs 1061 interpreted as positive (unsigned) 128-bit integers in network byte 1062 order. 1064 x and y values are from the ENCRYPTED parameters from I2 and R2 1065 respectively when this HIP association was set up. For the I2 1066 packet, value y is NULL. 1068 The initial keys are drawn sequentially in the order that is 1069 determined by the numeric comparison of the two HITs, with comparison 1070 method described in the previous paragraph. HOST_g denotes the host 1071 with the greater HIT value, and HOST_l the host with the lower HIT 1072 value. 1074 The drawing order for initial keys: 1076 HIP-gl encryption key for HOST_g's outgoing HIP packets 1078 HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1080 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 1081 packets 1083 HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1085 The number of bits drawn for a given algorithm is the "natural" size 1086 of the keys. For the mandatory algorithms, the following sizes 1087 apply: 1089 AES 128 or 256 bits 1091 If other key sizes are used, they must be treated as different 1092 encryption algorithms and defined separately. 1094 6.4. Processing Incoming I1 Packets 1096 An implementation SHOULD reply to an I1 with an R1 packet, unless the 1097 implementation is unable or unwilling to set up a HIP association. 1098 An I1 in DEX is handled identically to BEX with the exception that in 1099 constructing the R1, the Responder SHOULD select a HIT that is 1100 constructed with the MUST algorithm, which is currently ECDH. 1102 6.4.1. R1 Management 1104 All compliant implementations MUST produce R1 packets. An R1 in DEX 1105 is handled identically to BEX. 1107 6.5. Processing Incoming R1 Packets 1109 A system receiving an R1 MUST first check to see if it has sent an I1 1110 to the originator of the R1 (i.e., it is in state I1-SENT). An R1 in 1111 DEX is handled identically to BEX with the following differences. 1113 If the system has been sending out a stream of I1 packets to work 1114 around high packet loss on a network, it stops sending the I1 packets 1115 AFTER successfully processing the R1 packet. 1117 There is no HIP_SIGNATURE on this packet. This is an 1118 unauthentication packet. 1120 The following steps define the conceptual processing rules for 1121 responding to an R1 packet that are different than in BEX: 1123 1. If the system is configured with a authentication password for 1124 the responder, it constructs the autentication response to 1125 include in the I2. 1127 2. The system prepares and sends an I2, as described in 1128 Section 5.2.3. The system MAY be configured to continually send 1129 this I2 until it receives and validates an R2. 1131 6.6. Processing Incoming I2 Packets 1133 Upon receipt of an I2, the system MAY perform initial checks to 1134 determine whether the I2 corresponds to a recent R1 that has been 1135 sent out, if the Responder keeps such state. An I2 in DEX is handled 1136 identically to BEX with the following differences. 1138 The HIP implementation SHOULD process the I2. This includes 1139 validation of the puzzle solution, extracting the ENCRYPTED key for 1140 processing I2, decrypting the Initiator's Host Identity, verifying 1141 the mac, creating state, and finally sending an R2. 1143 There is no HIP_SIGNATURE on this packet. Authentication is 1144 completely based on the HIP_MAC_3 parameter. 1146 The following steps define the conceptual processing rules for 1147 responding to an I2 packet: 1149 1. If the system's state machine is in the I2-SENT state, the system 1150 makes a comparison between its local and sender's HITs (similarly 1151 as in Section 6.3). If the local HIT is smaller than the 1152 sender's HIT, it should drop the I2 packet, and continue using 1153 the R1 received and I2 sent to the peer earlier. Otherwise, the 1154 system should process the received I2 packet and drop any 1155 previously derived Diffie-Hellman keying material Kij and 1156 ENCRYPTED keying material it might have formed upon sending the 1157 I2 previously. The peer Diffie-Hellman key, ENCRYPTED keying 1158 material and the nonce J are taken from the just arrived I2 1159 packet. The local Diffie-Hellman key and the nonce I are the 1160 ones that were earlier sent in the R1 packet. 1162 2. The system MUST validate the solution to the puzzle by computing 1163 the mac described in Section 5.2.3 using the CMAC algorithm. 1165 3. The system must extract the keying material from the ENCRYPTED 1166 parameter. This key is used to derive the I2 HIP association 1167 keys, as described in Section 6.3. 1169 4. If the checks above are valid, then the system proceeds with 1170 further I2 processing; otherwise, it discards the I2 and its 1171 state machine remains in the same state. If the system has been 1172 sending a stream of R1 packets to the HIT in the I2 the system 1173 stops sending the R1s. 1175 6.7. Processing Incoming R2 Packets 1177 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1178 results in the R2 being dropped and the state machine staying in the 1179 same state. If an R2 is received in state I2-SENT, it SHOULD be 1180 processed. 1182 There is no HIP_SIGNATURE on this packet. Authentication is 1183 completely based on the HIP_MAC_3 parameter. 1185 The conceptual processing rules for an incoming R2 packet in DEX are 1186 identical to BEX with the following differences. 1188 1. The system checks the DH_GROUP_LIST as in R1 packet processing. 1189 If the list is different from R1's there may have been a DH 1190 downgrade attack against the unprotected R1 packet. If the 1191 DH_GROUP_LIST presents a better list than recieved in the R1 1192 packet, the system may either resend I1 within the retry bounds 1193 or abandon the HIP exchange. 1195 2. The system must extract the keying material from the ENCRYPTED 1196 parameter. This key is concatanated with that sent in the I2 1197 packet to form the HIP association keys, as described in 1198 Section 6.3. 1200 6.8. Sending UPDATE Packets 1202 A host sends an UPDATE packet when it wants to update some 1203 information related to a HIP association. DEX UPDATE handling is the 1204 similar in DEX as in BEX. The key difference is NO HIP_SIGNATURE. 1206 6.9. Handling State Loss 1208 In the case of system crash and unanticipated state loss, the system 1209 SHOULD delete the corresponding HIP state, including the keying 1210 material. That is, the state SHOULD NOT be stored on stable storage. 1211 If the implementation does drop the state (as RECOMMENDED), it MUST 1212 also drop the peer's R1 generation counter value, unless a local 1213 policy explicitly defines that the value of that particular host is 1214 stored. An implementation MUST NOT store R1 generation counters by 1215 default, but storing R1 generation counter values, if done, MUST be 1216 configured by explicit HITs. 1218 7. HIP Policies 1220 There are a number of variables that will influence the HIP exchanges 1221 that each host must support. All HIP implementations MUST support 1222 more than one simultaneous HI, at least one of which SHOULD be 1223 reserved for anonymous usage. Although anonymous HIs will be rarely 1224 used as Responders' HIs, they will be common for Initiators. Support 1225 for more than two HIs is RECOMMENDED. 1227 Many Initiators would want to use a different HI for different 1228 Responders. The implementations SHOULD provide for an ACL of 1229 Initiator's HIT to Responder's HIT. This ACL SHOULD also include 1230 preferred transform and local lifetimes. 1232 The value of K used in the HIP R1 packet can also vary by policy. K 1233 should never be greater than 20, but for trusted partners it could be 1234 as low as 0. 1236 Responders would need a similar ACL, representing which hosts they 1237 accept HIP exchanges, and the preferred transform and local 1238 lifetimes. Wildcarding SHOULD be supported for this ACL also. 1240 8. Security Considerations 1242 HIP is designed to provide secure authentication of hosts. HIP also 1243 attempts to limit the exposure of the host to various denial-of- 1244 service and man-in-the-middle (MitM) attacks. In so doing, HIP 1245 itself is subject to its own DoS and MitM attacks that potentially 1246 could be more damaging to a host's ability to conduct business as 1247 usual. 1249 HIP DEX replaces the SIGMA authenticated Diffie-Hellman key exchange 1250 of BEX with a random generated key exchange encrypted by a Diffie- 1251 Hellman derived key. Both the Initiator and Responder contribute to 1252 this key. 1254 The strength of the key is based on the quality of the secrets 1255 generated the Initiator and Responder. Since the Initiator is 1256 commonly a sensor there is a natural concern about the quality of 1257 its random number generator. 1259 DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1260 compromised, ALL HIP connections protected with that HI are 1261 compromised. 1263 The puzzle mechanism using CMAC may need further study that it 1264 does present the desired level of difficulty. 1266 The DEX HIT extraction MAY present new attack opportunities; 1267 further study is needed. 1269 The R1 packet is unprotected and offers an attacker new resource 1270 attacks against the Initiator. This is mitigated by the Initator 1271 only processing a received R1 when it has sent an I1. This is 1272 another DoS attack, but for battery powered Initiators, it could be a 1273 concern. 1275 9. IANA Considerations 1277 IANA has reserved protocol number 139 for the Host Identity Protocol. 1279 The following HIT suites are defined for DEX HIT generation. 1281 +-------+------------+----------------------+-----------------------+ 1282 | Index | Hash | Signature algorithm | Description | 1283 | | function | family | | 1284 +-------+------------+----------------------+-----------------------+ 1285 | 5 | LTRUNC | ECDH | ECDH HI truncated to | 1286 | | | | 96 bits | 1287 +-------+------------+----------------------+-----------------------+ 1289 Table 5: HIT Suites 1291 10. Acknowledgments 1293 The drive to put HIP on a cryptographic 'Diet' came out of a number 1294 of discussions with sensor vendors at IEEE 802.15 meetings. David 1295 McGrew was very 1297 11. References 1299 11.1. Normative References 1301 [RFC2119] Bradner, S., "Key words for use in RFCs to 1302 Indicate Requirement Levels", BCP 14, RFC 2119, 1303 March 1997. 1305 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 1306 Version 6 (IPv6) Specification", RFC 2460, 1307 December 1998. 1309 [RFC2463] Conta, A. and S. Deering, "Internet Control 1310 Message Protocol (ICMPv6) for the Internet 1311 Protocol Version 6 (IPv6) Specification", 1312 RFC 2463, December 1998. 1314 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC 1315 Cipher Algorithm and Its Use with IPsec", 1316 RFC 3602, September 2003. 1318 [RFC3972] Aura, T., "Cryptographically Generated Addresses 1319 (CGA)", RFC 3972, March 2005. 1321 [RFC4309] Housley, R., "Using Advanced Encryption Standard 1322 (AES) CCM Mode with IPsec Encapsulating Security 1323 Payload (ESP)", RFC 4309, December 2005. 1325 [RFC4843-bis] Nikander, P., Laganier, J., and F. Dupont, "STUB: 1326 An IPv6 Prefix for Overlay Routable Cryptographic 1327 Hash Identifiers (ORCHID)", 1328 draft-laganier-rfc4843-bis-00 (work in progress), 1329 February 2010. 1331 [RFC5201-bis] Moskowitz, R., Nikander, P., Jokela, P., 1332 Henderson, T., and T. Heer, "Host Identity 1333 Protocol", draft-moskowitz-hip-rfc5201-bis-01 1334 (work in progress), March 2010. 1336 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using 1337 the Encapsulating Security Payload (ESP) Transport 1338 Format with the Host Identity Protocol (HIP)", 1339 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, "Analysis 1349 of the HIP Base Exchange Protocol", in Proceedings 1350 of 10th Australasian Conference on Information 1351 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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for 1359 Writing an IANA Considerations Section in RFCs", 1360 BCP 26, RFC 2434, October 1998. 1362 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) 1363 Protocol", RFC 4306, December 2005. 1365 [rfc4423-bis] Moskowitz, R. and P. Nikander, "Host Identity 1366 Protocol Architecture", 1367 draft-moskowitz-hip-rfc4423-bis-00 (work in 1368 progress), December 2009. 1370 Appendix A. Using Responder Puzzles 1372 As mentioned in Section 4.1.1, the Responder may delay state creation 1373 and still reject most spoofed I2s by using a number of pre-calculated 1374 R1s and a local selection function. This appendix defines one 1375 possible implementation in detail. The purpose of this appendix is 1376 to give the implementors an idea on how to implement the mechanism. 1377 If the implementation is based on this appendix, it MAY contain some 1378 local modification that makes an attacker's task harder. 1380 The Responder creates a secret value S, that it regenerates 1381 periodically. The Responder needs to remember the two latest values 1382 of S. Each time the S is regenerated, the R1 generation counter 1383 value is incremented by one and the Responder generates an R1 packet. 1385 When the Initiator sends the I1 packet for initializing a connection, 1386 the Responder gets the HIT and IP address from the packet, and 1387 generates an I value for the puzzle. 1389 I value calculation: 1390 I = Ltrunc( CMAC ( S, HIT-I | HIT-R | IP-I | IP-R ), n) 1391 where n = CMAC-len/2 1393 From an incoming I2 packet, the Responder gets the required 1394 information to validate the puzzle: HITs, IP addresses, and the 1395 information of the used S value from the R1_COUNTER. Using these 1396 values, the Responder can regenerate the I, and verify it against the 1397 I received in the I2 packet. If the I values match, it can verify 1398 the solution using I, J, and difficulty K. If the I values do not 1399 match, the I2 is dropped. 1401 puzzle_check: 1402 V := Ltrunc( CMAC( I2.I | I2.I, I2.hit_i | I2.hit_r | I2.J ), K ) 1403 if V != 0, drop the packet 1405 If the puzzle solution is correct, the I and J values are stored for 1406 later use. They are used as input material when keying material is 1407 generated. 1409 Keeping state about failed puzzle solutions depends on the 1410 implementation. Although it is possible for the Responder not to 1411 keep any state information, it still may do so to protect itself 1412 against certain attacks (see Section 4.1.1). 1414 Appendix B. Generating a Public Key Encoding from an HI 1416 The following pseudo-code illustrates the process to generate a 1417 public key encoding from an HI for ECDH. 1419 Author's Address 1421 Robert Moskowitz 1422 ICSA labs, An Independent Division of Verizon Business 1423 1000 Bent Creek Blvd, Suite 200 1424 Mechanicsburg, PA 1425 USA 1427 EMail: robert.moskowitz@icsalabs.com