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]