Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPSec)
draft-corcoran-cnsa-ipsec-profile-00

Network Working Group                                        L. Corcoran
Internet-Draft                                                M. Jenkins
Intended status: Informational                                       NSA
Expires: June 6, 2020                                   December 4, 2019

  Commercial National Security Algorithm (CNSA) Suite Cryptography for
                   Internet Protocol Security (IPSec)
                  draft-corcoran-cnsa-ipsec-profile-00

Abstract

   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.

Status of This Memo

   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 June 6, 2020.

Copyright Notice

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

Corcoran & Jenkins        Expires June 6, 2020                  [Page 1]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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.

Table of Contents

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

1.  Introduction

   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-

Corcoran & Jenkins        Expires June 6, 2020                  [Page 2]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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:

   o  [RFC4303], IP Encapsulating Security Payload (ESP)

   o  [RFC5280], Internet X.509 Public Key Infrastructure Certificate
      and Certificate Revocation List (CRL) Profile

   o  [RFC7296], Internet Key Exchange Version 2 (IKEv2)

   o  [RFC8221], Cryptographic Algorithm Implementation Requirements and
      Usage Guidance for Encapsulating Security Payload (ESP) and
      Authentication Header (AH)

   o  [RFC8603], Commercial National Security Algorithm (CNSA) Suite
      Certificate and Certificate Revocation List (CRL) Profile

2.  Terminology

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

   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.

3.  The Commercial National Security Algorithm Suite

   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

Corcoran & Jenkins        Expires June 6, 2020                  [Page 3]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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.

4.  CNSA Compliant IPSec Overview

   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:

      Encryption:

         AES [FIPS197] (with key size 256 bits)

      Digital Signature:

         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
   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].

Corcoran & Jenkins        Expires June 6, 2020                  [Page 4]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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.

5.  IPSec User Interface Suites

   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.

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

      ESP SA:

         Encryption: AES with 256-bit keys and 16-octet ICV in GCM mode
         [RFC4106]

         Integrity: NULL

      IKEv2 SA:

Corcoran & Jenkins        Expires June 6, 2020                  [Page 5]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

         Encryption: AEAD_AES_256_GCM - AES with 256-bit keys in GCM
         mode [RFC5282]

         PRF: PRF-HMAC-SHA-512 [RFC4868]

         Integrity: NULL

         Diffie-Hellman group: 384-bit random ECP group [RFC5903]

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

      ESP SA:

         Encryption: AES with 256-bit keys and 16-octet ICV in GCM mode
         [RFC4106]

         Integrity: NULL

      IKEv2 SA:

         Encryption: AEAD_AES_256_GCM - AES with 256-bit keys in GCM
         mode [RFC5282]

         PRF: PRF-HMAC-SHA-512 [RFC4868]

         Integrity: NULL

         Diffie-Hellman group: 3072 modulus [RFC3526]

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

      ESP SA:

         Encryption: AES with 256-bit keys and 16-octet ICV in GCM mode
         [RFC4106]

         Integrity: NULL

      IKEv2 SA:

         Encryption: AEAD_AES_256_GCM - AES with 256-bit keys in GCM
         mode [RFC5282]

         PRF: PRF-HMAC-SHA-512 [RFC4868]

         Integrity: NULL

         Diffie-Hellman group: 4096 modulus [RFC3526]

Corcoran & Jenkins        Expires June 6, 2020                  [Page 6]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

6.  IKEv2 Authentication

   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.

7.  Certificates

   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.

8.  IKEv2 Security Associations (SA)

   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:

      CNSA-GCM-256-ECDH-384,

      CNSA-GCM-256-DH-3072,

      CNSA-GCM-256-DH-4096.

Corcoran & Jenkins        Expires June 6, 2020                  [Page 7]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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.

9.  The Key Exchange Payload in the IKE_SA_INIT Exchange

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

   If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected
   for the SA, the initiator and responder both MUST generate an
   elliptic curve (EC) key pair using the P-384 elliptic curve.  The
   ephemeral public keys MUST be stored in the key exchange payload as
   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.

10.  Generating Key Material for the IKE SA

   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.

Corcoran & Jenkins        Expires June 6, 2020                  [Page 8]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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].

11.  Additional Requirements

   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.

Corcoran & Jenkins        Expires June 6, 2020                  [Page 9]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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.

12.  Guidance for Applications With Long Data-Protection Requirements

   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 [ID.ipsecme-qr-ikev2].  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 [ID.ipsecme-qr-ikev2] 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).

13.  Security Considerations

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

Corcoran & Jenkins        Expires June 6, 2020                 [Page 10]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   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.

14.  IANA Considerations

   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.

        Identifier                        Reference
   =====================           ======================
   CNSA-GCM-256-ECDH-384           [This RFC]
   CNSA-GCM-256-DH-3072            [This RFC]
   CNSA-GCM-256-DH-4096            [This RFC]

15.  References

15.1.  Normative References

   [CNSA]     Committee for National Security Systems, "Use of Public
              Standards for Secure Information Sharing", CNSSP 15,
              October 2016,
              <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.

   [FIPS180]  National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", Federal Information Processing
              Standard 180-4, August 2015,
              <https://csrc.nist.gov/publications/detail/fips/180/4/
              final>.

Corcoran & Jenkins        Expires June 6, 2020                 [Page 11]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   [FIPS186]  National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", NIST Federal Information
              Processing Standard 186-4, July 2013,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-4.pdf>.

   [FIPS197]  National Institute of Standards and Technology, "Advanced
              Encryption Standard (AES)", Federal Information Processing
              Standard 197, November 2001,
              <https://csrc.nist.gov/publications/detail/fips/197/
              final>.

   [ID.ipsecme-qr-ikev2]
              Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov,
              "Postquantum Preshared Keys for IKEv2", March 2019,
              <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-
              ikev2/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, DOI 10.17487/RFC3526, May 2003,
              <https://www.rfc-editor.org/info/rfc3526>.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              RFC 4106, DOI 10.17487/RFC4106, June 2005,
              <https://www.rfc-editor.org/info/rfc4106>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC4754]  Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
              the Elliptic Curve Digital Signature Algorithm (ECDSA)",
              RFC 4754, DOI 10.17487/RFC4754, January 2007,
              <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>.

Corcoran & Jenkins        Expires June 6, 2020                 [Page 12]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5282]  Black, D. and D. McGrew, "Using Authenticated Encryption
              Algorithms with the Encrypted Payload of the Internet Key
              Exchange version 2 (IKEv2) Protocol", RFC 5282,
              DOI 10.17487/RFC5282, August 2008,
              <https://www.rfc-editor.org/info/rfc5282>.

   [RFC5903]  Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
              Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
              DOI 10.17487/RFC5903, June 2010,
              <https://www.rfc-editor.org/info/rfc5903>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <https://www.rfc-editor.org/info/rfc8017>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8221]  Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
              Kivinen, "Cryptographic Algorithm Implementation
              Requirements and Usage Guidance for Encapsulating Security
              Payload (ESP) and Authentication Header (AH)", RFC 8221,
              DOI 10.17487/RFC8221, October 2017,
              <https://www.rfc-editor.org/info/rfc8221>.

   [RFC8247]  Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
              "Algorithm Implementation Requirements and Usage Guidance
              for the Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8247, DOI 10.17487/RFC8247, September 2017,
              <https://www.rfc-editor.org/info/rfc8247>.

Corcoran & Jenkins        Expires June 6, 2020                 [Page 13]
Internet-Draft          CNSA Suite IPSec Profile           December 2019

   [RFC8603]  Jenkins, M. and L. Zieglar, "Commercial National Security
              Algorithm (CNSA) Suite Certificate and Certificate
              Revocation List (CRL) Profile", RFC 8603,
              DOI 10.17487/RFC8603, May 2019,
              <https://www.rfc-editor.org/info/rfc8603>.

   [SP80056A]
              National Institute of Standards and Technology,
              "Recommendation for Pair-Wise Key Establishment Schemes
              Using Discrete Logarithm Cryptography", NIST Special
              Publication 800-56A, Revision 3, April 2018,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-56Ar3.pdf>.

15.2.  Informative References

   [RFC4308]  Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
              DOI 10.17487/RFC4308, December 2005,
              <https://www.rfc-editor.org/info/rfc4308>.

   [RFC8452]  Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV:
              Nonce Misuse-Resistant Authenticated Encryption",
              RFC 8452, DOI 10.17487/RFC8452, April 2019,
              <https://www.rfc-editor.org/info/rfc8452>.

   [SP80059]  National Institute of Standards and Technology, "Guideline
              for Identifying an Information System as a National
              Security System", Special Publication 800-59 , August
              2003, <https://csrc.nist.gov/publications/detail/sp/800-
              59/final>.

Authors' Addresses

   Laura Corcoran
   National Security Agency

   Email: lscorco@nsa.gov

   Michael Jenkins
   National Security Agency

   Email: mjjenki@nsa.gov

Corcoran & Jenkins        Expires June 6, 2020                 [Page 14]