Network Working Group D. Simon
Request for Comments: 5216 B. Aboba
Obsoletes: 2716 R. Hurst
Category: Standards Track Microsoft Corporation
March 2008
Network Working Group D. Simon
Request for Comments: 5216 B. Aboba
Obsoletes: 2716 R. Hurst
Category: Standards Track Microsoft Corporation
March 2008
The EAP-TLS Authentication Protocol
EAP-TLS认证协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.
RFC3748中定义的可扩展身份验证协议（EAP）支持多种身份验证方法。传输层安全性（TLS）提供了相互身份验证、完整性保护的密码套件协商以及两个端点之间的密钥交换。本文档定义了EAP-TLS，其中包括对基于证书的相互身份验证和密钥派生的支持。
This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A.
本文件淘汰了RFC 2716。附录A中提供了本文件与RFC 2716之间的变更摘要。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements ...............................................3
1.2. Terminology ................................................3
2. Protocol Overview ...............................................4
2.1. Overview of the EAP-TLS Conversation .......................4
2.1.1. Base Case ...........................................4
2.1.2. Session Resumption ..................................7
2.1.3. Termination .........................................8
2.1.4. Privacy ............................................11
2.1.5. Fragmentation ......................................14
2.2. Identity Verification .....................................16
2.3. Key Hierarchy .............................................17
2.4. Ciphersuite and Compression Negotiation ...................19
3. Detailed Description of the EAP-TLS Protocol ...................20
3.1. EAP-TLS Request Packet ....................................20
3.2. EAP-TLS Response Packet ...................................22
4. IANA Considerations ............................................23
5. Security Considerations ........................................24
5.1. Security Claims ...........................................24
5.2. Peer and Server Identities ................................25
5.3. Certificate Validation ....................................26
5.4. Certificate Revocation ....................................27
5.5. Packet Modification Attacks ...............................28
6. References .....................................................29
6.1. Normative References ......................................29
6.2. Informative References ....................................29
Acknowledgments ...................................................31
Appendix A -- Changes from RFC 2716 ...............................32
1. Introduction ....................................................2
1.1. Requirements ...............................................3
1.2. Terminology ................................................3
2. Protocol Overview ...............................................4
2.1. Overview of the EAP-TLS Conversation .......................4
2.1.1. Base Case ...........................................4
2.1.2. Session Resumption ..................................7
2.1.3. Termination .........................................8
2.1.4. Privacy ............................................11
2.1.5. Fragmentation ......................................14
2.2. Identity Verification .....................................16
2.3. Key Hierarchy .............................................17
2.4. Ciphersuite and Compression Negotiation ...................19
3. Detailed Description of the EAP-TLS Protocol ...................20
3.1. EAP-TLS Request Packet ....................................20
3.2. EAP-TLS Response Packet ...................................22
4. IANA Considerations ............................................23
5. Security Considerations ........................................24
5.1. Security Claims ...........................................24
5.2. Peer and Server Identities ................................25
5.3. Certificate Validation ....................................26
5.4. Certificate Revocation ....................................27
5.5. Packet Modification Attacks ...............................28
6. References .....................................................29
6.1. Normative References ......................................29
6.2. Informative References ....................................29
Acknowledgments ...................................................31
Appendix A -- Changes from RFC 2716 ...............................32
The Extensible Authentication Protocol (EAP), described in [RFC3748], provides a standard mechanism for support of multiple authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. EAP has been defined for use with a variety of lower layers, including the Point-to-Point Protocol (PPP) [RFC1661], Layer 2 tunneling protocols such as the Point-to-Point Tunneling Protocol (PPTP) [RFC2637] or Layer 2 Tunneling Protocol (L2TP) [RFC2661], IEEE 802 wired networks [IEEE-802.1X], and wireless technologies such as IEEE 802.11 [IEEE-802.11] and IEEE 802.16 [IEEE-802.16e].
[RFC3748]中描述的可扩展身份验证协议（EAP）提供了支持多种身份验证方法的标准机制。通过使用EAP，可以添加对许多身份验证方案的支持，包括智能卡、Kerberos、公钥、一次性密码等。EAP已被定义用于各种较低层，包括点对点协议（PPP）[RFC1661]、第2层隧道协议（如点对点隧道协议（PPTP）[RFC2637]或第2层隧道协议（L2TP）[RFC2661]、IEEE 802有线网络[IEEE-802.1X]和无线技术（如IEEE 802.11）[IEEE-802.11]和IEEE 802.16[IEEE-802.16e]。
While the EAP methods defined in [RFC3748] did not support mutual authentication, the use of EAP with wireless technologies such as [IEEE-802.11] has resulted in development of a new set of
虽然[RFC3748]中定义的EAP方法不支持相互认证，但将EAP与[IEEE-802.11]等无线技术结合使用，已导致开发了一套新的认证方法
requirements. As described in "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs" [RFC4017], it is desirable for EAP methods used for wireless LAN authentication to support mutual authentication and key derivation. Other link layers can also make use of EAP to enable mutual authentication and key derivation.
要求。如“无线局域网的可扩展认证协议（EAP）方法要求”[RFC4017]所述，用于无线局域网认证的EAP方法需要支持相互认证和密钥推导。其他链路层也可以使用EAP来实现相互认证和密钥派生。
This document defines EAP-Transport Layer Security (EAP-TLS), which includes support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS protocol, described in "The Transport Layer Security (TLS) Protocol Version 1.1" [RFC4346]. While this document obsoletes RFC 2716 [RFC2716], it remains backward compatible with it. A summary of the changes between this document and RFC 2716 is available in Appendix A.
本文档定义了EAP传输层安全（EAP-TLS），其中包括支持基于证书的相互认证和密钥派生，利用TLS协议的受保护密码套件协商、相互认证和密钥管理功能，如“传输层安全（TLS）协议版本1.1”所述[RFC4346]。虽然本文档淘汰了RFC 2716[RFC2716]，但它仍然向后兼容。附录A中提供了本文档与RFC 2716之间的更改摘要。
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]中所述进行解释。
This document frequently uses the following terms:
本文件经常使用以下术语：
authenticator The entity initiating EAP authentication.
authenticator发起EAP身份验证的实体。
peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the Supplicant.
对等响应身份验证器的实体。在[IEEE-802.1X]中，该实体称为请求者。
backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X].
后端身份验证服务器后端身份验证服务器是向身份验证者提供身份验证服务的实体。使用时，此服务器通常为身份验证程序执行EAP方法。此术语也在[IEEE-802.1X]中使用。
EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server.
EAP服务器与对等方终止EAP身份验证方法的实体。在不使用后端身份验证服务器的情况下，EAP服务器是身份验证程序的一部分。在认证器以直通模式操作的情况下，EAP服务器位于后端认证服务器上。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method.
主会话密钥（MSK）是在EAP对等方和服务器之间派生并通过EAP方法导出的密钥材料。
Extended Master Session Key (EMSK) Additional keying material derived between the EAP peer and server that is exported by the EAP method.
扩展主会话密钥（EMSK）：在EAP对等方和服务器之间派生的、通过EAP方法导出的附加密钥材料。
As described in [RFC3748], the EAP-TLS conversation will typically begin with the authenticator and the peer negotiating EAP. The authenticator will then typically send an EAP-Request/Identity packet to the peer, and the peer will respond with an EAP-Response/Identity packet to the authenticator, containing the peer's user-Id.
如[RFC3748]所述，EAP-TLS对话通常以认证者和对等协商EAP开始。然后，认证者通常将EAP请求/标识分组发送给对等方，对等方将使用包含对等方的用户Id的EAP响应/标识分组来响应认证者。
From this point forward, while nominally the EAP conversation occurs between the EAP authenticator and the peer, the authenticator MAY act as a pass-through device, with the EAP packets received from the peer being encapsulated for transmission to a backend authentication server. In the discussion that follows, we will use the term "EAP server" to denote the ultimate endpoint conversing with the peer.
从这一点开始，虽然名义上EAP会话发生在EAP认证器和对等方之间，但认证器可以充当直通设备，从对等方接收的EAP分组被封装以传输到后端认证服务器。在下面的讨论中，我们将使用术语“EAP服务器”来表示与对等方进行的最终端点转换。
Once having received the peer's Identity, the EAP server MUST respond with an EAP-TLS/Start packet, which is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS conversation will then begin, with the peer sending an EAP-Response packet with EAP-Type=EAP-TLS. The data field of that packet will encapsulate one or more TLS records in TLS record layer format, containing a TLS client_hello handshake message. The current cipher spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null
一旦接收到对等方的身份，EAP服务器必须用EAP-TLS/Start数据包进行响应，该数据包是EAP类型=EAP-TLS的EAP请求数据包，起始位设置为，且无数据。然后，EAP-TLS对话将开始，对等方发送EAP类型为EAP-TLS的EAP响应数据包。该数据包的数据字段将以TLS记录层格式封装一个或多个TLS记录，其中包含一条TLS客户机hello握手消息。TLS记录的当前密码规范将是TLS\u NULL\u，其中包含\u NULL\u NULL和NULL
compression. This current cipher spec remains the same until the change_cipher_spec message signals that subsequent records will have the negotiated attributes for the remainder of the handshake.
压缩。此当前密码规范保持不变，直到change_cipher_spec消息表明后续记录将具有握手剩余部分的协商属性。
The client_hello message contains the peer's TLS version number, a sessionId, a random number, and a set of ciphersuites supported by the peer. The version offered by the peer MUST correspond to TLS v1.0 or later.
client_hello消息包含对等方的TLS版本号、会话ID、随机数以及对等方支持的一组密码套件。对等方提供的版本必须对应于TLS v1.0或更高版本。
The EAP server will then respond with an EAP-Request packet with EAP-Type=EAP-TLS. The data field of this packet will encapsulate one or more TLS records. These will contain a TLS server_hello handshake
然后，EAP服务器将使用EAP Type=EAP-TLS的EAP请求数据包进行响应。此数据包的数据字段将封装一个或多个TLS记录。这些将包含TLS服务器\u hello握手
message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message. The server_hello handshake message contains a TLS version number, another random number, a sessionId, and a ciphersuite. The version offered by the server MUST correspond to TLS v1.0 or later.
消息，可能后跟TLS证书、服务器密钥交换、证书请求、服务器hello完成和/或完成握手消息和/或TLS更改密码规范消息。服务器hello握手消息包含一个TLS版本号、另一个随机数、一个会话ID和一个密码套件。服务器提供的版本必须对应于TLS v1.0或更高版本。
If the peer's sessionId is null or unrecognized by the server, the server MUST choose the sessionId to establish a new session. Otherwise, the sessionId will match that offered by the peer, indicating a resumption of the previously established session with that sessionId. The server will also choose a ciphersuite from those offered by the peer. If the session matches the peer's, then the ciphersuite MUST match the one negotiated during the handshake protocol execution that established the session.
如果对等方的sessionId为null或服务器无法识别，则服务器必须选择sessionId以建立新会话。否则，sessionId将与对等方提供的sessionId相匹配，表示使用该sessionId恢复先前建立的会话。服务器还将从对等方提供的密码套件中选择密码套件。如果会话与对等方匹配，则密码套件必须与建立会话的握手协议执行期间协商的密码套件匹配。
If the EAP server is not resuming a previously established session, then it MUST include a TLS server_certificate handshake message, and a server_hello_done handshake message MUST be the last handshake message encapsulated in this EAP-Request packet.
如果EAP服务器未恢复先前建立的会话，则它必须包含TLS server_证书握手消息，并且server_hello_done握手消息必须是封装在此EAP请求数据包中的最后一条握手消息。
The certificate message contains a public key certificate chain for either a key exchange public key (such as an RSA or Diffie-Hellman key exchange public key) or a signature public key (such as an RSA or Digital Signature Standard (DSS) signature public key). In the latter case, a TLS server_key_exchange handshake message MUST also be included to allow the key exchange to take place.
证书消息包含密钥交换公钥（如RSA或Diffie-Hellman密钥交换公钥）或签名公钥（如RSA或数字签名标准（DSS）签名公钥）的公钥证书链。在后一种情况下，还必须包含TLS服务器密钥交换握手消息，以便进行密钥交换。
The certificate_request message is included when the server desires the peer to authenticate itself via public key. While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means.
当服务器希望对等方通过公钥对自身进行身份验证时，会包含证书请求消息。虽然EAP服务器应要求对等身份验证，但这不是强制性的，因为在某些情况下不需要对等身份验证（例如，紧急服务，如[UNAUTH]中所述），或者对等身份验证将通过其他方式进行。
If the peer supports EAP-TLS and is configured to use it, it MUST respond to the EAP-Request with an EAP-Response packet of EAP-Type=EAP-TLS. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet did not indicate the resumption of a previous session, the data field of this packet MUST encapsulate one or more TLS records containing a TLS client_key_exchange, change_cipher_spec, and finished messages. If the EAP server sent a certificate_request message in the preceding EAP-Request packet, then unless the peer is configured for privacy (see Section 2.1.4) the peer MUST send, in addition, certificate and certificate_verify messages. The former contains a certificate for the peer's signature public key, while the latter contains the peer's signed authentication response to the EAP server. After receiving
如果对等方支持EAP-TLS并配置为使用它，则它必须使用EAP类型=EAP-TLS的EAP响应数据包响应EAP请求。如果EAP服务器在前一EAP请求数据包中发送的前一个服务器\u hello消息未指示前一个会话的恢复，则此数据包的数据字段必须封装一个或多个TLS记录，其中包含TLS客户端\u密钥\u交换、更改\u密码\u规范和完成的消息。如果EAP服务器在前面的EAP请求数据包中发送了证书请求消息，则除非对等方配置为隐私（参见第2.1.4节），否则对等方还必须发送证书和证书验证消息。前者包含对等方签名公钥的证书，而后者包含对等方对EAP服务器的签名认证响应。收到后
this packet, the EAP server will verify the peer's certificate and digital signature, if requested.
如果请求，EAP服务器将验证对等方的证书和数字签名。
If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server.
如果EAP服务器在前一EAP请求数据包中发送的前一服务器\u hello消息指示前一会话的恢复，则对等方必须仅发送更改\u密码\u规范和完成的握手消息。完成的消息包含对等方对EAP服务器的身份验证响应。
In the case where the EAP-TLS mutual authentication is successful, the conversation will appear as follows:
在EAP-TLS相互认证成功的情况下，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
The purpose of the sessionId within the TLS protocol is to allow for improved efficiency in the case where a peer repeatedly attempts to authenticate to an EAP server within a short period of time. While this model was developed for use with HTTP authentication, it also can be used to provide "fast reconnect" functionality as defined in Section 7.2.1 of [RFC3748].
TLS协议中sessionId的目的是在对等方在短时间内反复尝试向EAP服务器进行身份验证的情况下提高效率。虽然该模型是为HTTP认证而开发的，但它也可用于提供[RFC3748]第7.2.1节中定义的“快速重新连接”功能。
It is left up to the peer whether to attempt to continue a previous session, thus shortening the TLS conversation. Typically, the peer's decision will be made based on the time elapsed since the previous authentication attempt to that EAP server. Based on the sessionId chosen by the peer, and the time elapsed since the previous authentication, the EAP server will decide whether to allow the continuation or to choose a new session.
是否尝试继续上一个会话，从而缩短TLS对话，由对等方决定。通常，对等方的决定将基于自上次尝试对该EAP服务器进行身份验证以来经过的时间。根据对等方选择的会话ID以及自上次身份验证以来经过的时间，EAP服务器将决定是允许继续还是选择新会话。
In the case where the EAP server and authenticator reside on the same device, the peer will only be able to continue sessions when connecting to the same authenticator. Should the authenticators be set up in a rotary or round-robin, then it may not be possible for the peer to know in advance the authenticator to which it will be connecting, and therefore which sessionId to attempt to reuse. As a result, it is likely that the continuation attempt will fail. In the case where the EAP authentication is remoted, then continuation is much more likely to be successful, since multiple authenticators will utilize the same backend authentication server.
如果EAP服务器和验证器位于同一设备上，则对等方将只能在连接到同一验证器时继续会话。如果在循环或循环中设置认证器，则对等方可能无法提前知道其将连接到的认证器，因此无法知道尝试重用的会话ID。因此，继续尝试很可能会失败。在EAP身份验证是远程的情况下，由于多个身份验证程序将使用相同的后端身份验证服务器，因此继续更可能成功。
If the EAP server is resuming a previously established session, then it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message. The finished message contains the EAP server's authentication response to the peer.
如果EAP服务器正在恢复先前建立的会话，则它必须仅包括TLS change_cipher_spec消息和服务器hello消息后的TLS FINATED handshake消息。完成的消息包含EAP服务器对对等方的身份验证响应。
In the case where a previously established session is being resumed, and both sides authenticate successfully, the conversation will appear as follows:
如果先前建立的会话正在恢复，并且双方都成功进行了身份验证，则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- EAP-Success
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- EAP-Success
If the peer's authentication is unsuccessful, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record containing the appropriate TLS alert message. The EAP server SHOULD send a TLS alert message immediately terminating the conversation so as to allow the peer to inform the user or log the cause of the failure and possibly allow for a restart of the conversation.
如果对等方的身份验证失败，EAP服务器应发送EAP Type=EAP-TLS的EAP请求数据包，封装包含适当TLS警报消息的TLS记录。EAP服务器应立即发送TLS警报消息终止对话，以便允许对等方通知用户或记录故障原因，并可能允许重新启动对话。
To ensure that the peer receives the TLS alert message, the EAP server MUST wait for the peer to reply with an EAP-Response packet. The EAP-Response packet sent by the peer MAY encapsulate a TLS client_hello handshake message, in which case the EAP server MAY allow the EAP-TLS conversation to be restarted, or it MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST send an EAP-Failure packet and terminate the conversation. It is up to the EAP server whether to allow restarts, and if so, how many times the conversation can be restarted. An EAP Server implementing restart capability SHOULD impose a per-peer limit
为确保对等方收到TLS警报消息，EAP服务器必须等待对等方使用EAP响应数据包进行回复。对等方发送的EAP响应包可以封装TLS客户端\u hello握手消息，在这种情况下，EAP服务器可以允许重新启动EAP-TLS会话，或者它可以包含EAP类型=EAP-TLS且无数据的EAP响应包，在这种情况下，EAP服务器必须发送EAP故障包并终止会话。是否允许重启取决于EAP服务器，如果允许重启，则取决于会话可以重启多少次。实现重启功能的EAP服务器应施加每个对等方的限制
on the number of restarts, so as to protect against denial-of-service attacks.
重新启动的次数，以防止拒绝服务攻击。
If the peer authenticates successfully, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in the case of a new TLS session, one or more TLS records containing TLS change_cipher_spec and finished handshake messages. The latter contains the EAP server's authentication response to the peer. The peer will then verify the finished message in order to authenticate the EAP server.
如果对等方认证成功，EAP服务器必须使用EAP Type=EAP-TLS的EAP请求数据包进行响应，在新TLS会话的情况下，该数据包包括一个或多个包含TLS更改密码规范和完成握手消息的TLS记录。后者包含EAP服务器对对等方的身份验证响应。然后，对等方将验证完成的消息，以便对EAP服务器进行身份验证。
If EAP server authentication is unsuccessful, the peer SHOULD delete the session from its cache, preventing reuse of the sessionId. The peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator.
如果EAP服务器身份验证失败，对等方应从其缓存中删除会话，从而防止会话ID的重用。对等方可发送EAP类型=EAP-TLS的EAP响应包，其中包含识别认证失败原因的TLS警报消息。对等方可以发送TLS警报消息，而不是立即终止对话，以便EAP服务器记录错误原因，供系统管理员检查。
To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP Server to reply before terminating the conversation. The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition.
为确保EAP服务器收到TLS警报消息，对等方必须等待EAP服务器回复，然后才能终止对话。EAP服务器必须使用EAP失败数据包进行回复，因为服务器身份验证失败是一种终端条件。
If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP Server then MUST respond with an EAP-Success message.
如果EAP服务器验证成功，则对等方必须发送EAP类型=EAP-TLS的EAP响应数据包，且无数据。然后，EAP服务器必须响应EAP成功消息。
In the case where the server authenticates to the peer successfully, but the peer fails to authenticate to the server, the conversation will appear as follows:
如果服务器成功向对等方进行身份验证，但对等方未能向服务器进行身份验证，则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) ->
EAP响应/EAP类型=EAP-TLS（TLS证书、TLS客户端密钥交换、TLS证书验证、TLS更改、密码规范、TLS完成）->
<- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Request EAP-Type=EAP-TLS (TLS Alert message) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Failure (User Disconnected)
<-EAP请求/EAP类型=EAP-TLS（TLS更改\u密码\u规范，TLS完成）EAP响应/EAP类型=EAP-TLS-><-EAP请求EAP类型=EAP-TLS（TLS警报消息）EAP响应/EAP类型=EAP-TLS-><-EAP故障（用户断开连接）
In the case where server authentication is unsuccessful, the conversation will appear as follows:
如果服务器身份验证失败，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- EAP-Failure
(User Disconnected)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- EAP-Failure
(User Disconnected)
EAP-TLS peer and server implementations MAY support privacy. Disclosure of the username is avoided by utilizing a privacy Network Access Identifier (NAI) [RFC4282] in the EAP-Response/Identity, and transmitting the peer certificate within a TLS session providing confidentiality.
EAP-TLS对等和服务器实现可能支持隐私。通过在EAP响应/标识中使用隐私网络访问标识符（NAI）[RFC4282]，并在提供机密性的TLS会话中传输对等证书，可以避免用户名的泄露。
In order to avoid disclosing the peer username, an EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing no entries in response to the initial certificate_request from the EAP-TLS server.
为了避免泄露对等方用户名，配置为隐私的EAP-TLS对等方必须协商支持机密性的TLS密码套件，并且必须提供不包含任何条目的客户端证书列表，以响应EAP-TLS服务器的初始证书请求。
An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead, it MUST bring up the TLS session and then send a hello_request. The handshake then proceeds normally; the peer sends a client_hello and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, etc.
支持隐私的EAP-TLS服务器不得将不包含任何条目的证书列表视为终端条件；相反，它必须启动TLS会话，然后发送hello_请求。然后握手正常进行；对等方发送客户端hello，服务器回复服务器hello、证书、服务器密钥交换、证书请求、服务器hello完成等。
For the calculation of exported keying material (see Section 2.3), the master_secret derived within the second handshake is used.
对于导出的键控材料的计算（参见第2.3节），使用在第二次握手中导出的主密钥。
An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting privacy does not receive a client certificate in response to the subsequent certificate_request, then it MUST abort the session.
支持隐私的EAP-TLS对等方必须提供包含至少一个条目的证书列表，以响应服务器发送的后续证书请求。如果支持隐私的EAP-TLS服务器没有收到响应后续证书请求的客户端证书，则必须中止会话。
EAP-TLS privacy support is designed to allow EAP-TLS peers that do not support privacy to interoperate with EAP-TLS servers supporting privacy. EAP-TLS servers supporting privacy MUST request a client certificate, and MUST be able to accept a client certificate offered by the EAP-TLS peer, in order to preserve interoperability with EAP-TLS peers that do not support privacy.
EAP-TLS隐私支持旨在允许不支持隐私的EAP-TLS对等方与支持隐私的EAP-TLS服务器进行互操作。支持隐私的EAP-TLS服务器必须请求客户端证书，并且必须能够接受EAP-TLS对等方提供的客户端证书，以保持与不支持隐私的EAP-TLS对等方的互操作性。
However, an EAP-TLS peer configured for privacy typically will not be able to successfully authenticate with an EAP-TLS server that does not support privacy, since such a server will typically treat the refusal to provide a client certificate as a terminal error. As a result, unless authentication failure is considered preferable to disclosure of the username, EAP-TLS peers SHOULD only be configured for privacy on networks known to support it.
然而，为隐私配置的EAP-TLS对等方通常无法成功地向不支持隐私的EAP-TLS服务器进行身份验证，因为这样的服务器通常会将拒绝提供客户端证书视为终端错误。因此，除非认证失败被认为比用户名泄露更可取，否则EAP-TLS对等方应仅在已知支持它的网络上配置隐私。
This is most easily achieved with EAP lower layers that support network advertisement, so that the network and appropriate privacy configuration can be determined. In order to determine the privacy configuration on link layers (such as IEEE 802 wired networks) that do not support network advertisement, it may be desirable to utilize information provided in the server certificate (such as the subject and subjectAltName fields) or within identity selection hints [RFC4284] to determine the appropriate configuration.
这最容易通过支持网络广告的EAP较低层实现，因此可以确定网络和适当的隐私配置。为了确定不支持网络广告的链路层（如IEEE 802有线网络）上的隐私配置，可能需要利用服务器证书（如subject和subjectAltName字段）或身份选择提示中提供的信息[RFC4284]以确定适当的配置。
In the case where the peer and server support privacy and mutual authentication, the conversation will appear as follows:
在对等方和服务器支持隐私和相互身份验证的情况下，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (Anonymous NAI) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (Anonymous NAI) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate (no cert), TLS client_key_exchange, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, finished, hello_request) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, TLS server_key_exchange, TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Success
EAP响应/EAP类型=EAP-TLS（TLS客户端\u hello）-><-EAP请求/EAP类型=EAP-TLS（TLS服务器\u hello，TLS证书，[TLS服务器\u密钥交换，]TLS证书\u请求，TLS服务器\u hello\u完成）EAP响应/EAP类型=EAP-TLS（TLS证书（无证书），TLS客户端\u密钥交换，TLS更改\u密码\u规范，TLS完成）-><-EAP请求/EAP类型=EAP-TLS（TLS更改\u密码\u规范，完成，你好\u请求）EAP响应/EAP类型=EAP-TLS（TLS客户端\u你好）-><-EAP请求/EAP类型=EAP-TLS（TLS服务器\u你好，TLS证书，TLS服务器\u密钥交换，TLS证书\u请求，TLS服务器\u你好\u完成）EAP响应/EAP类型=EAP-TLS（TLS证书、TLS客户端密钥交换、TLS证书验证、TLS更改密码规范、TLS完成）-><-EAP请求/EAP类型=EAP-TLS（TLS更改密码规范、TLS完成）EAP响应/EAP类型=EAP-TLS-><-EAP成功
A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may in principle be as long as 16 MB. The group of EAP-TLS messages sent in a single round may thus be larger than the MTU size or the maximum Remote Authentication Dail-In User Service (RADIUS) packet size of 4096 octets. As a result, an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly. However, in order to ensure interoperability with existing implementations, TLS handshake messages SHOULD NOT be fragmented into multiple TLS records if they fit within a single TLS record.
单个TLS记录的长度可能高达16384个八位字节，但TLS消息可能跨越多个TLS记录，原则上TLS证书消息的长度可能长达16 MB。因此，在单轮中发送的EAP-TLS消息组可能大于MTU大小或用户服务中的最大远程认证Dail（RADIUS）数据包大小4096个八位字节。因此，EAP-TLS实现必须为碎片和重组提供自己的支持。但是，为了确保与现有实现的互操作性，如果TLS握手消息适合于单个TLS记录，则不应将其分割为多个TLS记录。
In order to protect against reassembly lockup and denial-of-service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a single certificate is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB.
为了防止重组锁定和拒绝服务攻击，实现可能需要为一组这样的TLS消息设置最大大小。由于单个证书的长度很少超过几千个八位字节，而且其他字段的长度也不可能接近几千个八位字节，因此可接受的最大消息长度的合理选择可能是64 KB。
Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field as is provided in IPv4.
由于EAP是一个简单的ACK-NAK协议，因此可以以简单的方式添加碎片支持。在EAP中，在传输过程中丢失或损坏的片段将被重新传输，并且由于序列信息由EAP中的标识符字段提供，因此不需要IPv4中提供的片段偏移字段。
EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. Flags include the Length included (L), More fragments (M), and EAP-TLS Start (S) bits. The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M flag is set on all but the last fragment. The S flag is set only within the EAP-TLS start message sent from the EAP server to the peer. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented; this simplifies buffer allocation.
EAP-TLS分段支持是通过在EAP响应和EAP请求数据包中添加标志八位组以及四个八位组的TLS消息长度字段来提供的。标志包括包含的长度（L）、更多片段（M）和EAP-TLS起始位。设置L标志以指示存在四个八位组的TLS消息长度字段，并且必须为分段TLS消息或消息集的第一个片段设置L标志。除最后一个片段外，所有片段都设置了M标志。S标志仅在从EAP服务器发送到对等方的EAP-TLS启动消息中设置。TLS消息长度字段为四个八位字节，并提供正在分段的TLS消息或消息集的总长度；这简化了缓冲区分配。
When an EAP-TLS peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
当EAP-TLS对等方接收到设置了M位的EAP请求数据包时，它必须以EAP Type=EAP-TLS且无数据的EAP响应进行响应。这是一个片段。EAP服务器必须等到收到EAP响应后再发送另一个片段。为了防止处理片段时出错，EAP服务器必须增加EAP请求中包含的每个片段的标识符字段，并且对等方必须在EAP响应中包含的片段确认中包含此标识符值。重新传输的片段将包含相同的标识符值。
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
类似地，当EAP服务器接收到设置为M位的EAP响应时，它必须使用EAP Type=EAP-TLS且无数据的EAP请求进行响应。这是一个片段。EAP对等方必须等到收到EAP请求后再发送另一个片段。为了防止片段处理中出现错误，EAP服务器必须增加EAP请求中包含的每个片段ACK的标识符值，并且对等方必须在EAP响应中包含的后续片段中包含该标识符值。
In the case where the EAP-TLS mutual authentication is successful, and fragmentation is required, the conversation will appear as follows:
如果EAP-TLS相互认证成功，并且需要分段，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished)(Fragment 1: L, M bits set)-> <- EAP-Request/ EAP-Type=EAP-TLS EAP-Response/ EAP-Type=EAP-TLS (Fragment 2)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Success
EAP响应/EAP类型=EAP-TLS（TLS证书、TLS客户端密钥交换、TLS证书验证、TLS更改密码规范、TLS完成）（片段1:L，M位集）-><-EAP请求/EAP类型=EAP-TLS EAP响应/EAP类型=EAP-TLS（片段2）-><-EAP请求/EAP类型=EAP-TLS（TLS更改密码规范，TLS完成）EAP响应/EAP类型=EAP-TLS-><-EAP成功
As noted in Section 5.1 of [RFC3748]:
如[RFC3748]第5.1节所述：
It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.
建议标识响应主要用于路由目的和选择要使用的EAP方法。EAP方法应包括用于获取身份的方法特定机制，以便它们不必依赖身份响应。
As part of the TLS negotiation, the server presents a certificate to the peer, and if mutual authentication is requested, the peer presents a certificate to the server. EAP-TLS therefore provides a mechanism for determining both the peer identity (Peer-Id in [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]). For details, see Section 5.2.
作为TLS协商的一部分，服务器向对等方提供证书，如果请求相互身份验证，对等方向服务器提供证书。因此，EAP-TLS提供了一种确定对等身份（在[KEYFRAME]中的对等Id）和服务器身份（在[KEYFRAME]中的服务器Id）的机制。有关详细信息，请参见第5.2节。
Since the identity presented in the EAP-Response/Identity need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical. However, if they are not identical, the identity presented in the EAP-Response/Identity is unauthenticated information, and SHOULD NOT be used for access control or accounting purposes.
由于EAP响应/标识中显示的标识不需要与对等证书中显示的标识相关，因此EAP-TLS实现不应要求它们相同。但是，如果它们不相同，EAP响应/标识中显示的标识是未经验证的信息，不应用于访问控制或记帐目的。
Figure 1 illustrates the TLS Key Hierarchy, described in [RFC4346] Section 6.3. The derivation proceeds as follows:
图1说明了第6.3节[RFC4346]中描述的TLS密钥层次结构。推导过程如下：
master_secret = TLS-PRF-48(pre_master_secret, "master secret", client.random || server.random) key_block = TLS-PRF-X(master_secret, "key expansion", server.random || client.random)
master_secret=TLS-PRF-48（pre_master_secret，“master secret”，client.random | server.random）key_block=TLS-PRF-X（master_secret，“key expansion”，server.random | client.random）
Where:
哪里：
TLS-PRF-X = TLS pseudo-random function defined in [RFC4346], computed to X octets.
TLS-PRF-X=在[RFC4346]中定义的TLS伪随机函数，计算为X个八位字节。
In EAP-TLS, the MSK, EMSK, and Initialization Vector (IV) are derived from the TLS master secret via a one-way function. This ensures that the TLS master secret cannot be derived from the MSK, EMSK, or IV unless the one-way function (TLS PRF) is broken. Since the MSK and EMSK are derived from the TLS master secret, if the TLS master secret is compromised then the MSK and EMSK are also compromised.
在EAP-TLS中，MSK、EMSK和初始化向量（IV）通过单向函数从TLS主密钥中导出。这确保了TLS主密钥不能从MSK、EMSK或IV派生，除非单向函数（TLS PRF）被破坏。由于MSK和EMSK来自TLS主密钥，因此如果TLS主密钥被泄露，则MSK和EMSK也被泄露。
The MSK is divided into two halves, corresponding to the "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32 octets) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key, 32 octets).
MSK分为两半，分别对应于“对等认证方加密密钥”（Enc RECV密钥，32个八位字节）和“认证方对对等加密密钥”（Enc SEND密钥，32个八位字节）。
The IV is a 64-octet quantity that is a known value; octets 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
IV是一个已知值的64个八位组的量；八位字节0-31称为“对等认证器IV”或RECV-IV，八位字节32-63称为“对等认证器IV”或SEND-IV。
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<----+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| key_block |
| label == "key expansion" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<----+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| key_block |
| label == "key expansion" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
Figure 1 - TLS [RFC4346] Key Hierarchy
图1-TLS[RFC4346]密钥层次结构
EAP-TLS derives exported keying material and parameters as follows:
EAP-TLS导出的键控材料和参数如下：
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
client.random || server.random)
MSK = Key_Material(0,63)
EMSK = Key_Material(64,127)
IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random)
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
client.random || server.random)
MSK = Key_Material(0,63)
EMSK = Key_Material(64,127)
IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random)
Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK in [IEEE-802.11].
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
(MS-MPPE-Send-Key in [RFC2548])
RECV-IV = IV(0,31) = Peer to Authenticator Initialization Vector
SEND-IV = IV(32,63) = Authenticator to Peer Initialization
Vector
Session-Id = 0x0D || client.random || server.random
Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK in [IEEE-802.11].
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
(MS-MPPE-Send-Key in [RFC2548])
RECV-IV = IV(0,31) = Peer to Authenticator Initialization Vector
SEND-IV = IV(32,63) = Authenticator to Peer Initialization
Vector
Session-Id = 0x0D || client.random || server.random
Where:
哪里：
Key_Material(W,Z) = Octets W through Z inclusive of the key material. IV(W,Z) = Octets W through Z inclusive of the IV. MSK(W,Z) = Octets W through Z inclusive of the MSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK. TLS-PRF-X = TLS PRF function computed to X octets. client.random = Nonce generated by the TLS client. server.random = Nonce generated by the TLS server.
键_材料（W，Z）=八位字节W到Z，包括键材料。IV（W，Z）=八位字节W到Z，包括IV。MSK（W，Z）=八位字节W到Z，包括MSK。EMSK（W，Z）=八位字节W到Z，包括EMSK。TLS-PRF-X=计算为X个八位字节的TLS PRF函数。client.random=TLS客户端生成的Nonce。server.random=由TLS服务器生成的Nonce。
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<----+
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MSK, EMSK |
| label == "client EAP encryption" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MSK(0,31) | MSK(32,63) | EMSK(0,63)
| | |
| | |
V V V
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<----+
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MSK, EMSK |
| label == "client EAP encryption" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MSK(0,31) | MSK(32,63) | EMSK(0,63)
| | |
| | |
V V V
Figure 2 - EAP-TLS Key Hierarchy
图2-EAP-TLS密钥层次结构
The use of these keys is specific to the lower layer, as described in Section 2.1 of [KEYFRAME].
如[关键帧]第2.1节所述，这些关键帧的使用特定于下层。
EAP-TLS implementations MUST support TLS v1.0.
EAP-TLS实施必须支持TLS v1.0。
EAP-TLS implementations need not necessarily support all TLS ciphersuites listed in [RFC4346]. Not all TLS ciphersuites are supported by available TLS tool kits, and licenses may be required in some cases.
EAP-TLS实现不一定支持[RFC4346]中列出的所有TLS密码套件。并非所有TLS密码套件都受可用TLS工具包支持，在某些情况下可能需要许可证。
To ensure interoperability, EAP-TLS peers and servers MUST support the TLS [RFC4346] mandatory-to-implement ciphersuite:
为确保互操作性，EAP-TLS对等方和服务器必须支持实施ciphersuite所必需的TLS[RFC4346]：
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_与_3DES_EDE_CBC_SHA
EAP-TLS peers and servers SHOULD also support and be able to negotiate the following TLS ciphersuites:
EAP-TLS对等方和服务器还应支持并能够协商以下TLS密码套件：
TLS_RSA_WITH_RC4_128_SHA [RFC4346] TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]
TLS_RSA_与_RC4_128_SHA[RFC4346]TLS_RSA_与_AES_128_CBC_SHA[RFC3268]
In addition, EAP-TLS servers SHOULD support and be able to negotiate the following TLS ciphersuite:
此外，EAP-TLS服务器应支持并能够协商以下TLS密码套件：
TLS_RSA_WITH_RC4_128_MD5 [RFC4346]
TLS_RSA_与_RC4_128_MD5[RFC4346]
Since TLS supports ciphersuite negotiation, peers completing the TLS negotiation will also have selected a ciphersuite, which includes encryption and hashing methods. Since the ciphersuite negotiated within EAP-TLS applies only to the EAP conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate the ciphersuites used to secure data.
由于TLS支持密码套件协商，完成TLS协商的对等方还将选择一个密码套件，其中包括加密和哈希方法。由于EAP-TLS中协商的密码套件仅适用于EAP对话，因此TLS密码套件协商不得用于协商用于保护数据的密码套件。
TLS also supports compression as well as ciphersuite negotiation. However, during the EAP-TLS conversation the EAP peer and server MUST NOT request or negotiate compression.
TLS还支持压缩和密码套件协商。但是，在EAP-TLS对话期间，EAP对等方和服务器不得请求或协商压缩。
A summary of the EAP-TLS Request packet format is shown below. The fields are transmitted from left to right.
EAP-TLS请求数据包格式摘要如下所示。字段从左向右传输。
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 | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS 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 | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
1
1.
Identifier
标识符
The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet.
标识符字段是一个八位字节，有助于将响应与请求匹配。必须在每个请求数据包上更改标识符字段。
Length
长
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时必须忽略。
Type
类型
13 -- EAP-TLS
13——EAP-TLS
Flags
旗帜
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+
L = Length included M = More fragments S = EAP-TLS start R = Reserved
L=包含的长度M=更多碎片S=EAP-TLS开始R=保留
The L bit (length included) is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S bit (EAP-TLS start) is set in an EAP-TLS Start message. This differentiates the EAP-TLS Start message from a fragment acknowledgment. Implementations of this specification MUST set the reserved bits to zero, and MUST ignore them on reception.
设置L位（包括长度）以指示存在四个八位TLS消息长度字段，并且必须为分段TLS消息或消息集的第一个片段设置。M位（更多片段）设置在除最后一个片段外的所有片段上。在EAP-TLS启动消息中设置S位（EAP-TLS启动）。这将EAP-TLS启动消息与片段确认区别开来。本规范的实现必须将保留位设置为零，并且在接收时必须忽略它们。
TLS Message Length
TLS消息长度
The TLS Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the TLS message or set of messages that is being fragmented.
TLS消息长度字段为四个八位字节，仅当设置了L位时才存在。此字段提供正在分段的TLS消息或消息集的总长度。
TLS data
TLS数据
The TLS data consists of the encapsulated TLS packet in TLS record format.
TLS数据由TLS记录格式的封装TLS数据包组成。
A summary of the EAP-TLS Response packet format is shown below. The fields are transmitted from left to right.
EAP-TLS响应数据包格式摘要如下所示。字段从左向右传输。
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 | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS 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 | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
2
2.
Identifier
标识符
The Identifier field is one octet and MUST match the Identifier field from the corresponding request.
标识符字段是一个八位字节，必须与相应请求中的标识符字段匹配。
Length
长
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时必须忽略。
Type
类型
13 -- EAP-TLS
13——EAP-TLS
Flags
旗帜
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M R R R R R R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M R R R R R R|
+-+-+-+-+-+-+-+-+
L = Length included M = More fragments R = Reserved
L=包含长度M=更多碎片R=保留
The L bit (length included) is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. Implementations of this specification MUST set the reserved bits to zero, and MUST ignore them on reception.
设置L位（包括长度）以指示存在四个八位TLS消息长度字段，并且必须为分段TLS消息或消息集的第一个片段设置。M位（更多片段）设置在除最后一个片段外的所有片段上。本规范的实现必须将保留位设置为零，并且在接收时必须忽略它们。
TLS Message Length
TLS消息长度
The TLS Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the TLS message or set of messages that is being fragmented.
TLS消息长度字段为四个八位字节，仅当设置了L位时才存在。此字段提供正在分段的TLS消息或消息集的总长度。
TLS data
TLS数据
The TLS data consists of the encapsulated TLS packet in TLS record format.
TLS数据由TLS记录格式的封装TLS数据包组成。
IANA has allocated EAP Type 13 for EAP-TLS. The allocation has been updated to reference this document.
IANA已为EAP-TLS分配了EAP类型13。分配已更新，以引用此文档。
EAP security claims are defined in Section 7.2.1 of [RFC3748]. The security claims for EAP-TLS are as follows:
[RFC3748]第7.2.1节对EAP担保索赔进行了定义。EAP-TLS的安全声明如下：
Auth. mechanism: Certificates
Ciphersuite negotiation: Yes [4]
Mutual authentication: Yes [1]
Integrity protection: Yes [1]
Replay protection: Yes [1]
Confidentiality: Yes [2]
Key derivation: Yes
Key strength: [3]
Dictionary attack prot.: Yes
Fast reconnect: Yes
Crypt. binding: N/A
Session independence: Yes [1]
Fragmentation: Yes
Channel binding: No
Auth. mechanism: Certificates
Ciphersuite negotiation: Yes [4]
Mutual authentication: Yes [1]
Integrity protection: Yes [1]
Replay protection: Yes [1]
Confidentiality: Yes [2]
Key derivation: Yes
Key strength: [3]
Dictionary attack prot.: Yes
Fast reconnect: Yes
Crypt. binding: N/A
Session independence: Yes [1]
Fragmentation: Yes
Channel binding: No
Notes
-----
Notes
-----
[1] A formal proof of the security of EAP-TLS when used with [IEEE-802.11] is provided in [He]. This proof relies on the assumption that the private key pairs used by the EAP peer and server are not shared with other parties or applications. For example, a backend authentication server supporting EAP-TLS SHOULD NOT utilize the same certificate with https.
[1] [He]中提供了EAP-TLS与[IEEE-802.11]一起使用时安全性的正式证明。该证明基于EAP对等方和服务器使用的私钥对不与其他方或应用程序共享的假设。例如，支持EAP-TLS的后端身份验证服务器不应将同一证书与https一起使用。
[2] Privacy is an optional feature described in Section 2.1.4.
[2] 隐私是第2.1.4节中描述的可选功能。
[3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or Diffie-Hellman (DH) module and Digital Signature Algorithm (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 of Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
[3] BCP 86[RFC3766]第5节提供了关于给定抗攻击等级（以位为单位）所需RSA或Diffie-Hellman（DH）模块和数字签名算法（DSA）子组大小（以位为单位）的建议。例如，建议使用2048位RSA密钥来提供128位等效密钥强度。国家标准与技术研究所（NIST）还就[SP800-57]中的适当键尺寸提供了建议。
[4] EAP-TLS inherits the secure ciphersuite negotiation features of TLS, including key derivation function negotiation when utilized with TLS v1.2 [RFC4346bis].
[4] EAP-TLS继承了TLS的安全密码套件协商功能，包括与TLS v1.2[RFC4346bis]一起使用时的密钥派生函数协商。
The EAP-TLS peer name (Peer-Id) represents the identity to be used for access control and accounting purposes. The Server-Id represents the identity of the EAP server. Together the Peer-Id and Server-Id name the entities involved in deriving the MSK/EMSK.
EAP-TLS对等名称（对等Id）表示用于访问控制和记帐目的的标识。服务器Id表示EAP服务器的标识。对等Id和服务器Id一起命名派生MSK/EMSK所涉及的实体。
In EAP-TLS, the Peer-Id and Server-Id are determined from the subject or subjectAltName fields in the peer and server certificates. For details, see Section 4.1.2.6 of [RFC3280]. Where the subjectAltName field is present in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName. If subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical.
在EAP-TLS中，对等Id和服务器Id由对等证书和服务器证书中的subject或subjectAltName字段确定。有关详细信息，请参见[RFC3280]第4.1.2.6节。如果对等或服务器证书中存在subjectAltName字段，则必须将对等Id或服务器Id设置为subjectAltName的内容。如果使用者命名信息仅存在于对等或服务器证书的subjectAltName扩展中，则使用者字段必须为空序列，并且subjectAltName扩展必须是关键的。
Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in Section 2.1 of [RFC4282]. If a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used.
当对等身份表示主机时，对等证书中应存在dnsName类型的subjectAltName。如果对等身份表示用户而不是资源，则应使用rfc822Name类型的subjectAltName，符合[RFC4282]第2.1节中定义的网络访问标识符（NAI）语法。如果dnsName或RFC822名称不可用，则可以使用其他字段类型（例如，ipAddress或uniformResourceIdentifier类型的subjectAltName）。
A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dnsName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used.
服务器标识通常表示主机，而不是用户或资源。因此，服务器证书中应该存在dnsName类型的subjectAltName。如果dnsName不可用，则可以使用其他字段类型（例如，ipAddress或uniformResourceIdentifier类型的subjectAltName）。
Conforming implementations generating new certificates with Network Access Identifiers (NAIs) MUST use the rfc822Name in the subject alternative name field to describe such identities. The use of the subject name field to contain an emailAddress Relative Distinguished Name (RDN) is deprecated, and MUST NOT be used. The subject name field MAY contain other RDNs for representing the subject's identity.
生成具有网络访问标识符（NAI）的新证书的一致性实现必须使用subject alternative name字段中的RFC822名称来描述此类身份。不推荐使用subject name字段来包含emailAddress相对可分辨名称（RDN），并且不得使用。“受试者姓名”字段可能包含用于表示受试者身份的其他RDN。
Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). If subject naming information is present only in the subject name field of a peer certificate and the peer identity represents a host or device, the subject name field SHOULD contain a CommonName (CN) RDN or serialNumber RDN. If subject naming information is present only in the subject name field of a server certificate, then the subject name field SHOULD contain a CN RDN or serialNumber RDN.
如果不为空，则“主题名称”字段必须包含X.500可分辨名称（DN）。如果主题命名信息仅存在于对等证书的主题名称字段中，且对等身份表示主机或设备，则主题名称字段应包含CommonName（CN）RDN或serialNumber RDN。如果使用者命名信息仅存在于服务器证书的使用者名称字段中，则使用者名称字段应包含CN RDN或serialNumber RDN。
It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also export a non-empty subject distinguished name field within the Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid.
除了空的或非空的主题可分辨名称外，对等或服务器证书中还可能存在多个subjectAltName字段。支持导出对等Id和服务器Id的EAP-TLS实现应导出对等Id或服务器Id中的所有subjectAltName字段，还应导出对等Id或服务器Id中的非空主题可分辨名称字段。所有导出的对等ID和服务器ID都被视为有效。
EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOULD export Peer-Ids and Server-Ids in the same order in which they appear within the certificate. Such canonical ordering would aid in comparison operations and would enable using those identifiers for key derivation if that is deemed useful. However, the ordering of fields within the certificate SHOULD NOT be used for access control.
支持对等Id和服务器Id导出的EAP-TLS实现应按照对等Id和服务器Id在证书中的显示顺序导出。这种规范化排序将有助于比较操作，并且如果认为有用的话，可以使用这些标识符进行密钥派生。但是，证书中字段的顺序不应用于访问控制。
Since the EAP-TLS server is typically connected to the Internet, it SHOULD support validating the peer certificate using RFC 3280 [RFC3280] compliant path validation, including the ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details, see Section 4.2.2.1 of [RFC3280].
由于EAP-TLS服务器通常连接到Internet，因此它应支持使用符合RFC 3280[RFC3280]的路径验证来验证对等证书，包括检索验证对等证书所需的中间证书的能力。有关详细信息，请参见[RFC3280]第4.2.2.1节。
Where the EAP-TLS server is unable to retrieve intermediate certificates, either it will need to be pre-configured with the necessary intermediate certificates to complete path validation or it will rely on the EAP-TLS peer to provide this information as part of the TLS handshake (see Section 7.4.6 of [RFC4346]).
如果EAP-TLS服务器无法检索中间证书，则需要使用必要的中间证书对其进行预配置以完成路径验证，或者它将依赖EAP-TLS对等方提供此信息，作为TLS握手的一部分（参见[RFC4346]第7.4.6节）。
In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore, the EAP-TLS server SHOULD provide its entire certificate chain minus the root to facilitate certificate validation by the peer. The EAP-TLS peer SHOULD support validating the server certificate using RFC 3280 [RFC3280] compliant path validation.
与EAP-TLS服务器不同，EAP-TLS对等方可能没有Internet连接。因此，EAP-TLS服务器应提供其整个证书链减去根，以便于对等方进行证书验证。EAP-TLS对等方应支持使用符合RFC 3280[RFC3280]的路径验证验证服务器证书。
Once a TLS session is established, EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS. The authorization process makes use of the contents of the certificates as well as other contextual information. While authorization requirements will vary from deployment to deployment, it is RECOMMENDED that implementations be able to authorize based on the EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2.
一旦建立了TLS会话，EAP-TLS对等和服务器实现必须验证证书中表示的身份是否适当，并授权与EAP-TLS一起使用。授权过程利用证书的内容以及其他上下文信息。虽然授权要求因部署而异，但建议实施能够根据第5.2节所述确定的EAP-TLS对等Id和服务器Id进行授权。
In the case of the EAP-TLS peer, this involves ensuring that the certificate presented by the EAP-TLS server was intended to be used as a server certificate. Implementations SHOULD use the Extended Key Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that at least one of the following is true:
对于EAP-TLS对等机，这涉及确保EAP-TLS服务器提供的证书用作服务器证书。实施应使用扩展密钥用法（见[RFC3280]第4.2.1.13节）扩展，并确保以下至少一项为真：
1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see Section 4.2.1.13 of [RFC3280]). 3) The issuer included the id-kp-serverAuth identifier in the certificate (see Section 4.2.1.13 [RFC3280]).
1) 证书颁发者未在证书中包含扩展密钥使用标识符。2） 发卡机构在证书中包含anyExtendedKeyUsage标识符（参见[RFC3280]第4.2.1.13节）。3） 发卡机构在证书中包含id kp serverAuth标识符（请参阅第4.2.1.13节[RFC3280]）。
When performing this comparison, implementations MUST follow the validation rules specified in Section 3.1 of [RFC2818]. In the case of the server, this involves ensuring the certificate presented by the EAP-TLS peer was intended to be used as a client certificate. Implementations SHOULD use the Extended Key Usage (see Section 4.2.1.13 [RFC3280]) extension and ensure that at least one of the following is true:
执行此比较时，实现必须遵循[RFC2818]第3.1节中规定的验证规则。对于服务器，这涉及到确保EAP-TLS对等方提供的证书用作客户端证书。实施应使用扩展密钥使用（见第4.2.1.13节[RFC3280]）扩展，并确保至少满足以下一项：
1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see Section 4.2.1.13 of [RFC3280]). 3) The issuer included the id-kp-clientAuth identifier in the certificate (see Section 4.2.1.13 of [RFC3280]).
1) 证书颁发者未在证书中包含扩展密钥使用标识符。2） 发卡机构在证书中包含anyExtendedKeyUsage标识符（参见[RFC3280]第4.2.1.13节）。3） 发卡机构在证书中包含id kp clientAuth标识符（见[RFC3280]第4.2.1.13节）。
Certificates are long-lived assertions of identity. Therefore, it is important for EAP-TLS implementations to be capable of checking whether these assertions have been revoked.
证书是身份的长期断言。因此，EAP-TLS实现必须能够检查这些断言是否已被撤销。
EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs); for details, see Section 3.3 of [RFC3280]. EAP-TLS peer and server implementations SHOULD also support the Online Certificate Status Protocol (OCSP), described in "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" [RFC2560]. OCSP messages are typically much smaller than CRLs, which can shorten connection times especially in bandwidth-constrained environments. While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes.
EAP-TLS对等和服务器实现必须支持证书撤销列表（CRL）的使用；有关详细信息，请参见[RFC3280]第3.3节。EAP-TLS对等和服务器实现还应支持在线证书状态协议（OCSP），如“X.509 Internet公钥基础设施在线证书状态协议-OCSP”[RFC2560]所述。OCSP消息通常比CRL小得多，这可以缩短连接时间，特别是在带宽受限的环境中。虽然EAP-TLS服务器通常在EAP对话期间连接到Internet，但在身份验证完成之前，EAP-TLS对等方可能没有Internet连接。
In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation.
在对等方使用PPTP[RFC2637]或L2TP[RFC2661]发起自愿性第2层隧道的情况下，对等方通常已经在隧道发起时建立了PPP接口和互联网连接。
However, in the case where the EAP-TLS peer is attempting to obtain network access, it will not have network connectivity and is therefore not capable of checking for certificate revocation until after authentication completes and network connectivity is available. For this reason, EAP-TLS peers and servers SHOULD implement Certificate Status Request messages, as described in "Transport Layer Security (TLS) Extensions", Section 3.6 of [RFC4366]. To enable revocation checking in situations where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default.
但是，在EAP-TLS对等方试图获得网络访问的情况下，它将不具有网络连接，因此在身份验证完成且网络连接可用之前无法检查证书吊销。因此，EAP-TLS对等方和服务器应实现证书状态请求消息，如[RFC4366]第3.6节“传输层安全（TLS）扩展”中所述。若要在服务器不支持证书状态请求消息且在身份验证完成之前网络连接不可用的情况下启用吊销检查，对等实现还必须支持在身份验证完成且网络连接可用后检查证书吊销，默认情况下，他们应该利用这种能力。
The integrity protection of EAP-TLS packets does not extend to the EAP header fields (Code, Identifier, Length) or the Type or Flags fields. As a result, these fields can be modified by an attacker.
EAP-TLS数据包的完整性保护不扩展到EAP标头字段（代码、标识符、长度）或类型或标志字段。因此，攻击者可以修改这些字段。
In most cases, modification of the Code or Identifier fields will only result in a denial-of-service attack. However, an attacker can add additional data to an EAP-TLS packet so as to cause it to be longer than implied by the Length field. EAP peers, authenticators, or servers that do not check for this could be vulnerable to a buffer overrun.
在大多数情况下，修改代码或标识符字段只会导致拒绝服务攻击。但是，攻击者可以向EAP-TLS数据包添加额外数据，从而使其长度超过长度字段所暗示的长度。未对此进行检查的EAP对等方、身份验证方或服务器可能容易发生缓冲区溢出。
It is also possible for an attacker to modify the Type or Flags fields. By modifying the Type field, an attacker could cause one TLS-based EAP method to be negotiated instead of another. For example, the EAP-TLS Type field (13) could be changed to indicate another TLS-based EAP method. Unless the alternative TLS-based EAP method utilizes a different key derivation formula, it is possible that an EAP method conversation altered by a man-in-the-middle could run all the way to completion without detection. Unless the ciphersuite selection policies are identical for all TLS-based EAP methods utilizing the same key derivation formula, it may be possible for an attacker to mount a successful downgrade attack, causing the peer to utilize an inferior ciphersuite or TLS-based EAP method.
攻击者还可能修改类型或标志字段。通过修改类型字段，攻击者可以导致协商一个基于TLS的EAP方法，而不是另一个。例如，EAP-TLS类型字段（13）可以更改为指示另一种基于TLS的EAP方法。除非替代的基于TLS的EAP方法使用不同的密钥推导公式，否则中间人更改的EAP方法会话可能会一直运行到完成，而不会被检测到。除非所有使用相同密钥派生公式的基于TLS的EAP方法的密码套件选择策略相同，否则攻击者可能会成功发起降级攻击，从而导致对等方使用劣等密码套件或基于TLS的EAP方法。
[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月。
[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月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[RFC3268]Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[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月。
[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月。
[IEEE-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.
[IEEE-802.1X]电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X-2004，2004年12月。
[IEEE-802.11] 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 Std. 802.11-2007, 2007.
[IEEE-802.11]信息技术-系统间电信和信息交换-局域网和城域网-特定要求第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范，IEEE标准802.11-2007，2007。
[IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks: Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems: Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operations in Licensed Bands", IEEE 802.16e, August 2005.
[IEEE-802.16e]电气和电子工程师协会，“局域网和城域网的IEEE标准：第16部分：固定和移动宽带无线接入系统的空中接口：许可频带内固定和移动组合操作的物理和介质接入控制层的修订”，IEEE 802.16e，2005年8月。
[He] He, C., Sundararajan, M., Datta, A., Derek, A. and J. Mitchell, "A Modular Correctness Proof of IEEE 802.11i and TLS", CCS '05, November 7-11, 2005, Alexandria, Virginia, USA
[He]He，C.，Sundararajan，M.，Datta，A.，Derek，A.和J.Mitchell，“IEEE 802.11i和TLS的模块正确性证明”，CCS'05，2005年11月7-11日，美国弗吉尼亚州亚历山大市
[KEYFRAME] Aboba, B., Simon, D. and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, November 2007.
[KEYFRAME]Aboba，B.，Simon，D.和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，正在进行的工作，2007年11月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.，和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716]Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[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月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[RFC4284]Adrangi，F.，Lortz，V.，Bari，F.，和P.Ernen，“可扩展身份验证协议（EAP）的身份选择提示”，RFC 4284，2006年1月。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]国家标准与技术研究所，“密钥管理建议”，特别出版物800-57，2006年5月。
[RFC4346bis] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", Work in Progress, February 2008.
[RFC4346bis]Dierks，T.和E.Rescorla，“TLS协议版本1.2”，正在进行的工作，2008年2月。
[UNAUTH] Schulzrinne. H., McCann, S., Bajko, G. and H. Tschofenig, "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Work in Progress, November 2007.
[未经授权]舒尔兹林内。H.，McCann，S.，Bajko，G.和H.Tschofenig，“处理未经认证和未经授权设备的应急服务架构扩展”，正在进行的工作，2007年11月。
Acknowledgments
致谢
Thanks to Terence Spies, Mudit Goel, Anthony Leibovitz, and Narendra Gidwani of Microsoft, Glen Zorn of NetCube, Joe Salowey of Cisco, and Pasi Eronen of Nokia for useful discussions of this problem space.
感谢特伦斯·斯皮尔斯、微软的穆迪·戈尔、安东尼·莱博维茨和纳伦德拉·吉德瓦尼、NetCube的格伦·佐恩、思科的乔·萨洛维和诺基亚的帕西·埃隆对这个问题空间进行了有益的讨论。
Appendix A -- Changes from RFC 2716
附录A——RFC 2716的变更
This appendix lists the major changes between [RFC2716] and this document. Minor changes, including style, grammar, spelling, and editorial changes, are not mentioned here.
本附录列出了[RFC2716]与本文件之间的主要变更。这里没有提到一些小的变化，包括风格、语法、拼写和编辑方面的变化。
o As EAP is now in use with a variety of lower layers, not just PPP for which it was first designed, mention of PPP is restricted to situations relating to PPP-specific behavior and reference is made to other lower layers such as IEEE 802.11, IEEE 802.16, etc.
o 由于EAP现在用于各种较低层，而不仅仅是它最初设计的PPP，因此PPP的提及仅限于与PPP特定行为相关的情况，并参考其他较低层，如IEEE 802.11、IEEE 802.16等。
o The document now cites TLS v1.1 as a normative reference (Sections 1 and 6.1).
o 本文件现在引用TLS v1.1作为规范性参考（第1节和第6.1节）。
o The terminology section has been updated to reflect definitions from [RFC3748] (Section 1.2), and the EAP Key Management Framework [KEYFRAME] (Section 1.2).
o 术语部分已更新，以反映[RFC3748]（第1.2节）和EAP密钥管理框架[KEYFRAME]（第1.2节）中的定义。
o Use for peer unauthenticated access is clarified (Section 2.1.1).
o 澄清了未经认证的对等访问的使用（第2.1.1节）。
o Privacy is supported as an optional feature (Section 2.1.4).
o 隐私作为可选功能受到支持（第2.1.4节）。
o It is no longer recommended that the identity presented in the EAP-Response/Identity be compared to the identity provided in the peer certificate (Section 2.2).
o 不再建议将EAP响应/标识中提供的标识与对等证书中提供的标识进行比较（第2.2节）。
o The EAP-TLS key hierarchy is defined, using terminology from [RFC3748]. This includes formulas for the computation of TEKs as well as the MSK, EMSK, IV, and Session-Id (Section 2.3).
o EAP-TLS密钥层次结构是使用[RFC3748]中的术语定义的。这包括TEK以及MSK、EMSK、IV和会话Id的计算公式（第2.3节）。
o Mandatory and recommended TLS ciphersuites are provided. The use of TLS ciphersuite negotiation for determining the lower layer ciphersuite is prohibited (Section 2.4).
o 提供了强制性和推荐的TLS密码套件。禁止使用TLS密码套件协商来确定下层密码套件（第2.4节）。
o The Start bit is not set within an EAP-Response packet (Section 3.2).
o EAP响应数据包中未设置起始位（第3.2节）。
o A section on security claims has been added and advice on key strength is provided (Section 5.1).
o 增加了关于安全索赔的一节，并提供了关于密钥强度的建议（第5.1节）。
o The Peer-Id and Server-Id are defined (Section 5.2), and requirements for certificate validation (Section 5.3) and revocation (Section 5.4) are provided.
o 定义了对等Id和服务器Id（第5.2节），并提供了证书验证（第5.3节）和撤销（第5.4节）的要求。
o Packet modification attacks are described (Section 5.5).
o 描述了包修改攻击（第5.5节）。
o The examples have been updated to reflect typical messages sent in the described scenarios. For example, where mutual authentication is performed, the EAP-TLS server is shown to request a client certificate and the peer is shown to provide a certificate_verify message. A privacy example is provided, and two faulty examples of session resume failure were removed.
o 这些示例已更新，以反映在所述场景中发送的典型消息。例如，在执行相互认证的情况下，显示EAP-TLS服务器请求客户端证书，显示对等方提供证书验证消息。提供了一个隐私示例，并删除了会话恢复失败的两个错误示例。
Authors' Addresses
作者地址
Dan Simon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Dan Simon微软公司华盛顿州雷德蒙微软大道一号98052-6399
Phone: +1 425 882 8080
Fax: +1 425 936 7329
EMail: dansimon@microsoft.com
Phone: +1 425 882 8080
Fax: +1 425 936 7329
EMail: dansimon@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399
Phone: +1 425 882 8080
Fax: +1 425 936 7329
EMail: rmh@microsoft.com
Phone: +1 425 882 8080
Fax: +1 425 936 7329
EMail: rmh@microsoft.com
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.