摘要

  • 节点属于信任域 T，表示它被认为遵守 Spec(T)；B 信任 A，则还要求 B 与 A 有安全连接，并在本地配置中确认 A 是该域成员。
  • 断言身份若来自接收方不信任的节点，就不具备真实性或完整性保证，不得显示、转发或用作服务输入。

边界只说明规则相容

“信任域”很容易让人想象成一间封闭房间：只要进入房间，所有成员就能互信。RFC 3324 特意拆掉了这个直觉。一个节点成为 T 的成员，是因为人们知道它遵守一组配置和规范，即 Spec(T)。单一运营者可以凭自己对设备的了解建立域；多个运营者也可以借双边协议把较小的域接在一起。这个过程产生的是管理上的成员集合，并不会自动为每一对节点建立安全会话。

真正的信任从接收方 B 出发。只有当 B 与 A 之间存在安全连接，而且 B 的配置明确指出 A 属于该域时，才能说 B 信任 A。方向不能省略。B 可以信任 A，而 A 不信任 B；域外用户代理也可以信任域内的家庭代理，却不因此成为域成员。RFC 图示最有力的地方，正是把同域与互信画成两件事：A、B、C 同域，A 只信任 C。

因此，文档拒绝“从可信节点收到信息”这种说法。单个节点并不知道域内所有成员的完整状态，也不能替别的接收方作判断。可接受的表述是“从它所信任的另一个节点收到信息”。一字之差，改变了证据结构：必须说清是谁接收、谁是直接发送者、两者间的安全连接是什么，以及接收方依据哪项配置认定成员资格。

身份断言不能脱离来路

网络断言身份由 SIP 网络中介在认证之后生成。它可以是 SIP、SIPS 或电话 URI，并应在相应域或号码范围内具有可路由意义。认证方法，至少其可靠性和强度，必须成为 Spec(T) 的一部分。用户可以向中介提供偏好的身份，但是否采纳仍由域策略决定。

普通 From 字段并没有同样的证据能力。SIP 允许用户填写想要的别名，而用户代理往往没有验证另一个用户代理所需的密钥。短期方案把认证和派生交给网络中介，再让理解同一规则的安全连接节点传递结果。

然而，断言不会因为带着“网络”二字就成为全局事实。接收方若从自己不信任的节点得到它，就无法知道生成与传输是否遵循 Spec(T)。RFC 3324 明确说，这种信息不带真实性或完整性保证，并给出刚性后果：不得向用户显示，不得继续传给其他节点，也不得作为服务逻辑的输入。把它放进界面再标一个小小警告，同样会让未经验证的名称影响人的决定。

安全连接也只证明一层事实。它应防止第三方读取、无痕篡改，并让 B 确认消息确实来自 A。B 的配置再把 A 与预期的域关联起来。但这两张收据都不独立证明最初认证一定足够强，也不证明中介实际按规则执行。原始认证、直接同伴、成员配置、传输完整性和最终服务动作，是彼此不同的证据面。

兼容集合不是互联网通用身份证

RFC 3324 一再限定适用范围。它面向一群已知遵守共同机制的设备，也允许域内节点通过安全直连，把身份交给信任它的域外节点。任意互联网主机之间的一般身份传输明确不在范围内。安全章节甚至警告：一旦离开这个上下文，接收方完全无法保证信息未被修改，也无法保证它起初就是正确的。

Spec(T) 也不必是一份公开、单一的成文标准。它是参与者共同知道的一组信息：断言了什么、如何确定、认证强度如何、完整性怎样维护、隐私政策如何处理。只看到一个字段名，却不知道这些运行规则，得到的只是语法，不是完整证据。

隐私会进一步限制传播。消息可以指明，网络断言身份受隐私要求约束，不得传给其他用户；另一个指示可以专门表达用户本人提出的请求，因为域策略可能区分用户意图与法律或运营原因。身份因此可以在可信网络内部继续流动，却对外部用户隐藏。这与 RFC 3323 的观察者相对隐私相容，但二者不是同一机制。

随后 RFC 3325 给出私有 SIP 扩展，RFC 5876 更新了它。RFC 4474、RFC 8224 与 RFC 8225 走向另一条认证身份和 PASSporT 路线，RFC 4916 处理对话中的连接身份。后续规范越多，越能看清 RFC 3324 的边界：它是一份需求文档，不是部署普查，也不是通用真实身份的证明。

它留下的历史教训很薄，却很硬。共同边界可以规定最低相容行为，不能替所有参与者完成验证。身份只有沿着接收方能够解释的有向边到达，才获得规定中的意义。

来源