Network Working Group B. Aboba
Requests for Commments: 2716 D. Simon
Category: Experimental Microsoft
October 1999
Network Working Group B. Aboba
Requests for Commments: 2716 D. Simon
Category: Experimental Microsoft
October 1999
PPP EAP TLS Authentication Protocol
PPP-EAP-TLS认证协议
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP.
点到点协议（PPP）提供了通过点到点链路传输多协议数据报的标准方法。PPP还定义了可扩展链路控制协议（LCP），可用于协商身份验证方法，以及用于协商PPP链路上的数据加密的加密控制协议（ECP）和用于协商压缩方法的压缩控制协议（CCP）。可扩展身份验证协议（EAP）是一个PPP扩展，它支持PPP中的其他身份验证方法。
Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP.
传输级安全性（TLS）提供了相互身份验证、完整性保护的密码套件协商以及两个端点之间的密钥交换。本文档描述了EAP-TLS（包括对碎片和重组的支持）如何在EAP中提供这些TLS机制。
The Extensible Authentication Protocol (EAP), described in [5], provides a standard mechanism for support of additional authentication methods within PPP. 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. To date however, EAP methods such as [6] have focussed on authenticating a client to a server.
[5]中描述的可扩展身份验证协议（EAP）提供了一种标准机制，用于支持PPP中的其他身份验证方法。通过使用EAP，可以添加对许多身份验证方案的支持，包括智能卡、Kerberos、公钥、一次性密码等。然而，到目前为止，EAP方法（如[6]）的重点是对客户端和服务器进行身份验证。
However, it may be desirable to support mutual authentication, and since PPP encryption protocols such as [9] and [10] assume existence of a session key, it is useful to have a mechanism for session key establishment. Since design of secure key management protocols is non-trivial, it is desirable to avoid creating new mechanisms for this. The EAP protocol described in this document allows a PPP peer to take advantage of the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS protocol, described in [12].
然而，可能希望支持相互认证，并且由于诸如[9]和[10]之类的PPP加密协议假定存在会话密钥，因此具有用于会话密钥建立的机制是有用的。由于安全密钥管理协议的设计非常重要，因此需要避免为此创建新机制。本文件中描述的EAP协议允许PPP对等方利用TLS协议的受保护密码套件协商、相互认证和密钥管理功能，如[12]所述。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [11].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[11]所述。
As described in [5], 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 userId.
如[5]所述，EAP-TLS对话通常以认证者和对等协商EAP开始。然后，认证者通常将EAP请求/标识包发送给对等方，对等方将使用包含对等方的用户id的EAP响应/标识包对认证者进行响应。
From this point forward, while nominally the EAP conversation occurs between the PPP authenticator and the peer, the authenticator MAY act as a passthrough device, with the EAP packets received from the peer being encapsulated for transmission to a RADIUS server or backend security server. In the discussion that follows, we will use the term "EAP server" to denote the ultimate endpoint conversing with the peer.
从这一点开始，虽然名义上在PPP认证器和对等方之间发生EAP对话，但认证器可以充当直通设备，从对等方接收的EAP数据包被封装以传输到RADIUS服务器或后端安全服务器。在下面的讨论中，我们将使用术语“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 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.
一旦接收到对等方的身份，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压缩。此当前密码规范保持不变，直到change_cipher_spec消息表明后续记录将具有握手剩余部分的协商属性。
The client_hello message contains the client's TLS version number, a sessionId, a random number, and a set of ciphersuites supported by the client. The version offered by the client 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 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.
然后，EAP服务器将使用EAP Type=EAP-TLS的EAP请求数据包进行响应。此数据包的数据字段将封装一个或多个TLS记录。这些将包含TLS服务器hello握手消息，可能后跟TLS证书、服务器密钥交换、证书请求、服务器hello完成和/或完成握手消息和/或TLS更改密码规范消息。服务器hello握手消息包含一个TLS版本号、另一个随机数、一个会话ID和一个密码套件。服务器提供的版本必须对应于TLS v1.0或更高版本。
If the client'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 client, indicating a resumption of the previously established session with that sessionID. The server will also choose a ciphersuite from those offered by the client; if the session matches the client's, then the ciphersuite MUST match the one negotiated during the handshake protocol execution that established the session.
如果客户端的sessionId为null或服务器无法识别，则服务器必须选择sessionId以建立新会话；否则，sessionId将与客户端提供的会话ID相匹配，表示使用该sessionId恢复先前建立的会话。服务器还将从客户端提供的密码套件中选择密码套件；如果会话与客户端的会话匹配，则密码套件必须与建立会话的握手协议执行期间协商的密码套件匹配。
The purpose of the sessionId within the TLS protocol is to allow for improved efficiency in the case where a client 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 may also have application to PPP authentication (e.g. multilink).
TLS协议中sessionId的目的是在客户机在短时间内反复尝试向EAP服务器进行身份验证的情况下提高效率。虽然此模型是为与HTTP身份验证一起使用而开发的，但它也可以应用于PPP身份验证（例如多链路）。
As a result, 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 whether to choose a new session.
因此，由对等方决定是否尝试继续上一个会话，从而缩短TLS对话。通常，对等方的决定将基于自上次尝试对该EAP服务器进行身份验证以来经过的时间。根据对等方选择的会话ID以及自上次身份验证以来经过的时间，EAP服务器将决定是允许继续，还是选择新会话。
In the case where the EAP server and authenticator reside on the same device, then client will only be able to continue sessions when connecting to the same NAS or tunnel server. Should these devices be set up in a rotary or round-robin then it may not be possible for the peer to know in advance the authenticator it will be connecting to, 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 NAS devices and tunnel servers will remote their EAP authentications to the same RADIUS server.
如果EAP服务器和验证器位于同一设备上，则客户端只能在连接到同一NAS或隧道服务器时继续会话。如果这些设备是以循环或循环方式设置的，则对等方可能无法提前知道它将连接到的验证器，因此无法知道要尝试重用的会话ID。因此，继续尝试很可能会失败。在EAP身份验证是远程的情况下，继续更可能成功，因为多个NAS设备和隧道服务器将其EAP身份验证远程到同一RADIUS服务器。
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. 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 change_cipher_spec消息和服务器hello消息后的TLS FINATED handshake消息。完成的消息包含EAP服务器对对等方的身份验证响应。如果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 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 client to authenticate itself via public key. While the EAP server SHOULD require client authentication, this is not a requirement, since it may be possible that the server will require that the peer authenticate via some other means.
当服务器希望客户端通过公钥进行自身身份验证时，会包含证书请求消息。虽然EAP服务器应要求客户端身份验证，但这不是一项要求，因为服务器可能会要求对等方通过其他方式进行身份验证。
The peer MUST respond to the EAP-Request with an EAP-Response packet of EAP-Type=EAP-TLS. The data field of this packet will encapsulate one or more TLS records containing a TLS change_cipher_spec message and finished handshake message, and possibly certificate, certificate_verify and/or client_key_exchange handshake messages. 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-TLS的EAP响应数据包响应EAP请求。此数据包的数据字段将封装一个或多个TLS记录，其中包含TLS更改\密码\规格消息和完成的握手消息，以及可能的证书、证书\验证和/或客户端\密钥\交换握手消息。如果EAP服务器在前一EAP请求数据包中发送的前一服务器\u hello消息指示前一会话的恢复，则对等方必须仅发送更改\u密码\u规范和完成的握手消息。完成的消息包含对等方对EAP服务器的身份验证响应。
If the preceding server_hello message sent by the EAP server in the preceeding EAP-Request packet did not indicate the resumption of a previous session, then the peer MUST send, in addition to the change_cipher_spec and finished messages, a client_key_exchange message, which completes the exchange of a shared master secret between the peer and the EAP server. If the EAP server sent a certificate_request message in the preceding EAP-Request packet, then the peer MUST send, in addition, certificate and certificate_verify handshake 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 this packet, the EAP server will verify the peer's certificate and digital signature, if requested.
如果EAP服务器在前一个EAP请求数据包中发送的前一个服务器\u hello消息未指示前一个会话的恢复，则除了更改\u密码\u规范和完成的消息外，对等方还必须发送客户端\u密钥\u交换消息，完成对等方和EAP服务器之间共享主密钥的交换。如果EAP服务器在前面的EAP请求数据包中发送了证书请求消息，则对等方还必须发送证书和证书验证握手消息。前者包含对等方签名公钥的证书，而后者包含对等方对EAP服务器的签名认证响应。在收到此数据包后，EAP服务器将根据请求验证对等方的证书和数字签名。
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 rather immediately terminating the conversation so as to allow the peer to inform the user of 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 limit on the number of restarts, so as to protect against denial of service attacks.
为确保对等方收到TLS警报消息，EAP服务器必须等待对等方使用EAP响应数据包进行回复。对等方发送的EAP响应包可以封装TLS客户端\u hello握手消息，在这种情况下，EAP服务器可以允许重新启动EAP-TLS会话，或者它可以包含EAP类型=EAP-TLS且无数据的EAP响应包，在这种情况下，EAP服务器必须发送EAP故障包并终止会话。是否允许重启取决于EAP服务器，如果允许重启，则取决于会话可以重启多少次。实现重启功能的EAP服务器应限制重启次数，以防止拒绝服务攻击。
If the peers 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 handshke messages. The latter contains the EAP server's authentication response to the peer. The peer will then verify the hash in order to authenticate the EAP server.
如果对等方验证成功，EAP服务器必须使用EAP Type=EAP-TLS的EAP请求数据包进行响应，在新TLS会话的情况下，该数据包包括一个或多个包含TLS change\u cipher\u spec和已完成的handshke消息的TLS记录。后者包含EAP服务器对对等方的身份验证响应。然后，对等方将验证哈希，以便对EAP服务器进行身份验证。
If the EAP server authenticates unsuccessfully, 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服务器身份验证失败，则对等方可发送EAP Type=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成功消息。
As with other EAP protocols, the EAP server is responsible for retry behavior. This means that if the EAP server does not receive a reply from the peer, it MUST resend the EAP-Request for which it has not yet received an EAP-Response. However, the peer MUST NOT resend EAP-Response packets without first being prompted by the EAP server.
与其他EAP协议一样，EAP服务器负责重试行为。这意味着，如果EAP服务器未收到来自对等方的回复，则必须重新发送尚未收到EAP响应的EAP请求。但是，未经EAP服务器提示，对等方不得重新发送EAP响应数据包。
For example, if the initial EAP-TLS start packet sent by the EAP server were to be lost, then the peer would not receive this packet, and would not respond to it. As a result, the EAP-TLS start packet would be resent by the EAP server. Once the peer received the EAP-TLS start packet, it would send an EAP-Response encapsulating the client_hello message. If the EAP-Response were to be lost, then the EAP server would resend the initial EAP-TLS start, and the peer would resend the EAP-Response.
例如，如果EAP服务器发送的初始EAP-TLS起始数据包丢失，则对等方将不会收到该数据包，也不会对其作出响应。因此，EAP服务器将重新发送EAP-TLS起始数据包。一旦对等方收到EAP-TLS启动数据包，它将发送一个封装客户机hello消息的EAP响应。如果EAP响应丢失，则EAP服务器将重新发送初始EAP-TLS启动，对等方将重新发送EAP响应。
As a result, it is possible that a peer will receive duplicate EAP-Request messages, and may send duplicate EAP-Responses. Both the peer and the EAP-Server should be engineered to handle this possibility.
因此，对等方可能会收到重复的EAP请求消息，并可能发送重复的EAP响应。对等服务器和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 16MB. The group of EAP-TLS messages sent in a single round may thus be larger than the PPP MTU size, the maximum RADIUS packet size of 4096 octets, or even the Multilink Maximum Received Reconstructed Unit (MRRU). As described in [2], the multilink MRRU is negotiated via the Multilink MRRU LCP option, which includes an MRRU length field of two octets, and thus can support MRRUs as large as 64 KB.
单个TLS记录的长度可能高达16384个八位字节，但TLS消息可能跨越多个TLS记录，原则上TLS证书消息的长度可能长达16MB。因此，在单轮中发送的EAP-TLS消息组可能大于PPP MTU大小、4096个八位字节的最大RADIUS数据包大小，甚至大于多链路最大接收重构单元（MRRU）。如[2]所述，多链路MRRU通过多链路MRRU LCP选项协商，该选项包括两个八位字节的MRRU长度字段，因此可以支持64 KB的MRRU。
However, note that 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 typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anwhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB.
然而，请注意，为了防止重组锁定和拒绝服务攻击，实现可能需要为一组这样的TLS消息设置最大大小。由于一个典型的证书链的长度很少超过几千个八位字节，并且没有其他字段的长度可能接近于几千个八位字节，因此可以合理选择的最大可接受消息长度可能是64 KB。
If this value is chosen, then fragmentation can be handled via the multilink PPP fragmentation mechanisms described in [2]. While this is desirable, there may be cases in which multilink or the MRRU LCP option cannot be negotiated. As a result, an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly.
如果选择此值，则可以通过[2]中描述的多链路PPP分段机制处理分段。虽然这是可取的，但在某些情况下，可能无法协商multilink或MRRU LCP选项。因此，EAP-TLS实现必须为碎片和重组提供自己的支持。
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-Reponse. 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 use 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-Reponse.
类似地，当EAP服务器接收到设置为M位的EAP响应时，它必须使用EAP Type=EAP-TLS且无数据的EAP请求进行响应。这是一个片段。EAP对等方必须等到收到EAP请求后再发送另一个片段。为了防止片段处理中出现错误，EAP服务器必须为EAP请求中包含的每个片段ACK使用增量标识符值，并且对等方必须在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.
作为TLS协商的一部分，服务器向对等方提供证书，如果请求相互身份验证，对等方向服务器提供证书。
Note that since the peer has made a claim of identity in the EAP-Response/Identity (MyID) packet, the EAP server SHOULD verify that the claimed identity corresponds to the certificate presented by the
请注意，由于对等方已在EAP响应/标识（MyID）数据包中声明身份，EAP服务器应验证声明的身份是否与对等方提供的证书相对应
peer. Typically this will be accomplished either by placing the userId within the peer certificate, or by providing a mapping between the peer certificate and the userId using a directory service.
同龄人通常，这可以通过将userId放置在对等证书中，或者通过使用目录服务提供对等证书和userId之间的映射来实现。
Similarly, the peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, in order to determine whether the EAP server can be trusted. Please note that in the case where the EAP authentication is remoted that the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended destination and whether the EAP server exists within a target sub-domain.
同样，对等方必须验证EAP服务器证书的有效性，并且还应该检查证书中显示的EAP服务器名称，以确定EAP服务器是否可以信任。请注意，如果EAP身份验证是远程的，则EAP服务器将不会与身份验证程序驻留在同一台计算机上，因此EAP服务器证书中的名称不能与预期目标的名称匹配。在这种情况下，更合适的测试可能是EAP服务器的证书是否由控制目标的CA签名，以及EAP服务器是否存在于目标子域中。
Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, "client EAP encryption", random) is computed up to 128 bytes, and the value PRF("", "client EAP encryption", random) is computed up to 64 bytes (where "" is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. TheEAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server
由于正常TLS密钥用于握手，因此不应在不同的上下文中使用，因此必须从TLS主密钥派生新的加密密钥，以便与PPP加密一起使用。对于对等服务器和EAP服务器，推导过程如下：给定TLS握手协商的主密钥，在使用的TLS版本规范中定义的伪随机函数（PRF），以及定义为握手消息字段client_hello.random和server_hello.random串联的值random（按照该顺序），值PRF（主密钥，“客户端EAP加密”，随机）最多可计算128字节，值PRF（“客户端EAP加密”，随机）最多可计算64字节（其中“”为空字符串）。对等加密密钥（用于从对等到EAP服务器加密数据的密钥）通过将这两个输出字符串中第一个PRF的前32字节截断为正确长度来获取。EAP服务器加密密钥（用于将数据从EAP服务器加密到对等服务器的密钥），如果与客户端加密密钥不同，则通过将同一PRF输出字符串的第二个32字节截断为正确长度来获取。客户端身份验证密钥（用于计算对等到EAP服务器的消息的MAC的密钥），如果使用，则通过将同一PRF输出字符串的第三个32字节截断为正确长度来获得。EAP服务器身份验证密钥（用于计算从EAP服务器到对等方的消息的MAC的密钥），如果使用，并且与对等身份验证密钥不同，则通过将该相同PRF输出字符串的第四个32字节截断为正确长度来获得。对等初始化向量（IV），如果指定了分组密码，则用于来自对等EAP服务器的消息，通过将上述第二个PRF输出字符串的前32字节截断为密码的块大小来获得。最后，用于来自对等EAP服务器的消息的服务器初始化向量（IV）
if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output.
如果指定了分组密码，则通过将第二个PRF输出的第二个32字节截断为密码的块大小来获得。
The use of these encryption and authentication keys is specific to the PPP encryption mechanism used, such as those defined in [9] and [10]. Additional keys or other non-secret values (such as IVs) can be obtained as needed for future PPP encryption methods by extending the outputs of the PRF beyond 128 bytes and 64 bytes, respectively.
这些加密和身份验证密钥的使用特定于所使用的PPP加密机制，如[9]和[10]中定义的机制。通过将PRF的输出分别扩展到128字节和64字节之外，可以根据未来PPP加密方法的需要获得额外的密钥或其他非秘密值（如IVs）。
Since TLS supports ciphersuite negotiation, peers completing the TLS negotiation will also have selected a ciphersuite, which includes key strength, encryption and hashing methods. As a result, a subsequent Encryption Control Protocol (ECP) conversation, if it occurs, has a predetermined result.
由于TLS支持密码套件协商，完成TLS协商的对等方还将选择一个密码套件，其中包括密钥强度、加密和哈希方法。结果，后续的加密控制协议（ECP）对话（如果发生）具有预定结果。
In order to ensure agreement between the EAP-TLS ciphersuite negotiation and the subsequent ECP negotiation (described in [6]), during ECP negotiation the PPP peer MUST offer only the ciphersuite negotiated inEAP-TLS. This ensures that the PPP authenticator MUST accept the EAP-TLS negotiated ciphersuite in order for the onversation to proceed. Should the authenticator not accept the EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP terminate and disconnect.
为了确保EAP-TLS密码套件协商与后续ECP协商（如[6]所述）之间达成一致，在ECP协商期间，PPP对等方必须仅提供在AP TLS中协商的密码套件。这确保PPP认证机构必须接受EAP-TLS协商密码套件，以便继续对话。如果认证方不接受EAP-TLS协商密码套件，则对等方必须发送LCP终止并断开连接。
Please note that it cannot be assumed that the PPP authenticator and EAP server are located on the same machine or that the authenticator understands the EAP-TLS conversation that has passed through it. Thus if the peer offers a ciphersuite other than the one negotiated in EAP-TLS there is no way for the authenticator to know how to respond correctly.
请注意，不能假设PPP认证器和EAP服务器位于同一台机器上，或者认证器理解通过它的EAP-TLS对话。因此，如果对等方提供的密码套件不是EAP-TLS中协商的密码套件，则认证者无法知道如何正确响应。
TLS as described in [12] supports compression as well as ciphersuite negotiation. However, TLS only provides support for a limited number of compression types which do not overlap with the compression types used in PPP. As a result, during the EAP-TLS conversation the EAP endpoints MUST NOT request or negotiate compression. Instead, the PPP Compression Control Protocol (CCP), described in [13] should be used to negotiate the desired compression scheme.
[12]中描述的TLS支持压缩和密码套件协商。但是，TLS只支持有限数量的压缩类型，这些压缩类型与PPP中使用的压缩类型不重叠。因此，在EAP-TLS会话期间，EAP端点不得请求或协商压缩。相反，应使用[13]中描述的PPP压缩控制协议（CCP）协商所需的压缩方案。
In the case where the EAP-TLS mutual authentication is successful, the conversation will appear as follows:
在EAP-TLS相互认证成功的情况下，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
ECP negotiation CCP negotiation
ECP谈判CCP谈判
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
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP 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)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS inished)(Fragment 1:
L, M bits set)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP 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)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS inished)(Fragment 1:
L, M bits set)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/ EAP-Type=EAP-TLS (Fragment 2)-> <- PPP EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) PPP EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
PPP EAP响应/EAP类型=EAP-TLS（片段2）-><-PPP EAP请求/EAP类型=EAP-TLS（TLS更改\u密码\u规范，TLS完成）PPP EAP响应/EAP类型=EAP-TLS-><-PPP EAP成功PPP认证阶段完成，NCP阶段开始
ECP negotiation CCP negotiation
ECP谈判CCP谈判
In the case where the server authenticates to the client successfully, but the client fails to authenticate to the server, the conversation will appear as follows:
如果服务器成功向客户端进行身份验证，但客户端未能向服务器进行身份验证，则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- PPP EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) PPP EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Request EAP-Type=EAP-TLS (TLS Alert message) PPP EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Failure (User Disconnected)
TLS证书验证、TLS更改、密码规范、TLS完成）-><-PPP EAP请求/EAP类型=EAP-TLS（TLS更改、密码规范、TLS完成）PPP EAP响应/EAP类型=EAP-TLS-><-PPP EAP请求EAP类型=EAP-TLS（TLS警报消息）PPP EAP响应/EAP类型=EAP-TLS-><-PPP EAP故障（用户断开连接）
In the case where server authentication is unsuccessful, the conversation will appear as follows:
如果服务器身份验证失败，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec, TLS finished) -> <- PPP EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) PPP EAP-Response/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) <- PPP EAP-Request/ EAP-Type=EAP-TLS PPP EAP-Response/ EAP-Type=EAP-TLS (TLS Alert message) -> <- PPP EAP-Failure (User Disconnected)
TLS更改\密码规范，TLS完成）-><-PPP EAP请求/EAP类型=EAP-TLS（TLS更改\密码规范，TLS完成）PPP EAP响应/EAP类型=EAP-TLS（TLS更改\密码规范，TLS完成）<-PPP EAP请求/EAP类型=EAP-TLS PPP EAP响应/EAP类型=EAP-TLS（TLS警报消息）->-PPP 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
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
PPP EAP-Response/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) -> <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
PPP EAP响应/EAP类型=EAP-TLS（TLS更改\u密码\u规范，TLS完成）-><-PPP EAP成功PPP认证阶段完成，NCP阶段开始
ECP negotiation
ECP谈判
CCP negotiation
中共谈判
In the case where a previously established session is being resumed, and the server authenticates to the client successfully but the client fails to authenticate to the server, the conversation will appear as follows:
如果恢复先前建立的会话，并且服务器成功向客户端进行身份验证，但客户端未能向服务器进行身份验证，则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EA-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EA-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
PPP EAP-Response EAP-Type=EAP-TLS -> <- PPP EAP-Failure (User Disconnected)
PPP EAP响应EAP类型=EAP-TLS-><-PPP EAP故障（用户断开连接）
In the case where a previously established session is being resumed, and the server authentication is unsuccessful, the conversation will appear as follows:
如果恢复先前建立的会话，并且服务器身份验证失败，则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- PPP EAP-Failure
(User Disconnected)
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- PPP EAP-Failure
(User Disconnected)
A summary of the PPP EAP TLS Request/Response packet format is shown below. The fields are transmitted from left to right.
PPP 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 | 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 | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
1 - Request 2 - Response
1-请求2-响应
Identifier
标识符
The identifier field is one octet and aids in matching responses with requests.
标识符字段是一个八位字节，有助于将响应与请求匹配。
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 should be ignored on reception.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时应忽略。
Type
类型
13 - EAP TLS
13-EAP TLS
Data
数据
The format of the Data field is determined by the Code field.
数据字段的格式由代码字段决定。
A summary of the PPP EAP TLS Request packet format is shown below. The fields are transmitted from left to right.
PPP 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 TLS Response fields.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和TLS响应字段。
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 acknowledgement.
设置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 PPP EAP TLS Response packet format is shown below. The fields are transmitted from left to right.
PPP 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, Identifir, Length, Type, and TLS data fields.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和TLS数据字段。
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 acknowledgement.
设置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数据包组成。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[2] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[3] 辛普森，W.，编辑，“PPP LCP扩展”，RFC 15701994年1月。
[4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[4] Rivest，R.和S.Dusse，“MD5消息摘要算法”，RFC 13211992年4月。
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5] Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[6] Meyer，G.，“PPP加密协议（ECP）”，RFC 1968，1996年6月。
[7] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977).
[7] 国家标准局，“数据加密标准”，FIPS PUB 46（1977年1月）。
[8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980).
[8] 国家标准局，“DES运行模式”，FIPS PUB 81（1980年12月）。
[9] Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[9] Sklower，K.amd G.Meyer，“PPP DES加密协议，第2版（DESE bis）”，RFC 2419，1998年9月。
[10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[10] Hummert，K.，“PPP三重DES加密协议（3DESE）”，RFC2420，1998年9月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[12] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1998年11月。
[13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June 1996.
[13] Rand，D.，“PPP压缩控制协议”，RFC 1962，1996年6月。
Since the EAP server is on the Internet during the EAP conversation, the server is capable of following a certificate chain or verifying whether the peer's certificate has been revoked. In contrast, the peer may or may not have Internet connectivity, and thus while it can validate the EAP server's certificate based on a pre-configured set of CAs, it may not be able to follow a certificate chain or verify whether the EAP server's certificate has been revoked.
由于EAP服务器在EAP会话期间位于Internet上，因此服务器能够跟踪证书链或验证对等方的证书是否已被吊销。相反，对等方可能具有或不具有互联网连接，因此，尽管它可以基于预先配置的CA集验证EAP服务器的证书，但它可能无法遵循证书链或验证EAP服务器的证书是否已被吊销。
In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP or L2TP, the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. As a result, during the EAP conversation it is capable of checking for certificate revocation.
在对等方正在使用PPTP或L2TP发起自愿性第2层隧道的情况下，对等方通常已经在隧道发起时建立了PPP接口和因特网连接。因此，在EAP会话期间，它能够检查证书吊销。
However, in the case where the peer is initiating an intial PPP conversation, it will not have Internet connectivity and is therefore not capable of checking for certificate revocation until after NCP negotiation completes and the peer has access to the Internet. In this case, the peer SHOULD check for certificate revocation after connecting to the Internet.
但是，在对等方发起初始PPP对话的情况下，它将不具有Internet连接，因此在NCP协商完成且对等方可以访问Internet之前，无法检查证书吊销。在这种情况下，对等方应在连接到Internet后检查证书吊销。
As a result of the EAP-TLS conversation, the EAP endpoints will mutually authenticate, negotiate a ciphersuite, and derive a session key for subsequent use in PPP encryption. Since the peer and EAP client reside on the same machine, it is necessary for the EAP client module to pass the session key to the PPP encryption module.
作为EAP-TLS对话的结果，EAP端点将相互验证、协商密码套件，并导出会话密钥，以便后续在PPP加密中使用。由于对等机和EAP客户端位于同一台机器上，因此EAP客户端模块需要将会话密钥传递给PPP加密模块。
The situation may be more complex on the PPP authenticator, which may or may not reside on the same machine as the EAP server. In the case where the EAP server and PPP authenticator reside on different machines, there are several implications for security. Firstly, the mutual authentication defined in EAP-TLS will occur between the peer and the EAP server, not between the peer and the authenticator. This means that as a result of the EAP-TLS conversation, it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to.
PPP验证器上的情况可能更复杂，它可能与EAP服务器驻留在同一台机器上，也可能不驻留在同一台机器上。在EAP服务器和PPP验证器驻留在不同机器上的情况下，存在几个安全问题。首先，EAP-TLS中定义的相互身份验证将发生在对等方和EAP服务器之间，而不是对等方和身份验证器之间。这意味着，作为EAP-TLS对话的结果，对等方不可能验证与之对话的NAS或隧道服务器的身份。
The second issue is that the session key negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the session key from the EAP server to the authenticator or tunnel server that needs to use the key. The specification of this transit mechanism is
第二个问题是，对等服务器和EAP服务器之间协商的会话密钥将需要传输到身份验证器。因此，需要提供一种机制，将会话密钥从EAP服务器传输到需要使用密钥的验证器或隧道服务器。该传输机制的规格如下所示
outside the scope of this document.
超出本文件的范围。
It is envisaged that EAP-TLS will be used primarily with dialup PPP connections. However, there are also circumstances in which PPP encryption may be used along with Layer 2 tunneling protocols such as PPTP and L2TP.
预计EAP-TLS将主要用于拨号PPP连接。然而，也存在PPP加密可与第2层隧道协议（如PPTP和L2TP）一起使用的情况。
In compulsory layer 2 tunneling, a PPP peer makes a connection to a NAS or router which tunnels the PPP packets to a tunnel server. Since with compulsory tunneling a PPP peer cannot tell whether its packets are being tunneled, let alone whether the network device is securing the tunnel, if security is required then the client must make its own arrangements. In the case where all endpoints cannot be relied upon to implement IPSEC, TLS, or another suitable security protocol, PPP encryption provides a convenient means to ensure the privacy of packets transiting between the client and the tunnel server.
在强制第2层隧道中，PPP对等方连接到NAS或路由器，后者将PPP数据包隧道到隧道服务器。由于使用强制隧道，PPP对等方无法判断其数据包是否正在隧道中，更不用说网络设备是否正在保护隧道，因此如果需要安全性，则客户端必须自行安排。在无法依靠所有端点来实现IPSEC、TLS或其他合适的安全协议的情况下，PPP加密提供了一种方便的方法来确保在客户端和隧道服务器之间传输的数据包的隐私。
Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space.
感谢特伦斯间谍、微软的格伦·佐恩（Glen Zorn）和纳伦德拉·吉德瓦尼（Narendra Gidwani）对这个问题空间的有益讨论。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
电话：425-936-6605电子邮件：bernarda@microsoft.com
Dan Simon Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dan Simon微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: 425-936-6711 EMail: dansimon@microsoft.com
电话：425-936-6711电子邮件：dansimon@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。