R. Moskowitz, ICSA Labs Internet Draft Document: February 2001 Host Identity Payload And Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Table of Contents 1. Abstract...........................................................2 2. Conventions used in this document..................................2 3. Introduction.......................................................2 4. The Host Identity Payload..........................................3 4.1. HIP format.......................................................3 4.2. HIP Key Payload..................................................4 5. HIP Cookie Exchange................................................5 6. HIP Packets........................................................5 6.1. I1 - the HIP Initiator packet....................................6 6.2. R1 - the HIP Responder packet....................................6 6.3. I2 - the HIP Second Initiator packet.............................7 6.4. R2 - the HIP Second Responder packet.............................7 6.5. REK - the HIP Rekey Packet.......................................8 6.6. NES - the HIP New SPI Packet.....................................9 6.7. REA - the HIP Readdress Packet..................................10 6.8. HIP Fragmentation Support.......................................11 7. ESP with HIP......................................................11 7.1. Security Parameters Index (SPI).................................11 7.2. Supported Transforms............................................11 Moskowitz 1 Host Identity Payload February 2001 7.3. Sequence Number.................................................12 7.4. ESP usage with non-cryptographic HI.............................12 8. HIP Exchange packet flow..........................................12 8.1. The HIP Exchange................................................12 8.2. HIP KEYMAT......................................................12 8.3. Refusing a HIP exchange.........................................13 8.4. Reboot restart of HIP...........................................13 8.5. Sequence Number State Machine...................................14 9. HIP Policies......................................................15 10. Security Considerations..........................................15 11. IANA Considerations..............................................17 12. ICANN Considerations.............................................17 13. References.......................................................17 14. Acknowledgments..................................................18 15. Author's Address.................................................18 16. Copyright Statement..............................................19 1. Abstract This memo describes the Host Identity Payload (HIP) described in the HIP architecture [HIPARCH] and the Host Layer Protocol (HLP) that uses it to establish a rapid authentication between two hosts and continuity between those hosts independent of the Networking Layer. The various forms of the Host Identity, HI, HIT, and LSI are covered in detail and how they support the authentication and the establishment of Keying Material that is used by ESP [ESP]. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many DOS attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered in the HIP implementation document [HIPIMPL]. 2. Conventions used in this document 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]. 3. Introduction The Host Identity Payload (HIP) along with the HIP Protocol a rapid exchange of Host Identities (HI) that also establishes a Security Association for ESP. The HIP protocol is resistant to Denial-of- Service (DOS) and Man-in-the-middle (MITM) attacks, and when used to enable ESP, provides DOS and MITM protection to TCP and UDP. The Host Identity Payload introduces a new namespace, the Host Identity. There are three representations of the Host Identity, the full Identity (HI), the Host Identity Tag (HIT), and the Local Moskowitz 2 Host Identity Payload February 2001 Scope Identity (LSI). Three representations are used, as each meets a different design goal of HIP, and none of them can be removed and meet these goals. The HI is the Identity, normally a public key. Since there are different public key algorithms that can be used with different key lengths, the HI is not good for using as the HIP packet identifier, or as a index into the various operational tables needed to support HIP. A hash of the HI, the Host Identity Tag (HIT) thus becomes the operational representation. It is 128 bits long, and the index in the payload. However, in many environments, 128 bits is still considered large. Also IPv4 is constrained with 32 bit API fields. So the third representation, the LSI is 32 bits. The LSI provides a compression of the HIT with only a local scope so that it can be carried efficiently in any packet and used in API calls. The HIP protocol is only four packets long. The four-packet design helps make HIP DOS attack resilient. The protocol exchanges Diffie- Hellman keys in the 2nd and 3rd packets and starts the cookie exchange in the 2nd packet. The exchange uses the Diffie-Hellman exchange to hide the Host Identities and exchanges these hidden Identities in packets 3 and 4. Data datagrams start after the 4th packet. Finally, HIP is designed as an end-to-end authentication and key establishment protocol. It lacks much of the fine-grain policy control found in IKE that allows IKE to support complex gateway policies. Thus HIP is not a complete replacement for IKE. In many cases, particularly in spanning addressing realms, HIP would be the preferred key establishment protocol. 4. The Host Identity Payload The Host Identity Payload or HIP is IP protocol NN. HIP SHOULD be carried in every datagram. However, since HIP datagrams are relatively large (at least 20 bytes), and ESP already has all of the functionality to maintain and protect state, the HIP payload is 'compressed' into an ESP payload after the HIP exchange. Thus in practice, HIP packets only occur in datagrams to establish or change HIP state. 4.1. HIP format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | Type | VER. | RES. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Identity Tag (HIT) | | | Moskowitz 3 Host Identity Payload February 2001 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HIP Key payload (opt) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP followed by IP payload (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header WILL be zero for those HIP packets that do not carry a transport layer. Thus Next Header SHOULD only be zero or 50 (ESP). Payload length is the length, in bytes, of the optional HIP Key payload. It is zero if there is no payload. Thus the length of the HIP envelope is 20 plus the payload length. The Type indicates which HIP packet this is. The HIP Version is one byte. The current version is 1. The HIT is always 128 bits (16 bytes). 4.2. HIP Key Payload The HIP Key Payload is used to carry the public key associated with the HIT and related security information. The format of the HIP Key Payload is a simplification of a DNS message [DNS]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RCOUNT | FQDNLGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / FQDN / / / | 0 - 7 bytes padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDLENGTH | TYPE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / RDATA / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . Moskowitz 4 Host Identity Payload February 2001 RCOUNT is the number of HIP Resource Records. If the sender does not have (or does not wish to divulge) an FQDN, a value of '.' will be used. The sender arbitrarily selects the content of the padding field. The HIP Resource Records will either be a KEY (e.g. DSA and D-H), SIG [DNSSEC], or OPT [EDNS] record. The RDATA of the OPT record in the payload can contain any of the following: OPT Attribute Length Data Remotes_HIT 128 Remote's HIT HIP_COOKIE 192 3 64 bit fields: Random # I, K or random # J, Hash target, Ltrunc(SHA1(I|J)) or Utrunc(SHA1(I|J)) HIP_TRANSFORM variable ISAKMP Transform [ISAKMP] Without first 32 bits Using Ipsec DOI ESP_TRANSFORM variable ISAKMP Transform [ISAKMP] Without first 32 bits Using Ipsec DOI Remotes_LSI 32 Remote's LSI Remotes_SPI 32 Remote's SPI 5. HIP Cookie Exchange The HIP cookie exchange serves to manage the establishment of state between the Initiator and Responder. This cookie exchange is different than other 3-way exchanges in that the Responder starts the exchange. Since the Responder starts the exchange, it can set the difficulty for the Initiator. The Responder supplies a random number I, and requires the Initiator hash it with a random number J. The resulting hash's lowest order K bits MUST match a hash target also supplied by the Responder. To accomplish this, the Initiator will have to generate a number of Js until one produces the hash target; the worst case SHOULD be 2^K hash operations. The Responder needs only hash the Initiator's J with its I to prove that the Initiator did its assigned task. Thus the Responder can set the difficulty for Initiator, based on its concern of trust of the Initiator. 6. HIP Packets There are 7 HIP packets. Four are for the HIP exchange and the other three are for mid-state changes (rekeying and address migration). Moskowitz 5 Host Identity Payload February 2001 6.1. I1 - the HIP Initiator packet Next Header = 0 Type = 1 HIT = Initiator's HIT Payload Contains: Responder's HIT in a KEY HIT RR The Initiator gets the responder's HIT either from a DNS lookup of the responder's FQDN or from a local table. Since this packet is so easy to spoof even if it were signed, no attempt is made to add to its generation or processing cost. Implementation MUST be able to handle a storm of I1 packets, discarding those with common content that arrive within a small time delta. 6.2. R1 - the HIP Responder packet Next Header = 0 Type = 2 HIT = Responder's HIT Payload Contains: Responder's HI in a KEY RR (e.g. KEY DSA RR) Initiator's HIT in a KEY HIT RR Responder's Diffie-Hellman public value in a KEY DH RR HIP TRANSFORM in a OPT RR ESP TRANSFORM in a OPT RR HIP COOKIE in an OPT RR HIP SIG in a SIG RR If the responder has multiple HIs, the HIT used MUST match Initiator's request. The Diffie-Hellman value is ephemeral, but can be reused over a number of connections. In fact, as a defense against I1 storms, an implementation MAY use the same Diffie-Hellman value for a period of time, for example 15 minutes. By using a small number of Is for a given Diffie-Hellman value, the R1 packets can be pre-computed and delivered as quickly as I1 packets arrive. A scavenger process should clean up unused DHs and Is. The HIP_TRANSFORM contains the encryption algorithms supported by the responder to protect the HI exchange, in order of preference. The ESP_TRANSFORM contains the ESP modes supported by the responder, in order of preference. HIP_COOKIE contains random I, K, and Hash Target. I is an internal pointer to the HI, HIT, and DH sent to the Initiator. It is only used as a pointer until this cookie is used in an SA. K is number of bits that the Initiator must match with the Hash Target. Moskowitz 6 Host Identity Payload February 2001 The HIP SIG is calculated over the whole HIP envelope. The Initiator MUST validate this SIG. It MAY use either the HI in the packet or the HI from a DNS query. 6.3. I2 - the HIP Second Initiator packet Next Header = 0 Type = 3 HIT = Initiator's HIT Payload Contains: Responder's HIT in a KEY HIT RR Responder's LSI in an OPT RR Responder's SPI in an OPT RR Initiator's Diffie-Hellman public value in a KEY DH RR HIP TRANSFORM in a OPT RR The following Resource Records are encrypted using the HIP Transform and are in a HIP ENCRPYT OPT RR HIP COOKIE in an OPT RR ESP TRANSFORM in a OPT RR Initiator's HI in a KEY RR (e.g. KEY DSA RR) HIP SIG in a SIG RR If the initiator has multiple HIs, the HI and HIT used MUST match Responder's reply. The Diffie-Hellman value is ephemeral. A scavenger process should clean up unused DHs and Js. The HIP_TRANSFORM contains the encryptions to protect the HI exchange selected by the initiator. HIP_COOKIE contains random I and J, and Ltrunc(SHA1(I|J)) (that is the low order bits of the SHA1 of I concatenated with J). The low order K bits of Ltrunc(SHA1(I|J)) MUST match the low order K bits of the Hash Target. J is an internal pointer to the HI, HIT, and DH sent to the Responder. The ESP_TRANSFORM contains the ESP mode selected by the initiator. The HIP SIG is calculated over whole HIP envelope. The Responder MUST validate this SIG. It MAY use either the HI in the packet or the HI from a DNS query. 6.4. R2 - the HIP Second Responder packet Next Header = 0 Type = 4 HIT = Responder's HIT Payload Contains: Initiator's LSI in an OPT RR Moskowitz 7 Host Identity Payload February 2001 Initiator's SPI in an OPT RR The following Resource Records are encrypted using the HIP Transform and are in a HIP ENCRPYT OPT RR Responder's HI in a KEY RR (e.g. KEY DSA RR) HIP COOKIE in an OPT RR HIP SIG in a SIG RR HIP_COOKIE contains random I, Ltrunc(SHA1(I|J)), and Rtrunc(SHA1(I|J)). The HIP SIG is calculated over whole HIP envelope. The Initiator MUST validate this SIG. 6.5. REK - the HIP Rekey Packet During the life of a Security Association established by HIP, one of the hosts may need to rekey. The reason for rekeying might be an approaching sequence number wrap in ESP, or a local policy on use of a key. Rekeying ends the current SA and starts a new one. The Rekey Payload permits a host to change its Diffie-Hellman key and thus the keying material for ESP. The Rekey Packet is a HIP packet with only a Diffie-Hellman RR in the HIP payload. The HIP packet is transported within the ESP to provide authentication and replay protection of the rekeying; there is no next protocol in the HIP packet. Thus the datagram looks like: IP[ESP[HIP(D-H)]] The HIP content is: Next Header = 0 Type = 5 HIT = Sender's HIT Payload Contains: New Diffie-Hellman public value in a KEY DH RR When a host receives a Rekey Packet, its second from next ESP packet MUST use the KEYMAT generated by the new Kij. The sending host MUST expect at least a sequence number replay window worth of ESP packets using the old Kij. Out of order delivery could result in needing the old Kij after packets start arriving using the new SA's Kij. Once past the rekeying start, the sending host can drop the old SA and its Kij. The first packet sent by the receiving system MUST be a HIP New SPI packet. This packet supplies the new SPI for the rekeying system, which cannot send any packets until it receives this packet. If it does not receive a HIP New SPI packet within a resonable round trip delta, it MUST assume it or the HIP Rekey packet was lost and renegotiate HIP as if in a reboot condition. Moskowitz 8 Host Identity Payload February 2001 6.6. NES - the HIP New SPI Packet The HIP New SPI Packet serves two functions. First it provides the rekeying system with its new SPI. Additionally, it provides any intermediate system with the mapping of the old SPI to the new. This is important to systems like NATs [HIPIMPL] that use SPIs to maintain address translation state. The new SPI Packet is a HIP packet with only a SPI OPT RR in the HIP payload. The HIP packet is transported within the ESP to provide authentication and replay protection. There MAY be a next protocol of HIP if the receiving host chooses to rekey at this time. Thus the datagram looks like: IP[ESP[HIP(SPI)]] or IP[ESP[HIP(SPI)[HIP(D-H)]]] The HIP content is: Next Header = 0 or NN (HIP's protocol number) Type = 6 HIT = Sender's HIT Payload Contains: Rekeyer's new SPI in an OPT RR HIP SIG in a SIG RR Since intermediate systems need this new SPI, this ESP packet MUST NOT be encrypted, that is ESP NULL is used. The rekeying system MUST anticipate this potential deviation from the agreed ESP Transform. It will recognize the packet as one arriving after it sent the HIP Rekey packet and the ESP Next Header will by NN BEFORE it decrypts, and the beginning of the ESP content is recognized as a HIP packet. Intermediate systems that use the SPI will have to inspect ALL ESP packets for a HIP New SPI packet. This is a potential DOS attack against the Intermediate system, as it cannot perform the ESP authentication. Thus the HIP record is signed with the HIP SIG RR for the benefit of the Intermediate systems. A further step against attack for the Intermediate systems is to implement ESP's replay protection of windowing the sequence number. Since this packet CANNOT be encrypted, the sending system MAY choose to send its Rekey packet (if it is rekeying immediately by local policy) in a separate packet using the new SPI and Kij. Alternatively, the sending system COULD use the following datagram to privately rekey: IP[ESP[HIP(SPI)[ESP[HIP(D-H)]]]] Where the first ESP header is the ESP NULL that is required by the HIP New SPI packet and the second ESP header uses the negotiated ESP transform as used in a simple HIP rekey packet. Moskowitz 9 Host Identity Payload February 2001 6.7. REA - the HIP Readdress Packet During the life of a Security Association established by HIP, one of the hosts may change its IP address. The reason for readdressing might be a PPP reconnect, DHCP new lease, or IPv6 address prefix change. The readdressing event might be from mobility or Internet reconnection. Although HIP enables ESP to be independent of the internetworking layer, there still needs to be a mapping of the LSI and HIT to an IP address. The Readdress Packet permits a host to notify its partners of an address change. The Readdress Packet is a HIP packet with a A or A6 RR in the HIP payload. The address RR is included in the HIP payload not for the partner's benefit (which COULD deduce this from the outer IP header), but for benefit of any intermediary systems that are maintaining state between the HIT and the address. If the readdressed host 'knew' that there were no intermediary systems between it and its partners, it COULD remove the address RR here for architectural purity. However, this option would only further complicate the protocol. The HIP packet is transported within the ESP to provide authentication and replay protection; there is no next protocol in the HIP packet. Thus the datagram looks like: IP[ESP[HIP(A|A6)]] The HIP content is: Next Header = 0 Type = 7 HIT = Sender's HIT Payload Contains: New address in an A or A6 RR HIP SIG in a SIG RR Since intermediate systems need this new address, this ESP packet MUST NOT be encrypted, that is ESP NULL is used. The receiving system MUST anticipate this potential deviation from the agreed ESP Transform. It will recognize the packet as one with the ESP Next Header of NN BEFORE it decrypts, and the beginning of the ESP content is recognized as a HIP packet. Intermediate systems that use the address will have to inspect ALL ESP packets for a HIP Readdress packet. This is a potential Dos attack against the Intermediate system, as it cannot perform the ESP authentication. Thus the HIP record is signed with the HIP SIG RR for the benefit of the Intermediate systems. A further step against attack for the Intermediate systems is to implement ESP's replay protection of windowing the sequence number. Moskowitz 10 Host Identity Payload February 2001 6.8. HIP Fragmentation Support A HIP implementation MUST support IP fragmentation/reassembly. HIP packets can get large, and may encounter low MTUs along their routed path. Since HIP does not provide a mechanism to use multiple IP datagrams for a single HIP packet, support of path MTU discovery does not bring any value to HIP. HIP aware NAT systems MUST perform any IP reassembly/fragmentation. 7. ESP with HIP HIP sets up a Security Association (SA) to enable ESP in an end-to- end manner that can span addressing realms (i.e. across NATs). This is accomplished through the various informations that are exchanged within HIP. It is anticipated that since HIP is designed for host usage, that is not for gateways, that only ESP transport mode will be supported with HIP. The SA is not bound to an IP address; all internal control of the SA is by the HIT and LSI. Thus a host can easily change its address using Mobile IP, DHCP, PPP, or IPv6 readdressing and still maintain the SA. And since the transports are bound to the SA (LSI), any active transport is also maintained. So real world conditions like loss of a PPP connection and its reestablishment or a mobile cell change will not require a HIP negotiation or disruption of transport services. Since HIP does not negotiate any lifetimes, all lifetimes are local policy. The only lifetimes a HIP implementation MUST support are sequence number rollover (for replay protection), and SA timeout. An SA times out if no packets are received using that SA. The default timeout value is 15 minutes. Implementations MAY support lifetimes for the various ESP transforms. Note that HIP does not offer any service comparable with IKE's Quick Mode. A Diffie- Hellman calculation is needed for each rekeying. 7.1. Security Parameters Index (SPI) The SPIs in ESP provide a simple compression of the HIP data from all packets after the HIP exchange. This does require a per HIT- pair Security Association (and SPI), and a decrease of policy granularity over other KMPs like IKE. When a host rekeys, it gets a new SPI from its partner. 7.2. Supported Transforms All HIP implementations MUST support 3DES [3DES] and HMAC-SHA-1-96 [HMACSHA1]. If the Initiator does not support any of the transforms offered by the Responder in the R1 HIP packet, it MUST use 3DES and HMAC-SHA-1-96 and state so in the I2 HIP packet. Moskowitz 11 Host Identity Payload February 2001 7.3. Sequence Number The Sequence Number field is MANDATORY in ESP. Anti-replay protection MUST be used in an ESP SA established with HIP. This means that each host MUST rekey before its sequence number reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman key is changed, that of the rekeying host. Thus if one host rekeys, the other host SHOULD rekey as well. 7.4. ESP usage with non-cryptographic HI Even if the Host Identity is not cryptographically based, ESP MUST still be used after the HIP exchange between the two hosts. The HIP TRANSFORM in this case will be left out of the HIP exchange, and the ESP envelope will not have any authentication of encryption. The purpose of using ESP in this situation is to have the SPI (LSI) for associating the packets with the HITs, and the sequence # for replay protection. 8. HIP Exchange packet flow A HIP exchange SHOULD be initiated whenever the DNS lookup returns HIP KEY resource records. Since some hosts may choose not to have information in DNS, hosts SHOULD support opportunistic HIP [HIPIMPL]. Only Initiator and Responder in common addressing realm (i.e. both public or both private) is shown here. Other packet flow scenarios are covered in the HIP implementation documents. 8.1. The HIP Exchange Initiator gets IP address, HI, and HIT of Responder somehow. Hard coded (bad) DNS lookup DNSSEC important I --> DNS (lookup R) I <-- DNS (R's address, HI, and HIT) I1 I --> R (Hi. Here is my I1, let's talk HIP) R1 I <-- R (OK. Here is my R1, handle this HIP cookie) I2 I --> R (Compute, compute, here is my counter I2) R2 I <-- R (OK. LetĘs finish HIP cookie with my R2) I --> R (ESP protected data) I <-- R (ESP protected data) 8.2. HIP KEYMAT Moskowitz 12 Host Identity Payload February 2001 HIP keying material is derived from the Diffie-Hellman Kij produced during the HIP exchange. The initiator has Kij during the creation or the I2 packet, and the responder has Kij once it receives the I2 packet. This is why I2 can already contain encrypted information. There are four keys that are derived from Kij; these are the initiator and responder HIP keys and the initiator and responder ESP keys. These four keys MUST be drawn sequentially (HIP initiator, HIP responder, ESP initiator, EXP responder, and where the ESP transform requires an encrypting and an authenticating key, they are taken sequentially) from the Kij KEYMAT. For situations where the amount of keying material desired is greater than that supplied by Kij, KEYMAT is expanded by feeding Kij into the following operation: KEYMAT = K1 | K2 | K3 | ... where K1 = SHA2-512(Kij | Resp-SPI) K2 = SHA2-512(K1 | Resp-SPI) K3 = SHA2-512(K2 | Resp-SPI) etc. In the situation where Kij is the result of a HIP rekey exchange, there is only the need from one set of ESP keys. These are then the only keys taken from Kij. 8.3. Refusing a HIP exchange A HIP aware host may choose not to accept a HIP exchange negotiation. If the host's policy is to only be an initiator, it should begin its own HIP exchange. There is a risk of a race condition if each host's policy is to only be an initiator, at which point the HIP exchange will fail. If the host's policy does not permit it to enter into a HIP exchange with the initiator, it should send an ICMP Host Unreachable, Administratively Prohibited message. A more complex HIP packet is not used here as it actually opens up more potential DOS attacks than a simple ICMP message. 8.4. Reboot restart of HIP If a host reboots or times out, it has lost its HIP state. If it is the initiator that loss state it simply restarts the HIP exchange. The responder sends an R1 HIP packet, but does not reset its state until it receives the I2 HIP packet. This is to handle DOS attacks that simulate a reboot of the initiator. If it is the responder that loss state, the recovery is more involved. The initiator would send an ESP packet, the responder will reply with an ICMP Host unreachable, Protocol unreachable. After the initiator receives N such ICMP messages (default is 5; the Moskowitz 13 Host Identity Payload February 2001 value of N is an initiator policy), the initiator resets its state with the responder and restarts the HIP exchange. Simulating a responder loss of state is a potential denial of service attack. The initiator can manage this attack by dropping any of the above ICMP messages if a responder ESP packet is received within some reasonable delta after it sent its ESP packet. 8.5. Sequence Number State Machine Ioo Initiator at no data packets sent, none received Roo Responder at no data packets sent, none received I1 or R1 Initial HIP packet from Host I2 or R2 Second HIP with data packet from Host IE or RE Data packet from Host with ESP Inm or Rnm host sent packet n, and received packet m +---------+ | Ioo,Roo |<----------------------------+ +---------+ | | | | I1->R | | | v | +---------+ | | Ioo,Roo | | +---------+ | | | | R1->I | | | v | After I receives +---------+ | x ICMPs | Ioo,Roo | | +---------+ | | | | I2->R | | | v | +---------+ I2->R +---------+ | | I1o,Ro1 |<-----------| Ioo,Rmn | | +---------+ +---------+ | | ^ | | R2->I | R1->I | | | | v | | +---------+ +---------+ | | I11,R11 | | Ioo,Rmn | | +---------+ +---------+ | +---------+ | ^ | | Inm,Roo |-+ | ESP | I1->R | +---------+ | Moskowitz 14 Host Identity Payload February 2001 | Packets | | ^ | v I reboots +---------+ | | Iesp->R | Ricmp +---------+ ---------->| Ioo,Rmn | | | | ->I +->| Inm,Rmn | or timeout +---------+ +---------+ | | +---------+ -------------------------->| Inm,Roo |<---+ | | | ^ R reboots +---------+ |NES | | +------+ or timeout |->R |Rrky|Irky | | |->I |->R |NES | | +----+ |->I | v v | +---------+ +---------+ | In1,R1n | | I1m,Rm1 | {rekeying states} +---------+ +---------+ 9. HIP Policies There are a number of variables that will influence the HIP exchanges that each host must support. All HIP implementations MUST support at least 2 HIs, one to publish in DNS and one for anonymous usage. Although anonymous HIs will be rarely used as responder HIs, they will be common for initiators. Support for multiple HIs is recommended. Many initiators would want to use a different HI for different responders. The implementations SHOULD provide for an ACL of initiator HIT to responder HIT. This ACL SHOULD also include preferred transform and local lifetimes. For HITs with HAAs, wildcarding SHOULD be supported. Thus if a Community of Interest, like Banking gets an RAA, a single ACL could be used. A global wildcard would represent the general policy to be used. Policy selection would be from most specific to most general. The value of K used in the HIP R1 packet can also vary by policy. K should never be greater than 8, but for trusted partners it could be as low as 1. Responders would need a similar ACL, representing which hosts they accept HIP exchanges, and the preferred transform and local lifetimes. Wildcarding SHOULD be support supported for this ACL also. 10. Security Considerations HIP is designed to provide secure authentication of hosts and provide a fast key exchange for IPsec ESP. HIP also attempts to limit the exposure of the host to various denial-of-service and man- in-the-middle attacks. In so doing, HIP itself is subject to its own DOS and MITM attacks that potentially could be more damaging to a host's ability to conduct business as usual. Moskowitz 15 Host Identity Payload February 2001 The Security Association for ESP is indexed by the LSI-SPI, not the SPI and IP address. HIP enabled ESP is IP address independent. This might seem to make it easier for an attacker, but ESP with replay protection is already as well protected as possible, and the removal of the IP address as a check should not increase the exposure of ESP to DOS attacks. Denial-of-service attacks take advantage of the cost of start of state for a protocol on the responder compared to the 'cheapness' on the initiator. HIP makes no attempt to increase the cost of the start of state on the initiator, but makes an effort to reduce the cost to the responder. This is done by having the responder start the 3-way cookie exchange instead of the initiator, making the HIP protocol 4 packets long. In doing this, packet 2 becomes a 'stock' packet that the responder MAY use many times. The duration of use is a paranoia versus throughput concern. Using the same Diffie- Hellman values, I and Hash target has some risk. This risk needs to be balanced against a potential storm of HIP I1 packets. This shifting of the start of state cost to the initiator in creating the I2 HIP packet, presents another DOS attack. The attacker spoofs the I1 HIP packet and the responder sends out the R1 HIP packet. This could conceivably tie up the 'initiator' with evaluating the R1 HIP packet, and creating the I2 HIP packet. The defense against this attack is to simply ignore any R1 packet where a corresponding I1 was not sent. A second form of DOS attack is emulating the restart of state after a reboot of one of the partners. To protect against such an attack on the responder, it should send reply to an I1 HIP packet without resetting its state. Only on receipt of an I2 HIP packet within a reasonable delta after sending its R1 HIP packet, should the responder reset its state. An initiator protects itself be ignoring any R1 or R2 packets while it has state with R. A third form of DOS attack is emulating the end of state. HIP has no end of state packet. It relies on a local policy timer to end state. Man-in-the-middle attacks are difficult to defend against, without third-party authentication. A skillful MITM could easily handle all parts of HIP; but HIP indirectly provides the following protection from a MITM attack. If the responder's HI is retrieved from a signed DNS zone by the initiator, the initiator can use this to validate the R1 HIP packet. Likewise, if the initiator's HI is in a secure DNS zone, the responder can retrieve it after it gets the I2 HIP packet and validate that. However, since an initiator may choose to use an anonymous HI, it knowingly risks a MITM attack. The responder may choose not to accept a HIP exchange with an anonymous initiator. Moskowitz 16 Host Identity Payload February 2001 Since not all hosts will ever support HIP, ICMP 'Destination Protocol Unreachable' are to be expected and present a DOS attack. Against an initiator, the attack would look like the responder does not support HIP, but shortly after receiving the ICMP message, the initiator would receive a valid R1 HIP packet. Thus to protect against this attack, an initiator should not react to an ICMP message until a reasonable delta time to get the real responder's R1 HIP packet. A similar attack against the responder is more involved. First an ICMP message is expected if the I1 was a DOS attack and the real owner of the spoofed IP address does not support HIP. The responder SHOULD NOT act on this ICMP message to remove the minimal state from the R1 HIP packet, but wait for either a valid I2 HIP packet or the natural timeout of the R1 HIP packet. This is to allow for a sophisticated attacker that is trying to break up the HIP exchange. Likewise, the initiator should ignore any ICMP message while waiting for an R2 HIP packet, deleting state only after a natural timeout. Another MITM attack is simulating a responder's rejection of a HIP initiation. This is a simple ICMP Host Unreachable, Administratively Prohibited message. A HIP packet was not used because it would either have to have unique content, and thus difficult to generate, resulting in yet another DOS attack, or just as spoofable as the ICMP message. The defense against this MITM attack is for the responder to wait a reasonable time period to get a valid R1 HIP packet. If one does not come, then the Initiator has to assume that the ICMP message is valid. Since this is the only point in the HIP exchange where this ICMP message is appropriate, it can be ignored at any other point in the exchange. 11. IANA Considerations IANA has assigned Protocol number XX to HIP. A new KEY RR protocol of XX is assigned to HIP and an algorithm of XX is assigned to HIT128. IANA will has also assigned new DNS OPT resource record OPTION-CODES of Remotes_HIT [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and Remotes_LSI [x]. 12. ICANN Considerations ICANN are covered in the HIP Architecture [HIPARCH] document. 13. References [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Moskowitz 17 Host Identity Payload February 2001 [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", draft-ietf-moskowitz-hip-arch-02.txt, January 2001. [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", draft-ietf-moskowitz-hip-impl-01.txt, January 2001. [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security Payload", RFC 2406, November 1998. [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [DNS], Mockapetris, P., "Domain Names - Implementation And Specification", RFC 1035, November 1987. [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August 1998. [3DES], Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [HMACSHA1], Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. 14. Acknowledgments The drive to create HIP came to being after attending the MALLOC meeting at IETF 43. Baiju Patel and Hilarie Orman really gave me the assist to get HIP beyond 5 paragraphs of ideas. It has matured considerably since the early drafts thanks to extensive input from IETFers. Most importantly, its design goals are articulated and are different from other efforts in this direction. Particular mention goes to the members of the NameSpace Research Group of the IRTF. Noel Chiappa provided the framework for LSIs and Kieth Moore the impetuous to provide resolvability. Steve Deering provided encouragement to keep working, as a solid proposal can act as a proof of ideas for a research group. Many others contributed; extensive security tips were provided by Steve Bellovin. Rob Austein kept the DNS parts on track. Paul Kocher taught me how to make the cookie exchange expensive for the Initiator to respond, but easy for the Responder to validate. Rodney Thayer and Hugh Daniels provide extensive feedback. John Gilmore kept me challenged to provide something of value. I hope I have. 15. Author's Address Moskowitz 18 Host Identity Payload February 2001 Robert Moskowitz ICSA Labs 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@icsa.net 16. Copyright Statement Copyright (c) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Moskowitz 19