密的要害字 。这也可以在每个系统上支持更多的Name/Secret对 。
3.2.2Success和Failure
描述
假如在Response包中的Value等于期待的值，则验证者必须发送一个代码域是3（Success）
的CHAP包 。
假如在Response包中的Value不等于期待的值，则验证者必须发送一个代码域是4
（Failure）的CHAP包，并且应该终止链路 。
下面是Success和Failure包格式的总结 。各个域由左到右传输 。
0123
01234567890123456789012345678901
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CodeIdentifierLength
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Message...
- - - - - - - - - - - - -
代码
3 Success
4 Failure
标识符
标识符是一个字节，用于匹配request和replies 。标识符必须从引起这个响应的Response
包的标识符复制过来的 。
Message
Message域是零个或者多个字节，它的内容依靠实现者 。它被设计成可读的，不得影响
协议操作 。建议在Message中包含可显示的ASCII字符（32－126） 。扩展字符集的机制
是进一步研究的主题 。大小由长度域决定 。
安全考虑
安全问题是此备忘录的主要话题 。
PPP中的验证协议的交互操作很大程度上依靠于实现者 。在文档中通篇使用SHOULD表
明了这点 。
例如，一旦验证失败，有些实现者并不终止链路 。相反，实现者限制网络层的通信量的
类型构造子网，这样反过来答应用户有机会更新秘密或者发邮件给网络治理员说明问题 。
对于验证失败没有重试机制 。然而，LCP状态机可以在任何时候重新磋商验证协议，这
样就答应了一个新的重试 。建议任何用来为验证失败的计数器在成功验证前或者终止失败的
链路前不要重置 。
不要求验证是双向的或者在两个方向使用相同的协议 。在任一个方向上使用不同的协议
是完全可以接受的 。当然，这依靠于在磋商时指定的协议 。
在实践中，在每个PPP服务器上有一个数据库，它联合验证信息的用户名字 。不期望使
用多个方法验证非凡的命名用户 。这样使用户轻易受到攻击 。作为代替的，对于每一个命名
用户有一个准确的方法用来验证用户名 。假如一个用户在不同的环境下需要使用不同的验证
方法，那么应该采用截然不同的用户名，每一个准确代表一个验证方法 。
密码和其他的秘密应该保存在各自的端点以至于对它们的访问尽可能的受到限制 。理想
的，只能是为了完成验证而需要访问的过程可以访问秘密 。
应该使用一种机制分发秘密，这种机制能够限制处理秘密实体的数目 。理想的，没有通
过验证的人不会再得到秘密的内容 。使用SNMP安全协议[4]可以实现这个目标，但是这样的
机制不在这个规范的范围内 。
目前正在研究和试验其他的分发机制 。SNMP安全文档很好的概括了对网络的威胁 。
参考文献
[1]Simpson,W.,"ThePoint-to-PointProtocol(PPP)",RFC1331,
Daydreamer,May1992.
[2]Reynolds,J.,andJ.Postel,"AssignedNumbers",RFC1340,
USC/InformationSciencesInstitute,July1992.
[3]Rivest,R.,andS.Dusse,"TheMD5Message-DigestAlgorithm",MIT
LaboratoryforComputerScienceandRSADataSecurity,Inc.RFC
1321,April1992.
[4]Galvin,J.,McCloghrie,K.,andJ.Davin,"SNMPSecurity
Protocols",TrustedInformationSystems,Inc.,HughesLAN
Systems,Inc.,MITLaboratoryforComputerScience,RFC1352,
July1992.
致谢
此文档的一些内容来自RFC1172，它是由DrewPerkinsofCarnegieMellonUniversity和
RussHobbyoftheUniversityofCaliforniaatDavis共同制定的 。
