[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 03 04 05 06 07 08 09

                                                R. Moskowitz, ICSA, Inc.
Internet Draft
Document: <draft-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


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/