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

Versions: 00 01 03 04 05 06 07 08 09

                                           R. Moskowitz, TruSecure Corp.
Internet Draft
Document: <draft-moskowitz-hip-04.txt>                         July 2001


                         Host Identity Payload
                              And Protocol


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.1. Host Identity....................................................3
4.2. Host Identity Tag (HIT)..........................................4
4.2.1. Storing HIT in DNS.............................................5
4.3. Host Assigning Authority (HAA) field.............................5
4.4. Local Scope Identity (LSI).......................................5
4.5. Security Parameter Index (SPI)...................................5
4.6. Difference between an LSI and the SPI............................6
5. The Host Identity Payload..........................................6
5.1. HIP format.......................................................6
5.2. HIP Key Payload..................................................7
5.3. HIP Cookie Exchange..............................................8
6. HIP Packets........................................................8
6.1. I1 - the HIP Initiator packet....................................9
6.2. R1 - the HIP Responder packet....................................9
6.3. I2 - the HIP Second Initiator packet............................10
6.4. R2 - the HIP Second Responder packet............................10

Moskowitz                                                            1

                        Host Identity Payload               July 2001


6.5. REK - the HIP Rekey Packet......................................11
6.6. NES - the HIP New SPI Packet....................................12
6.7. REA - the HIP Readdress Packet..................................13
6.8. BOS - the HIP Bootstrap Packet..................................14
6.9. HIP Fragmentation Support.......................................14
7. ESP with HIP......................................................14
7.1. Security Parameters Index (SPI).................................15
7.2. Supported Transforms............................................15
7.3. Sequence Number.................................................15
7.4. ESP usage with non-cryptographic HI.............................15
8. HIP Exchange packet flow..........................................15
8.1. The HIP Exchange................................................16
8.2. HIP KEYMAT......................................................16
8.3. Refusing a HIP exchange.........................................16
8.4. Reboot restart of HIP...........................................17
8.5. Sequence Number State Machine...................................17
9. HIP Policies......................................................18
10. Security Considerations..........................................19
11. IANA Considerations..............................................21
12. ICANN Considerations.............................................21
APPENDIX A.  Security Transform Formats..............................21
13. References.......................................................22
14. Acknowledgments..................................................23
15. Author's Address.................................................23
16. Copyright Statement..............................................24


1. Abstract

   This memo describes the Host Identity Payload (HIP) described in the
   HIP architecture [HIPARCH] and the Host Layer Protocol (HLP) that
   uses it to establish a rapid authentication between two hosts and
   continuity between those hosts independent of the Networking Layer.
   The various forms of the Host Identity, HI, HIT, and LSI are covered
   in detail and how they support the authentication and the
   establishment of Keying Material that is 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


Moskowitz                                                            2

                        Host Identity Payload               July 2001


   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 Tag (HIT), and the Local
   Scope Identity (LSI).  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 public key.
   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 Tag (HIT) 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 LSI is 32 bits.  The LSI provides a
   compression of the HIT with only a local scope so that it can be
   carried efficiently in any packet 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.  However, in some cases, the 3rd and 4th HIP packets can
   carry a datagram.

   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.1. Host Identity

   The 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.

   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.  It SHOULD
   be stored in a DNS KEY RR with the protocol set to HIP.  A Host
   Identity Tag (HIT) is used in protocols to represent the Host

Moskowitz                                                            3

                        Host Identity Payload               July 2001


   Identity.  Another representation of the Host Identity, the Local
   Scope Identity (LSI) can also be used in protocols and APIs.  LSI's
   advantage over HIT is its size; its disadvantage is its local scope.


4.2. Host Identity Tag (HIT)

   The Host Identity Tag 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.

   HIT 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, HIT identifies
   the public key that can validate the packet authentication.  HIT
   SHOULD be unique in the whole IP universe.  If there is more than
   one public key for a HIT, the HIT acts as a hint for the correct
   public key to use.

   There are two formats for HIT.  These two formats were selected to
   avoid the most commonly occurring IPv6 addresses in RFC 2373
   [RFC2372].  Bits 0 and 1 are used to differentiate the formats.  If
   Bit 0 is zero and Bit 1 is one, then the rest of HIT is a 126 bits
   of a Hash of the key.  For example, if the Identity is DSA, these
   bits MUST be the least significant 126 bits of the SHA-1 [FIPS-180-
   1] hash of the DSA public key Host Identity.

   If Bit 0 is one and Bit 1 is zero, then the next 62 bits is the Host
   Assigning Authority (HAA) field, and only the last 64 bits come from
   a SHA-1 hash of the Host Identity.  This format for HIT is
   recommended for 'well known' systems.  It is possible to support a
   resolution mechanism for these names in directories like DNS.
   Another use of HAA is in policy controls.

   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.


   Allocation                   Prefix          Fraction of IPv6
                                (binary)        Address Space
   ------------------------     --------        -------------

   IPv6 Address space           00              1/4
   126 bit HIT                  01

Moskowitz                                                            4

                        Host Identity Payload               July 2001


   HAA assigned 64 bit HIT      10
   IPv6 Address space           11              1/4


4.2.1. Storing HIT in DNS

   The HIT SHOULD be stored in DNS.  The exception to this is anonymous
   identities.  The HIT is stored in a new KEY RR.  The HIT KEY RR will
   have all flags set to ZERO, its protocol set to HIP, and algorithm
   set to HIT128.  The 'public key' field of the HIT KEY RR will be the
   128 bit HIT.


4.3. Host Assigning Authority (HAA) field

   The 62 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 22 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].\[x32/40].\[x64/22].HIT.int   IN PTR
   www.foo.com.


4.4. Local Scope Identity (LSI)

   LSIs are 32 bit localized representations of a Host Identity.  The
   purpose of an LSI is to facilitate using Host Identities in existing
   protocols and APIs.  The owner of the Host Identity does not set its
   own LSI; each host selects its partner's 32 bit representation for a
   Host Identity.  LSI assignment is sequential off of a random
   starting point.  That is, at kernel initiation, a random starting
   point is selected for LSIs, and they are assigned sequentially
   thereafter.  This avoids collisions if LSIs are assigned
   sequentially starting from zero, and even collisions on a busy host
   if assigned randomly.  The risk of collisions for random assignment
   is1% in a population of 10,000.

   Examples of how LSIs can be used include: as the address in a FTP
   command and as the address in a socket call.  Thus LSIs act as a
   bridge for Host Identity into old protocols and APIs.


4.5. Security Parameter Index (SPI)

   SPIs are used in ESP to index into the security association
   negotiated in HIP.  The ESP SPIs have added significance when used

Moskowitz                                                            5

                        Host Identity Payload               July 2001


   with HIP; they are a compressed representation of the HIT in every
   packet.  Thus they MAY be used by intermediary systems in providing
   services like address mapping.  A system does not set its own SPI;
   each host selects its partner's SPI.  It MUST be random.  The risk
   of collisions is too great (1% in a population of 10,000).

   A different SPI MUST be used for each HIP exchange with a particular
   host; this is to avoid a replay attack.  Additionally, when a host
   rekeys, the SPI MUST change.  One method for SPI creation that meets
   these criteria, would be to concatenate the HIT with a 32 bit random
   number, hash this (using SHA1), and then use the high order 32 bits
   as the SPI.


4.6. Difference between an LSI and the SPI

   There is a subtle difference between an LSI and a SPI.

   The LSI is relatively longed lived.  A system selects its peer's LSI
   and SHOULD reuse a previous LSI for a HIT during a HIP exchange.
   The LSI ONLY appears in the 3rd and 4th HIP packets (each system
   providing the other with its LSI).  The LSI is used anywhere in
   system processes where IP addresses have traditionally have been
   used, like in TCBs and FTP port commands.

   The SPI is short-lived.  It changes with each HIP exchange and with
   a HIP rekey.  A system notifies its peer of the SPI to use in ESP
   packets sent to it.  Since the SPI is in all but the first two HIP
   packets, it can be used in intermediary systems to assist in address
   remapping.


5. 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.


5.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      |  VER. |  RES. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    Host Identity Tag (HIT)                    |
   |                                                               |

Moskowitz                                                            6

                        Host Identity Payload               July 2001


   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     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 HIP Version is one byte.  The current version is 1.

   The HIT is always 128 bits (16 bytes).


5.2. HIP Key Payload

   The HIP Key Payload is used to carry the public key associated with
   the HIT and related security information.  The format of the HIP Key
   Payload is a simplification of a DNS message [DNS].


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RCOUNT               |           FQDNLGTH            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                              FQDN                             /
   /                                                               /
   |                                        0 û 7 bytes padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         RDLENGTH              |           TYPE                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                              RDATA                            /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .




Moskowitz                                                            7

                        Host Identity Payload               July 2001


   RCOUNT is the number of HIP Resource Records.  If the sender does
   not have (or does not wish to divulge) an FQDN, a value of '.' will
   be used.  The sender arbitrarily selects the content of the padding
   field.

   The HIP Resource Records will either be a KEY (e.g. DSA and D-H),
   SIG [DNSSEC], or OPT [EDNS] record.  The RDATA of the OPT record in
   the payload can contain any of the following:

   OPT Attribute        Length          Data

   Remotes_HIT          128             Remote's HIT
   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 (Appendix A)
                                        Without first 32 bits
                                        Using IPsec DOI
   ESP_TRANSFORM        variable        ISAKMP Transform (Appendix A)
                                        Without first 32 bits
                                        Using IPsec DOI
   Remotes_LSI          32              Remote's LSI
   Remotes_SPI          32              Remote's SPI


5.3. 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).



Moskowitz                                                            8

                        Host Identity Payload               July 2001


6.1. I1 - the HIP Initiator packet

   Next Header = 0
   Type = 1
   HIT = Initiator's HIT
   Payload Contains:
        Responder's HIT in a KEY HIT RR

   The Initiator gets the responder's HIT 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
   HIT = Responder's HIT
   Payload Contains:
        Responder's HI in a KEY RR (e.g. KEY DSA RR)
        Initiator's HIT in a KEY HIT 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 HIT 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 encryption algorithms 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, HIT, 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.

Moskowitz                                                            9

                        Host Identity Payload               July 2001



   The HIP SIG is calculated over the 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
   HIT = Initiator's HIT
   Payload Contains:
        Responder's HIT in a KEY HIT RR
        HIP COOKIE in an OPT RR
        Responder's LSI in an OPT RR
        Responder's SPI 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
                ESP TRANSFORM in a OPT RR
                Initiator's HI in a KEY RR (e.g. KEY DSA RR)
        HIP SIG in a SIG RR

   If the initiator has multiple HIs, the HI and HIT used MUST match
   Responder's reply.

   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, HIT, and DH
   sent to the Responder.

   The Diffie-Hellman value is ephemeral.  A scavenger process should
   clean up unused DHs and Js.

   The HIP_TRANSFORM contains the encryption used to protect the HI
   exchange selected by the initiator.  All implementations MUST
   support the 3DES transform.

   The ESP_TRANSFORM contains the ESP mode selected by the initiator.
   All implementations MUST support 3DES-HMAC-SHA-1-96, RFCs 2404 and
   2451.

   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

Moskowitz                                                           10

                        Host Identity Payload               July 2001


   HIT = Responder's HIT
   Payload Contains:
        Initiator's LSI in an OPT RR
        Initiator's SPI 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 an
   approaching sequence number wrap in ESP, or a local policy on use of
   a key.  Rekeying ends the current SA and starts a new one.  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:

   IP[ESP[HIP(D-H)]]

   The HIP content is:

   Next Header = 0
   Type = 5
   HIT = Sender's HIT
   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 SA's Kij.
   Once past the rekeying start, the sending host can drop the old SA
   and its Kij.

   The first packet sent by the receiving system MUST be a HIP New SPI
   packet.  This packet supplies the new SPI for the rekeying system,
   which cannot send any packets until it receives this packet.  If it
   does not receive a HIP New SPI packet within a resonable round trip


Moskowitz                                                           11

                        Host Identity Payload               July 2001


   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 SPI Packet

   The HIP New SPI Packet serves two functions.  First it provides the
   rekeying system with its new SPI.  Additionally, it provides any
   intermediate system with the mapping of the old SPI to the new.
   This is important to systems like NATs [HIPIMPL] that use SPIs to
   maintain address translation state. The new SPI Packet is a HIP
   packet with only a SPI 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(SPI)]]
   or
   IP[ESP[HIP(SPI)[HIP(D-H)]]]

   The HIP content is:

   Next Header = 0 or NN (HIP's protocol number)
   Type = 6
   HIT = Sender's HIT
   Payload Contains:
        Rekeyer's new SPI in an OPT RR
        HIP SIG in a SIG RR

   Since intermediate systems need this new SPI, this ESP packet MUST
   NOT be encrypted, that is ESP NULL is used.  The rekeying system
   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 SPI will have to inspect ALL ESP
   packets for a HIP New SPI 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 SPI and Kij.
   Alternatively, the sending system COULD use the following datagram
   to privately rekey:

   IP[ESP[HIP(SPI)[ESP[HIP(D-H)]]]]


Moskowitz                                                           12

                        Host Identity Payload               July 2001


   Where the first ESP header is the ESP NULL that is required by the
   HIP New SPI packet and the second ESP header uses the negotiated ESP
   transform as used in a simple HIP rekey packet.


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 the LSI
   and HIT 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 a A or A6
   RR in the HIP payload.  The address RR is included in the HIP
   payload not for the partner's benefit (which COULD deduce this from
   the outer IP header), but for benefit of any intermediary systems
   that are maintaining state between the HIT and the address.  If the
   readdressed host 'knew' that there were no intermediary systems
   between it and its partners, it COULD remove the address RR here for
   architectural purity.  However, this option would only further
   complicate the protocol.

   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
   HIT = Sender's HIT
   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.

   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

Moskowitz                                                           13

                        Host Identity Payload               July 2001


   attack for the Intermediate systems is to implement ESP's replay
   protection of windowing the sequence number.


6.8. BOS - the HIP Bootstrap Packet

   The HIP content is:

   Next Header = 0
   Type = 10
   HIT = Announcer's HIT
   Payload Contains:
        Announcer's HIT in a KEY HIT RR
        Announcer's HI in a KEY RR (e.g. KEY DSA RR)
        HIP SIG in a SIG RR

   In some situations, an initiator may not be able to learn of a
   responders information from DNS or another repository.  Some
   examples of this is a DHCP and NetBios servers.  Thus a packet is
   needed to provide information that would otherwise be gleaned from a
   repository.  This HIP packet is either self-signed in applications
   like SoHo, or from a trust anchor in large private or public
   deployments.  This packet SHOULD be broadcasted frequently.


6.9. 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 informations that are 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 HIT and LSI.  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 (LSI), 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

Moskowitz                                                           14

                        Host Identity Payload               July 2001


   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)

   The SPIs in ESP provide a simple compression of the HIP data from
   all packets after the HIP exchange.  This does require a per HIT-
   pair Security Association (and SPI), and a decrease of policy
   granularity over other KMPs like IKE.

   When a host rekeys, it gets a new 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 (LSI) for
   associating the packets with the HITs, 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].

Moskowitz                                                           15

                        Host Identity Payload               July 2001



   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 HIT of Responder somehow.
        Hard coded (bad)
        DNS lookup
                DNSSEC important

   I --> DNS (lookup R)
   I <-- DNS (R's address, HI, and HIT)
   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. HIP KEYMAT

   HIP keying material is derived from the Diffie-Hellman Kij produced
   during the HIP exchange.  The initiator has Kij during the creation
   or the I2 packet, and the responder has Kij once it receives the I2
   packet.  This is why I2 can already contain encrypted information.
   There are four keys that are derived from Kij; these are the
   initiator and responder HIP keys and the initiator and responder ESP
   keys.  These four keys MUST be drawn sequentially (HIP initiator,
   HIP responder, ESP initiator, EXP responder, and where the ESP
   transform requires an encrypting and an authenticating key, they are
   taken sequentially) from the Kij KEYMAT. For situations where the
   amount of keying material desired is greater than that supplied by
   Kij, KEYMAT is expanded by feeding Kij into the following operation:

   KEYMAT = K1 | K2 | K3 | ...
         where

        K1 = SHA2-512(Kij | Resp-SPI)
        K2 = SHA2-512(K1 | Resp-SPI)
        K3 = SHA2-512(K2 | Resp-SPI)
        etc.

   In the situation where Kij is the result of a HIP rekey exchange,
   there is only the need from one set of ESP keys.  These are then the
   only keys taken from Kij.


8.3. Refusing a HIP exchange


Moskowitz                                                           16

                        Host Identity Payload               July 2001


   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.4. 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.5. 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



      +---------+
      | Ioo,Roo |<----------------------------+
      +---------+                             |
           |                                  |
           | I1->R                            |
           |                                  |
           v                                  |
      +---------+                             |

Moskowitz                                                           17

                        Host Identity Payload               July 2001


      | 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

   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 HIT to responder HIT.  This ACL SHOULD also include

Moskowitz                                                           18

                        Host Identity Payload               July 2001


   preferred transform and local lifetimes.  For HITs 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 LSI-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.

   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.



Moskowitz                                                           19

                        Host Identity Payload               July 2001


   A second form of DOS attack arrives in the I2 HIP packet.  Once and
   attacking initiator has solved the cookie challenge, it can send
   packets with spoofed IP source addresses with either invalid
   encrypted HIP payload component or a bad HIP SIG.  This would take
   resources in the responderÆs part to reach the point to discover
   that the I2 packet cannot be completely processed.  The defense
   against this attack is after N bad I2 packets, the responder would
   discard any I2s that contain the given I.  Sort of a shutdown on the
   attack.  The attacker would have to request another R1 and use that
   to launch a new attack.  The responder could up the value of K while
   under attack.  On the downside, valid I2s might get dropped too.

   A third 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 fourth 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


Moskowitz                                                           20

                        Host Identity Payload               July 2001


   any ICMP message while waiting for an R2 HIP packet, deleting state
   only after a natural timeout.

   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 HIT128.

   IANA will has also assigned new DNS OPT resource record OPTION-CODES
   of Remotes_HIT [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and
   Remotes_LSI [x].


12. ICANN Considerations

   ICANN are covered in the HIP Architecture [HIPARCH] document.


APPENDIX A.  Security Transform Formats

   The security transforms, HIP and ESP transforms, use the format from
   ISAKMP [ISAKMP].

       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
     /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / | NP = Transform|   RESERVED    |         Payload Length        |
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Tr1| Transform # 1 | Transform ID  |           RESERVED2           |
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ |                         SA Attributes                         |
     >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / | NP = 0        |   RESERVED    |         Payload Length        |
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Tr2| Transform # 2 | Transform ID  |           RESERVED2           |
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ |                         SA Attributes                         |
     \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Moskowitz                                                           21

                        Host Identity Payload               July 2001



   Transform Classes    Values

        HIP_ENC         1
        ESP_ENC         2
        ESP_AUTH        3

   HIP Encryption Algorithm     Values

        DES-CBC                 1
        IDEA-CBC                2
        Blowfish-CBC            3
        RC5-R16-B64-CBC         4
        3DES-CBC                5
        CAST-CBC                6

   ESP Encryption Algorithm     Value

        RESERVED                0
        ESP_DES_IV64            1
        ESP_DES                 2
        ESP_3DES                3
        ESP_RC5                 4
        ESP_IDEA                5
        ESP_CAST                6
        ESP_BLOWFISH            7
        ESP_3IDEA               8
        ESP_DES_IV32            9
        ESP_RC4                 10
        ESP_NULL                11

   ESP Authenticat Algorithm    Value

        RESERVED                0-1
        MD5                     2
        SHA                     3
        DES                     4


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-03.txt, January 2001.

   [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation",
   draft-ietf-moskowitz-hip-impl-02.txt, January 2001.

   [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security
   Payload", RFC 2406, November 1998.


Moskowitz                                                           22

                        Host Identity Payload               July 2001


   [RFC2373], R. Hinden, S. Deering., "IP Version 6 Addressing
   Architecture", RFC 2373, July 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)

   [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.

   [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.

   [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol", RFC
   2408, 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 LSIs 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

Moskowitz                                                           23

                        Host Identity Payload               July 2001


   TruSecure Corporation
   1200 Walnut Bottom Rd.
   Carlisle, PA  17013
   Email: rgm@trusecure.com


16. Copyright Statement

   Copyright (c) The Internet Society (2001). 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
   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                                                           24


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