摘要

  • RFC 5193 把部署环境分成两类:PANA 之前,PaC 到 EP 的信道已经能够抵抗冒充和窃听;或者 PANA 运行在未受保护的信道上,成功后还必须通过安全关联协议建立逐包保护。
  • 这个分类会约束 EAP 方法是否必须适应开放信道并产生后续所需的密钥材料。因此,分类必须绑定接口、对端、EP 路径、保护范围和时间,不能由站点、设备型号或一次旧观察永久继承。

方法选择经常被描述为算法偏好:这个站点用 A,那个站点用 B。RFC 5193 提醒我们,选择背后还有一个环境事实。方法是在怎样的信道上运行?在第一条 PANA 消息出现之前,冒充与窃听风险是否已经由下层处理?

如果答案是“已经处理”,框架允许不再执行 PANA 之后的安全关联。如果答案是“没有”,方法就必须面对开放信道的威胁,并能生成后续协议需要的密码材料。两类环境不能只在文档里不同,执行结果却共用一个模板。

方法选择器依赖的不是站点名称

站点可以包含多个附件。办公室交换端口可能依赖物理隔离;企业无线可能已经完成下层认证与加密;访客无线可能没有同等保护;临时回传还可能把流量送到另一台 EP。它们共享地址、建筑甚至控制器,不代表共享安全属性。

选择器真正需要的输入,应当是当前附件的证据版本:PaC 与接口、下层对端或物理段、预期 EP、保护机制、抗冒充和抗窃听范围、观察时间与有效期。站点标签可以是查找策略的入口,不能直接成为结论。

如果证据无法解析到当前附件,最诚实的状态是“未证明”。本地策略可以选择更强方法、要求建立安全关联、拒绝接入或交给人工。RFC 5193 没有替部署者规定这套故障策略,但它没有授权系统把未知改写成已保护。

产出密钥是环境分支的后果

在 PANA 之前没有安全信道的环境里,RFC 5193 要求 EAP 方法能够抵抗相关攻击,并创建后来由安全关联协议使用的密码密钥。这句话给出了清晰的依赖链:环境判断影响方法;方法能力影响后续协议的输入;后续协议再创建逐包保护。

任何一层都不能代替下一层。方法“支持密钥”不等于这次执行产出了密钥;产出密钥不等于任务已调度;任务成功不等于安全关联属于当前接口、对端和 EP。

反方向同样重要。不产出后续所需密钥的方法未必天然错误。如果部署确实拥有满足要求的预先安全信道,它可能符合该环境的选择。错误在于系统用没有附件证据的站点模板证明了这个前提。

记录应当保存方法标识、选择规则版本、环境证据版本、所需攻击韧性、密钥产出预期和实际结果。这样,审计才能区分“设计上无需密钥”和“因为错误分类而没有密钥”。

成功不能倒推前提正确

一次 PANA 会话可能完成,但这不能证明初始信道在整个过程中免受窃听或冒充。协议结果属于协议表面;环境证据属于下层附件。后来的成功不会回到过去替前提签名。

运营系统常犯的错误,是在终态出现后清理中间不确定性。成功状态把 environment_source=site-default 变成了“已验证安全环境”,因为无人再追问。结果越绿,最早的证据缺口越难被发现。

应当保留决策时刻的原始输入,包括未知值与冲突。若下层证据在会话结束后才到达,它可以补充观察,却不应伪造为决策前已经存在。时间顺序本身就是证据。

下层安全不是一个统一产品

RFC 5193 给出的预先安全信道例子包括物理保护的 DSL 线路,也包括已经认证、授权并启用链路层加密的无线环境。二者都可能满足特定范围内的要求,但证明方式完全不同。

物理隔离需要段、端口、拓扑和共享边界。密码保护需要对端身份、协商、密钥状态、完整性或保密范围。把二者都压缩成 encrypted=true 会丢失物理方案;压缩成 trusted_link=true 又会掩盖密码方案的对端绑定。

正确的数据模型允许不同证据形状,却要求它们共同回答范围问题:谁与谁之间,保护什么,何时有效,哪一个 EP 处在边界上。

共址不会替客户端信道加密

PAA 与 EP 可以共址,PAA 与认证服务器也可以共址。共址减少的是功能实体之间的通信距离:网络协议可以变成内部 API。它没有改变 PaC 进入这台设备之前经过的接入链路。

如果方法选择器看到“PAA/EP 同机”就判定 secure-before,它把内部拓扑属性投射到了外部信道。即使所有后台功能都在一个进程里,开放无线上的客户端仍然可能面对窃听和冒充。

同理,RADIUS 或 Diameter 返回的认证与授权属性不能证明下层信道。认证服务器没有观察的事实,不会因为其决定重要就自动属于它。

变更必须切断继承链

接口切换、无线重关联、EP 故障转移、VLAN 延伸、桥接、控制器迁移、拓扑替换都可能改变安全环境。会话名称或设备身份保持不变,并不保留附件事实。

每次变更应产生新的附件版本。旧证据留作历史,新的选择只能引用新版本。若旧安全关联任务稍后完成,它也只能证明旧附件上的结果,不能把状态搬到当前路径。

这不是 RFC 5193 明文规定的遥测格式,而是对其依赖关系的忠实落实。Lu Heng 所说的“记录描述现实”在这里非常具体:模板能记录方法选择,不能凭记录本身让开放信道获得保护。

Sources

  1. RFC 5193 HTML
  2. RFC 5193 文本
  3. RFC 5193 记录
  4. IETF Datatracker RFC 5193
  5. RFC 5193 历史
  6. RFC 5193 引用
  7. RFC 5193 勘误
  8. RFC 5191
  9. RFC 5191 记录
  10. RFC 4058
  11. RFC 4058 记录
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu:现实层
  19. Heng Lu:最小初始规范
  20. Heng Lu:运行代码优先