[要約] RFC 6697は、Handover Keying（HOKEY）アーキテクチャデザインに関するものであり、モバイルネットワークのハンドオーバーにおける鍵交換の仕組みを提案しています。このRFCの目的は、セキュアなハンドオーバーを実現するためのアーキテクチャを定義することです。
Internet Engineering Task Force (IETF) G. Zorn, Ed.
Request for Comments: 6697 Network Zen
Category: Informational Q. Wu
ISSN: 2070-1721 T. Taylor
Huawei
Y. Nir
Check Point
K. Hoeper
Motorola Solutions, Inc.
S. Decugis
INSIDE Secure
July 2012
Handover Keying (HOKEY) Architecture Design
ハンドオーバーキーイング（HOKEY）アーキテクチャの設計
Abstract
概要
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.
ハンドオーバーキーイング（HOKEY）ワーキンググループは、ピアが1つの接続点から別の接続点に移動するときの認証によるハンドオーバー遅延を最小限に抑えることを目指しています。ハンドオーバーの遅延を削減するために、2つの異なるアプローチで作業が進んでいます。早期認証（ハンドオーバー中に認証を実行する必要がないようにするため）と、再認証時の時間を節約するための初期認証中に生成された暗号化素材の再利用です。基本的な想定では、モバイルホストまたは「ピア」は、RFC 3748で定義されているように、ピアとEAPサーバー間で実行される拡張認証プロトコル（EAP）を使用して最初に認証されます。
This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group.
このドキュメントでは、HOKEYアーキテクチャを定義しています。具体的には、設計目標、ハンドオーバーキーイングが動作する機能環境、HOKEYアーキテクチャ自体によって実行される機能、およびそれらの機能のアーキテクチャコンポーネントへの割り当てについて説明します。さらに、HOKEYワーキンググループによって作成された他のドキュメントでより完全に説明されているさまざまな展開シナリオ内でのアーキテクチャの動作について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6697.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6697で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Design Goals ....................................................6
3.1. Reducing Signaling Overhead ................................7
3.1.1. Minimized Communications with Home Servers ..........7
3.1.2. Minimized User Interaction for Authentication .......7
3.2. Integrated Local Domain Name (LDN) Discovery ...............7
3.3. Fault-Tolerant Re-Authentication ...........................8
3.4. Improved Deployment Scalability ............................8
4. Required Functionality ..........................................8
4.1. Authentication Subsystem Functional Overview ...............8
4.2. Pre-Authentication Function (Direct or Indirect) ...........9
4.3. EAP Re-Authentication Function .............................9
4.4. EAP Authentication Function ...............................10
4.5. Authenticated Anticipatory Keying (AAK) Function ..........10
4.6. Management of EAP-Based Handover Keys .....................10
5. Components of the HOKEY Architecture ...........................11
5.1. Functions of the Peer .....................................12
5.2. Functions of the Serving Authenticator ....................13
5.3. Functions of the Candidate Authenticator ..................14
5.4. Functions of the EAP Server ...............................15
5.5. Functions of the ER Server ................................16
6. Usage Scenarios ................................................16
6.1. Simple Re-Authentication ..................................16
6.2. Intra-Domain Handover .....................................17
6.3. Inter-Domain Handover .....................................17
6.4. Inter-Technology Handover .................................17
7. AAA Considerations .............................................17
7.1. Authorization .............................................17
7.2. Transport Aspect ..........................................18
8. Security Considerations ........................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
The Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework that supports different types of authentication methods. Originally designed for dial-up connections, EAP is now commonly used for authentication in a variety of access networks.
拡張認証プロトコル（EAP）[RFC3748]は、さまざまな種類の認証方法をサポートする認証フレームワークです。当初、ダイヤルアップ接続用に設計されたEAPは、現在、さまざまなアクセスネットワークでの認証に一般的に使用されています。
When a host (or "peer", the term used from this point onward) changes its point of attachment to the network, it must be re-authenticated. If a full EAP authentication must be repeated, several message round trips between the peer and the home EAP server may be involved. The resulting delay will result in degradation -- or, in the worst case, loss of any service session in progress -- if communication is suspended while re-authentication is carried out. The delay is worse if the new point of attachment is in a visited network rather than the peer's home network because of the extra procedural steps involved as well as the probable increase in round-trip time.
ホスト（または「ピア」、この時点以降で使用される用語）がネットワークへの接続ポイントを変更するときは、再認証する必要があります。完全なEAP認証を繰り返す必要がある場合は、ピアとホームEAPサーバーとの間のいくつかのメッセージラウンドトリップが関係する可能性があります。結果として生じる遅延は、再認証の実行中に通信が中断された場合、劣化、または最悪の場合、進行中のサービスセッションの損失につながります。新しい接続点がピアのホームネットワークではなく訪問先のネットワークにある場合は、追加の手順が必要になるだけでなく、往復時間が長くなる可能性があるため、遅延はさらに悪化します。
Clancy, et al. [RFC5169] describe this problem more fully and establish design goals for solutions to reduce re-authentication delay for transfers within a single administrative domain. They also suggest a number of ways to achieve a solution:
クランシー等。 [RFC5169]は、この問題をより詳しく説明し、単一の管理ドメイン内での転送の再認証遅延を削減するソリューションの設計目標を確立します。彼らはまた、解決策を達成するためのいくつかの方法を提案しています：
o specification of a method-independent, efficient re-authentication protocol based upon EAP;
o EAPに基づく、メソッドに依存しない効率的な再認証プロトコルの仕様。
o reuse of keying material from the initial EAP authentication;
o 最初のEAP認証からのキー情報の再利用。
o deployment of re-authentication servers local to the peer to reduce round-trip delay; and
o ラウンドトリップ遅延を減らすために、ピアにローカルな再認証サーバーを展開します。そして
o specification of the additional protocol needed to allow the EAP server to pass authentication information to the local re-authentication servers.
o EAPサーバーがローカルの再認証サーバーに認証情報を渡すために必要な追加プロトコルの仕様。
Salowey, et al. [RFC5295] tackle the problem of the reuse of keying material by specifying how to derive a hierarchy of cryptographically independent purpose-specific keys from the results of the original EAP authentication, while Cao, et al. [RFC6696] specify a method-independent re-authentication protocol (the EAP Re-authentication Protocol (ERP)) applicable to two specific deployment scenarios:
Salowey、他。 [RFC5295]は、元のEAP認証の結果から暗号的に独立した目的固有のキーの階層を導き出す方法を指定することにより、キー情報の再利用の問題に取り組みます。 [RFC6696]次の2つの特定の展開シナリオに適用可能な、メソッドに依存しない再認証プロトコル（EAP Re-authentication Protocol（ERP））を指定します。
o where the peer's home EAP server also performs re-authentication; and
o ピアのホームEAPサーバーも再認証を実行します。そして
o where a local re-authentication server exists but is co-located with an Authentication, Authorization, and Accounting (AAA) proxy within the domain.
o ローカル再認証サーバーは存在するが、ドメイン内の認証、承認、およびアカウンティング（AAA）プロキシと同じ場所に配置されている場合。
Other work provides further pieces of the solution or insight into the problem. For the purpose of this memo, Hoeper, et al. [RFC5749] provide an abstract mechanism for distribution of keying material from the EAP server to re-authentication servers. Ohba, et al. [RFC5836] contrast the EAP Re-authentication (ER) strategy provided by ERP with an alternative strategy called "early authentication". RFC 5836 defines EAP early authentication as the use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival. Hence, the goal of EAP early authentication is to complete all EAP-related communications, including AAA signaling, in preparation for the handover, before the mobile device actually moves. Early authentication includes direct and indirect pre-authentication as well as Authenticated Anticipatory Keying (AAK). All three early authentication mechanisms provide means to securely establish authenticated keying material on a Candidate Attachment Point (CAP) while still being connected to the Serving Attachment Point (SAP) but vary in their respective system assumptions and communication paths. In particular, direct pre-authentication assumes that clients are capable of discovering CAPs and all communications are routed through the SAP. On the other hand, indirect pre-authentication assumes an existing relationship between the SAP and CAP, whereas the discovery and selection of CAPs is outside the scope of AAK. Furthermore, both direct and indirect pre-authentication require a full EAP execution to occur before the handover of the peer takes place, while AAK techniques (like ERP [RFC6696]) use keys derived from the initial EAP authentication.
他の作業は、ソリューションのさらなる部分または問題への洞察を提供します。このメモの目的のために、Hoeper、等。 [RFC5749]は、EAPサーバーから再認証サーバーにキー情報を配布するための抽象的なメカニズムを提供します。大場他[RFC5836] ERPによって提供されるEAP再認証（ER）戦略と、「早期認証」と呼ばれる代替戦略とを対比してください。 RFC 5836は、EAP早期認証を、モバイルピアによるEAPの使用として、到着前にターゲットアタッチメントポイントに認証済みのキー情報を確立することを定義しています。したがって、EAP早期認証の目的は、モバイルデバイスが実際に移動する前に、ハンドオーバーの準備として、AAAシグナリングを含むすべてのEAP関連の通信を完了することです。初期認証には、直接および間接の事前認証と、Authenticated Anticipatory Keying（AAK）が含まれます。初期の3つの認証メカニズムはすべて、サービス提供接続ポイント（SAP）に接続されたまま、候補接続ポイント（CAP）で認証済みのキー情報を安全に確立する手段を提供しますが、それぞれのシステムの前提および通信パスは異なります。特に、直接事前認証は、クライアントがCAPを検出でき、すべての通信がSAP経由でルーティングされることを前提としています。一方、間接事前認証は、SAPとCAPの間に既存の関係があることを前提としていますが、CAPの検出と選択はAAKの範囲外です。さらに、直接および間接の両方の事前認証では、ピアのハンドオーバーが行われる前に完全なEAPが実行される必要があります。一方、AAK技法（ERP [RFC6696]など）は、初期EAP認証から導出されたキーを使用します。
Both EAP re-authentication and early authentication enable faster inter-authenticator handovers. However, it is currently unclear how the necessary handover infrastructure can be deployed and integrated into existing EAP infrastructures. In particular, previous work has not described how ER servers that act as endpoints in the re-authentication process should be integrated into local and home domain networks. Furthermore, how EAP infrastructure can support the timely triggering of early authentications and aid with the selection of CAPs is currently unspecified.
EAP再認証と早期認証の両方により、認証者間のハンドオーバーが高速化されます。ただし、現在、必要なハンドオーバーインフラストラクチャをどのように展開し、既存のEAPインフラストラクチャに統合できるかは不明です。特に、以前の研究では、再認証プロセスでエンドポイントとして機能するERサーバーをローカルおよびホームドメインネットワークに統合する方法については説明していません。さらに、EAPインフラストラクチャが早期認証のタイムリーなトリガーをサポートし、CAPの選択を支援する方法は現在のところ指定されていません。
This document proposes a general HOKEY architecture and demonstrates how it can be adapted to different deployment scenarios. To begin with, Section 3 recalls the design objectives for the HOKEY architecture. Section 4 reviews the functions that must be supported within the architecture. Section 5 describes the components of the HOKEY architecture. Section 6 describes the different deployment scenarios that the HOKEY Working Group has addressed and the information flows that must occur within those scenarios, by reference to the documents summarized above where possible and otherwise within this document itself. Finally, Section 7 provides an analysis of how AAA protocols can be applied in the HOKEY architecture.
このドキュメントでは、一般的なHOKEYアーキテクチャを提案し、さまざまな展開シナリオにどのように適応できるかを示します。まず、セクション3では、HOKEYアーキテクチャの設計目標について説明します。セクション4では、アーキテクチャー内でサポートする必要のある機能を確認します。セクション5では、HOKEYアーキテクチャのコンポーネントについて説明します。セクション6では、HOKEYワーキンググループが対処したさまざまな展開シナリオと、それらのシナリオ内で発生する必要のある情報フローについて、可能な場合はこのドキュメント自体の中で上記の要約されたドキュメントを参照して説明しています。最後に、セクション7では、AAAプロトコルをどのようにHOKEYアーキテクチャに適用できるかを分析します。
This document reuses terms defined in Section 2 of Ohba, et al. [RFC5836] and Section 2 of Cao, et al. [RFC6696]. In addition, it defines the following:
このドキュメントでは、Ohbaなどのセクション2で定義されている用語を再利用しています。 [RFC5836]およびCao、et al。のセクション2。 [RFC6696]。さらに、以下を定義します。
DS-rRK Domain-Specific re-authentication Root Key.
DS-rRKドメイン固有の再認証ルートキー。
pMSK pre-established Master Session Key.
pMSKが事前に確立したマスターセッションキー。
EAP Early Authentication The use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival; see Ohba, et al. [RFC5836].
EAP早期認証モバイルピアがEAPを使用して、ターゲットアタッチメントポイントに到着する前に、認証されたキー情報を確立します。大場らを参照。 [RFC5836]。
ER Key Management An instantiation of the mechanism described in Hoeper, et al. [RFC5749] for creating and delivering root keys from an EAP server to an ER server.
ERキー管理Hoeperらで説明されているメカニズムのインスタンス化。 [RFC5749]ルートキーを作成してEAPサーバーからERサーバーに配信するため。
EAP Re-authentication (ER) The use of keying material derived from an initial EAP authentication to enable single-round-trip re-authentication of a mobile peer. For a detailed description of the keying material, see Section 4 of Cao, et al. [RFC6696].
EAP再認証（ER）モバイルピアの単一ラウンドトリップの再認証を可能にするための、初期EAP認証から導出されたキー情報の使用。キーイングマテリアルの詳細については、Caoなどのセクション4を参照してください。 [RFC6696]。
ER Server A component of the HOKEY architecture that terminates the EAP re-authentication exchange with the peer.
ERサーバーピアとのEAP再認証交換を終了するHOKEYアーキテクチャのコンポーネント。
This section investigates the design goals for the HOKEY architecture. These include reducing the signaling overhead for re-authentication and early authentication, integrating local domain name discovery, enabling fault-tolerant re-authentication, and improving deployment scalability. These goals supplement those discussed in Section 4 of RFC 5169. Note that the identification and selection of CAPs is not a goal of the architecture, since those operations are generally specific to the lower layer in use.
このセクションでは、HOKEYアーキテクチャの設計目標を調査します。これには、再認証と早期認証のシグナリングオーバーヘッドの削減、ローカルドメイン名の検出の統合、フォールトトレラントな再認証の有効化、展開のスケーラビリティの向上が含まれます。これらの目標は、RFC 5169のセクション4で説明されている目標を補足します。CAPの識別と選択は、一般的に使用中の下位層に固有であるため、アーキテクチャの目標ではないことに注意してください。
ERP [RFC6696] requires only one round trip; however, this round trip may require communication between a peer and its home ER and/or home AAA server in explicit bootstrapping and communication between local servers and the home server in implicit bootstrapping even if the peer is currently attached to a visited (local) network. As a result, even this one round trip may introduce long delays because the home ER and home AAA servers may be distant from the peer and the network to which it is attached. To lower signaling overhead, communication with the home ER server and home AAA server should be minimized. Ideally, a peer should only need to communicate with local servers and other local entities.
ERP [RFC6696]は、往復が1つだけ必要です。ただし、この往復では、ピアが現在訪問している（ローカル）ネットワークに接続されている場合でも、明示的なブートストラップでのピアとそのホームERまたはホームAAAサーバー間の通信と、暗黙的なブートストラップでのローカルサーバーとホームサーバー間の通信が必要になる場合があります。その結果、ホームERサーバーとホームAAAサーバーがピアとそれが接続されているネットワークから離れている可能性があるため、この1回のラウンドトリップでも長い遅延が発生する可能性があります。シグナリングのオーバーヘッドを下げるには、ホームERサーバーおよびホームAAAサーバーとの通信を最小限に抑える必要があります。理想的には、ピアはローカルサーバーおよび他のローカルエンティティとのみ通信する必要があります。
When the peer is initially attached to the network or moves between heterogeneous networks, full EAP authentication between the peer and EAP server occurs and user interaction may be needed, e.g., a dialog to prompt the user for credentials. To reduce latency, user interaction for authentication at each handover should be minimized. Ideally, user involvement should take place only during initial authentication and subsequent re-authentication should occur transparently.
ピアが最初にネットワークに接続されたとき、または異種ネットワーク間を移動したときに、ピアとEAPサーバーの間で完全なEAP認証が行われ、ユーザーに資格情報の入力を求めるダイアログなどのユーザー対話が必要になる場合があります。待ち時間を短縮するには、各ハンドオーバーでの認証のためのユーザー対話を最小限に抑える必要があります。理想的には、ユーザーの関与は初期認証時にのみ行われ、その後の再認証は透過的に行われる必要があります。
ERP bootstrapping must occur before (implicit) or during (explicit) a handover to transport the necessary keys to the local ER server involved. Implicit bootstrapping is preferable because it does not require communication with the home ER server during handover, but it requires that the peer know the domain name of the ER server before the subsequent local ERP exchange happens in order to derive the necessary re-authentication keying material. ERP [RFC6696] does not specify such a domain name discovery mechanism and suggests that the peer may learn the domain name through the EAP-Initiate/Re-auth-Start message or via lower-layer announcements. However, domain name discovery happens after the implicit bootstrapping completes, which may introduce extra latency. To allow more efficient handovers, a HOKEY architecture should support an efficient domain name discovery mechanism (for example, see Zorn, Wu & Wang [RFC6440]) and allow its integration with ERP implicit bootstrapping. Even in the case of explicit bootstrapping, LDN discovery should be optimized such that it does not require contacting the home AAA server, as is currently the case.
ERPブートストラップは、必要なキーを関係するローカルERサーバーに転送するために、ハンドオーバーの前（暗黙的）またはハンドオーバー中に（明示的）発生する必要があります。暗黙的なブートストラップは、ハンドオーバー中にホームERサーバーとの通信を必要としないため推奨されますが、必要な再認証キー情報を導出するために、後続のローカルERP交換が発生する前に、ピアがERサーバーのドメイン名を知っている必要があります。 。 ERP [RFC6696]は、そのようなドメイン名検出メカニズムを指定しておらず、ピアがEAP-Initiate / Re-auth-Startメッセージまたは下位層のアナウンスを通じてドメイン名を学習できることを示唆しています。ただし、ドメイン名の検出は、暗黙的なブートストラップの完了後に行われるため、余分な遅延が生じる可能性があります。より効率的なハンドオーバーを可能にするために、HOKEYアーキテクチャは効率的なドメイン名検出メカニズム（たとえば、Zorn、Wu＆Wang [RFC6440]を参照）をサポートし、ERP暗黙的ブートストラップとの統合を可能にする必要があります。明示的なブートストラップの場合でも、LDN検出は、現在のようにホームAAAサーバーに接続する必要がないように最適化する必要があります。
If all authentication services depend upon a remote server, a network partition can result in the denial of service to valid users. However, if for example an ER server exists in the local network, previously authenticated users can re-authenticate even though a link to the home or main authentication server doesn't exist.
すべての認証サービスがリモートサーバーに依存している場合、ネットワーク分割により、有効なユーザーに対してサービス拒否が発生する可能性があります。ただし、たとえばERサーバーがローカルネットワークに存在する場合、ホームまたはメインの認証サーバーへのリンクが存在しなくても、以前に認証されたユーザーは再認証できます。
To provide better deployment scalability, there should be no requirement for the co-location of entities providing handover keying services (e.g., ER servers) and AAA servers or proxies. Separation of these entities may cause problems with routing but allows greater flexibility in deployment and implementation.
展開のスケーラビリティを向上させるために、ハンドオーバーキーサービスを提供するエンティティ（ERサーバーなど）とAAAサーバーまたはプロキシを同じ場所に配置する必要はありません。これらのエンティティを分離すると、ルーティングに問題が発生する可能性がありますが、展開と実装の柔軟性が向上します。
The operation of the authentication subsystem provided by HOKEY also depends on the availability of a number of discovery functions:
HOKEYが提供する認証サブシステムの操作は、いくつかのディスカバリー機能の可用性にも依存します。
o discovery of CAPs by the peer, by the SAP, or by some other entity;
o ピア、SAP、またはその他のエンティティによるCAPの検出。
o discovery of the authentication services supported at a given CAP;
o 特定のCAPでサポートされている認証サービスの検出。
o discovery of the required server in the home domain when a CAP is not in the same domain as the SAP, or no local server is available;
o CAPがSAPと同じドメインにない場合、または使用可能なローカルサーバーがない場合に、ホームドメインで必要なサーバーを検出します。
o peer discovery of the LDN when EAP re-authentication is used with a local server.
o ローカルサーバーでEAP再認証を使用する場合のLDNのピア検出。
It is assumed that these functions are provided by the environment within which the authentication subsystem operates and are outside the scope of the authentication subsystem itself. LDN discovery is a possible exception.
これらの機能は、認証サブシステムが動作する環境によって提供され、認証サブシステム自体の範囲外であると想定されています。 LDNディスカバリーは可能な例外です。
The major functions comprising the authentication subsystem and their interdependencies are discussed in greater detail below.
認証サブシステムを構成する主な機能とその相互依存性については、以下で詳しく説明します。
o When AAA is invoked to authorize network access, it uses one of two services offered by the authentication subsystem: full EAP authentication or EAP re-authentication. Note that although AAA may perform authentication directly in some cases, when EAP is utilized AAA functions only as a transport for EAP messages and the encryption keys (if any) resulting from successful EAP authentication.
oネットワークアクセスを承認するためにAAAが呼び出されると、認証サブシステムによって提供される2つのサービス（完全なEAP認証またはEAP再認証）のいずれかを使用します。 AAAが直接認証を実行する場合もありますが、EAPが使用される場合、AAAはEAPメッセージのトランスポートとしてのみ機能し、EAP認証が成功した結果として暗号化キー（存在する場合）として機能することに注意してください。
o Pre-authentication triggers AAA network access authorization at each CAP, which in turn causes full EAP authentication to be invoked.
o 事前認証により、各CAPでAAAネットワークアクセス許可がトリガーされ、これにより、完全なEAP認証が呼び出されます。
o EAP re-authentication invokes ER key management at the time of authentication to create and distribute keying material to ER servers.
o EAP再認証は、認証時にERキー管理を呼び出して、キー生成情報を作成し、ERサーバーに配布します。
o AAK relies on ER key management to establish keying material on ER/AAK servers but uses an extension to ER key management to derive and establish keying material on candidate authenticators. AAK uses an extension to EAP re-authentication to communicate with ER/AAK servers.
o AAKは、ERキー管理に依存してER / AAKサーバーにキー情報を確立しますが、ERキー管理の拡張機能を使用して、候補認証システムにキー情報を導き出し、確立します。 AAKは、EAP再認証の拡張機能を使用して、ER / AAKサーバーと通信します。
EAP authentication, EAP re-authentication, and handover key distribution depend on the routing and secure transport service provided by AAA. Discovery functions and the function of authentication and authorization of network entities (access points, ER servers) are not shown. As stated above, these are external to the authentication subsystem.
EAP認証、EAP再認証、およびハンドオーバーキーの配布は、AAAが提供するルーティングとセキュアなトランスポートサービスに依存します。検出機能と、ネットワークエンティティ（アクセスポイント、ERサーバー）の認証と承認の機能は表示されていません。上記のように、これらは認証サブシステムの外部にあります。
The pre-authentication function is responsible for discovery of CAPs and completion of network access authentication and authorization at each CAP in advance of handover. The operation of this function is described in general terms in Ohba, et al. [RFC5836]. No document is yet available to describe the implementation of pre-authentication in terms of specific protocols; pre-authentication support for the Protocol for Carrying Authentication for Network Access (PANA) [RFC5873] could be part of the solution.
事前認証機能は、CAPの検出と、ハンドオーバーに先立つ各CAPでのネットワークアクセス認証と承認の完了を担当します。この関数の動作は、Ohbaらの一般用語で説明されています。 [RFC5836]。特定のプロトコルに関して事前認証の実装を説明する文書はまだありません。ネットワークアクセスの認証を運ぶためのプロトコル（PANA）[RFC5873]の事前認証サポートは、ソリューションの一部である可能性があります。
The EAP re-authentication function is responsible for authenticating the peer at a specific access point using keying material derived from a prior full EAP authentication. RFC 5169 [RFC5169] provides the design objectives for an implementation of this function. ERP [RFC6696] describes a protocol to implement EAP re-authentication.
EAP再認証機能は、以前の完全なEAP認証から導出されたキー情報を使用して、特定のアクセスポイントでピアを認証する役割を果たします。 RFC 5169 [RFC5169]は、この機能の実装のための設計目標を提供します。 ERP [RFC6696]は、EAP再認証を実装するプロトコルについて説明しています。
The EAP authentication function is responsible for authenticating the peer at a specific access point using a full EAP exchange. Aboba, et al. [RFC3748] define the associated protocol, while Ohba, et al. [RFC5836] describe the use of EAP as part of pre-authentication. Note that the HOKEY Working Group has not specified the non-AAA protocol required to transport EAP frames over IP that is shown in Figures 3 and 5 of Ohba, et al. [RFC5836], although PANA [RFC5873] is a candidate.
EAP認証機能は、完全なEAP交換を使用して、特定のアクセスポイントでピアを認証します。 Aboba、et al。 [RFC3748]は関連するプロトコルを定義しますが、Ohbaなど。 [RFC5836]は、事前認証の一部としてのEAPの使用について説明しています。 HOKEYワーキンググループは、大場らの図3および5に示されているIPを介してEAPフレームを転送するために必要な非AAAプロトコルを指定していないことに注意してください。 [RFC5836]、PANA [RFC5873]は候補です。
The AAK function is responsible for pre-placing keying material derived from an initial full EAP authentication on CAPs. The operation is carried out in two steps: ER key management (with trigger not currently specified) places root keys derived from initial EAP authentication onto an ER/AAK server associated with the peer. When requested by the peer, the ER/AAK server derives and pushes predefined master session keys to one or more CAPs. The operation of the AAK function is described in very general terms in Ohba, et al. [RFC5836]. A protocol specification exists (see Cao, et al. [RFC6630]).
AAK機能は、CAPでの最初の完全なEAP認証から派生したキー情報を事前に配置する責任があります。操作は2つのステップで実行されます。ERキー管理（トリガーは現在指定されていません）は、初期EAP認証から導出されたルートキーを、ピアに関連付けられたER / AAKサーバーに配置します。ピアから要求されると、ER / AAKサーバーは事前定義されたマスターセッションキーを取得して1つ以上のCAPにプッシュします。 AAK機能の操作は、Ohbaらの非常に一般的な用語で説明されています。 [RFC5836]。プロトコル仕様が存在します（Cao、et al。[RFC6630]を参照）。
Handover key management consists of EAP method-independent key derivation and distribution and comprises the following specific functions:
ハンドオーバーキー管理は、EAPメソッドに依存しないキーの導出と配布で構成され、次の特定の機能を備えています。
o handover key derivation
o ハンドオーバー鍵導出
o handover key distribution
o ハンドオーバーキー配布
The derivation of handover keys is specified in Salowey, et al. [RFC5295], and AAA-based key distribution is specified in Hoeper, Nakhjiri & Ohba [RFC5749].
ハンドオーバー鍵の導出は、Saloweyらで指定されています。 [RFC5295]、AAAベースのキー配布はHoeper、Nakhjiri、Ohba [RFC5749]で指定されています。
This section describes the components of the HOKEY architecture in terms of the functions they perform. The components cooperate as described in this section to carry out the functions described in the previous section. Section 6 describes the different deployment scenarios that are possible using these functions.
このセクションでは、HOKEYアーキテクチャのコンポーネントについて、それらが実行する機能の観点から説明します。このセクションで説明するように、コンポーネントは連携して、前のセクションで説明した機能を実行します。セクション6では、これらの機能を使用して可能なさまざまな展開シナリオについて説明します。
The components of the HOKEY architecture are as follows:
HOKEYアーキテクチャのコンポーネントは次のとおりです。
o the peer;
o ピア;
o the authenticator, which is a part of the SAP and CAPs;
o オーセンティケーター。SAPおよびCAPの一部です。
o the EAP server;
o EAPサーバー。
o the ER server; and
o ERサーバー。そして
o the ER/AAK server [RFC6630], either in the home domain or local to the authenticator.
o ER / AAKサーバー[RFC6630]（ホームドメイン内またはオーセンティケーターに対してローカル）。
The peer participates in the functions described in Section 4, as shown in Table 1.
ピアは、表1に示すように、セクション4で説明する機能に参加します。
+--------------------+----------------------------------------------+
| Function | Peer Role |
+--------------------+----------------------------------------------+
| EAP authentication | Determines that full EAP authentication is |
| | needed based on context (e.g., initial |
| | authentication), prompting from the |
| | authenticator, or discovery that only EAP |
| | authentication is supported. Participates |
| | in the EAP exchange with the EAP server. |
| - | - |
| Direct | Discovers CAPs. Initiates |
| pre-authentication | pre-authentication with each, followed by |
| | EAP authentication as above, but using IP |
| | rather than L2 transport for the EAP frames. |
| - | - |
| Indirect | Enters into a full EAP exchange when |
| pre-authentication | triggered, using either L2 or L3 transport |
| | for the frames. |
| - | - |
| EAP | Determines that EAP re-authentication is |
| re-authentication | possible based on discovery or authenticator |
| | prompting. Participates in ERP exchange |
| | with the ER server. |
| - | - |
| AAK | Determines that AAK is possible based on |
| | discovery or serving authenticator |
| | prompting. Discovers CAPs. Participates in |
| | ERP/AAK exchange, requesting distribution of |
| | keying material to the CAPs. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 1: Functions of the Peer
表1：ピアの機能
The serving authenticator participates in the functions described in Section 4, as shown in Table 2.
表2に示すように、サービスを提供するオーセンティケーターは、セクション4で説明されている機能に参加します。
+--------------------+----------------------------------------------+
| Function | Serving Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | Discovers CAPs. Initiates an EAP exchange |
| pre-authentication | between the peer and the EAP server through |
| | each candidate authenticator. Mediates |
| | between L2 transport of EAP frames on the |
| | peer side and a non-AAA protocol over IP |
| | toward the CAP. |
| - | - |
| EAP | No role. |
| re-authentication | |
| - | - |
| AAK | Mediates between L2 transport of AAK frames |
| | on the peer side and AAA transport toward |
| | the ER/AAK server. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 2: Functions of the Serving Authenticator
表2：サービス提供オーセンティケーターの機能
The candidate authenticator participates in the functions described in Section 4, as shown in Table 3.
オーセンティケーター候補は、表3に示すように、セクション4で説明する機能に参加します。
+--------------------+----------------------------------------------+
| Function | Candidate Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | Invokes AAA network access authentication |
| | and authorization upon handover/initial |
| | attachment. Mediates between L2 transport |
| | of EAP frames on the peer link and AAA |
| | transport toward the EAP server. |
| - | - |
| Direct | Invokes AAA network access authentication |
| pre-authentication | and authorization when the peer initiates |
| | authentication. Mediates between non-AAA L3 |
| | transport of EAP frames on the peer side and |
| | AAA transport toward the EAP server. |
| - | - |
| Indirect | Same as direct pre-authentication, except |
| pre-authentication | that it communicates with the serving |
| | authenticator rather than the peer. |
| - | - |
| EAP | Invokes AAA network access authentication |
| re-authentication | and authorization upon handover. Discovers |
| | or is configured with the address of the ER |
| | server. Mediates between L2 transport of |
| | ERP frames on the peer side and AAA |
| | transport toward the ER server. |
| - | - |
| AAK | Receives and saves the pMSK. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 3: Functions of the Candidate Authenticator
表3：候補認証システムの機能
The EAP server participates in the functions described in Section 4, as shown in Table 4.
EAPサーバーは、表4に示すように、セクション4で説明する機能に参加します。
+--------------------+----------------------------------------------+
| Function | EAP Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | Terminates EAP signaling between it and the |
| | peer via the candidate authenticator. |
| | Determines whether network access |
| | authentication succeeds or fails. Provides |
| | the MSK to the authenticator (via AAA). |
| - | - |
| Direct | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| Indirect | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| EAP | Provides an rRK or DS-rRK to the ER server |
| re-authentication | (via AAA). |
| - | - |
| AAK | Same as for EAP re-authentication. |
| - | - |
| ER key management | Creates an rRK or DS-rRK and distributes it |
| | to the ER server requesting the information. |
+--------------------+----------------------------------------------+
Table 4: Functions of the EAP Server
表4：EAPサーバーの機能
The ER server participates in the functions described in Section 4, as shown in Table 5.
ERサーバーは、表5に示すように、セクション4で説明する機能に参加します。
+--------------------+----------------------------------------------+
| Function | ER Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | No role. |
| pre-authentication | |
| - | - |
| EAP | Acquires an rRK or DS-rRK as applicable when |
| re-authentication | necessary. Terminates ERP signaling between |
| | it and the peer via the candidate |
| | authenticator. Determines whether network |
| | access authentication succeeds or fails. |
| | Provides an MSK to the authenticator. |
| - | - |
| AAK | Acquires an rRK or DS-rRK as applicable when |
| | necessary. Derives pMSKs and passes them to |
| | the CAPs. |
| - | - |
| ER key management | Receives and saves an rRK or DS-rRK as |
| | applicable. |
+--------------------+----------------------------------------------+
Table 5: Functions of the ER Server
表5：ERサーバーの機能
Depending upon whether a change in a domain or access technology is involved, we have the following usage scenarios.
ドメインまたはアクセステクノロジの変更が関係しているかどうかに応じて、次の使用シナリオがあります。
The peer remains stationary and re-authenticates to the original access point. Note that in this case, the SAP takes the role of the CAP in the discussion above.
ピアは静止したままで、元のアクセスポイントに対して再認証します。この場合、SAPは上記の説明でCAPの役割を果たします。
The peer moves between two authenticators in the same domain. In this scenario, the peer communicates with the ER server via the ER authenticator within the same network.
ピアは、同じドメイン内の2つの認証システム間を移動します。このシナリオでは、ピアは同じネットワーク内のERオーセンティケーターを介してERサーバーと通信します。
The peer moves between two different domains. In this scenario, the peer communicates with more than one ER server via one or two different ER authenticators. One ER server is located in the current network as the peer, and one is located in the previous network from which the peer moves. Another ER server is located in the home network to which the peer belongs.
ピアは2つの異なるドメイン間を移動します。このシナリオでは、ピアは1つまたは2つの異なるERオーセンティケーターを介して複数のERサーバーと通信します。 1つのERサーバーは現在のネットワークにピアとして配置され、1つはピアが移動する前のネットワークに配置されます。別のERサーバーが、ピアが属するホームネットワークに配置されています。
The peer moves between two heterogeneous networks. In this scenario, the peer needs to support at least two access technologies. The coverage of two access technologies usually is overlapped during handover. In this case, only authentication corresponding to intra-domain handover is required; i.e., the peer can communicate with the same local ER server to complete authentication and obtain keying material corresponding to the peer.
ピアは2つの異種ネットワーク間を移動します。このシナリオでは、ピアは少なくとも2つのアクセステクノロジーをサポートする必要があります。通常、2つのアクセステクノロジーのカバレッジは、ハンドオーバー中に重複します。この場合、ドメイン内ハンドオーバーに対応する認証のみが必要です。つまり、ピアは同じローカルERサーバーと通信して、認証を完了し、ピアに対応するキー情報を取得できます。
This section provides an analysis of how the AAA protocol can be applied in the HOKEY architecture in accordance with Section 4.1 ("Authentication Subsystem Functional Overview").
このセクションでは、セクション4.1（「認証サブシステムの機能の概要」）に従ってAAAプロトコルをHOKEYアーキテクチャに適用する方法を分析します。
Authorization is a major issue in deployments. Wherever the peer moves around, the home AAA server provides authorization for the peer during its handover. However, it is unnecessary to couple authorization with authentication at every handover, since authorization is only needed when the peer is initially attached to the network or moves between two different AAA domains. The EAP key management document [RFC5247] discusses several vulnerabilities that are common to handover mechanisms. One important issue arises from the way that the authorization decisions might be handled at the AAA server during network access authentication. For example, if AAA proxies are involved, they may also influence authorization decisions. Furthermore, the reasons for choosing a particular decision are not communicated to the AAA clients. In fact, the AAA client only knows the final authorization result. Another issue relates to session management. In some circumstances, when the peer moves from one authenticator to another, the peer may be authenticated by the different authenticator during a period of time, and the authenticator to which the peer is currently attached needs to create a new AAA user session; however, the AAA server should not view these handoffs as different sessions. Otherwise, this may affect user experience and also cause accounting or logging issues. For example, session ID creation, in most cases, is done by each authenticator to which the peer attaches. In this sense, the new authenticator acting as AAA client needs to create a new AAA user session from scratch, which forces its corresponding AAA server to terminate the existing user session with the previous authenticator and set up a new user session with the new authenticator. This may complicate the setup and maintenance of the AAA user session.
承認は、展開における主要な問題です。ピアがどこに移動しても、ホームAAAサーバーは、ハンドオーバー中にピアに承認を提供します。ただし、許可はピアが最初にネットワークに接続されているとき、または2つの異なるAAAドメイン間を移動するときにのみ必要なので、すべてのハンドオーバー時に認証と認証を組み合わせる必要はありません。 EAPキー管理ドキュメント[RFC5247]では、ハンドオーバーメカニズムに共通するいくつかの脆弱性について説明しています。重要な問題の1つは、ネットワークアクセス認証中にAAAサーバーで承認決定が処理される方法から発生します。たとえば、AAAプロキシが関係している場合、それらは承認の決定にも影響を与える可能性があります。さらに、特定の決定を選択する理由は、AAAクライアントには通知されません。実際、AAAクライアントは最終的な認証結果しか知りません。別の問題は、セッション管理に関連しています。状況によっては、ピアが1つの認証システムから別の認証システムに移動すると、ピアが一定期間中に別の認証システムによって認証され、現在ピアが接続されている認証システムが新しいAAAユーザーセッションを作成する必要があります。ただし、AAAサーバーはこれらのハンドオフを別のセッションと見なすべきではありません。それ以外の場合、これはユーザーエクスペリエンスに影響し、アカウンティングまたはロギングの問題を引き起こす可能性があります。たとえば、セッションIDの作成は、ほとんどの場合、ピアが接続する各認証システムによって行われます。この意味で、AAAクライアントとして機能する新しいオーセンティケーターは、新しいAAAユーザーセッションを最初から作成する必要があります。これにより、対応するAAAサーバーは、以前のオーセンティケーターとの既存のユーザーセッションを終了し、新しいオーセンティケーターとの新しいユーザーセッションをセットアップします。これにより、AAAユーザーセッションのセットアップとメンテナンスが複雑になる場合があります。
The existing AAA protocols can be used to carry EAP and ERP messages between the AAA server and AAA clients. AAA transport of ERP messages is specified in Hoeper, Nakhjiri & Ohba [RFC5749] and Bournelle, et al. [DIAMETER-ERP]. AAA transport of EAP messages is specified in [RFC4072]. Key transport also can be performed through a AAA protocol. Zorn, Wu & Cakulev [DIAMETER-AVP] specify a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery.
既存のAAAプロトコルを使用して、AAAサーバーとAAAクライアント間でEAPおよびERPメッセージを伝送できます。 ERPメッセージのAAAトランスポートは、Hoeper、Nakhjiri、Ohba [RFC5749]およびBournelleなどで指定されています。 [DIAMETER-ERP]。 EAPメッセージのAAAトランスポートは[RFC4072]で指定されています。キー転送は、AAAプロトコルを介して実行することもできます。 Zorn、Wu＆Cakulev [DIAMETER-AVP]は、暗号鍵配信のネイティブDiameterサポートを提供する一連の属性値ペア（AVP）を指定します。
This document does not introduce any new security vulnerabilities.
このドキュメントでは、新しいセキュリティの脆弱性は紹介されていません。
The authors would like to thank Mark Jones, Zhen Cao, Semyon Mizikovsky, Stephen Farrell, Ondrej Sury, Richard Barnes, Jari Arkko, and Lionel Morand for their reviews and comments.
著者は、レビューとコメントを提供してくれたMark Jones、Zhen Cao、Semyon Mizikovsky、Stephen Farrell、Ondrej Sury、Richard Barnes、Jari Arkko、Lionel Morandに感謝します。
[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、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[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、「Handover Key Management and Re-Authentication Problem Statement」、RFC 5169、2008年3月。
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836] Ohba、Y。、編、Wu、Q。、編、およびG. Zorn、編、「Extensible Authentication Protocol（EAP）Early Authentication Problem Statement」、RFC 5836、2010年4月。
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, July 2012.
[RFC6696] Cao、Z.、He、B.、Shi、Y.、Wu、Q.、Ed。、およびG. Zorn、Ed。、「EAP再認証プロトコル（ERP）のEAP拡張機能」、RFC 6696、2012年7月。
[DIAMETER-AVP] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Work in Progress, August 2011.
[DIAMETER-AVP] Zorn、G.、Wu、Q。、およびV. Cakulev、「暗号化キートランスポートの直径の属性と値のペア」、進行中の作業、2011年8月。
[DIAMETER-ERP] Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G. Zorn, "Diameter Support for the EAP Re-authentication Protocol (ERP)", Work in Progress, June 2012.
[DIAMETER-ERP] Bournelle、J.、Morand、L.、Deculis、S.、Wu、Q。、およびG. Zorn、「Diameter Support for the EAP Re-authentication Protocol（ERP）」、Work in Progress、6月2012。
[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、「Diameter Extensible Authentication Protocol（EAP）Application」、RFC 4072、2005年8月。
[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、「Extensible Authentication Protocol（EAP）Key Management Framework」、RFC 5247、2008年8月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295] Salowey、J.、Dondeti、L.、Narayanan、V。、およびM. Nakhjiri、「拡張マスターセッションキー（EMSK）からのルートキーの派生に関する仕様」、RFC 5295、2008年8月。
[RFC5749] Hoeper, K., Ed., Nakhjiri, M., and Y. Ohba, Ed., "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010.
[RFC5749] Hoeper、K.、Ed。、Nakhjiri、M.、およびY. Ohba、Ed。、「Distribution of EAP-Based Keys for Handover and Re-Authentication」、RFC 5749、2010年3月。
[RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5873, May 2010.
[RFC5873] Ohba、Y。およびA. Yegin、「ネットワークアクセスの認証を実行するためのプロトコルの事前認証サポート（PANA）」、RFC 5873、2010年5月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440] Zorn、G.、Wu、Q。、およびY. Wang、「EAP再認証プロトコル（ERP）ローカルドメイン名DHCPv6オプション」、RFC 6440、2011年12月。
[RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.
[RFC6630] Cao、Z.、Deng、H.、Wu、Q。、およびG. Zorn、編、「Authenticated Anticipatory Keying（ERP / AAK）のEAP再認証プロトコル拡張機能」、RFC 6630、2012年6月。
Authors' Addresses
著者のアドレス
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 909 201060 EMail: glenzorn@gmail.com
Gelen Joron（編集者）Network Zen 228/356 Thanong Sunfoung Bang Na、Bangkok 10260 Thailand電話：+8（0）909から1080メール：Glenzoron：Gmail.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China Phone: +86-25-84565892 EMail: bill.wu@huawei.com
Wuhu AのQはテクノロジー株式会社向けです。101ソフトウェアアベニュー、Y Uは地区NaN京、江蘇省210012中国を電話します：+ 86-25-84565892メール：Bill。無@ Huawei.com
Tom Taylor Huawei Technologies Co., Ltd. Ottawa, Ontario Canada EMail: tom.taylor.stds@gmail.com
Tom Taylor Huawei Technologies Co.、Ltd.オタワ、オンタリオカナダEメール：tom.taylor.stds@gmail.com
Yoav Nir Check Point 5 Hasolelim St. Tel Aviv 67897 Israel EMail: ynir@checkpoint.com
Yoav Nir Check Point 5 Hasolelim St. Tel Aviv 67897 Israel EMail：ynir@checkpoint.com
Katrin Hoeper Motorola Solutions, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA EMail: khoeper@motorolasolutions.com>
かｔりん ほえぺｒ もとろぁ そぅちおんｓ、 いんｃ。 １３０１ え。 あｌごんくいん ろあｄ Ｓちゃうｍぶｒｇ、 いＬ ６０１９６ うさ えまいｌ： ｋほえぺｒ＠もとろぁそぅちおんｓ。こｍ＞
Sebastien Decugis INSIDE Secure 41 Parc Club du Golf Aix-en-Provence 13856 France Phone: +33 (0)4 42 39 63 00 EMail: sdecugis@freediameter.net
Sebastien Decugis INSIDE Secure 41 Parc Club du Golf Aix-en-Provence 13856 France電話：+33（0）4 42 39 63 00メール：sdecugis@freediameter.net