idnits 2.17.1 draft-corcoran-cnsa-ipsec-profile-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 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For CNSA compliant systems, the IKEv2 authentication method MUST use an end-entity certificate provided by the authenticating party. Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST not be used for the IKEv2 authentication method , but may be used for policy lookup. -- The document date (24 May 2021) is 1067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'This RFC' is mentioned on line 463, but not defined == Unused Reference: 'RFC5282' is defined on line 534, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 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: 25 November 2021 24 May 2021 7 Commercial National Security Algorithm (CNSA) Suite Cryptography for 8 Internet Protocol Security (IPSec) 9 draft-corcoran-cnsa-ipsec-profile-02 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 25 November 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified 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 CNSA Suite algorithms [CNSA] in Internet 86 Protocol Security (IPSec). It defines CNSA-based user interface 87 suites ("UI suites") describing sets of security configurations for 88 Internet Key Exchange version 2 (IKEv2) and IP Encapsulating Security 89 Payload (ESP) protocol use. It applies to the capabilities, 90 configuration, and operation of all components of US National 91 Security Systems that employ IPSec. US National Security Systems are 92 described in NIST Special Publication 800-59 [SP80059]. It is also 93 appropriate for all other US Government systems that process high- 94 value information. It is made publicly available for use by 95 developers and operators of these and any other system deployments. 97 The reader is assumed to have familiarity with the following: 99 [RFC4303], IP Encapsulating Security Payload (ESP) 101 [RFC5280], Internet X.509 Public Key Infrastructure Certificate 102 and Certificate Revocation List (CRL) Profile 104 [RFC7296], Internet Key Exchange Version 2 (IKEv2) 106 [RFC8221], Cryptographic Algorithm Implementation Requirements and 107 Usage Guidance for Encapsulating Security Payload (ESP) and 108 Authentication Header (AH) 110 [RFC8603], Commercial National Security Algorithm (CNSA) Suite 111 Certificate and Certificate Revocation List (CRL) Profile 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer 122 to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) 123 and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to 124 Diffie-Hellman key establishment. RSA refers to RSA signature. 126 3. The Commercial National Security Algorithm Suite 128 The National Security Agency (NSA) profiles commercial cryptographic 129 algorithms and protocols as part of its mission to support secure, 130 interoperable communications for US Government National Security 131 Systems. To this end, it publishes guidance both to assist with the 132 US Government transition to new algorithms, and to provide vendors - 133 and the Internet community in general - with information concerning 134 their proper use and configuration. 136 Recently, cryptographic transition plans have become overshadowed by 137 the prospect of the development of a cryptographically-relevant 138 quantum computer. NSA has established the Commercial National 139 Security Algorithm (CNSA) Suite to provide vendors and IT users near- 140 term flexibility in meeting their IA interoperability requirements. 141 The purpose behind this flexibility is to avoid vendors and customers 142 making two major transitions in a relatively short timeframe, as we 143 anticipate a need to shift to quantum-resistant cryptography in the 144 near future. 146 NSA is authoring a set of RFCs, including this one, to provide 147 updated guidance concerning the use of certain commonly available 148 commercial algorithms in IETF protocols. These RFCs can be used in 149 conjunction with other RFCs and cryptographic guidance (e.g., NIST 150 Special Publications) to properly protect Internet traffic and data- 151 at-rest for US Government National Security Systems. 153 4. CNSA Compliant IPSec Overview 155 CNSA compliant implementations for IPsec MUST use IKEv2 [RFC7296]. 157 Implementing a CNSA compliant IPSec system requires cryptographic 158 algorithm selection for both the IKEv2 and ESP protocols. The 159 following CNSA requirements apply to IPSec: 161 Encryption: 162 AES [FIPS197] (with key size 256 bits) 164 Digital Signature: 165 ECDSA [FIPS186] (using the NIST P-384 elliptic curve) 166 RSA [FIPS186] (with a modulus of 3072 bits or larger) 168 Key Establishment: 169 ECDH [SP80056A] (using the NIST P-384 elliptic curve) 170 DH [RFC3526] (with a prime modulus of 3072 or larger) 172 To facilitate selection of appropriate combinations of compliant 173 algorithms, this document provides CNSA compliant user interface 174 suites (UI Suites) [RFC4308] to implement IPSec on NSS. 176 The approved CNSA hash function for all purposes is SHA-384, as 177 defined in [FIPS180]. However, SHA-512 is recommended for PRF 178 instead of SHA-384 due to availability. See Section 8 below. 180 For CNSA Suite applications, public key certificates MUST be 181 compliant with the CNSA Suite Certificate and CRL Profile specified 182 in [RFC8603]. 184 Under certain conditions, such as applications having long-lived data 185 protection requirements, systems that do not comply with the 186 requirements of this document are acceptable; see Section 12. 188 5. IPSec User Interface Suites 190 User Interface (UI) suites are named suites that cover some typical 191 security policy options for IPsec. [RFC4308] Use of UI suites does 192 not change the IPsec protocol in any way. The following UI suites 193 provide cryptographic algorithm choices for ESP [RFC4303] and for 194 Internet Key Exchange (IKEv2) [RFC7296]. The selection of a UI Suite 195 will depend on the key exchange algorithm. The suite names indicate 196 the Advanced Encryption Standard [FIPS197] mode, AES key length 197 specified for encryption, and the key exchange algorithm. 199 Although RSA is also a CNSA approved key establishment algorithm, in 200 IPSec with IKEv2 only DH or ECDH are implemented for key exchange. 201 [RFC7296] RSA in IPSec is used only for digital signatures. See 202 Section 6. 204 ESP requires negotiation of both a confidentiality algorithm and an 205 integrity algorithm. However, authenticated encryption (AEAD) 206 algorithms do not require a separate integrity algorithm to be 207 negotiated. [RFC5116] In particular, since AES-GCM is an AEAD 208 algorithm, ESP implementing AES-GCM MUST indicate the integrity 209 algorithm NONE. [RFC7296] 211 To be CNSA compliant, IPsec implementations that use the following UI 212 suites MUST use the suite names listed below. IPsec implementations 213 SHOULD NOT use names different than those listed here for the suites 214 that are described, and MUST NOT use the names listed here for suites 215 that do not match these values. These requirements are necessary for 216 interoperability. 218 Transform names are as listed in the IANA registry for Internet Key 219 Exchange Version 2 (IKEv2) Parameters. Definitions of the transforms 220 are contained in the references specified in that registry. 222 Other UI suites may be acceptable for CNSA compliance. See Section 8 223 for details. 225 5.1. Suite CNSA-GCM-256-ECDH-384 227 ESP SA: 228 Encryption: ENCR_AES_GCM_16 229 Integrity: NONE 230 IKEv2 SA: 231 Encryption: ENCR_AES_GCM_16 232 PRF: PRF_HMAC_SHA2_512 233 Integrity: NONE 234 Diffie-Hellman group: 384-bit random ECP group 236 5.2. Suite CNSA-GCM-256-DH-3072 238 ESP SA: 239 Encryption: ENCR_AES_GCM_16 240 Integrity: NONE 241 IKEv2 SA: 242 Encryption: ENCR_AES_GCM_16 243 PRF: PRF_HMAC_SHA2_512 244 Integrity: NONE 245 Diffie-Hellman group: 3072-bit MODP Group 247 5.3. Suite CNSA-GCM-256-DH-4096 249 ESP SA: 250 Encryption: ENCR_AES_GCM_16 251 Integrity: NONE 252 IKEv2 SA: 253 Encryption: ENCR_AES_GCM_16 254 PRF: PRF_HMAC_SHA2_512 255 Integrity: NONE 256 Diffie-Hellman group: 4096-bit MODP Group 258 6. IKEv2 Authentication 260 Authentication of the IKEv2 Security Association (SA) requires 261 computation of a digital signature. To be CNSA compliant, digital 262 signatures MUST be generated with either ECDSA-384 as defined in 263 [RFC4754] or RSA with 3072-bit or greater modulus and SHA-384 as 264 defined in [RFC8017]. 266 Initiators and responders MUST be able to verify ECDSA-384 signatures 267 and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and 268 SHA-384 signatures. 270 For CNSA compliant systems, authentication methods other than 271 ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 272 3072-bit modulus or larger MUST be used for RSA. If the relying 273 party receives a message signed with any authentication method other 274 than ECDSA-384 or RSA signature it MUST return an 275 AUTHENTICATION_FAILED notification and stop processing the message. 276 If the relying party receives a message signed with RSA using less 277 than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED 278 notification and stop processing the message. 280 7. Certificates 282 To be CNSA compliant, the initiator and responder MUST use X.509 283 certificates that comply with [RFC8603]. The identity authentication 284 method MUST use an end-entity certificate provided by the 285 authenticating party and MUST NOT use the Identification Payload for 286 policy lookup. 288 8. IKEv2 Security Associations (SA) 290 Section 5 specifies three UI suites for ESP and IKEv2 Security 291 Associations. All three use AES-GCM for encryption but differ in the 292 key exchange algorithm. Galois Counter Mode (GCM) combines counter 293 (CTR) mode with a secure, parallelizable, and efficient 294 authentication mechanism. [RFC4106] Since AES-GCM is an AEAD 295 algorithm, ESP implements AES-GCM with no additional integrity 296 algorithm. [RFC7296] 298 An initiator SHOULD offer one or more of the following suites: 300 CNSA-GCM-256-ECDH-384, 301 CNSA-GCM-256-DH-3072, 302 CNSA-GCM-256-DH-4096. 304 A responder SHOULD support at least one of the three named suites. 306 Nonce construction for AES-GCM using a misuse-resistant technique 307 [RFC8452] conforms with the requirements of this document and MAY be 308 used if a Federal Information Processing Standard (FIPS) validated 309 implementation is available. 311 The named UI suites use SHA-512 for PRF since SHA-384 is not listed 312 among required PRF or integrity algorithms in [RFC8247], the security 313 level is comparable, and the difference in performance is negligible. 314 However, SHA-384 is the official CNSA algorithm for computing a 315 condensed representation of information. Therefore, SHA-384 316 implementations for PRF or integrity MAY be used. Any algorithm 317 other than SHA-384 or SHA-512 MAY NOT be used for PRF or integrity. 319 If none of the suites offered by the initiator consist solely of CNSA 320 algorithms or the named UI Suites, the responder MUST return a Notify 321 payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA 322 compliant mode. 324 9. The Key Exchange Payload in the IKE_SA_INIT Exchange 326 The key exchange payload is used to exchange Diffie-Hellman public 327 numbers as part of a Diffie-Hellman key exchange. The CNSA compliant 328 initiator and responder MUST each generate an ephemeral key pair to 329 be used in the key exchange. 331 If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected 332 for the SA, the initiator and responder both MUST generate an 333 elliptic curve (EC) key pair using the P-384 elliptic curve. The 334 ephemeral public keys MUST be stored in the key exchange payload as 335 in [RFC7296]. 337 If the Diffie-Hellman (DH) key exchange is selected for the SA, the 338 initiator and responder both MUST generate a key pair using the 339 appropriately sized MODP group as described in [RFC3526]. The size 340 of the MODP group will be determined by the selection of either a 341 3072-bit or greater modulus for the SA. 343 10. Generating Key Material for the IKE SA 345 The ECDH shared secret established during the key exchange consists 346 of the x value of the ECDH common value [RFC5903]. Because the P-384 347 elliptic curve is used, the x value is 384 bits. 349 IKEv2 [RFC7296] allows for the reuse of Diffie-Hellman exponentials 350 (i.e. private keys). However, there are security concerns related to 351 this practice. Section 5.6.3.3 of [SP80056A] states that an 352 ephemeral private key MUST be used in exactly one key establishment 353 transaction and MUST be destroyed (zeroized) as soon as possible. 354 Section 5.8 of [SP80056A] states that a Diffie-Hellman shared secret 355 must be destroyed (zeroized) immediately after its use. CNSA 356 compliant IPSec systems MUST follow the mandates in [SP80056A]. 358 11. Additional Requirements 360 The IPSec protocol AH MUST NOT be used in CNSA compliant 361 implementations. 363 ESP does not explicitly include a Diffie-Hellman key exchange. 364 [RFC8221] However, a Diffie-Hellman group MAY be negotiated for the 365 Child SA allowing peers to employ Diffie-Hellman in the 366 CREATE_CHILD_SA exchange. [RFC7296] If a transform of type 4 is 367 specified for an SA for ESP, the value of the transform MUST match 368 that of the transform used by the IKEv2 SA. 370 Per [RFC7296], if a CREATE_CHILD_SA exchange includes a KEi payload, 371 at least one of the SA offers MUST include the Diffie-Hellman group 372 of the KEi. For CNSA compliant IPSec compliant implementations, the 373 Diffie-Hellman group of the KEi MUST use the same group used in the 374 IKE_INIT_SA. 376 For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both 377 parties. The initiator of this exchange MAY include a new Diffie- 378 Hellman key; if it is included, it MUST use the same group used in 379 the IKE_INIT_SA. If the initiator of the exchange includes a Diffie- 380 Hellman key, the responder MUST include a Diffie-Hellman key, and it 381 MUST use the same group. 383 For CNSA compliant systems, the IKEv2 authentication method MUST use 384 an end-entity certificate provided by the authenticating party. 385 Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST 386 not be used for the IKEv2 authentication method , but may be used for 387 policy lookup. 389 The administrative user interface (UI) for a system that conforms to 390 this profile MUST allow the operator to specify a single suite. If 391 only one suite is specified in the administrative UI, the IKEv2 392 implementation MUST only offer algorithms for that one suite. 394 The administrative UI MAY allow the operator to specify more than one 395 suite; if it allows this, it MUST allow the operator to specify a 396 preferred order for the suites that are to be offered or accepted. 397 If more than one suite is specified in the administrative UI, the 398 IKEv2 implementation MUST only offer algorithms of those suites. 400 12. Guidance for Applications With Long Data-Protection Requirements 402 The CNSA mandate is to continue to use current algorithms with 403 increased security parameters, then transition to approved post- 404 quantum resilient algorithms when they are identified. However, some 405 applications have data-in-transit-protection requirements that are 406 long enough that post-quantum resilient protection must be provided 407 now. Lacking approved asymmetric post-quantum resilient 408 confidentiality algorithms, that means approved symmetric techniques 409 must be used as described in this section until approved post-quantum 410 resilient asymmetric algorithms are identified. 412 For new applications, confidentiality and integrity requirements from 413 the sections above MUST be followed, with the addition of a PSK mixed 414 in as defined in [RFC8784]. Installations currently using IKEv1 with 415 PSK MUST use AES in cipher block chaining mode (AES-CBC) in 416 conjunction with a CNSA compliant integrity algorithm, and transition 417 to IKEv2 with PSK [RFC8784] as soon as implementations become 418 available. 420 For all applications to which this section applies, PSK 421 authentication MUST be performed using HMAC-SHA-384 [RFC4868]. 423 Specific guidance for systems not compliant with the requirements of 424 this document, including non-GCM modes and PSK randomness, will be 425 defined in solution specific requirements appropriate to the 426 application. Details of those requirements will depend on the 427 program under which the commercial NSS solution is developed (e.g. 428 Commercial Solutions for Classified Capability Package). 430 13. Security Considerations 432 This document inherits all of the security considerations of the 433 IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754], 434 and [RFC8221]. 436 The security of a system that uses cryptography depends on both the 437 strength of the cryptographic algorithms chosen and the strength of 438 the keys used with those algorithms. The security also depends on 439 the engineering and administration of the protocol used by the system 440 to ensure that there are no non-cryptographic ways to bypass the 441 security of the overall system. 443 When selecting a mode for the AES encryption, be aware that nonce 444 reuse can result in a loss of confidentiality. [RFC5116] Nonce reuse 445 is catastrophic for GCM since it also results in a loss of integrity. 447 14. IANA Considerations 449 IANA is asked to amend the registry titled "Cryptographic Suites for 450 IKEv1, IKEv2, and IPsec" located at https://www.iana.org/assignments/ 451 crypto-suites as described in this section. The registry consists of 452 a text string and an RFC number that lists the associated transforms. 453 The UI suites defined in this document are listed, with this document 454 as the RFC reference. 456 +-----------------------+------------+ 457 | Identifier | Reference | 458 +-----------------------+------------+ 459 | CNSA-GCM-256-ECDH-384 | [This RFC] | 460 +-----------------------+------------+ 461 | CNSA-GCM-256-DH-3072 | [This RFC] | 462 +-----------------------+------------+ 463 | CNSA-GCM-256-DH-4096 | [This RFC] | 464 +-----------------------+------------+ 466 Table 1 468 15. References 470 15.1. Normative References 472 [CNSA] Committee for National Security Systems, "Use of Public 473 Standards for Secure Information Sharing", CNSSP 15, 474 October 2016, 475 . 477 [FIPS180] National Institute of Standards and Technology, "Secure 478 Hash Standard (SHS)", Federal Information Processing 479 Standard 180-4, August 2015, 480 . 483 [FIPS186] National Institute of Standards and Technology, "Digital 484 Signature Standard (DSS)", NIST Federal Information 485 Processing Standard 186-4, July 2013, 486 . 489 [FIPS197] National Institute of Standards and Technology, "Advanced 490 Encryption Standard (AES)", Federal Information Processing 491 Standard 197, November 2001, 492 . 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 501 Diffie-Hellman groups for Internet Key Exchange (IKE)", 502 RFC 3526, DOI 10.17487/RFC3526, May 2003, 503 . 505 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 506 (GCM) in IPsec Encapsulating Security Payload (ESP)", 507 RFC 4106, DOI 10.17487/RFC4106, June 2005, 508 . 510 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 511 RFC 4303, DOI 10.17487/RFC4303, December 2005, 512 . 514 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 515 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 516 RFC 4754, DOI 10.17487/RFC4754, January 2007, 517 . 519 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 520 384, and HMAC-SHA-512 with IPsec", RFC 4868, 521 DOI 10.17487/RFC4868, May 2007, 522 . 524 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 525 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 526 . 528 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 529 Housley, R., and W. Polk, "Internet X.509 Public Key 530 Infrastructure Certificate and Certificate Revocation List 531 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 532 . 534 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 535 Algorithms with the Encrypted Payload of the Internet Key 536 Exchange version 2 (IKEv2) Protocol", RFC 5282, 537 DOI 10.17487/RFC5282, August 2008, 538 . 540 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 541 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 542 DOI 10.17487/RFC5903, June 2010, 543 . 545 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 546 Kivinen, "Internet Key Exchange Protocol Version 2 547 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 548 2014, . 550 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 551 "PKCS #1: RSA Cryptography Specifications Version 2.2", 552 RFC 8017, DOI 10.17487/RFC8017, November 2016, 553 . 555 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 556 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 557 May 2017, . 559 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 560 Kivinen, "Cryptographic Algorithm Implementation 561 Requirements and Usage Guidance for Encapsulating Security 562 Payload (ESP) and Authentication Header (AH)", RFC 8221, 563 DOI 10.17487/RFC8221, October 2017, 564 . 566 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 567 "Algorithm Implementation Requirements and Usage Guidance 568 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 569 RFC 8247, DOI 10.17487/RFC8247, September 2017, 570 . 572 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 573 Algorithm (CNSA) Suite Certificate and Certificate 574 Revocation List (CRL) Profile", RFC 8603, 575 DOI 10.17487/RFC8603, May 2019, 576 . 578 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 579 "Mixing Preshared Keys in the Internet Key Exchange 580 Protocol Version 2 (IKEv2) for Post-quantum Security", 581 RFC 8784, DOI 10.17487/RFC8784, June 2020, 582 . 584 [SP80056A] National Institute of Standards and Technology, 585 "Recommendation for Pair-Wise Key Establishment Schemes 586 Using Discrete Logarithm Cryptography", NIST Special 587 Publication 800-56A, Revision 3, April 2018, 588 . 591 15.2. Informative References 593 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 594 DOI 10.17487/RFC4308, December 2005, 595 . 597 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 598 Nonce Misuse-Resistant Authenticated Encryption", 599 RFC 8452, DOI 10.17487/RFC8452, April 2019, 600 . 602 [SP80059] National Institute of Standards and Technology, "Guideline 603 for Identifying an Information System as a National 604 Security System", Special Publication 800-59 , August 605 2003, . 608 Authors' Addresses 610 Laura Corcoran 611 National Security Agency 613 Email: lscorco@nsa.gov 615 Michael Jenkins 616 National Security Agency 618 Email: mjjenki@cyber.nsa.gov