Network Working Group B. Aboba
Request for Comments: 5247 D. Simon
Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen
Nokia
August 2008
Extensible Authentication Protocol (EAP) Key Management Framework
拡張認証プロトコル（EAP）鍵管理フレームワーク
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied.
RFC 3748で定義された拡張認証プロトコル（EAP）は、拡張可能なネットワークアクセス認証を可能にします。この文書では、EAPキー階層を指定し、「方法」として知られているEAP認証アルゴリズムによって生成された材料およびパラメータをキーイングの輸送および使用のためのフレームワークを提供します。また、RFC 4962に記載された鍵管理ガイドラインを満足できる条件を記述する、詳細なシステムレベルのセキュリティ分析を提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................7
1.4. EAP Key Hierarchy .........................................10
1.5. Security Goals ............................................15
1.6. EAP Invariants ............................................16
2. Lower-Layer Operation ..........................................20
2.1. Transient Session Keys ....................................20
2.2. Authenticator and Peer Architecture .......................22
2.3. Authenticator Identification ..............................23
2.4. Peer Identification .......................................27
2.5. Server Identification .....................................29
3. Security Association Management ................................31
3.1. Secure Association Protocol ...............................32
3.2. Key Scope .................................................35
3.3. Parent-Child Relationships ................................35
3.4. Local Key Lifetimes .......................................37
3.5. Exported and Calculated Key Lifetimes .....................37
3.6. Key Cache Synchronization .................................40
3.7. Key Strength ..............................................40
3.8. Key Wrap ..................................................41
4. Handoff Vulnerabilities ........................................41
4.1. EAP Pre-Authentication ....................................43
4.2. Proactive Key Distribution ................................44
4.3. AAA Bypass ................................................46
5. Security Considerations ........................................50
5.1. Peer and Authenticator Compromise .........................51
5.2. Cryptographic Negotiation .................................53
5.3. Confidentiality and Authentication ........................54
5.4. Key Binding ...............................................59
5.5. Authorization .............................................60
5.6. Replay Protection .........................................63
5.7. Key Freshness .............................................64
5.8. Key Scope Limitation ......................................66
5.9. Key Naming ................................................66
5.10. Denial-of-Service Attacks ................................67
6. References .....................................................68
6.1. Normative References ......................................68
6.2. Informative References ....................................68
Acknowledgments ...................................................74
Appendix A - Exported Parameters in Existing Methods ..............75
The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the Internet Protocol (IP) protocol is not available. Originally developed for use with Point-to-Point Protocol (PPP) [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE-802.1X], Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], and wireless networks such as [IEEE-802.11] and [IEEE-802.16e].
[RFC3748]で定義された拡張認証プロトコル（EAP）は、インターネットプロトコル（IP）プロトコルが利用できない状況において、ネットワークアクセスのための拡張可能な認証を可能にするように設計しました。もともとポイントツーポイントプロトコル（PPP）[RFC1661]で使用するために開発され、それはその後もIEEE 802の有線ネットワーク[IEEE-802.1X]、インターネット鍵交換プロトコルバージョン2（IKEv2の）[RFC4306]に適用される、とされてきましたこのような[IEEE-802.11]と[IEEE-802.16eの]のような無線ネットワーク。
EAP is a two-party protocol spoken between the EAP peer and server. Within EAP, keying material is generated by EAP authentication algorithms, known as "methods". Part of this keying material can be used by EAP methods themselves, and part of this material can be exported. In addition to the export of keying material, EAP methods can also export associated parameters such as authenticated peer and server identities and a unique EAP conversation identifier, and can import and export lower-layer parameters known as "channel binding parameters", or simply "channel bindings".
EAPは、EAPピアとサーバ間の話2パーティプロトコルです。 EAP内、キーイング材料を「方法」として知られているEAP認証アルゴリズムによって生成されます。この鍵材料の一部は自身のEAP方式で使用することができ、そしてこの材料の一部をエクスポートすることができます。鍵材料の輸出に加えて、EAPメソッド」は、単に、そのような認証ピアとサーバアイデンティティ及び一意のEAPの会話識別子としての関連するパラメータをエクスポートすることができ、およびインポートすることができ、輸出「チャネル結合パラメータ」として知られている下層のパラメータを、またはチャネルバインディング」。
This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP methods. It also provides a detailed security analysis, describing the conditions under which the requirements described in "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" [RFC4962] can be satisfied.
この文書では、EAPキー階層を指定し、材料およびEAPメソッドによって生成されたパラメータをキーイングの輸送および使用のためのフレームワークを提供します。また、[RFC4962]「認証、許可、アカウンティング（AAA）キー管理のための指針」に記載されている要件を満たすことができる条件を記述し、詳細なセキュリティ分析を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The terms "Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and are used with the same meaning in this document, which also frequently uses the following terms:
「暗号が結合」という用語は、「暗号化分離」、「キー強度」と「相互認証」[RFC3748]で定義されているとも頻繁に次の用語を使用してこのドキュメントに記載されているのと同じ意味で使用されています。
4-Way Handshake A pairwise Authentication and Key Management Protocol (AKMP) defined in [IEEE-802.11], which confirms mutual possession of a Pairwise Master Key by two parties and distributes a Group Key.
で定義された4ウェイハンドシェイクペアワイズ認証および鍵管理プロトコル（AKMP）両当事者によってペアワイズマスターキーの相互所有を確認し、グループ鍵を配布[IEEE-802.11]。
AAA Authentication, Authorization, and Accounting AAA protocols with EAP support include "RADIUS Support for EAP" [RFC3579] and "Diameter EAP Application" [RFC4072]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably.
EAPをサポートしてAAA認証、許可、アカウンティングAAAプロトコルは、 "EAPのためのRADIUSサポート" [RFC3579]及び "直径EAPアプリケーション" [RFC4072]を含みます。この文書では、用語「AAAサーバ」と「バックエンド認証サーバ」は互換的に使用されています。
AAA-Key The term AAA-Key is synonymous with Master Session Key (MSK). Since multiple keys can be transported by AAA, the term is potentially confusing and is not used in this document.
AAAキー用語AAAキーは、マスターセッションキー（MSK）と同義です。複数のキーは、AAAによって搬送することができるので、この用語は、潜在的に混乱して、この文書で使用されていません。
Authenticator The entity initiating EAP authentication.
EAP認証を開始するエンティティをオーセンティケータ。
Backend Authentication Server A backend authentication server is 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 [IEEE-802.1X].
バックエンド認証サーバのバックエンド認証サーバは、オーセンティケータに認証サービスを提供するエンティティです。使用する場合、このサーバーは、通常、認証のためのEAPメソッドを実行します。この用語はまた、[IEEE-802.1X]に使用されています。
Channel Binding A secure mechanism for ensuring that a subset of the parameters transmitted by the authenticator (such as authenticator identifiers and properties) are agreed upon by the EAP peer and server. It is expected that the parameters are also securely agreed upon by the EAP peer and authenticator via the lower layer if the authenticator advertised the parameters.
（例えば、オーセンティケータ識別子およびプロパティなど）、オーセンティケータによって送信されたパラメータのサブセットは、EAPピアとサーバ間で合意されていることを保証するための安全なメカニズムを結合チャネル。オーセンティケータは、パラメータをアドバタイズした場合のパラメータも確実に下位層を介してEAPピアとオーセンティケータによって合意されていることが予想されます。
Derived Keying Material Keys derived from EAP keying material, such as Transient Session Keys (TSKs).
そのようなトランジエントセッション鍵（TSKs）としてEAPキーイングマテリアルから誘導される派生鍵材料キー、。
EAP Keying Material Keys derived by an EAP method; this includes exported keying material (MSK, Extended MSK (EMSK), Initialization Vector (IV)) as well as local keying material such as Transient EAP Keys (TEKs).
EAPメソッドによって誘導されるEAPキーイングマテリアルキー。これは、（MSK（EMSK）拡張MSK、初期化ベクトル（IV））エクスポート鍵材料、ならびにそのような過渡EAPキー（のTEK）などのローカルキーイング材料を含みます。
EAP Pre-Authentication The use of EAP to pre-establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator.
EAP事前認証の前、その認証者が管理するアクセスネットワークにおけるピアの到着にオーセンティケータにEAPキーイング材料を事前に確立するEAPの使用。
EAP Re-Authentication EAP authentication between an EAP peer and a server with whom the EAP peer shares valid unexpired EAP keying material.
EAPピアとEAPピア株式有効期限が切れていないEAPキーイング材料とサーバ間のEAP再認証EAP認証。
EAP Server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server.
EAPサーバピアとEAP認証方式を終了するエンティティ。いかなるバックエンド認証サーバが使用されない場合には、EAPサーバは、オーセンティケータの一部です。オーセンティケータがパススルー・モードで動作する場合、EAPサーバはバックエンド認証サーバに配置されています。
Exported Keying Material The EAP Master Session Key (MSK), Extended Master Session Key (EMSK), and Initialization Vector (IV).
エクスポートされた鍵材料ザ・EAPマスターセッションキー（MSK）、拡張マスターセッションキー（EMSK）、および初期化ベクトル（IV）。
Extended Master Session Key (EMSK) Additional keying material derived between the peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length and is never shared with a third party. The EMSK MUST be at least as long as the MSK in size.
EAP方式によってエクスポートされたピアとサーバ間の派生拡張マスターセッションキー（EMSK）の追加鍵素材。 EMSKは、長さが少なくとも64オクテットであると第三者と共有されることはありません。 EMSKのサイズはMSKと少なくとも同じ長さでなければなりません。
Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in methods such as EAP-TLS (Transport Layer Security) [RFC5216], 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 it is OPTIONAL for EAP methods to generate it. However, when it is generated, it MUST be unpredictable.
初期化ベクトル（IV）ピアとEAPサーバとの間に誘導される初期化ベクトルフィールドでの使用に適した、少なくとも64オクテットの量、。 IVは、EAP-TLS（トランスポート層セキュリティ）[RFC5216]のような方法で既知の値であるので、それが秘密のままにする必要がある任意の量の計算のために単独で使用することができません。その結果、その使用は推奨されていませんし、EAPメソッドは、それを生成することは任意です。それが発生した場合しかし、それは予測不可能でなければなりません。
Keying Material Unless otherwise qualified, the term "keying material" refers to EAP keying material as well as derived keying material.
鍵材料は、そうでない場合は資格のない限り、用語「鍵材料は、」派生鍵素材だけでなく、EAPキーイング材料を意味します。
Key Scope The parties to whom a key is available.
主な適用範囲当事者が鍵を誰にも利用できます。
Key Wrap The encryption of one symmetric cryptographic key in another. The algorithm used for the encryption is called a key wrap algorithm or a key encryption algorithm. The key used in the encryption process is called a key-encryption key (KEK).
キーは、別の1つの対称暗号化キーの暗号化を包みます。暗号化に使用されるアルゴリズムは、キーラップアルゴリズムや鍵暗号化アルゴリズムと呼ばれています。暗号化プロセスで使用されるキーは、キー暗号化キー（KEK）と呼ばれています。
Long-Term Credential EAP methods frequently make use of long-term secrets in order to enable authentication between the peer and server. In the case of a method based on pre-shared key authentication, the long-term credential is the pre-shared key. In the case of a public-key-based method, the long-term credential is the corresponding private key.
長期資格EAPメソッドは、頻繁にピアとサーバ間の認証を有効にするために、長期的な秘密を利用します。事前共有鍵の認証に基づく方法の場合には、長期資格情報は、事前共有鍵です。公開鍵ベースの方法の場合には、長期的な資格は、対応する秘密鍵です。
Lower Layer The lower layer is responsible for carrying EAP frames between the peer and authenticator.
下層、下層は、ピアとオーセンティケータとの間でEAPフレームを運ぶための責任があります。
Lower-Layer Identity A name used to identify the EAP peer and authenticator within the lower layer.
下層アイデンティティ下層内EAPピアとオーセンティケータを識別するために使用される名前。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length.
EAPピアとサーバとの間で導出され、EAPメソッドによってエクスポートされるマスタセッションキー（MSK）キーイング材料。 MSKは、長さが少なくとも64オクテットです。
Network Access Server (NAS) A device that provides an access service for a user to a network.
ネットワークアクセスサーバ（NAS）ネットワークへのユーザのアクセスサービスを提供する装置。
Pairwise Master Key (PMK) Lower layers use the MSK in a lower-layer dependent manner. For instance, in IEEE 802.11 [IEEE-802.11], Octets 0-31 of the MSK are known as the Pairwise Master Key (PMK); the Temporal Key Integrity Protocol (TKIP) and Advanced Encryption Standard Counter Mode with CBC-MAC Protocol (AES CCMP) ciphersuites derive their Transient Session Keys (TSKs) solely from the PMK, whereas the Wired Equivalent Privacy (WEP) ciphersuite, as noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], derives its TSKs from both halves of the MSK. In [IEEE-802.16e], the MSK is truncated to 20 octets for PMK and 20 octets for PMK2.
ペアワイズマスターキー（PMK）下位層は、下層依存的にMSKを使用します。例えば、IEEE 802.11 [IEEE-802.11]で、MSKのオクテット0-31は、ペアワイズマスターキー（PMK）として知られています。 CBC-MACプロトコル（AES CCMP）とTKIP（Temporal Key Integrity Protocol）がと高度暗号化標準カウンタモードは暗号スイートは、WEP（Wired Equivalent Privacy）暗号スイートのに対し、で述べたように、もっぱらPMKからの一時セッション鍵（TSKs）を導出します[RFC3580] "IEEE 802.1X RADIUS使用上の注意事項"、MSKの両半分からそのTSKsを導出します。 [IEEE-802.16eの】において、MSKは、PMK 20オクテットとPMK2 20個のオクテットに切り詰められます。
Peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the Supplicant.
オーセンティケータに応答エンティティをピア。 [IEEE-802.1X]では、このエンティティは、サプリカントとして知られています。
Security Association A set of policies and cryptographic state used to protect information. Elements of a security association include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc.
セキュリティアソシエーションポリシーと暗号化状態のセットは、情報を保護するために使用しました。セキュリティアソシエーションの要素は、暗号化キー、交渉し暗号群およびその他のパラメータ、カウンタ、数列空間、許可属性などが含まれます
Secure Association Protocol An exchange that occurs between the EAP peer and authenticator in order to manage security associations derived from EAP exchanges. The protocol establishes unicast and (optionally) multicast security associations, which include symmetric keys and a context for the use of the keys. An example of a Secure Association Protocol is the 4-way handshake defined within [IEEE-802.11].
アソシエーションプロトコルをEAP交換に由来するセキュリティアソシエーションを管理するためにEAPピアとオーセンティケータとの間に生じる交換を確保します。プロトコルは、ユニキャストおよび対称鍵と鍵の使用のためのコンテキストを含む（任意で）マルチキャストセキュリティアソシエーションを確立します。セキュアアソシエーションプロトコルの例は、[IEEE-802.11]内で定義された4ウェイハンドシェイクです。
Session-Id The EAP Session-Id uniquely identifies an EAP authentication exchange between an EAP peer (as identified by the Peer-Id(s)) and server (as identified by the Server-Id(s)). For more information, see Section 1.4.
セッションIDザEAPセッションIDは、EAPピア（ピアID（複数可）によって識別される）と、（サーバID（複数可）によって識別される）サーバとの間のEAP認証交換を識別する。詳細については、セクション1.4を参照してください。
Transient EAP Keys (TEKs) Session keys that are used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. The TEKs are stored locally by the EAP method and are not exported. 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.
過渡EAPキー（のTEK）EAP認証交換中にEAPピアとサーバ間の保護されたチャネルを確立するために使用されるセッション鍵。 TEKは、EAPの会話を保護する際に使用するためEAPピアとサーバ間でネゴシエート暗号スイートでの使用に適しています。 TEKは、EAPメソッドによってローカルに保存され、エクスポートされません。 EAP認証時にEAPピアとサーバ間の保護されたチャネルをセットアップするために使用される暗号スイートは、その後EAPピアとオーセンティケータとの間で送信されるデータを保護するために使用される暗号スイートとは無関係であることに留意されたいです。
Transient Session Keys (TSKs) Keys used to protect data exchanged after EAP authentication has successfully completed using the ciphersuite negotiated between the EAP peer and authenticator.
EAP認証が成功したEAPピアとオーセンティケータの間で交渉暗号スイートを使用して完了した後に一時的なセッション鍵（TSKs）のデータを保護するために使用されるキーには、交換しました。
Where EAP key derivation is supported, the conversation typically takes place in three phases:
EAP鍵導出がサポートされている場合、会話は一般的に3つのフェーズで行われます。
Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication 1b: AAA Key Transport (optional) Phase 2: Secure Association Protocol 2a: Unicast Secure Association 2b: Multicast Secure Association (optional)
位相0：発見フェーズ1：認証1A：EAP認証1B：AAAキートランスポート（オプション）フェーズ2：セキュアアソシエーションプロトコル2A：ユニキャストセキュアアソシエーション2bは：アソシエーションをセキュアマルチキャスト（オプション）
Of these phases, phase 0, 1b, and 2 are handled external to EAP. phases 0 and 2 are handled by the lower-layer protocol, and phase 1b is typically handled by a AAA protocol.
これらの相の、位相0、1B、及び2はEAPの外部に処理されます。フェーズ0及び2は、下位層プロトコルによって処理され、位相1bは、典型的にはAAAプロトコルによって処理されます。
In the discovery phase (phase 0), peers locate authenticators and discover their capabilities. A peer can locate an authenticator providing access to a particular network, or a peer can locate an authenticator behind a bridge with which it desires to establish a Secure Association. Discovery can occur manually or automatically, depending on the lower layer over which EAP runs.
発見フェーズ（フェーズ0）では、ピアは認証子を見つけて、自分の能力を発見します。ピアは、特定のネットワークへのアクセスを提供する認証手段を見つけることができ、またはピアは、セキュア・アソシエーションを確立するために希望すると、ブリッジの背後にオーセンティケータを見つけることができます。発見は、EAPを実行する上、下部層に応じて、手動または自動的に発生することができます。
The authentication phase (phase 1) can begin once the peer and authenticator discover each other. This phase, if it occurs, always includes EAP authentication (phase 1a). Where the chosen EAP method supports key derivation, in phase 1a, EAP keying material is derived on both the peer and the EAP server.
ピア及びオーセンティケータが互いを発見したら、認証フェーズ（フェーズ1）を開始することができます。このフェーズでは、それが発生した場合、常にEAP認証（フェーズ1a）を含んでいます。選択されたEAPメソッドがキー導出をサポートする場合、位相1aに、EAPキーイングマテリアルは、ピアとEAPサーバの両方に導出されます。
An additional step (phase 1b) is needed in deployments that include a backend authentication server, in order to transport keying material from the backend authentication server to the authenticator. In order to obey the principle of mode independence (see Section 1.6.1), where a backend authentication server is present, all keying material needed by the lower layer is transported from the EAP server to the authenticator. Since existing TSK derivation and transport techniques depend solely on the MSK, in existing implementations, this is the only keying material replicated in the AAA key transport phase 1b.
追加のステップ（フェーズ1bは）オーセンティケータにバックエンド認証サーバからの鍵材料を輸送するために、バックエンド認証サーバを含む展開に必要とされます。モードの独立性の原理に従うために、バックエンド認証サーバは、下位層が必要とするすべての鍵材料は、オーセンティケータにEAPサーバから搬送されて存在する、（セクション1.6.1を参照）。既存のTSKの導出及び輸送技術は、MSKにのみ依存するので、既存の実装では、これはAAAキー搬送位相1bに複製のみキーイング材料です。
Successful completion of EAP authentication and key derivation by a peer and EAP server does not necessarily imply that the peer is committed to joining the network associated with an EAP server. Rather, this commitment is implied by the creation of a security association between the EAP peer and authenticator, as part of the Secure Association Protocol (phase 2). The Secure Association Protocol exchange (phase 2) occurs between the peer and authenticator in order to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations between the peer and authenticator. The conversation between the parties is shown in Figure 1.
ピアとEAPサーバによるEAP認証と鍵導出の正常終了は必ずしもピアがEAPサーバに関連付けられているネットワークに参加することを約束していることを意味するものではありません。むしろ、この取り組みは、セキュアアソシエーションプロトコル（フェーズ2）の一部として、EAPピアとオーセンティケータとの間のセキュリティアソシエーションの作成によって暗示されています。セキュアアソシエーションプロトコル交換（フェーズ2）は、ユニキャスト（フェーズ2a）及びマルチキャスト（位相2B）ピアとオーセンティケータとの間のセキュリティアソシエーションの作成および削除を管理するために、ピアとオーセンティケータとの間で発生します。当事者間の会話は、図1に示されています。
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
Figure 1: Conversation Overview
図1：会話の概要
Existing EAP lower layers implement phase 0, 2a, and 2b in different ways:
既存のEAP下位層は、様々な方法で位相0、図2a、及び図2bを実装します。
PPP The Point-to-Point Protocol (PPP), defined in [RFC1661], does not support discovery, nor does it include a Secure Association Protocol.
[RFC1661]で定義されたPPPザポイントツーポイントプロトコル（PPP）は、発見をサポートしていません。また、セキュリティで保護協会プロトコルが含まれません。
PPPoE PPP over Ethernet (PPPoE), defined in [RFC2516], includes support for a Discovery stage (phase 0). In this step, the EAP peer sends a PPPoE Active Discovery Initiation (PADI) packet to the broadcast address, indicating the service it is requesting. The Access Concentrator replies with a PPPoE Active Discovery Offer (PADO) packet containing its name, the service name, and an indication of the services offered by the concentrator. The discovery phase is not secured. PPPoE, like PPP, does not include a Secure Association Protocol.
[RFC2516]で定義されたイーサネット（登録商標）上のPPPoE PPP（PPPoEは）、ディスカバリステージ（位相0）のサポートを含みます。このステップでは、EAPピアは、それが要求しているサービスを示す、ブロードキャストアドレスへのPPPoEアクティブディスカバリーイニシエーション（PADI）パケットを送信します。アクセスコンセントレータは、その名前、サービス名、およびコンセントレータが提供するサービスの表示を含むのPPPoEアクティブディスカバリーオファー（PADO）パケットで応答します。発見フェーズが確保されていません。 PPPoEは、PPPのように、セキュアな協会プロトコルが含まれていません。
IKEv2 Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes support for EAP and handles the establishment of unicast security associations (phase 2a). However, the establishment of multicast security associations (phase 2b) typically does not involve EAP and needs to be handled by a group key management protocol such as Group Domain of Interpretation (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], Multimedia Internet KEYing (MIKEY) [RFC3830], or Group Key Distribution Protocol (GKDP) [GKDP]. Several mechanisms have been proposed for the discovery of IPsec security gateways. [RFC2230] discusses the use of Key eXchange (KX) Resource Records (RRs) for IPsec gateway discovery; while KX RRs are supported by many Domain Name Service (DNS) server implementations, they have not yet been widely deployed. Alternatively, DNS SRV RRs [RFC2782] can be used for this purpose. Where DNS is used for gateway location, DNS security mechanisms such as DNS Security (DNSSEC) ([RFC4033], [RFC4035]), TSIG [RFC2845], and Simple Secure Dynamic Update [RFC3007] are available.
[RFC4306]で定義のIKEv2インターネットキー交換V2（のIKEv2）は、EAPのサポートを含み、ユニキャストセキュリティアソシエーション（フェーズ2a）の確立を取り扱います。しかし、マルチキャストのセキュリティアソシエーションの確立は（フェーズ2b）は、通常、EAPを伴い、そのような解釈のグループドメイン（GDOI）[RFC3547]、グループセキュア協会鍵管理プロトコル（GSAKMP）としてグループ鍵管理プロトコルによって処理される必要がありません[RFC4535]、マルチメディアインターネットキーイング（MIKEY）[RFC3830]、またはグループ鍵配布プロトコル（GKDP）[GKDP]。いくつかのメカニズムは、IPsecセキュリティゲートウェイの発見のために提案されています。 [RFC2230]はIPsecゲートウェイの発見のための鍵交換（KX）リソースレコード（RR）の使用について説明します。 KXのRRのは、多くのドメインネームサービス（DNS）サーバーの実装によってサポートされている間、彼らはまだ広く展開されていません。あるいは、DNS SRVのRR [RFC2782]は、この目的のために使用することができます。 DNSは、ゲートウェイの場所に使用される場合、そのようなDNSセキュリティ（DNSSEC）（[RFC4033]、[RFC4035]）、TSIG [RFC2845]、および単純セキュア動的更新[RFC3007]としてDNSセキュリティメカニズムが利用可能です。
IEEE 802.11 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the Beacon and Probe Request/Response mechanisms. IEEE 802.11 Access Points (APs) periodically announce their Service Set Identifiers (SSIDs) as well as capabilities using Beacon frames. Stations can query for APs by sending a Probe Request. Neither Beacon nor Probe Request/Response frames are secured. The 4-way handshake defined in [IEEE-802.11] enables the derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) secure associations. Since the group key exchange transports a group key from the AP to the station, two 4-way handshakes can be needed in order to support peer-to-peer communications. A proof of the security of the IEEE 802.11 4-way handshake, when used with EAP-TLS, is provided in [He].
[IEEE-802.11]で定義されたIEEE 802.11 IEEE 802.11は、ビーコンおよびプローブ要求/応答機構を介して発見を扱います。 IEEE 802.11アクセスポイント（AP）は、定期的にビーコンフレームを使用してのService Set Identifier（SSIDの）だけでなく、機能を発表します。ステーションは、プローブ要求を送信することにより、APを問い合わせることができます。ビーコンやプローブのいずれもリクエスト/レスポンスフレームが固定されています。 [IEEE-802.11]で定義された4ウェイハンドシェイクは、ユニキャストの導出（フェーズ2a）およびマルチキャスト/ブロードキャスト（位相2B）セキュアな関連付けを可能にします。グループ鍵交換はステーションにAPからグループ鍵を搬送するため、2つの4ウェイハンドシェイクは、ピア・ツー・ピア通信をサポートするために必要とされることができます。 IEEE 802.11 4ウェイハンドシェイクのセキュリティの証明は、EAP-TLSで使用される場合、[彼]で提供されます。
IEEE 802.1X IEEE 802.1X-2004, defined in [IEEE-802.1X], does not support discovery (phase 0), nor does it provide for derivation of unicast or multicast secure associations.
[IEEE-802.1X]で定義されたIEEE 802.1X IEEE 802.1X-2004は、発見（位相0）をサポートしません。また、ユニキャストまたはマルチキャストの安全な関連付けの導出を提供ありません。
As illustrated in Figure 2, the EAP method key derivation has, at the root, the long-term credential utilized by the selected EAP method. If authentication is based on a pre-shared key, the parties store the EAP method to be used and the pre-shared key. The EAP server also stores the peer's identity as well as additional information. This information is typically used outside of the EAP method to determine whether to grant access to a service. The peer stores information necessary to choose which secret to use for which service.
図2に示すように、EAPメソッドキー導出は、ルートに、選択されたEAPメソッドによって利用長期資格を有しています。認証は事前共有キーに基づいている場合、当事者は、使用するEAP方式と事前共有鍵を格納します。 EAPサーバは、ピアの識別情報などの追加情報を格納します。この情報は、典型的には、サービスへのアクセスを許可するかどうかを決定するためにEAPメソッドの外で使用されています。ピアは、どのサービスに使用する秘密を選択するために必要な情報を格納します。
If authentication is based on proof of possession of the private key corresponding to the public key contained within a certificate, the parties store the EAP method to be used and the trust anchors used to validate the certificates. The EAP server also stores the peer's identity, and the peer stores information necessary to choose which certificate to use for which service. Based on the long-term credential established between the peer and the server, methods derive two types of EAP keying material:
認証が証明書に含まれる公開鍵に対応する秘密鍵を所有していることの証明に基づいている場合、当事者は、使用するEAP方式と証明書を検証するために使用トラストアンカーを格納します。 EAPサーバは、ピアの識別情報を格納し、そのサービスのために使用する証明書を選択するために必要なピア情報を格納します。ピアとサーバの間で確立長期資格情報に基づいて、方法はEAPキーイングマテリアルの2種類を導き出します：
(a) Keying material calculated locally by the EAP method but not exported, such as the Transient EAP Keys (TEKs).
（a）は、EAPメソッドによってローカルで計算材料を合わせるが、このような過渡EAPキー（のTEK）として、エクスポートされません。
(b) Keying material exported by the EAP method: Master Session Key (MSK), Extended Master Session Key (EMSK), Initialization Vector (IV).
EAP方式によってエクスポート（b）のキーイング材料：マスターセッションキー（MSK）、拡張マスターセッションキー（EMSK）、初期化ベクトル（IV）。
As noted in [RFC3748] Section 7.10:
[RFC3748]セクション7.10に述べたように：
In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets.
その後に交渉暗号スイートで使用するための鍵材料を提供するために、鍵導出をサポートするEAP方式は、少なくとも64オクテットの少なくとも64オクテットのマスターセッションキー（MSK）、および拡張マスターセッションキー（EMSK）をエクスポートする必要があります。
EAP methods also MAY export the IV; however, the use of the IV is deprecated. The EMSK MUST NOT be provided to an entity outside the EAP server or peer, nor is it permitted to pass any quantity to an entity outside the EAP server or peer from which the EMSK could be computed without breaking some cryptographic assumption, such as inverting a one-way function.
EAP方法もIVをエクスポートできます。しかし、IVの使用が推奨されていません。 EMSKはEAPサーバまたはピア外部エンティティに提供してはいけません、またそれは、反転として、EMSKは、いくつかの暗号化の仮定を破ることなく計算することができ、そこからEAPサーバまたはピア外部エンティティに任意の量を通過することが許可され一方向関数。
EAP methods supporting key derivation and mutual authentication SHOULD export a method-specific EAP conversation identifier known as the Session-Id, as well as one or more method-specific peer identifiers (Peer-Id(s)) and MAY export one or more method-specific server identifiers (Server-Id(s)). EAP methods MAY also support the import and export of channel binding parameters. EAP method specifications developed after the publication of this document MUST define the Peer-Id, Server-Id, and Session-Id. The Peer-Id(s) and Server-Id(s), when provided, identify the entities involved in generating EAP keying material. For existing EAP methods, the Peer-Id, Server-Id, and Session-Id are defined in Appendix A.
セッションIdとして知られている方法に固有のEAP会話識別子をエクスポートする必要があり、鍵導出および相互認証をサポートするEAPメソッド、ならびに1つまたは複数の方法、特定のピアの識別子（ピアID（S））と1つ以上の方法をエクスポートでき固有のサーバ識別子（サーバID（S））。 EAPメソッドもパラメータを結合チャネルのインポートおよびエクスポートをサポートするかもしれません。このドキュメントの発行後に開発EAPメソッドの仕様は、ピアID、サーバーID、およびセッションIDを定義する必要があります。提供される場合ピアID（複数可）及びサーバID（複数可）は、EAPキーイングマテリアルの生成に関与するエンティティを識別する。既存のEAPメソッドのために、ピアID、サーバーID、およびセッションIdは、付録Aで定義されています
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| | | | Exported |
| Peer-Id(s), | channel | MSK (64+B) | IV (64B) by |
| Server-Id(s), | bindings | EMSK (64+B) | (Optional) EAP |
| Session-Id | & Result | | Method |
V V V V V
Figure 2: EAP Method Parameter Import/Export
図2：EAPメソッドのパラメータのインポート/エクスポート
Peer-Id
ピアID
If an EAP method that generates keys authenticates one or more method-specific peer identities, those identities are exported by the method as the Peer-Id(s). It is possible for more than one Peer-Id to be exported by an EAP method. Not all EAP methods provide a method-specific peer identity; where this is not defined, the Peer-Id is the null string. In EAP methods that do not support key generation, the Peer-Id MUST be the null string. Where an EAP method that derives keys does not provide a Peer-Id, the EAP server will not authenticate the identity of the EAP peer with which it derived keying material.
キーを生成するEAPメソッドは、1つ以上の方法、特定のピアのアイデンティティを認証する場合、それらの同一性は、ピアID（複数可）等の方法によってエクスポートされます。複数のピアIDは、EAPメソッドによってエクスポートすることが可能です。すべてのEAPメソッドは、メソッド固有のピアのアイデンティティを提供していません。これが定義されていない場合は、ピアIDはヌル文字列です。鍵の生成をサポートしていないEAP方式では、ピアIDはヌル文字列でなければなりません。鍵を導出EAP方式は、ピアIDを提供しない場合は、EAPサーバは、それが材料をキーイング導き出されるEAPピアの識別情報を認証しません。
Server-Id
サーバID
If an EAP method that generates keys authenticates one or more method-specific server identities, those identities are exported by the method as the Server-Id(s). It is possible for more than one Server-Id to be exported by an EAP method. Not all EAP methods provide a method-specific server identity; where this is not defined, the Server-Id is the null string. If the EAP method does not generate keying material, the Server-Id MUST be the null string. Where an EAP method that derives keys does not provide a Server-Id, the EAP peer will not authenticate the identity of the EAP server with which it derived EAP keying material.
キーを生成するEAPメソッドは、1つ以上の方法、特定のサーバのアイデンティティを認証する場合、それらのIDは、サーバID（複数可）等の方法によってエクスポートされます。複数のサーバー-IdがEAPメソッドによってエクスポートされることが可能です。すべてのEAPメソッドは、メソッド固有のサーバーIDを提供しません。これが定義されていない場合は、サーバー-Idはヌル文字列です。 EAPメソッドが鍵材料を生成しない場合は、サーバー-Idはヌル文字列でなければなりません。鍵を導出EAPメソッドはサーバIDを提供しない場合は、EAPピアは、それがEAPキーイング材料を得たとEAPサーバのIDを認証しません。
Session-Id
セッションID
The Session-Id uniquely identifies an EAP session between an EAP peer (as identified by the Peer-Id) and server (as identified by the Server-Id). Where non-expanded EAP Type Codes are used (EAP Type Code not equal to 254), the EAP Session-Id is the concatenation of the single octet EAP Type Code and a temporally unique identifier obtained from the method (known as the Method-Id):
セッションIDは、EAPピア（ピアIDによって識別される）と、（サーバIDによって識別される）サーバとの間のEAPセッションを識別する。ここで、非拡張EAPタイプコードは、（EAPタイプコードは254に等しくない）に使用される、EAPセッションIdは、メソッドIDとして知られている（単一オクテットEAPタイプコードの連結及び方法から得られた時間的に一意な識別子であります）：
Session-Id = Type-Code || Method-Id
セッションId =タイプコード||この方法-ID
Where expanded EAP Type Codes are used, the EAP Session-Id consists of the Expanded Type Code (including the Type, Vendor-Id (in network byte order) and Vendor-Type fields (in network byte order) defined in [RFC3748] Section 5.7), concatenated with a temporally unique identifier obtained from the method (Method-Id):
拡張EAPタイプコードが使用される場合、EAPセッションIdは、[RFC3748]セクションで定義された拡張ネットワークバイト順に入力し、ベンダーID（を含むタイプコード（）とネットワークバイト順にベンダータイプフィールド（）で構成されてい5.7）、方法（方法-ID）から得られた時間的に一意の識別子と連結。
Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id
セッションId = 0xFEの||ベンダーID ||ベンダータイプ||この方法-ID
The Method-Id is typically constructed from nonces or counters used within the EAP method exchange. The inclusion of the Type Code or Expanded Type Code in the EAP Session-Id ensures that each EAP method has a distinct Session-Id space. Since an EAP session is not bound to a particular authenticator or specific ports on the peer and authenticator, the authenticator port or identity are not included in the Session-Id.
方法-IDは、典型的には、EAPメソッド交換内で使用されるナンスまたはカウンタから構成されています。 EAPセッションIDを入力コードまたは拡張タイプコードを含めることは、各EAPメソッドが異なるセッションID空間を有することを保証します。 EAPセッションが特定のオーセンティケータ又はピアとオーセンティケータ上の特定のポートにバインドされていないので、オーセンティケータポートまたは同一性は、セッションIdに含まれていません。
Channel Binding
チャネルバインディング
Channel binding is the process by which lower-layer parameters are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport channel binding parameters MUST treat this data as opaque octets. See Section 5.3.3 for further discussion.
結合チャネルは、下層のパラメータは、EAPピアとサーバとの間の一貫性を検証するプロセスです。トランスポート・チャネルの結合パラメータは不透明なオクテットとしてこのデータを扱わなければならないメディアの依存関係、EAP方式を導入しないようにするために。さらなる議論については、セクション5.3.3を参照してください。
Each key created within the EAP key management framework has a name (a unique identifier), as well as a scope (the parties to whom the key is available). The scope of exported keying material and TEKs is defined by the authenticated method-specific peer identities (Peer-Id(s)) and the authenticated server identities (Server-Id(s)), where available.
EAPキー管理フレームワーク内で作成された各キーには名前（一意の識別子）を持っているだけでなく、スコープ（キーが利用可能である人の当事者）。エクスポートされた鍵材料とのTEKの範囲は、利用可能な認証方式固有のピア・アイデンティティ（ピアID（S））と認証サーバのID（サーバID（S））によって定義されます。
MSK and EMSK Names The MSK and EMSK are exported by the EAP peer and EAP server, and MUST be named using the EAP Session-Id and a binary or textual indication of the EAP keying material being referred to.
MSK及びEMSK名MSK及びEMSKはEAPピアとEAPサーバによってエクスポートされ、そして参照されるEAPセッションIDとEAPキーイングマテリアルのバイナリまたはテキスト表示を使用して名前を付ける必要があります。
PMK Name This document does not specify a naming scheme for the Pairwise Master Key (PMK). The PMK is only identified by the name of the key from which it is derived.
PMK名はこの文書では、ペアワイズマスターキー（PMK）の命名スキームを指定していません。 PMKは、唯一それが由来するキーの名前で識別されます。
Note: IEEE 802.11 names the PMK for the purposes of being able
to refer to it in the Secure Association Protocol; the PMK name
(known as the PMKID) is based on a hash of the PMK itself as
well as some other parameters (see [IEEE-802.11] Section
8.5.1.2).
TEK Name Transient EAP Keys (TEKs) MAY be named; their naming is specified in the EAP method specification.
TEK名前過渡EAPキーズ（のTEK）が命名されるかもしれません。その命名は、EAPメソッドの仕様で指定されています。
TSK Name Transient Session Keys (TSKs) are typically named. Their naming is specified in the lower layer so that the correct set of TSKs can be identified for processing a given packet.
TSK名前一時セッション鍵（TSKs）が一般的に命名されています。 TSKsの正しいセットが与えられたパケットを処理するために識別できるように、それらの命名は、下層に指定されています。
The goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the backend authentication server).
EAPの会話の目標は、のみ、当事者に知られているEAPピアとオーセンティケータの間で新鮮なセッションキーを導出するためのものであり、EAPピアとオーセンティケータの両方のために、彼らはお互いまたはのいずれかによってその役割を実行するために許可されていることを実証します信頼できる第三者（バックエンド認証サーバ）。
Completion of an EAP method exchange (phase 1a) supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s)) and EAP server (identified by the Server-Id(s)). Both the EAP peer and EAP server know this keying material to be fresh. The Peer-Id and Server-Id are discussed in Sections 1.4, 2.4, and 2.5 as well as in Appendix A. Key freshness is discussed in Sections 3.4, 3.5, and 5.7.
のみ（ピアID（複数可）によって識別される）EAPピアとEAPサーバに知られているEAPメソッド交換の完了は、（位相1A）EAPキーイング材料（MSK、EMSK、のTEK）の導出に鍵導出の結果を支持する（同定しますサーバID（S））によります。 EAPピアとEAPサーバの両方が、この鍵素材が新鮮であることを知っています。ピアIDとサーバIDは、セクション1.4、2.4で議論されている、および2.5は、同様に、付録のようにA.主な新鮮さはセクション3.4、3.5、および5.7で説明されています。
Completion of the AAA exchange (phase 1b) results in the transport of keying material from the EAP server (identified by the Server-Id(s)) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh. Disclosure issues are discussed in Sections 3.8 and 5.3; security properties of AAA protocols are discussed in Sections 5.1 - 5.9.
AAA交換の完了は、EAPサーバからの鍵材料の搬送中に（位相1b）の結果は、他の当事者に開示することなく、（NAS-識別子によって識別される）EAP認証に（サーバID（複数可）によって識別されます）。 EAPサーバとEAP認証の両方が、このキーイング材料が新鮮であることを知っています。開示の問題は、セクション3.8と5.3で説明されています。 5.9 - AAAプロトコルのセキュリティプロパティは、セクション5.1で説明されています。
The backend authentication server is trusted to transport keying material only to the authenticator that was established with the peer, and it is trusted to transport that keying material to no other parties. In many systems, EAP keying material established by the EAP peer and EAP server are combined with publicly available data to derive other keys. The backend authentication server is trusted to refrain from deriving these same keys or acting as a man-in-the-middle even though it has access to the keying material that is needed to do so.
バックエンド認証サーバにのみピアと確立されたオーセンティケータへの鍵材料を輸送するために信頼され、そして無い他の当事者にその鍵素材を輸送するために信頼されています。多くのシステムでは、EAPピアとEAPサーバによって確立されたEAPキーイング材料は、他のキーを導出するために公的に利用可能なデータと組み合わされます。バックエンド認証サーバは、これらのキーと同じキーを導出するか、それがそうするために必要とされるキーイングマテリアルへのアクセス権を持っているにもかかわらずのman-in-the-middleとして機能する控えるように信頼されています。
The authenticator is also a trusted party. The authenticator is trusted not to distribute keying material provided by the backend authentication server to any other parties. If the authenticator uses a key derivation function to derive additional keying material, the authenticator is trusted to distribute the derived keying material only to the appropriate party that is known to the peer, and no other party. When this approach is used, care must be taken to ensure that the resulting key management system meets all of the principles in [RFC4962], confirming that keys used to protect data are to be known only by the peer and authenticator.
オーセンティケータはまた、信頼できる当事者です。オーセンティケータは、他の当事者にバックエンド認証サーバが提供する鍵材料を配布しないように信頼されています。オーセンティケータは、追加のキーイング材料を導き出すために鍵導出関数を使用している場合は、オーセンティケータはピアに知られている適切なパーティ、ノー相手に派生鍵素材を配布するために信頼されています。このアプローチを使用する場合、注意が得られた鍵管理システムは、データを保護するために使用されるキーのみピアとオーセンティケータによって知られるようにしていることを確認し、[RFC4962]での原理の全てを満たしていることを保証するために注意しなければなりません。
Completion of the Secure Association Protocol (phase 2) results in the derivation or transport of Transient Session Keys (TSKs) known only to the EAP peer (identified by the Peer-Id(s)) and authenticator (identified by the NAS-Identifier). Both the EAP peer and authenticator know the TSKs to be fresh. Both the EAP peer and authenticator demonstrate that they are authorized to perform their roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; security properties of Secure Association Protocols are discussed in Section 3.1.
導出のみ（NAS-識別子によって識別される）のEAP（ピアID（複数可）によって識別される）ピアとオーセンティケータに公知のトランジエントセッション鍵（TSKs）の輸送におけるセキュアアソシエーションプロトコル（位相2）結果の完了。 EAPピアとオーセンティケータの両方がTSKsが新鮮であることを知っています。 EAPピアとオーセンティケータの両方が彼らの役割を実行する権限があることを示しています。認証の問題は、セクション4.3.2と5.5で説明されています。セキュア協会プロトコルのセキュリティプロパティは、3.1節で議論されています。
Certain basic characteristics, known as "EAP Invariants", hold true for EAP implementations:
「EAP不変」として知られているいくつかの基本的な特徴は、EAPの実装のために当てはまります。
Mode independence Media independence Method independence Ciphersuite independence
モードの独立メディア独立方式の独立も、Ciphersuite独立
EAP is typically deployed to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator locally implements one or more EAP methods. However, when utilized in "pass-through" mode, EAP enables the deployment of new authentication methods without requiring the development of new code on the authenticator.
EAPは、典型的には、ピアは、1つまたは複数のオーセンティケータを介してネットワークへのアクセスを望む状況で拡張可能なネットワークアクセス認証をサポートするために配備されます。オーセンティケータは、スタンドアロン展開されている場合、EAPの会話は、ピアとオーセンティケータとの間で発生し、オーセンティケータは、局所的に一つ以上のEAPメソッドを実装します。 「パススルー」モードで利用される場合しかし、EAPオーセンティケータ上の新しいコードの開発を必要とせずに、新しい認証方法の展開を可能にします。
While the authenticator can implement some EAP methods locally and use those methods to authenticate local users, it can at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization, and Accounting (AAA) protocol spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [RFC4072].
オーセンティケータは、局所的に、いくつかのEAPメソッドを実装し、ローカルユーザーを認証するためにこれらの方法を使用することができるが、それはバックエンド認証サーバとピアとの間で前後にEAPパケットを転送し、通過他のユーザーと方法と同じ時間作用ででき。これはオーセンティケータとバックエンド認証サーバとの間で話さ認証、許可、アカウンティング（AAA）プロトコル内のEAPパケットをカプセル化することによって達成されます。 EAPをサポートするAAAプロトコルはRADIUS [RFC3579]とDiameter [RFC4072]を含みます。
It is a fundamental property of EAP that at the EAP method layer, the conversation between the EAP peer and server is unaffected by whether the EAP authenticator is operating in "pass-through" mode. EAP methods operate identically in all aspects, including key derivation and parameter import/export, regardless of whether or not the authenticator is operating as a pass-through.
これは、EAPメソッドレイヤで、EAPピアとサーバ間の会話は、EAP認証が「パススルー」モードで動作しているかどうかによって影響を受けないことをEAPの基本的な特性です。 EAPメソッドに関係なくオーセンティケータがパススルーとして動作しているか否かを、鍵導出およびパラメータのインポート/エクスポートを含むすべての面で同一に動作します。
The successful completion of an EAP method that supports key derivation results in the export of EAP keying material and parameters on the EAP peer and server. Even though the EAP peer or server can import channel binding parameters that can include the identity of the EAP authenticator, this information is treated as opaque octets. As a result, within EAP, the only relevant identities are the Peer-Id(s) and Server-Id(s). Channel binding parameters are only interpreted by the lower layer.
EAPキーイング材料の輸出とEAPピアとサーバ上のパラメータで鍵導出結果をサポートしているEAPメソッドが正常に完了しました。 EAPピアまたはサーバがEAP認証のアイデンティティを含むことができ、チャネル結合パラメータをインポートすることができるにもかかわらず、この情報は、不透明なオクテットとして扱われます。その結果、EAP内、唯一の関連アイデンティティはピアID（複数可）とサーバID（複数可）です。チャネル結合パラメータは、下層のみによって解釈されます。
Within EAP, the primary function of the AAA protocol is to maintain the principle of mode independence. As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation.
EAP内では、AAAプロトコルの主な機能は、モードの独立の原則を維持することです。限りEAPピアに関しては、そのEAPオーセンティケータとの会話、その会話のすべての結果は、関係なく、操作のオーセンティケータモードの、同一です。
One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748] Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and wireless networks such as 802.11 [IEEE-802.11] and 802.16 [IEEE-802.16e].
EAPの目標の一つは、EAPの方法は、任意の下層会議の[RFC3748]セクション3.1に概説された基準を機能させるためです。例えば、[RFC3748]に記載されているように、EAP認証はPPP [RFC1661]、IEEE 802の有線ネットワーク[IEEE-802.1X]、及び無線ネットワークなど802.11 [IEEE-802.11]と802.16 [IEEE-802.16eの上で実行することができます]。
In order to maintain media independence, it is necessary for EAP to avoid consideration of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported, and cannot be restricted to identifiers associated with a particular usage environment (e.g., Medium Access Control (MAC) addresses).
EAPは、メディア固有の要素を考慮を避けるためにするために、メディアの独立性を維持するためには、必要です。例えば、EAPメソッドは、それらが輸送される上に、下層の知識を有すると仮定することができず、特定の使用環境（例えば、媒体アクセス制御（MAC）アドレス）に関連付けられた識別子に制限することができません。
Note that media independence can be retained within EAP methods that support channel binding or method-specific identification. An EAP method need not be aware of the content of an identifier in order to use it. This enables an EAP method to use media-specific identifiers such as MAC addresses without compromising media independence. Channel binding parameters are treated as opaque octets by EAP methods so that handling them does not require media-specific knowledge.
そのメディア独立性は、チャネル結合または方法に固有の識別をサポートするEAPメソッド内に保持することができます。 EAPメソッドは、それを使用するために、識別子の内容を意識する必要はありません。これは、メディアの独立性を損なうことなく、このようなMACアドレスなどのメディア固有の識別子を使用するEAP方式を可能にします。それらを処理することは、メディア固有の知識を必要としないように、チャネル結合パラメータは、EAPメソッドによって不透明なオクテットとして扱われます。
By enabling pass-through, authenticators can support any method implemented on the peer and server, not just locally implemented methods. This allows the authenticator to avoid having to implement the EAP methods configured for use by peers. In fact, since a pass-through authenticator need not implement any EAP methods at all, it cannot be assumed to support any EAP method-specific code. As noted in [RFC3748] Section 2.3:
パススルーを有効にすることによって、オーセンティケータは、ピアとサーバだけでなく、局所的に実施される方法で実装任意の方法をサポートすることができます。これは、オーセンティケータは、ピアで使用するために構成されたEAPメソッドを実装する必要がないようにすることができます。実際には、パススルー認証者が全くEAPメソッドを実装する必要がないので、任意のEAPメソッド固有のコードをサポートすると仮定することはできません。 [RFC3748]セクション2.3で述べたように：
Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type.
準拠パススルー認証システムの実装では、あらゆる種類のデフォルトでは前方EAPパケットなければなりません。
This is useful where there is no single EAP method that is both mandatory to implement and offers acceptable security for the media in use. For example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not provide dictionary attack resistance, mutual authentication, or key derivation, and as a result, is not appropriate for use in Wireless Local Area Network (WLAN) authentication [RFC4017]. However, despite this, it is possible for the peer and authenticator to interoperate as long as a suitable EAP method is supported both on the EAP peer and server.
実装するために必須の両方で、使用中のメディアのために許容可能なセキュリティを提供しています単一のEAP方式が存在しない場合に有用です。例えば、[RFC3748]強制的に実装EAPメソッド（MD5チャレンジ）は、辞書攻撃性、相互認証、鍵導出を提供していません、その結果、無線ローカルエリアネットワークで使用するのに適切ではない（WLAN ）認証[RFC4017]。ピア及びオーセンティケータがあれば適切なEAPメソッドがEAPピアとサーバの両方がサポートされているように相互運用するためしかし、それにもかかわらず、それが可能です。
Ciphersuite Independence is a requirement for media independence. Since lower-layer ciphersuites vary between media, media independence requires that exported EAP keying material be large enough (with sufficient entropy) to handle any ciphersuite.
暗号スイート独立メディアの独立性の要件です。下層暗号スイートは、メディアの間で変化するので、メディア独立性は、任意の暗号スイートを処理するために（十分なエントロピーで）エクスポートされたEAPキーイング材料が十分に大きいことが必要です。
While EAP methods can negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of the data exchanged after EAP authentication has completed is negotiated between the peer and authenticator within the lower layer, outside of EAP.
EAPメソッドはEAP対話の保護に使用される暗号スイートを交渉することができるが、データの保護に使用する暗号スイートは、EAP認証が完了した後にEAPの外側、下部層内のピアとオーセンティケータとの間でネゴシエートさ交換しました。
For example, within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP) defined in [RFC1968], after EAP authentication is completed. Within [IEEE-802.11], the AP ciphersuites are advertised in the Beacon and Probe Responses prior to EAP authentication and are securely verified during a 4-way handshake exchange.
例えば、PPP内で、暗号スイートは、EAP認証が完了した後、[RFC1968]で定義された暗号化制御プロトコル（ECP）内で交渉されます。 [IEEE-802.11]、APの暗号スイートは、EAP認証の前に、ビーコンおよびプローブ応答でアドバタイズされると安全4ウェイハンドシェイク交換時に検証されている範囲内。
Since the ciphersuites used to protect data depend on the lower layer, requiring that EAP methods have knowledge of lower-layer ciphersuites would compromise the principle of media independence. As a result, methods export EAP keying material that is ciphersuite independent. Since ciphersuite negotiation occurs in the lower layer, there is no need for lower-layer ciphersuite negotiation within EAP.
データを保護するために使用する暗号スイートは、下位層に依存するため、EAPメソッドは、下位層の暗号スイートの知識を持っていることを必要とすることは、メディアの独立性の原則を危うくします。その結果、暗号スイート独立して、メソッドの輸出のEAPキーイングマテリアル。暗号スイートネゴシエーションが下層に発生するので、EAP内下層暗号スイートネゴシエーションする必要がありません。
In order to allow a ciphersuite to be usable within the EAP keying framework, the ciphersuite specification needs to describe how TSKs suitable for use with the ciphersuite are derived from exported EAP keying material. To maintain method independence, algorithms for deriving TSKs MUST NOT depend on the EAP method, although algorithms for TEK derivation MAY be specific to the EAP method.
暗号スイートがEAPキーイングフレームワーク内で使用できるようにするために、暗号の仕様は暗号スイートで使用するのに適したTSKsがエクスポートEAPキーイングマテリアルから誘導される方法を説明する必要があります。 TEK導出のためのアルゴリズムは、EAPメソッドに特異的であってもよいが、方法の独立性を維持するために、TSKsを導出するためのアルゴリズムは、EAP方式に依存してはなりません。
Advantages of ciphersuite-independence include:
暗号スイート・独立性の利点は次のとおりです。
Reduced update requirements Ciphersuite independence enables EAP methods to be used with new ciphersuites without requiring the methods to be updated. If EAP methods were to specify how to derive transient session keys for each ciphersuite, they would need to be updated each time a new ciphersuite is developed. In addition, backend authentication servers might not be usable with all EAP-capable authenticators, since the backend authentication server would also need to be updated each time support for a new ciphersuite is added to the authenticator.
減少し、更新の必要は独立性を更新する方法を必要とせずに、新しい暗号群で使用するEAP方式を可能にしますのCipherSuite。 EAPメソッドは、各暗号スイートの過渡セッションキーを導出する方法を指定した場合、彼らは新しい暗号スイートが開発されるたびに更新する必要があります。バックエンド認証サーバはまた、オーセンティケータに追加された新しい暗号スイートのための各時間のサポートを更新する必要がありますので、また、バックエンド認証サーバは、すべてのEAP対応のオーセンティケーターでは使用できない場合があります。
Reduced EAP method complexity Ciphersuite independence enables EAP methods to avoid having to include ciphersuite-specific code. Requiring each EAP method to include ciphersuite-specific code for transient session key derivation would increase method complexity and result in duplicated effort.
縮小EAPメソッドの複雑たciphersuite独立性は、暗号の固有のコードを含むことを避けるためにEAPメソッドを可能にします。トランジエントセッション鍵導出のための暗号の固有のコードを含むように、各EAPメソッドを必要とする方法の複雑さを増加させ、重複努力をもたらすであろう。
Simplified configuration Ciphersuite independence enables EAP method implementations on the peer and server to avoid having to configure ciphersuite-specific parameters. The ciphersuite is negotiated between the peer and authenticator outside of EAP. Where the authenticator operates in "pass-through" mode, the EAP server is not a party to this negotiation, nor is it involved in the data flow between the EAP peer and authenticator. As a result, the EAP server does not have knowledge of the ciphersuites and negotiation policies implemented by the peer and authenticator, nor is it aware of the ciphersuite negotiated between them. For example, since Encryption Control Protocol (ECP) negotiation occurs after authentication, when run over PPP, the EAP peer and server cannot anticipate the negotiated ciphersuite, and therefore, this information cannot be provided to the EAP method.
簡略化されたコンフィギュレーションたciphersuite独立性は、暗号の固有のパラメータを設定することを避けるために、ピアとサーバ上のEAPメソッドの実装を可能にします。暗号スイートは、EAPの外部ピアとオーセンティケータの間で交渉されます。オーセンティケータが「パススルー」モードで動作する場合、EAPサーバは、この交渉の当事者ではない、またそれは、EAPピアとオーセンティケータの間のデータフローに関与しています。その結果、EAPサーバは、ピアとオーセンティケータによって実装暗号スイートと交渉方針についての知識を持っていません。また、それらの間で交渉暗号スイートを認識しています。暗号化制御プロトコル（ECP）ネゴシエーションは、認証後に発生するのでPPP上で実行するとき、例えば、EAPピアとサーバは、ネゴシエート暗号スイートを予測することができないため、この情報は、EAPメソッドに提供することができません。
On completion of EAP authentication, EAP keying material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s), and Session-Id. The Initialization Vector (IV) is deprecated, but might be provided.
EAP認証の完了時に、EAPキーイング材料およびEAPメソッドによってエクスポートされたパラメータが、下層とAAA層（存在する場合）に提供されます。これらは、マスターセッションキー（MSK）、拡張マスターセッションキー（EMSK）を含み、ピアID（複数可）、サーバID（複数可）、およびセッションId。初期化ベクトル（IV）が廃止されましたが、提供される可能性があります。
In order to preserve the security of EAP keying material derived within methods, lower layers MUST NOT export keys passed down by EAP methods. This implies that EAP keying material passed down to a lower layer is for the exclusive use of that lower layer and MUST NOT be used within another lower layer. This prevents compromise of one lower layer from compromising other applications using EAP keying material.
メソッド内派生EAPキーイング材料のセキュリティを維持するために、下位層は、EAPメソッドによって受け継がキーをエクスポートしてはなりません。これは、下位レイヤに渡さEAPキーイング材料がその下層の専用であり、他の下位層内で使用してはならないことを意味します。これは、EAPキーイング材料を使用して他のアプリケーションを損なうから1つの下層の妥協を防止します。
EAP keying material provided to a lower layer MUST NOT be transported to another entity. For example, EAP keying material passed down to the EAP peer lower layer MUST NOT leave the peer; EAP keying material passed down or transported to the EAP authenticator lower layer MUST NOT leave the authenticator.
下層に設けられたEAPキーイング材料は、別のエンティティに輸送してはいけません。例えば、EAPキーイングマテリアルはEAPピアピアを残してはいけません下位レイヤに渡さ。 EAPキーイング材料は受け継がまたはEAP認証認証子を残してはならない下位層に輸送します。
On the EAP server, keying material and parameters requested by and passed down to the AAA layer MAY be replicated to the AAA layer on the authenticator (with the exception of the EMSK). On the authenticator, the AAA layer provides the replicated keying material and parameters to the lower layer over which the EAP authentication conversation took place. This enables mode independence to be maintained.
EAPサーバ、キーイング材料によって要求されたとAAA層まで渡されたパラメータに（EMSKを除く）オーセンティケータ上のAAA層に複製することができます。オーセンティケータに、AAA層はEAP認証会話が行われた上、下部層に複製鍵材料及びパラメータを提供します。これは、モードの独立性を維持することができます。
The EAP layer, as well as the peer and authenticator layers, MUST NOT modify or cache keying material or parameters (including channel bindings) passing in either direction between the EAP method layer and the lower layer or AAA layer.
EAPの層、並びにピアとオーセンティケータの層は、鍵材料またはEAPメソッド層と下部層またはAAA層との間のいずれかの方向に通過する（チャネルバインディングを含む）のパラメータを変更したりキャッシュしてはいけません。
Where explicitly supported by the lower layer, lower layers MAY cache keying material, including exported EAP keying material and/or TSKs; the structure of this key cache is defined by the lower layer. So as to enable interoperability, new lower-layer specifications MUST describe key caching behavior. Unless explicitly specified by the lower layer, the EAP peer, server, and authenticator MUST assume that peers and authenticators do not cache keying material. Existing EAP lower layers and AAA layers handle the generation of transient session keys and caching of EAP keying material in different ways:
明示的に下位層によってサポートされている場合、下位層は、エクスポートされたEAPキーイング材料及び/又はTSKsを含む、鍵材料キャッシュすることができます。このキーキャッシュの構造は、下位層によって定義されます。相互運用性を可能にするように、新しい下位層の仕様は、キーキャッシュの動作を説明しなければなりません。明示的に下位層によって指定されない限り、EAPピア、サーバー、およびオーセンティケータは、ピアとオーセンティケータが鍵材料をキャッシュしていないと仮定しなければなりません。既存のEAP下位レイヤとAAA層は、トランジエントセッション鍵と異なる方法でのEAPキーイングマテリアルのキャッシュの生成を取り扱います。
IEEE 802.1X-2004 When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does not support link-layer ciphersuites, and as a result, it does not provide for the generation of TSKs or caching of EAP keying material and parameters. Once EAP authentication completes, it is assumed that EAP keying material and parameters are discarded; on IEEE 802 wired networks, there is no subsequent Secure Association Protocol exchange. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports this.
IEEE 802.1X-2004有線ネットワークに用いる、IEEE 802.1X-2004 [IEEE-802.1X]はリンク層暗号スイートをサポートしていない、その結果、それはTSKsまたはEAPキーイングマテリアルのキャッシュの生成のために提供していませんそして、パラメータ。 EAP認証が完了すると、EAPキーイングマテリアルとパラメータが破棄されているものとします。 IEEE 802有線ネットワーク上で、後続のセキュア協会プロトコル交換はありません。完全転送秘密（PFS）は、ネゴシエートEAPメソッドがこれをサポートしている場合にのみ可能です。
PPP PPP, defined in [RFC1661], does not include support for a Secure Association Protocol, nor does it support caching of EAP keying material or parameters. PPP ciphersuites derive their TSKs directly from the MSK, as described in [RFC2716] Section 3.5. This is NOT RECOMMENDED, since if PPP were to support caching of EAP keying material, this could result in TSK reuse. As a result, once the PPP session is terminated, EAP keying material and parameters MUST be discarded. Since caching of EAP keying material is not permitted within PPP, there is no way to handle TSK re-key without EAP re-authentication. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports this.
[RFC1661]で定義されたPPP PPPは、セキュア協会プロトコルのサポートが含まれていません。また、EAPキーイング材料やパラメータのキャッシュをサポートしていません。 [RFC2716]セクション3.5で説明したようにPPPの暗号スイートは、MSKから直接TSKsを導き出します。 PPPは、EAPキーイング材料のキャッシングをサポートした場合、これはTSKの再利用につながる可能性があるため、これは推奨されません。 PPPセッションが終了すると、結果として、EAPキーイングマテリアルとパラメータは捨てなければなりません。 EAPキーイング材料のキャッシングはPPP内許可されていないので、EAPの再認証なしでTSKの再キーを処理する方法はありません。完全転送秘密（PFS）は、ネゴシエートEAPメソッドがこれをサポートしている場合にのみ可能です。
IKEv2 IKEv2, defined in [RFC4306], only uses the MSK for authentication purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id or Session-Id are not used. As a result, the TSKs derived by IKEv2 are cryptographically independent of the EAP keying material and re-key of IPsec SAs can be handled without requiring EAP re-authentication. Within IKEv2, it is possible to negotiate PFS, regardless of which EAP method is negotiated. IKEv2 as specified in [RFC4306] does not cache EAP keying material or parameters; once IKEv2 authentication completes, it is assumed that EAP keying material and parameters are discarded. The Session-Timeout Attribute is therefore interpreted as a limit on the VPN session time, rather than an indication of the MSK key lifetime.
[RFC4306]で定義のIKEv2のIKEv2は、認証のみを目的としない鍵導出のためのMSKを使用します。 EMSK、IV、ピアID、サーバIDまたはSession-Idは使用されません。結果として、のIKEv2によって得TSKsは、暗号EAP再認証を必要とせずに取り扱うことができる材料とIPsec SAの再鍵キーイングEAPから独立しています。 IKEv2の内、関係なく、ネゴシエートされたEAPメソッドの、PFSを交渉することが可能です。 [RFC4306]で指定されるようのIKEv2は、EAPキーイングマテリアルまたはパラメータをキャッシュしません。 IKEv2の認証が完了すると、EAPキーイングマテリアルとパラメータが破棄されることが想定されます。セッションタイムアウト項目したがってVPNセッション時間に制限はなく、MSKキー寿命の指標として解釈されます。
IEEE 802.11 IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id. More details about the structure of the cache are available in [IEEE-802.11]. In IEEE
IEEE 802.11 IEEE 802.11は、MSKのキャッシュを有効にではなく、EMSK、IV、ピアID、サーバーID、またはセッションId。キャッシュの構造についての詳細は[IEEE-802.11]でご利用いただけます。 IEEEで
802.11, TSKs are derived from the MSK using a Secure Association
Protocol known as the 4-way handshake, which includes a nonce
exchange. This guarantees TSK freshness even if the MSK is
reused. The 4-way handshake also enables TSK re-key without EAP
re-authentication. PFS is only possible within IEEE 802.11 if
caching is not enabled and the negotiated EAP method supports
PFS.
IEEE 802.16e IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id. IEEE 802.16e supports a Secure Association Protocol in which TSKs are chosen by the authenticator without any contribution by the peer. The TSKs are encrypted, authenticated, and integrity protected using the MSK and are transported from the authenticator to the peer. TSK re-key is possible without EAP re-authentication. PFS is not possible even if the negotiated EAP method supports it.
[IEEE-802.16eの]で定義されたIEEE 802.16eのは、IEEE802.16eは、MSKのキャッシュではなく、EMSK、IV、ピアID、サーバーID、またはセッションIdをサポートしています。 IEEE 802.16eのはTSKsがピアによるいかなる貢献せずにオーセンティケータによって選択されているセキュア協会プロトコルをサポートしています。 TSKsは、暗号化、認証、および整合性がMSKを使用して保護し、ピアへのオーセンティケータから輸送されています。 TSKの再キーは、EAPの再認証なしに可能です。 PFSは、ネゴシエートEAPメソッドがそれをサポートしている場合でもできません。
AAA Existing implementations and specifications for RADIUS/EAP [RFC3579] or Diameter EAP [RFC4072] do not support caching of keying material or parameters. In existing AAA clients, proxy and server implementations, exported EAP keying material (MSK, EMSK, and IV), as well as parameters and derived keys are not cached and MUST be presumed lost after the AAA exchange completes.
RADIUS / EAP [RFC3579]または直径EAP [RFC4072]のためのAAA既存の実装及び仕様は、材料またはパラメータをキーイングのキャッシュをサポートしていません。既存のAAAクライアント、プロキシとサーバーの実装では、EAPキーイング材料を輸出（MSK、EMSK、およびIV）、などのパラメータと派生キーがキャッシュされないとAAAの交換が完了した後に失わ推定されなければなりません。
In order to avoid key reuse, the AAA layer MUST delete
transported keys once they are sent. The AAA layer MUST NOT
retain keys that it has previously sent. For example, a AAA
layer that has transported the MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point forward.
This specification does not impose constraints on the architecture of the EAP authenticator or peer. For example, any of the authenticator architectures described in [RFC4118] can be used. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures.
この仕様は、EAP認証またはピアのアーキテクチャ上の制約を課すことはありません。例えば、[RFC4118]に記載のオーセンティケータ・アーキテクチャのいずれかを使用することができます。結果として、下位層はピアとオーセンティケータアーキテクチャに関する暗黙の仮定を組み込むことなく、明確EAPピアとオーセンティケータを識別する必要があります。
For example, it is possible for multiple base stations and a "controller" (e.g., WLAN switch) to comprise a single EAP authenticator. In such a situation, the "base station identity" is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in channel binding. Many base stations can share the same authenticator identity. An EAP authenticator or peer:
例えば、複数の基地局と単一のEAP認証を含むように「コントローラ」（例えば、WLANスイッチ）のために可能です。このような状況では、「基地局IDが」おそらく結合チャネルに使用される不透明なBLOBを除き、EAPメソッドの会話とは無関係です。多くの基地局が同じオーセンティケータの同一性を共有することができます。 EAP認証またはピア：
(a) can contain one or more physical or logical ports;
(b) can advertise itself as one or more "virtual" authenticators
or peers;
(c) can utilize multiple CPUs;
(d) can support clustering services for load balancing or
failover.
Both the EAP peer and authenticator can have more than one physical or logical port. A peer can simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator can offer network access to multiple peers, each via a separate physical or logical port. When a single physical authenticator advertises itself as multiple virtual authenticators, it is possible for a single physical port to belong to multiple virtual authenticators.
どちらのEAPピアとオーセンティケータは、複数の物理または論理ポートを持つことができます。ピアが同時に与えられたオーセンティケータ上の複数のオーセンティケータを介して、または複数の物理または論理ポートを介してネットワークにアクセスすることができます。同様に、オーセンティケータは、別々の物理又は論理ポートを介して複数のピア、それぞれへのネットワークアクセスを提供することができます。単一の物理オーセンティケータは、複数の仮想認証者としての地位をアドバタイズする場合、単一の物理ポートは、複数の仮想認証者に属しすることが可能です。
An authenticator can be configured to communicate with more than one EAP server, each of which is configured to communicate with a subset of the authenticators. The situation is illustrated in Figure 3.
オーセンティケータは、オーセンティケータのサブセットと通信するように構成され、それぞれが複数のEAPサーバと通信するように構成することができます。状況は図3に示されています。
The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purpose of channel binding (see Section 5.3.3). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation.
EAPメソッドの会話は、EAPピアとサーバの間です。認証者IDは、EAPメソッドによって全く考慮すれば、（セクション5.3.3を参照）は、結合チャネルのために不透明なブロブとして扱われます。 AAAプロトコル交換およびSecure協会プロトコルの会話 - しかし、オーセンティケータの同一性は、2つの他の取引所で重要です。
The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier Attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised.
AAAの会話はEAP認証とバックエンド認証サーバとの間にあります。バックエンド認証サーバの観点から、鍵材料及びパラメータは、NAS-identifier属性によって識別されるEAP認証器に搬送されます。 EAP認証は、他の当事者とEAPキーイングマテリアルまたはパラメータを共有していなければならないので、EAPピア又はバックエンド認証サーバがNAS-識別子によって定義された範囲の外にEAPキーイングマテリアル及びパラメータの使用を検出した場合、鍵材料が損なわ考慮しなければなりません。
The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers that support key caching, it is particularly important for the EAP peer, authenticator, and backend server to have a consistent view of the usage scope of the transported keying material. In order to enable this, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, rather than implicitly assuming that this is defined by the authenticator and peer endpoint addresses.
セキュア協会プロトコルの会話は、ピアとオーセンティケータとの間にあります。 EAPピア、オーセンティケータ、及びバックエンドサーバが輸送鍵材料の使用範囲の一貫したビューを持っているキーキャッシングをサポートする下位層のためには、特に重要です。これを可能にするために、セキュアアソシエーションプロトコルが明示的ではなく、暗黙的に、これはオーセンティケータとピアエンドポイントアドレスによって定義されると仮定より、下位レイヤに渡さEAPキーイングマテリアルの使用範囲を伝えることが推奨されます。
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \ Authenticator
| | | | | | | | | Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth1 | | Auth2 | | Auth3 |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | \ |
\ | \ |
\ | \ |
EAP over AAA \ | \ |
(optional) \ | \ |
\ | \ |
\ | \ |
\ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication
| Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP Peer, Authenticator, and Server
図3：EAPピアとの関係、認証、およびサーバー
Since an authenticator can have multiple ports, the scope of the authenticator key cache cannot be described by a single endpoint address. Similarly, where a peer can have multiple ports and sharing of EAP keying material and parameters between peer ports of the same link type is allowed, the extent of the peer key cache cannot be communicated by using a single endpoint address. Instead, it is RECOMMENDED that the EAP peer and authenticator consistently identify themselves utilizing explicit identifiers, rather than endpoint addresses or port identifiers.
オーセンティケータは、複数のポートを持つことができるので、認証者のキーキャッシュの範囲は、単一のエンドポイントアドレスによって記述することができません。ピアが同じリンクタイプが許可されているのピアポートとの間の複数のポートとEAPキーイングマテリアルの共有とパラメータを有することができる。同様に、ピアキーキャッシュの程度は、単一のエンドポイントアドレスを使用して通信することができません。その代わりに、EAPピアとオーセンティケータが一貫むしろエンドポイントアドレスやポート識別子よりも、明示的な識別子を利用し自分自身を特定することが推奨されます。
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client MUST be co-resident, this mechanism is applicable to the identification of EAP authenticators.
このようなRADIUS [RFC3579]とDiameter [RFC4072]などのAAAプロトコルは、AAAクライアントの識別のためのメカニズムを提供します。 EAP認証とAAAクライアントが共存しなければならないので、このメカニズムは、EAPオーセンティケータの識別にも適用可能です。
RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address attributes. Since a NAS can have more than one IP address, the NAS-Identifier Attribute is RECOMMENDED for explicit identification of the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation.
RADIUS [RFC2865]はアクセス要求パケットがNAS-識別子、NAS-IP-アドレス、およびNAS-IPv6のアドレス属性の一つ以上が含まれている必要があります。 NASは、複数のIPアドレスを持つことができるので、NAS-identifier属性は、両方のAAAプロトコル交換及びセキュアアソシエーションプロトコル会話内、オーセンティケータの明示的な識別のために推奨されます。
Problems that can arise where the peer and authenticator implicitly identify themselves using endpoint addresses include the following:
ピアとオーセンティケータは、暗黙的にエンドポイントのアドレスを使用して自分自身を識別どこ発生する可能性の問題には、次のものがあります。
(a) It is possible that the peer will not be able to determine which authenticator ports are associated with which authenticators. As a result, the EAP peer will be unable to utilize the authenticator key cache in an efficient way, and will also be unable to determine whether EAP keying material has been shared outside its authorized scope, and therefore needs to be considered compromised.
（A）は、ピアがオーセンティケータポートがどのオーセンティケータと関連付けられているかを決定することができなくなることが可能です。その結果、EAPピアは効率的な方法でオーセンティケータキーキャッシュを利用することができなくなり、また、EAPキーイング材料は、その認可範囲外で共有されているか否かを判断することができなくなり、したがって損なわ考慮する必要があります。
(b) It is possible that the authenticator will not be able to determine which peer ports are associated with which peers, preventing the peer from communicating with it utilizing multiple peer ports.
（B）は、オーセンティケータは、ピアポートは、複数のピアポートを利用して通信するピアを防ぐ、そのピアに関連付けられているかを決定することができなくなることが可能です。
(c) It is possible that the peer will not be able to determine with which virtual authenticator it is communicating. For example, multiple virtual authenticators can share a MAC address, but utilize different NAS-Identifiers.
（C）は、ピアは、それが通信している仮想オーセンティケータを用いて決定することができないことが可能です。例えば、複数の仮想オーセンティケータは、MACアドレスを共有するが、異なるNAS-識別子を利用することができます。
(d) It is possible that the authenticator will not be able to determine with which virtual peer it is communicating. Multiple virtual peers can share a MAC address, but utilize different Peer-Ids.
（D）は、オーセンティケータは、それが通信している仮想ピアと決定することができないことが可能です。複数の仮想ピアは、MACアドレスを共有するが、異なるピアのIdsを利用することができます。
(e) It is possible that the EAP peer and server will not be able to verify the authenticator identity via channel binding.
（E）は、EAPピア及びサーバはチャネル結合を介してオーセンティケータの識別情報を確認することができなくなることが可能です。
For example, problems (a), (c), and (e) occur in [IEEE-802.11], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems (b) and (d) do not occur since [IEEE-802.11] only allows a virtual peer to utilize a single port.
例えば、問題の（a）、（c）および（e）は4ウェイハンドシェイク内のピアとオーセンティケータのMACアドレスを利用する、[IEEE-802.11]で起こります。 [IEEE-802.11]は単一のポートを利用する仮想ピアを可能にするので問題（b）および（d）は発生しません。
The following steps enable lower-layer identities to be securely verified by all parties:
次の手順はしっかりとすべての当事者によって検証されるように下層のアイデンティティを有効にします。
(f) Specify the lower-layer parameters used to identify the authenticator and peer. As noted earlier, endpoint or port identifiers are not recommended for identification of the authenticator or peer when it is possible for them to have multiple ports.
（F）オーセンティケータとピアを識別するために使用される下層のパラメータを指定します。前述のように、エンドポイントまたはポート識別子は、それらが複数のポートを有することが可能であるオーセンティケータ又はピアの識別のために推奨されません。
(g) Communicate the lower-layer identities between the peer and authenticator within phase 0. This allows the peer and authenticator to determine the key scope if a key cache is utilized.
（g）このキーキャッシュが利用される場合、ピアとオーセンティケータは、キー範囲を決定することを可能にする位相0内のピアとオーセンティケータとの間の下層IDを伝えます。
(h) Communicate the lower-layer authenticator identity between the authenticator and backend authentication server within the NAS-Identifier Attribute.
（H）NAS-識別子属性内のオーセンティケータとバックエンド認証サーバとの間の下層認証IDを伝えます。
(i) Include the lower-layer identities within channel bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server.
（i）は、それらがEAPピアとサーバ間で通信されることを確実に、位相1a内（サポートされている場合）チャネルバインディング内下層IDを含めます。
(j) Support the integrity-protected exchange of identities within phase 2a.
（j）はフェーズ2a内のアイデンティティの整合性が保護交換をサポートしています。
(k) Utilize the advertised lower-layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope.
（K）キーがアドバタイズ範囲内に維持されることを確認するために、ピアとオーセンティケータを可能にするためにアドバタイズ下層アイデンティティを利用します。
When a single physical authenticator advertises itself as multiple virtual authenticators, if the virtual authenticators do not maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing a key cache.
仮想のオーセンティケータは、その後1つの仮想オーセンティケータに認証することで、論理的に独立したキーキャッシュを維持していない場合は、単一の物理オーセンティケータは、複数の仮想認証者としての地位をアドバタイズすると、ピアは、キーキャッシュを共有する他の仮想認証デバイスへのアクセスを得ることができます。
For example, where a physical authenticator implements "Guest" and "Corporate Intranet" virtual authenticators, an attacker acting as a peer could authenticate with the "Guest" virtual authenticator and derive EAP keying material. If the "Guest" and "Corporate Intranet" virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" network.
物理的なオーセンティケータは、「ゲスト」と「企業イントラネット」仮想認証デバイスを実装例については、攻撃者は、ピアが「ゲスト」の仮想オーセンティケータを使用して認証し、EAPキーイングマテリアルを導き出す可能性として動作します。 「ゲスト」と「企業イントラネット」仮想のオーセンティケータは、キーキャッシュを共有している場合、ピアは、「企業イントラネット」ネットワークへのアクセスを得るために、「ゲスト」ネットワークのための派生EAPキーイングマテリアルを利用することができます。
The following steps can be taken to mitigate this vulnerability:
次の手順は、この脆弱性を緩和するために撮影することができます。
(a) Authenticators are REQUIRED to cache associated authorizations along with EAP keying material and parameters and to apply authorizations to the peer on each network access, regardless of which virtual authenticator is being accessed. This ensures that an attacker cannot obtain elevated privileges even where the key cache is shared between virtual authenticators, and a peer obtains access to one virtual authenticator utilizing a key cache entry created for use with another virtual authenticator.
（a）は、オーセンティケータに関係なくアクセスされる仮想れるオーセンティケータの、EAPキーイング材料及びパラメータと共に関連する権限をキャッシュすると、各ネットワークアクセス上のピアに権限を適用するために必要とされます。これにより、攻撃者は、キーキャッシュが仮想認証デバイス間で共有されていても昇格した権限を得ることができないことを保証し、そしてピアは、別の仮想認証システムで使用するために作成したキーキャッシュエントリを利用し、一つの仮想オーセンティケータへのアクセスを取得します。
(b) It is RECOMMENDED that physical authenticators maintain separate key caches for each virtual authenticator. This ensures that a cache entry created for use with one virtual authenticator cannot be used for access to another virtual authenticator. Since a key cache entry can no longer be shared between virtual authentications, this step provides protection beyond that offered in (a). This is valuable in situations where authorizations are not used to enforce access limitations. For example, where access is limited using a filter installed on a router rather than using authorizations provided to the authenticator, a peer can gain unauthorized access to resources by exploiting a shared key cache entry.
（b）は、物理オーセンティケータは、各仮想オーセンティケータのための別個のキーキャッシュを維持することが推奨されます。これは、1つの仮想オーセンティケータで使用するために作成されたキャッシュ・エントリが別の仮想オーセンティケータへのアクセスに使用することができないことを保証します。キーキャッシュエントリはもはや仮想認証の間で共有することはできないので、この工程（a）で提供されるものを超えて保護を提供します。これは、権限、アクセス制限を適用するために使用されていない状況では貴重です。アクセスルータにインストールされたフィルタを使用してではなく、オーセンティケータに提供する権限を使用して限られている場合、例えば、ピアは共有鍵キャッシュエントリを利用することによって、リソースへの不正アクセスを得ることができます。
(c) It is RECOMMENDED that each virtual authenticator identify itself consistently to the peer and to the backend authentication server, so as to enable the peer to verify the authenticator identity via channel binding (see Section 5.3.3).
（C）結合チャネル（セクション5.3.3を参照）を介してオーセンティケータの身元を確認するためにピアを可能にするように、各仮想オーセンティケータは、ピアにバックエンド認証サーバに一貫して自分自身を識別することが推奨されます。
(d) It is RECOMMENDED that each virtual authenticator identify itself distinctly, in order to enable the peer and backend authentication server to tell them apart. For example, this can be accomplished by utilizing a distinct value of the NAS-Identifier Attribute.
（D）各仮想オーセンティケータは、それらを区別するために、ピアとバックエンド認証サーバを可能にするために、明確にそれ自体を識別することが推奨されます。例えば、これは、NAS-identifier属性の異なる値を利用することによって達成することができます。
As described in [RFC3748] Section 7.3, the peer identity provided in the EAP-Response/Identity can be different from the peer identities authenticated by the EAP method. For example, the identity provided in the EAP-Response/Identity can be a privacy identifier as described in "The Network Access Identifier" [RFC4282] Section 2. As noted in [RFC4284], it is also possible to utilize a Network Access Identifier (NAI) for the purposes of source routing; an NAI utilized for source routing is said to be "decorated" as described in [RFC4282] Section 2.7.
[RFC3748]セクション7.3に記載されているように、EAP応答/アイデンティティに設けられたピアのアイデンティティはEAPメソッドによって認証ピアのアイデンティティとは異なることができます。 「ネットワークアクセス識別子」に記載されているように、例えば、EAP応答/アイデンティティに設けられたアイデンティティ、プライバシー識別子とすることができる[RFC4282]セクション2 [RFC4284]で述べたように、ネットワークアクセス識別子を利用することも可能ですソースルーティングの目的のために（NAI）。ソースルーティングに利用NAIは、[RFC4282]セクション2.7に記載されているように「装飾された」と言われます。
When the EAP peer provides the Network Access Identity (NAI) within the EAP-Response/Identity, as described in [RFC3579], the authenticator copies the NAI included in the EAP-Response/Identity into the User-Name Attribute included within the Access-Request. As the Access-Request is forwarded toward the backend authentication server, AAA proxies remove decoration from the NAI included in the User-Name Attribute; the NAI included within the EAP-Response/Identity encapsulated in the Access-Request remains unchanged. As a result, when the Access-Request arrives at the backend authentication server, the EAP-Response/Identity can differ from the User-Name Attribute (which can have some or all of the decoration removed). In the absence of a Peer-Id, the backend authentication server SHOULD use the contents of the User-Name Attribute, rather than the EAP-Response/Identity, as the peer identity.
EAPピアはEAP応答/アイデンティティ内にネットワークアクセス識別子（NAI）を提供する場合、[RFC3579]に記載されているように、NAIは、User-Name属性にEAP応答/アイデンティティに含まれるオーセンティケータ・コピーは、Access内に含ま-要求。アクセス要求は、バックエンド認証サーバに向けて転送されると、AAAプロキシは、User-Name属性に含まNAIから装飾を削除します。 NAIは、アクセス要求にカプセル化されたEAP応答/アイデンティティに含まは変わりません。アクセス要求は、バックエンド認証サーバに到着したときにその結果、EAP応答/アイデンティティは、（削除装飾の一部またはすべてを持つことができます）User-Name属性と異なる場合があります。ピアIDがない場合には、バックエンド認証サーバは、ピアのアイデンティティとして、むしろEAP応答/アイデンティティよりも、User-Name属性の内容を使用すべきです。
It is possible for more than one Peer-Id to be exported by an EAP method. For example, a peer certificate can contain more than one peer identity; in a tunnel method, peer identities can be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Peer-Id in the form of a Relative Distinguished Name (RDN), whereas an inner exchange could identify the peer via its NAI or MAC address. Where EAP keying material is determined solely from the outer exchange, only the outer Peer-Id(s) are exported; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Peer-Id(s) are exported by the tunnel method.
複数のピアIDは、EAPメソッドによってエクスポートすることが可能です。例えば、ピア証明書は、複数のピアのアイデンティティを含めることができます。トンネル方式では、ピアのアイデンティティは、外側と内側の交換の両方の中に認証することができ、これらのIDは、種類や内容に異なる可能性があります。インナー交換は、そのNAI又はMACアドレスを介してピアを識別することができるのに対し、例えば、外側の交換は、相対識別名（RDN）の形でピアIDを提供することができます。 EAPキーイング材料が外側交換のみから決定される、唯一の外側のピアIDは、（S）エクスポートされます。 EAPキーイングマテリアルの両方の内側と外側の交換から決定された場合、その後、内側及び外側ピアID（複数可）の両方がトンネル方式によってエクスポートされます。
It is possible for more than one Server-Id to be exported by an EAP method. For example, a server certificate can contain more than one server identity; in a tunnel method, server identities could be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Server-Id in the form of an IP address, whereas an inner exchange could identify the server via its Fully-Qualified Domain Name (FQDN) or hostname. Where EAP keying material is determined solely from the outer exchange, only the outer Server-Id(s) are exported by the EAP method; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Server-Id(s) are exported by the EAP method.
複数のサーバー-IdがEAPメソッドによってエクスポートされることが可能です。例えば、サーバ証明書は、複数のサーバーIDを含めることができます。トンネル方式では、サーバ識別情報は、両方の外側と内側の交換内で認証することができ、これらのIDは、タイプおよびコンテンツに異なる可能性があります。インナー交換がその完全修飾ドメイン名（FQDN）またはホスト名を介してサーバーを識別することができ、一方、例えば、外側の交換は、IPアドレスの形式でサーバIDを提供することができます。 EAPキーイング材料が外側交換のみから決定される、唯一の外側のサーバID（S）EAPメソッドによってエクスポートされます。 EAPキーイングマテリアルは、両方の内側と外側のサーバID（複数可）、両方の内側と外側の交換から決定されるEAPメソッドによってエクスポートされます。
As shown in Figure 3, an authenticator can be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with can vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state.
図3に示すように、オーセンティケータは、複数のEAPサーバと通信するように構成することができます。オーセンティケータが通信するEAPサーバは、構成およびネットワークとサーバーの可用性に応じて変えることができます。 EAPピアは、レルム内のすべてのEAPサーバは認証の試みを検証するために必要な資格情報へのアクセス権を持っていると仮定することができますが、それはすべてのEAPサーバが永続的な状態を共有することを想定することはできません。
Authenticators can be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in the event of a communication failure, the authenticator can fail over to another EAP server. For example, in Figure 3, Authenticator2 can be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 can become the primary server.
オーセンティケータは、負荷のバランスをとるために、異なる第一級または第二EAPサーバで構成することができます。また、オーセンティケータは、動的にリクエストが送信されますためのEAPサーバを決定することができます。通信障害が発生した場合には、オーセンティケータは、別のEAPサーバにフェイルオーバーすることができます。例えば、図3において、Authenticator2は、最初にその一次バックエンド認証サーバとしてのEAP SERVER1で構成することができ、バックアップとしてのEAPサーバ2が、EAPのSERVER1が使用できなくなった場合、EAPのサーバ2は、一次サーバになることができます。
In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm, this decision is made by AAA clients, nor can the peer determine with which EAP server it will be communicating, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP-Request/Identity, and since the EAP server may be determined dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. Some EAP methods do not export the Server-Id so that it is possible that the EAP peer will not learn with which server it was conversing after the EAP conversation completes successfully.
一般に、EAPピアはこの決定をAAAクライアントによって行われ、領域内の特定のEAPサーバへの認証の試みを指示することができない、またピアが決定することができると、それが通信するEAPサーバは、EAPメソッドの開始前会話。サーバIDは、EAP要求/アイデンティティに含まれていない、とEAPサーバを動的に決定することができるので、オーセンティケータは検出フェーズでサーバIDをアドバタイズするために、それは一般的には不可能です。 EAPピアがEAPの会話が正常に完了した後、それが会話しているサーバーで学習しない可能性があるように、いくつかのEAPメソッドは、サーバIDをエクスポートしません。
As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, can find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748]
その結果、EAPピアは、新しいオーセンティケータに接続するか、同一のオーセンティケータに再接続に、異なるEAPサーバと通信自体を見つけることができます。 [RFC3748]で定義された高速再接続、
Section 7.2, can fail if the EAP server with which the peer communicates is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume can find that the new EAP-TLS server will not have access to the TLS Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange.
ピアが通信するEAPサーバは、それが最初にセキュリティアソシエーションを確立していると同じものでない場合は、7.2節では、失敗する可能性があります。たとえば、完了を必要とする、EAP-TLSセッション再開を試みるEAPピアは新しいEAP-TLSサーバがTLSセッションIdで識別TLSマスターキーへのアクセス権を持っていないことを見つけることができますので、セッション再開の試みは失敗しますフルEAP-TLS交換の。
EAP methods that export the Server-Id MUST authenticate the server. However, not all EAP methods supporting mutual authentication provide a non-null Server-Id; some methods only enable the EAP peer to verify that the EAP server possesses a long-term secret, but do not provide the identity of the EAP server. In this case, the EAP peer will know that an authenticator has been authorized by an EAP server, but will not confirm the identity of the EAP server. Where the EAP method does not provide a Server-Id, the peer cannot identify the EAP server with which it generated keying material. This can make it difficult for the EAP peer to identify the location of a key possessed by that EAP server.
サーバIDをエクスポートするEAPメソッドは、サーバーを認証する必要があります。しかし、相互認証をサポートしているすべてのEAPメソッドはnull以外のサーバIDを提供しません。いくつかの方法が唯一のEAPサーバは、長期的な秘密を持っていますが、EAPサーバのIDを提供しないことを確認するために、EAPピアを有効にします。この場合、EAPピアはオーセンティケータがEAPサーバによって許可されていることを知っているだろうが、EAPサーバの身元を確認しません。 EAPメソッドはサーバIDを提供しない場合は、ピアは、それが鍵材料を生成したとEAPサーバを識別することはできません。これは、それが困難なEAPピアがそのEAPサーバが持つキーの位置を特定するために作ることができます。
As noted in [RFC5216] Section 5.2, EAP methods supporting authentication using server certificates can determine the Server-Id from the subject or subjectAltName fields in the server certificate. Validating the EAP server identity can help the EAP peer to decide whether a specific EAP server is authorized. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it can even be possible for the peer to verify some channel binding parameters from the server certificate.
[RFC5216]セクション5.2で述べたように、サーバ証明書を用いて認証をサポートするEAPメソッドは、サーバー証明書のサブジェクトまたはのsubjectAltNameフィールドからサーバIDを決定することができます。 EAPサーバの身元を検証するEAPピアは、特定のEAPサーバが許可されているかどうかを判断するのに役立ちます。ピアは、サーバ証明書からパラメータを結合するいくつかのチャンネルを確認するためのいくつかの場合において、このような[RFC4334]で定義された証明書拡張は、サーバ証明書に含まれている場合のように、それも可能であることができます。
It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, it is possible that the Server-Id exported by EAP methods will not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, it is possible that the subjectAltName used in the backend authentication server certificate will not be identical to the Server-Id or backend authentication server FQDN. This is not normally an issue in EAP, as the authenticator will be unaware of the identities used between the EAP peer and server. However, this can be an issue for key caching, if the authenticator is expected to locate a backend authentication server corresponding to a Server-Id provided by an EAP peer.
問題は、EAPサーバがEAPピアとオーセンティケータに異なり、それ自体を特定の状況で発生することが可能です。例えば、EAPメソッドによってエクスポートされたサーバIDがバックエンド認証サーバの完全修飾ドメイン名（FQDN）と同一ではない可能性があります。証明書ベースの認証はRADIUSまたはDIAMETER内で使用される場合、バックエンド認証サーバ証明書で使用されるのsubjectAltNameは、サーバIDまたはバックエンド認証サーバFQDNと同じでない可能性があります。オーセンティケータはEAPピアとサーバ間で使用されるアイデンティティを知らないだろう、これは、通常、EAPの問題ではありません。オーセンティケータがEAPピアが提供するサーバIDに対応するバックエンド認証サーバを見つけることが期待されている場合ただし、これは、キーキャッシュの問題になることができます。
Where the backend authentication server FQDN differs from the subjectAltName in the backend authentication server certificate, it is possible that the AAA client will not be able to determine whether it is talking to the correct backend authentication server. Where the Server-Id and backend authentication server FQDN differ, it is possible that the combination of the key scope (Peer-Id(s), Server-Id(s)) and EAP conversation identifier (Session-Id) will not be sufficient to determine where the key resides. For example, the authenticator can identify backend authentication servers by their IP address (as occurs in RADIUS), or using a Fully Qualified Domain Name (as in Diameter). If the Server-Id does not correspond to the IP address or FQDN of a known backend authentication server, then it may not be possible to locate which backend authentication server possesses the key.
バックエンド認証サーバFQDNがバックエンド認証サーバ証明書内のsubjectAltNameと異なった場合、AAAクライアントは、それが正しいバックエンド認証サーバに話しているかどうかを決定することができない可能性があります。サーバIDおよびバックエンド認証サーバFQDNが異なる場合、重要なスコープ（ピアID（複数可）、サーバID（S））の組み合わせとEAPの会話識別子（セッションID）が十分ではない可能性があります鍵はどこにあるかを決定します。 （RADIUSで起こるように）、例えば、オーセンティケータは、それらのIPアドレスによって、バックエンド認証サーバを識別することができる、または（直径として）完全修飾ドメイン名を使用して。サーバー-Idが知られているバックエンド認証サーバのIPアドレスまたはFQDNに対応していない場合、鍵を持っているどのバックエンド認証サーバー見つけることができない場合があります。
EAP, as defined in [RFC3748], supports key derivation, but does not provide for the management of lower-layer security associations. Missing functionality includes:
EAPは、[RFC3748]で定義されるように、鍵導出をサポートするが、下層のセキュリティアソシエーションの管理を提供しません。不足している機能が含まれています：
(a) Security Association negotiation. EAP does not negotiate lower-layer unicast or multicast security associations, including cryptographic algorithms or traffic profiles. EAP methods only negotiate cryptographic algorithms for their own use, not for the underlying lower layers. EAP also does not negotiate the traffic profiles to be protected with the negotiated ciphersuites; in some cases the traffic to be protected can have lower-layer source and destination addresses different from the lower-layer peer or authenticator addresses.
（a）は、セキュリティアソシエーションのネゴシエーション。 EAPは、暗号アルゴリズムまたはトラフィックプロファイルを含む下層ユニキャストまたはマルチキャストのセキュリティアソシエーションをネゴシエートしません。 EAPメソッドは、独自の使用だけのためではなく、根本的な下位層のための暗号化アルゴリズムを交渉します。 EAPはまた、交渉し暗号スイートで保護するトラフィックプロファイルをネゴシエートしません。いくつかのケースで保護されるトラフィックは、下層ピアまたはオーセンティケータのアドレスとは異なる下層送信元アドレスと宛先アドレスを有することができます。
(b) Re-key. EAP does not support the re-keying of exported EAP keying material without EAP re-authentication, although EAP methods can support "fast reconnect" as defined in [RFC3748] Section 7.2.1.
（B）リキー。 [RFC3748]セクション7.2.1で定義されるようにEAPメソッドは「高速再接続」をサポートすることができるがEAPは、EAP再認証なしエクスポートEAPキーイング材料の再入力をサポートしていません。
(c) Key delete/install semantics. EAP does not synchronize installation or deletion of keying material on the EAP peer and authenticator.
（c）は、Deleteキー/セマンティクスをインストールします。 EAPは、EAPピアとオーセンティケータ上に材料をキーイングのインストールや削除を同期しません。
(d) Lifetime negotiation. EAP does not support lifetime negotiation for exported EAP keying material, and existing EAP methods also do not support key lifetime negotiation.
（d）の生涯交渉。 EAPは、エクスポートされたEAPキーイングマテリアルのための生涯ネゴシエーションをサポートしていない、と既存のEAPメソッドも、キーの有効期間ネゴシエーションをサポートしていません。
(e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can be reused if EAP keying material is cached.
（e）は、TSKの鮮度を保証しました。 EAPキーイングマテリアルがキャッシュされている場合、ポストEAPハンドシェークがなければ、TSKsを再利用することができます。
These deficiencies are typically addressed via a post-EAP handshake known as the Secure Association Protocol.
これらの欠陥は、通常、セキュア協会プロトコルとして知られているポストEAPハンドシェークを介してアドレス指定されています。
Since neither EAP nor EAP methods provide for establishment of lower-layer security associations, it is RECOMMENDED that these facilities be provided within the Secure Association Protocol, including:
EAPやEAPどちらの方法は、下位層のセキュリティアソシエーションの確立のために提供しているので、これらの施設は、を含めた安全協会プロトコル内に提供することをお勧めします。
(a) Entity Naming. A basic feature of a Secure Association Protocol is the explicit naming of the parties engaged in the exchange. Without explicit identification, the parties engaged in the exchange are not identified and the scope of the EAP keying parameters negotiated during the EAP exchange is undefined.
（a）は、エンティティネーミング。セキュア協会プロトコルの基本的な機能は、Exchangeに従事する当事者の明示的な命名です。明示的に識別することなく、交換に従事する当事者が識別され、EAP交換中にネゴシエートされたEAPキーイングパラメータの範囲は不定であるれていません。
(b) Mutual proof of possession of EAP keying material. During the Secure Association Protocol, the EAP peer and authenticator MUST demonstrate possession of the keying material transported between the backend authentication server and authenticator (e.g., MSK), in order to demonstrate that the peer and authenticator have been authorized. Since mutual proof of possession is not the same as mutual authentication, the peer cannot verify authenticator assertions (including the authenticator identity) as a result of this exchange. Authenticator identity verification is discussed in Section 2.3.
（b）は、EAPキーイングマテリアルの所有の相互証明を。セキュアアソシエーションプロトコル中、EAPピアとオーセンティケータは、ピアとオーセンティケータが許可されていることを実証するために、バックエンド認証サーバおよびオーセンティケータ（例えば、MSK）との間に搬送キーイングマテリアルの所有を実証しなければなりません。所有の相互証明は、相互認証と同じではないので、ピアはこの交換の結果（認証者識別情報を含む）オーセンティケータアサーションを検証することができません。オーセンティケータの本人確認は、2.3節で議論されています。
(c) Secure capabilities negotiation. In order to protect against spoofing during the discovery phase, ensure selection of the "best" ciphersuite, and protect against forging of negotiated security parameters, the Secure Association Protocol MUST support secure capabilities negotiation. This includes the secure negotiation of usage modes, session parameters (such as security association identifiers (SAIDs) and key lifetimes), ciphersuites and required filters, including confirmation of security-relevant capabilities discovered during phase 0. The Secure Association Protocol MUST support integrity and replay protection of all capability negotiation messages.
（C）セキュア機能のネゴシエーション。 、発見フェーズの間になりすましから守る「最良の」暗号スイートの選択を確保し、交渉されたセキュリティパラメータの鍛造から保護するために、セキュア協会プロトコルは、セキュアな機能ネゴシエーションをサポートしなければなりません。これは、利用形態、（例えばセキュリティアソシエーション識別子（SAIDs）とキーの有効期間など）セッションパラメータの安全なネゴシエーションを含み、セキュア協会議定0期に発見されたセキュリティ関連の機能の確認を含む暗号スイートと必要なフィルタは、整合性をサポートしなければならないし、すべての能力交渉メッセージの再生保護。
(d) Key naming and selection. Where key caching is supported, it is possible for the EAP peer and authenticator to share more than one key of a given type. As a result, the Secure Association Protocol MUST explicitly name the keys used in the proof of possession exchange, so as to prevent confusion when more than one set of keying material could potentially be used as the basis for the exchange. Use of the key naming mechanism described in Section 1.4.1 is RECOMMENDED.
（d）のキーの命名と選択。キーキャッシュがサポートされている場合、EAPピアとオーセンティケータは、与えられたタイプの複数のキーを共有することが可能です。鍵材料の複数のセットは、潜在的交換のための基礎として使用することができたときに混乱を防止するために、結果として、セキュア協会プロトコルは、明示的に、所持交換の証明に使用されるキーに名前を付ける必要があります。 1.4.1項で説明したキー命名メカニズムの使用を推奨します。
In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated transient session keys so that the correct set of
transient session keys can be identified for processing a given
packet. The phase 2 Secure Association Protocol also MUST
support transient session key activation and SHOULD support
deletion so that establishment and re-establishment of transient
session keys can be synchronized between the parties.
(e) Generation of fresh transient session keys (TSKs). Where the lower layer supports caching of keying material, the EAP peer lower layer can initiate a new session using keying material that was derived in a previous session. Were the TSKs to be derived solely from a portion of the exported EAP keying material, this would result in reuse of the session keys that could expose the underlying ciphersuite to attack.
新鮮な過渡セッションキー（TSKs）の（e）の生成。下層材料を合わせるのキャッシュをサポートする場合、EAPは、下位層は、前のセッションで導出された鍵材料を使用して新しいセッションを開始することができるピア。エクスポートされたEAPキーイング材料の部分のみに由来するTSKsた、これは攻撃の基盤となる暗号スイートを公開する可能性がセッションキーの再利用につながります。
In lower layers where caching of keying material is supported,
the Secure Association Protocol phase is REQUIRED, and MUST
support the derivation of fresh unicast and multicast TSKs, even
when the transported keying material provided by the backend
authentication server is not fresh. This is typically supported
via the exchange of nonces or counters, which are then mixed
with the keying material in order to generate fresh unicast
(phase 2a) and possibly multicast (phase 2b) session keys. By
not using exported EAP keying material directly to protect data,
the Secure Association Protocol protects it against compromise.
(f) Key lifetime management. This includes explicit key lifetime negotiation or seamless re-key. EAP does not support the re-keying of EAP keying material without re-authentication, and existing EAP methods do not support key lifetime negotiation. As a result, the Secure Association Protocol MAY handle the re-key and determination of the key lifetime. Where key caching is supported, secure negotiation of key lifetimes is RECOMMENDED. Lower layers that support re-key, but not key caching, may not require key lifetime negotiation. For example, a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and re-keying the SA when necessary.
（f）は鍵寿命管理。これは、明示的なキーの有効期間の交渉やシームレスな再キーが含まれています。 EAPは、再認証なしでEAPキーイングマテリアルの再入力をサポートしていない、と既存のEAPメソッドは、キーの有効期間ネゴシエーションをサポートしていません。その結果、セキュア協会プロトコルは、キーの有効期間の再キーと決意を処理することができます。キーキャッシュがサポートされている場合は、キーの有効期間の安全な交渉を推奨します。再キーをサポートする下位層ではなく、キーキャッシュは、キーの有効期間の交渉を必要としない場合があります。例えば、IKEv1の[RFC2409]とのIKEv2 [RFC4306]との差がIKEv1のSA寿命でネゴシエートされたことです。 IKEv2の中で、SAの両端には、SAに、独自の有効期間ポリシーを施行し、必要な時にSAを再キーイングする責任があります。
(g) Key state resynchronization. It is possible for the peer or authenticator to reboot or reclaim resources, clearing portions or all of the key cache. Therefore, key lifetime negotiation cannot guarantee that the key cache will remain synchronized, and it may not be possible for the peer to determine before attempting to use a key whether it exists within the authenticator cache. It is therefore RECOMMENDED for the EAP lower layer to provide a mechanism for key state resynchronization, either via the SAP or using a lower layer indication (see [RFC3748] Section 3.4). Where the peer and authenticator do not jointly possess a key with which to protect the resynchronization exchange, secure resynchronization is not possible, and alternatives (such as an initiation of EAP re-authentication after expiration of a timer) are needed to ensure timely resynchronization.
（g）のキーの状態の再同期。ピアまたはオーセンティケータは、一部またはキーキャッシュのすべてをクリアし、再起動するか、リソースを再利用することが可能です。そのため、キーの有効期間の交渉は、キーキャッシュが同期されたままになることを保証することはできませんし、ピアはそれがオーセンティケータキャッシュ内に存在するかどうかの鍵を使用する前に判断することができない場合があります。それゆえSAPを介して下層の指示のいずれかを使用して、キー状態の再同期するためのメカニズムを提供するEAP下位レイヤに推奨される（[RFC3748]セクション3.4を参照）。ピアとオーセンティケータが共同で再同期交換を保護するとの鍵を持っていない場合は、安全な再同期が可能ではない、と（例えばタイマの満了後にEAP再認証の開始など）の選択肢はタイムリーな再同期を確保するために必要とされます。
(h) Key scope synchronization. To support key scope determination, the Secure Association Protocol SHOULD provide a mechanism by which the peer can determine the scope of the key cache on each authenticator and by which the authenticator can determine the scope of the key cache on a peer. This includes negotiation of restrictions on key usage.
（H）キー範囲の同期。キースコープ決意をサポートするために、セキュアアソシエーションプロトコルは、ピアは、各オーセンティケータ上のキーキャッシュの範囲を決定することができ、それによってオーセンティケータが、ピアのキーキャッシュの範囲を決定することができるメカニズムを提供するべきです。これは、鍵の使用上の制限の交渉を含んでいます。
(i) Traffic profile negotiation. The traffic to be protected by a lower-layer security association will not necessarily have the same lower-layer source or destination address as the EAP peer and authenticator, and it is possible for the peer and authenticator to negotiate multiple security associations, each with a different traffic profile. Where this is the case, the profile of protected traffic SHOULD be explicitly negotiated. For example, in IKEv2 it is possible for an Initiator and Responder to utilize EAP for authentication, then negotiate a Tunnel Mode Security Association (SA), which permits passing of traffic originating from hosts other than the Initiator and Responder. Similarly, in IEEE 802.16e, a Subscriber Station (SS) can forward traffic to the Base Station (BS), which originates from the Local Area Network (LAN) to which it is attached. To enable this, Security Associations within IEEE 802.16e are identified by the Connection Identifier (CID), not by the EAP peer and authenticator MAC addresses. In both IKEv2 and IEEE 802.16e, multiple security associations can exist between the EAP peer and authenticator, each with their own traffic profile and quality of service parameters.
（I）トラフィックプロファイル交渉。下層セキュリティアソシエーションにより保護されるトラフィックは、必ずしもEAPピアとオーセンティケータと同じ下層のソースまたは宛先アドレスを持っていないであろう、ピアとオーセンティケータは、複数のセキュリティアソシエーションをネゴシエートすることが可能であり、各異なるトラフィックプロファイル。これが事実である場合には、保護されたトラフィックのプロファイルが明示的に交渉されるべきです。イニシエータとレスポンダは、次に、認証のためにEAPを使用するイニシエータとレスポンダ以外のホストから発信されたトラフィックの通過を許可するトンネルモードセキュリティアソシエーション（SA）をネゴシエートするために、例えば、IKEv2の中でそれが可能です。同様に、IEEE 802.16eの中に、加入者局（SS）は、それが接続されているローカルエリアネットワーク（LAN）に由来する基地局（BS）にトラフィックを転送することができます。これを可能にするために、のIEEE802.16e内のセキュリティアソシエーションは、MACアドレスの接続識別子（CID）によってではなく、EAPピアとオーセンティケータによって識別されます。両方のIKEv2およびIEEE 802.16eのでは、複数のセキュリティアソシエーションは、EAPピアとオーセンティケータ、独自のトラフィックプロファイルとサービス品質パラメータとそれぞれの間に存在することができます。
(j) Direct operation. Since the phase 2 Secure Association Protocol is concerned with the establishment of security associations between the EAP peer and authenticator, including the derivation of transient session keys, only those parties have "a need to know" the transient session keys. The Secure Association Protocol MUST operate directly between the peer and authenticator and MUST NOT be passed-through to the backend authentication server or include additional parties.
（j）を直接操作。フェーズ2セキュア協会プロトコルは、過渡セッションキーの導出を含むEAPピアとオーセンティケータ間のセキュリティアソシエーションの確立に関係しているので、のみ当事者は、過渡セッションキーを「知る必要」があります。セキュア協会プロトコルは、ピアとオーセンティケータとの間で直接操作しなければならないとバックエンド認証サーバにスルー渡されたり、追加の当事者を含めてはなりません。
(k) Bi-directional operation. While some ciphersuites only require a single set of transient session keys to protect traffic in both directions, other ciphersuites require a unique set of transient session keys in each direction. The phase 2 Secure Association Protocol SHOULD provide for the derivation of unicast and multicast keys in each direction, so as not to require two separate phase 2 exchanges in order to create a bi-directional phase 2 security association. See [RFC3748] Section 2.4 for more discussion.
（K）双方向動作を制御します。いくつかの暗号スイートのみ両方向のトラフィックを保護するために、過渡セッションキーの単一のセットを必要としますが、他の暗号スイートは、各方向における過渡セッションキーのユニークなセットを必要とします。双方向フェーズ2セキュリティアソシエーションを作成するために、2つの別個のフェーズ2回の交換を必要としないように、位相2セキュアアソシエーションプロトコルは、各方向におけるユニキャストとマルチキャストキーの導出のために提供すべきです。より多くの議論のための[RFC3748]セクション2.4を参照してください。
Absent explicit specification within the lower layer, after the completion of phase 1b, transported keying material, and parameters are bound to the EAP peer and authenticator, but are not bound to a specific peer or authenticator port.
下部層内の不在の明示的な指定は、位相1bと、搬送キーイング材料、およびパラメータの完了後にEAPピアとオーセンティケータに結合されているが、特定のピアまたはオーセンティケータのポートにバインドされていません。
While EAP keying material passed down to the lower layer is not intrinsically bound to particular authenticator and peer ports, TSKs MAY be bound to particular authenticator and peer ports by the Secure Association Protocol. However, a lower layer MAY also permit TSKs to be used on multiple peer and/or authenticator ports, provided that TSK freshness is guaranteed (such as by keeping replay counter state within the authenticator).
下位レイヤに渡さEAPキーイング材料は、本質的に特定のオーセンティケータとピアポートにバインドされていないが、TSKsセキュアアソシエーションプロトコルによって特定のオーセンティケータとピアポートに結合されてもよいです。しかし、下位層は、複数のピア及び/又はオーセンティケータのポートで使用されるTSKsをも可能にすることができる、TSK鮮度が（例えば、オーセンティケータ内のリプレイカウンタの状態を維持することなどによって）保証されることを条件とします。
In order to further limit the key scope, the following measures are suggested:
さらに、キー範囲を制限するために、以下の対策が提案されています。
(a) The lower layer MAY specify additional restrictions on key usage, such as limiting the use of EAP keying material and parameters on the EAP peer to the port over which the EAP conversation was conducted.
（a）は、下部層は、EAPの会話を行った先のポートにEAPピアに対するEAPキーイングマテリアル及びパラメータの使用を制限するものとして主要な用法上の追加制限を指定することができます。
(b) The backend authentication server and authenticator MAY implement additional attributes in order to further restrict the scope of keying material. For example, in IEEE 802.11, the backend authentication server can provide the authenticator with a list of authorized Called or Calling-Station-Ids and/or SSIDs for which keying material is valid.
（b）はバックエンド認証サーバと、オーセンティケータはさらに、鍵材料の範囲を制限するために追加の属性を実装することができます。例えば、IEEE 802.11で、バックエンド認証サーバは、呼び出されたり呼び出し-駅-のIdsおよび/またはキーイング材料が有効であるSSIDを認可リストとオーセンティケータを提供することができます。
(c) Where the backend authentication server provides attributes restricting the key scope, it is RECOMMENDED that restrictions be securely communicated by the authenticator to the peer. This can be accomplished using the Secure Association Protocol, but also can be accomplished via the EAP method or the lower layer.
バックエンド認証サーバがキー範囲を制限する属性を提供する（c）が、制限が確実にピアへのオーセンティケータによって通信することが推奨されます。これは、セキュアアソシエーションプロトコルを使用して達成することができるだけでなく、EAPメソッドまたは下層を介して達成することができます。
When an EAP re-authentication takes place, new EAP keying material is exported by the EAP method. In EAP lower layers where EAP re-authentication eventually results in TSK replacement, the maximum lifetime of derived keying material (including TSKs) can be less than or equal to that of EAP keying material (MSK/EMSK), but it cannot be greater.
EAPの再認証が行われると、新しいEAPキーイングマテリアルは、EAPメソッドによってエクスポートされます。 EAP再認証が最終的TSK置換をもたらすEAP下位層において、（TSKsを含む）由来の鍵材料の最大寿命は、以下のEAPキーイングマテリアル（MSK / EMSK）と同等であることができるが、それは大きくすることはできません。
Where TSKs are derived from or are wrapped by exported EAP keying material, compromise of that exported EAP keying material implies compromise of TSKs. Therefore, if EAP keying material is considered stale, not only SHOULD EAP re-authentication be initiated, but also replacement of child keys, including TSKs.
どこTSKsはその妥協がEAPキーイングマテリアルはTSKsの妥協を意味し、エクスポート、由来しているまたはエクスポートEAPキーイング材料によって包まれています。したがって、もしEAPキーイングマテリアルは、EAP再認証を開始するだけでなく、TSKs含む子キーの交換することのみならず、古くなったと考えられています。
Where EAP keying material is used only for entity authentication but not for TSK derivation (as in IKEv2), compromise of exported EAP keying material does not imply compromise of the TSKs. Nevertheless, the compromise of EAP keying material could enable an attacker to impersonate an authenticator, so that EAP re-authentication and TSK re-key are RECOMMENDED.
EAPキーイング材料のみエンティティ認証のためではなく、（IKEv2のように）TSKを導出するために使用される場合、エクスポートされたEAPキーイング材料の妥協はTSKsの妥協を意味するものではありません。それにもかかわらず、EAPキーイング材料の妥協は、EAPの再認証とTSKの再鍵が推奨されるように、オーセンティケータを偽装する攻撃を可能にすることができます。
With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2 Clarifications and Implementation Guidelines", states:
IKEv2の、[RFC4718]の5.2節に関しては、「IKEv2の明確化と実装のガイドライン」、状態：
Rekeying the IKE_SA and reauthentication are different concepts in IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and resets the Message ID counters, but it does not authenticate the parties again (no AUTH or EAP payloads are involved)... This means that reauthentication also establishes new keys for the IKE_SA and CHILD_SAs. Therefore while rekeying can be performed more often than reauthentication, the situation where "authentication lifetime" is shorter than "key lifetime" does not make sense.
鍵の変更IKE_SAと再認証がIKEv2の中に異なる概念です。再キーイングIKE_SAはIKE_SAのための新しいキーを確立し、メッセージIDカウンタをリセットしますが、それは...これは、再認証もIKE_SAとのCHILD_SAsのための新しいキーを確立することを意味します（何AUTHまたはEAPペイロードが関与していない）、再びパーティーを認証しません。鍵の再生成を再認証よりも頻繁に実行することができるのでながら、「認証の有効期間は、」「キー寿命」よりも短くなっている状況では意味がありません。
Child keys that are used frequently (such as TSKs that are used for traffic protection) can expire sooner than the exported EAP keying material on which they are dependent, so that it is advantageous to support re-key of child keys prior to EAP re-authentication. Note that deletion of the MSK/EMSK does not necessarily imply deletion of TSKs or child keys.
前にEAP再に子キーの再キーをサポートするために有利になるように、（そのようなトラフィックの保護のために使用されているTSKsなど）が頻繁に使用されている子キーは、彼らが依存エクスポートEAPキーイング材料よりも早く期限切れになることができます認証。 MSK / EMSKの削除は必ずしもTSKsまたは子キーの削除を意味しないことに注意してください。
Failure to mutually prove possession of exported EAP keying material during the Secure Association Protocol exchange need not be grounds for deletion of keying material by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack.
相互セキュア協会プロトコル交換中にエクスポートされたEAPキーイングマテリアルの所有を証明するために失敗すると、両当事者によって材料をキーイングの削除の根拠である必要はありません。律速セキュア協会プロトコル交換は、ブルートフォース攻撃を防ぐために使用することができます。
The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. TEKs are typically created during an EAP conversation, used until the end of the conversation and then discarded. However, methods can re-key TEKs during an EAP conversation.
一時EAPキーズ（のTEK）がEAPの会話を保護するために使用されるセッションキーです。 TEKは、EAPメソッドの内部で、エクスポートされません。 TEKは、一般的に、EAPの会話中に作成された会話の終わりまで使用し、その後廃棄されています。しかし、この方法は、EAPの会話の間のTEK-キーを再することができます。
When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, TEK re-key MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK re-keying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa.
EAPの会話の中や会話全体でのTEKを使用する場合は、再生保護およびキー分離の要件が満たされていることを確実にすることが必要です。リプレイカウンタが使用される場合、例えば、TEKの再鍵は、先行カウンタの包装に起こらなければなりません。同様に、TSKsはTEK再キーイングまたはキャッシングにもかかわらずのTEKから暗号別個のままでなければなりません。これはTSKsおよびその逆の妥協に直結するからTEKの妥協を防ぐことができます。
EAP methods MAY cache local EAP keying material (TEKs) that can persist for multiple EAP conversations when fast reconnect is used [RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC5216]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local EAP keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee that the original long-term credentials are still in the possession of the peer. For instance, a smart-card holding the private key for EAP-TLS may have been removed. EAP servers SHOULD also verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired.
EAPメソッドは、高速再接続を使用する場合、複数のEAPの会話のための持続可能なローカルEAPキーイング材料（のTEK）[RFC3748]をキャッシュすることができます。例えば、（例えば、EAP-TLS [RFC5216]など）TLSに基づくEAPメソッドは、典型的には、かなりの期間にわたって、TLSマスターシークレットを導出し、キャッシュ。 EAPメソッド内で計算され、他のローカルEAPキーイング材料の寿命は方法によって定義されます。高速再接続を使用する場合、一般的には、オリジナルの長期的な資格情報がピアの所有に残っているという保証がないことに注意してください。たとえば、EAP-TLS用の秘密鍵を保持しているスマートカードが削除された可能性があります。 EAPサーバは、長期の資格情報は、オリジナルの認証に使用する証明書がまだ有効期限が切れていないことを確認することなどによって、まだ有効であることを確認する必要があります。
The following mechanisms are available for communicating the lifetime of keying material between the EAP peer, server, and authenticator:
次のメカニズムは、EAPピア、サーバ、オーセンティケータとの間で鍵材料の寿命を通信するために利用可能です。
AAA protocols (backend authentication server and authenticator) Lower-layer mechanisms (authenticator and peer) EAP method-specific negotiation (peer and server)
AAAプロトコル（バックエンド認証サーバと認証）下層機構（オーセンティケータとピア）EAPメソッド固有ネゴシエーション（ピア及びサーバ）
Where the EAP method does not support the negotiation of the lifetime of exported EAP keying material, and a key lifetime negotiation mechanism is not provided by the lower layer, it is possible that there will not be a way for the peer to learn the lifetime of keying material. This can leave the peer uncertain of how long the authenticator will maintain keying material within the key cache. In this case the lifetime of keying material can be managed as a system parameter on the peer and authenticator; a default lifetime of 8 hours is RECOMMENDED.
EAPメソッドは下位層によって提供されていないエクスポートされたEAPキーイング材料の寿命、およびキー寿命交渉メカニズムのネゴシエーションをサポートしていない場合は、ピアがの生涯を学ぶための方法がないだろうということも可能です材料をキーイング。これは、オーセンティケータは、キーキャッシュ内のキーイング材料を維持する時間の長さの不確かピアを残すことができます。この場合、鍵材料の寿命は、ピアとオーセンティケータのシステムパラメータとして管理することができます。 8時間のデフォルトの寿命を推奨します。
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be used to communicate the maximum key lifetime from the backend authentication server to the authenticator.
このようなRADIUS [RFC2865]とDiameter [RFC4072]などのAAAプロトコルは、オーセンティケータにバックエンド認証サーバから最大のキー寿命を通信するために使用することができます。
The Session-Timeout Attribute is defined for RADIUS in [RFC2865] and for Diameter in [RFC4005]. Where EAP is used for authentication, [RFC3580] Section 3.17, indicates that a Session-Timeout Attribute sent in an Access-Accept along with a Termination-Action value of RADIUS-Request specifies the maximum number of seconds of service provided prior to EAP re-authentication.
セッションタイムアウト属性は[RFC2865]及び[RFC4005]の直径のRADIUSのために定義されます。 EAPは、認証に使用される場合、[RFC3580]セクション3.17は、で送信されたセッションタイムアウト属性RADIUSリクエストの終了アクション値とともにアクセスが、受け入れていることを示しているEAPの再前に提供されるサービスの最大秒数を指定します-authentication。
However, there is also a need to be able to specify the maximum lifetime of cached keying material. Where EAP pre-authentication is supported, cached keying material can be pre-established on the authenticator prior to session start and will remain there until expiration. EAP lower layers supporting caching of keying material MAY also persist that material after the end of a session, enabling the peer to subsequently resume communication utilizing the cached keying material. In these situations it can be desirable for the backend authentication server to specify the maximum lifetime of cached keying material.
ただし、キャッシュされた鍵材料の最大存続期間を指定できるようにする必要もあります。 EAP事前認証がサポートされている場合、キャッシュされた鍵材料は、セッション開始前にオーセンティケータに事前に確立することができ、有効期限までそこに残ります。鍵材料のキャッシュをサポートするEAP下位層は、その後、キャッシュされた鍵材料を利用した通信を再開するためにピアを可能にする、セッションの終了後、その物質を持続し得ます。バックエンド認証サーバがキャッシュされた鍵材料の最大存続期間を指定するためにこのような状況では、それは望ましいことがあります。
To accomplish this, [IEEE-802.11] overloads the Session-Timeout Attribute, assuming that it represents the maximum time after which transported keying material will expire on the authenticator, regardless of whether transported keying material is cached.
これを達成するために、[IEEE-802.11]は、それが鍵材料に関係なく搬送キーイング材料がキャッシュされているかどうかの、オーセンティケータに期限切れとなる搬送後の最大時間を表すと仮定すると、セッションタイムアウト項目をオーバーロード。
An IEEE 802.11 authenticator receiving transported keying material is expected to initialize a timer to the Session-Timeout value, and once the timer expires, the transported keying material expires. Whether this results in session termination or EAP re-authentication is controlled by the value of the Termination-Action Attribute. Where EAP re-authentication occurs, the transported keying material is replaced, and with it, new calculated keys are put in place. Where session termination occurs, transported and derived keying material is deleted.
輸送鍵材料を受信IEEE 802.11オーセンティケータは、セッションタイムアウト値にタイマーを初期化することが期待され、タイマーが満了した後に、輸送鍵材料が満了しています。セッション終了またはEAPの再認証で、この結果は、Termination-Action属性値によって制御されているかどうか。 EAPの再認証が発生した場合は、輸送鍵材料が交換され、そしてそれを、新たに計算されたキーが所定の位置に置かれています。セッション終了が発生した場合は、輸送および派生鍵素材が削除されます。
Overloading the Session-Timeout Attribute is problematic in situations where it is necessary to control the maximum session time and key lifetime independently. For example, it might be desirable to limit the lifetime of cached keying material to 5 minutes while permitting a user once authenticated to remain connected for up to an hour without re-authenticating. As a result, in the future, additional attributes can be specified to control the lifetime of cached keys; these attributes MAY modify the meaning of the Session-Timeout Attribute in specific circumstances.
セッションタイムアウト属性をオーバーロードすることは、独立して、最大セッション時間と鍵の有効期間を制御する必要がある状況で問題があります。例えば、再認証することなく、一度時間までのための接続を維持するために、認証されたユーザを可能にしながら、5分にキャッシュされた鍵材料の寿命を制限することが望ましいかもしれません。その結果、将来的には、追加属性は、キャッシュされたキーの寿命を制御するために指定することができます。これらの属性は、特定の状況でセッションタイムアウト属性の意味を変更することができます。
Since the TSK lifetime is often determined by authenticator resources, and the backend authentication server has no insight into the TSK derivation process by the principle of ciphersuite independence, it is not appropriate for the backend authentication server to manage any aspect of the TSK derivation process, including the TSK lifetime.
TSKの寿命は、多くの場合、オーセンティケータリソースによって決定され、バックエンド認証サーバは、暗号スイートの独立の原則により、TSKの導出過程に何の洞察力を持っていないので、バックエンド認証サーバは、TSKの導出プロセスのあらゆる側面を管理することは、適切ではありませんTSK寿命を含みます。
Lower-layer mechanisms can be used to enable the lifetime of keying material to be negotiated between the peer and authenticator. This can be accomplished either using the Secure Association Protocol or within the lower-layer transport.
下層機構は、ピアとオーセンティケータとの間で交渉される鍵材料の寿命を可能にするために使用することができます。これは、セキュアアソシエーションプロトコルを使用して、または下層のトランスポート内のいずれかで達成することができます。
Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include support for TSK re-key. Where the TSK is taken directly from the MSK, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime are identical.
TSKsがセキュア協会プロトコル交換の結果として確立されている場合は、セキュア協会プロトコルは、TSKの再キーのサポートを含めることをお勧めします。 TSKは、MSKから直接取得されるTSK寿命とMSKの寿命が同じであるため、別個のパラメータとしてTSK寿命を管理する必要がありません。
As noted in [RFC3748] Section 7.10:
[RFC3748]セクション7.10に述べたように：
In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server.
その後に交渉暗号スイートで使用するための鍵材料を提供するために、鍵導出をサポートするEAP方式は、少なくとも64オクテットの少なくとも64オクテットのマスターセッションキー（MSK）、および拡張マスターセッションキー（EMSK）をエクスポートする必要があります。鍵を導出するEAPメソッドは、EAPピアとEAPサーバ間の相互認証のために提供しなければなりません。
However, EAP does not itself support the negotiation of lifetimes for exported EAP keying material such as the MSK, EMSK, and IV.
ただし、EAPは、それ自体は、MSK、EMSK、およびIVとしてエクスポートEAPキーイング材料のための寿命のネゴシエーションをサポートしていません。
While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on key lifetime negotiation within EAP methods would only function with these methods. Also, there is no guarantee that the key lifetime negotiated within the EAP method would be compatible with backend authentication server policy. In the interest of method independence and compatibility with backend authentication server implementations, management of the lifetime of keying material SHOULD NOT be provided within EAP methods.
EAP自体は生涯ネゴシエーションをサポートしていませんが、やる方法を指定することも可能です。しかし、EAPメソッド内キーの有効期間の交渉に依存しているシステムにのみ、これらの方法で機能するであろう。また、EAPメソッド内で交渉キーの有効期間は、バックエンド認証サーバのポリシーと互換性があるだろうという保証はありません。バックエンド認証サーバの実装と方法の独立性と互換性の関心では、材料をキーイングの寿命の管理は、EAPメソッド内で提供されるべきではありません。
Key lifetime negotiation alone cannot guarantee key cache synchronization. Even where a lower-layer exchange is run immediately after EAP in order to determine the lifetime of keying material, it is still possible for the authenticator to purge all or part of the key cache prematurely (e.g., due to reboot or need to reclaim memory).
単独のキーの有効期間の交渉は、キーキャッシュの同期を保証することはできません。下層交換は材料をキーイングの寿命を決定するために、EAPの直後に実行された場合であっても、認証が途中でキーキャッシュの全部または一部をパージするために、それはまだ可能です（再起動したり、メモリを再利用するために必要とするなど、原因）。
The lower layer can utilize the Discovery phase 0 to improve key cache synchronization. For example, if the authenticator manages the key cache by deleting the oldest key first, the relative creation time of the last key to be deleted could be advertised within the Discovery phase, enabling the peer to determine whether keying material had been prematurely expired from the authenticator key cache.
下の層は、キーキャッシュの同期化を改善するために、ディスカバリー・フェーズ0を利用することができます。オーセンティケータは最も古いキーを削除することにより、キーキャッシュを管理する場合、例えば、削除する最後のキーの相対的な作成時間は、鍵材料が途中から有効期限が切れていたかどうかを判断するためにピアを有効にする、発見フェーズ中に宣伝することができオーセンティケータキーキャッシュ。
As noted in Section 2.1, EAP lower layers determine TSKs in different ways. Where exported EAP keying material is utilized in the derivation, encryption or authentication of TSKs, it is possible for EAP key generation to represent the weakest link.
セクション2.1で述べたように、EAP下位レイヤは、異なる方法でTSKsを決定します。エクスポートされたEAPキーイング材料はTSKsの導出、暗号化や認証に利用されている場合はEAP鍵の生成が最も弱いリンクを表現することが可能です。
In order to ensure that methods produce EAP keying material of an appropriate symmetric key strength, it is RECOMMENDED that EAP methods utilizing public key cryptography choose a public key that has a cryptographic strength providing the required level of attack resistance. This is typically provided by configuring EAP methods, since there is no coordination between the lower layer and EAP method with respect to minimum required symmetric key strength.
方法は、適切な対称鍵強度のEAPキーイングマテリアルを生成することを確実にするためには、公開鍵暗号を利用するEAPメソッドは、攻撃性の必要なレベルを提供する暗号化強度を有している公開鍵を選択することを推奨されています。最低限必要な対称キー強度に対する下層とEAPメソッド間には連携が存在しないので、これは、典型的には、EAPメソッドを構成することによって提供されます。
Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
BCP 86 [RFC3766]のセクション5は、ビットで攻撃耐性の所与のレベルに対して、ビットに必要なRSA上の助言やDHモジュールとDSAサブグループサイズを提供します。標準技術研究所（NIST）は、[SP800-57]で適切なキーのサイズについてアドバイスを提供しています。
The key wrap specified in [RFC2548], which is based on an MD5-based stream cipher, has known problems, as described in [RFC3579] Section 4.3. RADIUS uses the shared secret for multiple purposes, including per-packet authentication and attribute hiding, considerable information is exposed about the shared secret with each packet. This exposes the shared secret to dictionary attacks. MD5 is used both to compute the RADIUS Response Authenticator and the Message-Authenticator Attribute, and concerns exist relating to the security of this hash [MD5Collision].
[RFC3579]セクション4.3に記載されているようにMD5ベースのストリーム暗号に基づいている[RFC2548]で指定されたキーラップは、問題が知られています。 RADIUSは、パケットごとの認証と属性の隠蔽を含む複数の目的のために共有秘密を使用して、かなりの情報は、各パケットと共有秘密について暴露されます。これは、辞書攻撃に共有秘密を公開します。 MD5は、RADIUS認証応答とMessage-Authenticatorアトリビュートを計算するために両方を使用している、との懸念が、このハッシュ[MD5Collision]のセキュリティに関連して存在します。
As discussed in [RFC3579] Section 4.3, the security vulnerabilities of RADIUS are extensive, and therefore development of an alternative key wrap technique based on the RADIUS shared secret would not substantially improve security. As a result, [RFC3579] Section 4.2 recommends running RADIUS over IPsec. The same approach is taken in Diameter EAP [RFC4072], which in Section 4.1.3 defines the EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to be protected by IPsec or TLS.
[RFC3579]セクション4.3で議論するように、RADIUSのセキュリティの脆弱性は広範であるため、RADIUSの共有秘密に基づいて別の主要な包装技術の開発は、実質的にセキュリティを改善しないであろう。結果として、[RFC3579]セクション4.2は、IPsec上にRADIUSを実行してお勧めします。同じアプローチはセクション4.1.3にIPSecまたはTLSによって保護されるクリアテキストにEAPマスターセッションキー属性値ペア（AVP）を定義直径EAP [RFC4072]に取り込まれます。
A handoff occurs when an EAP peer moves to a new authenticator. Several mechanisms have been proposed for reducing handoff latency within networks utilizing EAP. These include:
EAPピアは新しいオーセンティケータに移動するときにハンドオフが発生します。いくつかのメカニズムは、EAPを利用したネットワーク内のハンドオフの待ち時間を減らすために提案されています。これらは、次のとおりです。
EAP pre-authentication In EAP pre-authentication, an EAP peer pre-establishes EAP keying material with an authenticator prior to arrival. EAP pre-authentication only affects the timing of EAP authentication, but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) exchanges; Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges occur as described in Section 1.3. As a result, the primary benefit is to enable EAP authentication to be removed from the handoff critical path, thereby reducing latency. Use of EAP pre-authentication within IEEE 802.11 is described in [IEEE-802.11] and [8021XPreAuth].
EAP事前認証においてEAP事前認証は、EAPピア到着前にオーセンティケータとEAPキーイング材料を事前に確立します。 EAP事前認証は、EAP認証のタイミングに影響を与えるが、短縮またはEAP（フェーズ1a）又はAAA（フェーズ1b）の交換を排除しません。セクション1.3で説明したようにディスカバリ（位相0）とセキュアアソシエーションプロトコル（位相2）交換が起こります。その結果、主な利点は、それによって待ち時間を減少させる、ハンドオフのクリティカルパスから除去されるEAP認証を可能にすることです。 IEEE 802.11内のEAP事前認証の使用は[IEEE-802.11]と[8021XPreAuth]に記載されています。
Proactive key distribution In proactive key distribution, keying material and authorizations are transported from the backend authentication server to a candidate authenticator in advance of a handoff. As a result, EAP (phase 1a) is not needed, but the Discovery (phase 0), and Secure Association Protocol exchanges (phase 2) are still necessary. Within the AAA exchange (phase 1b), authorization and key distribution functions are typically supported, but not authentication. Proactive key distribution is described in [MishraPro], [IEEE-03-084], and [HANDOFF].
積極的な鍵配布において積極的な鍵配布、鍵材料及び権限は、ハンドオフの前に候補オーセンティケータにバックエンド認証サーバから搬送されています。その結果、EAP（フェーズ1a）は必要とされず、ディスカバリー（位相0）、およびセキュアアソシエーションプロトコル交換（フェーズ2）が依然として必要です。 AAA交換（フェーズ1B）内に、認可及び鍵配布機能は、典型的には、認証サポートではなく、。積極的な鍵配布は[IEEE-03から084]、および[ハンドオフ]、[MishraPro]に記載されています。
Key caching Caching of EAP keying material enables an EAP peer to re-attach to an authenticator without requiring EAP (phase 1a) or AAA (phase 1b) exchanges. However, Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges are still needed. Use of key caching within IEEE 802.11 is described in [IEEE-802.11].
EAPキーイングマテリアルのキーキャッシングキャッシングは、EAP（フェーズ1a）又はAAA（フェーズ1b）の交換を必要とせずに、オーセンティケータに再アタッチするEAPピアを可能にします。しかし、ディスカバリー（フェーズ0）およびSecure協会プロトコル（フェーズ2）交換がまだ必要とされています。 IEEE 802.11内のキーキャッシュの使用は[IEEE-802.11]に記載されています。
Context transfer In context transfer schemes, keying material and authorizations are transferred between a previous authenticator and a new authenticator. This can occur in response to a handoff request by the EAP peer, or in advance, as in proactive key distribution. As a result, EAP (phase 1a) is eliminated, but not the Discovery (phase 0) or Secure Association Protocol exchanges (phase 2). If a secure channel can be established between the new and previous authenticator without assistance from the backend authentication server, then the AAA exchange (phase 1b) can be eliminated; otherwise, it is still needed, although it can be shortened. Context transfer protocols are described in [IEEE-802.11F] (now deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067]. "Fast Authentication Methods for Handovers between IEEE 802.11 Wireless LANs" [Bargh] analyzes fast handoff techniques, including context transfer mechanisms.
コンテキスト転送方式、鍵材料及び権限のコンテキスト転送は前オーセンティケータと新しいオーセンティケータとの間で転送されます。これは積極的な鍵配布のように、EAPピアによってハンドオフ要求に応答して発生し、または事前にすることができます。その結果、EAP（フェーズ1a）は除去されるがないディスカバリー（位相0）またはセキュアアソシエーションプロトコル交換（フェーズ2）。セキュアチャネルは、バックエンド認証サーバからの支援なしに新しい及び前オーセンティケータとの間に確立することができる場合には、AAA交換（フェーズ1B）を排除することができます。それを短縮することができるが、そうでない場合、それはまだ、必要とされています。コンテキスト転送プロトコルは[IEEE-802.11F]に記載されている（廃止）と "コンテキスト転送プロトコル（CXTP）" [RFC4067]。 「IEEE 802.11無線LAN間のハンドオーバのための高速認証方式」[Bargh]はコンテキスト転送メカニズムを含む高速ハンドオフ技術を、分析します。
Token distribution In token distribution schemes, the EAP peer is provided with a credential, subsequently enabling it to authenticate with one or more additional authenticators. During the subsequent authentications, EAP (phase 1a) is eliminated or shortened; the Discovery (phase 0) and Secure Association Protocol exchanges (phase 2) still occur, although the latter can be shortened. If the token includes authorizations and can be validated by an authenticator without assistance from the backend authentication server, then the AAA exchange (phase 1b) can be eliminated; otherwise, it is still needed, although it can be shortened. Token-based schemes, initially proposed in early versions of IEEE 802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and [SHORT-TERM].
トークン分配スキームにおいてトークン分布は、EAPピアは、その後、1つのまたは複数の追加のオーセンティケータで認証することを可能にする、資格を備えています。後続の認証の際に、EAP（フェーズ1a）は排除または短縮されます。後者を短縮することができるが発見（位相0）とセキュアアソシエーションプロトコル交換（フェーズ2）は依然として起こります。トークンは、権限を含み、バックエンド認証サーバからの支援なしに、オーセンティケータによって検証することができる場合には、AAA交換（フェーズ1B）を排除することができます。それを短縮することができるが、そうでない場合、それはまだ、必要とされています。最初IEEE 802.11iの[IEEE-802.11i規格]の初期バージョンで提案されているトークンベースのスキームは、[Tokenk]、および[SHORT-TERM]、[トークン]に記載されています。
The sections that follow discuss the security vulnerabilities introduced by the above schemes.
上記のスキームによって導入されたセキュリティ上の脆弱性を議論する以下のセクション。
EAP pre-authentication differs from a normal EAP conversation primarily with respect to the lower-layer encapsulation. For example, in [IEEE-802.11], EAP pre-authentication frames utilize a distinct Ethertype, but otherwise conforms to the encapsulation described in [IEEE-802.1X]. As a result, an EAP pre-authentication conversation differs little from the model described in Section 1.3, other than the introduction of a delay between phase 1 and phase 2.
EAP事前認証は、主に下層のカプセル化に対して通常のEAPの会話とは異なります。例えば、[IEEE-802.11]で、EAP事前認証フレームは、別個のイーサタイプを利用するが、それ以外は[IEEE-802.1X]に記載のカプセル化に従います。その結果、EAP事前認証対話は、フェーズ1とフェーズ2の間の遅延の導入以外のセクション1.3に記載されたモデルから少し異なります。
EAP pre-authentication relies on lower-layer mechanisms for discovery of candidate authenticators. Where discovery can provide information on candidate authenticators outside the immediate listening range, and the peer can determine whether it already possesses valid EAP keying material with candidate authenticators, the peer can avoid unnecessary EAP pre-authentications and can establish EAP keying material well in advance, regardless of the coverage overlap between authenticators. However, if the peer can only discover candidate authenticators within listening range and cannot determine whether it can reuse existing EAP keying material, then it is possible that the peer will not be able to complete EAP pre-authentication prior to connectivity loss or that it can pre-authenticate multiple times with the same authenticator, increasing backend authentication server load.
EAP事前認証は、候補オーセンティケータの発見のための下層メカニズムに依存しています。発見はすぐにリスニングの範囲外の候補オーセンティケータに関する情報を提供することができ、およびピアは、それがすでに候補オーセンティケータで有効なEAPキーイング材料を有しているかどうかを判断できた場合、ピアは不要EAP事前認証を避けることができ、事前にEAPキーイング材料を確立することができ、かかわらず、オーセンティケータとの間のカバレッジオーバーラップ。ピアのみ聴取範囲内の候補オーセンティケータを発見することができ、それは既存のEAPキーイングマテリアルを再利用できるかどうかを判断することができない場合は、ピアが前の接続損失、またはそれができることEAP事前認証を完了できないことが可能ですバックエンド認証サーバ負荷を増大させる、同じオーセンティケータで複数回の事前認証します。
Since a peer can complete EAP pre-authentication with an authenticator without eventually attaching to it, it is possible that phase 2 will not occur. In this case, an Accounting-Request signifying the start of service will not be sent, or will only be sent with a substantial delay after the completion of authentication.
ピアが最終的に付着することなく、オーセンティケータとEAP事前認証を完了することができるので、第2相が発生しない可能性があります。この場合には、サービスの開始を意味アカウンティング要求が送信されないか、または唯一の認証が完了した後、実質的な遅延で送信されます。
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA exchange resulting from EAP pre-authentication differs little from an ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. For example, since in IEEE 802.11 [IEEE-802.11] an Association exchange does not occur prior to EAP pre-authentication, the SSID is not known by the authenticator at authentication time, so that an Access-Request cannot include the SSID within the Called-Station-Id attribute as described in [RFC3580] Section 3.20.
「IEEE 802.1X RADIUS使用上の注意事項」[RFC3580]で述べたように、EAP事前認証起因AAA交換は「EAPのためのRADIUSサポート」[RFC3579]に記載通常交換機から少し異なります。 IEEE 802.11の[IEEE-802.11]アソシエーション交換前EAP事前認証に生じないためアクセス要求が呼び出さ内のSSIDを含めないことができるように、例えば、SSIDは、認証時に認証者によって知られていません[RFC3580]セクション3.20に記載されているように-station-Id属性。
Since only the absence of an SSID in the Called-Station-Id attribute distinguishes an EAP pre-authentication attempt, if the authenticator does not always include the SSID for a normal EAP authentication attempt, it is possible that the backend authentication server will not be able to determine whether a session constitutes an EAP pre-authentication attempt, potentially resulting in authorization or accounting problems. Where the number of simultaneous sessions is limited, the backend authentication server can refuse to authorize a valid EAP pre-authentication attempt or can enable the peer to engage in more simultaneous sessions than they are authorized for. Where EAP pre-authentication occurs with an authenticator which the peer never attaches to, it is possible that the backend accounting server will not be able to determine whether the absence of an Accounting-Request was due to packet loss or a session that never started.
呼び出され-駅-Id属性でSSIDの唯一の不在はEAP事前認証の試みを区別するので、オーセンティケータは、常に通常のEAP認証の試行のためのSSIDが含まれていない場合、バックエンド認証サーバはされない可能性がありセッションが潜在的に許可またはアカウンティング問題が生じる、EAP事前認証の試みを構成するかどうかを決定することができます。同時セッションの数が限られている場合は、バックエンド認証サーバは、有効なEAP事前認証の試みを承認することを拒否することができますか彼らが認可されているよりも多くの同時セッションに従事するためにピアを有効にすることができます。 EAP事前認証は、ピアがに接続することはありませんオーセンティケータで発生した場合は、バックエンドアカウンティングサーバがアカウンティング要求の不在は、パケット損失または開始決してセッションによるものであったかどうかを決定することができない可能性があります。
In order to enable pre-authentication requests to be handled more reliably, it is RECOMMENDED that AAA protocols explicitly identify EAP pre-authentication. In order to suppress unnecessary EAP pre-authentication exchanges, it is RECOMMENDED that authenticators unambiguously identify themselves as described in Section 2.3.
より確実に処理されるように事前認証要求を有効にするためには、AAAプロトコルが明示的EAP事前認証を識別することを推奨されます。不要EAP事前認証交換を抑制するためには、セクション2.3で説明したようにオーセンティケータは、明確に自分自身を識別することが推奨されます。
In proactive key distribution schemes, the backend authentication server transports keying material and authorizations to an authenticator in advance of the arrival of the peer. The authenticators selected to receive the transported key material are selected based on past patterns of peer movement between authenticators known as the "neighbor graph". In order to reduce handoff latency, proactive key distribution schemes typically only demonstrate proof of possession of transported keying material between the EAP peer and authenticator. During a handoff, the backend authentication server is not provided with proof that the peer successfully authenticated to an authenticator; instead, the authenticator generates a stream of accounting messages without a corresponding set of authentication exchanges. As described in [MishraPro], knowledge of the neighbor graph can be established via static configuration or analysis of authentication exchanges. In order to prevent corruption of the neighbor graph, new neighbor graph entries can only be created as the result of a successful EAP exchange, and accounting packets with no corresponding authentication exchange need to be verified to correspond to neighbor graph entries (e.g., corresponding to handoffs between neighbors).
積極的な鍵配布方式において、バックエンド認証サーバは、ピアの到着の前にオーセンティケータに材料及び認可キーイング搬送します。輸送鍵材料を受信するように選択されたオーセンティケータは、「隣接グラフ」として知られているオーセンティケータとの間のピア・移動の過去のパターンに基づいて選択されます。ハンドオフ遅延を低減するために、積極的な鍵配布方式は、典型的に、EAPピアとオーセンティケータとの間の搬送キーイングマテリアルの所有の証拠を実証します。ハンドオフ中に、バックエンド認証サーバは、ピアが正常にオーセンティケータに認証することを証明して設けられていません。代わりに、オーセンティケータは、認証交換の対応するセットなしアカウンティングメッセージのストリームを生成します。 【MishraPro]に記載されているように、隣接グラフの知識は、認証交換の静的構成または分析を介して確立することができます。隣接グラフの破損を防ぐために、新しい隣人グラフエントリは唯一成功したEAP交換の結果として作成することができ、かつ、該当する認証交換とアカウンティングパケットはに対応し、例えば（ネイバーグラフの項目に対応するように検証する必要がありますネイバー間のハンドオフ）。
In order to prevent compromise of one authenticator from resulting in compromise of other authenticators, cryptographic separation needs to be maintained between the keying material transported to each authenticator. However, even where cryptographic separation is maintained, an attacker compromising an authenticator can still disrupt the operation of other authenticators. As noted in [RFC3579] Section 4.3.7, in the absence of spoofing detection within the AAA infrastructure, it is possible for EAP authenticators to impersonate each other. By forging NAS identification attributes within authentication messages, an attacker compromising one authenticator could corrupt the neighbor graph, tricking the backend authentication server into transporting keying material to arbitrary authenticators. While this would not enable recovery of EAP keying material without breaking fundamental cryptographic assumptions, it could enable subsequent fraudulent accounting messages, or allow an attacker to disrupt service by increasing load on the backend authentication server or thrashing the authenticator key cache.
他のオーセンティケータの妥協をもたらすから1つのオーセンティケータの妥協を防止するために、暗号化分離は各オーセンティケータに搬送鍵材料との間に維持される必要があります。しかし、暗号分離が維持されている場合でも、オーセンティケータを損なう攻撃者が、依然として他のオーセンティケータの動作を中断させることができます。 AAAインフラストラクチャ内スプーフィング検出の非存在下での[RFC3579]セクション4.3.7で述べたようにEAPオーセンティケータがお互いを偽装することが可能です。 NASの識別を鍛造することにより、認証メッセージ内の属性1つのオーセンティケータを損なう攻撃者が破損する可能性があり、隣接グラフ、任意のオーセンティケータへの鍵材料を輸送にバックエンド認証サーバをだまし。これは基本的な暗号化の仮定を壊すことなく、EAPキーイング材料の回復を有効にしないだろうが、それ以降の不正会計メッセージを有効にする、または攻撃者がバックエンド認証サーバの負荷を増大させることにより、サービスを中断またはオーセンティケータキーキャッシュをスラッシングする可能性があります。
Since proactive key distribution requires the distribution of derived keying material to candidate authenticators, the effectiveness of this scheme depends on the ability of backend authentication server to anticipate the movement of the EAP peer. Since proactive key distribution relies on backend authentication server knowledge of the neighbor graph, it is most applicable to intra-domain handoff scenarios. However, in inter-domain handoff, where there can be many authenticators, peers can frequently connect to authenticators that have not been previously encountered, making it difficult for the backend authentication server to derive a complete neighbor graph.
積極的な鍵配布は、候補オーセンティケータに由来鍵材料の分布を必要とするので、この方式の有効性は、EAPピアの動きを予測するためのバックエンド認証サーバの能力に依存します。積極的な鍵配布が隣接グラフのバックエンド認証サーバの知識に依存しているので、それは、ドメイン内のハンドオフのシナリオに最も適しています。バックエンド認証サーバが完全な隣接グラフを導出するためしかし、多くのオーセンティケータがあることができ、ドメイン間のハンドオフで、ピアが頻繁ことが困難になる、以前に遭遇していないオーセンティケータに接続することができます。
Since proactive key distribution schemes typically require introduction of server-initiated messages as described in [RFC5176] and [HANDOFF], security issues described in [RFC5176] Section 6 are applicable, including authorization (Section 6.1) and replay detection (Section 6.3) problems.
[RFC5176]と[ハンドオフ]に記載されているように積極的な鍵配布方式は、典型的には、サーバ起動メッセージの導入を必要とするので、[RFC5176]セクション6に記載されているセキュリティの問題は、認可（セクション6.1）とリプレイ検出（セクション6.3）の問題を含め、適用可能です。
Fast handoff techniques that enable elimination of the AAA exchange (phase 1b) differ fundamentally from typical network access scenarios (dial-up, wired LAN, etc.) that include user authentication as well as authorization for the offered service. Where the AAA exchange (phase 1b) is omitted, authorizations and keying material are not provided by the backend authentication server, and as a result, they need to be supplied by other means. This section describes some of the implications.
（フェーズ1B）AAA交換の除去を可能に高速ハンドオフ技術は、ユーザ認証だけでなく、提供されるサービスの許可を含む典型的なネットワーク・アクセス・シナリオ（等、有線LAN、ダイヤルアップ）とは根本的に異なります。 AAA交換（フェーズ1B）が省略された場合、認可及び鍵材料は、バックエンド認証サーバによって提供されず、結果として、それらは他の手段によって供給される必要があります。このセクションでは、意味合いのいくつかを説明しています。
Where transported keying material is not supplied by the backend authentication server, it needs to be provided by another party authorized to access that keying material. As noted in Section 1.5, only the EAP peer, authenticator, and server are authorized to possess transported keying material. Since EAP peers do not trust each other, if the backend authentication server does not supply transported keying material to a new authenticator, it can only be provided by a previous authenticator.
輸送鍵材料は、バックエンド認証サーバによって供給されていない場合は、その鍵素材にアクセスする権限を他の当事者によって提供される必要があります。セクション1.5で述べたように、唯一のEAPピア、オーセンティケータとサーバは、搬送キーイング材料を有することが許可されています。 EAPピアは互いを信頼していないので、バックエンド認証サーバは、新しいオーセンティケータに輸送鍵材料を供給しない場合には、それだけで前オーセンティケータによって提供することができます。
As noted in Section 1.5, the goal of the EAP conversation is to derive session keys known only to the peer and the authenticator. If keying material is replicated between a previous authenticator and a new authenticator, then the previous authenticator can possess session keys used between the peer and new authenticator. Also, the new authenticator can possess session keys used between the peer and the previous authenticator.
第1.5節で述べたように、EAPの会話の目標は、唯一のピアとオーセンティケータに知られているセッション鍵を導出することです。キーイング材料が前オーセンティケータと新しいオーセンティケータとの間で複製される場合、前オーセンティケータは、ピアと新しいオーセンティケータとの間で使用されるセッションキーを有することができます。また、新しいオーセンティケータは、ピアと前オーセンティケータ間で使用されるセッションキーを所有することができます。
If a one-way function is used to derive the keying material to be transported to the new authenticator, then the new authenticator cannot possess previous session keys without breaking a fundamental cryptographic assumption.
一方向関数は、新しいオーセンティケータに輸送されるキーイング材料を導出するために使用されている場合は、新しいオーセンティケータは、基本的な暗号化の仮定を壊すことなく、前のセッションキーを所有することはできません。
As a part of the authentication process, the backend authentication server determines the user's authorization profile and transmits the authorizations to the authenticator along with the transported keying material. Typically, the profile is determined based on the user identity, but a certificate presented by the user can also provide authorization information.
認証プロセスの一部として、バックエンド認証サーバは、ユーザの権限プロファイルを決定し、搬送キーイング材料と共にオーセンティケータに承認を送信します。典型的には、プロファイルは、ユーザーIDに基づいて決定されるが、ユーザーによって提示された証明書はまた、許可情報を提供することができます。
The backend authentication server is responsible for making a user authorization decision, which requires answering the following questions: (a) Is this a legitimate user of this network?
バックエンド認証サーバは、以下の質問に答える必要とする、ユーザー認証の決定を行うための責任がある：（a）は、これは、このネットワークの正当な利用者か？
(b) Is the user allowed to access this network?
（b）は、このネットワークにアクセスすることを許可されたユーザですか？
(c) Is the user permitted to access this network on this day and at this time?
（c）は、ユーザがこの日にして、この時点で、このネットワークにアクセスすることを許可されていますか？
(d) Is the user within the concurrent session limit?
（d）は、同時セッション制限内のユーザですか？
(e) Are there any fraud, credit limit, or other concerns that could lead to access denial?
（e）のいずれかの詐欺、信用限度、またはアクセス拒否につながる可能性がある他の問題はありますか？
(f) If access is to be granted, what are the service parameters (mandatory tunneling, bandwidth, filters, and so on) to be provisioned for the user?
アクセスが許可される場合（f）は、ユーザーにプロビジョニングするサービスパラメータ（必須トンネリング、帯域幅、フィルタなど）は何ですか？
While the authorization decision is, in principle, simple, the distributed decision making process can add complexity. Where brokers or proxies are involved, all of the AAA entities in the chain from the authenticator to the home backend authentication server are involved in the decision. For example, a broker can deny access even if the home backend authentication server would allow it, or a proxy can add authorizations (e.g., bandwidth limits).
認可判断ですが、原則的には、簡単な、分散型の意思決定プロセスは複雑さを追加することができます。ブローカーまたはプロキシが関与する場合、オーセンティケータからホームバックエンド認証サーバへのチェーンのAAAエンティティの全ては、決定に関与しています。たとえば、ブローカーは家庭用バックエンド認証サーバがそれを可能にする場合でも、アクセスを拒否することができ、またはプロキシは、権限（例えば、帯域幅制限）を追加することができます。
Decisions can be based on static policy definitions and profiles as well as dynamic state (e.g., time of day or concurrent session limits). In addition to the Accept/Reject decisions made by AAA entities, service parameters or constraints can be communicated to the authenticator.
決定は静的ポリシー定義とプロファイルならびに動的な状態（例えば、日または同時セッション限度の時間）に基づくことができます。 AAAエンティティ、サービスパラメータまたは制約によって作られた許可/拒否の決定に加えて、オーセンティケータに伝達することができます。
The criteria for Accept/Reject decisions or the reasons for choosing particular authorizations are typically not communicated to the authenticator, only the final result is. As a result, the authenticator has no way to know on what the decision was based. Was a set of authorization parameters sent because this service is always provided to the user, or was the decision based on the time of day and the capabilities of the authenticator?
許可/拒否の決定または特定の権限を選んだ理由のための基準は通常、オーセンティケータに伝達されず、最終的な結果のみです。その結果、オーセンティケータは、決定が基づいていたものに知る方法がありません。このサービスは、常に一日の時間と認証の機能に基づいて意思決定をユーザに提供する、またはでしたされているため、許可パラメータのセットが送られましたか？
When the AAA exchange (phase 1b) is bypassed, several challenges arise in ensuring correct authorization:
AAA交換（フェーズ1B）がバイパスされる場合、いくつかの課題が正しい権限を確実に生じます。
Theft of service Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to extend their network access or gain access to services they are not entitled to.
AAA交換をバイパスするサービスの盗難（フェーズ1bは）彼らのネットワークアクセスを拡張したり、それらがに資格を与えていないサービスへのアクセスを得るために、ユーザーを有効にしないでください。
Consideration of network-wide state Handoff techniques SHOULD NOT render the backend authentication server incapable of keeping track of network-wide state. For example, a backend authentication server can need to keep track of simultaneous user sessions.
ネットワーク全体の状態ハンドオフ技術の検討は、ネットワーク全体の状態を追跡することができないバックエンド認証サーバをレンダリングするべきではありません。例えば、バックエンド認証サーバは、同時ユーザーセッションを追跡する必要がありますすることができます。
Elevation of privilege Backend authentication servers often perform conditional evaluation, in which the authorizations returned in an Access-Accept message are contingent on the authenticator or on dynamic state such as the time of day. In this situation, bypassing the AAA exchange could enable unauthorized access unless the restrictions are explicitly encoded within the authorizations provided by the backend authentication server.
バックエンド認証サーバは、多くの場合、権限はAccess-Acceptメッセージで返され、条件付きの評価を行う特権の昇格は、オーセンティケータ上や時刻など動的な状態に偶発的です。制限が明示的にバックエンド認証サーバが提供する権限内にエンコードされていない限り、このような状況では、AAA交換をバイパスすることは、不正なアクセスを可能にすることができます。
A handoff mechanism that provides proper authorization is said to be "correct". One condition for correctness is as follows:
適切な権限を提供ハンドオフ機構が「正しい」と言われています。次のように正しさのための一つの条件は次のとおりです。
For a handoff to be "correct" it MUST establish on the new authenticator the same authorizations as would have been created had the new authenticator completed a AAA conversation with the backend authentication server.
ハンドオフが「正しい」ものにするための新しいオーセンティケータは、バックエンド認証サーバとのAAAの会話を完了した作成されていたであろうと、それは新しいオーセンティケータに同じ権限を確立する必要があります。
A properly designed handoff scheme will only succeed if it is "correct" in this way. If a successful handoff would establish "incorrect" authorizations, it is preferable for it to fail. Where the supported services differ between authenticators, a handoff that bypasses the backend authentication server is likely to fail. Section 1.1 of [RFC2865] states:
それは、このように「正しい」であれば、適切に設計されたハンドオフ方式が唯一成功します。成功したハンドオフが「正しくない」の権限を確立する場合、それは失敗することが望ましいです。サポートされているサービスは、認証デバイス間で異なる場合は、バックエンド認証サーバをバイパスハンドオフは失敗する可能性があります。 [RFC2865]のセクション1.1で述べています：
A authenticator that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a authenticator that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A authenticator MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead.
指定されたサービスを実装していないオーセンティケータは、そのサービスのRADIUS属性を実装してはなりません。たとえば、RADIUSを実装してはならないARAPサービスを提供することができませんオーセンティケータは、ARAPの属性。オーセンティケータは、RADIUSの代わりに、拒否アクセスとして利用できないサービスを許可するアクセスは、受け入れ扱わなければなりません。
This behavior applies to attributes that are known, but not implemented. For attributes that are unknown, Section 5 of [RFC2865] states:
この動作は、知られている属性に適用されますが、実装されていません。未知の属性については、[RFC2865]のセクション5は述べて：
A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type.
RADIUSサーバは、未知のタイプと属性を無視するかもしれません。 RADIUSクライアントは、未知のタイプと属性を無視するかもしれません。
In order to perform a correct handoff, if a new authenticator is provided with RADIUS authorizations for a known but unavailable service, then it MUST process these authorizations the same way it would handle a RADIUS Access-Accept requesting an unavailable service; this MUST cause the handoff to fail. However, if a new authenticator is provided with authorizations including unknown attributes, then these attributes MAY be ignored. The definition of a "known but unsupported service" MUST encompass requests for unavailable security services. This includes vendor-specific attributes related to security, such as those described in [RFC2548]. Although it can seem somewhat counter-intuitive, failure is indeed the "correct" result where a known but unsupported service is requested.
新しいオーセンティケータが知られているが、利用できないサービスのためのRADIUS認可が備えられている場合は、正しいハンドオフを実行するためには、それはこれらの権限にそれが利用できないサービスを要求するアクセス承認RADIUSを処理するのと同じ方法で処理しなければなりません。これは、ハンドオフが失敗する可能性がなければなりません。新しいオーセンティケータは、未知の属性を含む権限を備えている場合には、これらの属性は無視されるかもしれません。 「知られているが、サポートされていないサービス」の定義には使用できないセキュリティサービスの要求を包含しなければなりません。これは、[RFC2548]に記載されているような、セキュリティに関連するベンダー固有の属性を含みます。それはやや直感に反するように見えることができますが、障害が実際に知られているが、サポートされていないサービスが要求された「正しい」結果です。
Presumably, a correctly configured backend authentication server would not request that an authenticator provide a service that it does not implement. This implies that if the new authenticator were to complete a AAA conversation, it would be likely to receive different service instructions. Failure of the handoff is the desired result since it will cause the new authenticator to go back to the backend server in order to receive the appropriate service definition.
おそらく、正しく設定バックエンド認証サーバは、オーセンティケータは、それが実装されていないサービスを提供することを要求しないでしょう。これは、新しいオーセンティケータは、AAAの会話を完了した場合、異なるサービス命令を受信する可能性が高いだろうことを意味しています。それが適切なサービス定義を受け取るために、バックエンドサーバーに戻るために、新しいオーセンティケータの原因となりますので、ハンドオフの失敗は望ましい結果です。
Handoff mechanisms that bypass the backend authentication server are most likely to be successful when employed in a homogeneous deployment within a single administrative domain. In a heterogeneous deployment, the backend authentication server can return different authorizations depending on the authenticator making the request in order to make sure that the requested service is consistent with the authenticator capabilities. Where a backend authentication server would send different authorizations to the new authenticator than were sent to a previous authenticator, transferring authorizations between the previous authenticator and the new authenticator will result in incorrect authorization.
バックエンド認証サーバをバイパスハンドオフ・メカニズムは、単一の管理ドメイン内の均質な展開で使用される場合に成功する可能性が最も高いです。異機種間の配置では、バックエンド認証サーバは、要求されたサービスは、認証機能と一致していることを確認するために、要求を行う認証システムに応じて、異なる権限を返すことができます。どこにバックエンド認証サーバは、前オーセンティケータの間で権限を転送する、前オーセンティケータに送信され、新しいオーセンティケータが間違っ承認につながるよりも、新しいオーセンティケータに異なる権限を送信します。
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS support for dynamic VLANs is described in [RFC3580] and [RFC4675]. If some authenticators support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier) could be examined by the backend authentication server to determine when VLAN attributes will be returned, and if so, which ones. However, if the backend authenticator is bypassed, then a handoff occurring between authenticators supporting different VLAN capabilities could result in a user obtaining access to an unauthorized VLAN (e.g., a user with access to a guest VLAN being given unrestricted access to the network).
仮想LAN（VLAN）のサポートは[IEEE-802.1Q]で定義されています。動的VLANのRADIUSサポートは、[RFC3580]及び[RFC4675]に記載されています。他の人がいない間、いくつかのオーセンティケータは、ダイナミックVLANをサポートしている場合、それまでに調べることができ（例えばNASポート型、NAS-IP-アドレス、NAS-IPv6にアドレス、およびNAS-識別子など）アクセス要求に存在する属性バックエンド認証サーバは、VLANの属性が返されます際に決定し、もしそうなら、どれにします。バックエンド認証がバイパスされる場合は、その後、異なるVLAN機能をサポートしているオーセンティケータとの間に発生するハンドオフは、不正なVLAN（例えば、ゲストVLANへのアクセス権を持つユーザがネットワークへの無制限のアクセスを与えられる）へのユーザー得るアクセスが生じる可能性があります。
Similarly, it is preferable for a handoff between an authenticator providing confidentiality and another that does not to fail, since if the handoff were successful, the user would be moved from a secure to an insecure channel without permission from the backend authentication server.
同様に、ハンドオフが成功した場合、ユーザは、バックエンド認証サーバからの許可なしに安全でないチャネルをセキュアから移動されるので、失敗しない別のオーセンティケータ提供機密間のハンドオフのために好適であると。
The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (known as "security claims") are described in [RFC3748] Section 7.2.1. EAP method requirements for applications such as Wireless LAN authentication are described in [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579], Sections 4.2 and 4.3.
EAPの脅威モデルは、[RFC3748]セクション7.1に記載されています。 （「セキュリティクレーム」としても知られる）EAPメソッドのセキュリティプロパティは、[RFC3748]セクション7.2.1に記載されています。このような無線LAN認証などの用途のためのEAPメソッド要件は[RFC4017]に記載されています。 RADIUSの脅威モデルは、[RFC3579]セクション4.1に記載されており、これらの脅威への対応は、[RFC3579]のセクション4.2および4.3に記載されています。
However, in addition to threats against EAP and AAA, there are other system level threats. In developing the threat model, it is assumed that:
しかしながら、EAP及びAAAに対して脅威に加えて、他のシステム・レベルの脅威があります。脅威モデルを開発するには、それが想定されます。
All traffic is visible to the attacker. The attacker can alter, forge, or replay messages. The attacker can reroute messages to another principal. The attacker can be a principal or an outsider. The attacker can compromise any key that is sufficiently old.
すべてのトラフィックは、攻撃者に見えます。攻撃者は、変更偽造、またはメッセージを再生することができます。攻撃者は、別のプリンシパルにメッセージを再ルーティングすることができます。攻撃者は、プリンシパルまたは部外者であることができます。攻撃者は、十分に古いです、任意のキーを妥協することができます。
Threats arising from these assumptions include:
これらの仮定に起因する脅威は、次のとおりです。
(a) An attacker can compromise or steal an EAP peer or authenticator, in an attempt to gain access to other EAP peers or authenticators or to obtain long-term secrets.
（a）は、攻撃者が侵害または他のEAPピアまたはオーセンティケータにアクセスするために、または長期の秘密を得るための試みにおいて、EAPピアまたはオーセンティケータを盗むことができます。
(b) An attacker can attempt a downgrade attack in order to exploit known weaknesses in an authentication method or cryptographic algorithm.
（b）は、攻撃者が認証方法や暗号アルゴリズムにおける既知の脆弱性を利用するためにダウングレード攻撃を試みることができます。
(c) An attacker can try to modify or spoof packets, including Discovery or Secure Association Protocol frames, EAP or AAA packets.
（c）は、攻撃者が発見またはSecure協会プロトコルは、フレーム、EAPまたはAAAパケットを含むパケットを、変更したり、なりすましを試みることができます。
(d) An attacker can attempt to induce an EAP peer, authenticator, or server to disclose keying material to an unauthorized party, or utilize keying material outside the context that it was intended for.
（D）攻撃者が不正者に鍵材料を開示、又はそれを意図したコンテキスト外材料を合わせる利用するEAPピア、オーセンティケータ、またはサーバを誘導することを試みることができます。
(e) An attacker can alter, forge, or replay packets.
（E）攻撃者は、偽造変更、またはパケットを再生することができます。
(f) An attacker can cause an EAP peer, authenticator, or server to reuse a stale key. Use of stale keys can also occur unintentionally. For example, a poorly implemented backend authentication server can provide stale keying material to an authenticator, or a poorly implemented authenticator can reuse nonces.
（f）は、攻撃者は、EAPピア、オーセンティケータ、またはサーバが古いキーを再利用させることができます。古い鍵の使用も意図せずに発生することがあります。例えば、不完全に実装バックエンド認証サーバは、認証に失効キーイング材料を提供することができ、又は難実施オーセンティケータは、ナンスを再利用することができます。
(g) An authenticated attacker can attempt to obtain elevated privilege in order to access information that it does not have rights to.
（g）に認証された攻撃者は、それが権利を持っていないという情報にアクセスするために、システム特権を取得しようとすることができます。
(h) An attacker can attempt a man-in-the-middle attack in order to gain access to the network.
（H）攻撃者がネットワークにアクセスするためにman-in-the-middle攻撃を試みることができます。
(i) An attacker can compromise an EAP authenticator in an effort to commit fraud. For example, a compromised authenticator can provide incorrect information to the EAP peer and/or server via out-of-band mechanisms (such as via a AAA or lower-layer protocol). This includes impersonating another authenticator, or providing inconsistent information to the peer and EAP server.
（I）攻撃者が不正行為をコミットするための努力でEAP認証を危うくすることができます。例えば、損なわオーセンティケータは、（例えば、AAAまたは下位層プロトコルを介して）アウトオブバンド機構を介してEAPピア及び/またはサーバーに誤った情報を提供することができます。これは、別のオーセンティケータになりすまし、またはピアとEAPサーバに一貫性のない情報を提供することを含みます。
(j) An attacker can launch a denial-of-service attack against the EAP peer, authenticator, or backend authentication server.
（j）は、攻撃者は、EAPピア、オーセンティケータ、またはバックエンド認証サーバに対するサービス拒否攻撃を仕掛けることができます。
In order to address these threats, [RFC4962] Section 3 describes required and recommended security properties. The sections that follow analyze the compliance of EAP methods, AAA protocols, and Secure Association Protocols with those guidelines.
これらの脅威に対処するために、[RFC4962]セクション3は必須であり、推奨されるセキュリティのプロパティについて説明します。以下のセクションでは、EAP方式、AAAプロトコルのコンプライアンスを分析し、これらのガイドラインに協会のプロトコルを固定します。
Requirement: In the event that an authenticator is compromised or stolen, an attacker can gain access to the network through that authenticator, or can obtain the credentials needed for the authenticator/AAA client to communicate with one or more backend authentication servers. Similarly, if a peer is compromised or stolen, an attacker can obtain credentials needed to communicate with one or more authenticators. A mandatory requirement from [RFC4962] Section 3:
要件：オーセンティケータが侵害または盗難された場合には、攻撃者はその認証システムを介してネットワークへのアクセスを得ることができ、あるいは1つまたは複数のバックエンド認証サーバとの通信にオーセンティケータ/ AAAクライアントのために必要な資格を取得することができます。ピアが損なわれたり盗まれたりした場合も同様に、攻撃者は、一つ以上のオーセンティケータと通信するために必要な資格を得ることができます。 [RFC4962]セクション3から必須要件：
Prevent the Domino effect
ドミノ効果を防ぎます
Compromise of a single peer MUST NOT compromise keying material held by any other peer within the system, including session keys and long-term keys. Likewise, compromise of a single authenticator MUST NOT compromise keying material held by any other authenticator within the system. In the context of a key hierarchy, this means that the compromise of one node in the key hierarchy must not disclose the information necessary to compromise other branches in the key hierarchy. Obviously, the compromise of the root of the key hierarchy will compromise all of the keys; however, a compromise in one branch MUST NOT result in the compromise of other branches. There are many implications of this requirement; however, two implications deserve highlighting. First, the scope of the keying material must be defined and understood by all parties that communicate with a party that holds that keying material. Second, a party that holds keying material in a key hierarchy must not share that keying material with parties that are associated with other branches in the key hierarchy.
単一ピアの妥協は、セッション鍵と長期キーを含むシステム内の他のピアによって保持された材料を、キーイング妥協してはいけません。同様に、単一オーセンティケータの妥協点は、システム内の他のオーセンティケータによって保持された鍵材料を妥協してはなりません。キー階層のコンテキストでは、これは、キー階層内の1つのノードの妥協がキー階層内の他のブランチを妥協するために必要な情報を開示していなければならないことを意味します。もちろん、キー階層のルートの妥協は、キーのすべてを妥協します。しかし、一方の分岐で妥協が他のブランチの妥協につながるなりません。この要件の多くの意味があります。しかし、2つの意味が強調に値します。まず、キーイング材料の範囲は、その鍵材料を保持している相手と通信するすべての当事者によって定義されたと理解されなければなりません。第二に、主要な階層構造に鍵材料を保持している当事者はキー階層内の他の支店に関連している政党で材料をキーイングすることを共有してはいけません。
Group keys are an obvious exception. Since all members of the group have a copy of the same key, compromise of any one of the group members will result in the disclosure of the group key.
グループキーは明らかに例外です。グループのすべてのメンバーが同じキーのコピーを持っているので、グループメンバーのいずれかの妥協は、グループキーの開示になります。
Some of the implications of the requirement are as follows:
次のような要件の意味は以下のとおりです。
Key Sharing In order to be able to determine whether keying material has been shared, it is necessary for the identity of the EAP authenticator (NAS-Identifier) to be defined and understood by all parties that communicate with it. EAP lower-layer specifications such as [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve key sharing.
キーイング材料が共有されているか否かを決定することができるように、鍵共有は、それと通信するすべての当事者によって定義され、理解されるべきEAP認証（NAS-識別子）の識別のために必要です。などEAP下位レイヤ仕様は[IEEE-802.11]、[IEEE-802.16eの]、[IEEE-802.1X]、のIKEv2 [RFC4306]、およびPPP [RFC1661]は鍵共有を伴いません。
AAA Credential Sharing AAA credentials (such as RADIUS shared secrets, IPsec pre-shared keys or certificates) MUST NOT be shared between AAA clients, since if one AAA client were compromised, this would enable an attacker to impersonate other AAA clients to the backend authentication server, or even to impersonate a backend authentication server to other AAA clients.
AAA資格共有AAA資格1つのAAAクライアントが危険にさらされた場合、これはバックエンド認証に他のAAAクライアントを偽装する攻撃を可能にするため、AAAクライアント間で共有されてはならない、（RADIUSは、IPsecの事前共有キーまたは証明書が秘密を共有するなど）サーバー、あるいは他のAAAクライアントへのバックエンド認証サーバーを偽装します。
Compromise of Long-Term Credentials An attacker obtaining keying material (such as TSKs, TEKs, or the MSK) MUST NOT be able to obtain long-term user credentials such as pre-shared keys, passwords, or private-keys without breaking a fundamental cryptographic assumption. The mandatory requirements of [RFC4017] Section 2.2 include generation of EAP keying material, capability to generate EAP keying material with 128 bits of effective strength, resistance to dictionary attacks, shared state equivalence, and protection against man-in-the-middle attacks.
長期資格情報の妥協点（例えばTSKs、のTEK、またはMSKなど）鍵材料を得た攻撃者が基本を壊すことなく、このような事前共有鍵、パスワード、またはプライベート・キーのような長期的なユーザーの資格情報を取得できないようにする必要があり暗号仮定。 [RFC4017]セクション2.2の必須の要件は、効果的な強さ、辞書攻撃に対する耐性、共有状態の等価、およびman-in-the-middle攻撃に対する保護の128ビットでEAPキーイングマテリアルを生成する能力をEAPキーイングマテリアルの生成を含みます。
Mandatory requirements from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Cryptographic algorithm independent
暗号アルゴリズムの独立しました
The AAA key management protocol MUST be cryptographic algorithm independent. However, an EAP method MAY depend on a specific cryptographic algorithm. The ability to negotiate the use of a particular cryptographic algorithm provides resilience against compromise of a particular cryptographic algorithm. Algorithm independence is also REQUIRED with a Secure Association Protocol if one is defined. This is usually accomplished by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. While highly desirable, the ability to negotiate key derivation functions (KDFs) is not required. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Note that without protection by IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does not meet this requirement, since the integrity protection algorithm cannot be negotiated.
AAAの鍵管理プロトコルは、暗号アルゴリズム独立していなければなりません。しかし、EAPメソッドは、特定の暗号アルゴリズムに依存してもよいです。特定の暗号アルゴリズムの使用を交渉する能力は、特定の暗号アルゴリズムの危殆に対する回復力を提供します。 1が定義されている場合、アルゴリズムの独立性は、セキュア協会プロトコルで必要になります。これは、通常、プロトコルにおけるアルゴリズム識別子およびパラメータを含むことによって、プロトコル仕様のアルゴリズムの要件を指定することによって達成されます。非常に望ましいが、鍵導出関数（KDFs）を交渉する能力が必要とされません。相互運用性のために、強制的に実装アルゴリズムの少なくとも一方スイートが選択されなければなりません。完全性保護アルゴリズムがネゴシエートすることができないので、[RFC3579]セクション4.2に記載されているようにIPSecで保護することなく、RADIUS [RFC2865]は、この要件を満たしていないことに留意されたいです。
This requirement does not mean that a protocol must support both public-key and symmetric-key cryptographic algorithms. It means that the protocol needs to be structured in such a way that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means that the protocol needs to be structured in such a way that multiple symmetric-key algorithms can be used whenever a symmetric-key algorithm is employed.
この要件は、プロトコルは、公開鍵と対称鍵暗号アルゴリズムの両方をサポートしなければならないという意味ではありません。これは、プロトコルは、公開鍵アルゴリズムが使用されるたびに、複数の公開鍵アルゴリズムを使用することができるように構成する必要があることを意味します。同様に、プロトコルは共通鍵暗号が使用されるたびに複数の対称鍵アルゴリズムを使用することができるように構成する必要があることを意味します。
Confirm ciphersuite selection
暗号スイートの選択を確認します
The selection of the "best" ciphersuite SHOULD be securely confirmed. The mechanism SHOULD detect attempted roll-back attacks.
「最高の」暗号スイートの選択が確実に確認すべきです。メカニズムが試みロールバック攻撃を検出する必要があります。
EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements and AAA protocols utilizing transmission-layer security are capable of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes the "protected ciphersuite negotiation" security claim that refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP method conversation, as well as to integrity protect the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP methods satisfying this security claim. Since TLS v1.2 [RFC5246] and IKEv2 [RFC4306] support negotiation of Key Derivation Functions (KDFs), EAP methods based on TLS or IKEv2 will, if properly designed, inherit this capability. However, negotiation of KDFs is not required by RFC 4962 [RFC4962], and EAP methods based on neither TLS nor IKEv2 typically do not support KDF negotiation.
トランスミッション・レイヤ・セキュリティを利用する[RFC4017]セクション2.2の必須要件およびAAAプロトコルを満足するEAPメソッドは、ダウングレード攻撃に対処することが可能です。 [RFC3748]セクション7.2.1は、暗号スイートネゴシエーションを保護するEAPメソッドの会話を保護するために使用される暗号の組み合わせ、ならびに完全性を交渉するEAPメソッドの能力を意味する「保護された暗号スイートネゴシエーション」セキュリティクレームを記載しています。 [RFC4017]セクション2.2は、このセキュリティクレームを満たすEAPメソッドを必要とします。適切に設計されている場合TLS v1.2の[RFC5246]と鍵導出関数（KDFs）のIKEv2の[RFC4306]のサポート交渉ので、TLSまたはIKEv2のEAPに基づく方法は、この機能を継承します。しかし、KDFsの交渉は、RFC 4962 [RFC4962]によって必要とされていない、とTLSもIKEv2のどちらに基づいて、EAP方法は、典型的には、KDFネゴシエーションをサポートしていません。
When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for transmission layer security, they can leverage the cryptographic algorithm negotiation support provided by IKEv2 [RFC4306] or TLS [RFC5246]. RADIUS [RFC3579] by itself does not support cryptographic algorithm negotiation and relies on MD5 for integrity protection, authentication, and confidentiality. Given the known weaknesses in MD5 [MD5Collision], this is undesirable, and can be addressed via use of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
AAAプロトコルは、送信レイヤ・セキュリティのためのTLS [RFC5246]やIPsec [RFC4301]を使用する場合、それらはのIKEv2 [RFC4306]またはTLS [RFC5246]により提供される暗号アルゴリズムネゴシエーションサポートを活用することができます。それ自体でRADIUS [RFC3579]は、暗号アルゴリズムのネゴシエーションをサポートし、完全性保護、認証、および機密保持のためにMD5に依存していません。 MD5 [MD5Collision]で公知の弱点を与え、これは望ましくない、と[RFC3579]セクション4.2に記載されているように、IPsecの上にRADIUSを使用することによって対処することができます。
To ensure against downgrade attacks within lower-layer protocols, algorithm independence is REQUIRED with lower layers using EAP for key derivation. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Lower-layer protocols supporting EAP for key derivation SHOULD also support secure ciphersuite negotiation as well as KDF negotiation.
下位層プロトコル内のダウングレード攻撃を確実にするために、アルゴリズムの独立性は、鍵導出のためにEAPを使用して下位層に必要になります。相互運用性のために、強制的に実装アルゴリズムの少なくとも一方スイートが選択されなければなりません。鍵導出のためのEAPをサポートする下位層プロトコルはまた、セキュアな暗号スイートの交渉だけでなく、KDFネゴシエーションをサポートする必要があります。
As described in [RFC1968], PPP ECP does not support secure ciphersuite negotiation. While [IEEE-802.16e] and [IEEE-802.11] support ciphersuite negotiation for protection of data, they do not support negotiation of the cryptographic primitives used within the Secure Association Protocol, such as message integrity checks (MICs) and KDFs.
[RFC1968]で説明したように、PPP ECPは、安全な暗号スイートのネゴシエーションをサポートしていません。データの保護のため[IEEE-802.16eの]と[IEEE-802.11]サポート暗号スイートのネゴシエーションは、彼らがそのようなメッセージの整合性チェック（MIC）があるかとKDFsなどの安全な協会プロトコル内で使用される暗号プリミティブのネゴシエーションをサポートしていませんが。
Mandatory requirements from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Authenticate all parties
すべての当事者を認証します
Each party in the AAA key management protocol MUST be authenticated to the other parties with whom they communicate. Authentication mechanisms MUST maintain the confidentiality of any secret values used in the authentication process. When a secure association protocol is used to establish session keys, the parties involved in the secure association protocol MUST identify themselves using identities that are meaningful in the lower-layer protocol environment that will employ the session keys. In this situation, the authenticator and peer may be known by different identifiers in the AAA protocol environment and the lower-layer protocol environment, making authorization decisions difficult without a clear key scope. If the lower-layer identifier of the peer will be used to make authorization decisions, then the pair of identifiers associated with the peer MUST be authorized by the authenticator and/or the AAA server.
AAAの鍵管理プロトコルにおける各当事者は、彼らが通信誰と他の当事者に認証される必要があります。認証メカニズムは、認証プロセスで使用される任意の秘密の値の機密性を維持しなければなりません。安全な協会プロトコルは、セッションキーを確立するために使用された場合は、安全な協会プロトコルに関わる当事者はセッションキーを採用する下位層プロトコル環境で意味のあるIDを使用して自分自身を特定しなければなりません。この状況では、オーセンティケータとピアはクリアキースコープなし難しい許可決定を行う、AAAプロトコル環境と下位層プロトコル環境における異なる識別子によって知られていてもよいです。ピアの下層識別子が承認の判断を行うために使用される場合、ピアに関連付けられた識別子のペアは、認証および/またはAAAサーバによって承認されなければなりません。
AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators.
このようなRADIUS [RFC2865]とDiameter [RFC3588]などのAAAプロトコルは、AAAクライアントの識別のためのメカニズムを提供します。 EAP認証およびAAAクライアントは常に共存しているので、このメカニズムは、EAP認証者の識別に適用されます。
When multiple base stations and a "controller" (such as a WLAN switch) comprise a single EAP authenticator, the "base station identity" is not relevant; the EAP method conversation takes place between the EAP peer and the EAP server. Also, many base stations can share the same authenticator identity. The authenticator identity is important in the AAA protocol exchange and the secure association protocol conversation.
（例えばWLANスイッチのような）複数の基地局と「コントローラ」は、単一のEAP認証を含む場合、「基地局IDが」関連性はありません。 EAPメソッドの会話は、EAPピアとEAPサーバとの間で行われます。また、多くの基地局が同じオーセンティケータの同一性を共有することができます。オーセンティケータのアイデンティティは、AAAプロトコル交換と安全な協会プロトコル会話の中で重要です。
Authentication mechanisms MUST NOT employ plaintext passwords. Passwords may be used provided that they are not sent to another party without confidentiality protection.
認証メカニズムは、平文パスワードを使用してはなりません。使用できるパスワードは、彼らが機密性保護せずに、別の相手に送信されていないことを条件とします。
Keying material confidentiality and integrity
材料の機密性と完全性をキーイング
While preserving algorithm independence, confidentiality and integrity of all keying material MUST be maintained.
アルゴリズムの独立性を維持しながら、すべての鍵材料の機密性と完全性を維持しなければなりません。
Conformance to these requirements is analyzed in the sections that follow.
これらの要件への適合は、以下のセクションで分析されます。
Per-packet authentication and integrity protection provides protection against spoofing attacks.
パケットごとの認証と完全性保護は、スプーフィング攻撃に対する保護を提供します。
Diameter [RFC3588] provides support for per-packet authentication and integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides for per-packet authentication and integrity protection via use of the Message-Authenticator Attribute.
直径[RFC3588]はIPSecまたはTLSの使用を介して、パケットごとの認証と完全性保護のためのサポートを提供します。 RADIUS / EAP [RFC3579]はMessage-Authenticatorアトリビュートの使用を介して、パケットごとの認証と完全性保護のために用意されています。
[RFC3748] Section 7.2.1 describes the "integrity protection" security claim and [RFC4017] Section 2.2 requires EAP methods supporting this claim.
[RFC3748]セクション7.2.1は、「完全性保護」セキュリティクレームを記述[RFC4017]セクション2.2はこの主張をサポートするEAP方式が必要です。
In order to prevent forgery of Secure Association Protocol frames, per-frame authentication and integrity protection is RECOMMENDED on all messages. IKEv2 [RFC4306] supports per-frame integrity
セキュア協会プロトコルフレームの偽造を防ぐために、フレーム毎の認証と完全性保護は、すべてのメッセージに推奨されます。 IKEv2の[RFC4306]はフレーム毎の整合性をサポートしています
protection and authentication, as does the Secure Association Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame integrity protection and authentication on all messages within the 4-way handshake except the first message. An attack leveraging this omission is described in [Analysis].
保護や認証、[IEEE-802.16eの]で定義された安全協会プロトコルがそうであるように。 [IEEE-802.11]は最初のメッセージを除き、4ウェイハンドシェイク内のすべてのメッセージのフレームごとの完全性保護と認証をサポートしています。この省略を活かした攻撃は、[解析]に記載されています。
Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are potentially vulnerable to a rogue authenticator impersonating another authenticator. While both protocols support mutual authentication between the AAA client/authenticator and the backend authentication server, the security mechanisms vary.
RADIUS [RFC2865]とDiameter [RFC3588]の両方の実装では、別のオーセンティケータになりすます不正認証者に対して潜在的に脆弱です。両方のプロトコルは、AAAクライアント/オーセンティケータおよびバックエンド認証サーバ間の相互認証をサポートしていますが、セキュリティメカニズムが異なります。
In RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. However, when RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-Address, NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS server will not correspond to the source address. As noted in [RFC3579] Section 4.3.7, if the first-hop proxy does not check the NAS identification attributes against the source address in the Access-Request packet, it is possible for a rogue authenticator to forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or NAS-Identifier [RFC2865] attributes in order to impersonate another authenticator; attributes such as the Called-Station-Id [RFC2865] and Calling-Station-Id [RFC2865] can be forged as well. Among other things, this can result in messages (and transported keying material) being sent to the wrong authenticator.
RADIUSは、認証に使用される共有秘密は、RADIUSパケットの送信元アドレスによって決定されます。 RADIUSアクセス要求がプロキシによって転送されている場合しかし、RADIUSサーバが受信したNAS-IP-アドレス、NAS-識別子、またはNAS-IPv6のアドレス属性は、送信元アドレスに対応していません。 [RFC3579]セクション4.3.7で述べたように最初のホッププロキシがチェックしない場合、NASの識別は、アクセス要求パケットの送信元アドレスに対して属性不正オーセンティケータは、NAS-IP-アドレスを偽造することが可能です[ RFC2865]、NAS-のIPv6アドレス[RFC3162]、またはNAS-識別子[RFC2865]は、別のオーセンティケータを偽装するために属性。 [RFC2865]-駅-IDを呼び出すように呼び出され-駅-ID [RFC2865]などの属性とは、同様に偽造することができます。とりわけ、これは間違ったオーセンティケータに送信されるメッセージ（と輸送鍵材料）をもたらす可能性があります。
While [RFC3588] requires use of the Route-Record AVP, this utilizes Fully Qualified Domain Names (FQDNs), so that impersonation detection requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly configured. As a result, Diameter is as vulnerable to this attack as RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends mechanisms for impersonation detection; to prevent access to keying material by proxies without a "need to know", it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588].
[RFC3588]はルートレコードAVPの使用を必要としながら、その偽装検出を適切に設定するDNS A、AAAA、およびPTRリソースレコード（RR）を必要とするので、これは、完全修飾ドメイン名（FQDN）を利用します。その結果、直径がRADIUSとして、この攻撃に対して脆弱で、そうでない場合よりそうです。 [RFC3579]セクション4.3.7は、偽装検出のためのメカニズムをお勧めします。 「知る必要がある」ことなく、プロキシによってキーイング材料へのアクセスを防止するためには、例えば、[RFC3588]でサポートされているリダイレクト機能を介してのように、直接オーセンティケータと通信するバックエンド認証サーバを許可する必要があります。
It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This can enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via AAA or the lower layer).
妥協又は難実装EAP認証器がEAPピア及び/またはサーバーに誤った情報を通信することが可能です。これは、別のオーセンティケータを偽装または（例えばAAA又は下層を介して）アウトオブバンド機構を介して誤った情報を通信するためにオーセンティケータを可能にすることができます。
Where EAP is used in pass-through mode, the EAP peer does not verify the identity of the pass-through authenticator within the EAP conversation. Within the Secure Association Protocol, the EAP peer and authenticator only demonstrate mutual possession of the transported keying material; they do not mutually authenticate. This creates a potential security vulnerability, described in [RFC3748] Section 7.15.
EAPは、パススルーモードで使用される場合、EAPピアはEAP対話内パススルー認証者の身元を確認しません。セキュアアソシエーションプロトコル内、EAPピアとオーセンティケータは、搬送キーイング材料の相互所有を証明します。彼らは相互に認証されません。これは、[RFC3748]のセクション7.15で説明した潜在的なセキュリティの脆弱性を、作成します。
As described in [RFC3579] Section 4.3.7, it is possible for a first-hop AAA proxy to detect a AAA client attempting to impersonate another authenticator. However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the backend authentication server while communicating misleading information to the EAP peer via the lower layer.
[RFC3579]セクション4.3.7に記載のように、第1のホップAAAプロキシは別のオーセンティケータを偽装しようとAAAクライアントを検出することが可能です。しかし、下位層を介してEAPピアに誤解を招く情報を通信しながら、バックエンド認証サーバに正しい情報を提供するために、AAAクライアントとして機能するパススルー認証者のために可能です。
For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer. Also, a pass-through authenticator acting as a AAA client can provide an incorrect peer Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication server via the AAA protocol.
例えば、損なわオーセンティケータは、下位層を介してEAPピアと通信する際に別のオーセンティケータの着信ステーション-IDまたはNAS-識別子を利用することができます。また、AAAクライアントとして機能するパススルー認証システムは、AAAプロトコルを介してバックエンド認証サーバに[RFC2865] [RFC3580]-駅-IDを呼び出すと、誤ったピアを提供することができます。
As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865] [RFC3580], Calling-Station-Id [RFC2865] [RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162].
[RFC3748]セクション7.15に述べたように、この脆弱性は、このような（これらに限定されない）を含むエンドポイント識別子としてチャネル特性の保護交換をサポートするEAPメソッドによって対処することができる：着信ステーション-ID [RFC2865]、[RFC3580]、 [RFC2865] [RFC3580]、NAS-識別子[RFC2865]、NAS-IP-アドレス[RFC2865]、およびNAS-IPv6にアドレス[RFC3162]-駅-IDを呼び出します。
Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Typically, the EAP method imports channel binding parameters from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport can occur from EAP server to peer, or can be bi-directional. On the side of the exchange (peer or server) where channel binding is verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. For further discussion, see [EAP-SERVICE].
そのような保護された交換を使用して、EAPメソッド内で交換されたものに対して、アウトオブバンド機構を介してオーセンティケータによって提供されるチャネル特性を一致させることができます。典型的には、EAPメソッドの輸入は、ピア上の下位層から結合パラメータをチャネル、および下層又はAAA層にそれらをエクスポートするEAPサーバに安全に送信します。しかしながら、輸送は、ピア・ツーEAPサーバから発生することができ、または双方向であってもよいです。チャネル結合が確認されている交換機（ピアまたはサーバ）側で、下部層またはAAA層はEAPメソッドまで（TRUEまたはFALSE）検証の結果を渡します。検証は、ピアまたはサーバのいずれかを行うことができるが、典型的にのみサーバは、単にそれらの等価性を検証することとは対照的に、値の正確性を決定するための知識を有しています。さらなる議論に関しては、[EAP-SERVICE]を参照してください。
It is also possible to perform channel binding without transporting data over EAP, as described in [EAP-CHANNEL]. In this approach the EAP method includes channel binding parameters in the calculation of exported EAP keying material, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there is a mismatch in the channel binding parameters. However, this approach can only be applied where methods generating EAP keying material are used along with lower layers that utilize EAP keying material. For example, this mechanism would not enable verification of channel binding on wired IEEE 802 networks using [IEEE-802.1X].
[EAP-CHANNEL]に記載されているようにEAPを介してデータを搬送することなく、結合チャネルを行うことも可能です。このアプローチではEAPメソッドは、それが不可能なパラメータを結合チャネルの不整合がある場合、ピアとオーセンティケータは、セキュアアソシエーションプロトコルを完了できるようにすること、エクスポートされたEAPキーイング材料の計算におけるチャネル結合パラメータを含みます。 EAPキーイングマテリアルを生成する方法がEAPキーイングマテリアルを利用する下位層と共に使用される場合しかし、このアプローチは、適用することができます。例えば、このメカニズムは[IEEE-802.1X]を使用して有線IEEE 802ネットワークに結合チャネルの検証を有効にしないであろう。
[RFC3748] Section 7.2.1 describes the "mutual authentication" and "dictionary attack resistance" claims, and [RFC4017] requires EAP methods satisfying these claims. EAP methods complying with [RFC4017] therefore provide for mutual authentication between the EAP peer and server.
[RFC3748]セクション7.2.1は、「相互認証」と「辞書攻撃性」の特許請求の範囲、及び[RFC4017]を説明し、これらの特許請求の範囲を満足するEAPメソッドを必要とします。 [RFC4017]に準拠したEAPメソッドは、したがって、EAPピアとサーバ間の相互認証を提供します。
[RFC3748] Section 7.2.1 also describes the "Cryptographic binding" security claim, and [RFC4017] Section 2.2 requires support for this claim. As described in [EAP-BINDING], EAP method sequences and compound authentication mechanisms can be subject to man-in-the-middle attacks. When such attacks are successfully carried out, the attacker acts as an intermediary between a victim and a legitimate authenticator. This allows the attacker to authenticate successfully to the authenticator, as well as to obtain access to the network.
[RFC3748]セクション7.2.1にも「暗号バインディング」セキュリティクレーム、[RFC4017]セクション2.2を記述するには、この主張のためのサポートが必要です。 [EAP-BINDING]に記載されているように、EAPメソッド配列および化合物の認証メカニズムは、man-in-the-middle攻撃を受けることができます。このような攻撃が正常に行われている場合、攻撃者が被害者と合法的な認証システムとの間の仲介として機能します。これにより、攻撃者は、認証に成功し認証するために、だけでなく、ネットワークへのアクセスを得ることができます。
In order to prevent these attacks, [EAP-BINDING] recommends derivation of a compound key by which the EAP peer and server can prove that they have participated in the entire EAP exchange. Since the compound key MUST NOT be known to an attacker posing as an authenticator, and yet must be derived from EAP keying material, it MAY be desirable to derive the compound key from a portion of the EMSK. Where this is done, in order to provide proper key hygiene, it is RECOMMENDED that the compound key used for man-in-the-middle protection be cryptographically separate from other keys derived from the EMSK.
これらの攻撃を防ぐために、[EAP-BINDING]はEAPピアとサーバは、彼らが全体のEAP交換に参加したことを証明することが可能な複合キーの導出を推奨しています。複合キーをオーセンティケータとしてポーズ攻撃者に知られてはいけません、そしてまだEAPキーイングマテリアルから誘導されなければならないので、EMSKの部分からの化合物の鍵を導出することが望ましい場合があります。これが行われる場合には、適切なキー衛生を提供するために、のman-in-the-middle保護のために使用される化合物の鍵はEMSKから導出された他のキーと暗号的に別のことが推奨されます。
Diameter [RFC3588] provides for per-packet authentication and integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also provides for per-packet authentication and integrity protection. Where the authenticator/AAA client and backend authentication server communicate directly and credible key wrap is used (see Section 3.8), this ensures that the AAA Key Transport (phase 1b) achieves its security objectives: mutually authenticating the AAA client/authenticator and backend authentication server and providing transported keying material to the EAP authenticator and to no other party.
直径[RFC3588] IPSecまたはTLS、およびRADIUS / EAPを介してパケットごとの認証と完全性保護を提供する[RFC3579]もパケットごとの認証と完全性保護を提供します。相互AAAクライアント/オーセンティケータおよびバックエンド認証を認証：オーセンティケータ/ AAAクライアントとバックエンド認証サーバが直接通信し、信頼できるキーラップは（3.8節を参照）が使用される場合、これはAAAキートランスポート（フェーズ1bは）そのセキュリティ対策方針を実現することを保証しますサーバとEAP認証にしていない相手に運ば鍵材料を提供します。
[RFC2607] Section 7 describes the security issues occurring when the authenticator/AAA client and backend authentication server do not communicate directly. Where a AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, transported keying material can be recovered by an attacker in control of the intermediary. As discussed in Section 2.1, unless the TSKs are derived independently from EAP keying material (as in IKEv2), possession of transported keying material enables decryption of data traffic sent between the peer and the authenticator to whom the keying material was transported. It also allows the AAA intermediary to impersonate the authenticator or the peer. Since the peer does not authenticate to a AAA intermediary, it has no ability to determine whether it is authentic or authorized to obtain keying material.
[RFC2607]のセクション7は、認証/ AAAクライアントとバックエンド認証サーバが直接通信していないときに発生するセキュリティ上の問題について説明します。 AAA仲介は、（例えばRADIUSプロキシまたは直径剤として）存在し、データオブジェクトのセキュリティが使用されていない場合、輸送鍵材料は、中間の制御において、攻撃者によって回収することができます。セクション2.1で議論するようにTSKsは、独立して、（IKEv2のように）EAPキーイング材料から導出されなければ、輸送鍵材料の所持は、キーイング材料を搬送した人に、ピアとオーセンティケータとの間で送信されるデータトラフィックの復号化を可能にします。また、AAA仲介がオーセンティケータまたはピアを偽装することができます。ピアがAAA仲介に認証しないので、キーイング材料を得ることが本物又は許可されているか否かを決定する能力はありません。
However, as long as transported keying material or keys derived from it are only utilized by a single authenticator, compromise of the transported keying material does not enable an attacker to impersonate the peer to another authenticator. Vulnerability to compromise of a AAA intermediary can be mitigated by implementation of redirect functionality, as described in [RFC3588] and [RFC4072].
しかし、限り、それに由来する輸送鍵材料またはキーが単一のオーセンティケータによって利用されるように、輸送鍵材料の妥協は、別のオーセンティケータとピアを偽装する攻撃を可能にしません。 [RFC3588]及び[RFC4072]に記載されているようにAAA仲介の妥協に対する脆弱性は、リダイレクト機能を実装することによって緩和することができます。
The Secure Association Protocol does not provide for mutual authentication between the EAP peer and authenticator, only mutual proof of possession of transported keying material. In order for the peer to verify the identity of the authenticator, mutual proof of possession needs to be combined with impersonation prevention and channel binding. Impersonation prevention (described in Section 5.3.2) enables the backend authentication server to determine that the transported keying material has been provided to the correct authenticator. When utilized along with impersonation prevention, channel binding (described in Section 5.3.3) enables the EAP peer to verify that the EAP server has authorized the authenticator to possess the transported keying material. Completion of the Secure Association Protocol exchange demonstrates that the EAP peer and the authenticator possess the transported keying material.
セキュア協会プロトコルは、EAPピアとオーセンティケータ間の相互認証のために輸送鍵材料の所持の唯一の相互の証拠を提供していません。認証者の身元を確認するピアのために、所有の相互証明は、偽装防止及びチャネル結合と組み合わせることが必要です。なりすまし防止（5.3.2節で説明）が搬送キーイング材料を正しい認証者に提供されていることを決定するために、バックエンド認証サーバを可能にします。偽装防止、結合チャネル（セクション5.3.3を参照）EAPサーバが輸送鍵材料を有することがオーセンティケータを承認したことを確認するために、EAPピアを可能にすると共に利用される場合。セキュア協会プロトコル交換の完了は、EAPピアとオーセンティケータが輸送鍵材料を有することを示しています。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Bind key to its context
そのコンテキストにバインドキー
Keying material MUST be bound to the appropriate context. The context includes the following:
鍵材料は、適切なコンテキストにバインドする必要があります。コンテキストには、次のものが含まれます。
o The manner in which the keying material is expected to be used.
キーイング材料を使用することが期待される方法O。
o The other parties that are expected to have access to the keying material.
キーイング材料へのアクセスを有することが期待される他の当事者O。
o The expected lifetime of the keying material. Lifetime of a child key SHOULD NOT be greater than the lifetime of its parent in the key hierarchy.
キーイング材料の予想寿命O。子キーの有効期間は、キー階層内の親の寿命よりも大きくすべきではありません。
Any party with legitimate access to keying material can determine its context. In addition, the protocol MUST ensure that all parties with legitimate access to keying material have the same context for the keying material. This requires that the parties are properly identified and authenticated, so that all of the parties that have access to the keying material can be determined.
鍵材料への正当なアクセス権を持つ当事者は、そのコンテキストを決定することができます。また、プロトコルは、鍵材料をへの正当なアクセス権を持つすべての当事者が鍵素材のため、同じコンテキストを持っていることを確認しなければなりません。キーイング材料へのアクセス権を持つ当事者のすべてを決定することができるようにこれは、関係者が適切に識別・認証されている必要があります。
The context will include the peer and NAS identities in more than one form. One (or more) name form is needed to identify these parties in the authentication exchange and the AAA protocol. Another name form may be needed to identify these parties within the lower layer that will employ the session key.
コンテキストは、複数のフォームでのピアとNASのIDが含まれます。 1つ（またはそれ以上）の名前の形式は、認証交換とAAAプロトコルでこれらの当事者を識別するために必要とされます。別の名前の形式は、セッションキーを採用する下位層内でこれらの当事者を特定するために必要な場合があります。
Within EAP, exported keying material (MSK, EMSK,IV) is bound to the Peer-Id(s) and Server-Id(s), which are exported along with the keying material. However, not all EAP methods support authenticated server identities (see Appendix A).
EAP内、キーイング材料（MSK、EMSK、IV）はピアID（複数可）及びサーバID（s）は、キーイング材料と共にエクスポートさにバインドされてエクスポート。ただし、すべてのEAPメソッドが認証をサポートするサーバーのID（付録Aを参照してください）。
Within the AAA protocol, transported keying material is destined for the EAP authenticator identified by the NAS-Identifier Attribute within the request, and is for use by the EAP peer identified by the Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI) [RFC4372] attributes. The maximum lifetime of the transported keying material can be provided, as discussed in Section 3.5.1. Key usage restrictions can also be included as described in Section 3.2. Key lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.
ユーザ名[RFC2865]、AAAプロトコル内、輸送鍵材料は、リクエスト内のNAS-identifier属性によって識別されるEAP認証宛てて、ピアID（複数可）によって識別されるEAPピアによって使用するためのものです課金対象ユーザーアイデンティティ（CUI）[RFC4372]属性または。セクション3.5.1で説明したように搬送鍵材料の最大寿命を提供することができます。 3.2節で説明したように、キーの使用制限を含めることもできます。キーの有効期間の問題については、セクション3.3、3.4、および3.5で議論されています。
Requirement: The Secure Association Protocol (phase 2) conversation may utilize different identifiers from the EAP conversation (phase 1a), so that binding between the EAP and Secure Association Protocol identities is REQUIRED.
要件：EAPとセキュアアソシエーションプロトコルアイデンティティとの間の結合が必要であることにセキュアアソシエーションプロトコル（位相2）会話は、EAPの会話（位相1A）とは異なる識別子を利用してもよいです。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Peer and authenticator authorization
ピアとオーセンティケータ承認
Peer and authenticator authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED whenever a peer associates with a new authenticator. The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authenticator is detected.
ピアとオーセンティケータの承認を実行しなければなりません。これらのエンティティは、それを開示することなく、適切な鍵素材の所有を実証しなければなりません。認可は、新しいオーセンティケータといつでもピア仲間を必要としています。許可検査は特権攻撃の上昇を防ぎ、そしてそれが不正オーセンティケータが検出されることを保証します。
Authorizations SHOULD be synchronized between the peer, NAS, and backend authentication server. Once the AAA key management protocol exchanges are complete, all of these parties should hold a common view of the authorizations associated with the other parties.
承認は、ピア、NAS、およびバックエンド認証サーバの間で同期させなければなりません。 AAA鍵管理プロトコル交換が完了したら、これらの当事者のすべてが他の当事者に関連付けられた権限の共通のビューを保持する必要があります。
In addition to authenticating all parties, key management protocols need to demonstrate that the parties are authorized to possess keying material. Note that proof of possession of keying material does not necessarily prove authorization to hold that keying material. For example, within an IEEE 802.11, the 4-way handshake demonstrates that both the peer and authenticator possess the same EAP keying material. However, by itself, this possession proof does not demonstrate that the authenticator was authorized by the backend authentication server to possess that keying material. As noted in [RFC3579] in Section 4.3.7, where AAA proxies are present, it is possible for one authenticator to impersonate another, unless each link in the AAA chain implements checks against impersonation. Even with these checks in place, an authenticator may still claim different identities to the peer and the backend authentication server. As described in [RFC3748] Section 7.15, channel binding is required to enable the peer to verify that the authenticator claim of identity is both consistent and correct.
すべての関係者を認証することに加えて、鍵管理プロトコルは、当事者が鍵材料を有することが許可されていることを証明する必要があります。必ずしも材料をキーイングすることを保持するための権限を証明しない鍵材料の所持の証拠を注意してください。例えば、IEEE 802.11内で、4ウェイハンドシェイクは、ピアとオーセンティケータの両方が同じEAPキーイングマテリアルを有することを示しています。しかし、それ自体で、この所持の証拠は、オーセンティケータがその鍵素材を所有するバックエンド認証サーバによって承認されたことを示すものではありません。 AAAプロキシが存在するセクション4.3.7に[RFC3579]で述べたように、AAAチェーンの各リンクは、なりすましに対するチェックを実装しない限り、1つのオーセンティケータは、別のものを偽装することが可能です。でも、代わりにこれらのチェックで、オーセンティケータはまだピアとバックエンド認証サーバに異なるIDを請求することができます。 [RFC3748]セクション7.15に記載されているように、チャネル結合が同一のオーセンティケータ主張が一致し、正しい両方であることを確認するためにピアを可能にするために必要とされます。
Recommendation from [RFC4962] Section 3:
[RFC4962]セクション3からの提言：
Authorization restriction
認証制限
If peer authorization is restricted, then the peer SHOULD be made aware of the restriction. Otherwise, the peer may inadvertently attempt to circumvent the restriction. For example, authorization restrictions in an IEEE 802.11 environment include:
ピアの認証が制限されている場合、ピアは制限を認識してなされるべきです。そうでない場合、ピアは不注意制限を回避しようと試みることができます。例えば、IEEE 802.11環境における認証の制限は、次のとおりです。
o Key lifetimes, where the keying material can only be used for a certain period of time;
キーイング材料のみ一定期間のために使用することができるキーの有効期間、O。
o SSID restrictions, where the keying material can only be used with a specific IEEE 802.11 SSID;
キーイング材料のみ特定IEEE 802.11 SSIDと一緒に使用することができる入出力SSIDの制限;
o Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID; and
鍵材料は、単一のIEEE 802.11 BSSIDと使用することができる着信ステーション-ID制限、O。そして
o Calling-Station-ID restrictions, where the keying material can only be used with a single peer IEEE 802 MAC address.
鍵材料は、単一のピアIEEE 802 MACアドレスを使用することができる発呼ステーション-ID制限、O。
As described in Section 2.3, consistent identification of the EAP authenticator enables the EAP peer to determine the scope of keying material provided to an authenticator, as well as to confirm with the backend authentication server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it.
セクション2.3で説明したように、EAP認証の一貫した識別がオーセンティケータに提供する鍵材料の範囲を決定するために、EAPピアを可能にする、並びにがEAP認証中EAPキーイングマテリアルの所有を証明するバックエンド認証サーバで確認しますセキュア協会プロトコルは、それを得ることが承認されました。
Within the AAA protocol, the authorization attributes are bound to the transported keying material. While the AAA exchange provides the AAA client/authenticator with authorizations relating to the EAP peer, neither the EAP nor AAA exchanges provide authorizations to the EAP peer. In order to ensure that all parties hold the same view of the authorizations, it is RECOMMENDED that the Secure Association Protocol enable communication of authorizations between the EAP authenticator and peer.
AAAプロトコル内で、許可属性が運ばキーイング材料に結合されています。 AAA交換は、EAPピアに関連する権限を持つAAAのクライアント/認証システムを提供していますが、どちらもEAPもAAA交換は、EAPピアに権限を与えません。すべての当事者は、権限の同じビューを保持することを確実にするためには、セキュアアソシエーションプロトコルがEAPオーセンティケータとピアとの間の権限の通信を可能にすることが推奨されます。
In lower layers where the authenticator consistently identifies itself to the peer and backend authentication server and the EAP peer completes the Secure Association Protocol exchange with the same authenticator through which it completed the EAP conversation, authorization of the authenticator is demonstrated to the peer by mutual authentication between the peer and authenticator as discussed in the previous section. Identification issues are discussed in Sections 2.3, 2.4, and 2.5 and key scope issues are discussed in Section 3.2.
下位層にオーセンティケータは、一貫してピアとバックエンド認証サーバに対して自身を識別し、EAPピアは、それがEAPの会話を終え、それを通して同じオーセンティケータとのセキュアアソシエーションプロトコル交換を完了した場合、オーセンティケータの許可は、相互認証によってピアに実証されています前のセクションで説明したように、ピアとオーセンティケータの間です。識別の問題は、セクション2.3で2.4、および2.5に議論され、キー範囲の問題は、3.2節で議論されています。
Where the EAP peer utilizes different identifiers within the EAP method and Secure Association Protocol conversations, peer authorization can be difficult to demonstrate to the authenticator without additional restrictions. This problem does not exist in IKEv2 where the Identity Payload is used for peer identification both within IKEv2 and EAP, and where the EAP conversation is cryptographically protected within IKEv2 binding the EAP and IKEv2 exchanges. However, within [IEEE-802.11], the EAP peer identity is not used within the 4-way handshake, so that it is necessary for the authenticator to require that the EAP peer utilize the same MAC address for EAP authentication as for the 4-way handshake.
EAPピアがEAP方法およびSecure協会プロトコルの会話内の異なる識別子を利用する場合、ピア認可が追加の制限なしに、認証に証明することは困難です。この問題は、アイデンティティペイロードがピア識別の両方のIKEv2およびEAP内で使用されるのIKEv2に存在しない、およびEAPの会話を暗号EAPとIKEv2の交換結合のIKEv2内で保護されます。オーセンティケータはEAPピアが、4-用としてEAP認証のために同じMACアドレスを使用することを要求することが必要であるようしかし、[IEEE-802.11]内、EAPピアIDは、4ウェイハンドシェイク内で使用されていませんウェイハンドシェイク。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Replay detection mechanism
リプレイ検出メカニズム
The AAA key management protocol exchanges MUST be replay protected, including AAA, EAP and Secure Association Protocol exchanges. Replay protection allows a protocol message recipient to discard any message that was recorded during a previous legitimate dialogue and presented as though it belonged to the current dialogue.
AAA鍵管理プロトコル交換は、再生AAA、EAP及びセキュアアソシエーションプロトコル交換を含む、保護されなければなりません。リプレイ保護は前正当対話中に記録され、それが現在の会話に属しているかのように提示された任意のメッセージを廃棄するプロトコルメッセージの受信者を可能にします。
[RFC3748] Section 7.2.1 describes the "replay protection" security claim, and [RFC4017] Section 2.2 requires use of EAP methods supporting this claim.
[RFC3748]セクション7.2.1には、「リプレイ防御」セキュリティの主張を説明して、[RFC4017]セクション2.2はこの主張をサポートするEAPメソッドを使用する必要があります。
Diameter [RFC3588] provides support for replay protection via use of IPsec or TLS. "RADIUS Support for EAP" [RFC3579] protects against replay of keying material via the Request Authenticator. According to [RFC2865] Section 3:
直径[RFC3588]はIPSecまたはTLSの使用を介して再生保護のためのサポートを提供します。 「EAPのためのRADIUSサポート」[RFC3579]は要求認証を介して、鍵材料の再生に対する保護します。 [RFC2865]セクション3によると：
In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator.
アクセス要求パケットに、認証値は16オクテット乱数であり、要求認証と呼ばれます。
However, some RADIUS packets are not replay protected. In Accounting, Disconnect, and Care-of Address (CoA)-Request packets, the Request Authenticator contains a keyed Message Integrity Code (MIC) rather than a nonce. The Response Authenticator in Accounting, Disconnect, and CoA-Response packets also contains a keyed MIC whose calculation does not depend on a nonce in either the Request or Response packets. Therefore, unless an Event-Timestamp attribute is included or IPsec is used, it is possible that the recipient will not be able to determine whether these packets have been replayed. This issue is discussed further in [RFC5176] Section 6.3.
ただし、一部のRADIUSパケットは保護され、再生されていません。会計、切り離し、および気付アドレス（CoA） - 要求パケットでは、要求認証は、鍵付きメッセージ整合性コード（MIC）のではなくナンスが含まれています。会計、切断、およびCoAをレスポンスパケットのレスポンス認証はまた、その計算要求又は応答パケットのいずれかで一回だけに依存しないキー付きMICを含んでいます。イベント・タイムスタンプ属性が含まれているか、IPsecが使用されていない限り、したがって、受信者がこれらのパケットが再生されているかどうかを決定することができない可能性があります。この問題は、[RFC5176]セクション6.3でさらに議論されています。
In order to prevent replay of Secure Association Protocol frames, replay protection is REQUIRED on all messages. [IEEE-802.11] supports replay protection on all messages within the 4-way handshake; IKEv2 [RFC4306] also supports this.
セキュア協会プロトコルフレームの再生を防ぐために、再生保護は、すべてのメッセージで必要とされます。 [IEEE-802.11]は4ウェイハンドシェイク内のすべてのメッセージの再生保護をサポートしています。 IKEv2の[RFC4306]もこれをサポートしています。
Requirement: A session key SHOULD be considered compromised if it remains in use beyond its authorized lifetime. Mandatory requirement from [RFC4962] Section 3:
要件：それはその権限の寿命を越えて使用中のままであれば、セッション鍵が危険にさらさ考慮されるべきです。 [RFC4962]セクション3からの必須要件：
Strong, fresh session keys
強力な、新鮮なセッションキー
While preserving algorithm independence, session keys MUST be strong and fresh. Each session deserves an independent session key. Fresh keys are required even when a long replay counter (that is, one that "will never wrap") is used to ensure that loss of state does not cause the same counter value to be used more than once with the same session key.
アルゴリズムの独立性を維持しながら、セッション鍵が強く、新鮮でなければなりません。各セッションは独立したセッションキーに値します。新鮮なキーは、場合でも、長いリプレイカウンター要求されている（つまり、「ラップすることはありません」ということです）状態の損失は、同じセッションキーを複数回使用する同じカウンタ値を起こさないことを確実にするために使用されます。
Some EAP methods are capable of deriving keys of varying strength, and these EAP methods MUST permit the generation of keys meeting a minimum equivalent key strength. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
いくつかのEAPメソッドは、様々な強さの鍵を導出することが可能であり、これらのEAPメソッドは、最小同等のキー強度を満たす鍵の生成を可能にしなければなりません。 BCP 86 [RFC3766]は、適切なキーのサイズについてアドバイスを提供しています。標準技術研究所（NIST）は、[SP800-57]で適切なキーのサイズについてアドバイスを提供しています。
A fresh cryptographic key is one that is generated specifically for the intended use. In this situation, a secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material supplied as an input to session key derivation is fresh, and the secure association protocol MUST generate a separate session key for each session, even if the keying material provided by EAP is cached. A cached key persists after the authentication exchange has completed. For the AAA/EAP server, key caching can happen when state is kept on the server. For the NAS or client, key caching can happen when the NAS or client does not destroy keying material immediately following the derivation of session keys.
新鮮な暗号化キーは、意図された用途のために特別に生成されるものです。このような状況では、安全な協会プロトコルは、セッションキーを確立するために使用されます。 AAAプロトコル及びEAPメソッドは、セッションキー導出への入力として供給される鍵材料が新鮮であることを保証しなければならない、およびセキュアアソシエーションプロトコルがEAPによって提供される鍵材料がキャッシュされている場合でも、セッションごとに別個のセッション・キーを生成しなければなりません。認証交換が完了した後にキャッシュされたキーが持続します。状態は、サーバー上に保存されている場合、AAA / EAPサーバの場合は、キーキャッシュが発生する可能性があります。 NASまたはクライアントがすぐにセッションキーの導出、次の鍵材料を破壊しないときNASまたはクライアントの場合は、キーキャッシュが発生する可能性があります。
Session keys MUST NOT be dependent on one another. Multiple session keys may be derived from a higher-level shared secret as long as a one-time value, usually called a nonce, is used to ensure that each session key is fresh. The mechanism used to generate session keys MUST ensure that the disclosure of one session key does not aid the attacker in discovering any other session keys.
セッションキーは互いに依存しているはずがありません。複数のセッション鍵であれば、通常、ノンスと呼ばれるワンタイム値を、各セッション鍵が新鮮であることを保証するために使用されるより高いレベルの共有秘密情報から導出することができます。セッション鍵を生成するために使用されるメカニズムは、1つのセッションキーの開示は、他のセッション鍵を発見するには、攻撃者を支援しないことを保証しなければなりません。
EAP, AAA, and the lower layer each bear responsibility for ensuring the use of fresh, strong session keys. EAP methods need to ensure the freshness and strength of EAP keying material provided as an input to session key derivation. [RFC3748] Section 7.10 states:
EAPは、AAA、および下層それぞれは、新鮮な、強力なセッションキーの使用を確保するための責任を負います。 EAPメソッドは、セッションキーの導出への入力として提供EAPキーイング材料の新鮮さと強度を確保する必要があります。 [RFC3748]セクション7.10状態：
EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in cases where one party may not have a high quality random number generator. A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK.
EAP方式も、一方の当事者が、高品質の乱数発生器を持っていない可能性例では、MSKとEMSKの鮮度を確保すべきです。各当事者は、MSK及びEMSKの導出に使用される少なくとも128ビットのノンスを提供するために推奨される方法です。
The contribution of nonces enables the EAP peer and server to ensure that exported EAP keying material is fresh.
ナンスの寄与は、エクスポートEAPキーイング材料が新鮮であることを確認するためにEAPピア及びサーバを可能にします。
[RFC3748] Section 7.2.1 describes the "key strength" and "session independence" security claims, and [RFC4017] requires EAP methods supporting these claims as well as methods capable of providing equivalent key strength of 128 bits or greater. See Section 3.7 for more information on key strength.
[RFC3748]セクション7.2.1は、「キー強度」と「セッション独立」セキュリティクレーム、及び[RFC4017]を説明128ビット以上の等価鍵強度を提供することが可能なこれらの特許請求の範囲、ならびに方法をサポートするEAPメソッドを必要とします。キーの強度についての詳細は、3.7節を参照してください。
The AAA protocol needs to ensure that transported keying material is fresh and is not utilized outside its recommended lifetime. Replay protection is necessary for key freshness, but an attacker can deliver a stale (and therefore potentially compromised) key in a replay-protected message, so replay protection is not sufficient. As discussed in Section 3.5, the Session-Timeout Attribute enables the backend authentication server to limit the exposure of transported keying material.
AAAプロトコルは、搬送キーイング材料は新鮮であり、その推奨寿命外利用されないことを保証する必要があります。リプレイ保護キー鮮度のために必要であるが、攻撃者はリプレイ保護されたメッセージに失効（したがって、潜在的に危険にさらさ）キーを配信することができるので、再生保護が十分ではありません。 3.5節で述べたように、セッションタイムアウト属性は、輸送鍵材料の露出を制限するために、バックエンド認証サーバを有効にします。
The EAP Session-Id, described in Section 1.4, enables the EAP peer, authenticator, and server to distinguish EAP conversations. However, unless the authenticator keeps track of EAP Session-Ids, the authenticator cannot use the Session-Id to guarantee the freshness of keying material.
1.4節で説明EAPセッションIdは、EAPの会話を識別するためEAPピア、オーセンティケータ、およびサーバーを可能にします。オーセンティケータはEAPセッションIDの追跡しない限り、しかし、オーセンティケータは、材料をキーイングの鮮度を保証するためにセッションIDを使用することはできません。
The Secure Association Protocol, described in Section 3.1, MUST generate a fresh session key for each session, even if the EAP keying material and parameters provided by methods are cached, or either the peer or authenticator lack a high entropy random number generator. A RECOMMENDED method is for the peer and authenticator to each provide a nonce or counter used in session key derivation. If a nonce is used, it is RECOMMENDED that it be at least 128 bits. While [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement, [IEEE-802.16e] does not, since randomness is only contributed from the Base Station.
セクション3.1で説明セキュアアソシエーションプロトコルは、材料および方法によって提供されたパラメータをキーイングEAPがキャッシュされている場合でも、セッションごとに新鮮なセッション鍵を生成しなければならない、またはピアまたはオーセンティケータのいずれかが高エントロピー乱数発生器を欠いています。推奨される方法は、各々がセッションキーの導出に使用されるナンスまたはカウンタを提供するために、ピアとオーセンティケータのためのものです。ノンスを使用する場合、少なくとも128ビットであることが推奨されます。 [IEEE-802.11]とのIKEv2 [RFC4306]この要件を満たしながらランダムのみ基地局から寄与されるので、[IEEE-802.16eの]はありません。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Limit key scope
キー範囲を限定
Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it.
最小特権の原則に続いて、当事者がその役割を実行するために必要とされていない材料を鍵へのアクセス権を持つことはできません。それはそれを引き出すために必要な秘密情報のすべてにアクセスを持っている場合当事者は、特定のキーへのアクセス権を持っています。
Any protocol that is used to establish session keys MUST specify the scope for session keys, clearly identifying the parties to whom the session key is available.
セッションキーを確立するために使用されているすべてのプロトコルが明確にセッションキーが利用可能である誰にパーティーを識別、セッションキーのためのスコープを指定する必要があります。
Transported keying material is permitted to be accessed by the EAP peer, authenticator and server. The EAP peer and server derive EAP keying material during the process of mutually authenticating each other using the selected EAP method. During the Secure Association Protocol exchange, the EAP peer utilizes keying material to demonstrate to the authenticator that it is the same party that authenticated to the EAP server and was authorized by it. The EAP authenticator utilizes the transported keying material to prove to the peer not only that the EAP conversation was transported through it (this could be demonstrated by a man-in-the-middle), but that it was uniquely authorized by the EAP server to provide the peer with access to the network. Unique authorization can only be demonstrated if the EAP authenticator does not share the transported keying material with a party other than the EAP peer and server. TSKs are permitted to be accessed only by the EAP peer and authenticator (see Section 1.5); TSK derivation is discussed in Section 2.1. Since demonstration of authorization within the Secure Association Protocol exchange depends on possession of transported keying material, the backend authentication server can obtain TSKs unless it deletes the transported keying material after sending it.
輸送鍵材料は、EAPピア、オーセンティケータとサーバによってアクセスが許可されます。 EAPピアとサーバは、互いに選択EAPメソッドを使用して、互いを認証する過程EAPキーイング材料を導き出します。セキュア協会プロトコル交換時には、EAPピアは、それはEAPサーバに認証し、それによって認可されたのと同じパーティであるオーセンティケータに実証する鍵材料を利用しています。 EAP認証はEAPの会話が（これはのman-in-the-middleによって実証することができる）、それを通って輸送されたことが、それを一意にEAPサーバによって承認されたことだけでなく、ピアに証明する搬送キーイング材料を使用しますネットワークへのアクセスをピアを提供しています。 EAP認証は、EAPピアとサーバ以外の者で運ば鍵材料を共有していない場合は固有の認証にのみ発揮させることができます。 TSKsは（セクション1.5を参照）EAPピアとオーセンティケータによってのみアクセスすることが許可されています。 TSKの導出は、セクション2.1で議論されています。セキュア協会プロトコル交換内の認可のデモが輸送鍵材料の所有物に依存しているので、それを送信した後、輸送鍵材料を削除しない限り、バックエンド認証サーバはTSKsを得ることができます。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの必須要件：
Uniquely named keys
一意の名前のキー
AAA key management proposals require a robust key naming scheme, particularly where key caching is supported. The key name provides a way to refer to a key in a protocol so that it is clear to all parties which key is being referenced. Objects that cannot be named cannot be managed. All keys MUST be uniquely named, and the key name MUST NOT directly or indirectly disclose the keying material. If the key name is not based on the keying material, then one can be sure that it cannot be used to assist in a search for the key value.
AAA鍵管理の提案は、キーキャッシュがサポートされている、特に堅牢なキー命名スキームを、必要としています。キー名は、それが参照されているキーすべての当事者には明らかであるように、プロトコルでキーを参照する方法を提供します。名前を付けることができないオブジェクトを管理することができません。すべてのキーは一意の名前を付ける必要があり、キーの名前は、直接的または間接的に鍵素材を開示してはなりません。キー名を合わせることの材料に基づいていない場合、その一つは、キー値の検索を支援するために使用することはできないことを確認することができます。
EAP key names (defined in Section 1.4.1), along with the Peer-Id(s) and Server-Id(s), uniquely identify EAP keying material, and do not directly or indirectly expose EAP keying material.
（1.4.1項で定義された）EAPキー名は、ピアID（複数可）及びサーバID（複数可）と一緒に、一意のEAPキーイングマテリアルを識別し、直接または間接的に材料を合わせるEAPを公開していません。
Existing AAA server implementations do not distribute key names along with the transported keying material. However, Diameter EAP [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for the purpose of transporting the EAP Session-Id. Since the EAP-Key-Name AVP is defined within the RADIUS attribute space, it can be used either with RADIUS or Diameter.
既存のAAAサーバの実装は、輸送鍵材料と一緒にキー名を配布しないでください。しかし、直径EAP [RFC4072]セクション4.1.4は、EAPセッションIdを輸送する目的のためにEAP-キー名AVPを定義します。 EAP-キー名AVPはRADIUSの属性空間内で定義されているので、それはRADIUSまたは直径のどちらかを使用することができます。
Since the authenticator is not provided with the name of the transported keying material by existing backend authentication server implementations, existing Secure Association Protocols do not utilize EAP key names. For example, [IEEE-802.11] supports PMK caching; to enable the peer and authenticator to determine the cached PMK to utilize within the 4-way handshake, the PMK needs to be named. For this purpose, [IEEE-802.11] utilizes a PMK naming scheme that is based on the key. Since IKEv2 [RFC4306] does not cache transported keying material, it does not need to refer to transported keying material.
オーセンティケータは、既存のバックエンド認証サーバの実装により輸送鍵材料の名前で提供されていないので、既存のセキュア協会プロトコルは、EAPキー名を利用しません。例えば、[IEEE-802.11] PMKキャッシュをサポートします。 4ウェイハンドシェイク中に利用するために、キャッシュされたPMKを決定するために、ピアと認証を有効にするために、PMKが命名する必要があります。この目的のために、[IEEE-802.11]キーに基づいているPMKの命名規則を使用しています。 IKEv2の[RFC4306]は輸送鍵材料をキャッシュしませんので、それは輸送鍵材料を参照する必要はありません。
Key caching can result in vulnerability to denial-of-service attacks. For example, EAP methods that create persistent state can be vulnerable to denial-of-service attacks on the EAP server by a rogue EAP peer.
キーキャッシュは、サービス拒否攻撃に対する脆弱性をもたらす可能性があります。例えば、永続的な状態を作成するEAPメソッドは、不正なEAPピアによってEAPサーバ上でサービス拒否攻撃に対して脆弱であることができます。
To address this vulnerability, EAP methods creating persistent state can limit the persistent state created by an EAP peer. For example, for each peer an EAP server can choose to limit persistent state to a few EAP conversations, distinguished by the EAP Session-Id. This prevents a rogue peer from denying access to other peers.
この脆弱性に対処するために、永続的な状態を作り出すEAPメソッドは、EAPピアによって作成された永続的な状態を制限することができます。例えば、各ピアのためのEAPサーバは、EAPセッションIdで区別いくつかのEAPの会話に永続的な状態を制限するように選択することができます。これは、他のピアへのアクセスを拒否することから不正なピアを防ぐことができます。
Similarly, to conserve resources an authenticator can choose to limit the persistent state corresponding to each peer. This can be accomplished by limiting each peer to persistent state corresponding to a few EAP conversations, distinguished by the EAP Session-Id.
同様に、リソースを節約するために、オーセンティケータは、各ピアに対応する永続的な状態を制限するように選択することができます。これは、EAPセッションIdによって区別いくつかのEAPの会話に対応する永続的な状態に各ピアを制限することによって達成することができます。
Whether creation of new TSKs implies deletion of previously derived TSKs depends on the EAP lower layer. Where there is no implied deletion, the authenticator can choose to limit the number of TSKs and associated state that can be stored for each peer.
新しいTSKsの作成は以前に派生TSKsの削除を意味するかどうかは、EAP下位層に依存します。いかなる暗黙欠失が存在しない場合、オーセンティケータは、ピアごとに保存することができるTSKsの数と関連する状態を制限するために選択することができます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley氏、R。およびB. Aboba、 "認証、許可、アカウンティング（AAA）キー管理のための指針"、BCP 132、RFC 4962、2007年7月。
[8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1x Model", Proceedings of the IFIP TC6/WG6.8 Working Conference on Personal Wireless Communications, p.175-182, October 23-25, 2002.
[8021XPreAuth]パック、S.およびY.チェ、「事前認証IEEE 802.1xのモデルに基づいた公衆無線LANでの高速ハンドオフ」パーソナル無線通信に関するIFIP TC6 / WG6.8ワーキング会議の議事録、p.175 -182、10月23-25、2002。
[Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way Handshake", Proceedings of the 2004 ACM Workshop on Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
[分析]彼、C.とJ.ミッチェル、 "802.11i規格の分析4ウェイハンドシェイク"、ワイヤレスセキュリティ、頁上の2004 ACMワークショップの議事録は43-50、ISBN：1-58113-925-X。
[Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, H. and P. Schoo, "Fast Authentication Methods for Handovers between IEEE 802.11 Wireless LANs", Proceedings of the 2nd ACM international workshop on Wireless mobile applications and services on WLAN hotspots, October, 2004.
【Bargh] Bargh、M.、Hulsebosch、R.、Eertink、E.、プラサド、A.、王、H.及びP. Schoo、 "IEEE 802.11無線LAN間のハンドオーバのための高速認証方式"、第2回ACM議事録WLANホットスポットのワイヤレスモバイルアプリケーションとサービスに関する国際ワークショップ、2004年10月。
[GKDP] Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group Key Distribution Protocol", Work in Progress, March 2006.
[GKDP] Dondeti、L.、翔、J.、およびS. Rowles、 "GKDP：グループ鍵配布プロトコル"、進歩、2006年3月での作業。
[He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. Mitchell, "A Modular Correctness Proof of TLS and IEEE 802.11i", ACM Conference on Computer and Communications Security (CCS '05), November, 2005.
[彼]彼、C.、Sundararajan、M.、ダッタ、A.デレク、A.およびJCミッチェル、 "TLSおよびIEEE 802.11i規格のモジュラー正しさの証明"、コンピュータおよび通信セキュリティ上のACM会議（CCS '05） 、2005年11月。
[IEEE-802.11] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-2007, 2007.
電気電子技術者の[IEEE-802.11]研究所、「情報技術 - 地方とメトロポリタンエリアネットワーク - - 電気通信及びシステム間の情報交換の固有の要件パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様」 、IEEE標準802.11-2007、2007。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
電気電子学会、「地方とメトロポリタンエリアネットワーク：ポートベースのネットワークアクセスコントロール」の[IEEE-802.1X]研究所、IEEE標準802.1X-2004、2004年12月。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.1Q]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：2003年1月、仮想ブリッジローカルエリアネットワーク、P802.1Q-2003用標準案。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "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/D1, 2001.
電気電子技術者の[IEEE-802.11i規格]研究所、「電気通信及びシステム間情報交換のための標準への補足 - LAN / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：セキュリティ強化」、IEEE 802.11i規格/ D1、2001年のための仕様。
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, July 2003 (now deprecated).
電気電子技術者の[IEEE-802.11F]研究所、「動作IEEE 802.11を支える物流システム間インターアクセスポイントプロトコルを介したマルチベンダーアクセスポイントの相互運用性のための推奨プラクティス」、IEEE 802.11F、2003年7月には、（現在は非推奨します）。
[IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks: Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems: Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operations in Licensed Bands" IEEE 802.16e, August 2005.
[IEEE-802.16eの]電気学会電子技術、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：パート16：エア・インタフェースの固定およびモバイルブロードバンドワイヤレスアクセスシステムのための：固定結合され、モバイルのための物理的および媒体アクセス制御層のための改正は、許諾バンドでの操作」のIEEE802.16e、2005年8月。
[IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03- 084r1-I, http://www.ieee802.org/11/Documents/ DocumentHolder/3-084.zip, January 2003.
[IEEE-03から084]ミシュラ、A.、新、M.、Arbaugh、W.、リー、I.およびK.チャン、 "高速で安全なローミングをサポートするための積極的なキー配布"、IEEE 802.11ワーキンググループ、IEEE- 03- 084r1-I、http://www.ieee802.org/11/Documents/ DocumentHolder / 3-084.zip、2003年1月。
[EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
[EAP-SERVICE] Arkko、J.、およびP. Eronen、 "拡張認証プロトコル（EAP）のための認証サービスの情報"、進歩、2005年10月に作業。
[SHORT-TERM] Friedman, A., Sheffer, Y., and A. Shaqed, "Short-Term Certificates", Work in Progress, June 2007.
[短期]フリードマン、A.、シェファー、Y.、およびA. Shaqed、 "短期証明書"、進歩、2007年6月に作業。
[HANDOFF] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
[HANDOFF] Arbaugh、W.およびB. Aboba、 "RADIUSへのハンドオフ拡張"、進歩、2003年10月に作業。
[EAP-CHANNEL] Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel Binding Mechanism Based on Parameter Binding in Key Derivation", Work in Progress, June 2007.
[EAP-CHANNEL]大場、Y.、Parthasrathy、M.、およびM.柳屋、 "鍵の導出にバインドパラメータに基づいて、チャネルバインディング機能"、進歩、2007年6月に作業。
[EAP-BINDING] Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, "The Compound Authentication Binding Problem", Work in Progress, October 2003.
[EAP-BINDING] Puthenkulam、J.、Lortz、V.、Palekar、A.、およびD.サイモン、進歩、2003年10月ワーク "問題を結合化合物認証"。
[MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions Within a Minute", Cryptology ePrint Archive, March 2006, http://eprint.iacr.org/2006/105.pdf
[MD5Collision]クリマ、V.、 "ハッシュ関数でトンネル：MD5衝突分以内"、暗号学ePrintのアーカイブ、2006年3月、http://eprint.iacr.org/2006/105.pdf
[MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key Distribution using Neighbor Graphs", IEEE Wireless Communications, vol. 11, February 2004.
【MishraPro]ミシュラ、A.、シン、M.およびW. Arbaugh、「隣接グラフを用いたプロアクティブなキー配布」、IEEE無線通信、体積11、2004年2月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968]マイヤー、G.、 "PPP暗号化制御プロトコル（ECP）"、RFC 1968、1996年6月。
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.
[RFC2230]アトキンソン、R.、 "DNSのための鍵交換委任録音"、RFC 2230、1997年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidlの、K.、Evarts、J.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716] Aboba、B.及びD.シモン、 "PPP EAP TLS認証プロトコル"、RFC 2716、1999年10月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]いるVixie、P.、グドムンソン、O.、イーストレイク3日、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon氏、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "IEEE 802.1Xのリモート認証ダイヤルインユーザーサービス（RADIUS）使用上のガイドライン"、RFC 3580、2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、RFC 4005、2005年8月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4067] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4067] Loughney、J.、編、Nakhjiri、M.、パーキンス、C.、およびR. Koodli、 "コンテキスト転送プロトコル（CXTP）"、RFC 4067、2005年7月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.編、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（EAP）アプリケーション"、RFC 4072、2005年8月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]ヤン、L.、Zerfos、P.、およびE. Sadot、RFC 4118、2005年6月の "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のためのアーキテクチャ分類学"。
[RFC4186] Haverinen, H., Ed., and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4186] Haverinen、H.編、及びJ. Salowey、編、 "モバイル通信用グローバルシステム（GSM）加入者識別モジュール（EAP-SIM）のための拡張認証プロトコル方法"、RFC 4186、2006年1月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187] Arkko、J.とH. Haverinen、 "第3世代認証及び鍵合意（EAP-AKA）のための拡張認証プロトコル方式"、RFC 4187、2006年1月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[RFC4284] Adrangi、F.、Lortz、V.、バーリ、F.、およびP. Eronen、2006年1月、RFC 4284 "アイデンティティの選択は、拡張認証プロトコル（EAP）のためのヒント"。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] Adrangi、F.、LIOR、A.、Korhonen、J.、およびJ. Loughney、 "有料ユーザーID"、RFC 4372、2006年1月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
[RFC4334] Housley氏、R.とT.ムーア、「証明書の拡張機能と属性で認証のサポートポイントツーポイントプロトコル（PPP）とワイヤレスローカルエリアネットワーク（WLAN）」、RFC 4334、2006年2月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", RFC 4763, November 2006.
、RFC 4763、2006年11月の "共有秘密認証と鍵確立（EAP-SAKE）のための拡張認証プロトコル方式" [RFC4763] VANDERVEEN、M.およびH.ソリマン、。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon氏、P.、サンチェス、M.、およびB. Aboba、 "RADIUSは、仮想LANとプライオリティサポートのための属性"、RFC 4675、2006年9月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P.およびP.ホフマン、 "IKEv2の明確化および実装のガイドライン"、RFC 4718、2006年10月。
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007.
[RFC4764] Bersani、F.及びH. Tschofenig、 "EAP-PSKプロトコル：事前共有キー拡張認証プロトコル（EAP）方式"、RFC 4764、2007年1月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
、RFC 5176、2008年1月[RFC5176]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]サイモン、D.、Aboba、B.、およびR.ハースト、 "EAP-TLS認証プロトコル"、RFC 5216、2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]米国国立標準技術研究所、「キー管理のための勧告」、特別な公表800-57、2006年5月。
[Token] Fantacci, R., Maccari, L., Pecorella, T., and F. Frosali, "A secure and performant token-based authentication for infrastructure and mesh 802.1X networks", IEEE Conference on Computer Communications, June 2006.
[トークン] Fantacci、R.、Maccari、L.、Pecorella、T.、およびF. Frosali、 "インフラのための安全とパフォーマンスのトークンベースの認証および802.1Xメッシュネットワーク"、コンピュータ通信、2006年6月にIEEE会議。
[Tokenk] Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover Keying: A Media-Independent Handover Key Management Architecture", Mobiarch 2007.
[Tokenk]大場、Y.、ダス、S.、およびA. Duttak、 "ケルベロス化ハンドオーバキーイング：メディアに依存しないハンドオーバキー管理アーキテクチャ"、Mobiarch 2007。
Acknowledgments
謝辞
Thanks to Ashwin Palekar, Charlie Kaufman, and Tim Moore of Microsoft, Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco, and Russ Housley of Vigil Security for useful feedback.
有用なフィードバックのためのAshwin Palekar、チャーリー・カウフマン、およびマイクロソフトのティム・ムーア、エリクソンのヤリArkko、アルバネットワークスのドロシー・スタンレー、TruSecureのボブ・モスコウィッツ、インテルのジェシー・ウォーカー、シスコのジョーSalowey、およびビジルセキュリティのラスHousleyに感謝します。
Appendix A - Exported Parameters in Existing Methods
付録A - 既存の方法でエクスポートパラメータ
This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-Lifetime for EAP methods that have been published prior to this specification. Future EAP method specifications MUST include a definition of the Session-Id, Peer-Id and Server-Id (could be the null string). In the descriptions that follow, all fields comprising the Session-Id are assumed to be in network byte order.
この付録では、この仕様に先立って発表されているEAPメソッドのためのセッションId、ピアID、サーバIDおよびキーの有効期間を指定します。将来のEAPメソッドの仕様は、Session-ID、ピアIDとサーバID（ヌル文字列である可能性）の定義を含まなければなりません。以下の説明では、セッションIdを構成するすべてのフィールドはネットワークバイト順であると想定されています。
EAP-Identity
EAP-アイデンティティ
The EAP-Identity method is defined in [RFC3748]. It does not derive keys, and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAPアイデンティティ法は[RFC3748]で定義されています。これは、鍵を導出しないので、セッションIdを定義していません。ピアID及びサーバIDがNULL文字列（長さがゼロ）です。
EAP-Notification
EAP-通知
The EAP-Notification method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP-通知方法は、[RFC3748]で定義されています。これは、セッションIdを定義していないため、鍵を導出していません。ピアID及びサーバIDがNULL文字列（長さがゼロ）です。
EAP-MD5-Challenge
EAP-MD5チャレンジ
The EAP-MD5-Challenge method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP-MD5チャレンジ法は[RFC3748]で定義されています。これは、セッションIdを定義していないため、鍵を導出していません。ピアID及びサーバIDがNULL文字列（長さがゼロ）です。
EAP-GTC
EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP-GTC法は[RFC3748]で定義されています。これは、セッションIdを定義していないため、鍵を導出していません。ピアID及びサーバIDがNULL文字列（長さがゼロ）です。
EAP-OTP
EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP-OTP方法は、[RFC3748]で定義されています。これは、セッションIdを定義していないため、鍵を導出していません。ピアID及びサーバIDがNULL文字列（長さがゼロ）です。
EAP-AKA
EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute:
EAP-AKAは[RFC4187]で定義されています。 EAP-AKAセッションIdはAT_AUTN属性にAUTNフィールドの内容に続くAT_RAND属性からRANDフィールドの内容とEAPタイプコード（0x17の）の連結です。
Session-Id = 0x17 || RAND || AUTN
セッションId = 0x17の|| RAND || AUTN
The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast EAP re-authentication identity. The Server-Id is the null string (zero length).
ピアIDは、しかし、最初からのみ実際のアイデンティティの長さのオクテットを使用して、AT_IDENTITY属性からのアイデンティティフィールドの内容です。それらが送信される内容は関係なく、送信アイデンティティは永久、仮名、または高速EAP再認証のアイデンティティであったかどうかの、使用されていることに注意してください。サーバIDがNULL文字列（長さがゼロ）です。
EAP-SIM
EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the concatenation of the EAP Type Code (0x12) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the NONCE_MT field in the AT_NONCE_MT attribute:
EAP-SIMは、[RFC4186]で定義されています。 EAP-SIMセッションIdはAT_NONCE_MT属性にNONCE_MTフィールドの内容に続くAT_RAND属性からRANDフィールドの内容とEAPタイプコード（0x12を）の連結です。
Session-Id = 0x12 || RAND || NONCE_MT
セッションId = 0x12を|| RAND || NONCE_MT
The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast EAP re-authentication identity. The Server-Id is the null string (zero length).
ピアIDは、しかし、最初からのみ実際のアイデンティティの長さのオクテットを使用して、AT_IDENTITY属性からのアイデンティティフィールドの内容です。それらが送信される内容は関係なく、送信アイデンティティは永久、仮名、または高速EAP再認証のアイデンティティであったかどうかの、使用されていることに注意してください。サーバIDがNULL文字列（長さがゼロ）です。
EAP-PSK
CRD-RIS
EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and server (RAND_S) nonces:
EAP-PSKは、[RFC4764]で定義されています。 EAP-PSKセッションIdピア（RAND_P）とサーバ（RAND_S）ナンスとEAPタイプコード（0x2F）の連結です。
Session-Id = 0x2F || RAND_P || RAND_S
セッションId = 0x2F || RAND_P || RAND_S
The Peer-Id is the contents of the ID_P field and the Server-Id is the contents of the ID_S field.
ピアIDはID_Pフィールドの内容で、サーバー-IdはID_Sフィールドの内容です。
EAP-SAKE
EAP-SAKE
EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the concatenation of the EAP Type Code (0x30) with the contents of the RAND_S field from the AT_RAND_S attribute, followed by the contents of the RAND_P field in the AT_RAND_P attribute:
EAP-酒は[RFC4763]で定義されています。 EAP-酒セッションIdはAT_RAND_P属性にRAND_Pフィールドの内容に続くAT_RAND_S属性からRAND_Sフィールドの内容とEAPタイプコード（0x30から）の連結です。
Session-Id = 0x30 || RAND_S || RAND_P
セッションId = 0x30の|| RAND_S || RAND_P
Note that the EAP-SAKE Session-Id is not the same as the "Session ID" parameter chosen by the Server, which is sent in the first message, and replicated in subsequent messages. The Peer-Id is contained within the value field of the AT_PEERID attribute and the Server-Id, if available, is contained in the value field of the AT_SERVERID attribute.
EAP-酒セッションIdは、後続のメッセージの最初のメッセージで送信され、そして複製されたサーバによって選択された「セッションID」パラメータと同じではないことに留意されたいです。ピアIDはAT_PEERID属性およびサーバIDの値フィールド内に含まれている、利用可能な場合、AT_SERVERID属性の値フィールドに含まれています。
EAP-TLS
EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [RFC5216].
EAP-TLS、ピアID、サーバIDとセッションIDの[RFC5216]で定義されています。
Authors' Addresses
著者のアドレス
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052
だん しもん みｃろそｆｔ れせあｒｃｈ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２
EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 936 7329
メールアドレス：dansimon@microsoft.com電話：+1 425 706 6711ファックス：+1 425 936 7329
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。