< draft-ietf-hip-dex-07.txt   draft-ietf-hip-dex-08.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: November 1, 2019 Hirschmann Automation and Control Expires: December 26, 2019 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
April 30, 2019 June 24, 2019
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-07 draft-ietf-hip-dex-08
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. In doing so, the main goal is to still deliver similar functions.
security properties to HIPv2.
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. In addition, HIP DEX can also be used as a keying
mechanism for security primitives at the MAC layer, e.g., for IEEE mechanism for security primitives at the MAC layer, e.g., for IEEE
802.15.4 networks. 802.15.4 networks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 45
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 November 1, 2019. This Internet-Draft will expire on December 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 21 skipping to change at page 3, line 21
6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 35
6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 38
6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 39
6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 40
6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 40
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 41 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 44 12.1. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 44
12.2. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44 12.2. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44
12.3. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44 12.3. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44
12.4. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44 12.4. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44
12.5. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44 12.5. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44
12.6. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 44 12.6. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 45
12.7. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 45 12.7. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 45
12.8. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45 12.8. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45
12.9. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 12.9. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45
12.10. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46 12.10. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46
12.11. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46 12.11. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46
12.12. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 12.12. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
13.1. Normative References . . . . . . . . . . . . . . . . . . 46 13.1. Normative References . . . . . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . 48 13.2. Informative References . . . . . . . . . . . . . . . . . 48
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 . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
packets. Separate session key(s) are used to protect the packets. Separate session key(s) are used to protect the
transmission of upper layer protocol data. These session key(s) transmission of upper layer protocol data. These session key(s)
are established via a new secret exchange during the handshake. are established via a new secret exchange during the handshake.
5. HIP DEX introduced a new, optional retransmission strategy that 5. HIP DEX introduced a new, optional retransmission strategy that
is specifically designed to handle potentially extensive is specifically designed to handle potentially extensive
processing times of the employed cryptographic operations on processing times of the employed cryptographic operations on
computationally constrained devices. computationally constrained devices.
By eliminating the need for public-key signatures and the ephemeral By eliminating the need for public-key signatures and the ephemeral
DH key agreement, HIP DEX reduces the computation, energy, DH key agreement, HIP DEX reduces the computational, energy,
transmission, and memory requirements for public-key cryptography transmission, and memory requirements for public-key cryptography
(see [LN08]) in the HIPv2 protocol design. Moreover, by dropping the (see [LN08]) in the HIPv2 protocol design. This makes HIP DEX
cryptographic hash function, HIP DEX affords a more efficient especially suitable for constrained devices as defined in [RFC7228].
protocol implementation than HIP BEX with respect to the
corresponding computation and memory requirements. This makes HIP
DEX especially suitable for constrained devices as defined in
[RFC7228].
This document focuses on the protocol specifications related to This document focuses on the protocol specifications related to
differences between HIP BEX and HIP DEX. Where differences are not differences between HIP BEX and HIP DEX. Where differences are not
called out explicitly, the protocol specification of HIP DEX is the called out explicitly, the protocol specification of HIP DEX is the
same as defined in [RFC7401]. same as defined in [RFC7401].
1.1. The HIP Diet EXchange (DEX) 1.1. The HIP Diet EXchange (DEX)
The HIP Diet EXchange is a two-party cryptographic protocol used to The HIP Diet EXchange is a two-party cryptographic protocol used to
establish a secure communication context between hosts. The first establish a secure communication context between hosts. The first
skipping to change at page 41, line 34 skipping to change at page 41, line 34
the HIP DEX implementation performs the above check on reception of the HIP DEX implementation performs the above check on reception of
the R1 packet and cancels the handshake in case of a negative result. the R1 packet and cancels the handshake in case of a negative result.
In both failure scenarios, the implementation should report an error In both failure scenarios, the implementation should report an error
to the user via appropriate means. to the user via appropriate means.
In the second case, the HIP DEX implementation (Responder) inspects In the second case, the HIP DEX implementation (Responder) inspects
the Initiator's HIT on reception of an I1 packet. If the OGA ID the Initiator's HIT on reception of an I1 packet. If the OGA ID
field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP
DEX implementation cancels the handshake and sends an ICMP packet DEX implementation cancels the handshake and sends an ICMP packet
with type Parameter Problem, with the Pointer pointing to the source with type Parameter Problem, with the Pointer pointing to the source
HIT, to the Initiator. As an adversary could also send such an ICMP HIT, to the Initiator. As an off-path adversary could also send such
packet in a man-in-the-middle attack with the aim to prevent the HIP an ICMP packet with the aim to prevent the HIP DEX handshake from
DEX handshake from completing, the Initiator SHOULD NOT react to an completing, the Initiator SHOULD NOT react to an ICMP message before
ICMP message before retransmission counter reaches I1_RETRIES_MAX in retransmission counter reaches I1_RETRIES_MAX in its state machine
its state machine (see Table 3 in [RFC7401]). (see Table 3 in [RFC7401]).
9. Security Considerations 9. Security Considerations
HIP DEX closely resembles HIPv2. As such, the security HIP DEX closely resembles HIPv2. As such, the security
considerations discussed in Section 8 of [RFC7401] similarly apply to considerations discussed in Section 8 of [RFC7401] similarly apply to
HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated
Diffie-Hellman key exchange of HIPv2 with an exchange of random Diffie-Hellman key exchange of HIPv2 with an exchange of random
keying material that is encrypted with a Diffie-Hellman derived key. keying material that is encrypted with a Diffie-Hellman derived key.
Both the Initiator and Responder contribute to this keying material. Both the Initiator and Responder contribute to this keying material.
As a result, the following additional security considerations apply As a result, the following additional security considerations apply
to HIP DEX: to HIP DEX:
o The strength of the keys for the Pair-wise Key SA is based on the o The strength of the keys for the Pair-wise Key SA is based on the
quality of the random keying material generated by the Initiator quality of the random keying material generated by the Initiator
and the Responder. As either peer may be a sensor or an actuator and the Responder. As either peer may be a sensor or an actuator
device, there is a natural concern about the quality of its random device, there is a natural concern about the quality of its random
number generator. number generator.
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 HIP connections Consequently, if an HI is compromised, all previous HIP
protected with that HI are compromised as explained in Section 1. connections protected with that HI are compromised as explained in
Section 1.
o The puzzle mechanism using CMAC explained in Section 4.1.1 may o The puzzle mechanism using CMAC explained in Section 4.1.1 may
need further study regarding the level of difficulty in order to need further study regarding the level of difficulty in order to
establish best practices with current generation of constrained establish best practices with current generation of constrained
devices. 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.
 End of changes. 12 change blocks. 
23 lines changed or deleted 19 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/