idnits 2.17.1 draft-heer-hip-middle-auth-03.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 I1 packers 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. Hence, 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 (September 4, 2011) is 4619 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) Summary: 6 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 3 Internet-Draft K. Wehrle 4 Intended status: Experimental RWTH Aachen University, 5 Expires: March 7, 2012 Communication and Distributed 6 Systems Group 7 M. Komu 8 Aalto University 9 September 4, 2011 11 End-Host Authentication for HIP Middleboxes 12 draft-heer-hip-middle-auth-03 14 Abstract 16 The Host Identity Protocol [RFC5201] is a signaling protocol for 17 secure communication, mobility, and multihoming that introduces a 18 cryptographic namespace. This document specifies an extension for 19 HIP that enables middleboxes to unambiguously verify the identities 20 of hosts that communicate across them. This extension allows 21 middleboxes to verify the liveness and freshness of a HIP association 22 and, thus, to secure access control in middleboxes. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Notation 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 7, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Authentication and Replay Attacks . . . . . . . . . . . . 5 68 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Signed Middlebox Nonces . . . . . . . . . . . . . . . . . 6 70 2.2. Identity Verification by Middleboxes . . . . . . . . . . . 9 71 2.3. Failure Signaling . . . . . . . . . . . . . . . . . . . . 13 72 2.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 13 73 2.5. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 13 74 3. Security Services for the HIP Control Channel . . . . . . . . 15 75 3.1. Adversary model and Security Services . . . . . . . . . . 15 76 4. Security Services for the HIP Payload Channel . . . . . . . . 16 77 4.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 17 78 4.2. Resource allocation . . . . . . . . . . . . . . . . . . . 17 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Version 3 . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 The Host Identity Protocol (HIP) introduces a new cryptographic 90 namespace, based on public keys, in order to secure Internet 91 communication. This namespace allows hosts to securely address and 92 authenticate their peers. HIP was designed to be middlebox-friendly 93 and to allow middleboxes to inspect HIP control traffic. Examples of 94 such middleboxes are firewalls and Network Address Translators 95 (NATs). 97 In this context, one can distinguish HIP-aware middleboxes, which are 98 designed to process HIP packets, and other middleboxes, which are 99 unaware of HIP. This document addresses only HIP-aware middleboxes 100 while the behavior of HIP in combination with HIP-unaware middleboxes 101 is specified in [I-D.ietf-hip-nat-traversal]. Moreover, the scope of 102 this document is restricted to middleboxes that use HIP in order to 103 provide Authentication, Authorization, and Accounting (AAA)-related 104 services and, thus, need to authenticate the communicating peers that 105 send traffic over the middlebox. The class of middleboxes this 106 document focuses on does not require the end-host to explicitly 107 register to the middlebox. HIP behavior for interacting and 108 registering to such middleboxes is specified in [RFC5203]. Thus, we 109 focus on middleboxes that build their state based on packets they 110 forward (path-coupled signaling). 112 An example of such a middlebox is a firewall that only allows traffic 113 from certain hosts to traverse. We assume that access control is 114 performed based on Host Identities (HIs). Such an authenticating 115 middlebox needs to observe the HIP Base EXchange (BEX) or a HIP 116 mobility update [RFC5206] and check the Host Identifiers (HIs) in the 117 packets. 119 Along the lines of [I-D.irtf-hiprg-nat], an authentication solution 120 for middleboxes must have some vital properties. For one, the 121 middlebox must be able to unambiguously identify one or both of the 122 communicating peers. Additionally, the solution must not allow for 123 new attacks against the middlebox. This document specifies a HIP 124 extension that allows middleboxes to participate in the HIP handshake 125 and the HIP update process in order to allow these middleboxes to 126 reliably verify the identities of the communicating peers. To this 127 end, this HIP extension defines how middleboxes can interact with 128 end-hosts in order to verify their identities. 130 Verifying public-key (PK) signatures is costly in terms of CPU 131 cycles. Thus, in addition to authentication capabilities, it is also 132 necessary to provide middleboxes with a way of defending against 133 resource-exhaustion attacks that target PK signature verification. 134 This document defines how middleboxes can utilize the HIP puzzle 135 mechanism defined in [RFC5201] to slow down resource-exhaustion 136 attacks. 138 The presented authentication extension only targets the HIP control 139 channel. Additional security considerations and possible security 140 services for the HIP payload channel are discussed in Section 4. 142 1.1. Authentication and Replay Attacks 144 Middleboxes may need to verify the HIs in the HIP base exchange 145 messages to perform access control based on Host Identities. 146 However, passive verification of HIs in the messages is not 147 sufficient to ensure the identity of an end-host because of a 148 possible replay attack against which the basic HIP protocol as 149 specified in [RFC5201] does not provide adequate protection. 151 To illustrate the need for additional security measures for HIP-aware 152 middleboxes, we briefly outline the replay attack: Assume that the 153 legitimate owner of Host Identity Tag (HIT) X establishes a HIP 154 association with the legitimate owner of HIT Y at some point in time 155 and an attacker A overhears the base exchange and records it. 157 Assume that a middlebox M checks HIP HIs in order to restrict traffic 158 passing through the box. At some later point in time, Attacker A 159 collaborates with another attacker B. They replay the very same BEX 160 packets to the middlebox M on the communication path. Note that it 161 is not required that the middlebox M was on the communication path 162 between X and Y when the BEX was recorded. 164 The middlebox has no way to distinguish legitimate hosts X and Y from 165 the attackers A and B as it can only overhear the BEX passively and 166 it cannot can distinguish the replayed BEX from a the genuine 167 handshake. As the attackers overheard the SPI numbers, they can 168 traverse the middlebox with "fake" ESP packets with valid SPI 169 numbers, and hence, send data across M without proper authentication. 170 Since the middleboxes do not know the integrity and encryption keys 171 for ESP, they cannot distinguish valid ESP packets from forged ones. 172 Hence, collaborating attackers can use any replayed BEX to falsely 173 authenticate to the middlebox and thus impersonate any host. This is 174 problematic in cases in which the middlebox needs to know the 175 identity of the peers that communicate across it. Examples for such 176 cases are AAA-related services, such as access control, logging of 177 activities, and accounting for traffic volume or connection duration. 179 This attack scenario is not addressed by the current HIP 180 specifications. Therefore, this document specifies a HIP extension 181 that allows middleboxes to defend against this attack. 183 2. Protocol Overview 185 This section gives an overview of the interaction between hosts and 186 authenticating middleboxes. This document describes a framework that 187 middleboxes can use to implement authentication of end-hosts and 188 leaves its further use to other documents and to middlebox 189 implementors. 191 2.1. Signed Middlebox Nonces 193 The described attack scenario shows the necessity for unambiguous 194 end-host identity verification by middleboxes. However, this 195 authentication cannot be purely end-to end: a) Relying on nonces 196 generated by the end-hosts is not possible because middleboxes cannot 197 verify the freshness of these nonces. b) Introducing time-stamps 198 restricts the attack to a certain time frame but requires global time 199 synchronization and therefore should be avoided. 201 The following sections specify how HIP hosts can prove their identity 202 by performing a challenge-response protocol between the middlebox and 203 the end-hosts. As a challenge, the middlebox adds information (e.g. 204 self-generated nonces) to HIP control packets which the end-hosts 205 sign with public-key (PK) signatures and echo back. 207 The challenge-response mechanism is similar to the ECHO_REQUEST/ 208 ECHO_RESPONSE mechanism employed already by HIP end-hosts (see 209 [RFC5201] ). It assumes that the end-hosts exchange at least two HIP 210 packets with each other. The middlebox adds a CHALLENGE_REQUEST 211 parameter to the first HIP control packet. Similar to the 212 ECHO_REQUEST parameter in the original HIP protocol, this parameter 213 contains an opaque data field that must be echoed by its receiver. 214 The receiver echoes the opaque data field in a CHALLENGE_RESPONSE 215 parameter. The CHALLENGE_RESPONSE parameter must be covered by the 216 packet signature, thereby proving that the receiver is in possession 217 of the private key that corresponds to the HI. 219 The middlebox can either verify the identity of the initiator, the 220 responder, or both peers, depending on the purpose of the middlebox. 221 The choice of which authentication is required left to middlebox 222 implementers. 224 2.1.1. CHALLENGE_REQUEST 226 Middleboxes MAY add CHALLENGE_REQUEST parameters to the R1 and I1 227 packers and to any UPDATE packet. This parameter contains an opaque 228 data block of variable size, which the middlebox uses to carry 229 arbitrary data (e.g., a nonce). The HIP packets that carry middlebox 230 challenges may contain multiple CHALLENGE_REQUEST parameters, since 231 all middleboxes on the path may add these parameters. Hence, the MBs 232 should restrict the size of the variable data field in the 233 CHALLENGE_REQUEST parameter. The total length of the packets SHOULD 234 not exceed 1280 bytes to avoid IPv6 fragmentation [RFC2460]. 236 The middleboxes add the CHALLENGE_REQUEST parameter to the 237 unprotected part of a HIP message. Thus it does not corrupt any HMAC 238 or public-key signatures that protect the HIP packet. However, the 239 middlebox MUST recompute the IP and HIP header checksums as defined 240 in [RFC5201] and the UDP headers of UDP encapsulated HIP packets as 241 defined in [I-D.ietf-hip-nat-traversal]. 243 A HIP end-host that receives a HIP control packet containing one or 244 multiple CHALLENGE_REQUEST parameters must copy the contents of each 245 parameter without modification to a CHALLENGE_RESPONSE parameter. 246 This end-host MUST send the CHALLENGE_RESPONSE parameter within the 247 signed part of its reply. Note that middleboxes MAY also add 248 ECHO_REQUEST_UNSIGNED parameter as specified in [RFC5201] if the 249 receiver of the parameter is not required to sign the contents of the 250 ECHO_REQUEST. 252 Middleboxes can delay state creation by utilizing the 253 CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters by hiding 254 encrypted or otherwise protected information about previous 255 authentication steps in the opaque data field. 257 2.1.2. CHALLENGE_RESPONSE 259 When a middlebox injects an opaque blob of data with a 260 CHALLENGE_REQUEST parameter, it expects to receive the same data 261 without modification as part of a CHALLENGE_RESPONSE parameter in a 262 subsequent packet. The opaque data MUST be copied as it is from the 263 corresponding CHALLENGE_REQUEST parameter. In the case of multiple 264 CHALLENGE_REQUEST parameters, their order MUST be preserved by the 265 corresponding CHALLENGE_RESPONSE parameters. 267 The CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters MAY be used 268 for any purpose, in particular when a middlebox has to carry state 269 information in a HIP packet to receive it in the next response 270 packet. The CHALLENGE_RESPONSE MUST be covered by the HIP_SIGNATURE. 272 The CHALLENGE_RESPONSE parameter is non-critical. Depending on its 273 local policy, a middlebox can react differently on a missing 274 CHALLENGE_RESPONSE parameter. Possible actions range from degraded 275 or restricted service, such as bandwidth limitation, up to refusing 276 connections and reporting access violations. 278 When sending a HIP control packet, an end-host may face the problem 279 that not all CHALLENGE_RESPONSE parameters fit into the HIP control 280 packet. In this case, the host should send several packets 281 containing the with the first packet containing the tail of the 282 sequence of ECHO_RESPONSE_M parameters and further packets containing 283 the rest in reverse order of inclusion of the CHALLENGE_REQUEST 284 parameters in the previous packet. This way, the middleboxes closest 285 to the sender will already have authenticated the identity of the 286 peers and can let further control packets pass. 288 2.1.3. Middlebox Puzzles 290 Since PK operations are costly in terms of CPU cycles, a middlebox 291 has to defend itself against resource-exhaustion attacks when 292 verifying signatures in HIP packets. The HIP base protocol [RFC5201] 293 specifies a puzzle mechanism to protect the Responder from I2 floods 294 that require numerous public-key operations. However, middleboxes 295 cannot utilize this mechanism because a they cannot verify the 296 freshness of the puzzle solution in the BEX packets. This section 297 specifies how middleboxes can utilize the puzzle mechanism to add 298 their own puzzles to R1, I2, and any UPDATE packets. This allows 299 middleboxes to shelter against Denial of Service (DoS) attacks on PK 300 verification. 302 The puzzle mechanism for middleboxes utilizes the CHALLENGE_REQUEST 303 and CHALLENGE_RESPONSE parameters. The CHALLENGE_REQUEST parameter 304 contains fields for setting the difficulty and the expiration date of 305 the puzzle. In contrast to the PUZZLE parameter in the HIP base 306 specifications, there is no dedicated puzzle seed field. Instead, 307 the hash of the opaque data field in the CHALLENGE_REQUEST parameter 308 serves as puzzle seed. The hash is generated by applying the SHA-1 309 algorithm to the opaque data field. The destination end-host of the 310 HIP control packet MUST solve the puzzle and provide the solution in 311 the CHALLENGE_RESPONSE parameter. The middlebox can set the puzzle 312 difficulty by adjusting the K value in the CHALLENGE_REQUEST packet. 313 The semantics of this field equal the semantics of the PUZZLE 314 parameter. Setting K to 0 signifies that no puzzle solution is 315 required. 317 Since a puzzle increases the delay and computational cost for 318 establishing or updating a HIP association, a middlebox SHOULD only 319 increase K when it is under attack. Moreover, middleboxes SHOULD 320 distinguish attack directions. If the majority of the CPU load is 321 caused by verifying HIP control messages that arrive from a certain 322 interface, middleboxes MAY increase K for HIP control packets that 323 leave the interface. The middlebox chooses the difficultly of the 324 puzzle according to its load and local policies. 326 2.2. Identity Verification by Middleboxes 328 This section describes how middleboxes can influence the BEX and the 329 HIP update process in order to verify the identity of the HIP end- 330 hosts. 332 2.2.1. Identity Verification During BEX 334 Middleboxes MAY add CHALLENGE_REQUEST parameters to R1 and I2 packets 335 in order to verify the identities of the participating end-hosts. 336 Middleboxes can choose either to authenticate the Initiator, the 337 Responder, or both. Middleboxes MUST NOT add CHALLENGE_REQUEST 338 parameters to I1 messages because this would expose the Responder to 339 DoS attacks. Thus, middleboxes MUST let unauthenticated and minimal 340 I1 packets traverse. Minimal means that the I1 packet MUST NOT 341 contain more than the minimal set of parameters specified by HIP 342 standards or internet drafts. In particular, the I1 packet MUST NOT 343 contain any attached payload. Figure 1 illustrates the 344 authentication process during the BEX. 346 Main path: 348 Initiator Middlebox Responder 349 .-----------------. 350 I1 | | I1 351 -----------------> | |----------------------------> 352 | | 353 R1, + CQ1 | Add CQ | R1 354 <----------------- | |<---------------------------- 355 | | 356 I2, {CR1} | Verify CR1 | I2, {CR1} + CQ2 357 -----------------> | Add CQ2 |----------------------------> 358 | | 359 | | 360 R2, {CR2} | Verify CR2 | R2, {CR2} 361 <----------------- | |<----------------------------- 362 '-----------------' 364 CQ: Middlebox challenge reQuest 365 CR: Middlebox challenge Response 366 {}: Signature with sender's HI as key 368 Middlebox authentication of a HIP base exchange. 370 Figure 1 372 2.2.2. Identity Verification During Mobility Updates 374 HIP rekeying, mobility and multihoming UPDATE mechanisms for non- 375 NATted environments are described in [RFC5206]. This section 376 describes how middleboxes process UPDATE messages in non-NATted 377 environments and leave NATted environments for future revisions of 378 the draft. 380 The middleboxes can apply middlebox challenges to mobility related 381 HIP control messages in the case where both end-hosts are single- 382 homed. The middlebox challenges can be applied both ways as the 383 UPDATE process consists of three packets (U1, U2, U3) which all 384 traverse through the same middlebox as shown in Figure 2. 386 In cases, in which fewer packets are used for updating an 387 association, the following rule applies. 389 RESPONSE RULE: 391 A HIP host, receiving a CHALLENGE_REQUEST MUST reply with a 392 CHALLENGE_RESPONSE in its next UPDATE packet. If no further UPDATE 393 packets are necessary to complete the update procedure, an additional 394 UPDATE packet containing the CHALLENGE_RESPONSE MUST be sent. 396 Initiator Middlebox Responder 397 .------. 398 U1 | | U1 + CQ1 399 -----------------------------> | | --------------------------> 400 | | 401 U2, {CR1} + CQ2 | | U2, {CR1} 402 <----------------------------- |OK | <-------------------------- 403 | | 404 U3, {CR2} | | U3, {CR2} 405 -----------------------------> | OK| --------------------------> 406 '------' 407 CQ: Middlebox challenge reQuest 408 CR: Middlebox challenge Response 409 {}: Signature with sender's HI as key 411 Middlebox authentication of a HIP mobility update over a single path. 413 Figure 2 415 Middlebox 1 in Figure 2 can verify the identity of the Responder by 416 checking its PK signature and the presence of the CHALLENGE_RESPONSE 417 in the U2 packet. If necessary, the middlebox MAY add an 418 CHALLENGE_REQUEST for the Initiator of the update. The middlebox can 419 verify the Initiator's identity by verifying its signature and the 420 CHALLENGE_RESPONSE in the U3 packet. 422 2.2.3. Identity Verification for Multihomed Mobility Updates 424 Multihomed hosts may use multiple communication paths during an HIP 425 mobility update. Depending on whether the middlebox is located on 426 the communication path between the preferred locators of the hosts or 427 not, the middlebox forwards different packets and, thus, needs to 428 interact differently with the updates. Figure 3 I) and II) 429 illustrates an update with Middlebox 1 on the path between the 430 Initiator's and the Responder's preferred locators and with Middlebox 431 2 on an alternative path. Middlebox 2 is not located on the path 432 between the preferred locators of the HIP end-hosts does not receive 433 the U1 message. Therefore, it will not recognize any 434 CHALLENGE_RESPONSE (CR1) in the second UPDATE packet. Thus, if a 435 middlebox encounters non-matching or missing CHALLENGE_RESPONSE 436 parameter in an initial update packet, the middlebox SHOULD ignore 437 it. 439 Complying to the RESPONSE RULE stated in Section Section 2.2.2, the 440 RESPONDER generates an additional fourth update packet on receiving 441 the CHALLENGE_REQUEST. The update process for a middlebox on the 442 preferred communication path (Middlebox 1) and a middlebox off the 443 preferred communication path (Middlebox 2) is depicted in Figure 3. 445 I) Main path: 447 Initiator Middlebox 1 Responder 448 .------. 449 U1 | | U1 + CQ1 450 ----------------------------> | | ---------------------------> 451 | | 452 U2, {CR1} + CQ2 | | U2, {CR1} 453 <---------------------------- |OK | <--------------------------- 454 | | 455 U3, {CR2} | | U3, {CR2} 456 ----------------------------> | OK| ---------------------------> 457 '------' 459 II) Alternative path: 461 Initiator Middlebox 2 Responder 463 U1 (bypasses Middlebox 2) 464 ------------------------------------------------------------------> 465 .------. 466 U2, {CR1} + CQ3 | | U2, {CR1} 467 <---------------------------- | wrong| <--------------------------- 468 | | 469 U3', {CR3} | | U3', {CR3} + CQ4 470 ----------------------------> |OK | ---------------------------> 471 | | 472 U4, {CR4} | | U4, {CR4} 473 <---------------------------- | OK| <--------------------------- 474 '------' 475 CQ: Middlebox challenge reQuest 476 CR: Middlebox challenge Response 477 {}: Signature with sender's HI as key 479 Middlebox authentication of a HIP mobility update over different 480 paths. 482 Figure 3 484 2.2.4. Identity Signaling During Updates 486 As middleboxes have to verify rapidly and forward HIP packets, they 487 need to be supplied with all information necessary to do so. If end- 488 hosts hand over communication to a new communication path, 489 middleboxes need to be able to learn their Host Identifiers (HIs) 490 from the UPDATE packets. Therefore, all packets that contain a 491 CHALLENGE_RESPONSE parameter MUST contain the HOST_ID parameter. 493 2.2.5. Closing of Connections 495 At the time being, identity verification during the closing of a HIP 496 association is not supported. Hence, the middlebox MUST preserve the 497 state until it expires according to local policies. An appropriate 498 mechanism for middleboxes to verify CLOSE messages by middleboxes 499 will be provided in future versions of this document. 501 2.3. Failure Signaling 503 Middleboxes SHOULD inform the sender of a BEX packet or update packet 504 if it does not satisfy the requirements of the middlebox. Reasons 505 for non-satisfactory packets are missing HOST_ID or 506 CHALLENGE_RESPONSE parameters. Other reasons may be middlebox 507 policies regarding, for example, insufficient client capabilities or 508 or insufficient credentials delivered in a HIP CERT parameter 509 [I-D.varjonen-hip-cert]. Options for expressing such shortcomings 510 are ICMP packets if no HIP association is established and HIP_NOTIFY 511 packets in case of an already established HIP association. Defining 512 this signaling mechanism is future work. 514 2.4. Fragmentation 516 Analogously to the specification in [RFC5201], HIP aware middleboxes 517 SHOULD support IP-level fragmentation and reassembly for IPv6 and 518 MUST support IP-level fragmentation and reassembly for IPv4. 519 However, when adding CHALLENGE_REQUEST parameters, a middlebox SHOULD 520 keep the total packet size below 1280 bytes to avoid packet 521 fragmentation in IPv6. 523 2.5. HIP Parameters 525 This HIP extension specifies four new HIP parameters that allow 526 middleboxes to authenticate HIP end-hosts and to protect against DoS 527 attacks. 529 2.5.1. CHALLENGE_REQUEST 531 A middlebox MAY append the CHALLENGE_REQUEST parameter to R1, I2, and 532 UPDATE packets. The structure of the CHALLENGE_REQUEST parameter is 533 depicted in the following figure. The semantics of the K and 534 Lifetime fields is identical to the fields defined in the PUZZLE 535 parameter in [RFC5201]. The opaque data field serves as nonce and 536 puzzle seed value. To generate the seed corresponding to the 8-byte 537 value I in [RFC5201], the receiver of the puzzle applies SHA-1 to the 538 opaque data field and truncates the result to 8-byte length. Note 539 that the opaque data field must provide enough randomness to serve as 540 puzzle seed. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type | Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | K, 1 byte | Lifetime | / 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 549 / / 550 / Opaque, (variable length) / 551 / +-+-+-+-+-+-+-+-+-+-| 552 / | Padding | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Type 65334 556 Length Variable 557 K K is the number of verified bits 558 Lifetime Challenge lifetime 2^(value-32) seconds 559 Opaque Opaque data that serves as nonce and as basis for the 560 puzzle. The puzzle value I is generated by hashing the 561 opaque data field with the hash function SHA-1 and 562 truncating it to 8-byte length. 563 Random #I Random number 565 2.5.2. CHALLENGE_RESPONSE 567 The CHALLENGE_RESPONSE parameter is the response to the 568 CHALLENGE_REQUEST parameter. The receiver of a CHALLENGE_REQUEST 569 parameter SHOULD reply with a CHALLENGE_RESPONSE. Otherwise, the 570 middlebox that added the CHALLENGE_REQUEST parameter MAY decide to 571 degrade or deny its service. The contents of the CHALLENGE_REQUEST 572 parameter must be copied to the CHALLENGE_RESPONSE parameter without 573 any modification. If the puzzle difficulty in the CHALLENGE_REQUEST 574 parameter is set to any other value except 0, an appropriate puzzle 575 solution (adhering to the SOLUTION specifications in [RFC5201]) must 576 be provided in the CHALLENGE_RESPONSE parameter. The 577 CHALLENGE_RESPONSE parameter is non-critical and covered by the 578 SIGNATURE. The structure of the CHALLENGE_RESPONSE parameter is 579 depicted below: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Length | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | K, 1 byte | Lifetime | / 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 588 / Puzzle solution #J, 8 bytes / 589 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 / | / 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 592 / Opaque, (variable length) / 593 / +-+-+-+-+-+-+-+-+-+-| 594 / | Padding | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Type 322 598 Length Variable 599 K K is the number of verified bits 600 Opaque Copied unmodified from the received 601 CHALLENGE_REQUEST parameter 602 Puzzle solution Random number 604 3. Security Services for the HIP Control Channel 606 In this section, we define the adversary model that the security 607 analysis in the later sections will be based on. 609 3.1. Adversary model and Security Services 611 For discussing the security properties of the proposed HIP extension 612 we first define an attacker model. We assume a Dolev-Yao threat 613 model in which an adversary can eavesdrop on all traffic regardless 614 of its source and destination. The adversary can inject arbitrary 615 packets with any source and destination addresses. Consequently, an 616 adversary can also replay previously eavesdropped messages. However, 617 the adversary cannot subvert the cryptographic ciphers and hash 618 function, nor can it compromise one of the communicating nodes. 620 Even in the face of this strong attacker, the proposed HIP extension 621 enables middleboxes to verify the identity of the communicating HIP 622 peers. It ensures that both peers are involved in the communication 623 and that the HIP BEX or update packets are fresh, i.e. not replayed. 625 It enables the middlebox to verify the source and destination (in 626 terms of HIs) of the HIP association and the integrity of RSA and DSA 627 signed HIP packets. 629 4. Security Services for the HIP Payload Channel 631 The presented extension for HIP authentication by middleboxes only 632 covers the HIP control channel, i.e., the HIP control messages. 633 Depending on the binding between the HIP control and payload channel, 634 certain security properties for the payload channel can be derived 635 from the strong cryptographic authentication of the end-hosts. 636 Assuming that there is a secure binding between packets belonging to 637 a payload stream and the control stream, the same security properties 638 as in Section 3 apply to the payload stream. 640 ESP [RFC5202] is currently the default payload encapsulation format 641 for HIP. A limitation of ESP is that it does not provide a secure 642 binding between the HIP control channel and the ESP traffic on a per- 643 packet basis. Hence, the achievable level of security for the 644 payload channel is lower compared to the HIP control channel. 646 This section discusses security properties of an ESP payload channel 647 bound to a HIP control channel. Depending on the assumed adversary 648 model, certain security services are possible. We briefly describe 649 two application scenarios and how they benefit from the resulting 650 security services. For the payload channel, HIP in combination with 651 the middlebox authentication scheme offers the following security 652 services: 654 Attribute binding: Middleboxes can extract certain payload channel 655 attributes (e.g. locators and SPIs) from the control channel. 656 These attributes can be used to enforce certain restrictions on 657 the payload channel, e.g., to exhibit the same attributes as the 658 control channel. The attributes can either be stated explicitly 659 in the HIP control packets or can be derived from the IP or UDP 660 packets carrying the HIP control messages. 662 Host involvement: Middleboxes can verify whether a certain host is 663 involved in the establishment of a HIP association and, thus, 664 involved in the establishment of the payload channel. 666 Based on these security services we construct two use cases that 667 illustrate the use of HIP authentication by middleboxes: access 668 control and resource allocation as described in the following 669 sections. 671 4.1. Access Control 673 Middleboxes can manage resources based on HIs. As an example, let us 674 assume that a middlebox only forwards HIP payload packets after a 675 successful HIP BEX or HIP update. The middlebox uses the parameters 676 in the control channel (specifically IP addresses and SPIs) to filter 677 the payload traffic. The middlebox only forwards traffic from and to 678 specific authenticated hosts and drops other traffic. 680 The feasibility of subverting the function of the middlebox depends 681 on the assumed adversary model. 683 4.1.1. Adversary model and Security Services 685 If we assume a Dolev-Yao threat model, attribute binding is not 686 helpful to aid packet filtering for access control. An attacker can 687 send packets from any IP address and can read packets destined to any 688 IP address. Without per packet verification by the middlebox, such 689 an attacker can inject arbitrary forged packets into the HIP payload 690 channel and make them traverse the middlebox. The attacker can also 691 read the packets from the HIP payload channel, and hence, communicate 692 across the middlebox. However, the forged packets are disclosed by 693 inconsistencies in the ESP sequence numbers, which makes the attack 694 visible to the middlebox as well as the HIP end hosts. Moreover, 695 attackers can only inject packets into an already established HIP 696 payload channel. Opening a new payload channel and replaying a 697 closing of the channel are not possible. 699 An attacker that is not able to send IP packets from an arbitrary 700 source address and receive IP packets addressed to any destination, 701 cannot use the ESP channel to send fake ESP packets when the 702 middleboxes bind HIs and SPI numbers to addresses. By fixing the set 703 of source and destination IP addresses, the opportunity to 704 successfully inject packets into the payload channel is limited to 705 hosts that can send packets from the same source address as the 706 legitimate HIP hosts. Moreover, an attacker can only receive 707 injected packets if it is on the communication path towards the 708 legitimate HIP peer. Attackers cannot open new HIP payload channels 709 and thus have no influence on the bound payload stream parameters. 710 Finally, attackers cannot close HIP associations of legitimate peers. 712 4.2. Resource allocation 714 When using HIs to limit the resources (e.g. bandwidth) allocated for 715 a certain host, the HIs can be used to authenticate the hosts in a 716 similar fashion to the access control illustrated above. Regarding 717 authentication, both use cases share the same strengths and 718 weaknesses. However, the implications for the targeted scenarios 719 differ. Therefore, we restrict the following discussion to these 720 differences. 722 4.2.1. Adversary Model and Security Services 724 When assuming an Dolev-Yao threat model, an attacker is able to use 725 resources allocated for the payload channel of another host by 726 injecting packets into this channel. Also, the attacker cannot open 727 a new payload channel with another host nor can it close an existing 728 one. 730 When binding the IP addresses of the HIP payload channel to the IP 731 addresses used in the HIP control channel and assuming an attacker is 732 unable to receive IP packets addressed to the IP address of an 733 authenticated host, the attacker cannot utilize the resources 734 allocated to authenticated host. However, the attacker can still 735 inject packets and waste resources, yet without having any benefit 736 other than causing disturbance to the other host. Specifically, it 737 cannot increase the share of resources allocated to itself. Hence, 738 this measure takes incentive from selfish users that try to benefit 739 by mounting a DoS attack. Defense against purely malicious attackers 740 that aim at creating disturbance without immediate benefit is 741 difficult to achieve and out of scope of this document. 743 5. Security Considerations 745 This HIP extension specifies how HIP-aware middleboxes interact with 746 the handshake and mobility-signaling of the Host Identity Protocol. 747 The scope is restricted to the authentication of end-hosts and 748 excludes the issue of stronger authentication of ESP traffic at the 749 middlebox. 751 Providing middleboxes with a way of adding puzzles to the HIP control 752 packets may cause both HIP peers, including the Responder, to spend 753 CPU time on solving these puzzles. Thus, it is advised that HIP 754 implementations for servers employ mechanisms to prevent middlebox 755 puzzles from being used as DoS attacks. Under high CPU load, servers 756 can rate limit or assign lower priority to packets containing 757 middlebox puzzles. 759 6. IANA Considerations 761 This document specifies two new HIP parameter types. The preliminary 762 parameter type numbers are 322 and 65334. 764 7. Acknowledgments 766 Thanks to Thomas Jansen, Shaohui Li, and Janne Lindqvist for the 767 fruitful discussions on this topic. Many thanks to Julien Laganier, 768 Stefan Goetz, Ari Keranen, Samu Varjonen, Rene Hummen, and Kate 769 Harrison for commenting and helping to improve the quality of this 770 document. 772 8. Changelog 774 8.1. Version 3 776 - Some editorial changes. 778 - Added text about space issues in response packets with too many 779 CHALLENGE_RESPONSE parameters in Section Section 2.1.2 781 9. Normative References 783 [I-D.ietf-hip-nat-traversal] 784 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 785 Keranen, "Basic HIP Extensions for Traversal of Network 786 Address Translators", draft-ietf-hip-nat-traversal-09 787 (work in progress), October 2009. 789 [I-D.irtf-hiprg-nat] 790 Stiemerling, M., "NAT and Firewall Traversal Issues of 791 Host Identity Protocol (HIP) Communication", 792 draft-irtf-hiprg-nat-04 (work in progress), March 2007. 794 [I-D.varjonen-hip-cert] 795 Heer, T. and S. Varjonen, "HIP Certificates", 796 draft-varjonen-hip-cert-01 (work in progress), July 2008. 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", BCP 14, RFC 2119, March 1997. 801 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 802 (IPv6) Specification", RFC 2460, December 1998. 804 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 805 "Host Identity Protocol", RFC 5201, April 2008. 807 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 808 Encapsulating Security Payload (ESP) Transport Format with 809 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 811 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 812 Protocol (HIP) Registration Extension", RFC 5203, 813 April 2008. 815 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 816 Host Mobility and Multihoming with the Host Identity 817 Protocol", RFC 5206, April 2008. 819 Authors' Addresses 821 Tobias Heer 822 RWTH Aachen University, Communication and Distributed Systems Group 823 Ahornstrasse 55 824 Aachen 52062 825 Germany 827 Email: heer@cs.rwth-aachen.de 828 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 830 Klaus Wehrle 831 RWTH Aachen University, Communication and Distributed Systems Group 832 Ahornstrasse 55 833 Aachen 52062 834 Germany 836 Email: heer@cs.rwth-aachen.de 837 URI: http://www.comsys.rwth-aachen.de/team/klaus/ 839 Miika Komu 840 Aalto University, Department of Computer Science and Engineering 841 Konemiehentie 2 842 Espoo 843 Finland 845 Phone: +358947027117 846 Fax: +358947025014 847 Email: miika@iki.fi 848 URI: http://www.hiit.fi/