[要約] 要約：RFC 5169は、モバイルネットワークでのハンドオーバーキー管理と再認証の問題を説明しています。 目的：このRFCの目的は、ハンドオーバーキー管理と再認証の問題を明確にし、解決策を提案することです。
Network Working Group T. Clancy
Request for Comments: 5169 LTS
Category: Informational M. Nakhjiri
Motorola
V. Narayanan
L. Dondeti
Qualcomm
March 2008
Handover Key Management and Re-Authentication Problem Statement
ハンドオーバーキー管理と再認証問題ステートメント
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover.
このドキュメントでは、ハンドオーバーキーイング（Hokey）の再認証問題の声明について説明しています。現在の拡張可能な認証プロトコル（EAP）キーイングフレームワークは、EAPメソッドを再実行せずに再認証と拳オーバーをサポートするようには設計されていません。これは、多くの場合、さまざまなモバイルワイヤレス環境で容認できない遅延を引き起こします。このドキュメントは、問題の詳細を詳述し、派生したEAPキーイング材料を引き渡すために再利用するための一般的なメカニズムの設計目標を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
6.1. Method-Specific EAP Re-Authentication . . . . . . . . . . 9
6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
The Extensible Authentication Protocol (EAP), specified in RFC 3748 [RFC3748] is a generic framework supporting multiple authentication methods. The primary purpose of EAP is network access control. It also supports exporting session keys derived during the authentication. The EAP keying hierarchy defines two keys that are derived at the top level, the Master Session Key (MSK) and the Extended Master Session Key (EMSK).
RFC 3748 [RFC3748]で指定された拡張可能な認証プロトコル（EAP）は、複数の認証方法をサポートする汎用フレームワークです。EAPの主な目的は、ネットワークアクセス制御です。また、認証中に導出されたセッションキーのエクスポートをサポートします。EAPキーイング階層は、マスターセッションキー（MSK）と拡張マスターセッションキー（EMSK）であるトップレベルで導出される2つのキーを定義します。
In many common deployment scenarios, an EAP peer and EAP server authenticate each other through a third party known as the pass-through authenticator (hereafter referred to as simply "authenticator"). The authenticator is responsible for encapsulating EAP packets from a network-access technology lower layer within the Authentication, Authorization, and Accounting (AAA) protocol. The authenticator does not directly participate in the EAP exchange, and simply acts as a gateway during the EAP method execution.
多くの一般的な展開シナリオでは、EAPピアとEAPサーバーは、パススルー認証機として知られる第三者を介して互いに認証されます（以下、単に「認証者」と呼ばれます）。Authenticatorは、認証、承認、および会計（AAA）プロトコル内のネットワークアクセステクノロジーの下位レイヤーからのEAPパケットをカプセル化する責任があります。AuthenticatorはEAP Exchangeに直接参加することはなく、EAPメソッドの実行中に単にゲートウェイとして機能します。
After successful authentication, the EAP server transports the MSK to the authenticator. Note that this is performed using AAA protocols, not EAP itself. The underlying L2 or L3 protocol uses the MSK to derive additional keys, including the transient session keys (TSKs) used for per-packet encryption and authentication.
認証が成功した後、EAPサーバーはMSKをAuthenticatorに輸送します。これは、EAP自体ではなく、AAAプロトコルを使用して実行されることに注意してください。基礎となるL2またはL3プロトコルは、MSKを使用して、パケットごとの暗号化と認証に使用される一時的なセッションキー（TSK）を含む追加のキーを導き出します。
Note that while the authenticator is one logical device, there can be multiple physical devices involved. For example, the CAPWAP model [RFC3990] splits authenticators into two logical devices: Wireless Termination Points (WTPs) and Access Controllers (ACs). Depending on the configuration, authenticator features can be split in a variety of ways between physical devices; however, from the EAP perspective, there is only one logical authenticator.
Authenticatorは1つの論理デバイスですが、複数の物理デバイスが関与する可能性があることに注意してください。たとえば、CAPWAPモデル[RFC3990]は、認証器を2つの論理デバイスに分割します：ワイヤレス終了ポイント（WTPS）とアクセスコントローラー（ACS）。構成に応じて、認証機の機能は、物理デバイス間でさまざまな方法で分割できます。ただし、EAPの観点からは、論理認証器は1つだけです。
Wireless handover between access points or base stations is typically a complex process that involves several layers of protocol execution. Often times executing these protocols results in unacceptable delays for many real-time applications such as voice [MSA03]. One part of the handover process is EAP re-authentication, which can contribute significantly to the overall handover time [MSPCA04]. Thus, in many environments we can lower overall handover time by lowering EAP re-authentication time.
アクセスポイントまたはベースステーション間のワイヤレスハンドオーバーは、通常、プロトコル実行のいくつかの層を含む複雑なプロセスです。多くの場合、これらのプロトコルを実行すると、Voice [MSA03]などの多くのリアルタイムアプリケーションが受け入れられない遅延が生じます。ハンドオーバープロセスの一部はEAP再認証であり、これは全体的なハンドオーバー時間に大きく貢献できます[MSPCA04]。したがって、多くの環境では、EAPの再認証時間を短縮することにより、全体的なハンドオーバー時間を短縮できます。
In EAP existing implementations, when a peer arrives at the new authenticator, it runs an EAP method irrespective of whether it has been authenticated to the network recently and has unexpired keying material. This typically involves an EAP-Response/Identity message from the peer to the server, followed by one or more round trips between the EAP server and peer to perform the authentication, followed by the EAP-Success or EAP-Failure message from the EAP server to the peer. At a minimum, the EAP exchange consists of 1.5 round trips. However, given the way EAP interacts with AAA, and given that an EAP identity exchange is typically employed, at least 2 round trips are required to the EAP server. An even higher number of round trips is required by the most commonly used EAP methods. For instance, EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) requires at least 3, but typically 4 or more, round trips.
EAP既存の実装では、ピアが新しい認証機に到着すると、最近ネットワークに認証されており、キーイング素材が終了していないかどうかに関係なく、EAPメソッドを実行します。これには通常、ピアからサーバーへのEAP応答/アイデンティティメッセージが含まれ、その後、EAPサーバーとピア間の1つ以上のラウンドトリップが認証を実行し、その後にEAPサクセスまたはEAPサーバーからのEAP-Failureメッセージが続きます。ピアに。少なくとも、EAP交換は1.5ラウンド旅行で構成されています。ただし、EAPがAAAと対話する方法を考えると、EAP ID交換が通常使用されることを考えると、EAPサーバーには少なくとも2回のラウンド旅行が必要です。最も一般的に使用されるEAPメソッドでは、さらに多くの往復が必要です。たとえば、EAP -TLS（拡張可能な認証プロトコル - 輸送層のセキュリティ）には、少なくとも3回は必要ですが、通常は4回以上の往復が必要です。
There have been attempts to solve the problem of efficient re-authentication in various ways. However, those solutions are either EAP-method specific or EAP lower-layer specific. Furthermore, these solutions do not deal with scenarios involving handovers to new authenticators, or they do not conform to the AAA keying requirements specified in [RFC4962].
さまざまな方法で効率的な再認証の問題を解決しようとする試みがありました。ただし、これらのソリューションは、EAPメソッド固有またはEAP低層層固有のいずれかです。さらに、これらのソリューションは、新しい認証機への手観察を含むシナリオを扱うものではなく、[RFC4962]で指定されたAAAキーイング要件に準拠していません。
This document provides a detailed description of efficient EAP-based re-authentication protocol design goals. The scope of this protocol is specifically re-authentication and handover between authenticators within a single administrative domain. While the design goals presented in this document may facilitate inter-technology handover and inter-administrative-domain handover, they are outside the scope of this protocol.
このドキュメントは、効率的なEAPベースの再認証プロトコル設計目標の詳細な説明を提供します。このプロトコルの範囲は、単一の管理ドメイン内の認証者間の再認証と引き渡しです。このドキュメントで提示された設計目標は、技術間のハンドオーバーと政治間ドメインのハンドオーバーを促進する可能性がありますが、これらはこのプロトコルの範囲外です。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the qualification that, unless otherwise stated, they apply to the design of the re-authentication protocol, not its implementation or application.
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているとおりに解釈するために、特に明記しない限り、その実装やアプリケーションではなく、再認証プロトコルの設計に適用されるという資格とともに。
With respect to EAP, this document follows the terminology that has been defined in [RFC3748] and [EAP-KEYING].
EAPに関して、このドキュメントは[RFC3748]および[EAP-Keying]で定義されている用語に従います。
Under the existing model, any re-authentication requires a full EAP exchange with the EAP server to which the peer initially authenticated [RFC3748]. This introduces handover latency from both network transit time and processing delay. In service provider networks, the home EAP server for a peer could be on the other side of the world, and typical intercontinental latencies across the Internet are 100 to 300 milliseconds per round trip [LGS07].
既存のモデルでは、再認証は、ピアが最初に認証されたEAPサーバーとの完全なEAP交換を必要とします[RFC3748]。これにより、ネットワークトランジット時間と処理遅延の両方からハンドオーバーレイテンシが導入されます。サービスプロバイダーネットワークでは、ピア用のホームEAPサーバーが世界の反対側にある可能性があり、インターネット上の典型的な大陸間潜伏latesは、往復あたり100〜300ミリ秒です[LGS07]。
Processing delays average a couple of milliseconds for symmetric-key operations and hundreds of milliseconds for public-key operations.
処理は、対称キー操作では平均数ミリ秒、パブリックキー運用で数百ミリ秒遅れです。
An EAP conversation with a full EAP method run can take two or more round trips to complete, causing delays in re-authentication and handover times. Some methods specify the use of keys and state from the initial authentication to finish subsequent authentications in fewer round trips and without using public-key operations (detailed in Section 6.1). However, even in those cases, multiple round trips to the EAP server are required, resulting in unacceptable handover times.
完全なEAPメソッドの実行を使用したEAP会話は、2回以上の往復を完了するために完了し、再認証と引き渡し時間の遅延を引き起こす可能性があります。一部の方法では、初期認証からキーと状態の使用を指定して、パブリックキー操作を使用せずに、往復を減らして後続の認証を完了します（セクション6.1で詳細）。ただし、これらの場合でも、EAPサーバーへの複数のラウンド旅行が必要であり、その結果、容認できないハンドオーバー時間があります。
In summary, it is undesirable to run an EAP Identity and complete EAP method exchange each time a peer authenticates to a new authenticator or needs to extend its current authentication with the same authenticator. Furthermore, it is desirable to specify a method-independent, efficient, re-authentication protocol. Keying material from the initial authentication can be used to enable efficient re-authentication. It is also desirable to have a local server with low-latency connectivity to the peer that can facilitate re-authentication. Lastly, a re-authentication protocol should also be capable of supporting scenarios where an EAP server passes authentication information to a remote re-authentication server, allowing a peer to re-authenticate locally, without having to communicate with its home re-authentication server.
要約すると、Peerが新しい認証機に認証するたびに、EAP IDを実行し、EAPメソッド交換を完了することは望ましくありません。さらに、メソッドに依存し、効率的な、再認可プロトコルを指定することが望ましいです。初期認証のキーイング材料を使用して、効率的な再認証を可能にすることができます。また、再認証を促進できる、ピアへの低遅延の接続性を備えたローカルサーバーを持つことも望ましいです。最後に、再認証プロトコルは、EAPサーバーが認証情報をリモート再認証サーバーに渡すシナリオをサポートできる必要があります。
These problems are the primary issues to be resolved. In solving them, there are a number of constraints to conform to, and those result in some additional work to be done in the area of EAP keying.
これらの問題は、解決すべき主要な問題です。それらを解決するには、適合すべき多くの制約があり、それらはEAPキーイングの領域でいくつかの追加の作業を行う必要があります。
The following are the goals and constraints in designing the EAP re-authentication and key management protocol:
以下は、EAPの再認証と主要な管理プロトコルを設計する際の目標と制約です。
Lower-latency operation: The protocol MUST be responsive to handover and re-authentication latency performance objectives within a mobile access network. A solution that reduces latency as compared to a full EAP authentication will be most favorable, since in networks that rely on reactive re-authentication this will directly impact handover times.
低遅延操作：プロトコルは、モバイルアクセスネットワーク内のハンドオーバーおよび再認定のレイテンシーパフォーマンス目標に対応する必要があります。完全なEAP認証と比較してレイテンシを削減するソリューションが最も有利です。これは、リアクティブな再認証に依存するネットワークでは、ハンドオーバー時間に直接影響するためです。
EAP lower-layer independence: Any keying hierarchy and protocol defined MUST be lower-layer independent in order to provide capabilities over heterogeneous technologies. The defined protocols MAY require some additional support from the lower layers that use it, but should not require any particular lower layer.
EAP低層層の独立性：定義されたキーイング階層とプロトコルは、不均一なテクノロジーよりも能力を提供するために、より低層層独立でなければなりません。定義されたプロトコルは、それを使用する下層からの追加のサポートを必要とする場合がありますが、特定の下層層を必要としないはずです。
EAP method independence: Changes to existing EAP methods MUST NOT be required as a result of the re-authentication protocol. There MUST be no requirements imposed on future EAP methods, provided they satisfy [EAP-KEYING] and [RFC4017]. Note that the only EAP methods for which independence is required are those that currently conform to the specifications of [EAP-KEYING] and [RFC4017]. In particular, methods that do not generate the keys required by [EAP-KEYING] need not be supported by the re-authentication protocol.
EAPメソッドの独立性：既存のEAPメソッドの変更は、再認証プロトコルの結果として必須ではありません。[EAP-Keying]および[RFC4017]を満たしていれば、将来のEAPメソッドに課される要件はありません。独立が必要な唯一のEAPメソッドは、現在[EAP-Keying]および[RFC4017]の仕様に適合している方法であることに注意してください。特に、[EAP-Keying]に必要なキーを生成しない方法は、再認証プロトコルによってサポートされる必要はありません。
AAA protocol compatibility and keying: Any modifications to EAP and EAP keying MUST be compatible with RADIUS [RADEXT-DESIGN] and Diameter [DIME-APP-DESIGN]. Extensions to both RADIUS and Diameter to support these EAP modifications are acceptable. The designs and protocols must be configurable to satisfy the AAA key management requirements specified in RFC 4962 [RFC4962].
AAAプロトコルの互換性とキーイング：EAPおよびEAPキーイングの変更は、半径[Radext-Design]および直径[Dime-App-Design]と互換性がなければなりません。これらのEAP修正をサポートするために、半径と直径の両方に拡張することは許容されます。設計とプロトコルは、RFC 4962 [RFC4962]で指定されているAAAキー管理要件を満たすために構成可能でなければなりません。
Compatibility: Compatibility and coexistence with compliant ([RFC3748] [EAP-KEYING]) EAP deployments MUST be provided. Specifically, the protocol should be designed such that a peer not supporting fast re-reauthentication should still function in a network supporting fast re-authentication, and also a peer supporting fast re-authentication should still function in a network not supporting fast re-authentication.
互換性：準拠（[rfc3748] [eap-keying]）との互換性と共存を提供する必要があります。具体的には、プロトコルは、高速な再認証をサポートしていないピアが迅速な再認証をサポートするネットワークで機能するように設計する必要があります。また、高速な再認証をサポートするピアは、高速な再認証をサポートしないネットワークでまだ機能する必要があります。。
Cryptographic Agility: Any re-authentication protocol MUST support cryptographic algorithm agility, to avoid hard-coded primitives whose security may eventually prove to be compromised. The protocol MAY support cryptographic algorithm negotiation, provided it does not adversely affect overall performance (i.e., by requiring additional round trips).
暗号化の俊敏性：再認証プロトコルは、セキュリティが最終的に侵害される可能性があるハードコード化されたプリミティブを避けるために、暗号化アルゴリズムの俊敏性をサポートする必要があります。プロトコルは、全体的なパフォーマンスに悪影響を及ぼさない場合（つまり、追加の往復を必要とすることで）、暗号化アルゴリズムのネゴシエーションをサポートする場合があります。
Impact to Existing Deployments: Any re-authentication protocol MAY make changes to the peer, authenticator, and EAP server, as necessary to meet the aforementioned design goals. In order to facilitate protocol deployment, protocols should seek to minimize the necessary changes, without sacrificing performance.
既存の展開への影響：再認証プロトコルは、前述の設計目標を達成するために必要に応じて、ピア、認証機、およびEAPサーバーに変更を加える場合があります。プロトコルの展開を促進するために、プロトコルはパフォーマンスを犠牲にすることなく、必要な変更を最小限に抑えるよう努める必要があります。
This section draws from the guidance provided in [RFC4962] to further define the security goals to be achieved by a complete re-authentication keying solution.
このセクションでは、[RFC4962]で提供されたガイダンスから、完全な再認証キーイングソリューションによって達成されるセキュリティ目標をさらに定義します。
Any key must have a well-defined scope and must be used in a specific context and for the intended use. This specifically means the lifetime and scope of each key must be defined clearly so that all entities that are authorized to have access to the key have the same context during the validity period. In a hierarchical key structure, the lifetime of lower-level keys must not exceed the lifetime of higher-level keys. This requirement may imply that the context and the scope parameters have to be exchanged. Furthermore, the semantics of these parameters must be defined to provide proper channel binding specifications. The definition of exact parameter syntax definition is part of the design of the transport protocol used for the parameter exchange, and that may be outside scope of this protocol.
任意のキーは明確に定義されたスコープを持っている必要があり、特定のコンテキストで、および使用するために使用する必要があります。これは、具体的には、各キーの寿命と範囲を明確に定義する必要があることを意味し、キーにアクセスすることが許可されているすべてのエンティティが有効期間中に同じコンテキストを持つようにします。階層的なキー構造では、低レベルのキーの寿命は、高レベルのキーの寿命を超えてはなりません。この要件は、コンテキストとスコープパラメーターを交換する必要があることを意味する場合があります。さらに、適切なチャネル結合仕様を提供するために、これらのパラメーターのセマンティクスを定義する必要があります。正確なパラメーター構文定義の定義は、パラメーター交換に使用されるトランスポートプロトコルの設計の一部であり、このプロトコルの範囲外である可能性があります。
If a key hierarchy is deployed, compromising lower-level keys must not result in a compromise of higher-level keys that were used to derive the lower-level keys. The compromise of keys at each level must not result in compromise of other keys at the same level. The same principle applies to entities that hold and manage a particular key defined in the key hierarchy. Compromising keys on one authenticator must not reveal the keys of another authenticator. Note that the compromise of higher-level keys has security implications on lower levels.
キー階層が展開されている場合、低レベルのキーを侵害すると、低レベルのキーを導出するために使用された高レベルのキーの妥協が得られないようにしてはなりません。各レベルでのキーの妥協は、同じレベルで他のキーの妥協をもたらさないはずです。同じ原則は、重要な階層で定義されている特定のキーを保持および管理するエンティティに適用されます。1つの認証器に妥協するキーは、別の認証装置のキーを明らかにしてはなりません。高レベルのキーの妥協は、より低いレベルにセキュリティに影響を与えることに注意してください。
Guidance on parameters required, caching, and storage and deletion procedures to ensure adequate security and authorization provisioning for keying procedures must be defined in a solution document.
適切なセキュリティとキーイング手順の許可プロビジョニングを確実に確保するために、必要なパラメーター、キャッシュ、および保管および削除手順に関するガイダンスは、ソリューションドキュメントで定義する必要があります。
All the keying material must be uniquely named so that it can be managed effectively.
すべてのキーイング素材は、効果的に管理できるように独自に名前を付けなければなりません。
As [RFC4962] defines, a fresh key is one that is generated for the intended use. This would mean the key hierarchy must provide for creation of multiple cryptographically separate child keys from a root key at higher level. Furthermore, the keying solution needs to provide mechanisms for refreshing each of the keys within the key hierarchy.
[rfc4962]が定義するように、新鮮なキーは、使用するために生成されるものです。これは、キー階層が、より高いレベルのルートキーから複数の暗号的に分離された子キーを作成するために提供する必要があることを意味します。さらに、キーイングソリューションは、キー階層内の各キーを更新するためのメカニズムを提供する必要があります。
Each handover keying participant must be authenticated to any other party with whom it communicates to the extent it is necessary to ensure proper key scoping, and securely provide its identity to any other entity that may require the identity for defining the key scope.
各ハンドオーバーキーイング参加者は、適切なキースコーピングを確保するために必要な範囲でコミュニケーションをとる他の当事者に認証され、重要な範囲を定義するためにアイデンティティを必要とする可能性のある他のエンティティにそのアイデンティティを安全に提供する必要があります。
The EAP Key management document [EAP-KEYING] discusses several vulnerabilities that are common to handover mechanisms. One important issue arises from the way the authorization decisions might be handled at the AAA server during network access authentication. Furthermore, the reasons for making a particular authorization decision are not communicated to the authenticator. In fact, the authenticator only knows the final authorization result. The proposed solution must make efforts to document and mitigate authorization attacks.
EAPキー管理ドキュメント[EAP-Keying]は、引き渡しメカニズムに共通するいくつかの脆弱性について説明します。1つの重要な問題は、ネットワークアクセス認証中にAAAサーバーで承認の決定が処理される方法から生じます。さらに、特定の承認決定を下す理由は、認証者に伝えられません。実際、認証者は最終的な認証結果のみを知っています。提案されたソリューションは、承認攻撃を文書化し、軽減する努力をしなければなりません。
Channel Binding procedures are needed to avoid a compromised intermediate authenticator providing unverified and conflicting service information to each of the peer and the EAP server. To support fast re-authentication, there will be intermediate entities between the peer and the back-end EAP server. Various keys need to be established and scoped between these parties and some of these keys may be parents to other keys. Hence, the channel binding for this architecture will need to consider layering intermediate entities at each level to make sure that an entity with a higher level of trust can examine the truthfulness of the claims made by intermediate parties.
侵害された中間認証機を回避するために、チャネルバインディング手順が必要です。各ピアとEAPサーバーに未検証で矛盾するサービス情報を提供します。迅速な再認証をサポートするために、ピアとバックエンドEAPサーバーの間に中間エンティティがあります。これらのパーティーの間にはさまざまなキーを確立してスコープする必要があり、これらのキーの一部は他のキーの親である場合があります。したがって、このアーキテクチャのチャネル拘束は、各レベルの中間エンティティを階層化することを検討して、より高いレベルの信頼を持つエンティティが中間当事者による主張の真実性を調べることができることを確認する必要があります。
Depending on the physical architecture and the functionality of the elements involved, there may be a need for multiple protocols to perform the key transport between entities involved in the handover keying architecture. Thus, a set of requirements for each of these protocols, and the parameters they will carry, must be developed.
物理的アーキテクチャと関連する要素の機能に応じて、ハンドオーバーキーイングアーキテクチャに関与するエンティティ間で重要な輸送を実行するために複数のプロトコルが必要になる場合があります。したがって、これらの各プロトコルの要件のセットと、それらが携帯するパラメーターを開発する必要があります。
The use of existing AAA protocols for carrying EAP messages and keying material between the AAA server and AAA clients that have a role within the architecture considered for the keying problem will be carefully examined. Definition of specific parameters, required for keying procedures and for being transferred over any of the links in the architecture, are part of the scope. The relation between the identities used by the transport protocol and the identities used for keying also needs to be explored.
AAAサーバーとキーイングの問題を考慮したアーキテクチャ内で役割を果たしているAAAサーバーとAAAクライアントの間でEAPメッセージとキーイング素材を携帯するための既存のAAAプロトコルの使用は、慎重に検討されます。キーイングプロシージャに必要な特定のパラメーターの定義、およびアーキテクチャのリンクのいずれかに転送されるためには、範囲の一部です。輸送プロトコルで使用されるアイデンティティとキーイングに使用されるアイデンティティとの関係も調査する必要があります。
In order to further clarify the items listed in scope of the proposed work, this section provides some background on related work and the use cases envisioned for the proposed work.
提案された作業の範囲にリストされている項目をさらに明確にするために、このセクションでは、関連する作業と提案された作業のために想定されるユースケースに関する背景を提供します。
A number of EAP methods support fast re-authentication. In this section, we examine their properties in further detail.
多くのEAPメソッドは、高速な再認証をサポートしています。このセクションでは、それらの特性をさらに詳細に調べます。
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re-authentication, bootstrapped by the keys generated during an initial full authentication. In response to the typical EAP-Request/ Identity, the peer sends a specially formatted identity indicating a desire to perform a fast re-authentication. A single round-trip occurs to verify knowledge of the existing keys and provide fresh nonces for generating new keys. This is followed by an EAP success. In the end, it requires a single local round trip between the peer and authenticator, followed by another round trip between the peer and EAP server. AKA is based on symmetric-key cryptography, so processing latency is minimal.
EAP-SIM [RFC4186]およびEAP-AKA [RFC4187]は、最初の完全な認証中に生成されたキーによってブートストラップされた高速な再認証をサポートします。典型的なEAP-Request/ Identityに応えて、ピアは、迅速な再認証を実行したいという欲求を示す特別にフォーマットされたアイデンティティを送信します。既存のキーの知識を検証し、新しいキーを生成するための新鮮な非能力を提供するために、単一の往復が発生します。これに続いて、EAPの成功が続きます。最終的に、ピアと認証者の間のローカルラウンド旅行が必要であり、ピアサーバーとEAPサーバーの間の別の往復が続きます。AKAは対称的なキー暗号化に基づいているため、レイテンシの処理は最小限です。
EAP-TTLS [EAP-TTLS] and PEAP (Protected EAP Protocol) [JOSEFSSON-PPPEXT] support using TLS session resumption for fast re-authentication. During the TLS handshake, the client includes the message ID of the previous session he wishes to resume, and the server can echo that ID back if it agrees to resume the session. EAP-FAST [RFC4851] also supports TLS session resumption, but additionally allows stateless session resumption as defined in [RFC5077]. Overall, for all three protocols, there are still two round trips between the peer and EAP server, in addition to the local round trip for the Identity request and response.
EAP-TTLS [EAP-TTLS]およびPEAP（Protected EAP Protocol）[Josefsson-Pppext]サポートTLSセッションを使用して、迅速な再認証のために再開します。TLSハンドシェイク中、クライアントは再開したい前のセッションのメッセージIDを含め、セッションの再開に同意した場合、サーバーはそのIDを反映することができます。EAP-Fast [RFC4851]はTLSセッション再開もサポートしていますが、[RFC5077]で定義されているステートレスセッション再開も可能になります。全体として、3つのプロトコルすべてについて、IDリクエストと応答のためのローカルラウンドトリップに加えて、ピアサーバーとEAPサーバーの間にまだ2回の往復があります。
To improve performance, fast re-authentication needs to reduce the number of overall round trips. Optimal performance could result from eliminating the EAP-Request/Identity and EAP-Response/Identity messages observed in typical EAP method execution, and allowing a single round trip between the peer and a local re-authentication server.
パフォーマンスを向上させるには、迅速な再認証が必要です。全体的なラウンド旅行の数を減らす必要があります。最適なパフォーマンスは、典型的なEAPメソッド実行で観察されるEAP-Request/IDとEAP応答/IDメッセージを排除し、ピアとローカルの再認証サーバーの間の1回の丸い旅行を許可することから生じる可能性があります。
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in the process of specifying a fast handover mechanism. Access Points (APs) are grouped into mobility domains. Initial authentication to any AP in a mobility domain requires execution of EAP, but handover between APs within the mobility domain does not require the use of EAP.
EAP下層の1つであるIEEE 802.11 [IEEE.802-11R-D9.0]は、高速ハンドオーバーメカニズムを指定するプロセスにあります。アクセスポイント（APS）は、モビリティドメインにグループ化されます。モビリティドメインの任意のAPへの初期認証には、EAPの実行が必要ですが、モビリティドメイン内のAP間の引き渡しでは、EAPの使用は必要ありません。
Internal to the mobility domain are sets of security associations to support key transfers between APs. In one model, relatively few devices, called R0-KHs, act as authenticators. All EAP traffic traverses an R0-KH, and it derives the initial IEEE 802.11 keys. It then distributes cryptographically separate keys to APs in the mobility domain, as necessary, to support the client mobility. For a deployment with M designated R0-KHs and N APs, this requires M*N security associations. For small M, this approach scales reasonably. Another approach allows any AP to act as an R0-KH, necessitating a full mesh of N2 security associations, which scales poorly.
モビリティドメインの内部は、AP間の重要な転送をサポートするセキュリティ関連のセットです。1つのモデルでは、R0-KHSと呼ばれる比較的少数のデバイスが認証器として機能します。すべてのEAPトラフィックはR0-khを横断し、初期のIEEE 802.11キーを導き出します。次に、クライアントのモビリティをサポートするために、必要に応じて、モビリティドメインのAPに暗号化されたキーを分離します。Mが指定されたR0-khsおよびn APSを使用した展開の場合、これにはM*nセキュリティ関連が必要です。小さなmの場合、このアプローチは合理的に拡大します。別のアプローチにより、APはR0-KHとして機能することができ、N2セキュリティ関連の完全なメッシュを必要とします。
The model that utilizes designated R0-KHs is architecturally similar to the fast re-authentication model proposed by HOKEY. HOKEY, however, allows for handover between authenticators. This would allow an IEEE 802.11r-enabled peer to handover from one mobility domain to another without performing an EAP authentication.
指定されたR0-KHSを利用するモデルは、Hokeyが提案した高速再認証モデルと建築的に似ています。ただし、Hokeyは、認証者間の引き渡しを可能にします。これにより、IEEE 802.11R対応のピアが、EAP認証を実行せずに、あるモビリティドメインから別のモビリティドメインへと引き渡すことができます。
The CAPWAP (Control and Provisioning of Wireless Access Points) protocol [CAPWAP-PROTOCOL-SPEC] allows the functionality of an IEEE 802.11 access point to be split into two physical devices in enterprise deployments. Wireless Termination Points (WTPs) implement the physical and low-level Media Access Control (MAC) layers, while a centralized Access Controller (AC) provides higher-level management and protocol execution. Client authentication is handled by the AC, which acts as the AAA authenticator.
CAPWAP（ワイヤレスアクセスポイントの制御とプロビジョニング）プロトコル[CAPWAP-Protocol-Spec]により、IEEE 802.11アクセスポイントの機能は、エンタープライズ展開の2つの物理デバイスに分割されます。ワイヤレス終端ポイント（WTPS）は、物理的および低レベルのメディアアクセス制御（MAC）レイヤーを実装し、集中型アクセスコントローラー（AC）は高レベルの管理とプロトコルの実行を提供します。クライアント認証は、AAA認証器として機能するACによって処理されます。
One of the many features provided by CAPWAP is the ability to roam between WTPs without executing an EAP authentication. To accomplish this, the AC caches the MSK from an initial EAP authentication, and uses it to execute a separate four-way handshake with the station as it moves between WTPs. The keys resulting from the four-way handshake are then distributed to the WTP to which the station is associated. CAPWAP is transparent to the station.
CapWapが提供する多くの機能の1つは、EAP認証を実行せずにWTPS間を歩き回る機能です。これを達成するために、ACは最初のEAP認証からMSKをキャッシュし、それを使用して、WTPS間を移動する際にステーションで個別の四方握手を実行します。4方向の握手に起因するキーは、ステーションが関連付けられているWTPに配布されます。CapWapは駅に透明です。
CAPWAP currently has no means to support roaming between ACs in an enterprise network. The proposed work on EAP efficient re-authentication addresses is an inter-authenticator handover problem from an EAP perspective, which applies during handover between ACs. Inter-AC handover is a topic yet to be addressed in great detail and the re-authentication work can potentially address it in an effective manner.
CapWapは現在、エンタープライズネットワークのACS間のローミングをサポートする手段がありません。EAP効率の高い再認証アドレスに関する提案された作業は、ACS間のハンドオーバー中に適用されるEAPの観点からの認証間のハンドオーバー問題です。Inter-ACハンドオーバーは、まだ詳細に対処されていないトピックであり、再認可作業は効果的な方法で対処する可能性があります。
This document details the HOKEY problem statement. Since HOKEY is an authentication protocol, there is a myriad of security-related issues surrounding its development and deployment.
このドキュメントは、Hokeyの問題ステートメントを詳述しています。Hokeyは認証プロトコルであるため、開発と展開を取り巻くセキュリティ関連の問題が無数にあります。
In this document, we have detailed a variety of security properties inferred from [RFC4962] to which HOKEY must conform, including the management of key context, scope, freshness, and transport; resistance to attacks based on the domino effect; and authentication and authorization. See Section 5 for further details.
このドキュメントでは、[RFC4962]から推測されるさまざまなセキュリティプロパティについて詳しく説明しています。ドミノ効果に基づく攻撃に対する抵抗。および認証と承認。詳細については、セクション5を参照してください。
This document represents the synthesis of two problem statement documents. In this section, we acknowledge their contributions, and involvement in the early documents.
このドキュメントは、2つの問題ステートメントドキュメントの統合を表しています。このセクションでは、彼らの貢献と初期の文書への関与を認めます。
Mohan Parthasarathy Nokia EMail: mohan.parthasarathy@nokia.com
Mohan Parthasarathy Nokiaメール：mohan.parthasarathy@nokia.com
Julien Bournelle France Telecom R&D EMail: julien.bournelle@orange-ftgroup.com
Julien Bournelle France Telecom R＆Dメール：julien.bournele@orange-ftgroup.com
Hannes Tschofenig Siemens EMail: Hannes.Tschofenig@siemens.com
Hannes tschofenig siemensメール：hannes.tschofenig@siemens.com
Rafael Marin Lopez Universidad de Murcia EMail: rafa@dif.um.es
Rafael Marin Lopez Universidad de Murciaメール：rafa@dif.um.es
The authors would like to thank the participants of the HOKEY working group for their review and comments including: Glen Zorn, Dan Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to thank those that provided last-call reviews including: Bernard Aboba, Alan DeKok, Jari Arkko, and Hannes Tschofenig.
著者は、Glen Zorn、Dan Harkins、Joe Salowey、Yoshi Ohbaなどのレビューとコメントについて、Hokeyワーキンググループの参加者に感謝したいと思います。著者はまた、バーナード・アボバ、アラン・デコック、ジャリ・アークコ、ハンヌ・ツェコフェニグなど、最後のレビューを提供したものに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（EAP）メソッド要件」、RFC 4017、2005年3月。
[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月。
[CAPWAP-PROTOCOL-SPEC] Calhoun, P., Montemurro, M., and D. Stanely, "CAPWAP Protocol Specification", Work in Progress, March 2008.
[Capwap-Protocol-Spec] Calhoun、P.、Montemurro、M。、およびD. Stanely、「Capwap Protocol Specification」、2008年3月、Work in Progress。
[DIME-APP-DESIGN] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, "Diameter Applications Design Guidelines", Work in Progress, January 2008.
[Dime-App-Design] Fajardo、V.、Asveren、T.、Tschofenig、H.、McGregor、G。、およびJ. Loughney、「Diameter Applications Design Guidelines」、2008年1月の作業。
[EAP-KEYING] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, November 2007.
[EAP-Keying] Aboba、B.、Simon、D。、およびP. Eronen、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、2007年11月、Work in Progress。
[EAP-TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", Work in Progress, March 2008.
[eap-ttls] Funk、P。and S. Blake-Wilson、「EAP Tunneled TLS認証プロトコルバージョン0（EAP-TTLSV0）」、2008年3月、進行中の作業。
[IEEE.802-11R-D9.0] "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, January 2008.
[IEEE.802-11R -D9.0] "情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様 - 修正2：Fast BSS Transition "、IEEE Standard 802.11r、2008年1月。
[JOSEFSSON-PPPEXT] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[Josefsson-Pppext] Josefsson、S.、Palekar、A.、Simon、D。、およびG. Zorn、「Protected EAP Protocol（PEAP）バージョン2」、2004年10月の作業進行中。
[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network Coordinates in the Wild", USENIX Symposium on Networked System Design and Implementation, April 2007.
[LGS07] Ledlie、J.、Gardner、P。、およびM. Selter、「Network Coordinates in the Wild」、2007年4月、ネットワーク化されたシステム設計と実装に関するUsenix Symposium。
[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of the IEEE 802.11 MAC-Layer Handoff Process", ACM SIGCOMM Computer and Communications Review, April 2003.
[MSA03] Mishra、A.、Shin、M。、およびW. Arbaugh、「IEEE 802.11 Mac-Layer Handoff Processの経験的分析」、ACM Sigcomm Computer and Communications Review、2003年4月。
[MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W. Arbaugh, "Proactive Key Distribution using Neighbor Graphs", IEEE Wireless Communications, February 2004.
[MSPCA04] Mishra、A.、Shin、M.、Petroni、N.、Clancy、T。、およびW. Arbaugh、「隣接グラフを使用したプロアクティブキーディストリビューション」、IEEE Wireless Communications、2004年2月。
[RADEXT-DESIGN] Weber, G. and A. DeKok, "RADIUS Design Guidelines", Work in Progress, December 2007.
[Radext-Design] Weber、G。およびA. Dekok、「Radius Design Guidelines」、2007年12月の進行中。
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[RFC3990] O'Hara、B.、Calhoun、P。、およびJ. Kempf、「ワイヤレスアクセスポイント（CAPWAP）問題ステートメントの構成とプロビジョニング」、RFC 3990、2005年2月。
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4186] Haverinen、H。およびJ. Salowey、「モバイル通信のためのグローバルシステムのための拡張可能な認証プロトコル法（GSM）サブスクライバーIDモジュール（EAP-SIM）」、RFC 4186、2006年1月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187] Arkko、J。およびH. Haverinen、「第3世代認証と主要な合意（EAP-AKA）のための拡張可能な認証プロトコル法」、RFC 4187、2006年1月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851] Cam-Winget、N.、McGrew、D.、Salowey、J。、およびH. Zhou、「安全なトンネル拡張可能な認証プロトコル法（EAP-FAST）を介した柔軟な認証」、RFC 4851、2007年5月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしでの輸送層セキュリティ（TLS）セッション再開」、RFC 5077、2008年1月。
Authors' Addresses
著者のアドレス
T. Charles Clancy, Editor Laboratory for Telecommunications Sciences US Department of Defense College Park, MD USA
T.チャールズクランシー、電気通信科学編集研究所米国国防総省カレッジパーク、メリーランド州
EMail: clancy@LTSnet.net
Madjid Nakhjiri Motorola
Madjid Nakhjiri Motorola
EMail: madjid.nakhjiri@motorola.com
Vidya Narayanan Qualcomm, Inc. San Diego, CA USA
Vidya Narayanan Qualcomm、Inc。サンディエゴ、カリフォルニア州アメリカ
EMail: vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. San Diego, CA USA
Lakshminath Dondeti Qualcomm、Inc。サンディエゴ、カリフォルニア州アメリカ
EMail: ldondeti@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。