RFC 9212 INFORMATIONAL SECURITY · CRYPTOGRAPHY · SSH
CNSA Suite for SSH: Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)
NSA-approved cryptographic algorithms for securing government SSH connections.
RFC EDITOR
Gajcowski, N. and M. Jenkins, "Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)", RFC 9212, DOI 10.17487/RFC9212, March 2022, <https://www.rfc-editor.org/info/rfc9212>.
BIBTEX
@misc{rfc9212,
series = {Request for Comments},
number = 9212,
howpublished = {RFC 9212},
publisher = {RFC Editor},
doi = {10.17487/RFC9212},
url = {https://www.rfc-editor.org/info/rfc9212},
author = {N. Gajcowski and M. Jenkins},
title = {{Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)}},
pagetotal = 10,
year = 2022,
month = mar,
} RFC text
Contents
Independent Submission N. Gajcowski
Request for Comments: 9212 M. Jenkins
Category: Informational NSA
ISSN: 2070-1721 March 2022
Commercial National Security Algorithm (CNSA) Suite Cryptography for
Secure Shell (SSH)
Abstract
The United States Government has published the 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 (described in NIST Special Publication 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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9212.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction
2. Terminology
3. The Commercial National Security Algorithm Suite
4. CNSA and Secure Shell
5. Security Mechanism Negotiation and Initialization
6. Key Exchange
6.1. ECDH Key Exchange
6.2. DH Key Exchange
7. Authentication
7.1. Server Authentication
7.2. User Authentication
8. Confidentiality and Data Integrity of SSH Binary Packets
8.1. Galois/Counter Mode
8.2. Data Integrity
9. Rekeying
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Authors' Addresses
1. Introduction
This document specifies conventions for using the United States
National Security Agency's CNSA Suite algorithms [CNSA] with the
Secure Shell Transport Layer Protocol [RFC4253] and the Secure Shell
Authentication Protocol [RFC4252]. It applies to the capabilities,
configuration, and operation of all components of US National
Security Systems (described in NIST Special Publication 800-59
[SP80059]) 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.
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.
3. The Commercial National Security Algorithm Suite
The 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's 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. 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., to elliptic curve 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.
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.
4. CNSA and Secure Shell
Several RFCs have documented how each of the CNSA components are to
be integrated into Secure Shell (SSH):
kex algorithms:
* ecdh-sha2-nistp384 [RFC5656]
* diffie-hellman-group15-sha512 [RFC8268]
* diffie-hellman-group16-sha512 [RFC8268]
public key algorithms:
* ecdsa-sha2-nistp384 [RFC5656]
* rsa-sha2-512 [RFC8332]
encryption algorithms (both client_to_server and server_to_client):
* AEAD_AES_256_GCM [RFC5647]
message authentication code (MAC) algorithms (both client_to_server
and server_to_client):
* AEAD_AES_256_GCM [RFC5647]
While the approved CNSA hash function for all purposes is SHA-384, as
defined in [FIPS180], commercial products are more likely to
incorporate the kex algorithms and public key algorithms based on
SHA-512 (sha2-512), which are defined in [RFC8268] and [RFC8332].
Therefore, the SHA-384-based kex and public key algorithms SHOULD be
used; SHA-512-based algorithms MAY be used. Any hash algorithm other
than SHA-384 or SHA-512 MUST NOT be used.
Use of the Advanced Encryption Standard in Galois/Counter Mode (AES-
GCM) shall meet the requirements set forth in [SP800-38D], with the
additional requirements that all 16 octets of the authentication tag
MUST 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 [RFC5647], 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, [RFC5647] fails to specify
that the AES-GCM invocation counter is incremented mod 2^64. CNSA
implementations MUST ensure the counter never repeats and is properly
incremented after processing a binary packet:
invocation_counter = invocation_counter + 1 mod 2^64.
The purpose of this document is to draw upon all of these documents
to provide guidance for CNSA-compliant implementations of Secure
Shell. Algorithms specified in this document may be different from
mandatory-to-implement algorithms; where this occurs, the latter will
be present but not used. Note that, while compliant Secure Shell
implementations MUST 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.
5. Security Mechanism Negotiation and Initialization
As described in Section 7.1 of [RFC4253], 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.
The choice of all but the user authentication methods is determined
by the exchange of SSH_MSG_KEXINIT between the client and the server.
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 4. While [RFC9142] establishes general
guidance on the capabilities of SSH implementations and requires
support for "diffie-hellman-group14-sha256", it MUST NOT be used.
The result MUST be one of the following kex_algorithms, or the
connection MUST be terminated:
* ecdh-sha2-nistp384 [RFC5656]
* diffie-hellman-group15-sha512 [RFC8268]
* diffie-hellman-group16-sha512 [RFC8268]
One of the following sets MUST be used for the encryption_algorithms
and mac_algorithms name-lists. Either set MAY be used for each
direction (i.e., client_to_server or server_to_client), but the
result must be the same (i.e., use of AEAD_AES_256_GCM).
encryption_algorithm_name_list := { AEAD_AES_256_GCM }
mac_algorithm_name_list := { AEAD_AES_256_GCM }
or
encryption_algorithm_name_list := { aes256-gcm@openssh.com }
mac_algorithm_name_list := {}
One of the following public key algorithms MUST be used:
* rsa-sha2-512 [RFC8332]
* ecdsa-sha2-nistp384 [RFC5656]
The procedures for applying the negotiated algorithms are given in
the following sections.
6. Key Exchange
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 between the client and the server.
A compliant system MUST NOT 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 [SP80056A] states that an
ephemeral private key shall be used in exactly one key establishment
transaction and shall be destroyed (zeroized) as soon as possible.
Section 5.8 of [SP80056A] states that such shared secrets shall be
destroyed (zeroized) immediately after its use. CNSA-compliant
systems MUST follow these mandates.
6.1. ECDH Key Exchange
The key exchange begins with the SSH_MSG_KEXECDH_INIT message that
contains the client's ephemeral public key used to generate a shared
secret value.
The server responds to an SSH_MSG_KEXECDH_INIT message with an
SSH_MSG_KEXECDH_REPLY message 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 be ecdh-sha2-nistp384, and the public
key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512.
6.2. DH Key Exchange
The key exchange begins with the SSH_MSG_KEXDH_INIT message that
contains the client's DH exchange value used to generate a shared
secret value.
The server responds to an SSH_MSG_KEXDH_INIT message with 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 be one of diffie-hellman-group15-sha512 or
diffie-hellman-group16-sha512, and the public key algorithm MUST be
either ecdsa-sha2-nistp384 or rsa-sha2-512.
7. Authentication
7.1. Server Authentication
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 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.
The following public key algorithms MUST be used:
* ecdsa-sha2-nistp384 [RFC5656]
* rsa-sha2-512 [RFC8332]
The client MUST verify that the presented key is a valid
authenticator for the server before verifying the server signature.
If possible, validation SHOULD be done using certificates.
Otherwise, the client MUST validate the presented public key through
some other secure, possibly off-line mechanism. Implementations MUST
NOT employ a "Trust on First Use (TOFU)" security model where a
client accepts 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 client as the server.
Where X.509 v3 Certificates are used, their use MUST comply with
[RFC8603].
7.2. User Authentication
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 be authenticated, MUST follow [RFC4252],
and SHOULD be authenticated using a public key method. Users MAY
authenticate using passwords. Other methods of authentication MUST
not be used, including "none".
When authenticating with public key, the following public key
algorithms MUST be used:
* ecdsa-sha2-nistp384 [RFC5656]
* rsa-sha2-512 [RFC8332]
The server MUST verify that the public key is a valid authenticator
for the user. If possible, validation SHOULD be done using
certificates. Otherwise, the server must validate the public key
through another secure, possibly off-line mechanism.
Where X.509 v3 Certificates are used, their use MUST comply with
[RFC8603].
If authenticating with RSA, the client's public key modulus MUST be
3072 or 4096 bits in size, and the server MUST NOT accept signatures
from an RSA public key modulus of any other size.
To facilitate client authentication with RSA using SHA-512, clients
and servers SHOULD implement the server-sig-algs extension, as
specified in [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 an SSH_MSG_EXT_INFO message
containing the server-sig-algs extension. The server MUST list only
ecdsa-sha2-nistp384 and/or rsa-sha2-512 as the acceptable public key
algorithms in this response.
If authenticating by passwords, it is essential that passwords have
sufficient entropy to protect against dictionary attacks. During
authentication, the password MUST be protected in the established
encrypted communications channel. Additional guidelines are provided
in [SP80063].
8. Confidentiality and Data Integrity of SSH Binary Packets
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 AES-GCM will both encrypt the packet and
form a 16-octet authentication tag to ensure data integrity.
8.1. Galois/Counter Mode
Use of AES-GCM in Secure Shell is described in [RFC5647]. CNSA-
complaint SSH implementations MUST support AES-GCM (negotiated as
AEAD_AES_GCM_256 or aes256-gcm@openssh; see Section 5) to provide
confidentiality and ensure data integrity. No other confidentiality
or data integrity algorithms are permitted.
The AES-GCM invocation counter is incremented mod 2^64. That is,
after processing a binary packet:
invocation_counter = invocation_counter + 1 mod 2^64
The invocation counter MUST NOT repeat a counter value.
8.2. Data Integrity
As specified in [RFC5647], all 16 octets of the authentication tag
MUST be used as the SSH data integrity value of the SSH binary
packet.
9. Rekeying
Section 9 of [RFC4253] allows either the server or the client to
initiate a "key re-exchange ... by sending an SSH_MSG_KEXINIT packet"
and to "change some or all of the [cipher] algorithms during the re-
exchange". This specification requires the same cipher suite to be
employed when rekeying; that is, the cipher algorithms MUST NOT be
changed when a rekey occurs.
10. Security Considerations
The security considerations of [RFC4251], [RFC4252], [RFC4253],
[RFC5647], and [RFC5656] apply.
11. IANA Considerations
This document has no IANA actions.
12. References
12.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.cfm>.
[FIPS180] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
[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>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
Secure Shell Transport Layer Protocol", RFC 5647,
DOI 10.17487/RFC5647, August 2009,
<https://www.rfc-editor.org/info/rfc5647>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>.
[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>.
[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-
Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
<https://www.rfc-editor.org/info/rfc8268>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
the Secure Shell (SSH) Protocol", RFC 8332,
DOI 10.17487/RFC8332, March 2018,
<https://www.rfc-editor.org/info/rfc8332>.
[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>.
12.2. Informative References
[RFC9142] Baushke, M., "Key Exchange (KEX) Method Updates and
Recommendations for Secure Shell (SSH)", RFC 9142,
DOI 10.17487/RFC9142, January 2022,
<https://www.rfc-editor.org/info/rfc9142>.
[SP800-38D]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November
2007, <https://doi.org/10.6028/NIST.SP.800-38D>.
[SP80056A] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", Revision 3, NIST
Special Publication 800-56A,
DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>.
[SP80059] National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National
Security System", NIST Special Publication 800-59,
DOI 10.6028/NIST.SP.800-59, August 2003,
<https://doi.org/10.6028/NIST.SP.800-59>.
[SP80063] National Institute of Standards and Technology, "Digital
Identity Guidelines", NIST Special Publication 800-63-3,
DOI 10.6028/NIST.SP.800-63-3, June 2017,
<https://doi.org/10.6028/NIST.SP.800-63-3>.
Authors' Addresses
Nicholas Gajcowski
National Security Agency
Email: nhgajco@uwe.nsa.gov
Michael Jenkins
National Security Agency
Email: mjjenki@cyber.nsa.gov
AI ELI5
On this page
PROBLEMUS Government systems need to use cryptographically strong algorithms for SSH that meet national security requirements and are resistant to future quantum computing threats.
MECHANISMThis RFC specifies which algorithms, key sizes, and configuration options from the NSA's Commercial National Security Algorithm Suite must be used with SSH for key exchange, authentication, and encryption.
POLICY GUIDANCEGovernment agencies can deploy SSH with standardized, approved cryptographic algorithms designed to protect sensitive communications.
§1Introduction and Background
This RFC specifies how to use the Commercial National Security Algorithm (CNSA) Suite with the Secure Shell protocol (SSH). The CNSA Suite is a set of cryptographic algorithms approved by the United States National Security Agency for protecting government information systems.
The RFC applies to all US National Security Systems that use SSH, and also to other US Government systems handling high-value information. It draws on earlier RFCs that documented how individual CNSA components integrate with SSH, providing a single authoritative guide for proper configuration.
The CNSA Suite was established to provide flexibility during the transition to quantum-resistant cryptography. Rather than forcing agencies to make two major cryptographic transitions in a short timeframe, CNSA allows gradual evolution while maintaining security standards today.
The government needs secure ways for computers to talk to each other. The NSA approves specific locks that are strong enough for sensitive work.
§2Approved Algorithms
The CNSA Suite for SSH requires specific algorithms in four areas:
Key Exchange: Three algorithms are approved: ecdh-sha2-nistp384 (Elliptic Curve Diffie-Hellman using the NIST P-384 curve with SHA-384), and two Diffie-Hellman variants using SHA-512 with 15- and 16-bit group parameters. The RFC states that SHA-384-based algorithms SHOULD be preferred, though SHA-512 MAY be used.
Authentication: Two public key algorithms are approved: ecdsa-sha2-nistp384 (Elliptic Curve Digital Signature Algorithm) and rsa-sha2-512 (RSA with SHA-512). For RSA, the key modulus must be either 3072 or 4096 bits; other sizes are rejected.
Encryption and Integrity: Only AEAD_AES_256_GCM (Advanced Encryption Standard in Galois/Counter Mode with 256-bit keys) is permitted for both encryption and message authentication. All 16 octets of the authentication tag must be used, and the invocation counter must be properly incremented modulo 2^64 with no repeats.
The approved locks use three types of math: elliptic curves (strong and modern), big prime numbers (Diffie-Hellman), and AES encryption. The government says which specific versions to use.
| Category | Approved Algorithms |
|---|---|
| Key Exchange | ecdh-sha2-nistp384, diffie-hellman-group15-sha512, diffie-hellman-group16-sha512 |
| Public Key (Authentication) THIS RFC | ecdsa-sha2-nistp384, rsa-sha2-512 (3072 or 4096-bit keys) |
| Encryption & Integrity | AEAD_AES_256_GCM or aes256-gcm@openssh.com |
| Hash Functions | SHA-384 (preferred) or SHA-512 |
§3Algorithm Negotiation
When a client and server establish an SSH connection, they exchange SSH_MSG_KEXINIT packets to negotiate which algorithms to use. The RFC specifies that all algorithm choices must result in the approved combinations above.
The kex_algorithms field in KEXINIT must contain one of the three approved key exchange algorithms; RFC 9142's diffie-hellman-group14-sha256 must NOT be used. Similarly, the server and client must agree on one of the two approved public key algorithms for authentication.
For encryption and MAC algorithms, implementations may advertise either the explicit AEAD_AES_256_GCM as both encryption and MAC, or use the OpenSSH-specific aes256-gcm@openssh.com notation with an empty MAC list. Both achieve the same result: AES-256-GCM for both confidentiality and integrity.
When computers start talking, they say which locks they'll use. Both sides must pick from the approved list, or the connection stops.
§4Key Exchange and Authentication
The RFC specifies two key exchange methods. With ECDH, the client sends an ephemeral public key and the server responds with its ephemeral key, the server's permanent host key, and a signature over the exchange hash. With Diffie-Hellman, the flow is similar but uses discrete logarithm parameters instead of elliptic curves.
Critical to CNSA compliance: ephemeral private keys must be used exactly once and destroyed immediately after the key exchange. Shared secrets must be zeroized immediately after use. This prevents any reuse of exchange values that could compromise security.
Server authentication uses a digital signature on the exchange hash. The server's public key must be validated by the client before accepting the signature—either through certificates or another secure mechanism. The RFC explicitly forbids the Trust-On-First-Use (TOFU) model, where clients accept unverified keys from servers they have never contacted before.
User authentication follows RFC 4252 and should be done with public keys (using the same approved algorithms as server authentication). Password authentication is permitted if passwords have sufficient entropy, but other methods including 'none' are not allowed. If RSA is used for user authentication, keys must be 3072 or 4096 bits.
During login, computers prove they are who they say using math and signatures. Keys get thrown away after use. Trusting a stranger's key is forbidden.
§5Encryption, Integrity, and Rekeying
SSH binary packets use AES-256-GCM for both encryption and authentication. The GCM mode produces a 16-octet authentication tag that serves as SSH's data integrity check; all 16 octets must be used. The invocation counter (used to prevent cipher stream reuse) increments modulo 2^64 and must never repeat.
RFC 4253 permits servers and clients to rekey—to exchange new SSH_MSG_KEXINIT packets and establish new algorithms. However, the CNSA Suite requires that cipher algorithms remain the same during rekeying. The same AES-256-GCM configuration must continue; no algorithm switching is allowed.
Every message gets scrambled with a strong cipher and a checksum. When computers refresh their shared secret, they keep using the same cipher.
§6References
[CNSA]Committee for National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSSP 15, October 2016.
[RFC4251]RFC 4251Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.January 2006[RFC4252]RFC 4252Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.January 2006[RFC4253]RFC 4253Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.January 2006[RFC5647]RFC 5647Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", RFC 5647, August 2009.August 2009[RFC5656]RFC 5656Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, December 2009.December 2009[RFC8268]RFC 8268Baushke, M., "More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)", RFC 8268, December 2017.December 2017[RFC8308]RFC 8308Bider, D., "Extension Negotiation in the Secure Shell (SSH) Protocol", RFC 8308, March 2018.March 2018[RFC8332]RFC 8332Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol", RFC 8332, March 2018.March 2018[RFC8603]RFC 8603Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, May 2019.May 2019