摘要

  • RFC 3079 中的主值只是下一层派生的输入，真正初始化流量密码状态的是按端点角色和收发方向分出的瞬态密钥。
  • 测试向量匹配只能证明给定输入产生了给定输出；它不能证明双方选择了同一次首次认证、正确对应发送与接收、协商了同一 MPPE 强度、保持了状态同步或把数据交给应用。

名字最响亮的密钥，却不碰流量

规范中最值得记住的不是一行十六进制，而是一句限制：主会话密钥永远不用于加密或解密数据。它只用于派生瞬态会话密钥。

在 MS-CHAP-2 路径中，口令哈希的再哈希值与 NT-Response 先进入 GetMasterKey。得到的 16 字节主值随后进入 GetAsymmetricStartKey。这个函数不仅问“发送还是接收”，还问“本端是不是服务器”。最后，GetNewKeyFromSHA 再生成真正装入发送或接收 RC4 表的瞬态密钥。

因此，“主密钥派生成功”不是一张流量保护证明。它没有说明下一步选了哪条分支，也没有说明结果装进哪个方向。两端都可能各自记录成功，却因为一端把自己当成了错误的角色，或把对端的发送字段机械复制到自己的发送字段，得到彼此不相配的状态。

RFC 3079 的贡献不只在公开算法，也在迫使实现者承认密钥有谱系。认证材料、主值、方向起始值、瞬态值和密码上下文不是同一个对象。每次变换都需要独立回执。

三种认证来源没有被一个结果抹平

RFC 3079 于 2001 年 3 月以 Informational RFC 发布，目标是让第三方能够与 Microsoft 产品互操作。它没有规定 MPPE 的 CCP 协商、数据包格式、会话内换钥或丢包恢复；这些由 RFC 3078 负责。它也不是 Internet Standard，更不能单凭发布状态证明部署。

文档处理三条来源路径。MS-CHAP-1 的 40 位和 56 位分支来自 LAN Manager 口令哈希，128 位分支来自 Windows NT 口令哈希及认证方挑战。MS-CHAP-2 的三个强度都来自 Windows NT 口令谱系与 NT-Response。EAP-TLS 则从 TLS 导出的主秘密开始。

它们最后都能生成 MPPE 密钥，却不是可互换的证据。审计必须保留认证家族、发起呼叫的对端、首次认证的挑战与响应、TLS 导出代次，以及结果要进入哪条链路。只记录“安装了 8 字节密钥”，甚至不能区分 40 位与 56 位的有效强度。

RFC 2759 定义 MS-CHAP-2 的 Peer-Challenge、Authenticator-Challenge、ChallengeHash、NT-Response 与 AuthenticatorResponse；RFC 2433 提供更早的 MS-CHAP-1 过程；RFC 2716 说明 EAP-TLS 如何进入 PPP。它们能证明上游输入，却不能证明 CCP 已经 Opened。

“首次认证”其实是会话身份的一部分

RFC 3079 规定，两条方向的初始密钥都取自发起呼叫一方的凭据；需要挑战时，使用第一次认证中的挑战。即便双方互相认证，这条规则仍成立；多链路捆绑中的每条链路也一样。

分布式实现最容易丢掉的正是“第一次”。认证服务可能只保留最近一次成功；链路聚合器可能只知道用户名与成功状态；故障转移节点可能复制了会话，却没有复制当初的挑战/响应代次。此时每台机器使用的公式都完全正确，结果仍会错。

规范没有假装算法能解决状态分发。在多机箱 multilink 场景中，它把责任直接交给实现者：所有参与机器必须生成正确密钥。用户名、PPP 句柄和一个布尔成功值不足以完成这项责任。真正的会话身份还包括认证事件、端点角色、链路成员和派生代次。

方向是一段关系，不是本地字段名

GetAsymmetricStartKey 用固定标签把同一个主值分成两支。服务器端发送所用的标签，对应客户端接收；服务器端接收则对应客户端发送。RFC 3079 在 EAP-TLS 部分写得更直接：一侧的发送密钥就是另一侧的接收密钥。

因此，send_key 不是可以原样跨机器复制的自足属性。“发送”永远相对于本端。若两个配置系统都把对方的 send_key 放进自己的 send_key，它们保留了同一个词，却破坏了同一段关系。

正确回执应当同时连接双方：端点身份、client/server 角色、本地方向、对端方向、认证代次指纹和瞬态密钥指纹。在不记录秘密本身的前提下，它应证明 A 的出站与 B 的入站相同，B 的出站与 A 的入站相同。

强度是在派生之后被主动塑造的

40 位和 56 位模式使用 8 字节值，128 位模式使用 16 字节值，但长度不是全部。40 位模式会把开头三个字节覆盖成固定常量；56 位模式覆盖第一个字节。有效强度是在较早派生完成后被有意降低的。

EAP-TLS 路径还规定了长度归一化：不足目标长度的非对称主值要在左侧补零，过长则截断。最终长度相同，不代表原始长度或处理路径相同。

RFC 给出的完整测试向量可以检验算法实现，却无法检验线上谱系。向量通过不证明真实用户的认证材料正确，不证明 EAP-TLS 主值安全抵达 PPP 认证方，也不证明双方最后选中了 128 位而不是 40 位。

安全章节进一步揭示边界。MS-CHAP-1 的 40 位路径在相同对端凭据下会跨会话产生相同初始密钥，规范因此建议尽量不用；口令派生路径继承口令质量；EAP-TLS 路径则继承 TLS 与主值传输的安全性。本文据此解释历史机制，并不为 RC4、LAN Manager 哈希或传统 MS-CHAP 提供现代安全背书。

派生完成时，服务还没有开始

RFC 3078 要求 PPP 已进入 Network-Layer Protocol 阶段、CCP 已达到 Opened，才可发送 MPPE 包。RFC 2548 解决另一条相邻边界：已生成的方向密钥如何通过 RADIUS 传递，以及代理如何在转发时成为密钥保管者。

这些步骤不能缩成一个“加密成功”。认证通过不等于主值已到达 PPP 端点；密钥到达不等于分配给正确链路；方向对应不等于 CCP 选择 MPPE；CCP Opened 不等于后续密码状态保持同步；解开一个包也不等于应用接受了内容。

用 Lu Heng 的现实层方法看，“master”“send”“receive”“authenticated”“128-bit”都是符号。真正的系统由符号之间的变换构成。运行代码必须逐步完成这些变换，而审计必须证明完成的是哪一步。

RFC 3079 的历史价值因此很具体：它把互操作的最低共同面写成一条可复现谱系。主密钥不是流量密钥；方向不是单机属性；派生成功只授权进入下一道验证。

来源