摘要

  • RFC 9930 允许服务器在接受 TEAP 会话恢复时完全跳过第二阶段；这条捷径只有在票据仍能指向已完成的内部认证、正确凭据与当前授权时才成立。
  • 新凭据无法与票据建立关联时，服务器必须作废票据，让下一次连接重新完成认证；可恢复的加密状态不是长期访问资格。

恢复机制最诱人的地方，是它确实省掉了工作。校园网等环境可能让同一用户每天反复认证，多次访问身份数据库会形成真实负担。RFC 9930 因此要求 TEAP 实现支持恢复，并把可扩展性与稳定性列为直接收益。但“支持恢复”和“接受这一次恢复”是两件不同的事。

完整 TEAP 有两层判断。第一阶段用 TLS 建立受保护且经过认证的隧道；第二阶段在隧道内运行内部方法和 TLV，可以分别认证机器与用户、配置或更换凭据、完成 Crypto-Binding，再交换受保护的结果。RFC 6678 规定了标准隧道式 EAP 方法应满足的设计要求，RFC 3748 则给出 EAP 的参与者、成功与失败语义。隧道已建成，不等于隧道内的所有工作已经完成。

RFC 9930 的关键边界很简短：服务器同意恢复时，第二阶段被完全跳过；拒绝恢复时，双方完成完整 TLS 握手后必须继续第二阶段。状态可以保存在服务器，也可以使用 RFC 5077 一类客户端票据。TLS 1.3 的 RFC 8446 用 NewSessionTicket 为未来连接建立 PSK 相关状态。它证明的是可恢复关系，不是所有授权条件在未来都自动续期。

票据甚至可能早于内部认证。RFC 9427 指出，TLS 1.3 可以在收到客户端 Finished 后就发送 NewSessionTicket，而隧道内认证此时可能尚未运行。恶意客户端若先拿票据再中止，就可能尝试绕过内部认证。服务器不得让未成功完成内部认证的票据恢复认证；最好延后出票，做不到时则必须丢弃或作废失败会话的票据。若票据无法说明内部认证是否完成，服务器必须按“未完成”处理，并在授权访问前重新运行内部方法。

完整会话中的成功也需要分层记录。每个成功的内部方法之后要有 Intermediate-Result 与 Crypto-Binding。Compound MAC 能把双方、隧道与内部认证序列连接起来，暴露替换或参与缺口。它却不会决定 VLAN、ACL、角色、账户状态或业务权限。即使服务器发送成功 Result TLV，若对端的认证政策仍未满足，对端仍可请求进一步动作；服务器是否响应仍由本地政策决定。

真正的时间问题出现在一次完全合法的初始认证之后。TEAP 第二阶段可以发放或更换凭据，所以后续授权必须基于经过认证的凭据，不能拿匿名或不同的第一阶段身份替代。恢复时同样要应用正确授权：新凭据必须与会话票据关联。关联做不到，服务器就必须作废当前会话产生的票据。下一次连接被迫走完整认证，新的票据才能重新绑定可解释的授权基础。

RFC 9190 把风险扩展到凭据之外。完整握手与恢复之间，对端信息、认证器信息以及外层协议环境都可能改变；只要变化可能改变授权、计费或政策判断，就必须重新评估。无法安全作出决定时，应拒绝恢复并回到完整握手。TLS 1.3 的七天票据上限只是最长密码学寿命，不是七天授权书；尚未过期的票据也可能已经陈旧。

因此，运营证据不能只记“resume=success”。至少要保存票据或 Session ID 的哈希、签发者、起止时间、来源完整会话、内部认证完成状态、凭据标识与版本、政策及认证器环境、期间发生的变更、重新评估结果，以及接受、拒绝或作废理由。当前授权要单独记录，NAS 的执行收据再单独记录，最后才是数据包与服务观察。RFC 5247 可以帮助限定 EAP 身份与密钥上下文，却不能替后面的系统写出结果。

这与 Heng Lu 所说的最小初始规范相吻合：共同层只携带互操作所需的有限状态，未来决定仍由本地承担。运行代码必须说明它实际读取了什么，现实层也不能混写——票据、认证凭据、当前政策、授权、执行和结果各有自己的证据。安全的恢复不是“什么都不用再看”，而是能够准确说明哪些工作没有重做，以及为什么仍可放心省略。

Sources