[要約] RFC 5836は、EAPの早期認証の問題を述べたものであり、EAPの拡張可能な認証プロトコルの要件を定義している。 目的は、EAPの早期認証に関連する問題を特定し、セキュリティとパフォーマンスの向上を図るためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) Y. Ohba
Request for Comments: 5836 Toshiba
Category: Informational Q. Wu, Ed.
ISSN: 2070-1721 Huawei
G. Zorn, Ed.
Network Zen
April 2010
Extensible Authentication Protocol (EAP) Early Authentication Problem Statement
拡張可能な認証プロトコル（EAP）アーリー認証問題ステートメント
Abstract
概要
Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail.
拡張可能な認証プロトコル（EAP）早期認証は、到着前にターゲットアタッチメントポイントに認証されたキーイング材料を確立するために、モバイルデバイスによるEAPの使用として定義される場合があります。このドキュメントでは、EAP早期認証の問題について詳しく説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5836.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5836で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Problem Statement ...............................................6
3.1. Handover Preparation .......................................6
3.2. Handover Execution .........................................6
3.2.1. Examples ............................................7
3.3. Solution Space .............................................7
3.3.1. Context Transfer ....................................7
3.3.2. Early Authentication ................................8
4. System Overview .................................................8
5. Topological Classification of Handover Scenarios ................9
6. Models of Early Authentication .................................10
6.1. EAP Pre-Authentication Usage Models .......................10
6.1.1. The Direct Pre-Authentication Model ................11
6.1.2. The Indirect Pre-Authentication Usage Model ........11
6.2. The Authenticated Anticipatory Keying Usage Model .........13
7. Architectural Considerations ...................................13
7.1. Authenticator Discovery ...................................13
7.2. Context Binding ...........................................14
8. AAA Issues .....................................................14
9. Security Considerations ........................................16
10. Acknowledgments ...............................................17
11. Contributors ..................................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................18
When a mobile device, during an active communication session, moves from one access network to another and changes its attachment point, the session may be subjected to disruption of service due to the delay associated with the handover operation. The performance requirements of a real-time application will vary based on the type of application and its characteristics such as delay and packet-loss tolerance. For Voice over IP applications, ITU-T G.114 [ITU] recommends a steady-state end-to-end delay of 150 ms as the upper limit and rates 400 ms as generally unacceptable delay. Similarly, a streaming application has tolerable packet-error rates ranging from 0.1 to 0.00001 with a transfer delay of less than 300 ms. Any help that an optimized handoff mechanism can provide toward meeting these objectives is useful. The ultimate objective is to achieve seamless handover with low latency, even when handover is between different link technologies or between different Authentication, Authorization, and Accounting (AAA) realms.
アクティブな通信セッション中にモバイルデバイスが1つのアクセスネットワークから別のアクセスネットワークに移動し、添付ファイルポイントを変更すると、ハンドオーバー操作に関連する遅延によりセッションがサービスの混乱にさらされる場合があります。リアルタイムアプリケーションのパフォーマンス要件は、アプリケーションのタイプと遅延やパケット損失の耐性などのその特性によって異なります。Voice over IPアプリケーションの場合、ITU-T G.114 [ITU]は、上限として150ミリ秒の定常状態のエンドツーエンド遅延を推奨し、一般的に許容できない遅延として400ミリ秒のレートを推奨します。同様に、ストリーミングアプリケーションには、0.1〜0.00001の範囲の許容可能なパケットエラーレートがあり、転送遅延は300ミリ秒未満です。最適化されたハンドオフメカニズムがこれらの目的を達成するために提供できるヘルプは有用です。究極の目的は、異なるリンクテクノロジーの間で、または異なる認証、承認、会計（AAA）領域の間にハンドオーバーがある場合でも、低遅延でシームレスなハンドオーバーを達成することです。
As a mobile device goes through a handover process, it is subjected to delay because of the rebinding of its association at or across several layers of the protocol stack and because of the additional round trips needed for a new EAP exchange. Delays incurred within each protocol layer affect the ongoing multimedia application and data traffic within the client [WCM].
モバイルデバイスはハンドオーバープロセスを通過するため、プロトコルスタックのいくつかのレイヤーまたはいくつかのレイヤーにわたって関連性の再バインディングと、新しいEAP交換に必要な追加の往復により、遅延が発生します。各プロトコル層内で発生した遅延は、継続的なマルチメディアアプリケーションとクライアント内のデータトラフィックに影響します[WCM]。
The handover process often requires authentication and authorization for acquisition or modification of resources assigned to the mobile device. In most cases, these authentications and authorizations require interaction with a central authority in a realm. In some cases, the central authority may be distant from the mobile device. The delay introduced due to such an authentication and authorization procedure adds to the handover latency and consequently affects ongoing application sessions [MQ7]. The discussion in this document is focused on mitigating delay due to EAP authentication.
ハンドオーバープロセスでは、多くの場合、モバイルデバイスに割り当てられたリソースの取得または変更のための認証と承認が必要です。ほとんどの場合、これらの認証と認可には、領域内の中央当局との相互作用が必要です。場合によっては、中央当局がモバイルデバイスから離れている場合があります。このような認証と承認手順のために導入された遅延は、ハンドオーバーレイテンシを追加し、その結果、進行中のアプリケーションセッション[MQ7]に影響します。このドキュメントの議論は、EAP認証による遅延の緩和に焦点を当てています。
AAA
AAA
Authentication, Authorization, and Accounting (see below). RADIUS [RFC2865] and Diameter [RFC3588] are examples of AAA protocols defined in the IETF.
認証、承認、および会計（以下を参照）。半径[RFC2865]および直径[RFC3588]は、IETFで定義されているAAAプロトコルの例です。
AAA realm The set of access networks within the scope of a specific AAA server. Thus, if a mobile device moves from one attachment point to another within the same AAA realm, it continues to be served by the same AAA server.
AAAレルム特定のAAAサーバーの範囲内のアクセスネットワークのセット。したがって、モバイルデバイスが同じAAAレルム内の1つの添付ファイルポイントから別のポイントに移動すると、同じAAAサーバーによって引き続き提供されます。
Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation [RFC2989].
トレンド分析、監査、請求、またはコスト配分[RFC2989]を目的として、リソースの使用に関する情報を収集する行為を会計。
Attachment Point A device, such as a wireless access point, that serves as a gateway between access clients and a network. In the context of this document, an attachment point must also support EAP authenticator functionality and may act as a AAA client.
アタッチメントポイントアクセスクライアントとネットワークの間のゲートウェイとして機能するワイヤレスアクセスポイントなどのデバイス。このドキュメントのコンテキストでは、添付ファイルポイントはEAP認証機能機能もサポートし、AAAクライアントとして機能する必要があります。
Authentication The act of verifying a claimed identity, in the form of a preexisting label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication) [RFC2989].
認証は、相互に既知の名前空間からの既存のラベルの形で、メッセージ（メッセージ認証）のオリジネーターとして、またはチャネルのエンドポイント（エンティティ認証）[RFC2989]として、請求されたアイデンティティを検証する行為。
Authenticator The end of the link initiating EAP authentication [RFC3748].
Authenticator EAP認証を開始するリンクの終わり[RFC3748]。
Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential [RFC2989].
認可されたリソースへのアクセスなどの特定の権利が特定の資格情報の発表者に付与できるかどうかを判断する行為[RFC2989]。
Candidate Access Network An access network that can potentially become the target access network for a mobile device. Multiple access networks may be candidates simultaneously.
候補アクセスネットワークモバイルデバイスのターゲットアクセスネットワークになる可能性のあるアクセスネットワーク。複数のアクセスネットワークが同時に候補である場合があります。
Candidate Attachment Point (CAP) An attachment point that can potentially become the target attachment point for a mobile device. Multiple attachment points may be candidates simultaneously.
候補アタッチメントポイント（CAP）アタッチメントポイントは、モバイルデバイスのターゲットアタッチメントポイントになる可能性があります。複数のアタッチメントポイントは、同時に候補である場合があります。
Candidate Authenticator (CA) The EAP authenticator on the CAP.
候補者認証者（CA）キャップ上のEAP認証器。
EAP Server The entity that terminates the EAP authentication method with the peer [RFC3748]. EAP servers are often, but not necessarily, co-located with AAA servers, using a AAA protocol to communicate with remote pass-through authenticators.
EAPサーバーPeer [RFC3748]でEAP認証法を終了するエンティティ。EAPサーバーは、多くの場合、AAAサーバーと共同住宅されており、AAAプロトコルを使用してリモートパススルー認証器と通信します。
Inter-AAA-realm Handover (Inter-realm Handover) A handover across multiple AAA realms.
Inter-AAA-Realmハンドオーバー（Realm Inter-Realm Handover）複数のAAA領域にわたるハンドオーバー。
Inter-Technology Handover A handover across different link-layer technologies.
テクノロジー間ハンドオーバー異なるリンク層テクノロジー全体のハンドオーバー。
Intra-AAA-realm Handover (Intra-realm Handover) A handover within the same AAA realm. Intra-AAA-realm handover includes a handover across different authenticators within the same AAA realm.
Intra-AAA-Realmハンドオーバー（Realm Intra Handover）同じAAA領域内の引き渡し。Intra-AAA-Realmのハンドオーバーには、同じAAAレルム内の異なる認証者にわたるハンドオーバーが含まれています。
Intra-Technology Handover A handover within the same link-layer technology.
テクノロジー内ハンドオーバー同じリンク層テクノロジー内でのハンドオーバー。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method [RFC3748].
EAPピアとサーバーの間で導出され、EAPメソッド[RFC3748]によってエクスポートされるマスターセッションキー（MSK）キーイング素材。
Peer The entity that responds to the authenticator and requires authentication [RFC3748].
認証器に応答し、認証が必要なエンティティをピアします[RFC3748]。
Serving Access Network An access network that is currently serving the mobile device.
アクセスネットワークにサービスを提供しているアクセスネットワークが現在モバイルデバイスにサービスを提供しています。
Serving Attachment Point (SAP) An attachment point that is currently serving the mobile device.
アタッチメントポイント（SAP）は、現在モバイルデバイスを提供している添付ファイルポイントです。
Target Access Network An access network that has been selected to be the new serving access network for a mobile device.
ターゲットアクセスネットワークモバイルデバイス用の新しいサービングアクセスネットワークとして選択されたアクセスネットワーク。
Target Attachment Point (TAP) An attachment point that has been selected to be the new SAP for a mobile device.
ターゲットアタッチメントポイント（タップ）モバイルデバイスの新しいSAPとして選択された添付ファイルポイント。
The basic mechanism of handover is a two-step procedure involving
ハンドオーバーの基本的なメカニズムは、2段階の手順を含む2段階の手順です
o handover preparation and
o ハンドオーバーの準備と
o handover execution
o ハンドオーバー実行
Handover preparation includes the discovery of candidate attachment points and selection of an appropriate target attachment point from the candidate set. Handover preparation is outside the scope of this document.
ハンドオーバーの準備には、候補者のアタッチメントポイントの発見と、候補セットからの適切なターゲットアタッチメントポイントの選択が含まれます。ハンドオーバーの準備は、このドキュメントの範囲外です。
Handover execution consists of setting up Layer 2 (L2) and Layer 3 (L3) connectivity with the TAP. Currently, handover execution includes network access authentication and authorization performed directly with the target network; this may include full EAP authentication in the absence of any particular optimization for handover key management. Following a successful EAP authentication, a secure association procedure is typically performed between the mobile device and the TAP to derive a new set of link-layer encryption keys from EAP keying material such as the MSK. The handover latency introduced by full EAP authentication has proven to be higher than that which is acceptable for real-time application scenarios [MQ7]; hence, reduction in handover latency due to EAP is a necessary objective for such scenarios.
ハンドオーバーの実行は、レイヤー2（L2）とレイヤー3（L3）のタップとの接続をセットアップすることで構成されています。現在、ハンドオーバーの実行には、ターゲットネットワークで直接実行されるネットワークアクセス認証と認証が含まれます。これには、ハンドオーバーキー管理のための特定の最適化がない場合の完全なEAP認証が含まれる場合があります。EAP認証が成功した後、通常、モバイルデバイスとTAPの間で安全な関連性手順が実行され、MSKなどのEAPキーイング材料のリンク層暗号化キーの新しいセットが導き出されます。完全なEAP認証によって導入されたハンドオーバーレイテンシーは、リアルタイムアプリケーションシナリオ[MQ7]で許容されるものよりも高いことが証明されています。したがって、EAPによるハンドオーバーレイテンシの減少は、このようなシナリオに必要な目的です。
In IEEE 802.11 Wireless Local Area Networks (WLANs) [IEEE.802-11.2007] network access authentication and authorization involves performing a new IEEE 802.1X [IEEE.802-1X.2004] message exchange with the authenticator in the TAP to execute an EAP exchange with the authentication server [WPA]. There has been some optimization work undertaken by the IEEE, but these efforts have been scoped to IEEE link-layer technologies; for example, the work done in the IEEE 802.11f [IEEE.802-11F.2003] and 802.11r [IEEE.802-11R.2008] Task Groups applies only to intra-technology handovers.
IEEE 802.11では、ワイヤレスローカルエリアネットワーク（WLANS）[IEEE.802-11.2007]ネットワークアクセス認証と認可が含まれます。認証サーバー[WPA]と交換します。IEEEによって行われたいくつかの最適化作業がありましたが、これらの取り組みはIEEEリンクレイヤーテクノロジーに徴収されています。たとえば、IEEE 802.11f [IEEE.802-11F.2003]および802.11R [IEEE.802-11R.2008]タスクグループで行われた作業は、テクノロジー内のハンドオーバーにのみ適用されます。
The Third Generation Partnership Project (3GPP) Technical Specification 33.402 [TS33.402] defines the authentication and key management procedures performed during interworking between non-3GPP access networks and the Evolved Packet System (EPS). Network access authentication and authorization happens after the L2 connection is established between the mobile device and a non-3GPP target access network, and involves an EAP exchange between the mobile device and the 3GPP AAA server via the non-3GPP target access network. These procedures are not really independent of link technology, since they assume either that the authenticator lies in the EPS network or that separate authentications are performed in the access network and then in the EPS network.
第3世代パートナーシッププロジェクト（3GPP）技術仕様33.402 [TS33.402]は、非3GPPアクセスネットワークと進化したパケットシステム（EPS）間のインターワーキング中に実行される認証と主要な管理手順を定義します。ネットワークアクセス認証と承認は、モバイルデバイスと非3GPPターゲットアクセスネットワークの間にL2接続が確立された後に行われ、非3GPPターゲットアクセスネットワークを介してモバイルデバイスと3GPP AAAサーバー間のEAP交換が含まれます。これらの手順は、AuthenticatorがEPSネットワークにあるか、Access Network、およびEPSネットワークで個別の認証が実行されると仮定するため、リンクテクノロジーとは独立していません。
As the examples in the preceding sections illustrate, a solution is needed to enable EAP early authentication for inter-AAA-realm handovers and inter-technology handovers. A search for solutions at the IP level may offer the necessary technology independence.
前のセクションの例が示しているように、AAA間のハンドオーバーとテクノロジー間のハンドオーバーのEAP早期認証を有効にするための解決策が必要です。IPレベルでのソリューションの検索は、必要な技術の独立性を提供する場合があります。
Optimized solutions for secure inter-authenticator handovers can be seen either as security context transfer (e.g., using the EAP Extensions for EAP Re-authentication Protocol (ERP)) [RFC5296], or as EAP early authentication.
安全性のある自己認識間携帯用の最適化されたソリューションは、セキュリティコンテキスト転送（例えば、EAP再認証プロトコル（ERP）のEAP拡張機能を使用）[RFC5296]、またはEAP初期認証として見ることができます。
Security context transfer involves transfer of reusable key context to the TAP and can take two forms: horizontal and vertical.
セキュリティコンテキストの転送には、再利用可能なキーコンテキストのタップへの転送が含まれ、水平と垂直の2つの形式を取ることができます。
Horizontal security context transfer (e.g., from SAP to TAP) is not recommended because of the possibility that the compromise of one attachment point might lead to the compromise of another (the so-called domino effect, [RFC4962]). Vertical context transfer is similar to the initial establishment of keying material on an attachment point in that the keys are sent from a trusted server to the TAP as a direct result of a successful authentication. ERP specifies vertical context transfer using existing EAP keying material obtained from the home AAA server during the initial authentication. A cryptographically independent re-authentication key is derived and transmitted to the TAP as a result of successful ERP authentication. This reduces handover delay for intra-realm handovers by eliminating the need to run full EAP authentication with the home EAP server.
水平セキュリティコンテキストの転送（例えば、SAPからタップへ）は、あるアタッチメントポイントの妥協が別のものの妥協につながる可能性があるため、推奨されません（いわゆるドミノ効果、[RFC4962]）。垂直コンテキスト転送は、認証の成功の直接的な結果として、キーが信頼できるサーバーからTAPに送信されるという点で、キーキーキーの材料の最初の確立に似ています。ERPは、初期認証中にホームAAAサーバーから得られた既存のEAPキーイング材料を使用して、垂直コンテキスト転送を指定します。ERP認証が成功した結果、暗号的に独立した再認証キーが導出され、TAPに送信されます。これにより、Home EAP Serverで完全なEAP認証を実行する必要性を排除することにより、リアル内の携帯船のハンドオーバー遅延が削減されます。
However, in the case of inter-realm handover, either ERP is not applicable or an additional optimization mechanism is needed to establish a key on the TAP.
ただし、REALM間のハンドオーバーの場合、ERPが適用できないか、TAPにキーを確立するために追加の最適化メカニズムが必要です。
In EAP early authentication, AAA-based authentication and authorization for a CAP is performed while ongoing data communication is in progress via the serving access network, the goal being to complete AAA signaling for EAP before the mobile device moves. The applicability of EAP early authentication is limited to the scenarios where candidate authenticators can be discovered and an accurate prediction of movement can be easily made. In addition, the effectiveness of EAP early authentication may be less significant for particular inter-technology-handover scenarios where simultaneous use of multiple technologies is not a major concern.
EAPの早期認証では、AAAベースの認証とCAPの認証が実行され、進行中のデータ通信がサービングアクセスネットワークを介して進行中です。目標は、モバイルデバイスが移動する前にEAPのAAAシグナリングを完了することです。EAP早期認証の適用性は、候補者認証器を発見できるシナリオに限定され、動きの正確な予測を簡単に作成できます。さらに、EAP早期認証の有効性は、複数のテクノロジーを同時に使用することが大きな関心事ではない特定の技術間ハンドオーバーシナリオではそれほど重要ではない場合があります。
There are also several AAA issues related to EAP early authentication, discussed in Section 8.
セクション8で説明されているEAP早期認証に関連するいくつかのAAAの問題もあります。
Figure 1 shows the functional elements that are related to EAP early authentication. These functional elements include a mobile device, a SAP, a CAP, and one or more AAA and EAP servers; for the sake of convenience, the AAA and EAP servers are represented as being co-located. When the SAP and CAP belong to different AAA realms, the CAP may require a different set of user credentials than those used by the peer when authenticating to the SAP. Alternatively, the CAP and the SAP may rely on the same AAA server, located in the home realm of the mobile device (MD).
図1は、EAPの早期認証に関連する機能要素を示しています。これらの機能要素には、モバイルデバイス、SAP、キャップ、1つ以上のAAAおよびEAPサーバーが含まれます。便利なため、AAAおよびEAPサーバーは共同住宅として表されます。SAPとキャップが異なるAAAレルムに属している場合、CAPは、SAPを認証する際にピアが使用するものとは異なるユーザー資格情報を必要とする場合があります。あるいは、CAPとSAPは、モバイルデバイス（MD）のホーム領域にある同じAAAサーバーに依存する場合があります。
+------+ +-------+ +---------+ +---------+
| MD |------| SAP |------| | | |
+------+ +-------+ | IP | | EAP/AAA
. | |------| |
. Move | Network | | Server |
v +-------+ | | | |
| CAP |------| | | |
+-------+ +---------+ +---------+
Figure 1: EAP Early Authentication Functional Elements
図1：EAP早期認証機能要素
A mobile device is attached to the serving access network. Before the MD performs handover from the serving access network to a candidate access network, it performs EAP early authentication with a candidate authenticator via the serving access network. The peer may perform EAP early authentication with one or more candidate authenticators. It is assumed that each attachment point has an IP address. It is assumed that there is at least one CAP in each candidate access network. The serving and candidate access networks may use different link-layer technologies.
モバイルデバイスは、サービングアクセスネットワークに接続されています。MDがサービングアクセスネットワークから候補者アクセスネットワークへのハンドオーバーを実行する前に、サービングアクセスネットワークを介して候補者とのEAP早期認証を実行します。ピアは、1人以上の候補者の認証器を使用してEAP早期認証を実行できます。各アタッチメントポイントにはIPアドレスがあると想定されています。各候補アクセスネットワークに少なくとも1つのキャップがあると想定されています。サービングおよび候補のアクセスネットワークは、異なるリンク層テクノロジーを使用する場合があります。
Each authenticator is either a standalone authenticator or a pass-through authenticator [RFC3748]. When an authenticator acts as a standalone authenticator, it also has the functionality of an EAP server. When an authenticator acts as a pass-through authenticator, it communicates with the EAP server, typically using a AAA transport protocol such as RADIUS [RFC2865] or Diameter [RFC3588].
各認証器は、スタンドアロン認証機またはパススルー認証器のいずれかです[RFC3748]。認証機がスタンドアロン認証器として機能する場合、EAPサーバーの機能も備えています。認証器がパススルー認証器として機能する場合、通常、RADIUS [RFC2865]や直径[RFC3588]などのAAAトランスポートプロトコルを使用して、EAPサーバーと通信します。
If the CAP uses an MSK [RFC5247] for generating lower-layer ciphering keys, EAP early authentication is used to proactively generate an MSK for the CAP.
キャップが下層層の暗号化キーを生成するためにMSK [RFC5247]を使用している場合、EAP早期認証を使用してCAPのMSKを積極的に生成します。
The complexity of the authentication and authorization part of handover depends on whether it involves a change in EAP server. Consider first the case where the authenticators operate in pass-through mode, so that the EAP server is co-located with a AAA server. Then, there is a strict hierarchy of complexity, as follows:
ハンドオーバーの認証と承認の部分の複雑さは、EAPサーバーの変更を伴うかどうかによって異なります。EAPサーバーがAAAサーバーと共同で配置されるように、認証器がパススルーモードで動作する場合を最初に考えてください。次に、次のように、複雑さの厳格な階層があります。
1. inter-attachment-point handover with common AAA server: the CAP and SAP are different entities, but the AAA server is the same. There are two sub-cases here:
1. 一般的なAAAサーバーを使用した攻撃間ポイントのハンドオーバー：キャップとSAPは異なるエンティティですが、AAAサーバーは同じです。ここには2つのサブケースがあります：
(a) the AAA server is common because both attachment points lie within the same network, or
(a) AAAサーバーは、両方のアタッチメントポイントが同じネットワーク内にある、または
(b) the AAA server is common because AAA entities in the serving and candidate networks proxy to a AAA server in the home realm.
(b) AAAサーバーは一般的です。これは、サービングおよび候補ネットワークのAAAエンティティがホームレルムのAAAサーバーにプロキシをプロキシであるためです。
2. inter-AAA-realm handover: the CAP and SAP are different entities, and the respective AAA servers also differ. As a result, authentication in the candidate network requires a second set of user credentials.
2. Inter-AAA-Realmハンドオーバー：キャップとSAPは異なるエンティティであり、それぞれのAAAサーバーも異なります。その結果、候補ネットワークでの認証には、2番目のユーザー資格情報が必要です。
A third case is where one or both authenticators are co-located with an EAP server. This has some of the characteristics of an inter-AAA-realm handover, but offers less flexibility for resolution of the early authentication problem.
3番目のケースは、片方または両方の認証器がEAPサーバーと共同で配置される場所です。これには、inter-aaa-realmのハンドオーバーの特徴がいくつかありますが、早期認証の問題の解決に対する柔軟性が低下します。
Orthogonally to this classification, one can distinguish intra-technology handover from inter-technology handover thinking of the link technologies involved. In the inter-technology case, it is highly probable that the authenticators will differ. The most likely cases are 1(b) or 2 in the above list.
この分類に直交することで、テクノロジー内のハンドオーバーと、関係するリンクテクノロジーのテクノロジー間のハンドオーバー考えることを区別できます。テクノロジー間の場合、認証者が異なる可能性が非常に高いです。最も可能性の高いケースは、上記のリストの1（b）または2です。
As noted in Section 3, there are cases where early authentication is applicable while ERP does not work. This section concentrates on providing some models around which we can build our analysis of the EAP early authentication problem. Different usage models can be defined depending on whether
セクション3で述べたように、ERPが機能しない間に早期認証が適用できる場合があります。このセクションでは、EAP初期認証問題の分析を構築できるモデルの提供に集中しています。さまざまな使用モデルを定義することができます
o the SAP is not involved in early authentication (direct pre-authentication usage model),
o SAPは、早期認証に関与していません（直接的な認証前使用モデル）、
o the SAP interacts only with the CAP (indirect pre-authentication usage model), or
o SAPは、CAP（間接的な認証前使用モデル）とのみ相互作用します。
o the SAP interacts with the AAA server (the authenticated anticipatory keying usage model).
o SAPは、AAAサーバー（認証された予測キーイング使用モデル）と相互作用します。
It is assumed that the CAP and SAP are different entities. It is further assumed in describing these models that there is no direct L2 connectivity between the peer and the candidate attachment point.
CAPとSAPは異なるエンティティであると想定されています。これらのモデルを説明する際に、ピアと候補の添付ファイルポイントの間に直接的なL2接続がないことを説明することが想定されています。
In the EAP pre-authentication model, the SAP does not interact with the AAA server directly. Depending on how the SAP is involved in the pre-authentication signaling, the EAP pre-authentication usage model can be further categorized into the following two sub-models, direct and indirect.
EAP前発作モデルでは、SAPはAAAサーバーと直接相互作用しません。SAPが受精前シグナリングにどのように関与しているかに応じて、EAP前免除の使用モデルは、次の2つのサブモデル（直接および間接）にさらに分類できます。
In this model, the SAP is not involved in the EAP exchange and only forwards the EAP pre-authentication traffic as it would any other data traffic. The direct pre-authentication model is based on the assumption that the MD can discover candidate authenticators and establish direct IP communication with them. It is applicable to any of the cases described in Section 5.
このモデルでは、SAPはEAP交換に関与しておらず、他のデータトラフィックと同様にEAP前の認証トラフィックのみを転送します。直接的な事前認証モデルは、MDが候補者認証者を発見し、それらとの直接的なIP通信を確立できるという仮定に基づいています。セクション5で説明されているケースのいずれかに適用されます。
Mobile Candidate Attachment AAA Server
Device Point(CAP)
+-----------+ +-------------------------+ +------------+
| | | Candidate | | |
| Peer | | Authenticator | | EAP Server |
| | | | | |
+-----------+ +-------------------------+ +------------+
| MD-CAP |<-->| MD-CAP | | CAP-AAA |<-->| CAP-AAA |
| Signaling | | Signaling | | Signaling | | Signaling |
+-----------+ +-----------+ +-----------+ +------------+
Figure 2: Direct Pre-Authentication Usage Model
図2：直接的な認証前使用モデル
The direct pre-authentication signaling for the usage model is shown in Figure 3.
使用モデルの直接的な免除シグナル伝達を図3に示します。
Mobile Serving Candidate AAA/EAP
Device Attachment Point Authenticator Server
(SAP)
| | | |
| | | |
| EAP over MD-CAP Signaling (L3) | EAP over AAA |
|<------------------+------------------->|<----------------->|
| | | |
| | | |
Figure 3: Direct Pre-Authentication Signaling for the Usage Model
図3：使用モデルの直接的な免除シグナル伝達
The indirect pre-authentication usage model is illustrated in Figure 4.
間接的な認証前使用モデルを図4に示します。
Mobile Device Serving Candidate AAA
(MD) Attachment Point Attachment Point Server
(SAP) (CAP)
+----------+ +----------------+ +--------+
| | | | | |
| EAP Peer | | Candidate | | EAP |
| | | Authenticator | | Server |
| | | | | |
+----------+ +---------+-------+ +-------+--------+ +--------+
| MD-SAP |<->| MD-SAP |SAP-CAP|<->|SAP-CAP|CAP-AAA |<->|CAP-AAA |
+----------+ +---------+-------+ +-------+--------+ +--------+
{-----------------------------Signaling----------------------------}
Figure 4: Indirect Pre-Authentication Usage Model
図4：間接的な認証前使用モデル
In the indirect pre-authentication model, it is assumed that a trust relationship exists between the serving network (or serving AAA realm) and candidate network (or candidate AAA realm). The SAP is involved in EAP pre-authentication signaling. This pre-authentication model is needed if the peer cannot discover the candidate authenticators identity or if direct IP communication between the MD and CAP is not possible due to security or network topology issues.
間接前の免除モデルでは、サービングネットワーク（またはAAAレルムを提供する）と候補ネットワーク（または候補AAAレルム）の間に信頼関係が存在すると想定されています。SAPは、EAP前認証シグナル伝達に関与しています。ピアが候補者の認証機のアイデンティティを発見できない場合、またはセキュリティまたはネットワークトポロジの問題によりMDとCAP間の直接的なIP通信が不可能な場合、この事前認証モデルが必要です。
The role of the SAP in this pre-authentication model is to forward EAP pre-authentication signaling between the mobile device and CAP; the role of the CAP is to forward EAP pre-authentication signaling between the peer (via the SAP) and EAP server and receive the transported keying material.
この承認前モデルにおけるSAPの役割は、モバイルデバイスとCAPの間でEAP前発見のシグナルを転送することです。キャップの役割は、ピア（SAPを介して）とEAPサーバーの間でEAP前発見のシグナルを転送し、輸送されたキーイング材料を受け取ることです。
The pre-authentication signaling for this model is shown in Figure 5.
このモデルの認証前シグナリングを図5に示します。
Mobile Serving Candidate AAA/EAP
Device Attachment Point Attachment Point Server
(SAP) (CAP)
| | | |
| EAP over | EAP over | EAP over AAA |
| MD-SAP Signaling | SAP-CAP Signaling | |
| (L2 or L3) | (L3) | |
|<----------------->|<------------------<|<----------------->|
| | | |
| | | |
Figure 5: Indirect Pre-Authentication Signaling for the Usage Model
図5：使用モデルの間接的な事前認証シグナル
In this model, the pre-authentication signaling path between a peer and a candidate authenticator consists of two segments: peer-to-SAP signaling (over L2 or L3) and SAP-to-CAP signaling over L3.
このモデルでは、ピアと候補者の認証因子の間の認証前シグナリングパスは、PEER-SAPシグナル伝達（L2またはL3を超える）とL3を超えるSAPからCAPシグナリングの2つのセグメントで構成されています。
In this model, it is assumed that there is no trust relationship between the SAP and the CAP, and the SAP is required to interact with the AAA server directly. The authenticated anticipatory keying usage model is illustrated in Figure 6.
このモデルでは、SAPとCAPの間に信頼関係がないと想定されており、SAPはAAAサーバーと直接対話するために必要です。認証された予測キーイング使用モデルを図6に示します。
Mobile Serving AAA Server Candidate
Device Attachment Point Attachment
(SAP) Point (CAP)
+---------+ +------------------+ +-----------------+ +--------+
| | | | | | | |
| Peer | | Authenticator | | EAP Server | | AAA |
| | | | | | | Client |
+---------+ +------------------+ +-----------------+ +--------+
| MD-SA |<->| MD-SAP |SAP-AAA |<->|SAP-AAA |CAP-AAA |<>|CAP-AAA |
+---------+ +------------------+ +--------+--------+ +--------+
{------------------------------Signaling---------------------------}
Figure 6: Authenticated Anticipatory Keying Usage Model
図6：認証された予測キーイング使用モデル
The SAP is involved in EAP authenticated anticipatory keying signaling.
SAPは、EAP認証された予測キーイングシグナル伝達に関与しています。
The role of the serving attachment point in this usage model is to communicate with the peer on one side and exchange authenticated anticipatory keying signaling with the EAP server on the other side. The role of the candidate authenticator is to receive the transported keying materials from the EAP server and to act as the serving attachment point after handover occurs. The MD-SAP signaling is performed over L2 or L3; the SAP-AAA and AAA-CAP segments operate over L3.
この使用モデルにおけるサービングアタッチメントポイントの役割は、一方のピアと通信し、反対側のEAPサーバーと認証された予測キーイングシグナリングを交換することです。候補者認証者の役割は、EAPサーバーから輸送されたキーイング材料を受け取り、ハンドオーバーが発生した後にサービングアタッチメントポイントとして機能することです。MD-SAPシグナル伝達は、L2またはL3で実行されます。SAP-AAAおよびAAA-CAPセグメントはL3で動作します。
There are two architectural issues relating to early authentication: authenticator discovery and context binding.
初期認証に関連する2つのアーキテクチャの問題があります：認証者の発見とコンテキストバインディング。
In general, early authentication requires the identity of a candidate attachment point to be discovered by a peer, by a serving attachment point, or by some other entity prior to handover. An attachment point discovery protocol is typically defined as a separate protocol from an early authentication protocol. For example, the IEEE 802.21 Information Service (IS) [IEEE.802-21] provides a link-layer-independent mechanism for obtaining neighboring network information by defining a set of Information Elements (IEs), where one of the IEs is defined to contain an IP address of an attachment point. IEEE 802.21 IS queries for such an IE may be used as a method for authenticator discovery.
一般に、早期認証では、ピア、サービングアタッチメントポイント、または引き渡し前の他のエンティティによって、ピアによって発見される候補者の添付ファイルポイントの身元が必要です。アタッチメントポイントディスカバリープロトコルは、通常、初期認証プロトコルからの個別のプロトコルとして定義されます。たとえば、IEEE 802.21情報サービス（IS）[IEEE.802-21]は、IESの1つが定義される情報要素のセット（IE）を定義することにより、近隣のネットワーク情報を取得するためのリンク層に依存しないメカニズムを提供します。添付ポイントのIPアドレスが含まれています。IEEE 802.21は、そのようなIEのクエリは、認証機の発見の方法として使用される場合があります。
If IEEE 802.21 IS or a similar mechanism is used, authenticator discovery requires a database of information regarding the target network; the provisioning of a server with such a database is another issue.
IEEE 802.21がISまたは同様のメカニズムが使用されている場合、Authenticator Discoveryにはターゲットネットワークに関する情報のデータベースが必要です。このようなデータベースを使用したサーバーのプロビジョニングは、別の問題です。
When a candidate authenticator uses different EAP transport protocols for normal authentication and early authentication, a mechanism is needed to bind link-layer-independent context carried over early authentication signaling to the link-layer-specific context of the link to be established between the peer and the candidate authenticator. The link-layer-independent context includes the identities of the peer and authenticator as well as the MSK. The link-layer-specific context includes link-layer addresses of the peer and the candidate authenticator. Such context binding can happen before or after the peer changes its point of attachment.
候補者認証器が通常の認証と早期認証のために異なるEAP輸送プロトコルを使用する場合、ピア間で確立されるリンクのリンク層固有のコンテキストに及ぼすリンク層に依存しないコンテキストをバインドするメカニズムが必要です。および候補者の認証者。Link-Layerに依存しないコンテキストには、PEERとAuthenticatorのアイデンティティ、およびMSKが含まれます。リンク層固有のコンテキストには、ピアと候補者の認証者のリンク層アドレスが含まれます。このようなコンテキスト結合は、ピアが添付ファイルのポイントを変更する前または後に発生する可能性があります。
There are at least two possible approaches to address the context binding issue. The first approach is based on communicating the link-layer context as opaque data via early authentication signaling. The second approach is based on running EAP over the link layer of the candidate authenticator after the peer arrives at the authenticator, using short-term credentials generated via early authentication. In this case, the short-term credentials are shared between the peer and the candidate authenticator. In both approaches, context binding needs to be securely made between the peer and the candidate authenticator. Also, the peer is not fully authorized by the candidate authenticator until the peer completes the link-layer-specific secure association procedure with the authenticator using link-layer signaling.
コンテキスト結合の問題に対処するための少なくとも2つの可能なアプローチがあります。最初のアプローチは、リンク層コンテキストを早期認証シグナリングを介して不透明なデータとして通信することに基づいています。2番目のアプローチは、ピアが認証器に到着した後、候補者認証器のリンクレイヤーでEAPを実行し、早期認証を介して生成された短期資格情報を使用していることに基づいています。この場合、短期の資格情報は、ピアと候補者の認証者の間で共有されます。どちらのアプローチでも、コンテキスト結合をピアと候補者の認証者の間でしっかりと行う必要があります。また、ピアは、リンク層シグナル伝達を使用して、ピアがリンク層固有のセキュアーアソシエーション手順を認証装置と完了するまで、候補者によって完全に許可されていません。
Most of the AAA documents today do not distinguish between a normal authentication and an early authentication, and this creates a set of open issues: Early authentication authorization Users may not be allowed to have more than one logon session at the time. This means that while such users actively engage in a session (as a result of a previously valid authentication), they will not be able to perform early authentication. The AAA server currently has no way of distinguishing between a normal authentication request and an early authentication request.
今日のAAAドキュメントのほとんどは、通常の認証と早期認証を区別していません。これにより、一連のオープンな問題が作成されます。早期認証承認ユーザーは、当時複数のログオンセッションを許可されない場合があります。これは、そのようなユーザーが（以前に有効な認証の結果として）セッションに積極的に関与しているが、早期認証を実行できないことを意味します。AAAサーバーには現在、通常の認証要求と早期認証要求を区別する方法がありません。
Early authentication lifetime Currently, AAA protocols define attributes carrying lifetime information for a normal authentication session. Even when a user profile and the AAA server support early authentication, the lifetime for an early authentication session is typically valid only for a short amount of time because the peer has not completed its authentication at the target link layer. It is currently not possible for a AAA server to indicate to the AAA client or a peer the lifetime of the early authenticated session unless AAA protocols are extended to carry early authentication session lifetime information. In other words, it is not clear to the peer or the authenticator when the early authentication session will expire.
初期認証寿命現在、AAAプロトコルは、通常の認証セッションのライフタイム情報を運ぶ属性を定義しています。ユーザープロファイルとAAAサーバーが早期認証をサポートしている場合でも、ピアがターゲットリンクレイヤーで認証を完了していないため、早期認証セッションの寿命は通常、短時間のみ有効です。現在、AAAサーバーがAAAクライアントに、AAAプロトコルが拡張されて早期認証セッションのライフタイム情報を掲載しない限り、早期認証セッションの生涯をピアに示すことは不可能です。言い換えれば、初期の認証セッションが期限切れになる場合、ピアや認証者には明確ではありません。
Early authentication retries It is typically expected that, shortly following the early authentication process, the peer moves to the new point of attachment and converts the early authentication state to a normal authentication state (the procedure for which is not the topic of this particular subsection). However, if the peer has not yet moved to the new location and realizes that the early authentication session is expiring, it may perform another early authentication. Some limiting mechanism is needed to avoid an unlimited number of early authentication attempts.
早期認証を取得することは通常、初期認証プロセスに続いて、ピアが添付ファイルの新しいポイントに移動し、初期認証状態を通常の認証状態に変換することが期待されています（この特定のサブセクションのトピックではない手順）。ただし、ピアがまだ新しい場所に移動しておらず、早期認証セッションが期限切れになっていることに気付いた場合、別の早期認証を実行する可能性があります。無制限の数の早期認証試行を避けるためには、いくつかの制限メカニズムが必要です。
Completion of network attachment Once the peer has successfully attached to the new point of attachment, it needs to convert its authentication state from early authenticated to fully attached and authorized. If the AAA server needs to differentiate between early authentication and normal authentication, there may need to be a mechanism within the AAA protocol to provide this indication to the AAA server. This may be important from a billing perspective if the billing policy does not charge for an early authenticated peer until the peer is fully attached to the target authenticator.
ネットワーク添付ファイルの完了ピアが新しい添付ファイルのポイントに正常に接続されると、認証状態を早期に認証されたものから完全に添付および承認された状態に変換する必要があります。AAAサーバーが早期認証と通常の認証を区別する必要がある場合、AAAサーバーにこの表示を提供するためにAAAプロトコル内にメカニズムが必要になる場合があります。これは、ピアがターゲット認証機に完全に添付されるまで、請求ポリシーが早期に認証されたピアに対して請求されない場合、請求の観点から重要かもしれません。
Session resumption In the case where the peer cycles between a network N1 with which it has fully authenticated and another network N2 and then back to N1, it should be possible to simply convert the fully authenticated state on N1 to an early authenticated state. The problems around handling session lifetime and keying material caching need to be dealt with.
セッション再開ネットワークN1と別のネットワークN2がN1に戻り、N1に戻る場合、N1の完全に認証された状態を初期認証状態に単純に変換することができるはずです。セッションのライフタイムとキーイングマテリアルキャッシングの処理に関する問題に対処する必要があります。
Multiple candidate attachment points There may be situations where the peer needs to choose from a number of CAPs. In such cases, it is desirable for the peer to perform early authentication with multiple candidate authenticators. This amplifies the difficulties noted under the point "Early authentication authorization".
複数の候補アタッチメントポイントピアが多数のキャップから選択する必要がある状況がある場合があります。そのような場合、ピアは複数の候補者認証機を使用して早期認証を実行することが望ましいです。これは、「早期認証承認」という点で記載されている困難を増幅します。
Inter-AAA-realm handover support There may be situations where the peer moves out of the home AAA realm or across different visited AAA realms. In such cases, the early authentication should be performed through the visited AAA realm with the AAA server in the home AAA realm. It also requires AAA in the visited realm to acquire the identity information of the home AAA realms for routing the EAP early authentication traffic. Knowledge of realm identities is required by both the peer and AAA to generate the early authentication key for mutual authentication between the peer and the visited AAA server.
Inter-AAA-RealmハンドオーバーサポートピアがホームAAAレルムから外に出るか、さまざまな訪問されたAAA領域を越えて移動する状況があるかもしれません。そのような場合、Home AAA RealmのAAAサーバーを使用して、訪問したAAAレルムを通じて初期認証を実行する必要があります。また、EAP早期認証トラフィックをルーティングするために、Home AAA RealmsのID情報を取得するには、訪問された領域のAAAが必要です。ピアとAAAの両方が、ピアと訪問されたAAAサーバーの間の相互認証のための早期認証キーを生成するために、ピアとAAAの両方で領域のアイデンティティの知識が必要です。
Inter-technology support Current specifications on early authentication mostly deal with homogeneous 802.11 networks. AAA attributes such as Calling-Station-ID [RADEXT-WLAN] may need to be expanded to cover other access technologies. Furthermore, inter-technology handovers may require a change of the peer identifier as part of the handover. Investigation on the best type of identifiers for peers that support multiple access technologies is required.
テクノロジー間は、早期認証に関する現在の仕様をサポートしています。主に均一な802.11ネットワークを扱います。Calling-Station-ID [Radext-Wlan]などのAAA属性を拡張して、他のアクセステクノロジーをカバーする必要がある場合があります。さらに、テクノロジー間の携帯電話では、ハンドオーバーの一部としてピア識別子の変更が必要になる場合があります。複数のアクセステクノロジーをサポートするピアの最良のタイプの識別子に関する調査が必要です。
This section specifically covers threats introduced to the EAP model by early authentication. Security issues on general EAP and handover are described in other documents such as [RFC3748], [RFC4962], [RFC5169], and [RFC5247].
このセクションは、早期認証によってEAPモデルに導入された脅威を特にカバーしています。一般的なEAPおよびハンドオーバーに関するセキュリティの問題は、[RFC3748]、[RFC4962]、[RFC5169]、[RFC5247]などの他の文書で説明されています。
Since early authentication, as described in this document, needs to work across multiple attachment points, any solution needs to consider the following security threats.
このドキュメントで説明されているように、初期の認証は複数の添付ファイルポイントで動作する必要があるため、ソリューションは次のセキュリティの脅威を考慮する必要があります。
First, a resource consumption denial-of-service attack is possible, where an attacker that is not on the same IP link as the legitimate peer or the candidate authenticator may send unprotected early authentication messages to the legitimate peer or the candidate authenticator. As a result, the latter may spend computational and bandwidth resources on processing early authentication messages sent by the attacker. This attack is possible in both the direct and indirect pre-authentication scenarios. To mitigate this attack, the candidate network or authenticator may apply non-cryptographic packet filtering so that only early authentication messages received from a specific set of serving networks or authenticators are processed. In addition, a simple solution for the peer side would be to let the peer always initiate EAP early authentication and not allow EAP early authentication initiation from an authenticator.
第一に、正当なピアまたは候補者認証者と同じIPリンクにない攻撃者が、正当なピアまたは候補者認証者に保護されていない早期認証メッセージを送信する場合がある場合、リソース消費拒否攻撃が可能です。その結果、後者は、攻撃者から送信された早期認証メッセージの処理に計算リソースと帯域幅リソースを費やす可能性があります。この攻撃は、直接的および間接的な認証前シナリオの両方で可能です。この攻撃を軽減するために、候補ネットワークまたは認証器は、非暗号化されたパケットフィルタリングを適用して、特定のサービングネットワークまたは認証器から受信した早期認証メッセージのみが処理されるようにすることができます。さらに、ピア側の簡単なソリューションは、ピアが常にEAP早期認証を開始できるようにし、認証者からのEAP早期認証の開始を許可しないことです。
Second, consideration for the channel binding problem described in [RFC5247] is needed as lack of channel binding may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower-layer protocol) [RFC3748]. It should be noted that it is relatively easier to launch such an impersonation attack for early authentication than normal authentication because an attacker does not need to be physically on the same link as the legitimate peer to send an early authentication trigger to the peer.
第二に、[RFC5247]に記載されているチャネル結合問題の考慮が必要であるため、チャネル結合がない可能性があるため、認証器が別の認証器になりすましたり、帯域外のメカニズムを介して誤った情報を通信したりすることができるため（AAAまたは低層プロトコルなど）[RFC3748]。攻撃者は、ピアに早期認証トリガーを送信するために正当なピアと同じリンクに物理的にある必要がないため、通常の認証よりも早期認証のためにこのようななりすまし攻撃を起動する方が比較的簡単であることに注意してください。
The editors would like to thank Preetida Vinayakray, Shubhranshu Singh, Ajay Rajkumar, Rafa Marin Lopez, Jong-Hyouk Lee, Maryna Komarova, Katrin Hoeper, Subir Das, Charles Clancy, Jari Arkko, and Bernard Aboba for their valuable input.
編集者は、Preetida Vinayakray、Shubhranshu Singh、Ajay Rajkumar、Rafa Marin Lopez、Jong-Hyouk Lee、Maryna Komarova、Katrin Hoeper、Subir Das、Charles Clancy、Jari Arkko、およびBernard Abobaに感謝します。
The following people all contributed to this document: Alper E. Yegin, Tom Taylor, Srinivas Sreemanthula, Madjid Nakhjiri, Mahalingam Mani, and Ashutosh Dutta.
次の人々がこの文書に貢献しました：Alper E. Yegin、Tom Taylor、Srinivas Sreemanthula、Madjid Nakhjiri、Mahalingam Mani、Ashutosh Dutta。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[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月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、RFC 5247、2008年8月。
[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月。
[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月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re- Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169] Clancy、T.、Nakhjiri、M.、Narayanan、V。、およびL. Dondeti、「ハンドオーバーキー管理および再認証問題ステートメント」、RFC 5169、2008年3月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296] Narayanan、V。およびL. Dondeti、「EAP再認証プロトコル（ERP）のEAP拡張」、RFC 5296、2008年8月。
[RADEXT-WLAN] Aboba, B., Malinen, J., Congdon, P., and J. Salowey, "RADIUS Attributes for IEEE 802 Networks", Work in Progress, February 2010.
[Radext-Wlan] Aboba、B.、Malinen、J.、Congdon、P。、およびJ. Salowey、「IEEE 802ネットワークのRadius属性」、2010年2月の作業。
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil, D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen, S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim, B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
[RFC2989] Aboba、B.、Calhoun、P.、Glass、S.、Hiller、T.、McCann、P.、Shiino、H.、Zorn、G.、Dommety、G.、C.Perkins、B.Patil、D.Mitton、S.Manning、M.Beadles、P.Walsh、X.Chen、S.Sivalingham、A.Hameed、M.Munson、S.Jacobs、B.Lim、B.Hirschman、R.Hsu、Y.xu、E.Campell、S.Baba、およびE.Jaques、「ネットワークアクセスのためのAAAプロトコルを評価するための基準」、RFC 2989、2000年11月。
[IEEE.802-1X.2004] Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control", IEEE Standard 802.1X, 2004.
[IEEE.802-1x.2004]電気および電子機器エンジニアの研究所、「ポートベースのネットワークアクセス制御」、IEEE Standard 802.1x、2004。
[IEEE.802-21] Institute of Electrical and Electronics Engineers, "Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE Standard 802.21, 2008.
[IEEE.802-21]電気およびエレクトロニクスエンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワークの標準：メディア独立ハンドオーバーサービス」、IEEE Standard 802.21、2008。
[IEEE.802-11.2007] 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.
[IEEE.802-11.2007]電気およびエレクトロニクスエンジニアの研究所、「情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理レイヤー（Phyy）仕様」、IEEE Standard 802.11、2007。
[IEEE.802-11R.2008] 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 - Amendment 2: Fast BSS Transition", IEEE Standard 802.11R, 2008.
[IEEE.802-11R.2008]電気およびエレクトロニクスエンジニアの研究所、「情報技術 - システム間の通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理レイヤー（PHY）仕様 - 修正2：高速BSS移行 "、IEEE Standard 802.11r、2008。
[IEEE.802-11F.2003] Institute of Electrical and Electronics Engineers, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE Recommendation 802.11F, 2003.
[IEEE.802-11F.2003]電気およびエレクトロニクスエンジニアの研究所、「IEEEの試用版のアクセスポイントプロトコルを介したIEEE 802.11操作をサポートする配信システム間のインターアクセスポイントプロトコルのIEEEトライアル使用法」、IEEE推奨802.11F、2003年。
[TS33.402] 3GPP, "System Architecture Evolution (SAE): Security aspects of non-3GPP accesses (Release 8)", 3GPP TS33.402 V8.3.1, 2009.
[TS33.402] 3GPP、「システムアーキテクチャの進化（SAE）：非3GPPアクセスのセキュリティ側面（リリース8）」、3GPP TS33.402 V8.3.1、2009。
[ITU] ITU-T, "General Characteristics of International Telephone Connections and International Telephone Circuits: One-Way Transmission Time", ITU-T Recommendation G.114, 1998.
[ITU] ITU-T、「国際電話接続と国際電話回路の一般的な特性：一方向伝達時間」、ITU-T推奨G.114、1998。
[WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi WPA v3.1, 2004.
[WPA] Wi-Fi Alliance、「WPA（Wi-Fi Protected Access）」、Wi-Fi WPA V3.1、2004。
[MQ7] Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A. Skarmeta, "Network-layer Assisted Mechanism to Optimize Authentication Delay During Handoff in 802.11 Networks", The 4th Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (MOBIQUITOUS 2007), 2007.
[MQ7] Lopez、R.、Dutta、A.、Ohba、Y.、Schulzrinne、H.、およびA. Skarmeta、「802.11ネットワークでのハンドオフ中に認証遅延を最適化するためのネットワーク層支援メカニズム」、第4回年次国際会議であるモバイルおよびユビキタスシステム：コンピューティング、ネットワーキング、サービス（Mobiquitous 2007）、2007年。
[WCM] Dutta, A., Famorali, D., Das, S., Ohba, Y., and R. Lopez, "Media-independent pre-authentication supporting secure interdomain handover optimization", IEEE Wireless Communications Volume 15, Issue 2, April 2008.
[WCM] Dutta、A.、Famorali、D.、Das、S.、Ohba、Y。、およびR. Lopez、「安全なドメイン間ハンドオーバーの最適化をサポートするメディアに依存しない事前認証」、IEEEワイヤレス通信ボリューム15、第2号、2008年4月。
Authors' Addresses
著者のアドレス
Yoshihiro Ohba Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa, 212-8582 Japan
ヨシヒロ大統領企業研究開発センター1 Komukai-Toshiba-Cho Saiwai-Ku、川崎、川崎、212-8582日本
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Qin Wu (editor) Huawei Technologies Co., Ltd Huawei Nanjing R&D Center, Floor 1F, Software Avenue, No.101., Yuhua District Nanjing, JiangSu 210012 China
Qin Wu（編集者）Huawei Technologies Co.、Ltd Huawei Nanjing R＆D Center、Floor 1F、Software Avenue、No.101。、Yuhua District Nanjing、Jiangsu 210012 China
Phone: +86 25 56622908
EMail: sunseawq@huawei.com
Glen Zorn (editor) Network Zen 1463 East Republican Street Seattle, Washington 98112 USA
グレンゾーン（編集者）ネットワークZEN 1463イースト共和党ストリートシアトル、ワシントン98112 USA
EMail: gwz@net-zen.net