draft-ietf-hip-dex-23.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: 19 July 2021 Hirschmann Automation and Control Expires: 23 July 2021 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
15 January 2021 19 January 2021
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-23 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) and DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and
specifically developed for use on low end processors. The HIP DEX specifically developed for use on low end processors. The HIP DEX
protocol design aims at reducing the overhead of the employed protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and cryptographic primitives by omitting public-key signatures and
cryptographic hash functions. cryptographic hash functions.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 July 2021. This Internet-Draft will expire on 23 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 6 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 6
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. Partial Computational Cost of FS via SIGMA . . . . . 8 1.2.1. Partial Computational Cost of FS via SIGMA . . . . . 8
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 9 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 9
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 9 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 9
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 9 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 9
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 11
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 12
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 12 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 13
3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 13 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 13
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 14 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 14
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 16 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 16
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 16 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 17
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 20 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 21
4.1.4. User Data Considerations . . . . . . . . . . . . . . 21 4.1.4. User Data Considerations . . . . . . . . . . . . . . 22
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 21 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 21 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 22
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 21 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 22
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 22 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 23
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 22 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 23
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 24 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 25
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 24 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 25
5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 26 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 27
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 27 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 28
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 29 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 30
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 30 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 31
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 31 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 32
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 32 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 32 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 33
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 32 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 33
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 32 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 33
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 34 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 35
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 37 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 38
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 37 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 38
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 38 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 39
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 41 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 42
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 44 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 45
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 45 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 46
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 46 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 47
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 46 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 47
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 46 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 47
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 47 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 48
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 47 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9.1. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 50 9.1. Caution on using HIP DEX rather than HIP BEX . . . . . . 51
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 50 9.2. Use of AES-CTR for HIP Parameter Encryption . . . . . . . 51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 9.3. Need to Validate Public Keys . . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Changes in draft-ietf-hip-dex-23 . . . . . . . . . . . . 52 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.2. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 52 12.1. Changes in draft-ietf-hip-dex-24 . . . . . . . . . . . . 53
12.3. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 52 12.2. Changes in draft-ietf-hip-dex-23 . . . . . . . . . . . . 53
12.4. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 52 12.3. Changes in draft-ietf-hip-dex-22 . . . . . . . . . . . . 53
12.5. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 53 12.4. Changes in draft-ietf-hip-dex-21 . . . . . . . . . . . . 53
12.6. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 53 12.5. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 54
12.7. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 53 12.6. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 54
12.8. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 53 12.7. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 54
12.9. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 53 12.8. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 54
12.10. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 53 12.9. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 54
12.11. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 54 12.10. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 55
12.12. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 54 12.11. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 55
12.13. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 54 12.12. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 55
12.14. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 54 12.13. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 55
12.15. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 54 12.14. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 55
12.16. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 54 12.15. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 55
12.17. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 55 12.16. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 55
12.18. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 55 12.17. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 56
12.19. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 55 12.18. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 56
12.20. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 55 12.19. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 56
12.21. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 55 12.20. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 56
12.22. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 55 12.21. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 56
12.23. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 55 12.22. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 56
12.24. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 56 12.23. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 56
12.25. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 56 12.24. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 57
12.26. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 56 12.25. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 57
12.27. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 57 12.26. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 57
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 12.27. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 58
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 12.28. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 58
13.2. Informative References . . . . . . . . . . . . . . . . . 58 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix A. Calculating Collision Probabilities . . . . . . . . 60 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 Appendix B. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 61 HIP DEX handshake . . . . . . . . . . . . . . . . . . . . 62
Appendix C. IESG Considerations . . . . . . . . . . . . . . . . 61 Appendix C. IESG Considerations . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 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), specifically developed for use on low end processors that DEX), specifically developed for use on low end processors that
cannot support the cryptographic requirements of HIP Base EXchange cannot support the cryptographic requirements of HIP Base EXchange
(HIP BEX). HIP DEX is derived from HIP BEX, which is defined in the (HIP BEX). HIP DEX is derived from HIP BEX, which is defined in the
Host Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX Host Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX
preserves the protocol semantics as well as the general packet preserves the protocol semantics as well as the general packet
structure of HIPv2. Hence, it is recommended that [RFC7401] is well- structure of HIPv2. Hence, it is recommended that [RFC7401] is well-
skipping to change at page 7, line 21 skipping to change at page 7, line 21
mentioning that the HIP DEX base protocol does not cover all the mentioning that the HIP DEX base protocol does not cover all the
fine-grained policy control found in Internet Key Exchange Version 2 fine-grained policy control found in Internet Key Exchange Version 2
(IKEv2) [RFC7296] that allows IKEv2 to support complex gateway (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway
policies. Thus, HIP DEX is not a replacement for IKEv2. policies. Thus, HIP DEX is not a replacement for IKEv2.
1.2. Applicability 1.2. Applicability
HIP DEX achieves its lightweight nature in large part due to the HIP DEX achieves its lightweight nature in large part due to the
intentional removal of Forward Secrecy (FS) from the key exchange. intentional removal of Forward Secrecy (FS) from the key exchange.
Current mechanisms to achieve FS use an authenticated ephemeral Current mechanisms to achieve FS use an authenticated ephemeral
Diffie-Hellman exchange (e.g., SIGMA or PAKE). HIP DEX targets usage 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 on devices where even the most lightweight ECDH exchange is
prohibitively expensive for recurring (ephemeral) use. For example, prohibitively expensive for recurring (ephemeral) use. For example,
experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has
shown that EC25519 keypair generation exceeds 10 seconds and consumes shown that EC25519 keypair generation exceeds 10 seconds and consumes
significant energy (i.e., battery resources). Even the ECDH significant energy (i.e., battery resources). Even the ECDH
multiplication for the HIP DEX static-static key exchange takes 8-9 multiplication for the HIP DEX static-static key exchange takes 8-9
seconds, again with measurable energy consumption. The ECDH seconds, again with measurable energy consumption. The ECDH
multiplication resource consumption via a static EC25519 keypair is multiplication resource consumption via a static EC25519 keypair is
tolerable as a one-time event during provisioning, but would render tolerable as a one-time event during provisioning, but would render
the protocol unsuitable for use on these devices if it was required the protocol unsuitable for use on these devices if it was required
skipping to change at page 8, line 28 skipping to change at page 8, line 28
systems, most noticeably sensor gateways. HIP DEX MUST NOT be used systems, most noticeably sensor gateways. HIP DEX MUST NOT be used
between systems capable of HIP BEX. This may be controlled by between systems capable of HIP BEX. This may be controlled by
limiting the use of DEX to an "internal" interface, or for such 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 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 try a DEX HIT. Note that such a downgrade (from BEX to DEX) offer
approach is open to attack, requiring additional mitigation (e.g. approach is open to attack, requiring additional mitigation (e.g.
ACL controls). ACL controls).
1.2.1. Partial Computational Cost of FS via SIGMA 1.2.1. Partial Computational Cost of FS via SIGMA
From the Initator's process, FS via SIGMA in HIP BEX on an 8-bit From the Initator's process, FS via SIGMA [SIGMA] in HIP BEX comes at
sensor comes at a high cost. In BEX, the Initator has: a prohibitive cost for constrained, 8-bit devices. In BEX, the
Initator has:
2 Public Key signing verifications, a. Public key operations
1 Public Key signing, 2 Public Key signing verifications,
1 Diffie-Hellman ephemeral keypair generation, and 1 Public Key signing,
1 Diffie-Hellman shared secret generation. 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 Whereas HIP DEX only has the Diffie-Hellman shared secret generation
cost. cost.
Papers like [EfficientECC] show on the ATmega328P (clock rate of Papers like [EfficientECC] show on the ATmega328P [ATmega328P] an
7.37MHz) an EdDSA25519 signature generation of 19M cycles and EdDSA25519 signature generation of 19M cycles and verification of 31M
verification of 31M cycles. Thus the SIGMA Public Key operations cycles. Thus the SIGMA Public Key operations come at a cost of 81M
come at a cost of 81M cycles. Actual wallclock time and energy cycles. Actual wallclock time and energy consumption are not
consumption is not provided in this paper, nor is the Curve25519 provided in this paper, nor is the Curve25519 keypair generation
keypair generation time. time.
This is just the cost of the Public Key operations, excluding This is just the cost of the Public Key operations, excluding
additional BEX over DEX processing. The added cost of HIP BEX (over additional BEX over DEX processing. The added cost of HIP BEX (over
HIP DEX) has been a major barrier to adoption of SIGMA based key HIP DEX) has been a blocking factor to adoption of SIGMA based key
establishment on 8-bit processors. establishment on 8-bit processors with limited power.
1.3. Memo Structure 1.3. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout this the central keywords, notation, and terms used throughout this
document. Section 3 defines the structure of the Host Identity and document. Section 3 defines the structure of the Host Identity and
its various representations. Section 4 gives an overview of the HIP its various representations. Section 4 gives an overview of the HIP
Diet EXchange protocol. Sections 5 and 6 define the detailed packet Diet EXchange protocol. Sections 5 and 6 define the detailed packet
formats and rules for packet processing. Finally, Sections 7, 8, 9, formats and rules for packet processing. Finally, Sections 7, 8, 9,
and 10 discuss policy, interoperability between HIPv2 vs DEX, and 10 discuss policy, interoperability between HIPv2 vs DEX,
skipping to change at page 42, line 17 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. The system MUST validate the Initiator's HI per Section 9.2. 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 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.
6. 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
skipping to change at page 45, line 12 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. The system MUST validate the Responder's HI per Section 9.2. 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 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 (e.g. aborting with logging), system SHOULD act accordingly (e.g. aborting with logging),
based on its local policy. based on its local policy.
7. The system MUST decrypt the keying material from the 7. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial input ENCRYPTED_KEY parameter. This keying material is a partial input
to the key derivation process for the Pair-wise Key SA (see to the key derivation process for the Pair-wise Key SA (see
Section 6.3). Section 6.3).
skipping to change at page 50, line 5 skipping to change at page 51, line 5
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-
computed 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. Use of AES-CTR for HIP Parameter Encryption 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 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 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 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 used like a one-time pad. Any reuse of that keystream breaks the
confidentiality of the protected data, so when using AES-CTR, care confidentiality of the protected data, so when using AES-CTR, care
must be taken to ensure that within a given keystream the counter 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 value is never reused, and that any given key is only used to
generate a single keystream. The integration of AES-CTR into IPsec 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 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 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 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 to provide a keystream for protecting a given packet, the IV is
chosen by the encryptor in a "manner that ensures uniqueness", and chosen by the encryptor in a "manner that ensures uniqueness", and
the nonce persists for the lifetime of a given SA. In particular, in 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 this usage the nonce must be unpredictable, not just single-use. In
HIP-DEX, the properties of nonce uniqueness/unpredictability and per- HIP-DEX, the properties of nonce uniqueness/unpredictability and per-
packet IV uniqueness are defined in Section 5.2.2. packet IV uniqueness are defined in Section 5.2.2.
9.2. Need to Validate Public Keys 9.3. Need to Validate Public Keys
With the curves specified here, there is a straightforward key With the curves specified here, there is a straightforward key
extraction attack, which is a very serious problem with the use of extraction attack, which is a very serious problem with the use of
static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's
Public Key. Public Key.
With the NIST curves, there are no internal length markers, so each
number representation occupies as many octets as implied by the curve
parameters. For P-256, this means that each of X and Y use 32
octets, padded on the left by zeros if necessary. For P-384, they
take 48 octets each.
For Curve25519 and Curve448, the contents of the public value are the For Curve25519 and Curve448, the contents of the public value are the
byte string inputs and outputs of the corresponding functions defined byte string inputs and outputs of the corresponding functions defined
in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448.
The validation is done in Section 6.7, step 4 and Section 6.8, step The validation is done in Section 6.7, step 4 and Section 6.8, step
5. 5.
10. IANA Considerations 10. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
skipping to change at page 52, line 14 skipping to change at page 53, line 14
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-23 12.1. Changes in draft-ietf-hip-dex-24
* Apply editorial comments from Eric Vyncke in Section 1.2
* Added SIGMA and ATmega328P references
* 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 * Apply editorial comment from Eric Vyncke
* Added concatenating Context ID with HI in FOLD to mirror HIPv2 * Added concatenating Context ID with HI in FOLD to mirror HIPv2
ORCHID construction ORCHID construction
* Added Partial Computational Cost of FS via SIGMA, Section 1.2.1 * Added Partial Computational Cost of FS via SIGMA, Section 1.2.1
* Added further text to Section 3.2.1 * Added further text to Section 3.2.1
12.2. Changes in draft-ietf-hip-dex-22 12.3. Changes in draft-ietf-hip-dex-22
* Apply editorial comment from Roman Danyliw * Apply editorial comment from Roman Danyliw
* Clarify IKM content for Master SA and Pairwise SA in Section 6.3 * Clarify IKM content for Master SA and Pairwise SA in Section 6.3
* Add behavior on BEX before DEX to Section 1.2 * Add behavior on BEX before DEX to Section 1.2
* Added [NIST.SP.800-56C], [NIST.SP.800-108], and [KeyDerivation] as * Added [NIST.SP.800-56C], [NIST.SP.800-108], and [KeyDerivation] as
source guidance for CKDF to Section 6.3 source guidance for CKDF to Section 6.3
* Removed NIST curves from Section 5.2.1 and Section 5.2.3 as too * Removed NIST curves from Section 5.2.1 and Section 5.2.3 as too
slow for 8-bit CPUs slow for 8-bit CPUs
12.3. Changes in draft-ietf-hip-dex-21 12.4. Changes in draft-ietf-hip-dex-21
* Clarified on security concerns of using AES-CTR in Section 9.1
* Clarified on security concerns of using AES-CTR in Section 9.2
* Edits for SECDIR comments * Edits for SECDIR comments
12.4. Changes in draft-ietf-hip-dex-20 12.5. Changes in draft-ietf-hip-dex-20
* Clarified text on AES-CTR for HIP parameter encryption. This * Clarified text on AES-CTR for HIP parameter encryption. This
includes Section 9.1 includes Section 9.2
* Clarified text on R2 processing to validate content of R1. * Clarified text on R2 processing to validate content of R1.
* Clarified Applicability section. * Clarified Applicability section.
* Expanded Fig 1. * Expanded Fig 1.
* Clarified differences between BEX and DEX state machines. * Clarified differences between BEX and DEX state machines.
* ESP transform is MTI and ESP-TCP is Experimental. * ESP transform is MTI and ESP-TCP is Experimental.
12.5. Changes in draft-ietf-hip-dex-19 12.6. Changes in draft-ietf-hip-dex-19
* Replaced reference to RFC4493 for CMAC with NIST SP800-38B. * Replaced reference to RFC4493 for CMAC with NIST SP800-38B.
* Remove NIST P-521 from DH_GROUP_LIST. * Remove NIST P-521 from DH_GROUP_LIST.
* Remove NULL-ENCRYPT. * Remove NULL-ENCRYPT.
* Added reference to rfc8005 for HIT lookup in DNS. * Added reference to rfc8005 for HIT lookup in DNS.
* Remove setting Control bit: A. * Remove setting Control bit: A.
* Many textual improvements per Benjamin Kaduk comments. * Many textual improvements per Benjamin Kaduk comments.
12.6. Changes in draft-ietf-hip-dex-18 12.7. Changes in draft-ietf-hip-dex-18
* Changed Perfect Forward Secrecy to Forward Secrecy. * Changed Perfect Forward Secrecy to Forward Secrecy.
12.7. Changes in draft-ietf-hip-dex-17 12.8. Changes in draft-ietf-hip-dex-17
* Added hex values for strings CKDF-Extract and CKDF-Expand. * Added hex values for strings CKDF-Extract and CKDF-Expand.
* Replace Perfect Forward Secrecy with Forward Secrecy. * Replace Perfect Forward Secrecy with Forward Secrecy.
12.8. Changes in draft-ietf-hip-dex-16 12.9. Changes in draft-ietf-hip-dex-16
* Remove old placeholder text. * Remove old placeholder text.
* Remove SECP160R1. Experience has shown EC25519 performance equal * Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it. enough to not need it.
12.9. Changes in draft-ietf-hip-dex-15 12.10. Changes in draft-ietf-hip-dex-15
* Added Public Key validation in I2 and R2 processing. * Added Public Key validation in I2 and R2 processing.
* Added ACL processing (Section 7.1). * Added ACL processing (Section 7.1).
* Added IANA instructions for DH_GROUP_LIST. * Added IANA instructions for DH_GROUP_LIST.
12.10. Changes in draft-ietf-hip-dex-14 12.11. Changes in draft-ietf-hip-dex-14
* Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan * Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment comment
12.11. Changes in draft-ietf-hip-dex-12 and 13 12.12. Changes in draft-ietf-hip-dex-12 and 13
* Nits from Jeff Ahrenholz (including some formatting issues) * Nits from Jeff Ahrenholz (including some formatting issues)
12.12. Changes in draft-ietf-hip-dex-11 and 12 12.13. Changes in draft-ietf-hip-dex-11 and 12
* Included more precise references to the IANA subregistries * Included more precise references to the IANA subregistries
* Addressed GEN-ART feedback from Francis Dupont * Addressed GEN-ART feedback from Francis Dupont
* Added reasoning for FS in a separate section, and it is mentioned * Added reasoning for FS in a separate section, and it is mentioned
also in the abstract and intro. also in the abstract and intro.
* Donald Eastlake's (secdir) nits addressed * Donald Eastlake's (secdir) nits addressed
* Resolved IANA nits from Amanda Baber. * Resolved IANA nits from Amanda Baber.
* New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 * New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (removed in ver 16), "Need to Validate Public Considered Unsafe" (removed in ver 16), "Need to Validate Public
Keys" (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric Keys" (Section 9.3), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.13. Changes in draft-ietf-hip-dex-11 12.14. Changes in draft-ietf-hip-dex-11
* Update IANA considerations as requested by Eric Envyncke * Update IANA considerations as requested by Eric Envyncke
12.14. Changes in draft-ietf-hip-dex-10 12.15. Changes in draft-ietf-hip-dex-10
* Explanations on why the document includes so many SHOULDs * Explanations on why the document includes so many SHOULDs
12.15. Changes in draft-ietf-hip-dex-09 12.16. Changes in draft-ietf-hip-dex-09
* Fixed values for * Fixed values for
- DH_GROUP_LIST - DH_GROUP_LIST
- HIT_SUITE_LIST - HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.16. Changes in draft-ietf-hip-dex-05 12.17. Changes in draft-ietf-hip-dex-05
* Clarified main differences between HIP BEX and HIP DEX in * Clarified main differences between HIP BEX and HIP DEX in
Section 1. Section 1.
* Addressed MitM attack in Section 8. * Addressed MitM attack in Section 8.
* Minor editorial changes. * Minor editorial changes.
12.17. Changes in draft-ietf-hip-dex-04 12.18. Changes in draft-ietf-hip-dex-04
* Added new paragraph on rekeying procedure with HIP DEX. * Added new paragraph on rekeying procedure with HIP DEX.
* Updated references. * Updated references.
* Editorial changes. * Editorial changes.
12.18. Changes in draft-ietf-hip-dex-03 12.19. Changes in draft-ietf-hip-dex-03
* Added new section on HIP DEX/HIPv2 interoperability * Added new section on HIP DEX/HIPv2 interoperability
* Added reference to RFC4493 for CMAC. * Added reference to RFC4493 for CMAC.
* Added reference to RFC5869 for CKDF. * Added reference to RFC5869 for CKDF.
* Added processing of NOTIFY message in I2-SENT of state diagram. * Added processing of NOTIFY message in I2-SENT of state diagram.
* Editorial changes. * Editorial changes.
12.19. Changes in draft-ietf-hip-dex-02 12.20. Changes in draft-ietf-hip-dex-02
* Author address change. * Author address change.
12.20. Changes in draft-ietf-hip-dex-01 12.21. Changes in draft-ietf-hip-dex-01
* 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.21. Changes in draft-ietf-hip-dex-00 12.22. Changes in draft-ietf-hip-dex-00
* The Internet Draft was adopted by the HIP WG. * The Internet Draft was adopted by the HIP WG.
12.22. Changes in draft-moskowitz-hip-rg-dex-06 12.23. Changes in draft-moskowitz-hip-rg-dex-06
* A major change in the ENCRYPT parameter to use AES-CTR rather than * A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
12.23. Changes in draft-moskowitz-hip-dex-00 12.24. Changes in draft-moskowitz-hip-dex-00
* 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.
* Added the change section. * Added the change section.
* Added a Definitions section. * Added a Definitions section.
* 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.
* Cleaned up KEYMAT Generation text. * Cleaned up KEYMAT Generation text.
* 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.24. Changes in draft-moskowitz-hip-dex-01 12.25. Changes in draft-moskowitz-hip-dex-01
* Numerous editorial changes. * Numerous editorial changes.
* New retransmission strategy. * New retransmission strategy.
* New HIT generation mechanism. * New HIT generation mechanism.
* Modified layout of ENCRYPTED_KEY parameter. * Modified layout of ENCRYPTED_KEY parameter.
* Clarify use puzzle difficulty of zero under normal network * Clarify use puzzle difficulty of zero under normal network
skipping to change at page 56, line 39 skipping to change at page 57, line 48
MUST). MUST).
* 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).
* 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.
* Added new author. * Added new author.
12.25. Changes in draft-moskowitz-hip-dex-02 12.26. Changes in draft-moskowitz-hip-dex-02
* Introduced formal definition of FOLD function. * Introduced formal definition of FOLD function.
* Clarified use of CMAC for puzzle computation in section "Solving * Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle". the Puzzle".
* Several editorial changes. * Several editorial changes.
12.26. Changes in draft-moskowitz-hip-dex-03 12.27. Changes in draft-moskowitz-hip-dex-03
* Addressed HI crypto agility. * Addressed HI crypto agility.
* Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. * Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
* Extended the IV in the ENCRYPTED_KEY parameter. * Extended the IV in the ENCRYPTED_KEY parameter.
* Introduced forward-references to HIP DEX KEYMAT process and * Introduced forward-references to HIP DEX KEYMAT process and
improved KEYMAT section. improved KEYMAT section.
* 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.
* Updated references. * Updated references.
* Further editorial changes. * Further editorial changes.
12.27. Changes in draft-moskowitz-hip-dex-04 12.28. Changes in draft-moskowitz-hip-dex-04
* Improved retransmission extension. * Improved retransmission extension.
* Updated and strongly revised packet processing rules. * Updated and strongly revised packet processing rules.
* Updated security considerations. * Updated security considerations.
* Updated IANA considerations. * Updated IANA considerations.
* Move the HI Algorithm for ECDH to a value of 11. * Move the HI Algorithm for ECDH to a value of 11.
skipping to change at page 58, line 37 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
[ATmega328P]
Atmel, "ATmega328P 8-bit AVR Microcontroller with 32K
Bytes In-System Programmable Flash", SEC 2 , 2015,
<https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-
7810-Automotive-Microcontrollers-
ATmega328P_Datasheet.pdf>.
[DH76] Diffie, W. and M. Hellman, "New directions in [DH76] Diffie, W. and M. Hellman, "New directions in
cryptography", IEEE Transactions on Information cryptography", IEEE Transactions on Information
Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638, Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638,
November 1976, <https://doi.org/10.1109/tit.1976.1055638>. November 1976, <https://doi.org/10.1109/tit.1976.1055638>.
[EfficientECC] [EfficientECC]
Nascimento, E., López, J., and R. Dahab, "Efficient and Nascimento, E., Lopez, J., and R. Dahab, "Efficient and
Secure Elliptic Curve Cryptography for 8-bit AVR Secure Elliptic Curve Cryptography for 8-bit AVR
Microcontrollers", Security, Privacy, and Applied Microcontrollers", Security, Privacy, and Applied
Cryptography Engineering pp. 289-309, Cryptography Engineering pp. 289-309,
DOI 10.1007/978-3-319-24126-5_17, 2015, DOI 10.1007/978-3-319-24126-5_17, 2015,
<https://doi.org/10.1007/978-3-319-24126-5_17>. <https://www.researchgate.net/publication/300253314_Effici
ent_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_M
icrocontrollers>.
[hip-rfc4423-bis] [hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-hip-rfc4423-bis-20, 14 February 2019, ietf-hip-rfc4423-bis-20, 14 February 2019,
<https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis- <https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-
20>. 20>.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Wehrle, "Tailoring end-to-end IP security protocols to the Wehrle, "Tailoring end-to-end IP security protocols to the
skipping to change at page 60, line 47 skipping to change at page 62, line 13
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>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>. October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[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 Appendix A. Calculating Collision Probabilities
The accepted formula for calculating the probability of a collision The accepted formula for calculating the probability of a collision
is: is:
p = 1 - e^{-k^2/(2n)} p = 1 - e^{-k^2/(2n)}
P Collision Probability P Collision Probability
n Total possible population n Total possible population
k Actual population k Actual population
skipping to change at page 62, line 35 skipping to change at page 63, line 38
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
 End of changes. 57 change blocks. 
148 lines changed or deleted 172 lines changed or added

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