One document matched: draft-moskowitz-hip-arch-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-22 04:44:39 |