摘要

  • EAP 方法可以正确验证对端，而策略、AAA 属性、认证器动作、密钥交付和底层数据通路仍可能分别失败。
  • 可审计的接入记录应把方法对话、EAP 结果、RADIUS 报文、授权判断、安全关联、受控端口与首次可用连接保留为不同凭据。

把“认证成功”放到故障工单里，往往像是在宣告身份系统已经完成全部工作。可是在真实链路上，这句话可能只表示某种密码学方法接受了凭据。会话上限仍可拒绝用户，指定 VLAN 仍可能不受设备支持，导出的密钥仍可能没有安装，受控端口也可能没有打开。

RFC 3748 于 2004 年以 Standards Track 文档定义 Extensible Authentication Protocol。Bernard Aboba 是五位署名作者之一，其他作者为 Larry Blunk、John Vollbrecht、James Carlson 与编辑 Henrik Levkowetz。文章不能把 EAP 归为一人的发明。更值得保留的是它的分工：EAP 是承载多种认证方法的框架，不是包办网络授权和可达性的系统。

peer 在链路上回应，authenticator 发起 EAP 并控制本地接入点，EAP server 结束认证方法。采用 pass-through 时，服务器可以位于远端 AAA 后端，接入设备只负责转送它并不理解的认证消息。于是，验证凭据的组件与最终打开数据通路的组件天然可能分离。

RFC 3748 明确指出，peer 即使通过认证，也可能因为授权不足而被拒绝，例如已经达到会话数量限制；AAA 代理也会影响授权判断。方法内部的受保护结果，只回答方法两端确认了什么。它不会自动公布服务等级、VLAN、过滤器、设备能力或端口状态。

EAP Success 是一张很窄的回执

认证方法成功结束后，authenticator 发送 Code 3 的 EAP Success。该报文不携带额外数据，不要求确认，也不会重传。若它丢失，peer 在特定条件下可以依据底层成功指示作出结论。因此，一份只含最后一个报文的抓包，既不能还原完整授权，也不能用缺包直接证明失败。

协议还要求：如果方法并未允许在当前状态结束，peer 必须丢弃连接一开始就出现的“罐装”Success。这条规则防止恶意认证器跳过方法交换。结果码必须与此前的方法状态一起解释，而不是被单独提升为身份证明。

EAP Success 本身没有记录 AAA 返回了哪些授权属性，也没有证明设备按这些属性打开受控端口。它更不会说明是否获得 IP 配置、是否安装了正确的流量密钥，或者第一条应用连接是否成功。

RADIUS 的判断位于另一字段

Aboba 与 P. Calhoun 合著的 RFC 3579 描述了 RADIUS 承载 EAP 的 pass-through 模式。NAS 转送 EAP 对话，直到后端返回 Access-Accept 或 Access-Reject。NAS 必须依据 RADIUS 报文类型决定接入，不能依据其中封装的 EAP 报文内容。

规范列出了不应发送的矛盾组合。若 Access-Reject 中封装 EAP Success，NAS 仍要拒绝接入，而 peer 可能认为认证已经成功。Access-Accept 与 EAP Failure 的组合会产生相反分裂。重点不是把异常当常态，而是承认 AAA 结果和 EAP 结果由不同字段表达、由不同组件消费。NAS 不能凭空制造报文来掩盖冲突。

Access-Accept 只结束认证阶段，还可能携带 VLAN、过滤器、服务或限制。设备若认识某项服务却无法提供，就应失败。后端也可能根据不同认证器的能力返回不同授权。同一有效账号在不同位置、漫游域或设备状态下，可以得到不同且合理的结果。

导出密钥不等于数据通路已建立

Aboba、Dan Simon 与 P. Eronen 合著的 RFC 5247 把方法执行、密钥传输和底层安全关联拆开。产生 Master Session Key 只是中间事件。AAA 还要把所需密钥材料送到正确的认证器，底层协议再导出或安装保护实际流量的临时密钥。

“MSK 已生成”没有回答接收者、范围、会话标识、临时密钥或安装状态。它也无法证明安全关联已经完成。隧道方法的内外层可能输出不同 peer 或 server 标识，peer 在交换开始前也未必知道后端会选择哪台 EAP server。

RFC 3748 进一步要求，认证后的数据保护应绑定到真正完成 EAP 的实体。逐包完整性、认证与防重放必须与派生密钥连接。缺少这种绑定，正确的认证对话之后仍可能出现被修改、伪造或重放的流量。

有效凭据也可能落在错误网络

同一凭据有时可用于多个服务。这给错误或恶意 NAS 留下空间：它对 peer 宣称一个网络，却把用户带到另一个网络。RFC 6677 将其称为 lying NAS 或 lying provider 问题。channel binding 让 peer 在方法保护之下提交自己看到的服务属性，后端再把它们同认证器声明和既有记录比较。

channel binding 不是“客户端已经认识网络”的抽象口号。它需要保存四项材料：peer 看到的广告、NAS 的声明、后端的预期，以及保护比较过程的方法。任一项丢失，强认证仍可能在错误服务上成功。

RFC 5216 在 EAP-TLS 中给出同类边界。证书路径验证成功后，实现仍须判断证书中的身份是否适合并获准用于当前 EAP-TLS 环境。密码学有效性是授权输入，不是跨部署通用的政策结论。

按顺序保存接入凭据

一份有用的账本从网络发现、peer 意图、NAS 标识和端口开始。随后保存方法选择、完整对话、受保护结果、peer 与 server 标识、外层 EAP 结果、RADIUS 类型、授权属性与本地能力判断。再往后才是密钥导出和接收者、安全关联、受控端口、IP 配置、首次可用连接及计费或断开记录。

这条链把无效凭据与“凭据有效但政策拒绝”分开，把 Access-Accept 与“不支持所请求服务”分开，也把方法完成与数据通路完成分开。它让故障归因落到真正控制结果的组件。

来源