idnits 2.17.1 draft-heer-hip-middle-auth-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]), 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Middleboxes MAY add CHALLENGE_REQUEST parameters to the R1 and I2 packets and to any UPDATE packet. This parameter contains an opaque data block of variable size, which the middlebox uses to carry arbitrary data (e.g., a nonce). The HIP packets that carry middlebox challenges may contain multiple CHALLENGE_REQUEST parameters, since all middleboxes on the path may add these parameters. A middlebox MUST append its own CHALLENGE_REQUEST parameter behind already existing CHALLENGE_REQUEST parameters in the HIP packet. In order to avoid packet fragmentation, the MBs should restrict the size of the variable data field in the CHALLENGE_REQUEST parameter. The total length of the packets SHOULD not exceed 1280 bytes to avoid IPv6 fragmentation [RFC2460]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2011) is 4564 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) ** Obsolete normative reference: RFC 6253 (Obsoleted by RFC 8002) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol T. Heer, Ed. 3 Internet-Draft R. Hummen 4 Intended status: Experimental K. Wehrle 5 Expires: April 30, 2012 RWTH Aachen University, 6 Communication and Distributed 7 Systems Group 8 M. Komu 9 Aalto University 10 October 28, 2011 12 End-Host Authentication for HIP Middleboxes 13 draft-heer-hip-middle-auth-04 15 Abstract 17 The Host Identity Protocol [RFC5201] is a signaling protocol for 18 secure communication, mobility, and multihoming that introduces a 19 cryptographic namespace. This document specifies an extension for 20 HIP that enables middleboxes to unambiguously verify the identities 21 of hosts that communicate across them. This extension allows 22 middleboxes to verify the liveness and freshness of a HIP association 23 and, thus, to secure access control in middleboxes. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Notation 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 30, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Authentication and Replay Attacks . . . . . . . . . . . . 5 69 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1. Signed Middlebox Nonces . . . . . . . . . . . . . . . . . 6 71 2.2. Identity Verification by Middleboxes . . . . . . . . . . . 9 72 2.3. Failure Signaling . . . . . . . . . . . . . . . . . . . . 15 73 2.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16 74 2.5. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 16 75 3. Security Services for the HIP Control Channel . . . . . . . . 18 76 3.1. Adversary model and Security Services . . . . . . . . . . 18 77 4. Security Services for the HIP Payload Channel . . . . . . . . 19 78 4.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 20 79 4.2. Resource allocation . . . . . . . . . . . . . . . . . . . 21 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 83 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 8.1. Version 4 . . . . . . . . . . . . . . . . . . . . . . . . 22 85 8.2. Version 3 . . . . . . . . . . . . . . . . . . . . . . . . 22 86 9. Normative References . . . . . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 The Host Identity Protocol (HIP) introduces a new cryptographic 92 namespace, based on public keys, in order to secure Internet 93 communication. This namespace allows hosts to securely address and 94 authenticate their peers. HIP was designed to be middlebox-friendly 95 and to allow middleboxes to inspect HIP control traffic. Examples of 96 such middleboxes are firewalls and Network Address Translators 97 (NATs). 99 In this context, one can distinguish HIP-aware middleboxes, which are 100 designed to process HIP packets, and other middleboxes, which are 101 unaware of HIP. This document addresses only HIP-aware middleboxes 102 while the behavior of HIP in combination with HIP-unaware middleboxes 103 is specified in [RFC5770]. Moreover, the scope of this document is 104 restricted to middleboxes that use HIP in order to provide 105 Authentication, Authorization, and Accounting (AAA)-related services 106 and, thus, need to authenticate the communicating peers that send 107 traffic over the middlebox. The class of middleboxes this document 108 focuses on does not require the end-host to explicitly register to 109 the middlebox. HIP behavior for interacting and registering to such 110 middleboxes is specified in [RFC5203]. Thus, we focus on middleboxes 111 that build their state based on packets they forward (path-coupled 112 signaling). 114 An example of such a middlebox is a firewall that only allows traffic 115 from certain hosts to traverse. We assume that access control is 116 performed based on Host Identities (HIs). Such an authenticating 117 middlebox needs to observe the HIP Base EXchange (BEX) or a HIP 118 mobility update [RFC5206] and check the Host Identifiers (HIs) in the 119 packets. 121 Along the lines of [RFC5207], an authentication solution for 122 middleboxes must have some vital properties. For one, the middlebox 123 must be able to unambiguously identify one or both of the 124 communicating peers. Additionally, the solution must not allow for 125 new attacks against the middlebox. This document specifies a HIP 126 extension that allows middleboxes to participate in the HIP handshake 127 and the HIP update process in order to allow these middleboxes to 128 reliably verify the identities of the communicating peers. To this 129 end, this HIP extension defines how middleboxes can interact with 130 end-hosts in order to verify their identities. 132 Verifying public-key (PK) signatures is costly in terms of CPU 133 cycles. Thus, in addition to authentication capabilities, it is also 134 necessary to provide middleboxes with a way of defending against 135 resource-exhaustion attacks that target PK signature verification. 136 This document defines how middleboxes can utilize the HIP puzzle 137 mechanism defined in [RFC5201] to slow down resource-exhaustion 138 attacks. 140 The presented authentication extension only targets the HIP control 141 channel. Additional security considerations and possible security 142 services for the HIP payload channel are discussed in Section 4. 144 1.1. Authentication and Replay Attacks 146 Middleboxes may need to verify the HIs in the HIP base exchange 147 messages to perform access control based on Host Identities. 148 However, passive verification of HIs in the messages is not 149 sufficient to ensure the identity of an end-host because of a 150 possible replay attack against which the basic HIP protocol as 151 specified in [RFC5201] does not provide adequate protection. 153 To illustrate the need for additional security measures for HIP-aware 154 middleboxes, we briefly outline the replay attack: Assume that the 155 legitimate owner of Host Identity Tag (HIT) X establishes a HIP 156 association with the legitimate owner of HIT Y at some point in time 157 and an attacker A overhears the base exchange and records it. 159 Assume that a middlebox M checks HIP HIs in order to restrict traffic 160 passing through the box. At some later point in time, Attacker A 161 collaborates with another attacker B. They replay the very same BEX 162 packets to the middlebox M on the communication path. Note that it 163 is not required that the middlebox M was on the communication path 164 between X and Y when the BEX was recorded. 166 The middlebox has no way to distinguish legitimate hosts X and Y from 167 the attackers A and B as it can only overhear the BEX passively and 168 it cannot can distinguish the replayed BEX from a the genuine 169 handshake. As the attackers overheard the SPI numbers, they can 170 traverse the middlebox with "fake" ESP packets with valid SPI 171 numbers, and hence, send data across M without proper authentication. 172 Since the middleboxes do not know the integrity and encryption keys 173 for ESP, they cannot distinguish valid ESP packets from forged ones. 174 Hence, collaborating attackers can use any replayed BEX to falsely 175 authenticate to the middlebox and thus impersonate any host. This is 176 problematic in cases in which the middlebox needs to know the 177 identity of the peers that communicate across it. Examples for such 178 cases are AAA-related services, such as access control, logging of 179 activities, and accounting for traffic volume or connection duration. 181 This attack scenario is not addressed by the current HIP 182 specifications. Therefore, this document specifies a HIP extension 183 that allows middleboxes to defend against this attack. 185 2. Protocol Overview 187 This section gives an overview of the interaction between hosts and 188 authenticating middleboxes. This document describes a framework that 189 middleboxes can use to implement authentication of end-hosts and 190 leaves its further use to other documents and to middlebox 191 implementors. 193 2.1. Signed Middlebox Nonces 195 The described attack scenario shows the necessity for unambiguous 196 end-host identity verification by middleboxes. However, this 197 authentication cannot be purely end-to end: a) Relying on nonces 198 generated by the end-hosts is not possible because middleboxes cannot 199 verify the freshness of these nonces. b) Introducing time-stamps 200 restricts the attack to a certain time frame but requires global time 201 synchronization and therefore should be avoided. 203 The following sections specify how HIP hosts can prove their identity 204 by performing a challenge-response protocol between the middlebox and 205 the end-hosts. As a challenge, the middlebox adds information (e.g. 206 self-generated nonces) to HIP control packets which the end-hosts 207 sign with public-key (PK) signatures and echo back. 209 The challenge-response mechanism is similar to the ECHO_REQUEST/ 210 ECHO_RESPONSE mechanism employed already by HIP end-hosts (see 211 [RFC5201] ). It assumes that the end-hosts exchange at least two HIP 212 packets with each other. The middlebox adds a CHALLENGE_REQUEST 213 parameter to the first HIP control packet. Similar to the 214 ECHO_REQUEST parameter in the original HIP protocol, this parameter 215 contains an opaque data field that must be echoed by its receiver. 216 The receiver echoes the opaque data field in a CHALLENGE_RESPONSE 217 parameter. The CHALLENGE_RESPONSE parameter must be covered by the 218 packet signature, thereby proving that the receiver is in possession 219 of the private key that corresponds to the HI. 221 The middlebox can either verify the identity of the initiator, the 222 responder, or both peers, depending on the purpose of the middlebox. 223 The choice of which authentication is required left to middlebox 224 implementers. 226 2.1.1. CHALLENGE_REQUEST 228 Middleboxes MAY add CHALLENGE_REQUEST parameters to the R1 and I2 229 packets and to any UPDATE packet. This parameter contains an opaque 230 data block of variable size, which the middlebox uses to carry 231 arbitrary data (e.g., a nonce). The HIP packets that carry middlebox 232 challenges may contain multiple CHALLENGE_REQUEST parameters, since 233 all middleboxes on the path may add these parameters. A middlebox 234 MUST append its own CHALLENGE_REQUEST parameter behind already 235 existing CHALLENGE_REQUEST parameters in the HIP packet. In order to 236 avoid packet fragmentation, the MBs should restrict the size of the 237 variable data field in the CHALLENGE_REQUEST parameter. The total 238 length of the packets SHOULD not exceed 1280 bytes to avoid IPv6 239 fragmentation [RFC2460]. 241 The middleboxes add the CHALLENGE_REQUEST parameter to the 242 unprotected part of a HIP message. Thus, it does not corrupt any 243 HMAC or public-key signatures that protect the HIP packet. However, 244 the middlebox MUST recompute the IP and HIP header checksums as 245 defined in [RFC5201] and the UDP headers of UDP encapsulated HIP 246 packets as defined in [RFC5770]. 248 A HIP end-host that receives a HIP control packet containing one or 249 more CHALLENGE_REQUEST parameters must copy the contents of each 250 parameter without modification to a single CHALLENGE_RESPONSE 251 parameter. This end-host MUST send the CHALLENGE_RESPONSE parameter 252 within the signed part of its reply. Note that middleboxes MAY also 253 add ECHO_REQUEST_UNSIGNED parameters as specified in [RFC5201] if the 254 receiver of the parameter is not required to sign the contents of the 255 ECHO_REQUEST. 257 Middleboxes can delay state creation by utilizing the 258 CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters by hiding 259 encrypted or otherwise protected information about previous 260 authentication steps in the opaque data field. 262 2.1.2. CHALLENGE_RESPONSE 264 When a middlebox injects an opaque blob of data with a 265 CHALLENGE_REQUEST parameter, it expects to receive the same data 266 without modification as part of a CHALLENGE_RESPONSE parameter in a 267 subsequent packet. Hence, the opaque data MUST be copied as it is 268 from the corresponding CHALLENGE_REQUEST parameter. In the case of 269 multiple CHALLENGE_REQUEST parameters, their order MUST be preserved 270 within the corresponding CHALLENGE_RESPONSE parameter. 272 The CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters MAY be used 273 for any purpose, in particular when a middlebox has to carry state 274 information in a HIP packet to receive it in the next response 275 packet. The CHALLENGE_RESPONSE MUST be covered by the HIP_SIGNATURE. 277 The CHALLENGE_RESPONSE parameter is non-critical. Depending on its 278 local policy, a middlebox can react differently on a missing 279 CHALLENGE_RESPONSE parameter. Possible actions range from degraded 280 or restricted service, such as bandwidth limitation, up to refusing 281 connections and reporting access violations. 283 When sending a HIP control packet, an end-host may face the problem 284 that not all opaque values of the received CHALLENGE_REQUEST 285 parameters fit into the CHALLENGE_RESPONSE parameter due to HIP 286 control packet size restrictions. In this case, the host should send 287 several packets. The first packet contains a CHALLENGE_RESPONSE 288 parameter that includes the received opaque values of the 289 CHALLENGE_REQUEST parameters starting from the last occurrence in the 290 packet. Further packets contain the remaining values in the reverse 291 order of the inclusion in the received packet. This way, the 292 middleboxes closest to the sender will already have authenticated the 293 identity of the peers and can let further control packets pass 294 through. 296 2.1.3. Middlebox Puzzles 298 Since PK operations are costly in terms of CPU cycles, a middlebox 299 has to defend itself against resource-exhaustion attacks when 300 verifying signatures in HIP packets. The HIP base protocol [RFC5201] 301 specifies a puzzle mechanism to protect the Responder from I2 floods 302 that require numerous public-key operations. However, middleboxes 303 cannot utilize this mechanism because they cannot verify the 304 freshness of the puzzle solution in the BEX packets. This section 305 specifies how middleboxes can utilize the puzzle mechanism to add 306 their own puzzles to R1, I2, and any UPDATE packets. This allows 307 middleboxes to shelter against Denial of Service (DoS) attacks on PK 308 verification. 310 The puzzle mechanism for middleboxes utilizes the CHALLENGE_REQUEST 311 and CHALLENGE_RESPONSE parameters. The CHALLENGE_REQUEST parameter 312 contains fields for setting the difficulty and the expiration date of 313 the puzzle. In contrast to the PUZZLE parameter in the HIP base 314 specifications, there is no dedicated puzzle seed field. Instead, 315 the hash of the opaque data field in the CHALLENGE_REQUEST parameter 316 serves as puzzle seed. The hash is generated by applying the SHA-1 317 algorithm to the opaque data field. The destination end-host of the 318 HIP control packet MUST solve the puzzle and provide the solution in 319 the CHALLENGE_RESPONSE parameter. The middlebox can set the puzzle 320 difficulty by adjusting the K value in the CHALLENGE_REQUEST packet. 321 The semantics of this field equal the semantics of the PUZZLE 322 parameter. Setting K to 0 signifies that no puzzle solution is 323 required. 325 In case of multiple CHALLENGE_RESPONSE parameters, the responder 326 derives the puzzle seed from the concatenation of the opaque data of 327 all CHALLENGE_REQUEST parameters in the received control packet in 328 the reverse order of their inclusion. Furthermore, he MUST compute 329 the solution based on the highest difficulty value K in the received 330 CHALLENGE_REQUEST parameters. This selection of K satisfies the 331 security requirements of each middlebox while preventing the the 332 receiver from computing multiple puzzle solutions. The responder 333 MUST meet the lowest time boundaries of the received 334 CHALLENGE_REQUEST parameters. Otherwise, there exists one on-path 335 middlebox that will not approve the solution. 337 When approaching the IPv6 packet fragmentation threshold, end-hosts 338 should split the CHALLENGE_RESPONSE parameter in case of multiple 339 CHALLENGE_REQUEST parameters. Hence, end-hosts SHOULD compute the 340 puzzle solution after the overall packet size of the response packet 341 has been determined. Hence, only the opaque values of the 342 CHALLENGE_REQUEST parameters that are included in the respective 343 CHALLENGE_RESPONSE parameter MUST be used during the puzzle seed 344 generation. 346 Since a puzzle increases the delay and computational cost for 347 establishing or updating a HIP association, a middlebox SHOULD only 348 increase K when it is under attack. Moreover, middleboxes SHOULD 349 distinguish attack directions. If the majority of the CPU load is 350 caused by verifying HIP control messages that arrive from a certain 351 interface, middleboxes MAY increase K for HIP control packets that 352 leave the interface. The middlebox chooses the difficultly of the 353 puzzle according to its load and local policies. 355 2.1.4. CHALLENGE_RESPONSE Verification 357 When a middlebox has added a CHALLENGE_REQUEST parameter to a control 358 packet and receives a control packet that contains a 359 CHALLENGE_RESPONSE parameter, it first checks if its opaque data has 360 been echoed back correctly. To this end, it traverses the Opaque 361 values included in the CHALLENGE_RESPONSE parameter. 363 If the opaque data has been echoed back correctly by the end-host, 364 the middlebox verifies the provided puzzle solution. It, therefore, 365 hashes the Opaque values as contained in the CHALLENGE_RESPONSE 366 parameter and verifies the signaled solution. In case of a 367 successful verification, the middlebox MAY check further security 368 mechanisms such as the PK signature and process the packet according 369 to its function. 371 2.2. Identity Verification by Middleboxes 373 This section describes how middleboxes can influence the BEX and the 374 HIP update process in order to verify the identity of the HIP end- 375 hosts. 377 2.2.1. Identity Verification During BEX 379 Middleboxes MAY add CHALLENGE_REQUEST parameters to R1 and I2 packets 380 in order to verify the identities of the participating end-hosts. 381 Middleboxes can choose either to authenticate the Initiator, the 382 Responder, or both. Middleboxes MUST NOT add CHALLENGE_REQUEST 383 parameters to I1 messages because this would expose the Responder to 384 DoS attacks. Thus, middleboxes MUST let unauthenticated and minimal 385 I1 packets traverse. Minimal means that the I1 packet MUST NOT 386 contain more than the minimal set of parameters specified by HIP 387 standards or internet drafts. In particular, the I1 packet MUST NOT 388 contain any attached payload. Figure 1 illustrates the 389 authentication process during the BEX. 391 Main path: 393 Initiator Middlebox Responder 394 .-----------------. 395 I1 | | I1 396 -----------------> | |----------------------------> 397 | | 398 R1, + CQ1 | Add CQ | R1 399 <----------------- | |<---------------------------- 400 | | 401 I2, {CR1} | Verify CR1 | I2, {CR1} + CQ2 402 -----------------> | Add CQ2 |----------------------------> 403 | | 404 | | 405 R2, {CR2} | Verify CR2 | R2, {CR2} 406 <----------------- | |<----------------------------- 407 '-----------------' 409 CQ: Middlebox challenge reQuest 410 CR: Middlebox challenge Response 411 {}: Signature with sender's HI as key 413 Middlebox authentication of a HIP base exchange. 415 Figure 1 417 2.2.2. Identity Verification During Mobility Updates 419 HIP rekeying, mobility and multihoming UPDATE mechanisms for non- 420 NATted environments are described in [RFC5206]. This section 421 describes how middleboxes process UPDATE messages in non-NATted 422 environments and leave NATted environments for future revisions of 423 the draft. 425 The middleboxes can apply middlebox challenges to mobility related 426 HIP control messages in the case where both end-hosts are single- 427 homed. The middlebox challenges can be applied both ways as the 428 UPDATE process consists of three packets (U1, U2, U3) which all 429 traverse through the same middlebox as shown in Figure 2. 431 In cases, in which fewer packets are used for updating an 432 association, the following rule applies. 434 RESPONSE RULE: 436 A HIP host, receiving a CHALLENGE_REQUEST MUST reply with a 437 CHALLENGE_RESPONSE in its next UPDATE packet. If no further UPDATE 438 packets are necessary to complete the update procedure, an additional 439 UPDATE packet containing the CHALLENGE_RESPONSE MUST be sent. 441 Initiator Middlebox Responder 442 .------. 443 U1 | | U1 + CQ1 444 -----------------------------> | | --------------------------> 445 | | 446 U2, {CR1} + CQ2 | | U2, {CR1} 447 <----------------------------- |OK | <-------------------------- 448 | | 449 U3, {CR2} | | U3, {CR2} 450 -----------------------------> | OK| --------------------------> 451 '------' 452 CQ: Middlebox challenge reQuest 453 CR: Middlebox challenge Response 454 {}: Signature with sender's HI as key 456 Middlebox authentication of a HIP mobility update over a single path. 458 Figure 2 460 Middlebox 1 in Figure 2 can verify the identity of the Responder by 461 checking its PK signature and the presence of the CHALLENGE_RESPONSE 462 in the U2 packet. If necessary, the middlebox MAY add an 463 CHALLENGE_REQUEST for the Initiator of the update. The middlebox can 464 verify the Initiator's identity by verifying its signature and the 465 CHALLENGE_RESPONSE in the U3 packet. 467 2.2.3. Identity Verification for Multihomed Mobility Updates 469 Multihomed hosts may use multiple communication paths during an HIP 470 mobility update. Depending on whether the middlebox is located on 471 the communication path between the preferred locators of the hosts or 472 not, the middlebox forwards different packets and, thus, needs to 473 interact differently with the updates. Figure 3 I) and II) 474 illustrates an update with Middlebox 1 on the path between the 475 Initiator's and the Responder's preferred locators and with Middlebox 476 2 on an alternative path. Middlebox 2 is not located on the path 477 between the preferred locators of the HIP end-hosts does not receive 478 the U1 message. Therefore, it will not recognize any 479 CHALLENGE_RESPONSE (CR1) in the second UPDATE packet. Thus, if a 480 middlebox encounters non-matching or missing CHALLENGE_RESPONSE 481 parameter in an initial update packet, the middlebox SHOULD ignore 482 it. 484 Complying to the RESPONSE RULE stated in Section Section 2.2.2, the 485 RESPONDER generates an additional fourth update packet on receiving 486 the CHALLENGE_REQUEST. The update process for a middlebox on the 487 preferred communication path (Middlebox 1) and a middlebox off the 488 preferred communication path (Middlebox 2) is depicted in Figure 3. 490 I) Main path: 492 Initiator Middlebox 1 Responder 493 .------. 494 U1 | | U1 + CQ1 495 ----------------------------> | | ---------------------------> 496 | | 497 U2, {CR1} + CQ2 | | U2, {CR1} 498 <---------------------------- |OK | <--------------------------- 499 | | 500 U3, {CR2} | | U3, {CR2} 501 ----------------------------> | OK| ---------------------------> 502 '------' 504 II) Alternative path: 506 Initiator Middlebox 2 Responder 508 U1 (bypasses Middlebox 2) 509 ------------------------------------------------------------------> 510 .------. 511 U2, {CR1} + CQ3 | | U2, {CR1} 512 <---------------------------- | wrong| <--------------------------- 513 | | 514 U3', {CR3} | | U3', {CR3} + CQ4 515 ----------------------------> |OK | ---------------------------> 516 | | 517 U4, {CR4} | | U4, {CR4} 518 <---------------------------- | OK| <--------------------------- 519 '------' 520 CQ: Middlebox challenge reQuest 521 CR: Middlebox challenge Response 522 {}: Signature with sender's HI as key 524 Middlebox authentication of a HIP mobility update over different 525 paths. 527 Figure 3 529 2.2.4. Identity Signaling During Updates 531 As middleboxes have to verify rapidly and forward HIP packets, they 532 need to be supplied with all information necessary to do so. If end- 533 hosts hand over communication to a new communication path, 534 middleboxes need to be able to learn their Host Identifiers (HIs) 535 from the UPDATE packets. Therefore, all packets that contain a 536 CHALLENGE_RESPONSE parameter MUST contain the HOST_ID parameter. 538 2.2.5. Closing of Connections 540 The connection tear down as defined in [RFC5201] consists of two 541 consecutive messages. This lack of a third message restricts 542 middleboxes to authenticating the Responder of a CLOSE packet. 543 However, verifying the legitimacy of the Responder suffices in most 544 network scenarios, as CLOSE packets from unauthentic Initiators will 545 be dropped by the Responder due to an invalid HMAC parameter. As a 546 result, on-path middleboxes will not see CLOSE_ACK packets for 547 rejected CLOSE packets. CLOSE_ACK packets can be authenticated by 548 the middleboxes by adding a CHALLENGE_REQUEST parameter to the 549 corresponding CLOSE packet as described above. Hence, middleboxes do 550 not falsely tear down connections on illegitimate (forged) CLOSE 551 packets. 553 If local policies still require a middlebox to authenticate the CLOSE 554 messages of both peers, the tear down operation needs to be extended 555 following the RESPONSE RULE in Section 2.2.2. Hence, the responder 556 side CLOSE_ACK packet MUST be followed by an initiator side CLOSE_ACK 557 if the received CLOSE_ACK packet contains a CHALLENGE_REQUEST 558 parameter. 560 Middleboxes should have learned the identities of the peers during 561 the BEX or an UPDATE prior to the CLOSE exchange. Hence, end-hosts 562 are not required to include their identities in the CLOSE exchange. 563 If a middlebox has not learned the identities of the peers when 564 inspecting a CLOSE packet, it MUST forward the packet. In order to 565 prevent misuse of the CLOSE exchange as a side channel for disallowed 566 communication, middleboxes SHOULD rate limit unauthenticated CLOSE 567 exchanges. 569 I) Regular CLOSE authentication: 571 Initiator Middlebox Responder 572 .------. 573 CLOSE | | CLOSE + CQ1 574 ----------------------------> | | ---------------------------> 575 | | 576 CLOSE_ACK, {CR1} | | CLOSE_ACK, {CR1} 577 <---------------------------- |OK | <--------------------------- 578 | | 579 '------' 581 II) Extended CLOSE authentication: 583 Initiator Middlebox Responder 584 .------. 585 CLOSE | | CLOSE + CQ1 586 ----------------------------> | | ---------------------------> 587 | | 588 CLOSE_ACK, {CR1} + CQ2 | | CLOSE_ACK, {CR1} 589 <---------------------------- |OK | <--------------------------- 590 | | 591 CLOSE_ACK, {CR2} | | CLOSE_ACK, {CR2} 592 ----------------------------> | OK| ---------------------------> 593 '------' 594 CQ: Middlebox challenge reQuest 595 CR: Middlebox challenge Response 596 {}: Signature with sender's HI as key 598 Middlebox authentication of a HIP close with authentication of (I) 599 the Responder and (II) both peers. 601 Figure 4 603 2.3. Failure Signaling 605 Middleboxes SHOULD inform the sender of a BEX packet or update packet 606 if it does not satisfy the requirements of the middlebox. Reasons 607 for non-satisfactory packets are missing HOST_ID or 608 CHALLENGE_RESPONSE parameters. Other reasons may be middlebox 609 policies regarding, for example, insufficient client capabilities or 610 or insufficient credentials delivered in a HIP CERT parameter 611 [RFC6253]. Options for expressing such shortcomings are ICMP packets 612 if no HIP association is established and HIP_NOTIFY packets in case 613 of an already established HIP association. Defining this signaling 614 mechanism is future work. 616 2.4. Fragmentation 618 Analogously to the specification in [RFC5201], HIP aware middleboxes 619 SHOULD support IP-level fragmentation and reassembly for IPv6 and 620 MUST support IP-level fragmentation and reassembly for IPv4. 621 However, when adding CHALLENGE_REQUEST parameters, a middlebox SHOULD 622 keep the total packet size below 1280 bytes to avoid packet 623 fragmentation in IPv6. 625 2.5. HIP Parameters 627 This HIP extension specifies four new HIP parameters that allow 628 middleboxes to authenticate HIP end-hosts and to protect against DoS 629 attacks. 631 2.5.1. CHALLENGE_REQUEST 633 A middlebox MAY append the CHALLENGE_REQUEST parameter to R1, I2, and 634 UPDATE packets. The structure of the CHALLENGE_REQUEST parameter is 635 depicted in the following figure. The semantics of the K and 636 Lifetime fields are identical to the fields defined in the PUZZLE 637 parameter in [RFC5201]. The opaque data field serves as nonce and 638 puzzle seed value. To generate the seed corresponding to the 8-byte 639 value I in [RFC5201], the receiver of the puzzle applies Ltrunc as 640 defined in [RFC5201] to the received opaque data and truncates the 641 result to 8 bytes. Note that the opaque data field must provide 642 sufficient randomness to serve as puzzle seed. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | K, 1 byte | Lifetime | / 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 651 / / 652 / Opaque, (variable length) / 653 / +-+-+-+-+-+-+-+-+-+-| 654 / | Padding | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Type 65334 658 Length Variable 659 K K is the number of verified bits 660 Lifetime Challenge lifetime 2^(value-32) seconds 661 Opaque Opaque data that serves as nonce and as basis for the 662 puzzle. The puzzle value I is generated by hashing the 663 opaque data field with the hash function SHA-1 and 664 truncating it to 8-byte length. 666 2.5.2. CHALLENGE_RESPONSE 668 The CHALLENGE_RESPONSE parameter is the response to one or more 669 CHALLENGE_REQUEST parameters. The receiver of a CHALLENGE_REQUEST 670 parameter SHOULD reply with a CHALLENGE_RESPONSE. Otherwise, the 671 middlebox that added the CHALLENGE_REQUEST parameter MAY decide to 672 degrade or deny its service. The Opaque fields of the received 673 CHALLENGE_REQUEST parameters must be copied to the CHALLENGE_RESPONSE 674 parameter in the reverse order of reception without any modification. 675 As the number of opaque fields may be variable, it is encoded in the 676 CHALLENGE_RESPONSE parameter. Furthermore, the length of each Opaque 677 value is variable and is included in the parameter. The Opaque 678 values are appended behind the last Opaque length field. Instead of 679 copying the Opaque field of each CHALLENGE_REQUEST parameter, the 680 input for the puzzle generation procedure may be reused. If the 681 puzzle difficulty in the received CHALLENGE_REQUEST parameters is set 682 to any other value except 0, an appropriate puzzle solution (adhering 683 to the SOLUTION specifications in [RFC5201]) must be provided in the 684 CHALLENGE_RESPONSE parameter. The CHALLENGE_RESPONSE parameter is 685 non-critical and covered by the SIGNATURE. The structure of the 686 CHALLENGE_RESPONSE parameter is depicted below: 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type | Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | K, 1 byte | Lifetime | No. opaque values | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 / Puzzle solution #J, 8 bytes / 696 / / 697 / / 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Opaque length | Opaque length | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 / Opaque, (variable length) / 702 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 / | / 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 705 / Opaque, (variable length) / 706 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 / | Padding | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Type 322 711 Length Variable 712 K K is the number of verified bits 713 Lifetime Challenge lifetime 2^(value-32) seconds 714 No. opaque values Number of included opaque values 715 Puzzle solution Random number 716 Opaque length Length of an included Opaque field 717 Opaque Copied unmodified from the received 718 CHALLENGE_REQUEST parameters 720 3. Security Services for the HIP Control Channel 722 In this section, we define the adversary model that the security 723 analysis in the later sections will be based on. 725 3.1. Adversary model and Security Services 727 For discussing the security properties of the proposed HIP extension 728 we first define an attacker model. We assume a Dolev-Yao threat 729 model in which an adversary can eavesdrop on all traffic regardless 730 of its source and destination. The adversary can inject arbitrary 731 packets with any source and destination addresses. Consequently, an 732 adversary can also replay previously eavesdropped messages. However, 733 the adversary cannot subvert the cryptographic ciphers and hash 734 function, nor can it compromise one of the communicating nodes. 736 Even in the face of this strong attacker, the proposed HIP extension 737 enables middleboxes to verify the identity of the communicating HIP 738 peers. It ensures that both peers are involved in the communication 739 and that the HIP BEX or update packets are fresh, i.e. not replayed. 740 It enables the middlebox to verify the source and destination (in 741 terms of HIs) of the HIP association and the integrity of RSA and DSA 742 signed HIP packets. 744 4. Security Services for the HIP Payload Channel 746 The presented extension for HIP authentication by middleboxes only 747 covers the HIP control channel, i.e., the HIP control messages. 748 Depending on the binding between the HIP control and payload channel, 749 certain security properties for the payload channel can be derived 750 from the strong cryptographic authentication of the end-hosts. 751 Assuming that there is a secure binding between packets belonging to 752 a payload stream and the control stream, the same security properties 753 as in Section 3 apply to the payload stream. 755 ESP [RFC5202] is currently the default payload encapsulation format 756 for HIP. A limitation of ESP is that it does not provide a secure 757 binding between the HIP control channel and the ESP traffic on a per- 758 packet basis. Hence, the achievable level of security for the 759 payload channel is lower compared to the HIP control channel. 761 This section discusses security properties of an ESP payload channel 762 bound to a HIP control channel. Depending on the assumed adversary 763 model, certain security services are possible. We briefly describe 764 two application scenarios and how they benefit from the resulting 765 security services. For the payload channel, HIP in combination with 766 the middlebox authentication scheme offers the following security 767 services: 769 Attribute binding: Middleboxes can extract certain payload channel 770 attributes (e.g. locators and SPIs) from the control channel. 771 These attributes can be used to enforce certain restrictions on 772 the payload channel, e.g., to exhibit the same attributes as the 773 control channel. The attributes can either be stated explicitly 774 in the HIP control packets or can be derived from the IP or UDP 775 packets carrying the HIP control messages. 777 Host involvement: Middleboxes can verify whether a certain host is 778 involved in the establishment of a HIP association and, thus, 779 involved in the establishment of the payload channel. 781 Based on these security services we construct two use cases that 782 illustrate the use of HIP authentication by middleboxes: access 783 control and resource allocation as described in the following 784 sections. 786 4.1. Access Control 788 Middleboxes can manage resources based on HIs. As an example, let us 789 assume that a middlebox only forwards HIP payload packets after a 790 successful HIP BEX or HIP update. The middlebox uses the parameters 791 in the control channel (specifically IP addresses and SPIs) to filter 792 the payload traffic. The middlebox only forwards traffic from and to 793 specific authenticated hosts and drops other traffic. 795 The feasibility of subverting the function of the middlebox depends 796 on the assumed adversary model. 798 4.1.1. Adversary model and Security Services 800 If we assume a Dolev-Yao threat model, attribute binding is not 801 helpful to aid packet filtering for access control. An attacker can 802 send packets from any IP address and can read packets destined to any 803 IP address. Without per packet verification by the middlebox, such 804 an attacker can inject arbitrary forged packets into the HIP payload 805 channel and make them traverse the middlebox. The attacker can also 806 read the packets from the HIP payload channel, and hence, communicate 807 across the middlebox. However, the forged packets are disclosed by 808 inconsistencies in the ESP sequence numbers, which makes the attack 809 visible to the middlebox as well as the HIP end hosts. Moreover, 810 attackers can only inject packets into an already established HIP 811 payload channel. Opening a new payload channel and replaying a 812 closing of the channel are not possible. 814 An attacker that is not able to send IP packets from an arbitrary 815 source address and receive IP packets addressed to any destination, 816 cannot use the ESP channel to send fake ESP packets when the 817 middleboxes bind HIs and SPI numbers to addresses. By fixing the set 818 of source and destination IP addresses, the opportunity to 819 successfully inject packets into the payload channel is limited to 820 hosts that can send packets from the same source address as the 821 legitimate HIP hosts. Moreover, an attacker can only receive 822 injected packets if it is on the communication path towards the 823 legitimate HIP peer. Attackers cannot open new HIP payload channels 824 and thus have no influence on the bound payload stream parameters. 826 Finally, attackers cannot close HIP associations of legitimate peers. 828 4.2. Resource allocation 830 When using HIs to limit the resources (e.g. bandwidth) allocated for 831 a certain host, the HIs can be used to authenticate the hosts in a 832 similar fashion to the access control illustrated above. Regarding 833 authentication, both use cases share the same strengths and 834 weaknesses. However, the implications for the targeted scenarios 835 differ. Therefore, we restrict the following discussion to these 836 differences. 838 4.2.1. Adversary Model and Security Services 840 When assuming an Dolev-Yao threat model, an attacker is able to use 841 resources allocated for the payload channel of another host by 842 injecting packets into this channel. Also, the attacker cannot open 843 a new payload channel with another host nor can it close an existing 844 one. 846 When binding the IP addresses of the HIP payload channel to the IP 847 addresses used in the HIP control channel and assuming an attacker is 848 unable to receive IP packets addressed to the IP address of an 849 authenticated host, the attacker cannot utilize the resources 850 allocated to authenticated host. However, the attacker can still 851 inject packets and waste resources, yet without having any benefit 852 other than causing disturbance to the other host. Specifically, it 853 cannot increase the share of resources allocated to itself. Hence, 854 this measure takes incentive from selfish users that try to benefit 855 by mounting a DoS attack. Defense against purely malicious attackers 856 that aim at creating disturbance without immediate benefit is 857 difficult to achieve and out of scope of this document. 859 5. Security Considerations 861 This HIP extension specifies how HIP-aware middleboxes interact with 862 the handshake and mobility-signaling of the Host Identity Protocol. 863 The scope is restricted to the authentication of end-hosts and 864 excludes the issue of stronger authentication of ESP traffic at the 865 middlebox. 867 Providing middleboxes with a way of adding puzzles to the HIP control 868 packets may cause both HIP peers, including the Responder, to spend 869 CPU time on solving these puzzles. Thus, it is advised that HIP 870 implementations for servers employ mechanisms to prevent middlebox 871 puzzles from being used as DoS attacks. Under high CPU load, servers 872 can rate limit or assign lower priority to packets containing 873 middlebox puzzles. 875 6. IANA Considerations 877 This document specifies two new HIP parameter types. The preliminary 878 parameter type numbers are 322 and 65334. 880 7. Acknowledgments 882 Thanks to Thomas Jansen, Shaohui Li, and Janne Lindqvist for the 883 fruitful discussions on this topic. Many thanks to Julien Laganier, 884 Stefan Goetz, Ari Keranen, Samu Varjonen, and Kate Harrison for 885 commenting and helping to improve the quality of this document. 887 8. Changelog 889 8.1. Version 4 891 - Some clarifications. 893 - Add new way to compute single solution for multiple 894 CHALLENGE_REQUEST parameters. 896 - Modify parameter layout for CHALLENGE_RESPONSE parameter. 898 - Add middlebox authentication for the CLOSE exchange. 900 - Updated outdated references. 902 8.2. Version 3 904 - Some editorial changes. 906 - Added text about space issues in response packets with too many 907 CHALLENGE_RESPONSE parameters in Section Section 2.1.2 909 9. Normative References 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 915 (IPv6) Specification", RFC 2460, December 1998. 917 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 918 "Host Identity Protocol", RFC 5201, April 2008. 920 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 921 Encapsulating Security Payload (ESP) Transport Format with 922 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 924 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 925 Protocol (HIP) Registration Extension", RFC 5203, 926 April 2008. 928 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 929 Host Mobility and Multihoming with the Host Identity 930 Protocol", RFC 5206, April 2008. 932 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 933 Firewall Traversal Issues of Host Identity Protocol (HIP) 934 Communication", RFC 5207, April 2008. 936 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 937 Keranen, "Basic Host Identity Protocol (HIP) Extensions 938 for Traversal of Network Address Translators", RFC 5770, 939 April 2010. 941 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 942 Certificates", RFC 6253, May 2011. 944 Authors' Addresses 946 Tobias Heer (editor) 947 RWTH Aachen University, Communication and Distributed Systems Group 948 Ahornstrasse 55 949 Aachen 52062 950 Germany 952 Email: heer@cs.rwth-aachen.de 953 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 954 Rene Hummen 955 RWTH Aachen University, Communication and Distributed Systems Group 956 Ahornstrasse 55 957 Aachen 52062 958 Germany 960 Email: hummen@cs.rwth-aachen.de 961 URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/ 963 Klaus Wehrle 964 RWTH Aachen University, Communication and Distributed Systems Group 965 Ahornstrasse 55 966 Aachen 52062 967 Germany 969 Email: heer@cs.rwth-aachen.de 970 URI: http://www.comsys.rwth-aachen.de/team/klaus/ 972 Miika Komu 973 Aalto University, Department of Computer Science and Engineering 974 Konemiehentie 2 975 Espoo 976 Finland 978 Phone: +358947027117 979 Fax: +358947025014 980 Email: miika@iki.fi 981 URI: http://www.hiit.fi/