RFC1994：PPP Challenge Handshake Authentication Protocol (CHAP)，August 1996
本备忘录的状态
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
梗概
点对点协议 (Point-to-Point Protocol，PPP) [1] 提供了一种通过点对点链路传输多协议数据报的标准方法。
PPP 还定义了一个可扩展的链路控制协议，它允许在允许网络层协议在链路上传输之前协商用于验证其对等体的身份验证协议。
本文档定义了一种使用 PPP 进行身份验证的方法，该方法使用随机质询，并具有依赖于质询和密钥的加密散列响应。
1、 介绍
为了在点对点链路上建立通信，PPP 链路的每一端必须首先在链路建立阶段发送 LCP 数据包来配置数据链路。链路建立后，PPP 在进入网络层协议阶段之前提供一个可选的身份验证阶段。
默认情况下，身份验证不是强制性的。如果需要对链路进行身份验证，则实现必须在链路建立阶段指定身份验证协议配置选项。
这些身份验证协议主要供通过交换电路或拨号线路连接到 PPP 网络服务器的主机和路由器使用，但也可应用于专用链路。服务器可以在网络层协商的选项选择中使用连接主机或路由器的标识。
本文档定义了 PPP 认证协议。链路建立和身份验证阶段以及身份验证协议配置选项在点对点协议 (PPP) [1] 中定义。
1.1、 需求说明
在本文档中，使用了几个词来表示规范的要求。这些词通常大写。
MUST/必须
这个词，或形容词“必须”，意味着定义是规范的绝对要求。
MUST NOT/一定不
这句话的意思是定义是对规范的绝对禁止。
SHOULD/应该
这个词，或者形容词“recommended/推荐”，意味着在特定情况下可能存在合理的理由忽略这个项目，但在选择不同的词语之前必须理解并仔细权衡全部含义。
MAY/可以
这个词，或者形容词“optional/可选”，意味着这个项目是一组允许的替代品之一。不包含该选项的实现必须准备好与包含该选项的另一个实现互操作。
1.2、 术语
本文档经常使用以下术语：
authenticator/验证器
需要身份验证的链路的末尾。身份验证器指定要在链路建立阶段的配置请求中使用的身份验证协议。
peer/对等体
点对点链路的另一端；验证器正在验证的端。
silently discard/默默地丢弃
这意味着实现会丢弃数据包而不进行进一步处理。实现应该提供记录错误的能力，包括静默丢弃数据包的内容，并且应该在统计计数器中记录事件。
2、 质询握手认证协议
质询握手身份验证协议 (Challenge-Handshake Authentication Protocol，CHAP) 用于使用 3 次握手定期验证对等体的身份。这是在初始链路建立时完成的，并且可以在链路建立后的任何时候重复。
1. 链路建立阶段完成后，认证方向对端发送“质询”消息。
2. 对等体点以使用“单向散列”函数计算的值进行响应。
3. 验证器根据它自己对预期散列值的计算来检查响应。如果值匹配，则确认身份验证；否则连接应该被终止。
4. 鉴权者以随机间隔向对等体发送新的质询，并重复步骤 1 至 3。
2.1、 好处
CHAP 通过使用增量变化的标识符和可变的质询值来防止对等体端的回放攻击。重复质询的使用旨在限制暴露于任何单一攻击的时间。验证者控制质询的频率和时间。
这种身份验证方法取决于只有身份验证者和该对等体知道的“密钥”。密钥不是通过链路发送的。
尽管身份验证只是单向的，但通过在两个方向上协商 CHAP，相同的密钥集可以很容易地用于相互身份验证。
由于 CHAP 可用于验证许多不同的系统，因此名称字段可用作索引以在大型密钥表中定位正确的密钥。这也使得每个系统支持多个名称/密钥对成为可能，并且可以在会话期间随时更改正在使用的密钥。
2.2、 缺点
CHAP 要求密钥以明文形式提供。无法使用通常可用的不可逆转的加密密码数据库。
对于大型部署，它不是那么有用，因为每个可能的密钥都保存在链路的两端。
实施注意事项：为了避免通过网络中的其他链路发送密钥，建议在中央服务器而不是每个网络访问服务器上检查质询和响应值。否则，密钥应该以可逆加密的形式发送到这些服务器。这两种情况都需要信任关系，这超出了本规范的范围。
2.3、 设计要求
CHAP 算法要求密钥的长度必须至少为 1 个八位字节。密钥应该至少与精心选择的密码一样大且不可猜测。优选地，密钥至少是所选散列算法的散列值的长度（MD5为16个八位字节）。这是为了确保密钥有足够大的范围以提供针对穷举搜索攻击的保护。
选择单向散列算法使得从已知的质询和响应值确定密钥在计算上是不可行的。
每个质询值应该是唯一的，因为重复质询值与相同的密钥将允许攻击者用先前截获的响应进行回复。由于预期相同的密钥可以用于与不同地理区域的服务器进行身份验证，因此质询应该表现出全局和时间唯一性。
每个质询值也应该是不可预测的，至少攻击者会诱使对等体点响应预测的未来质询，然后使用响应伪装成验证器的对等体点。
尽管 CHAP 等协议无法抵御实时主动窃听攻击，但生成独特的不可预测的质询可以抵御范围广泛的主动攻击。
Magic-Number 配置选项 [1] 中包含了对唯一性来源和发散概率的讨论。
3、 配置选项格式
下面显示了用于协商质询握手身份验证协议的身份验证协议配置选项格式的摘要。字段从左到右传输。
Type：类型，3
Length：长度，5
Authentication-Protocol：认证协议，c223（十六进制）用于质询握手认证协议。
Algorithm：算法，Algorithm 字段是一个八位字节，指示要使用的身份验证方法。最新值在最近的“指定数字”[2] 中指定。需要填充一个值：
5 使用MD5的CHAP [3]
4、 数据包格式
PPP 数据链路层帧的信息字段中封装了一个Challenge-Handshake Authentication Protocol 数据包，其中协议字段指示类型为hex c223（Challenge-Handshake Authentication Protocol）。CHAP 数据包格式的摘要如下所示。字段从左到右传输。
Code：代码，Code 字段是一个八位字节，用于标识 CHAP 数据包的类型。CHAP 代码分配如下：
1 Challenge ，质询 2 Response ，回应 3 Success ，成功 4 Failure ，失败
Identifier：标识符，标识符字段是一个八位字节，有助于匹配质询、响应和回复。
Length：长度，Length 字段是两个八位字节，指示 CHAP 数据包的长度，包括 Code、Identifier、Length 和 Data 字段。长度字段范围之外的八位字节应被视为数据链路层填充并且在接收时应被忽略。
Data：数据，数据字段是零个或多个八位字节。数据字段的格式由代码字段决定。
4.1、 质询与回应
Challenge 数据包用于开始 Challenge-Handshake 身份验证协议。认证者必须发送一个代码字段设置为 1（质询）的 CHAP 数据包。必须发送额外的质询数据包，直到收到有效的响应数据包，或者可选的重试计数器到期。
质询包也可以在网络层协议阶段的任何时间传输，以确保连接没有被改变。
在认证阶段和网络层协议阶段，对等体应该期待质询数据包。每当收到质询包时，对等体必须发送一个 CHAP 包，其代码字段设置为 2（响应）。
每当接收到响应数据包时，验证器将响应值与其自己计算的期望值进行比较。基于这个比较，认证者必须发送一个成功或失败的数据包（如下所述）。
实现注意事项：因为Success可能会丢失，认证器必须在完成认证阶段后的网络层协议阶段允许重复的响应数据包。为了防止发现替代名称和密钥，收到的任何具有当前质询标识符的响应数据包必须返回先前为该特定质询返回的相同回复代码（消息部分可能不同）。在任何其他阶段收到的任何响应数据包都必须被静默丢弃。
当Failure 丢失，并且验证器终止链路时，LCP Terminate-Request 和Terminate-Ack 提供一个替代指示，表明验证失败。
质询和响应数据包格式的摘要如下所示。字段从左到右传输。
Code：代码
1 为质询 2 为响应
Identifier：标识符，标识符字段是一个八位字节。每次发送质询时，必须更改标识符字段。
响应标识符必须从引起响应的质询的标识符字段中复制。
Value-Size：值长度，该字段是一个八位字节，指示 Value 字段的长度。
Value：值，Value 字段是一个或多个八位字节。首先传输最重要的八位字节。
质询值是八位字节的可变流。质询值的唯一性及其与密钥的关系的重要性在上面进行了描述。每次发送质询时必须更改质询值。质询值的长度取决于用于生成八位字节的方法，并且与所使用的散列算法无关。
响应值是在由标识符组成的八位字节流上计算的单向散列，后跟（连接）“密钥”，后跟（连接）质询值。响应值的长度取决于所使用的散列算法（MD5 为 16 个八位字节）。
Name：名称，Name 字段是一个或多个八位字节，代表传输数据包的系统的标识。该字段的内容没有限制。例如，它可以包含 ASN.1 语法中的 ASCII 字符串或全局唯一标识符。名称不应为 NUL 或 CR/LF 终止。大小由长度字段确定。
4.2、 成功与失败
如果在响应中收到的值等于预期值，则实现必须发送一个 CHAP 数据包，其代码字段设置为 3（成功）。
如果响应中收到的值不等于预期值，则实现必须发送一个代码字段设置为 4（失败）的 CHAP 数据包，并且应该采取措施终止链路。
成功和失败数据包格式的摘要如下所示。字段从左到右传输。
Code：代码
3 成功 4 失败
Identifier：标识符，标识符字段是一个八位字节，有助于匹配请求和回复。标识符字段必须从引起此回复的响应的标识符字段中复制。
Message：信息，Message 字段是零个或多个八位字节，其内容取决于实现。它旨在供人类阅读，并且不得影响协议的操作。建议消息包含可显示的 ASCII 字符 32 到 126 十进制。扩展到其他字符集的机制是未来研究的主题。大小由长度字段确定。
5、 安全注意事项
安全问题是本 RFC 的主要主题。
PPP 中认证协议的交互高度依赖于实现。这通过在整个文档中使用 SHOULD 来表示。
例如，在认证失败时，一些实现不终止链路。相反，该实现将网络层协议中的流量类型限制为过滤的子集，这反过来又允许用户有机会更新密钥或向网络管理员发送邮件以指示问题。
没有对失败的身份验证进行重试的规定。然而，LCP 状态机可以随时重新协商认证协议，从而允许新的尝试。建议任何用于验证失败的计数器在验证成功或失败链路的后续终止之前不要重置。
没有要求认证是全双工的或在两个方向上使用相同的协议。在每个方向使用不同的协议是完全可以接受的。当然，这将取决于协商的具体协议。
密钥不应该在两个方向上都相同。这允许攻击者重放对等体的质询，接受计算出的响应，并使用该响应进行身份验证。
实际上，在每个 PPP 服务器内或与每个 PPP 服务器相关联，有一个数据库将“用户”名称与身份验证信息（“密钥”）相关联。预计不会通过多种方法对特定命名用户进行身份验证。这将使用户容易受到从一组中协商最不安全的方法（例如 PAP 而不是 CHAP）的攻击。如果使用相同的密钥，PAP 将透露该密钥，以便稍后与 CHAP 一起使用。
相反，对于每个用户名，应该指示用于验证该用户名的确切方法。如果用户在不同的情况下需要使用不同的身份验证方法，那么应该使用不同的用户名，每个用户名都准确地标识一种身份验证方法。
密码和其他密钥应存储在各自的末端，以便尽可能限制对其的访问。理想情况下，密钥应该只能由需要访问以执行身份验证的进程访问。
密钥信息的分发机制应该限制处理（从而了解）密钥信息的实体数量。理想情况下，任何未经授权的人都不应该知道这些密钥。这种机制超出了本规范的范围。
6、 致谢
David Kaufman、Frank Heinrich 和 Karl Auerbach 在 1970 年代中期在为“安全”网络设计其中一个协议时使用了 SDC 的质询握手。汤姆·贝尔森 (Tom Bearson) 在 1982-83 年的时间范围内基于质询-响应概念构建了 Sytek 产品原型（“Poloneous”？）。另一个变体记录在各种 IBM SNA 手册中。Karl Auerbach 大约在 1991 年在 Telebit NetBlazer 中实现了另一个变体。
Kim Toms 和 Barney Wolff 对本文档的早期版本提供了有用的评论。
特别感谢 Dave Balenson、Steve Crocker、James Galvin 和 Steve Kent，他们提供了大量的解释和建议。现在，如果我们能让他们彼此同意就好了。
参考
[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.
