Host Identity Protocol T. Heer Internet-Draft RWTH Aachen University Intended status: Standards Track February 2007 Expires: August 5, 2007 LHIP Lightweight Authentication Extension for HIP draft-heer-hip-lhip-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it 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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies the Lightweight authentication extension for the Host Identifier Protocol (LHIP). The goal of LHIP is to reduce the computational requirements of the Host Identifier Protocol (HIP), thus, making its benefits, such as end-host mobility and multihoming, accessible to CPU-restricted devices. LHIP reduces the computational Heer Expires August 5, 2007 [Page 1] Internet-Draft Lightweght HIP February 2007 cost of establishing, updating, and closing a HIP association by providing an alternative way of signing and verifying HIP control packets which is based on computationally inexpensive hash function computations and hash chains. However, LHIP does not provide nor does it aim at providing the same level of security as HIP does. Especially, host authentication and payload encryption are not possible. The LHIP extensions in this draft specify also mechanisms for dynamic transitioning between lightweight and full HIP associations on the fly. 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 RFC 2119 [RFC2119] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. LHIP Security . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Cryptographic Techniques used in LHIP . . . . . . . . . . . . 8 3.1. One-Time Signatures . . . . . . . . . . . . . . . . . . . 8 3.2. Hash Chains . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Interactive Hash Chain-Based Signatures . . . . . . . . . 9 4. Lightweight Authentication Extension for HIP . . . . . . . . . 10 4.1. Supported Hash Functions . . . . . . . . . . . . . . . . . 10 4.2. Hash Chain Creation . . . . . . . . . . . . . . . . . . . 10 4.3. IHC-based Signatures in LHIP . . . . . . . . . . . . . . . 11 4.3.1. Initiating the Signature Process . . . . . . . . . . . 12 4.3.2. The First Signature Packet: S1 . . . . . . . . . . . . 13 4.3.3. The First Acknowledgement Packet: A1 . . . . . . . . . 13 4.3.4. The Second Signature Packet: S2 . . . . . . . . . . . 14 4.3.5. The Second Acknowledgement Packet: A2 . . . . . . . . 14 4.3.6. Host Mobility with LHIP . . . . . . . . . . . . . . . 15 4.3.7. Overhead of IHC-based Signatures . . . . . . . . . . . 16 4.4. LHIP Parameters . . . . . . . . . . . . . . . . . . . . . 16 4.4.1. HCA parameter . . . . . . . . . . . . . . . . . . . . 16 4.4.2. HCE Parameter . . . . . . . . . . . . . . . . . . . . 18 4.4.3. PS Parameter . . . . . . . . . . . . . . . . . . . . . 18 4.4.4. PACK, PNACK, HACK, and HNACK Parameters . . . . . . . 19 4.4.5. LFLAGS Parameter . . . . . . . . . . . . . . . . . . . 20 4.5. LHIP Packets . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.1. The S1 Packet . . . . . . . . . . . . . . . . . . . . 21 4.5.2. The A1 Packet . . . . . . . . . . . . . . . . . . . . 21 4.5.3. The S2 Packet . . . . . . . . . . . . . . . . . . . . 22 4.5.4. The A2 Packet . . . . . . . . . . . . . . . . . . . . 22 4.5.5. Source and Destination Addresses . . . . . . . . . . . 22 Heer Expires August 5, 2007 [Page 2] Internet-Draft Lightweght HIP February 2007 4.6. State Machines . . . . . . . . . . . . . . . . . . . . . . 23 4.6.1. Terminology . . . . . . . . . . . . . . . . . . . . . 23 4.6.2. SIGNER State Machine . . . . . . . . . . . . . . . . . 24 4.6.3. VERIFIER State Machine . . . . . . . . . . . . . . . . 26 4.6.4. State Loss . . . . . . . . . . . . . . . . . . . . . . 27 4.7. Predefined Signals . . . . . . . . . . . . . . . . . . . . 28 4.8. Unprotected HIP Control Packets . . . . . . . . . . . . . 28 4.9. LHIP Handshake . . . . . . . . . . . . . . . . . . . . . . 28 4.9.1. LHIP Transform Suites . . . . . . . . . . . . . . . . 29 4.9.2. Hash Chain Anchors . . . . . . . . . . . . . . . . . . 29 4.9.3. Diffie-Hellman Parameters . . . . . . . . . . . . . . 30 4.9.4. ECHO_REQUEST parameter . . . . . . . . . . . . . . . . 30 4.9.5. RSA and DSA Signatures . . . . . . . . . . . . . . . . 30 4.9.6. Authenticated Hash Chain Anchors . . . . . . . . . . . 31 4.9.7. Encrypted Host Identifiers . . . . . . . . . . . . . . 32 4.9.8. Puzzle Mechanism . . . . . . . . . . . . . . . . . . . 32 4.9.9. Basic LHIP Base Exchange Overview . . . . . . . . . . 32 4.9.10. Use of IPsec and Other Payload Transfer Protocols . . 33 4.9.11. Concluding the LHIP Base Exchange . . . . . . . . . . 34 4.10. Chained Bootstrapping . . . . . . . . . . . . . . . . . . 34 4.10.1. Chained Bootstrapping for the INITIATOR . . . . . . . 34 4.10.2. Chained Bootstrapping for the RESPONDER . . . . . . . 34 4.11. Hash Chain Extension . . . . . . . . . . . . . . . . . . . 37 4.12. LHIP Interaction with Middle-boxes . . . . . . . . . . . . 37 4.13. Closing an LHIP Association . . . . . . . . . . . . . . . 38 4.14. Upgrading an LHIP Association . . . . . . . . . . . . . . 38 4.14.1. The First Upgrade Packet . . . . . . . . . . . . . . . 38 4.14.2. The Second Upgrade Packet . . . . . . . . . . . . . . 40 4.14.3. Concurrent Upgrade Initialization . . . . . . . . . . 40 4.14.4. HIP Downgrade . . . . . . . . . . . . . . . . . . . . 40 4.14.5. Upgrade DoS Attack . . . . . . . . . . . . . . . . . . 40 4.14.6. Sequence Numbers . . . . . . . . . . . . . . . . . . . 40 4.15. State Loss . . . . . . . . . . . . . . . . . . . . . . . . 41 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1. Normative References . . . . . . . . . . . . . . . . . . . 43 8.2. Informative References . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 45 Heer Expires August 5, 2007 [Page 3] Internet-Draft Lightweght HIP February 2007 Notation +-----------+-------------------------------------------------------+ | Symbol | Explanation | +-----------+-------------------------------------------------------+ | [x] | indicates that x is optional. | | [x/y] | indicates that either x or y is present. | | x_y | indicates that y is an index of x. | | x_{yz} | indicates that yz is an index of h. | | X(y) | indicates that y is a parameter of X. | | | | signifies concatenation. | | x=?y | signifies a check whether x equals y. | | peer | denotes the remote host the local host is | | | communicating to, using HIP or LHIP. | | MESSAGE | denotes a HIP control packet (I1, R1, UPDATE, etc) | | | which a host intends to transmit to its peer. | | | Transmitting a MESSAGE may require to transmit | | | several packets. | | MSG | is used as shorthand for MESSAGE. | | SIG | is used as shorthand for SIGNATURE. | | SIGNER | denotes the sender of an IHC-signed MESSAGE. | | VERIFIER | denotes the receiver of an IHC-signed MESSAGE. | | INITIATOR | is the host which initiates a HIP or LHIP | | | association. | | RESPONDER | is the host which responds to the INITIATOR. | | --> | signifies "SIGNER to VERIFIER" or "INITIATOR to | | | RESPONDER" communication. | | <-- | signifies "VERIFIER to SIGNER" or "RESPONDER to | | | INITIATOR" communication. | | rcv | is used as shorthand for receive or received. | | snd | is used as shorthand for send or sent. | | ack, nack | are used as shorthands for acknowledgment and | | | negative acknowledgment. | | hybrid | denotes a hybrid host which supports HIP as well as | | | LHIP. | | anchor | denotes the first element of a hash chain (h_n) in | | | reverse order of creation. | | seed | denotes the last element of a hash chain (r) in | | | reverse order of creation. The seed is the random or | | | pseudo-random value from which the hash chain is | | | created. | | HMAC-F | denotes a function which generates an HMAC. The | | | function takes a message as first parameter and a key | | | as second parameter. | +-----------+-------------------------------------------------------+ Heer Expires August 5, 2007 [Page 4] Internet-Draft Lightweght HIP February 2007 1. Introduction The Host Identity Protocol (HIP) [I-D.ietf-hip-base] decouples the transport from the network layer by introducing a new namespace. Using Host Identities (HIs) for addressing hosts allows IP addresses to be pure locators which enables hosts to use several locators or to change their locators without breaking transport-layer connections. This way, HIP provides end-host mobility and multihoming support for a wide range of appliances. HIP uses public-key cryptography to verify the identity of hosts and to generate symmetric keys that are used for data encryption and integrity protection. Despite of the valuable security features which public-key cryptography offers, it also imposes a non-negligible computational cost which complicates the use of HIP on devices with few CPU resources. LHIP puts aside the benefits of data encryption and end-host authentication in favor of a computationally inexpensive way of providing integrity protection for HIP control packets. Thus, allowing CPU-restricted devices to use the mobility and multihoming features of HIP. Therefore, HIP payload from upper protocol layers is neither encrypted nor authenticated and the HIs of hosts are not verified. Nevertheless, it is necessary to provide a way to authenticate HIP control packets, especially the UPDATE packets which allow to modify an established HIP association, in order to allow the HIP protocol to perform secure mobility and multihoming updates. The integrity protection mechanisms which HIP employs to secure HIP control packets rely on public-key cryptography. Hosts use Hash Message Authentication Codes (HMACs) with keys that are generated from an Authenticated Diffie-Hellman (DH) key exchange [DH71]. Moreover, the UPDATE packets must be signed with RSA [RFC3110] or DSA [RFC2536] signatures to allow verification by middle-boxes which are not in possession of the shared secret for the HMAC. In order to reduce HIPs dependency on PK cryptography, LHIP introduces a new way of authenticating HIP control messages which is mainly based on cryptographic hash functions and one-way hash chains. The Interactive Hash Chain (IHC) approach [I-D.ylitalo-multi6-wimp] and one-time signatures [Lam81] provide the basis for this authentication mechanism. The authentication functionality of LHIP is conceptually located below the HIP-layer in order to be transparent to the basic HIP protocol. The task of protecting HIP payload is delegated to LHIP. Therefore, LHIP disables the security mechanisms which protect control packets in HIP. HIP passes unprotected HIP control packets to LHIP which applies lightweight packet authentication if necessary. However, there are packets which can not be protected (payload) and packets which do not not require protection. These packets are sent Heer Expires August 5, 2007 [Page 5] Internet-Draft Lightweght HIP February 2007 unprotected. Figure 1 depicts the location of LHIP in the networking stack. Layering of HIP and LHIP: .-----------------------------------------------. | | | UDP / TCP | | | +-----------------------------------------------+ | | | | HIP / LHIP | Payload | +-----------------------------+ | | LHIP authentication | | | unprotected | protected | unprotected | +-----------------------------+-----------------+ | | | IP | | | +-----------------------------------------------+ Figure 1 LHIP and HIP share the same host identity namespace but LHIP does not authenticate the HIs of hosts except in cases of conflicts and potential attacks (cf. Section 4.9.5). This allows LHIP to reuse the HIP namespace and name resolution mechanisms without performing CPU- intensive PK computations. A host can use the same HI for HIP and LHIP associations depending on whether the additional security features of HIP are required or not. However, using LHIP and HIP for an identical pair of source HI and destination HI at the same time is not possible. Despite the benefits of sharing the same HI namespace, some security issues arise when using the same HIs for LHIP and HIP. Section 4.9.5 discusses these issues and specifies defense mechanisms against potential attacks. The life-cycle of a typical LHIP association is similar to the life- cycle of a HIP association. First, two hosts establish a communication context during the Base EXchange (BEX). Then, they update the association due to locator changes and, finally, they close the association. LHIP modifies all of these steps to reduce the computational cost of each. Moreover, an LHIP host has the option to upgrade an established LHIP association to a full HIP association. Heer Expires August 5, 2007 [Page 6] Internet-Draft Lightweght HIP February 2007 LHIP was explicitly designed to support the basic HIP protocol functions and basic mobility and multihoming. The generic design of LHIP also enables PK-less authentication for many other HIP extensions. However, defining the behavior of LHIP when it used with other HIP extensions is future work. The decision when to use HIP and when to use LHIP should either be based on a set of policies or be taken by the application which initiates or accepts a new HIP association. Applications should use an appropriate API [I-D.komu-btns-api] [I-D.mkomu-hip-native-api] to communicate this decision. The decision when to upgrade an LHIP association should also be expressed via this API. LHIP does not replace but extends HIP. Therefore, this document only focuses on changes and extensions of the basic HIP protocol and its mobility and multihoming extensions [I-D.ietf-hip-mm]. All aspects of HIP which are not mentioned explicitly in this document remain identical to HIP. 2. LHIP Security LHIP does not use the Diffie-Hellman key exchange and, consequently, can not use a shared secret to encrypt or authenticate packets with symmetric encryption algorithms or conventional Hashed Message Authentication Code (HMAC) [RFC2104]. Therefore, only payload transport protocols which do not rely on symmetric keys can be used with LHIP. The LHIP authentication mechanisms do not provide any integrity protection for HIP payload. All authentication mechanisms defined in this document refer to HIP control messages. LHIP does not necessarily verify the identity of hosts as this procedure requires the use of PK signatures. However, host authentication is can be requested either by the INITIATOR or the RESPONDER of an LHIP association during the BEX if necessary. Similar to HIP end-hosts, middle-boxes can only verify the identity of a host when this host uses RSA or DSA signatures during the BEX or during the update process. LHIP can not protect against Man in the Middle (MitM) attacks during the BEX. However, it protects against such attacks after the BEX, especially, during location updates. This is an important feature as mobile devices are likely to be exposed to attackers on the communication path if they change their point of network attachment frequently. The following list summarizes the security properties of LHIP: Heer Expires August 5, 2007 [Page 7] Internet-Draft Lightweght HIP February 2007 Integrity: LHIP allows to verify the integrity of HIP control messages and, therefore, protects these against malicious data manipulation. LHIP payload is unprotected. Authentication of packet origin: LHIP allows to verify that several consecutive HIP control packets relate to the same origin. However the identity of the origin can only be verified if RSA or DSA is used during the LHIP handshake. The origin of LHIP payload can not be determined in any way. Replay protection: LHIP protects HIP control messages from replay attacks. It does not provide replay protection for payload. Confidentiality: LHIP does neither encrypt HIP control packets nor payload. Protection against MitM attacks: LHIP protects against MitM attacks after the BEX. Due to the non-obligatory host authentication and the inability to encrypt payload, it is RECOMMENDED to use LHIP only when the application does not require such security. LHIP can be used when security is employed by other protocols in higher or lower protocol layers. 3. Cryptographic Techniques used in LHIP This chapter introduces the necessary terms and principles which relate to message authentication for LHIP. 3.1. One-Time Signatures Lamport proposed one-time signatures based on hash functions [Lam81]. A host uses two sufficiently large random or pseudo-random numbers r_1 and r_2, applies a pre-image-resistant cryptographic one-way hash function H to both, and keeps them secret. It publishes H(r_1) and H(r_2) as public key. The host signs a one-bit message by either disclosing r_1 as signature S when the value of the bit is 1. Otherwise, it discloses r_2. A receiver can verify the authenticity of the single bit by comparing the hash of the signature H(S) to the public key values H(r_1) and H(r_2). 3.2. Hash Chains A host uses chains of hashes to create a sequence of related hash values [Lam81]. The host uses such hash chains to tie together several signatures, allowing the host to relate all signatures to one Heer Expires August 5, 2007 [Page 8] Internet-Draft Lightweght HIP February 2007 sender without repeatedly exchanging public-key hashes. Iterative application of the hash function to a random or pseudo-random number forms a sequence of values hc = {h_1 = H(r), h_2 = H(h_1) = H(H(r)), ... , Hn = H(h_n-1)}. The host discloses the elements of the hash chain in reverse order of their creation beginning with h_n. This sequence hc has three properties which are useful for LHIP: i) Given h_{i-1} and h_i, it is easy to verify that h_{i-1} belongs to the same hash chain as h_i by verifying that H(h_{i-1}) equals h_i. ii) It is computationally hard to find h_{i-1} if only h_i is given. iii) Given h_{i+1}, it is hard to find an h_i' with H(h_i') = h_{i+1}. The first element of the hash chain in reverse order of creation (h_i) is denoted hash chain anchor. The last element of the hash chain in reverse order of creation (r) is denoted as the seed of the hash chain. 3.3. Interactive Hash Chain-Based Signatures HMAC provides a computationally inexpensive way to verify the integrity of a packet. However, HMAC requires a shared secret (a symmetric key) to be exchanged beforehand. Several communication protocols (e.g. TESLA[RFC4082] and WIMP[I-D.ylitalo-multi6-wimp]) circumvent this restriction by using elements of hash chains as key for the HMAC signature. The basic idea behind hash chain based packet authentication is to use HMACs with temporary secrets instead of shared secrets. A SIGNER of a message sign the message with an HMAC which uses secret value, only known to the SIGNER, as key. In the absence of an encrypted channel to the VERIFIER, the SIGNER must transmit the message, the signature, and the HMAC key in cleartext to the receiver in order to allow it to verify the signature. Attackers cannot change the message unnoticeably because hosts accept messages only if the signature has been created before the key was disclosed. This ensures that only the host in possession of the secret was able to sign the message before it was disclosed. Using hash chains as source for the keys, allows to relate several consequent signatures to the owner of a hash chain. Temporally separating the time of signing and transmitting the message from the time of disclosing and transmitting the secret key is crucial for the security of hash chain based signatures. WIMP uses an interactive approach to guarantee this separation. Hosts Heer Expires August 5, 2007 [Page 9] Internet-Draft Lightweght HIP February 2007 must acknowledge the receipt of a signature before the secret key is disclosed. WIMP uses elements of hash chains to prevent attackers from sending forged acknowledgments. Every host adds an element of its hash chain h_i to the acknowledgment to allow the SIGNER to verify the origin of the acknowledgment. The SIGNER can verify the origin of the hash chain element by comparing H(h_i) to the most recently disclosed element of the VERIFIER's hash chain h_{i+1} : H(h_i)=?h_{i+1}. It only discloses the secret key (the next element of its own hash chain) if this test succeeds. 4. Lightweight Authentication Extension for HIP LHIP modifies the way in which HIP authenticates messages but leaves most of the other functionality of HIP untouched. This way, other HIP extensions can use LHIP transparently. The LHIP authentication protocol is conceptually located below HIP and above the network layer. LHIP acts as output and input filter for HIP control packets and processes these whenever they arrive or are about to be sent. LHIP uses two mechanisms to protect HIP control mechanisms. The first of these mechanisms is based on IHC signatures and can be used to sign and verify arbitrary content. The second mechanism is based on one-time signatures and can be used to trigger predefined processes. The following section specifies these mechanisms. The following sections define the LHIP authentication mechanism before the setup of an LHIP association is discussed. Note that this order does not reflect the chronological order of the processes in the LHIP protocol as the LHIP association must be established before LHIP can authenticate HIP control packets. 4.1. Supported Hash Functions LHIP hosts MUST support SHA-1 [RFC3174] for hash chain creation and verification. 4.2. Hash Chain Creation In order to create a hash chain, a host must pick a random or pseudo- random number with the size of the hash function in use. The host stores this number as first element of the hash chain (r). It applies the selected hash function to it and stores the result as second element of the hash chain (h_1). It repeats this process by always using the recently generated hash chain element as input of the hash function until it has stored a sufficient number of elements Heer Expires August 5, 2007 [Page 10] Internet-Draft Lightweght HIP February 2007 (n). It discloses the elements of the hash chain in reverse order of creation, beginning with h_n which it publishes as anchor value. It MUST NOT disclose parts of the hash chain before all previous elements (in reverse order of creation) have been disclosed. 4.3. IHC-based Signatures in LHIP This section gives an overview how LHIP authenticates HIP control messages. The authentication process is based on the IHC signature approach. It is only used to protect HIP control messages, such as UPDATE messages, that are exchanged after the HIP and LHIP Base EXchange (BEX) is completed. The following explanations assume that the SIGNER and the VERIFIER of a MESSAGE have already established the LHIP association successfully. Especially the anchor values of the hash chains in use must be exchanged during the BEX. Moreover, the hash function which is used for generating and verifying the hash chains is negotiated during the BEX. When an LHIP host is about to send a HIP control message, it initiates the IHC-based signature process. The transmission of this HIP MESSAGE with IHC-based protection requires to exchange four packets. Two packets precede the HIP control message. These packets are used to deliver the signature and to acknowledge its receipt. Then the HIP control message (e.g. an UPDATE packet) is sent. LHIP attaches additional parameters to this control message to allow IHC- based authentication. The fourth packet delivers an acknowledgment or negative acknowledgment of the successful verification of the MESSAGE. As four packets are used for securing one single MESSAGE, this document differentiates between packets which are sent within the IHC-based signature process and the MESSAGE which is protected by these packets. Each LHIP host uses two distinct IHC-signature related hash chains for every LHIP association: one for signing MESSAGES and one for receiving and acknowledging packets of the IHC-based signature process. The hash chain which is used when the host acts as SIGNER is denoted SIGNATURE_CHAIN and the hash chain which is used when the host acts as VERIFIER is denoted TRIGGER_CHAIN. The hosts exchange the anchors of SIGNATURE_CHAIN and TRIGGER_CHAIN during the BEX. In the following description, the anchor of the SIGNER's SIGNATURE_CHAIN is denoted hs_i and the anchor of the VERIFIER's TRIGGER_CHAIN is denoted ht_i. These anchors have been exchanged previously. A schematic overview of the signature process is depicted in Figure 2. It is followed by a description of the packets and mechanisms involved in the signature process. Heer Expires August 5, 2007 [Page 11] Internet-Draft Lightweght HIP February 2007 The modified IHC signature process as used by LHIP: SIGNER VERIFIER S1: hs_{i-1}, PRE_SIG --------------------------> H(hs_{i-1})?=hs_i: Buffer PRE_SIG A1: ht_i, PACK, PNACK <-------------------------- H(ht_{i-1})=?ht_i: Buffer PACK, PNACK S2: hs_{i-2}, MESSAGE (i.e. UPDATE) --------------------------> HMAC-F(MESSAGE, hs_{i-2})=? PRE_SIG A2: ht_{i-2}, [secret_ack/ secret_nack] <-------------------------- HMAC-F("__[n]ack[_]__"| secret_[n]ack, ht_{i-2})=?[PACK/PNACK] ... further signature processes.... S1: hs_{i-3}, PRE_SIG --------------------------> . . . . . . Figure 2 4.3.1. Initiating the Signature Process The signature process begins when an LHIP host is about to transmit a protected MESSAGE (HIP control message) to its peer. The host which intends to send the MESSAGE acts as SIGNER and the host which receives the MESSAGE acts as VERIFIER. The SIGNER can only send MESSAGES one by one. Therefore, it must enqueue and delay concurrent Heer Expires August 5, 2007 [Page 12] Internet-Draft Lightweght HIP February 2007 MESSAGES. 4.3.2. The First Signature Packet: S1 The first (S1) of the four signature packets contains a unused clear- text element from the SIGNER's SIGNATURE_CHAIN (hs_{i-1}) which allows the VERIFIER to verify the origin of the packet. It also contains the signature of the MESSAGE which the SIGNER wants to transmit. The signature is denoted pre-signature (PRE_SIG) because the S1 packet does not contain the actual MESSAGE to which the signature belongs to. The pre-signature is created with the HMAC algorithm for which the next element of the SIGNER's SIGNATURE_CHAIN is used as key. Due to the ambiguity of the term HMAC in HIP (HMAC algorithm/function and HMAC parameter) the term HMAC-F is used when referring to the algorithm. (PRE_SIG = HMAC-F(MESSAGE, hs_{i-2}) ). The VERIFIER must verify that the packet was sent by the SIGNER by comparing the hash of the clear-text hash chain element hs_{i-1} to the anchor of the SIGNER's signature chain ( H(hs_{i-1})=?hs_i ). It can not verify the MESSAGE at this point as it neither knows the MESSAGE nor the key for the HMAC signature. Therefore, it stores the PRE_SIG until the MESSAGE and the key are transmitted. The VERIFIER must not accept any further packets containing hs_{i-1} and, most importantly, MUST NOT buffer further PRE_SIGs after it has sent the A1 packet. 4.3.3. The First Acknowledgement Packet: A1 The receiver sends an acknowledgment packet (A1) to the SIGNER to acknowledge the receipt of the S1 packet. It attaches the next undisclosed element of its TRIGGER_CHAIN ht_{i-1} to the packet as proof that it has received the S1 packet. LHIP provides an acknowledged MESSAGE delivery service which means that the SIGNER gets a signed acknowledgment if the verification was successful and a signed negative acknowledgment if the verification has failed. LHIP piggy-backs these signed acks and nacks on the IHC- signature packets to reduce the overhead for these. Therefore, the VERIFIER attaches a pre-signature of the ack and the nack to the A1 message. As the outcome of the verification is unclear, when sending the A2, it must attach both pre-signatures (for an ack and nack) to the A1 packet. The pre-signature of the acknowledgment is denoted PACK and the pre-signature of the negative acknowledgment is denoted PNACK. They are computed as follows: PACK = HMAC-F("__ack___" | secret_ack , ht_{i-2}) PNACK = HMAC-F("__nack__" | secret_nack, ht_{i-2}) Heer Expires August 5, 2007 [Page 13] Internet-Draft Lightweght HIP February 2007 The message strings for the PACK and PNACK consist simple ASCII strings concatenated with pseudo-random numbers (secret_ack and secret_nack). The pseudo-random numbers prevent that the message text can be guessed and that a acknowledgment or negative acknowledgment can be forged. On receipt of the A1 packet, the SIGNER MUST check that the clear- text hash chain element in the A1 packet belongs to the VERIFIER's TRIGGER chain by computing H(hs_{i-1})=?hs_i. A successful check indicates that the VERIFIER has received the S1 packet and that the SIGNER can send the MESSAGE and the key of the pre-signature now. The SIGNER MUST buffer the PACK and the PNACK value from the A1 packet. It MUST not accept any further PACK or PNACK values before receiving the S2 packet. 4.3.4. The Second Signature Packet: S2 The SIGNER sends the MESSAGE and the next undisclosed elements of its hash chain hs_{i-2} to the VERIFIER in the second signature packet (S2). This is the hash chain element which was used to create the PRE_SIG value. After receiving the S2 packet, the VERIFIER verifies that the packet was sent by the SIGNER. It does so by computing H(hs_{i-2})=?hs_{i-1}. If the test succeeds, it verifies the integrity of the MESSAGE by computing PRE_SIG=?HMAC-F(MESSAGE, hs_{i-2}). The signature is valid if this test succeeds. The authentication protocol delivers the MESSAGE (the HIP control message, such as an UPDATE) to the appropriate HIP protocol functions in case of an successful verification. 4.3.5. The Second Acknowledgement Packet: A2 The A2 packet from the VERIFIER to the SIGNER contains the next element of the VERIFIER's TRIGGER_CHAIN ht_{i-2} and the secret_ack if the verification of the signature was successful. The packet contains secret_nack if the signature was invalid. The SIGNER determines whether the signature process was successful after receiving the A2 packet. It verifies that the VERIFIER has sent the A2 packet and compares the secret_ack or secret_nack to the PACK or PNACK by computing PACK=?HMAC-F("__ack___" | secret_ack , ht_{i-2}) or PNACK=?HMAC-F("__nack__" | secret_nack , ht_{i-2}), respectively. The acknowledgment or negative acknowledgment is valid when this test succeeds. Heer Expires August 5, 2007 [Page 14] Internet-Draft Lightweght HIP February 2007 4.3.6. Host Mobility with LHIP This section gives a short example how LHIP protects the message exchange during an HIP location update. In our example, this basic location update consists of three UPDATE MESSAGES. The mobile host transmits a set of new locators in the first UPDATE MESSAGE. The stationary host acknowledges this set of new locators and sends an ECHO_REQUEST in the second UPDATE MESSAGE. The mobile host replies the ECHO_RESPONSE in the third UPDATE MESSAGE. The first and the second update MESSAGES are protected by IHC-based signatures while the third UPDATE MESSAGE is unprotected. The decision to leave this MESSAGE unprotected is based upon the fact that modifications to this packet can not go unnoticed even without signatures. The reason for this is that the packet carries only an ECHO_RESPONSE in order to verify a locator. Figure 3 shows the whole process in a simplified way. The protected HIP UPDATE MESSAGES are marked with an (x). HIP update with LHIP: MOBILE HOST STATIONARY HOST S1 (PRE_SIG of the 1st UPDATE packet) ------------------------------------> A1 (Acknowledgment) <------------------------------------- S2 (1st UPDATE MESSAGE) -------------------------------------> (x) A2 (NACK or ACK) * <------------------------------------- S1 (PRE_SIG of the 2nd UPDATE packet) * <------------------------------------- A1 (Acknowledgment) -------------------------------------> S2 (2nd UPDATE MESSAGE) <------------------------------------- (x) A2 (NACK or ACK) * -------------------------------------> 3rd UPDATE packet (unprotected) * -------------------------------------> (x) Figure 3 Heer Expires August 5, 2007 [Page 15] Internet-Draft Lightweght HIP February 2007 Notice that packets marked with an asterisk are sent in parallel, thus, reducing the transmission delay from 4.5 RTTs to 3.5 RTTs. 4.3.7. Overhead of IHC-based Signatures The four IHC signature packets replace a single conventional RSA, DSA, or HMAC signed packet from the SIGNER to the VERIFIER. This results in an additional delay of 1.5 Round-Trip Times (RTTs) per MESSAGE compared to HIP. However, depending on the computational cost of generating the conventional signature, and the processing speed of the LHIP device, this signature scheme can still be advantageous because of its low computational cost. Another advantage of LHIP is that Middle-boxes can verify the signatures without being in possession of a shared secret, which is required for HMAC based signatures. This allows middle-boxes to verify the contents of HIP packets without using PK cryptography. 4.4. LHIP Parameters LHIP control packets are identical to HIP control packets with the exception that HMAC parameters are calculated with a key of all zeroes instead of the DH-generated shared secret. Therefore, the HMAC parameter contained in LHIP packets is just a message digest. LHIP uses this message digest as basis for the IHC-based signature. It protects only the HMAC parameter with IHC-based signatures, thus, protecting exactly the same fields of the HIP control packets that are protected by the HMAC parameter. Reusing the HMAC parameter in this way ensures that the semantics of the HMAC parameter remain compatible with HIP. Furthermore, no DSA or RSA signatures are applied which means that the corresponding HIP parameters are missing. LHIP adds several other parameters to HIP control packets which allow IHC-based authentication. 4.4.1. HCA parameter LHIP defines several types of hash chain anchors which are transmitted as Hash Chain Anchor (HCA) parameter in BEX or IHC-signed UPDATE packets. A signed HIP control packet MAY contain several HCA parameters. Unsigned HIP control packets MUST NOT contain any HCA parameters. The different types of anchors are identified by an 8-bit type field. A packet MUST NOT contain several HCA parameters with the same type ID. The VERIFIER MUST ignore such duplicate HCA parameters. Depending on the purpose of the hash chains that belong to the anchors, these hash chains should differ in length. In the context of hash chains, length refers the number of elements in a hash chain. The SIGNATURE_CHAIN and the TRIGGER_CHAIN are used for IHC-based Heer Expires August 5, 2007 [Page 16] Internet-Draft Lightweght HIP February 2007 signatures. Each signature uses at least two hash chain elements. Therefore, the hash chain MUST at least consist of three elements, including the published anchor element to allow one successful signature. It is RECOMMENDED to use larger number of elements to allow a larger number of updates before the hash chains are depleted. The CLOSE_CHAIN and the UPGRADE_CHAIN are used to secure predefined signals (cf. Section 4.13 and Section 4.14). These two signals are only invoked once. Therefore, a hash chain length of two elements is sufficient. Other predefined signals, which may be defined by other HIP extensions in the future, may be invoked more often and would, therefore, require longer hash chains. An overview of the currently defined hash chain types is given below. +-----------------+---------+--------------------------+------------+ | Hash Chain | Type ID | Predefined Signal | Length | +-----------------+---------+--------------------------+------------+ | SIGNATURE_CHAIN | 1 | - | 1 + 2 x S* | | TRIGGER_CHAIN | 2 | - | 1 + 2 x S* | | CLOSE_CHAIN | 3 | Close LHIP association | 2 | | UPGRADE_CHAIN | 4 | Upgrade from LHIP to HIP | 2 | +-----------------+---------+--------------------------+------------+ Hash chain attributes. *S means the number of expected signature processes (positive value). The structure of the HCA parameter is depicted below. 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Anchor Type | | +-+-+-+-+-+-+-+-+ Hash Value / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 222 Length 21 for SHA-1 Anchor Type Type ID of the corresponding hash chain Hash Value The first element of the corresponding hash chain in reverse order of creation (h_n). Heer Expires August 5, 2007 [Page 17] Internet-Draft Lightweght HIP February 2007 4.4.2. HCE Parameter The Hash Chain Element parameter (HCE) contains the recently released element of the corresponding hash chain. HCE parameters are used during the IHC-based signature process or to protect predefined signals. When belonging to an IHC-based signature process, HCE parameters from the SIGNER MUST contain elements of the SIGNER's SIGNATURE_CHAIN and HCE parameters from the VERIFIER MUST contain elements of the VERIFIER's TRIGGER_CHAIN. The length of the Hash Chain Element field is determined by the hash function which negotiated during the LHIP BEX (cf. Section 4.9). The structure of the HCE parameter is depicted below. 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chain Type | | +---------------' Hash Chain Element / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64702 Length 21 for SHA-1 Chain Type The ID of the corresponding hash chain to distinguish several HCE parameters which are assigned to different predefined signals or signature processes. Hash Chain Element An element of the corresponding hash chain. 4.4.3. PS Parameter The Pre-Signature (PS) parameter carries the pre-signature in the A1 packet. The pre-signature is an Hashed Message Authentication Code of the HMAC parameter contained in the HIP control packet. Note that the HMAC parameter in the HIP packet is generated by using a key of zeroes when using LHIP. Therefore, the HMAC does not protect the packet but provides a message digest which covers the packet. The pre-signature HMAC is generated from this digest with the next undisclosed hash chain element as key. The pre-signature is computed as follows: HMAC-F(HMAC,h_{i-1}). Heer Expires August 5, 2007 [Page 18] Internet-Draft Lightweght HIP February 2007 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Pre-Signature / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64704 Length 20 for SHA-1 Pre-Signature The pre-signature used in the IHC-based signature process. 4.4.4. PACK, PNACK, HACK, and HNACK Parameters The Pre-ACKnowledgment parameter (PACK) and the Pre-Negative- ACKnowledgment Parameter (PNACK) are used to transmit the PACK and PNACK values from the VERIFIER to the SIGNER in the A2 packet. The hash-based acknowledgment (HACK) and the corresponding negative acknowledgment (HNACK) contain the secret that was used to create the PACK or PNACK value, respectively. The size of the secret must equal the output size of the hash function in use. The PACK, PNACK, HACK, and HNACK MUST be calculated according to the description in Section 4.3.3. All four parameters have the same structure. They consist of the HIP parameter header and a byte field containing the corresponding values. Heer Expires August 5, 2007 [Page 19] Internet-Draft Lightweght HIP February 2007 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / [PACK/PNACK/secret_ack/secret_nack] / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64725 for PACK 64727 for PNACK 64729 for HACK 64731 for HNACK Length 20 for SHA-1 [PACK value/ PNACK value/ secret_ack/ secret_nack] The PACK, PNACK, secret_ack, or secret_nack value 4.4.5. LFLAGS Parameter The LHIP-flags parameter allows hosts to transmit additional information about an LHIP association to their peers. The LFLAGS parameter is transmitted in the R1 and the I2 packet of the LHIP BEX. It consists of the HIP parameter header and an 32-bit field. The 32- bit field MUST be in network byte order. Setting the corresponding bit to 1 indicates that the host sends the information defined below. +---------------------+-----+---------+-----------------------------+ | Flag | Bit | Integer | Meaning | +---------------------+-----+---------+-----------------------------+ | LFLAG_REQUIRE_AUTH | 0 | 1 | Peer must authenticate | | LFLAG_OFFER_AUTH | 1 | 2 | Host is willing to | | | | | authenticate | | LFLAG_OFFER_UPGRADE | 2 | 4 | Host is willing to upgrade | +---------------------+-----+---------+-----------------------------+ The structure of the LFLAGS parameter is depicted below. Heer Expires August 5, 2007 [Page 20] Internet-Draft Lightweght HIP February 2007 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 63404 Length 4 Flags A bit-mask as defined above. 4.5. LHIP Packets LHIP uses several additional HIP control packet types which are used to transmit the S1, A1, and A2 packet of the IHC-based signature process. The Type of the S2 packet is determined by the type of the HIP control message which is protected by the IHC-based signatures. LHIP hosts MUST implement the S1, A1, and A2 packets. The packets are defined as follows. 4.5.1. The S1 Packet The transmission of the S1 packet is triggered by a transmission request from the basic HIP protocol. The LHIP protocol queues and delays this transmission and prepares a new S1 packet. This packet consists of the HIP packet header, the next hash chain element of the SIGNER encoded an HCE parameter, and the pre-signature of the queued original MESSAGE encoded as PS parameter. Header: Packet Type = 22 (preliminary) SRC HIT = SIGNER's HIT DST HIT = VERIFIER's HIT IP ( HIP ( HCE, PS ) ) Valid control bits: none 4.5.2. The A1 Packet The A1 packet is only sent as direct response to an S1 packet from the SIGNER. It contains the HIP packet header, the next element of the VERIFIER's trigger-chain encoded as HCE parameter, and a PACK and a NACK parameter. Heer Expires August 5, 2007 [Page 21] Internet-Draft Lightweght HIP February 2007 Header: Packet Type = 23 (preliminary) SRC HIT = VERIFIER's HIT DST HIT = SIGNER's HIT IP ( HIP ( HCE, PACK, PNACK ) ) Valid control bits: none 4.5.3. The S2 Packet The second signature packet S2 is the queued MESSAGE which was originally sent by the basic HIP protocol. LHIP attaches an HCE parameter which contains the next undisclosed hash chain element from the SIGNER's signature-chain. This HCE parameter allows the VERIFIER to a) determine that the packet was sent by the SIGNER and b) to verify the pre-signature sent in the S1 packet. There is no special packet type for the S2 packet as the LHIP parameters are piggy-backed on the original MESSAGE sent by the basic HIP protocol. The presence of a valid HCE parameter is sufficient for the VERIFIER to identify the packet as S2 packet. 4.5.4. The A2 Packet The VERIFIER sends the A2 packet only as a direct response to the S2 packet. It contains the next element of the VERIFIER's hash chain encoded as HCE parameter and an HACK or HNACK parameter depending on whether the signed HIP MESSAGE was verified successfully or not. Header: Packet Type = 24 (preliminary) SRC HIT = VERIFIER's HIT DST HIT = SIGNER's HIT IP ( HIP ( HCE, [HACK/HNACK] ) ) Valid control bits: none 4.5.5. Source and Destination Addresses The correct choice of source and destination addresses in the IP headers of the S1 and A1 packets is important because these packets precede the actual HIP control message. The control message can be part of an update process due to a change in a host's locator set. The source and destination address of the S1 packet MUST be the same as the source and destination address of the queued HIP control message from the basic HIP protocol. The destination address of the A1 packet MUST be set to the source address of the corresponding S1 Heer Expires August 5, 2007 [Page 22] Internet-Draft Lightweght HIP February 2007 packet regardless of the preferred address and regardless of the previously announced set of locators of the SIGNER. The source address of the A1 packet MUST be the address of the VERIFIER's interface on which the S1 packet was received. 4.6. State Machines Temporally separating the transmission of the first and the third signature packet is crucial for the security of the IHC-signature scheme. The following section provides two state machines. They ensure temporal separation and handling of duplicate transmissions, undeliverable packets, and packet loss. These state machines focus on the LHIP packet signature and verification process only. They do not replace any existing HIP state machine but take over the process of sending an authenticated MESSAGE. The state machines define the behavior of the SIGNER and the VERIFIER of an IHC-signed MESSAGE. Note that both LHIP peers MUST implement both state machines. Each host can act as SIGNER of an IHC-signed MESSAGE and as VERIFIER of another IHC-signed MESSAGE at the same time. Moreover, each host holds separate state information for every LHIP association which enables the host to process several IHC-signed MESSAGES from or to different hosts simultaneously. 4.6.1. Terminology Depending on whether an element in an HCE parameter belongs to the peer's corresponding hash chain or not, and depending on when it was disclosed, a host classifies LHIP authentication packets into three classes: Valid: A packet is valid when it contains a HCE parameter with the predecessor element of the most recently disclosed hash chain element of the same hash chain. When, for instance, h_i is the last hash chain element disclosed by a host, only the value h_{i-1}, which fulfills the equation H(h_{i-1}) = h_i, is considered to be valid. Old: A packet is old when the hash chain element in the HCE parameter equals to the most recently disclosed hash chain element of the corresponding hash chain. Assuming that h_i is the last hash chain element disclosed by a host, further packets with h_i in the HCE parameter are considered to be old. Invalid: A packet is invalid when it is neither old nor valid. LHIP hosts MUST drop packets with invalid HCE parameters. Packets with old HCE parameters indicate duplicate transmissions or packet loss and must be handled according to the state machines specified Heer Expires August 5, 2007 [Page 23] Internet-Draft Lightweght HIP February 2007 below. 4.6.2. SIGNER State Machine The SIGNER state machine consists of three states. Figure 4 depicts the SIGNER's state machine with conditions for the state transitions and the corresponding actions. In the case of packet loss, retransmissions are always initiated by the SIGNER to avoid the possibility of traffic amplification for DoS attacks. +---------------+---------------------------------------------------+ | State | Explanation | +---------------+---------------------------------------------------+ | INITIAL/READY | State machine start, ready for new IHC signature | | | process. Waiting for HIP control packet to be | | | sent. | | S1-SENT | Waiting for valid A1 | | S2-SENT | Waiting for valid A2 | +---------------+---------------------------------------------------+ Heer Expires August 5, 2007 [Page 24] Internet-Draft Lightweght HIP February 2007 LHIP SIGNER IHC-based signature state machine : Rcv A1: drop A1; Rcv A2: drop A2 .-----. | | | V .---------. (1) Send event: .---------. Timeout: | | buffer HIP MSG, | |<-. resend S1; | INITIAL | snd S1* | S1- | | Rcv A2: -->| /READY |---------------------->| SENT | | drop A2 | | | |--' Rcv valid A1, '---------' '---------' cancel process: ^ ^ | snd new S1 (x) rcv valid A2| | | ACK: | (2) Rcv valid A2 NACK: | | Rcv valid A1: no action | resend S1* | | snd S2*, | | | store PACK and PNACK | .---------. | | | | |---------' | | | S2- | | '--------| SENT | | | |<-----------' '---------' | ^ | | '-----' Timeout: resend S2; Rcv A1: drop A1 Figure 4 State transitions that require the use a new hash chain element from the SIGNER's SIGNATURE_CHAIN are marked with an asterisk. The send event (marked with (1)) is triggered when HIP hands an outgoing HIP control packet (e.g. an UPDATE packet) to LHIP at the SIGNER. This packet is queued and delayed until it is sent as S2 packet. The retransmission of the S1 packet after a NACK (2) requires that the SIGNER calculates a new pre-signature with an undisclosed hash chain element from its SIGNATURE_CHAIN. The SIGNER MUST queue all outgoing messages from the HIP base protocol when these messages arrive while the queue is non-empty or Heer Expires August 5, 2007 [Page 25] Internet-Draft Lightweght HIP February 2007 when the SIGNER's state machine is not in state READY. The SIGNER can handle one message in the queue at a time. The SIGNER removes a message from the queue after receiving a valid A2 packet that contains a valid HACK parameter. The SIGNER MAY repeat the signature process if the VERIFIER sends a HNACK parameter in the A2 packet. However, it SHOULD limit the number of retries to avoid the depletion of its hash chain. Consecutive signature failures indicate an attack because packets with transmission errors are already detected by the checksums in the IP header with high probability. Multi-homed hosts can try to use alternative communication paths to circumvent an attacker. The SIGNER uses timeouts to determine when a packet was lost on the way to or from the VERIFIER. It resends the previously sent packet without using a new hash chain element in such a case. The SIGNER SHOULD abort the signature process if consecutive retransmissions fail due to timeouts. It deletes the queued message belonging to the IHC-based signature process from the queue and sends a new S1 packet for the next message in the queue. In this case, the SIGNER MUST repeat the signature process for the packet without considering this failed signature as an attack if the VERIFIER sends an HNACK in the A2 packet. The LHIP IHC-signature protocol allows the SIGNER to gracefully abort a signature process after receiving an A1 packet by sending a new S1 packet, thus, initiating a new signature process for the next queued HIP control message. This mechanism delivers important packets with higher priority. The corresponding conditions and state transitions are marked with an (x) in both state machine diagrams. 4.6.3. VERIFIER State Machine The VERIFIER state machine starts in the ready state, in which it waits for the first S1 packet to arrive from the SIGNER. The SIGNER sends the A1 packet and transitions to state A1-SENT. After completing an IHC-based signature process by sending an acknowledgment or negative acknowledgment, the VERIFIER state machine transitions to state A2-SENT in which it waits until a new IHC-based signature process is initiated by a valid S1 packet. The VERIFIER's state machine is depicted in Figure 5. +---------------+---------------------------------------------------+ | State | Explanation | +---------------+---------------------------------------------------+ | INITIAL/READY | State machine start, waiting for valid S1 | | A1-SENT | Waiting for valid S2 | Heer Expires August 5, 2007 [Page 26] Internet-Draft Lightweght HIP February 2007 | A2-SENT | IHC-signature process completed, Waiting for | | | valid S1 | +---------------+---------------------------------------------------+ LHIP VERIFIER IHC-based signature state machine : Rcv S2: drop S2 .-----. | V Rcv old S1: .---------. Rcv valid S1: .---------. resend A1; | | snd A1*, | |<-. Rcv valid S1: | INITIAL | store S1 | A1- | | snd new A1*; (x) -->| READY |-------------->| SENT | | Rcv S2: drop S2 | | | |--' '---------' '--------- ^ | | | (1) Rcv valid S1: | | Rcv valid S2, signature valid: snd A1*, | | snd A2 with HACK*, deliver MSG; store S1 | | Rcv valid S2, signature invalid: | | snd A2 with HNACK* | | | V .---------. Rcv old S2: .->| | resend A2; | | A2- | Rcv valid S2: | | SENT | drop S2; '--| | '---------' Figure 5 The transitions marked with an asterisk require the VERIFIER to use a new hash chain element from its TRIGGER_CHAIN. The VERIFIER sends the secret_ack encoded as HACK parameter in the A2 packet when the signature of the MESSAGE is valid (1). The LHIP authentication process delivers the packet to the HIP only when the signature is valid. Otherwise, it MUST drop the message and send the secret_nack encoded as HNACK parameter to the SIGNER. 4.6.4. State Loss Recovery from state loss during the authentication process is not supported as the LHIP association, including all necessary hash chains, would be lost as well. Recovery from state loss for the whole LHIP association is handled in Section 4.15. Heer Expires August 5, 2007 [Page 27] Internet-Draft Lightweght HIP February 2007 4.7. Predefined Signals Messages containing only one bit to be protected (e.g. the signaling for triggering a predefined action), can be invoked by using one-way signatures. LHIP uses binary hash chains which consist only of two elements -- a pseudo-random number r and the hash of r, h_1 = H(r) -- for this purpose. The h_1 is exchanged beforehand as anchor value. It is bound to a specific action. A local host can trigger this action by disclosing r. Its peer can verify if the host has requested the specific action by verifying that H(r) equals h_1. This procedure provides a way to trigger actions such as the closing of a HIP association in a secure way. It only requires to attach the secret value r to the message which carries the unprotected signaling for the predefined signal. The transmission of r substitutes the IHC-based signature that would otherwise have been necessary to secure the signaling of the action. Therefore, using predefined signals instead of IHC-based signatures saves 1.5 RTTs. Anchors for predefined signals must be exchanged and assigned to the signal in the beginning of the communication process during the BEX. 4.8. Unprotected HIP Control Packets For some control packets, it is not necessary to apply signatures as these either do not carry data worth protecting or are protected by other mechanisms. Apart from the following exceptions, all HIP control packets MUST be protected with IHC-based signatures. Other HIP extensions may define further exceptions. List of MESSAGES which are not protected by IHC-based signatures: 1. UPDATE packets which only carry ACK and ECHO_RESPONSE because manipulations can be detected without signatures (cf. Section 4.3.6). 2. CLOSE packets because they are protected by predefined signals (cf. Section 4.13). 3. UPDATE packets which are used for an LHIP to HIP upgrade because they are protected by a predefined signal and an HMAC which uses a shared key (cf. Section 4.14). 4.9. LHIP Handshake HIP uses the BEX to create the HIP communication context, the HIP association, on both hosts. LHIP extends the BEX in order to establish the LHIP communication context. LHIP hosts generate hash chains and exchange hash chain anchors with the peer during the base exchange. Unlike the HIP base exchange, no PK operations are Heer Expires August 5, 2007 [Page 28] Internet-Draft Lightweght HIP February 2007 performed during the LHIP base exchange in the general case. Therefore, all HIP specific packets and parameters except the RSA and HMAC signatures in the I2 and R2 packet are present in the LHIP base exchange. LHIP preserves the semantics and the functionality of HIP parameters that excluded from this document. However, LHIP extends the functionality of the TRANSFORM parameter and uses the new LFLAGS parameters during the BEX. 4.9.1. LHIP Transform Suites LHIP negotiates the type of association (LHIP or HIP) during the BEX to allow interoperability of hybrid hosts and LHIP-unaware HIP hosts. It uses the HIP_TRANSFORM parameter to determine whether LHIP or HIP must be used. LHIP defines one additional transform suite and suite-ID in addition to the transform suites defined in [I-D.ietf-hip-base]: +-----------------+-------+ | Suite-ID | Value | +-----------------+-------+ | LHIP with SHA-1 | 7 | +-----------------+-------+ LHIP uses SHA-1 hash chains and SHA-1 HMACs when transform suite 7 is selected. Other transform suites have not been defined for LHIP yet but may be defined in the future. The RESPONDER indicates that it supports LHIP by including an LHIP transform suite in the HIP_TRANSFORM parameter, carried by the R1 packet . The ordering of the transform suites indicates the RESPONDER's preferences. The INITIATOR selects two transform suites from the given set transform suites in the HIP_TRANSFORM parameter in the R1 and sends them back to the RESPONDER. LHIP MUST used when the INITIATOR selects an LHIP transform suite as preferred (first) entry. The INITIATOR also selects a second HIP transform suite other than an LHIP transform suite in order to specify the HIP transform suite that will be used after the upgrade from LHIP to HIP. The INITIATOR sends back both selections in a HIP transform parameter in the I2 packet. The RESPONDER buffers the second HIP transform suite for later use during the upgrade process. 4.9.2. Hash Chain Anchors The hosts must exchange their sets of hash chain anchors during the base exchange in order to sign HIP control messages with the IHC- Heer Expires August 5, 2007 [Page 29] Internet-Draft Lightweght HIP February 2007 based approach and to use predefined signals later. These anchors are added to the I2 packets and the R2 packets. This enables the RESPONDER to stay stateless until it receives the I2 packet without the need to buffer the INITIATOR's hash chain anchors. Moreover, the RESPONDER can use the echo-request/response mechanism to verify the routability of the INITIATOR's locator before creating the hash chains. LHIP exchanges the the anchors of the SIGNATURE_CHAIN, TRIGGER_CHAIN, CLOSE_CHAIN, and the UPGRADE_CHAIN during the BEX. The corresponding HCA parameters MUST be present in the I2 and R2 packet. 4.9.3. Diffie-Hellman Parameters LHIP does not use the Diffie-Hellman key exchange during the BEX in order to reduce the computational complexity of the HIP base exchange. Nevertheless, it is necessary to exchange the DH parameters in order to allow an upgrade from LHIP to HIP at a later point in time. Therefore, both hosts exchange their DH parameters as specified in the HIP base protocol. Each host buffers the DH parameters of its peer until these are used during the LHIP upgrade process. 4.9.4. ECHO_REQUEST parameter LHIP hosts MUST include an ECHO REQUEST in the R1 packet if they act as RESPONDER and in the I2 packet if they act as INITIATOR. The hosts must ensure that the ECHO_REQUESTS are unique for every association. This uniqueness serves as replay protection for authenticated LHIP associations. LHIP hosts MUST reply with an ECHO_REQUEST_SIGNED parameter to ECHO_RESPONSE parameters. 4.9.5. RSA and DSA Signatures RSA and DSA signatures are not obligatory for the I2 and R2 packet during the LHIP base exchange. Only the R1 packet is REQUIRED to be signed for compatibility reasons. However, some scenarios make the selective use of these PK-signatures in the I2 and R2 packet necessary. LHIP does not provide host authentication but, in case of a name collisions (two different hosts use the same HI to contact a RESPONDER), it is necessary to verify the identity of a host. Especially when LHIP and HIP are used in combination, protection of the HIP namespace is vital. We distinguish two different kinds of attacks on unprotected HIs: HI blocking attack: An attacker uses the HI of a victim host to establish a connection to a RESPONDER in order to create an incorrect binding between HI and an IP on the RESPONDER before or after the victim contacts the RESPONDER. This leads to a Heer Expires August 5, 2007 [Page 30] Internet-Draft Lightweght HIP February 2007 situation in which the RESPONDER can not differentiate the attacker from the victim if none of them authenticates by using its private key. HI stealing attack: An attacker uses an HI of a potential RESPONDER of the victim to establish an LHIP association with the victim before the victim contacts the RESPONDER. If the victim tries to send data to the RESPONDER later, it will use the already established LHIP association with the attacker and consequently send all traffic to the attacker. Using RSA or DSA to verify the HIs of the hosts during the BEX solves both problems but increases the computational complexity of LHIP. Therefore, LHIP only uses RSA or DSA signatures in case of name collisions and potential HI stealing attacks. A RESPONDER MUST request PK-authentication from an INITIATOR if it has already maintains an open LHIP association with the HI of the INITIATOR. This authentication serves as protection against the HI blocking attack. Hosts which typically act as servers SHOULD authenticate all outgoing LHIP associations. Hosts, which typically act as client, SHOULD authenticate all incoming LHIP associations. A host MUST either authenticate all incoming or outgoing associations. This authentication scheme makes the HI stealing attack impossible. 4.9.6. Authenticated Hash Chain Anchors Using RSA and DSA signatures to verify the HI of a peer also ties the hash chain anchors to the HI because they are contained in the signed part of the I2 and R2 packet. In this case, the LHIP association and all following updates and modifications can be related to the identity of a host. Hosts can define their own policies when to verify the identity of a peer and when they are willing to authenticate to the peer. For instance, servers that only offer insensitive content can deny to authenticate to clients in order to save CPU-resources. These requirements and this willingness is expressed in the LFLAGS parameter. This parameter is attached to the R1 packet and to the I2 packet. It provides three flags: LFLAG_AUTH_REQUIRED, LFLAG_OFFER_AUTH, and LFLAG_OFFER_UPGRADE. Setting LFLAG_AUTH_REQUIRED flag signals that the peer MUST authenticate in order to continue the BEX. A host, which receives an LFLAGS parameter with the LFLAG_AUTH_REQUIRED flag, MUST either sign its next BEX packet (I2 or R2 depending on whether the host acts as INITIATOR or RESPONDER) with its private key or abort the BEX. The LFLAG_OFFER_AUTH flag signals that a host is willing to Heer Expires August 5, 2007 [Page 31] Internet-Draft Lightweght HIP February 2007 authenticate when its peer requires authentication. Denying authentication is useful for servers which are vulnerable to DoS attacks and do not provide sensible data or services. The LFLAG_OFFER_UPGRADE indicates that a host will accept requests to upgrade from LHIP to HIP. Setting this flag indicates implicitly the willingness to use PK-signatures during the upgrade process. Authenticated LHIP BEX packets MUST contain the ECHO_RESPONSE parameter in the signed part of the packet. LHIP hosts MUST ensure that an ECHO_RESPONSE parameter is only used once to avoid replay attacks. Consecutive authenticated I2 and R2 packets with the same ECHO_RESPONSE parameter contents MUST be discarded 4.9.7. Encrypted Host Identifiers LHIP does not support encrypted HIs in the I2 packet as no symmetric key is available to encrypt these. 4.9.8. Puzzle Mechanism LHIP does not change the semantics or the functionality of the HIP puzzle mechanism. LHIP RESPONDERS can use puzzles to generate CPU- load on the INITIATOR. However, it is RECOMMENDED to use low puzzle difficulties (e.g. 0) in order to keep the computational cost of LHIP low. 4.9.9. Basic LHIP Base Exchange Overview The LHIP BEX is depicted below. The anchors comprise all LHIP anchors. The anchors of the INITIATOR are marked with an index i and the anchors of the RESPONDER with an index r, accordingly. Heer Expires August 5, 2007 [Page 32] Internet-Draft Lightweght HIP February 2007 The basic LHIP BEX: INITIATOR RESPONDER Pre-calculate R1 I1: I1 contents --------------------------> Add LFLAGS to pre- calculated R1: set LFLAG_AUTH_REQUIRED in case of collisions R1: R1 contents, LFLAGS <---------------------------- [Verify signature] select LHIP transform suite, select HIP transform suite, [add signature to I2] I2: I2 contents, anchors_i, [SIG], LFLAGS ----------------------------> [Verify signature], store anchors, [add signature to R2] R2: R2 contents, anchors_r, [SIG] <---------------------------- [Verify signature], store anchors. The contents of the HIP BEX packets are summarized as I1, R1, I2, and R2 contents. In contrast to the basic HIP BEX, the I2 and R2 contents do not necessarily contain RSA, DSA, or HMAC signatures. Figure 6 4.9.10. Use of IPsec and Other Payload Transfer Protocols When using IPsec [RFC2401] to transfer payload, the LHIP communication peers must use the IPsec ESP BEET mode [I-D.nikander-esp-beet-mode] with NULL encryption and with a key of zeroes for authentication. The authentication algorithm must be set according to the selected LHIP transform suite ID (cf. Section 4.9.1). Note that using IPsec in this way neither ensures integrity nor confidentiality for LHIP payload. Currently, the only Heer Expires August 5, 2007 [Page 33] Internet-Draft Lightweght HIP February 2007 supported transfer protocol for LHIP is IPsec. Specifying the use of other ways for transferring payload, such as using plain IP or UDP tunneling is future work. 4.9.11. Concluding the LHIP Base Exchange In the end of the LHIP base exchange, both hosts have agreed to use LHIP. Both hosts have also exchanged their hash chain anchors. The hosts have an unencrypted ESP BEET tunnel between them. HIP control messages are protected by IHC-based signatures. 4.10. Chained Bootstrapping The LHIP base exchange is vulnerable to active attackers which are able to eavesdrop the R1 packets and can send forged I2 packets with spoofed locator information. One way to circumvent this attack is to use a mechanism similar to chained bootstrapping as proposed in the WIMP protocol[I-D.ylitalo-multi6-wimp]. Chained bootstrapping is OPTIONAL for LHIP because it raises the computational cost for the RESPONDER slightly. LHIP compliant hosts MAY implement and support chained bootstrapping but are not obliged to do so. 4.10.1. Chained Bootstrapping for the INITIATOR When using chained bootstrapping, the INITIATOR must compute its hash chains before sending the I1 packet. It includes the pre-signature of the I2 packet (including the anchors) in the I1 packet. This pre- signature is created with a pseudo-random value r_1 as key. All fields of the I2 packet which depend on the R1 packet of the RESPONDER (the R1_COUNTER, the puzzle SOLUTION, the HIP_TRANSFORM, the [encrypted] HOST_ID and the ECHO_RESPONSE) are excluded from the signature. These parameters are not zeroed in the signature but completely left out. It is important to include the anchors of the hash chains in the pre-signature of the I1 packet to avoid that these are forged by a third party when transmitted in cleartext in the I2 packet. The RESPONDER can stay stateless when it includes the pre-signature from the INITIATOR in the ECHO_REQUEST parameter of the R1 packet. It MUST encrypt the pre-signature or apply other integrity protection measures to the ECHO_REQUEST in order to avoid security compromise. 4.10.2. Chained Bootstrapping for the RESPONDER Chained bootstrapping is also applicable to the R1 and the R2 packet. The RESPONDER must generate its hash chains before sending the R1 packet. It generates an HMAC signature from the concatenation of the R1 packet and the anchors of the hash chains and encodes it as PS Heer Expires August 5, 2007 [Page 34] Internet-Draft Lightweght HIP February 2007 parameter. It uses a pseudo-random value r_2 as key for the HMAC. It attaches the PS parameter to the R1 packet. The RESPONDER must store the anchors and the r2_value until the I2 message arrives. Alternatively, it can use the ECHO_REQUEST parameter to send r_2 and the seeds of the hash chains to the INITIATOR in an encrypted envelope, keeping the key to the envelope disclosed. The INITIATOR must send back the encrypted envelope from which the RESPONDER can decrypt the seeds and the r_2 value. It can generate the very same hash chains and hash chain anchors from the seeds. The details of managing the anchors and the state like the choice of the encryption algorithm are implementation details which only concern the RESPONDER. Therefore, these details are not specified in this document. The INITIATOR can check the integrity of the R1 packet and the hash chain anchors in the R2 packet after it has received the R2 packet which contains the r_2 value. This means that the INITIATOR MUST react to the unverified R1 packet in order to continue the BEX. However, it MAY verify the RSA or DSA signature in the R1 packet. Chaining the R1 and R2 packet ensures that both messages have been sent by the same host and that neither the anchor values nor the contents of the R1 packet have been modified. However, it is possible that an MitM attacker modifies both messages and forges R1 and R2 packets with different contents and anchor values. It is important to include the anchors in the pre-signature in the R1 packet to avoid that these are manipulated while the R2 packet is in transit. This ensures that the anchors are related to the R1 packet. Therefore, this avoids attacks after the INITIATOR has received the R1 packet. Heer Expires August 5, 2007 [Page 35] Internet-Draft Lightweght HIP February 2007 The chained LHIP BEX with chaining on the INITIATOR's and RESPONDER's side: INITIATOR RESPONDER Generate anchors, PS=HMAC-F(I2, r_1), I1: I1 contents, PS_1 --------------------------> Generate anchors from seeds PS_2=HMAC(R1|anchors_r, r_2), ECHO=ENC(secret, PS_1|r_2|seeds) R1: R1 contents, ECHO, PS_2 <-------------------------- Buffer PS_2 I2: I2 contents, anchors_i, r_1 --------------------------> PS_1=?HMAC(I2|anchors_i, r_1), seeds, r_2=DEC(secret, ECHO), Generate anchors from seeds R2: R2 contents, anchors_r, r_2 <-------------------------- PS_2=?HMAC(R1|anchors, r_2) The contents of the HIP BEX packets are summarized in the I1, R1, I2, and R2 content. Only parameters which are related to chained bootstrapping are depicted. Further LHIP specific parameters are depicted in Figure 6. Figure 7 It is not necessary to explicitly announce that a host uses chained bootstrapping as its peer can validate this from the presence of the PS parameter in the I1 or R1 packet. Heer Expires August 5, 2007 [Page 36] Internet-Draft Lightweght HIP February 2007 4.11. Hash Chain Extension Hash chains are finite. Therefore, it is necessary to replace depleted hash chains with new ones to allow an infinite number of signature processes. In order to accomplish this, a host must send new anchors to the peer. The host MUST sign the packets that contain anchors with IHC-based signatures. Therefore, the host can either submit the anchors in a dedicated UPDATE packet or piggy-backed on other signed HIP control packets. For example, UPDATE packets can be used for piggy-backing. An LHIP host MUST check the contents of each IHC-signed message and buffer new anchors when present. A host MAY use the new replacement hash chains as soon as the acknowledgment for the IHC-signed message, carrying the new anchors, is received. It MAY also continue to use the old hash chains. However, it MUST activate the new hash chains before the old hash chains deplete. LHIP uses an implicit mechanism for activating the new hash chains after they have been delivered to the peer. A host activates the new hash chain by using an element of the new hash chain in the HCE parameter of S1 packet or in the A1 packet. The receiver of an S1 or A1 packet verifies whether the contained HCE belongs to the old or the new hash chain. A host MUST remove the old hash chain and MUST start to use the new hash chain after the it has sent the first HCE parameter containing an element of the new hash. A host, which receives a message with an HCE belonging to a new anchor, MUST NOT accept HCE parameters which belong to old anchors or hash chain elements. 4.12. LHIP Interaction with Middle-boxes HIP UPDATE messages are not only processed by the communicating peers but also by middle-boxes on the communication path. These middle- boxes learn about new locators and SPI values by inspecting the UPDATE messages. The IHC-based signatures can be authenticated by middle-boxes. Therefore, in contrast to HIP, UPDATE packets do not need to contain RSA or DSA signatures. Like LHIP VERIFIERS, Middle-boxes must buffer the PS parameter in the S1 packet of the IHC signature until the S2 packet with the corresponding hash chain element and the message arrives. In order to allow IHC-based signatures, the middle-box must let S1 and A1 packets pass through without verification and without restriction of the source IP addresses contained in them. However, the middle box SHOULD rate-limit the number of S1 and A1 packets that are sent to the same IP address to avoid DoS attacks on hosts behind a middle- box. It SHOULD also verify that the HCE parameter in these packets are either valid or old. Packets containing invalid HCEs SHOULD NOT be forwarded. It SHOULD also check that these packets contain no Heer Expires August 5, 2007 [Page 37] Internet-Draft Lightweght HIP February 2007 payload besides the HSE, the PS, the PACK, and the PNACK parameters and SHOULD drop packets which contain further parameters to prevent attacks with large parameter contents. 4.13. Closing an LHIP Association Like HIP associations, LHIP associations are torn down when they are not used any more. It is necessary to protect this closing process to avoid attacks. However, it is not necessary for LHIP to protect the CLOSE messages with IHC-based signatures as they only carry one vital bit of information which requires protection: whether to close the association. Therefore, it it sufficient to use a predefined signal to securely announce the closing of an LHIP association. Both hosts send HIP CLOSE or CLOSE_ACK messages without RSA, DSA and HMAC signatures and attach a HCE parameter containing the second element of the CLOSE_CHAIN. The peer MUST verify the CLOSE and CLOSE_ACK message by comparing the hashed contents of the HCE parameter with the anchor of the peer's CLOSE_CHAIN which was exchanged during the LHIP BEX. The hosts proceed with the standard HIP closing procedure if the HCE parameter is valid. CLOSE messages with old or invalid HCE parameters MUST be discarded without further processing. 4.14. Upgrading an LHIP Association A host can initiate an upgrade from an LHIP to a HIP association when the security properties of a full HIP association are required. This is the case when a process establishes an LHIP association and the same or another process requests a HIP association with the same HIs as endpoints later. LHIP associations are upgradable when both hosts have indicated that they support upgrades in the LFLAGS parameter. The upgrade process is a two-way message exchange. LHIP uses HIP UPDATE messages to carry the upgrade information. In order to achieve security properties of full HIP, LHIP uses RSA or DSA signatures and the DH key exchange during the upgrade. The term INITIATOR is used for the initiator of an upgrade and the term RESPONDER for the host which reacts to the upgrade request. 4.14.1. The First Upgrade Packet Before initiating an upgrade, the INITIATOR calculates the DH shared secret from the DH keys exchanged during the BEX. It generates the symmetric keys and the keys for the HMAC creation from this shared secret. The key creation process follows the rules defined for the key creation during the HIP BEX. The INITIATOR sets up new IPsec SPs which use the algorithms selected in the second HIP transform. It also sets up a new outgoing IPsec security association with the symmetric keys. Heer Expires August 5, 2007 [Page 38] Internet-Draft Lightweght HIP February 2007 The INITIATOR sends the first message U1 of the upgrade process. It is an UPDATE message which contains the SPI value of the new IPsec SA encoded as ESP_INFO parameter (cf. [I-D.ietf-hip-esp]), HI, and an HMAC to protect the SPI values. The freshly created symmetric keys are used as key for the HMAC computation. The INITIATOR also adds an RSA or DSA signature, generated with the private key if it has not authenticated during the BEX. In this case, it MUST include the ECHO_RESPONSE parameter in the U1 packet as replay protection. A host which supports LHIP upgrades MUST ensure that the ECHO_REQUEST in the R1 packet is unique for every LHIP association and that the ECHO_RESPONSE in the first upgrade packet has not been used in order to upgrade an LHIP association between the same HIs before. The UPGRADE message triggers the DH shared key computation at the RESPONDER. This operation is CPU-intensive and can be used in an attack to provoke the DH calculations with a forged message. Therefore, the upgrade process must be protected with signatures. As for the CLOSE packets, using predefined signals is sufficient as all other vital information in the packet is protected by the HMAC. Therefore, both hosts include an HCE parameter containing the next element of the UPGRADE_CHAIN in their upgrade message. The structure of the U1 packet is depicted below. IP ( HIP-UPDATE ( ESP_INFO, ECHO_RESPONSE_SIGNED, HMAC, HIP_SIGNATURE, HCE)) The host responding to U1 packet verifies that the HCE parameter belongs to the peer's UPGRADE_CHAIN and that it is valid. This comparison is inexpensive and proves that the legitimate peer initiated the upgrade process. The host calculates the DH shared secret if the hash chain verification is successful. The RESPONDER generates the symmetric keys and the key for the HMAC signatures from the shared secrets. The RESPONDER can verify the HMAC signature in the UPGRADE message by using the freshly calculated keys. The RESPONDER modifies the IPsec SPs in order to use the encryption algorithms selected in the second HIP transform. It then sets up the outgoing and incoming IPsec SAs corresponding to the remote peer's SPI and the symmetric keys. It is necessary to include the HIs of the peers in the UPGRADE messages to support HIP-aware middle-boxes. The HIs in the packets enable these middle-boxes to learn the public keys of the hosts, in case the middle-box has not observed the BEX. This is the case when either of the hosts has moved behind a new middle-box during the LHIP Heer Expires August 5, 2007 [Page 39] Internet-Draft Lightweght HIP February 2007 association. 4.14.2. The Second Upgrade Packet The RESPONDER sends back an HMAC-protected UPDATE message which contains its SPI value for the incoming IPsec SA encoded as ESP_INFO parameter, the next element of its UPGRADE_CHAIN encoded as HCE parameter, and its HI. The RESPONDER MUST prove its identity by using its RSA or DSA private key, if it has not already done so during the LHIP BEX. It MUST also include the ECHO_RESPONSE from the LHIP BEX to avoid replay attacks. The INITIATOR can use the HMAC to verify the UPDATE message. It sets up its outgoing SA with the SPI given by the remote peer. At this point, both peers have upgraded to HIP and established an encrypted BEET tunnel. They do not use the LHIP authentication functions any more. The structure of the U2 packet is identical to the structure f the U1 packet. 4.14.3. Concurrent Upgrade Initialization The first and the second upgrade packet are symmetrical. This avoids problems with concurrent upgrades. A host which has sent the first upgrade packet can use a simultaneously sent first upgrade packet as second upgrade packet and complete the upgrade process successfully. 4.14.4. HIP Downgrade A downgrade from HIP to LHIP is not desirable because both hosts are already in possession of the shared secret which enables efficient message authentication and symmetric encryption. 4.14.5. Upgrade DoS Attack The upgrade process can be used as a tool to DoS attack a victim host that uses LHIP. An attacker can open numerous LHIP associations to the victim with low computational cost and upgrade all of these connections at the same time. This would require the victim to compute numerous Diffie-Hellman key exchanges which results in high CPU utilization. Currently, there is no defense to this attack as the puzzle mechanism is not applicable to the two-way upgrade process. Therefore, hosts SHOULD limit the number of upgrades in a certain time interval. Alternatively, hosts can refuse to upgrade associations by not setting the LFLAG_OFFER_UPGRADE flag in the LFLAG parameter. 4.14.6. Sequence Numbers HIP uses sequence numbers to protect HIP UPDATE packets. LHIP allows HIP extensions to send unprotected UPDATE packets when the contents Heer Expires August 5, 2007 [Page 40] Internet-Draft Lightweght HIP February 2007 of the UPDATE packet does not require authentication. Therefore, attackers can modify the sequence numbers in these unprotected packets. The IHC-based signature scheme of LHIP ensures the correct sequence of protected HIP UPDATE packets. Therefore, LHIP hosts MUST ignore the sequence numbers of HIP control packets. As sequence numbers are vital for HIP to operate correctly, LHIP associations which have been upgraded to HIP associations must obey the sequence numbers. The sequence number counter of an upgraded LHIP association must be set to the sequence number contained in the U1 or U2 packet, respectively. 4.15. State Loss A host can lose all information about an established LHIP association due to events like hardware errors, software errors, or an operating system reboot. In this case, the peers of the host still use the context information of the broken LHIP association. Recovery from state loss requires host authentication to avoid replay attacks. A host that has lost its state reinitiates an LHIP association by sending an I1 packet. As the RESPONDER has already associated state with the other host's HI, the RESPONDER MUST require the INITIATOR to authenticate by using its private key. The RESPONDER deletes the existing state if the authentication is successful. It MUST silently drop the I2 packet otherwise. 5. Security Considerations LHIP aims at providing HIP mobility and multihoming support for devices with few CPU resources. As discussed in Section 2, LHIP provides no support for end-host authentication nor does it encrypt payload from upper protocol layers. Therefore, it SHOULD only be used when these properties are either provided by higher-layer protocols or are not required at all. LHIP uses the same host identifier namespace as HIP without necessarily authenticating the HIs. As discussed in Section 4.9.5 attacks are possible if host authentication is omitted completely. Therefore, it is important that all LHIP hosts implement the proposed defense mechanisms against the HI stealing and HI blocking attack in order to protect LHIP and, importantly, HIP hosts. The question how to avoid DoS attacks caused by parallel LHIP upgrades, as discussed in Section 4.14.5, is not solved completely. Hosts which are prospective targets for such attacks SHOULD limit the number of concurrent upgrades or categorically deny LHIP upgrades. The option of tearing down an LHIP association and re-establishing a Heer Expires August 5, 2007 [Page 41] Internet-Draft Lightweght HIP February 2007 new HIP association remains as alternative way to switch from LHIP to HIP. In that case, all security features of HIP, including the puzzle mechanism, can be used to protect the RESPONDER. In opposition to HIP, LHIP does not provide protection against MitM attacks during the BEX if the hosts do not use authenticated hash chains. Unauthenticated LHIP is vulnerable to MiTM attacks. Impersonation attacks can only be detected and resulting conflicts can only be resolved if two hosts use the same HI to establish an association with a RESPONDER. It is out of scope for LHIP to protect against these attacks as LHIP does not enforce host authentication. Note that LHIP does not replace HIP in any way. LHIP is an extension to HIP and requires a full HIP implementation including all security and protocol features provided by the basic HIP protocol. 6. IANA Considerations This document defines three new HIP packet types in Section 4.5 the type numbers (22, 23, 24) for these packet types are preliminary and need to be assigned through IETF consensus. LHIP also defines several new parameter types in Section 4.4. The preliminary parameter type numbers are 222, 64702, 64704, 64725, 64727, 64729, 64731, and 63404. LHIP defines a new HIP transform suite ID (7). This suite ID is preliminary and needs to be assigned in consensus with the IETF. LHIP creates a new namespace for hash chains type identifiers. New identifiers for further hash chain types which are either used in the IHC-based signature process or for predefined signals are assigned through IETF consensus. Other HIP extensions may use the LFLAGS parameter to transmit LHIP related flags as well. The position for these flags in the bit-mask are assigned through IETF consensus. 7. Acknowledgments Miika Komu, Stefan Goetz, Jukka Ylitalo, Pekka Nikander, Sasu Tarkoma, Janne Lindqvist, Olaf Landsiedel, and Klaus Wehrle have contributed valuable ideas and important feedback concerning LHIP and the IHC-based signature process. Heer Expires August 5, 2007 [Page 42] Internet-Draft Lightweght HIP February 2007 8. References 8.1. Normative References [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 (work in progress), February 2007. [I-D.ietf-hip-esp] Jokela, P., "Using ESP transport format with HIP", draft-ietf-hip-esp-05 (work in progress), February 2007. [I-D.ietf-hip-mm] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-04 (work in progress), June 2006. [I-D.komu-btns-api] Komu, M., "IPsec Application Programming Interfaces", draft-komu-btns-api-00 (work in progress), October 2006. [I-D.mkomu-hip-native-api] Komu, M., "Native Application Programming Interfaces for the Host Identity Protocol", draft-mkomu-hip-native-api-00 (work in progress), March 2005. [I-D.nikander-esp-beet-mode] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 (work in progress), August 2006. [I-D.ylitalo-multi6-wimp] Ylitalo, J., "Weak Identifier Multihoming Protocol (WIMP)", draft-ylitalo-multi6-wimp-01 (work in progress), July 2004. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. Heer Expires August 5, 2007 [Page 43] Internet-Draft Lightweght HIP February 2007 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. 8.2. Informative References [DH71] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory vol. IT-22, number 6, pages 644-654, 1976. [Lam81] Lamport, L., "Password authentication with insecure communication", Commun. of ACM 24 (11), pp. 770-772, 1981. Author's Address Tobias Heer RWTH Aachen University, Distributed Systems Group Ahornstrasse 55 Aachen 52062 Germany Phone: +49 241 80 214 32 Email: tobias.heer@cs.rwth-aachen.de URI: http://ds.cs.rwth-aachen.de/members/heer Heer Expires August 5, 2007 [Page 44] Internet-Draft Lightweght HIP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Heer Expires August 5, 2007 [Page 45]