draft-ietf-hip-dex-19.txt   draft-ietf-hip-dex-20.txt 
HIP WG R. Moskowitz, Ed. HIP WG R. Moskowitz, Ed.
Internet-Draft HTT Consulting Internet-Draft HTT Consulting
Intended status: Standards Track R. Hummen Intended status: Standards Track R. Hummen
Expires: November 5, 2020 Hirschmann Automation and Control Expires: November 22, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
May 4, 2020 May 21, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-19 draft-ietf-hip-dex-20
Abstract Abstract
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash cryptographic primitives by omitting public-key signatures and hash
functions. functions.
The HIP DEX protocol is primarily designed for computation or memory- The HIP DEX protocol is primarily designed for computation or memory-
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2020. This Internet-Draft will expire on November 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 15
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 19
4.1.4. User Data Considerations . . . . . . . . . . . . . . 19 4.1.4. User Data Considerations . . . . . . . . . . . . . . 20
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 20
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 21
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 20 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 21 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 23
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 22 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 23
5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 23 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 24 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 25
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 25 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 26
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 27 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 28
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 28 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 29
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 29 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 30
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 29 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 30 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 31
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 30 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 31
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 30 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 31
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 31 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 34 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 34 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 35 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 38 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 41 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 42 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 43 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 43 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 43 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 44 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47 9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47
9.2. NULL-ENCRYPT ONLY for Testing/Debugging . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48 12.1. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 49
12.1. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 48 12.2. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 49
12.2. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 49 12.3. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 50
12.3. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 49 12.4. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 50
12.4. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 49 12.5. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 50
12.5. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 49 12.6. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 50
12.6. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49 12.7. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50
12.7. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 49 12.8. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50
12.8. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 49 12.9. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50
12.9. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50 12.10. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 51
12.10. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50 12.11. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 51
12.11. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50 12.12. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 51
12.12. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50 12.13. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51
12.13. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 50 12.14. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51
12.14. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 50 12.15. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51
12.15. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51 12.16. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 52
12.16. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51 12.17. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 52
12.17. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51 12.18. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 52
12.18. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51 12.19. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 52
12.19. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51 12.20. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52
12.20. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 51 12.21. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52
12.21. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52 12.22. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 53
12.22. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52 12.23. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53
12.23. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 52 12.24. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . 53 13.1. Normative References . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 56 HIP DEX handshake . . . . . . . . . . . . . . . . . 57
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 56 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX). HIP DEX is derived from the Base EXchange (BEX) of the Host DEX). HIP DEX is derived from the Base EXchange (BEX) of the Host
Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the
protocol semantics as well as the general packet structure of HIPv2. protocol semantics as well as the general packet structure of HIPv2.
Hence, it is recommended that [RFC7401] is well-understood before Hence, it is recommended that [RFC7401] is well-understood before
reading this document. reading this document.
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 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.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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
Diffie-Hellman exchange (e.g., SIGMA or PAKE). HIP DEX targets usage Diffie-Hellman exchange (e.g., SIGMA or PAKE). HIP DEX targets usage
on devices where even the most lightweight ECDH exchange is on devices where even the most lightweight ECDH exchange is
prohibitively expensive for recurring (ephemeral) use. For example, prohibitively expensive for recurring (ephemeral) use. For example,
experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has
shown that EC25519 keypair generation exceeds 10 seconds and consumes shown that EC25519 keypair generation exceeds 10 seconds and consumes
significant energy (i.e., battery resources). Even the ECDH significant energy (i.e., battery resources). Even the ECDH
multiplication for the HIP DEX static-static key exchange takes 8-9 multiplication for the HIP DEX static-static key exchange takes 8-9
seconds, again with measurable energy consumption. This resource seconds, again with measurable energy consumption. The ECDH
consumption is tolerable as a one-time event during provisioning, but multiplication resource consumption via a static EC25519 keypair is
would render the protocol unsuitable for use on these devices if it tolerable as a one-time event during provisioning, but would render
was required to be a recurring part of the protocol. For devices the protocol unsuitable for use on these devices if it was required
constrained in this manner, a FS-enabled protocol will likely provide to be a recurring part of the protocol. Further, for devices
little gain. The resulting "FS" key, likely produced during device constrained in this manner, a FS-enabled protocol's cost will likely
provisioning, would typically end up being used for the remainder of provide little gain. Since the resulting "FS" key, likely produced
the device's lifetime. during device deployment, would typically end up being used for the
remainder of the device's lifetime.
With such a usage pattern, the inherent benefit of ephemeral keys is With such a usage pattern, the inherent benefit of ephemeral keys is
not realized. The security properties of such usage are very similar not realized. The security properties of such usage are very similar
to those of using a statically provisioned symmetric pre-shared key, to those of using a statically provisioned symmetric pre-shared key,
in that there remains a single PSK in static storage that is in that there remains a single PSK in static storage that is
susceptible to exfiltration/compromise, and compromise of that key in susceptible to exfiltration/compromise, and compromise of that key in
effect compromises the entire protocol for that node. HIP DEX effect compromises the entire protocol for that node. HIP DEX
achieves marginally better security properties by computing the achieves marginally better security properties by computing the
effective long-term PSK from a DH exchange, so that the provisioning effective long-term PSK from a DH exchange, so that the provisioning
service is not required to be part of the risk surface due to also service is not required to be part of the risk surface due to also
possessing the PSK. 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 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.
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
skipping to change at page 9, line 37 skipping to change at page 9, line 43
handshake. This role is typically forgotten once the handshake is handshake. This role is typically forgotten once the handshake is
completed. completed.
RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message redefined as CMAC. Still, note that CMAC is a message
authentication code (MAC) and not a cryptographic hash function. authentication code (MAC) and not a cryptographic hash function.
Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where
RHASH is used. Moreover, RHASH has different security properties RHASH is used. Moreover, RHASH has different security properties
in HIP DEX and is not used for HIT generation. in HIP DEX and is not used for HIT generation.
Secure Association (SA): An SA is a simplex "connection" that
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,
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 [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
skipping to change at page 12, line 34 skipping to change at page 12, line 49
The second packet, R1, starts the actual authenticated Diffie-Hellman The second packet, R1, starts the actual authenticated Diffie-Hellman
key exchange. It contains a puzzle - a cryptographic challenge that key exchange. It contains a puzzle - a cryptographic challenge that
the Initiator must solve before continuing the exchange. The level the Initiator must solve before continuing the exchange. The level
of difficulty of the puzzle can be adjusted based on level of of difficulty of the puzzle can be adjusted based on level of
knowledge of the Initiator, current load, or other factors. In knowledge of the Initiator, current load, or other factors. In
addition, the R1 contains the Responder's Diffie-Hellman parameter addition, the R1 contains the Responder's Diffie-Hellman parameter
and lists of cryptographic algorithms supported by the Responder. and lists of cryptographic algorithms supported by the Responder.
Based on these lists, the Initiator can continue, abort, or restart Based on these lists, the Initiator can continue, abort, or restart
the handshake with a different selection of cryptographic algorithms. the handshake with a different selection of cryptographic algorithms.
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
skipping to change at page 14, line 17 skipping to change at page 15, line 27
[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 Section 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
skipping to change at page 21, line 6 skipping to change at page 22, line 6
Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to: to:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) AES-128-CTR TBD4 (suggested: 5) ([RFC3686])
Mandatory implementation: AES-128-CTR. Mandatory implementation: AES-128-CTR.
The initialization vector (IV) counter for AES-128-CTR MUST have a
length of 128 bits. The puzzle value #I and the puzzle solution #J
(see Section 4.1.2 in [RFC7401]) are used to construct the high-order
bits of the IV. The IV is computed as FOLD(I | J, 112) plus a 16 bit
counter value, which is initialized to zero on first use, appended to
the Fold value in order to guarantee that a non-repeating nonce is
fed to the AES-CTR encryption algorithm.
This IV 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:
skipping to change at page 22, line 30 skipping to change at page 23, 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 5.2.6. I_NONCE
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Initiator Nonce / / Initiator Nonce /
/ / / /
/ +-------------------------------+ / +-------------------------------+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 15 skipping to change at page 27, line 18
The HIP_CIPHER contains the encryption algorithms supported by the The HIP_CIPHER contains the encryption algorithms supported by the
Responder to protect the key exchange, in the order of preference. Responder to protect the key exchange, in the order of preference.
All implementations MUST support the AES-CTR [RFC3686]. All implementations MUST support the AES-CTR [RFC3686].
The DH_GROUP_LIST parameter contains the Responder's order of The DH_GROUP_LIST parameter contains the Responder's order of
preference based on the Responder's choice the ECDH key contained in preference based on the Responder's choice the ECDH key contained in
the HOST_ID parameter (see below). This allows the Initiator to the HOST_ID parameter (see below). This allows the Initiator to
begin 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 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
skipping to change at page 27, line 8 skipping to change at page 28, line 11
Responder sets the source HIT in the R1 packet based on the Responder sets the source HIT in the R1 packet based on the
destination HIT from the I1 packet. Based on the deviating DH group destination HIT from the I1 packet. Based on the deviating DH group
ID in the HOST_ID parameter, the Initiator then MUST abort the ID in the HOST_ID parameter, the Initiator then MUST abort the
current handshake and SHOULD initiate a new handshake with the current handshake and SHOULD initiate a new handshake with the
mutually supported DH group as far as local policies (see Section 7) mutually supported DH group as far as local policies (see Section 7)
permit. 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 36, line 5 skipping to change at page 37, 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 37, line 24 skipping to change at page 38, line 28
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 40, line 43 skipping to change at page 41, line 40
contain specifications for handling any specific transport contain specifications for handling any specific transport
selected. selected.
14. 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.
15. 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.
16. The I2 packet may have the A-bit set - in this case, the system 16. The system MUST decrypt the keying material from the
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.
17. 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).
18. 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.
19. 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
R2-SENT, an R2 packet is sent as described in Section 5.3.4 and R2-SENT, an R2 packet is sent as described in Section 5.3.4 and
the system's state machine transitions to state R2-SENT. the system's state machine transitions to state R2-SENT.
20. Upon successful processing of an I2 packet when the system's 19. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent as is dropped and a new one is installed, an R2 packet is sent as
described in Section 5.3.4, and the system's state machine described in Section 5.3.4, and the system's state machine
transitions to R2-SENT. transitions to R2-SENT.
21. Upon the system's state machine transitioning to R2-SENT, the 20. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP ESTABLISHED if some data has been received on the incoming HIP
association, or an UPDATE packet has been received (or some association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for a has moved to ESTABLISHED). If the timer expires (allowing for a
maximal amount of retransmissions of I2 packets), the state maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED. machine transitions to ESTABLISHED.
Note that steps 11 (encrypted HOST_ID) and 15 (signature Note that steps 11 (encrypted HOST_ID) and 15 (signature
verification) from the original processing rules of HIPv2 have been verification) from the original processing rules of HIPv2 have been
skipping to change at page 47, line 25 skipping to change at page 48, line 18
octets, padded on the left by zeros if necessary. For P-384, they octets, padded on the left by zeros if necessary. For P-384, they
take 48 octets each. take 48 octets each.
For Curve25519 and Curve448, the contents of the public value are the For Curve25519 and Curve448, the contents of the public value are the
byte string inputs and outputs of the corresponding functions defined byte string inputs and outputs of the corresponding functions defined
in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448.
The validation is done in Section 6.7, step 4 and Section 6.8, step The validation is done in Section 6.7, step 4 and Section 6.8, step
5. 5.
9.2. NULL-ENCRYPT ONLY for Testing/Debugging
Production deployments of this specification MUST NOT use the NULL-
ENCRYPT HIP_CIPHER. Per Section 5.2.2, the NULL-ENCRYPT MUST NOT be
offered or accepted unless explicitly configured for testing/
debugging of HIP.
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:
ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643)
(see Section 5.2.5) in the "Parameter Types" subregistry of the (see Section 5.2.5) in the "Parameter Types" subregistry of the
"Host Identity Protocol (HIP) Parameters" registry. "Host Identity Protocol (HIP) Parameters" registry.
DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519 DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519
skipping to change at page 48, line 42 skipping to change at page 49, line 28
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-19 12.1. Changes in draft-ietf-hip-dex-20
o Clarified text on AES-CTR for HIP parameter encryption.
o Clarified text on R2 processing to validate content of R1.
o Clarified Applicability section.
o Expanded Fig 1.
o Clarified differences between BEX and DEX state machines.
o ESP transform is MTI and ESP-TCP is Experimental.
12.2. Changes in draft-ietf-hip-dex-19
o Replaced reference to RFC4493 for CMAC with NIST SP800-38B. o Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
o Remove NIST P-521 from DH_GROUP_LIST. o Remove NIST P-521 from DH_GROUP_LIST.
o Remove NULL-ENCRYPT. o Remove NULL-ENCRYPT.
o Added reference to rfc8005 for HIT lookup in DNS. o Added reference to rfc8005 for HIT lookup in DNS.
o Remove setting Control bit: A. o Remove setting Control bit: A.
o Many textual improvements per Benjamin Kaduk comments. o Many textual improvements per Benjamin Kaduk comments.
12.2. Changes in draft-ietf-hip-dex-18 12.3. Changes in draft-ietf-hip-dex-18
o Changed Perfect Forward Secrecy to Forward Secrecy. o Changed Perfect Forward Secrecy to Forward Secrecy.
12.3. Changes in draft-ietf-hip-dex-17 12.4. Changes in draft-ietf-hip-dex-17
o Added hex values for strings CKDF-Extract and CKDF-Expand. o Added hex values for strings CKDF-Extract and CKDF-Expand.
o Replace Perfect Forward Secrecy with Forward Secrecy. o Replace Perfect Forward Secrecy with Forward Secrecy.
12.4. Changes in draft-ietf-hip-dex-16 12.5. Changes in draft-ietf-hip-dex-16
o Remove old placeholder text. o Remove old placeholder text.
o Remove SECP160R1. Experience has shown EC25519 performance equal o Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it. enough to not need it.
12.5. Changes in draft-ietf-hip-dex-15 12.6. Changes in draft-ietf-hip-dex-15
o Added Public Key validation in I2 and R2 processing. o Added Public Key validation in I2 and R2 processing.
o Added ACL processing (Section 7.1). o Added ACL processing (Section 7.1).
o Added IANA instructions for DH_GROUP_LIST. o Added IANA instructions for DH_GROUP_LIST.
12.6. Changes in draft-ietf-hip-dex-14 12.7. Changes in draft-ietf-hip-dex-14
o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment comment
12.7. Changes in draft-ietf-hip-dex-12 and 13 12.8. Changes in draft-ietf-hip-dex-12 and 13
o Nits from Jeff Ahrenholz (including some formatting issues) o Nits from Jeff Ahrenholz (including some formatting issues)
12.8. Changes in draft-ietf-hip-dex-11 and 12 12.9. Changes in draft-ietf-hip-dex-11 and 12
o Included more precise references to the IANA subregistries o Included more precise references to the IANA subregistries
o Addressed GEN-ART feedback from Francis Dupont o Addressed GEN-ART feedback from Francis Dupont
o Added reasoning for FS in a separate section, and it is mentioned o Added reasoning for FS in a separate section, and it is mentioned
also in the abstract and intro. also in the abstract and intro.
o Donald Eastlake's (secdir) nits addressed o Donald Eastlake's (secdir) nits addressed
o Resolved IANA nits from Amanda Baber. o Resolved IANA nits from Amanda Baber.
o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (removed in ver 16), "Need to Validate Public Considered Unsafe" (removed in ver 16), "Need to Validate Public
Keys" (Section 9.1), and "I_NONCE" (Section 5.2.6) to address Eric Keys" (Section 9.1), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.9. Changes in draft-ietf-hip-dex-11 12.10. Changes in draft-ietf-hip-dex-11
o Update IANA considerations as requested by Eric Envyncke o Update IANA considerations as requested by Eric Envyncke
12.10. Changes in draft-ietf-hip-dex-10 12.11. Changes in draft-ietf-hip-dex-10
o Explanations on why the document includes so many SHOULDs o Explanations on why the document includes so many SHOULDs
12.11. Changes in draft-ietf-hip-dex-09 12.12. Changes in draft-ietf-hip-dex-09
o Fixed values for o Fixed values for
* DH_GROUP_LIST * DH_GROUP_LIST
* HIT_SUITE_LIST * HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.12. Changes in draft-ietf-hip-dex-05 12.13. Changes in draft-ietf-hip-dex-05
o Clarified main differences between HIP BEX and HIP DEX in o Clarified main differences between HIP BEX and HIP DEX in
Section 1. Section 1.
o Addressed MitM attack in Section 8. o Addressed MitM attack in Section 8.
o Minor editorial changes. o Minor editorial changes.
12.13. Changes in draft-ietf-hip-dex-04 12.14. Changes in draft-ietf-hip-dex-04
o Added new paragraph on rekeying procedure with HIP DEX. o Added new paragraph on rekeying procedure with HIP DEX.
o Updated references. o Updated references.
o Editorial changes. o Editorial changes.
12.14. Changes in draft-ietf-hip-dex-03 12.15. Changes in draft-ietf-hip-dex-03
o Added new section on HIP DEX/HIPv2 interoperability o Added new section on HIP DEX/HIPv2 interoperability
o Added reference to RFC4493 for CMAC. o Added reference to RFC4493 for CMAC.
o Added reference to RFC5869 for CKDF. o Added reference to RFC5869 for CKDF.
o Added processing of NOTIFY message in I2-SENT of state diagram. o Added processing of NOTIFY message in I2-SENT of state diagram.
o Editorial changes. o Editorial changes.
12.15. Changes in draft-ietf-hip-dex-02 12.16. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.16. Changes in draft-ietf-hip-dex-01 12.17. Changes in draft-ietf-hip-dex-01
o Added the new ECDH groups of Curve25519 and Curve448 from RFC o Added the new ECDH groups of Curve25519 and Curve448 from RFC
7748. 7748.
12.17. Changes in draft-ietf-hip-dex-00 12.18. Changes in draft-ietf-hip-dex-00
o The Internet Draft was adopted by the HIP WG. o The Internet Draft was adopted by the HIP WG.
12.18. Changes in draft-moskowitz-hip-rg-dex-06 12.19. Changes in draft-moskowitz-hip-rg-dex-06
o A major change in the ENCRYPT parameter to use AES-CTR rather than o A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
12.19. Changes in draft-moskowitz-hip-dex-00 12.20. Changes in draft-moskowitz-hip-dex-00
o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual
submission. submission.
o Added the change section. o Added the change section.
o Added a Definitions section. o Added a Definitions section.
o Changed I2 and R2 packets to reflect use of AES-CTR for o Changed I2 and R2 packets to reflect use of AES-CTR for
ENCRYPTED_KEY parameter. ENCRYPTED_KEY parameter.
o Cleaned up KEYMAT Generation text. o Cleaned up KEYMAT Generation text.
o Added Appendix with C code for the ECDH shared secret generation o Added Appendix with C code for the ECDH shared secret generation
on an 8 bit processor. on an 8 bit processor.
12.20. Changes in draft-moskowitz-hip-dex-01 12.21. Changes in draft-moskowitz-hip-dex-01
o Numerous editorial changes. o Numerous editorial changes.
o New retransmission strategy. o New retransmission strategy.
o New HIT generation mechanism. o New HIT generation mechanism.
o Modified layout of ENCRYPTED_KEY parameter. o Modified layout of ENCRYPTED_KEY parameter.
o Clarify use puzzle difficulty of zero under normal network o Clarify use puzzle difficulty of zero under normal network
skipping to change at page 52, line 19 skipping to change at page 53, line 19
MUST). MUST).
o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1
and I2). and I2).
o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be
echoed in R2 packet. echoed in R2 packet.
o Added new author. o Added new author.
12.21. Changes in draft-moskowitz-hip-dex-02 12.22. Changes in draft-moskowitz-hip-dex-02
o Introduced formal definition of FOLD function. o Introduced formal definition of FOLD function.
o Clarified use of CMAC for puzzle computation in section "Solving o Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle". the Puzzle".
o Several editorial changes. o Several editorial changes.
12.22. Changes in draft-moskowitz-hip-dex-03 12.23. Changes in draft-moskowitz-hip-dex-03
o Addressed HI crypto agility. o Addressed HI crypto agility.
o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
o Extended the IV in the ENCRYPTED_KEY parameter. o Extended the IV in the ENCRYPTED_KEY parameter.
o Introduced forward-references to HIP DEX KEYMAT process and o Introduced forward-references to HIP DEX KEYMAT process and
improved KEYMAT section. improved KEYMAT section.
o Replaced Appendix A on "C code for ECC point multiplication" with o Replaced Appendix A on "C code for ECC point multiplication" with
short discussion in introduction. short discussion in introduction.
o Updated references. o Updated references.
o Further editorial changes. o Further editorial changes.
12.23. Changes in draft-moskowitz-hip-dex-04 12.24. Changes in draft-moskowitz-hip-dex-04
o Improved retransmission extension. o Improved retransmission extension.
o Updated and strongly revised packet processing rules. o Updated and strongly revised packet processing rules.
o Updated security considerations. o Updated security considerations.
o Updated IANA considerations. o Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11. o Move the HI Algorithm for ECDH to a value of 11.
 End of changes. 64 change blocks. 
178 lines changed or deleted 215 lines changed or added

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