idnits 2.17.1 draft-moskowitz-hip-new-crypto-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7401, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7402, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 January 2021) is 1191 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8750' on line 443 -- Possible downref: Non-RFC (?) normative reference: ref. 'Xoodyak' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Updates: 7401, 7402 (if approved) S. Card 5 Intended status: Standards Track A. Wiethuechter 6 Expires: 24 July 2021 AX Enterprize 7 20 January 2021 9 New Cryptographic Algorithms for HIP 10 draft-moskowitz-hip-new-crypto-08 12 Abstract 14 This document provides new cryptographic algorithms to be used with 15 HIP. The Edwards Elliptic Curve and the Keccak sponge functions are 16 the main focus. The HIP parameters and processing instructions 17 impacted by these algorithms are defined. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 24 July 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 55 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. HIP Parameter values for new Cryptographic Functions . . . . 4 57 3.1. Elliptic Curves for Diffie-Hellman . . . . . . . . . . . 4 58 3.1.1. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 5 59 3.2. Edward Digital Signature Algorithm for HITs . . . . . . . 5 60 3.2.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 6 62 3.3. Hashing in HIP . . . . . . . . . . . . . . . . . . . . . 7 63 3.3.1. Hashing with the Sponge Functions . . . . . . . . . . 7 64 3.3.2. RHASH . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.3.3. HIP_MAC and HIP_MAC2 . . . . . . . . . . . . . . . . 8 66 3.4. HIP Cipher . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.4.1. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 9 68 3.5. ESP Transform . . . . . . . . . . . . . . . . . . . . . . 9 69 3.5.1. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 10 70 4. Generating a HIT from an HI . . . . . . . . . . . . . . . . . 10 71 5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . . . 10 72 5.1. The Keccak KEYMAT . . . . . . . . . . . . . . . . . . . . 11 73 5.2. The Xoodyak KEYMAT . . . . . . . . . . . . . . . . . . . 11 74 6. Pseudorandom Function (PRF) . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8.1. Keymat vulnerabilities . . . . . . . . . . . . . . . . . 12 78 8.2. KMAC Security as a KDF . . . . . . . . . . . . . . . . . 13 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 This document adds new cryptographic algorithms for HIPv2 [RFC7401] 88 and [RFC7402]. This includes: 90 * New elliptic curves for ECDH. 92 * The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA) 93 used in Host Identities (HI) and for Base Exchange (BEX) 94 signatures. 96 * Hashes used in Host Identity Tag (HIT) generation, and wherever 97 else hashes are needed. 99 * Keyed hashes used for KEYMAT generation and packet MACing 100 operations. 102 * AEAD and stream ciphers to use in HIP and HIP enabled secure 103 communication protocols. 105 The hashes and encryption are all built on the Keccak [Keccak] sponge 106 function and the Xoodyak [Xoodyak] Lightweight Cryptography 107 candidate. 109 These additions reflect selection of advances in the field of 110 cryptography that would best benefit HIP, particularly in constrained 111 devices and communications. 113 Ed Note: The Xoodyak function calls should be considered the 1st best 114 effort. There are a few areas open for discussion, like which of the 115 3 choices for adding in the nonce to the AEAD mode and when to use 116 counter and Id. Also there may be copy errors from the source 117 specification, nicer function calls, better acronyms. 119 2. Terms and Definitions 121 2.1. Requirements Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2.2. Definitions 131 cSHAKE (The customizable SHAKE function): 132 Extends the SHAKE scheme to allow users to customize their use of 133 the function. 135 DEC function (Doubly-Extendable Cryptographic function): 136 An extendable output function (XOF) that accepts sequences of 137 strings as input and that supports incremental queries 138 efficiently. 140 DECK function (Doubly-Extendable Cryptographic Keyed function): 141 A keyed function that takes a sequence of input strings and 142 returns a pseudorandom string of arbitrary length and that can be 143 computed incrementally. 145 Keccak: 146 The family of all sponge functions with a KECCAK-f permutation as 147 the underlying function and multi-rate padding as the padding 148 rule. 150 KMAC (KECCAK Message Authentication Code): 151 A pseduo random function (PRF) and keyed hash function based on 152 KECCAK. 154 SHAKE (Secure Hash Algorithm KECCAK): 155 A secure hash that allows for an arbitrary output length. 156 SHAKE128 and SHAKE256 are instances of XOFs. SHAKE is shorthand 157 for SHAKE128. 159 PRF (Pseudorandom Function): 160 A function that takes as input a key and that it is hard to 161 distinguish from a random oracle by an adversary that does not 162 know the key. 164 XHASH (Xoodyak Hash Algorithm): 165 A secure hash, based on Xoodyak, that allows for an arbitrary 166 output length. XHASH is an instance of XOF. 168 XMAC (Xoodyak Message Authentication Code): 169 A keyed hash function, based on Xoodyak, that allows for an 170 arbitrary output length. 172 XOF (eXtendable-Output Function): 173 A function on bit strings (also called messages) in which the 174 output can be extended to any desired length. 176 3. HIP Parameter values for new Cryptographic Functions 178 HIP parameters carry information that is necessary for establishing 179 and maintaining a HIP association. For example, the device's public 180 keys as well as the signaling for negotiating ciphers and payload 181 handling are encapsulated in HIP parameters. Additional information, 182 meaningful for end hosts or middleboxes, may also be included in HIP 183 parameters. The specification of the HIP parameters and their 184 mapping to HIP packets and packet types is flexible to allow HIP 185 extensions to define new parameters and new protocol behavior. 187 3.1. Elliptic Curves for Diffie-Hellman 189 Elliptic curves Curve25519 and Curve448 [RFC7748] are specified here 190 for use in the HIP Diffie-Hellman exchange. 192 Curve25519 and Curve448 are already defined in Section 5.2.1 of 193 [hip-dex], using the HIP-DEX CKDF. Here they are defined for using 194 the new KMAC [NIST.SP.800-185] or XMAC [Xoodyak] derived KDF in 195 Section 5. 197 3.1.1. DIFFIE_HELLMAN 199 The DIFFIE_HELLMAN parameter may be included in selected HIP packets 200 based on the DH Group ID selected. The DIFFIE_HELLMAN parameter is 201 defined in Section 5.2.7 of [RFC7401]. 203 The following Elliptic Curves are defined here: 205 Group KDF Value 207 Curve25519 [RFC7748] KMAC 13 208 Curve448 [RFC7748] KMAC 14 210 A new KDF for KEYMAT, Section 6.5 of [RFC7401] using Keccak or 211 Xoodyak is defined in Section 5. 213 3.2. Edward Digital Signature Algorithm for HITs 215 This section is extracted from Appendix D of [drip-rid]. It may 216 later be pulled and only maintained there. 218 Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are 219 specified here for use as Host Identities (HIs) per HIPv2 [RFC7401]. 220 Further the HIT_SUITE_LIST is specified as used in [RFC7343]. 222 3.2.1. HOST_ID 224 The HOST_ID parameter specifies the public key algorithm, and for 225 elliptic curves, a name. The HOST_ID parameter is defined in 226 Section 5.2.19 of [RFC7401]. 228 Algorithm 229 profiles Values 231 EdDSA 13 [RFC8032] 233 For hosts that implement EdDSA as the algorithm, the following ECC 234 curves are available: 236 Algorithm Curve Values 238 EdDSA RESERVED 0 239 EdDSA EdDSA25519 1 [RFC8032] 240 EdDSA EdDSA25519ph 2 [RFC8032] 241 EdDSA EdDSA448 3 [RFC8032] 242 EdDSA EdDSA448ph 4 [RFC8032] 244 3.2.2. HIT_SUITE_LIST 246 The HIT_SUITE_LIST parameter contains a list of the supported HIT 247 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 248 Initiator can determine which source HIT Suite IDs are supported by 249 the Responder. The HIT_SUITE_LIST parameter is defined in 250 Section 5.2.10 of [RFC7401]. 252 The following HIT Suite ID is defined, and the relationship between 253 the four-bit ID value used in the OGA ID field and the eight-bit 254 encoding within the HIT_SUITE_LIST ID field is clarified: 256 HIT Suite Four-bit ID Eight-bit encoding 257 RESERVED 0 0x00 258 EdDSA/cSHAKE128 5 0x50 259 EdDSA/XHASH 6 0x60 261 The following table provides more detail on the above HIT Suite 262 combinations. The input for each generation algorithm is the 263 encoding of the HI as defined herein. 265 The output of cSHAKE128 and XHASH are variable per the needs of a 266 specific ORCHID construction. It is at most 96 bits long and is 267 directly used in the ORCHID (without truncation). 269 +=======+===========+=========+===========+====================+ 270 | Index | Hash | HMAC | Signature | Description | 271 | | function | | algorithm | | 272 | | | | family | | 273 +=======+===========+=========+===========+====================+ 274 | 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | 275 | | | | | with cSHAKE128, | 276 | | | | | output is variable | 277 +-------+-----------+---------+-----------+--------------------+ 278 | 6 | XHASH | XMAC | EdDSA | EdDSA HI hashed | 279 | | | | | with XMAC, output | 280 | | | | | is variable | 281 +-------+-----------+---------+-----------+--------------------+ 283 Table 1: HIT Suites 285 3.3. Hashing in HIP 287 Hashing is used in HIP for HIT generation and keyed hashes of HIP 288 payloads. The hash algorithm used is designated as part of the 289 HIT_SUITE_ID. The keyed hash function is the "common" such function 290 used in conjunction with the HIT hash. 292 3.3.1. Hashing with the Sponge Functions 294 The XOF function in SHA-3, Secure Hash Algorithm Keccak (SHAKE) 295 [NIST.FIPS.202] and the more recent Xoodyak [Xoodyak] algorithm are 296 called sponge functions. Sponge functions have a special feature in 297 which an arbitrary number of output bits are "squeezed" out of the 298 hashing state. This is a significant use change in that hash 299 truncation or multiple "runs" for enough bits are not used with 300 sponge functions. 302 3.3.1.1. cSHAKE, the customizable SHAKE function 304 The customizable SHAKE function (cSHAKE) in [NIST.SP.800-185] will be 305 used as a HIP hash. As a Keccak XOF, it does not use the truncation 306 operation that other hashes need. The invocation of cSHAKE specifies 307 the desired number of bits in the hash output. Further, cSHAKE has a 308 parameter 'S' as a customization bit string. This parameter will be 309 used for including hash specific customization like the ORCHID 310 Context Identifier in a standard fashion. 312 Hardware implementation of Keccak in VHDL is available from Keccak 313 [Keccak] team website. 315 3.3.1.2. The Xoodyak Hash 317 The Xoodyak [Xoodyak] sponge function is a candidate in the NIST 318 Lightweight Cryptography (LWC) Standardization process. Xoodyak has 319 been selected here for use in HIP from the LWC 2nd round candidates 320 as it was developed by the Keccak team, making it more directly in 321 line with Keccak. 323 Xoodyak has a hash function mode. More specifically, this hash mode 324 is an extendable output function (XOF). 326 As the Xoodyak specification [Xoodyak_Spec] does not provide high- 327 level function calls, rather a set of primitives to use to construct 328 the various modes, the appropriate primitive calls will be detailed 329 below. Xoodyak as a hash will be called here "XHASH". 331 To get a n-byte digest of some input x: XHASH(n, x), use the 332 following set of Xoodyak primitives: 334 Cyclist(ε,ε,ε) 335 Absorb(x) 336 Squeeze(n) 338 Xoodyak can also naturally implement a DEC function and process a 339 sequence of strings. Here the output depends on the sequence as such 340 and not just on the concatenation of the different strings. To 341 compute a n-byte digest, XHASH(n, {x1, x2, x3}) the Xoodyak 342 primitives are: 344 Cyclist(ε,ε,ε) 345 Absorb(x3) 346 Absorb(x2) 347 Absorb(x1) 348 Squeeze(n) 350 The equivalent of the parameter 'S' in cSHAKE above can be 351 implemented as the last Absorb primitive call in the DEC function. 352 That is: XHASH(L, {S, N, X}) is equivalent to cSHAKE(X, L, N, S). 354 3.3.2. RHASH 356 RHASH is the general term used throughout [RFC7401] to refer to the 357 hash used for a specific HIT suite. For this addendum SHAKE128 for 358 Keccak or XHASH for Xoodyak is used, even for HITs of EdDSA448. 360 Unless otherwise specified, L of SHAKE128 or n of XHASH is 256, 361 resulting in a similar output to SHA256. Any truncation used for, 362 older, fixed output hashes is still used. This is to simplify code 363 integration. One exception to this is in Section 4. 365 3.3.3. HIP_MAC and HIP_MAC2 367 The HIP_MAC and HIP_MAC2 parameters in [RFC7401] use HMAC [RFC2104]. 368 This performs two hashes on a string with a key for a keyed hash the 369 length of the underlying hash. 371 For both HIP_MAC and HIP_MAC2 use, the parameter S below is NULL. It 372 is included for complete function definition. 374 3.3.3.1. The Keccak Keyed MAC 376 Here, KMAC from NIST SP 800-185 [NIST.SP.800-185] is used. This is a 377 single pass using the underlying cSHAKE function. The function call 378 is: 380 KMAC128(Key, Input String, 256, S) 382 3.3.3.2. The Xoodyak Keyed MAC 384 Here, XMAC is defined as the keyed hash function based on Xoodyak. 385 It is built with primitives from [Xoodyak_Spec] as a DEC function. 387 To get a n-byte keyed MAC of some input x: XMAC(Key, n, {x, S}). 388 Where n=256, use the following set of Xoodyak primitives: 390 Cyclist(Key,Id,ε) 391 Absorb(S) Only if S is non-null 392 Absorb(Input String) 393 Squeeze(256) 395 Id is "HIP_MAC" and "HIP_MAC2" respectively. Note since S is null in 396 this XMAC usage, the first Absorb call is not performed. 398 3.4. HIP Cipher 400 HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of 401 [RFC7401]. The Xoodyak cipher, [Xoodyak], is recommended. Here 402 Xoodyak is used in encrypt only mode. 404 3.4.1. HIP_CIPHER 406 The HIP_CIPHER parameter value for Xoodyak is: 408 hip_cipher 409 Suite ID Value 411 Xoodyak 6 (Xoodyak) 413 The Xoodyak primitive calls for encrypt only are: 415 Cyclist(Key,Id,ε) 416 Absorb(IV) 417 C ← Encrypt(P) 419 Where Id is HIP parameter name (e.g. "ENCRYPTED"). 420 IV is from the encrypted HIP parameter. 421 P is the plain-text per the specific HIP encrypted parameter. 422 C is the ciphertext. 424 3.5. ESP Transform 426 The ESP_TRANSFORM parameter is used during ESP SA establishment, 427 Section 5.1.2 of [RFC7402]. The Xoodyak cipher, [Xoodyak], is 428 recommended. Here Xoodyak is used in AEAD mode. 430 Further, it is recommended to use Implicit IV ESP [RFC8750] to match 431 its lightweight over-the-air format with the lightweight Xoodyak AEAD 432 cipher. 434 3.5.1. ESP_TRANSFORM 436 The ESP_TRANSFORM Suite IDs for Xoodyak are: 438 hip_cipher 439 Suite ID Value 441 Xoodyak-96 16 (Xoodyak) 442 Xoodyak 17 (Xoodyak) 443 Implicit IV 18 [8750] 445 The Implicit IV Suite ID is unique in that it is an AND condition 446 with ciphers that can use it. That is AES-GCM and Xoodyak can both 447 use 'regular' ESP [RFC4303] or [RFC8750]. 449 The Xoodyak primitive calls for AEAD encrypt are: 451 Cyclist(Key,Id,ε) 452 Absorb(IV) 453 Absorb(A) 454 C ← Encrypt(P) 455 T ← Squeeze(t) 457 Where Id is "ESP_TRANSFORM". The IV is either a 32 bit ESP IV per 458 [RFC4303] or the ESP Seq Number per[RFC8750]. P is the plain-text 459 and A is the associated data. t is either 96 or 128. T is the ESP 460 ICV of length t. 462 4. Generating a HIT from an HI 464 The EdDSA/cSHAKE based HITs require a new ORCHID generation method 465 than that described in section 3.2 of [RFC7401]. The XOF 466 functionality of cSHAKE produces an output of L bits. This replaces 467 the Encode_96 function in the ORCHID generation. 469 For identities that are EdDSA public keys, ORCHIDs will be generated 470 per the process defined in Appendix C.2.1 of [drip-rid]. 472 5. HIP KEYMAT Generation 474 For either the Keccak or Xoodyak KEYMAT generation, the inputs are 475 consistent. The only practical difference is that SHAKE allows for 476 128 or 256 bits of strength, whereas Xoodyak only provides 128 bits. 478 L is the derived key bit length. Since 4 HIP keys are "drawn" from 479 this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp. 480 606-637 [ASIACRYPT-2017] each of these derived keys will have the 481 same strength as the Diffie-Hellman shared secret. 483 S is the byte string 01001011 || 01000100 || 01000110, which 484 represents the sequence of characters "K", "D", and "F" in 8-bit 485 ASCII. 487 Salt and info are derived as defined in sec 6.5 of [RFC7401]. There 488 are special security considerations for IKM per [RFC7748]. 490 5.1. The Keccak KEYMAT 492 The KMAC function provides a new, more efficient, key derivation 493 function over HKDF [RFC5869]. KMAC as a KDF is defined below. 495 The two HIs MUST be used in constructing IKM as follows: 497 IKM = Diffie-Hellman secret | sort(HI-I | HI-R) 499 The two HIs are separately DER encoded per [RFC7401] 501 The choice of KMAC128 or KMAC256 is based on the strength of the 502 output key material. For 256 bits of strength equivalent to HMAC- 503 SHA256, use KMAC256. Per [NIST.SP.800-56Cr1], Section 4.1, Option 3: 505 OKM = KMAC[128|256](salt | info, IKM, L, S) 507 5.2. The Xoodyak KEYMAT 509 Here, XMAC from Section 3.3.3.2 is used. The DEC function XMAC("", 510 L, {DH, sort(HI-I, HI-R), info, Salt, S}) primitives are: 512 Cyclist(ε, ε, ε) 513 Absorb(S) 514 Absorb(salt) 515 Absorb(info) 516 Absorb(max(HI-I , HI-R)) 517 Absorb(min(HI-I , HI-R)) 518 Absorb(Diffie-Hellman secret) 519 Squeeze(L) 521 Ed Note: Need to check that all above are well defined bytestrings 522 per 7401. I think they are. 524 6. Pseudorandom Function (PRF) 526 Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use 527 SHAKE, cSHAKE, or KMAC as a PRF. 529 For Xoodyak, XMAC from Section 3.3.3.2 is used in the same manner as 530 KMAC above. 532 7. IANA Considerations 534 IANA will need to make the following changes to the "Host Identity 535 Protocol (HIP) Parameters" registries: 537 Diffie Hellman: 538 This document defines the new Curve25519 and Curve448 for the 539 Diffie-Hellman exchange (see Section 3.1.1). 541 Host ID: 542 This document defines the new EdDSA Host ID (see Section 3.2.1). 544 HIT Suite ID: 545 This document defines the new HIT Suite of EdDSA/cSHAKE and EdDSA/ 546 XHASH (see Section 3.2.2). 548 HIP Cipher: 549 This document defines the new Xoodyak cipher for HIP encrypted 550 parameters (see Section 3.4.1). 552 ESP Transform: 553 This document defines the new Xoodyak cipher and use of [RFC8750] 554 for the ESP Transform parameter (see Section 3.5). 556 8. Security Considerations 558 8.1. Keymat vulnerabilities 560 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 561 for key derivation: 563 Designers using these curves should be aware that for each public 564 key, there are several publicly computable public keys that are 565 equivalent to it, i.e., they produce the same shared secrets. Thus 566 using a public key as an identifier and knowledge of a shared secret 567 as proof of ownership (without including the public keys in the key 568 derivation) might lead to subtle vulnerabilities. 570 Thus the two Host IDs are included with the Diffie-Hellman secret in 571 the KEYMAT generation. 573 8.2. KMAC Security as a KDF 575 Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states: 577 "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and 578 keyed hash function based on KECCAK . It provides variable-length 579 output" 581 That is, the output of KMAC is indistinguishable from a random 582 string, regardless of the length of the output. As such, the output 583 of KMAC can be divided into multiple substrings, each with the 584 strength of the function (KMAC128 or KMAC256) and provided that a 585 long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. 587 For example KMAC128(K, X, 512, S), where K is at least 128 bits, can 588 produce 4 128 bit keys each with a strength of 128 bits. That is a 589 single sponge operation is replacing perhaps 5 HMAC-SHA256 operations 590 (each 2 SHA256 operations) in HKDF. 592 9. Acknowledgments 594 Quynh Dang of NIST gave considerable guidance on using Keccak and the 595 NIST supporting documents. Joan Deamen of the Keccak team was 596 especially helpful in many aspects of using Keccak and Xoodyak, 597 particularly with the KEYMAT section and the strength of the derived 598 keys. 600 NIST is entering round 3 (final) of its Lightweight Crypto 601 Competition with anticipated selection the end of 2021 or early in 602 2022. Events in this process will impact selections in this 603 document. 605 10. References 607 10.1. Normative References 609 [NIST.FIPS.202] 610 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 611 Extendable-Output Functions", National Institute of 612 Standards and Technology report, 613 DOI 10.6028/nist.fips.202, July 2015, 614 . 616 [NIST.SP.800-185] 617 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 618 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 619 National Institute of Standards and Technology report, 620 DOI 10.6028/nist.sp.800-185, December 2016, 621 . 623 [NIST.SP.800-56Cr1] 624 Barker, E., Chen, L., and R. Davis, "Recommendation for 625 key-derivation methods in key-establishment schemes", 626 National Institute of Standards and Technology report, 627 DOI 10.6028/nist.sp.800-56cr1, April 2018, 628 . 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 636 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 637 RFC 7401, DOI 10.17487/RFC7401, April 2015, 638 . 640 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 641 Encapsulating Security Payload (ESP) Transport Format with 642 the Host Identity Protocol (HIP)", RFC 7402, 643 DOI 10.17487/RFC7402, April 2015, 644 . 646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 648 May 2017, . 650 [Xoodyak] Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., and 651 R. Van Keer, "The Xoodyak Cipher and Hash", 652 . 654 [Xoodyak_Spec] 655 Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., and 656 R. Van Keer, "Xoodoo cookbook", 2019, 657 . 659 10.2. Informative References 661 [ASIACRYPT-2017] 662 Daemen, J., Mennink, B., and G. Van Assche, "Full-State 663 Keyed Duplex with Built-In Multi-user Support", 664 DOI 10.1007/978-3-319-70697-9_21, Advances in Cryptology - 665 ASIACRYPT 2017 pp. 606-637, 2017, 666 . 668 [drip-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 669 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 670 ietf-drip-rid-06, 31 December 2020, 671 . 673 [hip-dex] Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 674 (DEX)", Work in Progress, Internet-Draft, draft-ietf-hip- 675 dex-22, 14 December 2020, 676 . 678 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 679 R. Van Keer, "The Keccak Function", 680 . 682 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 683 Hashing for Message Authentication", RFC 2104, 684 DOI 10.17487/RFC2104, February 1997, 685 . 687 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 688 RFC 4303, DOI 10.17487/RFC4303, December 2005, 689 . 691 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 692 Key Derivation Function (HKDF)", RFC 5869, 693 DOI 10.17487/RFC5869, May 2010, 694 . 696 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 697 Routable Cryptographic Hash Identifiers Version 2 698 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 699 2014, . 701 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 702 for Security", RFC 7748, DOI 10.17487/RFC7748, January 703 2016, . 705 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 706 Signature Algorithm (EdDSA)", RFC 8032, 707 DOI 10.17487/RFC8032, January 2017, 708 . 710 [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit 711 Initialization Vector (IV) for Counter-Based Ciphers in 712 Encapsulating Security Payload (ESP)", RFC 8750, 713 DOI 10.17487/RFC8750, March 2020, 714 . 716 Authors' Addresses 718 Robert Moskowitz 719 HTT Consulting 720 Oak Park, MI 48237 721 United States of America 723 Email: rgm@labs.htt-consult.com 725 Stuart W. Card 726 AX Enterprize 727 4947 Commercial Drive 728 Yorkville, NY 13495 729 United States of America 731 Email: stu.card@axenterprize.com 733 Adam Wiethuechter 734 AX Enterprize 735 4947 Commercial Drive 736 Yorkville, NY 13495 737 United States of America 739 Email: adam.wiethuechter@axenterprize.com