摘要

  • RFC 9678 通过可选的临时 ECDHE 扩展，把 X25519 或 P-256 的共享秘密纳入 EAP-AKA' 的密钥派生，并用既有的 AT_MAC 保护新的协商属性。
  • 规范对已结束历史会话的保护有明确前提：端点必须删除全部相关临时密钥和会话密钥；握手记录本身不能证明该前提已经满足。
  • 完整证据链必须分别覆盖策略、协商、鉴别、派生、下游消费、会话结束、密钥副本清单、销毁回执与独立恢复测试。

第四个灯没有自动亮起

一套认证控制台展示三个绿灯：终端支持 RFC 9678；服务器与终端选择了共同的 ECDHE/KDF 方案；EAP-AKA' 身份鉴别成功。界面随后把整场会话标成“具备前向保密”。

这个结论少了第四个灯：相关密钥是否真的消失。

前三个状态都有协议证据。AT_KDF_FS 记录了前向保密 KDF 的选择，AT_PUB_ECDHE 携带双方的临时公钥，AT_MAC 把这些属性绑定到经过鉴别的交换。第四个状态却发生在协议报文之外。私钥标量是否残留于进程内存，MSK 是否被网关缓存，K_re 是否被长期复用，崩溃转储是否复制了秘密，都无法由对端通过一条握手得知。

所以 RFC 9678 的价值并不是把四个问题压成一个答案，而是让前三个问题有了标准化答案，并清楚暴露第四个问题必须由运行系统承担。

规范改变了哪一段派生

RFC 9678 于 2025 年 3 月作为 Proposed Standard 发布，更新 RFC 9048 及其前身 RFC 5448。EAP-AKA' 的基础信任来自订户侧与归属网络侧持有的长期对称密钥。若攻击者先保存通信，后来再获得长期密钥，缺少独立临时贡献的旧会话就面临被追溯恢复的风险。

新扩展要求服务器发送一个或多个 AT_KDF_FS 选项以及服务器的 AT_PUB_ECDHE。终端按规则选择首个可支持的方案，并返回自己的临时公钥。IANA 为两个属性登记了 152 和 153；规范定义了 X25519 和 P-256 两种选择。

双方得出的 ECDHE 共享秘密进入 MK_ECDHE，进而影响 K_re、MSK 和 EMSK。新的属性受 AT_MAC 保护，因此未持有鉴别材料的中间人不能静默替换公钥或 KDF 选择而仍让验证通过。

这项改变切断了一条特定的追溯路径：后来得到长期密钥，不应仅凭它恢复已经结束、正确使用扩展且完成密钥销毁的会话。它没有承诺抵抗一个在当前认证期间已经持有长期密钥、又处在路径上的主动攻击者。时间条件是安全定义的一部分。

成功认证存在两条路径

RFC 9678 的扩展是可选项。若终端不支持或不愿选择它，而本地策略允许兼容，认证仍可沿普通 EAP-AKA' 完成。若策略规定必须使用前向保密，则无法达成共同选择时应失败，而不能把普通路径包装成受保护路径。

因此，“认证成功率”只能说明接入可用性。它不能说明多少会话真正完成 RFC 9678。一次迁移既可能维持极高成功率，又在老旧终端群体中留下大量未获得前向保密的会话；也可能因为拒绝降级而让成功率下降，却提升保护的一致性。

终端与服务器各自拥有策略权：是否提供扩展、支持哪些算法、是否接受回退、何时强制失败。管理层需要看到这些决策的结果，而不是只看到最终的绿色接入状态。最少应分开记录能力、提供、选择、鉴别完成、普通路径回退和策略性拒绝。

“临时”描述算法，不描述真实寿命

规范的安全分析把保护限定于已结束会话，并假定这些会话已经删除所有相关会话密钥材料。端点不但要销毁临时私钥，还必须处理从该次交换派生、足以恢复或继续使用会话的其他材料。

真实系统中的副本可能分散在终端进程、认证服务器、密钥管理服务、硬件加速器、接入点、网关、重认证缓存、交换分区、休眠镜像、核心转储、备份与诊断平台。EAP 库调用一次清零函数，只能说明它负责的那一份；它不能替其他保管者出具回执。

“会话结束”也不是天然统一的时刻。EAP 方法可以先结束，链路关联仍然活跃；终端漫游可以造成上下文重叠；隧道、订户数据库和接入设备可能使用不同超时。若某个组件仍获准使用 MSK 或派生密钥，对该组件而言销毁义务尚未开始或尚未完成。

可靠的做法是按密钥类别定义退出事件：谁宣布不再使用，哪些句柄立即失效，哪些缓存可延迟多久，硬件如何清除，转储与快照如何处置，例外由谁批准。没有完整集合，就无法证明“全部删除”。

重认证看起来新，却没有新 DH

若最初的完整认证使用 RFC 9678，K_re 也来自受到 ECDHE 贡献保护的层级。此后重认证可以继承对未来长期密钥泄露的抵抗力。

但重认证本身不会重新执行一次 Diffie-Hellman。运营日志中的一次新接入事件，可能仍依赖更早的完整认证和持续保存的 K_re。其年龄、复用次数和下一次强制完整认证的阈值，都是必须呈现的安全状态。

把每次重认证标为“新 ECDHE”会制造不存在的新鲜度。正确的记录应把它链接回产生该上下文的完整认证，并说明继承关系何时终止。

保护效果取决于谁消费 MSK

EAP 输出 MSK 与 EMSK，真正承载业务数据的通常是后续层。若下游使用 IKEv2，并通过自己的临时交换为隧道提供前向保密，RFC 9678 对该路径的边际增益可能较小。若链路层直接依赖 EAP 输出而没有另一个独立的前向保密交换，新扩展的作用就更关键。

因此，认证回执还要连接到消费回执：哪一个 MSK 实例交给了哪个关联，期间是否有另一场临时密钥交换，关联何时退出，消费设备是否复制或导出过密钥。若缺少这种绑定，组织只能证明 EAP 方法发生过，不能证明报告中所称的数据面得到何种保护。

从报文证据走向不可恢复证据

第一层记录双方策略：扩展是强制、优先还是可选，是否允许普通 EAP-AKA'。第二层记录实现版本、支持算法、实际提供顺序和选择结果。第三层保存经 AT_MAC 验证的会话事实，但不保存私密标量。

随后用非秘密标识证明 ECDHE 贡献进入规定的派生层级，并把 MSK、EMSK 与 K_re 上下文映射到实际消费者。每一次回退都必须显式标注。每个系统分别给出自己的会话结束事件。

再往后才是销毁：列出所有可能持有秘密的位置，为每个位置记录清零、过期或密码学失效。诊断转储、合规留存、快照等例外不能被排除在结论之外，而要降低结论范围。

最后可以在授权环境中进行恢复测试：使用留存的协议记录和后来暴露的长期密钥，尝试恢复已退出会话的密钥。范围清楚的失败结果，比“功能已启用”更接近所需事实。它仍不证明不存在未知副本，却能检验已知保管链。

最小规范与运行代码

RFC 9678 提供一套最小互操作框架：属性、算法、选择与派生。它不替本地运营者决定兼容策略、重认证寿命、内存管理、下游保管和审计强度。规范发布不等于产品支持；产品支持不等于会话选择；会话选择不等于密钥销毁。

按照 Heng Lu 对现实层与运行代码的强调，IANA 码点属于协调层，鉴别后的 transcript 属于协议层，内存中的字节属于实现层，接入关联属于运营层，恢复实验属于证据层，“前向保密已开启”则属于叙事层。

领导力不是让叙事层覆盖下面各层，而是要求每一层提供与自身能力相称的回执。RFC 9678 已经把协商这一段做得更清晰。其余部分必须由部署它的人完成。

来源