[要約] RFC 9212は、米国政府が公開したCommercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)に関する規定であり、国家安全保障アプリケーション向けの暗号アルゴリズムポリシーを定義しています。この文書は、米国国家安全保障局のCNSA SuiteアルゴリズムをSecure Shell Transport Layer ProtocolおよびSecure Shell Authentication Protocolで使用するための規則を指定しています。
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)
Secure Shell（SSH）用の商業全国セキュリティアルゴリズム（CNSA）スイート暗号化
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.
米国政府は、国家セキュリティアプリケーションのための暗号化アルゴリズム方針を定義する国家安全保障庁（NSA）商業全国セキュリティアルゴリズム（CNSA）スイートを発表しました。このドキュメントは、安全なシェルトランスポート層プロトコルとセキュアシェル認証プロトコルを使用して、米国国家セキュリティエージェンシーのCNSAスイートアルゴリズムを使用するための規則を指定します。Secure Shell（SSH）を採用した米国国家セキュリティシステムのすべてのコンポーネントの機能、構成、および操作に適用されます。この文書は、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよび他のシステム展開の開発者および事業者による使用には公に利用可能にされています。
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.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。RFC 7841のセクション2を参照してください。
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.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、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.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
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
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.
このドキュメントは、Secure Shell Transport Layer Protocol [RFC4253]とSecure Shell認証プロトコル[RFC4252]を使用して、米国国家セキュリティエージェンシーのCNSA Suite Algorithms [CNSA]を使用するための規則を指定します。SSHを使用する米国国家セキュリティシステムのすべてのコンポーネントの機能、構成、および操作に適用されます。この文書は、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよび他のシステム展開の開発者および事業者による使用には公に利用可能にされています。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
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.
NSAプロファイルは、米国政府の国家セキュリティシステムのための安全な相互運用可能なコミュニケーションを支援するためのその使命の一環として、市販の暗号化アルゴリズムとプロトコルをプロファイルします。この目的のために、米国政府の新しいアルゴリズムへの移行を支援し、ベンダーとインターネットコミュニティを一般的に提供することを支援することができます。
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.
最近、暗号的に関連する量子コンピュータの開発の見通しによって暗号化された遷移計画が隠されてきた。NSAは、現在の暗号化を使用した情報保証の相互運用性要件を満たす際に、ベンダーとITユーザーを提供するための市販の国家セキュリティアルゴリズム（CNSA）スイートを設立しました。この柔軟性の背後にある目的は、ベンダーや顧客が比較的短い時間枠で2つの大きな遷移を行う（すなわち、楕円曲線暗号化、次に楕円曲線暗号化、次に量子暗号化に）、比較的短い時間枠で、近い将来。
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.
NSAは、これを含むRFCのセットを作成しています。これらのRFCは、米国政府の国家セキュリティシステムにとってインターネットトラフィックとデータ同士のデータを適切に保護するために、他のRFCおよび暗号案内（例えば、NIST特別刊行物）と組み合わせて使用することができる。
Several RFCs have documented how each of the CNSA components are to be integrated into Secure Shell (SSH):
いくつかのRFCは、各CNSAコンポーネントをSecure Shell（SSH）にどのように統合されるかを文書化しています。
kex algorithms:
KEXアルゴリズム：
* 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]
public key algorithms:
公開鍵アルゴリズム：
* ecdsa-sha2-nistp384 [RFC5656]
* ECDSA-SHA2-NISTP384 [RFC5656]
* rsa-sha2-512 [RFC8332]
* RSA-SHA2-512 [RFC8332]
encryption algorithms (both client_to_server and server_to_client):
暗号化アルゴリズム（client_to_serverと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):
メッセージ認証コード（MAC）アルゴリズム（Client_To_ServerとServer_TO_Clientの両方）：
* AEAD_AES_256_GCM [RFC5647]
* 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.
[FIPS180]で定義されているように、すべての目的のための承認されたCNSAハッシュ関数はSHA-384であるが、商用製品はSHA - 512（SHA2-512）に基づいてKEXアルゴリズムおよび公開鍵アルゴリズムを組み込む可能性が高い。[RFC8268]と[RFC8332]。したがって、SHA-384ベースのKEXおよび公開鍵アルゴリズムを使用する必要があります。SHA-512ベースのアルゴリズムを使用することができます。SHA-384またはSHA-512以外のハッシュアルゴリズムを使用してはいけません。
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:
Galois / Counter Mode（AES-GCM）における高度な暗号化規格の使用は[SP800-38D]に記載されている要件を満たしており、認証タグの16個の16オクテットをSSHデータの整合性値として使用する必要があります。そして、そのAESは256ビットキーで使用されます。SSHでのAES-GCMを使用すると、[RFC5647]で説明されているように、AES-GCMがその使用が暗黙的な場合（aes256-gcm@openssh.comなど）MACアルゴリズムとしてリストされる必要があります。。また、[RFC5647]は、AES-GCM呼び出しカウンタがインクリメントされたMOD 2 ^ 64の増分であることを指定できません。CNSA実装は、カウンタが繰り返さないことを確認し、バイナリパケットを処理した後に正しくインクリメントされている必要があります。
invocation_counter = invocation_counter + 1 mod 2^64.
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.
この文書の目的は、Secure ShellのCNSA準拠の実装のためのガイダンスを提供するためのこれらのすべての文書を描くことです。この文書で指定されたアルゴリズムは、必須のアルゴリズムとは異なる場合があります。これが発生する場合、後者は存在しますが使用されません。なお、準拠のセキュアシェルの実装はこの文書のガイダンスに従わなければならないが、その要件はそれ自体ではなく、確保されたシェルの実装が全国セキュリティシステムの使用に適していることを意味する。そのような使用が許可される前に、実装は適切な権限によって検証されなければなりません。
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.
[RFC4253]のセクション7.1で説明されているように、サーバーとクライアントの間のSSH_MSG_KEXINITの交換は、どのキー契約アルゴリズム、MACアルゴリズム、ホストキーアルゴリズム（サーバー認証アルゴリズム）、および暗号化アルゴリズムを使用するかを確立します。このセクションでは、セキュアシェルアルゴリズムのネゴシエーション、キー契約、サーバー認証、およびユーザー認証におけるCNSAコンポーネントの使用を指定します。
The choice of all but the user authentication methods is determined by the exchange of SSH_MSG_KEXINIT between the client and the server.
ユーザー認証方法をすべて選択することは、クライアントとサーバー間のSSH_MSG_KEXINITの交換によって決まります。
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:
kex_algorithms name-listは、セクション4に記載のガイダンスに従ってサーバーとクライアント間の単一のキー合意アルゴリズムをネゴシエートするために使用されます。-group14-sha256 "、使用してはいけません。結果は次の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]
* 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_algorithmsおよびmac_algorithms name-listに使用する必要があります。各方向（すなわち、CLIST_TO_SERVERまたはSERVER_TO_CLIENT）に設定することができるが、結果は同じでなければならない（すなわち、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]
* RSA-SHA2-512 [RFC8332]
* ecdsa-sha2-nistp384 [RFC5656]
* ECDSA-SHA2-NISTP384 [RFC5656]
The procedures for applying the negotiated algorithms are given in the following sections.
交渉されたアルゴリズムを適用するための手順は、以下のセクションで示されています。
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.
使用されるべき鍵交換は、上述のように、SSH_MSG_KEXINITパケットで交換された名前リストによって決まります。楕円曲線Diffie-Hellman（ECDH）またはDIFFIE-HELLMAN（DH）を使用して、クライアントとサーバー間の共有秘密値を確立する必要があります。
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.
準拠システムは、この慣習に関連するセキュリティ上の懸念のために、鍵交換アルゴリズムでの一時的/交換値の再利用を許可してはなりません。[SP80056A]のセクション5.6.3.3は、一時的な秘密鍵が正確に1つの重要な確立トランザクションで使用され、できるだけ早く破壊される（ゼロ化）するものとします。[SP80056A]のセクション5.8は、そのような共有秘密がその使用の直後に破壊される（ゼロ化）しなければならないと述べています。CNSA準拠のシステムはこれらの命令に従う必要があります。
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.
鍵交換は、共有秘密値を生成するために使用されるクライアントの一時公開鍵を含むSSH_MSG_KEXECDH_INITメッセージで始まります。
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.
サーバーは、サーバーの一時公開鍵、サーバーの公開鍵、および新しく確立された共有秘密値から形成されたExchangeハッシュ値の署名を含むSSH_MSG_KEXECDH_INITメッセージに応答します。KEXアルゴリズムはECDH-SHA2-NISTP384でなければならず、公開鍵アルゴリズムはECDSA-SHA2-NISTP384またはRSA-SHA2-512のいずれかでなければなりません。
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.
鍵交換は、共有秘密値を生成するために使用されるクライアントのDH交換値を含むSSH_MSG_KEXDH_INITメッセージで始まります。
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.
サーバーは、サーバーのDH交換値、サーバーの公開鍵キー、および新しく確立された共有秘密値から形成されたExchangeハッシュ値の署名を含むSSH_MSG_KEXDH_INITメッセージに応答します。KEXアルゴリズムは、Diffie-Hellman-Group15-SHA512またはDiffie-Hellman-Group16-SHA512の1つでなければならず、公開鍵アルゴリズムはECDSA-SHA2-NISTP384またはRSA-SHA2-512のいずれかでなければなりません。
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.
新しく確立された共有秘密値から派生したExchange Hash値のシグネチャは、クライアントへのサーバーを認証するために使用されます。サーバーはデジタル署名を使用して認証されなければなりません。実装された公開鍵アルゴリズムは、ECDSA-SHA2-NISTP384またはRSA-SHA2-512でなければなりません。RSA公開鍵モジュラスは、3072または4096ビットのサイズでなければなりません。クライアントは、他のサイズの公開鍵モジュラスからRSAシグニチャを受け入れないでください。
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 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.
クライアントは、サーバーの署名を検証する前に、提示されたキーがサーバーの有効な認証者であることを確認する必要があります。可能であれば、検証は証明書を使用して実行する必要があります。それ以外の場合、クライアントは他の安全な、場合によってはオフラインのメカニズムを介して提示された公開鍵を検証する必要があります。実装は、クライアントがそれに提示されていないサーバーからそれに提示された最初の公開ホスト鍵を受け入れるセキュリティモデルを「最初の使用（TOFU）」セキュリティモデルを使用してはいけません。豆腐モデルを使用すると、中間の敵対者がサーバーとしてクライアントに自分自身を提示することができます。
Where X.509 v3 Certificates are used, their use MUST comply with [RFC8603].
X.509 V3証明書が使用されている場合、それらの使用は[RFC8603]に準拠しなければなりません。
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".
セキュアシェルトランスポート層プロトコルは、サーバをホストに認証しますが、ユーザー（またはユーザーのホスト）をサーバーに認証しません。すべてのユーザーは認証されなければならず、[RFC4252]に従う必要があり、公開鍵メソッドを使用して認証されるべきです。ユーザーはパスワードを使用して認証できます。「なし」を含めて、他の認証方法を使用してはいけません。
When authenticating with public key, 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 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].
X.509 V3証明書が使用されている場合、それらの使用は[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.
RSAで認証されている場合、クライアントの公開鍵モジュラスはサイズが3072または4096ビットでなければならず、サーバーは他のサイズのRSA公開鍵モジュラスから署名を受け付けてはなりません。
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.
SHA-512を使用してRSAを使用したクライアント認証を容易にするために、[RFC8308]で指定されているように、クライアントとサーバーはサーバー-SIG-ALGS拡張機能を実装する必要があります。その場合、SSH_MSG_KEXINITでは、クライアントはex_algorithmsフィールドにインジケータext-info-cを含め、サーバーはサーバー-SIG-ALGS拡張子を含むSSH_MSG_EXT_INFOメッセージで応答する必要があります。この応答の許容される公開鍵アルゴリズムとして、サーバーはECDSA-SHA2-NISTP384および/またはRSA-SHA2-512のみをリストする必要があります。
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].
パスワードで認証されている場合は、パスワードに辞書攻撃から保護するのに十分なエントロピーがあることが不可欠です。認証中、パスワードは確立された暗号化通信チャネルで保護されている必要があります。[SP80063]に追加のガイドラインがあります。
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.
セキュアシェルは、独自のバイナリパケット構造を使用してクライアントとサーバー間でデータを転送します。SSHバイナリパケット構造は、基礎となるデータチャネル上のパケット構造とは無関係です。各バイナリパケットの内容とヘッダの部分は暗号化され、各パケットはそれ自身のメッセージ認証コードで認証されます。AES-GCMの使用は両方ともパケットを暗号化し、データの整合性を確保するために16オクテット認証タグを形成します。
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.
セキュアシェルにおけるAES-GCMの使用は[RFC5647]に記載されています。CNSA対応のSSHの実装は、機密性を提供し、データの整合性を確保するために、AES-GCM（aead_aes_gcm_256またはAES256-gcm @ opensshと交渉する必要があります。セクション5を参照）。他の機密性やデータ整合性アルゴリズムは許可されていません。
The AES-GCM invocation counter is incremented mod 2^64. That is, after processing a binary packet:
AES-GCM呼び出しカウンタはインクリメントされたMOD 2 ^ 64です。つまり、バイナリパケットを処理した後です。
invocation_counter = invocation_counter + 1 mod 2^64
The invocation counter MUST NOT repeat a counter value.
呼び出しカウンタはカウンタ値を繰り返してはいけません。
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.
[RFC5647]で指定されているように、認証タグの16オクテットをすべてSSHバイナリパケットのSSHデータ整合性値として使用する必要があります。
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.
[RFC4253]のセクション9では、サーバーまたはクライアントのいずれかが「SSH_MSG_KEXIXINITパケットを送信することで鍵再交換...」を開始し、「再交換中の[暗号化アルゴリズムの一部または全部を変更することができます。この仕様では、REKEYSに同じ暗号スイートを採用する必要があります。つまり、リークが発生したときに暗号アルゴリズムを変更しないでください。
The security considerations of [RFC4251], [RFC4252], [RFC4253], [RFC5647], and [RFC5656] apply.
[RFC4251]、[RFC4252]、[RFC4253]、[RFC5647]、[RFC5656]のセキュリティ上の考慮事項。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>.
[CNSA]国家セキュリティシステムの委員会、「安全な情報共有のための公開基準の使用」、CNSSP 15、2016年10月15日、<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>.
[FIPS180]国立標準技術研究所、「セキュアハッシュスタンダード（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<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>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC4251] Ylonen、T.およびC. Lonvick、Ed。、「Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<https：//www.rfc-editor.org/情報/ 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>.
[RFC4252] Ylonen、T.およびC. Lonvick、Ed。、「セキュアシェル（SSH）認証プロトコル」、RFC 4252、DOI 10.17487 / RFC4252、2006年1月、<https：//www.rfc-editor.org/情報/ 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>.
[RFC4253] Ylonen、T.およびC. Lonvick、Ed。、「セキュアシェル（SSH）トランスポート層プロトコル」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<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>.
[RFC5647] IGOE、K.およびJ. Solinas、RFC 5647、DOI 10.17487 / RFC5647、2009年8月、<https：//www.rfc-editor.org/情報/ 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>.
[RFC5656] Stebila、D.およびJ.Green、「セキュアシェルトランスポート層における楕円曲線アルゴリズム統合」、RFC 5656、DOI 10.17487 / RFC5656、2009年12月、<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>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8268] Baushke、M。、「Secure Shell（SSH）の鍵交換（KEX）グループ、RFC 8268、DOI 10.17487 / RFC8268、2017年12月、<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>.
[RFC8308] Bier、D.、「Secure Shell（SSH）プロトコル（SSH）プロトコルの拡張ネゴシエーション」、RFC 8308、DOI 10.17487 / RFC8308、2018年3月、<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>.
[RFC8332] Bier、D.、「SHA-256とSHA-512のRSAキーの使用」、RFC 8332、DOI 10.17487 / RFC8332、2018年3月、<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>.
[RFC8603] Jenkins、M.およびL.Zieglar、「商業全国セキュリティアルゴリズム（CNSA）スイート証明書および証明書失効リスト（CRL）プロファイル」、RFC 8603、DOI 10.17487 / RFC8603、2019年5月、<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>.
[RFC9142] Baushke、M.、「Secure Shell（SSH）」、RFC 9142、DOI 10.17487 / RFC9142、DOI 10.17487 / RFC9142、<https://ww.rfc-editor.org/情報/ 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>.
[SP800-38D]国立標準技術研究所「ブロック暗号化モードのための推奨：ガロア/カウンターモード（GCM）およびGMAC」、NIST特別出版物800-38D、DOI 10.6028 / NIST.SP.800-38D、2007年11月、<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>.
[SP80056A]国立標準化学研究所、「離散対数暗号化を用いたペアワイズ鍵確立方式の推薦」、改訂3、NIST特別出版物800-56A、DOI 10.6028 / NIST.SP.800-56AR3、2018年4月、<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>.
[SP80059]国立標準技術研究所、「国家安全保障システムとしての情報システムを特定するためのガイドライン」、NIST特別出版物800-59、DOI 10.6028 / NIST.SP.800-59、2003年8月、<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>.
[SP80063]国立標準技術研究所、「デジタルアイデンティティーガイドライン」、NIST特別出版物800-63-3、DOI 10.6028 / NIST.SP.800-63-3、2017年6月、<https：//doi.org/10.6028 / NIST.SP.800-63-3>。
Authors' Addresses
著者の住所
Nicholas Gajcowski National Security Agency Email: nhgajco@uwe.nsa.gov
Nicholas Gajcowski National Security Agency Eメール：nhgajco@uwe.nsa.gov.
Michael Jenkins National Security Agency Email: mjjenki@cyber.nsa.gov
Michael Jenkins National Security Agency Eメール：mjjenki@cyber.nsa.gov.