Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3National Security Agencydecoole@nsa.govThis document defines a base profile for TLS protocol versions 1.2
and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the
US Commercial National Security Algorithm (CNSA) Suite.
The profile applies to the capabilities, configuration, and operation
of all components of US National Security Systems that use TLS or DTLS.
It is also appropriate for all other US Government systems that process
high-value information.
The profile is made publicly available here for use by developers and
operators of these and any other system deployments.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. CNSA
. Terminology
. CNSA Suites
. CNSA (D)TLS Key Establishment Algorithms
. CNSA TLS Authentication
. CNSA Compliance and Interoperability Requirements
IntroductionThis document specifies a profile of TLS version 1.2 and TLS version 1.3 as well as DTLS version 1.2 and DTLS version 1.3 for use by applications that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite . The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems . It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
This document does not define any new cipher suites; instead, it defines a CNSA-compliant profile of TLS and DTLS, and the cipher suites defined in , , and . This profile uses only algorithms in the CNSA Suite.
The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as well as the DTLS 1.2 and 1.3 protocol specifications: , , , and , respectively. All MUST-level requirements from the protocol documents apply throughout this profile; they are generally not repeated. This profile contains changes that elevate some SHOULD-level options to MUST-level; this profile also contains changes that elevate some MAY-level options to SHOULD-level or MUST-level. All options that are not mentioned in this profile remain at their original requirement level.
CNSAThe National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure,
interoperable communications for US National Security Systems. To this
end, it publishes guidance both to assist with the US Government
transition to new algorithms and to provide vendors -- and the Internet
community in general -- with information concerning their proper use and
configuration.
Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the CNSA Suite to provide vendors and IT users near-term flexibility in meeting their Information Assurance (IA) interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
The NSA is authoring a set of RFCs, including this one, to provide
updated guidance concerning the use of certain commonly available
commercial algorithms in IETF protocols. These RFCs can be used in
conjunction with other RFCs and cryptographic guidance (e.g., NIST
Special Publications) to properly protect Internet traffic and
data-at-rest for US National Security Systems.
TerminologyThe 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 when, and only when, they appear in all capitals, as shown here.
"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. ECDSA and ECDH are used with the NIST P-384 curve (which is based on a 384-bit prime modulus) and the SHA-384 hash function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH are used with a 3072-bit or 4096-bit modulus. When RSA is used for digital signature, it is used with the SHA-384 hash function.
Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS versions 1.2 and 1.3 collectively as "(D)TLS".
CNSA Suites approves the use of both Finite Field and elliptic curve versions of the DH key agreement algorithm as well as RSA-based key establishment. also approves certain versions of the RSA and elliptic curve digital signature algorithms. The approved encryption techniques include the Advanced Encryption Standard (AES) used with a 256-bit key in an Authenticated Encryption with Associated Data (AEAD) mode.
In particular, CNSA includes the following:
ECDSA (using the NIST P-384
elliptic curve)RSA (with a modulus of
3072 bits or 4096 bits)
Key Establishment (includes key agreement and key transport):
ECDH (using the NIST P-384
elliptic curve)DH (with a prime
modulus of 3072 or 4096 bits)RSA (with a modulus of
3072 or 4096 bits, but only in (D)TLS 1.2)
also approves the use of SHA-384 as the hash algorithm for mask generation, signature generation, Pseudorandom Function (PRF) in TLS 1.2 and HMAC-based Key Derivation Function (HKDF) in TLS 1.3.
CNSA (D)TLS Key Establishment AlgorithmsThe following combination of algorithms and key sizes are used in CNSA (D)TLS:
AES with 256-bit key, operating in GCM mode
ECDH using the
Ephemeral Unified Model Scheme with cofactor set to 1 (see Section
6.1.2.2 in )
TLS PRF/HKDF with SHA-384
Or
AES with 256-bit key, operating in GCM mode
RSA key transport using 3072-bit or 4096-bit modulus
TLS PRF/HKDF with SHA-384
Or
AES with 256-bit key, operating in GCM mode
DH using dhEphem with domain parameters specified below in (see Section 6.1.2.1 in )
TLS PRF/HKDF with SHA-384
The specific CNSA-compliant cipher suites are listed in .
CNSA TLS AuthenticationFor server and/or client authentication, CNSA (D)TLS MUST generate and verify either ECDSA signatures or RSA signatures.
In all cases, the client MUST authenticate the
server. The server MAY also authenticate the client, as
needed by the specific application.
The public keys used to verify these signatures MUST
be contained in a certificate (see for more
information).CNSA Compliance and Interoperability RequirementsCNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS
1.2 in a CNSA-compliant system. CNSA (D)TLS servers and clients
MUST implement and use either (D)TLS version 1.2 or (D)TLS version 1.3 .
Acceptable Elliptic Curve Cryptography (ECC) CurvesThe elliptic curves used in the CNSA Suite appear in the literature
under two different names . For the sake of clarity, both names
are listed below:
Elliptic Curves in CNSA Suite
Curve
NIST name
SECG name
P-384
nistp384
secp384r1
defines a variety of elliptic curves. CNSA (D)TLS connections MUST use secp384r1 (also called nistp384), and the uncompressed form MUST be used, as required by and .
Key pairs MUST be generated following Section 5.6.1.2 of .
Acceptable RSA Schemes, Parameters, and Checks specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile.
For (D)TLS 1.2:
For certificate signatures, RSASSA-PKCS1-v1_5 MUST be supported, and RSASSA-PSS SHOULD be supported.For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5 MUST be supported, and RSASSA-PSS SHOULD be supported.For key transport, RSAES-PKCS1-v1_5 MUST be supported.
For (D)TLS 1.3:
For certificate signatures, RSASSA-PKCS1-v1_5 MUST be supported, and RSASSA-PSS SHOULD be supported.For signatures in TLS handshake messages, RSASSA-PSS MUST be
supported.For key transport, TLS 1.3 does not support RSA key
transport.
For all versions of (D)TLS:
RSA exponent e MUST satisfy
216<e<2256 and be odd per .If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then
the implementation MUST assert rsaEncryption as the public
key algorithm, the hash algorithm (used for both mask generation and
signature generation) MUST be SHA-384, the mask generation
function 1 (MGF1) from MUST be used, and the salt length MUST be 48
octets.
Acceptable Finite Field Groups specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile.
Ephemeral key pairs MUST be generated following Section 5.6.1.1.1 of using the approved safe prime groups specified in for DH ephemeral key agreement. The named groups are:
ffdhe3072 (ID=257)
ffdhe4096 (ID=258)
CertificatesCertificates used to establish a CNSA (D)TLS connection MUST be signed with ECDSA or RSA and MUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile .
(D)TLS 1.2 RequirementsAlthough TLS 1.2 has technically been obsoleted by the IETF in favor of TLS 1.3, many implementations and deployments of TLS 1.2 will continue to exist. For the cases where TLS 1.2 continues to be used, implementations MUST use and SHOULD implement the updates specified in (outlined in Section of that document).
The CNSA (D)TLS 1.2 client MUST offer at least one of these cipher suites:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
The CNSA cipher suites listed above MUST be the first
(most preferred) cipher suites in the ClientHello message.
A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant MAY offer additional cipher suites, but any additional cipher suites MUST appear after the CNSA cipher suites in the ClientHello message.
A CNSA (D)TLS server MUST accept one of the CNSA
Suites above if they are offered in the ClientHello message before
accepting a non-CNSA-compliant suite.
If interoperability is not desired with non-CNSA-compliant clients or
servers, then the session MUST fail if no CNSA Suites are
offered or accepted.
The "extended_master_secret" ExtensionA CNSA (D)TLS client SHOULD include and a CNSA
(D)TLS server SHOULD accept the
"extended_master_secret" extension as specified in . See for security
concerns when this extension is not used.
The "signature_algorithms" ExtensionA CNSA (D)TLS client MUST include and a CNSA (D)TLS server MUST also accept the "signature_algorithms" extension. The CNSA (D)TLS client MUST offer and the
CNSA (D)TLS server MUST also accept at least one of the following values in the "signature_algorithms" extensions as specified in :
ecdsa_secp384r1_sha384
rsa_pkcs1_sha384
And, if supported, the client SHOULD offer and/or the server SHOULD also accept:
rsa_pss_pss_sha384
rsa_pss_rsae_sha384
Following the guidance in , CNSA (D)TLS servers MUST only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for certification path validation.
Other client offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA and to indicate the signature algorithms that are acceptable for ServerKeyExchange messages and for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server.
The "signature_algorithms_cert" ExtensionA CNSA (D)TLS client MAY include the
"signature_algorithms_cert" extension. CNSA (D)TLS servers
MUST process the "signature_algorithms_cert" extension
if it is offered per .
Both CNSA (D)TLS clients and servers MUST use one of the following values for certificate path validation:
ecdsa_secp384r1_sha384
rsa_pkcs1_sha384
And, if supported, SHOULD offer/accept:
rsa_pss_pss_sha384
rsa_pss_rsae_sha384
The CertificateRequest MessageWhen a CNSA (D)TLS server is configured to authenticate the client, the server MUST include the following values in its CertificateRequest.supported_signature_algorithms offer:
ecdsa_secp384r1_sha384
rsa_pkcs1_sha384
And, if supported as specified in , SHOULD offer/accept:
rsa_pss_pss_sha384
rsa_pss_rsae_sha384
The CertificateVerify MessageA CNSA (D)TLS client MUST use ECDSA or RSA when sending the CertificateVerify message. CNSA (D)TLS servers MUST only accept ECDSA or RSA in the CertificateVerify message.
The Signature in the ServerKeyExchange MessageA CNSA (D)TLS server MUST sign the ServerKeyExchange message using ECDSA or RSA.
Certificate StatusCertificate Authorities (CAs) providing certificates to a CNSA (D)TLS
server or client MUST provide certificate revocation
status information via a Certificate Revocation List (CRL)
distribution point or using the Online Certificate Status Protocol
(OCSP). A CNSA client SHOULD request it according to
. If OCSP is supported, the (D)TLS server
SHOULD provide OCSP responses in the
CertificateStatus message.
(D)TLS 1.3 RequirementsThe CNSA (D)TLS client MUST offer the following cipher
suite in the ClientHello:
TLS_AES_256_GCM_SHA384
The CNSA (D)TLS client MUST include at least one of
the following values in the "supported_groups" extension:
ECDHE: secp384r1
DHE: ffdhe3072
DHE: ffdhe4096
The CNSA cipher suite MUST be the first (most
preferred) cipher suite in the ClientHello message and in the
extensions.
A CNSA (D)TLS client that offers interoperability with servers that are
not CNSA compliant MAY offer additional cipher suites, but any additional
cipher suites MUST appear after the CNSA-compliant cipher suites in the
ClientHello message.
A CNSA (D)TLS server MUST accept one of the CNSA algorithms listed above if they are offered in the ClientHello message.
If interoperability is not desired with non-CNSA-compliant clients or servers, then the session MUST fail if no CNSA Suites are offered or accepted.
The "signature_algorithms" ExtensionA CNSA (D)TLS client MUST include the "signature_algorithms" extension. The CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms" extension:
ecdsa_secp384r1_sha384
rsa_pss_pss_sha384
rsa_pss_rsae_sha384
Clients that allow negotiating TLS 1.2 MAY offer rsa_pkcs1_sha384 for use with TLS 1.2. Other offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server.
The "signature_algorithms_cert" ExtensionA CNSA (D)TLS client SHOULD include the "signature_algorithms_cert" extension. And, if offered, the CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms_cert" extension:
ecdsa_secp384r1_sha384
rsa_pkcs1_sha384
And, if supported, SHOULD offer:
rsa_pss_pss_sha384
rsa_pss_rsae_sha384
Following the guidance in , CNSA (D)TLS servers MUST only accept ECDSA or RSA for certificate path validation.
Other offerings MAY be included to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server.
The "early_data" ExtensionA CNSA (D)TLS client or server MUST NOT include the
"early_data" extension. See for security concerns.
ResumptionA CNSA (D)TLS server MAY send a CNSA (D)TLS client a
NewSessionTicket message to enable resumption. A CNSA (D)TLS client
MUST request "psk_dhe_ke" via the
"psk_key_exchange_modes" ClientHello extension to resume a session. A
CNSA (D)TLS client MUST offer Ephemeral Elliptic Curve
Diffie-Hellman (ECDHE) with SHA-384 and/or Ephemeral Diffie-Hellman (DHE) with SHA-384 in the
"supported_groups" and/or "key_share" extensions.
Certificate StatusCertificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or client MUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA client SHOULD request it according to . If OCSP is supported, the (D)TLS server SHOULD provide OCSP responses in the "CertificateEntry".
Security ConsiderationsMost of the security considerations for this document are described
in , , , and . In addition, the security
considerations for Elliptic Curve Cryptography (ECC) related to TLS are
described in , , and . Readers should consult those documents.
In order to meet the goal of a consistent security level for the entire cipher suite, CNSA (D)TLS implementations MUST only use the elliptic curves, RSA schemes, and Finite Fields defined in , , and , respectively. If this is not the case, then security may be weaker than is required.
As noted in TLS version 1.3 , TLS does not provide inherent replay protections for early data. For this reason, this profile forbids the use of early data.
IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesAnnouncing the ADVANCED ENCRYPTION STANDARD (AES)National Institute of Standards and TechnologyUse of Public Standards for Secure Information SharingCommittee for National Security SystemsDigital Signature Standard (DSS)National Institute of Standards and TechnologyRecommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMACRecommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm CryptographyRecommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization CryptographyKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]AES Galois Counter Mode (GCM) Cipher Suites for TLSThis memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). This memo provides information for the Internet community.Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]Transport Layer Security (TLS) Session Hash and Extended Master Secret ExtensionThe Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).PKCS #1: RSA Cryptography Specifications Version 2.2This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.This document also obsoletes RFC 3447.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and EarlierThis document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.This document obsoletes RFC 4492.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) ProfileThis document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.The Datagram Transport Layer Security (DTLS) Protocol Version 1.3This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.This document obsoletes RFC 6347.Secure Hash Standard (SHS)National Institute of Standards and Technology (NIST)Informative ReferencesSEC 2: Recommended Elliptic Curve Domain ParametersGuideline for Identifying an Information System as a National Security SystemAuthor's AddressNational Security Agencydecoole@nsa.gov