idnits 2.17.1 draft-corcoran-cnsa-ipsec-profile-06.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 (11 January 2022) is 836 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4868' is defined on line 545, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: 15 July 2022 11 January 2022 7 Commercial National Security Algorithm (CNSA) Suite Cryptography for 8 Internet Protocol Security (IPsec) 9 draft-corcoran-cnsa-ipsec-profile-06 11 Abstract 13 The United States Government has published the National Security 14 Agency's Commercial National Security Algorithm (CNSA) Suite, which 15 defines cryptographic algorithm policy for national security 16 applications. This document specifies the conventions for using the 17 United States National Security Agency's CNSA Suite algorithms in 18 Internet Protocol Security. It applies to the capabilities, 19 configuration, and operation of all components of US National 20 Security Systems that employ IPsec. US National Security Systems are 21 described in NIST Special Publication 800-59. It is also appropriate 22 for all other US Government systems that process high-value 23 information. It is made publicly available for use by developers and 24 operators of these and 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 15 July 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The Commercial National Security Algorithm Suite . . . . . . 3 62 4. CNSA Compliant IPsec Overview . . . . . . . . . . . . . . . . 4 63 5. IPsec User Interface Suites . . . . . . . . . . . . . . . . . 5 64 5.1. Suite CNSA-GCM-256-ECDH-384 . . . . . . . . . . . . . . . 5 65 5.2. Suite CNSA-GCM-256-DH-3072 . . . . . . . . . . . . . . . 6 66 5.3. Suite CNSA-GCM-256-DH-4096 . . . . . . . . . . . . . . . 6 67 6. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 6 68 7. Certificates . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. IKEv2 Security Associations (SA) . . . . . . . . . . . . . . 7 70 9. The Key Exchange Payload in the IKE_SA_INIT Exchange . . . . 8 71 10. Generating Key Material for the IKE SA . . . . . . . . . . . 8 72 11. Additional Requirements . . . . . . . . . . . . . . . . . . . 8 73 12. Guidance for Applications With Long Data-Protection 74 Requirements . . . . . . . . . . . . . . . . . . . . . . 9 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 15.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 This document specifies conventions for using the United States 85 National Security Agency's Commercial National Security Algorithm 86 (CNSA) Suite algorithms [CNSA] in Internet Protocol Security (IPsec). 87 It defines CNSA-based user interface suites ("UI suites") describing 88 sets of security configurations for Internet Key Exchange version 2 89 (IKEv2) and IP Encapsulating Security Payload (ESP) protocol use, and 90 specifies certain other constraints with respect to algorithm 91 selection and configuration. It applies to the capabilities, 92 configuration, and operation of all components of US National 93 Security Systems that employ IPsec. US National Security Systems are 94 described in NIST Special Publication 800-59 [SP80059]. It is also 95 appropriate for all other US Government systems that process high- 96 value information. It is made publicly available for use by 97 developers and operators of these and any other system deployments. 99 The reader is assumed to have familiarity with the following: 101 [RFC4303], IP Encapsulating Security Payload (ESP) 103 [RFC5280], Internet X.509 Public Key Infrastructure Certificate 104 and Certificate Revocation List (CRL) Profile 106 [RFC7296], Internet Key Exchange Version 2 (IKEv2) 108 [RFC8221], Cryptographic Algorithm Implementation Requirements and 109 Usage Guidance for Encapsulating Security Payload (ESP) and 110 Authentication Header (AH) 112 [RFC8603], Commercial National Security Algorithm (CNSA) Suite 113 Certificate and Certificate Revocation List (CRL) Profile 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer 124 to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) 125 and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to 126 Diffie-Hellman key establishment. RSA refers to RSA signature. 128 3. The Commercial National Security Algorithm Suite 130 The National Security Agency (NSA) profiles commercial cryptographic 131 algorithms and protocols as part of its mission to support secure, 132 interoperable communications for US Government National Security 133 Systems. To this end, it publishes guidance both to assist with the 134 US Government transition to new algorithms, and to provide vendors - 135 and the Internet community in general - with information concerning 136 their proper use and configuration. 138 Recently, cryptographic transition plans have become overshadowed by 139 the prospect of the development of a cryptographically-relevant 140 quantum computer. NSA has established the Commercial National 141 Security Algorithm (CNSA) Suite to provide vendors and IT users near- 142 term flexibility in meeting their information assurance 143 interoperability requirements. The purpose behind this flexibility 144 is to avoid vendors and customers making two major transitions in a 145 relatively short timeframe, as we anticipate a need to shift to 146 quantum-resistant cryptography in the near future. 148 NSA is authoring a set of RFCs, including this one, to provide 149 updated guidance concerning the use of certain commonly available 150 commercial algorithms in IETF protocols. These RFCs can be used in 151 conjunction with other RFCs and cryptographic guidance (e.g., NIST 152 Special Publications) to properly protect Internet traffic and data- 153 at-rest for US Government National Security Systems. 155 4. CNSA Compliant IPsec Overview 157 CNSA compliant implementations for IPsec MUST use IKEv2 [RFC7296]. 159 Implementing a CNSA compliant IPsec system requires cryptographic 160 algorithm selection for both the IKEv2 and ESP protocols. The 161 following CNSA requirements apply to IPsec: 163 Encryption: 164 AES [FIPS197] (with key size 256 bits) 166 Digital Signature: 167 ECDSA [FIPS186] (using the NIST P-384 elliptic curve) 168 RSA [FIPS186] (with a modulus of 3072 bits or larger) 170 Key Establishment: 171 ECDH [SP80056A] (using the NIST P-384 elliptic curve) 172 DH [RFC3526] (with a prime modulus of 3072 or larger) 174 To facilitate selection of appropriate combinations of compliant 175 algorithms, this document provides CNSA compliant user interface 176 suites (UI Suites) [RFC4308] to implement IPsec on NSS. 178 The approved CNSA hash function for all purposes is SHA-384, as 179 defined in [FIPS180]. However, PRF_HMAC_SHA-512 is specified for the 180 IKEv2 PRF instead of PRF_HMAC_SHA-384 due to availability. See 181 Section 8 below. 183 For CNSA Suite applications, public key certificates MUST be 184 compliant with the CNSA Suite Certificate and CRL Profile specified 185 in [RFC8603]. 187 Under certain conditions, such as applications having long-lived data 188 protection requirements, systems that do not comply with the 189 requirements of this document are acceptable; see Section 12. 191 5. IPsec User Interface Suites 193 User Interface (UI) suites [RFC4308] are named suites that cover some 194 typical security policy options for IPsec. Use of UI suites does not 195 change the IPsec protocol in any way. The following UI suites 196 provide cryptographic algorithm choices for ESP [RFC4303] and for 197 Internet Key Exchange (IKEv2) [RFC7296]. The selection of a UI Suite 198 will depend on the key exchange algorithm. The suite names indicate 199 the Advanced Encryption Standard [FIPS197] mode, AES key length 200 specified for encryption, and the key exchange algorithm. 202 Although RSA is also a CNSA approved key establishment algorithm, in 203 IPsec with IKEv2 [RFC7296] only DH or ECDH are implemented for key 204 exchange. RSA in IPsec is used only for digital signatures. See 205 Section 6. 207 ESP requires negotiation of both a confidentiality algorithm and an 208 integrity algorithm. However, authenticated encryption (AEAD) 209 algorithms [RFC5116] do not require a separate integrity algorithm to 210 be negotiated. In particular, since AES-GCM is an AEAD algorithm, 211 ESP implementing AES-GCM MUST either offer no integrity algorithm, or 212 indicate the single integrity algorithm NONE (see Section 3.3 of 213 [RFC7296]). 215 To be CNSA compliant, IPsec implementations that use the following UI 216 suites MUST use the suite names listed below. IPsec implementations 217 SHOULD NOT use names different than those listed here for the suites 218 that are described, and MUST NOT use the names listed here for suites 219 that do not match these values. These requirements are necessary for 220 interoperability. 222 Transform names are as listed in the IANA registry for Internet Key 223 Exchange Version 2 (IKEv2) Parameters. Definitions of the transforms 224 are contained in the references specified in that registry. 226 Other UI suites may be acceptable for CNSA compliance. See Section 8 227 for details. 229 5.1. Suite CNSA-GCM-256-ECDH-384 231 ESP SA: 232 Encryption: ENCR_AES_GCM_16 (with key size 256 bits) 233 Integrity: NONE 234 IKEv2 SA: 235 Encryption: ENCR_AES_GCM_16 (with key size 256 bits) 236 PRF: PRF_HMAC_SHA2_512 237 Integrity: NONE 238 Diffie-Hellman group: 384-bit random ECP group 240 5.2. Suite CNSA-GCM-256-DH-3072 242 ESP SA: 243 Encryption: ENCR_AES_GCM_16 (with key size 256 bits) 244 Integrity: NONE 245 IKEv2 SA: 246 Encryption: ENCR_AES_GCM_16 (with key size 256 bits) 247 PRF: PRF_HMAC_SHA2_512 248 Integrity: NONE 249 Diffie-Hellman group: 3072-bit MODP Group 251 5.3. Suite CNSA-GCM-256-DH-4096 253 ESP SA: 254 Encryption: ENCR_AES_GCM_16 (with key size 256 bits) 255 Integrity: NONE 256 IKEv2 SA: 257 Encryption: ENCR_AES_GCM_16 (with key size 256 bits) 258 PRF: PRF_HMAC_SHA2_512 259 Integrity: NONE 260 Diffie-Hellman group: 4096-bit MODP Group 262 6. IKEv2 Authentication 264 Authentication of the IKEv2 Security Association (SA) requires 265 computation of a digital signature. To be CNSA compliant, digital 266 signatures MUST be generated with either ECDSA-384 as defined in 267 [RFC4754] or RSA with 3072-bit or greater modulus and SHA-384 as 268 defined in [RFC8017]. (For applications with long data-protection 269 requirements, somewhat different rules apply; see Section 12.) 271 Initiators and responders MUST be able to verify ECDSA-384 signatures 272 and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and 273 SHA-384 signatures. 275 For CNSA compliant systems, authentication methods other than 276 ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 277 3072-bit modulus or larger MUST be used for RSA. If the relying 278 party receives a message signed with any authentication method other 279 than ECDSA-384 or RSA signature it MUST return an 280 AUTHENTICATION_FAILED notification and stop processing the message. 281 If the relying party receives a message signed with RSA using less 282 than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED 283 notification and stop processing the message. 285 7. Certificates 287 To be CNSA compliant, the initiator and responder MUST use X.509 288 certificates that comply with [RFC8603]. Peer authentication 289 decisions must be based on the Subject or Subject Alternative Name 290 from the certificate that contains the key used to validate the 291 signature in the Authentication Payload defined in Section 3.8 of 292 [RFC7296], rather than the Identification Data from the 293 Identification Payload that is used to look up policy. 295 8. IKEv2 Security Associations (SA) 297 Section 5 specifies three UI suites for ESP and IKEv2 Security 298 Associations. All three use AES-GCM for encryption but differ in the 299 key exchange algorithm. Galois Counter Mode (GCM) [RFC4106] combines 300 counter (CTR) mode with a secure, parallelizable, and efficient 301 authentication mechanism. Since AES-GCM is an AEAD algorithm, ESP 302 implements AES-GCM with no additional integrity algorithm (see 303 Section 3.3 of [RFC7296]). 305 An initiator proposal SHOULD be constructed from one or more of the 306 following suites: 308 CNSA-GCM-256-ECDH-384, 309 CNSA-GCM-256-DH-3072, 310 CNSA-GCM-256-DH-4096. 312 A responder SHOULD accept proposals constructed from at least one of 313 the three named suites. Other UI suites may result in acceptable 314 proposals (such as those based on PRF_HMAC_SHA2_384); however, these 315 are provided to promote interoperability. 317 Nonce construction for AES-GCM using a misuse-resistant technique 318 [RFC8452] conforms with the requirements of this document and MAY be 319 used if a Federal Information Processing Standard (FIPS) validated 320 implementation is available. 322 The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF 323 transform as PRF_HMAC_SHA2_384 is not listed among required PRF 324 transforms in [RFC8247]; therefore, implementation of the latter is 325 likely to be scarce. The security level of PRF_HMAC_SHA2_512 is 326 comparable, and the difference in performance is negligible. 327 However, SHA-384 is the official CNSA algorithm for computing a 328 condensed representation of information. Therefore, the 329 PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to 330 initiator and responder. Any PRF transform other than 331 PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used. 333 If none of the proposals offered by the initiator consist solely of 334 transforms based on CNSA algorithms (such as those in the UI Suites 335 defined in Section 5, the responder MUST return a Notify payload with 336 the error NO_PROPOSAL_CHOSEN when operating in CNSA compliant mode. 338 9. The Key Exchange Payload in the IKE_SA_INIT Exchange 340 The key exchange payload is used to exchange Diffie-Hellman public 341 numbers as part of a Diffie-Hellman key exchange. The CNSA compliant 342 initiator and responder MUST each generate an ephemeral key pair to 343 be used in the key exchange. 345 If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected 346 for the SA, the initiator and responder both MUST generate an 347 elliptic curve (EC) key pair using the P-384 elliptic curve. The 348 ephemeral public keys MUST be stored in the key exchange payload as 349 in [RFC7296]. 351 If the Diffie-Hellman (DH) key exchange is selected for the SA, the 352 initiator and responder both MUST generate a key pair using the 353 appropriately sized MODP group as described in [RFC3526]. The size 354 of the MODP group will be determined by the selection of either a 355 3072-bit or greater modulus for the SA. 357 10. Generating Key Material for the IKE SA 359 As noted in Section 7 of [RFC5903], the shared secret result of a 360 ECDH key exchange is the 384 bit x value of the ECDH common value. 361 The shared secret result of a DH key exchange is the number of octets 362 needed to accomodate the prime (e.g. 384 octets for 3072 MODP) with 363 leading zeros as necessary, as described in Section 2.1.2 of 364 [RFC2631]. 366 IKEv2, Section 2.12 [RFC7296] allows for the reuse of Diffie-Hellman 367 private keys. However, there are security concerns related to this 368 practice. Section 5.6.3.3 of [SP80056A] states that an ephemeral 369 private key MUST be used in exactly one key establishment transaction 370 and MUST be destroyed (zeroized) as soon as possible. Section 5.8 of 371 [SP80056A] states that a Diffie-Hellman shared secret must be 372 destroyed (zeroized) immediately after its use. CNSA compliant IPsec 373 systems MUST follow the mandates in [SP80056A]. 375 11. Additional Requirements 377 The IPsec protocol AH MUST NOT be used in CNSA compliant 378 implementations. 380 A Diffie-Hellman group MAY be negotiated for a Child SA as described 381 in Section 1.3 of [RFC7296] allowing peers to employ Diffie-Hellman 382 in the CREATE_CHILD_SA exchange. If a transform of type 4 is 383 specified for an SA for ESP, the value of that transform MUST match 384 the value of the transform used by the IKEv2 SA. 386 Per [RFC7296], if a CREATE_CHILD_SA exchange includes a KEi payload, 387 at least one of the SA offers MUST include the Diffie-Hellman group 388 of the KEi. For CNSA compliant IPsec compliant implementations, the 389 Diffie-Hellman group of the KEi MUST use the same group used in the 390 IKE_INIT_SA. 392 For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both 393 parties. The initiator of this exchange MAY include a new Diffie- 394 Hellman key; if it is included, it MUST use the same group used in 395 the IKE_INIT_SA. If the initiator of the exchange includes a Diffie- 396 Hellman key, the responder MUST include a Diffie-Hellman key, and it 397 MUST use the same group. 399 For CNSA compliant systems, the IKEv2 authentication method MUST use 400 an end-entity certificate provided by the authenticating party. 401 Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST 402 NOT be used for the IKEv2 authentication method , but may be used for 403 policy lookup. 405 The administrative user interface (UI) for a system that conforms to 406 this profile MUST allow the operator to specify a single suite. If 407 only one suite is specified in the administrative UI, the IKEv2 408 implementation MUST only offer algorithms for that one suite. 410 The administrative UI MAY allow the operator to specify more than one 411 suite; if it allows this, it MUST allow the operator to specify a 412 preferred order for the suites that are to be offered or accepted. 413 If more than one suite is specified in the administrative UI, the 414 IKEv2 implementation MUST only offer algorithms of those suites. 415 (Note that although this document does not define a UI suite 416 specifying PRF_HMAC_SHA2_384, a proposal containing such a transform 417 is CNSA compliant.) 419 12. Guidance for Applications With Long Data-Protection Requirements 421 The CNSA mandate is to continue to use current algorithms with 422 increased security parameters, then transition to approved post- 423 quantum resilient algorithms when they are identified. However, some 424 applications have data-in-transit-protection requirements that are 425 long enough that post-quantum resilient protection must be provided 426 now. Lacking approved asymmetric post-quantum resilient 427 confidentiality algorithms, that means approved symmetric techniques 428 must be used as described in this section until approved post-quantum 429 resilient asymmetric algorithms are identified. 431 For new applications, confidentiality and integrity requirements from 432 the sections above MUST be followed, with the addition of a PSK mixed 433 in as defined in [RFC8784]. 435 Installations currently using IKEv1 with PSK MUST use AES in cipher 436 block chaining mode (AES-CBC) in conjunction with a CNSA compliant 437 integrity algorithm (e.g. AUTH_HMAC_SHA2_384_192), and transition to 438 IKEv2 with PSK [RFC8784] as soon as implementations become available. 440 Specific guidance for systems not compliant with the requirements of 441 this document, including non-GCM modes and PSK length and randomness, 442 will be defined in solution specific requirements appropriate to the 443 application. Details of those requirements will depend on the 444 program under which the commercial NSS solution is developed (e.g. 445 Commercial Solutions for Classified Capability Package). 447 13. Security Considerations 449 This document inherits all of the security considerations of the 450 IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754], 451 and [RFC8221]. 453 The security of a system that uses cryptography depends on both the 454 strength of the cryptographic algorithms chosen and the strength of 455 the keys used with those algorithms. The security also depends on 456 the engineering and administration of the protocol used by the system 457 to ensure that there are no non-cryptographic ways to bypass the 458 security of the overall system. 460 When selecting a mode for the AES encryption [RFC5116] , be aware 461 that nonce reuse can result in a loss of confidentiality. Nonce 462 reuse is catastrophic for GCM since it also results in a loss of 463 integrity. 465 14. IANA Considerations 467 IANA is asked to amend the registry titled "Cryptographic Suites for 468 IKEv1, IKEv2, and IPsec" located at https://www.iana.org/assignments/ 469 crypto-suites as described in this section. The registry consists of 470 a text string and an RFC number that lists the associated transforms. 471 The UI suites defined in this document are listed, with this document 472 as the RFC reference. 474 +-----------------------+--------------------------------+ 475 | Identifier | Reference | 476 +-----------------------+--------------------------------+ 477 | CNSA-GCM-256-ECDH-384 | [this document when published] | 478 +-----------------------+--------------------------------+ 479 | CNSA-GCM-256-DH-3072 | [this document when published] | 480 +-----------------------+--------------------------------+ 481 | CNSA-GCM-256-DH-4096 | [this document when published] | 482 +-----------------------+--------------------------------+ 484 Table 1 486 15. References 488 15.1. Normative References 490 [CNSA] Committee for National Security Systems, "Use of Public 491 Standards for Secure Information Sharing", CNSSP 15, 492 October 2016, 493 . 495 [FIPS180] National Institute of Standards and Technology, "Secure 496 Hash Standard (SHS)", Federal Information Processing 497 Standard 180-4, August 2015, 498 . 501 [FIPS186] National Institute of Standards and Technology, "Digital 502 Signature Standard (DSS)", NIST Federal Information 503 Processing Standard 186-4, July 2013, 504 . 507 [FIPS197] National Institute of Standards and Technology, "Advanced 508 Encryption Standard (AES)", Federal Information Processing 509 Standard 197, November 2001, 510 . 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 519 RFC 2631, DOI 10.17487/RFC2631, June 1999, 520 . 522 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 523 Diffie-Hellman groups for Internet Key Exchange (IKE)", 524 RFC 3526, DOI 10.17487/RFC3526, May 2003, 525 . 527 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 528 (GCM) in IPsec Encapsulating Security Payload (ESP)", 529 RFC 4106, DOI 10.17487/RFC4106, June 2005, 530 . 532 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 533 RFC 4303, DOI 10.17487/RFC4303, December 2005, 534 . 536 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 537 DOI 10.17487/RFC4308, December 2005, 538 . 540 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 541 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 542 RFC 4754, DOI 10.17487/RFC4754, January 2007, 543 . 545 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 546 384, and HMAC-SHA-512 with IPsec", RFC 4868, 547 DOI 10.17487/RFC4868, May 2007, 548 . 550 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 551 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 552 . 554 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 555 Housley, R., and W. Polk, "Internet X.509 Public Key 556 Infrastructure Certificate and Certificate Revocation List 557 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 558 . 560 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 561 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 562 DOI 10.17487/RFC5903, June 2010, 563 . 565 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 566 Kivinen, "Internet Key Exchange Protocol Version 2 567 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 568 2014, . 570 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 571 "PKCS #1: RSA Cryptography Specifications Version 2.2", 572 RFC 8017, DOI 10.17487/RFC8017, November 2016, 573 . 575 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 576 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 577 May 2017, . 579 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 580 Kivinen, "Cryptographic Algorithm Implementation 581 Requirements and Usage Guidance for Encapsulating Security 582 Payload (ESP) and Authentication Header (AH)", RFC 8221, 583 DOI 10.17487/RFC8221, October 2017, 584 . 586 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 587 "Algorithm Implementation Requirements and Usage Guidance 588 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 589 RFC 8247, DOI 10.17487/RFC8247, September 2017, 590 . 592 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 593 Algorithm (CNSA) Suite Certificate and Certificate 594 Revocation List (CRL) Profile", RFC 8603, 595 DOI 10.17487/RFC8603, May 2019, 596 . 598 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 599 "Mixing Preshared Keys in the Internet Key Exchange 600 Protocol Version 2 (IKEv2) for Post-quantum Security", 601 RFC 8784, DOI 10.17487/RFC8784, June 2020, 602 . 604 [SP80056A] National Institute of Standards and Technology, 605 "Recommendation for Pair-Wise Key Establishment Schemes 606 Using Discrete Logarithm Cryptography", NIST Special 607 Publication 800-56A, Revision 3, April 2018, 608 . 611 15.2. Informative References 613 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 614 Nonce Misuse-Resistant Authenticated Encryption", 615 RFC 8452, DOI 10.17487/RFC8452, April 2019, 616 . 618 [SP80059] National Institute of Standards and Technology, "Guideline 619 for Identifying an Information System as a National 620 Security System", Special Publication 800-59 , August 621 2003, . 624 Authors' Addresses 626 Laura Corcoran 627 National Security Agency 629 Email: lscorco@nsa.gov 631 Michael Jenkins 632 National Security Agency 634 Email: mjjenki@cyber.nsa.gov