Commercial National Security Algorithm (CNSA) Suite Profile for SSH
draft-becker-cnsa2-ssh-profile-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Alison Becker , Casey Wynn | ||
| Last updated | 2025-06-06 (Latest revision 2025-04-17) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | Submission Received | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-becker-cnsa2-ssh-profile-01
Network Working Group A. Becker
Internet-Draft C. Wynn
Obsoletes: 9212 (if approved) NSA
Intended status: Informational 17 April 2025
Expires: 19 October 2025
Commercial National Security Algorithm (CNSA) Suite Profile for SSH
draft-becker-cnsa2-ssh-profile-01
Abstract
This document defines a base profile of SSH for use with the U.S.
Commercial National Security Algorithm (CNSA) 2.0 Suite, a
cybersecurity advisory published by the United States Government
which outlines quantum-resistant cryptographic algorithm policy for
U.S. national security applications.
This profile applies to the capabilities, configuration, and
operation of all components of U.S. National Security Systems that
employ SSH. It is also appropriate for all other U.S. Government
systems that process high-value information.
This profile is made publicly available for use by developers and
operators of these and any other system deployments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 October 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Becker & Wynn Expires 19 October 2025 [Page 1]
Internet-Draft CNSA2 SSH Profile April 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Commercial National Security Algorithm Suite . . . . . . 3
4. CNSA 2.0 Compliance . . . . . . . . . . . . . . . . . . . . . 4
4.1. CNSA 2.0 Suite . . . . . . . . . . . . . . . . . . . . . 4
5. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. SSH_MSG_KEXINIT Overview . . . . . . . . . . . . . . . . 5
5.2. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Server Host Authentication . . . . . . . . . . . . . . . 7
5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 8
6. User Authentication . . . . . . . . . . . . . . . . . . . . . 8
7. Confidentiality and Data Integrity . . . . . . . . . . . . . 9
8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
This document specifies a profile of SSH [RFC4253] to comply with the
National Security Agency's (NSA) Commercial National Security
Algorithm (CNSA) 2.0 Suite [annccnsa]. This profile applies to the
capabilities, configuration, and operation of all components of U.S.
National Security Systems (NSS) that employ SSH. U.S. National
Security Systems are described in NIST Special Publication 800-59
[SP80059]. This profile is also appropriate for all other U.S.
Government systems that process high-value information, and is made
publicly available for use by developers and operators of these and
any other system deployments.
The reader is assumed to have familiarity with [RFC4253].
[ED NOTE: This document uses some details from
[I-D.harrison-mlkem-ssh] to specify use of ML-KEM in SSH. We note
that the draft is not yet an RFC, and we may need to adjust this text
accordingly based on the progress of that document.]
Becker & Wynn Expires 19 October 2025 [Page 2]
Internet-Draft CNSA2 SSH Profile April 2025
[ED NOTE: This document may change to use guidance from work
specifying the use of ML-KEM and ML-DSA in SSH.]
All usage of the term "CNSA" in this document refers to CNSA 2.0
[annccnsa], unless otherwise stated.
2. Terminology
Text from RFC2119.
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] if and only if they appear in all capitals, as
shown here.
All MUST-level requirements of [RFC4253], apply throughout this
profile; they are generally not repeated. In cases where a MUST-
level requirement is repeated for clarity, the source document
prevails. This profile may contain changes that elevate or downgrade
some SHOULD- or MUST-level options from a specified RFC. All options
from [RFC4253], that are not mentioned in this profile remain at the
requirement level of the reference.
All usage of the term "CNSA" in this document refers to CNSA 2.0
[annccnsa], unless otherwise stated.
3. The Commercial National Security Algorithm Suite
The National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure,
interoperable communications for U.S. Government National Security
Systems (NSS). To this end, it publishes guidance both to assist
with the U.S. Government transition to new algorithms and to provide
vendors - and the internet community in general - with information
concerning their proper use and configuration within the scope of
U.S. Government National Security Systems.
The Commercial National Security Algorithm (CNSA) Suite is the set of
approved commercial algorithms that can be used by vendors and IT
users to meet cybersecurity and interoperability requirements for
NSS. The initial suite of CNSA Suite algorithms, Suite B,
established a baseline for use of commercial algorithms to protect
classified information. The following suite, CNSA 1.0, served as a
bridge between the original set and a fully quantum-resistant
cryptographic capability. The current suite, CNSA 2.0, establishes
fully quantum-resistant protection [annccnsa].
Becker & Wynn Expires 19 October 2025 [Page 3]
Internet-Draft CNSA2 SSH Profile April 2025
Pursuant to the National Security Memorandum on Promoting United
States Leadership in Quantum Computing While Mitigating Risks to
Vulnerable Cryptographic Systems [NSM-10], the National Institute for
Standards and Technology (NIST) selected several quantum-resistant,
or post-quantum, asymmetric algorithms for standardization. From
these, NSA has included two in CNSA 2.0: ML-DSA-87 [FIPS204] for
signing, and ML-KEM-1024 [FIPS203] for key establishment. ML-DSA-87
and ML-KEM-1024 together with SHA384, SHA512, AES-256, LMS, and XMSS
comprise the CNSA Suite 2.0.
The NSA is authoring a set of RFCs, including this one, to provide
updated guidance for using the CNSA 2.0 Suite in certain 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 U.S. Government
National Security Systems.
4. CNSA 2.0 Compliance
The purpose of this document is to provide guidance for CNSA-
compliant implementations of the Secure Shell (SSH) protocol
[RFC4253]. 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 in NSS. An implementation must be validated by the
appropriate authority before such usage is permitted.
4.1. CNSA 2.0 Suite
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 algorithms provided in the name-lists specified in
SSH_MSG_KEXINIT are listed in order of preference. CNSA-compliant
implementations MUST list the following algorithms as the first (most
preferred) algorithms in their respective name-lists.
Key Exchange Algorithms:
ML-KEM-1024-sha384 [FIPS203], [SHS]
[ED NOTE: Use of ML-KEM is specified in [I-D.harrison-mlkem-ssh], and
this draft only details use for ML-KEM-1024-sha384. CNSA 2.0 also
allows SHA-512 to be used for the exchange hash, but at the time of
writing, only ML-KEM-1024 with SHA-382 is specified in
[I-D.harrison-mlkem-ssh]. If SHA-512 becomes available as an option,
it will be a CNSA compliant option.]
Public Key Algorithms:
Becker & Wynn Expires 19 October 2025 [Page 4]
Internet-Draft CNSA2 SSH Profile April 2025
ML-DSA-87 [FIPS204]
[ED NOTE: There is no formal specification for use of ML-DSA in SSH,
this draft will be updated as necessary guidance is established.]
Encryption Algorithms:
AEAD_AES_256_GCM [RFC5647]
aes256-gcm@openssh.com
MAC Algorithms (both client_to_server and server_to_client):
AEAD_AES_256_GCM [RFC5647]
Any algorithms not appearing in the above list MUST NOT be negotiated
for use in a CNSA-compliant implementation of SSH.
[ED NOTE: The authors are tracking draft-miller-sshm-aes-gcm with
regard to the use of AES-256 GCM for encryption and MAC. As the
draft progresses, we may include aes256-gcm in the Encryption
Algorithms field noted above.]
The procedures for applying the negotiated algorithms are given in
the following sections.
5. Transport Layer
5.1. SSH_MSG_KEXINIT Overview
The server and client use the SSH_MSG_KEXINIT exchange [RFC4253,
Section 7.1] to negotiate the following name-lists:
kex_algorithms
server_host_key_algorithms
encryption_algorithms (client_to_server and server_to_client)
mac_algorithms (client_to_server and server_to_client
The kex_algorithms name-list is used to negotiate key exchange
algorithms and hash used in the exchange hash. This is discussed
further in Section 5.2.
The server_host_key_algorithms name-list is used to identify the
algorithms for which the server has host keys, and which the client
is willing to accept. This is discussed in Section 5.3.
Becker & Wynn Expires 19 October 2025 [Page 5]
Internet-Draft CNSA2 SSH Profile April 2025
The encryption_algorithms and mac_algorithms name-lists are used to
negotiate symmetric encryption and MAC algorithm. These name-lists
are discussed in more detail in Section 5.4.
5.2. Key Exchange
This document does not preclude implementations that contain
algorithms other than those specified in CNSA 2.0, such as the
mandatory-to-implement algorithms listed in the Key Exchange Method
Names (also known as those containinng "MUST" in the OK to Implement
column). However, algorithms that are not CNSA compliant must not be
negotiated and used in a CNSA-compliant connection.
A CNSA compliant connection MUST NOT allow the reuse of ephemeral/
exchange values in a key exchange algorithm due to security concerns
related to this practice. In accordance with [SP80056A], an
ephemeral private key shall be used in exactly one key establishment
transaction and shall be destroyed (zeroized) as soon as possible.
The key exchange algorithm and hash is determined by the
kex_algorithms name-list exchanged in the SSH_MSG_KEXINIT packets
[RFC 4253 Section 7.1], as described above.
For CNSA compliant connections, the following MUST be negotiated in
the kex_algorithms name-list of SSH_MSG_KEXINIT, and MUST be the
first (most preferred) choice in the list:
Key Exchange: ML-KEM-1024 MUST be used to establish a shared
secret value between the client and the server. Any algorithm
other than ML-KEM-1024 MUST NOT be negotiated for key exchange in
a CNSA-compliant connection.
Hash Algorithm: The exchange hash MUST be generated using either
SHA-384 or SHA-512, or the connection MUST be terminated. Any
algorithm other than SHA-384 or SHA-512 MUST NOT be negotiated for
hashing in a CNSA-compliant connection.
[ED NOTE: CNSA 2.0 compliance requires the use of ML-KEM-1024 for key
establishment, and SHA-384 or SHA-512 for hashing. [RFC9142] does
not provide guidance for use of ML-KEM in SSH, but recently posted
[I-D.harrison-mlkem-ssh] details guidance on the technical function
necessary to include ML-KEM in SSH. Currently, the kex message
exchange requires use of SSH_MSG_KEXDH_INIT [RFC4253], or
SSH_MSG_ECDH_INIT [RFC5656], and the details are given in that
document. This document is subject to change as
[I-D.harrison-mlkem-ssh] progresses. ]
Becker & Wynn Expires 19 October 2025 [Page 6]
Internet-Draft CNSA2 SSH Profile April 2025
The key exchange is started by the client and server sending an
SSH_MSG_KEXINIT message. In SSH_MSG_KEXINIT, both the client and
server MUST include ML-KEM-1024-sha384 [I-D.harrison-mlkem-ssh] in
the kex_algorithms name-list, and ML-KEM-1024-sha384 MUST be the
first (most preferred) algorithm in the list.
For use of ML-KEM, the client sends the public key output, PK, of the
ML-KEM KeyGen algorithm in a following message.
The server then sends its reply message, which includes the
ciphertext output, CT, of the ML-KEM Encaps algorithm, and the
server’s ephemeral public host key. The exchange hash is then
generated and signed by the server.
Note that [I-D.harrison-mlkem-ssh] details several checks that must
also be performed for the ML-KEM algorithm components.
5.3. Server Host Authentication
For server host authentication, the server sends the client the
server_host_key_algorithms name-list packet of the SSH_MSG_KEXINIT
message. For CNSA compliant connections, ML-DSA-87 MUST be listed as
the first (most preferred) algorithm in server_host_key_algorithms.
The server generates the exchange hash H as defined in Section 5.2
and signs it using its private host key. CNSA 2.0 compliance
requires the use of ML-DSA-87 for signatures.
[ED NOTE: There is no formal specification for use of ML-DSA in SSH,
this draft will be updated as necessary guidance is established.]
Authentication by the client is a two-step process of validating the
presented public key and verifying the signature. By default, the
server sends a raw public key, but it could be an X.509 certificate.
For CNSA compliant connections, servers MUST be authenticated using
digital signatures. The public key algorithm implemented MUST be ML-
DSA-87. Where possible, public keys SHOULD be validated with
certificates, otherwise, the client MUST validate the presented
public key through another secure, possibly offline, mechanism.
CSNA compliant 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. If raw public
key format is used, the trust anchor MUST be securely distributed.
Becker & Wynn Expires 19 October 2025 [Page 7]
Internet-Draft CNSA2 SSH Profile April 2025
Where X.509 certificates are used, they must comply with [RFC8603].
Details on CNSA compliance and certificates can be found in
[I-D.jenkins-cnsa2-pkix-profile].
5.4. Encryption
One of the following sets MUST be used for the encryption_algorithms
and mac_algorithms name-lists in SSH_MSG_KEXDH. Either set MAY be
used for each direction (client_to_server and server_to_client):
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 := {}
For encryption, use of AES-GCM MUST meet the requirements in
[SP80038D], 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 in aes256-gcm@openssh.com). In addition, the AES-
GCM invocation counter is incremented mod 2^64:
invocation_counter = invocation_counter + 1 mod 2^64
CNSA compliant implementations MUST NOT repeat a counter value, and
MUST ensure the counter is properly incremented after processing a
binary packet.
6. User Authentication
The user authentication protocol for authenticating the client to the
server is specified in [RFC4252]. For CNSA compliant connections,
all users MUST be authenticated as outlined in [RFC4252], and SHOULD
be authenticated using a public key method.
Specifically, all users MUST be authenticated and SHOULD be
authenticated using public key. Users MAY authenticated using
passwords subject to requirements in this section. CNSA compliant
connections MUST NOT use other methods of authentication, including
hostbased authentication, keyboard-interactive authentication, or
“none”.
Becker & Wynn Expires 19 October 2025 [Page 8]
Internet-Draft CNSA2 SSH Profile April 2025
When authenticating with public key, CNSA compliant connects MUST use
ML-DSA-87.
The server MUST verify that the public key is a valid authenticator
for the user. Public key authentication is a two-step process of
validating the public key and verifying the signature. In order for
the server to verify the client, it must have a copy of the client’s
public key in advance. If possible, validation SHOULD be done using
certificates. Otherwise, the server must validate the public key
through another secure, possibly offline, mechanism. When
certificates are used, the file can list the CA key preceded by the
string “@cert-authority” instead of the user key.
When algorithms are negotiated in SSH_MSG_KEXINIT, the SSH protocol
defined in [RFC 4253] does not require the server to declare its
supported algorithms for user host key, and the server will reject
public key authentication requests for key types it does not support.
For CNSA compliant connections, the client MUST use ML-DSA-87.
Recent OpenSSH implementations do require the server to declare its
supported algorithms via mechanisms detailed in [RFC 8308]. The
client includes “ext-info-c” in the kex_algorithms field of the
SSH_MSG_KEXINIT message, to indicate that it wants to negotiate an
SSH extension. In OpenSSH versions 9.5 and 9.6, “ext-info-c” is
automatically appended and forces the server to list the user
authentication methods it support. CNSA compliant servers MUST list
ML-DSA_87.
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 guidance on password
requirements are provided in [SP80063].
7. Confidentiality and Data Integrity
Use of AES-GCM in SSH is detailed in [RFC5647]. CNSA compliant
implementations MUST support AES-GCM as described in SECTION, to
provide confidentiality and ensure data integrity. No other
confidentiality or data integrity algorithms are permitted.
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.
Becker & Wynn Expires 19 October 2025 [Page 9]
Internet-Draft CNSA2 SSH Profile April 2025
8. 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
reexchange". For CNSA compliant implementations, the same cipher
suite MUST be employed when rekeying; that is, the cipher algorithms
MUST NOT be changed when a rekey occurs.
9. Security Considerations
Most of the security considerations for this document are described
in [RFC4253], [RFC5647], [RFC4252]. Additional security
considerations for the use of ML-KEM in SSH can be found in
[I-D.harrison-mlkem-ssh].
10. IANA Considerations
This document has no IANA actions
11. References
[AES] National Institute of Standards and Technology,
"Announcing the ADVANCED ENCRYPTION STANDARD (AES)",
FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001,
<https://nvlpubs.nist.gov/nistpubs/fips/
NIST.FIPS.197.pdf>.
[annccnsa] National Security Agency, "Announcing the Commercial
National Security Algorithm Suite 2.0", September 2022,
<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/
CSA_CNSA_2.0_ALGORITHMS_.PDF>.
[FIPS203] National Institute of Standards and Technology (2024),
"Module-Lattice-Based Key-Encapsulation Mechanism
Standard", (Department of Commerce, Washington,
D.C.), Federal Information Processing Standards
Publication (FIPS), NIST FIPS 203,
<https://doi.org/10.6028/NIST.FIPS.203>.
[FIPS204] National Institute of Standards and Technology (2024),
"Module-Lattice-Based Digital Signature Standard",
(Department of Commerce, Washington, D.C.), Federal
Information Processing Standards Publication (FIPS), NIST
FIPS 204, <https://doi.org/10.6028/NIST.FIPS.204>.
Becker & Wynn Expires 19 October 2025 [Page 10]
Internet-Draft CNSA2 SSH Profile April 2025
[GCM] Dworkin, M., "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://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38d.pdf>.
[I-D.harrison-mlkem-ssh]
Harrison, A., "Module-Lattice Key Exchange in SSH",
January 2025, <https://datatracker.ietf.org/doc/draft-
harrison-mlkem-ssh/00/>.
[I-D.jenkins-cnsa2-pkix-profile]
Jenkins, M. and A. Becker, "Commercial National Security
Algorithm Suite Certificate and Certificate Revocation
List Profile", January 2025,
<https://datatracker.ietf.org/doc/draft-jenkins-cnsa2-
pkix-profile/>.
[NSM-10] United States, The White House, "National Security
Memorandum on Promoting United States Leadership in
Quantum Computing While Mitigating Risks to Vulnerable
Cryptographic Systems", NSM 10, May 2022,
<https://www.whitehouse.gov/briefing-room/statements-
releases/2022/05/04/national-security-memorandum-on-
promoting-united-states-leadership-in-quantum-computing-
while-mitigating-risks-to-vulnerable-cryptographic-
systems/>.
[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>.
[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>.
Becker & Wynn Expires 19 October 2025 [Page 11]
Internet-Draft CNSA2 SSH Profile April 2025
[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>.
[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>.
[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>.
[SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4,
FIPS PUB 180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[SP80038D] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC, NIST Special
Publication 800-38D", 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", 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", Special Publication 59, DOI
10.6028/NIST.SP.800-59, August 2003,
<https://csrc.nist.gov/publications/detail/sp/800-59/
final>.
Becker & Wynn Expires 19 October 2025 [Page 12]
Internet-Draft CNSA2 SSH Profile April 2025
[SP80063] National Institute of Standards and Technology, "Digital
Idenity Guidelines", 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
Alison Becker
National Security Agency
Email: aebecke@uwe.nsa.gov
Casey Wynn
National Security Agency
Email: cwwynn@uwe.nsa.gov
Becker & Wynn Expires 19 October 2025 [Page 13]