draft-ietf-hip-dex-14.txt   draft-ietf-hip-dex-15.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 10, 2020 Hirschmann Automation and Control Expires: September 14, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
March 9, 2020 March 13, 2020
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-14 draft-ietf-hip-dex-15
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 10, 2020. This Internet-Draft will expire on September 14, 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 20 skipping to change at page 3, line 20
6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32
6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35
6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35
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
8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 47 9.1. SECP160R1 Considered Unsafe . . . . . . . . . . . . . . . 47
9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 47 9.2. Need to Validate Public Keys . . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 49 12.1. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 50
12.2. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 49 12.2. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50
12.3. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 49 12.3. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50
12.4. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 49 12.4. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50
12.5. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 49 12.5. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 50
12.6. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50 12.6. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 50
12.7. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 50 12.7. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 50
12.8. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 50 12.8. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51
12.9. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 50 12.9. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51
12.10. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 50 12.10. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51
12.11. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 50 12.11. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 51
12.12. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51 12.12. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 51
12.13. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 51 12.13. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 51
12.14. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 51 12.14. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 52
12.15. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 51 12.15. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52
12.16. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 52 12.16. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52
12.17. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 52 12.17. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 53
12.18. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 52 12.18. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 12.19. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . 53 13.1. Normative References . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Password-based two-factor authentication during the Appendix A. Password-based two-factor authentication during the
HIP DEX handshake . . . . . . . . . . . . . . . . . 56 HIP DEX handshake . . . . . . . . . . . . . . . . . 57
Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57
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
this document. this document.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
| | (suggested | | for Master Key | | | (suggested | | for Master Key |
| | value 644) | | | | | value 644) | | |
+------------------+--------------+----------+----------------------+ +------------------+--------------+----------+----------------------+
5.2.1. DH_GROUP_LIST 5.2.1. DH_GROUP_LIST
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 SECP160R1 [SECG] CKDF 10
Curve25519 [RFC7748] CKDF 12 Curve25519 [RFC7748] CKDF TBD7 (suggested value 12)
Curve448 [RFC7748] CKDF 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 12 and 13 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).
5.2.2. HIP_CIPHER 5.2.2. HIP_CIPHER
The HIP_CIPHER parameter contains the list of supported cipher The HIP_CIPHER parameter contains the list of supported cipher
algorithms to be used for encrypting the contents of the ENCRYPTED algorithms to be used for encrypting the contents of the ENCRYPTED
and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in
Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited
to: to:
skipping to change at page 32, line 21 skipping to change at page 32, line 21
The HIP DEX KEYMAT process is used to derive the keys for the Master The HIP DEX KEYMAT process is used to derive the keys for the Master
Key SA as well as for the Pair-wise Key SA. The keys for the Master Key SA as well as for the Pair-wise Key SA. The keys for the Master
Key SA are based on the Diffie-Hellman derived key, Kij, which is Key SA are based on the Diffie-Hellman derived key, Kij, which is
produced during the HIP DEX handshake. The Initiator generates Kij produced during the HIP DEX handshake. The Initiator generates Kij
during the creation of the I2 packet and the Responder generates Kij during the creation of the I2 packet and the Responder generates Kij
once it receives the I2 packet. This is why the I2 packet can once it receives the I2 packet. This is why the I2 packet can
already contain authenticated and/or encrypted information. already contain authenticated and/or encrypted information.
The keys derived for the Pair-wise Key SA are not used during the HIP 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 DEX handshake. Instead, these keys are made available as payload
protection keys (e.g., for IPsec). Some payload protection protection keys (e.g., for IPsec).
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.
The HIP DEX KEYMAT process is based on the Hash-based Key Derivation The HIP DEX KEYMAT process is based on the Hash-based Key Derivation
Function (HKDF) defined in [RFC5869] and consists of two components, Function (HKDF) defined in [RFC5869] and consists of two components,
CKDF-Extract and CKDF-Expand. The CKDF-Extract function compresses a CKDF-Extract and CKDF-Expand. The CKDF-Extract function compresses a
non-uniformly distributed key, such as the output of a Diffie-Hellman non-uniformly distributed key, such as the output of a Diffie-Hellman
key derivation, to extract the key entropy into a fixed length key derivation, to extract the key entropy into a fixed length
output. The CKDF-Expand function takes either the output of the output. The CKDF-Expand function takes either the output of the
Extract function or directly uses a uniformly distributed key and Extract function or directly uses a uniformly distributed key and
expands the length of the key, repeatedly distributing the key expands the length of the key, repeatedly distributing the key
entropy, to produce the keys needed. entropy, to produce the keys needed.
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. If the system's state machine is in the R2-SENT state, the 4. The system MUST validate the Initiator's HI per Section 9.2.
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.
5. 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
system MUST make a comparison between its local and sender's system MUST make a comparison between its local and sender's
HITs (similarly as in Section 6.3). If the local HIT is smaller HITs (similarly as in Section 6.3). If the local HIT is smaller
than the sender's HIT, it should drop the I2 packet, use the than the sender's HIT, it should drop the I2 packet, use the
peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
#I from the R1 packet received earlier, and get the local #I from the R1 packet received earlier, and get the local
Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
from the I2 packet sent to the peer earlier. Otherwise, the from the I2 packet sent to the peer earlier. Otherwise, the
system processes the received I2 packet and drops any previously system processes the received I2 packet and drops any previously
derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY
keying material it might have generated upon sending the I2 keying material it might have generated upon sending the I2
packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY, packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY,
and the nonce #J are taken from the just arrived I2 packet. The and the nonce #J are taken from the just arrived I2 packet. The
local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the
nonce #I are the ones that were sent earlier in the R1 packet. nonce #I are the ones that were sent earlier in the R1 packet.
6. If the system's state machine is in the I1-SENT state, and the 7. If the system's state machine is in the I1-SENT state, and the
HITs in the I2 packet match those used in the previously sent I1 HITs in the I2 packet match those used in the previously sent I1
packet, the system uses this received I2 packet as the basis for packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes retransmitting I1 packets (provided that the I2 packet passes
the additional checks below). the additional checks below).
7. If the system's state machine is in any state other than 8. If the system's state machine is in any state other than
R2-SENT, the system SHOULD check that the echoed R1 generation R2-SENT, the system SHOULD check that the echoed R1 generation
counter in the I2 packet is within the acceptable range if the counter in the I2 packet is within the acceptable range if the
counter is included. Implementations MUST accept puzzles from counter is included. Implementations MUST accept puzzles from
the current generation and MAY accept puzzles from earlier the current generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly received I2 generations. If the generation counter in the newly received I2
packet is outside the accepted range, the I2 packet is stale packet is outside the accepted range, the I2 packet is stale
(and perhaps replayed) and SHOULD be dropped. (and perhaps replayed) and SHOULD be dropped.
8. The system MUST validate the solution to the puzzle as described 9. The system MUST validate the solution to the puzzle as described
in Section 6.1. in Section 6.1.
9. The I2 packet MUST have a single value in the HIP_CIPHER 10. The I2 packet MUST have a single value in the HIP_CIPHER
parameter, which MUST match one of the values offered to the parameter, which MUST match one of the values offered to the
Initiator in the R1 packet. Initiator in the R1 packet.
10. The system MUST derive Diffie-Hellman keying material Kij based 11. The system MUST derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the HOST_ID parameter. This on the public value and Group ID in the HOST_ID parameter. This
keying material is used to derive the keys of the Master Key SA keying material is used to derive the keys of the Master Key SA
as described in Section 6.3. If the Diffie-Hellman Group ID is as described in Section 6.3. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped. If the unsupported, the I2 packet is silently dropped. If the
processing time for the derivation of the Diffie-Hellman keying processing time for the derivation of the Diffie-Hellman keying
material Kij is likely to cause premature I2 retransmissions by material Kij is likely to cause premature I2 retransmissions by
the Initiator, the system MAY send a NOTIFY packet before the Initiator, the system MAY send a NOTIFY packet before
starting the key derivation process. The NOTIFY packet contains starting the key derivation process. The NOTIFY packet contains
a NOTIFICATION parameter with Notify Message Type a NOTIFICATION parameter with Notify Message Type
I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the
anticipated remaining processing time for the I2 packet in anticipated remaining processing time for the I2 packet in
milliseconds as two-octet Notification Data. milliseconds as two-octet Notification Data.
11. The implementation SHOULD also verify that the Initiator's HIT 12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2 in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not be able to make this packet. (Note: some middleboxes may not be able to make this
verification.) verification.)
12. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
Other documents specifying transport formats (e.g., [RFC7402]) Other documents specifying transport formats (e.g., [RFC7402])
contain specifications for handling any specific transport contain specifications for handling any specific transport
selected. selected.
13. The system MUST verify the HIP_MAC according to the procedures 14. The system MUST verify the HIP_MAC according to the procedures
in Section 6.2. in Section 6.2.
14. If the checks above are valid, then the system proceeds with 15. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state. state machine remains in the same state.
15. The I2 packet may have the A-bit set - in this case, the system 16. The I2 packet may have the A-bit set - in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A-bit is set, the returns to state UNASSOCIATED. If the A-bit is set, the
Initiator's HIT is anonymous and MUST NOT be stored permanently. Initiator's HIT is anonymous and MUST NOT be stored permanently.
16. The system MUST decrypt the keying material from the 17. The system MUST decrypt the keying material from the
ENCRYPTED_KEY parameter. This keying material is a partial ENCRYPTED_KEY parameter. This keying material is a partial
input to the key derivation process for the Pair-wise Key SA input to the key derivation process for the Pair-wise Key SA
(see Section 6.3). (see Section 6.3).
17. The system initializes the remaining variables in the associated 18. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
18. Upon successful processing of an I2 packet when the system's 19. Upon successful processing of an I2 packet when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or
R2-SENT, an R2 packet is sent as described in Section 5.3.4 and R2-SENT, an R2 packet is sent as described in Section 5.3.4 and
the system's state machine transitions to state R2-SENT. the system's state machine transitions to state R2-SENT.
19. Upon successful processing of an I2 packet when the system's 20. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent as is dropped and a new one is installed, an R2 packet is sent as
described in Section 5.3.4, and the system's state machine described in Section 5.3.4, and the system's state machine
transitions to R2-SENT. transitions to R2-SENT.
20. Upon the system's state machine transitioning to R2-SENT, the 21. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP ESTABLISHED if some data has been received on the incoming HIP
association, or an UPDATE packet has been received (or some association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for a has moved to ESTABLISHED). If the timer expires (allowing for a
maximal amount of retransmissions of I2 packets), the state maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED. machine transitions to ESTABLISHED.
Note that steps 11 (encrypted HOST_ID) and 15 (signature Note that steps 11 (encrypted HOST_ID) and 15 (signature
verification) from the original processing rules of HIPv2 have been verification) from the original processing rules of HIPv2 have been
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. If any of the checks above fail, there is a high probability of 5. The system MUST validate the Responder's HI per Section 9.2.
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.
6. 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).
7. Upon successful processing of the R2 packet, the state machine 8. Upon successful processing of the R2 packet, the state machine
transitions to state ESTABLISHED. transitions to state ESTABLISHED.
Note that step 4 (signature verification) from the original Note that step 4 (signature verification) from the original
processing rules of HIPv2 has been replaced with a negotiation re- processing rules of HIPv2 has been replaced with a negotiation re-
evaluation in the above processing rules for HIP DEX. Moreover, step evaluation in the above processing rules for HIP DEX. Moreover, step
6 has been added to the processing rules. 6 has been added to the processing rules.
6.9. Processing Incoming NOTIFY Packets 6.9. Processing Incoming NOTIFY Packets
Processing of NOTIFY packets is OPTIONAL. If processed, any errors Processing of NOTIFY packets is OPTIONAL. If processed, any errors
skipping to change at page 45, line 5 skipping to change at page 45, line 5
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.
If a Responder is not under high load, K SHOULD be 0. If a Responder is not under high load, K SHOULD be 0.
All HIP DEX implementations SHOULD provide for an Access Control List All HIP DEX implementations SHOULD provide for an Access Control List
(ACL), representing for which hosts they accept HIP diet exchanges, (ACL), representing for which hosts they accept HIP diet exchanges,
and the preferred transport format and local lifetimes. Wildcarding and the preferred transport format and local lifetimes. Wildcarding
SHOULD be supported for such ACLs. SHOULD be supported for such ACLs.
7.1. HIT/HI ACL
Both the Initiator and Responder SHOULD implement an ACL. Minimally,
these ACLs will be a list of trusted HIT/HIs. They may also contain
the password used in the password-based two-factor authentication
(Appendix A) and preferred HIT Suite.
ACL processing is applied to all HIP packets. A HIP peer MAY reject
any packet where the Receiver's HIT is not in the ACL. The HI (in
the R1, I2, and optionally NOTIFY packets) MUST be validated as well,
when present in the ACL. This is the defense against collision and
second-image attacks on the HIT generation.
Devices with no input mechanism (e.g. sensors) SHOULD accept R1
packets from unknown HITs. These R1 packets SHOULD contain the start
of the password-based two-factor authentication . If the R2 for this
HIT indicates success, then the device may add this HIT to its ACL
for future use.
Devices unable to manage an ACL (e.g. sensors) are subject to MITM
attacks, even with the use of the password authentication (password
theft by attacker). As long as the other peer (e.g. sensor
controller) does use an ACL, the attack can be recognized there and
addressed. This is often seen where the sensor does not appear as
properly operating with the controller, as the attacker cannot
impersonate information in the ACL.
8. Interoperability between HIP DEX and HIPv2 8. Interoperability between HIP DEX and HIPv2
HIP DEX and HIPv2 both use the same protocol number and packet HIP DEX and HIPv2 both use the same protocol number and packet
formats. Hence, an implementation that either supports HIP DEX or formats. Hence, an implementation that either supports HIP DEX or
HIPv2 has to be able to detect the dialect that the peer is speaking. HIPv2 has to be able to detect the dialect that the peer is speaking.
This section outlines how a HIP DEX implementation can achieve such This section outlines how a HIP DEX implementation can achieve such
detection for the two relevant cases where: detection for the two relevant cases where:
1. the Initiator supports HIP DEX and the Responder supports HIP 1. the Initiator supports HIP DEX and the Responder supports HIP
BEX, BEX,
skipping to change at page 48, line 11 skipping to change at page 48, line 39
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
5.
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.
I_NONCE "I_NONCE" with type number TBD6 (suggested: 644) (see DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519
Section 5.2.6) in the "Parameter Types" subregistry of the "Host with value TBD7 (suggested: 12) and Curve448 with value TBD8
Identity Protocol (HIP) Parameters" registry. (suggested: 13) (see Section 5.2.1) in the "Group IDs" subregistry
of the "Host Identity Protocol (HIP) Parameters" registry.
HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD"
without four-bit ID of TBD2 (suggested: 4) and eight-bit encoding without four-bit ID of TBD2 (suggested: 4) and eight-bit encoding
of TBD3 (suggested: 0x40) (see Section 5.2.4) in the "HIT Suite of TBD3 (suggested: 0x40) (see Section 5.2.4) in the "HIT Suite
ID" subregistry of the "Host Identity Protocol (HIP) Parameters" ID" subregistry of the "Host Identity Protocol (HIP) Parameters"
registry. registry.
HIP Cipher ID This document defines the new HIP Cipher ID "AES- HIP Cipher ID This document defines the new HIP Cipher ID "AES-
128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2) 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2)
in the "HIP Cipher ID" subregistry of the "Host Identity Protocol in the "HIP Cipher ID" subregistry of the "Host Identity Protocol
(HIP) Parameters" registry. (HIP) Parameters" registry.
HI Algorithm This document defines the new HI Algorithm "ECDH" with HI Algorithm This document defines the new HI Algorithm "ECDH" with
type number TBD5 (suggested: 11) (see Section 5.2.3) in the "HI type number TBD5 (suggested: 11) (see Section 5.2.3) in the "HI
Algorithm" subregistry of the "Host Identity Protocol (HIP) Algorithm" subregistry of the "Host Identity Protocol (HIP)
Parameters" registry. Parameters" registry.
I_NONCE "I_NONCE" with type number TBD6 (suggested: 644) (see
Section 5.2.6) in the "Parameter Types" subregistry of the "Host
Identity Protocol (HIP) Parameters" registry.
ECC Curve Label This document specifies a new algorithm-specific ECC Curve Label This document specifies a new algorithm-specific
subregistry named "ECDH Curve Label". The values for this subregistry named "ECDH Curve Label". The values for this
subregistry are defined in Section 5.2.1. The complete list of subregistry are defined in Section 5.2.1. The complete list of
algorithms for the DH_GROUP_LIST parameter are listed in the algorithms for the DH_GROUP_LIST parameter are listed in the
"Group IDs" subregistry of the "Host Identity Protocol (HIP) "Group IDs" subregistry of the "Host Identity Protocol (HIP)
Parameters" registry. Parameters" registry.
11. Acknowledgements 11. Acknowledgements
The drive to put HIP on a cryptographic 'Diet' came out of a number The drive to put HIP on a cryptographic 'Diet' came out of a number
skipping to change at page 49, line 16 skipping to change at page 50, line 5
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-14 12.1. Changes in draft-ietf-hip-dex-15
o Added Public Key validation in I2 and R2 processing.
o Added ACL processing (Section 7.1).
o Added IANA instructions for DH_GROUP_LIST.
12.2. 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.2. Changes in draft-ietf-hip-dex-12 and 13 12.3. 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.3. Changes in draft-ietf-hip-dex-11 and 12 12.4. 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" (Section 9.1), "Need to Validate Public Keys"
(Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric (Section 9.2), and "I_NONCE" (Section 5.2.6) to address Eric
Rescorla's concerns. Rescorla's concerns.
12.4. Changes in draft-ietf-hip-dex-11 12.5. 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.5. Changes in draft-ietf-hip-dex-10 12.6. 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.6. Changes in draft-ietf-hip-dex-09 12.7. 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.7. Changes in draft-ietf-hip-dex-05 12.8. 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.8. Changes in draft-ietf-hip-dex-04 12.9. 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.9. Changes in draft-ietf-hip-dex-03 12.10. 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.10. Changes in draft-ietf-hip-dex-02 12.11. Changes in draft-ietf-hip-dex-02
o Author address change. o Author address change.
12.11. Changes in draft-ietf-hip-dex-01 12.12. 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.12. Changes in draft-ietf-hip-dex-00 12.13. 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.13. Changes in draft-moskowitz-hip-rg-dex-06 12.14. 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.14. Changes in draft-moskowitz-hip-dex-00 12.15. 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.15. Changes in draft-moskowitz-hip-dex-01 12.16. 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 52, line 7 skipping to change at page 53, line 5
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.16. Changes in draft-moskowitz-hip-dex-02 12.17. 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.17. Changes in draft-moskowitz-hip-dex-03 12.18. 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.18. Changes in draft-moskowitz-hip-dex-04 12.19. 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. 58 change blocks. 
86 lines changed or deleted 130 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/