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
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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）基础设施表示一组信息（例如，网络身份、能力、配置等），同时向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.
作为一个具体的例子，考虑具有两个不同的IEEE 802.11无线网络的组织。一个是访问web的安全性相对较低的网络，而另一个可以访问有价值的机密信息。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
本文档定义并实现EAP通道绑定，以解决“说谎NAS”和“说谎提供者”问题，使用EAP对等方向受保护的AAA服务器提供有关认证者提供的服务特征的信息的过程
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方法中。这允许服务器验证验证器向对等方提供的信息是否与从该验证器接收的信息以及存储的关于该验证器的信息一致。[AAA-PAY]中定义的“AAA有效载荷”是本规范中提出的承载此信息的机制的起点。
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].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
有两种不同类型的网络需要考虑：企业网络和服务提供商网络。在企业网络中，假设只有一个管理域，EAP服务器可以拥有关于网络中所有身份验证器的信息。在服务提供商网络中，由于漫游的间接性，全球知识是不可行的。当对等方不在其主管理域内时，目标是确保对等方接收的服务级别与两个服务提供商之间的合同协议一致。同一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 企业网络：一个企业网络可能有多个虚拟局域网（VLAN）在其整个校园网中可用，并且有IEEE 802.11接入点连接到每个VLAN。假设一个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通用安全服务应用程序接口（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
o 服务提供商网络：支持EAP的移动电话提供商可以宣传非常有竞争力的固定费率，但可以将每分钟费率发送到家庭服务器，从而吸引对等方连接到其网络并向其多收费。在更为复杂的攻击中，对等方可能会被诱骗在不知情的情况下漫游。例如，一家沿地缘政治边界运营的移动电话提供商可以提高其手机发射塔的传输能力，并宣传邻国本土提供商的网络身份。这将导致不知情的手机与无意中的运营商联系起来，从而在没有意识到它们已经漫游出其家庭提供商的网络的情况下支付高额漫游费。这些类型的场景可被视为“说谎提供商”问题，因为在这里，提供商将其NAS配置为广播错误信息。就本文档中定义的通道绑定而言，服务提供商网络（本地NAS、本地身份验证服务器和/或本地代理）中“存在”的本地实体并不重要，因为从访问的网络接收到的唯一由通道绑定验证的信息是家庭身份验证服务器从通信链中的最后一个跃点接收到的信息。换句话说，通道绑定支持
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.
检测访问网络中信息的不一致性，但无法确定哪个实体在撒谎。当然，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对等方通告的信息的准确性。这两个相关概念分别采用了术语“通道绑定”；当冲突被发现时，每种用法都有大量的文献。EAP通道绑定可用于提供[RFC5056]通道绑定。特别是，通过在内部EAP方法的通道绑定中包含外部通道的[RFC5056]通道绑定数据，可以将内部EAP方法绑定到外部方法。这样做将提供类似于EAP加密绑定的功能，只是中间的人无法从隧道中提取内部方法。本规范未权衡这样做的优点，也未说明如何这样做；本示例仅用于说明EAP通道绑定和[RFC5056]通道绑定如何重叠。
There are two categories of approach to EAP channel bindings:
EAP通道绑定有两类方法：
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 对等方和服务器都可以在不交换网络信息的情况下对各自的网络信息视图进行唯一编码，从而形成一个不透明的blob，该blob可以直接包含在EAP会话密钥的派生中。
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服务器知道的密钥进行保密保护。为了使系统正常工作，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.
对于许多部署，更改所有NASE的成本很高，并且为足够多的EAP方法添加通道绑定支持以实现部署目标的成本也会更低。然而，对于新设备的部署，特别是新的低层技术的部署，改变NASE可能比改变EAP方法更便宜。特别是如果这样的部署需要支持大量EAP方法，那么在安全关联协议中发送通道绑定可能是有意义的。在安全关联协议中发送通道绑定甚至可以与EAP重新认证协议（ERP）[RFC5296]一起工作，其中先前建立的EAP密钥材料用于安全关联协议，而无需在重新认证期间执行任何EAP方法。
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通道绑定的范围根据使用它们的部署类型有所不同。在企业网络中，它们可用于认证验证器的特定属性（例如，介质访问控制（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信息可能不包含太多可验证的信息。例如，AAA属性（如NAS IP地址）中携带的信息可能在转换过程中丢失，因此EAP服务器不知道。更糟糕的是，信息可能仍然可用，但毫无用处，例如，表示专用网络或中间盒上设备的身份。这会影响EAP服务器验证特定NAS属性的能力。然而，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。管理员需要确保网络保证，当AAA基础设施信任的认证器向客户端提供特定SSID时，该网络具有预期的属性。通常，当NAS被授权声明特定服务时，通道绑定不可能检测到说谎的NAS行为。也就是说，如果允许同一个物理验证器公布两个网络，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属性，而是来自本地配置。例如，在移动电话案例中，预期漫游速率不能来自漫游提供商，除非根据两个提供商之间的合同进行验证。类似地，在企业中，特定接入点预期公布的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协议和本地数据库提供的信息来区分较不受信任的实体和较受信任的实体。一种可能的部署涉及到能够验证关于相对可信实体的许多特征，而对于其他实体，则只是验证它们是否不那么可信。
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节）。在第一小节中，概述了通用通信基础设施，指定了用于通道绑定验证的消息，并定义了协议流。第二小节探讨了检查通道绑定协议期间交换的不同信息片段的一致性的困难。第三小节描述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.
通道绑定始终在两个通信端点（此处为EAP对等方和EAP服务器）之间提供，它们通常以直通模式通过验证器进行通信。规范将AAA服务器和EAP服务器视为不同的实体。但是，AAA服务器和EAP服务器之间没有标准的通信协议。为了使本文档中介绍的通道绑定协议能够工作，EAP服务器需要能够访问EAP会话（下面的i2）期间使用的AAA服务器和本地数据库中的信息。例如，EAP服务器和本地数据库可以与AAA服务器共存，如图1所示。另一种体系结构是为EAP服务器提供一种机制，用于通知AAA服务器提供了哪些通道绑定属性，并且AAA服务器通知EAP服务器在做出决策时考虑了哪些通道绑定属性。
+ -------------------------+
-------- ------------- | ---------- ______ |
|EAP peer|<---->|Authenticator|<--> | |EAP Server|___(______) |
-------- ------------- | ---------- | DB | |
. . |AAA (______) |
. i1 . +--------------------------+
.<----------------. i2 . .
. .------------> .
. i1 .
.-------------------------------------->.
. CB_success/failure(i1, i2,info) .
.<--------------------------------------.
+ -------------------------+
-------- ------------- | ---------- ______ |
|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还可以包括验证器标识符和它所表示的网络的标识。信息（例如正在使用的媒体类型）可以在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节中描述的机制向EAP服务器发送i1。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
上面，EAP服务器被描述为执行通道绑定验证。在大多数部署中，这将是一个必要的实现约束。EAP交换需要包括通道绑定成功或失败的指示。大多数现有实现没有在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消息期间，服务器和另一个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失败消息以终止会话。如果EAP服务器以其他方式配置，则必须允许EAP会话正常完成，并由对等方的策略决定网络访问。如果i1或i2不符合策略，EAP服务器不得在用于执行通道绑定的信息集中列出不符合策略的信息。在这种情况下，EAP服务器应指示通道绑定失败；这一要求将来可能会升级为必须的要求。
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:
验证检查是上一小节中描述的通道绑定协议的核心，由两部分组成，其中服务器检查是否：
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服务器能够检测企业网络中的说谎NASE或验证器以及服务提供商网络中的说谎提供商。
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
正如[HC07]中已经指出的，检查i1和i2的一致性是非常重要的。首先，i1可以包含由身份验证器传播的任何类型的信息，而i2仅限于可以在AAA属性中携带的信息。第二，由于认证器通常通过不同的链路层与对等方和AAA基础设施进行通信，因此可能已经向两个通信端点呈现了不同类型的标识符和地址。如果没有其他信息，EAP服务器或AAA服务器无法直接检查这些不同的标识符和地址是否属于同一设备。最后，由于途中处理或恶意修改，i2可能与验证器发送的原始信息不同。因此，在服务提供商模型中，EAP服务器可用的i1信息通常只能根据i2的最后一个跃点部分或根据i2传播的值进行验证
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.
代理服务器。此外，仅检查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属性以及在转换过程中可能丢失的额外存储的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方法来说太大。对等方应提供适当的策略控制以选择通道绑定或强制其成功。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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所示的格式。协议以一个字节代码开始；见第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.
长度：以网络字节顺序表示的长度的两个八位字节，表示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：名称空间标识符。一个八位字节，描述从中绘制属性的名称空间。有关如何在通道绑定数据和响应中编码半径属性的说明，请参见第5.3.3节。RADIUS使用名称空间标识符1。
NS-Specific: The encoding of the attributes in a manner specific to the type of attribute.
NS Specific：以特定于属性类型的方式对属性进行编码。
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在通道绑定数据或通道绑定响应中不得出现多次。相反，特定NSID的所有NS特定数据必须出现在一组字段（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
在通道绑定响应中，服务器选择代码；见第5.3.1节。对于成功的通道绑定，服务器返回代码2。EAP服务器返回的属性集取决于代码。如果成功，服务器将返回服务器在确定通道绑定已成功验证时考虑的属性；服务器无法检查或无法根据发送的内容验证的属性
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.
不能在成功响应中返回对等方。通常，如果检查了任何属性并且无法验证对等方指定的属性，服务器将不会返回成功响应。在特殊情况下，例如在服务器上分阶段使用新属性，当该属性无法验证时，可能需要服务器返回成功。在通道绑定响应中返回属性时，服务器返回对等方提供的值。
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），服务器应包括已成功验证的所有属性。此代码表示服务器策略指示客户端发送的属性不能准确描述身份验证器。服务器在此响应中可能不包含任何属性；例如，如果服务器检查对等方提供的属性，但这些属性不一致，则可能会发送不带属性的响应。
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 |
+------+-----------------------------------+
+------+-----------------------------------+
| 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 | |
+-----+--------------------------+---------------+
+-----+--------------------------+---------------+
| 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.
半径属性值对（AVP）使用一个八位字节属性类型，后跟一个八位字节长度，后跟正在编码的半径属性值进行编码。长度包括八位字节的类型和长度；最低法定长度为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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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设备操纵传输的数据。传输协议应提供保密性。这样做的动机是通道绑定可以包含私有信息，包括应该保护的对等身份。如果无法提供机密性，则不得将私人信息作为通道绑定信息的一部分发送。
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
任何传输都需要小心，不要超过下层介质的MTU。特别地，如果在受保护的EAP方法信道内交换信道绑定信息，则这些方法可以是或
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.
可能不支持碎片化。为了使用所有方法，通道绑定消息必须适合可用负载。例如，如果EAP MTU是1020个八位字节，并且EAP-通用预共享密钥（EAP-GPSK）用作认证方法，并且使用最大长度标识，则最多384个八位字节可用于传输信道绑定信息。其他方法，如EAP隧道传输层安全性（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属性，但为了已有的有形属性，本节讨论适合承载通道绑定的AAA AVP（即第5节中i1的数据）。
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
通常，较低的层需要指定i1中应该包含哪些信息。现有的较低层可能需要新文档来指定此信息。下层规范
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中包含足够的信息，以唯一地确定涉及哪个较低层。执行此操作的首选方法是包含下一节中定义的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.
定义了一个新的RADIUS属性来携带用于此EAP身份验证的EAP较低层的信息。此属性提供与EAP传输的下层相关的信息。NAS可以在访问请求或记帐请求数据包中将此属性发送到RADIUS服务器。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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访问请求消息中哪些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地址：该值通常是验证器的IP地址；但是，在代理连接中，它可能与访问请求的源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地址；但是，在代理连接中，它可能与访问请求的源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标识符：这是由NAS填充的标识符，用于向AAA服务器标识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端口类型：指定基础链路技术。应根据信息交换中从对等方收到的值以及授权链路层技术的数据库对其进行验证。
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执行期间建立前两个信任关系，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部署中，一个身份验证器可以模拟另一个身份验证器的攻击并不重要，因为所有身份验证器都提供相同的服务。身份验证器不会通过模拟另一个身份验证器而获得显著优势。在不同身份验证器提供不同服务的情况下使用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
通道绑定的一个有吸引力的实现策略是向隧道方法添加通道绑定支持，该隧道方法可以隧道内部EAP身份验证。通过这种方式，可以使用任何可以充当内部方法的方法实现通道绑定，即使该内部方法没有本机通道绑定支持。相互认证和密钥派生的要求在实际执行通道绑定的EAP层。隧道方法有时使用加密绑定，这是一个对等方证明外部方法的对等方与内部方法的对等方相同的过程，用于将一层的身份验证与内层绑定在一起。加密绑定并不总是提供相互认证；它的定义不要求服务器证明内部服务器和外部服务器是相同的。即使加密绑定尝试确认内部和外部服务器是相同的，来自内部方法的主会话密钥（MSK）通常也用于保护绑定。攻击者（如想要破坏通道绑定的身份验证程序）可能会建立一个终止于身份验证程序的外部隧道。如果外部方法隧道在验证器上终止，则向验证器公开MSK，验证器通常可以攻击加密绑定。如果验证器控制加密绑定，则它通常控制通道绑定参数和结果。如果通道绑定过程用于区分一个身份验证器和另一个身份验证器，则该身份验证器可以声明支持未经授权的服务。此攻击不在现有加密绑定威胁模型的范围内，因为不考虑区分身份验证器。因此，现有的加密绑定通常不提供通道绑定所需的内部方法服务器的相互身份验证。除了加密绑定之外，还有其他方法可用
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.
提供通道绑定所需的相互身份验证。例如，如果验证服务器证书并检查名称，则可以通过隧道直接提供相互身份验证。
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.
不诚实的服务器可以发送EAP失败消息并中止EAP身份验证，即使收到的i1有效。但是，服务器始终可以中止任何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
需要考虑为通道绑定选择的属性的隐私影响。考虑信道绑定用户名属性。对等方在其EAP标识消息中发送隐私保护匿名标识符，但在受保护的i1消息中发送完整用户名。但是，验证者希望了解完整信息
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.
用户名。它进行猜测并在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对等方将需要EAP下层和EAP方法之间的API，该API将来自NAS的必要信息公开给EAP对等方进行验证，然后EAP对等方可以将该信息提供给EAP方法进行传输。例如，IEEE 802.11系统需要向EAP对等方提供需要验证的各种信息元素，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.
已为“可扩展身份验证协议（EAP）通道绑定参数”创建了一个新的顶级注册表。该注册表由几个子注册表组成。
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通道绑定代码”子注册表定义通道绑定数据和通道绑定响应数据包中代码字段的值。初始注册见第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通道绑定名称空间”子注册表包含通道绑定数据和通道绑定响应中NSID字段的注册。初始注册见第5.3.2节中的表格。此注册表中的注册需要IETF审查。有效值范围为0-255；0是保留的。与“EAP通道绑定代码”子注册表一样，已包含一个参考列，用于指向本文档进行初始注册。
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.
EAP编号注册表中的新子注册表位于http://www.iana.org/assignments/eap-numbers 已为EAP较低层创建。注册需要专家审查[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] |
+-------+----------------------------------------+
+-------+----------------------------------------+
| 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.
使用名称EAP Lower Layer注册一个新的RADIUS属性；163半径属性位于注册表中的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.
作者和编辑要感谢Bernard Aboba、Glen Zorn、Joe Salowey、Stephen Hanna和Klaas Wierenga，感谢他们的宝贵意见，这些意见有助于改进和形成本文件。
Sam Hartman's work on this specification is funded by JANET(UK).
Sam Hartman在本规范方面的工作由JANET（英国）资助。
The EAP-Lower-Layer attribute was taken from "RADIUS Attributes for IEEE 802 Networks" [RADIUS-WLAN].
EAP下层属性取自“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，“可扩展身份验证协议（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，“早期IANA标准轨道代码点分配”，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，“在RFCs中编写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，“EAP方法支持AAA有效载荷的运输”，正在进行的工作，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]Hartman，S.，Ed.和J.Howlett，“可扩展身份验证协议的GSS-API机制”，正在进行的工作，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，“EAP安全声明失败的地方”，计算机科学、社会信息学和电信工程研究所（ICST），第四届异构网络质量、可靠性、安全性和鲁棒性国际会议（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，“IEEE 802网络的RADIUS属性”，正在进行的工作，2011年10月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，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，“承载网络接入认证（PANA）的协议”，RFC 51912008年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再认证协议（ERP）的EAP扩展”，RFC 52962008年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至少支持一种常见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发送虚假的网络标识，诱使用户连接到网络而不知道自己正在漫游。
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
通道绑定将检测到伪造的网络标识符，因为发送到i1中的身份验证服务器的网络标识符既不匹配信息i2，也不匹配存储的数据。验证失败，因为i1中的信息声称来自对等方的家庭网络，而家庭身份验证服务器知道
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.
连接通过主域之外的访问网络进行。在相同的上下文中，可以利用通道绑定提供“主区域”功能，在用户每次要连接到其主域之外的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）、通过安全隧道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的不正确被叫站点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
山姆·哈特曼（编辑）无痛安全美国马萨诸塞州北安多佛阿伯特街356号01845
EMail: hartmans-ietf@mit.edu
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.Charles Clancy弗吉尼亚理工学院和州立大学电气和计算机工程900美国弗吉尼亚州阿灵顿北格莱贝路22203号
EMail: tcc@vt.edu
EMail: tcc@vt.edu
Katrin Hoeper Motorola Solutions, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA
Katrin Hoeper Motorola Solutions，Inc.地址：美国伊利诺伊州绍姆堡阿尔冈金东路1301号，邮编：60196
EMail: khoeper@motorolasolutions.com
EMail: khoeper@motorolasolutions.com