idnits 2.17.1 draft-moskowitz-hip-new-crypto-06.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 draft header indicates that this document updates RFC7401, 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 (November 2, 2020) is 1269 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 (if approved) S. Card 5 Intended status: Standards Track A. Wiethuechter 6 Expires: May 6, 2021 AX Enterprize 7 November 2, 2020 9 New Cryptographic Algorithms for HIP 10 draft-moskowitz-hip-new-crypto-06 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 May 6, 2021. 36 Copyright Notice 38 Copyright (c) 2020 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 Crytpo . . . . . . . . . . . . . 4 57 3.1. Elliptic Curves for Diffie-Hellman . . . . . . . . . . . 4 58 3.1.1. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 4 59 3.2. Edward Digital Signature Algorithm for HITs . . . . . . . 4 60 3.2.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 5 62 3.3. Hashing with the Keccak Function . . . . . . . . . . . . 6 63 3.3.1. The Keccak Permutation . . . . . . . . . . . . . . . 6 64 3.3.2. RHASH . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3.3. HIP_MAC and HIP_MAC2 . . . . . . . . . . . . . . . . 7 66 3.4. HIP Cipher . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4.1. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 7 68 4. Generating a HIT from an HI . . . . . . . . . . . . . . . . . 8 69 5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . . . 8 70 6. Using Keccak for a Pseudorandom Function . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8.1. Keymat vulnerabilities . . . . . . . . . . . . . . . . . 9 74 8.2. KMAC Security as a KDF . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 10.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 This document adds new cryptographic algorithms for HIPv2 [RFC7401]. 84 This includes: 86 * New elliptic curves for ECDH. 88 * The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA) 89 used in Host Identities (HI) and for Base Exchange (BEX) 90 signatures. 92 * Hashes used in Host Identity Tag (HIT) generation, and wherever 93 else hashes are needed. 95 * Keyed hashes used for KEYMAT generation and packet MACing 96 operations. 98 * AEAD and stream ciphers to use in HIP and HIP enabled secure 99 communication protocols. 101 The hashes and encryption are all built on the [Keccak] sponge 102 function. 104 These additions reflect selection of advances in the field of 105 cryptography that would best benefit HIP, particularly in constrained 106 devices and communications. 108 2. Terms and Definitions 110 2.1. Requirements Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 2.2. Definitions 120 Keccak (KECCAK Message Authentication Code): 121 The family of all sponge functions with a KECCAK-f permutation as 122 the underlying function and multi-rate padding as the padding 123 rule. 125 KMAC (KECCAK Message Authentication Code): 126 A PRF and keyed hash function based on KECCAK. 128 cSHAKE (The customizable SHAKE function): 129 Extends the SHAKE scheme to allow users to customize their use of 130 the function. 132 SHAKE (Secure Hash Algorithm KECCAK): 133 A secure hash that allows for an arbitrary output length. 135 PRF (Pseudorandom Function): 136 A function that can be used to generate output from a random seed 137 such that the output is computationally indistinguishable from 138 truly random output. 140 capacity: 141 In the sponge construction, the width of the underlying function 142 minus the rate. 144 rate: 145 In the sponge construction, the number of input bits processed per 146 invocation of the underlying function. 148 XOF (eXtendable-Output Function): 149 A function on bit strings (also called messages) in which the 150 output can be extended to any desired length. 152 3. HIP Parameter values for new Crytpo 154 HIP parameters carry information that is necessary for establishing 155 and maintaining a HIP association. For example, the device's public 156 keys as well as the signaling for negotiating ciphers and payload 157 handling are encapsulated in HIP parameters. Additional information, 158 meaningful for end hosts or middleboxes, may also be included in HIP 159 parameters. The specification of the HIP parameters and their 160 mapping to HIP packets and packet types is flexible to allow HIP 161 extensions to define new parameters and new protocol behavior. 163 3.1. Elliptic Curves for Diffie-Hellman 165 Elliptic curves Curve25519 and Curve448 [RFC7748] are specified here 166 for use in the HIP Diffie-Hellman exchange. 168 Curve25519 and Curve448 are already defined in Section 5.2.1 of 169 [hip-dex], using the HIP-DEX CKDF. Here they are defined for using 170 the new KMAC [NIST.SP.800-185] derived KDF in Section 5. 172 3.1.1. DIFFIE_HELLMAN 174 The DIFFIE_HELLMAN parameter may be included in selected HIP packets 175 based on the DH Group ID selected. The DIFFIE_HELLMAN parameter is 176 defined in Section 5.2.7 of [RFC7401]. 178 The following Elliptic Curves are defined here: 180 Group KDF Value 182 Curve25519 [RFC7748] KKDF 13 183 Curve448 [RFC7748] KKDF 14 185 A new KDF for KEYMAT, Section 6.5 of [RFC7401] and Section 6.3 of 186 [hip-dex] using Keccak is defined in Section 5. 188 3.2. Edward Digital Signature Algorithm for HITs 190 This section is pulled from Appendix D of [drip-uas-rid]. It may 191 later be pulled and only maintained there. 193 Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are 194 specified here for use as Host Identities (HIs) per HIPv2 [RFC7401]. 195 Further the HIT_SUITE_LIST is specified as used in [RFC7343]. 197 3.2.1. HOST_ID 199 The HOST_ID parameter specifies the public key algorithm, and for 200 elliptic curves, a name. The HOST_ID parameter is defined in 201 Section 5.2.19 of [RFC7401]. 203 Algorithm 204 profiles Values 206 EdDSA 13 [RFC8032] (RECOMMENDED) 208 For hosts that implement EdDSA as the algorithm, the following ECC 209 curves are available: 211 Algorithm Curve Values 213 EdDSA RESERVED 0 214 EdDSA EdDSA25519 1 [RFC8032] 215 EdDSA EdDSA25519ph 2 [RFC8032] 216 EdDSA EdDSA448 3 [RFC8032] 217 EdDSA EdDSA448ph 4 [RFC8032] 219 3.2.2. HIT_SUITE_LIST 221 The HIT_SUITE_LIST parameter contains a list of the supported HIT 222 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 223 Initiator can determine which source HIT Suite IDs are supported by 224 the Responder. The HIT_SUITE_LIST parameter is defined in 225 Section 5.2.10 of [RFC7401]. 227 The following HIT Suite ID is defined, and the relationship between 228 the four-bit ID value used in the OGA ID field and the eight-bit 229 encoding within the HIT_SUITE_LIST ID field is clarified: 231 HIT Suite Four-bit ID Eight-bit encoding 232 RESERVED 0 0x00 233 EdDSA/cSHAKE128 5 0x50 (RECOMMENDED) 235 The following table provides more detail on the above HIT Suite 236 combinations. The input for each generation algorithm is the 237 encoding of the HI as defined in this Appendix. 239 The output of cSHAKE128 is variable per the needs of a specific 240 ORCHID construction. It is at most 96 bits long and is directly used 241 in the ORCHID (without truncation). 243 +=======+===========+=========+===========+====================+ 244 | Index | Hash | HMAC | Signature | Description | 245 | | function | | algorithm | | 246 | | | | family | | 247 +=======+===========+=========+===========+====================+ 248 | 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | 249 | | | | | with cSHAKE128, | 250 | | | | | output is variable | 251 +-------+-----------+---------+-----------+--------------------+ 253 Table 1: HIT Suites 255 3.3. Hashing with the Keccak Function 257 The [Keccak] sponge function is the basis for the new SHA-3, standard 258 [NIST.FIPS.202], and the customized XOF functions in 259 [NIST.SP.800-185]. These are used here as an alternative to all the 260 hashing functions in HIP. 262 Hardware implementation of Keccak in VHDL is available from [Keccak]. 264 3.3.1. The Keccak Permutation 266 Keccak is described as a sponge function. The analogy to a sponge is 267 that an arbitrary number of input bits are "absorbed" into the state 268 of the function, after which an arbitrary number of output bits are 269 "squeezed" out of its state. 271 The Keccak function is defined to have a width of b bits. Where b 272 is the capacity (c) + rate (r). 274 The rate is the number of bits "fed" into the sponge at a time. 276 The capacity is twice the desired hash "strength" and part of the 277 sponge width. 279 b is one of the set {25, 50, 100, 200, 400, 800, 1600}. In FIPS 202, 280 b=1600. Thus a hash strength of 128 bits can be delivered with c=256 281 and r=1344, or 168 byte segment input to the sponge. 283 Keccak can also provide a hash strength of 128 bit with b=800 (r=544 284 or 68 bytes) and b=400 (r=144 or 18 bytes). 256 bit strength can 285 only be provided with b=1600 or 800. 287 FIPS 202 does not specify use of these smaller values for b which may 288 be preferred in memory constrained devices, processing relatively 289 short input strings. Future work will determine if the smaller 290 values for b result in a significant performance/memory improvement 291 to warrant their use. 293 3.3.2. RHASH 295 The RHASH is the general term used throughout [RFC7401] to refer to 296 the hash used for a specific HIT suite. For this addendum SHAKE128 297 is used, even for HIs of EdDSA448. 299 Unless otherwise specified, L of SHAKE128 is 256, resulting in a 300 similar output to SHA256. Any truncation used for, older, fixed 301 output hashes is still used. This is to simplify code integration. 302 One exception to this is in Section 4. 304 3.3.3. HIP_MAC and HIP_MAC2 306 The HIP_MAC and HIP_MAC2 parameters in [RFC7401] use HMAC [RFC2104]. 307 This performs two hashes on a string with a key for a keyed hash the 308 length of the underlying hash. 310 Here, KMAC from NIST SP 800-185 [NIST.SP.800-185] is used. This is a 311 single pass using the underlying cSHAKE function. The function call 312 is: 314 KMAC128(Key, Input String, 256, "") 316 3.4. HIP Cipher 318 HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of 319 [RFC7401]. The Keccak Keyak cipher, [Keyak_Cipher], is recommended. 320 Keyak is a candidate in the NIST Lightweight Cryptography competition 321 and is consistent with the overall approach in this addendum to use 322 Keccak functions for simplicity in design and implementation. 324 3.4.1. HIP_CIPHER 326 The HIP_CIPHER parameter values for Keyak are: 328 hip_cipher 329 Suite ID Value 331 RIVER KEYAK 6 (Keyak) 332 LAKE KEYAK 7 (Keyak) 334 For use as the HIP Cipher, the TAG generated in Keyak is length 0. 335 The Keyak SUV is the key plus IV specified for the encrypted 336 parameter. River Keyak MAY be used for [Keyak_Cipher], in place of 337 AES-CTR. 339 Lake Keyak can provide 256 bits of security by following the 340 recommendations for the Keyak cipher. 342 4. Generating a HIT from an HI 344 The EdDSA/cSHAKE based HITs require a new ORCHID generation method 345 than that described in section 3.2 of [RFC7401]. The XOF 346 functionality of cSHAKE produces an output of L bits. This replaces 347 the Encode_96 function in the ORCHID generation. 349 For identities that are EdDSA public keys, ORCHIDs will be generated 350 per the process defined in Appendix C.2.1 of [drip-uas-rid]. 352 5. HIP KEYMAT Generation 354 The KMAC function provides a new, more efficient, key derivation 355 function over HKDF [RFC5869]. This will be referred to as KKDF. 357 The choice of KMAC128 or KMAC256 is based on the strength of the 358 output key material. For 256 bits of strength equivalent to HMAC- 359 SHA256, use KMAC256. Per [NIST.SP.800-56Cr1], Section 4.1, Option 3: 361 OKM = KMAC[128|256](salt | info, IKM, L, S) 363 L is the derived key bit length. Since 4 HIP keys are "drawn" from 364 this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp. 365 606-637 [ASIACRYPT-2017] each of these derived keys will have the 366 same strength as the Diffie-Hellman shared secret. 368 S is the byte string 01001011 || 01000100 || 01000110, which 369 represents the sequence of characters "K", "D", and "F" in 8-bit 370 ASCII. 372 Salt and info are derived as defined in [RFC7401] or [hip-dex]. 373 There are special security considerations for IKM per [RFC7748]. The 374 two HIs MUST be used in constructing IKM as follows: 376 IKM = Diffie-Hellman secret | HI-R | HI-I 378 These are separately DER encoded. 380 6. Using Keccak for a Pseudorandom Function 382 Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use 383 SHAKE, cSHAKE, or KMAC as a PRF. 385 7. IANA Considerations 387 IANA will need to make the following changes to the "Host Identity 388 Protocol (HIP) Parameters" registries: 390 Diffie Hellman: 391 This document defines the new Curve25519 and Curve448 for the 392 Diffie-Hellman exchange (see Section 3.1.1). 394 Host ID: 395 This document defines the new EdDSA Host ID (see Section 3.2.1). 397 HIT Suite ID: 398 This document defines the new HIT Suite of EdDSA/cSHAKE (see 399 Section 3.2.2). 401 HIP Cipher: 402 This document defines the new Keyak ciphers for HIP encrypted 403 parameters (see Section 3.4.1). 405 8. Security Considerations 407 8.1. Keymat vulnerabilities 409 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 410 for key derivation: 412 Designers using these curves should be aware that for each public 413 key, there are several publicly computable public keys that are 414 equivalent to it, i.e., they produce the same shared secrets. Thus 415 using a public key as an identifier and knowledge of a shared secret 416 as proof of ownership (without including the public keys in the key 417 derivation) might lead to subtle vulnerabilities. 419 This applies to [hip-dex], but may have broader consequences. Thus 420 the two Host IDs are included with the Diffie-Hellman secret. 422 8.2. KMAC Security as a KDF 424 Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states: 426 "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and 427 keyed hash function based on KECCAK . It provides variable-length 428 output" 430 That is, the output of KMAC is indistinguishable from a random 431 string, regardless of the length of the output. As such, the output 432 of KMAC can be divided into multiple substrings, each with the 433 strength of the function (KMAC128 or KMAC256) and provided that a 434 long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. 436 For example KMAC128(K, X, 512, S), where K is at least 128 bits, can 437 produce 4 128 bit keys each with a strength of 128 bits. That is a 438 single sponge operation is replacing perhaps 5 HMAC-SHA256 operations 439 (each 2 SHA256 operations) in HKDF. 441 9. Acknowledgments 443 Quynh Dang of NIST gave considerable guidance on using Keccak and the 444 NIST supporting documents. Joan Deamen of the Keccak team was 445 especially helpful in many aspects of using Keccak, particularly with 446 the KEYMAT section and the strength of the derived keys. 448 NIST is entering round 3 (final) of its Lightweight Crypto 449 Competition with anticipated selection the end of 2021 or early in 450 2022. Events in this process will impact selections in this 451 document. 453 10. References 455 10.1. Normative References 457 [NIST.FIPS.202] 458 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 459 Extendable-Output Functions", National Institute of 460 Standards and Technology report, 461 DOI 10.6028/nist.fips.202, July 2015, 462 . 464 [NIST.SP.800-185] 465 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 466 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 467 National Institute of Standards and Technology report, 468 DOI 10.6028/nist.sp.800-185, December 2016, 469 . 471 [NIST.SP.800-56Cr1] 472 Barker, E., Chen, L., and R. Davis, "Recommendation for 473 key-derivation methods in key-establishment schemes", 474 National Institute of Standards and Technology report, 475 DOI 10.6028/nist.sp.800-56cr1, April 2018, 476 . 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 485 May 2017, . 487 10.2. Informative References 489 [ASIACRYPT-2017] 490 Daemen, J., Mennink, B., and G. Van Assche, "Full-State 491 Keyed Duplex with Built-In Multi-user Support", 492 DOI 10.1007/978-3-319-70697-9_21, Advances in Cryptology - 493 ASIACRYPT 2017 pp. 606-637, 2017, 494 . 496 [drip-uas-rid] 497 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 498 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 499 ietf-drip-rid-04, November 1, 2020, 500 . 502 [hip-dex] Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 503 (DEX)", Work in Progress, Internet-Draft, draft-ietf-hip- 504 dex-21, July 8, 2020, 505 . 507 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 508 R. Van Keer, "The Keccak Function", 509 . 511 [Keyak_Cipher] 512 Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 513 R. Van Keer, "The Keyak Cipher", 514 . 516 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 517 Hashing for Message Authentication", RFC 2104, 518 DOI 10.17487/RFC2104, February 1997, 519 . 521 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 522 Key Derivation Function (HKDF)", RFC 5869, 523 DOI 10.17487/RFC5869, May 2010, 524 . 526 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 527 Routable Cryptographic Hash Identifiers Version 2 528 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 529 2014, . 531 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 532 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 533 RFC 7401, DOI 10.17487/RFC7401, April 2015, 534 . 536 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 537 for Security", RFC 7748, DOI 10.17487/RFC7748, January 538 2016, . 540 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 541 Signature Algorithm (EdDSA)", RFC 8032, 542 DOI 10.17487/RFC8032, January 2017, 543 . 545 Authors' Addresses 547 Robert Moskowitz 548 HTT Consulting 549 Oak Park, MI 48237 550 United States of America 552 Email: rgm@labs.htt-consult.com 554 Stuart W. Card 555 AX Enterprize 556 4947 Commercial Drive 557 Yorkville, NY 13495 558 United States of America 560 Email: stu.card@axenterprize.com 561 Adam Wiethuechter 562 AX Enterprize 563 4947 Commercial Drive 564 Yorkville, NY 13495 565 United States of America 567 Email: adam.wiethuechter@axenterprize.com