摘要

  • RFC 9645 为 TLS 客户端身份、服务器身份、对端认证、Hello 参数与保活策略定义了可复用的 YANG grouping；它明确提供的是“最小公分母”配置，不是逐会话事实记录。
  • 已配置的证书、裸公钥或 PSK 只能证明运营者允许了一种可能性，不能证明对端是否请求、实际提供了什么、验证是否通过、会话是否恢复，以及应用最终接受了哪个主体。
  • 可辩护的认证路径回执必须把模型与配置版本连接到真实握手分支、对端身份、验证结论、可选客户端认证、应用主体和操作结果；看不见的部分必须缩小结论。

配置树回答的是“允许什么”

设想一次高权限变更之后的审计。服务器配置里有 X.509 身份，也保留了裸公钥能力；应急通道预置外部 PSK；客户端侧的信任材料引用全部可解析；TLS 库还报告支持获批版本与密码套件。每一项都可能真实且合规。

审计者问：执行那次变更的连接，究竟由谁认证了谁？

配置系统无法直接回答。它只能列出当时允许的路径。

RFC 9645 定义 ietf-tls-common、ietf-tls-client、ietf-tls-server，并关联由 IANA 维护的密码套件枚举模块。客户端和服务器 grouping 专注 TLS 自身，故意不接管底层地址、端口和连接建立方式。文档还把通用模型称为“最小公分母”，高级特性留给消费它的应用模型扩充。

这种克制不是缺陷。它让共同规范保持可复用，也明确了权力边界：模型有权规定如何表达意图，却没有替一次握手、一次身份判断和一次业务授权作证。

四种身份分支不能压成一个绿色图标

RFC 9645 的客户端与服务器身份 choice 涵盖证书、裸公钥、TLS 1.2 PSK 和 TLS 1.3 外部 PSK。这四条分支的证据含义不同。

证书路径涉及证书链、参考身份、时间、密钥用途、签名算法、信任锚和本地策略。裸公钥没有同样的证书链语义，通常依赖精确可信密钥关系。TLS 1.2 PSK 依照较早协议的共享秘密与标识规则工作。TLS 1.3 外部 PSK 还包含外部身份、哈希以及可选的 context 与目标参数。

RFC 9257 提醒，PSK 标识可能在网络上暴露并具有可链接性；多人共享同一 PSK 时，成员之间可以互相冒充。RFC 9258 又把带上下文导入的 PSK 与无上下文 PSK 区分开。于是，“PSK 验证成功”可能只能证明某个群体掌握共享秘密，不能天然定位到单一设备或操作者。

运营回执的第一原则因此不是记录“TLS 已启用”，而是记录实际认证分支，并绑定本次会话加载的具体凭据版本或指纹。过早把四条路径归一，事后就无法恢复它们的责任差异。

服务器认证与客户端认证是两条独立链

客户端 grouping 将 client-identity 与 server-authentication 分开。客户端身份是可选项，因为客户端认证也可能在 TLS 之上的协议层完成。即使配置了客户端凭据，也只有服务器在建立会话时提出请求，客户端才会按路径提供。

服务器 grouping 同样把 server-identity 与可选 client-authentication 分开。没有后者时，服务器不应请求客户端凭据；配置后，CA 证书、精确终端证书、裸公钥和 PSK 支持又构成可叠加的客户端认证集合。

这说明“启用了双向 TLS”不是一条足够严谨的审计结论。它可能只代表服务器具备请求客户端证书的能力；也可能该监听器根本没有使用这段配置；还可能连接由会话恢复完成，没有重复完整证书交换。TLS 层即使识别了一台设备，应用也可能把它映射成共享账户，或者拒绝为它创建任何主体。

回执应逐项记录：服务器是否请求客户端认证，客户端提供哪类身份，服务器采用何种验证方法，验证结果如何，应用把结果映射成什么主体，以及该主体是否获准执行操作。

恢复会话不能伪装成一次新的证书验证

TLS 1.3 使这一边界更加关键。当前规范 RFC 9846 将版本、签名算法、支持组、key share 与 PSK 身份保持为不同握手输入。服务器选择兼容的 PSK 与密码套件，并验证把 PSK 绑定到当前握手 transcript 的 binder。

这个绑定能证明当前交换使用了对应 PSK，却不等于当前连接重新执行了最初的证书路径验证。会话恢复可能继承早先连接建立的安全上下文。若报表只看到“TLS 成功”，再从静态配置取出一张证书展示，读者会误以为该证书在本次连接中重新出现并被检查。

外部 PSK 与恢复 PSK也不能混为一谈。前者来自带外供应，可能有或没有上下文绑定；后者来自先前会话。若存在 early data，应用字节还可能在普通一往返流量的确认边界之前发送。只记录最终握手成功，会掩盖关键操作处于不同的重放与授权风险面。

因此，回执必须明确是完整握手、恢复握手还是含 early data 的路径，并说明 PSK 的类别与上下文状态，但绝不能暴露秘密本身。

版本和密码套件不是身份结论

hello-params-grouping 可以设置 TLS 版本上下限和用户排序的密码套件列表；可选的 supported-algorithm 状态还能描述实现能力。这些字段重要，却回答不了“对端是谁”。

IANA TLS 注册表明确警告算法会随时间削弱，专家批准也不是安全背书；TLS 1.3 的密码套件语义还与 TLS 1.2 及更早版本不同。RFC 9325 提供部署建议，RFC 9852 则在其适用范围内要求使用 TLS 的新协议必须支持 TLS 1.3。标识符可以保持不变，围绕它的安全判断却会变化。

会话回执需要记录实际版本与密码套件，但必须与身份模式、对端材料和验证结果分栏。“TLS 1.3 + 获准密码套件”只能描述通道的一部分，不能证明该通道通过证书、裸公钥、外部 PSK 还是恢复状态认证对端。

从授权配置走到运行事实

RFC 8342 区分预期配置与运行状态。RFC 8341 控制谁能改写敏感节点。RFC 9641 与 RFC 9642 又为 RFC 9645 提供 truststore 和 keystore 引用。这些层都不可缺少，但每层只证明自己的事实。

keystore 引用可以成功解析，而握手使用另一份凭据；truststore bag 可以存在，而对端根本没有提供证书；配置可以进入运行态，而流量从未到达目标监听器；TLS 可以验证一把密钥，而应用拒绝映射主体；应用主体可以获准，操作仍可能失败。

Heng Lu 关于符号权力与运行现实的区分在此非常具体。模型支配共同词汇，变更流程支配组织意图，TLS 栈执行一条分支，应用决定该身份拥有什么权利。任何一层都不应借用其他层尚未产生的权威。

一份最小但完整的认证路径回执应包括：

  • RFC 与 YANG 模块修订、feature、deviation 和消费模型；
  • 已应用配置的版本、来源 datastore、批准者与生效时间；
  • 端点身份分支，以及实际解析的 keystore/truststore 引用；
  • 本次加载凭据与信任材料的受保护指纹或版本；
  • 会话关联标识和可信时间戳；
  • 协商版本与密码套件，并与身份模式分离；
  • 完整、恢复或 early-data 路径，以及 PSK 类别与上下文状态；
  • 对端实际提供的身份、验证方法、输入、结果与不确定性；
  • 客户端认证的请求、响应、验证与应用主体映射；
  • 握手完成、告警、重试或回退历史；
  • 应用授权、操作、验收条件与结果；
  • 无法观察的字段及有权批准最终表述的责任人。

这些 RFC 没有规定统一回执。本文提出的是从规范边界推导出的运营控制。它的最低承诺应是：对于已标识会话和操作，组织能够证明在某版已应用配置下，实际走了哪条认证路径、验证了什么身份、映射出什么主体，并得到什么结果。

来源

  1. 最小初始规范
  2. 现实层与符号权力
  3. 运行代码优先
  4. RFC 9645 文档历史
  5. RFC 9645 信息页
  6. RFC 9645 HTML
  7. RFC 9645 纯文本
  8. RFC 9645 XML
  9. RFC 9645 内联勘误
  10. IANA TLS 参数
  11. IANA TLS 密码套件 YANG 模块
  12. RFC 9641：Truststore 模型
  13. RFC 9642：Keystore 模型
  14. RFC 9846：现行 TLS 1.3
  15. RFC 9852：新协议的 TLS 1.3 要求
  16. RFC 9325：TLS 安全部署建议
  17. RFC 9257：外部 PSK 指南
  18. RFC 9258：导入外部 PSK
  19. RFC 8341：网络配置访问控制
  20. RFC 8342：网络管理数据存储架构