rfc9212xml2.original.xml   rfc9212.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.2119.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.4251.xml">
<!ENTITY rfc4252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4252.xml">
<!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">
]> ]>
<!-- Extra statement used by XSLT processors to control the output style. --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> " number="9212" docName="draft-gajcowski-cnsa-ssh-profile-07" obsoletes="" updat
es="" submissionType="independent" xml:lang="en" tocInclude="true" tocDepth="2"
<!-- Information about the document. --> symRefs="true" sortRefs="true" version="3">
<rfc category="info" ipr="trust200902" docName="draft-gajcowski-cnsa-ssh-profile <!-- xml2rfc v2v3 conversion 3.12.0 -->
-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 -->
<front> <front>
<title abbrev="CNSA Suite SSH Profile">Commercial National Security Algorith m (CNSA) Suite Cryptography for Secure Shell (SSH)</title> <title abbrev="CNSA Suite SSH Profile">Commercial National Security Algorith m (CNSA) Suite Cryptography for Secure Shell (SSH)</title>
<seriesInfo name="RFC" value="9212"/>
<author fullname="Nicholas Gajcowski" initials="N." surname="Gajcowski"> <author fullname="Nicholas Gajcowski" initials="N." surname="Gajcowski">
<organization abbrev="NSA">National Security Agency</organization> <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>
<author fullname="Michael Jenkins" initials="M." surname="Jenkins"> <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
<organization abbrev="NSA">National Security Agency</organization> <organization abbrev="NSA">National Security Agency</organization>
<address><email>mjjenki@cyber.nsa.gov</email></address> <address>
<email>mjjenki@cyber.nsa.gov</email>
</address>
</author> </author>
<date month="March" year="2022"/>
<date year="2022"/> <keyword>NSS</keyword>
<keyword>remote administration</keyword>
<!-- 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 pu
blished. Vielen Dank. -->
<abstract> <abstract>
<t>The United States Government has published the National Security
<t>The United States Government has published the NSA Commercial National Securi Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which
ty Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for nati defines cryptographic algorithm policy for national security
onal security applications. This document specifies the conventions for using th applications. This document specifies the conventions for using the
e United States National Security Agency's CNSA Suite algorithms with the Secure United States National Security Agency's CNSA Suite algorithms with the
Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. It Secure Shell Transport Layer Protocol and the Secure Shell
applies to the capabilities, configuration, and operation of all components of Authentication Protocol. It applies to the capabilities, configuration,
US National Security Systems that employ SSH. US National Security Systems are d and operation of all components of US National Security Systems
escribed in NIST Special Publication 800-59. It is also appropriate for all othe (described in NIST Special Publication 800-59) that employ Secure Shell
r US Government systems that process high-value information. It is made publicly (SSH). This document is also appropriate for all other US Government
available for use by developers and operators of these and any other system dep systems that process high-value information. It is made publicly
loyments. available for use by developers and operators of these and any other
</t> system deployments.
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document specifies conventions for using the United States National Secu
rity Agency's CNSA Suite algorithms <xref target="CNSA" /> with Secure Shell Tra
nsport Layer Protocol <xref target="RFC4253" /> and the Secure Shell Authenticat
ion Protocol <xref target="RFC4252" />. It applies to the capabilities, configur
ation, and operation of all components of US National Security Systems that empl
oy SSH. US National Security Systems are described in NIST Special Publication 8
00-59 <xref target="SP80059" />. It is also appropriate for all other US Governm
ent systems that process high-value information. It is made publicly available f
or use by developers and operators of these and any other system deployments.
</t>
</section> <!-- intro -->
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119" /> <
xref target="RFC8174" /> when, and only when, they appear in all capitals, as sh
own here.
</t>
</section> <!-- terminology -->
<section anchor="cnsa" title="The Commercial National Security Algorithm Suite">
<t>The National Security Agency (NSA) profiles commercial cryptographic algorith
ms and protocols as part of its mission to support secure, interoperable communi
cations for US Government National Security Systems. To this end, it publishes g
uidance both to assist with the US Government transition to new algorithms, and
to provide vendors - and the Internet community in general - with information co
ncerning their proper use and configuration.
</t>
<t>Recently, cryptographic transition plans have become overshadowed by the pros
pect of the development of a cryptographically-relevant quantum computer. NSA ha
s established the Commercial National Security Algorithm (CNSA) Suite to provide
vendors and IT users near-term flexibility in meeting their information assuran
ce interoperability requirements using current cryptography. The purpose behind
this flexibility is to avoid vendors and customers making two major transitions
(i.e. to elliptic curve cryptography, and then to post-quantum cryptography) in
a relatively short timeframe, as we anticipate a need to shift to quantum-resist
ant cryptography in the near future.
</t> </t>
</abstract>
<t>NSA is authoring a set of RFCs, including this one, to provide updated guidan </front>
ce concerning the use of certain commonly available commercial algorithms in IET <middle>
F protocols. These RFCs can be used in conjunction with other RFCs and cryptogra <section anchor="intro" numbered="true" toc="default">
phic guidance (e.g., NIST Special Publications) to properly protect Internet tra <name>Introduction</name>
ffic and data-at-rest for US Government National Security Systems. <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 (described in NIST Special Publication 800-59
<xref target="SP80059" 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> </t>
</section>
</section> <!-- cnsa --> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="cnsa-and-ssh" title="CNSA and Secure Shell">
<t>Several RFCs have documented how each of the CNSA components are to be integr
ated into Secure Shell (SSH):
<list style="empty"> <t>
<t>kex algorithms The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<list style="empty"> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
<t>ecdh-sha2-nistp384 <xref target="RFC5656" /></t> ",
<t>diffie-hellman-group15-sha512 <xref target="RFC8268" /></t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<t>diffie-hellman-group16-sha512 <xref target="RFC8268" /></t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</list></t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>public key algorithms be
<list style="empty"> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<t>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t> target="RFC8174"/> when, and only when, they appear in all capitals, as
<t>rsa-sha2-512 <xref target="RFC8332" /></t> shown here.
</list></t> </t>
<t>encryption algorithms (both client_to_server and server_to_client) </section>
<list style="empty">
<t>AEAD_AES_256_GCM <xref target="RFC5647" /></t>
</list></t>
<t>MAC algorithms (both client_to_server and server_to_client)
<list style="empty">
<t>AEAD_AES_256_GCM <xref target="RFC5647" /></t>
</list></t>
</list>
</t>
<t>While the approved CNSA hash function for all purposes is SHA-384, as defined <section anchor="cnsa" numbered="true" toc="default">
in <xref target="FIPS180" />, commercial products are more likely to incorporat <name>The Commercial National Security Algorithm Suite</name>
e the SHA-512 (sha2-512) based kex algorithms and public key algorithms defined <t>The NSA profiles commercial cryptographic algorithms and
in <xref target="RFC8268" /> and <xref target="RFC8332" />. Therefore, the SHA-3 protocols as part of its mission to support secure, interoperable communic
84 based kex and public key algorithms SHOULD be used; SHA-512 based algorithms ations for US
MAY be used. Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used. Government National Security Systems. To this end, it publishes guidance b
</t> oth to assist
with the US Government's transition to new algorithms and to provide vendo
rs -- and the
Internet community in general -- with information concerning their proper
use and
configuration.</t>
<t>Recently, cryptographic transition plans have become overshadowed by th
e prospect of the
development of a 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 interoperabil
ity requirements
using current cryptography. The purpose behind this flexibility is to avoi
d vendors and
customers making two major transitions (i.e., to elliptic curve cryptograp
hy and then to
post-quantum cryptography) in a relatively short timeframe, as we anticipa
te a need to
shift to quantum-resistant cryptography in the near future.</t>
<t>The NSA is authoring a set of RFCs, including this one, to provide upda
ted 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 gu
idance (e.g.,
NIST Special Publications) to properly protect Internet traffic and data-a
t-rest for US
Government National Security Systems.</t>
</section>
<t>Use of AES GCM shall meet the requirements set forth in SP 800-38D with the a <section anchor="cnsa-and-ssh" numbered="true" toc="default">
dditional requirements that all 16 octets of the authentication tag MUST be used <name>CNSA and Secure Shell</name>
as the SSH data integrity value and that AES is used with a 256-bit key. Use of <t>Several RFCs have documented how each of the CNSA components are to be
AES-GCM in SSH should be done as described in RFC 5647, with the exception that integrated into Secure Shell (SSH):
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 to specify that
the AES GCM invocation counter is incremented mod 2^64. CNSA implementations MU
ST ensure the counter never repeats and is properly incremented after processing
a binary packet: invocation_counter = invocation_counter + 1 mod 2^64.
</t>
<t>The purpose of this document is to draw upon all of these documents to provid e guidance for CNSA compliant implementations of Secure Shell. Algorithms specif ied in this document may be different to mandatory-to-implement algorithms; in t hat case the latter will be present but not used. Note that while compliant Secu re Shell implementations MUST follow the guidance in this document, that require ment 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 valida ted by the appropriate authority before such usage is permitted.
</t> </t>
</section> <!-- cnsa-and-ssh --> <t>kex algorithms:</t>
<ul>
<li>ecdh-sha2-nistp384 <xref target="RFC5656" format="default"/></li
>
<li>diffie-hellman-group15-sha512 <xref target="RFC8268" format="def
ault"/></li>
<li>diffie-hellman-group16-sha512 <xref target="RFC8268" format="def
ault"/></li>
</ul>
<section anchor="sec-mech-neg-init" title="Security Mechanism Negotiation and In itialization"> <t>public key algorithms:</t>
<t>As described in Section 7.1 of <xref target="RFC4253" />, the exchange of SSH <ul>
_MSG_KEXINIT between the server and the client establishes which key agreement a <li>ecdsa-sha2-nistp384 <xref target="RFC5656" format="default"/></l
lgorithm, MAC algorithm, host key algorithm (server authentication algorithm), a i>
nd encryption algorithm are to be used. This section specifies the use of CNSA c <li>rsa-sha2-512 <xref target="RFC8332" format="default"/></li>
omponents in the Secure Shell algorithm negotiation, key agreement, server authe </ul>
ntication, and user authentication.
</t>
<t>The choice of all but the user authentication methods are determined by the e <t>encryption algorithms (both client_to_server and server_to_client):</
xchange of SSH_MSG_KEXINIT between the client and the server. t>
</t>
<t>The kex_algorithms name-list is used to negotiate a single key agreement algo <ul>
rithm between the server and client in accordance with the guidance given in Sec <li>AEAD_AES_256_GCM <xref target="RFC5647" format="default"/></li>
tion 2. While ID.ietf-curdle-ssh-kex-sha2 establishes general guidance on the ca </ul>
pabilities of SSH implementations and requires support for "diffie-hellman-group
14-sha256", it MUST NOT be used. The result MUST be one of the following kex_alg
orithms or the connection MUST be terminated.
<list style="empty"> <t>message authentication code (MAC) algorithms (both client_to_server a
<t>ecdh-sha2-nistp384 <xref target="RFC5656" /></t> nd server_to_client):</t>
<t>diffie-hellman-group15-sha512 <xref target="RFC8268" /></t>
<t>diffie-hellman-group16-sha512 <xref target="RFC8268" /></t>
</list>
</t>
<t>One of the following sets MUST be used for the encryption_algorithms and mac_ <ul>
algorithms name-lists. Either set MAY be used for each direction (i.e. client_to <li>AEAD_AES_256_GCM <xref target="RFC5647" format="default"/></li>
_server, server_to_client) but the result must be the same (i.e. use of AEAD_AES </ul>
_256_GCM). This option MUST be used.
<list style="empty"> <t>While the approved CNSA hash function for all purposes is SHA-384, as d
<t>encryption_algorithm_name_list := { AEAD_AES_256_GCM }</t> efined in <xref target="FIPS180" format="default"/>, commercial products are mor
<t>mac_algorithm_name_list := { AEAD_AES_256_GCM }</t> e likely to incorporate the kex algorithms and public key algorithms based on SH
</list> A-512 (sha2-512), which are defined in <xref target="RFC8268" format="default"/>
or and <xref target="RFC8332" format="default"/>. Therefore, the SHA-384-based kex
<list style="empty"> and public key algorithms <bcp14>SHOULD</bcp14> be used; SHA-512-based algorith
<t>encryption_algorithm_name_list := { aes256-gcm@openssh.com }</t> ms <bcp14>MAY</bcp14> be used. Any hash algorithm other than SHA-384 or SHA-512
<t>mac_algorithm_name_list := {}</t> <bcp14>MUST NOT</bcp14> be used.
</list>
</t> </t>
<t>One of the following public key algorithms MUST be used. <t>Use of the Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) shal
l meet the requirements set forth in <xref target="SP800-38D" format="default"/>
, with the additional requirements that all 16 octets of the authentication tag
<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 <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-gc
m@openssh.com). In addition, <xref target="RFC5647" format="default"/> fails to
specify that the AES-GCM invocation counter is incremented mod 2<sup>64</sup>. C
NSA implementations <bcp14>MUST</bcp14> ensure the counter never repeats and is
properly incremented after processing a binary packet:</t>
<t indent="3">invocation_counter = invocation_counter + 1 mod 2<sup>64</sup>.</
t>
<list style="empty"> <t>The purpose of this document is to draw upon all of these documents to provid
<t>rsa-sha2-512 <xref target="RFC8332" /></t> e guidance for CNSA-compliant implementations of Secure Shell. Algorithms specif
<t>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t> ied in this document may be different from mandatory-to-implement algorithms; wh
</list> ere this occurs, the latter will be present but not used. Note that, while compl
iant Secure Shell implementations <bcp14>MUST</bcp14> follow the guidance in thi
s document, that requirement does not in and of itself imply that a given implem
entation of Secure Shell is suitable for use national security systems. An imple
mentation must be validated by the appropriate authority before such usage is pe
rmitted.
</t> </t>
</section>
<t>The procedures for applying the negotiated algorithms are given in the follow <section anchor="sec-mech-neg-init" numbered="true" toc="default">
ing sections. <name>Security Mechanism Negotiation and Initialization</name>
<t>As described in <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 algori
thm (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>
<t>The choice of all but the user authentication methods is determined by
the exchange of SSH_MSG_KEXINIT between the client and the server.
</t>
</section> <!-- sec-mech-neg-init --> <t>The kex_algorithms name-list is used to negotiate a single key agreemen
t algorithm between the server and client in accordance with the guidance given
<section anchor="kex" title="Key Exchange"> in <xref target="cnsa-and-ssh" format="default"/>. While <xref target="RFC9142"
format="default"/> establishes general guidance on the capabilities of SSH imple
mentations and requires support for "diffie-hellman-group14-sha256", it <bcp14>M
UST NOT</bcp14> be used. The result <bcp14>MUST</bcp14> be one of the following
kex_algorithms, or the connection <bcp14>MUST</bcp14> be terminated:
<t>The key exchange to be used is determined by the name-lists exchanged in the SSH_MSG_KEXINIT packets as described above. Either elliptic curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) MUST be used to establish a shared secret value b etween the client and the server.
</t> </t>
<ul spacing="normal">
<li>ecdh-sha2-nistp384 <xref target="RFC5656" format="default"/></li>
<li>diffie-hellman-group15-sha512 <xref target="RFC8268" format="default
"/></li>
<li>diffie-hellman-group16-sha512 <xref target="RFC8268" format="default
"/></li>
</ul>
<t>A compliant system MUST NOT allow the reuse of ephemeral/exchange values in a <t>One of the following sets <bcp14>MUST</bcp14> be used for the encryptio
key exchange algorithm due to security concerns related to this practice. Secti n_algorithms and mac_algorithms name-lists. Either set <bcp14>MAY</bcp14> be use
on 5.6.3.3 of <xref target="SP80056A" /> states that an ephemeral private key mu d for each direction (i.e., client_to_server or server_to_client), but the resul
st be used in exactly one key establishment transaction and must be destroyed (z t must be the same (i.e., use of AEAD_AES_256_GCM). </t>
eroized) as soon as possible. Section 5.8 of <xref target="SP80056A" /> states t
hat such shared secrets must be destroyed (zeroized) immediately after its use.
CNSA compliant systems MUST follow these mandates.
</t>
<section anchor="ecdh-kex" title="ECDH Key Exchange"> <t indent="3">encryption_algorithm_name_list := { AEAD_AES_256_GCM }</t>
<t indent="3">mac_algorithm_name_list := { AEAD_AES_256_GCM }</t>
<t>The key exchange begins with the SSH_MSG_KEXECDH_INIT message which contains <t> or</t>
the client's ephemeral public key used to generate a shared secret value.
</t>
<t>The server responds to a SSH_MSG_KEXECDH_INIT message with a SSH_MSG_KEXECDH_ <t indent="3">encryption_algorithm_name_list := { aes256-gcm@openssh.com
REPLY message which contains the server's ephemeral public key, the server's pub }</t>
lic host key, and a signature of the exchange hash value formed from the newly e <t indent="3">mac_algorithm_name_list := {}</t>
stablished shared secret value. The kex algorithm MUST be ecdh-sha2-nistp384, an
d the public key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512.
</t>
</section> <!-- ecdh-kex --> <t>One of the following public key algorithms <bcp14>MUST</bcp14> be used: </t>
<section anchor="dh-kex" title="DH Key Exchange"> <ul spacing="normal">
<li>rsa-sha2-512 <xref target="RFC8332" format="default"/></li>
<li>ecdsa-sha2-nistp384 <xref target="RFC5656" format="default"/></li>
</ul>
<t>The key exchange begins with the SSH_MSG_KEXDH_INIT message which contains th e client's DH exchange value used to generate a shared secret value. <t>The procedures for applying the negotiated algorithms are given in the following sections.
</t> </t>
</section>
<t>The server responds to a SSH_MSG_KEXDH_INIT message with a SSH_MSG_KEXDH_REPL <section anchor="kex" numbered="true" toc="default">
Y message. The SSH_MSG_KEXDH_REPLY contains the server's DH exchange value, the <name>Key Exchange</name>
server's public host key, and a signature of the exchange hash value formed from <t>The key exchange to be used is determined by the name-lists exchanged i
the newly established shared secret value. The kex algorithm MUST be one of dif n the SSH_MSG_KEXINIT packets, as described above. Either Elliptic Curve Diffie-
fie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and the public key Hellman (ECDH) or Diffie-Hellman (DH) <bcp14>MUST</bcp14> be used to establish a
algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512. shared secret value between the client and the server.
</t> </t>
<t>A compliant system <bcp14>MUST NOT</bcp14> allow the reuse of ephemeral/excha
</section> <!-- dh-kex --> nge values in a key exchange algorithm due to security concerns related to this
</section> <!-- kex --> practice.
Section 5.6.3.3 of <xref target="SP80056A" format="default"/> states that an eph
<section anchor="authn" title="Authentication"> emeral private key shall be used in exactly one key establishment transaction an
d shall be destroyed (zeroized) as soon as possible. Section 5.8 of <xref target
<section anchor="serv-authn" title="Server Authentication"> ="SP80056A" format="default"/> states that such shared secrets shall be destroye
d (zeroized) immediately after its use. CNSA-compliant systems <bcp14>MUST</bcp1
<t>A signature on the exchange hash value derived from the newly established sha 4> follow these mandates.
red secret value is used to authenticate the server to the client. Servers MUST
be authenticated using digital signatures. The public key algorithm implemented
MUST be ecdsa-sha2-nistp384 or rsa-sha2-512. The RSA public key modulus MUST be
3072 or 4096 bits in size; clients MUST NOT accept RSA signatures from a public
key modulus of any other size.
</t> </t>
<section anchor="ecdh-kex" numbered="true" toc="default">
<t>The following public key algorithms MUST be used: <name>ECDH Key Exchange</name>
<t>The key exchange begins with the SSH_MSG_KEXECDH_INIT message that co
<list style="empty"> ntains the client's ephemeral public key used to generate a shared secret value.
<t>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t>
<t>rsa-sha2-512 <xref target="RFC8332" /></t>
</list>
</t> </t>
<t>The server responds to an SSH_MSG_KEXECDH_INIT message with an SSH_MS
<t>The client MUST verify that the presented key is a valid authenticator for th G_KEXECDH_REPLY message that contains the server's ephemeral public key, the ser
e server before verifying the server signature. If possible, validation SHOULD b ver's public host key, and a signature of the exchange hash value formed from th
e done using certificates. Otherwise, the client MUST validate the presented pub e newly established shared secret value. The kex algorithm <bcp14>MUST</bcp14> b
lic key through some other secure, possibly off-line mechanism. Implementations e ecdh-sha2-nistp384, and the public key algorithm <bcp14>MUST</bcp14> be either
MUST NOT employ a trust on first use (TOFU) security model where a client accept ecdsa-sha2-nistp384 or rsa-sha2-512.
s the first public host key presented to it from a not yet verified server. Use
of a TOFU model would allow an intermediate adversary to present itself to the c
lient as the server.
</t> </t>
</section>
<t>Where X.509v3 certificates are used, their use MUST comply with <xref target= <section anchor="dh-kex" numbered="true" toc="default">
"RFC8603"/> <name>DH Key Exchange</name>
<t>The key exchange begins with the SSH_MSG_KEXDH_INIT message that cont
ains the client's DH exchange value used to generate a shared secret value.
</t> </t>
<t>The server responds to an SSH_MSG_KEXDH_INIT message with an SSH_MSG_
</section> <!-- serv-authn --> KEXDH_REPLY message that contains the server's DH exchange value, the server's p
ublic host key, and a signature of the exchange hash value formed from the newly
<section anchor="user-authn" title="User Authentication"> established shared secret value. The kex algorithm <bcp14>MUST</bcp14> be one o
f diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and the public
<t>The Secure Shell Transport Layer Protocol authenticates the server to the hos key algorithm <bcp14>MUST</bcp14> be either ecdsa-sha2-nistp384 or rsa-sha2-512
t but does not authenticate the user (or the user's host) to the server. All use .
rs MUST be authenticated, MUST follow <xref target="RFC4252" />, and SHOULD be a
uthenticated using a public key method. Users MAY authenticate using passwords.
Other methods of authentication MUST not be used, including "none".
</t> </t>
</section>
<t>When authenticating with public key, the following public key algorithms MUST be used: </section>
<list style="empty"> <section anchor="authn" numbered="true" toc="default">
<t>ecdsa-sha2-nistp384 <xref target="RFC5656" /></t> <name>Authentication</name>
<t>rsa-sha2-512 <xref target="RFC8332" /></t> <section anchor="serv-authn" numbered="true" toc="default">
</list> <name>Server Authentication</name>
<t>A signature on the exchange hash value derived from the newly establi
shed shared secret value is used to authenticate the server to the client. Serve
rs <bcp14>MUST</bcp14> be authenticated using digital signatures. The public key
algorithm implemented <bcp14>MUST</bcp14> be ecdsa-sha2-nistp384 or rsa-sha2-51
2. The RSA public key modulus <bcp14>MUST</bcp14> be 3072 or 4096 bits in size;
clients <bcp14>MUST NOT</bcp14> accept RSA signatures from a public key modulus
of any other size.
</t> </t>
<t>The following public key algorithms <bcp14>MUST</bcp14> be used:</t>
<t>The server MUST verify that the public key is a valid authenticator for the u <ul spacing="normal">
ser. If possible, validation SHOULD be done using certificates. Otherwise, the s <li>ecdsa-sha2-nistp384 <xref target="RFC5656" format="default"/></li>
erver must validate the public key through another secure, possibly off-line mec <li>rsa-sha2-512 <xref target="RFC8332" format="default"/></li>
hanism. </ul>
<t>The client <bcp14>MUST</bcp14> verify that the presented key is a val
id authenticator for the server before verifying the server signature. If possib
le, validation <bcp14>SHOULD</bcp14> be done using certificates. Otherwise, the
client <bcp14>MUST</bcp14> validate the presented public key through some other
secure, possibly off-line mechanism. Implementations <bcp14>MUST NOT</bcp14> emp
loy a "Trust on First Use (TOFU)" security model where a client accepts the firs
t public host key presented to it from a not-yet-verified server. Use of a TOFU
model would allow an intermediate adversary to present itself to the client as t
he server.
</t> </t>
<t>Where X.509 v3 Certificates are used, their use <bcp14>MUST</bcp14> c
omply with <xref target="RFC8603" format="default"/>.</t>
</section>
<t>Where X.509v3 certificates are used, their use MUST comply with <xref target= <section anchor="user-authn" numbered="true" toc="default">
"RFC8603" />. <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 <bcp14>MUST</bcp14> be authenticated, <bcp14>MUST</bcp14> follow <xre
f target="RFC4252" format="default"/>, and <bcp14>SHOULD</bcp14> be authenticate
d using a public key method. Users <bcp14>MAY</bcp14> authenticate using passwor
ds. Other methods of authentication <bcp14>MUST</bcp14> not be used, including "
none".
</t> </t>
<t>When authenticating with public key, the following public key algorit
<t>If authenticating with RSA, the client's public key modulus MUST be 3072 or 4 hms <bcp14>MUST</bcp14> be used:</t>
096 bits in size, and the server MUST NOT accept signatures from an RSA public k <ul spacing="normal">
ey modulus of any other size. <li>ecdsa-sha2-nistp384 <xref target="RFC5656" format="default"/></li>
<li>rsa-sha2-512 <xref target="RFC8332" format="default"/></li>
</ul>
<t>The server <bcp14>MUST</bcp14> verify that the public key is a valid
authenticator for the user. If possible, validation <bcp14>SHOULD</bcp14> be don
e using certificates. Otherwise, the server must validate the public key through
another secure, possibly off-line mechanism.
</t> </t>
<t>Where X.509 v3 Certificates are used, their use <bcp14>MUST</bcp14> c
<t>To facilitate client authentication with RSA using SHA-512, clients and serve omply with <xref target="RFC8603" format="default"/>.
rs SHOULD implement the server-sig-algs extension as specified in <xref target="
RFC8308" />. In that case, in the SSH_MSG_KEXINIT, the client SHALL include the
indicator ext-info-c to the kex_algorithms field, and the server SHOULD respond
with a SSH_MSG_EXT_INFO message containing the server-sig-algs extension. The se
rver MUST list only ecdsa-sha2-nistp384 and-or rsa-sha2-512 as the acceptable pu
blic key algorithms in this response.
</t> </t>
<t>If authenticating with RSA, the client's public key modulus <bcp14>MU
<t>If authenticating by passwords, it is essential that passwords have sufficien ST</bcp14> be 3072 or 4096 bits in size, and the server <bcp14>MUST NOT</bcp14>
t entropy to protect against dictionary attacks. During authentication, the pass accept signatures from an RSA public key modulus of any other size.
word MUST be protected in the established encrypted communications channel. Addi
tional guidelines are provided in <xref target="SP80063" />.
</t> </t>
<t>To facilitate client authentication with RSA using SHA-512, clients a
</section> <!-- user-authn --> nd servers <bcp14>SHOULD</bcp14> implement the server-sig-algs extension, as spe
</section> <!-- authn --> cified in <xref target="RFC8308" format="default"/>. In that case, in the SSH_MS
G_KEXINIT, the client <bcp14>SHALL</bcp14> include the indicator ext-info-c to t
<section anchor="pkt-conf-and-integ" title="Confidentiality and Data Integrity o he kex_algorithms field, and the server <bcp14>SHOULD</bcp14> respond with an SS
f SSH Binary Packets"> H_MSG_EXT_INFO message containing the server-sig-algs extension. The server <bcp
14>MUST</bcp14> list only ecdsa-sha2-nistp384 and/or rsa-sha2-512 as the accepta
<t>Secure Shell transfers data between the client and the server using its own b ble public key algorithms in this response.
inary packet structure. The SSH binary packet structure is independent of any pa
cket structure on the underlying data channel. The contents of each binary packe
t and portions of the header are encrypted, and each packet is authenticated wit
h its own message authentication code. Use of the Advanced Encryption Standard i
n Galois Counter Mode (AES GCM) will both encrypt the packet and form a 16-octet
authentication tag to ensure data integrity.
</t> </t>
<t>If authenticating by passwords, it is essential that passwords have s
<section anchor="gcm" title="Galois/Counter Mode"> ufficient entropy to protect against dictionary attacks. During authentication,
the password <bcp14>MUST</bcp14> be protected in the established encrypted commu
<t>Use of AES GCM in Secure Shell is described in <xref target="RFC5647" />. CNS nications channel. Additional guidelines are provided in <xref target="SP80063"
A complaint SSH implementations MUST support AES GCM (negotiated as AEAD_AES_GCM format="default"/>.
_256 or aes256-gcm@openssh, see <xref target="sec-mech-neg-init" />) to provide
confidentiality and ensure data integrity. No other confidentiality or data inte
grity algorithms are permitted.
</t> </t>
</section>
<t>The AES GCM invocation counter is incremented mod 2^64. That is, after proces sing a binary packet: </section>
<list style="empty"> <section anchor="pkt-conf-and-integ" numbered="true" toc="default">
<t>invocation_counter = invocation_counter + 1 mod 2^64</t> <name>Confidentiality and Data Integrity of SSH Binary Packets</name>
</list> <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 authenticat
ed with its own message authentication code. Use of AES-GCM will both encrypt th
e packet and form a 16-octet authentication tag to ensure data integrity.
</t> </t>
<section anchor="gcm" numbered="true" toc="default">
<t>The invocation counter MUST NOT repeat a counter value.</t> <name>Galois/Counter Mode</name>
<t>Use of AES-GCM in Secure Shell is described in <xref target="RFC5647"
</section> <!-- gcm --> format="default"/>. CNSA-complaint SSH implementations <bcp14>MUST</bcp14> supp
ort AES-GCM (negotiated as AEAD_AES_GCM_256 or aes256-gcm@openssh; see <xref tar
<section anchor="data-integ" title="Data Integrity"> get="sec-mech-neg-init" format="default"/>) to provide confidentiality and ensur
e data integrity. No other confidentiality or data integrity algorithms are perm
<t>As specified in <xref target="RFC5647" />, all 16 octets of the authenticatio itted.
n tag MUST be used as the SSH data integrity value of the SSH binary packet.
</t> </t>
<t>The AES-GCM invocation counter is incremented mod 2<sup>64</sup>. Tha
t is, after processing a binary packet:</t>
<t indent="3">invocation_counter = invocation_counter + 1 mod 2<sup>64
</sup></t>
<t>The invocation counter <bcp14>MUST NOT</bcp14> repeat a counter value
.</t>
</section>
</section> <!-- data-integ --> <section anchor="data-integ" numbered="true" toc="default">
<name>Data Integrity</name>
</section> <!-- pkt-conf-and-integ --> <t>As specified in <xref target="RFC5647" format="default"/>, all 16 oct
ets of the
<section anchor="rekeying" title="Rekeying"> authentication tag <bcp14>MUST</bcp14> be used as the SSH data integrity
value of the SSH
<t>Section 9 of <xref target="RFC4253" /> allows either the server or the client binary packet.</t>
to initiate a ‘key re-exchange by sending an SSH_MSG_KEXINIT packet’ and to ‘ch </section>
ange some or all of the (cipher) algorithms during re-exchange.’ This specifica
tion requires the same cipher suite to be employed when re-keying, that is, the
cipher algorithms MUST NOT be changed when a rekey occurs.
</t>
</section> <!-- rekeying --> </section>
<section anchor="sec-considerations" title="Security Considerations"> <section anchor="rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>The security considerations of <xref target="RFC4251" />, <xref target="RFC42 52" />, <xref target="RFC4253" />, <xref target="RFC5647" />, and <xref target=" RFC5656" /> apply. <t><xref target="RFC4253" section="9" sectionFormat="of" format="default"/ > allows either the server or the client to initiate a "key re-exchange ... by s ending an SSH_MSG_KEXINIT packet" and to "change some or all of the [cipher] alg orithms during the re-exchange". This specification requires the same cipher su ite to be employed when rekeying; that is, the cipher algorithms <bcp14>MUST NOT </bcp14> be changed when a rekey occurs.
</t> </t>
</section>
</section> <!-- sec-considerations --> <section anchor="sec-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="iana" title="IANA Considerations"> <t>The security considerations of <xref target="RFC4251" format="default"/
>, <xref
<t>No IANA actions are requested. target="RFC4252" format="default"/>, <xref target="RFC4253" format="defaul
</t> t"/>, <xref
target="RFC5647" format="default"/>, and <xref target="RFC5656" format="de
fault"/>
apply.</t>
</section>
</section> <!-- iana --> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle> </middle>
<back>
<back> <!-- *****BACK MATTER ***** --> <references>
<name>References</name>
<references title="Normative References"> <references>
<name>Normative References</name>
<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Policies. <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Pol
htm"> icies.htm">
<front> <front>
<title>Use of Public Standards for Secure Information Sharing</title> <title>Use of Public Standards for Secure Information Sharing</title
<author><organization>Committee for National Security Systems</organizatio >
n></author> <author>
<date month="October" year="2016"></date> <organization>Committee for National Security Systems</organizatio
</front> n>
<seriesInfo name="CNSSP" value="15"></seriesInfo> </author>
</reference> <!-- CNSA --> <date month="October" year="2016"/>
</front>
<seriesInfo name="CNSSP" value="15"/>
</reference>
<reference anchor="FIPS180" target="https://doi.org/10.6028/NIST.FIPS.180-4"> <reference anchor="FIPS180" target="https://doi.org/10.6028/NIST.FIPS.180-4">
<front> <front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>National Institute of Standards and Technology</organizati <organization>National Institute of Standards and Technology</orga
on> nization>
</author> </author>
<date month="August" year="2015" /> <date month="August" year="2015"/>
</front> </front>
<seriesInfo name="Federal Information Processing Standard" value="180-4" /> <seriesInfo name="FIPS PUB" value="180-4"/>
</reference> <!-- FIPS180 --> <seriesInfo name='DOI' value='10.6028/NIST.FIPS.180-4' />
</reference>
&rfc2119; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
&rfc4251; C.2119.xml"/>
&rfc4252; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc4253; FC.4251.xml"/>
&rfc5647; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc5656; FC.4252.xml"/>
&rfc8174; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc8268; FC.4253.xml"/>
&rfc8308; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc8332; FC.5647.xml"/>
&rfc8603; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8268.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8308.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8332.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8603.xml"/>
</references>
<references>
<name>Informative References</name>
</references> <!-- Normative --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9142. xml"/>
<references title="Informative References"> <reference anchor="SP800-38D" target="https://doi.org/10.6028/NIST.SP.800-38D"
>
<front>
<title>Recommendation for Block Cipher Modes of Operation: Ga
lois/Counter Mode (GCM) and GMAC</title>
<author>
<organization>National Institute of Standards and Techn
ology</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 <reference anchor="SP80056A" target="https://doi.org/10.6028/NIST.SP.800-
"> 56Ar3">
<front> <front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Discre <title>Recommendation for Pair-Wise Key Establishment Schemes Using
te Logarithm Cryptography</title> Discrete Logarithm Cryptography</title>
<author> <author>
<organization>National Institute of Standards and Technology</organizati <organization>National Institute of Standards and Technology</orga
on> nization>
</author> </author>
<date month="April" year="2018" /> <date month="April" year="2018"/>
</front> </front>
<seriesInfo name="NIST Special Publication" value="800-56A, Revision 3" /> <refcontent>Revision 3</refcontent>
</reference> <!-- SP80056A --> <seriesInfo name="NIST Special Publication" value="800-56A"/>
<seriesInfo name='DOI' value='10.6028/NIST.SP.800-56Ar3' />
</reference>
<reference anchor="SP80059" target="https://doi.org/10.6028/NIST.SP.800-59"> <reference anchor="SP80059" target="https://doi.org/10.6028/NIST.SP.800-59">
<front> <front>
<title>Guideline for Identifying an Information System as a National Secur <title>Guideline for Identifying an Information System as a National
ity System</title> Security
<author> System</title>
<organization>National Institute of Standards and Technology</organizati <author>
on> <organization>National Institute of Standards and Technology</orga
</author> nization>
<date month="August" year="2003" /> </author>
</front> <date month="August" year="2003"/>
<seriesInfo name="Special Publication 800-59" value="" /> </front>
</reference> <!-- SP80059 --> <seriesInfo name="NIST Special Publication" value="800-59"/>
<seriesInfo name='DOI' value='10.6028/NIST.SP.800-59' />
</reference>
<reference anchor="SP80063" target="https://doi.org/10.6028/NIST.SP.800-63-3"> <reference anchor="SP80063" target="https://doi.org/10.6028/NIST.SP.800-63-3">
<front> <front>
<title>Digital Identity Guidelines</title> <title>Digital Identity Guidelines</title>
<author> <author>
<organization>National Institute of Standards and Technology</organizati <organization>National Institute of Standards and Technology</orga
on> nization>
</author> </author>
<date month="June" year="2017" /> <date month="June" year="2017"/>
</front> </front>
<seriesInfo name="NIST Special Publication" value="800-63, Revision 3" /> <seriesInfo name="NIST Special Publication" value="800-63-3"/>
</reference> <!-- SP80063 --> <seriesInfo name='DOI' value='10.6028/NIST.SP.800-63-3' />
</reference>
</references> <!-- Informative -->
</back> <!-- ===== END BACK MATTER ===== --> </references>
</references>
</back>
</rfc> </rfc>
 End of changes. 82 change blocks. 
460 lines changed or deleted 474 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/