[要約] 要約： RFC 8268は、SSHのためのMODP Diffie-Hellmanキー交換グループの拡張を提供し、よりモジュラーな指数計算を可能にする。目的： 1. SSHのセキュリティを向上させるために、MODP Diffie-Hellmanキー交換グループを拡張する。 2. よりモジュラーな指数計算をサポートすることで、効率的な鍵交換を実現する。 3. セキュリティプロトコルの進化に対応するため、新しいMODP Diffie-Hellmanグループを導入する。
Internet Engineering Task Force (IETF) M. Baushke
Request for Comments: 8268 Juniper Networks, Inc.
Updates: 4250, 4253 December 2017
Category: Standards Track
ISSN: 2070-1721
More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
セキュアシェル（SSH）向けのModular Exponentiation（MODP）Diffie-Hellman（DH）Key Exchange（KEX）グループの追加
Abstract
概要
This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.
このドキュメントでは、SHA-2ハッシュを使用するセキュアシェル（SSH）プロトコル用に追加されたModular Exponentiation（MODP）グループを定義します。このドキュメントはRFC 4250を更新します。このドキュメントは、ピアのDH公開鍵のチェックに関するエラーを修正することにより、RFC 4253を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8268.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8268で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4
4. Checking the Peer's DH Public Key . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
Secure Shell (SSH) is a common protocol for secure communication on the Internet. Security protocols and primitives are an active area for research and help to suggest updates to SSH.
Secure Shell（SSH）は、インターネット上の安全な通信のための一般的なプロトコルです。セキュリティプロトコルとプリミティブは、研究の活発な領域であり、SSHの更新を提案するのに役立ちます。
Section 8 of [RFC4253] contains a small error in point 3 regarding checking the Peer's DH Public Key. Section 4 of this document provides the correction.
[RFC4253]のセクション8には、ピアのDH公開鍵の確認に関するポイント3の小さなエラーが含まれています。このドキュメントのセクション4は修正を提供します。
Due to security concerns with SHA-1 [RFC6194] and with MODP groups with less than 2048 bits [NIST-SP-800-131Ar1], implementers and users should request support for larger Diffie-Hellman (DH) MODP group sizes with data-integrity verification by using the SHA-2 family of secure hash algorithms and by having MODP groups provide more security. The use of larger MODP groups and the move to the SHA-2 family of hashes are important features to strengthen the key exchange algorithms available to the SSH client and server.
SHA-1 [RFC6194]および2048ビット未満のMODPグループ[NIST-SP-800-131Ar1]のセキュリティ上の懸念により、実装者とユーザーは、データ付きのより大きなDiffie-Hellman（DH）MODPグループサイズのサポートを要求する必要があります。セキュアハッシュアルゴリズムのSHA-2ファミリを使用し、MODPグループにセキュリティを提供させることによる整合性検証。より大きなMODPグループの使用と、SHA-2ファミリーのハッシュへの移行は、SSHクライアントとサーバーで使用できる鍵交換アルゴリズムを強化するための重要な機能です。
DH primes being adopted by this document are all "safe primes" such that p = 2q + 1 where q is also a prime. New MODP groups are being introduced starting with the MODP 3072-bit group15. All use SHA512 as the hash algorithm.
このドキュメントで採用されているDH素数は、すべてpが2q + 1であるような「安全な素数」であり、qも素数です。新しいMODPグループは、MODP 3072ビットグループ15から導入されています。すべてハッシュアルゴリズムとしてSHA512を使用します。
The DH 2048-bit MODP group14 is already present in most SSH implementations and most implementations already have a SHA256 implementation, so "diffie-hellman-group14-sha256" is provided as easy to implement.
DH 2048ビットMODP group14はすでにほとんどのSSH実装に存在しており、ほとんどの実装にはすでにSHA256実装があるため、「diffie-hellman-group14-sha256」は実装が簡単なものとして提供されています。
It is intended that these new MODP groups with SHA-2-based hashes update Section 6.4 of [RFC4253] and Section 4.10 of [RFC4250].
SHA-2ベースのハッシュを持つこれらの新しいMODPグループは、[RFC4253]のセクション6.4および[RFC4250]のセクション4.10を更新することを目的としています。
The United States Information Assurance Directorate (IAD) at the National Security Agency (NSA) has published "Commercial National Security Algorithm Suite and Quantum Computing Frequently Asked Questions". [MFQ-U-OO-815099-15] is addressed to organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS.
国家安全保障局（NSA）の米国情報保証局（IAD）は、「商用国家安全保障アルゴリズムスイートと量子コンピューティングに関するよくある質問」を公開しています。 [MFQ-U-OO-815099-15]は、機密または未分類の国家安全保障システム（NSS）を実行する組織と、NSSで使用される製品を構築するベンダーを対象としています。
This FAQ document indicates that NSS should no longer use:
このFAQドキュメントは、NSSが使用しないことを示しています。
o Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) with NIST P-256. (For SSH, this would suggest avoiding [RFC5656] Key Exchange Algorithm "ecdh-sha2-nistp256" and Public Key Algorithm "ecdsa-sha2-nistp256".)
o 楕円曲線Diffie-Hellman（ECDH）およびNIST P-256を使用した楕円曲線デジタル署名アルゴリズム（ECDSA）。 （SSHの場合、これは[RFC5656]鍵交換アルゴリズム「ecdh-sha2-nistp256」および公開鍵アルゴリズム「ecdsa-sha2-nistp256」を回避することをお勧めします。）
o SHA-256 (For SSH, this would suggest avoiding any Key Exchange Method using SHA1, SHA224, or SHA256 in favor of using SHA384 or SHA512.)
o SHA-256（SSHの場合、これは、SHA384またはSHA512を使用する代わりに、SHA1、SHA224、またはSHA256を使用する鍵交換方式を回避することをお勧めします。）
o AES-128 (For SSH, this would suggest avoiding Encryption Algorithms [RFC4253] "aes128-cbc" and [RFC4344] "aes128-ctr".)
o AES-128（SSHの場合、これは暗号化アルゴリズム[RFC4253] "aes128-cbc"および[RFC4344] "aes128-ctr"を回避することをお勧めします。）
o RSA with 2048-bit keys (For SSH, this would suggest avoiding [RFC4253] "ssh-rsa" using RSA with SHA1 as well as [RFC6187] "x509v3-rsa2048-sha256" as well as any other RSA key that has a length less than 3072-bits or uses a hash less than SHA384.)
o 2048ビットキーを使用するRSA（SSHの場合、これは[RFC4253] "ssh-rsa"とRSAをSHA1とともに使用すること、および[RFC6187] "x509v3-rsa2048-sha256"と他の長さのRSAキーを使用しないことをお勧めします3072ビット未満、またはSHA384未満のハッシュを使用します。）
o Diffie-Hellman with 2048-bit keys (For SSH, this would suggest avoiding use of [RFC4253] both of "diffie-hellman-group1-sha1" and "diffie-hellman-group14-sha1" as well as avoiding "diffie-hellman-group14-sha256" added by this document.)
o 2048ビットキーのDiffie-Hellman（SSHの場合、これは[RFC4253]の「diffie-hellman-group1-sha1」と「diffie-hellman-group14-sha1」の両方の使用を避け、「diffie-hellmanこのドキュメントによって追加された-group14-sha256」）。
The FAQ also states that NSS users should select DH groups based upon well-established and validated parameter sets that comply with the minimum required sizes. Some specific examples include:
FAQには、NSSユーザーは、最低限必要なサイズに準拠し、十分に確立され検証されたパラメーターセットに基づいてDHグループを選択する必要があることも記載されています。いくつかの具体的な例は次のとおりです。
o Elliptic Curves are currently restricted to the NIST P-384 group only for both ECDH and ECDSA, in accordance with existing NIST and National Information Assurance Partnership (NIAP) standards. (For SSH, this means using [RFC5656] "ecdh-sha2-nistp384" for key exchange and "ecdsa-sha2-nistp384" for Public Key Algorithm Names.)
o 楕円曲線は現在、既存のNISTおよびNational Information Assurance Partnership（NIAP）標準に従って、ECDHとECDSAの両方についてのみNIST P-384グループに制限されています。 （SSHの場合、これはキー交換に[RFC5656] "ecdh-sha2-nistp384"を使用し、公開鍵アルゴリズム名に "ecdsa-sha2-nistp384"を使用することを意味します。）
o RSA moduli should have a minimum size of 3072 bits (other than the noted PKI exception), and keys should be generated in accordance with all relevant NIST standards.
o RSAモジュライの最小サイズは3072ビット（上記のPKI例外を除く）である必要があり、鍵はすべての関連するNIST標準に従って生成される必要があります。
o For Diffie-Hellman, use a Diffie-Hellman prime modulus of at least 3072 bits. (For bit sizes as specified in [RFC3526], this would allow for any of group15, group16, group17, group18 to be used.)
o Diffie-Hellmanの場合、少なくとも3072ビットのDiffie-Hellman素数係数を使用します。 （[RFC3526]で指定されているビットサイズの場合、これにより、group15、group16、group17、group18のいずれかを使用できます。）
Although SSH may not always be used to protect Top Secret communications, this document adopts the use of the DH groups provided as an example in the FAQ as well as the use of SHA512 rather than SHA256 for the new DH groups.
SSHは常にトップシークレット通信の保護に使用されるとは限りませんが、このドキュメントでは、FAQで例として提供されているDHグループの使用と、新しいDHグループのSHA256ではなくSHA512の使用を採用しています。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document adds some new Key Exchange Algorithm Method Names to what originally appeared in [RFC4253] and [RFC4250].
このドキュメントは、[RFC4253]と[RFC4250]で最初に登場したものにいくつかの新しいキー交換アルゴリズムメソッド名を追加します。
This document adopts the style and conventions of [RFC4253] in specifying how the use of new data key exchange is indicated in SSH.
このドキュメントは、SSHで新しいデータキー交換の使用がどのように示されるかを指定する際に、[RFC4253]のスタイルと規則を採用しています。
The following new key exchange method algorithms are defined:
以下の新しい鍵交換方式アルゴリズムが定義されています。
o diffie-hellman-group14-sha256
o diffie-hellman-group14-sha256
o diffie-hellman-group15-sha512
o diffie-hellman-group15-sha512
o diffie-hellman-group16-sha512
o diffie-hellman-group16-sha512
o diffie-hellman-group17-sha512
o diffie-hellman-group17-sha512
o diffie-hellman-group18-sha512
o diffie-hellman-group18-sha512
The SHA-2 family of secure hash algorithms is defined in [RFC6234].
セキュアハッシュアルゴリズムのSHA-2ファミリは、[RFC6234]で定義されています。
The method of key exchange used for the name "diffie-hellman-group14-sha256" is the same as that for "diffie-hellman-group14-sha1" except that the SHA256 hash algorithm is used. It is recommended that "diffie-hellman-group14-sha256" SHOULD be supported to smooth the transition to newer group sizes.
「diffie-hellman-group14-sha256」という名前に使用される鍵交換の方法は、SHA256ハッシュアルゴリズムが使用されることを除いて、「diffie-hellman-group14-sha1」と同じです。新しいグループサイズへの移行をスムーズにするために、「diffie-hellman-group14-sha256」をサポートする必要があります（SHOULD）。
The group15 through group18 names are the same as those specified in [RFC3526]: 3072-bit MODP group15, 4096-bit MODP group16, 6144-bit MODP group17, and 8192-bit MODP group18.
group15からgroup 18までの名前は、[RFC 3526]で指定されているものと同じです：3072ビットMODP group15、4096ビットMODP group16、6144ビットMODP group17、および8192ビットMODP group18。
The SHA512 algorithm is to be used when "sha512" is specified as a part of the key exchange method name.
SHA512アルゴリズムは、「sha512」が鍵交換メソッド名の一部として指定されている場合に使用されます。
Section 8 of [RFC4253] contains a small error in point 3. When checking e (client Public Key) and f (server Public Key) values, an incorrect range is provided. The erroneous text is:
[RFC4253]のセクション8のポイント3に小さなエラーが含まれています。e（クライアントの公開鍵）とf（サーバーの公開鍵）の値をチェックすると、誤った範囲が提供されます。エラーのあるテキストは次のとおりです。
Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be sent or accepted by either side. If this condition is violated, the key exchange fails.
[1、p-1]の範囲にない「e」または「f」の値は、どちらの側からも送信または受け入れてはなりません。この条件に違反すると、鍵の交換が失敗します。
The problem is that the range should have been an open interval excluding the endpoint values. (i.e., "(1, p-1)"). This document amends that document text as follows:
問題は、範囲がエンドポイント値を除いたオープンインターバルである必要があることです。 （つまり、「（1、p-1）」）。このドキュメントは、そのドキュメントテキストを次のように修正します。
DH Public Key values MUST be checked and both conditions:
DH公開鍵の値を確認する必要があり、両方の条件：
1 < e < p-1
1 <e <p-1
1 < f < p-1
1 <f <p-1
MUST be true. Values not within these bounds MUST NOT be sent or accepted by either side. If either one of these conditions is violated, then the key exchange fails.
本当でなければなりません。これらの境界内にない値は、どちらの側からも送信または受け入れてはなりません。これらの条件のいずれかに違反すると、鍵の交換は失敗します。
This simple check ensures that:
この簡単なチェックにより、次のことが保証されます。
o The remote peer behaves properly.
o リモートピアは正しく動作します。
o The local system is not forced into the two-element subgroup.
o ローカルシステムは2要素のサブグループに強制されません。
IANA has added the following entries to the "Key Exchange Method Names" registry [IANA-KEX]:
IANAは、「キー交換メソッド名」レジストリ[IANA-KEX]に次のエントリを追加しました。
Method Name Reference
----------------------------- ---------
diffie-hellman-group14-sha256 RFC 8268
diffie-hellman-group15-sha512 RFC 8268
diffie-hellman-group16-sha512 RFC 8268
diffie-hellman-group17-sha512 RFC 8268
diffie-hellman-group18-sha512 RFC 8268
The security considerations of [RFC4253] apply to this document.
[RFC4253]のセキュリティに関する考慮事項がこのドキュメントに適用されます。
The security considerations of [RFC3526] suggest that MODP group14 through group18 have security strengths that range between 110 bits of security through 310 bits of security. They are based on "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys" [RFC3766]. Care should be taken to use sufficient entropy and/ or deterministic random-bit generator (DRBG) algorithms to maximize the true security strength of the key exchange and ciphers selected.
[RFC3526]のセキュリティに関する考慮事項は、MODPグループ14からグループ18までのセキュリティ強度が110ビットから310ビットの範囲であることを示唆しています。それらは、「対称鍵の交換に使用される公開鍵の強度の決定」[RFC3766]に基づいています。十分なエントロピーおよび/または確定的ランダムビットジェネレーター（DRBG）アルゴリズムを使用して、選択したキー交換および暗号の真のセキュリティ強度を最大化するように注意する必要があります。
Using a fixed set of Diffie-Hellman parameters makes them a high value target for pre-computation. Generating additional sets of primes to be used, or moving to larger values mitigates this issue.
Diffie-Hellmanパラメータの固定セットを使用すると、事前計算のターゲットとして高い値になります。使用する素数の追加セットを生成するか、より大きな値に移動すると、この問題が軽減されます。
[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>。
[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）のためのその他のModular Exponential（MODP）Diffie-Hellmanグループ」、RFC 3526、DOI 10.17487 / RFC3526、2003年5月、<https：// www。 rfc-editor.org/info/rfc3526>。
[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、編、「The Secure Shell（SSH）Protocol Assigned Numbers」、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、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<https://www.rfc-editor.org / info / rfc4253>。
[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] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：//www.rfc- editor.org/info/rfc6234>。
[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>。
[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters",
<http://www.iana.org/assignments/ssh-parameters/>
[MFQ-U-OO-815099-15] National Security Agency / Central Security Service, "Commerical National Security Algorithm Suite and Quantum Computing FAQ", MFQ U/OO/815099-15 , January 2016, <https://www.iad.gov/iad/library/ia-guidance/ ia-solutions-for-classified/algorithm-guidance/assets/public/upload/ CNSA-Suite-and-Quantum-Computing-FAQ.pdf>.
[MFQ-U-OO-815099-15]国家安全保障局/中央安全保障局、「商用国家安全保障アルゴリズムスイートおよび量子コンピューティングFAQ」、MFQ U / OO / 815099-15、2016年1月、<https：// www。 iad.gov/iad/library/ia-guidance/ ia-solutions-for-classified / algorithm-guidance / assets / public / upload / CNSA-Suite-and-Quantum-Computing-FAQ.pdf>。
[NIST-SP-800-131Ar1] Barker and Roginsky, "Transitions: Recommendation for the Transitioning of the Use of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A, Revision 1, DOI 10.6028/NIST.SP.800-131Ar1, November 2015, <http://dx.doi.org/10.6028/NIST.SP.800-131Ar1>.
[NIST-SP-800-131Ar1] BarkerとRoginsky、「移行：暗号化アルゴリズムとキー長の使用の移行に関する推奨事項」、NIST Special Publication 800-131A、Revision 1、DOI 10.6028 / NIST.SP.800- 131Ar1、2015年11月、<http://dx.doi.org/10.6028/NIST.SP.800-131Ar1>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <https://www.rfc-editor.org/info/rfc3766>.
[RFC3766] Orman、H。およびP. Hoffman、「Determining Strengths for Public Keys Exchangeing Symmetric Keys」、BCP 86、RFC 3766、DOI 10.17487 / RFC3766、2004年4月、<https：//www.rfc-editor。 org / info / rfc3766>。
[RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, DOI 10.17487/RFC4344, January 2006, <https://www.rfc-editor.org/info/rfc4344>.
[RFC4344] Bellare、M.、Kohno、T。、およびC. Namprempre、「Secure Shell（SSH）Transport Layer Encryption Modes」、RFC 4344、DOI 10.17487 / RFC4344、2006年1月、<https：//www.rfc -editor.org/info/rfc4344>。
[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、「Secure Shell Transport Layerにおける楕円曲線アルゴリズムの統合」、RFC 5656、DOI 10.17487 / RFC5656、2009年12月、<https://www.rfc-editor.org/info / rfc5656>。
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6187] Igoe、K。およびD. Stebila、「Secure Shell AuthenticationのX.509v3証明書」、RFC 6187、DOI 10.17487 / RFC6187、2011年3月、<https://www.rfc-editor.org/info/rfc6187 >。
[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>。
Acknowledgements
謝辞
Thanks to the following people for review and comments: Denis Bider, Peter Gutmann, Damien Miller, Niels Moller, Matt Johnston, Iwamoto Kouichi, Dave Dugal, Daniel Migault, Anna Johnston, Ron Frederick, Rich Salz, Travis Finkenauer, and Eric Rescorla.
レビューとコメントをいただいた次の方々に感謝します。デニス・バイダー、ピーター・グットマン、ダミアン・ミラー、ニールス・モラー、マット・ジョンストン、岩本浩一、デイブ・デュガル、ダニエル・ミゴー、アンナ・ジョンストン、ロン・フレデリック、リッチ・サルツ、トラビス・フィンケナウアー、エリック・レスコーラ
Author's Address
著者のアドレス
Mark D. Baushke Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, CA 94089-1228 United States of America
Mark D. Baushke Juniper Networks、Inc. 1133 Innovation Way Sunnyvale、CA 94089-1228アメリカ合衆国
Phone: +1 408 745 2952
Email: mdb@juniper.net
URI: http://www.juniper.net/