摘要

  • RFC 3329 让 SIP 用户代理和下一跳交换能力清单，启用双方已知且服务器偏好最高的机制，再通过该保护回送服务器的完整静态清单。
  • 这份 Security-Verify 回执能暴露删项、重排或改参，但不会追溯保护最初报价；整套设计仍受允许机制中最弱的完整性与防重放能力约束。

一个星号都不必伪造，删掉一项就够了

如果服务器原先给出四种安全机制，中间设备只需在响应到达用户代理前抹去第一项，就可能改变双方之后采用的保护方式。攻击者不必伪造一个服务器，也不必破解某个加密算法；只要趁选择尚未发生时改变清单，两端就可能在较弱的共同选项上继续通信，并各自以为对方从未提出更强选项。

这是一道顺序问题。协商机制必须先交换选项，之后才可能启用从中选出的机制。要求第一份清单一开始就由尚未建立的保护来保护，等于要求协议先完成它还没法完成的事。RFC 3329 没有假装消除这个窗口，而是把检查安排在后面。

用户代理把 Security-Client 放入发往下一跳 SIP 实体的请求。服务器回送 Security-Server，其中是针对该适用范围预先配置的机制列表和启动所选机制所需的信息。客户端从已知的共同机制中，选择服务器偏好值最高的一项，按该机制建立保护，再发起请求，并把收到的服务器列表放进 Security-Verify。

服务器此时不必相信客户端对“刚才看见了什么”的口头描述。它拿 Security-Verify 与自己的静态列表比较：机制、顺序和参数都应对应。如果客户端收到的是被删短的三项列表，而服务器原先发出四项，比较就不一致。这个拒绝说明报价的连续性没有得到确认，却不能单独证明是谁动了手，也不能区分恶意篡改和配置、路径或实现故障。

因此，RFC 3329 改变的不是第一条消息的历史，而是攻击者的下一步成本。首次删项仍在明文或未受协商保护的交换中发生；要让服务器也接受被删短的回执，攻击者还必须在新的保护机制启用之后伪造它所保护的内容。一次肉眼难见的删项，变成了可能留下失败回执的完整性挑战。

服务器必须先有自己的参照物

这次比较若要有意义，服务器提供的清单就不能根据客户端报来的清单临时裁剪。否则，中间攻击者先删掉 Security-Client 中的强选项，服务器再据此只返回剩余选项；客户端随后回送同一份缩短清单，双方便会得到一条自洽、却已被外部影响的协商链。

RFC 3329 因而要求服务器清单保持静态，不随客户端输入变化。静态不等于每台设备、每条链路都只能使用同一张清单；节点可以为不同接口配置不同列表。关键是，每张列表在观察到这次客户端报价之前已经确定，能作为后续比较的独立基准。

机制偏好使用不同的 q 值。客户端在服务器清单中选择自己已知的共同机制里优先级最高的选项；服务器偏好决定共同能力间的顺序，但不替客户端证明它真实支持什么。篡改客户端初始清单仍可能让服务器省略某些启动资料，或使双方作出不同选择并无法继续。失败值得调查，却仍是攻击可能性而非攻击判决。

比较还避免了 SIP 层为每次协商记住一份临时挑战状态。受保护请求回来时，服务器可以按适用接口上的静态列表进行验证。底层连接或安全关联本身当然可能需要状态，例如 TLS 连接、IKE 生命周期或 Digest 重新挑战；“无状态”说的是列表比较这一步，不代表整条安全关联无需管理。

下一跳不是端到端

协议的边界同样明确：用户代理与其下一跳 SIP 实体之间，通常是首跳或出站代理。服务器主动发起协商时，会检查请求只有一个 Via；若已有多个中继标记，它就不是该请求的第一跳，不应套用这个程序。别的跳、呼叫另一端或消息主体，并不会因为这份回执而自动获得保护。

代码也区分不同起始状态。客户端用 Require 和 Proxy-Require 声明 sec-agree，发出未保护的初始化请求；服务器可用 494 Security Agreement Required 返回选项清单。若服务器按本地策略要求扩展，而客户端没有声明支持，可能用 421 Extension Required 说明必须扩展；若客户端已表明支持但协商尚未完成，则使用 494。两个代码描述的是协议处理位置，不是“检测到攻击”的告警。

服务器还会在没有共同机制时照样给出自身清单。这让用户代理看到协商要求和实际服务器政策的区别，而不是把无匹配掩盖成看似普通的网络失败。连接失败可能来自旧客户端、失配策略、丢失的扩展标记、配置过期，也可能是攻击。要作判断，运营记录至少应保留代码、双向清单、列表顺序及参数、选中机制、启动资料、保护结果与最终比较结果。

机制名称不等于它的保护属性

RFC 3329 定义了几种启动路径。选中 TLS 时，客户端按 SIP 服务器定位规则建立受保护连接；Digest 使用挑战和响应资料，并让验证计算覆盖服务器清单；ipsec-ike 会尝试建立 IKE 关联；手动配置的 IPsec 则依赖带外分发的密钥与策略。RFC 3310 增加 AKA 相关的 Digest 用法，却没有替代“把报价带回再核对”的机制。

这些方式提供的性质不相同。Digest 可认证并保护特定验证值，却不加密整份 SIP 消息。TLS 提供的是一跳上的通道保护，不会因此把整条代理链变成端到端加密。IPsec 的结果取决于真实建立的关联、选择器和策略。完整回执证明的是服务器清单在比较点上保持对应，不是所有列出的机制都被启用，更不是每个算法按今天的标准都足够强。

时间让这一区分更重要。RFC 3329 于 2003 年发布。RFC 8996 后来更新它，禁止协商 TLS 1.0 和 TLS 1.1；RFC 8446 定义 TLS 1.3，RFC 7616 则修订 HTTP Digest。清单仍可能合法地显示注册机制名，但 IANA 注册记录只说明名称获得登记，并不证明部署规模、当前使用或安全结论。

标准勘误也提醒读者区分正文规则和示例。RFC 3329 的两个示例把 Security-Verify 放进 ACK，而头字段使用表却将它标为不适用；相关勘误指出这处不一致等待文档修订。另一项已验证勘误把 ipsec-3gpp 的 SPI 长度从“恰好十位”改为“一至十位”。引用时不能只看示例，也不能把未修正范例当成规范边界。

RFC 3329 留下的是一个有限但重要的次序设计：当协商先于保护，记住原始报价，待保护生效后把它带回，并在服务器端做精确比较。回执能确认路径上的列表是否仍相符；系统愿意接受多弱的机制，仍是独立的策略选择。

来源