draft-ietf-hip-dex-04.txt   draft-ietf-hip-dex-05.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: April 25, 2017 Hirschmann Automation and Control Expires: August 9, 2017 Hirschmann Automation and Control
October 22, 2016 February 5, 2017
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-04 draft-ietf-hip-dex-05
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. In doing so, the main goal is to still deliver similar
security properties to HIPv2. security properties to HIPv2.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 25, 2017. This Internet-Draft will expire on August 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 4 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5
1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 5 1.2. Memo Structure . . . . . . . . . . . . . . . . . . . . . 6
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 7
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 9
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 11
4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 12
4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 16
4.1.4. User Data Considerations . . . . . . . . . . . . . . 17 4.1.4. User Data Considerations . . . . . . . . . . . . . . 17
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 19 skipping to change at page 3, line 19
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 31
6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 32
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 . . . . . . . . . 40 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 43 12.1. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 43
12.2. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 43 12.2. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 44
12.3. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44 12.3. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 44
12.4. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44 12.4. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 44
12.5. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 44 12.5. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 44
12.6. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 44 12.6. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 44
12.7. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 44 12.7. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 44
12.8. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 44 12.8. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 44
12.9. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 45 12.9. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 45
12.10. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 45 12.10. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 45
12.11. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 45 12.11. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 45
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 . . . . . . . . . . . . . . . . . . 46
13.2. Informative References . . . . . . . . . . . . . . . . . 47 13.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 49 HIP DEX handshake . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 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
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.
The main differences between HIP BEX and HIP DEX are: The main differences between HIP BEX and HIP DEX are:
1. Minimum collection of cryptographic primitives to reduce the 1. HIP DEX uses a different set of cryptographic primitives compared
protocol overhead. to HIP BEX with the goal to reduce the protocol overhead:
* Static Elliptic Curve Diffie-Hellman key pairs for peer * Peer authentication and key agreement in HIP DEX are based on
authentication and encryption of the session key. static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This
replaces the use of public-key signatures and ephemeral
Diffie-Hellman key pairs in HIPv2.
* AES-CTR for symmetric encryption and AES-CMAC for MACing * HIP DEX uses AES-CTR for symmetric-key encryption and AES-CMAC
function. as its MACing function. In contrast, HIPv2 currently supports
AES-CBC for encryption and HMAC-SHA-1, HMAC-SHA-256, or HMAC-
SHA-384 for MACing.
* A simple fold function for HIT generation. * HIP DEX defines a simple fold function to efficiently generate
HITs, whereas the HIT generation of HIPv2 is based on SHA-1,
SHA-256, or SHA-384.
2. Forfeit of Perfect Forward Secrecy with the dropping of an 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of
ephemeral Diffie-Hellman key agreement. HIPv2 due to the removal of the ephemeral Diffie-Hellman key
agreement.
3. Forfeit of digital signatures with the removal of a hash 3. HIP DEX forfeits the use of digital signatures with the removal
function. Reliance on ECDH derived key used in HIP_MAC to prove of a hash function. Peer authentication with HIP DEX, therefore,
ownership of the private key. is based on the use of the ECDH derived key in the HIP_MAC
parameter.
4. Diffie-Hellman derived key ONLY used to protect the HIP packets. 4. With HIP DEX, the ECDH derived key is only used to protect HIP
A separate secret exchange within the HIP packets creates the packets. Separate session key(s) are used to protect the
session key(s). transmission of upper layer protocol data. These session key(s)
are established via a new secret exchange during the handshake.
5. Optional retransmission strategy tailored to handle the 5. HIP DEX introduced a new, optional retransmission strategy that
potentially extensive processing time of the employed is specifically designed to handle potentially extensive
cryptographic operations on computationally constrained devices. processing times of the employed cryptographic operations on
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 computation, 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. Moreover, by dropping the
cryptographic hash function, HIP DEX affords a more efficient cryptographic hash function, HIP DEX affords a more efficient
protocol implementation than HIP BEX with respect to the protocol implementation than HIP BEX with respect to the
corresponding computation and memory requirements. This makes HIP corresponding computation and memory requirements. This makes HIP
DEX especially suitable for constrained devices as defined in DEX especially suitable for constrained devices as defined in
[RFC7228]. [RFC7228].
skipping to change at page 4, line 51 skipping to change at page 5, line 12
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
party is called the Initiator and the second party the Responder. party is called the Initiator and the second party the Responder.
The four-packet exchange helps to make HIP DEX DoS resilient. The The four-packet exchange helps to make HIP DEX Denial of Service
Initiator and the Responder exchange their static Elliptic Curve (DoS) resilient. The Initiator and the Responder exchange their
Diffie-Hellman (ECDH) keys in the 2nd and 3rd handshake packet. The static Elliptic Curve Diffie-Hellman (ECDH) keys in the 2nd and 3rd
parties then authenticate each other in the 3rd and 4th handshake handshake packet. The parties then authenticate each other in the
packet based on the ECDH-derived keying material. The Initiator and 3rd and 4th handshake packet based on the ECDH-derived keying
the Responder additionally transmit keying material for the session material. The Initiator and the Responder additionally transmit
key in these last two handshake packets. This is to prevent overuse keying material for the session key in these last two handshake
of the static ECDH-derived keying material. Moreover, the Responder packets. This is to prevent overuse of the static ECDH-derived
starts a puzzle exchange in the 2nd packet and the Initiator keying material. Moreover, the Responder starts a puzzle exchange in
completes this exchange in the 3rd packet before the Responder the 2nd packet and the Initiator completes this exchange in the 3rd
performs computationally expensive operations or stores any state packet before the Responder performs computationally expensive
from the exchange. Given this handshake structure, HIP DEX operations or stores any state from the exchange. Given this
operationally is very similar to HIP BEX. Moreover, the employed handshake structure, HIP DEX operationally is very similar to HIP
model is also fairly equivalent to 802.11-2007 [IEEE.802-11.2007] BEX. Moreover, the employed model is also fairly equivalent to
Master Key and Pair-wise Transient Key, but handled in a single 802.11-2007 [IEEE.802-11.2007] Master Key and Pair-wise Transient
exchange. Key, but 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 3rd packet. The Responder's Host Identity also is Initiator in the 3rd 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 that indicates such anonymity end-point anonymity and any signaling that indicates such anonymity
should be ignored. should be ignored.
As in [RFC7401], data packets start to flow after the 4th packet. As in [RFC7401], data packets start to flow after the 4th packet.
The 3rd and 4th HIP packets may carry data payload in the future. The 3rd and 4th HIP packets may carry data payload in the future.
However, the details of this may be defined later. However, the details of this may be defined later.
skipping to change at page 10, line 30 skipping to change at page 10, line 36
the sender (Initiator) via a MAC. the sender (Initiator) via a MAC.
The R2 packet acknowledges the receipt of the I2 packet and completes The R2 packet acknowledges the receipt of the I2 packet and completes
the handshake. The R2 contains a key wrap parameter that carries the the handshake. The R2 contains a key wrap parameter that carries the
rest of the keying material of the Responder. The packet is rest of the keying material of the Responder. The packet is
authenticated by the sender (Responder) via a MAC. authenticated by the sender (Responder) via a MAC.
The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)"
and "ENC(DH,y)" refer to the random values x and y that are wrapped and "ENC(DH,y)" refer to the random values x and y that are wrapped
based on the Master Key SA (indicated by ENC and DH). Note that x based on the Master Key SA (indicated by ENC and DH). Note that x
and y each constitute half the final session key material. The and y each constitute half of the final session key material. The
packets also contain other parameters that are not shown in this packets also contain other parameters that are not shown in this
figure. figure.
Initiator Responder Initiator Responder
I1: I1:
---------------------------------> --------------------------------->
remain stateless remain stateless
R1: puzzle, HI R1: puzzle, HI
<-------------------------------- <--------------------------------
solve puzzle solve puzzle
perform ECDH perform ECDH
encrypt x encrypt x
I2: solution, HI, ENC(DH,x), mac I2: solution, HI, ENC(DH,x), mac
---------------------------------> --------------------------------->
check puzzle check puzzle
perform ECDH perform ECDH
check mac check MAC
decrypt x decrypt x
encrypt y encrypt y
R2: ENC(DH,y), mac R2: ENC(DH,y), mac
<--------------------------------- <---------------------------------
check mac check MAC
decrypt y decrypt y
Figure 1: High-level overview of the HIP Diet EXchange
4.1.1. HIP Puzzle Mechanism 4.1.1. HIP Puzzle Mechanism
The purpose of the HIP puzzle mechanism is to protect the Responder The purpose of the HIP puzzle mechanism is to protect the Responder
from a number of denial-of-service threats. It allows the Responder from a number of denial-of-service threats. It allows the Responder
to delay state creation until receiving the I2 packet. Furthermore, to delay state creation until receiving the I2 packet. Furthermore,
the puzzle allows the Responder to use a fairly cheap calculation to the puzzle allows the Responder to use a fairly cheap calculation to
check that the Initiator is "sincere" in the sense that it has check that the Initiator is "sincere" in the sense that it has
churned enough CPU cycles in solving the puzzle. churned enough CPU cycles in solving the puzzle.
The puzzle mechanism enables a Responder to immediately reject an I2 The puzzle mechanism enables a Responder to immediately reject an I2
skipping to change at page 16, line 15 skipping to change at page 16, line 15
4.1.3. HIP DEX Security Associations 4.1.3. HIP DEX Security Associations
HIP DEX establishes two Security Associations (SA), one for the HIP DEX establishes two Security Associations (SA), one for the
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
little data is protected by this SA, it can be long-lived with no a small amount of data is protected by this SA, it can be long-lived
need for rekeying. with no need for rekeying.
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 19, line 32 skipping to change at page 19, line 32
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
the Responder. The HIT_SUITE_LIST parameter is defined in the Responder. The HIT_SUITE_LIST parameter is defined in
Section 5.2.10 of [RFC7401]. Section 5.2.10 of [RFC7401].
The following new HIT Suite IDs are defined for HIP DEX, and the The following new HIT Suite ID is defined for HIP DEX, and the
relationship between the four-bit ID value used in the OGA ID field relationship between the four-bit ID value used in the OGA ID field
and the eight-bit encoding within the HIT_SUITE_LIST ID field is and the eight-bit encoding within the HIT_SUITE_LIST ID field is
clarified: clarified:
HIT Suite Four-bit ID Eight-bit encoding HIT Suite Four-bit ID Eight-bit encoding
ECDH/FOLD 8 0x80 ECDH/FOLD 8 0x80
Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field
allows the peers to distinguish a HIP DEX handshake from a HIPv2 allows the peers to distinguish a HIP DEX handshake from a HIPv2
skipping to change at page 41, line 29 skipping to change at page 41, line 29
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. HIT, to the Initiator. As an adversary could also send such an ICMP
packet in a man-in-the-middle attack with the aim to prevent the HIP
DEX handshake from completing, the Initiator SHOULD NOT react to an
ICMP message after sending the I1 until a reasonable delta time to
get the real Responder's R1 HIP packet.
Note that an implementation may also support both HIP DEX and HIPv2. Note that an implementation may also support both HIP DEX and HIPv2.
It then uses the above procedure to determine the protocol variant It then uses the above procedure to determine the protocol variant
that is supported by its handshake peer and performs the that is supported by its handshake peer and performs the
corresponding handshake. corresponding handshake.
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
skipping to change at page 43, line 35 skipping to change at page 43, line 43
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-04 12.1. Changes in draft-ietf-hip-dex-05
o Clarified main differences between HIP BEX and HIP DEX in
Section 1.
o Addressed MitM attack in Section 8.
o Minor editorial changes.
12.2. 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.2. Changes in draft-ietf-hip-dex-03 12.3. 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.3. Changes in draft-ietf-hip-dex-02 12.4. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.4. Changes in draft-ietf-hip-dex-01 12.5. 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.5. Changes in draft-ietf-hip-dex-00 12.6. 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.6. Changes in draft-moskowitz-hip-rg-dex-06 12.7. 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.7. Changes in draft-moskowitz-hip-dex-00 12.8. 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.8. Changes in draft-moskowitz-hip-dex-01 12.9. 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 to use puzzle difficulty of zero under normal network
skipping to change at page 45, line 19 skipping to change at page 45, 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.9. Changes in draft-moskowitz-hip-dex-02 12.10. 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.10. Changes in draft-moskowitz-hip-dex-03 12.11. 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.11. Changes in draft-moskowitz-hip-dex-04 12.12. 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 47, line 18 skipping to change at page 47, line 34
Cryptography", IEEE Transactions on Information Cryptography", IEEE Transactions on Information
Theory vol. IT-22, number 6, pages 644-654, Nov 1976. Theory vol. IT-22, number 6, pages 644-654, Nov 1976.
[HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K.
Wehrle, "Tailoring End-to-End IP Security Protocols to the Wehrle, "Tailoring End-to-End IP Security Protocols to the
Internet of Things", in Proceedings of IEEE International Internet of Things", in Proceedings of IEEE International
Conference on Network Protocols (ICNP 2013), October 2013. Conference on Network Protocols (ICNP 2013), October 2013.
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-14 (work in Architecture", draft-ietf-hip-rfc4423-bis-15 (work in
progress), June 2016. progress), November 2016.
[IEEE.802-11.2007] [IEEE.802-11.2007]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, June Layer (PHY) Specifications", IEEE Standard 802.11, June
2007, <http://standards.ieee.org/getieee802/ 2007, <http://standards.ieee.org/getieee802/
download/802.11-2007.pdf>. download/802.11-2007.pdf>.
 End of changes. 37 change blocks. 
76 lines changed or deleted 102 lines changed or added

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