draft-ietf-hip-dex-13.txt   draft-ietf-hip-dex-14.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: August 17, 2020 Hirschmann Automation and Control Expires: September 10, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
February 14, 2020 March 9, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-13 draft-ietf-hip-dex-14
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. functions.
The HIP DEX protocol is primarily designed for computation or memory- The HIP DEX protocol is primarily designed for computation or memory-
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 https://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 August 17, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 10 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18
4.1.4. User Data Considerations . . . . . . . . . . . . . . 19 4.1.4. User Data Considerations . . . . . . . . . . . . . . 19
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 27 skipping to change at page 3, line 27
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 47 9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 47
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 47 9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 49 12.1. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49
12.2. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 49 12.2. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 49
12.3. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 49 12.3. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 49
12.4. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 49 12.4. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 49
12.5. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 49 12.5. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 49
12.6. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50 12.6. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50
12.7. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 50 12.7. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50
12.8. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 50 12.8. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 50
12.9. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 50 12.9. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 50
12.10. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 50 12.10. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 50
12.11. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 50 12.11. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 50
12.12. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51
12.13. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51 12.13. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51
12.14. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 51 12.14. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51
12.15. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52 12.15. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 51
12.16. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52 12.16. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52
12.17. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 52 12.17. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52
12.18. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 52
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.1. Normative References . . . . . . . . . . . . . . . . . . 52 13.1. Normative References . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 56 HIP DEX handshake . . . . . . . . . . . . . . . . . 56
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 56 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
contained with an ENCRYPTED parameter) that indicates such anonymity 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 R2 packet. The As in [RFC7401], data packets start to flow after the R2 packet. The
I2 and R2 packets may carry a data payload in the future. The I2 and R2 packets may carry a data payload in the future. The
details of this may be defined later. 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 does so even in the absence of the
the original HIPv2 specification. HIP_SIGNATURE that is used in standard HIPv2.
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) [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. Applicability 1.2. Applicability
HIP DEX, by design, does not support Perfect Forward Secrecy (PFS). HIP DEX achieves its lightweight nature in large part due to the
All current PFS approaches use Ephemeral DH, secured and identified intentional removal of Forward Secrecy (FS) from the key exchange.
in some manner (for example, with SIGMA or PAKE). There are classes Current mechanisms to achieve FS use an authenticated ephemeral
of devices, like those based on the 8-bit 8051 microprocessor, where Diffie-Hellman exchange (e.g., SIGMA or PAKE). HIP DEX targets usage
this is prohibitively expensive. Past experience with the 8051 based on devices where even the most lightweight ECDH exchange is
ZWAVE ZW0500 product has shown that EC25519 key pair generation prohibitively expensive for recurring (ephemeral) use. For example,
exceeded 10 seconds with unacceptable battery consumption. The ECDH experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has
wide-multiply of the static-static keys took 8 - 9 seconds with shown that EC25519 keypair generation exceeds 10 seconds and consumes
measurable battery drain. For these class of devices, the possible significant energy (i.e., battery resources). Even the ECDH
risk of no PFS has to be weighed against the risk of theft of multiplication for the HIP DEX static-static key exchange takes 8-9
preshared keys alternatives. Also, it is often the case that HIP DEX seconds, again with measurable energy consumption. This resource
is only performed during device join time, and, thus, no PFS is consumption is tolerable as a one-time event during provisioning, but
considered an acceptable compromise. would render the protocol unsuitable for use on these devices if it
was required to be a recurring part of the protocol. For devices
constrained in this manner, a FS-enabled protocol will likely provide
little gain. The resulting "FS" key, likely produced during device
provisioning, would typically end up being used for the remainder of
the device's lifetime.
Also, it is often the case that HIP DEX is only performed during With such a usage pattern, the inherent benefit of ephemeral keys is
device join time, and thus no PFS is considered an acceptable not realized. The security properties of such usage are very similar
compromised. to those of using a statically provisioned symmetric pre-shared key,
in that there remains a single PSK in static storage that is
susceptible to exfiltration/compromise, and compromise of that key in
effect compromises the entire protocol for that node. HIP DEX
achieves marginally better security properties by computing the
effective long-term PSK from a DH exchange, so that the provisioning
service is not required to be part of the risk surface due to also
possessing the PSK.
HIP DEX MUST only be used in communicating with such constrained Due to the substantially reduced security guarantees of HIP DEX
devices (e.g., class 0 and 1 devices as defined in section 3 in compared to HIP BEX, HIP DEX MUST only be used when at least one of
[RFC7228]). the two endpoints is a class 0 or 1 constrained device defined in
Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both
endpoints are class 2 devices or unconstrained.
1.3. Memo Structure 1.3. 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, 9, formats and rules for packet processing. Finally, Sections 7, 8, 9,
and 10 discuss policy, interoperability between HIPv2 vs DEX, and 10 discuss policy, interoperability between HIPv2 vs DEX,
skipping to change at page 8, line 19 skipping to change at page 8, line 30
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].
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.
HIP DEX (Diet EXchange): The ECDH-based HIP handshake for HIP DEX (Diet EXchange): The ECDH-based HIP handshake for
establishing a new HIP association. establishing a new HIP association.
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 for HIP DEX,
algorithms are: 1) ECDH and 2) FOLD. these algorithms are: 1) ECDH and 2) FOLD.
HI (Host Identity): The static ECDH public key that represents the HI (Host Identity): 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 (see Section 3). derived ECDH key (see Section 3).
HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It
is generated by folding the HI (see Section 3). is generated by folding the HI (see Section 3).
Initiator: The host that initiates the HIP DEX handshake. This role Initiator: The host that initiates the HIP DEX handshake. This role
skipping to change at page 9, line 31 skipping to change at page 9, line 43
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.
HIP DEX implementations MUST support the Elliptic Curve Diffie- HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH)
Hellman (ECDH) [RFC6090] key exchange for generating the HI as [RFC6090] key exchange for generating the HI as defined in
defined in Section 5.2.3. No additional algorithms are supported at Section 5.2.3. No alternative algorithms are defined at this time.
this time.
A compressed encoding of the HI, the Host Identity Tag (HIT), is used A compressed encoding of the HI, the Host Identity Tag (HIT), is used
in the handshake packets to represent the HI. The DEX Host Identity in the handshake packets to represent the HI. The DEX Host Identity
Tag (HIT) is different from the BEX HIT in two ways: Tag (HIT) is different from the BEX HIT in two ways:
o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4).
o The DEX HIT is not generated via a cryptographic hash. Rather, it o The DEX HIT is not generated via a cryptographic hash. Rather, it
is a compression of the HI. is a compression of the HI.
Due to the latter property, an attacker may be able to find a Due to the latter property, an attacker may be able to find a
collision with a HIT that is in use. Hence, policy decisions such as collision with a HIT that is in use. Hence, policy decisions such as
access control MUST NOT be based solely on the HIT. Instead, the HI access control MUST NOT be based solely on the HIT. Instead, the HI
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 or 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 use of HIP DEX without any additional headers in cases, this allows use of 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. When other user data packet formats are used, the association. When other user data packet formats are used, the
corresponding extensions need to define a replacement for the corresponding extensions need to define a replacement for the
ESP_TRANSFORM [RFC7402] parameter along with associated semantics, ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
skipping to change at page 11, line 46 skipping to change at page 12, line 9
the Master Key SA generation. This Master Key SA is used by the the Master Key SA generation. This Master Key SA is used by the
Initiator and the Responder to wrap secret keying material in the I2 Initiator and the Responder to wrap secret keying material in the I2
and R2 packets. Based on the exchanged keying material, the peers and R2 packets. Based on the exchanged keying material, the peers
then derive a Pair-wise Key SA if cryptographic keys are needed, then derive a Pair-wise Key SA if cryptographic keys are needed,
e.g., for ESP-based protection of user data. e.g., for ESP-based protection of user data.
The Initiator first sends a trigger packet, I1, to the Responder. The Initiator first sends a trigger packet, I1, to the Responder.
This packet contains the HIT of the Initiator and the HIT of the This packet contains the HIT of the Initiator and the HIT of the
Responder, if it is known. Moreover, the I1 packet initializes the Responder, if it is known. Moreover, the I1 packet initializes the
negotiation of the Diffie-Hellman group that is used for generating negotiation of the Diffie-Hellman group that is used for generating
the the Master Key SA. Therefore, the I1 packet contains a list of the Master Key SA. Therefore, the I1 packet contains a list of
Diffie-Hellman Group IDs supported by the Initiator. Note that in Diffie-Hellman Group IDs supported by the Initiator.
some cases it may be possible to replace this trigger packet by some
other form of a trigger, in which case the protocol starts with the
Responder sending the R1 packet. In such cases, another mechanism to
convey the Initiator's supported DH Groups (e.g., by using a default
group) must be specified.
The second packet, R1, starts the actual authenticated Diffie-Hellman The second packet, R1, starts the actual authenticated Diffie-Hellman
key exchange. It contains a puzzle - a cryptographic challenge that key exchange. It contains a puzzle - a cryptographic challenge that
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
with the Initiator, current load, or other factors. In addition, the knowledge of the Initiator, current load, or other factors. In
R1 contains the Responder's Diffie-Hellman parameter and lists of addition, the R1 contains the Responder's Diffie-Hellman parameter
cryptographic algorithms supported by the Responder. Based on these and lists of cryptographic algorithms supported by the Responder.
lists, the Initiator can continue, abort, or restart the handshake Based on these lists, the Initiator can continue, abort, or restart
with a different selection of cryptographic algorithms. the handshake 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 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 of the final session key. The packet is authenticated by only half of the final session key. The packet is authenticated by
the 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
skipping to change at page 27, line 4 skipping to change at page 27, line 4
(i.e., during an opportunistic handshake), the Responder chooses its (i.e., during an opportunistic handshake), the Responder chooses its
HOST_ID according to the Initiator's employed DH group as indicated HOST_ID according to the Initiator's employed DH group as indicated
in the received DH_GROUP_LIST parameter and sets the source HIT in in the received DH_GROUP_LIST parameter and sets the source HIT in
the R1 packet accordingly. If the Responder however does not support the R1 packet accordingly. If the Responder however does not support
the DH group required by the Initiator or if the Responder HIT in the the DH group required by the Initiator or if the Responder HIT in the
I1 packet does not match the required DH group, the Responder selects I1 packet does not match the required DH group, the Responder selects
the mutually preferred and supported DH group based on the the mutually preferred and supported DH group based on the
DH_GROUP_LIST parameter in the I1 packet. The Responder then DH_GROUP_LIST parameter in the I1 packet. The Responder then
includes the corresponding ECDH key in the HOST_ID parameter. This includes the corresponding ECDH key in the HOST_ID parameter. This
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 R1 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. The different format types are DEFAULT, ESP and payload protection. The different format types are DEFAULT, ESP and
ESP-TCP as explained in Section 3.1 in [RFC6261]. ESP-TCP as explained in Section 3.1 in [RFC6261].
skipping to change at page 30, line 4 skipping to change at page 30, line 4
Initiator MUST validate the HIP_MAC parameter. Initiator MUST validate the HIP_MAC parameter.
5.4. ICMP Messages 5.4. ICMP Messages
When a HIP implementation detects a problem with an incoming packet, When a HIP implementation detects a problem with an incoming packet,
and it either cannot determine the identity of the sender of the and it either cannot determine the identity of the sender of the
packet or does not have any existing HIP association with the sender packet or does not have any existing HIP association with the sender
of the packet, it MAY respond with an ICMP packet. Any such reply of the packet, it MAY respond with an ICMP packet. Any such reply
MUST be rate-limited as described in [RFC4443]. In most cases, the MUST be rate-limited as described in [RFC4443]. In most cases, the
ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for
ICMPv6), with the Pointer field pointing to the field that caused the ICMPv6) and Code of 0. The Pointer field pointing to the field that
ICMP message to be generated. The problem cases specified in caused the ICMP message to be generated, for example to the first 8
Section 5.4. of [RFC7401] also apply to HIP DEX. bytes of a UDP payload for "SPI is Unknown". The problem cases
specified in Section 5.4. of [RFC7401] also apply to HIP DEX.
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]).
skipping to change at page 32, line 28 skipping to change at page 32, line 28
The keys derived for the Pair-wise Key SA are not used during the HIP The keys derived for the Pair-wise Key SA are not used during the HIP
DEX handshake. Instead, these keys are made available as payload DEX handshake. Instead, these keys are made available as payload
protection keys (e.g., for IPsec). Some payload protection protection keys (e.g., for IPsec). Some payload protection
mechanisms have their own Key Derivation Function, and if so this mechanisms have their own Key Derivation Function, and if so this
mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST
be used to derive the keys of the Pair-wise Key SA based on the be used to derive the keys of the Pair-wise Key SA based on the
concatenation of the random values that are contained in the concatenation of the random values that are contained in the
exchanged ENCRYPTED_KEY parameters. exchanged ENCRYPTED_KEY parameters.
The HIP DEX KEYMAT process is based on the is the Hash-based Key The HIP DEX KEYMAT process is based on the Hash-based Key Derivation
Derivation Function (HKDF) defined in [RFC5869] and consists of two Function (HKDF) defined in [RFC5869] and consists of two components,
components, CKDF-Extract and CKDF-Expand. The CKDF-Extract function CKDF-Extract and CKDF-Expand. The CKDF-Extract function compresses a
compresses a non-uniformly distributed key, such as the output of a non-uniformly distributed key, such as the output of a Diffie-Hellman
Diffie-Hellman key derivation, to extract the key entropy into a key derivation, to extract the key entropy into a fixed length
fixed length output. The CKDF-Expand function takes either the output. The CKDF-Expand function takes either the output of the
output of the Extract function or directly uses a uniformly Extract function or directly uses a uniformly distributed key and
distributed key and expands the length of the key, repeatedly expands the length of the key, repeatedly distributing the key
distributing the key entropy, to produce the keys needed. entropy, to produce the keys needed.
The key derivation for the Master Key SA employs always both the The key derivation for the Master Key SA employs always both the
Extract and Expand phases. The Pair-wise Key SA needs only the Extract and Expand phases. The Pair-wise Key SA needs only the
Extract phase when the key is smaller or equal to 128 bits, but Extract phase when the key is smaller or equal to 128 bits, but
otherwise requires also the Expand phase. otherwise 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
skipping to change at page 45, line 51 skipping to change at page 45, line 51
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 both the Master and Pair-wise Key SAs
quality of the random keying material generated by the Initiator is based on the quality of the random keying material generated by
and the Responder. As either peer may be a sensor or an actuator the Initiator and the Responder. As either peer may be a sensor
device, there is a natural concern about the quality of its random or an actuator device, there is a natural concern about the
number generator. quality of its random number generator. Thus at least a CSPRNG
SHOULD be used.
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 previous HIP Consequently, if an HI is compromised, all previous HIP
connections protected with that HI are compromised as explained in connections protected with that HI are compromised as explained in
Section 1. Section 1.
o The puzzle mechanism using CMAC explained in Section 4.1.1 may o The puzzle mechanism using CMAC explained in Section 4.1.1 may
need further study regarding the level of difficulty in order to need further study regarding the level of difficulty in order to
establish best practices with current generation of constrained establish best practices with current generation of constrained
devices. devices.
skipping to change at page 47, line 35 skipping to change at page 47, line 36
show that it can be used on very constrained hardware. The over-the- show that it can be used on very constrained hardware. The over-the-
air and storage costs for EC25519 are also closely comparable with air and storage costs for EC25519 are also closely comparable with
SECP160R1. SECP160R1.
Thus the security risk of the weak SECP160R1 must be shown to be of Thus the security risk of the weak SECP160R1 must be shown to be of
value over any slight costs of using EC25519 instead. value over any slight costs of using EC25519 instead.
9.2. Need to Validate Public Keys 9.2. Need to Validate Public Keys
With the curves specified here, there is a straightforward key With the curves specified here, there is a straightforward key
extraction attack, which is a very serious problem the use of static extraction attack, which is a very serious problem with the use of
keys by HIP-DEX. Thus it is MANDATORY to validate the peer's Public static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's
Key. Public Key.
For the curve SECP160R1, peers MUST validate each other's public For the curve SECP160R1, peers MUST validate each other's public
value Q by ensuring that the point is a valid point on the elliptic value Q by ensuring that the point is a valid point on the elliptic
curve. This process consists of three steps: (1) verify that Q is curve. This process consists of three steps: (1) verify that Q is
not the point at infinity (O), (2) verify that for Q = (x, y) both not the point at infinity (O), (2) verify that for Q = (x, y) both
integers x and y are in the correct interval, and (3) ensure that (x, integers x and y are in the correct interval, and (3) ensure that (x,
y) is a correct solution to the elliptic curve equation. For this y) is a correct solution to the elliptic curve equation. For this
curve, implementors do not need to verify membership in the correct curve, implementors do not need to verify membership in the correct
subgroup. subgroup.
skipping to change at page 49, line 16 skipping to change at page 49, line 16
12. 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.
12.1. Changes in draft-ietf-hip-dex-12 and 13 12.1. Changes in draft-ietf-hip-dex-14
o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment
12.2. Changes in draft-ietf-hip-dex-12 and 13
o Nits from Jeff Ahrenholz (including some formatting issues) o Nits from Jeff Ahrenholz (including some formatting issues)
12.2. Changes in draft-ietf-hip-dex-11 and 12 12.3. Changes in draft-ietf-hip-dex-11 and 12
o Included more precise references to the IANA subregistries o Included more precise references to the IANA subregistries
o Addressed GEN-ART feedback from Francis Dupont o Addressed GEN-ART feedback from Francis Dupont
o Added reasoning for PFS in a separate section, and it is mentioned o Added reasoning for PFS in a separate section, and it is mentioned
also in the abstract and intro. also in the abstract and intro.
o Donald Eastlake's (secdir) nits addressed o Donald Eastlake's (secdir) nits addressed
o Resolved IANA nits from Amanda Baber. o Resolved IANA nits from Amanda Baber.
o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (Section 9.1), "Need to Validate Public Keys" Considered Unsafe" (Section 9.1), "Need to Validate Public Keys"
(Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.3. Changes in draft-ietf-hip-dex-11 12.4. Changes in draft-ietf-hip-dex-11
o Update IANA considerations as requested by Eric Envyncke o Update IANA considerations as requested by Eric Envyncke
12.4. Changes in draft-ietf-hip-dex-10 12.5. Changes in draft-ietf-hip-dex-10
o Explanations on why the document includes so many SHOULDs o Explanations on why the document includes so many SHOULDs
12.5. Changes in draft-ietf-hip-dex-09 12.6. Changes in draft-ietf-hip-dex-09
o Fixed values for o Fixed values for
* DH_GROUP_LIST * DH_GROUP_LIST
* HIT_SUITE_LIST * HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.6. Changes in draft-ietf-hip-dex-05 12.7. Changes in draft-ietf-hip-dex-05
o Clarified main differences between HIP BEX and HIP DEX in o Clarified main differences between HIP BEX and HIP DEX in
Section 1. Section 1.
o Addressed MitM attack in Section 8. o Addressed MitM attack in Section 8.
o Minor editorial changes. o Minor editorial changes.
12.7. Changes in draft-ietf-hip-dex-04 12.8. Changes in draft-ietf-hip-dex-04
o Added new paragraph on rekeying procedure with HIP DEX. o Added new paragraph on rekeying procedure with HIP DEX.
o Updated references. o Updated references.
o Editorial changes. o Editorial changes.
12.8. Changes in draft-ietf-hip-dex-03 12.9. Changes in draft-ietf-hip-dex-03
o Added new section on HIP DEX/HIPv2 interoperability o Added new section on HIP DEX/HIPv2 interoperability
o Added reference to RFC4493 for CMAC. o Added reference to RFC4493 for CMAC.
o Added reference to RFC5869 for CKDF. o Added reference to RFC5869 for CKDF.
o Added processing of NOTIFY message in I2-SENT of state diagram. o Added processing of NOTIFY message in I2-SENT of state diagram.
o Editorial changes. o Editorial changes.
12.9. Changes in draft-ietf-hip-dex-02 12.10. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.10. Changes in draft-ietf-hip-dex-01 12.11. Changes in draft-ietf-hip-dex-01
o Added the new ECDH groups of Curve25519 and Curve448 from RFC o Added the new ECDH groups of Curve25519 and Curve448 from RFC
7748. 7748.
12.11. Changes in draft-ietf-hip-dex-00 12.12. 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.
12.12. Changes in draft-moskowitz-hip-rg-dex-06 12.13. 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.
12.13. Changes in draft-moskowitz-hip-dex-00 12.14. 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.
12.14. Changes in draft-moskowitz-hip-dex-01 12.15. 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 use puzzle difficulty of zero under normal network o Clarify use puzzle difficulty of zero under normal network
skipping to change at page 52, line 5 skipping to change at page 52, 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.
12.15. Changes in draft-moskowitz-hip-dex-02 12.16. 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.
12.16. Changes in draft-moskowitz-hip-dex-03 12.17. 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.
12.17. Changes in draft-moskowitz-hip-dex-04 12.18. 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.
 End of changes. 40 change blocks. 
103 lines changed or deleted 120 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/