Host Identity Protocol T. Heer, Ed. Internet-Draft K. Wehrle Intended status: Experimental Distributed Systems Group, RWTH Expires: September 1, 2009 Aachen University M. Komu HIIT February 28, 2009 End-Host Authentication for HIP Middleboxes draft-heer-hip-middle-auth-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Heer, et al. Expires September 1, 2009 [Page 1] Internet-Draft Hip-Middle-Auth February 2009 Abstract The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension allows middleboxes to verify the liveness and freshness of a HIP association and, thus, to secure access control in middleboxes. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Notation [x] indicates that x is optional. {x} indicates that x is under signature. Initiator is the host that initiates a HIP association (cf. HIP base protocol). Responder is the host that responds to the INITIATOR (cf. HIP base protocol). --> signifies "Initiator to Responder" communication. <-- signifies "Responder to Initiator" communication. Heer, et al. Expires September 1, 2009 [Page 2] Internet-Draft Hip-Middle-Auth February 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Authentication and Replay Attacks . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Signed Middlebox Nonces . . . . . . . . . . . . . . . . . 6 2.2. Identity Verification by Middleboxes . . . . . . . . . . . 8 2.3. Failure Signaling . . . . . . . . . . . . . . . . . . . . 13 2.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 13 2.5. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 13 3. Security Services for the HIP Control Channel . . . . . . . . 15 3.1. Adversary model and Security Services . . . . . . . . . . 15 4. Security Services for the HIP Payload Channel . . . . . . . . 16 4.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Resource allocation . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Heer, et al. Expires September 1, 2009 [Page 3] Internet-Draft Hip-Middle-Auth February 2009 1. Introduction The Host Identity Protocol (HIP) introduces a new cryptographic namespace, based on public keys, in order to secure Internet communication. This namespace allows hosts to securely address and authenticate their peers. HIP was designed to be middlebox-friendly and to allow middleboxes to inspect HIP control traffic. Examples of such middleboxes are firewalls and Network Address Translators (NATs). In this context, one can distinguish HIP-aware middleboxes, which are designed to process HIP packets, and other middleboxes, which are unaware of HIP. This document addresses only HIP-aware middleboxes while the behavior of HIP in combination with HIP-unaware middleboxes is specified in [I-D.ietf-hip-nat-traversal]. Moreover, the scope of this document is restricted to middleboxes that use HIP in order to provide Authentication, Authorization, and Accounting (AAA)-related services and, thus, need to authenticate the communicating peers that send traffic over the middlebox. The class of middleboxes this document focuses on does not require the end-host to explicitly register to the middlebox. HIP behavior for interacting and registering to such middleboxes is specified in [RFC5203]. Thus, we focus on middleboxes that build their state based on packets they forward (path-coupled signaling). An example of such a middlebox is a firewall that only allows traffic from certain hosts to traverse. We assume that access control is performed based on Host Identities (HIs). Such an authenticating middlebox needs to observe the HIP Base EXchange (BEX) or a HIP mobility update [RFC5206] and check the Host Identifiers (HIs) in the packets. Along the lines of [I-D.irtf-hiprg-nat], an authentication solution for middleboxes must have some vital properties. For one, the middlebox must be able to unambiguously identify one or both of the communicating peers. Additionally, the solution must not allow for new attacks against the middlebox. This document specifies a HIP extension that allows middleboxes to participate in the HIP handshake and the HIP update process in order to allow these middleboxes to reliably verify the identities of the communicating peers. To this end, this HIP extension defines how middleboxes can interact with end-hosts in order to verify their identities. Verifying public-key (PK) signatures is costly in terms of CPU cycles. Thus, in addition to authentication capabilities, it is also necessary to provide middleboxes with a way of defending against resource-exhaustion attacks that target PK signature verification. This document defines how middleboxes can utilize the HIP puzzle Heer, et al. Expires September 1, 2009 [Page 4] Internet-Draft Hip-Middle-Auth February 2009 mechanism defined in [RFC5201] to slow down resource-exhaustion attacks. The presented authentication extension only targets the HIP control channel. Additional security considerations and possible security services for the HIP payload channel are discussed in Section 4. 1.1. Authentication and Replay Attacks Middleboxes may need to verify the HIs in the HIP base exchange messages to perform access control based on Host Identities. However, passive verification of HIs in the messages is not sufficient to ensure the identity of an end-host because of a possible replay attack against which the basic HIP protocol as specified in [RFC5201] does not provide adequate protection. To illustrate the need for additional security measures for HIP-aware middleboxes, we briefly outline the replay attack: Assume that the legitimate owner of Host Identity Tag (HIT) X establishes a HIP association with the legitimate owner of HIT Y at some point in time and an attacker A overhears the base exchange and records it. Assume that a middlebox M checks HIP HIs in order to restrict traffic passing through the box. At some later point in time, Attacker A collaborates with another attacker B. They replay the very same BEX over a middlebox M on the communication path. Note that it is not required that the middlebox M was on the communication path between the peers when the BEX was recorded. The middlebox has no way to distinguish legitimate hosts X and Y from the attackers A and B as it can only overhear the BEX passively and it cannot can distinguish the replayed BEX from a the genuine handshake. As the attackers overheard the SPI numbers, they can taverse the middlebox with "fake" ESP packets with valid SPI numbers, and hence, send data across m without proper authentication. Since the middleboxes do not know the integrity and encryption keys for ESP, they cannot distinguish valid ESP packets from fake ones. Hence, collaborating attackers can use any replayed BEX to falsely authenticate to the middlebox and thus impersonate any host. This is problematic in cases in which the middlebox needs to know the identity of the peers that communicate across it. Examples for such cases are AAA-related services, such as access control, logging of activities, and accounting for traffic volume or connection duration. This attack scenario is not addressed by the current HIP specifications. Therefore, this document specifies a HIP extension that allows middleboxes to defend against this attack. Heer, et al. Expires September 1, 2009 [Page 5] Internet-Draft Hip-Middle-Auth February 2009 2. Protocol Overview This section gives an overview of the interaction between hosts and authenticating middleboxes. This document describes a framework that middleboxes can use to implement authentication of end-hosts and leaves its further use to other documents and to middlebox implementors. 2.1. Signed Middlebox Nonces The described attack scenario shows the necessity for unambiguous end-host identity verification by middleboxes. Relying on nonces generated by the end-hosts is not possible because middleboxes cannot verify the freshness of these nonces. Introducing time-stamps restricts the attack to a certain time frame but requires global time synchronization and therefore should be avoided. The following sections specify how HIP hosts can prove their identity by performing a challenge-response protocol between the middlebox and the end-hosts. As the challenge, the middlebox adds information (e.g. nonces) to HIP control packets which the end-hosts sign with public-key (PK) their signatures and echo back. The challenge-response mechanism is similar to the ECHO_REQUEST/ ECHO_RESPONSE mechanism employed already by HIP end-hosts. It assumes that the end-hosts exchange at least two HIP packets with each other. The middlebox adds a CHALLENGE_REQUEST parameter to the first HIP control packet. Similar to the ECHO_REQUEST parameter in the original HIP protocol, this parameter contains an opaque data field that must be echoed by its receiver. The receiver echoes the opaque data field in a CHALLENGE_RESPONSE parameter. The CHALLENGE_RESPONSE parameter must be covered by the packet signature, thereby proving that the receiver is in possession of the private key that corresponds to the HI. The middlebox can either verify the identity of the initiator, the responder, or both peers, depending on the purpose of the middlebox. The choice of which authentication is required left to middlebox implementers. 2.1.1. CHALLENGE_REQUEST Middleboxes MAY add CHALLENGE_REQUEST parameters to the R1, I2, 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 Heer, et al. Expires September 1, 2009 [Page 6] Internet-Draft Hip-Middle-Auth February 2009 the size of the variable data field in the CHALLENG_REQUEST parameter. The total length of the packets SHOULD not exceed 1280 bytes to avoid IPv6 fragmentation [RFC2460]. The middleboxes add the CHALLENGE_REQUEST parameter to the unprotected part of a HIP message. Thus it does not corrupt any HMAC or public-key signatures that protect the HIP packet. However, the middlebox MUST recompute the IP- and HIP header checksums as defined in [RFC5201] and the UDP headers of UDP encapsulated HIP packets as defined in [I-D.ietf-hip-nat-traversal]. An end-host that receives a HIP control packet containing one or multiple CHALLENGE_REQUEST parameters must copy the contents of each parameter without modification to an CHALLENGE_RESPONSE parameter. This end-host MUST send this parameter within the signed part of its reply. Note that middleboxes MAY also add ECHO_REQUEST_UNSIGNED parameter as specified in [RFC5201] when the receiver of the parameter does not have to sign the contents of the ECHO_REQUEST. Middleboxes can delay state creation by utilizing the CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters by hiding encrypted or otherwise protected information about previous authentication steps in the opaque data field. 2.1.2. CHALLENGE_RESPONSE When a middlebox injects an opaque blob of data with a CHALLENGE_REQUEST parameter, it expects to receive the same data without modification as part of a CHALLENGE_RESPONSE parameter in a subsequent packet. The opaque data MUST be copied as it is from the corresponding CHALLENGE_REQUEST parameter. In the case of multiple CHALLENGE_REQUEST parameters, their order MUST be preserved by the corresponding CHALLENGE_RESPONSE parameters. The CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters MAY be used for any purpose, in particular when a middlebox has to carry state information in a HIP packet to receive it in the next response packet. The CHALLENGE_RESPONSE MUST be covered by the HIP_SIGNATURE. The CHALLENGE_RESPONSE parameter is non-critical. Depending on its local policy, a middlebox can react differently on a missing CHALLENGE_RESPONSE parameter. Possible actions range from degraded or restricted service, such as bandwidth limitation, up to refusing connections and reporting access violations. Heer, et al. Expires September 1, 2009 [Page 7] Internet-Draft Hip-Middle-Auth February 2009 2.1.3. Middlebox Puzzles As PK operations are costly in terms of CPU cycles, a middlebox has to defend itself against resource-exhaustion attacks when verifying signatures in HIP packets. The HIP base protocol [RFC5201] specifies a puzzle mechanism to protect the Responder from I2 floods that require numerous public-key operations. However, middleboxes cannot utilize this mechanism as there is no defense against a collaborative replay attack, which involves a malicious Initiator and a malicious Responder. This section specifies how middleboxes can utilize the puzzle mechanism to add their own puzzles to R1, I2, and any UPDATE packets. This allows middleboxes to shelter against Denial of Service (DoS) attacks on PK verification. The puzzle mechanism for middleboxes utilizes the CHALLENGE_REQUEST and CHALLENGE_RESPONSE parameters. The CHALLENGE_REQUEST parameter contains fields for setting the difficulty and the expiration date of the puzzle. In contrast to the PUZZLE parameter in the HIP base specifications, there is no dedicated puzzle seed field. Instead, the hash of the opaque data field in the CHALLENGE_REQUEST parameter serves as puzzle seed. The hash is generated by applying the responder's hash algorithm (RHASH) to the opaque data field. The destination end-host of the HIP control packet MUST solve the puzzle and provide the solution in the CHALLENGE_RESPONSE parameter. The middlebox can set the puzzle difficulty by adjusting the K value in the CHALLENGE_REQUEST packet. The semantics of this field equal the semantics of the PUZZLE parameter. Setting K to 0 signifies that no puzzle solution is required. As a puzzle increases the delay and computational cost for establishing or updating a HIP association, a middlebox SHOULD only increase K when it is under attack. Moreover, middleboxes SHOULD distinguish attack directions. If the majority of the CPU load is caused by verifying HIP control messages that arrive from a certain interface, middleboxes MAY increase K for HIP control packets that leave the interface. The middlebox chooses the difficultly of the puzzle according to its load and local policies. 2.2. Identity Verification by Middleboxes This section describes how middleboxes can influence the BEX and the HIP update process in order to verify the identity of the HIP end- hosts. 2.2.1. Identity Verification During BEX Middleboxes MAY add CHALLENGE_REQUEST parameters to R1 and I2 packets in order to verify the identities of the participating end-hosts. Heer, et al. Expires September 1, 2009 [Page 8] Internet-Draft Hip-Middle-Auth February 2009 Middleboxes can choose either to authenticate the Initiator, the Responder, or both. Middleboxes MUST NOT add CHALLENGE_REQUEST parameters to I1 messages because this would expose the Responder to DoS attacks. Thus, middleboxes MUST let unauthenticated and minimal I1 packets traverse. Minimal means that the I1 packet MUST NOT contain more than the minimal set of parameters specified by HIP standards or internet drafts. In particular, the I1 packet MUST NOT contain any attached payload. Figure 1 illustrates the authentication process during the BEX. Middlebox authentication of a HIP base exchange. Main path: Initiator Middlebox Responder .-----------------. I1 | | I1 -----------------> | |----------------------------> | | R1, + CQ1 | Add CQ | R1 <----------------- | |<---------------------------- | | I2, {CR1} | Verify CR1 | I2, {CR1} + CQ2 -----------------> | Add CQ2 |----------------------------> | | | | R2, {CR2} | Verify CR2 | R2, {CR2} <----------------- | |<----------------------------- '-----------------' CQ: Middlebox challenge reQuest CR: Middlebox challenge Response {}: Signature with sender's HI as key Figure 1 2.2.2. Identity Verification During Mobility Updates HIP rekeying, mobility and multihoming UPDATE mechanisms for non- NATted environments are described in [RFC5206]. This section describes how middleboxes process UPDATE messages in non-NATted environments and leave NATted environments for future revisions of the draft. The middleboxes can apply middlebox challenges to mobility related HIP control messages in the case where both end-hosts are single- homed. The middlebox challenges can be applied both ways as the Heer, et al. Expires September 1, 2009 [Page 9] Internet-Draft Hip-Middle-Auth February 2009 UPDATE process consists of three packets (U1, U2, U3) which all traverse through the same middlebox as shown in Figure 2. In cases, in which fewer packets are used for updating an association, the following rule applies. RESPONSE RULE: A HIP host, receiving a CHALLENGE_REQUEST MUST reply with a CHALLENGE_RESPONSE in its next UPDATE packet. If no further UPDATE packets are necessary to complete the update procedure, an additional UPDATE packet containing the CHALLENGE_RESPONSE MUST be sent. Initiator Middlebox Responder .------. U1 | | U1 + CQ1 -----------------------------> | | ---------------------------> | | U2, {CR1} + CQ2 | | U2, {CR1} <----------------------------- |OK | <--------------------------- | | U3, {CR2} | | U3, {CR2} -----------------------------> | OK| ---------------------------> '------' CQ: Middlebox challenge reQuest CR: Middlebox challenge Response {}: Signature with sender's HI as key Middlebox authentication of a HIP mobility update over a single path. Figure 2 Middlebox 1 in Figure 2 can verify the identity of the Responder by checking its PK signature and the presence of the CHALLENGE_RESPONSE in the U2 packet. If necessary, the middlebox MAY add an CHALLENGE_REQUEST for the Initiator of the update. The middlebox can verify the Initiator's identity by verifying its signature and the CHALLENGE_RESPONSE in the U3 packet. 2.2.3. Identity Verification for Multihomed Mobility Updates Multihomed hosts may use multiple communication paths during an HIP mobility update. Depending on whether the middlebox is located on the communication path between the preferred locators of the hosts or not, the middlebox forwards different packets and, thus, needs to interact differently with the updates. Figure 3 I) and II) Heer, et al. Expires September 1, 2009 [Page 10] Internet-Draft Hip-Middle-Auth February 2009 illustrates an update with Middlebox 1 on the path between the Initiator's and the Responder's preferred locators and with Middlebox 2 on an alternative path. Middlebox 2 is not located on the path between the preferred locators of the HIP end-hosts does not receive the U1 message. Therefore, it will not recognize any CHALLENGE_RESPONSE (CR1) in the second UPDATE packet. Thus, if a middlebox encounters non-matching or missing CHALLENGE_RESPONSE parameter in an initial update packet, the middlebox SHOULD ignore it. Complying to the RESPONSE RULE stated in Section Section 2.2.2, the RESPONDER generates an additional fourth update packet on receiving the CHALLENGE_REQUEST. The update process for a middlebox on the preferred communication path (Middlebox 1) and a middlebox off the preferred communication path (Middlebox 2) is depicted in Figure 3. Heer, et al. Expires September 1, 2009 [Page 11] Internet-Draft Hip-Middle-Auth February 2009 I) Main path: Initiator Middlebox 1 Responder .------. U1 | | U1 + CQ1 ----------------------------> | | ---------------------------> | | U2, {CR1} + CQ2 | | U2, {CR1} <---------------------------- |OK | <--------------------------- | | U3, {CR2} | | U3, {CR2} ----------------------------> | OK| ---------------------------> '------' II) Alternative path: Initiator Middlebox 2 Responder U1 (bypasses Middlebox 2) ------------------------------------------------------------------> .------. U2, {CR1} + CQ3 | | U2, {CR1} <---------------------------- | wrong| <--------------------------- | | U3', {CR3} | | U3', {CR3} + CQ4 ----------------------------> |OK | ----------------------------> | | U4, {CR4} | | U4, {CR4} <---------------------------- | OK| <--------------------------- '------' CQ: Middlebox challenge reQuest CR: Middlebox challenge Response {}: Signature with sender's HI as key Middlebox authentication of a HIP mobility update over different paths. Figure 3 2.2.4. Identity Signaling During Updates As middleboxes have to verify rapidly and forward HIP packets, they need to be supplied with all information necessary to do so. If end- hosts hand over communication to a new communication path, middleboxes need to be able to learn their Host Identifiers (HIs) from the UPDATE packets. Therefore, all packets that contain a CHALLENGE_RESPONSE parameter MUST contain the HOST_ID parameter. Heer, et al. Expires September 1, 2009 [Page 12] Internet-Draft Hip-Middle-Auth February 2009 2.2.5. Closing of Connections At the time being, identity verification during the closing of a HIP association is not supported. Hence, the middlebox MUST preserve the state until it expires according to local policies. An appropriate mechanism for middleboxes to verify CLOSE messages by middleboxes will be provided in future versions of this document. 2.3. Failure Signaling Middleboxes SHOULD inform the sender of a BEX packet or update packet if it does not satisfy the requirements of the middlebox. Reasons for non-satisfactory packets are missing HOST_ID or CHALLENGE_RESPONSE parameters. Other reasons may be middlebox policies regarding, for example, insufficient client capabilities or or insufficient credentials delivered in a HIP CERT parameter [I-D.varjonen-hip-cert]. Options for expressing such shortcomings are ICMP packets if no HIP association is established and HIP_NOTIFY packets in case of an already established HIP association. Defining this signaling mechanism is future work. 2.4. Fragmentation Analogously to the specification in [RFC5201], HIP aware middleboxes SHOULD support IP-level fragmentation and reassembly for IPv6 and MUST support IP-level fragmentation and reassembly for IPv4. However, when adding CHALLENGE_REQUEST parameters, a middlebox SHOULD keep the total packet size below 1280 bytes to avoid packet fragmentation in IPv6. 2.5. HIP Parameters This HIP extension specifies four new HIP parameters that allow middleboxes to authenticate HIP end-hosts and to protect against DoS attacks. 2.5.1. CHALLENGE_REQUEST A middlebox MAY append the CHALLENGE_REQUEST parameter to R1, I2, and UPDATE packets. The structure of the CHALLENGE_REQUEST parameter is depicted in the following figure. The semantics of the K and Lifetime fields is identical to the fields defined in the PUZZLE parameter in [RFC5201]. The opaque data field serves as nonce and puzzle seed value. To generate the seed corresponding to the 8-byte value I in [RFC5201], the receiver of the puzzle applies RHASH to the opaque data field and truncates the result to 8-byte length. Note that the opaque data field must provide enough randomness to serve as puzzle seed. Heer, et al. Expires September 1, 2009 [Page 13] Internet-Draft Hip-Middle-Auth February 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Lifetime | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Opaque, (variable length) / / +-+-+-+-+-+-+-+-+-+-| / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65334 Length Variable K K is the number of verified bits Lifetime Challenge lifetime 2^(value-32) seconds Opaque Opaque data that serves as nonce and as basis for the puzzle. The puzzle value I is generated by hashing the opaque data field with the hash function RHASH and truncating it to 8-byte length. Random #I Random number 2.5.2. CHALLENGE_RESPONSE The CHALLENGE_RESPONSE parameter is the response to the CHALLENGE_REQUEST parameter. The receiver of a CHALLENGE_REQUEST parameter SHOULD reply with a CHALLENGE_RESPONSE. Otherwise, the middlebox that added the CHALLENGE_REQUEST parameter MAY decide to degrade or deny its service. The contents of the CHALLENGE_REQUEST parameter must be copied to the CHALLENGE_RESPONSE parameter without any modification. If the puzzle difficulty in the CHALLENGE_REQUEST parameter is set to any other value except 0, an appropriate puzzle solution (adhering to the SOLUTION specifications in [RFC5201]) must be provided in the CHALLENGE_RESPONSE parameter. The CHALLENGE_RESPONSE parameter is non-critical and covered by the SIGNATURE. The structure of the CHALLENGE_RESPONSE parameter is depicted below: Heer, et al. Expires September 1, 2009 [Page 14] Internet-Draft Hip-Middle-Auth February 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Lifetime | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / Puzzle solution #J, 8 bytes / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / Opaque, (variable length) / / +-+-+-+-+-+-+-+-+-+-| / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 322 Length Variable K K is the number of verified bits Opaque Copied unmodified from the received CHALLENGE_REQUEST parameter Puzzle solution Random number 3. Security Services for the HIP Control Channel In this section, we define the adversary model that the security analysis in the later sections will be based on. 3.1. Adversary model and Security Services For discussing the security properties of the proposed HIP extension we first define an attacker model. We assume a Dolev-Yao threat model in which an adversary can eavesdrop on all traffic regardless of its source and destination. The adversary can inject arbitrary packets with any source and destination addresses. Consequently, an adversary can also replay previously eavesdropped messages. However, the adversary cannot subvert the cryptographic ciphers and hash function, nor can it compromise one of the communicating nodes. Even in the face of this strong attacker, the proposed HIP extension enables middleboxes to verify the identity of the communicating HIP peers. It ensures that both peers are involved in the communication and that the HIP BEX or update packets are fresh, i.e. not replayed. Heer, et al. Expires September 1, 2009 [Page 15] Internet-Draft Hip-Middle-Auth February 2009 It enables the middlebox to verify the source and destination (in terms of HIs) of the HIP association and the integrity of RSA and DSA signed HIP packets. 4. Security Services for the HIP Payload Channel The presented extension for HIP authentication by middleboxes only covers the HIP control channel, i.e., the HIP control messages. Depending on the binding between the HIP control and payload channel, certain security properties for the payload channel can be derived from the strong cryptographic authentication of the end-hosts. Assuming that there is a secure binding between packets belonging to a payload stream and the control stream, the same security properties as in Section 3 apply to the payload stream. ESP [RFC5202] is currently the default payload encapsulation format for HIP. A limitation of ESP is that it does not provide a secure binding between the HIP control channel and the ESP traffic on a per- packet basis. Hence, the achievable level of security for the payload channel is lower compared to the HIP control channel. This section discusses security properties of an ESP payload channel bound to a HIP control channel. Depending on the assumed adversary model, certain security services are possible. We briefly describe two application scenarios and how they benefit from the resulting security services. For the payload channel, HIP in combination with the middlebox authentication scheme offers the following security services: Attribute binding: Middleboxes can extract certain payload channel attributes (e.g. locators and SPIs) from the control channel. These attributes can be used to enforce certain restrictions on the payload channel, e.g., to exhibit the same attributes as the control channel. The attributes can either be stated explicitly in the HIP control packets or can be derived from the IP or UDP packets carrying the HIP control messages. Host involvement: Middleboxes can verify whether a certain host is involved in the establishment of a HIP association and, thus, involved in the establishment of the payload channel. Based on these security services we construct two use cases that illustrate the use of HIP authentication by middleboxes: access control and resource allocation as described in the following sections. Heer, et al. Expires September 1, 2009 [Page 16] Internet-Draft Hip-Middle-Auth February 2009 4.1. Access Control Middleboxes can manage resources based on HIs. As an example, let us assume that a middlebox only forwards HIP payload packets after a successful HIP BEX or HIP update. The middlebox uses the parameters in the control channel (specifically IP addresses and SPIs) to filter the payload traffic. The middlebox only forwards traffic from and to specific authenticated hosts and drops other traffic. The feasibility of subverting the function of the middlebox depends on the assumed adversary model. 4.1.1. Adversary model and Security Services If we assume a Dolev-Yao threat model, attribute binding is not helpful to aid packet filtering for access control. An attacker can send packets from any IP address and can read packets destined to any IP address. Without per packet verification by the middlebox, such an attacker can inject arbitrary forged packets into the HIP payload channel and make them traverse the middlebox. The attacker can also read the packets from the HIP payload channel, and hence, communicate across the middlebox. However, the forged packets are disclosed by inconsistencies in the ESP sequence numbers, which makes the attack visible to the middlebox as well as the HIP end hosts. Moreover, attackers can only inject packets into an already established HIP payload channel. Opening a new payload channel and replaying a closing of the channel are not possible. An attacker that is not able to send IP packets from an arbitrary source address and receive IP packets addressed to any destination, cannot use the ESP channel to send fake ESP packets when the middleboxes bind HIs and SPI numbers to addresses. By fixing the set of source and destination IP addresses, the opportunity to successfully inject packets into the payload channel is limited to hosts that can send packets from the same source address as the legitimate HIP hosts. Moreover, an attacker can only receive injected packets if it is on the communication path towards the legitimate HIP peer. Attackers cannot open new HIP payload channels and thus have no influence on the bound payload stream parameters. Finally, attackers cannot close HIP associations of legimitate peers. 4.2. Resource allocation When using HIs to limit the resources (e.g. bandwidth) allocated for a certain host, the HIs can be used to authenticate the hosts in a similar fashion to the access control illustrated above. Regarding authentication, both use cases share the same strengths and weaknesses. However, the implications for the targeted scenarios Heer, et al. Expires September 1, 2009 [Page 17] Internet-Draft Hip-Middle-Auth February 2009 differ. Therefore, we restrict the following discussion to these differences. 4.2.1. Adversary Model and Security Services When assuming an Dolev-Yao threat model, an attacker is able to use resources allocated for the payload channel of another host by injecting packets into this channel. Also, the attacker cannot open a new payload channel with another host nor can it close an existing one. When binding the IP addresses of the HIP payload channel to the IP addresses used in the HIP control channel and assuming an attacker is unable to receive IP packets addressed to the IP address of an authenticated host, the attacker cannot utilize the resources allocated to authenticated host. However, the attacker can still inject packets and waste resources, yet without having any benefit other than causing disturbance to the other host. Specifically, it cannot increase the share of resources allocated to itself. Hence, this measure takes incentive from selfish users that try to benefit by mounting a DoS attack. Defense against purely malicious attackers that aim at creating disturbance without immediate benefit is difficult to achieve and out of scope of this document. 5. Security Considerations This HIP extension specifies how HIP-aware middleboxes interact with the handshake and mobility-signaling of the Host Identity Protocol. The scope is restricted to the authentication of end-hosts and excludes the issue of stronger authentication of ESP traffic at the middlebox. Providing middleboxes with a way of adding puzzles to the HIP control packets may cause both HIP peers, including the Responder, to spend CPU time on solving these puzzles. Thus, it is advised that HIP implementations for servers employ mechanisms to prevent middlebox puzzles from being used as DoS attacks. Under high CPU load, servers can rate limit or assign lower priority to packets containing middlebox puzzles. If multiple middleboxes add CHALLENGE_REQUEST parameters to a HIP control packet, the remaining space in the packet might not be sufficient for further CHALLENGE_REQUEST parameters to be added. Moreover, as the CHALLENGE_REQUEST must be echoed within a CHALLENGE_RESPONSE, the space in the subsequent packet may not be sufficient to include all CHALLENGE_RESPONSE parameters. Thus, middleboxes SHOULD keep the size of the nonces small. Heer, et al. Expires September 1, 2009 [Page 18] Internet-Draft Hip-Middle-Auth February 2009 6. IANA Considerations This document specifies two new HIP parameter types. The preliminary parameter type numbers are 322 and 65334. 7. Acknowledgments Thanks to Shaohui Li, and Janne Lindqvist for the fruitful discussions on this topic. Many thanks to Julien Laganier, Stefan Goetz, Ari Keranen, Samu Varjonen, Rene Hummen, and Kate Harrison for commenting and helping to improve the quality of this document. 8. Normative References [I-D.ietf-hip-nat-traversal] Komu, M., Henderson, T., Matthews, P., Tschofenig, H., and A. Keraenen, "Basic HIP Extensions for Traversal of Network Address Translators", draft-ietf-hip-nat-traversal-05 (work in progress), October 2008. [I-D.irtf-hiprg-nat] Stiemerling, M., "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", draft-irtf-hiprg-nat-04 (work in progress), March 2007. [I-D.varjonen-hip-cert] Heer, T. and S. Varjonen, "HIP Certificates", draft-varjonen-hip-cert-01 (work in progress), July 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008. [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008. Heer, et al. Expires September 1, 2009 [Page 19] Internet-Draft Hip-Middle-Auth February 2009 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. Authors' Addresses Tobias Heer (editor) Distributed Systems Group, RWTH Aachen University Ahornstrasse 55 Aachen 52062 Germany Phone: +49 241 80 214 36 Email: heer@cs.rwth-aachen.de URI: http://ds.cs.rwth-aachen.de/members/heer Klaus Wehrle Distributed Systems Group, RWTH Aachen University Ahornstrasse 55 Aachen 52062 Germany Phone: +49 241 80 214 30 Email: wehrle@cs.rwth-aachen.de URI: http://ds.cs.rwth-aachen.de/members/klaus Miika Komu Helsinki Institute for Information Technology Metsanneidonkuja 4 Espoo Finland Phone: +358503841531 Fax: +35896949768 Email: miika@iki.fi URI: http://www.hiit.fi/ Heer, et al. Expires September 1, 2009 [Page 20]