RFC1994【PPP CHAP】中文翻译
1.简介
为了在点到点链路上建立通信，PPP链路的每一端在链路建立阶段必须首先发送LCP包进行数据链路配置。链路建立之后，PPP提供可选的认证阶段，可以在进入NLP阶段之前实行认证。
缺省情况下，认证并非是强制执行的，如果需要链路认证，PPP实现必须在链路建立阶段指定“认证协议配置选项”。
这些认证协议主要用于主机和路由器，这些主机和路由器一般通过交换电路线或者拨号线连在PPP网络服务器上，但是也可以通过专线实现。服务器可以用主机或路由器的连接身份来作为网络层协商的选项。
本文定义了PPP认证协议。链路建立阶段和认证阶段以及“认证协议配置选项”都已经在PPP【1】中定义。
1.1.要求规范
在本文中，用以下几个词表示规范描述要求，这几个词经常用大写标明。
MUST “必须”，也就是形容词“必需的”，意思是该项是本规范的绝对要求。MUST NOT “不得”，意思是该项是本规范所绝对禁止的。
SHOULD “应该”，也就是形容词“推荐的”，意思是在某些场合可能由于某种原因忽略该项，但是协议的完全实现必须能够理解该项，在决定其他方式之前要经过仔细考虑。MAY “可以”，也就是形容词“可选的”，意思是该项可以作为可选集使用，不包含该选项的协议实现必须能够和包含了该选项的实现交互协作。
1.2.术语
本文频繁使用的术语包括以下几个：
Authenticator（认证者）
链路要求认证的一端，认证者在链路建立阶段的Configure-Request中指定认证协议。Peer（对端）
点到点链路的另一端；由认证者认证的一端。
silently discard（静静丢弃）
协议实现直接丢弃数据包，不作进一步处理。实现应该提供记录错误的能力——包括被静静丢弃的包的内容，还应该在统计计数器里记录事件。
2.挑战握手认证协议
挑战握手认证协议（CHAP）通过三次握手周期性的认证对端的身份。这在初始链路建立时完成，并且可以在链路建立之后的任何时候重复进行。
1.链路建立阶段结束之后，认证者向对端发送“挑战”消息。
2.对端用经过“单向哈希函数”计算出来的值做应答。
3.认证者根据它自己的预期哈希值的计算来检查应答，如果值匹配。认证得到承认；否则，连接应该终止。
4.经过一定的随机间隔，认证者发送一个新的挑战给对端，重复1到3的步骤。2.1. 优点
通过递增改变的标识符和可变的挑战值，CHAP防止了重放攻击。重复挑战限制了对单个攻击的暴露时间。认证者控制挑战的频度。
该认证方法依赖于只有认证者和对端知道的“密钥”。该密钥不会通过该链路发送。
虽然该认证是单向的，但是在两个方向都进行CHAP协商，同一密钥可以很容易的实现交互认证。
由于CHAP可以用在许多不同的系统认证中，因此可以用NAME字段作为索引，以便在一张大型密钥表中查正确的密钥。这样也可以在一个系统中支持多个NAME/密钥对，在会话中随时改变密钥。
2.2.缺点
CHAP要求密钥以明文形式存在，通常的那种不可回复加密口令的数据库无法使用。
在大型设备中不适用，因为每个可能的密钥由链路的两端共同维护。
注：为了避免在网络的其他链路上发送密钥，推荐在中心服务器中检查挑战和应答，而不是在每一个接入服务器中，否则，密钥最好发送到可回复加密格式的服务器中。无论那种情况都需要信任关系，信任关系的讨论超出本文的范围。
2.3.设计要求
CHAP算法要求密钥长度必须至少是一字节，至少应该不易让人猜出。密钥最好至少是哈希算法（16字节，MD5）所选用的哈希值的长度，如此可以保证密钥不易受到穷搜索攻击。
所选用的哈希算法，必须使得从已知挑战值和应答值来确定密钥在计算上是不可行的。
每一个挑战值应该是唯一的，否则在同一密钥下，重复挑战值将使攻击者能够用以前截获的应答值响应挑战。由于希望同一密钥可以用于地理上分散的不同服务器的认证，因此挑战应该全局临时唯一。
每一个挑战值也应该是不可预计的，否则攻击者可以欺骗对端，让对端响应一个预计的的挑战值，然后用该响应冒充对端欺骗认证者。
虽然CHAP不能防止实时的主动搭线窃听攻击，然而只要能产生不可预计的挑战就可以防范大多数的主动攻击。
唯一性来源和分歧可能性在魔术数配置选项【1】中讨论。
3.配置选项格式
协商CHAP的“认证协议配置选项”格式如下图所示，字段从左到右传输。
3
长度Length
5
认证协议Authentication-Protocol
0xc223CHAP
算法Algorithm
算法字段一字节，指示所使用的认证方法，最新的值在最近的“Assigned Number”【2】中指定，必须实现的一个值是：
5MD5【3】下的CHAP
4.包格式
CHAP数据包封装在PPP数据链路层帧的信息域中，PPP的协议字段指示0xc223。
代码Code
代码字段一字节，指示CHAP包的类型，分配如下：
1挑战Challenge
2应答Response
3成功 uccess
4失败Failure
标识符Identifier
标识符字段一字节，辅助匹配挑战、应答和响应。
长度Length
长度字段两字节，指示CHAP包的长度，包括代码、长度和数据字段。超出长度的字节应该视为数据链路层填充，接收方应该忽略。
数据Data
数据字段是零个或多个字节，数据字段格式由代码字段确定。
4.1.挑战和应答
描述
挑战包是CHAP的开始。认证者必须传送代码字段为1的CHAP包，其他挑战数据包必须在有效应答数据包成功接收之后或者可选重试计数器计满后发送。
为了确保连接没有被更改，挑战包也可以在NLP阶段的任何时候发送。
对端应该随时为认证阶段和NLP阶段的挑战做好准备，任何时候收到挑战包，对端都必须传送代码字段为2（应答）的CHAP数据包。
无论何时，如果收到应答包，认证者都必须把应答值和自己计算的预期值比较，基于这种比较，认证者必须发送成功（Success）或者失败（Failure）CHAP包。
注：由于成功包可能丢失，认证者在NLP阶段中必须允许重复的应答包，
为了发现更改的名字和密钥，收到具有当前挑战标识符的应答包必须返
回与先前挑战同样的响应代码（消息部分可能不相同）。在任何其他阶
段收到的任何应答包必须静静丢弃。
如果“失败包”丢失，认证者终止了链路，那么可以由LCP的“终止请求”
和“终止确认”来指示认证已经失败。
代码Code
1 挑战
标识符Identifier
editor assigned是什么意思标识符字段一个字节。标识符字段必须每次发送挑战时改变。
应答时标识符必须从当前要应答的挑战包的标识符字段拷贝。
值大小V alue_Size
该字段一个字节，表示值字段的长度。
值V alue
值字段一个或多个字节。最高有效位先发送。
挑战包得值字段是一串的字节。挑战包的值字段唯一性的重要性以及它与密钥的关系已经在前面描述。挑战包的值字段必须在每次挑战发送时改变。挑战包值字段的长度取决于用来产生字节的方法，而不依赖于所使用的哈希算法。
应答包的值字段通过单向哈希算法计算，参与计算的字节串包括标识符、密钥、挑战值字段。应答包的值字段长度取决于所使用的哈希算法（16字节，MD5）。
名字Name
名字字段一个或多个字节，表示发送这个包的系统的身份标识。该字段的内容没有限制。例如，它可以由ASCII 字符组成，也可以由ASN.1 语法表示的全局唯一标识组成。名字字段不应该为空，或者以CR/LF 结束。该字段的大小通过长度字段来判定。
4.2 成功和失败
描述
如果在接收到的应答包中，值与所预期的值相等，则实现者必须发送一个代码字段是3（成功）的CHAP 包。
如果在接收到的应答包中，值与所预期的值不相等，则实现者必须发送一个代码字段是4（失败）的CHAP 包，并且应该采取行动，终止链路。
成功和失败包的格式如下所示。字段的传输从左到右的顺序。
代码Code
3 成功
4 失败
标识符Identifier
标识符字段一个字节，辅助匹配请求和应答。标识符字段必须从当前要回复的应答包的标识符字段拷贝。
消息Message
消息字段0字节或多字节，内容取决于实现者。一般是用来提供人工可读性，而不得影响到协议的操作。
建议该消息字段的内容由可显示的ASCII 字符组成，32到126。扩展到其他字符集的机制是未来研究的主题。该字段的长度通过长度字段来判定。
安全话题是本RFC 重点讨论的主题。
在PPP的认证协议中的互操作高度取决于实现者。本文中对这部分的描述都使用必须两字。
例如，认证失败时，有些实现者没有终止链路。取而代之，该实现者限定了NLP 的通信类型，允许用户有机会更新密钥或者发送和网络管理员来反馈问题。
没有规定失败认证的重试次数。然而，LCP 状态机可以在任何时候重新协商认证协议，这样允许新的尝试。建议认证失败计数器不要复位，直到成功认证结束或者终止了失败的链路。
没有要求认证全双工，也没有要求在两个方向上使用相同的协议。这对于要在每个方向上使用不同协议来说，是个好消息。当然，这得依靠特定的协议协商。
在两个方向上，密钥不得相同。这允许攻击者重放对端的挑战包，接受计算的响应包，使用响应包来认证。
在实践中，在每个关联的PPP 服务器中，有一个数据库，将“user”名字和认证信息（“密钥”）关联起来。
无法预料某个特别的用户名字可能被不同的方法认证。如果用户认证时从认证的方法集中选择了最不安全的认证方法（比如选择PAP 而不是CHAP），那么该用户就容易受攻击。如果使用了同一个密钥，则ＰＡＰ将暴露密钥，该密钥也在以后的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.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。