摘要

  • RFC 3520 的 AUTH_SESSION 把一项范围明确的会话授权带入资源预留请求。签名、时间和字段匹配能够支撑准入判断，却不能单独证明资源已经端到端预留、媒体已经传输或会话已经达到应用结果。
  • 可追责的凭证链必须分别保留授权者及权限范围、令牌原始字节、时间或会话标识的防重放状态、字段比对、本地 PDP 决策、PEP 执行、RSVP 与 SIP 状态、实际流量以及经认证的应用确认。

时间型授权最容易制造一种错觉：只要签名没坏、时间没过，授权就仍然有效。但时间不是令牌内部自给自足的事实。判断“没有过期”的系统必须知道当前时间，而当前时间来自时钟、同步源、容差策略和运行状态。

RFC 3520 于 2003 年 4 月按 Standards Track 发布，目前仍列为 Proposed Standard。它定义 Session Authorization Policy Element，让主机从会话信令获得授权元素，再原样复制到 RSVP 的 POLICY_DATA 对象中。这个设计解决的是声明如何跨控制平面传递，不是把声明自动变成服务结果。

主机可以是不受信任的搬运者。它保存字节，不因此成为授权者、验证者或资源的最终决策者。第一张凭证只能说明：授权系统产生了这些字节，资源控制系统收到了这些字节。

防重放要求揭示了时钟之外的状态

构造 AUTH_SESSION 时必须有 START_TIME 或 SESSION_ID，目的是阻止 replay。二者对应两种不同的运行责任。

使用开始时间时，接收方要用自己的时钟判断新鲜度。在非关联模型中，策略服务器必须支持 NTP 同步；RFC 明确警告，不同步的时钟可能使重放成为可能。应记录的不是一个“时间有效”布尔值，而是时间源、观测偏差、允许窗口、判断时刻与最终结论。

使用会话标识时，风险从钟表转移到记忆。标识何时生成、是否已使用、状态是否跨副本传播、重启和故障切换是否保留，都决定相同令牌能否再次被接受。签名能够在第二次提交时继续正确，因为密码学并不知道第一次提交已经发生。

RFC 5905 是后来的 NTP 语境，不能反向证明某个 RFC 3520 部署拥有可靠时钟。审计必须依赖当时实际保留的运行证据。

授权元素是一份有边界的陈述

AUTH_SESSION 可包含授权实体、会话标识、源地址、目的地址、开始与结束时间、资源以及认证数据。资源可以表示为最大带宽、RSVP flow spec、SDP 媒体描述或 DSCP。

这些字段不是供界面展示的元数据，而是权限边界。在非关联模型中，所有字段都必须与资源请求吻合。请求报文中的源与目的地址需要匹配，所请求的 QoS 不得超过授权值；发生不匹配时，应拒绝请求。

端口缺失尤其值得审慎解释。某一侧没有端口列表时，按照文档规则，该侧所有端口都被视为有效；存在列表时，只有列出的端口有效。因此，“没有填端口”和“端口不限”不是可以在日志清洗中相互替代的表述。

可靠记录应逐项保存令牌值、实际请求值、规范化规则、比较结果和策略后果。只留下一句“QoS 已授权”，无法说明范围到底狭窄还是意外宽泛。

四种部署关系把上下文放在不同地方

在 coupled model 中，同一个策略服务器参与服务授权与资源决策，所以只有 SESSION_ID 是必需项。标识指向服务器保存的决定；其具体格式虽由实现决定，相关状态仍需经受复制、重启与切换。

associated model 还携带授权实体身份，边缘据此找到掌握媒体授权决定的策略服务器。如果边缘无法独立确认该身份属于本域合法的策略服务器，就需要认证数据，以防攻击者把查询引向伪造授权者。

两个策略服务器的变体横跨行政边界：一个理解服务，一个控制资源。查询、响应与本地采纳条件都应进入凭证链。non-associated model 则假定验证方可能没有与授权者共享状态，因而令牌需要携带足够多的信息供其独立判断。

这些模型不能被同一个“token valid”字段审计。上下文驻留位置不同，信任关系不同，故障时丢失的状态也不同。

身份真实不等于拥有本地资源权限

AUTHENTICATION_DATA 保护它之前的数据。原文描述了当时的共享密钥、Kerberos 与公钥机制；公钥处理还涉及证书路径、吊销和签名验证。它们回答数据完整性与来源问题。

但建立授权实体身份、验证服务请求之后，路由器或 Policy Decision Point 仍须查询本地策略表。表中内容由本地决定；若决定依赖补充信息，该信息也必须安全取得。

密码学证明“被接受的密钥保护了这些字节”。本地治理判断“这个身份是否有权在本域、此时、为这项资源发言”。前者不能自动继承后者。文档在 2003 年列举的算法属于历史规范，也不应被包装成今天的密码部署建议。

策略对象经过路径不代表每一跳都执行了它

策略感知的 RSVP 路由器应把消息送往 PDP 并等待答复。策略不感知的路由器会忽略 policy-data 对象，继续 RSVP 处理。因此，在路径入口和出口都看见 AUTH_SESSION，不能证明中间每一跳都理解或执行了它。

运维记录需要列出哪些节点是 PEP、每个 PEP 咨询哪个 PDP、哪些节点忽略策略对象、实际安装了什么预留状态。令牌的传播范围与策略的执行范围是两个拓扑事实。

若 PDP 无法验证元素，RFC 3520 要求向 PEP 返回 Policy Control Failure，即 Error Code 02，并建议用 AUTH_DATA 携带更具体的策略错误。这个错误只证明验证边界失败；没有它，也不能反证本地策略通过、资源可用或会话成功。

预留完成仍不是媒体到达

RFC 3521 展示的是分阶段流程：会话管理可能报告建立完成，也可能仍在进行；主机发送 PATH；边缘咨询策略服务器；服务器可能修改资源；随后 RESV 也可能报告预留完成或仍在进行。

“仍在进行”反复出现，是对过早结案的提醒。资源控制中的一次肯定事件只关闭它负责的步骤。

RFC 3312 又把 SIP 的 QoS 前提条件拆成 desired status 和 current status。强制前提未满足时，会话建立保持暂停，媒体不应流动。资源事件可以更新 current status，却不会替代后续信令、实际包流和应用结果。

队列被预留不等于声音被解码；策略允许不等于用户同意；SIP 响应也不等于服务持续可用。承诺是什么，最后一张凭证就必须对应什么。

构造可以经受争议的证据链

先保存会话请求、经认证的行为主体及其代表的法律或运营主体。记录授权者身份、权限范围、决策版本和保留状态；计算原始令牌字节的哈希，并保存每个字段、密钥或凭据引用、证书与吊销结果以及防重放决定。

再把源、目的、端口、资源上限和有效期与 RSVP 请求逐项比较，保留 PDP 对资源的任何修改。记录作出决定的 PDP、执行决定的 PEP、忽略对象的节点，并用同一事务标识关联 PATH、RESV 与错误。

最后补上 SIP desired/current 状态、实际传输观测和经认证的应用确认。如果计费或客户承诺依赖“完成”，必须明确哪一张凭证触发完成。

故障切换后这条链仍应成立。替代服务器不能因丢失前任的状态而放过重放；时钟跳变不能悄悄放宽授权窗口；拓扑改变不能在离开已知执行范围后继续沿用“已准入”标签。

证据边界

本文不指认任何产品、厂商、运营商、策略服务器、路由器、客户、用户、会话、媒体流、事故或部署，也不声称任何现实系统当前采用、符合或安全实施了这些规范，不评价其性能、QoS 或商业结果。

RFC 3520 被视为 2003 年 4 月发布、当前状态为 Proposed Standard 的 Standards Track 文档。RFC 3521、RFC 3313 与 RFC 5866 保留各自状态与范围；RFC 3313 的专门行政域假设不外推至整个互联网。后来的 NTP 与 Diameter 文档仅作比较证据。

Heng Lu 关于权威与 running code 的文章是明确披露的编辑视角，用于辨别形式声明、实际控制和可观测结果，不是 IETF 意图的来源。

结论无需扩大：令牌可以保持签名有效，却因时钟、状态、字段、政策或路径问题不能支撑会话结果；即使全部准入条件通过，结果仍需另外证明。

来源