摘要

  • RFC 9672 记录 IETF 的同意：OWE 今后的维护与发展转由 IEEE 802.11 工作组承担。
  • IEEE 版本要做到单凭自身即可实现、维护和修改 OWE；这项制度安排并不能证明某台设备采用了哪份规范或完成了升级。
  • 可靠证据链必须把维护权、精确文本版本、经审阅的差异、产品 build、认证测试范围、逐台配置和实际关联结果分别绑定。

移交文件已经生效，采购表也把标准名称更新了。可在无线控制器里，没有任何一条记录说明哪台接入点因为这次移交更换了固件。制度层完成了一次明确动作，运行层却没有被它远程改写。

这正是阅读 RFC 9672 时必须守住的边界。该文件确认：最初由 RFC 8110 描述的 Opportunistic Wireless Encryption，今后的维护和发展将在 IEEE 802.11 工作组内进行。它还要求 IEEE 复制这套协议，使 IEEE 自己的文件足以支持实现、维护与修改。

这不是一句空泛声明。它明确改变了未来规范工作的归属。但维护权移交不是运行时事件：不会自动刷新接入点镜像，不会扩大旧认证报告的范围，也不会证明客户端与 AP 在某次连接中协商了什么。

先看移交要解决的结构问题

RFC 8110 在 2017 年给 IEEE 802.11 环境定义了 OWE。客户端和接入点在不相互认证身份的情况下，为每次关联建立独立密钥，以减少开放无线链路上的被动窃听。协议文本在 IETF，承载它的 802.11 体系则由 IEEE 维护。

这种跨机构结构可以工作，但会产生同步成本。宿主规范发生维护或修订时，外部协议文本如何保持一致？实现者到底应该把哪些版本放在一起阅读？RFC 9672 没有声称过去出现过某个具体缺陷，而是把今后的维护放到最接近宿主机制的工作组中。

公开往来把这次移交的细节保留下来。2024 年 5 月 22 日，IEEE 802.11 发给 IETF 的 liaison 表示，在假定移交草案获批的前提下，OWE 已主动并入 REVme D5.0；该修订汇集了维护变更、编辑和技术修正以及已通过的修正案，IEEE 802.11 将继续维护 OWE。

9 月 6 日，IETF 的回复 宣布草案已经批准，RFC 8110 所述协议的维护正式移交。回复随后提出一个很现实的问题：应快速发布 RFC，还是等 IEEE 标准出版后加入明确的前向引用？IETF 表明它更愿意保留完整的规范链。

RFC 9672 最终在 2024 年 12 月出版，其中没有编号为 IEEE 802.11-2024 的引用。IEEE 802.11-2024 的官方记录显示，该标准于 2024 年 9 月获 Standards Board 批准，2025 年 4 月 28 日出版，并取代 802.11-2020。工作组网站现在也把它列为近期出版标准。

这些日期不能被夸大成技术断裂。它们证明的是：即使双方都同意移交，后继文件的编号、出版与交叉引用仍有独立时间线。运营者若只写“支持 OWE”，就把机构自己认真处理过的版本问题抹掉了。

“完整复制”之后更需要标明版本

RFC 9672 要求 IEEE 文件自身足以支持实现与修改，这是合理的最小共同层。后续维护者不必每次跨两个机构拼装规范，协议与宿主体系也能在同一程序中演进。

但对采购与审计而言，OWE 从此至少有几种不同指代：历史上的 RFC 8110、IEEE 后继文本、产品功能名、Enhanced Open 的市场表达、测试或认证项目，以及现场实际启用的服务。它们互有关联，却不能相互替代。

第一份回执必须来自文档层：精确记录 RFC、IEEE 版次、修订、修正案和勘误；保存稳定取证记录；把公开差异或经过审阅的条款映射绑定到两端。如果公开条件不足以完成逐条比较，应写明“本地未验证等价性”，而不是凭印象宣称完全相同，也不是反过来虚构差异。

这与“最小初始规范、未来决策本地化、采用自愿”并不冲突。共同规范越薄，越需要本地决策可见。运营者可以选择何时升级、采用哪家产品，但必须能指出它选择的是哪份共同基线，以及本地自由具体改变了什么。

产品声明必须落到可识别的二进制

第二份回执属于产品。供应商说“支持 RFC 8110”“符合 IEEE 802.11-2024”或“提供 Enhanced Open”时，应同时给出硬件修订、固件 build、控制器版本、客户端驱动或操作系统版本、声明日期和责任主体。

一条 release note 是关于声明的证据，不是关于整个实现的自动证明。它需要进一步说明覆盖了哪些规范变化、有哪些例外、哪些硬件无法获得同等更新。旧版本也不能仅因年代而被判定错误；它可能继续正确互操作。关键是可比的内容与结果，而不是发布日期的新旧。

认证和互操作测试是第三层。有效记录应包括测试项目及其版本、测试用例、实验室、设备 build、日期、结果与例外。认证标识可以帮助市场快速识别，却不能在高影响决策中替代测试边界。

采购合同还要处理未来。IEEE 发布下一项修正时，供应商如何判断受影响产品？首个包含修正的版本是什么？支持周期有多长？是否强制更换控制器或硬件？客户能否导出版本—测试—设备映射？如果这些答案只存在于供应商内部，开放规范也可能在执行层变成锁定。

能力、启用与实际协商不是同一个状态

固件中存在 OWE，不代表某个 SSID 已启用 OWE。控制器下发策略，不代表每台 AP 都已接收并执行。AP 提供能力，也不代表客户端在这次连接中走了预期路径。

因此需要把 build 与控制器策略版本、设备清单、逐台应用回执关联起来。记录服务集如何启用 OWE、迁移或共存如何安排、客户端宣告哪些能力、AP 最终选择哪些元素。然后用可复现的抓包与设备遥测观察一次关联。

抓包能证明这次连接里出现了什么，不能证明开发者依据哪份制度文本编写代码。IEEE 标准记录能证明文本的身份和状态，不能证明空中的报文。两种证据相连，才能形成有限而准确的结论。

安全边界也不能因维护权变化而漂移。RFC 7435把机会式安全放在渐进部署环境中：双方能力和策略决定能得到哪种保护，明确要求的认证加密不能被机会式机制取代。RFC 8110 同样说明 OWE 不认证对端，只保护无线介质，不提供端到端安全，并仍可能遭遇主动冒充。

BTW 已有一篇 Warren Kumari / RFC 8110 文章专门讨论“加密不等于认证”。本篇不重新占用那条论点。这里引用它，只为了防止新维护者、新标准编号或一次成功关联被错误扩写成新的身份保证。

修正发布只是交付链的起点

IEEE 今后可能发布 OWE 修正。规范层的工作到此完成，产品和运营层的工作才刚开始：供应商评估差异、修改代码、发布版本；实验室或内部团队验证；运营者批准试点、逐步上线、核对现场状态并保留回滚。

完整记录应包含新文本、差异、供应商采纳决定、首个实现版本、测试结果、变更批准、设备覆盖率、上线后观察和回滚条件。任何一步尚未完成，都不应借前一步的绿色状态隐藏。

“运行代码优先”不是否定标准，而是限制权力的推理。标准可以定义共同预期，不能替设备宣布已经执行；运行网络可以证明结果，不能独自定义所有互操作含义。RFC 9672 精确完成了维护权的移交。领导层的责任，是不把这项精确事实膨胀成它从未声称的部署事实。

来源