Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7029 M. Wasserman
Category: Informational Painless Security
ISSN: 2070-1721 D. Zhang
Huawei
October 2013
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7029 M. Wasserman
Category: Informational Painless Security
ISSN: 2070-1721 D. Zhang
Huawei
October 2013
Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding
可扩展身份验证协议（EAP）相互加密绑定
Abstract
摘要
As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.
随着可扩展认证协议（EAP）的发展，EAP对等方越来越依赖于从EAP服务器接收的信息。信道绑定或网络姿态信息等EAP扩展通常在隧道方法中进行；同龄人可能会依赖这些信息。加密绑定是RFC3748中描述的一种功能，用于保护隧道方法免受中间人攻击。但是，加密绑定的重点是保护服务器而不是对等方。本备忘录探讨了当对等方不受中间人攻击保护时可能发生的攻击，并建议基于扩展主会话密钥的加密绑定，这是一种新的加密绑定形式，可保护对等方和服务器以及其他缓解措施。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7029.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7029.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Keywords for Requirement Levels ............................5
2. An Example Problem ..............................................5
3. The Server Insertion Attack .....................................6
3.1. Conditions for the Attack ..................................7
3.2. Mitigation Strategies ......................................8
3.2.1. Server Authentication ...............................8
3.2.2. Server Policy .......................................9
3.2.3. Existing Cryptographic Binding .....................12
3.2.4. Introducing EMSK-Based Cryptographic Binding .......12
3.2.5. Mix Key into Long-Term Credentials .................14
3.3. Intended Intermediates ....................................14
4. Recommendations ................................................15
4.1. Mutual Cryptographic Binding ..............................15
4.2. State Tracking ............................................15
4.3. Certificate Naming ........................................16
4.4. Inner Mixing ..............................................16
5. Survey of Tunnel Methods .......................................16
5.1. Tunnel EAP (TEAP) Method ..................................16
5.2. Flexible Authentication via Secure Tunneling (FAST) .......17
5.3. EAP Tunneled Transport Layer Security (EAP-TTLS) ..........17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
1. Introduction ....................................................3
1.1. Keywords for Requirement Levels ............................5
2. An Example Problem ..............................................5
3. The Server Insertion Attack .....................................6
3.1. Conditions for the Attack ..................................7
3.2. Mitigation Strategies ......................................8
3.2.1. Server Authentication ...............................8
3.2.2. Server Policy .......................................9
3.2.3. Existing Cryptographic Binding .....................12
3.2.4. Introducing EMSK-Based Cryptographic Binding .......12
3.2.5. Mix Key into Long-Term Credentials .................14
3.3. Intended Intermediates ....................................14
4. Recommendations ................................................15
4.1. Mutual Cryptographic Binding ..............................15
4.2. State Tracking ............................................15
4.3. Certificate Naming ........................................16
4.4. Inner Mixing ..............................................16
5. Survey of Tunnel Methods .......................................16
5.1. Tunnel EAP (TEAP) Method ..................................16
5.2. Flexible Authentication via Secure Tunneling (FAST) .......17
5.3. EAP Tunneled Transport Layer Security (EAP-TTLS) ..........17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
The Extensible Authentication Protocol (EAP) [RFC3748] provides authentication between a peer (a party accessing some service) and a authentication server. Traditionally, peers have not relied significantly on information received from EAP servers. However, facilities such as EAP channel binding [RFC6677] provide the peer with confirmation of information about the resource it is accessing. Other facilities such as EAP Posture Transport [PT-EAP] permit a peer and EAP server to discuss the security properties of accessed networks. Both of these facilities provide peers with information they need to rely on and provide attackers who are able to impersonate an EAP server to a peer with new opportunities for attack.
可扩展身份验证协议（EAP）[RFC3748]提供对等方（访问某些服务的一方）和身份验证服务器之间的身份验证。传统上，对等方不太依赖从EAP服务器接收的信息。但是，EAP通道绑定[RFC6677]等功能向对等方提供有关其正在访问的资源的信息确认。EAP姿态传输[PT-EAP]等其他设施允许对等方和EAP服务器讨论访问网络的安全属性。这两种设施都为对等方提供了他们需要依赖的信息，并为能够向对等方模拟EAP服务器的攻击者提供了新的攻击机会。
Instead of adding these new facilities to all EAP methods, work has focused on adding support to tunnel methods [RFC6678]. There are numerous tunnel methods, including [RFC4851] and [RFC5281], and work on building a Standards Track tunnel method [TEAP]. These tunnel methods are extensible. By adding an extension to support a facility such as channel binding to a tunnel method, an extension can be used with any inner method carried in the tunnel.
与其将这些新设施添加到所有EAP方法中，不如将工作重点放在为隧道方法添加支持[RFC6678]。有许多隧道方法，包括[RFC4851]和[RFC5281]，并致力于建立标准轨道隧道方法[TEAP]。这些隧道方法是可扩展的。通过添加一个扩展来支持一个工具，例如通道绑定到隧道方法，扩展可以与隧道中携带的任何内部方法一起使用。
Tunnel methods need to be careful about man-in-the-middle attacks. See [RFC6678] (Sections 3.2 and 4.6.3) and [TUNNEL-MITM] for a detailed description of these attacks. For example, an attack can happen when a peer is willing to perform authentication inside and outside a tunnel. An attacker can impersonate the EAP server and offer the inner method to the peer. However, on the other side, the attacker acts as a man-in-the-middle and opens a tunnel to the real EAP server. Figure 1 illustrates this attack. At the end of the attack, the EAP server believes it is talking to the peer. At the inner method level, this is true. At the outer method level, however, the server is talking to the attacker.
隧道方法需要小心中间人攻击。有关这些攻击的详细说明，请参见[RFC6678]（第3.2节和第4.6.3节）和[TUNNEL-MITM]。例如，当对等方愿意在隧道内外执行身份验证时，可能会发生攻击。攻击者可以模拟EAP服务器并向对等方提供内部方法。然而，在另一方面，攻击者充当中间人，打开一条通向真正EAP服务器的隧道。图1说明了这种攻击。在攻击结束时，EAP服务器认为它正在与对等方对话。在内部方法级别，这是正确的。但是，在外部方法级别，服务器正在与攻击者对话。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+-------X-------->| |
| (Intercepted by an Attacker) | |
| | | |
| | Tunnel Establishment |
| |<-------------------------------->|
| | | |
| |..................................|
| | Tunnel |
| Non-Tunneled | | |
| Method | Tunneled Authentication Method |
|<===================>|<================================>|
| | | |
| |..................................|
| | | |
| | Attacker |<--- MSK keys --|
| | Connected as | |
| | Peer | |
| |<--------------->| |
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+-------X-------->| |
| (Intercepted by an Attacker) | |
| | | |
| | Tunnel Establishment |
| |<-------------------------------->|
| | | |
| |..................................|
| | Tunnel |
| Non-Tunneled | | |
| Method | Tunneled Authentication Method |
|<===================>|<================================>|
| | | |
| |..................................|
| | | |
| | Attacker |<--- MSK keys --|
| | Connected as | |
| | Peer | |
| |<--------------->| |
A classic tunnel attack where the attacker inserts an extra tunnel between the attacker and EAP server.
一种典型的隧道攻击，攻击者在攻击者和EAP服务器之间插入额外的隧道。
Figure 1: Classic Tunnel Attack
图1：经典隧道攻击
There are two mitigation strategies for this classic attack. First, security policy can be set up so that the same method is not offered by a server both inside and outside a tunnel. Second, a technical solution is available if the inner method is sufficiently strong: cryptographic binding is a security property of a tunnel method under which the EAP server confirms that the inner and outer parties are the same. Cryptographic binding is typically implemented by requiring the outer party (the other end of the tunnel) to prove knowledge of the Master Session Key (MSK) of the inner method. This proves to the server that the inner and outer exchanges are with the same party. RFC 3748's definition of cryptographic binding allows for an optional proof to the peer that the inner and outer exchanges are with the same party. As discussed below, proving knowledge of the MSK is insufficient to prove to the peer that the inner and outer exchanges are with the same party.
此经典攻击有两种缓解策略。首先，可以设置安全策略，以便隧道内外的服务器都不提供相同的方法。其次，如果内部方法足够强大，则可以使用技术解决方案：加密绑定是隧道方法的安全属性，在该方法下，EAP服务器确认内部和外部方是相同的。加密绑定通常通过要求外部方（隧道的另一端）证明内部方法的主会话密钥（MSK）的知识来实现。这向服务器证明内部和外部交换是与同一方进行的。RFC 3748对加密绑定的定义允许向对等方提供可选的证据，证明内部和外部交换是与同一方进行的。如下所述，证明MSK的知识不足以向对等方证明内部和外部交换是与同一方进行的。
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]中所述进行解释。
The GSS-EAP (Generic Security Service Extensible Authentication Protocol) mechanism [GSS-EAP] provides application authentication using EAP. A peer could reasonably trust some applications significantly more than others. If the peer sends confidential information to some applications, an attacker may gain significant value from convincing the peer that the attacker is the trusted application. Channel bindings are used to provide information to the peer about the application service to which the peer connects. Prior to channel bindings, peers could not distinguish one Network Access Service (NAS) from another, so attacks where one NAS impersonated another were out of scope. However, channel bindings add this capability and thus expands the threat model of EAP. The GSS-EAP mechanism requires distinguishing one service from another.
GSS-EAP（通用安全服务可扩展身份验证协议）机制[GSS-EAP]使用EAP提供应用程序身份验证。对等方可以合理地信任某些应用程序，而不是其他应用程序。如果对等方向某些应用程序发送机密信息，攻击者可以通过说服对等方攻击者是受信任的应用程序而获得重大价值。通道绑定用于向对等方提供有关对等方所连接的应用程序服务的信息。在通道绑定之前，对等方无法区分一个网络访问服务（NAS）和另一个，因此一个NAS模拟另一个NAS的攻击超出范围。然而，通道绑定增加了这种能力，从而扩展了EAP的威胁模型。GSS-EAP机制要求区分不同的服务。
Consider the following example. A relatively untrusted service, say a print server, has been compromised. A user is attempting to connect to a trusted service such as a financial application. Both the print server and the financial application use an Authentication, Authorization, and Accounting protocol (AAA) to transport EAP authentication back to the user's EAP server. The print server mounts a man-in-the-middle attack on the user's connection to the financial application and claims to be the application.
考虑下面的例子。一个相对不可信的服务，比如打印服务器，已经被破坏。用户正试图连接到受信任的服务，如金融应用程序。打印服务器和财务应用程序都使用身份验证、授权和记帐协议（AAA）将EAP身份验证传输回用户的EAP服务器。打印服务器在用户与金融应用程序的连接上安装中间人攻击，并声称是该应用程序。
The print server offers a tunnel method towards the peer. The print server extracts the inner method from the tunnel and sends it on towards the AAA server. Channel binding happens at the tunnel method though. So, the print server is happy to confirm that it is the financial application. After the inner method completes, the EAP server sends the MSK to the print server over the AAA protocol. If only the MSK is needed for cryptographic binding, then the print server can successfully perform cryptographic binding and may be able to impersonate the financial application to the peer.
打印服务器提供了一种通向对等方的隧道方法。打印服务器从隧道中提取内部方法，并将其发送到AAA服务器。通道绑定发生在隧道方法中。因此，打印服务器很乐意确认它是财务应用程序。内部方法完成后，EAP服务器通过AAA协议将MSK发送到打印服务器。如果加密绑定只需要MSK，则打印服务器可以成功执行加密绑定，并且可以向对等方模拟金融应用程序。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel | | |
| | |
| Tunneled | Non-Tunneled |
| Method | Authentication Method |
|<===================>|<================================>|
| |(Same as Inner Method from Tunnel)|
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel | | |
| | |
| Tunneled | Non-Tunneled |
| Method | Authentication Method |
|<===================>|<================================>|
| |(Same as Inner Method from Tunnel)|
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |
A modified tunnel attack when an extra server rather than extra client is inserted.
插入额外服务器而不是额外客户端时的修改隧道攻击。
Figure 2: Channel Binding Requires More than Cryptographic Binding
图2：通道绑定需要的不仅仅是加密绑定
This attack is not specific to GSS-EAP. The channel bindings specification [RFC6677] describes a number of situations where channel bindings are important for network access. In these situations, one NAS could impersonate another by using a similar attack.
此攻击不是GSS-EAP特有的。通道绑定规范[RFC6677]描述了通道绑定对网络访问非常重要的一些情况。在这些情况下，一个NAS可以通过使用类似的攻击来模拟另一个NAS。
The previous section described an example of the server insertion attack. In this attack, one party adds a layer of tunneling such that from the perspective of the EAP peer, there are more methods than from the perspective of the EAP server. This attack is most beneficial when the party inserting the extra tunnel is a legitimate NAS, so mitigations need to be able to prevent a legitimate NAS from inappropriately adding a layer of tunneling. Some deployments utilize an intentional intermediary that adds an extra level of EAP tunneling between the peer and the EAP server; see Section 3.3 for a discussion.
上一节描述了服务器插入攻击的示例。在这种攻击中，一方添加了一层隧道，使得从EAP对等方的角度来看，有比从EAP服务器的角度来看更多的方法。当插入额外隧道的一方是合法NAS时，此攻击最为有利，因此需要采取缓解措施，以防止合法NAS不适当地添加隧道层。一些部署利用有意的中介，在对等方和EAP服务器之间添加额外级别的EAP隧道；有关讨论，请参见第3.3节。
For an inserted server attack to have value, the attacker needs to gain an advantage from its attack. An attacker could gain an advantage in the following ways:
要使插入的服务器攻击具有价值，攻击者需要从其攻击中获得优势。攻击者可以通过以下方式获得优势：
o The attacker can send information to a peer that the peer would trust from the EAP server but not the attacker. Examples of this include channel-binding responses.
o 攻击者可以从EAP服务器向对等方信任的对等方发送信息，但不会向攻击者发送。这方面的示例包括通道绑定响应。
o The peer sends information to the attacker that was intended for the EAP server. For example, the inner user identity may disclose privacy-sensitive information. The channel-binding request may disclose what service the peer wishes to connect to.
o 对等方向攻击者发送用于EAP服务器的信息。例如，内部用户身份可能泄露隐私敏感信息。信道绑定请求可能会披露对等方希望连接到的服务。
o The attacker may influence session parameters. For example, if the attacker can influence the MSK, then the attacker may be able to read or influence session traffic and mount an attack on the confidentiality or integrity of the resulting session.
o 攻击者可能会影响会话参数。例如，如果攻击者可以影响MSK，则攻击者可能能够读取或影响会话流量，并对生成会话的机密性或完整性发起攻击。
o An attacker may impact availability of the session. In practice though, an attacker that can mount a server insertion attack is likely to be able to impact availability in other ways.
o 攻击者可能会影响会话的可用性。但实际上，能够发起服务器插入攻击的攻击者可能会以其他方式影响可用性。
For this attack to be possible, the following conditions need to hold:
要使此攻击成为可能，需要满足以下条件：
1. The attacker needs to be able to establish a tunnel method with the peer over which the peer will authenticate.
1. 攻击者需要能够与对等方建立隧道方法，对等方将通过该方法进行身份验证。
2. The attacker needs to be able to respond to any inner authentication. For example, an attacker who is a legitimate NAS can forward the inner authentication over AAA towards the EAP server. Note that the inner authentication may not be EAP.
2. 攻击者需要能够响应任何内部身份验证。例如，合法NAS攻击者可以通过AAA将内部身份验证转发到EAP服务器。请注意，内部身份验证可能不是EAP。
3. Typically, the attacker needs to be able to complete the tunnel method after inner authentication. This may not be necessary if the attacker is gaining advantage from information sent by the peer over the tunnel.
3. 通常，攻击者需要能够在内部身份验证后完成隧道方法。如果攻击者从对等方通过隧道发送的信息中获取优势，则可能不需要这样做。
4. In some cases, the attacker may need to complete a Secure Association Protocol (SAP) or otherwise demonstrate knowledge of the MSK after the tunnel method successfully completes.
4. 在某些情况下，攻击者可能需要完成安全关联协议（SAP）或在隧道方法成功完成后演示对MSK的了解。
Attackers who are legitimate NASes are the primary focus of this memo. Previous work has provided mitigation against attackers who are not NASes; these mitigations are briefly discussed.
本备忘录主要关注的是合法的NASE攻击者。以前的工作已经针对非NASE攻击者提供了缓解措施；简要讨论了这些缓解措施。
If the peer confirms the identity of the party that the tunnel method is established with, the peer prevents the first condition (attacker establishing a tunnel method). Many tunnel methods rely on Transport Layer Security (TLS) [RFC5281] [TEAP]. The specifications for these methods tend to encourage or mandate certificate checking. If the TLS certificate is validated back to a trust anchor and the identity of the tunnel method server confirmed, then the first attack condition cannot be met.
如果对等方确认与之建立隧道方法的一方的身份，则对等方将阻止第一个条件（攻击者建立隧道方法）。许多隧道方法依赖于传输层安全（TLS）[RFC5281][TEAP]。这些方法的规范倾向于鼓励或强制进行证书检查。如果将TLS证书验证回信任锚，并且确认了隧道方法服务器的身份，则无法满足第一个攻击条件。
Many challenges make server authentication difficult. There is not an obvious name by which to identify a tunnel method server. It is not obvious where in the tunnel server certificate the name should be found. One particularly problematic practice is to use a certificate that names the host on which the tunnel server runs. Given such a name, it is very difficult for a peer to understand whether that server is intended to be a tunnel method server for the realm.
许多挑战使服务器身份验证变得困难。没有用于标识隧道方法服务器的明显名称。在隧道服务器证书中应该在哪里找到名称并不明显。一种特别有问题的做法是使用一个证书来命名运行隧道服务器的主机。给定这样一个名称，对等方很难理解该服务器是否打算成为该领域的隧道方法服务器。
It's not clear what trust anchors to use for tunnel servers. Using commercial Certificate Authorities (CAs) is probably undesirable because tunnel servers often operate in a closed community and are often provisioned with certificates issued by that community. Using commercial CAs can be particularly problematic with peers that support hostnames in certificates. Then anyone who can obtain a certificate for any host in the domain being contacted can impersonate a tunnel server.
目前还不清楚隧道服务器使用什么信任锚。使用商业证书颁发机构（CA）可能是不可取的，因为隧道服务器通常在一个封闭的社区中运行，并且通常由该社区颁发证书。对于在证书中支持主机名的对等方来说，使用商业CA可能特别有问题。然后，任何可以为正在联系的域中的任何主机获取证书的人都可以模拟隧道服务器。
These difficulties lead to poor deployment of good certificate validation. Many peers make it easy to disable certificate validation. Other peers validate back to trust anchors but do not check names of certificates. What name types are supported and what configuration is easy to perform depend significantly on the peer in question.
这些困难导致良好证书验证的部署不佳。许多对等方可以轻松禁用证书验证。其他对等方验证回信任锚，但不检查证书的名称。支持何种名称类型以及易于执行何种配置在很大程度上取决于所讨论的对等方。
Specifications also make the problem worse. For example, [RFC5281] indicates that the only impact of failing to perform certificate validation is that the inner method can be attacked. Administrators and implementors believing this claim may believe that protection from passive attacks is sufficient.
规范也使问题变得更糟。例如，[RFC5281]表示无法执行证书验证的唯一影响是内部方法可能受到攻击。相信这一说法的管理员和实现者可能认为，被动攻击的保护就足够了。
In addition, some deployments such as provisioning or strong inner methods are designed to work without certificate validation. Section 3.9 of the tunnel requirements document [RFC6678] discusses this requirement.
此外，某些部署（如资源调配或强内部方法）设计为在没有证书验证的情况下工作。隧道要求文件[RFC6678]第3.9节讨论了该要求。
Server policy can potentially prevent the second condition (attacker being able to respond to inner authentication) from being possible. If the server only performs a particular inner authentication within a tunnel, then the attacker cannot gain a response to the inner authentication without there being such a tunnel. The attacker may be able to add a second layer of tunnels; see Figure 3. The inner tunnel may limit the attacker's capabilities; for example, if channel binding is performed over tunnel t2 in the figure, then an attacker cannot observe or influence it.
服务器策略可能会阻止出现第二种情况（攻击者能够响应内部身份验证）。如果服务器仅在隧道内执行特定的内部身份验证，则攻击者无法在没有此类隧道的情况下获得对内部身份验证的响应。攻击者可以添加第二层隧道；参见图3。内部通道可能会限制攻击者的能力；例如，如果在图中的通道t2上执行通道绑定，则攻击者无法观察或影响它。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel t1 | | |
| | | |
|.......................................... .............|
| Tunnel t2 |
| |
| |
| Inner Method |
|<======================================================>|
| |
|.......................................... .............|
| | | |
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel t1 | | |
| | | |
|.......................................... .............|
| Tunnel t2 |
| |
| |
| Inner Method |
|<======================================================>|
| |
|.......................................... .............|
| | | |
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |
A tunnel t1 from the peer to the attacker contains a tunnel t2 from the peer to the home EAP server. Inside tunnel t2 is an inner authentication.
从对等方到攻击者的隧道t1包含从对等方到家庭EAP服务器的隧道t2。内部通道t2是内部身份验证。
Figure 3: Multiple Layered Tunnels
图3：多层隧道
Peer policy can be combined with this server policy to help prevent conditions 1 (attacker can establish a tunnel the peer will use) and 2 (attacker can respond to inner authentication). If the peer requires exactly one tunnel of a particular type and the EAP server only performs inner authentication over a tunnel of this type, then the attacker cannot establish tunnel t1 in the figure above. Configuring this peer policy may be more challenging than configuring policy on the EAP server.
对等策略可以与此服务器策略相结合，以帮助防止出现条件1（攻击者可以建立对等方将使用的隧道）和条件2（攻击者可以响应内部身份验证）。如果对等方只需要一个特定类型的隧道，而EAP服务器仅通过该类型的隧道执行内部身份验证，则攻击者无法建立上图中的隧道t1。配置此对等策略可能比在EAP服务器上配置策略更具挑战性。
An attacker may be able to mount a more traditional man-in-the-middle attack in this instance; see Figure 4. This policy on the peer and EAP server combined with a tunnel method that supports cryptographic binding will allow the EAP server to detect the attacker. This means the attacker cannot act as a legitimate NAS and, in particular, does not obtain the MSK. So, if the tunnel between the attacker and peer also requires cryptographic binding and if the cryptographic binding requires both the EAP server and peer to prove knowledge of the inner MSK, then the authentication will fail. If cryptographic binding is not performed, then this attack may succeed.
在这种情况下，攻击者可以发起更传统的中间人攻击；参见图4。对等和EAP服务器上的此策略与支持加密绑定的隧道方法相结合，将允许EAP服务器检测攻击者。这意味着攻击者无法充当合法的NAS，尤其是无法获得MSK。因此，如果攻击者和对等方之间的隧道也需要加密绑定，并且加密绑定需要EAP服务器和对等方证明内部MSK的知识，则身份验证将失败。如果未执行加密绑定，则此攻击可能会成功。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| Tunnel Establishment |
|<------------------->|<-------------------------------->|
|.....................|.................... .............|
| Tunnel t1 | Tunnel t2 |
| | |
| Tunneled | |
| Method | Tunneled Method |
|<===================>|<================================>|
| | |
|.....................|..................................|
| | | |
| Peer | | |
| Connected to | | |
| Attacker | | |
|<------------------->| | |
| | | |
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| Tunnel Establishment |
|<------------------->|<-------------------------------->|
|.....................|.................... .............|
| Tunnel t1 | Tunnel t2 |
| | |
| Tunneled | |
| Method | Tunneled Method |
|<===================>|<================================>|
| | |
|.....................|..................................|
| | | |
| Peer | | |
| Connected to | | |
| Attacker | | |
|<------------------->| | |
| | | |
A tunnel t1 extends from the peer to the attacker. A tunnel t2 extends from the attacker to the home EAP server. An inner EAP authentication is forwarded unmodified by the attacker from tunnel t1 to tunnel t2. The attacker can observe this inner authentication.
隧道t1从对等方延伸到攻击者。隧道t2从攻击者延伸到主EAP服务器。攻击者未经修改就将内部EAP身份验证从隧道t1转发到隧道t2。攻击者可以观察此内部身份验证。
Figure 4: A Traditional Man-in-the-Middle Attack
图4：传统的中间人攻击
Cryptographic binding is only a valuable component of a defense if the inner authentication is a key-deriving EAP method. Most tunnel methods also support non-EAP inner authentication such as Microsoft CHAP version 2 [RFC2759]. This may undermine cryptographic binding in a number of ways. An attacker may be able to convert an EAP method into a compatible non-EAP form of the same credential to suppress cryptographic binding. In addition, an inner authentication may be available through an entirely different means. For example, a Lightweight Directory Access Protocol [RFC4510] or other directory server may provide an attacker a way to get challenges and provide responses for an authentication mechanism entirely outside of the AAA/EAP context. An attacker with this capability may be able to get around server policy requiring an inner authentication be used only in a given type of tunnel.
如果内部身份验证是密钥派生EAP方法，则加密绑定只是防御的一个有价值的组成部分。大多数隧道方法还支持非EAP内部身份验证，如Microsoft CHAP版本2[RFC2759]。这可能会以多种方式破坏加密绑定。攻击者可以将EAP方法转换为同一凭证的兼容非EAP形式，以抑制加密绑定。此外，内部认证可以通过完全不同的方式提供。例如，轻量级目录访问协议[RFC4510]或其他目录服务器可能为攻击者提供一种获取挑战的方法，并为完全不在AAA/EAP上下文中的身份验证机制提供响应。具有此功能的攻击者可能能够绕过服务器策略，该策略要求仅在给定类型的隧道中使用内部身份验证。
To recap, the following policy conditions appear sufficient to prevent a server insertion attack:
总而言之，以下策略条件似乎足以防止服务器插入攻击：
1. Peer and EAP server require a particular inner EAP method used within a particular tunnel method.
1. 对等和EAP服务器需要在特定隧道方法中使用特定的内部EAP方法。
2. The inner EAP method's authentication is only available within the tunnel and through no other means including non-EAP means.
2. 内部EAP方法的身份验证仅在隧道内可用，不通过其他方式（包括非EAP方式）使用。
3. The inner EAP method produces a key.
3. 内部EAP方法生成密钥。
4. The tunnel method uses cryptographic binding and the peer requires the other end of the tunnel to prove knowledge of the inner MSK.
4. 隧道方法使用加密绑定，对等方要求隧道的另一端证明内部MSK的知识。
The most advanced examples of cryptographic binding today work at two levels. First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined with some outer key material to form the tunnel's EAP keys. This is sufficient to detect an inserted server or peer provided that the attacker does not learn the inner MSK. This seems sufficient to defend against attackers who cannot act as a legitimate NAS.
当今最先进的加密绑定示例在两个级别上工作。首先，服务器和对等方相互证明内部MSK的知识。然后，将内部MSK与一些外部密钥材料组合以形成隧道的EAP密钥。只要攻击者不了解内部MSK，这就足以检测插入的服务器或对等服务器。这似乎足以抵御无法充当合法NAS的攻击者。
The definition of cryptographic binding in [RFC3748] does not require these steps. To meet that definition, it would be sufficient for a peer to prove knowledge of the inner key to the EAP server. This would open some additional attacks. For example, by indicating success, an attacker might be able to mask a cryptographic binding failure. The peer is unlikely to be able to detect the failure, especially if only the tunnel key material is used for the final keys.
[RFC3748]中加密绑定的定义不需要这些步骤。为了满足该定义，对等方证明了解EAP服务器的内部密钥就足够了。这将引发一些额外的攻击。例如，通过指示成功，攻击者可能能够掩盖加密绑定失败。对等方不太可能检测到故障，尤其是在仅将隧道密钥材料用于最终密钥的情况下。
As discussed in the previous section, cryptographic binding is only effective when the inner method is EAP.
如前一节所述，加密绑定仅在内部方法为EAP时有效。
Cryptographic binding can be strengthened when the inner EAP method supports an Extended Master Session Key (EMSK). The EMSK is never disclosed to any party other than the EAP server or peer, so even a legitimate NAS cannot learn the EMSK. So, if the same techniques currently applied to the inner MSK are applied to the inner EMSK, then condition 3 (completing tunnel authentication) will not hold because the attacker cannot complete this new form of cryptographic binding. This does not prevent the attacker from learning
当内部EAP方法支持扩展主会话密钥（EMSK）时，可以加强加密绑定。EMSK从不向EAP服务器或对等方以外的任何一方公开，因此即使是合法的NAS也无法了解EMSK。因此，如果将当前应用于内部MSK的相同技术应用于内部EMSK，则条件3（完成隧道身份验证）将不成立，因为攻击者无法完成这种新形式的加密绑定。这不会阻止攻击者学习
confidential information such as a channel-binding request sent over the tunnel prior to cryptographic binding.
机密信息，例如加密绑定之前通过隧道发送的通道绑定请求。
Obviously, as with all forms of cryptographic binding, cryptographic binding only works for key-deriving inner EAP methods. Also, some deployments (see Section 3.3) insert intermediates between the peer and the EAP server. EMSK-based cryptographic binding is incompatible with these deployments because the intermediate cannot learn the EMSK.
显然，与所有形式的加密绑定一样，加密绑定只适用于密钥派生的内部EAP方法。此外，一些部署（请参见第3.3节）在对等服务器和EAP服务器之间插入中间层。基于EMSK的加密绑定与这些部署不兼容，因为中间层无法学习EMSK。
Formally, EMSK-based cryptographic binding is a security claim for EAP tunnel methods that holds when:
形式上，基于EMSK的加密绑定是EAP隧道方法的安全声明，在以下情况下有效：
1. The peer proves to the server that the peer participating in any inner method is the same as the peer for the tunnel method.
1. 对等方向服务器证明参与任何内部方法的对等方与隧道方法的对等方相同。
2. The server proves to the peer that the server for any inner method is the same as the server for the tunnel method.
2. 服务器向对等方证明，任何内部方法的服务器都与隧道方法的服务器相同。
3. The MSK and EMSK for the tunnel depend on the MSK and EMSK of inner methods.
3. 隧道的MSK和EMSK取决于内部方法的MSK和EMSK。
4. The peer MUST be able to force the authentication to fail if the peer is unable to confirm the identity of the server.
4. 如果对等方无法确认服务器的身份，则对等方必须能够强制身份验证失败。
5. Proofs offered need to be secure even against attackers who know the inner method MSK.
5. 提供的证据需要安全，即使攻击者知道内部方法MSK。
If EMSK-based cryptographic binding is not an optional facility, it provides a strong defense against server insertion attacks and other tunnel man-in-the-middle (MITM) attacks for inner methods that provide an EMSK. The strength of the defense is dependent on the strength of the inner method. EMSK-based cryptographic binding MAY be provided as an optional facility. The value of EMSK-based cryptographic binding is reduced somewhat if it is an optional feature. It permits configurations where a peer uses other means to authenticate the server if the peer has sufficient information configured to validate the certificate and identity of an EAP server while using EMSK-based cryptographic binding for deployments where that is possible.
如果基于EMSK的加密绑定不是可选功能，那么它可以为提供EMSK的内部方法提供强大的防御，以抵御服务器插入攻击和其他中间人隧道（MITM）攻击。防御的强度取决于内部方法的强度。基于EMSK的加密绑定可以作为可选功能提供。如果是可选功能，则基于EMSK的加密绑定的值会有所降低。如果对等方拥有足够的信息来验证EAP服务器的证书和身份，并且在可能的情况下使用基于EMSK的加密绑定进行部署，则允许配置对等方使用其他方式对服务器进行身份验证。
If EMSK-based cryptographic binding is an optional facility, the negotiation of whether to use it MUST be protected by the inner MSK or EMSK. Typically, the MSK will be used because the primary advantage of making EMSK-based cryptographic binding an optional facility is to permit intermediates who know only the MSK to decline to use EMSK-based cryptographic binding. The peer MUST have an
如果基于EMSK的加密绑定是可选功能，那么是否使用它的协商必须受到内部MSK或EMSK的保护。通常，将使用MSK，因为使基于EMSK的加密绑定成为可选工具的主要优点是允许仅知道MSK的中间人拒绝使用基于EMSK的加密绑定。同级必须有一个
opportunity to fail the authentication after the server declines to use EMSK-based cryptographic binding.
服务器拒绝使用基于EMSK的加密绑定后身份验证失败的机会。
Another defense against tunnel MITM attacks, potentially including server insertion attacks, is to use a different credential for tunneled methods from other authentications. This may prevent the second condition (attacker being able to respond to inner authentication) from taking place. For example, if key material from the tunnel is mixed into a shared secret or password that is the basis of the inner authentication, then the second condition will not hold unless the attacker already knows this shared secret. The advantage of this approach is that it seems to be the only way to strengthen non-EAP inner authentications within a tunnel.
针对隧道MITM攻击（可能包括服务器插入攻击）的另一种防御措施是为隧道方法使用不同于其他身份验证的凭据。这可以防止发生第二种情况（攻击者能够响应内部身份验证）。例如，如果来自隧道的密钥材料混合到作为内部身份验证基础的共享机密或密码中，则第二个条件将不成立，除非攻击者已经知道该共享机密。这种方法的优点是，它似乎是增强隧道内非EAP内部身份验证的唯一方法。
There are several disadvantages. Choosing a function to mix the tunnel key material into the inner authentication will be very dependent on the inner authentication. In addition, this appears to involve a layering violation. However, exploring the possibility of providing a solution like this seems important because it can function for inner authentications where no other approach will work.
有几个缺点。选择一个函数将隧道密钥材料混合到内部身份验证中将非常依赖于内部身份验证。此外，这似乎涉及分层违规。然而，探索提供这样一个解决方案的可能性似乎很重要，因为它可以在没有其他方法可以工作的情况下用于内部身份验证。
Some deployments introduce a tunnel server separate from the EAP server; see [RFC5281] for an example of this style of deployment. The tunnel server is between the NAS and the EAP server. The only difference between such an intermediate and an attacker is that the intermediate provides some function valuable to the peer or EAP server and that the intermediate is trusted by the peer. If peers are configured with the necessary information to validate certificates of these intermediates and to confirm their identity, then tunnel MITM and inserted server attacks can be defended against. The intermediates need to be trusted with regard to channel binding and other services that the peer depends on.
一些部署引入了一个独立于EAP服务器的隧道服务器；有关这种部署方式的示例，请参见[RFC5281]。隧道服务器位于NAS和EAP服务器之间。这种中间层与攻击者之间的唯一区别在于，中间层提供了对对等方或EAP服务器有价值的功能，并且中间层受到对等方的信任。如果为对等方配置了必要的信息以验证这些中间方的证书并确认其身份，则可以防御隧道MITM和插入服务器攻击。在通道绑定和对等方依赖的其他服务方面，需要信任中间方。
Support for trusted intermediates is not a requirement according to the tunnel method requirements.
根据隧道方法要求，对可信中间产物的支持不是一项要求。
It seems reasonable to treat trusted intermediates as a special case if they are supported and to focus on the security of the case where there are not intermediates in the tunnel as the common case.
如果受信任的中间人得到支持，则将其视为特殊情况，并将重点放在隧道中没有中间人的情况的安全性上，这似乎是合理的。
The Tunnel EAP method [TEAP] should gain support for EMSK-based cryptographic binding.
隧道EAP方法[TEAP]应获得对基于EMSK的加密绑定的支持。
As channel-binding support is added to existing EAP methods, EMSK-based cryptographic binding or some other form of cryptographic binding that protects against server insertion should also be added to these methods. Mutual cryptographic binding may also be valuable when other services are added to EAP methods that may require a peer trust an EAP server.
随着通道绑定支持添加到现有EAP方法中，基于EMSK的加密绑定或防止服务器插入的其他形式的加密绑定也应添加到这些方法中。当向EAP方法添加其他服务时，相互加密绑定也可能很有价值，这些服务可能需要EAP服务器的对等信任。
Today, mutual authentication in EAP is thought of as a security claim about a method. However, in practice, it's an attribute of a particular exchange. Mutual authentication can be obtained via checking certificates, through mutual cryptographic binding, or in very controlled cases through carefully crafted peer and server policy combined with existing cryptographic binding. Using services like channel binding that involve the peer trusting the EAP server should require mutual authentication be present in the session.
今天，EAP中的相互认证被认为是关于方法的安全声明。然而，在实践中，它是特定交换的属性。可以通过检查证书、通过相互加密绑定或在非常受控的情况下通过精心编制的对等和服务器策略以及现有加密绑定来获得相互身份验证。使用涉及对等方信任EAP服务器的通道绑定等服务时，会话中应该存在相互身份验证。
To accomplish this, implementations including channel binding or other peer services MUST track whether mutual authentication has happened. They SHOULD default to not permitting these peer services unless mutual authentication has happened. They SHOULD support a configuration where the peer fails to authenticate unless mutual authentication takes place. Discussion of whether this configuration should be recommended as a default is required.
为了实现这一点，包括通道绑定或其他对等服务在内的实现必须跟踪是否发生了相互身份验证。他们应该默认不允许这些对等服务，除非发生了相互身份验证。它们应该支持这样一种配置：除非发生相互身份验证，否则对等方无法进行身份验证。需要讨论是否建议将此配置作为默认配置。
The Tunnel EAP method [TEAP] should permit peers to force authentication failure if they are unable to perform mutual authentication. The protocol should permit this to be deferred until after mutual cryptographic binding is considered.
隧道EAP方法[TEAP]应允许对等方在无法执行相互认证时强制认证失败。协议应允许将此延迟到考虑相互加密绑定之后。
Services such as channel binding should be deferred until after cryptographic binding or mutual cryptographic binding.
诸如通道绑定之类的服务应该推迟到加密绑定或相互加密绑定之后。
An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how mutual authentication is achieved, only some of these parties may have confidence in it. For example, if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the
当隧道方法对多方进行身份验证（例如对EAP服务器的对等机器和对等用户进行身份验证）时，会产生额外的复杂性。根据如何实现相互认证，只有其中一些方可能对其有信心。例如，如果使用强共享机密对用户和EAP服务器进行相互认证，则如果
machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties that have achieved mutual authentication need to be considered when evaluating whether to use peer services.
计算机无法信任用户不向攻击者泄露共享机密。在这些情况下，在评估是否使用对等服务时，需要考虑已实现相互认证的各方。
Work is required to promote interoperable deployment of server certificate validation by peers. A standard way to name EAP servers is required. Recommendations for what name forms peers should implement is required.
需要开展工作，以促进对等方可互操作地部署服务器证书验证。需要一种命名EAP服务器的标准方法。需要对同行应实施的名称表单提出建议。
More consideration of the proposal to mix some key material into inner authentications is desired. Currently, the proposal is under-defined and fairly invasive. Are there versions of this proposal that would be valuable? Is there a way to view it as something more abstract so that it does not involve a combinatorial explosion as a result of considering specific tunnels and inner methods?
需要更多地考虑将一些关键材料混合到内部认证中的建议。目前，该提案定义不足，具有相当大的侵入性。这个提议有没有有价值的版本？有没有办法把它看成更抽象的东西，这样它就不会因为考虑了特定的隧道和内部方法而涉及到组合爆炸？
The Tunnel EAP method [TEAP] provides several features designed to limit man-in-the-middle vulnerabilities and provide a safe platform for peer services.
隧道EAP方法[TEAP]提供了一些功能，旨在限制中间人漏洞，并为对等服务提供安全平台。
TEAP implementations support checking the Network Access Identifier (NAI) realm portion against a DNS subjectAlternativeName in the certificate of the TEAP server. TEAP supports EMSK-based cryptographic binding as a way to achieve mutual cryptographic binding. TEAP also supports MSK-based cryptographic binding for cases where the EMSK is not available; this cryptographic binding does not provide sufficient assurance for peer services. TEAP provides recommendations on conditions that need to be met prior to using peer services. These recommendations explicitly address when the MSK-based cryptographic binding is sufficient and when EMSK-based cryptographic binding is required. TEAP meets the recommendations for implementations outlined in this memo.
TEAP实现支持根据TEAP服务器证书中的DNS subjectAlternativeName检查网络访问标识符（NAI）领域部分。TEAP支持基于EMSK的加密绑定，作为实现相互加密绑定的一种方式。TEAP还支持在EMSK不可用的情况下基于MSK的加密绑定；此加密绑定不能为对等服务提供足够的保证。技经评估组就使用对等服务之前需要满足的条件提出了建议。这些建议明确指出了基于MSK的加密绑定何时足够以及何时需要基于EMSK的加密绑定。技经评估组符合本备忘录概述的实施建议。
EAP-FAST [RFC4851] provides MSK-based cryptographic binding. EAP-FAST requires that server certificates be validated. However, no guidance is given on how servers are named, so the specification does not provide enough guidance to interoperably enforce this requirement.
EAP-FAST[RFC4851]提供基于MSK的加密绑定。EAP-FAST要求验证服务器证书。但是，没有给出关于如何命名服务器的指导，因此该规范没有提供足够的指导来以互操作方式强制执行此要求。
EAP-FAST does not support channel binding or other peer services, although the protocol is extensible and TLVs could be defined for peer services. If the certificates are actually validated and names checked, then EAP-FAST would provide security guarantees sufficient to use these peer services. However, the cryptographic binding in EAP-FAST is not strong enough to secure peer services if the server certificate is not validated and name checked.
EAP-FAST不支持通道绑定或其他对等服务，尽管该协议是可扩展的，并且可以为对等服务定义TLV。如果证书被实际验证并检查了名称，那么EAP-FAST将提供足够的安全保证来使用这些对等服务。但是，如果服务器证书未经验证和名称检查，EAP-FAST中的加密绑定不足以保护对等服务。
The EAP Tunneled Transport Layer Security Version 0 (EAP-TTLS) [RFC5281] does not support cryptographic binding. It also does not support peer services such as channel binding although they could be added using extensible AVPs.
EAP隧道传输层安全版本0（EAP-TTLS）[RFC5281]不支持加密绑定。它也不支持对等服务，例如通道绑定，尽管它们可以使用可扩展的AVP添加。
EAP-TTLS recommends that implementations SHOULD validate certificates but gives no guidance on how to handle naming. Even if certificates are validated, EAP-TTLS is not generally suited to peer services. As an example, EAP-TTLS does not include protected result indication. So, an unprotected EAP success packet can end the authentication. In addition, it is difficult for a peer to request services such as channel binding because the server ends the authentication as soon as authentication is successful.
EAP-TTLS建议实现应该验证证书，但没有提供如何处理命名的指导。即使证书经过验证，EAP-TTLS通常也不适用于对等服务。例如，EAP-TTLS不包括受保护的结果指示。因此，未受保护的EAP成功数据包可以结束身份验证。此外，对等请求服务（如通道绑定）很难实现，因为一旦身份验证成功，服务器就会结束身份验证。
A variety of extensions, including EAP-TTLS version 1, improve some of these concerns. Specification and implementation issues complicate analysis of these extensions. As an example, most implementations can be tricked into using EAP-TTLS version 0.
各种扩展，包括EAP-TTLS版本1，改善了其中一些问题。规范和实现问题使这些扩展的分析变得复杂。例如，大多数实现都可能被骗使用EAP-TTLS版本0。
This memo examines the security considerations of providing new classes of service within EAP methods. Traditionally, the primary focus of EAP is authenticating the peer to the network. However, as the peer places trust in the EAP server, mutual authentication becomes more important. This memo examines the security of mutual authentication for EAP tunnel methods.
本备忘录审查了在EAP方法中提供新服务类的安全注意事项。传统上，EAP的主要重点是对网络中的对等方进行身份验证。然而，当对等方信任EAP服务器时，相互认证变得更加重要。本备忘录检查EAP隧道方法的相互身份验证的安全性。
The authors would like to thank Alan DeKok for helping to explore these attacks. Alan focused the discussion on the importance of inner authentications that are not EAP and proposed mixing in key material as a way to resolve these authentications.
作者要感谢Alan DeKok帮助探索这些攻击。Alan重点讨论了非EAP的内部身份验证的重要性，并建议将关键材料中的混合作为解决这些身份验证的方法。
Jari Arkko provided a review of the attack and valuable context on past efforts in developing cryptographic binding.
Jari Arkko回顾了这次攻击，并回顾了过去在开发加密绑定方面所做的努力。
Sam Hartman's and Margaret Wasserman's work on this memo is funded by Huawei.
Sam Hartman和Margaret Wasserman在这份备忘录上的工作由华为出资。
[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月。
[GSS-EAP] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", Work in Progress, August 2012.
[GSS-EAP]Hartman，S.和J.Howlett，“可扩展身份验证协议的GSS-API机制”，正在进行的工作，2012年8月。
[PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, March 2013.
[PT-EAP]Cam Winget，N.和P.Sangster，“PT-EAP：EAP隧道方法的姿态传输（PT）协议”，正在进行的工作，2013年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]Zorn，G.，“微软PPP CHAP扩展，第2版”，RFC 2759，2000年1月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展认证协议方法（EAP-FAST）的灵活认证”，RFC 4851，2007年5月。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5281]Funk，P.和S.Blake Wilson，“可扩展认证协议隧道传输层安全认证协议版本0（EAP-TTLSv0）”，RFC 52812008年8月。
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677]Hartman，S.，Clancy，T.，和K.Hoeper，“可扩展身份验证协议（EAP）方法的通道绑定支持”，RFC 6677，2012年7月。
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, "Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method", RFC 6678, July 2012.
[RFC6678]Hoeper，K.，Hanna，S.，Zhou，H.，和J.Salowey，“基于隧道的可扩展认证协议（EAP）方法的要求”，RFC 6678，2012年7月。
[TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel EAP Method (TEAP) Version 1", Work in Progress, September 2013.
[TEAP]Zhou，H.，Cam Winget，N.，Salowey，J.，和S.Hanna，“隧道EAP方法（TEAP）第1版”，正在进行的工作，2013年9月。
[TUNNEL-MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication Protocols", Cryptology ePrint Archive: Report 2002/163, November 2002.
[TUNNEL-MITM]Asokan，N.，Niemi，V.，和K.Nyberg，“隧道认证协议中的中间人”，密码学ePrint档案：报告2002/163，2002年11月。
Authors' Addresses
作者地址
Sam Hartman Painless Security
山姆·哈特曼无痛安全
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Margaret Wasserman Painless Security
玛格丽特·沃瑟曼无痛安全
EMail: mrw@painless-security.com
URI: http://www.painless-security.com/
EMail: mrw@painless-security.com
URI: http://www.painless-security.com/
Dacheng Zhang Huawei
张大成华为
EMail: zhangdacheng@huawei.com
EMail: zhangdacheng@huawei.com