[要約] RFC 9142は、セキュアシェル（SSH）のためのキー交換（KEX）方法の更新と推奨事項に関する文書です。この文書の目的は、SSH接続のセキュリティを強化するための新しいキー交換アルゴリズムの導入と既存のものの改善を提案することです。主に、セキュアな通信を必要とするネットワーク管理者やシステム管理者が利用場面として想定されます。
Internet Engineering Task Force (IETF) M. Baushke
Request for Comments: 9142 January 2022
Updates: 4250, 4253, 4432, 4462
Category: Standards Track
ISSN: 2070-1721
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
鍵交換（KEX）メソッドの更新と安全なシェルのための推奨事項（SSH）
Abstract
概要
This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462.
このドキュメントは、Secure Shell（SSH）プロトコルで使用するための推奨されるキー交換方法のセットを更新して、強化されたセキュリティのための進化する必要性を満たしています。RFCS 4250,4253,4432、および4462を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、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/rfc9142.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9142で取得できます。
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. 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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Overview and Rationale
1.1. Selecting an Appropriate Hashing Algorithm
1.2. Selecting an Appropriate Public Key Algorithm
1.2.1. Elliptic Curve Cryptography (ECC)
1.2.2. Finite Field Cryptography (FFC)
1.2.3. Integer Factorization Cryptography (IFC)
2. Requirements Language
3. Key Exchange Methods
3.1. Elliptic Curve Cryptography (ECC)
3.1.1. curve25519-sha256 and gss-curve25519-sha256-*
3.1.2. curve448-sha512 and gss-curve448-sha512-*
3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp*
3.2. Finite Field Cryptography (FFC)
3.2.1. FFC Diffie-Hellman Using Generated MODP Groups
3.2.2. FFC Diffie-Hellman Using Named MODP Groups
3.3. Integer Factorization Cryptography (IFC)
3.4. KDFs and Integrity Hashing
3.5. Secure Shell Extension Negotiation
4. Summary Guidance for Implementation of Key Exchange Method
Names
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address
Secure Shell (SSH) is a common protocol for secure communication on the Internet. In [RFC4253], SSH originally defined two Key Exchange (KEX) Method Names that MUST be implemented. Over time, what was once considered secure is no longer considered secure. The purpose of this RFC is to recommend that some published key exchanges be deprecated or disallowed as well as to recommend some that SHOULD and one that MUST be adopted.
Secure Shell（SSH）は、インターネット上の安全な通信のための一般的なプロトコルです。[RFC4253]では、最初に実行する必要がある2つの鍵交換（KEX）メソッド名を定義しています。時間が経つにつれて、安全であると考えられたことはもはや安全ではないと考えられていません。このRFCの目的は、いくつかの公開されている鍵交換が推奨されていないか、または採用されなければならないものを推奨することを推奨することです。
This document updates [RFC4250], [RFC4253], [RFC4432], and [RFC4462] by changing the requirement level ("MUST" moving to "SHOULD", "MAY", or "SHOULD NOT", and "MAY" moving to "MUST", "SHOULD", "SHOULD NOT", or "MUST NOT") of various key exchange mechanisms. Some recommendations will be unchanged but are included for completeness.
この文書は[RFC4250]、[RFC4253]、[RFC4432]、[RFC4432]、[RFC4442]、[RFC4462]、[RFC4462]、[RFC4462]、[はず "、" may "、"、 "、"しないで ""様々な鍵交換メカニズムの「必ず」、「しない」、「しない」、または「してはいけない」）。いくつかの推奨事項は変わりませんが完全性のために含まれます。
Section 7.2 of [RFC4253] says the following:
[RFC4253]のセクション7.2は次のとおりです。
| The key exchange produces two values: a shared secret K, and an
| exchange hash H. Encryption and authentication keys are derived
| from these. The exchange hash H from the first key exchange is
| additionally used as the session identifier, which is a unique
| identifier for this connection. It is used by authentication
| methods as a part of the data that is signed as a proof of
| possession of a private key. Once computed, the session
| identifier is not changed, even if keys are later re-exchanged.
The security strength of the public key exchange algorithm and the hash used in the Key Derivation Function (KDF) both impact the security of the shared secret K being used.
公開鍵交換アルゴリズムのセキュリティ強度と鍵導出関数（KDF）で使用されているハッシュはどちらも使用されている共有秘密kのセキュリティに影響を与えます。
The hashing algorithms used by key exchange methods described in this document are: sha1, sha256, sha384, and sha512. In many cases, the hash name is explicitly appended to the public key exchange algorithm name. However, some of them are implicit and defined in the RFC that defines the key exchange algorithm name.
この文書に記載されている主要交換方法で使用されるハッシュアルゴリズムは、SHA1、SHA256、SHA384、およびSHA512です。多くの場合、ハッシュ名は公開鍵交換アルゴリズム名に明示的に追加されています。ただし、それらの一部は鍵交換アルゴリズム名を定義するRFCで暗黙的および定義されています。
Various RFCs use different spellings and capitalizations for the hashing function and encryption function names. For the purpose of this document, the following are equivalent names: sha1, SHA1, and SHA-1; sha256, SHA256, SHA-256, and SHA2-256; sha384, SHA384, SHA-384, and SHA2-384; and sha512, SHA512, SHA-512, and SHA2-512.
さまざまなRFCSは、ハッシュ関数と暗号化関数名のために異なるスペルと資本化を使用します。この文書の目的のために、以下は同等の名前です：SHA1、SHA1、およびSHA-1。SHA256、SHA256、SHA-256、およびSHA2-256。SHA384、SHA384、SHA-384、およびSHA2-384。SHA512、SHA512、SHA-512、およびSHA2-512。
For the purpose of this document, the following are equivalent: aes128, AES128, AES-128; aes192, AES192, and AES-192; and aes256, AES256, and AES-256.
この文書の目的のために、以下は等価です：AES128、AES128、AES-128。AES192、AES192、およびAES-192。AES256、AES256、およびAES-256。
It is good to try to match the security strength of the public key exchange algorithm with the security strength of the symmetric cipher.
公開鍵交換アルゴリズムのセキュリティ強さを対称暗号のセキュリティ強度と一致させることを試みるのが良いことです。
There are many possible symmetric ciphers available with multiple modes. The list in Table 1 is intended as a representative sample of those that appear to be present in most SSH implementations. The security strength estimates are generally available in [RFC4086] for triple-DES and AES, as well as Section 5.6.1.1 of [NIST.SP.800-57pt1r5].
複数のモードで利用可能な多くの可能な対称暗号があります。表1のリストは、ほとんどのSSH実装で存在するように見えるものの代表的なサンプルとして意図されています。セキュリティ強度の見積もりは、一般的にTriple-DESおよびAESの[RFC4086]では、[NIST.SP.800-57PT1R5]のセクション5.6.1.1では使用可能です。
+========================+=============================+
| Cipher Name (modes) | Estimated Security Strength |
+========================+=============================+
| 3des (cbc) | 112 bits |
+------------------------+-----------------------------+
| aes128 (cbc, ctr, gcm) | 128 bits |
+------------------------+-----------------------------+
| aes192 (cbc, ctr, gcm) | 192 bits |
+------------------------+-----------------------------+
| aes256 (cbc, ctr, gcm) | 256 bits |
+------------------------+-----------------------------+
Table 1: Symmetric Cipher Security Strengths
表1：対称暗号セキュリティ強度
The following subsections describe how to select each component of the key exchange.
次のサブセクションでは、キー交換の各コンポーネントを選択する方法について説明します。
The SHA-1 hash is in the process of being deprecated for many reasons.
SHA-1ハッシュは、多くの理由で廃止予定のプロセスです。
There have been attacks against SHA-1, and it is no longer strong enough for SSH security requirements. Therefore, it is desirable to move away from using it before attacks become more serious.
SHA-1に対する攻撃があり、SSHのセキュリティ要件には十分に強くはありません。したがって、攻撃がより深刻になる前にそれを使用することから離れることが望ましいです。
The SHA-1 hash provides for approximately 80 bits of security strength. This means that the shared key being used has at most 80 bits of security strength, which may not be sufficient for most users.
SHA-1ハッシュは、約80ビットのセキュリティ強度を提供します。これは、使用されている共有キーが最大80ビットのセキュリティ強度を持ち、ほとんどのユーザーにとって十分ではない可能性があります。
For purposes of key exchange methods, attacks against SHA-1 are collision attacks that usually rely on human help rather than a pre-image attack. The SHA-1 hash resistance against a second pre-image is still at 160 bits, but SSH does not depend on second pre-image resistance but rather on chosen-prefix collision resistance.
主要な交換方法の目的のために、SHA-1に対する攻撃は、通常、画像の攻撃よりもむしろ人間の助けに頼る衝突攻撃です。第2の事前画像に対するSHA - 1ハッシュ抵抗は依然として160ビットであるが、SSHは第2の事前像抵抗に依存しないが、むしろ選択されたプレフィックス衝突抵抗に依存しない。
Transcript Collision attacks are documented in [TRANSCRIPTION]. This paper shows that an on-path attacker does not tamper with the Diffie-Hellman values and does not know the connection keys. The attack could be used to tamper with both I_C and I_S (as defined in Section 7.3 of [RFC4253]) and might potentially be able to downgrade the negotiated ciphersuite to a weak cryptographic algorithm that the attacker knows how to break.
トランスクリプト衝突攻撃は[転記]に記載されています。このホワイトペーパーでは、ON-PATH攻撃者がDiffie-Hellman値を改ざんしなくており、接続キーを知りません。攻撃はI_CとI_Sの両方を改ざんすることができ、（RFC4253のセクション7.3で定義されているように）、ネゴシエートされた暗号化アルゴリズムを攻撃者が壊す方法を知っている弱い暗号化アルゴリズムにダウングラフすることができる可能性があります。
These attacks are still computationally very difficult to perform, but it is desirable that any key exchange using SHA-1 be phased out as soon as possible.
これらの攻撃は依然として計算的に実行することが非常に困難であるが、SHA - 1を使用する任意の鍵交換はできるだけ早く段階的であることが望ましい。
If there is a need for using SHA-1 in a key exchange for compatibility, it would be desirable to list it last in the preference list of key exchanges.
互換性のために鍵交換でSHA-1を使用する必要がある場合は、鍵交換の環境設定リストで最後に一覧表示することが望ましいでしょう。
Use of the SHA-2 family of hashes found in [RFC6234] rather than the SHA-1 hash is strongly advised.
SHA-1ハッシュではなく[RFC6234]に見られるSHA-2ファミリーのハッシュの使用が強く推奨されています。
When it comes to the SHA-2 family of secure hashing functions, SHA2-256 has 128 bits of security strength; SHA2-384 has 192 bits of security strength; and SHA2-512 has 256 bits of security strength. It is suggested that the minimum secure hashing function used for key exchange methods should be SHA2-256 with 128 bits of security strength. Other hashing functions may also have the same number of bits of security strength, but none are as yet defined in any RFC for use in a KEX for SSH.
SHA-2ファミリーの安全なハッシュ関数になると、SHA2-256には128ビットのセキュリティ強度があります。SHA2-384には192ビットのセキュリティ強度があります。SHA2-512には256ビットのセキュリティ強度があります。鍵交換方法に使用される最小セキュアハッシュ関数は、128ビットのセキュリティ強度を持つSHA2-256である必要があります。他のハッシュ関数はまた、同じ数のセキュリティ強度を有することができるが、SSHのためにkexで使用するための任意のRFCにおいてまだ定義されていない。
To avoid combinatorial explosion of key exchange names, newer key exchanges are generally restricted to *-sha256 and *-sha512. The exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*, which are defined to use SHA2-384 (also known as SHA-384) defined in [RFC6234] for the hash algorithm.
鍵交換名の組み合わせ爆発を避けるために、新しい鍵交換は一般に* -Sha256と* -sha512に制限されています。例外は、ECDH-SHA2-NISTP384およびGSS-NISTP384-SHA384- *で、ハッシュアルゴリズムの[RFC6234]で定義されたSHA2-384（SHA-384とも呼ばれる）を使用するように定義されています。
Table 2 provides a summary of security strength for hashing functions for collision resistance. You may consult [NIST.SP.800-107r1] for more information on hash algorithm security strength.
表2は、衝突抵抗のためのハッシュ関数のセキュリティ強度の概要を示しています。ハッシュアルゴリズムのセキュリティ強度の詳細については、[NIST.SP.800-107R1]にお問い合わせください。
+===========+=============================+
| Hash Name | Estimated Security Strength |
+===========+=============================+
| sha1 | 80 bits (before attacks) |
+-----------+-----------------------------+
| sha256 | 128 bits |
+-----------+-----------------------------+
| sha384 | 192 bits |
+-----------+-----------------------------+
| sha512 | 256 bits |
+-----------+-----------------------------+
Table 2: Hashing Function Security Strengths
表2：ハッシュ関数セキュリティ強度
SSH uses mathematically hard problems for doing key exchanges:
SSHは、キー交換を行うために数学的に難しい問題を使用します。
* Elliptic Curve Cryptography (ECC) has families of curves for key exchange methods for SSH. NIST prime curves with names and other curves are available using an object identifier (OID) with Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 and curve448 key exchanges are used with ECDH via [RFC8731].
* 楕円曲線暗号化（ECC）は、SSHのための鍵交換方法のための曲線のファミリーを持っています。名前やその他の曲線を持つNIST Prime曲線は、[RFC5656]を介して楕円曲線Diffie-Hellman（ECDH）を使用して、オブジェクト識別子（OID）を使用して使用できます。Curve25519とCurve448キー交換はECDHで使用されます[RFC8731]。
* Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) key exchange with "safe primes" either from a specified list found in [RFC3526] or generated dynamically via [RFC4419] as updated by [RFC8270].
* [RFC3526]で見つけられた指定リストから[RFC4419]が[RFC8270]で[RFC4419]で動的に生成された、Diffie-Hellman（DH）鍵交換には、有限フィールド暗号化（FFC）が使用されます。
* Integer Factorization Cryptography (IFC) using the RSA algorithm is provided for in [RFC4432].
* RSAアルゴリズムを使用した整数因数分解暗号化（IFC）は、[RFC4432]に提供されています。
It is desirable that the security strength of the key exchange be chosen to be comparable with the security strength of the other elements of the SSH handshake. Attackers can target the weakest element of the SSH handshake.
鍵交換のセキュリティ強度は、SSHハンドシェイクの他の要素のセキュリティ強度と同等になるように選択されることが望ましい。攻撃者はSSHハンドシェイクの最も弱い要素をターゲットにすることができます。
It is desirable that a minimum of 112 bits of security strength be selected to match the weakest of the symmetric cipher (3des-cbc) available. Based on implementer security needs, a stronger minimum may be desired.
最低112ビットのセキュリティ強度が、利用可能な対称暗号（3DES - CBC）の最も弱いものと一致するように選択されることが望ましい。実装者のセキュリティのニーズに基づいて、より強い最小値が望まれる場合があります。
The larger the Modular Exponentiation (MODP) group, the ECC curve size, or the RSA key length, the more computation power will be required to perform the key exchange.
モジュラー指数（MODP）グループ、ECCカーブサイズ、またはRSAキーの長さが大きいほど、鍵交換を実行するためには、より計算電力が必要になります。
For ECC, across all of the named curves, the minimum security strength is approximately 128 bits. The [RFC5656] key exchanges for the named curves use a hashing function with a matching security strength. Likewise, the [RFC8731] key exchanges use a hashing function that has more security strength than the curves. The minimum strength will be the security strength of the curve. Table 3 contains a breakdown of just the ECC security strength by curve name; it does include the hashing algorithm used. The curve25519 and curve488 security-level numbers are in [RFC7748]. The nistp256, nistp384, and nistp521 (NIST prime curves) are provided in [RFC5656]. The hashing algorithm designated for use with the individual curves have approximately the same number of bits of security as the named curve.
ECCの場合、名前付き曲線の全てにわたって、最小セキュリティ強度は約128ビットです。名前付き曲線の[RFC5656]キー交換は、一致するセキュリティ強度を持つハッシュ関数を使用します。同様に、[RFC8731]キー交換は、曲線よりもセキュリティ強度が多くなるハッシュ関数を使用します。最小強度は曲線のセキュリティ強度になります。表3に、曲線名によるECCセキュリティ強度のみの内訳が含まれています。使用されるハッシュアルゴリズムが含まれます。CURVE25519とCURVE488セキュリティレベルの数字は[RFC7748]です。NISTP256、NISTP384、およびNISTP521（NISTプライム曲線）は[RFC5656]に設けられています。個々の曲線と共に使用するために指定されたハッシュアルゴリズムは、名前付き曲線とほぼ同じビットのセキュリティ数を有する。
+============+=============================+
| Curve Name | Estimated Security Strength |
+============+=============================+
| nistp256 | 128 bits |
+------------+-----------------------------+
| nistp384 | 192 bits |
+------------+-----------------------------+
| nistp521 | 512 bits |
+------------+-----------------------------+
| curve25519 | 128 bits |
+------------+-----------------------------+
| curve448 | 224 bits |
+------------+-----------------------------+
Table 3: ECC Security Strengths
表3：ECCセキュリティ強み
For FFC, it is recommended to use a modulus with a minimum of 2048 bits (approximately 112 bits of security strength) with a hash that has at least as many bits of security as the FFC. The security strength of the FFC and the hash together will be the minimum of those two values. This is sufficient to provide a consistent security strength for the 3des-cbc cipher. Section 1 of [RFC3526] notes that the Advanced Encryption Standard (AES) cipher, which has more strength, needs stronger groups. For the 128-bit AES, we need about a 3200-bit group. The 192- and 256-bit keys would need groups that are about 8000 and 15400 bits, respectively. Table 4 provides the security strength of the MODP group. When paired with a hashing algorithm, the security strength will be the minimum of the two algorithms.
FFCの場合、最低2048ビット（約112ビットのセキュリティ強度）のモジュラスを使用することをお勧めします。FFCとハッシュのセキュリティ強度は、これら2つの値の最小値になります。これは、3DES-CBC暗号に対して一貫したセキュリティ強度を提供するのに十分です。[RFC3526]のセクション1は、強度が強く、より強力なグループが必要です。128ビットAESの場合は、3200ビットのグループが必要です。192および256ビットキーは、それぞれ約8000と15400ビットのグループを必要とします。表4は、MODPグループのセキュリティ強度を提供します。ハッシュアルゴリズムとペアになっている場合、セキュリティ強度は2つのアルゴリズムの最小値になります。
+==================+=============================+============+
| Prime Field Size | Estimated Security Strength | Example |
| | | MODP Group |
+==================+=============================+============+
| 2048-bit | 112 bits | group14 |
+------------------+-----------------------------+------------+
| 3072-bit | 128 bits | group15 |
+------------------+-----------------------------+------------+
| 4096-bit | 152 bits | group16 |
+------------------+-----------------------------+------------+
| 6144-bit | 176 bits | group17 |
+------------------+-----------------------------+------------+
| 8192-bit | 200 bits | group18 |
+------------------+-----------------------------+------------+
Table 4: FFC MODP Security Strengths
表4：FFC MODPセキュリティ強化
The minimum MODP group is the 2048-bit MODP group14. When used with a SHA-1 hash, this group provides approximately 80 bits of security. When used with a SHA2-256 hash, this group provides approximately 112 bits of security. The 3des-cbc cipher itself provides at most 112 bits of security, so the group14-sha256 key exchanges is sufficient to keep all of the 3des-cbc key, for 112 bits of security.
最小MODPグループは、2048ビットMODP GROUP14です。SHA-1ハッシュと共に使用されるとき、このグループは約80ビットのセキュリティを提供します。SHA2-256ハッシュと共に使用されると、このグループは約112ビットのセキュリティを提供します。3DES-CBC暗号自体は最大112ビットのセキュリティを提供します。そのため、Group14-SHA256キー交換では、3DES-CBCキーをすべて保証112ビットに保つのに十分です。
A 3072-bit MODP group when used with a SHA2-256 hash will provide approximately 128 bits of security. This is desirable when using a cipher such as aes128 or chacha20-poly1305 that provides approximately 128 bits of security.
SHA2-256ハッシュと共に使用されるときの3072ビットMODPグループは、約128ビットのセキュリティを提供します。これは、AES128またはChacha20-Poly1305などの暗号を使用するとき、約128ビットのセキュリティを提供するときに望ましい。
The 8192-bit group18 MODP group when used with sha512 provides approximately 200 bits of security, which is sufficient to protect aes192 with 192 bits of security.
SHA512と共に使用されたときの8192ビットGROUP18 MODPグループは、約200ビットのセキュリティを提供します。これは、192ビットのセキュリティでAES192を保護するのに十分です。
The only IFC algorithm for key exchange is the RSA algorithm specified in [RFC4432]. RSA 1024-bit keys have approximately 80 bits of security strength. RSA 2048-bit keys have approximately 112 bits of security strength. It is worth noting that the IFC types of key exchange do not provide Forward Secrecy, which both FFC and ECC do provide.
鍵交換の唯一のIFCアルゴリズムは、[RFC4432]で指定されたRSAアルゴリズムです。RSA 1024ビットキーには、約80ビットのセキュリティ強度があります。RSA 2048ビットキーには、約112ビットのセキュリティ強度があります。IFCのタイプの鍵交換の種類が前進秘密を提供していないため、FFCとECCの両方が提供することがわかります。
In order to match the 112 bits of security strength needed for 3des-cbc, an RSA 2048-bit key matches the security strength. The use of a SHA-2 family hash with RSA 2048-bit keys has sufficient security to match the 3des-cbc symmetric cipher. The rsa1024-sha1 key exchange has approximately 80 bits of security strength and is not desirable.
3DES-CBCに必要な112ビットのセキュリティ強度と一致させるために、RSA 2048ビットキーはセキュリティ強度と一致します。SHA-2ファミリハッシュをRSA 2048ビットキーで使用するには、3DES-CBC対称暗号を一致させるのに十分なセキュリティがあります。RSA1024-SHA1キー交換は、約80ビットのセキュリティ強度を持ち、望ましくありません。
Table 5 summarizes the security strengths of these key exchanges without including the hashing algorithm strength. Guidance for these strengths can be found in Section 5.6.1.1 of [NIST.SP.800-57pt1r5].
ハッシュアルゴリズム強度を含まずに、これらの鍵交換のセキュリティ強みをまとめたものである。これらの強みに対するガイダンスは[NIST.SP.800-57PT1R5]のセクション5.6.1.1にあります。
+=====================+=============================+
| Key Exchange Method | Estimated Security Strength |
+=====================+=============================+
| rsa1024-sha1 | 80 bits |
+---------------------+-----------------------------+
| rsa2048-sha256 | 112 bits |
+---------------------+-----------------------------+
Table 5: IFC Security Strengths
表5：IFCセキュリティ強み
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document adopts the style and conventions of [RFC4253] in specifying how the use of data key exchange is indicated in SSH.
この文書では、SSHでデータ鍵交換の使用方法を指定する際に、[RFC4253]のスタイルと規則を採用しています。
This RFC also collects key exchange method names in various existing RFCs ([RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], [RFC8268], [RFC8308], [RFC8731], and [RFC8732]) and provides a suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT. Any method not explicitly listed MAY be implemented.
このRFCはまた、既存のRFCの鍵交換方法名を収集します（[RFC4253]、[RFC4419]、[RFC4432]、[RFC4462]、[RFC5656]、[RFC8268]、[RFC8731]、[RFC8732]）そして、必須の可能性のために提案された適合性を提供し、そうでなければならず、そうでなければならない。明示的にリストされていない方法が実装されてもよい。
Section 7.2 of [RFC4253] defines the generation of a shared secret K (really the output of the KDF) and an exchange key hash H. Each key exchange method uses a specified HASH function, which must be the same for both key exchange and Key Derivation. H is used for key exchange integrity across the SSH session as it is computed only once. It is noted at the end of Section 7.2 of [RFC4253] that:
[RFC4253]のセクション7.2は、共有シークレットK（実際にはKDFの出力）とExchangeキーHASH Hの生成を定義します。各鍵交換方法は指定されたハッシュ関数を使用します。これは、キー交換とキーの両方で同じでなければなりません。導出。Hは、SSHセッション全体での鍵交換整合性に1回だけ計算されます。[RFC4253]のセクション7.2の終わりに注意しています。
| This process will lose entropy if the amount of entropy in K is | larger than the internal state size of HASH.
| ..このプロセスは、Kのエントロピーの量が|の場合はエントロピーを失います。ハッシュの内部状態サイズよりも大きい。
So, care must be taken that the hashing algorithm used is well chosen ("reasonable") for the key exchange algorithms being used.
そのため、使用されている主要な交換アルゴリズムについては、使用されるハッシュアルゴリズムがよく選択されている（「合理的な」）ことが注意してください。
This document provides guidance as to what key exchange algorithms are to be considered for new or updated SSH implementations.
この文書は、新規または更新されたSSH実装のために、主要な交換アルゴリズムを考慮する必要があるものについてのガイダンスを提供します。
In general, key exchange methods that are considered "weak" are being moved to either deprecated ("SHOULD NOT") or disallowed ("MUST NOT"). Methods that are newer or considered to be stronger usually require more device resources than many administrators and/or developers need are to be allowed ("MAY"). (Eventually, some of these methods could be moved by consensus to "SHOULD" to increase interoperability and security.) Methods that are not "weak" and have implementation consensus are encouraged ("SHOULD"). There needs to be at least one consensus method promoted to a status of mandatory to implement (MTI). This should help to provide continued interoperability even with the loss of one of the now disallowed MTI methods.
一般に、「弱い」と見なされる鍵交換方法は、推奨されていない（「しない」）または許可されていない（「必ず」してはいけません）。より新しいか、またはより強いと考えられる方法は、通常、多くの管理者や開発者が許可される必要がある（「MAY」という）ことができるよりも多くのデバイスリソースを必要とします。（最終的には、これらの方法のいくつかは、相互運用性とセキュリティを増やすために「コンセンサス」に移動することができます。）「弱い」とは限らない方法で、実装コンセンサスが促進されます（ ""）。実装（MTI）のために必須のステータスに昇格した少なくとも1つのコンセンサス法が必要です。これは、現在許可されていないMTIメソッドのいずれかの損失でも、継続的な相互運用性を提供するのに役立ちます。
For this document, 112 bits of security strength is the minimum. Use of either or both of SHA-1 and RSA 1024 bits at an approximate 80 bits of security fall below this minimum and should be deprecated and moved to disallowed as quickly as possible in configured deployments of SSH. It seems plausible that this minimum may be increased over time, so authors and administrators may wish to prepare for a switch to algorithms that provide more security strength.
この文書では、112ビットのセキュリティ強度が最小です。SHA-1とRSA 1024ビットのどちらかまたは両方のセキュリティがこの最小値を下回ると、SSHの設定された展開でできるだけ早く許可されないように推奨されていないように移動して移動する必要があります。この最小値が時間の経過とともに増加する可能性があるように見えるように見えるので、作者や管理者は、より多くのセキュリティ強さを提供するアルゴリズムへのスイッチを準備することを望むかもしれません。
The Elliptic Curve (EC) key exchange algorithms used with SSH include the ECDH and EC Menezes-Qu-Vanstone (ECMQV).
SSHで使用される楕円曲線（EC）鍵交換アルゴリズムには、ECDHおよびEC Menezes-Qu-Vanstone（ECMQV）が含まれます。
The ECC curves defined for the key exchange algorithms above include the following: curve25519, curve448, the NIST prime curves (nistp256, nistp384, and nistp521), as well as other curves allowed for by Section 6 of [RFC5656]. There are key exchange mechanisms based on the Generic Security Service Application Program Interface (GSS-API) that use these curves as well that have a "gss-" prefix.
上記の鍵交換アルゴリズムに定義されているECC曲線には、Curve25519、Curve448、NIST Prime Curves（NISTP256、NISTP384、およびNISTP521）、および[RFC5656]のセクション6によって許容されるその他の曲線があります。これらの曲線を使用するGeneric Security Service Application Program Interface（GSS-API）に基づく主要な交換メカニズムがあります。
Curve25519 is efficient on a wide range of architectures with properties that allow higher-performance implementations compared to the patented elliptic curve parameters purchased by NIST for the general public to use as described in [RFC5656]. The corresponding key exchange methods use SHA2-256 (also known as SHA-256) defined in [RFC6234]. SHA2-256 is a reasonable hash for use in both the KDF and session integrity. It is reasonable for both gss and non-gss uses of curve25519 key exchange methods. These key exchange methods are described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key agreement described in [RFC8031]. The curve25519-sha256 key exchange method has multiple implementations and SHOULD be implemented. The gss-curve25519-sha256-* key exchange method SHOULD also be implemented because it shares the same performance and security characteristics as curve25519-sha256.
CURVE25519は、[RFC5656]に記載されているように、一般的な公衆のために購入された特許取得済みの楕円曲線パラメータと比較して、高性能な実装を可能にする特性を有する広範囲のアーキテクチャで効率的です。対応する鍵交換方法は、[RFC6234]で定義されているSHA2-256（SHA-256とも呼ばれます）を使用します。SHA2-256は、KDFとセッションの整合性の両方で使用するための妥当なハッシュです。GSSと非GSSの両方がCurve25519キー交換方法の使用に合理的です。これらの主要な交換方法は[RFC8731]と[RFC8732]に記載されており、[RFC8031]に記載されているIKEV2キー契約と同様です。CURVE25519-SHA256キー交換方法には複数の実装があり、実装する必要があります。GSS-Curve25519-SHA256- *キー交換方法は、Curve25519-SHA256と同じ性能とセキュリティ特性を共有しているため、鍵交換方法も実装する必要があります。
Table 6 contains a summary of the recommendations for curve25519-based key exchanges.
表6は、Curve25519ベースのキー交換の推奨事項の概要を示しています。
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| curve25519-sha256 | SHOULD |
+--------------------------+----------+
| gss-curve25519-sha256-* | SHOULD |
+--------------------------+----------+
Table 6: Curve25519 Implementation Guidance
表6：CURVE25519実装ガイダンス
Curve448 provides more security strength than curve25519 at a higher computational and bandwidth cost. The corresponding key exchange methods use SHA2-512 (also known as SHA-512) defined in [RFC6234]. SHA2-512 is a reasonable hash for use in both the KDF and session integrity. It is reasonable for both gss and non-gss uses of curve448 key exchange methods. These key exchange methods are described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key agreement described in [RFC8031]. The curve448-sha512 key exchange method MAY be implemented. The gss-curve448-sha512-* key exchange method MAY also be implemented because it shares the same performance and security characteristics as curve448-sha512.
CURVE448は、より高い計算と帯域幅のコストでCurve25519よりも高いセキュリティ強度を提供します。対応する鍵交換方法は、[RFC6234]で定義されているSHA2-512（SHA-512とも呼ばれる）を使用します。SHA2-512は、KDFとセッションの整合性の両方で使用するための妥当なハッシュです。GSSと非GSSの両方がCurve448キー交換方法の使用に合理的です。これらの主要な交換方法は[RFC8731]と[RFC8732]に記載されており、[RFC8031]に記載されているIKEV2キー契約と同様です。CURVE448-SHA512キー交換方法を実装することができます。GSS-Curve448-SHA512- *鍵交換方法は、Curve448-SHA512と同じ性能とセキュリティ特性を共有するため、実装されてもよい。
Table 7 contains a summary of the recommendations for curve448-based key exchanges.
表7に、Curve448ベースのキー交換の推奨事項の概要を示します。
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| curve448-sha512 | MAY |
+--------------------------+----------+
| gss-curve448-sha512-* | MAY |
+--------------------------+----------+
Table 7: Curve448 Implementation Guidance
表7：Curve448実装ガイダンス
The ecdh-sha2-* namespace allows for both the named NIST prime curves (nistp256, nistp384, and nistp521) as well as other curves to be defined for the ECDH key exchange. At the time of this writing, there are three named curves in this namespace that SHOULD be supported. They appear in Section 10.1 of [RFC5656]. If implemented, the named curves SHOULD always be enabled unless specifically disabled by local security policy. In Section 6.1 of [RFC5656], the method to name other ECDH curves using OIDs is specified. These other curves MAY be implemented.
ECDH-SHA2- *名前空間は、名前付きNIST Prime Curves（NISTP256、NISTP384、およびNISTP521）とECDH鍵交換用に定義される他の曲線の両方を可能にします。この書き込み時には、サポートされるべきこのネームスペースには、3つの名前付き曲線があります。それらは[RFC5656]のセクション10.1に表示されます。実装されている場合、名前付き曲線は常にローカルセキュリティポリシーによって特に無効にされない限り有効にする必要があります。[RFC5656]のセクション6.1では、OIDを使用して他のECDH曲線に名前を付ける方法が指定されています。これらの他の曲線を実施することができる。
The GSS-API namespace with gss-nistp*-sha* mirrors the algorithms used by ecdh-sha2-* names. They are described in [RFC8732].
GSS-NISTP * -SHA *を持つGSS-API名前空間は、ECDH-SHA2- *名で使用されるアルゴリズムを反映しています。それらは[RFC8732]に記載されています。
ECDH reduces bandwidth of key exchanges compared to FFC DH at a similar security strength.
ECDHは、同様のセキュリティ強度でFFC DHと比較して鍵交換の帯域幅を減少させます。
Table 8 lists algorithms as "SHOULD" where implementations may be more efficient or widely deployed. The items listed as "MAY" in Table 8 are potentially less efficient.
表8は、実装がより効率的であるか広く展開される可能性がある「SOPE」としてのアルゴリズムをリストします。表8の「5月」としてリストされている項目は潜在的に効率的ではありません。
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| ecdh-sha2-* | MAY |
+--------------------------+----------+
| ecdh-sha2-nistp256 | SHOULD |
+--------------------------+----------+
| gss-nistp256-sha256-* | SHOULD |
+--------------------------+----------+
| ecdh-sha2-nistp384 | SHOULD |
+--------------------------+----------+
| gss-nistp384-sha384-* | SHOULD |
+--------------------------+----------+
| ecdh-sha2-nistp521 | SHOULD |
+--------------------------+----------+
| gss-nistp521-sha512-* | SHOULD |
+--------------------------+----------+
| ecmqv-sha2 | MAY |
+--------------------------+----------+
Table 8: ECDH Implementation Guidance
表8：ECDH実装ガイダンス
It is advisable to match the Elliptic Curve Digital Signature Algorithm (ECDSA) and ECDH algorithm to use the same curve for both to maintain the same security strength in the connection.
接続内の同じセキュリティ強度を維持するために同じ曲線を使用するように楕円曲線デジタル署名アルゴリズム（ECDSA）とECDHアルゴリズムとを一致させることをお勧めします。
[RFC4419] defines two key exchange methods that use a random selection from a set of pre-generated moduli for key exchange: the diffie-hellman-group-exchange-sha1 method and the diffie-hellman-group-exchange-sha256 method. Per [RFC8270], implementations SHOULD use a MODP group whose modulus size is equal to or greater than 2048 bits. MODP groups with a modulus size less than 2048 bits are weak and MUST NOT be used.
[RFC4419]鍵交換の事前に生成されたモジュリのセットからランダムな選択を使用する2つの鍵交換方法を定義します。[RFC8270]ごとに、実装は、モジュラスサイズが2048ビット以上のMODPグループを使用する必要があります。2048ビット未満のモジュラスサイズを持つMODPグループは弱く、使用してはいけません。
The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT be used. This method uses SHA-1, which is being deprecated.
Diffie-Hellman-Group-Exchange-SHA1鍵交換方法は使用しないでください。この方法では、推奨されていないSHA-1を使用しています。
The diffie-hellman-group-exchange-sha256 key exchange method MAY be used. This method uses SHA2-256, which is reasonable for MODP groups less than 4096 bits.
DIFFIE-HELLMAN-GROUP-Exchange-SHA256鍵交換方法を使用することができる。このメソッドはSHA2-256を使用しています。これは、4096ビット未満のMODPグループに合理的なものです。
Care should be taken in the pre-generation of the moduli P and generator G such that the generator provides a Q-ordered subgroup of P. Otherwise, the parameter set may leak one bit of the shared secret.
ジェネレータがPのQ順にサブグループを提供するように、Moduli PおよびGenerator Gの事前生成に注意する必要があります。そうしないと、パラメータセットは共有秘密の1ビットを漏らす可能性があります。
Table 9 provides a summary of the guidance for these exchanges.
表9は、これらの交換のためのガイダンスの概要を示しています。
+======================================+============+
| Key Exchange Method Name | Guidance |
+======================================+============+
| diffie-hellman-group-exchange-sha1 | SHOULD NOT |
+--------------------------------------+------------+
| diffie-hellman-group-exchange-sha256 | MAY |
+--------------------------------------+------------+
Table 9: FFC Generated MODP Group Implementation Guidance
表9：FFCが生成されたMODPグループの実装ガイダンス
The diffie-hellman-group14-sha256 key exchange method is defined in [RFC8268] and represents a key exchange that has approximately 112 bits of security strength that matches 3des-cbc symmetric cipher security strength. It is a reasonably simple transition from SHA-1 to SHA-2, and given that diffie-hellman-group14-sha1 and diffie-hellman-group14-sha256 share a MODP group and only differ in the hash function used for the KDF and integrity, it is a correspondingly simple transition from implementing diffie-hellman-group14-sha1 to implementing diffie-hellman-group14-sha256. Given that diffie-hellman-group14-sha1 is being removed from mandatory to implement (MTI) status, the diffie-hellman-group14-sha256 method MUST be implemented. The rest of the FFC MODP group from [RFC8268] have a larger number of security bits and are suitable for symmetric ciphers that also have a similar number of security bits.
DIFFIE-HELLMAN-GROUP14-SHA256鍵交換方法は[RFC8268]で定義され、3DES-CBC対称暗号セキュリティ強度に一致する約112ビットのセキュリティ強度を持つ鍵交換を表します。SHA-1からSHA-2への適度に簡単な遷移で、Diffie-Hellman-Group14-SHA1とDiffie-Hellman-Group14-SHA256がMODPグループを共有し、KDFと完全性に使用されるハッシュ関数のみが異なることを考えるまた、Diffie-Hellman-Group14-SHA1を実装してdiffie-hellman-group14-sha256を実装することからの対応して簡単な遷移です。diffie-hellman-group14-sha1が必須から（MTI）ステータスに除去されていることを考えると、diffie-hellman-group14-sha256メソッドを実装する必要があります。[RFC8268]からのFFC MODPグループの残りのセキュリティビットは、より多くのセキュリティビットを持ち、同様の数のセキュリティビットを持つ対称暗号に適しています。
Table 10 provides explicit guidance by name.
表10は、名前による明示的なガイダンスを提供します。
+===============================+==========+
| Key Exchange Method Name | Guidance |
+===============================+==========+
| diffie-hellman-group14-sha256 | MUST |
+-------------------------------+----------+
| gss-group14-sha256-* | SHOULD |
+-------------------------------+----------+
| diffie-hellman-group15-sha512 | MAY |
+-------------------------------+----------+
| gss-group15-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group16-sha512 | SHOULD |
+-------------------------------+----------+
| gss-group16-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group17-sha512 | MAY |
+-------------------------------+----------+
| gss-group17-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group18-sha512 | MAY |
+-------------------------------+----------+
| gss-group18-sha512-* | MAY |
+-------------------------------+----------+
Table 10: FFC Named Group Implementation Guidance
表10：Group Implementation Guidanceという名前のFFC
The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses an RSA 1024-bit modulus with a SHA-1 hash. This key exchange does NOT meet security requirements. This method MUST NOT be implemented.
RSA1024-SHA1鍵交換方法は[RFC4432]で定義され、SHA-1ハッシュでRSA 1024ビットモジュラスを使用します。この鍵交換はセキュリティ要件を満たしていません。この方法は実装されてはならない。
The rsa2048-sha256 key exchange method is defined in [RFC4432] and uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange meets 112-bit minimum security strength. This method MAY be implemented.
RSA2048-SHA256鍵交換方法は[RFC4432]で定義され、SHA2-256ハッシュでRSA 2048ビットモジュラスを使用します。この鍵交換は112ビットの最小限のセキュリティ強度を満たしています。この方法は実装されてもよい。
Table 11 provides a summary of the guidance for IFC key exchanges.
表11は、IFC鍵交換のためのガイダンスの概要を示しています。
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| rsa1024-sha1 | MUST NOT |
+--------------------------+----------+
| rsa2048-sha256 | MAY |
+--------------------------+----------+
Table 11: IFC Implementation Guidance
表11：IFC実装ガイダンス
The SHA-1 and SHA-2 family of hashing algorithms are combined with the FFC, ECC, and IFC algorithms to comprise a key exchange method name.
SHA-1およびSHA-2ファミリのハッシュアルゴリズムは、キー交換方法名を含むFFC、ECC、およびIFCアルゴリズムと組み合わされます。
The selected hash algorithm is used both in the KDF as well as for the integrity of the response.
選択されたハッシュアルゴリズムは、KDF内でも応答の整合性の両方で使用されます。
All of the key exchange methods using the SHA-1 hashing algorithm should be deprecated and phased out due to security concerns for SHA-1, as documented in [RFC6194].
SHA-1ハッシュアルゴリズムを使用したすべての鍵交換方法は、[RFC6194]に記載されているように、SHA-1のセキュリティ上の懸念のために廃止予定で廃止されるべきです。
Unconditionally deprecating and/or disallowing SHA-1 everywhere will hasten the day when it may be simply removed from implementations completely. Leaving partially broken algorithms lying around is not a good thing to do.
無条件でSHA-1を無償で償却し、いたるところでは、単に実装から完全に削除される可能性がある日が急増します。横になっている部分的に壊れたアルゴリズムを残すことは良いことではありません。
The SHA-2 family of hashes [RFC6234] is more secure than SHA-1. They have been standardized for use in SSH with many of the currently defined key exchanges.
HasheSのSHA-2ファミリー[RFC6234]はSHA-1よりも安全です。それらは、現在定義されている主要な交換の多くのSSHでの使用のために標準化されています。
Please note that at the present time, there is no key exchange method for Secure Shell that uses the SHA-3 family of secure hashing functions or the Extendable-Output Functions [NIST.FIPS.202].
現時点では、SHA-3ファミリのSHA-3ファミリを使用するセキュアシェルのための鍵交換方法はありません。
Prior to the changes made by this document, diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie-hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit MODP group) is defined in Section 3 of [RFC3526]. The SSH group1 is defined in Section 8.1 of [RFC4253] as using the Oakley Group 2 provided in Section 6.2 of [RFC2409] (a 1024-bit MODP group). This group1 MODP group with approximately 80 bits of security is too weak to be retained. However, rather than jumping from the MTI status to making it disallowed, many implementers suggested that it should transition to deprecated first and be disallowed at a later time. The group14 MODP group using a SHA-1 hash for the KDF is not as weak as the group1 MODP group. There are some legacy situations where it will still provide administrators with value, such as small hardware Internet of Things (IOT) devices that have insufficient compute and memory resources to use larger MODP groups before a timeout of the session occurs. There was consensus to transition from MTI to a requirement status that provides for continued use with the expectation that it would be deprecated or disallowed in the future. Therefore, it is considered reasonable to retain the diffie-hellman-group14-sha1 exchange for interoperability with legacy implementations. The diffie-hellman-group14-sha1 key exchange MAY be implemented, but should be put at the end of the list of negotiated key exchanges.
この文書によって行われた変更の前に、Diffie-Hellman-Group1-SHA1およびDiffie-Hellman-Group14-SHA1はMTIでした。 DIFFIE-HELLMAN-GROUP14-SHA1は2つのより強いです。 GROUP14（2048ビットMODPグループ）は[RFC3526]のセクション3で定義されています。 SSH Group1は、[RFC2409]（RFC2409]（1024ビットMODPグループ）で提供されているOakley Group 2を使用して、[RFC4253]のセクション8.1で定義されています。約80ビットのセキュリティを持つこのGroup1 MODPグループは、保持されるには弱すぎます。しかし、MTIステータスからそれを許可させているようにするために、MTIステータスからジャンプするのではなく、多くの実装者が最初に非推奨に移行して後で許可されるべきであることを提案しました。 KDFのSHA-1ハッシュを使用したGROUP14 MODPグループは、Group1 MODPグループと同じくらい弱くありません。セッションのタイムアウトが発生する前に、より大きなMODPグループを使用するためのコンピューティングリソースとメモリリソースが不十分なものとメモリリソースの小型ハードウェアインターネット（IoT）デバイスの小さなハードウェアインターネット（IoT）デバイスのような管理者には、管理者に提供されるものがあります。 MTIから継続的な使用を提供する要件ステータスに移行するためのコンセンサスが、将来非推奨または非難されることを期待しています。したがって、従来の実装との相互運用性についてDiffie-Hellman-Group14-SHA1の交換を維持するのは合理的であると考えられます。 Diffie-Hellman-Group14-SHA1の鍵交換は実装されるかもしれませんが、ネゴシエートされた鍵交換のリストの最後に置くべきです。
The diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1 SHOULD NOT be implemented. The gss-group1-sha1-*, gss-group14-sha1-*, and gss-gex-sha1-* key exchanges are already specified as SHOULD NOT be implemented by [RFC8732].
Diffie-Hellman-Group1-SHA1とDiffie-Hellman-Group-Exchange-SHA1は実装されてはいけません。GSS-GROUP1-SHA1- *、GSS-GROUP14-SHA1- *、GSS-GEX-SHA1- *キー交換は、[RFC8732]で実装されてはいけません。
There are two methods, ext-info-c and ext-info-s, defined in [RFC8308]. They provide a mechanism to support other Secure Shell negotiations. Being able to extend functionality is desirable. Both ext-info-c and ext-info-s SHOULD be implemented.
[RFC8308]で定義されている2つの方法、ext-info-cとext-info-sがあります。それらは他の安全なシェル交渉をサポートするためのメカニズムを提供します。機能を拡張することができることが望ましいです。EXT-INFO-CとEXT-INFO-Sの両方を実装する必要があります。
Table 12 provides the existing key exchange method names listed alphabetically. The Implement column contains the current recommendations of this RFC.
表12は、アルファベット順にリストされている既存の鍵交換方法名を示しています。実装列には、このRFCの現在の推奨事項が含まれています。
+=======================+============+================+===========+
| Key Exchange Method | Reference | Previous | RFC 9142 |
| Name | | Recommendation | Implement |
+=======================+============+================+===========+
| curve25519-sha256 | [RFC8731] | none | SHOULD |
+-----------------------+------------+----------------+-----------+
| curve448-sha512 | [RFC8731] | none | MAY |
+-----------------------+------------+----------------+-----------+
| diffie-hellman-group- | [RFC4419], | none | SHOULD |
| exchange-sha1 | [RFC8270] | | NOT |
+-----------------------+------------+----------------+-----------+
| diffie-hellman-group- | [RFC4419], | none | MAY |
| exchange-sha256 | [RFC8270] | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC4253] | MUST | SHOULD |
| group1-sha1 | | | NOT |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC4253] | MUST | MAY |
| group14-sha1 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MUST |
| group14-sha256 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MAY |
| group15-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | SHOULD |
| group16-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MAY |
| group17-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MAY |
| group18-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-* | [RFC5656] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp256 | [RFC5656] | MUST | SHOULD |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp384 | [RFC5656] | MUST | SHOULD |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp521 | [RFC5656] | MUST | SHOULD |
+-----------------------+------------+----------------+-----------+
| ecmqv-sha2 | [RFC5656] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| ext-info-c | [RFC8308] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| ext-info-s | [RFC8308] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss- | [RFC4462] | reserved | reserved |
+-----------------------+------------+----------------+-----------+
| gss- | [RFC8732] | SHOULD | SHOULD |
| curve25519-sha256-* | | | |
+-----------------------+------------+----------------+-----------+
| gss-curve448-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-gex-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | [RFC8732] | | NOT |
+-----------------------+------------+----------------+-----------+
| gss-group1-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | [RFC8732] | | NOT |
+-----------------------+------------+----------------+-----------+
| gss-group14-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | [RFC8732] | | NOT |
+-----------------------+------------+----------------+-----------+
| gss-group14-sha256-* | [RFC8732] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss-group15-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-group16-sha512-* | [RFC8732] | SHOULD | MAY |
+-----------------------+------------+----------------+-----------+
| gss-group17-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-group18-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-nistp256-sha256-* | [RFC8732] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss-nistp384-sha384-* | [RFC8732] | MAY | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss-nistp521-sha512-* | [RFC8732] | MAY | SHOULD |
+-----------------------+------------+----------------+-----------+
| rsa1024-sha1 | [RFC4432] | MAY | MUST NOT |
+-----------------------+------------+----------------+-----------+
| rsa2048-sha256 | [RFC4432] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
Table 12: IANA Guidance for Implementation of Key Exchange Method Names
表12：鍵交換方法名の実装のためのIANAガイダンス
The full set of official [IANA-SSH] "Key Exchange Method Names" not otherwise mentioned in this document MAY be implemented.
この文書では記載されていない「IANA-SSH」「鍵交換方法名」のフルセットを実装することができる。
This SSH protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity checks. It also derives a unique session ID that may be used by higher-level protocols. The key exchange itself generates a shared secret and uses the hash function for both the KDF and integrity.
このSSHプロトコルは、安全でないネットワークを介して安全な暗号化されたチャネルを提供します。サーバーホスト認証、鍵交換、暗号化、および整合性チェックを実行します。高レベルのプロトコルで使用できる固有のセッションIDも導出されます。鍵交換自体は共有秘密を生成し、KDFと整合性の両方にハッシュ関数を使用します。
Full security considerations for this protocol are provided in [RFC4251] and continue to apply. In addition, the security considerations provided in [RFC4432] apply. Note that Forward Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key exchanges.
このプロトコルの完全なセキュリティ上の考慮事項は[RFC4251]に記載されており、申請を続けています。また、[RFC4432]で提供されているセキュリティ上の考慮事項が適用されます。RSA1024-SHA1またはRSA2048-SHA256キー交換では、前方秘密が利用できません。
It is desirable to deprecate or disallow key exchange methods that are considered weak so they are not still actively in operation when they are broken.
故障しているため、故障しているときに積極的に動作していないため、鍵交換方法を非推奨または許可しないことが望ましい。
A key exchange method is considered weak when the security strength is insufficient to match the symmetric cipher or the algorithm has been broken.
鍵交換方法は、セキュリティ強度が対称暗号またはアルゴリズムに一致するのに不十分である場合に弱いと見なされます。
The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too small for the symmetric ciphers used in SSH.
diffie-hellman-group1-sha1によって使用される1024ビットのMODPグループは、SSHで使用される対称暗号には小さすぎます。
MODP groups with a modulus size less than 2048 bits are too small for the symmetric ciphers used in SSH. If the diffie-hellman-group-exchange-sha256 or diffie-hellman-group-exchange-sha1 key exchange method is used, the modulus size of the MODP group used needs to be at least 2048 bits.
モジュラスサイズが2048ビット未満のMODPグループは、SSHで使用される対称暗号には小さすぎます。Diffie-Hellman-Group-Exchange-SHA256またはDIFFIE-HELLMAN-GROUP-Exchange-SHA1キー交換方法が使用されている場合、使用されるMODPグループのモジュラスサイズは少なくとも2048ビットである必要があります。
At this time, the rsa1024-sha1 key exchange is too small for the symmetric ciphers used in SSH.
このとき、SSHで使用される対称暗号には、RSA1024-SHA1のキー交換が小さすぎます。
The use of SHA-1 for use with any key exchange may not yet be completely broken, but it is time to retire all uses of this algorithm as soon as possible.
鍵交換と一緒に使用するためのSHA-1の使用はまだ完全に壊れていないかもしれませんが、できるだけ早くこのアルゴリズムのすべての用途を引退する時が来ました。
The diffie-hellman-group14-sha1 algorithm is not yet completely deprecated. This is to provide a practical transition from the MTI algorithms to a new one. However, it would be best to only be used as a last resort in key exchange negotiations. All key exchange methods using the SHA-1 hash are to be considered as deprecated.
diffie-hellman-group14-sha1アルゴリズムはまだ完全に推奨されていません。これは、MTIアルゴリズムから新しいものへの実用的な遷移を提供することです。しかし、主要な交換交渉の最後の手段としてのみ使用されることが最善です。SHA-1ハッシュを使用したすべての鍵交換方法は、廃止予定と見なされます。
IANA has added a new column to the "Key Exchange Method Names" registry [IANA-SSH] with the heading "OK to Implement" and annotated entries therein with the implementation guidance provided in Section 4, "Summary Guidance for Implementation of Key Exchange Method Names", in this document. IANA also added entries for ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521, and added references to [RFC4462] and [RFC8732] for gss-gex-sha1-*, gss-group1-sha1-*, gss-group14-sha1-*, diffie-hellman-group-exchange-sha1, and diffie-hellman-group-exchange-sha256. A summary may be found in Table 12 in Section 4. IANA has also included this document as an additional registry reference for the suggested implementation guidance provided in Section 4 of this document and added a note indicating the following:
IANAは「鍵交換方法名」レジストリ[IANA-SSH]に「鍵交換方法名」レジストリ[IANA-SSH]に追加しました。この文書では、名前 "。IANAはまた、ECDH-SHA2-NISTP256、ECDH-SHA2-NISTP384、ECDH-SHA2-NISTP521のエントリーを追加し、GSS-gex-sha1- *、GSS-Group1-SHA1-の場合の[RFC4462]および[RFC8732]への参照を追加しました。*、GSS-GROUP14-SHA1- *、Diffie-Hellman-Group-Exchange-SHA1、およびDiffie-Hellman-Group-Exchange-SHA256。この文書のセクション4に記載されている提案された実装ガイダンスのための追加のレジストリ参照として、このドキュメントを追加のレジストリ参照として追加し、次のことを示すメモを追加しました。
| OK to Implement guidance entries for registrations that pre-date | [RFC9142] are found in Table 12 in Section 4 of [RFC9142].
| ..プレースされた登録のためのガイダンスエントリを実装するのはOK[RFC9142] [RFC9142]のセクション4の表12にあります。
Registry entries annotated with "MUST NOT" are considered disallowed. Registry entries annotated with "SHOULD NOT" are deprecated and may be disallowed in the future.
「必須ではない」と注釈されたレジストリエントリは、許可されていないと見なされます。「しない」と注釈が付けられたレジストリエントリは推奨されており、将来的には許可されている可能性があります。
[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>。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.
[RFC4250] Lehtinen、S.およびC. Lonvick、Ed。、「セキュアシェル（SSH）プロトコル割り当て番号」、RFC 4250、DOI 10.17487 / RFC4250、2006年1月、<https：//www.rfc-editor.org/ info / rfc4250>。
[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>。
[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>。
[RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, <https://www.rfc-editor.org/info/rfc8270>.
[RFC8270] Velvindron、L.およびM.Baushke、「セキュアシェル最小推奨Diffie-Hellmanモジュラスサイズを2048ビットに増やす」、RFC 8270、DOI 10.17487 / RFC8270、2017年12月、<https：//www.rfc-編集者.org / info / rfc8270>。
[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>。
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, <https://www.rfc-editor.org/info/rfc8731>.
[RFC8731] Adamantiadis、A.、Josefsson、S.、およびM.Baushke、Curve25519およびCurve448を使用した「セキュアシェル（SSH）キー交換方法、RFC 8731、DOI 10.17487 / RFC8731、2020年2月、<https：// www.rfc-editor.org / info / rfc8731>。
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters", <https://www.iana.org/assignments/ssh-parameters/>.
[IANA-SSH] IANA、「セキュアシェル（SSH）プロトコルパラメータ」、<https：//www.iana.org/ashignments/ssh-parameters/>。
[NIST.FIPS.202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
[NIST.FIPS.202]国立標準技術研究所、「SHA-3標準：順列ベースのハッシュおよび拡張可能出力関数」、FIPS PUB 202、DOI 10.6028 / NIST.FIPS.FIPS.FIPS.202、<HTTPS：//doi.org/10.6028/nist.fips.202>。
[NIST.SP.800-107r1] Dang, Q., "Recommendation for applications using approved hash algorithms", DOI 10.6028/NIST.SP.800-107r1, August 2012, <https://doi.org/10.6028/NIST.SP.800-107r1>.
[NIST.SP.800-107R1] Dang、Q.、承認されたハッシュアルゴリズムを使用したアプリケーションの推奨事項、DOI 10.6028 / NIST.SP.800-107R1、<https：//doi.org/10.6028/nist.SP.800-107R1>。
[NIST.SP.800-57pt1r5] Barker, E., "Recommendation for Key Management: Part 1 - General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[NIST.SP.800-57PT1R5] Barker、E.、「鍵管理のための推奨事項：第1部 - 一般」、DOI 10.6028 / NIST.SP.800-57PT1R5、<https：//doi.org/10.6028/nist.sp.800-57pt1r5>。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, <https://www.rfc-editor.org/info/rfc2409>.
[RFC2409] Harkins、D.およびD. Carrele、「インターネット鍵交換（IKE）」、RFC 2409、DOI 10.17487 / RFC2409、1998年11月、<https：//www.rfc-editor.org/info/rfc2409>。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <https://www.rfc-editor.org/info/rfc3526>.
[RFC3526] Kivinen、T.およびM. kojo、「インターネット鍵交換（IKE）」、RFC 3526、DOI 10.17487 / RFC3526、DIFI 10.17487 / RFC3526、<https：// www。rfc-editor.org/info/rfc3526>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.ORG / INFO / RFC4086>。
[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>。
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <https://www.rfc-editor.org/info/rfc4419>.
[RFC4419] Friedl、M.、Propos、N.およびW.Simpson、「セキュアシェル（SSH）トランスポート層プロトコルのためのDiffie-Hellman Group Exchange」、RFC 4419、DOI 10.17487 / RFC4419、2006年3月、<https：//www.rfc-editor.org/info/rfc4419>。
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, March 2006, <https://www.rfc-editor.org/info/rfc4432>.
[RFC4432]ハリス、B.、「セキュアシェル（SSH）トランスポート層プロトコルのRSAキー交換」、RFC 4432、DOI 10.17487 / RFC4432、2006年3月、<https：//www.rfc-editor.org/info/RFC4432>。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 2006, <https://www.rfc-editor.org/info/rfc4462>.
[RFC4462] Hutzelman、J.、Salowey、J.、Galbraith、J.、およびV.ウェルチ、「一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）認証およびSecure Shell（SSH）プロトコルの鍵交換」、RFC4462、DOI 10.17487 / RFC4462、2006年5月、<https：//www.rfc-editor.org/info/rfc4462>。
[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>。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <https://www.rfc-editor.org/info/rfc6194>.
[RFC6194] Polk、T.、Chen、L.、Turner、S.、およびP.Hoffman、「SHA-0およびSHA-1メッセージ - ダイジェストアルゴリズムのセキュリティ上の考慮事項」、RFC 6194、DOI 10.17487 / RFC6194、3月2011年、<https://www.rfc-editor.org/info/rfc6194>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]イーストレイク3RD、D.およびT.ハンセン、「米国セキュアハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：///www.rfc-editor.org/info/rfc6234>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748] Langley、A.、Hamburg、M.、およびS.ターナー、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<https：//www.rfc-editor.org/info/ RFC7748>。
[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, <https://www.rfc-editor.org/info/rfc8031>.
[RFC8031] NIR、Y.およびS. Josefsson、「Interne Key Exchange Protocol Version 2（IKEV2）キー契約のためのCurve25519およびCurven448」、RFC 8031、DOI 10.17487 / RFC8031、2016年12月、<https：//www.rfc-editor.org/info/rfc8031>。
[RFC8732] Sorce, S. and H. Kario, "Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, <https://www.rfc-editor.org/info/rfc8732>.
[RFC8732] SORCE、S.およびH。Kario、「一般セキュリティサービスアプリケーションプログラムインタフェース（GSS-API）キー交換、RFC 8732、DOI 10.17487 / RFC8732、2020年2月、<https：// www。rfc-editor.org/info/rfc8732>。
[TRANSCRIPTION] Bhargavan, K. and G. Leurent, "Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH", Network and Distributed System Security Symposium (NDSS), DOI 10.14722/ndss.2016.23418, February 2016, <https://doi.org/10.14722/ndss.2016.23418>.
[転写] Bhargavan、K.およびG.創立、「トランスクリプト衝突攻撃：TLS、IKE、SSHの認証」、ネットワークおよび分散システムセキュリティシンポジウム（NDS）、DOI 10.14722 / NDSS.2016.23418、2016年2月、<HTTPS//doi.org/10.14722/ndss.2016.23418>。
Acknowledgements
謝辞
Thanks to the following people for review and comments: Denis Bider, Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, Tero Kivinen, and Travis Finkenauer.
レビューやコメントのための以下の人々のおかげで：Denis Bider、Peter Gutmann、Damien Miller、Niels Moeller、Matt Joesefsson、Matt Joesefsson、Dave Dugal、Daniel Migault、Anna Johnston、Tero Kivenenauer、Tero Kivenenauer。
Thanks to the following people for code to implement interoperable exchanges using some of these groups as found in this document: Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh), and Poderosa implementations also adopting new Diffie-Hellman groups based on this document.
この文書に記載されているこれらのグループのいくつかを使用して相互運用可能な交換を実装するためのコードのための以下の人々のおかげで：DRENBEARのためのOpenSSHおよびMatt JohnstonのためのDarren Tucker。そしてRlogin、Tera Term（TTSSH）、およびPoderosaの実装については、この文書に基づいて新しいDiffie-Hellmanグループを採用しています。
Author's Address
作者の住所
Mark D. Baushke
マークD. Baushke.
Email: mbaushke.ietf@gmail.com