rfc1134.txt

很多RFC的中文文档

	Challenge值应该符合两个标准：唯一性和不可预测性。每一个challenge值应该是唯一
的，因为使用与相同秘密联系的challenge执的副本可以让攻击者利用前一个截获得响应包响
应。由于希望可以使用相同的秘密在不同区域中验证服务器，challenge 应该具有全局和暂时
的唯一性。每一个challenge值也应该是不可预测的，否则攻击者欺骗对端响应一个可预测的
未来challenge，然后用这个响应伪装成对端欺骗验证者。尽管象CHAP这样的协议不能够防
止实时的窃听攻击，但是使用唯一的和不可预测的challenge可以防止一定范围的能动攻击。
	关于唯一性来源和产生分歧概率的讨论包含在Magic-Number配置选项中。
3.1配置选项格式
下面是Challenge-Handshake 验证协议使用的Authentication-Protocol 配置选项格式的总
结。各个域由左到右传输。

    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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Algorithm   |
   +-+-+-+-+-+-+-+-+

类型
3
长度
5
Authentication-Protocol
c223 Challenge-Protocol Authentication Protocol
算法
算法域是一个字节，代表所使用的one-way 哈希算法。CHAP算法域的最新值在最近的
“Assigned Numbers”RFC[2]中有详细说明。当前的值分配如下：
0-4	unused(保留)
5	MD5[3]
3.2包格式
CHAP包封装在PPP数据联络层帧的信息域中，它的协议域是c223。下面是CHAP包格
式的总结。各个域由左到右传输。

    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 ...
   +-+-+-+-+

代码
代码域是一个字节，代表CHAP包的类型。CHAP代码分配如下：
1	Challenge
2	esponse
3	Success
4	Failure

标识符
标识符是一个字节，用于匹配challenge,response和replies。
长度
长度域是两个字节，代表CHAP包的长度，包括Code,Identifier,Length和Data。超出这
个长度的字节应该被认为是链路层的填料，在接收端应该被忽略。
数据
数据域是零个或者多个字节。它的格式由code域决定。
3.2.1 Challenge 和 Response
	描述
	Challenge包用来启动CHAP。验证者必须发送一个代码域是1的CHAP包。一直到接收
到有效的响应包或者重试计数器超时，必须不停发送Challenge包。
	在网络层协议阶段的任一个时间也可以发送Challenge包确保连接没有改变。
	在验证阶段和网络层协议阶段对端应该期待Challenge包。无论何时接到Challenge包，
对端必须发送一个代码域是2的CHAP包。
	无论何时验证者接到一个Response包，则它比较Response值和自己计算的期待值是否
相同。在比较的基础上，验证者必须发送一个Success 或者Failure包。
	实现注意：因为Success包有可能丢失，验证者必须在完成验证阶段后允许重复的
Response包。为了防止名字和秘密的泄漏，在验证阶段后，任何具有当前Challenge标识符的
Response包必须返回相同的响应代码。在其他阶段接到的任何Response包必须被静静地丢掉。
	如果Failure包丢失和验证者终止链路，则LCP的Terminate-Request包和Terminate-Ack
包提供了另一种代表验证失败的方法。
	下面是Challenge 和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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	代码
	1	Challenge
2	Response

	标识符
	标识符是一个字节，每发送一个Challenge包标识符必须改变。Response包的标识符必
须从引起这个响应的Challenge包的标识符复制过来的。
	Value-Size
	此域是一个字节，代表Value域的长度。
	Value
	Value域是一个或多个字节。最重要的字节先传输。
	Challenge Value是一个可变的字节流。上面讲述了Challenge Value唯一性的重要性以及
它和秘密的关系。每次发送Challenge 包必须改变Challenge Value。Challenge Value的长度依
靠于产生字节所使用的方法，独立于所用的哈希算法。
	Response Value是在字节流上用单向哈希算法计算得出的，字节流包含Identifier,后面是
secret,再后面是Challenge Value。Response Value的长度依靠于所用的哈希算法（对于MD5
是16个字节）。
	名字
	名字域是一个或多个字节，代表发送包的系统的标识。对这个域的内容没有限制。例如，
它可以是ASCII字符串或者是ASN.1语法中的全局唯一标识。名字不应该是以NULL 或者
CR/LF结尾的。大小由长度域决定。
	因为CHAP可以验证许多不同的系统，所以名字域的内容可以用作在秘密数据库查询秘
密的关键字。这也可以在每个系统上支持更多的Name/Secret对。
3.2.2 Success 和 Failure
	描述
	如果在Response包中的Value等于期待的值，则验证者必须发送一个代码域是3（Success）
的CHAP包。
	如果在Response包中的Value不等于期待的值，则验证者必须发送一个代码域是4
（Failure）的CHAP包，并且应该终止链路。
	下面是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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

	代码
	3	Success
	4	Failure
	
	标识符
标识符是一个字节，用于匹配request和replies。标识符必须从引起这个响应的Response
包的标识符复制过来的。
Message
Message域是零个或者多个字节，它的内容依靠实现者。它被设计成可读的，不得影响
协议操作。建议在Message中包含可显示的ASCII字符（32－126）。扩展字符集的机制
是进一步研究的主题。大小由长度域决定。


安全考虑
	安全问题是此备忘录的主要话题。
	PPP中的验证协议的交互操作很大程度上依靠于实现者。在文档中通篇使用SHOULD表
明了这点。
	例如，一旦验证失败，有些实现者并不终止链路。相反，实现者限制网络层的通信量的
类型构造子网，这样反过来允许用户有机会更新秘密或者发邮件给网络管理员说明问题。
	对于验证失败没有重试机制。然而，LCP状态机可以在任何时候重新磋商验证协议，这
样就允许了一个新的重试。建议任何用来为验证失败的计数器在成功验证前或者终止失败的
链路前不要重置。
	不要求验证是双向的或者在两个方向使用相同的协议。在任一个方向上使用不同的协议
是完全可以接受的。当然，这依靠于在磋商时指定的协议。
	在实践中，在每个PPP服务器上有一个数据库，它联合验证信息的用户名字。不期望使
用多个方法验证特殊的命名用户。这样使用户容易受到攻击。作为代替的，对于每一个命名
用户有一个准确的方法用来验证用户名。如果一个用户在不同的环境下需要使用不同的验证
方法，那么应该采用截然不同的用户名，每一个准确代表一个验证方法。
	密码和其他的秘密应该保存在各自的端点以至于对它们的访问尽可能的受到限制。理想
的，只能是为了完成验证而需要访问的过程可以访问秘密。
	应该使用一种机制分发秘密，这种机制能够限制处理秘密实体的数目。理想的，没有通
过验证的人不会再得到秘密的内容。使用SNMP安全协议[4]可以实现这个目标，但是这样的
机制不在这个规范的范围内。
	目前正在研究和试验其他的分发机制。SNMP安全文档很好的概括了对网络的威胁。

参考文献

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
       Daydreamer, May 1992.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [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.

   [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
       Protocols", Trusted Information Systems, Inc., Hughes LAN
       Systems, Inc., MIT Laboratory for Computer Science, RFC 1352,
       July 1992.

致谢
	此文档的一些内容来自RFC1172，它是由 Drew Perkins of Carnegie Mellon University和
Russ Hobby of the University of California at Davis共同制定的。
	特别感谢Dave Balenson, Steve Crocker and, James Galvin,和Steve Kent，感谢他们的广泛
的解释和建议。
主席地址
	可以通过现任主席联系工作组。
	Brian Lloyd
      Lloyd & Associates
      3420 Sudbury Road
      Cameron Park, California 95682

      Phone: [phone]

      EMail: [e-mail]


作者地址
	关于此备忘录的问题可以直接联系：
      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      P O Box 6205
      East Lansing, MI  48826-6205

      EMail: [e-mail]

完整版权说明
   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   只要在所有复本与推导性工作中包含上面的版权声明和这段文字，就可以全部地或者
部分地且没有任何限制地复制这篇文档与其译本以及把它提供给其它文档，同样也可以准备、
复制、出版与发行推导性工作，而且需要评述此推导性工作否则就得解释它，或者辅助此推
导性工作的实现。然而，此文档本身不可以做任何修改，诸如删除版权声明或者因特网社区
或其它因特网组织的涉及，除了当需要开发因特网标准的目的时之外且在此种情况下必须遵
循在因特网标准过程中定义的版权程序，或者除了当要求把它译成其它语言（即不是英文）
的目的时之外。
在上面准予的有限的许可是永久性的，而且因特网社区或者它的继承者或指派者都将不
会废除它。
在此包含的这篇文档与信息是基于“AS IS”而提供的，并且因特网社区与因特网工程任
务组织声明了所有的授权、表达或含义，且包含对任何授权的限制，比如这里信息的使用不
会违反任何授权或者出于特殊目的的商品性或适切性的任何含蓄授权。
致谢
感谢因特网社区当前为RFC编辑提供了功能基金。


RFC1334——PPP Authentication Protocols                                     PPP 身份验证协议


1
RFC文档中文翻译计划