组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：piex（piex&nbsp;&nbsp;&nbsp;&nbsp;jintao@bigfoot.com）<br />
译文发布时间：2002-01-18<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Blunk<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2284&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Vollbrecht<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Merit&nbsp;Network,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;March&nbsp;1998<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PPP扩展认证协议(EAP)<br />
(RFC2284-PPP&nbsp;Extensible&nbsp;Authentication&nbsp;Protocol&nbsp;(EAP))<br />
<br />
<br />
Status&nbsp;of&nbsp;this&nbsp;Memo<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;specifies&nbsp;an&nbsp;Internet&nbsp;standards&nbsp;track&nbsp;protocol&nbsp;for&nbsp;the<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;community,&nbsp;and&nbsp;requests&nbsp;discussion&nbsp;and&nbsp;suggestions&nbsp;for<br />
&nbsp;&nbsp;&nbsp;improvements.&nbsp;&nbsp;Please&nbsp;refer&nbsp;to&nbsp;the&nbsp;current&nbsp;edition&nbsp;of&nbsp;the&nbsp;"Internet<br />
&nbsp;&nbsp;&nbsp;Official&nbsp;Protocol&nbsp;Standards"&nbsp;(STD&nbsp;1)&nbsp;for&nbsp;the&nbsp;standardization&nbsp;state<br />
&nbsp;&nbsp;&nbsp;and&nbsp;status&nbsp;of&nbsp;this&nbsp;protocol.&nbsp;&nbsp;Distribution&nbsp;of&nbsp;this&nbsp;memo&nbsp;is&nbsp;unlimited.<br />
<br />
Copyright&nbsp;Notice<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1998).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
摘要<br />
<br />
	点到点协议（PPP）提供一种在点到点链路上传输多协议报文的标准方法。在PPP中定义了一个可扩展的链路控制协议（LCP），LCP协议允许协商认证协议，从而可以在网络层报文在链路上传输之前对对端进行认证。本文档定义了PPP扩展认证协议（EAP）。<br />
目&nbsp;&nbsp;录<br />
1介绍<br />
3<br />
1.1要求规范<br />
3<br />
1.2术语<br />
3<br />
2PPP扩展认证协议(EAP)<br />
3<br />
2.1配置选项(Config&nbsp;Option)格式<br />
4<br />
2.2报文格式<br />
4<br />
请求和应答<br />
5<br />
成功和失败<br />
6<br />
3EAP请求/应答类型<br />
7<br />
3.1标识&nbsp;Identification<br />
7<br />
3.2通知&nbsp;Notification<br />
8<br />
3.3否定&nbsp;Nak<br />
8<br />
3.4MD5挑战字<br />
8<br />
3.5一次密码（OTP）<br />
9<br />
3.6通用令牌卡<br />
9<br />
4安全考虑<br />
9<br />
5参考文献<br />
10<br />
6鸣谢<br />
10<br />
1.介绍<br />
为了在点到点的链路上进行通信，PPP链路的每一端在链路建立阶段必须首先发送LCP报文配置数据链路。链路建立之后，PPP提供可选的认证阶段，可以在进入NCP阶段之前对对端进行认证。<br />
缺省情况下，认证过程不是必须的。如果需要链路认证，PPP实现必须在链路建立阶段指定“认证协议”配置选项。<br />
这些认证协议主要是用在主机或者路由器，这些主机和路由器通过交换电路线或者拨号线连在PPP网络服务器上，但是也适用于专线。PPP网络服务器可以用主机或路由器的认证身份来作为网络层协商的选项&nbsp;。<br />
本文定义了PPP的扩展认证协议（EAP）。链路建立和认证阶段以及其中的认证协议配置选项在PPP协议中定义[1]。<br />
1.1&nbsp;要求规范<br />
在本文中用以下几个词表示规范描述要求，这几个词用大些（黑体）表示。<br />
1.	MUST&nbsp;	“必须”，也就是形容词“必需的”，意思是该项是本规范的绝对要求。<br />
2.	MUST&nbsp;NOT&nbsp;&nbsp;“不得”，意思是该项是本规范所绝对禁止的。<br />
3.	SHOULD&nbsp;&nbsp;&nbsp;&nbsp;“应该”，也就是形容词“推荐的”，意思是在某些场合可能由于某种原因忽略该项，但是协议的完全实现必须能够理解该项，在决定其他方式之前要经过仔细考虑。<br />
4.	MAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;“可以”，也就是形容词“可选的”，意思是该项可以作为可选集使用，不包含该选项的协议实现必须能够和包含了该选项的实现交互协作。<br />
1.2&nbsp;术语<br />
本文频繁使用下面的术语：<br />
黖	Autherticator&nbsp;认证者<br />
链路要求认证的一端。认证者在链路建立阶段的配置请求项中指定要使用的认证协议。<br />
黖	Peer&nbsp;对端<br />
点到点链路的另一端，由认证者认证的另一端。<br />
黖	Sliently&nbsp;discard&nbsp;静静丢弃<br />
指直接丢弃数据包，不作进一步处理。实现中应该提供记录错误的能力——包括所丢弃报文的内容，还应该在统计计数器中记录这个事件。<br />
2&nbsp;PPP扩展认证协议(EAP)<br />
PPP扩展认证协议（EAP）是一个用于PPP认证的通用协议，可以支持多种认证方法。EAP并不在链路建立阶段指定认证方法，而是把这个过程推迟到认证阶段。这样认证方就可以在得到更多的信息以后再决定使用什么认证方法。这种机制还允许PPP认证方简单地把收到的认证报文透传给后方的认证服务器，由后方的认证服务器来真正实现各种认证方法。<br />
1.	在链路阶段完成以后，认证方向对端发送一个或多个请求报文。在请求报文中有一个类型字段用来指明认证方所请求的信息类型，例如是对端的ID、MD5的挑战字、一次密码（OTP）以及通用令牌卡等。MD5的挑战字对应于CHAP认证协议的挑战字。典型情况下，认证方首先发送一个ID请求报文随后再发送其他的请求报文。当然，并不是必须要首先发送这个ID请求报文，在对端身份是已知的情况下（如租用线、拨号专线等）可以跳过这个步骤。<br />
2.	对端对每一个请求报文回应一个应答报文。和请求报文一样，应答报文中也包含一个类型字段，对应于所回应的请求报文中的类型字段。<br />
3.	认证方通过发送一个成功或者失败的报文来结束认证过程。<br />
<br />
优点：<br />
EAP可以支持多种认证机制，而无需在LCP阶段预协商过程中指定。<br />
某些设备（如：网络接入服务器）不需要关心每一个请求报文的真正含义，而是作为一个代理把认证报文直接透传给后端的认证服务器。设备只需关心认证结果是成功还是失败，然后结束认证阶段。<br />
<br />
缺点：<br />
EAP需要在LCP中增加一个新的认证协议，这样现有的PPP实现要想使用EAP就必须进行修改。同时，使用EAP也和现有的在LCP协商阶段指定认证方法的模型不一致。<br />
2.1&nbsp;配置选项(Config&nbsp;Option)格式<br />
用于指定EAP认证协议的认证协议配置选项格式如下所示，字段的传输顺序是从左向右。<br />
&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Authentication-Protocol&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
类型&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
长度&nbsp;Length<br />
	4<br />
认证协议&nbsp;Authentication-Protocol<br />
	C227&nbsp;(16进制)&nbsp;对应于PPP的扩展认证协议EAP<br />
1.1&nbsp;报文格式<br />
当PPP帧的协议字段是16机制的C227的时候，表示PPP帧的信息字段里封装了一个完整的EAP报文。EAP报文的格式如下所示，字段的传输顺序是从左向右。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Code&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Identifier&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Data&nbsp;...<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+<br />
代码&nbsp;Code<br />
代码字段占一个字节，表明了EAP报文的报文类型。分配如下：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;请求<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;应答<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;成功<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;失败<br />
<br />
标识&nbsp;Identifier<br />
标识字段占一个字节，用于应答报文和请求报文之间进行匹配。<br />
<br />
长度&nbsp;Length<br />
长度字段占两个字节，用于表示EAP报文的长度，包括代码、标识、长度和数据字段。超出长度的字节应该视为链路层的填充字节，接收方应该忽略。<br />
<br />
数据&nbsp;Data<br />
数据字段是零个或多个字节，数据字段格式由代码字段确定。<br />
<br />
请求和应答<br />
描述<br />
请求报文由认证方发向对端。每一个请求报文都有一个类型字段用来表示请求方在请求什么信息。认证方必须向对端发送一个EAP报文并把其中的代码（CODE）字段设为1（REQUEST）。认证方必须在收到一个有效的应答报文或者在一个可选的计数器计满后再发送其他的请求报文。重传的请求报文中的标识（ID）字段必须保持不变，以便区分重传的请求报文和新的请求报文。数据字段的内容取决于类型字段的值。对端每收到一个请求报文后必须回应一个报文。只有在收到请求报文的情况下才发送应答报文，请求报文没有超时重传的情况。应答报文中标识（ID）字段必须和请求报文中的标识字（ID）段相匹配。<br />
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;实现注意事项：由于在认证过程经常涉及到用户输入，必须采取合适的重传策略和超时时间。建议缺省情况下采用6秒的超时计数器，最大重传次数设为10。在某些情况下可以延长超时时间（如涉及到令牌卡的情况）。另外，对端在等待用户输入的时候必须静静地丢弃收到的重复的请求报文。<br />
请求和应答报文的格式如下所示，字段的传输顺序是从左向右。<br />
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Code&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Identifier&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Type-Data&nbsp;...<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<br />
代码&nbsp;Code<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;请求<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;.&nbsp;应答<br />
<br />
标识&nbsp;Identifier<br />
标识字段占一个字节。由于等待应答超时而重传的请求报文的标识字段必须保持不变。新的（不是重传的）请求报文必须改变标识字段。如果对端在收到重复的请求报文之前已经发送过针对该报文的应答报文，它必须重新发送已发送的应答报文。如果对端收到重复的请求报文之前还没有发送针对该报文的应答报文，它必须静静地丢弃重复的请求报文。	<br />
<br />
长度&nbsp;&nbsp;Length<br />
长度字段占两个自己，用于表示EAP报文的长度，包括代码、标识、长度和数据字段。超出长度的字节应该视为链路层的填充字节，接收方应该忽略。<br />
<br />
类型&nbsp;&nbsp;Type<br />
类型字段占一个字节。这个字段表示请求或者应答的信息类型。每一种EAP&nbsp;&nbsp;请求或者应答报文必须指定并且也只能指定一种类型。一般情况下，应答报文中的类型字段和请求报文中的类型字段是相同的，但是还存在一种为NAK的应答类型用来表示对端不接受请求报文中的信息类型。当对端用NAK报文应答请求报文的时候，对端可以同时提供一个它所支持的的信息类型供认证者选择。在本文的随后章节中有对类型的详细定义。<br />
<br />
类型数据&nbsp;&nbsp;Type-Data<br />
类型数据字段随着请求或应答报文中的类型字段变化而变化。<br />
<br />
成功和失败<br />
描述<br />
成功报文是认证者向发送给对端用来指示认证成功的。认证者必须传送代码字段为3（成功）的EAP报文。<br />
如果不能认证对端（对应于一个或多个请求报文收到不可接受的应答），认证者必须发送代码字段为4（失败）的EAP报文。认证者可能会在发送失败的应答报文之前再发起请求报文来避免用户输入错误的情况。<br />
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;实现注意事项：由于成功和失败报文不需要确认，它们有可能会丢失。对端必须允许这种情况的发生。对端可以把网络协议报文作为对认证成功的指示；同样也可以把LCP的结束请求报文作为对认证失败的指示。<br />
成功和失败报文的格式如下所示，字段的传输顺序从左向右。<br />
&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Code&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Identifier&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
代码&nbsp;Code<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;代表成功<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;代表失败<br />
<br />
标识&nbsp;Identifier<br />
标识字段占一个字节，用于和对端的应答报文之间的匹配。成功和失败报文中的标识字段必须和它所对应的应答报文中的标识字段相匹配。<br />
<br />
长度&nbsp;&nbsp;&nbsp;Length<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4<br />
1&nbsp;EAP请求/应答类型<br />
这一节中主要定义了在请求和应答的交互过程中所使用到的EAP类型集，后续的文档可能会再扩展其他的类型。类型字段占一个字节，它标识了EAP请求和应答报文的结构。前三中类型有其特别的适用情况，后两种类型适用于认证信息的交互。NAK类型只适用在应答报文中，而绝不能出现在请求报文中。所有的EAP实现必须支持类型1到4，本文中定义了这些类型以及类型5、6。后续的RFC可能会定义一些其他的类型。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;标识&nbsp;Identity<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;通知&nbsp;Notification<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;否定&nbsp;Nak&nbsp;(只用在应答中)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MD5挑战字&nbsp;&nbsp;MD5-Challenge<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;一次密码&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;One-Time&nbsp;Password&nbsp;(OTP)&nbsp;(RFC&nbsp;1938)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;通用令牌卡&nbsp;&nbsp;Generic&nbsp;Token&nbsp;Card<br />
<br />
1.1&nbsp;标识&nbsp;Identification<br />
描述<br />
标识类型用来询问对端的身份。一般情况下，认证者会首先发起这种类型的请求，这种请求报文可选择包含一个可显示的提示信息，用于和终端用户间的交互。对这种请求报文的应答报文的类型值也必须设为1。<br />
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;实现注意事项：对端可能通过用户的输入得到身份值，因此建议认证者在收到错误的身份值或者认证失败的身份值后重新发送标识类型的请求报文，以应付用户输入错误的情况。并且建议认证者至少在尝试三次失败以后才向对端发送一个失败（Failure）的应答报文来终止认证阶段。认证者可以在重新发送标识（ID）请求报文之前发送一个通知（Notification）报文用于提示对端认证错误（也可以把这些提示信息放在重新发送的标识（ID）请求报文的提示信息中）。<br />
类型&nbsp;&nbsp;&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<br />
类型数据&nbsp;&nbsp;&nbsp;Type-Data<br />
在请求报文中这个字段可以包含一段可显示的提示信息；而在应答报文中这个字段包含对端的身份（ID），如果对端还不知道自己的身份，那么在长度（Length）字段中指示标识（ID）字段的长度应该为零。在该字段中的字符串不需要用空字符（NULL）结束，因为长度字段中的值就标明了字符串的长度。<br />
1.2&nbsp;通知&nbsp;Notification<br />
描述<br />
通知类型经常用于认证者向对端传送一个可显示的字符串。对端应该把这个字符串显示给用户，如果不能显示的话也应该记录下来。它主要用于向对端发一些通知，比如提示密码将要超期、OTP的顺序号码接近零以及认证失败的警告等。在大部分情况下不需要这个类型。<br />
类型&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<br />
类型数据&nbsp;Type-Data<br />
请求报文中的类型数据字段包含一段长度大于0字节的可显示的字符串。字符串的长度由请求报文中的长度字段的值来决定，并且字符串不需要用空字符（NULL）结束。对端收到这种类型的请求报文以后不管怎么处理其中的通知信息都必须立刻发送一个类型值为2（通知）的应答报文，并且应答报文的类型数据字段的长度应该为零。<br />
1.3&nbsp;否定&nbsp;Nak<br />
描述<br />
否定类型只应该出现在应答报文中，用来表示对端不接受请求报文中的认证信息类型。认证信息类型是指类型值大于等于4的信息类型。否定类型的应答报文中可以同时提供一个对端所期望的认证信息类型。<br />
类型&nbsp;&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
类型数据&nbsp;Type-Data<br />
这个字段必须包含一个字节用来向认证者提供对端所期待的认证信息类型。<br />
1.4&nbsp;MD5挑战字<br />
描述<br />
MD5挑战字和PPP的CHAP[3]协议中的挑战字类似，使用MD5算法。CHAP的具体实现细节应该查阅PPP挑战握手认证协议的RFC[3]。在类型为MD5挑战字的请求报文中包含一个“挑战”信息，对端收到这个请求报文后必须发送一个应答报文，应答报文的信息类型可以是4（MD5挑战字）或者3（否定），在NAK应答报文中对端同时也标明了它所期待的认证机制的类型值。所有的EAP实现必须支持MD5挑战字算法。<br />
类型&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4<br />
类型数据&nbsp;&nbsp;Type-Data<br />
类型数据的内容如下所示。至于如何使用其中的这些字段请参阅PPP的挑战握手认证协议[3]。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Value-Size&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Value&nbsp;...<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Name&nbsp;...<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
1.5&nbsp;一次密码（OTP）<br />
描述<br />
一次密码系统在文献[4]中定义。请求报文中包含一个可显示的信息作为一次密码（OTP）的挑战字。对端收到这种请求报文后必须发送一个应答报文，应答报文的类型值也必须设为5（OTP）或者3（NAK）,在NAK应答报文中对端同时也标明了它所期待的认证机制的类型值。<br />
类型&nbsp;&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5<br />
类型数据&nbsp;&nbsp;Type-Data<br />
在请求报文中，类型数据字段包含一个可显示的信息作为一次密码（OTP）的挑战字。在应答报文中类型数据字段用于填充从OTP目录中得到的6个字。该字段不需要用空字符（NULL）结束，该字段的长度可以从报文的长度字段中计算得到。<br />
1.6&nbsp;通用令牌卡<br />
描述<br />
通用令牌卡类型适用于各种需要用户输入信息的令牌卡的实现。在请求报文中包含一段ASCII文本信息，而应答报文中包含用于认证的令牌卡信息。典型的，令牌卡信息是由用户从令牌卡设备上读取得到并作为ASCII文本输入的。<br />
类型&nbsp;&nbsp;Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6<br />
类型数据&nbsp;Type-Data<br />
在请求报文中，该字段包含一段长度大于零的可显示的信息，它的长度可以从报文的长度字段中计算得到，因此该字段不需要用空字符（NULL）结束。对端收到这种请求报文以后必须发送一个类型值为6（通用令牌卡）的报文作为应答，应答报文中包含用于认证的令牌卡信息，通用它的长度也可以从报文的长度字段中计算得到。<br />
<br />
1&nbsp;安全考虑<br />
安全主题是该RFC的主题。<br />
PPP的认证交换过程依赖于实现。例如在有些实现中认证失败就直接终止链路，而在另外一些实现中并不终止链路，而只是限制和滤除网络层的流量从而允许用户更改密钥或者发邮件通知管理员。<br />
虽然没有如何处理认证失败以后的重新认证的规定，但由于LCP的状态机可以随时重新协商认证协议，然后开始一个新的认证过程，因此建议用于认证失败的各种计数器只有在认证成功或者链路终结以后才重新设置。<br />
并没有要求认证一定要在两个方向上进行，也没有要求在两个方向上使用同样的认证协议。我们完全可以接受在两个方向上使用不同的认证协议，当然，这依赖于协商的结果。<br />
实际上，一个PPP服务器不应该使用多种认证协议来认证一个特定的用户。因为这样容易使用户在使用安全性较低的认证协议（如PAP，而不是EAP）的时候受到攻击。&nbsp;&nbsp;&nbsp;&nbsp;对于每一个用户名，应该指示一种特定的认证方法，如果用户在不同的环境下使用不同的认证方法，那么他应该在不同的环境下使用不同的用户名，每个用户名对应一个认证方法。<br />
<br />
1&nbsp;参考文献<br />
[1]&nbsp;&nbsp;&nbsp;Simpson,&nbsp;W.,&nbsp;"The&nbsp;Point-to-Point&nbsp;Protocol&nbsp;(PPP)",&nbsp;STD&nbsp;51,&nbsp;RFC&nbsp;1661,&nbsp;July&nbsp;1994.<br />
[2]&nbsp;&nbsp;&nbsp;Reynolds,&nbsp;J.&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Assigned&nbsp;Numbers",&nbsp;STD&nbsp;2,&nbsp;RFC&nbsp;1700,&nbsp;October&nbsp;1994.<br />
[3]&nbsp;&nbsp;Simpson,&nbsp;W.,&nbsp;"PPP&nbsp;Challenge&nbsp;Handshake&nbsp;Authentication&nbsp;Protocol&nbsp;(CHAP)",&nbsp;RFC&nbsp;1994,&nbsp;August&nbsp;1996.<br />
[4]&nbsp;&nbsp;&nbsp;Haller,&nbsp;N.&nbsp;and&nbsp;C.&nbsp;Metz,&nbsp;"A&nbsp;One-Time&nbsp;Password&nbsp;System",&nbsp;RFC&nbsp;1938,&nbsp;May&nbsp;1996.<br />
[5]&nbsp;&nbsp;Yergeau,&nbsp;F.,&nbsp;"UTF-8,&nbsp;a&nbsp;transformation&nbsp;format&nbsp;of&nbsp;Unicode&nbsp;and&nbsp;ISO&nbsp;10646",&nbsp;RFC&nbsp;2044,&nbsp;October&nbsp;1996.<br />
[6]&nbsp;&nbsp;&nbsp;Bradner,&nbsp;S.,&nbsp;"Key&nbsp;words&nbsp;for&nbsp;use&nbsp;in&nbsp;RFCs&nbsp;to&nbsp;Indicate&nbsp;Requirement&nbsp;&nbsp;Levels",&nbsp;RFC&nbsp;2119,&nbsp;March&nbsp;1997.<br />
<br />
1&nbsp;鸣谢<br />
撰写本文的很多灵感都来源于Dave&nbsp;Carrel的AHA草案和PPP的CHAP认证协议。&nbsp;Bill&nbsp;Simpson提供了本文所使用的书写模板。&nbsp;Al&nbsp;Rubens为本文提出了很多有价值的建议。<br />
<br />