draft-ietf-hip-dex-02.txt   draft-ietf-hip-dex-03.txt 
HIP WG R. Moskowitz, Ed. HIP WG R. Moskowitz, Ed.
Internet-Draft HTT Consulting Internet-Draft HTT Consulting
Intended status: Standards Track R. Hummen Intended status: Standards Track R. Hummen
Expires: September 22, 2016 Hirschmann Automation and Control Expires: December 6, 2016 Hirschmann Automation and Control
March 21, 2016 June 4, 2016
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-02 draft-ietf-hip-dex-03
Abstract Abstract
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash cryptographic primitives by omitting public-key signatures and hash
functions. In doing so, the main goal is to still deliver similar functions. In doing so, the main goal is to still deliver similar
security properties to HIPv2. security properties to HIPv2.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on December 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 8 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 8
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 10 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 11 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 11
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 15 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 15
4.1.4. User Data Considerations . . . . . . . . . . . . . . 16 4.1.4. User Data Considerations . . . . . . . . . . . . . . 16
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 16 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 16 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 16
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 16 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 17 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 17
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 18 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 17 skipping to change at page 3, line 17
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 27 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 27
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 30 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 30
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 30 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 30
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 31 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 31
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 34 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 34
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 37 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 37
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 38 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 38
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 39 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 39
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 39 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 39
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 39 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8. Interoperability between HIP DEX and HIPv2 . . . . . . . 39
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 41 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.2. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 41 12.1. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 42
11.3. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 41 12.2. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 42
11.4. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 41 12.3. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 42
11.5. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 42 12.4. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 43
11.6. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 42 12.5. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 43
11.7. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 42 12.6. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 43
11.8. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 43 12.7. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 43
11.9. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 43 12.8. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.9. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . 43 12.10. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Password-based two-factor authentication during Appendix A. Password-based two-factor authentication during
the HIP DEX handshake . . . . . . . . . . . . . . . 47 the HIP DEX handshake . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity
Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol
semantics as well as the general packet structure of HIPv2. Hence, semantics as well as the general packet structure of HIPv2. Hence,
it is recommended that [RFC7401] is well-understood before reading it is recommended that [RFC7401] is well-understood before reading
this document. this document.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
completes this exchange in the 3rd packet before the Responder completes this exchange in the 3rd packet before the Responder
performs computationally expensive operations or stores any state performs computationally expensive operations or stores any state
from the exchange. Given this handshake structure, HIP DEX from the exchange. Given this handshake structure, HIP DEX
operationally is very similar to HIP BEX. Moreover, the employed operationally is very similar to HIP BEX. Moreover, the employed
model is also fairly equivalent to 802.11-2007 [IEEE.802-11.2007] 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 Master Key and Pair-wise Transient Key, but handled in a single
exchange. exchange.
HIP DEX does not have the option to encrypt the Host Identity of the 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 Initiator in the 3rd packet. The Responder's Host Identity also is
not protected. Thus, contrary to HIPv2, there is no attempt at not protected. Thus, contrary to HIPv2, HIP DEX does not provide for
anonymity. end-point anonymity and any signaling that indicates such anonymity
should be ignored.
Data packets start to flow after the 4th packet. The 3rd and 4th HIP As in [RFC7401], data packets start to flow after the 4th packet.
packets may carry data payload in the future. However, the details The 3rd and 4th HIP packets may carry data payload in the future.
of this may be defined later. However, the details of this may be defined later.
An existing HIP association can be updated with the update mechanism An existing HIP association can be updated with the update mechanism
defined in [RFC7401]. Likewise, the association can be torn down defined in [RFC7401]. Likewise, the association can be torn down
with the defined closing mechanism for HIPv2 if it is no longer with the defined closing mechanism for HIPv2 if it is no longer
needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of
original HIPv2 specification. the original HIPv2 specification.
Finally, HIP DEX is designed as an end-to-end authentication and key Finally, HIP DEX is designed as an end-to-end authentication and key
establishment protocol. As such, it can be used in combination with establishment protocol. As such, it can be used in combination with
Encapsulated Security Payload (ESP) [RFC7402] as well as with other Encapsulated Security Payload (ESP) [RFC7402] as well as with other
end-to-end security protocols. In addition, HIP DEX can also be used 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., 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 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 mentioning that the HIP DEX base protocol does not cover all the
fine-grained policy control found in Internet Key Exchange Version 2 fine-grained policy control found in Internet Key Exchange Version 2
(IKEv2) [RFC5996] that allows IKEv2 to support complex gateway (IKEv2) [RFC5996] that allows IKEv2 to support complex gateway
policies. Thus, HIP DEX is not a replacement for IKEv2. policies. Thus, HIP DEX is not a replacement for IKEv2.
1.2. Memo Structure 1.2. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout this the central keywords, notation, and terms used throughout this
document. Section 3 defines the structure of the Host Identity and document. Section 3 defines the structure of the Host Identity and
its various representations. Section 4 gives an overview of the HIP its various representations. Section 4 gives an overview of the HIP
Diet EXchange protocol. Sections 5 and 6 define the detailed packet Diet EXchange protocol. Sections 5 and 6 define the detailed packet
formats and rules for packet processing. Finally, Sections 7, 8, and formats and rules for packet processing. Finally, Sections 7, 9, and
9 discuss policy, security, and IANA considerations, respectively. 10 discuss policy, security, and IANA considerations, respectively.
2. Terms and Definitions 2. Terms and Definitions
2.1. Requirements Terminology 2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Notation 2.2. Notation
skipping to change at page 7, line 21 skipping to change at page 7, line 21
Initiator: The host that initiates the HIP DEX handshake. This role Initiator: The host that initiates the HIP DEX handshake. This role
is typically forgotten once the handshake is completed. is typically forgotten once the handshake is completed.
Responder: The host that responds to the Initiator in the HIP DEX Responder: The host that responds to the Initiator in the HIP DEX
handshake. This role is typically forgotten once the handshake is handshake. This role is typically forgotten once the handshake is
completed. completed.
Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message redefined as CMAC. Still, note that CMAC is a message
authentication code and not a cryptographic hash function. Thus, authentication code (MAC) and not a cryptographic hash function.
a mapping from CMAC(x,y) to RHASH(z) must be defined where RHASH Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where
is used. Moreover, RHASH has different security properties in HIP RHASH is used. Moreover, RHASH has different security properties
DEX and is not used for HIT generation. in HIP DEX and is not used for HIT generation.
Length of the Responder's HIT Hash Algorithm (RHASH_len): The Length of the Responder's HIT Hash Algorithm (RHASH_len): The
natural output length of RHASH in bits. natural output length of RHASH in bits.
CMAC: The Cipher-based Message Authentication Code with the 128-bit
Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].
CKDF: CMAC-based Key Derivation Function. CKDF: CMAC-based Key Derivation Function.
3. Host Identity (HI) and its Structure 3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. 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 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 Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
skipping to change at page 8, line 48 skipping to change at page 8, line 50
the compressed representation of the HI. Third, a 96-bit hashed the compressed representation of the HI. Third, a 96-bit hashed
representation of the HI. In contrast to HIPv2, HIP DEX employs HITs representation of the HI. In contrast to HIPv2, HIP DEX employs HITs
that are NOT generated by means of a cryptographic hash. Instead, that are NOT generated by means of a cryptographic hash. Instead,
the HI is compressed to 96 bits as defined in the following section. the HI is compressed to 96 bits as defined in the following section.
3.2. Generating a HIT from an HI 3.2. Generating a HIT from an HI
The HIT does not follow the exact semantics of an ORCHID as there is 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 no hash function in HIP DEX. Still, its structure is strongly
aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 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 is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used
for the four bits of the Orchid Generation Algorithm (OGA) field in for the four bits of the Orchid Generation Algorithm (OGA) field in
the ORCHID. The hash representation in an ORCHID is replaced with the ORCHID. The hash representation in an ORCHID is replaced with
FOLD(HI,96). FOLD(HI,96).
4. Protocol Overview 4. Protocol Overview
This section gives a simplified overview of the HIP DEX protocol This section gives a simplified overview of the HIP DEX protocol
operation and does not contain all the details of the packet formats operation and does not contain all the details of the packet formats
or the packet processing steps. Section 5 and Section 6 describe or the packet processing steps. Section 5 and Section 6 describe
these aspects in more detail and are normative in case of any these aspects in more detail and are normative in case of any
skipping to change at page 10, line 7 skipping to change at page 10, line 10
the Initiator must solve before continuing the exchange. The level the Initiator must solve before continuing the exchange. The level
of difficulty of the puzzle can be adjusted based on level of trust of difficulty of the puzzle can be adjusted based on level of trust
with the Initiator, current load, or other factors. In addition, the with the Initiator, current load, or other factors. In addition, the
R1 contains the Responder's Diffie-Hellman parameter and lists of R1 contains the Responder's Diffie-Hellman parameter and lists of
cryptographic algorithms supported by the Responder. Based on these cryptographic algorithms supported by the Responder. Based on these
lists, the Initiator can continue, abort, or restart the handshake lists, the Initiator can continue, abort, or restart the handshake
with a different selection of cryptographic algorithms. with a different selection of cryptographic algorithms.
In the I2 packet, the Initiator MUST display the solution to the In the I2 packet, the Initiator MUST display the solution to the
received puzzle. Without a correct solution, the I2 packet is received puzzle. Without a correct solution, the I2 packet is
discarded. The I2 also contains a key wrap parameter that carries a discarded. The I2 also contains a key wrap parameter that carries
secret keying material of the Initiator. This keying material is secret keying material of the Initiator. This keying material is
only half the final session key. The packet is authenticated by the only half of the final session key. The packet is authenticated by
sender (Initiator) via a MAC. the sender (Initiator) via a MAC.
The R2 packet acknowledges the receipt of the I2 packet and completes The R2 packet acknowledges the receipt of the I2 packet and completes
the handshake. The R2 contains a key wrap parameter that carries the the handshake. The R2 contains a key wrap parameter that carries the
rest of the keying material of the Responder. The packet is rest of the keying material of the Responder. The packet is
authenticated by the sender (Responder) via a MAC. authenticated by the sender (Responder) via a MAC.
The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 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 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 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 and y each constitute half the final session key material. The
skipping to change at page 11, line 24 skipping to change at page 11, line 31
targeted DoS attacks. Under normal network conditions, the puzzle targeted DoS attacks. Under normal network conditions, the puzzle
difficulty SHOULD be zero, thus effectively reverting the puzzle difficulty SHOULD be zero, thus effectively reverting the puzzle
mechanism to a cookie-based DoS protection mechanism. Without mechanism to a cookie-based DoS protection mechanism. Without
setting the puzzle difficulty to zero under normal network setting the puzzle difficulty to zero under normal network
conditions, potentially scarce computation resources at the Initiator conditions, potentially scarce computation resources at the Initiator
would be churned unnecessarily. would be churned unnecessarily.
Conceptually, the puzzle mechanism in HIP DEX is the same as in 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 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in
[RFC7401] for more detailed information about the employed mechanism. [RFC7401] for more detailed information about the employed mechanism.
Notably, the only difference between the puzzle mechanism in HIP DEX Notably, the only differences between the puzzle mechanism in HIP DEX
and HIPv2 is that HIP DEX uses CMAC instead of a hash function for and HIPv2 are that HIP DEX does not employ pre-computation of R1
solving and verifying a puzzle. The implications of this change on packets and uses CMAC instead of a hash function for solving and
the puzzle implementation are discussed in Section 6.1. verifying a puzzle. The implications of these changes on the puzzle
implementation are discussed in Section 6.1.
4.1.2. HIP State Machine 4.1.2. HIP State Machine
The HIP DEX state machine has the same states as the HIPv2 state The HIP DEX state machine has the same states as the HIPv2 state
machine (see 4.4. in [RFC7401]). However, HIP DEX features a machine (see 4.4. in [RFC7401]). However, HIP DEX features a
retransmission strategy with an optional reception acknowledgement retransmission strategy with an optional reception acknowledgement
for the I2 packet. The goal of this additional acknowledgement is to for the I2 packet. The goal of this additional acknowledgement is to
reduce premature I2 retransmissions in case of devices with low reduce premature I2 retransmissions in case of devices with low
computation resources [HWZ13]. As a result, there are minor changes computation resources [HWZ13]. As a result, there are minor changes
regarding the transitions in the HIP DEX state machine. The regarding the transitions in the HIP DEX state machine. The
skipping to change at page 12, line 31 skipping to change at page 12, line 38
was successfully verified and if the remaining I2 packet processing was successfully verified and if the remaining I2 packet processing
incurs a high processing delay. The Responder MAY therefore send a incurs a high processing delay. The Responder MAY therefore send a
NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator
before the Responder commences the ECDH operation. The NOTIFY packet before the Responder commences the ECDH operation. The NOTIFY packet
serves as an acknowledgement for the I2 packet and consists of a serves as an acknowledgement for the I2 packet and consists of a
NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT
(see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter
contains the anticipated remaining processing time for the I2 packet contains the anticipated remaining processing time for the I2 packet
in milliseconds as two-octet Notification Data. This processing time in milliseconds as two-octet Notification Data. This processing time
can, e.g., be estimated by measuring the computation time of the ECDH can, e.g., be estimated by measuring the computation time of the ECDH
key derivation operation at Responder boot-up. After the I2 key derivation operation during the Responder start-up procedure.
processing has finished, the Responder sends the regular R2 packet. After the I2 processing has finished, the Responder sends the regular
R2 packet.
When the Initiator receives the NOTIFY packet, it sets the I2 When the Initiator receives the NOTIFY packet, it sets the I2
retransmission timeout to the I2 processing time indicated in the retransmission timeout to the I2 processing time indicated in the
NOTIFICATION parameter plus half the RTT-based timeout value. In NOTIFICATION parameter plus half the RTT-based timeout value. In
doing so, the Initiator MUST NOT set the retransmission timeout to a doing so, the Initiator MUST NOT set the retransmission timeout to a
higher value than allowed by a local policy. This is to prevent higher value than allowed by a local policy. This is to prevent
unauthenticated NOTIFY packets from maliciously delaying the unauthenticated NOTIFY packets from maliciously delaying the
handshake beyond a well-defined upper bound in case of a lost R2 handshake beyond a well-defined upper bound in case of a lost R2
packet. At the same time, this extended retransmission timeout packet. At the same time, this extended retransmission timeout
enables the Initiator to defer I2 retransmissions until the point in enables the Initiator to defer I2 retransmissions until the point in
skipping to change at page 14, line 19 skipping to change at page 14, line 19
+----------------| UNASSOCIATED |----------------+ | +----------------| UNASSOCIATED |----------------+ |
datagram | +--+ +--------------+ | | datagram | +--+ +--------------+ | |
to send, | | | Alg. not supported, | | to send, | | | Alg. not supported, | |
send I1 | | | send I1 | | send I1 | | | send I1 | |
. v | v | | . v | v | |
. +---------+ recv I2, send R2 | | . +---------+ recv I2, send R2 | |
+---->| I1-SENT |--------------------------------------+ | | +---->| I1-SENT |--------------------------------------+ | |
| +---------+ +----------------------+ | | | | +---------+ +----------------------+ | | |
| | recv R1, | recv I2, send R2 | | | | | | recv R1, | recv I2, send R2 | | | |
| v send I2 | v v v | | v send I2 | v v v |
| +---------+ | +---------+ | | +---------+----------+ +---------+ |
| +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | | +--->| I2-SENT |<-------------+ +------------| R2-SENT |<---+ |
| | +---------+ | +---------+ | | | | +---------+ recv NOTIFY, | | +---------+ | |
| | | |recv R2 | data or| | | | | | | | reset timer | | data or| | |
| |recv R1, | | | EC timeout| | | | |recv R1, | | +--------------+ | EC timeout| | |
| |send I2 +--|-----------------+ | receive I2,| | | |send I2 +-|--------------------+ | receive I2,| |
| | | | +-------------+ | send R2| | | | | | +-------------+ | send R2| |
| | | +------>| ESTABLISHED |<----------+ | | | | | +-------->| ESTABLISHED |<---------+ | |
| | | +-------------+ | | | | | recv R2 +-------------+ | |
| | | | | | receive I2, send R2 | | | | | | | | receive I2, send R2 | |
| | +------------+ | +-------------------------------+ | | | +------------+ | +-------------------------------+ |
| | | +-----------+ | | | | | +-----------+ | |
| | | no packet sent/received| +---+ | | | | | no packet sent/received| +---+ | |
| | | for UAL min, send CLOSE| | |timeout | | | | | for UAL min, send CLOSE| | |timeout | |
| | | v v |(UAL+MSL) | | | | | v v |(UAL+MSL) | |
| | | +---------+ |retransmit | | | | | +---------+ |retransmit | |
+--|----------|------------------------| CLOSING |-+CLOSE | | +--|----------|------------------------| CLOSING |-+CLOSE | |
| | +---------+ | | | | +---------+ | |
| | | | | | | | | | | | | | | |
skipping to change at page 17, line 27 skipping to change at page 17, line 27
Group KDF Value Group KDF Value
NIST P-256 [RFC5903] CKDF 7 NIST P-256 [RFC5903] CKDF 7
NIST P-384 [RFC5903] CKDF 8 NIST P-384 [RFC5903] CKDF 8
NIST P-521 [RFC5903] CKDF 9 NIST P-521 [RFC5903] CKDF 9
SECP160R1 [SECG] CKDF 10 SECP160R1 [SECG] CKDF 10
Curve25519 [RFC7748] CKDF 11 Curve25519 [RFC7748] CKDF 11
Curve448 [RFC7748] CKDF 12 Curve448 [RFC7748] CKDF 12
The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH The ECDH groups with values 7 - 9 are defined in [RFC5903] and
group 10 is covered in [SECG] and Appendix D of [RFC7401]. These [RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of
curves, when used with HIP MUST have a co-factor of 1. [RFC7401]. These curves, when used with HIP MUST have a co-factor of
1.
The ECDH groups 11 and 12 are defined in [RFC7748]. These curves The ECDH groups with values 11 and 12 are defined in [RFC7748].
have cofactors of 8 and 4 (respectively). These curves have cofactors of 8 and 4 (respectively).
5.2.2. HIP_CIPHER 5.2.2. HIP_CIPHER
The HIP_CIPHER parameter contains the list of supported cipher The HIP_CIPHER parameter contains the list of supported cipher
algorithms to be used for encrypting the contents of the ENCRYPTED algorithms to be used for encrypting the contents of the ENCRYPTED
and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 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 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to: to:
Suite ID Value Suite ID Value
skipping to change at page 18, line 13 skipping to change at page 18, line 13
debugging of HIP. debugging of HIP.
5.2.3. HOST_ID 5.2.3. HOST_ID
The HOST_ID parameter conveys the Host Identity (HI) along with 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 optional information about a host. It is defined in Section 5.2.9 of
[RFC7401]. [RFC7401].
HIP DEX uses the public portion of a host's static ECDH key-pair as 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 the HI. Correspondingly, HIP DEX limits the HI algorithms to the
following profile: following new profile:
Algorithm profiles Value Algorithm profiles Value
ECDH 11 [RFC6090] (REQUIRED) ECDH 11 [RFC6090] (REQUIRED)
HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 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 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 encoded in the "ECC curve" field of the HOST_ID parameter. The
supported DH Group IDs are defined in Section 5.2.1. supported DH Group IDs are defined in Section 5.2.1.
5.2.4. HIT_SUITE_LIST 5.2.4. HIT_SUITE_LIST
The HIT_SUITE_LIST parameter contains a list of the supported HIT The HIT_SUITE_LIST parameter contains a list of the supported HIT
suite IDs of the Responder. Based on the HIT_SUITE_LIST, the suite IDs of the Responder. Based on the HIT_SUITE_LIST, the
Initiator can determine which source HIT Suite IDs are supported by Initiator can determine which source HIT Suite IDs are supported by
the Responder. The HIT_SUITE_LIST parameter is defined in the Responder. The HIT_SUITE_LIST parameter is defined in
Section 5.2.10 of [RFC7401]. Section 5.2.10 of [RFC7401].
The following HIT Suite IDs are defined for HIP DEX, and the The following new HIT Suite IDs are defined for HIP DEX, and the
relationship between the four-bit ID value used in the OGA ID field 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 and the eight-bit encoding within the HIT_SUITE_LIST ID field is
clarified: clarified:
HIT Suite Four-bit ID Eight-bit encoding HIT Suite Four-bit ID Eight-bit encoding
ECDH/FOLD 8 0x80 ECDH/FOLD 8 0x80
Note that the HIP DEX HIT Suite ID allows the peers to distinguish a Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field
HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond allows the peers to distinguish a HIP DEX handshake from a HIPv2
with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP handshake. The Responder MUST respond with a HIP DEX HIT suite ID
DEX HIT. when the HIT of the Initiator is a HIP DEX HIT.
5.2.5. ENCRYPTED_KEY 5.2.5. ENCRYPTED_KEY
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Encrypted value / / Encrypted value /
/ / / /
/ +-------------------------------+ / +-------------------------------+
skipping to change at page 19, line 26 skipping to change at page 19, line 26
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Encrypted The value is encrypted using an encryption algorithm Encrypted The value is encrypted using an encryption algorithm
value as defined in the HIP_CIPHER parameter. value as defined in the HIP_CIPHER parameter.
The ENCRYPTED_KEY parameter encapsulates a random value that is later The ENCRYPTED_KEY parameter encapsulates a random value that is later
used in the session key creation process (see Section 6.3). This 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 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 #I and the puzzle solution #J (see [RFC7401]) are used as the
initialization vector (IV) for the encryption process. To this end, 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 the IV is computed as FOLD(I | J, 128). Moreover, a 16 bit counter
bit value that is initialized to zero with the first use. value, which is initialized to zero on first use, is appended to the
IV value in order to guarantee that a non-repeating nonce is fed to
the encryption algorithm defined by the HIP_CIPHER.
Once this encryption process is completed, the "encrypted value" data Once this encryption process is completed, the "encrypted value" data
field is ready for inclusion in the Parameter. If necessary, field is ready for inclusion in the Parameter. If necessary,
additional Padding for 8-byte alignment is then added according to additional Padding for 8-byte alignment is then added according to
the rules of TLV Format in [RFC7401]. the rules of TLV Format in [RFC7401].
5.3. HIP Packets 5.3. HIP Packets
HIP DEX uses the same eight basic HIP packets as HIPv2 (see 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 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake
skipping to change at page 20, line 38 skipping to change at page 20, line 40
type as defined in Section 5.2.4. type as defined in Section 5.2.4.
Regarding the Responder's HIT, the Initiator may receive this HIT Regarding the Responder's HIT, the Initiator may receive this HIT
either from a DNS lookup of the Responder's FQDN, from some other 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 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 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 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 zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for
detailed information about the "HIP Opportunistic Mode". detailed information about the "HIP Opportunistic Mode".
As a compression of the employed HIs, the Initiator's and the As the Initiator's and the Responder's HITs are compressions of the
Responder's HITs both determine the DH group ID that must be used in employed HIs, they determine the DH Group ID that must be used in
order to successfully conclude the triggered handshake. HITs, order to successfully conclude the triggered handshake. HITs,
however, only include the OGA ID identifying a HIP DEX HIT. They do however, only include the OGA ID identifying the HI algorithm. They
not include information about the specific DH group ID of the do not include information about the specific group ID of the HI. To
corresponding HI. To inform the Responder about its employed and its inform the Responder about its employed and its otherwise supported
otherwise supported DH Group IDs, the Initiator therefore includes DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST
the DH_GROUP_LIST parameter in the I1 packet. This parameter MUST parameter in the I1 packet. This parameter MUST include the DH group
include the DH group ID that corresponds to the currently employed ID that corresponds to the currently employed Initiator HIT as the
Initiator HIT as the first list element. With HIP DEX, the first list element. With HIP DEX, the DH_GROUP_LIST parameter MUST
DH_GROUP_LIST parameter MUST only include ECDH groups defined in only include ECDH groups defined in Section 5.2.1.
Section 5.2.1.
Since this packet is so easy to spoof even if it were protected, no 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 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. result, the DH_GROUP_LIST in the I1 packet is not protected.
Implementations MUST be able to handle a storm of received I1 Implementations MUST be able to handle a storm of received I1
packets, discarding those with common content that arrive within a packets, discarding those with common content that arrive within a
small time delta. small time delta.
5.3.2. R1 - the HIP Responder Packet 5.3.2. R1 - the HIP Responder Packet
skipping to change at page 22, line 37 skipping to change at page 22, line 37
Initiator MAY decide to abort the current handshake and initiate a Initiator MAY decide to abort the current handshake and initiate a
new handshake with a different mutually supported HIT suite. This new handshake with a different mutually supported HIT suite. This
mechanism can, e.g., be used to move from an initial HIP DEX mechanism can, e.g., be used to move from an initial HIP DEX
handshake to a HIP BEX handshake for peers supporting both protocol handshake to a HIP BEX handshake for peers supporting both protocol
variants. variants.
The HOST_ID parameter depends on the received DH_GROUP_LIST parameter The HOST_ID parameter depends on the received DH_GROUP_LIST parameter
and the Responder HIT in the I1 packet. Specifically, if the I1 and the Responder HIT in the I1 packet. Specifically, if the I1
contains a Responder HIT, the Responder verifies that this HIT contains a Responder HIT, the Responder verifies that this HIT
matches the required DH group based on the received DH_GROUP_LIST matches the required DH group based on the received DH_GROUP_LIST
parameter. In case of a positive result, the Responder selects the parameter included in the I1. In case of a positive result, the
corresponding HOST_ID for inclusion in the R1 packet. Likewise, if Responder selects the corresponding HOST_ID for inclusion in the R1
the Responder HIT in the I1 packet is NULL (i.e., during an packet. Likewise, if the Responder HIT in the I1 packet is NULL
opportunistic handshake), the Responder chooses its HOST_ID according (i.e., during an opportunistic handshake), the Responder chooses its
to the Initiator's employed DH group as indicated in the received HOST_ID according to the Initiator's employed DH group as indicated
DH_GROUP_LIST parameter and sets the source HIT in the R1 packet in the received DH_GROUP_LIST parameter and sets the source HIT in
accordingly. If the Responder however does not support the DH group the R1 packet accordingly. If the Responder however does not support
required by the Initiator or if the Responder HIT in the I1 packet the DH group required by the Initiator or if the Responder HIT in the
does not match the required DH group, the Responder selects the I1 packet does not match the required DH group, the Responder selects
mutually preferred and supported DH group based on the DH_GROUP_LIST the mutually preferred and supported DH group based on the
parameter in the I1 packet. The Responder then includes the DH_GROUP_LIST parameter in the I1 packet. The Responder then
corresponding ECDH key in the HOST_ID parameter. This parameter also includes the corresponding ECDH key in the HOST_ID parameter. This
indicates the selected DH group. Moreover, the Responder sets the parameter also indicates the selected DH group. Moreover, the
source HIT in the R2 packet based on the destination HIT from the I1 Responder sets the source HIT in the R2 packet based on the
packet. Based on the deviating DH group ID in the HOST_ID parameter, destination HIT from the I1 packet. Based on the deviating DH group
the Initiator then SHOULD abort the current handshake and initiate a ID in the HOST_ID parameter, the Initiator then SHOULD abort the
new handshake with the mutually supported DH group as far as local current handshake and initiate a new handshake with the mutually
policies (see Section 7) permit. supported DH group as far as local policies (see Section 7) permit.
The TRANSPORT_FORMAT_LIST parameter is an ordered list of the The TRANSPORT_FORMAT_LIST parameter is an ordered list of the
Responder's supported and preferred transport format types. The list Responder's supported and preferred transport format types. The list
allows the Initiator and the Responder to agree on a common type for allows the Initiator and the Responder to agree on a common type for
payload protection. Currently, the only transport format defined is payload protection. Currently, the only transport format defined is
IPsec ESP [RFC7402]. IPsec ESP [RFC7402].
The ECHO_REQUEST_UNSIGNED parameters contain data that the sender The ECHO_REQUEST_UNSIGNED parameters contain data that the sender
wants to receive unmodified in the corresponding response packet in wants to receive unmodified in the corresponding response packet in
the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero
skipping to change at page 25, line 51 skipping to change at page 25, line 51
The processing of outgoing and incoming application data remains the The processing of outgoing and incoming application data remains the
same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]).
6.1. Solving the Puzzle 6.1. Solving the Puzzle
The procedures for solving and verifying a puzzle in HIP DEX are The procedures for solving and verifying a puzzle in HIP DEX are
strongly based on the corresponding procedures in HIPv2. The only strongly based on the corresponding procedures in HIPv2. The only
exceptions are that HIP DEX does not use pre-computation of R1 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- 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 computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX.
DEX.
Moreover, the Initiator solves a puzzle by computing: Moreover, the Initiator solves a puzzle by computing:
Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0
Similarly, the Responder verifies a puzzle by computing: Similarly, the Responder verifies a puzzle by computing:
V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K )
Apart from these modifications, the procedures defined in Section 6.3 Apart from these modifications, the procedures defined in Section 6.3
of [RFC7401] also apply for HIP DEX. of [RFC7401] also apply for HIP DEX.
skipping to change at page 27, line 32 skipping to change at page 27, line 32
defined in Section 6.3 and verify it against the received CMAC. defined in Section 6.3 and verify it against the received CMAC.
5. Set Checksum and Header Length fields in the HIP header to 5. Set Checksum and Header Length fields in the HIP header to
original values. Note that the Checksum and Length fields original values. Note that the Checksum and Length fields
contain incorrect values after this step. contain incorrect values after this step.
6.3. HIP DEX KEYMAT Generation 6.3. HIP DEX KEYMAT Generation
The HIP DEX KEYMAT process is used to derive the keys for the Master 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 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 Key SA are based on the Diffie-Hellman derived key, Kij, which is
during the HIP DEX handshake. The Initiator generates Kij during the produced during the HIP DEX handshake. The Initiator generates Kij
creation of the I2 packet and the Responder generates Kij once it during the creation of the I2 packet and the Responder generates Kij
receives the I2 packet. Hence, I2, R2, UPDATE, CLOSE, and CLOSE_ACK once it receives the I2 packet. This is why the I2 packet can
packets can contain authenticated and/or encrypted information. already contain authenticated and/or encrypted information.
The keys of the Pair-wise Key SA are not directly used in the HIP DEX The keys derived for the Pair-wise Key SA are not used during the HIP
handshake. Instead, these keys are made available as payload DEX handshake. Instead, these keys are made available as payload
protection keys. Some payload protection mechanisms have their own protection keys (e.g., for IPsec). Some payload protection
Key Derivation Function, and if so this mechanism SHOULD be used. mechanisms have their own Key Derivation Function, and if so this
Otherwise, the HIP DEX KEYMAT process MUST be used to derive the keys mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST
of the Pair-wise Key SA based on the concatenation of the random be used to derive the keys of the Pair-wise Key SA based on the
values that are contained in the exchanged ENCRYPTED_KEY parameters. 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 The HIP DEX KEYMAT process is based on the is the Hash-based Key
and CKDF-Expand. The Extract function compresses a non-uniformly Derivation Function (HKDF) defined in [RFC5869] and consists of two
distributed key, as is the output of a Diffie-Hellman key derivation, components, CKDF-Extract and CKDF-Expand. The CKDF-Extract function
to extract the key entropy into a fixed length output. The Expand compresses a non-uniformly distributed key, such as the output of a
function takes either the output of the Extract function or directly Diffie-Hellman key derivation, to extract the key entropy into a
uses a uniformly distributed key and expands the length of the key, fixed length output. The CKDF-Expand function takes either the
repeatedly distributing the key entropy, to produce the keys needed. 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.
The key derivation for the Master Key SA employs both the Extract and The key derivation for the Master Key SA employs always both the
Expand phases, whereas the Pair-wise Key SA MAY need both the Extract Extract and Expand phases. The Pair-wise Key SA needs only the
and Expand phases if the key is longer than 128 bits. Otherwise, it Extract phase when key is smaller or equal to 128 bits, but otherwise
only requires the Expand phase. requires also the Expand phase.
The CKDF-Extract function is the following operation: The CKDF-Extract function is the following operation:
CKDF-Extract(I, IKM, info) -> PRK CKDF-Extract(I, IKM, info) -> PRK
where Inputs:
I Random #I from the PUZZLE parameter
IKM Input keying material, i.e., the Diffie-Hellman derived
key for the Master Key SA and the concatenation of the
random values of the ENCRYPTED_KEY parameters in the
same order as the HITs with sort(HIT-I | HIT-R) for the
Pair-wise Key SA
info sort(HIT-I | HIT-R) | "CKDF-Extract"
where "CKDF-Extract" is an octet string
I Random #I from the PUZZLE parameter Output:
IKM Input keying material, i.e., either the Diffie-Hellman PRK a pseudorandom key (of RHASH_len/8 octets)
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: The pseudorandom key PRK is calculated as follows:
PRK = CMAC(I, IKM | info) PRK = CMAC(I, IKM | info)
The CKDF-Expand function is the following operation: The CKDF-Expand function is the following operation:
CKDF-Expand(PRK, info, L) -> OKM CKDF-Expand(PRK, info, L) -> OKM
where Inputs:
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) in case of no extract)
info sort(HIT-I | HIT-R) | "CKDF-Expand"
where "CKDF-Expand" is an octet string
L length of output keying material in octets
(<= 255*RHASH_len/8)
PRK a pseudorandom key of at least RHASH_len/8 octets Output:
(either the output from the extract step or the OKM output keying material (of L octets)
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: The output keying material OKM is calculated as follows:
N = ceil(L/RHASH_len/8) N = ceil(L/RHASH_len/8)
T = T(1) | T(2) | T(3) | ... | T(N) T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T OKM = first L octets of T
where where
T(0) = empty string (zero length) T(0) = empty string (zero length)
skipping to change at page 29, line 42 skipping to change at page 29, line 44
(where the constant concatenated to the end of each T(n) is a (where the constant concatenated to the end of each T(n) is a
single octet.) single octet.)
sort(HIT-I | HIT-R) is defined as the network byte order sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte interpreted as positive (unsigned) 128-bit integers in network byte
order. order.
The initial keys are drawn sequentially in the order that is The initial keys for the Master Key SA are drawn sequentially in the
determined by the numeric comparison of the two HITs, with the order that is determined by the numeric comparison of the two HITs,
comparison method described in the previous paragraph. HOST_g with the comparison method described in the previous paragraph.
denotes the host with the greater HIT value, and HOST_l the host with HOST_g denotes the host with the greater HIT value, and HOST_l the
the lower HIT value. host with the lower HIT value.
The drawing order for initial keys: The drawing order for initial keys:
1. HIP-gl encryption key for HOST_g's outgoing HIP packets 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 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets
3. HIP-lg encryption key for HOST_l's outgoing HIP packets 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 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 The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes of the keys regarding the algorithm defined in the HIP_CIPHER. For
apply: the mandatory algorithms, the following size applies:
AES 128 or 256 bits AES 128 bits
If other key sizes are used, they must be treated as different If other key sizes are used, they must be treated as different
encryption algorithms and defined separately. encryption algorithms and defined separately.
6.4. Initiation of a HIP Diet EXchange 6.4. Initiation of a HIP Diet EXchange
The initiation of a HIP DEX handshake proceeds as described in The initiation of a HIP DEX handshake proceeds as described in
Section 6.6 of [RFC7401]. The I1 packet contents are specified in Section 6.6 of [RFC7401]. The I1 packet contents are specified in
Section 5.3.1. Section 5.3.1.
skipping to change at page 31, line 21 skipping to change at page 31, line 22
does not support the DH group required by the Initiator or if the 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 destination HIT in the I1 packet does not match the required DH
group, it selects the mutually preferred and supported DH group group, it selects the mutually preferred and supported DH group
based on the DH_GROUP_LIST parameter in the I1 packet. The based on the DH_GROUP_LIST parameter in the I1 packet. The
implementation includes the corresponding ECDH public key in the implementation includes the corresponding ECDH public key in the
HOST_ID parameter. If no suitable DH Group ID was contained in 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 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with
any suitable ECDH public key. any suitable ECDH public key.
5. If the received Responder's HIT in the I1 packet is not NULL, the 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 Responder's HIT in the R1 packet MUST match the destination HIT
in the I1 packet. Otherwise, the Responder MUST select a 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 with the same HIT Suite as the Initiator's HIT. If this HIT
Suite is not supported by the Responder, it SHOULD select a Suite is not supported by the Responder, it SHOULD select a
REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is
currently RSA/DSA/SHA-256. Other than that, selecting the HIT is currently RSA/DSA/SHA-256. Other than that, selecting the HIT is
a local policy matter. a local policy matter.
6. The Responder expresses its supported HIP transport formats in 6. The Responder expresses its supported HIP transport formats in
the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of
[RFC7401]. The Responder MUST provide at least one payload [RFC7401]. The Responder MUST provide at least one payload
skipping to change at page 32, line 11 skipping to change at page 32, line 11
The modified conceptual processing rules for responding to an R1 The modified conceptual processing rules for responding to an R1
packet are as follows: packet are as follows:
1. A system receiving an R1 MUST first check to see if it has sent 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 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 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 with the HITs in the R1). Unless the I1 packet was sent in
opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP
addresses in the received R1 packet SHOULD be ignored by the R1 addresses in the received R1 packet SHOULD be ignored by the R1
processing and, when looking up the right HIP association, the processing and, when looking up the correct HIP association, the
received R1 packet SHOULD be matched against the associations received R1 packet SHOULD be matched against the associations
using only the HITs. If a match exists, the system should using only the HITs. If a match exists, the system should
process the R1 packet as described below. process the R1 packet as described below.
2. Otherwise, if the system is in any state other than I1-SENT or 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 I2-SENT with respect to the HITs included in the R1 packet, it
SHOULD silently drop the R1 packet and remain in the current SHOULD silently drop the R1 packet and remain in the current
state. state.
3. If the HIP association state is I1-SENT or I2-SENT, the received 3. If the HIP association state is I1-SENT or I2-SENT, the received
skipping to change at page 34, line 27 skipping to change at page 34, line 27
trial counter associated with the I2 packet. The sender SHOULD trial counter associated with the I2 packet. The sender SHOULD
retransmit the I2 packet upon a timeout and restart the timer, retransmit the I2 packet upon a timeout and restart the timer,
up to a maximum of I2_RETRIES_MAX tries. up to a maximum of I2_RETRIES_MAX tries.
18. If the system is in state I1-SENT, it SHALL transition to state 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 I2-SENT. If the system is in any other state, it remains in the
current state. current state.
Note that step 4 from the original processing rules of HIPv2 Note that step 4 from the original processing rules of HIPv2
(signature verification) has been removed in the above processing (signature verification) has been removed in the above processing
rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules rules for HIP DEX. Moreover, step 7 of the original processing rules
has been adapted to account for the fact that HIP DEX uses ECDH has been adapted in step 6 avove to account for the fact that HIP DEX
public keys as HIs. The considerations about malformed R1 packets in uses ECDH public keys as HIs. The considerations about malformed R1
Sections 6.8.1 of [RFC7401] also apply to HIP DEX. packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX.
6.7. Processing Incoming I2 Packets 6.7. Processing Incoming I2 Packets
The processing of I2 packets follows similar rules as HIPv2 (see The processing of I2 packets follows similar rules as HIPv2 (see
Section 6.9 of [RFC7401]). The main differences to HIPv2 are that Section 6.9 of [RFC7401]). The main differences to HIPv2 are that
HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY
parameter as well as an I2 reception acknowledgement for parameter as well as an I2 reception acknowledgement for
retransmission purposes. Moreover, with HIP DEX the Initiator is retransmission purposes. Moreover, with HIP DEX the Initiator is
responsible for triggering retransmissions, whereas the Responder responsible for triggering retransmissions, whereas the Responder
merely replies to received I2 packets. merely replies to received I2 packets.
skipping to change at page 37, line 30 skipping to change at page 37, line 30
other packet that indicates that the peer system's state machine other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for a has moved to ESTABLISHED). If the timer expires (allowing for a
maximal amount of retransmissions of I2 packets), the state maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED. machine transitions to ESTABLISHED.
Note that steps 11 (encrypted HOST_ID) and 15 (signature Note that steps 11 (encrypted HOST_ID) and 15 (signature
verification) from the original processing rules of HIPv2 have been verification) from the original processing rules of HIPv2 have been
removed in the above processing rules for HIP DEX. Moreover, step 10 removed in the above processing rules for HIP DEX. Moreover, step 10
of the HIPv2 processing rules has been adapted to account for of the HIPv2 processing rules has been adapted to account for
optional extension of the retransmission mechanism. Step 16 has been optional extension of the retransmission mechanism. Step 16 has been
added to the processing rules. The considerations about malformed I2 added to the processing rules in this document. The considerations
packets in Sections 6.9.1 of [RFC7401] also apply to HIP DEX. about malformed I2 packets in Sections 6.9.1 of [RFC7401] also apply
to HIP DEX.
6.8. Processing Incoming R2 Packets 6.8. Processing Incoming R2 Packets
R2 packets in HIP DEX are handled identically to HIPv2 (see R2 packets in HIP DEX are handled identically to HIPv2 (see
Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX
introduces a new session key exchange via the ENCRYPTED_KEY parameter introduces a new session key exchange via the ENCRYPTED_KEY parameter
and does not employ signatures. and does not employ signatures.
The modified conceptual processing rules for responding to an R2 The modified conceptual processing rules for responding to an R2
packet are as follows: packet are as follows:
skipping to change at page 39, line 8 skipping to change at page 39, line 8
I2 retransmission timer to the I2 processing time indicated in I2 retransmission timer to the I2 processing time indicated in
the NOTIFICATION parameter plus half the RTT-based timeout value. the NOTIFICATION parameter plus half the RTT-based timeout value.
The system MUST NOT set the retransmission timeout to a higher The system MUST NOT set the retransmission timeout to a higher
value than allowed by a local policy. Moreover, the system value than allowed by a local policy. Moreover, the system
SHOULD reset the I2 retransmission timer to the RTT-based timeout SHOULD reset the I2 retransmission timer to the RTT-based timeout
value after the next I2 retransmission. value after the next I2 retransmission.
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets
UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 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]). as in HIPv2 (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 The only difference is the that the HIP_SIGNATURE is never present
and, therefore, is not required to be processed by the receiving and, therefore, is not required to be processed by the receiving
party. party.
6.11. Handling State Loss 6.11. Handling State Loss
Implementors MAY choose to use non-volatile, secure storage for HIP Implementors MAY choose to use non-volatile, secure storage for HIP
states in order for them to survive a system reboot. If no secure states in order for them to survive a system reboot. If no secure
storage capabilities are available, the system SHOULD delete the storage capabilities are available, the system SHOULD delete the
corresponding HIP state, including the keying material. If the corresponding HIP state, including the keying material. If the
implementation does drop the state (as RECOMMENDED), it MUST also implementation does drop the state (as RECOMMENDED), it MUST also
drop the peer's R1 generation counter value, unless a local policy drop the peer's R1 generation counter value, unless a local policy
explicitly defines that the value of that particular host is stored. explicitly defines that the value of that particular host is stored.
An implementation MUST NOT store a peer's R1 generation counters by Such storing of the R1 generation counter values MUST be configured
default, but storing R1 generation counter values, if done, MUST be by explicit HITs.
configured by explicit HITs.
7. HIP Policies 7. HIP Policies
There are a number of variables that will influence the HIP exchanges There are a number of variables that will influence the HIP exchanges
that each host must support. All HIP DEX implementations SHOULD that each host must support. The value of #K used in the HIP R1 must
provide for an ACL of Initiator's HI to Responder's HI. This ACL be chosen with care. Values of #K that are too high will exclude
SHOULD also include preferred transform and local lifetimes. clients with weak CPUs because these devices cannot solve the puzzle
Wildcards SHOULD also be supported for this ACL. 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.
The value of #K used in the HIP R1 must be chosen with care. Values All HIP DEX implementations SHOULD provide for an Access Control List
of #K that are too high will exclude clients with weak CPUs because (ACL), representing for which hosts they accept HIP diet exchanges,
these devices cannot solve the puzzle within a reasonable amount of and the preferred transport format and local lifetimes. Wildcarding
time. #K should only be raised if a Responder is under high load, SHOULD be supported for such ACLs.
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 8. Interoperability between HIP DEX and HIPv2
HIP DEX and HIPv2 both use the same protocol number and packet
formats. Hence, an implementation that either supports HIP DEX or
HIPv2 must be able to detect the dialect that the peer is speaking.
This section outlines how a HIP DEX implementation can achieve such
detection for the two relevant cases where:
1. the Initiator supports HIP DEX and the Responder supports HIP
BEX,
2. the Initiator supports HIP BEX and the Responder supports HIP
DEX.
In the first case, the HIP DEX implementation (Initiator) inspects
the Responder's HIT prior to sending the I1 packet. If the OGA ID
field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP
DEX implementation cancels the handshake. If the Responder is
unknown prior to sending the I1 packet (i.e., opportunistic mode),
the HIP DEX implementation performs the above check on reception of
the R1 packet and cancels the handshake in case of a negative result.
In both failure scenarios, the implementation should report an error
to the user via appropriate means.
In the second case, the HIP DEX implementation (Responder) inspects
the Initiator's HIT on reception of an I1 packet. If the OGA ID
field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP
DEX implementation cancels the handshake and sends an ICMP packet
with type Parameter Problem, with the Pointer pointing to the source
HIT, to the Initiator.
Note that an implementation may also support both HIP DEX and HIPv2.
It then uses the above procedure to determine the protocol variant
that is supported by its handshake peer and performs the
corresponding handshake.
9. Security Considerations
HIP DEX closely resembles HIPv2. As such, the security HIP DEX closely resembles HIPv2. As such, the security
considerations discussed in Section 8 of [RFC7401] similarly apply to considerations discussed in Section 8 of [RFC7401] similarly apply to
HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated
Diffie-Hellman key exchange of HIPv2 with an exchange of random Diffie-Hellman key exchange of HIPv2 with an exchange of random
keying material that is encrypted by a Diffie-Hellman derived key. keying material that is encrypted with a Diffie-Hellman derived key.
Both the Initiator and Responder contribute to this keying material. Both the Initiator and Responder contribute to this keying material.
As a result, the following additional security considerations apply As a result, the following additional security considerations apply
to HIP DEX: to HIP DEX:
o The strength of the keys for the Pair-wise Key SA is based on the 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 quality of the random keying material generated by the Initiator
and the Responder. Since the Initiator is expected to be a sensor and the Responder. As either peer may be a sensor or an actuator
or an actuator device, there is a natural concern about the device, there is a natural concern about the quality of its random
quality of its random number generator. number generator.
o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2.
Consequently, if an HI is compromised, all HIP connections Consequently, if an HI is compromised, all HIP connections
protected with that HI are compromised. protected with that HI are compromised.
o The puzzle mechanism using CMAC may need further study regarding o The puzzle mechanism using CMAC may need further study regarding
the level of difficulty. the level of difficulty.
o The HIP DEX HIT generation may present new attack opportunities. o The HIP DEX HIT generation may present new attack opportunities.
Hence, HIP DEX HITs should not be use as the only means to
identify a peer in an ACL. Instead, the use of the peer's HI is
recommended.
o The R1 packet is unauthenticated and offers an adversary a new o The R1 packet is unauthenticated and offers an adversary a new
attack vector against the Initiator. This is mitigated by only attack vector against the Initiator. This is mitigated by only
processing a received R1 packet when the Initiator has previously processing a received R1 packet when the Initiator has previously
sent a corresponding I1 packet. Moreover, the Responder repeats sent a corresponding I1 packet. Moreover, the Responder repeats
the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and
TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to
enable the Initiator to verify that these parameters have not been enable the Initiator to verify that these parameters have not been
modified by an attacker in the unprotected R1 packet. modified by an attacker in the unprotected R1 packet.
skipping to change at page 40, line 48 skipping to change at page 41, line 38
against this attack, the Initiator SHOULD set the NOTIFY-based against this attack, the Initiator SHOULD set the NOTIFY-based
timeout value to the maximum indicated packet processing time in case timeout value to the maximum indicated packet processing time in case
of conflicting NOTIFY packets. This allows the legitimate Responder of conflicting NOTIFY packets. This allows the legitimate Responder
to extend the retransmission timeout to the intended length. The to extend the retransmission timeout to the intended length. The
adversary, however, can still arbitrarily delay the protocol adversary, however, can still arbitrarily delay the protocol
handshake beyond the Responder's actual I2 processing time. To limit handshake beyond the Responder's actual I2 processing time. To limit
the extend of such a maliciously induced handshake delay, this the extend of such a maliciously induced handshake delay, this
specification additionally requires the Initiator not to set the specification additionally requires the Initiator not to set the
NOTIFY-based timeout value higher than allowed by a local policy. NOTIFY-based timeout value higher than allowed by a local policy.
9. IANA Considerations 10. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
Parameters" registries have been made: Parameters" registries have been made:
HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD"
(see Section 5.2.4). (see Section 5.2.4).
Parameter Type This document defines the new HIP parameter Parameter Type This document defines the new HIP parameter
"ENCRYPTED_KEY" with type number 643 (see Section 5.2.5). "ENCRYPTED_KEY" with type number 643 (see Section 5.2.5).
HIP Cipher ID This document defines the new HIP Cipher ID "AES- HIP Cipher ID This document defines the new HIP Cipher ID "AES-
128-CTR" (see Section 5.2.2). 128-CTR" (see Section 5.2.2).
HI Algorithm This document defines the new HI Algorithm "ECDH" (see HI Algorithm This document defines the new HI Algorithm "ECDH" (see
Section 5.2.3). Section 5.2.3).
ECC Curve Label This document specifies a new algorithm-specific ECC Curve Label This document specifies a new algorithm-specific
subregistry named "ECDH Curve Label". The values for this subregistry named "ECDH Curve Label". The values for this
subregistry are defined in Section 5.2.1. subregistry are defined in Section 5.2.1.
10. Acknowledgments 11. Acknowledgments
The drive to put HIP on a cryptographic 'Diet' came out of a number 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 of discussions with sensor vendors at IEEE 802.15 meetings. David
McGrew was very helpful in crafting this document. McGrew was very helpful in crafting this document. Special thanks to
Miika Komu for reviewing this document in the context of Convince
Celtic+ project.
11. Changelog 12. Changelog
This section summarizes the changes made from draft-moskowitz-hip-rg- This section summarizes the changes made from draft-moskowitz-hip-rg-
dex-05, which was the first stable version of the draft. Note that dex-05, which was the first stable version of the draft. Note that
the draft was renamed after draft-moskowitz-hip-rg-dex-06. the draft was renamed after draft-moskowitz-hip-rg-dex-06.
The draft was then renamed from draft-moskowitz-hip-dex to draft- The draft was then renamed from draft-moskowitz-hip-dex to draft-
ietf-hip-dex. ietf-hip-dex.
11.1. Changes in draft-ietf-hip-dex-02 12.1. Changes in draft-ietf-hip-dex-03
o Added new section on HIP DEX/HIPv2 interoperability
o Added reference to RFC4493 for CMAC.
o Added reference to RFC5869 for CKDF.
o Added processing of NOTIFY message in I2-SENT of state diagram.
o Editorial changes.
12.2. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
11.2. Changes in draft-ietf-hip-dex-01 12.3. Changes in draft-ietf-hip-dex-01
o Added the new ECDH groups of Curve2519 and Curve448 from RFC 7748. o Added the new ECDH groups of Curve25519 and Curve448 from RFC
7748.
11.3. Changes in draft-ietf-hip-dex-00 12.4. Changes in draft-ietf-hip-dex-00
o The Internet Draft was adopted by the HIP WG. o The Internet Draft was adopted by the HIP WG.
11.4. Changes in draft-moskowitz-hip-rg-dex-06 12.5. Changes in draft-moskowitz-hip-rg-dex-06
o A major change in the ENCRYPT parameter to use AES-CTR rather than o A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
11.5. Changes in draft-moskowitz-hip-dex-00 12.6. Changes in draft-moskowitz-hip-dex-00
o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual
submission. submission.
o Added the change section. o Added the change section.
o Added a Definitions section. o Added a Definitions section.
o Changed I2 and R2 packets to reflect use of AES-CTR for o Changed I2 and R2 packets to reflect use of AES-CTR for
ENCRYPTED_KEY parameter. ENCRYPTED_KEY parameter.
o Cleaned up KEYMAT Generation text. o Cleaned up KEYMAT Generation text.
o Added Appendix with C code for the ECDH shared secret generation o Added Appendix with C code for the ECDH shared secret generation
on an 8 bit processor. on an 8 bit processor.
11.6. Changes in draft-moskowitz-hip-dex-01 12.7. Changes in draft-moskowitz-hip-dex-01
o Numerous editorial changes. o Numerous editorial changes.
o New retransmission strategy. o New retransmission strategy.
o New HIT generation mechanism. o New HIT generation mechanism.
o Modified layout of ENCRYPTED_KEY parameter. o Modified layout of ENCRYPTED_KEY parameter.
o Clarify to use puzzle difficulty of zero under normal network o Clarify to use puzzle difficulty of zero under normal network
skipping to change at page 42, line 46 skipping to change at page 44, line 7
MUST). MUST).
o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1
and I2). and I2).
o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be
echoed in R2 packet. echoed in R2 packet.
o Added new author. o Added new author.
11.7. Changes in draft-moskowitz-hip-dex-02 12.8. Changes in draft-moskowitz-hip-dex-02
o Introduced formal definition of FOLD function. o Introduced formal definition of FOLD function.
o Clarified use of CMAC for puzzle computation in section "Solving o Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle". the Puzzle".
o Several editorial changes. o Several editorial changes.
11.8. Changes in draft-moskowitz-hip-dex-03 12.9. Changes in draft-moskowitz-hip-dex-03
o Addressed HI crypto agility. o Addressed HI crypto agility.
o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
o Extended the IV in the ENCRYPTED_KEY parameter. o Extended the IV in the ENCRYPTED_KEY parameter.
o Introduced forward-references to HIP DEX KEYMAT process and o Introduced forward-references to HIP DEX KEYMAT process and
improved KEYMAT section. improved KEYMAT section.
o Replaced Appendix A on "C code for ECC point multiplication" with o Replaced Appendix A on "C code for ECC point multiplication" with
short discussion in introduction. short discussion in introduction.
o Updated references. o Updated references.
o Further editorial changes. o Further editorial changes.
11.9. Changes in draft-moskowitz-hip-dex-04 12.10. Changes in draft-moskowitz-hip-dex-04
o Improved retransmission extension. o Improved retransmission extension.
o Updated and strongly revised packet processing rules. o Updated and strongly revised packet processing rules.
o Updated security considerations. o Updated security considerations.
o Updated IANA considerations. o Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11. o Move the HI Algorithm for ECDH to a value of 11.
o Many editorial changes. o Many editorial changes.
12. References 13. References
13.1. Normative References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <http://www.rfc-editor.org/info/rfc2410>. November 1998, <http://www.rfc-editor.org/info/rfc2410>.
skipping to change at page 44, line 16 skipping to change at page 45, line 26
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<http://www.rfc-editor.org/info/rfc3686>. <http://www.rfc-editor.org/info/rfc3686>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <http://www.rfc-editor.org/info/rfc4493>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2 Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <http://www.rfc-editor.org/info/rfc7343>. 2014, <http://www.rfc-editor.org/info/rfc7343>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>. <http://www.rfc-editor.org/info/rfc7402>.
12.2. Informative References 13.2. Informative References
[DH76] Diffie, W. and M. Hellman, "New Directions in [DH76] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Cryptography", IEEE Transactions on Information
Theory vol. IT-22, number 6, pages 644-654, Nov 1976. Theory vol. IT-22, number 6, pages 644-654, Nov 1976.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Wehrle, "Tailoring End-to-End IP Security Protocols to the Wehrle, "Tailoring End-to-End IP Security Protocols to the
Internet of Things", in Proceedings of IEEE International Internet of Things", in Proceedings of IEEE International
Conference on Network Protocols (ICNP 2013), October 2013. Conference on Network Protocols (ICNP 2013), October 2013.
skipping to change at page 45, line 29 skipping to change at page 46, line 39
Layer (PHY) Specifications for Low-Rate Wireless Personal Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September Area Networks (WPANs)", IEEE Standard 802.15.4, September
2011, <http://standards.ieee.org/getieee802/ 2011, <http://standards.ieee.org/getieee802/
download/802.15.4-2011.pdf>. download/802.15.4-2011.pdf>.
[LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for
Elliptic Curve Cryptography in Wireless Sensor Networks", Elliptic Curve Cryptography in Wireless Sensor Networks",
in Proceedings of International Conference on Information in Proceedings of International Conference on Information
Processing in Sensor Networks (IPSN 2008), April 2008. Processing in Sensor Networks (IPSN 2008), April 2008.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
DOI 10.17487/RFC5903, June 2010, DOI 10.17487/RFC5903, June 2010,
<http://www.rfc-editor.org/info/rfc5903>. <http://www.rfc-editor.org/info/rfc5903>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010, RFC 5996, DOI 10.17487/RFC5996, September 2010,
<http://www.rfc-editor.org/info/rfc5996>. <http://www.rfc-editor.org/info/rfc5996>.
 End of changes. 71 change blocks. 
195 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/