draft-ietf-hip-dex-11.txt   draft-ietf-hip-dex-24.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: May 2, 2020 Hirschmann Automation and Control Expires: 23 July 2021 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
October 30, 2019 19 January 2021
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-11 draft-ietf-hip-dex-24
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) and
HIP DEX protocol design aims at reducing the overhead of the employed specifically developed for use on low end processors. The HIP DEX
cryptographic primitives by omitting public-key signatures and hash protocol design aims at reducing the overhead of the employed
functions. cryptographic primitives by omitting public-key signatures and
cryptographic hash functions.
The HIP DEX protocol is primarily designed for computation or memory- The HIP DEX protocol is primarily designed for computation or memory-
constrained sensor/actuator devices. Like HIPv2, it is expected to constrained sensor/actuator devices. Like HIPv2, it is expected to
be used together with a suitable security protocol such as the be used together with a suitable security protocol such as the
Encapsulated Security Payload (ESP) for the protection of upper layer Encapsulated Security Payload (ESP) for the protection of upper layer
protocol data. In addition, HIP DEX can also be used as a keying protocol data. Unlike HIPv2, HIP DEX does not support Forward
mechanism for security primitives at the MAC layer, e.g., for IEEE Secrecy (FS), and MUST only be used on devices where FS is
802.15.4 networks. prohibitively expensive. In addition, HIP DEX can also be used as a
keying mechanism for security primitives at the MAC layer, e.g., for
IEEE 802.15.4 networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 May 2, 2020. This Internet-Draft will expire on 23 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 6
1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 6 1.2.1. Partial Computational Cost of FS via SIGMA . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 9
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 9
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 9
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 8 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 13
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 13
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 14
4.1.4. User Data Considerations . . . . . . . . . . . . . . 17 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 16
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 17
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 17 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 21
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 17 4.1.4. User Data Considerations . . . . . . . . . . . . . . 22
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 18 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 18 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 22
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 22
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 19 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 23
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 20 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 23
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 21 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 25
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 22 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 25
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 24 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 25 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 26 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 27
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 26 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 28
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 27 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 30
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 27 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 31
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 27 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 32
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 28 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 33
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 31 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 33
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 33
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 33
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 35
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 38
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 38
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 39
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 42
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 45
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 41 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 47
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 47
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 48
12.1. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 44 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 48
12.2. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 44 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
12.3. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44 9.1. Caution on using HIP DEX rather than HIP BEX . . . . . . 51
12.4. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44 9.2. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 51
12.5. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 45 9.3. Need to Validate Public Keys . . . . . . . . . . . . . . 51
12.6. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 45 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
12.7. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 45 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
12.8. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 45 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.9. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45 12.1. Changes in draft-ietf-hip-dex-24 . . . . . . . . . . . . 53
12.10. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 12.2. Changes in draft-ietf-hip-dex-23 . . . . . . . . . . . . 53
12.11. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46 12.3. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 53
12.12. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46 12.4. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 53
12.13. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 12.5. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 54
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 12.6. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . 47 12.7. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . 48 12.8. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 54
Appendix A. Password-based two-factor authentication during the 12.9. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 54
HIP DEX handshake . . . . . . . . . . . . . . . . . 50 12.10. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 55
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 50 12.11. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 12.12. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 55
12.13. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 55
12.14. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 55
12.15. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 55
12.16. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 55
12.17. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 56
12.18. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 56
12.19. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 56
12.20. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 56
12.21. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 56
12.22. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 56
12.23. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 56
12.24. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 57
12.25. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 57
12.26. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 57
12.27. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 58
12.28. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 58
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.1. Normative References . . . . . . . . . . . . . . . . . . 58
13.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Calculating Collision Probabilities . . . . . . . . 62
Appendix B. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 62
Appendix C. IESG Considerations . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
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), specifically developed for use on low end processors that
Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol cannot support the cryptographic requirements of HIP Base EXchange
semantics as well as the general packet structure of HIPv2. Hence, (HIP BEX). HIP DEX is derived from HIP BEX, which is defined in the
it is recommended that [RFC7401] is well-understood before reading Host Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX
this document. preserves the protocol semantics as well as the general packet
structure of HIPv2. Hence, it is recommended that [RFC7401] is well-
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.
* HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC * HIP DEX uses AES-CTR for symmetric-key encryption of HIP
as its MACing function. In contrast, HIPv2 currently supports payloads and AES-CMAC as its MACing function. In contrast,
AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC- HIPv2 currently supports AES-CBC for encryption and HMAC-SHA-
SHA-384 for MACing. 1, HMAC-SHA-256, or HMAC-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 Perfect Forward Secrecy property of 2. HIP DEX forfeits the HIPv2 Forward Secrecy property due to the
HIPv2 due to the removal of the ephemeral Diffie-Hellman key removal of the ephemeral Diffie-Hellman key agreement. As this
agreement. weakens the security properties of HIP DEX, it MUST be used only
with constrained devices where this is prohibitively expensive as
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 CMAC-based
parameter. HIP_MAC parameter.
4. With HIP DEX, the ECDH derived key is only used to protect HIP 4. The forfeiture of the use of digital signatures leaves the R1
packet open to a MITM attack. Such an attack is managed in the
R2 packet validation and is yet another DOS attack mitigated
through the HIP state machine. This state machine mitigation is
augmented by HIT,HI ACL controls, Section 7.1.
5. The forfeiture of a cryptographic hash leaves the HIT generated
by a fold function vulnerable to pre-image attacks. This MUST be
mitigated through a HIT,HI pairing as in an ACL control mechanism
Section 7.1.
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.
5. HIP DEX introduced a new, optional retransmission strategy that 7. 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].
Cryptographic hashing was eliminated due to the memory/code space or
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.
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
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-2016
[IEEE.802-11.2007] 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.
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. However, I2 and R2 packets may carry a data payload in the future. The
the details of this may be defined later. details of this may be defined later.
An existing HIP association can be updated with the update mechanism An existing HIP association can be updated with the update mechanism
defined in [RFC7401]. Likewise, the association can be torn down defined in [RFC7401]. Likewise, the association can be torn down
with the defined closing mechanism for HIPv2 if it is no longer with the defined closing mechanism for HIPv2 if it is no longer
needed. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of needed. Standard HIPv2 uses a HIP_SIGNATURE to authenticate the
the original HIPv2 specification. 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.2015]. It is worth
mentioning that the HIP DEX base protocol does not cover all the mentioning that the HIP DEX base protocol does not cover all the
fine-grained policy control found in Internet Key Exchange Version 2 fine-grained policy control found in Internet Key Exchange Version 2
(IKEv2) [RFC7296] that allows IKEv2 to support complex gateway (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway
policies. Thus, HIP DEX is not a replacement for IKEv2. policies. Thus, HIP DEX is not a replacement for IKEv2.
1.2. Memo Structure 1.2. Applicability
HIP DEX achieves its lightweight nature in large part due to the
intentional removal of Forward Secrecy (FS) from the key exchange.
Current mechanisms to achieve FS use an authenticated ephemeral
Diffie-Hellman exchange (e.g., SIGn-and-MAc Approach, SIGMA or
Password-Authenticated Key Agreement, PAKE). HIP DEX targets usage
on devices where even the most lightweight ECDH exchange is
prohibitively expensive for recurring (ephemeral) use. For example,
experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has
shown that EC25519 keypair generation exceeds 10 seconds and consumes
significant energy (i.e., battery resources). Even the ECDH
multiplication for the HIP DEX static-static key exchange takes 8-9
seconds, again with measurable energy consumption. The ECDH
multiplication resource consumption via a static EC25519 keypair is
tolerable as a one-time event during provisioning, but would render
the protocol unsuitable for use on these devices if it was required
to be a recurring part of the protocol. Further, for devices
constrained in this manner, a FS-enabled protocol's cost will likely
provide little gain. Since the resulting "FS" key, likely produced
during device deployment, would typically end up being used for the
remainder of the device's lifetime. Since this key (or the
information needed to regenerate it) persists for the device's
lifetime, the key step of 'throw away old keys' in achieving forward
secrecy does not occur, thus the forward secrecy would not be
obtained in practice.
With such a usage pattern, the inherent benefit of ephemeral keys is
not realized. The security properties of such usage are very similar
to those of using a statically provisioned symmetric pre-shared key,
in that there remains a single PSK in static storage that is
susceptible to exfiltration/compromise, and compromise of that key in
effect compromises the entire protocol for that node. HIP DEX
achieves marginally better security properties by computing the
effective long-term PSK from a DH exchange, so that the provisioning
service is not required to be part of the risk surface due to also
possessing the PSK.
If the device is not able to generate the ECDH keypair, the
provisioning service can generate and install the ECDH keypair
provided it wipes knowledge of the private key. Typically, the
provisioning service will make the public key (HI) and PSK available
for the deployment step.
Due to the substantially reduced security guarantees of HIP DEX
compared to HIP BEX, HIP DEX MUST only be used when at least one of
the two endpoints is a class 0 or 1 constrained device defined in
Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both
endpoints are class 2 devices or unconstrained.
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
between systems capable of HIP BEX. This may be controlled by
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
try a DEX HIT. Note that such a downgrade (from BEX to DEX) offer
approach is open to attack, requiring additional mitigation (e.g.
ACL controls).
1.2.1. Partial Computational Cost of FS via SIGMA
From the Initator's process, FS via SIGMA [SIGMA] in HIP BEX comes at
a prohibitive cost for constrained, 8-bit devices. In BEX, the
Initator has:
a. Public key operations
2 Public Key signing verifications,
1 Public Key signing,
b. Key generation
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 [ATmega328P] 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 are 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 blocking factor to adoption of SIGMA based key
establishment on 8-bit processors with limited power.
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 highligts 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
capitals, as shown here. capitals, as shown here.
2.2. Notation 2.2. Notation
[x] indicates that x is optional. [x] indicates that x is optional.
{x} indicates that x is encrypted. {x} indicates that x is encrypted.
X(y) indicates that y is a parameter of X. X(y) indicates that y is a parameter of X.
<x>i indicates that x exists i times. <x>i indicates that x exists i times.
--> signifies "Initiator to Responder" communication (requests). --> signifies "Initiator to Responder" communication (requests).
<-- signifies "Responder to Initiator" communication (replies). <-- signifies "Responder to Initiator" communication (replies).
| signifies concatenation of information - e.g., X | Y is the | signifies concatenation of information - e.g., X | Y is the
concatenation of X and Y. concatenation of X and Y.
FOLD (X, K) denotes the partitioning of X into n K-bit segments and FOLD (X, K) denotes the partitioning of X into n K-bit segments and
the iterative folding of these segments via XOR. I.e., X = x_1, the iterative folding of these segments via XOR. I.e., X = x_1,
x_2, ..., x_n, where x_i is of length K and the last segment x_n x_2, ..., x_n, where x_i is of length K and the last segment x_n
is padded to length K by appending 0 bits. FOLD then is computed is padded to length K by appending 0 bits. FOLD then is computed
as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1.
Ltrunc (M(x), K) denotes the lowest order K bits of the result of Ltrunc (M(x), K) denotes the lowest order K bits of the result of
the MAC function M on the input x. the MAC function M on the input x.
sort (HIT-I | HIT-R) is defined as the network byte order sort (HIT-I | HIT-R) is defined as the network byte order
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
HIP Diet Exchange (DEX): The ECDH-based HIP handshake for CKDF: CMAC-based Key Derivation Function.
CMAC: The Cipher-based Message Authentication Code with the 128-bit
Advanced Encryption Standard (AES) defined in [NIST.SP.800-38B].
HIP association: The shared state between two peers after completion
of the HIP handshake.
HIP DEX (Diet EXchange): The ECDH-based HIP handshake for
establishing a new HIP association. establishing a new HIP association.
Host Identity (HI): The static ECDH public key that represents the 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,
these algorithms are: 1) ECDH and 2) FOLD.
HI (Host Identity): The static ECDH public key that represents the
identity of the host. In HIP DEX, a host proves ownership of the identity of the host. In HIP DEX, a host proves ownership of the
private key belonging to its HI by creating a HIP_MAC with the private key belonging to its HI by creating a HIP_MAC with the
derived ECDH key (see Section 3). derived ECDH key (see Section 3) in the appropriate I2 or R2
packet.
Host Identity Tag (HIT): 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).
HIT Suite: A HIT Suite groups all algorithms that are required to
generate and use an HI and its HIT. In particular, these
algorithms are: 1) ECDH and 2) FOLD.
HIP association: The shared state between two peers after completion
of the HIP DEX handshake.
Initiator: The host that initiates the HIP DEX handshake. This role Initiator: The host that initiates the HIP DEX handshake. This role
is typically forgotten once the handshake is completed. is typically forgotten once the handshake is completed.
KEYMAT: Keying material. That is, the bit string(s) used as
cryptographic keys.
RHASH_len: The natural output length of the RHASH Algorithm in bits.
Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE
parameter (see section 5.2.4 in [RFC7401]. It is also referred to
as "random value #I" in this document.
OGA (Orchid Generation Algorithm): Hash function used in generating
the ORCHID.
ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6
addresses intended to be used as endpoint identifiers at
applications and Application Programming Interfaces (APIs) and not
as identifiers for network location at the IP layer.
Puzzle difficulty K: The Initiator has to compute a solution for the
puzzle. The level of computational difficulty is denoted by the
#K field in the puzzle parameter (see section 5.2.4 in [RFC7401].
Responder: The host that responds to the Initiator in the HIP DEX Responder: The host that responds to the Initiator in the HIP DEX
handshake. This role is typically forgotten once the handshake is handshake. This role is typically forgotten once the handshake is
completed. completed.
Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message redefined as CMAC. Still, note that CMAC is a message
authentication code (MAC) and not a cryptographic hash function. authentication code (MAC) and not a cryptographic hash function.
Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where
RHASH is used. Moreover, RHASH has different security properties RHASH is used. Moreover, RHASH has different security properties
in HIP DEX and is not used for HIT generation. in HIP DEX and is not used for HIT generation.
Length of the Responder's HIT Hash Algorithm (RHASH_len): The Security Association (SA): An SA is a simplex "connection" that
natural output length of RHASH in bits. affords security services to the traffic carried by it. HIP DEX
has two forms of SAs, a Master Key SA for the actual HIP traffic,
CMAC: The Cipher-based Message Authentication Code with the 128-bit and a Pair-wise Key SA for use by a data transport service.
Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].
CKDF: CMAC-based Key Derivation Function.
Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE
parameter (see section 5.2.4 in [RFC7401]. It is also referred to
as "random value #I" in this document.
Puzzle difficulty K: The Initiator has to compute a solution for the
puzzle. The level of computational difficulty is denoted by the
#K field in the puzzle parameter (see section 5.2.4 in [RFC7401].
3. Host Identity (HI) and its Structure 3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [hip-rfc4423-bis] for more details on the
details on the difference between an identity and the corresponding difference between an identity and the corresponding identifier.
identifier.
HIP DEX implementations MUST support the Elliptic Curve Diffie- HIP DEX implementations use Elliptic Curve Diffie-Hellman (ECDH)
Hellman (ECDH) [RFC6090] key exchange for generating the HI as [RFC6090] key exchange for generating the HI as defined in
defined in Section 5.2.3. No additional algorithms are supported at Section 5.2.3. No alternative algorithms are defined at this time.
this time.
A compressed encoding of the HI, the Host Identity Tag (HIT), is used A compressed encoding of the HI, the Host Identity Tag (HIT), is used
in the handshake packets to represent the HI. The DEX Host Identity in the handshake packets to represent the HI. The DEX Host Identity
Tag (HIT) is different from the BEX HIT in two ways: Tag (HIT) is different from the BEX HIT in two ways:
o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). * 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 * The DEX HIT is not generated via a cryptographic hash. Rather, it
is a compression of the HI. is a compression of the HI.
Due to the latter property, an attacker may be able to find a Due to the latter property, an attacker may be able to find a
collision with a HIT that is in use. Hence, policy decisions such as collision with a HIT that is in use. Hence, policy decisions such as
access control MUST NOT be based solely on the HIT. Instead, the HI access control MUST NOT use an unverified HIT as input. The full HI
of a host SHOULD be considered. of a host SHOULD be considered, and the HIT MAY be used as a hint for
locating the full HI (see Section 7.1).
Carrying HIs and HITs in the header of user data packets would Carrying HIs or HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that increase the overhead of packets. Thus, it is not expected that
these parameters are carried in every packet, but other methods are these parameters are carried in every packet, but other methods are
used to map the data packets to the corresponding HIs. In some used to map the data packets to the corresponding HIs. In some
cases, this allows to use HIP DEX without any additional headers in cases, this allows use of HIP DEX without any additional headers in
the user data packets. For example, if ESP is used to protect data the user data packets. For example, if ESP is used to protect data
traffic, the Security Parameter Index (SPI) carried in the ESP header traffic, the Security Parameter Index (SPI) carried in the ESP header
can be used to map the encrypted data packet to the correct HIP DEX can be used to map the encrypted data packet to the correct HIP DEX
association. When other user data packet formats are used, the association. When other user data packet formats are used, the
corresponding extensions need to define a replacement for the corresponding extensions need to define a replacement for the
ESP_TRANSFORM [RFC7402] parameter along with associated semantics, ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
but this procedure is outside the scope of this document. but this procedure is outside the scope of this document.
3.1. Host Identity Tag (HIT) 3.1. Host Identity Tag (HIT)
With HIP DEX, the HIT is a 128-bit value - a compression of the HI With HIP DEX, the HIT is a 128-bit value - a compression of the HI
prepended with a specific prefix. There are two advantages of using prepended with a specific prefix. There are two advantages of using
a hashed encoding over the actual variable-sized public key in this compressed encoding over the actual variable-sized public key in
protocols. First, the fixed length of the HIT keeps packet sizes protocols. First, the fixed length of the HIT keeps packet sizes
manageable and eases protocol coding. Second, it presents a manageable and eases protocol coding. Second, it presents a
consistent format for the protocol, independent of the underlying consistent format for the protocol, independent of the underlying
identity technology in use. identity technology in use.
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((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
HIP DEX by design lacks a cryptographic hash function. The
generation of the HIT is one of the few places in the protocol where
this presents a challenge. CMAC was first considered for this
purpose, but to use CMAC for HIT generation would require using a
static key, either ZERO or some published value. NIST does not
consider CMAC an approved cryptographic hash as:
It is straightforward to demonstrate that CMAC is not collision-
resistant for any choice of a published key.
Since collision-resistance is not possible with the tools at hand,
any reasonable function (e.g. FOLD) that takes the full value of the
HI into generating the HIT can be used, provided that collision
detection is part of the HIP-DEX deployment design. This is achieved
here through either an ACL, Section 7.1, or some other lookup process
that externally binds the HIT and HI.
Even without collision-resistance, it is not trivial to create
duplicate FOLD generated HITs, as FOLD is starting out with a random
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 10, line 16 skipping to change at page 14, line 26
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 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. Note that in supported by the Initiator.
some cases it may be possible to replace this trigger packet by some
other form of a trigger, in which case the protocol starts with the
Responder sending the R1 packet. In such cases, another mechanism to
convey the Initiator's supported DH Groups (e.g., by using a default
group) must be specified.
The second packet, R1, starts the actual authenticated Diffie-Hellman The second packet, R1, starts the actual authenticated Diffie-Hellman
key exchange. It contains a puzzle - a cryptographic challenge that key exchange. It contains a puzzle - a cryptographic challenge that
the Initiator must solve before continuing the exchange. The level the Initiator must solve before continuing the exchange. The level
of difficulty of the puzzle can be adjusted based on level of trust of difficulty of the puzzle can be adjusted based on level of
with the Initiator, current load, or other factors. In addition, the knowledge of the Initiator, current load, or other factors. In
R1 contains the Responder's Diffie-Hellman parameter and lists of addition, the R1 contains the Responder's Diffie-Hellman parameter
cryptographic algorithms supported by the Responder. Based on these and lists of cryptographic algorithms supported by the Responder.
lists, the Initiator can continue, abort, or restart the handshake Based on these lists, the Initiator can continue, abort, or restart
with a different selection of cryptographic algorithms. the handshake with a different selection of cryptographic algorithms.
Unlike in HIP BEX, the R1 packet in DEX is not signed. Thus the
Initiator MUST compare the content of R1 with that it later gets in
R2 to ensure there was no MITM attack on R1.
In the I2 packet, the Initiator MUST display the solution to the In the I2 packet, the Initiator MUST display the solution to the
received puzzle. Without a correct solution, the I2 packet is received puzzle. Without a correct solution, the I2 packet is
discarded. The I2 also contains a key wrap parameter that carries discarded. The I2 also contains a nonce and key wrap parameter that
secret keying material of the Initiator. This keying material is carries secret keying material of the Initiator. This keying
only half of the final session key. The packet is authenticated by material is only half of the final session (pair-wise) key. The
the sender (Initiator) via a MAC. packet is authenticated by the sender (Initiator) via a MAC.
The R2 packet acknowledges the receipt of the I2 packet and completes The R2 packet acknowledges the receipt of the I2 packet and completes
the handshake. The R2 contains a key wrap parameter that carries the the handshake. The R2 echos the nonce from I2 and contains a key
rest of the keying material of the Responder. The packet is wrap parameter that carries the rest of the keying material of the
authenticated by the sender (Responder) via a MAC. Responder. The packet is authenticated by the sender (Responder) via
a MAC. The R2 repeats the lists from R1 for signed validation to
defend them against a MITM attack.
The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)"
and "ENC(DH,y)" refer to the random values x and y that are wrapped and "ENC(DH,y)" refer to the random values x and y that are wrapped
based on the Master Key SA (indicated by ENC and DH). Note that x based on the Master Key SA (indicated by ENC and DH). Note that x
and y each constitute half of the final session key material. The and y each constitute half of the final session key material. The
packets also contain other parameters that are not shown in this packets also contain other parameters that are not shown in this
figure. figure.
Initiator Responder Initiator Responder
I1: DH List
-------------------------------------->
remain stateless
R1: puzzle, (DH, Suite, Trans) Lists,
HI
<-------------------------------------
I1:
--------------------------------->
remain stateless
R1: puzzle, HI
<--------------------------------
solve puzzle solve puzzle
perform ECDH perform ECDH
encrypt x encrypt x
I2: solution, HI, ENC(DH,x), mac
---------------------------------> I2: solution, HI, ENC(DH,x), Trans List,
check puzzle I_Nonce, mac
perform ECDH -------------------------------------->
check MAC
decrypt x check puzzle
encrypt y perform ECDH
R2: ENC(DH,y), mac check MAC
<--------------------------------- decrypt x
encrypt y
R2: (DH, Suite, Trans) Lists, ENC(DH,y),
I_Nonce, mac
<--------------------------------------
check MAC check MAC
validate lists in R1
decrypt y decrypt y
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 12, line 26 skipping to change at page 17, line 26
[RFC7401] for more detailed information about the employed mechanism. [RFC7401] for more detailed information about the employed mechanism.
Notably, the only differences between the puzzle mechanism in HIP DEX Notably, the only differences between the puzzle mechanism in HIP DEX
and HIPv2 are that HIP DEX does not employ pre-computation of R1 and HIPv2 are that HIP DEX does not employ pre-computation of R1
packets and uses CMAC instead of a hash function for solving and packets and uses CMAC instead of a hash function for solving and
verifying a puzzle. The implications of these changes on the puzzle verifying a puzzle. The implications of these changes on the puzzle
implementation are discussed in Section 6.1. implementation are discussed in Section 6.1.
4.1.2. HIP State Machine 4.1.2. HIP State Machine
The HIP DEX state machine has the same states as the HIPv2 state The HIP DEX state machine has the same states as the HIPv2 state
machine (see 4.4. in [RFC7401]). However, HIP DEX features a machine (see Section 4.4. in [RFC7401]); this is for easier
comparison between the two Exchanges. However, HIP DEX features a
retransmission strategy with an optional reception acknowledgement retransmission strategy with an optional reception acknowledgement
for the I2 packet. The goal of this additional acknowledgement is to for the I2 packet. The goal of this additional acknowledgement is to
reduce premature I2 retransmissions in case of devices with low reduce premature I2 retransmissions in case of devices with low
computation resources [HWZ13]. As a result, there are minor changes computation resources [HWZ13]. As a result, there are minor changes
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 14, line 7 skipping to change at page 18, line 52
time when the Responder should have completed its I2 packet time when the Responder should have completed its I2 packet
processing and the network should have delivered the R2 packet processing and the network should have delivered the R2 packet
according to the employed worst-case estimates. according to the employed worst-case estimates.
4.1.2.2. HIP State Processes 4.1.2.2. HIP State Processes
HIP DEX clarifies or introduces the following new transitions. HIP DEX clarifies or introduces the following new transitions.
System behavior in state I2-SENT, Table 1. System behavior in state I2-SENT, Table 1.
+---------------------+---------------------------------------------+ +=================+===============================================+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +=================+===============================================+
| Receive NOTIFY, | Set I2 retransmission timer to value in | | Receive NOTIFY, | Set I2 retransmission timer to value in |
| process | I2_ACKNOWLEDGEMENT Notification Data plus | | process | I2_ACKNOWLEDGEMENT Notification Data plus 1/2 |
| | 1/2 RTT-based timeout value and stay at | | | RTT-based timeout value and stay at I2-SENT |
| | I2-SENT | +-----------------+-----------------------------------------------+
| | | +-----------------+-----------------------------------------------+
| | | | Timeout | Increment trial counter |
| | | +-----------------+-----------------------------------------------+
| Timeout | Increment trial counter | +-----------------+-----------------------------------------------+
| | | | | If counter is less than I2_RETRIES_MAX, send |
| | | | | I2, reset timer to RTT-based timeout, and |
| | | | | stay at I2-SENT |
| | If counter is less than I2_RETRIES_MAX, | +-----------------+-----------------------------------------------+
| | send I2, reset timer to RTT-based timeout, | +-----------------+-----------------------------------------------+
| | and stay at I2-SENT | | | If counter is greater than I2_RETRIES_MAX, go |
| | | | | to E-FAILED |
| | | +-----------------+-----------------------------------------------+
| | |
| | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange
4.1.2.3. Simplified HIP State Diagram 4.1.2.3. Simplified HIP State Diagram
The following diagram shows the major state transitions. Transitions The following diagram shows the major state transitions. Transitions
based on received packets implicitly assume that the packets are based on received packets implicitly assume that the packets are
successfully authenticated or processed. successfully authenticated or processed.
+--+ +----------------------------+ +--+ +----------------------------+
skipping to change at page 16, line 18 skipping to change at page 21, line 18
Diffie-Hellman derived key, or Master Key, and one for the session Diffie-Hellman derived key, or Master Key, and one for the session
key, or Pair-wise Key. key, or Pair-wise Key.
4.1.3.1. Master Key SA 4.1.3.1. Master Key SA
The Master Key SA is used to authenticate HIP packets and to encrypt The Master Key SA is used to authenticate HIP packets and to encrypt
selected HIP parameters in the HIP DEX packet exchanges. Since only selected HIP parameters in the HIP DEX packet exchanges. Since only
a small amount of data is protected by this SA, it can be long-lived a small amount of data is protected by this SA, it can be long-lived
with no need for rekeying. At the latest, the system MUST initiate with no need for rekeying. At the latest, the system MUST initiate
rekeying when its incoming ESP sequence counter is going to overflow, rekeying when its incoming ESP sequence counter is going to overflow,
and he system MUST NOT replace its keying material until the rekeying and the system MUST NOT replace its keying material until the
packet exchange successfully completes as described in Section 6.8 in rekeying packet exchange successfully completes as described in
[RFC7402]. Section 6.8 in [RFC7402].
The Master Key SA contains the following elements: The Master Key SA contains the following elements:
o Source HIT * Source HIT
o Destination HIT * Destination HIT
o HIP_Encrypt Key * HIP_Encrypt Key
o HIP_MAC Key * HIP_MAC Key
The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie-
Hellman derived key as described in Section 6.3. Their length is Hellman derived key as described in Section 6.3. Their length is
determined by the HIP_CIPHER. determined by the HIP_CIPHER.
4.1.3.2. Pair-wise Key SA 4.1.3.2. Pair-wise Key SA
The Pair-wise Key SA is used to authenticate and to encrypt user The Pair-wise Key SA is used to authenticate and to encrypt user
data. It is refreshed (or rekeyed) using an UPDATE packet exchange. data. It is refreshed (or rekeyed) using an UPDATE packet exchange.
The Pair-wise Key SA elements are defined by the data transform The Pair-wise Key SA elements are defined by the data transform
skipping to change at page 17, line 43 skipping to change at page 22, line 43
allow HIP extensions to define new parameters and new protocol allow HIP extensions to define new parameters and new protocol
behavior. behavior.
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. * DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites.
o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. * HIP_CIPHER is restricted to AES-128-CTR.
o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. * HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD.
o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, * 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 (suggested | variable | Encrypted container |
| | (suggested | | for the session key | | | value 643) | | for the session key |
| | value 643) | | exchange | | | | | exchange |
+------------------+--------------+----------+----------------------+ +---------------+-----------------+----------+---------------------+
| I_NONCE | TBD6 (suggested | variable | Nonce from Initator |
| | value 644) | | for Master Key |
+---------------+-----------------+----------+---------------------+
Table 2
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-384 [RFC5903] CKDF 8
NIST P-521 [RFC5903] CKDF 9
SECP160R1 [SECG] CKDF 10
Curve25519 [RFC7748] CKDF 12
Curve448 [RFC7748] CKDF 13
The ECDH groups with values 7 - 9 are defined in [RFC5903] and Curve25519 [RFC7748] CKDF TBD7 (suggested value 12)
[RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of Curve448 [RFC7748] CKDF TBD8 (suggested value 13)
[RFC7401]. These curves, when used with HIP MUST have a co-factor of
1.
The ECDH groups with values 12 and 13 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
requirements on 8-bit CPUs. It is included for "completeness". An
implementor should ensure they can get the needed performance for
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:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
NULL-ENCRYPT 1 ([RFC2410])
AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) AES-128-CTR TBD4 (suggested: 5) ([RFC3686])
Mandatory implementation: AES-128-CTR. Implementors SHOULD support Mandatory implementation: AES-128-CTR.
NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT
offer or accept this value unless explicitly configured for testing/ The counter for AES-128-CTR MUST have a length of 128 bits. The
debugging of HIP. puzzle value #I and the puzzle solution #J (see Section 4.1.2 in
[RFC7401]) are used to construct the initialization vector (IV) as
FOLD(I | J, 112) which are the high-order bits of the CTR counter. A
16 bit value as a block counter, which is initialized to zero on
first use, is appended to the IV in order to guarantee that a non-
repeating nonce is fed to the AES-CTR encryption algorithm.
This counter is incremented as it is used for all encrypted HIP
parameters. That is a single AES-129-CTR counter associated with the
Master Key SA.
5.2.3. HOST_ID 5.2.3. HOST_ID
The HOST_ID parameter conveys the Host Identity (HI) along with The HOST_ID parameter conveys the Host Identity (HI) along with
optional information about a host. The HOST_ID parameter is defined optional information about a host. The HOST_ID parameter is defined
in Section 5.2.9 of [RFC7401]. in Section 5.2.9 of [RFC7401].
HIP DEX uses the public portion of a host's static ECDH key-pair as HIP DEX uses the public portion of a host's static ECDH key-pair as
the HI. Correspondingly, HIP DEX limits the HI algorithms to the the HI. Correspondingly, HIP DEX limits the HI algorithms to the
following new profile: following new profile:
Algorithm profiles Value Algorithm profiles Value
ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED)
For hosts that implement ECDH as the algorithm, the following curves
are required:
Group Value
Curve25519 5 [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
The HIT_SUITE_LIST parameter contains a list of the supported HIT The HIT_SUITE_LIST parameter contains a list of the supported HIT
suite IDs of the Responder. Based on the HIT_SUITE_LIST, the suite IDs of the Responder. Based on the HIT_SUITE_LIST, the
Initiator can determine which source HIT Suite IDs are supported by Initiator can determine which source HIT Suite IDs are supported by
skipping to change at page 20, line 26 skipping to change at page 25, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD1 (suggested value 643) Type TBD1 (suggested value 643)
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Encrypted The value is encrypted using an encryption algorithm Encrypted The value is encrypted using an encryption algorithm
value as defined in the HIP_CIPHER parameter. value as defined in the HIP_CIPHER parameter.
The ENCRYPTED_KEY parameter encapsulates a random value that is later The ENCRYPTED_KEY parameter encapsulates a random value that is later
used in the session key creation process (see Section 6.3). This used in the session key creation process (see Section 6.3). This
random value MUST have a length of at least 64 bits. The puzzle random value MUST have a length of at least 64 bits. The HIP_CIPHER
value #I and the puzzle solution #J (see Section 4.1.2 in [RFC7401]) is used for the encryption.
are used as the initialization vector (IV) for the encryption
process. To this end, the IV is computed as FOLD(I | J, 128).
Moreover, a 16 bit counter value, which is initialized to zero on
first use, is appended to the IV value in order to guarantee that a
non-repeating nonce is fed to the encryption algorithm defined by the
HIP_CIPHER.
Once this encryption process is completed, the "encrypted value" data Once this encryption process is completed, the "encrypted value" data
field is ready for inclusion in the Parameter. If necessary, field is ready for inclusion in the Parameter. If necessary,
additional Padding for 8-byte alignment is then added according to additional Padding for 8-byte alignment is then added according to
the rules of TLV Format in [RFC7401]. the rules of TLV Format in [RFC7401].
5.2.6. I_NONCE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Initiator Nonce /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD6 (suggested value 644)
Length length in octets, excluding Type, Length, and
Padding
Initiator Nonce provided by the Initiator for use in the
Nonce Master Key
The I_NONCE parameter encapsulates a random value that is later used
in the Master key creation process (see Section 6.3). This random
value MUST have a length of 2 x RHASH_len. This parameter is sent to
the Responder in I2 which echos it back to the Initiator in R2.
If necessary, additional Padding for 8-byte alignment is added
according to the rules of TLV Format in [RFC7401].
5.3. HIP Packets 5.3. HIP Packets
HIP DEX uses the same eight basic HIP packets as HIPv2 (see HIP DEX uses the same eight basic HIP packets as HIPv2 (see
Section 5.3 of [RFC7401]). Four of them are for the HIP handshake Section 5.3 of [RFC7401]). Four of them are for the HIP handshake
(I1, R1, I2, and R2), one is for updating an association (UPDATE), (I1, R1, I2, and R2), one is for updating an association (UPDATE),
one is for sending notifications (NOTIFY), and two are for closing one is for sending notifications (NOTIFY), and two are for closing
the association (CLOSE and CLOSE_ACK). There are some differences the association (CLOSE and CLOSE_ACK). There are some differences
regarding the HIP parameters that are included in the handshake regarding the HIP parameters that are included in the handshake
packets concerning HIP BEX and HIP DEX. This section covers these packets concerning HIP BEX and HIP DEX. This section covers these
differences for the DEX packets. Packets not discussed here, follow differences for the DEX packets. Packets not discussed here, follow
skipping to change at page 21, line 38 skipping to change at page 27, line 33
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 22, line 34 skipping to change at page 28, line 43
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 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,
and it is RECOMMENDED that it is increased at least as often as and it is RECOMMENDED that it is increased at least as often as
solutions to old puzzles are no longer accepted. solutions to old puzzles are no longer accepted.
The Puzzle contains a Random value #I and the puzzle difficulty K. The Puzzle contains a Random value #I and the puzzle difficulty K.
The difficulty K indicates the number of lower-order bits, in the The difficulty K indicates the number of lower-order bits, in the
puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders
SHOULD set K to zero by default and only increase the puzzle SHOULD set K to zero by default and only increase the puzzle
difficulty to protect against a DoS attack targeting the HIP DEX difficulty to protect against a DoS attack targeting the HIP DEX
handshake. A puzzle difficulty of zero effectively turns the puzzle handshake. A puzzle difficulty of zero effectively turns the puzzle
mechanism into a return-routablility test and is strongly encouraged mechanism into a return-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 which the Responder chose the ECDH key contained preference based on the Responder's choice the ECDH key contained in
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 HIP 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 R2 packet based on the Responder sets the source HIT in the R1 packet based on the
destination HIT from the I1 packet. Based on the deviating DH group destination HIT from the I1 packet. Based on the deviating DH group
ID in the HOST_ID parameter, the Initiator then SHOULD abort the ID in the HOST_ID parameter, the Initiator then 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
ESP-TCP as explained in Section 3.1 in [RFC6261]. (Mandatory to Implement) and ESP-TCP (Experimental, as explained in
Section 3.1 in [RFC6261]).
The ECHO_REQUEST_UNSIGNED parameters contain data that the sender The ECHO_REQUEST_UNSIGNED parameters contain data that the sender
wants to receive unmodified in the corresponding response packet in wants to receive unmodified in the corresponding response packet in
the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero
or more ECHO_REQUEST_UNSIGNED parameters. or more ECHO_REQUEST_UNSIGNED parameters.
5.3.3. I2 - the Second HIP Initiator Packet 5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: The HIP header values for the I2 packet:
skipping to change at page 24, line 39 skipping to change at page 30, line 48
Type = 3 Type = 3
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT DST HIT = Responder's HIT
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,
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 25, line 26 skipping to change at page 31, 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
for the Master Key generation as shown in Section 6.3. This is
echoed back to the Initiator in the R2 packet.
The MAC is calculated over the whole HIP envelope, excluding any The MAC is calculated over the whole HIP envelope, excluding any
parameters after the HIP_MAC parameter as described in Section 6.2. parameters after the HIP_MAC parameter as described in Section 6.2.
The Responder MUST validate the HIP_MAC parameter. The Responder MUST validate the HIP_MAC parameter.
5.3.4. R2 - the Second HIP Responder Packet 5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet: The HIP header values for the R2 packet:
Header: Header:
Packet Type = 4 Packet Type = 4
SRC HIT = Responder's HIT SRC HIT = Responder's HIT
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
IP ( HIP ( DH_GROUP_LIST, IP ( HIP ( DH_GROUP_LIST,
HIP_CIPHER, HIP_CIPHER,
ENCRYPTED_KEY, ENCRYPTED_KEY,
HIT_SUITE_LIST, HIT_SUITE_LIST,
TRANSPORT_FORMAT_LIST, TRANSPORT_FORMAT_LIST,
I_NONCE,
HIP_MAC) HIP_MAC)
Valid control bits: none Valid control bits: none
The HITs used MUST match the ones used in the I2 packet. The HITs used MUST match the ones used in the I2 packet.
The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST,
and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These
parameters MUST be the same as included in the R1 packet. The parameters MUST be the same as included in the R1 packet. The
parameter are re-included here because the R2 packet is MACed and parameter are re-included here because the R2 packet is MACed and
thus cannot be altered by an attacker. For verification purposes, thus cannot be altered by an attacker. For verification purposes,
the Initiator re-evaluates the selected suites and compares the the Initiator re-evaluates the selected suites and compares the
results against the chosen ones. If the re-evaluated suites do not results against the chosen ones. If the re-evaluated suites do not
match the chosen ones, the Initiator acts based on its local policy. match the chosen ones, the Initiator acts based on its local policy.
The ENCRYPTED_KEY parameter contains an Responder generated random The ENCRYPTED_KEY parameter contains an Responder 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 I_NONCE parameter contains the nonce, supplied by the Initiator
for the Master Key generation as shown in Section 6.3. The Responder
is echoing the value back to the Initiator to show it used the
Initiator provided nonce.
The MAC is calculated over the whole HIP envelope, excluding any The MAC is calculated over the whole HIP envelope, excluding any
parameters after the HIP_MAC, as described in Section 6.2. The parameters after the HIP_MAC, as described in Section 6.2. The
Initiator MUST validate the HIP_MAC parameter. Initiator MUST validate the HIP_MAC parameter.
5.4. ICMP Messages 5.4. ICMP Messages
When a HIP implementation detects a problem with an incoming packet, When a HIP implementation detects a problem with an incoming packet,
and it either cannot determine the identity of the sender of the and it either cannot determine the identity of the sender of the
packet or does not have any existing HIP association with the sender packet or does not have any existing HIP association with the sender
of the packet, it MAY respond with an ICMP packet. Any such reply of the packet, it MAY respond with an ICMP packet. Any such reply
MUST be rate-limited as described in [RFC4443]. In most cases, the MUST be rate-limited as described in [RFC4443]. In most cases, the
ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for
ICMPv6), with the Pointer field pointing to the field that caused the ICMPv6) and Code of 0. The Pointer field pointing to the field that
ICMP message to be generated. The problem cases specified in caused the ICMP message to be generated, for example to the first 8
Section 5.4. of [RFC7401] also apply to HIP DEX. bytes of a UDP payload for "SPI is Unknown". The problem cases
specified in Section 5.4. of [RFC7401] also apply to HIP DEX.
6. Packet Processing 6. Packet Processing
Due to the adopted protocol semantics and the inherited general Due to the adopted protocol semantics and the inherited general
packet structure, the packet processing in HIP DEX only differs from packet structure, the packet processing in HIP DEX only differs from
HIPv2 in very few places. Here, we focus on these differences and HIPv2 in very few places. Here, we focus on these differences and
refer to Section 6 in [RFC7401] otherwise. refer to Section 6 in [RFC7401] otherwise.
The processing of outgoing and incoming application data remains the The processing of outgoing and incoming application data remains the
same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]).
It should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further
implementation experience provides better guidance. Please refer
also to Appendix B for argumentation about the SHOULDs.
6.1. Solving the Puzzle 6.1. Solving the Puzzle
The procedures for solving and verifying a puzzle in HIP DEX are The procedures for solving and verifying a puzzle in HIP DEX are
strongly based on the corresponding procedures in HIPv2. The only strongly based on the corresponding procedures in HIPv2. The only
exceptions are that HIP DEX does not use pre-computation of R1 exceptions are that HIP DEX does not use pre-computation of R1
packets and that RHASH is set to CMAC. As a result, the pre- packets and that RHASH is set to CMAC. As a result, the pre-
computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX.
Moreover, the Initiator solves a puzzle by computing: Moreover, the Initiator solves a puzzle by computing:
Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0
skipping to change at page 27, line 41 skipping to change at page 34, line 7
CMAC: { HIP header | [ Parameters ] } CMAC: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters of the packet that is where Parameters include all HIP parameters of the packet that is
being calculated with Type values ranging from 1 to (HIP_MAC's Type being calculated with Type values ranging from 1 to (HIP_MAC's Type
value - 1) and exclude parameters with Type values greater or equal value - 1) and exclude parameters with Type values greater or equal
to HIP_MAC's Type value. to HIP_MAC's Type value.
During HIP_MAC calculation, the following applies: During HIP_MAC calculation, the following applies:
o In the HIP header, the Checksum field is set to zero. * In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to * In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_MAC parameter. the beginning of the HIP_MAC parameter.
The parameter order is described in Section 5.2.1 of [RFC7401]. The parameter order is described in Section 5.2.1 of [RFC7401].
The CMAC calculation and verification process is as follows: The CMAC calculation and verification process is as follows:
Packet sender: Packet sender:
1. Create the HIP packet, without the HIP_MAC or any other parameter 1. Create the HIP packet, without the HIP_MAC or any other parameter
with greater Type value than the HIP_MAC parameter has. with greater Type value than the HIP_MAC parameter has.
skipping to change at page 28, line 50 skipping to change at page 35, line 17
The HIP DEX KEYMAT process is used to derive the keys for the Master The HIP DEX KEYMAT process is used to derive the keys for the Master
Key SA as well as for the Pair-wise Key SA. The keys for the Master Key SA as well as for the Pair-wise Key SA. The keys for the Master
Key SA are based on the Diffie-Hellman derived key, Kij, which is Key SA are based on the Diffie-Hellman derived key, Kij, which is
produced during the HIP DEX handshake. The Initiator generates Kij produced during the HIP DEX handshake. The Initiator generates Kij
during the creation of the I2 packet and the Responder generates Kij during the creation of the I2 packet and the Responder generates Kij
once it receives the I2 packet. This is why the I2 packet can once it receives the I2 packet. This is why the I2 packet can
already contain authenticated and/or encrypted information. already contain authenticated and/or encrypted information.
The keys derived for the Pair-wise Key SA are not used during the HIP The keys derived for the Pair-wise Key SA are not used during the HIP
DEX handshake. Instead, these keys are made available as payload DEX handshake. Instead, these keys are made available as payload
protection keys (e.g., for IPsec). Some payload protection protection keys (e.g., for IPsec's ESP).
mechanisms have their own Key Derivation Function, and if so this
mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST
be used to derive the keys of the Pair-wise Key SA based on the
concatenation of the random values that are contained in the
exchanged ENCRYPTED_KEY parameters.
The HIP DEX KEYMAT process is based on the is the Hash-based Key The HIP DEX KEYMAT process is similar to the Hash-based Key
Derivation Function (HKDF) defined in [RFC5869] and consists of two Derivation Function (HKDF) defined in [RFC5869], but uses CMAC in
components, CKDF-Extract and CKDF-Expand. The CKDF-Extract function place of a cryptographic hash. DEX KEYMAT follows the CMAC usage
compresses a non-uniformly distributed key, such as the output of a guidance for a KDF construct provided in [NIST.SP.800-56C],
Diffie-Hellman key derivation, to extract the key entropy into a [NIST.SP.800-108] and [KeyDerivation]. This CMAC Key Derivation
fixed length output. The CKDF-Expand function takes either the Function (CKDF) consists of two components, CKDF-Extract and CKDF-
output of the Extract function or directly uses a uniformly Expand. The CKDF-Extract function compresses a non-uniformly
distributed key and expands the length of the key, repeatedly distributed key, such as the output of a Diffie-Hellman key
distributing the key entropy, to produce the keys needed. derivation, to extract the key entropy into a fixed length output.
The CKDF-Expand function takes either the output of the Extract
function or directly uses a uniformly distributed key and expands the
length of the key, repeatedly distributing the key entropy, to
produce the keys needed.
The key derivation for the Master Key SA employs always both the The key derivation for the Master Key SA employs always both the
Extract and Expand phases. The Pair-wise Key SA needs only the Extract and Expand phases. The Pair-wise Key SA needs only the
Extract phase when key is smaller or equal to 128 bits, but otherwise Extract phase when the key is smaller or equal to 128 bits, but
requires also the Expand phase. otherwise requires also the Expand phase.
The CKDF-Extract function is the following operation: The CKDF-Extract function is the following operation:
CKDF-Extract(I, IKM, info) -> PRK CKDF-Extract(I, IKM, info) -> PRK
Inputs: Inputs:
I Random #I from the PUZZLE parameter I Random #I, provided by the Responder, from the PUZZLE
IKM Input keying material, i.e., the Diffie-Hellman derived parameter
key for the Master Key SA and the concatenation of the Kij Diffie-Hellman derived key
random values of the ENCRYPTED_KEY parameters in the IKM IKMm for Master Key SA Input keying material
same order as the HITs with sort(HIT-I | HIT-R) for the or
Pair-wise Key SA IKMp for Pair-wise Key SA Input keying material
IKMm Kij | I_NONCE
IKMp Kij | I_NONCE | (concatenated random values of the
ENCRYPTED_KEY parameters in the same order as
the HITs with sort(HIT-I | HIT-R))
info sort(HIT-I | HIT-R) | "CKDF-Extract" info sort(HIT-I | HIT-R) | "CKDF-Extract"
where "CKDF-Extract" is an octet string Where the input text: "CKDF-Extract"
Is the hex string: 0x434b44462d45787472616374
Output: Output:
PRK a pseudorandom key (of RHASH_len/8 octets) PRK a pseudorandom key (of RHASH_len/8 octets)
The pseudorandom key PRK is calculated as follows: The pseudorandom key PRK is calculated as follows:
PRK = CMAC(I, IKM | info) PRK = CMAC(I, IKM | info)
The CKDF-Expand function is the following operation: The CKDF-Expand function is the following operation:
CKDF-Expand(PRK, info, L) -> OKM CKDF-Expand(PRK, info, L) -> OKM
Inputs: Inputs:
PRK a pseudorandom key of at least RHASH_len/8 octets PRK a pseudorandom key of at least RHASH_len/8 octets
(either the output from the extract step or the (either the output from the extract step or the
concatenation of the random values of the concatenation of the random values of the
ENCRYPTED_KEY parameters in the same order as the ENCRYPTED_KEY parameters in the same order as the
HITs with sort(HIT-I | HIT-R) in case of no extract) HITs with sort(HIT-I | HIT-R) in case of no extract)
info sort(HIT-I | HIT-R) | "CKDF-Expand" info sort(HIT-I | HIT-R) | "CKDF-Expand"
where "CKDF-Expand" is an octet string Where the input text: "CKDF-Expand"
Is the hex string: 0x434b44462d457870616e64
L length of output keying material in octets L length of output keying material in octets
(<= 255*RHASH_len/8) (<= 255*RHASH_len/8)
Output: Output:
OKM output keying material (of L octets) OKM output keying material (of L octets)
The output keying material OKM is calculated as follows: The output keying material OKM is calculated as follows:
N = ceil(L/(RHASH_len/8)) N = ceil(L/(RHASH_len/8))
T = T(1) | T(2) | T(3) | ... | T(N) T = T(1) | T(2) | T(3) | ... | T(N)
skipping to change at page 32, line 49 skipping to change at page 40, line 5
processing rules of HIPv2. The considerations about R1 management processing rules of HIPv2. The considerations about R1 management
(except pre-computation) and malformed I1 packets in Sections 6.7.1 (except pre-computation) and malformed I1 packets in Sections 6.7.1
and 6.7.2 of [RFC7401] likewise apply to HIP DEX. and 6.7.2 of [RFC7401] likewise apply to HIP DEX.
6.6. Processing Incoming R1 Packets 6.6. Processing Incoming R1 Packets
R1 packets in HIP DEX are handled identically to HIPv2 (see R1 packets in HIP DEX are handled identically to HIPv2 (see
Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses
ECDH public keys as HIs and does not employ signatures. ECDH public keys as HIs and does not employ signatures.
As R1 is not signed and no proof is possible in the authenticity of
its contents, all processing of the R1 is provisional until verified
by the R2 processing.
The modified conceptual processing rules for responding to an R1 The modified conceptual processing rules for responding to an R1
packet are as follows: packet are as follows:
1. A system receiving an R1 MUST first check to see if it has sent 1. A system receiving an R1 MUST first check to see if it has sent
an I1 packet to the originator of the R1 packet (i.e., it has a an I1 packet to the originator of the R1 packet (i.e., it has a
HIP association that is in state I1-SENT and that is associated HIP association that is in state I1-SENT and that is associated
with the HITs in the R1). Unless the I1 packet was sent in with the HITs in the R1). Unless the I1 packet was sent in
opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP
addresses in the received R1 packet SHOULD be ignored by the R1 addresses in the received R1 packet SHOULD be ignored by the R1
processing and, when looking up the correct HIP association, the processing and, when looking up the correct HIP association, the
skipping to change at page 34, line 21 skipping to change at page 41, line 31
restarting the handshake, the Initiator MUST consult local restarting the handshake, the Initiator MUST consult local
policies (see Section 7) regarding the use of another, mutually policies (see Section 7) regarding the use of another, mutually
supported DH group for the subsequent handshake with the supported DH group for the subsequent handshake with the
Responder. Responder.
7. If the HIP association state is I2-SENT, the system MAY re-enter 7. If the HIP association state is I2-SENT, the system MAY re-enter
state I1-SENT and process the received R1 packet if it has a state I1-SENT and process the received R1 packet if it has a
larger R1 generation counter than the R1 packet responded to larger R1 generation counter than the R1 packet responded to
previously. previously.
8. The R1 packet can have the A-bit set - in this case, the system 8. The system SHOULD attempt to validate the HIT against the
MAY choose to refuse it by dropping the R1 packet and returning
to state UNASSOCIATED. The system SHOULD consider dropping the
R1 packet only if it used a NULL HIT in the I1 packet. If the
A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be
stored permanently.
9. The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host Identity to received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT. construct a HIT and verify that it matches the Sender's HIT.
10. The system MUST store the received R1 generation counter for 9. The system MUST store the received R1 generation counter for
future reference. future reference.
11. The system attempts to solve the puzzle in the R1 packet. The 10. The system attempts to solve the puzzle in the R1 packet. The
system MUST terminate the search after exceeding the remaining system MUST terminate the search after exceeding the remaining
lifetime of the puzzle. If the puzzle is not successfully lifetime of the puzzle. If the puzzle is not successfully
solved, the implementation MAY either resend the I1 packet solved, the implementation MAY either resend the I1 packet
within the retry bounds or abandon the HIP base exchange. within the retry bounds or abandon the HIP base exchange.
12. The system computes standard Diffie-Hellman keying material 11. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the according to the public value and Group ID provided in the
HOST_ID parameter. The Diffie-Hellman keying material Kij is HOST_ID parameter. The Diffie-Hellman keying material Kij is
used for key extraction as specified in Section 6.3. used for key extraction as specified in Section 6.3.
13. The system selects the HIP_CIPHER ID from the choices presented 12. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2 generating and using encryption keys, and when sending the I2
packet. If the proposed alternatives are not acceptable to the packet. If the proposed alternatives are not acceptable to the
system, it MAY either resend an I1 packet within the retry system, it MAY either resend an I1 packet within the retry
bounds or abandon the HIP base exchange. bounds or abandon the HIP base exchange.
14. The system chooses one suitable transport format from the 13. The system chooses one suitable transport format from the
TRANSPORT_FORMAT_LIST and includes the respective transport TRANSPORT_FORMAT_LIST and includes the respective transport
format parameter in the subsequent I2 packet. format parameter in the subsequent I2 packet.
15. The system initializes the remaining variables in the associated 14. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
16. The system prepares and sends an I2 packet as described in 15. The system prepares and sends an I2 packet as described in
Section 5.3.3. Section 5.3.3.
17. The system SHOULD start a timer whose timeout value SHOULD be 16. The system SHOULD start a timer whose timeout value SHOULD be
larger than the worst-case anticipated RTT, and MUST increment a larger than the worst-case anticipated RTT, and MUST increment a
trial counter associated with the I2 packet. The sender SHOULD trial counter associated with the I2 packet. The sender SHOULD
retransmit the I2 packet upon a timeout and restart the timer, retransmit the I2 packet upon a timeout and restart the timer,
up to a maximum of I2_RETRIES_MAX tries. up to a maximum of I2_RETRIES_MAX tries.
18. If the system is in state I1-SENT, it SHALL transition to state 17. If the system is in state I1-SENT, it SHALL transition to state
I2-SENT. If the system is in any other state, it remains in the I2-SENT. If the system is in any other state, it remains in the
current state. current state.
Note that step 4 from the original processing rules of HIPv2 Note that step 4 from the original processing rules of HIPv2
(signature verification) has been removed in the above processing (signature verification) has been removed in the above processing
rules for HIP DEX. Moreover, step 7 of the original processing rules rules for HIP DEX. Moreover, step 7 of the original processing rules
has been adapted in step 6 above to account for the fact that HIP DEX has been adapted in step 6 above to account for the fact that HIP DEX
uses ECDH public keys as HIs. The considerations about malformed R1 uses ECDH public keys as HIs. The considerations about malformed R1
packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX. packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX.
skipping to change at page 36, line 9 skipping to change at page 43, line 17
implementation dependent. See Appendix A in [RFC7401] for a implementation dependent. See Appendix A in [RFC7401] for a
description of an example implementation. description of an example implementation.
2. The system MUST check that the Responder's HIT corresponds to 2. The system MUST check that the Responder's HIT corresponds to
one of its own HITs and MUST drop the packet otherwise. one of its own HITs and MUST drop the packet otherwise.
3. The system MUST further check that the Initiator's HIT Suite is 3. The system MUST further check that the Initiator's HIT Suite is
supported. The Responder SHOULD silently drop I2 packets with supported. The Responder SHOULD silently drop I2 packets with
unsupported Initiator HITs. unsupported Initiator HITs.
4. If the system's state machine is in the R2-SENT state, the 4. The system MUST validate the Initiator's HI per Section 9.3.
5. If the system's state machine is in the R2-SENT state, the
system MUST check to see if the newly received I2 packet is system MUST check to see if the newly received I2 packet is
similar to the one that triggered moving to R2-SENT. If so, it similar to the one that triggered moving to R2-SENT. If so, it
MUST retransmit a previously sent R2 packet and reset the MUST retransmit a previously sent R2 packet and reset the
R2-SENT timer. The system SHOULD re-use the previously R2-SENT timer. The system SHOULD re-use the previously
established state to re-create the corresponding R2 packet in established state to re-create the corresponding R2 packet in
order to prevent unnecessary computation overhead. order to prevent unnecessary computation overhead.
5. If the system's state machine is in the I2-SENT state, the 6. If the system's state machine is in the I2-SENT state, the
system MUST make a comparison between its local and sender's system MUST make a comparison between its local and sender's
HITs (similarly as in Section 6.3). If the local HIT is smaller HITs (similarly as in Section 6.3). If the local HIT is smaller
than the sender's HIT, it should drop the I2 packet, use the than the sender's HIT, it should drop the I2 packet, use the
peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
#I from the R1 packet received earlier, and get the local #I from the R1 packet received earlier, and get the local
Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
from the I2 packet sent to the peer earlier. Otherwise, the from the I2 packet sent to the peer earlier. Otherwise, the
system processes the received I2 packet and drops any previously system processes the received I2 packet and drops any previously
derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY
keying material it might have generated upon sending the I2 keying material it might have generated upon sending the I2
packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY, packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY,
and the nonce #J are taken from the just arrived I2 packet. The and the nonce #J are taken from the just arrived I2 packet. The
local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the
nonce #I are the ones that were sent earlier in the R1 packet. nonce #I are the ones that were sent earlier in the R1 packet.
6. If the system's state machine is in the I1-SENT state, and the 7. If the system's state machine is in the I1-SENT state, and the
HITs in the I2 packet match those used in the previously sent I1 HITs in the I2 packet match those used in the previously sent I1
packet, the system uses this received I2 packet as the basis for packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes retransmitting I1 packets (provided that the I2 packet passes
the additional checks below). the additional checks below).
7. If the system's state machine is in any state other than 8. If the system's state machine is in any state other than
R2-SENT, the system SHOULD check that the echoed R1 generation R2-SENT, the system SHOULD check that the echoed R1 generation
counter in the I2 packet is within the acceptable range if the counter in the I2 packet is within the acceptable range if the
counter is included. Implementations MUST accept puzzles from counter is included. Implementations MUST accept puzzles from
the current generation and MAY accept puzzles from earlier the current generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly received I2 generations. If the generation counter in the newly received I2
packet is outside the accepted range, the I2 packet is stale packet is outside the accepted range, the I2 packet is stale
(and perhaps replayed) and SHOULD be dropped. (and perhaps replayed) and SHOULD be dropped.
8. The system MUST validate the solution to the puzzle as described 9. The system MUST validate the solution to the puzzle as described
in Section 6.1. in Section 6.1.
9. The I2 packet MUST have a single value in the HIP_CIPHER 10. The I2 packet MUST have a single value in the HIP_CIPHER
parameter, which MUST match one of the values offered to the parameter, which MUST match one of the values offered to the
Initiator in the R1 packet. Initiator in the R1 packet.
10. The system MUST derive Diffie-Hellman keying material Kij based 11. The system MUST derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the HOST_ID parameter. This on the public value and Group ID in the HOST_ID parameter. This
keying material is used to derive the keys of the Master Key SA keying material is used to derive the keys of the Master Key SA
as described in Section 6.3. If the Diffie-Hellman Group ID is as described in Section 6.3. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped. If the unsupported, the I2 packet is silently dropped. If the
processing time for the derivation of the Diffie-Hellman keying processing time for the derivation of the Diffie-Hellman keying
material Kij is likely to cause premature I2 retransmissions by material Kij is likely to cause premature I2 retransmissions by
the Initiator, the system MAY send a NOTIFY packet before the Initiator, the system MAY send a NOTIFY packet before
starting the key derivation process. The NOTIFY packet contains starting the key derivation process. The NOTIFY packet contains
a NOTIFICATION parameter with Notify Message Type a NOTIFICATION parameter with Notify Message Type
I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the
anticipated remaining processing time for the I2 packet in anticipated remaining processing time for the I2 packet in
milliseconds as two-octet Notification Data. milliseconds as two-octet Notification Data.
11. The implementation SHOULD also verify that the Initiator's HIT 12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2 in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not be able to make this packet. (Note: some middleboxes may not be able to make this
verification.) verification.)
12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
Other documents specifying transport formats (e.g., [RFC7402]) Other documents specifying transport formats (e.g., [RFC7402])
contain specifications for handling any specific transport contain specifications for handling any specific transport
selected. selected.
13. The system MUST verify the HIP_MAC according to the procedures 14. The system MUST verify the HIP_MAC according to the procedures
in Section 6.2. in Section 6.2.
14. If the checks above are valid, then the system proceeds with 15. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state. state machine remains in the same state.
15. The I2 packet may have the A-bit set - in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A-bit is set, the
Initiator's HIT is anonymous and MUST NOT be stored permanently.
16. The system MUST decrypt the keying material from the 16. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial ENCRYPTED_KEY parameter. This keying material is a partial
input to the key derivation process for the Pair-wise Key SA input to the key derivation process for the Pair-wise Key SA
(see Section 6.3). (see Section 6.3).
17. The system initializes the remaining variables in the associated 17. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
18. Upon successful processing of an I2 packet when the system's 18. Upon successful processing of an I2 packet when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or
skipping to change at page 39, line 9 skipping to change at page 46, line 12
HITs that were received in the R1 packet that caused the HITs that were received in the R1 packet that caused the
transition to the I2-SENT state. transition to the I2-SENT state.
3. The system MUST verify the HIP_MAC according to the procedures in 3. The system MUST verify the HIP_MAC according to the procedures in
Section 6.2. Section 6.2.
4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER,
HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2
packet and compare the results against the chosen suites. packet and compare the results against the chosen suites.
5. If any of the checks above fail, there is a high probability of 5. The system MUST validate the Responder's HI per Section 9.3.
6. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy. system SHOULD act accordingly (e.g. aborting with logging),
based on its local policy.
6. The system MUST decrypt the keying material from the 7. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial input ENCRYPTED_KEY parameter. This keying material is a partial input
to the key derivation process for the Pair-wise Key SA (see to the key derivation process for the Pair-wise Key SA (see
Section 6.3). Section 6.3).
7. Upon successful processing of the R2 packet, the state machine 8. Upon successful processing of the R2 packet, the state machine
transitions to state ESTABLISHED. transitions to state ESTABLISHED.
Note that step 4 (signature verification) from the original Note that step 4 (signature verification) from the original
processing rules of HIPv2 has been replaced with a negotiation re- processing rules of HIPv2 has been replaced with a negotiation re-
evaluation in the above processing rules for HIP DEX. Moreover, step evaluation in the above processing rules for HIP DEX. Moreover, step
6 has been added to the processing rules. 6 has been added to the processing rules.
6.9. Processing Incoming NOTIFY Packets 6.9. Processing Incoming NOTIFY Packets
Processing of NOTIFY packets is OPTIONAL. If processed, any errors Processing of NOTIFY packets is OPTIONAL. If processed, any errors
skipping to change at page 40, line 29 skipping to change at page 47, line 38
6.11. Handling State Loss 6.11. Handling State Loss
Implementors MAY choose to use non-volatile, secure storage for HIP Implementors MAY choose to use non-volatile, secure storage for HIP
states in order for them to survive a system reboot. If no secure states in order for them to survive a system reboot. If no secure
storage capabilities are available, the system SHOULD delete the storage capabilities are available, the system SHOULD delete the
corresponding HIP state, including the keying material. If the corresponding HIP state, including the keying material. If the
implementation does drop the state (as RECOMMENDED), it MUST also implementation does drop the state (as RECOMMENDED), it MUST also
drop the peer's R1 generation counter value, unless a local policy drop the peer's R1 generation counter value, unless a local policy
explicitly defines that the value of that particular host is stored. explicitly defines that the value of that particular host is stored.
Such storing of the R1 generation counter values MUST be configured
by explicit HITs. Storing of the R1 generation counter values and ENCRYPTED_KEY counter
(Section 5.2.5) MUST be configured by explicit HITs.
7. HIP Policies 7. HIP Policies
There are a number of variables that will influence the HIP exchanges There are a number of variables that will influence the HIP exchanges
that each host must support. The value of puzzle difficulty K used that each host must support. The value of puzzle difficulty K used
in the HIP R1 must be chosen with care. Values for the K that are in the HIP R1 must be chosen with care. Values for the K that are
too high will exclude clients with weak CPUs because these devices too high will exclude clients with weak CPUs because these devices
cannot solve the puzzle within a reasonable amount of time. The K cannot solve the puzzle within a reasonable amount of time. The K
value should only be raised if a Responder is under high load, i.e., value should only be raised if a Responder is under high load, i.e.,
it cannot process all incoming HIP handshakes any more. it cannot process all incoming HIP handshakes any more.
If a Responder is not under high load, K SHOULD be 0. If a Responder is not under high load, K SHOULD be 0.
All HIP DEX implementations SHOULD provide for an Access Control List All HIP DEX implementations SHOULD provide for an Access Control List
(ACL), representing for which hosts they accept HIP diet exchanges, (ACL), representing for which hosts they accept HIP diet exchanges,
and the preferred transport format and local lifetimes. Wildcarding and the preferred transport format and local lifetimes. Wildcarding
SHOULD be supported for such ACLs. SHOULD be supported for such ACLs.
7.1. HIT/HI ACL
Both the Initiator and Responder SHOULD implement an ACL. Minimally,
these ACLs will be a list of trusted HIT/HIs. They may also contain
the password used in the password-based two-factor authentication
(Appendix B) and preferred HIT Suite.
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
the R1, I2, and optionally NOTIFY packets) MUST be validated as well,
when present in the ACL. This is the defense against collision and
second-image attacks on the HIT generation.
Devices with no input mechanism (e.g. sensors) SHOULD accept R1
packets from unknown HITs. These R1 packets SHOULD contain the start
of the password-based two-factor authentication . If the R2 for this
HIT indicates success, then the device may add this HIT/HI to its ACL
for future use.
Devices unable to manage an ACL (e.g. sensors) are subject to MITM
attacks, even with the use of the password authentication (password
theft by attacker). As long as the other peer (e.g. sensor
controller) does use an ACL, the attack can be recognized there and
addressed. This is often seen where the sensor does not appear as
properly operating with the controller, as the attacker cannot
impersonate information in the ACL.
8. Interoperability between HIP DEX and HIPv2 8. Interoperability between HIP DEX and HIPv2
HIP DEX and HIPv2 both use the same protocol number and packet HIP DEX and HIPv2 both use the same protocol number and packet
formats. Hence, an implementation that either supports HIP DEX or formats. Hence, an implementation that either supports HIP DEX or
HIPv2 has to be able to detect the dialect that the peer is speaking. HIPv2 has to be able to detect the dialect that the peer is speaking.
This section outlines how a HIP DEX implementation can achieve such This section outlines how a HIP DEX implementation can achieve such
detection for the two relevant cases where: detection for the two relevant cases where:
1. the Initiator supports HIP DEX and the Responder supports HIP 1. the Initiator supports HIP DEX and the Responder supports HIP
BEX, BEX,
skipping to change at page 41, line 51 skipping to change at page 49, line 37
HIP DEX closely resembles HIPv2. As such, the security HIP DEX closely resembles HIPv2. As such, the security
considerations discussed in Section 8 of [RFC7401] similarly apply to considerations discussed in Section 8 of [RFC7401] similarly apply to
HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated
Diffie-Hellman key exchange of HIPv2 with an exchange of random Diffie-Hellman key exchange of HIPv2 with an exchange of random
keying material that is encrypted with a Diffie-Hellman derived key. keying material that is encrypted with a Diffie-Hellman derived key.
Both the Initiator and Responder contribute to this keying material. Both the Initiator and Responder contribute to this keying material.
As a result, the following additional security considerations apply As a result, the following additional security considerations apply
to HIP DEX: to HIP DEX:
o The strength of the keys for the Pair-wise Key SA is based on the * The strength of the keys for both the Master and Pair-wise Key SAs
quality of the random keying material generated by the Initiator is based on the quality of the random keying material generated by
and the Responder. As either peer may be a sensor or an actuator the Initiator and the Responder. As either peer may be a sensor
device, there is a natural concern about the quality of its random or an actuator device, there is a natural concern about the
number generator. quality of its random number generator. Thus at least a CSPRNG
SHOULD be used.
o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. * HIP DEX lacks the Forward Secrecy (FS) property of HIPv2.
Consequently, if an HI is compromised, all previous HIP Consequently, if an HI is compromised, all previous HIP
connections protected with that HI are compromised as explained in connections protected with that HI are compromised as explained in
Section 1. Section 1.
o The puzzle mechanism using CMAC explained in Section 4.1.1 may * The HIP DEX HIT generation may present new attack opportunities.
need further study regarding the level of difficulty in order to
establish best practices with current generation of constrained
devices.
o The HIP DEX HIT generation may present new attack opportunities.
Hence, HIP DEX HITs MUST NOT be used as the only means to identify Hence, HIP DEX HITs MUST NOT be used as the only means to identify
a peer in an ACL. Instead, the use of the peer's HI is a peer in an ACL. Instead, the use of the peer's HI is
recommended as explained in Section 3. recommended as explained in Section 3.
o The R1 packet is unauthenticated and offers an adversary a new * The R1 packet is unauthenticated and offers an adversary a new
attack vector against the Initiator. This is mitigated by only attack vector against the Initiator. This is mitigated by only
processing a received R1 packet when the Initiator has previously processing a received R1 packet when the Initiator has previously
sent a corresponding I1 packet. Moreover, the Responder repeats sent a corresponding I1 packet. Moreover, the Responder repeats
the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and
TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to
enable the Initiator to verify that these parameters have not been enable the Initiator to verify that these parameters have not been
modified by an attacker in the unprotected R1 packet as explained modified by an attacker in the unprotected R1 packet as explained
in Section 6.8. in Section 6.8.
o Contrary to HIPv2, HIP DEX does not provide for end-point * Contrary to HIPv2, HIP DEX does not provide for end-point
anonymity for the Initiator or Responder. Thus, any signaling anonymity for the Initiator or Responder. Thus, any signaling
that indicates such anonymity should be ignored as explained in that indicates such anonymity should be ignored as explained in
Section 1.1. Section 1.1.
* It is critical to properly manage the ENCRYPTED_KEY counter
(Section 5.2.5). If non-volatile store is used to maintain HIP
state across system resets, then this counter MUST be part of the
state store.
The optional retransmission extension of HIP DEX is based on a NOTIFY The optional retransmission extension of HIP DEX is based on a NOTIFY
packet that the Responder can use to inform the Initiator about the packet that the Responder can use to inform the Initiator about the
reception of an I2 packet. The Responder, however, cannot protect reception of an I2 packet. The Responder, however, cannot protect
the authenticity of this packet as it did not yet set up the Master the authenticity of this packet as it did not yet set up the Master
Key SA. Hence, an eavesdropping adversary may send spoofed reception Key SA. Hence, an eavesdropping adversary may send spoofed reception
acknowledgments for an overheard I2 packet and signal an arbitrary I2 acknowledgements for an overheard I2 packet and signal an arbitrary
processing time to the Initiator. The adversary can, e.g., indicate I2 processing time to the Initiator. The adversary can, e.g.,
a lower I2 processing time than actually required by the Responder in indicate a lower I2 processing time than actually required by the
order to cause premature retransmissions. To protect against this Responder in order to cause premature retransmissions. To protect
attack, the Initiator SHOULD set the NOTIFY-based timeout value to against this attack, the Initiator SHOULD set the NOTIFY-based
the maximum indicated packet processing time in case of conflicting timeout value to the maximum indicated packet processing time in case
NOTIFY packets. This allows the legitimate Responder to extend the of conflicting NOTIFY packets. This allows the legitimate Responder
retransmission timeout to the intended length. The adversary, to extend the retransmission timeout to the intended length. The
however, can still arbitrarily delay the protocol handshake beyond adversary, however, can still arbitrarily delay the protocol
the Responder's actual I2 processing time. To limit the extend of handshake beyond the Responder's actual I2 processing time. To limit
such a maliciously induced handshake delay, this specification the extend of such a maliciously induced handshake delay, this
additionally requires the Initiator not to set the NOTIFY-based specification additionally requires the Initiator not to set the
timeout value higher than allowed by a local policy. NOTIFY-based timeout value higher than allowed by a local policy.
Section 5.3.1 mentions that implementations need to be able to handle Section 5.3.1 mentions that implementations need to be able to handle
storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre- storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre-
computated in HIP DEX and also the state machine does not include an computed in HIP DEX and also the state machine does not include an
"R1_SENT" state (that would enable caching of R1 packets). "R1_SENT" state (that would enable caching of R1 packets).
Therefore, an implementation has to cache information (e.g., at least Therefore, an implementation has to cache information (e.g., at least
the HITs) from incoming I1 packets and rate control the incoming I1 the HITs) from incoming I1 packets and rate control the incoming I1
packets to avoid unnecessary packet processing during I1 packet packets to avoid unnecessary packet processing during I1 packet
storms. storms.
9.1. Caution on using HIP DEX rather than HIP BEX
Due to the substantially reduced security guarantees of HIP DEX
compared to HIP BEX, HIP DEX MUST only be used when at least one of
the two endpoints is a class 0 or 1 constrained device defined in
Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both
endpoints are class 2 devices or unconstrained.
9.2. Use of AES-CTR for HIP Parameter Encryption
AES-CTR is a basic cipher mode that does not accept an initialization
vector to allow for key re-use. In essence, it stretches the initial
key into a much longer keystream (akin to a stream cipher) that is
used like a one-time pad. Any reuse of that keystream breaks the
confidentiality of the protected data, so when using AES-CTR, care
must be taken to ensure that within a given keystream the counter
value is never reused, and that any given key is only used to
generate a single keystream. The integration of AES-CTR into IPsec
ESP (RFC 3686) used by HIP (and, thus, by HIP-DEX) improves on the
situation by partitioning the 128-bit counter space into a 32-bit
nonce, 64-bit IV, and 32-bits of counter. The counter is incremented
to provide a keystream for protecting a given packet, the IV is
chosen by the encryptor in a "manner that ensures uniqueness", and
the nonce persists for the lifetime of a given SA. In particular, in
this usage the nonce must be unpredictable, not just single-use. In
HIP-DEX, the properties of nonce uniqueness/unpredictability and per-
packet IV uniqueness are defined in Section 5.2.2.
9.3. Need to Validate Public Keys
With the curves specified here, there is a straightforward key
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
Public Key.
For Curve25519 and Curve448, the contents of the public value are the
byte string inputs and outputs of the corresponding functions defined
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
5.
10. IANA Considerations 10. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
Parameters" registries have been made: Parameters" registries have been made:
Parameter Type This document defines the new HIP parameter ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643)
"ENCRYPTED_KEY" with type number TBD1 (suggested: 643) (see (see Section 5.2.5) in the "Parameter Types" subregistry of the
Section 5.2.5). "Host Identity Protocol (HIP) Parameters" registry.
DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519
with value TBD7 (suggested: 12) and Curve448 with value TBD8
(suggested: 13) (see Section 5.2.1) in the "Group IDs" subregistry
of the "Host Identity Protocol (HIP) Parameters" registry.
HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD"
without four-bit ID of TBD2 (suggested: 8) and eight-bit encoding without four-bit ID of TBD2 (suggested: 4) and eight-bit encoding
of TBD3 (suggested: 0x80) (see Section 5.2.4). of TBD3 (suggested: 0x40) (see Section 5.2.4) in the "HIT Suite
ID" subregistry of the "Host Identity Protocol (HIP) Parameters"
registry.
HIP Cipher ID This document defines the new HIP Cipher ID "AES- HIP Cipher ID This document defines the new HIP Cipher ID "AES-
128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2). 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2)
in the "HIP Cipher ID" subregistry of the "Host Identity Protocol
(HIP) Parameters" registry.
HI Algorithm This document defines the new HI Algorithm "ECDH" with HI Algorithm This document defines the new HI Algorithm "ECDH" with
type number TBD5 (suggested: 11) (see Section 5.2.3). type number TBD5 (suggested: 11) (see Section 5.2.3) in the "HI
Algorithm" subregistry of the "Host Identity Protocol (HIP)
Parameters" registry.
I_NONCE "I_NONCE" with type number TBD6 (suggested: 644) (see
Section 5.2.6) in the "Parameter Types" subregistry of the "Host
Identity Protocol (HIP) Parameters" registry.
ECC Curve Label This document specifies a new algorithm-specific ECC Curve Label This document specifies a new algorithm-specific
subregistry named "ECDH Curve Label". The values for this subregistry named "ECDH Curve Label". The values for this
subregistry are defined in Section 5.2.1. subregistry are defined in Section 5.2.1. The complete list of
algorithms for the DH_GROUP_LIST parameter are listed in the
"Group IDs" subregistry of the "Host Identity Protocol (HIP)
Parameters" registry.
11. Acknowledgments 11. Acknowledgements
The drive to put HIP on a cryptographic 'Diet' came out of a number The drive to put HIP on a cryptographic 'Diet' came out of a number
of discussions with sensor vendors at IEEE 802.15 meetings. David of discussions with sensor vendors at IEEE 802.15 meetings. David
McGrew was very helpful in crafting this document. Special thanks to McGrew was very helpful in crafting this document. Special thanks to
Miika Komu for reviewing this document in the context of Convince Mohit Sethi in helping with the draft during IESG process.
Celtic+ project.
Special thanks to Dr. Hugo Krawczyk for early guidance on the IRTF
CFRG list on how to safely use CMAC in a key derivation function.
And Dr. Lily Chen of NIST who spent time discussing CKDF at IEEE 802
and IETF meetings.
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-09 12.1. Changes in draft-ietf-hip-dex-24
o Fixed values for * Apply editorial comments from Eric Vyncke in Section 1.2
* DH_GROUP_LIST * Added SIGMA and ATmega328P references
* HIT_SUITE_LIST * Added non-paywall URL for EfficientECC reference
* Added Section 9.1 and removed last NIST P-384 text.
12.2. 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.3. Changes in draft-ietf-hip-dex-22
* Apply editorial comment from Roman Danyliw
* Clarify IKM content for Master SA and Pairwise SA in Section 6.3
* Add behavior on BEX before DEX to Section 1.2
* Added [NIST.SP.800-56C], [NIST.SP.800-108], and [KeyDerivation] as
source guidance for CKDF to Section 6.3
* Removed NIST curves from Section 5.2.1 and Section 5.2.3 as too
slow for 8-bit CPUs
12.4. Changes in draft-ietf-hip-dex-21
* Clarified on security concerns of using AES-CTR in Section 9.2
* Edits for SECDIR comments
12.5. Changes in draft-ietf-hip-dex-20
* Clarified text on AES-CTR for HIP parameter encryption. This
includes Section 9.2
* Clarified text on R2 processing to validate content of R1.
* Clarified Applicability section.
* Expanded Fig 1.
* Clarified differences between BEX and DEX state machines.
* ESP transform is MTI and ESP-TCP is Experimental.
12.6. Changes in draft-ietf-hip-dex-19
* Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
* Remove NIST P-521 from DH_GROUP_LIST.
* Remove NULL-ENCRYPT.
* Added reference to rfc8005 for HIT lookup in DNS.
* Remove setting Control bit: A.
* Many textual improvements per Benjamin Kaduk comments.
12.7. Changes in draft-ietf-hip-dex-18
* Changed Perfect Forward Secrecy to Forward Secrecy.
12.8. Changes in draft-ietf-hip-dex-17
* Added hex values for strings CKDF-Extract and CKDF-Expand.
* Replace Perfect Forward Secrecy with Forward Secrecy.
12.9. Changes in draft-ietf-hip-dex-16
* Remove old placeholder text.
* Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it.
12.10. Changes in draft-ietf-hip-dex-15
* Added Public Key validation in I2 and R2 processing.
* Added ACL processing (Section 7.1).
* Added IANA instructions for DH_GROUP_LIST.
12.11. Changes in draft-ietf-hip-dex-14
* Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment
12.12. Changes in draft-ietf-hip-dex-12 and 13
* Nits from Jeff Ahrenholz (including some formatting issues)
12.13. Changes in draft-ietf-hip-dex-11 and 12
* Included more precise references to the IANA subregistries
* Addressed GEN-ART feedback from Francis Dupont
* Added reasoning for FS in a separate section, and it is mentioned
also in the abstract and intro.
* Donald Eastlake's (secdir) nits addressed
* Resolved IANA nits from Amanda Baber.
* New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (removed in ver 16), "Need to Validate Public
Keys" (Section 9.3), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns.
12.14. Changes in draft-ietf-hip-dex-11
* Update IANA considerations as requested by Eric Envyncke
12.15. Changes in draft-ietf-hip-dex-10
* Explanations on why the document includes so many SHOULDs
12.16. Changes in draft-ietf-hip-dex-09
* Fixed values for
- DH_GROUP_LIST
- HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.2. Changes in draft-ietf-hip-dex-05 12.17. Changes in draft-ietf-hip-dex-05
o Clarified main differences between HIP BEX and HIP DEX in * Clarified main differences between HIP BEX and HIP DEX in
Section 1. Section 1.
o Addressed MitM attack in Section 8. * Addressed MitM attack in Section 8.
o Minor editorial changes. * Minor editorial changes.
12.3. Changes in draft-ietf-hip-dex-04 12.18. Changes in draft-ietf-hip-dex-04
o Added new paragraph on rekeying procedure with HIP DEX. * Added new paragraph on rekeying procedure with HIP DEX.
o Updated references. * Updated references.
o Editorial changes. * Editorial changes.
12.4. Changes in draft-ietf-hip-dex-03 12.19. Changes in draft-ietf-hip-dex-03
o Added new section on HIP DEX/HIPv2 interoperability * Added new section on HIP DEX/HIPv2 interoperability
o Added reference to RFC4493 for CMAC. * Added reference to RFC4493 for CMAC.
o Added reference to RFC5869 for CKDF. * Added reference to RFC5869 for CKDF.
o Added processing of NOTIFY message in I2-SENT of state diagram. * Added processing of NOTIFY message in I2-SENT of state diagram.
o Editorial changes. * Editorial changes.
12.5. Changes in draft-ietf-hip-dex-02 12.20. Changes in draft-ietf-hip-dex-02
o Author address change. * Author address change.
12.6. Changes in draft-ietf-hip-dex-01 12.21. Changes in draft-ietf-hip-dex-01
o 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.7. Changes in draft-ietf-hip-dex-00 12.22. Changes in draft-ietf-hip-dex-00
o The Internet Draft was adopted by the HIP WG.
12.8. Changes in draft-moskowitz-hip-rg-dex-06 * The Internet Draft was adopted by the HIP WG.
o A major change in the ENCRYPT parameter to use AES-CTR rather than 12.23. Changes in draft-moskowitz-hip-rg-dex-06
* A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
12.9. Changes in draft-moskowitz-hip-dex-00 12.24. Changes in draft-moskowitz-hip-dex-00
o 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.
o Added the change section. * Added the change section.
o Added a Definitions section. * Added a Definitions section.
o 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.
o Cleaned up KEYMAT Generation text. * Cleaned up KEYMAT Generation text.
o 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.10. Changes in draft-moskowitz-hip-dex-01 12.25. Changes in draft-moskowitz-hip-dex-01
o Numerous editorial changes. * Numerous editorial changes.
o New retransmission strategy. * New retransmission strategy.
o New HIT generation mechanism. * New HIT generation mechanism.
o Modified layout of ENCRYPTED_KEY parameter. * Modified layout of ENCRYPTED_KEY parameter.
o Clarify to use puzzle difficulty of zero under normal network * Clarify use puzzle difficulty of zero under normal network
conditions. conditions.
o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to * Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to
MUST). MUST).
o 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).
o 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.
o Added new author. * Added new author.
12.11. Changes in draft-moskowitz-hip-dex-02 12.26. Changes in draft-moskowitz-hip-dex-02
o Introduced formal definition of FOLD function. * Introduced formal definition of FOLD function.
o Clarified use of CMAC for puzzle computation in section "Solving * Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle". the Puzzle".
o Several editorial changes. * Several editorial changes.
12.12. Changes in draft-moskowitz-hip-dex-03 12.27. Changes in draft-moskowitz-hip-dex-03
o Addressed HI crypto agility. * Addressed HI crypto agility.
o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. * Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
o Extended the IV in the ENCRYPTED_KEY parameter. * Extended the IV in the ENCRYPTED_KEY parameter.
o Introduced forward-references to HIP DEX KEYMAT process and * 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 * Replaced Appendix A on "C code for ECC point multiplication" with
short discussion in introduction. short discussion in introduction.
o Updated references. * Updated references.
o Further editorial changes. * Further editorial changes.
12.13. Changes in draft-moskowitz-hip-dex-04 12.28. Changes in draft-moskowitz-hip-dex-04
o Improved retransmission extension. * Improved retransmission extension.
o Updated and strongly revised packet processing rules. * Updated and strongly revised packet processing rules.
o Updated security considerations. * Updated security considerations.
o Updated IANA considerations. * Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11. * Move the HI Algorithm for ECDH to a value of 11.
o Many editorial changes. * 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 :: the CMAC mode for authentication", National
Institute of Standards and Technology report,
DOI 10.6028/nist.sp.800-38b, 2016,
<https://doi.org/10.6028/nist.sp.800-38b>.
[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 48, line 11 skipping to change at page 59, line 47
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<https://www.rfc-editor.org/info/rfc7402>. <https://www.rfc-editor.org/info/rfc7402>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
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 [ATmega328P]
Cryptography", IEEE Transactions on Information Atmel, "ATmega328P 8-bit AVR Microcontroller with 32K
Theory vol. IT-22, number 6, pages 644-654, Nov 1976. Bytes In-System Programmable Flash", SEC 2 , 2015,
<https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-
7810-Automotive-Microcontrollers-
ATmega328P_Datasheet.pdf>.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. [DH76] Diffie, W. and M. Hellman, "New directions in
Wehrle, "Tailoring End-to-End IP Security Protocols to the cryptography", IEEE Transactions on Information
Internet of Things", in Proceedings of IEEE International Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638,
Conference on Network Protocols (ICNP 2013), October 2013. November 1976, <https://doi.org/10.1109/tit.1976.1055638>.
[I-D.ietf-hip-rfc4423-bis] [EfficientECC]
Nascimento, E., Lopez, 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://www.researchgate.net/publication/300253314_Effici
ent_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_M
icrocontrollers>.
[hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-20 (work in Architecture", Work in Progress, Internet-Draft, draft-
progress), February 2019. ietf-hip-rfc4423-bis-20, 14 February 2019,
<https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-
20>.
[IEEE.802-11.2007] [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Engineers, I. O. E. A. E., "Information technology - Wehrle, "Tailoring end-to-end IP security protocols to the
Internet of Things", 2013 21st IEEE International
Conference on Network Protocols (ICNP),
DOI 10.1109/icnp.2013.6733571, October 2013,
<https://doi.org/10.1109/icnp.2013.6733571>.
[IEEE.802-11.2016]
"IEEE Standard for Information technology--
Telecommunications and information exchange between Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific systems Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium Access Control requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", (MAC) and Physical Layer (PHY) Specifications",
IEEE Standard 802.11, June 2007, IEEE standard, DOI 10.1109/ieeestd.2016.7786995, n.d.,
<http://standards.ieee.org/getieee802/ <https://doi.org/10.1109/ieeestd.2016.7786995>.
download/802.11-2007.pdf>.
[IEEE.802-15-4.2011] [IEEE.802-15-4.2015]
Engineers, I. O. E. A. E., "Information technology - Engineers, I. O. E. A. E., "Information technology -
Telecommunications and information exchange between Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific systems - Local and metropolitan area networks - Specific
requirements - Part 15.4: Wireless Medium Access Control requirements - Part 15.4: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-Rate (MAC) and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks (WPANs)", IEEE Standard Wireless Personal Area Networks (WPANs)", IEEE Standard
802.15.4, September 2011, 802.15.4, December 2015,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.15.4-2011.pdf>. download/802.15.4-2015.pdf>.
[LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for [KeyDerivation]
Dodis, Y., Gennaro, R., Håstad, J., Krawczyk, H., and T.
Rabin, "Randomness Extraction and Key Derivation Using the
CBC, Cascade and HMAC Modes", Advances in Cryptology -
CRYPTO 2004 pp. 494-510, DOI 10.1007/978-3-540-28628-8_30,
2004, <https://doi.org/10.1007/978-3-540-28628-8_30>.
[LN08] Liu, A. and P. 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 2008 International Conference on Information Processing in
Processing in Sensor Networks (IPSN 2008), April 2008. Sensor Networks (ipsn 2008), DOI 10.1109/ipsn.2008.47,
April 2008, <https://doi.org/10.1109/ipsn.2008.47>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [NIST.SP.800-108]
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June Chen, L., "Recommendation for key derivation using
2006, <https://www.rfc-editor.org/info/rfc4493>. pseudorandom functions (revised)", National Institute of
Standards and Technology report,
DOI 10.6028/nist.sp.800-108, 2009,
<https://doi.org/10.6028/nist.sp.800-108>.
[NIST.SP.800-56C]
Chen, L., "Recommendation for key derivation through
extraction-then-expansion", National Institute of
Standards and Technology report,
DOI 10.6028/nist.sp.800-56c, 2011,
<https://doi.org/10.6028/nist.sp.800-56c>.
[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
Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
DOI 10.17487/RFC5903, June 2010,
<https://www.rfc-editor.org/info/rfc5903>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>. <https://www.rfc-editor.org/info/rfc6090>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[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 [SIGMA] Krawczyk, H., "SIGMA: the ‘SIGn-and-MAc’ Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", 2003,
<https://webee.technion.ac.il/~hugo/sigma-pdf.pdf>.
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 to identify 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 IEDG review, a concern was raised on the number of SHOULDS in During IESG review, a concern was raised on the number of SHOULDs in
this document. Here is an analysis of the 57 SHOULDS in HIP DEX. this document. Here is an analysis of the 57 SHOULDs in HIP DEX.
46 of SHOULDS are also in [RFC7401]. Here are the sections with 46 of SHOULDs are also in [RFC7401]. Here are the sections with
SHOULDS that match up with [RFC7401]: SHOULDs that match up with [RFC7401]:
5.2.2. HIP_CIPHER (same as 7401) 5.2.2. HIP_CIPHER (same as 7401)
6.5. Processing Incoming I1 Packets 6.5. Processing Incoming I1 Packets
3. (same as 7401) 3. (same as 7401)
5. (same as 7401) 5. (same as 7401)
6.6. Processing Incoming R1 Packets (same as 7401) 6.6. Processing Incoming R1 Packets (same as 7401)
6.7. Processing Incoming I2 Packets 6.7. Processing Incoming I2 Packets
skipping to change at page 51, line 28 skipping to change at page 63, line 31
6.8. Processing Incoming R2 Packets 6.8. Processing Incoming R2 Packets
5. (same as 7401) 5. (same as 7401)
6.9. Processing Incoming NOTIFY Packets 6.9. Processing Incoming NOTIFY Packets
1st para (same as 7401) 1st para (same as 7401)
6.11. Handling State Loss (same as 7401) 6.11. Handling State Loss (same as 7401)
7. HIP Policies (1st and 3rd same as 7401) 7. HIP Policies (1st and 3rd same as 7401)
Many of the other 11 SHOULDS are due to the nature of constrained Many of the other 11 SHOULDs are due to the nature of constrained
devices and in most cases the text points this out: devices and in most cases the text points this out:
In Section 4.1.1, this is clearly adjusting for how the puzzle could In Section 4.1.1, this is clearly adjusting for how the puzzle could
actually be an attack against a constrained device. Same situation actually be an attack against a constrained device. Same situation
in Section 5.3.2. in Section 5.3.2.
Section 6, clearly states that:
it should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further
implementation experience provides better guidance.
thus the SHOULD here is informative of future guidance.
The SHOULD in Section 6.3, clearly reflects new work with the new The SHOULD in Section 6.3, clearly reflects new work with the new
Sponge Function KDFs: Sponge Function KDFs:
The keys derived for the Pair-wise Key SA are not used during the HIP The keys derived for the Pair-wise Key SA are not used during the HIP
DEX handshake. Instead, these keys are made available as payload DEX handshake. Instead, these keys are made available as payload
protection keys (e.g., for IPsec). Some payload protection protection keys (e.g., for IPsec). Some payload protection
mechanisms have their own Key Derivation Function, and if so this mechanisms have their own Key Derivation Function, and if so this
mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST
be used to derive the keys of the Pair-wise Key SA based on the be used to derive the keys of the Pair-wise Key SA based on the
concatenation of the random values that are contained in the concatenation of the random values that are contained in the
exchanged ENCRYPTED_KEY parameters. exchanged ENCRYPTED_KEY parameters.
In Section 6.5, the reason why this is a SHOULD should be clear to In Section 6.5, the reason why this is a SHOULD should be clear to
any implementer. That is the HIT Suite list in I1 is a desire on any implementer. That is the HIT Suite list in I1 is a desire on
what suite to use. The Responder may have 'different ideas' about what suite to use. The Responder may have 'different ideas' about
the Suite to use (like what it supports). Thus it is best that the the Suite to use (like what it supports). Thus it is best that the
Responder selects a DEX HIT, but there are good reasons, in an Responder selects a DEX HIT, but there are good reasons, in an
implementation not to do so. The implementer should know this and implementation not to do so. The implementer should know this and
will deal with it appropriately. will deal with it appropriately.
The SHOULDS in Section 6.7 and Section 6.9 are there for The SHOULDs in Section 6.7 and Section 6.9 are there for
considerations for constrained systems. Some constrained systems considerations for constrained systems. Some constrained systems
need this approach, others may not. need this approach, others may not.
The 2nd SHOULD in Section 7 follows the same as above. ACLs and The 2nd SHOULD in Section 7 follows the same as above. ACLs and
constrained systems tend to go together. constrained systems tend to go together.
Similarly in Section 8 the SHOULD is again is highlighting Similarly in Section 8 the SHOULD is again is highlighting
constrained system processing considerations. constrained system processing considerations.
Authors' Addresses Authors' Addresses
Robert Moskowitz (editor) Robert Moskowitz (editor)
HTT Consulting HTT Consulting
Oak Park, MI Oak Park, MI
USA United States of America
EMail: rgm@htt-consult.com Email: rgm@htt-consult.com
Rene Hummen Rene Hummen
Hirschmann Automation and Control Hirschmann Automation and Control
Stuttgarter Strasse 45-51 Stuttgarter Strasse 45-51
Neckartenzlingen 72654 72654 Neckartenzlingen
Germany Germany
EMail: rene.hummen@belden.com Email: rene.hummen@belden.com
Miika Komu Miika Komu
Ericsson Research, Finland Ericsson Research, Finland
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 FI-02420 Jorvas
Finland Finland
EMail: miika.komu@ericsson.com Email: miika.komu@ericsson.com
 End of changes. 249 change blocks. 
556 lines changed or deleted 1066 lines changed or added

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