idnits 2.17.1 draft-moskowitz-hip-rg-dex-04.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 (January 30, 2011) is 4828 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: 'I-D.mcgrew-fundamental-ecc' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 1447, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1450, but no explicit reference was found in the text == Unused Reference: 'AUR03' is defined on line 1476, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-rfc4423-bis' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1524, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-mcgrew-fundamental-ecc-03 ** Downref: Normative reference to an Informational draft: draft-mcgrew-fundamental-ecc (ref. 'I-D.mcgrew-fundamental-ecc') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-00 -- Unexpected draft version: The latest known version of draft-moskowitz-hip-rfc5201-bis is -02, but you're referring to -04. ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-01 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft Verizon 4 Intended status: Standards Track January 30, 2011 5 Expires: August 3, 2011 7 HIP Diet EXchange (DEX) 8 draft-moskowitz-hip-rg-dex-04 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 memory and processor constrained. Like HIP BEX it is expected to be 20 used together with another suitable security protocol, such as the 21 Encapsulated Security Payload (ESP). HIP DEX can also be used 22 directly as a keying mechanism for a MAC layer security protocol as 23 is supported by IEEE 802.15.4 [IEEE.802-15-4.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 August 3, 2011. 42 Copyright Notice 44 Copyright (c) 2011 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. HIP DEX Security Associations . . . . . . . . . . . . 14 86 4.1.5. User Data Considerations . . . . . . . . . . . . . . . 14 87 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 15 89 5.1.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . 15 90 5.1.2. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 16 91 5.1.3. HIP_MAC_3 . . . . . . . . . . . . . . . . . . . . . . 17 92 5.2. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.2.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 18 94 5.2.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 19 95 5.2.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 20 96 5.2.4. R2 - the Second HIP Responder Packet . . . . . . . . . 21 98 5.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 22 99 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 22 100 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 23 101 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . . 24 102 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . . 24 103 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 25 104 6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . . 28 105 6.4.1. R1 Management . . . . . . . . . . . . . . . . . . . . 28 106 6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . . 28 107 6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . . 29 108 6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . . 30 109 6.8. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 30 110 6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 30 111 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 114 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 116 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32 117 11.2. Informative References . . . . . . . . . . . . . . . . . . 33 118 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 35 119 Appendix B. Generating a Public Key Encoding from an HI . . . . . 35 121 1. Introduction 123 NOTE: This version of the draft was prepared for the HIP RG meeting 124 with MOST of the additions worked out since the last draft. However, 125 it was NOT carefully edited and some parts are still mis-matched 126 between the old and new discriptive text. 128 This memo specifies the details of the Host Identity Protocol Diet 129 EXchange (HIP DEX). HIP DEX uses the smallest possible set of 130 established cryptographic primitives, in such a manner that does not 131 change our understanding of their behaviour, yet in a different 132 formulation to achieve assertions normally met with different 133 primatives. 135 HIP DEX builds on HIP BEX [RFC5201-bis], and only the differences 136 between BEX and DEX are documented here. 138 There are a few key differences between BEX and DEX. 140 Minimum collection of cryptographic primatives. 142 AES-CBC for symmetric encryption and to provide CMAC for MACing 143 functions. 145 Static/Static Elliptic Curve Diffie-Hellman keys used to 146 encrypt the session key. 148 A simple trunctation function for HIT generation. 150 Forfeit of Perfect Forward Secrecy with the dropping of ephemeral 151 Diffie-Hellman. 153 Forfeit of digital signatures with the removal of a hash function. 154 Reliance of DH derived key used in HIP_MAC to prove ownership of 155 the private key. 157 Provide a Password Authentication within the exchange. This may 158 be supported by BEX as well, but not defined there. 160 Operate in an aggressive retransmission manner to deal with the 161 high packet loss nature of sensor networks. 163 1.1. The HIP Diet EXchange (DEX) 165 The HIP diet exchange is a two-party cryptographic protocol used to 166 establish communications context between hosts. The first party is 167 called the Initiator and the second party the Responder. The four- 168 packet design helps to make HIP DoS resilient. The protocol 169 exchanges Static Diffie-Hellman keys in the 2nd and 3rd packets, 170 transmits session secrets in the 3rd and 4th packets, and 171 authenticates the parties also in the 3rd and 4th packets. 172 Additionally, the Responder starts a puzzle exchange in the 2nd 173 packet, with the Initiator completing it in the 3rd packet before the 174 Responder stores any state from the exchange. 176 Thus DEX is operationally similar to BEX. The model is fairly 177 equivalent to 802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise 178 Transient Key, but handled in a single exchange. 180 HIP DEX does not have the option of encrypting the Host Identity of 181 the Initiator in the 3rd packet. The Responder's Host Identity is 182 also not protected. Thus there is no attempt at anonymity as in BEX. 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 received 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 any aggressively 191 retransmitted I2 packets. 193 An existing HIP association can be updated using the update mechanism 194 defined in this document, and when the association is no longer 195 needed, it can be closed using the defined closing 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 214 2.1. Requirements Terminology 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in RFC 2119 [RFC2119]. 220 2.2. Notation 222 [x] indicates that x is optional. 224 {x} indicates that x is encrypted. 226 X(y) indicates that y is a parameter of X. 228 i indicates that x exists i times. 230 --> signifies "Initiator to Responder" communication (requests). 232 <-- signifies "Responder to Initiator" communication (replies). 234 | signifies concatenation of information-- e.g., X | Y is the 235 concatenation of X with Y. 237 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 238 the mac function M on the input x. 240 3. The DEX Host Identifier Tag (HIT) and Its Representations 242 The DEX Host Identity Tag (HIT) is distinguished in two ways from the 243 BEX HIT: 245 The HIT SUITE ID Section 5.1.1 is ONLY a DEX ID. 247 The HIT DEX hit is not generated via a cryptographic hash. Rather 248 it is a truncation of the Elliptic Curve Host Identity. 250 3.1. Host Identity Tag (HIT) 252 The DEX Host Identity Tag is a 128-bit value -- a truncation of the 253 Host Identifier. There are two advantages of using a Host Identity 254 Tag over the actual Host Identity public key in protocols. Firstly, 255 its fixed length makes for easier protocol coding and also better 256 manages the packet size cost of this technology. Secondly, it 257 presents a consistent format to the protocol whatever underlying 258 identity technology is used. 260 BEX uses RFC 4843-bis [RFC4843-bis] specified 128-bit hash-based 261 identifiers, called Overlay Routable Cryptographic Hash Identifiers 262 (ORCHIDs). Their prefix, allocated from the IPv6 address block, is 263 defined in [RFC4843-bis]. 265 In DEX, a cryptographic hash is NOT used to form the HIT. Rather the 266 HI is truncated to 96 bits. 268 3.2. Generating a HIT from an HI 270 The DEX HIT is not an ORCHID, as there is no hash function in DEX. 271 Since a HI that is an ECDH key is directly computed from a random 272 number it is already collision resistant. The DEX HIT is the left- 273 truncated 96 bits of the HI. This 96 bit value is used in place of 274 the hash in the ORCHID. The HIT suite (see Section 9) is used for 275 the four bits of the Orchid Generation Algorithm (OGA) field in the 276 ORCHID. The same IPv6 prefix used in BEX is used for DEX. 278 4. Protocol Overview 280 The following material is an overview of the differences between the 281 BEX and DEX implementations of the HIP protocol. It is expected that 282 [RFC5201-bis] is well understood first. 284 4.1. Creating a HIP Association 286 By definition, the system initiating a HIP exchange is the Initiator, 287 and the peer is the Responder. This distinction is forgotten once 288 the base exchange completes, and either party can become the 289 Initiator in future communications. 291 The HIP Diet EXchange serves to manage the establishment of state 292 between an Initiator and a Responder. The first packet, I1, 293 initiates the exchange, and the last three packets, R1, I2, and R2, 294 constitute an authenticated secret key wrapped by a Diffie-Hellman 295 derived key for session key generation. The HIP association keys are 296 drawn from this keying material. If other cryptographic keys are 297 needed, e.g., to be used with ESP, they are expected to be drawn from 298 the same keying material. 300 The second packet, R1, starts the actual exchange. It contains a 301 puzzle -- a cryptographic challenge that the Initiator must solve 302 before continuing the exchange. The level of difficulty of the 303 puzzle can be adjusted based on level of trust with the Initiator, 304 current load, or other factors. The R1 also contains lists of 305 cryptographic algorithms supported by the Responder. Based on these 306 lists, the Initiator can continue, abort, or restart the base 307 exchange with a different selection of cryptographic algorithms. 309 In the I2 packet, the Initiator must display the solution to the 310 received puzzle. Without a correct solution, the I2 message is 311 discarded. The I2 also contains a key wrap parameter that carries 312 the key for the Responder. This key is only half the final session 313 key. The packet is MACed by the sender (Initiator). 315 The R2 packet finalizes the base exchange. The R2 contains a key 316 wrap parameter that carries the rest of the key for the Initiator. 317 The packet is MACed by the sender (Initiator). 319 The base exchange is illustrated below. The term "key" refers to the 320 Host Identity public key, "secret" refers to a random value encrypted 321 by a public key, and "sig" represents a signature using such a key. 322 The packets contain other parameters not shown in this figure. 324 Initiator Responder 326 I1: 327 --------------------------> 328 select precomputed R1 329 R1: puzzle, PK 330 <------------------------- 331 solve puzzle remain stateless 332 PK Encrypt x 333 I2: solution, PK, ECR(DH,secret x), mac 334 --------------------------> 335 check puzzle 336 check mac 337 PK Encrypt y 338 R2: PK, ECR(DH,secret y), mac 339 <-------------------------- 340 check mac 342 4.1.1. HIP Puzzle Mechanism 344 The purpose of the HIP puzzle mechanism is to protect the Responder 345 from a number of denial-of-service threats. It allows the Responder 346 to delay state creation until receiving I2. Furthermore, the puzzle 347 allows the Responder to use a fairly cheap calculation to check that 348 the Initiator is "sincere" in the sense that it has churned CPU 349 cycles in solving the puzzle. 351 DEX uses the CMAC function instead of a hash function as in BEX. 353 The puzzle mechanism has been explicitly designed to give space for 354 various implementation options. It allows a Responder implementation 355 to completely delay session-specific state creation until a valid I2 356 is received. In such a case, a correctly formatted I2 can be 357 rejected only once the Responder has checked its validity by 358 computing one CMAC function. On the other hand, the design also 359 allows a Responder implementation to keep state about received I1s, 360 and match the received I2s against the state, thereby allowing the 361 implementation to avoid the computational cost of the CMAC function. 362 The drawback of this latter approach is the requirement of creating 363 state. Finally, it also allows an implementation to use other 364 combinations of the space-saving and computation-saving mechanisms. 366 Generally speaking, the puzzle mechanism works in DEX the same as in 367 BEX. There are some implementation differences, using CMAC rather 368 than a hash. 370 See Appendix A for one possible implementation. Implementations 371 SHOULD include sufficient randomness to the algorithm so that 372 algorithmic complexity attacks become impossible [CRO03]. 374 4.1.2. Puzzle Exchange 376 The Responder starts the puzzle exchange when it receives an I1. The 377 Responder supplies a random number I, and requires the Initiator to 378 find a number J. To select a proper J, the Initiator must create the 379 concatenation of the HITs of the parties and J, and feed this 380 concatenation using I as the key into the CMAC algorithm. The lowest 381 order K bits of the result MUST be zeros. The value K sets the 382 difficulty of the puzzle. 384 To generate a proper number J, the Initiator will have to generate a 385 number of Js until one produces the CMAC target of zeros. The 386 Initiator SHOULD give up after exceeding the puzzle lifetime in the 387 PUZZLE parameter ([RFC5201-bis]). The Responder needs to re-create 388 the concatenation of the HITs and the provided J, and compute the 389 CMAC using I once to prove that the Initiator did its assigned task. 391 To prevent precomputation attacks, the Responder MUST select the 392 number I in such a way that the Initiator cannot guess it. 393 Furthermore, the construction MUST allow the Responder to verify that 394 the value was indeed selected by it and not by the Initiator. See 395 Appendix A for an example on how to implement this. 397 Using the Opaque data field in an ECHO_REQUEST_UNSIGNED parameter 398 ([RFC5201-bis]), the Responder can include some data in R1 that the 399 Initiator must copy unmodified in the corresponding I2 packet. The 400 Responder can generate the Opaque data in various ways; e.g., using 401 some secret, the sent I, and possibly other related data. Using the 402 same secret, the received I (from the I2), and the other related data 403 (if any), the Receiver can verify that it has itself sent the I to 404 the Initiator. The Responder MUST periodically change such a used 405 secret. 407 It is RECOMMENDED that the Responder generates a new puzzle and a new 408 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 409 Responder remembers an old puzzle at least 2*Lifetime seconds after 410 the puzzle has been deprecated. These time values allow a slower 411 Initiator to solve the puzzle while limiting the usability that an 412 old, solved puzzle has to an attacker. 414 4.1.3. HIP State Machine 416 The HIP protocol itself has little state. In HIP DEX, as in BEX, 417 there is an Initiator and a Responder. Once the security 418 associations (SAs) are established, this distinction is lost. If the 419 HIP state needs to be re-established, the controlling parameters are 420 which peer still has state and which has a datagram to send to its 421 peer. 423 The HIP DEX state machine has the same states as the BEX state 424 machine. However, there is an optional to implement aggressive 425 transmission feature to provide better performance in sensor networks 426 with high packet loss. the following documents the few differences in 427 the DEX state machine. 429 4.1.3.1. HIP Aggressive Transmission Mechanism 431 HIP DEX may be used on networks with high packet loss. DEX deals 432 with this by using an aggressive transmission practice for I1 and I2 433 packets. The Initiator SHOULD continually send I1 and I2 packets at 434 some short interval t msec, based on local policy. The transmission 435 stops on receipt of the corresponding R1 or R2 packet, which acts as 436 an acknowledgment receipt. 438 Since the Responder is stateless until it receives an I2, it does not 439 need any special behaviour on sending R1 other than to send one 440 whenever it receives an I1. The Responder sends an R2 after receipt 441 every I2. The Responder does need to know that R2 was received by 442 the Initiator. Like in BEX, the Responder can learn this when it 443 starts receiving datagrams. 445 4.1.3.2. HIP States 447 +---------------------+---------------------------------------------+ 448 | State | Explanation | 449 +---------------------+---------------------------------------------+ 450 | UNASSOCIATED | State machine start | 451 | | | 452 | I1-SENT | Initiating base exchange | 453 | | | 454 | I2-SENT | Waiting to complete base exchange | 455 | | | 456 | R2-SENT | Waiting to complete base exchange | 457 | | | 458 | ESTABLISHED | HIP association established | 459 | | | 460 | CLOSING | HIP association closing, no data can be | 461 | | sent | 462 | | | 463 | CLOSED | HIP association closed, no data can be sent | 464 | | | 465 | E-FAILED | HIP exchange failed | 466 +---------------------+---------------------------------------------+ 468 Table 1: HIP States 470 4.1.3.3. HIP State Processes 472 System behavior in state I1-SENT, Table 2. 474 +---------------------+-----------------------------+ 475 | Trigger | Action | 476 +---------------------+-----------------------------+ 477 | t msec | Send I1 and stay at I1-SENT | 478 +---------------------+-----------------------------+ 480 Table 2: I1-SENT - Initiating HIP 482 System behavior in state I2-SENT, Table 3. 484 +---------------------+-----------------------------+ 485 | Trigger | Action | 486 +---------------------+-----------------------------+ 487 | t msec | Send I2 and stay at I2-SENT | 488 +---------------------+-----------------------------+ 490 Table 3: I2-SENT - Waiting to finish HIP 492 System behavior in state R2-SENT, Table 4. 494 +----------------------+-----------------------------+ 495 | Trigger | Action | 496 +----------------------+-----------------------------+ 497 | Receive duplicate I2 | Send R2 and stay at R2-SENT | 498 +----------------------+-----------------------------+ 500 Table 4: R2-SENT - Waiting to finish HIP 502 4.1.3.4. Simplified HIP State Diagram 504 The following diagram shows the major state transitions. Transitions 505 based on received packets implicitly assume that the packets are 506 successfully authenticated or processed. 508 +-+ +------------------------------+ 509 I1 received, send R1 | | | | 510 | v v | 511 Datagram to send +--------------+ I2 received, send R2 | 512 Send I1 +--------------| UNASSOCIATED |--------------+ | 513 +-+ | +-+ +--------------+ | | 514 send | | | | | | | 515 I1 t | | | | | Alg. not supported, send I1 | | 516 msec v | v | v | | 517 +---------+ I2 received, send R2 | | 518 +---->| I1-SENT |-------------------------------------+ | | 519 | +---------+ | | | 520 | | +----------------------+ | | +-+receive | 521 | send I2+-+ | R1 received, | I2 received, send R2 | | | | |I2, | 522 | t msec | v v send I2 | v v v | v send R2 | 523 | +---------+ | +---------+ | 524 | +->| I2-SENT |------------+ | R2-SENT |<--+ | 525 | | +---------+ +---------+ | | 526 | | | | | | 527 | | | data| | | 528 | |receive | or| | | 529 | |R1, send | EC timeout| receive I2,| | 530 | |I2 |R2 received +--------------+ | send R2| | 531 | | +----------->| ESTABLISHED |<--------+ | | 532 | | +--------------+ | | 533 | | | | | receive I2, send R2 | | 534 | | recv+------------+ | +------------------------+ | 535 | | CLOSE,| | | | 536 | | send| No packet sent| | | 537 | | CLOSE_ACK| /received for | timeout | | 538 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 539 | | | CLOSE +--->| CLOSING |--+ retransmit | | 540 | | | +---------+ CLOSE | | 541 +--|------------|----------------------+| | | | | | 542 +------------|-----------------------+ | | +-----------------+ | 543 | | +-----------+ +-------------------|----+ 544 | +-----------+ | receive CLOSE, CLOSE_ACK | | 545 | | | send CLOSE_ACK received or | | 546 | | | timeout | | 547 | | | (UAL+MSL) | | 548 | v v | | 549 | +--------+ receive I2, send R2 | | 550 +-----------------------| CLOSED |----------------------------+ | 551 +--------+ /-------------------------+ 552 ^ | \-------/ timeout (UAL+2MSL), 553 | | move to UNASSOCIATED 554 +-+ 555 CLOSE received, send CLOSE_ACK 557 4.1.4. HIP DEX Security Associations 559 HIP DEX establishes two Security Associations (SA), one for the 560 Diffie-Hellman derived key, or Master Key, and one for session or 561 Pair-wise Key. 563 4.1.4.1. Master Key SA 565 The Master Key SA is used to secure DEX parameters and authenticate 566 HIP packets. Since so little data will be protected by this SA it 567 can be very longed lived. 569 The Master Key SA contains the following elements. 571 Source HIT 573 Destination HIT 575 HIP_Encrypt Key 577 HIP_MAC Key 579 Both keys are extracted from the Diffie-Hellman derived key via 580 Section 6.3. Their length is determined by HIP_CIPHER. 582 4.1.4.2. Pair-wise Key SA 584 The Pair-wise Key SA is used to secure and authenticate user data. 585 It is refreshed (or rekeyed) using the UPDATE packet exchange. 587 The Pair-wise Key SA elements are defined by the data transform (e.g. 588 ESP_TRANSFORM [RFC5202]). 590 The secrets in ENCRYPTED_KEY from I2 and R2 are concatenated to form 591 the input to a Key Derivation Function (KDF). If the data transform 592 does not have its own KDF, then Section 6.3 is used. Even though 593 this input is randomly distributed, a KDF Extract phase may be needed 594 to get the proper length for input to the KDF Expand phase. 596 4.1.5. User Data Considerations 598 There is no difference in User Data Considerations between BEX and 599 DEX with one exception. Loss of state due to system reboot may be a 600 critical performance issue. Thus implementors MAY choose to use non- 601 volatile, secure storage for HIP state so it will survive system 602 reboot. This will limit state loss during reboots to only those 603 situtations that there is an SA timeout. 605 5. Packet Formats 607 5.1. HIP Parameters 609 The HIP Parameters are used to carry the public key associated with 610 the sender's HIT, together with related security and other 611 information. They consist of ordered parameters, encoded in TLV 612 format. 614 The following new parameter types are currently defined for DEX, in 615 addition to those defined for BEX. Also listed are BEX parameters 616 that have additional values for DEX. 618 For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and HOST_ID, 619 only the ECC values are valid in DEX. 621 +------------------+-------+----------+-----------------------------+ 622 | TLV | Type | Length | Data | 623 +------------------+-------+----------+-----------------------------+ 624 | ENCRYPTED_KEY | 643 | variable | Encrypted container of for | 625 | | | | key generation exchange | 626 | | | | | 627 | HIP_MAC_3 | 61507 | variable | CMAC-based message | 628 | | | | authentication code | 629 | | | | | 630 | HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT | 631 | | | | suites supported by the | 632 | | | | Responder | 633 +------------------+-------+----------+-----------------------------+ 635 5.1.1. HIT_SUITE_LIST 637 The HIT suites in DEX are limited to: 639 HIT suite ID 640 ECDH/DEX 8 642 The HIT_SUITE_LIST parameter contains a list of the supported HIT 643 suite IDs of the Responder. Since the HIT of the Initiator is a DEX 644 HIT, the Responder MUST only respond with a DEX HIT suite ID. 645 Currently, only one such suite ID has been defined. 647 5.1.2. ENCRYPTED_KEY 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Type | Length | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Reserved | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 / Encrypted value / 657 / / 658 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 660 / Nonce / 661 / +-------------------------------+ 662 / | Padding | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Type 643 666 Length length in octets, excluding Type, Length, and 667 Padding 668 Encrypted The value is encrypted using an encryption algorithm 669 value as defined in the HIP_CIPHER parameter. 670 Nonce Nonce included in encrypted text. 672 The ENCRYPTED parameter encapsulates a value and a nonce. The value 673 is typically a random number used in a key creation process and the 674 nonce is known to the receiver to validate successful decryption. 676 Some encryption algorithms require an IV (initialization vector). 677 The IV MUST be known to the receiver through some source other than 678 within the Encrypted_key block. For example the Puzzle value, I, can 679 be used as an IV. 681 Some encryption algorithms require that the data to be encrypted must 682 be a multiple of the cipher algorithm block size. In this case, the 683 above block of data MUST include additional padding, as specified by 684 the encryption algorithm. The size of the extra padding is selected 685 so that the length of the unencrypted data block is a multiple of the 686 cipher block size. The encryption algorithm may specify padding 687 bytes other than zero; for example, AES [FIPS.197.2001] uses the 688 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 689 remaining n bytes to fill the block each have the value n. This 690 yields an "unencrypted data" block that is transformed to an 691 "encrypted data" block by the cipher suite. This extra padding added 692 to the set of parameters to satisfy the cipher block alignment rules 693 is not counted in HIP TLV length fields, and this extra padding 694 should be removed by the cipher suite upon decryption. 696 Note that the length of the cipher suite output may be smaller or 697 larger than the length of the value and nonce to be encrypted, since 698 the encryption process may compress the data or add additional 699 padding to the data. 701 Once this encryption process is completed, the Encrypted_key data 702 field is ready for inclusion in the Parameter. If necessary, 703 additional Padding for 8-byte alignment is then added according to 704 the rules of TLV Format in [RFC5201-bis]. 706 5.1.3. HIP_MAC_3 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Type | Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | | 714 | CMAC | 715 / / 716 / +-------------------------------+ 717 | | Padding | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Type 61507 721 Length length in octets, excluding Type, Length, and 722 Padding 723 CMAC CMAC computed over the HIP packet, excluding the 724 HIP_MAC parameter itself. The checksum field MUST 725 be set to zero and the HIP header length in the HIP 726 common header MUST be calculated not to cover any 727 excluded parameters when the CMAC is calculated. The 728 size of the CMAC is the natural size of the AES block 729 depending on the AES key size. 731 The CMAC calculation and verification process is presented in 732 Section 6.2.1. 734 5.2. HIP Packets 736 DEX uses the same eight basic HIP packets (see [RFC5201-bis]) as BEX. 737 Four are for the HIP exchange, one is for updating, one is for 738 sending notifications, and two are for closing a HIP association. 739 There are some differences in the HIP parameters in the exchange 740 packets between BEX and DEX. This section will cover the DEX 741 packets. 743 An important difference between BEX and DEX HIP packets is that there 744 is NO HIP_SIGNATURE available in DEX. Thus R1 is completely 745 unprotected and can be spoof. The I2, R2, UPDATE, NOTIFY, CLOSE, and 746 CLOSE_ACK only have HIP_MAC_3 for packet authentication The 747 processing of these packets are changed accordingly. 749 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 750 header. The Next Header field in the header indicates if there is 751 additional data following the HIP header. The HIP packet, however, 752 MUST NOT be fragmented. This limits the size of the possible 753 additional data in the packet. 755 5.2.1. I1 - the HIP Initiator Packet 757 The HIP header values for the I1 packet: 759 Header: 760 Packet Type = 1 761 SRC HIT = Initiator's HIT 762 DST HIT = Responder's HIT, or NULL 764 IP ( HIP ( DH_GROUP_LIST ) ) 766 Minimum size = 40 bytes 768 The I1 packet contains the fixed HIP header and the Initiator's 769 DH_GROUP_LIST. 771 Valid control bits: none 773 The Initiator HIT MUST be a DEX HIT. That is the HIT Suite ID MUST 774 be of a DEX type. Currently only ECDH/DEX is defined. 776 The Initiator gets the Responder's HIT either from a DNS lookup of 777 the Responder's FQDN, from some other repository, or from a local 778 table. The Responder's HIT MUST be a DEX HIT. If the Initiator does 779 not know the Responder's HIT, it may attempt to use opportunistic 780 mode by using NULL (all zeros) as the Responder's HIT. See also "HIP 781 Opportunistic Mode" [RFC5201-bis]. 783 Since this packet is so easy to spoof even if it were signed, no 784 attempt is made to add to its generation or processing cost. 786 The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform 787 the Responder of its preferred DH Group IDs. Only ECDH Groups may be 788 included in this list. Note that the DH_GROUP_LIST in the I1 packet 789 is not protected by a MAC. 791 Implementations MUST be able to handle a storm of received I1 792 packets, discarding those with common content that arrive within a 793 small time delta, but distinguishing this from arriving at a set time 794 delta. This behaviour is the expected behaviour for an Initiator on 795 a network with high packet loss. The HIP state machine calls out 796 this behaviour in this case and the Initiator will stop sending I1 797 packets after it receives an R1 packet. 799 5.2.2. R1 - the HIP Responder Packet 801 The HIP header values for the R1 packet: 803 Header: 804 Packet Type = 2 805 SRC HIT = Responder's HIT 806 DST HIT = Initiator's HIT 808 IP ( HIP ( [ R1_COUNTER, ] 809 PUZZLE, 810 HIP_CIPHER, 811 HOST_ID, 812 HIT_SUITE_LIST, 813 DH_GROUP_LIST, 814 [ <, ECHO_REQUEST_UNSIGNED >i ]) 816 Minimum size = 120 bytes 818 Valid control bits: A 820 If the Responder's HI is an anonymous one, the A control MUST be set. 822 The Initiator's HIT MUST match the one received in I1. If the 823 Responder has multiple HIs, the Responder's HIT used MUST match 824 Initiator's request. If the Initiator used opportunistic mode, the 825 Responder may select freely among its HIs. See also "HIP 826 Opportunistic Mode" [RFC5201-bis]. 828 The R1 generation counter is used to determine the currently valid 829 generation of puzzles. The value is increased periodically, and it 830 is RECOMMENDED that it is increased at least as often as solutions to 831 old puzzles are no longer accepted. 833 The Puzzle contains a Random #I and the difficulty K. The difficulty 834 K indicates the number of lower-order bits, in the puzzle CMAC 835 result, that must be zeros; see Section 4.1.2. 837 The Initiator HIT does not provide the HOST_ID key size. The 838 Responder selects its HOST_ID based on the Initiator's preference 839 expressed in the DH_GROUP_LIST parameter in the I1. The Responder 840 sends back its own preference based on which it chose the HOST_ID as 841 DH_GROUP_LIST. This allows the Initiator to determine whether its 842 own DH_GROUP_LIST in the I1 was manipulated by an attacker. There is 843 a further risk that the Responder's DH_GROUP_LIST was manipulated by 844 an attacker, as R1 cannot be authenticated in DEX as it can in BEX. 845 Thus it is repeated in R2 allowing for a final check at that point. 847 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 848 discarded. 850 The HIP_CIPHER contains the encryption algorithms supported by the 851 Responder to protect the key exchange, in the order of preference. 852 All implementations MUST support the AES-CBC [RFC3602]. 854 The ECHO_REQUEST_UNSIGNED contains data that the sender wants to 855 receive unmodified in the corresponding response packet in the 856 ECHO_RESPONSE_UNSIGNED parameter. 858 5.2.3. I2 - the Second HIP Initiator Packet 860 The HIP header values for the I2 packet: 862 Header: 863 Type = 3 864 SRC HIT = Initiator's HIT 865 DST HIT = Responder's HIT 867 IP ( HIP ( [R1_COUNTER,] 868 SOLUTION, 869 HIP_CIPHER, 870 HOST_ID, 871 ENCRYPTED_KEY {DH, secret-x|I}, 872 [ ENCRYPTED {DH, ENCRYPTED_KEY {passwd, challenge } },] 873 HIP_MAC_3, 874 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 876 Minimum size = 180 bytes 878 Valid control bits: A 880 The HITs used MUST match the ones used previously. 882 If the Initiator's HI is an anonymous one, the A control MUST be set. 884 The Initiator MAY include an unmodified copy of the R1_COUNTER 885 parameter received in the corresponding R1 packet into the I2 packet. 887 The Solution contains the Random #I from R1 and the computed #J. The 888 low-order K bits of the CMAC(S, | ... | J) MUST be zero. 890 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 891 discarded. 893 The HIP_CIPHER contains the single encryption transform selected by 894 the Initiator, that will be used to protect the HI exchange. The 895 chosen transform MUST correspond to one offered by the Responder in 896 the R1. All implementations MUST support the AES-CBC transform 897 [RFC3602]. 899 The ECHO_RESPONSE_UNSIGNED contain the unmodified Opaque data copied 900 from the corresponding echo request parameter. 902 The ENCRYPTED_KEY contains an Initiator generated random secret x 903 that MUST be uniformly distributed that is concatenated with I from 904 the puzzle. The secret x's length matches the keysize of the 905 selected encryption transform. I from the puzzle is used as the IV 906 in the encryption transform. This acts as a nonce from the Responder 907 to prove freshness of the secret wrapping from the Initiator. I in 908 the ENCRYPTED block enables the Responder to validate a proper 909 decryption of the block. The key for the encryption is the 910 HIP_Encrypt key. 912 If the Initiator has prior knowledge that the Responder is expecting 913 a password authenication, the Initiator encrypts the 914 ECHO_REQUEST_UNSIGNED with the password, then wraps the ENCRYPTED 915 parameter in the secret x. I from the puzzle is used as the nonce 916 here as well. There is no signal within R1 for this behaviour. 917 Knowledge of password authencation must be externally configured. 919 The MAC is calculated over the whole HIP envelope, excluding any 920 parameters after the HIP_MAC_3, as described in Section 6.2.1. The 921 Responder MUST validate the HIP_MAC_3. 923 5.2.4. R2 - the Second HIP Responder Packet 925 The HIP header values for the R2 packet: 927 Header: 928 Packet Type = 4 929 SRC HIT = Responder's HIT 930 DST HIT = Initiator's HIT 932 IP ( HIP ( DH_GROUP_LIST, 933 ENCRYPTED_KEY {DH, secret-y|I}, 934 HIP_MAC_3) 936 Minimum size = 108 bytes 938 Valid control bits: none 940 The Responder repeats the DH_GROUP_LIST parameter in R2. This MUST 941 be the same list as included in R1. The DH_GROUP_LIST parameter is 942 repeated here because R2 is MACed and thus cannot be altered by an 943 attacker. This allows the Initiator to determine whether its own 944 DH_GROUP_LIST in the I1 was manipulated by an attacker. 946 The ENCRYPTED contains an Responder generated random secret y that 947 MUST be uniformly distributed that is concatenated with I from the 948 puzzle. The secret y's length matches the keysize of the selected 949 encryption transform. I from the puzzle is used as the IV in the 950 encryption transform. This acts as a nonce from the Initiator to 951 prove freshness of the secret wrapping from the Responder. I in the 952 ENCRYPTED block enables the Responder to validate a proper decryption 953 of the block. The key for the encryption is the HIP_Encrypt key. 955 The HIP_MAC_3 is calculated over the whole HIP envelope, with 956 Responder's HOST_ID parameter concatenated with the HIP envelope. 957 The HOST_ID parameter is removed after the CMAC calculation. The 958 procedure is described in Section 6.2.1. 960 The Initiator MUST validate the HIP_MAC_3. 962 5.3. ICMP Messages 964 When a HIP implementation detects a problem with an incoming packet, 965 and it either cannot determine the identity of the sender of the 966 packet or does not have any existing HIP association with the sender 967 of the packet, it MAY respond with an ICMP packet. Any such replies 968 MUST be rate-limited as described in [RFC2463]. In most cases, the 969 ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 970 for ICMPv6), with the Pointer field pointing to the field that caused 971 the ICMP message to be generated. 973 6. Packet Processing 975 Each host is assumed to have a single HIP protocol implementation 976 that manages the host's HIP associations and handles requests for new 977 ones. Each HIP association is governed by a conceptual state 978 machine, with states defined above in Section 4.1.3. The HIP 979 implementation can simultaneously maintain HIP associations with more 980 than one host. Furthermore, the HIP implementation may have more 981 than one active HIP association with another host; in this case, HIP 982 associations are distinguished by their respective HITs. It is not 983 possible to have more than one HIP association between any given pair 984 of HITs. Consequently, the only way for two hosts to have more than 985 one parallel association is to use different HITs, at least at one 986 end. 988 6.1. Solving the Puzzle 990 This subsection describes the puzzle-solving details. 992 In R1, the values I and K are sent in network byte order. Similarly, 993 in I2, the values I and J are sent in network byte order. The mac is 994 created by concatenating, in network byte order, the following data, 995 in the following order and using the CMAC algorithm with I as the 996 key: 998 128-bit Initiator's HIT, in network byte order, as appearing in 999 the HIP Payload in R1 and I2. 1001 128-bit Responder's HIT, in network byte order, as appearing in 1002 the HIP Payload in R1 and I2. 1004 n-bit random value J (where n is CMAC-len), in network byte order, 1005 as appearing in I2. 1007 In order to be a valid response puzzle, the K low-order bits of the 1008 resulting CMAC must be zero. 1010 Notes: 1012 i) All the data in the CMAC input MUST be in network byte order. 1014 ii) The order of the Initiator's and Responder's HITs are 1015 different in the R1 and I2 packets; see [RFC5201-bis]. Care must 1016 be taken to copy the values in the right order to the CMAC input. 1018 The following procedure describes the processing steps involved, 1019 assuming that the Responder chooses to precompute the R1 packets: 1021 Precomputation by the Responder: 1022 Sets up the puzzle difficulty K. 1023 Creates a R1 and caches it. 1025 Responder: 1026 Selects a suitable cached R1. 1027 Generates a random number I. 1028 Sends I and K in an R1. 1029 Saves I and K for a Delta time. 1031 Initiator: 1032 Generates repeated attempts to solve the puzzle until a matching J 1033 is found: 1034 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1035 Sends I and J in an I2. 1037 Responder: 1038 Verifies that the received I is a saved one. 1039 Finds the right K based on I. 1040 Computes V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1041 Rejects if V != 0 1042 Accept if V == 0 1044 6.2. HIP_MAC Calculation and Verification 1046 The following subsections define the actions for processing the 1047 HIP_MAC_3 parameter. 1049 6.2.1. CMAC Calculation 1051 Both the Initiator and the Responder should take some care when 1052 verifying or calculating the HIP_MAC_3. Specifically, the Responder 1053 should preserve other parameters than the HOST_ID when sending the 1054 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 1055 was received in the R1 packet. 1057 The scope of the calculation for HIP_MAC_3 is: 1059 CMAC: { HIP header | [ Parameters ] } 1061 where Parameters include all HIP parameters of the packet that is 1062 being calculated with Type values from 1 to (HIP_MAC's Type value - 1063 1) and exclude parameters with Type values greater or equal to 1064 HIP_MAC's Type value. 1066 During HIP_MAC calculation, the following applies: 1068 o In the HIP header, the Checksum field is set to zero. 1070 o In the HIP header, the Header Length field value is calculated to 1071 the beginning of the HIP_MAC parameter. 1073 Parameter order is described in [RFC5201-bis]. 1075 The HIP_MAC parameter is defined in Section 5.1.3. The CMAC 1076 calculation and verification process is as follows: 1078 Packet sender: 1080 1. Create the HIP packet, without the HIP_MAC or any other parameter 1081 with greater Type value than the HIP_MAC parameter has. 1083 2. Calculate the Header Length field in the HIP header. 1085 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1086 retrieved from KEYMAT as defined in Section 6.3. 1088 4. Add the HIP_MAC_3 parameter to the packet and any parameter with 1089 greater Type value than the HIP_MAC's (HIP_MAC_3's) that may 1090 follow. 1092 5. Recalculate the Length field in the HIP header. 1094 Packet receiver: 1096 1. Verify the HIP header Length field. 1098 2. Remove the HIP_MAC_3 parameter, as well as all other parameters 1099 that follow it with greater Type value, saving the contents if 1100 they will be needed later. 1102 3. Recalculate the HIP packet length in the HIP header and clear the 1103 Checksum field (set it to all zeros). 1105 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1106 defined in Section 6.3 and verify it against the received CMAC. 1108 5. Set Checksum and Header Length field in the HIP header to 1109 original values. 1111 6.3. HIP DEX KEYMAT Generation 1113 The HIP DEX KEYMAT process is used for both the Diffie-Hellman 1114 Derived Master key and the Encrypted secrets Pair-wise key. The 1115 former uses both the Extract and Expand phases, while the later MAY 1116 need the Extract and Expand phases if the key is longer than 128 1117 bits. Othewise it only needs the Expand phase. 1119 The Diffie-Hellman Derived Master key is exchanged in R1 and I2 and 1120 used in I2, R2. UPDATE, NOTIFY, and ACK packets. The Encrypted 1121 secrets Pair-wise key is not used in HIP, but is available as the 1122 datagram protection key. Some datagram protection mechanisms have 1123 their own Key Derivation Function, and if so that SHOULD be used 1124 rather than the HIP DEX KEYMAT. 1126 The KEYMAT has two components, CKDF-Extract and CKDF-Expand. The 1127 Extract function COMPRESSES a non-uniformly distributed key, as is 1128 the output of a Diffie-Hellman key derivation, to EXTRACT all the key 1129 entropy into a fixed length output. The Expand function takes either 1130 the output of the Extract function or directly uses a uniformly 1131 distributed key and EXPANDS the length of the key, repeatedly 1132 distributing the key entropy, to produce the keys needed. 1134 The CKDF-Extract function is following operation; the | operation 1135 denotes concatenation. 1137 CKDF-Extract(DHK, info, L) -> CK 1139 where 1141 info = sort(HIT-I | HIT-R) | "CKDF-Extract" 1142 BigK = Diffie-Hellman Derived or Session (x | y) Key 1143 I = I from PUZZLE Parameter 1145 The output CK is calculated as follows: 1147 CK = CMAC(I, BigK | info) 1149 The CKDF-Expand function is following operation; the | operation 1150 denotes concatenation. 1152 CKDF-Expand(CK, info, L) -> OKM 1154 where 1156 info = sort(HIT-I | HIT-R) | "CKDF-Expand" 1157 CK = CK from CKDF-Extract or (x | y) 1158 PRKlen = Length of PRK in octets 1159 maclen = Length of CMAC in octets = 128/8 = 16 1160 L length of output keying material in octets 1161 (<= 255*macLen) 1163 If PRKlen != macLen then PRK = CMAC(0^128, PRK) 1165 The output OKM is calculated as follows: 1167 N = ceil(L/macLen) 1168 T = T(1) | T(2) | T(3) | ... | T(N) 1169 OKM = first L octets of T 1171 where: 1173 T(0) = empty string (zero length) 1174 T(1) = CMAC(CK, T(0) | info | 0x01) 1175 T(2) = CMAC(CK, T(1) | info | 0x02) 1176 T(3) = CMAC(CK, T(2) | info | 0x03) 1177 ... 1179 (where the constant concatenated to the end of each T(n) is a 1180 single octet.) 1182 Sort(HIT-I | HIT-R) is defined as the network byte order 1183 concatenation of the two HITs, with the smaller HIT preceding the 1184 larger HIT, resulting from the numeric comparison of the two HITs 1185 interpreted as positive (unsigned) 128-bit integers in network byte 1186 order. 1188 x and y values are from the ENCRYPTED parameters from I2 and R2 1189 respectively. 1191 The initial keys are drawn sequentially in the order that is 1192 determined by the numeric comparison of the two HITs, with comparison 1193 method described in the previous paragraph. HOST_g denotes the host 1194 with the greater HIT value, and HOST_l the host with the lower HIT 1195 value. 1197 The drawing order for initial keys: 1199 HIP-gl encryption key for HOST_g's outgoing HIP packets 1201 HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1203 HIP-lg encryption key for HOST_l's outgoing HIP packets 1205 HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1207 The number of bits drawn for a given algorithm is the "natural" size 1208 of the keys. For the mandatory algorithms, the following sizes 1209 apply: 1211 AES 128 or 256 bits 1213 If other key sizes are used, they must be treated as different 1214 encryption algorithms and defined separately. 1216 6.4. Processing Incoming I1 Packets 1218 An implementation SHOULD reply to an I1 with an R1 packet, unless the 1219 implementation is unable or unwilling to set up a HIP association. 1220 An I1 in DEX is handled identically to BEX with the exception that in 1221 constructing the R1, the Responder SHOULD select a HIT that is 1222 constructed with the MUST algorithm, which is currently ECDH. 1224 6.4.1. R1 Management 1226 All compliant implementations MUST produce R1 packets. An R1 in DEX 1227 is handled identically to BEX. 1229 6.5. Processing Incoming R1 Packets 1231 A system receiving an R1 MUST first check to see if it has sent an I1 1232 to the originator of the R1 (i.e., it is in state I1-SENT). An R1 in 1233 DEX is handled identically to BEX with the following differences. 1235 If the system has been sending out a stream of I1 packets to work 1236 around high packet loss on a network, it stops sending the I1 packets 1237 AFTER successfully processing the R1 packet. 1239 There is no HIP_SIGNATURE on this packet. This is an 1240 unauthentication packet. 1242 The following steps define the conceptual processing rules for 1243 responding to an R1 packet that are different than in BEX: 1245 1. If the system is configured with an authentication password for 1246 the responder, it constructs the authentication response to 1247 include in the I2. 1249 2. The system prepares and sends an I2, as described in 1250 Section 5.2.3. The system MAY be configured to continually send 1251 this I2 until it receives and validates an R2. 1253 6.6. Processing Incoming I2 Packets 1255 Upon receipt of an I2, the system MAY perform initial checks to 1256 determine whether the I2 corresponds to a recent R1 that has been 1257 sent out, if the Responder keeps such state. An I2 in DEX is handled 1258 identically to BEX with the following differences. 1260 The HIP implementation SHOULD process the I2. This includes 1261 validation of the puzzle solution, extracting the ENCRYPTED key for 1262 processing I2, decrypting the Initiator's Host Identity, verifying 1263 the mac, creating state, and finally sending an R2. 1265 There is no HIP_SIGNATURE on this packet. Authentication is 1266 completely based on the HIP_MAC_3 parameter. 1268 The following steps define the conceptual processing rules for 1269 responding to an I2 packet: 1271 1. If the system's state machine is in the I2-SENT state, the system 1272 makes a comparison between its local and sender's HITs (similarly 1273 as in Section 6.3). If the local HIT is smaller than the 1274 sender's HIT, it should drop the I2 packet, and continue using 1275 the R1 received and I2 sent to the peer earlier. Otherwise, the 1276 system should process the received I2 packet and drop any 1277 previously derived Diffie-Hellman keying material Kij and 1278 ENCRYPTED keying material it might have formed upon sending the 1279 I2 previously. The peer Diffie-Hellman key, ENCRYPTED keying 1280 material and the nonce J are taken from the just arrived I2 1281 packet. The local Diffie-Hellman key and the nonce I are the 1282 ones that were earlier sent in the R1 packet. 1284 2. The system MUST validate the solution to the puzzle by computing 1285 the mac described in Section 5.2.3 using the CMAC algorithm. 1287 3. The system must extract the keying material from the ENCRYPTED 1288 parameter. This key is used to derive the HIP data keys. 1290 4. If the checks above are valid, then the system proceeds with 1291 further I2 processing; otherwise, it discards the I2 and its 1292 state machine remains in the same state. If the system has been 1293 sending a stream of R1 packets to the HIT in the I2 the system 1294 stops sending the R1s. 1296 6.7. Processing Incoming R2 Packets 1298 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1299 results in the R2 being dropped and the state machine staying in the 1300 same state. If an R2 is received in state I2-SENT, it SHOULD be 1301 processed. 1303 There is no HIP_SIGNATURE on this packet. Authentication is 1304 completely based on the HIP_MAC_3 parameter. 1306 The conceptual processing rules for an incoming R2 packet in DEX are 1307 identical to BEX with the following differences. 1309 1. The system checks the DH_GROUP_LIST as in R1 packet processing. 1310 If the list is different from R1's there may have been a DH 1311 downgrade attack against the unprotected R1 packet. If the 1312 DH_GROUP_LIST presents a better list than recieved in the R1 1313 packet, the system may either resend I1 within the retry bounds 1314 or abandon the HIP exchange. 1316 2. The system must extract the keying material from the ENCRYPTED 1317 parameter. This key is concatanated with that sent in the I2 1318 packet to form the HIP data keys. 1320 6.8. Sending UPDATE Packets 1322 A host sends an UPDATE packet when it wants to update some 1323 information related to a HIP association. DEX UPDATE handling is the 1324 similar in DEX as in BEX. The key difference is NO HIP_SIGNATURE. 1326 6.9. Handling State Loss 1328 In the case of system crash and unanticipated state loss, the system 1329 SHOULD delete the corresponding HIP state, including the keying 1330 material. That is, the state SHOULD NOT be stored on stable storage. 1331 If the implementation does drop the state (as RECOMMENDED), it MUST 1332 also drop the peer's R1 generation counter value, unless a local 1333 policy explicitly defines that the value of that particular host is 1334 stored. An implementation MUST NOT store R1 generation counters by 1335 default, but storing R1 generation counter values, if done, MUST be 1336 configured by explicit HITs. 1338 7. HIP Policies 1340 There are a number of variables that will influence the HIP exchanges 1341 that each host must support. All HIP implementations MUST support 1342 more than one simultaneous HI, at least one of which SHOULD be 1343 reserved for anonymous usage. Although anonymous HIs will be rarely 1344 used as Responders' HIs, they will be common for Initiators. Support 1345 for more than two HIs is RECOMMENDED. 1347 Many Initiators would want to use a different HI for different 1348 Responders. The implementations SHOULD provide for an ACL of 1349 Initiator's HIT to Responder's HIT. This ACL SHOULD also include 1350 preferred transform and local lifetimes. 1352 The value of K used in the HIP R1 packet can also vary by policy. K 1353 should never be greater than 20, but for trusted partners it could be 1354 as low as 0. 1356 Responders would need a similar ACL, representing which hosts they 1357 accept HIP exchanges, and the preferred transform and local 1358 lifetimes. Wildcarding SHOULD be supported for this ACL also. 1360 8. Security Considerations 1362 HIP is designed to provide secure authentication of hosts. HIP also 1363 attempts to limit the exposure of the host to various denial-of- 1364 service and man-in-the-middle (MitM) attacks. In so doing, HIP 1365 itself is subject to its own DoS and MitM attacks that potentially 1366 could be more damaging to a host's ability to conduct business as 1367 usual. 1369 HIP DEX replaces the SIGMA authenticated Diffie-Hellman key exchange 1370 of BEX with a random generated key exchange encrypted by a Diffie- 1371 Hellman derived key. Both the Initiator and Responder contribute to 1372 this key. 1374 The strength of the key is based on the quality of the secrets 1375 generated the Initiator and Responder. Since the Initiator is 1376 commonly a sensor there is a natural concern about the quality of 1377 its random number generator. 1379 DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1380 compromised, ALL HIP connections protected with that HI are 1381 compromised. 1383 The puzzle mechanism using CMAC may need further study that it 1384 does present the desired level of difficulty. 1386 The DEX HIT extraction MAY present new attack opportunities; 1387 further study is needed. 1389 The R1 packet is unprotected and offers an attacker new resource 1390 attacks against the Initiator. This is mitigated by the Initator 1391 only processing a received R1 when it has sent an I1. This is 1392 another DoS attack, but for battery powered Initiators, it could be a 1393 concern. 1395 9. IANA Considerations 1397 IANA has reserved protocol number 139 for the Host Identity Protocol. 1399 The following HIT suites are defined for DEX HIT generation. 1401 +-------+------------+----------------------+-----------------------+ 1402 | Index | Hash | Signature algorithm | Description | 1403 | | function | family | | 1404 +-------+------------+----------------------+-----------------------+ 1405 | 5 | LTRUNC | ECDH | ECDH HI truncated to | 1406 | | | | 96 bits | 1407 +-------+------------+----------------------+-----------------------+ 1409 Table 5: HIT Suites 1411 10. Acknowledgments 1413 The drive to put HIP on a cryptographic 'Diet' came out of a number 1414 of discussions with sensor vendors at IEEE 802.15 meetings. David 1415 McGrew was very 1417 11. References 1419 11.1. Normative References 1421 [I-D.mcgrew-fundamental-ecc] McGrew, D., Igoe, K., and M. Salter, 1422 "Fundamental Elliptic Curve 1423 Cryptography Algorithms", 1424 draft-mcgrew-fundamental-ecc-03 (work 1425 in progress), May 2010. 1427 [RFC2119] Bradner, S., "Key words for use in RFCs 1428 to Indicate Requirement Levels", 1429 BCP 14, RFC 2119, March 1997. 1431 [RFC2460] Deering, S. and R. Hinden, "Internet 1432 Protocol, Version 6 (IPv6) 1433 Specification", RFC 2460, 1434 December 1998. 1436 [RFC2463] Conta, A. and S. Deering, "Internet 1437 Control Message Protocol (ICMPv6) for 1438 the Internet Protocol Version 6 (IPv6) 1439 Specification", RFC 2463, 1440 December 1998. 1442 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 1443 "The AES-CBC Cipher Algorithm and Its 1444 Use with IPsec", RFC 3602, 1445 September 2003. 1447 [RFC3972] Aura, T., "Cryptographically Generated 1448 Addresses (CGA)", RFC 3972, March 2005. 1450 [RFC4309] Housley, R., "Using Advanced Encryption 1451 Standard (AES) CCM Mode with IPsec 1452 Encapsulating Security Payload (ESP)", 1453 RFC 4309, December 2005. 1455 [RFC4843-bis] Laganier, J. and F. Dupont, "An IPv6 1456 Prefix for Overlay Routable 1457 Cryptographic Hash Identifiers 1458 (ORCHID)", 1459 draft-ietf-hip-rfc4843-bis-00 (work in 1460 progress), August 2010. 1462 [RFC5201-bis] Moskowitz, R., Nikander, P., Jokela, 1463 P., Henderson, T., and T. Heer, "Host 1464 Identity Protocol", 1465 draft-moskowitz-hip-rfc5201-bis-04 1466 (work in progress), January 2011. 1468 [RFC5202] Jokela, P., Moskowitz, R., and P. 1469 Nikander, "Using the Encapsulating 1470 Security Payload (ESP) Transport Format 1471 with the Host Identity Protocol (HIP)", 1472 RFC 5202, April 2008. 1474 11.2. Informative References 1476 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 1477 "Analysis of the HIP Base Exchange 1478 Protocol", in Proceedings of 10th 1479 Australasian Conference on Information 1480 Security and Privacy, July 2003. 1482 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 1483 Service via Algorithmic Complexity 1484 Attacks", in Proceedings of Usenix 1485 Security Symposium 2003, Washington, 1486 DC., August 2003. 1488 [FIPS.197.2001] National Institute of Standards and 1489 Technology, "Advanced Encryption 1490 Standard (AES)", FIPS PUB 197, 1491 November 2001, . 1495 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 1496 Architecture", 1497 draft-ietf-hip-rfc4423-bis-01 (work in 1498 progress), August 2010. 1500 [IEEE.802-11.2007] "Information technology - 1501 Telecommunications and information 1502 exchange between systems - Local and 1503 metropolitan area networks - Specific 1504 requirements - Part 11: Wireless LAN 1505 Medium Access Control (MAC) and 1506 Physical Layer (PHY) Specifications", 1507 IEEE Standard 802.11, June 2007, . 1511 [IEEE.802-15-4.2006] "Information technology - 1512 Telecommunications and information 1513 exchange between systems - Local and 1514 metropolitan area networks - Specific 1515 requirements - Part 15.4: Wireless 1516 Medium Access Control (MAC) and 1517 Physical Layer (PHY) Specifications for 1518 Low-Rate Wireless Personal Area 1519 Networks (WPANs)", IEEE Standard 1520 802.15.4, September 2006, . 1524 [RFC2434] Narten, T. and H. Alvestrand, 1525 "Guidelines for Writing an IANA 1526 Considerations Section in RFCs", 1527 BCP 26, RFC 2434, October 1998. 1529 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 1530 Cryptography Specification Version 1531 2.0", RFC 2898, September 2000. 1533 [RFC4306] Kaufman, C., "Internet Key Exchange 1534 (IKEv2) Protocol", RFC 4306, 1535 December 2005. 1537 Appendix A. Using Responder Puzzles 1539 As mentioned in Section 4.1.1, the Responder may delay state creation 1540 and still reject most spoofed I2s by using a number of pre-calculated 1541 R1s and a local selection function. This appendix defines one 1542 possible implementation in detail. The purpose of this appendix is 1543 to give the implementors an idea on how to implement the mechanism. 1544 If the implementation is based on this appendix, it MAY contain some 1545 local modification that makes an attacker's task harder. 1547 The Responder creates a secret value S, that it regenerates 1548 periodically. The Responder needs to remember the two latest values 1549 of S. Each time the S is regenerated, the R1 generation counter 1550 value is incremented by one and the Responder generates an R1 packet. 1552 When the Initiator sends the I1 packet for initializing a connection, 1553 the Responder gets the HIT and IP address from the packet, and 1554 generates an I value for the puzzle. 1556 I value calculation: 1557 I = Ltrunc( CMAC ( S, HIT-I | HIT-R | IP-I | IP-R ), n) 1558 where n = CMAC-len 1560 From an incoming I2 packet, the Responder gets the required 1561 information to validate the puzzle: HITs, IP addresses, and the 1562 information of the used S value from the R1_COUNTER. Using these 1563 values, the Responder can regenerate the I, and verify it against the 1564 I received in the I2 packet. If the I values match, it can verify 1565 the solution using I, J, and difficulty K. If the I values do not 1566 match, the I2 is dropped. 1568 puzzle_check: 1569 V := Ltrunc( CMAC( I2.I | I2.I, I2.hit_i | I2.hit_r | I2.J ), K ) 1570 if V != 0, drop the packet 1572 If the puzzle solution is correct, the I and J values are stored for 1573 later use. They are used as input material when keying material is 1574 generated. 1576 Keeping state about failed puzzle solutions depends on the 1577 implementation. Although it is possible for the Responder not to 1578 keep any state information, it still may do so to protect itself 1579 against certain attacks (see Section 4.1.1). 1581 Appendix B. Generating a Public Key Encoding from an HI 1583 The following pseudo-code illustrates the process to generate a 1584 public key encoding from an HI for ECDH. 1586 Author's Address 1588 Robert Moskowitz 1589 Verizon Telcom and Business 1590 1000 Bent Creek Blvd, Suite 200 1591 Mechanicsburg, PA 1592 USA 1594 EMail: robert.moskowitz@verizonbusiness.com