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