摘要

  • 在包含响应 token 的交换中，RFC 2025 把发起端的 randSrc 与目标端的 randTarg 依次拼成 Context ID。两边都贡献，才意味着两边都参与了把本次上下文与旧上下文隔开。
  • 单边 SPKM-2 只有 SPKM-REQ。目标端没有机会加入随机数，只能信任发起端对新鲜度的保证，或者拒绝该上下文；key-src-bind 加强的是请求、来源名与拟议密钥的绑定，不会凭空产生目标端贡献。
  • 建立上下文时防旧交换重放，与上下文建立后可选的逐消息 replay/sequence 服务，是两个独立层面。Context ID 也不证明授权、消息送达或业务完成。

一张能数出签发者的收据

RFC 2025 定义了 Simple Public-Key GSS-API Mechanism，即 SPKM。它的上下文建立 token 包含大量字段，其中 Context ID 的生成方式尤其适合审计：发起端先给出 randSrc；只要交换还有目标端响应，目标端就在响应中加入 randTarg，此后两者的拼接值成为该安全上下文的标识。

顺序揭示了贡献者。randSrc || randTarg 不是事后随手分配的编号，而是交换双方各自放入的一段“此前极可能没有用过”的材料。发起端由目标端的新增值知道自己看到的不是一段原封不动的旧响应；目标端也知道 Context ID 包含自己刚生成的部分。就这一点而言，它是一张范围很窄的双方收据。

“范围很窄”不能省略。RFC 2025 明确指出，这些随机数不要求不可预测，只要求以高概率从未使用过。这里需要的是跨上下文的不重复性，而不是秘密性。把它写成“高强度随机数”，不会让 Context ID 多证明任何事情。

四种交换里，少了一次响应就改变了证据

SPKM-1 无论单边还是双边认证都有目标端响应：单边形式是 SPKM-REQ、SPKM-REP-TI；双边形式再加 SPKM-REP-IT。双边 SPKM-2 同样有响应。只要有这一响应，目标端就能提供 randTarg，与 randSrc 一起构成 Context ID。

单边 SPKM-2 是例外。它只有一个 SPKM-REQ，没有承载 randTarg 的回程 token。于是 Context ID 就只有发起端的随机值。RFC 对后果的表述很清楚：目标端必须信任发起端提供的是新随机数，否则就应拒绝建立上下文。

这不是“一条消息比两条消息快”的版式差异，而是控制权发生了转移。在有响应的交换里，接受上下文的一方可以把自己的不重复值放进共同标识；在单边 SPKM-2 里，目标端只能评估发起端提供的证据。Context ID 仍然有用，却不能被描述成双方共同参与新鲜度生成的证明。

key-src-bind 修补了什么

RFC 2025 对单边 SPKM-2 还有一项专门要求：如果所用密钥建立算法本身没有把来源名绑定到上下文密钥，请求必须携带 key-src-bind。它是对编码后的来源名与拟议上下文密钥所作的 MD5 摘要。

这能帮助目标端判断收到的 token、所称来源和拟议密钥是否属于同一项请求，也能辅助目标端相信该 token 与密钥的新鲜性。但这个字段仍由发起端放进 SPKM-REQ。它没有创造响应，没有加入 randTarg，也没有表明目标端生成了任何新鲜材料。

绑定、谁贡献新鲜度、是否双向认证，是三项不同事实。一个系统若只保存“context established=true”，就会把它们压扁成同一结论。协议并没有给这种压缩背书。

两个重放平面

SPKM 还可为上下文建立后的受保护消息提供 replay detection 与 sequencing。这些服务使用序列号，但只有应用请求时才启用。它们不会因为 Context ID 采用了随机数组合而自动成立。

通用 GSS-API 规范 RFC 2743 把这两层分得很开。逐消息 replay 与 sequence 是可选择的上下文标志；调用方提出请求，接收方报告实际可用能力。实现甚至可以在补充状态中标出重复或乱序，同时仍把消息交给调用方。token 如何传输，也始终由应用负责。

因此，审计记录必须分别回答：本次上下文建立是否与旧的建立尝试隔开？上下文内的后续消息是否接受了重复或顺序检查？Context ID 只能帮助回答第一个问题；请求与接受的标志、序列状态和逐消息验证结果，才回答第二个问题。

把历史记录限制在它能证明的范围内

RFC Editor 将 RFC 2025 记录为 1996 年 10 月发布的 Proposed Standard；本次核查时，勘误数据库没有列出该文档的已发布勘误。IANA 的 SMI 登记表仍保留 SPKM-1、SPKM-2、SPKM-3 以及 SPKM GSS token 的对象标识符。这些资料证明的是规范沿革和编号分配，不是当代部署规模。

后来的 RFC 2847 把 SPKM-3 定义为除若干明确改动外与 SPKM-1 等价。它有助于追踪机制家族，却不会改变 RFC 2025 的证据边界：阅读 Context ID 时，必须同时知道产生它的交换形态。

可守住的结论很简洁：randSrc || randTarg 记录双方对上下文新鲜度的贡献；单边 SPKM-2 的 Context ID 只记录发起端贡献，即使存在 key-src-bind 也不例外。两者都不证明证书授权、算法选择、后续消息送达或业务结果。

来源