draft-ietf-hip-dex-16.txt   draft-ietf-hip-dex-17.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 18, 2020 Hirschmann Automation and Control Expires: September 19, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
March 17, 2020 March 18, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-16 draft-ietf-hip-dex-17
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 18, 2020. This Internet-Draft will expire on September 19, 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 30 skipping to change at page 3, line 30
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. Need to Validate Public Keys . . . . . . . . . . . . . . 47 9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47
9.2. NULL-ENCRYPT ONLY for Testing/Debugging . . . . . . . . . 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-16 . . . . . . . . . . . . 49 12.1. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 49
12.2. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 49 12.2. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 49
12.3. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49 12.3. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50
12.4. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50 12.4. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50
12.5. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50 12.5. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50
12.6. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50 12.6. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50
12.7. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50 12.7. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50
12.8. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50 12.8. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50
12.9. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50 12.9. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51
12.10. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51 12.10. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51
12.11. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51 12.11. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51
12.12. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51
12.13. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51 12.13. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51
12.14. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51 12.14. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51
12.15. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51 12.15. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51
12.16. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51 12.16. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52
12.17. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52 12.17. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52
12.18. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52 12.18. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52
12.19. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52 12.19. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53
12.20. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53 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 . . . . . . . . . . . . . . . . . 54 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
skipping to change at page 8, line 37 skipping to change at page 8, line 37
HIP DEX (Diet EXchange): The ECDH-based HIP handshake for HIP DEX (Diet EXchange): The ECDH-based HIP handshake for
establishing a new HIP association. 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 for HIP DEX, generate and use an HI and its HIT. In particular for HIP DEX,
these algorithms are: 1) ECDH and 2) FOLD. these algorithms are: 1) ECDH and 2) FOLD.
HI (Host Identity): The static ECDH public key that represents the HI (Host Identity): The static ECDH public key that represents the
identity of the host. In HIP DEX, a host proves ownership of the identity of the host. In HIP DEX, a host proves ownership of the
private key belonging to its HI by creating a HIP_MAC with the private key belonging to its HI by creating a HIP_MAC with the
derived ECDH key (see Section 3). derived ECDH key (see Section 3) in the appropriate I2 or R2
packet.
HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It
is generated by folding the HI (see Section 3). is generated by folding the HI (see Section 3).
Initiator: The host that initiates the HIP DEX handshake. This role Initiator: The host that initiates the HIP DEX handshake. This role
is typically forgotten once the handshake is completed. is typically forgotten once the handshake is completed.
KEYMAT: Keying material. That is, the bit string(s) used as KEYMAT: Keying material. That is, the bit string(s) used as
cryptographic keys. cryptographic keys.
Length of the Responder's HIT Hash Algorithm (RHASH_len): The RHASH_len: The natural length of the RHASH Algorithm in bits.
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 OGA (Orchid Generation Algorithm): Hash function used in generating
the ORCHID. the ORCHID.
ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6 ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6
addresses intended to be used as endpoint identifiers at addresses intended to be used as endpoint identifiers at
skipping to change at page 10, line 11 skipping to change at page 10, line 11
Tag (HIT) is different from the BEX HIT in two ways: Tag (HIT) is different from the BEX HIT in two ways:
o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4).
o The DEX HIT is not generated via a cryptographic hash. Rather, it o The DEX HIT is not generated via a cryptographic hash. Rather, it
is a compression of the HI. is a compression of the HI.
Due to the latter property, an attacker may be able to find a Due to the latter property, an attacker may be able to find a
collision with a HIT that is in use. Hence, policy decisions such as collision with a HIT that is in use. Hence, policy decisions such as
access control MUST NOT be based solely on the HIT. Instead, the HI access control MUST NOT be based solely on the HIT. Instead, the HI
of a host SHOULD be considered. of a host SHOULD be considered (see Section 7.1).
Carrying HIs or HITs in the header of user data packets would Carrying HIs or HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that increase the overhead of packets. Thus, it is not expected that
these parameters are carried in every packet, but other methods are these parameters are carried in every packet, but other methods are
used to map the data packets to the corresponding HIs. In some used to map the data packets to the corresponding HIs. In some
cases, this allows use of 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
skipping to change at page 44, line 31 skipping to change at page 44, line 31
6.11. Handling State Loss 6.11. Handling State Loss
Implementors MAY choose to use non-volatile, secure storage for HIP Implementors MAY choose to use non-volatile, secure storage for HIP
states in order for them to survive a system reboot. If no secure states in order for them to survive a system reboot. If no secure
storage capabilities are available, the system SHOULD delete the storage capabilities are available, the system SHOULD delete the
corresponding HIP state, including the keying material. If the corresponding HIP state, including the keying material. If the
implementation does drop the state (as RECOMMENDED), it MUST also implementation does drop the state (as RECOMMENDED), it MUST also
drop the peer's R1 generation counter value, unless a local policy drop the peer's R1 generation counter value, unless a local policy
explicitly defines that the value of that particular host is stored. explicitly defines that the value of that particular host is stored.
Such storing of the R1 generation counter values MUST be configured
by explicit HITs. Storing of the R1 generation counter values and ENCRYPTED_KEY counter
(Section 5.2.5) MUST be configured by explicit HITs.
7. HIP Policies 7. HIP Policies
There are a number of variables that will influence the HIP exchanges There are a number of variables that will influence the HIP exchanges
that each host must support. The value of puzzle difficulty K used that each host must support. The value of puzzle difficulty K used
in the HIP R1 must be chosen with care. Values for the K that are in the HIP R1 must be chosen with care. Values for the K that are
too high will exclude clients with weak CPUs because these devices too high will exclude clients with weak CPUs because these devices
cannot solve the puzzle within a reasonable amount of time. The K cannot solve the puzzle within a reasonable amount of time. The K
value should only be raised if a Responder is under high load, i.e., value should only be raised if a Responder is under high load, i.e.,
it cannot process all incoming HIP handshakes any more. it cannot process all incoming HIP handshakes any more.
skipping to change at page 47, line 13 skipping to change at page 47, line 13
TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to
enable the Initiator to verify that these parameters have not been enable the Initiator to verify that these parameters have not been
modified by an attacker in the unprotected R1 packet as explained modified by an attacker in the unprotected R1 packet as explained
in Section 6.8. in Section 6.8.
o Contrary to HIPv2, HIP DEX does not provide for end-point 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.
o It is critical to properly manage the ENCRYPTED_KEY counter
(Section 5.2.5). If non-volatile store is used to maintain HIP
state across system resets, then this counter MUST be part of the
state store.
The optional retransmission extension of HIP DEX is based on a NOTIFY The optional retransmission extension of HIP DEX is based on a NOTIFY
packet that the Responder can use to inform the Initiator about the packet that the Responder can use to inform the Initiator about the
reception of an I2 packet. The Responder, however, cannot protect reception of an I2 packet. The Responder, however, cannot protect
the authenticity of this packet as it did not yet set up the Master the authenticity of this packet as it did not yet set up the Master
Key SA. Hence, an eavesdropping adversary may send spoofed reception Key SA. Hence, an eavesdropping adversary may send spoofed reception
acknowledgements for an overheard I2 packet and signal an arbitrary acknowledgements for an overheard I2 packet and signal an arbitrary
I2 processing time to the Initiator. The adversary can, e.g., I2 processing time to the Initiator. The adversary can, e.g.,
indicate a lower I2 processing time than actually required by the indicate a lower I2 processing time than actually required by the
Responder in order to cause premature retransmissions. To protect Responder in order to cause premature retransmissions. To protect
against this attack, the Initiator SHOULD set the NOTIFY-based against this attack, the Initiator SHOULD set the NOTIFY-based
 End of changes. 13 change blocks. 
14 lines changed or deleted 20 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/