RFC2284PPP可扩展认证协议.docx
《RFC2284PPP可扩展认证协议.docx》由会员分享，可在线阅读，更多相关《RFC2284PPP可扩展认证协议.docx（17页珍藏版）》请在冰豆网上搜索。
RFC2284PPP可扩展认证协议
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
Hlp（hlp,huangliuqi@）
译文发布时间：
2001-4-26
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
NetworkWorkingGroupL.Blunk
RequestforComments:
2284J.Vollbrecht
Category:
StandardsTrackMeritNetwork,Inc.
March1998
PPP可扩展认证协议
（RFC2284PPPExtensibleAuthenticationProtocol,EAP）
本文档现状
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"（STD1）forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.
版权通告
Copyright（C）TheInternetSociety（1998）.AllRightsReserved.
摘要
点到点协议（PPP，参考文献[1]）提供了一种在点到点链路上传输多协议数据包的标准的方法。
PPP还定义了可扩展的链路控制协议（LinkControlProtocol,简称LCP），允许该链路在进入网络层协议之前协商为通信对方进行身份认证所使用的认证协议（AuthenticationProtocol）。
本文档定义了PPP可扩展的认证协议（AuthenticationProtocol）。
ThisdocumentdefinesthePPPExtensibleAuthenticationProtocol.
目录
1.简介.................................................2
1.1规范的条件.......................................2
1.2术语.............................................2
2.PPP可扩展认证协议（EAP）...............................3
2.1配置选项格式.....................................4
2.2数据包格式.......................................6
2.2.1Request和Response..............................6
2.2.2Success和Failure...............................7
3.初始EAPRequest/Response类型............................8
3.1Identity........................................9
3.2Notification....................................10
3.3Nak.............................................10
3.4MD5-Challenge...................................11
3.5One-TimePassword（OTP）.........................11
3.6GenericTokenCard..............................12
参考文献.......................................................13
致谢..........................................................14
主席地址.....................................................14
作者地址......................................................14
完整的版权通告................................................15
1.简介
为了在点到点链路上建立通信，在链路建立阶段PPP链路的每一端都必须首先发送LCP数据包来对该数据链路进行配置。
在链路已经建立起来后，在进入网络层协议之前，PPP提供一个可选的认证阶段。
缺省认为，认证不是必需的。
如果想要对链路进行认证，实现必须在链路建立阶段指定认证协议配置选项（Authentication-ProtocolConfiguration）。
这些认证协议主要是由通过交换电路（switchedcircuits）或者拨号链路（也适用于专用链路）连接到PPP网络服务器上的主机或者路由器使用。
服务器可以使用这些主机或路由器的身份（identification）来选择网络层协商的选项。
本文档定义了PPP可扩展认证协议（EAP）。
链路建立阶段、认证阶段以及认证协议配置选项在点到点协议（PPP，参考文献[1]）中定义。
1.1.本规范的条件
本文档中出现的关键词必须（MUST）,不允许（MUSTNOT）,必需（REQUIRED）,应该（SHALL）,不应（SHALLNOT）,应该（SHOULD）,不应该（SHOULDNOT）,推荐（RECOMMENDED）,可以（可能，MAY）,以及可选（OPTIONAL）,按RFC2119（参考文献[6]）解释。
中译版本将对这些关键词加粗并加上红色突出显示。
1.2.术语
本文档频繁使用下面的术语：
认证者（authenticator）
链路要求进行认证的一端。
在链路建立阶段的Configure-Request中认证者指定了将要使用的认证协议。
对方（peer）
点到点链路的另一端；被认证者进行认证的那一端。
悄悄地丢弃（silentlydiscard）
意味着实现不对数据包进行进一步处理而把它丢掉。
实现应该提供对错误包括被丢弃数据包的内容进行登记的能力，并且应该在一个统计计数器中记录下该事件。
可显示的消息（displayablemessage）
解释为人类可读的字符串，并且不允许影响本协议的操作。
消息的编码必须符合UTF-8转换格式（参考文献[5]）。
2.PPP可扩展认证协议（EAP）
PPP可扩展认证协议（EAP）是PPP认证的一个通用协议，支持多种认证机制。
EAP在链路控制（LCP）阶段没有选择好一种认证机制，而把这一步推迟到认证（Authentication）阶段。
这样就允许认证者在确定某种特定认证机制之前请求更多的信息。
这样做还允许使用一个“后端”服务器来实际实现各种认证机制，PPP的认证者仅仅需要传送认证（passthrough）认证信息。
1.在链路建立阶段完成后，认证者发送一个或多个Request来对对方进行认证。
Request中有一个type域表明请求的类型。
Request中type的实例包括，Identity,MD5-challenge,One-TimePasswords,GenericTokenCard等等。
MD5-challenge类型与CHAP认证协议紧紧对应。
典型情况下，认证者将发送一个最初的Identity请求，然后是一个或多个请求认证信息的Request。
但是，最初的IdentityRequest并不是必需的，在identity能被事先假定（租借链路，专用拨号线路等等）的情况下可以跳过（bypass）。
2.对方发送一个Response数据包对每一个Request做出应答。
对应于每一个Request数据包，Response数据包包含一个type域，与Request中的type域对应。
3.认证者发送一个Success或Failure数据包结束认证阶段。
优点
EAP协议可以支持多种认证机制，而不必在LCP阶段预先协商好某种特定认证机制。
特定设备（例如，网络访问服务器NAS）不一定要理解每一种请求类型，而可以简单的作为某个主机上的“后端”服务器的透传（passthrough）代理。
设备仅仅需要检查success/failure的code来结束认证阶段。
缺点
EAP要求给LCP增加新的认证类型（机制），这就要求修改PPP实现以使用EAP。
它也与在LCP阶段就协商好特定认证机制的传统的PPP认证模式相背离。
2.1.认证选项格式
协商EAP认证协议的“认证协议配置选项”（Authentication-ProtocolConfigurationOption）的格式如下所示。
传输时各域从左到右依次进行。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Authentication-Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
4
Authentication-Protocol
C227（十六进制）EAP
2.2.数据包格式
档PPP帧中的protocol域表明协议类型为C227（PPPEAP）时，在PPP数据链路层帧的Information域中封装且仅封装一个PPPEAP数据包。
EAP数据包的格式如下所示，传输时各域从左到右依次进行。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data...
+-+-+-+-+
Code
Code域为一个字节，标识了EAP数据包的类型。
EAP的code值指定如下：
1Request
2Response
3Success
4Failure
Identifier
Identifier域为一个字节，辅助进行response和request的匹配。
Length
Length域为两个字节，表明了EAP数据包的长度，包括Code,Identifier,Length以及Data等各域。
超出Length域范围的字节应该视为数据链路层填充（padding）,在接收时应该被忽略掉。
Data
Data域为0个或更多个字节。
Data域的格式由Code域决定。
2.2.1.Request和Response
描述
Request数据包由认证者发送给对方。
每一个Request有一个type域来表明正在请求的类型。
认证者必须发送一个Code域为1的EAP数据包（即Request）。
在收到有效的Response数据包之前，或者在可选的重发计数器计数满（expires）之前，必须发送另外的Request数据包。
重新发送的Request必须保持Identifier的值不变以区别于新的Request。
Data域的内容依赖于Request的Type。
对方必须发送一个Response作为对Request的应答。
Response必须仅在对接收到的Request作出应答时发送，从不根据定时器重发。
Response中的Identifier域必须与Request中的Identifier域匹配。
实现须知：
因为认证过程经常涉及到用户输入，在决定重发策略和认证超时设定（timeout）时要谨慎。
建议使用重发定时器为6秒，最大重传次数为10次作为缺省值。
人们可能希望某些特定情况下（例如，涉及到TokenCards的时候）超时设定能更长些。
另外，对方必须准备好在等待用户输入时悄悄丢弃所收到的重传数据包。
Request和Response数据包的格式如下所示，传输时各域从左到右依次进行。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Type-Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
1forRequest;
2forResponse.
Identifier
Identifier域为一个字节。
在等待Response时根据timeout而重发的Request的Identifier域必须相同。
任何新的（非重发的）Request必须修改Identifier域。
如果对方收到了重复的Request，并且已经发送了对该Request的Response，则对方必须重发该Response。
如果对方在给最初的Request发送Response之前收到重复的Request（也就是说，它在等待用户输入），它必须悄悄的丢弃重复的Request。
Length
Length域为两个字节，表明EAP数据包的长度，包括Code,Identifier，Length，Type以及Type-Data等各域。
超出Length域的字节应视为数据链路层填充（padding），在接收时应该被忽略掉。
Type
Type域为一个字节,该域表明了Request或Response的类型。
在EAP的Request或Response中必须出现且仅出现一个Type。
通常，Response中的Type域和Request中的Type域相同。
但是，Response可以有一个Nak类型，表明Request中的Type不能被对方接受。
当对方发送Nak来响应一个Request时，它可以暗示它所希望使用并且支持的认证类型。
各种Type的原始定义在本文档后面的章节中给出。
Type-Data
Type-Data域随Request和相对应的Response的Type的不同而不同。
2.2.2.Success和Failure
描述
Success数据包由认证者发送给对方，以确认认证成功。
认证者必须发送一个Code域为3的EAP数据包（即Success）。
如果认证者不能为对方进行认证（给一个或多个Request发送“不可接受”Response）,则实现必须发送一个Code域为4的EAP数据包（即Failure）。
认证者可能希望在发送Failure之前发送几个Request以顾及到人为地打字错误。
实现须知：
因为Success和Failure数据包不被确认，所以它们有可能丢失。
对方必须顾及到这种情况。
对方可以用一个网络协议数据包（NetworkProtocolpacket）来作为可选的Success的暗示。
同样，收到LCPTerminate-Request可以视为收到Failure。
Success和Failure数据包的格式如下所示。
传输时各域从左到右依次进行。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
3Success;
4Failure.
Identifier
Identifier域为一个字节，辅助匹配Response应答。
Identifier域必须与其正在应答的Response域中的Identifier域相匹配。
Length
4
3.最初Request/Respons中的Type类型
本章定义了用于Request/Response中的各种EAPType的最初集合。
更多的类型在以后的文档中可以定义。
Type域为一个字节，标识了EAPRequest或Response数据包的结构。
头3种Type被认为特殊情形的Type，其余的Type定义了认证的交换流量。
Nak类型仅对Response数据包有效，不允许把它放在Request中发送。
Nak类型必须仅在对使用认证Type的Request作出响应时才发送。
所有的EAP实现必须支持类型1-4,这些类型和类型5-6在本文档中定义，以后的RFC将定义其它的类型。
Blunk&VollbrechtStandardsTrack[Page8]
RFC2284EAPMarch1998
1Identity
2Notification
3Nak（Responseonly）
4MD5-Challenge
5One-TimePassword（OTP）（RFC1938）
6GenericTokenCard
3.1.Identity
描述
Identify类型用来查询对方的身份。
通常，认证者发送该类型作为最初的Request。
在期望与用户进行交互的场合还可以包括一条可选的可显示的消息以给对方作出提示。
必须对包含Type1（Identity）的Request发送Response以作出响应。
实现须知：
对方可以通过用户输入获得Identity。
建议在Identity无效或者认证失败时认证者重发（retry）IdentityRequest以顾及到用户的打字错误。
建议在发送Failure应答来结束认证阶段之前最少重发IdentityRequest3次。
在发送新的IdentityRequest之前可以发送一个NotificationRequest来暗示认证无效（可选地，失败可以通过新的Identity中的消息来暗示）。
Type
1
Type-Data
该域可以包含一条可显示的消息。
Response用该域来返回Identity。
如果Identity未知，该域长度应该为0。
该域不允许以null作为终结符。
该域的长度由Request/Response中的Length域来决定，所以null是不必要的。
Blunk&VollbrechtStandardsTrack[Page9]
RFC2284EAPMarch1998
3.2.Notification
描述
NotificationType可选地由认证者用来给对方传递一条可显示的消息。
对方应该把这条消息显示给用户，如果无法显示则纪录（log）该消息。
使用它的目的是在某些紧急情况下（imperativenature）提供一条确认通知（acknowledgednotification）。
这样的例子包括带一个超时设定（expiration）的口令，OTP序列整数（接近0），认证失败警告等等。
在大多数情况下，notification不应该是必要的。
Type
2
Type-Data
Type-Data域包含一条长度大于0字节的可显示的消息。
消息的长度由Request数据包中的Length域决定，消息不允许以null作为终结符。
必须对带有Type域为2（Notification）的Request发送一个Response。
Response中的Type-Data域长度为0字节，Response应该立即发送（与消息显示或纪录的方法无关）。
3.3.Nak
描述
Nak仅对Response有效，当Request中希望（desired）的认证类型不可接受时，发送Nak作为对Request的响应。
AuthenticationType的值为大于等于4。
Response中包含了对方所希望使用的认证类型。
Type
3
Type-Data
该域必须包含一个唯一的字节，表明希望的认证类型。
Blunk&VollbrechtStandardsTrack[Page10]
RFC2284EAPMarch1998
3.4.MD5-Challenge
描述
MD5-ChallengeType与PPPCHAP协议（参考文献[3]，制定了MD5算法）类似。
更多的实现细节应该参考PPP挑战握手认证协议RFC（参考文献[3]）。
Request包含一个对对方进行“挑战”的消息，必须对这样的Request发送一个Response以作出应答。
Response可以为Type4（MD5-Challenge）或者Type3（Nak）。
Nak应答表明对方希望的认证机制类型。
所有的EAP实现必须支持MD5-Challenge机制。
Type
4
Type-Data
Type-Data域的内容如下所示。
这些域的用法请参考PPP挑战握手认证协议（参考文献[3]）。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value-Size|Value...
+-+-+-+-
升级会员 