draft-ietf-hip-dex-21.txt   draft-ietf-hip-dex-22.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: January 9, 2021 Hirschmann Automation and Control Expires: 17 June 2021 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
July 8, 2020 14 December 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-21 draft-ietf-hip-dex-22
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. Unlike HIPv2, HIP DEX does not support Forward protocol data. Unlike HIPv2, HIP DEX does not support Forward
Secrecy (FS), and MUST only be used on devices where FS is Secrecy (FS), and MUST only be used on devices where FS is
prohibitively expensive. In addition, HIP DEX can also be used as a prohibitively expensive. In addition, HIP DEX can also be used as a
keying mechanism for security primitives at the MAC layer, e.g., for keying mechanism for security primitives at the MAC layer, e.g., for
IEEE 802.15.4 networks. IEEE 802.15.4 networks.
skipping to change at page 1, line 47 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2021. This Internet-Draft will expire on 17 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 6
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 12
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 12
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 15
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 15 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 16
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 19 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 20
4.1.4. User Data Considerations . . . . . . . . . . . . . . 20 4.1.4. User Data Considerations . . . . . . . . . . . . . . 21
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 20 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 20 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 21
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 20 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 21 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 22
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 21 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 22
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 23 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 24
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 23 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 24
5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 25
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 25 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 26
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 26 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 27
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 28 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 29
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 29 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 30
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 30
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 30 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 31 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 32
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 31 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 32
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 31 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 32
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 32
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 34
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 37
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 37
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 38
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 41
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 44
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 45
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 46
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 46
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 46
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 47
9.1. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 48 9.1. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 50
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 50
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 49 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.2. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 50 12.1. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 52
12.3. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 50 12.2. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 52
12.4. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 50 12.3. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 52
12.5. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 50 12.4. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 52
12.6. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 50 12.5. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 53
12.7. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 51 12.6. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 53
12.8. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 51 12.7. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 53
12.9. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 51 12.8. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 53
12.10. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 51 12.9. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 53
12.11. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 51 12.10. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 53
12.12. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 51 12.11. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 53
12.13. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 54
12.14. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 52 12.13. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 54
12.15. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 52 12.14. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 54
12.16. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 52 12.15. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 54
12.17. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 52 12.16. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 54
12.18. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 52 12.17. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 55
12.19. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 52 12.18. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 55
12.20. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 53 12.19. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 55
12.21. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 53 12.20. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 55
12.22. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 53 12.21. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 55
12.23. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 54 12.22. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 55
12.24. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 54 12.23. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 56
12.25. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 54 12.24. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 12.25. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 56
13.1. Normative References . . . . . . . . . . . . . . . . . . 54 12.26. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 58 HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 60
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 58 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX). HIP DEX is derived from the Base EXchange (BEX) of the Host DEX), specifically developed for use on low end processors that
Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the cannot support the cryptographic requirements of HIP BEX. HIP DEX is
protocol semantics as well as the general packet structure of HIPv2. derived from the Base EXchange (BEX) of the Host Identity Protocol
Hence, it is recommended that [RFC7401] is well-understood before Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol
reading this document. 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.
skipping to change at page 4, line 49 skipping to change at page 5, line 7
SHA-256, or SHA-384. SHA-256, or SHA-384.
2. HIP DEX forfeits the HIPv2 Forward Secrecy property due to the 2. HIP DEX forfeits the HIPv2 Forward Secrecy property due to the
removal of the ephemeral Diffie-Hellman key agreement. As this removal of the ephemeral Diffie-Hellman key agreement. As this
weakens the security properties of HIP DEX, it MUST be used only weakens the security properties of HIP DEX, it MUST be used only
with constrained devices where this is prohibitively expensive as with constrained devices where this is prohibitively expensive as
further explained in Section 1.2. further explained in Section 1.2.
3. HIP DEX forfeits the use of digital signatures with the removal 3. HIP DEX forfeits the use of digital signatures with the removal
of a hash function. Peer authentication with HIP DEX, therefore, of a hash function. Peer authentication with HIP DEX, therefore,
is based on the use of the ECDH derived key in the HIP_MAC is based on the use of the ECDH derived key in the CMAC-based
parameter. HIP_MAC parameter.
4. The forfeiture of the use of digital signatures leaves the R1 4. The forfeiture of the use of digital signatures leaves the R1
packet open to a MITM attack. Such an attack is managed in the packet open to a MITM attack. Such an attack is managed in the
R2 packet validation and is yet another DOS attack mitigated R2 packet validation and is yet another DOS attack mitigated
through the HIP state machine. through the HIP state machine. This state machine mitigation is
augmented by HIT,HI ACL controls.
5. With HIP DEX, the ECDH derived key is only used to protect HIP 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.
6. HIP DEX introduces 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.
skipping to change at page 5, line 50 skipping to change at page 6, line 24
and R2 handshake packets based on the ECDH-derived keying material. and R2 handshake packets based on the ECDH-derived keying material.
The Initiator and the Responder additionally transmit keying material The Initiator and the Responder additionally transmit keying material
for the session key in these last two handshake packets (I2 and R2). for the session key in these last two handshake packets (I2 and R2).
This is to prevent overuse of the static ECDH-derived keying This is to prevent overuse of the static ECDH-derived keying
material. Moreover, the Responder starts a puzzle exchange in the R1 material. Moreover, the Responder starts a puzzle exchange in the R1
packet and the Initiator completes this exchange in the I2 packet packet and the Initiator completes this exchange in the I2 packet
before the Responder performs computationally expensive operations or before the Responder performs computationally expensive operations or
stores any state from the exchange. Given this handshake structure, stores any state from the exchange. Given this handshake structure,
HIP DEX operationally is very similar to HIP BEX. Moreover, the HIP DEX operationally is very similar to HIP BEX. Moreover, the
employed model is also fairly equivalent to 802.11-2007 employed model is also fairly equivalent to 802.11-2007
[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
skipping to change at page 6, line 28 skipping to change at page 7, line 10
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. Standard HIPv2 uses a HIP_SIGNATURE to authenticate the needed. Standard HIPv2 uses a HIP_SIGNATURE to authenticate the
association close operation, but since DEX does not provide for association close operation, but since DEX does not provide for
signatures, the usual per-message MAC suffices. 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. Applicability 1.2. Applicability
HIP DEX achieves its lightweight nature in large part due to the HIP DEX achieves its lightweight nature in large part due to the
intentional removal of Forward Secrecy (FS) from the key exchange. intentional removal of Forward Secrecy (FS) from the key exchange.
Current mechanisms to achieve FS use an authenticated ephemeral Current mechanisms to achieve FS use an authenticated ephemeral
skipping to change at page 7, line 34 skipping to change at page 8, line 17
provided it wipes knowledge of the private key. Typically, the provided it wipes knowledge of the private key. Typically, the
provisioning service will make the public key (HI) and PSK available provisioning service will make the public key (HI) and PSK available
for the deployment step. for the deployment step.
Due to the substantially reduced security guarantees of HIP DEX 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 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 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 Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both
endpoints are class 2 devices or unconstrained. 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.3. Memo Structure 1.3. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout this the central keywords, notation, and terms used throughout this
document. Section 3 defines the structure of the Host Identity and document. Section 3 defines the structure of the Host Identity and
its various representations. Section 4 gives an overview of the HIP its various representations. Section 4 gives an overview of the HIP
Diet EXchange protocol. Sections 5 and 6 define the detailed packet Diet EXchange protocol. Sections 5 and 6 define the detailed packet
formats and rules for packet processing. Finally, Sections 7, 8, 9, formats and rules for packet processing. Finally, Sections 7, 8, 9,
and 10 discuss policy, interoperability between HIPv2 vs DEX, and 10 discuss policy, interoperability between HIPv2 vs DEX,
security, and IANA considerations, respectively. Appendix A defines security, and IANA considerations, respectively. Appendix A defines
skipping to change at page 8, line 14 skipping to change at page 8, line 51
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
CKDF: CMAC-based Key Derivation Function. CKDF: CMAC-based Key Derivation Function.
CMAC: The Cipher-based Message Authentication Code with the 128-bit CMAC: The Cipher-based Message Authentication Code with the 128-bit
skipping to change at page 10, line 24 skipping to change at page 11, line 12
has two forms of SAs, a Master Key SA for the actual HIP traffic, has two forms of SAs, a Master Key SA for the actual HIP traffic,
and a Pair-wise Key SA for use by a data transport service. and a Pair-wise Key SA for use by a data transport service.
3. Host Identity (HI) and its Structure 3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
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 use Elliptic Curve Diffie-Hellman (ECDH) HIP DEX implementations use Elliptic Curve Diffie-Hellman (ECDH)
[RFC6090] key exchange for generating the HI as defined in [RFC6090] key exchange for generating the HI as defined in
Section 5.2.3. No alternative algorithms are defined at this time. Section 5.2.3. No alternative algorithms are defined at this time.
A compressed encoding of the HI, the Host Identity Tag (HIT), is used A compressed encoding of the HI, the Host Identity Tag (HIT), is used
in the handshake packets to represent the HI. The DEX Host Identity in the handshake packets to represent the HI. The DEX Host Identity
Tag (HIT) is different from the BEX HIT in two ways: Tag (HIT) is different from the BEX HIT in two ways:
o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). * 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 use an unverified HIT as input. The full HI access control MUST NOT use an unverified HIT as input. The full HI
of a host SHOULD be considered, and the HIT MAY be used as a hint for of a host SHOULD be considered, and the HIT MAY be used as a hint for
locating the full HI (see Section 7.1). locating the full HI (see Section 7.1).
Carrying HIs or HITs in the header of user data packets would Carrying HIs or HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that increase the overhead of packets. Thus, it is not expected that
skipping to change at page 14, line 38 skipping to change at page 15, line 38
encrypt y encrypt y
R2: (DH, Suite, Trans) Lists, ENC(DH,y), R2: (DH, Suite, Trans) Lists, ENC(DH,y),
I_Nonce, mac I_Nonce, mac
<-------------------------------------- <--------------------------------------
check MAC check MAC
validate lists in R1 validate lists in R1
decrypt y decrypt y
Figure 1: High-level overview of the HIP Diet EXchange Figure 1: 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 17, line 7 skipping to change at page 17, 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 19, line 24 skipping to change at page 20, line 24
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 the system MUST NOT replace its keying material until the and the system MUST NOT replace its keying material until the
rekeying packet exchange successfully completes as described in rekeying packet exchange successfully completes as described in
Section 6.8 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 20, line 43 skipping to change at page 21, 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. * 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 PUZZLE, SOLUTION, and HIP_MAC parameter processing is altered to * PUZZLE, SOLUTION, and HIP_MAC parameter processing is altered to
support CMAC in RHASH and RHASH_len (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 parameters: 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 | variable | Nonce from Initator | | I_NONCE | TBD6 (suggested | variable | Nonce from Initator |
| | (suggested | | for Master Key | | | value 644) | | for Master Key |
| | value 644) | | | +---------------+-----------------+----------+---------------------+
+------------------+--------------+----------+----------------------+
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
Curve25519 [RFC7748] CKDF TBD7 (suggested value 12) Curve25519 [RFC7748] CKDF TBD7 (suggested value 12)
Curve448 [RFC7748] CKDF TBD8 (suggested value 13) Curve448 [RFC7748] CKDF TBD8 (suggested value 13)
The ECDH groups with values 7 - 9 are defined in [RFC5903] and
[RFC6090]. These curves, when used with HIP MUST have a co-factor of
1.
The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748]. The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748].
These curves have cofactors of 8 and 4 (respectively). These curves have cofactors of 8 and 4 (respectively).
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
skipping to change at page 22, line 37 skipping to change at page 23, line 37
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 For hosts that implement ECDH as the algorithm, the following curves
are required: are required:
Group Value Group Value
NIST P-256 1 [RFC5903]
NIST P-384 2 [RFC5903]
Curve25519 5 [RFC7748] Curve25519 5 [RFC7748]
Curve448 6 [RFC7748] Curve448 6 [RFC7748]
HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see
Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is
encoded in the "ECC curve" field of the HOST_ID parameter. The encoded in the "ECC curve" field of the HOST_ID parameter. The
supported DH Group IDs are defined in Section 5.2.1. supported DH Group IDs are defined in Section 5.2.1.
5.2.4. HIT_SUITE_LIST 5.2.4. HIT_SUITE_LIST
skipping to change at page 31, line 44 skipping to change at page 33, 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 32, line 52 skipping to change at page 34, 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). protection keys (e.g., for IPsec's ESP).
The HIP DEX KEYMAT process is based on the Hash-based Key Derivation The HIP DEX KEYMAT process is similar to the Hash-based Key
Function (HKDF) defined in [RFC5869] and consists of two components, Derivation Function (HKDF) defined in [RFC5869], but uses CMAC in
CKDF-Extract and CKDF-Expand. The CKDF-Extract function compresses a place of a cryptographic hash. DEX KEYMAT follows the CMAC usage
non-uniformly distributed key, such as the output of a Diffie-Hellman guidance for a KDF construct provided in [NIST.SP.800-56C],
key derivation, to extract the key entropy into a fixed length [NIST.SP.800-108] and [KeyDerivation]. This CMAC Key Derivation
output. The CKDF-Expand function takes either the output of the Function (CKDF) consists of two components, CKDF-Extract and CKDF-
Extract function or directly uses a uniformly distributed key and Expand. The CKDF-Extract function compresses a non-uniformly
expands the length of the key, repeatedly distributing the key distributed key, such as the output of a Diffie-Hellman 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 the key is smaller or equal to 128 bits, but Extract phase when the key is smaller or equal to 128 bits, but
otherwise requires also the Expand phase. otherwise requires also the Expand phase.
The CKDF-Extract function is the following operation: The CKDF-Extract function is the following operation:
CKDF-Extract(I, IKM, info) -> PRK CKDF-Extract(I, IKM, info) -> PRK
Inputs: Inputs:
I Random #I, provided by the Responder, from the PUZZLE I Random #I, provided by the Responder, from the PUZZLE
parameter parameter
IKM Input keying material Kij Diffie-Hellman derived key
the Diffie-Hellman derived key, concatenated with the IKM IKMm for Master Key SA Input keying material
random I_NONCE value for the Master Key SA or
the Diffie-Hellman derived key, concatenated with the IKMp for Pair-wise Key SA Input keying material
random values of the ENCRYPTED_KEY parameters in
the same order as the HITs with sort(HIT-I | HIT-R) IKMm Kij | I_NONCE
for the Pair-wise Key SA 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 the input text: "CKDF-Extract" Where the input text: "CKDF-Extract"
Is the hex string: 0x434b44462d45787472616374 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:
skipping to change at page 43, line 9 skipping to change at page 45, line 16
Section 6.2. Section 6.2.
4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER,
HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2
packet and compare the results against the chosen suites. packet and compare the results against the chosen suites.
5. The system MUST validate the Responder's HI per Section 9.2. 5. The system MUST validate the Responder's HI per Section 9.2.
6. If any of the checks above fail, there is a high probability of 6. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy. system SHOULD act accordingly (e.g. aborting with logging),
based on its local policy.
7. The system MUST decrypt the keying material from the 7. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial input ENCRYPTED_KEY parameter. This keying material is a partial input
to the key derivation process for the Pair-wise Key SA (see to the key derivation process for the Pair-wise Key SA (see
Section 6.3). Section 6.3).
8. 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
skipping to change at page 46, line 30 skipping to change at page 48, 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 both the Master and Pair-wise Key SAs * The strength of the keys for both the Master and Pair-wise Key SAs
is based on the quality of the random keying material generated by is based on the quality of the random keying material generated by
the Initiator and the Responder. As either peer may be a sensor the Initiator and the Responder. As either peer may be a sensor
or an actuator device, there is a natural concern about the or an actuator device, there is a natural concern about the
quality of its random number generator. Thus at least a CSPRNG quality of its random number generator. Thus at least a CSPRNG
SHOULD be used. SHOULD be used.
o HIP DEX lacks the Forward Secrecy (FS) 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 HIP DEX HIT generation may present new attack opportunities. * 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.
o It is critical to properly manage the ENCRYPTED_KEY counter * It is critical to properly manage the ENCRYPTED_KEY counter
(Section 5.2.5). If non-volatile store is used to maintain HIP (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 across system resets, then this counter MUST be part of the
state store. 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
acknowledgements for an overheard I2 packet and signal an arbitrary acknowledgements for an overheard I2 packet and signal an arbitrary
skipping to change at page 49, line 39 skipping to change at page 51, line 44
"Group IDs" subregistry of the "Host Identity Protocol (HIP) "Group IDs" subregistry of the "Host Identity Protocol (HIP)
Parameters" registry. Parameters" registry.
11. Acknowledgements 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
Mohit Sethi in helping with the draft during IESG process. Mohit Sethi in helping with the draft during IESG process.
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-21 12.1. Changes in draft-ietf-hip-dex-22
o Clarified on security concerns of using AES-CTR in Section 9.1 * Apply editorial comment from Roman Danyliw
o Edits for SECDIR comments * Clarify IKM content for Master SA and Pairwise SA in Section 6.3
12.2. Changes in draft-ietf-hip-dex-20 * Add behavior on BEX before DEX to Section 1.2
o Clarified text on AES-CTR for HIP parameter encryption. This * 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.2. Changes in draft-ietf-hip-dex-21
* Clarified on security concerns of using AES-CTR in Section 9.1
* Edits for SECDIR comments
12.3. Changes in draft-ietf-hip-dex-20
* Clarified text on AES-CTR for HIP parameter encryption. This
includes Section 9.1 includes Section 9.1
o Clarified text on R2 processing to validate content of R1. * Clarified text on R2 processing to validate content of R1.
o Clarified Applicability section. * Clarified Applicability section.
o Expanded Fig 1. * Expanded Fig 1.
o Clarified differences between BEX and DEX state machines. * Clarified differences between BEX and DEX state machines.
o ESP transform is MTI and ESP-TCP is Experimental. * ESP transform is MTI and ESP-TCP is Experimental.
12.3. Changes in draft-ietf-hip-dex-19 12.4. Changes in draft-ietf-hip-dex-19
o Replaced reference to RFC4493 for CMAC with NIST SP800-38B. * Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
o Remove NIST P-521 from DH_GROUP_LIST. * Remove NIST P-521 from DH_GROUP_LIST.
o Remove NULL-ENCRYPT. * Remove NULL-ENCRYPT.
o Added reference to rfc8005 for HIT lookup in DNS. * Added reference to rfc8005 for HIT lookup in DNS.
o Remove setting Control bit: A. * Remove setting Control bit: A.
o Many textual improvements per Benjamin Kaduk comments. * Many textual improvements per Benjamin Kaduk comments.
12.4. Changes in draft-ietf-hip-dex-18 12.5. Changes in draft-ietf-hip-dex-18
o Changed Perfect Forward Secrecy to Forward Secrecy. * Changed Perfect Forward Secrecy to Forward Secrecy.
12.5. Changes in draft-ietf-hip-dex-17 12.6. Changes in draft-ietf-hip-dex-17
o Added hex values for strings CKDF-Extract and CKDF-Expand. * Added hex values for strings CKDF-Extract and CKDF-Expand.
o Replace Perfect Forward Secrecy with Forward Secrecy. * Replace Perfect Forward Secrecy with Forward Secrecy.
12.6. Changes in draft-ietf-hip-dex-16 12.7. Changes in draft-ietf-hip-dex-16
o Remove old placeholder text. * Remove old placeholder text.
o Remove SECP160R1. Experience has shown EC25519 performance equal * Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it. enough to not need it.
12.7. Changes in draft-ietf-hip-dex-15 12.8. Changes in draft-ietf-hip-dex-15
o Added Public Key validation in I2 and R2 processing. * Added Public Key validation in I2 and R2 processing.
o Added ACL processing (Section 7.1). * Added ACL processing (Section 7.1).
o Added IANA instructions for DH_GROUP_LIST. * Added IANA instructions for DH_GROUP_LIST.
12.8. Changes in draft-ietf-hip-dex-14 12.9. Changes in draft-ietf-hip-dex-14
o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan * Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment comment
12.9. Changes in draft-ietf-hip-dex-12 and 13 12.10. Changes in draft-ietf-hip-dex-12 and 13
o Nits from Jeff Ahrenholz (including some formatting issues)
12.10. Changes in draft-ietf-hip-dex-11 and 12 * Nits from Jeff Ahrenholz (including some formatting issues)
o Included more precise references to the IANA subregistries 12.11. Changes in draft-ietf-hip-dex-11 and 12
o Addressed GEN-ART feedback from Francis Dupont * Included more precise references to the IANA subregistries
* Addressed GEN-ART feedback from Francis Dupont
o Added reasoning for FS in a separate section, and it is mentioned * Added reasoning for FS in a separate section, and it is mentioned
also in the abstract and intro. also in the abstract and intro.
o Donald Eastlake's (secdir) nits addressed * Donald Eastlake's (secdir) nits addressed
o Resolved IANA nits from Amanda Baber. * Resolved IANA nits from Amanda Baber.
o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 * New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (removed in ver 16), "Need to Validate Public Considered Unsafe" (removed in ver 16), "Need to Validate Public
Keys" (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric Keys" (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.11. Changes in draft-ietf-hip-dex-11 12.12. Changes in draft-ietf-hip-dex-11
o Update IANA considerations as requested by Eric Envyncke * Update IANA considerations as requested by Eric Envyncke
12.12. Changes in draft-ietf-hip-dex-10 12.13. Changes in draft-ietf-hip-dex-10
o Explanations on why the document includes so many SHOULDs * Explanations on why the document includes so many SHOULDs
12.13. Changes in draft-ietf-hip-dex-09 12.14. Changes in draft-ietf-hip-dex-09
o Fixed values for * Fixed values for
* DH_GROUP_LIST - DH_GROUP_LIST
* HIT_SUITE_LIST
- HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.14. Changes in draft-ietf-hip-dex-05 12.15. 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.15. Changes in draft-ietf-hip-dex-04 12.16. 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.16. Changes in draft-ietf-hip-dex-03 12.17. 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.17. Changes in draft-ietf-hip-dex-02 12.18. Changes in draft-ietf-hip-dex-02
o Author address change. * Author address change.
12.18. Changes in draft-ietf-hip-dex-01 12.19. 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.19. Changes in draft-ietf-hip-dex-00 12.20. Changes in draft-ietf-hip-dex-00
o The Internet Draft was adopted by the HIP WG. * The Internet Draft was adopted by the HIP WG.
12.20. Changes in draft-moskowitz-hip-rg-dex-06 12.21. Changes in draft-moskowitz-hip-rg-dex-06
o A major change in the ENCRYPT parameter to use AES-CTR rather than * A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
12.21. Changes in draft-moskowitz-hip-dex-00 12.22. 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.22. Changes in draft-moskowitz-hip-dex-01 12.23. 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 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.23. Changes in draft-moskowitz-hip-dex-02 12.24. 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.24. Changes in draft-moskowitz-hip-dex-03 12.25. 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.25. Changes in draft-moskowitz-hip-dex-04 12.26. 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] [NIST.SP.800-38B]
Dworkin, M., "Recommendation for block cipher modes of Dworkin, M., "Recommendation for block cipher modes of
operation :", National Institute of Standards and operation :: the CMAC mode for authentication", National
Technology report, DOI 10.6028/nist.sp.800-38b, 2016. 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>.
[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>.
skipping to change at page 56, line 7 skipping to change at page 58, line 27
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 [DH76] Diffie, W. and M. Hellman, "New directions in
Cryptography", IEEE Transactions on Information cryptography", IEEE Transactions on Information
Theory vol. IT-22, number 6, pages 644-654, Nov 1976. Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638,
November 1976, <https://doi.org/10.1109/tit.1976.1055638>.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Wehrle, "Tailoring End-to-End IP Security Protocols to the
Internet of Things", in Proceedings of IEEE International
Conference on Network Protocols (ICNP 2013), October 2013.
[I-D.ietf-hip-rfc4423-bis] [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>.
[NIST.SP.800-108]
Chen, L., "Recommendation for key derivation using
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>.
skipping to change at page 60, line 30 skipping to change at page 62, line 37
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. 181 change blocks. 
347 lines changed or deleted 409 lines changed or added

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