Internet DRAFT - draft-moskowitz-hip-dex
draft-moskowitz-hip-dex
Network Working Group R. Moskowitz, Ed.
Internet-Draft HTT Consulting
Intended status: Standards Track R. Hummen
Expires: July 21, 2016 COMSYS, RWTH Aachen
January 20, 2016
HIP Diet EXchange (DEX)
draft-moskowitz-hip-dex-05
Abstract
This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash
functions. In doing so, the main goal is to still deliver similar
security properties to HIPv2.
The HIP DEX protocol is primarily designed for computation or memory-
constrained sensor/actuator devices. Like HIPv2, it is expected to
be used together with a suitable security protocol such as the
Encapsulated Security Payload (ESP) for the protection of upper layer
protocol data. In addition, HIP DEX can also be used as a keying
mechanism for security primitives at the MAC layer, e.g., for IEEE
802.15.4 networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 21, 2016.
Moskowitz & Hummen Expires July 21, 2016 [Page 1]
Internet-Draft HIP Diet EXchange (DEX) January 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4
1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 8
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 10
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 11
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 15
4.1.4. User Data Considerations . . . . . . . . . . . . . . 16
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 16
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 17
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 18
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 18
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 20
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 21
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 23
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 24
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 25
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 25
Moskowitz & Hummen Expires July 21, 2016 [Page 2]
Internet-Draft HIP Diet EXchange (DEX) January 2016
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 25
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 26
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 26
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 27
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 30
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 30
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 31
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 34
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 37
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 38
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 39
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 39
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 41
11.2. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 41
11.3. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 42
11.4. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 42
11.5. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 42
11.6. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Password-based two-factor authentication during
the HIP DEX handshake . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction
This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity
Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol
semantics as well as the general packet structure of HIPv2. Hence,
it is recommended that [RFC7401] is well-understood before reading
this document.
The main differences between HIP BEX and HIP DEX are:
1. Minimum collection of cryptographic primitives to reduce the
protocol overhead.
* Static Elliptic Curve Diffie-Hellman key pairs for peer
authentication and encryption of the session key.
Moskowitz & Hummen Expires July 21, 2016 [Page 3]
Internet-Draft HIP Diet EXchange (DEX) January 2016
* AES-CTR for symmetric encryption and AES-CMAC for MACing
function.
* A simple fold function for HIT generation.
2. Forfeit of Perfect Forward Secrecy with the dropping of an
ephemeral Diffie-Hellman key agreement.
3. Forfeit of digital signatures with the removal of a hash
function. Reliance on ECDH derived key used in HIP_MAC to prove
ownership of the private key.
4. Diffie-Hellman derived key ONLY used to protect the HIP packets.
A separate secret exchange within the HIP packets creates the
session key(s).
5. Optional retransmission strategy tailored to handle the
potentially extensive processing time of the employed
cryptographic operations on computationally constrained devices.
By eliminating the need for public-key signatures and the ephemeral
DH key agreement, HIP DEX reduces the computation, energy,
transmission, and memory requirements for public-key cryptography
(see [LN08]) in the HIPv2 protocol design. Moreover, by dropping the
cryptographic hash function, HIP DEX affords a more efficient
protocol implementation than HIP BEX with respect to the
corresponding computation and memory requirements. This makes HIP
DEX especially suitable for constrained devices as defined in
[RFC7228].
This document focuses on the protocol specifications related to
differences between HIP BEX and HIP DEX. Where differences are not
called out explicitly, the protocol specification of HIP DEX is the
same as defined in [RFC7401].
1.1. The HIP Diet EXchange (DEX)
The HIP Diet EXchange is a two-party cryptographic protocol used to
establish a secure communication context between hosts. The first
party is called the Initiator and the second party the Responder.
The four-packet exchange helps to make HIP DEX DoS resilient. The
Initiator and the Responder exchange their static Elliptic Curve
Diffie-Hellman (ECDH) keys in the 2nd and 3rd handshake packet. The
parties then authenticate each other in the 3rd and 4th handshake
packet based on the ECDH-derived keying material. The Initiator and
the Responder additionally transmit keying material for the session
key in these last two handshake packets. This is to prevent overuse
of the static ECDH-derived keying material. Moreover, the Responder
Moskowitz & Hummen Expires July 21, 2016 [Page 4]
Internet-Draft HIP Diet EXchange (DEX) January 2016
starts a puzzle exchange in the 2nd packet and the Initiator
completes this exchange in the 3rd packet before the Responder
performs computationally expensive operations or stores any state
from the exchange. Given this handshake structure, HIP DEX
operationally is very similar to HIP BEX. Moreover, the employed
model is also fairly equivalent to 802.11-2007 [IEEE.802-11.2007]
Master Key and Pair-wise Transient Key, but handled in a single
exchange.
HIP DEX does not have the option to encrypt the Host Identity of the
Initiator in the 3rd packet. The Responder's Host Identity also is
not protected. Thus, contrary to HIPv2, there is no attempt at
anonymity.
Data packets start to flow after the 4th packet. The 3rd and 4th HIP
packets may carry data payload in the future. However, the details
of this may be defined later.
An existing HIP association can be updated with the update mechanism
defined in [RFC7401]. Likewise, the association can be torn down
with the defined closing mechanism for HIPv2 if it is no longer
needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the
original HIPv2 specification.
Finally, HIP DEX is designed as an end-to-end authentication and key
establishment protocol. As such, it can be used in combination with
Encapsulated Security Payload (ESP) [RFC7402] as well as with other
end-to-end security protocols. In addition, HIP DEX can also be used
as a keying mechanism for security primitives at the MAC layer, e.g.,
for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth
mentioning that the HIP DEX base protocol does not cover all the
fine-grained policy control found in Internet Key Exchange Version 2
(IKEv2) [RFC5996] that allows IKEv2 to support complex gateway
policies. Thus, HIP DEX is not a replacement for IKEv2.
1.2. Memo Structure
The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout this
document. Section 3 defines the structure of the Host Identity and
its various representations. Section 4 gives an overview of the HIP
Diet EXchange protocol. Sections 5 and 6 define the detailed packet
formats and rules for packet processing. Finally, Sections 7, 8, and
9 discuss policy, security, and IANA considerations, respectively.
Moskowitz & Hummen Expires July 21, 2016 [Page 5]
Internet-Draft HIP Diet EXchange (DEX) January 2016
2. Terms and Definitions
2.1. Requirements Terminology
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].
2.2. Notation
[x] indicates that x is optional.
{x} indicates that x is encrypted.
X(y) indicates that y is a parameter of X.
<x>i indicates that x exists i times.
--> signifies "Initiator to Responder" communication (requests).
<-- signifies "Responder to Initiator" communication (replies).
| signifies concatenation of information - e.g., X | Y is the
concatenation of X and Y.
FOLD (X, K) denotes the partitioning of X into n K-bit segments and
the iterative folding of these segments via XOR. I.e., X = x_1,
x_2, ..., x_n, where x_i is of length K and the last segment x_n
is padded to length K by appending 0 bits. FOLD then is computed
as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1.
Ltrunc (M(x), K) denotes the lowest order K bits of the result of
the MAC function M on the input x.
2.3. Definitions
HIP Diet Exchange (DEX): The ECDH-based HIP handshake for
establishing a new HIP association.
Host Identity (HI): The static ECDH public key that represents the
identity of the host. In HIP DEX, a host proves ownership of the
private key belonging to its HI by creating a HIP_MAC with the
derived ECDH key (c.f. Section 3).
Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It
is generated by folding the HI (c.f. Section 3).
Moskowitz & Hummen Expires July 21, 2016 [Page 6]
Internet-Draft HIP Diet EXchange (DEX) January 2016
HIT Suite: A HIT Suite groups all algorithms that are required to
generate and use an HI and its HIT. In particular, these
algorithms are: 1) ECDH and 2) FOLD.
HIP association: The shared state between two peers after completion
of the HIP DEX handshake.
Initiator: The host that initiates the HIP DEX handshake. This role
is typically forgotten once the handshake is completed.
Responder: The host that responds to the Initiator in the HIP DEX
handshake. This role is typically forgotten once the handshake is
completed.
Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message
authentication code and not a cryptographic hash function. Thus,
a mapping from CMAC(x,y) to RHASH(z) must be defined where RHASH
is used. Moreover, RHASH has different security properties in HIP
DEX and is not used for HIT generation.
Length of the Responder's HIT Hash Algorithm (RHASH_len): The
natural output length of RHASH in bits.
CKDF: CMAC-based Key Derivation Function.
3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding
identifier.
HIP DEX implementations MUST support the Elliptic Curve Diffie-
Hellman (ECDH) [RFC6090] key exchange for generating the HI as
defined in Section 5.2.3. No additional algorithms are supported at
this time.
A compressed encoding of the HI, the Host Identity Tag (HIT), is used
in the handshake packets to represent the HI. The DEX Host Identity
Tag (HIT) is different from the BEX HIT in two ways:
o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4).
Moskowitz & Hummen Expires July 21, 2016 [Page 7]
Internet-Draft HIP Diet EXchange (DEX) January 2016
o The DEX HIT is not generated via a cryptographic hash. Rather, it
is a compression of the HI.
Due to the latter property, an attacker may be able to find a
collision with a HIT that is in use. Hence, policy decisions such as
access control MUST NOT be based solely on the HIT. Instead, the HI
of a host SHOULD be considered.
Carrying HIs and HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that
these parameters are carried in every packet, but other methods are
used to map the data packets to the corresponding HIs. In some
cases, this allows to use HIP DEX without any additional headers in
the user data packets. For example, if ESP is used to protect data
traffic, the Security Parameter Index (SPI) carried in the ESP header
can be used to map the encrypted data packet to the correct HIP DEX
association.
3.1. Host Identity Tag (HIT)
With HIP DEX, the HIT is a 128-bit value - a compression of the HI
prepended with a specific prefix. There are two advantages of using
a hashed encoding over the actual variable-sized public key in
protocols. First, the fixed length of the HIT keeps packet sizes
manageable and eases protocol coding. Second, it presents a
consistent format for the protocol, independent of the underlying
identity technology in use.
The structure of the HIT is based on RFC 7343 [RFC7343], called
Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and
consists of three parts: first, an IANA assigned prefix to
distinguish it from other IPv6 addresses. Second, a four-bit
encoding of the algorithms that were used for generating the HI and
the compressed representation of the HI. Third, a 96-bit hashed
representation of the HI. In contrast to HIPv2, HIP DEX employs HITs
that are NOT generated by means of a cryptographic hash. Instead,
the HI is compressed to 96 bits as defined in the following section.
3.2. Generating a HIT from an HI
The HIT does not follow the exact semantics of an ORCHID as there is
no hash function in HIP DEX. Still, its structure is strongly
aligned with the ORCHID design. The same IPv6 prefix used in HIPv2
is used for HIP DEX. The HIP DEX HIT suite (see Section 9) is used
for the four bits of the Orchid Generation Algorithm (OGA) field in
the ORCHID. The hash representation in an ORCHID is replaced with
FOLD(HI,96).
Moskowitz & Hummen Expires July 21, 2016 [Page 8]
Internet-Draft HIP Diet EXchange (DEX) January 2016
4. Protocol Overview
This section gives a simplified overview of the HIP DEX protocol
operation and does not contain all the details of the packet formats
or the packet processing steps. Section 5 and Section 6 describe
these aspects in more detail and are normative in case of any
conflicts with this section. Importantly, the information given in
this section focuses on the differences between the HIPv2 and HIP DEX
protocol specifications.
4.1. Creating a HIP Association
By definition, the system initiating a HIP Diet EXchange is the
Initiator, and the peer is the Responder. This distinction is
typically forgotten once the handshake completes, and either party
can become the Initiator in future communications.
The HIP Diet EXchange serves to manage the establishment of state
between an Initiator and a Responder. The first packet, I1,
initiates the exchange, and the last three packets, R1, I2, and R2,
constitute an authenticated Diffie-Hellman [DH76] key exchange for
the Master Key SA generation. This Master Key SA is used by the
Initiator and the Responder to wrap secret keying material in the I2
and R2 packets. Based on the exchanged keying material, the peers
then derive a Pair-wise Key SA if cryptographic keys are needed,
e.g., for ESP-based protection of user data.
The Initiator first sends a trigger packet, I1, to the Responder.
This packet contains the HIT of the Initiator and the HIT of the
Responder, if it is known. Moreover, the I1 packet initializes the
negotiation of the Diffie-Hellman group that is used for generating
the the Master Key SA. Therefore, the I1 packet contains a list of
Diffie-Hellman Group IDs supported by the Initiator. Note that in
some cases it may be possible to replace this trigger packet by some
other form of a trigger, in which case the protocol starts with the
Responder sending the R1 packet. In such cases, another mechanism to
convey the Initiator's supported DH Groups (e.g., by using a default
group) must be specified.
The second packet, R1, starts the actual authenticated Diffie-Hellman
key exchange. It contains a puzzle - a cryptographic challenge that
the Initiator must solve before continuing the exchange. The level
of difficulty of the puzzle can be adjusted based on level of trust
with the Initiator, current load, or other factors. In addition, the
R1 contains the Responder's Diffie-Hellman parameter and lists of
cryptographic algorithms supported by the Responder. Based on these
lists, the Initiator can continue, abort, or restart the handshake
with a different selection of cryptographic algorithms.
Moskowitz & Hummen Expires July 21, 2016 [Page 9]
Internet-Draft HIP Diet EXchange (DEX) January 2016
In the I2 packet, the Initiator MUST display the solution to the
received puzzle. Without a correct solution, the I2 packet is
discarded. The I2 also contains a key wrap parameter that carries a
secret keying material of the Initiator. This keying material is
only half the final session key. The packet is authenticated by the
sender (Initiator) via a MAC.
The R2 packet acknowledges the receipt of the I2 packet and completes
the handshake. The R2 contains a key wrap parameter that carries the
rest of the keying material of the Responder. The packet is
authenticated by the sender (Responder) via a MAC.
The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)"
and "ENC(DH,y)" refer to the random values x and y that are wrapped
based on the Master Key SA (indicated by ENC and DH). Note that x
and y each constitute half the final session key material. The
packets also contain other parameters that are not shown in this
figure.
Initiator Responder
I1:
--------------------------------->
remain stateless
R1: puzzle, HI
<--------------------------------
solve puzzle
perform ECDH
encrypt x
I2: solution, HI, ENC(DH,x), mac
--------------------------------->
check puzzle
perform ECDH
check mac
decrypt x
encrypt y
R2: ENC(DH,y), mac
<---------------------------------
check mac
decrypt y
4.1.1. HIP Puzzle Mechanism
The purpose of the HIP puzzle mechanism is to protect the Responder
from a number of denial-of-service threats. It allows the Responder
to delay state creation until receiving the I2 packet. Furthermore,
the puzzle allows the Responder to use a fairly cheap calculation to
Moskowitz & Hummen Expires July 21, 2016 [Page 10]
Internet-Draft HIP Diet EXchange (DEX) January 2016
check that the Initiator is "sincere" in the sense that it has
churned enough CPU cycles in solving the puzzle.
The puzzle mechanism enables a Responder to immediately reject an I2
packet if it does not contain a valid puzzle solution. To verify the
puzzle solution, the Responder only has to compute a single CMAC
operation. After a successful puzzle verification, the Responder can
securely create session-specific state and perform CPU-intensive
operations such as a Diffie-Hellman key generation. By varying the
difficulty of the puzzle, the Responder can frustrate CPU or memory
targeted DoS attacks. Under normal network conditions, the puzzle
difficulty SHOULD be zero, thus effectively reverting the puzzle
mechanism to a cookie-based DoS protection mechanism. Without
setting the puzzle difficulty to zero under normal network
conditions, potentially scarce computation resources at the Initiator
would be churned unnecessarily.
Conceptually, the puzzle mechanism in HIP DEX is the same as in
HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in
[RFC7401] for more detailed information about the employed mechanism.
Notably, the only difference between the puzzle mechanism in HIP DEX
and HIPv2 is that HIP DEX uses CMAC instead of a hash function for
solving and verifying a puzzle. The implications of this change on
the puzzle implementation are discussed in Section 6.1.
4.1.2. HIP State Machine
The HIP DEX state machine has the same states as the HIPv2 state
machine (see 4.4. in [RFC7401]). However, HIP DEX features a
retransmission strategy with an optional reception acknowledgement
for the I2 packet. The goal of this additional acknowledgement is to
reduce premature I2 retransmissions in case of devices with low
computation resources [HWZ13]. As a result, there are minor changes
regarding the transitions in the HIP DEX state machine. The
following section documents these differences compared to HIPv2.
4.1.2.1. HIP DEX Retransmission Mechanism
For the retransmission of I1 and I2 packets, the Initiator adopts the
retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]).
This strategy is based on a timeout that is set to a value larger
than the worst-case anticipated round-trip time (RTT). For each
received I1 or I2 packet, the Responder sends an R1 or R2 packet,
respectively. This design trait enables the Responder to remain
stateless until the reception and successful processing of the I2
packet. The Initiator stops retransmitting I1 or I2 packets after
the reception of the corresponding R1 or R2. If the Initiator did
not receive an R1 packet after I1_RETRIES_MAX tries, it stops I1
Moskowitz & Hummen Expires July 21, 2016 [Page 11]
Internet-Draft HIP Diet EXchange (DEX) January 2016
retransmissions. Likewise, it stops retransmitting the I2 packet
after I2_RETRIES_MAX unsuccessful tries.
For repeatedly received I2 packets, the Responder SHOULD NOT perform
operations related to the Diffie-Hellman key exchange or the keying
material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD
re-use the previously established state to re-create the
corresponding R2 packet in order to prevent unnecessary computation
overhead.
The potentially high processing time of an I2 packet at a (resource-
constrained) Responder may cause premature retransmissions if the
time required for I2 transmission and processing exceeds the RTT-
based retransmission timeout. Thus, the Initiator should also take
the processing time of the I2 packet at the Responder into account
for retransmission purposes. To this end, the Responder MAY notify
the Initiator about the anticipated delay once the puzzle solution
was successfully verified and if the remaining I2 packet processing
incurs a high processing delay. The Responder MAY therefore send a
NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator
before the Responder commences the ECDH operation. The NOTIFY packet
serves as an acknowledgement for the I2 packet and consists of a
NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT
(see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter
contains the anticipated remaining processing time for the I2 packet
in milliseconds as two-octet Notification Data. This processing time
can, e.g., be estimated by measuring the computation time of the ECDH
key derivation operation at Responder boot-up. After the I2
processing has finished, the Responder sends the regular R2 packet.
When the Initiator receives the NOTIFY packet, it sets the I2
retransmission timeout to the I2 processing time indicated in the
NOTIFICATION parameter plus half the RTT-based timeout value. In
doing so, the Initiator MUST NOT set the retransmission timeout to a
higher value than allowed by a local policy. This is to prevent
unauthenticated NOTIFY packets from maliciously delaying the
handshake beyond a well-defined upper bound in case of a lost R2
packet. At the same time, this extended retransmission timeout
enables the Initiator to defer I2 retransmissions until the point in
time when the Responder should have completed its I2 packet
processing and the network should have delivered the R2 packet
according to the employed worst-case estimates.
4.1.2.2. HIP State Processes
HIP DEX clarifies or introduces the following new transitions.
Moskowitz & Hummen Expires July 21, 2016 [Page 12]
Internet-Draft HIP Diet EXchange (DEX) January 2016
System behavior in state I2-SENT, Table 1.
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive NOTIFY, | Set I2 retransmission timer to value in |
| process | I2_ACKNOWLEDGEMENT Notification Data plus |
| | 1/2 RTT-based timeout value and stay at |
| | I2-SENT |
| | |
| Timeout | Increment trial counter |
| | |
| | If counter is less than I2_RETRIES_MAX, |
| | send I2, reset timer to RTT-based timeout, |
| | and stay at I2-SENT |
| | |
| | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange
4.1.2.3. Simplified HIP State Diagram
The following diagram shows the major state transitions. Transitions
based on received packets implicitly assume that the packets are
successfully authenticated or processed.
Moskowitz & Hummen Expires July 21, 2016 [Page 13]
Internet-Draft HIP Diet EXchange (DEX) January 2016
+--+ +----------------------------+
recv I1, send R1 | | | |
| v v |
+--------------+ recv I2, send R2 |
+----------------| UNASSOCIATED |----------------+ |
datagram | +--+ +--------------+ | |
to send, | | | Alg. not supported, | |
send I1 | | | send I1 | |
. v | v | |
. +---------+ recv I2, send R2 | |
+---->| I1-SENT |--------------------------------------+ | |
| +---------+ +----------------------+ | | |
| | recv R1, | recv I2, send R2 | | | |
| v send I2 | v v v |
| +---------+ | +---------+ |
| +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ |
| | +---------+ | +---------+ | |
| | | |recv R2 | data or| | |
| |recv R1, | | | EC timeout| | |
| |send I2 +--|-----------------+ | receive I2,| |
| | | | +-------------+ | send R2| |
| | | +------>| ESTABLISHED |<----------+ | |
| | | +-------------+ | |
| | | | | | receive I2, send R2 | |
| | +------------+ | +-------------------------------+ |
| | | +-----------+ | |
| | | no packet sent/received| +---+ | |
| | | for UAL min, send CLOSE| | |timeout | |
| | | v v |(UAL+MSL) | |
| | | +---------+ |retransmit | |
+--|----------|------------------------| CLOSING |-+CLOSE | |
| | +---------+ | |
| | | | | | | |
+----------|-------------------------+ | | +----------------+ |
| | +-----------+ +------------------|--+
| | |recv CLOSE, recv CLOSE_ACK | |
| +-------------+ |send CLOSE_ACK or timeout | |
| recv CLOSE, | | (UAL+MSL) | |
| send CLOSE_ACK v v | |
| +--------+ receive I2, send R2 | |
+---------------------| CLOSED |------------------------------+ |
+--------+ |
^ | | |
recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) |
+-+ +------------------------------------+
Moskowitz & Hummen Expires July 21, 2016 [Page 14]
Internet-Draft HIP Diet EXchange (DEX) January 2016
4.1.3. HIP DEX Security Associations
HIP DEX establishes two Security Associations (SA), one for the
Diffie-Hellman derived key, or Master Key, and one for the session
key, or Pair-wise Key.
4.1.3.1. Master Key SA
The Master Key SA is used to authenticate HIP packets and to encrypt
selected HIP parameters in the HIP DEX packet exchanges. Since only
little data is protected by this SA, it can be long-lived with no
need for rekeying.
The Master Key SA contains the following elements:
o Source HIT
o Destination HIT
o HIP_Encrypt Key
o HIP_MAC Key
The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie-
Hellman derived key as described in Section 6.3. Their length is
determined by the HIP_CIPHER.
4.1.3.2. Pair-wise Key SA
The Pair-wise Key SA is used to authenticate and to encrypt user
data. It is refreshed (or rekeyed) using an UPDATE packet exchange.
The Pair-wise Key SA elements are defined by the data transform (e.g.
ESP_TRANSFORM [RFC7402]).
The keys for the Pair-wise Key SA are derived based on the wrapped
keying material exchanged in the ENCRYPTED_KEY parameter (see
Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged
keying material of the two peers is concatenated. This concatenation
forms the input to a Key Derivation Function (KDF). If the data
transform does not specify its own KDF, the key derivation function
defined in Section 6.3 is used. Even though this input is randomly
distributed, a KDF Extract phase may be needed to get the proper
length for the input to the KDF Expand phase.
Moskowitz & Hummen Expires July 21, 2016 [Page 15]
Internet-Draft HIP Diet EXchange (DEX) January 2016
4.1.4. User Data Considerations
The User Data Considerations in Section 4.5. of [RFC7401] also apply
to HIP DEX. There is only one difference between HIPv2 and HIP DEX.
Loss of state due to system reboot may be a critical performance
issue for resource-constrained devices. Thus, implementors MAY
choose to use non-volatile, secure storage for HIP states in order
for them to survive a system reboot. This will limit state loss
during reboots to only those situations with an SA timeout.
5. Packet Formats
5.1. Payload Format
HIP DEX employs the same fixed HIP header and payload structure as
HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also
apply to HIP DEX.
5.2. HIP Parameters
The HIP parameters carry information that is necessary for
establishing and maintaining a HIP association. For example, the
peer's public keys as well as the signaling for negotiating ciphers
and payload handling are encapsulated in HIP parameters. Additional
information, meaningful for end-hosts or middleboxes, may also be
included in HIP parameters. The specification of the HIP parameters
and their mapping to HIP packets and packet types is flexible to
allow HIP extensions to define new parameters and new protocol
behavior.
In HIP packets, HIP parameters are ordered according to their numeric
type number and encoded in TLV format.
HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of
[RFC7401] where possible. Still, HIP DEX further restricts and/or
extends the following existing parameter types:
o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites.
o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT.
o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD.
o RHASH and RHASH_len are redefined to CMAC for the PUZZLE,
SOLUTION, and HIP_MAC parameters (see Section 6.1 and
Section 6.2).
In addition, HIP DEX introduces the following new parameter:
Moskowitz & Hummen Expires July 21, 2016 [Page 16]
Internet-Draft HIP Diet EXchange (DEX) January 2016
+------------------+------+----------+------------------------------+
| TLV | Type | Length | Data |
+------------------+------+----------+------------------------------+
| ENCRYPTED_KEY | 643 | variable | Encrypted container for the |
| | | | session key exchange |
+------------------+------+----------+------------------------------+
5.2.1. DH_GROUP_LIST
The DH_GROUP_LIST parameter contains the list of supported DH Group
IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With
HIP DEX, the DH Group IDs are restricted to:
Group KDF Value
NIST P-256 [RFC5903] CKDF 7
NIST P-384 [RFC5903] CKDF 8
NIST P-521 [RFC5903] CKDF 9
SECP160R1 [SECG] CKDF 10
The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH
group 10 is covered in [SECG] and Appendix D of [RFC7401]. Any ECDH
used with HIP MUST have a co-factor of 1.
5.2.2. HIP_CIPHER
The HIP_CIPHER parameter contains the list of supported cipher
algorithms to be used for encrypting the contents of the ENCRYPTED
and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in
Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to:
Suite ID Value
RESERVED 0
NULL-ENCRYPT 1 ([RFC2410])
AES-128-CTR 5 ([RFC3686])
Mandatory implementation: AES-128-CTR. Implementors SHOULD support
NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT
offer or accept this value unless explicitly configured for testing/
debugging of HIP.
5.2.3. HOST_ID
The HOST_ID parameter conveys the Host Identity (HI) along with
optional information about a host. It is defined in Section 5.2.9 of
[RFC7401].
Moskowitz & Hummen Expires July 21, 2016 [Page 17]
Internet-Draft HIP Diet EXchange (DEX) January 2016
HIP DEX uses the public portion of a host's static ECDH key-pair as
the HI. Correspondingly, HIP DEX limits the HI algorithms to the
following profile:
Algorithm profiles Value
ECDH 11 [RFC6090] (REQUIRED)
HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see
Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is
encoded in the "ECC curve" field of the HOST_ID parameter. The
supported DH Group IDs are defined in Section 5.2.1.
5.2.4. HIT_SUITE_LIST
The HIT_SUITE_LIST parameter contains a list of the supported HIT
suite IDs of the Responder. Based on the HIT_SUITE_LIST, the
Initiator can determine which source HIT Suite IDs are supported by
the Responder. The HIT_SUITE_LIST parameter is defined in
Section 5.2.10 of [RFC7401].
The following HIT Suite IDs are defined for HIP DEX, and the
relationship between the four-bit ID value used in the OGA ID field
and the eight-bit encoding within the HIT_SUITE_LIST ID field is
clarified:
HIT Suite Four-bit ID Eight-bit encoding
ECDH/FOLD 8 0x80
Note that the HIP DEX HIT Suite ID allows the peers to distinguish a
HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond
with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP
DEX HIT.
5.2.5. ENCRYPTED_KEY
Moskowitz & Hummen Expires July 21, 2016 [Page 18]
Internet-Draft HIP Diet EXchange (DEX) January 2016
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Encrypted value /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 643
Length length in octets, excluding Type, Length, and
Padding
Encrypted The value is encrypted using an encryption algorithm
value as defined in the HIP_CIPHER parameter.
The ENCRYPTED_KEY parameter encapsulates a random value that is later
used in the session key creation process (see Section 6.3). This
random value MUST have a length of at least 64 bit. The puzzle value
#I and the puzzle solution #J (see [RFC7401]) are used as the
initialization vector (IV) for the encryption process. To this end,
the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16
bit value that is initialized to zero with the first use.
Once this encryption process is completed, the "encrypted value" data
field is ready for inclusion in the Parameter. If necessary,
additional Padding for 8-byte alignment is then added according to
the rules of TLV Format in [RFC7401].
5.3. HIP Packets
HIP DEX uses the same eight basic HIP packets as HIPv2 (see
Section 5.3 of [RFC7401]). Four of them are for the HIP handshake
(I1, R1, I2, and R2), one is for updating an association (UPDATE),
one is for sending notifications (NOTIFY), and two are for closing
the association (CLOSE and CLOSE_ACK). There are some differences
regarding the HIP parameters that are included in the handshake
packets concerning HIP BEX and HIP DEX. This section covers these
differences for the DEX packets. Packets not discussed here, follow
the structure defined in [RFC7401].
An important difference between packets in HIP BEX and HIP DEX is
that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not
included in HIP DEX. Thus, the R1 packet is completely unprotected
and can be spoofed. As a result, negotiation parameters contained in
the R1 packet have to be re-included in later, protected packets in
order to detect and prevent potential downgrading attacks. Moreover,
Moskowitz & Hummen Expires July 21, 2016 [Page 19]
Internet-Draft HIP Diet EXchange (DEX) January 2016
the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not
covered by a signature and purely rely on the HIP_MAC parameter for
packet authentication. The processing of these packets is changed
accordingly.
In the future, an optional upper-layer payload MAY follow the HIP
header. The Next Header field in the header indicates if there is
additional data following the HIP header.
5.3.1. I1 - the HIP Initiator Packet
The HIP header values for the I1 packet:
Header:
Packet Type = 1
SRC HIT = Initiator's HIT
DST HIT = Responder's HIT, or NULL
IP ( HIP ( DH_GROUP_LIST ) )
Valid control bits: none
The I1 packet contains the fixed HIP header and the Initiator's
DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX
type as defined in Section 5.2.4.
Regarding the Responder's HIT, the Initiator may receive this HIT
either from a DNS lookup of the Responder's FQDN, from some other
repository, or from a local table. The Responder's HIT also MUST be
of a HIP DEX type. If the Initiator does not know the Responder's
HIT, it may attempt to use opportunistic mode by using NULL (all
zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for
detailed information about the "HIP Opportunistic Mode".
As a compression of the employed HIs, the Initiator's and the
Responder's HITs both determine the DH group ID that must be used in
order to successfully conclude the triggered handshake. HITs,
however, only include the OGA ID identifying a HIP DEX HIT. They do
not include information about the specific DH group ID of the
corresponding HI. To inform the Responder about its employed and its
otherwise supported DH Group IDs, the Initiator therefore includes
the DH_GROUP_LIST parameter in the I1 packet. This parameter MUST
include the DH group ID that corresponds to the currently employed
Initiator HIT as the first list element. With HIP DEX, the
DH_GROUP_LIST parameter MUST only include ECDH groups defined in
Section 5.2.1.
Moskowitz & Hummen Expires July 21, 2016 [Page 20]
Internet-Draft HIP Diet EXchange (DEX) January 2016
Since this packet is so easy to spoof even if it were protected, no
attempt is made to add to its generation or processing cost. As a
result, the DH_GROUP_LIST in the I1 packet is not protected.
Implementations MUST be able to handle a storm of received I1
packets, discarding those with common content that arrive within a
small time delta.
5.3.2. R1 - the HIP Responder Packet
The HIP header values for the R1 packet:
Header:
Packet Type = 2
SRC HIT = Responder's HIT
DST HIT = Initiator's HIT
IP ( HIP ( [ R1_COUNTER, ]
PUZZLE,
DH_GROUP_LIST,
HIP_CIPHER,
HOST_ID,
HIT_SUITE_LIST,
TRANSPORT_FORMAT_LIST,
[ <, ECHO_REQUEST_UNSIGNED >i ])
Valid control bits: A
If the Responder's HI is an anonymous one, the A control MUST be set.
The Initiator's HIT MUST match the one received in the I1 packet if
the R1 is a response to an I1. If the Responder has multiple HIs,
the Responder's HIT MUST match the Initiator's request. If the
Initiator used opportunistic mode, the Responder may select among its
HIs as described below. See Section 4.1.8 of [RFC7401] for detailed
information about the "HIP Opportunistic Mode".
The R1 packet generation counter is used to determine the currently
valid generation of puzzles. The value is increased periodically,
and it is RECOMMENDED that it is increased at least as often as
solutions to old puzzles are no longer accepted.
The Puzzle contains a Random value #I and the puzzle difficulty K.
The difficulty K indicates the number of lower-order bits, in the
puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders
SHOULD set K to zero by default and only increase the puzzle
difficulty to protect against a DoS attack targeting the HIP DEX
handshake. A puzzle difficulty of zero effectively turns the puzzle
Moskowitz & Hummen Expires July 21, 2016 [Page 21]
Internet-Draft HIP Diet EXchange (DEX) January 2016
mechanism into a return-routablility test and is strongly encouraged
during normal operation in order to conserve energy resources as well
as to prevent unnecessary handshake delay in case of a resource-
constrained Initiator.
The DH_GROUP_LIST parameter contains the Responder's order of
preference based on which it chose the ECDH key contained in the
HOST_ID parameter (see below). This allows the Initiator to
determine whether its own DH_GROUP_LIST in the I1 packet was
manipulated by an attacker. There is a further risk that the
Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1
packet cannot be authenticated in HI DEX. Thus, this parameter is
repeated in the R2 packet to allow for a final, cryptographically
secured validation.
The HIP_CIPHER contains the encryption algorithms supported by the
Responder to protect the key exchange, in the order of preference.
All implementations MUST support the AES-CTR [RFC3686].
The HIT_SUITE_LIST parameter is an ordered list of the Responder's
supported and preferred HIT Suites. It enables a Responder to notify
the Initiator about other available HIT suites than the one used in
the current handshake. Based on the received HIT_SUITE_LIST, the
Initiator MAY decide to abort the current handshake and initiate a
new handshake with a different mutually supported HIT suite. This
mechanism can, e.g., be used to move from an initial HIP DEX
handshake to a HIP BEX handshake for peers supporting both protocol
variants.
The HOST_ID parameter depends on the received DH_GROUP_LIST parameter
and the Responder HIT in the I1 packet. Specifically, if the I1
contains a Responder HIT, the Responder verifies that this HIT
matches the required DH group based on the received DH_GROUP_LIST
parameter. In case of a positive result, the Responder selects the
corresponding HOST_ID for inclusion in the R1 packet. Likewise, if
the Responder HIT in the I1 packet is NULL (i.e., during an
opportunistic handshake), the Responder chooses its HOST_ID according
to the Initiator's employed DH group as indicated in the received
DH_GROUP_LIST parameter and sets the source HIT in the R1 packet
accordingly. If the Responder however does not support the DH group
required by the Initiator or if the Responder HIT in the I1 packet
does not match the required DH group, the Responder selects the
mutually preferred and supported DH group based on the DH_GROUP_LIST
parameter in the I1 packet. The Responder then includes the
corresponding ECDH key in the HOST_ID parameter. This parameter also
indicates the selected DH group. Moreover, the Responder sets the
source HIT in the R2 packet based on the destination HIT from the I1
packet. Based on the deviating DH group ID in the HOST_ID parameter,
Moskowitz & Hummen Expires July 21, 2016 [Page 22]
Internet-Draft HIP Diet EXchange (DEX) January 2016
the Initiator then SHOULD abort the current handshake and initiate a
new handshake with the mutually supported DH group as far as local
policies (see Section 7) permit.
The TRANSPORT_FORMAT_LIST parameter is an ordered list of the
Responder's supported and preferred transport format types. The list
allows the Initiator and the Responder to agree on a common type for
payload protection. Currently, the only transport format defined is
IPsec ESP [RFC7402].
The ECHO_REQUEST_UNSIGNED parameters contain data that the sender
wants to receive unmodified in the corresponding response packet in
the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero
or more ECHO_REQUEST_UNSIGNED parameters.
5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet:
Header:
Type = 3
SRC HIT = Initiator's HIT
DST HIT = Responder's HIT
IP ( HIP ( [R1_COUNTER,]
SOLUTION,
HIP_CIPHER,
ENCRYPTED_KEY,
HOST_ID,
TRANSPORT_FORMAT_LIST,
HIP_MAC,
[<, ECHO_RESPONSE_UNSIGNED>i )] )
Valid control bits: A
The HITs MUST match the ones used in the R1 packet.
If the Initiator's HI is an anonymous one, the A control bit MUST be
set.
If present in the R1 packet, the Initiator MUST include an unmodified
copy of the R1_COUNTER parameter into the I2 packet.
The Solution contains the Random #I from the R1 packet and the
computed #J value. The low-order #K bits of the RHASH(I | ... | J)
MUST be zero.
Moskowitz & Hummen Expires July 21, 2016 [Page 23]
Internet-Draft HIP Diet EXchange (DEX) January 2016
The HIP_CIPHER contains the single encryption transform selected by
the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY
parameters. The chosen cipher MUST correspond to one of the ciphers
offered by the Responder in the R1. All implementations MUST support
the AES-CTR transform [RFC3686].
The HOST_ID parameter contains the Initiator HI corresponding to the
Initiator HIT.
The ENCRYPTED_KEY parameter contains an Initiator generated random
value that MUST be uniformly distributed. This random value is
encrypted with the Master Key SA using the HIP_CIPHER encryption
algorithm.
The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque
data copied from the corresponding echo request parameter(s). This
parameter can also be used for two-factor password authentication as
shown in Appendix A.
The TRANSPORT_FORMAT_LIST parameter contains the single transport
format type selected by the Initiator. The chosen type MUST
correspond to one of the types offered by the Responder in the R1
packet. Currently, the only transport format defined is the ESP
transport format [RFC7402].
The MAC is calculated over the whole HIP envelope, excluding any
parameters after the HIP_MAC parameter as described in Section 6.2.
The Responder MUST validate the HIP_MAC parameter.
5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet:
Header:
Packet Type = 4
SRC HIT = Responder's HIT
DST HIT = Initiator's HIT
IP ( HIP ( DH_GROUP_LIST,
HIP_CIPHER,
ENCRYPTED_KEY,
HIT_SUITE_LIST,
TRANSPORT_FORMAT_LIST,
HIP_MAC)
Valid control bits: none
The HITs used MUST match the ones used in the I2 packet.
Moskowitz & Hummen Expires July 21, 2016 [Page 24]
Internet-Draft HIP Diet EXchange (DEX) January 2016
The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST,
and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These
parameters MUST be the same as included in the R1 packet. The
parameter are re-included here because the R2 packet is MACed and
thus cannot be altered by an attacker. For verification purposes,
the Initiator re-evaluates the selected suites and compares the
results against the chosen ones. If the re-evaluated suites do not
match the chosen ones, the Initiator acts based on its local policy.
The ENCRYPTED_KEY parameter contains an Responder generated random
value that MUST be uniformly distributed. This random value is
encrypted with the Master Key SA using the HIP_CIPHER encryption
algorithm.
The MAC is calculated over the whole HIP envelope, excluding any
parameters after the HIP_MAC, as described in Section 6.2. The
Initiator MUST validate the HIP_MAC parameter.
5.4. ICMP Messages
When a HIP implementation detects a problem with an incoming packet,
and it either cannot determine the identity of the sender of the
packet or does not have any existing HIP association with the sender
of the packet, it MAY respond with an ICMP packet. Any such reply
MUST be rate-limited as described in [RFC4443]. In most cases, the
ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for
ICMPv6), with the Pointer field pointing to the field that caused the
ICMP message to be generated. The problem cases specified in
Section 5.4. of [RFC7401] also apply to HIP DEX.
6. Packet Processing
Due to the adopted protocol semantics and the inherited general
packet structure, the packet processing in HIP DEX only differs from
HIPv2 in very few places. Here, we focus on these differences and
refer to Section 6 in [RFC7401] otherwise.
The processing of outgoing and incoming application data remains the
same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]).
6.1. Solving the Puzzle
The procedures for solving and verifying a puzzle in HIP DEX are
strongly based on the corresponding procedures in HIPv2. The only
exceptions are that HIP DEX does not use pre-computation of R1
packets and that RHASH is set to CMAC. As a result, the pre-
computation step in in Section 6.3 of [RFC7401] is skipped in HIP
DEX.
Moskowitz & Hummen Expires July 21, 2016 [Page 25]
Internet-Draft HIP Diet EXchange (DEX) January 2016
Moreover, the Initiator solves a puzzle by computing:
Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0
Similarly, the Responder verifies a puzzle by computing:
V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K )
Apart from these modifications, the procedures defined in Section 6.3
of [RFC7401] also apply for HIP DEX.
6.2. HIP_MAC Calculation and Verification
The following subsections define the actions for processing the
HIP_MAC parameter.
6.2.1. CMAC Calculation
The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying
cryptographic function. The scope of the calculation for HIP_MAC is:
CMAC: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters of the packet that is
being calculated with Type values ranging from 1 to (HIP_MAC's Type
value - 1) and exclude parameters with Type values greater or equal
to HIP_MAC's Type value.
During HIP_MAC calculation, the following applies:
o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_MAC parameter.
The parameter order is described in Section 5.2.1 of [RFC7401].
The CMAC calculation and verification process is as follows:
Packet sender:
1. Create the HIP packet, without the HIP_MAC or any other parameter
with greater Type value than the HIP_MAC parameter has.
2. Calculate the Header Length field in the HIP header.
3. Compute the CMAC using either HIP-gl or HIP-lg integrity key
retrieved from KEYMAT as defined in Section 6.3.
Moskowitz & Hummen Expires July 21, 2016 [Page 26]
Internet-Draft HIP Diet EXchange (DEX) January 2016
4. Add the HIP_MAC parameter to the packet and any parameter with
greater Type value than the HIP_MAC's that may follow.
5. Recalculate the Length field in the HIP header.
Packet receiver:
1. Verify the HIP header Length field.
2. Remove the HIP_MAC parameter, as well as all other parameters
that follow it with greater Type value, saving the contents if
they will be needed later.
3. Recalculate the HIP packet length in the HIP header and clear the
Checksum field (set it to all zeros).
4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as
defined in Section 6.3 and verify it against the received CMAC.
5. Set Checksum and Header Length fields in the HIP header to
original values. Note that the Checksum and Length fields
contain incorrect values after this step.
6.3. HIP DEX KEYMAT Generation
The HIP DEX KEYMAT process is used to derive the keys for the Master
Key SA as well as for the Pair-wise Key SA. The keys for the Master
Key SA are based from the Diffie-Hellman derived key, Kij, produced
during the HIP DEX handshake. The Initiator generates Kij during the
creation of the I2 packet and the Responder generates Kij once it
receives the I2 packet. Hence, I2, R2, UPDATE, CLOSE, and CLOSE_ACK
packets can contain authenticated and/or encrypted information.
The keys of the Pair-wise Key SA are not directly used in the HIP DEX
handshake. Instead, these keys are made available as payload
protection keys. Some payload protection mechanisms have their own
Key Derivation Function, and if so this mechanism SHOULD be used.
Otherwise, the HIP DEX KEYMAT process MUST be used to derive the keys
of the Pair-wise Key SA based on the concatenation of the random
values that are contained in the exchanged ENCRYPTED_KEY parameters.
The HIP DEX KEYMAT process consists of two components, CKDF-Extract
and CKDF-Expand. The Extract function compresses a non-uniformly
distributed key, as is the output of a Diffie-Hellman key derivation,
to extract the key entropy into a fixed length output. The Expand
function takes either the output of the Extract function or directly
uses a uniformly distributed key and expands the length of the key,
repeatedly distributing the key entropy, to produce the keys needed.
Moskowitz & Hummen Expires July 21, 2016 [Page 27]
Internet-Draft HIP Diet EXchange (DEX) January 2016
The key derivation for the Master Key SA employs both the Extract and
Expand phases, whereas the Pair-wise Key SA MAY need both the Extract
and Expand phases if the key is longer than 128 bits. Otherwise, it
only requires the Expand phase.
The CKDF-Extract function is the following operation:
CKDF-Extract(I, IKM, info) -> PRK
where
I Random #I from the PUZZLE parameter
IKM Input keying material, i.e., either the Diffie-Hellman
derived key or the concatenation of the random values
of the ENCRYPTED_KEY parameters in the same order as
the HITs with sort(HIT-I | HIT-R)
info sort(HIT-I | HIT-R) | "CKDF-Extract"
PRK a pseudorandom key (of RHASH_len/8 octets)
| denotes the concatenation
The pseudorandom key PRK is calculated as follows:
PRK = CMAC(I, IKM | info)
The CKDF-Expand function is the following operation:
Moskowitz & Hummen Expires July 21, 2016 [Page 28]
Internet-Draft HIP Diet EXchange (DEX) January 2016
CKDF-Expand(PRK, info, L) -> OKM
where
PRK a pseudorandom key of at least RHASH_len/8 octets
(either the output from the extract step or the
concatenation of the random values of the
ENCRYPTED_KEY parameters in the same order as the
HITs with sort(HIT-I | HIT-R))
info sort(HIT-I | HIT-R) | "CKDF-Expand"
L length of output keying material in octets
(<= 255*RHASH_len/8)
| denotes the concatenation
The output keying material OKM is calculated as follows:
N = ceil(L/RHASH_len/8)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
where
T(0) = empty string (zero length)
T(1) = CMAC(PRK, T(0) | info | 0x01)
T(2) = CMAC(PRK, T(1) | info | 0x02)
T(3) = CMAC(PRK, T(2) | info | 0x03)
...
(where the constant concatenated to the end of each T(n) is a
single octet.)
sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte
order.
The initial keys are drawn sequentially in the order that is
determined by the numeric comparison of the two HITs, with the
comparison method described in the previous paragraph. HOST_g
denotes the host with the greater HIT value, and HOST_l the host with
the lower HIT value.
The drawing order for initial keys:
1. HIP-gl encryption key for HOST_g's outgoing HIP packets
2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets
Moskowitz & Hummen Expires July 21, 2016 [Page 29]
Internet-Draft HIP Diet EXchange (DEX) January 2016
3. HIP-lg encryption key for HOST_l's outgoing HIP packets
4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets
The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes
apply:
AES 128 or 256 bits
If other key sizes are used, they must be treated as different
encryption algorithms and defined separately.
6.4. Initiation of a HIP Diet EXchange
The initiation of a HIP DEX handshake proceeds as described in
Section 6.6 of [RFC7401]. The I1 packet contents are specified in
Section 5.3.1.
6.5. Processing Incoming I1 Packets
I1 packets in HIP DEX are handled almost identical to HIPv2 (see
Section 6.7 of [RFC7401]). The main differences are that the
Responder SHOULD select a HIP DEX HIT Suite in the R1 response.
Moreover, as R1 packets are neither covered by a signature nor incur
the overhead of generating an ephemeral Diffie-Hellman key-pair, pre-
computation of an R1 is only marginally beneficial, but would incur
additional memory resources at the Responder. Hence, the R1 pre-
computation SHOULD be omitted in HIP DEX.
Correspondingly, the modified conceptual processing rules for
responding to an I1 packet are as follows:
1. The Responder MUST check that the Responder's HIT in the received
I1 packet is either one of its own HITs or NULL. Otherwise, it
must drop the packet.
2. If the Responder is in ESTABLISHED state, the Responder MAY
respond to this with an R1 packet, prepare to drop an existing
HIP security association with the peer, and stay at ESTABLISHED
state.
3. If the Responder is in I1-SENT state, it MUST make a comparison
between the sender's HIT and its own (i.e., the receiver's) HIT.
If the sender's HIT is greater than its own HIT, it should drop
the I1 packet and stay at I1-SENT. If the sender's HIT is
smaller than its own HIT, it SHOULD send the R1 packet and stay
Moskowitz & Hummen Expires July 21, 2016 [Page 30]
Internet-Draft HIP Diet EXchange (DEX) January 2016
at I1-SENT. The HIT comparison is performed as defined in
Section 6.3.
4. If the implementation chooses to respond to the I1 packet with an
R1 packet, it creates a new R1 according to the format described
in Section 5.3.2. It chooses the HI based on the destination HIT
and the DH_GROUP_LIST in the I1 packet. If the implementation
does not support the DH group required by the Initiator or if the
destination HIT in the I1 packet does not match the required DH
group, it selects the mutually preferred and supported DH group
based on the DH_GROUP_LIST parameter in the I1 packet. The
implementation includes the corresponding ECDH public key in the
HOST_ID parameter. If no suitable DH Group ID was contained in
the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with
any suitable ECDH public key.
5. If the received Responder's HIT in the I1 packet is not NULL, the
Responder's in the R1 packet HIT MUST match the destination HIT
in the I1 packet. Otherwise, the Responder MUST select a HIT
with the same HIT Suite as the Initiator's HIT. If this HIT
Suite is not supported by the Responder, it SHOULD select a
REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is
currently RSA/DSA/SHA-256. Other than that, selecting the HIT is
a local policy matter.
6. The Responder expresses its supported HIP transport formats in
the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of
[RFC7401]. The Responder MUST provide at least one payload
transport format type.
7. The Responder sends the R1 packet to the source IP address of the
I1 packet.
Note that only steps 4 and 5 have been changed with regard to the
processing rules of HIPv2. The considerations about R1 management
(except pre-computation) and malformed I1 packets in Sections 6.7.1
and 6.7.2 of [RFC7401] likewise apply to HIP DEX.
6.6. Processing Incoming R1 Packets
R1 packets in HIP DEX are handled identically to HIPv2 (see
Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses
ECDH public keys as HIs and does not employ signatures.
The modified conceptual processing rules for responding to an R1
packet are as follows:
Moskowitz & Hummen Expires July 21, 2016 [Page 31]
Internet-Draft HIP Diet EXchange (DEX) January 2016
1. A system receiving an R1 MUST first check to see if it has sent
an I1 packet to the originator of the R1 packet (i.e., it has a
HIP association that is in state I1-SENT and that is associated
with the HITs in the R1). Unless the I1 packet was sent in
opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP
addresses in the received R1 packet SHOULD be ignored by the R1
processing and, when looking up the right HIP association, the
received R1 packet SHOULD be matched against the associations
using only the HITs. If a match exists, the system should
process the R1 packet as described below.
2. Otherwise, if the system is in any state other than I1-SENT or
I2-SENT with respect to the HITs included in the R1 packet, it
SHOULD silently drop the R1 packet and remain in the current
state.
3. If the HIP association state is I1-SENT or I2-SENT, the received
Initiator's HIT MUST correspond to the HIT used in the original
I1 packet. Also, the Responder's HIT MUST correspond to the one
used in the I1 packet, unless this packet contained a NULL HIT.
4. If the HIP association state is I1-SENT, and multiple valid R1
packets are present, the system MUST select from among the R1
packets with the largest R1 generation counter.
5. The system MUST check that the Initiator's HIT Suite is
contained in the HIT_SUITE_LIST parameter in the R1 packet
(i.e., the Initiator's HIT Suite is supported by the Responder).
If the HIT Suite is supported by the Responder, the system
proceeds normally. Otherwise, the system MAY stay in state
I1-SENT and restart the HIP DEX handshake by sending a new I1
packet with an Initiator HIT that is supported by the Responder
and hence is contained in the HIT_SUITE_LIST in the R1 packet.
The system MAY abort the handshake if no suitable source HIT is
available. The system SHOULD wait for an acceptable time span
to allow further R1 packets with higher R1 generation counters
or different HIT and HIT Suites to arrive before restarting or
aborting the HIP DEX handshake.
6. The system MUST check that the DH Group ID in the HOST_ID
parameter in the R1 matches the first DH Group ID in the
Responder's DH_GROUP_LIST in the R1 packet, and also that this
Group ID corresponds to a value that was included in the
Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID
of the HOST_ID parameter does not express the Responder's best
choice, the Initiator can conclude that the DH_GROUP_LIST in the
I1 or R1 packet was adversely modified. In such a case, the
Initiator MAY send a new I1 packet; however, it SHOULD NOT
Moskowitz & Hummen Expires July 21, 2016 [Page 32]
Internet-Draft HIP Diet EXchange (DEX) January 2016
change its preference in the DH_GROUP_LIST in the new I1 packet.
Alternatively, the Initiator MAY abort the HIP DEX handshake.
Moreover, if the DH Group ID indicated in the HOST_ID parameter
does not match the DH Group ID of the HI employed by the
Initiator, the system SHOULD wait for an acceptable time span to
allow further R1 packets with different DH Group IDs to arrive
before restarting or aborting the HIP DEX handshake. When
restarting the handshake, the Initiator MUST consult local
policies (see Section 7) regarding the use of another, mutually
supported DH group for the subsequent handshake with the
Responder.
7. If the HIP association state is I2-SENT, the system MAY re-enter
state I1-SENT and process the received R1 packet if it has a
larger R1 generation counter than the R1 packet responded to
previously.
8. The R1 packet may have the A-bit set - in this case, the system
MAY choose to refuse it by dropping the R1 packet and returning
to state UNASSOCIATED. The system SHOULD consider dropping the
R1 packet only if it used a NULL HIT in the I1 packet. If the
A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be
stored permanently.
9. The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT.
10. The system MUST store the received R1 generation counter for
future reference.
11. The system attempts to solve the puzzle in the R1 packet. The
system MUST terminate the search after exceeding the remaining
lifetime of the puzzle. If the puzzle is not successfully
solved, the implementation MAY either resend the I1 packet
within the retry bounds or abandon the HIP base exchange.
12. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the
HOST_ID parameter. The Diffie-Hellman keying material Kij is
used for key extraction as specified in Section 6.3.
13. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2
packet. If the proposed alternatives are not acceptable to the
system, it may either resend an I1 packet within the retry
bounds or abandon the HIP base exchange.
Moskowitz & Hummen Expires July 21, 2016 [Page 33]
Internet-Draft HIP Diet EXchange (DEX) January 2016
14. The system chooses one suitable transport format from the
TRANSPORT_FORMAT_LIST and includes the respective transport
format parameter in the subsequent I2 packet.
15. The system initializes the remaining variables in the associated
state, including Update ID counters.
16. The system prepares and sends an I2 packet as described in
Section 5.3.3.
17. The system SHOULD start a timer whose timeout value SHOULD be
larger than the worst-case anticipated RTT, and MUST increment a
trial counter associated with the I2 packet. The sender SHOULD
retransmit the I2 packet upon a timeout and restart the timer,
up to a maximum of I2_RETRIES_MAX tries.
18. If the system is in state I1-SENT, it SHALL transition to state
I2-SENT. If the system is in any other state, it remains in the
current state.
Note that step 4 from the original processing rules of HIPv2
(signature verification) has been removed in the above processing
rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules
has been adapted to account for the fact that HIP DEX uses ECDH
public keys as HIs. The considerations about malformed R1 packets in
Sections 6.8.1 of [RFC7401] also apply to HIP DEX.
6.7. Processing Incoming I2 Packets
The processing of I2 packets follows similar rules as HIPv2 (see
Section 6.9 of [RFC7401]). The main differences to HIPv2 are that
HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY
parameter as well as an I2 reception acknowledgement for
retransmission purposes. Moreover, with HIP DEX the Initiator is
responsible for triggering retransmissions, whereas the Responder
merely replies to received I2 packets.
The modified HIP DEX conceptual processing rules for responding to an
I2 packet are:
1. The system MAY perform checks to verify that the I2 packet
corresponds to a recently sent R1 packet. Such checks are
implementation dependent. See Appendix A in [RFC7401] for a
description of an example implementation.
2. The system MUST check that the Responder's HIT corresponds to
one of its own HITs and MUST drop the packet otherwise.
Moskowitz & Hummen Expires July 21, 2016 [Page 34]
Internet-Draft HIP Diet EXchange (DEX) January 2016
3. The system MUST further check that the Initiator's HIT Suite is
supported. The Responder SHOULD silently drop I2 packets with
unsupported Initiator HITs.
4. If the system's state machine is in the R2-SENT state, the
system MUST check to see if the newly received I2 packet is
similar to the one that triggered moving to R2-SENT. If so, it
MUST retransmit a previously sent R2 packet and reset the
R2-SENT timer. The system SHOULD re-use the previously
established state to re-create the corresponding R2 packet in
order to prevent unnecessary computation overhead.
5. If the system's state machine is in the I2-SENT state, the
system MUST make a comparison between its local and sender's
HITs (similarly as in Section 6.3). If the local HIT is smaller
than the sender's HIT, it should drop the I2 packet, use the
peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
#I from the R1 packet received earlier, and get the local
Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
from the I2 packet sent to the peer earlier. Otherwise, the
system should process the received I2 packet and drop any
previously derived Diffie-Hellman keying material Kij and
ENCRYPTED_KEY keying material it might have generated upon
sending the I2 packet previously. The peer Diffie-Hellman key,
ENCRYPTED_KEY, and the nonce #J are taken from the just arrived
I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying
material, and the nonce #I are the ones that were sent earlier
in the R1 packet.
6. If the system's state machine is in the I1-SENT state, and the
HITs in the I2 packet match those used in the previously sent I1
packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes
the additional checks below).
7. If the system's state machine is in any state other than
R2-SENT, the system SHOULD check that the echoed R1 generation
counter in the I2 packet is within the acceptable range if the
counter is included. Implementations MUST accept puzzles from
the current generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly received I2
packet is outside the accepted range, the I2 packet is stale
(and perhaps replayed) and SHOULD be dropped.
8. The system MUST validate the solution to the puzzle as described
in Section 6.1.
Moskowitz & Hummen Expires July 21, 2016 [Page 35]
Internet-Draft HIP Diet EXchange (DEX) January 2016
9. The I2 packet MUST have a single value in the HIP_CIPHER
parameter, which MUST match one of the values offered to the
Initiator in the R1 packet.
10. The system MUST derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the HOST_ID parameter. This
keying material is used to derive the keys of the Master Key SA
as described in Section 6.3. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped. If the
processing time for the derivation of the Diffie-Hellman keying
material Kij is likely to cause premature I2 retransmissions by
the Initiator, the system MAY send a NOTIFY packet before
starting the key derivation process. The NOTIFY packet contains
a NOTIFICATION parameter with Notify Message Type
I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the
anticipated remaining processing time for the I2 packet in
milliseconds as two-octet Notification Data.
11. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not be able to make this
verification.)
12. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
Other documents specifying transport formats (e.g., [RFC7402])
contain specifications for handling any specific transport
selected.
13. The system MUST verify the HIP_MAC according to the procedures
in Section 6.2.
14. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state.
15. The I2 packet may have the A-bit set - in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A-bit is set, the
Initiator's HIT is anonymous and should not be stored
permanently.
16. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial
input to the key derivation process for the Pair-wise Key SA
(see Section 6.3).
17. The system initializes the remaining variables in the associated
state, including Update ID counters.
Moskowitz & Hummen Expires July 21, 2016 [Page 36]
Internet-Draft HIP Diet EXchange (DEX) January 2016
18. Upon successful processing of an I2 packet when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or
R2-SENT, an R2 packet is sent as described in Section 5.3.4 and
the system's state machine transitions to state R2-SENT.
19. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent as
described in Section 5.3.4, and the system's state machine
transitions to R2-SENT.
20. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP
association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for a
maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED.
Note that steps 11 (encrypted HOST_ID) and 15 (signature
verification) from the original processing rules of HIPv2 have been
removed in the above processing rules for HIP DEX. Moreover, step 10
of the HIPv2 processing rules has been adapted to account for
optional extension of the retransmission mechanism. Step 16 has been
added to the processing rules. The considerations about malformed I2
packets in Sections 6.9.1 of [RFC7401] also apply to HIP DEX.
6.8. Processing Incoming R2 Packets
R2 packets in HIP DEX are handled identically to HIPv2 (see
Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX
introduces a new session key exchange via the ENCRYPTED_KEY parameter
and does not employ signatures.
The modified conceptual processing rules for responding to an R2
packet are as follows:
1. If the system is in any other state than I2-SENT, the R2 packet
is silently dropped.
2. The system MUST verify that the HITs in use correspond to the
HITs that were received in the R1 packet that caused the
transition to the I2-SENT state.
3. The system MUST verify the HIP_MAC according to the procedures in
Section 6.2.
Moskowitz & Hummen Expires July 21, 2016 [Page 37]
Internet-Draft HIP Diet EXchange (DEX) January 2016
4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER,
HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2
packet and compare the results against the chosen suites.
5. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy.
6. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial input
to the key derivation process for the Pair-wise Key SA (see
Section 6.3).
7. Upon successful processing of the R2 packet, the state machine
transitions to state ESTABLISHED.
Note that step 4 (signature verification) from the original
processing rules of HIPv2 has been replaced with a negotiation re-
evaluation in the above processing rules for HIP DEX. Moreover, step
6 has been added to the processing rules.
6.9. Processing Incoming NOTIFY Packets
Processing of NOTIFY packets is OPTIONAL. If processed, any errors
in a received NOTIFICATION parameter SHOULD be logged. Received
errors MUST be considered only as informational, and the receiver
SHOULD NOT change its HIP state purely based on the received NOTIFY
packet.
If a NOTIFY packet is received in state I2-SENT, this packet may be
an I2 reception acknowledgement of the optional retransmission
mechanism extension and SHOULD be processed. The following steps
define the conceptual processing rules for such incoming NOTIFY
packets in state I2-SENT:
1. The system MUST verify that the HITs in use correspond to the
HITs that were received in the R1 packet that caused the
transition to the I2-SENT state. If this check fails, the NOTIFY
packet SHOULD be dropped silently.
2. If the NOTIFY packet contains a NOTIFICATION parameter with
Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the
I2 retransmission timer to the I2 processing time indicated in
the NOTIFICATION parameter plus half the RTT-based timeout value.
The system MUST NOT set the retransmission timeout to a higher
value than allowed by a local policy. Moreover, the system
SHOULD reset the I2 retransmission timer to the RTT-based timeout
value after the next I2 retransmission.
Moskowitz & Hummen Expires July 21, 2016 [Page 38]
Internet-Draft HIP Diet EXchange (DEX) January 2016
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets
UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX
as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]).
The only difference is the that the HIP_SIGNATURE is never present
and, therefore, is not required to be processed by the receiving
party.
6.11. Handling State Loss
Implementors MAY choose to use non-volatile, secure storage for HIP
states in order for them to survive a system reboot. If no secure
storage capabilities are available, the system SHOULD delete the
corresponding HIP state, including the keying material. If the
implementation does drop the state (as RECOMMENDED), it MUST also
drop the peer's R1 generation counter value, unless a local policy
explicitly defines that the value of that particular host is stored.
An implementation MUST NOT store a peer's R1 generation counters by
default, but storing R1 generation counter values, if done, MUST be
configured by explicit HITs.
7. HIP Policies
There are a number of variables that will influence the HIP exchanges
that each host must support. All HIP DEX implementations SHOULD
provide for an ACL of Initiator's HI to Responder's HI. This ACL
SHOULD also include preferred transform and local lifetimes.
Wildcards SHOULD also be supported for this ACL.
The value of #K used in the HIP R1 must be chosen with care. Values
of #K that are too high will exclude clients with weak CPUs because
these devices cannot solve the puzzle within a reasonable amount of
time. #K should only be raised if a Responder is under high load,
i.e., it cannot process all incoming HIP handshakes any more. If a
Responder is not under high load, #K SHOULD be 0.
8. Security Considerations
HIP DEX closely resembles HIPv2. As such, the security
considerations discussed in Section 8 of [RFC7401] similarly apply to
HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated
Diffie-Hellman key exchange of HIPv2 with an exchange of random
keying material that is encrypted by a Diffie-Hellman derived key.
Both the Initiator and Responder contribute to this keying material.
As a result, the following additional security considerations apply
to HIP DEX:
Moskowitz & Hummen Expires July 21, 2016 [Page 39]
Internet-Draft HIP Diet EXchange (DEX) January 2016
o The strength of the keys for the Pair-wise Key SA is based on the
quality of the random keying material generated by the Initiator
and the Responder. Since the Initiator is expected to be a sensor
or an actuator device, there is a natural concern about the
quality of its random number generator.
o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2.
Consequently, if an HI is compromised, all HIP connections
protected with that HI are compromised.
o The puzzle mechanism using CMAC may need further study regarding
the level of difficulty.
o The HIP DEX HIT generation may present new attack opportunities.
o The R1 packet is unauthenticated and offers an adversary a new
attack vector against the Initiator. This is mitigated by only
processing a received R1 packet when the Initiator has previously
sent a corresponding I1 packet. Moreover, the Responder repeats
the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and
TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to
enable the Initiator to verify that these parameters have not been
modified by an attacker in the unprotected R1 packet.
The optional retransmission extension of HIP DEX is based on a NOTIFY
packet that the Responder can use to inform the Initiator about the
reception of an I2 packet. The Responder, however, cannot protect
the authenticity of this packet as it did not yet set up the Master
Key SA. Hence, an eavesdropping adversary may send spoofed reception
acknowledgements for an overheard I2 packet and signal an arbitrary
I2 processing time to the Initiator. The adversary can, e.g.,
indicate a lower I2 processing time than actually required by the
Responder in order to cause premature retransmissions. To protect
against this attack, the Initiator SHOULD set the NOTIFY-based
timeout value to the maximum indicated packet processing time in case
of conflicting NOTIFY packets. This allows the legitimate Responder
to extend the retransmission timeout to the intended length. The
adversary, however, can still arbitrarily delay the protocol
handshake beyond the Responder's actual I2 processing time. To limit
the extend of such a maliciously induced handshake delay, this
specification additionally requires the Initiator not to set the
NOTIFY-based timeout value higher than allowed by a local policy.
9. IANA Considerations
The following changes to the "Host Identity Protocol (HIP)
Parameters" registries have been made:
Moskowitz & Hummen Expires July 21, 2016 [Page 40]
Internet-Draft HIP Diet EXchange (DEX) January 2016
HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD"
(see Section 5.2.4).
Parameter Type This document defines the new HIP parameter
"ENCRYPTED_KEY" with type number 643 (see Section 5.2.5).
HIP Cipher ID This document defines the new HIP Cipher ID "AES-
128-CTR" (see Section 5.2.2).
HI Algorithm This document defines the new HI Algorithm "ECDH" (see
Section 5.2.3).
ECC Curve Label This document specifies a new algorithm-specific
subregistry named "ECDH Curve Label". The values for this
subregistry are defined in Section 5.2.1.
10. Acknowledgments
The drive to put HIP on a cryptographic 'Diet' came out of a number
of discussions with sensor vendors at IEEE 802.15 meetings. David
McGrew was very helpful in crafting this document.
11. Changelog
This section summarizes the changes made from draft-moskowitz-hip-rg-
dex-05, which was the first stable version of the draft. Note that
the draft was renamed after draft-moskowitz-hip-rg-dex-06.
11.1. Changes in draft-moskowitz-hip-rg-dex-06
o A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC.
11.2. Changes in draft-moskowitz-hip-dex-00
o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual
submission.
o Added the change section.
o Added a Definitions section.
o Changed I2 and R2 packets to reflect use of AES-CTR for
ENCRYPTED_KEY parameter.
o Cleaned up KEYMAT Generation text.
Moskowitz & Hummen Expires July 21, 2016 [Page 41]
Internet-Draft HIP Diet EXchange (DEX) January 2016
o Added Appendix with C code for the ECDH shared secret generation
on an 8 bit processor.
11.3. Changes in draft-moskowitz-hip-dex-01
o Numerous editorial changes.
o New retransmission strategy.
o New HIT generation mechanism.
o Modified layout of ENCRYPTED_KEY parameter.
o Clarify to use puzzle difficulty of zero under normal network
conditions.
o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to
MUST).
o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1
and I2).
o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be
echoed in R2 packet.
o Added new author.
11.4. Changes in draft-moskowitz-hip-dex-02
o Introduced formal definition of FOLD function.
o Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle".
o Several editorial changes.
11.5. Changes in draft-moskowitz-hip-dex-03
o Addressed HI crypto agility.
o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
o Extended the IV in the ENCRYPTED_KEY parameter.
o Introduced forward-references to HIP DEX KEYMAT process and
improved KEYMAT section.
Moskowitz & Hummen Expires July 21, 2016 [Page 42]
Internet-Draft HIP Diet EXchange (DEX) January 2016
o Replaced Appendix A on "C code for ECC point multiplication" with
short discussion in introduction.
o Updated references.
o Further editorial changes.
11.6. Changes in draft-moskowitz-hip-dex-04
o Improved retransmission extension.
o Updated and strongly revised packet processing rules.
o Updated security considerations.
o Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11.
o Many editorial changes.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, September 2014.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", RFC 7401,
April 2015.
Moskowitz & Hummen Expires July 21, 2016 [Page 43]
Internet-Draft HIP Diet EXchange (DEX) January 2016
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, April 2015.
12.2. Informative References
[DH76] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory
vol. IT-22, number 6, pages 644-654, Nov 1976.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Wehrle, "Tailoring End-to-End IP Security Protocols to the
Internet of Things", in Proceedings of IEEE International
Conference on Network Protocols (ICNP 2013), October 2013.
[I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-13 (work in
progress), December 2015.
[IEEE.802-11.2007]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, June
2007, <http://standards.ieee.org/getieee802/
download/802.11-2007.pdf>.
[IEEE.802-15-4.2011]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September
2011, <http://standards.ieee.org/getieee802/
download/802.15.4-2011.pdf>.
[LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for
Elliptic Curve Cryptography in Wireless Sensor Networks",
in Proceedings of International Conference on Information
Processing in Sensor Networks (IPSN 2008), April 2008.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June
2010.
Moskowitz & Hummen Expires July 21, 2016 [Page 44]
Internet-Draft HIP Diet EXchange (DEX) January 2016
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
[SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC
2 , 2000, <http://www.secg.org/>.
Moskowitz & Hummen Expires July 21, 2016 [Page 45]
Internet-Draft HIP Diet EXchange (DEX) January 2016
Appendix A. Password-based two-factor authentication during the HIP DEX
handshake
HIP DEX allows to identify authorized connections based on a two-
factor authentication mechanism. With two-factor authentication,
devices that are authorized to communicate with each other are
required to be pre-provisioned with a shared (group) key. The
Initiator uses this pre-provisioned key to encrypt the
ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2,
the Responder verifies that its challenge in the
ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted
with the correct key. If verified successfully, the Responder
proceeds with the handshake. Otherwise, it silently drops the I2
packet.
Note that there is no explicit signaling in the HIP DEX handshake for
this behavior. Thus, knowledge of two-factor authentication must be
configured externally prior to the handshake.
Authors' Addresses
Robert Moskowitz (editor)
HTT Consulting
Oak Park, MI
USA
EMail: rgm@htt-consult.com
Rene Hummen
Chair of Communication and Distributed Systems, RWTH Aachen
Ahornstrasse 55
Aachen 52074
Germany
EMail: hummen@comsys.rwth-aachen.de
URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/
Moskowitz & Hummen Expires July 21, 2016 [Page 46]
