idnits 2.17.1 draft-moskowitz-hip-rg-dex-06.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.2011]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2012) is 4325 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) == Missing Reference: 'RFC2410' is mentioned on line 645, but not defined == Unused Reference: 'RFC2460' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 1462, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1465, but no explicit reference was found in the text == Unused Reference: 'RFC6090' is defined on line 1480, but no explicit reference was found in the text == Unused Reference: 'AUR03' is defined on line 1493, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1527, 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) == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-00 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-08 ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 4 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 May 25, 2012 5 Expires: November 26, 2012 7 HIP Diet EXchange (DEX) 8 draft-moskowitz-hip-rg-dex-06 10 Abstract 12 This document specifies the details of the Host Identity Protocol 13 Diet EXchange (HIP DEX). HIP DEX is a variant of the HIP Base 14 EXchange (HIP BEX) [RFC5201-bis] specifically designed to use as few 15 crypto primitives as possible yet still deliver the same class of 16 security features as HIP BEX. 18 The design goal of HIP DEX is to be usable by sensor devices that are 19 memory and processor constrained. Like HIP BEX it is expected to be 20 used together with another suitable security protocol, such as the 21 Encapsulated Security Payload (ESP). HIP DEX can also be used 22 directly as a keying mechanism for a MAC layer security protocol as 23 is supported by IEEE 802.15.4 [IEEE.802-15-4.2011]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 26, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4 73 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 75 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5 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. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . . 15 90 5.1.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . 16 91 5.1.3. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 16 92 5.1.4. HIP_MAC_3 . . . . . . . . . . . . . . . . . . . . . . 18 93 5.2. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.2.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 19 95 5.2.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 20 96 5.2.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 21 97 5.2.4. R2 - the Second HIP Responder Packet . . . . . . . . . 22 98 5.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 23 99 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 23 100 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 24 101 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . . 25 102 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . . 25 103 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 26 104 6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . . 28 105 6.4.1. R1 Management . . . . . . . . . . . . . . . . . . . . 29 106 6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . . 29 107 6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . . 29 108 6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . . 30 109 6.8. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 31 110 6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 31 111 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 114 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 116 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 117 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 118 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 35 119 Appendix B. Generating a Public Key Encoding from an HI . . . . . 36 121 1. Introduction 123 This memo specifies the details of the Host Identity Protocol Diet 124 EXchange (HIP DEX). HIP DEX uses the smallest possible set of 125 established cryptographic primitives, in such a manner that does not 126 change our understanding of their behaviour, yet in a different 127 formulation to achieve assertions normally met with different 128 primitives. 130 HIP DEX builds on the HIP Base Exchange (HIP BEX) [RFC5201-bis], and 131 only the differences between BEX and DEX are documented here. 133 There are a few key differences between BEX and DEX. 135 Minimum collection of cryptographic primitives. 137 AES-CTR for symmetric encryption and AES-CMAC for MACing 138 functions. 140 Static Elliptic Curve Diffie-Hellman key pairs used to encrypt 141 the session key. 143 A simple truncation function for HIT generation. 145 Forfeit of Perfect Forward Secrecy with the dropping of ephemeral 146 Diffie-Hellman. 148 Forfeit of digital signatures with the removal of a hash function. 149 Reliance of DH derived key used in HIP_MAC to prove ownership of 150 the private key. 152 Provide a Password Authentication within the exchange. This may 153 be supported by BEX as well, but not defined there. 155 Operate in an aggressive retransmission manner to deal with the 156 high packet loss nature of sensor networks. 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 exchanges Static Diffie-Hellman keys in the 2nd and 3rd packets, 165 transmits session secrets in the 3rd and 4th packets, and 166 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. The model is fairly 172 equivalent to 802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise 173 Transient Key, but handled in a single exchange. 175 HIP DEX does not have the option of encrypting the Host Identity of 176 the Initiator in the 3rd packet. The Responder's Host Identity is 177 also not protected. Thus there is no attempt at anonymity as in BEX. 179 Data packets start to flow after the 4th packet. Simiarly to HIP 180 BEX, DEX does not have an explicit transition to connected state for 181 the Responder. 183 This is learned when the Responder starts receiving protected 184 datagrams, indicating that the Initiator received the R2 packet. As 185 such the Intitator should take care to NOT send the first data packet 186 until some delta time after it received the R2 packet. This is to 187 provide time for the Responder to process any aggressively 188 retransmitted I2 packets. 190 An existing HIP association can be updated using the update mechanism 191 defined in this document, and when the association is no longer 192 needed, it can be closed using the defined closing mechanism. 194 Finally, HIP is designed as an end-to-end authentication and key 195 establishment protocol, to be used with Encapsulated Security Payload 196 (ESP) [rfc5202-bis] and other end-to-end security protocols. The 197 base protocol does not cover all the fine-grained policy control 198 found in Internet Key Exchange (IKE) [RFC4306] that allows IKE to 199 support complex gateway policies. Thus, HIP is not a replacement for 200 IKE. 202 1.2. Memo Structure 204 The rest of this memo is structured as follows. Section 2 defines 205 the central keywords, notation, and terms used throughout the rest of 206 the document. Section 4 gives an overview of the HIP base exchange 207 protocol. Section 6 define the rules for packet processing. 208 Finally, Sections 7, 8, and 9 discuss policy, security, and IANA 209 considerations, respectively. 211 2. Terms and Definitions 213 2.1. Requirements Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC 2119 [RFC2119]. 219 2.2. Notation 221 [x] indicates that x is optional. 223 {x} indicates that x is encrypted. 225 X(y) indicates that y is a parameter of X. 227 i indicates that x exists i times. 229 --> signifies "Initiator to Responder" communication (requests). 231 <-- signifies "Responder to Initiator" communication (replies). 233 | signifies concatenation of information-- e.g., X | Y is the 234 concatenation of X with Y. 236 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 237 the mac function M on the input x. 239 3. The DEX Host Identifier Tag (HIT) and Its Representations 241 The DEX Host Identity Tag (HIT) is distinguished in two ways from the 242 BEX HIT: 244 The HIT SUITE ID Section 5.1.2 is ONLY a DEX ID. 246 The HIT DEX HIT is not generated via a cryptographic hash. Rather 247 it is a truncation of the Elliptic Curve Host Identity. 249 3.1. Host Identity Tag (HIT) 251 The DEX Host Identity Tag is a 128-bit value -- a truncation of the 252 Host Identifier appended with a prefix. There are two advantages of 253 using a Host Identity Tag over the actual Host Identity public key in 254 protocols. Firstly, its fixed length makes for easier protocol 255 coding and also better manages the packet size cost of this 256 technology. Secondly, it presents a consistent format to the 257 protocol whatever underlying identity technology is used. 259 BEX uses RFC 4843-bis [RFC4843-bis] specified 128-bit hash-based 260 identifiers, called Overlay Routable Cryptographic Hash Identifiers 261 (ORCHIDs). Their prefix, allocated from the IPv6 address block, is 262 defined in [RFC4843-bis]. 264 In DEX, a cryptographic hash is NOT used to form the HIT. Rather the 265 HI is truncated to 96 bits. 267 3.2. Generating a HIT from an HI 269 The DEX HIT is not an ORCHID, as there is no hash function in DEX. 270 Since a HI that is an ECDH key is directly computed from a random 271 number it is already collision resistant. The DEX HIT is the left- 272 truncated 96 bits of the HI. This 96 bit value is used in place of 273 the hash in the ORCHID. The HIT suite (see Section 9) is used for 274 the four bits of the Orchid Generation Algorithm (OGA) field in the 275 ORCHID. The same IPv6 prefix used in BEX is used for DEX. 277 4. Protocol Overview 279 The following material is an overview of the differences between the 280 BEX and DEX implementations of the HIP protocol. It is expected that 281 [RFC5201-bis] is well understood first. 283 4.1. Creating a HIP Association 285 By definition, the system initiating a HIP exchange is the Initiator, 286 and the peer is the Responder. This distinction is forgotten once 287 the base exchange completes, and either party can become the 288 Initiator in future communications. 290 The HIP Diet EXchange serves to manage the establishment of state 291 between an Initiator and a Responder. The first packet, I1, 292 initiates the exchange, and the last three packets, R1, I2, and R2, 293 constitute an authenticated secret key wrapped by a Diffie-Hellman 294 derived key for session key generation. The HIP association keys are 295 drawn from this keying material. If other cryptographic keys are 296 needed, e.g., to be used with ESP, they are expected to be drawn from 297 the same keying material. 299 The second packet, R1, starts the actual exchange. It contains a 300 puzzle -- a cryptographic challenge that the Initiator must solve 301 before continuing the exchange. The level of difficulty of the 302 puzzle can be adjusted based on level of trust with the Initiator, 303 current load, or other factors. The R1 also contains lists of 304 cryptographic algorithms supported by the Responder. Based on these 305 lists, the Initiator can continue, abort, or restart the base 306 exchange with a different selection of cryptographic algorithms. 308 In the I2 packet, the Initiator must display the solution to the 309 received puzzle. Without a correct solution, the I2 message is 310 discarded. The I2 also contains a key wrap parameter that carries 311 the key for the Responder. This key is only half the final session 312 key. The packet is authenticated by the sender (Initiator). 314 The R2 packet finalizes the base exchange. The R2 contains a key 315 wrap parameter that carries the rest of the key for the Initiator. 316 The packet is authenticated by the sender (Initiator). 318 The base exchange is illustrated below. The term "key" refers to the 319 Host Identity public key, "secret" refers to a random value encrypted 320 by a public key, and "sig" represents a signature using such a key. 321 The packets contain other parameters not shown in this figure. 323 Initiator Responder 325 I1: 326 --------------------------> 327 select precomputed R1 328 R1: puzzle, PK 329 <------------------------- 330 solve puzzle remain stateless 331 PK Encrypt x 332 I2: solution, PK, ECR(DH,secret x), mac 333 --------------------------> 334 check puzzle 335 check mac 336 PK Encrypt y 337 R2: PK, ECR(DH,secret y), mac 338 <-------------------------- 339 check mac 341 4.1.1. HIP Puzzle Mechanism 343 The purpose of the HIP puzzle mechanism is to protect the Responder 344 from a number of denial-of-service threats. It allows the Responder 345 to delay state creation until receiving I2. Furthermore, the puzzle 346 allows the Responder to use a fairly cheap calculation to check that 347 the Initiator is "sincere" in the sense that it has churned CPU 348 cycles in solving the puzzle. 350 DEX uses the CMAC function instead of a hash function as in BEX. 352 The puzzle mechanism has been explicitly designed to give space for 353 various implementation options. It allows a Responder implementation 354 to completely delay session-specific state creation until a valid I2 355 is received. In such a case, a correctly formatted I2 can be 356 rejected only once the Responder has checked its validity by 357 computing one CMAC function. On the other hand, the design also 358 allows a Responder implementation to keep state about received I1s, 359 and match the received I2s against the state, thereby allowing the 360 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 aggressive transmission 425 feature to provide better performance in sensor networks with high 426 packet loss. The following section 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-bis]). 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 only one difference in User Data Considerations between BEX 599 and DEX. Loss of state due to system reboot may be a critical 600 performance issue. Thus implementors MAY choose to use non-volatile, 601 secure storage for HIP state so that it survives system reboot. This 602 will limit state loss during reboots to only those situtations that 603 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 parameters, ordered according to their 612 numeric type number and encoded in TLV 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_HELLMAN, 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 for key | 625 | | | | generation exchange | 626 | | | | | 627 | HIP_MAC_3 | 61507 | variable | CMAC-based message | 628 | | | | authentication code | 629 | | | | | 630 | HIP_CIPHER | 579 | variable | List of HIP encryption | 631 | | | | algorithms | 632 | | | | | 633 | HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT | 634 | | | | suites supported by the | 635 | | | | Responder | 636 +------------------+-------+----------+-----------------------------+ 638 5.1.1. HIP_CIPHER 640 The HIP ciphers in DEX are limited to: 642 Suite ID Value 644 RESERVED 0 645 NULL-ENCRYPT 1 ([RFC2410]) 646 AES-128-CTR 5 ([RFC3686]) 648 The HIP_CIPHER parameter is limited to NULL or AES-CTR. 650 5.1.2. HIT_SUITE_LIST 652 The HIT suites in DEX are limited to: 654 HIT suite ID 655 ECDH/DEX 8 657 The HIT_SUITE_LIST parameter contains a list of the supported HIT 658 suite IDs of the Responder. Since the HIT of the Initiator is a DEX 659 HIT, the Responder MUST only respond with a DEX HIT suite ID. 660 Currently, only one such suite ID has been defined. 662 5.1.3. ENCRYPTED_KEY 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type | Length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Reserved | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 / Encrypted value / 672 / / 673 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 675 / Nonce / 676 / +-------------------------------+ 677 / | Padding | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Type 643 681 Length length in octets, excluding Type, Length, and 682 Padding 683 Encrypted The value is encrypted using an encryption algorithm 684 value as defined in the HIP_CIPHER parameter. 685 Nonce Nonce included in encrypted text. 687 The ENCRYPTED parameter encapsulates a value and a nonce. The value 688 is typically a random number used in a key creation process and the 689 nonce is known to the receiver to validate successful decryption. 691 Some encryption algorithms require an IV (initialization vector). 692 The IV MUST be known to the receiver through some source other than 693 within the Encrypted_key block. For example the Puzzle value, I, can 694 be used as an IV. 696 Text on CTR use here. 698 Some encryption algorithms require that the data to be encrypted must 699 be a multiple of the cipher algorithm block size. In this case, the 700 above block of data MUST include additional padding, as specified by 701 the encryption algorithm. The size of the extra padding is selected 702 so that the length of the unencrypted data block is a multiple of the 703 cipher block size. The encryption algorithm may specify padding 704 bytes other than zero; for example, AES [FIPS.197.2001] uses the 705 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 706 remaining n bytes to fill the block each have the value n. This 707 yields an "unencrypted data" block that is transformed to an 708 "encrypted data" block by the cipher suite. This extra padding added 709 to the set of parameters to satisfy the cipher block alignment rules 710 is not counted in HIP TLV length fields, and this extra padding 711 should be removed by the cipher suite upon decryption. 713 Note that the length of the cipher suite output may be smaller or 714 larger than the length of the value and nonce to be encrypted, since 715 the encryption process may compress the data or add additional 716 padding to the data. 718 Once this encryption process is completed, the Encrypted_key data 719 field is ready for inclusion in the Parameter. If necessary, 720 additional Padding for 8-byte alignment is then added according to 721 the rules of TLV Format in [RFC5201-bis]. 723 5.1.4. HIP_MAC_3 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Type | Length | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | 731 | CMAC | 732 / / 733 / +-------------------------------+ 734 | | Padding | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Type 61507 738 Length length in octets, excluding Type, Length, and 739 Padding 740 CMAC CMAC computed over the HIP packet, excluding the 741 HIP_MAC parameter itself. The checksum field MUST 742 be set to zero and the HIP header length in the HIP 743 common header MUST be calculated not to cover any 744 excluded parameters when the CMAC is calculated. The 745 size of the CMAC is the natural size of the AES block 746 depending on the AES key size. 748 The CMAC calculation and verification process is presented in 749 Section 6.2.1. 751 5.2. HIP Packets 753 DEX uses the same eight basic HIP packets (see [RFC5201-bis]) as in 754 BEX. Four are for the HIP exchange, one is for updating, one is for 755 sending notifications, and two are for closing a HIP association. 756 There are some differences in the HIP parameters in the exchange 757 packets between BEX and DEX. This section will cover the DEX 758 packets. 760 An important difference between BEX and DEX HIP packets is that there 761 is no HIP_SIGNATURE parameter available in DEX. Thus R1 is 762 completely unprotected and can be spoofed. The I2, R2, UPDATE, 763 NOTIFY, CLOSE, and CLOSE_ACK parameters only have a HIP_MAC_3 764 parameter for packet authentication. The processing of these packets 765 are changed accordingly. 767 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 768 header. The Next Header field in the header indicates if there is 769 additional data following the HIP header. The HIP packet, however, 770 MUST NOT be fragmented. This limits the size of the possible 771 additional data in the packet. 773 5.2.1. I1 - the HIP Initiator Packet 775 The HIP header values for the I1 packet: 777 Header: 778 Packet Type = 1 779 SRC HIT = Initiator's HIT 780 DST HIT = Responder's HIT, or NULL 782 IP ( HIP ( DH_GROUP_LIST ) ) 784 Minimum size = 40 bytes 786 The I1 packet contains the fixed HIP header and the Initiator's 787 DH_GROUP_LIST. 789 Valid control bits: none 791 The Initiator HIT MUST be a DEX HIT. The HIT Suite ID MUST be of a 792 DEX type. Currently only ECDH/DEX is defined. 794 The Initiator receives the Responder's HIT either from a DNS lookup 795 of the Responder's FQDN, from some other repository, or from a local 796 table. The Responder's HIT MUST be a DEX HIT. If the Initiator does 797 not know the Responder's HIT, it may attempt to use opportunistic 798 mode by using NULL (all zeros) as the Responder's HIT. See also "HIP 799 Opportunistic Mode" [RFC5201-bis]. 801 Since this packet is so easy to spoof even if it were signed, no 802 attempt is made to add to its generation or processing cost. 804 The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform 805 the Responder of its preferred DH Group IDs. Only ECDH Groups may be 806 included in this list. Note that the DH_GROUP_LIST in the I1 packet 807 is not protected by a MAC. 809 Implementations MUST be able to handle a storm of received I1 810 packets, discarding those with common content that arrive within a 811 small time delta, but distinguishing this from arriving at a set time 812 delta. This behaviour is the expected behaviour for an Initiator on 813 a network with high packet loss. The HIP state machine calls out 814 this behaviour in this case and the Initiator will stop sending I1 815 packets after it receives an R1 packet. 817 5.2.2. R1 - the HIP Responder Packet 819 The HIP header values for the R1 packet: 821 Header: 822 Packet Type = 2 823 SRC HIT = Responder's HIT 824 DST HIT = Initiator's HIT 826 IP ( HIP ( [ R1_COUNTER, ] 827 PUZZLE, 828 HIP_CIPHER, 829 HOST_ID, 830 HIT_SUITE_LIST, 831 DH_GROUP_LIST, 832 [ <, ECHO_REQUEST_UNSIGNED >i ]) 834 Minimum size = 120 bytes 836 Valid control bits: A 838 If the Responder's HI is an anonymous one, the A control MUST be set. 840 The Initiator's HIT MUST match the one received in I1. If the 841 Responder has multiple HIs, the Responder's HIT used MUST match 842 Initiator's request. If the Initiator used opportunistic mode, the 843 Responder may select freely among its HIs. See also "HIP 844 Opportunistic Mode" [RFC5201-bis]. 846 The R1 generation counter is used to determine the currently valid 847 generation of puzzles. The value is increased periodically, and it 848 is RECOMMENDED that it is increased at least as often as solutions to 849 old puzzles are no longer accepted. 851 The Puzzle contains a Random #I and the difficulty K. The difficulty 852 K indicates the number of lower-order bits, in the puzzle CMAC 853 result, that MUST be zeros; see Section 4.1.2. 855 The Initiator HIT does not provide the HOST_ID key size. The 856 Responder selects its HOST_ID based on the Initiator's preference 857 expressed in the DH_GROUP_LIST parameter in the I1. The Responder 858 sends back its own preference based on which it chose the HOST_ID as 859 DH_GROUP_LIST. This allows the Initiator to determine whether its 860 own DH_GROUP_LIST in the I1 was manipulated by an attacker. There is 861 a further risk that the Responder's DH_GROUP_LIST was manipulated by 862 an attacker, as R1 cannot be authenticated in DEX as it can in BEX. 863 Thus it is repeated in R2 allowing for a final check at that point. 865 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 866 discarded. 868 The HIP_CIPHER contains the encryption algorithms supported by the 869 Responder to protect the key exchange, in the order of preference. 870 All implementations MUST support the AES-CBC [RFC3602]. 872 The ECHO_REQUEST_UNSIGNED contains data that the sender wants to 873 receive unmodified in the corresponding response packet in the 874 ECHO_RESPONSE_UNSIGNED parameter. 876 5.2.3. I2 - the Second HIP Initiator Packet 878 The HIP header values for the I2 packet: 880 Header: 881 Type = 3 882 SRC HIT = Initiator's HIT 883 DST HIT = Responder's HIT 885 IP ( HIP ( [R1_COUNTER,] 886 SOLUTION, 887 HIP_CIPHER, 888 HOST_ID, 889 ENCRYPTED_KEY {DH, secret-x|I}, 890 [ ENCRYPTED {DH, ENCRYPTED_KEY {passwd, challenge } },] 891 HIP_MAC_3, 892 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 894 Minimum size = 180 bytes 896 Valid control bits: A 898 The HITs used MUST match the ones used previously. 900 If the Initiator's HI is an anonymous one, the A control MUST be set. 902 The Initiator MAY include an unmodified copy of the R1_COUNTER 903 parameter received in the corresponding R1 packet into the I2 packet. 905 The Solution contains the Random #I from R1 and the computed #J. The 906 low-order K bits of the CMAC(S, | ... | J) MUST be zero. 908 In DEX, the Diffie-Hellman HOST_ID values are static. They are NOT 909 discarded. 911 The HIP_CIPHER contains the single encryption transform selected by 912 the Initiator, that will be used to protect the HI exchange. The 913 chosen transform MUST correspond to one offered by the Responder in 914 the R1. All implementations MUST support the AES-CBC transform 915 [RFC3602]. 917 The ECHO_RESPONSE_UNSIGNED contain the unmodified Opaque data copied 918 from the corresponding echo request parameter. 920 The ENCRYPTED_KEY contains an Initiator generated random secret x 921 that MUST be uniformly distributed that is concatenated with I from 922 the puzzle. The secret x's length matches the keysize of the 923 selected encryption transform. I from the puzzle is used as the IV 924 in the encryption transform. This acts as a nonce from the Responder 925 to prove freshness of the secret wrapping from the Initiator. I in 926 the ENCRYPTED block enables the Responder to validate a proper 927 decryption of the block. The key for the encryption is the 928 HIP_Encrypt key. 930 If the Initiator has prior knowledge that the Responder is expecting 931 a password authenication, the Initiator encrypts the 932 ECHO_REQUEST_UNSIGNED with the password, then wraps the ENCRYPTED 933 parameter in the secret x. I from the puzzle is used as the nonce 934 here as well. There is no signal within R1 for this behaviour. 935 Knowledge of password authencation must be externally configured. 937 The MAC is calculated over the whole HIP envelope, excluding any 938 parameters after the HIP_MAC_3, as described in Section 6.2.1. The 939 Responder MUST validate the HIP_MAC_3. 941 5.2.4. R2 - the Second HIP Responder Packet 943 The HIP header values for the R2 packet: 945 Header: 946 Packet Type = 4 947 SRC HIT = Responder's HIT 948 DST HIT = Initiator's HIT 950 IP ( HIP ( DH_GROUP_LIST, 951 ENCRYPTED_KEY {DH, secret-y|I}, 952 HIP_MAC_3) 954 Minimum size = 108 bytes 956 Valid control bits: none 958 The Responder repeats the DH_GROUP_LIST parameter in R2. This MUST 959 be the same list as included in R1. The DH_GROUP_LIST parameter is 960 repeated here because R2 is MACed and thus cannot be altered by an 961 attacker. This allows the Initiator to determine whether its own 962 DH_GROUP_LIST in the I1 was manipulated by an attacker. 964 The ENCRYPTED contains an Responder generated random secret y that 965 MUST be uniformly distributed that is concatenated with I from the 966 puzzle. The secret y's length matches the keysize of the selected 967 encryption transform. I from the puzzle is used as the IV in the 968 encryption transform. This acts as a nonce from the Initiator to 969 prove freshness of the secret wrapping from the Responder. I in the 970 ENCRYPTED block enables the Responder to validate a proper decryption 971 of the block. The key for the encryption is the HIP_Encrypt key. 973 The HIP_MAC_3 is calculated over the whole HIP envelope, with 974 Responder's HOST_ID parameter concatenated with the HIP envelope. 975 The HOST_ID parameter is removed after the CMAC calculation. The 976 procedure is described in Section 6.2.1. 978 The Initiator MUST validate the HIP_MAC_3. 980 5.3. ICMP Messages 982 When a HIP implementation detects a problem with an incoming packet, 983 and it either cannot determine the identity of the sender of the 984 packet or does not have any existing HIP association with the sender 985 of the packet, it MAY respond with an ICMP packet. Any such replies 986 MUST be rate-limited as described in [RFC2463]. In most cases, the 987 ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 988 for ICMPv6), with the Pointer field pointing to the field that caused 989 the ICMP message to be generated. 991 6. Packet Processing 993 Each host is assumed to have a single HIP protocol implementation 994 that manages the host's HIP associations and handles requests for new 995 ones. Each HIP association is governed by a conceptual state 996 machine, with states defined above in Section 4.1.3. The HIP 997 implementation can simultaneously maintain HIP associations with more 998 than one host. Furthermore, the HIP implementation may have more 999 than one active HIP association with another host; in this case, HIP 1000 associations are distinguished by their respective HITs. It is not 1001 possible to have more than one HIP association between any given pair 1002 of HITs. Consequently, the only way for two hosts to have more than 1003 one parallel association is to use different HITs, at least at one 1004 end. 1006 6.1. Solving the Puzzle 1008 This subsection describes the puzzle-solving details. 1010 In R1, the values I and K are sent in network byte order. Similarly, 1011 in I2, the values I and J are sent in network byte order. The mac is 1012 created by concatenating, in network byte order, the following data, 1013 in the following order and using the CMAC algorithm with I as the 1014 key: 1016 128-bit Initiator's HIT, in network byte order, as appearing in 1017 the HIP Payload in R1 and I2. 1019 128-bit Responder's HIT, in network byte order, as appearing in 1020 the HIP Payload in R1 and I2. 1022 n-bit random value J (where n is CMAC-len), in network byte order, 1023 as appearing in I2. 1025 In order to be a valid response puzzle, the K low-order bits of the 1026 resulting CMAC MUST be zero. 1028 Notes: 1030 i) All the data in the CMAC input MUST be in network byte order. 1032 ii) The order of the Initiator's and Responder's HITs are 1033 different in the R1 and I2 packets; see [RFC5201-bis]. Care must 1034 be taken to copy the values in the right order to the CMAC input. 1036 The following procedure describes the processing steps involved, 1037 assuming that the Responder chooses to precompute the R1 packets: 1039 Precomputation by the Responder: 1040 Sets up the puzzle difficulty K. 1041 Creates a R1 and caches it. 1043 Responder: 1044 Selects a suitable cached R1. 1045 Generates a random number I. 1046 Sends I and K in an R1. 1047 Saves I and K for a Delta time. 1049 Initiator: 1050 Generates repeated attempts to solve the puzzle until a matching J 1051 is found: 1052 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1053 Sends I and J in an I2. 1055 Responder: 1056 Verifies that the received I is a saved one. 1057 Finds the right K based on I. 1058 Computes V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1059 Rejects if V != 0 1060 Accept if V == 0 1062 6.2. HIP_MAC Calculation and Verification 1064 The following subsections define the actions for processing the 1065 HIP_MAC_3 parameter. 1067 6.2.1. CMAC Calculation 1069 Both the Initiator and the Responder should take some care when 1070 verifying or calculating the HIP_MAC_3. Specifically, the Responder 1071 should preserve other parameters than the HOST_ID when sending the 1072 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 1073 was received in the R1 packet. 1075 The scope of the calculation for HIP_MAC_3 is: 1077 CMAC: { HIP header | [ Parameters ] } 1079 where Parameters include all HIP parameters of the packet that is 1080 being calculated with Type values from 1 to (HIP_MAC's Type value - 1081 1) and exclude parameters with Type values greater or equal to 1082 HIP_MAC's Type value. 1084 During HIP_MAC calculation, the following applies: 1086 o In the HIP header, the Checksum field is set to zero. 1088 o In the HIP header, the Header Length field value is calculated to 1089 the beginning of the HIP_MAC parameter. 1091 Parameter order is described in [RFC5201-bis]. 1093 The HIP_MAC parameter is defined in Section 5.1.4. The CMAC 1094 calculation and verification process is as follows: 1096 Packet sender: 1098 1. Create the HIP packet, without the HIP_MAC or any other parameter 1099 with greater Type value than the HIP_MAC parameter has. 1101 2. Calculate the Header Length field in the HIP header. 1103 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1104 retrieved from KEYMAT as defined in Section 6.3. 1106 4. Add the HIP_MAC_3 parameter to the packet and any parameter with 1107 greater Type value than the HIP_MAC's (HIP_MAC_3's) that may 1108 follow. 1110 5. Recalculate the Length field in the HIP header. 1112 Packet receiver: 1114 1. Verify the HIP header Length field. 1116 2. Remove the HIP_MAC_3 parameter, as well as all other parameters 1117 that follow it with greater Type value, saving the contents if 1118 they will be needed later. 1120 3. Recalculate the HIP packet length in the HIP header and clear the 1121 Checksum field (set it to all zeros). 1123 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1124 defined in Section 6.3 and verify it against the received CMAC. 1126 5. Set Checksum and Header Length field in the HIP header to 1127 original values. 1129 6.3. HIP DEX KEYMAT Generation 1131 The HIP DEX KEYMAT process is used for both the Diffie-Hellman 1132 Derived Master key and the Encrypted secrets Pair-wise key. The 1133 former uses both the Extract and Expand phases, while the later MAY 1134 need the Extract and Expand phases if the key is longer than 128 1135 bits. Othewise it only needs the Expand phase. 1137 The Diffie-Hellman Derived Master key is exchanged in R1 and I2 and 1138 used in I2, R2. UPDATE, NOTIFY, and ACK packets. The Encrypted 1139 secrets Pair-wise key is not used in HIP, but is available as the 1140 datagram protection key. Some datagram protection mechanisms have 1141 their own Key Derivation Function, and if so that SHOULD be used 1142 rather than the HIP DEX KEYMAT. 1144 The KEYMAT has two components, CKDF-Extract and CKDF-Expand. The 1145 Extract function COMPRESSES a non-uniformly distributed key, as is 1146 the output of a Diffie-Hellman key derivation, to EXTRACT all the key 1147 entropy into a fixed length output. The Expand function takes either 1148 the output of the Extract function or directly uses a uniformly 1149 distributed key and EXPANDS the length of the key, repeatedly 1150 distributing the key entropy, to produce the keys needed. 1152 The CKDF-Extract function is following operation; the | operation 1153 denotes concatenation. 1155 CKDF-Extract(DHK, info, L) -> CK 1157 where 1159 info = sort(HIT-I | HIT-R) | "CKDF-Extract" 1160 BigK = Diffie-Hellman Derived or Session (x | y) Key 1161 I = I from PUZZLE Parameter 1163 The output CK is calculated as follows: 1165 CK = CMAC(I, BigK | info) 1167 The CKDF-Expand function is following operation; the | operation 1168 denotes concatenation. 1170 CKDF-Expand(CK, info, L) -> OKM 1172 where 1174 info = sort(HIT-I | HIT-R) | "CKDF-Expand" 1175 CK = CK from CKDF-Extract or (x | y) 1176 PRKlen = Length of PRK in octets 1177 maclen = Length of CMAC in octets = 128/8 = 16 1178 L length of output keying material in octets 1179 (<= 255*macLen) 1181 If PRKlen != macLen then PRK = CMAC(0^128, PRK) 1183 The output OKM is calculated as follows: 1185 N = ceil(L/macLen) 1186 T = T(1) | T(2) | T(3) | ... | T(N) 1187 OKM = first L octets of T 1189 where: 1191 T(0) = empty string (zero length) 1192 T(1) = CMAC(CK, T(0) | info | 0x01) 1193 T(2) = CMAC(CK, T(1) | info | 0x02) 1194 T(3) = CMAC(CK, T(2) | info | 0x03) 1195 ... 1197 (where the constant concatenated to the end of each T(n) is a 1198 single octet.) 1200 Sort(HIT-I | HIT-R) is defined as the network byte order 1201 concatenation of the two HITs, with the smaller HIT preceding the 1202 larger HIT, resulting from the numeric comparison of the two HITs 1203 interpreted as positive (unsigned) 128-bit integers in network byte 1204 order. 1206 x and y values are from the ENCRYPTED parameters from I2 and R2 1207 respectively. 1209 The initial keys are drawn sequentially in the order that is 1210 determined by the numeric comparison of the two HITs, with comparison 1211 method described in the previous paragraph. HOST_g denotes the host 1212 with the greater HIT value, and HOST_l the host with the lower HIT 1213 value. 1215 The drawing order for initial keys: 1217 HIP-gl encryption key for HOST_g's outgoing HIP packets 1219 HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1221 HIP-lg encryption key for HOST_l's outgoing HIP packets 1223 HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1225 The number of bits drawn for a given algorithm is the "natural" size 1226 of the keys. For the mandatory algorithms, the following sizes 1227 apply: 1229 AES 128 or 256 bits 1231 If other key sizes are used, they must be treated as different 1232 encryption algorithms and defined separately. 1234 6.4. Processing Incoming I1 Packets 1236 An implementation SHOULD reply to an I1 with an R1 packet, unless the 1237 implementation is unable or unwilling to set up a HIP association. 1238 An I1 in DEX is handled identically to BEX with the exception that in 1239 constructing the R1, the Responder SHOULD select a HIT that is 1240 constructed with the MUST algorithm, which is currently ECDH. 1242 6.4.1. R1 Management 1244 All compliant implementations MUST produce R1 packets. An R1 in DEX 1245 is handled identically to BEX. 1247 6.5. Processing Incoming R1 Packets 1249 A system receiving an R1 MUST first check to see if it has sent an I1 1250 to the originator of the R1 (i.e., it is in state I1-SENT). An R1 in 1251 DEX is handled identically to BEX with the following differences. 1253 If the system has been sending out a stream of I1 packets to work 1254 around high packet loss on a network, it stops sending the I1 packets 1255 AFTER successfully processing a R1 packet. 1257 There is no HIP_SIGNATURE in the R1 packet. It is an 1258 unauthentication packet. 1260 The following steps define the conceptual processing rules for 1261 responding to an R1 packet that are different than in BEX: 1263 1. If the system is configured with an authentication password for 1264 the responder, it constructs the authentication response to 1265 include in the I2. 1267 2. The system prepares and sends an I2, as described in 1268 Section 5.2.3. The system MAY be configured to continually send 1269 this I2 until it receives and validates an R2. 1271 6.6. Processing Incoming I2 Packets 1273 Upon receipt of an I2, the system MAY perform initial checks to 1274 determine whether the I2 corresponds to a recent R1 that has been 1275 sent out, if the Responder keeps such state. An I2 in DEX is handled 1276 identically to BEX with the following differences. 1278 The HIP implementation SHOULD process the I2. This includes 1279 validation of the puzzle solution, extracting the ENCRYPTED key for 1280 processing I2, decrypting the Initiator's Host Identity, verifying 1281 the mac, creating state, and finally sending an R2. 1283 There is no HIP_SIGNATURE on this packet. Authentication is 1284 completely based on the HIP_MAC_3 parameter. 1286 The following steps define the conceptual processing rules for 1287 responding to an I2 packet: 1289 1. If the system's state machine is in the I2-SENT state, the system 1290 makes a comparison between its local and sender's HITs (similarly 1291 as in Section 6.3). If the local HIT is smaller than the 1292 sender's HIT, it should drop the I2 packet, and continue using 1293 the R1 received and I2 sent to the peer earlier. Otherwise, the 1294 system should process the received I2 packet and drop any 1295 previously derived Diffie-Hellman keying material Kij and 1296 ENCRYPTED keying material it might have formed upon sending the 1297 I2 previously. The peer Diffie-Hellman key, ENCRYPTED keying 1298 material and the nonce J are taken from the just arrived I2 1299 packet. The local Diffie-Hellman key and the nonce I are the 1300 ones that were earlier sent in the R1 packet. 1302 2. The system MUST validate the solution to the puzzle by computing 1303 the mac described in Section 5.2.3 using the CMAC algorithm. 1305 3. The system must extract the keying material from the ENCRYPTED 1306 parameter. This key is used to derive the HIP data keys. 1308 4. If the checks above are valid, then the system proceeds with 1309 further I2 processing; otherwise, it discards the I2 and its 1310 state machine remains in the same state. If the system has been 1311 sending a stream of R1 packets to the HIT in the I2 the system 1312 stops sending the R1s. 1314 6.7. Processing Incoming R2 Packets 1316 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 1317 results in the R2 being dropped and the state machine staying in the 1318 same state. If an R2 is received in state I2-SENT, it SHOULD be 1319 processed. 1321 There is no HIP_SIGNATURE on this packet. Authentication is 1322 completely based on the HIP_MAC_3 parameter. 1324 The conceptual processing rules for an incoming R2 packet in DEX are 1325 identical to BEX with the following differences. 1327 1. The system checks the DH_GROUP_LIST as in R1 packet processing. 1328 If the list is different from R1's there may have been a DH 1329 downgrade attack against the unprotected R1 packet. If the 1330 DH_GROUP_LIST presents a better list than recieved in the R1 1331 packet, the system may either resend I1 within the retry bounds 1332 or abandon the HIP exchange. 1334 2. The system must extract the keying material from the ENCRYPTED 1335 parameter. This key is concatanated with that sent in the I2 1336 packet to form the HIP data keys. 1338 6.8. Sending UPDATE Packets 1340 A host sends an UPDATE packet when it updates some information 1341 related to a HIP association. DEX UPDATE handling is the similar in 1342 DEX as in BEX. The key difference is the HIP_SIGNATURE is not 1343 present. 1345 6.9. Handling State Loss 1347 In the case of system crash and unanticipated state loss, the system 1348 SHOULD delete the corresponding HIP state, including the keying 1349 material. That is, the state SHOULD NOT be stored on stable storage. 1350 If the implementation does drop the state (as RECOMMENDED), it MUST 1351 also drop the peer's R1 generation counter value, unless a local 1352 policy explicitly defines that the value of that particular host is 1353 stored. An implementation MUST NOT store R1 generation counters by 1354 default, but storing R1 generation counter values, if done, MUST be 1355 configured by explicit HITs. 1357 7. HIP Policies 1359 There are a number of variables that will influence the HIP exchanges 1360 that each host must support. All HIP implementations MUST support 1361 more than one simultaneous HI, at least one of which SHOULD be 1362 reserved for anonymous usage. Although anonymous HIs will be rarely 1363 used as Responders' HIs, they will be common for Initiators. Support 1364 for more than two HIs is RECOMMENDED. 1366 Many Initiators would want to use a different HI for different 1367 Responders. The implementations SHOULD provide for an ACL of 1368 Initiator's HIT to Responder's HIT. This ACL SHOULD also include 1369 preferred transform and local lifetimes. 1371 The value of K used in the HIP R1 packet can also vary by policy. K 1372 should never be greater than 20, but for trusted partners it could be 1373 as low as 0. 1375 Responders would need a similar ACL, representing which hosts they 1376 accept HIP exchanges, and the preferred transform and local 1377 lifetimes. Wildcarding SHOULD be supported for this ACL also. 1379 8. Security Considerations 1381 HIP is designed to provide secure authentication of hosts. HIP also 1382 attempts to limit the exposure of the host to various denial-of- 1383 service and man-in-the-middle (MitM) attacks. In so doing, HIP 1384 itself is subject to its own DoS and MitM attacks that potentially 1385 could be more damaging to a host's ability to conduct business as 1386 usual. 1388 HIP DEX replaces the SIGMA authenticated Diffie-Hellman key exchange 1389 of BEX with a random generated key exchange encrypted by a Diffie- 1390 Hellman derived key. Both the Initiator and Responder contribute to 1391 this key. 1393 The strength of the key is based on the quality of the secrets 1394 generated the Initiator and Responder. Since the Initiator is 1395 commonly a sensor there is a natural concern about the quality of 1396 its random number generator. 1398 DEX lacks Perfect Forward Secrecy (PFS). If the Initiator's HI is 1399 compromised, ALL HIP connections protected with that HI are 1400 compromised. 1402 The puzzle mechanism using CMAC may need further study that it 1403 does present the desired level of difficulty. 1405 The DEX HIT extraction MAY present new attack opportunities; 1406 further study is needed. 1408 The R1 packet is unprotected and offers an attacker new resource 1409 attacks against the Initiator. This is mitigated by the Initator 1410 only processing a received R1 when it has sent an I1. This is 1411 another DoS attack, but for battery powered Initiators, it could be a 1412 concern. 1414 9. IANA Considerations 1416 IANA has reserved protocol number 139 for the Host Identity Protocol. 1418 The following HIT suites are defined for DEX HIT generation. 1420 +-------+------------+----------------------+-----------------------+ 1421 | Index | Hash | Signature algorithm | Description | 1422 | | function | family | | 1423 +-------+------------+----------------------+-----------------------+ 1424 | 5 | LTRUNC | ECDH | ECDH HI truncated to | 1425 | | | | 96 bits | 1426 +-------+------------+----------------------+-----------------------+ 1428 Table 5: HIT Suites 1430 10. Acknowledgments 1432 The drive to put HIP on a cryptographic 'Diet' came out of a number 1433 of discussions with sensor vendors at IEEE 802.15 meetings. David 1434 McGrew was very 1436 11. References 1438 11.1. Normative References 1440 [RFC2119] Bradner, S., "Key words for use in RFCs to 1441 Indicate Requirement Levels", BCP 14, RFC 2119, 1442 March 1997. 1444 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 1445 Version 6 (IPv6) Specification", RFC 2460, 1446 December 1998. 1448 [RFC2463] Conta, A. and S. Deering, "Internet Control 1449 Message Protocol (ICMPv6) for the Internet 1450 Protocol Version 6 (IPv6) Specification", 1451 RFC 2463, December 1998. 1453 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES- 1454 CBC Cipher Algorithm and Its Use with IPsec", 1455 RFC 3602, September 2003. 1457 [RFC3686] Housley, R., "Using Advanced Encryption 1458 Standard (AES) Counter Mode With IPsec 1459 Encapsulating Security Payload (ESP)", 1460 RFC 3686, January 2004. 1462 [RFC3972] Aura, T., "Cryptographically Generated 1463 Addresses (CGA)", RFC 3972, March 2005. 1465 [RFC4309] Housley, R., "Using Advanced Encryption 1466 Standard (AES) CCM Mode with IPsec 1467 Encapsulating Security Payload (ESP)", 1468 RFC 4309, December 2005. 1470 [RFC4843-bis] Laganier, J. and F. Dupont, "An IPv6 Prefix for 1471 Overlay Routable Cryptographic Hash Identifiers 1472 (ORCHID)", draft-ietf-hip-rfc4843-bis-00 (work 1473 in progress), August 2010. 1475 [RFC5201-bis] Moskowitz, R., Heer, T., Jokela, P., and T. 1476 Henderson, "Host Identity Protocol Version 2 1477 (HIPv2)", draft-ietf-hip-rfc5201-bis-08 (work 1478 in progress), March 2012. 1480 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 1481 "Fundamental Elliptic Curve Cryptography 1482 Algorithms", RFC 6090, February 2011. 1484 [rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., and J. 1485 Melen, "Using the Encapsulating Security 1486 Payload (ESP) Transport Format with the Host 1487 Identity Protocol (HIP)", 1488 draft-ietf-hip-rfc5202-bis-00 (work in 1489 progress), September 2010. 1491 11.2. Informative References 1493 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 1494 "Analysis of the HIP Base Exchange Protocol", 1495 in Proceedings of 10th Australasian Conference 1496 on Information Security and Privacy, July 2003. 1498 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service 1499 via Algorithmic Complexity Attacks", in 1500 Proceedings of Usenix Security Symposium 2003, 1501 Washington, DC., August 2003. 1503 [FIPS.197.2001] National Institute of Standards and Technology, 1504 "Advanced Encryption Standard (AES)", FIPS PUB 1505 197, November 2001, . 1508 [IEEE.802-11.2007] "Information technology - Telecommunications 1509 and information exchange between systems - 1510 Local and metropolitan area networks - Specific 1511 requirements - Part 11: Wireless LAN Medium 1512 Access Control (MAC) and Physical Layer (PHY) 1513 Specifications", IEEE Standard 802.11, 1514 June 2007, . 1517 [IEEE.802-15-4.2011] "Information technology - Telecommunications 1518 and information exchange between systems - 1519 Local and metropolitan area networks - Specific 1520 requirements - Part 15.4: Wireless Medium 1521 Access Control (MAC) and Physical Layer (PHY) 1522 Specifications for Low-Rate Wireless Personal 1523 Area Networks (WPANs)", IEEE Standard 802.15.4, 1524 September 2011, . 1527 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for 1528 Writing an IANA Considerations Section in 1529 RFCs", BCP 26, RFC 2434, October 1998. 1531 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 1532 Cryptography Specification Version 2.0", 1533 RFC 2898, September 2000. 1535 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) 1536 Protocol", RFC 4306, December 2005. 1538 [rfc4423-bis] Moskowitz, R., "Host Identity Protocol 1539 Architecture", draft-ietf-hip-rfc4423-bis-02 1540 (work in progress), February 2011. 1542 Appendix A. Using Responder Puzzles 1544 As mentioned in Section 4.1.1, the Responder may delay state creation 1545 and still reject most spoofed I2s by using a number of pre-calculated 1546 R1s and a local selection function. This appendix defines one 1547 possible implementation in detail. The purpose of this appendix is 1548 to give the implementors an idea on how to implement the mechanism. 1549 If the implementation is based on this appendix, it MAY contain some 1550 local modification that makes an attacker's task harder. 1552 The Responder creates a secret value S, that it regenerates 1553 periodically. The Responder needs to remember the two latest values 1554 of S. Each time the S is regenerated, the R1 generation counter 1555 value is incremented by one and the Responder generates an R1 packet. 1557 When the Initiator sends the I1 packet for initializing a connection, 1558 the Responder gets the HIT and IP address from the packet, and 1559 generates an I value for the puzzle. 1561 I value calculation: 1562 I = Ltrunc( CMAC ( S, HIT-I | HIT-R | IP-I | IP-R ), n) 1563 where n = CMAC-len 1565 From an incoming I2 packet, the Responder gets the required 1566 information to validate the puzzle: HITs, IP addresses, and the 1567 information of the used S value from the R1_COUNTER. Using these 1568 values, the Responder can regenerate the I, and verify it against the 1569 I received in the I2 packet. If the I values match, it can verify 1570 the solution using I, J, and difficulty K. If the I values do not 1571 match, the I2 is dropped. 1573 puzzle_check: 1574 V := Ltrunc( CMAC( I2.I | I2.I, I2.hit_i | I2.hit_r | I2.J ), K ) 1575 if V != 0, drop the packet 1577 If the puzzle solution is correct, the I and J values are stored for 1578 later use. They are used as input material when keying material is 1579 generated. 1581 Keeping state about failed puzzle solutions depends on the 1582 implementation. Although it is possible for the Responder not to 1583 keep any state information, it still may do so to protect itself 1584 against certain attacks (see Section 4.1.1). 1586 Appendix B. Generating a Public Key Encoding from an HI 1588 The following pseudo-code illustrates the process to generate a 1589 public key encoding from an HI for ECDH. 1591 Author's Address 1593 Robert Moskowitz 1594 Verizon 1595 1000 Bent Creek Blvd, Suite 200 1596 Mechanicsburg, PA 1597 USA 1599 EMail: robert.moskowitz@verizon.com