[要約] RFC 6124は、EKE(Encrypted Key Exchange)プロトコルに基づくEAP(Extensible Authentication Protocol)認証方法に関する文書です。この文書の目的は、パスワードベースの認証を提供することで、中間者攻撃に対して強固なセキュリティを確保するEAP認証メカニズムを定義することにあります。主に、無線LANやVPNなどのネットワークアクセス認証に利用されます。関連するRFCには、RFC 3748（EAPの概要）、RFC 5247（EAPのキーフレームワーク）、およびRFC 5448（EAPのパスワード認証プロトコル）などがあります。
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
暗号化されたキーエクスチェンジ（EKE）プロトコルに基づくEAP認証方法
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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とMerrittによって最初に記述されました。その後、[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（KE、...）を使用して暗号化された情報を示し、ProT（KE、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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サーバー（「Authenticator」とも呼ばれる）の間で話されている2パーティのプロトコルです。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 ID交換を使用してお互いのアイデンティティを学び、その後の交換で使用するために暗号化されたものに同意します。コミット交換では、ピアとサーバーが交換して共有キーを生成し、パスワードの特定の推測に互いに結合します。確認交換では、ピアとサーバーは、検証データを生成および検証することにより、パスワードの活性と知識を証明します（コミットエクスチェンジの2番目のメッセージは、このlivenivesの証明に不可欠な部分をすでに再生していることに注意してください）。
+--------+ +--------+
| | 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 Exchange
Schematically, the original exchange as described in [BM92] (and with the roles reversed) is:
概略的には、[BM92]（および役割が逆転している場合）に記載されている元の交換は次のとおりです。
Server Peer
------ ----
Encr(Password, y_s) ->
<- Encr(Password, y_p), Encr(SharedSecret, 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).
o Y_SとY_Pは、それぞれサーバーとピアの公開キー、つまり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.
o NonCE_S、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は、Diffie-Hellmanアルゴリズム、つまりSharedSecret = g^（x_s * x_p）（mod p）によって作成された秘密です。この値は、サーバーによって次のように計算されます：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/response <-id_p、cryptoselection
Commit/Request Encr(Password, y_s) ->
Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P)
Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S ->
Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P
確認/応答<-PROT（KE、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 KEは暗号化キーであり、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.
上記の交換に示されているように、以下の情報要素が元のプロトコルに追加されました：両方のプロトコルパーティ（ID_S、ID_P）のID値、暗号化プロトコルの交渉、および交渉されたパラメーターの完全性を保護する署名フィールド（AUTH_S、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ヘッダー（[RFC3748]のセクション4を参照）で構成されており、EAP-EKE Exchangeタイプが続きます。ヘッダーには次の構造があります。
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
図2：EAP-EKEヘッダー
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-Exch（EKE Exchange）フィールドは、データフィールドにカプセル化されたEAP-EKEペイロードのタイプを識別します。このドキュメントは、EKE-Exchフィールドの次の値を定義します。
o 0x00: Reserved
o 0x00：予約済み
o 0x01: EAP-EKE-ID exchange
o 0x01：EAP-EKE-ID Exchange
o 0x02: EAP-EKE-Commit exchange o 0x03: EAP-EKE-Confirm exchange
o 0x02：EAP-eke-commit Exchange o 0x03：EAP-eke-confirm Exchange
o 0x04: EAP-EKE-Failure message
o 0x04：EAP-eke-failureメッセージ
Further values of this EKE-Exch field are available via IANA registration (Section 7.7).
このEKE-Exchフィールドのさらなる値は、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/Responseメッセージでは、Numproposalsフィールドを1（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.
IDタイプを示します。これは、セクション7.5で定義されているIANAレジストリから取得されます。サーバーとピアは、異なるIDタイプを使用する場合があります。すべての実装は、ID_NAIとID_FQDNの2つのIDタイプを受信できる必要があります。
Identity:
身元：
The meaning of the Identity field depends on the values of the Code and IDType fields.
IDフィールドの意味は、コードフィールドとIDTypeフィールドの値に依存します。
* EAP-EKE-ID/Request: server ID
* EAP-EKE-ID/リクエスト：サーバーID
* EAP-EKE-ID/Response: peer ID
* EAP-EKE-ID/Response：ピアID
The length of the Identity field is computed from the Length field in the EAP header. Specifically, its length is
IDフィールドの長さは、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-Confirm Exchangeの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-commitペイロード
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を参照してください。各構造には独自の長さが含まれています。フィールドは暗号化されておらず、整合性の保護されていませんが、代わりに確認交換の認証ペイロードによって保護されています。
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-Confirmペイロード
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-FAILUREペイロード
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.
このフィールドの追加値は、IANA登録を介して利用できます。セクション7.8を参照してください。
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-Failureで応答する必要があります。サーバーは、Exchangeを終了するために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-Failureで応答する必要があります。ピアは、「エラーなし」障害コードを含むEAP-eke-failureメッセージを送り返す必要があります。次に、サーバーはExchangeを終了するために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.
o 暗号化アルゴリズム/モードに必要な場合に必要なオプションのIV、例えばCBC暗号化の場合。このフィールドのコンテンツとサイズは、選択した暗号化アルゴリズムによって決定されます。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は、送信された情報を検証したり、使用したりしません。情報は、EAP-EKE-Confirm Exchangeで検証されるまで、消費者プロトコルで使用してはなりません（具体的には、auth_s、auth_pペイロードによって整合性が保護されるまで）。その結果、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.
これは、チャネルバインディング値のタイプです。このドキュメントでは、値0x0000を予約済みと定義しています。IANAの割り当てには、その他の値が利用できます。セクション7.6を参照してください。
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.
ここで、X_Sは範囲2のランダムに選択された数値です。P-1。ランダムに選択された数字は一時的な秘密鍵であり、計算された値は対応する一時的な公開鍵です。サーバーとピアは、プロトコルの各実行でX_Sの新鮮でランダムな値と対応するX_Pを使用する必要があります。
The server computes and transmits the encrypted field (Section 4.4)
サーバーは暗号化されたフィールドを計算して送信します（セクション4.4）
temp = prf(0+, password)
key = prf+(temp, ID_S | ID_P)
key = prf（temp、id_s | id_p）
DHComponent_S = Encr(key, y_s).
dhcomponent_s = encr（key、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つのステップのいずれかの出力を選択する場合があることに注意してください。パスワードがID値によって塩分される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)
key = prf+(temp, ID_S | ID_P)
key = prf（temp、id_s | id_p）
DHComponent_P = Encr(key, y_p)
dhcomponent_p = encr（key、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))
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]の「抽出ステップ」です。ピアは、応答を送信する前に共有秘密の値を計算する必要があることに注意してください。
The encryption and integrity protection keys are computed:
暗号化と整合性保護キーが計算されます。
Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)
ke |ki = prf（sharedsecret、 "eap-eke keys" | id_s | id_p）
And the peer generates the Protected Nonce:
そして、ピアは保護されたノンセを生成します：
PNonce_P = Prot(Ke, Ki, Nonce_P),
pnonce_p = prot（ke、ki、nonce_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）、KIを使用してKIを使用して保護されているKEとMACアルゴリズムを使用して保護されています。
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.
サーバーは、受信したNONCEの正しい整合性保護を確認する必要があり、「認証障害」コードで、間違っている場合はプロトコルを中止する必要があります。
The server constructs:
サーバーは構成します：
PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S),
pnonce_ps = prot（ke、ki、nonce_p | nonce_s）、
as a protected field, where Nonce_S is a randomly generated string, of the same size as Nonce_P.
非CE_Sは、NonCE_Pと同じサイズのランダムに生成された文字列である保護されたフィールドとして。
It computes:
それは計算します：
Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | Nonce_S)
ka = prf（sharedsecret、 "eap-eke ka" | 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 server" | eap-eke-id/request | eap-eke-id/response | eap-eke-commit/request | eap-eke-commit/response）。
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-confirm/requestまたはeap-eke-confirm/responseメッセージ自体に追加してはならないことを意味します。。
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)
pnonce_s = prot（ke、ki、nonce_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 peer" | eap-eke-id/request | eap-eke-id/response | eap-eke-commit/request | eap-eke-commit/response）
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.
サーバーは、受信したNonCEの正しい整合性保護と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]で指定された半径属性をキーイング材料の輸送に使用する場合、MSKの最初の32バイトはMS-MPPE-RECV-KEYに対応し、2番目の32バイトにMS-MPPE-Send-Keyに対応します。この場合、キーイング材料（MSK）のキーイング材料（MSK）のみが使用されます。
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、ka、および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、s）= t1 |T2 |T3 |T4 |...
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ビットの高度な暗号化標準（AES）キーと160ビットHMACキーであり、PRF関数が160ビットを生成します。T1とT2の始まりから来ますが、HMACキーはT2の残りの部分とT3の始まりから来ます）。
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グループには、パスワードに関する使用可能な量の情報が漏れないようにするために、次のプロパティが必要です。
1. The generator is a primitive element of the group.
1. ジェネレーターは、グループの原始的な要素です。
2. The most significant 64 bits of the prime number are 1.
2. プライムナンバーの最も重要な64ビットは1です。
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-group）
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は次のサブセクションで説明されているレジストリを作成しました。値（個人用の値以外）は、必要な仕様ごとにこれらのレジストリに追加できます[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.
この表は、このレジストリの初期内容を定義します。値列は、グループを交渉するときに使用されます。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」です。文字列には、ターミネーター（ヌル、CRなど）を含めてはなりません。ID_FQDNのすべての文字はASCIIです。国際化されたドメイン名の場合、構文は[rfc5891]、たとえば「xn - tmonesimerkki-bfbb.example.net」で定義されています。
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レジストリを定義します。値0x0000は予約されていると定義されています。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.
このセクションでは、8ビットの長いコードであるEAP-EKE Exchangeレジストリの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.
このセクションでは、32ビットの長いコードである故障コードレジストリのIANAレジストリを定義します。初期値は、セクション4.2.4で定義されています。0xfeffffffFFまでのすべての値は、IANA経由の割り当てに使用できます。0xffffffffffまでの残りの値は、プライベートで使用できます。
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]はこれらのいくつかを義務付け、推奨します。主張は次のとおりです。
1. Mechanism: password.
1. メカニズム：パスワード。
2. Claims:
2. 請求：
* 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 (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またはEMSKの妥協を可能にしません。
* 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 Association、または802.3 "Link-up"を介して接続を取得し、2つのEAPメッセージに応答するという要件により、ゲートされています。-id/request and eap-eke-id/request。
* 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-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.
* 「Denning-Sacco」攻撃に対する抵抗：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とEMSKは、交渉された擬似ランダム関数を使用して、プロトコルの実行中に生成された秘密の値から導き出されます。
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.
* 保護された暗号化されたネゴシエーション：サーバーによって行われたciphersuiteの提案は、アクティブな攻撃者による改ざんから保護されていません。ただし、提案がアクティブな攻撃者によって変更された場合、提案は各側によって確認メッセージに拘束され、結果としてプロトコルが失敗するため、相手が送信したメッセージを確認できなくなります。これは、提案されているシファースーツのいずれも、攻撃者がリアルタイムの暗号化を実行できるようにすることを想定していることに注意してください。
* 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/リクエストでサーバーのIDを表示し、EAP-EKE-ID/ Responseでピアの身元を確認します。セクション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.
コミット交換を分析する場合、基本セキュリティの仮定は「通常の」暗号学とは異なることに注意する必要があります。通常、キーには強力なセキュリティプロパティがあり、データにはほとんどないか何もない可能性があると想定しています。ここでは、キーにはセキュリティプロパティが弱い（攻撃者に可能なキーのリストがある場合がある）、したがって、データに強いプロパティがあることを確認する必要があります（ランダムと区別できない）。この違いは、この場合、暗号学の従来の知恵が適用されない可能性があることを意味する場合があります。これはまた、プロトコルに深刻な制約を課します。たとえば、ランダムパディングの必須使用や特定の有限グループを定義する必要性。
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値のパッシブ攻撃者は、パスワードの推測に基づいて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交換は保護されておらず、盗聴者は両方の当事者のアイデンティティを観察できます。このプロトコルの将来の拡張は、たとえば、サーバーが交換の終わりにピアに一時的なアイデンティティを送信できるようにすることにより、匿名性をサポートする可能性があります。
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は、この点でトンネルメソッドとは異なります。これは、通常、ID交換を暗号化することにより、ピアに無条件のアイデンティティ保護を提供しますが、サーバー証明書に情報を明らかにします。このレベルのアイデンティティ保護を実現するために、トンネル付き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 複雑な展開と移行シナリオには、各アルゴリズムごとに複数の保存されたパスワードが必要になる場合があります。
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]から恥ずかしくも選択されていました。これらの文書の著者に感謝します：ダンハーキンス、グレンゾーン、ジェームズカールソン、バーナードアボバ、ヘンリーヘイベーリネン。デイビッド・ジェイコブソン、スティーブ・ベロヴィン、ラス・ハウスリー、ブライアン・ワイス、ダン・ハーキンス、アレクセイ・メルニコフの有用なコメントに感謝します。Lidar HerootyとIdan Ofratはこのプロトコルを実装し、適切な質問をすることでそれを改善するのに役立ちました。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor固有のRADIUS属性」、RFC 2548、1999年3月。
[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月。
[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. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、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.、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月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、2006年6月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、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] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン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]国立標準技術研究所、米国商務省、「Secure Hash Standard」、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. Merritt、「暗号化されたキーエクスチェンジ：パスワードベースのプロトコルは辞書攻撃に対して安全な」、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. Merritt、「拡張暗号化されたキーエクスチェンジ：辞書攻撃とパスワードファイルの妥協に対して安全なパスワードベースのプロトコル」、Proc。コンピューターおよび通信セキュリティに関する第1回ACM会議、1993年。
[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.、Mackenzie、P。、およびS. Patel、「Diffie-Hellmanを使用したパスワード認証キー交換」、CryptologyのAdvances、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] Black、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] Carlson、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巻、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] Patel、S。、「安全なパスワードスキームに対する数の理論的攻撃」、1997年のIEEE Symposium on Security and Privacyの議事録、1997年。
[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月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、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] Harkins、D。およびG. Zorn、「パスワードのみを使用した拡張可能な認証プロトコル（EAP）認証」、RFC 5931、2010年8月。
Authors' Addresses
著者のアドレス
Yaron Sheffer Independent
ヤロン・シェファー・インディペンデント
EMail: yaronf.ietf@gmail.com
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na、Bangkok 10260 Thail
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Scott Fluhrer Cisco Systems. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
スコット・フルラー・シスコ・システム。1414マサチューセッツアベニュー、ボックスボロー、マサチューセッツ州01719 USA
EMail: sfluhrer@cisco.com