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キーイング階層は、トップレベルで誘導される2つのキーを定義し、マスターセッションキー（MSK）及び拡張マスタセッションキー（EMSK）。
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サーバはパススルー認証者として知られている第三者を介して互いに認証（以下、単に「認証者」と呼びます）。オーセンティケータは、認証、許可、アカウンティング（AAA）プロトコル内のネットワークアクセス技術下位層からEAPパケットをカプセル化する責任があります。オーセンティケータはEAP直接交換に参加し、単に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を輸送します。 AAAプロトコルを使用して行われるこの、自分自身をEAPないことに注意してください。下地L2又はL3プロトコルは、パケットごとの暗号化と認証のために使用されるトランジエントセッション鍵（TSKs）を含む追加の鍵を導出するためにMSKを使用します。
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.
オーセンティケータは、一つの論理デバイスであるが、関与する複数の物理デバイスが存在し得ることに留意されたいです。ワイヤレスターミネーションポイント（WTPs）とアクセスコントローラ（ACS）：例えば、CAPWAPモデル[RFC3990]は二つの論理デバイスにオーセンティケータを分割します。設定によっては、オーセンティケータ機能は、物理デバイス間のさまざまな方法で分割することができます。ただし、EAPの観点から、唯一つの論理オーセンティケータがあります。
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.
アクセスポイントまたは基地局間の無線ハンドオーバは、典型的には、プロトコル実行のいくつかの層を含む複雑なプロセスです。しばしば、[MSA03]音声などの多くのリアルタイムアプリケーションのために許容できない遅延がこれらのプロトコルの結果を実行します。ハンドオーバ処理の一部は、全体ハンドオーバ時間[MSPCA04]に大きく寄与することができるEAP再認証です。このように、多くの環境では、我々は、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-成功またはEAP-失敗メッセージに続いて、認証を実行するEAPサーバとピアとの間の1件のまたは複数のラウンドトリップが続くサーバへのピアからのEAP-Response / Identityメッセージを、必要としますピアへ。最低でも、EAP交換が1.5往復で構成されています。しかしながら、EAPは、AAAと対話する方法を与え、そしてEAPアイデンティティ交換は、典型的には、少なくとも2回の往復がEAPサーバに要求されている、使用されていることを考えます。往復のより高い数は、最も一般的に使用される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.
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように、特に明記しない限り、資格と、解釈されるべきで、それらは再認証プロトコルではなく、その実施またはアプリケーションの設計に適用されます。
With respect to EAP, this document follows the terminology that has been defined in [RFC3748] and [EAP-KEYING].
EAPに関しては、このドキュメントは[RFC3748]と[EAPキーイング]で定義された用語に従います。
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].
既存のモデルでは、任意の再認証は、ピアが最初に認証された[RFC3748]にするEAPサーバとの完全なEAP交換が必要です。これは、ネットワーク通過時間と処理遅延の両方からハンドオーバ待ち時間を導入します。サービスプロバイダーネットワークでは、ピアのホームEAPサーバは、世界の反対側にあることができ、インターネットを介して、典型的な大陸間の待ち時間は、往復[LGS07]あたり100〜300ミリ秒です。
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の会話は、再認証とハンドオーバ時間の遅れを引き起こし、完了するために、二つ以上のラウンドトリップを取ることができます。いくつかの方法は、より少ないラウンドトリップでと（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.
要約すると、ピアは新しいオーセンティケータに認証したり、同じオーセンティケータとの現在の認証を拡張する必要があるたびにEAPアイデンティティと完全な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方法に課される要件があってはならない、彼らは[EAP-KEYING]と[RFC4017]を満たす提供。独立性が必要とされるだけのEAPメソッドは、現在、[EAP-KEYING]と[RFC4017]の仕様に準拠したものであることに注意してください。具体的には、[EAPキーイング]で必要なキーを生成しない方法は、再認証プロトコルによってサポートされる必要はありません。
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キーイングに対する変更はRADIUS [RADEXT-DESIGN]とDiameter [DIME-APP-DESIGN]と互換性がなければなりません。これらのEAPの変更をサポートするためのRADIUSおよび直径の両方への拡張が許容されます。デザインとプロトコルは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キーイング]）との互換性と共存EAP展開を提供しなければなりません。具体的には、プロトコルは、高速再再認証をサポートしないピアは依然として速い再認証をサポートするネットワークで機能する必要があり、また、速い再認証をサポートするピアは依然として速い再認証をサポートしないネットワークで機能するべきであるように設計されるべきです。
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キーイングは、ハンドオーバ機構に共通するいくつかの脆弱性を論じています。一つの重要な問題は、認可決定がネットワークアクセス認証中に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クライアント間で材料を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に応答して、ピアが速い再認証を実行するための希望を示す特別な形式の識別情報を送信します。 1回のラウンドトリップは、既存のキーの知識を確認し、新しいキーを生成するための新鮮なナンスを提供するために発生します。これは、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]と速い再認証のためにTLSセッション再開を使用してPEAP（保護されたEAPプロトコル）[Josefsson氏-PPPEXT]サポート。 TLSハンドシェイク中に、クライアントは、彼が再開することを希望する前のセッションのメッセージIDが含まれており、それがセッションを再開することに同意した場合、サーバーはバックそのIDをエコーすることができます。 EAP-FAST [RFC4851]もTLSセッション再開をサポートしていますが、[RFC5077]で定義されるようにさらにステートレスセッション再開を可能にします。全体的に、すべての3つのプロトコルのために、ピアと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要求/アイデンティティおよびEAP応答/アイデンティティメッセージを排除し、ピアとローカル再認証サーバとの間の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下位層の一つは、IEEE 802.11 [IEEE.802-11R-D9.0]、高速ハンドオーバメカニズムを特定する処理です。アクセスポイント（AP）は、モビリティドメインにグループ化されています。モビリティドメイン内の任意の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間のキーの転送をサポートするために、セキュリティアソシエーションのセットです。一つのモデルでは、R0-KHSと呼ばれる比較的少数のデバイスは、オーセンティケータとして機能します。すべてのEAPトラフィックはR0-KHを横断し、それが最初のIEEE 802.11の鍵を導出します。これは、クライアントのモビリティをサポートするために、必要に応じて、モビリティドメイン内のAPに暗号的に独立したキーを配布しています。 R0-KHSとNのAP指定されたMと展開については、これはM * N個のセキュリティアソシエーションが必要です。小さなMの場合、このアプローチは、合理的に拡張できます。別のアプローチは、任意のAPが不十分スケールN2のセキュリティアソシエーションのフルメッシュを、必要、R0-KHとして動作させることができます。
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は、しかし、オーセンティケータ間のハンドオーバーが可能になります。これは、EAP認証を行うことなく、別のモビリティドメインからのハンドオーバにIEEE 802.11rの対応ピアを可能にします。
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プロトコル-SPEC]はIEEE 802.11アクセスポイントの機能は、企業の展開に2つの物理デバイスに分割されることを可能にします。無線ターミネーションポイント（WTPs）集中アクセスコントローラ（AC）は、より高いレベルの管理及びプロトコルの実行を提供しながら、物理的および低レベルのメディアアクセス制御（MAC）層を実装します。クライアント認証は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によって提供される多くの機能の一つは、EAP認証を実行することなくWTPs間でローミングする能力です。これを達成するために、ACは、初期EAP認証からMSKをキャッシュし、それがWTPs間を移動するようにステーションを有する別個の四方向ハンドシェイクを実行するためにそれを使用します。四方向ハンドシェイクに起因するキーは、ステーションが関連付けられている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の観点から相互認証者のハンドオーバの問題です。インター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.
この文書では、我々は、キーコンテキスト、スコープ、鮮度、及び輸送の管理を含むHOKEYが適合しなければならないれた[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.
この文書では、二つの問題文文書の合成を表しています。このセクションでは、我々は彼らの貢献を認め、早期の文書への関与。
Mohan Parthasarathy Nokia EMail: mohan.parthasarathy@nokia.com
モハンパルタサラティノキアEメール：mohan.parthasarathy@nokia.com
Julien Bournelle France Telecom R&D EMail: julien.bournelle@orange-ftgroup.com
ジュリアンBournelleフランステレコムR＆D Eメール：julien.bournelle@orange-ftgroup.com
Hannes Tschofenig Siemens EMail: Hannes.Tschofenig@siemens.com
ハンネスTschofenigシーメンスEメール：Hannes.Tschofenig@siemens.com
Rafael Marin Lopez Universidad de Murcia EMail: rafa@dif.um.es
ムルシアメールのラファエル・マリン・ロペス大学：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.
グレンツォルン、ダンハーキンズ、ジョーSalowey、およびヨシ大場：作者は彼らのレビューとを含むコメントをHOKEYワーキンググループの参加者に感謝したいと思います。バーナードAboba、アランDeKok、ヤリArkko、およびハンネスTschofenig：著者も含めて、最後の呼び出しレビューを提供しているものに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、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]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（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。および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]カルフーン、P.、モンテムッロ、M.、およびD. Stanely、 "CAPWAPプロトコル仕様"、進歩、2008年3月での作業。
[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]ファハルド、V.、Asveren、T.、Tschofenig、H.、マクレガー、G.、およびJ. Loughney、 "Diameterアプリケーション設計ガイドライン"、進歩、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.、サイモン、D.、およびP. Eronen、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、進歩、2007年11月に作業。
[EAP-TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", Work in Progress, March 2008.
[EAP-TTLS]ファンク、P.とS.ブレーク - ウィルソン、 "EAPトンネル化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：高速BSS遷移」、IEEE標準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.、サイモン、D.、およびG.ツォルン、 "保護されたEAPプロトコル（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.、ガードナー、P.、およびM. Selter、 "ワイルドでネットワーク座標"、USENIXシンポジウム、2007年4月。
[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]ミシュラ、A.、新、M.、およびW. Arbaugh、 "IEEE 802.11 MACレイヤハンドオフプロセスの実証分析"、ACM SIGCOMMコンピュータとコミュニケーションレビュー、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]ミシュラ、A.、新、M.、ペトローニ、N.、クランシー、T.、およびW. Arbaugh、 "隣人グラフを使用して積極的なキー配布"、IEEE無線通信、2004年2月。
[RADEXT-DESIGN] Weber, G. and A. DeKok, "RADIUS Design Guidelines", Work in Progress, December 2007.
[RADEXT-DESIGN]ウェーバー、G.とA. DeKok、 "RADIUS設計ガイドライン"、進歩、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]オハラ、B.、カルフーン、P.、およびJ.ケンフ、 "ワイヤレスアクセスポイント（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）加入者識別モジュール（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]カムウィンゲット、N.、マグリュー、D.、Salowey、J.、およびH.周、RFC 4851、2007年5月 "（EAP-FAST）セキュアなトンネリング拡張認証プロトコル方法を介してフレキシブル認証"。
[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.、周、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.チャールズ・クランシー、電気通信科学米国国防総省のカレッジパーク、MD USAのためのエディタ研究所
EMail: clancy@LTSnet.net
メールアドレス：clancy@LTSnet.net
Madjid Nakhjiri Motorola
マジドNakhjiriモトローラ
EMail: madjid.nakhjiri@motorola.com
メールアドレス：madjid.nakhjiri@motorola.com
Vidya Narayanan Qualcomm, Inc. San Diego, CA USA
Vidyaナラヤナンクアルコム社、サンディエゴ、CA USA
EMail: vidyan@qualcomm.com
メールアドレス：vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. San Diego, CA USA
Lakshminath Dandetiクアルコム、これ。サンディエゴ、それかどうか
EMail: ldondeti@qualcomm.com
メールアドレス：ldondeti@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。