[要約] RFC 5433は、EAP-GPSKメソッドに関する仕様であり、一般化された事前共有キーを使用した認証プロトコルです。このRFCの目的は、EAPフレームワーク内での拡張可能な認証メカニズムの提供です。
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
拡張可能な認証プロトコル - 一般化された事前共有キー（EAP-GPSK）メソッド
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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 Generalized Pre-Shared Key（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メソッドです。相互認証は、事前に共有キーによって保護されているNonCEベースの交換によって達成されます。
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の現在のバージョンには2つのCiphersuitesが含まれていますが、追加のCifersuitesを簡単に追加できます。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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：利用可能なciphersuites（可変長）をリストするオクテットアレイリスト。
CSuite_Sel: Ciphersuite selected by the peer (6 octets).
csuite_sel：ピア（6オクテット）によって選択されたciphersuite。
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：選択したciphersuite csuite_selの入力キーサイズ、オクテットの整数を表す整数。キーサイズは、ciphersuiteパラメーターの1つです。
ML: Integer representing the length of the Message Authentication Code (MAC) output, in octets, of the selected ciphersuite CSuite_Sel.
ML：選択したciphersuite csuite_selのメッセージ認証コード（MAC）出力の長さを表す整数（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.
A ||B：オクテット弦AとBの連結
A**B: Integer exponentiation.
A ** B：整数の指数。
truncate(A,B): Returns the first B octets of A.
Truncate（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）：Secret XとSeed 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-OCTET整数としてエンコードされます。
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は、選択したCiphersuiteに基づいて整合性保護を提供する関数です。関数SECは、選択したCiphersuiteによって定義されたアルゴリズムを使用し、キー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のオクテットAからBを表す表記法。
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. 第1フェーズである発見は、IEEE 802.11 [80211]によって利用されているIEEE 802.1xなどの基礎となるプロトコルによって処理されます。
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は、恥ずかしさキーの所持の証明と見なされます。さらに2つのメッセージ、すなわちGPSK-Failと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を選択し、サポートされているCipherSuitesをCSUITE_LISTにエンコードすることにより、EAP-GPSKを開始します。Ciphersuiteは、暗号化アルゴリズム、キー派生関数、およびメッセージ認証コードで構成されています。
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、およびサポートされているCipherSuites CSUITE_LISTのリストを送信します。どのciphersuiteを提供するか、どのciphersuiteを選択するかという決定は、ポリシーおよび実装依存性であり、したがって、このドキュメントの範囲外です。
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）と選択したCipherSuiteの受信したパラメーターを繰り返します。送信されたすべてのパラメーターでメッセージ認証コードを計算します。
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で送信されるID、Nonces、およびCiphersuiteパラメーターの一貫性を検証します。検証が成功した場合、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で送信されるID、Nonces、およびCiphersuiteパラメーターの一貫性を検証します。検証が成功した場合、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成功メッセージを送信して、認証の成功を示すことを示します。
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（暗号化されたCiphersuiteを使用する場合）は、Ciphersuite指定KDFとプロトコルの実行中に交換されるデータを使用して導出されます。'rand_peer ||id_peer ||rand_server ||ID_Server '、その短い手形の入力ストリングと呼ばれます。
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は入力ストリングです、
[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]は、Octet Aで始まり、KDF関数の出力からOctet Bで仕上げるオクテットの文字列を抽出します。
This keying material is derived using the ciphersuite-specified KDF as follows:
このキーイング材料は、次のようにCiphersuite指定の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]
o msk = kdf- {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]（暗号化されたciphersuiteを使用する場合）
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-OCTET整数としてエンコードされます。KSは、オクテットのCiphersuite入力キーサイズの長さであることを思い出してください。
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:
さらに、EAPキーイングフレームワーク[RFC5247]には、Method-ID、Session-ID、Peer-ID、およびServer-IDの定義が必要です。これらの値は、次のように定義されます。
o Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type || CSuite_Sel || inputString)[0..15]
o method-id = kdf-16（psk [0..ks-1]、 "method id" || eap_method_type || csuite_sel || inputstring）[0..15]
o Session-ID = EAP_Method_Type || Method_ID
o session-id = eap_method_type ||method_id
o Peer-ID = ID_Peer
o peer-id = id_peer
o Server-ID = ID_Server
o server-id = id_server
EAP_Method_Type refers to the 1-octet, IANA-allocated EAP Type code value.
EAP_METHOD_TYPEは、1-OCTETのIANA-Allocated 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.
相互運用可能にするには、PSKをピアとサーバーの両方で同じ方法で入力する必要があります。PSKを入力するための管理インターフェイスは、ASCII文字列および16進コードとして、最大64オクテットの長さのPSKの入力をサポートする必要があります。
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の設計により、暗号化アルゴリズムとCiphersuitesと呼ばれるキーサイズをプロトコルの実行中に交渉できます。ブロックベースとハッシュベースのシファースーツを指定する機能が提供されます。拡張性は、新しいCifersuitesの導入により提供されます。このドキュメントは、初期セットを指定します。図3のcsuite/ specifier列は、ciphersuiteを一意に識別します。
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.
ベンダー固有のciphersuiteの場合、最初の4つのオクテットは、ネットワークバイトの順序でエンコードされた「SMIネットワーク管理プライベートエンタープライズコード」値（[entnum]を参照）を含むIANAによって割り当てられた「SMIネットワーク管理プライベートエンタープライズコード」を含むベンダー固有のエンタープライズ番号です。最後の2つのオクテットは、特定のCiphersuiteに割り当てられたベンダーです。0x00000000のベンダーコードは、IETFによって標準化されたIANAが維持したレジストリで標準化されたCiphersuitesを示しています。
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):
このドキュメントでは、次のCiphersuitesが指定されています（KSはオクテットのCiphersuite入力キーの長さであり、MLはOctetsの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：Ciphersuites
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:
暗号化の原始として高度な暗号化標準（AES）に基づいたCiphersuite 1を実装する必要があります。このドキュメントは、実装される可能性のある2番目のCiphersuiteも指定しています。このドキュメントで定義されている両方のCiphersuitesは、セクション7で定義されている一般化キー誘導関数（GKDF）を使用しています。GKDFへの入力として使用されるPSKが十分に長いことを確認するために、次の側面を考慮する必要があります。
1. The PSK used with ciphersuite 1 MUST be 128 bits in length. Keys longer than 128 bits will be truncated.
1. Ciphersuite 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. Ciphersuite 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を使用する将来定義されたCipherSuitesは、最小のPSKサイズを指定する必要があります（このドキュメントにリストされているCiphersuitesで行われるように）。
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.
各ciphersuiteは、キー派生関数を指定する必要があります。このドキュメントで定義されているCiphersuitesは、Ciphersuiteで定義されたMAC関数を利用する一般化キー誘導関数（GKDF）を使用します。将来のCiphersuitesは、キーとシード値を引数として取得し、少なくとも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 = "";
result = "";
for i = 1 to n {
result = result || MAC_Y (i || Z);
}
return truncate(result, X) }
Truncate（result、x）を返します}
Note that the variable 'i' in M_i is represented as a 2-octet value in network byte order.
M_Iの変数「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).
このCiphersuiteを使用すると、すべての暗号化は、単一の暗号化プリミティブ、AES-128（[AES]）を中心に構築されています。保護されたデータフレーム内では、AES-128がCipherブロックチェーン（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は、暗号化される前に最初のPlantextブロックでXoredです。次に、連続したブロックの場合、以前の暗号文ブロックは、暗号化される前に現在のプレーンテキストでXoredになります。
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].
Ciphersuite 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
o メッセージGPSK-2のSEC_SK（パラメーター）内のパラメーター
o Parameter within SEC_SK(Parameter) in message GPSK-3
o メッセージGPSK-3のSEC_SK（パラメーター）内のパラメーター
o Parameter within SEC_SK(Parameter) in message GPSK-4
o メッセージGPSK-4のSEC_SK（パラメーター）内のパラメーター
Ciphersuite 2 does not include an algorithm for encryption. With a NULL encryption algorithm, encryption is defined as:
Ciphersuite 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を使用する場合、保護されたデータブロック内で交換されるデータは暗号化されていません。したがって、保護されたデータブロック内に機密情報が表示される場合、このモードは使用しないでください。
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash algorithm (see [RFC4634]).
Ciphersuite 2は、SHA256ハッシュアルゴリズムを使用して、キー付きMAC関数HMACを使用します（[RFC4634]を参照）。
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
o メッセージGPSK-2のSEC_SK（パラメーター）内のパラメーター
o Parameter within SEC_SK(Parameter) in message GPSK-3
o メッセージGPSK-3のSEC_SK（パラメーター）内のパラメーター
o Parameter within SEC_SK(Parameter) in message GPSK-4
o メッセージGPSK-4の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コードフィールドは、6つの値の1つです。
o 0x00 : Reserved
o 0x00：予約
o 0x01 : GPSK-1
o 0x01：gpsk-1
o 0x02 : GPSK-2
o 0x02：GPSK-2
o 0x03 : GPSK-3
o 0x03：GPSK-3
o 0x04 : GPSK-4
o 0x04：GPSK-4
o 0x05 : GPSK-Fail
o 0x05：gpsk-fail
o 0x06 : GPSK-Protected-Fail
o 0x06：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.
Ciphersuitesは6オクテットの配列としてエンコードされています。最初の4つのオクテットは、CSUITE/ベンダーフィールドを示しています。ベンダー固有のCiphersuitesの場合、これはベンダーエンタープライズ番号を表し、ネットワークバイトの順序でエンコードされたIANAが割り当てられた「SMIネットワーク管理プライベートエンタープライズコード」値（[entnum]を参照）値（[entnum]を参照）を含みます。最後の2つのオクテットは、特定のciphersuiteを識別するcsuite/specifierフィールドを示します。4-OCTET CSUITE/VENDOR値0x00000000は、IETFによって割り当てられたCiferSuitesを示しています。
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-OCTET Ciphersuite CSUite/VendorおよびCSUite/Specifierペアとしてエンコードされています。
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は、Ciphersuitesの可変長さのオクテットアレイです。エンコードされたciphersuite値を連結することによってエンコードされます。オクテットのその長さは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ペイロードは除外されます。Payload 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ペイロードは除外されます。pd_payload_blockの存在に関係なく、Macは常に含める必要があります。Payload Macは、PD_Payload_Blockの長さからオプションのPD_Payload_Blockまでのパケット全体をカバーしています。
The GPSK-Fail payload format is defined as follows:
gpsk-failペイロード形式は、次のように定義されています。
--- 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-failペイロード
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:
故障コードフィールドは3つの値の1つですが、拡張できます。
o 0x00000000 : Reserved
o 0x00000000：予約
o 0x00000001 : PSK Not Found
o 0x00000001：PSKが見つかりません
o 0x00000002 : Authentication Failure
o 0x00000002：認証障害
o 0x00000003 : Authorization Failure
o 0x00000003：承認の失敗
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 Not Found」は、特定のユーザーが見つけることができなかったためのキーを示しており、認証を不可能にします。「認証障害」は、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.
保護されたデータブロックは、ピアとサーバーがデータを安全に交換するための一般的なメカニズムです。指定されたCiphersuiteにヌル暗号化プリミティブがある場合、このチャネルは信頼性のみであり、機密性を提供します。
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-OCTET仕様フィールドで表されます。ベンダーフィールドは、標準指定またはベンダー固有のタイプを示します。
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-OCTET整数として指定され、値の長さのみを反映し、タイプと長さのフィールドの長さは含まれません。
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
図13：暗号化がサポートされている場合の保護されたデータブロック（pd_payload_block）フォーマット
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長に等しいランダムに選択された値です。必要な長さは、ciphersuiteによって定義されます。受信者はあらゆる価値を受け入れる必要があります。送信者は、各メッセージに対してこの値の擬似ランダムリーを選択して独立して選択するか、以前のメッセージの最終的な暗号文ブロックを使用する必要があります。送信者は、メッセージごとに同じ値を使用したり、ハミング距離が低い値（シーケンス番号など）のシーケンスを使用したり、受信したメッセージから暗号文を使用したりしてはなりません。IVは、基礎となる暗号のセキュリティ要件ごとに選択する必要があります。データが暗号化されていない場合、IVの長さは0でなければなりません。CiphersuiteがIVを必要としない場合、またはIVを通信する自己完結型の方法がある場合、IVの長さフィールドは0でなければなりません。Ciphersuiteの定義は、PD_PayloadでIVがカプセル化される方法を定義します。
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の連結、パディング、およびパッドの長さの組み合わせを暗号化ブロックサイズの倍数にする長さが必要です。基礎となるciphersuiteがパディング（たとえば、ストリームベースの暗号モード）を必要としない場合、または暗号化が使用されていない場合、パディングの長さはまだ存在し、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、Padding、およびPadの長さを組み合わせてブロックサイズの倍数（ブロックベースのCipherモードの場合）の組み合わせにする最小値にパッドの長さを設定する必要がありますが、受信者は任意のものを受け入れる必要があります。適切なアライメントをもたらす長さ。このフィールドは、交渉された暗号で暗号化されています。
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.
ネゴシエートされたciphersuiteが暗号化をサポートしていない場合、IVフィールドは長さ0でなければならず、パディングフィールドは長さ0でなければなりません。IVの長さとパディングの長さフィールドはまだ存在し、値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
図14：保護されたデータブロック（pd_payload_block）暗号化なしでのフォーマット
For PData/Vendor field 0x00000000, the following PData/Specifier fields are defined:
PDATA/ベンダーフィールド0x00000000の場合、次のPDATA/仕様フィールドが定義されています。
o 0x0000 : Reserved
o 0x0000：予約
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サーバー（たとえば、GPSK-1を受信する前またはGPSK-2を送信する前にGPSK-3を受信するEAPピア）は、パケットを静かに捨てる必要があります。
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ピアにサーバーと共通のciphersuitesがない場合、またはID_Serverが認証、承認、および会計（AAA）サーバーのID_Serverが認証を希望しない場合、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.
GPSK-2の場合、ID_PEERが不明なユーザー用である場合、EAPサーバーは、ポリシーに応じて、「PSKが見つかりません」GPSKフェイルメッセージまたは「認証障害」GPSK-Failを送信する必要があります。MAC検証が失敗した場合、サーバーは「認証障害」を指定するGPSK-failメッセージを送信する必要があります。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-fail / gpskで保護されたフェイルメッセージを受け取るピアは、受信したGPSK-fail / gpsk-strectected-failメッセージを再生する必要があります。次に、EAPサーバーは、GPSK-Fail / GPSKで保護されたフェイルメッセージを受信した後、EAPフェイルを返し、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.
[RFC3748]は、EAP自体がセキュリティを提供しないため、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) 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)
認証メカニズム：共有キーCiphersuite交渉：はい（セクション12.16）相互認証：はい（セクション12.2）整合性保護：はい（セクション12.4）リプレイ保護：はい（セクション12.5）機密性：いいえ（セクション12.17、セクション12.15）キー派生：はい（セクション12.8）キー強度：変化（セクション12.8）辞書攻撃保護：いいえ（セクション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は、十分なエントロピー、したがって十分な強度を提供する必要があります。nonces（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は、このドキュメントで提案されているCiphersuitesに基づいて整合性保護を提供します。整合性保護は、すべてのCiphersuiteが提供する必要がある最小機能です。
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は、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コードフィールドの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.
EAP-GPSKは、セクション4に示すようにキー派生をサポートしています。
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のセキュリティに基づいています。PSKには、少なくとも16オクテットのエントロピーが必要です。プロトコル交換（つまり、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）膨大な量の状態が割り当てられることにつながる攻撃があります。（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-OCTET 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保護メカニズムを実装することを選択した場合、serverとcsuite_selは、serverとcsuite_selを1人あたりのベースで管理し、1人あたりではなく、知っているサーバーで管理することができます。
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自体のセキュリティに関する考慮事項は、RFC 3748 [RFC3748]のセクション5.2および7を参照して、この仕様にも適用できます（たとえば、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またはEMSKの妥協を可能にしません。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は、ピアとサーバーの2つの関係者間でのみ共有する必要があります。特に、この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.
このドキュメントでは、ID保護は指定されていません。この機能を提供するためにこのプロトコルを強化する拡張機能を定義できます。
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は、最初のメッセージでサーバーによる利用可能なCiphersuitesの表示を介して、保護されたCiphersuite交渉と、後続のメッセージでピアによる確認を提供します。
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メッセージには、ciphersuiteリストが実際に認証される前に、選択したciphersuiteに基づいてアルゴリズムで保護されているペイロードenc_pk（pd_payload_block）がオプションで含まれている場合があることに注意してください。古典的な格下げ攻撃では、敵がリアルタイムで壊れたり、暗号化保護を完全に無効にしようとする非常に弱い暗号を選択します。EAP-GPSK用に定義されているCiphersuiteは、少なくとも認証と整合性の保護を提供する必要があるため、後者は不可能です。機密保護はオプションです。将来のある時点で、ciphersuiteにリアルタイムで壊れることができるアルゴリズムが含まれている場合、ピアに関するポリシーとサーバーは、そのようなciphersuiteを当事者によって選択してはならないことを示す必要があります。
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.
さらに、敵は、クライアントが機密保護を提供しないciphersuiteを選択するためのCiphersuiteの選択を変更する場合があります。その結果、これにより、PD_Payload_BlockのコンテンツがClearTextで送信されます。Protocol DesignersがEAP-GPSKを拡張してGPSK-2メッセージのpd_payload_blockに情報を伝達する場合、機密保護が必須かどうかを示す必要があります。このような拡張が機密保護を備えたciphersuiteを必要とする場合、ピアのポリシーは、GPSK-2メッセージのpd_payload_blockにその拡張機能の情報を送信しないことでなければなりません。ピアは、可能であれば、この情報要素の送信を、ciphersuiteの交渉がすでに確認されている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に新しいEAPタイプを割り当てました（51）。
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は、Ciphersuites、保護されたデータ型、障害コード、およびOPコードの新しいレジストリを作成しました。IANAは、以下に定義するように、これらのレジストリに指定されたシファースーツ、保護されたデータ型、障害コード、およびOPコードを追加しました。Ciphersuites（ブロックベースまたはハッシュベース）を定義する値、保護されたデータペイロード、障害コード、およびOPコードを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 Ciphersuites」レジストリの初期内容を表しています。csuite/specifierフィールドの長さは16ビットです。他のすべての値は、IANA登録を介して利用できます。各ciphersuiteは、次のアルゴリズムのインスタンス化（暗号化、整合性、キー派生、キーの長さ）をどのようにインスタンス化するかを指定する必要があります。
The following are the initial contents of the "EAP-GPSK Protected Data Payloads" registry:
以下は、「EAP-GPSK保護されたデータペイロード」レジストリの初期内容です。
o 0x0000 : Reserved
o 0x0000：予約
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
o 0x00000000：予約
o 0x00000001 : PSK Not Found
o 0x00000001：PSKが見つかりません
o 0x00000002 : Authentication Failure o 0x00000003 : Authorization Failure
o 0x00000002：認証障害o 0x00000003：承認障害
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
o 0x00：予約
o 0x01 : GPSK-1
o 0x01：gpsk-1
o 0x02 : GPSK-2
o 0x02：GPSK-2
o 0x03 : GPSK-3
o 0x03：GPSK-3
o 0x04 : GPSK-4
o 0x04：GPSK-4
o 0x05 : GPSK-Fail
o 0x05：gpsk-fail
o 0x06 : GPSK-Protected-Fail
o 0x06：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]要件を満たす強力な共有秘密に基づいたメカニズムを開発するために作成されたEAPメソッドアップデート（EMU）デザインチームの共同努力です。デザインチームのメンバー（アルファベット順）は次のとおりです。
o Jari Arkko
o ジャリ・アークコ
o Mohamad Badra
o モハマド・バドラ
o Uri Blumenthal
o Uri Blumenthal
o Charles Clancy
o チャールズ・クランシー
o Lakshminath Dondeti
o Lakshminath dondeti
o David McGrew
o デビッド・マクグリュー
o Joe Salowey
o ジョー・サロウィー
o Sharma Suman o Hannes Tschofenig
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.
o Jouni MalinenとBernard Abobaは、2006年6月の文書に関する初期のコメントについて。
o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela Vanderveen, and Ray Bell for their input to the ciphersuite discussions between July and August 2006.
o Lakshminath Dondeti、David McGrew、Bernard Aboba、Michaela Vanderveen、およびRay Bellは、2006年7月から8月までの間にCiphersuiteの議論に参加してくれました。
o Lakshminath Dondeti for his detailed review (sent to the EMU mailing list on 12 July 2006).
o Lakshminath Dondetiの詳細なレビューについて（2006年7月12日にEMUメーリングリストに送信）。
o Based on a review requested from NIST, Quynh Dang suggested changes to the GKDF function (December 2006).
o NISTから要求されたレビューに基づいて、Quynh DangはGKDF関数の変更を提案しました（2006年12月）。
o Jouni Malinen and Victor Fajardo for their review in January 2007.
o 2007年1月のレビューのために、Jouni MalinenとVictor Fajardo。
o Jouni Malinen for his suggestions regarding the examples and the key derivation function in February 2007.
o Jouni Malinen 2007年2月の例と重要な派生関数に関する彼の提案について。
o Bernard Aboba and Jouni Malinen for their review in February 2007.
o 2007年2月のレビューのために、バーナード・アボバとジュニア・マリネン。
o Vidya Narayanan for her review in March 2007.
o 2007年3月にレビューをしたVidya Narayanan。
o Pasi Eronen for his IESG review in March and July 2008.
o Pasi Eronenは、2008年3月と7月にIESGレビューを行っています。
o Dan Harkins for his review in June 2008.
o 2008年6月のレビューのためのダンハーキンス。
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 EMUワーキンググループの議長であるJoe Saloweyは、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 Paul Rowe、Arnab Roy、Andre Scedrov教授、およびJohn C. Mitchell教授にEAP-GPSKの分析をしてくれたことに感謝します。攻撃と格下げ攻撃へ。入力に基づいて、キー派生関数が変更され、セキュリティに関する考慮事項セクションのテキストが更新されました。
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 最後に、ワーキンググループの椅子であるJoe Saloweyに、彼の支援と彼が私たちと開かれた問題について話し合うのに費やしたことに感謝したいと思います。
[AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) 197, November 2001.
[AES]国立標準技術研究所、「高度な暗号化標準（AES）の仕様」、連邦情報処理基準（FIPS）197、2001年11月。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Blunk、L.、Vollbrecht、J.、Carlson、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] Eastlake、D。およびT. Hansen、「US Secure Hashアルゴリズム（SHAおよびHMAC-SHA）」、RFC 4634、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、RFC 5247、2008年8月。
[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 Standard 802.11-2007、3月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] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（EAP）メソッド要件」、RFC 4017、2005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA
T.チャールズ・クランシー・ドッド・ラボ・フォー・テレコミュニケーション・サイエンス8080グリーンミード・ドライブ・カレッジ・パーク、メリーランド州20740 USA
EMail: clancy@ltsnet.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
EMail: Hannes.Tschofenig@gmx.net