idnits 2.17.1 draft-corcoran-cnsa-ipsec-profile-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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The named UI suites use SHA-512 for PRF since SHA-384 is not listed among required PRF or integrity algorithms in [RFC8247], the security level is comparable, and the difference in performance is negligible. However, SHA-384 is the official CNSA algorithm for computing a condensed representation of information. Therefore, SHA-384 implementations for PRF or integrity MAY be used. Any algorithm other than SHA-384 or SHA-512 MAY NOT be used for PRF or integrity. -- The document date (December 4, 2019) is 1576 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'This RFC' is mentioned on line 503, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Corcoran 3 Internet-Draft M. Jenkins 4 Intended status: Informational NSA 5 Expires: June 6, 2020 December 4, 2019 7 Commercial National Security Algorithm (CNSA) Suite Cryptography for 8 Internet Protocol Security (IPSec) 9 draft-corcoran-cnsa-ipsec-profile-00 11 Abstract 13 The United States Government has published the NSA Commercial 14 National Security Algorithm (CNSA) Suite, which defines cryptographic 15 algorithm policy for national security applications. This document 16 specifies the conventions for using the United States National 17 Security Agency's CNSA Suite algorithms in Internet Protocol 18 Security. It applies to the capabilities, configuration, and 19 operation of all components of US National Security Systems that 20 employ IPSec. US National Security Systems are described in NIST 21 Special Publication 800-59. It is also appropriate for all other US 22 Government systems that process high-value information. It is made 23 publicly available for use by developers and operators of these and 24 any other system deployments. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. The Commercial National Security Algorithm Suite . . . . . . 3 63 4. CNSA Compliant IPSec Overview . . . . . . . . . . . . . . . . 4 64 5. IPSec User Interface Suites . . . . . . . . . . . . . . . . . 5 65 5.1. Suite CNSA-GCM-256-ECDH-384 . . . . . . . . . . . . . . . 5 66 5.2. Suite CNSA-GCM-256-DH-3072 . . . . . . . . . . . . . . . 6 67 5.3. Suite CNSA-GCM-256-DH-4096 . . . . . . . . . . . . . . . 6 68 6. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 7 69 7. Certificates . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. IKEv2 Security Associations (SA) . . . . . . . . . . . . . . 7 71 9. The Key Exchange Payload in the IKE_SA_INIT Exchange . . . . 8 72 10. Generating Key Material for the IKE SA . . . . . . . . . . . 8 73 11. Additional Requirements . . . . . . . . . . . . . . . . . . . 9 74 12. Guidance for Applications With Long Data-Protection 75 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 15.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 This document specifies conventions for using the United States 86 National Security Agency's CNSA Suite algorithms [CNSA] in Internet 87 Protocol Security (IPSec). It defines CNSA-based user interface 88 suites ("UI suites") describing sets of security configurations for 89 Internet Key Exchange version 2 (IKEv2) and IP Encapsulating Security 90 Payload (ESP) protocol use. It applies to the capabilities, 91 configuration, and operation of all components of US National 92 Security Systems that employ IPSec. US National Security Systems are 93 described in NIST Special Publication 800-59 [SP80059]. It is also 94 appropriate for all other US Government systems that process high- 95 value information. It is made publicly available for use by 96 developers and operators of these and any other system deployments. 98 The reader is assumed to have familiarity with the following: 100 o [RFC4303], IP Encapsulating Security Payload (ESP) 102 o [RFC5280], Internet X.509 Public Key Infrastructure Certificate 103 and Certificate Revocation List (CRL) Profile 105 o [RFC7296], Internet Key Exchange Version 2 (IKEv2) 107 o [RFC8221], Cryptographic Algorithm Implementation Requirements and 108 Usage Guidance for Encapsulating Security Payload (ESP) and 109 Authentication Header (AH) 111 o [RFC8603], Commercial National Security Algorithm (CNSA) Suite 112 Certificate and Certificate Revocation List (CRL) Profile 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer 123 to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) 124 and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to 125 Diffie-Hellman key establishment. RSA refers to RSA signature. 127 3. The Commercial National Security Algorithm Suite 129 The National Security Agency (NSA) profiles commercial cryptographic 130 algorithms and protocols as part of its mission to support secure, 131 interoperable communications for US Government National Security 132 Systems. To this end, it publishes guidance both to assist with the 133 US Government transition to new algorithms, and to provide vendors - 134 and the Internet community in general - with information concerning 135 their proper use and configuration. 137 Recently, cryptographic transition plans have become overshadowed by 138 the prospect of the development of a cryptographically-relevant 139 quantum computer. NSA has established the Commercial National 140 Security Algorithm (CNSA) Suite to provide vendors and IT users near- 141 term flexibility in meeting their IA interoperability requirements. 142 The purpose behind this flexibility is to avoid vendors and customers 143 making two major transitions in a relatively short timeframe, as we 144 anticipate a need to shift to quantum-resistant cryptography in the 145 near future. 147 NSA is authoring a set of RFCs, including this one, to provide 148 updated guidance concerning the use of certain commonly available 149 commercial algorithms in IETF protocols. These RFCs can be used in 150 conjunction with other RFCs and cryptographic guidance (e.g., NIST 151 Special Publications) to properly protect Internet traffic and data- 152 at-rest for US Government National Security Systems. 154 4. CNSA Compliant IPSec Overview 156 CNSA compliant implementations for IPsec MUST use IKEv2 [RFC7296]. 158 Implementing a CNSA compliant IPSec system requires cryptographic 159 algorithm selection for both the IKEv2 and ESP protocols. The 160 following CNSA requirements apply to IPSec: 162 Encryption: 164 AES [FIPS197] (with key size 256 bits) 166 Digital Signature: 168 ECDSA [FIPS186] (using the NIST P-384 elliptic curve) 170 RSA [FIPS186] (with a modulus of 3072 bits or larger) 172 Key Establishment: 174 ECDH [SP80056A] (using the NIST P-384 elliptic curve) 176 DH [RFC3526] (with a prime modulus of 3072 or larger) 178 To facilitate selection of appropriate combinations of compliant 179 algorithms, this document provides CNSA compliant user interface 180 suites (UI Suites) [RFC4308] to implement IPSec on NSS. 182 The approved CNSA hash function for all purposes is SHA-384, as 183 defined in [FIPS180]. However, SHA-512 is recommended for PRF 184 instead of SHA-384 due to availability. See Section 8 below. 186 For CNSA Suite applications, public key certificates MUST be 187 compliant with the CNSA Suite Certificate and CRL Profile specified 188 in [RFC8603]. 190 Under certain conditions, such as applications having long-lived data 191 protection requirements, systems that do not comply with the 192 requirements of this document are acceptable; see Section 12. 194 5. IPSec User Interface Suites 196 User Interface (UI) suites are named suites that cover some typical 197 security policy options for IPsec. [RFC4308] Use of UI suites does 198 not change the IPsec protocol in any way. The following UI suites 199 provide cryptographic algorithm choices for ESP [RFC4303] and for 200 Internet Key Exchange (IKEv2) [RFC7296]. The selection of a UI Suite 201 will depend on the key exchange algorithm. The suite names indicate 202 the Advanced Encryption Standard [FIPS197] mode, AES key length 203 specified for encryption, and the key exchange algorithm. 205 Although RSA is also a CNSA approved key establishment algorithm, in 206 IPSec with IKEv2 only DH or ECDH are implemented for key exchange. 207 [RFC7296] RSA in IPSec is used only for digital signatures. See 208 Section 6. 210 ESP requires negotiation of both a confidentiality algorithm and an 211 integrity algorithm. However, authenticated encryption (AEAD) 212 algorithms do not require a separate integrity algorithm to be 213 negotiated. [RFC5116] In particular, since AES-GCM is an AEAD 214 algorithm, ESP implementing AES-GCM MUST indicate the integrity 215 algorithm NONE. [RFC7296] 217 To be CNSA compliant, IPsec implementations that use the following UI 218 suites MUST use the suite names listed below. IPsec implementations 219 SHOULD NOT use names different than those listed here for the suites 220 that are described, and MUST NOT use the names listed here for suites 221 that do not match these values. These requirements are necessary for 222 interoperability. 224 Other UI suites may be acceptable for CNSA compliance. See Section 8 225 for details. 227 5.1. Suite CNSA-GCM-256-ECDH-384 229 ESP SA: 231 Encryption: AES with 256-bit keys and 16-octet ICV in GCM mode 232 [RFC4106] 234 Integrity: NULL 236 IKEv2 SA: 238 Encryption: AEAD_AES_256_GCM - AES with 256-bit keys in GCM 239 mode [RFC5282] 241 PRF: PRF-HMAC-SHA-512 [RFC4868] 243 Integrity: NULL 245 Diffie-Hellman group: 384-bit random ECP group [RFC5903] 247 5.2. Suite CNSA-GCM-256-DH-3072 249 ESP SA: 251 Encryption: AES with 256-bit keys and 16-octet ICV in GCM mode 252 [RFC4106] 254 Integrity: NULL 256 IKEv2 SA: 258 Encryption: AEAD_AES_256_GCM - AES with 256-bit keys in GCM 259 mode [RFC5282] 261 PRF: PRF-HMAC-SHA-512 [RFC4868] 263 Integrity: NULL 265 Diffie-Hellman group: 3072 modulus [RFC3526] 267 5.3. Suite CNSA-GCM-256-DH-4096 269 ESP SA: 271 Encryption: AES with 256-bit keys and 16-octet ICV in GCM mode 272 [RFC4106] 274 Integrity: NULL 276 IKEv2 SA: 278 Encryption: AEAD_AES_256_GCM - AES with 256-bit keys in GCM 279 mode [RFC5282] 281 PRF: PRF-HMAC-SHA-512 [RFC4868] 283 Integrity: NULL 285 Diffie-Hellman group: 4096 modulus [RFC3526] 287 6. IKEv2 Authentication 289 Authentication of the IKEv2 Security Association (SA) requires 290 computation of a digital signature. To be CNSA compliant, digital 291 signatures MUST be generated with either ECDSA-384 as defined in 292 [RFC4754] or RSA with 3072-bit or greater modulus and SHA-384 as 293 defined in [RFC8017]. 295 Initiators and responders MUST be able to verify ECDSA-384 signatures 296 and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and 297 SHA-384 signatures. 299 For CNSA compliant systems, authentication methods other than 300 ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 301 3072-bit modulus or larger MUST be used for RSA. If the relying 302 party receives a message signed with any authentication method other 303 than ECDSA-384 or RSA signature it MUST return an 304 AUTHENTICATION_FAILED notification and stop processing the message. 305 If the relying party receives a message signed with RSA using less 306 than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED 307 notification and stop processing the message. 309 7. Certificates 311 To be CNSA compliant, the initiator and responder MUST use X.509 312 certificates that comply with [RFC8603]. The identity authentication 313 method MUST use an end-entity certificate provided by the 314 authenticating party and MUST NOT use the Identification Payload for 315 policy lookup. 317 8. IKEv2 Security Associations (SA) 319 Section 5 specifies three UI suites for ESP and IKEv2 Security 320 Associations. All three use AES-GCM for encryption but differ in the 321 key exchange algorithm. Galois Counter Mode (GCM) combines counter 322 (CTR) mode with a secure, parallelizable, and efficient 323 authentication mechanism. [RFC4106] Since AES-GCM is an AEAD 324 algorithm, ESP implements AES-GCM with no additional integrity 325 algorithm. [RFC7296] 327 An initiator SHOULD offer one or more of the following suites: 329 CNSA-GCM-256-ECDH-384, 331 CNSA-GCM-256-DH-3072, 333 CNSA-GCM-256-DH-4096. 335 A responder SHOULD support at least one of the three named suites. 337 Nonce construction for AES-GCM using a misuse-resistant technique 338 [RFC8452] conforms with the requirements of this document and MAY be 339 used if a Federal Information Processing Standard (FIPS) validated 340 implementation is available. 342 The named UI suites use SHA-512 for PRF since SHA-384 is not listed 343 among required PRF or integrity algorithms in [RFC8247], the security 344 level is comparable, and the difference in performance is negligible. 345 However, SHA-384 is the official CNSA algorithm for computing a 346 condensed representation of information. Therefore, SHA-384 347 implementations for PRF or integrity MAY be used. Any algorithm 348 other than SHA-384 or SHA-512 MAY NOT be used for PRF or integrity. 350 If none of the suites offered by the initiator consist solely of CNSA 351 algorithms or the named UI Suites, the responder MUST return a Notify 352 payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA 353 compliant mode. 355 9. The Key Exchange Payload in the IKE_SA_INIT Exchange 357 The key exchange payload is used to exchange Diffie-Hellman public 358 numbers as part of a Diffie-Hellman key exchange. The CNSA compliant 359 initiator and responder MUST each generate an ephemeral key pair to 360 be used in the key exchange. 362 If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected 363 for the SA, the initiator and responder both MUST generate an 364 elliptic curve (EC) key pair using the P-384 elliptic curve. The 365 ephemeral public keys MUST be stored in the key exchange payload as 366 in [RFC7296]. 368 If the Diffie-Hellman (DH) key exchange is selected for the SA, the 369 initiator and responder both MUST generate a key pair using the 370 appropriately sized MODP group as described in [RFC3526]. The size 371 of the MODP group will be determined by the selection of either a 372 3072-bit or greater modulus for the SA. 374 The key used to protect the transport of a key should be at least as 375 strong as the key being transported. 377 10. Generating Key Material for the IKE SA 379 The ECDH shared secret established during the key exchange consists 380 of the x value of the ECDH common value [RFC5903]. Because the P-384 381 elliptic curve is used, the x value is 384 bits. 383 IKEv2 [RFC7296] allows for the reuse of Diffie-Hellman exponentials 384 (i.e. private keys). However, there are security concerns related to 385 this practice. Section 5.6.3.3 of [SP80056A] states that an 386 ephemeral private key MUST be used in exactly one key establishment 387 transaction and MUST be destroyed (zeroized) as soon as possible. 388 Section 5.8 of [SP80056A] states that a Diffie-Hellman shared secret 389 must be destroyed (zeroized) immediately after its use. CNSA 390 compliant IPSec systems MUST follow the mandates in [SP80056A]. 392 Because each named UI Suite specified PRF-HMAC-SHA-512 as the PRF, 393 SKEYSEED, SK_d, SK_pi, and SK_pr MUST each be generated to be 512 394 bits long. SK_ai and SK_ar MUST be 512 bits long. SK_ei and SK_er 395 MUST be 256 bits long since the key length attribute for AES is 396 required by CNSA to be to 256. [RFC7296]. 398 11. Additional Requirements 400 The IPSec protocol AH MUST NOT be used in CNSA compliant 401 implementations. 403 ESP does not explicitly include a Diffie-Hellman key exchange. 404 [RFC8221] However, a Diffie-Hellman group MAY be negotiated for the 405 Child SA allowing peers to employ Diffie-Hellman in the 406 CREATE_CHILD_SA exchange. [RFC7296] If a transform of type 4 is 407 specified for an SA for ESP, the value of the transform MUST match 408 that of the transform used by the IKEv2 SA. 410 Per [RFC7296], if a CREATE_CHILD_SA exchange includes a KEi payload, 411 at least one of the SA offers MUST include the Diffie-Hellman group 412 of the KEi. For CNSA compliant IPSec compliant implementations, the 413 Diffie-Hellman group of the KEi MUST use the same group used in the 414 IKE_INIT_SA. 416 For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both 417 parties. The initiator of this exchange MAY include a new Diffie- 418 Hellman key; if it is included, it MUST use the same group used in 419 the IKE_INIT_SA. If the initiator of the exchange includes a Diffie- 420 Hellman key, the responder MUST include a Diffie-Hellman key, and it 421 MUST use the same group. 423 IKEv2 does not specify how Identification Payloads (Idi and IDr) in 424 the IKE_AUTH exchanges are used for policy lookup. For CNSA 425 compliant systems, the IKEv2 authentication method MUST NOT use the 426 Identification Payloads for policy lookup. Instead, the 427 authentication method MUST use an end-entity certificate provided by 428 the authenticating party. 430 The administrative user interface (UI) for a system that conforms to 431 this profile MUST allow the operator to specify a single suite. If 432 only one suite is specified in the administrative UI, the IKEv2 433 implementation MUST only offer algorithms for that one suite. 435 The administrative UI MAY allow the operator to specify more than one 436 suite; if it allows this, it MUST allow the operator to specify a 437 preferred order for the suites that are to be offered or accepted. 438 If more than one suite is specified in the administrative UI, the 439 IKEv2 implementation MUST only offer algorithms of those suites. 441 12. Guidance for Applications With Long Data-Protection Requirements 443 The CNSA mandate is to continue to use current algorithms with 444 increased security parameters, then transition to approved post- 445 quantum resilient algorithms when they are identified. However, some 446 applications have data-in-transit-protection requirements that are 447 long enough that post-quantum resilient protection must be provided 448 now. Lacking approved asymmetric post-quantum resilient 449 confidentiality algorithms, that means an approved symmetric 450 algorithm (AES-256) must be used with a pre-shared key (PSK) until 451 approved post-quantum resilient asymmetric algorithms are identified. 453 For new applications, confidentiality and integrity requirements from 454 the sections above MUST be followed, with the addition of a PSK mixed 455 in as defined in [ID.ipsecme-qr-ikev2]. Installations currently 456 using IKEv1 with PSK MUST use AES in cipher block chaining mode (AES- 457 CBC) in conjunction with a CNSA compliant integrity algorithm, and 458 transition to IKEv2 with PSK [ID.ipsecme-qr-ikev2] as soon as 459 implementations become available. 461 For all applications to which this section applies, PSK 462 authentication MUST be performed using HMAC-SHA-384 [RFC4868]. 464 Specific guidance for systems not compliant with the requirements of 465 this document, including non-GCM modes and PSK randomness, will be 466 defined in solution specific requirements appropriate to the 467 application. Details of those requirements will depend on the 468 program under which the commercial NSS solution is developed (e.g. 469 Commercial Solutions for Classified Capability Package). 471 13. Security Considerations 473 This document inherits all of the security considerations of the 474 IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754], 475 and [RFC8221]. 477 The security of a system that uses cryptography depends on both the 478 strength of the cryptographic algorithms chosen and the strength of 479 the keys used with those algorithms. The security also depends on 480 the engineering and administration of the protocol used by the system 481 to ensure that there are no non-cryptographic ways to bypass the 482 security of the overall system. 484 When selecting a mode for the AES encryption, be aware that nonce 485 reuse can result in a loss of confidentiality 487 . [RFC5116] Nonce reuse is catastrophic for GCM since it also results 488 in a loss of integrity. 490 14. IANA Considerations 492 IANA is asked to amend the registry titled "Cryptographic Suites for 493 IKEv1, IKEv2, and IPsec" located at https://www.iana.org/assignments/ 494 crypto-suites as described in this section. The registry consists of 495 a text string and an RFC number that lists the associated transforms. 496 The UI suites defined in this document are listed, with this document 497 as the RFC reference. 499 Identifier Reference 500 ===================== ====================== 501 CNSA-GCM-256-ECDH-384 [This RFC] 502 CNSA-GCM-256-DH-3072 [This RFC] 503 CNSA-GCM-256-DH-4096 [This RFC] 505 15. References 507 15.1. Normative References 509 [CNSA] Committee for National Security Systems, "Use of Public 510 Standards for Secure Information Sharing", CNSSP 15, 511 October 2016, 512 . 514 [FIPS180] National Institute of Standards and Technology, "Secure 515 Hash Standard (SHS)", Federal Information Processing 516 Standard 180-4, August 2015, 517 . 520 [FIPS186] National Institute of Standards and Technology, "Digital 521 Signature Standard (DSS)", NIST Federal Information 522 Processing Standard 186-4, July 2013, 523 . 526 [FIPS197] National Institute of Standards and Technology, "Advanced 527 Encryption Standard (AES)", Federal Information Processing 528 Standard 197, November 2001, 529 . 532 [ID.ipsecme-qr-ikev2] 533 Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov, 534 "Postquantum Preshared Keys for IKEv2", March 2019, 535 . 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 544 Diffie-Hellman groups for Internet Key Exchange (IKE)", 545 RFC 3526, DOI 10.17487/RFC3526, May 2003, 546 . 548 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 549 (GCM) in IPsec Encapsulating Security Payload (ESP)", 550 RFC 4106, DOI 10.17487/RFC4106, June 2005, 551 . 553 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 554 RFC 4303, DOI 10.17487/RFC4303, December 2005, 555 . 557 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 558 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 559 RFC 4754, DOI 10.17487/RFC4754, January 2007, 560 . 562 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 563 384, and HMAC-SHA-512 with IPsec", RFC 4868, 564 DOI 10.17487/RFC4868, May 2007, 565 . 567 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 568 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 569 . 571 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 572 Housley, R., and W. Polk, "Internet X.509 Public Key 573 Infrastructure Certificate and Certificate Revocation List 574 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 575 . 577 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 578 Algorithms with the Encrypted Payload of the Internet Key 579 Exchange version 2 (IKEv2) Protocol", RFC 5282, 580 DOI 10.17487/RFC5282, August 2008, 581 . 583 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 584 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 585 DOI 10.17487/RFC5903, June 2010, 586 . 588 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 589 Kivinen, "Internet Key Exchange Protocol Version 2 590 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 591 2014, . 593 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 594 "PKCS #1: RSA Cryptography Specifications Version 2.2", 595 RFC 8017, DOI 10.17487/RFC8017, November 2016, 596 . 598 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 599 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 600 May 2017, . 602 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 603 Kivinen, "Cryptographic Algorithm Implementation 604 Requirements and Usage Guidance for Encapsulating Security 605 Payload (ESP) and Authentication Header (AH)", RFC 8221, 606 DOI 10.17487/RFC8221, October 2017, 607 . 609 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 610 "Algorithm Implementation Requirements and Usage Guidance 611 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 612 RFC 8247, DOI 10.17487/RFC8247, September 2017, 613 . 615 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 616 Algorithm (CNSA) Suite Certificate and Certificate 617 Revocation List (CRL) Profile", RFC 8603, 618 DOI 10.17487/RFC8603, May 2019, 619 . 621 [SP80056A] 622 National Institute of Standards and Technology, 623 "Recommendation for Pair-Wise Key Establishment Schemes 624 Using Discrete Logarithm Cryptography", NIST Special 625 Publication 800-56A, Revision 3, April 2018, 626 . 629 15.2. Informative References 631 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 632 DOI 10.17487/RFC4308, December 2005, 633 . 635 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 636 Nonce Misuse-Resistant Authenticated Encryption", 637 RFC 8452, DOI 10.17487/RFC8452, April 2019, 638 . 640 [SP80059] National Institute of Standards and Technology, "Guideline 641 for Identifying an Information System as a National 642 Security System", Special Publication 800-59 , August 643 2003, . 646 Authors' Addresses 648 Laura Corcoran 649 National Security Agency 651 Email: lscorco@nsa.gov 653 Michael Jenkins 654 National Security Agency 656 Email: mjjenki@nsa.gov