[要約] RFC 6677は、EAPメソッドのためのチャネルバインディングサポートに関する規格です。目的は、EAPメソッドのセキュリティを向上させ、認証プロセスの信頼性を確保することです。
Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 6677 Painless Security
Category: Standards Track T. Clancy
ISSN: 2070-1721 Virginia Tech
K. Hoeper
Motorola Solutions, Inc.
July 2012
Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
拡張認証プロトコル（EAP）メソッドのチャネルバインディングサポート
Abstract
概要
This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem.
このドキュメントでは、拡張認証プロトコル（EAP）メソッドのチャネルバインディングを実装して、「嘘のネットワークアクセスサービス（NAS）」の問題と「嘘のプロバイダー」の問題に対処する方法を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6677.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6677で入手できます。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Types of EAP Channel Bindings . . . . . . . . . . . . . . 8
4.2. Channel Bindings in the Secure Association Protocol . . . 9
4.3. Channel-Binding Scope . . . . . . . . . . . . . . . . . . 10
5. Channel-Binding Process . . . . . . . . . . . . . . . . . . . 12
5.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 12
5.2. Channel-Binding Consistency Check . . . . . . . . . . . . 14
5.3. EAP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Channel-Binding Codes . . . . . . . . . . . . . . . . 17
5.3.2. Namespace Identifiers . . . . . . . . . . . . . . . . 17
5.3.3. RADIUS Namespace . . . . . . . . . . . . . . . . . . . 18
6. System Requirements . . . . . . . . . . . . . . . . . . . . . 18
6.1. General Transport Protocol Requirements . . . . . . . . . 18
6.2. EAP Method Requirements . . . . . . . . . . . . . . . . . 19
7. Channel-Binding TLV . . . . . . . . . . . . . . . . . . . . . 19
7.1. Requirements for Lower-Layer Bindings . . . . . . . . . . 19
7.2. EAP Lower-Layer Attribute . . . . . . . . . . . . . . . . 20
8. AAA-Layer Bindings . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Consequences of Trust Violation . . . . . . . . . . . . . 23
9.3. Bid-Down Attacks . . . . . . . . . . . . . . . . . . . . . 24
9.4. Privacy Violations . . . . . . . . . . . . . . . . . . . . 24
10. Operations and Management Considerations . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. EAP Lower Layers Registry . . . . . . . . . . . . . . . . 26
11.2. RADIUS Registration . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Attacks Prevented by Channel Bindings . . . . . . . . 29
A.1. Enterprise Subnetwork Masquerading . . . . . . . . . . . . 29
A.2. Forced Roaming . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Downgrading Attacks . . . . . . . . . . . . . . . . . . . 30
A.4. Bogus Beacons in IEEE 802.11r . . . . . . . . . . . . . . 30
A.5. Forcing False Authorization in IEEE 802.11i . . . . . . . 30
The so-called "lying NAS" problem is a well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when used in pass-through authenticator mode. Here, a Network Access Server (NAS), or pass-through authenticator, may represent one set of information (e.g., network identity, capabilities, configuration, etc) to the backend Authentication, Authorization, and Accounting (AAA) infrastructure, while representing contrary information to EAP peers. Another possibility is that the same false information could be provided to both the EAP peer and EAP server by the NAS. A "lying" entity can also be located anywhere on the AAA path between the NAS and the EAP server.
いわゆる「横になっているNAS」の問題は、パススルー認証モードで使用した場合の現在の拡張認証プロトコル（EAP）アーキテクチャ[RFC3748]で十分に文書化された問題です。ここで、ネットワークアクセスサーバー（NAS）、またはパススルー認証システムは、バックエンドの認証、承認、およびアカウンティング（AAA）インフラストラクチャへの情報（ネットワークID、機能、構成など）の1つのセットを表す一方で、 EAPピアに反する情報。別の可能性として、NASがEAPピアとEAPサーバーの両方に同じ誤った情報を提供する可能性があります。 「横になっている」エンティティは、NASとEAPサーバー間のAAAパス上のどこにでも配置できます。
This problem results when the same credentials are used to access multiple services that differ in some interesting property. The EAP server learns which client credentials are in use. The client knows which EAP credentials are used, but cannot distinguish between servers that use those credentials. For methods that distinguish between client and server credentials, either using different server credentials for access to the different services or having client credentials with access to a disjoint set of services can potentially defend against the attack.
この問題は、同じ資格情報を使用して、いくつかの興味深いプロパティが異なる複数のサービスにアクセスすると発生します。 EAPサーバーは、使用されているクライアント資格情報を学習します。クライアントは使用されているEAP資格情報を認識していますが、それらの資格情報を使用するサーバーを区別できません。クライアントの資格情報とサーバーの資格情報を区別する方法の場合、異なるサービスへのアクセスに異なるサーバーの資格情報を使用するか、サービスのまとまりのないセットにアクセスできるクライアントの資格情報を使用すると、攻撃から防御できる可能性があります。
As a concrete example, consider an organization with two different IEEE 802.11 wireless networks. One is a relatively low-security network for accessing the web, while the other has access to valuable confidential information. An access point on the web network could act as a lying NAS, sending the Service Set Identifier (SSID) of the confidential network in its beacons. This access point could gain an advantage by doing so if it tricks clients that intend to connect to the confidential network to connect to it and disclose confidential information.
具体的な例として、2つの異なるIEEE 802.11ワイヤレスネットワークを持つ組織を考えてみましょう。 1つはWebにアクセスするための比較的セキュリティの低いネットワークで、もう1つは貴重な機密情報にアクセスできます。 Webネットワーク上のアクセスポイントは、横になっているNASとして機能し、ビーコンで機密ネットワークのサービスセット識別子（SSID）を送信できます。このアクセスポイントは、機密ネットワークに接続して機密情報を開示しようとするクライアントをだましてしまう場合に、そうすることで利点を得ることができます。
A similar problem can be observed in the context of roaming. Here, the lying entity is located in a visited service provider network, e.g., attempting to lure peers to connect to the network based on falsely advertised roaming rates. This is referred to as the "lying provider" problem in the remainder of this document. The lying entity's motivation often is financial; the entity may be paid whenever peers roam to its service. However, a lying entity in a provider network can also gain access to traffic that it might not otherwise see.
ローミングのコンテキストでも同様の問題が見られます。ここで、横たわっているエンティティは、訪問先のサービスプロバイダーネットワークに配置されています。たとえば、誤ってアドバタイズされたローミングレートに基づいて、ピアをネットワークに接続するように誘惑しています。これは、このドキュメントの残りの部分では「嘘つきプロバイダー」の問題と呼ばれます。嘘をつく実体の動機は、しばしば金銭的です。エンティティは、ピアがそのサービスにローミングするたびに支払われる可能性があります。ただし、プロバイダーネットワーク内にあるエンティティは、他の方法では見られない可能性があるトラフィックにアクセスすることもできます。
This document defines and implements EAP channel bindings to solve the "lying NAS" and the "lying provider" problems, using a process in which the EAP peer gives information about the characteristics of the service provided by the authenticator to the AAA server protected within the EAP method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator. "AAA Payloads" defined in [AAA-PAY] served as the starting point for the mechanism proposed in this specification to carry this information.
このドキュメントでは、EAPピアがAuthenticatorによって提供されるサービスの特性に関する情報を、AAAサーバー内で保護されているAAAサーバーに提供するプロセスを使用して、「嘘のNAS」と「嘘のプロバイダー」の問題を解決するEAPチャネルバインディングを定義および実装します。 EAPメソッド。これにより、サーバーは、オーセンティケータがピアに提供している情報を、このオーセンティケータから受信した情報や、このオーセンティケータについて格納されている情報と一致して検証できます。 [AAA-PAY]で定義されている「AAA Payloads」は、この情報でこの仕様で提案されているメカニズムの開始点として機能しました。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語が使用されています。これらの単語は、多くの場合大文字です。このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In an EAP authentication compliant with [RFC4017], the EAP peer and EAP server mutually authenticate each other, and derive keying material. However, when operating in pass-through mode, the EAP server can be far removed from the authenticator both in terms of network distance and number of entities who need to be trusted in order to establish trusted communication. A malicious or compromised authenticator may represent incorrect information about the network to the peer in an effort to affect its operation in some way. Additionally, while an authenticator may not be compromised, other compromised elements in the network (such as proxies) could provide false information to the authenticator that it could simply be relaying to EAP peers. Hence, the goal must be to ensure that the authenticator is providing correct information to the EAP peer during the initial network discovery, selection, and authentication.
[RFC4017]に準拠したEAP認証では、EAPピアとEAPサーバーが相互に認証を行い、キー情報を導出します。ただし、パススルーモードで動作している場合、EAPサーバーは、信頼できる通信を確立するために信頼する必要があるエンティティの数とネットワーク距離の両方の点で、認証システムから遠く離れている可能性があります。悪意のある、または侵害されたオーセンティケーターは、何らかの形でその動作に影響を与えようとして、ピアに対してネットワークに関する誤った情報を表す場合があります。さらに、オーセンティケータは危険にさらされない可能性がありますが、ネットワーク内の他の危険にさらされた要素（プロキシなど）は、単にEAPピアにリレーしているという誤った情報をオーセンティケータに提供する可能性があります。したがって、最初のネットワークの検出、選択、および認証中に、認証システムがEAPピアに正しい情報を提供していることを確認する必要があります。
There are two different types of networks to consider: enterprise networks and service provider networks. In enterprise networks, assuming a single administrative domain, it is feasible for an EAP server to have information about all the authenticators in the network. In service provider networks, global knowledge is infeasible due to indirection via roaming. When a peer is outside its home administrative domain, the goal is to ensure that the level of service received by the peer is consistent with the contractual agreement between the two service providers. The same EAP server may need to support both types of networks. For example an enterprise may have a roaming agreement permitting its users to use the networks of third-party service providers. In these situations, the EAP server may authenticate for an enterprise and provider network.
考慮すべきネットワークには、エンタープライズネットワークとサービスプロバイダーネットワークの2種類があります。エンタープライズネットワークでは、単一の管理ドメインを想定して、EAPサーバーがネットワーク内のすべての認証システムについての情報を持つことができます。サービスプロバイダーのネットワークでは、ローミングによる間接化のため、グローバルな知識は実現できません。ピアがホーム管理ドメインの外部にある場合の目標は、ピアが受け取るサービスのレベルが2つのサービスプロバイダー間の契約上の合意と一致することを確認することです。同じEAPサーバーが両方のタイプのネットワークをサポートする必要がある場合があります。たとえば、企業は、ユーザーがサードパーティのサービスプロバイダーのネットワークを使用することを許可するローミング契約を結んでいる場合があります。これらの状況では、EAPサーバーは企業およびプロバイダーのネットワークに対して認証を行う場合があります。
The following are example attacks possible by presenting false network information to peers.
以下は、ピアに偽のネットワーク情報を提示することによって可能になる攻撃の例です。
o Enterprise network: A corporate network may have multiple virtual LANs (VLANs) available throughout their campus network, and have IEEE 802.11 access points connected to each VLAN. Assume one VLAN connects users to the firewalled corporate network, while the other connects users to a public guest network. The corporate network is assumed to be free of adversarial elements, while the guest network is assumed to possibly have malicious elements. Access points on both VLANs are serviced by the same EAP server, but broadcast different SSIDs to differentiate. A compromised access point connected to the guest network but not the corporate network could advertise the SSID of the corporate network in an effort to lure peers to connect to a network with a false sense of security regarding their traffic. Conditions and further details of this attack can be found in the appendix.
o 企業ネットワーク：企業ネットワークでは、キャンパスネットワーク全体で利用可能な複数の仮想LAN（VLAN）があり、各VLANにIEEE 802.11アクセスポイントが接続されている場合があります。 1つのVLANがユーザーをファイアウォールで保護された企業ネットワークに接続し、もう1つのVLANがユーザーをパブリックゲストネットワークに接続するとします。企業ネットワークには敵対的な要素がないと想定されていますが、ゲストネットワークには悪意のある要素が存在する可能性があると想定されています。両方のVLAN上のアクセスポイントは同じEAPサーバーによってサービスされますが、区別するために異なるSSIDをブロードキャストします。ゲストネットワークには接続されているが企業ネットワークには接続されていないセキュリティ侵害されたアクセスポイントは、ピアに関するトラフィックを誤ったセキュリティでネットワークに接続するように仕向けるために、企業ネットワークのSSIDをアドバタイズする可能性があります。この攻撃の条件と詳細については、付録を参照してください。
o Enterprise network: The EAP Generic Security Service Application Program Interface (GSS-API) mechanism [GSS-API-EAP] mechanism provides a way to use EAP to authenticate to mail servers, instant messaging servers, and other non-network services. Without EAP channel binding, an attacker could trick the user into connecting to a relatively untrusted service instead of a relatively trusted service. For example, the instant messaging service could impersonate the mail server.
o エンタープライズネットワーク：EAP Generic Security Serviceアプリケーションプログラムインターフェイス（GSS-API）メカニズム[GSS-API-EAP]メカニズムは、EAPを使用してメールサーバー、インスタントメッセージングサーバー、およびその他の非ネットワークサービスを認証する方法を提供します。 EAPチャネルバインディングがないと、攻撃者はユーザーをだまして、比較的信頼できるサービスではなく、比較的信頼できないサービスに接続させることができます。たとえば、インスタントメッセージングサービスがメールサーバーを偽装する可能性があります。
o Service provider network: An EAP-enabled mobile phone provider could advertise very competitive flat rates but send per-minute rates to the home server, thus luring peers to connect to their network and overcharging them. In more elaborate attacks, peers can be tricked into roaming without their knowledge. For example, a mobile phone provider operating along a geopolitical boundary could boost their cell towers' transmission power and advertise the network identity of the neighboring country's indigenous provider. This would cause unknowing handsets to associate with an unintended operator, and consequently be subject to high roaming fees without realizing they had roamed off their home provider's network. These types of scenarios can be considered as the "lying provider" problem, because here the provider configures its NAS to broadcast false information. For the purpose of channel bindings as defined in this document, it does not matter which local entity (or entities) is "lying" in a service provider network (local NAS, local authentication server, and/or local proxies), because the only information received from the visited network that is verified by channel bindings is the information the home authentication server received from the last hop in the communication chain. In other words, channel bindings enable the detection of inconsistencies in the information from a visited network, but cannot enable the determination of which entity is lying. Naturally, channel bindings for EAP methods can only verify the endpoints; if desirable, intermediate hops need to be protected by the employed AAA protocol.
oサービスプロバイダーネットワーク：EAP対応の携帯電話プロバイダーは、非常に競争力のある定額料金をアドバタイズしますが、分単位のレートをホームサーバーに送信するため、ピアをネットワークに接続させ、過剰に課金する可能性があります。より複雑な攻撃では、ピアは知らないうちにだまされてローミングする可能性があります。たとえば、地政学的な境界に沿って事業を行っている携帯電話プロバイダーは、基地局の送信電力を増強し、近隣国の先住民プロバイダーのネットワークIDをアドバタイズできます。これにより、知らないハンドセットが意図しないオペレーターに関連付けられ、その結果、ホームプロバイダーのネットワークからローミングしたことに気付かずに、ローミング料金が高くなる可能性があります。これらのタイプのシナリオは、「嘘のプロバイダー」の問題と見なすことができます。これは、プロバイダーが誤った情報をブロードキャストするようにNASを構成するためです。このドキュメントで定義されているチャネルバインディングの目的では、サービスプロバイダーネットワーク（ローカルNAS、ローカル認証サーバー、ローカルプロキシ、あるいはその両方）で「ローカルエンティティ」が「横になっている」かどうかは関係ありません。訪問先ネットワークから受信したチャネルバインディングによって検証される情報は、ホーム認証サーバーが通信チェーンの最後のホップから受信した情報です。言い換えると、チャネルバインディングは、訪問先ネットワークからの情報の不整合の検出を可能にしますが、どのエンティティが嘘をついているかの決定を可能にすることはできません。当然、EAPメソッドのチャネルバインディングはエンドポイントのみを検証できます。必要に応じて、使用するAAAプロトコルで中間ホップを保護する必要があります。
o Enterprise and provider networks: In a situation where an enterprise has roaming agreements with providers, a compromised access point in a provider network could masquerade as the enterprise network in an attempt to gain confidential information. Today this could potentially be solved by using different credentials for internal and external access. Depending on the type of credential, this may introduce usability or man-in-the-middle security issues.
o エンタープライズネットワークとプロバイダーネットワーク：企業がプロバイダーとローミング契約を結んでいる状況では、プロバイダーネットワーク内の危険にさらされたアクセスポイントが、機密情報を入手しようとしてエンタープライズネットワークになりすます可能性があります。今日、これは内部と外部のアクセスに異なる資格情報を使用することで解決できる可能性があります。資格情報の種類によっては、これにより、ユーザビリティや中間者セキュリティの問題が発生する可能性があります。
To address these problems, a mechanism is required to validate unauthenticated information advertised by EAP authenticators.
これらの問題に対処するには、EAPオーセンティケーターによってアドバタイズされる非認証情報を検証するメカニズムが必要です。
EAP channel bindings seek to authenticate previously unauthenticated information provided by the authenticator to the EAP peer by allowing the peer and server to compare their perception of network properties in a secure channel.
EAPチャネルバインディングは、ピアとサーバーがセキュリティで保護されたチャネル内のネットワークプロパティの認識を比較できるようにすることで、認証システムによってEAPピアに提供された未認証の情報を認証しようとします。
It should be noted that the definition of EAP channel bindings differs somewhat from channel bindings documented in [RFC5056], which seek to securely bind together the endpoints of a multi-layer protocol, allowing lower layers to protect data from higher layers. Unlike [RFC5056], EAP channel bindings do not ensure the binding of different layers of a session; rather, they ensure the accuracy of the information advertised to an EAP peer by an authenticator acting as the pass-through device during an EAP execution. The term "channel bindings" was independently adopted for these two related concepts; by the time the conflict was discovered, a wide body of literature existed for each usage. EAP channel bindings could be used to provide [RFC5056] channel bindings. In particular, an inner EAP method could be bound to an outer method by including the [RFC5056] channel-binding data for the outer channel in the inner EAP method's channel bindings. Doing so would provide a facility similar to EAP cryptographic binding, except that a man-in-the-middle could not extract the inner method from the tunnel. This specification does not weigh the advantages of doing so nor specify how to do so; the example is provided only to illustrate how EAP channel binding and [RFC5056] channel binding overlap.
EAPチャネルバインディングの定義は、[RFC5056]で文書化されているチャネルバインディングとは多少異なり、マルチレイヤプロトコルのエンドポイントを安全にバインドして、下位層が上位層からデータを保護できるようにすることに注意してください。 [RFC5056]とは異なり、EAPチャネルバインディングは、セッションの異なるレイヤーのバインディングを保証しません。むしろ、それらは、EAP実行中にパススルーデバイスとして機能するオーセンティケーターによってEAPピアにアドバタイズされる情報の正確さを保証します。 「チャネルバインディング」という用語は、これら2つの関連する概念に対して独立して採用されました。紛争が発見されるまでに、使用法ごとに幅広い文献が存在していました。 EAPチャネルバインディングを使用して、[RFC5056]チャネルバインディングを提供できます。特に、内部EAPメソッドのチャネルバインディングに外部チャネルの[RFC5056]チャネルバインディングデータを含めることにより、内部EAPメソッドを外部メソッドにバインドできます。そうすることで、中間者がトンネルから内部メソッドを抽出できなかったことを除いて、EAP暗号バインディングと同様の機能が提供されます。この仕様は、そうすることの利点を比較したり、その方法を指定したりしません。この例は、EAPチャネルバインディングと[RFC5056]チャネルバインディングがどのようにオーバーラップするかを示すためにのみ提供されています。
There are two categories of approach to EAP channel bindings:
EAPチャネルバインディングへのアプローチには2つのカテゴリがあります。
o After keys have been derived during an EAP execution, the peer and server can, in an integrity-protected channel, exchange plaintext information about the network with each other and verify consistency and correctness.
o EAPの実行中にキーが導出された後、ピアとサーバーは、整合性が保護されたチャネルで、ネットワークに関するプレーンテキスト情報を相互に交換し、整合性と正確性を確認できます。
o The peer and server can both uniquely encode their respective view of the network information without exchanging it, resulting into an opaque blob that can be included directly into the derivation of EAP session keys.
o ピアとサーバーはどちらも、交換せずにネットワーク情報のそれぞれのビューを一意にエンコードできるため、EAPセッションキーの派生に直接含めることができる不透明なblobになります。
Both approaches are only applicable to key-deriving EAP methods and both have advantages and disadvantages. Various hybrid approaches are also possible. Advantages of exchanging plaintext information include:
どちらのアプローチも、キー派生EAPメソッドにのみ適用可能であり、どちらにも長所と短所があります。さまざまなハイブリッドアプローチも可能です。平文情報を交換する利点は次のとおりです。
o It allows for policy-based comparisons of network properties, rather than requiring precise matches for every field, which achieves a policy-defined consistency, rather than bitwise equality. This allows network operators to define which properties are important and even verifiable in their network.
o すべてのフィールドで正確な一致を要求するのではなく、ネットワークプロパティのポリシーベースの比較が可能になり、ビット単位の同等性ではなく、ポリシーで定義された一貫性が実現されます。これにより、ネットワークオペレーターは、ネットワーク内で重要かつ検証可能なプロパティを定義できます。
o EAP methods that support extensible, integrity-protected channels can easily include support for exchanging this network information. In contrast, direct inclusion into the key derivation would require more extensive revisions to existing EAP methods or a wrapper EAP method.
o 完全性が保護された拡張可能なチャネルをサポートするEAPメソッドには、このネットワーク情報の交換のサポートを簡単に含めることができます。対照的に、キーの派生に直接含めるには、既存のEAPメソッドまたはラッパーEAPメソッドをさらに広範囲に修正する必要があります。
o Given it doesn't affect the key derivation, this approach facilitates debugging, incremental deployment, backward compatibility, and a logging mode in which verification results are recorded but do not have an effect on the remainder of the EAP execution. The exact use of the verification results can be subject to the network policy. Additionally, consistent information canonicalization and formatting for the key derivation approach would likely cause significant deployment problems.
o キーの派生に影響を与えないことを考えると、このアプローチは、デバッグ、増分展開、下位互換性、および検証結果が記録されるが、残りのEAP実行には影響しないロギングモードを容易にします。検証結果の正確な使用は、ネットワークポリシーの対象となる場合があります。さらに、主要な派生アプローチの一貫した情報の正規化とフォーマットは、重大な展開の問題を引き起こす可能性があります。
The following are advantages of directly including channel-binding information in the key derivation:
以下は、キーの派生にチャネルバインディング情報を直接含めることの利点です。
o EAP methods not supporting extensible, integrity-protected channels could still be supported, either by revising their key derivation, revising EAP, or wrapping them in a universal method that supports channel binding.
o 拡張可能で整合性が保護されたチャネルをサポートしないEAPメソッドは、キーの派生を修正するか、EAPを修正するか、またはチャネルバインディングをサポートする汎用的なメソッドでそれらをラップすることによって、引き続きサポートできます。
o It can guarantee proper channel information, since subsequent communication would be impossible if differences in channel information yield different session keys on the EAP peer and server.
o チャネル情報の違いによりEAPピアとサーバーで異なるセッションキーが生成されると、その後の通信が不可能になるため、適切なチャネル情報を保証できます。
This document describes channel bindings performed by transporting channel-binding information as part of an integrity-protected exchange within an EAP method. Alternatively, some future document could specify a mechanism for transporting channel bindings within the lower layer's secure association protocol. Such a specification would need to describe how channel bindings are exchanged over the lower-layer protocol between the peer and authenticator. In addition, since the EAP exchange concludes before the secure association protocol begins, a mechanism for transporting the channel bindings from the authenticator to the EAP server needs to be specified. A mechanism for transporting a protected result from the EAP server, through the authenticator, back to the peer needs to be specified.
このドキュメントでは、EAPメソッド内の整合性保護された交換の一部としてチャネルバインディング情報を転送することによって実行されるチャネルバインディングについて説明します。あるいは、将来のいくつかのドキュメントでは、下位層のセキュアアソシエーションプロトコル内でチャネルバインディングを転送するメカニズムを指定する可能性があります。このような仕様では、ピアとオーセンティケータの間で下位層プロトコルを介してチャネルバインディングを交換する方法を説明する必要があります。さらに、セキュアなアソシエーションプロトコルが開始する前にEAP交換が完了するため、オーセンティケーターからEAPサーバーにチャネルバインディングを転送するメカニズムを指定する必要があります。保護された結果をEAPサーバーから認証システムを介してピアに転送するメカニズムを指定する必要があります。
The channel bindings MUST be transported with integrity protection based on a key known only to the peer and EAP server. The channel bindings SHOULD be confidentiality protected using a key known only to the peer and EAP server. For the system to function, the EAP server or AAA server needs access to the channel-binding information from the peer as well as the AAA attributes and a local database described later in this document.
チャネルバインディングは、ピアとEAPサーバーだけが知っているキーに基づいて整合性保護を使用して転送する必要があります。チャネルバインディングは、ピアとEAPサーバーだけが知っているキーを使用して機密性を保護する必要があります（SHOULD）。システムが機能するには、EAPサーバーまたはAAAサーバーが、ピアからのチャネルバインディング情報、およびこのドキュメントで後述するAAA属性とローカルデータベースにアクセスできる必要があります。
The primary advantage of sending channel bindings as part of the secure association protocol is that EAP methods need not be changed. The disadvantage is that a new AAA exchange is required, and secure association protocols need to be changed. As the results of the secure association protocol change, every NAS needs to be upgraded to support channel bindings within the secure association protocol.
セキュアアソシエーションプロトコルの一部としてチャネルバインディングを送信する主な利点は、EAPメソッドを変更する必要がないことです。欠点は、新しいAAA交換が必要であり、安全な関連付けプロトコルを変更する必要があることです。セキュアアソシエーションプロトコルの変更の結果として、セキュアアソシエーションプロトコル内のチャネルバインディングをサポートするには、すべてのNASをアップグレードする必要があります。
For many deployments, changing all the NASes is expensive, and adding channel-binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower-layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. Sending channel bindings in the secure association protocol can work even with the EAP Re-authentication Protocol (ERP) [RFC5296] in which previously established EAP key material is used for the secure association protocol without carrying out any EAP method during re-authentication.
多くの導入では、すべてのNASの変更に費用がかかり、導入の目標を満たすために十分なEAPメソッドにチャネルバインディングサポートを追加する方が安上がりです。ただし、新しい機器の導入、特に新しい下位層テクノロジーの導入では、NASを変更する方がEAP方法を変更するよりも費用がかからない場合があります。特に、このような展開で多数のEAPメソッドをサポートする必要がある場合、セキュアアソシエーションプロトコルでチャネルバインディングを送信することは意味があります。セキュアアソシエーションプロトコルでのチャネルバインディングの送信は、再認証中にEAPメソッドを実行せずに、以前に確立されたEAPキーマテリアルがセキュアアソシエーションプロトコルに使用されるEAP再認証プロトコル（ERP）[RFC5296]でも機能します。
If channel bindings using a secure association protocol are specified, semantics as well as the set of information that peers exchange can be shared with the mechanism described in this document.
セキュアアソシエーションプロトコルを使用したチャネルバインディングが指定されている場合、ピアが交換するセマンティクスと情報のセットは、このドキュメントで説明されているメカニズムと共有できます。
The scope of EAP channel bindings differs somewhat depending on the type of deployment in which they are being used. In enterprise networks, they can be used to authenticate very specific properties of the authenticator (e.g., Medium Access Control (MAC) address, supported link types and data rates, etc.), while in service provider networks they can generally only authenticate broader information about a roaming partner's network (e.g., network name, roaming information, link security requirements, etc.). The reason for the difference has to do with the amount of information about the authenticator and/or network to which the peer is connected the home EAP server is expected to have access to. In roaming cases, the home server is likely to only have access to information contained in their roaming agreements.
EAPチャネルバインディングのスコープは、それらが使用されている展開の種類によって多少異なります。エンタープライズネットワークでは、オーセンティケーターの非常に特定のプロパティ（Medium Access Control（MAC）アドレス、サポートされているリンクタイプ、データレートなど）を認証するために使用できますが、サービスプロバイダーネットワークでは、通常、より広範な情報しか認証できません。ローミングパートナーのネットワークについて（ネットワーク名、ローミング情報、リンクセキュリティ要件など）。違いの理由は、ピアが接続されているオーセンティケーターやネットワークに関する情報量に関係があり、ホームEAPサーバーがアクセスできると予想されます。ローミングの場合、ホームサーバーは、ローミング契約に含まれている情報にのみアクセスできます。
With any multi-hop AAA infrastructure, many of the NAS-specific AAA attributes are obscured by the AAA proxy that's decrypting, reframing, and retransmitting the underlying AAA messages. Especially service provider networks are affected by this, and the AAA information received from the last hop may not contain much verifiable information after transformations performed by AAA proxies. For example, information carried in AAA attributes such as the NAS IP address may have been lost in transition and thus are not known to the EAP server. Even worse, information may still be available but be useless, for example, representing the identity of a device on a private network or a middlebox. This affects the ability of the EAP server to verify specific NAS properties. However, often verification of the MAC or IP address of the NAS is not useful for improving the overall security posture of a network. More often, the best approach is to make policy decisions about services being offered to peers. For example, in an IEEE 802.11 network, the EAP server may wish to ensure that peers connecting to the corporate intranet are using secure link-layer encryption, while link-layer security requirements for peers connecting to the guest network could be less stringent. These types of policy decisions can be made without knowing or being able to verify the IP address of the NAS through which the peer is connecting.
マルチホップAAAインフラストラクチャでは、NAS固有のAAA属性の多くは、基盤となるAAAメッセージを復号化、再フレーム化、再送信するAAAプロキシによって隠されます。特にサービスプロバイダーネットワークはこの影響を受け、最終ホップから受信したAAA情報には、AAAプロキシによって変換が実行された後、検証可能な情報が多く含まれない場合があります。たとえば、NAS IPアドレスなどのAAA属性で伝達される情報は、移行中に失われた可能性があるため、EAPサーバーには認識されません。さらに悪いことに、情報はまだ利用可能であるかもしれませんが、たとえば、プライベートネットワークまたはミドルボックス上のデバイスのIDを表すために役に立たない場合があります。これは、特定のNASプロパティを確認するEAPサーバーの機能に影響します。ただし、NASのMACアドレスまたはIPアドレスの検証は、ネットワークの全体的なセキュリティポスチャを改善するのに役立ちません。多くの場合、最良のアプローチは、ピアに提供されるサービスに関するポリシー決定を行うことです。たとえば、IEEE 802.11ネットワークでは、EAPサーバーは、企業のイントラネットに接続するピアが安全なリンク層暗号化を使用していることを確認したい場合がありますが、ゲストネットワークに接続するピアのリンク層セキュリティ要件はそれほど厳しくありません。これらのタイプのポリシー決定は、ピアが接続しているNASのIPアドレスを知らない、または確認できない場合に行うことができます。
The properties of the network that the peer wishes to validate depend on the specific deployment. In a mobile phone network, peers generally don't care what the name of the network is, as long as they can make their phone call and are charged the expected amount for the call. However, in an enterprise network, the administrators of a peer may be more concerned with specifics of where their network traffic is being routed and what VLAN is in use. To establish policies surrounding these requirements, administrators would capture some attribute such as SSID to describe the properties of the network they care about. Channel bindings could validate the SSID. The administrator would need to make sure that the network guarantees that when an authenticator trusted by the AAA infrastructure to offer a particular SSID to clients does offer this SSID, that network has the intended properties. Generally, it is not possible for channel bindings to detect lying NAS behavior when the NAS is authorized to claim a particular service. That is, if the same physical authenticator is permitted to advertise two networks, the AAA infrastructure is unlikely to be able to determine when this authenticator lies.
ピアが検証するネットワークのプロパティは、特定の展開によって異なります。携帯電話ネットワークでは、ピアは通常、電話をかけることができ、予想される通話料金が請求される限り、ネットワークの名前が何であるかを気にしません。ただし、エンタープライズネットワークでは、ピアの管理者は、ネットワークトラフィックがルーティングされている場所や使用されているVLANの詳細に関心を持つ場合があります。これらの要件を取り巻くポリシーを確立するために、管理者はSSIDなどの属性をキャプチャして、関心のあるネットワークのプロパティを記述します。チャネルバインディングはSSIDを検証できます。管理者は、特定のSSIDをクライアントに提供するためにAAAインフラストラクチャによって信頼されたオーセンティケーターがこのSSIDを提供する場合、そのネットワークが意図したプロパティを持つことをネットワークが保証することを確認する必要があります。一般に、NASが特定のサービスを要求することを許可されている場合、チャネルバインディングが横になっているNASの動作を検出することはできません。つまり、同じ物理オーセンティケータが2つのネットワークをアドバタイズすることが許可されている場合、AAAインフラストラクチャは、このオーセンティケータがいつ存在するかを判別できない可能性があります。
As discussed in the next section, some of the most important information to verify cannot come from AAA attributes but instead comes from local configuration. For example, in the mobile phone case, the expected roaming rate cannot come from the roaming provider without being verified against the contract between the two providers. Similarly, in an enterprise, the SSID that a particular access point is expected to advertise comes from configuration rather than an AAA exchange (which can be confirmed with channel binding).
次のセクションで説明するように、確認する最も重要な情報の一部は、AAA属性から取得することはできませんが、代わりにローカル設定から取得します。たとえば、携帯電話の場合、予想されるローミングレートは、2つのプロバイダー間の契約に対して検証されない限り、ローミングプロバイダーから取得することはできません。同様に、企業では、特定のアクセスポイントがアドバタイズすると予想されるSSIDは、AAA交換（チャネルバインディングで確認できます）ではなく、設定から取得されます。
The peer and authenticator do not initially have a basis for trust. The peer has a credential with the EAP server that forms a basis for trust. The EAP server and authenticator have a potentially indirect trust path using the AAA infrastructure. Channel binding leverages the trust between the peer and EAP server to build trust in certain attributes between the peer and authenticator.
ピアとオーセンティケータには、最初は信頼の基盤がありません。ピアは、信頼の基礎を形成するEAPサーバーの資格情報を持っています。 EAPサーバーとオーセンティケーターには、AAAインフラストラクチャを使用して、潜在的に間接的な信頼パスがあります。チャネルバインディングは、ピアとEAPサーバー間の信頼を活用して、ピアと認証システム間の特定の属性の信頼を構築します。
Channel bindings can be important for forming areas of trust, especially when provider networks are involved, and exact information is not available to the EAP server. Without channel bindings, all entities in the system need to be held to the standards of the most trusted entity that could be accessed using the EAP credential. Otherwise, a less trusted entity can impersonate a more trusted entity. However when channel bindings are used, the EAP server can use information supplied by the peer, AAA protocols and local database to distinguish less trusted entities from more trusted entities. One possible deployment involves being able to verify a number of characteristics about relatively trusted entities while for other entities simply verifying that they are less trusted.
チャネルバインディングは、特にプロバイダーネットワークが関係し、正確な情報がEAPサーバーで利用できない場合に、信頼の領域を形成するために重要になる可能性があります。チャネルバインディングがない場合、システム内のすべてのエンティティは、EAP資格情報を使用してアクセスできる最も信頼できるエンティティの標準に準拠する必要があります。それ以外の場合は、信頼性の低いエンティティが信頼性の高いエンティティになりすますことができます。ただし、チャネルバインディングが使用されている場合、EAPサーバーは、ピア、AAAプロトコル、およびローカルデータベースによって提供される情報を使用して、信頼性の低いエンティティと信頼性の高いエンティティを区別できます。考えられる1つの展開では、比較的信頼できるエンティティに関するいくつかの特性を検証できる一方で、他のエンティティについては、それらの信頼性が低いことを確認するだけです。
Any deployment of channel bindings should take into consideration both what information the EAP server is likely to know or have access to, and what type of network information the peer would want and need authenticated.
チャネルバインディングの展開では、EAPサーバーが認識またはアクセスする可能性のある情報と、ピアが必要とし、認証が必要なネットワーク情報の種類の両方を考慮する必要があります。
This section defines the process for verifying channel-binding information during an EAP authentication. The protocol uses the approach where plaintext data is exchanged, since it allows channel bindings to be used more flexibly in varied deployment models (see Section 4.1). In the first subsection, the general communication infrastructure is outlined, the messages used for channel-binding verifications are specified, and the protocol flows are defined. The second subsection explores the difficulties of checking the different pieces of information that are exchanged during the channel-binding protocol for consistency. The third subsection describes the information carried in the EAP exchange.
このセクションでは、EAP認証中にチャネルバインディング情報を確認するプロセスを定義します。プロトコルは、プレーンテキストデータが交換されるアプローチを使用します。これにより、チャネルバインディングをさまざまな展開モデルでより柔軟に使用できるようになります（セクション4.1を参照）。最初のサブセクションでは、一般的な通信インフラストラクチャの概要を説明し、チャネルバインディング検証に使用されるメッセージを指定し、プロトコルフローを定義します。 2番目のサブセクションでは、チャネルバインディングプロトコル中に交換されるさまざまな情報の整合性をチェックする難しさについて説明します。 3番目のサブセクションでは、EAP交換で伝達される情報について説明します。
Channel bindings are always provided between two communication endpoints (here, the EAP peer and the EAP server), who communicate through an authenticator typically in pass-through mode. Specifications treat the AAA server and EAP server as distinct entities. However, there is no standardized protocol for the AAA server and EAP server to communicate with each other. For the channel-binding protocol presented in this document to work, the EAP server needs to be able to access information from the AAA server that is utilized during the EAP session (i2 below) and a local database. For example, the EAP server and the local database can be co-located with the AAA server, as illustrated in Figure 1. An alternate architecture would be to provide a mechanism for the EAP server to inform the AAA server what channel-binding attributes were supplied and the AAA server to inform the EAP server about what channel-binding attributes it considered when making its decision.
チャネルバインディングは常に、通常はパススルーモードのオーセンティケーターを介して通信する2つの通信エンドポイント（ここでは、EAPピアとEAPサーバー）間で提供されます。仕様では、AAAサーバーとEAPサーバーを別個のエンティティとして扱います。ただし、AAAサーバーとEAPサーバーが相互に通信するための標準化されたプロトコルはありません。このドキュメントに記載されているチャネルバインディングプロトコルが機能するためには、EAPサーバーは、EAPセッション中に使用されるAAAサーバー（以下のi2）およびローカルデータベースからの情報にアクセスできる必要があります。たとえば、図1に示すように、EAPサーバーとローカルデータベースをAAAサーバーと同じ場所に配置できます。代替のアーキテクチャは、EAPサーバーがAAAサーバーにチャネルバインディング属性を通知するメカニズムを提供することです。提供され、AAAサーバーは、決定を行うときに考慮したチャネルバインディング属性についてEAPサーバーに通知します。
+ -------------------------+
-------- ------------- | ---------- ______ |
|EAP peer|<---->|Authenticator|<--> | |EAP Server|___(______) |
-------- ------------- | ---------- | DB | |
. . |AAA (______) |
. i1 . +--------------------------+
.<----------------. i2 . .
. .------------> .
. i1 .
.-------------------------------------->.
. CB_success/failure(i1, i2,info) .
.<--------------------------------------.
Figure 1: Overview of Channel-Binding Protocol
図1：チャネルバインディングプロトコルの概要
During network advertisement, selection, and authentication, the authenticator presents unauthenticated information, labeled i1, about the network to the peer. Message i1 could include an authenticator identifier and the identity of the network it represents, in addition to advertised network information such as offered services and roaming information. Information (such as the type of media in use) may be communicated implicitly in i1. As there is no established trust relationship between the peer and authenticator, there is no way for the peer to validate this information.
ネットワークアドバタイズ、選択、および認証中に、オーセンティケータは、i1というラベルの付いた認証されていない情報をネットワークについてピアに提示します。メッセージi1には、提供されたサービスやローミング情報などのアドバタイズされたネットワーク情報に加えて、認証識別子とそれが表すネットワークのIDを含めることができます。情報（使用中のメディアのタイプなど）は、i1で暗黙的に通信できます。ピアとオーセンティケータの間に確立された信頼関係がないため、ピアがこの情報を検証する方法はありません。
Additionally, during the transaction the authenticator presents a number of information properties in the form of AAA attributes about itself and the current request. These AAA attributes may or may not contain accurate information. This information is labeled i2. Message i2 is the information the AAA server receives from the last hop in the AAA proxy chain which is not necessarily the authenticator.
さらに、トランザクション中に、オーセンティケーターは自身と現在のリクエストに関するAAA属性の形式でいくつかの情報プロパティを提示します。これらのAAA属性には、正確な情報が含まれる場合と含まれない場合があります。この情報にはi2というラベルが付いています。メッセージi2は、AAAサーバーがAAAプロキシチェーンの最後のホップから受信する情報であり、必ずしも認証システムではありません。
AAA hops between the authenticator and AAA server can validate some of i2. Whether the AAA server will be able to rely on this depends significantly on the business relationship executed with these proxies and on the structure of the AAA network.
オーセンティケーターとAAAサーバー間のAAAホップは、一部のi2を検証できます。 AAAサーバーがこれに依存できるかどうかは、これらのプロキシで実行されるビジネス関係とAAAネットワークの構造に大きく依存します。
The local database is perhaps the most important part of this system. In order for the EAP server or AAA server to know whether i1 and i2 are correct, they need access to trustworthy information, since an authenticator could include false information in both i1 and i2. Additional reasons why such a database is necessary for channel bindings to work are discussed in the next subsection. The information contained within the database could involve wildcards. For example, this could be used to check whether IEEE 802.11 access points on a particular IP subnet all use a specific SSID. The exact IP address is immaterial, provided it is on the correct subnet.
ローカルデータベースは、おそらくこのシステムの最も重要な部分です。 EAPサーバーまたはAAAサーバーがi1とi2が正しいかどうかを知るには、オーセンティケーターがi1とi2の両方に誤った情報を含める可能性があるため、信頼できる情報にアクセスする必要があります。チャネルバインディングが機能するためにこのようなデータベースが必要になるその他の理由については、次のサブセクションで説明します。データベース内に含まれる情報には、ワイルドカードが含まれる場合があります。たとえば、これを使用して、特定のIPサブネット上のIEEE 802.11アクセスポイントがすべて特定のSSIDを使用しているかどうかを確認できます。正確なIPアドレスは、正しいサブネット上にある限り重要ではありません。
During an EAP method execution with channel bindings, the peer sends i1 to the EAP server using the mechanism described in Section 5.3. The EAP server verifies the consistency of i1 provided by the peer, i2 provided by the authenticator, and the information in the local database. Upon the check, the EAP server sends a message to the peer indicating whether the channel-binding validation check succeeded or failed and includes the attributes that were used in the check. The message flow is illustrated in Figure 1.
チャネルバインディングを使用したEAPメソッドの実行中、ピアは、セクション5.3で説明されているメカニズムを使用してi1をEAPサーバーに送信します。 EAPサーバーは、ピアから提供されたi1、オーセンティケーターから提供されたi2、およびローカルデータベースの情報の整合性を検証します。チェック時に、EAPサーバーは、チャネルバインディング検証チェックが成功したか失敗したかを示すメッセージをピアに送信し、チェックで使用された属性が含まれます。メッセージフローを図1に示します。
Above, the EAP server is described as performing the channel-binding validation. In most deployments, this will be a necessary implementation constraint. The EAP exchange needs to include an indication of channel-binding success or failure. Most existing implementations do not have a way to have an exchange between the EAP server and another AAA entity during the EAP server's processing of a single EAP message. However, another AAA entity can provide information to the EAP server to make its decision.
上記では、EAPサーバーはチャネルバインディング検証を実行するものとして説明されています。ほとんどの展開では、これが必要な実装の制約になります。 EAP交換には、チャネルバインディングの成功または失敗の表示を含める必要があります。既存のほとんどの実装では、EAPサーバーによる単一のEAPメッセージの処理中に、EAPサーバーと別のAAAエンティティの間で交換を行う方法がありません。ただし、別のAAAエンティティがEAPサーバーに情報を提供して、その決定を行うことができます。
If the compliance of i1 or i2 information with the authoritative policy source is mandatory and a consistency check failed, then after sending a protected indication of failed consistency, the EAP server MUST send an EAP-Failure message to terminate the session. If the EAP server is otherwise configured, it MUST allow the EAP session to complete normally and leave the decision about network access up to the peer's policy. If i1 or i2 does not comply with policy, the EAP server MUST NOT list information that failed to comply in the set of information used to perform channel binding. In this case, the EAP server SHOULD indicate channel-binding failure; this requirement may be upgraded to a MUST in the future.
信頼できるポリシーソースによるi1またはi2情報のコンプライアンスが必須であり、整合性チェックに失敗した場合、EAPサーバーは、整合性の失敗を示す保護された表示を送信した後、セッションを終了するためにEAP-Failureメッセージを送信する必要があります。 EAPサーバーが別の方法で構成されている場合は、EAPセッションが正常に完了し、ネットワークアクセスに関する決定をピアのポリシーに任せる必要があります。 i1またはi2がポリシーに準拠していない場合、EAPサーバーは、チャネルバインディングの実行に使用される一連の情報に準拠していない情報をリストに含めてはなりません（MUST NOT）。この場合、EAPサーバーはチャネルバインディングの失敗を示す必要があります（SHOULD）。この要件は将来、MUSTにアップグレードされる可能性があります。
The validation check that is the core of the channel-binding protocol described in the previous subsection consists of two parts in which the server checks whether:
前のサブセクションで説明したチャネルバインディングプロトコルのコアである検証チェックは、サーバーが次のことをチェックする2つの部分で構成されています。
1. the authenticator is lying to the peer, i.e., i1 contains false information, and
1. オーセンティケーターがピアに嘘をついている、つまりi1に誤った情報が含まれている
2. the authenticator or any entity on the AAA path to the AAA server provides false information in form of AAA attributes, i.e., i2 contains false information.
2. オーセンティケーターまたはAAAサーバーへのAAAパス上のエンティティは、AAA属性の形式で誤った情報を提供します。つまり、i2には誤った情報が含まれています。
These checks enable the EAP server to detect lying NASes or authenticators in enterprise networks and lying providers in service provider networks.
これらのチェックにより、EAPサーバーは、エンタープライズネットワークにあるNASまたはオーセンティケーターと、サービスプロバイダーネットワークにあるプロバイダーを検出できます。
Checking the consistency of i1 and i2 is nontrivial, as has been pointed out already in [HC07]. First, i1 can contain any type of information propagated by the authenticator, whereas i2 is restricted to information that can be carried in AAA attributes. Second, because the authenticator typically communicates over different link layers with the peer and the AAA infrastructure, different types of identifiers and addresses may have been presented to both communication endpoints. Whether these different identifiers and addresses belong to the same device cannot be directly checked by the EAP server or AAA server without additional information. Finally, i2 may be different from the original information sent by the authenticator because of en route processing or malicious modifications. As a result, in the service provider model, typically the i1 information available to the EAP server can only be verified against the last-hop portion of i2 or against values propagated by proxy servers. In addition, checking the consistency of i1 and i2 alone is insufficient because an authenticator could lie to both the peer and the EAP server, i.e., i1 and i2 may be consistent but both contain false information.
[HC07]ですでに指摘されているように、i1とi2の整合性のチェックは重要です。第1に、i1にはオーセンティケーターによって伝搬されるあらゆるタイプの情報を含めることができますが、i2はAAA属性で伝送できる情報に制限されます。第2に、オーセンティケーターは通常、異なるリンクレイヤーを介してピアおよびAAAインフラストラクチャと通信するため、異なるタイプの識別子とアドレスが両方の通信エンドポイントに提示されている可能性があります。これらの異なる識別子とアドレスが同じデバイスに属しているかどうかは、追加情報がないと、EAPサーバーまたはAAAサーバーで直接確認できません。最後に、i2は、途中の処理や悪意のある変更のために、認証システムによって送信された元の情報とは異なる場合があります。その結果、サービスプロバイダーモデルでは、通常、EAPサーバーで利用可能なi1情報は、i2の最終ホップ部分またはプロキシサーバーによって伝達された値に対してのみ検証できます。さらに、オーセンティケーターがピアとEAPサーバーの両方にある可能性があるため、i1とi2の整合性をチェックするだけでは不十分です。
A local database is required to leverage the above-mentioned shortcomings and support the consistency and validation checks. In particular, information stored for each NAS/authenticator (enterprise scenario) or each roaming partner (service provider scenario) enables a comparison of any information received in i1 with AAA attributes in i2 as well as additionally stored AAA attributes that might have been lost in transition. Furthermore, only such a database enables the EAP server and AAA server to check the received information against trusted information about the network including roaming agreements.
上記の欠点を活用し、整合性と検証のチェックをサポートするには、ローカルデータベースが必要です。特に、各NAS /オーセンティケーター（エンタープライズシナリオ）または各ローミングパートナー（サービスプロバイダーシナリオ）に保存された情報により、i1で受信した情報とi2のAAA属性を比較できます。遷移。さらに、このようなデータベースだけが、EAPサーバーとAAAサーバーが、ローミング契約を含むネットワークに関する信頼できる情報と照合して、受信した情報をチェックできるようにします。
Section 7 describes lower-layer-specific properties that can be exchanged as a part of i1. Section 8 describes specific AAA attributes that can be included and evaluated in i2. The EAP server reports back the results from the channel-binding validation check that compares the consistency of all the values with those in the local database. The challenges of setting up such a local database are discussed in Section 10.
セクション7では、i1の一部として交換できる下位層固有のプロパティについて説明します。セクション8では、i2に含めて評価できる特定のAAA属性について説明します。 EAPサーバーは、すべての値の整合性をローカルデータベースの値と比較するチャネルバインディング検証チェックの結果を報告します。このようなローカルデータベースの設定に関する課題については、セクション10で説明します。
EAP methods supporting channel binding consistent with this specification provide a mechanism for carrying channel-binding data from the peer to the EAP server and a channel-binding response from the EAP server to the peer. The specifics of this mechanism are dependent on the method, although the content of the channel-binding data and channel-binding response are defined by this section.
この仕様と一致するチャネルバインディングをサポートするEAPメソッドは、ピアからEAPサーバーにチャネルバインディングデータを伝送するメカニズムと、EAPサーバーからピアにチャネルバインディング応答を伝送するメカニズムを提供します。このメカニズムの詳細はメソッドによって異なりますが、チャネルバインディングデータとチャネルバインディング応答の内容はこのセクションで定義されています。
Typically the lower layer will communicate a set of attributes to the EAP implementation on the peer that should be part of channel binding. The EAP implementation may need to indicate to the lower layer that channel-binding information cannot be sent. Reasons for failing to send channel-binding information include an EAP method that does not support channel binding is selected, or channel-binding data is too big for the EAP method selected. Peers SHOULD provide appropriate policy controls to select channel binding or mandate its success.
通常、下位層は、チャネルバインディングの一部であるはずのピア上のEAP実装に一連の属性を伝達します。 EAP実装は、チャネルバインディング情報を送信できないことを下位層に示す必要がある場合があります。チャネルバインディング情報の送信に失敗する理由には、チャネルバインディングをサポートしないEAPメソッドが選択されている、または選択されたEAPメソッドに対してチャネルバインディングデータが大きすぎるなどがあります。ピアは、チャネルバインディングを選択するか、その成功を義務付ける適切なポリシー制御を提供する必要があります（SHOULD）。
The EAP server receives the channel-binding data and performs the validation. The EAP method provides a way to return a response; the channel-binding response uses the same basic format as the channel-binding data.
EAPサーバーはチャネルバインディングデータを受信し、検証を実行します。 EAPメソッドは、応答を返す方法を提供します。チャネルバインディング応答は、チャネルバインディングデータと同じ基本形式を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | NSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NS-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | NSID | NS-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Channel-Binding Encoding
図2：チャネルバインディングエンコーディング
Both the channel-binding data and response use the format illustrated in Figure 2. The protocol starts with a one-byte code; see Section 5.3.1. Then, for each type of attribute contained in the channel-binding data, the following information is encoded:
チャネルバインディングデータと応答は、図2に示す形式を使用します。プロトコルは1バイトのコードで始まります。セクション5.3.1を参照してください。次に、チャネルバインディングデータに含まれる属性のタイプごとに、次の情報がエンコードされます。
Length: Two octets of length in network byte order, indicating the length of the NS-Specific data. The NSID and length octets are not included.
長さ：ネットワークバイトオーダーの2オクテットの長さで、NS固有のデータの長さを示します。 NSIDと長さのオクテットは含まれません。
NSID: Namespace identifier. One octet describing the namespace from which the attributes are drawn. See Section 5.3.3 for a description of how to encode RADIUS attributes in channel-binding data and responses. RADIUS uses a namespace identifier of 1 .
NSID：名前空間識別子。属性が引き出される名前空間を説明する1つのオクテット。チャネルバインディングデータと応答でRADIUS属性をエンコードする方法については、セクション5.3.3を参照してください。 RADIUSは1の名前空間識別子を使用します。
NS-Specific: The encoding of the attributes in a manner specific to the type of attribute.
NS固有：属性のタイプに固有の方法での属性のエンコード。
A given NSID MUST NOT appear more than once in a channel-binding data or channel-binding response. Instead, all NS-Specific data for a particular NSID must occur inside one set of fields (NSID, Length, and NS-Specific). This set of fields may be repeated if multiple namespaces are included.
特定のNSIDは、チャネルバインディングデータまたはチャネルバインディング応答に複数回出現してはなりません（MUST NOT）。代わりに、特定のNSIDのすべてのNS固有のデータは、1組のフィールド（NSID、長さ、およびNS固有）の内部で発生する必要があります。複数の名前空間が含まれている場合、このフィールドのセットは繰り返される可能性があります。
In channel-binding data, the code is set to 1 (channel-binding data), and the full attributes and values that the peer wishes the EAP server to validate are included.
チャネルバインディングデータでは、コードは1（チャネルバインディングデータ）に設定され、ピアがEAPサーバーに検証を要求する完全な属性と値が含まれます。
In a channel-binding response, the server selects the code; see Section 5.3.1. For successful channel binding, the server returns code 2. The set of attributes that the EAP server returns depend on the code. For success, the server returns the attributes that were considered by the server in making the determination that channel bindings are successfully validated; attributes that the server is unable to check or that failed to validate against what is sent by the peer MUST NOT be returned in a success response. Generally, servers will not return a success response if any attributes were checked and failed to validate those specified by the peer. Special circumstances such as a new attribute being phased in at a server MAY require servers to return success when such an attribute fails to validate. The server returns the value supplied by the peer when returning an attribute in channel-binding responses.
チャネルバインディング応答では、サーバーがコードを選択します。セクション5.3.1を参照してください。チャネルバインディングが成功すると、サーバーはコード2を返します。EAPサーバーが返す属性のセットは、コードによって異なります。成功した場合、サーバーは、チャネルバインディングが正常に検証されたと判断する際にサーバーによって考慮された属性を返します。サーバーがチェックできない属性、またはピアが送信したものに対して検証に失敗した属性は、成功応答で返されてはなりません（MUST NOT）。一般に、ピアが指定した属性がチェックされ、検証に失敗した場合、サーバーは成功応答を返しません。新しい属性がサーバーで段階的に導入されるなどの特別な状況では、そのような属性が検証に失敗した場合、サーバーは成功を返す必要があります。サーバーは、チャネルバインディング応答で属性を返すときに、ピアから提供された値を返します。
For channel-binding failure (code 3), the server SHOULD include any attributes that were successfully validated. This code means that server policy indicates that the attributes sent by the client do not accurately describe the authenticator. Servers MAY include no attributes in this response; for example, if the server checks the attributes supplied by the peer and they fail to be consistent, it may send a response without attributes.
チャネルバインディングの失敗（コード3）の場合、サーバーは正常に検証されたすべての属性を含める必要があります（SHOULD）。このコードは、クライアントによって送信された属性がオーセンティケーターを正確に記述していないことをサーバーポリシーが示していることを意味します。サーバーは、この応答に属性を含めない場合があります。たとえば、サーバーがピアから提供された属性をチェックし、それらが整合性に失敗した場合、属性なしで応答を送信することがあります。
Peers MUST treat unknown codes as channel-binding failure. Peers MUST ignore differences between attribute values sent in the channel-binding data and those sent in the response. Peers and servers MUST ignore any attributes contained in a field with an unknown NSID. Peers MUST ignore any attributes in a response not present in the channel-binding data.
ピアは不明なコードをチャネルバインディングの失敗として扱う必要があります。ピアは、チャネルバインディングデータで送信される属性値と応答で送信される属性値の違いを無視する必要があります。ピアとサーバーは、NSIDが不明なフィールドに含まれる属性をすべて無視する必要があります。ピアは、チャネルバインディングデータに存在しない応答の属性を無視する必要があります。
+------+-----------------------------------+
| Code | Meaning |
+------+-----------------------------------+
| 1 | Channel-binding data from client |
| 2 | Channel-binding response: success |
| 3 | Channel-binding response: failure |
+------+-----------------------------------+
+-----+--------------------------+---------------+
| ID | Namespace | Reference |
+-----+--------------------------+---------------+
| 1 | RADIUS | Section 5.3.3 |
| 255 | Reserved for Private Use | |
+-----+--------------------------+---------------+
RADIUS attribute-value pairs (AVPs) are encoded with a one-octet attribute type followed by a one-octet length followed by the value of the RADIUS attribute being encoded. The length includes the type and length octets; the minimum legal length is 3. Attributes are concatenated to form the namespace-specific portion of the packet.
RADIUS属性と値のペア（AVP）は、1オクテットの属性タイプ、1オクテットの長さ、続いてエンコードされるRADIUS属性の値でエンコードされます。長さには、タイプと長さのオクテットが含まれます。最小の長さは3です。属性は連結されて、パケットの名前空間固有の部分を形成します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: RADIUS AVP Encoding
図3：RADIUS AVPエンコーディング
The full value of an attribute is included in the channel-binding data and response.
属性の完全な値は、チャネルバインディングデータと応答に含まれます。
This section defines requirements on components used to implement the channel-bindings protocol.
このセクションでは、チャネルバインディングプロトコルの実装に使用されるコンポーネントの要件を定義します。
The channel-binding protocol defined in this document must be transported after keying material has been derived between the EAP peer and server, and before the peer would suffer adverse affects from joining an adversarial network. This document describes a protocol for performing channel binding within EAP methods. As discussed in Section 4.2, an alternative approach for meeting this requirement is to perform channel bindings during the secure association protocol of the lower layer.
このドキュメントで定義されているチャネルバインディングプロトコルは、キーマテリアルがEAPピアとサーバー間で導出された後、ピアが敵対的なネットワークに参加することによる悪影響を受ける前に転送する必要があります。このドキュメントでは、EAPメソッド内でチャネルバインディングを実行するためのプロトコルについて説明します。セクション4.2で説明したように、この要件を満たすための代替アプローチは、下位層のセキュアアソシエーションプロトコル中にチャネルバインディングを実行することです。
The transport protocol for carrying channel-binding information MUST support end-to-end (i.e., between the EAP peer and server) message integrity protection to prevent the adversarial NAS or AAA device from manipulating the transported data. The transport protocol SHOULD provide confidentiality. The motivation for this is that the channel bindings could contain private information, including peer identities, which SHOULD be protected. If confidentiality cannot be provided, private information MUST NOT be sent as part of the channel-binding information.
チャネルバインディング情報を伝送するためのトランスポートプロトコルは、エンドツーエンド（つまり、EAPピアとサーバー間）のメッセージ整合性保護をサポートして、敵対的なNASまたはAAAデバイスがトランスポートされたデータを操作できないようにする必要があります。転送プロトコルは機密性を提供する必要があります。この動機は、チャネルバインディングに、保護されるべきであるピアIDを含むプライベート情報が含まれる可能性があることです。機密性を提供できない場合、個人情報をチャネルバインディング情報の一部として送信してはなりません。
Any transport needs to be careful not to exceed the MTU for its lower-layer medium. In particular, if channel-binding information is exchanged within protected EAP method channels, these methods may or may not support fragmentation. In order to work with all methods, the channel-binding messages must fit within the available payload. For example, if the EAP MTU is 1020 octets, and EAP - Generalized Pre-Shared Key (EAP-GPSK) is used as the authentication method, and maximal-length identities are used, a maximum of 384 octets is available for conveying channel-binding information. Other methods, such as EAP Tunneled Transport Layer Security (EAP-TTLS), support fragmentation and could carry significantly longer payloads.
トランスポートは、その下位層メディアのMTUを超えないように注意する必要があります。特に、チャネルバインディング情報が保護されたEAPメソッドチャネル内で交換される場合、これらのメソッドはフラグメンテーションをサポートする場合とサポートしない場合があります。すべてのメソッドを使用するには、チャネルバインディングメッセージが使用可能なペイロード内に収まる必要があります。たとえば、EAP MTUが1020オクテットで、認証方法としてEAP-Generalized Pre-Shared Key（EAP-GPSK）が使用されており、最大長のIDが使用されている場合、チャネルの伝達に最大384オクテットを使用できます。バインディング情報。 EAP Tunneled Transport Layer Security（EAP-TTLS）などの他の方法は、断片化をサポートし、著しく長いペイロードを運ぶ可能性があります。
When transporting data directly within an EAP method, the method MUST be able to carry integrity-protected data from the EAP peer to server and from EAP server to peer. EAP methods MUST exchange channel-binding data with the AAA subsystem hosting the EAP server. EAP methods MUST be able to import channel-binding data from the lower layer on the EAP peer.
EAPメソッド内で直接データを転送する場合、このメソッドは、整合性保護されたデータをEAPピアからサーバーへ、およびEAPサーバーからピアへ伝送できる必要があります。 EAPメソッドは、EAPサーバーをホストするAAAサブシステムとチャネルバインディングデータを交換する必要があります。 EAPメソッドは、EAPピアの下位層からチャネルバインディングデータをインポートできる必要があります。
This section defines some channel-binding TLVs. While message i1 is not limited to AAA attributes, for the sake of tangible attributes that are already in place, this section discusses AAA AVPs that are appropriate for carrying channel bindings (i.e., data from i1 in Section 5).
このセクションでは、いくつかのチャネルバインディングTLVを定義します。メッセージi1はAAA属性に限定されていませんが、すでに適用されている具体的な属性のために、このセクションではチャネルバインディング（セクション5のi1からのデータ）を運ぶのに適したAAA AVPについて説明します。
For any lower-layer protocol, network information of interest to the peer and server can be encapsulated in AVPs or other defined payload containers. The appropriate AVPs depend on the lower-layer protocol as well as on the network type (i.e., enterprise network or service provider network) and its application.
下位層のプロトコルの場合、ピアとサーバーにとって重要なネットワーク情報は、AVPまたは他の定義されたペイロードコンテナーにカプセル化できます。適切なAVPは、下位層のプロトコル、およびネットワークタイプ（つまり、エンタープライズネットワークまたはサービスプロバイダーネットワーク）とそのアプリケーションに依存します。
Lower-layer protocols MUST support EAP in order to support EAP channel bindings. These lower layers MUST support EAP methods that derive keying material, as otherwise no integrity-protected channel would be available to execute the channel-bindings protocol. Lower-layer protocols need not support traffic encryption, since this is independent of the authentication phase.
下位層プロトコルは、EAPチャネルバインディングをサポートするために、EAPをサポートする必要があります。これらの下位層は、キーイングマテリアルを導出するEAPメソッドをサポートしなければなりません。下位層のプロトコルは、認証フェーズとは独立しているため、トラフィックの暗号化をサポートする必要はありません。
The data conveyed within the AVP type MUST NOT conflict with the externally defined usage of the AVP. Additional TLV types MAY be defined for values that are not communicated within AAA attributes.
AVPタイプ内で伝達されるデータは、AVPの外部で定義された使用法と競合してはなりません。 AAA属性内で通信されない値に対して、追加のTLVタイプが定義される場合があります。
In general, lower layers will need to specify what information should be included in i1. Existing lower layers will probably require new documents to specify this information. Lower-layer specifications need to include sufficient information in i1 to uniquely identify which lower layer is involved. The preferred way to do this is to include the EAP-Lower-Layer attribute defined in the next section. This MUST be included in i1 unless an attribute specific to a particular lower layer is included in i1.
一般に、下位層はi1に含める情報を指定する必要があります。既存の下位層では、おそらくこの情報を指定するために新しいドキュメントが必要になります。下位層の仕様では、関連する下位層を一意に識別するために、i1に十分な情報を含める必要があります。これを行う好ましい方法は、次のセクションで定義するEAP-Lower-Layer属性を含めることです。これは、特定の下位層に固有の属性がi1に含まれていない限り、i1に含まれている必要があります。
A new RADIUS attribute is defined to carry information on which EAP lower layer is used for this EAP authentication. This attribute provides information relating to the lower layer over which EAP is transported. This attribute MAY be sent by the NAS to the RADIUS server in an Access-Request or an Accounting-Request packet. A summary of the EAP-Lower-Layer attribute format is shown below. The fields are transmitted from left to right.
このEAP認証にどのEAP下位層が使用されるかに関する情報を伝達するために、新しいRADIUS属性が定義されています。この属性は、EAPが転送される下位層に関する情報を提供します。この属性は、NASからAccess-RequestまたはAccounting-RequestパケットでRADIUSサーバーに送信される場合があります。 EAP-Lower-Layer属性形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code is 163, the length is 6, and the value is a 32-bit unsigned integer in network byte order. The value specifies the EAP lower layer in use. Values are taken from the IANA registry established in Section 11.1.
コードは163、長さは6、値はネットワークバイトオーダーの32ビット符号なし整数です。この値は、使用中のEAP下位層を指定します。値は、セクション11.1で確立されたIANAレジストリから取得されます。
This section discusses which AAA attributes in a AAA Access-Request message can and should be validated by a EAP server (i.e., data from i2 in Section 5). As noted before, this data can be manipulated by AAA proxies either to enable functionality (e.g., removing realm information after messages have been proxied) or to act maliciously (e.g., in the case of a lying provider). As such, this data cannot always be easily validated. However, as thorough of a validation as possible should be conducted in an effort to detect possible attacks.
このセクションでは、AAA Access-RequestメッセージのどのAAA属性をEAPサーバーで検証できるか、および検証する必要があるかについて説明します（つまり、セクション5のi2からのデータ）。前述のように、このデータはAAAプロキシによって操作されて、機能を有効にする（たとえば、メッセージがプロキシされた後にレルム情報を削除する）か、悪意を持って（たとえば、横になっているプロバイダーの場合）動作します。そのため、このデータは常に簡単に検証できるとは限りません。ただし、攻撃の可能性を検出するために、可能な限り徹底的な検証を行う必要があります。
NAS-IP-Address: This value is typically the IP address of the authenticator; however, in a proxied connection, it likely will not match the source IP address of an Access-Request. A consistency check MAY verify the subnet of the IP address was correct based on the last-hop proxy.
NAS-IP-Address：この値は通常、オーセンティケーターのIPアドレスです。ただし、プロキシ接続では、Access-Requestの送信元IPアドレスと一致しない可能性があります。一貫性チェックは、IPアドレスのサブネットがラストホッププロキシに基づいて正しいことを確認する場合があります。
NAS-IPv6-Address: This value is typically the IPv6 address of the authenticator; however, in a proxied connection, it likely will not match the source IPv6 address of an Access-Request. A consistency check MAY verify the subnet of the IPv6 address was correct based on the last-hop proxy.
NAS-IPv6-Address：この値は通常、オーセンティケーターのIPv6アドレスです。ただし、プロキシ接続では、Access-RequestのソースIPv6アドレスと一致しない可能性があります。一貫性チェックは、最終ホッププロキシに基づいて、IPv6アドレスのサブネットが正しいことを検証する場合があります。
NAS-Identifier: This is an identifier populated by the NAS to identify the NAS to the AAA server; it SHOULD be validated against the local database.
NAS-Identifier：これは、AAAサーバーに対してNASを識別するためにNASによって入力される識別子です。ローカルデータベースに対して検証する必要があります。
NAS-Port-Type: This specifies the underlying link technology. It SHOULD be validated against the value received from the peer in the information exchange and against a database of authorized link-layer technologies.
NAS-Port-Type：これは、基礎となるリンク技術を指定します。情報交換でピアから受信した値と、承認されたリンク層技術のデータベースに対して検証する必要があります。
This section discusses security considerations surrounding the use of EAP channel bindings.
このセクションでは、EAPチャネルバインディングの使用に関するセキュリティの考慮事項について説明します。
In the considered trust model, EAP peer and authentication server are honest, while the authenticator is maliciously sending false information to peer and/or server. In the model, the peer and server trust each other, which is not an unreasonable assumption, considering they already have a trust relationship. The following are the trust relationships:
考慮される信頼モデルでは、EAPピアと認証サーバーは正直ですが、オーセンティケーターは悪意のある偽の情報をピアやサーバーに送信しています。モデルでは、ピアとサーバーは相互に信頼していますが、すでに信頼関係があることを考えると、これは不当な仮定ではありません。信頼関係は次のとおりです。
o The server trusts that the channel-binding information received from the peer is the information that the peer received from the authenticator.
o サーバーは、ピアから受信したチャネルバインディング情報が、ピアがオーセンティケーターから受信した情報であることを信頼します。
o The peer trusts the channel-binding result received from the server.
o ピアは、サーバーから受信したチャネルバインディング結果を信頼します。
o The server trusts the information contained within its local database.
o サーバーは、ローカルデータベースに含まれる情報を信頼します。
In order to establish the first two trust relationships during an EAP execution, an EAP method MUST provide the following:
EAPの実行中に最初の2つの信頼関係を確立するために、EAPメソッドは以下を提供する必要があります。
o mutual authentication between peer and server
o ピアとサーバー間の相互認証
o derivation of keying material including a key for integrity protection of channel-binding messages known to the peer and EAP server but not the authenticator
o オーセンティケーターではなく、ピアとEAPサーバーに既知のチャネルバインディングメッセージの整合性保護のためのキーを含むキー情報の導出
o transmission of the channel-binding request from peer to server over an integrity-protected channel
o 整合性保護されたチャネルを介したピアからサーバーへのチャネルバインディング要求の送信
o transmission of the channel-binding result from server to peer over an integrity-protected channel
o 完全性で保護されたチャネルを介したサーバーからピアへのチャネルバインディング結果の送信
This trust model is a significant departure from the standard EAP model. In many EAP deployments today, attacks where one authenticator can impersonate another are not a significant concern because all authenticators provide the same service. A authenticator does not gain significant advantage by impersonating another authenticator. The use of EAP in situations where different authenticators provide different services may give an attacker who can impersonate a authenticator greater advantage. The system as a whole needs to be analyzed to evaluate cases where one authenticator may impersonate another and to evaluate the impact of this impersonation.
この信頼モデルは、標準のEAPモデルとは大きく異なります。今日の多くのEAP展開では、1つの認証システムが別の認証システムになりすますことができる攻撃は、すべての認証システムが同じサービスを提供するため、重要な問題ではありません。オーセンティケーターは、別のオーセンティケーターになりすますことによる大きな利点はありません。異なる認証システムが異なるサービスを提供する状況でEAPを使用すると、認証システムを偽装できる攻撃者に大きな利点を与える可能性があります。ある認証者が別の認証者になりすます可能性があるケースを評価し、このなりすましの影響を評価するには、システム全体を分析する必要があります。
One attractive implementation strategy for channel binding is to add channel-binding support to a tunnel method that can tunnel an inner EAP authentication. This way, channel binding can be achieved with any method that can act as an inner method even if that inner method does not have native channel-binding support. The requirement for mutual authentication and key derivation is at the layer of EAP that actually performs the channel binding. Tunnel methods sometimes use cryptographic binding, a process where a peer proves that the peer for the outer method is the same as the peer for an inner method to tie authentication at one layer together with an inner layer. Cryptographic binding does not always provide mutual authentication; its definition does not require the server to prove that the inner server and outer server are the same. Even when cryptographic binding does attempt to confirm that the inner and outer server are the same, the Master Session Key (MSK) from the inner method is typically used to protect the binding. An attacker such as an authenticator that wishes to subvert channel binding could establish an outer tunnel terminating at the authenticator. If the outer method tunnel terminates on the authenticator, the MSK is disclosed to the authenticator, which can typically attack cryptographic binding. If the authenticator controls cryptographic binding, then it typically controls the channel-binding parameters and results. If the channel-binding process is used to differentiate one authenticator from another, then the authenticator can claim to support services that it was not authorized to. This attack was not in scope for existing threat models for cryptographic binding because differentiated authenticators was not a consideration. Thus, existing cryptographic binding does not typically provide mutual authentication of the inner-method server required for channel binding. Other methods besides cryptographic binding are available to provide mutual authentication required by channel binding. As an example, if server certificates are validated and names checked, mutual authentication can be provided directly by the tunnel.
チャネルバインディングの魅力的な実装戦略の1つは、内部EAP認証をトンネリングできるトンネルメソッドにチャネルバインディングサポートを追加することです。この方法では、内部メソッドがネイティブのチャネルバインディングサポートを持たない場合でも、内部メソッドとして機能できる任意のメソッドでチャネルバインディングを実現できます。相互認証と鍵導出の要件は、実際にチャネルバインディングを実行するEAPの層にあります。トンネル方式では、暗号化バインディングを使用する場合があります。これは、ピアが外部メソッドのピアが内部メソッドのピアと同じであることを証明して、1つのレイヤーと内部レイヤーの認証を結び付けるプロセスです。暗号バインディングは常に相互認証を提供するわけではありません。その定義では、サーバーが内部サーバーと外部サーバーが同じであることを証明する必要はありません。暗号化バインディングが内部サーバーと外部サーバーが同じであることを確認しようとする場合でも、通常、内部メソッドのマスターセッションキー（MSK）を使用してバインディングを保護します。オーセンティケータなどの攻撃者がチャネルバインディングを破壊しようとすると、オーセンティケータで終端する外部トンネルが確立される可能性があります。外部メソッドトンネルがオーセンティケーターで終了する場合、MSKはオーセンティケーターに公開されます。オーセンティケーターは通常、暗号バインディングを攻撃できます。オーセンティケーターが暗号バインディングを制御する場合は、通常、チャネルバインディングパラメーターと結果を制御します。チャネルバインディングプロセスを使用して、ある認証システムを別の認証システムと区別する場合、認証システムは、認証されていないサービスをサポートすると主張できます。差別化されたオーセンティケーターは考慮されていなかったため、この攻撃は暗号化バインディングの既存の脅威モデルの対象ではありませんでした。したがって、既存の暗号バインディングは通常、チャネルバインディングに必要な内部方式サーバーの相互認証を提供しません。暗号バインディング以外の方法を使用して、チャネルバインディングで必要な相互認証を提供できます。例として、サーバー証明書が検証され、名前が確認される場合、トンネルによって相互認証を直接提供できます。
If any of the trust relationships listed in Section 9.1 are violated, channel binding cannot be provided. In other words, if mutual authentication with key establishment as part of the EAP method as well as protected database access are not provided, then achieving channel binding is not feasible.
セクション9.1に記載されている信頼関係のいずれかに違反すると、チャネルバインディングを提供できません。言い換えれば、EAP方式の一部としての鍵の確立を伴う相互認証と保護されたデータベースアクセスが提供されていない場合、チャネルバインディングを実現することはできません。
Dishonest peers can only manipulate the first message i1 of the channel-binding protocol. In this scenario, a peer sends i1' to the server. If i1' is invalid, the channel-binding validation will fail. On the other hand, if i1' passes the validation, either the original i1 was wrong and i1' corrected the problem, or both i1 and i1' constitute valid information. A peer could potentially gain an advantage in auditing or charging if both are valid and information from i1' is used for auditing or charging. Such peers can be detected by including the information in i2 and checking i1 against i2.
不正なピアは、チャネルバインディングプロトコルの最初のメッセージi1のみを操作できます。このシナリオでは、ピアがi1 'をサーバーに送信します。 i1 'が無効な場合、チャネルバインディングの検証は失敗します。一方、i1 'が検証に合格した場合、元のi1が間違っていてi1'が問題を修正したか、i1とi1 'の両方が有効な情報を構成しています。ピアは、両方が有効であり、i1 'からの情報が監査または課金に使用される場合、監査または課金で利点を得る可能性があります。このようなピアは、i2に情報を含め、i2に対してi1をチェックすることで検出できます。
If information from i1 does not validate, an EAP server cannot generally determine whether the authenticator advertised incorrect information or whether the peer is dishonest. This should be considered before using channel-binding validation failures to determine the reputation either of the peer or authenticator.
i1からの情報が検証されない場合、EAPサーバーは通常、オーセンティケーターが誤った情報をアドバタイズしたのか、ピアが不正であるのかを判別できません。これは、チャネルバインディング検証エラーを使用してピアまたはオーセンティケーターのレピュテーションを決定する前に検討する必要があります。
Dishonest servers can send EAP-Failure messages and abort the EAP authentication even if the received i1 is valid. However, servers can always abort any EAP session, independent of whether or not channel binding is offered. On the other hand, dishonest servers can claim a successful validation even if i1 contains invalid information. This can be seen as collaboration of authenticator and server. Channel binding can neither prevent nor detect such attacks. In general, such attacks cannot be prevented by cryptographic means and should be addressed using policies that make servers liable for their provided information and services.
不正なサーバーは、受信したi1が有効な場合でも、EAP-Failureメッセージを送信し、EAP認証を中止できます。ただし、チャネルバインディングが提供されているかどうかに関係なく、サーバーは常に任意のEAPセッションを中止できます。一方、不正なサーバーは、i1に無効な情報が含まれている場合でも、検証が成功したと主張できます。これは、認証システムとサーバーのコラボレーションと見なすことができます。チャネルバインディングは、このような攻撃を防ぐことも検出することもできません。一般に、このような攻撃は暗号化の手段で防止することはできません。提供される情報やサービスに対してサーバーが責任を負うようにするポリシーを使用して対処する必要があります。
Additional network entities (such as proxies) might be on the communication path between peer and server and may attempt to manipulate the channel-binding protocol. If these entities do not possess the keying material used for integrity protection of the channel-binding messages, the same threat analysis applies as for the dishonest authenticators. Hence, such entities cannot manipulate a single channel-binding message or the outcome. On the other hand, entities with access to the keying material must be treated like a server in a threat analysis. Hence, such entities are able to manipulate the channel-binding protocol without being detected. However, the required knowledge of keying material is unlikely since channel binding is executed before the EAP method is completed, and thus before keying material is typically transported to other entities.
追加のネットワークエンティティ（プロキシなど）がピアとサーバー間の通信パス上にある可能性があり、チャネルバインディングプロトコルの操作を試みる可能性があります。これらのエンティティがチャネルバインディングメッセージの整合性保護に使用されるキー情報を所有していない場合、不正な認証システムと同じ脅威分析が適用されます。したがって、そのようなエンティティは単一のチャネルバインディングメッセージまたは結果を操作できません。一方、キー分析情報にアクセスできるエンティティは、脅威分析ではサーバーのように扱う必要があります。したがって、このようなエンティティは、検出されることなくチャネルバインディングプロトコルを操作できます。ただし、チャネルバインディングはEAPメソッドが完了する前に実行されるため、通常、キー情報が他のエンティティに転送される前に、キー情報に関する必要な知識はほとんどありません。
EAP methods that add channel binding will typically negotiate its use. Even for entirely new EAP methods designed with channel binding from the first version, some deployments may not use it. It is desirable to protect against attacks on the negotiation of channel bindings. An attacker including the NAS SHOULD NOT be able to prevent a peer and server who support channel bindings from using them.
チャネルバインディングを追加するEAPメソッドは、通常、その使用をネゴシエートします。最初のバージョンのチャネルバインディングを使用して設計されたまったく新しいEAPメソッドでも、一部の展開ではそれを使用しない場合があります。チャネルバインディングのネゴシエーションに対する攻撃から保護することが望ましいです。 NASを含む攻撃者は、チャネルバインディングをサポートするピアとサーバーがそれらを使用するのを防ぐことはできません。
Unfortunately, existing EAP methods may make it difficult or impossible to protect against attacks on negotiation. For example, many EAP state machines will accept a success message at any point after key derivation to terminate authentication. EAP success messages are not integrity protected; an attacker who could insert a message can generate one. The NAS is always in a position to generate a success message. Common EAP servers take advantage of state machines accepting success messages even in cases where an EAP method might support a protected indication of success. It may be challenging to define channel-binding support for existing EAP methods in a manner that permits peers to distinguish an old EAP server that sends a success indication and does not support channel binding from an attacker injecting a success indication.
残念ながら、既存のEAP方式では、ネゴシエーションに対する攻撃から保護することが困難または不可能になる場合があります。たとえば、多くのEAPステートマシンは、認証を終了するためのキーの派生後の任意の時点で成功メッセージを受け入れます。 EAP成功メッセージは整合性が保護されていません。メッセージを挿入できる攻撃者がメッセージを生成できます。 NASは常に成功メッセージを生成する立場にあります。一般的なEAPサーバーは、EAPメソッドが成功の保護された表示をサポートする場合でも、成功メッセージを受け入れる状態マシンを利用します。既存のEAPメソッドのチャネルバインディングサポートを定義して、ピアが成功の通知を送信し、チャネルバインドをサポートしていない古いEAPサーバーを、成功の通知を注入する攻撃者から区別できるようにするのは難しい場合があります。
While the channel-binding information exchanged between EAP peer and EAP server (i.e., i1 and the result message) must always be integrity protected, it may not be encrypted. In the case that these messages contain identifiers of peer and/or network entities, the privacy property of the executed EAP method may be violated. Hence, in order to maintain the privacy of an EAP method, the exchanged channel-binding information must be encrypted. If encryption is not available, private information is not sent as part of the channel-binding information, as described in Section 6.1.
EAPピアとEAPサーバー間で交換されるチャネルバインディング情報（つまり、i1と結果メッセージ）は常に整合性が保護されている必要がありますが、暗号化されていない場合があります。これらのメッセージにピアやネットワークエンティティの識別子が含まれている場合、実行されたEAPメソッドのプライバシープロパティが侵害される可能性があります。したがって、EAP方式のプライバシーを維持するには、交換されるチャネルバインディング情報を暗号化する必要があります。暗号化が利用できない場合、セクション6.1で説明されているように、プライベート情報はチャネルバインディング情報の一部として送信されません。
Privacy implications of attributes selected for channel binding need to be considered. Consider channel binding the username attribute. A peer sends a privacy protecting anonymous identifier in its EAP identity message, but sends the full username in the protected i1 message. However, the authenticator would like to learn the full username. It makes a guess and sends that in i2 rather than the anonymous identifier. If the EAP server validates this attribute and fails when the username from the peer mismatches i2, then the EAP server confirms the authenticator's guess. Similar privacy exposures may result whenever one party is in a position to guess channel-binding information provided by another party.
チャネルバインディング用に選択された属性のプライバシーへの影響を考慮する必要があります。ユーザー名属性をチャネルバインドすることを検討してください。ピアは、そのEAP IDメッセージでプライバシー保護匿名識別子を送信しますが、保護されたi1メッセージで完全なユーザー名を送信します。ただし、認証者は完全なユーザー名を知りたいと考えています。推測して匿名IDではなくi2で送信します。 EAPサーバーがこの属性を検証し、ピアのユーザー名がi2と一致しない場合に失敗すると、EAPサーバーはオーセンティケーターの推測を確認します。ある当事者が別の当事者によって提供されたチャネルバインディング情報を推測する立場にあるときはいつでも、同様のプライバシーの危険が生じる可能性があります。
As with any extension to existing protocols, there will be an impact on existing systems. Typically, the goal is to develop an extension that minimizes the impact on both development and deployment of the new system, subject to the system requirements. This section discusses the impact on existing devices that currently utilize EAP, assuming the channel-binding information is transported within the EAP method execution.
既存のプロトコルへの拡張と同様に、既存のシステムに影響があります。通常、目標は、システム要件に従って、新しいシステムの開発と展開の両方への影響を最小限に抑える拡張機能を開発することです。このセクションでは、チャネルバインディング情報がEAPメソッドの実行内で転送されることを前提として、現在EAPを利用している既存のデバイスへの影響について説明します。
The EAP peer will need an API between the EAP lower layer and the EAP method that exposes the necessary information from the NAS to be validated to the EAP peer, which can then feed that information into the EAP methods for transport. For example, an IEEE 802.11 system would need to make available the various information elements that require validation to the EAP peer, which would properly format them and pass them to the EAP method. Additionally, the EAP peer will require updated EAP methods that support transporting channel-binding information. While most method documents are written modularly to allow incorporating arbitrary protected information, implementations of those methods would need to be revised to support these extensions. Driver updates are also required so methods can access the required information.
EAPピアは、検証するNASから必要な情報をEAPピアに公開するEAP下位層とEAPメソッドの間にAPIを必要とします。これにより、その情報をEAPメソッドに転送して転送することができます。たとえば、IEEE 802.11システムは、EAPピアへの検証を必要とするさまざまな情報要素を利用可能にする必要があります。これらの情報要素は、それらを適切にフォーマットし、EAPメソッドに渡します。さらに、EAPピアには、チャネルバインディング情報の転送をサポートする更新されたEAPメソッドが必要です。ほとんどのメソッドドキュメントはモジュール化されて記述されているため、任意の保護情報を組み込むことができますが、これらのメソッドの実装は、これらの拡張機能をサポートするように修正する必要があります。メソッドが必要な情報にアクセスできるように、ドライバーの更新も必要です。
No changes to the pass-through authenticator would be required.
パススルー認証システムを変更する必要はありません。
The EAP server would need an API between the database storing NAS information and the individual EAP server. The database may already exist on the AAA server, in which case the EAP server passes the parameters to the AAA server for validation. The EAP methods need to be able to export received channel-binding information to the EAP server so it can be validated.
EAPサーバーには、NAS情報を格納するデータベースと個々のEAPサーバーとの間にAPIが必要です。データベースはすでにAAAサーバーに存在している可能性があります。その場合、EAPサーバーは検証のためにパラメーターをAAAサーバーに渡します。 EAPメソッドは、検証できるように、受信したチャネルバインディング情報をEAPサーバーにエクスポートできる必要があります。
A new top-level registry has been created for "Extensible Authentication Protocol (EAP) Channel Binding Parameters". This registry consists of several sub-registries.
「Extensible Authentication Protocol（EAP）Channel Binding Parameters」用の新しいトップレベルのレジストリが作成されました。このレジストリは、いくつかのサブレジストリで構成されています。
The "EAP Channel-Binding Codes" sub-registry defines values for the code field in the channel-binding data and channel-binding response packet. See the table in Section 5.3.1 for initial registrations. This registry requires Standards Action [RFC5226] for new registrations. Early allocation [RFC4020] is allowed. An additional reference column has been added to the table for the registry, pointing all codes in the initial registration to this specification. Valid values in this sub-registry range from 0-255; 0 is reserved.
「EAP Channel-Binding Codes」サブレジストリは、チャネルバインディングデータおよびチャネルバインディング応答パケットのコードフィールドの値を定義します。初期登録については、セクション5.3.1の表を参照してください。このレジストリには、新規登録のための標準アクション[RFC5226]が必要です。早期割り当て[RFC4020]が許可されています。レジストリのテーブルに追加の参照列が追加され、初期登録のすべてのコードがこの仕様にポイントされています。このサブレジストリの有効な値の範囲は0〜255です。 0は予約されています。
The "EAP Channel-Binding Namespaces" sub-registry contains registrations for the NSID field in the channel-binding data and channel-binding response. Initial registrations are found in the table in Section 5.3.2. Registrations in this registry require IETF Review. Valid values range from 0-255; 0 is reserved. As with the "EAP Channel-Binding Codes" sub-registry, a reference column has been included to point to this document for initial registrations.
「EAP Channel-Binding Namespaces」サブレジストリには、チャネルバインディングデータおよびチャネルバインディング応答のNSIDフィールドの登録が含まれています。初期登録は、セクション5.3.2の表に記載されています。このレジストリへの登録にはIETFレビューが必要です。有効な値の範囲は0〜255です。 0は予約されています。 「EAP Channel-Binding Codes」サブレジストリと同様に、このドキュメントを最初の登録用に参照するための参照列が含まれています。
A new sub-registry in the EAP Numbers registry at http://www.iana.org/assignments/eap-numbers has been created for EAP Lower Layers. Registration requires Expert Review [RFC5226]; the primary role of the expert is to prevent multiple registrations for the same lower layer.
http://www.iana.org/assignments/eap-numbersにあるEAP番号レジストリの新しいサブレジストリが、EAP下位レイヤー用に作成されました。登録にはExpert Review [RFC5226]が必要です。エキスパートの主な役割は、同じ下位層に対する複数の登録を防ぐことです。
The following table gives the initial registrations for this registry.
次の表は、このレジストリの初期登録を示しています。
+-------+----------------------------------------+
| Value | Lower Layer |
+-------+----------------------------------------+
| 1 | Wired IEEE 802.1X |
| 2 | IEEE 802.11 (no-pre-auth) |
| 3 | IEEE 802.11 (pre-authentication) |
| 4 | IEEE 802.16e |
| 5 | IKEv2 |
| 6 | PPP |
| 7 | PANA (no pre-authentication) [RFC5191] |
| 8 | GSS-API [GSS-API-EAP] |
| 9 | PANA (pre-authentication) [RFC5873] |
+-------+----------------------------------------+
A new RADIUS attribute is registered with the name EAP-Lower-Layer; 163. The RADIUS attributes are in the registry at http://www.iana.org/assignments/radius-types.
新しいRADIUS属性がEAP-Lower-Layerという名前で登録されます。 163. RADIUS属性は、http：//www.iana.org/assignments/radius-typesのレジストリにあります。
The authors and editor would like to thank Bernard Aboba, Glen Zorn, Joe Salowey, Stephen Hanna, and Klaas Wierenga for their valuable inputs that helped to improve and shape this document over the time.
著者と編集者は、バーナードアボバ、グレンゾーン、ジョーサロウイ、スティーブンハンナ、およびクラースウィーレンガに、このドキュメントを改善し、形作るのに役立つ貴重な情報を提供してくれたことに感謝します。
Sam Hartman's work on this specification is funded by JANET(UK).
この仕様に関するSam Hartmanの作業は、JANET（UK）から資金提供を受けています。
The EAP-Lower-Layer attribute was taken from "RADIUS Attributes for IEEE 802 Networks" [RADIUS-WLAN].
EAP-Lower-Layer属性は、「IEEE 802ネットワークのRADIUS属性」[RADIUS-WLAN]から取得されました。
[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、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020] Kompella、K。およびA. Zinin、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 4020、2005年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[AAA-PAY] Clancy, T., Lior, A., Ed., Zorn, G., and K. Hoeper, "EAP Method Support for Transporting AAA Payloads", Work in Progress, May 2010.
[AAA-PAY] Clancy、T.、Lior、A.、Ed。、Zorn、G。、およびK. Hoeper、「AAAペイロードを転送するためのEAPメソッドのサポート」、Work in Progress、2010年5月。
[GSS-API-EAP] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", Work in Progress, June 2012.
[GSS-API-EAP]ハートマン、S。、エド。およびJ.ハウレット、「Extensible Authentication ProtocolのGSS-APIメカニズム」、Work in Progress、2012年6月。
[HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", Institute for Computer Sciences, Social Informatics and Telecommunications Engineering (ICST), The Fourth International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness (QShine 2007), August 2007.
[HC07] Hoeper、K.およびL. Chen、「Where EAP Security Claims Fail」、コンピュータ科学研究所、社会情報通信技術研究所（ICST）、第4回国際質の異なるネットワーク会議、信頼性、セキュリティおよび堅牢性（ QShine 2007）、2007年8月。
[RADIUS-WLAN] Aboba, B., Malinen, J., Congdon, P., and J. Salowey, "RADIUS Attributes for IEEE 802 Networks", Work in Progress, October 2011.
[RADIUS-WLAN] Aboba、B.、Malinen、J.、Congdon、P.、J。Salowey、「RADIUS Attributes for IEEE 802 Networks」、Work in Progress、2011年10月。
[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.アボバ、「ワイヤレスLANの拡張認証プロトコル（EAP）メソッドの要件」、RFC 4017、2005年3月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズN.、「セキュアチャネルへのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Patil、B.、Tschofenig、H。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）」、RFC 5191、2008年5月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296] Narayanan、V.およびL. Dondeti、「EAP Extensions for EAP Re-authentication Protocol（ERP）」、RFC 5296、2008年8月。
[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月。
In the following appendix, it is demonstrated how the presented channel bindings can prevent attacks by malicious authenticators (representing the "lying NAS" problem) as well as malicious visited networks (representing the "lying provider" problem). This document only provides part of the solution necessary to realize a defense against these attacks. In addition, lower-layer protocols need to describe what attributes should be included in channel-binding requests. EAP methods need to be updated in order to describe how the channel-binding request and response are carried. In addition, deployments may need to decide what information is populated in the local database. The following sections describe types of attacks that can be prevented by this framework with appropriate lower-layer attributes carried in channel bindings, EAP methods with channel-binding support, and appropriate local database information at the EAP server.
次の付録では、提示されたチャネルバインディングが、悪意のあるオーセンティケーター（「嘘つきNAS」の問題を表す）および悪意のある訪問ネットワーク（「嘘つきプロバイダー」の問題を表す）による攻撃をどのように防ぐことができるかを示します。このドキュメントは、これらの攻撃に対する防御を実現するために必要なソリューションの一部のみを提供します。さらに、下位層プロトコルは、チャネルバインディング要求に含める必要がある属性を記述する必要があります。チャネルバインディングの要求と応答の伝達方法を説明するために、EAPメソッドを更新する必要があります。さらに、デプロイメントでは、ローカルデータベースに入力する情報を決定する必要がある場合があります。以下のセクションでは、チャネルバインディングで運ばれる適切な下位層属性、チャネルバインディングサポートを使用するEAPメソッド、およびEAPサーバーでの適切なローカルデータベース情報を使用して、このフレームワークによって防止できる攻撃のタイプについて説明します。
As outlined in Section 3, an enterprise network may have multiple VLANs providing different levels of security. In an attack, a malicious NAS connecting to a guest network with lesser security protection could broadcast the SSID of a subnetwork with higher protection. This could lead peers to believe that they are accessing the network over secure connections and, e.g., transmit confidential information that they normally would not send over a weakly protected connection. This attack works under the conditions that peers use the same set of credentials to authenticate to the different kinds of VLANs and that the VLANs support at least one common EAP method. If these conditions are not met, the EAP server would not authorize the peers to connect to the guest network, because the peers used credentials and/or an EAP method that is associated with the corporate network.
セクション3で概説されているように、企業ネットワークには、さまざまなレベルのセキュリティを提供する複数のVLANがある場合があります。攻撃では、セキュリティ保護の低いゲストネットワークに接続している悪意のあるNASが、保護の高いサブネットワークのSSIDをブロードキャストする可能性があります。これにより、ピアは、安全な接続を介してネットワークにアクセスしていると思い込み、たとえば、通常は弱く保護された接続では送信しない機密情報を送信する可能性があります。この攻撃は、ピアが同じ資格情報のセットを使用してさまざまな種類のVLANに対して認証を行い、VLANが少なくとも1つの一般的なEAP方式をサポートするという条件下で機能します。これらの条件が満たされていない場合、ピアは資格情報や企業ネットワークに関連付けられたEAPメソッドを使用するため、EAPサーバーはピアにゲストネットワークへの接続を承認しません。
Mobile phone providers boosting their cell towers' transmission power to get more users to use their networks have occurred in the past. The increased transmission range combined with a NAS sending a false network identity lures users to connect to the network without being aware that they are roaming.
携帯電話プロバイダーは、より多くのユーザーにネットワークを使用してもらうために、セルタワーの送信電力を増強しています。 NASが誤ったネットワークIDを送信することと組み合わされた伝送範囲の拡大は、ユーザーがローミングしていることを意識せずにネットワークに接続するように誘います。
Channel bindings would detect the bogus network identifier because the network identifier sent to the authentication server in i1 will match neither information i2 nor the stored data. The verification fails because the info in i1 claims to come from the peer's home network, while the home authentication server knows that the connection is through a visited network outside the home domain. In the same context, channel bindings can be utilized to provide a "home zone" feature that notifies users every time they are about to connect to a NAS outside their home domain.
i1の認証サーバーに送信されたネットワーク識別子は情報i2にも保存されたデータとも一致しないため、チャネルバインディングは偽のネットワーク識別子を検出します。 i1の情報はピアのホームネットワークからのものであると主張しているため、検証は失敗します。一方、ホーム認証サーバーは、接続がホームドメイン外の訪問済みネットワークを介していることを認識しています。同じコンテキストで、チャネルバインディングを利用して、ホームドメイン外のNASに接続しようとするたびにユーザーに通知する「ホームゾーン」機能を提供できます。
A malicious authenticator could modify the set of offered EAP methods in its beacon to force the peer to choose from only the weakest EAP method(s) accepted by the authentication server. For instance, instead of having a choice between the EAP MD5 Challenge Handshake Authentication Protocol (EAP-MD5-CHAP), the Flexible Authentication via Secure Tunneling EAP (EAP-FAST), and some other methods, the authenticator reduces the choice for the peer to the weaker EAP-MD5- CHAP method. Assuming that weak EAP methods are supported by the authentication server, such a downgrading attack can enable the authenticator to attack the integrity and confidentiality of the remaining EAP execution and/or break the authentication and key exchange. The presented channel bindings prevent such downgrading attacks, because peers submit the offered EAP method selection that they have received in the beacon as part of i1 to the authentication server. As a result, the authentication server recognizes the modification when comparing the information to the respective information in its policy database. This presumes that all acceptable EAP methods support channel binding and that an attacker cannot break the EAP method in real-time.
悪意のあるオーセンティケーターは、ビーコンで提供されているEAP方式のセットを変更して、認証サーバーによって受け入れられた最も弱いEAP方式のみからピアを選択させることができます。たとえば、認証者は、EAP MD5チャレンジハンドシェイク認証プロトコル（EAP-MD5-CHAP）、Secure Tunneling EAP（EAP-FAST）を介した柔軟な認証、および他のいくつかの方法から選択する代わりに、ピアの選択を減らします弱いEAP-MD5- CHAP方式に。弱いEAP方式が認証サーバーでサポートされていると想定すると、このようなダウングレード攻撃により、認証者は残りのEAP実行の整合性と機密性を攻撃し、認証や鍵交換を破ることができます。提示されたチャネルバインディングは、ピアがi1の一部としてビーコンで受信した提供されたEAPメソッド選択を認証サーバーに送信するため、このようなダウングレード攻撃を防止します。その結果、認証サーバーは、ポリシーデータベース内のそれぞれの情報と情報を比較するときに、変更を認識します。これは、受け入れ可能なすべてのEAPメソッドがチャネルバインディングをサポートし、攻撃者がリアルタイムでEAPメソッドを解読できないことを前提としています。
In IEEE 802.11r, the SSID is bound to the TSK calculations, so that the TSK needs to be consistent with the SSID advertised in an authenticator's beacon. While this prevents outsiders from spoofing a beacon, it does not stop a "lying NAS" from sending a bogus beacon and calculating the TSK accordingly.
IEEE 802.11rでは、SSIDはTSKの計算にバインドされるため、TSKは認証システムのビーコンで通知されるSSIDと一致する必要があります。これにより、部外者によるビーコンのなりすましが防止されますが、「横になっているNAS」が偽のビーコンを送信し、それに応じてTSKを計算することは阻止されません。
By implementing channel bindings, as described in this document, in IEEE 802.11r, the verification by the authentication server would detect the inconsistencies between the information the authenticator has sent to the peer and the information the server received from the authenticator and stores in the policy database.
このドキュメントで説明されているように、IEEE 802.11rでチャネルバインディングを実装することにより、認証サーバーによる検証は、認証システムがピアに送信した情報と、サーバーが認証システムから受信してポリシーに格納した情報との間の不整合を検出しますデータベース。
In IEEE 802.11i, a malicious NAS can modify the beacon to make the peer believe it is connected to a network different from the one the peer is actually connected to.
IEEE 802.11iでは、悪意のあるNASがビーコンを変更して、ピアが実際に接続しているネットワークとは異なるネットワークに接続しているとピアに信じ込ませることができます。
In addition, a malicious NAS can force an authentication server into authorizing access by sending an incorrect Called-Station-ID that belongs to an authorized NAS in the network. This could cause the authentication server to believe it had granted access to a different network or even provider than the one the peer got access to.
さらに、悪意のあるNASは、ネットワーク内の承認されたNASに属する不正なCalled-Station-IDを送信することにより、認証サーバーに強制的にアクセスを許可させることができます。これにより、認証サーバーは、ピアがアクセスしたネットワークとは異なるネットワークまたはプロバイダーへのアクセスを許可したと信じることができます。
Both attacks can be prevented by implementing channel bindings, because the server can compare the information sent to the peer, the information it received from the authenticator during the AAA communication, and the information stored in the policy database.
サーバーはピアに送信された情報、AAA通信中にオーセンティケーターから受信した情報、およびポリシーデータベースに格納されている情報を比較できるため、どちらの攻撃もチャネルバインディングを実装することで防止できます。
Authors' Addresses
著者のアドレス
Sam Hartman (editor) Painless Security 356 Abbott St. North Andover, MA 01845 USA
サムハートマン（編集者）Painless Security 356 Abbott St. North Andover、MA 01845 USA
EMail: hartmans-ietf@mit.edu
T. Charles Clancy Virginia Polytechnic Institute and State University Electrical and Computer Engineering 900 North Glebe Road Arlington, VA 22203 USA
T.チャールズクランシーバージニア工科大学および州立大学電気およびコンピューター工学900 North Glebe Roadアーリントン、バージニア州22203米国
EMail: tcc@vt.edu
Katrin Hoeper Motorola Solutions, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA
かｔりん ほえぺｒ もとろぁ そぅちおんｓ、 いんｃ。 １３０１ え。 あｌごんくいん ろあｄ Ｓちゃうｍぶｒｇ、 いＬ ６０１９６ うさ
EMail: khoeper@motorolasolutions.com