draft-ietf-hip-dex-06.txt   draft-ietf-hip-dex-07.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: June 21, 2018 Hirschmann Automation and Control Expires: November 1, 2019 Hirschmann Automation and Control
December 18, 2017 M. Komu
Ericsson
April 30, 2019
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-06 draft-ietf-hip-dex-07
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 37 skipping to change at page 1, line 39
802.15.4 networks. 802.15.4 networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 June 21, 2018. This Internet-Draft will expire on November 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2019 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5
1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 6
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 8
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16
4.1.4. User Data Considerations . . . . . . . . . . . . . . 17 4.1.4. User Data Considerations . . . . . . . . . . . . . . 17
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 17 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 17
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 17 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 18 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 18
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 18
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 19 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 19
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 19 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 20
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 21 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 21
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 22 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 22
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 24 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 24
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 25 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 25
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 26 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 26
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 26 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 26 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 27
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 27 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 27
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 27 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 27
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 28 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 28
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 31 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 31
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 40 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 43 12.1. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 44
12.2. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44 12.2. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44
12.3. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44 12.3. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44
12.4. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44 12.4. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44
12.5. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44 12.5. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44
12.6. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 44 12.6. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 44
12.7. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 44 12.7. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 45
12.8. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 44 12.8. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45
12.9. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 12.9. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45
12.10. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 45 12.10. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46
12.11. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 45 12.11. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46
12.12. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 12.12. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
13.1. Normative References . . . . . . . . . . . . . . . . . . 46 13.1. Normative References . . . . . . . . . . . . . . . . . . 46
13.2. Informative References . . . . . . . . . . . . . . . . . 47 13.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 50 HIP DEX handshake . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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,
skipping to change at page 5, line 14 skipping to change at page 5, line 14
called out explicitly, the protocol specification of HIP DEX is the called out explicitly, the protocol specification of HIP DEX is the
same as defined in [RFC7401]. same as defined in [RFC7401].
1.1. The HIP Diet EXchange (DEX) 1.1. The HIP Diet EXchange (DEX)
The HIP Diet EXchange is a two-party cryptographic protocol used to The HIP Diet EXchange is a two-party cryptographic protocol used to
establish a secure communication context between hosts. The first establish a secure communication context between hosts. The first
party is called the Initiator and the second party the Responder. party is called the Initiator and the second party the Responder.
The four-packet exchange helps to make HIP DEX Denial of Service The four-packet exchange helps to make HIP DEX Denial of Service
(DoS) resilient. The Initiator and the Responder exchange their (DoS) resilient. The Initiator and the Responder exchange their
static Elliptic Curve Diffie-Hellman (ECDH) keys in the 2nd and 3rd static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2
handshake packet. The parties then authenticate each other in the handshake packet. The parties then authenticate each other in the I2
3rd and 4th handshake packet based on the ECDH-derived keying and R2 handshake packet based on the ECDH-derived keying material.
material. The Initiator and the Responder additionally transmit The Initiator and the Responder additionally transmit keying material
keying material for the session key in these last two handshake for the session key in these last two handshake packets (I2 and R2).
packets. This is to prevent overuse of the static ECDH-derived This is to prevent overuse of the static ECDH-derived keying
keying material. Moreover, the Responder starts a puzzle exchange in material. Moreover, the Responder starts a puzzle exchange in the R1
the 2nd packet and the Initiator completes this exchange in the 3rd packet and the Initiator completes this exchange in the I2 packet
packet before the Responder performs computationally expensive before the Responder performs computationally expensive operations or
operations or stores any state from the exchange. Given this stores any state from the exchange. Given this handshake structure,
handshake structure, HIP DEX operationally is very similar to HIP HIP DEX operationally is very similar to HIP BEX. Moreover, the
BEX. Moreover, the employed model is also fairly equivalent to employed model is also fairly equivalent to 802.11-2007
802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise Transient [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but
Key, but handled in a single exchange. handled in a single 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 I2 packet. The Responder's Host Identity also is
not protected. Thus, contrary to HIPv2, HIP DEX does not provide for not protected. Thus, contrary to HIPv2, HIP DEX does not provide for
end-point anonymity and any signaling that indicates such anonymity end-point anonymity and any signaling (i.e., HOST_ID parameter
contained with an ENCRYPTED parameter) that indicates such anonymity
should be ignored. should be ignored.
As in [RFC7401], data packets start to flow after the 4th packet. As in [RFC7401], data packets start to flow after the R2 packet. The
The 3rd and 4th HIP packets may carry data payload in the future. I2 and R2 packets may carry a data payload in the future. However,
However, the details of this may be defined later. 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. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of
the 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
skipping to change at page 6, line 15 skipping to change at page 6, line 16
(IKEv2) [RFC7296] that allows IKEv2 to support complex gateway (IKEv2) [RFC7296] 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, 9, and formats and rules for packet processing. Finally, Sections 7, 8, 9,
10 discuss policy, security, and IANA considerations, respectively. and 10 discuss policy, interoperability between HIPv2 vs DEX,
security, and IANA considerations, respectively.
2. Terms and Definitions 2. Terms, Notation 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Notation 2.2. Notation
[x] indicates that x is optional. [x] indicates that x is optional.
{x} indicates that x is encrypted. {x} indicates that x is encrypted.
X(y) indicates that y is a parameter of X. X(y) indicates that y is a parameter of X.
<x>i indicates that x exists i times. <x>i indicates that x exists i times.
skipping to change at page 7, line 5 skipping to change at page 7, line 8
FOLD (X, K) denotes the partitioning of X into n K-bit segments and 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, 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 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 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. 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 Ltrunc (M(x), K) denotes the lowest order K bits of the result of
the MAC function M on the input x. the MAC function M on the input x.
sort (HIT-I | HIT-R) 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.
2.3. Definitions 2.3. Definitions
HIP Diet Exchange (DEX): The ECDH-based HIP handshake for HIP Diet Exchange (DEX): The ECDH-based HIP handshake for
establishing a new HIP association. establishing a new HIP association.
Host Identity (HI): The static ECDH public key that represents the Host Identity (HI): The static ECDH public key that represents the
identity of the host. In HIP DEX, a host proves ownership of 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 private key belonging to its HI by creating a HIP_MAC with the
derived ECDH key (c.f. Section 3). derived ECDH key (see Section 3).
Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It
is generated by folding the HI (c.f. Section 3). is generated by folding the HI (see Section 3).
HIT Suite: A HIT Suite groups all algorithms that are required to HIT Suite: A HIT Suite groups all algorithms that are required to
generate and use an HI and its HIT. In particular, these generate and use an HI and its HIT. In particular, these
algorithms are: 1) ECDH and 2) FOLD. algorithms are: 1) ECDH and 2) FOLD.
HIP association: The shared state between two peers after completion HIP association: The shared state between two peers after completion
of the HIP DEX handshake. of the HIP DEX handshake.
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.
skipping to change at page 7, line 47 skipping to change at page 8, line 7
in HIP 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 CMAC: The Cipher-based Message Authentication Code with the 128-bit
Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].
CKDF: CMAC-based Key Derivation Function. CKDF: CMAC-based Key Derivation Function.
Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE
parameter (see section 5.2.4 in [RFC7401]. It is also referred to
as "random value #I" in this document.
Puzzle difficulty K: The Initiator has to compute a solution for the
puzzle. The level of computational difficulty is denoted by the
#K field in the puzzle parameter (see section 5.2.4 in [RFC7401].
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
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
skipping to change at page 8, line 36 skipping to change at page 9, line 4
of a host SHOULD be considered. of a host SHOULD be considered.
Carrying HIs and HITs in the header of user data packets would Carrying HIs and HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that increase the overhead of packets. Thus, it is not expected that
these parameters are carried in every packet, but other methods are these parameters are carried in every packet, but other methods are
used to map the data packets to the corresponding HIs. In some used to map the data packets to the corresponding HIs. In some
cases, this allows to use HIP DEX without any additional headers in 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 the user data packets. For example, if ESP is used to protect data
traffic, the Security Parameter Index (SPI) carried in the ESP header 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 can be used to map the encrypted data packet to the correct HIP DEX
association. association. When other user data packet formats are used, the
corresponding extensions need to define a replacement for the
ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
but this procedure is outside the scope of this document.
3.1. Host Identity Tag (HIT) 3.1. Host Identity Tag (HIT)
With HIP DEX, the HIT is a 128-bit value - a compression of the HI 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 prepended with a specific prefix. There are two advantages of using
a hashed encoding over the actual variable-sized public key in a hashed encoding over the actual variable-sized public key in
protocols. First, the fixed length of the HIT keeps packet sizes protocols. First, the fixed length of the HIT keeps packet sizes
manageable and eases protocol coding. Second, it presents a manageable and eases protocol coding. Second, it presents a
consistent format for the protocol, independent of the underlying consistent format for the protocol, independent of the underlying
identity technology in use. identity technology in use.
skipping to change at page 14, line 15 skipping to change at page 14, line 15
System behavior in state I2-SENT, Table 1. System behavior in state I2-SENT, Table 1.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Receive NOTIFY, | Set I2 retransmission timer to value in | | Receive NOTIFY, | Set I2 retransmission timer to value in |
| process | I2_ACKNOWLEDGEMENT Notification Data plus | | process | I2_ACKNOWLEDGEMENT Notification Data plus |
| | 1/2 RTT-based timeout value and stay at | | | 1/2 RTT-based timeout value and stay at |
| | I2-SENT | | | I2-SENT |
| | | | | |
| | |
| | |
| Timeout | Increment trial counter | | Timeout | Increment trial counter |
| | | | | |
| | |
| | |
| | If counter is less than I2_RETRIES_MAX, | | | If counter is less than I2_RETRIES_MAX, |
| | send I2, reset timer to RTT-based timeout, | | | send I2, reset timer to RTT-based timeout, |
| | and stay at I2-SENT | | | and stay at I2-SENT |
| | | | | |
| | |
| | |
| | If counter is greater than I2_RETRIES_MAX, | | | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED | | | go to E-FAILED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange
4.1.2.3. Simplified HIP State Diagram 4.1.2.3. Simplified HIP State Diagram
The following diagram shows the major state transitions. Transitions The following diagram shows the major state transitions. Transitions
based on received packets implicitly assume that the packets are based on received packets implicitly assume that the packets are
skipping to change at page 16, line 16 skipping to change at page 16, line 16
HIP DEX establishes two Security Associations (SA), one for the HIP DEX establishes two Security Associations (SA), one for the
Diffie-Hellman derived key, or Master Key, and one for the session Diffie-Hellman derived key, or Master Key, and one for the session
key, or Pair-wise Key. key, or Pair-wise Key.
4.1.3.1. Master Key SA 4.1.3.1. Master Key SA
The Master Key SA is used to authenticate HIP packets and to encrypt The Master Key SA is used to authenticate HIP packets and to encrypt
selected HIP parameters in the HIP DEX packet exchanges. Since only selected HIP parameters in the HIP DEX packet exchanges. Since only
a small amount of data is protected by this SA, it can be long-lived a small amount of data is protected by this SA, it can be long-lived
with no need for rekeying. with no need for rekeying. At the latest, the system MUST initiate
rekeying when its incoming ESP sequence counter is going to overflow,
and he system MUST NOT replace its keying material until the rekeying
packet exchange successfully completes as described in Section 6.8 in
[RFC7402].
The Master Key SA contains the following elements: The Master Key SA contains the following elements:
o Source HIT o Source HIT
o Destination HIT o Destination HIT
o HIP_Encrypt Key o HIP_Encrypt Key
o HIP_MAC Key o HIP_MAC Key
The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie-
Hellman derived key as described in Section 6.3. Their length is Hellman derived key as described in Section 6.3. Their length is
determined by the HIP_CIPHER. determined by the HIP_CIPHER.
4.1.3.2. Pair-wise Key SA 4.1.3.2. Pair-wise Key SA
The Pair-wise Key SA is used to authenticate and to encrypt user The Pair-wise Key SA is used to authenticate and to encrypt user
data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 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. The Pair-wise Key SA elements are defined by the data transform
ESP_TRANSFORM [RFC7402]). (e.g., ESP_TRANSFORM [RFC7402]).
The keys for the Pair-wise Key SA are derived based on the wrapped The keys for the Pair-wise Key SA are derived based on the wrapped
keying material exchanged in the ENCRYPTED_KEY parameter (see keying material exchanged in the ENCRYPTED_KEY parameter (see
Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged
keying material of the two peers is concatenated. This concatenation keying material of the two peers is concatenated. This concatenation
forms the input to a Key Derivation Function (KDF). If the data forms the input to a Key Derivation Function (KDF). If the data
transform does not specify its own KDF, the key derivation function transform does not specify its own KDF, the key derivation function
defined in Section 6.3 is used. Even though this input is randomly defined in Section 6.3 is used. Even though the concatenated input
distributed, a KDF Extract phase may be needed to get the proper is randomly distributed, a KDF Extract phase may be needed to get the
length for the input to the KDF Expand phase. proper length for the input to the KDF Expand phase.
4.1.4. User Data Considerations 4.1.4. User Data Considerations
The User Data Considerations in Section 4.5. of [RFC7401] also apply 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. 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 Loss of state due to system reboot may be a critical performance
issue for resource-constrained devices. Thus, implementors MAY issue for resource-constrained devices. Thus, implementors MAY
choose to use non-volatile, secure storage for HIP states in order choose to use non-volatile, secure storage for HIP states in order
for them to survive a system reboot. This will limit state loss for them to survive a system reboot as discussed in Section 6.11.
during reboots to only those situations with an SA timeout. Using non-volatile storage will limit state loss during reboots to
only those situations with an SA timeout.
5. Packet Formats 5. Packet Formats
5.1. Payload Format 5.1. Payload Format
HIP DEX employs the same fixed HIP header and payload structure as HIP DEX employs the same fixed HIP header and payload structure as
HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also
apply to HIP DEX. apply to HIP DEX.
5.2. HIP Parameters 5.2. HIP Parameters
skipping to change at page 19, line 8 skipping to change at page 19, line 10
AES-128-CTR 5 ([RFC3686]) AES-128-CTR 5 ([RFC3686])
Mandatory implementation: AES-128-CTR. Implementors SHOULD support Mandatory implementation: AES-128-CTR. Implementors SHOULD support
NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT
offer or accept this value unless explicitly configured for testing/ offer or accept this value unless explicitly configured for testing/
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. The HOST_ID parameter is defined
[RFC7401]. in Section 5.2.9 of [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 new 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
skipping to change at page 20, line 23 skipping to change at page 20, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 643 Type 643
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 bits. The puzzle
#I and the puzzle solution #J (see [RFC7401]) are used as the value #I and the puzzle solution #J (see Section 4.1.2 in [RFC7401])
initialization vector (IV) for the encryption process. To this end, are used as the initialization vector (IV) for the encryption
the IV is computed as FOLD(I | J, 128). Moreover, a 16 bit counter process. To this end, the IV is computed as FOLD(I | J, 128).
value, which is initialized to zero on first use, is appended to the Moreover, a 16 bit counter value, which is initialized to zero on
IV value in order to guarantee that a non-repeating nonce is fed to first use, is appended to the IV value in order to guarantee that a
the encryption algorithm defined by the HIP_CIPHER. 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 23, line 7 skipping to change at page 23, line 11
The Puzzle contains a Random value #I and the puzzle difficulty K. The Puzzle contains a Random value #I and the puzzle difficulty K.
The difficulty K indicates the number of lower-order bits, in the The difficulty K indicates the number of lower-order bits, in the
puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders
SHOULD set K to zero by default and only increase the puzzle SHOULD set K to zero by default and only increase the puzzle
difficulty to protect against a DoS attack targeting the HIP DEX difficulty to protect against a DoS attack targeting the HIP DEX
handshake. A puzzle difficulty of zero effectively turns the puzzle handshake. A puzzle difficulty of zero effectively turns the puzzle
mechanism into a return-routablility test and is strongly encouraged mechanism into a return-routablility test and is strongly encouraged
during normal operation in order to conserve energy resources as well during normal operation in order to conserve energy resources as well
as to prevent unnecessary handshake delay in case of a resource- as to prevent unnecessary handshake delay in case of a resource-
constrained Initiator. constrained Initiator. Please also refer to Section 7 for further
recommendations on choosing puzzle difficulty.
The DH_GROUP_LIST parameter contains the Responder's order of The DH_GROUP_LIST parameter contains the Responder's order of
preference based on which it chose the ECDH key contained in the preference based on which the Responder chose the ECDH key contained
HOST_ID parameter (see below). This allows the Initiator to in the HOST_ID parameter (see below). This allows the Initiator to
determine whether its own DH_GROUP_LIST in the I1 packet was determine whether its own DH_GROUP_LIST in the I1 packet was
manipulated by an attacker. There is a further risk that the manipulated by an attacker. There is a further risk that the
Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1
packet cannot be authenticated in HI DEX. Thus, this parameter is packet cannot be authenticated in HI DEX. Thus, this parameter is
repeated in the R2 packet to allow for a final, cryptographically repeated in the R2 packet to allow for a final, cryptographically
secured validation. secured validation.
The HIP_CIPHER contains the encryption algorithms supported by the The HIP_CIPHER contains the encryption algorithms supported by the
Responder to protect the key exchange, in the order of preference. Responder to protect the key exchange, in the order of preference.
All implementations MUST support the AES-CTR [RFC3686]. All implementations MUST support the AES-CTR [RFC3686].
skipping to change at page 24, line 11 skipping to change at page 24, line 16
parameter also indicates the selected DH group. Moreover, the parameter also indicates the selected DH group. Moreover, the
Responder sets the source HIT in the R2 packet based on 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 destination HIT from the I1 packet. Based on the deviating DH group
ID in the HOST_ID parameter, the Initiator then SHOULD abort the ID in the HOST_ID parameter, the Initiator then SHOULD abort the
current handshake and initiate a new handshake with the mutually current handshake and initiate a new handshake with the mutually
supported DH group as far as local 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. The different format types are DEFAULT, ESP and
IPsec ESP [RFC7402]. ESP-TCP as explained in Section 3.1 in [RFC6261].
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
or more ECHO_REQUEST_UNSIGNED parameters. or more ECHO_REQUEST_UNSIGNED parameters.
5.3.3. I2 - the Second HIP Initiator Packet 5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: The HIP header values for the I2 packet:
skipping to change at page 25, line 27 skipping to change at page 25, line 31
algorithm. algorithm.
The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque
data copied from the corresponding echo request parameter(s). This data copied from the corresponding echo request parameter(s). This
parameter can also be used for two-factor password authentication as parameter can also be used for two-factor password authentication as
shown in Appendix A. shown in Appendix A.
The TRANSPORT_FORMAT_LIST parameter contains the single transport The TRANSPORT_FORMAT_LIST parameter contains the single transport
format type selected by the Initiator. The chosen type MUST format type selected by the Initiator. The chosen type MUST
correspond to one of the types offered by the Responder in the R1 correspond to one of the types offered by the Responder in the R1
packet. Currently, the only transport format defined is the ESP packet. The different format types are DEFAULT, ESP and ESP-TCP as
transport format [RFC7402]. explained in Section 3.1 in [RFC6261].
The MAC is calculated over the whole HIP envelope, excluding any The MAC is calculated over the whole HIP envelope, excluding any
parameters after the HIP_MAC parameter as described in Section 6.2. parameters after the HIP_MAC parameter as described in Section 6.2.
The Responder MUST validate the HIP_MAC parameter. The Responder MUST validate the HIP_MAC parameter.
5.3.4. R2 - the Second HIP Responder Packet 5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet: The HIP header values for the R2 packet:
Header: Header:
skipping to change at page 26, line 45 skipping to change at page 26, line 49
6. Packet Processing 6. Packet Processing
Due to the adopted protocol semantics and the inherited general Due to the adopted protocol semantics and the inherited general
packet structure, the packet processing in HIP DEX only differs from packet structure, the packet processing in HIP DEX only differs from
HIPv2 in very few places. Here, we focus on these differences and HIPv2 in very few places. Here, we focus on these differences and
refer to Section 6 in [RFC7401] otherwise. refer to Section 6 in [RFC7401] otherwise.
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]).
It should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further
implementation experience provides better guidance.
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 Section 6.3 of [RFC7401] is skipped in HIP DEX. computation step in Section 6.3 of [RFC7401] is skipped in HIP 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
skipping to change at page 27, line 50 skipping to change at page 28, line 11
The CMAC calculation and verification process is as follows: The CMAC calculation and verification process is as follows:
Packet sender: Packet sender:
1. Create the HIP packet, without the HIP_MAC or any other parameter 1. Create the HIP packet, without the HIP_MAC or any other parameter
with greater Type value than the HIP_MAC parameter has. with greater Type value than the HIP_MAC parameter has.
2. Calculate the Header Length field in the HIP header. 2. Calculate the Header Length field in the HIP header.
3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key
retrieved from KEYMAT as defined in Section 6.3. retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers
to host with greater HIT value and HIP-lg refers to the host with
smaller HIT value.
4. Add the HIP_MAC parameter to the packet and any parameter with 4. Add the HIP_MAC parameter to the packet and any parameter with
greater Type value than the HIP_MAC's that may follow. greater Type value than the HIP_MAC's that may follow.
5. Recalculate the Length field in the HIP header. 5. Recalculate the Length field in the HIP header.
Packet receiver: Packet receiver:
1. Verify the HIP header Length field. 1. Verify the HIP header Length field.
skipping to change at page 30, line 23 skipping to change at page 30, line 23
info sort(HIT-I | HIT-R) | "CKDF-Expand" info sort(HIT-I | HIT-R) | "CKDF-Expand"
where "CKDF-Expand" is an octet string where "CKDF-Expand" is an octet string
L length of output keying material in octets L length of output keying material in octets
(<= 255*RHASH_len/8) (<= 255*RHASH_len/8)
Output: Output:
OKM output keying material (of L octets) OKM output keying material (of L octets)
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)
T(1) = CMAC(PRK, T(0) | info | 0x01) T(1) = CMAC(PRK, T(0) | info | 0x01)
T(2) = CMAC(PRK, T(1) | info | 0x02) T(2) = CMAC(PRK, T(1) | info | 0x02)
T(3) = CMAC(PRK, T(2) | info | 0x03) T(3) = CMAC(PRK, T(2) | info | 0x03)
... ...
skipping to change at page 31, line 41 skipping to change at page 31, line 41
the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- the overhead of generating an ephemeral Diffie-Hellman key-pair, pre-
computation of an R1 is only marginally beneficial, but would incur computation of an R1 is only marginally beneficial, but would incur
additional memory resources at the Responder. Hence, the R1 pre- additional memory resources at the Responder. Hence, the R1 pre-
computation SHOULD be omitted in HIP DEX. computation SHOULD be omitted in HIP DEX.
Correspondingly, the modified conceptual processing rules for Correspondingly, the modified conceptual processing rules for
responding to an I1 packet are as follows: responding to an I1 packet are as follows:
1. The Responder MUST check that the Responder's HIT in the received 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 I1 packet is either one of its own HITs or NULL. Otherwise, it
must drop the packet. MUST drop the packet.
2. If the Responder is in ESTABLISHED state, the Responder MAY 2. If the Responder is in ESTABLISHED state, the Responder MAY
respond to this with an R1 packet, prepare to drop an existing respond to this with an R1 packet, prepare to drop an existing
HIP security association with the peer, and stay at ESTABLISHED HIP security association with the peer, and stay at ESTABLISHED
state. state.
3. If the Responder is in I1-SENT state, it MUST make a comparison 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. 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 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 the I1 packet and stay at I1-SENT. If the sender's HIT is
skipping to change at page 33, line 13 skipping to change at page 33, line 13
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 correct 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 processes
process the R1 packet as described below. 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
Initiator's HIT MUST correspond to the HIT used in the original Initiator's HIT MUST correspond to the HIT used in the original
I1 packet. Also, the Responder's HIT MUST correspond to the one I1 packet. Also, the Responder's HIT MUST correspond to the one
used in the I1 packet, unless this packet contained a NULL HIT. used in the I1 packet, unless this packet contained a NULL HIT.
skipping to change at page 34, line 21 skipping to change at page 34, line 21
restarting the handshake, the Initiator MUST consult local restarting the handshake, the Initiator MUST consult local
policies (see Section 7) regarding the use of another, mutually policies (see Section 7) regarding the use of another, mutually
supported DH group for the subsequent handshake with the supported DH group for the subsequent handshake with the
Responder. Responder.
7. If the HIP association state is I2-SENT, the system MAY re-enter 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 state I1-SENT and process the received R1 packet if it has a
larger R1 generation counter than the R1 packet responded to larger R1 generation counter than the R1 packet responded to
previously. previously.
8. The R1 packet may have the A-bit set - in this case, the system 8. The R1 packet can have the A-bit set - in this case, the system
MAY choose to refuse it by dropping the R1 packet and returning MAY choose to refuse it by dropping the R1 packet and returning
to state UNASSOCIATED. The system SHOULD consider dropping the to state UNASSOCIATED. The system SHOULD consider dropping the
R1 packet only if it used a NULL HIT in the I1 packet. If 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 A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be
stored permanently. stored permanently.
9. The system SHOULD attempt to validate the HIT against the 9. The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host Identity to received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT. construct a HIT and verify that it matches the Sender's HIT.
skipping to change at page 34, line 50 skipping to change at page 34, line 50
12. The system computes standard Diffie-Hellman keying material 12. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the according to the public value and Group ID provided in the
HOST_ID parameter. The Diffie-Hellman keying material Kij is HOST_ID parameter. The Diffie-Hellman keying material Kij is
used for key extraction as specified in Section 6.3. used for key extraction as specified in Section 6.3.
13. The system selects the HIP_CIPHER ID from the choices presented 13. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2 generating and using encryption keys, and when sending the I2
packet. If the proposed alternatives are not acceptable to the packet. If the proposed alternatives are not acceptable to the
system, it may either resend an I1 packet within the retry system, it MAY either resend an I1 packet within the retry
bounds or abandon the HIP base exchange. bounds or abandon the HIP base exchange.
14. The system chooses one suitable transport format from the 14. The system chooses one suitable transport format from the
TRANSPORT_FORMAT_LIST and includes the respective transport TRANSPORT_FORMAT_LIST and includes the respective transport
format parameter in the subsequent I2 packet. format parameter in the subsequent I2 packet.
15. The system initializes the remaining variables in the associated 15. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
16. The system prepares and sends an I2 packet as described in 16. The system prepares and sends an I2 packet as described in
skipping to change at page 36, line 25 skipping to change at page 36, line 25
order to prevent unnecessary computation overhead. order to prevent unnecessary computation overhead.
5. If the system's state machine is in the I2-SENT state, the 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 system MUST make a comparison between its local and sender's
HITs (similarly as in Section 6.3). If the local HIT is smaller 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 than the sender's HIT, it should drop the I2 packet, use the
peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
#I from the R1 packet received earlier, and get the local #I from the R1 packet received earlier, and get the local
Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
from the I2 packet sent to the peer earlier. Otherwise, the from the I2 packet sent to the peer earlier. Otherwise, the
system should process the received I2 packet and drop any system processes the received I2 packet and drops any previously
previously derived Diffie-Hellman keying material Kij and derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY
ENCRYPTED_KEY keying material it might have generated upon keying material it might have generated upon sending the I2
sending the I2 packet previously. The peer Diffie-Hellman key, packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY,
ENCRYPTED_KEY, and the nonce #J are taken from the just arrived and the nonce #J are taken from the just arrived I2 packet. The
I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the
material, and the nonce #I are the ones that were sent earlier nonce #I are the ones that were sent earlier in the R1 packet.
in the R1 packet.
6. If the system's state machine is in the I1-SENT state, and the 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 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 packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes retransmitting I1 packets (provided that the I2 packet passes
the additional checks below). the additional checks below).
7. If the system's state machine is in any state other than 7. If the system's state machine is in any state other than
R2-SENT, the system SHOULD check that the echoed R1 generation R2-SENT, the system SHOULD check that the echoed R1 generation
skipping to change at page 37, line 43 skipping to change at page 37, line 43
13. The system MUST verify the HIP_MAC according to the procedures 13. The system MUST verify the HIP_MAC according to the procedures
in Section 6.2. in Section 6.2.
14. If the checks above are valid, then the system proceeds with 14. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state. state machine remains in the same state.
15. The I2 packet may have the A-bit set - in this case, the system 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 MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A-bit is set, the returns to state UNASSOCIATED. If the A-bit is set, the
Initiator's HIT is anonymous and should not be stored Initiator's HIT is anonymous and MUST NOT be stored permanently.
permanently.
16. The system MUST decrypt the keying material from the 16. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial ENCRYPTED_KEY parameter. This keying material is a partial
input to the key derivation process for the Pair-wise Key SA input to the key derivation process for the Pair-wise Key SA
(see Section 6.3). (see Section 6.3).
17. The system initializes the remaining variables in the associated 17. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
18. Upon successful processing of an I2 packet when the system's 18. Upon successful processing of an I2 packet when the system's
skipping to change at page 39, line 34 skipping to change at page 39, line 34
6 has been added to the processing rules. 6 has been added to the processing rules.
6.9. Processing Incoming NOTIFY Packets 6.9. Processing Incoming NOTIFY Packets
Processing of NOTIFY packets is OPTIONAL. If processed, any errors Processing of NOTIFY packets is OPTIONAL. If processed, any errors
in a received NOTIFICATION parameter SHOULD be logged. Received in a received NOTIFICATION parameter SHOULD be logged. Received
errors MUST be considered only as informational, and the receiver errors MUST be considered only as informational, and the receiver
SHOULD NOT change its HIP state purely based on the received NOTIFY SHOULD NOT change its HIP state purely based on the received NOTIFY
packet. packet.
If a NOTIFY packet is received in state I2-SENT, this packet may be If a NOTIFY packet is received in state I2-SENT, this packet is an I2
an I2 reception acknowledgement of the optional retransmission reception acknowledgement of the optional retransmission mechanism
mechanism extension and SHOULD be processed. The following steps extension and SHOULD be processed. The following steps define the
define the conceptual processing rules for such incoming NOTIFY conceptual processing rules for such incoming NOTIFY packets in state
packets in state I2-SENT: I2-SENT:
1. The system MUST verify that the HITs in use correspond to the 1. The system MUST verify that the HITs in use correspond to the
HITs that were received in the R1 packet that caused the HITs that were received in the R1 packet that caused the
transition to the I2-SENT state. If this check fails, the NOTIFY transition to the I2-SENT state. If this check fails, the NOTIFY
packet SHOULD be dropped silently. packet MUST be dropped silently.
2. If the NOTIFY packet contains a NOTIFICATION parameter with 2. If the NOTIFY packet contains a NOTIFICATION parameter with
Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the
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.
skipping to change at page 40, line 35 skipping to change at page 40, line 35
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.
Such storing of the R1 generation counter values MUST be configured Such storing of the R1 generation counter values MUST be configured
by explicit HITs. 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. The value of #K used in the HIP R1 must that each host must support. The value of puzzle difficulty K used
be chosen with care. Values of #K that are too high will exclude in the HIP R1 must be chosen with care. Values for the K that are
clients with weak CPUs because these devices cannot solve the puzzle too high will exclude clients with weak CPUs because these devices
within a reasonable amount of time. #K should only be raised if a cannot solve the puzzle within a reasonable amount of time. The K
Responder is under high load, i.e., it cannot process all incoming value should only be raised if a Responder is under high load, i.e.,
HIP handshakes any more. If a Responder is not under high load, #K it cannot process all incoming HIP handshakes any more.
SHOULD be 0.
If a Responder is not under high load, K SHOULD be 0.
All HIP DEX implementations SHOULD provide for an Access Control List All HIP DEX implementations SHOULD provide for an Access Control List
(ACL), representing for which hosts they accept HIP diet exchanges, (ACL), representing for which hosts they accept HIP diet exchanges,
and the preferred transport format and local lifetimes. Wildcarding and the preferred transport format and local lifetimes. Wildcarding
SHOULD be supported for such ACLs. SHOULD be supported for such ACLs.
8. Interoperability between HIP DEX and HIPv2 8. Interoperability between HIP DEX and HIPv2
HIP DEX and HIPv2 both use the same protocol number and packet HIP DEX and HIPv2 both use the same protocol number and packet
formats. Hence, an implementation that either supports HIP DEX or formats. Hence, an implementation that either supports HIP DEX or
HIPv2 must be able to detect the dialect that the peer is speaking. HIPv2 has to be able to detect the dialect that the peer is speaking.
This section outlines how a HIP DEX implementation can achieve such This section outlines how a HIP DEX implementation can achieve such
detection for the two relevant cases where: detection for the two relevant cases where:
1. the Initiator supports HIP DEX and the Responder supports HIP 1. the Initiator supports HIP DEX and the Responder supports HIP
BEX, BEX,
2. the Initiator supports HIP BEX and the Responder supports HIP 2. the Initiator supports HIP BEX and the Responder supports HIP
DEX. DEX.
In the first case, the HIP DEX implementation (Initiator) inspects In the first case, the HIP DEX implementation (Initiator) inspects
skipping to change at page 41, line 32 skipping to change at page 41, line 37
to the user via appropriate means. to the user via appropriate means.
In the second case, the HIP DEX implementation (Responder) inspects In the second case, the HIP DEX implementation (Responder) inspects
the Initiator's HIT on reception of an I1 packet. If the OGA ID 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 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 DEX implementation cancels the handshake and sends an ICMP packet
with type Parameter Problem, with the Pointer pointing to the source with type Parameter Problem, with the Pointer pointing to the source
HIT, to the Initiator. As an adversary could also send such an ICMP HIT, to the Initiator. As an adversary could also send such an ICMP
packet in a man-in-the-middle attack with the aim to prevent the HIP packet in a man-in-the-middle attack with the aim to prevent the HIP
DEX handshake from completing, the Initiator SHOULD NOT react to an DEX handshake from completing, the Initiator SHOULD NOT react to an
ICMP message after sending the I1 until a reasonable delta time to ICMP message before retransmission counter reaches I1_RETRIES_MAX in
get the real Responder's R1 HIP packet. its state machine (see Table 3 in [RFC7401]).
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 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 with 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. As either peer may be a sensor or an actuator and the Responder. As either peer may be a sensor or an actuator
device, there is a natural concern about the quality of its random device, there is a natural concern about the 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 as explained in Section 1.
o The puzzle mechanism using CMAC may need further study regarding o The puzzle mechanism using CMAC explained in Section 4.1.1 may
the level of difficulty. need further study regarding the level of difficulty in order to
establish best practices with current generation of constrained
devices.
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 Hence, HIP DEX HITs MUST NOT be used as the only means to identify
identify a peer in an ACL. Instead, the use of the peer's HI is a peer in an ACL. Instead, the use of the peer's HI is
recommended. recommended as explained in Section 3.
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 as explained
in Section 6.8.
o Contrary to HIPv2, HIP DEX does not provide for end-point
anonymity for the Initiator or Responder. Thus, any signaling
that indicates such anonymity should be ignored as explained in
Section 1.1.
The optional retransmission extension of HIP DEX is based on a NOTIFY The optional retransmission extension of HIP DEX is based on a NOTIFY
packet that the Responder can use to inform the Initiator about the packet that the Responder can use to inform the Initiator about the
reception of an I2 packet. The Responder, however, cannot protect reception of an I2 packet. The Responder, however, cannot protect
the authenticity of this packet as it did not yet set up the Master the authenticity of this packet as it did not yet set up the Master
Key SA. Hence, an eavesdropping adversary may send spoofed reception Key SA. Hence, an eavesdropping adversary may send spoofed reception
acknowledgements for an overheard I2 packet and signal an arbitrary acknowledgments for an overheard I2 packet and signal an arbitrary I2
I2 processing time to the Initiator. The adversary can, e.g., processing time to the Initiator. The adversary can, e.g., indicate
indicate a lower I2 processing time than actually required by the a lower I2 processing time than actually required by the Responder in
Responder in order to cause premature retransmissions. To protect order to cause premature retransmissions. To protect against this
against this attack, the Initiator SHOULD set the NOTIFY-based attack, the Initiator SHOULD set the NOTIFY-based timeout value to
timeout value to the maximum indicated packet processing time in case the maximum indicated packet processing time in case of conflicting
of conflicting NOTIFY packets. This allows the legitimate Responder NOTIFY packets. This allows the legitimate Responder to extend the
to extend the retransmission timeout to the intended length. The retransmission timeout to the intended length. The adversary,
adversary, however, can still arbitrarily delay the protocol however, can still arbitrarily delay the protocol handshake beyond
handshake beyond the Responder's actual I2 processing time. To limit the Responder's actual I2 processing time. To limit the extend of
the extend of such a maliciously induced handshake delay, this such a maliciously induced handshake delay, this specification
specification additionally requires the Initiator not to set the additionally requires the Initiator not to set the NOTIFY-based
NOTIFY-based timeout value higher than allowed by a local policy. timeout value higher than allowed by a local policy.
Section 5.3.1 mentions that implementations need to be able to handle
storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre-
computated in HIP DEX and also the state machine does not include an
"R1_SENT" state (that would enable caching of R1 packets).
Therefore, an implementation has to cache information (e.g., at least
the HITs) from incoming I1 packets and rate control the incoming I1
packets to avoid unnecessary packet processing during I1 packet
storms.
10. 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). without four-bit ID of 8 and eight-bit encoding of 0x80 (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" with type number 5 (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" with
Section 5.2.3). type number 11 (see 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.
11. 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. Special thanks to McGrew was very helpful in crafting this document. Special thanks to
skipping to change at page 46, line 35 skipping to change at page 47, line 7
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.
13. References 13. References
13.1. Normative References 13.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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://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, <https://www.rfc-editor.org/info/rfc2410>. November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
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,
<https://www.rfc-editor.org/info/rfc3686>. <https://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", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the
Host Identity Protocol", RFC 6261, DOI 10.17487/RFC6261,
May 2011, <https://www.rfc-editor.org/info/rfc6261>.
[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, <https://www.rfc-editor.org/info/rfc7343>. 2014, <https://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,
<https://www.rfc-editor.org/info/rfc7401>. <https://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, <https://www.rfc- DOI 10.17487/RFC7402, April 2015,
editor.org/info/rfc7402>. <https://www.rfc-editor.org/info/rfc7402>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.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.
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-18 (work in Architecture", draft-ietf-hip-rfc4423-bis-20 (work in
progress), November 2017. progress), February 2019.
[IEEE.802-11.2007] [IEEE.802-11.2007]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, June Layer (PHY) Specifications", IEEE Standard 802.11, June
2007, <http://standards.ieee.org/getieee802/ 2007, <http://standards.ieee.org/getieee802/
download/802.11-2007.pdf>. download/802.11-2007.pdf>.
skipping to change at page 48, line 26 skipping to change at page 48, line 51
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.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>. 2006, <https://www.rfc-editor.org/info/rfc4493>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, <https://www.rfc- DOI 10.17487/RFC5869, May 2010,
editor.org/info/rfc5869>. <https://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, <https://www.rfc- DOI 10.17487/RFC5903, June 2010,
editor.org/info/rfc5903>. <https://www.rfc-editor.org/info/rfc5903>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, <https://www.rfc- DOI 10.17487/RFC6090, February 2011,
editor.org/info/rfc6090>. <https://www.rfc-editor.org/info/rfc6090>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, <https://www.rfc- DOI 10.17487/RFC7228, May 2014,
editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
skipping to change at line 2256 skipping to change at page 50, line 40
EMail: rgm@htt-consult.com EMail: rgm@htt-consult.com
Rene Hummen Rene Hummen
Hirschmann Automation and Control Hirschmann Automation and Control
Stuttgarter Strasse 45-51 Stuttgarter Strasse 45-51
Neckartenzlingen 72654 Neckartenzlingen 72654
Germany Germany
EMail: rene.hummen@belden.com EMail: rene.hummen@belden.com
Miika Komu
Ericsson Research, Finland
Hirsalantie 11
Jorvas 02420
Finland
EMail: miika.komu@ericsson.com
 End of changes. 72 change blocks. 
148 lines changed or deleted 209 lines changed or added

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