[要約] RFC 5931は、パスワードのみを使用して行われる拡張認証プロトコル（EAP）認証に関する規格です。このRFCの目的は、パスワードのみを使用してセキュアな認証を提供するための標準化とガイドラインの提供です。
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
パスワードのみを使用して、拡張可能な認証プロトコル（EAP）認証
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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とMerrittによって最初に記述されました。パスワードベースの認証されたキー交換について、その後の提案（[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].
Peer-idピアのアイデンティティ、ピアナイ[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は関数hに与えられ、固定長の出力yを生成します。
a | b The concatenation of string a with string b.
a |b文字列bとの連結b。
[a]b A string consisting of the single bit "a" repeated "b" times.
[a] b単一のビット「A」の繰り返しの「B」タイムで構成される文字列。
x mod y The remainder of division of x by y. The result will be between 0 and y.
x mod y y by yのxの残りの部分。結果は0からyの間になります。
g^x mod p The multiplication of the value "g" with itself "x" times, modulo the value "p".
g^x mod p値「g」とそれ自体「x」の乗算、値「p」をmoduloします。
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.
チョップ（x、y）弦xの減少は、少なくともyビットがyビットになります。
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、および可変長データを採用し、ランダムソースと区別できない固定長の出力を生成する擬似ランダム関数。
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.
ciphersuite 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.
EMSK EAP-PWDによってエクスポートされる拡張マスターセッションキー。これは、長さが高エントロピーの秘密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]を参照）。Exchangeの各当事者は、特定のドメインパラメーターのセット（ここでは「グループ」と呼ばれる）に関しては、短命キーを導き出します。グループは、有限畑暗号化（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.
o プライム、P、プライムフィールド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).
o gf（p）*の要素gは、FFCグループの発電機として機能します。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.
o gの乗算順序であるプライムr、したがってGF（P）*の暗号化サブグループのサイズは、Gによって生成されます。
An integer scalar, x, acts on an FFC group element, Y, via exponentiation modulo p -- Y^x mod p.
整数スカラーXは、指数モジュロP -Y^X mod 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つに等しくなるように定義されています。言い換えると、
(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グループは安全な素数に基づいており、順序はドメインパラメーターに含まれていません。この場合にのみ、順序rは、1つを2つ（p-1）/2で割った粒子マイナスとして計算する必要があります。グループの定義にドメインパラメーターに順序が含まれている場合、注文が求められている場合、この値をこの交換で使用する必要があります。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.
o プライム、P、プライムフィールドGF（P）の決定。暗号化グループは、楕円曲線上の点で構成される完全な楕円曲線グループのサブグループであり、曲線の方程式を満たす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).
o 曲線の方程式を定義するGF（P）の要素AとB。GF（p）x 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 ECCグループの発電機として機能する楕円曲線上のポイントG。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.
o gの順序であるプライムr、したがって、Gによって生成される暗号化サブグループのサイズでもあります。
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.
o 楕円曲線グループ（「無限のポイント」を含む）のサイズがfおよびrの積であるという要件によって定義された共因子F f。
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時間に追加されます）を介して、yccグループ要素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グループの逆関数は、要素とその逆の合計が「無限のポイント」（楕円曲線添加のアイデンティティ）であるように定義されます。言い換えると、
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での使用は定義されていません。さらに、1を超える（1）を超える共因子を持つECCグループは、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
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.
4. 関数hへの任意の入力の場合、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を決定することは計算上は実行不可能です。同様に、曲線定義、ジェネレーターG、y = x * gを与えられたECCグループの場合、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.
このメモで説明されているプロトコルは、ランダム関数Hを使用します。セクション2.3で述べられているように、これは[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オクテットで値がゼロであるキーを持つHMAC-SHA256（[RFC4634を参照]）によってインスタンス化されています。言い換えると、
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.
[SP800-108]によると、このプロトコルで使用されているKDFには、一般的な擬似ランダム関数（PRF）を使用したフィードバック構造を備えたカウンターモードがあります。PRFの特定の値は、サーバーが最初のEAP-PWDパケットをピアに送信するときに、ランダム関数とグループとともに指定されます。
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は、キーを伸ばし、キーにバインドするラベル、およびビット内の出力の希望の長さを示します。IとLの2つの内部変数を使用します。それぞれの長さは16ビットで、ネットワークの順序で表されます。アルゴリズム的には、次のとおりです。
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.
サーバーのアイデンティティとピアアイデンティティを表す文字列は、ネットワークアクセス識別子の[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:
EAP-PWDには、パスワード前処理の3つの手法が存在します。
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]から承認された誤差を含む[RFC2759]で定義されているように、出力PasswordHashhashを生成するために処理されなければなりません。この手法は、サーバーがPlantextパスワードにアクセスできない場合に役立ちます。
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ピアを定義します。
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.
ピアとサーバーは、ID交換を使用してお互いのアイデンティティを発見し、その後の交換で使用するために暗号外観に同意します。さらに、EAPサーバーは、EAP-PWD-ID/要求メッセージを使用して、必要になる可能性のあるパスワードの前処理をクライアントに通知します。コミット交換では、ピアとサーバーが交換して共有キーを生成し、パスワードの特定の推測に互いに結合します。確認交換では、ピアとサーバーは、検証データを生成および検証することにより、パスワードの活性と知識を証明します。
+--------+ +--------+
| | 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/request ciphersuite、トークン、パスワード処理方法、server_id
EAP-pwd-ID/Response Ciphersuite, Token, Password Processing Method, Peer_ID
eap-pwd-id/response ciphersuite、トークン、パスワード処理方法、peer_id
EAP-pwd-Commit/Request Scalar_S, Element_S
eap-pwd-commit/request scalar_s、element_s
EAP-pwd-Commit/Response Scalar_P, Element_P
eap-pwd-commit/response scalar_p、element_p
EAP-pwd-Confirm/Request Confirm_S
eap-pwd-confirm/request cundile_s
EAP-pwd-Confirm/Response Confirm_P
eap-pwd-confirm/response commint_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 Exchangeが完了すると、ピアとサーバーは互いのアイデンティティと合意されたCiphersuiteを使用して、パスワード要素と呼ばれるネゴシエートグループの要素を修正します（PWEまたはPWE、ECCグループの要素またはそれぞれ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-seed = h（token | peer-id | server-id |パスワード|カウンター）
Then, the pwd-seed is expanded using the KDF from the agreed-upon Ciphersuite out to the length of the prime:
次に、PWD-seedは、合意されたCiphersuiteからPrimeの長さまでKDFを使用して拡張されます。
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", 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値がPrime、P、P、カウンターが増加し、新しいPWDシードが生成され、ハンティングアンドペッキングが継続される場合。PWD値がPrime、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値は、楕円曲線の方程式を持つX座標Xとして直接使用され、曲線のドメインパラメーターセットからのパラメーターAとBを使用して、Y位を解きます。二次方程式の解決策がない場合、この操作は失敗し、狩猟と診察のプロセスが続きます。解決策が見つかった場合、方程式に技術的に2つの解があり、PWD-seedがそれらの1つを明確に選択するためにPWDシードが使用されるため、あいまいさが存在します。PWD-seedの低次ビットがYの低次ビットに等しい場合、候補PWEはポイント（x、y）として定義されます。PWD-seedの低次のビットがYの低次ビットと異なる場合、候補PWEはポイント（x、p-y）として定義されます。ここで、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)
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グループのグループ固有の操作は、PWD値を取得し、グループのドメインパラメーターセットからPWD-Valueを使用します（順序が定義されたドメインパラメーターセットの一部ではない場合はセクション2.2.1を参照）。PWD値を値（（p-1）/r）modulo the primeに指数指数することにより、候補パスワード要素PWEを直接生成します。結果が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)
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 ID交換の後、後続のメッセージのコンポーネントの構築は、Ciphersuite（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)
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
ELEMENT_SとSCALAR_Sは、EAP-PWD-commit/requestを作成するために使用されます
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)
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
Element_pとScalar_pは、EAP-PWD-commit/responseを構築するために使用されます
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)
Confirm_S is used to construct EAP-pwd-Confirm/Request
CONDIM_Sは、EAP-PWD-Confirm/リクエストを作成するために使用されます
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)
Confirm_P is used to construct EAP-pwd-Confirm/Response
CONDIF_Pは、EAP-PWD-Confirm/Responseの構築に使用されます
The EAP Server computes the shared secret as: MK = H(ks | Confirm_P | Confirm_S)
EAPサーバーは、共有秘密を計算します：mk = h（ks | cundif_p | cundif_s）
The EAP Peer computes the shared secret as: MK = H(kp | Confirm_P | Confirm_S)
EAPピアは共有秘密を計算します：mk = h（kp | cundif_p | cundif_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)
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
ELEMENT_SとSCALAR_Sは、EAP-PWD-commit/requestを作成するために使用されます
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)
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
Element_pとScalar_pは、EAP-PWD-commit/responseを構築するために使用されます
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)
Confirm_S is used to construct EAP-pwd-Confirm/Request
CONDIM_Sは、EAP-PWD-Confirm/リクエストを作成するために使用されます
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)
Confirm_P is used to construct EAP-pwd-Confirm/Request
CONDIF_Pは、EAP-PWD-Confirm/リクエストを作成するために使用されます
The EAP Server computes the shared secret as: MK = H(ks | Confirm_P | Confirm_S)
EAPサーバーは、共有秘密を計算します：mk = h（ks | cundif_p | cundif_s）
The EAP Peer computes the shared secret as: MK = H(kp | Confirm_P | Confirm_S)
EAPピアは共有秘密を計算します：mk = h（kp | cundif_p | cundif_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はピアのアイデンティティを決定するためのIDメソッドを提供しますが、IDの応答の値は、プライバシーを提供するか、ルーティングの目的で装飾されているために切り捨てられたり、難読化されたり[RFC3748]、EAP-PWDメソッドによる使用に不適切になっている可能性があります。したがって、EAP-PWD-ID交換は、ピアとサーバーの間でアイデンティティを交換する目的で定義されます。
The EAP-pwd-ID/Request contains the following quantities:
EAP-PWD-ID/リクエストには、次の数量が含まれています。
o a ciphersuite
o ciphersuite
o a representation of the server's identity per Section 2.7.1 o an anti-clogging token
o セクションごとのサーバーの身元の表現2.7.1 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.
Ciphersuiteは、その後の認証交換で使用するためにサーバーによって選択された有限循環グループ、ランダム関数、および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/リクエストを受け取ると、ピアは、CiphersuiteとPreprocessingメソッドが許容できるかどうかを決定します。そうでない場合、ピアはEAP-NAKで応答する必要があります。許容可能な場合、ピアは、セクション3.2.1に従って構築されたEAP-PWD-ID/応答でEAP-PWD-ID/応答で応答し、Ciphersuite、Token、およびPreprocessing Methodを認め、そのアイデンティティを追加します。EAP-PWD-ID/応答を送信した後、ピアはサーバー（リクエストから）、独自のアイデンティティ（応答でエンコード）、パスワードの前処理アルゴリズムの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 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.
EAP-PWD-ID/Responseは、リクエストからciphersuiteを認め、リクエストからのアンチ詰まりのトークンを、ピア側の「活性」のデモンストレーションを提供し、ピアのアイデンティティを含んでいます。応答を受け取ると、サーバーは、ピアによって認められた暗号外観がリクエストで送信されたものと同じであり、応答にピアによって追加されたアンチ詰まりのトークンがリクエストで送信されたものと同じであることを確認します。Ciphersuitesまたは詰まりのトークンが異なる場合、サーバーはEAPフェイルメッセージで応答する必要があります。詰まり防止トークンが同じである場合、サーバーはピアが交換にアクティブな参加者であることを知っています。ciphersuitesが同じ場合、サーバーは独自のアイデンティティ（リクエストでエンコードされている）とピアの身元（応答から）を把握し、セクション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.
サーバーは、S_RANDとS_MASKの2つの乱数を選択することにより、EAP-PWD-Confirm Exchangeを開始します。S_RANDとS_MASKは、1とR（セクション2.8.5.1で確立されたグループに従ってセクション2.1で説明されています）を選択します。1つ以上（1）。次に、セクション2.8.4で定義されている要素とスカラー_Sを計算し、セクション3.2.2に従ってEAP-PWDコミット/リクエストを構築します。Element_sとScalar_sは、この交換のために割り当てられた状態に追加され、EAP-PWD-Commit/リクエストはピアに送信されます。
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-Commit/リクエストを受信すると、ピアは、要素_SとSCALAR_Sの予想される長さ（合意されたグループの長さに応じて固定されている）に基づいて、ペイロード全体の長さを検証します。長さが正しくない場合、ピアは交換を終了する必要があります。長さが正しい場合、eAPPD-commit/requestからelement_sとscalar_sが抽出されます。次に、SCALAR_Sをチェックして、1〜Rの間であることを確認します。そうでない場合、ピアは交換を終了する必要があります。もしそうなら、element_sはグループのタイプに応じて検証する必要があります。FFCグループの要素検証はセクション2.8.5.2.1で説明され、ECCグループの要素検証はセクション2.8.5.2.2で説明されています。検証が成功した場合、ピアは2つの乱数、P_RANDとP_MASKを選択します。R（セクション2.8.5.1で確立されたグループに従って、Rはセクション2.1で説明されています）を選択します。1）、およびElement_pとScalar_pを計算します。次に、ピアは、P_RAND、Element_s、Scalar_s、およびセクション2.8.4に従ってパスワード要素からKPを計算します。KPが「アイデンティティ要素」（ECCグループの無限のポイントまたはFFCグループの値1（1）である場合）は、ピアが交換を終了する必要があります。そうでない場合、ピアは要素_PとSCALAR_Pを使用して、セクション3.2.2に従ってEAP-PWD-Commit/Responseを構築し、EAP-PWD-Commit/Responseをサーバーに送信します。
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-Commit/Responseを受信すると、サーバーは、要素_PとSCALAR_Pの予想される長さ（合意されたグループに従って修正）に基づいて、ペイロード全体の長さを検証します。長さが正しくない場合、サーバーはEAPフェイルメッセージで応答する必要があり、交換を終了し、割り当てられた状態を解放する必要があります。長さが正しい場合、SCALAR_PとElement_PはEAP-PWD-Commit/Responseから抽出され、SCALAR_SおよびElement_sと比較されます。Scalar_pがScalar_sに等しく、Element_pがElement_sに等しい場合、反射攻撃を示し、サーバーはEAPフェイルで応答し、Exchangeを終了する必要があります。それらが異なる場合、SCALAR_Pがチェックされて、それが1からRの間であることを確認します。そうでない場合は、サーバーがEAPフェイルで応答し、交換を終了する必要があります。もしそうなら、要素はグループのタイプに応じて検証されます - FFCグループの要素検証はセクション2.8.5.2.1で説明され、ECCグループの要素検証はセクション2.8.5.2.2で説明されています。検証が成功した場合、サーバーはS_RAND、Element_P、SCALAR_P、およびセクション2.8.4に従ってパスワード要素からKSを計算します。KSが「アイデンティティ要素」（ECCグループの無限のポイントまたはFFCグループの値1（1）である場合）は、サーバーがEAPフェイルで応答し、交換を終了する必要があります。それ以外の場合、サーバーはEAP-PWD-Confirm Exchangeを開始します。
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.
受信したFFC要素は、次の場合に有効です。1）1つの（1）とPrime、P、排他的です。2）グループ順序で要素のモジュラー指数をrが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に従って確認_を計算し、セクション3.2.3に従ってEAP-PWD-Confirm/リクエストを構築し、ピアに送信します。
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 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.
EAP-PWD-confirm/requestを受信すると、ピアは、confish_sの予想される長さに基づいてペイロード全体の長さを検証します（その長さは合意されたランダム関数によって固定されています）。長さが正しくない場合、ピアは交換を終了し、割り当てられた状態を解放する必要があります。長さが正しい場合、ピアは、confirm_sがKPの値に基づいて予想される値であることを確認します。confism_sの値が正しくない場合、ピアは交換を終了し、割り当てられた状態を解放する必要があります。confism_sの値が正しい場合、ピアコンピューターconfism_pは、セクション3.2.3に従ってEAP-PWD-Confirm/Responseを構築し、サーバーに送信します。ピアは、MK（セクション2.8.4に従って）とMSKとEMSK（セクション2.9による）を計算し、この交換に割り当てられた州のこれらのキーを保存します。ピアは、セッションキーを作成するために下層による安全な関連プロトコルを見越して、この時点でMSKとEMSKをエクスポートする必要があります。または、MSKとEMSKをエクスポートする前に、ピアはサーバーからのEAPサクセスメッセージまで待つことができます。
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/Responseを受信すると、サーバーは、confish_pの予想長に基づいてペイロード全体の長さを検証します（その長さは合意されたランダム関数によって固定されています）。長さが正しくない場合、サーバーはEAPフェイルメッセージで応答する必要があり、交換を終了し、割り当てられた状態を解放する必要があります。長さが正しい場合、サーバーは、confirm_pがKSの値に基づいて予想される値であることを確認します。confism_pの値が正しくない場合、サーバーはEAPフェイルメッセージで応答する必要があります。confism_pの値が正しい場合、サーバーはMK（セクション2.8.4に従って）とMSKとEMSK（セクション2.9による）を計算します。MSKとEMSKをエクスポートし、EAP-SUCSESSメッセージで応答します。サーバーは、この交換に割り当てられた状態を解放する必要があります。
[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を構築する方法を定義することを推奨しています。この情報はこのように構築されています。
Method-ID = H(Ciphersuite | Scalar_P | Scalar_S)
method-id = h（ciphersuite | scalar_p | scalar_s）
Session-ID = Type-Code | Method-ID
session-id = type-code |Method-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のサイズは、Ciphersuiteでアサートされたランダム関数Hに依存します。EAP-PWDは、2つの512ビットキー、MSKとEMSKをエクスポートする必要があります。LEN（MK）の価値に関係なく、実装は、MSKとEMSKを構築するためにセクション2.5で定義されているKDFを呼び出す必要があります。したがって、MSKとEMSKは次のように導き出されます。
MSK | EMSK = KDF(MK, Session-ID, 1024)
MSK |emsk = kdf（mk、session-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]は、特にキーキャッシングが使用されている場合、キーの名前の重要性に言及しています。このような重要な最適化を促進するために、名前は次のように割り当てられます。'e' |'m' |'s' |「K」
o MSK-name = Session-ID | 'M'| 'S' | 'K'
o msk-name = session-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'は値0x53の単一オクテット、「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グループ：[RFC5114]で定義されているグループ19
o Random Function: defined in Section 2.4
o ランダム関数：セクション2.4で定義されています
o PRF: HMAC-SHA256 defined in [RFC4634]
o PRF：[RFC4634]で定義されているHMAC-SHA256
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つのオクテットであり、リクエストとの対応を一致させるのに役立ちます。識別子フィールドは、各リクエストパケットで変更する必要があります。
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オクテットの合計長さフィールドの存在を示すように設定されており、断片化されたEAP-PWDメッセージまたはメッセージのセットの最初のフラグメントに設定する必要があります。
The M bit (more fragments) is set on all but the last fragment.
mビット（より多くのフラグメント）は、最後のフラグメントを除くすべてに設定されています。
PWD-Exch
pwd-exch
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-EXCHフィールドは、データフィールドにカプセル化されたEAP-PWDペイロードのタイプを識別します。このドキュメントは、PWD-Exchフィールドの次の値を定義します。
* 0x00 : Reserved
* 0x00：予約済み
* 0x01 : EAP-pwd-ID exchange
* 0x01：EAP-PWD-ID Exchange
* 0x02 : EAP-pwd-Commit exchange
* 0x02：EAP-PWDコミットエクスチェンジ
* 0x03 : EAP-pwd-Confirm exchange
* 0x03：EAP-PWD-Confirm Exchange
All other values of the PWD-Exch field are unassigned.
PWD-Exchフィールドの他のすべての値は割り当てられていません。
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 Exchangeのペイロードには、使用する有限環境グループ、Hに使用する暗号化原始、およびキーの導出に使用するPRFを示すCiphersuiteステートメントも含まれています。
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]
o 0x01：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:
PREPフィールドは、パスワードシードを生成する前にクライアントが使用するパスワード前処理手法（セクション2.7.2を参照）を表します（セクション2.8.3を参照）。このドキュメントは、準備フィールドの次の値を定義します。
o 0x00 : None
o 0x00：なし
o 0x01 : RFC2759
o 0x01：RFC2759
o 0x02 : SASLprep
o 0x02：saslprep
All other values of the Prep field are unassigned.
PREPフィールドの他のすべての値は割り当てられていません。
The Identity field depends on the tuple of PWD-Exch/Code.
IDフィールドは、PWD-Exch/コードのタプルに依存します。
o EAP-pwd-ID/Request : Server_ID
o eap-pwd-id/request：server_id
o EAP-pwd-ID/Response : Peer_ID
o EAP-PWD-ID/Response：PEER_ID
The length of the identity is computed from the Length field in the EAP header.
IDの長さは、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-Exch/コードのタプルに依存します。
o EAP-pwd-Commit/Request : Element_S, Scalar_S
o eap-pwd-commit/request：element_s、scalar_s
o EAP-pwd-Commit/Response : Element_P, Scalar_P
o eap-pwd-commit/response：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-Confirmペイロード
The Confirm field depends on the tuple of PWD-Exch/Code.
確認フィールドは、PWD-Exch/コードのタプルに依存します。
o EAP-pwd-Confirm/Request : Confirm_S
o eap-pwd-confirm/request：commis_s
o EAP-pwd-Confirm/Response : Confirm_P
o eap-pwd-confirm/response：commis_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グループの要素は、合意された楕円曲線のポイントです。そのような各要素は、2つのコンポーネントの連結、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.
2つのコンポーネントのそれぞれ、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のビット長の2倍でなければなりません。言い換えれば、「圧縮表現」は使用されません。
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オクテットの合計長さフィールドの存在を示すように設定されており、断片化された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-Type = EAP-PWDを使用した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-Type = EAP-PWDおよびデータなしのEAP-Requestで応答する必要があります。これは、フラグメントACKとして機能します。EAPピアは、別のフラグメントを送信する前に、EAP-Requestを受信するまで待つ必要があります。フラグメントの処理のエラーを防ぐために、EAPサーバーはEAP-Request内に含まれる各フラグメント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が管理する新しい数字スペースが含まれています。数値を割り当てるために使用されるポリシーは[RFC5226]で説明されています。IANAは、EAP-PWDに新しいEAPメソッドタイプを割り当てました（52）。
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-Exchメッセージ、ランダム関数、PRF、およびパスワードの前処理方法の新しいレジストリを作成し、このメモでそれぞれこれらのメモに指定されたメッセージ番号、ランダム関数、PRF、および前処理方法を追加しました。
The following is the initial PWD-Exch message registry layout:
以下は、最初のPWD-EXCHメッセージレジストリレイアウトです。
o 0x00 : Reserved
o 0x00：予約済み
o 0x01 : EAP-pwd-ID exchange
o 0x01：EAP-PWD-ID Exchange
o 0x02 : EAP-pwd-Commit exchange
o 0x02：EAP-PWDコミットエクスチェンジ
o 0x03 : EAP-pwd-Confirm exchange
o 0x03：EAP-PWD-Confirm Exchange
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-Exchフィールドの長さは6ビットです。値0x00は予約されています。他のすべての値は、IANAによる割り当てを通じて利用できます。IANAは、「IETFレビュー」に基づいて値を割り当てるように指示されます（[RFC5226]を参照）。
The following is the initial Random Function registry layout:
以下は、最初のランダム関数レジストリレイアウトです。
o 0x00 : Private Use
o 0x00：プライベート使用
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]を参照）。必要なレビューを実行する指定された専門家は、ランダム関数が暗号化された審査されたことを確認する必要があります。
The following is the initial PRF registry layout:
以下は、最初のPRFレジストリレイアウトです。
o 0x00 : Private Use
o 0x00：プライベート使用
o 0x01 : HMAC-SHA256 as defined in [RFC4634]
o 0x01：[RFC4634]で定義されているHMAC-SHA256
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 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]).
o 0x02：SASLPREP PREPフィールドの長さは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.
ピア（サーバー）の秘密のランダム値は、P_RAND（S_RAND）モジュロにP_MASK（S_MASK）をグループの順序に追加することにより、効果的に隠されます。順序が「R」の場合、値scalar_p（scalar_s）に合計する数字のほぼ「r」のペアがあります。特定のペアを推測しようとすることは、秘密のランダム値p_rand（s_rand）を推測するのと同じくらい難しいです。推測の確率は、「i」推測の後の1/（r -i）です。Rの大きな値の場合、この徹底的な検索手法は計算的に実行不可能です。攻撃者は、Rグループ操作の平方根の順序で実行されるベビーステップジャイアントステップアルゴリズム（[Appcry]を参照）などのアルゴリズムを使用して、要素_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は不明のままであるため、アクティブな攻撃はパッシブ攻撃者の攻撃に還元されました。アクティブな攻撃者は、CONDIME_P（CONDIME_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-Commit/ResponseをForgeしてサーバーに送信するまで待つことができます。サーバーは、EAP-PWD-Confirm/リクエストで応答します。これで、攻撃者は辞書攻撃の開始を試みることができます。彼女は、潜在的なパスワードを推測し、パスワード要素を計算し、EAP-PWD-Commit/要求からP_RAND、SCALAR_S、およびElement_sを使用してKPを計算できます。彼女は、EAP-PWD-Confirm/リクエストでCONDICE_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.
しかし、攻撃者は、彼女が要素_Pを計算したときに、彼女が偽造されたEAP-PWDコミュニティ/応答でパスワード推測をコミットしました。その値は、eap-pwd-confirm/requestで確認_sを構築したときに使用されたKSの計算でサーバーによって使用されました。攻撃者はそれが正しいかどうかを知る方法がないため、鍛造EAP-PWDコミュニティ/応答で使用されているパスワードとは異なるパスワードの推測は正しいものとして検証できませんでした。彼女は攻撃ごとに1つの推測と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コミット/応答で推測にコミットし、辞書を実行して、Forged Scalar_pとElement_pを使用してパスワード要素とKSを計算できます。彼女は、EAP-PWD-confirm/requestでサーバーが生成したconfism_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
PWE = Q * G、ECCグループの場合
pwe = g^q mod p, for an FFC group
pwe = g^q mod p、ffcグループ用
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: 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.
Qの知識を使用して、辞書攻撃を開始できます。簡潔にするために、ECCグループを想定して攻撃が実証されます。このように攻撃は機能します。攻撃者は、正直なサーバーがEAP-PWDコミット/リクエストを送信するまで待ちます。攻撃者はランダムScalar_pとランダムP_MASKを生成し、Element_P = P_MASK * Gを計算します。攻撃者はBogus scalar_pとelement_pをサーバーに送信し、見返りにcondien_sを取得します。サーバーは、要素_Pが誤って計算されたことを検出できないことに注意してください。
The attacker now knows that:
攻撃者は今それを知っています：
KS = (Scalar_P * q + p_mask) * s_rand * G
and
と
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と計算を使用してQを使用して使用できます。cundile_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つの推測後の成功の確率は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はMKから抽出されます。MKは、S_RAND、P_RAND、およびパスワード要素でグループ操作を行うことから派生しています。ピアとサーバーは、プロトコルの実行ごとにランダム値を選択します。したがって、攻撃者がパスワードを学習できたとしても、以前の実行からピアまたはサーバーのいずれかが使用するランダムな値を知りません。したがって、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.
このメモで定義されている必須の実装グループは、楕円曲線暗号化（セクション2.2.2を参照）に基づいた[RFC5114]のグループであるグループ19です。このグループを使用して導出された対称キーは128ビットで、これは高度な暗号化標準の典型的な長さです（[FIPS-197]）。有限のフィールド暗号化に基づいたグループを使用して、同等の強度の尺度を取得することは可能ですが（セクション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.
このプロトコルで使用できる定義されたグループのいくつかは、セキュリティの推定値（セクション6.5を参照）を128ビット未満にしていますが、多くのビットはそうではありません。、新しいランダム関数は、その入力を少なくとも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].
* 相互認証：共有パスワードの所有を証明することにより、ピアとサーバーの両方が互いに認証されます。これは[RFC4017]で必要です。
* forward secrecy: compromise of the password does not reveal the secret keys -- MK, MSK, or EMSK -- from earlier runs of the protocol.
* Forward Secrecy：パスワードの妥協は、プロトコルの以前の実行からSecret Keys（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またはEMSKの妥協を可能にしません。
* 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 Association、または802.3 "Link-up"）を介して接続を取得し、2つのEAPメッセージに応答するという要件により、ゲートされています。-id/ requestおよびeap-pwd-id/ request。EAP-PWD-ID Exchangeには、ピアが少なくとも基本的な量の処理を実行し、単にパケットをスプレーするだけでなく、サーバーにレベルの保証を提供するアンチコーギングトークンがさらに含まれます。これにより、分散されたサービス拒否攻撃を防ぎ、また、Mac（メディアアクセス制御）アドレスなどの低層のアイデンティティを発表し、コミットする必要があります。
* 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].
* 中間の攻撃抵抗：この交換は積極的な攻撃に耐性があります。これは、中間の攻撃を開始するための要件です。これは[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、Method-ID、およびSession-IDに同意します。ピアはサーバーIDに基づいてサーバーを認証し、サーバーはPeer-IDに基づいてピアを認証しました。これは、Peer-ID、Server-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.
* 「Denning-Sacco」攻撃に対する抵抗：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とEMSKは、セクション2.8.4で説明されているように、セクション2.5で定義されたKDFを使用してMKから派生します。
e. vulnerabilities (note that none of these are REQUIRED by [RFC4017]):
e. 脆弱性（これらのいずれも[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.
* 保護されたciphersuite交渉：サーバーが作成した暗号外観のオファーは、アクティブな攻撃者による改ざんから保護されていません。ただし、これは許容可能な暗号筋のリストを含む「交渉」ではないため、ダウングレード攻撃は防止されます。Ciphersuiteがアクティブな攻撃者によって変更された場合、Ciphersuiteが各側に確認メッセージに結合し、結果としてプロトコルが失敗するため、相手が送信したメッセージを確認できなくなります。
* 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.
* アイデンティティ保護：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を防ぐためにPWE/PWEを修正するための彼の非常に役立つ提案について、Scott Fluhrerに感謝します。著者はまた、基礎となる主要な交換プロトコルの以前のバージョンに対する攻撃を発見したという洞察について、鈴木史に感謝したいと思います。楕円曲線へのハッシュについての有益な議論と、小さなサブグループ攻撃から保護するための対策を提案してくれたJin-Meng Hoに感謝してくれたリリーチェンに感謝します。リッチデイビスは、メッセージをコミットするための防御チェックを提案し、彼のさまざまなコメントは、このメモの品質とそれが基づいている基礎となる主要な交換を大幅に改善しました。Scott Kellyは、分散型サービス拒否攻撃を防ぐために、Anti-Crogging TokenをID Exchangeに追加することを提案しました。ドロシー・スタンレーは、このメモの品質を向上させるために貴重な提案を提供しました。使用された断片化法は[RFC5216]から取られました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759] Zorn、G。、「Microsoft PPP Chap Extensions、バージョン2」、RFC 2759、2000年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、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.、Blunk、L.、Vollbrecht、J.、Carlson、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] Eastlake、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and HMAC-SHA）」、RFC 4634、2006年7月。
[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] Chen、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] Barker、E.、Johnson、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.
[Appcry] Menezes、A.、Van Oorshot、P。、およびS. Vanstone、「Handbook of Applied Cryprography」、CRC Press Series on Disclete Mathematics and Its Applications、1996。
[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. Merritt、「暗号化されたキーエクスチェンジ：パスワードベースのプロトコルは辞書攻撃に対して確保されます」、セキュリティとプライバシーに関するIEEEシンポジウムの議事録、1992年。
[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. Merritt、「拡張暗号化されたキー交換：辞書攻撃とパスワードファイルの妥協に対して安全なパスワードベースのプロトコル」、コンピューターおよび通信セキュリティに関する第1回ACM会議の議事録、ACM Press、1993。
[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.、Mackenzie、P。、およびS. Patel、「Diffie-Hellmanを使用したパスワード認証キー交換」、EuroCrypt 2000の議事録、LNCS 1807 Springer-Verlag、2000。
[FIPS-197] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), November 2001.
[FIPS-197]国立標準技術研究所、FIPS Pub 197：Advanced Encryption Standard（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 Computer Communication Review 1、Issue 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、Springer-Verlag、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] Bellare、M。およびP. Rogaway、「ランダムオラクルは実用的です：効率的なプロトコルを設計するためのパラダイム」、コンピューターおよび通信セキュリティに関する第1回ACM会議の議事録、ACM Press、1993。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、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] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（EAP）メソッド要件」、RFC 4017、2005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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。and 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. Kent、「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] Simon、D.、Aboba、B。、およびR. Hurst、「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.、Simon、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クロスマンアベニューサニーベール、カリフォルニア94089-1113 USA
EMail: dharkins@arubanetworks.com
Glen Zorn Network Zen 1310 East Thomas Street #306 Seattle, WA 98102 USA
Glen Zorn Network Zen 1310 East Thomas Street＃306シアトル、ワシントン州98102 USA
Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net