rfc2284.txt

283个中文RFC文档

   本章定义了用于Request/Response中的各种EAP Type的最初集合。更多的类型在以后的
文档中可以定义。Type域为一个字节，标识了EAP Request或Response数据包的结构。头3
种Type被认为特殊情形的Type，其余的Type定义了认证的交换流量。Nak类型仅对Response
数据包有效，不允许把它放在Request中发送。Nak类型必须仅在对使用认证Type的Request
作出响应时才发送。所有的EAP实现必须支持类型1-4,这些类型和类型5-6在本文档中定义，
以后的RFC将定义其它的类型。


Blunk & Vollbrecht          Standards Track                     [Page 8]


RFC 2284                          EAP                         March 1998


      1       Identity
      2       Notification
      3       Nak (Response only)
      4       MD5-Challenge
      5       One-Time Password (OTP) (RFC 1938)
      6       Generic Token Card

3.1.  Identity
描述

      Identify类型用来查询对方的身份。通常，认证者发送该类型作为最初的Request。
在期望与用户进行交互的场合还可以包括一条可选的可显示的消息以给对方作出提
示。必须对包含Type 1(Identity)的Request发送Response以作出响应。

        实现须知：对方可以通过用户输入获得Identity。建议在Identity无效或者认证
失败时认证者重发（retry）Identity Request以顾及到用户的打字错误。建议在
发送Failure应答来结束认证阶段之前最少重发Identity Request 3次。在发送新
的Identity Request之前可以发送一个Notification Request来暗示认证无效（可
选地，失败可以通过新的Identity中的消息来暗示）。
  
   Type

      1

   Type-Data

      该域可以包含一条可显示的消息。Response用该域来返回Identity。如果Identity
未知，该域长度应该为0。该域不允许以null作为终结符。该域的长度由
Request/Response中的Length域来决定，所以null是不必要的。









Blunk & Vollbrecht          Standards Track                     [Page 9]


RFC 2284                          EAP                         March 1998
3.2.  Notification
描述

      Notification Type可选地由认证者用来给对方传递一条可显示的消息。对方应该把
这条消息显示给用户，如果无法显示则纪录（log）该消息。使用它的目的是在某些紧
急情况下（imperative nature）提供一条确认通知（acknowledged notification）。
这样的例子包括带一个超时设定（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的响应。Authentication Type的值为大于等于4。Response
中包含了对方所希望使用的认证类型。

   Type

      3

   Type-Data

该域必须包含一个唯一的字节，表明希望的认证类型。


Blunk & Vollbrecht          Standards Track                    [Page 10]


RFC 2284                          EAP                         March 1998
3.4.  MD5-Challenge
描述

MD5-Challenge Type与PPP CHAP协议（参考文献[3]，制定了MD5算法）类似。更多
的实现细节应该参考PPP挑战握手认证协议RFC（参考文献[3]）。Request包含一个对
对方进行“挑战”的消息，必须对这样的Request发送一个Response以作出应答。

Response可以为Type 4（MD5-Challenge）或者Type 3(Nak)。Nak应答表明对方希
望的认证机制类型。所有的EAP实现必须支持MD5-Challenge机制。

   Type

      4

   Type-Data

      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 ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5.  One-Time Password (OTP)
描述
One-Time Password系统在“One-Time Password System（参考文献[4]）”中定义。
Request包含了一条包含一个OTP挑战的可显示的消息。必须对这样的Request发送
一个Response以作出应答。Response必须为Type 5(OTP)或Type 3(Nak)。Nak应答
表明了对方希望使用的认证机制类型。

   Type

      5
Blunk & Vollbrecht          Standards Track                    [Page 11]


RFC 2284                          EAP                         March 1998


   Type-Data

Type-Data域包含了该OTP挑战，为Request中的可显示消息。在Response中，该域
用来存放来自OTP字典（参考文献[4]）的6个词（word）,该消息不允许以null作
为终结符。该域的长度由Request/Reply数据包中的Length域决定。
3.6.  Generic Token Card
描述

Generic Token Card Type是为要求用户输入的各种Token Card实现定义的。Request
包含一条ASCII文本消息，Reply包含认证所必需的有关Token Card信息。典型地，
这些信息将是由用户从Token Card设备读取并以ASCII文本输入的信息。

   Type

      6

   Type-Data

Request中的Type-Data域包含了长度大于0的可显示的消息。消息的长度由Request
中的Length域决定，该消息不允许以null作为终结符。必须对包含Type为6（Generic 
Token Card）的Request发送一个Response以作为响应。Response包含了认证所必
需的Token Card信息，信息的长度由Response数据包中的Length域决定。
安全方面的考虑
   安全问题是本RFC的基本的主题。

PPP内各种认证协议的相互作用高度依赖于实现。

  例如，一旦认证失败，某些实现并不终止链路，相反，实现把网络层协议的流量限制为
某一个经筛选后的子集，这依次允许用户有机会更新密钥（secret）或者给网络管理员发送
邮件暗示出现了问题。




Blunk & Vollbrecht          Standards Track                    [Page 12]


RFC 2284                          EAP                         March 1998

    不提供失败认证的重试。但是，LCP状态机可在任意时刻协商认证协议，这就允许了新
的尝试。建议用于认证的计数器直到成功认证，或者随后终止该失效链路后才进行复位
（reset）。

   不要求认证是双向的，也不要求两个方向使用同一个协议。在每个方向是用不同的协议将
是可很合理的。这当然依赖于每个方向所使用的特定的协议

   在实践中，在每个PPP服务器内部或与之相关，事先不预期对特定名字的用户使用多种方
法来进行认证。如果这样做将使用户在一个可选认证协议的集合中当协商使用了最不安全的
认证类型（如使用PAP而不是EAP）时容易受到攻击。相反，对于每一个命名用户，应该表
明恰好只有一种方法对用户进行认证。如果一个用户需要在不同的环境下使用不同的认证方
法，应该使用不同的身份（identities），每一个身份对应唯一的认证方法。

参考文献
   [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.







Blunk & Vollbrecht          Standards Track                    [Page 13]


RFC 2284                          EAP                         March 1998
致谢
   本协议从Dave Carrel的AHA草案（即PPP CHAP协议，参考文献[3]）中获得灵感，Bill 
Simpson提供了本文当通篇使用的文档样板。Al Rubens(Merit)也提供了很有价值的反馈信
息。
主席地址
   工作组可以通过现任主席联系:

   Karl F. Fox
   Ascend Communications, Inc.
   655 Metro Place South, Suite 370
   Dublin, Ohio  43017

   EMail: [e-mail]
   Phone: [phone]
   Fax:   [phone]

作者地址

   Larry J. Blunk
   Merit Network, Inc.
   4251 Plymouth Rd., Suite C
   Ann Arbor, MI  48105

   EMail: [e-mail]
   Phone: [phone]
   FAX:   [phone]

   John R. Vollbrecht
   Merit Network, Inc.
   4251 Plymouth Rd., Suite C
   Ann Arbor, MI  48105

   EMail: [e-mail]
   Phone: [phone]
   FAX: [phone]
Blunk & Vollbrecht          Standards Track                    [Page 14]


RFC 2284                          EAP                         March 1998
完整的版权通告
Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.










Blunk & Vollbrecht          Standards Track                    [Page 15]
RFC 2284  PPP Extensible Authentication Protocol,EAP                     PPP可扩展认证协议


1
RFC文档中文翻译计划