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

Versions: 00 01 03 04 05 06 07 08 09

Internet Draft                            R. Moskowitz, TruSecure Corp.
Document: <draft-moskowitz-hip-05.txt>                    November 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.......................................................3
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)...................................6
4.6. Difference between an LSI and the SPI............................6
5. The Host Identity Payload..........................................6
5.1. HIP format.......................................................7
5.2. HIP Key Payload..................................................7
5.3. HIP Cookie Exchange..............................................8
5.3.1. HIP Cookie Mechanism...........................................9
5.3.2. HIP Controls...................................................9
5.3.3. HIP Birthday...................................................9
6. HIP Packets.......................................................10
6.1. I1 - the HIP Initiator packet...................................10
6.2. R1 - the HIP Responder packet...................................11
6.2.1. R1 Management.................................................12
6.3. I2 - the HIP Second Initiator packet............................12


Moskowitz                                                            1

                        Host Identity Payload           November 2001


6.4. R2 - the HIP Second Responder packet............................13
6.5. NES - the HIP New SPI Packet....................................14
6.6. REA - the HIP Readdress Packet..................................15
6.7. BOS - the HIP Bootstrap Packet..................................17
6.8. HIP Fragmentation Support.......................................17
7. ESP with HIP......................................................18
7.1. Security Association Management.................................18
7.2. Security Parameters Index (SPI).................................18
7.3. Supported Transforms............................................18
7.4. Sequence Number.................................................19
7.5. ESP usage with non-cryptographic HI.............................19
8. The Host Layer Protocol (HLP) packet flow.........................19
8.1. The Host Layer Protocol (HLP)...................................19
8.2. HLP Scenarios...................................................20
8.3. HIP KEYMAT......................................................20
8.4. Refusing a HLP exchange.........................................21
8.5. Reboot and SA timeout restart of HIP............................21
8.5. HLP State Machine...............................................22
8.5.1. HLP States....................................................22
8.5.2. HLP State Processes...........................................22
8.5.3. Simplified HLP State Diagram..................................23
9. HLP Policies......................................................24
10. Security Considerations..........................................24
11. IANA Considerations..............................................27
12. ICANN Considerations.............................................27
APPENDIX A.  Security Transform Formats..............................27
APPENDIX B.  Proposed change to the HIP Formats......................28
13. References.......................................................30
14. Acknowledgments..................................................31
15. Author's Address.................................................31
16. Copyright Statement..............................................32


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



Moskowitz                                                            2

                        Host Identity Payload           November 2001


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119].


3. Introduction

   The Host Identity Payload (HIP) along with the HIP Protocol provides
   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.  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 Identity of the Initiator in packet 3.  The
   Responder's Host Identity is not encrypted in packet 2, so it is not
   included in the encrypted part of packet 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


Moskowitz                                                            3

                        Host Identity Payload           November 2001


   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.  DSA was chosen as the
   default algorithm due to its small signature size.

   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 HIP.  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 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 are designed 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.

Moskowitz                                                            4

                        Host Identity Payload           November 2001


   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
   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
   is 1% in a population of 10,000.

Moskowitz                                                            5

                        Host Identity Payload           November 2001



   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
   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.
   This COULD be important in a timeout recovery situation.  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 could 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.


Moskowitz                                                            6

                        Host Identity Payload           November 2001



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)                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        HIP Key payload                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               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                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Moskowitz                                                            7

                        Host Identity Payload           November 2001


   |                                                               |
   /                              RDATA                            /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .


   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], A, AAAA, 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_CNTLS            variable        contains bit-wise controls
   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
   Birthday             64              System boot counter
   Remotes_LSI          32              Remote's LSI
   Remotes_SPI          32              Remote's SPI
   Sequence Number      32              Current ESP sequence number
   ID                   64              Name of a network Interface

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


Moskowitz                                                            8

                        Host Identity Payload           November 2001


   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.


5.3.1. HIP Cookie Mechanism

   Responder    Generates 2 Random Numbers, I and J
                Challenge = Ltrunc(SHA1(I|J),K)
                Send I, K, and Challenge in HIP Cookie in R1
                Saves I, K, and Challenge for Delta time

   Initiator    Do Until Challenge-response = Challenge
                Challenge-response = Ltrunc(SHA1(I|Rand),K)
                EndDo
                Send I, Rand, and Challenge-response in HIP Cookie
                        in I2

   Responder    Match Response with Challenge based on I
                Reject if Challenge-response = Challenge
                Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K)
                Accept if Challenge-proof = Challenge


5.3.2. HIP Controls

   HIP controls are informative items that will influence the HIP
   exchange and the use of ESP.  HIP Controls are assigned a bit
   location in the HIP_CNTL field numbered left to right.  Currently,
   there are two controls of value to a HIP exchange:

   BIT  Action

   0    If value is 1, the HI is anonymous.
        This control is set in packets R1 and/or I2.
        The peer receiving an anonymous HI may choose to refuse it by
        silently dropping the exchange.
   1    If value is 1, the ESP transform requires a 64 bit sequence
        number.  See Sequence Number section for processing this
        control.

   Various controls will be defined over time.  These controls will be
   added to the end of the HIP_CNTL field so that older implementations
   can ignore them.


5.3.3. HIP Birthday

   The Birthday is a reboot count used to manage state reestablishment
   when one peer rebooted or timed out its SA.  The Birthday is
   increased every time the system boots.  The Birthday also has to be

Moskowitz                                                            9

                        Host Identity Payload           November 2001


   increased in accordance with the system's SA timeout parameter.  If
   the system has open SAs, it MUST increase its Birthday.  This
   impacts a system's approach to precomputing R1 packets.

   Birthday SHOULD be a counter.  It cannot be reset by the user and a
   system is unlikely to need a birthday larger than 2^64. Date-time in
   GMT can be used if a cross-boot counter is not possible, but it has
   a potential problem if the system time is set back by the user.


6. HIP Packets

   There are 7 HIP packets.  Four are for the HIP exchange, two are for
   mid-state changes (rekeying and address migration), and one is a
   broadcast for use when there is no IP addressing (e.g. before DHCP
   exchange).

   Although HIP is presented to operate above IP, it MAY be used below
   IP to support MAC layer protocols like DHCP.  However, there is no
   MAC layer relaying mechanism defined like that defined in DHCP.

   All implementations MUST parse at least the following formats.  All
   implementations MUST recognize additional RR in the HIP envelope but
   MAY ignore them.

   Packet representation uses the following operations:

   ()   payload
   x{}  operation x on contents
   <>i  repeat () 1 to n times
   []   optional payload

   An ESP payload MAY follow some HIP payloads.  This transmission
   optimization SHOULD NOT be used if it results in fragmentation, and
   there would not be any fragmentation if the ESP payload were sent by
   itself.


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

   IP(HIP(HITr))

   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.

Moskowitz                                                           10

                        Host Identity Payload           November 2001


   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:
        HIP CONTROLs in an OPT RR
        Responder's HI in a KEY RR (e.g. KEY DSA RR)
        Optional SIG of Responder's HI by a signing authority
                in a SIG RR
        Responder's Diffie-Hellman public value in a KEY DH RR
        Birthday
        HIP TRANSFORM in an OPT RR
        ESP TRANSFORM in an OPT RR
        HIP COOKIE in an OPT RR
        HIP SIG in a SIG RR

   IP(HIP(H_CTRL,HIr,[AUTH_SIG,] DHr,BRTHDY,H_TRN,E_TRN,COOKIE1,SIG))

   The valid HIP control is the anonymous bit.

   If the responder has multiple HIs, the HIT used MUST match
   Initiator's request.

   The Optional Signature of the Responder's HI by a higher level
   authority known to the Initiator is an alternative method for the
   Initiator to trust the Responder's HI (over DNSSEC or PKI).

   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 Birthday is a reboot count used to manage state reestablishment
   when one peer rebooted or timed out its SA.

   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


Moskowitz                                                           11

                        Host Identity Payload           November 2001


   used as a pointer until this cookie is used in an SA.  K is number
   of bits that the Initiator must match with the Hash Target.

   The HIP SIG is calculated over 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.2.1. R1 Management

   All compliant implementations MUST produce R1 packets.
   An R1 packet MAY be precomputed.
   An R1 packet MAY be reused for time Delta T.
   R1 information MUST not be discarded until Delta S after T.  Time S
   is the delay needed for the last I2 to arrive back to the responder.
   A spoofed I1 can result in an R1 attack on a system.  An R1 sender
   MUST have a mechanism to rate limit R1s to an address.


6.3. I2 - the HIP Second Initiator packet

   Next Header = 0 or 50 (ESP)
   Type = 3
   HIT = Initiator's HIT
   Payload Contains:
        HIP CONTROLs in an OPT RR
        Responder's HIT in a KEY HIT RR
        Birthday
        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 an OPT RR
        The following Resource Records are encrypted using the HIP
        Transform and are in a HIP ENCRPYT OPT RR
                ESP TRANSFORM in an OPT RR
                Initiator's HI in a KEY RR (e.g. KEY DSA RR)
                Optional SIG of Initiator's HI by a signing authority
                        in a SIG RR
        HIP SIG in a SIG RR
        Optional data in an ESP envelope

   IP(HIP(H_CTRL,HITr,BRTHDY,COOKIE2,LSIr,SPIr,DHi,H_TRN,enc{E_TRN,HIi
   [,AUTH_SIG]},SIG)[ESP(data)])

   The valid HIP controls are the anonymous and 64 bit sequence number
   bits.

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

   The Birthday is a reboot count used to manage state reestablishment
   when one peer rebooted or timed out its SA.

Moskowitz                                                           12

                        Host Identity Payload           November 2001



   HIP_COOKIE contains I from R1 and random J, and Ltrunc(SHA1(I|J), K)
   (that is the low order K 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, Initiator's HI, and optional SIG on this HI are
   encrypted using the HIP_TRANSFORM.  The keying material is derived
   from the Diffie-Hellman exchanged as defined later in this document.

   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 Optional Signature of the Initiator's HI by a higher level
   authority known to the Responder is an alternative method for the
   Responder to trust the Initiator's HI (over DNSSEC or PKI).

   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.

   The optional ESP payload contains the first user datagram that the
   Initiator is sending to the Responder.  The SPI is set to NN, as the
   real Initiator SPI is not know yet be the Initiator.  When the
   Responder processes the HIP payload, it generates the Initiator SPI
   and replaces NN with this SPI.  The Sequence Number SHOULD be set to
   ONE, as this is the first datagram for this SA.  If the ESP
   transform uses the ESP header for the IV, then special
   considerations for the ESP header might apply.  For example, if the
   transform requires a random value in the header, expecting it to be
   the SPI, the Sequence Number can be a random number, and be reset to
   ONE by the Responder.  The Responder would pass the Initiator
   supplied SPI and Sequence Number to the decryption routine.


6.4. R2 - the HIP Second Responder packet

   Next Header = 0 or 50 (ESP)
   Type = 4
   HIT = Responder's HIT
   Payload Contains:
        HIP CONTROLs in an OPT RR
        Initiator's LSI in an OPT RR
        Initiator's SPI in an OPT RR

Moskowitz                                                           13

                        Host Identity Payload           November 2001


        HIP SIG in a SIG RR
        Optional data in an ESP envelope

   IP(HIP(H_CTRL,LSIi,SPIi,SIG)[ESP(data)])

   The valid HIP control is the 64 bit sequence number bit.

   The HIP SIG is calculated over whole HIP envelope. The Initiator
   MUST validate this SIG.

   The optional ESP payload contains the first user datagram that the
   Responder is sending to the Initiator.  The SPI is the value within
   I2. The Sequence Number MUST be set to ONE, as this is the first
   datagram for this SA.


6.5. NES - the HIP New SPI Packet

   The HIP New SPI Packet serves three functions.  First it provides
   the peer system with its new SPI.  Next it optionally provides a new
   Diffie-Hellman key to produce new keying material.  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 SPI and D-H OPT RRs in the HIP payload.  The HIP
   packet contains the current ESP Sequence Number and SPI to provide
   Dos and replay protection.

   The HIP content is:

   Next Header = 0
   Type = 5
   HIT = Sender's HIT
   Payload Contains:
        Sender's ESP Sequence Number in an OPT RR
        Sender's old SPI in an OPT RR
        Sender's new SPI in an OPT RR
        Optional Sender's Diffie-Hellman public value in a KEY DH RR
        HIP SIG in a SIG RR
        Optional data in an ESP envelope
                In reply packet only

   IP(HIP(SEQ,SPIo,SPI[,DH],SIG)[ESP(data)])

   During the life of an SA established by HIP, one of the hosts may
   need to reset the Sequence Number to one (to prevent wrapping) and
   rekey.  The reason for rekeying might be an approaching sequence
   number wrap in ESP, or a local policy on use of a key.  A new SPI or
   rekeying ends the current SA and starts a new one on both peers.

   The ESP Sequence Number and current SPI are included to provide
   replay protection for the receiving peer.  This packet MUST NOT be
   processed until all ESP packets with a lower Sequence Number have

Moskowitz                                                           14

                        Host Identity Payload           November 2001


   been received and processed, or a reasonable time has elapsed (to
   account for lost packets).  If the Sequence Number is a replay
   window greater than the current number it MUST be ignored.  This
   packet has a potential Dos attack of a packet within the replay
   window and proper SPI, but a malformed signature.  Implementations
   MUST recognize when they are under attack and manage the attack.  If
   it is still receiving ESP packets with increasing Sequence Numbers,
   the HIP new SPI packets are obviously attacks and can be ignored.

   Intermediate systems that use the SPI will have to inspect ALL HIP
   packets for a HIP New SPI packet.  This is a potential DOS attack
   against the Intermediate system, as the signature processing may be
   relatively expensive.  A further step against attack for the
   Intermediate systems is to implement ESP's replay protection of
   windowing the sequence number.  This requires the intermediate
   system to track ALL ESP packets to follow the Sequence Number.

   The peer that initiates a New SPI exchange MUST include a Diffie-
   Hellmen key.  Its peer MUST respond with a New SPI packet, an MAY
   include a Diffie-Hellman key if the receiving system's policy is to
   increase the new KEYMAT by changing its key pair.

   When a host receives a New SPI Packet with a Diffie-Hellman, its
   next ESP packet MUST use the KEYMAT generated by the new Kij.  The
   sending host MUST expect at least a 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.  It MAY also include a datagram, using the new SAs.  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 reasonable round trip delta,
   it MUST assume it or the HIP Rekey packet was lost and MAY resend
   the HIP New SPI packet or renegotiate HIP as if in a reboot
   condition.  The choice is a local policy decision.


6.6. 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. This readdress packet is NOT intended to provide all
   of the functionality needed for MobileIPv6, or even a mobile server.
   This functionality is provided in a separate specification.
   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.


Moskowitz                                                           15

                        Host Identity Payload           November 2001


   The Readdress Packet permits a host to notify its partners of an
   address change.  The Readdress Packet is a HIP packet with at least
   one pair of A or AAAA RRs 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 contains the current ESP Sequence Number and SPI to
   provide Dos and replay protection.

   The HIP content is:

   Next Header = 0 or 50 (ESP)
   Type = 6
   HIT = Sender's HIT
   Payload Contains:
        Sequence number in an OPT RR
        Current SPI
        Interface ID in an OPT RR
        New address in an A or AAAA RR
        HIP SIG in a SIG RR
        Optional data in an ESP envelope

   IP(HIP(SEQ,SPI,<[ID,]<Ao|AAAAo,An|AAAAn>j>i,SIG)[ESP(data)])

   The address OPT RRs are always in pairs, the old address and the new
   address.  Multiple addresses can be sent in a single HIP payload.

   The Interface ID, if included, groups a set of addresses to an
   interface.  The purpose of the Interface ID is to allow a
   knowledgeable peer to interact with the sender.  For example, the
   sender could be informing its peer that that an interface has both
   an IPv4 address and one or more IPv6 addresses.  The HIP host is
   free to introduce IDs at will.  That is, if a received REA has a new
   interface ID, it means that all the old addresses are also supposed
   to still work, while the new addresses in the REA are supposed to be
   associated with a new interface.  On the other hand, if a received
   REA has an interface ID that the receiver already knows about, it
   would replace (all) the address(es) currently associated with the
   interface with the new one(s).

   The ESP Sequence Number and current SPI are included to provide
   replay protection for the receiving peer.  This packet MUST NOT be
   processed until all ESP packets with a lower Sequence Number have
   been received and processed, or a reasonable time has elapsed (to
   account for lost packets).  If the Sequence Number is a replay
   window greater than the current number it MUST be ignored.  This
   packet has a potential Dos attack of a packet within the replay
   window and proper SPI, but a malformed signature.  Implementations

Moskowitz                                                           16

                        Host Identity Payload           November 2001


   MUST recognize when they are under attack and manage the attack.  If
   it is still receiving ESP packets with increasing Sequence Numbers,
   the HIP readdress packets are obviously attacks and can be ignored.

   Intermediate systems that use the SPI will have to inspect ALL HIP
   packets for a HIP readdress packet.  This is a potential DOS attack
   against the Intermediate system, as the signature processing may be
   relatively expensive.  A further step against attack for the
   Intermediate systems is to implement ESP's replay protection of
   windowing the sequence number.  This requires the intermediate
   system to track ALL ESP packets to follow the Sequence Number.

   The optional ESP protected datagram allows for efficiency in
   transmissions.


6.7. 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)
        Optional SIG of Announcer's HI by a signing authority
                in a SIG RR
        HIP SIG in a SIG RR

   IP(HIP(HIT,HI,[AUTH_SIG,] SIG)))

   In some situations, an initiator may not be able to learn of a
   responder's information from DNS or another repository.  Some
   examples of this are 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.

   The Optional Signature of the Announcer's HI by a higher level
   authority known to the Initiator is an alternative method for the
   Initiator to trust the Announcer's HI (over DNSSEC or PKI).


6.8. HIP Fragmentation Support

   A HIP implementation MUST support IP fragmentation/reassembly.  HIP
   packets can get large, and may encounter low MTUs along their routed
   path.  Since HIP does not provide a mechanism to use multiple IP
   datagrams for a single HIP packet, support of path MTU discovery
   does not bring any value to HIP.  HIP aware NAT systems MUST perform
   any IP reassembly/fragmentation.

Moskowitz                                                           17

                        Host Identity Payload           November 2001




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
   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 Association Management

   An SA is indexed by the 2 SPIs and 2 HITs (both HITs since a system
   can have more than one HIT).
   An inactivity timer is recommended for all SAs.
   If the state dictates the deletion of an SA, a timer is set to allow
   for any late arriving packets.
   The SA MUST include the I that created it for replay detection.


7.2. 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.3. 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.


Moskowitz                                                           18

                        Host Identity Payload           November 2001



7.4. 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 can be changed, that of the rekeying host.
   However, if one host rekeys, the other host SHOULD rekey as well.

   In some instances, a 32 bit sequence number is inadequate.  In
   either the I2 or R2 packets, a peer MAY require that a 64 bit
   sequence number be used.  In this case the higher 32 bits are NOT
   included in the ESP header, but are simply kept local to both peers.
   64 bit sequence numbers must only be used for ciphers that will not
   be open to cryptoanalysis as a result.  AES is one such cipher.


7.5. 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. The Host Layer Protocol (HLP) packet flow

   A Host Layer Protocol (HLP) exchange SHOULD be initiated whenever
   the DNS lookup returns HIP KEY resource records.  Since some hosts
   may choose not to have information in DNS, hosts SHOULD support
   opportunistic HIP [HIPIMPL].

   Only Initiator and Responder in common addressing realm (i.e. both
   public or both private) is shown here.  Other packet flow scenarios
   are covered in the HIP implementation documents.


8.1. The Host Layer Protocol (HLP)

   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)

Moskowitz                                                           19

                        Host Identity Payload           November 2001


   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. HLP Scenarios

   No prior state between the two systems.

        The system with data to send is the Initiator.
        The process follows standard 4 packet exchange, establishing
        the SAs.

   The system with data to send has no state with receiver, but
   receiver has a residual SA.

        Intiator acts as in no prior state, sending I1 and getting R1.
        When Receiver gets I2, the old SA is 'discovered' and deleted;
        the new SAs are established.

   System with data to send has an SA, but receiver does not.

        Receiver 'detects' when it receives an unknown SPI.
        Receiver sends an R1.
        Sender gets the R1 with a later birthdate, discards old SA and
        continues exchange to establish new SAs for sending data.

   A peer determines that it needs to reset Sequence number or rekey.
        It sends NES.
        Receiver sends NES response, establishes new SAs for peers.
        D-H optional for peer that received the first NES.


8.3. HIP KEYMAT

   HIP keying material is derived from the Diffie-Hellman Kij produced
   during the HLP 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 = HMAC-SHA1(Kij | sort(Resp-SPI | Init-SPI) | 1)

Moskowitz                                                           20

                        Host Identity Payload           November 2001


        K2 = HMAC-SHA1(Kij | K1 | 2)
        K3 = HMAC-SHA1(Kij | K2 | 3)
        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.4. Refusing a HLP exchange

   A HIP aware host may choose not to accept a HLP exchange.  If the
   host's policy is to only be an initiator, it should begin its own
   HLP exchange.  There is a risk of a race condition if each host's
   policy is to only be an initiator, at which point the HLP exchange
   will fail.

   If the host's policy does not permit it to enter into a HLP 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.5. Reboot and SA timeout restart of HIP

   Simulating a loss of state is a potential Dos attack.  The following
   process has been crafted to manage state recovery without presenting
   a Dos opportunity.

   If a host reboots or times out, it has lost its HLP state.  If the
   system that lost state has a datagram to deliver to its peer, it
   simply restarts the HLP exchange.  The peer sends an R1 HIP packet,
   but does not reset its state until it receives the I2 HIP packet.
   The I2 packet MUST have a Birthday greater than the current SA's
   Birthday.  This is to handle DOS attacks that simulate a reboot of a
   peer.  Note that either the original Initiator or the Responder
   could end up restarting the exchange, becoming the Intitator.  An
   example of the initial Responder needing to send a datagram but not
   having state occurs when the SAs timed out and a server on the
   Responder sends a keep-alive to the Initiator.

   If a system receives an ESP packet for an unknown SPI, the
   assumption is it lost state and its peer did not.  In this case, the
   system treats the ESP packet like an I1 packet and sends an R1
   packet.  The system receiving the R1 packet checks the Birthday, if
   the Birthday is greater than the current SA's Birthday, it processes
   the R1 packet and resends the ESP packet along with the I2 packet.
   This will reestablish state between the two peers.  [Potential Dos
   attack if hundreds of peers 'loose' their state and all send R1
   packets at once to a server.]



Moskowitz                                                           21

                        Host Identity Payload           November 2001


8.5. HLP State Machine

   HLP has very little state.  HLP has three processes: SA
   establishment, new SPI/rekey, and restart of HLP.  In HLP
   establishment, there is an Initiator and a Responder.  Once the SAs
   are established, this distinction is lost.  In new SPI/rekey the
   Initiator could be either peer.  In HLP reestablishment the
   controlling parameters are which peer still has state and which has
   a datagram to send to its peer.  The following state machine
   attempts to capture these processes.

   The state machine is presented in a single system view, representing
   either an Initiator or a Responder.  There is not a complete overlap
   of processing logic here and in the packet definitions.  Both are
   needed to completely implement HIP and HLP.


8.5.1. HLP States

   E0   State machine start
   E1   Initiating HIP
   E2   Waiting to finish HIP
   E3   HIP SA established


8.5.2. HLP State Processes

   +---------+
   |    E0   |  Start state
   +---------+

   Datagram to send, send I1 and go to E1
   Receive I1, send R1 and stay at E0
   Receive I2, process
        if successful, send R2 and go to E3
        if fail, stay at E0
   Receive ESP for unknown SA, send R1 and stay at E0
   Receive ANYOTHER, drop and stay at E0

   +---------+
   |    E1   |  Initiating HLP
   +---------+

   Receive R1, process
        if successful, send I2 and go to E2
        if fail, go to E-FAILED
   Receive ANYOTHER, drop and stay at E1
   Timeout, up timeout counter
        If counter is less than N, send I1 and stay at E1
        If counter is greater than N, Go to E-FAILED

   +---------+
   |    E2   | Waiting to finish HLP

Moskowitz                                                           22

                        Host Identity Payload           November 2001


   +---------+

   Receive R2, process
        if successful, go to E3
        if fail, go to E-FAILED
   Receive ANYOTHER, drop and stay at E2

   +---------+
   |    E3   | HIP SA established
   +---------+

   Receive NAS, process
        if successful, send NAS and stay at E3
        if failed, stay at E3
   Receive REA, process and stay at E3
   Receive I1, send R1 and stay at E3
   Receive I2, process with Birthday check
        if successful, send R2, drop old SA and cycle at E3
        if fail, stay at E3
   Receive R1, process with Birthday check
        if successful, send I2 with last datagram, drop old SA
                and go to E2
        if fail, stay at E3
   Receive ESP for SA, process and stay at E3
   Receive R2, drop and stay at E3


8.5.3. Simplified HLP State Diagram

   Receive packets cause a move to new state

   +---------+
   |    E0   |----+
   +---------+    |
    | ^ |         |
    | | | Dgm to  |
    +-+ | send    |
     I1 |         |  (note ESP- means ESP with unknown SPI)
   ESP- |         |
        v         |
   +---------+    |
   |    E1   |    |
   +---------+    |
        |         |
        | R1      |
        |         | I2
        v         |
   +---------+    |
   |    E2   |<---|-----+
   +---------+    |     |
        |         |     |
        | R2      |     |
        |         |     |R1

Moskowitz                                                           23

                        Host Identity Payload           November 2001


        v         |     |
   +---------+<---+     |
   |    E3   |----------+
   +---------+
    |  ^
    |  |
    +--+
    ESP,
    NAS,
    REA,
    I1,
    I2


9. HLP Policies

   There are a number of variables that will influence the HLP
   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
   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 and HLP are 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, HLP 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.

Moskowitz                                                           24

                        Host Identity Payload           November 2001


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

   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, a
   system Birthday is included in the R1 and I2 packets to prove loss
   of state to a peer.  The inclusion of the Birthday creates a very
   deterministic process for state restart.  Any other action is a Dos
   attack.

   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


Moskowitz                                                           25

                        Host Identity Payload           November 2001


   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 HLP exchange with an anonymous initiator.

   New SPIs and rekeying provide another opportunity for an attacker.
   Replay protection is included to prevent a system from accepting an
   old new SPI packet.  There is still the opening for an attacker to
   produce a packet with exactly the right Sequence Number and old SPI
   with a malformed signature, consuming considerable computing
   resources.  All implementations must design to mitigate this attack.
   If ESP protected datagrams are still being received; there is an
   obvious attack.  If the peer is quite, it is easier for an attacker
   to launch this sort of attack, but again, the system should be able
   to recognize a regular influx of malformed signatures and take some
   action.

   There is a similar attack centered on the readdress packet.  Similar
   defense mechanisms are appropriate here.

   Since not all hosts will ever support HIP, ICMP 'Destination
   Protocol Unreachable' are to be expected and present a DOS attack.
   Against an initiator, the attack would look like the responder does
   not support HIP, but shortly after receiving the ICMP message, the
   initiator would receive a valid R1 HIP packet.  Thus to protect
   against this attack, an initiator should not react to an ICMP
   message until a reasonable delta time to get the real responder's R1
   HIP packet.  A similar attack against the responder is more
   involved.  First an ICMP message is expected if the I1 was a DOS
   attack and the real owner of the spoofed IP address does not support
   HIP.  The responder SHOULD NOT act on this ICMP message to remove
   the minimal state from the R1 HIP packet, but wait for either a
   valid I2 HIP packet or the natural timeout of the R1 HIP packet.
   This is to allow for a sophisticated attacker that is trying to
   break up the HIP exchange.  Likewise, the initiator should ignore
   any ICMP message while waiting for an R2 HIP packet, deleting state
   only after a natural timeout.

   Another MITM attack is simulating a responder's rejection of a HLP
   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.

Moskowitz                                                           26

                        Host Identity Payload           November 2001




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

   IANA will assign a SPI of NN for use in the ESP header of the
   optional I2 HIP packet.


12. ICANN Considerations

   ICANN will need to set up the HIT.int zone and accredit the
   registered assigning authorities (RAA) for HAA field.  With 21 bits,
   ICANN can allocate just over 2M registries.


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                         |
     \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Transform Classes    Values

        HIP_ENC         1
        ESP_ENC         2
        ESP_AUTH        3

   HIP Encryption Algorithm     Values [IPSEC-REGISTRY]


Moskowitz                                                           27

                        Host Identity Payload           November 2001


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

   ESP Encryption Algorithm     Value [ISAKMP-REGISTRY]

        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 AES                 12

   ESP Authenticat Algorithm    Value

        RESERVED                0-1
        MD5                     2
        SHA                     3
        DES                     4


APPENDIX B.  Proposed change to the HIP Formats


   There is a proposed simplification of the HIP payload.  It still
   uses a variable format.

   The HIP header remains unchanged:

    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)                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RCOUNT               |           FQDNLGTH            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |

Moskowitz                                                           28

                        Host Identity Payload           November 2001


   /                              FQDN                             /
   /                                                               /
   |                                        0 ¡ 3 bytes padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A change, though is if there is no FQDN, FQDNLGTH = 0 instead of '.'
   This saves 4 bytes.  Padding of FQDN is also changed to 32 bit
   boundry instead of 64 bit.

   Each HIP Resource Record will be formated as:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            RLength            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                             RDATA                             /
   /                                                               /
   |                                      0 ¡ 3 bytes padding      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Codes are taken from DNS Types:

           Name                    Length

   1       A                       32
   24      SIG                     variable
   25      KEY                     variable
   28      AAAA                    128
   41      OPT                     variable

   Only Opt uses Identifier:

           Name                    Length

   1       HIT                     128
   2       HIP_CNTLS               variable
   3       HIP_COOKIE              192
   4       HIP_TRANSFORM           variable
   5       ESP_TRANSFORM           variable
   6       ENCRYPTED               variable
   7       BIRTHDAY                64
   8       LSI                     32
   9       SPI                     32
   10      ID                      64

   Only I2 uses ENCRYPTED.  Encrypted requires a 2-phase parsing.
   First it is parsed, then decrypted, and then its contents are
   parsed.

   There is only one optimization left to consider.  That is with
   HIP_CNTLS.  It COULD be put up in the header:

Moskowitz                                                           29

                        Host Identity Payload           November 2001



    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)                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        HIP CONTROLS                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RCOUNT               |           FQDNLGTH            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                              FQDN                             /
   /                                                               /
   |                                        0 ¡ 3 bytes padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This saves one byte in R1, I2, and R2 and costs a byte in I1, NES,
   and REA, and any future HIP packet.  I am disinclined to do this...


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.

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



Moskowitz                                                           30

                        Host Identity Payload           November 2001


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

   [IPSEC-REGISTRY],
        ftp://ftp.isi.edu/in-notes/iana/assignments/ipsec-registry

   [ISAKMP-REGISTRY],
        ftp://ftp.isi.edu/in-notes/iana/assignments/isakmp-registry


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.  Bill
   Sommerfeld supplied the Birthday concept to simplify reboot
   management.  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
   TruSecure Corporation
   1200 Walnut Bottom Rd.
   Carlisle, PA  17013
   Email: rgm@trusecure.com



Moskowitz                                                           31

                        Host Identity Payload           November 2001


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                                                           32


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