draft-ietf-hip-dex-11.txt   draft-ietf-hip-dex-12.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: August 12, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
October 30, 2019 February 9, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-11 draft-ietf-hip-dex-12
Abstract Abstract
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash cryptographic primitives by omitting public-key signatures and hash
functions. functions.
The HIP DEX protocol is primarily designed for computation or memory- The HIP DEX protocol is primarily designed for computation or memory-
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 Perfect
mechanism for security primitives at the MAC layer, e.g., for IEEE Forward Secrecy (PFS), and MUST only be used on devices where PFS 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 August 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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) . . . . . . . . . . . . . . . 5
1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 6 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 10
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13
4.1.4. User Data Considerations . . . . . . . . . . . . . . 17 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 14
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 18
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 17 4.1.4. User Data Considerations . . . . . . . . . . . . . . 19
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 17 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 18 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 19
5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 18 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 19
5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 20
5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 19 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 20
5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 20 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 21
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 21 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 22
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 22 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 24 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 25 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 24
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 26 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 25
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 26 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 27
6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 27 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 28
6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 27 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 27 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 30
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 28 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 30
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 31 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 30
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 30
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 34
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 34
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 35
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 38
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 41
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 42
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 41 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 43
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 44
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
12.1. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 44 9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 46
12.2. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 44 9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 46
12.3. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
12.4. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
12.5. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 45 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.6. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 45 12.1. Changes in draft-ietf-hip-dex-12 . . . . . . . . . . . . 48
12.7. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 45 12.2. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 48
12.8. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 45 12.3. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 48
12.9. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45 12.4. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 48
12.10. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 12.5. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 49
12.11. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46 12.6. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 49
12.12. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46 12.7. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 49
12.13. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 12.8. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 49
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 12.9. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 49
13.1. Normative References . . . . . . . . . . . . . . . . . . 47 12.10. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . 48 12.11. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 50
12.12. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 50
12.13. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 50
12.14. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 51
12.15. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 51
12.16. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 51
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. Normative References . . . . . . . . . . . . . . . . . . 51
13.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 50 HIP DEX handshake . . . . . . . . . . . . . . . . . 55
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 50 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
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). HIP DEX builds on the Base EXchange (BEX) of the Host Identity
Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the protocol
semantics as well as the general packet structure of HIPv2. Hence, semantics as well as the general packet structure of HIPv2. Hence,
it is recommended that [RFC7401] is well-understood before reading it is recommended that [RFC7401] is well-understood before reading
this document. this document.
skipping to change at page 4, line 26 skipping to change at page 4, line 35
as its MACing function. In contrast, HIPv2 currently supports as its MACing function. In contrast, HIPv2 currently supports
AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC- AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC-
SHA-384 for MACing. 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 Perfect Forward Secrecy property of
HIPv2 due to the removal of the ephemeral Diffie-Hellman key HIPv2 due to the removal of the ephemeral Diffie-Hellman key
agreement. agreement. As this 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 HIP_MAC
parameter. parameter.
4. With HIP DEX, the ECDH derived key is only used to protect HIP 4. 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.
skipping to change at page 5, line 35 skipping to change at page 5, line 46
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. In doing so, HIP DEX omits the HIP_SIGNATURE parameters of
the original HIPv2 specification. the original HIPv2 specification.
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.2011]. 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, by design, does not support Perfect Forward Secrecy (PFS).
All current PFS approaches use Ephemeral DH, secured and identified
in some manner (for example, with SIGMA or PAKE). There are classes
of devices, like those based on the 8-bit 8051 microprocessor, where
this is prohibitively expensive. Past experience with the 8051 based
ZWAVE ZW0500 product has shown that EC25519 key pair generation
exceeded 10 seconds with unacceptable battery consumption. The ECDH
wide-multiply of the static-static keys took 8 - 9 seconds with
measurable battery drain. For these class of devices, the possible
risk of no PFS has to be weighed against the risk of theft of
preshared keys alternatives. Also, it is often the case that HIP DEX
is only performed during device join time, and, thus, no PFS is
considered an acceptable compromise.
Also, it is often the case that HIP DEX is only performed during
device join time, and thus no PFS is considered an acceptable
compromised.
HIP DEX MUST only be used in communicating with such constrained
devices (e.g., class 0 and 1 devices as defined in section 3 in
[RFC7228]).
1.3. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout this the central keywords, notation, and terms used throughout this
document. Section 3 defines the structure of the Host Identity and document. Section 3 defines the structure of the Host Identity and
its various representations. Section 4 gives an overview of the HIP its various representations. Section 4 gives an overview of the HIP
Diet EXchange protocol. Sections 5 and 6 define the detailed packet Diet EXchange protocol. Sections 5 and 6 define the detailed packet
formats and rules for packet processing. Finally, Sections 7, 8, 9, formats and rules for packet processing. Finally, Sections 7, 8, 9,
and 10 discuss policy, interoperability between HIPv2 vs DEX, and 10 discuss policy, interoperability between HIPv2 vs DEX,
security, and IANA considerations, respectively. Appendix A defines security, and IANA considerations, respectively. Appendix A defines
a two factor authentication scheme and Appendix B highligts some a two factor authentication scheme and Appendix B 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
skipping to change at page 7, line 16 skipping to change at page 8, line 7
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.
establishing a new HIP association.
Host Identity (HI): The static ECDH public key that represents the CMAC: The Cipher-based Message Authentication Code with the 128-bit
identity of the host. In HIP DEX, a host proves ownership of the Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].
private key belonging to its HI by creating a HIP_MAC with the
derived ECDH key (see Section 3).
Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It HIP association: The shared state between two peers after completion
is generated by folding the HI (see Section 3). of the HIP DEX handshake.
HIP DEX (Diet EXchange): The ECDH-based HIP handshake for
establishing a new HIP association.
HIT Suite: A HIT Suite groups all algorithms that are required to HIT Suite: A HIT Suite groups all algorithms that are required to
generate and use an HI and its HIT. In particular, these generate and use an HI and its HIT. In particular, these
algorithms are: 1) ECDH and 2) FOLD. algorithms are: 1) ECDH and 2) FOLD.
HIP association: The shared state between two peers after completion HI (Host Identity): The static ECDH public key that represents the
of the HIP DEX handshake. 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
derived ECDH key (see Section 3).
HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It
is generated by folding the HI (see Section 3).
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.
Responder: The host that responds to the Initiator in the HIP DEX KEYMAT: Keying material. That is, the bit string(s) used as
handshake. This role is typically forgotten once the handshake is cryptographic keys.
completed.
Responder's HIT Hash Algorithm (RHASH): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message
authentication code (MAC) and not a cryptographic hash function.
Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where
RHASH is used. Moreover, RHASH has different security properties
in HIP DEX and is not used for HIT generation.
Length of the Responder's HIT Hash Algorithm (RHASH_len): The
natural output length of RHASH in bits.
CMAC: The Cipher-based Message Authentication Code with the 128-bit
Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].
CKDF: CMAC-based Key Derivation Function. Length of the Responder's HIT Hash Algorithm (RHASH_len):
The natural output length of RHASH in bits.
Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE 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 parameter (see section 5.2.4 in [RFC7401]. It is also referred to
as "random value #I" in this document. 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 difficulty K: The Initiator has to compute a solution for the
puzzle. The level of computational difficulty is denoted by the puzzle. The level of computational difficulty is denoted by the
#K field in the puzzle parameter (see section 5.2.4 in [RFC7401]. #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
handshake. This role is typically forgotten once the handshake is
completed.
RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is
redefined as CMAC. Still, note that CMAC is a message
authentication code (MAC) and not a cryptographic hash function.
Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where
RHASH is used. Moreover, RHASH has different security properties
in HIP DEX and is not used for HIT generation.
3. Host Identity (HI) and its Structure 3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
skipping to change at page 8, line 49 skipping to change at page 10, line 5
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 be based solely on the HIT. Instead, the HI
of a host SHOULD be considered. of a host SHOULD be considered.
Carrying HIs and HITs in the header of user data packets would Carrying HIs and 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)
skipping to change at page 9, line 39 skipping to change at page 10, line 44
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(HI,96).
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 cryptograhic 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 or some other lookup process that
externally binds the HIT and HI.
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 14, line 11 skipping to change at page 16, line 11
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 |
| | 1/2 RTT-based timeout value and stay at | | | Data plus 1/2 RTT-based timeout value and |
| | I2-SENT | | | stay at I2-SENT |
| | | | | |
| | | | | |
| | | | | |
| Timeout | Increment trial counter | | Timeout | Increment trial counter |
| | | | | |
| | | | | |
| | | | | |
| | If counter is less than I2_RETRIES_MAX, | | | If counter is less than I2_RETRIES_MAX, |
| | send I2, reset timer to RTT-based timeout, | | | send I2, reset timer to RTT- |
| | and stay at I2-SENT | | | based timeout, and stay at I2-SENT |
| | | | | |
| | | | | |
| | | | | |
| | If counter is greater than I2_RETRIES_MAX, | | | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED | | | 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
skipping to change at page 16, line 18 skipping to change at page 18, 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 o Source HIT
o Destination HIT o Destination HIT
o HIP_Encrypt Key o HIP_Encrypt Key
o HIP_MAC Key o HIP_MAC Key
skipping to change at page 18, line 7 skipping to change at page 20, line 7
o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT.
o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD.
o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, o RHASH and RHASH_len are redefined to CMAC for the PUZZLE,
SOLUTION, and HIP_MAC parameters (see Section 6.1 and SOLUTION, and HIP_MAC parameters (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 parameter:
+------------------+--------------+----------+----------------------+ +------------------+-------------+----------+-----------------------+
| TLV | Type | Length | Data | | TLV | Type | Length | Data |
+------------------+--------------+----------+----------------------+ +------------------+-------------+----------+-----------------------+
| ENCRYPTED_KEY | TBD1 | variable | Encrypted container | | ENCRYPTED_KEY | TBD1 | variable | Encrypted container |
| | (suggested | | for the session key | | | (suggested | | for the session key |
| | value 643) | | exchange | | | value 643) | | exchange |
+------------------+--------------+----------+----------------------+ | | | | |
| I_NONCE | TBD6 | variable | Nonce from Initator |
| | (suggested | | for Master |
| | value 644) | | Key |
+------------------+-------------+----------+-----------------------+
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-256 [RFC5903] CKDF 7
skipping to change at page 19, line 23 skipping to change at page 21, line 30
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
NIST P-256 1 [RFC5903]
NIST P-384 2 [RFC5903]
NIST P-521 3 [RFC5903]
SECP160R1 4 [SECG]
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 40 skipping to change at page 23, line 10
Moreover, a 16 bit counter value, which is initialized to zero on 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 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 non-repeating nonce is fed to the encryption algorithm defined by the
HIP_CIPHER. 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 22, line 36 skipping to change at page 25, line 33
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: A
If the Responder's HI is an anonymous one, the A control MUST be set. If the Responder's HI is an anonymous one, the A control bit 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 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 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 HI 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 The HIP_CIPHER contains the encryption algorithms supported by the
Responder to protect the key exchange, in the order of preference. Responder to protect the key exchange, in the order of preference.
All implementations MUST support the AES-CTR [RFC3686]. All implementations MUST support the AES-CTR [RFC3686].
skipping to change at page 24, line 39 skipping to change at page 27, line 36
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: A
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 If the Initiator's HI is an anonymous one, the A control bit MUST be
set. set.
skipping to change at page 25, line 34 skipping to change at page 28, line 34
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 A.
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
skipping to change at page 29, line 28 skipping to change at page 32, line 48
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 key is smaller or equal to 128 bits, but otherwise
requires also the Expand phase. 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
random values of the ENCRYPTED_KEY parameters in the
same order as the HITs with sort(HIT-I | HIT-R) for the
Pair-wise Key SA
info sort(HIT-I | HIT-R) | "CKDF-Extract"
where "CKDF-Extract" is an octet string
Output:
PRK a pseudorandom key (of RHASH_len/8 octets)
The pseudorandom key PRK is calculated as follows:
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
skipping to change at page 42, line 43 skipping to change at page 45, line 43
o Contrary to HIPv2, HIP DEX does not provide for end-point o 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.
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. SECP160R1 Considered Unsafe
The SECP160R1 curve is included more for historical reasons than a
demostrated need for a lightweight curve for constrained systems.
Until it is deprecated from [RFC7401], it is included, but
implementors should carefully weigh any advantages actual or
perceived over EC25519. Actual implementations of EC25519 on an 8501
show that it can be used on very constrained hardware. The over-the-
air and storage costs for EC25519 are also closely comparable with
SECP160R1.
Thus the security risk of the weak SECP160R1 must be shown to be of
value over any slight costs of using EC25519 instead.
9.2. Need to Validate Public Keys
With the curves specified here, there is a straightforward key
extraction attack, which is a very serious problem the use of static
keys by HIP-DEX. Thus it is MANDATORY to validate the peer's Public
Key.
For the curve SECP160R1, peers MUST validate each other's public
value Q by ensuring that the point is a valid point on the elliptic
curve. This process consists of three steps: (1) verify that Q is
not the point at infinity (O), (2) verify that for Q = (x, y) both
integers x and y are in the correct interval, and (3) ensure that (x,
y) is a correct solution to the elliptic curve equation. For this
curve, implementors do not need to verify membership in the correct
subgroup.
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 P-521, they take 66 octets each.
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.
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 Parameter Type This document defines the new HIP parameters
"ENCRYPTED_KEY" with type number TBD1 (suggested: 643) (see
Section 5.2.5). ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested:
643) (see Section 5.2.5) in the "Parameter Types" 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.
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.
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.
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-12
o Included more precise references to the IANA subregistries
o Addressed GEN-ART feedback from Francis Dupont
o Added reasoning for PFS in a separate section, and it is mentioned
also in the abstract and intro.
o Donald Eastlake's (secdir) nits addressed
o Resolved IANA nits from Amanda Baber.
o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (Section 9.2) and "I_NONCE" (Section 5.2.6) to
address Eric Rescorla's concerns.
12.2. Changes in draft-ietf-hip-dex-11
o Update IANA considerations as requested by Eric Envyncke
12.3. Changes in draft-ietf-hip-dex-10
o Explanations on why the document includes so many SHOULDs
12.4. Changes in draft-ietf-hip-dex-09
o Fixed values for o Fixed values for
* DH_GROUP_LIST * DH_GROUP_LIST
* HIT_SUITE_LIST * HIT_SUITE_LIST
to match [RFC7401]. to match [RFC7401].
12.2. Changes in draft-ietf-hip-dex-05 12.5. Changes in draft-ietf-hip-dex-05
o Clarified main differences between HIP BEX and HIP DEX in o Clarified main differences between HIP BEX and HIP DEX in
Section 1. Section 1.
o Addressed MitM attack in Section 8. o Addressed MitM attack in Section 8.
o Minor editorial changes. o Minor editorial changes.
12.3. Changes in draft-ietf-hip-dex-04 12.6. Changes in draft-ietf-hip-dex-04
o Added new paragraph on rekeying procedure with HIP DEX. o Added new paragraph on rekeying procedure with HIP DEX.
o Updated references. o Updated references.
o Editorial changes. o Editorial changes.
12.4. Changes in draft-ietf-hip-dex-03 12.7. Changes in draft-ietf-hip-dex-03
o Added new section on HIP DEX/HIPv2 interoperability o Added new section on HIP DEX/HIPv2 interoperability
o Added reference to RFC4493 for CMAC. o Added reference to RFC4493 for CMAC.
o Added reference to RFC5869 for CKDF. o Added reference to RFC5869 for CKDF.
o Added processing of NOTIFY message in I2-SENT of state diagram. o Added processing of NOTIFY message in I2-SENT of state diagram.
o Editorial changes. o Editorial changes.
12.5. Changes in draft-ietf-hip-dex-02 12.8. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.6. Changes in draft-ietf-hip-dex-01 12.9. Changes in draft-ietf-hip-dex-01
o Added the new ECDH groups of Curve25519 and Curve448 from RFC o Added the new ECDH groups of Curve25519 and Curve448 from RFC
7748. 7748.
12.7. Changes in draft-ietf-hip-dex-00 12.10. Changes in draft-ietf-hip-dex-00
o The Internet Draft was adopted by the HIP WG. o The Internet Draft was adopted by the HIP WG.
12.8. Changes in draft-moskowitz-hip-rg-dex-06 12.11. Changes in draft-moskowitz-hip-rg-dex-06
o A major change in the ENCRYPT parameter to use AES-CTR rather than o A major change in the ENCRYPT parameter to use AES-CTR rather than
AES-CBC. AES-CBC.
12.9. Changes in draft-moskowitz-hip-dex-00 12.12. Changes in draft-moskowitz-hip-dex-00
o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual
submission. submission.
o Added the change section. o Added the change section.
o Added a Definitions section. o Added a Definitions section.
o Changed I2 and R2 packets to reflect use of AES-CTR for o Changed I2 and R2 packets to reflect use of AES-CTR for
ENCRYPTED_KEY parameter. ENCRYPTED_KEY parameter.
o Cleaned up KEYMAT Generation text. o Cleaned up KEYMAT Generation text.
o Added Appendix with C code for the ECDH shared secret generation o Added Appendix with C code for the ECDH shared secret generation
on an 8 bit processor. on an 8 bit processor.
12.10. Changes in draft-moskowitz-hip-dex-01 12.13. Changes in draft-moskowitz-hip-dex-01
o Numerous editorial changes. o Numerous editorial changes.
o New retransmission strategy. o New retransmission strategy.
o New HIT generation mechanism. o New HIT generation mechanism.
o Modified layout of ENCRYPTED_KEY parameter. o Modified layout of ENCRYPTED_KEY parameter.
o Clarify to use puzzle difficulty of zero under normal network o Clarify use puzzle difficulty of zero under normal network
conditions. conditions.
o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to o 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 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1
and I2). and I2).
o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be
echoed in R2 packet. echoed in R2 packet.
o Added new author. o Added new author.
12.11. Changes in draft-moskowitz-hip-dex-02 12.14. Changes in draft-moskowitz-hip-dex-02
o Introduced formal definition of FOLD function. o Introduced formal definition of FOLD function.
o Clarified use of CMAC for puzzle computation in section "Solving o Clarified use of CMAC for puzzle computation in section "Solving
the Puzzle". the Puzzle".
o Several editorial changes. o Several editorial changes.
12.12. Changes in draft-moskowitz-hip-dex-03 12.15. Changes in draft-moskowitz-hip-dex-03
o Addressed HI crypto agility. o Addressed HI crypto agility.
o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter.
o Extended the IV in the ENCRYPTED_KEY parameter. o Extended the IV in the ENCRYPTED_KEY parameter.
o Introduced forward-references to HIP DEX KEYMAT process and o Introduced forward-references to HIP DEX KEYMAT process and
improved KEYMAT section. improved KEYMAT section.
o Replaced Appendix A on "C code for ECC point multiplication" with o Replaced Appendix A on "C code for ECC point multiplication" with
short discussion in introduction. short discussion in introduction.
o Updated references. o Updated references.
o Further editorial changes. o Further editorial changes.
12.13. Changes in draft-moskowitz-hip-dex-04 12.16. Changes in draft-moskowitz-hip-dex-04
o Improved retransmission extension. o Improved retransmission extension.
o Updated and strongly revised packet processing rules. o Updated and strongly revised packet processing rules.
o Updated security considerations. o Updated security considerations.
o Updated IANA considerations. o Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11. o Move the HI Algorithm for ECDH to a value of 11.
skipping to change at page 50, line 8 skipping to change at page 55, line 8
[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 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC
2 , 2000, <http://www.secg.org/>. 2 , 2000, <http://www.secg.org/>.
Appendix A. Password-based two-factor authentication during the HIP DEX Appendix A. 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 B. 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)
skipping to change at page 51, line 37 skipping to change at page 56, line 37
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: Section 6, clearly states that:
it should be noted that many of the packet processing rules are it should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further denoted here with "SHOULD" but may be updated to "MUST" when
implementation experience provides better guidance. further implementation experience provides better guidance.
thus the SHOULD here is informative of future 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
skipping to change at page 52, line 15 skipping to change at page 57, line 15
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
 End of changes. 66 change blocks. 
188 lines changed or deleted 374 lines changed or added

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