Internet Engineering Task Force (IETF) D. Harkins
Request for Comments: 5931 Aruba Networks
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
August 2010
Extensible Authentication Protocol (EAP) Authentication
Using Only a Password
Abstract
抽象
This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.
このメモは、認証用の共有パスワードを使用して拡張認証プロトコル（EAP）方式、EAP-PWDを、記載されています。パスワードは、低エントロピーのものであってもよいし、攻撃者に利用可能である辞書のように、可能なパスワードのいくつかの集合から引き出されます。根底にある鍵の交換は、アクティブな攻撃、受動的攻撃、および辞書攻撃に耐性があります。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5931.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5931で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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. 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Keyword Definitions . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Resistance to Passive Attack . . . . . . . . . . . . . 4
1.3.2. Resistance to Active Attack . . . . . . . . . . . . . 5
1.3.3. Resistance to Dictionary Attack . . . . . . . . . . . 5
1.3.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . 5
2. Specification of EAP-pwd . . . . . . . . . . . . . . . . . . . 5
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7
2.2.1. Finite Field Cryptography . . . . . . . . . . . . . . 7
2.2.2. Elliptic Curve Cryptography . . . . . . . . . . . . . 8
2.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Instantiating the Random Function . . . . . . . . . . . . 9
2.5. Key Derivation Function . . . . . . . . . . . . . . . . . 10
2.6. Random Numbers . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Representation and Processing of Input Strings . . . . . . 11
2.7.1. Identity Strings . . . . . . . . . . . . . . . . . . . 11
2.7.2. Passwords . . . . . . . . . . . . . . . . . . . . . . 11
2.8. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.2. Message Flows . . . . . . . . . . . . . . . . . . . . 12
2.8.3. Fixing the Password Element . . . . . . . . . . . . . 14
2.8.3.1. ECC Operation for PWE . . . . . . . . . . . . . . 15
2.8.3.2. FFC Operation for pwe . . . . . . . . . . . . . . 16
2.8.4. Message Construction . . . . . . . . . . . . . . . . . 16
2.8.4.1. ECC Groups . . . . . . . . . . . . . . . . . . . . 16
2.8.4.2. FFC Groups . . . . . . . . . . . . . . . . . . . . 17
2.8.5. Message Processing . . . . . . . . . . . . . . . . . . 18
2.8.5.1. EAP-pwd-ID Exchange . . . . . . . . . . . . . . . 18
2.8.5.2. EAP-pwd-Commit Exchange . . . . . . . . . . . . . 20
2.8.5.3. EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 21
2.9. Management of EAP-pwd Keys . . . . . . . . . . . . . . . . 22
2.10. Mandatory-to-Implement Parameters . . . . . . . . . . . . 23
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1. EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 23
3.2. EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 25
3.2.1. EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2. EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 26
3.2.3. EAP-pwd-Confirm . . . . . . . . . . . . . . . . . . . 27
3.3. Representation of Group Elements and Scalars . . . . . . . 27
3.3.1. Elements in FFC Groups . . . . . . . . . . . . . . . . 27
3.3.2. Elements in ECC Groups . . . . . . . . . . . . . . . . 28
3.3.3. Scalars . . . . . . . . . . . . . . . . . . . . . . . 28
4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6.1. Resistance to Passive Attack . . . . . . . . . . . . . . . 31
6.2. Resistance to Active Attack . . . . . . . . . . . . . . . 31
6.3. Resistance to Dictionary Attack . . . . . . . . . . . . . 32
6.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 34
6.5. Group Strength . . . . . . . . . . . . . . . . . . . . . . 34
6.6. Random Functions . . . . . . . . . . . . . . . . . . . . . 34
7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . . 38
The predominant access method for the Internet today is that of a human using a username and password to authenticate to a computer enforcing access control. Proof of knowledge of the password authenticates the human and computer.
インターネットのための主なアクセス方法は、今日では、アクセス制御を実施するコンピュータの認証にユーザー名とパスワードを使用して、ヒトのものです。パスワードの知識の証明は、人間とコンピュータを認証します。
Typically these passwords are not stored on a user's computer for security reasons and must be entered each time the human desires network access. Therefore, the passwords must be ones that can be repeatedly entered by a human with a low probability of error. They will likely not possess high-entropy, and it may be assumed that an adversary with access to a dictionary will have the ability to guess a user's password. It is therefore desirable to have a robust authentication method that is secure even when used with a weak password in the presence of a strong adversary.
通常、これらのパスワードは、セキュリティ上の理由により、ユーザーのコンピュータに保存されていないと、人間は、ネットワークへのアクセスを希望するたびに入力する必要があります。そのため、パスワードを繰り返し誤り確率の低い人間が入力できるものでなければなりません。彼らはおそらく高エントロピーを持っていないだろう、辞書へのアクセス権を持つ敵は、ユーザーのパスワードを推測する能力を持っているだろうと仮定することができます。強力な敵の存在下で弱いパスワードを使用しても安全である強固な認証方法を有することが望ましいです。
EAP-pwd is an EAP method that addresses the problem of password-based authenticated key exchange -- using a possibly weak password for authentication to derive an authenticated and cryptographically strong shared secret. This problem was first described by Bellovin and Merritt in [BM92] and [BM93]. There have been a number of subsequent suggestions ([JAB96], [LUC97], [BMP00], and others) for password-based authenticated key exchanges.
認証され、暗号的に強力な共有秘密を導出するための認証のために、おそらく弱いパスワードを使用して - EAP-PWDはパスワードベースの認証された鍵交換の問題に対処するEAP方式です。この問題は、最初の[BM92]と[BM93]でBellovin氏とメリットにより記載されました。パスワードベースの認証された鍵交換のために、後続の提案の数（[JAB96]、[LUC97]、[BMP00]など）がありました。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Any protocol that claims to solve the problem of password-authenticated key exchange must be resistant to active, passive, and dictionary attack and have the quality of forward secrecy. These characteristics are discussed further in the following sections.
パスワード認証鍵交換の問題を解決するために主張して任意のプロトコルは、アクティブ、パッシブ、および辞書攻撃に耐性があると前進の秘密保持の品質を持っている必要があります。これらの特性は、以下のセクションで詳しく説明されています。
A passive, or benign, attacker is one that merely relays messages back and forth between the peer and server, faithfully, and without modification. The contents of the messages are available for inspection, but that is all. To achieve resistance to passive attack, such an attacker must not be able to obtain any information about the password or anything about the resulting shared secret from watching repeated runs of the protocol. Even if a passive attacker is able to learn the password, she will not be able to determine any information about the resulting secret shared by the peer and server.
受動的、または良性、攻撃者は単に、忠実に、変更することなく前後ピアとサーバ間でメッセージを中継するものです。メッセージの内容は、検査のために利用可能であるが、それがすべてです。受動的攻撃に対する耐性を達成するために、そのような攻撃者は、プロトコルの繰り返しの実行を見てから生じる共有秘密についてのパスワードか何かについての情報を得ることができない必要があります。受動的攻撃者がパスワードを知ることができる場合でも、彼女は、ピアとサーバで共有した秘密に関する情報を決定することができません。
An active attacker is able to modify, add, delete, and replay messages sent between protocol participants. For this protocol to be resistant to active attack, the attacker must not be able to obtain any information about the password or the shared secret by using any of its capabilities. In addition, the attacker must not be able to fool a protocol participant into thinking that the protocol completed successfully.
アクティブな攻撃者は、変更、追加、削除、およびプロトコルの参加者の間で送信されるメッセージを再生することができます。このプロトコルは、アクティブな攻撃に耐性であるためには、攻撃者は、その機能のいずれかを使用して、パスワードまたは共有秘密に関する情報を入手することはできません必要があります。また、攻撃者は、プロトコルが正常に完了したことを考えることにプロトコルの参加者をだますことはできません必要があります。
It is always possible for an active attacker to deny delivery of a message critical in completing the exchange. This is no different than dropping all messages and is not an attack against the protocol.
活発な攻撃者が交換を完了する上で重要なメッセージの配信を拒否することは常に可能です。これは、すべてのメッセージをドロップするよりも違いはありません、プロトコルに対する攻撃ではありません。
For this protocol to be resistant to dictionary attack, any advantage an adversary can gain must be directly related to the number of interactions she makes with an honest protocol participant and not through computation. The adversary will not be able to obtain any information about the password except whether a single guess from a single protocol run is correct or incorrect.
このプロトコルは、辞書攻撃に耐性であるためには、敵対者が得ることができます任意の利点は、直接、彼女は正直なプロトコルの参加者ではなく計算により行い相互作用の数に関連していなければなりません。敵は単一のプロトコルの実行から単一の推測が正しいか間違っているかどうかを除いて、パスワードに関する情報を入手することができません。
Compromise of the password must not provide any information about the secrets generated by earlier runs of the protocol.
パスワードの妥協は、プロトコルの以前の実行によって生成された秘密についての情報を提供してはなりません。
The following notation is used in this memo:
以下の表記は、このメモで使用されています。
peer-ID The peer's identity, the peer NAI [RFC4282].
ピア-IDをピアの識別情報、ピアNAI [RFC4282]。
server-ID A string that identifies the server to the peer.
サーバIDピアにサーバーを識別する文字列。
password The password shared between the peer and server.
パスワードパスワードは、ピアとサーバ間で共有しました。
y = H(x) The binary string x is given to a function H, which produces a fixed-length output y.
Y = H（x）は、バイナリ文字列Xは、固定長の出力yを生成する関数Hに与えられます。
a | b The concatenation of string a with string b.
|列bを文字列aの連結B。
[a]b A string consisting of the single bit "a" repeated "b" times.
[A]単一ビット「」繰り返し「B」の時間からなる文字列B。
x mod y The remainder of division of x by y. The result will be between 0 and y.
X MOD Y yだけXの除算の余り。結果は0とyとの間であろう。
g^x mod p The multiplication of the value "g" with itself "x" times, modulo the value "p".
自身とG ^ Xモッズのp値「G」の乗算を時間を「x」は、値「P」を法とします。
inv(Q) The inverse of an element, Q, from a finite field.
有限体からINV（Q）要素、Qの逆数。
len(x) The length in bits of the string x.
LEN（x）は、文字列xのビット単位の長さ。
chop(x, y) The reduction of string x, being at least y bits in length, to y bits.
Yビットに、長さが少なくともYビットであり、（x、y）のストリングxの還元をチョップ。
PRF(x,y) A pseudo-random function that takes a key, x, and variable-length data, y, and produces a fixed-length output that cannot be distinguished (with a significant advantage) from a random source.
PRF（X、Y）キー、X、及び可変長データ、Yを取り、ランダムソースから（重要な利点で）区別することができない固定長の出力を生成する擬似ランダム関数。
LSB(x) Returns the least-significant bit of the bitstring "x".
LSB（x）のビット列の「x」の最下位ビットを返します。
Ciphersuite An encoding of a group to use with EAP-pwd, the definition of function H, and a PRF, in that order.
そのために、EAP-PWDで使用するグループの符号化、関数Hの定義、およびPRFを暗号スイート。
MK The Master Key is generated by EAP-pwd. This is a high-entropy secret whose length depends on the random function used.
MKザ・マスターキーは、EAP-PWDによって生成されます。これは、その長さが使用されるランダム機能に依存した高エントロピー秘密です。
MSK The Master Session Key exported by EAP-pwd. This is a high-entropy secret 512 bits in length.
MSKザ・マスターセッションキーは、EAP-PWDによってエクスポート。これは、長さが512ビットの秘密高エントロピーです。
EMSK The Extended Master Session Key exported by EAP-pwd. This is a high-entropy secret 512 bits in length.
EAP-PWDによってエクスポートされた拡張マスターセッションキーをEMSK。これは、長さが512ビットの秘密高エントロピーです。
This protocol uses discrete logarithm cryptography to achieve authentication and key agreement (see [SP800-56A]). Each party to the exchange derives ephemeral keys with respect to a particular set of domain parameters (referred to here as a "group"). A group can be based on Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC).
このプロトコルは認証およびキー合意を（[SP800-56A]参照）を達成するために、離散対数暗号を使用します。為替への各当事者は、（「グループ」としてここに呼ばれる）ドメインパラメータの特定のセットに関してはかないキーを導出します。グループは、有限フィールド暗号（FFC）や楕円曲線暗号（ECC）に基づくことができます。
Domain parameters for the FFC groups used by EAP-pwd include:
EAP-PWDが使用するFFCグループのドメインパラメータが含まれます：
o A prime, p, determining a prime field GF(p), the integers modulo p. The FFC group will be a subgroup of GF(p)*, the multiplicative group of non-zero elements in GF(p). The group operation for FFC groups is multiplication modulo p.
素数、P O、素体GF（p）を決定し、整数Pを法。 FFC基はGF（P）のサブグループになり*、GFにおける非零要素の乗法群（P）。 FFCグループのグループ操作は、乗算剰余Pです。
o An element, G, in GF(p)* which serves as a generator for the FFC group. G is chosen such that its multiplicative order is a sufficiently large prime divisor of ((p-1)/2).
FFCグループのジェネレータとして機能GF（P）の要素、G、* O。 Gはその乗法順序は（（P-1）/ 2）の十分に大きな素数除数であるように選択されます。
o A prime, r, which is the multiplicative order of G, and thus also the size of the cryptographic subgroup of GF(p)* that is generated by G.
Gの乗法オーダーであるため、またGFの暗号サブグループ（P）のサイズは*ことがGによって生成された素数、R、O
An integer scalar, x, acts on an FFC group element, Y, via exponentiation modulo p -- Y^x mod p.
Y ^ X MOD P - 整数のスカラーは、xは、べき乗剰余Pを介して、FFC族元素、Yに作用します。
The inverse function for an FFC group is defined such that the product of an element and its inverse modulo the group prime equals one (1). In other words,
FFCグループの逆関数は、要素とグループプライムモジュロその逆数の積が1に等しいように定義されている（1）。言い換えると、
(q * inv(q)) mod p = 1
（Q *のINV（Q））MOD p = 1
EAP-pwd uses an IANA registry for the definition of groups. Some FFC groups in this registry are based on safe primes and the order is not included in the domain parameters. In this case only, the order, r, MUST be computed as the prime minus one divided by two -- (p-1)/2. If the definition of the group includes an order in its domain parameters, that value MUST be used in this exchange when an order is called for. If an FFC group definition does not have an order in its domain parameters and it is not based on a safe prime, it MUST NOT be used with EAP-pwd.
EAP-PWDは、グループの定義については、IANAレジストリを使用しています。このレジストリ内のいくつかのFFCグループは、安全素数に基づいており、順序がドメインパラメータには含まれていません。 （P-1）/ 2 - のみこの場合、順序は、R、2で割ったプライムマイナス1として計算されなければなりません。グループの定義は、そのドメインパラメータの順序が含まれている場合、その値は、順序が呼び出され、この交換で使用されなければなりません。 FFCグループの定義は、そのドメインパラメータの順序を持っていないし、それが安全素数に基づいていない場合は、EAP-PWDを使用してはいけません。
Domain parameters for the ECC groups used by EAP-pwd include:
EAP-PWDが使用するECCグループのドメインパラメータが含まれます：
o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group that consists of points on an elliptic curve -- elements from GF(p) that satisfy the curve's equation -- together with the "point at infinity" that serves as the identity element. The group operation for ECC groups is addition of points on the elliptic curve.
素体GF（p）を決定素数、P、O。 GFの要素（P）の曲線の式を満たす - - 識別素子として「無限遠点」と一緒に暗号化グループは、楕円曲線上の点で構成され、完全な楕円曲線群のサブグループであろう。 ECCグループのグループ操作は、楕円曲線上の点の加算です。
o Elements a and b from GF(p) that define the curve's equation. The point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only if (y^2 - x^3 - a*x - b) mod p equals zero (0).
曲線の方程式を定義GF（P）からO要素AおよびB。 GF（p）×GF（p）内の点（x、y）は、楕円曲線上にある場合にのみ（Y ^ 2 - X ^ 3 - A * X - B）MOD pがゼロに等しい（0）。
o A point, G, on the elliptic curve, which serves as a generator for the ECC group. G is chosen such that its order, with respect to elliptic curve addition, is a sufficiently large prime.
O点、G、ECCグループの発電機として機能する楕円曲線上。 Gは、その順序は、楕円曲線加算に対して、十分に大きな素数であるように選択されます。
o A prime, r, which is the order of G, and thus is also the size of the cryptographic subgroup that is generated by G.
Gのオーダーであり、従ってまたG.により生成された暗号サブグループのサイズである素数、R、O
o A co-factor, f, defined by the requirement that the size of the full elliptic curve group (including the "point at infinity") is the product of f and r.
（「無限遠点」を含む）完全な楕円曲線群のサイズはFとRの積である要求によって定義される補因子、F、O。
An integer scalar, x, acts on an ECC group element, Y, via repetitive addition (Y is added to itself x times), also called point multiplication -- x * Y.
整数スカラー、xは、（Y回xをそれ自体に添加される）繰り返し添加によって、ECC族元素、Yに作用する、とも呼ばれる点乗算 - のx *のY.
The inverse function for an ECC group is defined such that the sum of an element and its inverse is the "point at infinity" (the identity for elliptic curve point addition). In other words,
ECCグループの逆関数は、要素とその逆数の和が「無限遠点」（楕円曲線点加算のID）であるように定義されます。言い換えると、
Q + inv(Q) = "O"
Q + INV（Q）= "O"
Only ECC groups over GF(p) can be used by EAP-pwd. ECC groups over GF(2^m) SHALL NOT be used by EAP-pwd. While such groups exist in the IANA registry used by EAP-pwd, their use in EAP-pwd is not defined. In addition, ECC groups with a co-factor greater than one (1) SHALL NOT be used by EAP-pwd. At the time of publication, no such groups existed in the IANA registry used by EAP-pwd.
GF（P）上の唯一のECCグループは、EAP-PWDで使用することができます。 GF（2 ^ m）の上ECCグループは、EAP-PWDにより使用してはなりません。このような基は、EAP-PWDによって使用されるIANAレジストリに存在するが、EAP-PWDにおけるそれらの使用が定義されていません。また、補因子とのECCグループが1より大きい（1）EAP-PWDにより使用してはなりません。公開時点では、そのようなグループは、EAP-PWDが使用するIANAレジストリに存在しません。
In order to see how the protocol addresses the requirements above (see Section 1.3), it is necessary to state some assumptions under which the protocol can be evaluated. They are:
プロトコル（セクション1.3を参照）上記の要件に対処する方法を確認するためには、プロトコルを評価することができるの下でいくつかの仮定を述べる必要があります。彼らです：
1. Function H maps a binary string of indeterminate length onto a fixed binary string that is x bits in length.
1.関数Hは、長さXビットである固定されたバイナリ文字列に不定長のバイナリ列をマッピングします。
H: {0,1}^* --> {0,1}^x
H：{0,1} ^ * - > {0,1} ^ X
2. Function H is a "random oracle" (see [RANDOR]). Given knowledge of the input to H, an adversary is unable to distinguish the output of H from a random data source.
2.関数Hは、 "ランダムオラクル"（[RANDOR]参照します）。 Hへの入力の知識を与え、敵はランダムデータソースからHの出力を区別することができません。
3. Function H is a one-way function. Given the output of H, it is computationally infeasible for an adversary to determine the input.
3.関数Hは一方向関数です。敵対者が入力を決定するためのHの出力を与え、それは計算上実行不可能です。
4. For any given input to function H, each of the 2^x possible outputs are equally probable.
Hを機能させる任意の入力4.、2 ^ Xの可能な出力のそれぞれが等しい確率です。
5. The discrete logarithm problem for the chosen group is hard. That is, given g, p, and y = g^x mod p, it is computationally infeasible to determine x. Similarly, for an ECC group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x.
5.選択されたグループのための離散対数問題が困難です。すなわち、与えられたG、P、及びY = G ^ X MOD pは、Xを決定する計算上実行不可能です。同様に、ECCグループについての曲線の定義、ジェネレータGを与え、そしてY = X * Gは、それがXを決定する計算上実行不可能です。
6. There exists a pool of passwords from which the password shared by the peer and server is drawn. This pool can consist of words from a dictionary, for example. Each password in this pool has an equal probability of being the shared password. All potential attackers have access to this pool of passwords.
6.ピアとサーバで共有パスワードが描かれているから、パスワードのプールが存在します。このプールは、例えば、辞書から単語で構成されます。このプール内の各パスワードは、共有パスワードであることの等しい確率を持っています。すべての潜在的な攻撃者は、パスワードのこのプールへのアクセス権を持っています。
The protocol described in this memo uses a random function, H. As noted in Section 2.3, this is a "random oracle" as defined in [RANDOR]. At first glance, one may view this as a hash function. As noted in [RANDOR], though, hash functions are too structured to be used directly as a random oracle. But they can be used to instantiate the random oracle.
このメモで説明されたプロトコルは、セクション2.3で述べたようにランダム関数Hを使用し、これは[RANDOR]で定義されるように「ランダムオラクル」です。一見、一つのハッシュ関数としてこれを見ることができます。 【RANDOR]で述べたように、しかし、ハッシュ関数は、あまりにもランダムオラクルとして直接使用するように構成されています。しかし、彼らはランダムオラクルをインスタンス化するために使用することができます。
The random function, H, in this memo is instantiated by HMAC-SHA256 (see [RFC4634]) with a key whose length is 32 octets and whose value is zero. In other words,
ランダム関数、Hは、このメモで長さが32個のオクテットであり、その値がゼロであるキーと（[RFC4634]を参照）HMAC-SHA256によってインスタンス化されます。言い換えると、
H(x) = HMAC-SHA-256([0]32, x)
H（X）= HMAC-SHA-256（[0] 32、X）
The keys output by this protocol, MSK and EMSK, are each 512 bits in length. The shared secret that results from the successful termination of this protocol is only 256 bits. Therefore, it is necessary to stretch the shared secret using a key derivation function (KDF).
このプロトコルにより、キー出力、MSK及びEMSKは、それぞれ長さ512ビットです。このプロトコルの正常終了に起因する共有秘密キーは、256ビットです。したがって、鍵導出関数（KDF）を使用して共有秘密を伸ばす必要があります。
The KDF used in this protocol has a counter-mode with feedback construction using a generic pseudo-random function (PRF), according to [SP800-108]. The specific value of the PRF is specified along with the random function and group when the server sends the first EAP-pwd packet to the peer.
このプロトコルで使用されるKDFは[SP800-108]によれば、一般的な擬似ランダム関数（PRF）を用いてフィードバック構成のカウンタモードを有しています。サーバはピアに最初のEAP-PWDパケットを送信する場合PRFの具体的な値は、ランダム関数とグループと一緒に指定されています。
The KDF takes a key to stretch, a label to bind into the key, and an indication of the desired length of the output in bits. It uses two internal variables, i and L, each of which is 16 bits in length and is represented in network order. Algorithmically, it is:
KDFは、ストレッチするキー、キーに結合する標識、及びビット出力の所望の長さの指標をとります。これは、長さが16ビットであり、ネットワークの順で表され、それぞれが2つの内部変数、IおよびLを、使用します。アルゴリズム的に、それは次のようになります。
KDF(key, label, length) {
i = 1
L = length
K(1) = PRF(key, i | label | L)
res = K(1)
while (len(res) < length)
do
i = i + 1
K(i) = PRF(key, K(i-1) | i | label | L)
res = res | K(i)
done
return chop(res, length)
}
Figure 1: Key Derivation Function
図1：鍵導出関数
The security of EAP-pwd relies upon each side, the peer and server, producing quality secret random numbers. A poor random number chosen by either side in a single exchange can compromise the shared secret from that exchange and open up the possibility of dictionary attack.
EAP-PWDのセキュリティは、品質の秘密の乱数を生成し、それぞれの側、ピアとサーバに依存しています。単一交換でどちらかの側が選択した貧しい乱数がその交換機から共有秘密を侵害し、辞書攻撃の可能性を開くことができます。
Producing quality random numbers without specialized hardware entails using a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events. A very good discussion of this can be found in [RFC4086].
特殊なハードウェアなし品質の乱数を生成する情報およびイベントの複数の無相関のソースからエントロピーを蒸留する（強いハッシュ関数のような）暗号混合関数を使用することを伴います。これは非常に良い議論は[RFC4086]で見つけることができます。
The strings representing the server identity and peer identity MUST follow the requirements of [RFC4282] for Network Access Identifiers. This ensures a canonical representation of identities by both ends of the conversation prior to their use in EAP-pwd.
サーバのIDとピアIDを表す文字列は、ネットワークアクセス識別子のための[RFC4282]の要件に従わなければなりません。これは、EAP-PWDでの使用に先立って、会話の両端によるアイデンティティの正規表現を保証します。
EAP-pwd requires passwords be input as binary strings. For the protocol to successfully terminate, each side must produce identical binary strings from the password. This imposes processing requirements on a password prior to its use.
EAP-PWDはパスワードがバイナリ文字列として入力することが必要です。プロトコルが正常に終了するために、それぞれの側は、パスワードと同一のバイナリ文字列を生成しなければなりません。これは、使用前にパスワードの処理要件を課しています。
Three techniques for password pre-processing exist for EAP-pwd:
パスワードの前処理のための3つの技術は、EAP-PWDのために存在します：
o None: The input password string SHALL be treated as an ASCII string or a hexadecimal string with no treatment or normalization performed. The output SHALL be the binary representation of the input string.
Oなし：入力されたパスワード文字列は、ASCII文字列または無処理または正規化を行っと16進数の文字列として扱われてはなりません。出力は、入力文字列のバイナリ表現でなければなりません。
o RFC 2759: The input password string SHALL be processed to produce the output PasswordHashHash, as defined in [RFC2759], including any approved errata to [RFC2759]. This technique is useful when the server does not have access to the plaintext password.
O RFC 2759 [RFC2759]で定義されるように入力されたパスワード文字列は、[RFC2759]に任意の承認された正誤表を含む、出力PasswordHashHashを生成するために処理されます。サーバーが平文のパスワードへのアクセス権を持っていない場合に便利です。
o SASLprep: The input password string is processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHALL be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep pre-processing SHALL cause a failure of pre-processing, and the output SHALL NOT be used with EAP-pwd.
O SASLprep：入力されたパスワード文字列は[RFC3454]の[RFC4013]プロフィールのルールに従って処理されます。パスワードは、[RFC3454]あたりの「保存された文字列」とみなされるものとし、未割り当てコードポイントは、したがって、禁止されています。出力は、処理されたUTF-8文字列のバイナリ表現されなければなりません。 SASLprep前処理で遭遇出力禁止と未割り当てコードポイントは、前処理の失敗を引き起こすものとし、出力がEAP-PWDを使用してはなりません。
Changing a password is out of scope of EAP-pwd, but due to the ambiguities in the way internationalized character strings are handled, 1) it SHOULD be done using SASLprep to ensure a canonical representation of the new password is stored on the server, and 2) subsequent invocations of EAP-pwd SHOULD use SASLprep to ensure that the client generates an identical binary string from the input password.
パスワードを変更すると、EAP-PWDの範囲外であるが、原因国際化文字列の処理方法では曖昧に、1）それは、新しいパスワードの正規表現は、サーバ上に格納されていることを確認するためにSASLprepを使用して行われるべきである、と2）EAP-PWDの後続の呼び出しは、クライアントが入力されたパスワードと同一のバイナリ文字列を発生することを確実にするためにSASLprepを使用すべきです。
EAP is a two-party protocol spoken between an EAP peer and an authenticator. For scaling purposes, the functionality of the authenticator that speaks EAP is frequently broken out into a stand-alone EAP server. In this case, the EAP peer communicates with an EAP server through the authenticator, with the authenticator merely being a passthrough.
EAPは、EAPピアとオーセンティケータの間で話さ2パーティプロトコルです。スケーリングの目的のために、EAPを話すオーセンティケータの機能は、頻繁にスタンドアロンEAPサーバに出て分割されます。この場合、EAPピアはオーセンティケータは、単にパススルーされると、オーセンティケータを介してEAPサーバと通信を行います。
An EAP method defines the specific authentication protocol being used by EAP. This memo defines a particular method and therefore defines the messages sent between the EAP server (or the "EAP server" functionality in an authenticator if it is not broken out) and the EAP peer for the purposes of authentication and key derivation.
EAPメソッドはEAPによって使用されている特定の認証プロトコルを定義します。このメモは、特定の方法を定義し、したがって、（それが出て壊れていない場合、オーセンティケータまたは「EAPサーバ」機能）EAPサーバ間で送信されるメッセージ認証および鍵導出の目的のためにEAPピアを定義します。
EAP-pwd defines three message exchanges: an Identity exchange, a Commit exchange, and a Confirm exchange. A successful authentication is shown in Figure 2.
アイデンティティ交換、コミット交換、及び確認交換：EAP-PWDは、3つのメッセージ交換を定義します。成功した認証は、図2に示されています。
The peer and server use the Identity exchange to discover each other's identities and to agree upon a Ciphersuite to use in the subsequent exchanges; in addition, the EAP Server uses the EAP-pwd-ID/Request message to inform the client of any password pre-processing that may be required. In the Commit exchange, the peer and server exchange information to generate a shared key and also to bind each other to a particular guess of the password. In the Confirm exchange, the peer and server prove liveness and knowledge of the password by generating and verifying verification data.
ピアとサーバは互いのアイデンティティを発見するために、その後の交換に使用するためにも、Ciphersuite合意するアイデンティティ交換を使用します。加えて、EAPサーバが必要になることがあります任意のパスワードの前処理をクライアントに通知するEAP-PWD-ID / Requestメッセージを使用しています。交換、ピアおよびサーバの情報交換、共有鍵を生成すると、パスワードの特定の推測に互いに結合することをコミットで。確認交換では、ピアとサーバは、検証データを生成し、検証することにより、パスワードの生存性と知識を証明します。
+--------+ +--------+
| | EAP-pwd-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-pwd-ID/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 2: A Successful EAP-pwd Exchange
図2：成功したEAP-PWD交換
The components of the EAP-pwd-* messages are as follows:
次のようにEAP-pwd- *メッセージのコンポーネントは次のとおりです。
EAP-pwd-ID/Request Ciphersuite, Token, Password Processing Method, Server_ID
EAP-PWD-ID /要求も、Ciphersuite、トークン、パスワード処理方法、SERVER_ID
EAP-pwd-ID/Response Ciphersuite, Token, Password Processing Method, Peer_ID
EAP-PWD-ID /レスポンスも、Ciphersuite、トークン、パスワード処理方法、Peer_ID
EAP-pwd-Commit/Request Scalar_S, Element_S
EAP-PWD-コミット/リクエストScalar_S、Element_S
EAP-pwd-Commit/Response Scalar_P, Element_P
EAP-PWD-コミット/レスポンスScalar_P、Element_P
EAP-pwd-Confirm/Request Confirm_S
EAP-PWD-確認/リクエストConfirm_S
EAP-pwd-Confirm/Response Confirm_P
EAP-PWD-確認/レスポンスConfirm_P
Once the EAP-pwd-ID exchange is completed, the peer and server use each other's identities and the agreed upon ciphersuite to fix an element in the negotiated group called the Password Element (PWE or pwe, for an element in an ECC group or an FFC group, respectively). The resulting element must be selected in a deterministic fashion using the password but must result in selection of an element that will not leak any information about the password to an attacker. From the point of view of an attacker who does not know the password, the Password Element will be a random element in the negotiated group.
EAP-PWD-IDの交換は、ECCグループ内の要素またはANのために、パスワード要素（PWEまたはPWEと呼ば互いのアイデンティティ、ピアとサーバの使用を完了し、交渉しグループ内の要素を修正するために暗号スイートで合意されたらFFC基、それぞれ）。得られた素子は、パスワードを使用して、決定論的方式で選択されなければならないが、攻撃者にパスワードに関する情報を漏洩しないであろう要素の選択を生じなければなりません。パスワードを知らない攻撃者の観点から、パスワード要素は、交渉し、グループ内のランダムな要素となります。
To properly fix the Password Element, both parties must have a common view of the string "password". Therefore, if a password pre-processing algorithm was negotiated during the EAP-pwd-ID exchange, the client MUST perform the specified password pre-processing prior to fixing the Password Element.
正しくパスワード要素を修正するには、両当事者は、文字列「パスワード」の一般的な見解を持っている必要があります。パスワード前処理アルゴリズムはEAP-PWD-IDの交換中にネゴシエートされた場合したがって、クライアントは、パスワード要素を固定する前に前処理指定されたパスワードを実行しなければなりません。
Fixing the Password Element involves an iterative hunting-and-pecking technique using the prime from the negotiated group's domain parameter set and an ECC- or FFC-specific operation depending on the negotiated group.
パスワード要素を固定することで交渉グループのドメインパラメータセットからのプライムと交渉しグループに応じて、ECC-またはFFC-特定の操作を使用して、反復探求およびつつき技術を必要とします。
First, an 8-bit counter is set to the value one (1). Then, the agreed-upon random function is used to generate a password seed from the identities and the anti-clogging token from the EAP-pwd-ID exchange (see Section 2.8.5.1):
まず、8ビットカウンタが値1（1）に設定されています。その後、合意されたランダム関数は、アイデンティティからパスワードシードとEAP-PWD-ID交換から目詰まり防止トークンを生成するために使用される（セクション2.8.5.1を参照してください）：
pwd-seed = H(token | peer-ID | server-ID | password | counter)
PWD-シード= H（トークン|ピアID |サーバーID |パスワード|カウンタ）
Then, the pwd-seed is expanded using the KDF from the agreed-upon Ciphersuite out to the length of the prime:
その後、PWD-シードが合意されたも、Ciphersuiteプライムの長さにうちからKDFを使用して展開されます。
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
PWD値= KDF（PWD種子、 "EAP-PWD狩猟と盗み"、LEN（P））
If the pwd-value is greater than or equal to the prime, p, the counter is incremented, and a new pwd-seed is generated and the hunting-and-pecking continues. If pwd-value is less than the prime, p, it is passed to the group-specific operation which either returns the selected Password Element or fails. If the group-specific operation fails, the counter is incremented, a new pwd-seed is generated, and the hunting-and-pecking continues. This process continues until the group-specific operation returns the Password Element.
PWD値よりも大きいか素数、Pに等しい場合、カウンタをインクリメントし、新しいPWDシードが生成され、ハンチングアンドつつきは継続します。 PWD-値が素数、p以下であれば、それは選択されたパスワードの要素を返すか、失敗するかのいずれかのグループに固有の操作に渡されます。グループ固有の操作が失敗した場合、カウンタは新しいPWD-シードが生成され、インクリメントされ、狩猟と-つつきは継続します。グループ固有の操作は、パスワード要素を返すまで、このプロセスは継続します。
The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the equation for the curve to produce the Password Element. First, pwd-value is used directly as the x-coordinate, x, with the equation for the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y. If there is no solution to the quadratic equation, this operation fails and the hunting-and-pecking process continues. If a solution is found, then an ambiguity exists as there are technically two solutions to the equation and pwd-seed is used to unambiguously select one of them. If the low-order bit of pwd-seed is equal to the low-order bit of y, then a candidate PWE is defined as the point (x, y); if the low-order bit of pwd-seed differs from the low-order bit of y, then a candidate PWE is defined as the point (x, p - y), where p is the prime over which the curve is defined. The candidate PWE becomes PWE, and the hunting and pecking terminates successfully.
ECCグループのグループ固有の操作はPWD値、PWD-種子、及びパスワード要素を生成するために、曲線の方程式を使用します。まず、PWD値は、y座標yについて解くために、曲線のドメインパラメータセットからパラメータa及びbと、楕円曲線の方程式を用いて、x座標、Xとして直接使用されます。二次方程式の解がない場合、この操作は失敗し、狩猟と-つつき処理が続行されます。溶液が見つかった場合、曖昧さは、明確にそれらのいずれかを選択するために使用される方程式とPWD種子への2つの解決策が技術的に存在するように存在します。 PWD種子の下位ビットは、Yの下位ビットに等しい場合、候補PWEは、点（x、y）として定義されます。 pが曲線が定義される上素数である、 - PWD種子の下位ビットは、Yの下位ビットと異なる場合、その候補PWEは、点（Y、X、P）として定義されます。候補PWEはPWEになり、狩猟とつつきが正常に終了します。
Algorithmically, the process looks like this:
アルゴリズム的に、プロセスは次のようになります。
found = 0 counter = 1 do { pwd-seed = H(token | peer-ID | server-ID | password | counter) pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) if (pwd-value < p) then x = pwd-value if ( (y = sqrt(x^3 + ax + b)) != FAIL) then if (LSB(y) == LSB(pwd-seed)) then PWE = (x, y) else PWE = (x, p-y) fi found = 1 fi fi counter = counter + 1 } while (found == 0)
見出さ= 0カウンタ= 1行う{PWD種子= H（トークン|ピアID |サーバID |パスワード|カウンタ）PWD値= KDF（PWD種子、 "EAP-PWD狩猟と盗み"、LEN（P ））（PWD値<P）をX = PWD値をIF（（Y = SQRT（X ^ 3 + AX + B））！= FAIL）をIF（LSB（Y）== LSB（PWD種子なら（実測値== 0）間））をPWE =（x、y）は他PWE =（X、PY）Fiは} = 1つのfi Fiのカウンタ=カウント+ 1を発見しました
Figure 3: Fixing PWE for ECC Groups
図3：ECCグループのためPWEを修正
The group-specific operation for FFC groups takes pwd-value, and the prime, p, and order, r, from the group's domain parameter set (see Section 2.2.1 when the order is not part of the defined domain parameter set) to directly produce a candidate Password Element, pwe, by exponentiating the pwd-value to the value ((p-1)/r) modulo the prime. If the result is greater than one (1), the candidate pwe becomes pwe, and the hunting and pecking terminates successfully.
FFCグループのグループ固有の操作は、グループのドメイン・パラメータ・セット（順序は定義されたドメインパラメータセットの一部ではない場合、セクション2.2.1を参照）からに、R、PWD値をとり、素数、p及び順序直接エレメント、PWE、値にPWD値を累乗することによって、候補のパスワードを生成する（（P-1）/ r）は、素数を法。結果は、（1）1より大きい場合、候補PWEはPWEになり、狩猟とつつきが正常に終了します。
Algorithmically, the process looks like this:
アルゴリズム的に、プロセスは次のようになります。
found = 0 counter = 1 do { pwd-seed = H(token | peer-ID | server-ID | password | counter) pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) if (pwd-value < p) then pwe = pwd-value ^ ((p-1)/r) mod p if (pwe > 1) then found = 1 fi fi counter = counter + 1 } while (found == 0)
見出さ= 0カウンタ= 1行う{PWD種子= H（トークン|ピアID |サーバID |パスワード|カウンタ）PWD値= KDF（PWD種子、 "EAP-PWD狩猟と盗み"、LEN（P ））場合（PWD値<P）をPWE = PWD値^（（P-1）/ R）MOD P（PWE場合>（実測しながら1）を} = 1つのfi Fiのカウンタ=カウント+ 1を発見= = 0）
Figure 4: Fixing PWE for FFC Groups
図4：FFCグループのためPWEを修正
After the EAP-pwd Identity exchange, the construction of the components of subsequent messages depends on the type of group from the ciphersuite (ECC or FFC). This section provides an overview of the authenticated key exchange. For a complete description of message generation and processing, see Sections 2.8.5.2 and 2.8.5.3.
EAP-PWDアイデンティティ交換後、後続のメッセージの構成要素の構成は、暗号スイート（ECCまたはFFC）から基の種類に依存します。このセクションでは、認証鍵交換の概要を説明します。メッセージ生成および処理の詳細については、セクション2.8.5.2および2.8.5.3を参照。
Using the mapping function F() defined in Section 2.2.2 and the group order r:
セクション2.2.2で定義されたマッピング関数F（）およびグループの順序rを使用して：
Server: EAP-pwd-Commit/Request - choose two random numbers, 1 < s_rand, s_mask < r - compute Scalar_S = (s_rand + s_mask) mod r - compute Element_S = inv(s_mask * PWE)
サーバ：EAP-PWD-コミット/リクエスト - 計算Scalar_Sの=（s_rand + S_MASK）MOD R - - 計算Element_S =のINV（S_MASK * PWE）2つの乱数、1 <s_rand、S_MASK <Rを選択
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
Element_SとScalar_Sは、EAP-PWD-コミット/リクエストを構築するために使用されています
Peer: EAP-pwd-Commit/Response - choose two random numbers, 1 < p_rand, p_mask < r - compute Scalar_P = (p_rand + p_mask) mod r - compute Element_P = inv(p_mask * PWE)
ピア：EAP-PWD-コミット/応答 - 2個の乱数を選択し、1 <p_rand、p_mask <R - MOD RをScalar_P =（p_rand + p_mask）を計算 - Element_Pを計算= INV（p_mask * PWE）
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
Element_PとScalar_Pは、EAP-PWD-コミット/レスポンスを構築するために使用されています
Server: EAP-pwd-Confirm/Request - compute KS = (s_rand * (Scalar_P * PWE + Element_P)) - compute ks = F(KS) - compute Confirm_S = H(ks | Element_S | Scalar_S | Element_P | Scalar_P | Ciphersuite)
サーバー：EAP-PWD-確認/リクエスト - 計算KS = F（KS） - - KS =（s_rand *（Scalar_P * PWE + Element_P））を計算し、計算Confirm_Sの=をH（KS | Element_S | Scalar_S | Element_P | Scalar_P |も、Ciphersuite）
Confirm_S is used to construct EAP-pwd-Confirm/Request
Confirm_Sは、EAP-PWD-確認/リクエストを構築するために使用されます
Peer: EAP-pwd-Confirm/Response - compute KP = (p_rand * (Scalar_S * PWE + Element_S)), - compute kp = F(KP) - compute Confirm_P = H(kp | Element_P | Scalar_P | Element_S | Scalar_S | Ciphersuite)
ピア：EAP-PWD-確認/レスポンス - 計算KP = F（KP） - - KP =（p_rand *（Scalar_S * PWE + Element_S））を、計算を計算Confirm_P = H（KP | Element_P | Scalar_P | Element_S | Scalar_S |も、Ciphersuite ）
Confirm_P is used to construct EAP-pwd-Confirm/Response
Confirm_Pは、EAP-PWD-確認/レスポンスを構築するために使用されます
The EAP Server computes the shared secret as: MK = H(ks | Confirm_P | Confirm_S)
MK = H（| Confirm_P | Confirm_S KS）：EAPサーバは、共有秘密を計算します
The EAP Peer computes the shared secret as: MK = H(kp | Confirm_P | Confirm_S)
EAPピアとして共有秘密を計算：MK = H（KP | Confirm_P | Confirm_S）
The MSK and EMSK are derived from MK per Section 2.9.
MSKとEMSKは、セクション2.9あたりMKから派生しています。
There is no mapping function, F(), required for an FFC group. Using the order, r, for the group (see Section 2.2.1 when the order is not part of the defined domain parameters):
FFCグループのために必要な一切のマッピング関数、F（）は、ありません。順序を使用して、R、グループのために（順序は定義されたドメインパラメータの一部でない場合、セクション2.2.1を参照）。
Server: EAP-pwd-Commit/Request - choose two random numbers, 1 < s_rand, s_mask < r - compute Scalar_S = (s_rand + s_mask) mod r - compute Element_S = inv(pwe^s_mask mod p)
サーバ：EAP-PWD-コミット/リクエスト - 2つの乱数、1 <s_rand、S_MASK <R選択 - 計算Scalar_S =（s_rand + S_MASK）をMOD R - 計算Element_Sの=のINV（PWE ^ S_MASK MOD P）
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
Element_SとScalar_Sは、EAP-PWD-コミット/リクエストを構築するために使用されています
Peer: EAP-pwd-Commit/Response - choose random two numbers, 1 < p_rand, p_mask < r - compute Scalar_P = (p_rand + p_mask) mod r - compute Element_P = inv(pwe^p_mask mod p)
ピア：EAP-PWD-コミット/レスポンス - 、ランダムな2つの数値を選択し、1 <p_rand、p_mask <R - Scalar_P =（p_rand + p_mask）を計算MOD R - Element_P = INV（PWE ^ p_mask MOD p）を計算します
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
Element_PとScalar_Pは、EAP-PWD-コミット/レスポンスを構築するために使用されています
Server: EAP-pwd-Confirm/Request - compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p - compute Confirm_S = H(ks | Element_S | Scalar_S | Element_P | Scalar_P | Ciphersuite)
サーバー：EAP-PWD-確認/リクエスト - 計算のKS =（（PWE ^ Scalar_PモッズP）* Element_P）^ s_randモッズp - で計算Confirm_Sの=のH（KS | Element_S | Scalar_S | Element_P | Scalar_P |も、Ciphersuite）
Confirm_S is used to construct EAP-pwd-Confirm/Request
Confirm_Sは、EAP-PWD-確認/リクエストを構築するために使用されます
Peer: EAP-pwd-Confirm/Response - compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p - compute Confirm_P = H(kp | Element_P | Scalar_P | Element_S | Scalar_S | Ciphersuite)
ピア：EAP-PWD-確認/レスポンス - 計算KP =（（PWE ^ Scalar_SモッズP）* Element_S）^ p_randモッズp - で計算Confirm_P = H（KP | Element_P | Scalar_P | Element_S | Scalar_S |も、Ciphersuite）
Confirm_P is used to construct EAP-pwd-Confirm/Request
Confirm_Pは、EAP-PWD-確認/リクエストを構築するために使用されます
The EAP Server computes the shared secret as: MK = H(ks | Confirm_P | Confirm_S)
MK = H（| Confirm_P | Confirm_S KS）：EAPサーバは、共有秘密を計算します
The EAP Peer computes the shared secret as: MK = H(kp | Confirm_P | Confirm_S)
EAPピアとして共有秘密を計算：MK = H（KP | Confirm_P | Confirm_S）
The MSK and EMSK are derived from MK per Section 2.9.
MSKとEMSKは、セクション2.9あたりMKから派生しています。
Although EAP provides an Identity method to determine the identity of the peer, the value in the Identity Response may have been truncated or obfuscated to provide privacy or decorated for routing purposes [RFC3748], making it inappropriate for usage by the EAP-pwd method. Therefore, the EAP-pwd-ID exchange is defined for the purpose of exchanging identities between the peer and server.
EAPピアのアイデンティティを決定するための識別方法を提供するが、アイデンティティ応答の値は切り捨て又は難読化されたプライバシーを提供するために、またはルーティング目的[RFC3748]のために装飾され、EAP-PWD方法による使用のために、それは不適切製造されていてもよいです。したがって、EAP-PWD-IDの交換は、ピアとサーバとの間のIDを交換する目的のために定義されています。
The EAP-pwd-ID/Request contains the following quantities:
EAP-PWD-ID /要求は、以下の量が含まれています。
o a ciphersuite
暗号スイートO
o a representation of the server's identity per Section 2.7.1
Oセクション2.7.1あたりのサーバのアイデンティティの表現
o an anti-clogging token
目詰まり防止トークンO
o a password pre-processing method
Oパスワード前処理方法
The ciphersuite specifies the finite cyclic group, random function, and PRF selected by the server for use in the subsequent authentication exchange.
暗号スイートは、後続の認証交換で使用するためにサーバによって選択された有限巡回群、ランダム関数、およびPRFを指定します。
The value of the anti-clogging token MUST be unpredictable and SHOULD NOT be from a source of random entropy. The purpose of the anti-clogging token is to provide the server an assurance that the peer constructing the EAP-pwd-ID/Response is genuine and not part of a flooding attack.
抗詰まりトークンの値は予測不可能でなければなりませんとランダムエントロピーの供給源からであるべきではありません。目詰まり防止トークンの目的は、EAP-PWD-ID /レスポンスを構築するピアが本物とフラッド攻撃の一部ではないことをサーバーに保証を提供することです。
A password pre-processing method is communicated to ensure interoperability by producing a canonical representation of the password string between the peer and server (see Section 2.7.2).
パスワード前処理方法は、ピアとサーバ間のパスワード文字列の正規表現を生成することによって、相互運用性を確保するために通信される（セクション2.7.2参照）。
The EAP-pwd-ID/Request is constructed according to Section 3.2.1 and is transmitted to the peer.
EAP-PWD-ID /要求は3.2.1に従って構成され、ピアに送信されます。
Upon receipt of an EAP-pwd-ID/Request, the peer determines whether the ciphersuite and pre-processing method are acceptable. If not, the peer MUST respond with an EAP-NAK. If acceptable, the peer responds to the EAP-pwd-ID/Request with an EAP-pwd-ID/Response, constructed according to Section 3.2.1, that acknowledges the Ciphersuite, token, and pre-processing method and then adds its identity. After sending the EAP-pwd-ID/Response, the peer has the identity of the server (from the Request), its own identity (it encoded in the Response), a password pre-processing algorithm, and it can compute the Password Element as specified in Section 2.8.3. The Password Element is stored in state allocated for this exchange.
EAP-PWD-ID /要求を受信すると、ピアは、暗号の組み合わせと前処理方法が許容可能であるか否かを判断します。そうでない場合、ピアは、EAP-NAKで応じなければなりません。許容される場合、ピアはトークンCipherSuiteで、認めセクション3.2.1、および前処理方法に従って構成EAP-PWD-ID /レスポンスとEAP-PWD-ID /要求に応答し、その識別情報を付加します。 EAP-PWD-ID /応答を送信した後、ピアは、それ自身のアイデンティティ（それが応答でコードされる）、パスワード前処理アルゴリズム（リクエストから）サーバの同一性を有し、そしてそれは、パスワード要素を計算することができますセクション2.8.3で指定されています。パスワード要素は、この交換のために割り当てられた状態で保存されます。
The EAP-pwd-ID/Response acknowledges the Ciphersuite from the Request, acknowledges the anti-clogging token from the Request providing a demonstration of "liveness" on the part of the peer, and contains the identity of the peer. Upon receipt of the Response, the server verifies that the Ciphersuite acknowledged by the peer is the same as that sent in the Request and that the anti-clogging token added by the peer in the Response is the same as that sent in the Request. If Ciphersuites or anti-clogging tokens differ, the server MUST respond with an EAP-Failure message. If the anti-clogging tokens are the same, the server knows the peer is an active participant in the exchange. If the Ciphersuites are the same, the server now knows its own identity (it encoded in the Request) and the peer's identity (from the Response) and can compute the Password
EAP-PWD-ID /応答が要求からCipherSuiteで認識し、ピアの一部の「生存性」のデモを提供要求から目詰まり防止トークンを認識し、ピアの識別が含まれています。応答を受信すると、サーバは、ピアによって応答も、Ciphersuiteリクエストで送信されたものと同じであり、それに応答して、ピアによって追加の抗詰まりトークンことリクエストで送信されたものと同じであることを検証します。暗号の組み合わせや目詰まり防止のトークンが異なる場合は、サーバがEAP失敗メッセージで応じなければなりません。目詰まり防止のトークンが同じであれば、サーバはピアが交流に積極的に参加して知っています。暗号の組み合わせが同じであれば、サーバは今（レスポンス）から、自身のアイデンティティ（それが要求でエンコード）し、ピアのアイデンティティを知っていて、パスワードを計算することができます
Element according to Section 2.8.3. The server stores the Password Element in state it has allocated for this exchange. The server then initiates an EAP-pwd-Commit exchange.
2.8.3項に従って要素。サーバーは、それがこの交換のために割り当てられている状態でパスワード要素を格納します。その後、サーバはEAP-PWD-コミット交換を開始します。
The server begins the EAP-pwd-Confirm exchange by choosing two random numbers, s_rand and s_mask, between 1 and r (where r is described in Section 2.1 according to the group established in Section 2.8.5.1) such that their sum modulo r is greater than one (1). It then computes Element_S and Scalar_S as defined in Section 2.8.4 and constructs an EAP-pwd-Commit/Request according to Section 3.2.2. Element_S and Scalar_S are added to the state allocated for this exchange, and the EAP-pwd-Commit/Request is transmitted to the peer.
サーバは、そのようなものがそれらの合計のモジュロRであること（式中、Rは、セクション2.8.5.1で確立グループに従ってセクション2.1に記載されている）1とRとの間に2つの乱数、s_randとS_MASKを選択することによって、EAP-PWD - 確認交換を開始します1より大きい（1）。その後、セクション2.8.4で定義されるようElement_SとScalar_Sを計算し、セクション3.2.2に従ってEAP-PWD-コミット/リクエストを構築します。 Element_SとScalar_Sはこの交換のために割り当てられた状態に加え、EAP-PWD-コミット/要求がピアに送信されます。
Upon receipt of the EAP-pwd-Commit/Request, the peer validates the length of the entire payload based upon the expected lengths of Element_S and Scalar_S (which are fixed according to the length of the agreed-upon group). If the length is incorrect, the peer MUST terminate the exchange. If the length is correct, Element_S and Scalar_S are extracted from the EAP-pwd-Commit/Request. Scalar_S is then checked to ensure it is between 1 and r, exclusive. If it is not, the peer MUST terminate the exchange. If it is, Element_S MUST be validated depending on the type of group -- Element validation for FFC groups is described in Section 2.8.5.2.1, and Element validation for ECC groups is described in Section 2.8.5.2.2. If validation is successful, the peer chooses two random numbers, p_rand and p_mask, between 1 and r (where r is described in Section 2.1 according to the group established in Section 2.8.5.1) such that their sum modulo r is greater than one (1), and computes Element_P and Scalar_P. Next, the peer computes kp from p_rand, Element_S, Scalar_S, and the Password Element according to Section 2.8.4. If kp is the "identity element" -- the point at infinity for an ECC group or the value one (1) for an FFC group -- the peer MUST terminate the exchange. If not, the peer uses Element_P and Scalar_P to construct an EAP-pwd-Commit/Response according to Section 3.2.2 and transmits the EAP-pwd-Commit/Response to the server.
EAP-PWD-コミット/要求を受信すると、ピアは（合意されたグループの長さに応じて固定されている）Element_SとScalar_Sの予想される長さに基づいて、ペイロード全体の長さを検証します。長さが正しくない場合、ピアは交換を終えなければなりません。長さが正しい場合、Element_SとScalar_SはEAP-PWD-コミット/要求から抽出されます。 Scalar_Sは、それが1とr、排他的との間にあることを確認するためにチェックされています。そうでない場合は、ピアは交換を終えなければなりません。もしそうであれば、Element_Sは、グループの種類に応じて検証する必要があり - FFCグループの要素の検証は、セクション2.8.5.2.1に記載されており、ECCグループの要素の検証はセクション2.8.5.2.2に記載されています。検証が成功した場合、ピアは1とR（Rは、セクション2.8.5.1で確立グループに従ってセクション2.1に記載されている場合）、それらの和モジュロrが1よりも大きいように（間に、2つの乱数、p_randとp_maskを選択します1）、及びElement_PとScalar_Pを計算します。次に、ピアはp_rand、Element_S、Scalar_SからKPを計算し、パスワード要素セクション2.8.4に記載の方法。 ECCグループの無限遠点または値1（1）FFCグループの - - Kpは「識別要素」である場合、ピアは、交換を終了しなければなりません。そうでない場合、ピアは3.2.2に従ってEAP-PWD-コミット/応答を構築するためにElement_PとScalar_Pを使用してサーバにEAP-PWD-コミット/応答を送信します。
Upon receipt of the EAP-pwd-Commit/Response, the server validates the length of the entire payload based upon the expected lengths of Element_P and Scalar_P (which are fixed according to the agreed-upon group). If the length is incorrect, the server MUST respond with an EAP-Failure message, and it MUST terminate the exchange and free up any state allocated. If the length is correct, Scalar_P and Element_P are extracted from the EAP-pwd-Commit/Response and compared to Scalar_S and Element_S. If Scalar_P equals Scalar_S and Element_P equals Element_S, it indicates a reflection attack and the server MUST respond with an EAP-failure and terminate the exchange. If they differ, Scalar_P is checked to ensure it is between 1 and r, exclusive. If not the server MUST respond with an EAP-failure and terminate the exchange. If it is, Element_P is verified depending on the type of group -- Element validation for FFC groups is described in Section 2.8.5.2.1, and Element validation for ECC groups is described in Section 2.8.5.2.2. If validation is successful, the server computes ks from s_rand, Element_P, Scalar_P, and the Password Element according to Section 2.8.4. If ks is the "identity element" -- the point at infinity for an ECC group or the value one (1) for an FFC group -- the server MUST respond with an EAP-failure and terminate the exchange. Otherwise, the server initiates an EAP-pwd-Confirm exchange.
EAP-PWD-コミット/応答を受信すると、サーバは、（合意されたグループに応じて固定されている）Element_PとScalar_Pの予想される長さに基づいて、ペイロード全体の長さを検証します。長さが間違っている場合は、サーバがEAP失敗メッセージで応じなければなりません、そして、それは交換を終了し、割り当てられた任意の状態を解放しなければなりません。長さが正しい場合、Scalar_PとElement_PはEAP-PWD-コミット/応答から抽出しScalar_SとElement_Sと比較されます。 Scalar_PはScalar_Sに等しく、Element_PはElement_Sに等しい場合には、反射攻撃を示しており、サーバがEAP-失敗で応答し、交換を終えなければなりません。それらが異なる場合は、Scalar_Pは、それが1とr、排他的との間にあることを確認するためにチェックされています。そうでない場合、サーバーは、EAP-失敗で応答し、交換を終えなければなりません。 FFCグループの要素の検証は、セクション2.8.5.2.1に記載されており、ECCグループの要素の検証はセクション2.8.5.2.2に記載されている - そうである場合、Element_Pは、グループの種類に応じて検証されます。検証が成功した場合、サーバは、セクション2.8.4によるs_rand、Element_P、Scalar_P、およびパスワード要素からKSを計算します。 ECCグループの無限遠点または値1（1）FFCグループの - - KS「は同一の要素」である場合、サーバはEAP-失敗に応答し、交換を終了しなければなりません。そうしないと、サーバはEAP-PWD-確認交換を開始します。
A received FFC Element is valid if: 1) it is between one (1) and the prime, p, exclusive; and 2) if modular exponentiation of the Element by the group order, r, equals one (1). If either of these conditions are not true the received Element is invalid.
1）それが1（1）と素数、P、排他的との間にある、次の場合受信FFC要素が有効です2）グループの順序によって要素のべき乗剰余演算は、R、1に等しい場合には（1）。これらの条件のいずれかが真でない場合は受信要素が無効です。
Validating a received ECC Element involves: 1) checking whether the two coordinates, x and y, are both greater than zero (0) and less than the prime defining the underlying field; and 2) checking whether the x- and y-coordinates satisfy the equation of the curve (that is, that they produce a valid point on the curve that is not the point at infinity). If either of these conditions are not met, the received Element is invalid; otherwise, the Element is valid.
受信されたECC要素を検証することを含む：1）は、2点の座標、x及びyは、両方とも0（ゼロより大きい）とその下にあるフィールドを定義する素数未満であるか否かをチェックします。 2）x座標とy座標は、それらが無限遠点）ではない曲線上有効なポイントを生成すること、すなわち（曲線の方程式を満たしているかどうかをチェックします。これらの条件のいずれかが満たされていない場合、受信要素が無効です。そうでない場合は、要素が有効です。
The server computes Confirm_S according to Section 2.8.4, constructs an EAP-pwd-Confirm/Request according to Section 3.2.3, and sends it to the peer.
サーバは、セクション2.8.4に従ってConfirm_Sを計算し、セクション3.2.3に従ってEAP-PWD-確認/要求を構築し、ピアに送信します。
Upon receipt of an EAP-pwd-Confirm/Request, the peer validates the length of the entire payload based upon the expected length of Confirm_S (whose length is fixed by the agreed-upon random function). If the length is incorrect, the peer MUST terminate the exchange and free up any state allocated. If the length is correct, the peer verifies that Confirm_S is the value it expects based on the value of kp. If the value of Confirm_S is incorrect, the peer MUST terminate the exchange and free up any state allocated. If the value of Confirm_S is correct, the peer computes Confirm_P, constructs an EAP-pwd-Confirm/Response according to Section 3.2.3, and sends it off to the server. The peer then computes MK (according to Section 2.8.4) and the MSK and EMSK (according to Section 2.9) and stores these keys
EAP-PWD-確認/要求を受信すると、ピアは（長合意されたランダム機能により固定されている）Confirm_Sの予想される長さに基づいて、ペイロード全体の長さを検証します。長さが正しくない場合、ピアは交換を終了し、割り当てられた任意の状態を解放しなければなりません。長さが正しい場合、ピアはConfirm_SそれがKPの値に基づいて、期待値であることを検証します。 Confirm_Sの値が正しくない場合、ピアは交換を終了し、割り当てられた任意の状態を解放しなければなりません。 Confirm_Sの値が正しい場合、ピアはConfirm_Pを計算し、セクション3.2.3に従ってEAP-PWD-確認/応答を構築し、サーバーにそれを送信します。ピアは、次いで、（2.9節に従う）MK（セクション2.8.4による）及びMSK及びEMSKを計算し、これらのキーを格納します
in state allocated for this exchange. The peer SHOULD export the MSK and EMSK at this time in anticipation of a secure association protocol by the lower layer to create session keys. Alternatively, the peer can wait until an EAP-Success message from the server before exporting the MSK and EMSK.
状態でこの交換用に割り当てられました。ピアは、セッションキーを作成するために、下位層でのセキュアアソシエーションプロトコルを見越して、この時点でMSK及びEMSKをエクスポートする必要があります。また、ピアはMSKとEMSKをエクスポートする前に、サーバーからのEAP-Successメッセージまで待つことができます。
Upon receipt of an EAP-pwd-Confirm/Response, the server validates the length of the entire payload based upon the expected length of Confirm_P (whose length is fixed by the agreed-upon random function). If the length is incorrect, the server MUST respond with an EAP-Failure message, and it MUST terminate the exchange and free up any state allocated. If the length is correct, the server verifies that Confirm_P is the value it expects based on the value of ks. If the value of Confirm_P is incorrect, the server MUST respond with an EAP-Failure message. If the value of Confirm_P is correct, the server computes MK (according to Section 2.8.4) and the MSK and EMSK (according to Section 2.9). It exports the MSK and EMSK and responds with an EAP-Success message. The server SHOULD free up state allocated for this exchange.
EAP-PWD-確認/応答を受信すると、サーバは、（長さが合意されたランダム機能により固定されている）Confirm_Pの予想される長さに基づいて、ペイロード全体の長さを検証します。長さが間違っている場合は、サーバがEAP失敗メッセージで応じなければなりません、そして、それは交換を終了し、割り当てられた任意の状態を解放しなければなりません。長さが正しければ、サーバはConfirm_Pが、それはKSの値に基づいて、期待した値であることを確認します。 Confirm_Pの値が正しくない場合、サーバーは、EAP失敗メッセージで応じなければなりません。 Confirm_Pの値が正しい場合、サーバは、（セクション2.9に従って）MK（セクション2.8.4による）及びMSK及びEMSKを計算します。これは、MSKとEMSKをエクスポートし、EAP-Successメッセージで応答します。サーバーは、この交換用に割り当てられた状態を解放する必要があります。
[RFC5247] recommends each EAP method define how to construct a Method-ID and Session-ID to identify a particular EAP session between a peer and server. This information is constructed thusly:
[RFC5247]は、各EAP方式は、ピアとサーバとの間の特定のEAPセッションを識別するための方法-IDとセッションIDを構築する方法を定義するお勧めします。この情報はthuslyに構築されています。
Method-ID = H(Ciphersuite | Scalar_P | Scalar_S)
方法-ID = H（も、Ciphersuite | Scalar_P | Scalar_S）
Session-ID = Type-Code | Method-ID
セッションID =タイプコード|この方法-ID
where Ciphersuite, Scalar_P, and Scalar_S are from the specific exchange being identified; H is the random function specified in the Ciphersuite; and, Type-Code is the code assigned for EAP-pwd, 52, represented as a single octet.
Ciphersuite、Scalar_P、及びScalar_S特定の交換機からのものである場合に識別されます。 Hはも、Ciphersuiteで指定されたランダム関数です。そして、タイプコードは、単一のオクテットとして表さEAP-PWDのために割り当てられたコード、52、です。
The authenticated key exchange of EAP-pwd generates a shared and authenticated key, MK. The size of MK is dependent on the random function, H, asserted in the Ciphersuite. EAP-pwd must export two 512-bit keys, MSK and EMSK. Regardless of the value of len(MK), implementations MUST invoke the KDF defined in Section 2.5 to construct the MSK and EMSK. The MSK and EMSK are derived thusly:
EAP-PWDの認証された鍵交換はMK、共有、認証キーを生成します。 MKの大きさはランダム関数に依存して、Hは、も、Ciphersuiteに主張しました。 EAP-PWDは2 512ビットキー、MSKとEMSKをエクスポートする必要があります。かかわらず、LEN（MK）の値が、実装はMSKおよびEMSKを構築するために、セクション2.5で定義されたKDFを呼び出さなければなりません。 MSKとEMSKはthusly導出されています。
MSK | EMSK = KDF(MK, Session-ID, 1024)
MSK | EMSK = KDF（MK、セッションID、1024）
[RFC4962] mentions the importance of naming keys, particularly when key caching is being used. To facilitate such an important optimization, names are assigned thusly: o EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K'
[RFC4962]キーキャッシングが使用されている場合は特に、命名鍵の重要性に言及しています。そのような重要な最適化を容易にするために、名前がthusly割り当てられています。EMSK名O =セッションID | 'E' | 'M' | 'S' | 'K'
o MSK-name = Session-ID | 'M'| 'S' | 'K'
O MSK-名=セッションID | 'M' | 'S' | 'K'
where 'E' is a single octet of value 0x45, 'M' is a single octet of value 0x4d, 'S' is a single octet of value 0x53, and 'K' is a single octet of value 0x4b.
「E」は、値0x45の単一オクテットであり、「M」は値0x4dの単一オクテットであり、「S」は、値$ 53の単一オクテットであり、「K」が値0x4bの単一オクテットです。
This naming scheme allows for key-management applications to quickly and accurately identify keys for a particular session or all keys of a particular type.
この命名方式は、迅速かつ正確に特定のセッションまたは特定のタイプのすべてのキーのキーを識別するための鍵管理アプリケーションが可能になります。
For the purposes of interoperability, compliant EAP-pwd implementations SHALL support the following parameters:
相互運用性の目的のために、対応EAP-PWDの実装は、次のパラメータをサポートしていなければなりません。
o Diffie-Hellman Group: group 19 defined in [RFC5114]
OのDiffie-Hellmanのグループ：グループ19は、[RFC5114]で定義され
o Random Function: defined in Section 2.4
Oランダム機能：2.4節で定義されています
o PRF: HMAC-SHA256 defined in [RFC4634]
O PRF：HMAC-SHA256 [RFC4634]で定義され
o Password Pre-Processing: none
Oパスワードの前処理：なし
The EAP-pwd header has the following structure:
EAP-PWDヘッダは、以下の構造を有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |L|M| PWD-Exch | Total-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-pwd Header
図5：EAP-PWDヘッダー
Code
コード
Either 1 (for Request) or 2 (for Response); see [RFC3748].
いずれかの1（要求）または（応答の場合）2。 [RFC3748]を参照してください。
Identifier
識別
The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet.
識別子フィールドは、リクエストとレスポンスのマッチングで1つのオクテットとエイズです。識別子フィールドは、各Requestパケットに変更する必要があります。
Length
長さ
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception.
長さフィールドは2つのオクテットで、コード、識別子、長さ、タイプ、およびデータフィールドを含むEAPパケットの長さを示します。長さフィールドの範囲外のオクテットは、データリンク層のパディングとして扱われるべきとレセプションで無視しなければなりません。
Type
タイプ
52 - EAP-pwd
52 - EAP-PWD
L and M bits
LとMビット
The L bit (Length included) is set to indicate the presence of the two-octet Total-Length field, and MUST be set for the first fragment of a fragmented EAP-pwd message or set of messages.
Lビットは、（長さを含む）2オクテットの総数-Lengthフィールドの存在を示すために設定され、断片化されたEAP-PWDメッセージの最初のフラグメントに対して設定またはメッセージの設定しなければなりません。
The M bit (more fragments) is set on all but the last fragment.
Mビット（複数の断片）が最後のフラグメント以外のすべてに設定されています。
PWD-Exch
PWD交換
The PWD-Exch field identifies the type of EAP-pwd payload encapsulated in the Data field. This document defines the following values for the PWD-Exch field:
PWD-エクスチェンジクラブフィールドは、データフィールドにカプセル化されたEAP-PWDペイロードのタイプを識別する。この文書では、PWD-エクスチェンジクラブフィールドに次の値を定義します。
* 0x00 : Reserved
* $ 00：リザーブ
* 0x01 : EAP-pwd-ID exchange
* 0×01：EAP-PWD-ID交換
* 0x02 : EAP-pwd-Commit exchange
* 0×02：交換がEAP-PWD-コミット
* 0x03 : EAP-pwd-Confirm exchange
* 0×03：EAP-PWD-確認交換
All other values of the PWD-Exch field are unassigned.
PWD-エクスチェンジクラブフィールドの他のすべての値が割り当てられていません。
Total-Length
全長
The Total-Length field is two octets in length, and is present only if the L bit is set. This field provides the total length of the EAP-pwd message or set of messages that is being fragmented.
全長さフィールドの長さは2つのオクテットであり、Lビットが設定されている場合にのみ存在します。このフィールドはEAP-PWDメッセージの全長を提供または断片化されているメッセージのセット。
EAP-pwd payloads all contain the EAP-pwd header and encoded information. Encoded information is comprised of sequences of data. Payloads in the EAP-pwd-ID exchange also include a ciphersuite statement indicating what finite cyclic group to use, what cryptographic primitive to use for H, and what PRF to use for deriving keys.
EAP-PWDペイロードはすべて、EAP-PWDヘッダと符号化された情報を含みます。符号化された情報は、データの列で構成されています。 EAP-PWD-ID交換におけるペイロードはまた、プリミティブ暗号何Hに使用する、どのようなPRFキーを導出するために使用する、有限巡回群を使用するかを示す暗号のステートメントを含みます。
The Group Description, Random Function, and PRF together, and in that order, comprise the Ciphersuite included in the calculation of the peer's and server's confirm messages.
グループの説明、ランダム関数、およびPRF一緒に、そしてそのためには、も、Ciphersuiteはピアの、サーバーの確認メッセージの計算に含ま含みます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Description | Random Func'n | PRF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prep | Identity...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-pwd-ID Payload
図6：EAP-PWD-IDペイロード
The Group Description field value is taken from the IANA registry for "Group Description" created by IKE [RFC2409].
グループの説明フィールド値はIKE [RFC2409]で作成された「グループの説明」のためのIANAレジストリから取得されます。
This document defines the following value for the Random Function field:
この文書では、ランダム関数のフィールドに次の値を定義します。
o 0x01 : Function defined in this memo in Section 2.4
Oが0x01：2.4節で、このメモで定義された関数
The value 0x00 is reserved for private use between mutually consenting parties. All other values of the Random Function field are unassigned.
値は0x00が互いに同意当事者間の私的使用のために予約されています。ランダム関数フィールドの他のすべての値が割り当てられていません。
The PRF field has the following value:
PRFフィールドには、次の値があります。
o 0x01 : HMAC-SHA256 [RFC4634]
0x01のO：HMAC-SHA256 [RFC4634]
The value 0x00 is reserved for private use between mutually consenting parties. All other values of the PRF field are unassigned.
値は0x00が互いに同意当事者間の私的使用のために予約されています。 PRFフィールドの他のすべての値が割り当てられていません。
The Token field contains an unpredictable value assigned by the server in an EAP-pwd-ID/Request and acknowledged by the peer in an EAP-pwd-ID/Response (see Section 2.8.5).
トークンフィールドはEAP-PWD-ID /レスポンスでピアによってEAP-PWD-ID /リクエストにサーバによって割り当てられたと認め予測不可能な値が含まれています（セクション2.8.5を参照してください）。
The Prep field represents the password pre-processing technique (see Section 2.7.2) to be used by the client prior to generating the password seed (see Section 2.8.3). This document defines the following values for the Prep field:
準備フィールドがパスワードシードを生成する前にクライアントが使用するパスワードの前処理技術（セクション2.7.2を参照）を表す（セクション2.8.3を参照）。この文書では、準備のフィールドに次の値を定義します。
o 0x00 : None
Oは0x00：なし
o 0x01 : RFC2759
Oが0x01：RFC2759
o 0x02 : SASLprep
0x02のO：SASLprep
All other values of the Prep field are unassigned.
準備フィールドの他のすべての値が割り当てられていません。
The Identity field depends on the tuple of PWD-Exch/Code.
アイデンティティフィールドは、PWD-エクスチェンジクラブ/コードの組に依存します。
o EAP-pwd-ID/Request : Server_ID
O EAP-PWD-ID /要求：SERVER_ID
o EAP-pwd-ID/Response : Peer_ID
O EAP-PWD-ID /応答：Peer_ID
The length of the identity is computed from the Length field in the EAP header.
同一の長さは、EAPヘッダの長さフィールドから計算されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Element ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Scalar +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-pwd-Commit Payload
図7：EAP-PWD-コミットペイロード
The Element and Scalar fields depend on the tuple of PWD-Exch/Code.
要素とスカラーフィールドはPWD-エクスチェンジクラブ/コードの組に依存しています。
o EAP-pwd-Commit/Request : Element_S, Scalar_S
O EAP-PWD-コミット/要求：Element_S、Scalar_S
o EAP-pwd-Commit/Response : Element_P, Scalar_P
O EAP-PWD-コミット/応答：Element_P、Scalar_P
The Element is encoded according to Section 3.3. The length of the Element is inferred by the finite cyclic group from the agreed-upon Ciphersuite. The length of the scalar can then be computed from the Length in the EAP header.
要素は、セクション3.3に従って符号化されます。素子の長さは、合意も、Ciphersuiteから有限の巡回グループによって推定されます。スカラーの長さは、次にEAPヘッダーの長さから算出することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Confirm ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-pwd-Confirm Payload
図8：EAP-PWD-確認ペイロード
The Confirm field depends on the tuple of PWD-Exch/Code.
確認]フィールドには、PWD-エクスチェンジクラブ/コードの組に依存します。
o EAP-pwd-Confirm/Request : Confirm_S
O EAP-PWD-確認/リクエスト：Confirm_S
o EAP-pwd-Confirm/Response : Confirm_P
O EAP-PWD-確認/応答：Confirm_P
The length of the Confirm field computed from the Length in the EAP header.
EAPヘッダーの長さから計算確認フィールドの長さ。
Payloads in the EAP-pwd-Commit exchange contain elements from the agreed-upon finite cyclic cryptographic group (either an FCC group or an ECC group). To ensure interoperability, field elements and scalars MUST be represented in payloads in accordance with the requirements described below.
EAP-PWD-コミット交換におけるペイロードは合意された有限環式暗号グループ（FCC基又はECCグループのいずれか）からの要素を含みます。相互運用性を確保するために、フィールド要素とスカラーについて説明要件に従ってペイロードに表現されなければなりません。
Elements in an FFC group MUST be represented (in binary form) as unsigned integers that are strictly less than the prime, p, from the group's domain parameter set. The binary representation of each group element MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
FFCグループ内の要素は、グループのドメインパラメータセットから、P、プライムよりも厳密に小さい符号なし整数として（バイナリ形式で）表現されなければなりません。各グループの要素のバイナリ表現は、pのバイナリ表現のビット長に等しいビット長を持たなければなりません。必要であれば、この長さの要件は、必要な長さが達成されるまで、ゼロで整数のバイナリ表現を付加することによって、実施されます。
Elements in an ECC group are points on the agreed-upon elliptic curve. Each such element MUST be represented by the concatenation of two components, an x-coordinate and a y-coordinate.
ECCグループ内の要素は、合意された楕円曲線上の点です。このような各要素は、二つの成分の連結によって表されるx座標とy座標なければなりません。
Each of the two components, the x-coordinate and the y-coordinate, MUST be represented (in binary form) as an unsigned integer that is strictly less than the prime, p, from the group's domain parameter set. The binary representation of each component MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
二つの成分のそれぞれは、x座標とy座標、グループのドメインパラメータセットから、素数、pより厳密に小さい符号なし整数として（バイナリ形式で）表現されなければなりません。各成分のバイナリ表現は、pのバイナリ表現のビット長に等しいビット長を持たなければなりません。必要であれば、この長さの要件は、必要な長さが達成されるまで、ゼロで整数のバイナリ表現を付加することによって、実施されます。
Since the field element is represented in a payload by the x-coordinate followed by the y-coordinate, it follows that the length of the element in the payload MUST be twice the bit length of p. In other words, "compressed representation" is not used.
フィールド要素は、x座標、y座標、続いによってペイロードに表されているので、ペイロード内の要素の長さは、pの二倍のビット長さでなければなりませんことになります。言い換えれば、「圧縮された表現は、」使用されていません。
Scalars MUST be represented (in binary form) as unsigned integers that are strictly less than r, the order of the generator of the agreed-upon cryptographic group. The binary representation of each scalar MUST have a bit length equal to the bit length of the binary representation of r. This requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
スカラrより厳密に小さい符号なし整数、合意された暗号群の発生の順序として（バイナリ形式で）表現されなければなりません。各スカラーのバイナリ表現は、rのバイナリ表現のビット長に等しいビット長を持たなければなりません。必要であれば、この要件は、必要な長さが達成されるまで、ゼロで整数のバイナリ表現を付加することによって、実施されます。
EAP [RFC3748] is a request-response protocol. The server sends requests and the peer responds. These request and response messages are assumed to be limited to at most 1020 bytes. Messages in EAP-pwd can be larger than 1020 bytes and therefore require support for fragmentation and reassembly.
EAP [RFC3748]は、要求 - 応答プロトコルです。サーバがリクエストを送信し、ピアが応答します。これらの要求および応答メッセージは、最大で1020バイトに制限されているものとします。 EAP-PWDのメッセージは1020バイトよりも大きく、したがって、断片化と再アセンブリのサポートを必要とすることができます。
Implementations MUST establish a fragmentation threshold that indicates the maximum size of an EAP-pwd payload. When an implementation knows the maximum transmission unit (MTU) of its lower layer, it SHOULD calculate the fragmentation threshold from that value. In lieu of knowledge of the lower layer's MTU, the fragmentation threshold MUST be set to 1020 bytes.
実装は、EAP-PWDペイロードの最大サイズを示すフラグメンテーションしきい値を確立しなければなりません。インプリメンテーションは、その下層の最大伝送単位（MTU）を知っている場合、その値からフラグメンテーションしきい値を計算する必要があります。下位レイヤのMTUの知識の代わりに、フラグメンテーションしきい値は1020バイトに設定しなければなりません。
Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field as is provided in IPv4.
EAPは、単純なACK-NAKプロトコルであるため、フラグメンテーションサポートを簡単に追加することができます。 EAPには、輸送中に紛失または破損しているフラグメントが再送され、情報がEAP内の識別子フィールドによって提供される配列決定するため、IPv4の提供されたようにフラグメントオフセットフィールドは不要です。
EAP-pwd fragmentation support is provided through the addition of flags within the EAP-Response and EAP-Request packets, as well as a Total-Length field of two octets. Flags include the Length included (L) and More fragments (M) bits. The L flag is set to indicate the presence of the two-octet Total-Length field, and MUST be set for the first fragment of a fragmented EAP-pwd message or set of messages. The M flag is set on all but the last fragment. The Total-Length field is two octets, and provides the total length of the EAP-pwd message or set of messages that is being fragmented; this simplifies buffer allocation.
EAP-PWD断片化のサポートはEAP応答およびEAP-Requestパケット、ならびに2つのオクテットの合計長フィールド内のフラグの付加を介して提供されます。フラグが含まれる長さ（L）およびそれ以上のフラグメント（M）ビットを含みます。 Lフラグは2オクテットの総数-Lengthフィールドの存在を示すために設定され、断片化されたEAP-PWDメッセージの最初のフラグメントに対して設定またはメッセージの設定しなければなりません。 Mフラグが最後のフラグメント以外のすべてに設定されています。全長さフィールドは2つのオクテットであり、EAP-PWDメッセージまたは断片化されるメッセージのセットの全体の長さを提供します。これは、バッファ割り当てを簡素化します。
When an EAP-pwd peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-pwd and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
EAP-PWDピアがMビットが設定されたEAP-Requestパケットを受信すると、EAPタイプ= PWD EAP-とデータのないEAP-応答で応答しなければなりません。これは、断片ACKとして機能します。それは別のフラグメントを送る前に、EAP-応答を受信するまで、EAPサーバは待たなければなりません。フラグメントの処理のエラーを防止するために、EAPサーバはEAP-要求内に含まれる各フラグメントの識別子フィールドをインクリメントしなければならない、とピアはEAPレスポンス内に含まれる断片のACKにおけるこの識別子の値を含まなければなりません。再送されたフラグメントは、同じ識別子の値が含まれます。
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-pwd and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
EAPサーバはMビットセットでEAP-応答を受信すると同様に、それはEAPタイプ= EAP-PWDとデータのないEAP-要求に応じなければなりません。これは、断片ACKとして機能します。それは別のフラグメントを送る前に、EAP-Requestを受信するまで、EAPピアは待たなければなりません。フラグメントの処理のエラーを防止するために、EAPサーバはEAP-要求内に含まれる各断片ACKのための識別子の値をインクリメントしなければならない、とピアはEAPレスポンス内に含まれる後続の断片におけるこの識別子の値を含まなければなりません。
This memo contains new numberspaces to be managed by IANA. The policies used to allocate numbers are described in [RFC5226]. IANA has allocated a new EAP method type for EAP-pwd (52).
このメモはIANAによって管理される新しいnumberspacesが含まれています。番号を割り当てるために使用されるポリシーは、[RFC5226]に記載されています。 IANAはEAP-PWD（52）のための新たなEAPメソッドタイプを割り当てました。
IANA has created new registries for PWD-Exch messages, random functions, PRFs, and password pre-processing methods and has added the message numbers, random function, PRF, and pre-processing methods specified in this memo to those registries, respectively.
IANAは、PWD-エクスチェンジクラブのメッセージ、ランダム関数、PRFを、パスワードの前処理方法のための新しいレジストリを作成しているとメッセージ番号、ランダム関数、PRF、それぞれ、それらのレジストリにこのメモで指定された前処理メソッドを追加しました。
The following is the initial PWD-Exch message registry layout:
以下は、最初のPWD-エクスチェンジクラブのメッセージレジストリレイアウトです：
o 0x00 : Reserved
0x00のO：予約
o 0x01 : EAP-pwd-ID exchange
Oが0x01：EAP-PWD-ID交換
o 0x02 : EAP-pwd-Commit exchange
O 0×02：EAP-PWD-コミット交流
o 0x03 : EAP-pwd-Confirm exchange
0x03のO：EAP-PWD-確認交換
The PWD-Exch field is 6 bits long. The value 0x00 is reserved. All other values are available through assignment by IANA. IANA is instructed to assign values based on "IETF Review" (see [RFC5226]).
PWD-エクスチェンジクラブフィールドは6ビット長です。値0x00が予約されています。他のすべての値は、IANAによって割り当てて利用できます。 IANAは、「IETFレビュー」（[RFC5226]を参照）に基づいて値を代入するように指示されます。
The following is the initial Random Function registry layout:
以下は、最初のランダム関数のレジストリレイアウトです：
o 0x00 : Private Use
O $ 00：私用
o 0x01 : Function defined in this memo, Section 2.4
Oが0x01：このメモで定義された機能、2.4節
The Random Function field is 8 bits long. The value 0x00 is for Private Use between mutually consenting parties. All other values are available through assignment by IANA. IANA is instructed to assign values based on "Specification Required" (see [RFC5226]). The Designated Expert performing the necessary review MUST ensure the random function has been cryptographically vetted.
ランダム関数フィールドは8ビット長です。値0x00が互いに同意当事者間の私的使用のためです。他のすべての値は、IANAによって割り当てて利用できます。 IANAは「仕様が必要である」（[RFC5226]を参照）に基づいて値を代入するように指示されます。ランダムな機能を確保しなければならない必要な見直しを行って指定Expertは、暗号吟味されています。
The following is the initial PRF registry layout:
以下は、最初のPRFのレジストリレイアウトです：
o 0x00 : Private Use
O $ 00：私用
o 0x01 : HMAC-SHA256 as defined in [RFC4634]
0x01のO：HMAC-SHA256 [RFC4634]で定義されるように
The PRF field is 8 bits long. The value 0x00 is for Private Use between mutually consenting parties. All other values are available through assignment by IANA. IANA is instructed to assign values based on "IETF Review" (see [RFC5226]).
PRFフィールドは8ビット長です。値0x00が互いに同意当事者間の私的使用のためです。他のすべての値は、IANAによって割り当てて利用できます。 IANAは、「IETFレビュー」（[RFC5226]を参照）に基づいて値を代入するように指示されます。
The following is the initial layout for the password pre-processing method registry:
以下では、パスワードの前処理方法レジストリの初期レイアウトです。
o 0x00 : None
Oは0x00：なし
o 0x01 : RFC2759
Oが0x01：RFC2759
o 0x02 : SASLprep
0x02のO：SASLprep
The Prep field is 8 bits long, and all other values are available through assignment by IANA. IANA is instructed to assign values based on "Specification Required" (see [RFC5226]).
準備フィールドは8ビット長であり、そして他のすべての値は、IANAによって割り当てを通じて入手可能です。 IANAは「仕様が必要である」（[RFC5226]を参照）に基づいて値を代入するように指示されます。
In Section 1.3, several security properties were presented that motivated the design of this protocol. This section will address how well they are met.
セクション1.3では、いくつかのセキュリティプロパティは、このプロトコルの設計の動機ことを発表されました。このセクションでは、それらが満たされているかうまく対処します。
A passive attacker will see Scalar_P, Element_P, Scalar_S, and Element_S. She can guess at passwords to compute the password element but will not know s_rand or p_rand and therefore will not be able to compute MK.
受動的攻撃者がScalar_P、Element_P、Scalar_S、およびElement_Sが表示されます。彼女は、パスワード要素を計算するために、パスワードを推測することができますが、s_randまたはp_randを知ることができませんので、MKを計算することができません。
The secret random value of the peer (server) is effectively hidden by adding p_mask (s_mask) to p_rand (s_rand) modulo the order of the group. If the order is "r", then there are approximately "r" distinct pairs of numbers that will sum to the value Scalar_P (Scalar_S). Attempting to guess the particular pair is just as difficult as guessing the secret random value p_rand (s_rand), the probability of a guess is 1/(r - i) after "i" guesses. For a large value of r, this exhaustive search technique is computationally infeasible. An attacker would do better by determining the discrete logarithm of Element_P (Element_S) using an algorithm like the baby-step giant-step algorithm (see [APPCRY]), which runs on the order of the square root of r group operations (e.g., a group with order 2^160 would require 2^80 exponentiations or point multiplications). Based on the assumptions made on the finite cyclic group in Section 2.3, that is also computationally infeasible.
ピア（サーバ）の秘密の乱数値を効果的にグループの順序を法（s_rand）をp_randするp_mask（S_MASK）を添加することによって隠されています。順序が「R」であれば、約「R」値Scalar_P（Scalar_S）を合計する数の異なる対が存在します。 「i」を推測した後に - 特に対を推測しようとする秘密のランダム値p_rand（s_rand）を推測と同じくらい困難であり、推測の確率は、1 /（I R）です。 Rの値が大きいため、この網羅的探索技術は、計算上実行不可能です。攻撃者は、例えば、（R基操作の平方根の順に実行される、（[APPCRY]参照）ベビーステップジャイアントステップのアルゴリズムのようなアルゴリズムを用いてElement_P（Element_S）の離散対数を決定することによって、より良いだろう順序2 ^ 160のグループは、2 ^ 80累乗または点乗算）を必要とするであろう。 2.3節で有限巡回群上の仮定に基づいて、それはまた、計算上不可能です。
An active attacker can launch her attack after an honest server has sent EAP-pwd-Commit/Request to an honest peer. This would result in the peer sending EAP-pwd-Commit/Response. In this case, the active attack has been reduced to that of a passive attacker since p_rand and s_rand will remain unknown. The active attacker could forge a value of Confirm_P (Confirm_S) and send it to the EAP server (EAP peer) in the hope that it will be accepted, but due to the assumptions on H made in Section 2.3, that is computationally infeasible.
正直なサーバーは、正直なピアにEAP-PWD-コミット/リクエストを送信した後にアクティブ攻撃者は、彼女の攻撃を仕掛けることができます。これは、EAP-PWD-コミット/レスポンスを送信するピアにつながります。この場合は、アクティブな攻撃はp_rand以来、受動的攻撃者のものに縮小されていて、s_rand不明のままになります。アクティブな攻撃者は、Confirm_P（Confirm_S）の値を偽造し、それが受け入れられることを期待してEAPサーバ（EAPピア）に送信しますが、原因のセクション2.3で行われたH上の仮定に、それは計算上実行不可能である可能性があります。
The active attacker can launch her attack by forging EAP-pwd-Commit/ Request and sending it to the peer. This will result in the peer responding with EAP-pwd-Commit/Response. The attacker can then attempt to compute ks, but since she doesn't know the password, this is infeasible. It can be shown that an attack by forging an EAP-pwd-Commit/Response is an identical attack with equal infeasibility.
アクティブな攻撃者は、EAP-PWD-コミット/要求し、ピアに送信を鍛造により、彼女の攻撃を開始することができます。これは、EAP-PWD-コミット/レスポンスで応答するピアになります。攻撃者は、その後、KSを計算するために試みることができますが、彼女は、パスワードを知らないため、これは実現不可能です。 EAP-PWD-コミット/応答を鍛造による攻撃が等しく実行不可能と同じ攻撃であることを示すことができます。
An active attacker can wait until an honest server sends EAP-pwd-Commit/Request and then forge EAP-pwd-Commit/Response and send it to the server. The server will respond with EAP-pwd-Confirm/Request. Now the attacker can attempt to launch a dictionary attack. She can guess at potential passwords, compute the password element, and compute kp using her p_rand, Scalar_S, and Element_S from the EAP-pwd-Commit/Request and the candidate password element from her guess. She will know if her guess is correct when she is able to verify Confirm_S in EAP-pwd-Confirm/Request.
アクティブな攻撃者は、正直なサーバがEAP-PWD-コミット/リクエストを送信するまで待ってから/レスポンスEAP-PWDコミットを偽造し、それをサーバに送信することができます。サーバーは、EAP-PWD-確認/リクエストに応答します。今、攻撃者は、辞書攻撃を開始しようとすることができます。彼女は、潜在的なパスワードを推測パスワード要素を計算し、EAP-PWD-コミット/要求と彼女の推測からの候補パスワード要素から彼女p_rand、Scalar_S、およびElement_Sを使用してKPを計算することができます。彼女はEAP-PWD-確認/リクエストでConfirm_Sを確認することができるとき、彼女の推測が正しければ、彼女は知っています。
But the attacker committed to a password guess with her forged EAP-pwd-Commit/Response when she computed Element_P. That value was used by the server in his computation of ks that was used when he constructed Confirm_S in EAP-pwd-Confirm/Request. Any guess of the password that differs from the one used in the forged EAP-pwd-Commit/ Response could not be verified as correct since the attacker has no way of knowing whether it is correct. She is able to make one guess and one guess only per attack. This means that any advantage she can gain -- guess a password, if it fails exclude it from the pool of possible passwords and try again -- is solely through interaction with an honest protocol peer.
彼女はElement_Pを計算する場合でも、パスワードにコミット攻撃者が彼女の偽造EAP-PWD-コミット/レスポンスと思います。この値は、彼がEAP-PWD-確認/リクエストにConfirm_Sを構築する際に使用したKSの彼の計算にサーバによって使用されました。攻撃者は、それが正しいかどうかを知る方法はありませんので、鍛造EAP-PWD-コミット/レスポンスで使用されるものとは異なり、パスワードのいずれかの推測が正しいと確認することができませんでした。彼女は1つの推測だけ攻撃ごとに推測をすることができます。単に正直なプロトコルのピアとの相互作用を介している - それは可能なパスワードのプールから除外し、もう一度試して失敗した場合は、パスワードを推測 - これは彼女が得ることができます任意の利点があることを意味します。
The attacker can commit to the guess with the forged EAP-pwd-Commit/ Response and then run through the dictionary, computing the password element and ks using her forged Scalar_P and Element_P. She will know she is correct if she can compute the same value for Confirm_S that the server produced in EAP-pwd-Confirm/Request. But this requires the attacker to know s_rand, which we noted above was not possible.
攻撃者は、偽造EAP-PWD-コミット/レスポンスと推測することを約束して、辞書を介して実行、彼女の偽造Scalar_PとElement_Pを使用してパスワード要素とKSを計算することができます。彼女は、サーバがEAP-PWD-確認/リクエストで生産Confirm_Sに同じ値を計算することができれば、彼女は彼女が正しいことを知っているだろう。しかし、これは、我々は上記のことは不可能だった、s_rand知っている攻撃者が必要です。
The password element PWE/pwe is chosen using a method described in Section 2.8.3. Since this is an element in the group, there exists a scalar value, q, such that:
パスワード要素PWE / PWEは、セクション2.8.3に記載した方法を用いて選択されます。これはグループの要素であるため、スカラー値、Q、その結果が存在します。
PWE = q * G, for an ECC group
ECCグループのPWE = Q * G、
pwe = g^q mod p, for an FFC group
FFCグループのPWE = G ^ Q MOD P、
Knowledge of q can be used to launch a dictionary attack. For the sake of brevity, the attack will be demonstrated assuming an ECC group. The attack works thusly:
Qの知識は辞書攻撃を起動するために使用することができます。簡潔にするために、攻撃は、ECCグループを仮定実証されます。攻撃はthusly動作します：
The attacker waits until an honest server sends an EAP-pwd-Commit/ Request. The attacker then generates a random Scalar_P and a random p_mask and computes Element_P = p_mask * G. The attacker sends the bogus Scalar_P and Element_P to the server and obtains Confirm_S in return. Note that the server is unable to detect that Element_P was calculated incorrectly.
正直なサーバーは、EAP-PWD-コミット/リクエストを送信するまで、攻撃者が待機します。その後、攻撃者はランダムScalar_Pとランダムp_maskを生成し、Element_P = p_mask * G.、攻撃者がサーバーに偽のScalar_PとElement_Pを送信し、見返りにConfirm_Sを取得し計算します。サーバはElement_Pが誤って計算されたことを検出することができないことに注意してください。
The attacker now knows that:
攻撃者は、今では知っています：
KS = (Scalar_P * q + p_mask) * s_rand * G
KS =（Scalar_P * Q + p_mask）* s_rand * G
and
そして
s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P)
s_rand * G = Scalar_P * G - （（1 / Q）MOD R * -Element_P）
Since Scalar_P, p_mask, G, and Element_P are all known, the attacker can run through the dictionary, make a password guess, compute PWE using the technique in Section 2.8.3, determine q, and then use the equations above to compute KS and see if it can verify Confirm_S. But to determine q for a candidate PWE, the attacker needs to perform a discrete logarithm that was assumed to be computationally infeasible in Section 2.3. Therefore, this attack is also infeasible.
Scalar_P、p_mask、G、及びElement_Pが全て知られているので、攻撃者は、辞書を介して実行パスワード推測を行い、セクション2.8.3に技術を使用して、PWEを計算し、Qを決定し、その後、KSを計算するために、上記の方程式を使用することができるとそれはConfirm_Sを確認することができます参照してください。しかし、候補PWEのためのQを決定するために、攻撃者は、セクション2.3で計算上実行不可能であると仮定された離散対数を実行する必要があります。したがって、この攻撃も実行不可能です。
The best advantage an attacker can gain in a single active attack is to determine whether a single guess at the password was correct. Therefore, her advantage is solely through interaction and not computation, which is the definition for resistance to dictionary attack.
攻撃者は、単一のアクティブな攻撃で得ることができる最高の利点は、パスワードで、単一の推測が正しかったかどうかを決定することです。そのため、彼女の長所は、辞書攻撃への抵抗のために定義されている、単に相互作用ではなく、計算することです。
Resistance to dictionary attack means that the attacker must launch an active attack to make a single guess at the password. If the size of the dictionary from which the password was extracted was D, and each password in the dictionary has an equal probability of being chosen, then the probability of success after a single guess is 1/D. After X guesses, and removal of failed guesses from the pool of possible passwords, the probability becomes 1/(D-X). As X grows, so does the probability of success. Therefore, it is possible for an attacker to determine the password through repeated brute-force, active, guessing attacks. This protocol does not presume to be secure against this, and implementations SHOULD ensure the size of D is sufficiently large to prevent this attack. Implementations SHOULD also take countermeasures -- for instance, refusing authentication attempts for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo.
辞書攻撃に対する抵抗性は、攻撃者がパスワードで単一の推測をするためにアクティブな攻撃を開始しなければならないことを意味します。パスワードが抽出された辞書のサイズがDであり、辞書内の各パスワードが選択される等しい確率を有する場合、単一の推測後の成功の確率は1 / Dです。 Xの推測、および可能なパスワードのプールから失敗した推測を除去した後、確率は1 /（D-X）となります。 Xが大きくなるにつれて、その成功の確率はありません。攻撃者は繰り返し力ずく、アクティブ、推測攻撃でパスワードを決定するためにしたがって、それは可能です。このプロトコルは、このに対して安全であることを前提とせず、実装は、Dの大きさは、この攻撃を防ぐために十分な大きさを確認する必要があります。失敗した認証試行の数が一定のしきい値に達した後、一定時間の認証の試行を拒否し、例えば、 - 実装はまた、対策を取るべきです。時間のそのようなしきい値または量は、このメモで推奨されていません。
The MSK and EMSK are extracted from MK, which is derived from doing group operations with s_rand, p_rand, and the password element. The peer and server choose random values with each run of the protocol. So even if an attacker is able to learn the password, she will not know the random values used by either the peer or server from an earlier run and will therefore be unable to determine MK, or the MSK or EMSK. This is the definition of Forward Secrecy.
MSKとEMSKはs_rand、p_rand、およびパスワード要素でグループ操作を行うことに由来しているMKから抽出されています。ピアおよびサーバは、プロトコルの各実行でランダムな値を選択してください。だから、攻撃者がパスワードを知ることができる場合でも、彼女は以前の実行からピアまたはサーバのいずれかで使用されるランダムな値を知ることができませんので、MK、またはMSKかEMSKを決定することができません。これは、転送秘密の定義です。
The strength of the shared secret, MK, derived in Section 2.8.4 depends on the effort needed to solve the discrete logarithm problem in the chosen group. [RFC3766] has a good discussion on the strength estimates of symmetric keys derived from discrete logarithm cryptography.
セクション2.8.4で導出共有秘密の強さ、MKは、選択したグループ内の離散対数問題を解決するために必要な努力に依存しています。 [RFC3766]は離散対数暗号由来する対称鍵の強度推定値で良い議論を有します。
The mandatory-to-implement group defined in this memo is group 19, a group from [RFC5114] based on Elliptic Curve Cryptography (see Section 2.2.2) with a prime bit length of 256. This group was chosen because the current best estimate of a symmetric key derived using this group is 128 bits, which is the typical length of a key for the Advanced Encryption Standard ([FIPS-197]). While it is possible to obtain a equivalent measure of strength using a group based on Finite Field Cryptography (see Section 2.2.1), it would require a much larger prime and be more memory and compute intensive.
このメモで定義されて強制的に実装グループは、グループ19は、256の素数ビット長の楕円曲線暗号に基づいて[RFC5114]からグループ（セクション2.2.2参照）このグループは現在の最良の推定ために選択しましたこのグループを使用して導出対称鍵の高度暗号化標準（[FIPS-197]）のためのキーの典型的な長さは128ビットです。 （セクション2.2.1を参照）有限フィールドの暗号化に基づいてグループを使用して強度の同等の測定値を得ることが可能であるが、それははるかに大きな素数を必要とし、より多くのメモリであると集約計算になります。
The protocol described in this memo uses a function referred to as a "random oracle" (as defined in [RANDOR]). A significant amount of care must be taken to instantiate a random oracle out of handy cryptographic primitives. The random oracle used here is based on the notion of a "Randomness Extractor" from [RFC5869].
このメモで説明されたプロトコルは、（[RANDOR]で定義されるように）「ランダムオラクル」と呼ばれる機能を使用します。ケアの重要な量は便利な暗号プリミティブのうち、ランダムオラクルのインスタンスを作成するために取られなければなりません。ここで使用されるランダムオラクルは、[RFC5869]から「ランダム性抽出」の概念に基づいています。
This protocol can use any properly instantiated random oracle. To ensure that any new value for H will use a properly instantiated random oracle, IANA has been instructed (in Section 5) to only allocate values from the Random Function registry after being vetted by an expert.
このプロトコルは、任意の適切インスタンス化ランダムオラクルを使用することができます。 Hのための新たな値が適切にインスタンス化ランダムオラクルを使用することを確実にするために、IANAは、専門家によって吟味された後にのみランダム関数レジストリから値を割り当てるには（第5節で）指示されました。
A few of the defined groups that can be used with this protocol have a security estimate (see Section 6.5) less than 128 bits, many do not though, and to prevent the random function from being the gating factor (or a target for attack), any new random function MUST map its input to a target of at least 128 bits and SHOULD map its input to a target of at least 256 bits.
セキュリティ推定値を有し、このプロトコルで使用することができる定義されたグループの数は多くはいえない未満128ビット（セクション6.5を参照）、およびゲーティング因子（または攻撃の標的）であることからランダム関数を防ぐために、新たなランダム関数は、少なくとも128ビットのターゲットへの入力をマップする必要がありそして少なくとも256ビットのターゲットへの入力をマップする必要があります。
[RFC3748] requires that documents describing new EAP methods clearly articulate the security properties of the method. In addition, for use with wireless LANs, [RFC4017] mandates and recommends several of these. The claims are:
[RFC3748]は、新たなEAPメソッドを記述した文書が明確にメソッドのセキュリティ特性を明確にする必要があります。また、無線LAN、[RFC4017]義務とで使用するためにこれらのいくつかをお勧めします。主張は以下のとおりです。
a. mechanism: password.
A。メカニズム：パスワード。
b. claims:
B。請求：
* mutual authentication: the peer and server both authenticate
each other by proving possession of a shared password. This
is REQUIRED by [RFC4017].
* forward secrecy: compromise of the password does not reveal the secret keys -- MK, MSK, or EMSK -- from earlier runs of the protocol.
*転送秘密：パスワードの妥協が秘密鍵明らかにしない - MK、MSK、またはEMSK - プロトコルの以前の実行からを。
* replay protection: an attacker is unable to replay messages from a previous exchange to either learn the password or a key derived by the exchange. Similarly the attacker is unable to induce either the peer or server to believe the exchange has successfully completed when it hasn't. Reflection attacks are foiled because the server ensures that the scalar and element supplied by the peer do not equal its own.
*リプレイ保護：攻撃者がパスワードまたは交換によって派生鍵を学ぶためにどちらかの以前の交換機からメッセージを再生することができません。同様に、攻撃者はそれがなかった場合に交換が正常に完了したと信じてピアまたはサーバのいずれかを誘導することができません。サーバは、ピアによって提供されるスカラーや要素は、独自に等しくないことが保証されているため、反射攻撃をくじかれています。
* key derivation: keys are derived by performing a group operation in a finite cyclic group (e.g., exponentiation) using secret data contributed by both the peer and server. An MSK and EMSK are derived from that shared secret. This is REQUIRED by [RFC4017]
*キー導出：キーは、ピアとサーバの両方が寄与する秘密データを使用して、有限巡回群（例えば、べき乗）でグループ演算を実行することによって導出されます。 MSKとEMSKは、その共有シークレットから派生しています。これは、[RFC4017]によって必要とされます
* dictionary attack resistance: this protocol is resistant to dictionary attack because an attacker can only make one password guess per active attack. The advantage gained by an attacker is through interaction not through computation. This is REQUIRED by [RFC4017].
*辞書攻撃耐性：攻撃者が唯一のアクティブな攻撃ごとに1つのパスワードの推測を行うことができますので、このプロトコルは、辞書攻撃に耐性があります。攻撃者によって得られる利点は、相互作用を介していない計算を介して行われます。これは、[RFC4017]によって必要とされます。
* session independence: this protocol is resistant to active and passive attack and does not enable compromise of subsequent or prior MSKs or EMSKs from either passive or active attack.
*セッションの独立性：このプロトコルは、アクティブとパッシブの攻撃に耐性があり、どちらか受動的または能動的な攻撃からの後続または事前たMSKまたはEMSKsの妥協を有効にしません。
* Denial-of-Service Resistance: it is possible for an attacker to cause a server to allocate state and consume CPU cycles generating Scalar_S and Element_S. Such an attack is gated, though, by the requirement that the attacker first obtain connectivity through a lower-layer protocol (e.g. 802.11 authentication followed by 802.11 association, or 802.3 "link-up") and respond to two EAP messages --the EAP-ID/ Request and the EAP-pwd-ID/Request. The EAP-pwd-ID exchange further includes an anti-clogging token that provides a level of assurance to the server that the peer is, at least, performing a rudimentary amount of processing and not merely spraying packets. This prevents distributed denial-of-service attacks and also requires the attacker to announce, and commit to, a lower-layer identity, such as a MAC (Media Access Control) address.
*サービス拒否抵抗：攻撃者が状態を割り当てるためのサーバーを引き起こし、Scalar_SとElement_Sを生成するCPUサイクルを消費することが可能です。そのような攻撃は、攻撃者はまず下位層プロトコル（802.11アソシエーション続い例えば802.11認証、又は802.3「リンクアップ」）を介して接続を得る二つのEAPメッセージに応答要件--the EAPによって、しかし、ゲートされ-ID /リクエストとEAP-PWD-ID /要求。さらにEAP-PWD-IDの交換は、ピアが、少なくとも、処理の基本的な量を行い、単にパケットを噴霧しない、あるサーバへの保証のレベルを提供する目詰まり防止トークンを含みます。これは、サービス拒否攻撃を分散し、また、MAC（Media Access Control）アドレスとして、下層のアイデンティティを発表し、にコミットし、攻撃者を必要としないように。
* Man-in-the-Middle Attack Resistance: this exchange is resistant to active attack, which is a requirement for launching a man-in-the-middle attack. This is REQUIRED by [RFC4017].
* man-in-the-middle攻撃性：この交換は、man-in-the-middle攻撃を起動するための必要条件であるアクティブな攻撃に耐性です。これは、[RFC4017]によって必要とされます。
* shared state equivalence: upon completion of EAP-pwd, the peer and server both agree on MK, MSK, EMSK, Method-ID, and Session-ID. The peer has authenticated the server based on the Server-ID, and the server has authenticated the peer based on the Peer-ID. This is due to the fact that Peer-ID, Server-ID, and the shared password are all combined to make the password element, which must be shared between the peer and server for the exchange to complete. This is REQUIRED by [RFC4017].
*共有状態の等価性：EAP-PWDが完了すると、ピアとサーバの両方が、MK、MSK、EMSK、方法-ID、およびセッションIDについては同意します。ピアはサーバー-IDに基づいてサーバを認証した、およびサーバがピアIDに基づいてピアを認証しています。これは、ピアID、サーバーID、および共有パスワードがすべて完了するの交換のために、ピアとサーバの間で共有されなければならないパスワード要素を、作るために結合されているという事実によるものです。これは、[RFC4017]によって必要とされます。
* fragmentation: this protocol defines a technique for fragmentation and reassembly in Section 4.
*フラグメンテーション：このプロトコルは、セクション4におけるフラグメンテーション及び再組み立てのための技術を規定します。
* resistance to "Denning-Sacco" attack: learning keys distributed from an earlier run of the protocol, such as the MSK or EMSK, will not help an adversary learn the password.
*「デニング・サッコ」攻撃への耐性：そのようMSKかEMSKなどのプロトコルの以前の実行から配布学習のキーは、敵がパスワードを学ぶ助けにはなりません。
c. key strength: the strength of the resulting key depends on the finite cyclic group chosen. See Section 6.5. This is REQUIRED by [RFC4017].
C。キー強度：得られたキーの強度は、選択された有限巡回群に依存します。 6.5節を参照してください。これは、[RFC4017]によって必要とされます。
d. key hierarchy: MSKs and EMSKs are derived from the MK using the KDF defined in Section 2.5 as described in Section 2.8.4.
D。キー階層：たMSKとEMSKsはセクション2.8.4で説明したように、セクション2.5で定義されたKDFを用いてMKから誘導されます。
e. vulnerabilities (note that none of these are REQUIRED by [RFC4017]):
電子。脆弱性（これらのいずれも[RFC4017]によって必要とされていないことに注意してください）：
* protected ciphersuite negotiation: the ciphersuite offer made
by the server is not protected from tampering by an active
attacker. Downgrade attacks are prevented, though, since this is not a "negotiation" with a list of acceptable
ciphersuites. If a Ciphersuite was modified by an active
attacker it would result in a failure to confirm the message
sent by the other party, since the Ciphersuite is bound by
each side into its confirm message, and the protocol would
fail as a result.
* confidentiality: none of the messages sent in this protocol are encrypted.
*機密性：このプロトコルで送信されたメッセージのどれもが暗号化されていません。
* integrity protection: messages in the EAP-pwd-Commit exchange are not integrity protected.
*完全性保護：内のメッセージの完全性保護されていない交換をEAP-PWDは、コミット。
* channel binding: this protocol does not enable the exchange of integrity-protected channel information that can be compared with values communicated via out-of-band mechanisms.
*チャネルバインディング：このプロトコルは、帯域外の機構を介して伝達さ値と比較することができる完全性保護チャネル情報の交換を可能にしません。
* fast reconnect: this protocol does not provide a fast-reconnect capability.
*高速再接続：このプロトコルは、高速再接続機能を提供していません。
* cryptographic binding: this protocol is not a tunneled EAP method and therefore has no cryptographic information to bind.
*暗号化バインド：このプロトコルは、トンネルEAP方式ではないため、拘束する一切の暗号化情報を持っていません。
* identity protection: the EAP-pwd-ID exchange is not protected. An attacker will see the server's identity in the EAP-pwd-ID/Request and see the peer's identity in EAP-pwd-ID/ Response.
* ID保護：EAP-PWD-IDの交換が保護されていません。攻撃者は、EAP-PWD-ID /リクエストにサーバの身元を確認し、EAP-PWD-ID /レスポンスでピアのアイデンティティが表示されます。
The authors would like to thank Scott Fluhrer for discovering the "password as exponent" attack that was possible in the initial version of this memo and for his very helpful suggestions on the techniques for fixing the PWE/pwe to prevent it. The authors would also like to thank Hideyuki Suzuki for his insight in discovering an attack against a previous version of the underlying key exchange protocol. Special thanks to Lily Chen for helpful discussions on hashing into an elliptic curve and to Jin-Meng Ho for suggesting the countermeasures to protect against a small sub-group attack. Rich Davis suggested the defensive checks to Commit messages, and his various comments greatly improved the quality of this memo and the underlying key exchange on which it is based. Scott Kelly suggested adding the anti-clogging token to the ID exchange to prevent distributed denial-of-service attacks. Dorothy Stanley provided valuable suggestions to improve the quality of this memo. The fragmentation method used was taken from [RFC5216].
著者は、このメモの最初のバージョンで、それを防ぐために、PWE / PWEを固定する技術上の彼の非常に役立つ提案のために可能だった「パスワード指数として」攻撃を発見するためのスコットFluhrerに感謝したいと思います。著者らはまた、基本となる鍵交換プロトコルの以前のバージョンへの攻撃を発見して、彼の洞察力のために英之鈴木に感謝したいと思います。楕円曲線へのハッシングに有益な議論のために、小さなサブグループの攻撃から守るための対策を提案してジン孟ホーへリリー・チェンに感謝します。リッチ・デイビスは、メッセージをコミットするために守備のチェックを提案し、彼の様々なコメントが大幅にこのメモの品質と、それが基づいている基本となる鍵交換を改善しました。スコット・ケリーは、分散サービス拒否攻撃を防ぐためにID交換に目詰まり防止トークンを追加することを提案しました。ドロシー・スタンレーは、このメモの品質を改善するための貴重な提案を提供しました。使用される断片化法は[RFC5216]から採取しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]ソーン、G.、 "マイクロソフトPPP CHAP拡張、Version 2"、RFC 2759、2000年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]イーストレイク、D.とT.ハンセンは、RFC 4634、2006年7月、 "米国は、ハッシュアルゴリズム（SHAとHMAC-SHA）を固定します"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[SP800-108] Chen, L., "Recommendations for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, April 2008.
[SP800-108]チェン、L.、 "鍵導出のための推奨事項は、擬似ランダム関数の使用"、は、NIST Special Publication 800から108、2008年4月。
[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendations for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, March 2007.
[SP800-56A]バーカー、E.、ジョンソン、D.、およびM. SMID、は、NIST Special Publication 800-56A、2007年3月 "離散対数暗号を使用してペアワイズ鍵確立スキームのための勧告"。
[APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press Series on Discrete Mathematics and Its Applications, 1996.
離散数学とその応用、1996年[APPCRY]メネゼス、A.、バンOorshot、P.、およびS. Vanstone著、 "応用暗号のハンドブック"、CRCプレスシリーズ。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attack", Proceedings of the IEEE Symposium on Security and Privacy, Oakland, 1992.
[BM92] Bellovin氏、S.とM.メリット、「暗号化鍵交換：辞書攻撃に対するセキュリティで保護されたパスワードベースのプロトコル」、セキュリティとプライバシー、オークランド、1992年IEEEシンポジウム。
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
[BM93] Bellovin氏、S.とM.メリット、「増補暗号化鍵交換：辞書攻撃やパスワード・ファイルの侵害に対するセキュリティで保護されたパスワードベースのプロトコル」、コンピュータおよび通信セキュリティ、ACMプレス、1993年第1回ACM会議の議事録。
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman", Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 2000.
[BMP00] Boyko、V.、マッケンジー、P.、およびS.パテル、 "証明可能ディフィー・ヘルマンを使用してセキュリティで保護されたパスワード認証鍵交換"、LNCS 1807シュプリンガー・フェアラーク、2000 EUROCRYPT 2000の議事。
[FIPS-197] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), November 2001.
[FIPS-197]アメリカ国立標準技術研究所、FIPSパブ197：高度暗号化標準（AES）、2001年11月。
[JAB96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communication Review Volume 1, Issue 5, October 1996.
[JAB96] Jablon、D.、 "強力なパスワードのみによる認証鍵交換"、ACM SIGCOMMコンピュータコミュニケーションレビュー第1巻、5号、1996年10月。
[LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys", Proceedings of the Security Protocols Workshop, LNCS 1361, Springer-Verlag, 1997.
[LUC97] Lucks、S.、「開く鍵交換：どのように公開鍵を暗号化せずに辞書攻撃を倒すために、」セキュリティプロトコルワークショップ、LNCS 1361、シュプリンガー・フェアラーク、1997年の議事録、。
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
[RANDOR]ベラー、M.とP. Rogawayは、「ランダムオラクルは、実用的である：効率的なプロトコルを設計するためのパラダイム」、コンピュータおよび通信セキュリティ、ACMプレス、1993年第1回ACM会議の議事録。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley氏、R。およびB. Aboba、 "認証、許可、アカウンティング（AAA）キー管理のための指針"、BCP 132、RFC 4962、2007年7月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114] Lepinski、M.とS.ケント、 "IETF標準を使用するための追加のDiffie-Hellmanのグループ"、RFC 5114、2008年1月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]サイモン、D.、Aboba、B.、およびR.ハースト、 "EAP-TLS認証プロトコル"、RFC 5216、2008年3月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、サイモン、D.、およびP. Eronen、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、RFC 5247、2008年8月。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5869] Krawczyk、H.、およびP. Eronen、 "HMACベースの抽出物と、拡大鍵導出関数（HKDF）"、RFC 5869、2010年5月を。
Authors' Addresses
著者のアドレス
Dan Harkins Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 USA
ダンハーキンズアルバネットワークス1322クロスマンアベニューサニーベール、CA 94089から1113 USA
EMail: dharkins@arubanetworks.com
メールアドレス：dharkins@arubanetworks.com
Glen Zorn Network Zen 1310 East Thomas Street #306 Seattle, WA 98102 USA
グレンツォルンネットワーク禅1310東トーマス・ストリート＃306シアトル、WA 98102 USA
Phone: +1 (206) 377-9035 EMail: gwz@net-zen.net
電話：+1（206）377-9035 Eメール：gwz@net-zen.net