rfc1994.txt

很多RFC的中文文档

      长度字段两字节，指示CHAP包的长度，包括代码、长度和数据字段。超出
      长度的字节应该视为数据链路层填充，接收方应该忽略。

   数据  Data

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

4.1.  挑战和应答
   描述

      挑战包是CHAP的开始，认证者必须传送代码字段为1的CHAP包，其他挑战
      数据包必须在有效应答数据包成功接收之后或者可选重试计数器计满后发
      送。

      为了确保连接没有被更改，挑战包也可以在NLP阶段的任何时候发送。

      对端应该随时为认证阶段和NLP阶段的挑战做好准备，任何时候收到挑战
      包，对端都必须传送代码字段为2（应答）的CHAP数据包。

      无论何时，如果收到应答包，认证者都必须把应答值和自己计算的预期值
      比较，基于这种比较，认证者必须发送成功（Success）或者失败
      （Failure）CHAP包。

         注：由于成功包可能丢失，认证者在NLP阶段中必须允许重复的应答包，
         为了发现更改的名字和密钥，收到具有当前挑战标识符的应答包必须返
         回与先前挑战同样的响应代码（消息部分可能不相同），在任何其他阶
         段收到的任何应答包必须静静丢弃。

         如果“失败包”丢失，认证者终止了链路，那么可以由LCP的“终止请
         求”和“终止应答”来指示认证失败。

   挑战包和应答包的格式如下，字段从左到右传输。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   代码  Code

      1  挑战 Challenge;

      2  应答 Response.

   标识  Identifier

      标识字段一字节，每次发送挑战都必须要改变标识字段的值。

      应答标识必须由响应的挑战标识字段拷贝得来。

   值大小  Value-Size

      一字节长，指示“值”字段的长度。

   值  Value

      值字段一个或者多个字节，首先传输最高位。

      挑战值是可变字节流，上文已经叙述了挑战值唯一性的重要性和它与密钥
      之间的关系。挑战值必须在每次发送挑战时都要改变。挑战值的具体长度
      由产生它的方法而定，独立于所用的哈希算法。

      应答值由标识串接密钥串接挑战值然后经过哈希运算得出，其长度由所用
      的哈希算法决定（对于MD5，为16字节）。

   名字  Name

      名字字段一个或多个字节，代表传输数据包的系统的标识，字段内容没有
      限制，如，可以是ASCII字串，或者是全局唯一的ASN.1标识，名字不应该
      是NUL或者CR/LF终止符。其长度由长度字段确定。

4.2.  成功与失败
   描述

      如果接收到的应答值等于预期值，那么认证者必须传送代码字段为3（
      成功）的CHAP数据包。

      如果接收到的应答值不等于预期值，那么认证者必须传送代码字段为4
      （失败）的CHAP数据包，并且应该终止链路。

   成功和失败包格式如下所示，字段从左到右传输。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   代码  Code

      3   成功 Success;

      4   失败 Failure.

   标识  Identifier

      标识字段一字节，辅助匹配应答和响应，从响应的应答标识字段拷贝得
      来。

   消息  Message

      消息字段是一个或者多个字节，其内容与具体实现无关，最好可以直接
      阅读，但是不得影响协议操作，推荐使用可显示的ASCII字符（从32到
      126）。扩展到其他字符集机制的研究留在以后进行，其长度由长度字段
      确定。


安全考虑

   安全问题是该RFC的主题。

   PPP认证协议的交互作用依赖于具体实现，本文通篇的“应该”字样已经暗示了
   这一点。

   例如，对于认证失败，一些实现可能并不终止链路，而只是限制网络层协议的
   流量，允许用户更新密钥或向网络管理员发送邮件表示有问题发生。

   对于失败的认证不做二次审定，然而，LCP状态机可以在任何时候重新协商认证
   协议，因而允许新的尝试，推荐让认证失败计数器只有在成功认证之后或者终
   止失败链路之后才重新设置。

   不需要双工认证，也不需要在两个方向上使用同一个认证协议，在不同的方向
   上使用不同的认证协议完全是可以接受的，当然，这都要根据具体协议协商而
   定。

   两个方向上的密钥不应该相同，否则，攻击者可以重放对端的挑战、接受经过
   运算的应答以及使用该应答来进行认证等。

   实际上，对于每个PPP服务器，有一个关联用户名和认证信息（密钥）的数据
   库，不要让特定用户由多个认证方法来认证，因为这会使攻击者容易选择一
   个安全性较低的认证方法入侵（如，用PAP，而不是CHAP）。如果使用了相同
   的密钥，PAP便会暴露CHAP所使用的密钥。

   对于每一个用户名，应该指示一种特定的认证方法，如果用户在不同的环境下
   使用不同的认证方法，那么他应该在不同的环境下使用不同的用户名，每个用
   户名标识一个认证方法。

   口令和其他其他密钥应该分别存在每一端，以便尽可能限制访问，理想的做法
   是，密钥只能由执行认证的进程访问。

   密钥的发布机制应该尽量限制处理密钥的实体，理想的做法是，非授权人不应
   该得到密钥的半点信息，这些机制的讨论产出本文的范围。

鸣谢
   David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
   handshake at SDC when designing one of the protocols for a "secure"
   network in the mid-1970s.  Tom Bearson built a prototype Sytek
   product ("Poloneous"?) on the challenge-response notion in the 1982-
   83 timeframe.  Another variant is documented in the various IBM SNA
   manuals.  Yet another variant was implemented by Karl Auerbach in the
   Telebit NetBlazer circa 1991.

   Kim Toms and Barney Wolff provided useful critiques of earlier
   versions of this document.

   Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
   Steve Kent, for their extensive explanations and suggestions.  Now,
   if only we could get them to agree with each other.

参考文献

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, DayDreamer, July 1994.

   [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
         1700, USC/Information Sciences Institute, October 1994.

   [3]   Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
         MIT Laboratory for Computer Science and RSA Data Security,
         Inc., RFC 1321, April 1992.



Contacts

   Comments should be submitted to the [e-mail] mailing list.
   This document was reviewed by the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  The working
   group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio 43221

          [e-mail]
          [e-mail]


   Questions about this memo can also be directed to:

      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          [e-mail]
          [e-mail] (preferred)
RFC1994——PPP Challenge Handshake Authentication Protocol (CHAP)
PPP挑战握手认证协议(CHAP)


10
RFC文档中文翻译计划