📄 rfc2284.txt
字号:
组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：Hlp(hlp,huangliuqi@hotmail.com)
译文发布时间：2001-4-26
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。
Network Working Group L. Blunk
Request for Comments: 2284 J. Vollbrecht
Category: Standards Track Merit Network, Inc.
March 1998
PPP可扩展认证协议
(RFC 2284 PPP Extensible Authentication Protocol,EAP)
本文档现状
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.
版权通告
Copyright (C) The Internet Society (1998). All Rights Reserved.
摘要
点到点协议（PPP，参考文献[1]）提供了一种在点到点链路上传输多协议数据包的标准的
方法。
PPP还定义了可扩展的链路控制协议(Link Control Protocol,简称LCP)，允许该链路在
进入网络层协议之前协商为通信对方进行身份认证所使用的认证协议(Authentication
Protocol)。
本文档定义了PPP可扩展的认证协议（Authentication Protocol）。
This document defines the PPP Extensible Authentication Protocol.
目录
1. 简介 ................................................. 2
1.1 规范的条件....................................... 2
1.2 术语............................................. 2
2. PPP可扩展认证协议(EAP) ..................... .......... 3
2.1 配置选项格式 ..................................... 4
2.2 数据包格式 ....................................... 6
2.2.1 Request和Response ......... ..................... 6
2.2.2 Success和Failure ............ ................... 7
3. 初始EAP Request/Response类型............................ 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
参考文献....................................................... 13
致谢 .......................................................... 14
主席地址 ..................................................... 14
作者地址 ...................................................... 14
完整的版权通告 ................................................ 15
1. 简介
为了在点到点链路上建立通信，在链路建立阶段PPP链路的每一端都必须首先发送LCP
数据包来对该数据链路进行配置。在链路已经建立起来后，在进入网络层协议之前，PPP提
供一个可选的认证阶段。
缺省认为，认证不是必需的。如果想要对链路进行认证，实现必须在链路建立阶段指定
认证协议配置选项（Authentication-Protocol Configuration）。
这些认证协议主要是由通过交换电路（switched circuits）或者拨号链路（也适用于专
用链路）连接到PPP网络服务器上的主机或者路由器使用。服务器可以使用这些主机或路由
器的身份（identification）来选择网络层协商的选项。
本文档定义了PPP可扩展认证协议（EAP）。链路建立阶段、认证阶段以及认证协议配置
选项在点到点协议（PPP，参考文献[1]）中定义。
1.1. 本规范的条件
本文档中出现的关键词必须（MUST）,不允许（MUST NOT）,必需（REQUIRED）,应该（SHALL）,
不应（SHALL NOT）,应该（SHOULD）,不应该（SHOULD NOT）,推荐（RECOMMENDED）,可以（可
能，MAY）,以及可选（OPTIONAL）,按RFC 2119(参考文献[6])解释。中译版本将对这些关键
词加粗并加上红色突出显示。
1.2. 术语
本文档频繁使用下面的术语：
认证者（authenticator）
链路要求进行认证的一端。在链路建立阶段的Configure-Request中认证者指
定了将要使用的认证协议。
对方（peer）
点到点链路的另一端；被认证者进行认证的那一端。
悄悄地丢弃（silently discard）
意味着实现不对数据包进行进一步处理而把它丢掉。实现应该提供对错误包括
被丢弃数据包的内容进行登记的能力，并且应该在一个统计计数器中记录下该
事件。
可显示的消息（displayable message）
解释为人类可读的字符串，并且不允许影响本协议的操作。消息的编码必须符
合UTF-8转换格式（参考文献[5]）。
2. PPP可扩展认证协议(EAP)
PPP可扩展认证协议(EAP)是PPP认证的一个通用协议，支持多种认证机制。EAP在链路
控制（LCP）阶段没有选择好一种认证机制，而把这一步推迟到认证(Authentication)阶段。
这样就允许认证者在确定某种特定认证机制之前请求更多的信息。这样做还允许使用一个“后
端”服务器来实际实现各种认证机制，PPP的认证者仅仅需要传送认证（pass through）认
证信息。
1. 在链路建立阶段完成后，认证者发送一个或多个Request来对对方进行认证。Request
中有一个type域表明请求的类型。Request中type的实例包括，Identity,
MD5-challenge, One-Time Passwords, Generic Token Card等等。MD5-challenge
类型与CHAP认证协议紧紧对应。典型情况下，认证者将发送一个最初的Identity请
求，然后是一个或多个请求认证信息的Request。但是，最初的Identity Request并
不是必需的，在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-Protocol Configuration
Option）的格式如下所示。传输时各域从左到右依次进行。
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
Length
4
Authentication-Protocol
C227 (十六进制) EAP
2.2. 数据包格式
档PPP帧中的protocol域表明协议类型为C227(PPP EAP)时，在PPP数据链路层帧的
Information域中封装且仅封装一个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 ...
+-+-+-+-+
Code
Code域为一个字节，标识了EAP数据包的类型。EAP的code值指定如下：
1 Request
2 Response
3 Success
4 Failure
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次作为
缺省值。人们可能希望某些特定情况下（例如，涉及到Token Cards的时候）超
时设定能更长些。另外，对方必须准备好在等待用户输入时悄悄丢弃所收到的重
传数据包。
Request和Response数据包的格式如下所示，传输时各域从左到右依次进行。
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.
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数据包不被确认，所以它们有可能丢失。对方
必须顾及到这种情况。对方可以用一个网络协议数据包（Network Protocol packet）
来作为可选的Success的暗示。同样，收到LCP Terminate-Request可以视为收到
Failure。
Success和Failure数据包的格式如下所示。传输时各域从左到右依次进行。
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 Success;
4 Failure.
Identifier
Identifier域为一个字节，辅助匹配Response应答。Identifier域必须与其正在应
答的Response域中的Identifier域相匹配。
Length
4
3.最初Request/Respons中的Type类型
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -