Internet Draft R. Moskowitz, TruSecure Corp. Document: <draft-moskowitz-hip-05.txt> November 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.......................................................3 4.1. Host Identity....................................................3 4.2. Host Identity Tag (HIT)..........................................4 4.2.1. Storing HIT in DNS.............................................5 4.3. Host Assigning Authority (HAA) field.............................5 4.4. Local Scope Identity (LSI).......................................5 4.5. Security Parameter Index (SPI)...................................6 4.6. Difference between an LSI and the SPI............................6 5. The Host Identity Payload..........................................6 5.1. HIP format.......................................................7 5.2. HIP Key Payload..................................................7 5.3. HIP Cookie Exchange..............................................8 5.3.1. HIP Cookie Mechanism...........................................9 5.3.2. HIP Controls...................................................9 5.3.3. HIP Birthday...................................................9 6. HIP Packets.......................................................10 6.1. I1 - the HIP Initiator packet...................................10 6.2. R1 - the HIP Responder packet...................................11 6.2.1. R1 Management.................................................12 6.3. I2 - the HIP Second Initiator packet............................12 Moskowitz 1 Host Identity Payload November 2001 6.4. R2 - the HIP Second Responder packet............................13 6.5. NES - the HIP New SPI Packet....................................14 6.6. REA - the HIP Readdress Packet..................................15 6.7. BOS - the HIP Bootstrap Packet..................................17 6.8. HIP Fragmentation Support.......................................17 7. ESP with HIP......................................................18 7.1. Security Association Management.................................18 7.2. Security Parameters Index (SPI).................................18 7.3. Supported Transforms............................................18 7.4. Sequence Number.................................................19 7.5. ESP usage with non-cryptographic HI.............................19 8. The Host Layer Protocol (HLP) packet flow.........................19 8.1. The Host Layer Protocol (HLP)...................................19 8.2. HLP Scenarios...................................................20 8.3. HIP KEYMAT......................................................20 8.4. Refusing a HLP exchange.........................................21 8.5. Reboot and SA timeout restart of HIP............................21 8.5. HLP State Machine...............................................22 8.5.1. HLP States....................................................22 8.5.2. HLP State Processes...........................................22 8.5.3. Simplified HLP State Diagram..................................23 9. HLP Policies......................................................24 10. Security Considerations..........................................24 11. IANA Considerations..............................................27 12. ICANN Considerations.............................................27 APPENDIX A. Security Transform Formats..............................27 APPENDIX B. Proposed change to the HIP Formats......................28 13. References.......................................................30 14. Acknowledgments..................................................31 15. Author's Address.................................................31 16. Copyright Statement..............................................32 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 Moskowitz 2 Host Identity Payload November 2001 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 provides 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 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. 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 Identity of the Initiator in packet 3. The Responder's Host Identity is not encrypted in packet 2, so it is not included in the encrypted part of packet 4. Data datagrams start after the 4th packet. However, in some cases, the 3rd and 4th HIP packets can carry a datagram. 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.1. Host Identity Moskowitz 3 Host Identity Payload November 2001 The structure of the Host Identity is that of a public key pair. DSA is the MUST implement algorithm for any implementation supporting public keys for the Host Identity. DSA was chosen as the default algorithm due to its small signature size. The Host Identity is never directly used in any Internet protocol. It may be stored in various DNS or LDAP directories as identified in the HIP architecture and it is passed in HIP. It SHOULD be stored in a DNS KEY RR with the protocol set to HIP. A Host Identity Tag (HIT) is used in protocols to represent the Host Identity. Another representation of the Host Identity, the Local Scope Identity (LSI) can also be used in protocols and APIs. LSI's advantage over HIT is its size; its disadvantage is its local scope. 4.2. Host Identity Tag (HIT) The Host Identity Tag is a 128 bit field. There are two advantages of using a hash over the actual Identity in protocols. First its fix length makes for easier protocol coding and also better manages the packet size cost of this technology. Secondly, it presents a consistent format to the protocol whatever underlying identity technology is used. HIT functions much like the SPI does in IPsec. However, instead of being an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for a datagram, HIT identifies the public key that can validate the packet authentication. HIT SHOULD be unique in the whole IP universe. If there is more than one public key for a HIT, the HIT acts as a hint for the correct public key to use. There are two formats for HIT. These two formats are designed to avoid the most commonly occurring IPv6 addresses in RFC 2373 [RFC2372]. Bits 0 and 1 are used to differentiate the formats. If Bit 0 is zero and Bit 1 is one, then the rest of HIT is a 126 bits of a Hash of the key. For example, if the Identity is DSA, these bits MUST be the least significant 126 bits of the SHA-1 [FIPS-180- 1] hash of the DSA public key Host Identity. If Bit 0 is one and Bit 1 is zero, then the next 62 bits is the Host Assigning Authority (HAA) field, and only the last 64 bits come from a SHA-1 hash of the Host Identity. This format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in directories like DNS. Another use of HAA is in policy controls. The birthday paradox sets a bound for the expectation of collisions. It is based on the square root of the number of values. A 64-bit hash, then, would put the chances of a collision at 50-50 with 2^32 hosts (4 billion). A 1% chance of collision would occur in a population of 640M and a .001% collision chance in a 20M population. Moskowitz 4 Host Identity Payload November 2001 A 128 bit hash will have the same .001% collision chance in a 9x10^16 population. Allocation Prefix Fraction of IPv6 (binary) Address Space ------------------------ -------- ------------- IPv6 Address space 00 1/4 126 bit HIT 01 HAA assigned 64 bit HIT 10 IPv6 Address space 11 1/4 4.2.1. Storing HIT in DNS The HIT SHOULD be stored in DNS. The exception to this is anonymous identities. The HIT is stored in a new KEY RR. The HIT KEY RR will have all flags set to ZERO, its protocol set to HIP, and algorithm set to HIT128. The 'public key' field of the HIT KEY RR will be the 128 bit HIT. 4.3. Host Assigning Authority (HAA) field The 62 bits of HAA supports two levels of delegation. The first is a registered assigning authority (RAA). The second is a registered identity (RI, commonly a company). The RAA is 22 bits with values assign sequentially by ICANN. The RI is 40 bits, also assigned sequentially but by the RAA. This can be used to create a resolution mechanism in the DNS. For example if FOO is RAA number 100 and BAR is FOO's 50th registered identity, and if 1385D17FC63961F5 is the hash of the key for www.foo.com, then by using DNS Binary Labels [DNSBIN] there could be a reverse lookup record like: \[x1385D17FC63961F5/64].\[x32/40].\[x64/22].HIT.int IN PTR www.foo.com. 4.4. Local Scope Identity (LSI) LSIs are 32-bit localized representations of a Host Identity. The purpose of an LSI is to facilitate using Host Identities in existing protocols and APIs. The owner of the Host Identity does not set its own LSI; each host selects its partner's 32 bit representation for a Host Identity. LSI assignment is sequential off of a random starting point. That is, at kernel initiation, a random starting point is selected for LSIs, and they are assigned sequentially thereafter. This avoids collisions if LSIs are assigned sequentially starting from zero, and even collisions on a busy host if assigned randomly. The risk of collisions for random assignment is 1% in a population of 10,000. Moskowitz 5 Host Identity Payload November 2001 Examples of how LSIs can be used include: as the address in a FTP command and as the address in a socket call. Thus LSIs act as a bridge for Host Identity into old protocols and APIs. 4.5. Security Parameter Index (SPI) SPIs are used in ESP to index into the security association negotiated in HIP. The ESP SPIs have added significance when used with HIP; they are a compressed representation of the HIT in every packet. Thus they MAY be used by intermediary systems in providing services like address mapping. A system does not set its own SPI; each host selects its partner's SPI. It MUST be random. The risk of collisions is too great (1% in a population of 10,000). A different SPI MUST be used for each HIP exchange with a particular host; this is to avoid a replay attack. Additionally, when a host rekeys, the SPI MUST change. One method for SPI creation that meets these criteria, would be to concatenate the HIT with a 32 bit random number, hash this (using SHA1), and then use the high order 32 bits as the SPI. 4.6. Difference between an LSI and the SPI There is a subtle difference between an LSI and a SPI. The LSI is relatively longed lived. A system selects its peer's LSI and SHOULD reuse a previous LSI for a HIT during a HIP exchange. This COULD be important in a timeout recovery situation. The LSI ONLY appears in the 3rd and 4th HIP packets (each system providing the other with its LSI). The LSI is used anywhere in system processes where IP addresses have traditionally have been used, like in TCBs and FTP port commands. The SPI is short-lived. It changes with each HIP exchange and with a HIP rekey. A system notifies its peer of the SPI to use in ESP packets sent to it. Since the SPI is in all but the first two HIP packets, it can be used in intermediary systems to assist in address remapping. 5. The Host Identity Payload The Host Identity Payload or HIP is IP protocol NN. HIP could 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. Moskowitz 6 Host Identity Payload November 2001 5.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) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HIP Key payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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). 5.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Moskowitz 7 Host Identity Payload November 2001 | | / RDATA / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . 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], A, AAAA, 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_CNTLS variable contains bit-wise controls 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 (Appendix A) Without first 32 bits Using IPsec DOI ESP_TRANSFORM variable ISAKMP Transform (Appendix A) Without first 32 bits Using IPsec DOI Birthday 64 System boot counter Remotes_LSI 32 Remote's LSI Remotes_SPI 32 Remote's SPI Sequence Number 32 Current ESP sequence number ID 64 Name of a network Interface 5.3. 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 Moskowitz 8 Host Identity Payload November 2001 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. 5.3.1. HIP Cookie Mechanism Responder Generates 2 Random Numbers, I and J Challenge = Ltrunc(SHA1(I|J),K) Send I, K, and Challenge in HIP Cookie in R1 Saves I, K, and Challenge for Delta time Initiator Do Until Challenge-response = Challenge Challenge-response = Ltrunc(SHA1(I|Rand),K) EndDo Send I, Rand, and Challenge-response in HIP Cookie in I2 Responder Match Response with Challenge based on I Reject if Challenge-response = Challenge Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K) Accept if Challenge-proof = Challenge 5.3.2. HIP Controls HIP controls are informative items that will influence the HIP exchange and the use of ESP. HIP Controls are assigned a bit location in the HIP_CNTL field numbered left to right. Currently, there are two controls of value to a HIP exchange: BIT Action 0 If value is 1, the HI is anonymous. This control is set in packets R1 and/or I2. The peer receiving an anonymous HI may choose to refuse it by silently dropping the exchange. 1 If value is 1, the ESP transform requires a 64 bit sequence number. See Sequence Number section for processing this control. Various controls will be defined over time. These controls will be added to the end of the HIP_CNTL field so that older implementations can ignore them. 5.3.3. HIP Birthday The Birthday is a reboot count used to manage state reestablishment when one peer rebooted or timed out its SA. The Birthday is increased every time the system boots. The Birthday also has to be Moskowitz 9 Host Identity Payload November 2001 increased in accordance with the system's SA timeout parameter. If the system has open SAs, it MUST increase its Birthday. This impacts a system's approach to precomputing R1 packets. Birthday SHOULD be a counter. It cannot be reset by the user and a system is unlikely to need a birthday larger than 2^64. Date-time in GMT can be used if a cross-boot counter is not possible, but it has a potential problem if the system time is set back by the user. 6. HIP Packets There are 7 HIP packets. Four are for the HIP exchange, two are for mid-state changes (rekeying and address migration), and one is a broadcast for use when there is no IP addressing (e.g. before DHCP exchange). Although HIP is presented to operate above IP, it MAY be used below IP to support MAC layer protocols like DHCP. However, there is no MAC layer relaying mechanism defined like that defined in DHCP. All implementations MUST parse at least the following formats. All implementations MUST recognize additional RR in the HIP envelope but MAY ignore them. Packet representation uses the following operations: () payload x{} operation x on contents <>i repeat () 1 to n times [] optional payload An ESP payload MAY follow some HIP payloads. This transmission optimization SHOULD NOT be used if it results in fragmentation, and there would not be any fragmentation if the ESP payload were sent by itself. 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 IP(HIP(HITr)) 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. Moskowitz 10 Host Identity Payload November 2001 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: HIP CONTROLs in an OPT RR Responder's HI in a KEY RR (e.g. KEY DSA RR) Optional SIG of Responder's HI by a signing authority in a SIG RR Responder's Diffie-Hellman public value in a KEY DH RR Birthday HIP TRANSFORM in an OPT RR ESP TRANSFORM in an OPT RR HIP COOKIE in an OPT RR HIP SIG in a SIG RR IP(HIP(H_CTRL,HIr,[AUTH_SIG,] DHr,BRTHDY,H_TRN,E_TRN,COOKIE1,SIG)) The valid HIP control is the anonymous bit. If the responder has multiple HIs, the HIT used MUST match Initiator's request. The Optional Signature of the Responder's HI by a higher level authority known to the Initiator is an alternative method for the Initiator to trust the Responder's HI (over DNSSEC or PKI). 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 Birthday is a reboot count used to manage state reestablishment when one peer rebooted or timed out its SA. 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 Moskowitz 11 Host Identity Payload November 2001 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. 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.2.1. R1 Management All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the responder. A spoofed I1 can result in an R1 attack on a system. An R1 sender MUST have a mechanism to rate limit R1s to an address. 6.3. I2 - the HIP Second Initiator packet Next Header = 0 or 50 (ESP) Type = 3 HIT = Initiator's HIT Payload Contains: HIP CONTROLs in an OPT RR Responder's HIT in a KEY HIT RR Birthday HIP COOKIE in an OPT 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 an OPT RR The following Resource Records are encrypted using the HIP Transform and are in a HIP ENCRPYT OPT RR ESP TRANSFORM in an OPT RR Initiator's HI in a KEY RR (e.g. KEY DSA RR) Optional SIG of Initiator's HI by a signing authority in a SIG RR HIP SIG in a SIG RR Optional data in an ESP envelope IP(HIP(H_CTRL,HITr,BRTHDY,COOKIE2,LSIr,SPIr,DHi,H_TRN,enc{E_TRN,HIi [,AUTH_SIG]},SIG)[ESP(data)]) The valid HIP controls are the anonymous and 64 bit sequence number bits. If the initiator has multiple HIs, the HI and HIT used MUST match Responder's reply. The Birthday is a reboot count used to manage state reestablishment when one peer rebooted or timed out its SA. Moskowitz 12 Host Identity Payload November 2001 HIP_COOKIE contains I from R1 and random J, and Ltrunc(SHA1(I|J), K) (that is the low order K 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 Diffie-Hellman value is ephemeral. A scavenger process should clean up unused DHs and Js. The HIP_TRANSFORM contains the encryption used to protect the HI exchange selected by the initiator. All implementations MUST support the 3DES transform. The ESP_TRANSFORM, Initiator's HI, and optional SIG on this HI are encrypted using the HIP_TRANSFORM. The keying material is derived from the Diffie-Hellman exchanged as defined later in this document. The ESP_TRANSFORM contains the ESP mode selected by the initiator. All implementations MUST support 3DES-HMAC-SHA-1-96, RFCs 2404 and 2451. The Optional Signature of the Initiator's HI by a higher level authority known to the Responder is an alternative method for the Responder to trust the Initiator's HI (over DNSSEC or PKI). 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. The optional ESP payload contains the first user datagram that the Initiator is sending to the Responder. The SPI is set to NN, as the real Initiator SPI is not know yet be the Initiator. When the Responder processes the HIP payload, it generates the Initiator SPI and replaces NN with this SPI. The Sequence Number SHOULD be set to ONE, as this is the first datagram for this SA. If the ESP transform uses the ESP header for the IV, then special considerations for the ESP header might apply. For example, if the transform requires a random value in the header, expecting it to be the SPI, the Sequence Number can be a random number, and be reset to ONE by the Responder. The Responder would pass the Initiator supplied SPI and Sequence Number to the decryption routine. 6.4. R2 - the HIP Second Responder packet Next Header = 0 or 50 (ESP) Type = 4 HIT = Responder's HIT Payload Contains: HIP CONTROLs in an OPT RR Initiator's LSI in an OPT RR Initiator's SPI in an OPT RR Moskowitz 13 Host Identity Payload November 2001 HIP SIG in a SIG RR Optional data in an ESP envelope IP(HIP(H_CTRL,LSIi,SPIi,SIG)[ESP(data)]) The valid HIP control is the 64 bit sequence number bit. The HIP SIG is calculated over whole HIP envelope. The Initiator MUST validate this SIG. The optional ESP payload contains the first user datagram that the Responder is sending to the Initiator. The SPI is the value within I2. The Sequence Number MUST be set to ONE, as this is the first datagram for this SA. 6.5. NES - the HIP New SPI Packet The HIP New SPI Packet serves three functions. First it provides the peer system with its new SPI. Next it optionally provides a new Diffie-Hellman key to produce new keying material. 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 SPI and D-H OPT RRs in the HIP payload. The HIP packet contains the current ESP Sequence Number and SPI to provide Dos and replay protection. The HIP content is: Next Header = 0 Type = 5 HIT = Sender's HIT Payload Contains: Sender's ESP Sequence Number in an OPT RR Sender's old SPI in an OPT RR Sender's new SPI in an OPT RR Optional Sender's Diffie-Hellman public value in a KEY DH RR HIP SIG in a SIG RR Optional data in an ESP envelope In reply packet only IP(HIP(SEQ,SPIo,SPI[,DH],SIG)[ESP(data)]) During the life of an SA established by HIP, one of the hosts may need to reset the Sequence Number to one (to prevent wrapping) and rekey. The reason for rekeying might be an approaching sequence number wrap in ESP, or a local policy on use of a key. A new SPI or rekeying ends the current SA and starts a new one on both peers. The ESP Sequence Number and current SPI are included to provide replay protection for the receiving peer. This packet MUST NOT be processed until all ESP packets with a lower Sequence Number have Moskowitz 14 Host Identity Payload November 2001 been received and processed, or a reasonable time has elapsed (to account for lost packets). If the Sequence Number is a replay window greater than the current number it MUST be ignored. This packet has a potential Dos attack of a packet within the replay window and proper SPI, but a malformed signature. Implementations MUST recognize when they are under attack and manage the attack. If it is still receiving ESP packets with increasing Sequence Numbers, the HIP new SPI packets are obviously attacks and can be ignored. Intermediate systems that use the SPI will have to inspect ALL HIP packets for a HIP New SPI packet. This is a potential DOS attack against the Intermediate system, as the signature processing may be relatively expensive. A further step against attack for the Intermediate systems is to implement ESP's replay protection of windowing the sequence number. This requires the intermediate system to track ALL ESP packets to follow the Sequence Number. The peer that initiates a New SPI exchange MUST include a Diffie- Hellmen key. Its peer MUST respond with a New SPI packet, an MAY include a Diffie-Hellman key if the receiving system's policy is to increase the new KEYMAT by changing its key pair. When a host receives a New SPI Packet with a Diffie-Hellman, its next ESP packet MUST use the KEYMAT generated by the new Kij. The sending host MUST expect at least a 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. It MAY also include a datagram, using the new SAs. 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 reasonable round trip delta, it MUST assume it or the HIP Rekey packet was lost and MAY resend the HIP New SPI packet or renegotiate HIP as if in a reboot condition. The choice is a local policy decision. 6.6. 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. This readdress packet is NOT intended to provide all of the functionality needed for MobileIPv6, or even a mobile server. This functionality is provided in a separate specification. 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. Moskowitz 15 Host Identity Payload November 2001 The Readdress Packet permits a host to notify its partners of an address change. The Readdress Packet is a HIP packet with at least one pair of A or AAAA RRs 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 contains the current ESP Sequence Number and SPI to provide Dos and replay protection. The HIP content is: Next Header = 0 or 50 (ESP) Type = 6 HIT = Sender's HIT Payload Contains: Sequence number in an OPT RR Current SPI Interface ID in an OPT RR New address in an A or AAAA RR HIP SIG in a SIG RR Optional data in an ESP envelope IP(HIP(SEQ,SPI,<[ID,]<Ao|AAAAo,An|AAAAn>j>i,SIG)[ESP(data)]) The address OPT RRs are always in pairs, the old address and the new address. Multiple addresses can be sent in a single HIP payload. The Interface ID, if included, groups a set of addresses to an interface. The purpose of the Interface ID is to allow a knowledgeable peer to interact with the sender. For example, the sender could be informing its peer that that an interface has both an IPv4 address and one or more IPv6 addresses. The HIP host is free to introduce IDs at will. That is, if a received REA has a new interface ID, it means that all the old addresses are also supposed to still work, while the new addresses in the REA are supposed to be associated with a new interface. On the other hand, if a received REA has an interface ID that the receiver already knows about, it would replace (all) the address(es) currently associated with the interface with the new one(s). The ESP Sequence Number and current SPI are included to provide replay protection for the receiving peer. This packet MUST NOT be processed until all ESP packets with a lower Sequence Number have been received and processed, or a reasonable time has elapsed (to account for lost packets). If the Sequence Number is a replay window greater than the current number it MUST be ignored. This packet has a potential Dos attack of a packet within the replay window and proper SPI, but a malformed signature. Implementations Moskowitz 16 Host Identity Payload November 2001 MUST recognize when they are under attack and manage the attack. If it is still receiving ESP packets with increasing Sequence Numbers, the HIP readdress packets are obviously attacks and can be ignored. Intermediate systems that use the SPI will have to inspect ALL HIP packets for a HIP readdress packet. This is a potential DOS attack against the Intermediate system, as the signature processing may be relatively expensive. A further step against attack for the Intermediate systems is to implement ESP's replay protection of windowing the sequence number. This requires the intermediate system to track ALL ESP packets to follow the Sequence Number. The optional ESP protected datagram allows for efficiency in transmissions. 6.7. BOS - the HIP Bootstrap Packet The HIP content is: Next Header = 0 Type = 10 HIT = Announcer's HIT Payload Contains: Announcer's HIT in a KEY HIT RR Announcer's HI in a KEY RR (e.g. KEY DSA RR) Optional SIG of Announcer's HI by a signing authority in a SIG RR HIP SIG in a SIG RR IP(HIP(HIT,HI,[AUTH_SIG,] SIG))) In some situations, an initiator may not be able to learn of a responder's information from DNS or another repository. Some examples of this are DHCP and NetBios servers. Thus a packet is needed to provide information that would otherwise be gleaned from a repository. This HIP packet is either self-signed in applications like SoHo, or from a trust anchor in large private or public deployments. This packet SHOULD be broadcasted frequently. The Optional Signature of the Announcer's HI by a higher level authority known to the Initiator is an alternative method for the Initiator to trust the Announcer's HI (over DNSSEC or PKI). 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. Moskowitz 17 Host Identity Payload November 2001 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 Association Management An SA is indexed by the 2 SPIs and 2 HITs (both HITs since a system can have more than one HIT). An inactivity timer is recommended for all SAs. If the state dictates the deletion of an SA, a timer is set to allow for any late arriving packets. The SA MUST include the I that created it for replay detection. 7.2. 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.3. 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 18 Host Identity Payload November 2001 7.4. 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 can be changed, that of the rekeying host. However, if one host rekeys, the other host SHOULD rekey as well. In some instances, a 32 bit sequence number is inadequate. In either the I2 or R2 packets, a peer MAY require that a 64 bit sequence number be used. In this case the higher 32 bits are NOT included in the ESP header, but are simply kept local to both peers. 64 bit sequence numbers must only be used for ciphers that will not be open to cryptoanalysis as a result. AES is one such cipher. 7.5. 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. The Host Layer Protocol (HLP) packet flow A Host Layer Protocol (HLP) 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 Host Layer Protocol (HLP) 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) Moskowitz 19 Host Identity Payload November 2001 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. HLP Scenarios No prior state between the two systems. The system with data to send is the Initiator. The process follows standard 4 packet exchange, establishing the SAs. The system with data to send has no state with receiver, but receiver has a residual SA. Intiator acts as in no prior state, sending I1 and getting R1. When Receiver gets I2, the old SA is 'discovered' and deleted; the new SAs are established. System with data to send has an SA, but receiver does not. Receiver 'detects' when it receives an unknown SPI. Receiver sends an R1. Sender gets the R1 with a later birthdate, discards old SA and continues exchange to establish new SAs for sending data. A peer determines that it needs to reset Sequence number or rekey. It sends NES. Receiver sends NES response, establishes new SAs for peers. D-H optional for peer that received the first NES. 8.3. HIP KEYMAT HIP keying material is derived from the Diffie-Hellman Kij produced during the HLP 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 = HMAC-SHA1(Kij | sort(Resp-SPI | Init-SPI) | 1) Moskowitz 20 Host Identity Payload November 2001 K2 = HMAC-SHA1(Kij | K1 | 2) K3 = HMAC-SHA1(Kij | K2 | 3) 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.4. Refusing a HLP exchange A HIP aware host may choose not to accept a HLP exchange. If the host's policy is to only be an initiator, it should begin its own HLP exchange. There is a risk of a race condition if each host's policy is to only be an initiator, at which point the HLP exchange will fail. If the host's policy does not permit it to enter into a HLP 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.5. Reboot and SA timeout restart of HIP Simulating a loss of state is a potential Dos attack. The following process has been crafted to manage state recovery without presenting a Dos opportunity. If a host reboots or times out, it has lost its HLP state. If the system that lost state has a datagram to deliver to its peer, it simply restarts the HLP exchange. The peer sends an R1 HIP packet, but does not reset its state until it receives the I2 HIP packet. The I2 packet MUST have a Birthday greater than the current SA's Birthday. This is to handle DOS attacks that simulate a reboot of a peer. Note that either the original Initiator or the Responder could end up restarting the exchange, becoming the Intitator. An example of the initial Responder needing to send a datagram but not having state occurs when the SAs timed out and a server on the Responder sends a keep-alive to the Initiator. If a system receives an ESP packet for an unknown SPI, the assumption is it lost state and its peer did not. In this case, the system treats the ESP packet like an I1 packet and sends an R1 packet. The system receiving the R1 packet checks the Birthday, if the Birthday is greater than the current SA's Birthday, it processes the R1 packet and resends the ESP packet along with the I2 packet. This will reestablish state between the two peers. [Potential Dos attack if hundreds of peers 'loose' their state and all send R1 packets at once to a server.] Moskowitz 21 Host Identity Payload November 2001 8.5. HLP State Machine HLP has very little state. HLP has three processes: SA establishment, new SPI/rekey, and restart of HLP. In HLP establishment, there is an Initiator and a Responder. Once the SAs are established, this distinction is lost. In new SPI/rekey the Initiator could be either peer. In HLP reestablishment the controlling parameters are which peer still has state and which has a datagram to send to its peer. The following state machine attempts to capture these processes. The state machine is presented in a single system view, representing either an Initiator or a Responder. There is not a complete overlap of processing logic here and in the packet definitions. Both are needed to completely implement HIP and HLP. 8.5.1. HLP States E0 State machine start E1 Initiating HIP E2 Waiting to finish HIP E3 HIP SA established 8.5.2. HLP State Processes +---------+ | E0 | Start state +---------+ Datagram to send, send I1 and go to E1 Receive I1, send R1 and stay at E0 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E0 Receive ESP for unknown SA, send R1 and stay at E0 Receive ANYOTHER, drop and stay at E0 +---------+ | E1 | Initiating HLP +---------+ Receive R1, process if successful, send I2 and go to E2 if fail, go to E-FAILED Receive ANYOTHER, drop and stay at E1 Timeout, up timeout counter If counter is less than N, send I1 and stay at E1 If counter is greater than N, Go to E-FAILED +---------+ | E2 | Waiting to finish HLP Moskowitz 22 Host Identity Payload November 2001 +---------+ Receive R2, process if successful, go to E3 if fail, go to E-FAILED Receive ANYOTHER, drop and stay at E2 +---------+ | E3 | HIP SA established +---------+ Receive NAS, process if successful, send NAS and stay at E3 if failed, stay at E3 Receive REA, process and stay at E3 Receive I1, send R1 and stay at E3 Receive I2, process with Birthday check if successful, send R2, drop old SA and cycle at E3 if fail, stay at E3 Receive R1, process with Birthday check if successful, send I2 with last datagram, drop old SA and go to E2 if fail, stay at E3 Receive ESP for SA, process and stay at E3 Receive R2, drop and stay at E3 8.5.3. Simplified HLP State Diagram Receive packets cause a move to new state +---------+ | E0 |----+ +---------+ | | ^ | | | | | Dgm to | +-+ | send | I1 | | (note ESP- means ESP with unknown SPI) ESP- | | v | +---------+ | | E1 | | +---------+ | | | | R1 | | | I2 v | +---------+ | | E2 |<---|-----+ +---------+ | | | | | | R2 | | | | |R1 Moskowitz 23 Host Identity Payload November 2001 v | | +---------+<---+ | | E3 |----------+ +---------+ | ^ | | +--+ ESP, NAS, REA, I1, I2 9. HLP Policies There are a number of variables that will influence the HLP 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 and HLP are 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, HLP 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. The Security Association for ESP is indexed by the LSI-SPI, not the SPI and IP address. HIP enabled ESP is IP address independent. Moskowitz 24 Host Identity Payload November 2001 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. HLP 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 HLP 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 arrives in the I2 HIP packet. Once and attacking initiator has solved the cookie challenge, it can send packets with spoofed IP source addresses with either invalid encrypted HIP payload component or a bad HIP SIG. This would take resources in the responder's part to reach the point to discover that the I2 packet cannot be completely processed. The defense against this attack is after N bad I2 packets, the responder would discard any I2s that contain the given I. Sort of a shutdown on the attack. The attacker would have to request another R1 and use that to launch a new attack. The responder could up the value of K while under attack. On the downside, valid I2s might get dropped too. A third form of DOS attack is emulating the restart of state after a reboot of one of the partners. To protect against such an attack, a system Birthday is included in the R1 and I2 packets to prove loss of state to a peer. The inclusion of the Birthday creates a very deterministic process for state restart. Any other action is a Dos attack. A fourth 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 Moskowitz 25 Host Identity Payload November 2001 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 HLP exchange with an anonymous initiator. New SPIs and rekeying provide another opportunity for an attacker. Replay protection is included to prevent a system from accepting an old new SPI packet. There is still the opening for an attacker to produce a packet with exactly the right Sequence Number and old SPI with a malformed signature, consuming considerable computing resources. All implementations must design to mitigate this attack. If ESP protected datagrams are still being received; there is an obvious attack. If the peer is quite, it is easier for an attacker to launch this sort of attack, but again, the system should be able to recognize a regular influx of malformed signatures and take some action. There is a similar attack centered on the readdress packet. Similar defense mechanisms are appropriate here. 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 HLP 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. Moskowitz 26 Host Identity Payload November 2001 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]. IANA will assign a SPI of NN for use in the ESP header of the optional I2 HIP packet. 12. ICANN Considerations ICANN will need to set up the HIT.int zone and accredit the registered assigning authorities (RAA) for HAA field. With 21 bits, ICANN can allocate just over 2M registries. APPENDIX A. Security Transform Formats The security transforms, HIP and ESP transforms, use the format from ISAKMP [ISAKMP]. 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | NP = Transform| RESERVED | Payload Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tr1| Transform # 1 | Transform ID | RESERVED2 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | SA Attributes | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | NP = 0 | RESERVED | Payload Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tr2| Transform # 2 | Transform ID | RESERVED2 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | SA Attributes | \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transform Classes Values HIP_ENC 1 ESP_ENC 2 ESP_AUTH 3 HIP Encryption Algorithm Values [IPSEC-REGISTRY] Moskowitz 27 Host Identity Payload November 2001 DES-CBC 1 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6 AES-CBC 7 ESP Encryption Algorithm Value [ISAKMP-REGISTRY] RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_RC4 10 ESP_NULL 11 ESP AES 12 ESP Authenticat Algorithm Value RESERVED 0-1 MD5 2 SHA 3 DES 4 APPENDIX B. Proposed change to the HIP Formats There is a proposed simplification of the HIP payload. It still uses a variable format. The HIP header remains unchanged: 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) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RCOUNT | FQDNLGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Moskowitz 28 Host Identity Payload November 2001 / FQDN / / / | 0 ¡ 3 bytes padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A change, though is if there is no FQDN, FQDNLGTH = 0 instead of '.' This saves 4 bytes. Padding of FQDN is also changed to 32 bit boundry instead of 64 bit. Each HIP Resource Record will be formated as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | RLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / RDATA / / / | 0 ¡ 3 bytes padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Codes are taken from DNS Types: Name Length 1 A 32 24 SIG variable 25 KEY variable 28 AAAA 128 41 OPT variable Only Opt uses Identifier: Name Length 1 HIT 128 2 HIP_CNTLS variable 3 HIP_COOKIE 192 4 HIP_TRANSFORM variable 5 ESP_TRANSFORM variable 6 ENCRYPTED variable 7 BIRTHDAY 64 8 LSI 32 9 SPI 32 10 ID 64 Only I2 uses ENCRYPTED. Encrypted requires a 2-phase parsing. First it is parsed, then decrypted, and then its contents are parsed. There is only one optimization left to consider. That is with HIP_CNTLS. It COULD be put up in the header: Moskowitz 29 Host Identity Payload November 2001 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) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HIP CONTROLS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RCOUNT | FQDNLGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / FQDN / / / | 0 ¡ 3 bytes padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This saves one byte in R1, I2, and R2 and costs a byte in I1, NES, and REA, and any future HIP packet. I am disinclined to do this... 13. References [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", draft-ietf-moskowitz-hip-arch-03.txt, January 2001. [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", draft-ietf-moskowitz-hip-impl-02.txt, January 2001. [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security Payload", RFC 2406, November 1998. [RFC2373], R. Hinden, S. Deering., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) http://csrc.nist.gov/fips/fip180-1.ps (postscript) [DNS], Mockapetris, P., "Domain Names - Implementation And Specification", RFC 1035, November 1987. [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. Moskowitz 30 Host Identity Payload November 2001 [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. [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [IPSEC-REGISTRY], ftp://ftp.isi.edu/in-notes/iana/assignments/ipsec-registry [ISAKMP-REGISTRY], ftp://ftp.isi.edu/in-notes/iana/assignments/isakmp-registry 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. Bill Sommerfeld supplied the Birthday concept to simplify reboot management. 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 Robert Moskowitz TruSecure Corporation 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@trusecure.com Moskowitz 31 Host Identity Payload November 2001 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 32