精通
英语
和
开源
,
擅长
开发
与
培训
,
胸怀四海
第一信赖
锐英源精品开源心得,转载请注明出处:锐英源,www.wisestudy.cn,孙老师作品,联系电话13803810136。
组织:中国互动出版网(http://www.china-pub.com/)
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
译者:王奎(pywang wangtianzhi@263.net)
译文发布时间:2001-12-28
版权:本翻译文档可以用于非商业用途自由转载,但必须保留本文档的翻译及组织信息。
Network Working Group B. Lloyd
Request for Comments: 1334 L&A
W. Simpson
Daydreamer
October 1992
PPP 身份验证协议
(RFC1334——PPP Authentication Protocols )
备忘录状态
此RFC 为internet community详细说明了 IAB 标准跟踪协议,并且请求讨论和建议以便改进。请参考IAB Official Protocol Standards 的当前版本,确保这个协议陈述和状态的标准化。此备忘录的分发不受限制。
摘要
点到点协议(the Point-to-Point Protocol)提供了一种在点到点链路上封装网络层协议信息的标准方法。PPP 也定义了可扩展的链路控制协议(Link Control Protocol),它(Link Control Protocol)使用验证协议磋商在链路上传输网络层协议前验证链路的对端。
这个文档定义了两种验证协议:密码验证协议(the Password Authentication Protocol)和挑战-握手验证协议(the Challenge-Handshake Authentication Protocol)。此RFC是IETF(the Internet Engineering Task Force)的PPP协议工作组的成果。关于这个备忘录的建议请提交给:ietf-ppp@ucdavis.edu邮件列表。
目录
1. 介绍
1.1要求说明书
1.2术语
2. 密码验证协议
2.1 配置选项格式
2.2 包格式
3.1配置选项格式
3.2包格式
安全考虑
参考文献
致谢
主席地址
作者地址
完整版权说明
致谢
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
类型
3
长度
4
验证-协议
c023(对于PAP)
数据
没有数据域
代码
代码域是一个字节,代表PAP包的类型。PAP代码分配如下:
1 Authenticate-Request
2 Authenticate-Ack
3 Authenticate-Nak
标识符
标识符是一个字节,用于匹配请求和响应。
长度
长度域是两个字节,代表PAP包的长度,包括代码域,标识符和数据域。超出长度域指定的字节被认为是数据链路层的填料,在接收端应该忽略掉。
数据
数据域是零个或多个字节。数据域的格式由代码域决定。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
代码
1 Authenticate-Request。
标识符
标识符是一个字节,用于匹配请求和回应。每次发送一个Authenticate-Request包,标识符域必须改变。
Peer-ID-Length
Peer-ID-Length域是一个字节,代表Peer-ID域的长度。
Peer-ID
Peer-ID域是零个或多个字节,代表被验证端的名字。
Passwd-Length
Passwd-Length域一个字节,代表Password域的长度。
Password
Password域是零个或者多个字节,是用来验证的密码。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
代码
2 Authenticate-Ack;
3 Authenticate-Nak
标识符
标识符域是一个字节,用于匹配请求和回应。此域必须从引起这次回应的Authenticate-Request包标识符域复制过来的。
Msg-Length
Msg-Length域是一个字节,代表Message域的长度。
Message
Message域是零个或者多个字节,并且它的内容依靠于实现者。它是可读的,不得影响协议的操作。建议在Message中包含可显示的ASCII字符(32-126)。扩展字符集的机制是进一步研究的主题。
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]
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域决定。
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对。
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: (916) 676-1147
EMail: brian@lloyd.com
作者地址
关于此备忘录的问题可以直接联系:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.edu
完整版权说明
Copyright (C) The Internet Society (2001). All Rights Reserved.
只要在所有复本与推导性工作中包含上面的版权声明和这段文字,就可以全部地或者部分地且没有任何限制地复制这篇文档与其译本以及把它提供给其它文档,同样也可以准备、复制、出版与发行推导性工作,而且需要评述此推导性工作否则就得解释它,或者辅助此推导性工作的实现。然而,此文档本身不可以做任何修改,诸如删除版权声明或者因特网社区或其它因特网组织的涉及,除了当需要开发因特网标准的目的时之外且在此种情况下必须遵循在因特网标准过程中定义的版权程序,或者除了当要求把它译成其它语言(即不是英文)的目的时之外。
在上面准予的有限的许可是永久性的,而且因特网社区或者它的继承者或指派者都将不会废除它。
在此包含的这篇文档与信息是基于“AS IS”而提供的,并且因特网社区与因特网工程任务组织声明了所有的授权、表达或含义,且包含对任何授权的限制,比如这里信息的使用不会违反任何授权或者出于特殊目的的商品性或适切性的任何含蓄授权。
致谢
感谢因特网社区当前为RFC编辑提供了功能基金。