rfc9212.original   rfc9212.txt 
Network Working Group N. Gajcowski Independent Submission N. Gajcowski
Internet-Draft M. Jenkins Request for Comments: 9212 M. Jenkins
Intended status: Informational NSA Category: Informational NSA
Expires: 18 July 2022 14 January 2022 ISSN: 2070-1721 March 2022
Commercial National Security Algorithm (CNSA) Suite Cryptography for Commercial National Security Algorithm (CNSA) Suite Cryptography for
Secure Shell (SSH) Secure Shell (SSH)
draft-gajcowski-cnsa-ssh-profile-07
Abstract Abstract
The United States Government has published the NSA Commercial The United States Government has published the National Security
National Security Algorithm (CNSA) Suite, which defines cryptographic Agency (NSA) Commercial National Security Algorithm (CNSA) Suite,
algorithm policy for national security applications. This document which defines cryptographic algorithm policy for national security
specifies the conventions for using the United States National applications. This document specifies the conventions for using the
Security Agency's CNSA Suite algorithms with the Secure Shell United States National Security Agency's CNSA Suite algorithms with
Transport Layer Protocol and the Secure Shell Authentication the Secure Shell Transport Layer Protocol and the Secure Shell
Protocol. It applies to the capabilities, configuration, and Authentication Protocol. It applies to the capabilities,
operation of all components of US National Security Systems that configuration, and operation of all components of US National
employ SSH. US National Security Systems are described in NIST Security Systems (described in NIST Special Publication 800-59) that
Special Publication 800-59. It is also appropriate for all other US employ Secure Shell (SSH). This document is also appropriate for all
Government systems that process high-value information. It is made other US Government systems that process high-value information. It
publicly available for use by developers and operators of these and is made publicly available for use by developers and operators of
any other system deployments. these and any other system deployments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 18 July 2022. 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 Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. The Commercial National Security Algorithm Suite . . . . . . 3 3. The Commercial National Security Algorithm Suite
4. CNSA and Secure Shell . . . . . . . . . . . . . . . . . . . . 3 4. CNSA and Secure Shell
5. Security Mechanism Negotiation and Initialization . . . . . . 5 5. Security Mechanism Negotiation and Initialization
6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Key Exchange
6.1. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . 6 6.1. ECDH Key Exchange
6.2. DH Key Exchange . . . . . . . . . . . . . . . . . . . . . 6 6.2. DH Key Exchange
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7 7. Authentication
7.1. Server Authentication . . . . . . . . . . . . . . . . . . 7 7.1. Server Authentication
7.2. User Authentication . . . . . . . . . . . . . . . . . . . 7 7.2. User Authentication
8. Confidentiality and Data Integrity of SSH Binary Packets . . 8 8. Confidentiality and Data Integrity of SSH Binary Packets
8.1. Galois/Counter Mode . . . . . . . . . . . . . . . . . . . 8 8.1. Galois/Counter Mode
8.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 9 8.2. Data Integrity
9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Rekeying
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
This document specifies conventions for using the United States This document specifies conventions for using the United States
National Security Agency's CNSA Suite algorithms [CNSA] with Secure National Security Agency's CNSA Suite algorithms [CNSA] with the
Shell Transport Layer Protocol [RFC4253] and the Secure Shell Secure Shell Transport Layer Protocol [RFC4253] and the Secure Shell
Authentication Protocol [RFC4252]. It applies to the capabilities, Authentication Protocol [RFC4252]. It applies to the capabilities,
configuration, and operation of all components of US National configuration, and operation of all components of US National
Security Systems that employ SSH. US National Security Systems are Security Systems (described in NIST Special Publication 800-59
described in NIST Special Publication 800-59 [SP80059]. It is also [SP80059]) that employ SSH. This document is also appropriate for
appropriate for all other US Government systems that process high- all other US Government systems that process high-value information.
value information. It is made publicly available for use by It is made publicly available for use by developers and operators of
developers and operators of these and any other system deployments. these and any other system deployments.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. The Commercial National Security Algorithm Suite 3. The Commercial National Security Algorithm Suite
The National Security Agency (NSA) profiles commercial cryptographic The NSA profiles commercial cryptographic algorithms and protocols as
algorithms and protocols as part of its mission to support secure, part of its mission to support secure, interoperable communications
interoperable communications for US Government National Security for US Government National Security Systems. To this end, it
Systems. To this end, it publishes guidance both to assist with the publishes guidance both to assist with the US Government's transition
US Government transition to new algorithms, and to provide vendors - to new algorithms and to provide vendors -- and the Internet
and the Internet community in general - with information concerning community in general -- with information concerning their proper use
their proper use and configuration. and configuration.
Recently, cryptographic transition plans have become overshadowed by Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically-relevant the prospect of the development of a cryptographically relevant
quantum computer. NSA has established the Commercial National quantum computer. The NSA has established the Commercial National
Security Algorithm (CNSA) Suite to provide vendors and IT users near- Security Algorithm (CNSA) Suite to provide vendors and IT users near-
term flexibility in meeting their information assurance term flexibility in meeting their information assurance
interoperability requirements using current cryptography. The interoperability requirements using current cryptography. The
purpose behind this flexibility is to avoid vendors and customers purpose behind this flexibility is to avoid vendors and customers
making two major transitions (i.e. to elliptic curve cryptography, making two major transitions (i.e., to elliptic curve cryptography
and then to post-quantum cryptography) in a relatively short and then to post-quantum cryptography) in a relatively short
timeframe, as we anticipate a need to shift to quantum-resistant timeframe, as we anticipate a need to shift to quantum-resistant
cryptography in the near future. cryptography in the near future.
NSA is authoring a set of RFCs, including this one, to provide The NSA is authoring a set of RFCs, including this one, to provide
updated guidance concerning the use of certain commonly available updated guidance concerning the use of certain commonly available
commercial algorithms in IETF protocols. These RFCs can be used in commercial algorithms in IETF protocols. These RFCs can be used in
conjunction with other RFCs and cryptographic guidance (e.g., NIST conjunction with other RFCs and cryptographic guidance (e.g., NIST
Special Publications) to properly protect Internet traffic and data- Special Publications) to properly protect Internet traffic and data-
at-rest for US Government National Security Systems. at-rest for US Government National Security Systems.
4. CNSA and Secure Shell 4. CNSA and Secure Shell
Several RFCs have documented how each of the CNSA components are to Several RFCs have documented how each of the CNSA components are to
be integrated into Secure Shell (SSH): be integrated into Secure Shell (SSH):
kex algorithms kex algorithms:
ecdh-sha2-nistp384 [RFC5656] * ecdh-sha2-nistp384 [RFC5656]
diffie-hellman-group15-sha512 [RFC8268] * diffie-hellman-group15-sha512 [RFC8268]
diffie-hellman-group16-sha512 [RFC8268]
public key algorithms * diffie-hellman-group16-sha512 [RFC8268]
ecdsa-sha2-nistp384 [RFC5656] public key algorithms:
rsa-sha2-512 [RFC8332] * ecdsa-sha2-nistp384 [RFC5656]
encryption algorithms (both client_to_server and server_to_client) * rsa-sha2-512 [RFC8332]
AEAD_AES_256_GCM [RFC5647] encryption algorithms (both client_to_server and server_to_client):
MAC algorithms (both client_to_server and server_to_client) * AEAD_AES_256_GCM [RFC5647]
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 While the approved CNSA hash function for all purposes is SHA-384, as
defined in [FIPS180], commercial products are more likely to defined in [FIPS180], commercial products are more likely to
incorporate the SHA-512 (sha2-512) based kex algorithms and public incorporate the kex algorithms and public key algorithms based on
key algorithms defined in [RFC8268] and [RFC8332]. Therefore, the SHA-512 (sha2-512), which are defined in [RFC8268] and [RFC8332].
SHA-384 based kex and public key algorithms SHOULD be used; SHA-512 Therefore, the SHA-384-based kex and public key algorithms SHOULD be
based algorithms MAY be used. Any hash algorithm other than SHA-384 used; SHA-512-based algorithms MAY be used. Any hash algorithm other
or SHA-512 MUST NOT be used. than SHA-384 or SHA-512 MUST NOT be used.
Use of AES GCM shall meet the requirements set forth in SP 800-38D Use of the Advanced Encryption Standard in Galois/Counter Mode (AES-
with the additional requirements that all 16 octets of the GCM) shall meet the requirements set forth in [SP800-38D], with the
authentication tag MUST be used as the SSH data integrity value and additional requirements that all 16 octets of the authentication tag
that AES is used with a 256-bit key. Use of AES-GCM in SSH should be MUST be used as the SSH data integrity value and that AES is used
done as described in RFC 5647, with the exception that AES-GCM need with a 256-bit key. Use of AES-GCM in SSH should be done as
not be listed as the MAC algorithm when its use is implicit (such as described in [RFC5647], with the exception that AES-GCM need not be
done in aes256-gcm@openssh.com). In addition, RFC 5647 failed to listed as the MAC algorithm when its use is implicit (such as done in
specify that the AES GCM invocation counter is incremented mod 2^64. aes256-gcm@openssh.com). In addition, [RFC5647] fails to specify
CNSA implementations MUST ensure the counter never repeats and is that the AES-GCM invocation counter is incremented mod 2^64. CNSA
properly incremented after processing a binary packet: implementations MUST ensure the counter never repeats and is properly
invocation_counter = invocation_counter + 1 mod 2^64. 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 The purpose of this document is to draw upon all of these documents
to provide guidance for CNSA compliant implementations of Secure to provide guidance for CNSA-compliant implementations of Secure
Shell. Algorithms specified in this document may be different to Shell. Algorithms specified in this document may be different from
mandatory-to-implement algorithms; in that case the latter will be mandatory-to-implement algorithms; where this occurs, the latter will
present but not used. Note that while compliant Secure Shell be present but not used. Note that, while compliant Secure Shell
implementations MUST follow the guidance in this document, that implementations MUST follow the guidance in this document, that
requirement does not in and of itself imply that a given requirement does not in and of itself imply that a given
implementation of Secure Shell is suitable for use national security implementation of Secure Shell is suitable for use national security
systems. An implementation must be validated by the appropriate systems. An implementation must be validated by the appropriate
authority before such usage is permitted. authority before such usage is permitted.
5. Security Mechanism Negotiation and Initialization 5. Security Mechanism Negotiation and Initialization
As described in Section 7.1 of [RFC4253], the exchange of As described in Section 7.1 of [RFC4253], the exchange of
SSH_MSG_KEXINIT between the server and the client establishes which SSH_MSG_KEXINIT between the server and the client establishes which
key agreement algorithm, MAC algorithm, host key algorithm (server key agreement algorithm, MAC algorithm, host key algorithm (server
authentication algorithm), and encryption algorithm are to be used. authentication algorithm), and encryption algorithm are to be used.
This section specifies the use of CNSA components in the Secure Shell This section specifies the use of CNSA components in the Secure Shell
algorithm negotiation, key agreement, server authentication, and user algorithm negotiation, key agreement, server authentication, and user
authentication. authentication.
The choice of all but the user authentication methods are determined The choice of all but the user authentication methods is determined
by the exchange of SSH_MSG_KEXINIT between the client and the server. 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 The kex_algorithms name-list is used to negotiate a single key
agreement algorithm between the server and client in accordance with agreement algorithm between the server and client in accordance with
the guidance given in Section 2. While ID.ietf-curdle-ssh-kex-sha2 the guidance given in Section 4. While [RFC9142] establishes general
establishes general guidance on the capabilities of SSH guidance on the capabilities of SSH implementations and requires
implementations and requires support for "diffie-hellman- support for "diffie-hellman-group14-sha256", it MUST NOT be used.
group14-sha256", it MUST NOT be used. The result MUST be one of the The result MUST be one of the following kex_algorithms, or the
following kex_algorithms or the connection MUST be terminated. connection MUST be terminated:
ecdh-sha2-nistp384 [RFC5656] * ecdh-sha2-nistp384 [RFC5656]
diffie-hellman-group15-sha512 [RFC8268] * diffie-hellman-group15-sha512 [RFC8268]
diffie-hellman-group16-sha512 [RFC8268] * diffie-hellman-group16-sha512 [RFC8268]
One of the following sets MUST be used for the encryption_algorithms One of the following sets MUST be used for the encryption_algorithms
and mac_algorithms name-lists. Either set MAY be used for each and mac_algorithms name-lists. Either set MAY be used for each
direction (i.e. client_to_server, server_to_client) but the result direction (i.e., client_to_server or server_to_client), but the
must be the same (i.e. use of AEAD_AES_256_GCM). This option MUST be result must be the same (i.e., use of AEAD_AES_256_GCM).
used.
encryption_algorithm_name_list := { AEAD_AES_256_GCM } encryption_algorithm_name_list := { AEAD_AES_256_GCM }
mac_algorithm_name_list := { AEAD_AES_256_GCM } mac_algorithm_name_list := { AEAD_AES_256_GCM }
or or
encryption_algorithm_name_list := { aes256-gcm@openssh.com } encryption_algorithm_name_list := { aes256-gcm@openssh.com }
mac_algorithm_name_list := {} mac_algorithm_name_list := {}
One of the following public key algorithms MUST be used. One of the following public key algorithms MUST be used:
rsa-sha2-512 [RFC8332] * rsa-sha2-512 [RFC8332]
ecdsa-sha2-nistp384 [RFC5656] * ecdsa-sha2-nistp384 [RFC5656]
The procedures for applying the negotiated algorithms are given in The procedures for applying the negotiated algorithms are given in
the following sections. the following sections.
6. Key Exchange 6. Key Exchange
The key exchange to be used is determined by the name-lists exchanged The key exchange to be used is determined by the name-lists exchanged
in the SSH_MSG_KEXINIT packets as described above. Either elliptic in the SSH_MSG_KEXINIT packets, as described above. Either Elliptic
curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) MUST be used to Curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) MUST be used to
establish a shared secret value between the client and the server. establish a shared secret value between the client and the server.
A compliant system MUST NOT allow the reuse of ephemeral/exchange A compliant system MUST NOT allow the reuse of ephemeral/exchange
values in a key exchange algorithm due to security concerns related values in a key exchange algorithm due to security concerns related
to this practice. Section 5.6.3.3 of [SP80056A] states that an to this practice. Section 5.6.3.3 of [SP80056A] states that an
ephemeral private key must be used in exactly one key establishment ephemeral private key shall be used in exactly one key establishment
transaction and must be destroyed (zeroized) as soon as possible. transaction and shall be destroyed (zeroized) as soon as possible.
Section 5.8 of [SP80056A] states that such shared secrets must be Section 5.8 of [SP80056A] states that such shared secrets shall be
destroyed (zeroized) immediately after its use. CNSA compliant destroyed (zeroized) immediately after its use. CNSA-compliant
systems MUST follow these mandates. systems MUST follow these mandates.
6.1. ECDH Key Exchange 6.1. ECDH Key Exchange
The key exchange begins with the SSH_MSG_KEXECDH_INIT message which The key exchange begins with the SSH_MSG_KEXECDH_INIT message that
contains the client's ephemeral public key used to generate a shared contains the client's ephemeral public key used to generate a shared
secret value. secret value.
The server responds to a SSH_MSG_KEXECDH_INIT message with a The server responds to an SSH_MSG_KEXECDH_INIT message with an
SSH_MSG_KEXECDH_REPLY message which contains the server's ephemeral SSH_MSG_KEXECDH_REPLY message that contains the server's ephemeral
public key, the server's public host key, and a signature of the public key, the server's public host key, and a signature of the
exchange hash value formed from the newly established shared secret exchange hash value formed from the newly established shared secret
value. The kex algorithm MUST be ecdh-sha2-nistp384, and the public value. The kex algorithm MUST be ecdh-sha2-nistp384, and the public
key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512. key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512.
6.2. DH Key Exchange 6.2. DH Key Exchange
The key exchange begins with the SSH_MSG_KEXDH_INIT message which The key exchange begins with the SSH_MSG_KEXDH_INIT message that
contains the client's DH exchange value used to generate a shared contains the client's DH exchange value used to generate a shared
secret value. secret value.
The server responds to a SSH_MSG_KEXDH_INIT message with a The server responds to an SSH_MSG_KEXDH_INIT message with an
SSH_MSG_KEXDH_REPLY message. The SSH_MSG_KEXDH_REPLY contains the SSH_MSG_KEXDH_REPLY message that contains the server's DH exchange
server's DH exchange value, the server's public host key, and a value, the server's public host key, and a signature of the exchange
signature of the exchange hash value formed from the newly hash value formed from the newly established shared secret value.
established shared secret value. The kex algorithm MUST be one of The kex algorithm MUST be one of diffie-hellman-group15-sha512 or
diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and diffie-hellman-group16-sha512, and the public key algorithm MUST be
the public key algorithm MUST be either ecdsa-sha2-nistp384 or rsa- either ecdsa-sha2-nistp384 or rsa-sha2-512.
sha2-512.
7. Authentication 7. Authentication
7.1. Server Authentication 7.1. Server Authentication
A signature on the exchange hash value derived from the newly A signature on the exchange hash value derived from the newly
established shared secret value is used to authenticate the server to established shared secret value is used to authenticate the server to
the client. Servers MUST be authenticated using digital signatures. the client. Servers MUST be authenticated using digital signatures.
The public key algorithm implemented MUST be ecdsa-sha2-nistp384 or 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 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 in size; clients MUST NOT accept RSA signatures from a public key
modulus of any other size. modulus of any other size.
The following public key algorithms MUST be used: The following public key algorithms MUST be used:
ecdsa-sha2-nistp384 [RFC5656] * ecdsa-sha2-nistp384 [RFC5656]
rsa-sha2-512 [RFC8332] * rsa-sha2-512 [RFC8332]
The client MUST verify that the presented key is a valid The client MUST verify that the presented key is a valid
authenticator for the server before verifying the server signature. authenticator for the server before verifying the server signature.
If possible, validation SHOULD be done using certificates. If possible, validation SHOULD be done using certificates.
Otherwise, the client MUST validate the presented public key through Otherwise, the client MUST validate the presented public key through
some other secure, possibly off-line mechanism. Implementations MUST some other secure, possibly off-line mechanism. Implementations MUST
NOT employ a trust on first use (TOFU) security model where a client NOT employ a "Trust on First Use (TOFU)" security model where a
accepts the first public host key presented to it from a not yet client accepts the first public host key presented to it from a not-
verified server. Use of a TOFU model would allow an intermediate yet-verified server. Use of a TOFU model would allow an intermediate
adversary to present itself to the client as the server. adversary to present itself to the client as the server.
Where X.509v3 certificates are used, their use MUST comply with Where X.509 v3 Certificates are used, their use MUST comply with
[RFC8603] [RFC8603].
7.2. User Authentication 7.2. User Authentication
The Secure Shell Transport Layer Protocol authenticates the server to 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 host but does not authenticate the user (or the user's host) to
the server. All users MUST be authenticated, MUST follow [RFC4252], the server. All users MUST be authenticated, MUST follow [RFC4252],
and SHOULD be authenticated using a public key method. Users MAY and SHOULD be authenticated using a public key method. Users MAY
authenticate using passwords. Other methods of authentication MUST authenticate using passwords. Other methods of authentication MUST
not be used, including "none". not be used, including "none".
When authenticating with public key, the following public key When authenticating with public key, the following public key
algorithms MUST be used: algorithms MUST be used:
ecdsa-sha2-nistp384 [RFC5656] * ecdsa-sha2-nistp384 [RFC5656]
rsa-sha2-512 [RFC8332] * rsa-sha2-512 [RFC8332]
The server MUST verify that the public key is a valid authenticator The server MUST verify that the public key is a valid authenticator
for the user. If possible, validation SHOULD be done using for the user. If possible, validation SHOULD be done using
certificates. Otherwise, the server must validate the public key certificates. Otherwise, the server must validate the public key
through another secure, possibly off-line mechanism. through another secure, possibly off-line mechanism.
Where X.509v3 certificates are used, their use MUST comply with Where X.509 v3 Certificates are used, their use MUST comply with
[RFC8603]. [RFC8603].
If authenticating with RSA, the client's public key modulus MUST be 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 3072 or 4096 bits in size, and the server MUST NOT accept signatures
from an RSA public key modulus of any other size. from an RSA public key modulus of any other size.
To facilitate client authentication with RSA using SHA-512, clients To facilitate client authentication with RSA using SHA-512, clients
and servers SHOULD implement the server-sig-algs extension as and servers SHOULD implement the server-sig-algs extension, as
specified in [RFC8308]. In that case, in the SSH_MSG_KEXINIT, the specified in [RFC8308]. In that case, in the SSH_MSG_KEXINIT, the
client SHALL include the indicator ext-info-c to the kex_algorithms 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 field, and the server SHOULD respond with an SSH_MSG_EXT_INFO message
containing the server-sig-algs extension. The server MUST list only containing the server-sig-algs extension. The server MUST list only
ecdsa-sha2-nistp384 and-or rsa-sha2-512 as the acceptable public key ecdsa-sha2-nistp384 and/or rsa-sha2-512 as the acceptable public key
algorithms in this response. algorithms in this response.
If authenticating by passwords, it is essential that passwords have If authenticating by passwords, it is essential that passwords have
sufficient entropy to protect against dictionary attacks. During sufficient entropy to protect against dictionary attacks. During
authentication, the password MUST be protected in the established authentication, the password MUST be protected in the established
encrypted communications channel. Additional guidelines are provided encrypted communications channel. Additional guidelines are provided
in [SP80063]. in [SP80063].
8. Confidentiality and Data Integrity of SSH Binary Packets 8. Confidentiality and Data Integrity of SSH Binary Packets
Secure Shell transfers data between the client and the server using Secure Shell transfers data between the client and the server using
its own binary packet structure. The SSH binary packet structure is its own binary packet structure. The SSH binary packet structure is
independent of any packet structure on the underlying data channel. independent of any packet structure on the underlying data channel.
The contents of each binary packet and portions of the header are The contents of each binary packet and portions of the header are
encrypted, and each packet is authenticated with its own message encrypted, and each packet is authenticated with its own message
authentication code. Use of the Advanced Encryption Standard in authentication code. Use of AES-GCM will both encrypt the packet and
Galois Counter Mode (AES GCM) will both encrypt the packet and form a form a 16-octet authentication tag to ensure data integrity.
16-octet authentication tag to ensure data integrity.
8.1. Galois/Counter Mode 8.1. Galois/Counter Mode
Use of AES GCM in Secure Shell is described in [RFC5647]. CNSA Use of AES-GCM in Secure Shell is described in [RFC5647]. CNSA-
complaint SSH implementations MUST support AES GCM (negotiated as complaint SSH implementations MUST support AES-GCM (negotiated as
AEAD_AES_GCM_256 or aes256-gcm@openssh, see Section 5) to provide AEAD_AES_GCM_256 or aes256-gcm@openssh; see Section 5) to provide
confidentiality and ensure data integrity. No other confidentiality confidentiality and ensure data integrity. No other confidentiality
or data integrity algorithms are permitted. or data integrity algorithms are permitted.
The AES GCM invocation counter is incremented mod 2^64. That is, The AES-GCM invocation counter is incremented mod 2^64. That is,
after processing a binary packet: after processing a binary packet:
invocation_counter = invocation_counter + 1 mod 2^64 invocation_counter = invocation_counter + 1 mod 2^64
The invocation counter MUST NOT repeat a counter value. The invocation counter MUST NOT repeat a counter value.
8.2. Data Integrity 8.2. Data Integrity
As specified in [RFC5647], all 16 octets of the authentication tag As specified in [RFC5647], all 16 octets of the authentication tag
MUST be used as the SSH data integrity value of the SSH binary MUST be used as the SSH data integrity value of the SSH binary
packet. packet.
9. Rekeying 9. Rekeying
Section 9 of [RFC4253] allows either the server or the client to 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 initiate a "key re-exchange ... by sending an SSH_MSG_KEXINIT packet"
to 'change some or all of the (cipher) algorithms during re- and to "change some or all of the [cipher] algorithms during the re-
exchange.' This specification requires the same cipher suite to be exchange". This specification requires the same cipher suite to be
employed when re-keying, that is, the cipher algorithms MUST NOT be employed when rekeying; that is, the cipher algorithms MUST NOT be
changed when a rekey occurs. changed when a rekey occurs.
10. Security Considerations 10. Security Considerations
The security considerations of [RFC4251], [RFC4252], [RFC4253], The security considerations of [RFC4251], [RFC4252], [RFC4253],
[RFC5647], and [RFC5656] apply. [RFC5647], and [RFC5656] apply.
11. IANA Considerations 11. IANA Considerations
No IANA actions are requested. This document has no IANA actions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[CNSA] Committee for National Security Systems, "Use of Public [CNSA] Committee for National Security Systems, "Use of Public
Standards for Secure Information Sharing", CNSSP 15, Standards for Secure Information Sharing", CNSSP 15,
October 2016, October 2016,
<https://www.cnss.gov/CNSS/Issuances/Policies.htm>. <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.
[FIPS180] National Institute of Standards and Technology, "Secure [FIPS180] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", Federal Information Processing Hash Standard (SHS)", FIPS PUB 180-4,
Standard 180-4, August 2015, DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>. <https://doi.org/10.6028/NIST.FIPS.180-4>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>. January 2006, <https://www.rfc-editor.org/info/rfc4251>.
skipping to change at page 11, line 5 skipping to change at line 473
<https://www.rfc-editor.org/info/rfc8332>. <https://www.rfc-editor.org/info/rfc8332>.
[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security
Algorithm (CNSA) Suite Certificate and Certificate Algorithm (CNSA) Suite Certificate and Certificate
Revocation List (CRL) Profile", RFC 8603, Revocation List (CRL) Profile", RFC 8603,
DOI 10.17487/RFC8603, May 2019, DOI 10.17487/RFC8603, May 2019,
<https://www.rfc-editor.org/info/rfc8603>. <https://www.rfc-editor.org/info/rfc8603>.
12.2. Informative References 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, [SP80056A] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special Using Discrete Logarithm Cryptography", Revision 3, NIST
Publication 800-56A, Revision 3, April 2018, Special Publication 800-56A,
DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>. <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
[SP80059] National Institute of Standards and Technology, "Guideline [SP80059] National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National for Identifying an Information System as a National
Security System", Special Publication 800-59 , August Security System", NIST Special Publication 800-59,
2003, <https://doi.org/10.6028/NIST.SP.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 [SP80063] National Institute of Standards and Technology, "Digital
Identity Guidelines", NIST Special Publication 800-63, Identity Guidelines", NIST Special Publication 800-63-3,
Revision 3, June 2017, DOI 10.6028/NIST.SP.800-63-3, June 2017,
<https://doi.org/10.6028/NIST.SP.800-63-3>. <https://doi.org/10.6028/NIST.SP.800-63-3>.
Authors' Addresses Authors' Addresses
Nicholas Gajcowski Nicholas Gajcowski
National Security Agency National Security Agency
Email: nhgajco@uwe.nsa.gov Email: nhgajco@uwe.nsa.gov
Michael Jenkins Michael Jenkins
National Security Agency National Security Agency
Email: mjjenki@cyber.nsa.gov Email: mjjenki@cyber.nsa.gov
 End of changes. 65 change blocks. 
177 lines changed or deleted 186 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/