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