摘要

  • RFC 5422 建议服务器未认证模式结束时不要开放网络；服务器已认证模式则可由服务器按策略授予访问。
  • Tunnel PAC 确认消息报告对端所称的处理与存储结果，不代表后续认证成功或已获网络准入。

引导交换有自己的终点

设备接入时，可能没有共享密钥、可信服务器根证书，也没有 Protected Access Credential。RFC 5422 讨论如何通过 EAP-FAST 在带内配置这些材料。真正需要判断的是：配置交换成功，是否也代表设备已获准使用网络？该规范把两个结果分开处理。

EAP-FAST 包含 TLS 第一阶段与内部 EAP 第二阶段。RFC 5422 区分服务器已认证和服务器未认证的配置模式。前者要求对端在 TLS 握手时验证服务器，因此设备必须预先拥有可验证服务器的信任材料。后者使用匿名 Diffie–Hellman TLS 隧道，降低初始部署门槛，但第一阶段并未确认服务器身份。

匿名隧道并不意味着可以省略身份验证。RFC 5422 要求双方在隧道内完成能够相互认证并派生密钥的 EAP 方法，再由对端验证 Crypto-Binding TLV，将内部交换与外层 TLS 隧道的完整性联系起来。2009 年版本要求该模式的实现必须支持 EAP-FAST-MSCHAPv2 作为内部认证方法。若只看内部认证结果而忽略绑定，便无法确认它是否属于当前这条外层隧道。 (RFC 5422 第 2、3.2–3.2.3、6.1.2 节；RFC 4851)

通过内部认证和 Crypto-Binding 后，服务器可以下发 Tunnel PAC（包括 PAC-Key 与 PAC-Opaque），也可以配置可信服务器根证书。Tunnel PAC 可供后续 EAP-FAST 建立隧道使用；它本身不是网络资源的准入许可。

Tunnel PAC 的 PAC-Acknowledgement 有明确范围：对端据此报告新 Tunnel PAC 的处理与存储结果。该确认不用于其他 PAC 类型。服务器拿到的是对端对存储结果的声明；仅凭这条消息，不能推出后续认证成功、访问策略放行，或应用流量已经到达。 (RFC 5422 第 3.2、4.1.4、4.2.5 节)

RFC 5422 明确指出：服务器未认证配置模式结束时，不应授予网络访问，因为这段会话仅用于配置。对端策略可以断开当前连接，再使用刚取得的信息发起一轮新的 EAP-FAST 认证。服务器已认证模式则允许服务器在配置成功后授予访问。两种模式不能被压成一个通用的“成功即放行”。 (RFC 5422 第 3.5 节)

这种区别对应不同成本。服务器认证模式对中间人攻击的防护更强，但要求设备事先拥有服务器验证凭据。匿名模式有助于免人工引导，却让基于口令的第二阶段更容易面临离线字典攻击。RFC 5422 提到限制在线尝试，并鼓励限制匿名模式可用的接口和条件。这些是 2009 年信息类文档中的设计约束，不是今天产品采用率或攻击发生率的统计。 (RFC 5422 第 6.1–6.3 节)

运营记录应分别保存：引导模式；内部相互认证和 Crypto-Binding 结果；凭据类型与有效期；Tunnel PAC 确认；之后使用该凭据的认证；最终访问策略决定。如果配置团队与网络准入团队分开，双方需要共同的会话关联键，并明确谁追查缺失的后续交换。前三个事件再成功，也不能填补第四项证据。

内层交换成功，仍可能拒绝准入

RFC 5422 第 3.5 节把最终授权交给服务器策略。服务器已认证模式下，服务器认证对端并配置 Tunnel PAC 后，可以授予网络访问。服务器未认证模式则不同：会话只用于配置，结束时不应开放网络。两种模式都能配置凭据，但输出的授权结果不同。

即使内层认证成功，网络授权仍未必成立。Result TLV 可以报告内层方法成功完成，服务器仍可能判定策略条件不满足并以 EAP Failure 结束。若这次交换并非用于开放网络，RFC 5422 还要求服务器不得准入，也不得向 Network Access Server 下发会话密钥。只统计内层成功的管理界面，可能显示绿色，却掩盖了服务器有意拒绝接入。证据链应跟到最终 EAP 结果和密钥下发，而不能停在第一个成功状态。（RFC 5422 第 3.5 节；RFC 4851 第 4.2.2 节）

确认消息只覆盖凭据生命周期中的一个时点

Tunnel PAC 由不同部分组成。PAC-Key 是建立第一阶段隧道的 32 字节秘密；PAC-Opaque 由签发服务器解释，并在之后的交换中交回服务器；PAC-Info 可以说明签发者，也可以携带有效期。RFC 4851 要求妥善保护 PAC-Key，RFC 5422 说明对端和服务器都要安全保存各自的状态。凭据下发因此带来后续保管、到期和续期责任，不能由一次配置成功自动完成。

PAC-Acknowledgement 的含义更窄：对端只在收到新 Tunnel PAC 后回报处理和存储结果，结果值为成功或失败。成功表示对端当时如此报告；它不能证明之后仍能建立 TLS 隧道、秘密材料没有泄露，或服务器会批准网络访问。后续 EAP-FAST 认证才检验凭据能否在新的认证上下文中使用；即便如此，也不等于应用流量已送达。（RFC 5422 第 4.2.2—4.2.5、6.8 节；RFC 4851 第 3.2.2 节）

拒绝也会带来可用性成本

这一边界并非没有代价。RFC 5422 指出，配置后拒绝访问并以 EAP Failure 结束，可能导致 802.11 无线设备完全解除关联。对端或服务器可以尝试 TLS 重新协商，用新凭据衔接后续认证，避免完整重启；但任何一方都可能拒绝这项请求。正常访问策略只能在新的认证成功后运行。因此，运营方应同时记录配置完成、后续返回、拒绝结果，以及恢复采用完整重启还是 TLS 重新协商。否则，预期内的拒绝会被误认为配置故障，而仅统计成功配置又会隐藏从未准入的设备。（RFC 5422 第 3.5 节）

来源