R. Moskowitz, ICSA.net Internet Draft Document: <draft-moskowitz-hip-arch-00.txt> Dec 1999 Host Identity Payload Architecture 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 reasoning behind proposing a new namespace, the Host Identity, and a payload, between the Internetworking and Transport layers, to carry this identity. Herein is presented the basics of the current namespaces, strengths and weaknesses, and how a new namespace will add completeness to them. This new namespace's roles in the protocols are defined. This document provides the details of this namespace and protocol. 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 Internet has created two namespaces: Internet Protocol (IP) addresses, and Domain Name Services (DNS) names. These two namespaces have a set of features and abstractions that have powered the Internet to what it is today. They also have a number of Moskowitz 1 Host Identity Payload Architecture December 1999 weaknesses. IP addresses define an interface, not a host and not every host has one permanently, so they cannot reliably be used for host authentication systems. Few systems on the Internet have DNS names. DNS names are also only indirect references to IP addresses, though this changes in part with DNSSEC and KEY records. Although each namespace can be stretched (IP with v6, DNS with KEY records), neither can adequately provide for host authentication or act as a separation between Internetworking and Transport layers. 4. Background The Internet is built from three principle components: Computing platforms, Packet transport infrastructure, and Services (applications). The Internet exists to service two principle components: People and Robotic processes (silicon based people, if you will). All these components need to be named in order to interact in a scalable manner. There are three principle namespaces in use in the Internet for these components: IP numbers, Domain Names, and Email addresses. IP addresses provide naming for the Transport Infrastructure interfaces on computing platforms. IP addresses assignments are centrally controlled and delegated in blocks. There is little anonymity in IP addresses. IPv4 addresses provide a unique (non- singular sometimes), but non-global names. IPv6 addresses MAY provide globally-unique (non singular regularly?) names. Most IP address assignment is transient, making IP addresses an unreliable namespace outside of packet delivery. Domain Names provide hierarchically assigned names for some computing platforms and some services. Each hierarchy is delegated from the level above; there is no anonymity in Domain Names. Email addresses provide naming for both carbon and silicon based people. Email addresses are extensions of Domain Names, only in so far as a named service is responsible for managing a person's mail. There is some anonymity in Email addresses. There are three critical deficiencies with the current namespaces. Computing platforms are not well named with the current namespaces. Anonymity is not provided in a consistent, trustable manner. And authentication is not provided. A namespace for computing platforms can be used in end-to-end operations independent of the evolution of the internetworking layer and across the many transport layers. If this namespace is cryptographically based, it can also provide authentication services. If this namespace is locally created without requiring registration, it can provide anonymity. Moskowitz 2 Host Identity Payload Architecture December 1999 Such a namespace (for computing platforms) should have the following characteristics: It is applied to the IP 'kernel'. The IP kernel is the 'component' between services and the packet transport infrastructure. It should not mandate any infrastructure. Deployment must come from the bottom up, in a pairwise deployment. It should be fixed length. For easy inclusion in datagrams. It MUST be statistically globally unique. 64 bits is inadequate (1% chance of collision in a population of 640M); thus approximately 128 bits should be used. It SHOULD be locally created. This can provide anonymity at the cost of making resolvability is very difficult. Sometimes it MAY contain a delegation component. This is the cost of resolvability. It SHOULD provide authentication services. This is a preferred function. It should be long lived, but replaceable at any time. This impacts access control lists; short lifetimes will tend to result in tedious list maintenance or require a namespace infrastructure for central control of access lists. It should be affordable when used in protocols. This is primarily a packet size issue. It should fully decouple the Internetworking layer from the higher layers. It should replace all occurrences of IP addresses within applications. This may require API changes. It should have a localized abstraction so that it can be used in existing protocols and APIs. This new namespace will be called the Host Identity. It will require its own protocol layer (the Host Identity Payload), between the Internetworking and Transport layers. It will be based on Public Key Cryptography to supply authentication services. Properly designed, it can deliver all of the above stated requirements. 5. Host Identity The Host Identity represents a statistically globally unique name for naming any system with an IP stack. This identity is normally Moskowitz 3 Host Identity Payload Architecture December 1999 associated with an IP stack. A system can have multiple identities, some 'well known', some anonymous. A system may self assert its identity, or may use a third-party authenticator like DNSSEC, PGP, or X.509 to 'notarize' the identity assertion. Host Identity adds two main features to Internet protocols. The first is a decoupling of the internetworking and transport layers. This decoupling will allow for independent evolution of the two layers. Additionally it can provide end-to-end services over multiple internetworking realms. The second feature is host authentication. If the Host Identity is a public key, this key can be used to authenticate security protocols like IPsec. The preferred 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. Any other Internet naming convention MAY be used for the Host Identity. However, these should only be used in situations of high trust - low risk. That is any place where host authentication is not needed (no risk of host spoofing) and no use of IPsec. 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 the HIP payload. If the Host Identity is a public key, it SHOULD be stored in a DNS KEY RR with the protocol set to HIP. A Host Identity Global Hash (HIGH) is used in protocols to represent the Host Identity. Another representation of the Host Identity, the Endpoint Selector (ESEL) can also be used in protocols and APIs. ESEL's advantage over HIGH is its size; its disadvantage is its local scope. 5.1. Host Identity Global Hash (HIGH) The Host Identity Global Hash 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. When the Host Identity is a public key, HIGH 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, HIGH identifies the public key that can validate the packet authentication. HIGH SHOULD be unique in the whole IP universe. If there is more than one public key for a HIGH, the HIGH acts as a hint for the correct public key to use. There are two formats for HIGH. Bit 0 is used to differentiate the formats. If Bit 0 is zero, then the rest of HIGH is a 127 bits of a Hash of the key. For example, if the Identity is DSA, these bits Moskowitz 4 Host Identity Payload Architecture December 1999 are the least significant 127 bits of the SHA-1 [FIPS-180-1] hash of the DSA public key Host Identity. If Bit 0 is one, then the next 63 bits is the Host Assigning Authority field, and only the last 64 bits come from a hash of the Host Identity. This format for HIGH is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in directories like DNS. 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. A 128 bit hash will have the same .001% collision chance in a 9x10^16 population. 5.1.1. Storing HIGH in DNS The HIGH SHOULD be stored in DNS. The exception to this is anonymous identities. The HIGH is stored in a new KEY RR. The HIGH KEY RR will have all flags set to ZERO, its protocol set to HIP, and algorithm set to HIGH128. The 'public key' field of the HIGH KEY RR will be the 128 bit HIGH. 5.2. Host Assigning Authority (HAA) field The 63 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 23 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].50.100.high.int IN PTR www.foo.com. 5.3. Endpoint Selector (ESEL) ESELs are 32 bit localized representations of a Host Identity. The purpose of an ESEL is to facilitate using Host Identities in existing protocols and APIs. Each host selects its own 32 bit representation for a Host Identity. It SHOULD be random, it COULD be sequential if security systems will not be relying on it. The owner of the Host Identity does not set its ESEL; the risk of collisions is too great (1% in a population of 10,000). Since the Moskowitz 5 Host Identity Payload Architecture December 1999 ESEL only has meaning to the host, its generation is a local policy issue. Examples of how ESELs can be used include: as the SPI in IPsec, as the destination IP address inside a IP tunnel, as the address in a FTP command, and as the address in a socket call. Thus ESELs act both as a bridge for Host Identity into old protocols and APIs and a packet compression mechanism for Host Identity in general. 5.4. Using ESELs in place of IP addresses ESELs can be used in place of IP addresses in socket calls. This can be accommodated with the aid of a modified resolver module. When a HIP exchange produces, and exchanges the ESELs, either the ESEL can be provided to the applications in place of the IP addresses and then the HIP module perform any substitution required, or the HIP module can intercept all address requests and use the ESEL where appropriate. At issue here is when do applications get IP addresses, and where do they use them. The ESELs are not established until the 3rd and 4th HIP packets, which may be too late for some applications. If the applications are using IP addresses within their data stream (as FTP commands do), the HIP module will have to perform tasks similar to a NAT to find these addresses and replace them with the appropriate ESEL. If the applications are using ESELs (as could be the case on subsequent connections during the lifetime of the HIP state), then the HIP module directs opens to ESELs to the appropriate IP address. The HIP module would not need to perform NAT functions on imbedded IP addresses. 6. Using the Host Identity There are a number of ways that Host Identity can be used in Internet Protocols. The first is to use it in IKE [IKE]. HIGH can be used in Main Mode. For this, the Host Identity MUST be a Public Key, and an appropriate Main Mode authentication (e.g. DSA signature) used. The ESEL of the HIGH can replace the usage of IP addresses in IKE. An appropriate ISAKMP [ISAKMP] payload will be needed to accommodate the Host Identity and HIGH. These additions to IKE would produce a mode of operation for IKE that could traverse a NAT. This, coupled with ESP transport mode, would produce a NAT friendly IPsec mode (note that the NATs can alter none of the data within the ESP). Another, and perhaps more powerful mode is a new, lightweight, protocol that will allow for one host to convey its Host Identity to another host. This Host Identity Protocol will enable two hosts to exchange Host Identity and related information and rapidly establish Moskowitz 6 Host Identity Payload Architecture December 1999 an ESP Security Association. It will lack the fine-grain controls of IKE and some of IKE's security features (like identity protection). 7. The Host Identity Payload The goal of the Host Identity Payload or HIP is to provide for a host identity, in most cases a trustable identity, in every IP datagram (see below for HIP packet compression). This identity can be used to enable IPsec to provide authenticity and privacy. HIP can supply the Host Identity for NAT state functions. HIP can be used as an alternative to IKE when fine-grain controls are not needed. In fact, HIP SHOULD be used with IPsec to bind its identity to the datagram. HIP can make protocols like IPsec's ESP NAT friendly. 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. 7.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 | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Identity Global Hash (HIGH) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HIP Key payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP followed by IP payload (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2. HIP Key Payload The HIP Key Payload is used to carry the public key associated with the HIGH and related security information. The format of the HIP Key Payload is a simplification of a DNS message [DNS]. Since only the answer portion of a message is needed, the payload consists of ANCOUNT field of the message header followed by the indicated number of resource records. The resource records will either be a KEY (e.g. DSA and D-H), SIG [DNSSEC], or OPT [EDNS] record. The first resource record in the Moskowitz 7 Host Identity Payload Architecture December 1999 HIP payload will contain the host's FQDN, if it has one, otherwise this field will be null. All other resource records for the host will use message compression. The RDATA of the OPT record in the payload can contain any of the following: OPT Attribute Length Data Remotes_HIGH 128 Remote's HIGH HIP_COOKIE 192 3 64 bit fields: Random #, either I or J SHA1(random#, I) truncated F(I,J) (zero in 1st 2 cookies) HIP_TRANSFORM variable ISAKMP Transform [ISAKMP] Without first 32 bits Using Ipsec DOI Remotes_ESEL 32 Remote's ESEL 7.3. HIP Rekey Payload During the life of an Security Association established by HIP, one of the hosts may need to rekey. The reason for rekeying might be a sequence number rap in ESP, or a local policy on use of a key. The Rekey Payload permits a host to change its Diffie-Hellman key and thus the keying material for ESP. The Rekey Payload 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 of the rekeying; there is no next protocol in the HIP packet. Thus the datagram looks like: IP[ESP[HIP(D-H)]] When a host receives a Rekey Payload, its 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 Kij. Once past the rekeying start, the sending host can drop the old Kij. 8. HIP Scenarios There are a number of scenarios for using HIP. The variables in these scenarios are the number of address realms (managed by NATs) and the jurisdictional location of the boundaries, and the type of Host Identity (public key or string like an FQDN). 8.1. HIP Scenario #1 Initiator and Responder in common addressing realm (i.e. both public or both private). Moskowitz 8 Host Identity Payload Architecture December 1999 Initiator gets IP address of Responder somehow. Hard coded (bad) DNS lookup DNSSEC important A HIP aware client should always retrieve HIP records too. The default DNS records would be a DSA and HIGH KEY RR with protocol of HIP. This is important for the Initiator to validate packet #3. I --> DNS (lookup R) I <-- DNS (R's info) I --> R (Hi, let's talk HIP) I <-- R (OK, handle this HIP cookie) I --> R (Compute, compute, here is my counter HIP with ESP protected data) I <-- R (OK, LetÆs finish HIP cookie, and here is my ESP protected data) Initiator sends first packet with HIP HIP Includes: HIGH, [Responder's HIGH (from DNS query)] Next protocol = 0 Responder sends first packet with HIP HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG If multiple HI, match Initiator's request HIP_COOKIE contains random I I is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Is HIP_TRANSFORM contains the ESP modes supported by the responder SIG calculated over whole HIP Next protocol = 0 Must keep state on I and DH pair. Can reduce costs in event of a DOS attack by using the same DH for a number of connects over some time. Additionally, the same I might be used if a large number of attempts come from different addresses in a short time (classic DOS attack). Initiator must validate the HIP SIG, minimally with included HI. If HI is received during initial DNS query, this should be used. Initiator sends second packet with HIP HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG HIP_COOKIE contains random J and Hash(current_secret, I). J is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Js The ESEL will become the ESP SPI HIP_TRANSFORM contains selected ESP algorithms Moskowitz 9 Host Identity Payload Architecture December 1999 SIG calculated over whole HIP Next Protocol is ESP Optional encryption and mandatory auth Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 SPI is the Responder's ESEL of the Initiator, but don't have ESEL yet, so 1st packet uses SPI = Random # ESP payload is first data gram Must keep state of I, J, DH pair, and Responder's DH, ESEL and ESP TRANSFORM used. Responder sends second, and last, packet with HIP HIP Includes: HIP_COOKIE, Initiator ESEL and SIG The ESEL will become the ESP SPI HIP_COOKIE contains random I, Hash(current_secret, I), and F(I,J) Next Protocol is ESP SPI is the Initiator's ESEL of the Responder ESP payload is data gram Must keep state of DH pair, and Initiator's DH, ESEL and ESP TRANSFORM used. All further packets are without HIP, HIP is implied with the SPIs = ESELs --> HIGH 8.2. HIP Scenario #2 Initiator behind NAT, Responder publicly addressed. Initiator gets IP address of Responder somehow. Hard coded (bad) DNS lookup DNSSEC important A HIP aware client should always retrieve HIP records too. The default DNS records would be a DSA and HIGH KEY RR with protocol of HIP. This is important for the Initiator to validate packet #3. If no default route to NAT, DNS ALG provides NAT with Responder's IP address and HIGH; NAT provides DNS ALG with substitute internal address. I --> NAT(I) --> DNS (lookup R) I <-- NAT(I) <-- DNS (R's info, record it in NAT) I --> NAT(I) --> R (Hi, let's talk HIP) I <-- NAT(I) <-- R (OK, handle this HIP cookie) I --> NAT(I) --> R (Compute, compute, here is my counter HIP with ESEL(R) and ESP protected data) Moskowitz 10 Host Identity Payload Architecture December 1999 I <-- NAT(I) <-- R (OK, LetÆs finish HIP cookie, and here is ESEL(I) and my ESP protected data) Initiator sends first packet with HIP HIP Includes: HIGH, [Responder's HIGH (from DNS query)] Next protocol = 0 NAT records Initiator's HIGH and address makes address changes in IP header Responder sends first packet with HIP HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG If multiple HI, match Initiator's request HIP_COOKIE contains random I I is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Is HIP_TRANSFORM contains the ESP modes supported by the responder SIG calculated over whole HIP Next protocol = 0 Must keep state on I and DH pair. Can reduce costs in event of a DOS attack by using the same DH for a number of connects over some time. Additionally, the same I might be used if a large number of attempts come from different addresses in a short time (classic DOS attack). Initiator must validate the HIP SIG, minimally with included HI. If HI is received during initial DNS query, this should be used. NAT changes addresses based on HIGHs in HIP. Initiator sends second packet with HIP HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG HIP_COOKIE contains random J and Hash(current_secret, I). J is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Js The ESEL will become the ESP SPI HIP_TRANSFORM contains selected ESP algorithms SIG calculated over whole HIP Next Protocol is ESP Optional encryption and mandatory auth Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 SPI is the Responder's ESEL of the Initiator, but don't have ESEL yet, so 1st packet uses SPI = Random # ESP payload is first data gram Must keep state of I, J, DH pair, and Responder's DH, ESEL and ESP TRANSFORM used. NAT adds Initiator's Responder ESEL to I/R state and changes addresses. Moskowitz 11 Host Identity Payload Architecture December 1999 Responder sends second, and last, packet with HIP HIP Includes: HIP_COOKIE, Initiator ESEL and SIG The ESEL will become the ESP SPI HIP_COOKIE contains random I, Hash(current_secret, I), and F(I,J) Next Protocol is ESP SPI is the Initiator's ESEL of the Responder ESP payload is data gram Must keep state of DH pair, and Initiator's DH, ESEL and ESP TRANSFORM used. NAT adds Responder's Initiator ESEL to I/R state and changes addresses. All further packets are without HIP, HIP is implied with the SPIs = ESELs --> HIGH NAT uses ESELs for address state. Hosts use ESELs in place of IP addresses inside protocols. E.G. Initiator uses Responder's Initiator ESEL (packet 4) for FTP port command. Responder is able to remap this to state it has on Initiator. 8.3. HIP Scenario #3 Initiator publicly addressed, Responder behind NAT. NAT configured with Responder's IP address and HIGH. DNS for the responder will have the NAT's address. Initiator gets IP address of Responder (NAT) somehow. Hard coded (bad) DNS lookup DNSSEC important A HIP aware client should always retrieve HIP records too. The default DNS records would be a DSA and HIGH KEY RR with protocol of HIP. This is important for the Initiator to validate packet #3. If no default route to NAT, NAT maps Initiator's HIGH and ESEL to an internal address. Since the ESEL has to be used after HIP exchange, and ESEL is on a host basis, the Initiator will use a separate internal address for each internal host. I --> DNS (lookup R, get NAT's address and R's HIGH) I <-- DNS (R's info) I --> NAT(R) --> R (Hi, let's talk HIP) I <-- NAT(R) <-- R (OK, handle this HIP cookie) Moskowitz 12 Host Identity Payload Architecture December 1999 I --> NAT(R) --> R (Compute, compute, here is my counter HIP with ESEL(R) and ESP protected data) I <-- NAT(R) <-- R (OK, LetÆs finish HIP cookie, and here is ESEL(I) and my ESP protected data) Initiator sends first packet with HIP HIP Includes: HIGH, Responder's HIGH (from DNS query) Next protocol = 0 NAT records Initiator's HIGH and address makes address changes in IP header. Uses Responder's HIGH to map to responder. Responder sends first packet with HIP HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG If multiple HI, match Initiator's request HIP_COOKIE contains random I I is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Is HIP_TRANSFORM contains the ESP modes supported by the responder SIG calculated over whole HIP Next protocol = 0 Must keep state on I and DH pair. Can reduce costs in event of a DOS attack by using the same DH for a number of connects over some time. Additionally, the same I might be used if a large number of attempts come from different addresses in a short time (classic DOS attack). Initiator must validate the HIP SIG, minimally with included HI. If HI is received during initial DNS query, this should be used. NAT changes addresses based on HIGHs in HIP. Initiator sends second packet with HIP HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG HIP_COOKIE contains random J and Hash(current_secret, I). J is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Js The ESEL will become the ESP SPI HIP_TRANSFORM contains selected ESP algorithms SIG calculated over whole HIP Next Protocol is ESP Optional encryption and mandatory auth Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 SPI is the Responder's ESEL of the Initiator, but don't have ESEL yet, so 1st packet uses SPI = Random # ESP payload is first data gram Moskowitz 13 Host Identity Payload Architecture December 1999 Must keep state of I, J, DH pair, and Responder's DH, ESEL and ESP TRANSFORM used. NAT adds Initiator's Responder ESEL to I/R state and changes addresses. The NAT will have one responder HIGH to address state, but potentially many responder ESEL to address state. Responder sends second, and last, packet with HIP HIP Includes: HIP_COOKIE, Initiator ESEL and SIG The ESEL will become the ESP SPI HIP_COOKIE contains random I, Hash(current_secret, I), and F(I,J) Next Protocol is ESP SPI is the Initiator's ESEL of the Responder ESP payload is data gram Must keep state of DH pair, and Initiator's DH, ESEL and ESP TRANSFORM used. NAT adds Responder's Initiator ESEL to I/R state and changes addresses. All further packets are without HIP, HIP is implied with the SPIs = ESELs --> HIGH NAT uses ESELs for address state. Hosts use ESELs in place of IP addresses inside protocols. E.G. Initiator uses Responder's Initiator ESEL (packet 4) for FTP port command. Responder is able to remap this to state it has on Initiator. 8.4. HIP Scenario #4 Initiator and Responder behind separate NATs. NAT configured with Responder's IP address and HIGH. DNS for the responder will have the NAT's address. Initiator gets IP address of Responder (NAT) somehow. Hard coded (bad) DNS lookup DNSSEC important A HIP aware client should always retrieve HIP records too. The default DNS records would be a DSA and HIGH KEY RR with protocol of HIP. This is important for the Initiator to validate packet #3. If no default route to initiator's NAT, DNS ALG provides NAT with Responder's IP address and HIGH; NAT provides DNS ALG with substitute internal address. If no default route to responder's NAT, NAT maps Initiator's HIGH and ESEL to an internal address. Since the ESEL has to be used after Moskowitz 14 Host Identity Payload Architecture December 1999 HIP exchange, and ESEL is on a host basis, the Initiator will use a separate internal address for each internal host. I --> NAT(I) --> DNS (lookup R, get NAT's address and R's HIGH) I <-- NAT(I) <-- DNS (R's info, record it in NAT) I --> NAT(I) --> NAT(R) --> R (Hi, let's talk HIP) I <-- NAT(I) <-- NAT(R) <-- R (OK, handle this HIP cookie) I --> NAT(I) --> NAT(R) --> R (Compute, compute, here is my counter HIP with ESEL(R) and ESP protected data) I <-- NAT(I) <-- NAT(R) <-- R (OK, LetÆs finish HIP cookie, and here is ESEL(I) and my ESP protected data) Initiator sends first packet with HIP HIP Includes: HIGH, Responder's HIGH (from DNS query) Next protocol = 0 Initiator's NAT records Initiator's HIGH and address makes address changes in IP header Responder's NAT records Initiator's HIGH and address makes address changes in IP header. Uses Responder's HIGH to map to responder. Responder sends first packet with HIP HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG If multiple HI, match Initiator's request HIP_COOKIE contains random I I is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Is HIP_TRANSFORM contains the ESP modes supported by the responder SIG calculated over whole HIP Next protocol = 0 Must keep state on I and DH pair. Can reduce costs in event of a DOS attack by using the same DH for a number of connects over some time. Additionally, the same I might be used if a large number of attempts come from different addresses in a short time (classic DOS attack). Initiator must validate the HIP SIG, minimally with included HI. If HI is received during initial DNS query, this should be used. Both NATs changes addresses based on HIGHs in HIP. Initiator sends second packet with HIP HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, HIP_TRANSFORM, and SIG HIP_COOKIE contains random J and Hash(current_secret, I). J is internal pointer to DH HIP_DH is ephemeral, but can be reused Scavenger cleans up unused DHs and Js The ESEL will become the ESP SPI HIP_TRANSFORM contains selected ESP algorithms Moskowitz 15 Host Identity Payload Architecture December 1999 SIG calculated over whole HIP Next Protocol is ESP Optional encryption and mandatory auth Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 SPI is the Responder's ESEL of the Initiator, but don't have ESEL yet, so 1st packet uses SPI = Random # ESP payload is first data gram Must keep state of I, J, DH pair, and Responder's DH, ESEL and ESP TRANSFORM used. Initiator's NAT adds Initiator's Responder ESEL to I/R state and changes addresses. Responder's NAT adds Initiator's Responder ESEL to I/R state and changes addresses. The NAT will have one responder HIGH to address state, but potentially many responder ESEL to address state. Responder sends second, and last, packet with HIP HIP Includes: HIP_COOKIE, Initiator ESEL and SIG The ESEL will become the ESP SPI HIP_COOKIE contains random I, Hash(current_secret, I), and F(I,J) Next Protocol is ESP SPI is the Initiator's ESEL of the Responder ESP payload is data gram Must keep state of DH pair, and Initiator's DH, ESEL and ESP TRANSFORM used. NAT adds Responder's Initiator ESEL to I/R state and changes addresses. All further packets are without HIP, HIP is implied with the SPIs = ESELs --> HIGH Both NATs uses ESELs for address state. Hosts use ESELs in place of IP addresses inside protocols. E.G. Initiator uses Responder's Initiator ESEL (packet 4) for FTP port command. Responder is able to remap this to state it has on Initiator. 8.5. 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 Moskowitz 16 Host Identity Payload Architecture December 1999 not used here as it actually opens up more potential DOS attacks than a simple ICMP message. 9. 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 information that is 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 HIGH and ESEL. Thus a host can easily change its address using Mobile IP, DHCP, or PPP and still maintain the SA. So real-world conditions like loss of a PPP connection and its reestablishment will not require a HIP negotiation. 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 when 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. 9.1. Security Parameters Index (SPI) HIP uses the ESELs as the SPIs in ESP. This provides simple compression of the HIP data from all packets after the HIP exchange. The very first ESP packet from the Initiator occurs before the Initiator has the ESEL from the Responder. For this packet a random number is used. The Responder will have to maintain the relation of that random number to the ESEL, so that when the next packet from the Initiator with the ESEL for the SPI arrives, the Responder recognizes that this is the same SA. This does result in a per host-pair SPI, and a decrease of policy granularity over other KMPs like IKE. 9.2. Sequence Number The Sequence Number field is MANDATORY in ESP [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. Moskowitz 17 Host Identity Payload Architecture December 1999 9.3. 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 Iesp or Resp Data packet from Host 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 | +---------+ | | Packets | | ^ | v I reboots +---------+ | | Iesp->R | Ricmp +---------+ ---------->| Ioo,Rmn | | | | ->I +->| Inm,Rmn | or timeout +---------+ +---------+ | | +---------+ -------------------------->| Inm,Roo |<---+ | | | ^ R reboots +---------+ |ESP | | +------+ or timeout |Pckt|Rrky|Irky | Moskowitz 18 Host Identity Payload Architecture December 1999 | |->I |->R |ESP | | +----+ |packet | v v | +---------+ +---------+ | In1,R1n | | I1m,Rm1 | {rekeying states} +---------+ +---------+ 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 MIM 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 ESEL-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. 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. Moskowitz 19 Host Identity Payload Architecture December 1999 Man-in-the-middle attacks are difficult to defend against, without third-party authentication. A skillful MIM could easily handle all parts of HIP; but HIP indirectly provides the following protection from a MIM 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 MIM attack. The responder may choose not to accept a HIP exchange with an anonymous initiator. 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 MIM 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 MIM 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. 10.1. Non-security Considerations The definition of the Host Identity states that the HI need not be a public key. That the HI could be any value; for example an FQDN. This document does not describe how to support a non-cryptographic HI. Such a HI would still offer the services of the ESEL for NAT traversal. It would carry the ESELs in an ESP that had neither privacy nor authentication (ESP EMPTY). Since this mode of HIP would offer so little additional functionality for so much addition to the IP kernel, it has not been defined in this document. Given Moskowitz 20 Host Identity Payload Architecture December 1999 how little public key cryptography HIP requires, HIP SHOULD only be implemented using public key Host Identities. 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 HIGH128. IANA will has also assigned new DNS OPT resource record OPTION-CODES of Remotes_HIGH [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and Remotes_ESEL [x]. 12. ICANN Considerations ICANN will need to set up the high.int zone and accredit the registered assigning authorities (RAA) for HAA field. With 21 bits, ICANN can allocate just over 2M registries. 13. References [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [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) [DNSBIN], Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999. [IKE], Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC 2409, 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. [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security Payload", RFC 2406, November 1998. Moskowitz 21 Host Identity Payload Architecture December 1999 14. Acknowledgments The drive to create HIP came to being after attending the MALLOC meeting at IETF 43. It has matured considerably since the early drafts thanks to extensive input from IETFers. Particular mention goes to the members of the NameSpace Research Group of the IRTF. Noel Chiappa provided the framework for ESELs 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. 15. Author's Addresses Robert Moskowitz ICSA.net 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@icsa.net Moskowitz 22