draft-ietf-hip-dex-18.txt   draft-ietf-hip-dex-19.txt 
HIP WG R. Moskowitz, Ed. HIP WG R. Moskowitz, Ed.
Internet-Draft HTT Consulting Internet-Draft HTT Consulting
Intended status: Standards Track R. Hummen Intended status: Standards Track R. Hummen
Expires: September 21, 2020 Hirschmann Automation and Control Expires: November 5, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
March 20, 2020 May 4, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-18 draft-ietf-hip-dex-19
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 September 21, 2020. This Internet-Draft will expire on November 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18
4.1.4. User Data Considerations . . . . . . . . . . . . . . 19 4.1.4. User Data Considerations . . . . . . . . . . . . . . 19
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 20 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 20
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 21 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 21
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 22 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 22
5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 23 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 24 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 24
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 25 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 25
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 27 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 27
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 28 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 28
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 29 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 29
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 30 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 30 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 30
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 30 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 30
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 30 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 30
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 31
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 34
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 34
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 35
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 38
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 41
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 42
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 43
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 43
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 44
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 48 9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47
9.2. NULL-ENCRYPT ONLY for Testing/Debugging . . . . . . . . . 48 9.2. NULL-ENCRYPT ONLY for Testing/Debugging . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.1. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 49 12.1. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 48
12.2. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 49 12.2. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 49
12.3. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 50 12.3. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 49
12.4. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50 12.4. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 49
12.5. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50 12.5. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 49
12.6. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50 12.6. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49
12.7. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50 12.7. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 49
12.8. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50 12.8. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 49
12.9. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 51 12.9. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50
12.10. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51 12.10. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50
12.11. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51 12.11. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50
12.12. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50
12.13. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51 12.13. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 50
12.14. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51 12.14. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 50
12.15. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 52 12.15. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51
12.16. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 52 12.16. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51
12.17. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52 12.17. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51
12.18. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52 12.18. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51
12.19. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 53 12.19. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51
12.20. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53 12.20. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 51
12.21. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53 12.21. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52
12.22. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52
12.23. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 52
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 57 HIP DEX handshake . . . . . . . . . . . . . . . . . 56
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX). HIP DEX builds on the Base EXchange (BEX) of the Host Identity DEX). HIP DEX is derived from the Base EXchange (BEX) of the Host
Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the
semantics as well as the general packet structure of HIPv2. Hence, protocol semantics as well as the general packet structure of HIPv2.
it is recommended that [RFC7401] is well-understood before reading Hence, it is recommended that [RFC7401] is well-understood before
this document. 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.
* HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC * HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC
as its MACing function. In contrast, HIPv2 currently supports as its MACing function. In contrast, HIPv2 currently supports
AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC- AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC-
SHA-384 for MACing. SHA-384 for MACing.
* HIP DEX defines a simple fold function to efficiently generate * HIP DEX defines a simple fold function to efficiently generate
HITs, whereas the HIT generation of HIPv2 is based on SHA-1, HITs, whereas the HIT generation of HIPv2 is based on SHA-1,
SHA-256, or SHA-384. SHA-256, or SHA-384.
2. HIP DEX forfeits the HIPv2 Forward Secrecy property of HIPv2 due 2. HIP DEX forfeits the HIPv2 Forward Secrecy property due to the
to the removal of the ephemeral Diffie-Hellman key agreement. As removal of the ephemeral Diffie-Hellman key agreement. As this
this weakens the security properties of HIP DEX, it MUST be used weakens the security properties of HIP DEX, it MUST be used only
only with constrained devices where this is prohibitively with constrained devices where this is prohibitively expensive as
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. 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 introduced a new, optional retransmission strategy that 5. 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 5, line 30 skipping to change at page 5, line 32
1.1. The HIP Diet EXchange (DEX) 1.1. The HIP Diet EXchange (DEX)
The HIP Diet EXchange is a two-party cryptographic protocol used to The HIP Diet EXchange is a two-party cryptographic protocol used to
establish a secure communication context between hosts. The first establish a secure communication context between hosts. The first
party is called the Initiator and the second party the Responder. party is called the Initiator and the second party the Responder.
The four-packet exchange helps to make HIP DEX Denial of Service The four-packet exchange helps to make HIP DEX Denial of Service
(DoS) resilient. The Initiator and the Responder exchange their (DoS) resilient. The Initiator and the Responder exchange their
static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2 static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2
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 packet 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-2007
[IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but
skipping to change at page 6, line 8 skipping to change at page 6, line 12
contained with an ENCRYPTED parameter) that indicates such anonymity contained with an ENCRYPTED parameter) that indicates such anonymity
should be ignored. should be ignored.
As in [RFC7401], data packets start to flow after the R2 packet. The As in [RFC7401], data packets start to flow after the R2 packet. The
I2 and R2 packets may carry a data payload in the future. The I2 and R2 packets may carry a data payload in the future. The
details of this may be defined later. details of this may be defined later.
An existing HIP association can be updated with the update mechanism An existing HIP association can be updated with the update mechanism
defined in [RFC7401]. Likewise, the association can be torn down defined in [RFC7401]. Likewise, the association can be torn down
with the defined closing mechanism for HIPv2 if it is no longer with the defined closing mechanism for HIPv2 if it is no longer
needed. In doing so, HIP DEX does so even in the absence of the needed. Standard HIPv2 uses a HIP_SIGNATURE to authenticate the
HIP_SIGNATURE that is used in standard HIPv2. association close operation, but since DEX does not provide for
signatures, the usual per-message MAC suffices.
Finally, HIP DEX is designed as an end-to-end authentication and key Finally, HIP DEX is designed as an end-to-end authentication and key
establishment protocol. As such, it can be used in combination with establishment protocol. As such, it can be used in combination with
Encapsulated Security Payload (ESP) [RFC7402] as well as with other Encapsulated Security Payload (ESP) [RFC7402] as well as with other
end-to-end security protocols. In addition, HIP DEX can also be used end-to-end security protocols. In addition, HIP DEX can also be used
as a keying mechanism for security primitives at the MAC layer, e.g., as a keying mechanism for security primitives at the MAC layer, e.g.,
for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth
mentioning that the HIP DEX base protocol does not cover all the mentioning that the HIP DEX base protocol does not cover all the
fine-grained policy control found in Internet Key Exchange Version 2 fine-grained policy control found in Internet Key Exchange Version 2
(IKEv2) [RFC7296] that allows IKEv2 to support complex gateway (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway
skipping to change at page 8, line 22 skipping to change at page 8, line 28
concatenation of the two HITs, with the smaller HIT preceding the concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network interpreted as positive (unsigned) 128-bit integers in network
byte order. byte order.
2.3. Definitions 2.3. Definitions
CKDF: CMAC-based Key Derivation Function. CKDF: CMAC-based Key Derivation Function.
CMAC: The Cipher-based Message Authentication Code with the 128-bit CMAC: The Cipher-based Message Authentication Code with the 128-bit
Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]. Advanced Encryption Standard (AES) defined in [NIST.SP.800-38B].
HIP association: The shared state between two peers after completion HIP association: The shared state between two peers after completion
of the HIP DEX handshake. of the HIP handshake.
HIP DEX (Diet EXchange): The ECDH-based HIP handshake for HIP DEX (Diet EXchange): The ECDH-based HIP handshake for
establishing a new HIP association. establishing a new HIP association.
HIT Suite: A HIT Suite groups all algorithms that are required to HIT Suite: A HIT Suite groups all algorithms that are required to
generate and use an HI and its HIT. In particular for HIP DEX, generate and use an HI and its HIT. In particular for HIP DEX,
these algorithms are: 1) ECDH and 2) FOLD. these algorithms are: 1) ECDH and 2) FOLD.
HI (Host Identity): The static ECDH public key that represents the HI (Host Identity): The static ECDH public key that represents the
identity of the host. In HIP DEX, a host proves ownership of the identity of the host. In HIP DEX, a host proves ownership of the
skipping to change at page 8, line 49 skipping to change at page 9, line 8
HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It
is generated by folding the HI (see Section 3). is generated by folding the HI (see Section 3).
Initiator: The host that initiates the HIP DEX handshake. This role Initiator: The host that initiates the HIP DEX handshake. This role
is typically forgotten once the handshake is completed. is typically forgotten once the handshake is completed.
KEYMAT: Keying material. That is, the bit string(s) used as KEYMAT: Keying material. That is, the bit string(s) used as
cryptographic keys. cryptographic keys.
RHASH_len: The natural length of the RHASH Algorithm in bits. RHASH_len: The natural output length of the RHASH Algorithm in bits.
Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE
parameter (see section 5.2.4 in [RFC7401]. It is also referred to parameter (see section 5.2.4 in [RFC7401]. It is also referred to
as "random value #I" in this document. as "random value #I" in this document.
OGA (Orchid Generation Algorithm): Hash function used in generating OGA (Orchid Generation Algorithm): Hash function used in generating
the ORCHID. the ORCHID.
ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6 ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6
addresses intended to be used as endpoint identifiers at addresses intended to be used as endpoint identifiers at
skipping to change at page 9, line 43 skipping to change at page 9, line 48
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH) HIP DEX implementations use Elliptic Curve Diffie-Hellman (ECDH)
[RFC6090] key exchange for generating the HI as defined in [RFC6090] key exchange for generating the HI as defined in
Section 5.2.3. No alternative algorithms are defined at this time. Section 5.2.3. No alternative algorithms are defined at this time.
A compressed encoding of the HI, the Host Identity Tag (HIT), is used A compressed encoding of the HI, the Host Identity Tag (HIT), is used
in the handshake packets to represent the HI. The DEX Host Identity in the handshake packets to represent the HI. The DEX Host Identity
Tag (HIT) is different from the BEX HIT in two ways: Tag (HIT) is different from the BEX HIT in two ways:
o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4).
o The DEX HIT is not generated via a cryptographic hash. Rather, it o The DEX HIT is not generated via a cryptographic hash. Rather, it
skipping to change at page 10, line 41 skipping to change at page 10, line 47
protocols. First, the fixed length of the HIT keeps packet sizes protocols. First, the fixed length of the HIT keeps packet sizes
manageable and eases protocol coding. Second, it presents a manageable and eases protocol coding. Second, it presents a
consistent format for the protocol, independent of the underlying consistent format for the protocol, independent of the underlying
identity technology in use. identity technology in use.
The structure of the HIT is based on RFC 7343 [RFC7343], called The structure of the HIT is based on RFC 7343 [RFC7343], called
Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and
consists of three parts: first, an IANA assigned prefix to consists of three parts: first, an IANA assigned prefix to
distinguish it from other IPv6 addresses. Second, a four-bit distinguish it from other IPv6 addresses. Second, a four-bit
encoding of the algorithms that were used for generating the HI and encoding of the algorithms that were used for generating the HI and
the compressed representation of the HI. Third, a 96-bit hashed the compressed representation of the HI. Third, the 96-bit
representation of the HI. In contrast to HIPv2, HIP DEX employs HITs compressed representation of the HI. In contrast to HIPv2, HIP DEX
that are NOT generated by means of a cryptographic hash. Instead, employs HITs that are NOT generated by means of a cryptographic hash.
the HI is compressed to 96 bits as defined in the following section. Instead, the HI is compressed to 96 bits as defined in the following
section.
3.2. Generating a HIT from an HI 3.2. Generating a HIT from an HI
The HIT does not follow the exact semantics of an ORCHID as there is The HIT does not follow the exact semantics of an ORCHID as there is
no hash function in HIP DEX. Still, its structure is strongly no hash function in HIP DEX. Still, its structure is strongly
aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2
is used for HIP DEX. The HIP DEX HIT suite (see Section 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(HI,96).
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 cryptograhic 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 or some other lookup process that
externally binds the HIT and HI. externally binds the HIT and HI.
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 11, line 47 skipping to change at page 12, line 11
By definition, the system initiating a HIP Diet EXchange is the By definition, the system initiating a HIP Diet EXchange is the
Initiator, and the peer is the Responder. This distinction is Initiator, and the peer is the Responder. This distinction is
typically forgotten once the handshake completes, and either party typically forgotten once the handshake completes, and either party
can become the Initiator in future communications. can become the Initiator in future communications.
The HIP Diet EXchange serves to manage the establishment of state The HIP Diet EXchange serves to manage the establishment of state
between an Initiator and a Responder. The first packet, I1, between an Initiator and a Responder. The first packet, I1,
initiates the exchange, and the last three packets, R1, I2, and R2, initiates the exchange, and the last three packets, R1, I2, and R2,
constitute an authenticated Diffie-Hellman [DH76] key exchange for constitute an authenticated Diffie-Hellman [DH76] key exchange for
the Master Key SA generation. This Master Key SA is used by the the Master Key Security Association (SA) generation. This Master Key
Initiator and the Responder to wrap secret keying material in the I2 SA is used by the Initiator and the Responder to wrap secret keying
and R2 packets. Based on the exchanged keying material, the peers material in the I2 and R2 packets. Based on the exchanged keying
then derive a Pair-wise Key SA if cryptographic keys are needed, material, the peers then derive a Pair-wise Key SA if cryptographic
e.g., for ESP-based protection of user data. keys are needed, e.g., for ESP-based protection of user data.
The Initiator first sends a trigger packet, I1, to the Responder. The Initiator first sends a trigger packet, I1, to the Responder.
This packet contains the HIT of the Initiator and the HIT of the This packet contains the HIT of the Initiator and the HIT of the
Responder, if it is known. Moreover, the I1 packet initializes the Responder, if it is known. Moreover, the I1 packet initializes the
negotiation of the Diffie-Hellman group that is used for generating negotiation of the Diffie-Hellman group that is used for generating
the Master Key SA. Therefore, the I1 packet contains a list of the Master Key SA by including a list of Diffie-Hellman Group IDs
Diffie-Hellman Group IDs supported by the Initiator. supported by the Initiator.
The second packet, R1, starts the actual authenticated Diffie-Hellman The second packet, R1, starts the actual authenticated Diffie-Hellman
key exchange. It contains a puzzle - a cryptographic challenge that key exchange. It contains a puzzle - a cryptographic challenge that
the Initiator must solve before continuing the exchange. The level the Initiator must solve before continuing the exchange. The level
of difficulty of the puzzle can be adjusted based on level of of difficulty of the puzzle can be adjusted based on level of
knowledge of the Initiator, current load, or other factors. In knowledge of the Initiator, current load, or other factors. In
addition, the R1 contains the Responder's Diffie-Hellman parameter addition, the R1 contains the Responder's Diffie-Hellman parameter
and lists of cryptographic algorithms supported by the Responder. and lists of cryptographic algorithms supported by the Responder.
Based on these lists, the Initiator can continue, abort, or restart Based on these lists, the Initiator can continue, abort, or restart
the handshake with a different selection of cryptographic algorithms. the handshake with a different selection of cryptographic algorithms.
skipping to change at page 14, line 32 skipping to change at page 14, line 32
regarding the transitions in the HIP DEX state machine. The regarding the transitions in the HIP DEX state machine. The
following section documents these differences compared to HIPv2. following section documents these differences compared to HIPv2.
4.1.2.1. HIP DEX Retransmission Mechanism 4.1.2.1. HIP DEX Retransmission Mechanism
For the retransmission of I1 and I2 packets, the Initiator adopts the For the retransmission of I1 and I2 packets, the Initiator adopts the
retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]).
This strategy is based on a timeout that is set to a value larger This strategy is based on a timeout that is set to a value larger
than the worst-case anticipated round-trip time (RTT). For each than the worst-case anticipated round-trip time (RTT). For each
received I1 or I2 packet, the Responder sends an R1 or R2 packet, received I1 or I2 packet, the Responder sends an R1 or R2 packet,
respectively. This design trait enables the Responder to remain respectively. This design trait to always send an R1 after an I1
stateless until the reception and successful processing of the I2 enables the Responder to remain stateless until the reception and
packet. The Initiator stops retransmitting I1 or I2 packets after successful processing of the I2 packet. The Initiator stops
the reception of the corresponding R1 or R2. If the Initiator did retransmitting I1 or I2 packets after the reception of the
not receive an R1 packet after I1_RETRIES_MAX tries, it stops I1 corresponding R1 or R2. If the Initiator did not receive an R1
retransmissions. Likewise, it stops retransmitting the I2 packet packet after I1_RETRIES_MAX tries, it stops I1 retransmissions.
after I2_RETRIES_MAX unsuccessful tries. Likewise, it stops retransmitting the I2 packet after I2_RETRIES_MAX
unsuccessful tries.
For repeatedly received I2 packets, the Responder SHOULD NOT perform For repeatedly received I2 packets, the Responder SHOULD NOT perform
operations related to the Diffie-Hellman key exchange or the keying operations related to the Diffie-Hellman key exchange or the keying
material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD
re-use the previously established state to re-create the re-use the previously established state to re-create the
corresponding R2 packet in order to prevent unnecessary computation corresponding R2 packet in order to prevent unnecessary computation
overhead. overhead.
The potentially high processing time of an I2 packet at a (resource- The potentially high processing time of an I2 packet at a (resource-
constrained) Responder may cause premature retransmissions if the constrained) Responder may cause premature retransmissions if the
time required for I2 transmission and processing exceeds the RTT- time required for I2 transmission and processing exceeds the RTT-
based retransmission timeout. Thus, the Initiator should also take based retransmission timeout. Thus, the Initiator should also take
the processing time of the I2 packet at the Responder into account the processing time of the I2 packet at the Responder into account
for retransmission purposes. To this end, the Responder MAY notify for retransmission purposes. To this end, the Responder MAY notify
the Initiator about the anticipated delay once the puzzle solution the Initiator about the anticipated delay once the puzzle solution
was successfully verified and if the remaining I2 packet processing was successfully verified that the remaining I2 packet processing
incurs a high processing delay. The Responder MAY therefore send a will incur a high processing delay. The Responder MAY therefore send
NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator a NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator
before the Responder commences the ECDH operation. The NOTIFY packet before the Responder commences the ECDH operation. The NOTIFY packet
serves as an acknowledgement for the I2 packet and consists of a serves as an acknowledgement for the I2 packet and consists of a
NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT
(see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter
contains the anticipated remaining processing time for the I2 packet contains the anticipated remaining processing time for the I2 packet
in milliseconds as two-octet Notification Data. This processing time in milliseconds as two-octet Notification Data. This processing time
can, e.g., be estimated by measuring the computation time of the ECDH can, e.g., be estimated by measuring the computation time of the ECDH
key derivation operation during the Responder start-up procedure. key derivation operation during the Responder start-up procedure.
After the I2 processing has finished, the Responder sends the regular After the I2 processing has finished, the Responder sends the regular
R2 packet. R2 packet.
skipping to change at page 19, line 45 skipping to change at page 19, line 45
In HIP packets, HIP parameters are ordered according to their numeric In HIP packets, HIP parameters are ordered according to their numeric
type number and encoded in TLV format. type number and encoded in TLV format.
HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of
[RFC7401] where possible. Still, HIP DEX further restricts and/or [RFC7401] where possible. Still, HIP DEX further restricts and/or
extends the following existing parameter types: extends the following existing parameter types:
o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites.
o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. o HIP_CIPHER is restricted to AES-128-CTR.
o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD.
o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, o PUZZLE, SOLUTION, and HIP_MAC parameter processing is altered to
SOLUTION, and HIP_MAC parameters (see Section 6.1 and support CMAC in RHASH and RHASH_len (see Section 6.1 and
Section 6.2). Section 6.2).
In addition, HIP DEX introduces the following new parameter: In addition, HIP DEX introduces the following new parameters:
+------------------+--------------+----------+----------------------+ +------------------+--------------+----------+----------------------+
| TLV | Type | Length | Data | | TLV | Type | Length | Data |
+------------------+--------------+----------+----------------------+ +------------------+--------------+----------+----------------------+
| ENCRYPTED_KEY | TBD1 | variable | Encrypted container | | ENCRYPTED_KEY | TBD1 | variable | Encrypted container |
| | (suggested | | for the session key | | | (suggested | | for the session key |
| | value 643) | | exchange | | | value 643) | | exchange |
| | | | | | | | | |
| I_NONCE | TBD6 | variable | Nonce from Initator | | I_NONCE | TBD6 | variable | Nonce from Initator |
| | (suggested | | for Master Key | | | (suggested | | for Master Key |
skipping to change at page 20, line 29 skipping to change at page 20, line 29
5.2.1. DH_GROUP_LIST 5.2.1. DH_GROUP_LIST
The DH_GROUP_LIST parameter contains the list of supported DH Group The DH_GROUP_LIST parameter contains the list of supported DH Group
IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With
HIP DEX, the DH Group IDs are restricted to: HIP DEX, the DH Group IDs are restricted to:
Group KDF Value Group KDF Value
NIST P-256 [RFC5903] CKDF 7 NIST P-256 [RFC5903] CKDF 7
NIST P-384 [RFC5903] CKDF 8 NIST P-384 [RFC5903] CKDF 8
NIST P-521 [RFC5903] CKDF 9
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 7 - 9 are defined in [RFC5903] and The ECDH groups with values 7 - 9 are defined in [RFC5903] and
[RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of [RFC6090]. These curves, when used with HIP MUST have a co-factor of
[RFC7401]. These curves, when used with HIP MUST have a co-factor of
1. 1.
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).
5.2.2. HIP_CIPHER 5.2.2. HIP_CIPHER
The HIP_CIPHER parameter contains the list of supported cipher The HIP_CIPHER parameter contains the list of supported cipher
algorithms to be used for encrypting the contents of the ENCRYPTED algorithms to be used for encrypting the contents of the ENCRYPTED
and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in
Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to: to:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
NULL-ENCRYPT 1 ([RFC2410])
AES-128-CTR TBD4 (suggested: 5) ([RFC3686])
Mandatory implementation: AES-128-CTR. Implementors SHOULD support AES-128-CTR TBD4 (suggested: 5) ([RFC3686])
NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT Mandatory implementation: AES-128-CTR.
offer or accept this value unless explicitly configured for testing/
debugging of HIP.
5.2.3. HOST_ID 5.2.3. HOST_ID
The HOST_ID parameter conveys the Host Identity (HI) along with The HOST_ID parameter conveys the Host Identity (HI) along with
optional information about a host. 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
the HI. Correspondingly, HIP DEX limits the HI algorithms to the the HI. Correspondingly, HIP DEX limits the HI algorithms to the
following new profile: following new profile:
skipping to change at page 21, line 37 skipping to change at page 21, line 27
ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED)
For hosts that implement ECDH as the algorithm, the following curves For hosts that implement ECDH as the algorithm, the following curves
are required: are required:
Group Value Group Value
NIST P-256 1 [RFC5903] NIST P-256 1 [RFC5903]
NIST P-384 2 [RFC5903] NIST P-384 2 [RFC5903]
NIST P-521 3 [RFC5903]
Curve25519 5 [RFC7748] Curve25519 5 [RFC7748]
Curve448 6 [RFC7748] Curve448 6 [RFC7748]
HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see
Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is
encoded in the "ECC curve" field of the HOST_ID parameter. The encoded in the "ECC curve" field of the HOST_ID parameter. The
supported DH Group IDs are defined in Section 5.2.1. supported DH Group IDs are defined in Section 5.2.1.
5.2.4. HIT_SUITE_LIST 5.2.4. HIT_SUITE_LIST
skipping to change at page 24, line 29 skipping to change at page 24, line 27
IP ( HIP ( DH_GROUP_LIST ) ) IP ( HIP ( DH_GROUP_LIST ) )
Valid control bits: none Valid control bits: none
The I1 packet contains the fixed HIP header and the Initiator's The I1 packet contains the fixed HIP header and the Initiator's
DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX
type as defined in Section 5.2.4. type as defined in Section 5.2.4.
Regarding the Responder's HIT, the Initiator may receive this HIT Regarding the Responder's HIT, the Initiator may receive this HIT
either from a DNS lookup of the Responder's FQDN, from some other either from a DNS lookup of the Responder's FQDN (see [RFC8005]),
repository, or from a local table. The Responder's HIT also MUST be from some other repository, or from a local table. The Responder's
of a HIP DEX type. If the Initiator does not know the Responder's HIT also MUST be of a HIP DEX type. If the Initiator does not know
HIT, it may attempt to use opportunistic mode by using NULL (all the Responder's HIT, it may attempt to use opportunistic mode by
zeros) as the Responder's HIT. See Section 4.1.8 of [RFC7401] for using NULL (all zeros) as the Responder's HIT. See Section 4.1.8 of
detailed information about the "HIP Opportunistic Mode". [RFC7401] for detailed information about the "HIP Opportunistic
Mode".
As the Initiator's and the Responder's HITs are compressions of the As the Initiator's and the Responder's HITs are compressions of the
employed HIs, they determine the DH Group ID that must be used in employed HIs, they determine the DH Group ID that must be used in
order to successfully conclude the triggered handshake. HITs, order to successfully conclude the triggered handshake. HITs,
however, only include the OGA ID identifying the HI algorithm. They however, only include the OGA ID identifying the HI algorithm. They
do not include information about the specific group ID of the HI. To do not include information about the specific group ID of the HI. To
inform the Responder about its employed and its otherwise supported inform the Responder about its employed and its otherwise supported
DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST
parameter in the I1 packet. This parameter MUST include the DH group parameter in the I1 packet. This parameter MUST include the DH group
ID that corresponds to the currently employed Initiator HIT as the ID that corresponds to the currently employed Initiator HIT as the
skipping to change at page 25, line 27 skipping to change at page 25, line 27
IP ( HIP ( [ R1_COUNTER, ] IP ( HIP ( [ R1_COUNTER, ]
PUZZLE, PUZZLE,
DH_GROUP_LIST, DH_GROUP_LIST,
HIP_CIPHER, HIP_CIPHER,
HOST_ID, HOST_ID,
HIT_SUITE_LIST, HIT_SUITE_LIST,
TRANSPORT_FORMAT_LIST, TRANSPORT_FORMAT_LIST,
[ <, ECHO_REQUEST_UNSIGNED >i ]) [ <, ECHO_REQUEST_UNSIGNED >i ])
Valid control bits: A Valid control bits: none
If the Responder's HI is an anonymous one, the A control bit MUST be
set.
The Initiator's HIT MUST match the one received in the I1 packet if The Initiator's HIT MUST match the one received in the I1 packet if
the R1 is a response to an I1. If the Responder has multiple HIs, the R1 is a response to an I1. If the Responder has multiple HIs,
the Responder's HIT MUST match the Initiator's request. If the the Responder's HIT MUST match the Initiator's request. If the
Initiator used opportunistic mode, the Responder may select among its Initiator used opportunistic mode, the Responder may select among its
HIs as described below. See Section 4.1.8 of [RFC7401] for detailed HIs as described below. See Section 4.1.8 of [RFC7401] for detailed
information about the "HIP Opportunistic Mode". information about the "HIP Opportunistic Mode".
The R1 packet generation counter is used to determine the currently The R1 packet generation counter is used to determine the currently
valid generation of puzzles. The value is increased periodically, valid generation of puzzles. The value is increased periodically,
skipping to change at page 26, line 7 skipping to change at page 26, line 5
puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders
SHOULD set K to zero by default and only increase the puzzle SHOULD set K to zero by default and only increase the puzzle
difficulty to protect against a DoS attack targeting the HIP DEX difficulty to protect against a DoS attack targeting the HIP DEX
handshake. A puzzle difficulty of zero effectively turns the puzzle handshake. A puzzle difficulty of zero effectively turns the puzzle
mechanism into a return-routability test and is strongly encouraged mechanism into a return-routability test and is strongly encouraged
during normal operation in order to conserve energy resources as well during normal operation in order to conserve energy resources as well
as to prevent unnecessary handshake delay in case of a resource- as to prevent unnecessary handshake delay in case of a resource-
constrained Initiator. Please also refer to Section 7 for further constrained Initiator. Please also refer to Section 7 for further
recommendations on choosing puzzle difficulty. recommendations on choosing puzzle difficulty.
The HIP_CIPHER contains the encryption algorithms supported by the
Responder to protect the key exchange, in the order of preference.
All implementations MUST support the AES-CTR [RFC3686].
The DH_GROUP_LIST parameter contains the Responder's order of The DH_GROUP_LIST parameter contains the Responder's order of
preference based on the Responder's choice the ECDH key contained in preference based on the Responder's choice the ECDH key contained in
the HOST_ID parameter (see below). This allows the Initiator to the HOST_ID parameter (see below). This allows the Initiator to
determine whether its own DH_GROUP_LIST in the I1 packet was begin to determine whether its own DH_GROUP_LIST in the I1 packet was
manipulated by an attacker. There is a further risk that the manipulated by an attacker. There is a further risk that the
Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1
packet cannot be authenticated in HI DEX. Thus, this parameter is packet cannot be authenticated in HI DEX. Thus, this parameter is
repeated in the R2 packet to allow for a final, cryptographically repeated in the R2 packet to allow for a final, cryptographically
secured validation. secured validation.
The HIP_CIPHER contains the encryption algorithms supported by the
Responder to protect the key exchange, in the order of preference.
All implementations MUST support the AES-CTR [RFC3686].
The HIT_SUITE_LIST parameter is an ordered list of the Responder's The HIT_SUITE_LIST parameter is an ordered list of the Responder's
supported and preferred HIT Suites. It enables a Responder to notify supported and preferred HIT Suites. It enables a Responder to notify
the Initiator about other available HIT suites than the one used in the Initiator about other available HIT suites than the one used in
the current handshake. Based on the received HIT_SUITE_LIST, the the current handshake. Based on the received HIT_SUITE_LIST, the
Initiator MAY decide to abort the current handshake and initiate a Initiator MAY decide to abort the current handshake and initiate a
new handshake with a different mutually supported HIT suite. This new handshake with a different mutually supported HIT suite. This
mechanism can, e.g., be used to move from an initial HIP DEX mechanism can, e.g., be used to move from an initial HIP DEX
handshake to a HIP BEX handshake for peers supporting both protocol handshake to a HIP BEX handshake for peers supporting both protocol
variants. variants.
The HOST_ID parameter depends on the received DH_GROUP_LIST parameter The HOST_ID parameter depends on the received DH_GROUP_LIST parameter
and the Responder HIT in the I1 packet. Specifically, if the I1 and the Responder HIT in the I1 packet. Specifically, if the I1
contains a Responder HIT, the Responder verifies that this HIT contains a Responder HIT, the Responder verifies that this HIT
matches the required DH group based on the received DH_GROUP_LIST matches the preferred DH group based on the received DH_GROUP_LIST
parameter included in the I1. In case of a positive result, the parameter included in the I1. In case of a positive result, the
Responder selects the corresponding HOST_ID for inclusion in the R1 Responder selects the corresponding HOST_ID for inclusion in the R1
packet. Likewise, if the Responder HIT in the I1 packet is NULL packet. Likewise, if the Responder HIT in the I1 packet is NULL
(i.e., during an opportunistic handshake), the Responder chooses its (i.e., during an opportunistic handshake), the Responder chooses its
HOST_ID according to the Initiator's employed DH group as indicated HOST_ID according to the Initiator's employed DH group as indicated
in the received DH_GROUP_LIST parameter and sets the source HIT in in the received DH_GROUP_LIST parameter and sets the source HIT in
the R1 packet accordingly. If the Responder however does not support the R1 packet accordingly. If the Responder however does not support
the DH group required by the Initiator or if the Responder HIT in the the DH group required by the Initiator or if the Responder HIT in the
I1 packet does not match the required DH group, the Responder selects I1 packet does not match the required DH group, the Responder selects
the mutually preferred and supported DH group based on the the mutually preferred and supported DH group based on the
DH_GROUP_LIST parameter in the I1 packet. The Responder then DH_GROUP_LIST parameter in the I1 packet. The Responder then
includes the corresponding ECDH key in the HOST_ID parameter. This includes the corresponding ECDH key in the HOST_ID parameter. This
parameter also indicates the selected DH group. Moreover, the parameter also indicates the selected DH group. Moreover, the
Responder sets the source HIT in the R1 packet based on the Responder sets the source HIT in the R1 packet based on the
destination HIT from the I1 packet. Based on the deviating DH group destination HIT from the I1 packet. Based on the deviating DH group
ID in the HOST_ID parameter, the Initiator then SHOULD abort the ID in the HOST_ID parameter, the Initiator then MUST abort the
current handshake and initiate a new handshake with the mutually current handshake and SHOULD initiate a new handshake with the
supported DH group as far as local policies (see Section 7) permit. mutually supported DH group as far as local policies (see Section 7)
permit.
The TRANSPORT_FORMAT_LIST parameter is an ordered list of the The TRANSPORT_FORMAT_LIST parameter is an ordered list of the
Responder's supported and preferred transport format types. The list Responder's supported and preferred transport format types. The list
allows the Initiator and the Responder to agree on a common type for allows the Initiator and the Responder to agree on a common type for
payload protection. The different format types are DEFAULT, ESP and payload protection. The different format types are DEFAULT, ESP and
ESP-TCP as explained in Section 3.1 in [RFC6261]. ESP-TCP as explained in Section 3.1 in [RFC6261].
The ECHO_REQUEST_UNSIGNED parameters contain data that the sender The ECHO_REQUEST_UNSIGNED parameters contain data that the sender
wants to receive unmodified in the corresponding response packet in wants to receive unmodified in the corresponding response packet in
the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero
skipping to change at page 27, line 37 skipping to change at page 27, line 35
IP ( HIP ( [R1_COUNTER,] IP ( HIP ( [R1_COUNTER,]
SOLUTION, SOLUTION,
HIP_CIPHER, HIP_CIPHER,
ENCRYPTED_KEY, ENCRYPTED_KEY,
HOST_ID, HOST_ID,
TRANSPORT_FORMAT_LIST, TRANSPORT_FORMAT_LIST,
I_NONCE, I_NONCE,
HIP_MAC HIP_MAC
[<, ECHO_RESPONSE_UNSIGNED>i )] ) [<, ECHO_RESPONSE_UNSIGNED>i )] )
Valid control bits: A Valid control bits: none
The HITs MUST match the ones used in the R1 packet. The HITs MUST match the ones used in the R1 packet.
If the Initiator's HI is an anonymous one, the A control bit MUST be
set.
If present in the R1 packet, the Initiator MUST include an unmodified If present in the R1 packet, the Initiator MUST include an unmodified
copy of the R1_COUNTER parameter into the I2 packet. copy of the R1_COUNTER parameter into the I2 packet.
The Solution contains the Random #I from the R1 packet and the The Solution contains the Random #I from the R1 packet and the
computed #J value. The low-order #K bits of the RHASH(I | ... | J) computed #J value. The low-order #K bits of the RHASH(I | ... | J)
MUST be zero. MUST be zero.
The HIP_CIPHER contains the single encryption transform selected by The HIP_CIPHER contains the single encryption transform selected by
the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY
parameters. The chosen cipher MUST correspond to one of the ciphers parameters. The chosen cipher MUST correspond to one of the ciphers
skipping to change at page 45, line 23 skipping to change at page 44, line 23
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
HIT indicates success, then the device may add this HIT to its ACL HIT indicates success, then the device may add this HIT/HI to its ACL
for future use. for future use.
Devices unable to manage an ACL (e.g. sensors) are subject to MITM Devices unable to manage an ACL (e.g. sensors) are subject to MITM
attacks, even with the use of the password authentication (password attacks, even with the use of the password authentication (password
theft by attacker). As long as the other peer (e.g. sensor theft by attacker). As long as the other peer (e.g. sensor
controller) does use an ACL, the attack can be recognized there and controller) does use an ACL, the attack can be recognized there and
addressed. This is often seen where the sensor does not appear as addressed. This is often seen where the sensor does not appear as
properly operating with the controller, as the attacker cannot properly operating with the controller, as the attacker cannot
impersonate information in the ACL. impersonate information in the ACL.
skipping to change at page 48, line 16 skipping to change at page 47, line 16
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
take 48 octets each. For P-521, they take 66 octets each. take 48 octets each.
For Curve25519 and Curve448, the contents of the public value are the For Curve25519 and Curve448, the contents of the public value are the
byte string inputs and outputs of the corresponding functions defined byte string inputs and outputs of the corresponding functions defined
in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448.
The validation is done in Section 6.7, step 4 and Section 6.8, step The validation is done in Section 6.7, step 4 and Section 6.8, step
5. 5.
9.2. NULL-ENCRYPT ONLY for Testing/Debugging 9.2. NULL-ENCRYPT ONLY for Testing/Debugging
skipping to change at page 49, line 42 skipping to change at page 48, line 42
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-17 12.1. Changes in draft-ietf-hip-dex-19
o Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
o Remove NIST P-521 from DH_GROUP_LIST.
o Remove NULL-ENCRYPT.
o Added reference to rfc8005 for HIT lookup in DNS.
o Remove setting Control bit: A.
o Many textual improvements per Benjamin Kaduk comments.
12.2. Changes in draft-ietf-hip-dex-18
o Changed Perfect Forward Secrecy to Forward Secrecy.
12.3. 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.2. Changes in draft-ietf-hip-dex-16 12.4. 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.3. Changes in draft-ietf-hip-dex-15 12.5. 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.4. Changes in draft-ietf-hip-dex-14 12.6. 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.5. Changes in draft-ietf-hip-dex-12 and 13 12.7. 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.6. Changes in draft-ietf-hip-dex-11 and 12 12.8. 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.1), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.7. Changes in draft-ietf-hip-dex-11 12.9. 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.8. Changes in draft-ietf-hip-dex-10 12.10. 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.9. Changes in draft-ietf-hip-dex-09 12.11. 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.10. Changes in draft-ietf-hip-dex-05 12.12. 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.11. Changes in draft-ietf-hip-dex-04 12.13. 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.12. Changes in draft-ietf-hip-dex-03 12.14. 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.13. Changes in draft-ietf-hip-dex-02 12.15. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.14. Changes in draft-ietf-hip-dex-01 12.16. 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.15. Changes in draft-ietf-hip-dex-00 12.17. 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.16. Changes in draft-moskowitz-hip-rg-dex-06 12.18. 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.17. Changes in draft-moskowitz-hip-dex-00 12.19. 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.18. Changes in draft-moskowitz-hip-dex-01 12.20. 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 7 skipping to change at page 52, line 19
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.19. Changes in draft-moskowitz-hip-dex-02 12.21. 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.20. Changes in draft-moskowitz-hip-dex-03 12.22. 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.21. Changes in draft-moskowitz-hip-dex-04 12.23. 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 54, line 4 skipping to change at page 53, line 12
o Updated security considerations. o Updated security considerations.
o Updated IANA considerations. o Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11. o Move the HI Algorithm for ECDH to a value of 11.
o Many editorial changes. o Many editorial changes.
13. References 13. References
13.1. Normative References 13.1. Normative References
[NIST.SP.800-38B]
Dworkin, M., "Recommendation for block cipher modes of
operation :", National Institute of Standards and
Technology report, DOI 10.6028/nist.sp.800-38b, 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<https://www.rfc-editor.org/info/rfc3686>. <https://www.rfc-editor.org/info/rfc3686>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
skipping to change at page 55, line 47 skipping to change at page 55, line 10
Wireless Personal Area Networks (WPANs)", IEEE Standard Wireless Personal Area Networks (WPANs)", IEEE Standard
802.15.4, September 2011, 802.15.4, September 2011,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.15.4-2011.pdf>. download/802.15.4-2011.pdf>.
[LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for
Elliptic Curve Cryptography in Wireless Sensor Networks", Elliptic Curve Cryptography in Wireless Sensor Networks",
in Proceedings of International Conference on Information in Proceedings of International Conference on Information
Processing in Sensor Networks (IPSN 2008), April 2008. Processing in Sensor Networks (IPSN 2008), April 2008.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
DOI 10.17487/RFC5903, June 2010, DOI 10.17487/RFC5903, June 2010,
<https://www.rfc-editor.org/info/rfc5903>. <https://www.rfc-editor.org/info/rfc5903>.
skipping to change at page 56, line 34 skipping to change at page 55, line 39
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
2 , 2000, <http://www.secg.org/>. System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>.
Appendix A. Password-based two-factor authentication during the HIP DEX Appendix A. 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,
 End of changes. 72 change blocks. 
163 lines changed or deleted 179 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/