HIP R. Moskowitz Internet-Draft HTT Consulting Updates: 7401, 7402 (if approved) S. Card Intended status: Standards Track A. Wiethuechter Expires: 4 July 2021 AX Enterprize 31 December 2020 New Cryptographic Algorithms for HIP draft-moskowitz-hip-new-crypto-07 Abstract 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. Status of This Memo 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 4 July 2021. Copyright Notice 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. Moskowitz, et al. Expires 4 July 2021 [Page 1] Internet-Draft HIP New Crypto December 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. HIP Parameter values for new Crytpo . . . . . . . . . . . . . 4 3.1. Elliptic Curves for Diffie-Hellman . . . . . . . . . . . 4 3.1.1. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 5 3.2. Edward Digital Signature Algorithm for HITs . . . . . . . 5 3.2.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 6 3.3. Hashing with Sponge Functions . . . . . . . . . . . . . . 6 3.3.1. Hashing with the Sponge Functions . . . . . . . . . . 7 3.3.2. RHASH . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.3. HIP_MAC and HIP_MAC2 . . . . . . . . . . . . . . . . 8 3.4. HIP Cipher . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 9 3.5. ESP Transform . . . . . . . . . . . . . . . . . . . . . . 9 3.5.1. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 10 4. Generating a HIT from an HI . . . . . . . . . . . . . . . . . 10 5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . . . 10 5.1. The Keccak KEYMAT . . . . . . . . . . . . . . . . . . . . 11 5.2. The Xoodyak Keyed MAC . . . . . . . . . . . . . . . . . . 11 6. Pseudorandom Function (PRF) . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Keymat vulnerabilities . . . . . . . . . . . . . . . . . 12 8.2. KMAC Security as a KDF . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document adds new cryptographic algorithms for HIPv2 [RFC7401] and [RFC7402]. This includes: * New elliptic curves for ECDH. * The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA) used in Host Identities (HI) and for Base Exchange (BEX) signatures. * Hashes used in Host Identity Tag (HIT) generation, and wherever else hashes are needed. Moskowitz, et al. Expires 4 July 2021 [Page 2] Internet-Draft HIP New Crypto December 2020 * Keyed hashes used for KEYMAT generation and packet MACing operations. * AEAD and stream ciphers to use in HIP and HIP enabled secure communication protocols. The hashes and encryption are all built on the Keccak [Keccak] sponge function and the Xoodyak [Xoodyak] Lightweight Cryptography candidate. These additions reflect selection of advances in the field of cryptography that would best benefit HIP, particularly in constrained devices and communications. Ed Note: The Xoodyak function calls should be considered the 1st best effort. There are a few areas open for discussion, like which of the 3 choices for adding in the nonce to the AEAD mode and when to use counter and Id. Also there may be copy errors from the source specification, nicer function calls, better acroynms. 2. Terms and Definitions 2.1. Requirements Terminology 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. 2.2. Definitions Keccak (KECCAK Message Authentication Code): The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule. KMAC (KECCAK Message Authentication Code): A PRF and keyed hash function based on KECCAK. cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme to allow users to customize their use of the function. Dec function (Doubly-Extendable Cryptographic function): An extendable output function (XOF) that accepts sequences of strings as input and that supports incremental queries efficiently. Moskowitz, et al. Expires 4 July 2021 [Page 3] Internet-Draft HIP New Crypto December 2020 Deck function (Doubly-Extendable Cryptographic Keyed function): A keyed function that takes a sequence of input strings and returns a pseudorandom string of arbitrary length and that can be computed incrementally. SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows for an arbitrary output length. PRF (Pseudorandom Function): A function that can be used to generate output from a random seed such that the output is computationally indistinguishable from truly random output. XHASH (Xoodyak Hash Algorithm): A secure hash, based on Xoodyak, that allows for an arbitrary output length. XKHASH (Xoodyak keyed Hash Algorithm): A keyed secure hash, based on Xoodyak, that allows for an arbitrary output length. XOF (eXtendable-Output Function): A function on bit strings (also called messages) in which the output can be extended to any desired length. 3. HIP Parameter values for new Crytpo 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. 3.1. Elliptic Curves for Diffie-Hellman 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 [hip-dex], using the HIP-DEX CKDF. Here they are defined for using the new KMAC [NIST.SP.800-185] or XMAC [Xoodyak] derived KDF in Section 5. Moskowitz, et al. Expires 4 July 2021 [Page 4] Internet-Draft HIP New Crypto December 2020 3.1.1. DIFFIE_HELLMAN 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] using Keccak or Xoodyak is defined in Section 5. 3.2. Edward Digital Signature Algorithm for HITs This section is extracted from Appendix D of [drip-rid]. It may later be pulled and only maintained there. Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are specified here for use as Host Identities (HIs) per HIPv2 [RFC7401]. Further the HIT_SUITE_LIST is specified as used in [RFC7343]. 3.2.1. HOST_ID 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] 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] Moskowitz, et al. Expires 4 July 2021 [Page 5] Internet-Draft HIP New Crypto December 2020 3.2.2. HIT_SUITE_LIST 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/cSHAKE128 5 0x50 EdDSA/XMAC 6 0x60 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 herein. The output of cSHAKE128 and XMAC (Xoodyak) are variable per the needs of a specific ORCHID construction. It is at most 96 bits long and is directly used in the ORCHID (without truncation). +=======+===========+=========+===========+====================+ | Index | Hash | HMAC | Signature | Description | | | function | | algorithm | | | | | | family | | +=======+===========+=========+===========+====================+ | 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | | | | | | with cSHAKE128, | | | | | | output is variable | +-------+-----------+---------+-----------+--------------------+ | 6 | XMAC | XKMAC | EdDSA | EdDSA HI hashed | | | | | | with XMAC, output | | | | | | is variable | +-------+-----------+---------+-----------+--------------------+ Table 1: HIT Suites 3.3. Hashing with Sponge Functions The Sponge Function is ideal for hashing and here is used as an alternative to all the hashing functions in HIP. The analogy to a sponge for this function 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. Moskowitz, et al. Expires 4 July 2021 [Page 6] Internet-Draft HIP New Crypto December 2020 3.3.1. Hashing with the Sponge Functions Keccak, and the more recent Xoodyak algorithms are called sponge functions. 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. 3.3.1.1. The Keccak Hash The Keccak [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]. Hardware implementation of Keccak in VHDL is available from Keccak [Keccak]. The cSHAKE XOF hash function in [NIST.SP.800-185] will be used. It is a variable output length hash function. As such it does not use the truncation operation that other hashes need. The invocation of cSHAKE specifies the desired number of bits in the hash output. Further, cSHAKE has a parameter 'S' as a customization bit string. This parameter will be used for including hash specific customization like the ORCHID Context Identifier in a standard fashion. 3.3.1.2. The Xoodyak Hash The Xoodyak [Xoodyak] sponge function is a candidate in the NIST Lightweight Cryptography (LWC) Standardization process. LWC originally targeted the need of a lightweight AEAD cipher, but fortunately many of the candidates, including Xoodyak, have included hashing, keyed hashing, and encrypt only modes. Xoodyak has been selected here from the LWC 2nd round candidates as it was developed by the Keccak team, making it more directly in line with Keccak. Xoodyak can be used as a hash function. More generally, it can serve as an extendable output function (XOF), the generalization of a hash function with arbitrary output length. As the Koodyak specification does not provide simple function calls, rather a set of calls to use to construct the various modes, the appropriate calls will be detailed below. Xoodyak as a hash will be called "XHASH". To get a n-byte digest of some input x {XHASH(n, x)}, one can use Xoodyak as follows: Cyclist(ε,ε,ε) Absorb(x) Squeeze(n) Moskowitz, et al. Expires 4 July 2021 [Page 7] Internet-Draft HIP New Crypto December 2020 Xoodyak can also naturally implement a Dec function and process a sequence of strings. Here the output depends on the sequence as such and not just on the concatenation of the different strings. To compute a n-byte digest over the sequence x3 ◦ x2 ◦ x1 {XHASH(n, x3,x2,x1)}, one does: Cyclist(ε,ε,ε) Absorb(x1) Absorb(x2) Absorb(x3) Squeeze(n) The equivalent of the parameter 'S' in cSHAKE above can be implemented as the last Absorb call in the Dec function. 3.3.2. RHASH RHASH is the general term used throughout [RFC7401] to refer to the hash used for a specific HIT suite. For this addendum SHAKE128 for Keccak or XHASH for Xoodyak is used, even for HIs of EdDSA448. Unless otherwise specified, L of SHAKE128 or n of XHASH 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. 3.3.3. HIP_MAC and HIP_MAC2 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. 3.3.3.1. The Keccak Keyed MAC 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, "") 3.3.3.2. The Xoodyak Keyed MAC Here, XKMAC from [Xoodyak] is used. The function calls are: Moskowitz, et al. Expires 4 July 2021 [Page 8] Internet-Draft HIP New Crypto December 2020 Cyclist(Key,Id,ε) Absorb(Input String) Squeeze(256) Where Id is "HIP_MAC" and "HIP_MAC2" respectively. Ed note: Id MAY end up being NULL. Furture study on role of Id in Cyclist is needed. 3.4. HIP Cipher HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of [RFC7401]. The Keccak Xoodyak cipher, [Xoodyak], is recommended. Here Xoodyak is used in encrypt only mode. 3.4.1. HIP_CIPHER The HIP_CIPHER parameter values for Xoodyak are: hip_cipher Suite ID Value Xoodyak 6 (Xoodyak) The Xoodyak function calls are: Cyclist(Key,Id,ε) Absorb(IV) C ← Encrypt(P) return (C) Where Id is HIP parameter name. P is the plain-text per the specific HIP encrypted parameter. Ed note: Id MAY end up being NULL. Furture study on role of Id in Cyclist is needed. 3.5. ESP Transform The ESP_TRANSFORM parameter is used during ESP SA establishment, Section 5.1.2 of [RFC7402]. The Keccak Xoodyak cipher, [Xoodyak], is recommended. Here Xoodyak is used in AEAD mode. Further, it is recommended to use Implicit IV ESP [RFC8750] to match its lightweight over-the-air format with the lightweight Xoodyak cipher. Moskowitz, et al. Expires 4 July 2021 [Page 9] Internet-Draft HIP New Crypto December 2020 3.5.1. ESP_TRANSFORM The ESP_TRANSFORM Suite IDs for Xoodyak are: hip_cipher Suite ID Value Xoodyak-96 16 (Xoodyak) Xoodyak 17 (Xoodyak) Implicit IV 18 [8750] The Implicit IV Suite ID is unique in that it is an AND condition with ciphers that can use it. That is AES-GCM and Xoodyak can both use 'regular' ESP [RFC4303] or [RFC8750]. The Xoodyak function calls are: Cyclist(Key,Id,ε) Absorb(IV) Absorb(A) C ← Encrypt(P) T ← Squeeze(t) return (C,T) Where Id is "ESP_TRANSFORM. The IV is either a 32 bit ESP IV per [RFC4303] or the ESP Seq Number per[RFC8750]. P is the plain-text and A is the associated data. t is either 96 or 128. T is the ESP ICV of length t. Ed note: Id MAY end up being NULL. Furture study on role of Id in Cyclist is needed. 4. Generating a HIT from an HI The EdDSA/cSHAKE based HITs require a new ORCHID generation method than that 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 Appendix C.2.1 of [drip-rid]. 5. HIP KEYMAT Generation For either the Keccak or Xoodyak KEYMAT generation, the inputs are consistant. The only practical difference is that Keccak allows for 256 bits of strength, whereas Xoodyak only provides 128 bits. Moskowitz, et al. Expires 4 July 2021 [Page 10] Internet-Draft HIP New Crypto December 2020 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 sec 6.5 of [RFC7401]. There are special security considerations for IKM per [RFC7748]. 5.1. The Keccak KEYMAT The KMAC function provides a new, more efficient, key derivation function over HKDF [RFC5869]. This will be referred to as KKDF. The two HIs MUST be used in constructing IKM as follows: IKM = Diffie-Hellman secret | sort(HI-I | HI-R) These are separately DER encoded. 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) 5.2. The Xoodyak Keyed MAC Here, XKMAC from [Xoodyak] is used. The function calls are: Cyclist(ε, ε, ε) Absorb(S) Absorb(salt) Absorb(info) Absorb(min(HI-I , HI-R)) Absorb(max(HI-I , HI-R)) Absorb(Diffie-Hellman secret) Squeeze(L) 6. Pseudorandom Function (PRF) Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use SHAKE, cSHAKE, or KMAC as a PRF. Moskowitz, et al. Expires 4 July 2021 [Page 11] Internet-Draft HIP New Crypto December 2020 A PRF is currently not in the Xoodyak specification. This may be added at a later point. 7. IANA Considerations IANA will need to make the following changes to the "Host Identity Protocol (HIP) Parameters" registries: Diffie Hellman: This document defines the new Curve25519 and Curve448 for the Diffie-Hellman exchange (see Section 3.1.1). Host ID: This document defines the new EdDSA Host ID (see Section 3.2.1). HIT Suite ID: This document defines the new HIT Suite of EdDSA/cSHAKE and EdDSA/ XMAC (see Section 3.2.2). HIP Cipher: This document defines the new Xoodyak cipher for HIP encrypted parameters (see Section 3.4.1). ESP Transform: This document defines the new Xoodyak cipher and use of [RFC8750] for the ESP Transform parameter (see Section 3.5). 8. Security Considerations 8.1. Keymat vulnerabilities [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. Thus the two Host IDs are included with the Diffie-Hellman secret in the KEYMAT generation. 8.2. KMAC Security as a KDF Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states: Moskowitz, et al. Expires 4 July 2021 [Page 12] Internet-Draft HIP New Crypto December 2020 "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. 9. Acknowledgments 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. NIST is entering round 3 (final) of its Lightweight Crypto Competition with anticipated selection the end of 2021 or early in 2022. Events in this process will impact selections in this document. 10. References 10.1. Normative References [NIST.FIPS.202] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", National Institute of Standards and Technology report, DOI 10.6028/nist.fips.202, July 2015, . [NIST.SP.800-185] Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived functions: cSHAKE, KMAC, TupleHash and ParallelHash", National Institute of Standards and Technology report, DOI 10.6028/nist.sp.800-185, December 2016, . [NIST.SP.800-56Cr1] Barker, E., Chen, L., and R. Davis, "Recommendation for key-derivation methods in key-establishment schemes", Moskowitz, et al. Expires 4 July 2021 [Page 13] Internet-Draft HIP New Crypto December 2020 National Institute of Standards and Technology report, DOI 10.6028/nist.sp.800-56cr1, April 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [Xoodyak] Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., and R. Van Keer, "The Xoodyak Cipher and Hash", . 10.2. Informative References [ASIACRYPT-2017] Daemen, J., Mennink, B., and G. Van Assche, "Full-State Keyed Duplex with Built-In Multi-user Support", DOI 10.1007/978-3-319-70697-9_21, Advances in Cryptology - ASIACRYPT 2017 pp. 606-637, 2017, . [drip-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, draft- ietf-drip-rid-05, 22 December 2020, . [hip-dex] Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange (DEX)", Work in Progress, Internet-Draft, draft-ietf-hip- dex-22, 14 December 2020, . Moskowitz, et al. Expires 4 July 2021 [Page 14] Internet-Draft HIP New Crypto December 2020 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and R. Van Keer, "The Keccak Function", . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", RFC 8750, DOI 10.17487/RFC8750, March 2020, . Authors' Addresses Robert Moskowitz HTT Consulting Oak Park, MI 48237 United States of America Email: rgm@labs.htt-consult.com Moskowitz, et al. Expires 4 July 2021 [Page 15] Internet-Draft HIP New Crypto December 2020 Stuart W. Card AX Enterprize 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: stu.card@axenterprize.com Adam Wiethuechter AX Enterprize 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Moskowitz, et al. Expires 4 July 2021 [Page 16]