[要約] RFC 5247は、EAPキーマネジメントフレームワークに関する標準化ドキュメントであり、EAPセッションの鍵管理に関するプロトコルと手順を定義しています。その目的は、EAPを使用するネットワーク認証プロトコルのセキュリティと効率を向上させることです。
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メソッドによって生成されたキーイング素材とパラメーターの輸送と使用のフレームワークを提供します。また、「認証、承認、会計（AAA）主要管理のガイダンス」[RFC4962]に記載されている要件を記述する詳細なセキュリティ分析も提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
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ウェイハンドシェイク[IEEE-802.11]で定義されたペアワイズ認証とキー管理プロトコル（AKMP）は、2つの当事者によるペアワイズマスターキーの相互所有を確認し、グループキーを配布します。
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.
AAA認証、承認、およびEAPサポートを備えた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-KEY AAA-Keyという用語は、マスターセッションキー（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).
Transient Session Keys（TSK）などの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、拡張MSK（EMSK）、初期化ベクトル（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サーバーは認証機の一部です。Authenticatorがパススルーモードで動作する場合、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).
キーは、別の対称的な暗号化キーの暗号化を別のものにラップします。暗号化に使用されるアルゴリズムは、キーラップアルゴリズムまたはキー暗号化アルゴリズムと呼ばれます。暗号化プロセスで使用されるキーは、キー暗号化キー（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）のCiphersuitesを使用した時間キーキーインテグリティプロトコル（TKIP）および高度な暗号化標準カウンターモードは、PMKからのみ一方の過渡セッションキー（TSK）を導き出します。「IEEE 802.1x半径使用ガイドライン」[RFC3580]は、MSKの両方の半分からTSKを導き出します。[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.
Authenticatorに対応するエンティティをピアします。[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.
SESSION-ID EAP Session-IDは、EAPピア（PEER-ID（S）で識別）とサーバー（サーバー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認証交換中にEAPピアとサーバーの間に保護されたチャネルを確立するために使用される一時的なEAPキー（TEK）セッションキー。TEKは、EAPの会話を保護するために使用するためにEAPピアとサーバーの間で交渉されたCiphersuiteで使用するのに適しています。TEKはEAPメソッドによってローカルに保管され、エクスポートされていません。EAP認証中にEAPピアとサーバーの間に保護されたチャネルをセットアップするために使用されるCiphersuiteは、その後EAPピアと認証器の間で送信されたデータを保護するために使用されるCiphersuiteとは無関係であることに注意してください。
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認証後に交換されたデータを保護するために使用される一時的なセッションキー（TSK）キーは、EAPピアと認証器の間で交渉されたCiphersuiteを使用して正常に完了しました。
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）が必要です。バックエンド認証サーバーが存在するモード独立性の原則（セクション1.6.1を参照）に従うために、下層に必要なすべてのキーイング素材は、EAPサーバーから認証器に輸送されます。既存の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.
Peer and 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.
PPP [RFC1661]で定義されているPoint-to-Pointプロトコル（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 Internet Key Exchange V2（IKEV2）には、EAPのサポートが含まれており、ユニキャストセキュリティ協会の確立（フェーズ2A）の確立を処理します。ただし、マルチキャストセキュリティ協会の確立（フェーズ2B）は通常、EAPを含むものではなく、グループセキュアーアソシエーションキー管理プロトコル（GSAKMP）、グループセキュアーアソシエーションキー管理プロトコルなどのグループキー管理プロトコルによって処理する必要があります。[RFC4535]、Multimedia Internet Keying（Mikey）[RFC3830]、またはGroup Key Distribution Protocol（GKDP）[GKDP]。IPSECセキュリティゲートウェイの発見のために、いくつかのメカニズムが提案されています。[RFC2230]は、IPSECゲートウェイディスカバリーにキーエクスチェンジ（KX）リソースレコード（RRS）の使用について説明します。KX RRSは多くのドメイン名サービス（DNS）サーバーの実装によってサポートされていますが、まだ広く展開されていません。あるいは、DNS SRV RRS [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アクセスポイント（APS）は、ビーコンフレームを使用したサービスセット識別子（SSIDS）と機能を定期的に発表します。ステーションは、プローブリクエストを送信することにより、APをクエリすることができます。ビーコンもプローブ要求/応答フレームも保護されていません。[IEEE-802.11]で定義された4ウェイハンドシェイクにより、ユニキャスト（フェーズ2A）とマルチキャスト/ブロードキャスト（フェーズ2B）の安全な関連付けの導出が可能になります。グループキーエクスチェンジは、APからステーションにグループキーを輸送するため、ピアツーピア通信をサポートするために2つの4方向の握手が必要になります。IEEE 802.11 4ウェイハンドシェイクのセキュリティの証拠は、EAP-TLSで使用される場合、[HE]で提供されます。
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サーバーは、ピアの身元も保存し、ピアはどの証明書を使用するかを選択するために必要な情報を保存します。ピアとサーバーの間に確立された長期的な資格に基づいて、メソッドは2種類のEAPキーイング材料を導き出します。
(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).
(b) EAPメソッドによってエクスポートされるキーイングマテリアル：マスターセッションキー（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.
その後ネゴシエートされたCiphersuiteで使用するためのキーイング素材を提供するには、キーの導出をサポートするEAPメソッドは、少なくとも64オクテットのマスターセッションキー（MSK）をエクスポートし、少なくとも64オクテットの拡張マスターセッションキー（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サーバーまたはピアの外側のエンティティに提供されてはなりません。また、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.
キー派生と相互認証をサポートするEAPメソッドは、セッションIDとして知られるメソッド固有のEAP会話識別子、および1つ以上のメソッド固有のピア識別子（PEER-ID）をエクスポートし、1つ以上の方法をエクスポートすることができます-Specific Server Identifiers（server-id（s））。EAPメソッドは、チャネル結合パラメーターのインポートとエクスポートもサポートする場合があります。このドキュメントの公開後に開発されたEAPメソッド仕様は、Peer-ID、Server-ID、およびSession-IDを定義する必要があります。Peer-IDおよびServer-ID（S）は、提供された場合、EAPキーイングの生成に関与するエンティティを特定します。既存のEAPメソッドについては、Peer-ID、Server-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
Peer-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つ以上のメソッド固有のピアアイデンティティを認証する場合、これらのアイデンティティは、この方法によってPEER-IDとしてエクスポートされます。EAPメソッドによって複数のPeer-IDがエクスポートされる可能性があります。すべてのEAPメソッドがメソッド固有のピアアイデンティティを提供するわけではありません。これが定義されていない場合、PEER-IDはヌル文字列です。キー生成をサポートしないEAPメソッドでは、Peer-IDはヌル文字列でなければなりません。キーを導出するEAPメソッドがピアドを提供しない場合、EAPサーバーは、キーイング素材を導き出したEAPピアのIDを認証しません。
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がEAPメソッドによってエクスポートされる可能性があります。すべてのEAPメソッドがメソッド固有のサーバーのアイデンティティを提供するわけではありません。これが定義されていない場合、server-idはnull文字列です。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):
Session-IDは、EAPピア（Peer-IDで識別）とサーバー（サーバーIDで識別）の間のEAPセッションを一意に識別します。非拡張EAPタイプコードが使用されている場合（EAPタイプコードは254に等しくない）、EAPセッションIDは、単一のオクテットEAPタイプコードとメソッドから取得した時間的に一意の識別子の連結です（Method-IDとして知られています）：
Session-Id = Type-Code || Method-Id
session-id = type-code ||Method-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]セクションで定義されているベンダータイプのフィールド（ネットワークバイト順）およびベンダータイプのフィールド（ネットワークバイト順）を含む拡張されたタイプコードで構成されています。5.7）、メソッド（Method-ID）から取得した時間的に一意の識別子と連結されています。
Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id
session-id = 0xfe ||ベンダー-ID ||ベンダータイプ||Method-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.
Method-IDは通常、EAPメソッド交換内で使用されるNoncesまたはカウンターから構築されます。EAP Session-IDにタイプコードまたは拡張されたタイプコードを含めることで、各EAPメソッドに異なるセッションIDスペースがあることが保証されます。EAPセッションは、ピアおよび認証機の特定の認証機または特定のポートにバインドされていないため、AuthenticatorポートまたはIDはセッション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の範囲は、利用可能な場合は、認証されたメソッド固有のピアアイデンティティ（PEER-ID（S））と認証されたサーバーID（サーバーID）によって定義されます。
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 Session-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).
注：IEEE 802.11は、Secure Association Protocolでそれを参照できる目的でPMKに名前を付けます。PMK名（PMKIDとして知られている）は、PMK自体のハッシュと他のパラメーターに基づいています（[IEEE-802.11]セクション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名一時的なセッションキー（TSK）は通常、名前が付けられています。それらの命名は下層で指定されているため、特定のパケットを処理するために正しい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ピアとそれらの関係者のみに知られているAuthenticatorの間に新鮮なセッションキーを導き出すことです。信頼できるサードパーティ（バックエンド認証サーバー）。
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.
EAPメソッド交換（フェーズ1A）の完了キー派生の結果は、EAPピア（Peer-ID（s）で識別された）とEAPサーバー（識別）にのみ知られているEAPキーイング材料（MSK、EMSK、TEK）の導出を導き出します。Server-ID（s））。EAPピアとEAPサーバーの両方が、このキーイング素材を新鮮であることを知っています。Peer-IDおよびServer-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 Exchange（フェーズ1B）の完了により、EAPサーバー（サーバーID（S）によって識別）からキーイング材料がEAP認証器（NAS-IDENTIFIERによって識別）を、他の当事者に開示せずに輸送します。EAPサーバーとEAP認証者の両方が、このキーイング素材を新鮮であることを知っています。開示の問題については、セクション3.8および5.3で説明します。AAAプロトコルのセキュリティプロパティについては、セクション5.1〜5.9で説明します。
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キーイング材料が、他のキーを導出するために公開されているデータと組み合わされています。バックエンド認証サーバーは、これらの同じキーを導き出すことを控えることや、そうするために必要なキーイング素材にアクセスできるにもかかわらず、中間の男として機能することを控えると信頼されています。
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.
認証者も信頼できるパーティーです。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.
Secure Association Protocol（フェーズ2）の完了により、EAPピア（Peer-ID（s）で識別）および認証因子（NAS-IDENTIFIERによって識別）にのみ既知の過渡セッションキー（TSK）の導出または輸送が発生します。。EAPピアと認証者の両方は、TSKが新鮮であることを知っています。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
モード独立メディアの独立方法独立性暗号化された独立
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会話はピアと認証者の間で発生し、認証者は1つ以上の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].
AuthenticatorはいくつかのEAPメソッドをローカルに実装し、それらのメソッドを使用してローカルユーザーを認証できますが、同時に他のユーザーとメソッドのパススルーとして機能し、EAPパケットをバックエンド認証サーバーとピア間で前後に転送できます。これは、認証、承認、およびAuthenticatorとBackEnd認証サーバーの間で話される会計（AAA）プロトコル内のEAPパケットをカプセル化することによって達成されます。EAPをサポートするAAAプロトコルには、半径[RFC3579]および直径[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メソッドは、認証器がパススルーとして動作しているかどうかに関係なく、キー派生とパラメーターのインポート/エクスポートなど、すべての側面で同じように動作します。
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認証器のIDを含むチャネルバインディングパラメーターをインポートできますが、この情報は不透明なオクテットとして扱われます。その結果、EAP内では、関連する唯一のアイデンティティは、Peer-IDとServer-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 Authenticatorとの会話、およびその会話のすべての結果は、認証機の動作モードに関係なく同一です。
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の目標の1つは、[RFC3748]セクション3.1で概説されている基準を満たす下層層でEAPメソッドが機能することを許可することです。たとえば、[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メソッドは、それらが輸送されている下層の知識を持つと想定することはできず、特定の使用環境に関連する識別子（例：Medium Access Control（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メソッドは、それを使用するために識別子の内容に注意する必要はありません。これにより、EAPメソッドは、メディアの独立性を損なうことなく、MACアドレスなどのメディア固有の識別子を使用できます。チャネル結合パラメーターは、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-Challenge）は、辞書攻撃抵抗、相互認証、または重要な導出を提供せず、その結果、ワイヤレスローカルエリアネットワークでの使用には適していません（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.
Ciphersuiteの独立性は、メディアの独立性の要件です。低層の暗号筋はメディア間で異なるため、メディアの独立性では、エクスポートされたEAPキーイング材料が、あらゆるciphersuiteを処理するのに十分な大きさ（十分なエントロピーを備えています）を必要とします。
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会話の保護に使用されるciphersuiteと交渉することができますが、EAP認証が完了した後に交換されたデータの保護に使用されるCiphersuiteは、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）内でCiphersuiteが交渉されます。[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メソッドには低層層の顕微鏡に関する知識があることを要求すると、メディアの独立性の原則が損なわれます。その結果、Ciphersuiteが独立したEAPキーイング材料を輸出する方法。Ciphersuiteの交渉は下層で発生するため、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.
CiphersuiteがEAPキーイングフレームワーク内で使用できるようにするために、Ciphersuiteの仕様は、Ciphersuiteでの使用に適したTSKがエクスポートされたEAPキーイング材料からどのように導出されるかを説明する必要があります。メソッドの独立性を維持するために、TSKを導出するためのアルゴリズムはEAPメソッドに依存してはなりませんが、TEK派生のアルゴリズムはEAPメソッドに固有の場合があります。
Advantages of ciphersuite-independence include:
Ciphersuite-Indopendenceの利点は次のとおりです。
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.
更新要件の削減Ciphersuite Independenceを使用すると、メソッドを更新することなく、EAPメソッドを新しいCiphersuitesで使用できます。EAPメソッドが各Ciphersuiteの過渡セッションキーを導出する方法を指定する場合、新しいCiphersuiteが開発されるたびに更新する必要があります。さらに、バックエンド認証サーバーは、新しいCiphersuiteのサポートがAuthenticatorに追加されるたびに更新する必要があるため、すべての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メソッドは、Ciphersuite固有のコードを含める必要がないことを避けることができます。各EAPメソッドが一時的なセッションキー導入のためにCiphersuite固有のコードを含めるように要求すると、メソッドの複雑さが増加し、努力が重複します。
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.
Simplied Configuration Ciphersuite Independenceを使用すると、ピアとサーバーでのEAPメソッド実装により、Ciphersuite固有のパラメーターの構成を避けることができます。Ciphersuiteは、EAP以外のピアと認証者との間で交渉されます。Authenticatorが「パススルー」モードで動作する場合、EAPサーバーはこの交渉の当事者ではなく、EAPピアと認証者の間のデータフローにも関与していません。その結果、EAPサーバーには、ピアと認証者によって実装されたciphersuitesと交渉ポリシーに関する知識がなく、それらの間で交渉されたciphersuiteを認識していません。たとえば、暗号化制御プロトコル（ECP）のネゴシエーションは認証後に発生するため、PPPを介して実行すると、EAPピアとサーバーはネゴシエートされたCiphersuiteを予測できないため、この情報は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）、Peer-ID（S）、Server-ID、およびSession-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 Authenticator下層に輸送されたりしたのは、認証器を離れてはなりません。
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レイヤーに要求されて渡された材料とパラメーターをキーイング化することが、認証機のAAAレイヤーに複製される場合があります（EMSKを除く）。Authenticatorでは、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キーイング材料および/またはTSKを含むキーイング材料をキャッシュする場合があります。このキーキャッシュの構造は、下層によって定義されます。相互運用性を有効にするために、新しい低層仕様は重要なキャッシング動作を記述する必要があります。下層で明示的に指定されていない限り、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]はリンク層の衝突物質をサポートしておらず、その結果、TSKの生成やEAPキーキーキーキーキーのキャッシュを提供しませんおよびパラメーター。EAP認証が完了すると、EAPキーイング材料とパラメーターが破棄されると想定されます。IEEE 802有線ネットワークでは、その後の安全な関連付けプロトコル交換はありません。交渉されたEAPメソッドがこれをサポートしている場合にのみ、完全なフォワード秘密（PFS）が可能です。
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 ciphersuitesはMSKから直接TSKを導き出します。PPPがEAPキーイング材料のキャッシュをサポートする場合、TSKの再利用につながる可能性があるため、これは推奨されません。その結果、PPPセッションが終了すると、EAPキーイング材料とパラメーターを破棄する必要があります。EAPキーイング材料のキャッシングはPPP内では許可されていないため、EAPの再認証なしでTSKの再認証を処理する方法はありません。交渉されたEAPメソッドがこれをサポートしている場合にのみ、完全なフォワード秘密（PFS）が可能です。
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、PEER-ID、SERVER-ID、またはSESSION-IDは使用されていません。その結果、IKEV2によって導出されたTSKは、EAPキーイング材料とは独立しており、IPSEC SASの再認識を必要とせずに処理できます。IKEV2内では、どのEAPメソッドがネゴシエートされているかに関係なく、PFSをネゴシエートすることが可能です。[RFC4306]で指定されているIKEV2は、EAPキーイング材料またはパラメーターをキャッシュしません。IKEV2認証が完了すると、EAPキーイング材料とパラメーターが破棄されると想定されます。したがって、セッションタイムアウト属性は、MSKキーライフタイムの兆候ではなく、VPNセッション時間の制限として解釈されます。
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 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.11 IEEE 802.11は、MSKのキャッシュを有効にしますが、EMSK、IV、Peer-ID、Server-ID、またはSession-IDではありません。キャッシュの構造の詳細については、[IEEE-802.11]で入手できます。IEEE 802.11では、TSKは、NonCe Exchangeを含む4ウェイハンドシェイクとして知られる安全な関連プロトコルを使用してMSKから派生しています。これにより、MSKが再利用されたとしても、TSKの新鮮さが保証されます。4ウェイハンドシェイクは、EAPの再認証なしでTSKのキーを可能にします。PFSは、キャッシュが有効にならず、ネゴシエートされたEAPメソッドがPFSをサポートしている場合、IEEE 802.11内でのみ可能です。
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 IEEE 802.16Eは、MSKのキャッシュをサポートしますが、EMSK、IV、Peer-ID、Server-ID、またはSession-IDはサポートしていません。IEEE 802.16Eは、ピアによる貢献なしに、TSKが認証者によって選択される安全な関連プロトコルをサポートしています。TSKは、MSKを使用して暗号化され、認証され、保護されている整合性が保護されており、認証者からピアに輸送されます。TSK RECHEは、EAPの再認証なしで可能です。交渉されたEAPメソッドがサポートしていても、PFSは不可能です。
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.
AAA radius/eap [rfc3579]または直径EAP [RFC4072]の既存の実装と仕様は、キーイング材料またはパラメーターのキャッシュをサポートしていません。既存の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.
キーの再利用を避けるために、AAA層は送信されたら輸送されたキーを削除する必要があります。AAAレイヤーは、以前に送信したキーを保持してはなりません。たとえば、MSKを輸送したAAAレイヤーは削除する必要があり、キーをその時点からMSKから派生させてはなりません。
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:
たとえば、複数のベースステーションと「コントローラー」（たとえば、WLANスイッチ）が単一のEAP認証器を構成する可能性があります。このような状況では、「基地局のアイデンティティ」は、おそらくチャネルバインディングで使用される不透明な塊として、EAPメソッドの会話とは無関係です。多くのベースステーションは、同じ認証機のアイデンティティを共有できます。EAP AuthenticatorまたはPeer：
(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.
Authenticatorは、複数のEAPサーバーと通信するように構成できます。各EAPサーバーは、Authenticatorのサブセットと通信するように構成されています。状況を図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ピアとサーバーの間です。Authenticatorのアイデンティティは、EAPメソッドで考慮された場合、チャネル結合を目的として不透明なブロブとして扱われます（セクション5.3.3を参照）。ただし、認証機のアイデンティティは、他の2つの交換で重要です - AAAプロトコル交換と安全な関連プロトコル会話。
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-IDENTIFIERによって定義されたスコープの外側の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.
Secure Association Protocolの会話は、ピアと認証者の間です。キーキャッシュをサポートする下層層の場合、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.
認証機には複数のポートを持つことができるため、Authenticatorキーキャッシュの範囲は、単一のエンドポイントアドレスでは説明できません。同様に、ピアが複数のポートを持つことができる場合、同じリンクタイプのピアポート間の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]や直径[RFC4072]などのAAAプロトコルは、AAAクライアントの識別のメカニズムを提供します。EAP Authenticatorと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-IDENTIFIER、NAS-IP-Address、およびNAS-IPV6-Address属性の1つ以上が含まれる必要があります。NASは複数のIPアドレスを持つことができるため、AAAプロトコル交換と安全性の関連性プロトコル会話の両方で、認証器を明示的に識別するためにNAS-IDENTIFIER属性が推奨されます。
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 IDENTIFIERを使用します。
(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アドレスを共有できますが、異なるPeer-IDを利用できます。
(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）は[IEEE-802.11]で発生します。これは、4ウェイハンドシェイク内でピアおよび認証機MACアドレスを利用します。[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) AuthenticatorとPeerを識別するために使用される低層パラメーターを指定します。前述のように、エンドポイントまたはポート識別子は、複数のポートを持つことができる場合、認証器またはピアを識別するために推奨されません。
(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内のピアと認証器の間の低層のアイデンティティを通信します。これにより、ピアと認証者は、キーキャッシュが使用されている場合にキースコープを決定できます。
(h) Communicate the lower-layer authenticator identity between the authenticator and backend authentication server within the NAS-Identifier Attribute.
(h) NAS-Identifier属性内のAuthenticatorとBackEnd認証サーバーの間で低層認証器の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) フェーズ1Aのチャネルバインディング（サポートされている場合）内に低層のアイデンティティを含め、EAPピアとサーバーの間で通信されるようにします。
(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) Authenticatorsは、EAPキーイングマテリアルおよびパラメーターとともに関連する認可をキャッシュし、各ネットワークアクセスのピアに許可を適用する必要があります。これにより、攻撃者は、仮想認証機の間でキーキャッシュが共有されている場合でも高度な特権を取得できなくなり、ピアは別の仮想認証機関で使用されるために作成されたキーキャッシュエントリを使用して、1つの仮想認証器へのアクセスを取得できます。
(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応答/IDで提供されるIDは、[ネットワークアクセス識別子] [RFC4282]セクション2で説明されているプライバシー識別子になります。（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ピアが[RFC3579]に記載されているように、EAP応答/IDine内のネットワークアクセスID（NAI）を提供する場合、Authenticatorは、EAP応答/IDに含まれるNAIをアクセス内に含まれるユーザー名属性にコピーします。-リクエスト。Access-Requestがバックエンド認証サーバーに向けられているため、AAAプロキシは、ユーザー名属性に含まれるNAIから装飾を削除します。Access-Requestにカプセル化されたEAP応答/アイデンティティ内に含まれるNAIは、変更されていません。その結果、Access-RequestがBackEnd認証サーバーに到着すると、EAP応答/IDはユーザー名属性（装飾の一部またはすべてが削除される可能性があります）と異なる場合があります。Peer-IDがない場合、バックエンド認証サーバーは、PEER IDとして、EAP応答/IDではなく、ユーザー名属性のコンテンツを使用する必要があります。
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.
EAPメソッドによって複数のPeer-IDがエクスポートされる可能性があります。たとえば、ピア証明書には複数のピアアイデンティティを含めることができます。トンネル法では、ピアアイデンティティは外側と内なる交換の両方で認証され、これらのアイデンティティはタイプと内容が異なる可能性があります。たとえば、外側の交換は、相対的な著名な名前（RDN）の形でピアIDを提供できますが、内なる交換はNAIまたはMACアドレスを介してピアを識別できます。EAPキーイング材料が外側の交換のみから決定されている場合、外側のピアIDのみがエクスポートされます。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を含めることができます。トンネル方式では、サーバーのアイデンティティは外側と内なる交換の両方で認証される可能性があり、これらのアイデンティティはタイプと内容が異なる可能性があります。たとえば、外側の交換はIPアドレスの形でサーバーIDを提供できますが、内部交換は完全に資格のあるドメイン名（FQDN）またはホスト名を介してサーバーを識別できます。EAPキーイング材料が外側の交換のみから決定される場合、外側サーバーIDのみが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に示すように、Authenticatorを複数の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サーバーで構成できます。また、Authenticatorは、リクエストが送信されるEAPサーバーを動的に決定できます。通信障害が発生した場合、認証者は別のEAPサーバーに失敗する可能性があります。たとえば、図3では、Authenticator2は最初にEAP Server1をプライマリバックエンド認証サーバーとして、EAP Server2をバックアップとして構成できますが、EAP Server1が利用できなくなった場合、EAP Server2はプライマリサーバーになります。
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ピアは認証の試みを領域内の特定のEAPサーバーに指示することはできません。この決定はAAAクライアントによって行われ、PeerがEAPメソッドの開始前にどのEAPサーバーが通信するかを決定することもできません。会話。Server-IDはEAP-Request/IDには含まれておらず、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] 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ピアは、新しい認証機に接続するか、同じ認証者に再接続することで、異なるEAPサーバーと通信することができます。[RFC3748]セクション7.2で定義されている高速再接続は、ピアが通信するEAPサーバーがセキュリティ協会を最初に確立したEAPサーバーと同じではない場合に失敗する可能性があります。たとえば、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メソッドが非ヌルサーバーIDを提供するわけではありません。一部の方法では、EAPピアがEAPサーバーが長期的な秘密を持っていることを確認できるが、EAPサーバーのIDは提供されないことを確認できます。この場合、EAPピアは、AuthenticatorがEAPサーバーによって承認されていることを知っていますが、EAPサーバーのIDは確認されません。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サーバーのIDを検証することで、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）と同一ではない可能性があります。証明書ベースの認証が半径または直径内で使用されている場合、バックエンド認証サーバー証明書で使用されている件名がServer-IDまたはバックエンド認証サーバーFQDNと同一ではない可能性があります。AuthenticatorはEAPピアとサーバーの間で使用されるアイデンティティを認識しないため、これは通常、EAPでは問題ではありません。ただし、Authenticatorが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がBackEnd Authentication Server証明書のsubjectaltnameと異なる場合、AAAクライアントが正しいバックエンド認証サーバーと話しているかどうかを判断できない可能性があります。サーバーIDとバックエンド認証サーバーFQDNが異なる場合、キースコープ（PEER-ID（S）、Server-ID（S））およびEAP会話識別子（SESSION-ID）の組み合わせが十分ではない可能性があります。キーがどこに存在するかを判断します。たとえば、Authenticatorは、IPアドレス（RADIUSで発生するように）でバックエンド認証サーバーを識別するか、完全に適格なドメイン名（直径）を使用して識別できます。Server-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:
[RFC3748]で定義されているEAPは、重要な派生をサポートしていますが、低層セキュリティ協会の管理を提供していません。機能の欠落は次のとおりです。
(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) 再キー。EAPは、EAPの再認証なしでエクスポートされたEAPキーイング材料の再キーをサポートしていませんが、EAPメソッドは[RFC3748]セクション7.2.1で定義されている「高速再接続」をサポートできます。
(c) Key delete/install semantics. EAP does not synchronize installation or deletion of keying material on the EAP peer and authenticator.
(c) キー削除/インストールセマンティクス。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キーイング材料がキャッシュされている場合、TSKは再利用できます。
These deficiencies are typically addressed via a post-EAP handshake known as the Secure Association Protocol.
これらの欠陥は、通常、Secure Associationプロトコルとして知られる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) エンティティネーミング。安全な関連プロトコルの基本的な特徴は、交換に従事する当事者の明示的な命名です。明示的な識別がなければ、交換に従事する当事者は特定されておらず、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キーイング材料の所持の相互証拠。Secure Associationプロトコル中、EAPピアと認証者は、ピアと認証器が承認されていることを実証するために、バックエンド認証サーバーと認証器（例：MSK）の間で輸送されるキーイング材料の所有を実証する必要があります。相互の所有証明は相互認証と同じではないため、ピアはこの交換の結果として認証機のアサーション（認証機のアイデンティティを含む）を検証することはできません。認証機のIDの確認については、セクション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) 安全な機能交渉。発見段階でのスプーフィングから保護するために、「最良の」シファースイートの選択を確保し、交渉されたセキュリティパラメーターの鍛造から保護するために、安全な協会プロトコルは安全な機能交渉をサポートする必要があります。これには、使用法モードの安全なネゴシエーション、セッションパラメーター（セキュリティ協会識別子（SAITS）および主要な寿命など）、ciphersuites、および必要なフィルターが含まれます。すべての機能交渉メッセージの保護を再生します。
(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ピアと認証者が特定のタイプの複数のキーを共有することが可能です。その結果、Secure Association Protocolは、所有権の証明で使用されているキーに明示的に名前を付ける必要があります。セクション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.
フェーズ2セキュリティアソシエーションの正しい処理をサポートするために、セキュアーアソシエーション（フェーズ2）プロトコルは、フェーズ2セキュリティアソシエーションと関連する過渡セッションキーの命名をサポートする必要があります。与えられたパケット。また、フェーズ2セキュアアソシエーションプロトコルは、一時的なセッションキーのアクティブ化をサポートする必要があり、削除をサポートする必要があります。これにより、過渡セッションキーの確立と再確立を当事者間で同期できるようにします。
(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.
(e) 新鮮な一時的なセッションキー（TSK）の生成。下層がキーイング材料のキャッシングをサポートする場合、EAPピアロワーレイヤーは、前のセッションで導き出されたキーイング素材を使用して新しいセッションを開始できます。TSKは、エクスポートされたEAPキーイング材料の一部のみに由来する場合、これにより、基礎となるCiphersuiteが攻撃にさらされる可能性のあるセッションキーが再利用されます。
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.
キーイング材料のキャッシュがサポートされている下層層では、安全な関連付けプロトコルフェーズが必要であり、バックエンド認証サーバーが提供する輸送されたキーイング材料が新鮮でない場合でも、新鮮なユニキャストとマルチキャストTSKの派生をサポートする必要があります。これは通常、NoncesまたはCountersの交換を介してサポートされます。これは、新鮮なユニキャスト（フェーズ2a）および場合によってはマルチキャスト（フェーズ2b）セッションキーを生成するために、キーイング材料と混合されます。エクスポートされたEAPキーイング材料を直接使用して直接使用してデータを保護することにより、Secure Associationプロトコルは妥協から保護します。
(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で寿命が交渉されたことです。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) 重要な状態再同期。ピアまたは認証者がリソースを再起動または回収したり、部分をクリアするか、すべての主要なキャッシュを再起動したりすることができます。したがって、キーライフタイムの交渉は、キーキャッシュが同期したままであることを保証することはできません。また、ピアが認証器キャッシュ内に存在するかどうかを使用する前に、ピアが決定することは不可能かもしれません。したがって、EAP下層が、SAPを介して、または下層指示を使用して、キー状態再同期のメカニズムを提供することをお勧めします（[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ピアや認証者と同じ低層層ソースまたは宛先アドレスを持っているわけではありません。また、ピアと認証者は複数のセキュリティ関連を交渉することが可能です。異なるトラフィックプロファイル。この場合、保護されたトラフィックのプロファイルは明示的に交渉する必要があります。たとえば、IKEV2では、イニシエーターとレスポンダーが認証にEAPを利用し、イニシエーターとレスポンダー以外のホストから発生するトラフィックの通過を許可するトンネルモードセキュリティ協会（SA）と交渉することが可能です。同様に、IEEE 802.16Eでは、サブスクライバーステーション（SS）は、添付されているローカルエリアネットワーク（LAN）に由来するベースステーション（BS）にトラフィックを転送できます。これを有効にするために、IEEE 802.16E内のセキュリティ関連は、EAPピアおよび認証機MACアドレスではなく、接続識別子（CID）によって識別されます。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ピアと認証者間のセキュリティ関連の確立に関係しているため、これらの当事者のみが一時的なセッションキーを「知る必要があります」。Secure Association Protocolは、ピアと認証者の間で直接動作する必要があり、バックエンド認証サーバーに渡されるか、追加のパーティーを含める必要があります。
(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つの別々のフェーズ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キーイング材料は、特定の認証機とピアポートに本質的にバインドされていませんが、TSKは安全な協会のプロトコルによって特定の認証機とピアポートにバインドされる場合があります。ただし、TSKの鮮度が保証されている場合、下層は複数のピアおよび/または認証装置ポートで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では、バックエンド認証サーバーは、キーイン素材が有効な承認された呼び出しまたは呼び出しステーションIDおよび/または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) バックエンド認証サーバーがキースコープを制限する属性を提供する場合、制限をピアに認証者から安全に伝達することをお勧めします。これは、Secure Association Protocolを使用して実現できますが、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下層層では、派生キーイング材料（TSKを含む）の最大寿命は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.
TSKがエクスポートされたEAPキーイング材料に由来する、または包まれている場合、そのエクスポートされたEAPキーイング材料の妥協は、TSKの妥協を意味します。したがって、EAPキーイング素材が古くなっていると見なされる場合、EAPの再認証を開始するだけでなく、TSKを含む児童鍵の交換も必要です。
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キーイング材料がエンティティ認証にのみ使用されるが、TSK派生には使用されない場合（IKEV2のように）、エクスポートされたEAPキーイング材料の妥協はTSKの妥協を意味しません。それにもかかわらず、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カウンターをリセットしますが、パーティーを再度認証することはありません（認証またはEAPペイロードは関係していません）...これは、IKE_SAとChild_SASの新しいキーも確立することを意味します。したがって、再認識よりも頻繁に再開することができますが、「認証寿命」が「キーライフタイム」よりも短い状況は意味がありません。
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.
頻繁に使用される子キー（交通保護に使用されるTSKなど）は、依存しているエクスポートされたEAPキーイング材料よりも早く有効になる可能性があるため、EAPの前に子キーの鍵をサポートすることが有利です。認証。MSK/EMSKの削除は、必ずしもTSKまたはチャイルドキーの削除を意味するわけではないことに注意してください。
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 Rekeyが発生する必要があります。同様に、TSKは、ティックが再キーキングまたはキャッシュするにもかかわらず、TEKと暗号化的に分離したままでなければなりません。これにより、TEKの妥協がTSKの妥協に直接導くことを防ぎ、その逆も同様です。
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]。たとえば、TLS（EAP-TLS [RFC5216]など）に基づくEAPメソッドは、通常、かなりの期間にわたってTLSマスターシークレットを導き出し、キャッシュします。EAPメソッド内で計算された他のローカルEAPキーイング材料の寿命は、この方法で定義されます。一般的に、高速再接続を使用する場合、元の長期資格がまだピアの所有物にあるという保証はないことに注意してください。たとえば、EAP-TLの秘密鍵を保持しているスマートカードが削除された可能性があります。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]や直径[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]の直径の場合に定義されます。EAPが認証に使用される場合[RFC3580]セクション3.17は、RADIUS-REQUESTの終端アクション値とともにアクセスアセプトで送信されたセッション時間アウト属性が、EAP REの前に提供されるサービスの最大秒数を指定していることを示しています。 - 認証。
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の再認証が得られるかどうかは、終端 - アクション属性の値によって制御されます。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ライフタイムはしばしば認証機リソースによって決定され、バックエンド認証サーバーはCiphersuiteの独立性の原則によるTSK派生プロセスについての洞察を持っていないため、バックエンド認証サーバーがTSK派生プロセスのあらゆる側面を管理するのは適切ではありません。TSK Lifetimeを含む。
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.
低層メカニズムを使用して、キーイング素材の寿命をピアと認証者の間で交渉できるようにすることができます。これは、Secure Associationプロトコルを使用するか、低層輸送内で実現できます。
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.
安全な協会プロトコル交換の結果としてTSKが確立される場合、安全なアソシエーションプロトコルにはTSK ReKeyのサポートを含めることをお勧めします。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.
その後ネゴシエートされたCiphersuiteで使用するためのキーイング素材を提供するには、キーの導出をサポートするEAPメソッドは、少なくとも64オクテットのマスターセッションキー（MSK）をエクスポートし、少なくとも64オクテットの拡張マスターセッションキー（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を利用して、キーキャッシュの同期を改善できます。たとえば、最初に最も古いキーを削除して認証器がキーキャッシュを管理する場合、削除する最後のキーの相対的な作成時間を発見フェーズ内で宣伝し、ピアがキーイング材料が早期に期限切れになっているかどうかを判断できるようになります。Authenticatorキーキャッシュ。
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下層層はさまざまな方法でTSKを決定します。TSKの派生、暗号化、または認証にエクスポートされたEAPキーイング材料が利用されている場合、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は、BITSでの特定のレベルの攻撃抵抗について、必要なRSAまたはDHモジュールとBITSの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].
[RFC2548]で指定されたキーラップは、MD5ベースのストリーム暗号に基づいており、[RFC3579]セクション4.3で説明されているように、既知の問題があります。RADIUSは、パケットごとの認証や属性を隠すなど、複数の目的で共有秘密を使用して、各パケットに共有された秘密についてかなりの情報が公開されます。これにより、共有秘密が辞書攻撃にさらされます。MD5は、RADIUS応答認証器とメッセージ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共有秘密に基づく代替キーラップ手法の開発は、セキュリティを大幅に改善しません。その結果、[RFC3579]セクション4.2では、IPSECを介して半径を実行することを推奨しています。同じアプローチが直径EAP [RFC4072]で取得されます。これは、セクション4.1.3で、IPSECまたはTLSによって保護されるために、クリアテキストのEAP-Master-Session-Key-Value-Value-Value-Valueペア（AVP）を定義しています。
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）内では、通常、認証は認証ではありませんが、認証はサポートされていません。プロアクティブなキー分布は、[Mishrapro]、[IEEE-03-084]、および[ハンドオフ]で説明されています。
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ピアはEAP（フェーズ1A）またはAAA（フェーズ1B）交換を必要とせずに認証器に再攻撃することができます。ただし、発見（フェーズ0）およびセキュアーアソシエーションプロトコル（フェーズ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 Exchange（フェーズ1B）を排除できます。それ以外の場合は、短縮することもできますが、それでも必要です。コンテキスト転送プロトコルは、[IEEE-802.11F]（現在は非推奨）および「コンテキスト転送プロトコル（CXTP）」[RFC4067]で説明されています。「IEEE 802.11ワイヤレスLANS間の拳銃の高速認証方法」[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 Exchange（フェーズ1B）を排除できます。それ以外の場合は、短縮することもできますが、それでも必要です。IEEE 802.11i [IEEE-802.11i]の初期バージョンで最初に提案されたトークンベースのスキームは、[Token]、[Tokenk]、および[短期]で説明されています。
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の事前認定を完了できないか、それができる可能性があります。同じ認証器を使用して複数回前に事前に発症し、バックエンド認証サーバーの負荷が増加します。
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半径の使用ガイドライン」[RFC3580]で述べたように、EAPの免除から生じるAAA交換は、「EAPのRadiusサポート」[RFC3579]に記載されている通常の交換とはほとんど違いがありません。たとえば、IEEE 802.11 [IEEE-802.11]では、EAP事前認証の前に関連交換が発生しないため、SSIDは認証時に認証機によって知られていないため、アクセスリクエストには、呼び出されたものにSSIDを含めることができません。-station-id属性[RFC3580]セクション3.20で説明されています。
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前発見の試みを承認することを拒否したり、ピアが許可されているよりも多くの同時セッションに従事できるようにすることができます。Peerが添付しない認証器を使用して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ピアと認証器の間で輸送されたキーイング材料の所持の証拠のみを示しています。ハンドオフ中、バックエンド認証サーバーには、ピアが認証装置に正常に認証されたという証拠が提供されていません。代わりに、Authenticatorは、対応する認証交換セットなしで会計メッセージのストリームを生成します。[Mishrapro]で説明されているように、隣接グラフの知識は、認証交換の静的な構成または分析を介して確立できます。近隣グラフの腐敗を防ぐために、新しいNeighborグラフエントリは、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つの認証器の妥協が他の認証機の妥協をもたらさないようにするために、各認証機に輸送されるキーイング材料間の暗号化の分離を維持する必要があります。ただし、暗号化の分離が維持されている場合でも、認証因子を侵害する攻撃者は、他の認証器の操作を混乱させる可能性があります。[RFC3579]セクション4.3.7に記載されているように、AAAインフラストラクチャ内のスプーフィング検出がない場合、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.
AAA Exchange（フェーズ1B）の排除を可能にする高速ハンドオフ手法は、ユーザー認証と提供されたサービスの許可を含む、一般的なネットワークアクセスシナリオ（ダイヤルアップ、有線LANなど）とは根本的に異なります。AAA Exchange（フェーズ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?
BackEnd Authentication Serverは、ユーザー認証の決定を行う責任があります。これは、次の質問に答える必要があります。（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 Exchange（フェーズ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.
特権バックエンド認証サーバーの昇格は、多くの場合、条件付き評価を実行します。この評価では、アクセスアクセプトメッセージで返された承認は、認証機または時刻などの動的状態で条件付けられます。この状況では、AAA Exchangeをバイパスすると、制限がバックエンド認証サーバーによって提供された承認内で明示的にエンコードされない限り、不正アクセスを可能にする可能性があります。
A handoff mechanism that provides proper authorization is said to be "correct". One condition for correctness is as follows:
適切な承認を提供するハンドオフメカニズムは、「正しい」と言われています。正確性の条件の1つは次のとおりです。
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.
ハンドオフが「正しい」ためには、新しい認証が作成されたのと同じ承認を新しい認証者に確立する必要があります。
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属性を実装してはなりません。たとえば、ARAPサービスを提供できない認証機は、ARAPのRADIUS属性を実装してはなりません。認証者は、代わりに利用できないサービスをアクセス拒否として許可するRADIUSアクセスacceptを扱う必要があります。
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承認が提供されている場合、これらの認可を処理する必要があります。これにより、ハンドオフが失敗する必要があります。ただし、新しい認証機に不明な属性を含む認可が提供されている場合、これらの属性は無視される場合があります。「既知のがサポートされていないサービス」の定義には、利用できないセキュリティサービスに対するリクエストを含める必要があります。これには、[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の半径サポートは、[RFC3580]および[RFC4675]で説明されています。一部の認証者は動的VLANをサポートしているが他の人がそうでない場合、アクセスレクエストに存在する属性（NASポートタイプ、NAS-IP-Address、NAS-IPV6-Address、およびNas-Identifierなど）は、バックエンド認証サーバーは、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]で説明されています。半径の脅威モデルは[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) 攻撃者は、発見または安全なアソシエーションプロトコルフレーム、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) 攻撃者は、ネットワークへのアクセスを得るために中間の攻撃を試みることができます。
(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クライアントに必要な資格情報を取得できます。同様に、ピアが侵害または盗まれた場合、攻撃者は1つ以上の認証者と通信するために必要な資格情報を取得できます。[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 Authenticator（NAS IDENTIFIER）の身元が、それと通信するすべての関係者によって定義および理解される必要があります。[IEEE-802.11]、[IEEE-802.16E]、[IEEE-802.1X]、IKEV2 [RFC4306]、PPP [RFC1661]などのEAP低層仕様は、重要な共有を伴いません。
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資格情報（RADIUS共有秘密、IPSEC事前共有キーまたは証明書など）は、AAAクライアント間でAAAクライアント間で共有されてはなりません。サーバー、またはバックエンド認証サーバーを他の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.
長期資格情報の妥協キーイング材料（TSK、TEK、MSKなど）を取得する攻撃者は、基本を破ることなく、事前共有キー、パスワード、プライベートキーなどの長期的なユーザー資格情報を取得できない必要があります暗号化の仮定。[RFC4017]セクション2.2の必須要件には、EAPキーイング材料の生成、128ビットの効果的な強度、辞書攻撃に対する抵抗、共有状態の等価性、および中間攻撃に対する保護を備えた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メソッドは特定の暗号化アルゴリズムに依存する場合があります。特定の暗号化アルゴリズムの使用を交渉する能力は、特定の暗号化アルゴリズムの妥協に対する回復力を提供します。アルゴリズムの独立性は、定義されている場合は安全な関連プロトコルでも必要です。これは通常、プロトコルにアルゴリズムの識別子とパラメーターを含めること、およびプロトコル仕様にアルゴリズム要件を指定することによって達成されます。非常に望ましいものの、キー派生関数（KDF）をネゴシエートする能力は必要ありません。相互運用性のために、少なくとも1つのスイートの必須アルゴリズムを選択する必要があります。[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
Ciphersuiteの選択を確認します
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を満たす[RFC4017]を満たすEAPメソッドおよびトランスミッションレイヤーセキュリティを利用したAAAプロトコルは、ダウングレード攻撃に対処できます。[RFC3748]セクション7.2.1では、EAPメソッドがEAPメソッドの会話を保護するために使用される微粒子を交渉する能力を指すだけでなく、整合性を密接性を保護する「保護されている暗号化された微小り交渉」セキュリティの主張について説明します。[RFC4017]セクション2.2では、このセキュリティクレームを満たすEAPメソッドが必要です。TLS V1.2 [RFC5246]およびIKEV2 [RFC4306]は、キー導出関数（KDFS）の交渉をサポートするため、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を介した半径の使用により対処できます。
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を使用して下層を使用してアルゴリズムの独立性が必要です。相互運用性のために、少なくとも1つのスイートの必須アルゴリズムを選択する必要があります。キー派生のために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]は、データの保護のためのCiphersuiteの交渉をサポートしますが、メッセージの整合性チェック（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キー管理プロトコルの各当事者は、彼らが通信する他の当事者に認証されなければなりません。認証メカニズムは、認証プロセスで使用される秘密の値の機密性を維持する必要があります。セッションキーを確立するために安全なアソシエーションプロトコルを使用する場合、セッションキーを採用する低層プロトコル環境で意味のあるアイデンティティを使用して、安全なアソシエーションプロトコルに関与する当事者は自分自身を特定する必要があります。この状況では、認証者とピアは、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]や直径[RFC3588]などのAAAプロトコルは、AAAクライアントの識別のメカニズムを提供します。EAP Authenticatorと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プロトコル交換とSecure Association Protocolの会話において重要です。
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]は、メッセージ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 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].
安全なアソシエーションプロトコルフレームの偽造を防ぐために、すべてのメッセージでフレームごとの認証と整合性保護が推奨されます。IKEV2 [RFC4306]は、[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]と直径[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サーバーによって受信されたNAS-IP-Address、NAS-Identifier、またはNAS-IPV6-Address属性はソースアドレスに対応しません。[RFC3579]セクション4.3.7に記載されているように、最初のホッププロキシがAccess-Requestパケットのソースアドレスに対してNAS識別属性を確認しない場合、不正な認証者がNAS-IPアドレスを偽造する可能性があります[RFC2865]、NAS-IPV6-Address [RFC3162]、またはNAS-IDINTIFIER [RFC2865]属性は、別の認証因子になりすまします。呼び出されたステーション-ID [RFC2865]や呼び出しステーション-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の使用が必要ですが、これは完全に適格なドメイン名（FQDN）を利用するため、なりすまし検出にはDNS A、AAAA、およびPTRリソースレコード（RRS）を適切に構成する必要があります。その結果、直径は、この攻撃に対して半径と同じくらい脆弱です。[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会話内のパススルー認証器のIDを検証しません。Secure Associationプロトコル内では、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で説明されているように、最初のホップAAAプロキシが別の認証機になりすまそうとするAAAクライアントを検出することが可能です。ただし、AAAクライアントとして機能するパススルー認証機が、下層層を介してEAPピアに誤解を招く情報を通信しながら、バックエンド認証サーバーに正しい情報を提供することができます。
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-IDENIDEINTIFIERを利用できます。また、AAAクライアントとして機能するパススルー認証器は、AAAプロトコルを介してバックエンド認証サーバーに誤ったピアコールステーションID [RFC2865] [RFC3580]を提供できます。
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メソッドで対処できます（ただし、制限されていません）：Calltation-ID [RFC2865] [RFC3580]、呼び出し-Station-ID [RFC2865] [RFC3580]、Nas-Identifier [RFC2865]、NAS-IP-Address [RFC2865]、およびNaS-IPV6-Address [RFC3162]。
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メソッドは、ピアの下層からチャネル結合パラメーターをインポートし、それらをEAPサーバーにしっかりと送信し、それらを下層層またはAAA層にエクスポートします。ただし、EAPサーバーからピアまでの輸送は発生するか、双方向になる可能性があります。チャネルバインディングが検証されている交換（ピアまたはサーバー）の側面では、下層またはAAA層が検証の結果（TrueまたはFalse）の結果をEAPメソッドまで渡します。検証はピアまたはサーバーのいずれかによって行われますが、通常、単に平等を検証するのではなく、値の正確性を判断するための知識を持っています。詳細については、[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バインディング]で説明されているように、EAPメソッドシーケンスと複合認証メカニズムは、中間攻撃の対象となります。そのような攻撃が正常に実行されると、攻撃者は被害者と正当な認証者の間の仲介者として機能します。これにより、攻撃者は認証機に正常に認証され、ネットワークへのアクセスを取得できます。
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バインディング]は、EAPピアとサーバーがEAP交換全体に参加したことを証明できる複合キーの導出を推奨しています。化合物キーは、認証機としての攻撃者に知られていない必要がありますが、EAPキーイング材料に由来する必要があるため、EMSKの一部から複合キーを導出することが望ましい場合があります。これが行われる場合、適切なキー衛生を提供するために、中間の保護に使用される化合物キーは、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]もパケットごとの認証と完全性保護を提供します。Authenticator/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では、Authenticator/AAAクライアントとバックエンド認証サーバーが直接通信しない場合に発生するセキュリティの問題について説明します。AAA仲介者が存在する場合（RADIUSプロキシや直径エージェントなど）、データオブジェクトのセキュリティが使用されていない場合、輸送されたキーイング材料は、仲介者を制御する攻撃者によって回収できます。セクション2.1で説明したように、TSKがEAPキーイング材料（IKEV2のように）とは独立して導出されない限り、輸送されたキーイング材料の所持により、ピアとキーイン材料が輸送された認証者との間で送られたデータトラフィックの復号化が可能になります。また、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.
Secure Association Protocolは、EAPピアと認証者の間の相互認証を提供せず、輸送されたキーイング材料の所持の相互証明のみを提供します。ピアが認証者の身元を検証するためには、相互の所持の証明をなりすましの予防とチャネル結合と組み合わせる必要があります。なりすまし防止（セクション5.3.2で説明）により、バックエンド認証サーバーは、輸送されたキーイング材料が正しい認証器に提供されていることを判断できます。なりすまし防止とともに利用されると、チャネルバインディング（セクション5.3.3で説明）により、EAPピアはEAPサーバーが認証者に輸送されたキーイング材料を所有することを許可していることを確認できます。Secure Association Protocol Exchangeの完了は、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のアイデンティティが含まれます。認証交換とAAAプロトコルでこれらの関係者を識別するために、1つの（またはそれ以上の）名前フォームが必要です。セッションキーを採用する下層内のこれらの関係者を識別するために、別の名前フォームが必要になる場合があります。
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）は、キーイング材料とともにエクスポートされるPeer-ID（S）およびServer-ID（S）に結合されます。ただし、すべてのEAPメソッドが認証されたサーバーのアイデンティティをサポートするわけではありません（付録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.
AAAプロトコル内では、輸送されたキーイング材料は、リクエスト内のNAS-IDENTIFIER属性によって識別されたEAP認証器用に運命づけられており、Peer-ID（s）、ユーザー名[RFC2865]によって識別されるEAPピアによって使用されます。または課金可能なユーザーID（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.
要件：Secure Association Protocol（フェーズ2）の会話は、EAP会話（フェーズ1A）の異なる識別子を利用する可能性があるため、EAPと安全な関連付けプロトコルのアイデンティティが必要です。
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チェーンの各リンクがなりすましに対するチェックを実装しない限り、ある認証者は別の認証者になりすまします。これらのチェックが整っていても、認証者は、ピアとバックエンド認証サーバーに異なるアイデンティティを請求する場合があります。[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;
o SSID制限。キーイング材料は、特定のIEEE 802.11 SSIDでのみ使用できます。
o Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID; and
o ステーション-ID制限と呼ばれ、キーイング材料は単一のIEEE 802.11 BSSIDでのみ使用できます。と
o Calling-Station-ID restrictions, where the keying material can only be used with a single peer IEEE 802 MAC address.
o キーイン素材は、単一のピアIEEE 802 MACアドレスでのみ使用できます。
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キーキーキーキーの材料の所有を証明していることをバックエンド認証サーバーに確認することができます。Secure Associationプロトコルは、それを取得することを許可されました。
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 Exchangeは、AAAクライアント/認証者にEAPピアに関する認可を提供しますが、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メソッド内で異なる識別子を利用し、Associationプロトコルの安全な会話を安全に使用する場合、Peer Authorizationは、追加の制限なしに認証者に実証することが困難です。この問題は、IKEV2とEAP内のピア識別にアイデンティティペイロードが使用され、EAP会話がIKEV2およびIKEV2交換を結合するIKEV2内で暗号化されている場合、IKEV2には存在しません。ただし、[IEEE-802.11]内では、EAPピアアイデンティティは4ウェイハンドシェイク内では使用されていないため、AuthenticatorがEAPピアが4-と同じMACアドレスをEAP認証に使用することを要求する必要があります。方法の握手。
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、EAP、Secure Associationプロトコル交換など、AAAキーマネジメントプロトコル交換は、リプレイ保護されている必要があります。リプレイ保護により、プロトコルメッセージ受信者は、以前の正当な対話中に記録されたメッセージを破棄し、現在の対話に属しているかのように提示されます。
[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.
Access-Requestパケットでは、Authenticator値は16オクテットの乱数で、リクエストAuthenticatorと呼ばれます。
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.
ただし、一部の半径パケットはリプレイ保護されていません。アカウンティング、切断、および住所（COA） - リクエストパケットでは、リクエストAuthenticatorには、非CEではなくキー付きメッセージ整合性コード（MIC）が含まれています。アカウンティング、切断、およびCOA応答パケットの応答認証機には、要求パケットまたは応答パケットのいずれのノンセに依存しないキー付きマイクも含まれています。したがって、イベントタイムスタンプ属性が含まれている場合、または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.
セッションキーは互いに依存してはなりません。複数のセッションキーは、通常、NonCEと呼ばれる1回限りの値が、各セッションキーが新鮮であることを確認するために使用される限り、高レベルの共有秘密から導き出される場合があります。セッションキーを生成するために使用されるメカニズムは、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メソッドは、1つの当事者が高品質の乱数ジェネレーターを持っていない場合でも、MSKとEMSKの新鮮さを確保する必要があります。推奨される方法は、各当事者がMSKとEMSKの派生に使用される少なくとも128ビットの非CEを提供することです。
The contribution of nonces enables the EAP peer and server to ensure that exported EAP keying material is fresh.
Noncesの貢献により、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]は、これらのクレームをサポートするEAPメソッドと、128ビット以上の同等のキー強度を提供できる方法を必要とします。キー強度の詳細については、セクション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の会話を区別できるようにします。ただし、AuthenticatorがEAP Session-IDを追跡しない限り、Authenticatorはセッション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キーイング素材とパラメーターがキャッシュされている場合でも、ピアまたは認証機に高いエントロピー乱数ジェネレーターを欠いている場合でも、各セッションの新しいセッションキーを生成する必要があります。推奨される方法は、それぞれのピアと認証装置がセッションキー派生で使用されるノンセまたはカウンターを提供することです。非CEを使用する場合は、少なくとも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キーイング材料を導き出します。Secure Association Protocol Exchangeでは、EAPピアはキーイング素材を利用して、AuthenticatorにEAPサーバーに認証され、それによって許可されたのと同じパーティーであることを認証者に実証します。EAP Authenticatorは、EAPの会話がそれを介して輸送されただけでなく、EAPサーバーによってユニークに許可されていることだけでなく、EAPの会話が輸送されたことだけでなく、ピアに証明するために、輸送されたキーイング素材を利用しています。ネットワークへのアクセスをピアに提供します。EAP Authenticatorが輸送されたキーイング資料をEAPピアおよびサーバー以外のパーティーと共有しない場合にのみ、独自の承認を実証できます。TSKは、EAPピアと認証者のみがアクセスすることが許可されています（セクション1.5を参照）。TSK派生については、セクション2.1で説明します。Secure Association Protocol Exchange内での承認の実証は、輸送されたキーイング材料の所持に依存しているため、バックエンド認証サーバーは、送信後に輸送されたキーイング材料を削除しない限りTSKを取得できます。
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.
EAPキー名（セクション1.4.1で定義）と、Peer-ID（S）およびServer-ID（S）とともに、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-Key-Name AVPを定義しています。EAP-Key-Name AVPは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.
Authenticatorには、既存のバックエンド認証サーバーの実装により、輸送されたキーイング素材の名前が提供されていないため、既存のSecure AssociationプロトコルはEAPキー名を使用しません。たとえば、[IEEE-802.11]はPMKキャッシングをサポートしています。ピアと認証者がキャッシュされたPMKを決定できるようにするには、4ウェイハンドシェイク内で利用できるようにするには、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ピアによって作成された永続的な状態を制限できます。たとえば、PEERごとに、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.
新しいTSKの作成が、以前に導出されたTSKの削除を意味するかどうかは、EAP下層に依存します。暗黙の削除がない場合、認証者は、ピアごとに保存できるTSKと関連状態の数を制限することを選択できます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（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。and 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] Pack、S。and Y. Choi、「IEEE 802.1xモデルに基づく公共のワイヤレスLANでの事前認証の高速ハンドオフ」、IFIP TC6/WG6.8個人ワイヤレス通信に関するワーキング会議、p.175-182、2002年10月23〜25日。
[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ワークショップに関するワイヤレスセキュリティワークショップの議事録、pp。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.、Prasad、A.、Wang、H。、およびP. Schoo、「IEEE 802.11 Wireless LANS間の携帯用の高速認証方法」、2番目のACMの議事録2004年10月、WLANホットスポットに関するワイヤレスモバイルアプリケーションとサービスに関する国際ワークショップ。
[GKDP] Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group Key Distribution Protocol", Work in Progress, March 2006.
[GKDP] Dondeti、L.、Xiang、J。、およびS. Rowles、「GKDP：Group Key Distribution Protocol」、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.、Datta、A。Derek、A。and J. C. Mitchell、「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 Standard 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 Standard 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標準：仮想ブリッジ付きローカルエリアネットワークのドラフト標準、P802.1Q-2003、2003年1月。
[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：固定およびモバイルブロードバンドワイヤレスアクセスシステムのエアインターフェース：固定とモバイルの組み合わせの物理的および中程度アクセス制御レイヤーの修正ライセンスバンドでの運用 "IEEE 802.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] Mishra、A.、Shin、M.、Arbaugh、W.、Lee、I。、およびK. Jang、「迅速かつ安全なローミングをサポートするためのプロアクティブなキーディストリビューション」、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.
[ハンドオフ] 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] Ohba、Y.、Parthasrathy、M。、およびM. Yanagiya、「キー導出におけるパラメーター結合に基づくチャネル結合メカニズム」、2007年6月、進行中の作業。
[EAP-BINDING] Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, "The Compound Authentication Binding Problem", Work in Progress, October 2003.
[EAPバインディング] Puthenkulam、J.、Lortz、V.、Palekar、A。、およびD. Simon、「複合認証結合問題」、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] Klima、V。、「ハッシュ機能のトンネル：1分以内のMD5衝突」、Cryptology Eprint Archive、2006年3月、http：//eprint.iaid.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] Mishra、A.、Shin、M。and W. Arbaugh、「隣接グラフを使用したプロアクティブキー分布」、IEEE Wireless Communications、Vol。11、2004年2月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968] Meyer、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] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.、Carrel、D.、Simone、D.、およびR. Wheeler、「PPPをイーサネット上に送信する方法」、RFC 2516、2月1999年。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor固有の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. Simon、「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.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、2000年5月、RFC 2845。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and 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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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. Calhoun、「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.、Smith、A.、Zorn、G。、およびJ. Roese、「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] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、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] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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.、Ed。、Nakhjiri、M.、Perkins、C。、およびR. Koodli、「Context Transfer Protocol（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.、Ed。、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（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] Yang、L.、Zerfos、P。、およびE. Sadot、「ワイヤレスアクセスポイントの制御とプロビジョニングのための建築分類（CAPWAP）」、RFC 4118、2005年6月。
[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.、ed。、およびJ. Salowey、ed。、「モバイルコミュニケーションのためのグローバルシステムのための拡張可能な認証プロトコル法（GSM）サブスクライバーIDモジュール（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.、Bari、F.、およびP. Eronen、「拡張可能な認証プロトコル（EAP）のアイデンティティ選択ヒント」、RFC 4284、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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、「chargeable user Identity」、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. Moore、「ポイントツーポイントプロトコル（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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、2006年6月。
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", RFC 4763, November 2006.
[RFC4763] Vanderveen、M。およびH. Soliman、「共有秘密認証と主要な設立（EAP-Sake）のための拡張可能な認証プロトコル法」、RFC 4763、2006年11月。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon、P.、Sanchez、M。、およびB. Aboba、「仮想LANおよび優先サポートの半径属性」、RFC 4675、2006年9月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P。およびP. Hoffman、「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プロトコル：Pre-Shared Key Extensible認証プロトコル（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.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「Remote Authentication Dial in User Service（RADIUS）への動的認証拡張」、RFC 5176、2008年1月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216] Simon、D.、Aboba、B。、およびR. Hurst、「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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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 Conference on Computer Communications
[Tokenk] Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover Keying: A Media-Independent Handover Key Management Architecture", Mobiarch 2007.
[Tokenk] Ohba、Y.、Das、S。、およびA. Duttak、「Kerberized Handover Keying：メディアに依存しないハンドオーバーキー管理アーキテクチャ」、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、Charlie Kaufman、MicrosoftのTim Moore、EricssonのJari Arkko、Aruba NetworksのDorothy Stanley、TrusecureのBob Moskowitz、IntelのJesse Walker、CiscoのJoe Salowey、およびVigil Secuard of Vigil 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メソッドについて、Session-ID、Peer-ID、Server-ID、およびキーライフタイムを指定しています。将来のEAPメソッド仕様には、Session-ID、Peer-ID、Server-IDの定義を含める必要があります（ヌル文字列になる可能性があります）。以下の説明では、セッションIDを含むすべてのフィールドは、ネットワークバイトの順序であると想定されています。
EAP-Identity
EAP-ID
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 IDENTITYメソッドは[RFC3748]で定義されています。キーを導き出さないため、セッションIDを定義しません。Peer-IDおよびServer-IDは、null文字列（長さゼロ）です。
EAP-Notification
eap-notification
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-notificationメソッドは[RFC3748]で定義されています。キーを導出せず、したがってセッションIDを定義しません。Peer-IDおよびServer-IDは、null文字列（長さゼロ）です。
EAP-MD5-Challenge
EAP-MD5-Challenge
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-Challengeメソッドは[RFC3748]で定義されています。キーを導出せず、したがってセッションIDを定義しません。Peer-IDおよびServer-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を定義しません。Peer-IDおよびServer-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を定義しません。Peer-IDおよびServer-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 SESSION-IDは、AT_RAND属性のRANDフィールドの内容とEAPタイプコード（0x17）の連結であり、その後、AT_AUTN属性のAUTNフィールドの内容が続きます。
Session-Id = 0x17 || RAND || AUTN
session-id = 0x17 ||ランド||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).
ただし、PEER-IDは、AT_IDENTITY属性のIDフィールドの内容であり、最初から実際のIDの長さのオクテットのみを使用しています。コンテンツは、送信されたアイデンティティが永続的、仮名、または高速な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 Session-IDは、AT_RAND属性からのRANDフィールドの内容とEAPタイプコード（0x12）とAT_NONCE_MT属性のnonCE_MTフィールドの内容を連結することです。
Session-Id = 0x12 || RAND || NONCE_MT
session-id = 0x12 ||ランド||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).
ただし、PEER-IDは、AT_IDENTITY属性のIDフィールドの内容であり、最初から実際のIDの長さのオクテットのみを使用しています。コンテンツは、送信されたアイデンティティが永続的、仮名、または高速なEAP再認証アイデンティティであるかどうかに関係なく、送信されるときに使用されることに注意してください。サーバーIDはnull文字列（長さゼロ）です。
EAP-PSK
EAP-PSK
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 Session-IDは、Peer（RAND_P）およびServer（RAND_S）NONCESとのEAPタイプコード（0x2F）の連結です：
Session-Id = 0x2F || RAND_P || RAND_S
session-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.
Peer-IDはID_Pフィールドの内容であり、Server-IDはID_Sフィールドの内容です。
EAP-SAKE
EAPセイク
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-Sake Session-IDは、AT_RAND_S属性のRAND_SフィールドのコンテンツとのEAPタイプコード（0x30）の連結であり、その後、AT_RAND_P属性のRAND_Pフィールドの内容が続きます。
Session-Id = 0x30 || RAND_S || RAND_P
session-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-Sake Session-IDは、サーバーが選択した「セッションID」パラメーターと同じではないことに注意してください。サーバーは最初のメッセージで送信され、後続のメッセージで再現されています。PEER-IDは、AT_PeerID属性の値フィールドに含まれており、使用可能な場合はAT_SERVERID属性の値フィールドに含まれています。
EAP-TLS
EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [RFC5216].
EAP-TLSの場合、PEER-ID、Server-ID、およびセッションIDは[RFC5216]で定義されています。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052
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
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。