draft-ietf-hip-dex-20.txt   draft-ietf-hip-dex-21.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: November 22, 2020 Hirschmann Automation and Control Expires: January 9, 2021 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
May 21, 2020 July 8, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-20 draft-ietf-hip-dex-21
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 November 22, 2020. This Internet-Draft will expire on January 9, 2021.
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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 15 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 15
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 19 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 19
4.1.4. User Data Considerations . . . . . . . . . . . . . . 20 4.1.4. User Data Considerations . . . . . . . . . . . . . . 20
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 20 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 20 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 23 skipping to change at page 3, line 23
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43
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
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47 9.1. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 47
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 49 12.1. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 49
12.2. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 49 12.2. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 50
12.3. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 50 12.3. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 50
12.4. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 50 12.4. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 50
12.5. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 50 12.5. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 50
12.6. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 50 12.6. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 50
12.7. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50 12.7. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 51
12.8. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50 12.8. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 51
12.9. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50 12.9. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 51
12.10. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 51 12.10. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 51
12.11. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 51 12.11. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 51
12.12. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 51
12.13. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51 12.13. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 51
12.14. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51 12.14. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 52
12.15. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51 12.15. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 52
12.16. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 52 12.16. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 52
12.17. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 52 12.17. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 52
12.18. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 52 12.18. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 52
12.19. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 52 12.19. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 52
12.20. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52 12.20. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 53
12.21. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52 12.21. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 53
12.22. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 53 12.22. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 53
12.23. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53 12.23. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 54
12.24. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53 12.24. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 54
12.25. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 54
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 57 HIP DEX handshake . . . . . . . . . . . . . . . . . 58
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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 is derived from the Base EXchange (BEX) of the Host DEX). HIP DEX is derived from the Base EXchange (BEX) of the Host
Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the
protocol semantics as well as the general packet structure of HIPv2. protocol semantics as well as the general packet structure of HIPv2.
Hence, it is recommended that [RFC7401] is well-understood before Hence, it is recommended that [RFC7401] is well-understood before
reading this document. reading this document.
skipping to change at page 4, line 50 skipping to change at page 5, line 5
removal of the ephemeral Diffie-Hellman key agreement. As this removal of the ephemeral Diffie-Hellman key agreement. As this
weakens the security properties of HIP DEX, it MUST be used only weakens the security properties of HIP DEX, it MUST be used only
with constrained devices where this is prohibitively expensive as with constrained devices where this is prohibitively expensive as
further explained in Section 1.2. further explained in Section 1.2.
3. HIP DEX forfeits the use of digital signatures with the removal 3. HIP DEX forfeits the use of digital signatures with the removal
of a hash function. Peer authentication with HIP DEX, therefore, of a hash function. Peer authentication with HIP DEX, therefore,
is based on the use of the ECDH derived key in the HIP_MAC is based on the use of the ECDH derived key in the HIP_MAC
parameter. parameter.
4. With HIP DEX, the ECDH derived key is only used to protect HIP 4. The forfeiture of the use of digital signatures leaves the R1
packet open to a MITM attack. Such an attack is managed in the
R2 packet validation and is yet another DOS attack mitigated
through the HIP state machine.
5. With HIP DEX, the ECDH derived key is only used to protect HIP
packets. Separate session key(s) are used to protect the packets. Separate session key(s) are used to protect the
transmission of upper layer protocol data. These session key(s) transmission of upper layer protocol data. These session key(s)
are established via a new secret exchange during the handshake. are established via a new secret exchange during the handshake.
5. HIP DEX introduces a new, optional retransmission strategy that 6. HIP DEX introduces a new, optional retransmission strategy that
is specifically designed to handle potentially extensive is specifically designed to handle potentially extensive
processing times of the employed cryptographic operations on processing times of the employed cryptographic operations on
computationally constrained devices. computationally constrained devices.
By eliminating the need for public-key signatures and the ephemeral By eliminating the need for public-key signatures and the ephemeral
DH key agreement, HIP DEX reduces the computational, energy, DH key agreement, HIP DEX reduces the computational, energy,
transmission, and memory requirements for public-key cryptography transmission, and memory requirements for public-key cryptography
(see [LN08]) in the HIPv2 protocol design. This makes HIP DEX (see [LN08]) in the HIPv2 protocol design. This makes HIP DEX
especially suitable for constrained devices as defined in [RFC7228]. especially suitable for constrained devices as defined in [RFC7228].
skipping to change at page 6, line 47 skipping to change at page 7, line 5
significant energy (i.e., battery resources). Even the ECDH significant energy (i.e., battery resources). Even the ECDH
multiplication for the HIP DEX static-static key exchange takes 8-9 multiplication for the HIP DEX static-static key exchange takes 8-9
seconds, again with measurable energy consumption. The ECDH seconds, again with measurable energy consumption. The ECDH
multiplication resource consumption via a static EC25519 keypair is multiplication resource consumption via a static EC25519 keypair is
tolerable as a one-time event during provisioning, but would render tolerable as a one-time event during provisioning, but would render
the protocol unsuitable for use on these devices if it was required the protocol unsuitable for use on these devices if it was required
to be a recurring part of the protocol. Further, for devices to be a recurring part of the protocol. Further, for devices
constrained in this manner, a FS-enabled protocol's cost will likely constrained in this manner, a FS-enabled protocol's cost will likely
provide little gain. Since the resulting "FS" key, likely produced provide little gain. Since the resulting "FS" key, likely produced
during device deployment, would typically end up being used for the during device deployment, would typically end up being used for the
remainder of the device's lifetime. remainder of the device's lifetime. Since this key (or the
information needed to regenerate it) persists for the device's
lifetime, the key step of 'throw away old keys' in achieving forward
secrecy does not occur, thus the forward secrecy would not be
obtained in practice.
With such a usage pattern, the inherent benefit of ephemeral keys is With such a usage pattern, the inherent benefit of ephemeral keys is
not realized. The security properties of such usage are very similar not realized. The security properties of such usage are very similar
to those of using a statically provisioned symmetric pre-shared key, to those of using a statically provisioned symmetric pre-shared key,
in that there remains a single PSK in static storage that is in that there remains a single PSK in static storage that is
susceptible to exfiltration/compromise, and compromise of that key in susceptible to exfiltration/compromise, and compromise of that key in
effect compromises the entire protocol for that node. HIP DEX effect compromises the entire protocol for that node. HIP DEX
achieves marginally better security properties by computing the achieves marginally better security properties by computing the
effective long-term PSK from a DH exchange, so that the provisioning 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 service is not required to be part of the risk surface due to also
skipping to change at page 9, line 43 skipping to change at page 10, line 12
handshake. This role is typically forgotten once the handshake is handshake. This role is typically forgotten once the handshake is
completed. completed.
RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message redefined as CMAC. Still, note that CMAC is a message
authentication code (MAC) and not a cryptographic hash function. authentication code (MAC) and not a cryptographic hash function.
Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where
RHASH is used. Moreover, RHASH has different security properties RHASH is used. Moreover, RHASH has different security properties
in HIP DEX and is not used for HIT generation. in HIP DEX and is not used for HIT generation.
Secure Association (SA): An SA is a simplex "connection" that Security Association (SA): An SA is a simplex "connection" that
affords security services to the traffic carried by it. HIP DEX affords security services to the traffic carried by it. HIP DEX
has two forms of SAs, a Master Key SA for the actual HIP traffic, has two forms of SAs, a Master Key SA for the actual HIP traffic,
and a Pair-wise Key SA for use by a data transport service. and a Pair-wise Key SA for use by a data transport service.
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
skipping to change at page 10, line 25 skipping to change at page 10, line 43
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 use an unverified HIT as input. The full HI
of a host SHOULD be considered (see Section 7.1). of a host SHOULD be considered, and the HIT MAY be used as a hint for
locating the full HI (see Section 7.1).
Carrying HIs or 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
skipping to change at page 22, line 6 skipping to change at page 22, line 6
Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to: to:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) AES-128-CTR TBD4 (suggested: 5) ([RFC3686])
Mandatory implementation: AES-128-CTR. Mandatory implementation: AES-128-CTR.
The initialization vector (IV) counter for AES-128-CTR MUST have a The counter for AES-128-CTR MUST have a length of 128 bits. The
length of 128 bits. The puzzle value #I and the puzzle solution #J puzzle value #I and the puzzle solution #J (see Section 4.1.2 in
(see Section 4.1.2 in [RFC7401]) are used to construct the high-order [RFC7401]) are used to construct the initialization vector (IV) as
bits of the IV. The IV is computed as FOLD(I | J, 112) plus a 16 bit FOLD(I | J, 112) which are the high-order bits of the CTR counter. A
counter value, which is initialized to zero on first use, appended to 16 bit value as a block counter, which is initialized to zero on
the Fold value in order to guarantee that a non-repeating nonce is first use, is appended to the IV in order to guarantee that a non-
fed to the AES-CTR encryption algorithm. repeating nonce is fed to the AES-CTR encryption algorithm.
This IV counter is incremented as it is used for all encrypted HIP This counter is incremented as it is used for all encrypted HIP
parameters. That is a single AES-129-CTR counter associated with the parameters. That is a single AES-129-CTR counter associated with the
Master Key SA. Master Key SA.
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. The HOST_ID parameter is defined optional information about a host. The HOST_ID parameter is defined
in Section 5.2.9 of [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
skipping to change at page 40, line 9 skipping to change at page 40, line 9
implementation dependent. See Appendix A in [RFC7401] for a implementation dependent. See Appendix A in [RFC7401] for a
description of an example implementation. description of an example implementation.
2. The system MUST check that the Responder's HIT corresponds to 2. The system MUST check that the Responder's HIT corresponds to
one of its own HITs and MUST drop the packet otherwise. one of its own HITs and MUST drop the packet otherwise.
3. The system MUST further check that the Initiator's HIT Suite is 3. The system MUST further check that the Initiator's HIT Suite is
supported. The Responder SHOULD silently drop I2 packets with supported. The Responder SHOULD silently drop I2 packets with
unsupported Initiator HITs. unsupported Initiator HITs.
4. The system MUST validate the Initiator's HI per Section 9.1. 4. The system MUST validate the Initiator's HI per Section 9.2.
5. If the system's state machine is in the R2-SENT state, the 5. If the system's state machine is in the R2-SENT state, the
system MUST check to see if the newly received I2 packet is system MUST check to see if the newly received I2 packet is
similar to the one that triggered moving to R2-SENT. If so, it similar to the one that triggered moving to R2-SENT. If so, it
MUST retransmit a previously sent R2 packet and reset the MUST retransmit a previously sent R2 packet and reset the
R2-SENT timer. The system SHOULD re-use the previously R2-SENT timer. The system SHOULD re-use the previously
established state to re-create the corresponding R2 packet in established state to re-create the corresponding R2 packet in
order to prevent unnecessary computation overhead. order to prevent unnecessary computation overhead.
6. If the system's state machine is in the I2-SENT state, the 6. If the system's state machine is in the I2-SENT state, the
skipping to change at page 43, line 5 skipping to change at page 43, line 5
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. transition to the I2-SENT state.
3. The system MUST verify the HIP_MAC according to the procedures in 3. The system MUST verify the HIP_MAC according to the procedures in
Section 6.2. Section 6.2.
4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER,
HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2
packet and compare the results against the chosen suites. packet and compare the results against the chosen suites.
5. The system MUST validate the Responder's HI per Section 9.1. 5. The system MUST validate the Responder's HI per Section 9.2.
6. If any of the checks above fail, there is a high probability of 6. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy. system SHOULD act accordingly, based on its local policy.
7. The system MUST decrypt the keying material from the 7. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial input ENCRYPTED_KEY parameter. This keying material is a partial input
to the key derivation process for the Pair-wise Key SA (see to the key derivation process for the Pair-wise Key SA (see
Section 6.3). Section 6.3).
skipping to change at page 47, line 46 skipping to change at page 47, line 46
Section 5.3.1 mentions that implementations need to be able to handle 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- storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre-
computed in HIP DEX and also the state machine does not include an computed in HIP DEX and also the state machine does not include an
"R1_SENT" state (that would enable caching of R1 packets). "R1_SENT" state (that would enable caching of R1 packets).
Therefore, an implementation has to cache information (e.g., at least Therefore, an implementation has to cache information (e.g., at least
the HITs) from incoming I1 packets and rate control the incoming I1 the HITs) from incoming I1 packets and rate control the incoming I1
packets to avoid unnecessary packet processing during I1 packet packets to avoid unnecessary packet processing during I1 packet
storms. storms.
9.1. Need to Validate Public Keys 9.1. Use of AES-CTR for HIP Parameter Encryption
AES-CTR is a basic cipher mode that does not accept an initialization
vector to allow for key re-use. In essence, it stretches the initial
key into a much longer keystream (akin to a stream cipher) that is
used like a one-time pad. Any reuse of that keystream breaks the
confidentiality of the protected data, so when using AES-CTR, care
must be taken to ensure that within a given keystream the counter
value is never reused, and that any given key is only used to
generate a single keystream. The integration of AES-CTR into IPsec
ESP (RFC 3686) used by HIP (and, thus, by HIP-DEX) improves on the
situation by partitioning the 128-bit counter space into a 32-bit
nonce, 64-bit IV, and 32-bits of counter. The counter is incremented
to provide a keystream for protecting a given packet, the IV is
chosen by the encryptor in a "manner that ensures uniqueness", and
the nonce persists for the lifetime of a given SA. In particular, in
this usage the nonce must be unpredictable, not just single-use. In
HIP-DEX, the properties of nonce uniqueness/unpredictability and per-
packet IV uniqueness are defined in Section 5.2.2.
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 with the use of extraction attack, which is a very serious problem with the use of
static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's
Public Key. Public Key.
With the NIST curves, there are no internal length markers, so each With the NIST curves, there are no internal length markers, so each
number representation occupies as many octets as implied by the curve number representation occupies as many octets as implied by the curve
parameters. For P-256, this means that each of X and Y use 32 parameters. For P-256, this means that each of X and Y use 32
octets, padded on the left by zeros if necessary. For P-384, they octets, padded on the left by zeros if necessary. For P-384, they
skipping to change at page 49, line 28 skipping to change at page 49, line 48
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-20 12.1. Changes in draft-ietf-hip-dex-21
o Clarified text on AES-CTR for HIP parameter encryption. o Clarified on security concerns of using AES-CTR in Section 9.1
o Edits for SECDIR comments
12.2. Changes in draft-ietf-hip-dex-20
o Clarified text on AES-CTR for HIP parameter encryption. This
includes Section 9.1
o Clarified text on R2 processing to validate content of R1. o Clarified text on R2 processing to validate content of R1.
o Clarified Applicability section. o Clarified Applicability section.
o Expanded Fig 1. o Expanded Fig 1.
o Clarified differences between BEX and DEX state machines. o Clarified differences between BEX and DEX state machines.
o ESP transform is MTI and ESP-TCP is Experimental. o ESP transform is MTI and ESP-TCP is Experimental.
12.2. Changes in draft-ietf-hip-dex-19 12.3. Changes in draft-ietf-hip-dex-19
o Replaced reference to RFC4493 for CMAC with NIST SP800-38B. o Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
o Remove NIST P-521 from DH_GROUP_LIST. o Remove NIST P-521 from DH_GROUP_LIST.
o Remove NULL-ENCRYPT. o Remove NULL-ENCRYPT.
o Added reference to rfc8005 for HIT lookup in DNS. o Added reference to rfc8005 for HIT lookup in DNS.
o Remove setting Control bit: A. o Remove setting Control bit: A.
o Many textual improvements per Benjamin Kaduk comments. o Many textual improvements per Benjamin Kaduk comments.
12.3. Changes in draft-ietf-hip-dex-18 12.4. Changes in draft-ietf-hip-dex-18
o Changed Perfect Forward Secrecy to Forward Secrecy. o Changed Perfect Forward Secrecy to Forward Secrecy.
12.4. Changes in draft-ietf-hip-dex-17 12.5. Changes in draft-ietf-hip-dex-17
o Added hex values for strings CKDF-Extract and CKDF-Expand. o Added hex values for strings CKDF-Extract and CKDF-Expand.
o Replace Perfect Forward Secrecy with Forward Secrecy. o Replace Perfect Forward Secrecy with Forward Secrecy.
12.5. Changes in draft-ietf-hip-dex-16 12.6. Changes in draft-ietf-hip-dex-16
o Remove old placeholder text. o Remove old placeholder text.
o Remove SECP160R1. Experience has shown EC25519 performance equal o Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it. enough to not need it.
12.6. Changes in draft-ietf-hip-dex-15 12.7. Changes in draft-ietf-hip-dex-15
o Added Public Key validation in I2 and R2 processing. o Added Public Key validation in I2 and R2 processing.
o Added ACL processing (Section 7.1). o Added ACL processing (Section 7.1).
o Added IANA instructions for DH_GROUP_LIST. o Added IANA instructions for DH_GROUP_LIST.
12.7. Changes in draft-ietf-hip-dex-14 12.8. Changes in draft-ietf-hip-dex-14
o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment comment
12.8. Changes in draft-ietf-hip-dex-12 and 13 12.9. 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.9. Changes in draft-ietf-hip-dex-11 and 12 12.10. 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 FS in a separate section, and it is mentioned o Added reasoning for FS 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" (removed in ver 16), "Need to Validate Public Considered Unsafe" (removed in ver 16), "Need to Validate Public
Keys" (Section 9.1), and "I_NONCE" (Section 5.2.6) to address Eric Keys" (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.10. Changes in draft-ietf-hip-dex-11 12.11. 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.11. Changes in draft-ietf-hip-dex-10 12.12. 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.12. Changes in draft-ietf-hip-dex-09 12.13. 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.13. Changes in draft-ietf-hip-dex-05 12.14. 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.14. Changes in draft-ietf-hip-dex-04 12.15. 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.15. Changes in draft-ietf-hip-dex-03 12.16. 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.16. Changes in draft-ietf-hip-dex-02 12.17. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.17. Changes in draft-ietf-hip-dex-01 12.18. 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.18. Changes in draft-ietf-hip-dex-00 12.19. 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.19. Changes in draft-moskowitz-hip-rg-dex-06 12.20. 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.20. Changes in draft-moskowitz-hip-dex-00 12.21. 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.21. Changes in draft-moskowitz-hip-dex-01 12.22. 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 53, line 19 skipping to change at page 54, line 5
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.22. Changes in draft-moskowitz-hip-dex-02 12.23. 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.23. Changes in draft-moskowitz-hip-dex-03 12.24. 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.24. Changes in draft-moskowitz-hip-dex-04 12.25. 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.
skipping to change at page 57, line 26 skipping to change at page 58, line 26
with the correct key. If verified successfully, the Responder with the correct key. If verified successfully, the Responder
proceeds with the handshake. Otherwise, it silently drops the I2 proceeds with the handshake. Otherwise, it silently drops the I2
packet. packet.
Note that there is no explicit signaling in the HIP DEX handshake for Note that there is no explicit signaling in the HIP DEX handshake for
this behavior. Thus, knowledge of two-factor authentication must be this behavior. Thus, knowledge of two-factor authentication must be
configured externally prior to the handshake. configured externally prior to the handshake.
Appendix B. IESG Considerations Appendix B. IESG Considerations
During IESG review, a concern was raised on the number of SHOULDS in During IESG review, a concern was raised on the number of SHOULDs in
this document. Here is an analysis of the 57 SHOULDS in HIP DEX. this document. Here is an analysis of the 57 SHOULDs in HIP DEX.
46 of SHOULDS are also in [RFC7401]. Here are the sections with 46 of SHOULDs are also in [RFC7401]. Here are the sections with
SHOULDS that match up with [RFC7401]: SHOULDs that match up with [RFC7401]:
5.2.2. HIP_CIPHER (same as 7401) 5.2.2. HIP_CIPHER (same as 7401)
6.5. Processing Incoming I1 Packets 6.5. Processing Incoming I1 Packets
3. (same as 7401) 3. (same as 7401)
5. (same as 7401) 5. (same as 7401)
6.6. Processing Incoming R1 Packets (same as 7401) 6.6. Processing Incoming R1 Packets (same as 7401)
6.7. Processing Incoming I2 Packets 6.7. Processing Incoming I2 Packets
skipping to change at page 58, line 28 skipping to change at page 59, line 28
6.8. Processing Incoming R2 Packets 6.8. Processing Incoming R2 Packets
5. (same as 7401) 5. (same as 7401)
6.9. Processing Incoming NOTIFY Packets 6.9. Processing Incoming NOTIFY Packets
1st para (same as 7401) 1st para (same as 7401)
6.11. Handling State Loss (same as 7401) 6.11. Handling State Loss (same as 7401)
7. HIP Policies (1st and 3rd same as 7401) 7. HIP Policies (1st and 3rd same as 7401)
Many of the other 11 SHOULDS are due to the nature of constrained Many of the other 11 SHOULDs are due to the nature of constrained
devices and in most cases the text points this out: devices and in most cases the text points this out:
In Section 4.1.1, this is clearly adjusting for how the puzzle could In Section 4.1.1, this is clearly adjusting for how the puzzle could
actually be an attack against a constrained device. Same situation actually be an attack against a constrained device. Same situation
in Section 5.3.2. in Section 5.3.2.
Section 6, clearly states that: Section 6, clearly states that:
it should be noted that many of the packet processing rules are it should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when denoted here with "SHOULD" but may be updated to "MUST" when
 End of changes. 50 change blocks. 
86 lines changed or deleted 124 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/