Internet DRAFT - draft-heer-hip-lhip

draft-heer-hip-lhip






Host Identity Protocol                                           T. Heer
Internet-Draft                                    RWTH Aachen University
Intended status: Standards Track                           February 2007
Expires: August 5, 2007


           LHIP Lightweight Authentication Extension for HIP
                         draft-heer-hip-lhip-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   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.

   This Internet-Draft will expire on August 5, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies the Lightweight authentication extension for
   the Host Identifier Protocol (LHIP).  The goal of LHIP is to reduce
   the computational requirements of the Host Identifier Protocol (HIP),
   thus, making its benefits, such as end-host mobility and multihoming,
   accessible to CPU-restricted devices.  LHIP reduces the computational



Heer                     Expires August 5, 2007                 [Page 1]

Internet-Draft               Lightweght HIP                February 2007


   cost of establishing, updating, and closing a HIP association by
   providing an alternative way of signing and verifying HIP control
   packets which is based on computationally inexpensive hash function
   computations and hash chains.  However, LHIP does not provide nor
   does it aim at providing the same level of security as HIP does.
   Especially, host authentication and payload encryption are not
   possible.  The LHIP extensions in this draft specify also mechanisms
   for dynamic transitioning between lightweight and full HIP
   associations on the fly.

Requirements Language

   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 [RFC2119]


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  LHIP Security  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Cryptographic Techniques used in LHIP  . . . . . . . . . . . .  8
     3.1.  One-Time Signatures  . . . . . . . . . . . . . . . . . . .  8
     3.2.  Hash Chains  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Interactive Hash Chain-Based Signatures  . . . . . . . . .  9
   4.  Lightweight Authentication Extension for HIP . . . . . . . . . 10
     4.1.  Supported Hash Functions . . . . . . . . . . . . . . . . . 10
     4.2.  Hash Chain Creation  . . . . . . . . . . . . . . . . . . . 10
     4.3.  IHC-based Signatures in LHIP . . . . . . . . . . . . . . . 11
       4.3.1.  Initiating the Signature Process . . . . . . . . . . . 12
       4.3.2.  The First Signature Packet: S1 . . . . . . . . . . . . 13
       4.3.3.  The First Acknowledgement Packet: A1 . . . . . . . . . 13
       4.3.4.  The Second Signature Packet: S2  . . . . . . . . . . . 14
       4.3.5.  The Second Acknowledgement Packet: A2  . . . . . . . . 14
       4.3.6.  Host Mobility with LHIP  . . . . . . . . . . . . . . . 15
       4.3.7.  Overhead of IHC-based Signatures . . . . . . . . . . . 16
     4.4.  LHIP Parameters  . . . . . . . . . . . . . . . . . . . . . 16
       4.4.1.  HCA parameter  . . . . . . . . . . . . . . . . . . . . 16
       4.4.2.  HCE Parameter  . . . . . . . . . . . . . . . . . . . . 18
       4.4.3.  PS Parameter . . . . . . . . . . . . . . . . . . . . . 18
       4.4.4.  PACK, PNACK, HACK, and HNACK Parameters  . . . . . . . 19
       4.4.5.  LFLAGS Parameter . . . . . . . . . . . . . . . . . . . 20
     4.5.  LHIP Packets . . . . . . . . . . . . . . . . . . . . . . . 21
       4.5.1.  The S1 Packet  . . . . . . . . . . . . . . . . . . . . 21
       4.5.2.  The A1 Packet  . . . . . . . . . . . . . . . . . . . . 21
       4.5.3.  The S2 Packet  . . . . . . . . . . . . . . . . . . . . 22
       4.5.4.  The A2 Packet  . . . . . . . . . . . . . . . . . . . . 22
       4.5.5.  Source and Destination Addresses . . . . . . . . . . . 22



Heer                     Expires August 5, 2007                 [Page 2]

Internet-Draft               Lightweght HIP                February 2007


     4.6.  State Machines . . . . . . . . . . . . . . . . . . . . . . 23
       4.6.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . 23
       4.6.2.  SIGNER State Machine . . . . . . . . . . . . . . . . . 24
       4.6.3.  VERIFIER State Machine . . . . . . . . . . . . . . . . 26
       4.6.4.  State Loss . . . . . . . . . . . . . . . . . . . . . . 27
     4.7.  Predefined Signals . . . . . . . . . . . . . . . . . . . . 28
     4.8.  Unprotected HIP Control Packets  . . . . . . . . . . . . . 28
     4.9.  LHIP Handshake . . . . . . . . . . . . . . . . . . . . . . 28
       4.9.1.  LHIP Transform Suites  . . . . . . . . . . . . . . . . 29
       4.9.2.  Hash Chain Anchors . . . . . . . . . . . . . . . . . . 29
       4.9.3.  Diffie-Hellman Parameters  . . . . . . . . . . . . . . 30
       4.9.4.  ECHO_REQUEST parameter . . . . . . . . . . . . . . . . 30
       4.9.5.  RSA and DSA Signatures . . . . . . . . . . . . . . . . 30
       4.9.6.  Authenticated Hash Chain Anchors . . . . . . . . . . . 31
       4.9.7.  Encrypted Host Identifiers . . . . . . . . . . . . . . 32
       4.9.8.  Puzzle Mechanism . . . . . . . . . . . . . . . . . . . 32
       4.9.9.  Basic LHIP Base Exchange Overview  . . . . . . . . . . 32
       4.9.10. Use of IPsec and Other Payload Transfer Protocols  . . 33
       4.9.11. Concluding the LHIP Base Exchange  . . . . . . . . . . 34
     4.10. Chained Bootstrapping  . . . . . . . . . . . . . . . . . . 34
       4.10.1. Chained Bootstrapping for the INITIATOR  . . . . . . . 34
       4.10.2. Chained Bootstrapping for the RESPONDER  . . . . . . . 34
     4.11. Hash Chain Extension . . . . . . . . . . . . . . . . . . . 37
     4.12. LHIP Interaction with Middle-boxes . . . . . . . . . . . . 37
     4.13. Closing an LHIP Association  . . . . . . . . . . . . . . . 38
     4.14. Upgrading an LHIP Association  . . . . . . . . . . . . . . 38
       4.14.1. The First Upgrade Packet . . . . . . . . . . . . . . . 38
       4.14.2. The Second Upgrade Packet  . . . . . . . . . . . . . . 40
       4.14.3. Concurrent Upgrade Initialization  . . . . . . . . . . 40
       4.14.4. HIP Downgrade  . . . . . . . . . . . . . . . . . . . . 40
       4.14.5. Upgrade DoS Attack . . . . . . . . . . . . . . . . . . 40
       4.14.6. Sequence Numbers . . . . . . . . . . . . . . . . . . . 40
     4.15. State Loss . . . . . . . . . . . . . . . . . . . . . . . . 41
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 42
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 42
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 43
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 44
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 45










Heer                     Expires August 5, 2007                 [Page 3]

Internet-Draft               Lightweght HIP                February 2007


Notation

   +-----------+-------------------------------------------------------+
   | Symbol    | Explanation                                           |
   +-----------+-------------------------------------------------------+
   | [x]       | indicates that x is optional.                         |
   | [x/y]     | indicates that either x or y is present.              |
   | x_y       | indicates that y is an index of x.                    |
   | x_{yz}    | indicates that yz is an index of h.                   |
   | X(y)      | indicates that y is a parameter of X.                 |
   | |         | signifies concatenation.                              |
   | x=?y      | signifies a check whether x equals y.                 |
   | peer      | denotes the remote host the local host is             |
   |           | communicating to, using HIP or LHIP.                  |
   | MESSAGE   | denotes a HIP control packet (I1, R1, UPDATE, etc)    |
   |           | which a host intends to transmit to its peer.         |
   |           | Transmitting a MESSAGE may require to transmit        |
   |           | several packets.                                      |
   | MSG       | is used as shorthand for MESSAGE.                     |
   | SIG       | is used as shorthand for SIGNATURE.                   |
   | SIGNER    | denotes the sender of an IHC-signed MESSAGE.          |
   | VERIFIER  | denotes the receiver of an IHC-signed MESSAGE.        |
   | INITIATOR | is the host which initiates a HIP or LHIP             |
   |           | association.                                          |
   | RESPONDER | is the host which responds to the INITIATOR.          |
   | -->       | signifies "SIGNER to VERIFIER" or "INITIATOR to       |
   |           | RESPONDER" communication.                             |
   | <--       | signifies "VERIFIER to SIGNER" or "RESPONDER to       |
   |           | INITIATOR" communication.                             |
   | rcv       | is used as shorthand for receive or received.         |
   | snd       | is used as shorthand for send or sent.                |
   | ack, nack | are used as shorthands for acknowledgment and         |
   |           | negative acknowledgment.                              |
   | hybrid    | denotes a hybrid host which supports HIP as well as   |
   |           | LHIP.                                                 |
   | anchor    | denotes the first element of a hash chain (h_n) in    |
   |           | reverse order of creation.                            |
   | seed      | denotes the last element of a hash chain (r) in       |
   |           | reverse order of creation.  The seed is the random or |
   |           | pseudo-random value from which the hash chain is      |
   |           | created.                                              |
   | HMAC-F    | denotes a function which generates an HMAC.  The      |
   |           | function takes a message as first parameter and a key |
   |           | as second parameter.                                  |
   +-----------+-------------------------------------------------------+






Heer                     Expires August 5, 2007                 [Page 4]

Internet-Draft               Lightweght HIP                February 2007


1.  Introduction

   The Host Identity Protocol (HIP) [I-D.ietf-hip-base] decouples the
   transport from the network layer by introducing a new namespace.
   Using Host Identities (HIs) for addressing hosts allows IP addresses
   to be pure locators which enables hosts to use several locators or to
   change their locators without breaking transport-layer connections.
   This way, HIP provides end-host mobility and multihoming support for
   a wide range of appliances.  HIP uses public-key cryptography to
   verify the identity of hosts and to generate symmetric keys that are
   used for data encryption and integrity protection.  Despite of the
   valuable security features which public-key cryptography offers, it
   also imposes a non-negligible computational cost which complicates
   the use of HIP on devices with few CPU resources.

   LHIP puts aside the benefits of data encryption and end-host
   authentication in favor of a computationally inexpensive way of
   providing integrity protection for HIP control packets.  Thus,
   allowing CPU-restricted devices to use the mobility and multihoming
   features of HIP.  Therefore, HIP payload from upper protocol layers
   is neither encrypted nor authenticated and the HIs of hosts are not
   verified.  Nevertheless, it is necessary to provide a way to
   authenticate HIP control packets, especially the UPDATE packets which
   allow to modify an established HIP association, in order to allow the
   HIP protocol to perform secure mobility and multihoming updates.

   The integrity protection mechanisms which HIP employs to secure HIP
   control packets rely on public-key cryptography.  Hosts use Hash
   Message Authentication Codes (HMACs) with keys that are generated
   from an Authenticated Diffie-Hellman (DH) key exchange [DH71].
   Moreover, the UPDATE packets must be signed with RSA [RFC3110] or DSA
   [RFC2536] signatures to allow verification by middle-boxes which are
   not in possession of the shared secret for the HMAC.  In order to
   reduce HIPs dependency on PK cryptography, LHIP introduces a new way
   of authenticating HIP control messages which is mainly based on
   cryptographic hash functions and one-way hash chains.  The
   Interactive Hash Chain (IHC) approach [I-D.ylitalo-multi6-wimp] and
   one-time signatures [Lam81] provide the basis for this authentication
   mechanism.

   The authentication functionality of LHIP is conceptually located
   below the HIP-layer in order to be transparent to the basic HIP
   protocol.  The task of protecting HIP payload is delegated to LHIP.
   Therefore, LHIP disables the security mechanisms which protect
   control packets in HIP.  HIP passes unprotected HIP control packets
   to LHIP which applies lightweight packet authentication if necessary.
   However, there are packets which can not be protected (payload) and
   packets which do not not require protection.  These packets are sent



Heer                     Expires August 5, 2007                 [Page 5]

Internet-Draft               Lightweght HIP                February 2007


   unprotected.  Figure 1 depicts the location of LHIP in the networking
   stack.




   Layering of HIP and LHIP:


               .-----------------------------------------------.
               |                                               |
               |                   UDP / TCP                   |
               |                                               |
               +-----------------------------------------------+
               |                             |                 |
               |           HIP / LHIP        |     Payload     |
               +-----------------------------+                 |
               |      LHIP authentication    |                 |
               |  unprotected  |  protected  |   unprotected   |
               +-----------------------------+-----------------+
               |                                               |
               |                      IP                       |
               |                                               |
               +-----------------------------------------------+

                                 Figure 1

   LHIP and HIP share the same host identity namespace but LHIP does not
   authenticate the HIs of hosts except in cases of conflicts and
   potential attacks (cf. Section 4.9.5).  This allows LHIP to reuse the
   HIP namespace and name resolution mechanisms without performing CPU-
   intensive PK computations.  A host can use the same HI for HIP and
   LHIP associations depending on whether the additional security
   features of HIP are required or not.  However, using LHIP and HIP for
   an identical pair of source HI and destination HI at the same time is
   not possible.  Despite the benefits of sharing the same HI namespace,
   some security issues arise when using the same HIs for LHIP and HIP.
   Section 4.9.5 discusses these issues and specifies defense mechanisms
   against potential attacks.

   The life-cycle of a typical LHIP association is similar to the life-
   cycle of a HIP association.  First, two hosts establish a
   communication context during the Base EXchange (BEX).  Then, they
   update the association due to locator changes and, finally, they
   close the association.  LHIP modifies all of these steps to reduce
   the computational cost of each.  Moreover, an LHIP host has the
   option to upgrade an established LHIP association to a full HIP
   association.



Heer                     Expires August 5, 2007                 [Page 6]

Internet-Draft               Lightweght HIP                February 2007


   LHIP was explicitly designed to support the basic HIP protocol
   functions and basic mobility and multihoming.  The generic design of
   LHIP also enables PK-less authentication for many other HIP
   extensions.  However, defining the behavior of LHIP when it used with
   other HIP extensions is future work.

   The decision when to use HIP and when to use LHIP should either be
   based on a set of policies or be taken by the application which
   initiates or accepts a new HIP association.  Applications should use
   an appropriate API [I-D.komu-btns-api] [I-D.mkomu-hip-native-api] to
   communicate this decision.  The decision when to upgrade an LHIP
   association should also be expressed via this API.

   LHIP does not replace but extends HIP.  Therefore, this document only
   focuses on changes and extensions of the basic HIP protocol and its
   mobility and multihoming extensions [I-D.ietf-hip-mm].  All aspects
   of HIP which are not mentioned explicitly in this document remain
   identical to HIP.


2.  LHIP Security

   LHIP does not use the Diffie-Hellman key exchange and, consequently,
   can not use a shared secret to encrypt or authenticate packets with
   symmetric encryption algorithms or conventional Hashed Message
   Authentication Code (HMAC) [RFC2104].  Therefore, only payload
   transport protocols which do not rely on symmetric keys can be used
   with LHIP.  The LHIP authentication mechanisms do not provide any
   integrity protection for HIP payload.  All authentication mechanisms
   defined in this document refer to HIP control messages.

   LHIP does not necessarily verify the identity of hosts as this
   procedure requires the use of PK signatures.  However, host
   authentication is can be requested either by the INITIATOR or the
   RESPONDER of an LHIP association during the BEX if necessary.
   Similar to HIP end-hosts, middle-boxes can only verify the identity
   of a host when this host uses RSA or DSA signatures during the BEX or
   during the update process.

   LHIP can not protect against Man in the Middle (MitM) attacks during
   the BEX.  However, it protects against such attacks after the BEX,
   especially, during location updates.  This is an important feature as
   mobile devices are likely to be exposed to attackers on the
   communication path if they change their point of network attachment
   frequently.

   The following list summarizes the security properties of LHIP:




Heer                     Expires August 5, 2007                 [Page 7]

Internet-Draft               Lightweght HIP                February 2007


   Integrity:  LHIP allows to verify the integrity of HIP control
      messages and, therefore, protects these against malicious data
      manipulation.  LHIP payload is unprotected.

   Authentication of packet origin:  LHIP allows to verify that several
      consecutive HIP control packets relate to the same origin.
      However the identity of the origin can only be verified if RSA or
      DSA is used during the LHIP handshake.  The origin of LHIP payload
      can not be determined in any way.

   Replay protection:  LHIP protects HIP control messages from replay
      attacks.  It does not provide replay protection for payload.

   Confidentiality:  LHIP does neither encrypt HIP control packets nor
      payload.

   Protection against MitM attacks:  LHIP protects against MitM attacks
      after the BEX.

   Due to the non-obligatory host authentication and the inability to
   encrypt payload, it is RECOMMENDED to use LHIP only when the
   application does not require such security.  LHIP can be used when
   security is employed by other protocols in higher or lower protocol
   layers.


3.  Cryptographic Techniques used in LHIP

   This chapter introduces the necessary terms and principles which
   relate to message authentication for LHIP.

3.1.  One-Time Signatures

   Lamport proposed one-time signatures based on hash functions [Lam81].
   A host uses two sufficiently large random or pseudo-random numbers
   r_1 and r_2, applies a pre-image-resistant cryptographic one-way hash
   function H to both, and keeps them secret.  It publishes H(r_1) and
   H(r_2) as public key.  The host signs a one-bit message by either
   disclosing r_1 as signature S when the value of the bit is 1.
   Otherwise, it discloses r_2.  A receiver can verify the authenticity
   of the single bit by comparing the hash of the signature H(S) to the
   public key values H(r_1) and H(r_2).

3.2.  Hash Chains

   A host uses chains of hashes to create a sequence of related hash
   values [Lam81].  The host uses such hash chains to tie together
   several signatures, allowing the host to relate all signatures to one



Heer                     Expires August 5, 2007                 [Page 8]

Internet-Draft               Lightweght HIP                February 2007


   sender without repeatedly exchanging public-key hashes.  Iterative
   application of the hash function to a random or pseudo-random number
   forms a sequence of values hc = {h_1 = H(r), h_2 = H(h_1) = H(H(r)),
   ... , Hn = H(h_n-1)}.  The host discloses the elements of the hash
   chain in reverse order of their creation beginning with h_n.  This
   sequence hc has three properties which are useful for LHIP:

   i) Given h_{i-1} and h_i, it is easy to verify that h_{i-1} belongs
      to the same hash chain as h_i by verifying that H(h_{i-1}) equals
      h_i.

   ii)  It is computationally hard to find h_{i-1} if only h_i is given.

   iii)  Given h_{i+1}, it is hard to find an h_i' with H(h_i') =
      h_{i+1}.

   The first element of the hash chain in reverse order of creation
   (h_i) is denoted hash chain anchor.  The last element of the hash
   chain in reverse order of creation (r) is denoted as the seed of the
   hash chain.

3.3.  Interactive Hash Chain-Based Signatures

   HMAC provides a computationally inexpensive way to verify the
   integrity of a packet.  However, HMAC requires a shared secret (a
   symmetric key) to be exchanged beforehand.  Several communication
   protocols (e.g.  TESLA[RFC4082] and WIMP[I-D.ylitalo-multi6-wimp])
   circumvent this restriction by using elements of hash chains as key
   for the HMAC signature.

   The basic idea behind hash chain based packet authentication is to
   use HMACs with temporary secrets instead of shared secrets.  A SIGNER
   of a message sign the message with an HMAC which uses secret value,
   only known to the SIGNER, as key.  In the absence of an encrypted
   channel to the VERIFIER, the SIGNER must transmit the message, the
   signature, and the HMAC key in cleartext to the receiver in order to
   allow it to verify the signature.  Attackers cannot change the
   message unnoticeably because hosts accept messages only if the
   signature has been created before the key was disclosed.  This
   ensures that only the host in possession of the secret was able to
   sign the message before it was disclosed.  Using hash chains as
   source for the keys, allows to relate several consequent signatures
   to the owner of a hash chain.

   Temporally separating the time of signing and transmitting the
   message from the time of disclosing and transmitting the secret key
   is crucial for the security of hash chain based signatures.  WIMP
   uses an interactive approach to guarantee this separation.  Hosts



Heer                     Expires August 5, 2007                 [Page 9]

Internet-Draft               Lightweght HIP                February 2007


   must acknowledge the receipt of a signature before the secret key is
   disclosed.

   WIMP uses elements of hash chains to prevent attackers from sending
   forged acknowledgments.  Every host adds an element of its hash chain
   h_i to the acknowledgment to allow the SIGNER to verify the origin of
   the acknowledgment.  The SIGNER can verify the origin of the hash
   chain element by comparing H(h_i) to the most recently disclosed
   element of the VERIFIER's hash chain h_{i+1} : H(h_i)=?h_{i+1}.  It
   only discloses the secret key (the next element of its own hash
   chain) if this test succeeds.


4.  Lightweight Authentication Extension for HIP

   LHIP modifies the way in which HIP authenticates messages but leaves
   most of the other functionality of HIP untouched.  This way, other
   HIP extensions can use LHIP transparently.  The LHIP authentication
   protocol is conceptually located below HIP and above the network
   layer.  LHIP acts as output and input filter for HIP control packets
   and processes these whenever they arrive or are about to be sent.

   LHIP uses two mechanisms to protect HIP control mechanisms.  The
   first of these mechanisms is based on IHC signatures and can be used
   to sign and verify arbitrary content.  The second mechanism is based
   on one-time signatures and can be used to trigger predefined
   processes.  The following section specifies these mechanisms.

   The following sections define the LHIP authentication mechanism
   before the setup of an LHIP association is discussed.  Note that this
   order does not reflect the chronological order of the processes in
   the LHIP protocol as the LHIP association must be established before
   LHIP can authenticate HIP control packets.

4.1.  Supported Hash Functions

   LHIP hosts MUST support SHA-1 [RFC3174] for hash chain creation and
   verification.

4.2.  Hash Chain Creation

   In order to create a hash chain, a host must pick a random or pseudo-
   random number with the size of the hash function in use.  The host
   stores this number as first element of the hash chain (r).  It
   applies the selected hash function to it and stores the result as
   second element of the hash chain (h_1).  It repeats this process by
   always using the recently generated hash chain element as input of
   the hash function until it has stored a sufficient number of elements



Heer                     Expires August 5, 2007                [Page 10]

Internet-Draft               Lightweght HIP                February 2007


   (n).  It discloses the elements of the hash chain in reverse order of
   creation, beginning with h_n which it publishes as anchor value.  It
   MUST NOT disclose parts of the hash chain before all previous
   elements (in reverse order of creation) have been disclosed.

4.3.  IHC-based Signatures in LHIP

   This section gives an overview how LHIP authenticates HIP control
   messages.  The authentication process is based on the IHC signature
   approach.  It is only used to protect HIP control messages, such as
   UPDATE messages, that are exchanged after the HIP and LHIP Base
   EXchange (BEX) is completed.  The following explanations assume that
   the SIGNER and the VERIFIER of a MESSAGE have already established the
   LHIP association successfully.  Especially the anchor values of the
   hash chains in use must be exchanged during the BEX.  Moreover, the
   hash function which is used for generating and verifying the hash
   chains is negotiated during the BEX.

   When an LHIP host is about to send a HIP control message, it
   initiates the IHC-based signature process.  The transmission of this
   HIP MESSAGE with IHC-based protection requires to exchange four
   packets.  Two packets precede the HIP control message.  These packets
   are used to deliver the signature and to acknowledge its receipt.
   Then the HIP control message (e.g. an UPDATE packet) is sent.  LHIP
   attaches additional parameters to this control message to allow IHC-
   based authentication.  The fourth packet delivers an acknowledgment
   or negative acknowledgment of the successful verification of the
   MESSAGE.

   As four packets are used for securing one single MESSAGE, this
   document differentiates between packets which are sent within the
   IHC-based signature process and the MESSAGE which is protected by
   these packets.

   Each LHIP host uses two distinct IHC-signature related hash chains
   for every LHIP association: one for signing MESSAGES and one for
   receiving and acknowledging packets of the IHC-based signature
   process.  The hash chain which is used when the host acts as SIGNER
   is denoted SIGNATURE_CHAIN and the hash chain which is used when the
   host acts as VERIFIER is denoted TRIGGER_CHAIN.  The hosts exchange
   the anchors of SIGNATURE_CHAIN and TRIGGER_CHAIN during the BEX.  In
   the following description, the anchor of the SIGNER's SIGNATURE_CHAIN
   is denoted hs_i and the anchor of the VERIFIER's TRIGGER_CHAIN is
   denoted ht_i.  These anchors have been exchanged previously.

   A schematic overview of the signature process is depicted in
   Figure 2.  It is followed by a description of the packets and
   mechanisms involved in the signature process.



Heer                     Expires August 5, 2007                [Page 11]

Internet-Draft               Lightweght HIP                February 2007


   The modified IHC signature process as used by LHIP:


      SIGNER                                          VERIFIER

                      S1: hs_{i-1}, PRE_SIG
                     -------------------------->

                                                H(hs_{i-1})?=hs_i:
                                                Buffer PRE_SIG

                      A1: ht_i, PACK, PNACK
                     <--------------------------

    H(ht_{i-1})=?ht_i:
    Buffer PACK, PNACK

                      S2: hs_{i-2}, MESSAGE (i.e. UPDATE)
                     -------------------------->

                                             HMAC-F(MESSAGE, hs_{i-2})=?
                                              PRE_SIG

                      A2: ht_{i-2}, [secret_ack/
                                       secret_nack]
                     <--------------------------
   HMAC-F("__[n]ack[_]__"|
     secret_[n]ack,
     ht_{i-2})=?[PACK/PNACK]


                 ... further signature processes....

                      S1:  hs_{i-3}, PRE_SIG
                     -------------------------->
                    .                           .
                    .                           .
                    .                           .

                                 Figure 2

4.3.1.  Initiating the Signature Process

   The signature process begins when an LHIP host is about to transmit a
   protected MESSAGE (HIP control message) to its peer.  The host which
   intends to send the MESSAGE acts as SIGNER and the host which
   receives the MESSAGE acts as VERIFIER.  The SIGNER can only send
   MESSAGES one by one.  Therefore, it must enqueue and delay concurrent



Heer                     Expires August 5, 2007                [Page 12]

Internet-Draft               Lightweght HIP                February 2007


   MESSAGES.

4.3.2.  The First Signature Packet: S1

   The first (S1) of the four signature packets contains a unused clear-
   text element from the SIGNER's SIGNATURE_CHAIN (hs_{i-1}) which
   allows the VERIFIER to verify the origin of the packet.  It also
   contains the signature of the MESSAGE which the SIGNER wants to
   transmit.  The signature is denoted pre-signature (PRE_SIG) because
   the S1 packet does not contain the actual MESSAGE to which the
   signature belongs to.  The pre-signature is created with the HMAC
   algorithm for which the next element of the SIGNER's SIGNATURE_CHAIN
   is used as key.  Due to the ambiguity of the term HMAC in HIP (HMAC
   algorithm/function and HMAC parameter) the term HMAC-F is used when
   referring to the algorithm.  (PRE_SIG = HMAC-F(MESSAGE, hs_{i-2}) ).

   The VERIFIER must verify that the packet was sent by the SIGNER by
   comparing the hash of the clear-text hash chain element hs_{i-1} to
   the anchor of the SIGNER's signature chain ( H(hs_{i-1})=?hs_i ).  It
   can not verify the MESSAGE at this point as it neither knows the
   MESSAGE nor the key for the HMAC signature.  Therefore, it stores the
   PRE_SIG until the MESSAGE and the key are transmitted.  The VERIFIER
   must not accept any further packets containing hs_{i-1} and, most
   importantly, MUST NOT buffer further PRE_SIGs after it has sent the
   A1 packet.

4.3.3.  The First Acknowledgement Packet: A1

   The receiver sends an acknowledgment packet (A1) to the SIGNER to
   acknowledge the receipt of the S1 packet.  It attaches the next
   undisclosed element of its TRIGGER_CHAIN ht_{i-1} to the packet as
   proof that it has received the S1 packet.

   LHIP provides an acknowledged MESSAGE delivery service which means
   that the SIGNER gets a signed acknowledgment if the verification was
   successful and a signed negative acknowledgment if the verification
   has failed.  LHIP piggy-backs these signed acks and nacks on the IHC-
   signature packets to reduce the overhead for these.  Therefore, the
   VERIFIER attaches a pre-signature of the ack and the nack to the A1
   message.  As the outcome of the verification is unclear, when sending
   the A2, it must attach both pre-signatures (for an ack and nack) to
   the A1 packet.  The pre-signature of the acknowledgment is denoted
   PACK and the pre-signature of the negative acknowledgment is denoted
   PNACK.  They are computed as follows:

            PACK  = HMAC-F("__ack___" | secret_ack ,  ht_{i-2})
            PNACK = HMAC-F("__nack__" | secret_nack,  ht_{i-2})




Heer                     Expires August 5, 2007                [Page 13]

Internet-Draft               Lightweght HIP                February 2007


   The message strings for the PACK and PNACK consist simple ASCII
   strings concatenated with pseudo-random numbers (secret_ack and
   secret_nack).  The pseudo-random numbers prevent that the message
   text can be guessed and that a acknowledgment or negative
   acknowledgment can be forged.

   On receipt of the A1 packet, the SIGNER MUST check that the clear-
   text hash chain element in the A1 packet belongs to the VERIFIER's
   TRIGGER chain by computing H(hs_{i-1})=?hs_i.  A successful check
   indicates that the VERIFIER has received the S1 packet and that the
   SIGNER can send the MESSAGE and the key of the pre-signature now.
   The SIGNER MUST buffer the PACK and the PNACK value from the A1
   packet.  It MUST not accept any further PACK or PNACK values before
   receiving the S2 packet.

4.3.4.  The Second Signature Packet: S2

   The SIGNER sends the MESSAGE and the next undisclosed elements of its
   hash chain hs_{i-2} to the VERIFIER in the second signature packet
   (S2).  This is the hash chain element which was used to create the
   PRE_SIG value.

   After receiving the S2 packet, the VERIFIER verifies that the packet
   was sent by the SIGNER.  It does so by computing
   H(hs_{i-2})=?hs_{i-1}.  If the test succeeds, it verifies the
   integrity of the MESSAGE by computing PRE_SIG=?HMAC-F(MESSAGE,
   hs_{i-2}).  The signature is valid if this test succeeds.  The
   authentication protocol delivers the MESSAGE (the HIP control
   message, such as an UPDATE) to the appropriate HIP protocol functions
   in case of an successful verification.

4.3.5.  The Second Acknowledgement Packet: A2

   The A2 packet from the VERIFIER to the SIGNER contains the next
   element of the VERIFIER's TRIGGER_CHAIN ht_{i-2} and the secret_ack
   if the verification of the signature was successful.  The packet
   contains secret_nack if the signature was invalid.

   The SIGNER determines whether the signature process was successful
   after receiving the A2 packet.  It verifies that the VERIFIER has
   sent the A2 packet and compares the secret_ack or secret_nack to the
   PACK or PNACK by computing PACK=?HMAC-F("__ack___" | secret_ack ,
   ht_{i-2}) or PNACK=?HMAC-F("__nack__" | secret_nack , ht_{i-2}),
   respectively.  The acknowledgment or negative acknowledgment is valid
   when this test succeeds.






Heer                     Expires August 5, 2007                [Page 14]

Internet-Draft               Lightweght HIP                February 2007


4.3.6.  Host Mobility with LHIP

   This section gives a short example how LHIP protects the message
   exchange during an HIP location update.  In our example, this basic
   location update consists of three UPDATE MESSAGES.  The mobile host
   transmits a set of new locators in the first UPDATE MESSAGE.  The
   stationary host acknowledges this set of new locators and sends an
   ECHO_REQUEST in the second UPDATE MESSAGE.  The mobile host replies
   the ECHO_RESPONSE in the third UPDATE MESSAGE.

   The first and the second update MESSAGES are protected by IHC-based
   signatures while the third UPDATE MESSAGE is unprotected.  The
   decision to leave this MESSAGE unprotected is based upon the fact
   that modifications to this packet can not go unnoticed even without
   signatures.  The reason for this is that the packet carries only an
   ECHO_RESPONSE in order to verify a locator.  Figure 3 shows the whole
   process in a simplified way.  The protected HIP UPDATE MESSAGES are
   marked with an (x).

   HIP update with LHIP:


          MOBILE HOST                             STATIONARY HOST

                 S1 (PRE_SIG of the 1st UPDATE packet)
                ------------------------------------>
                 A1 (Acknowledgment)
                <-------------------------------------
                 S2 (1st UPDATE MESSAGE)
                -------------------------------------> (x)
                 A2 (NACK or ACK)
              * <-------------------------------------


                 S1 (PRE_SIG of the 2nd UPDATE packet)
              * <-------------------------------------
                 A1 (Acknowledgment)
                 ------------------------------------->
                 S2 (2nd UPDATE MESSAGE)
                <------------------------------------- (x)
                 A2 (NACK or ACK)
              *  ------------------------------------->

                 3rd UPDATE packet (unprotected)
              *  -------------------------------------> (x)

                                 Figure 3




Heer                     Expires August 5, 2007                [Page 15]

Internet-Draft               Lightweght HIP                February 2007


   Notice that packets marked with an asterisk are sent in parallel,
   thus, reducing the transmission delay from 4.5 RTTs to 3.5 RTTs.

4.3.7.  Overhead of IHC-based Signatures

   The four IHC signature packets replace a single conventional RSA,
   DSA, or HMAC signed packet from the SIGNER to the VERIFIER.  This
   results in an additional delay of 1.5 Round-Trip Times (RTTs) per
   MESSAGE compared to HIP.  However, depending on the computational
   cost of generating the conventional signature, and the processing
   speed of the LHIP device, this signature scheme can still be
   advantageous because of its low computational cost.  Another
   advantage of LHIP is that Middle-boxes can verify the signatures
   without being in possession of a shared secret, which is required for
   HMAC based signatures.  This allows middle-boxes to verify the
   contents of HIP packets without using PK cryptography.

4.4.  LHIP Parameters

   LHIP control packets are identical to HIP control packets with the
   exception that HMAC parameters are calculated with a key of all
   zeroes instead of the DH-generated shared secret.  Therefore, the
   HMAC parameter contained in LHIP packets is just a message digest.
   LHIP uses this message digest as basis for the IHC-based signature.
   It protects only the HMAC parameter with IHC-based signatures, thus,
   protecting exactly the same fields of the HIP control packets that
   are protected by the HMAC parameter.  Reusing the HMAC parameter in
   this way ensures that the semantics of the HMAC parameter remain
   compatible with HIP.  Furthermore, no DSA or RSA signatures are
   applied which means that the corresponding HIP parameters are
   missing.  LHIP adds several other parameters to HIP control packets
   which allow IHC-based authentication.

4.4.1.  HCA parameter

   LHIP defines several types of hash chain anchors which are
   transmitted as Hash Chain Anchor (HCA) parameter in BEX or IHC-signed
   UPDATE packets.  A signed HIP control packet MAY contain several HCA
   parameters.  Unsigned HIP control packets MUST NOT contain any HCA
   parameters.  The different types of anchors are identified by an
   8-bit type field.  A packet MUST NOT contain several HCA parameters
   with the same type ID.  The VERIFIER MUST ignore such duplicate HCA
   parameters.

   Depending on the purpose of the hash chains that belong to the
   anchors, these hash chains should differ in length.  In the context
   of hash chains, length refers the number of elements in a hash chain.
   The SIGNATURE_CHAIN and the TRIGGER_CHAIN are used for IHC-based



Heer                     Expires August 5, 2007                [Page 16]

Internet-Draft               Lightweght HIP                February 2007


   signatures.  Each signature uses at least two hash chain elements.
   Therefore, the hash chain MUST at least consist of three elements,
   including the published anchor element to allow one successful
   signature.  It is RECOMMENDED to use larger number of elements to
   allow a larger number of updates before the hash chains are depleted.
   The CLOSE_CHAIN and the UPGRADE_CHAIN are used to secure predefined
   signals (cf. Section 4.13 and Section 4.14).  These two signals are
   only invoked once.  Therefore, a hash chain length of two elements is
   sufficient.  Other predefined signals, which may be defined by other
   HIP extensions in the future, may be invoked more often and would,
   therefore, require longer hash chains.  An overview of the currently
   defined hash chain types is given below.

   +-----------------+---------+--------------------------+------------+
   | Hash Chain      | Type ID | Predefined Signal        | Length     |
   +-----------------+---------+--------------------------+------------+
   | SIGNATURE_CHAIN | 1       | -                        | 1 + 2 x S* |
   | TRIGGER_CHAIN   | 2       | -                        | 1 + 2 x S* |
   | CLOSE_CHAIN     | 3       | Close LHIP association   | 2          |
   | UPGRADE_CHAIN   | 4       | Upgrade from LHIP to HIP | 2          |
   +-----------------+---------+--------------------------+------------+

     Hash chain attributes. *S means the number of expected signature
                        processes (positive value).

   The structure of the HCA parameter is depicted below.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Type            |C|             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Anchor Type  |                                               |
    +-+-+-+-+-+-+-+-+          Hash Value                           /
    /                                                               /
    /               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |                    Padding                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type           222
    Length         21 for SHA-1
    Anchor Type    Type ID of the corresponding hash chain
    Hash Value     The first element of the corresponding hash chain in
                   reverse order of creation (h_n).







Heer                     Expires August 5, 2007                [Page 17]

Internet-Draft               Lightweght HIP                February 2007


4.4.2.  HCE Parameter

   The Hash Chain Element parameter (HCE) contains the recently released
   element of the corresponding hash chain.  HCE parameters are used
   during the IHC-based signature process or to protect predefined
   signals.  When belonging to an IHC-based signature process, HCE
   parameters from the SIGNER MUST contain elements of the SIGNER's
   SIGNATURE_CHAIN and HCE parameters from the VERIFIER MUST contain
   elements of the VERIFIER's TRIGGER_CHAIN.  The length of the Hash
   Chain Element field is determined by the hash function which
   negotiated during the LHIP BEX (cf. Section 4.9).  The structure of
   the HCE parameter is depicted below.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type            |C|             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Chain Type   |                                               |
     +---------------'         Hash Chain Element                    /
     /                                                               /
     /               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                    Padding                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type                64702
     Length              21 for SHA-1
     Chain Type          The ID of the corresponding hash chain to
                         distinguish several HCE parameters which are
                         assigned to different predefined signals or
                         signature processes.
     Hash Chain Element  An element of the corresponding hash chain.


4.4.3.  PS Parameter

   The Pre-Signature (PS) parameter carries the pre-signature in the A1
   packet.  The pre-signature is an Hashed Message Authentication Code
   of the HMAC parameter contained in the HIP control packet.  Note that
   the HMAC parameter in the HIP packet is generated by using a key of
   zeroes when using LHIP.  Therefore, the HMAC does not protect the
   packet but provides a message digest which covers the packet.  The
   pre-signature HMAC is generated from this digest with the next
   undisclosed hash chain element as key.  The pre-signature is computed
   as follows: HMAC-F(HMAC,h_{i-1}).






Heer                     Expires August 5, 2007                [Page 18]

Internet-Draft               Lightweght HIP                February 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type            |C|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                        Pre-Signature                          /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type                64704
   Length              20 for SHA-1
   Pre-Signature       The pre-signature used in the IHC-based signature
                       process.

4.4.4.  PACK, PNACK, HACK, and HNACK Parameters

   The Pre-ACKnowledgment parameter (PACK) and the Pre-Negative-
   ACKnowledgment Parameter (PNACK) are used to transmit the PACK and
   PNACK values from the VERIFIER to the SIGNER in the A2 packet.

   The hash-based acknowledgment (HACK) and the corresponding negative
   acknowledgment (HNACK) contain the secret that was used to create the
   PACK or PNACK value, respectively.  The size of the secret must equal
   the output size of the hash function in use.

   The PACK, PNACK, HACK, and HNACK MUST be calculated according to the
   description in Section 4.3.3.  All four parameters have the same
   structure.  They consist of the HIP parameter header and a byte field
   containing the corresponding values.





















Heer                     Expires August 5, 2007                [Page 19]

Internet-Draft               Lightweght HIP                February 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type            |C|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /              [PACK/PNACK/secret_ack/secret_nack]              /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type                64725 for PACK
                       64727 for PNACK
                       64729 for HACK
                       64731 for HNACK
   Length              20 for SHA-1
   [PACK value/
     PNACK value/
     secret_ack/
     secret_nack]      The PACK, PNACK, secret_ack, or secret_nack value

4.4.5.  LFLAGS Parameter

   The LHIP-flags parameter allows hosts to transmit additional
   information about an LHIP association to their peers.  The LFLAGS
   parameter is transmitted in the R1 and the I2 packet of the LHIP BEX.
   It consists of the HIP parameter header and an 32-bit field.  The 32-
   bit field MUST be in network byte order.  Setting the corresponding
   bit to 1 indicates that the host sends the information defined below.

   +---------------------+-----+---------+-----------------------------+
   | Flag                | Bit | Integer | Meaning                     |
   +---------------------+-----+---------+-----------------------------+
   | LFLAG_REQUIRE_AUTH  | 0   | 1       | Peer must authenticate      |
   | LFLAG_OFFER_AUTH    | 1   | 2       | Host is willing to          |
   |                     |     |         | authenticate                |
   | LFLAG_OFFER_UPGRADE | 2   | 4       | Host is willing to upgrade  |
   +---------------------+-----+---------+-----------------------------+

   The structure of the LFLAGS parameter is depicted below.












Heer                     Expires August 5, 2007                [Page 20]

Internet-Draft               Lightweght HIP                February 2007


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type            |C|             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            FLAGS                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type                63404
     Length              4
     Flags               A bit-mask as defined above.

4.5.  LHIP Packets

   LHIP uses several additional HIP control packet types which are used
   to transmit the S1, A1, and A2 packet of the IHC-based signature
   process.  The Type of the S2 packet is determined by the type of the
   HIP control message which is protected by the IHC-based signatures.
   LHIP hosts MUST implement the S1, A1, and A2 packets.  The packets
   are defined as follows.

4.5.1.  The S1 Packet

   The transmission of the S1 packet is triggered by a transmission
   request from the basic HIP protocol.  The LHIP protocol queues and
   delays this transmission and prepares a new S1 packet.  This packet
   consists of the HIP packet header, the next hash chain element of the
   SIGNER encoded an HCE parameter, and the pre-signature of the queued
   original MESSAGE encoded as PS parameter.

                      Header:
                        Packet Type = 22 (preliminary)
                        SRC HIT = SIGNER's HIT
                        DST HIT = VERIFIER's HIT

                      IP ( HIP ( HCE, PS ) )

                      Valid control bits: none

4.5.2.  The A1 Packet

   The A1 packet is only sent as direct response to an S1 packet from
   the SIGNER.  It contains the HIP packet header, the next element of
   the VERIFIER's trigger-chain encoded as HCE parameter, and a PACK and
   a NACK parameter.






Heer                     Expires August 5, 2007                [Page 21]

Internet-Draft               Lightweght HIP                February 2007


                      Header:
                        Packet Type = 23 (preliminary)
                        SRC HIT = VERIFIER's HIT
                        DST HIT = SIGNER's HIT

                      IP ( HIP ( HCE, PACK, PNACK ) )

                      Valid control bits: none

4.5.3.  The S2 Packet

   The second signature packet S2 is the queued MESSAGE which was
   originally sent by the basic HIP protocol.  LHIP attaches an HCE
   parameter which contains the next undisclosed hash chain element from
   the SIGNER's signature-chain.  This HCE parameter allows the VERIFIER
   to a) determine that the packet was sent by the SIGNER and b) to
   verify the pre-signature sent in the S1 packet.  There is no special
   packet type for the S2 packet as the LHIP parameters are piggy-backed
   on the original MESSAGE sent by the basic HIP protocol.  The presence
   of a valid HCE parameter is sufficient for the VERIFIER to identify
   the packet as S2 packet.

4.5.4.  The A2 Packet

   The VERIFIER sends the A2 packet only as a direct response to the S2
   packet.  It contains the next element of the VERIFIER's hash chain
   encoded as HCE parameter and an HACK or HNACK parameter depending on
   whether the signed HIP MESSAGE was verified successfully or not.

                      Header:
                        Packet Type = 24 (preliminary)
                        SRC HIT = VERIFIER's HIT
                        DST HIT = SIGNER's HIT

                      IP ( HIP ( HCE, [HACK/HNACK] ) )

                      Valid control bits: none

4.5.5.  Source and Destination Addresses

   The correct choice of source and destination addresses in the IP
   headers of the S1 and A1 packets is important because these packets
   precede the actual HIP control message.  The control message can be
   part of an update process due to a change in a host's locator set.
   The source and destination address of the S1 packet MUST be the same
   as the source and destination address of the queued HIP control
   message from the basic HIP protocol.  The destination address of the
   A1 packet MUST be set to the source address of the corresponding S1



Heer                     Expires August 5, 2007                [Page 22]

Internet-Draft               Lightweght HIP                February 2007


   packet regardless of the preferred address and regardless of the
   previously announced set of locators of the SIGNER.  The source
   address of the A1 packet MUST be the address of the VERIFIER's
   interface on which the S1 packet was received.

4.6.  State Machines

   Temporally separating the transmission of the first and the third
   signature packet is crucial for the security of the IHC-signature
   scheme.  The following section provides two state machines.  They
   ensure temporal separation and handling of duplicate transmissions,
   undeliverable packets, and packet loss.  These state machines focus
   on the LHIP packet signature and verification process only.  They do
   not replace any existing HIP state machine but take over the process
   of sending an authenticated MESSAGE.  The state machines define the
   behavior of the SIGNER and the VERIFIER of an IHC-signed MESSAGE.
   Note that both LHIP peers MUST implement both state machines.  Each
   host can act as SIGNER of an IHC-signed MESSAGE and as VERIFIER of
   another IHC-signed MESSAGE at the same time.  Moreover, each host
   holds separate state information for every LHIP association which
   enables the host to process several IHC-signed MESSAGES from or to
   different hosts simultaneously.

4.6.1.  Terminology

   Depending on whether an element in an HCE parameter belongs to the
   peer's corresponding hash chain or not, and depending on when it was
   disclosed, a host classifies LHIP authentication packets into three
   classes:

   Valid:  A packet is valid when it contains a HCE parameter with the
      predecessor element of the most recently disclosed hash chain
      element of the same hash chain.  When, for instance, h_i is the
      last hash chain element disclosed by a host, only the value
      h_{i-1}, which fulfills the equation H(h_{i-1}) = h_i, is
      considered to be valid.

   Old:  A packet is old when the hash chain element in the HCE
      parameter equals to the most recently disclosed hash chain element
      of the corresponding hash chain.  Assuming that h_i is the last
      hash chain element disclosed by a host, further packets with h_i
      in the HCE parameter are considered to be old.

   Invalid:  A packet is invalid when it is neither old nor valid.

   LHIP hosts MUST drop packets with invalid HCE parameters.  Packets
   with old HCE parameters indicate duplicate transmissions or packet
   loss and must be handled according to the state machines specified



Heer                     Expires August 5, 2007                [Page 23]

Internet-Draft               Lightweght HIP                February 2007


   below.

4.6.2.  SIGNER State Machine

   The SIGNER state machine consists of three states.  Figure 4 depicts
   the SIGNER's state machine with conditions for the state transitions
   and the corresponding actions.  In the case of packet loss,
   retransmissions are always initiated by the SIGNER to avoid the
   possibility of traffic amplification for DoS attacks.

   +---------------+---------------------------------------------------+
   | State         | Explanation                                       |
   +---------------+---------------------------------------------------+
   | INITIAL/READY | State machine start, ready for new IHC signature  |
   |               | process.  Waiting for HIP control packet to be    |
   |               | sent.                                             |
   | S1-SENT       | Waiting for valid A1                              |
   | S2-SENT       | Waiting for valid A2                              |
   +---------------+---------------------------------------------------+
































Heer                     Expires August 5, 2007                [Page 24]

Internet-Draft               Lightweght HIP                February 2007


   LHIP SIGNER IHC-based signature state machine :


      Rcv A1:
       drop A1;
      Rcv A2:
       drop A2
         .-----.
         |     |
         |     V
       .---------. (1) Send event:       .---------.    Timeout:
       |         |      buffer HIP MSG,  |         |<-.  resend S1;
       | INITIAL |      snd S1*          |  S1-    |  | Rcv A2:
    -->| /READY  |---------------------->|  SENT   |  |  drop A2
       |         |                       |         |--' Rcv valid A1,
       '---------'                       '---------'     cancel process:
                ^                            ^  |        snd new S1 (x)
    rcv valid A2|                            |  |
    ACK:        |     (2) Rcv valid A2 NACK: |  | Rcv valid A1:
      no action |          resend S1*        |  |  snd S2*,
                |                            |  |  store PACK and PNACK
                |        .---------.         |  |
                |        |         |---------'  |
                |        |  S2-    |            |
                '--------|  SENT   |            |
                         |         |<-----------'
                         '---------'
                           |     ^
                           |     |
                           '-----'
                       Timeout:
                        resend S2;
                       Rcv A1:
                        drop A1

                                 Figure 4

   State transitions that require the use a new hash chain element from
   the SIGNER's SIGNATURE_CHAIN are marked with an asterisk.  The send
   event (marked with (1)) is triggered when HIP hands an outgoing HIP
   control packet (e.g. an UPDATE packet) to LHIP at the SIGNER.  This
   packet is queued and delayed until it is sent as S2 packet.  The
   retransmission of the S1 packet after a NACK (2) requires that the
   SIGNER calculates a new pre-signature with an undisclosed hash chain
   element from its SIGNATURE_CHAIN.

   The SIGNER MUST queue all outgoing messages from the HIP base
   protocol when these messages arrive while the queue is non-empty or



Heer                     Expires August 5, 2007                [Page 25]

Internet-Draft               Lightweght HIP                February 2007


   when the SIGNER's state machine is not in state READY.  The SIGNER
   can handle one message in the queue at a time.  The SIGNER removes a
   message from the queue after receiving a valid A2 packet that
   contains a valid HACK parameter.

   The SIGNER MAY repeat the signature process if the VERIFIER sends a
   HNACK parameter in the A2 packet.  However, it SHOULD limit the
   number of retries to avoid the depletion of its hash chain.
   Consecutive signature failures indicate an attack because packets
   with transmission errors are already detected by the checksums in the
   IP header with high probability.  Multi-homed hosts can try to use
   alternative communication paths to circumvent an attacker.

   The SIGNER uses timeouts to determine when a packet was lost on the
   way to or from the VERIFIER.  It resends the previously sent packet
   without using a new hash chain element in such a case.  The SIGNER
   SHOULD abort the signature process if consecutive retransmissions
   fail due to timeouts.  It deletes the queued message belonging to the
   IHC-based signature process from the queue and sends a new S1 packet
   for the next message in the queue.  In this case, the SIGNER MUST
   repeat the signature process for the packet without considering this
   failed signature as an attack if the VERIFIER sends an HNACK in the
   A2 packet.

   The LHIP IHC-signature protocol allows the SIGNER to gracefully abort
   a signature process after receiving an A1 packet by sending a new S1
   packet, thus, initiating a new signature process for the next queued
   HIP control message.  This mechanism delivers important packets with
   higher priority.  The corresponding conditions and state transitions
   are marked with an (x) in both state machine diagrams.

4.6.3.  VERIFIER State Machine

   The VERIFIER state machine starts in the ready state, in which it
   waits for the first S1 packet to arrive from the SIGNER.  The SIGNER
   sends the A1 packet and transitions to state A1-SENT.  After
   completing an IHC-based signature process by sending an
   acknowledgment or negative acknowledgment, the VERIFIER state machine
   transitions to state A2-SENT in which it waits until a new IHC-based
   signature process is initiated by a valid S1 packet.  The VERIFIER's
   state machine is depicted in Figure 5.

   +---------------+---------------------------------------------------+
   | State         | Explanation                                       |
   +---------------+---------------------------------------------------+
   | INITIAL/READY | State machine start, waiting for valid S1         |
   | A1-SENT       | Waiting for valid S2                              |




Heer                     Expires August 5, 2007                [Page 26]

Internet-Draft               Lightweght HIP                February 2007


   | A2-SENT       | IHC-signature process completed, Waiting for      |
   |               | valid S1                                          |
   +---------------+---------------------------------------------------+

   LHIP VERIFIER IHC-based signature state machine :


        Rcv S2:
          drop S2
         .-----.
         |     V                              Rcv old S1:
       .---------. Rcv valid S1: .---------.     resend A1;
       |         |  snd A1*,     |         |<-. Rcv valid S1:
       | INITIAL |  store S1     |  A1-    |  |  snd new A1*; (x)
    -->|  READY  |-------------->|  SENT   |  | Rcv S2: drop S2
       |         |               |         |--'
       '---------'               '---------
                                   ^  |
                                   |  | (1)
                   Rcv valid S1:   |  | Rcv valid S2, signature valid:
                    snd A1*,       |  |  snd A2 with HACK*, deliver MSG;
                    store S1       |  | Rcv valid S2, signature invalid:
                                   |  |  snd A2 with HNACK*
                                   |  |
                                   |  V
                               .---------.
              Rcv old S2:   .->|         |
               resend A2;   |  |  A2-    |
              Rcv valid S2: |  |  SENT   |
               drop S2;     '--|         |
                               '---------'

                                 Figure 5

   The transitions marked with an asterisk require the VERIFIER to use a
   new hash chain element from its TRIGGER_CHAIN.  The VERIFIER sends
   the secret_ack encoded as HACK parameter in the A2 packet when the
   signature of the MESSAGE is valid (1).  The LHIP authentication
   process delivers the packet to the HIP only when the signature is
   valid.  Otherwise, it MUST drop the message and send the secret_nack
   encoded as HNACK parameter to the SIGNER.

4.6.4.  State Loss

   Recovery from state loss during the authentication process is not
   supported as the LHIP association, including all necessary hash
   chains, would be lost as well.  Recovery from state loss for the
   whole LHIP association is handled in Section 4.15.



Heer                     Expires August 5, 2007                [Page 27]

Internet-Draft               Lightweght HIP                February 2007


4.7.  Predefined Signals

   Messages containing only one bit to be protected (e.g. the signaling
   for triggering a predefined action), can be invoked by using one-way
   signatures.  LHIP uses binary hash chains which consist only of two
   elements -- a pseudo-random number r and the hash of r, h_1 = H(r) --
   for this purpose.  The h_1 is exchanged beforehand as anchor value.
   It is bound to a specific action.  A local host can trigger this
   action by disclosing r.  Its peer can verify if the host has
   requested the specific action by verifying that H(r) equals h_1.
   This procedure provides a way to trigger actions such as the closing
   of a HIP association in a secure way.  It only requires to attach the
   secret value r to the message which carries the unprotected signaling
   for the predefined signal.  The transmission of r substitutes the
   IHC-based signature that would otherwise have been necessary to
   secure the signaling of the action.  Therefore, using predefined
   signals instead of IHC-based signatures saves 1.5 RTTs.  Anchors for
   predefined signals must be exchanged and assigned to the signal in
   the beginning of the communication process during the BEX.

4.8.  Unprotected HIP Control Packets

   For some control packets, it is not necessary to apply signatures as
   these either do not carry data worth protecting or are protected by
   other mechanisms.  Apart from the following exceptions, all HIP
   control packets MUST be protected with IHC-based signatures.  Other
   HIP extensions may define further exceptions.

   List of MESSAGES which are not protected by IHC-based signatures:

   1.  UPDATE packets which only carry ACK and ECHO_RESPONSE because
       manipulations can be detected without signatures (cf.
       Section 4.3.6).

   2.  CLOSE packets because they are protected by predefined signals
       (cf. Section 4.13).

   3.  UPDATE packets which are used for an LHIP to HIP upgrade because
       they are protected by a predefined signal and an HMAC which uses
       a shared key (cf. Section 4.14).

4.9.  LHIP Handshake

   HIP uses the BEX to create the HIP communication context, the HIP
   association, on both hosts.  LHIP extends the BEX in order to
   establish the LHIP communication context.  LHIP hosts generate hash
   chains and exchange hash chain anchors with the peer during the base
   exchange.  Unlike the HIP base exchange, no PK operations are



Heer                     Expires August 5, 2007                [Page 28]

Internet-Draft               Lightweght HIP                February 2007


   performed during the LHIP base exchange in the general case.
   Therefore, all HIP specific packets and parameters except the RSA and
   HMAC signatures in the I2 and R2 packet are present in the LHIP base
   exchange.  LHIP preserves the semantics and the functionality of HIP
   parameters that excluded from this document.  However, LHIP extends
   the functionality of the TRANSFORM parameter and uses the new LFLAGS
   parameters during the BEX.

4.9.1.  LHIP Transform Suites

   LHIP negotiates the type of association (LHIP or HIP) during the BEX
   to allow interoperability of hybrid hosts and LHIP-unaware HIP hosts.
   It uses the HIP_TRANSFORM parameter to determine whether LHIP or HIP
   must be used.

   LHIP defines one additional transform suite and suite-ID in addition
   to the transform suites defined in [I-D.ietf-hip-base]:

                        +-----------------+-------+
                        | Suite-ID        | Value |
                        +-----------------+-------+
                        | LHIP with SHA-1 | 7     |
                        +-----------------+-------+

   LHIP uses SHA-1 hash chains and SHA-1 HMACs when transform suite 7 is
   selected.  Other transform suites have not been defined for LHIP yet
   but may be defined in the future.

   The RESPONDER indicates that it supports LHIP by including an LHIP
   transform suite in the HIP_TRANSFORM parameter, carried by the R1
   packet .  The ordering of the transform suites indicates the
   RESPONDER's preferences.

   The INITIATOR selects two transform suites from the given set
   transform suites in the HIP_TRANSFORM parameter in the R1 and sends
   them back to the RESPONDER.  LHIP MUST used when the INITIATOR
   selects an LHIP transform suite as preferred (first) entry.  The
   INITIATOR also selects a second HIP transform suite other than an
   LHIP transform suite in order to specify the HIP transform suite that
   will be used after the upgrade from LHIP to HIP.  The INITIATOR sends
   back both selections in a HIP transform parameter in the I2 packet.
   The RESPONDER buffers the second HIP transform suite for later use
   during the upgrade process.

4.9.2.  Hash Chain Anchors

   The hosts must exchange their sets of hash chain anchors during the
   base exchange in order to sign HIP control messages with the IHC-



Heer                     Expires August 5, 2007                [Page 29]

Internet-Draft               Lightweght HIP                February 2007


   based approach and to use predefined signals later.  These anchors
   are added to the I2 packets and the R2 packets.  This enables the
   RESPONDER to stay stateless until it receives the I2 packet without
   the need to buffer the INITIATOR's hash chain anchors.  Moreover, the
   RESPONDER can use the echo-request/response mechanism to verify the
   routability of the INITIATOR's locator before creating the hash
   chains.  LHIP exchanges the the anchors of the SIGNATURE_CHAIN,
   TRIGGER_CHAIN, CLOSE_CHAIN, and the UPGRADE_CHAIN during the BEX.
   The corresponding HCA parameters MUST be present in the I2 and R2
   packet.

4.9.3.  Diffie-Hellman Parameters

   LHIP does not use the Diffie-Hellman key exchange during the BEX in
   order to reduce the computational complexity of the HIP base
   exchange.  Nevertheless, it is necessary to exchange the DH
   parameters in order to allow an upgrade from LHIP to HIP at a later
   point in time.  Therefore, both hosts exchange their DH parameters as
   specified in the HIP base protocol.  Each host buffers the DH
   parameters of its peer until these are used during the LHIP upgrade
   process.

4.9.4.  ECHO_REQUEST parameter

   LHIP hosts MUST include an ECHO REQUEST in the R1 packet if they act
   as RESPONDER and in the I2 packet if they act as INITIATOR.  The
   hosts must ensure that the ECHO_REQUESTS are unique for every
   association.  This uniqueness serves as replay protection for
   authenticated LHIP associations.  LHIP hosts MUST reply with an
   ECHO_REQUEST_SIGNED parameter to ECHO_RESPONSE parameters.

4.9.5.  RSA and DSA Signatures

   RSA and DSA signatures are not obligatory for the I2 and R2 packet
   during the LHIP base exchange.  Only the R1 packet is REQUIRED to be
   signed for compatibility reasons.  However, some scenarios make the
   selective use of these PK-signatures in the I2 and R2 packet
   necessary.  LHIP does not provide host authentication but, in case of
   a name collisions (two different hosts use the same HI to contact a
   RESPONDER), it is necessary to verify the identity of a host.
   Especially when LHIP and HIP are used in combination, protection of
   the HIP namespace is vital.  We distinguish two different kinds of
   attacks on unprotected HIs:

   HI blocking attack:  An attacker uses the HI of a victim host to
      establish a connection to a RESPONDER in order to create an
      incorrect binding between HI and an IP on the RESPONDER before or
      after the victim contacts the RESPONDER.  This leads to a



Heer                     Expires August 5, 2007                [Page 30]

Internet-Draft               Lightweght HIP                February 2007


      situation in which the RESPONDER can not differentiate the
      attacker from the victim if none of them authenticates by using
      its private key.

   HI stealing attack:  An attacker uses an HI of a potential RESPONDER
      of the victim to establish an LHIP association with the victim
      before the victim contacts the RESPONDER.  If the victim tries to
      send data to the RESPONDER later, it will use the already
      established LHIP association with the attacker and consequently
      send all traffic to the attacker.

   Using RSA or DSA to verify the HIs of the hosts during the BEX solves
   both problems but increases the computational complexity of LHIP.
   Therefore, LHIP only uses RSA or DSA signatures in case of name
   collisions and potential HI stealing attacks.  A RESPONDER MUST
   request PK-authentication from an INITIATOR if it has already
   maintains an open LHIP association with the HI of the INITIATOR.
   This authentication serves as protection against the HI blocking
   attack.  Hosts which typically act as servers SHOULD authenticate all
   outgoing LHIP associations.  Hosts, which typically act as client,
   SHOULD authenticate all incoming LHIP associations.  A host MUST
   either authenticate all incoming or outgoing associations.  This
   authentication scheme makes the HI stealing attack impossible.

4.9.6.  Authenticated Hash Chain Anchors

   Using RSA and DSA signatures to verify the HI of a peer also ties the
   hash chain anchors to the HI because they are contained in the signed
   part of the I2 and R2 packet.  In this case, the LHIP association and
   all following updates and modifications can be related to the
   identity of a host.

   Hosts can define their own policies when to verify the identity of a
   peer and when they are willing to authenticate to the peer.  For
   instance, servers that only offer insensitive content can deny to
   authenticate to clients in order to save CPU-resources.  These
   requirements and this willingness is expressed in the LFLAGS
   parameter.  This parameter is attached to the R1 packet and to the I2
   packet.  It provides three flags: LFLAG_AUTH_REQUIRED,
   LFLAG_OFFER_AUTH, and LFLAG_OFFER_UPGRADE.

   Setting LFLAG_AUTH_REQUIRED flag signals that the peer MUST
   authenticate in order to continue the BEX.  A host, which receives an
   LFLAGS parameter with the LFLAG_AUTH_REQUIRED flag, MUST either sign
   its next BEX packet (I2 or R2 depending on whether the host acts as
   INITIATOR or RESPONDER) with its private key or abort the BEX.

   The LFLAG_OFFER_AUTH flag signals that a host is willing to



Heer                     Expires August 5, 2007                [Page 31]

Internet-Draft               Lightweght HIP                February 2007


   authenticate when its peer requires authentication.  Denying
   authentication is useful for servers which are vulnerable to DoS
   attacks and do not provide sensible data or services.

   The LFLAG_OFFER_UPGRADE indicates that a host will accept requests to
   upgrade from LHIP to HIP.  Setting this flag indicates implicitly the
   willingness to use PK-signatures during the upgrade process.

   Authenticated LHIP BEX packets MUST contain the ECHO_RESPONSE
   parameter in the signed part of the packet.  LHIP hosts MUST ensure
   that an ECHO_RESPONSE parameter is only used once to avoid replay
   attacks.  Consecutive authenticated I2 and R2 packets with the same
   ECHO_RESPONSE parameter contents MUST be discarded

4.9.7.  Encrypted Host Identifiers

   LHIP does not support encrypted HIs in the I2 packet as no symmetric
   key is available to encrypt these.

4.9.8.  Puzzle Mechanism

   LHIP does not change the semantics or the functionality of the HIP
   puzzle mechanism.  LHIP RESPONDERS can use puzzles to generate CPU-
   load on the INITIATOR.  However, it is RECOMMENDED to use low puzzle
   difficulties (e.g. 0) in order to keep the computational cost of LHIP
   low.

4.9.9.  Basic LHIP Base Exchange Overview

   The LHIP BEX is depicted below.  The anchors comprise all LHIP
   anchors.  The anchors of the INITIATOR are marked with an index i and
   the anchors of the RESPONDER with an index r, accordingly.



















Heer                     Expires August 5, 2007                [Page 32]

Internet-Draft               Lightweght HIP                February 2007


   The basic LHIP BEX:



    INITIATOR                                            RESPONDER

                                                 Pre-calculate R1

                    I1: I1 contents
                   -------------------------->
                                                 Add LFLAGS to pre-
                                                 calculated R1:
                                                 set LFLAG_AUTH_REQUIRED
                                                 in case of collisions

                    R1: R1 contents, LFLAGS
                   <----------------------------
   [Verify signature]
   select LHIP transform suite,
   select HIP transform suite,
   [add signature to I2]

                    I2: I2 contents, anchors_i, [SIG], LFLAGS
                   ---------------------------->
                                                 [Verify signature],
                                                 store anchors,
                                                 [add signature to R2]

                    R2: R2 contents, anchors_r, [SIG]
                   <----------------------------
   [Verify signature],
   store anchors.

   The contents of the HIP BEX packets are summarized as I1, R1, I2, and
   R2 contents.  In contrast to the basic HIP BEX, the I2 and R2
   contents do not necessarily contain RSA, DSA, or HMAC signatures.

                                 Figure 6

4.9.10.  Use of IPsec and Other Payload Transfer Protocols

   When using IPsec [RFC2401] to transfer payload, the LHIP
   communication peers must use the IPsec ESP BEET mode
   [I-D.nikander-esp-beet-mode] with NULL encryption and with a key of
   zeroes for authentication.  The authentication algorithm must be set
   according to the selected LHIP transform suite ID (cf.
   Section 4.9.1).  Note that using IPsec in this way neither ensures
   integrity nor confidentiality for LHIP payload.  Currently, the only



Heer                     Expires August 5, 2007                [Page 33]

Internet-Draft               Lightweght HIP                February 2007


   supported transfer protocol for LHIP is IPsec.  Specifying the use of
   other ways for transferring payload, such as using plain IP or UDP
   tunneling is future work.

4.9.11.  Concluding the LHIP Base Exchange

   In the end of the LHIP base exchange, both hosts have agreed to use
   LHIP.  Both hosts have also exchanged their hash chain anchors.  The
   hosts have an unencrypted ESP BEET tunnel between them.  HIP control
   messages are protected by IHC-based signatures.

4.10.  Chained Bootstrapping

   The LHIP base exchange is vulnerable to active attackers which are
   able to eavesdrop the R1 packets and can send forged I2 packets with
   spoofed locator information.  One way to circumvent this attack is to
   use a mechanism similar to chained bootstrapping as proposed in the
   WIMP protocol[I-D.ylitalo-multi6-wimp].  Chained bootstrapping is
   OPTIONAL for LHIP because it raises the computational cost for the
   RESPONDER slightly.  LHIP compliant hosts MAY implement and support
   chained bootstrapping but are not obliged to do so.

4.10.1.  Chained Bootstrapping for the INITIATOR

   When using chained bootstrapping, the INITIATOR must compute its hash
   chains before sending the I1 packet.  It includes the pre-signature
   of the I2 packet (including the anchors) in the I1 packet.  This pre-
   signature is created with a pseudo-random value r_1 as key.  All
   fields of the I2 packet which depend on the R1 packet of the
   RESPONDER (the R1_COUNTER, the puzzle SOLUTION, the HIP_TRANSFORM,
   the [encrypted] HOST_ID and the ECHO_RESPONSE) are excluded from the
   signature.  These parameters are not zeroed in the signature but
   completely left out.  It is important to include the anchors of the
   hash chains in the pre-signature of the I1 packet to avoid that these
   are forged by a third party when transmitted in cleartext in the I2
   packet.

   The RESPONDER can stay stateless when it includes the pre-signature
   from the INITIATOR in the ECHO_REQUEST parameter of the R1 packet.
   It MUST encrypt the pre-signature or apply other integrity protection
   measures to the ECHO_REQUEST in order to avoid security compromise.

4.10.2.  Chained Bootstrapping for the RESPONDER

   Chained bootstrapping is also applicable to the R1 and the R2 packet.
   The RESPONDER must generate its hash chains before sending the R1
   packet.  It generates an HMAC signature from the concatenation of the
   R1 packet and the anchors of the hash chains and encodes it as PS



Heer                     Expires August 5, 2007                [Page 34]

Internet-Draft               Lightweght HIP                February 2007


   parameter.  It uses a pseudo-random value r_2 as key for the HMAC.
   It attaches the PS parameter to the R1 packet.  The RESPONDER must
   store the anchors and the r2_value until the I2 message arrives.
   Alternatively, it can use the ECHO_REQUEST parameter to send r_2 and
   the seeds of the hash chains to the INITIATOR in an encrypted
   envelope, keeping the key to the envelope disclosed.  The INITIATOR
   must send back the encrypted envelope from which the RESPONDER can
   decrypt the seeds and the r_2 value.  It can generate the very same
   hash chains and hash chain anchors from the seeds.  The details of
   managing the anchors and the state like the choice of the encryption
   algorithm are implementation details which only concern the
   RESPONDER.  Therefore, these details are not specified in this
   document.

   The INITIATOR can check the integrity of the R1 packet and the hash
   chain anchors in the R2 packet after it has received the R2 packet
   which contains the r_2 value.  This means that the INITIATOR MUST
   react to the unverified R1 packet in order to continue the BEX.
   However, it MAY verify the RSA or DSA signature in the R1 packet.
   Chaining the R1 and R2 packet ensures that both messages have been
   sent by the same host and that neither the anchor values nor the
   contents of the R1 packet have been modified.  However, it is
   possible that an MitM attacker modifies both messages and forges R1
   and R2 packets with different contents and anchor values.

   It is important to include the anchors in the pre-signature in the R1
   packet to avoid that these are manipulated while the R2 packet is in
   transit.  This ensures that the anchors are related to the R1 packet.
   Therefore, this avoids attacks after the INITIATOR has received the
   R1 packet.





















Heer                     Expires August 5, 2007                [Page 35]

Internet-Draft               Lightweght HIP                February 2007


   The chained LHIP BEX with chaining on the INITIATOR's and RESPONDER's
   side:


    INITIATOR                                     RESPONDER

   Generate anchors,
   PS=HMAC-F(I2, r_1),


                  I1: I1 contents, PS_1
                 -------------------------->

                                        Generate anchors from seeds
                                        PS_2=HMAC(R1|anchors_r, r_2),
                                        ECHO=ENC(secret, PS_1|r_2|seeds)

                  R1: R1 contents, ECHO, PS_2
                 <--------------------------
   Buffer PS_2

                  I2: I2 contents, anchors_i, r_1
                 -------------------------->

                                        PS_1=?HMAC(I2|anchors_i, r_1),
                                        seeds, r_2=DEC(secret, ECHO),
                                        Generate anchors from seeds

                 R2: R2 contents, anchors_r, r_2
                <--------------------------

   PS_2=?HMAC(R1|anchors, r_2)


   The contents of the HIP BEX packets are summarized in the I1, R1, I2,
   and R2 content.  Only parameters which are related to chained
   bootstrapping are depicted.  Further LHIP specific parameters are
   depicted in Figure 6.

                                 Figure 7

   It is not necessary to explicitly announce that a host uses chained
   bootstrapping as its peer can validate this from the presence of the
   PS parameter in the I1 or R1 packet.







Heer                     Expires August 5, 2007                [Page 36]

Internet-Draft               Lightweght HIP                February 2007


4.11.  Hash Chain Extension

   Hash chains are finite.  Therefore, it is necessary to replace
   depleted hash chains with new ones to allow an infinite number of
   signature processes.  In order to accomplish this, a host must send
   new anchors to the peer.  The host MUST sign the packets that contain
   anchors with IHC-based signatures.  Therefore, the host can either
   submit the anchors in a dedicated UPDATE packet or piggy-backed on
   other signed HIP control packets.  For example, UPDATE packets can be
   used for piggy-backing.  An LHIP host MUST check the contents of each
   IHC-signed message and buffer new anchors when present.

   A host MAY use the new replacement hash chains as soon as the
   acknowledgment for the IHC-signed message, carrying the new anchors,
   is received.  It MAY also continue to use the old hash chains.
   However, it MUST activate the new hash chains before the old hash
   chains deplete.  LHIP uses an implicit mechanism for activating the
   new hash chains after they have been delivered to the peer.  A host
   activates the new hash chain by using an element of the new hash
   chain in the HCE parameter of S1 packet or in the A1 packet.  The
   receiver of an S1 or A1 packet verifies whether the contained HCE
   belongs to the old or the new hash chain.  A host MUST remove the old
   hash chain and MUST start to use the new hash chain after the it has
   sent the first HCE parameter containing an element of the new hash.
   A host, which receives a message with an HCE belonging to a new
   anchor, MUST NOT accept HCE parameters which belong to old anchors or
   hash chain elements.

4.12.  LHIP Interaction with Middle-boxes

   HIP UPDATE messages are not only processed by the communicating peers
   but also by middle-boxes on the communication path.  These middle-
   boxes learn about new locators and SPI values by inspecting the
   UPDATE messages.  The IHC-based signatures can be authenticated by
   middle-boxes.  Therefore, in contrast to HIP, UPDATE packets do not
   need to contain RSA or DSA signatures.

   Like LHIP VERIFIERS, Middle-boxes must buffer the PS parameter in the
   S1 packet of the IHC signature until the S2 packet with the
   corresponding hash chain element and the message arrives.  In order
   to allow IHC-based signatures, the middle-box must let S1 and A1
   packets pass through without verification and without restriction of
   the source IP addresses contained in them.  However, the middle box
   SHOULD rate-limit the number of S1 and A1 packets that are sent to
   the same IP address to avoid DoS attacks on hosts behind a middle-
   box.  It SHOULD also verify that the HCE parameter in these packets
   are either valid or old.  Packets containing invalid HCEs SHOULD NOT
   be forwarded.  It SHOULD also check that these packets contain no



Heer                     Expires August 5, 2007                [Page 37]

Internet-Draft               Lightweght HIP                February 2007


   payload besides the HSE, the PS, the PACK, and the PNACK parameters
   and SHOULD drop packets which contain further parameters to prevent
   attacks with large parameter contents.

4.13.  Closing an LHIP Association

   Like HIP associations, LHIP associations are torn down when they are
   not used any more.  It is necessary to protect this closing process
   to avoid attacks.  However, it is not necessary for LHIP to protect
   the CLOSE messages with IHC-based signatures as they only carry one
   vital bit of information which requires protection: whether to close
   the association.  Therefore, it it sufficient to use a predefined
   signal to securely announce the closing of an LHIP association.  Both
   hosts send HIP CLOSE or CLOSE_ACK messages without RSA, DSA and HMAC
   signatures and attach a HCE parameter containing the second element
   of the CLOSE_CHAIN.  The peer MUST verify the CLOSE and CLOSE_ACK
   message by comparing the hashed contents of the HCE parameter with
   the anchor of the peer's CLOSE_CHAIN which was exchanged during the
   LHIP BEX.  The hosts proceed with the standard HIP closing procedure
   if the HCE parameter is valid.  CLOSE messages with old or invalid
   HCE parameters MUST be discarded without further processing.

4.14.  Upgrading an LHIP Association

   A host can initiate an upgrade from an LHIP to a HIP association when
   the security properties of a full HIP association are required.  This
   is the case when a process establishes an LHIP association and the
   same or another process requests a HIP association with the same HIs
   as endpoints later.  LHIP associations are upgradable when both hosts
   have indicated that they support upgrades in the LFLAGS parameter.
   The upgrade process is a two-way message exchange.  LHIP uses HIP
   UPDATE messages to carry the upgrade information.  In order to
   achieve security properties of full HIP, LHIP uses RSA or DSA
   signatures and the DH key exchange during the upgrade.  The term
   INITIATOR is used for the initiator of an upgrade and the term
   RESPONDER for the host which reacts to the upgrade request.

4.14.1.  The First Upgrade Packet

   Before initiating an upgrade, the INITIATOR calculates the DH shared
   secret from the DH keys exchanged during the BEX.  It generates the
   symmetric keys and the keys for the HMAC creation from this shared
   secret.  The key creation process follows the rules defined for the
   key creation during the HIP BEX.  The INITIATOR sets up new IPsec SPs
   which use the algorithms selected in the second HIP transform.  It
   also sets up a new outgoing IPsec security association with the
   symmetric keys.




Heer                     Expires August 5, 2007                [Page 38]

Internet-Draft               Lightweght HIP                February 2007


   The INITIATOR sends the first message U1 of the upgrade process.  It
   is an UPDATE message which contains the SPI value of the new IPsec SA
   encoded as ESP_INFO parameter (cf. [I-D.ietf-hip-esp]), HI, and an
   HMAC to protect the SPI values.  The freshly created symmetric keys
   are used as key for the HMAC computation.  The INITIATOR also adds an
   RSA or DSA signature, generated with the private key if it has not
   authenticated during the BEX.  In this case, it MUST include the
   ECHO_RESPONSE parameter in the U1 packet as replay protection.  A
   host which supports LHIP upgrades MUST ensure that the ECHO_REQUEST
   in the R1 packet is unique for every LHIP association and that the
   ECHO_RESPONSE in the first upgrade packet has not been used in order
   to upgrade an LHIP association between the same HIs before.

   The UPGRADE message triggers the DH shared key computation at the
   RESPONDER.  This operation is CPU-intensive and can be used in an
   attack to provoke the DH calculations with a forged message.
   Therefore, the upgrade process must be protected with signatures.  As
   for the CLOSE packets, using predefined signals is sufficient as all
   other vital information in the packet is protected by the HMAC.
   Therefore, both hosts include an HCE parameter containing the next
   element of the UPGRADE_CHAIN in their upgrade message.  The structure
   of the U1 packet is depicted below.

                  IP ( HIP-UPDATE (
                                    ESP_INFO,
                                    ECHO_RESPONSE_SIGNED,
                                    HMAC,
                                    HIP_SIGNATURE,
                                    HCE))

   The host responding to U1 packet verifies that the HCE parameter
   belongs to the peer's UPGRADE_CHAIN and that it is valid.  This
   comparison is inexpensive and proves that the legitimate peer
   initiated the upgrade process.  The host calculates the DH shared
   secret if the hash chain verification is successful.  The RESPONDER
   generates the symmetric keys and the key for the HMAC signatures from
   the shared secrets.  The RESPONDER can verify the HMAC signature in
   the UPGRADE message by using the freshly calculated keys.  The
   RESPONDER modifies the IPsec SPs in order to use the encryption
   algorithms selected in the second HIP transform.  It then sets up the
   outgoing and incoming IPsec SAs corresponding to the remote peer's
   SPI and the symmetric keys.

   It is necessary to include the HIs of the peers in the UPGRADE
   messages to support HIP-aware middle-boxes.  The HIs in the packets
   enable these middle-boxes to learn the public keys of the hosts, in
   case the middle-box has not observed the BEX.  This is the case when
   either of the hosts has moved behind a new middle-box during the LHIP



Heer                     Expires August 5, 2007                [Page 39]

Internet-Draft               Lightweght HIP                February 2007


   association.

4.14.2.  The Second Upgrade Packet

   The RESPONDER sends back an HMAC-protected UPDATE message which
   contains its SPI value for the incoming IPsec SA encoded as ESP_INFO
   parameter, the next element of its UPGRADE_CHAIN encoded as HCE
   parameter, and its HI.  The RESPONDER MUST prove its identity by
   using its RSA or DSA private key, if it has not already done so
   during the LHIP BEX.  It MUST also include the ECHO_RESPONSE from the
   LHIP BEX to avoid replay attacks.  The INITIATOR can use the HMAC to
   verify the UPDATE message.  It sets up its outgoing SA with the SPI
   given by the remote peer.  At this point, both peers have upgraded to
   HIP and established an encrypted BEET tunnel.  They do not use the
   LHIP authentication functions any more.  The structure of the U2
   packet is identical to the structure f the U1 packet.

4.14.3.  Concurrent Upgrade Initialization

   The first and the second upgrade packet are symmetrical.  This avoids
   problems with concurrent upgrades.  A host which has sent the first
   upgrade packet can use a simultaneously sent first upgrade packet as
   second upgrade packet and complete the upgrade process successfully.

4.14.4.  HIP Downgrade

   A downgrade from HIP to LHIP is not desirable because both hosts are
   already in possession of the shared secret which enables efficient
   message authentication and symmetric encryption.

4.14.5.  Upgrade DoS Attack

   The upgrade process can be used as a tool to DoS attack a victim host
   that uses LHIP.  An attacker can open numerous LHIP associations to
   the victim with low computational cost and upgrade all of these
   connections at the same time.  This would require the victim to
   compute numerous Diffie-Hellman key exchanges which results in high
   CPU utilization.  Currently, there is no defense to this attack as
   the puzzle mechanism is not applicable to the two-way upgrade
   process.  Therefore, hosts SHOULD limit the number of upgrades in a
   certain time interval.  Alternatively, hosts can refuse to upgrade
   associations by not setting the LFLAG_OFFER_UPGRADE flag in the LFLAG
   parameter.

4.14.6.  Sequence Numbers

   HIP uses sequence numbers to protect HIP UPDATE packets.  LHIP allows
   HIP extensions to send unprotected UPDATE packets when the contents



Heer                     Expires August 5, 2007                [Page 40]

Internet-Draft               Lightweght HIP                February 2007


   of the UPDATE packet does not require authentication.  Therefore,
   attackers can modify the sequence numbers in these unprotected
   packets.  The IHC-based signature scheme of LHIP ensures the correct
   sequence of protected HIP UPDATE packets.  Therefore, LHIP hosts MUST
   ignore the sequence numbers of HIP control packets.  As sequence
   numbers are vital for HIP to operate correctly, LHIP associations
   which have been upgraded to HIP associations must obey the sequence
   numbers.  The sequence number counter of an upgraded LHIP association
   must be set to the sequence number contained in the U1 or U2 packet,
   respectively.

4.15.  State Loss

   A host can lose all information about an established LHIP association
   due to events like hardware errors, software errors, or an operating
   system reboot.  In this case, the peers of the host still use the
   context information of the broken LHIP association.  Recovery from
   state loss requires host authentication to avoid replay attacks.

   A host that has lost its state reinitiates an LHIP association by
   sending an I1 packet.  As the RESPONDER has already associated state
   with the other host's HI, the RESPONDER MUST require the INITIATOR to
   authenticate by using its private key.  The RESPONDER deletes the
   existing state if the authentication is successful.  It MUST silently
   drop the I2 packet otherwise.


5.  Security Considerations

   LHIP aims at providing HIP mobility and multihoming support for
   devices with few CPU resources.  As discussed in Section 2, LHIP
   provides no support for end-host authentication nor does it encrypt
   payload from upper protocol layers.  Therefore, it SHOULD only be
   used when these properties are either provided by higher-layer
   protocols or are not required at all.

   LHIP uses the same host identifier namespace as HIP without
   necessarily authenticating the HIs.  As discussed in Section 4.9.5
   attacks are possible if host authentication is omitted completely.
   Therefore, it is important that all LHIP hosts implement the proposed
   defense mechanisms against the HI stealing and HI blocking attack in
   order to protect LHIP and, importantly, HIP hosts.

   The question how to avoid DoS attacks caused by parallel LHIP
   upgrades, as discussed in Section 4.14.5, is not solved completely.
   Hosts which are prospective targets for such attacks SHOULD limit the
   number of concurrent upgrades or categorically deny LHIP upgrades.
   The option of tearing down an LHIP association and re-establishing a



Heer                     Expires August 5, 2007                [Page 41]

Internet-Draft               Lightweght HIP                February 2007


   new HIP association remains as alternative way to switch from LHIP to
   HIP.  In that case, all security features of HIP, including the
   puzzle mechanism, can be used to protect the RESPONDER.

   In opposition to HIP, LHIP does not provide protection against MitM
   attacks during the BEX if the hosts do not use authenticated hash
   chains.  Unauthenticated LHIP is vulnerable to MiTM attacks.
   Impersonation attacks can only be detected and resulting conflicts
   can only be resolved if two hosts use the same HI to establish an
   association with a RESPONDER.  It is out of scope for LHIP to protect
   against these attacks as LHIP does not enforce host authentication.

   Note that LHIP does not replace HIP in any way.  LHIP is an extension
   to HIP and requires a full HIP implementation including all security
   and protocol features provided by the basic HIP protocol.


6.  IANA Considerations

   This document defines three new HIP packet types in Section 4.5 the
   type numbers (22, 23, 24) for these packet types are preliminary and
   need to be assigned through IETF consensus.

   LHIP also defines several new parameter types in Section 4.4.  The
   preliminary parameter type numbers are 222, 64702, 64704, 64725,
   64727, 64729, 64731, and 63404.

   LHIP defines a new HIP transform suite ID (7).  This suite ID is
   preliminary and needs to be assigned in consensus with the IETF.

   LHIP creates a new namespace for hash chains type identifiers.  New
   identifiers for further hash chain types which are either used in the
   IHC-based signature process or for predefined signals are assigned
   through IETF consensus.

   Other HIP extensions may use the LFLAGS parameter to transmit LHIP
   related flags as well.  The position for these flags in the bit-mask
   are assigned through IETF consensus.


7.  Acknowledgments

   Miika Komu, Stefan Goetz, Jukka Ylitalo, Pekka Nikander, Sasu
   Tarkoma, Janne Lindqvist, Olaf Landsiedel, and Klaus Wehrle have
   contributed valuable ideas and important feedback concerning LHIP and
   the IHC-based signature process.





Heer                     Expires August 5, 2007                [Page 42]

Internet-Draft               Lightweght HIP                February 2007


8.  References

8.1.  Normative References

   [I-D.ietf-hip-base]
              Moskowitz, R., "Host Identity Protocol",
              draft-ietf-hip-base-07 (work in progress), February 2007.

   [I-D.ietf-hip-esp]
              Jokela, P., "Using ESP transport format with HIP",
              draft-ietf-hip-esp-05 (work in progress), February 2007.

   [I-D.ietf-hip-mm]
              Nikander, P., "End-Host Mobility and Multihoming with the
              Host Identity Protocol", draft-ietf-hip-mm-04 (work in
              progress), June 2006.

   [I-D.komu-btns-api]
              Komu, M., "IPsec Application Programming Interfaces",
              draft-komu-btns-api-00 (work in progress), October 2006.

   [I-D.mkomu-hip-native-api]
              Komu, M., "Native Application Programming Interfaces for
              the Host Identity Protocol", draft-mkomu-hip-native-api-00
              (work in progress), March 2005.

   [I-D.nikander-esp-beet-mode]
              Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", draft-nikander-esp-beet-mode-06
              (work in progress), August 2006.

   [I-D.ylitalo-multi6-wimp]
              Ylitalo, J., "Weak Identifier Multihoming Protocol
              (WIMP)", draft-ylitalo-multi6-wimp-01 (work in progress),
              July 2004.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
              (DNS)", RFC 2536, March 1999.



Heer                     Expires August 5, 2007                [Page 43]

Internet-Draft               Lightweght HIP                February 2007


   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
              Name System (DNS)", RFC 3110, May 2001.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
              Briscoe, "Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA): Multicast Source Authentication
              Transform Introduction", RFC 4082, June 2005.

8.2.  Informative References

   [DH71]     Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information Theory vol.
              IT-22, number 6, pages 644-654, 1976.

   [Lam81]    Lamport, L., "Password authentication with insecure
              communication", Commun. of ACM 24 (11), pp. 770-772,
              1981.


Author's Address

   Tobias Heer
   RWTH Aachen University, Distributed Systems Group
   Ahornstrasse 55
   Aachen  52062
   Germany

   Phone: +49 241 80 214 32
   Email: tobias.heer@cs.rwth-aachen.de
   URI:   http://ds.cs.rwth-aachen.de/members/heer


















Heer                     Expires August 5, 2007                [Page 44]

Internet-Draft               Lightweght HIP                February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Heer                     Expires August 5, 2007                [Page 45]