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