idnits 2.17.1 draft-schaad-cose-more-algs-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5649], [I-D.ietf-cose-RFC8152bis-struct]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 May 2020) is 1435 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-08 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-07 == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Informational 22 May 2020 5 Expires: 23 November 2020 7 CBOR Object Signing and Encryption (COSE): Additional Algorithms 8 draft-schaad-cose-more-algs-01 10 Abstract 12 The CBOR Object Signing and Encryption (COSE) syntax 13 [I-D.ietf-cose-rfc8152bis-struct] allows for adding additional 14 algorithms to the registries. This document adds one additional key 15 wrap algorithm to the registry using the AES Wrap with Padding 16 Algorithm [RFC5649]. This document adds Keccak Message 17 Authentication Code (KMAC) algorithms as well as using KMAC as a Key 18 Derivation Function (KDF). 20 Contributing to this document 22 This note is to be removed before publishing as an RFC. 24 The source for this draft is being maintained in GitHub. Suggested 25 changes should be submitted as pull requests at https://github.com/ 26 cose-wg/X509 Editorial changes can be managed in GitHub, but any 27 substantial issues need to be discussed on the COSE mailing list. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 23 November 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 64 1.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 3 66 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 3 67 3.1. Keccak Message Authentication Code (KMAC) . . . . . . . . 4 68 4. AES Key Wrap with Padding . . . . . . . . . . . . . . . . . . 5 69 4.1. Security Considerations for AES-KW with Padding . . . . . 6 70 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 6 71 5.1. KMAC KDF . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Content Key Distribution Methods . . . . . . . . . . . . . . 8 73 6.1. Direct Key with KDF . . . . . . . . . . . . . . . . . . . 8 74 6.1.1. Security Considerations . . . . . . . . . . . . . . . 9 75 6.2. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.3. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Changes to the Algorithm Table . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The CBOR Object Signing and Encryption (COSE) syntax 87 [I-D.ietf-cose-rfc8152bis-struct] is defined to have an object based 88 set of security primitives using CBOR [I-D.ietf-cbor-7049bis] for use 89 in constrained environments. COSE has algorithm agility so that 90 documents like this one can register algorithms which are needed. 92 In this document we add: 94 * The AES Wrap with Padding algorithm. 96 * Keccak Message Authentication Code (KMAC) algorithms. 98 * KMAC as a Key Derivation Function (KDF) for direct and key 99 agreement algorithms. 101 1.1. Requirements Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 1.2. Open Issues 111 This section is to be removed before publishing as an RFC. 113 * Should 192-bit AES Key Wrap be omitted or just given a large 114 identifier? (John) 116 * Add the cSHAKE algorithms to the list? (Bob) 118 * RESOLVED: A desire has been expressed to all for the use of AES 119 Key Wrap with Padding as a content encryption algorithm. This is 120 not compatible with the requirement that all content encryption 121 algorithms "support authentication of both the content and 122 additional data." AES Key Wrap is an AE not an AEAD algorithm. 123 (Jim) Response: Russ said it was ok just to be a key wrap 124 algorithm. 126 2. Signature Algorithms 128 This section is to be removed before publishing as an RFC. 130 This document defines no new signature algorithms. 132 3. Message Authentication Code (MAC) Algorithms 133 3.1. Keccak Message Authentication Code (KMAC) 135 As part of the definition of the SHA-3 algorithms, NIST also defined 136 a number of algorithms that are based on SHA-3 [NIST-800-185]. The 137 Keccak Message Authentication Code (KMAC) is defined in that 138 document. KMAC has a big performance advantage when compared to 139 Hash-Based Message Authentication Code (HMAC) [RFC2104] [RFC4231] as 140 it was designed to deal with the length extension attacks that forced 141 the two pass structure of HMAC. 143 KMAC is parameterized with four inputs: 145 * K - the key used for authentication 147 * X - the byte string to be authenticated 149 * L - the size of the authentication value in bits. This MUST be at 150 least 64 and SHOULD be at least 128. 152 * S - customization string which shall be a zero length byte string. 154 The algorithm identifier does not encode the length of the 155 authentication tag, unlike the MAC algorithms defined in 156 [I-D.ietf-cose-rfc8152bis-algs]. This is because shortened tags for 157 those algorithms are generated by truncating a longer output. 158 However, KMAC takes the resultant output length as one of the 159 parameters and will generate different outputs depending on the 160 length. The length of the MAC code is therefore chosen by the 161 sender, and the length is inferred from the actual tag by the 162 validator. If an attacker attempts to gain an advantage by 163 shortening the tag, KMAC is not going to generate the correct tag. 165 +----------+-------+------------------------+-------------+ 166 | Name | Value | Description | Recommended | 167 +==========+=======+========================+=============+ 168 | KMAC 128 | TBD4 | KMAC w/ SHA-3 128-bits | Yes | 169 +----------+-------+------------------------+-------------+ 170 | KMAC 256 | TBD5 | KMAC w/ SHA-3 256-bits | Yes | 171 +----------+-------+------------------------+-------------+ 173 Table 1 175 When using a COSE key for this algorithm, the following checks are 176 made: 178 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 180 * If the 'alg' field is present, it MUST match the KMAC algorithm 181 being used. 183 * If the 'key_ops' field is present, it MUST include 'MAC create' 184 when creating an KMAC authentication tag. 186 * If the 'key_ops' field is present, it MUST include 'MAC verify' 187 when verifying an KMAC authentication tag. 189 Implementations creating and validating MAC values MUST validate that 190 the key type, key length, and algorithm are correct and appropriate 191 for the entities involved. 193 4. AES Key Wrap with Padding 195 The AES Key Wrap with Padding is defined in [RFC5649]. This 196 algorithm uses an AES key to wrap a value that is a multiple of 8 197 bits. As such, it can be used to wrap not only the key sizes for the 198 content encryption algorithms, but additionally it can be used to 199 encrypt off size keys that can be used with the keyed hash functions 200 or key derivation functions. The algorithm uses a single fixed 201 parameter, the initial value. This value is fixed in section 3 of 202 [RFC5649], this is a different value from that used for the AES Key 203 Wrap algorithm of [RFC3394]. There are no public parameters that 204 very on a per-invocation bases. This algorithm does not support 205 additional data and thus the protected header field MUST be empty. 207 +------------+-------+------+------------------------+-------------+ 208 | Name | Value | Key | Description | Recommended | 209 | | | Size | | | 210 +============+=======+======+========================+=============+ 211 | A128KW-Pad | TBD1 | 128 | AES Key Wrap w/padding | Yes | 212 | | | | and a 128-bit key | | 213 +------------+-------+------+------------------------+-------------+ 214 | A192KW-Pad | TBD2 | 192 | AES Key Wrap w/padding | No | 215 | | | | and a 192-bit key | | 216 +------------+-------+------+------------------------+-------------+ 217 | A256KW-Pad | TBD3 | 256 | AES Key Wrap w/padding | Yes | 218 | | | | and a 256-bit key | | 219 +------------+-------+------+------------------------+-------------+ 221 Table 2: AES Key Wrap Algorithm Values 223 When using a COSE key for this algorithm, the following checks are 224 made: 226 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 228 * If the 'alg' field is present, it MUST match the AES Key Wrap 229 algorithm being used. 231 * If the 'key_ops' field is present, it MUST include 'encrypt' or 232 'wrap key' when encrypting. 234 * If the 'key_ops' field is present, it MUST include 'decrypt' or 235 'unwrap key' when decrypting. 237 4.1. Security Considerations for AES-KW with Padding 239 The shared secret needs to have some method to be regularly updated 240 over time. The shared secret is the basis of trust. 242 5. Key Derivation Functions (KDFs) 244 5.1. KMAC KDF 246 KMAC can additionally be used as a key derivation function 247 [NIST-800-56C]. KMAC has a big advantage over the HKDF function, 248 defined in [HKDF], as it executes the hashing function once as 249 opposed to either two or four times for HKDF w/ HMAC SHA-256. This 250 advantage may be offset by having SHA-256 in hardware and KMAC in 251 software, so that should be one consideration in deciding which one 252 to use. 254 The KMAC-KDF algorithm takes these inputs: 256 * secret -- a shared value that is secret. Secrets may be either 257 previously shared or derived from operations like a Diffie-Hellman 258 (DH) key agreement. 260 * salt -- an optional value that is used to change the generation 261 process. The salt value can be either public or private. If the 262 salt is public and carried in the message, then the 'salt' 263 algorithm header parameter defined in Table 9 of 264 [I-D.ietf-cose-rfc8152bis-algs] is used. While [HKDF] suggests 265 that the length of the salt be the same as the length of the 266 underlying hash value, any positive salt length will improve the 267 security as different key values will be generated. This 268 parameter is protected by being included in the key computation 269 and does not need to be separately authenticated. The salt value 270 does not need to be unique for every message sent. 272 * length -- the number of bytes of output that need to be generated. 274 * context information -- Information that describes the context in 275 which the resulting value will be used. Making this information 276 specific to the context in which the material is going to be used 277 ensures that the resulting material will always be tied to that 278 usage. The context structure defined in Section 5.2 of 279 [I-D.ietf-cose-rfc8152bis-algs] is used by the KDFs in this 280 document. 282 Full details of how the key derivation works can be found in 283 Section 4 of [NIST-800-56C]. A quick summary of the details is 284 provided here for simplicity. The KMAC function call is: 286 Result = KMAC#(salt, x, outputBits, "KDF") 288 where: 290 * salt is the same parameter as above 292 * x is built as _counter || Z || FixedInfo_. Where counter is a 293 4-byte unsigned integer of 0, Z is the secret, and FixedInfo is 294 the context information. 296 * outputBits is length * 8 298 One algorithm parameter is defined for the KMAC-KDF function. 300 +------+-------+------+------------------------------+-------------+ 301 | Name | Label | Type | Algorithm | Description | 302 +======+=======+======+==============================+=============+ 303 | salt | -20 | bstr | direct+KMAC-128-KDF, | Random salt | 304 | | | | direct+KMAC-256-KDF, ECDH- | | 305 | | | | ES+KMAC-128-KDF, ECDH- | | 306 | | | | ES+KMAC-256-KDF, ECDH- | | 307 | | | | SS+KMAC-128-KDF, ECDH- | | 308 | | | | SS+KMAC-256-KDF ECDH- | | 309 | | | | ES+KMAC-128-KDF+A128KW, | | 310 | | | | ECDH-ES+KMAC-256-KDF+A128KW, | | 311 | | | | ECDH-SS+KMAC-128-KDF+A128KW, | | 312 | | | | ECDH-SS+KMAC-256-KDF+A128KW | | 313 | | | | ECDH-ES+KMAC-256-KDF+A256KW, | | 314 | | | | ECDH-ES+KMAC-256-KDF+A256KW, | | 315 | | | | ECDH-SS+KMAC-256-KDF+A256KW, | | 316 | | | | ECDH-SS+KMAC-256-KDF+A256KW | | 317 +------+-------+------+------------------------------+-------------+ 319 Table 3: KMAC-KDF Algorithm Parameters 321 6. Content Key Distribution Methods 323 6.1. Direct Key with KDF 325 These recipient algorithms take a common shared secret between the 326 two parties and applies the KMAC-KDF function (Section 5.1), using 327 the context structure defined in Section 5.2 of 328 [I-D.ietf-cose-rfc8152bis-algs] to transform the shared secret into 329 the CEK. The 'protected' field can be of non-zero length. Either 330 the 'salt' parameter of KMAC-KDF or the 'PartyU nonce' parameter of 331 the context structure MUST be present. The salt/nonce parameter can 332 be generated either randomly or deterministically. The requirement 333 is that it be a unique value for the shared secret in question. 335 If the salt/nonce value is generated randomly, then it is suggested 336 that the length of the random value be the same length as the KMAC- 337 KDF. While there is no way to guarantee that it will be unique, 338 there is a high probability that it will be unique. If the salt/ 339 nonce value is generated deterministically, it can be guaranteed to 340 be unique, and thus there is no length requirement. 342 A new IV must be used for each message if the same key is used. The 343 IV can be modified in a predictable manner, a random manner, or an 344 unpredictable manner (i.e., encrypting a counter). 346 The IV used for a key can also be generated from the same KMAC-KDF 347 functionality as the key is generated. If KMAC-KDF is used for 348 generating the IV, the algorithm identifier is set to "IV- 349 GENERATION". Doing this requires that the context be modified for 350 every IV generated to ensure that it is unique. 352 When these algorithms are used, the key type MUST be 'symmetric'. 354 The set of algorithms defined in this document can be found in 355 Table 4. 357 +-----------------+-------+----------+---------------------------+ 358 | Name | Value | KDF | Description | 359 +=================+=======+==========+===========================+ 360 | direct+KMAC-128 | TBD6 | KMAC-128 | Shared secret w/ KMAC-128 | 361 +-----------------+-------+----------+---------------------------+ 362 | direct+KMAC-256 | TBD7 | KMAC-256 | Shared secret w/ KMAC-128 | 363 +-----------------+-------+----------+---------------------------+ 365 Table 4: Direct Key with KDF 367 When using a COSE key for this algorithm, the following checks are 368 made: 370 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 372 * If the 'alg' field is present, it MUST match the algorithm being 373 used. 375 * If the 'key_ops' field is present, it MUST include 'deriveKey' or 376 'deriveBits'. 378 6.1.1. Security Considerations 380 The shared secret needs to have some method to be regularly updated 381 over time. The shared secret forms the basis of trust. Although not 382 used directly, it should still be subject to scheduled rotation. 384 While these methods do not provide for perfect forward secrecy, as 385 the same shared secret is used for all of the keys generated, if the 386 key for any single message is discovered, only the message (or series 387 of messages) using that derived key are compromised. A new key 388 derivation step will generate a new key that requires the same amount 389 of work to get the key. 391 6.2. Direct ECDH 393 This document adds to the set of Direct ECDH algorithms which were 394 defined in Section 6.3 of [I-D.ietf-cose-rfc8152bis-algs]. This is 395 done by adding a changing the KDF used to derive the shared secret. 397 +----------+-------+----------+------------+------+-----------------+ 398 | Name | Value | KDF | Ephemeral- | Key | Description | 399 | | | | Static | Wrap | | 400 +==========+=======+==========+============+======+=================+ 401 | ECDH-ES | TBD8 | KMAC-128 | yes | none | ECDH ES w/ | 402 | + | | | | | KMAC - | 403 | KMAC-128 | | | | | generate key | 404 | | | | | | directly | 405 +----------+-------+----------+------------+------+-----------------+ 406 | ECDH-ES | TBD9 | KMAC-256 | yes | none | ECDH ES w/ | 407 | + | | | | | KMAC - | 408 | KMAC-256 | | | | | generate key | 409 | | | | | | directly | 410 +----------+-------+----------+------------+------+-----------------+ 412 Table 5: ECDH Algorithm Values 414 Both of these algorithms use the same set of the ECDH Algorithm 415 Parameters as their HKDF counterparts. 417 This document defines these algorithms to be used with the curves 418 P-256, P-384, P-521, X25519, and X448. Implementations MUST verify 419 that the key type and curve are correct. Different curves are 420 restricted to different key types. Implementations MUST verify that 421 the curve and algorithm are appropriate for the entities involved. 423 When using a COSE key for this algorithm, the following checks are 424 made: 426 * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. 428 * If the 'alg' field is present, it MUST match the key agreement 429 algorithm being used. 431 * If the 'key_ops' field is present, it MUST include 'derive key' or 432 'derive bits' for the private key. 434 * If the 'key_ops' field is present, it MUST be empty for the public 435 key. 437 6.3. ECDH with Key Wrap 439 This document adds to the set of Direct ECDH algorithms which were 440 defined in Section 6.4 of [I-D.ietf-cose-rfc8152bis-algs]. This is 441 done by adding a changing the KDF used to derive the shared secret. 443 +----------+-------+----------+------------+--------+-------------+ 444 | Name | Value | KDF | Ephemeral- | Key | Description | 445 | | | | Static | Wrap | | 446 +==========+=======+==========+============+========+=============+ 447 | ECDH-ES | TBD10 | KMAC-128 | yes | A128KW | ECDH ES w/ | 448 | + | | | | | KMAC-128 | 449 | KMAC-128 | | | | | and AES Key | 450 | + A128KW | | | | | Wrap w/ | 451 | | | | | | 128-bit key | 452 +----------+-------+----------+------------+--------+-------------+ 453 | ECDH-ES | TBD11 | KMAC-256 | yes | A256KW | ECDH ES w/ | 454 | + | | | | | KMAC-256 | 455 | KMAC-256 | | | | | and AES Key | 456 | + A256KW | | | | | Wrap w/ | 457 | | | | | | 256-bit key | 458 +----------+-------+----------+------------+--------+-------------+ 459 | ECDH-SS | TBD12 | KMAC-128 | yes | A128KW | ECDH SS w/ | 460 | + | | | | | KMAC-128 | 461 | KMAC-128 | | | | | and AES Key | 462 | + A128KW | | | | | Wrap w/ | 463 | | | | | | 128-bit key | 464 +----------+-------+----------+------------+--------+-------------+ 465 | ECDH-SS | TBD13 | KMAC-256 | yes | A256KW | ECDH SS w/ | 466 | + | | | | | KMAC-256 | 467 | KMAC-256 | | | | | and AES Key | 468 | + A256KW | | | | | Wrap w/ | 469 | | | | | | 256-bit key | 470 +----------+-------+----------+------------+--------+-------------+ 472 Table 6: ECDH Algorithm Values with Key Wrap 474 When using a COSE key for this algorithm, the following checks are 475 made: 477 * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. 479 * If the 'alg' field is present, it MUST match the key agreement 480 algorithm being used. 482 * If the 'key_ops' field is present, it MUST include 'derive key' or 483 'derive bits' for the private key. 485 * If the 'key_ops' field is present, it MUST be empty for the public 486 key. 488 7. Security Considerations 490 Decide on this - TBD 492 8. IANA Considerations 494 8.1. Changes to the Algorithm Table 496 IANA is requested to add new items to the "COSE Algorithms" registry. 497 The content to be added can be found in Table 2. For all items to be 498 added, the Reference column should be set to this document. 500 9. References 502 9.1. Normative References 504 [I-D.ietf-cose-rfc8152bis-struct] 505 Schaad, J., "CBOR Object Signing and Encryption (COSE): 506 Structures and Process", Work in Progress, Internet-Draft, 507 draft-ietf-cose-rfc8152bis-struct-08, 9 March 2020, 508 . 511 [I-D.ietf-cose-rfc8152bis-algs] 512 Schaad, J., "CBOR Object Signing and Encryption (COSE): 513 Initial Algorithms", Work in Progress, Internet-Draft, 514 draft-ietf-cose-rfc8152bis-algs-07, 9 March 2020, 515 . 518 [I-D.ietf-cbor-7049bis] 519 Bormann, C. and P. Hoffman, "Concise Binary Object 520 Representation (CBOR)", Work in Progress, Internet-Draft, 521 draft-ietf-cbor-7049bis-13, 8 March 2020, 522 . 524 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 525 Hashing for Message Authentication", RFC 2104, 526 DOI 10.17487/RFC2104, February 1997, 527 . 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, 531 DOI 10.17487/RFC2119, March 1997, 532 . 534 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 535 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 536 RFC 4231, DOI 10.17487/RFC4231, December 2005, 537 . 539 [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 540 Key Derivation Function (HKDF)", RFC 5869, 541 DOI 10.17487/RFC5869, May 2010, 542 . 544 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 545 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 546 May 2017, . 548 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 549 (AES) Key Wrap with Padding Algorithm", RFC 5649, 550 DOI 10.17487/RFC5649, September 2009, 551 . 553 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 554 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 555 September 2002, . 557 [NIST-800-185] 558 Kelsey, J., Change, S., and R. Perlner, "SHA-3 Derived 559 Functions: cSHAKE, KMAC, TupleHash, ParallelHash", 560 December 2016, 561 . 564 [NIST-800-56C] 565 Barker, E., Chen, L., and R. Davis, "Recommendation for 566 Key-Derivation Methods in Key-Establishment Schemes"", 567 March 2020, 568 . 571 Author's Address 573 Jim Schaad 574 August Cellars 576 Email: ietf@augustcellars.com