Internet Engineering Task Force (IETF) K. Hoeper
Request for Comments: 6678 Motorola Solutions, Inc.
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper Networks
H. Zhou
J. Salowey, Ed.
Cisco Systems, Inc.
July 2012
Internet Engineering Task Force (IETF) K. Hoeper
Request for Comments: 6678 Motorola Solutions, Inc.
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper Networks
H. Zhou
J. Salowey, Ed.
Cisco Systems, Inc.
July 2012
Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
基于隧道的可扩展身份验证协议（EAP）方法的要求
Abstract
摘要
This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes.
本备忘录定义了基于隧道的可扩展身份验证协议（EAP）方法的要求。此隧道方法将使用传输层安全性（TLS）来建立安全隧道。该隧道将为密码认证、EAP认证和其他目的的附加数据传输提供支持。
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/rfc6678.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6678.
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第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. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 5
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 6
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 7
3.7. Client Authentication during Tunnel Establishment . . . . 7
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Certificate-Less Authentication and Generic EAP Method
Extension . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 11
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 5
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 6
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 7
3.7. Client Authentication during Tunnel Establishment . . . . 7
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Certificate-Less Authentication and Generic EAP Method
Extension . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 11
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor-Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 13
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
4.5.1.3. Server Certificate Revocation Checking . . . . . . 14
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
4.6. Requirements Associated with Carrying EAP Methods . . . . 15
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
4.6.4. Peer-Initiated EAP Authentication . . . . . . . . . . 17
4.6.5. Method Metadata . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
5.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
5.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
5.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . . 21
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor-Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 13
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
4.5.1.3. Server Certificate Revocation Checking . . . . . . 14
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
4.6. Requirements Associated with Carrying EAP Methods . . . . 15
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
4.6.4. Peer-Initiated EAP Authentication . . . . . . . . . . 17
4.6.5. Method Metadata . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
5.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
5.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
5.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . . 21
An Extensible Authentication Protocol (EAP) tunnel method is an EAP method that establishes a secure tunnel and executes other EAP methods under the protection of that secure tunnel. An EAP tunnel method can be used in any lower-layer protocol that supports EAP authentication. There are several existing EAP tunnel methods that use Transport Layer Security (TLS) to establish the secure tunnel. EAP methods supporting this include Protected EAP [PEAP], Tunneled Transport Layer Security EAP (TTLS) [RFC5281] and EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. In general, this has worked well so there is consensus to continue to use TLS as the basis for a tunnel method. There have been various reasons for employing a protected tunnel for EAP processes. They include protecting weak authentication exchanges, such as username and password. In addition, a protected tunnel can provide means to provide peer identity protection and EAP method chaining. Finally, systems have found it useful to transport additional types of data within the protected tunnel.
可扩展身份验证协议（EAP）隧道方法是建立安全隧道并在该安全隧道的保护下执行其他EAP方法的EAP方法。EAP隧道方法可用于支持EAP身份验证的任何较低层协议。有几种现有的EAP隧道方法使用传输层安全性（TLS）来建立安全隧道。支持这一点的EAP方法包括受保护的EAP[PEAP]、隧道传输层安全EAP（TTLS）[RFC5281]和通过安全隧道的EAP灵活身份验证（EAP-FAST）[RFC4851]。总的来说，这一方法效果良好，因此大家一致同意继续使用TLS作为隧道法的基础。EAP工艺采用受保护隧道有多种原因。它们包括保护弱身份验证交换，如用户名和密码。此外，受保护的隧道可以提供提供对等身份保护和EAP方法链接的方法。最后，系统发现在受保护的隧道内传输其他类型的数据非常有用。
This document describes the requirements for a EAP tunnel method as well as for a password protocol supporting legacy password verification within the tunnel method.
本文件描述了EAP隧道方法以及支持隧道方法内遗留密码验证的密码协议的要求。
Use of each capitalized word within a sentence or phrase carries the following meaning during the EAP Method Update (EMU) WG's method selection process:
在EAP方法更新（EMU）工作组的方法选择过程中，在句子或短语中使用每个大写单词具有以下含义：
MUST - indicates an absolute requirement
必须-表示绝对要求
MUST NOT - indicates something absolutely prohibited
不得-表示绝对禁止的内容
SHOULD - indicates a strong recommendation of a desired result
应该-表示对预期结果的强烈建议
SHOULD NOT - indicates a strong recommendation against a result
不应该-表示强烈反对结果的建议
MAY - indicates a willingness to allow an optional outcome
可能-表示允许可选结果的意愿
Lowercase uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" carry their normal meaning and are not subject to these definitions.
“必须”、“不得”、“应该”、“不应该”和“可以”的小写用法具有其正常含义，不受这些定义的约束。
To motivate and explain the requirements in this document, a representative set of use cases for the EAP tunnel method are supplied here. It is mandatory for a candidate tunnel method to support all of the use cases that are marked below as "MUST".
为了激发和解释本文件中的要求，这里提供了EAP隧道方法的一组代表性用例。候选隧道方法必须支持下面标记为“必须”的所有用例。
Many legacy systems only support user authentication with passwords. Some of these systems require transport of the actual username and password to the authentication server. This is true for systems where the authentication server does not have access to the cleartext password or a consistent transform of the cleartext password. Examples of such systems are some one-time password (OTP) systems and other systems where the username and password are submitted to an external party for validation. The tunnel method MUST support transporting cleartext username and password to the EAP server. It MUST NOT reveal information about the username and password to parties in the communication path between the peer and the EAP server. The advantage any attacker gains against the tunnel method when employing a username and password for authentication MUST be through interaction and not computation. The tunnel MUST support protection from man-in-the-middle attacks. The combination of the tunnel authentication and password authentication MUST enable mutual authentication.
许多传统系统仅支持使用密码进行用户身份验证。其中一些系统需要将实际用户名和密码传输到身份验证服务器。对于身份验证服务器无法访问明文密码或对明文密码进行一致转换的系统来说，这是正确的。此类系统的示例包括一些一次性密码（OTP）系统和将用户名和密码提交给外部方进行验证的其他系统。隧道方法必须支持将明文用户名和密码传输到EAP服务器。不得向对等方和EAP服务器之间通信路径中的各方透露有关用户名和密码的信息。当使用用户名和密码进行身份验证时，任何攻击者都必须通过交互而不是计算来获得对抗隧道方法的优势。隧道必须支持防止中间人攻击。隧道身份验证和密码身份验证的组合必须支持相互身份验证。
Since EAP authentication occurs before network access is granted the tunnel method SHOULD enable an inner exchange to provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems.
由于EAP身份验证发生在授予网络访问权之前，因此隧道方法应允许内部交换机提供对最小密码管理任务的支持，包括一些系统所需的密码更改、“新PIN模式”和“下一个令牌模式”。
Some existing EAP methods have vulnerabilities that could be eliminated or reduced by running them inside a protected tunnel. For example, an EAP-MD5 method does not provide mutual authentication or protection from dictionary attacks. Without extra protection, EAP tunnel methods are vulnerable to a special type of tunnel man-in-the-middle (MitM) attack [TUNNEL-MITM]. This attack is referred to as "tunnel MitM attack" in the remainder of this document. The additional protection needed to thwart tunnel MitM attacks depends on the inner method executed within the tunnel. When weak methods are used, these attacks can be mitigated via security policies that require the method to be used only within a tunnel. On the other hand, a technical solution (so-called cryptographic bindings) can be used whenever the inner method derives key material and is not susceptible to attacks outside a tunnel. Only the latter mitigation
一些现有的EAP方法存在漏洞，可以通过在受保护的隧道中运行来消除或减少这些漏洞。例如，EAP-MD5方法不提供相互身份验证或防止字典攻击。如果没有额外的保护，EAP隧道方法容易受到一种特殊类型的中间人（MitM）攻击[tunnel-MitM]。在本文档的其余部分中，此攻击称为“隧道MitM攻击”。阻止隧道MitM攻击所需的额外保护取决于隧道内执行的内部方法。当使用弱方法时，可以通过要求仅在隧道内使用该方法的安全策略来缓解这些攻击。另一方面，只要内部方法派生密钥材料并且不易受到隧道外攻击，就可以使用技术解决方案（所谓的加密绑定）。只有后一种缓解措施
technique can be made an actual requirement for EAP tunnel methods (see Section 4.6.3), while security policies are outside the scope of this requirement document. Please refer to the NIST "Recommendation for EAP Methods Used in Wireless Network Access Authentication" [NIST-SP-800-120] and [LCN-2010] for a discussion on security policies and complete solutions for thwarting tunnel MitM attacks.
该技术可作为EAP隧道方法的实际要求（见第4.6.3节），而安全策略不在本要求文件的范围内。请参考NIST“无线网络接入认证中使用的EAP方法建议”[NIST-SP-800-120]和[LCN-2010]，以了解有关挫败隧道MitM攻击的安全策略和完整解决方案的讨论。
The tunnel method MUST support protection of weak EAP methods. Cryptographic protection from tunnel MitM attacks MUST be provided for all key-generating methods. In combination with an appropriate security policy this will thwart MitM attacks against inner methods.
隧道方法必须支持弱EAP方法的保护。必须为所有密钥生成方法提供针对隧道MitM攻击的加密保护。结合适当的安全策略，这将阻止针对内部方法的MitM攻击。
Several circumstances are best addressed by using chained EAP methods. For example, it may be desirable to authenticate the user and also authenticate the device being used. However, chained EAP methods from different conversations can be redirected into the same conversation by an attacker giving the authenticator the impression that both conversations terminate at the same endpoint. Cryptographic binding can be used to bind the results of chained key-generating methods together or to an encompassing tunnel.
有几种情况最好使用链式EAP方法解决。例如，可能希望对用户进行认证，并且还对正在使用的设备进行认证。但是，攻击者可以将来自不同会话的链接EAP方法重定向到同一会话中，从而给认证者留下两个会话在同一端点终止的印象。加密绑定可用于将链式密钥生成方法的结果绑定在一起或绑定到包含的隧道。
The tunnel method MUST support chained EAP methods while including protection against attacks on method chaining.
隧道方法必须支持链式EAP方法，同时包括对方法链式攻击的保护。
When performing an EAP authentication, the peer may want to protect its identity and only disclose it to a trusted EAP server. This helps to maintain peer privacy.
在执行EAP身份验证时，对等方可能希望保护其身份，并且只将其披露给受信任的EAP服务器。这有助于维护同伴隐私。
The tunnel method MUST support identity protection, therefore the identity of the peer used for authentication purposes MUST NOT be obtainable by any entity other than the EAP server terminating the tunnel method. Peer identity protection provided by the tunnel method applies to the identities that are specific to the tunnel method and inner method being used. In a roaming scenario, note that the peer may need to expose the realm portion of the EAP outer identity in the Network Access Identifier (NAI) [RFC4282] in order to reach the appropriate authentication server.
隧道方法必须支持身份保护，因此，除了终止隧道方法的EAP服务器之外，任何实体都不能获取用于身份验证目的的对等方的身份。隧道方法提供的对等身份保护适用于特定于所使用的隧道方法和内部方法的身份。在漫游场景中，请注意，对等方可能需要在网络接入标识符（NAI）[RFC4282]中公开EAP外部标识的领域部分，以便到达适当的认证服务器。
When network service is provided, it is sometimes desirable for a user to gain network access in order to access limited services for emergency communication or troubleshooting information. To avoid eavesdropping, it's best to negotiate link-layer security as with any other authentication.
当提供网络服务时，用户有时希望获得网络访问权，以便访问用于紧急通信或故障排除信息的有限服务。为了避免窃听，最好与任何其他身份验证一样协商链路层安全性。
Therefore, the tunnel method SHOULD allow anonymous peers or server-only authentication, while still deriving keys that can be used for link-layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client.
因此，隧道方法应允许匿名对等方或仅限服务器的身份验证，同时仍然派生可用于链路层安全的密钥。隧道方法还允许绕过客户端上的服务器身份验证处理。
Foregoing user or server authentication increases the chance of man-in-the-middle and other types of attacks that can compromise the derived keys used for link-layer security. Therefore, passwords and other sensitive information MUST NOT be disclosed to an unauthenticated server, or to a server that is not authorized to authenticate the user.
前面提到的用户或服务器身份验证增加了中间人攻击和其他类型攻击的机会，这些攻击可能会危及用于链路层安全的派生密钥。因此，不得将密码和其他敏感信息披露给未经验证的服务器或未经授权对用户进行身份验证的服务器。
The Network Endpoint Assessment (NEA) protocols and reference model described in [RFC5209] provide a standard way to check the health ("posture") of a device at or after the time it connects to a network. If the device does not comply with the network's requirements, it can be denied access to the network or granted limited access to remediate itself. EAP is a convenient place for conducting an NEA exchange.
[RFC5209]中描述的网络端点评估（NEA）协议和参考模型提供了在设备连接到网络时或之后检查设备健康（“姿势”）的标准方法。如果设备不符合网络要求，则可以拒绝其访问网络或授予其有限的访问权限以进行自我补救。EAP是进行NEA交换的便利场所。
The tunnel method SHOULD support carrying NEA protocols such as a Posture Broker protocol compatible with Trusted Network Connect (PB-TNC) [RFC5793]. Depending on the specifics of the tunnel method, these protocols may be required to be carried in an EAP method.
隧道方法应支持承载NEA协议，例如与可信网络连接（PB-TNC）兼容的姿态代理协议[RFC5793]。根据隧道方法的具体情况，这些协议可能需要在EAP方法中执行。
In some cases, the peer will have credentials that allow it to authenticate during tunnel establishment. These credentials may only partially authenticate the identity of the peer and additional authentication may be required inside the tunnel. For example, a communication device may be authenticated during tunnel establishment; in addition, user authentication may be required to satisfy authentication policy. The tunnel method MUST be capable of providing client-side authentication during tunnel establishment.
在某些情况下，对等方将具有允许其在隧道建立期间进行身份验证的凭据。这些凭证只能部分验证对等方的身份，并且可能需要在隧道内进行额外的验证。例如，可以在隧道建立期间认证通信设备；此外，可能需要用户身份验证来满足身份验证策略。隧道方法必须能够在隧道建立期间提供客户端身份验证。
The tunnel method MUST provide extensibility so that additional data related to authentication, authorization, and network access can be carried inside the tunnel in the future. This removes the need to develop new tunneling methods for specific purposes.
隧道方法必须提供可扩展性，以便将来可以在隧道内携带与身份验证、授权和网络访问相关的附加数据。这样就不需要为特定目的开发新的隧道方法。
An application for extensibility is credential provisioning. When a peer has authenticated with EAP, this is a convenient time to distribute credentials to that peer that may be used for later authentication exchanges. For example, the authentication server can provide a private key or shared key to the peer that can be used by the peer to perform rapid re-authentication or roaming. In addition, there have been proposals to perform enrollment within EAP, such as [EAP-ENROLL]. Another use for extensibility is support for alternate authentication frameworks within the tunnel.
可扩展性的应用程序是凭证供应。当对等方已使用EAP进行身份验证时，这是向该对等方分发凭据的方便时间，该凭据可用于以后的身份验证交换。例如，认证服务器可以向对等方提供私钥或共享密钥，对等方可以使用私钥或共享密钥来执行快速重新认证或漫游。此外，有人提议在EAP内进行注册，如[EAP-ENROLL]。扩展性的另一个用途是支持隧道内的备用身份验证框架。
In some cases, the peer will not have a way to verify a server certificate and, in some cases, a server might not have a certificate to verify. Therefore, it is desirable to support certificate-less authentication. An application for this is credential provisioning where the peer and server authenticate each other with a shared password and credentials for subsequent authentication (e.g., a key pair and certificate, or a shared key) can be passed inside the tunnel. Another application is to extend existing EAP methods with new features such as EAP channel bindings.
在某些情况下，对等方无法验证服务器证书，在某些情况下，服务器可能没有要验证的证书。因此，希望支持无证书认证。这方面的一个应用是凭据提供，其中对等方和服务器使用共享密码相互验证，并且可以在隧道内传递用于后续验证的凭据（例如，密钥对和证书或共享密钥）。另一个应用程序是使用EAP通道绑定等新功能扩展现有EAP方法。
Great care must be taken when using tunnels with no server authentication for the protection of an inner method. For example, the client may lack the appropriate trust roots to fully authenticate the server, but may still establish the tunnel to execute an inner EAP method to perform mutual authentication and key derivation. In these cases, the inner EAP method MUST provide resistance to dictionary attack and a cryptographic binding between the inner method and the tunnel method MUST be established. Furthermore, the cipher suite used to establish the tunnel MUST derive the master key using contributions from both client and server, as in ephemeral Diffie-Hellman cipher suites.
当使用没有服务器身份验证的隧道来保护内部方法时，必须非常小心。例如，客户端可能缺少适当的信任根来完全认证服务器，但仍然可以建立隧道来执行内部EAP方法以执行相互认证和密钥派生。在这些情况下，内部EAP方法必须能够抵抗字典攻击，并且必须在内部方法和隧道方法之间建立加密绑定。此外，用于建立隧道的密码套件必须使用来自客户端和服务器的贡献来派生主密钥，如短暂的Diffie-Hellman密码套件。
The tunnel method MAY allow for certificate-less authentication.
隧道方法可能允许无证书身份验证。
The tunnel method MUST include a Security Claims section with all security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 3748 that tunnel methods MUST support protection against man-in-the-middle attacks. Furthermore, the tunnel method MUST support identity protection as specified in Section 7.3 of RFC 3748.
隧道法必须包括一个安全声明部分，以及RFC 3748[RFC3748]第7.2节中规定的所有安全声明。此外，它必须满足RFC 3748第2.1节和第7.4节的要求，即隧道方法必须支持对中间人攻击的保护。此外，隧道方法必须支持RFC 3748第7.3节规定的身份保护。
The tunnel method MUST be unconditionally compliant with RFC 4017 [RFC4017] (using the definition of "unconditionally compliant" contained in Section 1.1 of RFC 4017). This means that the method MUST satisfy all the "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" requirements in RFC 4017.
隧道法必须无条件符合RFC 4017[RFC4017]（使用RFC 4017第1.1节中包含的“无条件符合”定义）。这意味着该方法必须满足RFC4017中的所有“必须”、“不得”、“应该”和“不应该”要求。
The tunnel method MUST meet all the "MUST" and "SHOULD" requirements relevant to EAP methods contained in the EAP key management framework [RFC5247] or any successor. This includes the generation of the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, and Session-Id. These requirements will enable the tunnel method to properly fit into the EAP key management framework, maintaining all of the security properties and guarantees of that framework.
隧道方法必须满足EAP密钥管理框架[RFC5247]或任何后续文件中包含的与EAP方法相关的所有“必须”和“应该”要求。这包括生成主会话密钥（MSK）、扩展主会话密钥（EMSK）、对等Id、服务器Id和会话Id。这些要求将使隧道方法能够正确地适应EAP密钥管理框架，维护该框架的所有安全属性和保证。
The tunnel method MUST NOT be tied to any single cryptographic algorithm. Instead, it MUST support run-time negotiation to select among an extensible set of cryptographic algorithms, such as algorithms used with certificates presented during tunnel establishment. This "cryptographic algorithm agility" provides several advantages. Most important, when a weakness in an algorithm is discovered or increased processing power overtakes an algorithm, users can easily transition to a new algorithm. Also, users can choose the algorithm that best meets their needs.
隧道方法不能绑定到任何单个加密算法。相反，它必须支持运行时协商，以便在一组可扩展的加密算法中进行选择，例如在隧道建立期间使用证书的算法。这种“加密算法敏捷性”提供了几个优点。最重要的是，当发现算法中的弱点或增加的处理能力超过算法时，用户可以轻松地过渡到新算法。此外，用户可以选择最符合其需求的算法。
The tunnel method MUST meet the SHOULD and MUST requirements pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. This includes: cryptographic algorithm independence; strong, fresh session keys; replay detection; keying material confidentiality and integrity; and confirmation of cipher suite selection.
隧道法必须满足RFC 4962[RFC4962]第3节中包含的EAP法相关的“应该”和“必须”要求。这包括：密码算法的独立性；强大、新鲜的会话密钥；回放检测；键入资料的机密性和完整性；以及密码套件选择的确认。
The following section discusses requirements for TLS tunnel establishment.
下节讨论TLS隧道建设的要求。
The tunnel-based method MUST support TLS version 1.2 [RFC5246] and may support earlier versions greater than SSL 2.0 in order to enable the possibility of backwards compatibility.
基于隧道的方法必须支持TLS版本1.2[RFC5246]，并且可能支持高于SSL 2.0的早期版本，以便实现向后兼容性。
Cipher suite negotiations always suffer from downgrading attacks when they are not secured by any kind of integrity protection. A common practice is a post-negotiation integrity check in which, as soon as available, the established keys (here, the tunnel key) are used to derive integrity keys. These integrity keys are then used by the peer and authentication server to verify whether the cipher suite negotiation has been maliciously altered by another party.
密码套件协商在没有任何完整性保护的情况下总是遭受降级攻击。一种常见的做法是协商后完整性检查，其中一旦可用，就使用已建立的密钥（这里是隧道密钥）来派生完整性密钥。然后，对等方和身份验证服务器使用这些完整性密钥来验证密码套件协商是否被另一方恶意更改。
Integrity checks prevent downgrading attacks only if the derived integrity keys and the employed integrity algorithms cannot be broken in real-time. See Section 5.1 or [HC07] for more information on this. Hence, the tunnel method MUST provide integrity-protected cipher suite negotiation with secure integrity algorithms and integrity keys.
完整性检查仅在派生的完整性密钥和采用的完整性算法无法实时破坏时才防止降级攻击。有关这方面的更多信息，请参见第5.1节或[HC07]。因此，隧道方法必须使用安全的完整性算法和完整性密钥提供完整性保护的密码套件协商。
TLS provides protected cipher suite negotiation as long as all the cipher suites supported provide authentication, key establishment, and data integrity protection as discussed in Section 5.1.
TLS提供受保护的密码套件协商，只要所有受支持的密码套件提供第5.1节中讨论的身份验证、密钥建立和数据完整性保护。
In order to prevent attacks on the cryptographic algorithms employed by inner authentication methods, a tunnel protocol's protection needs to provide a basic level of algorithm strength. The tunnel method MUST provide at least one mandatory-to-implement cipher suite that provides the equivalent security of 128-bit AES for encryption and message authentication. See Part 1 of the NIST "Recommendation for Key Management" [NIST-SP-800-57] for a discussion of the relative strengths of common algorithms.
为了防止对内部身份验证方法使用的加密算法的攻击，隧道协议的保护需要提供基本级别的算法强度。隧道方法必须提供至少一个强制密码套件，以实现为加密和消息身份验证提供128位AES同等安全性的密码套件。有关常见算法相对优势的讨论，请参见NIST“密钥管理建议”[NIST-SP-800-57]第1部分。
A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer and mutual authentication between authentication server and EAP peer. The tunnel method MUST provide at least one mandatory-to-implement cipher suite that provides certificate-based authentication of the server and provides optional certificate-based authentication of the client. Other types of authentication MAY be supported.
隧道方法必须提供从身份验证服务器到EAP对等方的单向身份验证，以及身份验证服务器和EAP对等方之间的相互身份验证。隧道方法必须提供至少一个强制密码套件，以实现提供服务器基于证书的身份验证和客户端基于证书的可选身份验证的密码套件。可能支持其他类型的身份验证。
At least one mandatory-to-implement cipher suite MUST be approved by the NIST "Draft Recommendation for Key Management", Part 3 [NIST-SP-800-57p3], i.e., the cipher suite MUST be listed in Table 4-1, 4-2, or 4-3 in that document.
至少有一个强制实施密码套件必须得到NIST“密钥管理建议草案”第3部分[NIST-SP-800-57p3]的批准，即密码套件必须在该文件的表4-1、4-2或4-3中列出。
The mandatory-to-implement cipher suites MUST only include cipher suites that use strong cryptographic algorithms. They MUST NOT include cipher suites providing mutually anonymous authentication or static Diffie-Hellman cipher suites.
强制实现密码套件必须仅包括使用强密码算法的密码套件。它们不得包括提供相互匿名身份验证的密码套件或静态Diffie-Hellman密码套件。
Other cipher suites MAY be selected following the security requirements for tunnel protocols in the NIST "Recommendation for EAP Methods Used in Wireless Network Access Authentication" [NIST-SP-800-120].
可根据NIST“无线网络接入认证中使用的EAP方法建议”[NIST-SP-800-120]中隧道协议的安全要求选择其他密码套件。
In order to prevent replay attacks on a tunnel protocol, the message authentication MUST be generated using a time-variant input such as timestamps, sequence numbers, nonces, or a combination of these, so that any reuse of the authentication data can be detected as invalid. TLS provides sufficient replay protection to meet this requirement as long as weak cipher suites discussed in Section 5.1 are avoided.
为了防止对隧道协议的重播攻击，必须使用时变输入（如时间戳、序列号、nonce或它们的组合）生成消息身份验证，以便可以将身份验证数据的任何重用检测为无效。只要避免第5.1节中讨论的弱密码套件，TLS提供足够的重放保护以满足此要求。
In order to meet the requirements in this document, TLS extensions MAY be used. For example, TLS extensions may be useful in providing certificate revocation information via the TLS Online Certificate Status Protocol (OCSP) extension [RFC6066] (thus meeting the requirement in Section 4.5.1.3).
为了满足本文件的要求，可使用TLS扩展。例如，TLS扩展可用于通过TLS在线证书状态协议（OCSP）扩展[RFC6066]提供证书撤销信息（从而满足第4.5.1.3节的要求）。
A tunnel protocol MUST support peer privacy. This requires that the username and other attributes associated with the peer are not transmitted in the clear or to an unauthenticated, unauthorized party. Peer identity protection provided by the tunnel method
隧道协议必须支持对等隐私。这要求与对等方关联的用户名和其他属性不以明文形式传输，也不传输给未经验证的未授权方。隧道方法提供的对等身份保护
applies to establishment of the tunnel and protection of inner method specific identities. If applicable, the peer certificate is sent confidentially (i.e., encrypted).
适用于建立隧道和保护内部特定身份的方法。如果适用，对等证书以保密方式发送（即加密）。
The tunnel method MUST support TLS session resumption as defined in [RFC5246]. The tunnel method MAY support other methods of session resumption such as those defined in [RFC5077].
隧道方法必须支持[RFC5246]中定义的TLS会话恢复。隧道方法可支持其他会话恢复方法，如[RFC5077]中定义的方法。
Tunnel establishment sometimes requires the exchange of information that exceeds what can be carried in a single EAP message. In addition, information carried within the tunnel may also exceed this limit. Therefore, a tunnel method MUST support fragmentation and reassembly.
隧道建立有时需要交换超过单个EAP消息所能承载的信息。此外，隧道内携带的信息也可能超过此限制。因此，隧道方法必须支持碎片和重新组装。
A man-in-the-middle attacker can modify cleartext values such as protocol version and type code information communicated outside the TLS tunnel. The tunnel method MUST provide implicit or explicit protection of the protocol version and type code. If modification of other information external to the tunnel can cause exploitable vulnerabilities, the tunnel method MUST provide protection against modification of this additional data.
中间人攻击者可以修改明文值，例如协议版本和在TLS隧道外通信的类型代码信息。隧道方法必须为协议版本和类型代码提供隐式或显式保护。如果修改隧道外部的其他信息会导致可利用的漏洞，则隧道方法必须提供保护，防止修改此附加数据。
This section describes the payload requirements inside the tunnel. These requirements frequently express features that a candidate protocol must be capable of offering so that a deployer can decide whether to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment.
本节描述了隧道内的有效载荷要求。这些需求通常表示候选协议必须能够提供的特性，以便部署人员可以决定是否使用该特性。本节不说明部署期间必须使用每个协议的哪些功能的要求。
The payload MUST be extensible. Some standard payload attribute types will be defined to meet known requirements listed below, such as password authentication, inner EAP method, vendor-specific attributes, and result indication. Additional payload attributes MAY be defined in the future to support additional features and data types.
有效负载必须是可扩展的。将定义一些标准有效负载属性类型，以满足下面列出的已知要求，例如密码验证、内部EAP方法、供应商特定属性和结果指示。将来可能会定义额外的有效负载属性，以支持额外的功能和数据类型。
The payload MUST support the request and response type of half-duplex operation typical of EAP. Multiple attributes may be sent in a single payload. The payload MAY support transporting multiple authentications in a single payload packet.
有效负载必须支持EAP典型的半双工操作的请求和响应类型。可以在单个有效负载中发送多个属性。有效载荷可支持在单个有效载荷分组中传输多个认证。
It is expected that new attributes will be defined to be carried within the tunnel method. In some cases, it is necessary for the sender to know if the receiver did not understand the attribute. To support this, there MUST be a way for the sender to mark attributes such that the receiver will indicate if an attribute is not understood.
预计将在隧道方法中定义新属性。在某些情况下，发送方需要知道接收方是否不理解该属性。为了支持这一点，发送方必须有一种方法来标记属性，以便接收方能够指示是否不理解某个属性。
The payload MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identified vendor-specific namespaces. They can be used for experiments or vendor-specific features.
有效负载必须支持一组可扩展的供应商特定属性的通信。这些属性将被分割为唯一标识的特定于供应商的名称空间。它们可用于实验或特定于供应商的功能。
The payload MUST support result indication and its acknowledgement, so both the EAP peer and server will end up with a synchronized state. The result indication is needed after each chained inner authentication method and at the end of the authentication, so separate result indications for intermediate and final results MUST be supported.
有效负载必须支持结果指示及其确认，因此EAP对等方和服务器都将以同步状态结束。每个链式内部验证方法之后和验证结束时都需要结果指示，因此必须支持中间和最终结果的单独结果指示。
The payload MAY provide a standard attribute format that supports international strings. This attribute format MUST support encoding strings in UTF-8 [RFC3629] format. Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference as indicated by RFC 5646 [RFC5646]. Note that in some cases, such as when transmitting error codes, it is acceptable to exchange numeric codes that can be translated by the client to support the particular local language. These numeric codes are not subject to internationalization during transmission.
有效负载可以提供支持国际字符串的标准属性格式。此属性格式必须支持UTF-8[RFC3629]格式的编码字符串。服务器发送给用户显示的任何字符串必须以UTF-8格式发送，并且应能够标记语言信息，并根据RFC 5646[RFC5646]指示的用户语言偏好进行调整。请注意，在某些情况下，例如在传输错误代码时，可以交换可由客户端翻译以支持特定本地语言的数字代码。这些数字代码在传输过程中不受国际化影响。
The tunnel method MUST be capable of meeting EAP channel binding requirements described in [RFC6677]. As discussed in [RFC5056], EAP channel bindings differ from channel bindings discussed in other contexts. Cryptographic binding between the TLS tunnel and the inner method discussed in Section 4.6.3 relates directly to the non-EAP channel binding concepts discussed in RFC 5056.
隧道方法必须能够满足[RFC6677]中描述的EAP通道绑定要求。如[RFC5056]所述，EAP通道绑定不同于其他上下文中讨论的通道绑定。第4.6.3节中讨论的TLS隧道和内部方法之间的加密绑定与RFC 5056中讨论的非EAP通道绑定概念直接相关。
This section describes the requirements associated with tunneled password authentication. The password authentication mentioned here refers to user or machine authentication using a legacy password database or verifier, such as the Lightweight Directory Access Protocol (LDAP) [RFC4511], OTP, etc. These typically require the password in its original text form in order to authenticate the peer; hence, they require the peer to send the cleartext username and password to the EAP server.
本节介绍与隧道密码身份验证相关的要求。这里提到的密码认证是指使用传统密码数据库或验证器的用户或机器认证，如轻量级目录访问协议（LDAP）[RFC4511]，OTP等。这些通常需要原始文本形式的密码，以便对对等方进行认证；因此，它们要求对等方向EAP服务器发送明文用户名和密码。
Many internal EAP methods have the peer send its password in the clear to the EAP server. Other methods (e.g., challenge-response methods) are vulnerable to attacks if an eavesdropper can intercept the traffic. For any such methods, the security measures in the following sections MUST be met.
许多内部EAP方法让对等方将其密码以明文形式发送到EAP服务器。如果窃听者可以拦截流量，则其他方法（例如质询-响应方法）容易受到攻击。对于任何此类方法，必须满足以下章节中的安全措施。
The cleartext password exchange MUST be integrity and confidentiality protected. As long as the password exchange occurs inside an authenticated and encrypted tunnel, this requirement is met.
明文密码交换必须具有完整性和保密性保护。只要密码交换发生在经过身份验证和加密的隧道内，就可以满足此要求。
The EAP server MUST be authenticated before the peer sends the cleartext password to the server.
在对等方向服务器发送明文密码之前，必须对EAP服务器进行身份验证。
When certificate authentication is used during tunnel establishment, the EAP peer may need to present its password to the server before it has network access to check the revocation status of the server's credentials. Therefore, the tunnel method MUST support mechanisms to check the revocation status of a credential. The tunnel method SHOULD make use of Online Certificate Status Protocol (OCSP)
当在隧道建立期间使用证书身份验证时，EAP对等方可能需要在其具有网络访问权之前向服务器提供其密码，以检查服务器凭据的吊销状态。因此，隧道方法必须支持检查凭证吊销状态的机制。隧道方法应使用在线证书状态协议（OCSP）
[RFC2560] or Server-based Certificate Validation Protocol (SCVP) [RFC5055] to obtain the revocation status of the EAP server certificate.
[RFC2560]或基于服务器的证书验证协议（SCVP）[RFC5055]以获取EAP服务器证书的吊销状态。
The password authentication exchange MUST support usernames and passwords in international languages. It MUST support encoding of username and password strings in UTF-8 [RFC3629] format. The method MUST specify how username and password normalizations and/or comparisons are performed in reference to SASLprep [RFC4013], Net-UTF-8 [RFC5198], or their replacements.
密码验证交换必须支持国际语言的用户名和密码。它必须支持UTF-8[RFC3629]格式的用户名和密码字符串编码。该方法必须指定如何参考SASLprep[RFC4013]、Net-UTF-8[RFC5198]或其替代品执行用户名和密码规范化和/或比较。
Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference as indicated by RFC 5646 [RFC5646]. Note that, in some cases, such as when transmitting error codes, it is acceptable to exchange numeric codes that can be translated by the client to support the particular local language. These numeric codes are not subject to internationalization during transmission.
服务器发送给用户显示的任何字符串必须以UTF-8格式发送，并且应能够标记语言信息，并根据RFC 5646[RFC5646]指示的用户语言偏好进行调整。请注意，在某些情况下，例如在传输错误代码时，可以交换可由客户端翻译以支持特定本地语言的数字代码。这些数字代码在传输过程中不受国际化影响。
The password authentication exchange SHOULD support additional associated metadata that can be used to indicate whether the authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner authentications where the user and machine both need to be authenticated.
密码身份验证交换应支持其他关联元数据，这些元数据可用于指示身份验证是针对用户还是针对计算机。这允许EAP服务器和对等方专门为用户或机器请求和协商身份验证。这在用户和机器都需要进行身份验证的多个内部身份验证的情况下非常有用。
The password authentication exchange MUST support password change. The exchange SHOULD be extensible to support other "housekeeping" functions, such as the management of PINs or other data, required by some systems.
密码验证交换必须支持密码更改。交换应可扩展，以支持某些系统所需的其他“内务管理”功能，如PIN或其他数据的管理。
The tunnel method MUST be able to carry inner EAP methods without modifying them. EAP methods MUST NOT be redefined inside the tunnel.
隧道方法必须能够在不修改内部EAP方法的情况下承载这些方法。EAP方法不得在隧道内重新定义。
The tunnel method MUST support the protected negotiation of the inner EAP method. It MUST NOT allow the inner EAP method negotiation to be manipulated by intermediaries.
隧道方法必须支持内部EAP方法的受保护协商。不得允许中间人操纵内部EAP方法协商。
The tunnel method SHOULD support the chaining of multiple EAP methods. The tunnel method MUST allow for the communication of intermediate results and for the verification of compound binding between executed inner methods when chained methods are employed.
隧道方法应支持多个EAP方法的链接。当使用链式方法时，隧道方法必须允许中间结果的通信，以及验证已执行内部方法之间的复合绑定。
The tunnel method MUST provide a mechanism to bind the tunnel protocol and the inner EAP method. This property is referred to as cryptographic binding. Such bindings are an important tool for mitigating the tunnel MitM attacks [TUNNEL-MITM]. Cryptographic bindings enable the complete prevention of tunnel MitM attacks without the need of additional security policies, as long as the inner method derives keys and is not vulnerable to attacks outside a protected tunnel [LCN-2010]. Even though weak or non-key-deriving inner methods may be permitted. Thus, security policies preventing tunnel MitM attacks are still necessary, and the tunnel method MUST provide cryptographic bindings, because only this allows migrating to more secure, policy-independent implementations.
隧道方法必须提供绑定隧道协议和内部EAP方法的机制。此属性称为加密绑定。这种绑定是缓解隧道MitM攻击的重要工具[tunnel-MitM]。加密绑定可以完全防止隧道MitM攻击，而无需额外的安全策略，只要内部方法派生密钥并且不易受到受保护隧道之外的攻击[LCN-2010]。即使允许使用弱或非键派生的内部方法。因此，防止隧道MitM攻击的安全策略仍然是必要的，隧道方法必须提供加密绑定，因为只有这样才能迁移到更安全、与策略无关的实现。
Cryptographic bindings are typically achieved by securely mixing the established keying material (say, tunnel key TK) from the tunnel protocol with the established keying material (say, method key MK) from the inner authentication method(s) in order to derive fresh keying material. If chained EAP methods are executed in the tunnel, all derived inner keys are combined with the tunnel key to create a new compound tunnel key (CTK). In particular, CTK is used to derive the EAP MSK, EMSK and other transient keys (shown as "TEK" below), such as transient encryption keys and integrity protection keys. The key hierarchy for tunnel method executions that derive compound keys for the purpose of cryptographic binding is depicted in Figure 1.
加密绑定通常通过将来自隧道协议的已建立密钥材料（例如，隧道密钥TK）与来自内部认证方法的已建立密钥材料（例如，方法密钥MK）安全地混合来实现，以便导出新的密钥材料。如果在隧道中执行链式EAP方法，则所有派生的内部密钥都将与隧道密钥组合以创建新的复合隧道密钥（CTK）。具体而言，CTK用于导出EAP MSK、EMSK和其他瞬态密钥（如下所示为“TEK”），例如瞬态加密密钥和完整性保护密钥。图1描述了为加密绑定而派生复合密钥的隧道方法执行的密钥层次结构。
In the case of the sequential executions of n inner methods, a chained compound key CTK_i MUST be computed upon the completion of each inner method i such that it contains the compound key of all previous inner methods, i.e., CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n and CTK_0=TK, where f() is a key derivation function, such as one that complies with the NIST "Recommendation for Key Derivation Using Pseudorandom Functions" [NIST-SP-800-108]. CTK_n SHOULD serve as the key to derive further keys. Figure 1 depicts the key hierarchy in
在n个内部方法的顺序执行的情况下，必须在每个内部方法i完成时计算链式复合键CTK_i，以使其包含所有先前内部方法的复合键，即0<i<=n的CTK_i=f（CTK_i-1，MK_i）和CTK_0=TK，其中f（）是键派生函数，例如符合NIST“使用伪随机函数进行密钥推导的建议”[NIST-SP-800-108]。CTK_n应作为派生进一步密钥的密钥。图1描述了中的键层次结构
the case of a single inner method. Transient keys derived from the compound key CTK are used in a cryptographic protocol to verify the integrity of the tunnel and the inner authentication method.
单一内部方法的情况。从复合密钥CTK派生的瞬态密钥用于加密协议中，以验证隧道和内部身份验证方法的完整性。
-----------
| TK | MK |
-----------
| |
v v
--------
| CTK |
--------
|
v
----------------
| | |
v v v
------- ------ -------
| TEK | | MSK | | EMSK |
------- ------- --------
-----------
| TK | MK |
-----------
| |
v v
--------
| CTK |
--------
|
v
----------------
| | |
v v v
------- ------ -------
| TEK | | MSK | | EMSK |
------- ------- --------
Figure 1: Compound Keys
图1：复合键
Furthermore, all compound keys CTK_i and all keys derived from it SHOULD follow the recommendations for key derivations and key hierarchies as specified in [NIST-SP-800-108]. In particular, all derived keys MUST have a lifetime assigned that does not exceed the lifetime of any key higher in the key hierarchy. The derivation MUST prevent a compromise in one part of the system from leading to compromises in other parts of the system that relay on keys at the same or higher level in the hierarchy.
此外，所有复合密钥CTK_i及其派生的所有密钥应遵循[NIST-SP-800-108]中规定的密钥派生和密钥层次结构建议。特别是，所有派生密钥必须分配的生存期不超过密钥层次结构中任何更高级别密钥的生存期。派生必须防止系统的一个部分中的妥协导致系统的其他部分中的妥协，这些部分依赖于层次结构中相同或更高级别的密钥。
The tunnel method SHOULD allow for the peer to initiate an inner EAP authentication in order to meet its policy requirements for authenticating the server.
隧道方法应允许对等方启动内部EAP身份验证，以满足其对服务器进行身份验证的策略要求。
The tunnel method SHOULD allow for the communication of additional data associated with an EAP method. This can be used to indicate whether the authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner EAP authentications where the user and machine both need to be authenticated.
隧道方法应允许与EAP方法相关的附加数据的通信。这可用于指示身份验证是针对用户还是针对计算机。这允许EAP服务器和对等方专门为用户或机器请求和协商身份验证。这在多个内部EAP身份验证的情况下非常有用，其中用户和机器都需要进行身份验证。
A tunnel method is often deployed to provide mutual authentication between EAP Peer and EAP Server and to generate key material for use in protecting lower-layer protocols. In addition the tunnel is used to protect the communication of additional data, including peer identity between the EAP Peer and EAP Server from disclosure to or modification by an attacker. These sections cover considerations that affect the ability for a method to achieve these goals.
通常部署隧道方法来提供EAP对等方和EAP服务器之间的相互认证，并生成用于保护较低层协议的密钥材料。此外，隧道还用于保护其他数据的通信，包括EAP对等方和EAP服务器之间的对等方身份，以防攻击者泄露或修改。这些部分包括影响实现这些目标的方法能力的考虑因素。
TLS supports a wide range of cipher suites providing a variety of security properties. The selection of cipher suites is critical to the security of the tunnel method. Selection of a cipher suite with weak or no authentication, such as an anonymous Diffie-Hellman-based cipher suite, will greatly increase the risk of system compromise. Since a tunnel method uses the TLS tunnel to transport data, the selection of a cipher suite with weak data encryption and integrity algorithms will also increase the vulnerability of the method to attacks.
TLS支持广泛的密码套件，提供各种安全属性。密码套件的选择对隧道方法的安全性至关重要。选择弱身份验证或无身份验证的密码套件，例如基于Diffie-Hellman的匿名密码套件，将大大增加系统泄露的风险。由于隧道方法使用TLS隧道传输数据，因此选择具有弱数据加密和完整性算法的密码套件也会增加该方法对攻击的脆弱性。
A tunnel protocol is prone to downgrading attacks if the tunnel protocol supports any key establishment algorithm that can be broken on-line. In a successful downgrading attack, an adversary breaks the selected "weak" key establishment algorithm and optionally the "weak" authentication algorithm without being detected. Here, "weak" refers to a key establishment algorithm that can be broken in real-time, and an authentication scheme that can be broken off-line, respectively. See [HC07] for more details. The requirements in this document disapprove the use of key establishment algorithms that can be broken on-line.
如果隧道协议支持任何可以在线中断的密钥建立算法，则隧道协议容易受到降级攻击。在成功的降级攻击中，对手会在未被检测到的情况下破坏选定的“弱”密钥建立算法和可选的“弱”身份验证算法。这里，“弱”分别指可实时中断的密钥建立算法和可离线中断的认证方案。有关更多详细信息，请参见[HC07]。本文件中的要求不允许使用可在线中断的密钥建立算法。
Mutually anonymous tunnel protocols are prone to man-in-the-middle attacks described in [HC07]. During such an attack, an adversary establishes one tunnel with the peer and one with the authentication server, while the peer and server believe that they established a tunnel with each other. Once both tunnels have been established, the adversary can eavesdrop on all communications within the tunnels, i.e., the execution of the inner authentication method(s). Consequently, the adversary can eavesdrop on the identifiers that are exchanged as part of the EAP method, and thus the privacy of peer and/or authentication server is compromised along with any other data transmitted within the tunnels. This document requires server authentication to avoid the risks associated with anonymous cipher suites.
相互匿名的隧道协议容易受到[HC07]中描述的中间人攻击。在这种攻击过程中，对手与对等方建立一个隧道，与身份验证服务器建立一个隧道，而对等方和服务器认为他们彼此建立了一个隧道。一旦建立了两条隧道，敌方就可以窃听隧道内的所有通信，即执行内部身份验证方法。因此，对手可以窃听作为EAP方法的一部分交换的标识符，因此对等方和/或认证服务器的隐私与隧道内传输的任何其他数据一起受到损害。此文档要求服务器身份验证，以避免与匿名密码套件相关的风险。
In many cases, a tunnel method provides mutual authentication by authenticating the server during tunnel establishment and authenticating the peer within the tunnel using an EAP method. As described in [TUNNEL-MITM], this mode of operation can allow tunnel man-in-the-middle attackers to authenticate to the server as the peer by tunneling the inner EAP protocol messages to and from a peer that is executing the method outside a tunnel or with an untrustworthy server. Cryptographic binding between the established keying material from the inner authentication method(s) and the tunnel protocol verifies that the endpoints of the tunnel and the inner authentication method(s) are the same. This can thwart the attack if the inner-method-derived keys are of sufficient strength that they cannot be broken in real-time.
在许多情况下，隧道方法通过在隧道建立期间认证服务器和使用EAP方法认证隧道内的对等方来提供相互认证。如[TUNNEL-MITM]中所述，这种操作模式允许中间隧道人攻击者通过隧道内部EAP协议消息与在隧道外或不可信服务器上执行方法的对等方之间的通信，向作为对等方的服务器进行身份验证。来自内部身份验证方法和隧道协议的已建立密钥材料之间的加密绑定验证隧道和内部身份验证方法的端点是否相同。如果内部方法派生的密钥具有足够的强度，无法实时断开，则这可以阻止攻击。
In cases where the inner authentication method does not generate any key material or only weak key material, security policies MUST be enforced such that the peer cannot execute the inner method with the same credentials outside a protective tunnel or with an untrustworthy server.
在内部身份验证方法不生成任何密钥材料或仅生成弱密钥材料的情况下，必须强制执行安全策略，以便对等方不能在保护隧道外或不可信的服务器上使用相同的凭据执行内部方法。
The tunnel method will use data that is outside the TLS tunnel such as the EAP type code or version numbers. If an attacker can compromise the protocol by modifying these values, the tunnel method MUST protect this data from modification. In some cases, external data may not need additional protection because it is implicitly verified during the protocol operation.
隧道方法将使用TLS隧道之外的数据，如EAP类型代码或版本号。如果攻击者可以通过修改这些值来破坏协议，则隧道方法必须保护此数据不受修改。在某些情况下，外部数据可能不需要额外的保护，因为它是在协议操作期间隐式验证的。
Terminating the inner method at a different location than the outer tunnel needs careful consideration. The inner method data may be vulnerable to modification and eavesdropping between the server that terminates the tunnel and the server that terminates the inner method. For example, if a cleartext password is used, then it may be sent to the inner method server in a RADIUS password attribute, which uses weak encryption that may not be suitable protection for many environments.
在与外部隧道不同的位置终止内部方法需要仔细考虑。内部方法数据可能容易在终止隧道的服务器和终止内部方法的服务器之间被修改和窃听。例如，如果使用明文密码，则可能会将其发送到RADIUS密码属性中的内部方法服务器，该属性使用弱加密，可能不适合许多环境的保护。
In some cases, terminating the tunnel at a different location may make it difficult for a peer to authenticate the server and trust it for further communication. For example, if the TLS tunnel is terminated by a different organization, the peer needs to be able to authenticate and authorize the tunnel server to handle secret
在某些情况下，在不同位置终止隧道可能会使对等方难以对服务器进行身份验证并信任它进行进一步通信。例如，如果TLS隧道被其他组织终止，则对等方需要能够对隧道服务器进行身份验证和授权，以处理机密信息
credentials that the peer shares with the home server that terminates the inner method. This may not meet the security policy of many environments.
对等方与终止内部方法的主服务器共享的凭据。这可能不符合许多环境的安全策略。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和W.Polk，“基于服务器的证书验证协议（SCVP）”，RFC 50552007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677]Hartman，S.，Ed.，Clancy，T.，和K.Hoeper，“可扩展认证协议（EAP）方法的通道绑定支持”，RFC 6677，2012年7月。
[EAP-ENROLL] Mahy, R., "An Extensible Authentication Protocol (EAP) Enrollment Method", Work in Progress, March 2006.
[EAP-ENROLL]Mahy，R.，“可扩展认证协议（EAP）注册方法”，正在进行的工作，2006年3月。
[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月。
[LCN-2010] Hoeper, K. and L. Chen, "An Inconvenient Truth about Tunneled Authentications", Proceedings of 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), September 2009.
[LCN-2010]Hoeper，K.和L.Chen，“关于隧道认证的不方便的真相”，第35届IEEE本地计算机网络年会论文集（LCN 2010），2009年9月。
[NIST-SP-800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", Draft NIST Special Publication 800-108, April 2008.
[NIST-SP-800-108]Chen，L.“使用伪随机函数进行密钥推导的建议”，NIST特别出版物800-108草案，2008年4月。
[NIST-SP-800-120] Hoeper, K. and L. Chen, "Recommendation for EAP Methods Used in Wireless Network Access Authentication", NIST Special Publication 800-120, September 2009.
[NIST-SP-800-120]Hoeper，K.和L.Chen，“无线网络接入认证中使用EAP方法的建议”，NIST特别出版物800-120，2009年9月。
[NIST-SP-800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, part 1, March 2007.
[NIST-SP-800-57]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“关键管理建议-第1部分：概述（修订）”，NIST特别出版物800-57，第1部分，2007年3月。
[NIST-SP-800-57p3] Barker, E., Burr, W., Jones, A., Polk, W., Rose, S., and M. Smid, "Recommendation for Key Management, Part 3 Application-Specific Key Management Guidance", Draft NIST Special Publication 800-57, part 3, October 2008.
[NIST-SP-800-57p3]Barker，E.，Burr，W.，Jones，A.，Polk，W.，Rose，S.，和M.Smid，“密钥管理建议，第3部分特定于应用的密钥管理指南”，NIST特别出版物草案800-57，第3部分，2008年10月。
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP) Specification", August 2009, <http:// download.microsoft.com/download/9/5/E/ 95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-PEAP%5D.pdf>.
[PEAP]微软公司，“[MS-PEAP]：受保护的可扩展身份验证协议（PEAP）规范”，2009年8月，<http://download.Microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-PEAP%5D.pdf>。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年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月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209]Sangster，P.，Khosravi，H.，Mani，M.，Narayan，K.，和J.Tardo，“网络端点评估（NEA）：概述和要求”，RFC 52092008年6月。
[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月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010.
[RFC5793]Sahita，R.，Hanna，S.，Hurst，R.，和K.Narayan，“PB-TNC：与可信网络连接（TNC）兼容的姿态代理（PB）协议”，RFC 57932010年3月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[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
作者地址
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
Stephen Hanna Juniper Networks 3 Beverly Road Bedford, MA 01730 USA
美国马萨诸塞州贝德福德贝弗利路3号Stephen Hanna Juniper Networks 01730
EMail: shanna@juniper.net
EMail: shanna@juniper.net
Hao Zhou Cisco Systems, Inc. 4125 Highlander Parkway Richfield, OH 44286 USA
郝州思科系统有限公司，美国俄亥俄州里奇菲尔德高地公园路4125号，邮编44286
EMail: hzhou@cisco.com
EMail: hzhou@cisco.com
Joseph Salowey (editor) Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA
Joseph Salowey（编辑）思科系统公司，第2901-3页。美国华盛顿州西雅图大道98121号
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com