Network Working Group P. Funk
Request for Comments: 5281 Unaffiliated
Category: Informational S. Blake-Wilson
SafeNet
August 2008
Network Working Group P. Funk
Request for Comments: 5281 Unaffiliated
Category: Informational S. Blake-Wilson
SafeNet
August 2008
Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
可扩展身份验证协议隧道传输层安全身份验证协议版本0（EAP-TTLSv0）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange.
EAP-TTLS是一种EAP（可扩展身份验证协议）方法，它封装了TLS（传输层安全）会话，该会话由握手阶段和数据阶段组成。在握手阶段，使用标准TLS程序向客户机验证服务器（或客户机和服务器相互验证），并生成密钥材料，以便为后续数据阶段的信息交换创建加密安全隧道。在数据阶段，使用封装在安全隧道中的任意身份验证机制向服务器验证客户机（或者客户机和服务器相互验证）。封装的认证机制本身可以是EAP，也可以是另一认证协议，例如PAP、CHAP、MS-CHAP或MS-CHAP-V2。因此，EAP-TTLS允许对现有身份验证数据库使用传统的基于密码的身份验证协议，同时保护这些传统协议的安全性，防止窃听、中间人攻击和其他攻击。数据阶段也可用于额外的任意数据交换。
Table of Contents
目录
1. Introduction ....................................................4
2. Motivation ......................................................5
3. Requirements Language ...........................................7
4. Terminology .....................................................7
5. Architectural Model .............................................9
5.1. Carrier Protocols .........................................10
5.2. Security Relationships ....................................10
5.3. Messaging .................................................11
5.4. Resulting Security ........................................12
6. Protocol Layering Model ........................................12
7. EAP-TTLS Overview ..............................................13
7.1. Phase 1: Handshake ........................................14
7.2. Phase 2: Tunnel ...........................................14
7.3. EAP Identity Information ..................................15
7.4. Piggybacking ..............................................15
7.5. Session Resumption ........................................16
7.6. Determining Whether to Enter Phase 2 ......................17
7.7. TLS Version ...............................................18
7.8. Use of TLS PRF ............................................18
8. Generating Keying Material .....................................19
9. EAP-TTLS Protocol ..............................................20
9.1. Packet Format .............................................20
9.2. EAP-TTLS Start Packet .....................................21
9.2.1. Version Negotiation ................................21
9.2.2. Fragmentation ......................................22
9.2.3. Acknowledgement Packets ............................22
10. Encapsulation of AVPs within the TLS Record Layer .............23
10.1. AVP Format ...............................................23
10.2. AVP Sequences ............................................25
10.3. Guidelines for Maximum Compatibility with AAA Servers ....25
11. Tunneled Authentication .......................................26
11.1. Implicit Challenge .......................................26
11.2. Tunneled Authentication Protocols ........................27
11.2.1. EAP ...............................................27
11.2.2. CHAP ..............................................29
11.2.3. MS-CHAP ...........................................30
11.2.4. MS-CHAP-V2 ........................................30
11.2.5. PAP ...............................................32
11.3. Performing Multiple Authentications ......................33
11.4. Mandatory Tunneled Authentication Support ................34
11.5. Additional Suggested Tunneled Authentication Support .....34
12. Keying Framework ..............................................35
12.1. Session-Id ...............................................35
12.2. Peer-Id ..................................................35
12.3. Server-Id ................................................35
13. AVP Summary ...................................................35
1. Introduction ....................................................4
2. Motivation ......................................................5
3. Requirements Language ...........................................7
4. Terminology .....................................................7
5. Architectural Model .............................................9
5.1. Carrier Protocols .........................................10
5.2. Security Relationships ....................................10
5.3. Messaging .................................................11
5.4. Resulting Security ........................................12
6. Protocol Layering Model ........................................12
7. EAP-TTLS Overview ..............................................13
7.1. Phase 1: Handshake ........................................14
7.2. Phase 2: Tunnel ...........................................14
7.3. EAP Identity Information ..................................15
7.4. Piggybacking ..............................................15
7.5. Session Resumption ........................................16
7.6. Determining Whether to Enter Phase 2 ......................17
7.7. TLS Version ...............................................18
7.8. Use of TLS PRF ............................................18
8. Generating Keying Material .....................................19
9. EAP-TTLS Protocol ..............................................20
9.1. Packet Format .............................................20
9.2. EAP-TTLS Start Packet .....................................21
9.2.1. Version Negotiation ................................21
9.2.2. Fragmentation ......................................22
9.2.3. Acknowledgement Packets ............................22
10. Encapsulation of AVPs within the TLS Record Layer .............23
10.1. AVP Format ...............................................23
10.2. AVP Sequences ............................................25
10.3. Guidelines for Maximum Compatibility with AAA Servers ....25
11. Tunneled Authentication .......................................26
11.1. Implicit Challenge .......................................26
11.2. Tunneled Authentication Protocols ........................27
11.2.1. EAP ...............................................27
11.2.2. CHAP ..............................................29
11.2.3. MS-CHAP ...........................................30
11.2.4. MS-CHAP-V2 ........................................30
11.2.5. PAP ...............................................32
11.3. Performing Multiple Authentications ......................33
11.4. Mandatory Tunneled Authentication Support ................34
11.5. Additional Suggested Tunneled Authentication Support .....34
12. Keying Framework ..............................................35
12.1. Session-Id ...............................................35
12.2. Peer-Id ..................................................35
12.3. Server-Id ................................................35
13. AVP Summary ...................................................35
14. Security Considerations .......................................36
14.1. Security Claims ..........................................36
14.1.1. Authentication Mechanism ..........................36
14.1.2. Ciphersuite Negotiation ...........................37
14.1.3. Mutual Authentication .............................37
14.1.4. Integrity Protection ..............................37
14.1.5. Replay Protection .................................37
14.1.6. Confidentiality ...................................37
14.1.7. Key Derivation ....................................37
14.1.8. Key Strength ......................................37
14.1.9. Dictionary Attack Protection ......................38
14.1.10. Fast Reconnect ...................................38
14.1.11. Cryptographic Binding ............................38
14.1.12. Session Independence .............................38
14.1.13. Fragmentation ....................................38
14.1.14. Channel Binding ..................................38
14.2. Client Anonymity .........................................38
14.3. Server Trust .............................................39
14.4. Certificate Validation ...................................39
14.5. Certificate Compromise ...................................40
14.6. Forward Secrecy ..........................................40
14.7. Negotiating-Down Attacks .................................40
15. Message Sequences .............................................41
15.1. Successful Authentication via Tunneled CHAP ..............41
15.2. Successful Authentication via Tunneled
EAP/MD5-Challenge ........................................43
15.3. Successful Session Resumption ............................46
16. IANA Considerations ...........................................47
17. Acknowledgements ..............................................48
18. References ....................................................48
18.1. Normative References .....................................48
18.2. Informative References ...................................49
14. Security Considerations .......................................36
14.1. Security Claims ..........................................36
14.1.1. Authentication Mechanism ..........................36
14.1.2. Ciphersuite Negotiation ...........................37
14.1.3. Mutual Authentication .............................37
14.1.4. Integrity Protection ..............................37
14.1.5. Replay Protection .................................37
14.1.6. Confidentiality ...................................37
14.1.7. Key Derivation ....................................37
14.1.8. Key Strength ......................................37
14.1.9. Dictionary Attack Protection ......................38
14.1.10. Fast Reconnect ...................................38
14.1.11. Cryptographic Binding ............................38
14.1.12. Session Independence .............................38
14.1.13. Fragmentation ....................................38
14.1.14. Channel Binding ..................................38
14.2. Client Anonymity .........................................38
14.3. Server Trust .............................................39
14.4. Certificate Validation ...................................39
14.5. Certificate Compromise ...................................40
14.6. Forward Secrecy ..........................................40
14.7. Negotiating-Down Attacks .................................40
15. Message Sequences .............................................41
15.1. Successful Authentication via Tunneled CHAP ..............41
15.2. Successful Authentication via Tunneled
EAP/MD5-Challenge ........................................43
15.3. Successful Session Resumption ............................46
16. IANA Considerations ...........................................47
17. Acknowledgements ..............................................48
18. References ....................................................48
18.1. Normative References .....................................48
18.2. Informative References ...................................49
Extensible Authentication Protocol (EAP) [RFC3748] defines a standard message exchange that allows a server to authenticate a client using an authentication method agreed upon by both parties. EAP may be extended with additional authentication methods by registering such methods with IANA or by defining vendor-specific methods.
可扩展身份验证协议（EAP）[RFC3748]定义了一种标准消息交换，允许服务器使用双方商定的身份验证方法对客户端进行身份验证。EAP可以通过向IANA注册其他认证方法或通过定义特定于供应商的方法来扩展。
Transport Layer Security (TLS) [RFC4346] is an authentication protocol that provides for client authentication of a server or mutual authentication of client and server, as well as secure ciphersuite negotiation and key exchange between the parties. TLS has been defined as an authentication protocol for use within EAP (EAP-TLS) [RFC5216].
传输层安全性（TLS）[RFC4346]是一种身份验证协议，提供服务器的客户端身份验证或客户端和服务器的相互身份验证，以及双方之间的安全密码套件协商和密钥交换。TLS被定义为EAP内使用的认证协议（EAP-TLS）[RFC5216]。
Other authentication protocols are also widely deployed. These are typically password-based protocols, and there is a large installed base of support for these protocols in the form of credential databases that may be accessed by RADIUS [RFC2865], Diameter [RFC3588], or other AAA servers. These include non-EAP protocols such as PAP [RFC1661], CHAP [RFC1661], MS-CHAP [RFC2433], or MS-CHAP-V2 [RFC2759], as well as EAP protocols such as MD5-Challenge [RFC3748].
其他身份验证协议也被广泛部署。这些协议通常是基于密码的协议，并且这些协议的大量安装支持以凭据数据库的形式存在，可由RADIUS[RFC2865]、Diameter[RFC3588]或其他AAA服务器访问。这些协议包括非EAP协议，如PAP[RFC1661]、CHAP[RFC1661]、MS-CHAP[RFC2433]或MS-CHAP-V2[RFC2759]，以及EAP协议，如MD5挑战[RFC3748]。
EAP-TTLS is an EAP method that provides functionality beyond what is available in EAP-TLS. EAP-TTLS has been widely deployed and this specification documents what existing implementations do. It has some limitations and vulnerabilities, however. These are addressed in EAP-TTLS extensions and ongoing work in the creation of standardized tunneled EAP methods at the IETF. Users of EAP-TTLS are strongly encouraged to consider these in their deployments.
EAP-TTLS是一种EAP方法，它提供的功能超出了EAP-TLS中可用的功能。EAP-TTLS已被广泛部署，本规范记录了现有实现的功能。但是，它有一些局限性和漏洞。这些问题在EAP-TTLS扩展和IETF标准化隧道EAP方法创建的持续工作中得到了解决。EAP-TTLS的用户被强烈鼓励在它们的部署中考虑这些。
In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP-TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS authentication may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely deployed authentication infrastructures. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2.
在EAP-TLS中，TLS握手用于相互验证客户端和服务器。EAP-TTLS通过使用TLS握手建立的安全连接在客户端和服务器之间交换附加信息，扩展了这种身份验证协商。在EAP-TTLS中，TLS认证可以是相互的；或者它可能是单向的，在这种情况下，只有服务器通过了客户端的身份验证。然后，通过握手建立的安全连接可用于允许服务器使用现有的、广泛部署的认证基础设施认证客户端。客户端的认证可以是EAP本身，也可以是另一个认证协议，例如PAP、CHAP、MS-CHAP或MS-CHAP-V2。
Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.
因此，EAP-TTLS允许对现有身份验证数据库使用传统的基于密码的身份验证协议，同时保护这些传统协议的安全性，防止窃听、中间人攻击和其他攻击。
EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake.
EAP-TTLS还允许客户端和服务器建立密钥材料，用于客户端和访问点之间的数据连接。基于TLS握手，在客户端和服务器之间隐式地建立密钥材料。
In EAP-TTLS, client and server communicate using attribute-value pairs encrypted within TLS. This generality allows arbitrary functions beyond authentication and key exchange to be added to the EAP negotiation, in a manner compatible with the AAA infrastructure.
在EAP-TTLS中，客户端和服务器使用TLS中加密的属性值对进行通信。这种通用性允许以与AAA基础设施兼容的方式将身份验证和密钥交换以外的任意功能添加到EAP协商中。
The main limitation of EAP-TTLS is that its base version lacks support for cryptographic binding between the outer and inner authentication. Please refer to Section 14.1.11 for details and the conditions where this vulnerability exists. It should be noted that an extension for EAP-TTLS [TTLS-EXT] fixed this vulnerability. Users of EAP-TTLS are strongly encouraged to adopt this extension.
EAP-TTLS的主要限制是其基本版本不支持外部和内部身份验证之间的加密绑定。有关此漏洞存在的详细信息和条件，请参阅第14.1.11节。应注意，EAP-TTLS[TTLS-EXT]的扩展修复了此漏洞。强烈鼓励EAP-TTLS用户采用此扩展。
Most password-based protocols in use today rely on a hash of the password with a random challenge. Thus, the server issues a challenge, the client hashes that challenge with the password and forwards a response to the server, and the server validates that response against the user's password retrieved from its database. This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- Challenge, and EAP/One-Time Password.
目前使用的大多数基于密码的协议都依赖于带有随机质询的密码散列。因此，服务器发出质询，客户端使用密码对质询进行哈希运算并将响应转发给服务器，服务器根据从其数据库检索到的用户密码验证该响应。此通用方法描述CHAP、MS-CHAP、MS-CHAP-V2、EAP/MD5-挑战和EAP/一次性密码。
An issue with such an approach is that an eavesdropper that observes both challenge and response may be able to mount a dictionary attack, in which random passwords are tested against the known challenge to attempt to find one which results in the known response. Because passwords typically have low entropy, such attacks can in practice easily discover many passwords.
这种方法的一个问题是，同时观察质询和响应的窃听者可能会发起字典攻击，在这种攻击中，随机密码会针对已知质询进行测试，以试图找到导致已知响应的密码。由于密码通常具有低熵，因此此类攻击在实践中很容易发现许多密码。
While this vulnerability has long been understood, it has not been of great concern in environments where eavesdropping attacks are unlikely in practice. For example, users with wired or dial-up connections to their service providers have not been concerned that such connections may be monitored. Users have also been willing to entrust their passwords to their service providers, or at least to allow their service providers to view challenges and hashed responses which are then forwarded to their home authentication servers using, for example, proxy RADIUS, without fear that the service provider will mount dictionary attacks on the observed credentials. Because a user typically has a relationship with a single service provider, such trust is entirely manageable.
虽然人们早就了解了这一漏洞，但在实际上不太可能发生窃听攻击的环境中，这一漏洞并没有引起太大的关注。例如，与服务提供商有有线或拨号连接的用户并不担心这些连接会受到监控。用户还愿意将其密码委托给其服务提供商，或至少允许其服务提供商查看质询和哈希响应，然后使用代理RADIUS将这些质询和哈希响应转发给其家庭认证服务器，不用担心服务提供商会对观察到的凭据发起字典攻击。由于用户通常与单个服务提供商有关系，因此这种信任是完全可管理的。
With the advent of wireless connectivity, however, the situation changes dramatically:
然而，随着无线连接的出现，情况发生了巨大变化：
- Wireless connections are considerably more susceptible to eavesdropping and man-in-the-middle attacks. These attacks may enable dictionary attacks against low-entropy passwords. In addition, they may enable channel hijacking, in which an attacker gains fraudulent access by seizing control of the communications channel after authentication is complete.
- 无线连接更容易受到窃听和中间人攻击。这些攻击可能使字典攻击针对低熵密码。此外，它们还可能导致通道劫持，在这种情况下，攻击者通过在身份验证完成后夺取通信通道的控制权而获得欺诈性访问。
- Existing authentication protocols often begin by exchanging the client's username in the clear. In the context of eavesdropping on the wireless channel, this can compromise the client's anonymity and locational privacy.
- 现有的身份验证协议通常首先以明文形式交换客户端的用户名。在无线信道窃听的情况下，这可能会损害客户端的匿名性和位置隐私。
- Often in wireless networks, the access point does not reside in the administrative domain of the service provider with which the user has a relationship. For example, the access point may reside in an airport, coffee shop, or hotel in order to provide public access via 802.11 [802.11]. Even if password authentications are protected in the wireless leg, they may still be susceptible to eavesdropping within the untrusted wired network of the access point.
- 通常在无线网络中，接入点不位于与用户有关系的服务提供商的管理域中。例如，接入点可以驻留在机场、咖啡馆或酒店中，以便通过802.11[802.11]提供公共接入。即使密码认证在无线分支中受到保护，它们仍可能容易在接入点的不受信任有线网络中被窃听。
- In the traditional wired world, the user typically intentionally connects with a particular service provider by dialing an associated phone number; that service provider may be required to route an authentication to the user's home domain. In a wireless network, however, the user does not get to choose an access domain, and must connect with whichever access point is nearby; providing for the routing of the authentication from an arbitrary access point to the user's home domain may pose a challenge.
- 在传统的有线世界中，用户通常通过拨打相关联的电话号码来有意地与特定的服务提供商连接；该服务提供商可能需要将认证路由到用户的主域。然而，在无线网络中，用户不能选择接入域，必须与附近的接入点连接；提供从任意接入点到用户的主域的认证路由可能带来挑战。
Thus, the authentication requirements for a wireless environment that EAP-TTLS attempts to address can be summarized as follows:
因此，EAP-TTLS试图解决的无线环境的认证要求可以总结如下：
- Legacy password protocols must be supported, to allow easy deployment against existing authentication databases.
- 必须支持旧密码协议，以便轻松部署现有身份验证数据库。
- Password-based information must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against dictionary attacks.
- 在客户端节点和可信服务提供商之间的通信通道中，不得观察到基于密码的信息，以保护用户免受字典攻击。
- The user's identity must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against surveillance, undesired acquisition of marketing information, and the like.
- 用户的身份不得在客户端节点和可信服务提供商之间的通信信道中被观察到，以保护用户免受监视、不希望的营销信息获取等。
- The authentication process must result in the distribution of shared keying information to the client and access point to permit encryption and validation of the wireless data connection subsequent to authentication, to secure it against eavesdroppers and prevent channel hijacking.
- 身份验证过程必须将共享密钥信息分发给客户端和接入点，以允许在身份验证之后对无线数据连接进行加密和验证，从而保护其免受窃听者的攻击，并防止通道劫持。
- The authentication mechanism must support roaming among access domains with which the user has no relationship and which will have limited capabilities for routing authentication requests.
- 身份验证机制必须支持在与用户没有关系且路由身份验证请求的能力有限的访问域之间漫游。
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]中所述进行解释。
AAA
AAA
Authentication, Authorization, and Accounting - functions that are generally required to control access to a network and support billing and auditing.
身份验证、授权和记帐—通常需要这些功能来控制对网络的访问并支持计费和审核。
AAA protocol
AAA协议
A network protocol used to communicate with AAA servers; examples include RADIUS and Diameter.
用于与AAA服务器通信的网络协议；例如半径和直径。
AAA server
AAA服务器
A server which performs one or more AAA functions: authenticating a user prior to granting network service, providing authorization (policy) information governing the type of network service the user is to be granted, and accumulating accounting information about actual usage.
执行一个或多个AAA功能的服务器：在授予网络服务之前对用户进行身份验证，提供管理用户将被授予的网络服务类型的授权（策略）信息，以及积累有关实际使用情况的记帐信息。
AAA/H
AAA/H
A AAA server in the user's home domain, where authentication and authorization for that user are administered.
用户主域中的AAA服务器，用于管理该用户的身份验证和授权。
access point
接入点
A network device providing users with a point of entry into the network, and which may enforce access control and policy based on information returned by a AAA server. Since the access point terminates the server side of the EAP conversation, for the
一种网络设备，为用户提供进入网络的入口点，并可基于AAA服务器返回的信息实施访问控制和策略。由于接入点终止EAP会话的服务器端，因此
purposes of this document it is therefore equivalent to the "authenticator", as used in the EAP specification [RFC3748]. Since the access point acts as a client to a AAA server, for the purposes of this document it is therefore also equivalent to the "Network Access Server (NAS)", as used in AAA specifications such as [RFC2865].
因此，在本文件中，其等同于EAP规范[RFC3748]中使用的“验证器”。由于接入点充当AAA服务器的客户端，因此在本文档中，它也相当于AAA规范（如[RFC2865]）中使用的“网络接入服务器（NAS）”。
access domain
访问域
The domain, including access points and other devices, that provides users with an initial point of entry into the network; for example, a wireless hot spot.
为用户提供网络初始入口点的域，包括接入点和其他设备；例如，无线热点。
client
客户
A host or device that connects to a network through an access point. Since it terminates the client side of the EAP conversation, for the purposes of this document, it is therefore equivalent to the "peer", as used in the EAP specification [RFC3748].
通过接入点连接到网络的主机或设备。由于它终止了EAP会话的客户端，因此就本文档而言，它相当于EAP规范[RFC3748]中使用的“对等方”。
domain
领域
A network and associated devices that are under the administrative control of an entity such as a service provider or the user's home organization.
在诸如服务提供商或用户的家庭组织等实体的管理控制下的网络和相关设备。
link layer
链路层
A protocol used to carry data between hosts that are connected within a single network segment; examples include PPP and Ethernet.
用于在单个网段内连接的主机之间传输数据的协议；例如PPP和以太网。
NAI
奈
A Network Access Identifier [RFC4282], normally consisting of the name of the user and, optionally, the user's home realm.
一种网络访问标识符[RFC4282]，通常由用户名称和用户的主域（可选）组成。
proxy
代理
A server that is able to route AAA transactions to the appropriate AAA server, possibly in another domain, typically based on the realm portion of an NAI.
能够将AAA事务路由到适当的AAA服务器（可能在另一个域中）的服务器，通常基于NAI的域部分。
realm
领域
The optional part of an NAI indicating the domain to which a AAA transaction is to be routed, normally the user's home domain.
NAI的可选部分，指示AAA事务要路由到的域，通常是用户的主域。
service provider
服务提供商
An organization (with which a user has a business relationship) that provides network or other services. The service provider may provide the access equipment with which the user connects, may perform authentication or other AAA functions, may proxy AAA transactions to the user's home domain, etc.
提供网络或其他服务的组织（与用户有业务关系）。服务提供商可以提供用户与之连接的接入设备，可以执行认证或其他AAA功能，可以将AAA事务代理给用户的主域等。
TTLS server
TTLS服务器
A AAA server which implements EAP-TTLS. This server may also be capable of performing user authentication, or it may proxy the user authentication to a AAA/H.
实现EAP-TTLS的AAA服务器。该服务器还可以执行用户身份验证，或者它可以将用户身份验证代理给AAA/H。
user
使用者
The person operating the client device. Though the line is often blurred, "user" is intended to refer to the human being who is possessed of an identity (username), password, or other authenticating information, and "client" is intended to refer to the device which makes use of this information to negotiate network access. There may also be clients with no human operators; in this case, the term "user" is a convenient abstraction.
操作客户端设备的人。虽然界线经常模糊，“用户”指的是拥有身份（用户名）、密码或其他身份验证信息的人，“客户端”指的是利用这些信息协商网络访问的设备。也可能有没有人工操作员的客户；在这种情况下，术语“用户”是一种方便的抽象。
The network architectural model for EAP-TTLS usage and the type of security it provides is shown below.
EAP-TTLS使用的网络体系结构模型及其提供的安全类型如下所示。
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| client |<---->| access |<---->| TTLS AAA |<---->| AAA/H |
| | | point | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| client |<---->| access |<---->| TTLS AAA |<---->| AAA/H |
| | | point | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
<---- secure password authentication tunnel --->
<---- secure password authentication tunnel --->
<---- secure data tunnel ---->
<---- secure data tunnel ---->
The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the TTLS server and AAA/H server might be a single entity; the access point and TTLS server might be a single entity; or, indeed, the functions of the access point, TTLS server and AAA/H server might be combined into a single physical device. The above diagram illustrates the division of labor among entities in a general manner and shows how a
上面描述的实体是逻辑实体，可能对应于也可能不对应于单独的网络组件。例如，TTLS服务器和AAA/H服务器可能是单个实体；接入点和TTLS服务器可以是单个实体；或者，实际上，接入点、TTLS服务器和AAA/H服务器的功能可以组合到单个物理设备中。上图以一般方式说明了实体之间的分工，并显示了
distributed system might be constructed; however, actual systems might be realized more simply.
可以构建分布式系统；然而，实际系统的实现可能更简单。
Note also that one or more AAA proxy servers might be deployed between access point and TTLS server, or between TTLS server and AAA/H server. Such proxies typically perform aggregation or are required for realm-based message routing. However, such servers play no direct role in EAP-TTLS and are therefore not shown.
还请注意，一个或多个AAA代理服务器可能部署在接入点和TTLS服务器之间，或者部署在TTLS服务器和AAA/H服务器之间。这种代理通常执行聚合，或者是基于领域的消息路由所必需的。但是，此类服务器在EAP-TTL中不起直接作用，因此未显示。
The entities shown above communicate with each other using carrier protocols capable of encapsulating EAP. The client and access point communicate typically using a link layer carrier protocol such as PPP or EAPOL (EAP over LAN). The access point, TTLS server, and AAA/H server communicate using a AAA carrier protocol such as RADIUS or Diameter.
上面所示的实体使用能够封装EAP的载波协议彼此通信。客户端和接入点通常使用链路层载波协议进行通信，例如PPP或EAPOL（LAN上的EAP）。接入点、TTLS服务器和AAA/H服务器使用AAA载波协议（如RADIUS或Diameter）进行通信。
EAP, and therefore EAP-TTLS, must be initiated via the carrier protocol between client and access point. In PPP or EAPOL, for example, EAP is initiated when the access point sends an EAP-Request/Identity packet to the client.
EAP以及EAP-TTLS必须通过客户端和接入点之间的载波协议启动。例如，在PPP或EAPOL中，当接入点向客户端发送EAP请求/标识包时，EAP被启动。
The keying material used to encrypt and authenticate the data connection between the client and access point is developed implicitly between the client and TTLS server as a result of the EAP-TTLS negotiation. This keying material must be communicated to the access point by the TTLS server using the AAA carrier protocol.
作为EAP-TTLS协商的结果，客户端和TTLS服务器之间隐式开发了用于加密和验证客户端和接入点之间的数据连接的密钥材料。TTLS服务器必须使用AAA载波协议将该密钥资料传送到接入点。
The client and access point have no pre-existing security relationship.
客户端和访问点没有预先存在的安全关系。
The access point, TTLS server, and AAA/H server are each assumed to have a pre-existing security association with the adjacent entity with which it communicates. With RADIUS, for example, this is achieved using shared secrets. It is essential for such security relationships to permit secure key distribution.
接入点、TTLS服务器和AAA/H服务器均假定与与其通信的相邻实体具有预先存在的安全关联。例如，对于RADIUS，这是使用共享机密实现的。这种安全关系必须允许安全的密钥分发。
The client and AAA/H server have a security relationship based on the user's credentials such as a password.
客户端和AAA/H服务器具有基于用户凭据（如密码）的安全关系。
The client and TTLS server may have a one-way security relationship based on the TTLS server's possession of a private key guaranteed by a CA certificate which the user trusts, or may have a mutual security relationship based on certificates for both parties.
客户机和TTLS服务器可以具有基于TTLS服务器拥有由用户信任的CA证书保证的私钥的单向安全关系，或者可以具有基于双方证书的相互安全关系。
The client and access point initiate an EAP conversation to negotiate the client's access to the network. Typically, the access point issues an EAP-Request/Identity to the client, which responds with an EAP-Response/Identity. Note that the client need not include the user's actual identity in this EAP-Response/Identity packet other than for routing purposes (e.g., realm information; see Section 7.3 and [RFC3748], Section 5.1); the user's actual identity need not be transmitted until an encrypted channel has been established.
客户端和接入点发起EAP对话，以协商客户端对网络的访问。通常，接入点向客户端发出EAP请求/标识，客户端用EAP响应/标识进行响应。注意，除了用于路由目的（例如领域信息；参见第7.3节和[RFC3748]第5.1节），客户端不需要在该EAP响应/身份数据包中包含用户的实际身份；在建立加密信道之前，不需要传输用户的实际身份。
The access point now acts as a passthrough device, allowing the TTLS server to negotiate EAP-TTLS with the client directly.
接入点现在充当直通设备，允许TTLS服务器直接与客户端协商EAP-TTLS。
During the first phase of the negotiation, the TLS handshake protocol is used to authenticate the TTLS server to the client and, optionally, to authenticate the client to the TTLS server, based on public/private key certificates. As a result of the handshake, client and TTLS server now have shared keying material and an agreed upon TLS record layer cipher suite with which to secure subsequent EAP-TTLS communication.
在协商的第一阶段，TLS握手协议用于向客户机验证TTLS服务器，并且可选地，基于公钥/私钥证书向TTLS服务器验证客户机。握手的结果是，客户机和TTLS服务器现在共享了密钥材料和商定的TLS记录层密码套件，以确保后续EAP-TTLS通信的安全。
During the second phase of negotiation, client and TTLS server use the secure TLS record layer channel established by the TLS handshake as a tunnel to exchange information encapsulated in attribute-value pairs, to perform additional functions such as authentication (one-way or mutual), validation of client integrity and configuration, provisioning of information required for data connectivity, etc.
在协商的第二阶段，客户机和TTLS服务器使用TLS握手建立的安全TLS记录层通道作为隧道来交换封装在属性值对中的信息，以执行附加功能，例如身份验证（单向或双向）、验证客户机完整性和配置，提供数据连接等所需的信息。
If a tunneled client authentication is performed, the TTLS server de-tunnels and forwards the authentication information to the AAA/H. If the AAA/H issues a challenge, the TTLS server tunnels the challenge information to the client. The AAA/H server may be a legacy device and needs to know nothing about EAP-TTLS; it only needs to be able to authenticate the client based on commonly used authentication protocols.
如果执行隧道式客户端身份验证，则TTLS服务器将取消隧道并将身份验证信息转发给AAA/H。如果AAA/H发出质询，则TTLS服务器将质询信息隧道化到客户端。AAA/H服务器可能是遗留设备，不需要了解EAP-TTLS；它只需要能够根据常用的身份验证协议对客户端进行身份验证。
Keying material for the subsequent data connection between client and access point (Master Session Key / Extended Master Session Key (MSK/EMSK); see Section 8) is generated based on secret information developed during the TLS handshake between client and TTLS server. At the conclusion of a successful authentication, the TTLS server may transmit this keying material to the access point, encrypted based on the existing security associations between those devices (e.g., RADIUS).
客户机和接入点之间后续数据连接的密钥材料（主会话密钥/扩展主会话密钥（MSK/EMSK）；参见第8节）是根据客户机和TTLS服务器之间TLS握手过程中产生的秘密信息生成的。在成功的认证结束时，TTLS服务器可以将该密钥材料发送到接入点，并基于这些设备（例如RADIUS）之间的现有安全关联进行加密。
The client and access point now share keying material that they can use to encrypt data traffic between them.
客户端和访问点现在共享密钥材料，可用于加密它们之间的数据通信。
As the diagram above indicates, EAP-TTLS allows user identity and password information to be securely transmitted between client and TTLS server, and generates keying material to allow network data subsequent to authentication to be securely transmitted between client and access point.
如上图所示，EAP-TTLS允许在客户端和TTLS服务器之间安全传输用户身份和密码信息，并生成密钥材料，以允许在客户端和接入点之间安全传输认证后的网络数据。
EAP-TTLS packets are encapsulated within EAP, and EAP in turn requires a carrier protocol to transport it. EAP-TTLS packets themselves encapsulate TLS, which is then used to encapsulate attribute-value pairs (AVPs) which may carry user authentication or other information. Thus, EAP-TTLS messaging can be described using a layered model, where each layer is encapsulated by the layer beneath it. The following diagram clarifies the relationship between protocols:
EAP-TTLS数据包封装在EAP中，而EAP又需要一个载波协议来传输它。EAP-TTLS数据包本身封装TLS，然后用于封装可能携带用户身份验证或其他信息的属性值对（AVP）。因此，EAP-TTLS消息传递可以使用分层模型来描述，其中每一层都由其下的层封装。下图阐明了协议之间的关系：
+-----------------------------------------------------------+
| AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+
When the user authentication protocol is itself EAP, the layering is as follows:
当用户认证协议本身为EAP时，分层如下：
+-----------------------------------------------------------+
| EAP Method (MD-Challenge, etc.) |
+-----------------------------------------------------------+
| AVPs, including EAP |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| EAP Method (MD-Challenge, etc.) |
+-----------------------------------------------------------+
| AVPs, including EAP |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+
Methods for encapsulating EAP within carrier protocols are already defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to transport EAP between client and access point; RADIUS [RFC2865] or Diameter [RFC3588] are used to transport EAP between access point and TTLS server.
已经定义了在载波协议中封装EAP的方法。例如，PPP[RFC1661]或EAPOL[802.1X]可用于在客户端和接入点之间传输EAP；RADIUS[RFC2865]或Diameter[RFC3588]用于在接入点和TTLS服务器之间传输EAP。
A EAP-TTLS negotiation comprises two phases: the TLS handshake phase and the TLS tunnel phase.
EAP-TTLS协商包括两个阶段：TLS握手阶段和TLS隧道阶段。
During phase 1, TLS is used to authenticate the TTLS server to the client and, optionally, the client to the TTLS server. Phase 1 results in the activation of a cipher suite, allowing phase 2 to proceed securely using the TLS record layer. (Note that the type and degree of security in phase 2 depends on the cipher suite negotiated during phase 1; if the null cipher suite is negotiated, there will be no security!)
在第1阶段中，TLS用于向客户机验证TTLS服务器，或者向TTLS服务器验证客户机。第1阶段激活密码套件，允许第2阶段使用TLS记录层安全地进行。（请注意，第2阶段的安全类型和程度取决于第1阶段协商的密码套件；如果协商的是空密码套件，则不会有安全性！）
During phase 2, the TLS record layer is used to tunnel information between client and TTLS server to perform any of a number of functions. These might include user authentication, client integrity validation, negotiation of data communication security capabilities, key distribution, communication of accounting information, etc. Information between client and TTLS server is exchanged via attribute-value pairs (AVPs) compatible with RADIUS and Diameter; thus, any type of function that can be implemented via such AVPs may easily be performed.
在第2阶段，TLS记录层用于在客户端和TTLS服务器之间传输信息，以执行许多功能中的任何一项。这些可能包括用户身份验证、客户端完整性验证、数据通信安全能力协商、密钥分发、会计信息通信等。客户端和TTLS服务器之间的信息通过与RADIUS和Diameter兼容的属性值对（AVP）交换；因此，可以容易地执行可通过这种avp实现的任何类型的功能。
EAP-TTLS specifies how user authentication may be performed during phase 2. The user authentication may itself be EAP, or it may be a legacy protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Phase 2 user authentication may not always be necessary, since the user may already have been authenticated via the mutual authentication option of the TLS handshake protocol.
EAP-TTLS指定在阶段2期间如何执行用户身份验证。用户认证本身可以是EAP，也可以是传统协议，例如PAP、CHAP、MS-CHAP或MS-CHAP-V2。阶段2用户认证可能并不总是必要的，因为用户可能已经通过TLS握手协议的相互认证选项进行了认证。
Functions other than authentication MAY also be performed during phase 2. This document does not define any such functions; however, any organization or standards body is free to specify how additional functions may be performed through the use of appropriate AVPs.
在第2阶段，也可以执行除身份验证以外的功能。本文件未定义任何此类功能；但是，任何组织或标准机构都可以自由指定如何通过使用适当的AVP执行附加功能。
EAP-TTLS specifies how keying material for the data connection between client and access point is generated. The keying material is developed implicitly between client and TTLS server based on the results of the TLS handshake; the TTLS server will communicate the keying material to the access point over the carrier protocol.
EAP-TTLS指定如何生成客户端和访问点之间数据连接的键控材料。基于TLS握手的结果，在客户端和TTLS服务器之间隐式开发密钥材料；TTLS服务器将通过载波协议将密钥材料传送到接入点。
In phase 1, the TLS handshake protocol is used to authenticate the TTLS server to the client and, optionally, to authenticate the client to the TTLS server.
在阶段1中，TLS握手协议用于向客户机验证TTLS服务器，并可选地向TTLS服务器验证客户机。
The TTLS server initiates the EAP-TTLS method with an EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS and the S (Start) bit set. This indicates to the client that it should begin the TLS handshake by sending a ClientHello message.
TTLS服务器使用EAP-TTLS/Start数据包启动EAP-TTLS方法，该数据包是类型为EAP-TTLS并设置了S（Start）位的EAP请求。这向客户端指示它应该通过发送ClientHello消息来开始TLS握手。
EAP packets continue to be exchanged between client and TTLS server to complete the TLS handshake, as described in [RFC5216]. Phase 1 is completed when the client and TTLS server exchange ChangeCipherSpec and Finished messages. At this point, additional information may be securely tunneled.
EAP数据包继续在客户端和TTLS服务器之间交换，以完成TLS握手，如[RFC5216]中所述。当客户端和TTLS服务器交换更改CipherSpec和Finished消息时，阶段1完成。此时，可以安全地对附加信息进行隧道传输。
As part of the TLS handshake protocol, the TTLS server will send its certificate along with a chain of certificates leading to the certificate of a trusted CA. The client will need to be configured with the certificate of the trusted CA in order to perform the authentication.
作为TLS握手协议的一部分，TTLS服务器将发送其证书以及通向可信CA证书的证书链。客户端需要配置可信CA证书才能执行身份验证。
If certificate-based authentication of the client is desired, the client must have been issued a certificate and must have the private key associated with that certificate.
如果需要对客户端进行基于证书的身份验证，则客户端必须已被颁发证书，并且必须具有与该证书关联的私钥。
In phase 2, the TLS record layer is used to securely tunnel information between client and TTLS server. This information is encapsulated in sequences of attribute-value pairs (AVPs), whose use and format are described in later sections.
在阶段2中，TLS记录层用于在客户端和TTLS服务器之间安全地传输信息。该信息封装在属性值对（AVP）序列中，其使用和格式将在后面的章节中描述。
Any type of information may be exchanged during phase 2, according to the requirements of the system. (It is expected that applications utilizing EAP-TTLS will specify what information must be exchanged and therefore which AVPs must be supported.) The client begins the phase 2 exchange by encoding information in a sequence of AVPs, passing this sequence to the TLS record layer for encryption, and sending the resulting data to the TTLS server.
根据系统要求，任何类型的信息均可在第2阶段进行交换。（预计使用EAP-TTLS的应用程序将指定必须交换的信息以及必须支持的AVP。）客户机开始第2阶段交换，方法是将信息编码为AVP序列，将该序列传递给TLS记录层进行加密，并将结果数据发送到TTLS服务器。
The TTLS server recovers the AVPs in clear text from the TLS record layer. If the AVP sequence includes authentication information, it forwards this information to the AAA/H server using the AAA carrier protocol. Note that the EAP-TTLS and AAA/H servers may be one and the same; in which case, it simply processes the information locally.
TTLS服务器以明文形式从TLS记录层恢复AVP。如果AVP序列包括认证信息，则它使用AAA载波协议将该信息转发给AAA/H服务器。请注意，EAP-TTLS和AAA/H服务器可能是同一台服务器；在这种情况下，它只是在本地处理信息。
The TTLS server may respond with its own sequence of AVPs. The TTLS server passes the AVP sequence to the TLS record layer for encryption and sends the resulting data to the client. For example, the TTLS server may forward an authentication challenge received from the AAA/H.
TTLS服务器可以使用自己的AVP序列进行响应。TTLS服务器将AVP序列传递给TLS记录层进行加密，并将结果数据发送给客户端。例如，TTLS服务器可以转发从AAA/H接收的认证质询。
This process continues until the AAA/H either accepts or rejects the client, resulting in the TTLS server completing the EAP-TTLS negotiation and indicating success or failure to the encapsulating EAP protocol (which normally results in a final EAP-Success or EAP-Failure being sent to the client).
此过程将继续，直到AAA/H接受或拒绝客户端，从而导致TTLS服务器完成EAP-TTLS协商，并指示封装EAP协议的成功或失败（这通常会导致向客户端发送最终EAP成功或EAP失败）。
The TTLS server distributes data connection keying information and other authorization information to the access point in the same AAA carrier protocol message that carries the final EAP-Success or other success indication.
TTLS服务器在承载最终EAP成功或其他成功指示的同一AAA载波协议消息中向接入点分发数据连接密钥信息和其他授权信息。
The identity of the user is provided during phase 2, where it is protected by the TLS tunnel. However, prior to beginning the EAP-TTLS authentication, the client will typically issue an EAP-Response/Identity packet as part of the EAP protocol, containing a username in clear text. To preserve user anonymity against eavesdropping, this packet specifically SHOULD NOT include the actual name of the user; instead, it SHOULD use a blank or placeholder such as "anonymous". However, this privacy constraint is not intended to apply to any information within the EAP-Response/Identity that is required for routing; thus, the EAP-Response/Identity packet MAY include the name of the realm of a trusted provider to which EAP-TTLS packets should be forwarded; for example, "anonymous@myisp.com".
在第2阶段，用户的身份由TLS隧道保护。但是，在开始EAP-TTLS身份验证之前，客户端通常会发出一个EAP响应/标识包，作为EAP协议的一部分，其中包含一个明文用户名。为了保护用户匿名性以防窃听，此数据包特别不应包括用户的实际姓名；相反，它应该使用空白或占位符，如“匿名”。但是，该隐私约束不适用于路由所需的EAP响应/标识中的任何信息；因此，EAP响应/标识分组可以包括EAP-TTLS分组应当转发到的受信任提供者的域的名称；例如，”anonymous@myisp.com".
Note that at the time the initial EAP-Response/Identity packet is sent the EAP method is yet to be negotiated. If, in addition to EAP-TTLS, the client is willing to negotiate use of EAP methods that do not support user anonymity, then the client MAY include the name of the user in the EAP-Response/Identity to meet the requirements of the other candidate EAP methods.
注意，在发送初始EAP响应/标识数据包时，EAP方法尚未协商。如果除EAP-TTLS外，客户机愿意协商使用不支持用户匿名性的EAP方法，则客户机可以在EAP响应/身份中包括用户的姓名，以满足其他候选EAP方法的要求。
While it is convenient to describe EAP-TTLS messaging in terms of two phases, it is sometimes required that a single EAP-TTLS packet contain both phase 1 and phase 2 TLS messages.
虽然可以方便地从两个阶段描述EAP-TTLS消息，但有时要求单个EAP-TTLS数据包同时包含阶段1和阶段2 TLS消息。
Such "piggybacking" occurs when the party that completes the handshake also has AVPs to send. For example, when negotiating a resumed TLS session, the TTLS server sends its ChangeCipherSpec and
当完成握手的一方也要发送AVP时，就会发生这种“背驮”。例如，协商恢复的TLS会话时，TTLS服务器发送其ChangeCipherSpec和
Finished messages first, then the client sends its own ChangeCipherSpec and Finished messages to conclude the handshake. If the client has authentication or other AVPs to send to the TTLS server, it MUST tunnel those AVPs within the same EAP-TTLS packet immediately following its Finished message. If the client fails to do this, the TTLS server will incorrectly assume that the client has no AVPs to send, and the outcome of the negotiation could be affected.
首先完成消息，然后客户端发送自己的ChangeCipherSpec和完成消息以结束握手。如果客户端具有要发送到TTLS服务器的身份验证或其他AVP，则必须在完成消息后立即将这些AVP隧道到同一EAP-TTLS数据包中。如果客户端未能做到这一点，TTLS服务器将错误地认为客户端没有要发送的AVP，协商的结果可能会受到影响。
When a client and TTLS server that have previously negotiated an EAP-TTLS session begin a new EAP-TTLS negotiation, the client and TTLS server MAY agree to resume the previous session. This significantly reduces the time required to establish the new session. This could occur when the client connects to a new access point, or when an access point requires reauthentication of a connected client.
当先前协商过EAP-TTLS会话的客户端和TTLS服务器开始新的EAP-TTLS协商时，客户端和TTLS服务器可能同意恢复先前的会话。这大大减少了建立新会话所需的时间。当客户端连接到新的访问点时，或者当访问点需要对连接的客户端进行重新身份验证时，可能会发生这种情况。
Session resumption is accomplished using the standard TLS mechanism. The client signals its desire to resume a session by including the session ID of the session it wishes to resume in the ClientHello message; the TTLS server signals its willingness to resume that session by echoing that session ID in its ServerHello message.
会话恢复是使用标准TLS机制完成的。客户端通过在ClientHello消息中包括其希望恢复的会话的会话ID来表示其希望恢复会话；TTLS服务器通过在其ServerHello消息中回显会话ID来表示愿意恢复该会话。
If the TTLS server elects not to resume the session, it simply does not echo the session ID, causing a new session to be negotiated. This could occur if the TTLS server is configured not to resume sessions, if it has not retained the requested session's state, or if the session is considered stale. A TTLS server may consider the session stale based on its own configuration, or based on session-limiting information received from the AAA/H (e.g., the RADIUS Session-Timeout attribute).
如果TTLS服务器选择不恢复会话，它只是不回显会话ID，从而导致协商新会话。如果TTLS服务器配置为不恢复会话、未保留请求的会话状态或会话被视为过时，则可能发生这种情况。TTLS服务器可以考虑基于自身配置的会话过时，或者基于从AAA/H接收的会话限制信息（例如，RADIUS会话超时属性）。
Tunneled authentication is specifically not performed for resumed sessions; the presumption is that the knowledge of the master secret (as evidenced by the ability to resume the session) is authentication enough. This allows session resumption to occur without any messaging between the TTLS server and the AAA/H. If periodic reauthentication to the AAA/H is desired, the AAA/H must indicate this to the TTLS server when the original session is established, for example, using the RADIUS Session-Timeout attribute.
对于恢复的会话，专门不执行隧道身份验证；假设对主秘密的了解（通过恢复会话的能力证明）就足够了。这允许在TTLS服务器和AAA/H之间不发送任何消息的情况下进行会话恢复。如果需要定期对AAA/H进行重新验证，则AAA/H必须在建立原始会话时向TTLS服务器指示这一点，例如，使用RADIUS会话超时属性。
The client MAY send other AVPs in its first phase 2 message of a session resumption, to initiate non-authentication functions. If it does not, the TTLS server, at its option, MAY send AVPs to the client to initiate non-authentication functions, or MAY simply complete the EAP-TTLS negotiation and indicate success or failure to the encapsulating EAP protocol.
客户端可以在会话恢复的第一阶段2消息中发送其他avp，以启动非认证功能。如果没有，TTLS服务器可以选择向客户端发送AVP以启动非身份验证功能，或者可以简单地完成EAP-TTLS协商并指示封装EAP协议的成功或失败。
The TTLS server MUST retain authorization information returned by the AAA/H for use in resumed sessions. A resumed session MUST operate under the same authorizations as the original session, and the TTLS server must be prepared to send the appropriate information back to the access point. Authorization information might include the maximum time for the session, the maximum allowed bandwidth, packet filter information, and the like. The TTLS server is responsible for modifying time values, such as Session-Timeout, appropriately for each resumed session.
TTLS服务器必须保留AAA/H返回的授权信息，以便在恢复的会话中使用。恢复的会话必须在与原始会话相同的授权下运行，并且TTLS服务器必须准备好将适当的信息发送回访问点。授权信息可以包括会话的最长时间、允许的最大带宽、包过滤器信息等。TTLS服务器负责为每个恢复的会话适当地修改时间值，例如会话超时。
A TTLS server MUST NOT permit a session to be resumed if that session did not result in a successful authentication of the user during phase 2. The consequence of incorrectly implementing this aspect of session resumption would be catastrophic; any attacker could easily gain network access by first initiating a session that succeeds in the TLS handshake but fails during phase 2 authentication, and then resuming that session.
如果会话在第2阶段未成功验证用户，则TTLS服务器不得允许恢复该会话。错误地执行会话恢复的这一方面的后果将是灾难性的；通过首先启动TLS握手成功但在第2阶段身份验证期间失败的会话，然后恢复该会话，任何攻击者都可以轻松获得网络访问权。
[Implementation note: Toolkits that implement TLS often cache resumable TLS sessions automatically. Implementers must take care to override such automatic behavior, and prevent sessions from being cached for possible resumption until the user has been positively authenticated during phase 2.]
[实施说明：实现TLS的工具包通常会自动缓存可恢复的TLS会话。实施者必须注意覆盖此类自动行为，并防止会话被缓存以进行可能的恢复，直到用户在第2阶段获得了肯定的身份验证。]
Entering phase 2 is optional, and may be initiated by either client or TTLS server. If no further authentication or other information exchange is required upon completion of phase 1, it is possible to successfully complete the EAP-TTLS negotiation without ever entering phase 2 or tunneling any AVPs.
进入阶段2是可选的，可以由客户端或TTLS服务器启动。如果在第1阶段完成后不需要进一步认证或其他信息交换，则可以成功完成EAP-TTLS协商，而无需进入第2阶段或通过隧道传输任何AVP。
Scenarios in which phase 2 is never entered include:
从未进入第2阶段的场景包括：
- Successful session resumption, with no additional information exchange required,
- 成功恢复会话，无需额外信息交换，
- Authentication of the client via client certificate during phase 1, with no additional authentication or information exchange required.
- 在第1阶段，通过客户端证书对客户端进行身份验证，无需额外的身份验证或信息交换。
The client always has the first opportunity to initiate phase 2 upon completion of phase 1. If the client has no AVPs to send, it either sends an Acknowledgement (see Section 9.2.3) if the TTLS server sends the final phase 1 message, or simply does not piggyback a phase 2 message when it issues the final phase 1 message (as will occur during session resumption).
完成阶段1后，客户始终有第一次机会启动阶段2。如果客户机没有要发送的AVP，则如果TTLS服务器发送最终的第1阶段消息，则客户机将发送确认（参见第9.2.3节），或者在发出最终的第1阶段消息时，客户机根本不携带第2阶段消息（会话恢复期间将发生这种情况）。
If the client does not initiate phase 2, the TTLS server, at its option, may either complete the EAP-TTLS negotiation without entering phase 2 or initiate phase 2 by tunneling AVPs to the client.
如果客户端未启动阶段2，TTLS服务器可自行选择在不进入阶段2的情况下完成EAP-TTLS协商，或通过将AVP隧道传输到客户端来启动阶段2。
For example, suppose a successful session resumption occurs in phase 1. The following sequences are possible:
例如，假设在阶段1中成功恢复会话。以下顺序是可能的：
- Neither the client nor TTLS server has additional information to exchange. The client completes phase 1 without piggybacking phase 2 AVPs, and the TTLS server indicates success to the encapsulating EAP protocol without entering phase 2.
- 客户端和TTLS服务器都没有要交换的其他信息。客户端完成阶段1而不搭载阶段2 AVP，TTLS服务器表示封装EAP协议成功，而不进入阶段2。
- The client has no additional information to exchange, but the TTLS server does. The client completes phase 1 without piggybacking phase 2 AVPs, but the TTLS server extends the EAP-TTLS negotiation into phase 2 by tunneling AVPs in its next EAP-TTLS message.
- 客户端没有要交换的其他信息，但TTLS服务器有。客户机完成阶段1，但没有搭载阶段2 AVP，但TTLS服务器通过在其下一个EAP-TTLS消息中隧道AVP，将EAP-TTLS协商扩展到阶段2。
- The client has additional information to exchange, and piggybacks phase 2 AVPs with its final phase 1 message, thus extending the negotiation into phase 2.
- 客户机需要交换额外的信息，并将第2阶段的AVP与最终的第1阶段消息相结合，从而将协商扩展到第2阶段。
TLS version 1.0 [RFC2246], 1.1 [RFC4346], or any subsequent version MAY be used within EAP-TTLS. TLS provides for its own version negotiation mechanism.
EAP-TTLS中可使用TLS版本1.0[RFC2246]、1.1[RFC4346]或任何后续版本。TLS提供了自己的版本协商机制。
For maximum interoperability, EAP-TTLS implementations SHOULD support TLS version 1.0.
为了实现最大的互操作性，EAP-TTLS实现应支持TLS版本1.0。
EAP-TTLSv0 utilizes a pseudo-random function (PRF) to generate keying material (Section 8) and to generate implicit challenge material for certain authentication methods (Section 11.1). The PRF used in these computations is the TLS PRF used in the TLS handshake negotiation that initiates the EAP-TTLS exchange.
EAP-TTLSv0利用伪随机函数（PRF）生成密钥材料（第8节），并生成特定认证方法的隐式质询材料（第11.1节）。这些计算中使用的PRF是启动EAP-TTLS交换的TLS握手协商中使用的TLS PRF。
TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF function, and any EAP-TTLSv0 implementation based on these versions of TLS must use the PRF defined therein. It is expected that future versions of or extensions to the TLS protocol will permit alternative PRF functions to be negotiated. If an alternative PRF function is specified for the underlying TLS version or has been negotiated during the TLS handshake negotiation, then that alternative PRF function must be used in EAP-TTLSv0 computations instead of the TLS 1.0/1.1 PRF.
TLS版本1.0[RFC2246]和1.1[RFC4346]定义了相同的PRF功能，任何基于这些TLS版本的EAP-TTLSv0实现都必须使用其中定义的PRF。预计TLS协议的未来版本或扩展将允许协商替代PRF功能。如果为基础TLS版本指定了替代PRF函数，或在TLS握手协商期间协商了替代PRF函数，则该替代PRF函数必须在EAP-TTLSv0计算中使用，而不是TLS 1.0/1.1 PRF。
The TLS PRF function used in this specification is denoted as follows:
本规范中使用的TLS PRF功能表示如下：
PRF-nn(secret, label, seed)
PRF nn（秘密、标签、种子）
where:
哪里：
nn is the number of generated octets
nn是生成的八位字节数
secret is a secret key
秘密是一把秘密钥匙
label is a string (without null-terminator)
标签是字符串（不带空终止符）
seed is a binary sequence.
种子是一个二进制序列。
The TLS 1.0/1.1 PRF has invariant output regardless of how many octets are generated. However, it is possible that alternative PRF functions will include the size of the output sequence as input to the PRF function; this means generating 32 octets and generating 64 octets from the same input parameters will no longer result in the first 32 octets being identical. For this reason, the PRF is always specified with an "nn", indicating the number of generated octets.
TLS 1.0/1.1 PRF具有不变的输出，无论生成多少个八位字节。然而，替代PRF功能可能包括输出序列的大小作为PRF功能的输入；这意味着从相同的输入参数生成32个八位字节和64个八位字节将不再导致前32个八位字节相同。因此，PRF总是用“nn”指定，表示生成的八位字节数。
Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of keying material are generated and exported for use in securing the data connection between client and access point. The first 64 octets of the keying material constitute the MSK, the second 64 octets constitute the EMSK.
EAP-TTLS协商成功后，生成并导出128个八位字节的密钥材料，用于保护客户端和接入点之间的数据连接。键控材料的前64个八位组构成MSK，后64个八位组构成EMSK。
The keying material is generated using the TLS PRF function [RFC4346], with inputs consisting of the TLS master secret, the ASCII-encoded constant string "ttls keying material", the TLS client random, and the TLS server random. The constant string is not null-terminated.
使用TLS PRF函数[RFC4346]生成键控材料，输入包括TLS主密钥、ASCII编码常量字符串“ttls键控材料”、TLS客户端随机和TLS服务器随机。常量字符串不是以null结尾的。
Keying Material = PRF-128(SecurityParameters.master_secret, "ttls keying material", SecurityParameters.client_random + SecurityParameters.server_random)
密钥材料=PRF-128（SecurityParameters.master\u secret，“ttls密钥材料”，SecurityParameters.client\u random+SecurityParameters.server\u random）
MSK = Keying Material [0..63]
MSK=键控材质[0..63]
EMSK = Keying Material [64..127]
EMSK=键控材料[64..127]
Note that the order of client_random and server_random for EAP-TTLS is reversed from that of the TLS protocol [RFC4346]. This ordering follows the key derivation method of EAP-TLS [RFC5216]. Altering the order of randoms avoids namespace collisions between constant strings defined for EAP-TTLS and those defined for the TLS protocol.
注意，EAP-TTLS的客户端随机和服务器随机顺序与TLS协议的顺序相反[RFC4346]。该排序遵循EAP-TLS[RFC5216]的密钥推导方法。更改随机数的顺序可以避免为EAP-TTLS定义的常量字符串与为TLS协议定义的常量字符串之间的名称空间冲突。
The TTLS server distributes this keying material to the access point via the AAA carrier protocol. When RADIUS is the AAA carrier protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548] may be used to distribute the first 32 octets and second 32 octets of the MSK, respectively.
TTLS服务器通过AAA载波协议将该密钥材料分发到接入点。当RADIUS是AAA载波协议时，MPPE Recv密钥和MPPE发送密钥属性[RFC2548]可分别用于分发MSK的前32个八位字节和第二32个八位字节。
The EAP-TTLS packet format is shown below. The fields are transmitted left to right.
EAP-TTLS数据包格式如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 1 for request, 2 for response.
代码1表示请求，代码2表示响应。
Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed for each request packet and MUST be echoed in each response packet.
标识符标识符字段是一个八位字节，有助于将响应与请求匹配。必须为每个请求数据包更改标识符字段，并且必须在每个响应数据包中回显。
Length The Length field is two octets and indicates the number of octets in the entire EAP packet, from the Code field through the Data field.
长度长度字段为两个八位字节，表示从代码字段到数据字段的整个EAP数据包中的八位字节数。
Type 21 (EAP-TTLS)
21型（EAP-TTLS）
Flags
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| L | M | S | R | R | V |
+---+---+---+---+---+---+---+---+
Flags
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| L | M | S | R | R | V |
+---+---+---+---+---+---+---+---+
L = Length included M = More fragments S = Start R = Reserved V = Version (000 for EAP-TTLSv0)
L=包含的长度M=更多碎片S=开始R=保留V=版本（000用于EAP-TTLSv0）
The L bit is set to indicate the presence of the four-octet TLS Message Length field. The M bit indicates that more fragments are to come. The S bit indicates a Start message. The V field is set to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0.
L位设置为指示存在四个八位TLS消息长度字段。M位表示将出现更多碎片。S位表示开始消息。V字段设置为EAP-TTLS版本，EAP-TTLSv0设置为000。
Message Length The Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the raw data message sequence prior to fragmentation.
消息长度消息长度字段为四个八位字节，仅当设置了L位时才出现。此字段提供分段前原始数据消息序列的总长度。
Data For all packets other than a Start packet, the Data field consists of the raw TLS message sequence or fragment thereof. For a Start packet, the Data field may optionally contain an AVP sequence.
对于除起始数据包以外的所有数据包，数据字段由原始TLS消息序列或其片段组成。对于起始分组，数据字段可以可选地包含AVP序列。
The S bit MUST be set on the first packet sent by the server to initiate the EAP-TTLS protocol. It MUST NOT be set on any other packet.
必须在服务器发送的第一个数据包上设置S位，以启动EAP-TTLS协议。不得将其设置在任何其他数据包上。
This packet MAY contain additional information in the form of AVPs, which may provide useful hints to the client; for example, the server identity may be useful to the client to allow it to pick the correct TLS session ID for session resumption. Each AVP must begin on a four-octet boundary relative to the first AVP in the sequence. If an AVP is not a multiple of four octets, it must be padded with zeros to the next four-octet boundary.
该分组可包含avp形式的附加信息，其可向客户端提供有用的提示；例如，服务器标识可能对客户端有用，以允许客户端为会话恢复选择正确的TLS会话ID。每个AVP必须从相对于序列中第一个AVP的四个八位组边界开始。如果AVP不是四个八位字节的倍数，则必须用零填充到下一个四个八位字节边界。
The version of EAP-TTLS is negotiated in the first exchange between server and client. The server sets the highest version number of EAP-TTLS that it supports in the V field of its Start message (in the case of EAP-TTLSv0, this is 0). In its first EAP message in response, the client sets the V field to the highest version number
EAP-TTLS的版本在服务器和客户端之间的第一次交换中协商。服务器在其开始消息的V字段中设置其支持的EAP-TTLS的最高版本号（对于EAP-TTLSv0，这是0）。在响应的第一条EAP消息中，客户端将V字段设置为最高版本号
that it supports that is no higher than the version number offered by the server. If the client version is not acceptable to the server, it sends an EAP-Failure to terminate the EAP session. Otherwise, the version sent by the client is the version of EAP-TTLS that MUST be used, and both server and client MUST set the V field to that version number in all subsequent EAP messages.
它支持的版本号不高于服务器提供的版本号。如果服务器不接受客户端版本，则会发送EAP故障以终止EAP会话。否则，客户端发送的版本是必须使用的EAP-TTLS版本，并且服务器和客户端必须在所有后续EAP消息中将V字段设置为该版本号。
Each EAP-TTLS message contains a single leg of a half-duplex conversation. The EAP carrier protocol (e.g., PPP, EAPOL, RADIUS) may impose constraints on the length of an EAP message. Therefore it may be necessary to fragment an EAP-TTLS message across multiple EAP messages.
每个EAP-TTLS消息都包含半双工会话的一个分支。EAP载波协议（例如，PPP、EAPOL、RADIUS）可对EAP消息的长度施加约束。因此，可能有必要跨多个EAP消息对EAP-TTLS消息进行分段。
Each fragment except for the last MUST have the M bit set, to indicate that more data is to follow; the final fragment MUST NOT have the M bit set.
除最后一个片段外，每个片段都必须设置M位，以指示后续将有更多数据；最后一个片段不能设置M位。
If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant).
如果有多个片段，则第一个片段必须设置L位，并包括片段之前整个原始消息的长度。第一个片段以外的片段不得设置L位。未分段的消息可能设置了L位，并包括消息的长度（尽管此信息是冗余的）。
Upon receipt of a packet with the M bit set, the receiver MUST transmit an Acknowledgement packet. The receiver is responsible for reassembly of fragmented packets.
在接收到设置了M位的数据包时，接收器必须发送确认数据包。接收器负责重新组装碎片数据包。
An Acknowledgement packet is an EAP-TTLS packet with no additional data beyond the Flags octet, and with the L, M, and S bits of the Flags octet set to 0. (Note, however, that the V field MUST still be set to the appropriate version number.)
确认数据包是EAP-TTLS数据包，除标志八位字节外没有其他数据，标志八位字节的L、M和S位设置为0。（但是，请注意，V字段仍必须设置为相应的版本号。）
An Acknowledgement packet is sent for the following purposes:
发送确认数据包的目的如下：
- A Fragment Acknowledgement is sent in response to an EAP packet with the M bit set.
- 片段确认被发送以响应设置了M位的EAP分组。
- When the final EAP packet of the EAP-TTLS negotiation is sent by the TTLS server, the client must respond with an Acknowledgement packet, to allow the TTLS server to proceed with the EAP protocol upon completion of EAP-TTLS (typically by sending or causing to be sent a final EAP-Success or EAP-Failure to the client).
- 当TTLS服务器发送EAP-TTLS协商的最终EAP数据包时，客户端必须用确认数据包进行响应，以允许TTLS服务器在EAP-TTLS完成后继续执行EAP协议（通常通过向客户端发送或导致发送最终EAP成功或EAP失败）。
Subsequent to the TLS handshake, information may be tunneled between client and TTLS server through the use of attribute-value pairs (AVPs) encrypted within the TLS record layer.
在TLS握手之后，可以通过使用TLS记录层中加密的属性值对（AVP），在客户端和TTLS服务器之间通过隧道传输信息。
The AVP format chosen for EAP-TTLS is compatible with the Diameter AVP format. This does not represent a requirement that Diameter be supported by any of the devices or servers participating in an EAP-TTLS negotiation. Use of this format is merely a convenience. Diameter is a superset of RADIUS and includes the RADIUS attribute namespace by definition, though it does not limit the size of an AVP as does RADIUS; RADIUS, in turn, is a widely deployed AAA protocol and attribute definitions exist for all commonly used password authentication protocols, including EAP.
为EAP-TTLS选择的AVP格式与Diameter AVP格式兼容。这并不表示参与EAP-TTLS协商的任何设备或服务器都必须支持Diameter。使用这种格式只是为了方便。Diameter是RADIUS的超集，定义中包含RADIUS属性名称空间，但它不像RADIUS那样限制AVP的大小；RADIUS是一种广泛部署的AAA协议，所有常用的密码认证协议（包括EAP）都有属性定义。
Thus, Diameter is not considered normative except as specified in this document. Specifically, the representation of the Data field of an AVP in EAP-TTLS is identical to that of Diameter.
因此，除非本文件另有规定，否则不认为直径是规范性的。具体而言，EAP-TTLS中AVP数据字段的表示与Diameter的表示相同。
Use of the RADIUS/Diameter namespace allows a TTLS server to easily translate between AVPs it uses to communicate to clients and the protocol requirements of AAA servers that are widely deployed. Plus, it provides a well-understood mechanism to allow vendors to extend that namespace for their particular requirements.
RADIUS/Diameter名称空间的使用允许TTLS服务器在其用于与客户端通信的AVP和广泛部署的AAA服务器的协议要求之间轻松转换。此外，它还提供了一种易于理解的机制，允许供应商根据其特定需求扩展该名称空间。
It is expected that the AVP Codes used in EAP-TTLS will carry roughly the same meaning in EAP-TTLS as they do in Diameter and, by extension, RADIUS. However, although EAP-TTLS uses the same AVP Codes and syntax as Diameter, the semantics may differ, and most Diameter AVPs do not have any well-defined semantics in EAP-TTLS. A separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be used within EAP-TTLS and their semantics in this context (see Section 16 for details). A TTLS server copying AVPs between an EAP-TTLS exchange and a Diameter or RADIUS exchange with a backend MUST NOT make assumptions about AVPs whose usage in either EAP-TTLS or the backend protocol it does not understand. Therefore, a TTLS server MUST NOT copy an AVP between an EAP-TTLS exchange and a Diameter or RADIUS exchange unless the semantics of the AVP are understood and defined in both contexts.
预计EAP-TTLS中使用的AVP代码在EAP-TTLS中的含义与直径以及延伸至半径的含义大致相同。然而，尽管EAP-TTLS使用与Diameter相同的AVP代码和语法，但语义可能不同，并且大多数Diameter AVP在EAP-TTLS中没有任何定义良好的语义。单独的“EAP-TTLS AVP用法”注册表列出了可在EAP-TTLS中使用的AVP及其在此上下文中的语义（有关详细信息，请参阅第16节）。在EAP-TTLS交换和带有后端的Diameter或RADIUS交换之间复制AVP的TTLS服务器不得对其在EAP-TTLS或后端协议中的使用情况作出假设。因此，TTLS服务器不得在EAP-TTLS交换和Diameter或RADIUS交换之间复制AVP，除非在两种上下文中都理解并定义了AVP的语义。
The format of an AVP is shown below. All items are in network, or big-endian, order; that is, they have the most significant octet first.
AVP的格式如下所示。所有项目都是在网络，或大端，秩序；也就是说，它们首先有最重要的八位组。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code The AVP Code is four octets and, combined with the Vendor-ID field if present, identifies the attribute uniquely. The first 256 AVP numbers represent attributes defined in RADIUS [RFC2865]. AVP numbers 256 and above are defined in Diameter [RFC3588].
AVP代码AVP代码为四个八位字节，与供应商ID字段（如果存在）相结合，可唯一标识属性。前256个AVP编号表示RADIUS[RFC2865]中定义的属性。AVP编号256及以上在直径[RFC3588]中定义。
AVP Flags
AVP标志
The AVP Flags field is one octet and provides the receiver with information necessary to interpret the AVP.
AVP标志字段是一个八位字节，为接收机提供解释AVP所需的信息。
The 'V' (Vendor-Specific) bit indicates whether the optional Vendor-ID field is present. When set to 1, the Vendor-ID field is present and the AVP Code is interpreted according to the namespace defined by the vendor indicated in the Vendor-ID field.
“V”（供应商特定）位指示可选供应商ID字段是否存在。设置为1时，将显示供应商ID字段，并根据供应商ID字段中指示的供应商定义的名称空间解释AVP代码。
The 'M' (Mandatory) bit indicates whether support of the AVP is required. If this bit is set to 0, this indicates that the AVP may be safely ignored if the receiving party does not understand or support it. If set to 1, this indicates that the receiving party MUST fail the negotiation if it does not understand the AVP; for a TTLS server, this would imply returning EAP-Failure, for a client, this would imply abandoning the negotiation.
“M”（必填）位表示是否需要AVP支持。如果该位设置为0，则表示如果接收方不理解或不支持AVP，则可以安全地忽略该AVP。如果设置为1，则表示如果接收方不理解AVP，则其协商必须失败；对于TTLS服务器，这意味着返回EAP故障，对于客户端，这意味着放弃协商。
The 'r' (reserved) bits are unused and MUST be set to 0 by the sender and MUST be ignored by the receiver.
“r”（保留）位未使用，发送方必须将其设置为0，接收方必须忽略。
AVP Length
AVP长度
The AVP Length field is three octets and indicates the length of this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID (if present), and Data.
AVP长度字段为三个八位字节，表示此AVP的长度，包括AVP代码、AVP长度、AVP标志、供应商ID（如果存在）和数据。
Vendor-ID
供应商ID
The Vendor-ID field is present if the V bit is set in the AVP Flags field. It is four octets and contains the vendor's IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC3232] value. Vendors defining their own AVPs must maintain a consistent namespace for use of those AVPs within RADIUS, Diameter, and EAP-TTLS.
如果在AVP标志字段中设置了V位，则存在供应商ID字段。它是四个八位字节，包含供应商IANA分配的“SMI网络管理私有企业代码”[RFC3232]值。定义自己的AVP的供应商必须在RADIUS、Diameter和EAP-TTL中为这些AVP的使用维护一致的命名空间。
A Vendor-ID value of zero is equivalent to absence of the Vendor-ID field altogether.
供应商ID值为零等于完全不存在供应商ID字段。
Note that the M bit provides a means for extending the functionality of EAP-TTLS while preserving backward compatibility when desired. By setting the M bit of the appropriate AVP(s) to 0 or 1, the party initiating the function indicates that support of the function by the other party is either optional or required.
注意，M位提供了一种扩展EAP-TTLS功能的方法，同时在需要时保持向后兼容性。通过将适当AVP的M位设置为0或1，启动该功能的一方表示另一方对该功能的支持是可选的或必需的。
Data encapsulated within the TLS record layer must consist entirely of a sequence of zero or more AVPs. Each AVP must begin on a four-octet boundary relative to the first AVP in the sequence. If an AVP is not a multiple of four octets, it must be padded with zeros to the next four-octet boundary.
封装在TLS记录层中的数据必须完全由零个或多个AVP序列组成。每个AVP必须从相对于序列中第一个AVP的四个八位组边界开始。如果AVP不是四个八位字节的倍数，则必须用零填充到下一个四个八位字节边界。
Note that the AVP Length does not include the padding.
请注意，AVP长度不包括填充。
For maximum compatibility with AAA servers, the following guidelines for AVP usage are suggested:
为了最大限度地与AAA服务器兼容，建议使用以下AVP指南：
- Non-vendor-specific AVPs intended for use with AAA servers should be selected from the set of attributes defined for RADIUS; that is, attributes with codes less than 256. This provides compatibility with both RADIUS and Diameter.
- 用于AAA服务器的非供应商特定AVP应从为RADIUS定义的属性集中选择；即代码小于256的属性。这提供了与半径和直径的兼容性。
- Vendor-specific AVPs intended for use with AAA servers should be defined in terms of RADIUS. Vendor-specific RADIUS attributes translate to Diameter (and, hence, to EAP-TTLS) automatically; the reverse is not true. RADIUS vendor-specific attributes use RADIUS attribute 26 and include Vendor-ID, vendor-specific attribute code, and length; see [RFC2865] for details.
- 用于AAA服务器的供应商特定AVP应根据RADIUS进行定义。供应商特定半径属性自动转换为直径（因此，转换为EAP-TTLS）；事实并非如此。RADIUS供应商特定属性使用RADIUS属性26，包括供应商ID、供应商特定属性代码和长度；详见[RFC2865]。
EAP-TTLS permits user authentication information to be tunneled within the TLS record layer between client and TTLS server, ensuring the security of the authentication information against active and passive attack between the client and TTLS server. The TTLS server decrypts and forwards this information to the AAA/H over the AAA carrier protocol.
EAP-TTLS允许用户身份验证信息在客户端和TTLS服务器之间的TLS记录层中进行隧道传输，从而确保身份验证信息的安全性，防止客户端和TTLS服务器之间的主动和被动攻击。TTLS服务器解密此信息并通过AAA载波协议将其转发给AAA/H。
Any type of password or other authentication may be tunneled. Also, multiple tunneled authentications may be performed. Normally, tunneled authentication is used when the client has not been issued a certificate, and the TLS handshake provides only one-way authentication of the TTLS server to the client; however, in certain cases it may be desired to perform certificate authentication of the client during the TLS handshake as well as tunneled user authentication afterwards.
任何类型的密码或其他身份验证都可以通过隧道传输。此外，可以执行多个隧道认证。通常，当客户端尚未获得证书时，使用隧道式身份验证，TLS握手仅向客户端提供TTLS服务器的单向身份验证；然而，在某些情况下，可能需要在TLS握手期间执行客户端的证书认证以及之后的隧道用户认证。
Certain authentication protocols that use a challenge/response mechanism rely on challenge material that is not generated by the authentication server, and therefore the material requires special handling.
某些使用质询/响应机制的认证协议依赖于并非由认证服务器生成的质询资料，因此该资料需要特殊处理。
In CHAP, MS-CHAP, and MS-CHAP-V2, for example, the access point issues a challenge to the client, the client then hashes the challenge with the password and forwards the response to the access point. The access point then forwards both challenge and response to a AAA server. But because the AAA server did not itself generate the challenge, such protocols are susceptible to replay attack.
例如，在CHAP、MS-CHAP和MS-CHAP-V2中，接入点向客户端发出质询，然后客户端使用密码对质询进行散列，并将响应转发给接入点。然后，接入点将质询和响应转发给AAA服务器。但是，由于AAA服务器本身并不产生挑战，因此此类协议容易受到重播攻击。
If the client were able to create both challenge and response, anyone able to observe a CHAP or MS-CHAP exchange could pose as that user, even using EAP-TTLS.
如果客户端能够创建质询和响应，任何能够观察CHAP或MS-CHAP交换的人都可以冒充该用户，甚至可以使用EAP-TTLS。
To make these protocols secure under EAP-TTLS, it is necessary to provide a mechanism to produce a challenge that the client cannot control or predict. This is accomplished using the same technique described above for generating data connection keying material.
为了使这些协议在EAP-TTLS下安全，有必要提供一种机制来产生客户端无法控制或预测的挑战。这是使用上述生成数据连接键控材料的相同技术实现的。
When a challenge-based authentication mechanism is used, both client and TTLS server use the pseudo-random function to generate as many octets as are required for the challenge, using the constant string "ttls challenge", based on the master secret and random values established during the handshake:
当使用基于质询的身份验证机制时，客户端和TTLS服务器都使用伪随机函数，根据握手期间建立的主密钥和随机值，使用常量字符串“TTLS质询”，生成质询所需的尽可能多的八位字节：
EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret, "ttls challenge", SecurityParameters.client_random + SecurityParameters.server_random);
EAP-TTLS_challenge=PRF nn（SecurityParameters.master_secret，“TTLS challenge”，SecurityParameters.client_random+SecurityParameters.server_random）；
The number of octets to be generated (nn) depends on the authentication method, and is indicated below for each authentication method requiring implicit challenge generation.
要生成的八位字节数（nn）取决于身份验证方法，下面针对需要隐式质询生成的每个身份验证方法指出。
This section describes the methods for tunneling specific authentication protocols within EAP-TTLS.
本节介绍在EAP-TTLS中隧道特定身份验证协议的方法。
For the purpose of explication, it is assumed that the TTLS server and AAA/H use RADIUS as a AAA carrier protocol between them. However, this is not a requirement, and any AAA protocol capable of carrying the required information may be used.
为了便于解释，假设TTLS服务器和AAA/H使用RADIUS作为它们之间的AAA载波协议。然而，这不是一项要求，可以使用能够承载所需信息的任何AAA协议。
The client determines which authentication protocol will be used via the initial AVPs it sends to the server, as described in the following sections.
客户端通过发送到服务器的初始AVP确定将使用哪个身份验证协议，如以下部分所述。
Note that certain of the authentication protocols described below utilize vendor-specific AVPs originally defined for RADIUS. RADIUS and Diameter differ in the encoding of vendor-specific AVPs: RADIUS uses the vendor-specific attribute (code 26), while Diameter uses setting of the V bit to indicate the presence of Vendor-ID. The RADIUS form of the vendor-specific attribute is always convertible to a Diameter AVP with V bit set. All vendor-specific AVPs described below MUST be encoded using the preferred Diameter V bit mechanism; that is, the AVP Code of 26 MUST NOT be used to encode vendor-specific AVPs within EAP-TTLS.
请注意，下面描述的某些身份验证协议使用最初为RADIUS定义的特定于供应商的AVP。RADIUS和Diameter在供应商特定AVP的编码方面有所不同：RADIUS使用供应商特定属性（代码26），而Diameter使用V位的设置来指示供应商ID的存在。供应商特定属性的RADIUS形式始终可转换为设置了V位的Diameter AVP。以下描述的所有供应商特定AVP必须使用首选直径V位机制进行编码；也就是说，不得使用26的AVP代码对EAP-TTLS中的供应商特定AVP进行编码。
When EAP is the tunneled authentication protocol, each tunneled EAP packet between the client and TTLS server is encapsulated in an EAP-Message AVP, prior to tunneling via the TLS record layer.
当EAP是隧道式身份验证协议时，在通过TLS记录层隧道之前，客户端和TTLS服务器之间的每个隧道式EAP数据包被封装在EAP消息AVP中。
Note that because Diameter AVPs are not limited to 253 octets of data, as are RADIUS attributes, the RADIUS mechanism of concatenating multiple EAP-Message attributes to represent a longer-than-253-octet EAP packet is not appropriate in EAP-TTLS. Thus, a tunneled EAP packet within a single EAP-TTLS message MUST be contained in a single EAP-Message AVP.
注意，由于Diameter AVP不限于253个八位字节的数据，RADIUS属性也不限于此，因此将多个EAP消息属性串联以表示长度超过253个八位字节的EAP数据包的RADIUS机制在EAP-TTLS中是不合适的。因此，单个EAP-TTLS消息中的隧道EAP数据包必须包含在单个EAP消息AVP中。
The client initiates EAP by tunneling EAP-Response/Identity to the TTLS server. Depending on the requirements specified for the inner method, the client MAY now place the actual username in this packet; the privacy of the user's identity is now guaranteed by the TLS encryption. This username is typically a Network Access Identifier (NAI) [RFC4282]; that is, it is typically in the following format:
客户端通过将EAP响应/标识隧道传输到TTLS服务器来启动EAP。根据为内部方法指定的要求，客户机现在可以将实际用户名放入该数据包中；用户身份的隐私现在由TLS加密保证。该用户名通常是网络访问标识符（NAI）[RFC4282]；也就是说，它通常采用以下格式：
username@realm
username@realm
The @realm portion is optional, and is used to allow the TTLS server to forward the EAP packet to the appropriate AAA/H.
@realm部分是可选的，用于允许TTLS服务器将EAP数据包转发到适当的AAA/H。
Note that the client has two opportunities to specify realms. The first, in the initial, untunneled EAP-Response/Identity packet prior to starting EAP-TTLS, indicates the realm of the TTLS server. The second, occurring as part of the EAP exchange within the EAP-TTLS tunnel, indicates the realm of the client's home network. Thus, the access point need only know how to route to the realm of the TTLS server; the TTLS server is assumed to know how to route to the client's home realm. This serial routing architecture is anticipated to be useful in roaming environments, allowing access points or AAA proxies behind access points to be configured only with a small number of realms. (Refer to Section 7.3 for additional information distinguishing the untunneled and tunneled versions of the EAP-Response/Identity packets.)
注意，客户机有两个指定领域的机会。第一个是在启动EAP-TTLS之前的初始未启用EAP响应/标识数据包中，指示TTLS服务器的领域。第二个作为EAP-TTLS隧道内EAP交换的一部分出现，表示客户端家庭网络的领域。因此，接入点只需要知道如何路由到TTLS服务器的领域；假设TTLS服务器知道如何路由到客户端的主域。这种串行路由体系结构预计在漫游环境中很有用，允许接入点或接入点后面的AAA代理仅配置少量领域。（请参阅第7.3节，了解区分EAP响应/标识数据包的非隧道版本和隧道版本的更多信息。）
Note that TTLS processing of the initial identity exchange is different from plain EAP. The state machine of TTLS is different. However, it is expected that the server side is capable of dealing with client initiation, because even normal EAP protocol runs are client-initiated over AAA. On the client side, there are various implementation techniques to deal with the differences. Even a TTLS-unaware EAP protocol run could be used, if TTLS makes it appear as if an EAP-Request/Identity message was actually received. This is similar to what authenticators do when operating between a client and a AAA server.
注意，初始身份交换的TTLS处理不同于普通EAP。TTLS的状态机是不同的。然而，预计服务器端能够处理客户端启动，因为即使是正常的EAP协议运行也是通过AAA由客户端启动的。在客户端，有各种实现技术来处理这些差异。如果TTLS使其看起来好像实际收到了EAP请求/标识消息，则甚至可以使用TTLS unknowledge EAP协议运行。这类似于身份验证器在客户端和AAA服务器之间操作时所做的操作。
Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request.
收到隧道EAP响应/标识后，TTLS服务器将其转发给RADIUS访问请求中的AAA/H。
The AAA/H may immediately respond with an Access-Reject; in which case, the TTLS server completes the negotiation by sending an EAP-Failure to the access point. This could occur if the AAA/H does not recognize the user's identity, or if it does not support EAP.
AAA/H可立即响应访问拒绝；在这种情况下，TTLS服务器通过向接入点发送EAP故障来完成协商。如果AAA/H无法识别用户的身份，或者不支持EAP，则可能发生这种情况。
If the AAA/H does recognize the user's identity and does support EAP, it responds with an Access-Challenge containing an EAP-Request, with the Type and Type-Data fields set according to the EAP protocol with
如果AAA/H确实识别用户的身份并支持EAP，则它会以包含EAP请求的访问质询进行响应，并根据EAP协议设置类型和类型数据字段
which the AAA/H wishes to authenticate the client; for example MD5- Challenge, One-Time Password (OTP), or Generic Token Card.
AAA/H希望对客户进行认证；例如MD5-挑战、一次性密码（OTP）或通用令牌卡。
The EAP authentication between client and AAA/H proceeds normally, as described in [RFC3748], with the TTLS server acting as a passthrough device. Each EAP-Request sent by the AAA/H in an Access-Challenge is tunneled by the TTLS server to the client, and each EAP-Response tunneled by the client is decrypted and forwarded by the TTLS server to the AAA/H in an Access-Request.
客户端和AAA/H之间的EAP身份验证正常进行，如[RFC3748]中所述，TTLS服务器充当直通设备。由AAA/H在访问质询中发送的每个EAP请求由TTLS服务器隧道传输到客户端，由客户端隧道传输的每个EAP响应由TTLS服务器解密并在访问请求中转发到AAA/H。
This process continues until the AAA/H issues an Access-Accept or Access-Reject.
此过程将继续，直到AAA/H发出访问接受或访问拒绝。
Note that EAP-TTLS does not impose special rules on EAP Notification packets; such packets MAY be used within a tunneled EAP exchange according to the rules specified in [RFC3748].
请注意，EAP-TTLS不会对EAP通知数据包施加特殊规则；根据[RFC3748]中规定的规则，此类数据包可在隧道EAP交换中使用。
EAP-TTLS provides a reliable transport for the tunneled EAP exchange. However, [RFC3748] assumes an unreliable transport for EAP messages (see Section 3.1), and provides for silent discard of any EAP packet that violates the protocol or fails a method-specific integrity check, on the assumption that such a packet is likely a counterfeit sent by an attacker. But since the tunnel provides a reliable transport for the inner EAP authentication, errors that would result in silent discard according to [RFC3748] presumably represent implementation errors when they occur within the tunnel, and SHOULD be treated as such in preference to being silently discarded. Indeed, silently discarding an EAP message within the tunnel effectively puts a halt to the progress of the exchange, and will result in long timeouts in cases that ought to result in immediate failures.
EAP-TTLS为隧道EAP交换提供了可靠的传输。但是，[RFC3748]假设EAP消息的传输不可靠（见第3.1节），并假设任何违反协议或未通过特定方法完整性检查的EAP数据包可能是攻击者发送的伪造数据包，则允许对其进行无声丢弃。但是，由于隧道为内部EAP身份验证提供了可靠的传输，因此根据[RFC3748]可能会导致静默丢弃的错误表示在隧道内发生的实现错误，因此应优先将其视为静默丢弃。事实上，在隧道中悄悄地丢弃EAP消息实际上会使交换进程停止，并且在本应导致立即失败的情况下会导致长时间超时。
The CHAP algorithm is described in [RFC1661]; RADIUS attribute formats are described in [RFC2865].
[RFC1661]中描述了CHAP算法；[RFC2865]中描述了半径属性格式。
Both client and TTLS server generate 17 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
客户端和TTLS服务器都使用上述常量字符串“TTLS CHARGE”生成17个八位字节的质询材料。这些八位字节的用法如下：
CHAP-Challenge [16 octets] CHAP Identifier [1 octet]
CHAP质询[16个八位字节]CHAP标识符[1个八位字节]
The client initiates CHAP by tunneling User-Name, CHAP-Challenge, and CHAP-Password AVPs to the TTLS server. The CHAP-Challenge value is taken from the challenge material. The CHAP-Password consists of
客户端通过将用户名、CHAP质询和CHAP密码AVP隧道传输到TTLS服务器来启动CHAP。CHAP质询值取自质询材料。CHAP密码由以下部分组成：
CHAP Identifier, taken from the challenge material; and CHAP response, computed according to the CHAP algorithm.
CHAP标识符，取自质询材料；和CHAP响应，根据CHAP算法计算。
Upon receipt of these AVPs from the client, the TTLS server must verify that the value of the CHAP-Challenge AVP and the value of the CHAP Identifier in the CHAP-Password AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server must reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
从客户端收到这些AVP后，TTLS服务器必须验证CHAP质询AVP的值和CHAP密码AVP中CHAP标识符的值是否等于作为质询材料生成的值。如果任一项不完全匹配，TTLS服务器必须拒绝客户端。否则，它会在访问请求中将AVP转发给AAA/H。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA/H将以访问接受或访问拒绝响应。
The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute formats are described in [RFC2548].
MS-CHAP算法如[RFC2433]所述；[RFC2548]中描述了半径属性格式。
Both client and TTLS server generate 9 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
客户端和TTLS服务器都使用上述常量字符串“TTLS CHARGE”生成9个八位字节的质询材料。这些八位字节的用法如下：
MS-CHAP-Challenge [8 octets] Ident [1 octet]
MS CHAP挑战[8个八位字节]标识[1个八位字节]
The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from the challenge material. The MS-CHAP-Response consists of Ident, taken from the challenge material; Flags, set according the client preferences; and LM-Response and NT-Response, computed according to the MS-CHAP algorithm.
客户端通过将用户名、MS CHAP质询和MS CHAP响应AVP隧道传输到TTLS服务器来启动MS-CHAP。MS CHAP质询值取自质询材料。MS CHAP响应包括来自质询材料的识别；标志，根据客户端首选项设置；以及根据MS-CHAP算法计算的LM响应和NT响应。
Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP-Response AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
从客户端收到这些AVP后，TTLS服务器必须验证MS CHAP质询AVP的值和客户端MS CHAP响应AVP中的标识值是否等于作为质询材料生成的值。如果任一项不完全匹配，TTLS服务器必须拒绝客户端。否则，它会在访问请求中将AVP转发给AAA/H。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA/H将以访问接受或访问拒绝响应。
The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute formats are described in [RFC2548].
[RFC2759]中描述了MS-CHAP-V2算法；[RFC2548]中描述了半径属性格式。
Both client and TTLS server generate 17 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
客户端和TTLS服务器都使用上述常量字符串“TTLS CHARGE”生成17个八位字节的质询材料。这些八位字节的用法如下：
MS-CHAP-Challenge [16 octets] Ident [1 octet]
MS CHAP挑战[16个八位字节]标识[1个八位字节]
The client initiates MS-CHAP-V2 by tunneling User-Name, MS-CHAP-Challenge, and MS-CHAP2-Response AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from the challenge material. The MS-CHAP2-Response consists of Ident, taken from the challenge material; Flags, set to 0; Peer-Challenge, set to a random value; and Response, computed according to the MS-CHAP-V2 algorithm.
客户端通过将用户名、MS CHAP质询和MS-CHAP2-Response AVP隧道传输到TTLS服务器来启动MS-CHAP-V2。MS CHAP质询值取自质询材料。MS-CHAP2-Response由来自质询材料的Ident组成；标志，设置为0；同伴挑战，设置为随机值；和响应，根据MS-CHAP-V2算法计算。
Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP2-Response AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
从客户端收到这些AVP后，TTLS服务器必须验证MS CHAP质询AVP的值和客户端MS-CHAP2-Response AVP中的标识值是否等于质询材料生成的值。如果任一项不完全匹配，TTLS服务器必须拒绝客户端。否则，它会在访问请求中将AVP转发给AAA/H。
If the authentication is successful, the AAA/H will respond with an Access-Accept containing the MS-CHAP2-Success attribute. This attribute contains a 42-octet string that authenticates the AAA/H to the client based on the Peer-Challenge. The TTLS server tunnels this AVP to the client. Note that the authentication is not yet complete; the client must still accept the authentication response of the AAA/H.
如果身份验证成功，AAA/H将使用包含MS-CHAP2-Success属性的访问接受进行响应。此属性包含一个42个八位字节的字符串，该字符串根据对等质询向客户端验证AAA/H。TTLS服务器通过隧道将此AVP传输到客户端。请注意，身份验证尚未完成；客户端仍必须接受AAA/H的身份验证响应。
Upon receipt of the MS-CHAP2-Success AVP, the client is able to authenticate the AAA/H. If the authentication succeeds, the client sends an EAP-TTLS packet to the TTLS server containing no data (that is, with a zero-length Data field). Upon receipt of the empty EAP-TTLS packet from the client, the TTLS server considers the MS-CHAP-V2 authentication to have succeeded.
收到MS-CHAP2-Success AVP后，客户端能够对AAA/H进行身份验证。如果身份验证成功，客户端将向TTLS服务器发送一个EAP-TTLS数据包，该数据包不包含任何数据（即，数据字段长度为零）。从客户端收到空EAP-TTLS数据包后，TTLS服务器认为MS-CHAP-V2身份验证已成功。
If the authentication fails, the AAA/H will respond with an Access-Challenge containing the MS-CHAP-Error attribute. This attribute contains a new Ident and a string with additional information such as the error reason and whether a retry is allowed. The TTLS server tunnels this AVP to the client. If the error reason is an expired password and a retry is allowed, the client may proceed to change the user's password. If the error reason is not an expired password or if the client does not wish to change the user's password, it simply abandons the EAP-TTLS negotiation.
如果身份验证失败，AAA/H将响应包含MS CHAP错误属性的访问质询。此属性包含一个新标识和一个字符串，其中包含其他信息，例如错误原因以及是否允许重试。TTLS服务器通过隧道将此AVP传输到客户端。如果错误原因是密码过期且允许重试，则客户端可以继续更改用户密码。如果错误原因不是过期的密码，或者客户端不希望更改用户的密码，那么它将放弃EAP-TTLS协商。
If the client does wish to change the password, it tunnels MS-CHAP-NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS server. The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge received in the MS-CHAP-Error AVP. The MS-CHAP-Challenge AVP simply echoes the new Challenge.
如果客户端确实希望更改密码，它会将MS CHAP NT Enc PW、MS-CHAP2-CPW和MS CHAP CHAP CHALLE AVP隧道传输到TTLS服务器。MS-CHAP2-CPW AVP源自MS CHAP错误AVP中接收到的新标识和质询。MS CHAP Challenge AVP只是对新挑战的回应。
Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP2-CPW AVP match the values it sent in the MS-CHAP-Error AVP. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
从客户端收到这些AVP后，TTLS服务器必须验证MS CHAP质询AVP的值和客户端MS-CHAP2-CPW AVP中的标识值是否与它在MS CHAP错误AVP中发送的值匹配。如果任一项不完全匹配，TTLS服务器必须拒绝客户端。否则，它会在访问请求中将AVP转发给AAA/H。
If the authentication is successful, the AAA/H will respond with an Access-Accept containing the MS-CHAP2-Success attribute. At this point, the negotiation proceeds as described above; the TTLS server tunnels the MS-CHAP2-Success to the client, and the client authenticates the AAA/H based on this AVP. Then, the client either abandons the negotiation on failure or sends an EAP-TTLS packet to the TTLS server containing no data (that is, with a zero-length Data field), causing the TTLS server to consider the MS-CHAP-V2 authentication to have succeeded.
如果身份验证成功，AAA/H将使用包含MS-CHAP2-Success属性的访问接受进行响应。此时，谈判按上述方式进行；TTLS服务器将MS-CHAP2-Success隧道传输到客户端，客户端基于此AVP对AAA/H进行身份验证。然后，客户端要么放弃关于失败的协商，要么将EAP-TTLS分组发送到不含数据的TTLS服务器（即，具有零长度数据字段），使得TTLS服务器考虑MS-CHAP-V2认证成功。
Note that additional AVPs associated with MS-CHAP-V2 may be sent by the AAA/H; for example, MS-CHAP-Domain. The TTLS server MUST tunnel such authentication-related attributes along with the MS-CHAP2- Success.
注意，与MS-CHAP-V2相关联的附加avp可由AAA/H发送；例如，MS CHAP域。TTLS服务器必须与MS-CHAP2-Success一起通过隧道传输此类与身份验证相关的属性。
The client initiates PAP by tunneling User-Name and User-Password AVPs to the TTLS server.
客户端通过将用户名和用户密码AVP隧道传输到TTLS服务器来启动PAP。
Normally, in RADIUS, User-Password is padded with nulls to a multiple of 16 octets, then encrypted using a shared secret and other packet information.
通常情况下，在RADIUS中，用户密码用空值填充到16个八位字节的倍数，然后使用共享密钥和其他数据包信息进行加密。
An EAP-TTLS client, however, does not RADIUS-encrypt the password since no such RADIUS variables are available; this is not a security weakness since the password will be encrypted via TLS anyway. The client SHOULD, however, null-pad the password to a multiple of 16 octets, to obfuscate its length.
然而，EAP-TTLS客户端不加密RADIUS密码，因为没有可用的RADIUS变量；这不是一个安全弱点，因为密码无论如何都将通过TLS加密。但是，客户端应该将密码填充为16个八位字节的倍数，以混淆其长度。
Upon receipt of these AVPs from the client, the TTLS server forwards them to the AAA/H in a RADIUS Access-Request. (Note that in the Access-Request, the TTLS server must encrypt the User-Password attribute using the shared secret between the TTLS server and AAA/H.)
从客户机接收到这些AVP后，TTLS服务器以RADIUS访问请求的形式将其转发给AAA/H。（注意，在访问请求中，TTLS服务器必须使用TTLS服务器和AAA/H之间的共享密钥加密用户密码属性。）
The AAA/H may immediately respond with an Access-Accept or Access-Reject. The TTLS server then completes the negotiation by sending an EAP-Success or EAP-Failure to the access point using the AAA carrier protocol.
AAA/H可立即响应访问接受或访问拒绝。然后，TTLS服务器通过使用AAA载波协议向接入点发送EAP成功或EAP失败来完成协商。
The AAA/H may also respond with an Access-Challenge. The TTLS server then tunnels the AVPs from the AAA/H's challenge to the client. Upon receipt of these AVPs, the client tunnels User-Name and User-Password again, with User-Password containing new information in response to the challenge. This process continues until the AAA/H issues an Access-Accept or Access-Reject.
AAA/H还可响应接入质询。然后，TTLS服务器通过隧道将AVP从AAA/H的挑战传送到客户端。在收到这些AVP后，客户机再次传输用户名和用户密码，用户密码包含响应质询的新信息。此过程将继续，直到AAA/H发出访问接受或访问拒绝。
At least one of the AVPs tunneled to the client upon challenge MUST be Reply-Message. Normally, this is sent by the AAA/H as part of the challenge. However, if the AAA/H has not sent a Reply-Message, the TTLS server MUST issue one, with null value. This allows the client to determine that a challenge response is required.
在质询时，至少有一个通过隧道传输到客户端的AVP必须是应答消息。通常，这是AAA/H作为质询的一部分发送的。但是，如果AAA/H尚未发送回复消息，则TTLS服务器必须发出一条带有空值的回复消息。这允许客户端确定需要质询响应。
Note that if the AAA/H includes a Reply-Message as part of an Access-Accept or Access-Reject, the TTLS server does not tunnel this AVP to the client. Rather, this AVP and all other AVPs sent by the AAA/H as part of Access-Accept or Access-Reject are sent to the access point via the AAA carrier protocol.
请注意，如果AAA/H将应答消息作为访问接受或访问拒绝的一部分，则TTLS服务器不会将此AVP隧道传输到客户端。相反，该AVP和AAA/H作为接入接受或接入拒绝的一部分发送的所有其他AVP经由AAA载波协议发送到接入点。
In some cases, it is desirable to perform multiple user authentications. For example, a AAA/H may want first to authenticate the user by password, then by token card.
在某些情况下，希望执行多个用户身份验证。例如，AAA/H可能希望首先通过密码对用户进行身份验证，然后通过令牌卡进行身份验证。
The AAA/H may perform any number of additional user authentications using EAP, simply by issuing a EAP-Request with a new EAP type once the previous authentication completes. Note that each new EAP method is subject to negotiation; that is, the client may respond to the EAP request for a new EAP type with an EAP-Nak, as described in [RFC3748].
AAA/H可以使用EAP执行任意数量的附加用户认证，只要在先前的认证完成后发出具有新EAP类型的EAP请求即可。注意，每种新的EAP方法都需要协商；也就是说，如[RFC3748]中所述，客户端可以使用EAP Nak响应新EAP类型的EAP请求。
For example, a AAA/H wishing to perform an MD5-Challenge followed by Generic Token Card would first issue an EAP-Request/MD5-Challenge and receive a response. If the response is satisfactory, it would then issue an EAP-Request/Generic Token Card and receive a response. If that response were also satisfactory, it would accept the user.
例如，AAA/H希望在通用令牌卡之后执行MD5质询，将首先发出EAP请求/MD5质询并接收响应。如果响应令人满意，它将发出EAP请求/通用令牌卡并接收响应。如果该响应也令人满意，它将接受用户。
The entire inner EAP exchange comprising multiple authentications is considered a single EAP sequence, in that each subsequent request MUST contain distinct a EAP Identifier from the previous request, even as one authentication completes and another begins.
包含多个身份验证的整个内部EAP交换被视为单个EAP序列，因为每个后续请求必须包含不同于前一个请求的EAP标识符，即使一个身份验证完成，另一个身份验证开始。
The peer identity indicated in the original EAP-Response/Identity that initiated the EAP sequence is intended to apply to each of the sequential authentications. In the absence of an application profile standard specifying otherwise, additional EAP-Identity exchanges SHOULD NOT occur.
启动EAP序列的原始EAP响应/标识中指示的对等身份旨在应用于每个顺序认证。在没有应用程序配置文件标准另有规定的情况下，不应进行额外的EAP身份交换。
The conditions for overall success or failure when multiple authentications are used are a matter of policy on client and server; thus, either party may require that all inner authentications succeed, or that at least one inner authentication succeed, as a condition for success of the overall authentication.
当使用多个身份验证时，总体成功或失败的条件是客户端和服务器上的策略问题；因此，任何一方都可以要求所有内部认证成功，或者至少一个内部认证成功，作为整体认证成功的条件。
Each EAP method is intended to run to completion. Should the TTLS server abandon a method and start a new one, client behavior is not defined in this document and is a matter of client policy.
每个EAP方法都要运行到完成。如果TTLS服务器放弃一个方法并启动一个新的方法，则本文档中不定义客户机行为，而是客户机策略的问题。
Note that it is not always feasible to use the same EAP method twice in a row, since it may not be possible to determine when the first authentication completes and the new authentication begins if the EAP type does not change. Certain EAP methods, such as EAP-TLS, use a Start bit to distinguish the first request, thus allowing each new authentication using that type to be distinguished from the previous. Other methods, such as EAP-MS-CHAP-V2, terminate in a well-defined manner, allowing a second authentication of the same type to commence unambiguously. While use of the same EAP method for multiple authentications is relatively unlikely, implementers should be aware of the issues and avoid cases that would result in ambiguity.
请注意，在一行中使用同一EAP方法两次并不总是可行的，因为如果EAP类型没有更改，则可能无法确定第一次身份验证何时完成以及新身份验证何时开始。某些EAP方法（如EAP-TLS）使用起始位来区分第一个请求，从而允许将使用该类型的每个新身份验证与以前的身份验证区分开来。其他方法，如EAP-MS-CHAP-V2，以明确定义的方式终止，允许相同类型的第二次身份验证明确开始。虽然将同一EAP方法用于多次身份验证的可能性相对较小，但实施者应注意这些问题，并避免出现可能导致歧义的情况。
Multiple authentications using non-EAP methods or a mixture of EAP and non-EAP methods is not defined in this document, nor is it known whether such an approach has been implemented.
本文档中未定义使用非EAP方法或EAP和非EAP方法混合使用的多重身份验证，也不知道是否已实施此类方法。
To ensure interoperability, in the absence of an application profile standard specifying otherwise, an implementation compliant with this specification MUST implement EAP as a tunneled authentication method and MUST implement MD5-Challenge as an EAP type. However, such an implementation MAY allow the use of EAP, any EAP type, or any other tunneled authentication method to be enabled or disabled by administrative action on either client or TTLS server.
为了确保互操作性，在没有应用程序配置文件标准另有规定的情况下，符合本规范的实现必须将EAP实现为隧道式身份验证方法，并且必须将MD5质询实现为EAP类型。然而，这样的实现可以允许通过客户端或TTLS服务器上的管理操作启用或禁用EAP、任何EAP类型或任何其他隧道认证方法的使用。
In addition, in the absence of an application profile standard specifying otherwise, an implementation compliant with this specification MUST allow an administrator to configure the use of tunneled authentication without the M (Mandatory) bit set on any AVP.
此外，在没有应用程序配置文件标准另有规定的情况下，符合本规范的实现必须允许管理员配置隧道身份验证的使用，而无需在任何AVP上设置M（强制）位。
The following information is provided as non-normative guidance based on the experience of the authors and reviewers of this specification with existing implementations of EAP-TTLSv0.
以下信息作为非规范性指南提供，其依据是本规范作者和审查人员对EAP-TTLSv0现有实施的经验。
The following authentication methods are commonly used, and servers wishing for broad interoperability across multiple media should consider implementing them:
通常使用以下验证方法，希望在多个媒体之间进行广泛互操作的服务器应该考虑实现它们：
- PAP (both for password and token authentication)
- PAP（用于密码和令牌身份验证）
- MS-CHAP-V2
- MS-CHAP-V2
- EAP-MS-CHAP-V2
- EAP-MS-CHAP-V2
- EAP-GTC
- EAP-GTC
In compliance with [RFC5247], Session-Id, Peer-Id, and Server-Id are here defined.
根据[RFC5247]，这里定义了会话Id、对等Id和服务器Id。
The Session-Id uniquely identifies an authentication exchange between the client and TTLS server. It is defined as follows:
会话Id唯一标识客户端和TTLS服务器之间的身份验证交换。其定义如下：
Session-Id = 0x15 || client.random || server.random
会话Id=0x15 | | client.random | | server.random
The Peer-Id represents the identity to be used for access control and accounting purposes. When the client presents a certificate as part of the TLS handshake, the Peer-Id is determined based on information in the certificate, as specified in Section 5.2 of [RFC5216]. Otherwise, the Peer-Id is null.
对等Id表示用于访问控制和记帐目的的标识。当客户端作为TLS握手的一部分提供证书时，根据[RFC5216]第5.2节中的规定，根据证书中的信息确定对等Id。否则，对等Id为空。
The Server-Id identifies the TTLS server. When the TTLS server presents a certificate as part of the TLS handshake, the Server-Id is determined based on information in the certificate, as specified in Section 5.2 of [RFC5216]. Otherwise, the Server-Id is null.
服务器Id标识TTLS服务器。当TTLS服务器作为TLS握手的一部分提供证书时，根据[RFC5216]第5.2节中的规定，根据证书中的信息确定服务器Id。否则，服务器Id为空。
The following table lists each AVP defined in this document, whether the AVP may appear in a packet from server to client ("Request") and/or in a packet from client to server ("Response"), and whether the AVP MUST be implemented ("MI").
下表列出了本文件中定义的每个AVP，AVP是否可能出现在从服务器到客户端的数据包（“请求”）和/或从客户端到服务器的数据包（“响应”）中，以及是否必须实现AVP（“MI”）。
Name Request Response MI
---------------------------------------------------
User-Name X
User-Password X
CHAP-Password X
Reply-Message X
CHAP-Challenge X
EAP-Message X X X
MS-CHAP-Response X
MS-CHAP-Error X
MS-CHAP-NT-Enc-PW X
MS-CHAP-Domain X
MS-CHAP-Challenge X
MS-CHAP2-Response X
MS-CHAP2-Success X
MS-CHAP2-CPW X
Name Request Response MI
---------------------------------------------------
User-Name X
User-Password X
CHAP-Password X
Reply-Message X
CHAP-Challenge X
EAP-Message X X X
MS-CHAP-Response X
MS-CHAP-Error X
MS-CHAP-NT-Enc-PW X
MS-CHAP-Domain X
MS-CHAP-Challenge X
MS-CHAP2-Response X
MS-CHAP2-Success X
MS-CHAP2-CPW X
Pursuant to RFC 3748, security claims for EAP-TTLSv0 are as follows:
根据RFC 3748，EAP-TTLSv0的担保索赔如下：
Authentication mechanism: TLS plus arbitrary additional protected authentication(s) Ciphersuite negotiation: Yes Mutual authentication: Yes, in recommended implementation Integrity protection: Yes Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: Up to 384 bits Dictionary attack prot.: Yes Fast reconnect: Yes Cryptographic binding: No Session independence: Yes Fragmentation: Yes Channel binding: No
身份验证机制：TLS加任意附加受保护身份验证密码套件协商：是相互身份验证：是，在推荐的实现中完整性保护：是重播保护：是机密性：是密钥派生：是密钥强度：高达384位字典攻击保护：是快速重新连接：是加密绑定：无会话独立性：是碎片：是通道绑定：否
EAP-TTLSv0 utilizes negotiated underlying authentication protocols, both in the phase 1 TLS handshake and the phase 2 tunneled authentication. In a typical deployment, at a minimum the TTLS server authenticates to the client in phase 1, and the client authenticates to the AAA/H server in phase 2. Phase 1 authentication of the TTLS server to the client is typically by certificate; the client may optionally authenticate to the TTLS server by certificate
EAP-TTLSv0在第1阶段TLS握手和第2阶段隧道式身份验证中利用协商的底层身份验证协议。在典型部署中，TTLS服务器至少在第1阶段向客户机进行身份验证，客户机在第2阶段向AAA/H服务器进行身份验证。TTLS服务器到客户端的第1阶段身份验证通常是通过证书进行的；客户端可以选择通过证书向TTLS服务器进行身份验证
as well. Phase 2 authentication of the client to the AAA/H server is typically by password or security token via an EAP or supported non-EAP authentication mechanism; this authentication mechanism may provide authentication of the AAA/H server to the client as well (mutual authentication).
也客户端到AAA/H服务器的第2阶段身份验证通常通过密码或安全令牌通过EAP或支持的非EAP身份验证机制进行；该认证机制还可以向客户端提供AAA/H服务器的认证（相互认证）。
Ciphersuite negotiation is inherited from TLS.
Ciphersuite协商继承自TLS。
In the recommended minimum configuration, the TTLS server is authenticated to the client in phase 1, and the client and AAA/H server mutually authenticate in phase 2.
在推荐的最低配置中，TTLS服务器在第1阶段向客户机进行身份验证，而客户机和AAA/H服务器在第2阶段相互进行身份验证。
Integrity protection is inherited from TLS.
完整性保护继承自TLS。
Replay protection is inherited from TLS.
重播保护是从TLS继承的。
Confidentiality is inherited from TLS. Note, however, that EAP-TTLSv0 contains no provision for encryption of success or failure EAP packets.
机密性是从TLS继承的。然而，请注意，EAP-TTLSv0不包含成功或失败EAP数据包的加密规定。
Both MSK and EMSK are derived. The key derivation PRF is inherited from TLS, and cryptographic agility of this mechanism depends on the cryptographic agility of the TLS PRF.
推导了MSK和EMSK。密钥派生PRF继承自TLS，该机制的加密灵活性取决于TLS PRF的加密灵活性。
Key strength is limited by the size of the TLS master secret, which for versions 1.0 and 1.1 is 48 octets (384 bits). Effective key strength may be less, depending on the attack resistance of the negotiated Diffie-Helman (DH) group, certificate RSA/DSA group, etc. BCP 86 [RFC3766], Section 5, offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
密钥强度受TLS主密钥大小的限制，1.0和1.1版的主密钥大小为48个八位字节（384位）。根据协商的Diffie-Helman（DH）组、证书RSA/DSA组等的抗攻击性，有效密钥强度可能会更小。BCP 86[RFC3766]第5节针对给定的抗攻击性级别，提供了关于所需RSA或DH模块和DSA子组大小（以位为单位）的建议。例如，建议使用2048位RSA密钥来提供128位等效密钥强度。国家标准与技术研究所（NIST）也在[SP800-57]中提供了关于适当键尺寸的建议。
Phase 2 password authentication is protected against eavesdropping and therefore against offline dictionary attack by TLS encryption.
第2阶段密码身份验证可防止窃听，因此可通过TLS加密防止脱机字典攻击。
Fast reconnect is provided by TLS session resumption.
TLS会话恢复提供快速重新连接。
[MITM] describes a vulnerability that is characteristic of tunneled authentication protocols, in which an attacker authenticates as a client via a tunneled protocol by posing as an authenticator to a legitimate client using a non-tunneled protocol. When the same proof of credentials can be used in both authentications, the attacker merely shuttles the credential proof between them. EAP-TTLSv0 is vulnerable to such an attack. Care should be taken to avoid using authentication protocols and associated credentials both as inner TTLSv0 methods and as untunneled methods.
[MITM]描述了隧道式身份验证协议特有的漏洞，其中攻击者通过隧道式协议向使用非隧道式协议的合法客户端冒充身份验证者进行客户端身份验证。当两种身份验证都可以使用相同的凭证证明时，攻击者只需在它们之间传递凭证证明。EAP-TTLSv0易受此类攻击。应注意避免将身份验证协议和相关凭证同时用作内部TTLSv0方法和未启用的方法。
Extensions to EAP-TTLSv0 or a future version of EAP-TTLS should be defined to perform a cryptographic binding of keying material generated by inner authentication methods and the keying material generated by the TLS handshake. This avoids the man-in-the-middle problem when used with key-generating inner methods. Such an extension mechanism has been proposed [TTLS-EXT].
应定义EAP-TTLSv0的扩展或EAP-TTLS的未来版本，以执行内部身份验证方法生成的密钥材料和TLS握手生成的密钥材料的加密绑定。这避免了在使用密钥生成内部方法时出现中间人问题。已经提出了这种扩展机制[TTLS-EXT]。
TLS guarantees the session independence of its master secret, from which the EAP-TTLSv0 MSK/EMSK is derived.
TLS保证其主密钥的会话独立性，EAP-TTLSv0 MSK/EMSK由此派生。
Provision is made for fragmentation of lengthy EAP packets.
规定了长EAP数据包的碎片。
Support for channel binding may be added as a future extension, using appropriate AVPs.
可以使用适当的AVP作为将来的扩展添加对通道绑定的支持。
Unlike other EAP methods, EAP-TTLS does not communicate a username in the clear in the initial EAP-Response/Identity. This feature is designed to support anonymity and location privacy from attackers eavesdropping the network path between the client and the TTLS
与其他EAP方法不同，EAP-TTLS在初始EAP响应/标识中不以明文形式传递用户名。此功能旨在支持匿名性和位置隐私，防止攻击者窃听客户端和TTL之间的网络路径
server. However, implementers should be aware that other factors -- both within EAP-TTLS and elsewhere -- may compromise a user's identity. For example, if a user authenticates with a certificate during phase 1 of EAP-TTLS, the subject name in the certificate may reveal the user's identity. Outside of EAP-TTLS, the client's fixed MAC address, or in the case of wireless connections, the client's radio signature, may also reveal information. Additionally, implementers should be aware that a user's identity is not hidden from the EAP-TTLS server and may be included in the clear in AAA messages between the access point, the EAP-TTLS server, and the AAA/H server.
服务器然而，实现者应该意识到，EAP-TTLS内部和其他地方的其他因素可能会损害用户的身份。例如，如果用户在EAP-TTLS的阶段1期间使用证书进行身份验证，则证书中的使用者名称可能会显示用户的身份。在EAP-TTLS之外，客户机的固定MAC地址，或者在无线连接的情况下，客户机的无线电签名也可能泄露信息。此外，实施者应意识到，用户的身份不会对EAP-TTLS服务器隐藏，并且可能包含在接入点、EAP-TTLS服务器和AAA/H服务器之间的清除AAA消息中。
Note that if a client authenticating with a certificate wishes to shield its certificate, and hence its identity, from eavesdroppers, it may use the technique described in Section 2.1.4 ("Privacy") of [RFC5216], in which the client sends an empty certificate list, the TTLS server issues a ServerHello upon completion of the TLS handshake to begin a second, encrypted handshake, during which the client will send its certificate list. Note that for this feature to work the client must know in advance that the TTLS server supports it.
请注意，如果使用证书进行身份验证的客户端希望屏蔽其证书，从而保护其身份不被窃听者窃取，则可以使用[RFC5216]第2.1.4节（“隐私”）中描述的技术，其中客户端发送一个空证书列表，TTLS服务器在完成TLS握手后发出ServerHello，以开始第二次加密握手，在此期间客户端将发送其证书列表。请注意，要使此功能正常工作，客户端必须事先知道TTLS服务器支持它。
Trust of the server by the client is established via a server certificate conveyed during the TLS handshake. The client should have a means of determining which server identities are authorized to act as a TTLS server and may be trusted, and should refuse to authenticate with servers it does not trust. The consequence of pursuing authentication with a hostile server is exposure of the inner authentication to attack; e.g., offline dictionary attack against the client password.
客户机对服务器的信任通过TLS握手期间传递的服务器证书建立。客户端应该有一种方法来确定哪些服务器身份被授权作为TTLS服务器，并且可以被信任，并且应该拒绝向它不信任的服务器进行身份验证。使用恶意服务器进行身份验证的结果是内部身份验证暴露在攻击之下；e、 例如，针对客户端密码的脱机字典攻击。
When either client or server presents a certificate as part of the TLS handshake, it should include the entire certificate chain minus the root to facilitate certificate validation by the other party.
当客户机或服务器将证书作为TLS握手的一部分提供时，它应该包括整个证书链减去根，以便于另一方验证证书。
When either client or server receives a certificate as part of the TLS handshake, it should validate the certification path to a trusted root. If intermediate certificates are not provided by the sender, the receiver may use cached or pre-configured copies if available, or may retrieve them from the Internet if feasible.
当客户机或服务器接收到证书作为TLS握手的一部分时，它应该验证到受信任根的证书路径。如果发送方未提供中间证书，接收方可以使用缓存或预配置的副本（如果可用），或者如果可行，可以从Internet检索它们。
Clients and servers should implement policies related to the Extended Key Usage (EKU) extension [RFC5280] of certificates it receives, to ensure that the other party's certificate usage conforms to the certificate's purpose. Typically, a client EKU, when present, would
客户端和服务器应实施与其接收的证书的扩展密钥使用（EKU）扩展[RFC5280]相关的策略，以确保另一方的证书使用符合证书的用途。通常，客户EKU（如果存在）会
be expected to include id-kp-clientAuth; a server EKU, when present, would be expected to include id-kp-serverAuth. Note that absence of the EKU extension or a value of anyExtendedKeyUsage implies absence of constraint on the certificate's purpose.
应包括id kp clientAuth；服务器EKU（如果存在）应包含id kp serverAuth。请注意，缺少EKU扩展或anyExtendedKeyUsage值意味着对证书用途没有约束。
Certificates should be checked for revocation to reduce exposure to imposture using compromised certificates.
应检查证书是否被撤销，以减少使用受损证书的冒用风险。
Checking a server certificate against the most recent revocation list during authentication is not always possible for a client, as it may not have network access until completion of the authentication. This problem can be alleviated through the use of the Online Certificate Status Protocol (OCSP) [RFC2560] during the TLS handshake, as described in [RFC4366].
对于客户端来说，在身份验证期间根据最近的吊销列表检查服务器证书并不总是可行的，因为在完成身份验证之前，它可能无法访问网络。如[RFC4366]所述，通过在TLS握手期间使用在线证书状态协议（OCSP）[RFC2560]，可以缓解此问题。
With forward secrecy, revelation of a secret does not compromise session keys previously negotiated based on that secret. Thus, when the TLS key exchange algorithm provides forward secrecy, if a TTLS server certificate's private key is eventually stolen or cracked, tunneled user password information will remain secure as long as that certificate is no longer in use. Diffie-Hellman key exchange is an example of an algorithm that provides forward secrecy. A forward secrecy algorithm should be considered if attacks against recorded authentication or data sessions are considered to pose a significant threat.
对于前向保密，泄露秘密不会影响先前基于该秘密协商的会话密钥。因此，当TLS密钥交换算法提供前向保密性时，如果TTLS服务器证书的私钥最终被窃取或破解，则隧道用户密码信息将保持安全，只要该证书不再使用。Diffie-Hellman密钥交换是提供前向保密性的算法的一个例子。如果对记录的身份验证或数据会话的攻击被视为构成重大威胁，则应考虑使用前向保密算法。
EAP-TTLS negotiates its own protocol version prior to, and therefore outside the security established by the TLS tunnel. In principle, therefore, it is subject to a negotiating-down attack, in which an intermediary modifies messages in transit to cause a lower version of the protocol to be agreed upon, each party assuming that the other does not support as high a version as it actually does.
EAP-TTLS在TLS隧道建立的安全性之前协商自己的协议版本，因此在TLS隧道建立的安全性之外。因此，原则上，它会受到协商拒绝攻击，在这种攻击中，中间人修改传输中的消息以使协议的较低版本达成一致，每一方都假设另一方不支持其实际支持的较高版本。
The version of the EAP-TTLS protocol described in this document is 0, and is therefore not subject to such an attack. However, any new version of the protocol using a higher number than 0 should define a mechanism to ensure against such an attack. One such mechanism might be the TTLS server's reiteration of the protocol version that it proposed in an AVP within the tunnel, such AVP to be inserted with M bit clear even when version 0 is agreed upon.
本文档中描述的EAP-TTLS协议版本为0，因此不会受到此类攻击。但是，使用大于0的任何新版本的协议都应定义一种机制，以确保防止此类攻击。其中一种机制可能是TTLS服务器重复其在隧道内的AVP中提出的协议版本，即使在版本0达成一致意见时，该AVP也要插入M位清除。
This section presents EAP-TTLS message sequences for various negotiation scenarios. These examples do not attempt to exhaustively depict all possible scenarios.
本节介绍各种协商场景的EAP-TTLS消息序列。这些示例并不试图详尽地描述所有可能的场景。
It is assumed that RADIUS is the AAA carrier protocol both between access point and TTLS server, and between TTLS server and AAA/H.
假设RADIUS是接入点和TTLS服务器之间以及TTLS服务器和AAA/H之间的AAA载波协议。
EAP packets that are passed unmodified between client and TTLS server by the access point are indicated as "passthrough". AVPs that are securely tunneled within the TLS record layer are enclosed in curly braces ({}). Items that are optional are suffixed with question mark (?). Items that may appear multiple times are suffixed with plus sign (+).
接入点在客户端和TTLS服务器之间未经修改地传递的EAP数据包被指示为“passthrough”。在TLS记录层中安全隧道的AVP用花括号（{}）括起来。可选项的后缀为问号（？）。可能出现多次的项目以加号（+）作为后缀。
In this example, the client performs one-way TLS authentication of the TTLS server. CHAP is used as a tunneled user authentication mechanism.
在本例中，客户端对TTLS服务器执行单向TLS身份验证。CHAP用作隧道用户身份验证机制。
client access point TTLS server AAA/H
------ ------------ ----------- -----
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{User-Name}
{CHAP-Challenge}
{CHAP-Password}
-------------------->
EAP-Response/TTLS:
{User-Name}
{CHAP-Challenge}
{CHAP-Password}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
User-Name
CHAP-Challenge
CHAP-Password
-------------------->
RADIUS Access-Request:
User-Name
CHAP-Challenge
CHAP-Password
-------------------->
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------
EAP-Success
<--------------------
In this example, the client performs one-way TLS authentication of the TTLS server and EAP/MD5-Challenge is used as a tunneled user authentication mechanism.
在此示例中，客户端对TTLS服务器执行单向TLS身份验证，EAP/MD5质询用作隧道用户身份验证机制。
client access point TTLS server AAA/H
------ ------------ ----------- -----
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{EAP-Response/Identity}
-------------------->
EAP-Response/TTLS:
{EAP-Response/Identity}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response/Identity
-------------------->
RADIUS Access-Challenge
EAP-Request/
MD5-Challenge
<--------------------
RADIUS Access-Challenge
EAP-Request/
MD5-Challenge
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
{EAP-Request/MD5-Challenge}
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
{EAP-Request/MD5-Challenge}
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{EAP-Response/MD5-Challenge}
-------------------->
EAP-Response/TTLS:
{EAP-Response/MD5-Challenge}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge
EAP-Response/
MD5-Challenge
-------------------->
RADIUS Access-Challenge
EAP-Response/
MD5-Challenge
-------------------->
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------
EAP-Success
<--------------------
In this example, the client and server resume a previous TLS session. The ID of the session to be resumed is sent as part of the ClientHello, and the server agrees to resume this session by sending the same session ID as part of ServerHello.
在本例中，客户端和服务器恢复以前的TLS会话。要恢复的会话ID作为ClientHello的一部分发送，服务器同意通过发送与ServerHello相同的会话ID来恢复此会话。
client access point TTLS server AAA/H
------ ------------ ----------- -----
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
ChangeCipherSpec
Finished
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ChangeCipherSpec
Finished
-------------------->
EAP-Response/TTLS:
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Accept:
EAP-Success
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------
EAP-Success
<--------------------
IANA has assigned the number 21 (decimal) as the method type of the EAP-TTLS protocol. Mechanisms for defining new RADIUS and Diameter AVPs and AVP values are outlined in [RFC2865] and [RFC3588], respectively. No additional IANA registrations are specifically contemplated in this document.
IANA已将数字21（十进制）指定为EAP-TTLS协议的方法类型。[RFC2865]和[RFC3588]分别概述了定义新半径和直径AVP和AVP值的机制。本文件中未特别考虑其他IANA注册。
Section 11 of this document specifies how certain authentication mechanisms may be performed within the secure tunnel established by EAP-TTLS. New mechanisms and other functions MAY also be performed within this tunnel. Where such extensions use AVPs that are not vendor-specific, their semantics must be specified in new RFCs; that is, there are TTLS-specific processing rules related to the use of each individual AVP, even though such AVPs have already been defined for RADIUS or DIAMETER.
本文件第11节规定了如何在EAP-TTLS建立的安全隧道内执行某些身份验证机制。新机制和其他功能也可在该隧道内执行。如果此类扩展使用非供应商特定的AVP，则必须在新的RFC中指定其语义；也就是说，存在与每个AVP的使用相关的TTLS特定处理规则，即使已经为半径或直径定义了此类AVP。
This specification requires the creation of a new registry -- EAP-TTLS AVP Usage -- to be managed by IANA, listing each non-vendor-specific RADIUS/Diameter AVP that has been defined for use within EAP-TTLS, along with a reference to the RFC or other document that specifies its semantics. The initial list of AVPs shall be those listed in Section 13 of this document. The purpose of this registry is to avoid potential ambiguity resulting from the same AVP being utilized in different functional contexts. This registry does not assign numbers to AVPs, as the AVP numbers are assigned out of the RADIUS and Diameter namespaces as outlined in [RFC2865] and [RFC3588]. Only top-level AVPs -- that is, AVPs not encapsulated within Grouped AVPs -- will be registered. AVPs should be added to this registry based on IETF Review as defined in [RFC5226].
本规范要求创建一个新的注册表——EAP-TTLS AVP USERATION——由IANA管理，列出已定义用于EAP-TTLS的每个非供应商特定半径/直径AVP，以及对RFC或其他指定其语义的文档的引用。AVP的初始列表应为本文件第13节中列出的列表。此注册表的目的是避免由于同一AVP在不同功能环境中使用而导致的潜在歧义。此注册表不向AVP分配编号，因为AVP编号是在[RFC2865]和[RFC3588]中概述的半径和直径名称空间之外分配的。只有顶级AVP（即未封装在分组AVP中的AVP）将被注册。AVP应根据[RFC5226]中定义的IETF审查添加到此注册表中。
Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful reviews and useful comments.
感谢Bernard Aboba、Jari Arkko、Lakshminath Dondeti、Stephen Hanna、Ryan Hurst、Avi Lior和Gabriel Montegon的仔细审查和有用的评论。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433]Zorn，G.和S.Cobb，“微软PPP CHAP扩展”，RFC 2433，1998年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]Zorn，G.，“微软PPP CHAP扩展，第2版”，RFC 2759，2000年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，Ed.“分配的数字：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[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月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
[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月。
[802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
[802.1X]电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X-2004，2004年12月。
[802.11] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2007.
[802.11]电气和电子工程师协会，“信息技术-系统间的电信和信息交换-局域网和城域网-特定要求第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.112007。
[TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP-TTLSv0", Work in Progress, September 2007.
[TTLS-EXT]Hanna，S.和P.Funk，“EAP-TTLSv0的关键敏捷扩展”，正在进行的工作，2007年9月。
[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月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[MITM] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-Middle in Tunneled Authentication", http://www.saunalahti.fi/~asokan/research/mitm.html, Nokia Research Center, Finland, October 24, 2002.
[MITM]Asokan，N.，Niemi，V.，和Nyberg，K.，“隧道认证中的中间人”，http://www.saunalahti.fi/~asokan/research/mitm.html，芬兰诺基亚研究中心，2002年10月24日。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]国家标准与技术研究所，“密钥管理建议”，特别出版物800-57，2006年5月。
Authors' Addresses
作者地址
Paul Funk 43 Linnaean St. Cambridge, MA 02138 EMail: PaulFunk@alum.mit.edu
Paul Funk 43马萨诸塞州剑桥林奈街02138电子邮件：PaulFunk@alum.mit.edu
Simon Blake-Wilson SafeNet Amstelveenseweg 88-90 1054XV, Amsterdam The Netherlands EMail: sblakewilson@nl.safenet-inc.com
Simon Blake Wilson SafeNet Amsterlveenseweg 88-90 1054XV，荷兰阿姆斯特丹电子邮件：sblakewilson@nl.safenet-公司
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.