摘要

  • draft-ietf-emu-eap-ppt-04 删除了上一版从外层 TLS 导出器取得的 128 字节输出，并明确规定 EAP-PPT 不产生 MSK 或 EMSK。
  • Privacy Pass 令牌是在隧道内传送的不记名凭据；隧道终止方既能看到令牌，也能算出相同导出值，因此这组字节不能证明令牌持有者与隧道端点是同一个主体。

密码学导出器忠实地完成了任务：它给出了 128 个字节。失误发生在随后的一步——把一段确实可计算的输出，解释成它没有能力提供的身份证明。

EAP-PPT 第 03 版使用外层 TLS 隧道的导出器，以 EXPORTER_EAP_PPT_Key_Material 为标签，并把 EAP 类型和已兑付令牌放进上下文。结果可被分成 MSK 与 EMSK，交给承载 EAP-PPT 的隧道方法。形式上，它像一份来自“内层认证”的密钥贡献。

9 月 30 日发布的第 04 版把整段设计删掉。新文本明确说 EAP-PPT 不生成 MSK、也不生成 EMSK，实施者不得把任何 EAP-PPT 密钥材料报告给外层方法。这个改动不是弱化安全，而是把安全边界重新画在真实机制所在的位置。

不记名令牌没有贡献独占秘密

EAP-PPT 是一个内层 EAP 方法。对等端先从发行者处带外获得 Privacy Pass 令牌，再进入由其他 EAP 方法建立、仅验证服务器身份的 TLS 隧道，最后把令牌交给 EAP-PPT 服务器兑付。

公开可验证令牌由服务器使用发行者公钥验证。私下可验证令牌使用发行者与服务器之间的材料验证。两种模式都没有在对等端与 EAP-PPT 服务器之间建立新的共享秘密。对等端的动作是发送一份持有者即权利人的凭据；服务器的动作是检查它能否被接受。

TLS 导出值属于外层会话。谁终止这条隧道，谁就能计算导出值。令牌又明文存在于该加密隧道内部，隧道终止方自然也能看到作为导出上下文的一切。把令牌加入上下文可以区分两次计算，却不会凭空增加一个终止方不知道的秘密。

因此，输出可以是新鲜的、会话唯一的、标签正确的，仍然无法回答关键问题：内层凭据持有者贡献了什么只有自己知道的量？答案是没有。长度和随机外观不能代替独占贡献。

外层 TLS 不能证明内层主体

这种错觉在 TEAP 中尤其危险。TEAP 的 Crypto-Binding TLV 可以把隧道密钥与内层方法的密钥材料结合。如果 EAP-PPT 上报的所谓内层材料其实只来自同一条隧道和隧道终止方可见的令牌，最终计算虽然形状完整，却没有把两份独立证明绑在一起。

第 04 版直接指出：旧值会让隧道型方法生成一个看似有效的 Crypto-Binding TLV，但并不提供 EAP-PPT 与隧道之间的密码学绑定。协议图里像是有两个贡献者，实际计算里只有一个能掌握全部输入的终止方。

修订后的结论很简洁：EAP-PPT 可以通过令牌兑付授权对等端，但它不给链路生成密钥。真正的链路密钥来自外层隧道型 EAP 方法。若某套遥测仍为 EAP-PPT 显示 MSK 或类似 exporter 字段，它展示的不是额外安全性，而是已经被规范删除的歧义。

无内层密钥会改变中继风险

缺少内层密码学绑定时，服务器证书验证成为抵挡中继的第一道防线。若攻击者诱使对等端接受攻击者的 TLS 隧道，就能把隧道内 EAP-PPT 交换转发给真实服务，观察不记名令牌，并把它用于攻击者自己的接入。

草案因此要求严格、面向具体网络的 EAP 服务器证书验证。客户端应核对预期服务器身份，验证失败时直接拒绝，而不是让用户点击继续；首次使用即信任也不适用于这里。Privacy Pass challenge 中的 origin_info 若得到填充，并与证书身份核对，可以约束 challenge 替换，但不会产生内层密钥。

服务器部署位置也属于安全模型。把 EAP 服务器与 EAP-PPT 服务器放在一起，可以消除同一提供方内部的一段分离面。把 Phase 1 与 Phase 2 服务器拆开则“不建议”，除非双方关系和传输协议得到明确保护。这是信任边界，不是简单的机房拓扑。

Channel binding 可以发现客户端认为自己加入的网络与服务器观察到的认证器不一致。短生命周期令牌缩短损失窗口，双花检测可以在事后暴露同一令牌出现在不同路径。它们有用，但没有一项能让被删掉的导出值重新成为令牌持有连续性的证明。

语境判定之前，令牌可能已经花掉

第 04 版还增加了一条容易被总成功率掩盖的时序规则。令牌兑付成功后，EAP-PPT 服务器可以在 EAP Success 之前发送 EAP-Request/PPT-Channel-Binding。如果更早的 EAP 方法已经提供合适信息，服务器也可以跳过这次请求。

对等端一旦收到该请求，就知道令牌已被接受并从此花掉。后续结果不改变这件事。Channel-binding 响应格式错误、内容无效、服务器返回 EAP 错误，乃至网络最终不可用，都不能让这个令牌恢复可重用状态。

所以“令牌已花”是一张范围很窄的收据：它证明兑付成功。它不证明 channel binding 通过，不证明 EAP Success 已发出，不证明外层方法安装了链路密钥，也不证明 RADIUS/NAS 执行了允许策略，更不证明用户真的传出了一个数据包。

若把“已花”统计成“已连接”，就把至少六个独立决策压成一个数字。若把 EAP Success 解释为令牌持有者与隧道终止者同一，也只是把第 04 版刚从密钥流程里删掉的越权结论换了一个字段保存。

第 04 版不只更换编码

新版本把消息内容从 JSON 改为 TEAP 风格 TLV，直接承载 Privacy Pass 结构，不再先转成 base64url 字符串。它加入明确的 No-Suitable-Token TLV，规定长度、重复项、完整消费和单层嵌套规则，并用 M 位处理未知 TLV，还提供字节级测试向量。

错误码 9 区分“消息格式错误、尚未兑付”与“格式正确但令牌验证失败”。区别之所以重要，是因为令牌能否重用取决于它是否已经被服务器消费。修订还扩充了中继分析，并澄清公开、私下及联邦令牌类型的建议。

这些工作让线上的协议更明确，却不是实现或部署证据。该文件是 EMU 工作组正在推进、目标为 Proposed Standard 的 Internet-Draft。Datatracker 状态仍是 I-D Exists，没有负责 AD、文档 shepherd 或 telechat；它还不是 RFC。冻结来源也没有证明互操作、性能或采用情况。

运营证据必须分开保存、再做关联

可审计系统至少要分别记录：配置的网络和预期 EAP 服务器名；验证过的证书、信任锚与实际 TLS 端点；Privacy Pass challenge 与 origin_info；令牌类型、发行者密钥与 challenge 摘要；兑付结果和首次花费时间；channel binding 是本方法请求还是继承、最终是否通过；EAP Success/Failure；外层链路密钥；RADIUS/NAS 决策；以及观察到的网络接入。

这些记录的价值在关联，而不是把它们压平为一个“认证成功”。证书回答客户端信任了哪个服务器；兑付回答凭据是否有效；channel binding 回答两侧观察的网络语境是否一致；EAP 结果回答协议状态；NAS 与流量才回答接入是否真正执行。

规范不是不重要。恰恰相反，第 04 版的价值在于拒绝让 128 个权威感很强的字节替机制做过度承诺。真正的运行系统必须保存那组字节从来不能替代的证据连接。

来源