RFC 5683 - Password-Authenticated Key (PAK) Diffie-Hellman Exchange 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5683
タイトル : RFC 5683 - Password-authenticated Key（PAK）Diffie-Hellman Exchange
翻訳編集 : 自動生成

[要約] RFC 5683は、パスワード認証キー（PAK）Diffie-Hellman Exchangeのプロトコルを定義しています。このプロトコルの目的は、パスワードを使用してセキュアな鍵交換を行うことです。

Independent Submission                                    A. Brusilovsky
Request for Comments: 5683                                   I. Faynberg
Category: Informational                                       Z. Zeltsan
ISSN: 2070-1721                                           Alcatel-Lucent
                                                                S. Patel
                                                            Google, Inc.
                                                           February 2010

Password-Authenticated Key (PAK) Diffie-Hellman Exchange

Password-authenticated Key（PAK）Diffie-Hellman Exchange

Abstract

概要

This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.

このドキュメントでは、人間の軽emorizableパスワードに基づいて、基本的で無慈悲なdiffie-hellmanキーエクスチェンジに相互認証を追加することを提案しています。提案されたアルゴリズムは、パスワード認証キー（PAK）Exchangeと呼ばれます。Pakは、Diffie-Hellman Exchangeを実行しながら、2つのパーティーが自分自身を認証することを許可します。

The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy.

プロトコルは、すべての受動的およびアクティブな攻撃に対して安全です。特に、どちらのタイプの攻撃者も、パスワードに対するオフラインの辞書攻撃を可能にする情報を取得することはできません。Pakは秘密を秘密にします。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5683.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5683で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http: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.

このドキュメントは、BCP 78およびIETFドキュメント（http：trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

   1. Introduction ....................................................3
   2. Conventions .....................................................3
   3. Password-Authenticated Key Exchange .............................4
   4. Selection of Parameters .........................................5
      4.1. General Considerations .....................................5
      4.2. Over-the-Air Service Provisioning (OTASP) and Wireless
           Local Area Network (WLAN) Diffie-Hellman Parameters and
           Key Expansion Functions ....................................5
   5. Security Considerations .........................................7
   6. Acknowledgments .................................................8
   7. References ......................................................8
      7.1. Normative References .......................................8
      7.2. Informative References .....................................8

1. Introduction

1. はじめに

PAK has the following advantages:

Pakには次の利点があります。

- It provides a secure, authenticated key-exchange protocol. - It is secure against offline dictionary attacks when passwords are used. - It ensures Forward Secrecy. - It has been proven to be as secure as the Diffie-Hellman solution.

- 安全で認証されたキー交換プロトコルを提供します。 - パスワードが使用される場合、オフラインの辞書攻撃に対して安全です。 - それは秘密を前進させます。 - Diffie-Hellmanソリューションと同じくらい安全であることが証明されています。

The PAK protocol ([BMP00], [MP05], [X.1035]) has been proven to be as secure as the Diffie-Hellman ([RFC2631], [DH76]) in the random oracle model [BR93]. That is, PAK retains its security when used with low-entropy passwords. Therefore, it can be seamlessly integrated into existing applications, requiring secure authentication based on such low-entropy shared secrets.

PAKプロトコル（[BMP00]、[MP05]、[X.1035]）は、ランダムオラクルモデル[BR93]のDiffie-Hellman（[RFC2631]、[DH76]）と同じくらい安全であることが証明されています。つまり、PAKは、低エントロピーパスワードで使用するとセキュリティを保持します。したがって、既存のアプリケーションにシームレスに統合され、このような低エントロピー共有秘密に基づいて安全な認証が必要です。

2. Conventions

2. 規約

- A is an identity of Alice.

- Aはアリスのアイデンティティです。

- B is an identity of Bob.

- Bはボブのアイデンティティです。

- Ra is a secret random exponent selected by A.

- RAはAによって選択された秘密のランダム指数です。

- Rb is a secret random exponent selected by B.

- RBはBによって選択された秘密のランダム指数です。

- Xab denotes a value (X presumably computed by A) as derived by B.

- XABは、Bで導出された値（x）を示します（x）。

- Yba denotes a value (Y presumably computed by B) as derived by A.

- YBAは、Aによって導出された値（y）を示します（y）。

- A mod b denotes the least non-negative remainder when a is divided by b.

- Aは、aがbで分割されている場合、最も非陰性の残りを示します。

- Hi(u) denotes an agreed-on function (e.g., based on SHA-1, SHA-256, etc.) computed over a string u; the various H() act as independent random functions. H1(u) and H2(u) are the key derivation functions. H3(u), H4(u), and H5(u) are the hash functions.

- HI（u）は、文字列Uを介して計算された合意された関数（たとえば、SHA-1、SHA-256などに基づいて）を示します。さまざまなH（）は、独立したランダム関数として機能します。H1（U）およびH2（U）が重要な導出関数です。H3（U）、H4（U）、およびH5（U）はハッシュ関数です。

- s|t denotes concatenation of the strings s and t.

- s | tは、文字列sとtの連結を示します。

- ^ denotes exponentiation.

- ^指数を示します。

- Multiplication, division, and exponentiation are performed over (Zp)*; in other words: 1) a*b always means a*b (mod p).

- 乗算、分裂、および指数は（ZP）*で実行されます。つまり、1）a*bは常にa*b（mod p）を意味します。

2) a/b always means a * x (mod p), where x is the multiplicative inverse of b modulo p.

2) A/Bは常にA * x（mod p）を意味し、xはb modulo pの乗法逆です。

3) a^b means a^b (mod p).

3) a^bはa^b（mod p）を意味します。

3. Password-Authenticated Key Exchange

3. パスワードを認識したキー交換

Diffie-Hellman key agreement requires that both the sender and recipient of a message create their own secret, random numbers and exchange the exponentiation of their respective numbers.

Diffie-Hellmanの重要な契約では、メッセージの送信者と受信者の両方が独自の秘密、乱数を作成し、それぞれの数の指数を交換する必要があります。

PAK has two parties, Alice (A) and Bob (B), sharing a secret password PW that satisfies the following conditions:

Pakには、アリス（a）とボブ（b）の2つのパーティーがあり、次の条件を満たす秘密のパスワードPWを共有しています。

      H1(A|B|PW) != 0
      H2(A|B|PW) != 0

The global Diffie-Hellman publicly known constants, a prime p and a generator g, are carefully selected so that:

グローバルなDiffie-Hellman公開されている定数、プライムPと発電機Gは、次のように慎重に選択されます。

1. A safe prime p is large enough to make the computation of discrete logarithms infeasible, and

1. 安全なプライムPは、離散対数の計算を実行不可能にするのに十分な大きさであり、

2. Powers of g modulo p cover the entire range of p-1 integers from 1 to p-1. (References demonstrate working examples of selections).

2. G Modulo Pのパワーは、P-1整数の全範囲を1からP-1にカバーします。（参考文献は、選択の実用的な例を示しています）。

Initially, Alice (A) selects a secret, random exponent Ra and computes g^Ra; Bob (B) selects a secret, random exponent Rb and computes g^Rb. For efficiency purposes, short exponents could be used for Ra and Rb, provided they have a certain minimum size. Then:

最初に、アリス（a）は秘密のランダムな指数RAを選択し、g^raを計算します。ボブ（b）は、秘密のランダム指数RBを選択し、g^rbを計算します。効率のために、特定の最小サイズがあれば、RAとRBに短い指数を使用できます。それから：

   A --> B: {A, X = H1(A|B|PW)*(g^Ra)}
            (The above precondition on PW ensures that X != 0)

      Bob
        receives Q (presumably Q = X), verifies that Q != 0
          (if Q = 0, Bob aborts the procedure);
        divides Q by H1(A|B|PW) to get Xab, the recovered value of g^Ra

   B --> A: {Y = H2(A|B|PW)*(g^Rb), S1 = H3(A|B|PW|Xab|g^Rb|(Xab)^Rb)}
            (The above precondition on PW ensures that Y != 0)

      Alice
        verifies that Y != 0;
        divides Y by H2(A|B|PW) to get Yba, the recovered value of g^Rb,
        and computes S1' = H3(A|B|PW|g^Ra|Yba|(Yba)^Ra);
        authenticates Bob by checking whether S1' = S1;
        if authenticated, then sets key K = H5(A|B|PW|g^Ra|Yba|(Yba)^Ra)

   A --> B:  S2 = H4(A|B|PW|g^Ra|Yba|(Yba)^Ra)

      Bob
        Computes S2' = H4(A|B|PW|Xab|g^Rb|(Xab)^Rb) and
        authenticates Alice by checking whether S2' = S2;
        if authenticated, then sets K = H5(A|B|PW|Xab|g^Rb|(Xab)^Rb)

If any of the above verifications fails, the protocol halts; otherwise, both parties have authenticated each other and established the key.

上記の検証のいずれかが失敗した場合、プロトコルは停止します。それ以外の場合、両当事者はお互いを認証し、キーを確立しました。

4. Selection of Parameters

4. パラメーターの選択

This section provides guidance on selection of the PAK parameters. First, it addresses general considerations, then it reports on specific implementations.

このセクションでは、PAKパラメーターの選択に関するガイダンスを提供します。まず、一般的な考慮事項に対処し、次に特定の実装について報告します。

4.1. General Considerations

4.1. 一般的な考慮事項

In general implementations, the parameters must be selected to meet algorithm requirements of [BMP00].

一般的な実装では、[BMP00]のアルゴリズム要件を満たすためにパラメーターを選択する必要があります。

4.2. Over-the-Air Service Provisioning (OTASP) and Wireless Local Area Network (WLAN) Diffie-Hellman Parameters and Key Expansion Functions

4.2. オーバーザエアサービスプロビジョニング（OTASP）およびワイヤレスローカルエリアネットワーク（WLAN）diffie-hellmanパラメーターとキー拡張機能

[OTASP], [TIA683], and [WLAN] pre-set public parameters p and g to their "published" values. This is necessary to protect against an attacker sending bogus p and g values, tricking the legitimate user to engage in improper Diffie-Hellman exponentiation and leaking some information about the password.

[OTASP]、[TIA683]、および[WLAN]は、「公開された」値にPとGを事前に設定しました。これは、攻撃者が偽のPとGの値を送信し、合法的なユーザーが不適切なdiffie-hellmanの指数に従事し、パスワードに関する情報を漏らすためにトリックすることから保護するために必要です。

According to [OTASP], [TIA683], and [WLAN], g shall be set to 00001101, and p to the following 1024-bit prime number (most significant bit first): 0xFFFFFFFF 0xFFFFFFFF 0xC90FDAA2 0x2168C234 0xC4C6628B 0x80DC1CD1 0x29024E08 0x8A67CC74 0x020BBEA6 0x3B139B22 0x514A0879 0x8E3404DD 0xEF9519B3 0xCD3A431B 0x302B0A6D 0xF25F1437 0x4FE1356D 0x6D51C245 0xE485B576 0x625E7EC6 0xF44C42E9 0xA637ED6B 0x0BFF5CB6 0xF406B7ED 0xEE386BFB 0x5A899FA5 0xAE9F2411 0x7C4B1FE6 0x49286651 0xECE65381 0xFFFFFFFF 0xFFFFFFFF

In addition, if short exponents [MP05] are used for Diffie-Hellman parameters Ra and Rb, then they should have a minimum size of 384 bits. The independent, random functions H1 and H2 should each output 1152 bits, assuming prime p is 1024 bits long and session keys K are 128 bits long. H3, H4, and H5 each output 128 bits. More information on instantiating random functions using hash functions can be found in [BR93]. We use the FIPS 180 SHA-1 hashing function [FIPS180] below to instantiate the random function as done in [WLAN]; however, SHA-256 can also be used:

さらに、Diffie-HellmanパラメーターRAおよびRBに短い指数[MP05]が使用されている場合、最小サイズの384ビットが必要です。プライムPの長さが1024ビットで、セッションキーKが長さ128ビットであると仮定すると、独立したランダム機能H1とH2は各出力1152ビットが必要です。H3、H4、およびH5各出力128ビット。ハッシュ関数を使用したインスタンスランダム関数の詳細については、[BR93]に記載されています。以下のFIPS 180 SHA-1ハッシュ関数[FIPS180]を使用して、[WLAN]で実行されたランダム関数をインスタンス化します。ただし、SHA-256も使用できます。

   H1(z):
   SHA-1(1|1|z) mod 2^128 | SHA-1(1|2|z) mod 2^128 |...|
   | SHA-1(1|9|z) mod 2^128

   H2(z):
   SHA-1(2|1|z) mod 2^128 | SHA-1(2|2|z) mod 2^128 |...|
   | SHA-1(2|9|z) mod 2^128

   H3(z): SHA-1(3|len(z)|z|z) mod 2^128
   H4(z): SHA-1(4|len(z)|z|z) mod 2^128
   H5(z): SHA-1(5|len(z)|z|z) mod 2^128

In order to create 1152 output bits for H1 and H2, nine calls to SHA-1 are made and the 128 least significant bits of each output are used. The input payload of each call to SHA-1 consists of:

H1およびH2に1152出力ビットを作成するために、SHA-1への9つの呼び出しが行われ、各出力の128の最小有意ビットが使用されます。SHA-1への各呼び出しの入力ペイロードは、次のことです。

a) 32 bits of function type, which for H1 is set to 1 and for H2 is set to 2; b) a 32-bit counter value, which is incremented from 1 to 9 for each call to SHA-1; c) the argument z [for (A|B|PW)].

a) 32ビットの関数タイプ。H1は1に設定され、H2の場合は2に設定されています。b）32ビットのカウンター値。これは、SHA-1への呼び出しごとに1から9に増加します。c）引数z [for（a | b | pw）]。

The functions H3, H4, and H5 require only one call to the SHA-1 hashing function and their respective payloads consist of:

関数H3、H4、およびH5は、SHA-1ハッシュ関数への1つの呼び出しのみを必要とし、それぞれのペイロードは次のもので構成されています。

a) 32 bits of function type (e.g., 3 for H3); b) a 32-bit value for the bit length of the argument z; c) the actual argument repeated twice.

a) 32ビットの関数タイプ（例：H3の場合は3）;b）引数zのビット長の32ビット値。c）実際の議論が2回繰り返されました。

Finally, the 128 least significant bits of the output are used.

最後に、出力の128個の最小有意ビットが使用されます。

5. Security Considerations

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

Security considerations are as follows:

セキュリティ上の考慮事項は次のとおりです。

- Identifiers

- 識別子

Any protocol that uses PAK must specify a method for producing a single representation of identity strings.

PAKを使用するプロトコルは、ID文字列の単一の表現を生成する方法を指定する必要があります。

- Shared secret

- 共有秘密

PAK involves the use of a shared secret. Protection of the shared values and managing (limiting) their exposure over time is essential and can be achieved using well-known security policies and measures. If a single secret is shared among more than two entities (e.g., Alice, Bob, and Mallory), then Mallory can represent himself as Alice to Bob without Bob being any the wiser.

Pakには、共有された秘密の使用が含まれます。共有値の保護と時間の経過に伴う露出の管理（制限）は不可欠であり、よく知られているセキュリティポリシーと測定を使用して達成できます。単一の秘密が2つ以上のエンティティ（アリス、ボブ、マロリーなど）の間で共有されている場合、マロリーはボブが賢くなくてもボブへのアリスとして自分自身を表現できます。

- Selection of Diffie-Hellman parameters

- diffie-hellmanパラメーターの選択

The parameters p and g must be carefully selected in order not to compromise the shared secret. Only previously agreed-upon values for parameters p and g should be used in the PAK protocol. This is necessary to protect against an attacker sending bogus p and g values and thus tricking the other communicating party in an improper Diffie-Hellman exponentiation. Both parties also need to randomly select a new exponent each time the key-agreement protocol is executed. If both parties re-use the same values, then Forward Secrecy property is lost.

共有された秘密を妥協しないように、パラメーターPとGを慎重に選択する必要があります。PAKプロトコルでは、パラメーターPとGの以前に合意した値のみを使用する必要があります。これは、攻撃者が偽のPとGの値を送信し、したがって、不適切なDiffie-Hellmanの指数で他の通信パーティーをtrickするために必要です。また、両当事者は、キーアグリーメントプロトコルが実行されるたびに、新しい指数をランダムに選択する必要があります。両方の当事者が同じ値を再利用すると、秘密のプロパティを転送することが失われます。

In addition, if short exponents Ra and Rb are used, then they should have a minimum size of 384 bits (assuming that 128-bit session keys are used). Historically, the developers, who strived for 128-bit security (and thus selected 256-bit exponents), added 128 bits to the exponents to ensure the security reduction proofs. This should explain how an "odd" length of 384 has been arrived at.

さらに、短い指数RAとRBを使用する場合、最小サイズの384ビットを持つ必要があります（128ビットセッションキーが使用されると仮定します）。歴史的に、128ビットのセキュリティのために努力した開発者（したがって256ビットの指数を選択した）は、セキュリティ削減の証明を確保するために指数に128ビットを追加しました。これは、384の「奇妙な」長さがどのように到達したかを説明するはずです。

- Protection against attacks

- 攻撃に対する保護

a) There is a potential attack, the so-called discrete logarithm attack on the multiplicative group of congruencies modulo p, in which an adversary can construct a table of discrete logarithms to be used as a "dictionary". A sufficiently large prime, p, must be selected to protect against such an attack. A proper 1024-bit value for p and an appropriate value for g are published in [WLAN] and [TIA683]. For the moment, this is what has been implemented; however, a larger prime (i.e., one that is 2048 bits long, or even larger) will definitely provide better protection. It is important to note that once this is done, the generator must be changed too, so this task must be approached with extreme care.

a) 潜在的な攻撃があります。いわゆる離散対数攻撃は、一致する一致の増加グループに対する攻撃です。このモジュロPでは、敵は「辞書」として使用される離散対数の表を構築できます。このような攻撃から保護するために、十分に大きなプライムPを選択する必要があります。Pの適切な1024ビット値とGの適切な値は、[WLAN]および[TIA683]に公開されています。とりあえず、これが実装されているものです。ただし、より大きなプライム（つまり、2048ビットの長さ、さらにはさらに大きいプライム）は、間違いなくより良い保護を提供します。これが完了したら、ジェネレーターも変更する必要があるため、このタスクに非常に注意してアプローチする必要があることに注意することが重要です。

b) An online password attack can be launched by an attacker by repeatedly guessing the password and attempting to authenticate. The implementers of PAK should consider employing mechanisms (such as lockouts) for preventing such attacks.

b) オンラインパスワード攻撃は、パスワードを繰り返し推測し、認証しようとすることにより、攻撃者によって起動できます。PAKの実装者は、そのような攻撃を防ぐためにメカニズム（ロックアウトなど）を使用することを検討する必要があります。

- Recommendations on H() functions

- H（）関数に関する推奨事項

The independent, random functions H1 and H2 should output 1152 bits each, assuming prime p is 1024 bits long and session keys K are 128 bits long. The random functions H3, H4, and H5 should output 128 bits.

プライムPの長さが1024ビットで、セッションキーKが長さ128ビットであると仮定すると、独立したランダム機能H1とH2はそれぞれ1152ビットを出力する必要があります。ランダム機能H3、H4、およびH5は、128ビットを出力する必要があります。

An example of secure implementation of PAK is provided in [Plan9].

PAKの安全な実装の例は、[Plan9]に記載されています。

6. Acknowledgments

6. 謝辞

The authors are grateful for the thoughtful comments received from Shehryar Qutub, Ray Perlner, and Yaron Sheffer. Special thanks go to Alfred Hoenes, Tim Polk, and Jim Schaad for their careful reviews and invaluable help in preparing the final version of this document.

著者は、Shehryar Qutub、Ray Perlner、Yaron Shefferから受け取った思慮深いコメントに感謝しています。Alfred Hoenes、Tim Polk、およびJim Schaadに、このドキュメントの最終バージョンの準備に慎重なレビューと貴重なヘルプを提供してくれたことに感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[X.1035] ITU-T, "Password-authenticated key exchange (PAK) protocol", ITU-T Recommendation X.1035, 2007.

[X.1035] ITU-T、「パスワード認証キーエクスチェンジ（PAK）プロトコル」、ITU-T推奨X.1035、2007。

[TIA683] TIA, "Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems", TIA-683-D, May 2006.

[TIA683] TIA、「スプレッドスペクトルシステムにおけるモバイルステーションのオーバーザエアサービスプロビジョニング」、2006年5月、TIA-683-D。

7.2. Informative References

7.2. 参考引用

[Plan9] Alcatel-Lucent, "Plan 9 from Bell Labs", http://netlib.bell-labs.com/plan9/.

[Plan9] Alcatel-Lucent、「Bell Labsからの計画9」、http：//netlib.bell-labs.com/plan9/。

[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably secure password authentication and key exchange using Diffie-Hellman", Proceedings of Eurocrypt 2000.

[BMP00] Boyko、V.、Mackenzie、P。、およびS. Patel、「Diffie-Hellmanを使用したパスワード認証とキー交換」、Proceedings of EuroCrypt 2000。

[BR93] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 5th Annual ACM Conference on Computer and Communications Security, 1998.

[BR93] Bellare、M。およびP. Rogaway、「ランダムオラクルは実用的です：効率的なプロトコルを設計するためのパラダイム」、コンピューターおよび通信セキュリティに関する第5回ACM会議の議事録、1998年。

[DH76] Diffie, W. and M.E. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory 22 (1976), 644-654.

[DH76] Diffie、W。and M.E. Hellman、「暗号化の新しい方向」、IEEE情報理論22（1976）、644-654。

[FIPS180] NIST Federal Information Processing Standards, Publication FIPS 180-3, "Secure Hash Standard", 2008.

[FIPS180] NIST連邦情報処理基準、出版物FIPS 180-3、「Secure Hash Standard」、2008。

[MP05] MacKenzie, P. and S. Patel, "Hard Bits of the Discrete Log with Applications to Password Authentication", CT-RSA 2005.

[MP05] Mackenzie、P。およびS. Patel、「パスワード認証へのアプリケーションを備えた離散ログのハードビット」、CT-RSA 2005。

[OTASP] 3GPP2, "Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems", 3GPP2 C.S0016-C v. 1.0 5, October 2004.

[OTASP] 3GPP2、「スプレッドスペクトルシステムにおけるモバイルステーションのオーバーザエアサービスプロビジョニング」、3GPP2 C.S0016-Cv。1.05、2004年10月。

[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.

[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。

[WLAN] 3GPP2, "Wireless Local Area Network (WLAN) Interworking", 3GPP2 X.S0028-0, v.1.0, April 2005.

[WLAN] 3GPP2、「ワイヤレスローカルエリアネットワーク（WLAN）インターワーキング」、3GPP2 X.S0028-0、v.1.0、2005年4月。

Authors' Addresses

著者のアドレス

Alec Brusilovsky Alcatel-Lucent Room 9B-226, 1960 Lucent Lane Naperville, IL 60566-7217 USA Tel: +1 630 979 5490 EMail: Alec.Brusilovsky@alcatel-lucent.com

ALEC BRUSILOVSKY ALCATEL-LUCENT ROOM 9B-226、1960 Lucent Lane Naperville、IL 60566-7217 USA Tel：1 630 979 5490電子メール：alec.brusilovsky@alcatel-lucent.com

Igor Faynberg Alcatel-Lucent Room 2D-144, 600 Mountain Avenue Murray Hill, NJ 07974 USA Tel: +1 908 582 2626 EMail: igor.faynberg@alcatel-lucent.com

Igor Faynberg Alcatel-Lucent Room 2D-144、600 Mountain Avenue Murray Hill、NJ 07974 USA Tel：1 908 582 2626メール：igor.faynberg@alcatel-lucent.com

Sarvar Patel Google, Inc. 76 Ninth Avenue New York, NY 10011 USA Tel: +1 212 565 5907 EMail: sarvar@google.com

Sarvar Patel Google、Inc。76 NINTH ATHENUE NEW YORK、NY 10011 USA Tel：1 212 565 5907メール：sarvar@google.com

Zachary Zeltsan Alcatel-Lucent Room 2D-150, 600 Mountain Avenue Murray Hill, NJ 07974 USA Tel: +1 908 582 2359 EMail: zeltsan@alcatel-lucent.com

Zachary Zeltsan Alcatel-Lucent Room 2D-150、600 Mountain Avenue Murray Hill、NJ 07974 USA Tel：1 908 582 2359メール：Zeltsan@alcatel-lucent.com