idnits 2.17.1 draft-moskowitz-hip-new-crypto-02.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 (October 3, 2019) is 1666 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: April 5, 2020 A. Wiethuechter 6 AX Enterprize 7 October 3, 2019 9 New Cryptographic Algorithms for HIP 10 draft-moskowitz-hip-new-crypto-02 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 April 5, 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, [I-D.ietf-hip-dex], is 310 recommended. Keyak is a candidate in the NIST Lightweight 311 Cryptography competition and is consistent with the overall approach 312 in this addendum to use Keccak functions for simplicity in design and 313 implementation. 315 3.4.1. HIP_CIPHER 317 The HIP_CIPHER parameter values for Keyak are: 319 hip_cipher 320 Suite ID Value 322 RIVER KEYAK 6 (Keyak) 323 LAKE KEYAK 7 (Keyak) 325 For use as the HIP Cipher, the TAG generated in Keyak is length 0. 326 The Keyak SUV is the key plus IV specified for the encrypted 327 parameter. River Keyak MAY be used for [Keyak_Cipher], in place of 328 AES-CTR. 330 Lake Keyak can provide 256 bits of security by following the 331 recommendations for the Keyak cipher. 333 4. Generating a HIT from an HI 335 The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation 336 method described in section 3.2 of [RFC7401]. The XOF functionality 337 of cSHAKE produces an output of L bits. This replaces the Encode_96 338 function in the ORCHID generation. 340 For identities that are EdDSA public keys, the ORCHID input consists 341 of the public key encoding as specified for the Host Identity field 342 of the HOST_ID parameter (see Section 3.2.1). Since L is less than 343 128, cSHAKE128 is used for all EdDSA curve sizes: 345 cSHAKE128(EdDSA public key, 96, "", Context ID) 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 [NIST.SP.800-56Cr1], 355 Section 4.1, Option 3: 357 OKM = KMAC[128|256](salt | info, IKM, L, S) 359 L is the derived key bit length. Since 4 HIP keys are "drawn" from 360 this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp. 361 606-637 [ASIACRYPT-2017] each of these derived keys will have the 362 same strength as the Diffie-Hellman shared secret. 364 S is the byte string 01001011 || 01000100 || 01000110, which 365 represents the sequence of characters "K", "D", and "F" in 8-bit 366 ASCII. 368 Salt and info are derived as defined in [RFC7401] or 369 [I-D.ietf-hip-dex]. There are special security considerations for 370 IKM per [RFC7748]. The two HIs MUST be used in constructing IKM as 371 follows: 373 IKM = Diffie-Hellman secret | HI-R | HI-I 375 These are separately DER encoded. 377 6. Using Keccak for a Pseudorandom Function 379 Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use 380 SHAKE, cSHAKE, or KMAC as a PRF. 382 7. IANA Considerations 384 IANA will need to make the following changes to the "Host Identity 385 Protocol (HIP) Parameters" registries: 387 Diffie Hellman: This document defines the new Curve25519 and 388 Curve448 for the Diffie-Hellman exchange (see Section 3.1.1). 390 Host ID: This document defines the new EdDSA Host ID (see 391 Section 3.2.1). 393 HIT Suite ID: This document defines the new HIT Suite of EdDSA/ 394 cSHAKE (see Section 3.2.2). 396 HIP Cipher: This document defines the new Keyak ciphers for HIP 397 encrypted parameters (see Section 3.4.1). 399 8. Security Considerations 401 8.1. Keymat vulnerabilities 403 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 404 for key derivation: 406 Designers using these curves should be aware that for each public 407 key, there are several publicly computable public keys that are 408 equivalent to it, i.e., they produce the same shared secrets. Thus 409 using a public key as an identifier and knowledge of a shared secret 410 as proof of ownership (without including the public keys in the key 411 derivation) might lead to subtle vulnerabilities. 413 This applies to [I-D.ietf-hip-dex], but may have broader 414 consequences. Thus the two Host IDs are included with the Diffie- 415 Hellman secret. 417 9. Acknowledgments 419 Quynh Dang of NIST gave considerable guidance on using Keccak and the 420 NIST supporting documents. Joan Deamen of the Keccak team was 421 especially helpful in many aspects of using Keccak, particularly with 422 the KEYMAT section and the strength of the derived keys. 424 10. References 426 10.1. Normative References 428 [NIST.FIPS.202] 429 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 430 Extendable-Output Functions", National Institute of 431 Standards and Technology report, 432 DOI 10.6028/nist.fips.202, July 2015. 434 [NIST.SP.800-185] 435 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 436 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 437 National Institute of Standards and Technology report, 438 DOI 10.6028/nist.sp.800-185, December 2016. 440 [NIST.SP.800-56Cr1] 441 Barker, E., Chen, L., and R. Davis, "Recommendation for 442 key-derivation methods in key-establishment schemes", 443 National Institute of Standards and Technology report, 444 DOI 10.6028/nist.sp.800-56cr1, April 2018. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 452 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 453 May 2017, . 455 10.2. Informative References 457 [ASIACRYPT-2017] 458 Daemen, J., Mennink, B., and G. Van Assche, "Full-State 459 Keyed Duplex with Built-In Multi-user Support", Advances 460 in Cryptology - ASIACRYPT 2017 pp. 606-637, 461 DOI 10.1007/978-3-319-70697-9_21, 2017. 463 [I-D.ietf-hip-dex] 464 Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 465 (DEX)", draft-ietf-hip-dex-09 (work in progress), 466 September 2019. 468 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 469 R. Van Keer, "The Keccak Function", 470 . 472 [Keyak_Cipher] 473 Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 474 R. Van Keer, "The Keyak Cipher", 475 . 477 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 478 Hashing for Message Authentication", RFC 2104, 479 DOI 10.17487/RFC2104, February 1997, 480 . 482 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 483 Key Derivation Function (HKDF)", RFC 5869, 484 DOI 10.17487/RFC5869, May 2010, 485 . 487 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 488 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 489 RFC 7401, DOI 10.17487/RFC7401, April 2015, 490 . 492 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 493 for Security", RFC 7748, DOI 10.17487/RFC7748, January 494 2016, . 496 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 497 Signature Algorithm (EdDSA)", RFC 8032, 498 DOI 10.17487/RFC8032, January 2017, 499 . 501 Authors' Addresses 503 Robert Moskowitz 504 HTT Consulting 505 Oak Park, MI 48237 506 USA 508 Email: rgm@labs.htt-consult.com 510 Stuart W. Card 511 AX Enterprize 512 4947 Commercial Drive 513 Yorkville, NY 13495 514 USA 516 Email: stu.card@axenterprize.com 517 Adam Wiethuechter 518 AX Enterprize 519 4947 Commercial Drive 520 Yorkville, NY 13495 521 USA 523 Email: adam.wiethuechter@axenterprize.com