中文rfc2284.txt

本程序为在linux下实现FTP传输文件的实现

长度 Length
长度字段占两个字节，用于表示EAP报文的长度，包括代码、标识、长度和数据字段。超出长度的字节应该视为链路层的填充字节，接收方应该忽略。

数据 Data
数据字段是零个或多个字节，数据字段格式由代码字段确定。

请求和应答
描述
请求报文由认证方发向对端。每一个请求报文都有一个类型字段用来表示请求方在请求什么信息。认证方必须向对端发送一个EAP报文并把其中的代码（CODE）字段设为1（REQUEST）。认证方必须在收到一个有效的应答报文或者在一个可选的计数器计满后再发送其他的请求报文。重传的请求报文中的标识（ID）字段必须保持不变，以便区分重传的请求报文和新的请求报文。数据字段的内容取决于类型字段的值。对端每收到一个请求报文后必须回应一个报文。只有在收到请求报文的情况下才发送应答报文，请求报文没有超时重传的情况。应答报文中标识（ID）字段必须和请求报文中的标识字（ID）段相匹配。
1      实现注意事项：由于在认证过程经常涉及到用户输入，必须采取合适的重传策略和超时时间。建议缺省情况下采用6秒的超时计数器，最大重传次数设为10。在某些情况下可以延长超时时间（如涉及到令牌卡的情况）。另外，对端在等待用户输入的时候必须静静地丢弃收到的重复的请求报文。
请求和应答报文的格式如下所示，字段的传输顺序是从左向右。
    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  请求
     2 . 应答

标识 Identifier
标识字段占一个字节。由于等待应答超时而重传的请求报文的标识字段必须保持不变。新的（不是重传的）请求报文必须改变标识字段。如果对端在收到重复的请求报文之前已经发送过针对该报文的应答报文，它必须重新发送已发送的应答报文。如果对端收到重复的请求报文之前还没有发送针对该报文的应答报文，它必须静静地丢弃重复的请求报文。	

长度  Length
长度字段占两个自己，用于表示EAP报文的长度，包括代码、标识、长度和数据字段。超出长度的字节应该视为链路层的填充字节，接收方应该忽略。

类型  Type
类型字段占一个字节。这个字段表示请求或者应答的信息类型。每一种EAP  请求或者应答报文必须指定并且也只能指定一种类型。一般情况下，应答报文中的类型字段和请求报文中的类型字段是相同的，但是还存在一种为NAK的应答类型用来表示对端不接受请求报文中的信息类型。当对端用NAK报文应答请求报文的时候，对端可以同时提供一个它所支持的的信息类型供认证者选择。在本文的随后章节中有对类型的详细定义。

类型数据  Type-Data
类型数据字段随着请求或应答报文中的类型字段变化而变化。

成功和失败
描述
成功报文是认证者向发送给对端用来指示认证成功的。认证者必须传送代码字段为3（成功）的EAP报文。
如果不能认证对端（对应于一个或多个请求报文收到不可接受的应答），认证者必须发送代码字段为4（失败）的EAP报文。认证者可能会在发送失败的应答报文之前再发起请求报文来避免用户输入错误的情况。
1      实现注意事项：由于成功和失败报文不需要确认，它们有可能会丢失。对端必须允许这种情况的发生。对端可以把网络协议报文作为对认证成功的指示；同样也可以把LCP的结束请求报文作为对认证失败的指示。
成功和失败报文的格式如下所示，字段的传输顺序从左向右。
   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  代表成功
      4  代表失败

标识 Identifier
标识字段占一个字节，用于和对端的应答报文之间的匹配。成功和失败报文中的标识字段必须和它所对应的应答报文中的标识字段相匹配。

长度   Length
      4
1 EAP请求/应答类型
这一节中主要定义了在请求和应答的交互过程中所使用到的EAP类型集，后续的文档可能会再扩展其他的类型。类型字段占一个字节，它标识了EAP请求和应答报文的结构。前三中类型有其特别的适用情况，后两种类型适用于认证信息的交互。NAK类型只适用在应答报文中，而绝不能出现在请求报文中。所有的EAP实现必须支持类型1到4，本文中定义了这些类型以及类型5、6。后续的RFC可能会定义一些其他的类型。
      1       标识 Identity
      2       通知 Notification
      3       否定 Nak (只用在应答中)
      4       MD5挑战字  MD5-Challenge
      5       一次密码      One-Time Password (OTP) (RFC 1938)
      6       通用令牌卡  Generic Token Card

1.1 标识 Identification
描述
标识类型用来询问对端的身份。一般情况下，认证者会首先发起这种类型的请求，这种请求报文可选择包含一个可显示的提示信息，用于和终端用户间的交互。对这种请求报文的应答报文的类型值也必须设为1。
1     实现注意事项：对端可能通过用户的输入得到身份值，因此建议认证者在收到错误的身份值或者认证失败的身份值后重新发送标识类型的请求报文，以应付用户输入错误的情况。并且建议认证者至少在尝试三次失败以后才向对端发送一个失败（Failure）的应答报文来终止认证阶段。认证者可以在重新发送标识（ID）请求报文之前发送一个通知（Notification）报文用于提示对端认证错误（也可以把这些提示信息放在重新发送的标识（ID）请求报文的提示信息中）。
类型   Type
      1
类型数据   Type-Data
在请求报文中这个字段可以包含一段可显示的提示信息；而在应答报文中这个字段包含对端的身份（ID），如果对端还不知道自己的身份，那么在长度（Length）字段中指示标识（ID）字段的长度应该为零。在该字段中的字符串不需要用空字符（NULL）结束，因为长度字段中的值就标明了字符串的长度。
1.2 通知 Notification
描述
通知类型经常用于认证者向对端传送一个可显示的字符串。对端应该把这个字符串显示给用户，如果不能显示的话也应该记录下来。它主要用于向对端发一些通知，比如提示密码将要超期、OTP的顺序号码接近零以及认证失败的警告等。在大部分情况下不需要这个类型。
类型 Type
     2
类型数据 Type-Data
请求报文中的类型数据字段包含一段长度大于0字节的可显示的字符串。字符串的长度由请求报文中的长度字段的值来决定，并且字符串不需要用空字符（NULL）结束。对端收到这种类型的请求报文以后不管怎么处理其中的通知信息都必须立刻发送一个类型值为2（通知）的应答报文，并且应答报文的类型数据字段的长度应该为零。
1.3 否定 Nak
描述
否定类型只应该出现在应答报文中，用来表示对端不接受请求报文中的认证信息类型。认证信息类型是指类型值大于等于4的信息类型。否定类型的应答报文中可以同时提供一个对端所期望的认证信息类型。
类型  Type
      3
类型数据 Type-Data
这个字段必须包含一个字节用来向认证者提供对端所期待的认证信息类型。
1.4 MD5挑战字
描述
MD5挑战字和PPP的CHAP[3]协议中的挑战字类似，使用MD5算法。CHAP的具体实现细节应该查阅PPP挑战握手认证协议的RFC[3]。在类型为MD5挑战字的请求报文中包含一个“挑战”信息，对端收到这个请求报文后必须发送一个应答报文，应答报文的信息类型可以是4（MD5挑战字）或者3（否定），在NAK应答报文中对端同时也标明了它所期待的认证机制的类型值。所有的EAP实现必须支持MD5挑战字算法。
类型 Type
      4
类型数据  Type-Data
类型数据的内容如下所示。至于如何使用其中的这些字段请参阅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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.5 一次密码（OTP）
描述
一次密码系统在文献[4]中定义。请求报文中包含一个可显示的信息作为一次密码（OTP）的挑战字。对端收到这种请求报文后必须发送一个应答报文，应答报文的类型值也必须设为5（OTP）或者3（NAK）,在NAK应答报文中对端同时也标明了它所期待的认证机制的类型值。
类型  Type
      5
类型数据  Type-Data
在请求报文中，类型数据字段包含一个可显示的信息作为一次密码（OTP）的挑战字。在应答报文中类型数据字段用于填充从OTP目录中得到的6个字。该字段不需要用空字符（NULL）结束，该字段的长度可以从报文的长度字段中计算得到。
1.6 通用令牌卡
描述
通用令牌卡类型适用于各种需要用户输入信息的令牌卡的实现。在请求报文中包含一段ASCII文本信息，而应答报文中包含用于认证的令牌卡信息。典型的，令牌卡信息是由用户从令牌卡设备上读取得到并作为ASCII文本输入的。
类型  Type
      6
类型数据 Type-Data
在请求报文中，该字段包含一段长度大于零的可显示的信息，它的长度可以从报文的长度字段中计算得到，因此该字段不需要用空字符（NULL）结束。对端收到这种请求报文以后必须发送一个类型值为6（通用令牌卡）的报文作为应答，应答报文中包含用于认证的令牌卡信息，通用它的长度也可以从报文的长度字段中计算得到。

1 安全考虑
安全主题是该RFC的主题。
PPP的认证交换过程依赖于实现。例如在有些实现中认证失败就直接终止链路，而在另外一些实现中并不终止链路，而只是限制和滤除网络层的流量从而允许用户更改密钥或者发邮件通知管理员。
虽然没有如何处理认证失败以后的重新认证的规定，但由于LCP的状态机可以随时重新协商认证协议，然后开始一个新的认证过程，因此建议用于认证失败的各种计数器只有在认证成功或者链路终结以后才重新设置。
并没有要求认证一定要在两个方向上进行，也没有要求在两个方向上使用同样的认证协议。我们完全可以接受在两个方向上使用不同的认证协议，当然，这依赖于协商的结果。
实际上，一个PPP服务器不应该使用多种认证协议来认证一个特定的用户。因为这样容易使用户在使用安全性较低的认证协议（如PAP，而不是EAP）的时候受到攻击。    对于每一个用户名，应该指示一种特定的认证方法，如果用户在不同的环境下使用不同的认证方法，那么他应该在不同的环境下使用不同的用户名，每个用户名对应一个认证方法。

1 参考文献
[1]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[3]  Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[4]   Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, May 1996.
[5]  Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement  Levels", RFC 2119, March 1997.

1 鸣谢
撰写本文的很多灵感都来源于Dave Carrel的AHA草案和PPP的CHAP认证协议。 Bill Simpson提供了本文所使用的书写模板。 Al Rubens为本文提出了很多有价值的建议。