wdiff rfc9212xml2.original.xml rfc9212.xml

<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml"> zwsp   "&#8203;">
  <!ENTITY rfc4252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml"> nbhy   "&#8209;">
  <!ENTITY rfc4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc5647 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5647.xml">
<!ENTITY rfc5656 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5656.xml">
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc8268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8268.xml">
<!ENTITY rfc8308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8308.xml">
<!ENTITY rfc8332 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8332.xml">
<!ENTITY rfc8603 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8603.xml"> wj     "&#8288;">
]>

<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- Information about the document. -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902" number="9212" docName="draft-gajcowski-cnsa-ssh-profile-07" >

    <!-- Processing Instructions- PIs (for a complete list and description,
          see file http://xml.resource.org/authoring/README.html and below... -->

    <?rfc strict="yes" ?>
    <?rfc comments="no" ?>
    <?rfc inline="no" ?>
    <?rfc editing="no" ?>

    <!-- Table of Contents (ToC) options. -->
   <?rfc toc="yes"?>
   <?rfc tocompact="yes"?>
   <?rfc tocdepth="2"?>

    <!-- References options. -->
    <?rfc symrefs="yes"?>
    <?rfc sortrefs="yes" ?>

    <!-- Vertical spacing options. -->
    <?rfc compact="yes" ?>
    <?rfc subcompact="no" ?>

    <!-- end of list of popular I-D processing instructions obsoletes="" updates="" submissionType="independent" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.0 -->
<front>
    <title abbrev="CNSA Suite SSH Profile">Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)</title>
    <seriesInfo name="RFC" value="9212"/>
    <author fullname="Nicholas Gajcowski" initials="N." surname="Gajcowski">
      <organization abbrev="NSA">National Security Agency</organization>
        <address><email>nhgajco@uwe.nsa.gov</email></address>
      <address>
        <email>nhgajco@uwe.nsa.gov</email>
      </address>
    </author>
    <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
      <organization abbrev="NSA">National Security Agency</organization>
        <address><email>mjjenki@cyber.nsa.gov</email></address>
      <address>
        <email>mjjenki@cyber.nsa.gov</email>
      </address>
    </author>
    <date month="March" year="2022"/>

<!-- EDITOR NOTE: There is a text-only (no XML) citation below to ID.ietf-curdle-ssh-kex-sha2. It should be replaced with an xref citation when that draft is published. Vielen Dank. -->

<keyword>NSS</keyword>
<keyword>remote administration</keyword>

<abstract>
      <t>The United States Government has published the NSA National Security
      Agency (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 with the
      Secure Shell Transport Layer Protocol and the Secure Shell
      Authentication Protocol. It applies to the capabilities, configuration,
      and operation of all components of US National Security Systems that employ SSH. US National Security Systems are described
      (described in NIST Special Publication 800-59. It 800-59) that employ Secure Shell
      (SSH).  This document 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.
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document specifies conventions for using the United States
      National Security Agency's CNSA Suite algorithms <xref target="CNSA" />
      format="default"/> with the Secure Shell Transport Layer Protocol <xref
      target="RFC4253" /> format="default"/> and the Secure Shell Authentication
      Protocol <xref target="RFC4252" />. format="default"/>. It applies to the
      capabilities, configuration, and operation of all components of US
      National Security Systems that employ SSH. US National Security Systems are described (described in NIST Special Publication 800-59
      <xref target="SP80059" />. It format="default"/>) that employ SSH.  This
      document 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.
</t>
    </section>  <!-- intro -->

<section anchor="terminology" title="Terminology">

<t>The numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/> <xref target="RFC8174" />
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
    </section>  <!-- terminology -->

    <section anchor="cnsa" title="The numbered="true" toc="default">
      <name>The Commercial National Security Algorithm Suite"> Suite</name>
      <t>The National Security Agency (NSA) 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 Government's transition to new algorithms, algorithms and to provide vendors - -- and the
      Internet community in general - -- with information concerning their proper use and configuration.
</t>
      configuration.</t>
      <t>Recently, cryptographic transition plans have become overshadowed by the prospect of the
      development of a cryptographically-relevant cryptographically relevant quantum computer. The NSA has established the
      Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users
      near-term flexibility in meeting their information assurance interoperability requirements
      using current cryptography. The purpose behind this flexibility is to avoid vendors and
      customers making two major transitions (i.e. (i.e., to elliptic curve cryptography, cryptography and then to
      post-quantum cryptography) in a relatively short timeframe, as we anticipate a need to
      shift to quantum-resistant cryptography in the near future.
</t>

<t>NSA future.</t>
      <t>The NSA is authoring a set of RFCs, including this one, to provide updated guidance
      concerning the use of certain commonly available commercial algorithms in IETF protocols.
      These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g.,
      NIST Special Publications) to properly protect Internet traffic and data-at-rest for US
      Government National Security Systems.
</t> Systems.</t>
    </section> <!-- cnsa -->

<section anchor="cnsa-and-ssh" title="CNSA numbered="true" toc="default">
      <name>CNSA and Secure Shell"> Shell</name>
      <t>Several RFCs have documented how each of the CNSA components are to be integrated into Secure Shell (SSH):

<list style="empty">

</t>

        <t>kex algorithms
  <list style="empty">
    <t>ecdh-sha2-nistp384 algorithms:</t>
          <ul>
            <li>ecdh-sha2-nistp384 <xref target="RFC5656" /></t>
    <t>diffie-hellman-group15-sha512 format="default"/></li>
            <li>diffie-hellman-group15-sha512 <xref target="RFC8268" /></t>
    <t>diffie-hellman-group16-sha512 format="default"/></li>
            <li>diffie-hellman-group16-sha512 <xref target="RFC8268" /></t>
    </list></t> format="default"/></li>
          </ul>

        <t>public key algorithms
  <list style="empty">
    <t>ecdsa-sha2-nistp384 algorithms:</t>

          <ul>
            <li>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t>
    <t>rsa-sha2-512 format="default"/></li>
            <li>rsa-sha2-512 <xref target="RFC8332" /></t>
    </list></t> format="default"/></li>
          </ul>

        <t>encryption algorithms (both client_to_server and server_to_client)
  <list style="empty">
    <t>AEAD_AES_256_GCM server_to_client):</t>

          <ul>
            <li>AEAD_AES_256_GCM <xref target="RFC5647" /></t>
    </list></t>
  <t>MAC format="default"/></li>
          </ul>

        <t>message authentication code (MAC) algorithms (both client_to_server and server_to_client)
  <list style="empty">
    <t>AEAD_AES_256_GCM server_to_client):</t>

          <ul>
            <li>AEAD_AES_256_GCM <xref target="RFC5647" /></t>
    </list></t>
</list>
</t> format="default"/></li>
          </ul>

      <t>While the approved CNSA hash function for all purposes is SHA-384, as defined in <xref target="FIPS180" />, format="default"/>, commercial products are more likely to incorporate the SHA-512 (sha2-512) based kex algorithms and public key algorithms based on SHA-512 (sha2-512), which are defined in <xref target="RFC8268" /> format="default"/> and <xref target="RFC8332" />. format="default"/>. Therefore, the SHA-384 based SHA-384-based kex and public key algorithms SHOULD <bcp14>SHOULD</bcp14> be used; SHA-512 based SHA-512-based algorithms MAY <bcp14>MAY</bcp14> be used. Any hash algorithm other than SHA-384 or SHA-512 MUST NOT <bcp14>MUST NOT</bcp14> be used.
</t>

<t>Use of AES GCM the Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) shall meet the requirements set forth in SP 800-38D <xref target="SP800-38D" format="default"/>, with the additional requirements that all 16 octets of the authentication tag MUST <bcp14>MUST</bcp14> be used as the SSH data integrity value and that AES is used with a 256-bit key. Use of AES-GCM in SSH should be done as described in RFC 5647, <xref target="RFC5647" format="default"/>, with the exception that AES-GCM need not be listed as the MAC algorithm when its use is implicit (such as done in aes256-gcm@openssh.com). In addition, RFC 5647 failed <xref target="RFC5647" format="default"/> fails to specify that the AES GCM AES-GCM invocation counter is incremented mod 2^64. 2<sup>64</sup>. CNSA implementations MUST <bcp14>MUST</bcp14> ensure the counter never repeats and is properly incremented after processing a binary packet: invocation_counter packet:</t>
<t indent="3">invocation_counter = invocation_counter + 1  mod 2^64.
</t> 2<sup>64</sup>.</t>

<t>The purpose of this document is to draw upon all of these documents to provide guidance for CNSA compliant CNSA-compliant implementations of Secure Shell. Algorithms specified in this document may be different to from mandatory-to-implement algorithms; in that case where this occurs, the latter will be present but not used. Note that that, while compliant Secure Shell implementations MUST <bcp14>MUST</bcp14> follow the guidance in this document, that requirement does not in and of itself imply that a given implementation of Secure Shell is suitable for use national security systems. An implementation must be validated by the appropriate authority before such usage is permitted.
</t>
    </section>  <!-- cnsa-and-ssh -->

<section anchor="sec-mech-neg-init" title="Security numbered="true" toc="default">
      <name>Security Mechanism Negotiation and Initialization"> Initialization</name>
      <t>As described in Section 7.1 of <xref target="RFC4253" />, section="7.1" sectionFormat="of" format="default"/>, the exchange of SSH_MSG_KEXINIT between the server and the client establishes which key agreement algorithm, MAC algorithm, host key algorithm (server authentication algorithm), and encryption algorithm are to be used. This section specifies the use of CNSA components in the Secure Shell algorithm negotiation, key agreement, server authentication, and user authentication.
</t>
      <t>The choice of all but the user authentication methods are is determined by the exchange of SSH_MSG_KEXINIT between the client and the server.
      </t>

      <t>The kex_algorithms name-list is used to negotiate a single key agreement algorithm between the server and client in accordance with the guidance given in Section 2. <xref target="cnsa-and-ssh" format="default"/>. While ID.ietf-curdle-ssh-kex-sha2 <xref target="RFC9142" format="default"/> establishes general guidance on the capabilities of SSH implementations and requires support for "diffie-hellman-group14-sha256", it MUST NOT <bcp14>MUST NOT</bcp14> be used. The result MUST <bcp14>MUST</bcp14> be one of the following kex_algorithms kex_algorithms, or the connection MUST <bcp14>MUST</bcp14> be terminated.

<list style="empty">
  <t>ecdh-sha2-nistp384 terminated:

</t>
      <ul spacing="normal">
        <li>ecdh-sha2-nistp384 <xref target="RFC5656" /></t>
  <t>diffie-hellman-group15-sha512 format="default"/></li>
        <li>diffie-hellman-group15-sha512 <xref target="RFC8268" /></t>
  <t>diffie-hellman-group16-sha512 format="default"/></li>
        <li>diffie-hellman-group16-sha512 <xref target="RFC8268" /></t>
  </list>
</t> format="default"/></li>
      </ul>

      <t>One of the following sets MUST <bcp14>MUST</bcp14> be used for the encryption_algorithms and mac_algorithms name-lists. Either set MAY <bcp14>MAY</bcp14> be used for each direction (i.e. client_to_server, server_to_client) (i.e., client_to_server or server_to_client), but the result must be the same (i.e. (i.e., use of AEAD_AES_256_GCM). This option MUST be used.

<list style="empty">
  <t>encryption_algorithm_name_list </t>

        <t indent="3">encryption_algorithm_name_list := { AEAD_AES_256_GCM }</t>
  <t>mac_algorithm_name_list
        <t indent="3">mac_algorithm_name_list := { AEAD_AES_256_GCM }</t>
  </list>
or
<list style="empty">
  <t>encryption_algorithm_name_list

      <t> or</t>

        <t indent="3">encryption_algorithm_name_list := { aes256-gcm@openssh.com }</t>
  <t>mac_algorithm_name_list
        <t indent="3">mac_algorithm_name_list := {}</t>
  </list>
</t>

      <t>One of the following public key algorithms MUST <bcp14>MUST</bcp14> be used.

<list style="empty">
  <t>rsa-sha2-512 used:</t>

      <ul spacing="normal">
        <li>rsa-sha2-512 <xref target="RFC8332" /></t>
  <t>ecdsa-sha2-nistp384 format="default"/></li>
        <li>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t>
  </list>
</t> format="default"/></li>
      </ul>

      <t>The procedures for applying the negotiated algorithms are given in the following sections.
</t>
    </section>  <!-- sec-mech-neg-init -->

<section anchor="kex" title="Key Exchange"> numbered="true" toc="default">
      <name>Key Exchange</name>
      <t>The key exchange to be used is determined by the name-lists exchanged in the SSH_MSG_KEXINIT packets packets, as described above. Either elliptic curve Elliptic Curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) MUST <bcp14>MUST</bcp14> be used to establish a shared secret value between the client and the server.
</t>
<t>A compliant system MUST NOT <bcp14>MUST NOT</bcp14> allow the reuse of ephemeral/exchange values in a key exchange algorithm due to security concerns related to this practice.
Section 5.6.3.3 of <xref target="SP80056A" /> format="default"/> states that an ephemeral private key must shall be used in exactly one key establishment transaction and must shall be destroyed (zeroized) as soon as possible. Section 5.8 of <xref target="SP80056A" /> format="default"/> states that such shared secrets must shall be destroyed (zeroized) immediately after its use. CNSA compliant CNSA-compliant systems MUST <bcp14>MUST</bcp14> follow these mandates.
</t>
      <section anchor="ecdh-kex" title="ECDH numbered="true" toc="default">
        <name>ECDH Key Exchange"> Exchange</name>
        <t>The key exchange begins with the SSH_MSG_KEXECDH_INIT message which that contains the client's ephemeral public key used to generate a shared secret value.
</t>
        <t>The server responds to a an SSH_MSG_KEXECDH_INIT message with a an SSH_MSG_KEXECDH_REPLY message which that contains the server's ephemeral public key, the server's public host key, and a signature of the exchange hash value formed from the newly established shared secret value. The kex algorithm MUST <bcp14>MUST</bcp14> be ecdh-sha2-nistp384, and the public key algorithm MUST <bcp14>MUST</bcp14> be either ecdsa-sha2-nistp384 or rsa-sha2-512.
</t>
      </section>  <!-- ecdh-kex -->

<section anchor="dh-kex" title="DH numbered="true" toc="default">
        <name>DH Key Exchange"> Exchange</name>
        <t>The key exchange begins with the SSH_MSG_KEXDH_INIT message which that contains the client's DH exchange value used to generate a shared secret value.
</t>
        <t>The server responds to a an SSH_MSG_KEXDH_INIT message with a SSH_MSG_KEXDH_REPLY message. The an SSH_MSG_KEXDH_REPLY message that contains the server's DH exchange value, the server's public host key, and a signature of the exchange hash value formed from the newly established shared secret value. The kex algorithm MUST <bcp14>MUST</bcp14> be one of diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and the public key algorithm MUST <bcp14>MUST</bcp14> be either ecdsa-sha2-nistp384 or rsa-sha2-512.
</t>
      </section>  <!-- dh-kex -->

</section>  <!-- kex -->

<section anchor="authn" title="Authentication"> numbered="true" toc="default">
      <name>Authentication</name>
      <section anchor="serv-authn" title="Server Authentication"> numbered="true" toc="default">
        <name>Server Authentication</name>
        <t>A signature on the exchange hash value derived from the newly established shared secret value is used to authenticate the server to the client. Servers MUST <bcp14>MUST</bcp14> be authenticated using digital signatures. The public key algorithm implemented MUST <bcp14>MUST</bcp14> be ecdsa-sha2-nistp384 or rsa-sha2-512. The RSA public key modulus MUST <bcp14>MUST</bcp14> be 3072 or 4096 bits in size; clients MUST NOT <bcp14>MUST NOT</bcp14> accept RSA signatures from a public key modulus of any other size.
</t>
        <t>The following public key algorithms MUST <bcp14>MUST</bcp14> be used:

<list style="empty">
  <t>ecdsa-sha2-nistp384 used:</t>
        <ul spacing="normal">
          <li>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t>
  <t>rsa-sha2-512 format="default"/></li>
          <li>rsa-sha2-512 <xref target="RFC8332" /></t>
  </list>
</t> format="default"/></li>
        </ul>
        <t>The client MUST <bcp14>MUST</bcp14> verify that the presented key is a valid authenticator for the server before verifying the server signature. If possible, validation SHOULD <bcp14>SHOULD</bcp14> be done using certificates. Otherwise, the client MUST <bcp14>MUST</bcp14> validate the presented public key through some other secure, possibly off-line mechanism. Implementations MUST NOT <bcp14>MUST NOT</bcp14> employ a trust "Trust on first use (TOFU) First Use (TOFU)" security model where a client accepts the first public host key presented to it from a not yet verified not-yet-verified server. Use of a TOFU model would allow an intermediate adversary to present itself to the client as the server.
</t>
        <t>Where X.509v3 certificates X.509 v3 Certificates are used, their use MUST <bcp14>MUST</bcp14> comply with <xref target="RFC8603"/>
</t> target="RFC8603" format="default"/>.</t>
      </section>  <!-- serv-authn -->

<section anchor="user-authn" title="User Authentication"> numbered="true" toc="default">
        <name>User Authentication</name>
        <t>The Secure Shell Transport Layer Protocol authenticates the server to the host but does not authenticate the user (or the user's host) to the server. All users MUST <bcp14>MUST</bcp14> be authenticated, MUST <bcp14>MUST</bcp14> follow <xref target="RFC4252" />, format="default"/>, and SHOULD <bcp14>SHOULD</bcp14> be authenticated using a public key method. Users MAY <bcp14>MAY</bcp14> authenticate using passwords. Other methods of authentication MUST <bcp14>MUST</bcp14> not be used, including "none".
</t>
        <t>When authenticating with public key, the following public key algorithms MUST <bcp14>MUST</bcp14> be used:

<list style="empty">
  <t>ecdsa-sha2-nistp384 used:</t>
        <ul spacing="normal">
          <li>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t>
  <t>rsa-sha2-512 format="default"/></li>
          <li>rsa-sha2-512 <xref target="RFC8332" /></t>
  </list>
</t> format="default"/></li>
        </ul>
        <t>The server MUST <bcp14>MUST</bcp14> verify that the public key is a valid authenticator for the user. If possible, validation SHOULD <bcp14>SHOULD</bcp14> be done using certificates. Otherwise, the server must validate the public key through another secure, possibly off-line mechanism.
</t>
        <t>Where X.509v3 certificates X.509 v3 Certificates are used, their use MUST <bcp14>MUST</bcp14> comply with <xref target="RFC8603" />. format="default"/>.
</t>
        <t>If authenticating with RSA, the client's public key modulus MUST <bcp14>MUST</bcp14> be 3072 or 4096 bits in size, and the server MUST NOT <bcp14>MUST NOT</bcp14> accept signatures from an RSA public key modulus of any other size.
</t>
        <t>To facilitate client authentication with RSA using SHA-512, clients and servers SHOULD <bcp14>SHOULD</bcp14> implement the server-sig-algs extension extension, as specified in <xref target="RFC8308" />. format="default"/>. In that case, in the SSH_MSG_KEXINIT, the client SHALL <bcp14>SHALL</bcp14> include the indicator ext-info-c to the kex_algorithms field, and the server SHOULD <bcp14>SHOULD</bcp14> respond with a an SSH_MSG_EXT_INFO message containing the server-sig-algs extension. The server MUST <bcp14>MUST</bcp14> list only ecdsa-sha2-nistp384 and-or and/or rsa-sha2-512 as the acceptable public key algorithms in this response.
</t>
        <t>If authenticating by passwords, it is essential that passwords have sufficient entropy to protect against dictionary attacks. During authentication, the password MUST <bcp14>MUST</bcp14> be protected in the established encrypted communications channel. Additional guidelines are provided in <xref target="SP80063" />. format="default"/>.
</t>
      </section>  <!-- user-authn -->

</section>  <!-- authn -->

<section anchor="pkt-conf-and-integ" title="Confidentiality numbered="true" toc="default">
      <name>Confidentiality and Data Integrity of SSH Binary Packets"> Packets</name>
      <t>Secure Shell transfers data between the client and the server using its own binary packet structure. The SSH binary packet structure is independent of any packet structure on the underlying data channel. The contents of each binary packet and portions of the header are encrypted, and each packet is authenticated with its own message authentication code. Use of the Advanced Encryption Standard in Galois Counter Mode (AES GCM) AES-GCM will both encrypt the packet and form a 16-octet authentication tag to ensure data integrity.
</t>
      <section anchor="gcm" title="Galois/Counter Mode"> numbered="true" toc="default">
        <name>Galois/Counter Mode</name>
        <t>Use of AES GCM AES-GCM in Secure Shell is described in <xref target="RFC5647" />. CNSA complaint format="default"/>. CNSA-complaint SSH implementations MUST <bcp14>MUST</bcp14> support AES GCM AES-GCM (negotiated as AEAD_AES_GCM_256 or aes256-gcm@openssh, aes256-gcm@openssh; see <xref target="sec-mech-neg-init" />) format="default"/>) to provide confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted.
</t>
        <t>The AES GCM AES-GCM invocation counter is incremented mod 2^64. 2<sup>64</sup>. That is, after processing a binary packet:

<list style="empty">
  <t>invocation_counter packet:</t>
          <t indent="3">invocation_counter = invocation_counter + 1 mod 2^64</t>
  </list>
</t> 2<sup>64</sup></t>
        <t>The invocation counter MUST NOT <bcp14>MUST NOT</bcp14> repeat a counter value.</t>
      </section>  <!-- gcm -->

      <section anchor="data-integ" title="Data Integrity"> numbered="true" toc="default">
        <name>Data Integrity</name>
        <t>As specified in <xref target="RFC5647" />, format="default"/>, all 16 octets of the
	authentication tag MUST <bcp14>MUST</bcp14> be used as the SSH data integrity value of the SSH
	binary packet.
</t> packet.</t>
      </section>  <!-- data-integ -->

</section>  <!-- pkt-conf-and-integ -->

<section anchor="rekeying" title="Rekeying">

<t>Section 9 of <xref numbered="true" toc="default">
      <name>Rekeying</name>

      <t><xref target="RFC4253" /> section="9" sectionFormat="of" format="default"/> allows either the server or the client to initiate a ‘key "key re-exchange ... by sending an SSH_MSG_KEXINIT packet’ packet" and to ‘change "change some or all of the (cipher) [cipher] algorithms during re-exchange.’ the re-exchange".  This specification requires the same cipher suite to be employed when re-keying, rekeying; that is, the cipher algorithms MUST NOT <bcp14>MUST NOT</bcp14> be changed when a rekey occurs.
</t>
    </section>  <!-- rekeying -->

    <section anchor="sec-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of <xref target="RFC4251" />, format="default"/>, <xref
      target="RFC4252" />, format="default"/>, <xref target="RFC4253" />, format="default"/>, <xref
      target="RFC5647" />, format="default"/>, and <xref target="RFC5656" /> apply.
</t> format="default"/>
      apply.</t>
    </section>  <!-- sec-considerations -->

<section anchor="iana" title="IANA Considerations">

<t>No numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions are requested.
</t> actions.</t>
    </section> <!--  iana -->

</middle>
  <back>     <!--  *****BACK MATTER ***** -->

<references title="Normative References">

<references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Policies.htm">
          <front>
            <title>Use of Public Standards for Secure Information Sharing</title>
      <author><organization>Committee
            <author>
              <organization>Committee for National Security Systems</organization></author> Systems</organization>
            </author>
            <date month="October" year="2016"></date> year="2016"/>
          </front>
          <seriesInfo name="CNSSP" value="15"></seriesInfo> value="15"/>
        </reference> <!-- CNSA -->

  <reference anchor="FIPS180" target="https://doi.org/10.6028/NIST.FIPS.180-4">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2015" /> year="2015"/>
          </front>
          <seriesInfo name="Federal Information Processing Standard" value="180-4" name="FIPS PUB" value="180-4"/>
          <seriesInfo name='DOI' value='10.6028/NIST.FIPS.180-4' />
        </reference> <!-- FIPS180 -->

&rfc2119;
&rfc4251;
&rfc4252;
&rfc4253;
&rfc5647;
&rfc5656;
&rfc8174;
&rfc8268;
&rfc8308;
&rfc8332;
&rfc8603;

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5647.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5656.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8268.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8308.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8332.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/>
      </references>  <!-- Normative -->

<references title="Informative References">
      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9142.xml"/>

  <reference anchor="SP800-38D" target="https://doi.org/10.6028/NIST.SP.800-38D">
          <front>
		    <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
			<author>
			  <organization>National Institute of Standards and Technology</organization>
			</author>
			<date month="November" year="2007"/>
	        </front>
		  <seriesInfo name="NIST Special Publication" value="800-38D"/>
		  <seriesInfo name='DOI' value='10.6028/NIST.SP.800-38D'/>
		  </reference>

	<reference anchor="SP80056A" target="https://doi.org/10.6028/NIST.SP.800-56Ar3">
          <front>
            <title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="April" year="2018" /> year="2018"/>
          </front>
	  <refcontent>Revision 3</refcontent>
          <seriesInfo name="NIST Special Publication" value="800-56A, Revision 3" value="800-56A"/>
	  <seriesInfo name='DOI' value='10.6028/NIST.SP.800-56Ar3' />
        </reference>  <!-- SP80056A -->

  <reference anchor="SP80059" target="https://doi.org/10.6028/NIST.SP.800-59">
          <front>
            <title>Guideline for Identifying an Information System as a National Security
	    System</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2003" /> year="2003"/>
          </front>
          <seriesInfo name="Special Publication 800-59" value="" name="NIST Special Publication" value="800-59"/>
	  <seriesInfo name='DOI' value='10.6028/NIST.SP.800-59' />
        </reference> <!-- SP80059 -->

  <reference anchor="SP80063" target="https://doi.org/10.6028/NIST.SP.800-63-3">
          <front>
            <title>Digital Identity Guidelines</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="June" year="2017" /> year="2017"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-63, Revision 3" value="800-63-3"/>
	  <seriesInfo name='DOI' value='10.6028/NIST.SP.800-63-3' />
        </reference>  <!-- SP80063 -->

</references>  <!-- Informative -->
    </references>

</back>       <!--  ===== END BACK MATTER ===== -->
</rfc>