摘要

  • RFC 9813 允许一个 IP 地址对应多个 TLS-PSK RADIUS 客户端，也允许一个客户端从多个地址出现；PSK 身份只负责选中候选关系，只有随后对 PSK 的验证才证明对端持有相应凭据。
  • 可审计的系统必须分别保留粗粒度网段准入、身份输入校验、客户端表版本、关系专属地址检查、TLS 证明、RADIUS 层完整性、策略决定、会话恢复和实际服务结果的凭据。

传统 RADIUS 客户端表通常以源 IP 地址为键。报文到达后，服务器据此找到一行配置，取得共享密钥，再检查 RADIUS 报文。那一行其实同时绑定了三个问题：对端是谁、它可以从哪里来、它可以做什么。

当地址稳定且独占时，这种压缩看似有效。NAT 和移动网络却把它拆穿了。多个设备可能共用一个外部地址；同一设备也可能在一周内经过固定线路、蜂窝网络和备用出口。扩大允许网段只能恢复可达性，不能恢复关系精度。为每个可能地址复制一行配置，则会制造不断漂移的管理状态。

2025 年 7 月发布并成为 BCP 243 的 RFC 9813，补齐了 RADIUS over TLS/DTLS 使用 TLS-PSK 时的操作规则。它的核心变化是：以 PSK Identity 取代源 IP 来识别客户端。但这里的“取代”只发生在查表键上，不会让地址、应用层密钥、授权或执行结果自动消失。

明文选择器先于身份验证到达

服务器必须先知道该尝试哪一个 PSK，才能验证对端是否持有它。因此客户端会在 TLS 交换早期发送 PSK 身份。这个值以明文出现，而且发送它的对端此时尚未通过验证。任何能够抵达监听端口的人都可以编造一个看起来合理的字符串。

如果身份含有站点名、机构名或职能，它还可能泄露隶属关系。使用不透明的用户部分，或按 Network Access Identifier 组织命名空间，可以减少不必要的信息暴露，却不会把选择器变成秘密。

查到一行记录，只证明“收到的字符串与配置状态相符”。它不证明发送者持有 PSK，不证明来源地址属于该关系，也不证明该客户端有权发送某类 RADIUS 请求。若监控系统在查表命中时就写下“客户端已认证”，只是把旧有的 IP 地址迷信搬到了新字段。

未认证输入必须止步于严格边界

RFC 9813 明确把原始身份视作敌对输入。它可能包含无效 UTF-8、嵌入式 NUL、对 SQL、LDAP、REST 或 shell 有特殊含义的字符，长度还可能逼近 TLS 允许的 65,535 字节。若把它直接拼接进查询，协议选择器就变成了注入接口。

安全顺序应当是：先限制长度，识别静态身份或恢复票据的命名空间，验证编码和语法，使用有版本的规范化与比较规则，再按实际查询接口转义；任一步失败都关闭连接。规范化不能悄悄把两个管理身份合并。软件升级如果改变大小写或 Unicode 处理，必须能够说明它是否改变了命中的关系。

审计凭据可以保存原始输入的有界哈希、校验结果、规范化查找值、规则版本和被选中的记录 ID。日志不应把攻击者控制的长字符串复制到所有告警系统。拒绝原因、解析器版本、观察到的网段和哈希已经足够支撑调查。

客户端表的一行是一段双边关系

RFC 9813 描述的逻辑 TLS-PSK 表可以绑定允许网段、PSK 身份、对应 PSK、其他 TLS 凭据，以及是否要求客户端证书。TLS 建链之后，原有 RADIUS 客户端策略仍然决定它能发送什么请求。

因此，正确的资产单位不是某台设备的“全球身份”，而是特定客户端与特定服务器之间的关系。同一台设备连接主服务器和备服务器时，可以拥有两组独立凭据。两个管理域即使共享基础设施，也不应因此共享可相互冒充的密钥。

RFC 9813 要求实现能够为每一条客户端—服务器关系配置唯一的身份和 PSK。运营者仍可基于本地条件选择复用，但复用的风险必须显式承担。二十个客户端共用一个 PSK 时，任何一方都能制造同样的密码学证明；日志里的身份字符串再精确，也掩盖不了底层权限是共同持有的。对称密钥泄露还可能让攻击者冒充服务器，因此跨无关组织使用 PSK 尤其危险。

这体现了 Minimum Initial Specification 的边界：共同层要求实现具备隔离能力，轮换周期、维护窗口和具体拓扑则由本地决策承担。

地址没有失效，只是不再充当姓名

RFC 9813 保留两道来源检查。第一道发生在读取身份之前：不属于任何全局允许网段的连接被尽早拒绝。第二道发生在选中客户端记录之后：当前来源还必须满足该关系专属的允许范围。

第一道控制监听服务的暴露面，第二道回答“这条已选关系是否可以从这里出现”。在这两道边界内，服务器应支持一个 NAT 地址下的多个身份，也应支持同一身份从不同地址出现。

调查时，网段通过只说明服务器观察到的网络位置符合规则。PSK 通过只说明对端持有分配给候选关系的对称密钥。两者结合会缩小结论，却仍然不能证明究竟是哪一台物理设备或哪一个人在使用密钥。地址从“姓名”退回为一个证据坐标，反而更诚实。

TLS PSK 与 RADIUS 共享密钥不能合并

TLS PSK 证明 TLS 关系并保护通道；RADIUS 共享密钥用于封装在其中的协议检查。RFC 9813 禁止两个角色复用同一个值，并要求实现拒绝这种配置。同一个 PSK 也不应跨越 TLS 1.3 和更早版本；RFC 9258 提供了把外部 PSK 与协议版本、KDF 和上下文绑定的导入机制。

只有一个“站点密钥”输入框的管理界面会主动抹掉这些边界。界面应分别标注角色，显示非秘密的版本和依赖关系，在不记录密钥材料的前提下阻止相等值。TLS 握手成功只说明通道的一部分成立，不能代替 RADIUS 报文检查或授权决定。

轮换必须同时退休旧身份

因为身份是 PSK 的查找键，PSK 更新时身份也必须更新。若只在同一名字下替换密钥，旧客户端、分发失败和针对已知名字的攻击会表现成同一种错误，重叠期也失去可见性。

受控轮换会创建新的关系代次，记录新身份首次成功，限定新旧并存窗口，观察旧身份最后一次成功，然后明确禁用旧身份。退休之后的迟到尝试成为可操作信号。配置已下发不等于轮换完成；旧权限真正关闭才算完成。

“最后出现时间”可以帮助识别休眠客户端，但沉默既可能是退役，也可能是故障、季节性停用或被盗。自动失效之前，责任人、阈值、例外和恢复路径必须已知。

会话恢复创造第二套身份命名空间

TLS 1.3 会话恢复也使用 PSK 和身份，但它们由 TLS 子系统生成，不是管理员配置的静态客户端名。RFC 9813 不建议在这种 TLS-PSK 场景启用恢复。若迁移期必须使用，就要把不透明票据与静态身份分开保存、分开解析，未知值直接关闭连接，任何冲突都不能让票据落入静态表。

恢复成功也不是永久授权。服务器必须可靠取回初次完整握手的身份与策略上下文；来源地址等条件变化时，需要重新评估相关规则。缓存无法安全恢复时应回到完整握手。票据及相关缓存即使声明更长寿命，也不能超过七天。

一条完整证据链比“已知客户端”更有用

每次接受连接，都应能够还原：粗粒度网段准入、身份语法和命名空间、规范化规则、客户端表的精确代次、关系专属来源检查、TLS 版本与 KDF、PSK 持有证明、恢复缓存、RADIUS 报文检查、客户端策略、NAS 实际动作，以及用户或系统观察到的服务。前一步为真，后一步仍可为假。

Running-Code Primacy 要求用正在运行的解析器、查表和策略引擎证明实际选择了什么，而不是用标准字段或配置截图代替运行事实。On Reality Layers 则说明为什么任何一张凭据都不能替所有层发言。

RFC 9813 的贡献不是把 IP 王座交给 PSK 身份，而是让位置、选择、证明、授权和结果重新分开。运营者只有在数据模型和审计链中保留这些边界，才能真正得到它承诺的灵活性。

来源