draft-ietf-hip-dex-09.txt   draft-ietf-hip-dex-10.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: March 28, 2020 Hirschmann Automation and Control Expires: April 22, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
September 25, 2019 October 20, 2019
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-09 draft-ietf-hip-dex-10
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 45 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 March 28, 2020. This Internet-Draft will expire on April 22, 2020.
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 40 skipping to change at page 3, line 40
12.9. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45 12.9. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 45
12.10. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45 12.10. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45
12.11. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46 12.11. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 46
12.12. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46 12.12. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 46
12.13. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46 12.13. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . 47 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 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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 50, line 24 skipping to change at page 50, line 24
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
During IEDG review, a concern was raised on the number of SHOULDS in
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
SHOULDS that match up with [RFC7401]:
5.2.2. HIP_CIPHER (same as 7401)
6.5. Processing Incoming I1 Packets
3. (same as 7401)
5. (same as 7401)
6.6. Processing Incoming R1 Packets (same as 7401)
6.7. Processing Incoming I2 Packets
3. (same as 7401)
7. (same as 7401)
11. (same as 7401)
6.8. Processing Incoming R2 Packets
5. (same as 7401)
6.9. Processing Incoming NOTIFY Packets
1st para (same as 7401)
6.11. Handling State Loss (same as 7401)
7. HIP Policies (1st and 3rd same as 7401)
Many of the other 11 SHOULDS are due to the nature of constrained
devices and in most cases the text points this out:
In Section 4.1.1, this is clearly adjusting for how the puzzle could
actually be an attack against a constrained device. Same situation
in Section 5.3.2.
Section 6, clearly states that:
it should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further
implementation experience provides better guidance.
thus the SHOULD here is informative of future guidance.
The SHOULD in Section 6.3, clearly reflects new work with the new
Sponge Function KDFs:
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
protection keys (e.g., for IPsec). Some payload protection
mechanisms have their own Key Derivation Function, and if so this
mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST
be used to derive the keys of the Pair-wise Key SA based on the
concatenation of the random values that are contained in the
exchanged ENCRYPTED_KEY parameters.
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
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
Responder selects a DEX HIT, but there are good reasons, in an
implementation not to do so. The implementer should know this and
will deal with it appropriately.
The SHOULDS in Section 6.7 and Section 6.9 are there for
considerations for constrained systems. Some constrained systems
need this approach, others may not.
The 2nd SHOULD in Section 7 follows the same as above. ACLs and
constrained systems tend to go together.
Similarly in Section 8 the SHOULD is again is highlighting
constrained system processing considerations.
Authors' Addresses Authors' Addresses
Robert Moskowitz (editor) Robert Moskowitz (editor)
HTT Consulting HTT Consulting
Oak Park, MI Oak Park, MI
USA USA
EMail: rgm@htt-consult.com EMail: rgm@htt-consult.com
Rene Hummen Rene Hummen
 End of changes. 6 change blocks. 
5 lines changed or deleted 82 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/