摘要

  • RFC 5216 定义了基于证书的 EAP-TLS 认证和密钥派生。证书链、CertificateVerify 与 Finished 能证明明确的密码学事实，却不会替交换机创建 VLAN、安装 ACL 或打开受控端口。
  • EAP 与 AAA 文档明确保留了后续边界：认证成功后仍可能拒绝授权；后端也可能允许接入，而 NAS 因本地资源不足无法交付；拥有密钥不自动证明有权拥有密钥。
  • 可靠运营需要把证书、TLS、EAP、AAA、NAS 执行和真实流量串成可核验凭证链，不能让一个“证书通过”绿灯继承所有下游层的权威。

四次成功，端口仍然关闭

设想一个明确标注的合成场景。08:14:02，终端验证 EAP 服务器的证书路径与名称，服务器也验证终端证书。CertificateVerify 证明双方掌握相应私钥，Finished 证明双方对受保护握手记录与密钥状态达成一致。密码学面板变绿。

08:14:03，后端把已认证的证书身份与 NAS、物理端口和目标网络上下文组合，返回某个角色和 VLAN 的条件授权。策略面板也变绿。

08:14:04，接入设备发现目标 VLAN 并不存在于所需转发上下文中，因而无法执行授权。受控端口保持关闭。没有 DHCP，没有 IPv6 邻居状态，也没有应用数据穿过边缘。

08:14:20，只采集前两个事件的管理仪表盘显示“EAP-TLS 成功”。这不是伪造；它的问题更隐蔽：系统把关于身份与授权意图的真实证据，提升成了关于网络已经交付的错误结论。

这个场景不是对真实运营商、设备厂商或事故的描述，而是依据 RFC 5216、RFC 3748、RFC 3579 与 EAP 密钥框架构造的边界测试。每个组件都可能行为正确，错误却仍会出现在被压扁的总状态里。

证书究竟证明了什么

RFC 5216 使用 TLS 为 EAP 提供基于证书的双向认证、受完整性保护的密码套件协商、密钥交换和密钥派生。完整双向握手中，路径验证回答证书是否在验证者采用的信任政策下连接到可接受的锚；CertificateVerify 回答端点是否能用对应私钥给握手签名；Finished 回答双方是否抵达同一受保护的握手记录与秘密状态。

这些事实非常重要，正因如此才不应被夸大。证书主体或 SAN 可以为策略提供已认证身份，却不携带交换机端口的实时状态、VLAN 当前容量、ACL 安装结果、AAA 代理链的完整性或应用可达性。

EAP-TLS 的后续更新让这条边界更清晰。RFC 8996 废弃 TLS 1.0 和 1.1，RFC 9190 定义 TLS 1.3 的握手与密钥计划，RFC 9965 又加入围绕 eap.arpa 的配置机制。RFC 5216 仍是基础文档，但不能用 2008 年的流程图替代当前更新集；同样，也不能用 Standards Track 身份替代部署与执行证据。

RFC 9190 新增的授权章节适用于一般 EAP-TLS，而不仅限于 TLS 1.3。它要求授权和计费基于证书、PSK 身份以及恢复会话保存的受认证资料，而不能信任未被 EAP-TLS 认证的 EAP-Response/Identity。服务器还可以结合外层协议提供的 NAS、MAC、IP、端口和 SSID 信息做策略决定。

这说明认证不是失败了，而是它本来就只为授权提供输入。谁把输入显示成最终结果，谁才制造了治理错误。

EAP 早已拒绝“一盏绿灯”

RFC 3748 明确区分认证结果同步与授权同步。它列出的三种情况几乎就是现代接入事故的诊断表：EAP 服务器可能看不到 AAA 代理作出的授权决定；AAA 服务器可能等认证成功后才发现不能授权；后端可能允许接入，但认证器因为暂时缺少资源无法提供服务。

第一种情况下，决定发生在另一个主体；第二种情况下，身份事实成立但许可被拒绝；第三种情况下，许可成立而执行环境不足。三个状态都不能被“EAP method completed”覆盖。

RFC 4137 把 EAP peer 与 authenticator 的状态机及其对下层的信号形式化。状态机输出依然只是接口事件，不会暗中检查交换芯片、地址分配和应用路径。因此 EAP-Success 应被当作有价值但有边界的凭证：它说明 EAP 会话到达规定结果，不等于任何网络都会以任何权限交付服务。

有密钥，不等于有权持有密钥

EAP-TLS 会导出 MSK 与 EMSK。RFC 5247 却故意把过程分为不同阶段：EAP 方法在 peer 与服务器之间派生材料；AAA 把适当材料运到认证器；安全关联协议再证明占有并生成临时密钥。

该框架给出一句极其重要的限制：证明掌握密钥材料，不必然证明有权掌握这些材料。四次握手可以证明终端和认证器拥有同一份 EAP 派生材料，但不能单独证明后端确实授权这台认证器为这个终端持有它。

RFC 4962 把 peer 与 authenticator 的授权列为独立要求；RFC 4017 也把双向认证、密钥强度和授权分开；RFC 5295 则为 EMSK 派生根密钥规定用途与范围。密码学材料不会因为足够随机，就自动携带组织权威。

Access-Accept 是给特定执行点的指令

常见架构中，NAS 在终端与后端 RADIUS 之间转送 EAP。RFC 3579 区分 RADIUS 的 Access-Accept/Reject 与其中封装的 EAP 内容。Reject 要求 NAS 拒绝接入；Accept 结束认证阶段，并可携带角色、VLAN、过滤器与会话限制。

但 NAS 不是被动打印机。RFC 3579 要求：如果设备无法提供 Access-Accept 所要求的服务，就必须把它当成 Access-Reject。RFC 3580 还指出，RADIUS 包类型与封装的 EAP Success/Failure 可能冲突；认证器的接入决定必须依照 RADIUS 结果，而不是孤立的 EAP 字段。

后端日志最多证明它发送了哪条指令。只有 NAS 的本地证据才能回答：是否识别属性、是否找到 VLAN、是否安装 ACL、是否完成安全关联、受控端口是否真正转为开放。

而端口开放仍不是业务终点。DHCP 可能失败，IPv6 可能没有完成邻居发现，DNS 可能不可用，目标应用也可能被后续策略拦截。每一层都必须为自己的执行结果签字。

同一台 NAS 可以讲两个故事

RFC 6677 处理所谓 lying NAS 或 lying provider 问题：转发型认证器可以向终端展示一套网络身份与属性，同时向 AAA 提供另一套。Channel binding 让终端与服务器通过受保护通道比较各自看到的网络属性。

这个机制本身就证明：终端证书不会自动认证 SSID、物理端口、漫游提供商、下层类型或服务属性。这些事实来自不同主体，只有在来源与一致性得到验证后，才能进入授权。

Channel binding 也不是业务交付收据。它可以在终端加入恶意网络前验证定义好的上下文，但不会证明目标 VLAN 稍后完成转发、应用防火墙放行或服务五分钟后仍在。

RFC 7542 约束 NAI 的处理，RFC 9427 更新 TLS 1.3 在 TLS 型 EAP 方法中的使用。它们强化证据链的身份和协议转换，却没有消灭证据链本身。

会话恢复延续关系，不延续所有权限

TLS 1.3 会话恢复可以减少往返与重复证书工作。RFC 9190 说，服务器接受恢复后，会话被视为已经认证并与此前认证或恢复安全关联；同时它要求谨慎，不能让恢复会话获得超过原会话意图的权限。

原因在于多只时钟从不会完全同步。票据可能仍然有效，而证书已经撤销；设备角色改变；员工权限回收；NAS 移动；SSID 改策；VLAN 下线。证书有效期、撤销状态、票据寿命、授权寿命、端口会话与应用结果是六个不同时间轴。

RFC 9190 还加强 TLS 1.3 证书链的撤销检查，并讨论 OCSP stapling，因为终端往往要等认证完成才有普通网络连接。这个启动循环没有降低标准价值，反而提醒运营者：认证前的证据供应与认证后的服务交付是两个控制面。

让凭证链能够诚实失败

成熟系统应连接窄凭证，却不允许任何凭证冒充下一层。

证书凭证记录信任锚、叶证书与链哈希、验证名称、有效期、撤销方法和结果。TLS 凭证记录版本、套件、CertificateVerify、Finished 与安全会话标识，绝不泄露密钥。

EAP 凭证记录方法、受保护结果、导出密钥标识与 Success/Failure。AAA 凭证记录已认证身份、NAS、端口、上下文、策略版本、Accept/Reject 和完整授权属性。密钥运输凭证说明哪台认证器被允许接收哪种范围的材料。

执行凭证属于 NAS：属性解析、VLAN/角色解析、ACL 安装、安全关联和受控端口转换。业务凭证更靠后：地址获取、ARP/邻居状态、DNS、路由、第一次成功应用交换与明确失败原因。

负面状态必须保留。“证书有效，授权拒绝”没有矛盾；“收到 Accept，目标服务不可用”不应被隐藏；“端口开放，应用失败”也不说明认证错误。边界越诚实，故障越容易定位。

来源

  1. RFC 5216
  2. Datatracker 上的 RFC 5216
  3. RFC 5216 状态
  4. RFC 5216 历史
  5. RFC 5216 勘误
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Lu Heng：Running-Code Primacy
  21. Lu Heng：Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption