Network Working Group T. Clancy
Request for Comments: 5433 LTS
Category: Standards Track H. Tschofenig
Nokia Siemens Networks
February 2009
Extensible Authentication Protocol -
Generalized Pre-Shared Key (EAP-GPSK) Method
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation.
このメモは、EAP一般事前共有鍵（EAP-GPSK）と呼ばれる拡張認証プロトコル（EAP）メソッドを定義します。この方法は、相互認証および鍵導出を支持する軽量共有鍵認証プロトコルです。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................6
4. Key Derivation ..................................................8
5. Key Management .................................................11
6. Ciphersuites ...................................................11
7. Generalized Key Derivation Function (GKDF) .....................12
8. Ciphersuites Processing Rules ..................................13
8.1. Ciphersuite #1 ............................................13
8.1.1. Encryption .........................................13
8.1.2. Integrity ..........................................13
8.2. Ciphersuite #2 ............................................14
8.2.1. Encryption .........................................14
8.2.2. Integrity ..........................................14
9. Packet Formats .................................................15
9.1. Header Format .............................................15
9.2. Ciphersuite Formatting ....................................16
9.3. Payload Formatting ........................................16
9.4. Protected Data ............................................21
10. Packet Processing Rules .......................................24
11. Example Message Exchanges .....................................25
12. Security Considerations .......................................28
12.1. Security Claims ..........................................28
12.2. Mutual Authentication ....................................29
12.3. Protected Result Indications .............................29
12.4. Integrity Protection .....................................29
12.5. Replay Protection ........................................30
12.6. Reflection Attacks .......................................30
12.7. Dictionary Attacks .......................................30
12.8. Key Derivation and Key Strength ..........................31
12.9. Denial-of-Service Resistance .............................31
12.10. Session Independence ....................................32
12.11. Compromise of the PSK ...................................32
12.12. Fragmentation ...........................................32
12.13. Channel Binding .........................................32
12.14. Fast Reconnect ..........................................33
12.15. Identity Protection .....................................33
12.16. Protected Ciphersuite Negotiation .......................33
12.17. Confidentiality .........................................34
12.18. Cryptographic Binding ...................................34
13. IANA Considerations ...........................................34
14. Contributors ..................................................35
15. Acknowledgments ...............................................36
16. References ....................................................37
16.1. Normative References .....................................37
16.2. Informative References ...................................38
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a generalized pre-shared key authentication technique. Mutual authentication is achieved through a nonce-based exchange that is secured by a pre-shared key.
EAP一般事前共有鍵（EAP-GPSK）は、一般事前共有鍵認証技術を定義するEAPメソッドです。相互認証は、事前共有キーで固定されているナンスベースの交換によって達成されます。
EAP-GPSK addresses a large number of design goals with the intention of being applicable in a broad range of usage scenarios.
EAP-GPSKは、使用シナリオの幅広い範囲で適用可能であることを意図して設計目標を大量に対処しています。
The main design goals of EAP-GPSK are:
EAP-GPSKの主な設計目標は以下のとおりです。
Simplicity:
シンプル：
EAP-GPSK should be easy to implement.
EAP-GPSKは、実装が容易でなければなりません。
Security Model:
セキュリティモデル：
EAP-GPSK has been designed in a threat model where the attacker has full control over the communication channel. This EAP threat model is presented in Section 7.1 of [RFC3748].
EAP-GPSKは、攻撃者が通信チャネルを介して完全な制御を有する脅威モデルに設計されています。このEAPの脅威モデルは、[RFC3748]のセクション7.1に提示されています。
Efficiency:
効率：
EAP-GPSK does not make use of public key cryptography and fully relies of symmetric cryptography. The restriction of symmetric cryptographic computations allows for low computational overhead. Hence, EAP-GPSK is lightweight and well suited for any type of device, especially those with processing power, memory, and battery constraints. Additionally, it seeks to minimize the number of round trips.
EAP-GPSKは、公開鍵暗号方式を利用して、完全に対称暗号の依存しません。対称暗号計算の制限は、低い計算オーバヘッドを可能にします。したがって、EAP-GPSKは、軽量で、デバイスの任意の種類、処理能力、メモリ、およびバッテリ制約を特によく適しています。さらに、それは、ラウンドトリップの数を最小限にすることを目指しています。
Flexibility:
柔軟性：
EAP-GPSK offers cryptographic flexibility. At the beginning, the EAP server proposes a list of ciphersuites. The client then selects one. The current version of EAP-GPSK includes two ciphersuites, but additional ones can be easily added.
EAP-GPSKは、暗号化の柔軟性を提供しています。初めに、EAPサーバは、暗号スイートのリストを提案しています。クライアントは、1つを選択します。 EAP-GPSKの現在のバージョンは、二つの暗号スイートを含むが、付加的なものを容易に追加することができます。
Extensibility:
拡張性：
The design of EAP-GPSK allows to securely exchange information between the EAP peer and the EAP server using protected data fields. These fields might, for example, be used to exchange channel binding information or to provide support for identity confidentiality.
EAP-GPSKの設計を確実EAPピアと保護されたデータフィールドを使用して、EAPサーバ間で情報を交換することを可能にします。これらのフィールドは、例えば、チャネルバインディング情報を交換したり、アイデンティティの機密性のためのサポートを提供するために使用される可能性があります。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section describes the various variables and functions used in the EAP-GPSK method.
このセクションでは、EAP-GPSK法で使用される種々の変数および関数を記述しています。
Variables:
変数：
CSuite_List: An octet array listing available ciphersuites (variable length).
CSuite_List：使用可能な暗号スイートをリストオクテット配列（可変長）。
CSuite_Sel: Ciphersuite selected by the peer (6 octets).
CSuite_Sel：も、Ciphersuiteピア（6つのオクテット）で選択。
ID_Peer: Peer Network Access Identifier (NAI) [RFC4282].
ID_Peer：ネットワークアクセス識別子（NAI）[RFC4282]をピア。
ID_Server: Server identity as an opaque blob.
ID_Server：不透明ブロブとしてサーバーのID。
KS: Integer representing the input key size, in octets, of the selected ciphersuite CSuite_Sel. The key size is one of the ciphersuite parameters.
KS：選択された暗号スイートCSuite_Selのオクテット入力キーのサイズを表す整数、、。キーのサイズは暗号スイートのパラメータの一つです。
ML: Integer representing the length of the Message Authentication Code (MAC) output, in octets, of the selected ciphersuite CSuite_Sel.
ML：選択された暗号スイートのCSuite_Selのオクテットにメッセージ認証コード（MAC）の出力の長さを表す整数。
PD_Payload: Data carried within the protected data payload.
PD_Payload：保護されたデータペイロード内に運ばれたデータ。
PD_Payload_Block: Block of possibly multiple PD_Payloads carried by a GPSK packet.
PD_Payload_Block：GPSKパケットによって運ばれる可能性が複数のPD_Payloadsのブロック。
PL: Integer representing the length of the PSK in octets (2 octets). PL MUST be larger than or equal to KS.
PL：オクテットでPSKの長さを表す整数（2つのオクテット）。 PLはKSより大きいか等しくなければなりません。
RAND_Peer: Random integer generated by the peer (32 octets).
RAND_Peer：ピア（32オクテット）によって生成されたランダム整数。
RAND_Server: Random integer generated by the server (32 octets).
RAND_Server：サーバ（32オクテット）によって生成されたランダム整数。
Operations:
オペレーション：
A || B: Concatenation of octet strings A and B.
|| B：オクテットストリングの連結AおよびB.
A**B: Integer exponentiation.
** B：整数累乗。
truncate(A,B): Returns the first B octets of A.
（A、B）切り捨てる：Aの最初のBオクテットを返します。
ENC_X(Y): Encryption of message Y with a symmetric key X, using a defined block cipher.
ENC_X（Y）：対称鍵XとYメッセージの暗号化、定義されたブロック暗号を使用して。
KDF-X(Y): Key Derivation Function that generates an arbitrary number of octets of output using secret X and seed Y.
KDF-X（Y）：秘密XとシードYを使用して出力のオクテットの任意の数を生成する鍵導出関数
length(X): Function that returns the length of input X in octets, encoded as a 2-octet integer in network byte order.
長さ（X）：オクテット単位で入力Xの長さを返す関数、ネットワークバイト順に2オクテットの整数として符号化されます。
MAC_X(Y): Keyed message authentication code computed over Y with symmetric key X.
MAC_X（Y）：対称鍵XとYにわたって計算キー付きメッセージ認証コード
SEC_X(Y): SEC is a function that provides integrity protection based on the chosen ciphersuite. The function SEC uses the algorithm defined by the selected ciphersuite and applies it to the message content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y).
SEC_X（Y）：SECは、選択した暗号スイートに基づいて、完全性保護を提供する機能です。関数SECは、選択された暗号スイートによって定義されたアルゴリズムを使用し、要するに鍵Xとメッセージ内容Yに適用し、SEC_X（Y）= Y || MAC_X（Y）。
X[A..B]: Notation representing octets A through B of octet array X where the first octet of the array has index zero.
X [A..B]：アレイの最初のオクテットインデックスゼロを有するオクテット配列XのBを介しオクテットAを表す表記法。
The following abbreviations are used for the keying material:
以下の略語が鍵素材に使用されます。
EMSK: Extended Master Session Key is exported by the EAP method (64 octets).
EMSK：拡張マスターセッションキーは、EAPメソッド（64オクテット）によってエクスポートされます。
MK: A session-specific Master Key between the peer and EAP server from which all other EAP method session keys are derived (KS octets).
MK：他のすべてのEAPメソッドセッションキーが導出されるピアとEAPサーバ（KSオクテット）との間のセッション固有のマスターキー。
MSK: Master Session Key exported by the EAP method (64 octets).
MSK：EAPメソッド（64オクテット）によってエクスポートされたマスターセッションキー。
PK: Session key generated from the MK and used during protocol exchange to encrypt protected data (KS octets).
PK：セッション鍵MKから生成され、保護されたデータ（KSオクテット）を暗号化するプロトコル交換時に使用されます。
PSK: Long-term key shared between the peer and the server (PL octets).
PSK：ピアとサーバ（PLオクテット）との間で共有長期キー。
SK: Session key generated from the MK and used during protocol exchange to demonstrate knowledge of the PSK (KS octets).
SK：セッションキーMKから生成され、PSK（KSオクテット）の知識を実証するプロトコル交換時に使用されます。
The EAP framework (see Section 1.3 of [RFC3748]) defines three basic steps that occur during the execution of an EAP conversation between the EAP peer, the Authenticator, and the EAP server.
EAPフレームワークは、（[RFC3748]のセクション1.3を参照）EAPピアとの間のEAPの会話の実行、認証、及びEAPサーバの間に存在する3つの基本的な手順を定義しています。
1. The first phase, discovery, is handled by the underlying protocol, e.g., IEEE 802.1X as utilized by IEEE 802.11 [80211].
1.第一段階、発見、基礎となるプロトコルによって処理され、例えば、IEEE 802.1Xは、IEEE 802.11 [80211]で利用されます。
2. The EAP authentication phase with EAP-GPSK is defined in this document.
2. EAP-GPSKとEAP認証フェーズは、このドキュメントで定義されています。
3. The secure association distribution and secure association phases are handled differently depending on the underlying protocol.
3.セキュアアソシエーション分布と安全な会合相は、基礎となるプロトコルに応じて異なる方法で処理されます。
EAP-GPSK performs mutual authentication between the EAP peer ("Peer") and EAP server ("Server") based on a pre-shared key (PSK). The protocol consists of the message exchanges (GPSK-1, ..., GPSK-4) in which both sides exchange nonces and their identities, and compute and exchange a Message Authentication Code (MAC) over the previously exchanged values, keyed with the pre-shared key. This MAC is considered as proof of possession of the pre-shared key. Two further messages, namely GPSK-Fail and GPSK-Protected-Fail, are used to deal with error situations.
EAP-GPSKは、事前共有鍵（PSK）に基づくEAPピア（「ピア」）とEAPサーバ（「サーバ」）との間の相互認証を行います。プロトコルはでキーイング、メッセージ交換（GPSK-1、...、GPSK-4）両側がノンスと身元を交換し、そして以前に交換された値の上にメッセージ認証コード（MAC）を計算し、交換したから成り事前共有鍵。このMACは、事前共有キーを所有していることの証明と考えられています。さらに二つのメッセージ、すなわちGPSKフェイルとGPSK - 保護 - 失敗は、エラー状況に対処するために使用されています。
A successful protocol exchange is shown in Figure 1.
成功したプロトコル交換は、図1に示されています。
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-4 | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: EAP-GPSK: Successful Exchange
図1：EAP-GPSK：成功した取引
The full EAP-GPSK protocol is as follows:
次のように完全なEAP-GPSKプロトコルは次のとおりです。
GPSK-1:
GPSK-1：
ID_Server, RAND_Server, CSuite_List
ID_Server、RAND_Server、CSuite_List
GPSK-2:
GPSK-2：
SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
SEC_SK（ID_Peer、ID_Server、RAND_Peer、RAND_Server、CSuite_List、CSuite_Sel、[ENC_PK（PD_Payload_Block）]）
GPSK-3:
GPSK-3：
SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
SEC_SK（RAND_Peer、RAND_Server、ID_Server、CSuite_Sel、[ENC_PK（PD_Payload_Block）]）
GPSK-4:
GPSK-4：
SEC_SK( [ ENC_PK(PD_Payload_Block) ] )
SEC_SK（[ENC_PK（PD_Payload_Block）]）
The EAP server begins EAP-GPSK by selecting a random number RAND_Server and encoding the supported ciphersuites into CSuite_List. A ciphersuite consists of an encryption algorithm, a key derivation function, and a message authentication code.
EAPサーバは、乱数RAND_Serverを選択し、CSuite_Listにサポートする暗号スイートを符号化することにより、EAP-GPSKを開始します。暗号スイートは、暗号化アルゴリズム、鍵導出関数、およびメッセージ認証コードから成ります。
In GPSK-1, the EAP server sends its identity ID_Server, a random number RAND_Server, and a list of supported ciphersuites CSuite_List. The decision of which ciphersuite to offer and which ciphersuite to pick is policy- and implementation-dependent and, therefore, outside the scope of this document.
GPSK-1では、EAPサーバは、そのアイデンティティID_Server、乱数RAND_Server、およびサポートされている暗号スイートCSuite_Listのリストを送信します。提供する暗号スイートおよび選択する暗号スイートその決定は、この文書の範囲外で、従って、政策及び実装依存であり。
In GPSK-2, the peer sends its identity ID_Peer and a random number RAND_Peer. Furthermore, it repeats the received parameters of the GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected ciphersuite. It computes a Message Authentication Code over all the transmitted parameters.
GPSK-2において、ピアはそのアイデンティティID_Peerと乱数RAND_Peerを送信します。また、GPSK-1メッセージ（ID_Server、RAND_Server、CSuite_List）および選択された暗号スイートの受信されたパラメータを繰り返します。これは、すべての送信されたパラメータを介してメッセージ認証コードを計算します。
The EAP server verifies the received Message Authentication Code and the consistency of the identities, nonces, and ciphersuite parameters transmitted in GPSK-1. In case of successful verification, the EAP server computes a Message Authentication Code over the session parameter and returns it to the peer (within GPSK-3). Within GPSK-2 and GPSK-3, the EAP peer and EAP server have the possibility to exchange encrypted protected data parameters.
EAPサーバは、受信したメッセージ認証コードとGPSK-1で送信アイデンティティ、ノンス、および暗号スイートパラメータの整合性を検証します。検証が成功の場合には、EAPサーバは、セッションパラメータを介してメッセージ認証コードを計算し、（GPSK-3内の）ピアに返します。 GPSK-2及びGPSK-3内に、EAPピアとEAPサーバは、暗号化され保護されたデータパラメータを交換する可能性を有しています。
The peer verifies the received Message Authentication Code and the consistency of the identities, nonces, and ciphersuite parameters transmitted in GPSK-2. If the verification is successful, GPSK-4 is prepared. This message can optionally contain the peer's protected data parameters.
ピアは、受信したメッセージ認証コードとGPSK-2で送信アイデンティティ、ノンス、および暗号スイートパラメータの整合性を検証します。検証に成功した場合、GPSK-4を用意します。このメッセージは、必要に応じてピアの保護されたデータのパラメータを含めることができます。
Upon receipt of GPSK-4, the server processes any included PD_Payload_Block. Then, the EAP server sends an EAP Success message to indicate the successful outcome of the authentication.
GPSK-4を受信すると、サーバプロセスは、任意PD_Payload_Blockを含んでいました。その後、EAPサーバは、認証の成功した結果を示すために、EAP Successメッセージを送信します。
EAP-GPSK provides key derivation in compliance to the requirements of [RFC3748] and [RFC5247]. Note that this section provides an abstract description for the key derivation procedure that needs to be instantiated with a specific ciphersuite.
EAP-GPSKは[RFC3748]及び[RFC5247]の要件に準拠して鍵導出を提供します。このセクションでは、特定の暗号スイートでインスタンス化される必要がある鍵導出手順について抽象記述を提供することに留意されたいです。
The long-term credential shared between EAP peer and EAP server SHOULD be a strong pre-shared key PSK of at least 16 octets, though its length and entropy are variable. While it is possible to use a password or passphrase, doing so is NOT RECOMMENDED as EAP-GPSK is vulnerable to dictionary attacks.
その長さとエントロピーが可変であるけれどもEAPピアとEAPサーバの間で共有長期信任状は、少なくとも16オクテットの強い事前共有鍵PSKであるべきです。パスワードやパスフレーズを使用することも可能であるがEAP-GPSKは辞書攻撃に対して脆弱であるとして、そうすることは推奨されません。
During an EAP-GPSK authentication, a Master Key MK, a Session Key SK, and a Protected Data Encryption Key PK (if using an encrypting ciphersuite) are derived using the ciphersuite-specified KDF and data exchanged during the execution of the protocol, namely 'RAND_Peer || ID_Peer || RAND_Server || ID_Server', referred to as inputString in its short-hand form.
EAP-GPSK認証時に、マスターキーMK、セッションキーSK、および保護されたデータ暗号化鍵PK（暗号化暗号スイートを使用している場合）は、暗号スイートが指定したKDFを使用して導出されたデータは、すなわち、プロトコルの実行中に交換しました「RAND_Peer || ID_Peer || RAND_Server || ID_Server」は、その短手形でinputStringからと称します。
In case of successful completion, EAP-GPSK derives and exports an MSK and an EMSK, each 64 octets in length.
正常終了の場合には、EAP-GPSKを導出し、MSK及びEMSK、それぞれ長さ64個のオクテットをエクスポート。
The following notation is used: KDF-X(Y, Z)[A..B], whereby
以下の表記が使用される：KDF-X（Y、Z）A..B]、それによって
X is the length, in octets, of the desired output,
Xは、所望の出力を、オクテット単位で、長さ
Y is a secret key,
Yは秘密鍵であり、
Z is the inputString,
Zは、inputStringからです
[A..B] extracts the string of octets starting with octet A and finishing with octet B from the output of the KDF function.
【A..B]オクテットAで開始し、KDF関数の出力からオクテットBと仕上げオクテットの文字列を抽出します。
This keying material is derived using the ciphersuite-specified KDF as follows:
この鍵材料は、以下のように暗号の指定KDFを用いて導出されます。
o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
O inputStringから= RAND_Peer || ID_Peer || RAND_Server || ID_Server
o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || inputString)[0..KS-1]
O MK = KDF-KS（PSK [0..KS-1]、PL || PSK || || CSuite_Sel inputStringから）0..KS-1]
o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
MSK KDF- 0 = {128 + 2 * KS}（MK、inputStringから）[0 63]
o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
O EMSK = KDF- {128 + 2 * KS}（MK、inputStringから）[64..127]
o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
O SK = KDF- {128 + 2 * KS}（MK、inputStringから）[128..127 + KS]
o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using an encrypting ciphersuite)
O PK = KDF- {128 + 2 * KS}（MK、inputStringから）[128 + KS..127 + 2 * KS]（暗号化暗号スイートを使用する場合）
The value for PL (the length of the PSK in octets) is encoded as a 2-octet integer in network byte order. Recall that KS is the length of the ciphersuite input key size in octets.
PL（オクテットでPSKの長さ）の値は、ネットワークバイト順に2オクテットの整数として符号化されます。 KSはオクテットで暗号スイートの入力キーサイズの長さであることを思い出してください。
Additionally, the EAP keying framework [RFC5247] requires the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These values are defined as:
さらに、フレームワーク[RFC5247]をキーイングEAPは、メソッドID、セッションID、ピアID、およびサーバIDの定義を必要とします。これらの値は以下のように定義されています。
o Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type || CSuite_Sel || inputString)[0..15]
Oメソッド-ID = KDF-16（PSK [0..KS-1]、 "メソッドID" || || EAP_Method_Type CSuite_Sel || inputStringから）[0..15]
o Session-ID = EAP_Method_Type || Method_ID
セッションID = EAP_Method_Type O || Method_ID
o Peer-ID = ID_Peer
Oピア-ID = ID_Peer
o Server-ID = ID_Server
Oサーバ-ID = ID_Server
EAP_Method_Type refers to the 1-octet, IANA-allocated EAP Type code value.
EAP_Method_Typeは1オクテット、IANA割り当てEAPタイプコード値を意味します。
Figure 2 depicts the key derivation procedure of EAP-GPSK.
図2は、EAP-GPSKの鍵導出手順を示します。
+-------------+ +-------------------------------+
| PL-octet | | RAND_Peer || ID_Peer || |
| PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+
| | |
| +------------+ | |
| | CSuite_Sel | | |
| +------------+ | |
| | | |
v v v |
+--------------------------------------------+ |
| KDF | |
+--------------------------------------------+ |
| |
v |
+-------------+ |
| KS-octet | |
| MK | |
+-------------+ |
| |
v v
+---------------------------------------------------+
| KDF |
+---------------------------------------------------+
| | | |
v v v v
+---------+ +---------+ +----------+ +----------+
| 64-octet| | 64-octet| | KS-octet | | KS-octet |
| MSK | | EMSK | | SK | | PK |
+---------+ +---------+ +----------+ +----------+
Figure 2: EAP-GPSK Key Derivation
図2：EAP-GPSK鍵の導出
In order to be interoperable, PSKs must be entered in the same way on both the peer and server. The management interface for entering PSKs MUST support entering PSKs up to 64 octets in length as ASCII strings and in hexadecimal encoding.
相互運用可能であるためには、PSKsは、ピアとサーバーの両方で同じように入力する必要があります。 PSKsを入力するための管理インターフェイスは、ASCII文字列としての16進符号の長さは64オクテットまでPSKsに入るサポートしなければなりません。
Additionally, the ID_Peer and ID_Server MUST be provisioned with the PSK. Validation of these values is by an octet-wise comparison. The management interface SHOULD support entering non-ASCII octets for the ID_Peer and ID_Server up to 254 octets in length. For more information, the reader is advised to read Section 2.4 of RFC 4282 [RFC4282].
さらに、ID_PeerとID_ServerはPSKでプロビジョニングする必要があります。これらの値の検証は、オクテット単位の比較です。管理インターフェイスは、長さが254オクテットまでID_PeerとID_Serverのために非ASCIIオクテットを入力サポートすべきです。詳細については、読者は、RFC 4282 [RFC4282]のセクション2.4を読むことをお勧めします。
The design of EAP-GPSK allows cryptographic algorithms and key sizes, called ciphersuites, to be negotiated during the protocol run. The ability to specify block-based and hash-based ciphersuites is offered. Extensibility is provided with the introduction of new ciphersuites; this document specifies an initial set. The CSuite/ Specifier column in Figure 3 uniquely identifies a ciphersuite.
EAP-GPSKのデザインは、プロトコルの実行中にネゴシエートされるように、暗号スイートと呼ばれる、暗号化アルゴリズムとキーサイズを可能にします。ブロックベースとハッシュベースの暗号群を指定する機能が提供されています。拡張性は、新たな暗号スイートの導入に備えています。この文書では、最初のセットを指定します。図3のCSuite /指定子列を一意暗号スイートを識別する。
For a vendor-specific ciphersuite, the first four octets are the vendor-specific enterprise number that contains the IANA-assigned "SMI Network Management Private Enterprise Codes" value (see [ENTNUM]), encoded in network byte order. The last two octets are vendor assigned for the specific ciphersuite. A vendor code of 0x00000000 indicates ciphersuites standardized by the IETF in an IANA-maintained registry.
ベンダー固有の暗号群の場合は、最初の4つのオクテットは、ネットワークバイト順に符号化IANAによって割り当てられた「SMIネットワークマネージメント私企業コード」値を（[ENTNUM]参照）、含まれているベンダー固有のエンタープライズ番号です。最後の2つのオクテットは、ベンダー固有の暗号スイートのために割り当てられています。 0x00000000のベンダコードはIANA-維持レジストリにIETFによって標準化暗号スイートを示しています。
The following ciphersuites are specified in this document (recall that KS is the length of the ciphersuite input key length in octets, and ML is the length of the MAC output in octets):
以下の暗号スイートは、このドキュメント（KSオクテットで暗号の入力鍵長の長さであり、MLはオクテットでMAC出力の長さであることを想起されたい）で指定されています。
+-----------+----+-------------+----+--------------+----------------+
| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |
| Specifier | | | | KDF MAC | Function |
+-----------+----+-------------+----+--------------+----------------+
| 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
| 0x0002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
Figure 3: Ciphersuites
図3：暗号の組み合わせ
Ciphersuite 1, which is based on the Advanced Encryption Standard (AES) as a cryptographic primitive, MUST be implemented. This document specifies also a second ciphersuite, which MAY be implemented. Both ciphersuites defined in this document make use of the Generalized Key Derivation Function (GKDF), as defined in Section 7. The following aspects need to be considered to ensure that the PSK that is used as input to the GKDF is sufficiently long:
暗号プリミティブとしてのAdvanced Encryption Standard（AES）に基づいている暗号スイート1は、実施されなければなりません。この文書は実装されてもよい第二暗号スイートを指定します。以下の側面がGKDFへの入力として使用されるPSKが十分に長いことを確実にするために検討する必要があるセクション7で定義された、この文書で定義された両方の暗号スイートは、一般鍵導出関数（GKDF）を利用します。
1. The PSK used with ciphersuite 1 MUST be 128 bits in length. Keys longer than 128 bits will be truncated.
1.暗号スイート1を使用PSKは、長さが128ビットでなければなりません。 128ビットより長いキーは切り捨てられます。
2. The PSK used with ciphersuite 2 MUST be 256 bits in length. Keys longer than 256 bits will be truncated.
2.暗号スイート2と一緒に使用PSKの長さは256ビットでなければなりません。 256ビットより長いキーは切り捨てられます。
3. It is RECOMMENDED that 256 bit keys be provisioned in all cases to provide enough entropy for all current and many possible future ciphersuites.
3. 256ビットの鍵は、すべての現在および多くの可能な将来の暗号スイートのための十分なエントロピーを提供するために、すべてのケースでプロビジョニングすることが推奨されます。
Ciphersuites defined in the future that make use of the GKDF need to specify a minimum PSK size (as is done with the ciphersuites listed in this document).
GKDFを利用して、将来的に定義された暗号スイートは、（この文書に記載されている暗号スイートで行われているように）最小PSKサイズを指定する必要があります。
Each ciphersuite needs to specify a key derivation function. The ciphersuites defined in this document make use of the Generalized Key Derivation Function (GKDF) that utilizes the MAC function defined in the ciphersuite. Future ciphersuites can use any other formally specified KDF that takes as arguments a key and a seed value, and produces at least 128+2*KS octets of output.
各暗号スイートは、鍵導出関数を指定する必要があります。この文書で定義された暗号スイートは、暗号スイートで定義されたMAC機能を利用して一般化鍵導出関数（GKDF）を利用します。将来の暗号スイートは、引数として鍵およびシード値をとり、出力の少なくとも128個の+ 2 * KSオクテットを生成する任意の他の正式に指定されたKDFを使用することができます。
GKDF has the following structure:
GKDFは、以下の構造を有します：
GKDF-X(Y, Z)
GKDF-X（Y、Z）
X length, in octets, of the desired output
Xの長さ、オクテットで、所望の出力
Y secret key
Y秘密鍵
Z inputString
Z inputStringから
GKDF-X (Y, Z)
{
n = ceiling integer of ( X / ML );
/* determine number of output blocks */
result = "";
結果= "";
for i = 1 to n { result = result || MAC_Y (i || Z); }
N {結果=結果にI = 1 || MAC_Y（iはZを||）。 }
return truncate(result, X) }
戻りTRUNCATE（その結果、X）}
Note that the variable 'i' in M_i is represented as a 2-octet value in network byte order.
「i」はM_I変数は、ネットワークバイト順に2オクテット値として表されることに留意されたいです。
With this ciphersuite, all cryptography is built around a single cryptographic primitive, AES-128 ([AES]). Within the protected data frames, AES-128 is used in the Cipher Block Chaining (CBC) mode of operation (see [CBC]). This EAP method uses encryption in a single payload, in the protected data payload (see Section 9.4).
この暗号スイートを用いて、すべて暗号化は、単一の暗号プリミティブ、AES-128（[AES]）を中心に構築されています。保護されたデータフレーム内に、AES-128が操作の暗号ブロック連鎖（CBC）モードで使用されている（[CBC]を参照）。このEAP方法は、単一のペイロードに暗号化を使用して、保護されたデータペイロードに（9.4節を参照してください）。
In a nutshell, the CBC mode proceeds as follows. The IV is XORed with the first plaintext block before it is encrypted. Then for successive blocks, the previous ciphertext block is XORed with the current plaintext, before it is encrypted.
次のように簡単に言えば、CBCモードが進行します。 IVは、それが暗号化される前に、最初の平文ブロックとXORされます。それが暗号化される前に、次に連続するブロックのために、前の暗号文ブロックが、現在の平文とXORされます。
Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is recommended by NIST. Among its advantages, CMAC is capable to work with messages of arbitrary length. A detailed description of CMAC can be found in [CMAC].
暗号スイート1は、メッセージ認証コードとしてCMACを使用しています。 CMACは、NISTによって推奨されています。その利点の中でも、CMACは、任意の長さのメッセージで動作することが可能です。 CMACの詳細な説明は、[CMAC]に見出すことができます。
The following instantiation is used: AES-CMAC-128(SK, Input) denotes the MAC of Input under the key SK where Input refers to the following content:
次のインスタンスが使用される：AES-CMAC-128（SK、入力）入力は、以下の内容を意味する鍵SK下入力のMACを表します。
o Parameter within SEC_SK(Parameter) in message GPSK-2
メッセージGPSK-2中のO SEC_SK内のパラメータ（パラメータ）
o Parameter within SEC_SK(Parameter) in message GPSK-3
メッセージGPSK-3 O SEC_SK内のパラメータ（パラメータ）
o Parameter within SEC_SK(Parameter) in message GPSK-4
メッセージGPSK-4中のO SEC_SK内のパラメータ（パラメータ）
Ciphersuite 2 does not include an algorithm for encryption. With a NULL encryption algorithm, encryption is defined as:
暗号スイート2は、暗号化のためのアルゴリズムが含まれていません。 NULL暗号化アルゴリズムでは、暗号化は次のように定義されています。
E_X(Y) = Y
E_x（Y）= Y
When using this ciphersuite, the data exchanged inside the protected data block is not encrypted. Therefore, this mode MUST NOT be used if confidential information appears inside the protected data block.
この暗号スイートを使用する場合は、保護されたデータブロック内で交換されるデータは暗号化されません。機密情報が保護されたデータブロック内で表示された場合そのため、このモードを使用してはいけません。
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash algorithm (see [RFC4634]).
暗号スイート2は、SHA256ハッシュアルゴリズム（[RFC4634]を参照）を用いて、鍵付きMAC関数HMACを使用します。
For integrity protection, the following instantiation is used:
完全性保護のために、次のインスタンスが使用されます。
HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK where Input refers to the following content:
HMAC-SHA256（SK、入力）入力は、以下の内容を意味する鍵SK下入力のMACを表します。
o Parameter within SEC_SK(Parameter) in message GPSK-2
メッセージGPSK-2中のO SEC_SK内のパラメータ（パラメータ）
o Parameter within SEC_SK(Parameter) in message GPSK-3
メッセージGPSK-3 O SEC_SK内のパラメータ（パラメータ）
o Parameter within SEC_SK(Parameter) in message GPSK-4
メッセージGPSK-4中のO SEC_SK内のパラメータ（パラメータ）
This section defines the packet format of the EAP-GPSK messages.
このセクションでは、EAP-GPSKメッセージのパケットフォーマットを定義します。
The EAP-GPSK header has the following structure:
EAP-GPSKヘッダは、以下の構造を有します。
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-GPSK Header
図4：EAP-GPSKヘッダ
The Code, Identifier, Length, and Type fields are all part of the EAP header and are defined in [RFC3748]. The Type field in the EAP header MUST be the value allocated by IANA for EAP-GPSK.
コード、識別子、長さ、タイプフィールドはEAPヘッダーのすべての部分であり、[RFC3748]で定義されています。 EAPヘッダーのタイプフィールドはEAP-GPSKためのIANAによって割り当てられた値である必要があります。
The OP-Code field is one of 6 values:
OP-Codeフィールドは、6つの値のいずれかです。
o 0x00 : Reserved
0x00のO：予約
o 0x01 : GPSK-1
Oが0x01：GPSK-1
o 0x02 : GPSK-2
O 0×02：GPSK-2
o 0x03 : GPSK-3
O 0×03：GPSK-3
o 0x04 : GPSK-4
O 0x04を：GPSK-4
o 0x05 : GPSK-Fail
0x05のO：GPSKフェイル
o 0x06 : GPSK-Protected-Fail
0x06のO：GPSK - 保護 - 失敗
All other values of this OP-Code field are available via IANA registration.
このOPコード・フィールドの他のすべての値は、IANA登録を経由して利用できます。
Ciphersuites are encoded as 6-octet arrays. The first four octets indicate the CSuite/Vendor field. For vendor-specific ciphersuites, this represents the vendor enterprise number and contains the IANA-assigned "SMI Network Management Private Enterprise Codes" value (see [ENTNUM]), encoded in network byte order. The last two octets indicate the CSuite/Specifier field, which identifies the particular ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates ciphersuites allocated by the IETF.
暗号スイートは、6オクテットのアレイとして符号化されます。最初の4つのオクテットはCSuite /ベンダーフィールドを示しています。ベンダー固有の暗号スイートの場合、これは、ベンダ企業の数を表し、ネットワークバイト順に符号化されたIANAによって割り当てられた「SMIネットワーク管理プライベート企業コード」値（[ENTNUM]を参照）を含みます。最後の2つのオクテットは、特定の暗号スイートを識別するCSuite /指定子フィールドを示します。 4オクテットCSuite /ベンダー値0x00000000のは、IETFによって割り当てられた暗号スイートを示しています。
Graphically, they are represented as:
グラフィカルに、彼らは次のように表現されます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Vendor = 0x00000000 or enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Ciphersuite Formatting
図5：フォーマットも、Ciphersuite
CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and CSuite/Specifier pair.
CSuite_Selは6オクテットの暗号スイートのCSuite /ベンダーとCSuite /指定子ペアとして符号化されます。
CSuite_List is a variable-length octet array of ciphersuites. It is encoded by concatenating encoded ciphersuite values. Its length in octets MUST be a multiple of 6.
CSuite_Listは暗号スイートの可変長オクテット列です。これは、符号化された暗号スイート値を連結することによって符号化されます。オクテットで、その長さが6の倍数でなければなりません。
Payload formatting is based on the protocol exchange description in Section 3.
ペイロード書式はセクション3のプロトコル交換の記述に基づいています。
The GPSK-1 payload format is defined as follows:
次のようにGPSK-1ペイロードフォーマットが定義されます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GPSK-1 Payload
図6：GPSK-1ペイロード
The GPSK-2 payload format is defined as follows:
次のようにGPSK-2ペイロードフォーマットが定義されます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Peer) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GPSK-2 Payload
図7：GPSK-2ペイロード
If the optional protected data payload is not included, then length(PD_Payload_Block)=0 and the PD payload is excluded. The payload MAC covers the entire packet, from the ID_Peer length through the optional PD_Payload_Block.
オプションの保護されたデータペイロードが含まれていない場合は、長さ（PD_Payload_Block）= 0とPDペイロードは除外されます。ペイロードMACはID_Peer長から任意PD_Payload_Block介して、パケット全体を覆っています。
The GPSK-3 payload is defined as follows:
次のようにGPSK-3ペイロードに定義されます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GPSK-3 Payload
図8：GPSK-3ペイロード
If the optional protected data payload is not included, then length(PD_Payload_Block)=0 and the PD payload is excluded. The payload MAC covers the entire packet, from the RAND_Peer through the optional PD_Payload_Block.
オプションの保護されたデータペイロードが含まれていない場合は、長さ（PD_Payload_Block）= 0とPDペイロードは除外されます。ペイロードMACはRAND_Peerから任意PD_Payload_Block介して、パケット全体を覆っています。
The GPSK-4 payload format is defined as follows:
次のようにGPSK-4ペイロードフォーマットが定義されます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(PD_Payload_Block) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GPSK-4 Payload
図9：GPSK-4ペイロード
If the optional protected data payload is not included, then length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC MUST always be included, regardless of the presence of PD_Payload_Block. The payload MAC covers the entire packet, from the PD_Payload_Block length through the optional PD_Payload_Block.
オプションの保護されたデータペイロードが含まれていない場合は、長さ（PD_Payload_Block）= 0とPDペイロードは除外されます。 MACは関係なく、常にPD_Payload_Blockの存在を、含まれなければなりません。ペイロードMACは、オプションPD_Payload_Block介してPD_Payload_Blockの長さから、パケット全体を覆っています。
The GPSK-Fail payload format is defined as follows:
次のようにGPSKフェイルペイロードフォーマットが定義されます。
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: GPSK-Fail Payload
図10：GPSKフェイルペイロード
The GPSK-Protected-Fail payload format is defined as follows:
次のようにGPSK-プロテクト失敗ペイロードフォーマットが定義されます。
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: GPSK-Protected-Fail Payload
図11：GPSK - 保護 - 失敗ペイロード
The Failure-Code field is one of three values, but can be extended:
失敗-Codeフィールドは、3つの値のいずれかですが、拡張することができます。
o 0x00000000 : Reserved
0x00000000のO：予約
o 0x00000001 : PSK Not Found
0x00000001のO：PSKが見つかりません
o 0x00000002 : Authentication Failure
O 0x00000002：認証エラー
o 0x00000003 : Authorization Failure
認証の失敗：0x00000003 O
All other values of this field are available via IANA registration.
この分野の他のすべての値は、IANA登録を経由して利用できます。
"PSK Not Found" indicates a key for a particular user could not be located, making authentication impossible. "Authentication Failure" indicates a MAC failure due to a PSK mismatch. "Authorization Failure" indicates that while the PSK being used is correct, the user is not authorized to connect.
認証が不可能になって、特定のユーザーのためのキーが配置されなかったことを示し、「PSKが見つかりません」。 「認証エラーは、」原因PSKの不一致にMAC障害を示します。 「許可障害」は、使用されているPSKが正しいながら、ユーザが接続を許可されていないことを示しています。
The protected data blocks are a generic mechanism for the peer and server to securely exchange data. If the specified ciphersuite has a NULL encryption primitive, then this channel only offers authenticity, not confidentiality.
保護されたデータブロックは、データを安全に交換するために、ピアとサーバのための一般的なメカニズムです。指定された暗号スイートがプリミティブNULL暗号化を持っている場合、このチャネルは唯一の本物ではなく、機密性を提供しています。
These payloads are encoded as the concatenation of type-length-value (TLV) triples called PD_Payloads.
これらのペイロードはPD_Payloads呼ばれるタイプレングス値（TLV）トリプルの連結として符号化されます。
Type values are encoded as a 6-octet string and represented by a 4-octet vendor and a 2-octet specifier field. The vendor field indicates the type as either standards-specified or vendor-specific.
タイプ値は、6オクテットストリングとして符号化し、4オクテットのベンダー及び2オクテットの指定フィールドによって表されています。ベンダーのフィールドのいずれかの規格が指定するか、ベンダー固有のようなタイプを示します。
If these four octets are 0x00000000, then the value is standards-specified, and any other value represents a vendor-specific enterprise number.
これらの4つのオクテットが0x00000000のであれば、その値は、標準指定され、それ以外の値は、ベンダー固有の企業数を表します。
The specifier field indicates the actual type. For vendor field 0x00000000, the specifier field is maintained by IANA. For any other vendor field, the specifier field is maintained by the vendor.
指定フィールドには、実際の型を示します。ベンダーフィールド0x00000000のために、指定フィールドはIANAによって維持されています。他のベンダーのフィールドでは、指定フィールドはベンダーによって維持されています。
Length fields are specified as 2-octet integers in network byte order, reflect only the length of the value, and do not include the length of the type and length fields.
長さフィールドは、ネットワークバイト順に2オクテットの整数として指定された値の長さのみを反映し、タイプと長さフィールドの長さを含まないれます。
Graphically, this can be depicted as follows:
次のようにグラフィカルに、これを描写することができます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PData/Value ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Protected Data Payload (PD_Payload) Formatting
図12：保護されたデータペイロード（PD_Payload）フォーマット
These PD_Payloads are concatenated together to form a PD_Payload_Block. If the CSuite_Sel includes support for encryption, then the PD_Payload_Block includes fields specifying an Initialization Vector (IV) and the necessary padding. This can be depicted as follows:
これらのPD_PayloadsはPD_Payload_Blockを形成するために一緒に連結されています。 CSuite_Selは、暗号化のサポートが含まれている場合、PD_Payload_Blockは初期化ベクトル（IV）と、必要なパディングを指定するフィールドが含まれています。これは次のように描写することができます。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV Length | |
+-+-+-+-+-+-+-+-+ Initialization Vector +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Protected Data Block (PD_Payload_Block)
Formatting if Encryption is Supported
The Initialization Vector is a randomly chosen value whose length is equal to the specified IV Length. The required length is defined by the ciphersuite. Recipients MUST accept any value. Senders SHOULD either pick this value pseudo-randomly and independently for each message or use the final ciphertext block of the previous message sent. Senders MUST NOT use the same value for each message, use a sequence of values with low hamming distance (e.g., a sequence number), or use ciphertext from a received message. IVs should be selected per the security requirements of the underlying cipher. If the data is not being encrypted, then the IV Length MUST be 0. If the ciphersuite does not require an IV, or has a self-contained way of communicating the IV, then the IV Length field MUST be 0. In these cases, the ciphersuite definition defines how the IV is encapsulated in the PD_Payload.
初期化ベクトルは、長さが指定されたIVの長さに等しい、ランダムに選択された値です。必要な長さは、暗号スイートによって定義されます。受信者は、任意の値を受け入れなければなりません。送信者は、メッセージごとに擬似ランダムおよび独立して、この値を選択または送信前のメッセージの最後の暗号文ブロックを使用すべきであるいずれか。送信者は、メッセージごとに同じ値を使用して低いハミング距離（例えば、シーケンス番号）と値のシーケンスを使用するか、または受信されたメッセージから暗号文を使用してはいけません。 IVは、基本となる暗号のセキュリティ要件ごとに選択する必要があります。データが暗号化されていない場合は、IVの長さは、暗号スイートはIVを必要とする、またはIVの通信の自己完結型の方法を持っていない場合、IVの長さフィールドは、これらの場合は0でなければなりません0でなければなりません暗号スイートの定義は、IVがPD_Payloadにカプセル化される方法を定義します。
The concatenation of PD_Payloads along with the padding and padding length are all encrypted using the negotiated block cipher. If no block cipher is specified, then these fields are not encrypted.
パディングパディング長さに沿ってPD_Payloadsの連結は、全てネゴシエートブロック暗号を用いて暗号化されています。何ブロック暗号が指定されていない場合、これらのフィールドは暗号化されません。
The Padding field MAY contain any value chosen by the sender. For block-based cipher modes, the padding MUST have a length that makes the combination of the concatenation of PD_Payloads, the Padding, and the Pad Length to be a multiple of the encryption block size. If the underlying ciphersuite does not require padding (e.g., a stream-based cipher mode) or no encryption is being used, then the padding length MUST still be present and be 0.
パディングフィールドは、送信者が選択した任意の値を含むかもしれません。ブロックベースの暗号モードのために、パディングはPD_Payloadsの連結、パディング、パッド長さの組み合わせが暗号ブロックサイズの倍数であることができる長さでなければなりません。基礎となる暗号スイートは、パディングを必要としない場合（例えば、ストリームベースの暗号化モード）または暗号化なしが使用され、その後、パディングの長さは依然として存在し、0でなければなりません。
The Pad Length field is the length of the Padding field. The sender SHOULD set the Pad Length to the minimum value that makes the combination of the PD_Payloads, the Padding, and the Pad Length a multiple of the block size (in the case of block-based cipher modes), but the recipient MUST accept any length that results in proper alignment. This field is encrypted with the negotiated cipher.
パッド長フィールドはパディングフィールドの長さです。送信者はPD_Payloads、パディングの組み合わせを行う最小値にパッド長、パッドの長さ（ブロックベースの暗号モードの場合）ブロックサイズの倍数に設定する必要がありますが、受信者がいずれかを受け入れなければなりません適切な位置合わせをもたらす長さ。このフィールドは、交渉された暗号で暗号化されています。
If the negotiated ciphersuite does not support encryption, then the IV field MUST be of length 0 and the padding field MUST be of length 0. The IV length and padding length fields MUST still be present, and contain the value 0. The rationale for still requiring the length fields is to allow for modular implementations where the crypto processing is independent of the payload processing. This is depicted in the following figure.
交渉さ暗号スイートは、暗号化をサポートしていない場合は、IVフィールドは長さが0でなければならず、パディングフィールドは、IVの長さとパディング長フィールドがまだ存在しなければならない長さは0であること、そしてまだのために値0に根拠を含まなければなりません長さフィールドを必要とする暗号処理は、ペイロード処理とは独立しているモジュラー実装を可能にすることです。これを次の図に描かれています。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | |
+-+-+-+-+-+-+-+-+ PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Protected Data Block (PD_Payload_Block)
Formatting Without Encryption
For PData/Vendor field 0x00000000, the following PData/Specifier fields are defined:
パラレルデータPData /ベンダーフィールド0x00000000のために、以下のパラレルデータPData /指定子フィールドが定義されています。
o 0x0000 : Reserved
0000○：予約
All other values of this field are available via IANA registration.
この分野の他のすべての値は、IANA登録を経由して利用できます。
This section defines how the EAP peer and EAP server MUST behave when a received packet is deemed invalid.
このセクションでは、受信したパケットが無効とされたときにEAPピアとEAPサーバが振る舞う必要があるかを定義します。
Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP server MUST be silently discarded. An EAP peer or EAP server receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently discard the packet.
EAPピアまたはEAPサーバによって解析することができない任意のEAP-GPSKパケットは、黙って破棄しなければなりません。予期しないパケットを受信したEAPピアまたはEAPサーバ（例えば、EAPピアGPSK-1を受信する前またはGPSK-2を送信する前にGPSK-3を受信する）は静かにパケットを捨てなければなりません。
GPSK-1 contains no MAC protection, so provided it properly parses, it MUST be accepted by the peer. If the EAP peer has no ciphersuites in common with the server or decides the ID_Server is that of an Authentication, Authorization, and Accounting (AAA) server to which it does not wish to authenticate, the EAP peer MUST respond with an EAP-NAK.
GPSK-1は何のMAC保護が含まれていないので、それはピアで受け入れなければならない、それが適切に解析しました。 EAPピアは、サーバと共通の何の暗号スイートを持っていないか、ID_Serverは、認証のものであることを決定した場合、認可、アカウンティング（AAA）サーバは、EAPピアはEAP-NAKで応答しなければならない、それが認証したくないものにします。
For GPSK-2, if the ID_Peer is for an unknown user, the EAP server MUST send either a "PSK Not Found" GPSK-Fail message or an "Authentication Failure" GPSK-Fail, depending on its policy. If the MAC validation fails, the server MUST transmit a GPSK-Fail message specifying "Authentication Failure". If the RAND_Server or CSuite_List field in GPSK-2 does not match the values in GPSK-1, the server MUST silently discard the packet. If server policy determines the peer is not authorized and the MAC is correct, the server MUST transmit a GPSK-Protected-Fail message indicating "Authorization Failure", and discard the received packet.
ID_Peerが不明なユーザーの場合GPSK-2については、EAPサーバは、「PSKが見つかりません」GPSKフェイルメッセージまたはそのポリシーに応じて、「認証エラー」GPSK-失敗、どちらかを送らなければなりません。 MACの検証が失敗した場合、サーバーは、「認証エラー」を指定GPSK-失敗メッセージを伝えなければなりません。 GPSK-2でRAND_ServerまたはCSuite_ListフィールドがGPSK-1の値と一致しない場合、サーバは静かにパケットを捨てなければなりません。サーバポリシーがピアが許可されていないと判断するMACが正しい場合、サーバは、「認可の失敗」を示すGPSK-プロテクト失敗メッセージを送信し、受信したパケットを破棄しなければなりません。
A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in response to a GPSK-2 message MUST replay the received GPSK-Fail / GPSK-Protected-Fail message. Then, the EAP server returns an EAP-Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message to correctly finish the EAP conversation. If MAC validation on a GPSK-Protected-Fail packet fails, then the received packet MUST be silently discarded.
GPSK-2メッセージに応答GPSKフェイル/ GPSK-プロテクト失敗メッセージを受信したピアは、受信しGPSKフェイル/ GPSK-プロテクト失敗メッセージを再生しなければなりません。その後、EAPサーバは正しくEAPの会話を終了するGPSKフェイル/ GPSK - 保護 - 失敗メッセージを受信した後にEAP-失敗を返します。 GPSK - 保護 - 失敗パケットのMACの検証が失敗した場合、受信したパケットは黙って捨てなければなりません。
For GPSK-3, a peer MUST silently discard messages where the RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those transmitted in GPSK-2. An EAP peer MUST silently discard any packet whose MAC fails.
GPSK-3のために、ピアは静かRAND_Peer、ID_Server、又はCSuite_SelフィールドはGPSK-2で送信されるものと一致しないメッセージを破棄しなければなりません。 EAPピアは静かにそのMAC失敗したすべてのパケットを捨てなければなりません。
For GPSK-4, a server MUST silently discard any packet whose MAC fails validation.
GPSK-4の場合、サーバは静かにそのMAC検証に失敗したすべてのパケットを捨てなければなりません。
If a decryption failure of a protected payload is detected, the recipient MUST silently discard the GPSK packet.
保護されたペイロードの復号失敗が検出された場合、受信者は静かGPSKパケットを捨てなければなりません。
This section shows a couple of example message flows.
このセクションでは、例示的メッセージフローのいくつかを示しています。
A successful EAP-GPSK message exchange is shown in Figure 1.
成功したEAP-GPSKメッセージ交換は、図1に示されています。
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/EAP-NAK | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 15: EAP-GPSK: Unsuccessful Exchange
(Unacceptable AAA Server Identity; ID_Server)
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 16: EAP-GPSK: Unsuccessful Exchange (Unknown User)
図16：EAP-GPSK：失敗した取引所（未知のユーザ）
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (Authentication Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (Authentication Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 17: EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)
図17：EAP-GPSK：失敗交換（GPSK-2の無効MAC）
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 18: EAP-GPSK: Unsuccessful Exchange (Authorization Failure)
図18：EAP-GPSK：失敗した取引所（認証の失敗）
[RFC3748] highlights several attacks that are possible against EAP since EAP itself does not provide any security.
EAP自体はどのようなセキュリティを提供していないので、[RFC3748]はEAPに対して可能ないくつかの攻撃を強調しています。
This section discusses the claimed security properties of EAP-GPSK as well as vulnerabilities and security recommendations in the threat model of [RFC3748].
このセクションでは、[RFC3748]の脅威モデルに記載のセキュリティEAP-GPSKの特性ならびに脆弱性とセキュリティの推奨事項について説明します。
Authentication mechanism: Shared Keys Ciphersuite negotiation: Yes (Section 12.16) Mutual authentication: Yes (Section 12.2) Integrity protection: Yes (Section 12.4) Replay protection: Yes (Section 12.5) Confidentiality: No (Section 12.17, Section 12.15) Key derivation: Yes (Section 12.8) Key strength: Varies (Section 12.8)
認証メカニズム：共有鍵たciphersuite交渉：はい（セクション12.16）相互認証：はい（セクション12.2）完全性保護：はい（12.4節）リプレイ保護：はい（セクション12.5）機密性：いいえ（セクション12.17、セクション12.15）鍵の導出：はい（セクション12.8）キー強度：不定（12.8項）
Dictionary attack protection: No (Section 12.7) Fast reconnect: No (Section 12.14) Cryptographic binding: N/A (Section 12.18) Session independence: Yes (Section 12.10) Fragmentation: No (Section 12.12) Channel binding: Extensible (Section 12.13)
辞書攻撃からの保護：いいえ（12.7節）高速再接続：いいえ（セクション12.14）暗号バインディング：N / A（項12.18）セッションの独立性：はい（セクション12.10）フラグメンテーション：いいえ（セクション12.12）チャネルバインディング：拡張（セクション12.13）
EAP-GPSK provides mutual authentication.
EAP-GPSKは、相互認証を提供します。
The server believes that the peer is authentic when it successfully verifies the MAC in the GPSK-2 message; the peer believes that the server is authentic when it successfully verifies the MAC it receives with the GPSK-3 message.
サーバは、それが正常GPSK-2メッセージ内のMACを検証する際にピアが本物であると考えています。ピアは、それが成功し、それがGPSK-3メッセージを受信したMACの検証を行う際に、サーバーが本物であると考えています。
The key used for mutual authentication is derived based on the long-term secret PSK, nonces contributed by both parties, and other parameters. The long-term secret PSK has to provide sufficient entropy and, therefore, sufficient strength. The nonces (RAND_Peer and RAND_Server) need to be fresh and unique for every session. In this way, EAP-GPSK is not different than other authentication protocols based on pre-shared keys.
相互認証のために使用されるキーは、長期的な秘密PSK、両当事者によって寄与ナンス、および他のパラメータに基づいて導出されます。長期秘密PSKは十分エントロピー及び、従って、十分な強度を提供しなければなりません。ナンス（RAND_PeerとRAND_Server）は、セッションごとに新鮮でユニークである必要があります。このように、EAP-GPSKは、事前共有キーに基づいて、他の認証プロトコルとは異なるではありません。
EAP-GPSK supports protected result indications via the GPSK-Protected-Fail message. This allows a server to provide additional information to the peer as to why the session failed, and to do so in an authenticated way (if possible). In particular, the server can indicate the lack of PSK (account not present), failed authentication (PSK incorrect), or authorization failure (account disabled or unauthorized). Only the third message could be integrity protected.
EAP-GPSKはGPSK - 保護 - 失敗メッセージを介して保護された結果の表示をサポートしています。これは、サーバが、セッションが失敗した理由をピアに追加情報を提供するため、および認証された方法（可能な場合）でそうすることができます。具体的には、サーバは、PSKの欠如を示すことができます（アカウントは存在しない）、（無効または不正なアカウント）認証（PSK正しくない）、または許可の失敗を失敗しました。唯一の3番目のメッセージは、完全性を保護することができます。
It should be noted that these options make debugging network and account errors easier, but they also leak information about accounts to attackers. An attacker can determine if a particular ID_Peer is a valid user on the network or not. Thus, implementers should use care in enabling this particular option on their servers. If they are in an environment where such attacks are of concern, then protected result indication capabilities should be disabled.
これらのオプションは、デバッグネットワークおよびアカウントのエラーをより容易にすることに留意すべきであるが、彼らはまた、攻撃者にアカウントに関する情報を漏らします。特定のID_Peerが有効なユーザー、ネットワーク上であるかどう攻撃者が決定することができます。したがって、実装者は自分のサーバー上でこの特定のオプションを有効にするには注意して使用する必要があります。彼らはこのような攻撃が懸念される環境にある場合、保護された結果の表示機能を無効にする必要があります。
EAP-GPSK provides integrity protection based on the ciphersuites suggested in this document. Integrity protection is a minimum feature every ciphersuite must provide.
EAP-GPSKは、この文書で提案する暗号スイートに基づいて、完全性保護を提供します。完全性保護は、すべての暗号スイートを提供しなければならない最低限の機能です。
EAP-GPSK provides replay protection of its mutual authentication part thanks to the use of random numbers RAND_Server and RAND_Peer. Since RAND_Server is 32 octets long, one expects to have to record 2**64 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentications before a protocol run can be replayed. Hence, EAP-GPSK provides replay protection of its mutual authentication part as long as RAND_Server and RAND_Peer are chosen at random; randomness is critical for replay protection. RFC 4086 [RFC4086] describes techniques for producing random quantities.
EAP-GPSKは、乱数RAND_ServerとRAND_Peerの使用への相互認証部分のおかげでの再生保護を提供します。 RAND_Serverは32オクテットの長さであるので、一方が記録しなければならないことを期待2 ** 64（すなわち、約1.84 * 10 ** 19）EAP-GPSKプロトコルの実行を再生することができる前に、成功した認証。したがって、EAP-GPSKは限りRAND_ServerとRAND_Peerがランダムに選択されるように、その相互認証部のリプレイ保護を提供します。ランダム性はリプレイ保護のために重要です。 RFC 4086 [RFC4086]は、ランダムな量を生産するための技術を説明します。
Reflection attacks occur in bi-directional, challenge-response, mutual authentication protocols where an attacker, upon being issued a challenge by an authenticator, responds by issuing the same challenge back to the authenticator, obtaining the response, and then "reflecting" that same response to the original challenge.
リフレクション攻撃は同じ「を反映した」そして、双方向、チャレンジレスポンスでは、攻撃者は、認証者によって挑戦を発行されると、応答を取得し、バックオーセンティケータに同じ挑戦を発行することによって応答し、相互認証プロトコルを発生し、元のチャレンジへの応答。
EAP-GPSK provides protection against reflection attacks because the message formats for the challenges differ. The protocol does not consist of two independent authentications, but rather the authentications are tightly coupled.
挑戦のためのメッセージフォーマットが異なるため、EAP-GPSKは、反射攻撃に対する保護を提供します。プロトコルは、2つの独立した認証から構成されない、むしろ認証が緊密に結合されています。
Also note that EAP-GPSK does not provide MAC protection of the OP-Code field, but again since each message is constructed differently, it would not be possible to change the OP-Code of a valid message and still have it be parseable and accepted by the recipient.
また、EAP-GPSKはOP-CodeフィールドのMAC保護を提供していませんが、それぞれのメッセージが異なって構成されているので、再び、有効なメッセージのOP-コードを変更し、まだそれが解析可能なこと持ってすることはできないと認められたことに注意してください受信者によります。
EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be based on at least 16 octets of entropy to be fully secure. The EAP-GPSK protocol makes no special provisions to ensure keys based on passwords are used securely. Users who use passwords as the basis of their PSK are not protected against dictionary attacks. Derivation of the long-term shared secret from a password is strongly discouraged.
EAP-GPSKは、完全に安全であるとエントロピーの少なくとも16個のオクテットに基づくべきである長期的共有秘密（PSK）に依存しています。 EAP-GPSKプロトコルは、パスワードに基づいてキーが安全に使用されることを保証するために特別な規定を行いません。そのPSKの基礎として、パスワードを使用するユーザーは、辞書攻撃から保護されていません。パスワードから長期共有秘密の導出を強くお勧めします。
The success of a dictionary attack against EAP-GPSK depends on the strength of the long-term shared secret (PSK) it uses. The PSK used by EAP-GPSK SHOULD be drawn from a pool of secrets that is at least 2^128 bits large and whose distribution is uniformly random. Note that this does not imply resistance to dictionary attacks -- only that the probability of success in such an attack is acceptably remote.
EAP-GPSKに対する辞書攻撃の成功は、それが使用する長期共有秘密（PSK）の強度に依存します。 EAP-GPSKで使用PSKが大きく、その分布一様にランダムである少なくとも2 ^ 128ビットである秘密のプールから引き出されるべきです。このような攻撃の成功確率が許容可能なリモートであることだけを - これは、辞書攻撃に対する耐性を意味するものではないことに注意してください。
EAP-GPSK supports key derivation as shown in Section 4.
第4に示すように、EAP-GPSKは、鍵の導出をサポートしています。
Keys used within EAP-GPSK are all based on the security of the originating PSK. PSKs SHOULD have at least 16 octets of entropy. Independent of the protocol exchange (i.e., without knowing RAND_Peer and RAND_Server), the keys have been derived with sufficient input entropy to make them as secure as the underlying KDF output key length.
EAP-GPSK内で使用されるキーは、すべての発信元PSKのセキュリティに基づいています。 PSKsは、エントロピーの少なくとも16個のオクテットを持つべきである（SHOULD）。プロトコル交換の独立した（すなわち、RAND_PeerとRAND_Serverを知らずに）、キーは、下にあるKDF出力キーの長さ、それらにとしてセキュアにするために十分な入力エントロピーと導かれています。
There are three forms of denial-of-service (DoS) attacks relevant for this document, namely (1) attacks that lead to a vast amount of state being allocated, (2) attacks that attempt to prevent communication between the peer and server, and (3) attacks against computational resources.
サービス拒否（DoS）の3つの形態は、この文書に関連するが攻撃され、すなわち、（1）攻撃に割り当てられている状態の膨大な量につながること、（2）、ピアとサーバ間の通信を防止するために、その試みを攻撃（3）計算リソースに対する攻撃。
In an EAP-GPSK conversation the server has to maintain state, namely the 32-octet RAND_Server, when transmitting the GPSK-1 message to the peer. An adversary could therefore flood a server with a large number of EAP-GPSK communication attempts. An EAP server may therefore ensure that an established state times out after a relatively short period of time when no further messages are received. This enables a sort of garbage collection.
EAP-GPSK会話でサーバは、ピアへGPSK-1メッセージを送信するとき、状態、つまり32オクテットRAND_Serverを維持しなければなりません。敵対者は、したがって、EAP-GPSK通信試行多数のサーバーをあふれさせる可能性があります。 EAPサーバは、従って、更なるメッセージが受信されない時間の比較的短い期間の後に外状態時間を確立することを保証することができます。これは、ガベージコレクションの並べ替えを可能にします。
The client has to keep state information after receiving the GPSK-1 message. To prevent a replay attack, all the client needs to do is ensure that the value of RAND_Peer is consistent between GPSK-2 and GPSK-3. Message GPSK-3 contains all the material required to re-compute the keying material. Thus, if a client chooses to implement this client-side DoS protection mechanism, it may manage RAND_Peer and CSuite_Sel on a per-server basis for servers it knows, instead of on a per-message basis.
クライアントはGPSK-1メッセージを受信した後の状態情報を維持しています。リプレイ攻撃を防ぐために、すべてのクライアントはRAND_Peerの値はGPSK-2及びGPSK-3との間に一貫性があることを保証されて行う必要があります。メッセージGPSK-3は鍵を再計算するために必要なすべての材料が含まれています。クライアントは、このクライアント側のDoS保護メカニズムを実装することを選択した場合このように、それは代わりに、メッセージごとに、それは知っているサーバ用サーバ単位でRAND_PeerとCSuite_Selを管理することができます。
Attacks that disrupt communication between the peer and server are mitigated by silently discarding messages with invalid MACs. Attacks against computational resources are mitigated by having very light-weight cryptographic operations required during each protocol round.
ピアとサーバ間の通信を妨害する攻撃は黙っ無効のMACとメッセージを破棄することによって軽減されています。計算リソースに対する攻撃は、各プロトコルのラウンド中に必要な非常に軽量暗号化操作を有することによって軽減されます。
The security considerations of EAP itself, see Sections 5.2 and 7 of RFC 3748 [RFC3748], are also applicable to this specification (e.g., for example concerning EAP-based notifications).
EAP自体のセキュリティ問題は、セクション5.2およびRFC 3748の7 [RFC3748]を参照して、（例えば、EAPベースの通知に関するなど）も、本明細書に適用可能です。
Thanks to its key derivation mechanisms, EAP-GPSK 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. The assumption that RAND_Peer and RAND_Server are random is central for the security of EAP-GPSK in general and session independence in particular.
その鍵導出メカニズムのおかげで、EAP-GPSKは、セッションの独立性を提供します（たとえば、EAPの会話のキャプチャなど）、受動的攻撃または（MSKかEMSKの妥協を含む）アクティブな攻撃は、その後またはその前たMSKまたはEMSKsの妥協を有効にしないでください。 RAND_PeerとRAND_Serverがランダムであるという仮定は、一般、特にセッション独立でEAP-GPSKのセキュリティのための中心です。
EAP-GPSK does not provide perfect forward secrecy. Compromise of the PSK leads to compromise of recorded past sessions.
EAP-GPSKは完全転送秘密を提供していません。 PSKの妥協点は、記録された過去のセッションの妥協につながります。
Compromise of the PSK enables the attacker to impersonate the peer and the server, and it allows the adversary to compromise future sessions.
PSKの妥協は、ピアとサーバを偽装する攻撃を可能にし、そしてそれは敵が今後のセッションを危うくすることができます。
EAP-GPSK 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, the choice of which is outside the scope of this document. The PSK used by EAP-GPSK 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 (e.g., those with different ID_Peer values) communicating with the same server.
EAP-GPSKは、第三者とのPSKを共有する正当なピアに対する保護機能はありません。そのような保護は、PSK、この文書の範囲外となっている選択のための適切なリポジトリによって提供されてもよいです。ピアとサーバ：EAP-GPSKで使用PSKは、二者間で共有されなければなりません。特に、このPSKはピアのグループで共有されてはならない（例えば、異なるID_Peer値を持つもの）は、同じサーバーと通信します。
The PSK used by EAP-GPSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-GPSK may be compromised.
EAP-GPSKで使用PSKが暗号さもなければEAP-GPSKのセキュリティが損なわれる可能性があり、他のプロトコルによって使用されるキーから分離しなければなりません。
EAP-GPSK does not support fragmentation and reassembly since the message size is relatively small. However, it should be noted that this impacts the length of protected data payloads that can be attached to messages. Also, if the EAP frame is larger than the MTU of the underlying transport, and that transport does not support fragmentation, the frame will most likely not be transported. Consequently, implementers and deployers should take care to ensure EAP-GPSK frames are short enough to work properly on the target underlying transport mechanism.
メッセージのサイズが比較的小さいので、EAP-GPSKはフラグメンテーションおよび再組み立てをサポートしていません。しかし、それはメッセージに添付することができ、保護されたデータペイロードのこの影響は長さことに留意すべきです。 EAPフレームは、基礎となるトランスポートのMTUよりも大きく、そのトランスポートは、断片化をサポートしていない場合にも、フレームは、最も可能性の高い輸送されることはありません。その結果、実装者とデプロイヤは、EAP-GPSKフレームがターゲット基礎となるトランスポートメカニズム上で正しく動作するために十分に短いであることを確認するために世話をする必要があります。
This document enables the ability to exchange channel binding information. It does not, however, define the encoding of channel binding information in the document.
この文書では、チャネルバインディング情報を交換する能力を可能にします。しかしながら、文書内のチャネルバインディング情報の符号化を定義していません。
EAP-GPSK does not provide fast reconnect capability since this method is already at (or close to) the lower limit of the number of roundtrips and the cryptographic operations.
この方法は、ラウンドトリップの数及び暗号操作の下限に（またはそれに近い）が既にあるので、EAP-GPSKは、高速再接続機能を提供しません。
Identity protection is not specified in this document. Extensions can be defined that enhance this protocol to provide this feature.
アイデンティティ保護は、この文書で指定されていません。拡張機能は、この機能を提供するために、このプロトコルを強化するように定義することができます。
EAP-GPSK provides protected ciphersuite negotiation via the indication of available ciphersuites by the server in the first message, and a confirmation by the peer in the subsequent message.
EAP-GPSKは、最初のメッセージにサーバによって使用可能な暗号スイートの指示、およびその後のメッセージ内のピアによる確認によって保護暗号スイートネゴシエーションを提供します。
Note, however, that the GPSK-2 message may optionally contain a payload, ENC_PK(PD_Payload_Block), protected with an algorithm based on a selected ciphersuite before the ciphersuite list has actually been authenticated. In the classical downgrading attack, an adversary would choose a ciphersuite that is so weak that it can be broken in real time or would attempt to disable cryptographic protection altogether. The latter is not possible since any ciphersuite defined for EAP-GPSK must at least provide authentication and integrity protection. Confidentiality protection is optional. When, at some time in the future, a ciphersuite contains algorithms that can be broken in real-time, then a policy on peers and the server needs to indicate that such a ciphersuite must not be selected by any of parties.
ただし、GPSK-2メッセージは、必要に応じて暗号スイートリストが実際に認証されている前に選択暗号スイートに基づくアルゴリズムで保護されたペイロード、ENC_PK（PD_Payload_Block）を含んでいてもよいです。古典ダウングレード攻撃では、攻撃者は、それがリアルタイムに分けることができますまたは完全に暗号保護を無効にしようとほど弱い暗号スイートを選ぶだろう。後者は、EAP-GPSKのために定義された任意の暗号は、少なくとも認証と完全性保護を提供しなければならないので、可能ではありません。機密性の保護はオプションです。将来のある時点で、暗号スイートは、リアルタイムに分けることができるアルゴリズムが含まれている場合は、その後、ピア上のポリシーおよびサーバは、そのような暗号スイートは、当事者のいずれかによって選択されてはならないことを示す必要があります。
Furthermore, an adversary may modify the selection of the ciphersuite for the client to select a ciphersuite that does not provide confidentiality protection. As a result, this would cause the content of PD_Payload_Block to be transmitted in cleartext. When protocol designers extend EAP-GPSK to carry information in the PD_Payload_Block of the GPSK-2 message, then it must be indicated whether confidentiality protection is mandatory. In case such an extension requires a ciphersuite with confidentiality protection, then the policy at the peer must be to not transmit information of that extension in the PD_Payload_Block of the GPSK-2 message. The peer may, if possible, delay the transmission of this information element to the GPSK-4 message where the ciphersuite negotiation has been confirmed already. In general, when a ciphersuite is selected that does not provide confidentiality protection, then information that demands confidentiality protection must not be included in any of the PD_Payload_Block objects.
さらに、敵は機密性保護を提供しない暗号スイートを選択するために、クライアントの暗号スイートの選択を変更することができます。その結果、これはPD_Payload_Blockの内容が平文で送信される原因となります。プロトコル設計者はGPSK-2メッセージのPD_Payload_Blockに情報を運ぶためにEAP-GPSKを拡張する場合、機密保護が必須であるかどうかを示さなければなりません。ケースでは、そのような拡張は、機密保護された暗号スイートを必要とし、ピアにポリシーがGPSK-2メッセージのPD_Payload_Blockにその拡張の情報を送信しないようにしなければなりません。可能な場合、ピアは、暗号スイートネゴシエーションが既に確認されているGPSK-4のメッセージにこの情報要素の送信を遅延させることができます。一般的には、暗号スイートが選択されているときに、PD_Payload_Blockオブジェクトのいずれにも含まれてはならない機密保護を要求する情報を機密保護を提供しません。
Although EAP-GPSK provides confidentiality in its protected data payloads, it cannot claim to do so, per Section 7.2.1 of [RFC3748], since it does not support identity protection.
EAP-GPSKは、その保護されたデータペイロードに機密性を提供しますが、それはアイデンティティ保護をサポートしていないので、それは、[RFC3748]のセクション7.2.1あたりに、そうすることを主張することはできません。
Since EAP-GPSK does not tunnel another EAP method, it does not implement cryptographic binding.
EAP-GPSKトンネル別のEAPメソッドをしないので、暗号バインディングを実装していません。
IANA has allocated a new EAP Type for EAP-GPSK (51).
IANAはEAP-GPSK（51）のための新しいEAPタイプを割り当てました。
IANA has created a new registry for ciphersuites, protected data types, failure codes, and op-codes. IANA has added the specified ciphersuites, protected data types, failure codes, and op-codes to these registries as defined below. Values defining ciphersuites (block-based or hash-based), protected data payloads, failure codes, and op-codes can be added or modified per IETF Review [RFC5226].
IANAは、暗号スイート、保護されたデータの種類、障害コード、およびオペコードのための新しいレジストリを作成しました。以下に定義されるようにIANAは、これらのレジストリに指定された暗号スイート、保護されたデータタイプ、故障コード、およびオペコードを追加しました。暗号スイート（ブロックベースまたはハッシュベース）、保護されたデータペイロード、故障コード、およびオペコードを定義する値を追加またはIETFレビュー[RFC5226]あたりに変更することができます。
Figure 3 represents the initial contents of the "EAP-GPSK Ciphersuites" registry. The CSuite/Specifier field is 16 bits long. All other values are available via IANA registration. Each ciphersuite needs to provide processing rules and needs to specify how the following algorithms are instantiated: encryption, integrity, key derivation, and key length.
図3は、「EAP-GPSK暗号の組み合わせ」レジストリの初期内容を表しています。 CSuite /指定子フィールドは16ビット長です。他のすべての値は、IANA登録を経由して利用できます。各暗号スイートには、処理ルールを提供する必要があり、以下のアルゴリズムがインスタンス化される方法を指定する必要があります：暗号化、完全性、鍵導出、およびキーの長さを。
The following are the initial contents of the "EAP-GPSK Protected Data Payloads" registry:
以下は、「EAP-GPSK保護されたデータペイロード」レジストリの初期の内容です：
o 0x0000 : Reserved
0000○：予約
The PData/Specifier field is 16 bits long, and all other values are available via IANA registration. Each extension needs to indicate whether confidentiality protection for transmission between the EAP peer and the EAP server is mandatory.
パラレルデータPData /指定子フィールドは16ビット長であり、そして他のすべての値は、IANA登録を介して利用可能です。各拡張は、EAPピアとEAPサーバ間の伝送のための機密保護が必須であるかどうかを示す必要があります。
The following are the initial contents of the "EAP-GPSK Failure Codes" registry:
以下は、「EAP-GPSK失敗コード」レジストリの初期の内容です：
o 0x00000000 : Reserved
0x00000000のO：予約
o 0x00000001 : PSK Not Found
0x00000001のO：PSKが見つかりません
o 0x00000002 : Authentication Failure o 0x00000003 : Authorization Failure
O 0x00000002：0x00000003 O認証失敗：認証の失敗
The Failure-Code field is 32 bits long, and all other values are available via IANA registration.
障害コードフィールドは32ビット長であり、そして他のすべての値は、IANA登録を介して利用可能です。
The following are the initial contents of the "EAP-GPSK OP Codes" registry:
以下は、「EAP-GPSK OPコード」レジストリの初期の内容です：
o 0x00 : Reserved
0x00のO：予約
o 0x01 : GPSK-1
Oが0x01：GPSK-1
o 0x02 : GPSK-2
O 0×02：GPSK-2
o 0x03 : GPSK-3
O 0×03：GPSK-3
o 0x04 : GPSK-4
O 0x04を：GPSK-4
o 0x05 : GPSK-Fail
0x05のO：GPSKフェイル
o 0x06 : GPSK-Protected-Fail
0x06のO：GPSK - 保護 - 失敗
The OP-Code field is 8 bits long, and all other values are available via IANA registration.
OPコードフィールドは、8ビット長であり、そして他のすべての値は、IANA登録を介して利用可能です。
This work is a joint effort of the EAP Method Update (EMU) design team of the EMU Working Group that was created to develop a mechanism based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 4017 [RFC4017] requirements. The design team members (in alphabetical order) were:
この作品は、RFC 3748 [RFC3748]およびRFC 4017 [RFC4017]の要件を満たす強力な共有秘密に基づくメカニズムを開発するために作成されたEMU作業部会のEAPメソッドを更新（EMU）設計チームの共同の努力です。 （アルファベット順）デザインチームのメンバーは以下の通りでした。
o Jari Arkko
OヤリArkko
o Mohamad Badra
モハマドBadraについて
o Uri Blumenthal
ウリブルーメンソールO
o Charles Clancy
チャールズ・クランシーO
o Lakshminath Dondeti
マイクロLakshminath Dondeti
o David McGrew
Oデビッドマグリュー
o Joe Salowey
OジョーSalowey
o Sharma Suman o Hannes Tschofenig
お しゃｒま すまん お はんえｓ Ｔｓちょふぇにｇ
o Jesse Walker
Oジェシー・ウォーカー
Finally, we would like to thank Thomas Otto for his reviews, feedback, and text contributions.
最後に、我々は彼のレビュー、フィードバック、およびテキストの貢献のためのトーマス・オットーに感謝したいと思います。
We would like to thank:
私たちは感謝したいと思います：
o Jouni Malinen and Bernard Aboba for their early comments on the document in June 2006. Jouni Malinen developed the first prototype implementation.
文書上の彼らの初期のコメントのためのJouni MalinenとバーナードAboba O 2006年6月にJouni Malinenは、最初のプロトタイプ実装を開発しました。
o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela Vanderveen, and Ray Bell for their input to the ciphersuite discussions between July and August 2006.
7月と2006年8月の間に暗号スイートの議論への入力のためのO Lakshminath Dondeti、デビッドマグリュー、バーナードAboba、ミカエラVANDERVEEN、およびレイ・ベル。
o Lakshminath Dondeti for his detailed review (sent to the EMU mailing list on 12 July 2006).
（2006年7月12日にEMUメーリングリストに送られた）彼の詳細なレビューのためのLakshminath Dondeti O。
o Based on a review requested from NIST, Quynh Dang suggested changes to the GKDF function (December 2006).
O NISTから要求されたレビューに基づいて、クインダンはGKDF機能（2006年12月）への変更を提案しました。
o Jouni Malinen and Victor Fajardo for their review in January 2007.
2007年1月の彼らのレビューのためのO Jouni Malinenとビクターファハルド。
o Jouni Malinen for his suggestions regarding the examples and the key derivation function in February 2007.
Oの例と2007年2月における鍵導出関数に関する彼の提案をJouni Malinen。
o Bernard Aboba and Jouni Malinen for their review in February 2007.
2007年2月でのレビューのためのOバーナードAbobaとJouni Malinen。
o Vidya Narayanan for her review in March 2007.
2007年3月に彼女のレビューのためのO Vidyaナラヤナン。
o Pasi Eronen for his IESG review in March and July 2008.
3月と2008年7月の彼のIESGレビューのためパシEronen O。
o Dan Harkins for his review in June 2008.
2008年6月に彼のレビューのためのダンハーキンズO。
o Joe Salowey, the EMU working group chair, provided a document review in April 2007. Jouni Malinen also reviewed the document during the same month.
OジョーSalowey、EMUワーキンググループの議長は、Jouni Malinenも同月中に文書を見直し2007年4月に書類審査を提供します。
o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov, and Prof. John C. Mitchell for their analysis of EAP-GPSK, for their input to the key derivation function, and for pointing us to a client-side DoS attack and to a downgrading attack. Based on their input, the key derivation function has been modified and the text in the security considerations section has been updated.
O私たちは鍵導出関数への入力のために、クライアント側に私たちを指しているため、EAP-GPSKの彼らの分析のためにポール・ロウ、Arnabロイ教授アンドレScedrov、教授ジョンC.ミッチェルに感謝したいと思いますDoS攻撃とダウングレード攻撃へ。その入力に基づいて、鍵導出関数は変更されていると、セキュリティ上の考慮事項のセクション内のテキストが更新されました。
o Finally, we would like to thank our working group chair, Joe Salowey, for his support and for the time he spent discussing open issues with us.
O最後に、我々は彼のサポートのために、彼は私たちとの未解決の問題を議論に費やした時間のために、私たちのワーキンググループ議長、ジョーSaloweyに感謝したいと思います。
[AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) 197, November 2001.
[AES]米国国立標準技術研究所、連邦情報処理規格（FIPS）197、2001年11月 "のAdvanced Encryption Standard（AES）のための仕様"。
[CBC] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Encryption -- Methods and Techniques", Special Publication (SP) 800-38A, December 2001.
[CBC]米国国立標準技術研究所、「暗号化のブロック暗号モードのための推薦 - の方法と技術」、特別刊行物（SP）800-38A、2001年12月。
[CMAC] 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.
[CMAC]米国国立標準技術研究所、「オペレーションのブロック暗号モードのための推薦：認証のためのCMACモード」、特別刊行物（SP）800-38B、2005年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]イーストレイク、D.とT.ハンセンは、RFC 4634、2006年7月、 "米国は、ハッシュアルゴリズム（SHAとHMAC-SHA）を固定します"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、サイモン、D.、およびP. Eronen、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、RFC 5247、2008年8月。
[80211] "Information technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-2007, March 2007.
[80211]「情報技術 - 電気通信及びシステム間情報交換 - 地方とメトロポリタンエリアネットワーク - 固有の要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様」、IEEE標準802.11-2007、月2007。
[ENTNUM] IANA, "SMI Network Management Private Enterprise Codes", Private Enterprise Numbers, <http://www.iana.org>.
[ENTNUM] IANA、 "SMIネットワークマネージメント私企業コード"、民間企業番号、<http://www.iana.org>。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA
テレコミュニケーション科学T.チャールズ・クランシー国防総省研究所8080 Greenmeadドライブカレッジパーク、MD 20740 USA
EMail: clancy@ltsnet.net
メールアドレス：clancy@ltsnet.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
EMail: Hannes.Tschofenig@gmx.net
メールアドレス：Hannes.Tschofenig@gmx.net