rfc9206.original   rfc9206.txt 
Network Working Group L. Corcoran Independent Submission L. Corcoran
Internet-Draft M. Jenkins Request for Comments: 9206 M. Jenkins
Intended status: Informational NSA Category: Informational NSA
Expires: 15 July 2022 11 January 2022 ISSN: 2070-1721 February 2022
Commercial National Security Algorithm (CNSA) Suite Cryptography for Commercial National Security Algorithm (CNSA) Suite Cryptography for
Internet Protocol Security (IPsec) Internet Protocol Security (IPsec)
draft-corcoran-cnsa-ipsec-profile-06
Abstract Abstract
The United States Government has published the National Security The United States Government has published the National Security
Agency's Commercial National Security Algorithm (CNSA) Suite, which Agency's Commercial National Security Algorithm (CNSA) Suite, which
defines cryptographic algorithm policy for national security defines cryptographic algorithm policy for national security
applications. This document specifies the conventions for using the applications. This document specifies the conventions for using the
United States National Security Agency's CNSA Suite algorithms in United States National Security Agency's CNSA Suite algorithms in
Internet Protocol Security. It applies to the capabilities, Internet Protocol Security (IPsec). It applies to the capabilities,
configuration, and operation of all components of US National configuration, and operation of all components of US National
Security Systems that employ IPsec. US National Security Systems are Security Systems (described in NIST Special Publication 800-59) that
described in NIST Special Publication 800-59. It is also appropriate employ IPsec. This document is also appropriate for all other US
for all other US Government systems that process high-value Government systems that process high-value information. It is made
information. It is made publicly available for use by developers and publicly available for use by developers and operators of these and
operators of these and any other system deployments. any other system deployments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 15 July 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9206.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. The Commercial National Security Algorithm Suite . . . . . . 3 3. The Commercial National Security Algorithm Suite
4. CNSA Compliant IPsec Overview . . . . . . . . . . . . . . . . 4 4. CNSA-Compliant IPsec Overview
5. IPsec User Interface Suites . . . . . . . . . . . . . . . . . 5 5. IPsec User Interface Suites
5.1. Suite CNSA-GCM-256-ECDH-384 . . . . . . . . . . . . . . . 5 5.1. Suite CNSA-GCM-256-ECDH-384
5.2. Suite CNSA-GCM-256-DH-3072 . . . . . . . . . . . . . . . 6 5.2. Suite CNSA-GCM-256-DH-3072
5.3. Suite CNSA-GCM-256-DH-4096 . . . . . . . . . . . . . . . 6 5.3. Suite CNSA-GCM-256-DH-4096
6. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 6 6. IKEv2 Authentication
7. Certificates . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Certificates
8. IKEv2 Security Associations (SA) . . . . . . . . . . . . . . 7 8. IKEv2 Security Associations (SAs)
9. The Key Exchange Payload in the IKE_SA_INIT Exchange . . . . 8 9. The Key Exchange Payload in the IKE_SA_INIT Exchange
10. Generating Key Material for the IKE SA . . . . . . . . . . . 8 10. Generating Key Material for the IKE SA
11. Additional Requirements . . . . . . . . . . . . . . . . . . . 8 11. Additional Requirements
12. Guidance for Applications With Long Data-Protection 12. Guidance for Applications with Long Data-Protection
Requirements . . . . . . . . . . . . . . . . . . . . . . 9 Requirements
13. Security Considerations . . . . . . . . . . . . . . . . . . . 10 13. Security Considerations
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 14. IANA Considerations
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 15. References
15.1. Normative References . . . . . . . . . . . . . . . . . . 11 15.1. Normative References
15.2. Informative References . . . . . . . . . . . . . . . . . 13 15.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
This document specifies conventions for using the United States This document specifies the conventions for using the United States
National Security Agency's Commercial National Security Algorithm National Security Agency's (NSA's) Commercial National Security
(CNSA) Suite algorithms [CNSA] in Internet Protocol Security (IPsec). Algorithm (CNSA) Suite algorithms [CNSA] in Internet Protocol
It defines CNSA-based user interface suites ("UI suites") describing Security (IPsec). It defines CNSA-based User Interface suites ("UI
sets of security configurations for Internet Key Exchange version 2 suites") describing sets of security configurations for Internet Key
(IKEv2) and IP Encapsulating Security Payload (ESP) protocol use, and Exchange Protocol Version 2 (IKEv2) and IP Encapsulating Security
specifies certain other constraints with respect to algorithm Payload (ESP) protocol use, and specifies certain other constraints
selection and configuration. It applies to the capabilities, with respect to algorithm selection and configuration. It applies to
configuration, and operation of all components of US National the capabilities, configuration, and operation of all components of
Security Systems that employ IPsec. US National Security Systems are US National Security Systems (described in NIST Special Publication
described in NIST Special Publication 800-59 [SP80059]. It is also 800-59 [SP80059]) that employ IPsec. This document is also
appropriate for all other US Government systems that process high- appropriate for all other US Government systems that process high-
value information. It is made publicly available for use by value information. It is made publicly available for use by
developers and operators of these and any other system deployments. developers and operators of these and any other system deployments.
The reader is assumed to have familiarity with the following: The reader is assumed to have familiarity with the following:
[RFC4303], IP Encapsulating Security Payload (ESP) * "IP Encapsulating Security Payload (ESP)" [RFC4303]
[RFC5280], Internet X.509 Public Key Infrastructure Certificate * "Internet X.509 Public Key Infrastructure Certificate and
and Certificate Revocation List (CRL) Profile Certificate Revocation List (CRL) Profile" [RFC5280]
[RFC7296], Internet Key Exchange Version 2 (IKEv2) * "Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC7296]
[RFC8221], Cryptographic Algorithm Implementation Requirements and * "Cryptographic Algorithm Implementation Requirements and Usage
Usage Guidance for Encapsulating Security Payload (ESP) and Guidance for Encapsulating Security Payload (ESP) and
Authentication Header (AH) Authentication Header (AH)" [RFC8221]
[RFC8603], Commercial National Security Algorithm (CNSA) Suite * "Commercial National Security Algorithm (CNSA) Suite Certificate
Certificate and Certificate Revocation List (CRL) Profile and Certificate Revocation List (CRL) Profile" [RFC8603]
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer
to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA)
and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to
Diffie-Hellman key establishment. RSA refers to RSA signature. Diffie-Hellman key establishment. RSA refers to an RSA signature.
3. The Commercial National Security Algorithm Suite 3. The Commercial National Security Algorithm Suite
The National Security Agency (NSA) profiles commercial cryptographic The NSA profiles commercial cryptographic algorithms and protocols as
algorithms and protocols as part of its mission to support secure, part of its mission to support secure, interoperable communications
interoperable communications for US Government National Security for US Government National Security Systems. To this end, it
Systems. To this end, it publishes guidance both to assist with the publishes guidance to both (1) assist with the US Government
US Government transition to new algorithms, and to provide vendors - transition to new algorithms and (2) provide vendors -- and the
and the Internet community in general - with information concerning Internet community in general -- with information concerning their
their proper use and configuration. proper use and configuration.
Recently, cryptographic transition plans have become overshadowed by Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically-relevant the prospect of the development of a cryptographically relevant
quantum computer. NSA has established the Commercial National quantum computer. The NSA has established the Commercial National
Security Algorithm (CNSA) Suite to provide vendors and IT users near- Security Algorithm (CNSA) Suite to provide vendors and IT users near-
term flexibility in meeting their information assurance term flexibility in meeting their information assurance
interoperability requirements. The purpose behind this flexibility interoperability requirements. The purpose behind this flexibility
is to avoid vendors and customers making two major transitions in a is to avoid vendors and customers making two major transitions in a
relatively short timeframe, as we anticipate a need to shift to relatively short timeframe, as we anticipate a need to shift to
quantum-resistant cryptography in the near future. quantum-resistant cryptography in the near future.
NSA is authoring a set of RFCs, including this one, to provide The NSA is authoring a set of RFCs, including this one, to provide
updated guidance concerning the use of certain commonly available updated guidance concerning the use of certain commonly available
commercial algorithms in IETF protocols. These RFCs can be used in commercial algorithms in IETF protocols. These RFCs can be used in
conjunction with other RFCs and cryptographic guidance (e.g., NIST conjunction with other RFCs and cryptographic guidance (e.g., NIST
Special Publications) to properly protect Internet traffic and data- Special Publications) to properly protect Internet traffic and data-
at-rest for US Government National Security Systems. at-rest for US Government National Security Systems.
4. CNSA Compliant IPsec Overview 4. CNSA-Compliant IPsec Overview
CNSA compliant implementations for IPsec MUST use IKEv2 [RFC7296]. CNSA-compliant implementations for IPsec MUST use IKEv2 [RFC7296].
Implementing a CNSA compliant IPsec system requires cryptographic Implementing a CNSA-compliant IPsec system requires cryptographic
algorithm selection for both the IKEv2 and ESP protocols. The algorithm selection for both the IKEv2 and ESP protocols. The
following CNSA requirements apply to IPsec: following CNSA requirements apply to IPsec:
Encryption: Encryption:
AES [FIPS197] (with key size 256 bits)
Digital Signature: AES [FIPS197] (with key size 256 bits)
ECDSA [FIPS186] (using the NIST P-384 elliptic curve)
RSA [FIPS186] (with a modulus of 3072 bits or larger)
Key Establishment: Digital Signature:
ECDH [SP80056A] (using the NIST P-384 elliptic curve)
DH [RFC3526] (with a prime modulus of 3072 or larger) ECDSA [FIPS186] (using the NIST P-384 elliptic curve)
RSA [FIPS186] (with a modulus of 3072 bits or larger)
Key Establishment:
ECDH [SP80056A] (using the NIST P-384 elliptic curve)
DH [RFC3526] (with a prime modulus of 3072 or larger)
To facilitate selection of appropriate combinations of compliant To facilitate selection of appropriate combinations of compliant
algorithms, this document provides CNSA compliant user interface algorithms, this document provides CNSA-compliant User Interface
suites (UI Suites) [RFC4308] to implement IPsec on NSS. suites (UI suites) [RFC4308] to implement IPsec on National Security
Systems.
The approved CNSA hash function for all purposes is SHA-384, as The approved CNSA hash function for all purposes is SHA-384, as
defined in [FIPS180]. However, PRF_HMAC_SHA-512 is specified for the defined in [FIPS180]. However, PRF_HMAC_SHA_512 is specified for the
IKEv2 PRF instead of PRF_HMAC_SHA-384 due to availability. See IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to
Section 8 below. availability. See Section 8 below.
For CNSA Suite applications, public key certificates MUST be For CNSA Suite applications, public key certificates MUST be
compliant with the CNSA Suite Certificate and CRL Profile specified compliant with the CNSA Suite Certificate and CRL Profile specified
in [RFC8603]. in [RFC8603].
Under certain conditions, such as applications having long-lived data Under certain conditions, such as applications having long-lived
protection requirements, systems that do not comply with the data-protection requirements, systems that do not comply with the
requirements of this document are acceptable; see Section 12. requirements of this document are acceptable; see Section 12.
5. IPsec User Interface Suites 5. IPsec User Interface Suites
User Interface (UI) suites [RFC4308] are named suites that cover some User Interface (UI) suites [RFC4308] are named suites that cover some
typical security policy options for IPsec. Use of UI suites does not typical security policy options for IPsec. Use of UI suites does not
change the IPsec protocol in any way. The following UI suites change the IPsec protocol in any way. The following UI suites
provide cryptographic algorithm choices for ESP [RFC4303] and for provide cryptographic algorithm choices for ESP [RFC4303] and for
Internet Key Exchange (IKEv2) [RFC7296]. The selection of a UI Suite IKEv2 [RFC7296]. The selection of a UI suite will depend on the key
will depend on the key exchange algorithm. The suite names indicate exchange algorithm. The suite names indicate the Advanced Encryption
the Advanced Encryption Standard [FIPS197] mode, AES key length Standard [FIPS197] mode, AES key length specified for encryption, and
specified for encryption, and the key exchange algorithm. the key exchange algorithm.
Although RSA is also a CNSA approved key establishment algorithm, in Although RSA is also a CNSA-approved key establishment algorithm,
IPsec with IKEv2 [RFC7296] only DH or ECDH are implemented for key only DH and ECDH are specified for key exchange in IKEv2 [RFC7296].
exchange. RSA in IPsec is used only for digital signatures. See RSA in IPsec is used only for digital signatures. See Section 6.
Section 6.
ESP requires negotiation of both a confidentiality algorithm and an ESP requires negotiation of both a confidentiality algorithm and an
integrity algorithm. However, authenticated encryption (AEAD) integrity algorithm. However, algorithms for Authenticated
algorithms [RFC5116] do not require a separate integrity algorithm to Encryption with Associated Data (AEAD) [RFC5116] do not require a
be negotiated. In particular, since AES-GCM is an AEAD algorithm, separate integrity algorithm to be negotiated. In particular, since
ESP implementing AES-GCM MUST either offer no integrity algorithm, or AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST either
indicate the single integrity algorithm NONE (see Section 3.3 of offer no integrity algorithm or indicate the single integrity
[RFC7296]). algorithm NONE (see Section 3.3 of [RFC7296]).
To be CNSA compliant, IPsec implementations that use the following UI To be CNSA compliant, IPsec implementations that use the following UI
suites MUST use the suite names listed below. IPsec implementations suites MUST use the suite names listed below. IPsec implementations
SHOULD NOT use names different than those listed here for the suites 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 are described and MUST NOT use the names listed here for suites
that do not match these values. These requirements are necessary for that do not match these values. These requirements are necessary for
interoperability. interoperability.
Transform names are as listed in the IANA registry for Internet Key Transform names are as listed in the IANA "Internet Key Exchange
Exchange Version 2 (IKEv2) Parameters. Definitions of the transforms Version 2 (IKEv2) Parameters" registry. Definitions of the
are contained in the references specified in that registry. transforms are contained in the references specified in that
registry.
Other UI suites may be acceptable for CNSA compliance. See Section 8 Other UI suites may be acceptable for CNSA compliance. See Section 8
for details. for details.
5.1. Suite CNSA-GCM-256-ECDH-384 5.1. Suite CNSA-GCM-256-ECDH-384
ESP SA: ESP SA:
Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Encryption: ENCR_AES_GCM_16 (with key size 256 bits)
Integrity: NONE Integrity: NONE
IKEv2 SA: IKEv2 SA:
Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Encryption: ENCR_AES_GCM_16 (with key size 256 bits)
PRF: PRF_HMAC_SHA2_512 PRF: PRF_HMAC_SHA2_512
Integrity: NONE Integrity: NONE
Diffie-Hellman group: 384-bit random ECP group Diffie-Hellman group: 384-bit random ECP group
5.2. Suite CNSA-GCM-256-DH-3072 5.2. Suite CNSA-GCM-256-DH-3072
ESP SA: ESP SA:
Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Encryption: ENCR_AES_GCM_16 (with key size 256 bits)
Integrity: NONE Integrity: NONE
IKEv2 SA: IKEv2 SA:
Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Encryption: ENCR_AES_GCM_16 (with key size 256 bits)
PRF: PRF_HMAC_SHA2_512 PRF: PRF_HMAC_SHA2_512
Integrity: NONE Integrity: NONE
Diffie-Hellman group: 3072-bit MODP Group Diffie-Hellman group: 3072-bit MODP group
5.3. Suite CNSA-GCM-256-DH-4096 5.3. Suite CNSA-GCM-256-DH-4096
ESP SA: ESP SA:
Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Encryption: ENCR_AES_GCM_16 (with key size 256 bits)
Integrity: NONE Integrity: NONE
IKEv2 SA: IKEv2 SA:
Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Encryption: ENCR_AES_GCM_16 (with key size 256 bits)
PRF: PRF_HMAC_SHA2_512 PRF: PRF_HMAC_SHA2_512
Integrity: NONE Integrity: NONE
Diffie-Hellman group: 4096-bit MODP Group Diffie-Hellman group: 4096-bit MODP group
6. IKEv2 Authentication 6. IKEv2 Authentication
Authentication of the IKEv2 Security Association (SA) requires Authentication of the IKEv2 Security Association (SA) requires
computation of a digital signature. To be CNSA compliant, digital computation of a digital signature. To be CNSA compliant, digital
signatures MUST be generated with either ECDSA-384 as defined in signatures MUST be generated with SHA-384 as defined in [RFC8017]
[RFC4754] or RSA with 3072-bit or greater modulus and SHA-384 as together with either ECDSA-384 as defined in [RFC4754] or RSA with
defined in [RFC8017]. (For applications with long data-protection 3072-bit or greater modulus. (For applications with long data-
requirements, somewhat different rules apply; see Section 12.) protection requirements, somewhat different rules apply; see
Section 12.)
Initiators and responders MUST be able to verify ECDSA-384 signatures 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 and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and
SHA-384 signatures. SHA-384 signatures.
For CNSA compliant systems, authentication methods other than For CNSA-compliant systems, authentication methods other than
ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 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 3072-bit modulus or larger MUST be used for RSA. If the relying
party receives a message signed with any authentication method other party receives a message signed with any authentication method other
than ECDSA-384 or RSA signature it MUST return an than an ECDSA-384 or RSA signature, it MUST return an
AUTHENTICATION_FAILED notification and stop processing the message. AUTHENTICATION_FAILED notification and stop processing the message.
If the relying party receives a message signed with RSA using less If the relying party receives a message signed with RSA using less
than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED
notification and stop processing the message. notification and stop processing the message.
7. Certificates 7. Certificates
To be CNSA compliant, the initiator and responder MUST use X.509 To be CNSA compliant, the initiator and responder MUST use X.509
certificates that comply with [RFC8603]. Peer authentication certificates that comply with [RFC8603]. Peer authentication
decisions must be based on the Subject or Subject Alternative Name decisions must be based on the Subject or Subject Alternative Name
from the certificate that contains the key used to validate the from the certificate that contains the key used to validate the
signature in the Authentication Payload defined in Section 3.8 of signature in the Authentication Payload as defined in Section 3.8 of
[RFC7296], rather than the Identification Data from the [RFC7296], rather than the Identification Data from the
Identification Payload that is used to look up policy. Identification Payload that is used to look up policy.
8. IKEv2 Security Associations (SA) 8. IKEv2 Security Associations (SAs)
Section 5 specifies three UI suites for ESP and IKEv2 Security Section 5 specifies three UI suites for ESP and IKEv2 Security
Associations. All three use AES-GCM for encryption but differ in the Associations. All three use AES-GCM for encryption but differ in the
key exchange algorithm. Galois Counter Mode (GCM) [RFC4106] combines key exchange algorithm. Galois/Counter Mode (GCM) [RFC4106] combines
counter (CTR) mode with a secure, parallelizable, and efficient counter (CTR) mode with a secure, parallelizable, and efficient
authentication mechanism. Since AES-GCM is an AEAD algorithm, ESP authentication mechanism. Since AES-GCM is an AEAD algorithm, ESP
implements AES-GCM with no additional integrity algorithm (see implements AES-GCM with no additional integrity algorithm (see
Section 3.3 of [RFC7296]). Section 3.3 of [RFC7296]).
An initiator proposal SHOULD be constructed from one or more of the An initiator proposal SHOULD be constructed from one or more of the
following suites: following suites:
CNSA-GCM-256-ECDH-384, * CNSA-GCM-256-ECDH-384
CNSA-GCM-256-DH-3072, * CNSA-GCM-256-DH-3072
CNSA-GCM-256-DH-4096. * CNSA-GCM-256-DH-4096
A responder SHOULD accept proposals constructed from at least one of A responder SHOULD accept proposals constructed from at least one of
the three named suites. Other UI suites may result in acceptable the three named suites. Other UI suites may result in acceptable
proposals (such as those based on PRF_HMAC_SHA2_384); however, these proposals (such as those based on PRF_HMAC_SHA2_384); however, these
are provided to promote interoperability. are provided to promote interoperability.
Nonce construction for AES-GCM using a misuse-resistant technique Nonce construction for AES-GCM using a misuse-resistant technique
[RFC8452] conforms with the requirements of this document and MAY be [RFC8452] conforms with the requirements of this document and MAY be
used if a Federal Information Processing Standard (FIPS) validated used if a Federal Information Processing Standard (FIPS) validated
implementation is available. implementation is available.
The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF
transform as PRF_HMAC_SHA2_384 is not listed among required PRF transform, as PRF_HMAC_SHA2_384 is not listed among required PRF
transforms in [RFC8247]; therefore, implementation of the latter is transforms in [RFC8247]; therefore, implementation of the latter is
likely to be scarce. The security level of PRF_HMAC_SHA2_512 is likely to be scarce. The security level of PRF_HMAC_SHA2_512 is
comparable, and the difference in performance is negligible. comparable, and the difference in performance is negligible.
However, SHA-384 is the official CNSA algorithm for computing a However, SHA-384 is the official CNSA algorithm for computing a
condensed representation of information. Therefore, the condensed representation of information. Therefore, the
PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to
initiator and responder. Any PRF transform other than the initiator and responder. Any PRF transform other than
PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used. PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used.
If none of the proposals offered by the initiator consist solely of If none of the proposals offered by the initiator consist solely of
transforms based on CNSA algorithms (such as those in the UI Suites transforms based on CNSA algorithms (such as those in the UI suites
defined in Section 5, the responder MUST return a Notify payload with defined in Section 5), the responder MUST return a Notify payload
the error NO_PROPOSAL_CHOSEN when operating in CNSA compliant mode. with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant
mode.
9. The Key Exchange Payload in the IKE_SA_INIT Exchange 9. The Key Exchange Payload in the IKE_SA_INIT Exchange
The key exchange payload is used to exchange Diffie-Hellman public The key exchange payload is used to exchange Diffie-Hellman public
numbers as part of a Diffie-Hellman key exchange. The CNSA compliant numbers as part of a Diffie-Hellman key exchange. The CNSA-compliant
initiator and responder MUST each generate an ephemeral key pair to initiator and responder MUST each generate an ephemeral key pair to
be used in the key exchange. be used in the key exchange.
If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected
for the SA, the initiator and responder both MUST generate an for the SA, the initiator and responder both MUST generate an
elliptic curve (EC) key pair using the P-384 elliptic curve. The elliptic curve (EC) key pair using the P-384 elliptic curve. The
ephemeral public keys MUST be stored in the key exchange payload as ephemeral public keys MUST be stored in the key exchange payload as
in [RFC7296]. described in [RFC5903].
If the Diffie-Hellman (DH) key exchange is selected for the SA, the If the Diffie-Hellman (DH) key exchange is selected for the SA, the
initiator and responder both MUST generate a key pair using the initiator and responder both MUST generate a key pair using the
appropriately sized MODP group as described in [RFC3526]. The size appropriately sized MODP group as described in [RFC3526]. The size
of the MODP group will be determined by the selection of either a of the MODP group will be determined by the selection of either a
3072-bit or greater modulus for the SA. 3072-bit or greater modulus for the SA.
10. Generating Key Material for the IKE SA 10. Generating Key Material for the IKE SA
As noted in Section 7 of [RFC5903], the shared secret result of a 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. 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 The shared secret result of a DH key exchange is the number of octets
needed to accomodate the prime (e.g. 384 octets for 3072 MODP) with needed to accommodate the prime (e.g., 384 octets for 3072-bit MODP
leading zeros as necessary, as described in Section 2.1.2 of group) with leading zeros as necessary, as described in Section 2.1.2
[RFC2631]. of [RFC2631].
IKEv2, Section 2.12 [RFC7296] allows for the reuse of Diffie-Hellman IKEv2 allows for the reuse of Diffie-Hellman private keys; see
private keys. However, there are security concerns related to this Section 2.12 of [RFC7296]. However, there are security concerns
practice. Section 5.6.3.3 of [SP80056A] states that an ephemeral related to this practice. Section 5.6.3.3 of [SP80056A] states that
private key MUST be used in exactly one key establishment transaction an ephemeral private key MUST be used in exactly one key
and MUST be destroyed (zeroized) as soon as possible. Section 5.8 of establishment transaction and MUST be destroyed (zeroized) as soon as
[SP80056A] states that a Diffie-Hellman shared secret must be possible. Section 5.8 of [SP80056A] states that any shared secret
destroyed (zeroized) immediately after its use. CNSA compliant IPsec derived from key establishment MUST be destroyed (zeroized)
systems MUST follow the mandates in [SP80056A]. immediately after its use. CNSA-compliant IPsec systems MUST follow
the mandates in [SP80056A].
11. Additional Requirements 11. Additional Requirements
The IPsec protocol AH MUST NOT be used in CNSA compliant The IPsec protocol AH MUST NOT be used in CNSA-compliant
implementations. implementations.
A Diffie-Hellman group MAY be negotiated for a Child SA as described 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 Section 1.3 of [RFC7296], allowing peers to employ Diffie-Hellman
in the CREATE_CHILD_SA exchange. If a transform of type 4 is 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 specified for an SA for ESP, the value of that transform MUST match
the value of the transform used by the IKEv2 SA. the value of the transform used by the IKEv2 SA.
Per [RFC7296], if a CREATE_CHILD_SA exchange includes a KEi payload, 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 at least one of the SA offers MUST include the Diffie-Hellman group
of the KEi. For CNSA compliant IPsec compliant implementations, the of the KEi. For CNSA-compliant IPsec implementations, the Diffie-
Diffie-Hellman group of the KEi MUST use the same group used in the Hellman group of the KEi MUST use the same group used in the
IKE_INIT_SA. IKE_INIT_SA.
For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both
parties. The initiator of this exchange MAY include a new Diffie- 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 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- 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 Hellman key, the responder MUST include a Diffie-Hellman key, and it
MUST use the same group. MUST use the same group.
For CNSA compliant systems, the IKEv2 authentication method MUST use For CNSA-compliant systems, the IKEv2 authentication method MUST use
an end-entity certificate provided by the authenticating party. an end-entity certificate provided by the authenticating party.
Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST Identification Payloads (IDi and IDr) in the IKE_AUTH exchanges MUST
NOT be used for the IKEv2 authentication method , but may be used for NOT be used for the IKEv2 authentication method but may be used for
policy lookup. policy lookup.
The administrative user interface (UI) for a system that conforms to The administrative User Interface (UI) for a system that conforms to
this profile MUST allow the operator to specify a single suite. If this profile MUST allow the operator to specify a single suite. If
only one suite is specified in the administrative UI, the IKEv2 only one suite is specified in the administrative UI, the IKEv2
implementation MUST only offer algorithms for that one suite. implementation MUST only offer algorithms for that one suite.
The administrative UI MAY allow the operator to specify more than one 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 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. preferred order for the suites that are to be offered or accepted.
If more than one suite is specified in the administrative UI, the If more than one suite is specified in the administrative UI, the
IKEv2 implementation MUST only offer algorithms of those suites. IKEv2 implementation MUST only offer algorithms of those suites.
(Note that although this document does not define a UI suite (Note that although this document does not define a UI suite
specifying PRF_HMAC_SHA2_384, a proposal containing such a transform specifying PRF_HMAC_SHA2_384, a proposal containing such a transform
is CNSA compliant.) is CNSA compliant.)
12. Guidance for Applications With Long Data-Protection Requirements 12. Guidance for Applications with Long Data-Protection Requirements
The CNSA mandate is to continue to use current algorithms with The CNSA mandate is to continue to use current algorithms with
increased security parameters, then transition to approved post- increased security parameters, then transition to approved post-
quantum resilient algorithms when they are identified. However, some quantum resilient algorithms when they are identified. However, some
applications have data-in-transit-protection requirements that are applications have data-in-transit-protection requirements that are
long enough that post-quantum resilient protection must be provided long enough that post-quantum resilient protection must be provided
now. Lacking approved asymmetric post-quantum resilient now. Lacking approved asymmetric post-quantum resilient
confidentiality algorithms, that means approved symmetric techniques confidentiality algorithms, that means approved symmetric techniques
must be used as described in this section until approved post-quantum must be used as described in this section until approved post-quantum
resilient asymmetric algorithms are identified. resilient asymmetric algorithms are identified.
For new applications, confidentiality and integrity requirements from For new applications, confidentiality and integrity requirements from
the sections above MUST be followed, with the addition of a PSK mixed the sections above MUST be followed, with the addition of a Pre-
in as defined in [RFC8784]. Shared Key (PSK) mixed in as defined in [RFC8784].
Installations currently using IKEv1 with PSK MUST use AES in cipher Installations currently using IKEv1 with PSKs MUST (1) use AES in
block chaining mode (AES-CBC) in conjunction with a CNSA compliant cipher block chaining mode (AES-CBC) in conjunction with a CNSA-
integrity algorithm (e.g. AUTH_HMAC_SHA2_384_192), and transition to compliant integrity algorithm (e.g., AUTH_HMAC_SHA2_384_192) and (2)
IKEv2 with PSK [RFC8784] as soon as implementations become available. transition to IKEv2 with PSKs [RFC8784] as soon as implementations
become available.
Specific guidance for systems not compliant with the requirements of Specific guidance for systems not compliant with the requirements of
this document, including non-GCM modes and PSK length and randomness, this document, including non-GCM modes and PSK length, and PSK
will be defined in solution specific requirements appropriate to the randomness, will be defined in solution-specific requirements
application. Details of those requirements will depend on the appropriate to the application. Details of those requirements will
program under which the commercial NSS solution is developed (e.g. depend on the program under which the commercial National Security
Commercial Solutions for Classified Capability Package). Systems solution is developed (e.g., an NSA Commercial Solutions for
Classified Capability Package).
13. Security Considerations 13. Security Considerations
This document inherits all of the security considerations of the This document inherits all of the security considerations of the
IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754], IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754],
and [RFC8221]. and [RFC8221].
The security of a system that uses cryptography depends on both the The security of a system that uses cryptography depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
the engineering and administration of the protocol used by the system the engineering and administration of the protocol used by the system
to ensure that there are no non-cryptographic ways to bypass the to ensure that there are no non-cryptographic ways to bypass the
security of the overall system. security of the overall system.
When selecting a mode for the AES encryption [RFC5116] , be aware When selecting a mode for the AES encryption [RFC5116], be aware that
that nonce reuse can result in a loss of confidentiality. Nonce nonce reuse can result in a loss of confidentiality. Nonce reuse is
reuse is catastrophic for GCM since it also results in a loss of catastrophic for GCM, since it also results in a loss of integrity.
integrity.
14. IANA Considerations 14. IANA Considerations
IANA is asked to amend the registry titled "Cryptographic Suites for IANA has added the UI suites defined in this document to the
IKEv1, IKEv2, and IPsec" located at https://www.iana.org/assignments/ "Cryptographic Suites for IKEv1, IKEv2, and IPsec" registry located
crypto-suites as described in this section. The registry consists of at <https://www.iana.org/assignments/crypto-suites>:
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.
+-----------------------+--------------------------------+ +=======================+===========+
| Identifier | Reference | | Identifier | Reference |
+-----------------------+--------------------------------+ +=======================+===========+
| CNSA-GCM-256-ECDH-384 | [this document when published] | | CNSA-GCM-256-ECDH-384 | RFC 9206 |
+-----------------------+--------------------------------+ +-----------------------+-----------+
| CNSA-GCM-256-DH-3072 | [this document when published] | | CNSA-GCM-256-DH-3072 | RFC 9206 |
+-----------------------+--------------------------------+ +-----------------------+-----------+
| CNSA-GCM-256-DH-4096 | [this document when published] | | CNSA-GCM-256-DH-4096 | RFC 9206 |
+-----------------------+--------------------------------+ +-----------------------+-----------+
Table 1 Table 1
15. References 15. References
15.1. Normative References 15.1. Normative References
[CNSA] Committee for National Security Systems, "Use of Public [CNSA] Committee for National Security Systems, "Use of Public
Standards for Secure Information Sharing", CNSSP 15, Standards for Secure Information Sharing", CNSSP 15,
October 2016, October 2016,
<https://www.cnss.gov/CNSS/Issuances/Policies.htm>. <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.
[FIPS180] National Institute of Standards and Technology, "Secure [FIPS180] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", Federal Information Processing Hash Standard (SHS)", Federal Information Processing
Standard 180-4, August 2015, Standard 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/ <https://csrc.nist.gov/publications/detail/fips/180/4/
final>. final>.
[FIPS186] National Institute of Standards and Technology, "Digital [FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", NIST Federal Information Signature Standard (DSS)", NIST Federal Information
Processing Standard 186-4, July 2013, Processing Standard 186-4, DOI 10.6028/NIST.FIPS.186-4,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ July 2013,
NIST.FIPS.186-4.pdf>. <https://csrc.nist.gov/publications/detail/fips/186/4/
final>.
[FIPS197] National Institute of Standards and Technology, "Advanced [FIPS197] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Processing Encryption Standard (AES)", Federal Information Processing
Standard 197, November 2001, Standard 197, DOI 10.6028/NIST.FIPS.197, November 2001,
<https://csrc.nist.gov/publications/detail/fips/197/ <https://csrc.nist.gov/publications/detail/fips/197/
final>. final>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999, RFC 2631, DOI 10.17487/RFC2631, June 1999,
skipping to change at page 12, line 28 skipping to change at line 547
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
DOI 10.17487/RFC4308, December 2005, DOI 10.17487/RFC4308, December 2005,
<https://www.rfc-editor.org/info/rfc4308>. <https://www.rfc-editor.org/info/rfc4308>.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)", the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, DOI 10.17487/RFC4754, January 2007, RFC 4754, DOI 10.17487/RFC4754, January 2007,
<https://www.rfc-editor.org/info/rfc4754>. <https://www.rfc-editor.org/info/rfc4754>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 13, line 42 skipping to change at line 604
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange "Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security", Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020, RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>. <https://www.rfc-editor.org/info/rfc8784>.
[SP80056A] National Institute of Standards and Technology, [SP80056A] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, Revision 3, April 2018, Publication 800-56A, Revision 3,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
NIST.SP.800-56Ar3.pdf>. <https://csrc.nist.gov/publications/detail/sp/800-56a/rev-
3/final>.
15.2. Informative References 15.2. Informative References
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV:
Nonce Misuse-Resistant Authenticated Encryption", Nonce Misuse-Resistant Authenticated Encryption",
RFC 8452, DOI 10.17487/RFC8452, April 2019, RFC 8452, DOI 10.17487/RFC8452, April 2019,
<https://www.rfc-editor.org/info/rfc8452>. <https://www.rfc-editor.org/info/rfc8452>.
[SP80059] National Institute of Standards and Technology, "Guideline [SP80059] National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National for Identifying an Information System as a National
Security System", Special Publication 800-59 , August Security System", Special Publication 800-59,
2003, <https://csrc.nist.gov/publications/detail/sp/800- DOI 10.6028/NIST.SP.800-59, August 2003,
59/final>. <https://csrc.nist.gov/publications/detail/sp/800-59/
final>.
Authors' Addresses Authors' Addresses
Laura Corcoran Laura Corcoran
National Security Agency National Security Agency
Email: lscorco@nsa.gov Email: lscorco@nsa.gov
Michael Jenkins Michael Jenkins
National Security Agency National Security Agency - Center for Cybersecurity Standards
Email: mjjenki@cyber.nsa.gov Email: mjjenki@cyber.nsa.gov
 End of changes. 74 change blocks. 
236 lines changed or deleted 233 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/