draft-ietf-hip-dex-10.txt   draft-ietf-hip-dex-11.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 22, 2020 Hirschmann Automation and Control Expires: May 2, 2020 Hirschmann Automation and Control
M. Komu M. Komu
Ericsson Ericsson
October 20, 2019 October 30, 2019
HIP Diet EXchange (DEX) HIP Diet EXchange (DEX)
draft-ietf-hip-dex-10 draft-ietf-hip-dex-11
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 April 22, 2020. This Internet-Draft will expire on May 2, 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 6, line 16 skipping to change at page 6, line 16
1.2. Memo Structure 1.2. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout this the central keywords, notation, and terms used throughout this
document. Section 3 defines the structure of the Host Identity and document. Section 3 defines the structure of the Host Identity and
its various representations. Section 4 gives an overview of the HIP its various representations. Section 4 gives an overview of the HIP
Diet EXchange protocol. Sections 5 and 6 define the detailed packet Diet EXchange protocol. Sections 5 and 6 define the detailed packet
formats and rules for packet processing. Finally, Sections 7, 8, 9, formats and rules for packet processing. Finally, Sections 7, 8, 9,
and 10 discuss policy, interoperability between HIPv2 vs DEX, and 10 discuss policy, interoperability between HIPv2 vs DEX,
security, and IANA considerations, respectively. security, and IANA considerations, respectively. Appendix A defines
a two factor authentication scheme and Appendix B highligts some
discussions with the IESG.
2. Terms, Notation and Definitions 2. Terms, Notation and Definitions
2.1. Requirements Terminology 2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
FOLD (X, K) denotes the partitioning of X into n K-bit segments and FOLD (X, K) denotes the partitioning of X into n K-bit segments and
the iterative folding of these segments via XOR. I.e., X = x_1, the iterative folding of these segments via XOR. I.e., X = x_1,
x_2, ..., x_n, where x_i is of length K and the last segment x_n x_2, ..., x_n, where x_i is of length K and the last segment x_n
is padded to length K by appending 0 bits. FOLD then is computed is padded to length K by appending 0 bits. FOLD then is computed
as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1.
Ltrunc (M(x), K) denotes the lowest order K bits of the result of Ltrunc (M(x), K) denotes the lowest order K bits of the result of
the MAC function M on the input x. the MAC function M on the input x.
sort (HIT-I | HIT-R) sort(HIT-I | HIT-R) is defined as the network sort (HIT-I | HIT-R) is defined as the network byte order
byte order concatenation of the two HITs, with the smaller HIT concatenation of the two HITs, with the smaller HIT preceding the
preceding the larger HIT, resulting from the numeric comparison of larger HIT, resulting from the numeric comparison of the two HITs
the two HITs interpreted as positive (unsigned) 128-bit integers interpreted as positive (unsigned) 128-bit integers in network
in network byte order. byte order.
2.3. Definitions 2.3. Definitions
HIP Diet Exchange (DEX): The ECDH-based HIP handshake for HIP Diet Exchange (DEX): The ECDH-based HIP handshake for
establishing a new HIP association. establishing a new HIP association.
Host Identity (HI): The static ECDH public key that represents the Host Identity (HI): The static ECDH public key that represents the
identity of the host. In HIP DEX, a host proves ownership of the identity of the host. In HIP DEX, a host proves ownership of the
private key belonging to its HI by creating a HIP_MAC with the private key belonging to its HI by creating a HIP_MAC with the
derived ECDH key (see Section 3). derived ECDH key (see Section 3).
skipping to change at page 18, line 7 skipping to change at page 18, line 7
o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT. o HIP_CIPHER is restricted to AES-128-CTR and NULL-ENCRYPT.
o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD.
o RHASH and RHASH_len are redefined to CMAC for the PUZZLE, o RHASH and RHASH_len are redefined to CMAC for the PUZZLE,
SOLUTION, and HIP_MAC parameters (see Section 6.1 and SOLUTION, and HIP_MAC parameters (see Section 6.1 and
Section 6.2). Section 6.2).
In addition, HIP DEX introduces the following new parameter: In addition, HIP DEX introduces the following new parameter:
+------------------+------+----------+------------------------------+ +------------------+--------------+----------+----------------------+
| TLV | Type | Length | Data | | TLV | Type | Length | Data |
+------------------+------+----------+------------------------------+ +------------------+--------------+----------+----------------------+
| ENCRYPTED_KEY | 643 | variable | Encrypted container for the | | ENCRYPTED_KEY | TBD1 | variable | Encrypted container |
| | | | session key exchange | | | (suggested | | for the session key |
+------------------+------+----------+------------------------------+ | | value 643) | | exchange |
+------------------+--------------+----------+----------------------+
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
skipping to change at page 18, line 48 skipping to change at page 18, line 49
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:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
NULL-ENCRYPT 1 ([RFC2410]) NULL-ENCRYPT 1 ([RFC2410])
AES-128-CTR 5 ([RFC3686]) AES-128-CTR TBD4 (suggested: 5) ([RFC3686])
Mandatory implementation: AES-128-CTR. Implementors SHOULD support Mandatory implementation: AES-128-CTR. Implementors SHOULD support
NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT NULL-ENCRYPT ([RFC2410]) for testing/debugging purposes but MUST NOT
offer or accept this value unless explicitly configured for testing/ offer or accept this value unless explicitly configured for testing/
debugging of HIP. debugging of HIP.
5.2.3. HOST_ID 5.2.3. HOST_ID
The HOST_ID parameter conveys the Host Identity (HI) along with The HOST_ID parameter conveys the Host Identity (HI) along with
optional information about a host. The HOST_ID parameter is defined optional information about a host. The HOST_ID parameter is defined
in Section 5.2.9 of [RFC7401]. in Section 5.2.9 of [RFC7401].
HIP DEX uses the public portion of a host's static ECDH key-pair as HIP DEX uses the public portion of a host's static ECDH key-pair as
the HI. Correspondingly, HIP DEX limits the HI algorithms to the the HI. Correspondingly, HIP DEX limits the HI algorithms to the
following new profile: following new profile:
Algorithm profiles Value Algorithm profiles Value
ECDH 11 [RFC6090] (REQUIRED) ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED)
HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see
Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is
encoded in the "ECC curve" field of the HOST_ID parameter. The encoded in the "ECC curve" field of the HOST_ID parameter. The
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 ID is 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 4 0x40 ECDH/FOLD TBD2 (suggestion: 4) TBD3 (suggestion: 0x40)
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
handshake. The Responder MUST respond with a HIP DEX HIT suite ID handshake. The Responder MUST respond with a HIP DEX HIT suite ID
when the HIT of the Initiator is a HIP DEX HIT. when the HIT of the Initiator is a HIP DEX HIT.
5.2.5. ENCRYPTED_KEY 5.2.5. ENCRYPTED_KEY
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Encrypted value / / Encrypted value /
/ / / /
/ +-------------------------------+ / +-------------------------------+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 643 Type TBD1 (suggested value 643)
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Encrypted The value is encrypted using an encryption algorithm Encrypted The value is encrypted using an encryption algorithm
value as defined in the HIP_CIPHER parameter. value as defined in the HIP_CIPHER parameter.
The ENCRYPTED_KEY parameter encapsulates a random value that is later The ENCRYPTED_KEY parameter encapsulates a random value that is later
used in the session key creation process (see Section 6.3). This used in the session key creation process (see Section 6.3). This
random value MUST have a length of at least 64 bits. The puzzle random value MUST have a length of at least 64 bits. The puzzle
value #I and the puzzle solution #J (see Section 4.1.2 in [RFC7401]) value #I and the puzzle solution #J (see Section 4.1.2 in [RFC7401])
are used as the initialization vector (IV) for the encryption are used as the initialization vector (IV) for the encryption
skipping to change at page 24, line 39 skipping to change at page 24, line 39
Type = 3 Type = 3
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT DST HIT = Responder's HIT
IP ( HIP ( [R1_COUNTER,] IP ( HIP ( [R1_COUNTER,]
SOLUTION, SOLUTION,
HIP_CIPHER, HIP_CIPHER,
ENCRYPTED_KEY, ENCRYPTED_KEY,
HOST_ID, HOST_ID,
TRANSPORT_FORMAT_LIST, TRANSPORT_FORMAT_LIST,
HIP_MAC, HIP_MAC
[<, ECHO_RESPONSE_UNSIGNED>i )] ) [<, ECHO_RESPONSE_UNSIGNED>i )] )
Valid control bits: A Valid control bits: A
The HITs MUST match the ones used in the R1 packet. The HITs MUST match the ones used in the R1 packet.
If the Initiator's HI is an anonymous one, the A control bit MUST be If the Initiator's HI is an anonymous one, the A control bit MUST be
set. set.
If present in the R1 packet, the Initiator MUST include an unmodified If present in the R1 packet, the Initiator MUST include an unmodified
skipping to change at page 26, line 51 skipping to change at page 26, line 51
Due to the adopted protocol semantics and the inherited general Due to the adopted protocol semantics and the inherited general
packet structure, the packet processing in HIP DEX only differs from packet structure, the packet processing in HIP DEX only differs from
HIPv2 in very few places. Here, we focus on these differences and HIPv2 in very few places. Here, we focus on these differences and
refer to Section 6 in [RFC7401] otherwise. refer to Section 6 in [RFC7401] otherwise.
The processing of outgoing and incoming application data remains the The processing of outgoing and incoming application data remains the
same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]).
It should be noted that many of the packet processing rules are It should be noted that many of the packet processing rules are
denoted here with "SHOULD" but may be updated to "MUST" when further denoted here with "SHOULD" but may be updated to "MUST" when further
implementation experience provides better guidance. implementation experience provides better guidance. Please refer
also to Appendix B for argumentation about the SHOULDs.
6.1. Solving the Puzzle 6.1. Solving the Puzzle
The procedures for solving and verifying a puzzle in HIP DEX are The procedures for solving and verifying a puzzle in HIP DEX are
strongly based on the corresponding procedures in HIPv2. The only strongly based on the corresponding procedures in HIPv2. The only
exceptions are that HIP DEX does not use pre-computation of R1 exceptions are that HIP DEX does not use pre-computation of R1
packets and that RHASH is set to CMAC. As a result, the pre- packets and that RHASH is set to CMAC. As a result, the pre-
computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX.
Moreover, the Initiator solves a puzzle by computing: Moreover, the Initiator solves a puzzle by computing:
skipping to change at page 43, line 23 skipping to change at page 43, line 23
Therefore, an implementation has to cache information (e.g., at least Therefore, an implementation has to cache information (e.g., at least
the HITs) from incoming I1 packets and rate control the incoming I1 the HITs) from incoming I1 packets and rate control the incoming I1
packets to avoid unnecessary packet processing during I1 packet packets to avoid unnecessary packet processing during I1 packet
storms. storms.
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:
HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD"
without four-bit ID of 8 and eight-bit encoding of 0x80 (see
Section 5.2.4).
Parameter Type This document defines the new HIP parameter Parameter Type This document defines the new HIP parameter
"ENCRYPTED_KEY" with type number 643 (see Section 5.2.5). "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) (see
Section 5.2.5).
HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD"
without four-bit ID of TBD2 (suggested: 8) and eight-bit encoding
of TBD3 (suggested: 0x80) (see Section 5.2.4).
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 5 (see Section 5.2.2). 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2).
HI Algorithm This document defines the new HI Algorithm "ECDH" with HI Algorithm This document defines the new HI Algorithm "ECDH" with
type number 11 (see Section 5.2.3). type number TBD5 (suggested: 11) (see Section 5.2.3).
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. subregistry are defined in Section 5.2.1.
11. Acknowledgments 11. Acknowledgments
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
of discussions with sensor vendors at IEEE 802.15 meetings. David of discussions with sensor vendors at IEEE 802.15 meetings. David
McGrew was very helpful in crafting this document. Special thanks to McGrew was very helpful in crafting this document. Special thanks to
 End of changes. 18 change blocks. 
32 lines changed or deleted 36 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/