摘要

  • 只有客户端与服务器通过 ALPN 选中 radius/1.1，共享密钥与基于 MD5 的数据包认证、属性混淆才会在这条 TLS 或 DTLS 连接上退出；RADIUS/UDP 与 RADIUS/TCP 完全不在此次修改范围内。
  • 判断迁移不能只看 RFC、软件版本或“支持”清单，而要逐跳证明能力已经被提供、协商、强制，并最终关闭旧路径。

一份把旧决定写进正文的 RFC

技术标准很少主动保留自己的犹豫。RFC 9765 却在开篇说明，RADEXT 当年为 RADIUS 增加 TLS 与 DTLS 传输时，仍保留了数据包里的共享密钥与 MD5 处理。TLS 被当成包裹旧协议的外层，编码、解码、验证规则因而不用同步大改。DeKok 随后给出罕见的回顾：这个决定事后看来很可能是错的，而他本人也参与了当时的选择。

这不是把前人写成反面角色。兼容性曾经解决了真实问题——运营者可以先得到受保护的传输，而不必一次性替换所有 RADIUS 实现。代价则延后显现：TLS 已经提供机密性与完整性，内部仍运行一套依赖 MD5 的包级机制。随着合规环境拒绝已知薄弱的摘要算法，这套重复设计开始阻碍验证、采购与维护。

DeKok 的经历让这次修正不只停留在纸面。他的 IETF 个人页记载，他在 1997 年接触 RADIUS，1999 年启动 FreeRADIUS，并长期参与认证与协议工作组。FreeRADIUS 项目维护的是实际运行的策略服务器、客户端库和集成组件。可是，长期写代码不等于拥有协议主权。RFC 9765 是经过公开审议的 IETF 共识文件，类别仍是 Experimental；它邀请实现和评估，并没有宣布全球网络已完成升级。

信任从数据包移到连接

RFC 2865 描述的原始模型以客户端和服务器共同掌握的秘密为基础。共享密钥参与交换认证，User-Password 等内容则通过基于 MD5 的方法隐藏。RFC 6614 与 RFC 7360 后来分别规定 RADIUS 通过 TLS 与 DTLS 传输，但历史 RADIUS/TLS 仍保留包内的密钥与 MD5 运算。

RADIUS/1.1 把版本选择放进 TLS 握手。按照 RFC 7301 的 ALPN 机制，客户端提供自己能够使用的应用协议名，服务器从双方共同支持的集合中选择。只有结果为 radius/1.1 时，新配置才生效，而且要求 TLS 1.3 或更高版本。

选中之后，这一跳不再使用 RADIUS 共享密钥。Request Authenticator 与 Response Authenticator 的空间改为承载关联请求和响应的不透明 Token；Identifier 不再承担原功能；Message-Authenticator 不发送；User-Password、Tunnel-Password 等过去用 MD5 混淆的属性，以普通编码放进 TLS 提供的机密通道。

这里发生的是责任转移，而不是安全消失。TLS 必须正确验证对端，部署策略必须判断这个对端是否有权发送 RADIUS 请求，证书、密钥、密码套件和库更新也必须得到治理。删除重复的包级密码学后，传输层的失败会更加直接地成为接入系统的失败。

看起来相似，不代表状态相同

RFC 9765 刻意保持许多旧形态：包头大小不变，Code 和 Length 继续保持原义，未使用 MD5 混淆的属性仍有同样的编码与含义，端口也沿用 RADIUS/TLS 和 RADIUS/DTLS 的既有分配。因此，文件把 1.1 称作“传输配置”而不是另造一套完整协议。

但 1.0 与 1.1 不能在同一连接上混用。重新分配的字段、不同的验证方式和 Message-Authenticator 的处理，会使错误版本的大多数请求或全部响应被丢弃。从安全角度看，这种失败比静默接受错误数据更好；从运营角度看，它仍然会表现为用户无法认证、代理链断裂和难以解释的日志。

范围还要再缩小一层。CHAP、MS-CHAP 等材料可以继续作为不透明属性被转发。RADIUS/1.1 移除的是这一跳用于保护和混淆 RADIUS 数据包的 MD5 机制，不会自动重写所有被承载的认证方法，也不能证明后端再无任何旧算法。

真相以“这一跳”为单位

RADIUS 常常穿过代理与漫游链路。每个客户端—服务器连接都是单独的一跳。接入控制器到本地代理可以协商 1.1，本地代理到归属服务器却可能继续使用历史 RADIUS/TLS、UDP，或另一个被允许的传输。第一跳的绿色指标不能替下游作证。

ALPN 的价值正在于产生连接级证据。没有 radius/1.1 信号，软件不得自行假定已进入 1.1。RFC 建议同时支持两个版本的实现先允许 radius/1.0 与 radius/1.1，让新旧对端都能连接。运营者确认两端能力并观察到成功协商后，再把策略改为只接受 1.1，同时监测连接；若出现故障，可以暂时恢复双模式，查明问题后继续推进。

这套可回退路径避免“一刀切”，也制造了长期停滞的可能。供应商说“已经支持”，可能只表示代码里存在功能；采购清单打勾，可能只证明版本满足要求；偶尔选中 1.1，也不表示策略拒绝 1.0。可靠的迁移记录至少要区分五个状态：

状态 可验证证据
已支持 两端软件和 TLS 版本具备实现能力。
已提供 客户端握手确实发送相应 ALPN 名称。
已选中 生产连接记录 radius/1.1。
已强制 只能使用 1.0 的对端会被策略拒绝。
旧路已关 本次范围内不再允许历史配置与未保护传输。

缺少任何一列，“完成迁移”都只是计划语言。

DeKok 的价值不在“独自拯救”

InkBridge 将 DeKok 介绍为 FreeRADIUS 的创建者和负责人，这解释了他为何能横跨标准与运行实现，却不能把他写成 RADIUS 的唯一发明者。原始 RFC 有自己的作者，RADEXT 与 IETF 负责审议，TLS 库开发者完成协商逻辑，设备厂商决定功能如何暴露，代理链上的各运营者决定何时关闭旧版本。没有任何一方可以单独宣布端到端迁移成功。

更值得借鉴的是修正方式：公开承认旧折衷，保留仍能降低切换成本的包结构，把安全责任交给已经承担它的层，并用明确协商结果建立可观测边界。Experimental 状态提醒读者，这仍是一项等待广泛实现与验证的提案。作者声望不能替代运行代码，运行代码也不能替代生产连接的实际状态。

来源