Network Working Group F. Bersani
Request for Comments: 4764 France Telecom R&D
Category: Experimental H. Tschofenig
Siemens Networks GmbH & Co KG
January 2007
The EAP-PSK Protocol:
A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
The IESG thinks that this work is related to IETF work done in WGs EMU and EAP, but this does not prevent publishing.
IESGは、この作業は各WG EMUおよびEAPで行わIETF仕事に関連していると思うが、これは公開を防ぐことはできません。
Abstract
抽象
This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.
この文書では、EAP-PSK、相互認証及び事前共有キー（PSK）を使用してセッション鍵導出のために拡張認証プロトコル（EAP）メソッドを指定します。両当事者が上で通信するために、相互認証が成功した場合、EAP-PSKは、保護された通信チャネルを提供します。この文書では、唯一の結果指摘の保護交換のために、このチャネルの使用が記載されているが、将来のEAP-PSKの拡張は、他の目的のためのチャネルを使用することができます。 EAP-PSKは、IEEE 802.11のような安全でないネットワーク上で認証のために設計されています。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Design Goals for EAP-PSK ...................................4
1.1.1. Simplicity ..........................................4
1.1.2. Wide Applicability ..................................5
1.1.3. Security ............................................5
1.1.4. Extensibility .......................................5
1.2. Terminology ................................................5
1.3. Conventions ................................................8
1.4. Related Work ...............................................9
2. Protocol Overview ..............................................12
2.1. EAP-PSK Key Hierarchy .....................................13
2.1.1. The PSK ............................................13
2.1.2. AK .................................................14
2.1.3. KDK ................................................14
2.2. The TEK ...................................................15
2.3. The MSK ...................................................15
2.4. The EMSK ..................................................15
2.5. The IV ....................................................15
3. Cryptographic Design of EAP-PSK ................................15
3.1. The Key Setup .............................................16
3.2. The Authenticated Key Exchange ............................19
3.3. The Protected Channel .....................................23
4. EAP-PSK Message Flows ..........................................25
4.1. EAP-PSK Standard Authentication ...........................26
4.2. EAP-PSK Extended Authentication ...........................28
5. EAP-PSK Message Format .........................................31
5.1. EAP-PSK First Message .....................................32
5.2. EAP-PSK Second Message ....................................34
5.3. EAP-PSK Third Message .....................................36
5.4. EAP-PSK Fourth Message ....................................39
6. Rules of Operation for the EAP-PSK Protected Channel ...........41
6.1. Protected Result Indications ..............................41
6.1.1. CONT ...............................................42
6.1.2. DONE_SUCCESS .......................................43
6.1.3. DONE_FAILURE .......................................43
6.2. Extended Authentication ...................................43
7. IANA Considerations ............................................45
7.1. Allocation of an EAP-Request/Response Type for EAP-PSK ....45
7.2. Allocation of EXT Type Numbers ............................45
8. Security Considerations ........................................46
8.1. Mutual Authentication .....................................46
8.2. Protected Result Indications ..............................47
8.3. Integrity Protection ......................................48
8.4. Replay Protection .........................................48
8.5. Reflection Attacks ........................................48
8.6. Dictionary Attacks ........................................49
8.7. Key Derivation ............................................49
8.8. Denial-of-Service Resistance ..............................51
8.9. Session Independence ......................................51
8.10. Exposition of the PSK ....................................52
8.11. Fragmentation ............................................52
8.12. Channel Binding ..........................................53
8.13. Fast Reconnect ...........................................53
8.14. Identity Protection ......................................53
8.15. Protected Ciphersuite Negotiation ........................55
8.16. Confidentiality ..........................................55
8.17. Cryptographic Binding ....................................55
8.18. Implementation of EAP-PSK ................................55
9. Security Claims ................................................56
10. Acknowledgments ...............................................57
11. References ....................................................57
11.1. Normative References .....................................57
11.2. Informative References ...................................58
Appendix A. Generation of the PSK from a Password - Discouraged ...62
The Extensible Authentication Protocol (EAP) [3] provides an authentication framework that supports multiple authentication methods.
拡張認証プロトコル（EAP）[3]複数の認証方法をサポートする認証フレームワークを提供します。
This document specifies an EAP method, called EAP-PSK, that uses a Pre-Shared Key (PSK).
この文書では、事前共有鍵（PSK）を使用するEAP-PSKと呼ばれるEAPメソッドを、指定します。
EAP-PSK was developed at France Telecom R&D in 2003-2004. It is published as an RFC for the general information of the Internet community and to allow independent implementations.
EAP-PSKは、2003年から2004年にはフランステレコムR＆Dで開発されました。これは、インターネットコミュニティの一般的な情報については、RFCとして公開され、独立した実装を可能にするために。
Because PSKs are of frequent use in security protocols, other protocols may also refer to a PSK or contain this word in their name. For instance, Wi-Fi Protected Access (WPA) [48] specifies an authentication mode called "WPA-PSK". EAP-PSK is distinct from these protocols and should not be confused with them.
PSKsは、セキュリティプロトコルで頻繁に使用であるため、他のプロトコルもPSKを参照するか、自分の名前で、この言葉が含まれていてもよいです。例えば、のWi-Fi保護アクセス（WPA）は、[48]、 "WPA-PSK" と呼ばれる認証モードを指定します。 EAP-PSKは、これらのプロトコルは区別され、それらと混同してはなりません。
Design goals for EAP-PSK were:
EAP-PSKのための設計目標は以下の通りでした。
o Simplicity: EAP-PSK should be easy to implement and deploy without any pre-existing infrastructure. It should be available quickly because recently-released protocols, such as IEEE 802.11i [27], employ EAP in a different threat model than PPP [44] and thus require "modern" EAP methods.
Oシンプル：EAP-PSKは実装が容易で、あらゆる既存のインフラストラクチャなしに展開する必要があります。そのようなIEEE 802.11i規格[27]など最近リリースプロトコルは、PPP [44]とは異なる脅威モデルでEAPを採用するため、「現代」のEAPメソッドを必要とするので、それはすぐに利用可能であるべきです。
o Wide applicability: EAP-PSK should be suitable to authenticate over any network, and in particular over IEEE 802.11 [28] wireless LANs.
O広い適用：EAP-PSKは、任意のネットワーク上、特に、IEEE 802.11、[28]無線LAN上に認証するのに好適であるべきです。
o Security: EAP-PSK should be conservative in its cryptographic design.
Oセキュリティ：EAP-PSKは、その暗号の設計で保守的でなければなりません。
o Extensibility: EAP-PSK should be easily extensible.
拡張（O）EAP-PSKを容易に拡張可能であるべきです。
For the sake of simplicity, EAP-PSK relies on a single cryptographic primitive, AES-128 [7].
簡略化のため、EAP-PSKは、単一の暗号プリミティブに依存して、AES-128 [7]。
Restriction to such a primitive, and in particular, not using asymmetric cryptography like Diffie-Hellman key exchange, makes EAP-PSK: o Easy to understand and implement while avoiding cryptographic negotiations.
Diffie-Hellman鍵交換のような原始的な、特に、使用していない非対称暗号への制限は、EAP-PSKを作る：簡単に理解し、暗号化交渉を回避しながら実装するoを。
o Lightweight and well suited for any type of device, especially those with little processing power and memory.
O軽量デバイスの任意のタイプ、ほとんどの処理能力とメモリと特によく適し。
However, as further discussed in Section 8, this prevents EAP-PSK from offering advanced features such as identity protection, password support, or Perfect Forward Secrecy (PFS). This choice has been deliberately made as a trade-off between simplicity and security.
さらに8章で述べたようにしかし、これは、そのようなアイデンティティ保護、パスワードのサポート、または完全転送秘密（PFS）などの高度な機能を提供するから、EAP-PSKを防ぐことができます。この選択は、意図的にシンプルさとセキュリティの間のトレードオフとして行われています。
For the sake of simplicity, EAP-PSK has also chosen a fixed message format and not a Type-Length-Value (TLV) design.
簡略化のため、EAP-PSKはまた、固定されたメッセージフォーマットとしないタイプレングス値（TLV）デザインを選択しました。
EAP-PSK has been designed in a threat model where the attacker has full control over the communication channel. This is the EAP threat model that is presented in Section 7.1 of [3].
EAP-PSKは、攻撃者が通信チャネルを介して完全な制御を有する脅威モデルに設計されています。これは、[3]のセクション7.1に提示されたEAPの脅威モデルです。
Since the design of authenticated key exchange is notoriously known to be hard and error prone, EAP-PSK tries to avoid inventing any new cryptographic mechanism. It attempts instead to build on existing primitives and protocols that have been reviewed by the cryptographic community.
認証された鍵交換の設計は悪名高いハードとエラーが発生しやすいことが知られているので、EAP-PSKは、どんな新しい暗号化メカニズムを発明回避しようとしています。それは、暗号コミュニティによってレビューされている既存のプリミティブとプロトコル上に構築する代わりにしようとします。
EAP-PSK explicitly provides a mechanism to allow future extensions within its protected channel (see Section 3.3). Thanks to this mechanism, EAP-PSK will be able to provide more sophisticated services as the need to do so arises.
EAP-PSKが明示的に保護されたチャネル内の将来の拡張を可能にする機構を提供する（セクション3.3を参照）。このメカニズムのおかげで、EAP-PSKはそれほど生じ行う必要として、より洗練されたサービスを提供することができるようになります。
Authentication, Authorization, and Accounting (AAA) Please refer to [10] for more details.
認証、許可、アカウンティング（AAA）の詳細については、[10]を参照して下さい。
AES-128 A block cipher specified in the Advanced Encryption Standard [7].
AES-128高度暗号化規格で指定されたブロック暗号[7]。
Authentication Key (AK) A 16-byte key derived from the PSK that the EAP peer and server use to mutually authenticate.
認証キー（AK）EAPピアとサーバの使用が相互認証するPSKに由来する16バイトのキー。
AKEP2 An authenticated key exchange protocol; please refer to [14] for more details.
AKEP2 Anが鍵交換プロトコルを認証し、詳細については[14]を参照してください。
Backend Authentication Server An entity that provides an authentication service to an Authenticator. When used, this server typically executes EAP methods for the Authenticator. (This terminology is also used in [26], and has the same meaning in this document.)
バックエンド認証サーバー認証に認証サービスを提供するエンティティ。使用する場合、このサーバは、一般的に認証のためのEAPメソッドを実行します。 （この用語はまた、[26]で使用され、この文書に記載されているのと同じ意味を有します。）
CMAC Cipher-based Message Authentication Code. It is the authentication mode of operation of AES recommended by NIST in [8].
CMAC暗号ベースのメッセージ認証コード。これは、[8]でNISTによって推奨されるAESの操作の認証モードです。
Extensible Authentication Protocol (EAP) Defined in [3].
[3]で定義された拡張認証プロトコル（EAP）。
EAP Authenticator (or simply Authenticator) The end of the EAP link initiating the EAP authentication methods. (This terminology is also used in [26], and has the same meaning in this document.)
EAP認証（または単に認証）EAP認証メソッドを開始するEAPリンクの端部。 （この用語はまた、[26]で使用され、この文書に記載されているのと同じ意味を有します。）
EAP peer (or simply peer) The end of the EAP link that responds to the Authenticator. (In [26], this end is known as the Supplicant.)
EAPピア（又は単にピア）オーセンティケータに応答するEAPリンクの端部。 （[26]において、この目的は、サプリカントとして知られています。）
EAP server (or simply server) The entity that terminates the EAP authentication with the peer. When there is no Backend Authentication Server, this term refers to the EAP Authenticator. Where the EAP Authenticator operates in pass-through mode, it refers to the Backend Authentication Server.
EAPサーバ（または単にサーバ）ピアとEAP認証を終了するエンティティ。何のバックエンド認証サーバが存在しない場合には、この用語は、EAP認証を指します。 EAP認証がパススルーモードで動作する場合、それはバックエンド認証サーバを指します。
EAX An authenticated-encryption with associated data mode of operation for block ciphers [4].
ブロック暗号のための動作の関連するデータモードにEAX認証、暗号化[4]。
Extended Master Session Key (EMSK) Additional keying material derived between the EAP peer and server that is exported by the EAP method. The EMSK is reserved for future uses that are not defined yet and is not provided to a third party. Please refer to [9] for more details. EAP-PSK generates a 64-byte EMSK.
EAP方式によってエクスポートされたEAPピアとサーバ間の派生拡張マスターセッションキー（EMSK）の追加鍵素材。 EMSKはまだ定義されておらず、第三者に提供されていない将来の使用のために予約されています。詳細については、[9]を参照してください。 EAP-PSKは、64バイトのEMSKを生成します。
Initialization Vector (IV) A quantity of at least 64 bytes, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in methods such as EAP-TLS [11], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it. Please refer to [9] for more details. EAP-PSK does not generate an IV.
初期化ベクトル（IV）ピアとEAPサーバとの間に誘導される初期化ベクトルフィールドでの使用に適した、少なくとも64バイトの量、。 IVは、EAP-TLSなどの方法で既知の値[11]であるため、それは秘密のままにする必要がある任意の量の計算のために単独で使用することができません。その結果、その使用は推奨されていませんし、EAP方法は、それを生成する必要はありません。詳細については、[9]を参照してください。 EAP-PSKは、IVを生成しません。
Key-Derivation Key (KDK) A 16-byte key derived from the PSK that the EAP peer and server use to derive session keys (namely, the TEK, MSK, and EMSK).
鍵導出鍵（KDK）EAPピアとサーバの使用は、セッションキーを導出するPSK（すなわち、TEK、MSK及びEMSK）から誘導される16バイトのキー。
Message Authentication Code (MAC) Informally, the purpose of a MAC is to provide assurances regarding both the source of a message and its integrity [40]. IEEE 802.11i uses the acronym MIC (Message Integrity Check) to avoid confusion with the other meaning of the acronym MAC (Medium Access Control).
メッセージ認証コード（MAC）が非公式に、MACの目的は、メッセージの送信元とその完全性[40]の両方についての保証を提供することです。 IEEE 802.11i規格は、頭文字MAC（媒体アクセス制御）の他の意味との混同を避けるために、頭文字MIC（メッセージ完全性チェック）を使用しています。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. In existing implementations, a AAA server acting as an EAP server transports the MSK to the Authenticator [9]. EAP-PSK generates a 64-byte MSK.
EAPピアとサーバとの間で導出され、EAPメソッドによってエクスポートされるマスタセッションキー（MSK）キーイング材料。既存の実装では、EAPサーバとして作用するAAAサーバは、[9]オーセンティケータにMSKを搬送します。 EAP-PSKは、64バイトのMSKを生成します。
Network Access Identifier (NAI) Identifier used to identify the communicating parties [2].
ネットワークアクセス識別子（NAI）識別子は、通信相手を識別するために使用される[2]。
One Key CBC-MAC 1 (OMAC1) A method to generate a Message Authentication Code [29]. CMAC is the name under which NIST has standardized OMAC1.
一つのキーCBC-MAC 1（OMAC1）メッセージ認証コードを生成する方法[29]。 CMACは、NISTがOMAC1を標準化しているその下の名前です。
Perfect Forward Secrecy (PFS) The confidence that the compromise of a long-term private key does not compromise any earlier session keys. In other words, once an EAP dialog is finished and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the peer and the server cannot reconstruct the keys used to protect the conversation without doing a brute-force search of the session key space.
完全転送秘密（PFS）の長期秘密鍵の妥協が以前のセッションキーを損なわないことを確信。言い換えれば、一度EAPダイアログが終了し、それに対応するキーは、接続からデータのすべてを記録し、ピアの長期的なキーとキーを再構築することはできませんサーバーのすべてにアクセスできるようになりますしていても、誰かを忘れていますセッション鍵空間の力まかせ探索を行うことなく会話を保護するために使用。
EAP-PSK does not have this property.
EAP-PSKは、このプロパティを持っていません。
Pre-Shared Key (PSK) A Pre-Shared Key simply means a key in symmetric cryptography. This key is derived by some prior mechanism and shared between the parties before the protocol using it takes place. It is merely a bit sequence of given length, each bit of which has been chosen at random uniformly and independently. For EAP-PSK, the PSK is the long-term 16- byte credential shared by the EAP peer and server.
事前共有鍵（PSK）事前共有キーは、単に対称暗号における鍵を意味します。このキーは、いくつかの従来のメカニズムによって導出され、それが行われます使用してプロトコルの前に当事者間で共有されています。単に均一にかつ独立してランダムに選択された各ビットのうち所定の長さのビット列です。 EAP-PSKのために、PSKは、EAPピア及びサーバによって共有される長期的な16バイトの資格です。
Protected Result Indication Please refer to Section 7.16 of [3] for a definition of this term. This feature has been introduced because EAP-Success/Failure packets are unidirectional and are not protected.
保護された結果指示は、この用語の定義については、[3]のセクション7.16を参照してください。 EAP-成功/失敗パケットが単方向であり、保護されていないため、この機能が導入されました。
Transient EAP Key (TEK) A session key that is used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEK is appropriate for use with the ciphersuite negotiated between the EAP peer and server to protect the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and Authenticator [9]. EAP-PSK uses a 16-byte TEK for its protected channel, which is the only ciphersuite available between the EAP peer and server to protect the EAP conversation. This ciphersuite uses AES-128 in the EAX mode of operation.
過渡EAPキー（TEK）EAP認証交換中にEAPピアとサーバ間の保護されたチャネルを確立するために使用されるセッションキー。 TEKは、EAPの会話を保護するためのEAPピアとサーバの間で交渉暗号スイートでの使用に適しています。 EAP認証時にEAPピアとサーバ間の保護されたチャネルをセットアップするために使用される暗号スイートは、その後EAPピアとオーセンティケータ[9]の間で送信されるデータを保護するために使用される暗号スイートとは無関係であることに留意されたいです。 EAP-PSKは、EAPの会話を保護するためEAPピアとサーバ間で利用可能な唯一の暗号スイートであり、その保護されたチャネル、16バイトのTEKを使用します。この暗号スイートは、操作のEAXモードのAES-128を使用しています。
All numbers presented in this document are considered in network-byte order.
この文書のすべての数字は、ネットワークバイト順に考慮されています。
|| denotes concatenation of strings (and not the logical OR).
||文字列の連結（とない論理和）です。
MAC(K, String) denotes the MAC of String under the key K (the algorithm used in this document to compute the MACs is CMAC with AES-128; see Section 3.2).
MAC（K、文字列）キーKの下の列のMAC（MACを計算するために本書で使用しているアルゴリズムは、AES-128とCMACであり; 3.2節を参照）です。
[String] denotes the concatenation of String with the MAC of String calculated as specified by the context. Hence, we have, with K specified by the context: [String]=String||MAC(K,String)
[文字列]コンテキストによって指定されるように計算されたStringのMACと文字列の連結を表します。したがって、我々はコンテキストによって指定されたKと、を有する：[文字列] =文字列|| MAC（K、文字列）
** denotes integer exponentiation.
**整数累乗を表します。
"i" denotes the unsigned binary representation on 16 bytes of the integer i in network byte order. Therefore, this notation only makes sense when i is between 0 and 2**128-1.
「i」はネットワークバイト順に整数Iの16バイトに符号なし2進表現を示しています。 iは0〜2 ** 128-1である場合したがって、この表記法は、理にかなっています。
<i> denotes the unsigned binary representation on 4 bytes of the integer i in network byte order. Therefore, this notation only makes sense when i is between 0 and 2**32-1.
<i>はネットワークバイト順に整数Iの4バイトに符号なし2進表現を示しています。 iは0〜2 ** 32-1である場合したがって、この表記法は、理にかなっています。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
At the time this document is written, only three EAP methods are standards track EAP methods per IETF terminology (see [17]), namely:
この文書が書かれている時点では、唯一の3 EAP方法は規格である、すなわち、（[17]参照）IETF用語あたりのEAPメソッドを追跡します：
o MD5-Challenge (EAP-Request/Response type 4), defined in [3], which uses a MD5 challenge similar to [45].
[45]と同様MD5チャレンジを使用して、[3]で定義されたO MD5チャレンジ（EAP要求/応答タイプ4）、、。
o OTP (EAP-Request/Response type 5), defined in [3], which aims at providing One-Time Password support similar to [22] and [39].
O OTP（EAP要求/応答タイプ5）、[3]と同様のワンタイムパスワードのサポートを提供することを目的とした定義された[22]及び[39]。
o GTC (EAP-Request/Response type 6), defined in [3], which aims at providing Generic Token Card Support.
一般的なトークンカードサポートを提供することを目的O GTC（EAP要求/応答タイプ6）、[3]で定義され、。
Unfortunately, all three methods are deprecated for security reasons that are explained in part in [3].
残念ながら、すべての3つの方法は、[3]に部分的に説明されているセキュリティ上の理由から廃止されました。
Myriads of EAP methods have, however, been otherwise proposed:
EAPメソッドの無数が、しかし、そうでない場合は提案されています。
o One as an experimental RFC (EAP-TLS [11]), which therefore is not a standard (see [25]).
したがって、標準ではない実験RFC（EAP-TLS [11]）のような1、O（[25]参照）。
o Some as individual Internet-Draft submissions (e.g., [42] or this document).
Oの一部として、個々のインターネットドラフト提出（例えば、[42]又は本書）。
o And some even undocumented (e.g., Rob EAP, which has EAP-Request/ Response type 31).
Oおよび一部も文書化されていない（EAP要求/応答タイプ31を有する、例えば、ロブEAP）。
However, no secure and mature Pre-Shared Key EAP method is yet easily and widely available, which is all the more regrettable because Pre-Shared Key methods are the most basic ones!
しかし、安全かつ成熟した事前共有キーEAP方式は、事前共有キーの方法は、最も基本的なものであるため、すべてのより多く残念である、簡単に、広くはまだ利用できません！
The existing proposals for a future Pre-Shared Key EAP method are briefly reviewed hereafter (please refer to [16] for a more thorough synthesis of EAP methods).
将来の事前共有キーEAP方式のための既存の提案は、簡単に（EAP方法のより完全な合成のための[16]を参照してください）以下を検討しています。
Among these proposals, there are some that:
これらの提案の中で、いくつかのことがあります。
o Are broken from a security point of view, e.g.:
Oは、例えば、セキュリティの観点から壊れています：
* LEAP, which is specified in [38] and whose vulnerabilities are discussed in [49].
その脆弱性[49]に記載されている* [38]で指定されLEAP、および。
* EAP-MSCHAPv2, which is specified in [34] and whose vulnerabilities are indirectly discussed in [43].
*その脆弱性間接的[43]に記載されている[34]で指定されたEAP-MSCHAPv2、および。
o Essentially require additional infrastructure, e.g., EAP-SIM [24], EAP-AKA [12], or OTP/token card methods like [31].
O本質的に追加のインフラストラクチャ、例えば、EAP-SIM [24]、EAP-AKA [12]又は[31]のようなOTP /トークンカードの方法を必要とします。
o Are not shared key methods but are often confused with them, namely, the password methods, e.g., EAP-SRP [18] or SPEKE [30], whose wide adoption very unfortunately seems to be hindered by Intellectual Property Rights issues.
Oキーメソッドを共有されていないが、多くの場合、それらと混同されている、すなわち、その幅広い採用例えば、パスワード方式、EAP-SRP [18]またはSPEKE [30]は、非常に残念な知的財産権の問題によって妨げられているように見えます。
o Are generic tunneling methods, which do not essentially rely on Pre-Shared Keys as they require a public-key certificate for the server and allow the peer to authenticate with whatever EAP method or even other non-EAP authentication mechanisms, namely, [32] and [21].
Oは、サーバーの公開鍵証明書を必要とし、ピアはすなわち、どのようなEAP方式、あるいは他の非EAP認証メカニズムで認証できるようにするのと本質的に事前共有鍵に依存しない汎用的なトンネリング方法、[32です]及び[21]。
o Are abandoned but have provided the basis for EAP-PSK, namely, EAP-Archie [47].
O放棄されているが、EAP-PSK、すなわち、EAP-アーチー[47]のための基礎を提供しています。
o Are possible alternatives to EAP-PSK (i.e., claimed to be secure and subject of active work):
O EAP-PSK（すなわち、安全でアクティブな作業の対象であると主張）に可能な選択肢は次のとおりです。
* EAP-FAST [42].
* EAP-FAST [42]。
* EAP-IKEv2 [46].
* CRD-IKEf2 [46]。
* EAP-TLS (when shared key/password support is added to TLS; see [50]).
（共有鍵/パスワードサポートがTLSに追加され、[50]参照）* EAP-TLS。
EAP-PSK differs from the aforementioned methods on the following points:
EAP-PSKは、以下の点で前述の方法とは異なります。
o No attacks on EAP-PSK within its threat model have yet been found.
Oその脅威モデル内のEAP-PSKでのいかなる攻撃はまだ見出されていません。
o EAP-PSK was not designed to leverage a pre-existing infrastructure. Thus, it does not inherit potential limitations of such an infrastructure and it should be easier to deploy "from scratch".
O EAP-PSKは、既存のインフラストラクチャを活用するように設計されていませんでした。したがって、そのようなインフラの潜在的な制限を継承していないと、「ゼロから」展開することが容易でなければなりません。
o EAP-PSK wished to avoid IPR blockages.
O EAP-PSKは、IPRの閉塞を避けることを望みました。
o EAP-PSK does not have any dependencies on protocols other than EAP.
O EAP-PSKは、EAP以外のプロトコル上の任意の依存関係を持っていません。
o EAP-PSK was restricted to simply proposing a Pre-Shared Key method with symmetric cryptography
O EAP-PSKは、単純に、対称暗号と事前共有鍵方式を提案するために制限されていました
* To remain simple to understand and implement
*理解し、実装するための単純なままにするには
* To avoid potentially complex configurations and negotiations
*潜在的に複雑な構成と交渉を回避するために、
o EAP-PSK was designed with efficiency in mind.
O EAP-PSKを念頭に置いて効率的に設計されました。
Figure 1 presents an overview of the EAP-PSK key hierarchy.
図1は、EAP-PSKキー階層の概要を説明します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
| EAP-PSK Protocol: a Pre-Shared Key EAP Method | |
| | |
| +----------+ | |
| | PSK | | |
| |(16 bytes)| | |
| +----------+ | |
| | | |
| v | |
| *********************** | |
| *Modified Counter Mode* | |
| *********************** | |
| | | | |
| v v | |
| +----------+ +----------+ +----------------+ | |
| | AK | | KDK | | RAND_P | | |
| |(16 bytes)| |(16 bytes)| | (16 bytes) | | |
| +----------+ +----------+ +----------------+ | |
| | | | |
| | | | |
| +-----------+ | | | |
| +--------+|Plain Text | | | | |
|+-------+|Header H||Var.Length | | | | |
||Nonce N||22 bytes|+-----------+ v v Local |
||4 bytes|+--------+ | *********************** to EAP |
|+-------+ | +--------+ +------*Modified Counter Mode* Method |
| | v v v *********************** | |
| | ******* +--------+ |64 |64 | |
| | * EAX *-------|TEK | |bytes |bytes | |
| +-->******* |16 bytes| | | | |
| | +--------+ | | | |
| +-----+----+ | | | |
| v v | | | |
|+--------+ +-------------------+ | | | |
||Tag | |Cipher Text Payload| | | | |
||16 bytes| | Variable length L | | | | |
|+--------+ +-------------------+ | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
+-+-+-+-+-++ +-+-+-+-+-++ |
|MSK | |EMSK | |
| | | | Exported |
+-+-+-+-+-++ +-+-+-+-+-++ by EAP |
| | Method |
| | |
V V |
************************* V
* AAA Key Derivation * ---+
* Naming & Binding *
*************************
Figure 1: EAP-PSK Key Hierarchy Overview
図1：EAP-PSKキー階層の概要
This section presents the key hierarchy used by EAP-PSK. This hierarchy is inspired by the EAP key hierarchy described in [9].
このセクションでは、EAP-PSKで使用されるキー階層を提示します。この階層は、[9]に記載のEAPキー階層に触発されています。
The PSK is shared between the EAP peer and the EAP server.
PSKは、EAPピアとEAPサーバの間で共有されます。
EAP-PSK assumes that the PSK is known only to the EAP peer and EAP server. The security properties of the protocol are compromised if it has wider distribution. Please note that EAP-PSK shares this property with all other symmetric key methods (including all password-based methods).
EAP-PSKは、PSKのみEAPピアとEAPサーバに知られていることを前提としています。それは広い分布を持っている場合、プロトコルのセキュリティプロパティが侵害されています。 EAP-PSKは、株式（すべてのパスワードベースの方法を含む）他のすべての対称鍵の方法と、このプロパティをということに注意してください。
EAP-PSK also assumes the EAP server and EAP peer identify the correct PSK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI.
EAP-PSKはまた、EAPサーバとEAPピアがそれぞれのNAIに互いにおかげで使用する正しいPSKを識別する前提。これは多くても1つPSKが所与のピアNAIを使用して、指定されたサーバNAIとEAPピアを使用して、EAPサーバとの間で共有が存在しなければならないことを意味します。
This PSK is used, as shown in Figure 2, to derive two 16-byte static long-lived subkeys, respectively called the Authentication Key (AK) and the Key-Derivation Key (KDK). This derivation should only be done once: it is called the key setup. See Section 3.1 for an explanation of why PSK is not used as a static long-lived key, but only as the initial keying material for deriving the static long-lived keys, AK and KDK, which are actually used by the protocol EAP-PSK.
図2に示すように、このPSKは、それぞれ認証キー（AK）とキー導出鍵（KDK）と呼ばれる2つの16バイトの静的長寿命サブキーを導出するために、使用されます。この導出は一度だけ実行する必要があります。それは、キーのセットアップと呼ばれています。しかし、唯一の実際のプロトコルEAP-PSKで使用されている静的な長命のキー、AKとKDKを導出するための最初のキーイング材料として、PSKは静的な長命のキーとして使用されていない理由の説明については、セクション3.1を参照してください。 。
+---------------------------+
| PSK |
| (16 bytes) |
+---------------------------+
| |
v v
+---------------------------+ +---------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+---------------------------+ +---------------------------+
Figure 2: Derivation of AK and KDK from the PSK
図2：PSKからAKとKDKの導出
EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP server.
EAP-PSKは、相互にEAPピアとEAPサーバを認証するためにAKを使用しています。
AK is a static long-lived key derived from the PSK; see Section 3.1. AK is not a session key.
AKはPSK由来静的長寿命の鍵です。 3.1節を参照してください。 AKは、セッションキーではありません。
The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1.
EAPサーバとEAPピアは、それぞれのNAIにお互いのおかげで使用するための正しいAKを識別する。これは、多くても1つAKが与えられたピアNAIを使用して、指定されたサーバーNAIとEAPピアを使用して、EAPサーバ間で共有が存在しなければならないことを意味します。 PSKは、所与のピアNAIを使用して、指定されたサーバNAIとEAPピアを使用して、EAPサーバとの間で共有最大1つが存在する場合です。 2.1.1項を参照してください。
The EAP peer chooses the AK to use based on the EAP server NAI that has been sent by the EAP server in the first EAP-PSK message (namely, ID_S; see Section 4.1) and the EAP peer NAI it chooses to include in the second EAP-PSK message (namely, ID_P; see Section 4.1).
EAPピアは最初のEAP-PSKメッセージにEAPサーバによって送信されたEAPサーバNAIに基づいて、使用するAKを選択する（すなわち、ID_S、セクション4.1を参照）と、第2に含めることを選択したEAPピアNAIをEAP-PSKメッセージ（すなわち、ID_P、セクション4.1を参照）。
EAP-PSK uses KDK to derive session keys shared by the EAP peer and the EAP server (namely, the TEK, MSK, and EMSK).
EAP-PSKは、EAPピアとEAPサーバ（すなわち、TEK、MSK及びEMSK）で共有セッションキーを導出するためにKDKを使用します。
KDK is a static long-lived key derived from the PSK; see Section 3.1. KDK is not a session key.
KDKはPSK由来静的長寿命の鍵です。 3.1節を参照してください。 KDKは、セッションキーではありません。
The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1.
EAPサーバとEAPピアは、それぞれのNAIにお互いのおかげで使用するための正しいAKを識別する。これは、多くても1つAKが与えられたピアNAIを使用して、指定されたサーバーNAIとEAPピアを使用して、EAPサーバ間で共有が存在しなければならないことを意味します。 PSKは、所与のピアNAIを使用して、指定されたサーバNAIとEAPピアを使用して、EAPサーバとの間で共有最大1つが存在する場合です。 2.1.1項を参照してください。
The EAP peer chooses the AK to use based on the EAP server NAI that has been sent by the EAP server in the first EAP-PSK message (namely, ID_S; see Section 4.1) and the EAP peer NAI it chooses to include in the second EAP-PSK message (namely, ID_P; see Section 4.1).
EAPピアは最初のEAP-PSKメッセージにEAPサーバによって送信されたEAPサーバNAIに基づいて、使用するAKを選択する（すなわち、ID_S、セクション4.1を参照）と、第2に含めることを選択したEAPピアNAIをEAP-PSKメッセージ（すなわち、ID_P、セクション4.1を参照）。
EAP-PSK derives a 16-byte TEK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and KDK.
EAP-PSKは16バイトのTEKを導出乱数のおかげで、認証時（RAND_Pを、セクション5.1を参照）に交換し、KDKを。
This TEK is used to implement a protected channel for both mutually authenticated parties to communicate over securely.
このTEKは、両方の相互認証の当事者が確実介して通信するための保護されたチャネルを実装するために使用されます。
EAP-PSK derives a MSK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and the KDK.
EAP-PSK認証の間に交換乱数にMSKおかげ導出（RAND_Pと、セクション5.1を参照）とKDKを。
The MSK is 64 bytes long, which complies with [3].
MSKは、[3]に準拠した、64バイト長です。
EAP-PSK derives an EMSK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and the KDK.
EAP-PSKは、乱数のおかげでは、認証時に交換EMSK導出（RAND_Pと、セクション5.1を参照）とKDKを。
The EMSK is 64 bytes long, which complies with [3].
EMSKは、[3]に準拠した、64バイト長です。
EAP-PSK does not derive any IV, which complies with [9].
EAP-PSKは、[9]に準拠して任意のIVを導出しません。
EAP-PSK relies on a single cryptographic primitive, a block cipher, which is instantiated with AES-128. AES-128 takes a 16-byte Pre-Shared Key and a 16-byte Plain Text block as inputs. It outputs a 16-byte Cipher Text block. For a detailed description of AES-128, please refer to [7].
EAP-PSKは、AES-128でインスタンス化された単一の暗号プリミティブ、ブロック暗号、に依存しています。 AES-128は、入力として16バイトの事前共有キーと16バイトのテキストブロックを取ります。これは、16バイトの暗号文ブロックを出力します。 AES-128の詳細については、[7]を参照してください。
AES-128 has been chosen because:
AES-128があるため選ばれました：
o It is standardized and implementations are widely available.
Oそれは、標準化と実装が広く利用可能です。
o It has been carefully reviewed by the cryptographic community and is believed to be secure.
Oそれは慎重に、暗号コミュニティによってレビューされており、安全であると考えられています。
Other block ciphers could easily be proposed for EAP-PSK, as EAP-PSK does not intrinsically depend on AES-128. The only parameters of AES-128 that EAP-PSK depends on are the AES-128 block and key size (16 bytes). For the sake of simplicity, EAP-PSK has, however, been chosen to restrict to a single mandatory block cipher and not allow the negotiation of other block ciphers. In the case that AES-128 is deprecated for security reasons, EAP-PSK should also be deprecated and a cut-and-paste EAP-PSK' should be defined with another block cipher. This EAP-PSK' should not be backward compatible with EAP-PSK because of the security issues with AES-128. EAP-PSK' should therefore use a different EAP-Request/Response Type number. With the EAP-Request/Response Type number space structure defined in [3], this should not be a problem. The use of a different EAP-Request/Response Type number for EAP-PSK' will prevent this new method from being vulnerable to chosen protocol attacks.
EAP-PSKは、本質的にAES-128に依存しないように、他のブロック暗号を容易に、EAP-PSKのために提案することができます。 EAP-PSKが依存するAES-128の唯一のパラメータは、AES-128ブロックおよび鍵サイズ（16バイト）です。簡略化のため、EAP-PSKは、しかしながら、単一の必須のブロック暗号に制限し、他のブロック暗号のネゴシエーションを許可しないように選択されています。 AES-128は、セキュリティ上の理由のために廃止された場合に、EAP-PSKも廃止されるべきであり、カットアンドペーストEAP-PSK」は、他のブロック暗号を使用して定義されるべきです。このEAP-PSKは」理由はAES-128でのセキュリティ問題のEAP-PSKとの下位互換性があってはなりません。 EAP-PSKは、」したがって、異なるEAP要求/応答タイプ番号を使用する必要があります。で定義されたEAP要求/応答タイプ番号空間構造を持つ[3]、これが問題になることはありません。 EAP-PSKのためのさまざまなEAP-要求/応答タイプ番号」の使用は、選択されたプロトコル攻撃に対して脆弱であることから、この新しい方法を防ぐことができます。
EAP-PSK uses three cryptographic parts:
EAP-PSKは3つの暗号部品を使用しています：
o A key setup to derive AK and KDK from the PSK.
OキーセットアップはPSKからAKとKDKを導出します。
o An authenticated key exchange protocol to mutually authenticate the communicating parties and derive session keys.
O、認証鍵交換プロトコルは、相互に通信相手を認証し、セッションキーを導出します。
o A protected channel protocol for both mutually authenticated parties to communicate over.
O両方の相互認証の当事者のために保護されたチャネルプロトコルを介して通信します。
Each part is discussed in more detail in the subsequent paragraphs.
各部分は、後続の段落でより詳細に説明します。
EAP-PSK needs two cryptographically separated 16-byte subkeys for mutual authentication and session key derivation. Indeed, it is a rule of thumb in cryptography to use different keys for different applications.
EAP-PSKは、相互認証とセッション鍵導出用の2つの暗号化によって分離16バイトのサブキーを必要とします。確かに、アプリケーションごとに異なる鍵を使用する暗号技術における経験則です。
It could have implemented these two subkeys either by specifying a 32-byte PSK that would then be split in two 16-byte subkeys, or by specifying a 16-byte PSK that would then be cryptographically expanded to two 16-byte subkeys.
これは、2つの16バイトのサブキーに分割される32バイトのPSKを指定することにより、又はその後暗号2つの16バイトのサブキーに拡張される16バイトのPSKを指定することにより、いずれかのこれらの二つのサブキーを実装している可能性があります。
Because provisioning a 32-byte long-term credential is more cumbersome than a 16-byte one, and the strength of the derived session keys is 16 bytes either way, the latter option was chosen.
32バイトの長期資格情報をプロビジョニングする16バイトよりもより煩雑であり、誘導されたセッション鍵の強度が16バイトのいずれかの方法であるので、後者のオプションを選択しました。
Hence, the PSK is only used by EAP-PSK to derive AK and KDK. This derivation should be done only once, immediately after the PSK has been provisioned. As soon as AK and KDK have been derived, the PSK should be deleted. If the PSK is deleted, it should be done so securely (see, for instance, [19] for guidance on secure deletion of the PSK).
したがって、PSKのみAKとKDKを導出するためにEAP-PSKで使用されます。この導出は、PSKがプロビジョニングされた直後に、一度だけ実行する必要があります。すぐにAKとKDKが導き出されているとして、PSKを削除する必要があります。 PSKが削除された場合、それは（PSKの安全な削除に関するガイダンスのために[19]、例えば、参照）ので、確実に行われるべきです。
Derivation of AK and KDK from the PSK is called the key setup:
PSKからAKとKDKの導出は、キーのセットアップと呼ばれています。
o The input to the key setup is the PSK.
Oキー設定への入力はPSKです。
o The outputs of the key setup are AK and KDK.
キー設定の出力oをAKとKDKです。
AK and KDK are derived from the PSK using the modified counter mode of operation of AES-128. The modified counter mode is a length increasing function, i.e., it expands one AES-128 input block into a longer t-block output, where t>=2. This mode was chosen for the key setup because it had already been chosen for the derivation of the session keys (see Section 3.2).
AKとKDKは、AES-128の操作の改変カウンタ・モードを使用して、PSKから誘導されます。修飾されたカウンタモードは、長さ増加関数、すなわち、それはより長いT-ブロック出力、tは> = 2に1 AES-128の入力ブロックを拡張します。それはすでにセッションキーの導出のために選ばれていたので、このモードは、キー設定のために選択した（3.2節を参照してください）。
The details of the derivation of AK and KDK from the PSK are shown in Figure 3.
PSKからAKとKDKの導出の詳細は、図3に示されています。
+--------------------------+
| "0" |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(PSK,.) |
| |
+----------------+
|
|
+----------------------------+
| |
v v
+--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ |
| |
+----------------+ +----------------+
| | | |
| AES-128(PSK,.) | | AES-128(PSK,.) |
| | | |
+----------------+ +----------------+
| |
| |
v v
+------------------------+ +------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+------------------------+ +------------------------+
Figure 3: Derivation of AK and KDK from the PSK in Details
図3：詳細でPSKからAKとKDKの導出
The input block is "0". For the sake of simplicity, this input block has been chosen constant: it could have been set to a value depending on the peer and the server (for instance, the XOR of their respective NAIs appropriately truncated or zero-padded), but this did not seem to add much security to the scheme, whereas it added complexity. Any 16-byte constant could have been chosen, as the security is not supposed to depend on the particular value taken by the constant. "0" was arbitrarily chosen.
入力ブロックは「0」です。それは、ピアとサーバ（例えば、それぞれのNAIのXOR適宜切断又はゼロ詰め）に応じた値に設定されている可能性があり、これはなかった。簡単のため、この入力ブロックは、一定選択されていますそれは複雑さを追加しましたのに対し、スキームに多くのセキュリティを追加していないよう。セキュリティが定数で撮影した特定の値に依存することになっていないとして、任意の16バイトの定数は、選択された可能性があります。 「0」が任意に選ばれました。
The authentication protocol used by EAP-PSK is inspired by AKEP2, which is described in [14].
EAP-PSKで使用される認証プロトコルは、[14]に記載されてAKEP2、触発されます。
AKEP2 consists of a one-and-a-half round-trip exchange, as shown in Figure 4, which is inspired by Figure 5 of [14].
[14]の図5に触発されて、図4に示すようにAKEP2は一半往復交換から成ります。
Bob Alice
| RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Figure 4: Overview of AKEP2
図4：AKEP2の概要
It is also worth noting that [14] focuses on cryptography and not on designing a real-life protocol. Thus, as noted in subsection "Out-Of-Band-Data" of [14], Alice has to send A, its identity, to Bob so that Bob may select the appropriate credential for the sequel to the conversation. This leads to a slightly complemented version of AKEP2 for EAP-PSK as depicted in Figure 5.
[14]が暗号ではなく現実のプロトコルを設計に焦点を当てていることも注目に値します。 「アウト・オブ・バンド・データ」[14]の項で述べたようにこのように、アリスはボブが会話の続編のために適切な証明書を選択することができるように、ボブに、A、その識別情報を送信しなければなりません。これは、図5に示すようにEAP-PSK用AKEP2のわずかに補完バージョンをもたらします。
Bob Alice
| A||RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Figure 5: Overview of AKEP2
図5：AKEP2の概要
In AKEP2,
AKEP2で、
o RA and RB are random numbers chosen respectively by Alice and Bob.
O RAおよびRBは、アリス及びボブによってそれぞれ選択された乱数です。
o A and B are Alice's and Bob's respective identities. They allow Alice and Bob to retrieve the key that they have to use to run an authenticated key exchange between each other. They are also included in the protocol for cryptographic reasons.
O AとBはアリスのとボブのそれぞれのアイデンティティです。彼らは、アリスとボブは、彼らがお互いの間で認証鍵交換を実行するために使用する必要がキーを取得することができます。これらはまた、暗号化の理由のためのプロトコルに含まれています。
o The MACs (see Section 1.3 for the notation "[]") are calculated using a dedicated key.
MACはO（表記「[]」のセクション1.3を参照）は、専用キーを使用して計算されます。
EAP-PSK instantiates this protocol with:
EAP-PSKは、このプロトコルをインスタンス化します。
o The server as Alice and the peer as Bob.
アリスとボブのようなピアとしてサーバO。
o RA and RB as 16-byte random numbers, using Section 4.1 notations; this means RA=RAND_S and RB=RAND_P.
セクション4.1の表記を使用して16バイトの乱数としてO RAとRB;これは、RA = RAND_SとRB = RAND_Pを意味します。
o A and B as Alice's and Bob's respective NAIs, using Section 4.1 notations; this means A=ID_S and B=ID_P.
セクション4.1表記法を使用して、アリスとボブのそれぞれのNAIとしてA及びB O;これは、A = ID_S及びB = ID_Pを意味します。
o The MAC algorithm as CMAC with AES-128 using AK and producing a tag length of 16 bytes.
AKを使用して16バイトのタグ長を産生AES-128とCMACなどのMACアルゴリズムO。
o The modified counter mode of operation of AES-128 using KDK, to derive session keys as a result of this exchange.
この交換の結果としてセッションキーを導出するために、KDKを用いたAES-128の操作の改変カウンタモードO。
CMAC was chosen as the MAC algorithm because it is capable of handling arbitrary length messages, and its design is simple. It also enjoys up-to-date review by the cryptographic community, especially using provable security concepts. It has been recommended by the NIST. For a detailed description of CMAC, please refer to [8].
それは任意の長さのメッセージを処理することが可能であるため、CMACは、MACアルゴリズムとして選ばれた、そしてそのデザインはシンプルです。また、特に証明可能安全性の概念を使用して、暗号コミュニティによって最新のレビューを楽しんでいます。これは、NISTによって推奨されています。 CMACの詳細については、[8]を参照してください。
In AKEP2, the key exchange is "implicit": the session keys are derived from RB. In EAP-PSK, the session keys are thus derived from RAND_P by using KDK and the modified counter mode of operation of AES-128 described in [5]. This mode was chosen because it is a simple key derivation scheme that relies on a block cipher and has a proof of its security. It is a length increasing function, i.e., it expands one AES-128 input block into a longer t-block output, where t>=2. The derivation of the session keys is shown in Figure 6.
AKEP2では、鍵交換は、「暗黙的」である：セッションキーは、RBに由来しています。 EAP-PSKでは、セッション鍵は、このようにKDK及び[5]に記載のAES-128の操作の改変カウンタ・モードを使用してRAND_Pから誘導されます。それはブロック暗号に依存し、そのセキュリティの証拠を持っている簡単なキー導出スキームであるため、このモードが選択されました。これはすなわち、それは、T> = 2より長いTブロックの出力に1 AES-128入力ブロックを拡張し、長さ増加関数です。セッションキーの導出は、図6に示されています。
+--------------------------+ +-------------------------------+
| RAND_P | | KDK |
| Input Block (16 bytes) | | Key Derivation Key (16 bytes) |
+--------------------------+ +-------------------------------+
| |
v v
+-----------------------------------------------------------------+
| |
| Modified Counter Mode |
| |
+-----------------------------------------------------------------+
| | |
v v v
+------------+ +----------------------+ +----------------------+
| TEK | | MSK | | EMSK |
| (16 bytes) | | (64 bytes) | | (64 bytes) |
+------------+ +----------------------+ +----------------------+
Figure 6: Derivation of the Session Keys
図6：セッションキーの導出
The input to the derivation of the session keys is RAND_P.
セッションキーの導出への入力はRAND_Pです。
The outputs of the derivation of the session keys are:
セッションキーの導出の出力は、次のとおりです。
o The 16-byte TEK (the first output block).
16バイトのTEK（第一出力ブロック）O。
o The 64-byte MSK (the concatenation of the second to fifth output blocks).
O 64バイトMSK（第五の出力ブロックへの第2の連結）。
o The 64-byte EMSK (the concatenation of the sixth to ninth output blocks).
O 64バイトEMSK（第九の出力ブロックへの第六の連結）。
The details of the derivation of the session keys are shown in Figure 7.
セッションキーの導出の詳細は図7に示されています。
+--------------------------+
| RAND_P |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(KDK,.) |
| |
+----------------+
|
|
+---------------------+-- - - - - - - - - - --+
| | |
v v v
+--------+ +---+ +--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|.......| c9="9" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ | +--------+ |
| | |
+----------------+ +----------------+ +----------------+
| | | | | |
| AES-128(KDK,.) | | AES-128(KDK,.) |......| AES-128(KDK,.) |
| | | | | |
+----------------+ +----------------+ +----------------+
| | |
| | |
v v v
+-----------------+ +-----------------+ +------------------+
| Output Block #1 | | Output Block #2 | | Output Block #9 |
| (16 bytes) | | (16 bytes) |.....| (16 bytes) |
| TEK | | MSK (block 1/4) | | EMSK (block 4/4) |
+-----------------+ +-----------------+ +------------------+
Figure 7: Derivation of the Session Keys in Details
図7：詳細でのセッションキーの導出
The counter values are set respectively to the first t integers (that is, ci="i", with i=1 to 9).
カウンタ値は、（i付き= 1~9、つまり、CI =「I」）最初のTの整数にそれぞれ設定されています。
Keying material is sensitive information and should be handled accordingly (see Section 8.10 for further discussion).
材料を合わせることは、機密情報であり、（さらなる議論に関してセクション8.10を参照）に応じて扱われるべきです。
EAP-PSK provides a protected channel for both parties to communicate over, in case of a successful authentication. This protected channel is currently used to exchange protected result indications and may be used in the future to implement extensions.
EAP-PSKは、両当事者が認証成功の場合には、上で通信するための保護されたチャネルを提供します。この保護されたチャネルは、現在保護結果指摘を交換するために使用され、拡張を実装するために、将来的に使用することができます。
EAP-PSK uses the EAX mode of operation to provide this protected channel. For a detailed description of EAX, please refer to [4]. Figure 8 shows how EAX is used to implement EAP-PSK protected channel.
EAP-PSKは、この保護されたチャネルを提供するために、操作のEAXモードを使用します。 EAXの詳細については、[4]を参照してください。図8は、EAXがEAP-PSK保護チャネルを実装するために使用される方法を示しています。
+-----------+ +----------------+ +---------------------+ +----------+
| Nonce N | | Header H | | Plain Text Payload | | TEK |
| 4 bytes | | 22 bytes | | Variable length L | | 16 bytes |
+-----------+ +----------------+ +---------------------+ +----------+
| | | |
v v v v
+-------------------------------------------------------------------+
| |
| EAX |
| |
+-------------------------------------------------------------------+
| |
v v
+---------------------+ +----------+
| Cipher Text Payload | | Tag |
| Variable length L | | 16 bytes |
+---------------------+ +----------+
Figure 8: The Protected Channel
図8：保護されたチャンネル
This protected channel:
この保護されたチャネル：
o Provides replay protection.
oはリプレイ保護を提供します。
o Encrypts and authenticates a Plain Text Payload that becomes an Encrypted Payload. The Plain Text Payload must not exceed 960 bytes; see Sections 5.3, 5.4, and 8.11.
O暗号化し、暗号化されたペイロードになりますテキストペイロードを認証します。プレーンテキストペイロードは960のバイトを超えてはなりません。セクション5.3、5.4、および8.11を参照してください。
o Only authenticates a Header that is thus sent in clear.
Oのみが明らかに送られるヘッダーを認証します。
EAX is instantiated with AES-128 as the underlying block cipher.
EAXは、基礎となるブロック暗号として、AES-128でインスタンス化されます。
AES-128 is keyed with the TEK.
AES-128はTEKとキー止めされています。
The nonce N is used to provide cryptographic security to the encryption and data origin authentication as well as protection replay. Indeed, N is a 4-byte sequence number starting from <0> that is monotonically incremented at each EAP-PSK message within one EAP-PSK dialog, except retransmissions, of course.
ナンスNを暗号化し、データ発信元の認証だけでなく、保護リプレイへの暗号化セキュリティを提供するために使用されます。実際、Nは単調1 EAP-PSKダイアログ内で、再送除く、コースの各EAP-PSKメッセージで増分される<0>から始まる4バイトのシーケンス番号です。
N was taken to be 4 bytes to avoid 16-byte arithmetic. Since EAX uses a 16-byte nonce, N is padded with 96 zero bits for its high-order bits.
Nは、16バイトの演算を回避するために4バイトとしました。 EAXは、16バイトnonceを使用するので、Nはその上位ビット96がゼロビットでパディングされます。
For cryptographic reasons, N is not allowed to wrap around. In the unlikely, yet possible, event of the server sending an EAP-PSK message with N set to <2**32-2>, it must not send any further message on this protected channel, which would cause to reusing the value 0. Either the conversation is finished after the server receives the EAP-PSK answer from the peer with N set to <2**32-1> and the server proceeds (typically by sending an EAP-Success or Failure), or the conversation is not finished and must then be aborted (a new EAP-PSK dialog may subsequently be started to try again to authenticate). Thus, the maximum number of messages that can be exchanged over the same protected channel is 2**32 (which should not be a limitation in practice, as this is approximately equal to 4 billion).
暗号化の理由により、Nは、ラップアラウンドすることはできません。 NでEAP-PSKメッセージを送信するサーバの可能性は低い、まだでき、イベントは<2 ** 32-2>に設定するには、それは値0を再利用する原因と思われる、この保護されたチャネル上の任意の更なるメッセージを送信してはなりませんサーバがNとのピアからのEAP-PSKの答えは<** 32-1 2>に設定受信した後に会話が終了されるか、サーバが進行する（典型的には、EAP-成否を送信することによって）、または会話であります終了してから（新しいEAP-PSK]ダイアログがその後の認証を再試行するために開始することができる）中止されなければなりません。 （これは40億にほぼ等しくなるように、実際に制限すべきではない）このように、同一の保護チャネルを介して交換することができるメッセージの最大数は、2 ** 32です。
The Header H consists of the first 22 bytes of the EAP Request or Response packet (i.e., the EAP Code, Identifier, Length, and Type fields followed by the EAP-PSK Flags and RAND_S fields). Although it may appear unorthodox that an upper layer (EAP-PSK) protects some information of the lower layer (EAP), this was chosen to comply with EAP recommendation (see Section 7.5. of [3]) and seems to be existing practice at IETF (see, for instance, [35]).
ヘッダHは、EAP要求または応答パケット（EAP-PSKフラグとRAND_Sフィールド続い即ち、EAPコード、識別子、長さ、タイプフィールド）の最初の22バイトから成ります。それは上層（EAP-PSK）は下層（EAP）のいくつかの情報を保護すること非正統的な見えるかもしれないが、これはEAP勧告に準拠するように選択された（7.5節を参照。[3]の）と思われる既存する練習にIETF（[35]、例えば、参照）。
The Plain Text Payload is the payload that is to be encrypted and integrity protected. The Cipher Text Payload is the result of the encryption of the Plain Text.
プレーンテキストペイロードは暗号化と完全性を保護するペイロードです。暗号テキストペイロードはプレーンテキストの暗号化の結果です。
The Tag is a MAC that protects both the Header and the Plain Text Payload. The verification of the Tag must only be done after a successful verification of the Nonce for replay protection. If the verification of the Tag succeeds, then the Encrypted Payload is decrypted to recover the Plain Text Payload. If the verification of the Tag fails, then no decryption is performed and this MAC failure should be logged. The tag length is chosen to be 16 bytes for EAX within EAP-PSK. This length is considered appropriate by the cryptographic community.
タグは、ヘッダーとテキストのペイロードの両方を保護するMACです。タグの検証はリプレイ保護のためのノンスの検証が成功した後に行わなければなりません。タグの検証が成功した場合、暗号化されたペイロードは、プレーンテキストのペイロードを回復するために復号化されます。タグの検証が失敗した場合、何の復号化は行われず、このMACの失敗がログに記録されなければなりません。タグ長はEAP-PSK内EAXのために16バイトとなるように選択されます。この長さは、暗号コミュニティによって適切であると考えられます。
EAX was mainly chosen because:
EAXを主な理由に選ばれました。
o It strongly relies on OMAC in its design and OMAC1, a variant of OMAC, had already been chosen in EAP-PSK for the authentication part (please remember that OMAC1 and CMAC are analogous).
それは強く、そのデザインとOMAC1、OMACの変種でOMACに依存しているO、すでに（OMAC1とCMACが類似していることを忘れないでください）認証部のためのEAP-PSKで選択されていました。
o Its design is simple.
Oそのデザインはシンプルです。
o It enjoys a security proof.
Oそれはセキュリティ証明を楽しんでいます。
o It is free of any Intellectual Property Rights claims.
Oこれは、任意の知的財産権の特許請求の範囲の自由です。
EAP-PSK may consist of two different types of message flows:
EAP-PSKは、二つの異なるタイプのメッセージ・フローのからなることができます。
o The "standard authentication", which is:
である「標準認証」、O：
* Mandatory to implement.
*実装が必須。
* Fully specified in this document.
*完全にこの文書で指定されました。
* The simpler type of message flow, which is expected to be used most frequently.
*最も頻繁に使用されることが予想されるメッセージフローの簡単なタイプ。
o The "extended authentication", which is:
である「拡張認証」、O：
* Optional to implement (i.e., there are no mandatory extensions).
*実装するオプション（つまり、何も必須の拡張機能はありません）。
* Partly specified in this document since it depends on extensions and none are currently specified, let alone in this document.
*それは拡張子に依存するため、部分的に、この文書で指定され、いずれも現在、このドキュメントではおろか、指定されていません。
* The type of message flow that should be used when extensions of EAP-PSK are needed by more sophisticated usage scenarios and are available.
* EAP-PSKの拡張がより洗練された使用シナリオで必要とされている利用可能なときに使用するメッセージ・フローのタイプ。
EAP-PSK introduces the concept of a session to facilitate its analysis and provide a cleaner interface to other layers. A session is a particular instance of an EAP-PSK dialog between two parties. This session is identified by a session identifier.
EAP-PSKは、その分析を容易にし、他の層にクリーンインターフェースを提供するために、セッションの概念を導入します。セッションは、二つの当事者間のEAP-PSKダイアログの特定のインスタンスです。このセッションは、セッション識別子によって識別されます。
In the first EAP-PSK message, the EAP server asserts its identity. Given that the EAP-Request/Identity and EAP-Response/Identity may not be assumed to have occurred prior to this sending and that the response included in EAP-Response/Identity (if this EAP Identity exchange takes place) may not contain the actual NAI the peer shall use with EAP-PSK, this means that an EAP server implementing EAP-PSK must use the same EAP server NAI for all EAP-PSK dialogs with any EAP peer implementing EAP-PSK.
最初のEAP-PSKメッセージでは、EAPサーバは、そのアイデンティティを主張します。 EAP要求/アイデンティティおよびEAP応答/アイデンティティは、この前の送信に発生したと想定し、（このEAPアイデンティティ交換が行われた場合）、応答はEAP応答/アイデンティティに含まれることがないかもしれないことを考えると、実際に含めることはできませんNAIは、EAP-PSKで使用しなければならないピアが、これはEAP-PSKを実装するEAPサーバがEAP-PSKを実装する任意のEAPピアとのすべてのEAP-PSKダイアログに同じEAPサーバNAIを使用しなければならないことを意味します。
EAP-PSK standard authentication is comprised of four messages, i.e., two round-trips; see Figure 9.
EAP-PSK標準の認証は、4つのメッセージ、すなわち2つのラウンドトリップで構成されています。図9を参照してください。
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0 |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1 |
|--------------------------------------------------------->|
| |
Figure 9: EAP-PSK Standard Authentication
図9：EAP-PSK標準認証
o The first message is sent by the server to the peer to:
Oの最初のメッセージをピアにするサーバによって送信されます。
* Send a 16-byte random challenge (RAND_S). RAND_S was called RA in Section 3.2
* 16バイトのランダムチャレンジ（RAND_S）を送信します。 RAND_Sは、3.2節でRAと呼ばれていました
* State its identity (ID_S). ID_S was denoted by A in Section 3.2.
*そのアイデンティティ（ID_S）の状態。 ID_Sは、3.2節でAで示されました。
o The second message is sent by the peer to the server to:
O第2のメッセージをするためにサーバにピアによって送信されます。
* Send another 16-byte random challenge (RAND_P). RAND_P was called RB in Section 3.2
*別の16バイトのランダムチャレンジ（RAND_P）を送信します。 RAND_Pは、3.2節でRBと呼ばれていました
* State its identity (ID_P). ID_P was denoted by B in Section 3.2.
*そのアイデンティティ（ID_P）の状態。 ID_Pは、3.2節でBで示されました。
* Authenticate to the server by proving that it is able to compute a particular MAC (MAC_P), which is a function of the two challenges and AK: MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)
* 2つの課題とAKの関数である、特定のMAC（MAC_P）を計算することが可能であることを証明することにより、サーバの認証：MAC_P = CMAC-AES-128（AK、ID_P || || ID_S RAND_S || RAND_P）
o The third message is sent by the server to the peer to:
O第3のメッセージは、ピアのにサーバによって送信されます。
* Authenticate to the peer by proving that it is able to compute another MAC (MAC_S), which is a function of the peer's challenge and AK: MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)
*他のピアの挑戦の関数であるMAC（MAC_S）、及びAKを計算することが可能であることを証明することによってピアに認証：MAC_S = CMAC-AES-128（AK、ID_S || RAND_P）
* Set up the protected channel (P_CHANNEL_S_0) to:
*に保護されたチャネル（P_CHANNEL_S_0）を設定します。
+ Confirm that it has derived session keys (at least the TEK).
+それは（少なくともTEK）をセッションキーを派生していることを確認してください。
+ Give a protected result indication of the authentication.
+認証の保護された結果指示を与えます。
o The fourth message is sent by the peer to the server to finish the setup of the protected channel (P_CHANNEL_P_1) to:
O第4のメッセージは保護チャネル（P_CHANNEL_P_1）への設定を完了するためにサーバにピアによって送信されます。
* Confirm that it has derived session keys (at least the TEK).
*それは（少なくともTEK）をセッションキーを導出していることを確認してください。
* Give a protected result indication of the authentication.
*認証の保護された結果指示を与えます。
The PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and fourth EAP-PSK messages contain a MAC-computed thanks to TEK that protects the integrity of the messages. For a detailed list of the fields of the messages that are integrity protected, please refer to Section 3.3.
第三及び第四のEAP-PSKメッセージのPCHANNEL_S_0とPCHANNEL_P_1フィールドは、メッセージの完全性を保護TEKにMAC-計算感謝を含んでいます。完全性保護されたメッセージのフィールドの詳細なリストについては、3.3節を参照してください。
All EAP-PSK messages include a sort of header, which is comprised of two fields:
すべてのEAP-PSKメッセージは2つのフィールドで構成され、ヘッダの種類を含みます。
o Flags, a 1-byte field that is currently only used to number EAP-PSK messages.
Oフラグ、現在は数EAP-PSKメッセージに使用される1バイトのフィールド。
o RAND_S, a 16-byte challenge sent by the server that is used as a session identifier.
O RAND_S、セッション識別子として使用されているサーバーから送信された16バイトのチャレンジ。
This standard message flow could be comprised of only three messages, like AKEP2, were it not the request/response nature of EAP that prevents the third message to be the last one. Since the fourth message is mandatory, EAP-PSK chose to take advantage of this and set up a protected channel.
この標準メッセージ・フローはAKEP2のように、最後の一つであることが第3のメッセージを防ぎEAPの要求/応答の性質は、それをなかった、唯一の3つのメッセージで構成することができます。第4のメッセージは必須であるため、EAP-PSKは、これを利用し、保護されたチャネルを設定することを選びました。
The standard message flow also includes a statement by the peer of its identity, in addition to the EAP-Response/Identity it may have sent. This behavior follows Section 5.1 of [3], which recommends that the EAP-Response/Identity be used primarily for routing purposes and selecting which EAP method to use, and therefore that EAP methods include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.
標準メッセージ・フローはまた、そのアイデンティティのピアの声明、EAP応答/アイデンティティに加えて、それが送信された可能性を含んでいます。この現象は、そう、EAPメソッドは、識別情報を取得するためのメソッド固有の機構を含むことがEAP応答/アイデンティティは、主にEAPメソッドを使用する目的と選択をルーティングするために使用することをお勧めします、そして、[3]のセクション5.1を、以下彼らはアイデンティティ応答に依存する必要がないこと。
When a party receives an EAP-PSK message, it checks that the message is syntactically valid in accordance with the message formats defined in Section 5. If the message is syntactically incorrect, then it is silently discarded. Then it checks the cryptographic validity of this message, i.e., it checks the MAC(s) as follows:
当事者がEAP-PSKメッセージを受信すると、メッセージが文法的に間違っている場合は、メッセージが第5節で定義されたメッセージフォーマットに従って構文的に有効である、それは静かに破棄されていることを確認します。それは次のように、すなわち、それはMAC（複数可）をチェックし、このメッセージの暗号化有効性をチェック：
o If the received message is the first EAP-PSK message, there is no MAC to check as none is included in message 1.
受信したメッセージが最初のEAP-PSKメッセージである場合、O、どのMACは何もメッセージ1に含まれないようにチェックすることがありません。
o If the received message is the second EAP-PSK message, the validity of MAC_P is checked.
受信したメッセージが第EAP-PSKメッセージである場合、O、MAC_Pの妥当性がチェックされます。
o If the received message is the third EAP-PSK message, the validity of MAC_S is checked and then the validity of the Tag included in P_CHANNEL_S_0 is checked. The validity checks must be done in this order to avoid unnecessarily deriving TEK, MSK, and EMSK in case MAC_S is invalid, meaning that mutual authentication has failed. Indeed, TEK is used to verify the validity of the Tag included in P_CHANNEL_S_0.
受信したメッセージが第三のEAP-PSKメッセージである場合、O、MAC_Sの妥当性がチェックされ、その後、P_CHANNEL_S_0に含まれるタグの妥当性がチェックされます。妥当性チェックがMAC_Sは、相互認証が失敗したことを意味し、無効である場合にはTEK、MSK、およびEMSKを引き出す不必要に避けるために、この順序で行う必要があります。確かに、TEKはP_CHANNEL_S_0に含まれるタグの妥当性を検証するために使用されます。
o If the received message is the fourth EAP-PSK message, the validity of the Tag included in P_CHANNEL_P_1 is checked.
受信したメッセージが第四EAP-PSKメッセージである場合には、O、P_CHANNEL_P_1に含まれるタグの妥当性がチェックされます。
If a validity check fails, the message is silently discarded. There can be a counter to track the number of silently discarded messages Section 8.8. If there is an encrypted payload in the message (namely, in the PCHANNEL attribute), then the encrypted payload is decrypted. Then, if the decrypted payload is syntactically incorrect, the message is silently discarded.
妥当性チェックが失敗した場合、メッセージは静かに捨てられます。黙って破棄されたメッセージの8.8節の数を追跡するカウンタが存在する場合があります。メッセージ内の暗号化されたペイロードがある場合（すなわち、Pチャネル属性に）、次いで、暗号化されたペイロードが復号化されます。復号化されたペイロードが文法的に間違っている場合はその後、メッセージは静かに捨てられます。
To remain simple and yet be extensible to meet future requirements, EAP-PSK provides an extension mechanism within its protected channel: the payload of the protected channel may contain an optional extension field (EXT).
単純なままであり、まだ将来の要求を満たすために拡張できるように、EAP-PSKは、その保護されたチャネル内の拡張メカニズムを提供する：保護されたチャネルのペイロードは、オプションの拡張フィールド（EXT）を含んでいてもよいです。
Figure 10 presents the message sequence for EAP-PSK extended authentication.
図10は、EAP-PSK拡張認証のためのメッセージシーケンスを示します。
Extended authentication MUST be supported, i.e., any EAP-PSK implementation MUST support sending and reception of an EXT attribute according to rules of operation described in Section 6. Yet, although support of the EXT field is mandatory, there is no mandatory extension type to support. This means that if a server engages in EAP-PSK extended authentication, as only the server can start extended authentication per Section 6, a peer will recognize the attempt to start extended authentication through its EXT support. If the peer does not support the particular extension type used by the server, the peer will still be able to conclude the EAP-PSK dialog.
拡張認証はEXTフィールドのサポートは必須であるが、への必須の拡張型が存在しない、すなわち、任意のEAP-PSKの実装がまだ項6に記載の操作の規則に従って送信及びEXT属性の受信サポートしなければならない、サポートしなければなりませんサポート。これは、サーバが第6節ごとの拡張認証、同輩がEXTのサポートを通じて拡張認証を開始しようとする試みを認識し始めることができるよう、サーバがEAP-PSKに従事している場合、認証を拡張することを意味します。ピアは、サーバによって使用される特定の拡張子の種類をサポートしていない場合、ピアはまだEAP-PSK]ダイアログを締結することができるようになります。
The mandatory support of the EXT field is dictated:
EXTフィールドの必須サポートが決定されます：
o To guarantee a robust behavior in the future where some peers might support some extensions and others not. All peers will thus be able to understand that an extended authentication is being attempted and indicate whether or not they support the extension that is tried.
いくつかのピアは、いくつかの拡張機能や他の人ではないがサポートされる場合があり、将来的に堅牢な動作を保証するために、O。すべてのピアは、このように拡張認証を試み、彼らが試されている拡張機能をサポートしているか否かを示していることを理解することができるようになります。
o To ensure that all implementations will indeed be extensible.
すべての実装が実際に拡張可能になることを保証するために、O。
No extension is currently defined.
拡張子は、現在定義されていません。
At most, one extension may be run within a single EAP-PSK dialog: there can neither be sequences of extensions nor interleaved extensions. However, extensions may take a variable number of round-trips to complete.
せいぜい、1つの拡張子は、単一のEAP-PSK]ダイアログボックス内で実行することがあります。どちらも伸長もインターリーブされた拡張子のシーケンスはあり得ません。ただし、拡張子が完了するのラウンドトリップの可変数を取ることがあります。
Only the server can start an extension and, if it does so, it must start it in the first payload it sends over the protected channel.
サーバだけが拡張を開始することができ、それがそうならば、それが保護されたチャネルを介して送信最初のペイロードにそれを起動する必要があります。
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1(EXT) |
|--------------------------------------------------------->|
| |
. .
. .
. .
| Flags||RAND_S||PCHANNEL_S_2i(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_2i+1(EXT) |
|--------------------------------------------------------->|
| |
Figure 10: EAP-PSK Extended Authentication
図10：EAP-PSK拡張認証
Please refer to Section 6 for more details on how extended authentication works.
認証の仕組みの拡張の詳細については、セクション6を参照してください。
The PCHANNEL_S_2j and PCHANNEL_P_2j+1 fields of the EAP-PSK messages (where j varies from 0 to i) contain a MAC-computed thanks to TEK that protects the integrity of the messages. For a detailed list of the fields of the messages that are integrity protected, please refer to Section 3.3.
（jは0からIへの変化）EAP-PSKメッセージのPCHANNEL_S_2jとPCHANNEL_P_2j + 1のフィールドは、メッセージの完全性を保護するTEKにMAC計算おかげ含みます。完全性保護されたメッセージのフィールドの詳細なリストについては、3.3節を参照してください。
When a party receives an EAP-PSK message, it checks that the message is syntactically valid in accordance with the message formats defined in Section 5. If the message is syntactically incorrect, then it is silently discarded. Then it checks the cryptographic validity of this message, i.e., it checks the MAC(s) as follows:
当事者がEAP-PSKメッセージを受信すると、メッセージが文法的に間違っている場合は、メッセージが第5節で定義されたメッセージフォーマットに従って構文的に有効である、それは静かに破棄されていることを確認します。それは次のように、すなわち、それはMAC（複数可）をチェックし、このメッセージの暗号化有効性をチェック：
o If the received message is the first EAP-PSK message, there is no MAC to check as none is included in message 1.
受信したメッセージが最初のEAP-PSKメッセージである場合、O、どのMACは何もメッセージ1に含まれないようにチェックすることがありません。
o If the received message is the second EAP-PSK message, the validity of MAC_P is checked.
受信したメッセージが第EAP-PSKメッセージである場合、O、MAC_Pの妥当性がチェックされます。
o If the received message is the third EAP-PSK message, the validity of MAC_S is checked and then the validity of the Tag included in P_CHANNEL_S_0 is checked. The validity checks must be done in this order to avoid unnecessarily deriving TEK, MSK, and EMSK in case MAC_S is invalid, meaning that mutual authentication has failed. Indeed, TEK is used to verify the validity of the Tag included in P_CHANNEL_S_0.
受信したメッセージが第三のEAP-PSKメッセージである場合、O、MAC_Sの妥当性がチェックされ、その後、P_CHANNEL_S_0に含まれるタグの妥当性がチェックされます。妥当性チェックがMAC_Sは、相互認証が失敗したことを意味し、無効である場合にはTEK、MSK、およびEMSKを引き出す不必要に避けるために、この順序で行う必要があります。確かに、TEKはP_CHANNEL_S_0に含まれるタグの妥当性を検証するために使用されます。
o If the received message is the fourth EAP-PSK message, the validity of the Tag included in P_CHANNEL_P_1 is checked.
受信したメッセージが第四EAP-PSKメッセージである場合には、O、P_CHANNEL_P_1に含まれるタグの妥当性がチェックされます。
o If the received message is an EAP-PSK message different from the first four ones, then validity of the Tag included in P_CHANNEL is checked.
受信したメッセージが最初の4つのものとは異なるEAP-PSKメッセージである場合、O、P_CHANNELに含まれるタグの次に、妥当性がチェックされます。
If a validity check fails, the message is silently discarded. There can be a counter to track the number of silently discarded messages Section 8.8. If there is an encrypted payload in the message (namely in the PCHANNEL attribute), then the encrypted payload is decrypted. Then, if the decrypted payload is syntactically incorrect, the message is silently discarded.
妥当性チェックが失敗した場合、メッセージは静かに捨てられます。黙って破棄されたメッセージの8.8節の数を追跡するカウンタが存在する場合があります。 （すなわち、Pチャネル属性で）メッセージ内の暗号化ペイロードがある場合、暗号化されたペイロードが復号化されます。復号化されたペイロードが文法的に間違っている場合はその後、メッセージは静かに捨てられます。
For the sake of simplicity, EAP-PSK uses a fixed message format. There are four different types of EAP-PSK messages:
簡略化のため、EAP-PSKは、固定されたメッセージフォーマットを使用します。 EAP-PSKメッセージの4種類があります。
o The first EAP-PSK message, which is sent by the server to the peer.
ピアにサーバーによって送信される最初のEAP-PSKメッセージ、O。
o The second EAP-PSK message, which is sent by the peer to the server.
サーバにピアによって送信される第二EAP-PSKメッセージ、O。
o The third EAP-PSK message, which is sent by the server to the peer.
ピアにサーバーによって送信される第三のEAP-PSKメッセージ、O。
o The fourth EAP-PSK message, which is sent by the peer to the server. This is also the type of message that the peer further sends to the server in case of an extended authentication. This is also essentially the type of message that the server further sends to the peer in case of an extended authentication: the only slight modification that occurs in this last case is the setting of the EAP Code to 1 instead of 2 in the other cases.
サーバにピアによって送信される第四のEAP-PSKメッセージ、O。これはまた、ピアがさらに拡張認証の場合には、サーバに送信するメッセージのタイプです。この最後の場合に発生するわずかな変更は1の代わりに、他の場合には2にEAPコードの設定である：これは、本質的に、サーバは、さらに、拡張認証の場合には、ピアに送信されるメッセージのタイプです。
For the sake of clarity, the whole EAP packet that encapsulates the EAP-PSK message (i.e., the EAP-PSK message plus its EAP headers) is depicted in Figures 11, 13, 14, and 18.
明確にするために、EAP-PSKメッセージ（すなわち、EAP-PSKメッセージプラスのEAPヘッダー）をカプセル化全EAPパケットは、図11、図13、図14、及び図18に示されています。
The first EAP-PSK message is sent by the server to the peer. It has the format presented in Figure 11.
最初のEAP-PSKメッセージがピアにサーバーによって送信されます。これは、図11に提示形式を持っています。
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
: ID_S :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: EAP-PSK First Message
図11：EAP-PSK最初のメッセージ
Since IANA has allocated EAP method type 47 for EAP-PSK, Type EAP-PSK for the first EAP-PSK message as well as any other EAP-PSK message MUST be 47.
IANAのでEAP-PSK、最初のEAP-PSKメッセージのタイプEAP-PSK、ならびに任意の他のEAP-PSKメッセージは47でなければなりませんためのEAPメソッドタイプ47を割り当てました。
The first EAP-PSK message consists of:
最初のEAP-PSKメッセージがで構成されています。
o A 1-byte Flags field
1バイトのフラグフィールドO
o A 16-byte random number: RAND_S
RAND_S：16バイトの乱数O
o A variable length field that conveys the server's NAI: ID_S. The length of this field is deduced from the EAP length field. The length of this NAI must not exceed 966 bytes. This restriction aims at avoiding fragmentation issues (see Section 8.11).
OサーバーのNAIを伝える可変長フィールド：ID_S。このフィールドの長さは、EAP長フィールドから推定されます。このNAIの長さが966のバイトを超えてはなりません。この制限は、断片化の問題を（セクション8.11を参照）を回避することを目的とします。
The Flags field has the format presented in Figure 12.
Flagsフィールドは、図12に提示形式を持っています。
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| T | Reserved |
+-+-+-+-+-+-+-+-+
Figure 12: EAP-PSK Flags Field
図12：EAP-PSKフラグフィールド
The Flags field is comprised of two subfields:
Flagsフィールドは、2つのサブフィールドで構成されています。
o A 2-bit T subfield, which indicates the type of EAP-PSK message:
EAP-PSKメッセージのタイプを示す2ビットのTサブフィールド、O：
* T=0 for the first EAP-PSK message presented in Section 5.1.
*セクション5.1に提示最初のEAP-PSKメッセージのT = 0。
* T=1 for the second EAP-PSK message presented in Section 5.2.
*セクション5.2に提示第EAP-PSKメッセージのT = 1。
* T=2 for the third EAP-PSK message presented in Section 5.3.
*セクション5.3に提示第EAP-PSKメッセージのT = 2。
* T=3 for the fourth EAP-PSK message presented in Section 5.4 and the subsequent EAP-PSK messages that may be exchanged during extended authentication.
拡張認証時に交換することができる5.4とその後のEAP-PSKメッセージで提示第EAP-PSKメッセージのため* T = 3。
o A 6-bit Reserved subfield that is set to zero on transmission and ignored on reception.
送信にゼロに設定され、受信時には無視される6ビットのReservedサブフィールドO。
The PCHANNEL Nonce field N (see Section 5.3) is used to distinguish between the different EAP-PSK messages that may be exchanged during extended authentication that all have T set to 3, i.e., the fourth EAP-PSK message and possibly the next ones.
PチャネルナンスフィールドNは（セクション5.3を参照）は、すべてのTは3に設定されている拡張認証、すなわち、第四のEAP-PSKメッセージおよびおそらく次のものの間に交換されてもよい異なるEAP-PSKメッセージを区別するために使用されます。
The second EAP-PSK message is sent by the peer to the server. It has the format presented in Figure 13.
第二EAP-PSKメッセージがサーバにピアによって送信されます。これは図13に提示フォーマットを有します。
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: ID_P :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: EAP-PSK Second Message
図13：EAP-PSK第2のメッセージ
It consists of:
これは、で構成されています。
o A 1-byte Flags field
1バイトのフラグフィールドO
o The 16-byte random number sent by the server in the first EAP-PSK message (RAND_S) that serves as a session identifier
セッション識別子となる第1のEAP-PSKメッセージ（RAND_S）にサーバーによって送信された16バイトの乱数O
o A 16-byte random number: RAND_P
RAND_P：16バイトの乱数O
o A 16-byte MAC: MAC_P
O 16バイトのMAC：MAC_P
o A variable length field that conveys the peer's NAI: ID_P. The length of this field is deduced from the EAP length field. The length of this NAI must not exceed 966 bytes. This restriction aims at avoiding fragmentation issues (see Section 8.11).
ID_P：ピアのNAIを伝える可変長フィールドO。このフィールドの長さは、EAP長フィールドから推定されます。このNAIの長さが966のバイトを超えてはなりません。この制限は、断片化の問題を（セクション8.11を参照）を回避することを目的とします。
The Flags field format is presented in Figure 12.
Flagsフィールド形式は、図12に示されています。
The third EAP-PSK message is sent by the server to the peer. It has the format presented in Figure 14.
第三のEAP-PSKメッセージがピアにサーバーによって送信されます。これは、図14に提示形式を持っています。
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: EAP-PSK Third Message
図14：EAP-PSK、第3のメッセージ
It consists of:
これは、で構成されています。
o A 1-byte Flags field
1バイトのフラグフィールドO
o The 16-byte random number sent by the server in the first EAP-PSK message (RAND_S) that is used as a session identifier
セッション識別子として使用される第一のEAP-PSKメッセージにサーバーによって送信された16バイトの乱数（RAND_S）O
o A 16-byte MAC: MAC_S
16バイトのMAC O：MAC_S
o A variable length field that constitutes the protected channel: PCHANNEL
O保護されたチャネルを構成する可変長フィールド：P CHANNEL
The Flags field format is presented in Figure 12.
Flagsフィールド形式は、図12に示されています。
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:
拡張子がない場合は、認証が標準である場合、すなわち、pチャネルフィールドの構成は次のとおりです。
o A 4-byte Nonce N (see Section 3.3).
4バイトのノンスN O（3.3節を参照）。
o A 16-byte Tag (see Section 3.3).
16バイトのタグO（3.3節を参照してください）。
o A 2-bit result indication flag R.
O 2ビット結果指示フラグR.
o A 1-bit extension flag E, which is set to 0.
0に設定されている1ビットの拡張フラグE、O。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
発光にゼロに設定され、受信時には無視される5ビットのReservedフィールド、O。
R, E, and Reserved are sent encrypted by the protected channel (see Section 3.3).
R、E、及びリザーブが保護チャネルにより暗号化されて送信される（セクション3.3参照）。
If there is no extension, PCHANNEL has the format presented in Figure 15 (where R, E, and Reserved are presented in the clear for the sake of clarity, although in reality they are sent encrypted).
拡張子がない場合（実際には、それらが暗号化されて送信されているが、R、E、および予約を明確にするために明確に提示されている）、Pチャネルは、図15に提示フォーマットを有します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |0| Reserved|
+-+-+-+-+-+-+-+-+
Figure 15: The PCHANNEL Field with E=0
図15：E = 0とPチャネルフィールド
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:
拡張がある場合、認証が拡張された場合、すなわち、Pチャネル・フィールドは、から構成されています。
o A 4-byte Nonce N (see Section 3.3).
4バイトのノンスN O（3.3節を参照）。
o A 16-byte Tag (see Section 3.3).
16バイトのタグO（3.3節を参照してください）。
o A 2-bit result indication flag R.
O 2ビット結果指示フラグR.
o A 1-bit extension flag E, which is set to 1.
1に設定されている1ビットの拡張フラグE、O。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
発光にゼロに設定され、受信時には無視される5ビットのReservedフィールド、O。
o A variable length EXT field.
可変長EXTフィールドO。
R, E, Reserved, and EXT are sent encrypted by the protected channel (see Section 3.3).
R、E、予約、およびEXTは保護チャネルにより暗号化されて送信される（セクション3.3参照）。
If there is an extension, PCHANNEL has the format presented in Figure 16 where R, E, Reserved and EXT are presented in the clear for the sake of clarity, although in reality they are sent encrypted).
拡張がある場合、実際には、それらが暗号化されて送信されているが、Pチャネル）は、R、E、予約さEXTは、明確化のために明確に示されている図16に提示フォーマットを有します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |1| Reserved| |
+-+-+-+-+-+-+-+-+ +
: EXT :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: The PCHANNEL Field with E=1
図16：E = 1とPチャネルフィールド
This EXT field is split in two subfields:
このEXTフィールドは、2つのサブフィールドに分割されます。
o The EXT_Type subfield, which indicates the type of the extension
拡張のタイプを示すEXT_Typeサブフィールド、O
o The EXT_Payload subfield, which consists of the payload of the extension. The EXT_Payload length is derived from the EAP Length field. EXT_Payload must have a bit length that is a multiple of 8 bits and must not exceed 960 bytes. The latter restriction aims at avoiding fragmentation issues (see Section 8.11), whereas the former comes from the EAP length being specified in bytes.
拡張のペイロードから成るEXT_Payloadサブフィールド、O。 EXT_Payload長はEAP長フィールドから導出されます。 EXT_Payloadは8ビットの倍数であり、960のバイトを超えないビット長さを有していなければなりません。前者はバイト単位で指定されたEAPの長さから来ているのに対し、後者の制限は、（セクション8.11を参照）断片化の問題を回避することを目的とします。
The format of the EXT field is presented in Figure 17.
EXTフィールドのフォーマットは図17に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXT_Type | |
+-+-+-+-+-+-+-+-+ +
: EXT_Payload :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The EXT Field
図17：EXTフィールド
The fourth EAP-PSK message is sent by the peer to the server. It has the format presented in Figure 18.
第四のEAP-PSKメッセージがサーバにピアによって送信されます。これは、図18に提示形式を持っています。
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: EAP-PSK Fourth Message
図18：EAP-PSK 4番目のメッセージ
It consists of:
これは、で構成されています。
o A 1-byte Flags field
1バイトのフラグフィールドO
o The 16-byte random number sent by the server in the first EAP-PSK message (RAND_S) that is used as a session identifier
セッション識別子として使用される第一のEAP-PSKメッセージにサーバーによって送信された16バイトの乱数（RAND_S）O
o A variable length field that constitutes the protected channel: PCHANNEL
O保護されたチャネルを構成する可変長フィールド：P CHANNEL
The Flags field format is presented in Figure 12.
Flagsフィールド形式は、図12に示されています。
The PCHANNEL field has the following structure, which was already described in Section 5.3.
pチャネルフィールドは、すでに5.3節で説明した次のような構造を持っています。
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:
拡張子がない場合は、認証が標準である場合、すなわち、pチャネルフィールドの構成は次のとおりです。
o A 4-byte Nonce N (see Section 3.3).
4バイトのノンスN O（3.3節を参照）。
o A 16-byte Tag (see Section 3.3).
16バイトのタグO（3.3節を参照してください）。
o A 2-bit result indication flag R.
O 2ビット結果指示フラグR.
o A 1-bit extension flag E, which is set to 0.
0に設定されている1ビットの拡張フラグE、O。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
発光にゼロに設定され、受信時には無視される5ビットのReservedフィールド、O。
R, E, and Reserved are sent encrypted by the protected channel (see Section 3.3).
R、E、及びリザーブが保護チャネルにより暗号化されて送信される（セクション3.3参照）。
If there is no extension, PCHANNEL has the format presented in Figure 15.
拡張子がない場合は、Pチャネルは、図15に提示形式を持っています。
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:
拡張がある場合、認証が拡張された場合、すなわち、Pチャネル・フィールドは、から構成されています。
o A 4-byte Nonce N (see Section 3.3).
4バイトのノンスN O（3.3節を参照）。
o A 16-byte Tag (see Section 3.3).
16バイトのタグO（3.3節を参照してください）。
o A 2-bit result indication flag R.
O 2ビット結果指示フラグR.
o A 1-bit extension flag E, which is set to 1.
1に設定されている1ビットの拡張フラグE、O。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
発光にゼロに設定され、受信時には無視される5ビットのReservedフィールド、O。
o A variable length EXT field.
可変長EXTフィールドO。
R, E, Reserved, and EXT are sent encrypted by the protected channel (see Section 3.3).
R、E、予約、およびEXTは保護チャネルにより暗号化されて送信される（セクション3.3参照）。
If there is an extension, PCHANNEL has the format presented in Figure 16.
拡張がある場合、Pチャネルは、図16に提示フォーマットを有します。
This EXT field is split in two subfields:
このEXTフィールドは、2つのサブフィールドに分割されます。
o The EXT_Type subfield, which indicates the type of the extension
拡張のタイプを示すEXT_Typeサブフィールド、O
o The EXT_Payload subfield, which consists of the payload of the extension. The EXT_Payload length is derived from the EAP Length field. EXT_Payload must have a bit length that is a multiple of 8 bits and must not exceed 960 bytes. The latter restriction aims at avoiding fragmentation issues (see Section 8.11).
拡張のペイロードから成るEXT_Payloadサブフィールド、O。 EXT_Payload長はEAP長フィールドから導出されます。 EXT_Payloadは8ビットの倍数であり、960のバイトを超えないビット長さを有していなければなりません。後者の制限は、断片化の問題を（セクション8.11を参照）を回避することを目的とします。
The format of the EXT field is presented in Figure 17.
EXTフィールドのフォーマットは図17に示されています。
In this section, the rules of operation of the EAP-PSK protected channel are presented:
このセクションでは、EAP-PSK保護チャネルの動作の規則が提示されています。
o How protected result indications are implemented.
O保護された結果の表示はどのように実装されています。
o How an extended authentication works in details.
O拡張認証を詳細にどのように動作します。
The R flag of the PCHANNEL field in the third and fourth types of EAP-PSK messages is used to provide result indications.
EAP-PSKメッセージの第三及び第四のタイプにPチャネル電界のRフラグは、結果の指標を提供するために使用されます。
Since this 2-bit flag is communicated over the protected channel, it is:
この2ビットのフラグが保護チャネルを介して通信されるので、それは：
o Encrypted so that only the peer and the server can know its value.
唯一のピアおよびサーバはその値を知ることができるように、O暗号化されました。
o Integrity-protected so that it cannot be modified by an attacker without the peer or the server detecting this modification.
それはピアまたはこの変更を検出することなく、サーバ攻撃者によって変更することができないようにO完全性保護。
o Protected against replays.
Oリプレイに対する保護。
This 2-bit R flag can take the following values:
この2ビットのRフラグは以下の値を取ることができます。
o 01 to mean CONT o 10 to mean DONE_SUCCESS
01 O DONE_SUCCESSを意味する10 O CONTを意味します
o 11 to mean DONE_FAILURE
11 O DONE_FAILUREを意味します
The peer and the server each remember some information about both the values of R that they have sent and the values of R they have received. It is the conjunction of both sent and received R values that indicate the success or the failure of the EAP-PSK dialog.
ピアとサーバのそれぞれは、彼らが送られてきたRの値と、彼らが受けているRの値の両方に関するいくつかの情報を覚えています。それは、成功又はEAP-PSKダイアログの障害を示し、両方の送受信R値の組み合わせです。
In the case of a standard authentication, the following values of R should be exchanged:
標準的な認証の場合には、Rの次の値が交換されるべきです。
o Either the server sends a DONE_SUCCESS in the PCHANNEL of the third EAP-PSK message, to which the peer replies with a DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which successfully ends the EAP-PSK dialog.
Oサーバは、ピアが正常EAP-PSKダイアログを終了する第四のEAP-PSKメッセージのPチャネルにおけるDONE_SUCCESSで応答した第三のEAP-PSKメッセージのPチャネルでDONE_SUCCESSを送信いずれ。
o Or the server sends a DONE_FAILURE in the PCHANNEL of the third EAP-PSK message, to which the peer replies with a DONE_FAILURE in the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully ends the EAP-PSK dialog.
Oまたはサーバは、ピアが失敗したEAP-PSKダイアログを終了する第四のEAP-PSKメッセージのPチャネルにおけるDONE_FAILUREで応答した第三のEAP-PSKメッセージのPチャネルでDONE_FAILUREを送信します。
In the case of an extended authentication, more complex exchanges may occur, which is why the CONT value was introduced.
拡張認証の場合には、より複雑な交換はCONT値が導入された理由である、起こり得ます。
The rules of operation for each value that R may take are detailed below.
Rが取り得る値ごとの動作のルールは以下に詳述します。
The server and the peer each initialize the values of R they intend to send and receive as CONT.
サーバとピア各々は、それらが送信およびCONTとして受信する予定のRの値を初期化します。
Here CONT stands for "Continue". It indicates that the EAP-PSK dialog is not yet successful and that the party sending it wants to continue the dialog to try and reach success.
ここCONTは、「続行」の略です。これは、EAP-PSK]ダイアログボックスがまだ成功していないことを示し、当事者が、それは試してみて、成功に到達するためのダイアログを続けたい送ること。
Indeed, although the peer and the server must have successfully authenticated each other, thanks to MAC_P and MAC_S, before they start communicating over the protected channel, the EAP-PSK dialog may not yet be deemed successful after this mutual authentication because of authorization issues. For instance, a prepaid customer of a wireless Hot-Spot might have successfully authenticated but has to refill its account, e.g., with a credit card transaction over the protected channel, before it is authorized.
彼らは保護されたチャネルを介して通信を開始する前に実際に、ピアとサーバが正常に互いを認証している必要がありますが、MAC_PとMAC_Sのおかげで、EAP-PSKダイアログがまだあるため、許可の問題により、この相互認証の後に成功したとみなされないことがあります。例えば、無線ホットスポットのプリペイド顧客は、認証に成功したが、それが許可される前に、保護されたチャネルを介してクレジットカード決済で、例えば、そのアカウントを補充しなければならないかもしれません。
DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK dialog successful and therefore proposes to end this dialog.
DONE_SUCCESSはそれを送った当事者が成功したEAP-PSKダイアログをとみなすため、このダイアログを終了することを提案していることを示しています。
Once the server has sent a DONE_SUCCESS, it must keep sending this value for R.
サーバはDONE_SUCCESSを送信した後は、それはR.のために、この値を送り続ける必要があります
The peer must first receive a DONE_SUCCESS from the server before it is allowed to send a DONE_SUCCESS.
DONE_SUCCESSを送信することが許可される前に、ピアは、最初のサーバーからDONE_SUCCESSを受けなければなりません。
After the peer has received a DONE_SUCCESS from the server, it may:
ピアは、サーバからDONE_SUCCESSを受信した後、それは可能性があります。
o Send a CONT to the server if it has not reached success on its side. The server that receives a CONT should continue the EAP-PSK dialog (see Section 8.2 for some discussion on the security implications of this).
それはその側での成功に達していない場合は、OサーバにCONTを送信します。 CONTを受けたサーバーは、EAP-PSKダイアログを継続すべきである（これのセキュリティへの影響に関するいくつかの議論については、セクション8.2を参照してください）。
o Send a DONE_SUCCESS to the server, which will end the EAP-PSK dialog with success.
O成功とEAP-PSK]ダイアログボックスを終了しますサーバーにDONE_SUCCESSを送信します。
o Send a DONE_FAILURE to the server, which will end the EAP-PSK dialog with failure.
Oの障害を持つEAP-PSK]ダイアログボックスを終了しますサーバーにDONE_FAILUREを送信します。
DONE_FAILURE indicates that the party that sent it deems the EAP-PSK dialog unsuccessful and proposes to end this dialog because nothing will make it change its mind.
DONE_FAILUREはそれを送った当事者が失敗したEAP-PSKダイアログをと考えると、何もそれはその心を変え行いませんので、このダイアログを終了することを提案していることを示しています。
If the server is the first to send a DONE_FAILURE, then the peer that receives this DONE_FAILURE must reply with a DONE_FAILURE and fail, which ends the EAP-PSK dialog.
サーバがDONE_FAILUREを送ることが最初である場合、このDONE_FAILUREを受けたピアは、EAP-PSKダイアログを終了する、DONE_FAILUREで応答し、失敗しなければなりません。
If the peer is the first to send a DONE_FAILURE, then the server that receives this DONE_FAILURE must immediately end this EAP-PSK dialog without sending any further EAP-PSK message, and fail.
ピアがDONE_FAILUREを送ることが最初である場合、このDONE_FAILUREを受けたサーバは、すぐにそれ以上のEAP-PSKメッセージを送信せずに、このEAP-PSK]ダイアログボックスを終了し、失敗しなければなりません。
An extended authentication can only be started by the server.
拡張認証は、サーバによって開始することができます。
Exactly one extension (identified by the EXT_Type subfield of the EXT field) must be run during an EAP-PSK extended authentication dialog.
正確に（EXTフィールドのEXT_Typeサブフィールドによって識別される）1つの拡張子はEAP-PSK拡張認証ダイアログ中に実行する必要があります。
The extension is run over the protected channel: it can assume confidentiality, integrity, and replay protection.
拡張子は、保護されたチャネルを介して実行されます。それは、機密性、完全性、および再生保護をとることができます。
To start an extended authentication, the server sets the PCHANNEL E flag to 1 and includes the EXT_Payload of the extension it has chosen.
拡張認証を開始するために、サーバは、1にPチャネルEフラグを設定し、それが選択された拡張のEXT_Payloadを含みます。
Since EAP-PSK does not provide fragmentation, the extension must not send an EXT_Payload larger than 960 bytes, which corresponds to the 1020-byte EAP MTU that may minimally be assumed (see [3]).
EAP-PSKは、断片化を提供しないので、拡張は、最小（[3]参照）を想定することができるという1020バイトのEAP MTUに対応する、EXT_Payloadより大きい960のバイトを送信してはなりません。
Moreover, an extension must not send an empty EXT_Payload (because this has a particular meaning for EAP-PSK; see below).
（これはEAP-PSKのための特定の意味を持っているので、下記参照）また、拡張は、空EXT_Payloadを送信してはなりません。
When the peer receives the third EAP-PSK message with the E flag set to 1, it checks whether it is able to process the proposed extension.
ピアが1にセットEフラグを第三のEAP-PSKメッセージを受信すると、提案拡張を処理することができるかどうかをチェックします。
If the peer is not able to process the proposed extension, i.e., it does not recognize the EXT_Type of the proposed extension, it sets E=1 in its reply (the fourth EAP-PSK message) and include an EXT field of the same EXT_Type but with an empty EXT_Payload.
ピアが提案された拡張を処理できない場合、すなわち、それは提案拡張のEXT_Typeを認識しない、それは、その応答（第四のEAP-PSKメッセージ）にE = 1を設定し、同じEXT_TypeのEXTフィールドを含みますしかし、空EXT_Payloadと。
Depending on the values taken by the R flags, the EAP-PSK dialog may:
Rフラグによって撮影された値に応じて、EAP-PSKダイアログがよいです。
o End
Oエンド
* If the peer's policy mandates that it fails in the case of an unrecognized extension, it sends a DONE_FAILURE in the fourth EAP-PSK message.
*それが認識されない拡張子の場合には失敗したピアのポリシーの任務は、それが第四EAP-PSKメッセージでDONE_FAILUREを送信した場合。
* If the server has sent a DONE_SUCCESS in the third EAP-PSK message, and the peer's policy authorizes it to succeed even if the extension is not recognized, the peer sends a DONE_SUCCESS.
サーバは第三EAP-PSKメッセージでDONE_SUCCESSを送った、とピアのポリシーは、拡張子が認識されていなくても成功することを許可した場合*、ピアはDONE_SUCCESSを送信します。
o Continue for exactly one round-trip; namely, in case the server has sent a CONT in the third EAP-PSK message and the peer's policy authorizes it to succeed even if the extension is not recognized, the peer replies with a CONT in the fourth EAP-PSK message. The server must then, depending on its policy, send either a DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK message. If the server sent a DONE_SUCCESS in the fifth EAP-PSK message, the peer must send a DONE_SUCCESS in the sixth EAP-PSK message. All these messages must have the E flag set to 1 with an EXT field with the EXT_Type of the extension that was proposed and an empty EXT_Payload (this behavior was chosen to simplify implementations).
O正確に1往復のために進みます。すなわち、ケース内のサーバは、第三EAP-PSKメッセージにCONTを送信したピアのポリシー拡張子が認識されていなくても成功することを許可し、ピアが第四のEAP-PSKメッセージにCONTで応答します。次に、サーバは、そのポリシーに応じて、DONE_SUCCESS又は5 EAP-PSKメッセージ内のピアにDONE_FAILUREのいずれかを送信しなければなりません。サーバは、第五のEAP-PSKメッセージ内DONE_SUCCESSを送信した場合、ピアは、第六のEAP-PSKメッセージ内DONE_SUCCESSを送信しなければなりません。すべてのこれらのメッセージは、Eフラグが提案された拡張のEXT_Type空EXT_Payload（この動作は、実装を簡略化するために選択された）とEXTフィールドを1に設定しておく必要があります。
If the peer is able to process the proposed extension, then it does so. In this case, the extension must be aware of the R values sent and received and able to propose to update them. All the subsequent messages exchanged between the peer and the server must have the E flag set to 1 with an EXT field of the EXT_Type of the extension that was proposed and a non-empty EXT_Payload.
ピアが提案されている拡張子を処理することができるなら、それはそう。この場合、エクステンションは、R値送信及び受信し、それらを更新することを提案することを認識しなければなりません。後続のすべてのメッセージは、ピア間で交換し、サーバーは、Eフラグが提案された拡張のEXT_Typeと非空EXT_PayloadのEXTフィールドを1に設定する必要があります。
This section provides guidance to the IANA regarding registration of values related to the EAP-PSK protocol, in accordance with [6].
このセクションでは、に従って、EAP-PSKプロトコルに関連する値の登録に関してIANAにガイダンスを提供する[6]。
The following terms are used here with the meanings defined in [6]: "name space" and "registration".
「名前空間」と「登録」：以下の用語は、[6]で定義される意味と共にここで使用されています。
The following policies are used here with the meanings defined in [6]: "Expert Review" and "Specification Required".
「エキスパートレビュー」と「仕様が必要」：次のポリシーは、[6]で定義される意味と共にここで使用されています。
This document introduces one new Internet Assigned Numbers Authority (IANA) consideration: there is one name space in EAP-PSK that requires registration: the EXT_Type values (see Section 5.3 and Section 5.4).
この文書は、1件の新しいインターネット割り当て番号機関（IANA）対価を紹介：EXT_Type値は（5.3節および第5.4節を参照してください）：登録が必要EAP-PSKで1名にスペースがあります。
For registration requests where a Designated Expert should be consulted, the responsible IETF Area Director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated Expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
Expertが相談されるべきである登録要求のために、責任がIETFエリアディレクターはDesignated Expertを任命するべきです。その意図は、任意の割り当てが公開RFCを伴うことになるということです。 RFCが公開されることは明らかと思われるしかし、一度公表のために承認される前RFCへの値の割り当てを可能にするために、指定Expertは配分を承認することができます。指定専門家は、インターネットドラフトを含め、コメントやレビューのためのEAP WGメーリングリストへの要求（または地域ディレクターが指定する後継）を掲載します。 30日間の期間が経過する前に、指定Expertは承認または登録要求を拒否し、EAP WGメーリングリストやその後継者に決定の通知を発行するだけでなく、IANAに通知しますか。拒否通知は説明によって正当化や、許容なるように要求を変更することができますどのようにそれが可能である場合に、具体的な提案されなければなりません。
IANA allocated a new EAP Type for EAP-PSK.
IANAはEAP-PSK用の新しいEAPタイプを割り当てられます。
EAP-PSK is not intended as a general-purpose protocol, and allocations of EXT_Type should not be made for purposes unrelated to authentication, authorization, and accounting.
EAP-PSKは、汎用的なプロトコルとして意図されていない、とEXT_Typeの割り当ては、認証、許可、アカウンティングとは無関係の目的のために作られたべきではありません。
EXT_Type numbers have a range from 1 to 255.
EXT_Type番号は、1から255までの範囲を持っています。
EXT_Type 255 has been allocated for Experimental use.
EXT_Type 255は、実験的な使用のために割り当てられています。
EXT_Type 1-254 may be allocated on the advice of a Designated Expert, with Specification Required.
EXT_Type 1-254は仕様が必要で、指定専門家の助言に割り当てることができます。
[3] highlights several attacks that are possible against EAP, as EAP does not provide any robust security mechanism.
EAPは任意の堅牢なセキュリティメカニズムを提供していない[3]、EAPに対して可能ないくつかの攻撃を強調しています。
This section discusses the claimed security properties of EAP-PSK as well as vulnerabilities and security recommendations in the threat model of [3].
このセクションでは、[3]の脅威モデルに記載のセキュリティEAP-PSKの特性ならびに脆弱性とセキュリティの推奨事項について説明します。
EAP-PSK provides mutual authentication.
EAP-PSKは、相互認証を提供します。
The server believes that the peer is authentic because it can calculate a valid MAC and the peer believes that the server is authentic because it can calculate another valid MAC.
サーバは、それが有効なMACを計算することができ、ピアは、それは別の有効なMACを計算することができますので、サーバーが本物であると信じているので、相手が本物であると考えています。
The authentication protocol that inspired EAP-PSK, AKEP2, enjoys a security proof in the provable security paradigm; see [14].
EAP-PSK、AKEP2に影響を与えた認証プロトコルは、証明可能なセキュリティ・パラダイムのセキュリティ証明を享受する。 [14]を参照してください。
The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK, CMAC, also enjoys a security proof in the provable security paradigm; see [29]. A tag length of 16 bytes for CMAC is currently deemed appropriate by the cryptographic community for entity authentication.
EAP-PSK、CMAC内AKEP2のインスタンス化に使用されるMACアルゴリズムは、また、証明可能なセキュリティ・パラダイムのセキュリティ証明を享受する。 [29]を参照してください。 CMACのための16バイトのタグの長さは、現在のエンティティの認証のための暗号コミュニティによって適切であると考えられます。
The underlying block cipher used, AES-128, is widely believed to be a secure block cipher.
使用される基本的なブロック暗号、AES-128は、広く安全なブロック暗号であると考えられています。
Finally, the key used for mutual authentication, AK, is only used for that purpose, which makes this part cryptographically independent of the other parts of the protocol.
最後に、相互認証のために使用されるキーは、AKは、プロトコルの他の部分のこの部分は、暗号依存しなくなり、その目的のためにのみ使用されます。
EAP-PSK provides mutual authentication if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way, EAP-PSK is no different than other authentication protocols based on Pre-Shared Keys.
それは、十分な強度のペアワイズPSKに基づいている場合、EAP-PSKは、相互認証を提供します。 PSKは十分に強いペアごとのかないではない場合、それは認証を提供しません。このように、EAP-PSKは、事前共有鍵に基づいて、他の認証プロトコルよりも違いはありません。
EAP-PSK provides protected result indications thanks to its 2-bit R flag (see Section 6.1). This 2-bit R flag is protected because it is encrypted and integrity protected by the EAX mode of operation; see Section 3.3.
EAP-PSKは、その2ビットのRフラグを結果表示のおかげで保護提供する（セクション6.1を参照）。それは暗号化と完全性は、動作のEAXモードで保護されているため、この2ビットのRフラグが保護されています。 3.3節を参照してください。
Care may be taken against Byzantine failures, that is to say, for instance, when a peer tries to force a server to engage in a never-ending conversation. This could, for example, be done by a peer that keeps sending a CONT after it has received a DONE_SUCCESS from the server. A policy may limit the number of rounds in an EAP-PSK extended authentication to mitigate this threat, which is outside our threat model.
ケアは、ビザンチン故障に対して取ることができる、それは、ピアは決して終わることのない会話をするために、サーバーを強制しようとすると、例えば、と言うことです。これは、例えば、それはサーバからDONE_SUCCESSを受け取った後にCONTを送信し続けるピアによって行うことができます。ポリシーは、我々の脅威モデルの外側にあるこの脅威を緩和するためにEAP-PSK拡張認証にラウンドの数を制限することができます。
It should also be noted that the cryptographic protection of the result indications does not prevent message deletion.
また、結果指摘の暗号保護は、メッセージの削除を妨げるものではないことに留意すべきです。
For instance, let us consider a scenario in which:
たとえば、私たちはシナリオを考えてみましょう：
o A server sends a DONE_SUCCESS to a peer.
Oサーバーは、ピアにDONE_SUCCESSを送信します。
o The peer replies with a DONE_SUCCESS.
OピアはDONE_SUCCESSで応答します。
In the case that the last message from the peer is intercepted, and an EAP Success is sent to the peer before any retransmission from the server reaches it, or the retransmissions from the server are also deleted, the peer will believe that it has successfully authenticated to the server while the server will fail.
ピアからの最後のメッセージが傍受され、EAP成功は、サーバーが到達、またはサーバからの再送信も削除されてから任意の再送信の前にピアに送信された場合には、ピアは、それが正常に認証されたことを信じていますサーバにサーバが失敗しますながら。
This behavior is well known (see, e.g., [23]) and in a sense unavoidable. There is a trade-off between efficiency and the "level" of information sharing that is attainable. EAP-PSK specified a single round-trip of DONE_SUCCESS because it is believed that:
この現象はよく知られている（参照、例えば、[23]）との意味で避けられません。効率と達成可能である情報共有の「レベル」の間にトレードオフがあります。それがあると考えられているため、EAP-PSKはDONE_SUCCESSの1回のラウンドトリップを指定しました：
o If there is an adversary capable of disrupting the communication channel, it can do so whenever it wants (be it after 1 or 10 round-trips or even during data communication).
通信チャネルを破壊することが可能な敵が存在する場合、それは（それがデータ通信中であっても1又は10往復又は後であること）を望むたびに、O、それはそうすることができます。
o Other layers/applications will generally start by doing a specific key exchange and confirmation procedure using the keys derived by EAP-PSK. This is typically done by IEEE 802.11i "four-way handshake". In case the error is not detected by EAP-PSK, it should be detected then (please note, however, that it is bad practice to rely on an external mechanism to ensure synchronization, unless this is an explicit property of the external mechanism).
他の層のO /アプリケーションは、一般的にEAP-PSKによって引き出されたキーを使用して、特定の鍵交換や確認の手順を実行して開始します。これは通常、IEEE 802.11iの「4ウェイハンドシェイク」によって行われます。エラーがEAP-PSKで検出されない場合には、それは（これは外部機構の明示的な性質である場合を除き、同期を確保するために、外部のメカニズムに依存する悪い習慣であること、しかし、注意してください）その後、検出されるべきです。
EAP-PSK provides integrity protection thanks to the Tag of its protected channel (see Section 3.3).
EAP-PSKは、その保護されたチャネルのタグに完全性保護のおかげを提供（3.3節を参照してください）。
EAP-PSK provides integrity protection if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way, it is no different than other authentication protocols based on Pre-Shared Keys.
それは十分な強度の対PSKに基づいている場合EAP-PSKは、完全性保護を提供します。 PSKは十分に強いペアごとのかないではない場合、それは認証を提供しません。このようにして、事前共有鍵に基づいて、他の認証プロトコルよりも違いはありません。
EAP-PSK provides replay protection of its mutual authentication part thanks to the use of random numbers RAND_S and RAND_P. Since RAND_S is 128 bits long, one expects to have to record 2**64 (i.e., approximately 1.84*10**19) EAP-PSK successful authentications before an authentication can be replayed. Hence, EAP-PSK provides replay protection of its mutual authentication part as long as RAND_S and RAND_P are chosen at random; randomness is critical for security.
EAP-PSKは、乱数RAND_SとRAND_Pの使用への相互認証部分のおかげでの再生保護を提供します。 RAND_Sは128ビット長であるため、一方が記録しなければならないことを期待2 ** 64（すなわち、約1.84 * 10 ** 19）EAP-PSK認証の前に成功した認証を再生することができます。したがって、EAP-PSKであればRAND_SとRAND_Pがランダムに選択されるように、その相互認証部のリプレイ保護を提供します。ランダム性は、セキュリティのために重要です。
EAP-PSK provides replay protection during the conversation of the protected channel thanks to the Nonce N of its protected channel (see Section 3.3). This nonce is initialized to 0 by the server and monotonically incremented by one by the party that receives a valid EAP-PSK message. For instance, after receiving from the server a valid EAP-PSK message with Nonce set to x, the peer will answer with an EAP-PSK message with Nonce set to x+1 and wait for an EAP-PSK message with Nonce set to x+2. A retransmission of the server's message with Nonce set to x would cause the peer EAP layer to resend the message in which Nonce was set to x+1, which would be transparent to the EAP-PSK layer.
EAP-PSK（セクション3.3を参照）は、その保護されたチャネルのノンスNに保護されたチャネルのおかげでの会話中にリプレイ保護を提供します。このナンスは、サーバによって0に初期化し、単調に有効なEAP-PSKメッセージを受け取る当事者が1つインクリメントします。例えば、ノンスを持つ有効なEAP-PSKメッセージをxに設定し、サーバから受信した後、ピアはノンスを持つEAP-PSKメッセージで応答するX + 1に設定し、nonceがXに設定してEAP-PSKメッセージを待ちます2。ノンスとサーバのメッセージの再送がXに設定されたピアEAP層はノンスがEAP-PSK層に透明であろう、X + 1に設定されたメッセージを再送信する原因となります。
The EAP peer must check that the Nonce is indeed initialized to 0 by the server.
EAPピアはnonceが実際にサーバによって0に初期化されていることを確認する必要があります。
EAP-PSK provides protection against reflection attacks in case of an extended authentication because:
EAP-PSKであるため、拡張認証の場合には反射攻撃に対する保護を提供します。
o It integrity protects the EAP header (which contains the indication Request/Response.
Oそれは完全性指示要求/応答を含む（EAPヘッダーを保護します。
o It includes two separate spaces for the Nonces: the EAP server only receives messages with odd nonces, whereas the EAP peer only receives messages with even nonces.
EAPピアのみであっても一回だけのメッセージを受信するのに対し、EAPサーバにのみ、奇数ナンスでメッセージを受信：Oそれはナンスのための2つの別々のスペースを含みます。
Because EAP-PSK is not a password protocol, it is not vulnerable to dictionary attacks.
EAP-PSKパスワードプロトコルではありませんので、それは辞書攻撃に対して脆弱ではありません。
Indeed, the PSK used by EAP-PSK must not be derived from a password. Derivation of the PSK from a password may lead to dictionary attacks.
確かに、EAP-PSKで使用されるPSKがパスワードから派生してはいけません。パスワードからPSKの導出は、辞書攻撃につながる可能性があります。
However, using a 16-byte PSK has:
しかし、16バイトのPSKを使用しています
o Ergonomic impacts: some people may find it cumbersome to manually provision a 16-byte PSK.
人間工学に基づいた影響○：一部の人々は規定の16バイトのPSKを手動にそれが面倒かもしれません。
o Deployment impacts: some people may want to reuse existing credential databases that contain passwords and not PSKs.
Oの展開への影響：一部の人々は、パスワードではなくPSKsが含まれている既存の資格情報のデータベースを再利用する場合があります。
Because people will probably not heed the warning not to use passwords, guidance to derive a PSK from a password is provided in Appendix A. The method proposed in Appendix A only tries to make dictionary attacks harder. It does not eliminate them.
人々は、おそらくパスワードを使用しないよう警告に耳を傾けるませんので、パスワードからPSKを導出するためのガイダンスは、付録Aに提供され、付録Aに提案された方法は難しく辞書攻撃を作るしようとします。これは、それらを排除しません。
However, it does not cause a fatal error if passwords are used instead of PSKs: people rarely use password-derived certificates, so why should they do so for shared keys?
パスワードが代わりにPSKsで使用されている場合しかし、それは致命的なエラーが発生することはありません。人々はめったにパスワード由来の証明書を使用しない、なぜ彼らが共有鍵のためにそうする必要がありますか？
EAP-PSK supports key derivation.
EAP-PSKは、鍵の導出をサポートしています。
The key hierarchy is specified in Section 2.1.
キー階層構造はセクション2.1で指定されています。
The mechanism used for key derivation is the modified counter mode.
鍵導出のために使用されるメカニズムは、修正カウンタモードです。
The instantiation of the modified counter in EAP-PSK complies with the conditions stated in [5] so that the security proof for this mode holds.
EAP-PSKで修飾カウンタのインスタンスは、このモードのセキュリティ証明が成立するように、[5]に記載の条件に準拠しています。
The underlying block cipher used, AES-128, is widely believed to be a secure block cipher.
使用される基本的なブロック暗号、AES-128は、広く安全なブロック暗号であると考えられています。
A first key derivation occurs to calculate AK and KDK from the PSK: it is called the key setup (see Section 3.1). It uses the PSK as the key to the modified counter mode. Thus, AK and KDK are believed to be cryptographically separated and computable only to those who have knowledge of the PSK.
最初のキー導出はPSKからAKとKDKを計算するために発生します。これは、キー設定（3.1節を参照）と呼ばれています。これは、修正カウンタモードのキーとしてPSKを使用しています。このように、AKとKDKだけPSKの知識を持っている人に暗号的に分離して計算すると考えられています。
A second key derivation occurs to derive session keys, namely, the TEK, MSK, and EMSK (see Section 3.2). It uses KDK as the key to the modified counter mode.
第2の鍵導出（セクション3.2を参照）、すなわち、セッションキーを導出するためにTEK、MSKおよびEMSKを生じます。これは、修正カウンタモードのキーとしてKDKを使用しています。
The protocol design explicitly assumes that neither AK nor KDK are shared beyond the two parties utilizing them. AK loses its efficacy to mutually authenticate the peer and server with each other when it is shared. Similarly, the derived TEK, MSK, and EMSK lose their value when KDK is shared with a third party.
プロトコルの設計は、明示的にAKもKDKどちらもそれらを利用する2つの政党を超えて共有されていることを前提としています。 AKは、それが共有されているときに相互ピア及びサーバを認証するために、その効力を失います。 KDKが第三者と共有されている場合も同様に、派生TEK、MSK、およびEMSKは、その価値を失います。
It should be emphasized that the peer has control of the session keys derived by EAP-PSK. In particular, it can easily choose the random number it sends in EAP-PSK so that one of the nine derived 16-byte key blocks (see Section 2.1) takes a pre-specified value.
ピアがEAP-PSKによって得られたセッションキーを制御していることが強調されるべきです。 9由来の16バイトキーブロック（セクション2.1を参照）のいずれかが予め指定された値をとるように、特に、容易にそれがEAP-PSKで送信する乱数を選択することができます。
It was chosen not to prevent this control of the session keys by the peer because:
それはので、ピアによってセッションキーのこのコントロールを妨げない選択しました：
o Preventing it would have added some complexity to the protocol (typically, the inclusion of a one-way mode of operation of AES in the key derivation part).
予防oをそのプロトコルにいくつかの複雑さを追加したことになる（典型的には、鍵導出部におけるAESの動作の一方向モードを含めます）。
o It is believed that the peer won't try to force the server to use some pre-specified value for the session keys. Such an attack is outside the threat model and seems to have little value compared to a peer sharing its PSK.
Oピアがセッションキーのためにいくつかの事前に指定された値を使用するようにサーバーを強制しようとしないだろうと考えられています。このような攻撃は脅威モデルの外にあり、そのPSKを共有するピアに比べてほとんど価値を持っているようです。
However, this is not the behavior recommended by EAP in Section 7.10 of [3].
しかし、これは、[3]のセクション7.10でEAPが推奨する動作ではありません。
Since deriving the session keys requires some cryptographic computations, it is recommended that the session keys be derived only once authentication has succeeded (i.e., once the server has successfully verified MAC_P for the server side, and once the peer has successfully verified MAC_S for the peer side).
セッションキーを導出することは、いくつかの暗号計算を必要とするので、セッションキーは認証が（成功しただけで後は導出することをお勧めしますつまり、ピアが正常にピアのMAC_Sを確認した後、サーバーが正常にサーバ側のためMAC_Pを検証し、いったん側）。
It is recommended to take great care in implementations, so that derived keys are not made available if the EAP-PSK dialog fails (e.g., ends with DONE_FAILURE).
EAP-PSK]ダイアログに障害が発生した場合に生成されたキーが使用可能にされていないので、それは、実装に細心の注意を払うことをお勧めします（例えば、DONE_FAILUREで終わります）。
The TEK must not be made available to anyone except to the current EAP-PSK dialog.
TEKは、現在のEAP-PSKダイアログを除いて誰もが利用できるようにしてはいけません。
Denial of Service (DoS) resistance has not been a design goal for EAP-PSK.
サービス拒否（DoS）の抵抗は、EAP-PSKのための設計目標なかったです。
It is, however, believed that EAP-PSK does not provide any obvious and avoidable venue for such attacks.
しかし、EAP-PSKは、このような攻撃のための任意の明白かつ回避可能な会場を提供していないと考えられています。
It is worth noting that the server has to do a cryptographic calculation and maintain some state when it engages in an EAP-PSK conversation, namely, generate and remember the 16-byte RAND_S. However, this should not lead to resource exhaustion as this state and the associated computation are fairly lightweight.
これは、サーバが暗号計算を行うと、それはEAP-PSKの会話に従事したときに、いくつかの状態を維持する、すなわち、16バイトのRAND_Sを生成し、覚えなければならないことは注目に値します。この状態と関連付けられている計算はかなり軽量ですしかし、これはリソースの枯渇につながるべきではありません。
Please note that both the peer and the server must commit to their RAND_S and RAND_P to protect their partners from flooding attacks.
ピアとサーバーの両方がフラッディング攻撃から自分のパートナーを守るために自分のRAND_SとRAND_Pにコミットしなければならないことに注意してください。
It is recommended that EAP-PSK not allow EAP notifications to be interleaved in its dialog to prevent potential DoS attacks. Indeed, since EAP notifications are not integrity protected, they can easily be spoofed by an attacker. Such an attacker could force a peer that allows EAP notifications to engage in a discussion that would delay his or her authentication or result in the peer taking unexpected actions (e.g., in case a notification is used to prompt the peer to do some "bad" action).
EAP-PSKは、EAP通知は、潜在的なDoS攻撃を防ぐために、そのダイアログでインターリーブすることを許可しないことをお勧めします。 EAP通知が完全性保護されていないので、実際に、彼らは簡単に攻撃者によって偽装させることができます。通知はいくつかの「悪い」を行うためにピアに促すために使用されている場合にはそのような攻撃者は、EAP通知が彼または彼女の認証を遅らせたり、予期せぬアクション（例えば、服用ピアにつながる議論に従事することを可能にするピアを強制することができアクション）。
It is up to the implementation of EAP-PSK or to the peer and the server to specify the maximum number of failed cryptographic checks that are allowed. For instance, does the reception of a bogus MAC_P in the second EAP-PSK message cause a fatal error or is it discarded to continue waiting for the valid response of the valid peer? There is a trade-off between possibly allowing multiple tentative forgeries and allowing a direct DoS (in case the first error is fatal).
これはEAP-PSKの実装までまたはピアと許可されて失敗した暗号チェックの最大数を指定するためのサーバです。例えば、第2 EAP-PSKメッセージに偽のMAC_Pの受信は、致命的なエラーが発生したり、それが有効なピアの有効な応答を待ち続けるために廃棄されているのでしょうか？おそらく複数の仮の偽造を可能にし、（ケース最初のエラーが致命的であるに）直接DoS攻撃を可能にするとの間のトレードオフがあります。
For the sake of simplicity and denial-of-service resilience, EAP-PSK has chosen not to include any error messages. Hence, an "invalid" EAP-PSK message is silently discarded. Although this makes interoperability testing and debugging harder, this leads to simpler implementations and does not open any venue for denial-of-service attacks.
シンプルさとサービス拒否回復力のために、EAP-PSKはすべてのエラーメッセージを含めるしないことを選択しました。したがって、「無効」EAP-PSKメッセージは黙って破棄されます。これは難しい相互運用性のテストとデバッグを行いますが、これは単純な実装につながり、サービス妨害（DoS）攻撃のいずれかの会場を開きません。
Thanks to its key derivation mechanisms, EAP-PSK provides session independence: passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs.
その鍵導出メカニズムのおかげで、EAP-PSKは、セッションの独立性を提供します（たとえば、EAPの会話のキャプチャなど）、受動的攻撃または（MSKかEMSKの妥協を含む）アクティブな攻撃は、その後またはその前たMSKまたはEMSKsの妥協を有効にしないでください。
The assumption that RAND_P and RAND_S are random is central for the security of EAP-PSK in general and session independence in particular.
RAND_PとRAND_Sがランダムであるという仮定は、一般、特にセッション独立でEAP-PSKのセキュリティのための中心です。
EAP-PSK does not provide Perfect Forward Secrecy. Compromise of the PSK leads to compromise of recorded past sessions.
EAP-PSKは完全転送秘密を提供していません。 PSKの妥協点は、記録された過去のセッションの妥協につながります。
Compromise of the PSK enables the attacker to impersonate the peer and the server: compromise of the PSK leads to "full" compromise of future sessions.
PSKの妥協は、ピアとサーバを偽装する攻撃を可能にします：PSKの妥協は将来のセッションの「フル」妥協につながります。
EAP-PSK provides no protection against a legitimate peer sharing its PSK with a third party. Such protection may be provided by appropriate repositories for the PSK, whose choice is outside the scope of this document. The PSK used by EAP-PSK must only be shared between two parties: the peer and the server. In particular, this PSK must not be shared by a group of peers communicating with the same server.
EAP-PSKは、第三者とのPSKを共有する正当なピアに対する保護機能はありません。そのような保護は、選択この文書の範囲外であるPSK、適しリポジトリによって提供されてもよいです。ピアとサーバ：EAP-PSKで使用されるPSKは、二者間で共有されなければなりません。特に、このPSKは同一のサーバと通信するピアのグループで共有されてはなりません。
The PSK used by EAP-PSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-PSK may be compromised. It is a rule of thumb in cryptography to use different keys for different applications.
EAP-PSKで使用されるPSKが暗号さもなければEAP-PSKのセキュリティが損なわれる可能性があり、他のプロトコルによって使用されるキーから分離しなければなりません。これは、アプリケーションごとに異なる鍵を使用する暗号で親指のルールです。
EAP-PSK does not support fragmentation and reassembly.
EAP-PSKは、断片化と再構築をサポートしていません。
Indeed, the largest EAP-PSK frame is at most 1015 bytes long, because:
確かに、最大のEAP-PSKフレームがあるため、最大で1015バイトの長さ：
o The maximum length for the peer NAI identity used in EAP-PSK is 966 bytes (see Section 5.2). This should not be a limitation in practice (see Section 2.2 of [2] for more considerations on NAI length).
EAP-PSKで使用されるピアNAI同一の最大長が966バイトであるO（5.2節を参照）。これは、（NAIの長さ以上の考察については[2]のセクション2.2を参照）は、実際に制限すべきではありません。
o The maximum length for the EXT_Payload field used in EAP-PSK is 960 bytes (see Section 5.3 and Section 5.4).
O EAP-PSKで使用EXT_Payloadフィールドの最大長は960バイト（5.3節及び第5.4節を参照します）。
Per Section 3.1 of [3], the lower layers over which EAP may be run are assumed to have an EAP MTU of 1020 bytes or greater. Since the EAP header is 5 bytes long, supporting fragmentation for EAP-PSK is unnecessary.
セクション3.1当たり[3]、EAPを実行することができる上に、下部層1020バイト以上のEAP MTUを有すると仮定されています。 EAPヘッダは5バイト長であるため、EAP-PSKの支持断片化は不要です。
Extensions that require sending a payload larger than 960 bytes should provide their own fragmentation and reassembly mechanism.
960のバイトは、自分の断片化と再アセンブリメカニズムを提供しなければならないよりも大きなペイロードを送信する必要が拡張。
EAP-PSK does not provide channel binding as this feature is still very much a work in progress (see [13]).
EAP-PSKは、（[13]参照）、この機能はまだ進行中の非常に多くの仕事であるように結合チャネルを提供しません。
However, it should be easy to add it to EAP-PSK as an extension (see Section 4.2).
しかし、（4.2節を参照）拡張としてEAP-PSKに追加するのは簡単でなければなりません。
EAP-PSK does not provide any fast reconnect capability.
EAP-PSKは、任意の高速再接続機能を提供していません。
Indeed, as noted, for instance, in [15], mutual authentication (without counters or timestamps) requires three exchanges, thus four exchanges in EAP since any EAP-Request must be answered to by an EAP-Response.
任意のEAP-RequestがEAP-応答によって回答されなければならないので実際に、述べたように、例えば、中に[15]、（カウンタまたはタイムスタンプ無し）、相互認証は、このように3つの交換、EAPの4つの交換を必要とします。
Since this minimum bound is already reached in EAP-PSK standard authentication, there is no way the number of round-trips used within EAP-PSK can be reduced without using timestamps or counters. Timestamps and counters were deliberately avoided for the sake of simplicity and security (e.g., synchronization issues).
この最小結合が既にEAP-PSK認証標準に達しているため、EAP-PSK内で使用されるラウンドトリップの数はタイムスタンプまたはカウンタを使用することなく低減することができる方法はありません。タイムスタンプとカウンタは故意にシンプルさとセキュリティ（例えば、同期の問題）のために回避されました。
Since it was chosen to restrict to a single cryptographic primitive from symmetric cryptography, namely, the block cipher AES-128, it appears that it is not possible to provide "reasonable" identity protection without failing to meet the simplicity goal.
それは対称暗号から単一の暗号プリミティブに制限するために選ばれたので、すなわち、ブロック暗号AES-128は、シンプル目標を達成するために失敗することなく、「合理的な」アイデンティティ保護を提供することはできないことが表示されます。
Hereafter is an informal discussion of what is meant by identity protection and the rationale behind the requirement of identity protection. For some complementary discussion, refer to [37].
以下は、ID保護とアイデンティティの保護の必要性の根拠が何を意味するかの非公式の議論です。いくつかの相補的な議論のために、[37]を参照。
Identity protection basically means preventing the disclosure of the identities of the communicating parties over the network, which is quite contradictory to authentication. There are two levels of identity protection: protection against passive attackers and protection against active eavesdroppers.
アイデンティティ保護は、基本的には、認証に非常に矛盾しているネットワーク上で通信する当事者の身元の開示を、防止することを意味します。アクティブな盗聴に対する受動攻撃に対する防御と保護：アイデンティティ保護の2つのレベルがあります。
As explained in [37], "a common example [for identity protection] is the case of mobile devices wishing to prevent an attacker from correlating their (changing) location with the logical identity of the device (or user)".
[37]で説明したように、「[アイデンティティ保護用]一般的な例は、装置（又はユーザ）の論理的な同一性を有するそれらの（変化）の位置を相関からの攻撃を防ぐことを望むモバイル装置の場合です」。
If only symmetric cryptography is used, only a weak form of identity protection may be offered, namely, pseudonym management. In other words, the peer and the server agree on pseudonyms that they use to identify each other and usually change them periodically, possibly in a protected way so that an attacker cannot learn new pseudonyms before they are used.
唯一の対称暗号が使用される場合、アイデンティティ保護の弱い形態、すなわち、匿名の管理を提供することができます。言い換えると、ピアとサーバは、彼らがお互いを識別し、それらが使用される前に攻撃者が新しい匿名を学ぶことができないように、通常は、おそらく保護された方法で、定期的にそれらを変更するために使用偽名に同意するものとします。
With pseudonym management, there is a trade-off between allowing for pseudonym resynchronization (thanks to a permanent identity) and being vulnerable to active attacks (in which the attacker forges messages simulating a pseudonym desynchronization).
仮名管理では、仮名の再同期のために（永久的なアイデンティティのおかげで）できるようにし、アクティブな攻撃（ここで、攻撃者は仮名の非同期化をシミュレートするメッセージを偽造）に対して脆弱であることの間にはトレードオフが存在します。
Indeed, a protocol using time-varying pseudonyms may want to anticipate "desynchronization" situations such as, for instance, when the peer believes that its current pseudonym is "pseudo1@bigco.com" whereas the server believes this peer will use the pseudonym "pseudo2@bigco.com" (which is the pseudonym the server has sent to update "pseudo1@bigco.com").
ピアは、サーバがこのピアが「仮名を使用すると考えているのに対し、現在の仮名は「pseudo1@bigco.com」であると考えていたときに実際に、時間的に変化する偽名を使用してプロトコルは、このような場合のために、として「非同期」な状況を予測することもできます「（ 『pseudo1@bigco.comサーバーを更新するために、送信された仮名である』）pseudo2@bigco.com。
Because pseudonym management adds complexity to the protocol and implies this unsatisfactory trade-off, it was decided not to include this feature in EAP-PSK.
仮名管理はプロトコルに複雑さを追加し、この不十分なトレードオフを意味しますので、EAP-PSKでこの機能を含めるしないことに決めました。
However, EAP-PSK may trivially provide some protection when the concern is to avoid the "real-life" identity of the user being "discovered". For instance, let us take the example of user John Doe that roams and connects to a Hot-Spot owned and operated by Wireless Internet Service Provider (WISP) BAD. Suppose this user authenticates to his home WISP (WISP GOOD) with an EAP method under an identity (e.g., "john.doe@wispgood.com") that allows WISP BAD (or an attacker) to recover his "real-life" identity, i.e., John Doe. An example drawback of this is when a competitor of John Doe's WISP wants to win John Doe as a new customer by sending him some special targeted advertisement.
懸念が「発見」されているユーザの「現実」のアイデンティティを避けるためですしかし、EAP-PSKは自明いくつかの保護を提供することができます。たとえば、私たちがローミングするとBADホットスポット無線インターネットサービスプロバイダ（WISP）が所有し、運営に接続するユーザージョン・ドウの例を見てみましょう。このユーザーは、彼の「現実」のアイデンティティを回復するためにWISP BAD（または攻撃）を可能にするアイデンティティ（例えば、「john.doe@wispgood.com」）の下でEAP方式で自宅のWISP（WISP GOOD）の認証を受けたと、すなわち、ジョン・ドウ。 John DoeのWISPの競争相手は彼にいくつかの特別なターゲット広告を送信することにより、新たな顧客としてジョン・ドウを獲得したいときに、この例の欠点があります。
EAP-PSK can very simply thwart this attack, merely by avoiding to provide John Doe with an NAI that allows easy recovery of his real-life identity. It is believed that when an NAI that is not correlated to a real-life identity is used, no valuable information leaks because of the EAP method.
EAP-PSKは非常に簡単に、単に彼の現実のアイデンティティの容易な回収を可能にするNAIとジョン・ドウを提供するために、回避することにより、この攻撃を阻止することができます。現実のアイデンティティと相関されていないNAIを使用する場合、何の貴重な情報があるため、EAP方式のリークしていないと考えられています。
Indeed, the identity of the WISP used by a peer has to be disclosed anyway in the realm portion of its NAI to allow AAA routing. Moreover, the Medium Access Control Address of the peer's Network Interface Card can generally be used to track the peer as efficiently as a fixed NAI.
実際、ピアによって使用されるWISPの同一性は、AAAルーティングを可能にするために、そのNAIのレルム部分でとにかく開示されなければなりません。また、ピアのネットワークインタフェースカードのメディアアクセス制御アドレスは、一般的に、固定NAIな限り効率的にピアを追跡するために使用することができます。
It is worth noting that the server systematically discloses its identity, which may allow probing attacks. This may not be a problem as the identity of the server is not supposed to remain secret. On the contrary, users tend to want to know to whom they will be talking in order to choose the right network to attach to.
サーバーが体系的な攻撃をプロービングする可能性があり、そのアイデンティティを、開示していることは注目に値します。サーバーの身元が秘密のままになっていないので、これは問題ではないかもしれません。逆に、ユーザーは、彼らがに接続する権利ネットワークを選択するために話をされます誰に知りたい傾向にあります。
EAP-PSK does not allow negotiating ciphersuites. Hence, it is not vulnerable to negotiation attacks and does not implement protected ciphersuite negotiation.
EAP-PSKで暗号スイートを交渉はできません。したがって、それは交渉の攻撃に対して脆弱ではなく、保護された暗号スイートのネゴシエーションを実装していません。
Although EAP-PSK provides confidentiality in its protected channel, it cannot claim to do so as per Section 7.2.1 of [3]: "A method making this claim must support identity protection".
EAP-PSKは、その保護されたチャネルで機密性を提供しますが、それはの7.2.1項に従ってそうすることを主張することはできません[3]：「この主張を作る方法は、ID保護をサポートしなければなりません」。
Since EAP-PSK is not intended to be tunneled within another protocol that omits peer authentication, it does not implement cryptographic binding.
EAP-PSKは、ピア認証を省略別のプロトコル内でトンネリングすることを意図していないので、暗号バインディングを実装していません。
To really provide security, not only must a protocol be well thought-out and correctly specified, but its implementation must take special care.
実際にセキュリティを提供するために、プロトコルは、考え抜かれたことが、正しく指定しなければならないだけでなく、その実装は、特別な注意を払う必要があります。
For instance, implementing cryptographic algorithms requires special skills since cryptographic software is vulnerable not only to classical attacks (e.g., buffer overflow or missing checks) but also to some special cryptographic attacks (e.g., side channels attacks like timing ones; see [36]). In particular, care must be taken to avoid such attacks in EAX implementation; please refer to [4] for a note on this point.
暗号化ソフトウェアは、古典的な攻撃（例えば、バッファオーバーフローまたは欠落チェック）にもいくつかの特別な暗号攻撃（[36]参照ものタイミングなど、例えば、サイドチャネル攻撃）に対してのみならず、脆弱であるため、例えば、暗号化アルゴリズムを実装することは、特別なスキルを必要とします。具体的には、注意がEAX実装のような攻撃を避けるようにしなければなりません。この時点でのノートの[4]を参照してください。
An EAP-PSK implementation should use a good source of randomness to generate the random numbers required in the protocol. Please refer to [20] for more information on generating random numbers for security applications.
EAP-PSKの実装では、プロトコルに必要な乱数を生成する乱数の良好な供給源を使用する必要があります。セキュリティアプリケーションのために乱数を生成の詳細については、[20]を参照してください。
Handling sensitive material (namely, keying material such as the PSK, AK, KDK, etc.) should be done in a secure way (see, for instance, [19] for guidance on secure deletion).
感光材料を処理する（すなわち、例えばPSK、AK、KDK、等のような材料をキーイングする）（セキュア削除に関するガイダンスのために、例えば、参照[19]）安全な方法で行われるべきです。
The specification of a repository for the PSK that EAP-PSK uses is outside the scope of this document. In particular, nothing prevents one from storing this PSK on a tamper-resistant device such as a smart card rather than having it memorized or written down on a sheet of paper. The choice of the PSK repository may have important security impacts.
EAP-PSKを使用するPSKのリポジトリの仕様は、この文書の範囲外です。具体的には、何もこのようなスマートカードなどの耐タンパデバイスでこのPSKを格納するのではなく、それが記憶または紙に書き留めることからいずれかを妨げるものはありません。 PSKリポジトリの選択が重要なセキュリティへの影響を有することができます。
This section provides the security claims required by [3].
このセクションでは、[3]で必要なセキュリティクレームを提供します。
[a] Mechanism. EAP-PSK is based on symmetric cryptography (AES-128) and uses a 16-byte Pre-Shared Key (PSK).
[A]メカニズム。 EAP-PSKは、対称暗号方式（AES-128）に基づいており、16バイトの事前共有鍵（PSK）を使用しています。
[b] Security claims. EAP-PSK provides:
[B]セキュリティ主張。 EAP-PSKは以下を提供します。
* Mutual authentication (see Section 8.1)
*相互認証（8.1節を参照してください）
* Integrity protection (see Section 8.3)
*完全性保護（8.3節を参照してください）
* Replay protection (see Section 8.4)
*リプレイ保護（8.4節を参照してください）
* Key derivation (see Section 8.7)
*鍵導出（8.7節を参照してください）
* Dictionary attack resistance (see Section 8.6)
*辞書攻撃耐性（8.6節を参照してください）
* Session independence (see Section 8.9)
*セッションの独立性（8.9節を参照してください）
[c] Key strength. EAP-PSK provides a 16-byte effective key strength.
[C]キー強度。 EAP-PSKは、16バイトの実効キー強度を提供します。
[d] Description of key hierarchy. Please see Section 2.1.
[D]キー階層の説明。 2.1節を参照してください。
[e] Indication of vulnerabilities. EAP-PSK does not provide:
[E]の脆弱性の指標。 EAP-PSKは提供されません。
* Identity protection (see Section 8.14)
*アイデンティティプロテクション（セクション8.14を参照してください）
* Confidentiality (see Section 8.16)
*機密性（セクション8.16を参照してください）
* Fast reconnect (see Section 8.13)
*高速再接続（セクション8.13を参照してください）
* Fragmentation (see Section 8.11)
*フラグメンテーション（セクション8.11を参照してください）
* Cryptographic binding (see Section 8.17)
*結合暗号化（セクション8.17を参照してください）
* Protected ciphersuite negotiation (see Section 8.15)
*保護された暗号スイートのネゴシエーション（セクション8.15を参照してください）
* Perfect Forward Secrecy (see Section 8.10)
*完全転送秘密（8.10節を参照してください）
* Key agreement: the session key is chosen by the peer (see Section 8.7)
*主な合意：セッション鍵がピアによって選択された（8.7節を参照してください）
* Channel binding (see Section 8.12)
*結合チャネル（8.12節を参照してください）
This EAP method has been inspired by EAP-Archie and EAP-SIM. Many thanks to their respective authors: Jesse Walker (extra thanks to Jesse Walker for his thorough and challenging expert review of EAP-PSK), Russ Housley, Henry Haverinen, and Joseph Salowey.
このEAP方式はEAP-アーチーおよびEAP-SIMに触発されました。ジェシー・ウォーカー（EAP-PSKの彼の徹底した挑戦的な専門家レビューのためのジェシーウォーカーに余分のおかげ）、ラスHousley、ヘンリーHaverinen、そしてジョセフSalowey：それぞれの作者に感謝します。
Thanks to
おかげ
o Henri Gilbert for some interesting discussions on the cryptographic parts of EAP-PSK.
EAP-PSKの暗号化の部分にいくつかの興味深い議論のためのOアンリ・ギルバート。
o Aurelien Magniez for his valuable feedback on network aspects of EAP-PSK, his curiosity and rigor that led to numerous improvements, and his help in the first implementation of EAP-PSK under Microsoft Windows and Freeradius.
OオーレリアンEAP-PSKのネットワーク側面の彼の貴重なフィードバックのためのMagniez、多くの改良につながった彼の好奇心と厳しさ、およびMicrosoft WindowsおよびFreeRADIUSの下EAP-PSKの最初の実装では彼の助け。
o Thomas Otto for his valuable feedback on EAP-PSK and the implementation of the first version of EAP-PSK under Xsupplicant.
EAP-PSKおよびXsupplicant下EAP-PSKの最初のバージョンの実装上の彼の貴重なフィードバックのためのトーマスオットー・O。
o Nancy Cam-Winget for some exchanges on EAP-PSK.
EAP-PSKにいくつかの交換用Oナンシー・カム・ウィンゲット。
o Jari Arkko and Bernard Aboba, the beloved EAP WG chairs, for the work they stimulate.
OヤリArkkoとバーナードAboba、彼らは刺激する仕事のための最愛のEAP WGチェア、。
Finally, thanks to Vir Z., who has brought a permanent and outstanding though discreet contribution to this protocol.
最後に、このプロトコルに永久的かつ卓越したしかし控えめな貢献をもたらしたVirのZ.、おかげ。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[2] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[3] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[4] Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of operation", FSE 04, Springer-Verlag LNCS 3017, 2004.
[4]ベラー、M.、Rogaway、P.、およびD.ワグナー、 "操作のEAXモード"、FSE 04、シュプリンガー・フェアラークLNCS 3017、2004。
[5] Gilbert, H., "The Security of One-Block-to-Many Modes of Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.
[5]ギルバート、H.、「操作の1ブロック対多モードのセキュリティ」、FSE 03、シュプリンガー・フェアラークLNCS 2287、2003。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[7] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) 197, November 2001.
[7]米国国立標準技術研究所、連邦情報処理規格（FIPS）197、2001年11月 "のAdvanced Encryption Standard（AES）のための仕様"。
[8] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", Special Publication (SP) 800-38B, May 2005.
[8]米国国立標準技術研究所、「オペレーションのブロック暗号モードのための推薦：認証のためのCMACモード」、特別刊行物（SP）800-38B、2005年5月。
[9] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz,"Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2006.
進歩、2006年10月[9] Aboba、B.、サイモン、D.、Eronen、P.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、仕事。
[10] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Walsh, P., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Xu, Y., Campell, E., Baba, S., and E. Jaques, "Criteria for Evaluating AAA Protocols for work Access", RFC 2989, November 2000.
[10] Aboba、B.、カルフーン、P.、ガラス、S.、ヒラー、T.、マッキャン、P.、椎野、H.、ゾルン、G.、Dommety、G.、パーキンス、C.、パティル、 B.、ミットン、D.、マニング、S.、Beadles、M.、ウォルシュ、P.、チェン、X.、Sivalingham、S.、ハミード、A.、マンソン、M.、ジェイコブス、S.、リム、 B.、ハーシュマン、B.、スー、R.、徐、Y.、Campell、E.、馬場、S.、およびE.・ジャック、RFC 2989、2000年11月 "仕事へのアクセスのためにAAAプロトコルを評価するための基準"。
[11] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[11] Aboba、B.及びD.シモン、 "PPP EAP TLS認証プロトコル"、RFC 2716、1999年10月。
[12] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[12] Arkko、J.とH. Haverinen、 "第3世代認証及び鍵合意（EAP-AKA）のための拡張認証プロトコル方式"、RFC 4187、2006年1月。
[13] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
[13] Arkko、J.およびP. Eronen、 "拡張認証プロトコル（EAP）に対して認証サービス情報"、進歩、2005年10月に働いています。
[14] Bellare, M. and P. Rogaway, "Entity Authentication and Key Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994.
[14]ベラー、M。およびP. Rogaway、 "エンティティ認証と鍵配布"、CRYPTO 93、シュプリンガー・フェアラークLNCS 773、1994。
[15] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure Against Dictionary attacks", EUROCRYPT 00, Springer-Verlag LNCS 1807, 2000.
[15]ベラー、M.、Pointcheval、D.、およびP. Rogaway、EUROCRYPT 00、シュプリンガー・フェアラークLNCS 1807、2000 "認証鍵交換は、辞書攻撃に対して安全"。
[16] Bersani, F., "EAP shared key methods: a tentative synthesis of those proposed so far", Work in Progress, April 2004.
[16] Bersani、F.、「EAPは、キーのメソッドを共有：これまでに提案されているものの仮合成」、進歩、2004年4月に作業を。
[17] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[17]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[18] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
[18]カールソン、J.、Aboba、B.、およびH. Haverinen、 "EAP SRP-SHA1認証プロトコル"、進歩、2001年7月ワーク。
[19] Department of Defense of the United States, "National Industrial Security Program Operating Manual", DoD 5220-22M, January 1995.
[19]米国の国防総省、「国家産業セキュリティプログラムは、マニュアルの操作」、国防総省5220-22M、1995年1月。
[20] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[20]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[21] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Work in Progress, July 2004.
[21]ファンク、P.およびS.ブレーク - ウィルソン、 "EAPトンネリングTLS認証プロトコル（EAP-TTLS）"、進歩、2004年7月ワーク。
[22] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[22]ハラー、N.、メッツ、C.、Nesser、P.、およびM.わら、 "ワンタイムパスワードシステム"、RFC 2289、1998年2月。
[23] Halpern, J. and Y. Moses, "Knowledge and common knowledge in a distributed environment", Journal of the ACM 37:3, 1990.
[23]アルペルン、J.及びY.モーゼス、 "分散環境における知識と常識"、ACM 37のジャーナル：3、1990。
[24] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
[24] Haverinen、H.及びJ. Salowey、 "移動通信用グローバルシステム（GSM）加入者識別モジュール（EAP-SIM）のための拡張認証プロトコル方法"、RFC 4186、2006年1月。
[25] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995.
[25]のHuitema、C.、ポステル、J.、およびS.クロッカー、 "すべてのRFCが標準わけではありません"、RFC 1796、1995年4月。
[26] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
[26]電気電子学会、「地方とメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御」、IEEE標準802.1X、2001年9月。
[27] Institute of Electrical and Electronics Engineers, "Approved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i-2004, 2004.
[27]電気電子技術者協会、「システム-LAN / MAN固有の要件間の通信及び情報交換のための標準に承認されたドラフトサプリメント - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：仕様セキュリティ強化」、IEEE 802.11iの-2004、2004。
[28] Institute of Electrical and Electronics Engineers, "Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[28]「電気通信及びシステム間情報交換のための標準 - LAN / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様」電気電子学会、IEEE規格802.11、 1999。
[29] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03, Springer-Verlag LNCS 2887, 2003.
[29]岩田、T.とK.黒沢、 "OMAC：ワンキーCBC MAC"、FSE 03、シュプリンガー・フェアラークLNCS 2887、2003。
[30] Jablon, D., "The SPEKE Password-Based Key Agreement Methods", Work in Progress, November 2002.
[30] Jablon、D.、 "SPEKEパスワードベースのキー契約法"、進歩、2002年11月に作業。
[31] Josefsson, S., "The EAP SecurID(r) Mechanism", Work in Progress, February 2002.
[31] Josefsson氏、S.、 "EAPのSecurID（R）機構"、進歩、2002年2月に働いています。
[32] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[32] Josefsson氏、S.、Palekar、A.、サイモン、D.、およびG.ゾルン、 "保護されたEAPプロトコル（PEAP）バージョン2"、進歩、2004年10月に働いています。
[33] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[33] Kaliski、B.、 "PKCS＃5：パスワードベースの暗号化仕様バージョン2.0"、RFC 2898、2000年9月。
[34] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions", Work in Progress, April 2004.
[34] Kamath、V.およびA. Palekar、 "マイクロソフトEAP CHAP拡張機能"、進歩、2004年4月に作業。
[35] Kent, S., "IP Authentication Header", RFC 4302, December 2005
[35]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月
[36] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems", CRYPTO 96, Springer-Verlag LNCS 1109, 1996.
[36]コッヘル、P.、 "ディフィー - ヘルマン、RSA、DSSの実装にタイミング攻撃、および他のシステム"、CRYPTO 96、シュプリンガー・フェアラークLNCS 1109、1996。
[37] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", CRYPTO 03, Springer-Verlag LNCS 2729, June 2003.
[37] Krawczyk、H.、 "SIGMA：認証済みのDiffie-HellmanのとIKEプロトコルでの使用に`サインと-MAC」アプローチ"、CRYPTO 03、シュプリンガー・フェアラークLNCS 2729、2003年6月。
[38] MacNally, C., "Cisco LEAP protocol description", September 2001, available from <http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt>.
[38] <http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt>から入手MacNally、C.、 "シスコLEAPプロトコルの説明"、2001年9月、。
[39] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[39]メス、C.、 "OTP拡張レスポンス"、RFC 2243、1997年11月。
[40] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press , 1996.
[40]メネゼス、A.、バンOorschot、P.、およびS. Vanstone著、 "応用暗号のハンドブック"、CRCプレス、1996。
[41] National Institute of Standards and Technology, "Password Usage", Federal Information Processing Standards (FIPS) 112, May 1985.
[41]米国国立標準技術研究所、「パスワードの使用」、連邦情報処理規格（FIPS）112、1985年5月。
[42] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", Work in Progress, October 2006.
進歩、2006年10月ワーク "セキュアなトンネリング拡張認証プロトコル方法（EAP-FAST）を介して、フレキシブル認証" [42]カムウィンゲット、N.、マグリュー、D.、Salowey、J.、およびH.周。
[43] Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-Verlag LNCS 1740, October 1999.
[43]シュナイアー、B.、マッジ、およびD.ワグナー、 "MicrosoftのPPTP認証拡張機能の解読法（MS-CHAPv2を）"、CQRE 99、シュプリンガー・フェアラークLNCS 1740、1999年10月。
[44] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[44]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[45] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[45]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）"、RFC 1994、1996年8月。
[46] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP IKEv2 Method", Work in Progress, October 2006.
[46] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、大場、Y.、およびF. Bersani、 "EAP IKEv2の方法"、進歩、2006年10月に作業。
[47] Walker, J. and R. Housley, "The EAP Archie Protocol", Work in Progress, June 2003.
[47]ウォーカー、J.とR. Housley氏、 "EAPアーチー・プロトコル"、進歩、2003年6月での作業。
[48] Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0", April 2003.
[48]のWi-Fi Allianceは、2003年4月には、 "Wi-Fiは、バージョン2.0を保護アクセス"。
[49] Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03, August 2003.
[49]ライト、J.、デフコン03、2003年8月 "LEAPチャレンジ/レスポンスの弱点"。
[50] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[50] Eronen、P.とH. Tschofenig、 "事前共有鍵暗号の組み合わせトランスポート層セキュリティ（TLS）のために"、RFC 4279、2005年12月。
Appendix A. Generation of the PSK from a Password - Discouraged
パスワードからPSKの付録A.の生成 - 落胆
It is formally discouraged to use a password to generate the PSK, since this opens the door to exhaustive search or dictionary attacks, two attacks that would not otherwise be possible.
これは徹底的に検索や辞書攻撃、そうでない場合は不可能であろう2回の攻撃への扉を開きますので、正式に、PSKを生成するためのパスワードを使用することが推奨されていません。
EAP-PSK only provides a 16-byte key strength when a 16-byte PSK is drawn at random from the set of all possible 16-byte strings.
EAP-PSKはわずか16バイトのPSKはすべての可能な16バイトの文字列の集合からランダムに描かれている16バイトのキー強度を提供します。
However, as people will probably do this anyway, guidance is provided hereafter to generate the PSK from a password.
しかし、人々はおそらく、とにかくこれを行いますと、ガイダンスはパスワードからPSKを生成するために、以下に提供されます。
For some hints on how passwords should be selected, please refer to [41].
パスワードを選択する必要があります方法についていくつかのヒントについては、[41]を参照してください。
The technique presented herein is drawn from [33]. It is intended to try to mitigate the risks associated with password usage in cryptography, typically dictionary attacks.
本明細書に提示される技術は、[33]から引き出されます。一般的に辞書攻撃、暗号でパスワードの使用に関連するリスクを軽減しようとすることを意図しています。
If the binary representation of the password is strictly fewer than 16 bytes long (which by the way means that the chosen password is probably weak because it is too short), then it is padded to 16 bytes with zeroes as its high-order bits.
パスワードのバイナリ表現は（方法によってそれが短すぎるため、選択されたパスワードはおそらく弱いことを意味する）厳密未満の16バイト長である場合、それはその上位ビットとしてゼロと16バイトに埋め込まれています。
If the binary representation of the password is strictly more than 16 bytes long, then it is hashed down to exactly 16 bytes using the Matyas-Meyer-Oseas hash (please refer to [40] for a description of this hash. Using the notation of Figure 9.3 of [40], g is the identity function and E is AES-128 in our construction.) with IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been arbitrarily selected).
パスワードのバイナリ表現が厳密に16以上のバイト長である場合、それはマーチャーシュ - マイヤー - Oseasハッシュを使用して正確に16バイトまでハッシュされ（このハッシュの説明については、[40]を参照してください。の表記法を使用して[40] 9.3図、Gは恒等関数であり、Eは、我々の構築にAES-128である。）IV = 0x0123456789ABCDEFFEDCBA9876543210（この値は任意に選択されている）で。
We now assume that we have a 16-byte number derived from the initial password (that can be the password itself if its binary representation is exactly 16 bytes long). We shall call this number P16.
私たちは、今、私たちは、初期パスワード（そのバイナリ表現は正確に16バイト長である場合には、パスワードそのもの可能）に由来する16バイトの番号を持っていることを前提としています。我々は、この番号P16を呼びます。
Following the notations used in [33], the PSK is derived thanks to PBKDF2 instantiated with:
[33]で使用される表記法以下、PSKを用いてインスタンス化PBKDF2のおかげで導出されます。
o P16 as P
P16のP
o The first 96 bits of the XOR of the peer and server NAIs as Salt (zero-padded in the high-order bits if necessary).
塩として、ピア及びサーバのNAIのXOR（必要に応じて上位ビットにゼロパディング）の最初の96ビットのO。
o 5000 as c
CのようなO 5000
o 16 as dkLen
16 dkLen
Although this gives better protection than nothing, this derivation does not stricto sensu protect against dictionary attacks. It only makes dictionary precomputation harder.
これは何もないよりはましな保護を与えるが、この導出はsensuのは、辞書攻撃から守るstrictoしません。それだけで辞書事前計算が難しくなります。
Authors' Addresses
著者のアドレス
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux 92794 Cedex 9 FR
フロランBersaniフランステレコムR＆D 38、RUEデュ一般ルクレールイシレムリノーCedexの9 FR 92794
EMail: bersani_florent@yahoo.fr
メールアドレス：bersani_florent@yahoo.fr
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich 81739 GE
ハンネスTschofenigシーメンスネットワークス社＆CoのKGオットー・ハーンリング6 81739ミュンヘンGE
EMail: Hannes.Tschofenig@siemens.com
メールアドレス：Hannes.Tschofenig@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。