[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06                                          
                                                  R. Moskowitz, ICSA.net
Internet Draft
Document: <draft-moskowitz-hip-arch-00.txt>            Dec 1999


                          Host Identity Payload
                              Architecture


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


1. Abstract

   This memo describes the reasoning behind proposing a new namespace,
   the Host Identity, and a payload, between the Internetworking and
   Transport layers, to carry this identity.  Herein is presented the
   basics of the current namespaces, strengths and weaknesses, and how
   a new namespace will add completeness to them.  This new namespace's
   roles in the protocols are defined.  This document provides the
   details of this namespace and protocol.

2. Conventions used in this document

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


3. Introduction

   The Internet has created two namespaces: Internet Protocol (IP)
   addresses, and Domain Name Services (DNS) names.  These two
   namespaces have a set of features and abstractions that have powered
   the Internet to what it is today.  They also have a number of


Moskowitz                                                            1

                  Host Identity Payload Architecture     December 1999


   weaknesses. IP addresses define an interface, not a host and not
   every host has one permanently, so they cannot reliably be used for
   host authentication systems.  Few systems on the Internet have DNS
   names.  DNS names are also only indirect references to IP addresses,
   though this changes in part with DNSSEC and KEY records.  Although
   each namespace can be stretched (IP with v6, DNS with KEY records),
   neither can adequately provide for host authentication or act as a
   separation between Internetworking and Transport layers.


4. Background


   The Internet is built from three principle components: Computing
   platforms, Packet transport infrastructure, and Services
   (applications).  The Internet exists to service two principle
   components: People and Robotic processes (silicon based people, if
   you will).  All these components need to be named in order to
   interact in a scalable manner.

   There are three principle namespaces in use in the Internet for
   these components: IP numbers, Domain Names, and Email addresses.

   IP addresses provide naming for the Transport Infrastructure
   interfaces on computing platforms.  IP addresses assignments are
   centrally controlled and delegated in blocks.  There is little
   anonymity in IP addresses.  IPv4 addresses provide a unique (non-
   singular sometimes), but non-global names.  IPv6 addresses MAY
   provide globally-unique (non singular regularly?) names.  Most IP
   address assignment is transient, making IP addresses an unreliable
   namespace outside of packet delivery.

   Domain Names provide hierarchically assigned names for some
   computing platforms and some services.  Each hierarchy is delegated
   from the level above; there is no anonymity in Domain Names.

   Email addresses provide naming for both carbon and silicon based
   people.  Email addresses are extensions of Domain Names, only in so
   far as a named service is responsible for managing a person's mail.
   There is some anonymity in Email addresses.

   There are three critical deficiencies with the current namespaces.
   Computing platforms are not well named with the current namespaces.
   Anonymity is not provided in a consistent, trustable manner.  And
   authentication is not provided.

   A namespace for computing platforms can be used in end-to-end
   operations independent of the evolution of the internetworking layer
   and across the many transport layers.  If this namespace is
   cryptographically based, it can also provide authentication
   services.  If this namespace is locally created without requiring
   registration, it can provide anonymity.


Moskowitz                                                            2

                  Host Identity Payload Architecture     December 1999


   Such a namespace (for computing platforms) should have the following
   characteristics:

        It is applied to the IP 'kernel'.  The IP kernel is the
        'component' between services and the packet transport
        infrastructure.

        It should not mandate any infrastructure.  Deployment must come
        from the bottom up, in a pairwise deployment.

        It should be fixed length.  For easy inclusion in datagrams.

        It MUST be statistically globally unique.  64 bits is
        inadequate (1% chance of collision in a population of 640M);
        thus approximately 128 bits should be used.

        It SHOULD be locally created.  This can provide anonymity at
        the cost of making resolvability is very difficult.

        Sometimes it MAY contain a delegation component.  This is the
        cost of resolvability.

        It SHOULD provide authentication services.  This is a preferred
        function.

        It should be long lived, but replaceable at any time.  This
        impacts access control lists; short lifetimes will tend to
        result in tedious list maintenance or require a namespace
        infrastructure for central control of access lists.

        It should be affordable when used in protocols.  This is
        primarily a packet size issue.

        It should fully decouple the Internetworking layer from the
        higher layers.  It should replace all occurrences of IP
        addresses within applications.  This may require API changes.

        It should have a localized abstraction so that it can be used
        in existing protocols and APIs.

   This new namespace will be called the Host Identity.  It will
   require its own protocol layer (the Host Identity Payload), between
   the Internetworking and Transport layers.  It will be based on
   Public Key Cryptography to supply authentication services.  Properly
   designed, it can deliver all of the above stated requirements.




5. Host Identity

   The Host Identity represents a statistically globally unique name
   for naming any system with an IP stack.  This identity is normally

Moskowitz                                                            3

                  Host Identity Payload Architecture     December 1999


   associated with an IP stack. A system can have multiple identities,
   some 'well known', some anonymous.  A system may self assert its
   identity, or may use a third-party authenticator like DNSSEC, PGP,
   or X.509 to 'notarize' the identity assertion.

   Host Identity adds two main features to Internet protocols.  The
   first is a decoupling of the internetworking and transport layers.
   This decoupling will allow for independent evolution of the two
   layers.  Additionally it can provide end-to-end services over
   multiple internetworking realms.  The second feature is host
   authentication.  If the Host Identity is a public key, this key can
   be used to authenticate security protocols like IPsec.

   The preferred 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.  Any other Internet
   naming convention MAY be used for the Host Identity.  However, these
   should only be used in situations of high trust - low risk.  That is
   any place where host authentication is not needed (no risk of host
   spoofing) and no use of IPsec.

   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.  If the
   Host Identity is a public key, it SHOULD be stored in a DNS KEY RR
   with the protocol set to HIP.  A Host Identity Global Hash (HIGH) is
   used in protocols to represent the Host Identity.  Another
   representation of the Host Identity, the Endpoint Selector (ESEL)
   can also be used in protocols and APIs.  ESEL's advantage over HIGH
   is its size; its disadvantage is its local scope.


5.1. Host Identity Global Hash (HIGH)

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

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

   There are two formats for HIGH.  Bit 0 is used to differentiate the
   formats.  If Bit 0 is zero, then the rest of HIGH is a 127 bits of a
   Hash of the key.  For example, if the Identity is DSA, these bits

Moskowitz                                                            4

                  Host Identity Payload Architecture     December 1999


   are the least significant 127 bits of the SHA-1 [FIPS-180-1] hash of
   the DSA public key Host Identity.

   If Bit 0 is one, then the next 63 bits is the Host Assigning
   Authority field, and only the last 64 bits come from a hash of the
   Host Identity.  This format for HIGH is recommended for 'well known'
   systems.  It is possible to support a resolution mechanism for these
   names in directories like DNS.

   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.


5.1.1. Storing HIGH in DNS

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


5.2. Host Assigning Authority (HAA) field

   The 63 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 23 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].50.100.high.int   IN PTR  www.foo.com.


5.3. Endpoint Selector (ESEL)

   ESELs are 32 bit localized representations of a Host Identity.  The
   purpose of an ESEL is to facilitate using Host Identities in
   existing protocols and APIs.  Each host selects its own 32 bit
   representation for a Host Identity.  It SHOULD be random, it COULD
   be sequential if security systems will not be relying on it.  The
   owner of the Host Identity does not set its ESEL; the risk of
   collisions is too great (1% in a population of 10,000).  Since the


Moskowitz                                                            5

                  Host Identity Payload Architecture     December 1999


   ESEL only has meaning to the host, its generation is a local policy
   issue.

   Examples of how ESELs can be used include: as the SPI in IPsec, as
   the destination IP address inside a IP tunnel, as the address in a
   FTP command, and as the address in a socket call.  Thus ESELs act
   both as a bridge for Host Identity into old protocols and APIs and a
   packet compression mechanism for Host Identity in general.


5.4. Using ESELs in place of IP addresses

   ESELs can be used in place of IP addresses in socket calls.  This
   can be accommodated with the aid of a modified resolver module.
   When a HIP exchange produces, and exchanges the ESELs, either the
   ESEL can be provided to the applications in place of the IP
   addresses and then the HIP module perform any substitution required,
   or the HIP module can intercept all address requests and use the
   ESEL where appropriate.

   At issue here is when do applications get IP addresses, and where do
   they use them.  The ESELs are not established until the 3rd and 4th
   HIP packets, which may be too late for some applications.  If the
   applications are using IP addresses within their data stream (as FTP
   commands do), the HIP module will have to perform tasks similar to a
   NAT to find these addresses and replace them with the appropriate
   ESEL.

   If the applications are using ESELs (as could be the case on
   subsequent connections during the lifetime of the HIP state), then
   the HIP module directs opens to ESELs to the appropriate IP address.
   The HIP module would not need to perform NAT functions on imbedded
   IP addresses.


6. Using the Host Identity

   There are a number of ways that Host Identity can be used in
   Internet Protocols.  The first is to use it in IKE [IKE].  HIGH can
   be used in Main Mode.  For this, the Host Identity MUST be a Public
   Key, and an appropriate Main Mode authentication (e.g. DSA
   signature) used.  The ESEL of the HIGH can replace the usage of IP
   addresses in IKE.  An appropriate ISAKMP [ISAKMP] payload will be
   needed to accommodate the Host Identity and HIGH.  These additions
   to IKE would produce a mode of operation for IKE that could traverse
   a NAT.  This, coupled with ESP transport mode, would produce a NAT
   friendly IPsec mode (note that the NATs can alter none of the data
   within the ESP).

   Another, and perhaps more powerful mode is a new, lightweight,
   protocol that will allow for one host to convey its Host Identity to
   another host.  This Host Identity Protocol will enable two hosts to
   exchange Host Identity and related information and rapidly establish

Moskowitz                                                            6

                  Host Identity Payload Architecture     December 1999


   an ESP Security Association.  It will lack the fine-grain controls
   of IKE and some of IKE's security features (like identity
   protection).


7. The Host Identity Payload


   The goal of the Host Identity Payload or HIP is to provide for a
   host identity, in most cases a trustable identity, in every IP
   datagram (see below for HIP packet compression).  This identity can
   be used to enable IPsec to provide authenticity and privacy.  HIP
   can supply the Host Identity for NAT state functions.

   HIP can be used as an alternative to IKE when fine-grain controls
   are not needed.  In fact, HIP SHOULD be used with IPsec to bind its
   identity to the datagram.  HIP can make protocols like IPsec's ESP
   NAT friendly.  There is nothing in HIP that is tied to an IP
   address.  Of course the ESP payload can have imbedded IP addresses
   that, since authenticated, cannot be altered by a NAT.


7.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  |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |               Host Identity Global Hash (HIGH)                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     HIP Key payload                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ESP followed by IP payload (opt)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.2. HIP Key Payload

   The HIP Key Payload is used to carry the public key associated with
   the HIGH and related security information.  The format of the HIP
   Key Payload is a simplification of a DNS message [DNS].  Since only
   the answer portion of a message is needed, the payload consists of
   ANCOUNT field of the message header followed by the indicated number
   of resource records.

   The resource records will either be a KEY (e.g. DSA and D-H), SIG
   [DNSSEC], or OPT [EDNS] record.  The first resource record in the

Moskowitz                                                            7

                  Host Identity Payload Architecture     December 1999


   HIP payload will contain the host's FQDN, if it has one, otherwise
   this field will be null.  All other resource records for the host
   will use message compression.  The RDATA of the OPT record in the
   payload can contain any of the following:

   OPT Attribute        Length          Data

   Remotes_HIGH         128             Remote's HIGH
   HIP_COOKIE           192             3 64 bit fields:
                                        Random #, either I or J
                                        SHA1(random#, I) truncated
                                        F(I,J) (zero in 1st 2 cookies)
   HIP_TRANSFORM        variable        ISAKMP Transform [ISAKMP]
                                        Without first 32 bits
                                        Using Ipsec DOI
   Remotes_ESEL         32              Remote's ESEL


7.3. HIP Rekey Payload

   During the life of an Security Association established by HIP, one
   of the hosts may need to rekey.  The reason for rekeying might be a
   sequence number rap in ESP, or a local policy on use of a key.  The
   Rekey Payload permits a host to change its Diffie-Hellman key and
   thus the keying material for ESP.  The Rekey Payload 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 of the
   rekeying; there is no next protocol in the HIP packet.  Thus the
   datagram looks like:

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

   When a host receives a Rekey Payload, its next ESP packet MUST use
   the KEYMAT generated by the new Kij.  The sending host MUST expect
   at least a sequence number replay window worth of ESP packets using
   the old Kij.  Out of order delivery could result in needing the old
   Kij after packets start arriving using the new Kij.  Once past the
   rekeying start, the sending host can drop the old Kij.


8. HIP Scenarios

   There are a number of scenarios for using HIP.  The variables in
   these scenarios are the number of address realms (managed by NATs)
   and the jurisdictional location of the boundaries, and the type of
   Host Identity (public key or string like an FQDN).


8.1. HIP Scenario #1

   Initiator and Responder in common addressing realm (i.e. both public
   or both private).


Moskowitz                                                            8

                  Host Identity Payload Architecture     December 1999


   Initiator gets IP address of Responder somehow.
        Hard coded (bad)
        DNS lookup
                DNSSEC important
                A HIP aware client should always retrieve HIP records
                        too.  The default DNS records would be a DSA
                        and HIGH KEY RR with protocol of HIP.  This is
                        important for the Initiator to validate packet
                        #3.

   I --> DNS (lookup R)
   I <-- DNS (R's info)
   I --> R (Hi, let's talk HIP)
   I <-- R (OK, handle this HIP cookie)
   I --> R (Compute, compute, here is my counter HIP with ESP protected
           data)
   I <-- R (OK, LetÆs finish HIP cookie, and here is my ESP protected
           data)

   Initiator sends first packet with HIP
        HIP Includes: HIGH, [Responder's HIGH (from DNS query)]
        Next protocol = 0

   Responder sends first packet with HIP
        HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                If multiple HI, match Initiator's request
                HIP_COOKIE contains random I
                        I is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Is
                HIP_TRANSFORM contains the ESP modes supported by the
                        responder
                SIG calculated over whole HIP
                Next protocol = 0

        Must keep state on I and DH pair.  Can reduce costs in event of
        a DOS attack by using the same DH for a number of connects over
        some time.  Additionally, the same I might be used if a large
        number of attempts come from different addresses in a short
        time (classic DOS attack).  Initiator must validate the HIP
        SIG, minimally with included HI.  If HI is received during
        initial DNS query, this should be used.

   Initiator sends second packet with HIP
        HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                HIP_COOKIE contains random J and Hash(current_secret,
                        I).  J is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Js
                The ESEL will become the ESP SPI
                HIP_TRANSFORM contains selected ESP algorithms

Moskowitz                                                            9

                  Host Identity Payload Architecture     December 1999


                SIG calculated over whole HIP
        Next Protocol is ESP
                Optional encryption and mandatory auth
                Kij used from KEYMAT, Default is 3DES, HMAC-SHA1
                SPI is the Responder's ESEL of the Initiator, but don't
                        have ESEL yet, so 1st packet uses SPI = Random
                        #
                ESP payload is first data gram

        Must keep state of I, J, DH pair, and Responder's DH, ESEL and
        ESP TRANSFORM used.

   Responder sends second, and last, packet with HIP
        HIP Includes: HIP_COOKIE, Initiator ESEL and SIG
                The ESEL will become the ESP SPI
                HIP_COOKIE contains random I, Hash(current_secret, I),
                        and F(I,J)
        Next Protocol is ESP
                SPI is the Initiator's ESEL of the Responder
                ESP payload is data gram

        Must keep state of DH pair, and Initiator's DH, ESEL and ESP
        TRANSFORM used.

   All further packets are without HIP, HIP is implied with the SPIs =
   ESELs --> HIGH


8.2. HIP Scenario #2

   Initiator behind NAT, Responder publicly addressed.


   Initiator gets IP address of Responder somehow.
        Hard coded (bad)
        DNS lookup
                DNSSEC important
                A HIP aware client should always retrieve HIP records
                        too.  The default DNS records would be a DSA
                        and HIGH KEY RR with protocol of HIP.  This is
                        important for the Initiator to validate packet
                        #3.
                If no default route to NAT, DNS ALG provides NAT with
                        Responder's IP address and HIGH; NAT provides
                        DNS ALG with substitute internal address.

   I --> NAT(I) --> DNS (lookup R)
   I <-- NAT(I) <-- DNS (R's info, record it in NAT)
   I --> NAT(I) --> R (Hi, let's talk HIP)
   I <-- NAT(I) <-- R (OK, handle this HIP cookie)
   I --> NAT(I) --> R (Compute, compute, here is my counter HIP with
           ESEL(R) and ESP protected data)


Moskowitz                                                           10

                  Host Identity Payload Architecture     December 1999


   I <-- NAT(I) <-- R (OK, LetÆs finish HIP cookie, and here is ESEL(I)
           and my ESP protected data)

   Initiator sends first packet with HIP
        HIP Includes: HIGH, [Responder's HIGH (from DNS query)]
        Next protocol = 0
        NAT records Initiator's HIGH and address makes address changes
                in IP header

   Responder sends first packet with HIP
        HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                If multiple HI, match Initiator's request
                HIP_COOKIE contains random I
                        I is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Is
                HIP_TRANSFORM contains the ESP modes supported by the
                        responder
                SIG calculated over whole HIP
                Next protocol = 0

        Must keep state on I and DH pair.  Can reduce costs in event of
        a DOS attack by using the same DH for a number of connects over
        some time.  Additionally, the same I might be used if a large
        number of attempts come from different addresses in a short
        time (classic DOS attack).  Initiator must validate the HIP
        SIG, minimally with included HI.  If HI is received during
        initial DNS query, this should be used.
        NAT changes addresses based on HIGHs in HIP.

   Initiator sends second packet with HIP
        HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                HIP_COOKIE contains random J and Hash(current_secret,
                        I).  J is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Js
                The ESEL will become the ESP SPI
                HIP_TRANSFORM contains selected ESP algorithms
                SIG calculated over whole HIP
        Next Protocol is ESP
                Optional encryption and mandatory auth
                Kij used from KEYMAT, Default is 3DES, HMAC-SHA1
                SPI is the Responder's ESEL of the Initiator, but don't
                        have ESEL yet, so 1st packet uses SPI = Random
                        #
                ESP payload is first data gram

        Must keep state of I, J, DH pair, and Responder's DH, ESEL and
        ESP TRANSFORM used.
        NAT adds Initiator's Responder ESEL to I/R state and changes
        addresses.

Moskowitz                                                           11

                  Host Identity Payload Architecture     December 1999




   Responder sends second, and last, packet with HIP
        HIP Includes: HIP_COOKIE, Initiator ESEL and SIG
                The ESEL will become the ESP SPI
                HIP_COOKIE contains random I, Hash(current_secret, I),
                        and F(I,J)
        Next Protocol is ESP
                SPI is the Initiator's ESEL of the Responder
                ESP payload is data gram

        Must keep state of DH pair, and Initiator's DH, ESEL and ESP
        TRANSFORM used.
        NAT adds Responder's Initiator ESEL to I/R state and changes
        addresses.

   All further packets are without HIP, HIP is implied with the SPIs =
   ESELs --> HIGH
   NAT uses ESELs for address state.
   Hosts use ESELs in place of IP addresses inside protocols.
        E.G. Initiator uses Responder's Initiator ESEL (packet 4) for
   FTP port command.  Responder is able to remap this to state it has
   on Initiator.


8.3. HIP Scenario #3

   Initiator publicly addressed, Responder behind NAT.

   NAT configured with Responder's IP address and HIGH.  DNS for the
   responder will have the NAT's address.

   Initiator gets IP address of Responder (NAT) somehow.
        Hard coded (bad)
        DNS lookup
                DNSSEC important
                A HIP aware client should always retrieve HIP records
                        too.  The default DNS records would be a DSA
                        and HIGH KEY RR with protocol of HIP.  This is
                        important for the Initiator to validate packet
                        #3.
                If no default route to NAT, NAT maps Initiator's HIGH
                        and ESEL to an internal address.  Since the
                        ESEL has to be used after HIP exchange, and
                        ESEL is on a host basis, the Initiator will use
                        a separate internal address for each internal
                        host.

   I --> DNS (lookup R, get NAT's address and R's HIGH)
   I <-- DNS (R's info)
   I --> NAT(R) --> R (Hi, let's talk HIP)
   I <-- NAT(R) <-- R (OK, handle this HIP cookie)


Moskowitz                                                           12

                  Host Identity Payload Architecture     December 1999


   I --> NAT(R) --> R (Compute, compute, here is my counter HIP with
           ESEL(R) and ESP protected data)
   I <-- NAT(R) <-- R (OK, LetÆs finish HIP cookie, and here is ESEL(I)
           and my ESP protected data)

   Initiator sends first packet with HIP
        HIP Includes: HIGH, Responder's HIGH (from DNS query)
        Next protocol = 0
        NAT records Initiator's HIGH and address makes address changes
                in IP header.  Uses Responder's HIGH to map to
                responder.

   Responder sends first packet with HIP
        HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                If multiple HI, match Initiator's request
                HIP_COOKIE contains random I
                        I is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Is
                HIP_TRANSFORM contains the ESP modes supported by the
                        responder
                SIG calculated over whole HIP
                Next protocol = 0

        Must keep state on I and DH pair.  Can reduce costs in event of
        a DOS attack by using the same DH for a number of connects over
        some time.  Additionally, the same I might be used if a large
        number of attempts come from different addresses in a short
        time (classic DOS attack).  Initiator must validate the HIP
        SIG, minimally with included HI.  If HI is received during
        initial DNS query, this should be used.
        NAT changes addresses based on HIGHs in HIP.

   Initiator sends second packet with HIP
        HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                HIP_COOKIE contains random J and Hash(current_secret,
                        I).  J is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Js
                The ESEL will become the ESP SPI
                HIP_TRANSFORM contains selected ESP algorithms
                SIG calculated over whole HIP
        Next Protocol is ESP
                Optional encryption and mandatory auth
                Kij used from KEYMAT, Default is 3DES, HMAC-SHA1
                SPI is the Responder's ESEL of the Initiator, but don't
                        have ESEL yet, so 1st packet uses SPI = Random
                        #
                ESP payload is first data gram



Moskowitz                                                           13

                  Host Identity Payload Architecture     December 1999


        Must keep state of I, J, DH pair, and Responder's DH, ESEL and
        ESP TRANSFORM used.
        NAT adds Initiator's Responder ESEL to I/R state and changes
        addresses.  The NAT will have one responder HIGH to address
        state, but potentially many responder ESEL to address state.


   Responder sends second, and last, packet with HIP
        HIP Includes: HIP_COOKIE, Initiator ESEL and SIG
                The ESEL will become the ESP SPI
                HIP_COOKIE contains random I, Hash(current_secret, I),
                        and F(I,J)
        Next Protocol is ESP
                SPI is the Initiator's ESEL of the Responder
                ESP payload is data gram

        Must keep state of DH pair, and Initiator's DH, ESEL and ESP
        TRANSFORM used.
        NAT adds Responder's Initiator ESEL to I/R state and changes
        addresses.

   All further packets are without HIP, HIP is implied with the SPIs =
   ESELs --> HIGH
   NAT uses ESELs for address state.
   Hosts use ESELs in place of IP addresses inside protocols.
        E.G. Initiator uses Responder's Initiator ESEL (packet 4) for
   FTP port command.  Responder is able to remap this to state it has
   on Initiator.


8.4. HIP Scenario #4

   Initiator and Responder behind separate NATs.

   NAT configured with Responder's IP address and HIGH.  DNS for the
   responder will have the NAT's address.

   Initiator gets IP address of Responder (NAT) somehow.
        Hard coded (bad)
        DNS lookup
                DNSSEC important
                A HIP aware client should always retrieve HIP records
                        too.  The default DNS records would be a DSA
                        and HIGH KEY RR with protocol of HIP.  This is
                        important for the Initiator to validate packet
                        #3.
                If no default route to initiator's NAT, DNS ALG
                        provides NAT with Responder's IP address and
                        HIGH; NAT provides DNS ALG with substitute
                        internal address.
                If no default route to responder's NAT, NAT maps
                        Initiator's HIGH and ESEL to an internal
                        address.  Since the ESEL has to be used after

Moskowitz                                                           14

                  Host Identity Payload Architecture     December 1999


                        HIP exchange, and ESEL is on a host basis, the
                        Initiator will use a separate internal address
                        for each internal host.

   I --> NAT(I) --> DNS (lookup R, get NAT's address and R's HIGH)
   I <-- NAT(I) <-- DNS (R's info, record it in NAT)
   I --> NAT(I) --> NAT(R) --> R (Hi, let's talk HIP)
   I <-- NAT(I) <-- NAT(R) <-- R (OK, handle this HIP cookie)
   I --> NAT(I) --> NAT(R) --> R (Compute, compute, here is my counter
           HIP with ESEL(R) and ESP protected data)
   I <-- NAT(I) <-- NAT(R) <-- R (OK, LetÆs finish HIP cookie, and here
           is ESEL(I) and my ESP protected data)

   Initiator sends first packet with HIP
        HIP Includes: HIGH, Responder's HIGH (from DNS query)
        Next protocol = 0
        Initiator's NAT records Initiator's HIGH and address makes
        address changes in IP header
        Responder's NAT records Initiator's HIGH and address makes
                address changes in IP header.  Uses Responder's HIGH to
                map to responder.

   Responder sends first packet with HIP
        HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                If multiple HI, match Initiator's request
                HIP_COOKIE contains random I
                        I is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Is
                HIP_TRANSFORM contains the ESP modes supported by the
                        responder
                SIG calculated over whole HIP
                Next protocol = 0

        Must keep state on I and DH pair.  Can reduce costs in event of
        a DOS attack by using the same DH for a number of connects over
        some time.  Additionally, the same I might be used if a large
        number of attempts come from different addresses in a short
        time (classic DOS attack).  Initiator must validate the HIP
        SIG, minimally with included HI.  If HI is received during
        initial DNS query, this should be used.
        Both NATs changes addresses based on HIGHs in HIP.

   Initiator sends second packet with HIP
        HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH,
            HIP_TRANSFORM, and SIG
                HIP_COOKIE contains random J and Hash(current_secret,
                        I).  J is internal pointer to DH
                HIP_DH is ephemeral, but can be reused
                        Scavenger cleans up unused DHs and Js
                The ESEL will become the ESP SPI
                HIP_TRANSFORM contains selected ESP algorithms

Moskowitz                                                           15

                  Host Identity Payload Architecture     December 1999


                SIG calculated over whole HIP
        Next Protocol is ESP
                Optional encryption and mandatory auth
                Kij used from KEYMAT, Default is 3DES, HMAC-SHA1
                SPI is the Responder's ESEL of the Initiator, but don't
                        have ESEL yet, so 1st packet uses SPI = Random
                        #
                ESP payload is first data gram

        Must keep state of I, J, DH pair, and Responder's DH, ESEL and
        ESP TRANSFORM used.
        Initiator's NAT adds Initiator's Responder ESEL to I/R state
        and changes addresses.
        Responder's NAT adds Initiator's Responder ESEL to I/R state
        and changes addresses.  The NAT will have one responder HIGH to
        address state, but potentially many responder ESEL to address
        state.


   Responder sends second, and last, packet with HIP
        HIP Includes: HIP_COOKIE, Initiator ESEL and SIG
                The ESEL will become the ESP SPI
                HIP_COOKIE contains random I, Hash(current_secret, I),
                        and F(I,J)
        Next Protocol is ESP
                SPI is the Initiator's ESEL of the Responder
                ESP payload is data gram

        Must keep state of DH pair, and Initiator's DH, ESEL and ESP
        TRANSFORM used.
        NAT adds Responder's Initiator ESEL to I/R state and changes
        addresses.

   All further packets are without HIP, HIP is implied with the SPIs =
   ESELs --> HIGH
   Both NATs uses ESELs for address state.
   Hosts use ESELs in place of IP addresses inside protocols.
        E.G. Initiator uses Responder's Initiator ESEL (packet 4) for
   FTP port command.  Responder is able to remap this to state it has
   on Initiator.


8.5. Refusing a HIP exchange

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

   If the host's policy does not permit it to enter into a HIP exchange
   with the initiator, it should send an ICMP Host Unreachable,
   Administratively Prohibited message.  A more complex HIP packet is

Moskowitz                                                           16

                  Host Identity Payload Architecture     December 1999


   not used here as it actually opens up more potential DOS attacks
   than a simple ICMP message.


9. ESP with HIP

   HIP sets up a Security Association (SA) to enable ESP in an end-to-
   end manner that can span addressing realms (i.e. across NATs).  This
   is accomplished through the various information that is exchanged
   within HIP.  It is anticipated that since HIP is designed for host
   usage, that is not for gateways, that only ESP transport mode will
   be supported with HIP.  The SA is not bound to an IP address, all
   internal control of the SA is by the HIGH and ESEL.  Thus a host can
   easily change its address using Mobile IP, DHCP, or PPP and still
   maintain the SA.  So real-world conditions like loss of a PPP
   connection and its reestablishment will not require a HIP
   negotiation.

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


9.1. Security Parameters Index (SPI)

   HIP uses the ESELs as the SPIs in ESP.  This provides simple
   compression of the HIP data from all packets after the HIP exchange.
   The very first ESP packet from the Initiator occurs before the
   Initiator has the ESEL from the Responder.  For this packet a random
   number is used.  The Responder will have to maintain the relation of
   that random number to the ESEL, so that when the next packet from
   the Initiator with the ESEL for the SPI arrives, the Responder
   recognizes that this is the same SA.

   This does result in a per host-pair SPI, and a decrease of policy
   granularity over other KMPs like IKE.


9.2. Sequence Number

   The Sequence Number field is MANDATORY in ESP [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.


Moskowitz                                                           17

                  Host Identity Payload Architecture     December 1999



9.3. 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
   Iesp or Resp Data packet from Host
   Inm or Rnm   host sent packet n, and received packet m



      +---------+
      | Ioo,Roo |<----------------------------+
      +---------+                             |
           |                                  |
           | I1->R                            |
           |                                  |
           v                                  |
      +---------+                             |
      | Ioo,Roo |                             |
      +---------+                             |
           |                                  |
           | R1->I                            |
           |                                  |
           v                                  | After I receives
      +---------+                             |  x ICMPs
      | Ioo,Roo |                             |
      +---------+                             |
           |                                  |
           | I2->R                            |
           |                                  |
           v                                  |
      +---------+    I2->R   +---------+      |
      | I1o,Ro1 |<-----------| Ioo,Rmn |      |
      +---------+            +---------+      |
           |                      ^           |
           | R2->I                | R1->I     |
           |                      |           |
           v                      |           |
      +---------+            +---------+      |
      | I11,R11 |            | Ioo,Rmn |      |
      +---------+            +---------+      | +---------+
           |                      ^           | | Inm,Roo |-+
           | ESP                  | I1->R     | +---------+ |
           | Packets              |           |  ^          |
           v      I reboots  +---------+      |  | Iesp->R  | Ricmp
      +---------+ ---------->| Ioo,Rmn |      |  |          |  ->I
   +->| Inm,Rmn | or timeout +---------+     +---------+    |
   |  +---------+ -------------------------->| Inm,Roo |<---+
   |    |    | ^         R reboots           +---------+
   |ESP |    | +------+  or timeout
   |Pckt|Rrky|Irky    |

Moskowitz                                                           18

                  Host Identity Payload Architecture     December 1999


   |    |->I |->R     |ESP
   |    |    +----+   |packet
   |    v         v   |
   +---------+  +---------+
   | In1,R1n |  | I1m,Rm1 |  {rekeying states}
   +---------+  +---------+


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 MIM attacks that potentially could be more damaging to a
   host's ability to conduct business as usual.

   The Security Association for ESP is indexed by the ESEL-SPI, not the
   SPI and IP address.  HIP enabled ESP is IP address independent.
   This might seem to make it easier for an attacker, but ESP with
   replay protection is already as well protected as possible, and the
   removal of the IP address as a check should not increase the
   exposure of ESP to DOS attacks.

   Denial-of-service attacks take advantage of the cost of start of
   state for a protocol on the responder compared to the 'cheapness' on
   the initiator.  HIP makes no attempt to increase the cost of the
   start of state on the initiator, but makes an effort to reduce the
   cost to the responder.  This is done by having the responder start
   the 3-way cookie exchange instead of the initiator, making the HIP
   protocol 4 packets long.

   This shifting of the start of state cost to the initiator in
   creating the I2 HIP packet, presents another DOS attack.  The
   attacker spoofs the I1 HIP packet and the responder sends out the R1
   HIP packet.  This could conceivably tie up the 'initiator' with
   evaluating the R1 HIP packet, and creating the I2 HIP packet.  The
   defense against this attack is to simply ignore any R1 packet where
   a corresponding I1 was not sent.

   A second form of DOS attack is emulating the restart of state after
   a reboot of one of the partners.  To protect against such an attack
   on the responder, it should send reply to an I1 HIP packet without
   resetting its state.  Only on receipt of an I2 HIP packet within a
   reasonable delta after sending its R1 HIP packet, should the
   responder reset its state.  An initiator protects itself be ignoring
   any R1 or R2 packets while it has state with R.

   A third form of DOS attack is emulating the end of state.  HIP has
   no end of state packet.  It relies on a local policy timer to end
   state.



Moskowitz                                                           19

                  Host Identity Payload Architecture     December 1999


   Man-in-the-middle attacks are difficult to defend against, without
   third-party authentication.  A skillful MIM could easily handle all
   parts of HIP; but HIP indirectly provides the following protection
   from a MIM 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 MIM attack.  The responder may
   choose not to accept a HIP exchange with an anonymous initiator.

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

   Another MIM 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 MIM
   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.

10.1. Non-security Considerations

   The definition of the Host Identity states that the HI need not be a
   public key.  That the HI could be any value; for example an FQDN.
   This document does not describe how to support a non-cryptographic
   HI.  Such a HI would still offer the services of the ESEL for NAT
   traversal.  It would carry the ESELs in an ESP that had neither
   privacy nor authentication (ESP EMPTY).  Since this mode of HIP
   would offer so little additional functionality for so much addition
   to the IP kernel, it has not been defined in this document.  Given

Moskowitz                                                           20

                  Host Identity Payload Architecture     December 1999


   how little public key cryptography HIP requires, HIP SHOULD only be
   implemented using public key Host Identities.


11. IANA Considerations

   IANA has assigned Protocol number XX to HIP.

   A new KEY RR protocol of XX is assigned to HIP and an algorithm of
   XX is assigned to HIGH128.

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


12. ICANN Considerations

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


13. References

   [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997

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

   [DNSBIN], Crawford, M., "Binary Labels in the Domain Name System",
   RFC 2673, August 1999.

   [IKE], Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC
   2409, November 1998.

   [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol", RFC
   2408, November 1998.

   [DNS], Mockapetris, P., "Domain Names - Implementation And
   Specification", RFC 1035, November 1987.

   [DNSSEC], Eastlake, D., "Domain Name System Security Extensions",
   RFC 2535, March 1999.

   [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August
   1998.

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

Moskowitz                                                           21

                  Host Identity Payload Architecture     December 1999




14. Acknowledgments

   The drive to create HIP came to being after attending the MALLOC
   meeting at IETF 43.  It has matured considerably since the early
   drafts thanks to extensive input from IETFers.  Particular mention
   goes to the members of the NameSpace Research Group of the IRTF.
   Noel Chiappa provided the framework for ESELs and Kieth Moore the
   impetuous to provide resolvability.  Steve Deering provided
   encouragement to keep working, as a solid proposal can act as a
   proof of ideas for a research group.  Many others contributed;
   extensive security tips were provided by Steve Bellovin.  Rob
   Austein kept the DNS parts on track.

15. Author's Addresses

   Robert Moskowitz
   ICSA.net
   1200 Walnut Bottom Rd.
   Carlisle, PA  17013
   Email: rgm@icsa.net
































Moskowitz                                                           22