RFC 4419 - Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4419
タイトル : RFC 4419 - セキュアシェル（SSH）輸送層プロトコルのディフェヘルマングループ交換
翻訳編集 : 自動生成

[要約] RFC 4419は、SSHトランスポート層プロトコルのためのDiffie-Hellmanグループ交換に関する仕様です。このRFCの目的は、SSHセッションのセキュリティを向上させるために、Diffie-Hellman鍵交換アルゴリズムを使用する方法を提供することです。

Network Working Group                                          M. Friedl
Request for Comments: 4419                                     N. Provos
Category: Standards Track                                     W. Simpson
                                                              March 2006

Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol

セキュアシェル（SSH）輸送層プロトコルのディフェヘルマングループ交換

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time.

このメモは、安全なシェル（SSH）プロトコルの新しいキー交換方法について説明しています。これにより、SSHサーバーは、クライアントにDiffie-Hellmanキーエクスチェンジを実行する新しいグループを提案できます。提案されたグループは修正する必要はなく、時間とともに変化する可能性があります。

1. Overview and Rationale

1. 概要と根拠

SSH [RFC4251] is a very common protocol for secure remote login on the Internet. Currently, SSH performs the initial key exchange using the "diffie-hellman-group1-sha1" method [RFC4253]. This method prescribes a fixed group on which all operations are performed.

SSH [RFC4251]は、インターネット上の安全なリモートログインのための非常に一般的なプロトコルです。現在、SSHは「diffie-hellman-group1-sha1」メソッド[RFC4253]を使用して初期キー交換を実行しています。この方法は、すべての操作が実行される固定グループを規定しています。

The Diffie-Hellman key exchange provides a shared secret that cannot be determined by either party alone. Furthermore, the shared secret is known only to the participant parties. In SSH, the key exchange is signed with the host key to provide host authentication.

Diffie-Hellman Key Exchangeは、どちらの当事者だけでも決定できない共有秘密を提供します。さらに、共有された秘密は、参加者のみに知られています。SSHでは、キーエクスチェンジがホストキーに署名され、ホスト認証を提供します。

The security of the Diffie-Hellman key exchange is based on the difficulty of solving the Discrete Logarithm Problem (DLP). Since we expect that the SSH protocol will be in use for many years in the future, we fear that extensive precomputation and more efficient algorithms to compute the discrete logarithm over a fixed group might pose a security threat to the SSH protocol.

Diffie-Hellman Key Exchangeのセキュリティは、離散対数問題（DLP）を解決することの難しさに基づいています。SSHプロトコルが将来何年も使用されると予想されるため、固定グループ上で離散対数を計算するための広範な事前計算とより効率的なアルゴリズムがSSHプロトコルにセキュリティの脅威をもたらす可能性があることを恐れています。

The ability to propose new groups will reduce the incentive to use precomputation for more efficient calculation of the discrete logarithm. The server can constantly compute new groups in the background.

新しいグループを提案する能力は、離散対数のより効率的な計算のために事前計算を使用するインセンティブを減らします。サーバーは、バックグラウンドで常に新しいグループを計算できます。

2. Requirements Notation

2. 要件表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

3. Diffie-Hellman Group and Key Exchange

3. Diffie-Hellman GroupとKey Exchange

The server keeps a list of safe primes and corresponding generators that it can select from. A prime p is safe if p = 2q + 1 and q is prime. New primes can be generated in the background.

サーバーは、安全な素数と選択できる対応するジェネレーターのリストを保持します。P = 2Q 1、Qがプライムの場合、プライムPは安全です。新しいプライムをバックグラウンドで生成できます。

The generator g should be chosen such that the order of the generated subgroup does not factor into small primes; that is, with p = 2q + 1, the order has to be either q or p - 1. If the order is p - 1, then the exponents generate all possible public values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is "safe").

発電機Gは、生成されたサブグループの順序が小さなプライムに考慮されないように選択する必要があります。つまり、p = 2q 1では、順序はqまたはp -1のいずれかでなければなりません。順序がp -1の場合、指数はすべての可能なパブリック値を生成し、自転車なしでモジュラスPの範囲全体に均等に分布します。より小さなサブセットを介して。このようなジェネレーターは、「プリミティブルート」と呼ばれます（これは、Pが「安全」であるときに見つけるのは簡単です）。

The client requests a modulus from the server indicating the preferred size. In the following description (C is the client, S is the server, the modulus p is a large safe prime, and g is a generator for a subgroup of GF(p), min is the minimal size of p in bits that is acceptable to the client, n is the size of the modulus p in bits that the client would like to receive from the server, max is the maximal size of p in bits that the client can accept, V_S is S's version string, V_C is C's version string, K_S is S's public host key, I_C is C's KEXINIT message, and I_S is S's KEXINIT message that has been exchanged before this part begins):

クライアントは、優先サイズを示すサーバーからモジュラスを要求します。次の説明（Cはクライアント、Sはサーバー、弾性率は大きな安全なプライム、GはGF（P）のサブグループの発電機であり、MINは許容可能なBITSのPの最小サイズのサイズです。クライアントにとって、nはクライアントがサーバーから受信したいビットの弾性Pのサイズであり、最大はクライアントが受け入れることができるビットの最大サイズのサイズです。文字列、k_sはSのパブリックホストキー、i_cはcのkexinitメッセージであり、i_sはこの部分が開始される前に交換されたsのkexinitメッセージです）：

1. C sends "min || n || max" to S, indicating the minimal acceptable group size, the preferred size of the group, and the maximal group size in bits the client will accept.

1. Cは「min || n || max」をSに送信し、最小限のグループサイズ、グループの優先サイズ、およびクライアントが受け入れるビットの最大グループサイズを示します。

2. S finds a group that best matches the client's request, and sends "p || g" to C.

2. Sは、クライアントのリクエストに最も一致するグループを見つけ、「p || g」をCに送信します。

3. C generates a random number x, where 1 < x < (p-1)/2. It computes e = g^x mod p, and sends "e" to S.

3. c乱数xを生成します。ここで、1 <x <（p-1）/2。e = g^x mod pを計算し、「e」をSに送信します

4. S generates a random number y, where 0 < y < (p-1)/2, and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation.

4. Sは乱数yを生成します。ここで、0 <y <（p-1）/2で、f = g^y mod pを計算します。sは「e」を受け取ります。k = e^y mod p、h = hash（v_c || v_s || i_c || i_s || k_s || min || n || max || p || g || e || f ||k）（これらの要素は、その種類に従ってエンコードされています。以下を参照）、およびそのプライベートホストキーを備えたHの署名S。Sは「k_s || f || s」をCに送信します。署名操作には2回目のハッシュ操作が含まれる場合があります。

5. C verifies that K_S really is the host key for S (e.g., using certificates or a local database to obtain the public key). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K), and verifies the signature s on H.

5. cは、K_Sが実際にSのホストキーであることを確認します（たとえば、公開キーを取得するために証明書またはローカルデータベースを使用するなど）。Cは、検証なしでキーを受け入れることも許可されています。ただし、そうすることで、プロトコルはアクティブな攻撃に対して不安定になります（ただし、多くの環境で短期的には実際的な理由で望ましい場合があります）。c次に、k = f^x mod p、h = hash（v_c || v_s || i_c || i_s || k_s || min || n || max || p || g || e || f || k）、およびHの署名Sを確認します。

Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.

サーバーとクライアントは、kビットの弾性率の長さでグループをサポートする必要があります。ここで、1024 <= k <= 8192です。minとmaxの推奨値はそれぞれ1024と8192です。

Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. To prevent confinement attacks, they MUST accept the shared secret K only if 1 < K < p - 1.

どちらの側も、範囲にないeまたはfの値を送信または受け入れてはなりません[1、p-1]。この状態に違反した場合、キー交換は失敗します。閉じ込め攻撃を防ぐには、1 <k <p -1の場合にのみ共有秘密kを受け入れる必要があります。

The server should return the smallest group it knows that is larger than the size the client requested. If the server does not know a group that is larger than the client request, then it SHOULD return the largest group it knows. In all cases, the size of the returned group SHOULD be at least 1024 bits.

サーバーは、クライアントが要求したサイズよりも大きいことを知っている最小のグループを返す必要があります。サーバーがクライアント要求よりも大きいグループを知らない場合、それが知っている最大のグループを返す必要があります。すべての場合において、返されたグループのサイズは少なくとも1024ビットでなければなりません。

This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The public key algorithm for signing is negotiated with the KEXINIT messages.

これは、次のメッセージで実装されています。交換ハッシュを計算するためのハッシュアルゴリズムは、メソッド名で定義され、ハッシュと呼ばれます。署名のための公開キーアルゴリズムは、Kexinitメッセージと交渉されます。

First, the client sends:

最初に、クライアントは次のことを送信します。

byte SSH_MSG_KEY_DH_GEX_REQUEST uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server will send uint32 max, maximal size in bits of an acceptable group

BYTE SSH_MSG_KEY_DH_GEX_REQUEST UINT32 MIN、許容可能なグループUINT32 Nのビットの最小サイズ、グループのビットの優先サイズサーバーは、許容可能なグループのビットでUINT32 Max、最大サイズを送信します

The server responds with

サーバーはで応答します

byte SSH_MSG_KEX_DH_GEX_GROUP mpint p, safe prime mpint g, generator for subgroup in GF(p)

BYTE SSH_MSG_KEX_DH_GEX_GROUP MPINT P、SAFE PRIME MPINT G、GFのサブグループのジェネレーター（P）

The client responds with:

クライアントは次のように応答します。

byte SSH_MSG_KEX_DH_GEX_INIT mpint e

byte ssh_msg_kex_dh_gex_init mpint e

The server responds with:

サーバーは次のとおりです。

byte SSH_MSG_KEX_DH_GEX_REPLY string server public host key and certificates (K_S) mpint f string signature of H

BYTE SSH_MSG_KEX_DH_GEX_REPLY STRING SERVERパブリックホストキーと証明書（K_S）MPINT F文字列署名hの署名

The hash H is computed as the HASH hash of the concatenation of the following:

ハッシュHは、以下の連結のハッシュハッシュとして計算されます。

string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server will send uint32 max, maximal size in bits of an acceptable group mpint p, safe prime mpint g, generator for subgroup mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret

文字列v_c、クライアントのバージョン文字列（crおよびnl除外）文字列v_s、サーバーのバージョン文字列（crおよびnl除外）文字列i_c、クライアントのsshg_kexinit文字列i_sのペイロード、サーバーのssh_msg_kexinit文字列k_sのペイロード、ホストキーUINT32 MIN、許容可能なグループUINT32 Nのビットの最小サイズ、グループのビットで優先サイズサーバーはUINT32 Max、許容可能なグループMPINT Pのビットの最大サイズ、SAFE PRIME MPINT G、サブグループMPINT Eの発電機を送信します。クライアントMPINT Fによって送信された交換値、サーバーMPINT Kによって送信された交換値、共有秘密

This value is called the exchange hash, and it is used to authenticate the key exchange as per [RFC4253].

この値はExchange Hashと呼ばれ、[RFC4253]に従ってキー交換を認証するために使用されます。

4. Key Exchange Methods

4. 主要な交換方法

This document defines two new key exchange methods: "diffie-hellman-group-exchange-sha1" and "diffie-hellman-group-exchange-sha256".

このドキュメントでは、「Diffie-Hellman-Group-Exchange-Sha1」と「diffie-hellman-group-exchange-sha256」という2つの新しいキー交換方法を定義しています。

4.1. diffie-hellman-group-exchange-sha1

The "diffie-hellman-group-exchange-sha1" method specifies Diffie-Hellman Group and Key Exchange with SHA-1 [FIPS-180-2] as HASH.

「diffie-hellman-group-exchange-sha1」メソッドは、diffie-hellmanグループとSha-1 [FIPS-180-2]とのキー交換をハッシュとして指定します。

4.2. diffie-hellman-group-exchange-sha256

The "diffie-hellman-group-exchange-sha256" method specifies Diffie-Hellman Group and Key Exchange with SHA-256 [FIPS-180-2] as HASH.

「diffie-hellman-group-exchange-sha256」メソッドは、diffie-hellmanグループとSHA-256 [FIPS-180-2]とのキー交換をハッシュとして指定します。

Note that the hash used in key exchange (in this case, SHA-256) must also be used in the key derivation pseudo-random function (PRF), as per the requirement in the "Output from Key Exchange" section in [RFC4253].

[RFC4253]の「キーエクスチェンジからの出力」セクションの要件に従って、キーエクスチェンジ（この場合、SHA-256）で使用されるハッシュは、キー導入疑似ランダム関数（PRF）でも使用する必要があることに注意してください。。

5. Summary of Message Numbers

5. メッセージ番号の概要

The following message numbers have been defined in this document. They are in a name space private to this document and not assigned by IANA.

このドキュメントでは、次のメッセージ番号が定義されています。彼らはこのドキュメントに非公開の名前のスペースにあり、IANAによって割り当てられていません。

#define SSH_MSG_KEX_DH_GEX_REQUEST_OLD 30 #define SSH_MSG_KEX_DH_GEX_REQUEST 34 #define SSH_MSG_KEX_DH_GEX_GROUP 31 #define SSH_MSG_KEX_DH_GEX_INIT 32 #define SSH_MSG_KEX_DH_GEX_REPLY 33

#define ssh_msg_kex_dh_gex_request_old 30 #define sshg_kex_dh_gex_request 34 #define sshg_kex_dh_gex_gex_gex_gex_gex

SSH_MSG_KEX_DH_GEX_REQUEST_OLD is used for backward compatibility. Instead of sending "min || n || max", the client only sends "n". In addition, the hash is calculated using only "n" instead of "min || n || max".

ssh_msg_kex_dh_gex_request_oldは、後方互換性に使用されます。「min || n || max」を送信する代わりに、クライアントは「n」のみを送信します。さらに、ハッシュは、「min || n || max」の代わりに「n」のみを使用して計算されます。

The numbers 30-49 are key exchange specific and may be redefined by other kex methods.

数字30-49は重要な交換固有であり、他のKEXメソッドによって再定義される場合があります。

6. Implementation Notes

6. 実装ノート

6.1. Choice of Generator

6.1. 発電機の選択

One useful technique is to select the generator, and then limit the modulus selection sieve to primes with that generator:

有用な手法の1つは、発電機を選択し、そのジェネレーターを使用して弾性係数選択のふるいをプライムに制限することです。

2 when p (mod 24) = 11. 5 when p (mod 10) = 3 or 7.

2 p（mod 24）= 11. 5 p（mod 10）= 3または7の場合。

It is recommended to use 2 as generator, because it improves efficiency in multiplication performance. It is usable even when it is not a primitive root, as it still covers half of the space of possible residues.

乗算パフォーマンスの効率を改善するため、2を発電機として使用することをお勧めします。原始的な根ではない場合でも使用できます。これは、可能な残基の空間の半分をまだカバーしているためです。

6.2. Private Exponents

6.2. 私的指数

To increase the speed of the key exchange, both client and server may reduce the size of their private exponents. It should be at least twice as long as the key material that is generated from the shared secret. For more details, see the paper by van Oorschot and Wiener [VAN-OORSCHOT].

キーエクスチェンジの速度を上げるために、クライアントとサーバーの両方がプライベート指数のサイズを縮小する場合があります。共有された秘密から生成される重要な資料の少なくとも2倍の長さでなければなりません。詳細については、Van OorschotとWiener [Van-Oorschot]の論文を参照してください。

7. Security Considerations

7. セキュリティに関する考慮事項

This protocol aims to be simple and uses only well-understood primitives. This encourages acceptance by the community and allows for ease of implementation, which hopefully leads to a more secure system.

このプロトコルは、シンプルであることを目的としており、よく理解されているプリミティブのみを使用します。これにより、コミュニティへの受け入れが促進され、実装が容易になり、より安全なシステムにつながることができます。

The use of multiple moduli inhibits a determined attacker from precalculating moduli exchange values, and discourages dedication of resources for analysis of any particular modulus.

複数のモジュリを使用すると、決定された攻撃者が弾性率の交換値を事前にすることを阻害し、特定のモジュラスの分析のためのリソースの献身を思いとどまらせます。

It is important to employ only safe primes as moduli, as they allow us to find a generator g so that the order of the generated subgroup does not factor into small primes, that is, with p = 2q + 1, the order has to be either q or p - 1. If the order is p - 1, then the exponents generate all possible public values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. Van Oorshot and Wiener note that using short private exponents with a random prime modulus p makes the computation of the discrete logarithm easy [VAN-OORSCHOT]. However, they also state that this problem does not apply to safe primes.

生成されたサブグループの順序が小さなプライムを考慮しないように、つまりp = 2q 1では、順序をどちらかにする必要がないように、発電機Gを見つけることができるため、モジュリとして安全な素数のみを使用することが重要です。qまたはp -1。順序がp -1の場合、指数は、より小さなサブセットをサイクリングせずに、モジュラスPの範囲全体に均等に分布するすべての可能なパブリック値を生成します。Van OorshotとWienerは、ランダムプライムモジュラスPで短いプライベート指数を使用すると、離散対数の計算が簡単になることに注意してください[Van-Oorschot]。しかし、彼らはまた、この問題は安全な素数には当てはまらないと述べています。

The least significant bit of the private exponent can be recovered when the modulus is a safe prime [MENEZES]. However, this is not a problem if the size of the private exponent is big enough. Related to this, Waldvogel and Massey note: When private exponents are chosen independently and uniformly at random from {0,...,p-2}, the key entropy is less than 2 bits away from the maximum, lg(p-1) [WALDVOGEL].

弾性率が安全なプライム[メネゼ]である場合、私的指数の最も有意なビットは回復できます。ただし、プライベート指数のサイズが十分に大きい場合、これは問題ではありません。これに関連する、WaldvogelとMassey注：{0、...、P-2}から個人指数が独立して均一にランダムに選択されると、キーエントロピーは最大から2ビット未満、LG（P-1））[waldvogel]。

The security considerations in [RFC4251] also apply to this key exchange method.

[RFC4251]のセキュリティ上の考慮事項は、この重要な交換方法にも適用されます。

8. Acknowledgements

8. 謝辞

The document is derived in part from "SSH Transport Layer Protocol" [RFC4253] by T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen.

このドキュメントは、T。Ylonen、T。Kivinen、M。Saarinen、T。Rinne、およびS. Lehtinenによる「SSH Transport Layer Protocol」[RFC4253]から派生しています。

Markku-Juhani Saarinen pointed out that the least significant bit of the private exponent can be recovered efficiently when using safe primes and a subgroup with an order divisible by two.

Markku-Juhani Saarinenは、Safe Primeと2人で割り切れる順序でサブグループを使用する場合、プライベート指数の最も重要なビットを効率的に回復できると指摘しました。

Bodo Moeller suggested that the server send only one group, reducing the complexity of the implementation and the amount of data that needs to be exchanged between client and server.

Bodo Moellerは、サーバーが1つのグループのみを送信し、実装の複雑さとクライアントとサーバーの間で交換する必要があるデータの量を減らすことを提案しました。

Appendix A: Generation of Safe Primes

付録A：安全な素数の生成

The "Handbook of Applied Cryptography" [MENEZES] lists the following algorithm to generate a k-bit safe prime p. It has been modified so that 2 is a generator for the multiplicative group mod p.

「適用された暗号化のハンドブック」[Menezes]には、次のアルゴリズムをリストして、Kビットセーフプライムpを生成します。2が乗算グループmod pの発電機であるように変更されました。

1. Do the following:

1. 以下をせよ：

1. Select a random (k-1)-bit prime q, so that q mod 12 = 5.

1. q mod 12 = 5にランダム（k-1） - ビットプライムqを選択します。

2. Compute p := 2q + 1, and test whether p is prime (using, e.g., trial division and the Rabin-Miller test).

2. P：= 2Q 1を計算し、Pがプライムかどうかをテストします（例：試行部門とラビンミラーテストを使用）。

2. Repeat until p is prime.

2. pがプライムになるまで繰り返します。

If an implementation uses the OpenSSL libraries, a group consisting of a 1024-bit safe prime and 2 as generator can be created as follows:

実装がOpenSSLライブラリを使用している場合、1024ビットのSAFEプライムで構成されるグループと、ジェネレーターとして2を次のように作成できます。

       DH *d = NULL;
       d = DH_generate_parameters(1024, DH_GENERATOR_2, NULL, NULL);
       BN_print_fp(stdout, d->p);

The order of the subgroup generated by 2 is q = p - 1.

2で生成されるサブグループの順序はq = p -1です。

References

参考文献

Normative References

引用文献

[FIPS-180-2] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.

[FIPS-180-2]国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、FIPS Pub 180-2、2002年8月。

[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。

[RFC4253] Lonvick, C., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.

[RFC4253] Lonvick、C。、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

Informative References

参考引用

[MENEZES] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, p. 537, 1996.

[Menezes] Menezes、A.、Van Oorschot、P。、およびS. Vanstone、「適用された暗号化のハンドブック」、CRC Press、p。537、1996。

[VAN-OORSCHOT] van Oorschot, P. and M. Wiener, "On Diffie-Hellman key agreement with short exponents", Advances in Cryptology -EUROCRYPT'96, LNCS 1070, Springer-Verlag, pp. 332-343, 1996.

[van-ooschot] van ooschot、P。and M. wiener、「短い指数とのdiffie-hellmanの重要な合意」、暗号学の進歩-eurocrypt'96、LNCS 1070、Springer-verlag、pp。332-343、1996。

[WALDVOGEL] Waldvogel, C. and J. Massey, "The probability distribution of the Diffie-Hellman key", Proceedings of AUSCRYPT 92, LNCS 718, Springer-Verlag, pp. 492-504, 1993.

[Waldvogel] Waldvogel、C。およびJ. Massey、「Diffie-Hellman Keyの確率分布」、Auscrypt 92、LNCS 718、Springer-Verlag、pp。492-504、1993。

Authors' Addresses

著者のアドレス

Markus Friedl EMail: markus@openbsd.org

Markus friedlメール：markus@openbsd.org

Niels Provos EMail: provos@citi.umich.edu

niels provosメール：provos@citi.umich.edu

William A. Simpson EMail: wsimpson@greendragon.com

ウィリアムA.シンプソンメール：wsimpson@greendragon.com

Full Copyright Statement

完全な著作権声明

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。