摘要

  • 2026年9月30日的 EAP-PPT 工作组草案第04版，取消了第03版从外层 TLS 导出器取得128字节、再拆成 MSK 与 EMSK 的设计。它明确要求实现不得向承载它的隧道式 EAP 方法报告所谓 EAP-PPT 密钥材料。这仍是 I-D Exists 阶段的 Internet-Draft，不是已经批准的 RFC。
  • Privacy Pass 令牌是一种持有即可出示的凭据。验证它可以形成授权决定，却不会在出示者与 EAP-PPT 服务器之间生成只有双方知道的秘密。外层 TLS 会话的终止者本来就能计算该会话的导出值；把这些字节记作内层贡献，会夸大密码学绑定的证明力。

读一份接入日志时，“认证成功”“令牌已核销”“密钥已交付”很容易排成同一个绿色结果。但这三个结果的依据不同。EAP-PPT 草案让对等端在经过服务器认证的 TLS 隧道内提交 Privacy Pass 令牌；服务器决定是否接受。隧道式 EAP 方法负责自己的密钥材料，并向接入认证器提供链路密钥。第04版最重要的修订，是不再把隧道导出的密钥算到内部的令牌方法头上。Datatracker 将其列为 EMU 工作组文件、拟议标准方向、IESG 状态 I-D Exists；这不证明任何网络已经照此部署。

前一版的第6.6节曾给出明确公式：以 TLS 导出器取128字节，令上下文包含 EAP 类型和已经传送的令牌，再分别称前后64字节为 MSK 和 EMSK。新稿第5.7节撤销了这一整套推导，并写明 EAP-PPT 本身不产生这两种密钥。问题不是导出器不能给出字节，而是给出的字节究竟证明了什么。掌握外层 TLS 会话的一方同样能够计算它；令牌值也已在那条隧道里传送，并非对隧道终止者隐藏的第二把秘密。

令牌验证的两条路径进一步说明了区别。公开可验证类型使用签发者的公钥；私下可验证类型使用签发者与 EAP-PPT 服务器共享的材料。后一把秘密也不在令牌出示者手中。对等端通过发送不记名凭据来证明持有，而不是与服务器完成一次新的共享密钥协商。因此，令牌核销可以支持接入授权，却不能凭空为内部方法增加对端身份与隧道身份之间的独立密码学绑定。

新稿的安全声明把“密钥推导”和“密码学绑定”都标为否，同时把“信道绑定”标为是。信道绑定可核对对等端看到的网络信息与服务器侧的认证器信息，作用和密钥证明并不相同。也不能由“内层不供密钥”反推“外层隧道没有密钥”：草案明确由隧道式 EAP 方法提供交给认证器的密钥。真正需要分开的，是令牌接受、服务器证书验证、外层密钥来源和网络身份核对各自的证据。

第04版新增的安全讨论给出了这种区分的原因。若攻击者诱使对等端接受自己的服务器证书，便可能在一条隧道中取得令牌，再把内部 EAP-PPT 交换转发至真实服务器，为自己兑换网络接入。草案把按所加入网络配置的信任锚与预期服务器名称严格验证证书列为首要防线，反对首次使用即信任或让用户绕过验证失败。服务端功能合置、信道绑定、短期令牌与重复核销检测可限制后果，却不把不记名令牌变成密钥交换。草案没有报告现实攻击或特定厂商缺陷。

这次修订还将 JSON 格式改成 TLV，并收紧解析和错误处理；它们是另外的变化，不能用来声称本文所谈的密钥问题已经在生产中引发故障。可核实的新闻事实是：作者移除了一项会使“外层持有者能计算”误读成“内层独立证明”的设计。协议治理首先是把每种保证准确归给真正提供它的参与者。

来源