Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6124 Independent
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
H. Tschofenig
Nokia Siemens Networks
S. Fluhrer
Cisco
February 2011
An EAP Authentication Method Based on
the Encrypted Key Exchange (EKE) Protocol
Abstract
抽象
The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates.
拡張認証プロトコル（EAP）は、複数の認証メカニズムの使用を可能にするフレームワークを記述する。この文書では、暗号化キー交換（EKE）プロトコルに基づくEAP-EKEと呼ばれるEAPの認証メカニズムを定義します。この方法は、短い覚えやすいパスワードを使用して相互認証を提供します。他の一般的な認証方法と比較すると、EAP-EKEは、辞書攻撃の影響を受けません。どちらも、それは、公開鍵証明書の利用可能性を必要としないん。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6124.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6124で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7
4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8
4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10
4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11
4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12
4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13
4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14
4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15
5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15
5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17
5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18
5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18
5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19
6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19
6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19
6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20
6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27
8.2. Diffie-Hellman Group Considerations . . . . . . . . . . . 28
8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28
8.4. Identity Protection, Anonymity, and Pseudonymity . . . . . 28
8.5. Password Processing and Long-Term Storage . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 31
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 to the 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-EKE is an EAP method [RFC3748] that addresses the problem of password-based authenticated key exchange, using a possibly weak password for authentication and to derive an authenticated and cryptographically strong shared secret. This problem was first described by Bellovin and Merritt in [BM92] and [BM93]. Subsequently, a number of other solution approaches have been proposed, for example [JAB96], [LUC97], [BMP00], and others.
EAP-EKEはおそらく弱いパスワード認証のため、認証と暗号的に強力な共有秘密を導出するを使用して、パスワードベースの認証された鍵交換の問題に対処するEAP方式[RFC3748]です。この問題は、最初の[BM92]と[BM93]でBellovin氏とメリットにより記載されました。続いて、他のソリューションの多くのアプローチは、例えば、[JAB96]、[LUC97]、[BMP00]などが提案されています。
This proposal is based on the original Encrypted Key Exchange (EKE) proposal, as described in [BM92]. Some of the variants of the original EKE have been attacked, see e.g., [PA97], and improvements have been proposed. None of these subsequent improvements have been incorporated into the current protocol. However, we have used only the subset of [BM92] (namely the variant described in Section 3.1 of that paper) that has withstood the test of time and is believed secure as of this writing.
【BM92]に記載されているように、この提案は、元の暗号化キー交換（EKE）提案に基づいています。元EKEの変異体のいくつかは、例えば参照、[PA97]、攻撃されており、改善が提案されています。これらの後続の改善はいずれも、現在のプロトコルに組み込まれていません。しかし、我々は時間のテストに耐えており、この書き込みのような安全な考えられる[BM92（すなわち紙のセクション3.1に記載さ即ち変異体）のサブセットのみを使用しています。
This document uses Encr(Ke, ...) to denote encrypted information, and Prot(Ke, Ki, ...) to denote encrypted and integrity protected information.
この文書は暗号化された情報を示すためにENCR（柯、...）を使用し、Protの（柯、KI、...）は、暗号化と完全性保護された情報を示すために。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
EAP is a two-party protocol spoken between an EAP peer and an EAP server (also known as "authenticator"). 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 and the EAP peer for the purpose of authentication and key derivation.
EAPは、EAPピアと（また、「オーセンティケータ」としても知られる）EAPサーバとの間で話さ二者のプロトコルです。 EAPメソッドはEAPによって使用されている特定の認証プロトコルを定義します。このメモは、特定の方法を定義し、したがって、認証および鍵導出のためにEAPサーバとEAPピアとの間で送信されるメッセージを定義します。
A successful run of EAP-EKE consists of three message exchanges: an Identity exchange, a Commit exchange, and a Confirm exchange. This is shown in Figure 1.
アイデンティティ交換、コミット交換、および確認交換：EAP-EKEの成功の実行は、3回のメッセージ交換で構成されています。これは、図1に示されています。
The peer and server use the EAP-EKE Identity exchange to learn each other's identities and to agree upon a ciphersuite to use in the subsequent exchanges. 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 (note that the second message of the Commit exchange already plays an essential part in this liveness proof).
ピアとサーバは互いのアイデンティティを学ぶために、その後の交換に使用する暗号スイートに合意するEAP-EKEアイデンティティ交換を使用します。交換、ピアおよびサーバの情報交換、共有鍵を生成すると、パスワードの特定の推測に互いに結合することをコミットで。確認交換では、ピアとサーバは（コミット為替の2番目のメッセージは既にこのライブネス証拠に不可欠な役割を果たしていることに注意してください）検証データを生成し、検証することにより、パスワードの生存性と知識を証明します。
+--------+ +--------+
| | EAP-EKE-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| (P) | EAP-EKE-ID/Response | (S) |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: A Successful EAP-EKE Exchange
図1：成功したEAP-EKE交換
Schematically, the original exchange as described in [BM92] (and with the roles reversed) is:
概略的に、[BM92（および逆ロールを持つ）に記載されているように、元の交換があります。
Server Peer
------ ----
Encr(Password, y_s) ->
ENCR（パスワード、Y_S） - >
<- Encr(Password, y_p), Encr(SharedSecret, Nonce_P)
< - ENCR（パスワード、y_p）、ENCR（しsharedsecret、Nonce_P）
Encr(SharedSecret, Nonce_S | Nonce_P) ->
ENCR（しsharedsecret、NONCE_S | Nonce_P） - >
<- Encr(SharedSecret, Nonce_S)
< - ENCR（しsharedsecret、NONCE_S）
Where:
どこ：
o Password is a typically short string, shared between the server and the peer. In other words, the same password is used to authenticate the server to the peer, and vice versa.
Oパスワードサーバとピアとの間で共有典型的には、短い文字列です。換言すれば、同一のパスワードは、ピアへのサーバ、およびその逆を認証するために使用されます。
o y_s and y_p are the server's and the peer's, respectively, ephemeral public key, i.e., y_s = g ^ x_s (mod p) and y_p = g ^ x_p (mod p).
Y_Sとy_p Oサーバーのピアの、それぞれ、はかない公開鍵、すなわち、Y_S = G ^ x_s（MOD p）及びy_p = G ^ x_p（MOD P）です。
o Nonce_S, Nonce_P are random strings generated by the server and the peer as cryptographic challenges.
NONCE_S O、Nonce_Pは、暗号化の課題として、サーバおよびピアによって生成されるランダム文字列です。
o SharedSecret is the secret created by the Diffie-Hellman algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This value is calculated by the server as: SharedSecret = y_p ^ x_s (mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p).
Oしsharedsecret、すなわちしsharedsecret = G ^（x_s * x_p）（MOD P）のDiffie-Hellmanアルゴリズムによって作成された秘密です。ようにしsharedsecret = y_p ^ x_s（MOD P）、およびピアによって::しsharedsecret = Y_S ^ x_p（MOD P）この値は、としてサーバによって計算されます。
The current protocol extends the basic cryptographic protocol, and the regular successful exchange becomes:
現在のプロトコルは、基本的な暗号プロトコルを拡張し、定期的な成功交換は次のようになります。
Message Server Peer
--------- -------- ------
ID/Request ID_S, CryptoProposals ->
ID/Response <- ID_P, CryptoSelection
ID /レスポンス< - ID_P、CryptoSelection
Commit/Request Encr(Password, y_s) ->
コミット/リクエストENCR（パスワード、Y_S） - >
Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P)
</レスポンスをコミット - ENCR（パスワード、y_p）、Protの（柯、KI、Nonce_P）
Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S ->
確認/リクエストProtの（柯、KI、NONCE_S | Nonce_P）、Auth_S - >
Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P
確認/レスポンス< - Protの（柯、KI、NONCE_S）、Auth_P
Where, in addition to the above terminology:
ここで、上記の用語に加えて：
o Encr means encryption only, and Prot is encryption with integrity protection.
O ENCRは暗号化のみを意味し、Protが完全性保護と暗号化です。
o Ke is an encryption key, and Ki is an integrity-protection key.
O柯は、暗号化鍵であり、Kiが完全性保護キーです。
Section 5 explains the various cryptographic values and how they are derived.
第5節では、さまざまな暗号値を説明し、それらがどのように導出されています。
As shown in the exchange above, the following information elements have been added to the original protocol: identity values for both protocol parties (ID_S, ID_P), negotiation of cryptographic protocols, and signature fields to protect the integrity of the negotiated parameters (Auth_S, Auth_P). In addition, the shared secret is not used directly. In this initial exposition, a few details were omitted for clarity. Section 5 should be considered as authoritative regarding message and field details.
ネゴシエートされたパラメータ（Auth_Sの完全性を保護するために、同一の両方のプロトコル当事者（ID_S、ID_P）の値が、暗号プロトコルのネゴシエーション、および署名フィールド、上記交換に示すように、次の情報要素は、元のプロトコルに追加されていますAuth_P）。また、共有秘密は、直接使用されていません。この最初の博覧会では、いくつかの詳細を明確にするために省略されました。第5節では、権威に関するメッセージやフィールドの詳細として考慮されるべきです。
EAP-EKE defines a small number of message types, each message consisting of a header followed by a payload. This section defines the header, several payload formats, as well as the format of specific fields within the payloads.
EAP-EKEは、メッセージ・タイプの数が少ない、ペイロードが続くヘッダからなる各メッセージを定義します。このセクションは、ヘッダ、いくつかのペイロード・フォーマット、ならびにペイロード内の特定のフィールドのフォーマットを定義します。
As usual, all multi-octet strings MUST be laid out in network byte order.
いつものように、すべてのマルチオクテット文字列は、ネットワークバイト順にレイアウトされなければなりません。
The EAP-EKE header consists of the standard EAP header (see Section 4 of [RFC3748]), followed by an EAP-EKE exchange type. The header has the following structure:
EAP-EKEヘッダは、EAP-EKE交換型続いて標準EAPヘッダ（[RFC3748]のセクション4を参照）、から成ります。ヘッダは、以下の構造を有します。
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 | EKE-Exch | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EAP-EKE Header
図II：M-中心ヘッダ
The Code, Identifier, Length, and Type fields are all part of the EAP header as defined in [RFC3748]. The Type field in the EAP header is 53 for EAP-EKE Version 1.
[RFC3748]で定義されるようにコード、識別子、長さ、タイプフィールドは、すべてのEAPヘッダの一部です。 EAPヘッダーのタイプフィールドはEAP-EKEバージョン1 53です。
The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE payload encapsulated in the Data field. This document defines the following values for the EKE-Exch field:
EKE-エクスチェンジクラブ（EKE交換）フィールドは、データフィールドにカプセル化されたEAP-EKEペイロードのタイプを識別する。この文書では、EKE-エクスチェンジクラブフィールドに次の値を定義します。
o 0x00: Reserved
0x00のO：予約
o 0x01: EAP-EKE-ID exchange
0x01のO：EAP-EKE-ID交換
o 0x02: EAP-EKE-Commit exchange o 0x03: EAP-EKE-Confirm exchange
Oが0x02：0x03のO EAP-EKE-コミット為替：EAP-EKE-確認交換
o 0x04: EAP-EKE-Failure message
0x04のO：EAP-EKE失敗メッセージ
Further values of this EKE-Exch field are available via IANA registration (Section 7.7).
このEKE-エクスチェンジクラブフィールドのさらなる値は、IANA登録（セクション7.7）を介して入手可能です。
EAP-EKE messages all contain the EAP-EKE header and information encoded in a single payload, which differs for the different exchanges.
EAP-EKEメッセージすべてが異なる交換に異なる単一のペイロードにエンコードされたEAP-EKEヘッダ情報を含みます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProposals | Reserved | Proposal ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Proposal | IDType | Identity ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EAP-EKE-ID Payload
図3：EAP-EKE-IDペイロード
The EAP-EKE-ID payload contains the following fields:
EAP-EKE-IDペイロードは、以下のフィールドが含まれています。
NumProposals:
NumProposals：
The NumProposals field contains the number of Proposal fields subsequently contained in the payload. In the EAP-EKE-ID/Request message, the NumProposals field MUST NOT be set to zero (0), and in the EAP-EKE-ID/Response message, the NumProposals field MUST be set to one (1). The offered proposals in the Request are listed contiguously in priority order, most preferable first. The selected proposal in the Response MUST be fully identical with one of the offered proposals.
NumProposalsフィールドは、その後、ペイロードに含まれる提案のフィールドの数が含まれています。 EAP-EKE-ID /要求メッセージに、NumProposalsフィールドがゼロ（0）に設定してはいけません、そしてEAP-EKE-ID /応答メッセージに、NumProposalsフィールドは1（1）に設定しなければなりません。要求で提供される提案は、最も好ましい第一、優先順に連続的に記載されています。応じて選択提案が提供された提案の一つと完全に同じでなければなりません。
Reserved:
予約：
This field MUST be sent as zero, and MUST be ignored by the recipient.
このフィールドはゼロとして送らなければなりませんし、受信者は無視しなければなりません。
Proposal:
提案：
Each proposal consists of four one-octet fields, in this order:
各提案は、この順に4つの1オクテットフィールドから構成されています
Group Description:
グループの説明：
This field's value is taken from the IANA registry for Diffie-Hellman groups defined in Section 7.1.
このフィールドの値は、7.1節で定義されているのDiffie-HellmanグループのためのIANAレジストリから取得されます。
Encryption:
暗号化：
This field's value is taken from the IANA registry for encryption algorithms defined in Section 7.2.
このフィールドの値は、7.2節で定義された暗号化アルゴリズムのためのIANAレジストリから取得されます。
PRF:
PRF：
This field's value is taken from the IANA registry for pseudo-random functions defined in Section 7.3.
このフィールドの値は、7.3節で定義された擬似ランダム機能のためのIANAレジストリから取得されます。
MAC:
マック：
This field's value is taken from the IANA registry for keyed message digest algorithms defined in Section 7.4.
このフィールドの値は、7.4節で定義されたキー付きメッセージダイジェストアルゴリズムのためのIANAレジストリから取得されます。
IDType:
idtype：
Denotes the Identity Type. This is taken from the IANA registry defined in Section 7.5. The server and the peer MAY use different identity types. All implementations MUST be able to receive two identity types: ID_NAI and ID_FQDN.
アイデンティティのタイプを示します。これは、7.5節で定義されているIANAレジストリから取得されます。サーバとピアは異なるIDタイプを使用するかもしれません。 ID_NAIとID_FQDN：すべての実装は2つのアイデンティティタイプを受け取ることができなければなりません。
Identity:
身元：
The meaning of the Identity field depends on the values of the Code and IDType fields.
アイデンティティ・フィールドの意味は、コードとのidtypeフィールドの値に依存します。
* EAP-EKE-ID/Request: server ID
* EAP-EKE-ID /要求：サーバーID
* EAP-EKE-ID/Response: peer ID
* EAP-EKE-ID /レスポンス：ピアID
The length of the Identity field is computed from the Length field in the EAP header. Specifically, its length is
アイデンティティ・フィールドの長さは、EAPヘッダの長さフィールドから計算されます。具体的には、その長さは
eap_header_length - 9 - 4 * number_of_proposals.
eap_header_length - 9 - 4 * number_of_proposals。
This field, like all other fields in this specification, MUST be octet-aligned.
このフィールドは、この仕様のすべての他の分野と同様に、オクテット整列させる必要があります。
This payload allows both parties to send their encrypted ephemeral public key, with the peer also including a Challenge.
このペイロードは、両当事者はまた、チャレンジを含むピアと、その暗号化されたはかない公開鍵を送信することができます。
In addition, a small amount of data can be included by the server and/or the peer, and used for channel binding. This data is sent here unprotected, but is verified later, when it is signed by the Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange.
加えて、少量のデータをサーバー及び/又はピアによって含めることができ、及び結合チャネルに使用されます。このデータは、ここで保護されていない送信されますが、それはEAP-EKE-確認交換のAuth_S / Auth_Pペイロードによって署名されている場合、後で検証されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHComponent_S/DHComponent_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBValue (zero or more occurrences) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-EKE-Commit Payload
図4：EAP-EKE-コミットペイロード
DHComponent_S/DHComponent_P:
DHComponent_S / DHComponent_P：
This field contains the password-encrypted Diffie-Hellman public key, which is generated as described in Section 5.1. Its size is determined by the group and the encryption algorithm.
このフィールドは、セクション5.1で説明したように生成されたパスワード暗号化のDiffie-Hellman公開鍵を、含まれています。その大きさは、グループおよび暗号化アルゴリズムによって決定されます。
PNonce_P:
PNonce_P：
This field only appears in the response, and contains the encrypted and integrity-protected challenge value sent by the peer. The field's size is determined by the encryption and MAC algorithms being used, since this protocol mandates a fixed nonce size for a given choice of algorithms. See Section 5.2.
このフィールドは応答に表示され、ピアによって送信された暗号化と完全性保護されたチャレンジ値が含まれています。このプロトコルは、アルゴリズムの特定の選択のための固定ナンスサイズを義務付けているので、フィールドのサイズは、暗号化によって決定され、MACアルゴリズムが使用されています。 5.2節を参照してください。
CBValue:
CBValue：
This structure MAY be included both in the request and in the response, and MAY be repeated multiple times in a single payload. See Section 4.5. Each structure contains its own length. The field is neither encrypted nor integrity protected, instead it is protected by the AUTH payloads in the Confirm exchange.
この構造は、要求および応答の両方に含まれてもよく、単一のペイロードに複数回繰り返してもよいです。 4.5節を参照してください。各構造体は、独自の長さが含まれています。フィールドではなく、それが確認交換でAUTHペイロードによって保護され、暗号化や完全性を保護でもありません。
Using this payload, both parties complete the authentication by generating a shared temporary key, authenticating the entire protocol, and generating key material for the EAP consumer protocol.
このペイロードを使用して、両当事者は、共有一時鍵を生成するプロトコル全体を認証し、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_PS/PNonce_S ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth_S/Auth_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-EKE-Confirm Payload
図5：EAP-EKE-確認ペイロード
PNonce_PS/PNonce_S:
PNonce_PS / PNonce_S：
This field ("protected nonce") contains the encrypted and integrity-protected response to the other party's challenge; see Sections 5.3 and 5.4. Similarly to the PNonce_P field, this field's size is determined by the encryption and MAC algorithms.
このフィールド（「保護されたナンス」）は相手のチャレンジに暗号化と完全性保護された応答が含まれています。セクション5.3と5.4を参照してください。同様にPNonce_Pフィールドに、このフィールドのサイズは、暗号化とMACアルゴリズムによって決定されます。
Auth_S/Auth_P:
Auth_S / Auth_P：
This field signs the preceding messages, including the Identity and the negotiated fields. This prevents various possible attacks, such as algorithm downgrade attacks. See Section 5.3 and Section 5.4. The size is determined by the pseudo-random function negotiated.
このフィールドは、アイデンティティと交渉さフィールドを含む、先行するメッセージを、署名します。これは、このようなアルゴリズムのダウングレード攻撃などの様々な可能性のある攻撃を防ぐことができます。 5.3節および5.4節を参照してください。大きさは、ネゴシエートされた擬似ランダム関数によって決定されます。
The EAP-EKE-Failure payload format is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-EKE-Failure Payload
図6：EAP-EKE-障害ペイロード
The payload's size is always exactly 4 octets.
ペイロードのサイズは、常に正確に4つのオクテットです。
The following Failure-Code values are defined:
次の障害コード値が定義されています。
+------------+----------------+-------------------------------------+
| Value | Name | Meaning |
+------------+----------------+-------------------------------------+
| 0x00000000 | Reserved | |
| 0x00000001 | No Error | This code is used for failure |
| | | acknowledgement, see below. |
| 0x00000002 | Protocol Error | A failure to parse or understand a |
| | | protocol message or one of its |
| | | payloads. |
| 0x00000003 | Password Not | A password could not be located for |
| | Found | the identity presented by the other |
| | | protocol party, making |
| | | authentication impossible. |
| 0x00000004 | Authentication | Failure in the cryptographic |
| | Failure | computation, most likely caused by |
| | | an incorrect password or an |
| | | inappropriate identity type. |
| 0x00000005 | Authorization | While the password being used is |
| | Failure | correct, the user is not authorized |
| | | to connect. |
| 0x00000006 | No Proposal | The peer is unwilling to select any |
| | Chosen | of the cryptographic proposals |
| | | offered by the server. |
+------------+----------------+-------------------------------------+
Additional values of this field are available via IANA registration, see Section 7.8.
このフィールドの追加の値は、7.8節を参照して、IANA登録を経由して利用できます。
When the peer encounters an error situation, it MUST respond with EAP-EKE-Failure. The server MUST reply with an EAP-Failure message to end the exchange.
ピアがエラー状況に遭遇すると、それはEAP-EKE-失敗で応じなければなりません。サーバーは、交換を終了するEAP-失敗メッセージで応答しなければなりません。
When the server encounters an error situation, it MUST respond with EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message containing a "No Error" failure code. Then the server MUST send an EAP-Failure message to end the exchange.
サーバがエラー状況に遭遇すると、それはEAP-EKE-失敗で応じなければなりません。ピアは、「エラーなし」失敗コードを含むEAP-EKE失敗メッセージを返送しなければなりません。次に、サーバは、交換を終了するEAP失敗メッセージを送らなければなりません。
Implementation of the "Password Not Found" code is not mandatory. For security reasons, implementations MAY choose to return "Authentication Failure" also in cases where the password cannot be located.
「パスワードが見つかりません」のコードの実装は必須ではありません。セキュリティ上の理由から、実装はパスワードが見つからない場合にも、「認証失敗」を返すように選ぶかもしれません。
Several fields are encrypted and integrity-protected. They are denoted Prot(...). Their general structure is as follows:
いくつかのフィールドは暗号化され、整合性が保護されています。彼らはProtの（...）を付しています。次のように彼らの一般的な構造は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Random Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Protected Field Structure
図7：保護されたフィールド構造
The protected field is a concatenation of three octet strings:
保護されたフィールドは、3つのオクテット文字列を連結したものです：
o An optional IV, required when the encryption algorithm/mode necessitates it, e.g., for CBC encryption. The content and size of this field are determined by the selected encryption algorithm. In the case of CBC encryption, this field is a random octet string having the same size as the algorithm's block size.
暗号化アルゴリズム/モードは、CBC暗号化のために、例えば、それを必要とする場合、オプションのIV O、必要な。このフィールドの内容及びサイズは、選択された暗号化アルゴリズムによって決定されます。 CBC暗号化の場合、このフィールドは、アルゴリズムのブロックサイズと同じサイズを有するランダムオクテット文字列です。
o The original data, followed if necessary by random padding. This padding has the minimal length (possibly zero) required to complete the length of the encrypted data to the encryption algorithm's block size. The original data and the padding are encrypted together.
必要に応じて、元のデータO、ランダムパディング続きます。このパディングは、暗号化アルゴリズムのブロックサイズに暗号化されたデータの長さを完了するために必要な最低限の長さ（多分ゼロ）を持っています。元のデータとパディングが一緒に暗号化されます。
o ICV, a Message Authentication Code (MAC) cryptographic checksum of the encrypted data, including the padding. The checksum is computed over the encrypted, rather than the plaintext, data. Its length is determined by the MAC algorithm negotiated.
O ICV、メッセージ認証コード（MAC）パディングを含む暗号化されたデータの暗号チェックサム。チェックサムは、データではなく平文よりも、暗号化された上で計算されます。その長さは、交渉されたMACアルゴリズムによって決定されます。
We note that because of the requirement for an explicit ICV, this specification does not support authenticated encryption algorithms. Such algorithms may be added by a future extension.
当社は、理由の明示的ICVの要件のため、この仕様は、認証済みの暗号化アルゴリズムをサポートしていないことに注意してください。そのようなアルゴリズムは、将来の拡張によって追加することができます。
Two fields are encrypted but are not integrity protected. They are denoted Encr(...). Their format is identical to a protected field (Section 4.3), except that the Integrity Check Value is omitted.
2つのフィールドは、暗号化されているが、完全性保護されていません。彼らはENCR（...）を付しています。その形式は、整合性チェック値が省略されていることを除いて、保護されたフィールド（4.3節）と同じです。
This protocol allows higher-level protocols to transmit limited opaque information between the peer and the server. This information is integrity protected but not encrypted, and may be used to ensure that protocol participants are identical at different protocol layers. See Section 7.15 of [RFC3748] for more information on the rationale behind this facility.
このプロトコルは、上位レベルのプロトコルは、ピアとサーバとの間の限られた不透明な情報を送信することを可能にします。この情報は、完全性保護が暗号化されていないで、プロトコル参加者が異なるプロトコル層で同一であることを確実にするために使用することができます。この施設の理論的根拠の詳細については、[RFC3748]のセクション7.15を参照してください。
EAP-EKE neither validates nor makes any use of the transmitted information. The information MUST NOT be used by the consumer protocol until it is verified in the EAP-EKE-Confirm exchange (specifically, until it is integrity protected by the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied upon in case an error occurs at the EAP-EKE level.
EAP-EKEは、どちらも検証もなく、送信される情報のいずれかを利用します。 （それはAuth_S、Auth_Pペイロードによって保護完全性になるまで、具体的には）それはEAP-EKE - 確認交換で確認されるまで、情報は、消費者のプロトコルで使用してはいけません。これにより、エラーがEAP-EKEレベルで発生した場合に依拠してはいけません。
An unknown Channel Binding Value SHOULD be ignored by the recipient.
未知のチャンネル値バインディングは、受信者によって無視されるべきです。
Some implementations may require certain values to be present, and will abort the protocol if they are not. Such policy is out of scope of the current protocol.
いくつかの実装は、存在する特定の値を必要とするかもしれないし、そうでない場合にプロトコルを中止します。そのようなポリシーは、現在のプロトコルの範囲外です。
Each Channel Binding Value is encoded using a TLV structure:
各チャネルバインディング値がTLV構造を使用してエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Channel Binding Value
図8：チャネルバインディング値
CBType:
CBType：
This is the Channel Binding Value's type. This document defines the value 0x0000 as reserved. Other values are available for IANA allocation, see Section 7.6.
これは、チャンネルの値バインディングの型です。予約この文書は、値0000を定義します。他の値は、7.6節を参照して、IANAの割り当てのために用意されています。
Length:
長さ：
This field is the total length in octets of the structure, including the CBType and Length fields.
このフィールドはCBTypeと長さフィールドを含む構造のオクテットで全長です。
This facility should be used with care, since EAP-EKE does not provide for message fragmentation. EAP-EKE is not a tunneled method and should not be used as a generic transport; specifically, implementors should refrain from using the Channel Binding facility to transmit posture information, in the sense of [RFC5209].
EAP-EKEは、メッセージの断片化のために提供していないため、この施設では、注意して使用する必要があります。 EAP-EKEは、トンネル方式ではなく、一般的なトランスポートとして使用すべきではありません。具体的には、実装は、[RFC5209]の意味では、姿勢情報を送信するチャネルバインディング設備の使用を控えるべきです。
This section describes the sequence of messages for the Commit and Confirm exchanges, and lists the cryptographic operations performed by the server and the peer.
このセクションでは、コミットと確認交換のメッセージの順序を記述し、サーバおよびピアによって実行される暗号化操作を示しています。
The server computes:
サーバが計算します。
y_s = g ^ x_s (mod p),
Y_S = G ^ x_s（MOD P）、
where x_s is a randomly chosen number in the range 2 .. p-1. The randomly chosen number is the ephemeral private key, and the calculated value is the corresponding ephemeral public key. The server and the peer MUST both use a fresh, random value for x_s and the corresponding x_p on each run of the protocol.
範囲2 .. P-1でランダムに選択された数場所x_sあります。ランダムに選択された数は、エフェメラルプライベートキーであり、算出された値は、対応するはかない公開鍵です。サーバとピアの両方x_sおよびプロトコルの各実行に対応x_p新鮮な、ランダムな値を使用しなければなりません。
The server computes and transmits the encrypted field (Section 4.4)
サーバは、暗号化されたフィールド（セクション4.4）を計算し、送信します
temp = prf(0+, password)
TEMP = PRF（0+、パスワード）
key = prf+(temp, ID_S | ID_P)
キー= PRF +（温度、ID_S | ID_P）
DHComponent_S = Encr(key, y_s).
DHComponent_S = ENCR（キー、Y_S）。
See Section 6.1 for the prf+ notation. The first argument to "prf" is a string of zero octets whose length is the output size of the base hash algorithm, e.g., 20 octets for HMAC-SHA1; the result is of the same length. The first output octets of prf+ are used as the encryption key for the negotiated encryption algorithm, according to that algorithm's key length.
PRF +の表記については、セクション6.1を参照してください。 「PRF」の最初の引数は、長さベースハッシュアルゴリズムの出力サイズ、HMAC-SHA1のために、例えば、20オクテットであるゼロオクテットストリングです。結果は同じ長さです。 PRFの+の最初の出力オクテットは、そのアルゴリズムのキーの長さに応じて、交渉された暗号化アルゴリズムのための暗号化キーとして使用されています。
Since the PRF function is required to be an application of the HMAC operator to a hash function, the above construction implements HKDF as defined in [RFC5869].
PRF関数がハッシュ関数にHMAC演算子のアプリケーションであることが要求されるので、[RFC5869]で定義されるように、上記構成はHKDFを実装します。
When using block ciphers, it may be necessary to pad y_s on the right, to fit the encryption algorithm's block size. In such cases, random padding MUST be used, and this randomness is critical to the security of the protocol. Randomness recommendations can be found in [RFC4086]; also see [NIST.800-90.2007] for additional recommendations on cryptographic-level randomness. When decrypting this field, the real length of y_s is determined according to the negotiated Diffie-Hellman group.
ブロック暗号を使用する場合は、暗号化アルゴリズムのブロックサイズに合わせて、右のパッドY_Sに必要になることがあります。このような場合には、ランダムなパディングを使用しなければなりませんし、このランダム性は、プロトコルのセキュリティにとって非常に重要です。ランダム推奨は[RFC4086]に見出すことができます。また、暗号化レベルのランダム性に関する追加の推奨事項については、[NIST.800-90.2007]を参照してください。このフィールドを復号する際、Y_Sの実際の長さは、ネゴシエートされたDiffie-Hellmanグループに応じて決定されます。
If the password needs to be stored on the server, it is RECOMMENDED to store a randomized password value as a password-equivalent, rather than the cleartext password. We note that implementations may choose the output of either of the two steps of the password derivation. Using the output of the second step, where the password is salted by the identity values, is more secure; however, it may create an operational issue if identities are likely to change. See also Section 8.5.
パスワードがサーバー上に格納する必要がある場合は、パスワードと同等ではなく、平文パスワードとしてランダム化されたパスワード値を格納することをお勧めします。私たちは、実装がパスワード導出の2つの段階のいずれかの出力を選択するかもしれないことに注意します。パスワードが同一値で塩漬けされた第二ステップの出力を使用して、より安全です。アイデンティティが変更される可能性がある場合しかし、それは運用の問題を作成することがあります。また、セクション8.5を参照してください。
This protocol supports internationalized, non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output is the binary representation of the processed UTF-8 [RFC3629] character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHOULD cause a preprocessing failure and the output SHOULD NOT be used.
このプロトコルは、国際化、非ASCIIのパスワードをサポートしています。入力されたパスワード文字列は、[RFC3454]の[RFC4013]プロフィールの規則に従って処理されるべきです。パスワードは、[RFC3454]あたりの「保存された文字列」とみなされるべきであり、未割り当てコードポイントは、したがって、禁止されています。出力は、処理UTF-8 [RFC3629]の文字列のバイナリ表現です。 SASLprep前処理で遭遇出力禁止と未割り当てコードポイントは、前処理の失敗の原因とすべきであり、出力は使うべきではありません。
The peer computes:
ピアが計算されます。
y_p = g ^ x_p (mod p)
y_p = G ^ x_p（MOD P）
Then computes:
そして、計算します。
temp = prf(0+, password)
TEMP = PRF（0+、パスワード）
key = prf+(temp, ID_S | ID_P)
キー= PRF +（温度、ID_S | ID_P）
DHComponent_P = Encr(key, y_p)
DHComponent_P = ENCR（キー、y_p）
formatted as an encrypted field (Section 4.4).
暗号化されたフィールドとしてフォーマット（4.4節）。
Both sides calculate
双方は、計算します
SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))
しsharedsecret = PRF（0+、G ^（x_s * x_p）（MOD P））
The first argument to "prf" is a string of zero octets whose length is the output size of the base hash algorithm, e.g., 20 octets for HMAC-SHA1; the result is of the same length. This extra application of the pseudo-random function is the "extraction step" of [RFC5869]. Note that the peer needs to compute the SharedSecret value before sending out its response.
「PRF」の最初の引数は、長さベースハッシュアルゴリズムの出力サイズ、HMAC-SHA1のために、例えば、20オクテットであるゼロオクテットストリングです。結果は同じ長さです。擬似ランダム関数のこの余分なアプリケーションは、[RFC5869]の「抽出工程」です。ピアが応答を送信する前にしsharedsecret値を計算する必要があることに注意してください。
The encryption and integrity protection keys are computed:
暗号化と整合性の保護キーが計算されます。
Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)
柯| KI = PRF +（しsharedsecret、 "EAP-EKEキー" | ID_S | ID_P）
And the peer generates the Protected Nonce:
そして、ピアが保護されたnonceを生成します。
PNonce_P = Prot(Ke, Ki, Nonce_P),
Panonke_p =ダルマ（、Nonse_p）
where Nonce_P is a randomly generated binary string. The length of Nonce_P MUST be the maximum of 16 octets, and half the key size of the negotiated prf (rounded up to the next octet if necessary). The peer constructs this value as a protected field (Section 4.3), encrypted using Ke and integrity protected using Ki with the negotiated encryption and MAC algorithm.
Nonce_Pは、ランダムに生成されたバイナリ文字列です。 Nonce_Pの長さは16オクテットの最大値、および（必要に応じて次のオクテットに切り上げ）交渉されたprfの半分のキーサイズでなければなりません。ピアが保護されたフィールド（4.3節）として、この値を構築し、柯を使用して暗号化と整合性交渉し、暗号化とMACアルゴリズムでのKiを使用して保護。
The peer now sends a message that contains the two generated fields.
ピアは今、生成された2つのフィールドを含むメッセージを送信します。
The server MUST verify the correct integrity protection of the received nonce, and MUST abort the protocol if it is incorrect, with an "Authentication Failure" code.
サーバは、受信したナンスの正しい完全性保護を確かめなければなりませんし、それが正しくない場合は、「認証失敗」のコードで、プロトコルを中止しなければなりません。
The server constructs:
サーバが構築します。
PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S),
PNonce_PS = Protの（柯、KI、Nonce_P | NONCE_S）
as a protected field, where Nonce_S is a randomly generated string, of the same size as Nonce_P.
NONCE_SがNonce_Pと同じサイズのランダムに生成された文字列であり、保護フィールド、など。
It computes:
これは、計算します。
Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | Nonce_S)
カー= PRF +（しsharedsecret、 "EAP-EKEカー" | ID_S | ID_P | Nonce_P | NONCE_S）
whose length is the preferred key length of the negotiated prf (see Section 5.2). It then constructs:
長さが交渉されたprfの好適な鍵長である（5.2節を参照）。その後、構築します。
Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE-ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response).
Auth_S = PRF（KA、 "EAP-EKEサーバー" | EAP-EKE-ID /リクエスト| EAP-EKE-ID /レスポンス| EAP-EKE-コミット/リクエスト| EAP-EKE-コミット/応答）。
The messages are included in full, starting with the EAP header, and including any possible future extensions.
メッセージはEAPヘッダーで開始し、任意の可能な将来の拡張を含めて、完全に含まれています。
This construction of the Auth_S (and Auth_P) value implies that any future extensions MUST NOT be added to the EAP-EKE-Confirm/Request or EAP-EKE-Confirm/Response messages themselves, unless these extensions are integrity-protected in some other manner.
Auth_S（およびAuth_P）のこの構造値は、これらの拡張機能は、他の方法で整合性が保護されていない限り、将来の拡張には、EAP-EKE-確認/要求またはEAP-EKE-確認/応答メッセージ自体に追加してはならないことを意味します。
The server now sends a message that contains the two fields.
サーバーは現在、2つのフィールドが含まれているメッセージを送信します。
The peer MUST verify the correct integrity protection of the received nonces and the correctness of the Auth_S value, and MUST abort the protocol if either is incorrect, with an "Authentication Failure" code.
ピアは、受信した一回だけの正しい完全性保護及びAuth_S値の正しさを検証しなければならない、とのいずれかが「認証失敗」のコードと、正しくない場合、プロトコルを中止しなければなりません。
The peer computes Ka, and generates:
ピアがkaを計算し、生成されます。
PNonce_S = Prot(Ke, Ki, Nonce_S)
Panonke_s =ダルマ（、Nonse_s）
as a protected field. It then computes:
保護されたフィールドとして。その後、計算します。
Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response)
Auth_P = PRF（KA、 "EAP-EKEピア" | EAP-EKE-ID /リクエスト| EAP-EKE-ID /レスポンス| EAP-EKE-コミット/リクエスト| EAP-EKE-コミット/レスポンス）
The peer sends a message that contains the two fields.
ピアは、2つのフィールドが含まれているメッセージを送信します。
The server MUST verify the correct integrity protection of the received nonce and the correctness of the Auth_P value, and MUST abort the protocol if either is incorrect, with an "Authentication Failure" code.
サーバは、受信したナンスの正しい完全性保護とAuth_P値の正しさを確かめなければなりませんし、どちらかが「認証失敗」のコードで、間違っている場合は、プロトコルを中止しなければなりません。
Following the last message of the protocol, both sides compute and export the shared keys, each 64 bytes in length:
プロトコルの最後のメッセージの後、双方が計算およびエクスポート共有鍵を、それぞれ長さ64バイト。
MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S | ID_P | Nonce_P | Nonce_S)
MSK | EMSK = PRF +（しsharedsecret、 "EAP-EKEエクスポートキー" | ID_S | ID_P | Nonce_P | NONCE_S）
When the RADIUS attributes specified in [RFC2548] are used to transport keying material, then the first 32 bytes of the MSK correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material (the MSK) are used.
[RFC2548]で指定されたRADIUS属性が材料を合わせる輸送するために使用される場合、次いで、MSKの最初の32のバイトは、MS-MPPE-RECV-KEYおよびMS-MPPE-SEND-KEYの第32バイトに対応します。この場合、鍵材料（MSK）のわずか64バイトが使用されます。
At this point, both protocol participants MUST discard all intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, Ki, Ka, and SharedSecret. Similarly, both parties MUST immediately discard these values whenever the protocol terminates with a failure code or as a result of timeout.
この時点で、両方のプロトコルの参加者はx_p、x_s、y_p、Y_S、Keを、KI、カ、およびしsharedsecretを含むすべての中間暗号値を、捨てなければなりません。プロトコルは、エラーコードまたはタイムアウトの結果として終了するたびに同様に、両当事者は、直ちに、これらの値を破棄しなければなりません。
Keying material is derived as the output of the negotiated pseudo-random function (prf) algorithm. Since the amount of keying material needed may be greater than the size of the output of the prf algorithm, we will use the prf iteratively. We denote by "prf+" the function that outputs a pseudo-random stream based on the inputs to a prf as follows (where "|" indicates concatenation):
キーイング材料をネゴシエート擬似ランダム関数（PRF）アルゴリズムの出力として導出されます。必要な材料をキーイングの量はPRFアルゴリズムの出力のサイズよりも大きくすることができるので、私たちは繰り返しPRFを使用します。 ：|（「」連結を示す）、我々は次のようにPRFへの入力に基づいて擬似ランダムストリームを出力する関数「PRF +」で表します
prf+ (K, S) = T1 | T2 | T3 | T4 | ...
+ PRF（K、C）= T1 | T2 | TK | PM | ...
where:
どこ：
T1 = prf(K, S | 0x01)
T1 = PRF（K、S | 0x01の）
T2 = prf(K, T1 | S | 0x02)
T2 = PRF（K、T1 | S | 0x02の）
T3 = prf(K, T2 | S | 0x03)
T3 = PRF（K、T2 | S | 0x03の）
T4 = prf(K, T3 | S | 0x04)
T4 = PRF（K、T3 | S | 0x04を）
continuing as needed to compute all required keys. The keys are taken from the output string without regard to boundaries (e.g., if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key will come from T1 and the beginning of T2, while the HMAC key will come from the rest of T2 and the beginning of T3).
すべての必要なキーを計算するために、必要に応じて継続。必要なキーは、256ビットのAdvanced Encryption Standard（AES）の鍵と160ビットのHMACキーであり、PRF関数は160ビットAES鍵を生成する場合にキーが境界（例えば、に関係なく、出力文字列から取得されHMACキーはT2の残りとT3の始まりから来るながら）、T1とT2の先頭から来ます。
The constant concatenated to the end of each string feeding the prf is a single octet. In this document, prf+ is not defined beyond 255 times the size of the prf output.
PRFを供給する各文字列の末尾に連結定数は単一オクテットです。この文書では、PRF +はPRF出力の255倍の大きさを超えて定義されていません。
Many of the commonly used Diffie-Hellman groups are inappropriate for use in EKE. Most of these groups use a generator that is not a primitive element of the group. As a result, an attacker running a dictionary attack would be able to learn at least 1 bit of information for each decrypted password guess.
一般的に使用されるのDiffie-Hellmanグループの多くは、EKEでの使用のために不適切です。これらのグループのほとんどは、グループの原始要素ではない発電機を使用しています。その結果、辞書攻撃を実行する攻撃者は、各復号化されたパスワードの推測のための情報の少なくとも1ビットを学ぶことができるでしょう。
Any MODP Diffie-Hellman group defined for use in this protocol MUST have the following properties to ensure that it does not leak a usable amount of information about the password:
このプロトコルで使用するために定義された任意のMODPのDiffie-Hellmanグループは、パスワードに関する情報の使用可能量が漏れないことを確実にするために、以下の特性を有しなければなりません。
3. The group's order p is a "safe prime", i.e., (p-1)/2 is also prime.
3.グループの次数pは、「安全な素数」、即ち、（P-1）/ 2も素数です。
The last requirement is related to the strength of the Diffie-Hellman algorithm, rather than the password encryption. It also makes it easy to verify that the generator is primitive.
最後の要件は、のDiffie-Hellmanアルゴリズムの強さではなく、パスワードの暗号化に関連しています。また、発電機が原始的であることを確認することが容易になります。
Suitable groups are defined in Section 7.1.
適切な基は、セクション7.1で定義されています。
To facilitate interoperability, the following algorithms are mandatory to implement:
相互運用性を容易にするために、次のアルゴリズムは実装が必須です。
o ENCR_AES128_CBC (encryption algorithm)
O ENCR_AES128_CBC（暗号化アルゴリズム）
o PRF_HMAC_SHA1 (pseudo-random function)
O PRF_HMAC_SHA1（擬似ランダム関数）
o MAC_HMAC_SHA1 (keyed message digest)
O MAC_HMAC_SHA1（キー付きメッセージダイジェスト）
o DHGROUP_EKE_14 (DH-group)
O DHGROUP_EKE_14（DHグループ）
IANA has allocated the EAP method type 53 from the range 1-191, for "EAP-EKE Version 1".
IANAは、「EAP-EKEバージョン1」を、範囲1-191からEAPメソッドタイプ53を割り当てました。
Per this document, IANA created the registries described in the following sub-sections. Values (other than private-use ones) can be added to these registries per Specification Required [RFC5226], with two exceptions: the Exchange and Failure Code registries can only be extended per RFC Required [RFC5226].
このドキュメントごとに、IANAは以下のサブセクションで説明するレジストリを作成しました。 Exchangeおよび故障コードのレジストリのみRFC必須[RFC5226]あたりに拡張することができます。（私的利用以外の）値は、2つの例外を除いて、仕様が必要である[RFC5226]あたりのこれらのレジストリに追加することができます。
This section defines an IANA registry for Diffie-Hellman groups.
この節では、Diffie-HellmanグループのためのIANAレジストリを定義します。
This table defines the initial contents of this registry. The Value column is used when negotiating the group. Additional groups may be defined through IANA allocation. Any future specification that defines a non-MODP group MUST specify its use within EAP-EKE and MUST demonstrate the group's security in this context.
この表は、このレジストリの初期内容を定義します。グループをネゴシエートするときValueカラムが使用されます。追加のグループは、IANAの割り当てによって定義することができます。非MODPグループを定義し、将来の仕様では、EAP-EKE内での使用を指定しなければならないし、この文脈でグループのセキュリティを示さなければなりません。
+-----------------+---------+---------------------------------------+
| Name | Value | Description |
+-----------------+---------+---------------------------------------+
| Reserved | 0 | |
| DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit |
| | | Group 2 [RFC5996], with the generator |
| | | 5 (decimal) |
| DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit |
| | | Group 5 [RFC3526], g=31 |
| DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit |
| | | Group 14 [RFC3526], g=11 |
| DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit |
| | | Group 15 [RFC3526], g=5 |
| DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit |
| | | Group 16 [RFC3526], g=5 |
| Available for | 6-127 | |
| allocation via | | |
| IANA | | |
| Reserved for | 128-255 | |
| Private Use | | |
+-----------------+---------+---------------------------------------+
This section defines an IANA registry for encryption algorithms:
このセクションでは、暗号化アルゴリズムのためのIANAレジストリを定義します。
+-----------------+---------+-----------------------------------+
| Name | Value | Definition |
+-----------------+---------+-----------------------------------+
| Reserved | 0 | |
| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |
| | 2-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------------+---------+-----------------------------------+
This section defines an IANA registry for pseudo-random function algorithms:
このセクションでは、擬似ランダム関数アルゴリズムのためのIANAレジストリを定義します。
+-------------------+---------+-------------------------------------+
| Name | Value | Definition |
+-------------------+---------+-------------------------------------+
| Reserved | 0 | |
| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
| PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] |
| | 3-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-------------------+---------+-------------------------------------+
A pseudo-random function takes two parameters K and S (the key and input string respectively), and, to be usable in this protocol, must be defined for all lengths of K between 0 and 65,535 bits (inclusive).
擬似ランダム関数は、2つのパラメータK及びS（キーとそれぞれ入力文字列）を取り、そして、このプロトコルで使用できるように、0から65,535ビット（を含む）の間のKの全ての長さのために定義されなければなりません。
Any future pseudo-random function MUST be based on the HMAC construct, since the security of HKDF is only known for such functions.
HKDFのセキュリティのみこのような機能のために知られているので、将来の擬似ランダム関数は、HMAC構築物に基づいていなければなりません。
This section defines an IANA registry for keyed message digest algorithms:
このセクションでは、鍵付きメッセージダイジェストアルゴリズムのためのIANAレジストリを定義します。
+-------------------+---------+--------------+----------------------+
| Name | Value | Key Length | Definition |
| | | (Octets) | |
+-------------------+---------+--------------+----------------------+
| Reserved | 0 | | |
| MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as |
| | | | defined in [RFC2104] |
| MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 |
| Reserved | 3-127 | | Available for |
| | | | allocation via IANA |
| Reserved | 128-255 | | Reserved for Private |
| | | | Use |
+-------------------+---------+--------------+----------------------+
This section defines an IANA registry for identity types:
このセクションでは、アイデンティティのタイプのためのIANAレジストリを定義します。
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
| ID_NAI | 2 | A Network Access Identifier, as defined in |
| | | [RFC4282] |
| ID_IPv4 | 3 | An IPv4 address, in binary format |
| ID_IPv6 | 4 | An IPv6 address, in binary format |
| ID_FQDN | 5 | A fully qualified domain name, see note |
| | | below |
| ID_DN | 6 | An LDAP Distinguished Name formatted as a |
| | | string, as defined in [RFC4514] |
| | 7-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------+---------+---------------------------------------------+
An example of an ID_FQDN is "example.com". The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an internationalized domain name, the syntax is as defined in [RFC5891], for example "xn--tmonesimerkki-bfbb.example.net".
ID_FQDNの例は、「example.com」です。文字列は、任意のターミネーター（例えば、NULL、CRなど）を含んでいてはなりません。 ID_FQDNのすべての文字はASCIIです。 「xn--tmonesimerkki-bfbb.example.net」は、例えば、[RFC5891]で定義されるように国際化ドメイン名のために、シンタックスです。
This section defines an IANA registry for the Channel Binding Type registry, a 16-bit long code. The value 0x0000 has been defined as Reserved. All other values up to and including 0xfeff are available for allocation via IANA. The remaining values up to and including 0xffff are available for Private Use.
このセクションでは、チャネルバインディングタイプレジストリ、16ビット長のコードのIANAレジストリを定義します。値0000は予約済みとして定義されています。 0xfeffまでを含む他のすべての値は、IANA経由で割り当てのために用意されています。 0xffffのまでを含む残りの値は、プライベート使用のために用意されています。
This section defines an IANA registry for the EAP-EKE Exchange registry, an 8-bit long code. Initial values are defined in Section 4.1. All values up to and including 0x7f are available for allocation via IANA. The remaining values up to and including 0xff are available for private use.
このセクションでは、EAP-EKE交換レジストリ、8ビット長のコードのためのIANAレジストリを定義します。初期値は、4.1節で定義されています。 0x7fまでを含むすべての値は、IANA経由で割り当てのために用意されています。 0xffのまでを含む残りの値は、私的使用のために用意されています。
This section defines an IANA registry for the Failure-Code registry, a 32-bit long code. Initial values are defined in Section 4.2.4. All values up to and including 0xfeffffff are available for allocation via IANA. The remaining values up to and including 0xffffffff are available for private use.
このセクションでは、故障コードレジストリのためのIANAレジストリ、32ビット長のコードを定義します。初期値は、4.2.4項で定義されています。 0xfeffffffまでを含むすべての値は、IANA経由で割り当てのために用意されています。 0xffffffffにまでを含む残りの値は、私的使用のために用意されています。
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 paragraphs.
パスワード認証鍵交換の問題を解決するために主張して任意のプロトコルは、アクティブ、パッシブ、および辞書攻撃に耐性があると前進の秘密保持の品質を持っている必要があります。これらの特性は、以下の段落でさらに議論されています。
Resistance to Passive Attack: A passive 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.
受動攻撃に対する耐性：受動的攻撃者は単に、忠実に、そして変更することなく、前後のピアとサーバー間のメッセージを中継一つです。メッセージの内容は、検査のために利用可能であるが、それがすべてです。受動的攻撃に対する耐性を達成するために、そのような攻撃者は、プロトコルの繰り返しの実行を見てから生じる共有秘密についてのパスワードか何かについての情報を得ることができない必要があります。受動的攻撃者がパスワードを知ることができる場合でも、彼女は、ピアとサーバで共有した秘密に関する情報を決定することができません。
Resistance to Active Attack: 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.
積極的な攻撃への抵抗：アクティブ攻撃者は、変更、追加、削除、およびプロトコルの参加者の間で送信されるメッセージを再生することができます。このプロトコルは、アクティブな攻撃に耐性であるためには、攻撃者は、その機能のいずれかを使用して、パスワードまたは共有秘密に関する情報を入手することはできません必要があります。また、攻撃者は、プロトコルが正常に完了したことを考えることにプロトコルの参加者をだますことはできません必要があります。活発な攻撃者が交換を完了する上で重要なメッセージの配信を拒否することは常に可能です。これは、すべてのメッセージをドロップするよりも違いはありません、プロトコルに対する攻撃ではありません。
Resistance to Dictionary Attack: 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.
辞書攻撃に対する耐性：このプロトコルでは、辞書攻撃に対して耐性であることが、敵対者が得ることができます任意の利点は、直接、彼女は正直なプロトコルの参加者ではなく計算により行い相互作用の数に関連していなければなりません。敵は単一のプロトコルの実行から単一の推測が正しいか間違っているかどうかを除いて、パスワードに関する情報を入手することができません。
Forward Secrecy: Compromise of the password must not provide any information about the secrets generated by earlier runs of the protocol.
転送秘密：パスワードの妥協は、プロトコルの以前の実行によって生成された秘密についての情報を提供してはなりません。
[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]義務とで使用するためにこれらのいくつかをお勧めします。主張は以下のとおりです。
* Mutual authentication: the peer and server both authenticate
each other by proving possession of a shared password. This
is REQUIRED by [RFC4017].
* Forward secrecy: compromise of the password does not reveal the secret keys (MSK and EMSK) from earlier runs of the protocol.
*転送秘密：パスワードの妥協は、プロトコルの以前の実行から秘密鍵（MSKとEMSK）を明らかにしていません。
* Replay protection: an attacker is unable to replay messages from a previous exchange either to 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.
*リプレイ保護：攻撃者がパスワードまたは交換によって派生鍵を学ぶためにどちらかの以前の交換機からメッセージを再生することができません。同様に、攻撃者はそれがなかった場合に交換が正常に完了したと信じてピアまたはサーバのいずれかを誘導することができません。
* Key derivation: a shared secret is 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: an attacker can only make one password guess per active attack, and the protocol is designed so that the attacker does not gain any confirmation of her guess by observing the decrypted y_s or y_p value (see below). The advantage she can gain is through interaction not through computation. This is REQUIRED by [RFC4017].
*辞書攻撃性：攻撃者が唯一のアクティブな攻撃ごとに1つのパスワードの推測を行うことができ、攻撃者が解読さY_Sまたはy_p値（下記参照）を観察することによって、彼女の推測のいずれかの確認を得ないように、プロトコルが設計されています。彼女が得ることができるという利点が相互作用を介していない計算を介して行われます。これは、[RFC4017]によって必要とされます。
* Session independence: this protocol is resistant to active and passive attacks and does not enable compromise of subsequent or prior MSKs or EMSKs from either passive or active attacks.
*セッションの独立性：このプロトコルは、アクティブとパッシブの攻撃に耐性があり、受動的または能動的のいずれかの攻撃からの後続または事前たMSKまたはEMSKsの妥協を有効にしません。
* Denial-of-service resistance: it is possible for an attacker to cause a server to allocate state and consume CPU. 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-EKE-ID/Request.
*サービス拒否抵抗：攻撃者が状態を割り当て、CPUを消費するサーバーを引き起こすことが可能です。そのような攻撃は、攻撃者は第一下位層プロトコルを介して接続を得る要件によって、しかし、ゲートされる（例えば、802.11認証は、802.11アソシエーション、または802.3「リンクアップ」に続く）と2つのEAPメッセージに応答：EAP -ID /リクエストとEAP-EKE-ID /要求。
* Man-in-the-Middle Attack resistance: this exchange is resistant to active attack, which is a requirement for launching a man-in-the-middle attack. This is REQUIRED by [RFC4017].
* man-in-the-middle攻撃性：この交換は、man-in-the-middle攻撃を起動するための必要条件であるアクティブな攻撃に耐性です。これは、[RFC4017]によって必要とされます。
* Shared state equivalence: upon completion of EAP-EKE, the peer and server both agree on the MSK and EMSK values. 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 generated shared secret are all combined to make the authentication element that must be shared between the peer and server for the exchange to complete. This is REQUIRED by [RFC4017].
*状態の等価性を共有：EAP-EKE、両方がMSKとEMSKの値に同意ピアとサーバの完了時に。ピアはSERVER_IDに基づいてサーバを認証したとサーバがPeer_IDに基づいてピアを認証しています。これはPeer_ID、SERVER_ID、および生成された共有秘密がすべて完了するの交換のために、ピアとサーバの間で共有されなければならない認証要素を作るために結合されているという事実によるものです。これは、[RFC4017]によって必要とされます。
* Fragmentation: this protocol does not define a technique for fragmentation and reassembly.
*断片化：このプロトコルは、断片化と再構築のための技術を定義していません。
* Resistance to "Denning-Sacco" attack: learning keys distributed from an earlier run of the protocol, such as the MSK or EMSK, will not help an adversary learn the password.
*レジスタンス「デニング・サッコ」攻撃へ：このようMSKかEMSKなどのプロトコルの以前の実行から配布学習キー、敵がパスワードを学ぶ助けにはなりません。
3. Key strength: the strength of the resulting key depends on the finite cyclic group chosen. Sufficient key strength is REQUIRED by [RFC4017]. Clearly, "sufficient" strength varies over time, depending on computation power assumed to be available to potential attackers.
3.キー強度：結果のキーの強さは、選択された有限巡回群に依存します。十分なキー強度は、[RFC4017]によって必要とされます。明らかに、「十分な」強度は、潜在的な攻撃者に利用可能であると仮定計算能力に応じて、時間とともに変化します。
4. Key hierarchy: MSKs and EMSKs are derived from the secret values generated during the protocol run, using a negotiated pseudo-random function.
4.キー階層：たMSKとEMSKsを交渉し、擬似ランダム関数を使用して、プロトコルの実行中に生成された秘密値から導出されています。
5. Vulnerabilities (note that none of these are REQUIRED by [RFC4017]):
5.脆弱性（これらのいずれも[RFC4017]によって必要とされないことに注意してください）。
* Protected ciphersuite negotiation: the ciphersuite proposal
made by the server is not protected from tampering by an
active attacker. However, if a proposal was modified by an
active attacker, it would result in a failure to confirm the
message sent by the other party, since the proposal is bound
by each side into its Confirm message, and the protocol would
fail as a result. Note that this assumes that none of the
proposed ciphersuites enables an attacker to perform real-time
cryptanalysis.
* Confidentiality: none of the messages sent in this protocol are encrypted, though many of the protocol fields are.
*機密性：プロトコルフィールドの多くはあるものの、このプロトコルで送信されたメッセージのいずれも、暗号化されていません。
* Integrity protection: protocol messages are not directly integrity protected; however, the ID and Commit exchanges are integrity protected through the Auth payloads exchanged in the Confirm exchange.
*完全性保護：プロトコルメッセージは直接の完全性が保護されていません。しかし、IDと交流をコミットが確認交換で交換認証ペイロードを通じて保護の整合性です。
* Channel binding: this protocol enables 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-EKE-ID exchange is not protected. An attacker will see the server's identity in the EAP-EKE-ID/ Request and see the peer's identity in EAP-EKE-ID/Response. See also Section 8.4.
*アイデンティティの保護：EAP-EKE-IDの交換が保護されていません。攻撃者は、EAP-EKE-ID /リクエストにサーバの身元を確認し、EAP-EKE-ID /レスポンスでピアのアイデンティティが表示されます。また、8.4節を参照してください。
When analyzing the Commit exchange, it should be noted that the base security assumptions are different from "normal" cryptology. Normally, we assume that the key has strong security properties, and that the data may have few or none. Here, we assume that the key has weak security properties (the attacker may have a list of possible keys), and hence we need to ensure that the data has strong properties (indistinguishable from random). This difference may mean that conventional wisdom in cryptology might not apply in this case. This also imposes severe constraints on the protocol, e.g., the mandatory use of random padding and the need to define specific finite groups.
コミット交換を分析する際には、基本セキュリティ仮定は「通常」の暗号異なることに留意すべきです。通常、私たちは、キーは強力なセキュリティ特性を有していること、およびデータは、いくつかまたはnoneを持っていることを前提としています。ここでは、キーが弱いセキュリティプロパティを（攻撃者が可能なキーのリストを有していてもよい）があると仮定し、それゆえ我々は、データが（ランダムと区別できない）強い性質を持っていることを確認する必要があります。この違いは、暗号学における従来の知恵は、この場合には適用されない場合がありますことを意味します。また、これは、例えば、ランダムな詰め物と特定の有限群を定義する必要の必須使用をプロトコルに厳しい制約を課します。
It is fundamental to the dictionary attack resistance that the Diffie-Hellman public values y_s and y_p are indistinguishable from a random string. If this condition is not met, then a passive attacker can do trial-decryption of the encrypted DHComponent_P or DHComponent_S values based on a password guess, and if they decrypt to a value that is not a valid public value, they know that the password guess was incorrect.
それはのDiffie-Hellman公開値Y_Sとy_pはランダムな文字列と区別できないことを、辞書攻撃耐性の基本です。この条件が満たされない場合、受動的攻撃者は、パスワードの推測に基づいて暗号化されたDHComponent_PまたはDHComponent_S値のトライアル・復号化を行うことができ、それらは有効な公開値ではない値に復号化する場合、彼らはパスワードの推測があることを知っています間違っていました。
For MODP groups, Section 6.2 gives conditions on the group to make sure that this criterion is met. For other groups (for example, Elliptic Curve groups), some other means of ensuring this must be employed. The standard way of expressing Elliptic Curve public values does not meet this criterion, as a valid Elliptic Curve X coordinate can be distinguished from a random string with probability of approximately 0.5.
MODPグループの場合、6.2節では、この基準が満たされていることを確認するグループに条件を与えます。他の基（例えば、楕円曲線群）のために、これを保証する他の手段を使用しなければなりません。有効な楕円曲線X座標として、この基準を満たしていない楕円曲線公開値を表現する標準的な方法は、約0.5の確率でランダムな文字列と区別することができます。
A future document might introduce a group representation, and/or a slight modification of the password encryption scheme, so that Elliptic Curve groups can be accommodated. [BR02] presents several alternative solutions for this problem.
楕円曲線グループを収容することができるように、将来の文書は、群の表現、および/またはパスワードの暗号化方式のわずかな変更を導入することがあります。 [BR02]は、この問題について、いくつかの代替ソリューションを提供します。
An attacker, impersonating either the peer or the server, can always try to enumerate all possible passwords, for example by using a dictionary. To counter this likely attack vector, both peer and server MUST implement rate-limiting mechanisms. We note that locking out the other party after a small number of tries would create a trivial denial-of-service opportunity.
ピアまたはサーバを偽装攻撃者は、常に辞書を使用することにより、たとえば、すべての可能なパスワードを列挙しようとすることができます。この可能性の高い攻撃ベクトルに対抗するには、ピアとサーバの両方が律速メカニズムを実装しなければなりません。私たちは、試行の数が少ないの後に相手をロックアウトすることは些細なサービス拒否の機会を作成することに注意してください。
By default, the EAP-EKE-ID exchange is unprotected, and an eavesdropper can observe both parties' identities. A future extension of this protocol may support anonymity, e.g., by allowing the server to send a temporary identity to the peer at the end of the exchange, so that the peer can use that identity in subsequent exchanges.
デフォルトでは、EAP-EKE-ID交換が保護されていないで、盗聴者は、両当事者の身元を観察することができます。ピアは、後続の交換にそのIDを使用できるように、このプロトコルの将来の拡張は、サーバは、交換の終了時にピアに一時的な識別情報を送信することを可能にすることによって、例えば、匿名性をサポートすることができます。
EAP-EKE differs in this respect from tunneled methods, which typically provide unconditional identity protection to the peer by encrypting the identity exchange, but reveal information in the server certificate. It is possible to use EAP-EKE as the inner method in a tunneled EAP method in order to achieve this level of identity protection.
EAP-EKEは、一般的にアイデンティティ交換を暗号化することによって、ピアへの無条件アイデンティティ保護を提供しますが、サーバー証明書の情報を明らかにトンネル化する方法から、この点で異なります。アイデンティティこのレベルの保護を実現するために、トンネリングEAP方式で内部方式としてEAP-EKEを使用することが可能です。
This document recommends that a password-equivalent (a hash of the password) be stored instead of the cleartext password. While this solution provides a measure of security, there are also tradeoffs related to algorithm agility:
この文書は、パスワード相当（パスワードのハッシュ）が代わりに平文パスワードを格納することをお勧めします。このソリューションは、セキュリティの対策を提供していますが、俊敏性をアルゴリズムに関連するトレードオフもあります。
o Each stored password must identify the hash function that was used to compute the stored value.
O各保存されたパスワードが格納された値を計算するために使用されたハッシュ関数を識別する必要があります。
o Complex deployments and migration scenarios might necessitate multiple stored passwords, one per each algorithm.
O複雑な展開と移行シナリオは、各アルゴリズムごとに1つずつ、複数の保存されたパスワードが必要になるかもしれません。
o Changing the algorithm can require, in some cases, that the users manually change their passwords.
アルゴリズムを変更する必要になることがO、いくつかのケースでは、ユーザーが手動で自分のパスワードを変更すること。
The reader is referred to Section 10 of [RFC3629] for security considerations related to the parsing and processing of UTF-8 strings.
読者は、UTF-8文字列の解析および処理に関連するセキュリティ問題のために[RFC3629]のセクション10と呼ばれます。
Much of this document was unashamedly picked from [RFC5931] and [EAP-SRP], and we would like to acknowledge the authors of these documents: Dan Harkins, Glen Zorn, James Carlson, Bernard Aboba, and Henry Haverinen. We would like to thank David Jacobson, Steve Bellovin, Russ Housley, Brian Weis, Dan Harkins, and Alexey Melnikov for their useful comments. Lidar Herooty and Idan Ofrat implemented this protocol and helped us improve it by asking the right questions, and we would like to thank them both.
このドキュメントの多くは臆面もなく、[RFC5931]と[EAP-SRP]から選ばれた、と私たちはこれらの文書の作成者を確認したいと思います：ダンハーキンズ、グレン・ソーン、ジェームズ・カールソン、バーナードAboba、とヘンリーHaverinen。私たちは彼らの有益なコメントをデビッド・ジェイコブソン、スティーブBellovin氏、ラスHousley、ブライアン・ワイス、ダンハーキンズ、およびアレクセイメルニコフに感謝したいと思います。ライダーHerootyとIDAN Ofratは、このプロトコルを実装し、私たちは適切な質問を尋ねることによってそれを改善助けた、と我々は両方彼らに感謝したいと思います。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T.およびM.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"、RFC 4514、2006年6月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J.、 "アプリケーション（IDNA）で国際化ドメイン名：プロトコル"、RFC 5891、2010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
[SHA] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", NIST FIPS 180-3, October 2008.
標準技術[SHA]国立研究所、米国商務省が、NIST FIPS 180-3、2008年10月「ハッシュ標準セキュア」。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks", Proc. IEEE Symp. on Research in Security and Privacy , May 1992.
[BM92] Bellovin氏、S.とM.メリット、「暗号化鍵交換：辞書攻撃に対するセキュリティで保護されたパスワードベースのプロトコル」、PROC。 IEEE SYMP。 1992年5月、セキュリティの研究およびプライバシー上。
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise", Proc. 1st ACM Conference on Computer and Communication Security , 1993.
[BM93] Bellovin氏、S.とM.メリット、「増補暗号化鍵交換：辞書攻撃やパスワード・ファイルの侵害に対するセキュリティで保護されたパスワードベースのプロトコル」、PROC。コンピュータおよび通信セキュリティ、1993年第1回ACM会議。
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman", Advances in Cryptology, EUROCRYPT 2000 , 2000.
[BMP00] Boyko、V.、マッケンジー、P.、およびS.パテル、 "ディフィー・ヘルマンを使用して証明可能セキュリティで保護されたパスワード認証鍵交換" には、暗号学、EUROCRYPT 2000、2000年に進めます。
[BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite Domains", Proc. of the RSA Cryptographer's Track (RSA CT '02), LNCS 2271 , 2002.
【BR02】ブラック、J.およびP. Rogaway、PROC「任意有限ドメインと暗号」。 RSA暗号研究者のトラック（RSA CT '02）、LNCS 2271、2002。
[EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
[EAP-SRP]カールソン、J.、Aboba、B.、およびH. Haverinen、 "EAP SRP-SHA1認証プロトコル"、進歩、2001年7月ワーク。
[JAB96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM Computer Communications Review Volume 1, Issue 5, October 1996.
[JAB96] Jablon、D.、 "強力なパスワードのみによる認証鍵交換"、ACMコンピュータコミュニケーションレビュー第1巻、5号、1996年10月。
[LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys", Proc. of the Security Protocols Workshop LNCS 1361, 1997.
[LUC97] Lucks、S.、「開く鍵交換：どのように暗号公開鍵なしで辞書攻撃を倒す」、PROC。セキュリティプロトコルワークショップLNCS 1361、1997。
[NIST.800-90.2007] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)", NIST SP 800-90, March 2007.
[NIST.800-90.2007]米国国立標準技術研究所、NIST SP 800-90、2007年3月の「乱数生成は、決定論的ランダムビットジェネレータを使用するための推奨事項は、（改訂します）」。
[PA97] Patel, S., "Number Theoretic Attacks On Secure Password Schemes", Proceedings of the 1997 IEEE Symposium on Security and Privacy , 1997.
[PA97]パテル、S.、「セキュリティで保護されたパスワード方式に数論攻撃」、セキュリティとプライバシー、1997年に1997 IEEEシンポジウム。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209]サングスター、P.、Khosravi、H.、マニ、M.、ナラヤン、K.、およびJ. Tardo、 "ネットワークエンドポイントの評価（NEA）：概要および要件"、RFC 5209、2008年6月。
[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月。
[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月を。
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010.
[RFC5931]ハーキンとD.とG.ツォルン、 "唯一のパスワードを使用して拡張認証プロトコル（EAP）認証"、RFC 5931、2010年8月。
Authors' Addresses
著者のアドレス
Yaron Sheffer Independent
ヤロンシェファー独立
EMail: yaronf.ietf@gmail.com
メールアドレス：yaronf.ietf@gmail.com
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
グレンツォルンネットワーク禅358分の227タノンSanphawutバンナー、バンコク10260タイ
Phone: +66 (0) 87-040-4617 EMail: gwz@net-zen.net
電話：+66（0）87-040-4617 Eメール：gwz@net-zen.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at
Scott Fluhrer Cisco Systems. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
スコットFluhrerシスコシステムズ。 1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: sfluhrer@cisco.com
メールアドレス：sfluhrer@cisco.com