draft-ietf-hip-dex-22.txt   draft-ietf-hip-dex-23.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: 17 June 2021 Hirschmann Automation and Control Expires: 19 July 2021 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
14 December 2020 15 January 2021
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-22 draft-ietf-hip-dex-23
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) and DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and
specifically developed for use on low end processors. The HIP DEX specifically developed for use on low end processors. The HIP DEX
protocol design aims at reducing the overhead of the employed protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and cryptographic primitives by omitting public-key signatures and
cryptographic hash functions. cryptographic hash functions.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 17 June 2021. This Internet-Draft will expire on 19 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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) . . . . . . . . . . . . . . . 6 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 6
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 1.2.1. Partial Computational Cost of FS via SIGMA . . . . . 8
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 8 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 9
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 9
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 9
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 12 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 12
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 12 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 13
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 14
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 15 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 16
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 16 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 16
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 20 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 20
4.1.4. User Data Considerations . . . . . . . . . . . . . . 21 4.1.4. User Data Considerations . . . . . . . . . . . . . . 21
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 21 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 21 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 21
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 21 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 22 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 22
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 22 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 22
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 24 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 28 skipping to change at page 3, line 28
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 46 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 46
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 46 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 47 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 47
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 47 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 47
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9.1. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 50 9.1. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 50
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 50 9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 50
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 52 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 52 12.1. Changes in draft-ietf-hip-dex-23 . . . . . . . . . . . . 52
12.2. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 52 12.2. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 52
12.3. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 52 12.3. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 52
12.4. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 52 12.4. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 52
12.5. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 53 12.5. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 53
12.6. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 53 12.6. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 53
12.7. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 53 12.7. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 53
12.8. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 53 12.8. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 53
12.9. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 53 12.9. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 53
12.10. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 53 12.10. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 53
12.11. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 53 12.11. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 54
12.12. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 54 12.12. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 54
12.13. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 54 12.13. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 54
12.14. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 54 12.14. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 54
12.15. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 54 12.15. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 54
12.16. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 54 12.16. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 54
12.17. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 55 12.17. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 55
12.18. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 55 12.18. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 55
12.19. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 55 12.19. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 55
12.20. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 55 12.20. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 55
12.21. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 55 12.21. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 55
12.22. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 55 12.22. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 55
12.23. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 56 12.23. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 55
12.24. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 56 12.24. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 56
12.25. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 56 12.25. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 56
12.26. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 57 12.26. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 56
12.27. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 57
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 58 13.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Password-based two-factor authentication during the Appendix A. Calculating Collision Probabilities . . . . . . . . 60
HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Password-based two-factor authentication during the
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 61 HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Appendix C. IESG Considerations . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
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), specifically developed for use on low end processors that DEX), specifically developed for use on low end processors that
cannot support the cryptographic requirements of HIP BEX. HIP DEX is cannot support the cryptographic requirements of HIP Base EXchange
derived from the Base EXchange (BEX) of the Host Identity Protocol (HIP BEX). HIP DEX is derived from HIP BEX, which is defined in the
Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol Host Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX
semantics as well as the general packet structure of HIPv2. Hence, preserves the protocol semantics as well as the general packet
it is recommended that [RFC7401] is well-understood before reading structure of HIPv2. Hence, it is recommended that [RFC7401] is well-
this document. understood before reading this document.
The main differences between HIP BEX and HIP DEX are: The main differences between HIP BEX and HIP DEX are:
1. HIP DEX uses a different set of cryptographic primitives compared 1. HIP DEX uses a different set of cryptographic primitives compared
to HIP BEX with the goal to reduce the protocol overhead: to HIP BEX with the goal to reduce the protocol overhead:
* Peer authentication and key agreement in HIP DEX are based on * Peer authentication and key agreement in HIP DEX are based on
static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This
replaces the use of public-key signatures and ephemeral replaces the use of public-key signatures and ephemeral
Diffie-Hellman key pairs in HIPv2. Diffie-Hellman key pairs in HIPv2.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 CMAC-based is based on the use of the ECDH derived key in the CMAC-based
HIP_MAC parameter. HIP_MAC parameter.
4. The forfeiture of the use of digital signatures leaves the R1 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 packet open to a MITM attack. Such an attack is managed in the
R2 packet validation and is yet another DOS attack mitigated R2 packet validation and is yet another DOS attack mitigated
through the HIP state machine. This state machine mitigation is through the HIP state machine. This state machine mitigation is
augmented by HIT,HI ACL controls. augmented by HIT,HI ACL controls, Section 7.1.
5. The forfeiture of a cryptographic hash leaves the HIT generated 5. The forfeiture of a cryptographic hash leaves the HIT generated
by a fold function vulnerable to pre-image attacks. This MUST be by a fold function vulnerable to pre-image attacks. This MUST be
mitigated through a HIT,HI pairing as in an ACL control mechanism mitigated through a HIT,HI pairing as in an ACL control mechanism
Section 7.1. Section 7.1.
6. With HIP DEX, the ECDH derived key is only used to protect HIP 6. 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.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
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].
Cryptographic hashing was eliminated due to the memory/code space or Cryptographic hashing was eliminated due to the memory/code space or
gate cost for a hash. This is based on actual implementation efforts gate cost for a hash. This is based on actual implementation efforts
on 8-bit cpu sensors with 16KB memory and 64KB flash for code. on 8-bit CPU sensors with 16KB memory and 64KB flash for code.
This document focuses on the protocol specifications related to This document focuses on the protocol specifications related to
differences between HIP BEX and HIP DEX. Where differences are not differences between HIP BEX and HIP DEX. Where differences are not
called out explicitly, the protocol specification of HIP DEX is the called out explicitly, the protocol specification of HIP DEX is the
same as defined in [RFC7401]. same as defined in [RFC7401].
1.1. The HIP Diet EXchange (DEX) 1.1. The HIP Diet EXchange (DEX)
The HIP Diet EXchange is a two-party cryptographic protocol used to The HIP Diet EXchange is a two-party cryptographic protocol used to
establish a secure communication context between hosts. The first establish a secure communication context between hosts. The first
skipping to change at page 6, line 23 skipping to change at page 6, line 23
handshake packet. The parties then authenticate each other in the I2 handshake packet. The parties then authenticate each other in the I2
and R2 handshake packets based on the ECDH-derived keying material. and R2 handshake packets based on the ECDH-derived keying material.
The Initiator and the Responder additionally transmit keying material The Initiator and the Responder additionally transmit keying material
for the session key in these last two handshake packets (I2 and R2). for the session key in these last two handshake packets (I2 and R2).
This is to prevent overuse of the static ECDH-derived keying This is to prevent overuse of the static ECDH-derived keying
material. Moreover, the Responder starts a puzzle exchange in the R1 material. Moreover, the Responder starts a puzzle exchange in the R1
packet and the Initiator completes this exchange in the I2 packet packet and the Initiator completes this exchange in the I2 packet
before the Responder performs computationally expensive operations or before the Responder performs computationally expensive operations or
stores any state from the exchange. Given this handshake structure, stores any state from the exchange. Given this handshake structure,
HIP DEX operationally is very similar to HIP BEX. Moreover, the HIP DEX operationally is very similar to HIP BEX. Moreover, the
employed model is also fairly equivalent to 802.11-2007 employed model is also fairly equivalent to 802.11-2016
[IEEE.802-11.2016] Master Key and Pair-wise Transient Key, but [IEEE.802-11.2016] Master Key and Pair-wise Transient Key, but
handled in a single exchange. handled in a single exchange.
HIP DEX does not have the option to encrypt the Host Identity of the HIP DEX does not have the option to encrypt the Host Identity of the
Initiator in the I2 packet. The Responder's Host Identity also is Initiator in the I2 packet. The Responder's Host Identity also is
not protected. Thus, contrary to HIPv2, HIP DEX does not provide for not protected. Thus, contrary to HIPv2, HIP DEX does not provide for
end-point anonymity and any signaling (i.e., HOST_ID parameter end-point anonymity and any signaling (i.e., HOST_ID parameter
contained with an ENCRYPTED parameter) that indicates such anonymity contained with an ENCRYPTED parameter) that indicates such anonymity
should be ignored. should be ignored.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
It is inevitable that both HIP BEX and DEX will be available on some It is inevitable that both HIP BEX and DEX will be available on some
systems, most noticeably sensor gateways. HIP DEX MUST NOT be used systems, most noticeably sensor gateways. HIP DEX MUST NOT be used
between systems capable of HIP BEX. This may be controlled by between systems capable of HIP BEX. This may be controlled by
limiting the use of DEX to an "internal" interface, or for such limiting the use of DEX to an "internal" interface, or for such
systems to first offer a BEX HIT in an I1 and only if that fails to systems to first offer a BEX HIT in an I1 and only if that fails to
try a DEX HIT. Note that such a downgrade (from BEX to DEX) offer try a DEX HIT. Note that such a downgrade (from BEX to DEX) offer
approach is open to attack, requiring additional mitigation (e.g. approach is open to attack, requiring additional mitigation (e.g.
ACL controls). ACL controls).
1.2.1. Partial Computational Cost of FS via SIGMA
From the Initator's process, FS via SIGMA in HIP BEX on an 8-bit
sensor comes at a high cost. In BEX, the Initator has:
2 Public Key signing verifications,
1 Public Key signing,
1 Diffie-Hellman ephemeral keypair generation, and
1 Diffie-Hellman shared secret generation.
Whereas HIP DEX only has the Diffie-Hellman shared secret generation
cost.
Papers like [EfficientECC] show on the ATmega328P (clock rate of
7.37MHz) an EdDSA25519 signature generation of 19M cycles and
verification of 31M cycles. Thus the SIGMA Public Key operations
come at a cost of 81M cycles. Actual wallclock time and energy
consumption is not provided in this paper, nor is the Curve25519
keypair generation time.
This is just the cost of the Public Key operations, excluding
additional BEX over DEX processing. The added cost of HIP BEX (over
HIP DEX) has been a major barrier to adoption of SIGMA based key
establishment on 8-bit processors.
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,
security, and IANA considerations, respectively. Appendix A defines security, and IANA considerations, respectively. Appendix B defines
a two factor authentication scheme and Appendix B highlights some a two factor authentication scheme and Appendix C highlights some
discussions with the IESG. discussions with the IESG.
2. Terms, Notation and Definitions 2. Terms, Notation and Definitions
2.1. Requirements Terminology 2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 12, line 34 skipping to change at page 13, line 4
section. section.
3.2. Generating a HIT from an HI 3.2. Generating a HIT from an HI
The HIT does not follow the exact semantics of an ORCHID as there is The HIT does not follow the exact semantics of an ORCHID as there is
no hash function in HIP DEX. Still, its structure is strongly no hash function in HIP DEX. Still, its structure is strongly
aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2
is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used
for the four bits of the Orchid Generation Algorithm (OGA) field in for the four bits of the Orchid Generation Algorithm (OGA) field in
the ORCHID. The hash representation in an ORCHID is replaced with the ORCHID. The hash representation in an ORCHID is replaced with
FOLD(HI,96). FOLD((Context ID | HI),96) see Section 2.2 for the FOLD function.
The Context ID is the same as in HIP BEX, sec 3.2 RFC 7401 [RFC7401].
3.2.1. Why Introduce FOLD 3.2.1. Why Introduce FOLD
HIP DEX by design lacks a cryptographic hash function. The HIP DEX by design lacks a cryptographic hash function. The
generation of the HIT is one of the few places in the protocol where generation of the HIT is one of the few places in the protocol where
this presents a challenge. CMAC was first considered for this this presents a challenge. CMAC was first considered for this
purpose, but to use CMAC for HIT generation would require using a purpose, but to use CMAC for HIT generation would require using a
static key, either ZERO or some published value. NIST does not static key, either ZERO or some published value. NIST does not
consider CMAC an approved cryptographic hash as: consider CMAC an approved cryptographic hash as:
It is straightforward to demonstrate that CMAC is not collision- It is straightforward to demonstrate that CMAC is not collision-
resistant for any choice of a published key. resistant for any choice of a published key.
Since collision-resistance is not possible with the tools at hand, Since collision-resistance is not possible with the tools at hand,
any reasonable function (e.g. FOLD) that takes the full value of the any reasonable function (e.g. FOLD) that takes the full value of the
HI into generating the HIT can be used, provided that collision HI into generating the HIT can be used, provided that collision
detection is part of the HIP-DEX deployment design. This is achieved detection is part of the HIP-DEX deployment design. This is achieved
here through either an ACL or some other lookup process that here through either an ACL, Section 7.1, or some other lookup process
externally binds the HIT and HI. that externally binds the HIT and HI.
HIT collisions have always been a statistical possibility in BEX and Even without collision-resistance, it is not trivial to create
thus the HI has always been a part of the R1 and I2 packets for HI duplicate FOLD generated HITs, as FOLD is starting out with a random
validation. input (the HI). Although there is a set, {N}, of HIs that will have
duplicate FOLD HITs, even randomly generating duplicate HITs is
unlikely. Per Appendix A, 4T BEX HITs need be generated for a .01%
probability of a collision. The size of set above is not known, but
will not be large. In a test of 1M randomly generated FOLD HITs, no
duplicates were produced.
Note that HIT collisions have always been a statistical possibility
in BEX and thus the HI has always been a part of the R1 and I2
packets for HI validation.
4. Protocol Overview 4. Protocol Overview
This section gives a simplified overview of the HIP DEX protocol This section gives a simplified overview of the HIP DEX protocol
operation and does not contain all the details of the packet formats operation and does not contain all the details of the packet formats
or the packet processing steps. Section 5 and Section 6 describe or the packet processing steps. Section 5 and Section 6 describe
these aspects in more detail and are normative in case of any these aspects in more detail and are normative in case of any
conflicts with this section. Importantly, the information given in conflicts with this section. Importantly, the information given in
this section focuses on the differences between the HIPv2 and HIP DEX this section focuses on the differences between the HIPv2 and HIP DEX
protocol specifications. protocol specifications.
skipping to change at page 15, line 38 skipping to change at page 15, line 48
encrypt y encrypt y
R2: (DH, Suite, Trans) Lists, ENC(DH,y), R2: (DH, Suite, Trans) Lists, ENC(DH,y),
I_Nonce, mac I_Nonce, mac
<-------------------------------------- <--------------------------------------
check MAC check MAC
validate lists in R1 validate lists in R1
decrypt y decrypt y
Figure 1: Figure 1: High-level overview of the HIP Diet EXchange Figure 1: High-level overview of the HIP Diet EXchange
4.1.1. HIP Puzzle Mechanism 4.1.1. HIP Puzzle Mechanism
The purpose of the HIP puzzle mechanism is to protect the Responder The purpose of the HIP puzzle mechanism is to protect the Responder
from a number of denial-of-service threats. It allows the Responder from a number of denial-of-service threats. It allows the Responder
to delay state creation until receiving the I2 packet. Furthermore, to delay state creation until receiving the I2 packet. Furthermore,
the puzzle allows the Responder to use a fairly cheap calculation to the puzzle allows the Responder to use a fairly cheap calculation to
check that the Initiator is "sincere" in the sense that it has check that the Initiator is "sincere" in the sense that it has
churned enough CPU cycles in solving the puzzle. churned enough CPU cycles in solving the puzzle.
skipping to change at page 22, line 35 skipping to change at page 22, line 35
Group KDF Value Group KDF Value
Curve25519 [RFC7748] CKDF TBD7 (suggested value 12) Curve25519 [RFC7748] CKDF TBD7 (suggested value 12)
Curve448 [RFC7748] CKDF TBD8 (suggested value 13) Curve448 [RFC7748] CKDF TBD8 (suggested value 13)
The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748]. The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748].
These curves have cofactors of 8 and 4 (respectively). These curves have cofactors of 8 and 4 (respectively).
It is not known if Curve448 Diffie Hellman can meet the performance It is not known if Curve448 Diffie Hellman can meet the performance
requirements on 8-bit cpus. It is included for "completeness". An requirements on 8-bit CPUs. It is included for "completeness". An
implementor should ensure they can get the needed performance for implementor should ensure they can get the needed performance for
their target platform before committing to support this group. their target platform before committing to support this group.
5.2.2. HIP_CIPHER 5.2.2. HIP_CIPHER
The HIP_CIPHER parameter contains the list of supported cipher The HIP_CIPHER parameter contains the list of supported cipher
algorithms to be used for encrypting the contents of the ENCRYPTED algorithms to be used for encrypting the contents of the ENCRYPTED
and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in
Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to: to:
skipping to change at page 30, line 33 skipping to change at page 30, line 33
Initiator HIT. Initiator HIT.
The ENCRYPTED_KEY parameter contains an Initiator generated random The ENCRYPTED_KEY parameter contains an Initiator generated random
value that MUST be uniformly distributed. This random value is value that MUST be uniformly distributed. This random value is
encrypted with the Master Key SA using the HIP_CIPHER encryption encrypted with the Master Key SA using the HIP_CIPHER encryption
algorithm. algorithm.
The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque
data copied from the corresponding echo request parameter(s). This data copied from the corresponding echo request parameter(s). This
parameter can also be used for two-factor password authentication as parameter can also be used for two-factor password authentication as
shown in Appendix A. shown in Appendix B.
The TRANSPORT_FORMAT_LIST parameter contains the single transport The TRANSPORT_FORMAT_LIST parameter contains the single transport
format type selected by the Initiator. The chosen type MUST format type selected by the Initiator. The chosen type MUST
correspond to one of the types offered by the Responder in the R1 correspond to one of the types offered by the Responder in the R1
packet. The different format types are DEFAULT, ESP and ESP-TCP as packet. The different format types are DEFAULT, ESP and ESP-TCP as
explained in Section 3.1 in [RFC6261]. explained in Section 3.1 in [RFC6261].
The I_NONCE parameter contains the nonce, supplied by the Initiator The I_NONCE parameter contains the nonce, supplied by the Initiator
for the Master Key generation as shown in Section 6.3. This is for the Master Key generation as shown in Section 6.3. This is
echoed back to the Initiator in the R2 packet. echoed back to the Initiator in the R2 packet.
skipping to change at page 47, line 15 skipping to change at page 47, line 15
All HIP DEX implementations SHOULD provide for an Access Control List All HIP DEX implementations SHOULD provide for an Access Control List
(ACL), representing for which hosts they accept HIP diet exchanges, (ACL), representing for which hosts they accept HIP diet exchanges,
and the preferred transport format and local lifetimes. Wildcarding and the preferred transport format and local lifetimes. Wildcarding
SHOULD be supported for such ACLs. SHOULD be supported for such ACLs.
7.1. HIT/HI ACL 7.1. HIT/HI ACL
Both the Initiator and Responder SHOULD implement an ACL. Minimally, Both the Initiator and Responder SHOULD implement an ACL. Minimally,
these ACLs will be a list of trusted HIT/HIs. They may also contain these ACLs will be a list of trusted HIT/HIs. They may also contain
the password used in the password-based two-factor authentication the password used in the password-based two-factor authentication
(Appendix A) and preferred HIT Suite. (Appendix B) and preferred HIT Suite.
ACL processing is applied to all HIP packets. A HIP peer MAY reject ACL processing is applied to all HIP packets. A HIP peer MAY reject
any packet where the Receiver's HIT is not in the ACL. The HI (in any packet where the Receiver's HIT is not in the ACL. The HI (in
the R1, I2, and optionally NOTIFY packets) MUST be validated as well, the R1, I2, and optionally NOTIFY packets) MUST be validated as well,
when present in the ACL. This is the defense against collision and when present in the ACL. This is the defense against collision and
second-image attacks on the HIT generation. second-image attacks on the HIT generation.
Devices with no input mechanism (e.g. sensors) SHOULD accept R1 Devices with no input mechanism (e.g. sensors) SHOULD accept R1
packets from unknown HITs. These R1 packets SHOULD contain the start packets from unknown HITs. These R1 packets SHOULD contain the start
of the password-based two-factor authentication . If the R2 for this of the password-based two-factor authentication . If the R2 for this
skipping to change at page 52, line 14 skipping to change at page 52, line 14
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-22 12.1. Changes in draft-ietf-hip-dex-23
* Apply editorial comment from Eric Vyncke
* Added concatenating Context ID with HI in FOLD to mirror HIPv2
ORCHID construction
* Added Partial Computational Cost of FS via SIGMA, Section 1.2.1
* Added further text to Section 3.2.1
12.2. Changes in draft-ietf-hip-dex-22
* Apply editorial comment from Roman Danyliw * Apply editorial comment from Roman Danyliw
* Clarify IKM content for Master SA and Pairwise SA in Section 6.3 * Clarify IKM content for Master SA and Pairwise SA in Section 6.3
* Add behavior on BEX before DEX to Section 1.2 * Add behavior on BEX before DEX to Section 1.2
* Added [NIST.SP.800-56C], [NIST.SP.800-108], and [KeyDerivation] as * Added [NIST.SP.800-56C], [NIST.SP.800-108], and [KeyDerivation] as
source guidance for CKDF to Section 6.3 source guidance for CKDF to Section 6.3
* Removed NIST curves from Section 5.2.1 and Section 5.2.3 as too * Removed NIST curves from Section 5.2.1 and Section 5.2.3 as too
slow for 8-bit cpus slow for 8-bit CPUs
12.2. Changes in draft-ietf-hip-dex-21 12.3. Changes in draft-ietf-hip-dex-21
* Clarified on security concerns of using AES-CTR in Section 9.1 * Clarified on security concerns of using AES-CTR in Section 9.1
* Edits for SECDIR comments * Edits for SECDIR comments
12.3. Changes in draft-ietf-hip-dex-20 12.4. Changes in draft-ietf-hip-dex-20
* Clarified text on AES-CTR for HIP parameter encryption. This * Clarified text on AES-CTR for HIP parameter encryption. This
includes Section 9.1 includes Section 9.1
* Clarified text on R2 processing to validate content of R1. * Clarified text on R2 processing to validate content of R1.
* Clarified Applicability section. * Clarified Applicability section.
* Expanded Fig 1. * Expanded Fig 1.
* Clarified differences between BEX and DEX state machines. * Clarified differences between BEX and DEX state machines.
* ESP transform is MTI and ESP-TCP is Experimental. * ESP transform is MTI and ESP-TCP is Experimental.
12.4. Changes in draft-ietf-hip-dex-19 12.5. Changes in draft-ietf-hip-dex-19
* Replaced reference to RFC4493 for CMAC with NIST SP800-38B. * Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
* Remove NIST P-521 from DH_GROUP_LIST. * Remove NIST P-521 from DH_GROUP_LIST.
* Remove NULL-ENCRYPT. * Remove NULL-ENCRYPT.
* Added reference to rfc8005 for HIT lookup in DNS. * Added reference to rfc8005 for HIT lookup in DNS.
* Remove setting Control bit: A. * Remove setting Control bit: A.
* Many textual improvements per Benjamin Kaduk comments. * Many textual improvements per Benjamin Kaduk comments.
12.5. Changes in draft-ietf-hip-dex-18 12.6. Changes in draft-ietf-hip-dex-18
* Changed Perfect Forward Secrecy to Forward Secrecy. * Changed Perfect Forward Secrecy to Forward Secrecy.
12.6. Changes in draft-ietf-hip-dex-17 12.7. Changes in draft-ietf-hip-dex-17
* Added hex values for strings CKDF-Extract and CKDF-Expand. * Added hex values for strings CKDF-Extract and CKDF-Expand.
* Replace Perfect Forward Secrecy with Forward Secrecy. * Replace Perfect Forward Secrecy with Forward Secrecy.
12.7. Changes in draft-ietf-hip-dex-16 12.8. Changes in draft-ietf-hip-dex-16
* Remove old placeholder text. * Remove old placeholder text.
* Remove SECP160R1. Experience has shown EC25519 performance equal * Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it. enough to not need it.
12.8. Changes in draft-ietf-hip-dex-15 12.9. Changes in draft-ietf-hip-dex-15
* Added Public Key validation in I2 and R2 processing. * Added Public Key validation in I2 and R2 processing.
* Added ACL processing (Section 7.1). * Added ACL processing (Section 7.1).
* Added IANA instructions for DH_GROUP_LIST. * Added IANA instructions for DH_GROUP_LIST.
12.9. Changes in draft-ietf-hip-dex-14 12.10. Changes in draft-ietf-hip-dex-14
* Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan * Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment comment
12.10. Changes in draft-ietf-hip-dex-12 and 13 12.11. Changes in draft-ietf-hip-dex-12 and 13
* Nits from Jeff Ahrenholz (including some formatting issues) * Nits from Jeff Ahrenholz (including some formatting issues)
12.11. Changes in draft-ietf-hip-dex-11 and 12 12.12. Changes in draft-ietf-hip-dex-11 and 12
* Included more precise references to the IANA subregistries * Included more precise references to the IANA subregistries
* Addressed GEN-ART feedback from Francis Dupont * Addressed GEN-ART feedback from Francis Dupont
* Added reasoning for FS in a separate section, and it is mentioned * Added reasoning for FS in a separate section, and it is mentioned
also in the abstract and intro. also in the abstract and intro.
* Donald Eastlake's (secdir) nits addressed * Donald Eastlake's (secdir) nits addressed
* Resolved IANA nits from Amanda Baber. * Resolved IANA nits from Amanda Baber.
* New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 * New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
skipping to change at page 54, line 18 skipping to change at page 54, line 29
* Donald Eastlake's (secdir) nits addressed * Donald Eastlake's (secdir) nits addressed
* Resolved IANA nits from Amanda Baber. * Resolved IANA nits from Amanda Baber.
* New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 * 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.2), 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.12. Changes in draft-ietf-hip-dex-11 12.13. Changes in draft-ietf-hip-dex-11
* Update IANA considerations as requested by Eric Envyncke * Update IANA considerations as requested by Eric Envyncke
12.13. Changes in draft-ietf-hip-dex-10 12.14. Changes in draft-ietf-hip-dex-10
* Explanations on why the document includes so many SHOULDs * Explanations on why the document includes so many SHOULDs
12.14. Changes in draft-ietf-hip-dex-09 12.15. Changes in draft-ietf-hip-dex-09
* Fixed values for * Fixed values for
- DH_GROUP_LIST - DH_GROUP_LIST
- HIT_SUITE_LIST - HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.15. Changes in draft-ietf-hip-dex-05 12.16. Changes in draft-ietf-hip-dex-05
* Clarified main differences between HIP BEX and HIP DEX in * Clarified main differences between HIP BEX and HIP DEX in
Section 1. Section 1.
* Addressed MitM attack in Section 8. * Addressed MitM attack in Section 8.
* Minor editorial changes. * Minor editorial changes.
12.16. Changes in draft-ietf-hip-dex-04 12.17. Changes in draft-ietf-hip-dex-04
* Added new paragraph on rekeying procedure with HIP DEX. * Added new paragraph on rekeying procedure with HIP DEX.
* Updated references. * Updated references.
* Editorial changes. * Editorial changes.
12.17. Changes in draft-ietf-hip-dex-03 12.18. Changes in draft-ietf-hip-dex-03
* Added new section on HIP DEX/HIPv2 interoperability * Added new section on HIP DEX/HIPv2 interoperability
* Added reference to RFC4493 for CMAC. * Added reference to RFC4493 for CMAC.
* Added reference to RFC5869 for CKDF. * Added reference to RFC5869 for CKDF.
* Added processing of NOTIFY message in I2-SENT of state diagram. * Added processing of NOTIFY message in I2-SENT of state diagram.
* Editorial changes. * Editorial changes.
12.18. Changes in draft-ietf-hip-dex-02 12.19. Changes in draft-ietf-hip-dex-02
* Author address change. * Author address change.
12.19. Changes in draft-ietf-hip-dex-01 12.20. Changes in draft-ietf-hip-dex-01
* Added the new ECDH groups of Curve25519 and Curve448 from RFC * Added the new ECDH groups of Curve25519 and Curve448 from RFC
7748. 7748.
12.20. Changes in draft-ietf-hip-dex-00 12.21. Changes in draft-ietf-hip-dex-00
* The Internet Draft was adopted by the HIP WG. * The Internet Draft was adopted by the HIP WG.
12.21. Changes in draft-moskowitz-hip-rg-dex-06 12.22. Changes in draft-moskowitz-hip-rg-dex-06
* A major change in the ENCRYPT parameter to use AES-CTR rather than * A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
12.22. Changes in draft-moskowitz-hip-dex-00 12.23. Changes in draft-moskowitz-hip-dex-00
* Draft name change. HIPRG ended in IRTF, HIP DEX is now individual * Draft name change. HIPRG ended in IRTF, HIP DEX is now individual
submission. submission.
* Added the change section. * Added the change section.
* Added a Definitions section. * Added a Definitions section.
* Changed I2 and R2 packets to reflect use of AES-CTR for * Changed I2 and R2 packets to reflect use of AES-CTR for
ENCRYPTED_KEY parameter. ENCRYPTED_KEY parameter.
* Cleaned up KEYMAT Generation text. * Cleaned up KEYMAT Generation text.
* Added Appendix with C code for the ECDH shared secret generation * Added Appendix with C code for the ECDH shared secret generation
on an 8 bit processor. on an 8 bit processor.
12.23. Changes in draft-moskowitz-hip-dex-01 12.24. Changes in draft-moskowitz-hip-dex-01
* Numerous editorial changes. * Numerous editorial changes.
* New retransmission strategy. * New retransmission strategy.
* New HIT generation mechanism. * New HIT generation mechanism.
* Modified layout of ENCRYPTED_KEY parameter. * Modified layout of ENCRYPTED_KEY parameter.
* Clarify use puzzle difficulty of zero under normal network * Clarify use puzzle difficulty of zero under normal network
skipping to change at page 56, line 29 skipping to change at page 56, line 39
MUST). MUST).
* Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 * Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1
and I2). and I2).
* HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be * HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be
echoed in R2 packet. echoed in R2 packet.
* Added new author. * Added new author.
12.24. Changes in draft-moskowitz-hip-dex-02 12.25. Changes in draft-moskowitz-hip-dex-02
* Introduced formal definition of FOLD function. * Introduced formal definition of FOLD function.
* Clarified use of CMAC for puzzle computation in section "Solving * Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle". the Puzzle".
* Several editorial changes. * Several editorial changes.
12.25. Changes in draft-moskowitz-hip-dex-03 12.26. Changes in draft-moskowitz-hip-dex-03
* Addressed HI crypto agility. * Addressed HI crypto agility.
* Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. * Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
* Extended the IV in the ENCRYPTED_KEY parameter. * Extended the IV in the ENCRYPTED_KEY parameter.
* Introduced forward-references to HIP DEX KEYMAT process and * Introduced forward-references to HIP DEX KEYMAT process and
improved KEYMAT section. improved KEYMAT section.
* Replaced Appendix A on "C code for ECC point multiplication" with * Replaced Appendix A on "C code for ECC point multiplication" with
short discussion in introduction. short discussion in introduction.
* Updated references. * Updated references.
* Further editorial changes. * Further editorial changes.
12.26. Changes in draft-moskowitz-hip-dex-04 12.27. Changes in draft-moskowitz-hip-dex-04
* Improved retransmission extension. * Improved retransmission extension.
* Updated and strongly revised packet processing rules. * Updated and strongly revised packet processing rules.
* Updated security considerations. * Updated security considerations.
* Updated IANA considerations. * Updated IANA considerations.
* Move the HI Algorithm for ECDH to a value of 11. * Move the HI Algorithm for ECDH to a value of 11.
skipping to change at page 58, line 32 skipping to change at page 58, line 42
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[DH76] Diffie, W. and M. Hellman, "New directions in [DH76] Diffie, W. and M. Hellman, "New directions in
cryptography", IEEE Transactions on Information cryptography", IEEE Transactions on Information
Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638, Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638,
November 1976, <https://doi.org/10.1109/tit.1976.1055638>. November 1976, <https://doi.org/10.1109/tit.1976.1055638>.
[EfficientECC]
Nascimento, E., López, J., and R. Dahab, "Efficient and
Secure Elliptic Curve Cryptography for 8-bit AVR
Microcontrollers", Security, Privacy, and Applied
Cryptography Engineering pp. 289-309,
DOI 10.1007/978-3-319-24126-5_17, 2015,
<https://doi.org/10.1007/978-3-319-24126-5_17>.
[hip-rfc4423-bis] [hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-hip-rfc4423-bis-20, 14 February 2019, ietf-hip-rfc4423-bis-20, 14 February 2019,
<https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis- <https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-
20>. 20>.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Wehrle, "Tailoring end-to-end IP security protocols to the Wehrle, "Tailoring end-to-end IP security protocols to the
Internet of Things", 2013 21st IEEE International Internet of Things", 2013 21st IEEE International
skipping to change at page 60, line 33 skipping to change at page 60, line 47
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>. October 2016, <https://www.rfc-editor.org/info/rfc8005>.
Appendix A. Password-based two-factor authentication during the HIP DEX Appendix A. Calculating Collision Probabilities
The accepted formula for calculating the probability of a collision
is:
p = 1 - e^{-k^2/(2n)}
P Collision Probability
n Total possible population
k Actual population
Appendix B. Password-based two-factor authentication during the HIP DEX
handshake handshake
HIP DEX allows identifying authorized connections based on a two- HIP DEX allows identifying authorized connections based on a two-
factor authentication mechanism. With two-factor authentication, factor authentication mechanism. With two-factor authentication,
devices that are authorized to communicate with each other are devices that are authorized to communicate with each other are
required to be pre-provisioned with a shared (group) key. The required to be pre-provisioned with a shared (group) key. The
Initiator uses this pre-provisioned key to encrypt the Initiator uses this pre-provisioned key to encrypt the
ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2,
the Responder verifies that its challenge in the the Responder verifies that its challenge in the
ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted
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 C. 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
 End of changes. 54 change blocks. 
94 lines changed or deleted 165 lines changed or added

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