Network Working Group L. Blunk
Request for Comments: 2284 J. Vollbrecht
Category: Standards Track Merit Network, Inc.
March 1998
Network Working Group L. Blunk
Request for Comments: 2284 J. Vollbrecht
Category: Standards Track Merit Network, Inc.
March 1998
PPP Extensible Authentication Protocol (EAP)
PPP可扩展身份验证协议（EAP）
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法。
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
PPP还定义了一个可扩展的链路控制协议，该协议允许在允许网络层协议通过链路传输之前协商用于认证其对等方的认证协议。
This document defines the PPP Extensible Authentication Protocol.
本文档定义了PPP可扩展身份验证协议。
Table of Contents
目录
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 2
2. PPP Extensible Authentication Protocol (EAP) .......... 3
2.1 Configuration Option Format ..................... 4
2.2 Packet Format ................................... 6
2.2.1 Request and Response ............................ 6
2.2.2 Success and Failure ............................. 7
3. Initial EAP Request/Response Types .................... 8
3.1 Identity ........................................ 9
3.2 Notification .................................... 10
3.3 Nak ............................................. 10
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 2
2. PPP Extensible Authentication Protocol (EAP) .......... 3
2.1 Configuration Option Format ..................... 4
2.2 Packet Format ................................... 6
2.2.1 Request and Response ............................ 6
2.2.2 Success and Failure ............................. 7
3. Initial EAP Request/Response Types .................... 8
3.1 Identity ........................................ 9
3.2 Notification .................................... 10
3.3 Nak ............................................. 10
3.4 MD5-Challenge ................................... 11
3.5 One-Time Password (OTP) ......................... 11
3.6 Generic Token Card .............................. 12
REFERENCES ................................................... 13
ACKNOWLEDGEMENTS ............................................. 14
CHAIR'S ADDRESS .............................................. 14
AUTHORS' ADDRESSES ........................................... 14
Full Copyright Statement ..................................... 15
3.4 MD5-Challenge ................................... 11
3.5 One-Time Password (OTP) ......................... 11
3.6 Generic Token Card .............................. 12
REFERENCES ................................................... 13
ACKNOWLEDGEMENTS ............................................. 14
CHAIR'S ADDRESS .............................................. 14
AUTHORS' ADDRESSES ........................................... 14
Full Copyright Statement ..................................... 15
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase.
为了通过点到点链路建立通信，PPP链路的每一端必须首先发送LCP数据包，以便在链路建立阶段配置数据链路。链路建立后，PPP在进入网络层协议阶段之前提供可选的身份验证阶段。
By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.
默认情况下，身份验证不是强制性的。如果需要对链路进行身份验证，则实现必须在链路建立阶段指定身份验证协议配置选项。
These authentication protocols are intended for use primarily by hosts and routers that connect to a PPP network server via switched circuits or dial-up lines, but might be applied to dedicated links as well. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations.
这些认证协议主要用于通过交换电路或拨号线路连接到PPP网络服务器的主机和路由器，但也可以应用于专用链路。服务器可以在选择网络层协商选项时使用连接主机或路由器的标识。
This document defines the PPP Extensible Authentication Protocol (EAP). The Link Establishment and Authentication phases, and the Authentication-Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [1].
本文档定义了PPP可扩展身份验证协议（EAP）。链路建立和认证阶段以及认证协议配置选项在点对点协议（PPP）[1]中定义。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 RFC 2119 [6].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
This document frequently uses the following terms:
本文件经常使用以下术语：
authenticator The end of the link requiring the authentication. The authenticator specifies the authentication protocol to be used in the Configure-Request during Link Establishment phase.
authenticator需要身份验证的链接的末尾。身份验证器指定在链路建立阶段配置请求中使用的身份验证协议。
peer The other end of the point-to-point link; the end which is being authenticated by the authenticator.
对等点对点链路的另一端；正在由验证器进行身份验证的端。
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
静默丢弃这意味着实现在不进行进一步处理的情况下丢弃数据包。实现应该提供记录错误的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
displayable message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [5].
可显示消息这被解释为人类可读的字符串，并且不得影响协议的操作。消息编码必须遵循UTF-8转换格式[5]。
The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange.
PPP可扩展认证协议（EAP）是PPP认证的通用协议，支持多种认证机制。EAP不会在链路控制阶段选择特定的身份验证机制，而是将其推迟到身份验证阶段。这允许验证器在确定特定的身份验证机制之前请求更多信息。这还允许使用“后端”服务器，该服务器实际上实现了各种机制，而PPP认证器仅通过认证交换。
1. After the Link Establishment phase is complete, the authenticator sends one or more Requests to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, One-Time Passwords, Generic Token Card, etc. The MD5-challenge type corresponds closely to the CHAP authentication protocol. Typically, the authenticator will send an initial Identity Request followed by one or more Requests for authentication information. However, an initial Identity Request is not required, and MAY be bypassed in cases where the identity is presumed (leased lines, dedicated dial-ups, etc.).
1. 链路建立阶段完成后，认证器发送一个或多个请求以认证对等方。请求有一个类型字段，用于指示请求的内容。请求类型的示例包括身份、MD5质询、一次性密码、通用令牌卡等。MD5质询类型与CHAP身份验证协议密切相关。通常，认证者将发送初始身份请求，然后发送一个或多个认证信息请求。但是，不需要初始身份请求，在假定身份的情况下（租用线路、专用拨号等），可以绕过初始身份请求。
2. The peer sends a Response packet in reply to each Request. As with the Request packet, the Response packet contains a type field which corresponds to the type field of the Request.
2. 对等方发送一个响应包来响应每个请求。与请求包一样，响应包包含与请求的类型字段相对应的类型字段。
3. The authenticator ends the authentication phase with a Success or Failure packet.
3. 身份验证程序以成功或失败数据包结束身份验证阶段。
Advantages
优势
The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one during LCP Phase.
EAP协议可以支持多种认证机制，而无需在LCP阶段预先协商特定的认证机制。
Certain devices (e.g. a NAS) do not necessarily have to understand each request type and may be able to simply act as a passthrough agent for a "back-end" server on a host. The device only need look for the success/failure code to terminate the authentication phase.
某些设备（例如NAS）不一定必须了解每种请求类型，并且可以简单地充当主机上“后端”服务器的直通代理。设备只需查找成功/失败代码即可终止身份验证阶段。
Disadvantages
缺点
EAP does require the addition of a new authentication type to LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP.
EAP确实需要向LCP添加新的身份验证类型，因此需要修改PPP实现以使用它。它还偏离了以前的PPP认证模型，即在LCP期间协商特定的认证机制。
A summary of the Authentication-Protocol Configuration Option format to negotiate the EAP Authentication Protocol is shown below. The fields are transmitted from left to right.
协商EAP认证协议的认证协议配置选项格式摘要如下所示。字段从左向右传输。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
3
3.
Length
长
4
4.
Authentication-Protocol
认证协议
C227 (Hex) for PPP Extensible Authentication Protocol (EAP)
用于PPP可扩展身份验证协议（EAP）的C227（十六进制）
Exactly one PPP EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP EAP). A summary of the EAP packet format is shown below. The fields are transmitted from left to right.
只有一个PPP EAP数据包被封装在PPP数据链路层帧的信息字段中，其中协议字段指示hex C227（PPP EAP）类型。EAP数据包格式的摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
密码
The Code field is one octet and identifies the type of EAP packet. EAP Codes are assigned as follows:
代码字段是一个八位字节，用于标识EAP数据包的类型。EAP代码分配如下：
1 Request 2 Response 3 Success 4 Failure
1请求2响应3成功4失败
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 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数据包的长度，包括代码、标识符、长度和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时应忽略。
Data
数据
The Data field is zero or more octets. The format of the Data field is determined by the Code field.
数据字段为零个或多个八位字节。数据字段的格式由代码字段决定。
Description
描述
The Request packet is sent by the authenticator to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAP packet with the Code field set to 1 (Request). Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field is dependent on the Request type. The peer MUST send a Response packet in reply to a Request packet. Responses MUST only be sent in reply to a received Request and never retransmitted on a timer. The Identifier field of the Response MUST match that of the Request.
认证器将请求数据包发送给对等方。每个请求都有一个类型字段，用于指示请求的内容。认证器必须发送代码字段设置为1（请求）的EAP数据包。在收到有效响应数据包或可选重试计数器过期之前，必须发送其他请求数据包。必须使用相同的标识符值发送重新传输的请求，以便将其与新请求区分开来。数据字段的内容取决于请求类型。对等方必须发送响应数据包以响应请求数据包。响应只能作为对接收到的请求的响应而发送，决不能在计时器上重新传输。响应的标识符字段必须与请求的标识符字段匹配。
Implementation Note: Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. It is suggested a retransmission timer of 6 seconds with a maximum of 10 retransmissions be used as default. One may wish to make these timeouts longer in certain cases (e.g. where Token Cards are involved). Additionally, the peer must be prepared to silently discard received retransmissions while waiting for user input.
实施说明：由于身份验证过程通常涉及用户输入，因此在决定重传策略和身份验证超时时必须小心。建议默认使用6秒的重传计时器，最多10次重传。在某些情况下（如涉及代币卡），可能希望延长这些超时时间。此外，对等方必须准备在等待用户输入时悄悄放弃接收到的重新传输。
A summary of the Request and Response packet format is shown below. The fields are transmitted from left to right.
请求和响应数据包格式的摘要如下所示。字段从左向右传输。
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 | 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 | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
密码
1 for Request;
（一）请求；
2 for Response.
2.答复。
Identifier
标识符
The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. If a peer recieves a duplicate Request for which it has already sent a Response, it MUST resend it's Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request.
标识符字段是一个八位字节。如果在等待响应时由于超时而重新传输请求数据包，则标识符字段必须相同。任何新的（非重传）请求都必须修改标识符字段。如果对等方接收到重复的请求，并且已经发送了响应，则必须重新发送其响应。如果对等方在发送对初始请求的响应（即，它正在等待用户输入）之前收到重复请求，它必须以静默方式放弃重复请求。
Length
长
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-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
类型
The Type field is one octet. This field indicates the Type of Request or Response. Only one Type MUST be specified per EAP Request or Response. Normally, the Type field of the Response will be the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports. An initial specification of Types follows in a later section of this document.
类型字段是一个八位字节。此字段指示请求或响应的类型。每个EAP请求或响应只能指定一种类型。通常，响应的类型字段将与请求的类型相同。然而，还有一种Nak响应类型，用于指示对等方不接受请求类型。当发送Nak以响应请求时，对等方可指示其支持的备选期望认证类型。类型的初始规范将在本文档后面的章节中给出。
Type-Data
类型数据
The Type-Data field varies with the Type of Request and the associated Response.
类型数据字段随请求类型和相关响应而变化。
Description
描述
The Success packet is sent by the authenticator to the peer to acknowledge successful authentication. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success).
认证者将成功数据包发送给对等方，以确认认证成功。认证器必须发送代码字段设置为3（成功）的EAP数据包。
If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). An
如果验证器无法对对等方进行身份验证（对一个或多个请求的不可接受响应），则实现必须发送代码字段设置为4（失败）的EAP数据包。一
authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes.
验证器可能希望在发送失败响应之前发出多个请求，以便允许人为键入错误。
Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure.
实现说明：由于未确认成功和失败数据包，它们可能会丢失。同伴必须考虑到这种情况。对等方可以使用网络协议分组作为成功的替代指示。同样，收到LCP终止请求也可被视为失败。
A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right.
成功和失败数据包格式的摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
3 for Success;
三是追求成功；
4 for Failure.
4.失败。
Identifier
标识符
The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Indentifier field of the Response packet that it is sent in response to.
标识符字段是一个八位字节，有助于将回复与响应进行匹配。标识符字段必须与发送响应的响应数据包的标识符字段匹配。
Length
长
4
4.
This section defines the initial set of EAP Types used in Request/Response exchanges. More Types may be defined in follow-on documents. The Type field is one octet and identifies the structure of an EAP Request or Response packet. The first 3 Types are considered special case Types. The remaining Types define authentication exchanges. The Nak Type is valid only for Response packets, it MUST NOT be sent in a Request. The Nak Type MUST only be
本节定义了请求/响应交换中使用的EAP类型的初始集合。更多类型可在后续文档中定义。类型字段是一个八位字节，用于标识EAP请求或响应数据包的结构。前3种类型被视为特殊情况类型。其余类型定义身份验证交换。Nak类型仅对响应数据包有效，不能在请求中发送。Nak类型只能是
sent in repsonse to a Request which uses an authentication Type code. All EAP implementatins MUST support Types 1-4. These Types, as well as types 5 and 6, are defined in this document. Follow-on RFCs will define additional EAP Types.
以repsonse发送到使用身份验证类型代码的请求。所有EAP实施必须支持类型1-4。这些类型以及类型5和6在本文件中有定义。后续RFC将定义其他EAP类型。
1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One-Time Password (OTP) (RFC 1938) 6 Generic Token Card
1身份2通知3 Nak（仅响应）4 MD5质询5一次性密码（OTP）（RFC 1938）6通用令牌卡
Description
描述
The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity).
标识类型用于查询对等方的标识。通常，身份验证器会将此作为初始请求发出。可以包括可选的可显示消息，以在期望与用户交互的情况下提示对等方。必须向此请求发送类型为1（标识）的响应。
Implementation Note: The peer MAY obtain the Identity via user input. It is suggested that the authenticator retry the Indentity Request in the case of an invalid Identity or authentication failure to allow for potential typos on the part of the user. It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication phase with a Failure reply. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself).
实施说明：对等方可通过用户输入获得身份。建议身份验证人在身份无效或身份验证失败的情况下重试身份验证请求，以允许用户可能出现打字错误。建议在使用失败回复终止身份验证阶段之前，至少重试身份验证请求3次。通知请求可用于在发送新身份请求之前指示无效的认证尝试（可选地，可在新身份请求本身的消息中指示失败）。
Type
类型
1
1.
Type-Data
类型数据
This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required.
此字段可能包含请求中的可显示消息。响应使用此字段返回标识。如果标识未知，则此字段的长度应为零字节。该字段不能以null结尾。此字段的长度源自请求/响应数据包的长度字段，因此不需要null。
Description
描述
The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. The peer SHOULD display this message to the user or log it if it cannot be displayed. It is intended to provide an acknowledged notification of some imperative nature. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, notification should not be required.
通知类型可选地用于将可显示消息从验证器传送到对等方。对等方应向用户显示此消息，如果无法显示，则应记录此消息。其目的是提供某种必要性质的公认通知。示例包括到期时间即将到期的密码、接近0的OTP序列整数、身份验证失败警告等。在大多数情况下，不需要通知。
Type
类型
2
2.
Type-Data
类型数据
The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 2 (Notification). The Type-Data field of the Response is zero octets in length. The Response should be sent immediately (independent of how the message is displayed or logged).
请求中的类型数据字段包含长度大于零个八位字节的可显示消息。消息的长度由请求数据包的长度字段决定。消息不能以null结尾。必须使用类型字段2（通知）发送响应以答复请求。响应的类型数据字段的长度为零个八位字节。应立即发送响应（与消息的显示或记录方式无关）。
Description
描述
The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains the authentication Type desired by the peer.
Nak类型仅在响应消息中有效。当所需的身份验证类型不可接受时，将发送该消息以响应请求。认证类型编号为4及以上。响应包含对等方所需的身份验证类型。
Type
类型
3
3.
Type-Data
类型数据
This field MUST contain a single octet indicating the desired authentication type.
此字段必须包含一个表示所需身份验证类型的八位字节。
Description
描述
The MD5-Challenge Type is analagous to the PPP CHAP protocol [3] (with MD5 as the specified algorithm). The PPP Challenge Handshake Authentication Protocol RFC [3] should be referred to for further implementation specifics. The Request contains a "challenge" message to the peer. A Repsonse MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5- Challenge) or Type 3 (Nak). The Nak reply indicates the peer's desired authentication mechanism Type. All EAP implementations MUST support the MD5-Challenge mechanism.
MD5质询类型与PPP CHAP协议[3]非常相似（MD5是指定的算法）。PPP质询握手认证协议RFC[3]应参考进一步的实施细节。请求包含对对等方的“质询”消息。必须向请求发送回复。响应可以是类型4（MD5-挑战）或类型3（Nak）。Nak应答指示对等方所需的身份验证机制类型。所有EAP实施必须支持MD5质询机制。
Type
类型
4
4.
Type-Data
类型数据
The contents of the Type-Data field is summarized below. For reference on the use of this fields see the PPP Challenge Handshake Authentication Protocol [3].
类型数据字段的内容总结如下。有关此字段使用的参考信息，请参阅PPP质询握手认证协议[3]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
The One-Time Password system is defined in "A One-Time Password System" [4]. The Request contains a displayable message containing an OTP challenge. A Repsonse MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak reply indicates the peer's desired authentication mechanism Type.
一次性密码系统在“一次性密码系统”[4]中定义。请求包含一条包含OTP质询的可显示消息。必须向请求发送回复。响应必须为类型5（OTP）或类型3（Nak）。Nak应答指示对等方所需的身份验证机制类型。
Type
类型
5
5.
Type-Data
类型数据
The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [4]. The messages MUST not be null terminated. The length of the field is derived from the Length field of the Request/Reply packet.
类型数据字段包含OTP“质询”，作为请求中的可显示消息。在响应中，该字段用于OTP字典[4]中的6个单词。消息不能以null结尾。该字段的长度来自请求/应答数据包的长度字段。
Description
描述
The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains an ASCII text message and the Reply contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text.
通用令牌卡类型定义用于需要用户输入的各种令牌卡实现。请求包含ASCII文本消息，回复包含身份验证所需的令牌卡信息。通常，这将是用户从令牌卡设备读取的信息，并作为ASCII文本输入。
Type
类型
6
6.
Type-Data
类型数据
The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length is of the data is determined by the Length field of the Response packet.
请求中的类型数据字段包含长度大于零个八位字节的可显示消息。消息的长度由请求数据包的长度字段决定。消息不能以null结尾。必须使用类型字段6（通用令牌卡）发送响应以响应请求。响应包含身份验证所需的令牌卡数据。数据的长度由响应数据包的长度字段确定。
Security Considerations
安全考虑
Security issues are the primary topic of this RFC.
安全问题是本RFC的主要主题。
The interaction of the authentication protocols within PPP are highly implementation dependent.
PPP中认证协议的交互高度依赖于实现。
For example, upon failure of authentication, some implementations do not terminate the link. Instead, the implementation limits the kind of traffic in the Network-Layer Protocols to a filtered subset, which in turn allows the user opportunity to update secrets or send mail to the network administrator indicating a problem.
例如，在身份验证失败时，某些实现不会终止链接。相反，该实现将网络层协议中的通信量类型限制为过滤子集，这反过来允许用户有机会更新机密或向网络管理员发送指示问题的邮件。
There is no provision for retries of failed authentication. However, the LCP state machine can renegotiate the authentication protocol at any time, thus allowing a new attempt. It is recommended that any counters used for authentication failure not be reset until after successful authentication, or subsequent termination of the failed link.
没有关于重试失败的身份验证的规定。但是，LCP状态机可以随时重新协商身份验证协议，从而允许新的尝试。建议在成功验证或随后终止失败链接之前，不要重置用于验证失败的任何计数器。
There is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated.
不要求认证是全双工的，也不要求在两个方向上使用相同的协议。在每个方向上使用不同的协议是完全可以接受的。当然，这将取决于谈判的具体协议。
In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
在实践中，在每个PPP服务器内或与之相关联的情况下，预计不会通过多种方法对特定的命名用户进行身份验证。这会使用户容易受到攻击，这些攻击会从集合（例如PAP而不是EAP）中协商最不安全的方法。相反，对于每个命名用户，应该有一个用于验证该用户名的方法的指示。如果用户需要在不同的情况下使用不同的身份验证方法，那么应该使用不同的身份，每个身份都只标识一种身份验证方法。
References
工具书类
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[2] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[3] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[3] 辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, May 1996.
[4] Haller，N.和C.Metz，“一次性密码系统”，RFC 19381996年5月。
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[5] “UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
Acknowledgments
致谢
This protocol derives much of its inspiration from Dave Carrel's AHA draft as well as the PPP CHAP protocol [3]. Bill Simpson provided much of the boilerplate used throughout this document. Al Rubens (Merit) also provided valuable feedback.
该协议的大部分灵感来自Dave Carrel的AHA草案以及PPP CHAP协议[3]。比尔·辛普森（Bill Simpson）提供了贯穿本文件的许多样板文件。Al-Rubens（Merit）也提供了宝贵的反馈。
Chair's Address
主席致辞
The working group can be contacted via the current chair:
可通过现任主席联系工作组：
Karl F. Fox Ascend Communications, Inc. 655 Metro Place South, Suite 370 Dublin, Ohio 43017
Karl F.Fox Ascend Communications，Inc.俄亥俄州都柏林市城南广场655号370室，邮编43017
EMail: karl@ascend.com
Phone: +1 614 760 4041
Fax: +1 614 760 4050
EMail: karl@ascend.com
Phone: +1 614 760 4041
Fax: +1 614 760 4050
Authors' Addresses
作者地址
Larry J. Blunk Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105
美国密歇根州安娜堡市普利茅斯路4251号C室拉里·J·布朗克价值网络公司，邮编：48105
EMail: ljb@merit.edu
Phone: 734-763-6056
FAX: 734-647-3185
EMail: ljb@merit.edu
Phone: 734-763-6056
FAX: 734-647-3185
John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105
John R.Vollbrecht Merit Network，Inc.密歇根州安娜堡普利茅斯路4251号C室，邮编：48105
EMail: jrv@merit.edu
Phone: +1-313-763-1206
FAX: +1-734-647-3185
EMail: jrv@merit.edu
Phone: +1-313-763-1206
FAX: +1-734-647-3185
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。