EAP PPP扩展认证协议( 三 )


请求和应答报文的格式如下所示,字段的传输顺序是从左向右 。
0123
01234567890123456789012345678901
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CodeIdentifierLength
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeType-Data...
- - - - - - - - - - - - - - - - - -
代码Code
1请求
2.应答
标识Identifier
标识字段占一个字节 。由于等待应答超时而重传的请求报文的标识字段必须保持不变 。新的(不是重传的)请求报文必须改变标识字段 。假如对端在收到重复的请求报文之前已经发送过针对该报文的应答报文,它必须重新发送已发送的应答报文 。假如对端收到重复的请求报文之前还没有发送针对该报文的应答报文,它必须静静地丢弃重复的请求报文 。
长度Length
长度字段占两个自己,用于表示EAP报文的长度,包括代码、标识、长度和数据字段 。超出长度的字节应该视为链路层的填充字节,接收方应该忽略 。
类型Type
类型字段占一个字节 。这个字段表示请求或者应答的信息类型 。每一种EAP请求或者应答报文必须指定并且也只能指定一种类型 。一般情况下,应答报文中的类型字段和请求报文中的类型字段是相同的,但是还存在一种为NAK的应答类型用来表示对端不接受请求报文中的信息类型 。当对端用NAK报文应答请求报文的时候,对端可以同时提供一个它所支持的的信息类型供认证者选择 。在本文的随后章节中有对类型的具体定义 。
类型数据Type-Data
类型数据字段随着请求或应答报文中的类型字段变化而变化 。
成功和失败
描述
成功报文是认证者向发送给对端用来指示认证成功的 。认证者必须传送代码字段为3(成功)的EAP报文 。
假如不能认证对端(对应于一个或多个请求报文收到不可接受的应答),认证者必须发送代码字段为4(失败)的EAP报文 。认证者可能会在发送失败的应答报文之前再发起请求报文来避免用户输入错误的情况 。
1实现注重事项:由于成功和失败报文不需要确认,它们有可能会丢失 。对端必须答应这种情况的发生 。对端可以把网络协议报文作为对认证成功的指示;同样也可以把LCP的结束请求报文作为对认证失败的指示 。
成功和失败报文的格式如下所示,字段的传输顺序从左向右 。
0123
01234567890123456789012345678901
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CodeIdentifierLength
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
代码Code
3代表成功
4代表失败
标识Identifier
标识字段占一个字节,用于和对端的应答报文之间的匹配 。成功和失败报文中的标识字段必须和它所对应的应答报文中的标识字段相匹配 。
长度Length
4
1EAP请求/应答类型
这一节中主要定义了在请求和应答的交互过程中所使用到的EAP类型集,后续的文档可能会再扩展其他的类型 。类型字段占一个字节,它标识了EAP请求和应答报文的结构 。前三中类型有其非凡的适用情况,后两种类型适用于认证信息的交互 。NAK类型只适用在应答报文中,而绝不能出现在请求报文中 。所有的EAP实现必须支持类型1到4,本文中定义了这些类型以及类型5、6 。后续的RFC可能会定义一些其他的类型 。
1标识Identity
2通知Notification
3否定Nak(只用在应答中)
4MD5挑战字MD5-Challenge
5一次密码One-TimePassWord(OTP)(RFC1938)
6通用令牌卡GenericTokenCard
1.1标识Identification
描述
标识类型用来询问对端的身份 。一般情况下,认证者会首先发起这种类型的请求,这种请求报文可选择包含一个可显示的提示信息,用于和终端用户间的交互 。对这种请求报文的应答报文的类型值也必须设为1 。

推荐阅读