idnits 2.17.1 draft-moskowitz-hip-new-crypto-00.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 15, 2019) is 1678 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) -- Looks like a reference, but probably isn't: '8032' on line 198 == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-08 Summary: 0 errors (**), 0 flaws (~~), 2 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 Intended status: Standards Track S. Card 5 Expires: March 18, 2020 A. Wiethuechter 6 AX Enterprize 7 September 15, 2019 9 New Cryptographic Algorithms for HIP 10 draft-moskowitz-hip-new-crypto-00 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 18, 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 . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8.1. Keymat vulnerabilities . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 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 [8032] (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 KMAC[128|256](salt, 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. 361 S is the byte string 01001011 || 01000100 || 01000110, which 362 represents the sequence of characters "K", "D", and "F" in 8-bit 363 ASCII. 365 Salt is derived as defined in [RFC7401] or [I-D.ietf-hip-dex]. There 366 are special security considerations for IKM per [RFC7748]. The two 367 HIs MUST be used in constructing IKM as follows: 369 IKM = HI-I | Diffie-Hellman secret | HI-R 371 6. Using Keccak for a Pseudorandom Function 373 Appendix B of NIST SP 800-185 [NIST.SP.800-185] defines how to use 374 SHAKE, cSHAKE, or KMAC as a PRF. 376 7. IANA Considerations 378 IANA will need to make the following changes to the "Host Identity 379 Protocol (HIP) Parameters" registries: 381 Diffie Hellman: This document defines the new Curve25519 and 382 Curve448 for the Diffie-Hellman exchange (see Section 3.1.1). 384 Host ID: This document defines the new EdDSA Host ID (see 385 Section 3.2.1). 387 HIT Suite ID: This document defines the new HIT Suite of EdDSA/ 388 cSHAKE (see Section 3.2.2). 390 HIP Cipher: This document defines the new Keyak ciphers for HIP 391 encrypted parameters (see Section 3.4.1). 393 8. Security Considerations 395 8.1. Keymat vulnerabilities 397 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 398 for key derivation: 400 Designers using these curves should be aware that for each public 401 key, there are several publicly computable public keys that are 402 equivalent to it, i.e., they produce the same shared secrets. Thus 403 using a public key as an identifier and knowledge of a shared secret 404 as proof of ownership (without including the public keys in the key 405 derivation) might lead to subtle vulnerabilities. 407 This applies to [I-D.ietf-hip-dex], but may have broader 408 consequences. Thus the two Host IDs are included with the Diffie- 409 Hellman secret. 411 9. Acknowledgments 413 TBD 415 10. References 417 10.1. Normative References 419 [NIST.FIPS.202] 420 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 421 Extendable-Output Functions", National Institute of 422 Standards and Technology report, 423 DOI 10.6028/nist.fips.202, July 2015. 425 [NIST.SP.800-185] 426 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 427 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 428 National Institute of Standards and Technology report, 429 DOI 10.6028/nist.sp.800-185, December 2016. 431 [NIST.SP.800-56Cr1] 432 Barker, E., Chen, L., and R. Davis, "Recommendation for 433 key-derivation methods in key-establishment schemes", 434 National Institute of Standards and Technology report, 435 DOI 10.6028/nist.sp.800-56cr1, April 2018. 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 443 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 444 May 2017, . 446 10.2. Informative References 448 [I-D.ietf-hip-dex] 449 Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 450 (DEX)", draft-ietf-hip-dex-08 (work in progress), June 451 2019. 453 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 454 R. Van Keer, "The Keccak", 455 . 457 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 458 Hashing for Message Authentication", RFC 2104, 459 DOI 10.17487/RFC2104, February 1997, 460 . 462 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 463 Key Derivation Function (HKDF)", RFC 5869, 464 DOI 10.17487/RFC5869, May 2010, 465 . 467 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 468 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 469 RFC 7401, DOI 10.17487/RFC7401, April 2015, 470 . 472 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 473 for Security", RFC 7748, DOI 10.17487/RFC7748, January 474 2016, . 476 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 477 Signature Algorithm (EdDSA)", RFC 8032, 478 DOI 10.17487/RFC8032, January 2017, 479 . 481 Authors' Addresses 483 Robert Moskowitz 484 HTT Consulting 485 Oak Park, MI 48237 486 USA 488 Email: rgm@labs.htt-consult.com 490 Stuart W. Card 491 AX Enterprize 492 4947 Commercial Drive 493 Yorkville, NY 13495 494 USA 496 Email: stu.card@axenterprize.com 498 Adam Wiethuechter 499 AX Enterprize 500 4947 Commercial Drive 501 Yorkville, NY 13495 502 USA 504 Email: adam.wiethuechter@axenterprize.com