| Network Working Group | L. Corcoran |
| Internet-Draft | M. Jenkins |
| Intended status: Informational | NSA |
| Expires: February 18, 2021 | August 17, 2020 |
Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPSec)
draft-corcoran-cnsa-ipsec-profile-01
The United States Government has published the NSA Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPSec. 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2021.
Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies conventions for using the United States National Security Agency's CNSA Suite algorithms [CNSA] in Internet Protocol Security (IPSec). It defines CNSA-based user interface suites ("UI suites") describing sets of security configurations for Internet Key Exchange version 2 (IKEv2) and IP Encapsulating Security Payload (ESP) protocol use. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPSec. US National Security Systems are described in NIST Special Publication 800-59 [SP80059]. 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 reader is assumed to have familiarity with the following:
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.
AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to Diffie-Hellman key establishment. RSA refers to RSA signature.
The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government 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. NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their IA interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
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 Government National Security Systems.
CNSA compliant implementations for IPsec MUST use IKEv2 [RFC7296].
Implementing a CNSA compliant IPSec system requires cryptographic algorithm selection for both the IKEv2 and ESP protocols. The following CNSA requirements apply to IPSec:
To facilitate selection of appropriate combinations of compliant algorithms, this document provides CNSA compliant user interface suites (UI Suites) [RFC4308] to implement IPSec on NSS.
The approved CNSA hash function for all purposes is SHA-384, as defined in [FIPS180]. However, SHA-512 is recommended for PRF instead of 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, such as applications having long-lived data protection requirements, systems that do not comply with the requirements of this document are acceptable; see Section 12.
User Interface (UI) suites are named suites that cover some typical security policy options for IPsec. [RFC4308] Use of UI suites does not change the IPsec protocol in any way. The following UI suites provide cryptographic algorithm choices for ESP [RFC4303] and for Internet Key Exchange (IKEv2) [RFC7296]. The selection of a UI Suite will depend on the key exchange algorithm. The suite names indicate the Advanced Encryption Standard [FIPS197] mode, AES key length specified for encryption, and the key exchange algorithm.
Although RSA is also a CNSA approved key establishment algorithm, in IPSec with IKEv2 only DH or ECDH are implemented for key exchange. [RFC7296] RSA in IPSec is used only for digital signatures. See Section 6.
ESP requires negotiation of both a confidentiality algorithm and an integrity algorithm. However, authenticated encryption (AEAD) algorithms do not require a separate integrity algorithm to be negotiated. [RFC5116] In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST indicate the integrity algorithm NONE. [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 MUST NOT use the names listed here for suites that do not match these values. These requirements are necessary for interoperability.
Other UI suites may be acceptable for CNSA compliance. See Section 8 for details.
Authentication of the IKEv2 Security Association (SA) requires computation of a digital signature. To be CNSA compliant, digital signatures MUST be generated with either ECDSA-384 as defined in [RFC4754] or RSA with 3072-bit or greater modulus and SHA-384 as defined in [RFC8017].
Initiators and responders MUST be able to verify ECDSA-384 signatures and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and SHA-384 signatures.
For CNSA compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 3072-bit modulus or larger MUST be used for RSA. If the relying party receives a message signed with any authentication method other than ECDSA-384 or RSA signature it MUST return an AUTHENTICATION_FAILED notification and stop processing the message. If the relying party receives a message signed with RSA using less than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message.
To be CNSA compliant, the initiator and responder MUST use X.509 certificates that comply with [RFC8603]. The identity authentication method MUST use an end-entity certificate provided by the authenticating party and MUST NOT use the Identification Payload for policy lookup.
Section 5 specifies three UI suites for ESP and IKEv2 Security Associations. All three use AES-GCM for encryption but differ in the key exchange algorithm. Galois Counter Mode (GCM) combines counter (CTR) mode with a secure, parallelizable, and efficient authentication mechanism. [RFC4106] Since AES-GCM is an AEAD algorithm, ESP implements AES-GCM with no additional integrity algorithm. [RFC7296]
An initiator SHOULD offer one or more of the following suites:
A responder SHOULD support at least one of the three named suites.
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.
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.
If none of the suites offered by the initiator consist solely of CNSA algorithms or the named UI Suites, the responder MUST return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA compliant mode.
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 in [RFC7296].
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.
The key used to protect the transport of a key should be at least as strong as the key being transported.
The ECDH shared secret established during the key exchange consists of the x value of the ECDH common value [RFC5903]. Because the P-384 elliptic curve is used, the x value is 384 bits.
IKEv2 [RFC7296] allows for the reuse of Diffie-Hellman exponentials (i.e. private keys). 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 a Diffie-Hellman shared secret must be destroyed (zeroized) immediately after its use. CNSA compliant IPSec systems MUST follow the mandates in [SP80056A].
Because each named UI Suite specified PRF-HMAC-SHA-512 as the PRF, SKEYSEED, SK_d, SK_pi, and SK_pr MUST each be generated to be 512 bits long. SK_ai and SK_ar MUST be 512 bits long. SK_ei and SK_er MUST be 256 bits long since the key length attribute for AES is required by CNSA to be to 256. [RFC7296].
The IPSec protocol AH MUST NOT be used in CNSA compliant implementations.
ESP does not explicitly include a Diffie-Hellman key exchange. [RFC8221] However, a Diffie-Hellman group MAY be negotiated for the Child SA allowing peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange. [RFC7296] If a transform of type 4 is specified for an SA for ESP, the value of the transform MUST match that 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 compliant 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.
IKEv2 does not specify how Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges are used for policy lookup. For CNSA compliant systems, the IKEv2 authentication method MUST NOT use the Identification Payloads for policy lookup. Instead, the authentication method MUST use an end-entity certificate provided by the authenticating party.
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.
The CNSA mandate is to continue to use current algorithms with increased security parameters, then transition to approved post-quantum resilient algorithms when they are identified. However, some applications 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 an approved symmetric algorithm (AES-256) must be used with a pre-shared key (PSK) until approved post-quantum resilient asymmetric algorithms are identified.
For new applications, confidentiality and integrity requirements from the sections above MUST be followed, with the addition of a PSK mixed in as defined in [RFC8784]. Installations currently using IKEv1 with PSK MUST use AES in cipher block chaining mode (AES-CBC) in conjunction with a CNSA compliant integrity algorithm, and transition to IKEv2 with PSK [RFC8784] as soon as implementations become available.
For all applications to which this section applies, PSK authentication MUST be performed using HMAC-SHA-384 [RFC4868].
Specific guidance for systems not compliant with the requirements of this document, including non-GCM modes 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 NSS solution is developed (e.g. Commercial Solutions for Classified Capability Package).
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, be aware that nonce reuse can result in a loss of confidentiality. [RFC5116] Nonce reuse is catastrophic for GCM since it also results in a loss of integrity.
Identifier Reference
===================== ======================
CNSA-GCM-256-ECDH-384 [This RFC]
CNSA-GCM-256-DH-3072 [This RFC]
CNSA-GCM-256-DH-4096 [This RFC]
IANA is asked to amend the registry titled "Cryptographic Suites for IKEv1, IKEv2, and IPsec" located at https://www.iana.org/assignments/crypto-suites as described in this section. The registry consists of a text string and an RFC number that lists the associated transforms. The UI suites defined in this document are listed, with this document as the RFC reference.
| [RFC4308] | Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, DOI 10.17487/RFC4308, December 2005. |
| [RFC8452] | Gueron, S., Langley, A. and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019. |
| [SP80059] | National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 800-59 , August 2003. |