R. Moskowitz, ICSA, Inc. Internet Draft Document: May 1999 The Host Identity Payload 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. 1. Abstract This memo describes the Host Identity Payload, HIP, which is designed to carry a trustable host identity based on public key cryptography like DSA [FIPS-186]. It can be used to provide the DSA key and parameters for DSS auth [AUTH_DSS] within the IPsec Encapsulating Security Payload [ESP] and the IPsec Authentication Header [AH]. When used with ESP, NULL encryption is assumed except as defined in [HIP_ENC]. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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 Moskowitz 1 The Host Identity Payload May 1999 IP was never designed for a trustless environment. It lacks trustable host identities that can be used in the datagrams to supply various services. The Host Identity Payload or HIP is designed to carry a trustable host identity based on public key cryptography. It can be used to provide datagram authenticity, and provide defense from certain classes of protocol attacks. HIP is not a replacement for IKE [IKE]. HIP is designed to be lightweight in packet, thus latency overhead. Little attempt is made to gain the computational advantage of shared secret over public key cryptography. Some attention has been given to packet size growth caused by HIP. HIP should be used over IKE for low- bandwidth protocols like MALLOC that would benefit from the packet reduction or when public key cryptography becomes very cheap, computationally. HIP and IKE should be viewed as a balanced pair of keying systems that deliver IP authentication and optionally privacy by enabling IPsec. 4. Background With the advent of PPP, IP addresses stopped being effective host identifiers. This loss of identity for IP was further degraded with Private addresses, and DHCP. Additionally, even when an IP address is assigned to a single host interface, there is no assurance to a receiving host that a packet with a given Source IP address really came from that host. Finally, IP addresses are at best an interface label, not a host identity. Thus some protocols exhibit strange to broken behavior on multihomed hosts. The goal of the Host Identity Payload or HIP is to provide for a trustable host identity in every IP datagram. This identity can be used to enable IPsec to provide authenticity and privacy. In fact, HIP MUST be used with IPsec to bind its identity to the datagram. HIP can be NAT friendly if uses ESP. There is nothing in HIP that is tied to an IP address. Of course the ESP payload can have imbedded IP addresses that, since authenticated, cannot be altered by a NAT. 5. 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 | Algorithm # | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Hash (PKH) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Moskowitz 2 The Host Identity Payload May 1999 + HIP Key payload (opt) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AH or ESP followed by IP payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1. HIP Algorithm Number Each HIP algorithm is assigned a number by IANA. The HIP algorithm specifies the public key technology used. Since any HIP algorithm can be used with IPsec, the HIP Algorithm Numbers MUST be identical to corresponding algorithms in the IP Security Domain of Interpretation [DOI]. These are the IPSEC Security Association Attributes in section 4.5 of the DOI. Note that not all of the IPSEC Security Association Attributes can be used with HIP. See the HIP encryption document [HIP_ENC] for producing secret keying material for ESP encryption and keyed attributes. 5.1.1. HIP Algorithms HIP-DSA (Algorithm #s 6) DSA is the MANDITORY to implement algorithm for HIP. With HIP-DSA, the authentication process for AH or ESP consists of a DSS signing of the packet [AUTH_DSS]. The common key length for HIP-DSS is 320 bits, thus its Authentication Data is the same length. This is compared to 96 bits for AH HMAC-SHA1-96 [HMAC-SHA-1-96]. Thus AH or ESP with HIP-DSA is 40 bytes larger than with HMAC-SHA1-96. 5.2. Public Key Hash (PKH) The Public Key Hash (PKH) 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 (AH), uniquely identifies the Security Association for a datagram, the PKH identifies the public key that can validate the packet authentication. The PKH may not be unique in the whole IP universe. If there is more than one public key for a PHK, the PKH acts as a hint for the correct public key to use. The IP source address (when the source address is flagged immutable) can be used to further refine the public key selection method. 64 bits are used for the PKH to allow for enough public keys for the foreseeable future. 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). Moskowitz 3 The Host Identity Payload May 1999 For HIP-DSA, the PKH is derived from the least significant 64 bits of the SHA-1 [FIPS-180] hash of the DSA public key. 5.3. HIP Key Payload The HIP Key Payload is primarily used to carry the public key associated with the PKH. The format of the HIP Key Payload is a DNS message [DNS]. The resource records will either be a NULL or a KEY [DNSSEC] record. NULL RR is used when the hosts have the public keys statically configured, or when the receiving host can be expected to query the DNS for a KEY record. The name in the RR is used as the key to the storage table (required since it is possible to have duplicate PKHs) or for the DNS query. If a DNS query is used to get the KEY record, A SIG record is needed as well to establish the authenticity of the KEY record. KEY RR is used when the receiving host is not expected to have the sending hostĘs public key, nor access to DNS. For HIP-DSA, DSA KEYS [DSA_RR] are used to carry the DSA parameters along with the public key. The full DNS message format is used, not just a single DNS answer format, as multiple RRs may be needed in some cases. 6. IPsec with HIP 6.1. Security Parameters Index (SPI) The SPI for IPsec when used with HIP is assigned by IANA and is a value of 2. The function of the SPI in IPsec has been subsumed by the PKH. This does result in a per host-pair SPI, and a decrease of policy granularity over other KMPs like IKE. 6.2. Sequence Number The Sequence Number field is MANDATORY for the sender and provides replay and clogging protection. Processing the Sequence Number is OPTIONAL for the receiver. The Sequence Number is used in Replay protection. This unsigned 32-bit field contains a monotonically increasing counter value. Since AH or ESP with HIP does not use a KMP to create a SPI, the Sequence Number cannot be reset to zero with each KMP negotiation. The following ęcoarse timerĘ method is to be used for setting or re-setting the sequence number to an initial value. Moskowitz 4 The Host Identity Payload May 1999 Each host MUST maintain a Host Peer State entry. Each is identified by the peer's PKH. Until the PKH is obtained, the peer's IP address MAY be used. Since there can be duplicate PKHs, the best approach would be to use BOTH the IP address and the PKH. The two fields in this table are: Sender Sequence Number and Receiver Sequence Number. When a host is sending its first packet to a host, or receives the first packet to a host, these fields are set to ZERO. The first packet from a host has its Sequence Number set by the following procedure. AND 55555555 with the system time represented as a 32 bit value. This will allow for at least 2,863,311,530 packets (in the year 2036) before Sequence Number reset. This algorithm ensures a large number of packets before rekeying for any start date for the system 32 bit timer. If the receiving peerĘs Receiver Sequence Number is ZERO the following check is performed on the Sequence Number. The two numbers that are plus and minus N seconds from the receiverĘs system time represented as a 32 bit value are ANDed with 55555555. If the Sequence Number is between these two numbers, this packet is a valid start of state. The receiving peer sets its Receiver Sequence Number to the value in the packet. Otherwise it can be assumed that the receiver had rebooted, and the sender had historical state with the receiver. The receiver sends an authenticated ICMP Parameter Problem (Type 12) packet (Pointer to the Sequence NumberĘs first octet) to force the sender to reinitialize its Sequence Number and resend the packet. Note that since the systems are out of sync, the receiver is also setting its SenderĘs Sequence Number to initial state, so the ICMP message is a start of state as described above so there is no race condition on constructing the HIP authenticated ICMP message. The choice of AH or ESP for the ICMP message is a local host decision. The smaller the value of N, the harder it is to launch a replay attack, the default for N is 600 seconds, or 10 minutes. This value can be made much smaller, particularly if both systems are using NTP. However, it should not be made so small that network latency results in the appearance of a replay attack. If the Sequence Number is not within the IPsec replay window, the above range check is made. If the value is outside of the range, it can be considered a replay attack. Otherwise the assumption is the sender is restarting state, either because it rebooted, or the Sequence Number had reached 2^32-1 and the Sequence Number had to be reset to avoid rollover. Moskowitz 5 The Host Identity Payload May 1999 If a host has not sent or received a packet for a peer host for a set period of time, the Sequence Numbers are reset to ZERO. The Quite Time Period is a matter of local policy. It can be set on a per peer level. The recommended default value is 15 minutes. Hosts have to handle Sequence Number rollover after 2^32 packets. For peer initialization efficiency and to reduce the impact of random clogging, the sending system MUST identify start of state by including a HIP Key Payload as follows whenever the Sequence Number is set based on the above time algorithm. The HIP Key Payload MUST contain the senderĘs public key and appropriate parameter values. The format of the HIP Key Payload SHOULD be that of the DNS KEY RR [RFC 2065]. With this information, the receiver MUST be able to authenticate the packet without any additional information. The receiver MAY still perform any lookup based on the PKH that is necessary. 6.3. Sequence Number State Machine Ioo Initiator at no packets sent, none received Roo Responder at no packets sent, none received It or Rt Initial packet from Host Inm or Rnm host sent packet n, and received packet m +---------+ | Ioo,Roo | +---------+ | | It->R | v +---------+ +---------+ +---| Iot,Rto | | Ito,Rot |<--------------+ | +---------+ +---------+ | | ^ | | | | R retransmits | Rt->I +---------|---+ | with init seq# | | | | v | It->R | +---------+ +---------+ | | | Ioo,Roo | | Itt,Rtt |<----+ | +---------+ +---------+ | ^ | | | | | It->R | Rm+1 -> I | more packets | Forces R | I detects | | to reset | seq# error | | state | Sends ICMP error | | | Moskowitz 6 The Host Identity Payload May 1999 | | | v | | +---------+ I reboots +---------+ | | Inm,Rnm |---------->| Ioo,Rnm |------+ +---------+ +---------+ | | quite | n minutes v +---------+ | Ioo,Roo | +---------+ 7. Security Considerations Since the public keys in HIP will potentially be used in billions of signature operations, there might be a potential to brute-strength attack the public key. The maximum length public key possible, weighed against packet length (length of signature) and performance, should be used. 7.1. Changes to the ICV for AH and ESP with HIP For the Integrity Check Value Calculation in AH and ESP, HIP is treated as immutable in transit and MUST be included in the ICV. Without this, at substitution attack is possible against HIP. 8. IANA Considerations The IANA will assign a value of 2 for IPsec with HIP. Also each algorithm will be assigned a value by the IANA. This assignment is actually done in the DOI for IKE, and HIP uses those Security Authentication numbers that are appropriate for it. 9. References [ESP], Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. [AH], Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 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) [FIPS-186], US National Bureau of Standards, "Digital Signature Standard (DSS)", Federal Information Processing Standard (FIPS) Publication 186, May 1994, http://www.itl.nist.gov/div897/pubs/fip186.htm. Moskowitz 7 The Host Identity Payload May 1999 [Thayer97a], Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [HMAC-SHA-1-96], Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC 2404, November 1998. [DOI], Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [AUTH_DSS], Moskowitz, R., "The Use of DSS within ESP and AH", draft-ietf-moskowitz-auth-dss-00.txt, May 1999. [HIP_ENC], Moskowitz, R., "ESP Encryption support in HIP", draft- ietf-moskowitz-HIP-ENC-00.txt, May 1999. [DNS], Mockapetris, P., "Domain Names - Implementation And Specification", RFC 1035, November 1987. [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [DSA_RR], Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. 10. Acknowledgments The drive to create HIP came to being after attending the MALLOC meeting at IETF 43. It is distilled from many conversations from the IPsec mailing list and the IPsec workshops. Particularly Rodney Thayer should be mentioned for giving this protocol its initial push. Steve Bellovin assisted on some of the public key and replay concerns. Baiju Patel and Hilarie Orman gave extensive comments on the intial format, resulting in the present document. Hugh Daniels and IPsec implementers have kept after me to see that HIP moved beyond concept to spec. 11. Author's Addresses Robert Moskowitz ICSA, Inc. 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@icsa.net Moskowitz 8