rfc9206v1.txt   rfc9206.txt 
skipping to change at line 175 skipping to change at line 175
ECDSA [FIPS186] (using the NIST P-384 elliptic curve) ECDSA [FIPS186] (using the NIST P-384 elliptic curve)
RSA [FIPS186] (with a modulus of 3072 bits or larger) RSA [FIPS186] (with a modulus of 3072 bits or larger)
Key Establishment: Key Establishment:
ECDH [SP80056A] (using the NIST P-384 elliptic curve) ECDH [SP80056A] (using the NIST P-384 elliptic curve)
DH [RFC3526] (with a prime modulus of 3072 or larger) 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 National Security suites (UI suites) [RFC4308] to implement IPsec on National Security
Systems. 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 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA-384, due to IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to
availability. See 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 Under certain conditions, such as applications having long-lived
data-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, algorithms for Authenticated integrity algorithm. However, algorithms for Authenticated
Encryption with Associated Data (AEAD) [RFC5116] do not require a Encryption with Associated Data (AEAD) [RFC5116] do not require a
separate integrity algorithm to be negotiated. In particular, since separate integrity algorithm to be negotiated. In particular, since
AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST either AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST either
offer no integrity algorithm or indicate the single integrity offer no integrity algorithm or indicate the single integrity
algorithm NONE (see Section 3.3 of [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
skipping to change at line 267 skipping to change at line 266
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 an ECDSA-384 or RSA signature, it MUST return an than an ECDSA-384 or RSA signature, it MUST return an
skipping to change at line 335 skipping to change at line 335
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
the 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 defined in Section 5), the responder MUST return a Notify payload
with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant
mode. 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
described 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 an 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 accommodate 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 allows for the reuse of Diffie-Hellman private keys; see IKEv2 allows for the reuse of Diffie-Hellman private keys; see
Section 2.12 of [RFC7296]. However, there are security concerns Section 2.12 of [RFC7296]. However, there are security concerns
related to this practice. Section 5.6.3.3 of [SP80056A] states that related to this practice. Section 5.6.3.3 of [SP80056A] states that
an ephemeral private key MUST be used in exactly one key an ephemeral private key MUST be used in exactly one key
establishment transaction and MUST be destroyed (zeroized) as soon as establishment transaction and MUST be destroyed (zeroized) as soon as
possible. Section 5.8 of [SP80056A] states that a Diffie-Hellman possible. Section 5.8 of [SP80056A] states that any shared secret
shared secret must be destroyed (zeroized) immediately after its use. derived from key establishment MUST be destroyed (zeroized)
CNSA-compliant IPsec 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
skipping to change at line 437 skipping to change at line 438
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 Pre- the sections above MUST be followed, with the addition of a Pre-
Shared Key (PSK) mixed in as defined in [RFC8784]. Shared Key (PSK) mixed in as defined in [RFC8784].
Installations currently using IKEv1 with PSKs 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 PSKs [RFC8784] as soon as implementations become transition to IKEv2 with PSKs [RFC8784] as soon as implementations
available. 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 National Security Systems solution depend on the program under which the commercial National Security
is developed (e.g., the Commercial Solutions for Classified Systems solution is developed (e.g., an NSA Commercial Solutions for
Capability Package). 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
skipping to change at line 546 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 line 634 skipping to change at line 630
<https://csrc.nist.gov/publications/detail/sp/800-59/ <https://csrc.nist.gov/publications/detail/sp/800-59/
final>. 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. 14 change blocks. 
42 lines changed or deleted 38 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/