RFC 9206

Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)

📅 published March 2022, from ietf

Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec) ✨

okay bestie, this is RFC 9206 💜 and it's giving NSA energy, so buckle up 🫶

Here's the title block tea ☕: this one is an Independent Submission (aka the RFC Editor said "sure, publish it" rather than it coming out of a working group), written by L. Corcoran and M. Jenkins from the NSA 🕵️‍♀️. It's Informational category, which means it's not a Standards Track spec, and it was dated February 2022. The ISSN is 2070-1721 🌸 It doesn't obsolete or update anything, so no drama there ✨

This doc is part 1 of 3, so stay with me 🎀

Abstract

The US Government put out the NSA's Commercial National Security Algorithm (CNSA) Suite, which is basically the cryptography rulebook for national security stuff 🔥 This doc explains how to use the CNSA Suite algorithms in IPsec. It covers the capabilities, configuration, and operation of all parts of US National Security Systems (the ones described in NIST Special Publication 800-59) that use IPsec. It's also good for other US Government systems that handle high-value info 💅 And since it's public, anyone building or running these systems can use it 🦋

Status of This Memo

Okay so, this is not an Internet Standards Track spec. It's just here for info 🌈

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's valuable for implementation or deployment 🤷‍♀️ Docs approved by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 💖

Want errata or feedback info? Check out:

https://www.rfc-editor.org/info/rfc9206

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. Please actually read these, they're about your rights and restrictions 🙈

Table of Contents

1.  Introduction
2.  Terminology
3.  The Commercial National Security Algorithm Suite
4.  CNSA-Compliant IPsec Overview
5.  IPsec User Interface Suites
  5.1.  Suite CNSA-GCM-256-ECDH-384
  5.2.  Suite CNSA-GCM-256-DH-3072
  5.3.  Suite CNSA-GCM-256-DH-4096
6.  IKEv2 Authentication
7.  Certificates
8.  IKEv2 Security Associations (SAs)
9.  The Key Exchange Payload in the IKE_SA_INIT Exchange
10. Generating Key Material for the IKE SA
11. Additional Requirements
12. Guidance for Applications with Long Data-Protection
        Requirements
13. Security Considerations
14. IANA Considerations
15. References
  15.1.  Normative References
  15.2.  Informative References
Authors' Addresses

1. Introduction 🌸

This doc lays out how to use the NSA's Commercial National Security Algorithm (CNSA) Suite algorithms [CNSA] in IPsec 💜 It defines CNSA-based User Interface suites ("UI suites") that describe sets of security configs for Internet Key Exchange Protocol Version 2 (IKEv2) and IP Encapsulating Security Payload (ESP) use, and it also sets some other constraints around algorithm selection and config ✨ It applies to all components of US National Security Systems (described in NIST Special Publication 800-59 [SP80059]) that use IPsec, and it's also good for other US Government systems that process high-value information 🦋 Anyone can use it for their own deployments too 💅

You're expected to already be familiar with:

  • "IP Encapsulating Security Payload (ESP)" [RFC4303]
  • "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280]
  • "Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC7296]
  • "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)" [RFC8221]
  • "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile" [RFC8603]

2. Terminology 🧚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🙈

Quick glossary bestie 💖:

  • AES is the Advanced Encryption Standard.
  • ECDSA and ECDH refer to the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH), respectively.
  • DH refers to Diffie-Hellman key establishment.
  • RSA refers to an RSA signature.

3. The Commercial National Security Algorithm Suite 👑

The NSA profiles commercial crypto algorithms and protocols as part of its mission to support secure, interoperable comms for US Government National Security Systems 💅 It publishes guidance to (1) help the US Government transition to new algorithms and (2) give vendors, and the Internet community in general, info on their proper use and config 🫶

Recently, crypto transition plans have been overshadowed by the prospect of a cryptographically relevant quantum computer 😭 The NSA set up the Commercial National Security Algorithm (CNSA) Suite to give vendors and IT users near-term flexibility in meeting their information assurance interoperability requirements ✨ The whole point of that flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, since they expect a need to shift to quantum-resistant cryptography in the near future 🔮

The NSA is writing a set of RFCs, including this one, to give updated guidance on using certain commonly available commercial algorithms in IETF protocols 🌈 These RFCs can be used alongside other RFCs and crypto guidance (like NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems 🎀

4. CNSA-Compliant IPsec Overview 💜

CNSA-compliant implementations for IPsec MUST use IKEv2 [RFC7296]. 🚨

Implementing a CNSA-compliant IPsec system requires crypto algorithm selection for both the IKEv2 and ESP protocols. The following CNSA requirements apply to IPsec:

  • Encryption: AES [FIPS197] (with key size 256 bits)
  • Digital Signature: ECDSA [FIPS186] (using the NIST P-384 elliptic curve) and RSA [FIPS186] (with a modulus of 3072 bits or larger)
  • Key Establishment: ECDH [SP80056A] (using the NIST P-384 elliptic curve) and DH [RFC3526] (with a prime modulus of 3072 or larger)

To make it easier to pick compliant combos, this doc provides CNSA-compliant User Interface suites (UI suites) [RFC4308] to implement IPsec on National Security Systems ✨

The approved CNSA hash function for all purposes is SHA-384, as defined in [FIPS180] 🔥 However, PRF_HMAC_SHA_512 is specified for the IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to availability. See Section 8 below 🙈

For CNSA Suite applications, public key certificates MUST be compliant with the CNSA Suite Certificate and CRL Profile specified in [RFC8603] 💅

Under certain conditions, like applications with long-lived data-protection requirements, systems that don't comply with this doc are acceptable. See Section 12 🦋

5. IPsec User Interface Suites 🎀

UI suites [RFC4308] are named suites that cover some typical security policy options for IPsec 💖 Using UI suites doesn't change the IPsec protocol in any way ✨ The following UI suites give crypto algorithm choices for ESP [RFC4303] and IKEv2 [RFC7296]. Which UI suite you pick depends on the key exchange algorithm 🌸 The suite names tell you the Advanced Encryption Standard [FIPS197] mode, the AES key length for encryption, and the key exchange algorithm 🫶

Even though RSA is also a CNSA-approved key establishment algorithm, only DH and ECDH are specified for key exchange in IKEv2 [RFC7296] 🙈 RSA in IPsec is only used for digital signatures. See Section 6 💅

ESP needs negotiation of both a confidentiality algorithm and an integrity algorithm. Algorithms for Authenticated Encryption with Associated Data (AEAD) [RFC5116] don't need a separate integrity algorithm to be negotiated, though 🧚 Since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST either offer no integrity algorithm or indicate the single integrity algorithm NONE (see Section 3.3 of [RFC7296]) 🚨

To be CNSA compliant, IPsec implementations that use the following UI suites MUST use the suite names listed below. IPsec implementations SHOULD NOT use names different than those listed here for the suites that are described, and they MUST NOT use the names listed here for suites that don't match these values. These requirements are necessary for interoperability 🤝

Transform names are as listed in the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. Definitions of the transforms are in the references specified in that registry 📚

Other UI suites may be acceptable for CNSA compliance. See Section 8 for details 🌈

Wait, I need to fix that last line. The original says "MAY" is not in capitals there, so it's lowercase in my version, which is correct.

5.1. Suite CNSA-GCM-256-ECDH-384 💜

ESP SA:
   Encryption:  ENCR_AES_GCM_16 (with key size 256 bits)
   Integrity:  NONE
IKEv2 SA:
   Encryption:  ENCR_AES_GCM_16 (with key size 256 bits)
   PRF:  PRF_HMAC_SHA2_512
   Integrity:  NONE
   Diffie-Hellman group:  384-bit random ECP group

5.2. Suite CNSA-GCM-256-DH-3072 🦋

ESP SA:
   Encryption:  ENCR_AES_GCM_16 (with key size 256 bits)
   Integrity:  NONE
IKEv2 SA:
   Encryption:  ENCR_AES_GCM_16 (with key size 256 bits)
   PRF:  PRF_HMAC_SHA2_512
   Integrity:  NONE
   Diffie-Hellman group:  3072-bit MODP group

5.3. Suite CNSA-GCM-256-DH-4096 🌸

ESP SA:
   Encryption:  ENCR_AES_GCM_16 (with key size 256 bits)
   Integrity:  NONE
IKEv2 SA:
   Encryption:  ENCR_AES_GCM_16 (with key size 256 bits)
   PRF:  PRF_HMAC_SHA2_512
   Integrity:  NONE
   Diffie-Hellman group:  4096-bit MODP group

Part 1 of 3 is done, bestie 🎀 Sections 6 onward are coming in the next parts 💜

6. IKEv2 Authentication ✨

Okay so, IKEv2 authentication is where the digital signatures come in, and bestie, they have to be SHA-384 based 🔐💅. To be CNSA compliant, signatures MUST be generated with SHA-384 as defined in [RFC8017], together with either ECDSA-384 as defined in [RFC4754] or RSA with a 3072-bit or greater modulus. (Long data-protection needs play by somewhat different rules, so peek at Section 12 for that 🦋.)

Initiators and responders MUST be able to verify ECDSA-384 signatures, and they MUST also be able to verify RSA with a 3072-bit or 4096-bit modulus and SHA-384 signatures 💜.

Now the strict part 🙈. For CNSA-compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. An RSA modulus MUST be 3072 bits or larger. If the relying party gets a message signed with any authentication method other than an ECDSA-384 or RSA signature, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message. And if the relying party gets a message signed with RSA using less than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message too. No exceptions, periodt 💀🫶.

7. Certificates 🎀

To be CNSA compliant, the initiator and responder MUST use X.509 certificates that comply with [RFC8603]. Peer authentication decisions must be based on the Subject or Subject Alternative Name from the certificate that holds the key used to validate the signature in the Authentication Payload (see Section 3.8 of [RFC7296]), rather than on the Identification Data from the Identification Payload that gets used to look up policy 🌸. Different lanes, bestie!

8. IKEv2 Security Associations (SAs) 🧚

Section 5 lays out three UI suites for ESP and IKEv2 Security Associations 👑. They all use AES-GCM for encryption but differ in the key exchange algorithm. Galois/Counter Mode (GCM) [RFC4106] combines counter (CTR) mode with a secure, parallelizable, and efficient authentication mechanism ✨. Since AES-GCM is an AEAD algorithm, ESP implements AES-GCM with no additional integrity algorithm (see Section 3.3 of [RFC7296]) 🦋.

An initiator proposal SHOULD be constructed from one or more of the following suites:

  • CNSA-GCM-256-ECDH-384
  • CNSA-GCM-256-DH-3072
  • CNSA-GCM-256-DH-4096

A responder SHOULD accept proposals constructed from at least one of the three named suites 💖. Other UI suites may also result in acceptable proposals (such as those based on PRF_HMAC_SHA2_384), but those are provided to promote interoperability 🍓.

Nonce construction for AES-GCM using a misuse-resistant technique [RFC8452] conforms with the requirements of this document and MAY be used if a Federal Information Processing Standard (FIPS) validated implementation is available 🌈.

Here's the tea ☕: the named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF transform, because PRF_HMAC_SHA2_384 is not listed among the required PRF transforms in [RFC8247]. That means implementations of the latter are likely to be scarce 🙈. PRF_HMAC_SHA2_512 has a comparable security level, and the performance difference is negligible ⭐. However, SHA-384 is the official CNSA algorithm for computing a condensed representation of information, so the PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to the initiator and responder 💅. Any PRF transform other than PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used 🚫.

If none of the proposals the initiator offers consist solely of transforms based on CNSA algorithms (such as those in the UI suites defined in Section 5), the responder MUST return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant mode 😭.

9. The Key Exchange Payload in the IKE_SA_INIT Exchange 🔑

The key exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange 💜. The CNSA-compliant initiator and responder MUST each generate an ephemeral key pair to be used in the key exchange ✨.

If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected for the SA, the initiator and responder both MUST generate an elliptic curve (EC) key pair using the P-384 elliptic curve. The ephemeral public keys MUST be stored in the key exchange payload as described in [RFC5903] 🦋.

If the Diffie-Hellman (DH) key exchange is selected for the SA, the initiator and responder both MUST generate a key pair using the appropriately sized MODP group as described in [RFC3526]. The size of the MODP group will be determined by the selection of either a 3072-bit or greater modulus for the SA 🌸.

10. Generating Key Material for the IKE SA 🔐

Okay, key material time 🥹. As noted in Section 7 of [RFC5903], the shared secret result of an ECDH key exchange is the 384-bit x value of the ECDH common value. The shared secret result of a DH key exchange is the number of octets needed to accommodate the prime (e.g., 384 octets for a 3072-bit MODP group), with leading zeros as necessary, as described in Section 2.1.2 of [RFC2631] 🧚.

IKEv2 allows for the reuse of Diffie-Hellman private keys; see Section 2.12 of [RFC7296]. However, there are security concerns related to this practice 😬. Section 5.6.3.3 of [SP80056A] states that an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be destroyed (zeroized) as soon as possible. Section 5.8 of [SP80056A] states that any shared secret derived from key establishment MUST be destroyed (zeroized) immediately after its use. CNSA-compliant IPsec systems MUST follow the mandates in [SP80056A] 💀.

11. Additional Requirements 💅

The IPsec protocol AH MUST NOT be used in CNSA-compliant implementations 🚫. Not me being dramatic, but AH is simply out 👋.

A Diffie-Hellman group MAY be negotiated for a Child SA as described in Section 1.3 of [RFC7296], allowing peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange 🌈. If a transform of type 4 is specified for an SA for ESP, the value of that transform MUST match the value of the transform used by the IKEv2 SA 🫶.

Per [RFC7296], if a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers MUST include the Diffie-Hellman group of the KEi. For CNSA-compliant IPsec implementations, the Diffie-Hellman group of the KEi MUST use the same group used in the IKE_INIT_SA ✨.

For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both parties. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST use the same group used in the IKE_INIT_SA. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST use the same group 🔁.

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 they MAY be used for policy lookup 🎀.

The administrative User Interface (UI) for a system that conforms to this profile MUST allow the operator to specify a single suite. If only one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms for that one suite 🍓.

The administrative UI MAY allow the operator to specify more than one suite. If it allows this, it MUST allow the operator to specify a preferred order for the suites that are to be offered or accepted. If more than one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms of those suites. (Note that although this document does not define a UI suite specifying PRF_HMAC_SHA2_384, a proposal containing such a transform is CNSA compliant 🧚.)

12. Guidance for Applications with Long Data-Protection Requirements 🕰️

The CNSA mandate is to continue using current algorithms with increased security parameters, then transition to approved post-quantum resilient algorithms when they are identified 🔮. Some applications, though, have data-in-transit-protection requirements that are long enough that post-quantum resilient protection must be provided now 😱. Lacking approved asymmetric post-quantum resilient confidentiality algorithms, that means approved symmetric techniques must be used as described in this section, until approved post-quantum resilient asymmetric algorithms are identified 💜.

For new applications, the confidentiality and integrity requirements from the sections above MUST be followed, with the addition of a Pre-Shared Key (PSK) mixed in as defined in [RFC8784] ✨.

Installations currently using IKEv1 with PSKs MUST (1) use AES in cipher block chaining mode (AES-CBC) in conjunction with a CNSA-compliant integrity algorithm (e.g., AUTH_HMAC_SHA2_384_192) and (2) transition to IKEv2 with PSKs [RFC8784] as soon as implementations become available 🏃‍♀️💨.

Specific guidance for systems not compliant with the requirements of this document, including non-GCM modes, PSK length, and PSK randomness, will be defined in solution-specific requirements appropriate to the application. Details of those requirements will depend on the program under which the commercial National Security Systems solution is developed (e.g., an NSA Commercial Solutions for Classified Capability Package) 📋.

13. Security Considerations ⚠️

This is the serious part, bestie, so read carefully 🙏.

This document inherits all of the security considerations of the IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754], and [RFC8221] 🔒.

The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system, to ensure that there are no non-cryptographic ways to bypass the security of the overall system 🛡️.

When selecting a mode for the AES encryption [RFC5116], be aware that nonce reuse can result in a loss of confidentiality. Nonce reuse is catastrophic for GCM, since it also results in a loss of integrity 💀🔥.

14. IANA Considerations 📚

IANA has added the UI suites defined in this document to the "Cryptographic Suites for IKEv1, IKEv2, and IPsec" registry located at https://www.iana.org/assignments/crypto-suites 🌸:

                +=======================+===========+
                |       Identifier      | Reference |
                +=======================+===========+
                | CNSA-GCM-256-ECDH-384 | RFC 9206  |
                +-----------------------+-----------+
                | CNSA-GCM-256-DH-3072  | RFC 9206  |
                +-----------------------+-----------+
                | CNSA-GCM-256-DH-4096  | RFC 9206  |
                +-----------------------+-----------+

                             Table 1

15. References 📖

15.1. Normative References 📚✨

okay these are the big-name specs the whole doc leans on, so bookmark them bestie 🔖💅

15.2. Informative References 🌸

these ones are more like extra reading for the curious 🧚

Authors' Addresses 💜

Laura Corcoran National Security Agency Email: lscorco@nsa.gov

Michael Jenkins National Security Agency - Center for Cybersecurity Standards Email: mjjenki@cyber.nsa.gov

📦 where this page comes from