idnits 2.17.1 draft-moskowitz-hip-new-crypto-04.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 (23 January 2020) is 1526 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) == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-11 == Outdated reference: A later version (-01) exists of draft-moskowitz-orchid-cshake-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: 26 July 2020 AX Enterprize 7 23 January 2020 9 New Cryptographic Algorithms for HIP 10 draft-moskowitz-hip-new-crypto-04 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 26 July 2020. 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 . . . . . . . . . . . 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 . . . . . . . . . . 8 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: 146 In the sponge construction, the number of input bits processed per 147 invocation of the underlying function. 149 XOF (eXtendable-Output Function): 150 A function on bit strings (also called messages) in which the 151 output can be extended to any desired length. 153 3. HIP Parameter values for new Crytpo 155 HIP parameters carry information that is necessary for establishing 156 and maintaining a HIP association. For example, the device's public 157 keys as well as the signaling for negotiating ciphers and payload 158 handling are encapsulated in HIP parameters. Additional information, 159 meaningful for end hosts or middleboxes, may also be included in HIP 160 parameters. The specification of the HIP parameters and their 161 mapping to HIP packets and packet types is flexible to allow HIP 162 extensions to define new parameters and new protocol behavior. 164 3.1. Elliptic Curves for Diffie-Hellman 166 Elliptic curves Curve25519 and Curve448 [RFC7748] are specified here 167 for use in the HIP Diffie-Hellman exchange. 169 Curve25519 and Curve448 are already defined in Section 5.2.1 of 170 [I-D.ietf-hip-dex], using the HIP-DEX CKDF. Here they are defined 171 for using the new KMAC [NIST.SP.800-185] derived KDF in Section 5. 173 3.1.1. DIFFIE_HELLMAN 175 The DIFFIE_HELLMAN parameter may be included in selected HIP packets 176 based on the DH Group ID selected. The DIFFIE_HELLMAN parameter is 177 defined in Section 5.2.7 of [RFC7401]. 179 The following Elliptic Curves are defined here: 181 Group KDF Value 183 Curve25519 [RFC7748] KKDF 13 184 Curve448 [RFC7748] KKDF 14 186 A new KDF for KEYMAT, Section 6.5 of [RFC7401] and Section 6.3 of 187 [I-D.ietf-hip-dex] using Keccak is defined in Section 5. 189 3.2. Edward Digital Signature Algorithm 191 Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are 192 specified here for use as Host Identities (HIs). 194 3.2.1. HOST_ID 196 The HOST_ID parameter specifies the public key algorithm, and for 197 elliptic curves, a name. The HOST_ID parameter is defined in 198 Section 5.2.19 of [RFC7401]. 200 Algorithm 201 profiles Values 203 EdDSA 13 [RFC8032] (RECOMMENDED) 205 For hosts that implement EdDSA as the algorithm, the following ECC 206 curves are available: 208 Algorithm Curve Values 210 EdDSA RESERVED 0 211 EdDSA EdDSA25519 1 [RFC8032] 212 EdDSA EdDSA25519ph 2 [RFC8032] 213 EdDSA EdDSA448 3 [RFC8032] 214 EdDSA EdDSA448ph 4 [RFC8032] 216 3.2.2. HIT_SUITE_LIST 218 The HIT_SUITE_LIST parameter contains a list of the supported HIT 219 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 220 Initiator can determine which source HIT Suite IDs are supported by 221 the Responder. The HIT_SUITE_LIST parameter is defined in 222 Section 5.2.10 of [RFC7401]. 224 The following HIT Suite ID is defined, and the relationship between 225 the four-bit ID value used in the OGA ID field and the eight-bit 226 encoding within the HIT_SUITE_LIST ID field is clarified: 228 HIT Suite Four-bit ID Eight-bit encoding 229 RESERVED 0 0x00 230 EdDSA/SHAKE128 5 0x50 (RECOMMENDED) 232 The following table provides more detail on the above HIT Suite 233 combinations. The input for each generation algorithm is the 234 encoding of the HI as defined in Section 4. The output is 96 bits 235 long and is directly used in the ORCHID. 237 +-------+----------+---------+------------------+-------------------+ 238 | Index | Hash | HMAC | Signature | Description | 239 | | function | | algorithm | | 240 | | | | family | | 241 +=======+==========+=========+==================+===================+ 242 | 5 | SHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | 243 | | | | | with cSHAKE128, | 244 | | | | | output is 96 bits | 245 +-------+----------+---------+------------------+-------------------+ 247 Table 1: HIT Suites 249 3.3. Hashing with the Keccak Function 251 The [Keccak] sponge function is the basis for the new SHA-3, standard 252 [NIST.FIPS.202], and the customized XOF functions in 253 [NIST.SP.800-185]. These are used here as an alternative to all the 254 hashing functions in HIP. 256 Hardware implementation of Keccak in VHDL is available from [Keccak]. 258 3.3.1. The Keccak Permutation 260 Keccak is described as a sponge function. The analogy to a sponge is 261 that an arbitrary number of input bits are "absorbed" into the state 262 of the function, after which an arbitrary number of output bits are 263 "squeezed" out of its state. 265 The Keccak function is defined to have a width of b bits. Where b 266 is the capacity (c) + rate (r). 268 The rate is the number of bits "fed" into the sponge at a time. 270 The capacity is twice the desired hash "strength" and part of the 271 sponge width. 273 b is one of the set {25, 50, 100, 200, 400, 800, 1600}. In FIPS 202, 274 b=1600. Thus a hash strength of 128 bits can be delivered with c=256 275 and r=1344, or 168 byte segment input to the sponge. 277 Keccak can also provide a hash strength of 128 bit with b=800 (r=544 278 or 68 bytes) and b=400 (r=144 or 18 bytes). 256 bit strength can 279 only be provided with b=1600 or 800. 281 FIPS 202 does not specify use of these smaller values for b which may 282 be preferred in memory constrained devices, processing relatively 283 short input strings. Future work will determine if the smaller 284 values for b result in a significant performance/memory improvement 285 to warrant their use. 287 3.3.2. RHASH 289 The RHASH is the general term used throughout [RFC7401] to refer to 290 the hash used for a specific HIT suite. For this addendum SHAKE128 291 is used, even for HIs of EdDSA448. 293 Unless otherwise specified, L of SHAKE128 is 256, resulting in a 294 similar output to SHA256. Any truncation used for, older, fixed 295 output hashes is still used. This is to simplify code integration. 296 One exception to this is in Section 4. 298 3.3.3. HIP_MAC and HIP_MAC2 300 The HIP_MAC and HIP_MAC2 parameters in [RFC7401] use HMAC [RFC2104]. 301 This performs two hashes on a string with a key for a keyed hash the 302 length of the underlying hash. 304 Here, KMAC from NIST SP 800-185 [NIST.SP.800-185] is used. This is a 305 single pass using the underlying cSHAKE function. The function call 306 is: 308 KMAC128(Key, Input String, 256, "") 310 3.4. HIP Cipher 312 HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of 313 [RFC7401]. The Keccak Keyak cipher, [Keyak_Cipher], is recommended. 314 Keyak is a candidate in the NIST Lightweight Cryptography competition 315 and is consistent with the overall approach in this addendum to use 316 Keccak functions for simplicity in design and implementation. 318 3.4.1. HIP_CIPHER 320 The HIP_CIPHER parameter values for Keyak are: 322 hip_cipher 323 Suite ID Value 325 RIVER KEYAK 6 (Keyak) 326 LAKE KEYAK 7 (Keyak) 328 For use as the HIP Cipher, the TAG generated in Keyak is length 0. 329 The Keyak SUV is the key plus IV specified for the encrypted 330 parameter. River Keyak MAY be used for [Keyak_Cipher], in place of 331 AES-CTR. 333 Lake Keyak can provide 256 bits of security by following the 334 recommendations for the Keyak cipher. 336 4. Generating a HIT from an HI 338 The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation 339 method described in section 3.2 of [RFC7401]. The XOF functionality 340 of cSHAKE produces an output of L bits. This replaces the Encode_96 341 function in the ORCHID generation. 343 For identities that are EdDSA public keys, ORCHIDs will be generated 344 per the process defined in Using cSHAKE in ORCHIDs 345 [I-D.moskowitz-orchid-cshake] 347 5. HIP KEYMAT Generation 349 The KMAC function provides a new, more efficient, key derivation 350 function over HKDF [RFC5869]. This will be referred to as KKDF. 352 The choice of KMAC128 or KMAC256 is based on the strength of the 353 output key material. For 256 bits of strength equivalent to HMAC- 354 SHA256, use KMAC256. Per [NIST.SP.800-56Cr1], Section 4.1, Option 3: 356 OKM = KMAC[128|256](salt | info, IKM, L, S) 358 L is the derived key bit length. Since 4 HIP keys are "drawn" from 359 this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp. 360 606-637 [ASIACRYPT-2017] each of these derived keys will have the 361 same strength as the Diffie-Hellman shared secret. 363 S is the byte string 01001011 || 01000100 || 01000110, which 364 represents the sequence of characters "K", "D", and "F" in 8-bit 365 ASCII. 367 Salt and info are derived as defined in [RFC7401] or 368 [I-D.ietf-hip-dex]. There are special security considerations for 369 IKM per [RFC7748]. The two HIs MUST be used in constructing IKM as 370 follows: 372 IKM = Diffie-Hellman secret | HI-R | HI-I 374 These are separately DER encoded. 376 6. Using Keccak for a Pseudorandom Function 378 Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use 379 SHAKE, cSHAKE, or KMAC as a PRF. 381 7. IANA Considerations 383 IANA will need to make the following changes to the "Host Identity 384 Protocol (HIP) Parameters" registries: 386 Diffie Hellman: 387 This document defines the new Curve25519 and Curve448 for the 388 Diffie-Hellman exchange (see Section 3.1.1). 390 Host ID: 391 This document defines the new EdDSA Host ID (see Section 3.2.1). 393 HIT Suite ID: 394 This document defines the new HIT Suite of EdDSA/cSHAKE (see 395 Section 3.2.2). 397 HIP Cipher: 398 This document defines the new Keyak ciphers for HIP encrypted 399 parameters (see Section 3.4.1). 401 8. Security Considerations 403 8.1. Keymat vulnerabilities 405 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 406 for key derivation: 408 Designers using these curves should be aware that for each public 409 key, there are several publicly computable public keys that are 410 equivalent to it, i.e., they produce the same shared secrets. Thus 411 using a public key as an identifier and knowledge of a shared secret 412 as proof of ownership (without including the public keys in the key 413 derivation) might lead to subtle vulnerabilities. 415 This applies to [I-D.ietf-hip-dex], but may have broader 416 consequences. Thus the two Host IDs are included with the Diffie- 417 Hellman secret. 419 8.2. KMAC Security as a KDF 421 Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states: 423 "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and 424 keyed hash function based on KECCAK . It provides variable-length 425 output" 427 That is, the output of KMAC is indistinguishable from a random 428 string, regardless of the length of the output. As such, the output 429 of KMAC can be divided into multiple substrings, each with the 430 strength of the function (KMAC128 or KMAC256) and provided that a 431 long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. 433 For example KMAC128(K, X, 512, S), where K is at least 128 bits, can 434 produce 4 128 bit keys each with a strength of 128 bits. That is a 435 single sponge operation is replacing perhaps 5 HMAC-SHA256 operations 436 (each 2 SHA256 operations) in HKDF. 438 9. Acknowledgments 440 Quynh Dang of NIST gave considerable guidance on using Keccak and the 441 NIST supporting documents. Joan Deamen of the Keccak team was 442 especially helpful in many aspects of using Keccak, particularly with 443 the KEYMAT section and the strength of the derived keys. 445 10. References 447 10.1. Normative References 449 [NIST.FIPS.202] 450 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 451 Extendable-Output Functions", National Institute of 452 Standards and Technology report, 453 DOI 10.6028/nist.fips.202, July 2015, 454 . 456 [NIST.SP.800-185] 457 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 458 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 459 National Institute of Standards and Technology report, 460 DOI 10.6028/nist.sp.800-185, December 2016, 461 . 463 [NIST.SP.800-56Cr1] 464 Barker, E., Chen, L., and R. Davis, "Recommendation for 465 key-derivation methods in key-establishment schemes", 466 National Institute of Standards and Technology report, 467 DOI 10.6028/nist.sp.800-56cr1, April 2018, 468 . 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 476 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 477 May 2017, . 479 10.2. Informative References 481 [ASIACRYPT-2017] 482 Daemen, J., Mennink, B., and G. Van Assche, "Full-State 483 Keyed Duplex with Built-In Multi-user Support", 484 DOI 10.1007/978-3-319-70697-9_21, Advances in Cryptology - 485 ASIACRYPT 2017 pp. 606-637, 2017, 486 . 488 [I-D.ietf-hip-dex] 489 Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 490 (DEX)", Work in Progress, Internet-Draft, draft-ietf-hip- 491 dex-11, 31 October 2019, 492 . 494 [I-D.moskowitz-orchid-cshake] 495 Moskowitz, R., Card, S., and A. Wiethuechter, "Using 496 cSHAKE in ORCHIDs", Work in Progress, Internet-Draft, 497 draft-moskowitz-orchid-cshake-00, 11 December 2019, 498 . 501 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 502 R. Van Keer, "The Keccak Function", 503 . 505 [Keyak_Cipher] 506 Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 507 R. Van Keer, "The Keyak Cipher", 508 . 510 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 511 Hashing for Message Authentication", RFC 2104, 512 DOI 10.17487/RFC2104, February 1997, 513 . 515 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 516 Key Derivation Function (HKDF)", RFC 5869, 517 DOI 10.17487/RFC5869, May 2010, 518 . 520 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 521 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 522 RFC 7401, DOI 10.17487/RFC7401, April 2015, 523 . 525 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 526 for Security", RFC 7748, DOI 10.17487/RFC7748, January 527 2016, . 529 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 530 Signature Algorithm (EdDSA)", RFC 8032, 531 DOI 10.17487/RFC8032, January 2017, 532 . 534 Authors' Addresses 536 Robert Moskowitz 537 HTT Consulting 538 Oak Park, MI 48237 539 United States of America 541 Email: rgm@labs.htt-consult.com 543 Stuart W. Card 544 AX Enterprize 545 4947 Commercial Drive 546 Yorkville, NY 13495 547 United States of America 549 Email: stu.card@axenterprize.com 551 Adam Wiethuechter 552 AX Enterprize 553 4947 Commercial Drive 554 Yorkville, NY 13495 555 United States of America 557 Email: adam.wiethuechter@axenterprize.com