draft-ietf-hip-dex-15.txt   draft-ietf-hip-dex-16.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: September 14, 2020 Hirschmann Automation and Control Expires: September 18, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
March 13, 2020 March 17, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-15 draft-ietf-hip-dex-16
Abstract Abstract
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash cryptographic primitives by omitting public-key signatures and hash
functions. functions.
The HIP DEX protocol is primarily designed for computation or memory- The HIP DEX protocol is primarily designed for computation or memory-
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2020. This Internet-Draft will expire on September 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 23 skipping to change at page 3, line 23
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 47 9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 48 9.2. NULL-ENCRYPT ONLY for Testing/Debugging . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 50 12.1. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 49
12.2. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50 12.2. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 49
12.3. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50 12.3. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49
12.4. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50 12.4. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50
12.5. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50 12.5. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50
12.6. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50 12.6. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50
12.7. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50 12.7. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50
12.8. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51 12.8. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50
12.9. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51 12.9. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50
12.10. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51 12.10. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51
12.11. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51 12.11. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51
12.12. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51
12.13. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51 12.13. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51
12.14. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 52 12.14. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51
12.15. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52 12.15. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51
12.16. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52 12.16. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51
12.17. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 53 12.17. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52
12.18. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53 12.18. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52
12.19. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53 12.19. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52
12.20. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . 53 13.1. Normative References . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 57 HIP DEX handshake . . . . . . . . . . . . . . . . . 57
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
This document specifies the Host Identity Protocol Diet EXchange (HIP This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX). HIP DEX 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
skipping to change at page 10, line 30 skipping to change at page 10, line 30
can be used to map the encrypted data packet to the correct HIP DEX can be used to map the encrypted data packet to the correct HIP DEX
association. When other user data packet formats are used, the association. When other user data packet formats are used, the
corresponding extensions need to define a replacement for the corresponding extensions need to define a replacement for the
ESP_TRANSFORM [RFC7402] parameter along with associated semantics, ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
but this procedure is outside the scope of this document. but this procedure is outside the scope of this document.
3.1. Host Identity Tag (HIT) 3.1. Host Identity Tag (HIT)
With HIP DEX, the HIT is a 128-bit value - a compression of the HI With HIP DEX, the HIT is a 128-bit value - a compression of the HI
prepended with a specific prefix. There are two advantages of using prepended with a specific prefix. There are two advantages of using
a hashed encoding over the actual variable-sized public key in this compressed encoding over the actual variable-sized public key in
protocols. First, the fixed length of the HIT keeps packet sizes protocols. First, the fixed length of the HIT keeps packet sizes
manageable and eases protocol coding. Second, it presents a manageable and eases protocol coding. Second, it presents a
consistent format for the protocol, independent of the underlying consistent format for the protocol, independent of the underlying
identity technology in use. identity technology in use.
The structure of the HIT is based on RFC 7343 [RFC7343], called The structure of the HIT is based on RFC 7343 [RFC7343], called
Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and
consists of three parts: first, an IANA assigned prefix to consists of three parts: first, an IANA assigned prefix to
distinguish it from other IPv6 addresses. Second, a four-bit distinguish it from other IPv6 addresses. Second, a four-bit
encoding of the algorithms that were used for generating the HI and encoding of the algorithms that were used for generating the HI and
skipping to change at page 20, line 30 skipping to change at page 20, line 30
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
NIST P-384 [RFC5903] CKDF 8 NIST P-384 [RFC5903] CKDF 8
NIST P-521 [RFC5903] CKDF 9 NIST P-521 [RFC5903] CKDF 9
SECP160R1 [SECG] CKDF 10
Curve25519 [RFC7748] CKDF TBD7 (suggested value 12) Curve25519 [RFC7748] CKDF TBD7 (suggested value 12)
Curve448 [RFC7748] CKDF TBD8 (suggested value 13) Curve448 [RFC7748] CKDF TBD8 (suggested value 13)
The ECDH groups with values 7 - 9 are defined in [RFC5903] and The ECDH groups with values 7 - 9 are defined in [RFC5903] and
[RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of [RFC6090]. ECDH group 10 is covered in [SECG] and Appendix D of
[RFC7401]. These curves, when used with HIP MUST have a co-factor of [RFC7401]. These curves, when used with HIP MUST have a co-factor of
1. 1.
The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748]. The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748].
These curves have cofactors of 8 and 4 (respectively). These curves have cofactors of 8 and 4 (respectively).
skipping to change at page 21, line 38 skipping to change at page 21, line 38
ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED)
For hosts that implement ECDH as the algorithm, the following curves For hosts that implement ECDH as the algorithm, the following curves
are required: are required:
Group Value Group Value
NIST P-256 1 [RFC5903] NIST P-256 1 [RFC5903]
NIST P-384 2 [RFC5903] NIST P-384 2 [RFC5903]
NIST P-521 3 [RFC5903] NIST P-521 3 [RFC5903]
SECP160R1 4 [SECG]
Curve25519 5 [RFC7748] Curve25519 5 [RFC7748]
Curve448 6 [RFC7748] Curve448 6 [RFC7748]
HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see
Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is
encoded in the "ECC curve" field of the HOST_ID parameter. The encoded in the "ECC curve" field of the HOST_ID parameter. The
supported DH Group IDs are defined in Section 5.2.1. supported DH Group IDs are defined in Section 5.2.1.
5.2.4. HIT_SUITE_LIST 5.2.4. HIT_SUITE_LIST
skipping to change at page 30, line 19 skipping to change at page 30, line 19
6. Packet Processing 6. Packet Processing
Due to the adopted protocol semantics and the inherited general Due to the adopted protocol semantics and the inherited general
packet structure, the packet processing in HIP DEX only differs from packet structure, the packet processing in HIP DEX only differs from
HIPv2 in very few places. Here, we focus on these differences and HIPv2 in very few places. Here, we focus on these differences and
refer to Section 6 in [RFC7401] otherwise. refer to Section 6 in [RFC7401] otherwise.
The processing of outgoing and incoming application data remains the The processing of outgoing and incoming application data remains the
same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]).
It should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further
implementation experience provides better guidance. Please refer
also to Appendix B for argumentation about the SHOULDs.
6.1. Solving the Puzzle 6.1. Solving the Puzzle
The procedures for solving and verifying a puzzle in HIP DEX are The procedures for solving and verifying a puzzle in HIP DEX are
strongly based on the corresponding procedures in HIPv2. The only strongly based on the corresponding procedures in HIPv2. The only
exceptions are that HIP DEX does not use pre-computation of R1 exceptions are that HIP DEX does not use pre-computation of R1
packets and that RHASH is set to CMAC. As a result, the pre- packets and that RHASH is set to CMAC. As a result, the pre-
computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX.
Moreover, the Initiator solves a puzzle by computing: Moreover, the Initiator solves a puzzle by computing:
Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0
skipping to change at page 40, line 9 skipping to change at page 40, line 9
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.1.
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 43, line 9 skipping to change at page 43, line 9
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.1.
6. If any of the checks above fail, there is a high probability of 6. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy. system SHOULD act accordingly, 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 46, line 42 skipping to change at page 46, line 42
the Initiator and the Responder. As either peer may be a sensor the Initiator and the Responder. As either peer may be a sensor
or an actuator device, there is a natural concern about the or an actuator device, there is a natural concern about the
quality of its random number generator. Thus at least a CSPRNG quality of its random number generator. Thus at least a CSPRNG
SHOULD be used. SHOULD be used.
o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2.
Consequently, if an HI is compromised, all previous HIP Consequently, if an HI is compromised, all previous HIP
connections protected with that HI are compromised as explained in connections protected with that HI are compromised as explained in
Section 1. Section 1.
o The puzzle mechanism using CMAC explained in Section 4.1.1 may
need further study regarding the level of difficulty in order to
establish best practices with current generation of constrained
devices.
o The HIP DEX HIT generation may present new attack opportunities. o The HIP DEX HIT generation may present new attack opportunities.
Hence, HIP DEX HITs MUST NOT be used as the only means to identify Hence, HIP DEX HITs MUST NOT be used as the only means to identify
a peer in an ACL. Instead, the use of the peer's HI is a peer in an ACL. Instead, the use of the peer's HI is
recommended as explained in Section 3. recommended as explained in Section 3.
o The R1 packet is unauthenticated and offers an adversary a new o The R1 packet is unauthenticated and offers an adversary a new
attack vector against the Initiator. This is mitigated by only attack vector against the Initiator. This is mitigated by only
processing a received R1 packet when the Initiator has previously processing a received R1 packet when the Initiator has previously
sent a corresponding I1 packet. Moreover, the Responder repeats sent a corresponding I1 packet. Moreover, the Responder repeats
the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and
skipping to change at page 47, line 48 skipping to change at page 47, line 41
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. SECP160R1 Considered Unsafe 9.1. Need to Validate Public Keys
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 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.
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 With the NIST curves, there are no internal length markers, so each
number representation occupies as many octets as implied by the curve 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 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 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. take 48 octets each. For P-521, they take 66 octets each.
For Curve25519 and Curve448, the contents of the public value are the For Curve25519 and Curve448, the contents of the public value are the
byte string inputs and outputs of the corresponding functions defined byte string inputs and outputs of the corresponding functions defined
in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448.
The validation is done in Section 6.7, step 4 and Section 6.8, step The validation is done in Section 6.7, step 4 and Section 6.8, step
5. 5.
9.2. NULL-ENCRYPT ONLY for Testing/Debugging
Production deployments of this specification MUST NOT use the NULL-
ENCRYPT HIP_CIPHER. Per Section 5.2.2, the NULL-ENCRYPT MUST NOT be
offered or accepted unless explicitly configured for testing/
debugging of HIP.
10. IANA Considerations 10. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
Parameters" registries have been made: Parameters" registries have been made:
ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643)
(see Section 5.2.5) in the "Parameter Types" subregistry of the (see Section 5.2.5) in the "Parameter Types" subregistry of the
"Host Identity Protocol (HIP) Parameters" registry. "Host Identity Protocol (HIP) Parameters" registry.
DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519 DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519
skipping to change at page 50, line 5 skipping to change at page 49, line 32
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-15 12.1. Changes in draft-ietf-hip-dex-16
o Remove old placeholder text.
o Remove SECP160R1. Experience has shown EC25519 performance equal
enough to not need it.
12.2. Changes in draft-ietf-hip-dex-15
o Added Public Key validation in I2 and R2 processing. o Added Public Key validation in I2 and R2 processing.
o Added ACL processing (Section 7.1). o Added ACL processing (Section 7.1).
o Added IANA instructions for DH_GROUP_LIST. o Added IANA instructions for DH_GROUP_LIST.
12.2. Changes in draft-ietf-hip-dex-14 12.3. Changes in draft-ietf-hip-dex-14
o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan
comment comment
12.3. Changes in draft-ietf-hip-dex-12 and 13 12.4. Changes in draft-ietf-hip-dex-12 and 13
o Nits from Jeff Ahrenholz (including some formatting issues) o Nits from Jeff Ahrenholz (including some formatting issues)
12.4. Changes in draft-ietf-hip-dex-11 and 12 12.5. Changes in draft-ietf-hip-dex-11 and 12
o Included more precise references to the IANA subregistries o Included more precise references to the IANA subregistries
o Addressed GEN-ART feedback from Francis Dupont o Addressed GEN-ART feedback from Francis Dupont
o Added reasoning for PFS in a separate section, and it is mentioned o Added reasoning for PFS in a separate section, and it is mentioned
also in the abstract and intro. also in the abstract and intro.
o Donald Eastlake's (secdir) nits addressed o Donald Eastlake's (secdir) nits addressed
o Resolved IANA nits from Amanda Baber. o Resolved IANA nits from Amanda Baber.
o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1
Considered Unsafe" (Section 9.1), "Need to Validate Public Keys" Considered Unsafe" (removed in ver 16), "Need to Validate Public
(Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric Keys" (Section 9.1), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.5. Changes in draft-ietf-hip-dex-11 12.6. Changes in draft-ietf-hip-dex-11
o Update IANA considerations as requested by Eric Envyncke o Update IANA considerations as requested by Eric Envyncke
12.6. Changes in draft-ietf-hip-dex-10 12.7. Changes in draft-ietf-hip-dex-10
o Explanations on why the document includes so many SHOULDs o Explanations on why the document includes so many SHOULDs
12.7. Changes in draft-ietf-hip-dex-09 12.8. 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.8. Changes in draft-ietf-hip-dex-05 12.9. 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.9. Changes in draft-ietf-hip-dex-04 12.10. 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.10. Changes in draft-ietf-hip-dex-03 12.11. 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.11. Changes in draft-ietf-hip-dex-02 12.12. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.12. Changes in draft-ietf-hip-dex-01 12.13. 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.13. Changes in draft-ietf-hip-dex-00 12.14. 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.14. Changes in draft-moskowitz-hip-rg-dex-06 12.15. 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.15. Changes in draft-moskowitz-hip-dex-00 12.16. 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.16. Changes in draft-moskowitz-hip-dex-01 12.17. Changes in draft-moskowitz-hip-dex-01
o Numerous editorial changes. o Numerous editorial changes.
o New retransmission strategy. o New retransmission strategy.
o New HIT generation mechanism. o New HIT generation mechanism.
o Modified layout of ENCRYPTED_KEY parameter. o Modified layout of ENCRYPTED_KEY parameter.
o Clarify use puzzle difficulty of zero under normal network o Clarify use puzzle difficulty of zero under normal network
skipping to change at page 53, line 5 skipping to change at page 52, line 37
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.17. Changes in draft-moskowitz-hip-dex-02 12.18. 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.18. Changes in draft-moskowitz-hip-dex-03 12.19. 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.19. Changes in draft-moskowitz-hip-dex-04 12.20. Changes in draft-moskowitz-hip-dex-04
o Improved retransmission extension. o Improved retransmission extension.
o Updated and strongly revised packet processing rules. o Updated and strongly revised packet processing rules.
o Updated security considerations. o Updated security considerations.
o Updated IANA considerations. o Updated IANA considerations.
o Move the HI Algorithm for ECDH to a value of 11. o Move the HI Algorithm for ECDH to a value of 11.
 End of changes. 39 change blocks. 
87 lines changed or deleted 67 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/