idnits 2.17.1 draft-moskowitz-hip-new-crypto-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2019) is 1675 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-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: March 28, 2020 A. Wiethuechter 6 AX Enterprize 7 September 25, 2019 9 New Cryptographic Algorithms for HIP 10 draft-moskowitz-hip-new-crypto-01 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 March 28, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 56 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. HIP Parameter values for new Crytpo . . . . . . . . . . . . . 4 58 3.1. Elliptic Curves for Diffie-Hellman . . . . . . . . . . . 4 59 3.1.1. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 4 60 3.2. Edward Digital Signature Algorithm . . . . . . . . . . . 4 61 3.2.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 5 63 3.3. Hashing with the Keccak Function . . . . . . . . . . . . 6 64 3.3.1. The Keccak Permutation . . . . . . . . . . . . . . . 6 65 3.3.2. RHASH . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3.3. HIP_MAC and HIP_MAC2 . . . . . . . . . . . . . . . . 7 67 3.4. HIP Cipher . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4.1. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 7 69 4. Generating a HIT from an HI . . . . . . . . . . . . . . . . . 8 70 5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . . . 8 71 6. Using Keccak for a Pseudorandom Function . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8.1. Keymat vulnerabilities . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 10.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 This document adds new cryptographic algorithms for HIPv2 [RFC7401]. 84 This includes: 86 o New elliptic curves for ECDH. 88 o The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA) 89 used in Host Identities (HI) and for Base Exchange (BEX) 90 signatures. 92 o Hashes used in Host Identity Tag (HIT) generation, and wherever 93 else hashes are needed. 95 o Keyed hashes used for KEYMAT generation and packet MACing 96 operations. 98 o 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 [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): The family of all 121 sponge functions with a KECCAK-f permutation as the underlying 122 function and multi-rate padding as the padding rule. 124 KMAC (KECCAK Message Authentication Code): A PRF and keyed hash 125 function based on KECCAK. 127 cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme 128 to allow users to customize their use of the function. 130 SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows for 131 an arbitrary output length. 133 PRF (Pseudorandom Function): A function that can be used to generate 134 output from a random seed such that the output is computationally 135 indistinguishable from truly random output. 137 capacity: In the sponge construction, the width of the underlying 138 function minus the rate. 140 rate: In the sponge construction, the number of input bits processed 141 per invocation of the underlying function. 143 XOF (eXtendable-Output Function): A function on bit strings (also 144 called messages) in which the output can be extended to any 145 desired length. 147 3. HIP Parameter values for new Crytpo 149 HIP parameters carry information that is necessary for establishing 150 and maintaining a HIP association. For example, the device's public 151 keys as well as the signaling for negotiating ciphers and payload 152 handling are encapsulated in HIP parameters. Additional information, 153 meaningful for end hosts or middleboxes, may also be included in HIP 154 parameters. The specification of the HIP parameters and their 155 mapping to HIP packets and packet types is flexible to allow HIP 156 extensions to define new parameters and new protocol behavior. 158 3.1. Elliptic Curves for Diffie-Hellman 160 Elliptic curves Curve25519 and Curve448 RFC 7748 [RFC7748]) are 161 specified here for use in the HIP Diffie-Hellman exchange. 163 Curve25519 and Curve448 are already defined in Section 5.2.1 of 164 [I-D.ietf-hip-dex], using the HIP-DEX CKDF. Here they are defined 165 for using the new KMAC NIST SP 800-185 [NIST.SP.800-185] derived KDF 166 in Section 5. 168 3.1.1. DIFFIE_HELLMAN 170 The DIFFIE_HELLMAN parameter may be included in selected HIP packets 171 based on the DH Group ID selected. The DIFFIE_HELLMAN parameter is 172 defined in Section 5.2.7 of [RFC7401]. 174 The following Elliptic Curves are defined here: 176 Group KDF Value 178 Curve25519 [RFC7748] KKDF 13 179 Curve448 [RFC7748] KKDF 14 181 A new KDF for KEYMAT, Section 6.5 of [RFC7401] and Section 6.3 of 182 [I-D.ietf-hip-dex] using Keccak is defined in Section 5. 184 3.2. Edward Digital Signature Algorithm 186 Edwards-Curve Digital Signature Algorithm (EdDSA) (RFC 8032 187 [RFC8032]) are specified here for use as Host Identities (HIs). 189 3.2.1. HOST_ID 191 The HOST_ID parameter specifies the public key algorithm, and for 192 elliptic curves, a name. The HOST_ID parameter is defined in 193 Section 5.2.19 of [RFC7401]. 195 Algorithm 196 profiles Values 198 EdDSA 13 [RFC8032] (RECOMMENDED) 200 For hosts that implement EdDSA as the algorithm, the following ECC 201 curves are available: 203 Algorithm Curve Values 205 EdDSA RESERVED 0 206 EdDSA EdDSA25519 1 [RFC8032] 207 EdDSA EdDSA25519ph 2 [RFC8032] 208 EdDSA EdDSA448 3 [RFC8032] 209 EdDSA EdDSA448ph 4 [RFC8032] 211 3.2.2. HIT_SUITE_LIST 213 The HIT_SUITE_LIST parameter contains a list of the supported HIT 214 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 215 Initiator can determine which source HIT Suite IDs are supported by 216 the Responder. The HIT_SUITE_LIST parameter is defined in 217 Section 5.2.10 of [RFC7401]. 219 The following HIT Suite ID is defined, and the relationship between 220 the four-bit ID value used in the OGA ID field and the eight-bit 221 encoding within the HIT_SUITE_LIST ID field is clarified: 223 HIT Suite Four-bit ID Eight-bit encoding 224 RESERVED 0 0x00 225 EdDSA/SHAKE128 5 0x50 (RECOMMENDED) 227 The following table provides more detail on the above HIT Suite 228 combinations. The input for each generation algorithm is the 229 encoding of the HI as defined in Section 4. The output is 96 bits 230 long and is directly used in the ORCHID. 232 +-------+----------+---------+---------------+----------------------+ 233 | Index | Hash | HMAC | Signature | Description | 234 | | function | | algorithm | | 235 | | | | family | | 236 +-------+----------+---------+---------------+----------------------+ 237 | 5 | SHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed with | 238 | | | | | cSHAKE128, output is | 239 | | | | | 96 bits | 240 +-------+----------+---------+---------------+----------------------+ 242 Table 1: HIT Suites 244 3.3. Hashing with the Keccak Function 246 The Keccak [Keccak] sponge function is the basis for the new SHA-3, 247 standard NIST FIPS 202 [NIST.FIPS.202], and the customized XOF 248 functions in NIST SP 800-185 [NIST.SP.800-185]. These are used here 249 as an alternative to all the hashing functions in HIP. 251 Hardware implementation of Keccak in VHDL is available from Keccak 252 [Keccak]. 254 3.3.1. The Keccak Permutation 256 Keccak is described as a sponge function. The analogy to a sponge is 257 that an arbitrary number of input bits are "absorbed" into the state 258 of the function, after which an arbitrary number of output bits are 259 "squeezed" out of its state. 261 The Keccak function is defined to have a width of b bits. Where b 262 is the capacity (c) + rate (r). 264 The rate is the number of bits "fed" into the sponge at a time. 266 The capacity is twice the desired hash "strength" and part of the 267 sponge width. 269 b is one of the set {25, 50, 100, 200, 400, 800, 1600}. In FIPS 202, 270 b=1600. Thus a hash strength of 128 bits can be delivered with c=256 271 and r=1344, or 168 byte segment input to the sponge. 273 Keccak can also provide a hash strength of 128 bit with b=800 (r=544 274 or 68 bytes) and b=400 (r=144 or 18 bytes). 256 bit strength can 275 only be provided with b=1600 or 800. 277 FIPS 202 does not specify use of these smaller values for b which may 278 be preferred in memory constrained devices, processing relatively 279 short input strings. Future work will determine if the smaller 280 values for b result in a significant performance/memory improvement 281 to warrant their use. 283 3.3.2. RHASH 285 The RHASH is the general term used throughout [RFC7401] to refer to 286 the hash used for a specific HIT suite. For this addendum SHAKE128 287 is used, even for HIs of EdDSA448. 289 Unless otherwise specified, L of SHAKE128 is 256, resulting in a 290 similar output to SHA256. Any truncation used for, older, fixed 291 output hashes is still used. This is to simplify code integration. 292 One exception to this is in Section 4. 294 3.3.3. HIP_MAC and HIP_MAC2 296 The HIP_MAC and HIP_MAC2 parameters in [RFC7401] use HMAC [RFC2104]. 297 This performs two hashes on a string with a key for a keyed hash the 298 length of the underlying hash. 300 Here, KMAC from NIST SP 800-185 [NIST.SP.800-185] is used. This is a 301 single pass using the underlying cSHAKE function. The function call 302 is: 304 KMAC128(Key, Input String, 256, "") 306 3.4. HIP Cipher 308 HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of 309 [RFC7401]. The Keccak Keyak cipher, ref, is recommended. Keyak is a 310 candidate in the NIST Lightweight Cryptography competition and is 311 consistent with the overall approach in this addendum to use Keccak 312 functions for simplicity in design and implementation. 314 3.4.1. HIP_CIPHER 316 The HIP_CIPHER parameter values for Keyak are: 318 hip_cipher 319 Suite ID Value 321 RIVER KEYAK 6 (Keyak) 322 LAKE KEYAK 7 (Keyak) 324 For use as the HIP Cipher, the TAG generated in Keyak is discarded. 325 The Keyak SUV is the key plus IV specified for the encrypted 326 parameter. River Keyak MAY be used for [I-D.ietf-hip-dex], in place 327 of AES-CTR. 329 Lake Keyak can provide 256 bits of security by following the 330 recommendations for the Keyak cipher. 332 4. Generating a HIT from an HI 334 The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation 335 method described in section 3.2 of [RFC7401]. The XOF functionality 336 of cSHAKE produces an output of L bits. This replaces the Encode_96 337 function in the ORCHID generation. 339 For identities that are EdDSA public keys, the ORCHID input consists 340 of the public key encoding as specified for the Host Identity field 341 of the HOST_ID parameter (see Section 3.2.1). Since L is less than 342 128, cSHAKE128 is used for all EdDSA curve sizes: 344 cSHAKE128(EdDSA public key, 96, "", Context ID) 346 5. HIP KEYMAT Generation 348 The KMAC function provides a new, more efficient, key derivation 349 function over HKDF [RFC5869]. This will be referred to as KKDF. 351 The choice of KMAC128 or KMAC256 is based on the strength of the 352 output key material. For 256 bits of strength equivalent to HMAC- 353 SHA256, use KMAC256. Per NIST SP 800-56Cr1 [NIST.SP.800-56Cr1], 354 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: This document defines the new Curve25519 and 387 Curve448 for the Diffie-Hellman exchange (see Section 3.1.1). 389 Host ID: This document defines the new EdDSA Host ID (see 390 Section 3.2.1). 392 HIT Suite ID: This document defines the new HIT Suite of EdDSA/ 393 cSHAKE (see Section 3.2.2). 395 HIP Cipher: This document defines the new Keyak ciphers for HIP 396 encrypted parameters (see Section 3.4.1). 398 8. Security Considerations 400 8.1. Keymat vulnerabilities 402 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 403 for key derivation: 405 Designers using these curves should be aware that for each public 406 key, there are several publicly computable public keys that are 407 equivalent to it, i.e., they produce the same shared secrets. Thus 408 using a public key as an identifier and knowledge of a shared secret 409 as proof of ownership (without including the public keys in the key 410 derivation) might lead to subtle vulnerabilities. 412 This applies to [I-D.ietf-hip-dex], but may have broader 413 consequences. Thus the two Host IDs are included with the Diffie- 414 Hellman secret. 416 9. Acknowledgments 418 Quynh Dang of NIST gave considerable guidance on using Keccak and the 419 NIST supporting documents. Joan Deamen of the Keccak team was 420 especially helpful in many aspects of using Keccak, particularly with 421 the KEYMAT section and the strength of the derived keys. 423 10. References 425 10.1. Normative References 427 [NIST.FIPS.202] 428 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 429 Extendable-Output Functions", National Institute of 430 Standards and Technology report, 431 DOI 10.6028/nist.fips.202, July 2015. 433 [NIST.SP.800-185] 434 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 435 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 436 National Institute of Standards and Technology report, 437 DOI 10.6028/nist.sp.800-185, December 2016. 439 [NIST.SP.800-56Cr1] 440 Barker, E., Chen, L., and R. Davis, "Recommendation for 441 key-derivation methods in key-establishment schemes", 442 National Institute of Standards and Technology report, 443 DOI 10.6028/nist.sp.800-56cr1, April 2018. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 10.2. Informative References 456 [ASIACRYPT-2017] 457 Daemen, J., Mennink, B., and G. Van Assche, "Full-State 458 Keyed Duplex with Built-In Multi-user Support", Advances 459 in Cryptology - ASIACRYPT 2017 pp. 606-637, 460 DOI 10.1007/978-3-319-70697-9_21, 2017. 462 [I-D.ietf-hip-dex] 463 Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 464 (DEX)", draft-ietf-hip-dex-09 (work in progress), 465 September 2019. 467 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 468 R. Van Keer, "The Keccak", 469 . 471 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 472 Hashing for Message Authentication", RFC 2104, 473 DOI 10.17487/RFC2104, February 1997, 474 . 476 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 477 Key Derivation Function (HKDF)", RFC 5869, 478 DOI 10.17487/RFC5869, May 2010, 479 . 481 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 482 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 483 RFC 7401, DOI 10.17487/RFC7401, April 2015, 484 . 486 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 487 for Security", RFC 7748, DOI 10.17487/RFC7748, January 488 2016, . 490 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 491 Signature Algorithm (EdDSA)", RFC 8032, 492 DOI 10.17487/RFC8032, January 2017, 493 . 495 Authors' Addresses 497 Robert Moskowitz 498 HTT Consulting 499 Oak Park, MI 48237 500 USA 502 Email: rgm@labs.htt-consult.com 504 Stuart W. Card 505 AX Enterprize 506 4947 Commercial Drive 507 Yorkville, NY 13495 508 USA 510 Email: stu.card@axenterprize.com 511 Adam Wiethuechter 512 AX Enterprize 513 4947 Commercial Drive 514 Yorkville, NY 13495 515 USA 517 Email: adam.wiethuechter@axenterprize.com