| Internet-Draft | HIP New Crypto | January 2020 |
| Moskowitz, et al. | Expires 26 July 2020 | [Page] |
This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 26 July 2020.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document adds new cryptographic algorithms for HIPv2 [RFC7401]. This includes:¶
The hashes and encryption are all built on the [Keccak] sponge function.¶
These additions reflect selection of advances in the field of cryptography that would best benefit HIP, particularly in constrained devices and communications.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
HIP parameters carry information that is necessary for establishing and maintaining a HIP association. For example, the device's public keys as well as the signaling for negotiating ciphers and payload handling are encapsulated in HIP parameters. Additional information, meaningful for end hosts or middleboxes, may also be included in HIP parameters. The specification of the HIP parameters and their mapping to HIP packets and packet types is flexible to allow HIP extensions to define new parameters and new protocol behavior.¶
Elliptic curves Curve25519 and Curve448 [RFC7748] are specified here for use in the HIP Diffie-Hellman exchange.¶
Curve25519 and Curve448 are already defined in Section 5.2.1 of [I-D.ietf-hip-dex], using the HIP-DEX CKDF. Here they are defined for using the new KMAC [NIST.SP.800-185] derived KDF in Section 5.¶
The DIFFIE_HELLMAN parameter may be included in selected HIP packets based on the DH Group ID selected. The DIFFIE_HELLMAN parameter is defined in Section 5.2.7 of [RFC7401].¶
The following Elliptic Curves are defined here:¶
Group KDF Value Curve25519 [RFC7748] KKDF 13 Curve448 [RFC7748] KKDF 14¶
A new KDF for KEYMAT, Section 6.5 of [RFC7401] and Section 6.3 of [I-D.ietf-hip-dex] using Keccak is defined in Section 5.¶
Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are specified here for use as Host Identities (HIs).¶
The HOST_ID parameter specifies the public key algorithm, and for elliptic curves, a name. The HOST_ID parameter is defined in Section 5.2.19 of [RFC7401].¶
Algorithm
profiles Values
EdDSA 13 [RFC8032] (RECOMMENDED)
¶
For hosts that implement EdDSA as the algorithm, the following ECC curves are available:¶
Algorithm Curve Values
EdDSA RESERVED 0
EdDSA EdDSA25519 1 [RFC8032]
EdDSA EdDSA25519ph 2 [RFC8032]
EdDSA EdDSA448 3 [RFC8032]
EdDSA EdDSA448ph 4 [RFC8032]
¶
The HIT_SUITE_LIST parameter contains a list of the supported HIT suite IDs of the Responder. Based on the HIT_SUITE_LIST, the Initiator can determine which source HIT Suite IDs are supported by the Responder. The HIT_SUITE_LIST parameter is defined in Section 5.2.10 of [RFC7401].¶
The following HIT Suite ID is defined, and the 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 clarified:¶
HIT Suite Four-bit ID Eight-bit encoding
RESERVED 0 0x00
EdDSA/SHAKE128 5 0x50 (RECOMMENDED)
¶
The following table provides more detail on the above HIT Suite combinations. The input for each generation algorithm is the encoding of the HI as defined in Section 4. The output is 96 bits long and is directly used in the ORCHID.¶
| Index | Hash function | HMAC | Signature algorithm family | Description |
|---|---|---|---|---|
| 5 | SHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed with cSHAKE128, output is 96 bits |
The [Keccak] sponge function is the basis for the new SHA-3, standard [NIST.FIPS.202], and the customized XOF functions in [NIST.SP.800-185]. These are used here as an alternative to all the hashing functions in HIP.¶
Hardware implementation of Keccak in VHDL is available from [Keccak].¶
Keccak is described as a sponge function. The analogy to a sponge is that an arbitrary number of input bits are "absorbed" into the state of the function, after which an arbitrary number of output bits are "squeezed" out of its state.¶
b is one of the set {25, 50, 100, 200, 400, 800, 1600}. In FIPS 202, b=1600. Thus a hash strength of 128 bits can be delivered with c=256 and r=1344, or 168 byte segment input to the sponge.¶
Keccak can also provide a hash strength of 128 bit with b=800 (r=544 or 68 bytes) and b=400 (r=144 or 18 bytes). 256 bit strength can only be provided with b=1600 or 800.¶
FIPS 202 does not specify use of these smaller values for b which may be preferred in memory constrained devices, processing relatively short input strings. Future work will determine if the smaller values for b result in a significant performance/memory improvement to warrant their use.¶
The RHASH is the general term used throughout [RFC7401] to refer to the hash used for a specific HIT suite. For this addendum SHAKE128 is used, even for HIs of EdDSA448.¶
Unless otherwise specified, L of SHAKE128 is 256, resulting in a similar output to SHA256. Any truncation used for, older, fixed output hashes is still used. This is to simplify code integration. One exception to this is in Section 4.¶
The HIP_MAC and HIP_MAC2 parameters in [RFC7401] use HMAC [RFC2104]. This performs two hashes on a string with a key for a keyed hash the length of the underlying hash.¶
Here, KMAC from NIST SP 800-185 [NIST.SP.800-185] is used. This is a single pass using the underlying cSHAKE function. The function call is:¶
KMAC128(Key, Input String, 256, "")
¶
HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of [RFC7401]. The Keccak Keyak cipher, [Keyak_Cipher], is recommended. Keyak is a candidate in the NIST Lightweight Cryptography competition and is consistent with the overall approach in this addendum to use Keccak functions for simplicity in design and implementation.¶
The HIP_CIPHER parameter values for Keyak are:¶
hip_cipher
Suite ID Value
RIVER KEYAK 6 (Keyak)
LAKE KEYAK 7 (Keyak)
¶
For use as the HIP Cipher, the TAG generated in Keyak is length 0. The Keyak SUV is the key plus IV specified for the encrypted parameter. River Keyak MAY be used for [Keyak_Cipher], in place of AES-CTR.¶
Lake Keyak can provide 256 bits of security by following the recommendations for the Keyak cipher.¶
The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation method described in section 3.2 of [RFC7401]. The XOF functionality of cSHAKE produces an output of L bits. This replaces the Encode_96 function in the ORCHID generation.¶
For identities that are EdDSA public keys, ORCHIDs will be generated per the process defined in Using cSHAKE in ORCHIDs [I-D.moskowitz-orchid-cshake]¶
The KMAC function provides a new, more efficient, key derivation function over HKDF [RFC5869]. This will be referred to as KKDF.¶
The choice of KMAC128 or KMAC256 is based on the strength of the output key material. For 256 bits of strength equivalent to HMAC-SHA256, use KMAC256. Per [NIST.SP.800-56Cr1], Section 4.1, Option 3:¶
OKM = KMAC[128|256](salt | info, IKM, L, S)
¶
L is the derived key bit length. Since 4 HIP keys are "drawn" from this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp. 606-637 [ASIACRYPT-2017] each of these derived keys will have the same strength as the Diffie-Hellman shared secret.¶
S is the byte string 01001011 || 01000100 || 01000110, which represents the sequence of characters "K", "D", and "F" in 8-bit ASCII.¶
Salt and info are derived as defined in [RFC7401] or [I-D.ietf-hip-dex]. There are special security considerations for IKM per [RFC7748]. The two HIs MUST be used in constructing IKM as follows:¶
IKM = Diffie-Hellman secret | HI-R | HI-I
¶
These are separately DER encoded.¶
Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use SHAKE, cSHAKE, or KMAC as a PRF.¶
IANA will need to make the following changes to the "Host Identity Protocol (HIP) Parameters" registries:¶
[RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman for key derivation:¶
Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets. Thus using a public key as an identifier and knowledge of a shared secret as proof of ownership (without including the public keys in the key derivation) might lead to subtle vulnerabilities.¶
This applies to [I-D.ietf-hip-dex], but may have broader consequences. Thus the two Host IDs are included with the Diffie-Hellman secret.¶
Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states:¶
"The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and keyed hash function based on KECCAK . It provides variable-length output"¶
That is, the output of KMAC is indistinguishable from a random string, regardless of the length of the output. As such, the output of KMAC can be divided into multiple substrings, each with the strength of the function (KMAC128 or KMAC256) and provided that a long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185.¶
For example KMAC128(K, X, 512, S), where K is at least 128 bits, can produce 4 128 bit keys each with a strength of 128 bits. That is a single sponge operation is replacing perhaps 5 HMAC-SHA256 operations (each 2 SHA256 operations) in HKDF.¶
Quynh Dang of NIST gave considerable guidance on using Keccak and the NIST supporting documents. Joan Deamen of the Keccak team was especially helpful in many aspects of using Keccak, particularly with the KEYMAT section and the strength of the derived keys.¶