RFC4764 日本語訳
4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible AuthenticationProtocol (EAP) Method. F. Bersani, H. Tschofenig. January 2007. (Format: TXT=133990 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Bersani
Request for Comments: 4764 France Telecom R&D
Category: Experimental H. Tschofenig
Siemens Networks GmbH & Co KG
January 2007
コメントを求めるワーキンググループF.ベルサニの要求をネットワークでつないでください: 4764年のフランステレコム研究開発カテゴリ: 実験H.TschofenigジーメンスネットワークGmbHと共同kg2007年1月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配布しているプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実装と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
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-PSKを指定します、互いの認証とセッションの主要な派生のための拡張認証プロトコル(EAP)メソッドがPreによって共有されたKey(PSK)を使用して。 互いの認証が交信する双方でうまくいっているとき、EAP-PSKは保護された通信チャネルを提供します。このドキュメントはこのチャンネルの結果指摘の保護された交換だけの使用について説明しますが、将来のEAP-PSK拡張子は他の目的にチャンネルを使用するかもしれません。 EAP-PSKはIEEE802.11などの不安定なネットワークの上の認証のために設計されています。
Bersani & Tschofenig Experimental [Page 1] RFC 4764 EAP-PSK January 2007
[1ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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
1. 序論…4 1.1. EAP-PSKの目標を設計してください…4 1.1.1. 簡単さ…4 1.1.2. 広い適用性…5 1.1.3. セキュリティ…5 1.1.4. 伸展性…5 1.2. 用語…5 1.3. コンベンション…8 1.4. 仕事を関係づけます…9 2. 概要について議定書の中で述べてください…12 2.1. EAP-PSKの主要な階層構造…13 2.1.1. PSK…13 2.1.2. AK…14 2.1.3. KDK…14 2.2. TEK…15 2.3. MSK…15 2.4. EMSK…15 2.5. IV…15 3. EAP-PSKの暗号のデザイン…15 3.1. 主要なセットアップ…16 3.2. 認証された主要な交換…19 3.3. 保護されたチャンネル…23 4. EAP-PSKメッセージは流れます…25 4.1. EAP-PSKの標準の認証…26 4.2. EAP-PSKは認証を広げました…28 5. EAP-PSKメッセージ・フォーマット…31 5.1. EAP-PSK最初のメッセージ…32 5.2. EAP-PSK第2メッセージ…34 5.3. EAP-PSK第3メッセージ…36 5.4. EAP-PSK第4メッセージ…39 6. EAP-PSKのための操作の規則はチャンネルを保護しました…41 6.1. 結果指摘を保護します…41 6.1.1. CONT…42 6.1.2. _成功します…43 6.1.3. _失敗します…43 6.2. 認証を広げています…43 7. IANA問題…45 7.1. EAP-PSKのためのEAP-要求/応答タイプの配分…45 7.2. EXT形式数の配分…45 8. セキュリティ問題…46 8.1. 互いの認証…46 8.2. 結果指摘を保護します…47 8.3. 保全保護…48 8.4. 保護を再演してください…48 8.5. 反射は攻撃されます…48 8.6. 辞書は攻撃されます…49
Bersani & Tschofenig Experimental [Page 2] RFC 4764 EAP-PSK January 2007
[2ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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
8.7. キー派生…49 8.8. サービス妨害抵抗…51 8.9. セッション独立…51 8.10. PSKのエキスポ…52 8.11. 断片化…52 8.12. 拘束力があった状態で、精神を集中してください…53 8.13. 速く再接続してください…53 8.14. アイデンティティ保護…53 8.15. Ciphersuite交渉を保護します…55 8.16. 秘密性…55 8.17. 暗号の結合…55 8.18. EAP-PSKの実装…55 9. セキュリティクレーム…56 10. 承認…57 11. 参照…57 11.1. 標準の参照…57 11.2. 有益な参照…パスワードからのPSKの58付録A.世代--がっかりしています…62
Bersani & Tschofenig Experimental [Page 3] RFC 4764 EAP-PSK January 2007
[3ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
1. Introduction
1. 序論
1.1. Design Goals for EAP-PSK
1.1. EAP-PSKのデザイン目標
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).
このドキュメントはPreによって共有されたKey(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でのフランステレコムの研究開発で開発されました。 それは、インターネットコミュニティの一般情報、独立している実装を許容するためにRFCとして発行されます。
Because PSKs are of frequent use in security protocols, other protocols may also refer to a PSK or contain this word in their name. For instance, Wi-Fi Protected Access (WPA) [48] specifies an authentication mode called "WPA-PSK". EAP-PSK is distinct from these protocols and should not be confused with them.
PSKsがセキュリティプロトコルで頻繁に役に立つので、他のプロトコルは、また、PSKについて言及するか、またはそれらの名前のこの単語を含むかもしれません。 例えば、Wi-Fi Protected Access(WPA)[48]は"WPA-PSK"と呼ばれる認証モードを指定します。 EAP-PSKはこれらのプロトコルと異なって、それらに混乱しているべきではありません。
Design goals for EAP-PSK were:
EAP-PSKのデザイン目標は以下の通りでした。
o Simplicity: EAP-PSK should be easy to implement and deploy without
any pre-existing infrastructure. It should be available quickly
because recently-released protocols, such as IEEE 802.11i [27],
employ EAP in a different threat model than PPP [44] and thus
require "modern" EAP methods.
o 簡単さ: 少しも先在のインフラストラクチャなしで実装しやすくて、EAP-PSKは配布しやすいはずです。 それは、IEEE 802.11i[27]などの最近リリースされたプロトコルがPPP[44]と異なった脅威モデルでEAPを使うのですぐに利用可能であり、その結果、「現代」のEAPメソッドを必要とするべきです。
o Wide applicability: EAP-PSK should be suitable to authenticate
over any network, and in particular over IEEE 802.11 [28] wireless
LANs.
o 広い適用性: EAP-PSKはどんなネットワークの上とも、そして、特にIEEE802.11[28]の上で無線LANを認証するのにおいて適当であるはずです。
o Security: EAP-PSK should be conservative in its cryptographic
design.
o セキュリティ: EAP-PSKは暗号のデザインで保守的であるべきです。
o Extensibility: EAP-PSK should be easily extensible.
o 伸展性: EAP-PSKは容易に広げることができるべきです。
1.1.1. Simplicity
1.1.1. 簡単さ
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:
ディフィー-ヘルマンの主要な交換のように非対称の暗号を使用するのではなく、そのような基関数、および事項における制限がEAP- PSKを作ります:
Bersani & Tschofenig Experimental [Page 4] RFC 4764 EAP-PSK January 2007
[4ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
o Easy to understand and implement while avoiding cryptographic
negotiations.
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がアイデンティティ保護、パスワードサポート、または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はType長さの価値(TLV)のデザインではなく、固定メッセージ・フォーマットを選びました。
1.1.2. Wide Applicability
1.1.2. 広い適用性
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脅威モデルです。
1.1.3. Security
1.1.3. セキュリティ
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は、どんな新しい暗号のメカニズムも発明するのを避けようとします。 それは、代わりに暗号の共同体によって再検討された既存の基関数とプロトコルに建てるのを試みます。
1.1.4. Extensibility
1.1.4. 伸展性
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は、より洗練されたサービスを提供できるでしょう。
1.2. Terminology
1.2. 用語
Authentication, Authorization, and Accounting (AAA)
Please refer to [10] for more details.
認証、Authorization、およびAccounting(AAA)はその他の詳細のための[10]について言及してください。
AES-128 A block cipher specified in the Advanced Encryption
Standard [7].
AES-128Aブロック暗号はエー・イー・エス[7]で指定しました。
Authentication Key (AK)
A 16-byte key derived from the PSK that the EAP peer and
server use to mutually authenticate.
互いに認証するEAP同輩とサーバが使用するPSKから得られた認証のKey(AK)のA16バイトのキー。
Bersani & Tschofenig Experimental [Page 5] RFC 4764 EAP-PSK January 2007
[5ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
AKEP2 An authenticated key exchange protocol; please refer to
[14] for more details.
AKEP2 Anは主要な交換プロトコルを認証しました。 その他の詳細のための[14]を参照してください。
Backend Authentication Server
An entity that provides an authentication service to an
Authenticator. When used, this server typically executes
EAP methods for the Authenticator. (This terminology is
also used in [26], and has the same meaning in this
document.)
Authenticatorへの認証サービスを提供するバックエンドAuthentication Server An実体。 使用されると、このサーバは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によって推薦されたAESの認証運転モードです。
Extensible Authentication Protocol (EAP)
Defined in [3].
[3]で定義された拡張認証プロトコル(EAP)。
EAP Authenticator (or simply Authenticator)
The end of the EAP link initiating the EAP authentication
methods. (This terminology is also used in [26], and has
the same meaning in this document.)
EAP認証方法に着手するEAPの端がリンクするEAP Authenticator(または、単にAuthenticator)。 (この用語は、また、[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はじっと見ます(単にじっと見てください)。Authenticatorに応じるEAPリンクの端。 ([26]では、この終わりはSupplicantとして知られています。)
EAP server (or simply server)
The entity that terminates the EAP authentication with the
peer. When there is no Backend Authentication Server, this
term refers to the EAP Authenticator. Where the EAP
Authenticator operates in pass-through mode, it refers to
the Backend Authentication Server.
EAPサーバ、(または、単にサーバ) 同輩と共にEAP認証を終える実体。 Backend Authentication Serverが全くないとき、今期はEAP Authenticatorについて言及します。 EAP Authenticatorが通じて通りモードで作動するところと、それはBackend Authentication Serverを呼びます。
EAX An authenticated-encryption with associated data mode of
operation for block ciphers [4].
ブロックする関連データ運転モードによる認証された暗号化のEAX Anは[4]を解きます。
Extended Master Session Key (EMSK)
Additional keying material derived between the EAP peer and
server that is exported by the EAP method. The EMSK is
reserved for future uses that are not defined yet and is
not provided to a third party. Please refer to [9] for
more details.
EAP-PSK generates a 64-byte EMSK.
材料がEAP同輩とサーバで間それがEAPメソッドでエクスポートされる引き出した拡張Master Session Key(EMSK)の追加合わせること。 EMSKはまだ定義されていない将来の用途のために予約されて、第三者に提供されません。 その他の詳細のための[9]を参照してください。 EAP-PSKは64バイトのEMSKを生成します。
Initialization Vector (IV)
A quantity of at least 64 bytes, suitable for use in an
initialization vector field, that is derived between the
peer and EAP server. Since the IV is a known value in
(IV)大量であることの少なくとも64バイト、初期化ベクトル場での使用に適していて、それは同輩とEAPサーバの間で引き出されます。初期設定Vector、以来、IVは中の知られている値です。
Bersani & Tschofenig Experimental [Page 6] RFC 4764 EAP-PSK January 2007
[6ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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.
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).
16バイトのキーがEAP同輩とサーバがセッションキーを引き出すのに使用するPSKに由来していた主要な派生Key(KDK)(すなわち、TEK、MSK、およびEMSK)。
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の目的がメッセージの源とその保全[40]の両方を見なしながら保証を提供することになっているメッセージ立証コード(MAC)。 IEEE 802.11iは、頭文字語MAC(中型のAccess Control)のもう片方の意味への混乱を避けるのに、頭文字語MIC(メッセージIntegrity Check)を使用します。
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メソッドでエクスポートされる材料を合わせて、Session Key(MSK)をマスタリングしてください。 既存の実装では、EAPサーバとして機能するAAAサーバはAuthenticator[9]にMSKを輸送します。 EAP-PSKは64バイトのMSKを生成します。
Network Access Identifier (NAI)
Identifier used to identify the communicating parties [2].
ネットワークAccess Identifier(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.
メッセージ立証コードが[29]であると生成する1つKey CBC-Mac1(OMAC1)のAメソッド。 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.
Forward Secrecyを完成させてください。長期の秘密鍵の感染がどんな以前のセッションキーにも感染しないという(PFS)信用。 言い換えれば、いったんEAP対話が終わっていて、対応するキーが忘れられていると、接続からデータのすべてを記録して、同輩とサーバの長期のキーのすべてに近づく手段を得るだれかさえセッションの主要なスペースのブルートフォース検索をしないで会話を保護するのに使用されるキーを再建できません。
EAP-PSK does not have this property.
EAP-PSKには、この特性がありません。
Bersani & Tschofenig Experimental [Page 7] RFC 4764 EAP-PSK January 2007
[7ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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.
プレShared Key(PSK)のA Preが分配しているKeyは左右対称の暗号で単にキーを意味します。 それを使用するプロトコルが行われる前に、このキーは、何らかの先のメカニズムによって引き出されて、パーティーの間で共有されます。 それは単に当然のことの長さのしばらく系列です。その各ビットは無作為に一様に独自に選ばれました。 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.
保護されたResult Indication Pleaseは今期の定義のための[3]のセクション7.16について言及します。 この特徴は、EAPの成功/故障パケットが単方向ので導入されて、保護されていません。
Transient EAP Key (TEK)
A session key that is used to establish a protected channel
between the EAP peer and server during the EAP
authentication exchange. The TEK is appropriate for use
with the ciphersuite negotiated between the EAP peer and
server to protect the EAP conversation. Note that the
ciphersuite used to set up the protected channel between
the EAP peer and server during EAP authentication is
unrelated to the ciphersuite used to subsequently protect
data sent between the EAP peer and Authenticator [9].
EAP-PSK uses a 16-byte TEK for its protected channel, which
is the only ciphersuite available between the EAP peer and
server to protect the EAP conversation. This ciphersuite
uses AES-128 in the EAX mode of operation.
aを証明するのに使用される一時的なEAP Key(TEK)AセッションキーはEAP認証交換の間、EAP同輩とサーバの間のチャンネルを保護しました。 TEKはciphersuiteがEAP同輩とサーバの間で交渉されている使用がEAPの会話を保護するのは、適切です。 EAP認証の間、EAP同輩とサーバの間の保護されたチャンネルをセットアップするのにおいて中古のciphersuiteがEAP同輩とAuthenticator[9]の間に送られたデータが次に保護されるのにおいて中古のciphersuiteに関係ないことに注意してください。 EAP-PSKは、EAPの会話を保護するのに保護されたチャンネルのための16バイトのTEKを使用します。(チャンネルはEAP同輩とサーバの間で利用可能な唯一のciphersuiteです)。 このciphersuiteはEAX運転モードでAES-128を使用します。
1.3. Conventions
1.3. コンベンション
All numbers presented in this document are considered in network-byte order.
本書では提示されたすべての数がネットワークバイトオーダーで考えられます。
|| denotes concatenation of strings (and not the logical OR).
|| ストリング(そして、論理的な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の下でStringのMACを指示します(MACsを計算するのに本書では使用されるアルゴリズムはAES128と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が指定されるとして計算されているStringの連結を指示します。 したがって、私たちには、Kが文脈によって指定されている状態で、以下があります。 [ストリング]=ストリング||Mac(K、ストリング)
** denotes integer exponentiation.
** 整数羃法を指示します。
Bersani & Tschofenig Experimental [Page 8] RFC 4764 EAP-PSK January 2007
[8ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
"i" denotes the unsigned binary representation on 16 bytes of the integer i in network byte order. Therefore, this notation only makes sense when i is between 0 and 2**128-1.
「i」はネットワークバイトオーダーにおける、整数iの16バイトで未署名の2進法表示を指示します。 したがって、iが0〜2**128-1であるのにだけ、この記法は理解できます。
<i> denotes the unsigned binary representation on 4 bytes of the integer i in network byte order. Therefore, this notation only makes sense when i is between 0 and 2**32-1.
<i>はネットワークバイトオーダーにおける、整数iの4バイトで未署名の2進法表示を指示します。 したがって、iが0〜2**32-1であるのにだけ、この記法は理解できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
1.4. Related Work
1.4. 関連仕事
At the time this document is written, only three EAP methods are standards track EAP methods per IETF terminology (see [17]), namely:
このドキュメントが書かれているときIETF用語あたり3つのEAPメソッドだけが標準化過程EAPメソッドである、([17])を見てください、すなわち:
o MD5-Challenge (EAP-Request/Response type 4), defined in [3], which
uses a MD5 challenge similar to [45].
o [45]と同様のMD5挑戦を使用する[3]で定義されたMD5-挑戦(EAP-要求/応答タイプ4)。
o OTP (EAP-Request/Response type 5), defined in [3], which aims at
providing One-Time Password support similar to [22] and [39].
o One-時間Passwordを提供するところの目的がサポートする[3]で定義された[22]と[39]と同様のOTP(EAP-要求/応答タイプ5)。
o GTC (EAP-Request/Response type 6), defined in [3], which aims at
providing Generic Token Card Support.
o Generic Token Card Supportを提供するのを目的とする[3]で定義されたGTC(EAP-要求/応答タイプ6)。
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 EAP-TLS[11])、したがって、どれが規格でないか。実験的なRFCとしての1、(([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)。(EAPはEAP-要求/応答に31をタイプさせます)。
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!
しかしながら、どんな安全で熟しているPreによって共有されたKey EAPメソッドも今まで簡単で広く利用可能ではありません、Preの共有されたKeyメソッドが最も基本的なものであるのでひとしお残念などれ!
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).
将来のPreによって共有されたKey EAPメソッドのための既存の提案は簡潔に今後(EAPメソッドの、より徹底的な統合のための[16]について言及する)見直されます。
Bersani & Tschofenig Experimental [Page 9] RFC 4764 EAP-PSK January 2007
[9ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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].
* LEAP。[38]で指定されて、[49]でその脆弱性について議論します。
* EAP-MSCHAPv2, which is specified in [34] and whose
vulnerabilities are indirectly discussed in [43].
* EAP-MSCHAPv2。[34]で指定されて、[43]で間接的にその脆弱性について議論します。
o Essentially require additional infrastructure, e.g., EAP-SIM [24],
EAP-AKA [12], or OTP/token card methods like [31].
o 本質的には[31]のような追加インフラストラクチャ、例えば、EAP-SIM[24]、EAP-AKA[12]、または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 共有された主要なメソッドではありませんが、しばしばすなわち、非常に残念ながら、広い採用がIntellectual Property Rights問題で妨げられるように思えるそれら、パスワードメソッド、例えば、EAP-SRP[18]またはスピーク[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 ジェネリックトンネリングメソッド(本質的には必要であるようにPreによって共有されたキーズを当てにしない)はサーバのための公開鍵証明書です、そして、すなわち、同輩にいかなるEAPメソッドか他の同等の非EAP認証機構でも[32]と[21]を認証させてください。
o Are abandoned but have provided the basis for EAP-PSK, namely,
EAP-Archie [47].
o 捨てられますが、すなわち、EAP-PSK、EAP-アーチー[47]の基礎を提供しました。
o Are possible alternatives to EAP-PSK (i.e., claimed to be secure
and subject of active work):
o EAP-PSK(すなわち、安全であって、受けることがあると主張されて、アクティブでは、働く)に、可能な代替手段です:
* EAP-FAST [42].
* 速いEAP[42]。
* EAP-IKEv2 [46].
* EAP-IKEv2[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封鎖を避けたがっていました。
Bersani & Tschofenig Experimental [Page 10] RFC 4764 EAP-PSK January 2007
[10ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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は左右対称の暗号で単にPreによって共有されたKeyメソッドを提案するのに制限されました。
* 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は効率で念頭に設計されました。
Bersani & Tschofenig Experimental [Page 11] RFC 4764 EAP-PSK January 2007
[11ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
2. Protocol Overview
2. プロトコル概要
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ | | ^ | EAP-PSKは議定書を作ります: あらかじめ共有された主要なEAPメソッド| | | | | | +----------+ | | | | PSK| | | | |(16バイト)| | | | +----------+ | | | | | | | v| | | *********************** | | | *変更されたカウンタモード*| | | *********************** | | | | | | | | vに対して| | | +----------+ +----------+ +----------------+ | | | | AK| | KDK| | 底ならし革_P| | | | |(16バイト)| |(16バイト)| | (16バイト) | | | | +----------+ +----------+ +----------------+ | | | | | | | | | | | | | +-----------+ | | | | | +--------+|プレーンテキスト| | | | | |+-------+|ヘッダーH||var.の長さ| | | | | ||一回だけN||22バイト|+-----------+ v Localに対して| ||4バイト|+--------+ | *********************** EAPに| |+-------+ | +--------+ +------*変更されたカウンタモード*メソッド| | | v対***********************に| | | | ******* +--------+ |64 |64 | | | | * EAX*-------|TEK| |バイト|バイト| | | +-->*******|16バイト| | | | | | | +--------+ | | | | | +-----+----+ | | | | | vに対して| | | | |+--------+ +-------------------+ | | | | ||タグ| |暗号テキスト有効搭載量| | | | | ||16バイト| | 可変長L| | | | | |+--------+ +-------------------+ | | | V+++++++++++++++++++++++++++++++++---+ | | ^ +-+-+-+-+-++ +-+-+-+-+-++ | |MSK| |EMSK| | | | | | エクスポートされます。| EAPによる++++++++++++++|
Bersani & Tschofenig Experimental [Page 12] RFC 4764 EAP-PSK January 2007
[12ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
| | Method |
| | |
V V |
************************* V
* AAA Key Derivation * ---+
* Naming & Binding *
*************************
| | メソッド| | | | V V| ************************* V*AAAの主要な派生*---+ **************************を命名して、縛る*
Figure 1: EAP-PSK Key Hierarchy Overview
図1: EAP-PSKの主要な階層構造概要
2.1. EAP-PSK Key Hierarchy
2.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の主要な階層構造によって奮い立たせられます。
2.1.1. The PSK
2.1.1. PSK
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同輩がそれらのそれぞれのNAIsのおかげで互いと共に正しいPSKを使用に特定すると仮定します。 これは、与えられた同輩NAIを使用する与えられたサーバNAIを使用するEAPサーバとEAP同輩の間で共有されたPSKが最も1つにあるだけであるに違いないことを意味します。
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.
Authentication Key(AK)とKey-派生Key(KDK)は、それぞれこのPSKは使用されています、2個の16バイトの静的な長命のサブキーを引き出すために図2に示されるように呼びました。 一度この派生をするだけであるべきです: それは主要なセットアップと呼ばれます。 実際にプロトコルEAP- PSKによって使用される静的な長い送られたキー、AK、およびKDKを引き出すのに、PSKが静的な長命のキーとして使用されるのではなく、単に初期の合わせるとして使用される理由に関する説明のためのセクション3.1が物質的であることを見てください。
Bersani & Tschofenig Experimental [Page 13] RFC 4764 EAP-PSK January 2007
[13ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
+---------------------------+
| PSK |
| (16 bytes) |
+---------------------------+
| |
v v
+---------------------------+ +---------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+---------------------------+ +---------------------------+
+---------------------------+ | PSK| | (16バイト) | +---------------------------+ | | v対+---------------------------+ +---------------------------+ | AK| | KDK| | (16バイト) | | (16バイト) | +---------------------------+ +---------------------------+
Figure 2: Derivation of AK and KDK from the PSK
図2: PSKからのAKとKDKの派生
2.1.2. AK
2.1.2. AK
EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP server.
EAP-PSKは、互いにEAP同輩とEAPサーバを認証するのにAKを使用します。
AK is a static long-lived key derived from the PSK; see Section 3.1. AK is not a session key.
AKはPSKから得られた静的な長命のキーです。 セクション3.1を見てください。 AKはセッションキーではありません。
The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1.
EAPサーバとEAP同輩はそれらのそれぞれのNAIsのおかげで互いと共に正しいAKを使用に特定します。 これは、与えられた同輩NAIを使用する与えられたサーバNAIを使用するEAPサーバとEAP同輩の間で共有されたAKが最も1つにあるだけであるに違いないことを意味します。 与えられた同輩NAIを使用する与えられたサーバNAIを使用するEAPサーバとEAP同輩の間で共有されたPSKが最も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サーバに基づいて最初のEAP-PSKメッセージ(ID_S; すなわち、セクション4.1を見る)のEAPサーバによって送られたNAIとそれが2番目のEAP-PSKメッセージに含んでいるのを選ぶEAP同輩NAIを使用するためにAKを選びます(ID_P; すなわち、セクション4.1を見てください)。
2.1.3. KDK
2.1.3. KDK
EAP-PSK uses KDK to derive session keys shared by the EAP peer and the EAP server (namely, the TEK, MSK, and EMSK).
EAP-PSKは、EAP同輩とEAPサーバ(すなわち、TEK、MSK、およびEMSK)によって共有されたセッションキーを引き出すのにKDKを使用します。
KDK is a static long-lived key derived from the PSK; see Section 3.1. KDK is not a session key.
KDKはPSKから得られた静的な長命のキーです。 セクション3.1を見てください。 KDKはセッションキーではありません。
The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case
EAPサーバとEAP同輩はそれらのそれぞれのNAIsのおかげで互いと共に正しいAKを使用に特定します。 これは、与えられた同輩NAIを使用する与えられたサーバNAIを使用するEAPサーバとEAP同輩の間で共有されたAKが最も1つにあるだけであるに違いないことを意味します。 これはそうです。
Bersani & Tschofenig Experimental [Page 14] RFC 4764 EAP-PSK January 2007
[14ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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.
与えられた同輩NAIを使用する与えられたサーバNAIを使用するEAPサーバとEAP同輩の間で共有されたPSKが最も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サーバに基づいて最初のEAP-PSKメッセージ(ID_S; すなわち、セクション4.1を見る)のEAPサーバによって送られたNAIとそれが2番目のEAP-PSKメッセージに含んでいるのを選ぶEAP同輩NAIを使用するためにAKを選びます(ID_P; すなわち、セクション4.1を見てください)。
2.2. The TEK
2.2. TEK
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は、両方の互いに認証されたパーティーがしっかりと交信する保護されたチャンネルを実装するのに使用されます。
2.3. The MSK
2.3. MSK
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]に従います)。
2.4. The EMSK
2.4. EMSK
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]に従います)。
2.5. The IV
2.5. IV
EAP-PSK does not derive any IV, which complies with [9].
EAP-PSKはどんなIVも引き出しません([9]に従います)。
3. Cryptographic Design of EAP-PSK
3. EAP-PSKの暗号のデザイン
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バイトのPre共有されたKeyと16バイトのPlain Textブロック取ります。 それは16バイトのCipher Textブロックを出力します。 AES-128の詳述について、[7]を参照してください。
AES-128 has been chosen because:
AES-128が選ばれた、:
o It is standardized and implementations are widely available.
o それは標準化されます、そして、実装は広く利用可能です。
Bersani & Tschofenig Experimental [Page 15] RFC 4764 EAP-PSK January 2007
[15ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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は、暗号を1つの義務的なブロックに制限して、交渉を許さないように他のブロック暗号について選ばれました。 'AES-128が安全保障上の理由で推奨しなくて、また、EAP-PSKは推奨しなくて、カットとペーストのEAP-PSKであるべきです'は別のブロック暗号で定義されるべきです。 'このEAP-PSK'はAES-128の安全保障問題のためにEAP-PSKと互換性があった状態で後方であるべきではありません。 したがって、'EAP-PSK'は異なったEAP-要求/応答Type番号を使用するべきです。 EAP-要求/応答Type数のスペース構造が[3]で定義されている状態で、これは問題であるべきではありません。 'EAP-PSKの異なったEAP-要求/応答Type番号の使用'は被害を受け易い攻撃から選ばれたプロトコル攻撃までこの新しいメソッドを防ぐでしょう。
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.
さらに詳細にその後のパラグラフで各部分について議論します。
3.1. The Key Setup
3.1. 主要なセットアップ
EAP-PSK needs two cryptographically separated 16-byte subkeys for mutual authentication and session key derivation. Indeed, it is a rule of thumb in cryptography to use different keys for different applications.
EAP-PSKは互いの認証とセッションの主要な派生のための2個の暗号で切り離された16バイトのサブキーを必要とします。 本当に、それは異なったアプリケーションに異なったキーを使用する暗号の経験則です。
It could have implemented these two subkeys either by specifying a 32-byte PSK that would then be split in two 16-byte subkeys, or by specifying a 16-byte PSK that would then be cryptographically expanded to two 16-byte subkeys.
それは、次に2個の16バイトのサブキーで分割される32バイトのPSKを指定するか、または次に暗号で2個の16バイトのサブキーに広げられる16バイトのPSKを指定することによって、これらの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バイト厄介であるので、後者のオプションは選ばれました。
Bersani & Tschofenig Experimental [Page 16] RFC 4764 EAP-PSK January 2007
[16ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
Hence, the PSK is only used by EAP-PSK to derive AK and KDK. This derivation should be done only once, immediately after the PSK has been provisioned. As soon as AK and KDK have been derived, the PSK should be deleted. If the PSK is deleted, it should be done so securely (see, for instance, [19] for guidance on secure deletion of the PSK).
したがって、PSKは、AKとKDKを引き出すのにEAP-PSKによって使用されるだけです。 PSKが食糧を供給された直後一度だけこの派生をするべきです。 AKとKDKが引き出されるとすぐに、PSKは削除されるべきです。 PSKを削除するなら、それほどしっかりとそれをするべきです(例えば、見てください、PSKの安全な削除の指導のための[19])。
Derivation of AK and KDK from the PSK is called the key setup:
PSKからのAKとKDKの派生は主要なセットアップと呼ばれます:
o The input to the key setup is the PSK.
o 主要なセットアップへの入力はPSKです。
o The outputs of the key setup are AK and KDK.
o 主要なセットアップの出力は、AKとKDKです。
AK and KDK are derived from the PSK using the modified counter mode of operation of AES-128. The modified counter mode is a length increasing function, i.e., it expands one AES-128 input block into a longer t-block output, where t>=2. This mode was chosen for the key setup because it had already been chosen for the derivation of the session keys (see Section 3.2).
PSKからAES-128の変更されたカウンタ運転モードを使用することでAKとKDKを得ます。 変更されたカウンタモードが長さの増加関数である、すなわち、それは、より長いt-ブロック出力、どこt>=2に1つのAES-128入力ブロックを広げるか。 それが既にセッションキーの派生に選ばれていたので(セクション3.2を見てください)、このモードは主要なセットアップに選ばれました。
The details of the derivation of AK and KDK from the PSK are shown in Figure 3.
PSKからのAKとKDKの派生の詳細は図3に示されます。
Bersani & Tschofenig Experimental [Page 17] RFC 4764 EAP-PSK January 2007
[17ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
+--------------------------+
| "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) |
+------------------------+ +------------------------+
+--------------------------+ | "0" | | 入力Block(16バイト)| +--------------------------+ | +に対して----------------+ | | | AES-128(PSK) | | | +----------------+ | | +----------------------------+ | | v対+--------+ +---+ +--------+ +---+ | c1=「1インチ」|、-、>|XOR| | c2=「2インチ」|、-、>|XOR| |16バイト| +---+ |16バイト| +---+ +--------+ | +--------+ | | | +----------------+ +----------------+ | | | | | AES-128(PSK) | | AES-128(PSK) | | | | | +----------------+ +----------------+ | | | | v対+------------------------+ +------------------------+ | AK| | KDK| | (16バイト) | | (16バイト) | +------------------------+ +------------------------+
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インチ」です。 簡単にするために、定数はこの入力ブロックに選ばれました: それが同輩とサーバに頼る値に設定されたかもしれない、(例えば、それらのそれぞれのNAIsのXORが適切に先端を切った、無そっと歩く、)、これだけが多くのセキュリティを体系に加えるように思えませんでしたが、それは複雑さを加えました。 どんな16バイトの定数も選ばれたかもしれません、セキュリティが定数によって取られた特定の値に依存するべきでないとき。 「0インチは任意に選ばれました。」
Bersani & Tschofenig Experimental [Page 18] RFC 4764 EAP-PSK January 2007
[18ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
3.2. The Authenticated Key Exchange
3.2. 認証された主要な交換
The authentication protocol used by EAP-PSK is inspired by AKEP2, which is described in [14].
EAP-PSKによって使用された認証プロトコルはAKEP2によって奮い立たせられます。(AKEP2は[14]で説明されます)。
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によって奮い立たせられます)に示されるように1.5の丸い旅行交換から成ります。
Bob Alice
| RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
ボブ・アリス| RA| |<---------------------------------------------------------| | | | [B| | | | RA| | RB]| |--------------------------------------------------------->| | | | [| | RB]| |<---------------------------------------------------------|
Figure 4: Overview of AKEP2
図4: AKEP2の概要
It is also worth noting that [14] focuses on cryptography and not on designing a real-life protocol. Thus, as noted in subsection "Out- Of-Band-Data" of [14], Alice has to send A, its identity, to Bob so that Bob may select the appropriate credential for the sequel to the conversation. This leads to a slightly complemented version of AKEP2 for EAP-PSK as depicted in Figure 5.
また、[14]が現実のプロトコルを設計するのではなく、暗号に集中することに注意する価値があります。 したがって、「バンドデータの外に」小区分で述べられるように、アリスはボブが続編のために適切な資格証明書を会話に選択できるように、[14]でA、ボブへのアイデンティティを送らなければなりません。 これは図5に表現されるようにEAP-PSKのためのAKEP2のわずかに補足となったバージョンに通じます。
Bob Alice
| A||RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
ボブ・アリス| A||RA| |<---------------------------------------------------------| | | | [B| | | | RA| | RB]| |--------------------------------------------------------->| | | | [| | 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はアリスとボブのそれぞれのアイデンティティです。 彼らはアリスとボブに互いの間の認証された主要な交換を実行するのに使用しなければならないキーを検索させます。 また、それらは暗号の理由によるプロトコルに含まれています。
Bersani & Tschofenig Experimental [Page 19] RFC 4764 EAP-PSK January 2007
[19ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
o The MACs (see Section 1.3 for the notation "[]") are calculated
using a dedicated key.
o MACs(記法"[]"のためにセクション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 記法を使用する16バイトの乱数としてのRAとRB。 これはRA=RAND_SとRB=RAND_Pを意味します。
o A and B as Alice's and Bob's respective NAIs, using Section 4.1
notations; this means A=ID_S and B=ID_P.
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 AES-128が16バイトのタグの長さにAKを使用して、生産している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.
AKEP2では、主要な交換は「暗黙です」: RBからセッションキーを得ます。 EAP-PSKでは、RAND_PからKDKと[5]で説明されたAES-128の変更されたカウンタ運転モードを使用することによって、セッションキーをこのようにして得ます。 それがブロック暗号を当てにして、セキュリティの証拠を持っている簡単な主要な派生体系であるので、このモードは選ばれました。 長さの増加関数である、すなわち、それは、より長いt-ブロック出力、どこt>=2に1つのAES-128入力ブロックを広げるか。 セッションキーの派生は図6に示されます。
Bersani & Tschofenig Experimental [Page 20] RFC 4764 EAP-PSK January 2007
[20ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
+--------------------------+ +-------------------------------+
| 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) |
+------------+ +----------------------+ +----------------------+
+--------------------------+ +-------------------------------+ | 底ならし革_P| | KDK| | 入力Block(16バイト)| | 主要なDerivation Key(16バイト)| +--------------------------+ +-------------------------------+ | | v対+-----------------------------------------------------------------+ | | | 変更されたカウンタモード| | | +-----------------------------------------------------------------+ | | | v対+に------------+ +----------------------+ +----------------------+ | TEK| | MSK| | EMSK| | (16バイト) | | (64バイト) | | (64バイト) | +------------+ +----------------------+ +----------------------+
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(5番目にブロックを出力する2番目の連結)。
o The 64-byte EMSK (the concatenation of the sixth to ninth output
blocks).
o 64バイトのEMSK(9番目にブロックを出力する6の番目ものの連結)。
The details of the derivation of the session keys are shown in Figure 7.
セッションキーの派生の詳細は図7に示されます。
Bersani & Tschofenig Experimental [Page 21] RFC 4764 EAP-PSK January 2007
[21ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
+--------------------------+
| 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) |
+-----------------+ +-----------------+ +------------------+
+--------------------------+ | 底ならし革_P| | 入力Block(16バイト)| +--------------------------+ | +に対して----------------+ | | | AES-128(KDK) | | | +----------------+ | | +---------------------+-- - - - - - - - - - --+ | | | v対+に--------+ +---+ +--------+ +---+ +--------+ +---+ | c1=「1インチ」|、-、>|XOR| | c2=「2インチ」|、-、>|XOR|.......| c9=「9インチ」|、-、>|XOR| |16バイト| +---+ |16バイト| +---+ |16バイト| +---+ +--------+ | +--------+ | +--------+ | | | | +----------------+ +----------------+ +----------------+ | | | | | | | AES-128(KDK) | | AES-128(KDK) |......| AES-128(KDK) | | | | | | | +----------------+ +----------------+ +----------------+ | | | | | | v対+に-----------------+ +-----------------+ +------------------+ | 出力ブロック#1| | 出力ブロック#2| | 出力ブロック#9| | (16バイト) | | (16バイト) |.....| (16バイト) | | TEK| | MSK(ブロック1/4)| | EMSK(ブロック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は9へのi=1で「i」と等しいです)。
Keying material is sensitive information and should be handled accordingly (see Section 8.10 for further discussion).
材料を合わせるのは、機密情報であり、それに従って、扱われるべきです(さらなる議論に関してセクション8.10を見てください)。
Bersani & Tschofenig Experimental [Page 22] RFC 4764 EAP-PSK January 2007
[22ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
3.3. The Protected Channel
3.3. 保護されたチャンネル
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]を参照してください。 エイト環は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 |
+---------------------+ +----------+
+-----------+ +----------------+ +---------------------+ +----------+ | 一回だけN| | ヘッダーH| | プレーンテキスト有効搭載量| | TEK| | 4バイト| | 22バイト| | 可変長L| | 16バイト| +-----------+ +----------------+ +---------------------+ +----------+ | | | | v v対+に-------------------------------------------------------------------+ | | | EAX| | | +-------------------------------------------------------------------+ | | v対+---------------------+ +----------+ | 暗号テキスト有効搭載量| | タグ| | 可変長L| | 16バイト| +---------------------+ +----------+
Figure 8: The Protected Channel
エイト環: 保護されたチャンネル
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 Encrypted有効搭載量になるPlain Text有効搭載量を、コード化して、認証します。 Plain Text有効搭載量は960バイトを超えてはいけません。 セクション5.3、5.4、および8.11を見てください。
o Only authenticates a Header that is thus sent in clear.
o このようにしてはっきりと送られるHeaderを認証するだけです。
EAX is instantiated with AES-128 as the underlying block cipher.
EAXはAES-128と共に基本的なブロック暗号として例示されます。
AES-128 is keyed with the TEK.
AES-128はTEKと共に合わせられます。
Bersani & Tschofenig Experimental [Page 23] RFC 4764 EAP-PSK January 2007
[23ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
The nonce N is used to provide cryptographic security to the encryption and data origin authentication as well as protection replay. Indeed, N is a 4-byte sequence number starting from <0> that is monotonically incremented at each EAP-PSK message within one EAP- PSK dialog, except retransmissions, of course.
一回だけNは暗号のセキュリティを暗号化に提供するのに使用されます、そして、保護と同様にデータ起源認証は再演されます。 本当に、Nは1つのEAP- PSK対話の中でそれぞれのEAP-PSKメッセージで単調に増加される<0>から始める4バイトの系列番号です、「再-トランスミッション」を除いてもちろん。
N was taken to be 4 bytes to avoid 16-byte arithmetic. Since EAX uses a 16-byte nonce, N is padded with 96 zero bits for its high- order bits.
Nに、避ける4バイトが16バイトの演算であったなら、取りました。 EAXが16バイトの一回だけを使用するので、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は巻きつけることができません。 32-2 <2**>にNセットがあるEAP-PSKメッセージを送るサーバのありそうもなくて、しかし、可能な出来事では、それはこの保護されたチャンネルでどんなさらなるメッセージも送ってはいけません。(チャンネルは再利用への値0を引き起こすでしょう)。 サーバが32-1 Nセットをもっている同輩から<2**>までのEAP-PSK答えを受けて、サーバが続いた(通常、EAP-成功かFailureを送ることによって)後に終わっている会話か会話のどちらかが終わっていなくて、その時が中止にならなければならない、(新しい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]).
Header HはEAP RequestかResponseパケット(すなわち、EAP Code、Identifier、Length、EAP-PSK Flagsによって続かれたType野原、およびRAND_S野原)の最初の22バイトから成ります。 (EAP-PSK)上側の層が下層(EAP)の何らかの情報を保護するように正統でなく見えたかもしれませんが、これは、EAP推薦に従うために選ばれました。存在しているのはIETFで練習されます。(セクション7.5を見てください、[3])、見える、(例えば、見てください、[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.
Plain Text有効搭載量はコード化されていることになっているペイロードです、そして、保全は保護されました。 Cipher Text有効搭載量は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.
TagはHeaderとPlain Text有効搭載量の両方を保護するMACです。 Nonceのうまくいっている検証の後に反復操作による保護のためにTagの検証をするだけでよいです。 Tagの検証が成功するなら、Encrypted有効搭載量は、Plain Text有効搭載量を回復するために解読されます。 Tagの検証が失敗するなら、復号化は全く実行されません、そして、このMACの故障は登録されるべきです。 タグの長さは、EAP-PSKの中のEAXのための16バイトになるように選ばれています。 この長さは適切であると暗号の共同体によって考えられます。
Bersani & Tschofenig Experimental [Page 24] RFC 4764 EAP-PSK January 2007
[24ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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を当てにします、そして、OMAC1(OMACの異形)は認証部分への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 それには、どんなIntellectual Property Rightsクレームもありません。
4. EAP-PSK Message Flows
4. EAP-PSKメッセージ流れ
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
最初のEAP-PSKメッセージでは、EAPサーバはアイデンティティについて断言します。 EAP-要求/アイデンティティとEAP-応答/アイデンティティがこの発信の前に起こったと思われないかもしれなくて、またEAP-応答/アイデンティティ(このEAP Identity交換が起こるなら)に応答を含んでいるのが実際のNAIを含まないかもしれないと、同輩はそうするでしょう。
Bersani & Tschofenig Experimental [Page 25] RFC 4764 EAP-PSK January 2007
[25ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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-PSKを実行するEAPサーバがどんなEAP同輩もEAP-PSKを実行しているすべてのEAP-PSK対話に同じEAPサーバNAIを使用しなければならないことを意味します。
4.1. EAP-PSK Standard Authentication
4.1. EAP-PSKの標準の認証
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 |
|--------------------------------------------------------->|
| |
同輩サーバ| 旗||底ならし革_S||ID_S| |<---------------------------------------------------------| | | | 旗||底ならし革_S||底ならし革_P||Mac_P||ID_P| |--------------------------------------------------------->| | | | 旗||底ならし革_S||Mac_S||PCHANNEL_S_0| |<---------------------------------------------------------| | | | 旗||底ならし革_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)
* 特定のMAC(MAC_P)を計算できると立証するのによるサーバに以下を認証してください。MACは2つの挑戦とAKの機能です。 Mac_PはCMAC-AES-128と等しいです。(AK(ID)_P| | ID_S| | 底ならし革_S| | 底ならし革_P)
Bersani & Tschofenig Experimental [Page 26] RFC 4764 EAP-PSK January 2007
[26ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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| | 底ならし革_P)
* Set up the protected channel (P_CHANNEL_S_0) to:
* 以下のことのために、保護されたチャンネル(P_CHANNEL_S_0)をセットアップしてください。
+ Confirm that it has derived session keys (at least the TEK).
+は、セッションキー(少なくともTEK)を引き出したと確認します。
+ Give a protected result indication of the authentication.
+は認証の保護された結果しるしを与えます。
o The fourth message is sent by the peer to the server to finish the
setup of the protected channel (P_CHANNEL_P_1) to:
o 4番目のメッセージは、以下のことのために保護されたチャンネル(P_CHANNEL_P_1)のセットアップを終えるために同輩によってサーバに送られます。
* Confirm that it has derived session keys (at least the TEK).
* セッションキー(少なくともTEK)を引き出したと確認してください。
* Give a protected result indication of the authentication.
* 認証の保護された結果しるしをお願いします。
The PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and fourth EAP- PSK messages contain a MAC-computed thanks to TEK that protects the integrity of the messages. For a detailed list of the fields of the messages that are integrity protected, please refer to Section 3.3.
3番目と4番目のEAP- PSKメッセージのPCHANNEL_S_0とPCHANNEL_P_1分野はメッセージの保全を保護するTEKにMACによって計算された感謝を含んでいます。 保護された保全であるメッセージの分野の詳細なリストについて、セクション3.3を参照してください。
All EAP-PSK messages include a sort of header, which is comprised of two fields:
すべてのEAP-PSKメッセージが一種のヘッダーを含んでいます:(ヘッダーは2つの分野から成ります)。
o Flags, a 1-byte field that is currently only used to number EAP-
PSK messages.
o 旗、現在数のEAP- PSKメッセージに使用されるだけである1バイトの分野。
o RAND_S, a 16-byte challenge sent by the server that is used as a
session identifier.
o RAND_S、セッション識別子として使用されるサーバによって送られた16バイトの挑戦。
This standard message flow could be comprised of only three messages, like AKEP2, were it not the request/response nature of EAP that prevents the third message to be the last one. Since the fourth message is mandatory, EAP-PSK chose to take advantage of this and set up a protected channel.
この標準のメッセージ流動は3つのメッセージだけから成ることができました、AKEP2のように、3番目のメッセージを防ぐEAPの要求/応答自然ではなく、それが最後のものであることであったなら。 4番目のメッセージが義務的であるので、EAP-PSKはこれを利用して、保護されたチャンネルをセットアップするのを選びました。
The standard message flow also includes a statement by the peer of its identity, in addition to the EAP-Response/Identity it may have sent. This behavior follows Section 5.1 of [3], which recommends that the EAP-Response/Identity be used primarily for routing purposes and selecting which EAP method to use, and therefore that EAP methods include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.
また、標準のメッセージ流動はアイデンティティの同輩による声明を含んでいます、それが送ったかもしれないEAP-応答/アイデンティティに加えて。 この振舞いはEAP-応答/アイデンティティが主として、目的を発送して、どのEAP方法を使用したらよいかを選択するのに使用されて、したがって、EAP方法がアイデンティティを得るための方法特有のメカニズムを含むことを勧める[3]のセクション5.1に続きます、彼らがIdentity Responseを当てにする必要はないように。
Bersani & Tschofenig Experimental [Page 27] RFC 4764 EAP-PSK January 2007
[27ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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(s)をチェックします:
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にTagの正当性を含んでいるのはチェックされます。 MAC_Sが無効であるといけないので不必要にTEK、MSK、およびEMSKを引き出すのを避けるためにこの順でバリディティチェックをしなければなりません、互いの認証が失敗した意味。 本当に、TEKは、P_CHANNEL_S_0にTagを含む正当性について確かめるのに使用されます。
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にTagを含む正当性はチェックされます。
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属性で)にコード化されたペイロードがあれば、コード化されたペイロードは解読されます。 そして、解読されたペイロードがシンタクス上不正確であるなら、メッセージは静かに捨てられます。
4.2. EAP-PSK Extended Authentication
4.2. EAP-PSKは認証を広げました。
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
拡張認証を支持しなければなりません、すなわち、セクション6で説明された操作の規則に従って、どんなEAP-PSK実現もEXT属性の発信とレセプションを支持しなければなりません。 しかし、EXT分野のサポートは義務的ですが、支持するどんな義務的な拡大タイプもありません。 これは、サーバだけがセクション6あたりの拡張認証を始めることができるようにサーバが拡張認証をEAP-PSKに噛み合わせると、同輩がEXTサポートで拡張認証を始める試みを認めることを意味します。 if
Bersani & Tschofenig Experimental [Page 28] RFC 4764 EAP-PSK January 2007
[28ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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対話を結論づけることができるでしょう。
The mandatory support of the EXT field is dictated:
EXT分野の義務的なサポートは書き取られます:
o To guarantee a robust behavior in the future where some peers
might support some extensions and others not. All peers will thus
be able to understand that an extended authentication is being
attempted and indicate whether or not they support the extension
that is tried.
o 将来、何人かの同輩が何人かの拡大と他のものを支持するかもしれないところで体力を要している振舞いを保証します。 すべての同輩が、拡張認証が試みられているのを理解して、その結果、彼らが試験済みである拡大を支持するかどうかを示すことができるでしょう。
o To ensure that all implementations will indeed be extensible.
o 本当に、それを確実にするために、すべての実現が広げることができるでしょう。
No extension is currently defined.
拡大は全く現在、定義されません。
At most, one extension may be run within a single EAP-PSK dialog: there can neither be sequences of extensions nor interleaved extensions. However, extensions may take a variable number of round- trips to complete.
高々、1つの拡大がただ一つのEAP-PSK対話の中を走るかもしれません: そこには、缶は、拡大の系列でなく、また拡大をはさみ込みませんでした。 しかしながら、拡大は終了する可変数の丸い旅行をするかもしれません。
Only the server can start an extension and, if it does so, it must start it in the first payload it sends over the protected channel.
サーバだけが拡大を始めることができます、そして、そうするなら、それは保護されたチャンネルの上に送る最初のペイロードでそれを始めなければなりません。
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1(EXT) |
|--------------------------------------------------------->|
| |
. .
. .
. .
| Flags||RAND_S||PCHANNEL_S_2i(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_2i+1(EXT) |
|--------------------------------------------------------->|
| |
同輩サーバ| 旗||底ならし革_S||ID_S| |<---------------------------------------------------------| | | | 旗||底ならし革_S||底ならし革_P||Mac_P||ID_P| |--------------------------------------------------------->| | | | 旗||底ならし革_S||Mac_S||PCHANNEL_S_0(EXT)| |<---------------------------------------------------------| | | | 旗||底ならし革_S||PCHANNEL_P_1(EXT)| |--------------------------------------------------------->| | | . . . . . . | 旗||底ならし革_S||_PCHANNEL_S2i(EXT)| |<---------------------------------------------------------| | | | 旗||底ならし革_S||_PCHANNEL_P2i+1(EXT)| |--------------------------------------------------------->| | |
Figure 10: EAP-PSK Extended Authentication
図10: EAP-PSKは認証を広げました。
Bersani & Tschofenig Experimental [Page 29] RFC 4764 EAP-PSK January 2007
[29ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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.
_2jとPCHANNEL_P_2j+1がさばくEAP-PSKメッセージ(jが0〜iに異なるところ)のPCHANNEL_Sはメッセージの保全を保護する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(s)をチェックします:
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にTagの正当性を含んでいるのはチェックされます。 MAC_Sが無効であるといけないので不必要にTEK、MSK、およびEMSKを引き出すのを避けるためにこの順でバリディティチェックをしなければなりません、互いの認証が失敗した意味。 本当に、TEKは、P_CHANNEL_S_0にTagを含む正当性について確かめるのに使用されます。
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にTagを含む正当性はチェックされます。
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にTagを含む正当性はチェックされます。
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属性における)にコード化されたペイロードがあれば、コード化されたペイロードは解読されます。 そして、解読されたペイロードがシンタクス上不正確であるなら、メッセージは静かに捨てられます。
Bersani & Tschofenig Experimental [Page 30] RFC 4764 EAP-PSK January 2007
[30ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
5. EAP-PSK Message Format
5. EAP-PSKメッセージ・フォーマット
For the sake of simplicity, EAP-PSK uses a fixed message format. There are four different types of EAP-PSK messages:
簡単にするために、EAP-PSKは固定メッセージ・フォーマットを使用します。 4つの異なったタイプに関するEAP-PSKメッセージがあります:
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の代わりに1へのEAP Codeの設定です。
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に表現されます。
Bersani & Tschofenig Experimental [Page 31] RFC 4764 EAP-PSK January 2007
[31ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
5.1. EAP-PSK First Message
5.1. EAP-PSK最初のメッセージ
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 : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=1| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-PSKをタイプしてください。| 旗| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 底ならし革_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メッセージのためのType EAP-PSKは47歳であるに違いありません。
The first EAP-PSK message consists of:
最初のEAP-PSKメッセージは以下から成ります。
o A 1-byte Flags field
o 1バイトのFlags分野
o A 16-byte random number: RAND_S
o 16バイトの乱数: 底ならし革_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に形式を示します。
Bersani & Tschofenig Experimental [Page 32] RFC 4764 EAP-PSK January 2007
[32ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
0
0
0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | T | Reserved | +-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | T| 予約されます。| +-+-+-+-+-+-+-+-+
Figure 12: EAP-PSK Flags Field
図12: EAP-PSKは分野に旗を揚げさせます。
The Flags field is comprised of two subfields:
Flags分野は2つの部分体から成ります:
o A 2-bit T subfield, which indicates the type of EAP-PSK message:
o 2ビットのT部分体:(それは、EAP-PSKメッセージのタイプを示します)。
* 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.
* 4番目のEAP-PSKメッセージのためのT=3はセクション5.4とその後のEAP-PSKに拡張認証の間に交換されるかもしれないメッセージを提示しました。
o A 6-bit Reserved subfield that is set to zero on transmission and
ignored on reception.
o トランスミッションのときにゼロに設定されて、レセプションで無視される6ビットのReserved部分体。
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、4番目のEAP-PSKメッセージにTを設定させるという拡張認証の間に交換されるかもしれない異なったEAP-PSKメッセージとことによると次のものを見分けるのに使用されます。
Bersani & Tschofenig Experimental [Page 33] RFC 4764 EAP-PSK January 2007
[33ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
5.2. EAP-PSK Second Message
5.2. EAP-PSK第2メッセージ
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 : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=2| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-PSKをタイプしてください。| 旗| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 底ならし革_S| + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 底ならし革_P| + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | | + + | Mac_P| + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + : ID_P: : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: EAP-PSK Second Message
図13: EAP-PSK第2メッセージ
Bersani & Tschofenig Experimental [Page 34] RFC 4764 EAP-PSK January 2007
[34ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
It consists of:
それは以下から成ります。
o A 1-byte Flags field
o 1バイトのFlags分野
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バイトの乱数: 底ならし革_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に示されます。
Bersani & Tschofenig Experimental [Page 35] RFC 4764 EAP-PSK January 2007
[35ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
5.3. EAP-PSK Third Message
5.3. EAP-PSK第3メッセージ
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 : : : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=1| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-PSKをタイプしてください。| 旗| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 底ならし革_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バイトのFlags分野
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
Bersani & Tschofenig Experimental [Page 36] RFC 4764 EAP-PSK January 2007
[36ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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 1ビットの拡大旗E。(その旗は0に設定されます)。
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
o 5ビットのReserved分野。(その分野は、放出にゼロに設定されて、レセプションで無視されます)。
R, E, and Reserved are sent encrypted by the protected channel (see Section 3.3).
保護されたチャンネルによってコード化されて、R、E、およびReservedを送ります(セクション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、およびReservedを寄贈するか、コード化されていた状態でそれらをほんとうは送りますが)。
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| +-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一回だけ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | タグ| + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R|0| 予約されます。| +-+-+-+-+-+-+-+-+
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を見ます)。
Bersani & Tschofenig Experimental [Page 37] RFC 4764 EAP-PSK January 2007
[37ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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ビットの拡大旗E。(その旗は1に設定されます)。
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
o 5ビットのReserved分野。(その分野は、放出にゼロに設定されて、レセプションで無視されます)。
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、Reserved、および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はR、E、Reserved、およびEXTが明快のために明確で寄贈されるところに図16に形式を示させます、コード化されていた状態でそれらをほんとうは送りますが)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Tag | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R |1| Reserved| | +-+-+-+-+-+-+-+-+ + : EXT : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一回だけ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | タグ| + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R|1| 予約されます。| | +-+-+-+-+-+-+-+-+ + : 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
o EXT_有効搭載量部分体。(その部分体は拡大のペイロードから成ります)。 EAP Length分野からEXT_有効搭載量の長さを得ます。 EXT_有効搭載量は、8ビットの倍数である長さを少し持たなければならなくて、960バイトを超えてはいけません。 後者の制限目的
Bersani & Tschofenig Experimental [Page 38] RFC 4764 EAP-PSK January 2007
[38ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
at avoiding fragmentation issues (see Section 8.11), whereas the
former comes from the EAP length being specified in bytes.
ところが断片化が発行する(セクション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 : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_タイプ| | +-+-+-+-+-+-+-+-+ + : EXT_有効搭載量: : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The EXT Field
図17: EXT分野
5.4. EAP-PSK Fourth Message
5.4. EAP-PSK第4メッセージ
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 : : : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=2| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-PSKをタイプしてください。| 旗| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 底ならし革_S| + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : PCHANNEL: : : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: EAP-PSK Fourth Message
図18: EAP-PSK第4メッセージ
Bersani & Tschofenig Experimental [Page 39] RFC 4764 EAP-PSK January 2007
[39ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
It consists of:
それは以下から成ります。
o A 1-byte Flags field
o 1バイトのFlags分野
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 1ビットの拡大旗E。(その旗は0に設定されます)。
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
o 5ビットのReserved分野。(その分野は、放出にゼロに設定されて、レセプションで無視されます)。
R, E, and Reserved are sent encrypted by the protected channel (see Section 3.3).
保護されたチャンネルによってコード化されて、R、E、およびReservedを送ります(セクション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ビットの拡大旗E。(その旗は1に設定されます)。
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
o 5ビットのReserved分野。(その分野は、放出にゼロに設定されて、レセプションで無視されます)。
Bersani & Tschofenig Experimental [Page 40] RFC 4764 EAP-PSK January 2007
[40ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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、Reserved、およびEXTを送ります(セクション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_有効搭載量部分体。(その部分体は拡大のペイロードから成ります)。 EAP Length分野からEXT_有効搭載量の長さを得ます。 EXT_有効搭載量は、8ビットの倍数である長さを少し持たなければならなくて、960バイトを超えてはいけません。 後者の制限は断片化問題を避けるのを目的とします(セクション8.11を見てください)。
The format of the EXT field is presented in Figure 17.
EXT分野の形式は図17に示されます。
6. Rules of Operation for the EAP-PSK Protected Channel
6. EAP-PSKの保護されたチャンネルのための操作の規則
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 拡張認証はどう詳細に働いているか。
6.1. Protected Result Indications
6.1. 保護された結果指摘
The R flag of the PCHANNEL field in the third and fourth types of EAP-PSK messages is used to provide result indications.
3番目と4番目のタイプに関するEAP-PSKメッセージの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 01 CONTを意味するために
Bersani & Tschofenig Experimental [Page 41] RFC 4764 EAP-PSK January 2007
[41ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
o 10 to mean DONE_SUCCESS
o 10 DONE_SUCCESSを意味するために
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の値の両方の何らかの情報を覚えています。 それは、成功を示す送られて容認の両方にされたR値の接続詞かEAP-PSK対話の失敗です。
In the case of a standard authentication, the following values of R should be exchanged:
標準の認証の場合では、Rの以下の値を交換するべきです:
o Either the server sends a DONE_SUCCESS in the PCHANNEL of the
third EAP-PSK message, to which the peer replies with a
DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which
successfully ends the EAP-PSK dialog.
o サーバは3番目のEAP-PSKメッセージのPCHANNELでDONE_SUCCESSを送ります。(同輩はEAP-PSK対話を首尾よく終わらせる4番目のEAP-PSKメッセージのPCHANNELのDONE_SUCCESSと共にメッセージに関して返答します)。
o Or the server sends a DONE_FAILURE in the PCHANNEL of the third
EAP-PSK message, to which the peer replies with a DONE_FAILURE in
the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully
ends the EAP-PSK dialog.
o または、サーバは3番目のEAP-PSKメッセージのPCHANNELでDONE_FAILUREを送ります。(同輩は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.
拡張認証の場合では、より複雑な交換は起こるかもしれません(CONT値が導入された理由です)。
The rules of operation for each value that R may take are detailed below.
Rが取るかもしれない各値のための操作の規則は以下で詳細です。
6.1.1. CONT
6.1.1. CONT
The server and the peer each initialize the values of R they intend to send and receive as CONT.
サーバと同輩は、それぞれそれらが送つもりであるいことであるRの値を初期化して、CONTとして受信します。
Here CONT stands for "Continue". It indicates that the EAP-PSK dialog is not yet successful and that the party sending it wants to continue the dialog to try and reach success.
ここに、CONTは「続いてください」を表します。 それは、EAP-PSK対話がまだうまくいっていなくて、それを送るパーティーが成功に達してみるように対話を続けたがっているのを示します。
Indeed, although the peer and the server must have successfully authenticated each other, thanks to MAC_P and MAC_S, before they start communicating over the protected channel, the EAP-PSK dialog may not yet be deemed successful after this mutual authentication because of authorization issues. For instance, a prepaid customer of a wireless Hot-Spot might have successfully authenticated but has to refill its account, e.g., with a credit card transaction over the protected channel, before it is authorized.
本当に、互いを認可問題のために首尾よく同輩とサーバによるこの互いの認証であったに違いありませんが、MAC_PとMAC_Sのおかげで、彼らが保護されたチャンネルの上に交信し始める前にEAP-PSK対話はうまくいくとまだ次々と考えられていないかもしれません。 例えば、無線のHot-スポットの前払いの顧客は、首尾よく認証されていた状態でそうしたかもしれませんが、アカウントを詰め替えなければなりません、例えば、保護されたチャンネルの上にクレジットカードでの取引がある状態で、それが認可されている前に。
Bersani & Tschofenig Experimental [Page 42] RFC 4764 EAP-PSK January 2007
[42ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
6.1.2. DONE_SUCCESS
6.1.2. された_成功
DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK dialog successful and therefore proposes to end this dialog.
DONE_SUCCESSは、それを送ったパーティーが、EAP-PSK対話がうまくいっていると考えるのを示して、したがって、この対話を終わらせるよう提案します。
Once the server has sent a DONE_SUCCESS, it must keep sending this value for R.
サーバがいったんDONE_SUCCESSを送ると、それはRのためにこの値を送り続けなければなりません。
The peer must first receive a DONE_SUCCESS from the server before it is allowed to send a DONE_SUCCESS.
DONE_SUCCESSを送ることができる前に同輩は最初に、サーバからDONE_SUCCESSを受け取らなければなりません。
After the peer has received a DONE_SUCCESS from the server, it may:
同輩がサーバからDONE_SUCCESSを受け取った後に、受け取りました:
o Send a CONT to the server if it has not reached success on its
side. The server that receives a CONT should continue the EAP-PSK
dialog (see Section 8.2 for some discussion on the security
implications of this).
o それが側の上の成功に達していないなら、CONTをサーバに送ってください。 CONTを受けるサーバはEAP-PSK対話を続けるべきです(このセキュリティ含意についての何らかの議論に関してセクション8.2を見てください)。
o Send a DONE_SUCCESS to the server, which will end the EAP-PSK
dialog with success.
o 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対話を終わらせるでしょう)。
6.1.3. DONE_FAILURE
6.1.3. された_の故障
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を送る1番目であり、次に、この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を送る1番目であるなら、このDONE_FAILUREを受けるサーバは、すぐにどんなさらなるEAP-PSKメッセージも送らないでこのEAP-PSK対話を終わらせて、失敗しなければなりません。
6.2. Extended Authentication
6.2. 拡張認証
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.
まさに1つの拡大(EXT分野のEXT_Type部分体で、特定される)はEAP-PSKの間の走行が認証対話を広げたということであるに違いありません。
The extension is run over the protected channel: it can assume confidentiality, integrity, and replay protection.
拡大は保護されたチャンネルの上に走ります: それは秘密性、保全、および反復操作による保護を仮定できます。
Bersani & Tschofenig Experimental [Page 43] RFC 4764 EAP-PSK January 2007
[43ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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_有効搭載量を含んでいます。
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が断片化を提供しないので、拡大は最少量で想定されるかもしれないEXT_有効搭載量の対応する960バイトから1020バイトより大きいEAP MTUを送ってはいけません。([3])を見てください。
Moreover, an extension must not send an empty EXT_Payload (because this has a particular meaning for EAP-PSK; see below).
そのうえ、拡大は空のEXT_有効搭載量を送ってはいけません(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旗のセットで3番目のEAP-PSKメッセージを1に受け取るとき、それは、提案された拡大を処理できるかどうかチェックします。
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をはめ込みます、そして、_Typeにもかかわらず、空のEXT_有効搭載量で同じEXTのEXT分野を含んでください。
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と共に返答します。 そして、方針によって、サーバはDONE_SUCCESSかDONE_FAILUREのどちらかを5番目のEAP-PSKメッセージの同輩に送らなければなりません。 サーバが5番目のEAP-PSKメッセージでDONE_SUCCESSを送ったなら、同輩は6番目のEAP-PSKメッセージでDONE_SUCCESSを送らなければなりません。 これらのすべてのメッセージで、提案された拡大と空のEXT_有効搭載量の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
同輩が提案された拡大を処理できるなら、それはそうします。 この場合、拡大は、値が送って、受けたRを意識していてそれらをアップデートするよう提案できなければなりません。 同輩とサーバの間で交換されたすべてのその後のメッセージがEを持たなければなりません。
Bersani & Tschofenig Experimental [Page 44] RFC 4764 EAP-PSK January 2007
[44ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
flag set to 1 with an EXT field of the EXT_Type of the extension that was proposed and a non-empty EXT_Payload.
旗は提案された拡大のEXT_TypeのEXT分野と非空のEXT_有効搭載量で1にセットしました。
7. IANA Considerations
7. IANA問題
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).
このドキュメントは1新しいインターネットAssigned民数記Authority(IANA)の考慮を導入します: 1つの名前のスペースが登録を必要とするEAP-PSKにあります: EXT_Type値(セクション5.3とセクション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.
Designated Expertが相談されるべきである登録要求のために、責任があるIETF AreaディレクターはDesignated Expertを任命するべきです。 意志はどんな配分も発行されたRFCによって伴われるということです。 しかし、公表のために承認されるRFCの前で値の配分を考慮するために、RFCが発行されるのがいったん明確に見えると、Designated Expertは配分を承認できます。 Designated ExpertはコメントとレビューのためのEAP WGメーリングリスト(または、Areaディレクターによって任命された後継者)に要求を掲示するでしょう、インターネット草稿を含んでいて。 30日間の期間が経過する前に、Designated Expertは登録要求を承認するか、または否定して、EAP WGメーリングリストとの決定の通知かIANAに知らせることと同様にその後継者を発表するでしょう。 説明で否定通知を正当化しなければなりません、そして、可能であることで、それがそうである場合では、提案は具体的であってください。許容できるようになるようにどう要求を変更できるかに関して。
7.1. Allocation of an EAP-Request/Response Type for EAP-PSK
7.1. EAP-PSKのためのEAP-要求/応答タイプの配分
IANA allocated a new EAP Type for EAP-PSK.
IANAはEAP-PSKのために新しいEAP Typeを割り当てました。
7.2. Allocation of EXT Type Numbers
7.2. EXT形式数の配分
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までの範囲があります。
Bersani & Tschofenig Experimental [Page 45] RFC 4764 EAP-PSK January 2007
[45ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
EXT_Type 255 has been allocated for Experimental use.
Experimental使用のためにEXT_Type255を割り当てました。
EXT_Type 1-254 may be allocated on the advice of a Designated Expert, with Specification Required.
Specification RequiredとのDesignated ExpertのアドバイスのときにEXT_Type1-254を割り当てるかもしれません。
8. Security Considerations
8. セキュリティ問題
[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の要求されたセキュリティの特性について論じます。
8.1. Mutual Authentication
8.1. 互いの認証
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.
十分な力の対状PSKに基づいているなら、EAP-PSKは互いの認証を提供します。 PSKが対状かまたは十分強いなら、それは認証を提供しません。 このように、EAP-PSKは他の認証プロトコルがPreによって共有されたキーズを基礎づけたより異なっていません。
Bersani & Tschofenig Experimental [Page 46] RFC 4764 EAP-PSK January 2007
[46ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
8.2. Protected Result Indications
8.2. 保護された結果指摘
EAP-PSK provides protected result indications thanks to its 2-bit R flag (see Section 6.1). This 2-bit R flag is protected because it is encrypted and integrity protected by the EAX mode of operation; see Section 3.3.
EAP-PSKは2ビットのR旗のおかげで保護された結果指摘を提供します(セクション6.1を見てください)。 それが暗号化されていて、保全がEAX運転モードで保護されたので、この2ビットのR旗は保護されます。 セクション3.3を見てください。
Care may be taken against Byzantine failures, that is to say, for instance, when a peer tries to force a server to engage in a never- ending conversation. This could, for example, be done by a peer that keeps sending a CONT after it has received a DONE_SUCCESS from the server. A policy may limit the number of rounds in an EAP-PSK extended authentication to mitigate this threat, which is outside our threat model.
込み入った失敗に対してすなわち、例えば、注意するかもしれません、サーバを同輩が決して終わっていない会話に従事させようとするとき。 例えば、これによる. 方針が制限するかもしれないサーバからDONE_SUCCESSを受けた後にCONTを送り続ける同輩によって行われて、EAP-PSKのラウンドの数はこの脅威を緩和するために認証を広げました、私たちの脅威モデルの外にあるものということであるかもしれません。
It should also be noted that the cryptographic protection of the result indications does not prevent message deletion.
また、結果指摘の暗号の保護がメッセージ削除を防がないことに注意されるべきです。
For instance, let us consider a scenario in which:
例えば、中でシナリオを考えよう、どれ、:
o A server sends a DONE_SUCCESS to a peer.
o サーバはDONE_SUCCESSを同輩に送ります。
o The peer replies with a DONE_SUCCESS.
o 同輩はDONE_SUCCESSと共に返答します。
In the case that the last message from the peer is intercepted, and an EAP Success is sent to the peer before any retransmission from the server reaches it, or the retransmissions from the server are also deleted, the peer will believe that it has successfully authenticated to the server while the server will fail.
同輩からの最後のメッセージを傍受して、サーバからのどんな「再-トランスミッション」もそれに達する前にEAP Successを同輩に送るか、またはまた、サーバからの「再-トランスミッション」を削除して、サーバが失敗しますが、首尾よくサーバに認証されて、同輩は、そうしたと信じるでしょう。
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「4方法の握手」でこれをします。 誤りがEAP-PSKによって検出されないといけないので、それはその時、検出されるべきです(しかしながら、同期を確実にするために外部のメカニズムを当てにするのが、悪い習慣であることに注意してください、これが外部のメカニズムの明白な特性でないなら)。
Bersani & Tschofenig Experimental [Page 47] RFC 4764 EAP-PSK January 2007
[47ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
8.3. Integrity Protection
8.3. 保全保護
EAP-PSK provides integrity protection thanks to the Tag of its protected channel (see Section 3.3).
EAP-PSKは保護されたチャンネルのTagのおかげで保全保護を提供します(セクション3.3を見てください)。
EAP-PSK provides integrity protection if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way, it is no different than other authentication protocols based on Pre-Shared Keys.
十分な力の対状PSKに基づいているなら、EAP-PSKは保全保護を提供します。 PSKが対状かまたは十分強いなら、それは認証を提供しません。 このように、それは他の認証プロトコルがPreによって共有されたキーズを基礎づけたより異なっていません。
8.4. Replay Protection
8.4. 反復操作による保護
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は互いの認証部分の反復操作による保護を提供します。 偶発性はセキュリティのために重要です。
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はN保護されたNonceチャンネルのおかげで保護されたチャンネルの会話の間、反復操作による保護を提供します(セクション3.3を見てください)。 この一回だけは、サーバによって0に初期化されて、有効なEAP-PSKメッセージを受け取るパーティーによって単調に1つ増加されます。 例えば、サーバから有効なEAP-PSKメッセージを受け取った後に、同輩は、x+1に用意ができているNonceと共にEAP-PSKメッセージで答えて、x+2に用意ができているNonceと共にEAP-PSKメッセージを待っています。 xに用意ができているNonceがあるサーバのメッセージの「再-トランスミッション」は同輩EAP層にNonceがEAP-PSK層に透明であるだろうというx+1に用意ができていたメッセージを再送させるでしょう。
The EAP peer must check that the Nonce is indeed initialized to 0 by the server.
EAP同輩は、本当に、Nonceがサーバによって0に初期化されるのをチェックしなければなりません。
8.5. Reflection Attacks
8.5. 反射攻撃
EAP-PSK provides protection against reflection attacks in case of an extended authentication because:
EAP-PSKが拡張認証の場合に反射攻撃に対する保護を提供する、:
o It integrity protects the EAP header (which contains the
indication Request/Response.
o 保全はEAPヘッダーを保護します。それ、(指示Request/応答を含む。
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サーバは変な一回だけでメッセージを受け取るだけですが、EAP同輩は一回だけがあってもメッセージを受け取るだけです。
Bersani & Tschofenig Experimental [Page 48] RFC 4764 EAP-PSK January 2007
[48ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
8.6. Dictionary Attacks
8.6. 辞書攻撃
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 展開に影響を与えます: 人々の中にはPSKsではなく、パスワードを含む既存の資格証明データベースを再利用したがっているかもしれない人もいます。
Because people will probably not heed the warning not to use passwords, guidance to derive a PSK from a password is provided in Appendix A. The method proposed in Appendix A only tries to make dictionary attacks harder. It does not eliminate them.
人々がたぶん、パスワードを使用しないという警告を意に介さないので、Appendix Aで提案されたメソッドが辞書攻撃で、より強く作るだけであろうとするAppendix A.にパスワードからPSKを得る指導を提供します。 それはそれらを排除しません。
However, it does not cause a fatal error if passwords are used instead of PSKs: people rarely use password-derived certificates, so why should they do so for shared keys?
しかしながら、パスワードがPSKsの代わりに使用されるなら、致命的な誤りを引き起こしません: 人々がめったにパスワードで派生している証明書を使用しないので、それらはなぜ共有されたキーのためにそうするべきですか?
8.7. Key Derivation
8.7. 主要な派生
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を使用します。 したがって、PSKに関する知識を持っている人だけに暗号で切り離されてAKとKDKが計算できると信じられています。
Bersani & Tschofenig Experimental [Page 49] RFC 4764 EAP-PSK January 2007
[49ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
A second key derivation occurs to derive session keys, namely, the TEK, MSK, and EMSK (see Section 3.2). It uses KDK as the key to the modified counter mode.
2番目の主要な派生は、すなわち、セッションキー、TEK、MSK、およびEMSKを引き出すために起こります(セクション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バイトのキー・ブロック(セクション2.1を見る)の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 それを防ぐと、何らかの複雑さがプロトコル(通常主要な派生部分でのAESの操作の一方向モードの包含)に追加されたでしょう。
o It is believed that the peer won't try to force the server to use
some pre-specified value for the session keys. Such an attack is
outside the threat model and seems to have little value compared
to a peer sharing its PSK.
o サーバに同輩にセッションキーに何らかのプレ規定値を使用させようとしないと信じられています。 そのような攻撃は、脅威モデルの外にあって、PSKを共有している同輩と値をほとんど比較させないように思えます。
However, this is not the behavior recommended by EAP in Section 7.10 of [3].
しかしながら、これは[3]のセクション7.10でEAPによって推薦された振舞いではありません。
Since deriving the session keys requires some cryptographic computations, it is recommended that the session keys be derived only once authentication has succeeded (i.e., once the server has successfully verified MAC_P for the server side, and once the peer has successfully verified MAC_S for the peer side).
以来セッションキーを引き出すのはいくつかの暗号の計算を必要として、認証がいったん成功するとだけ(すなわち、サーバが一度首尾よくMAC_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対話以外に、だれにとっても利用可能にしてはいけません。
Bersani & Tschofenig Experimental [Page 50] RFC 4764 EAP-PSK January 2007
[50ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
8.8. Denial-of-Service Resistance
8.8. サービス妨害抵抗
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.
サーバが、暗号の計算をして、或るものがすなわち、16バイトのRAND_Sを生成して、それがEAP-PSKの会話に従事しているときには覚えているように述べると主張しなければならないことに注意する価値があります。 しかしながら、この状態と関連計算がかなり軽量であるときに、これはリソース疲労困憊に通じるべきではありません。
Please note that both the peer and the server must commit to their RAND_S and RAND_P to protect their partners from flooding attacks.
同輩とサーバの両方が、フラッディング攻撃から彼らのパートナーを保護するためにそれらのRAND_SとRAND_Pに公約されなければなりません。
It is recommended that EAP-PSK not allow EAP notifications to be interleaved in its dialog to prevent potential DoS attacks. Indeed, since EAP notifications are not integrity protected, they can easily be spoofed by an attacker. Such an attacker could force a peer that allows EAP notifications to engage in a discussion that would delay his or her authentication or result in the peer taking unexpected actions (e.g., in case a notification is used to prompt the peer to do some "bad" action).
EAP-PSKが、EAP通知が潜在的DoS攻撃を防ぐために対話ではさみ込まれるのを許容しないのは、お勧めです。 本当に、EAP通知が保護された保全でないので、攻撃者は容易にそれらを偽造することができます。 そのような攻撃者はEAP通知を予想外の行動を取る同輩でその人の認証か結果を遅らせる議論に従事させる同輩を強制できました(例えば、通知が同輩が何らかの「悪い」動作をするようにうながすのに使用されるといけないので)。
It is up to the implementation of EAP-PSK or to the peer and the server to specify the maximum number of failed cryptographic checks that are allowed. For instance, does the reception of a bogus MAC_P in the second EAP-PSK message cause a fatal error or is it discarded to continue waiting for the valid response of the valid peer? There is a trade-off between possibly allowing multiple tentative forgeries and allowing a direct DoS (in case the first error is fatal).
許されている失敗した暗号のチェックの最大数を指定するために、EAP-PSKの実装か同輩とサーバにそれはあります。 例えば、2番目のEAP-PSKメッセージにおける、にせのMAC_Pのレセプションは致命的な誤りを引き起こしますか、有効な同輩の有効回答を待ち続けているのが捨てられますか? ことによると複数の一時的な偽造を許して、ダイレクトDoSを許容するとき、トレードオフがあります(最初の誤りが致命的であるといけないので)。
For the sake of simplicity and denial-of-service resilience, EAP-PSK has chosen not to include any error messages. Hence, an "invalid" EAP-PSK message is silently discarded. Although this makes interoperability testing and debugging harder, this leads to simpler implementations and does not open any venue for denial-of-service attacks.
簡単さとサービスの否定弾力のために、EAP-PSKは、どんなエラーメッセージも含んでいないのを選びました。 したがって、「無効」のEAP-PSKメッセージは静かに捨てられます。 相互運用性テストとデバッグをより困難にしますが、これは、より簡単な実装に通じて、サービス不能攻撃のためにどんな開催地も開きません。
8.9. Session Independence
8.9. セッション独立
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の感染を含んでいる)がその後の、または、先のMSKsかEMSKsの感染を可能にしません。
Bersani & Tschofenig Experimental [Page 51] RFC 4764 EAP-PSK January 2007
[51ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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.
一般に、EAP-PSKのセキュリティと特にセッション独立に、RAND_PとRAND_Sが無作為であるという仮定は主要です。
8.10. Exposition of the PSK
8.10. PSKのエキスポ
EAP-PSK does not provide Perfect Forward Secrecy. Compromise of the PSK leads to compromise of recorded past sessions.
EAP-PSKはPerfect Forward Secrecyを提供しません。 妥協する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にそのような保護を提供するかもしれません。 2回のパーティーの間でEAP-PSKによって使用されたPSKを共有するだけでよいです: 同輩とサーバ. 特に、このPSKは同じサーバとコミュニケートする同輩のグループによって共有されてはいけません。
The PSK used by EAP-PSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-PSK may be compromised. It is a rule of thumb in cryptography to use different keys for different applications.
他のプロトコルによって使用されるキーとEAP-PSKによって使用されたPSKを暗号で切り離さなければなりません。さもなければ、EAP-PSKのセキュリティは感染されるかもしれません。 それは異なったアプリケーションに異なったキーを使用する暗号の経験則です。
8.11. Fragmentation
8.11. 断片化
EAP-PSK does not support fragmentation and reassembly.
EAP-PSKは断片化をサポートして、再アセンブリしません。
Indeed, the largest EAP-PSK frame is at most 1015 bytes long, because:
本当に、最も大きいEAP-PSKフレームが高々1015年のバイト長である、:
o The maximum length for the peer NAI identity used in EAP-PSK is
966 bytes (see Section 5.2). This should not be a limitation in
practice (see Section 2.2 of [2] for more considerations on NAI
length).
o EAP-PSKで使用される同輩NAIのアイデンティティのための最大の長さは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_有効搭載量分野への最大の長さは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バイトより大きいペイロードを送るのを必要とする拡張子はそれら自身の断片化と再アセンブリメカニズムを提供するべきです。
Bersani & Tschofenig Experimental [Page 52] RFC 4764 EAP-PSK January 2007
[52ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
8.12. Channel Binding
8.12. チャンネル結合
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を見てください)。
8.13. Fast Reconnect
8.13. 速く再接続してください。
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の中で使用された周遊旅行の数がタイムスタンプかカウンタを使用しないで減少できる方法が全くありません。 タイムスタンプとカウンタは簡単さとセキュリティ(例えば、同期問題)のために故意に避けられました。
8.14. Identity Protection
8.14. アイデンティティ保護
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.
それがシングルをaに制限するために選ばれたので、すなわち、左右対称の暗号からの暗号の基関数、ブロックは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].
将来はアイデンティティ保護の要件の後ろでアイデンティティ保護と原理によって意味されることに関する四角ばらない意見の交換です。 何らかの補足的な議論について、[37]を参照してください。
Identity protection basically means preventing the disclosure of the identities of the communicating parties over the network, which is quite contradictory to authentication. There are two levels of identity protection: protection against passive attackers and protection against active eavesdroppers.
アイデンティティ保護は、認証とかなり相容れないネットワークの上の交信パーティーのアイデンティティの公開を防ぐことを基本的に意味します。 アイデンティティ保護の2つのレベルがあります: 受け身の攻撃者に対する保護と活発な立ち聞きする者に対する保護。
As explained in [37], "a common example [for identity protection] is the case of mobile devices wishing to prevent an attacker from correlating their (changing) location with the logical identity of the device (or user)".
[37]で説明されるように「一般的な例[アイデンティティ保護のための]は攻撃者がデバイスの論理的なアイデンティティでそれらの(変化)位置を関連させるのを防ぎたがっているモバイル機器に関するケース(または、ユーザ)です」。
If only symmetric cryptography is used, only a weak form of identity protection may be offered, namely, pseudonym management. In other words, the peer and the server agree on pseudonyms that they use to
左右対称の暗号だけが使用されている場合にだけ、アイデンティティ保護の弱形が提供されるかもしれないa、すなわち、匿名管理しています。 言い換えれば、同輩とサーバはそれらが使用する匿名で同意します。
Bersani & Tschofenig Experimental [Page 53] RFC 4764 EAP-PSK January 2007
[53ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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").
本当に、時変匿名を使用するプロトコルは匿名" pseudo2@bigco.com "(サーバが" pseudo1@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は何らかの保護を些細なことに提供するかもしれません。 例えば、Wirelessインターネットサービスプロバイダ(WISP)BADによって所有されて、操作されたHot-スポットに歩き回って、接続するユーザジョン・ドウの例を取りましょう。 このユーザが彼の「現実」のアイデンティティ(すなわち、ジョン・ドウ)を回復するために、悪い状態で一握りを許容するアイデンティティ(例えば、" john.doe@wispgood.com ")(または、攻撃者)の下におけるEAPメソッドがある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と同じくらい効率的に同輩を追跡するのに同輩のNetwork Interface CardのMedium Access Control Addressを使用できます。
Bersani & Tschofenig Experimental [Page 54] RFC 4764 EAP-PSK January 2007
[54ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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.
サーバが系統的に攻撃を調べるかもしれないアイデンティティを明らかにすることに注意する価値があります。 サーバのアイデンティティが秘密のままで残るべきでないとき、これは問題でないかもしれません。 これに反して、ユーザは、彼らが付く正しいネットワークを選ぶためにだれと話すかを知りたい傾向があります。
8.15. Protected Ciphersuite Negotiation
8.15. 保護されたCiphersuite交渉
EAP-PSK does not allow negotiating ciphersuites. Hence, it is not vulnerable to negotiation attacks and does not implement protected ciphersuite negotiation.
EAP-PSKはciphersuitesを交渉させません。 したがって、それは、交渉攻撃に被害を受け易くなく、また保護されたciphersuiteが交渉であると実装しません。
8.16. Confidentiality
8.16. 秘密性
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に従ってそうすると主張できません: 「このクレームをするメソッドは、アイデンティティが保護であるとサポートしなければなりません。」
8.17. Cryptographic Binding
8.17. 暗号の結合
Since EAP-PSK is not intended to be tunneled within another protocol that omits peer authentication, it does not implement cryptographic binding.
同輩認証を省略する別のプロトコルの中でEAP-PSKがトンネルを堀られることを意図しないので、それは暗号の結合を実装しません。
8.18. Implementation of EAP-PSK
8.18. 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])。
Bersani & Tschofenig Experimental [Page 55] RFC 4764 EAP-PSK January 2007
[55ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
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のための倉庫の仕様があります。 特に、何も、1枚の紙にそれを暗記されるか、または書き留めるように持っているより1つがスマートカードなどの耐タンパー性デバイスにむしろこのPSKを保存するのを防ぎません。 PSK倉庫の選択には、重要なセキュリティ影響力があるかもしれません。
9. Security Claims
9. セキュリティクレーム
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バイトのPreによって共有されたKey(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)
* 保護されたciphersuite交渉(セクション8.15を見ます)
* Perfect Forward Secrecy (see Section 8.10)
* 完全な前進の秘密保持(セクション8.10を見ます)
Bersani & Tschofenig Experimental [Page 56] RFC 4764 EAP-PSK January 2007
[56ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
* Key agreement: the session key is chosen by the peer (see
Section 8.7)
* 主要な協定: セッションキーは同輩によって選ばれています。(セクション8.7を見ます)
* Channel binding (see Section 8.12)
* チャンネル結合(セクション8.12を見ます)
10. Acknowledgments
10. 承認
This EAP method has been inspired by EAP-Archie and EAP-SIM. Many thanks to their respective authors: Jesse Walker (extra thanks to Jesse Walker for his thorough and challenging expert review of EAP- PSK), Russ Housley, Henry Haverinen, and Joseph Salowey.
このEAP方法はEAP-アーチーとEAP-SIMによって奮い立たせられました。 彼らのそれぞれの作者をありがとうございます: ジェシー・ウォーカー(彼のEAP- PSKの徹底的でやりがいがある専門のレビューのためのジェシー・ウォーカーのおかげで余分な)、ラスHousley、ヘンリーHaverinen、およびジョゼフSalowey。
Thanks to
おかげ
o Henri Gilbert for some interesting discussions on the
cryptographic parts of EAP-PSK.
o 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 頻繁な改良につながった彼のEAP-PSKのネットワーク局面、好奇心、および厳しさの彼の有益なフィードバックと、マイクロソフトWindowsとFreeradiusの下のEAP-PSKの最初の実現における彼のご協力のためのAurelien Magniez。
o Thomas Otto for his valuable feedback on EAP-PSK and the
implementation of the first version of EAP-PSK under Xsupplicant.
o EAP-PSKの彼の有益なフィードバックとXsupplicantの下のEAP-PSKの最初のバージョンの実現のためのトーマス・オットー。
o Nancy Cam-Winget for some exchanges on EAP-PSK.
o EAP-PSKにおけるいくつかの交換のためのナンシーCam-Winget。
o Jari Arkko and Bernard Aboba, the beloved EAP WG chairs, for the
work they stimulate.
o 彼らが刺激する仕事のためのヤリArkkoとバーナードAboba、最愛のEAP WGいす。
Finally, thanks to Vir Z., who has brought a permanent and outstanding though discreet contribution to this protocol.
最終的にVir Z.への感謝。(Virは慎重な貢献ですが、永久的で未払いのaをこのプロトコルに持って来ました)。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
2005年12月の[2]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
Bersani & Tschofenig Experimental [Page 57] RFC 4764 EAP-PSK January 2007
[57ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
[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.ワグナー、「EAX運転モード」FSE04、Springer-Verlag LNCS3017、2004。
[5] Gilbert, H., "The Security of One-Block-to-Many Modes of
Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.
[5] ギルバート、H.、「多くへの1つのブロック運転モードのセキュリティ」、FSE03、追出石-Verlag LNCS2287、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問題部に書くためのガイドライン」BCP26、RFC2434(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がそうするかもしれません。
11.2. Informative References
11.2. 有益な参照
[9] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz,"Extensible
Authentication Protocol (EAP) Key Management Framework", Work
in Progress, October 2006.
[9] B.、サイモン、D.、Eronen、P.、およびH.Levkowetz、「拡張認証プロトコル(EAP)Key Management枠組み」というAbobaは進行中(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.、カルフーン、P.、Glass、S.、ヒラー、T.、マッキャン、P.、Shiino、H.、ゾルン、G.、Dommety、G.、パーキンス、C.、パティル、B.、ミットン、D.、マニング、S.、Beadles、M.、ウォルシュ、P.、チェン、X.、Sivalingham、S.、ハミード、A.、ムンソン、M.、ジェイコブズ、S.、リム、B.、ヒルシュマン、B.、シュー、R.、シュー、Y.、Campell、E.、馬場、S.、およびE.ジャキュース、「仕事AccessのためのEvaluating AAAプロトコルの評価基準」、RFC2989(2000年11月)。
[11] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[11]AbobaとB.とD.サイモン、「ppp EAP TLS認証プロトコル」、RFC2716、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-別名)について議定書の中で述べます」、RFC4187、2006年1月。
[13] Arkko, J. and P. Eronen, "Authenticated Service Information for
the Extensible Authentication Protocol (EAP)", Work in
Progress, October 2005.
[13] 「拡張認証プロトコル(EAP)のための認証されたサービス情報」というArkko、J.、およびP.Eronenは進歩、2005年10月に働いています。
[14] Bellare, M. and P. Rogaway, "Entity Authentication and Key
Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994.
773、[14]Bellare、M.、P.Rogaway、および暗号93の、そして、よりバネのVerlag LNCSの「実体認証と主要な分配」1994。
Bersani & Tschofenig Experimental [Page 58] RFC 4764 EAP-PSK January 2007
[58ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
[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、「認証されたKey Exchange Secure Against Dictionary攻撃」、EUROCRYPT00、Springer-Verlag LNCS1807、2000。
[16] Bersani, F., "EAP shared key methods: a tentative synthesis of
those proposed so far", Work in Progress, April 2004.
[16] ベルサニ、F.、「EAPは主要な方法を共有しました」。 「今までのところ提案されているそれらの一時的な統合」、Progress、2004年4月のWork。
[17] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[17] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[18] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", Work in Progress, July 2001.
[18] カールソン、J.、Aboba、B.、およびH.Haverinen、「EAP SRP-SHA1認証プロトコル」が進歩、2001年7月に働いています。
[19] Department of Defense of the United States, "National
Industrial Security Program Operating Manual", DoD 5220-22M,
January 1995.
[19]合衆国国防総省、「国家の産業保障プログラム操作マニュアル」、DoD5220-22M、1995年1月。
[20] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[20] イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[21] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", Work in Progress, July 2004.
[21] 「EAPはTLS認証プロトコル(EAP-TTLS)にトンネルを堀った」というファンク、P.、およびS.ブレーク-ウィルソンは進歩、2004年7月に働いています。
[22] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[22] ハラー、N.、メス、C.、Nesser、P.、およびM.わら、「A One-時間パスワードシステム」、RFC2289、1998年2月。
[23] Halpern, J. and Y. Moses, "Knowledge and common knowledge in a
distributed environment", Journal of the ACM 37:3, 1990.
[23] アルペルンとJ.とY.モーセ、「分散環境における知識的、そして、一般的な知識」、ACM37:3、1990年のJournal。
[24] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile Communications
(GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186,
January 2006.
[24]Haverinen、H.とJ.Salowey、「汎欧州デジタルセルラーシステム(GSM)加入者アイデンティティモジュール(EAP-SIM)のための拡張認証プロトコル方法」RFC4186(2006年1月)。
[25] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
Standards", RFC 1796, April 1995.
[25]HuitemaとC.とポステル、J.とS.クロッカー、「どんなAll RFCsもStandardsではありません」、RFC1796、1995年4月。
[26] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
[26] 米国電気電子技術者学会、「地方とメトロポリタンエリアネットワーク:」 「ポートベースのネットワークアクセス管理」、IEEEの標準の802.1X、2001年9月。
[27] Institute of Electrical and Electronics Engineers, "Approved
Draft Supplement to Standard for Telecommunications and
Information Exchange Between Systems-LAN/MAN Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications: Specification
for Enhanced Security", IEEE 802.11i-2004, 2004.
[27] 米国電気電子技術者学会、「テレコミュニケーションの規格への承認された草稿補足とシステムLAN/男性決められた一定の要求の間の情報交換--11を分けてください」 無線のLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 「警備の強化のための仕様」、IEEE 802.11i-2004、2004。
Bersani & Tschofenig Experimental [Page 59] RFC 4764 EAP-PSK January 2007
[59ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
[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/男性決められた一定の要求)は11を分けます」。 「無線のLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、IEEE規格802.11、1999。
[29] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03,
Springer-Verlag LNCS 2887, 2003.
[29] 磐田、T.、およびK.黒沢、「OMAC:」 「1主要なCBC MAC」、FSE03、追出石-Verlag LNCS2887、2003。
[30] Jablon, D., "The SPEKE Password-Based Key Agreement Methods",
Work in Progress, November 2002.
[30] D.、「パスワードベースの主要なスピーク協定方法」というJablonは進歩、2002年11月に働いています。
[31] Josefsson, S., "The EAP SecurID(r) Mechanism", Work in
Progress, February 2002.
[31] S.、「EAP SecurID(r)メカニズム」というJosefssonは進歩、2002年2月に働いています。
[32] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[32] Josefsson、S.、Palekar、A.、サイモン、D.、およびG.ゾルン、「保護されたEAPプロトコル(PEAP)バージョン2インチ、進歩、2004年10月に働いてください。」
[33] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[33]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、2000年9月。
[34] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions",
Work in Progress, April 2004.
[34] 「マイクロソフトEAPやつ拡張子」というKamath、V.、およびA.Palekarは進歩、2004年4月に働いています。
[35] Kent, S., "IP Authentication Header", RFC 4302, December 2005
[35] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月
[36] Kocher, P., "Timing Attacks on Implementations of Diffie-
Hellman, RSA, DSS, and Other Systems", CRYPTO 96, Springer-
Verlag LNCS 1109, 1996.
[36] コッハー、P.、「タイミングはディフィー・ヘルマン、RSA、DSS、および他のシステムの実現のときに攻撃します」、追出石Verlag LNCS1109、1996、暗号96。
[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.、「σ:」 「Authenticatedディフィー-ヘルマンとIKEプロトコルのそのUseへの'SIGnとMAc'Approach」、CRYPTO03、Springer-Verlag LNCS2729、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.、2001年9月に無線の、または、<http://www.missl.cs.umd.edu/霊妙な/leap.txt>から利用可能な「コクチマスLEAPプロトコル記述。」
[39] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[39] メス、C.、「OTPは応答を広げた」RFC2243、1997年11月。
[40] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of
Applied Cryptography", CRC Press , 1996.
[40] メネゼスとA.とバンOorschot、P.とS.Vanstone、「適用された暗号のハンドブック」CRC Press、1996。
[41] National Institute of Standards and Technology, "Password
Usage", Federal Information Processing Standards (FIPS) 112,
May 1985.
[41]米国商務省標準技術局(「パスワード用法」、連邦政府の情報処理規格(FIPS)112)は1985がそうするかもしれません。
Bersani & Tschofenig Experimental [Page 60] RFC 4764 EAP-PSK January 2007
[60ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
[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.
Progress(2006年10月)の[42]カム-Winget、N.、マグリュー、D.、Salowey、J.、およびH.周、「Secure Tunneling拡張認証プロトコルMethod(EAP-FAST)を通したFlexible Authentication」Work。
[43] Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of
Microsoft's PPTP Authentication Extensions (MS-CHAPv2)",
CQRE 99, Springer-Verlag LNCS 1740, October 1999.
[43] シュナイアー、B.、マッジ、およびD.ワグナー、「マイクロソフトのPPTP認証拡張子(MS-CHAPv2)の暗号文解読術」、CQRE99、追出石-Verlag LNCS1740、1999年10月。
[44] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[44] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[45] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[45] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[46] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and
F. Bersani, "EAP IKEv2 Method", Work in Progress, October 2006.
[46] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、オオバ、Y.、およびF.ベルサニ、「EAP IKEv2方法」は進歩、2006年10月に働いています。
[47] Walker, J. and R. Housley, "The EAP Archie Protocol", Work in
Progress, June 2003.
[47] 「EAPアーチープロトコル」というウォーカー、J.、およびR.Housleyは進歩、2003年6月に働いています。
[48] Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0",
April 2003.
「Wi-Fi Protected Access、バージョン2インチと、2003年4月」の[48]Wi-Fi Alliance。
[49] Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03,
August 2003.
[49] ライト、J.、「飛躍挑戦/応答における弱点」、Defcon03、2003年8月。
[50] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
Transport Layer Security (TLS)", RFC 4279, December 2005.
[50]EronenとP.とH.Tschofenig、「トランスポート層セキュリティ(TLS)のためのあらかじめ共有された主要なCiphersuites」、RFC4279、2005年12月。
Bersani & Tschofenig Experimental [Page 61] RFC 4764 EAP-PSK January 2007
[61ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
Appendix A. Generation of the PSK from a Password - Discouraged
パスワード--がっかりしているのからのPSKの付録A.世代
It is formally discouraged to use a password to generate the PSK, since this opens the door to exhaustive search or dictionary attacks, two attacks that would not otherwise be possible.
それは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.
すべての可能な16バイトのストリングのセットから16バイトのPSKを無作為に得るときだけ、EAP-PSKは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.
パスワードの2進法表示が厳密に長さ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).
パスワードの2進法表示が厳密に長さ16バイト以上であるなら、それは、マーチャーシュマイヤーOseas細切れ肉料理を使用することでちょうど16バイトまで論じ尽くされます。(この細切れ肉料理の記述のための[40]を参照してください。 [40]の図9.3の記法を使用して、gはアイデンティティ機能です、そして、Eは私たちの構造においてAES-128です。) IV=0x0123456789ABCDEFFEDCBA9876543210(この値は任意に選択された)と共に。
We now assume that we have a 16-byte number derived from the initial password (that can be the password itself if its binary representation is exactly 16 bytes long). We shall call this number P16.
私たちは、現在、初期のパスワードから16バイトの数を得させると思います(それは2進法表示がちょうど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 PとしてのP16
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 Saltとしての同輩とサーバNAIsのXORの最初の96ビット、(高位のビットで無そっと歩く、必要なら)
o 5000 as c
o cとしての5000
o 16 as dkLen
o 16 dkLenとして
Bersani & Tschofenig Experimental [Page 62] RFC 4764 EAP-PSK January 2007
[62ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
Although this gives better protection than nothing, this derivation does not stricto sensu protect against dictionary attacks. It only makes dictionary precomputation harder.
これは無、この派生より良い保護を与えますが、stricto扇子は辞書攻撃から守りませんか? それで、辞書前計算は、より困難になるだけです。
Authors' Addresses
作者のアドレス
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux 92794 Cedex 9 FR
フローランベルサニフランステレコムR&D38、悔悟duルクレールIssyレスMoulineaux92794Cedex9FR司令官
EMail: bersani_florent@yahoo.fr
メール: bersani_florent@yahoo.fr
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich 81739 GE
ハンネスTschofenigジーメンスネットワークGmbHと共同kgオットーハーン一味6ミュンヘン81739GE
EMail: Hannes.Tschofenig@siemens.com
メール: Hannes.Tschofenig@siemens.com
Bersani & Tschofenig Experimental [Page 63] RFC 4764 EAP-PSK January 2007
[63ページ]RFC4764EAP-PSK2007年1月に実験的なベルサニとTschofenig
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bersani & Tschofenig Experimental [Page 64]
ベルサニとTschofenig実験的です。[64ページ]
一覧
スポンサーリンク
