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