摘要

  • 个人 Internet-Draft draft-howard-virp 第 07 版于 2026 年 9 月 6 日提交，文本日期为 9 月 7 日。它不是 IETF 标准，不是工作组采纳文件，也不代表 IETF 已经认可该设计。
  • 新增的 External Authorization Binding 让闸门的常驻设备身份仅能观察；超出只读范围的命令必须由闸门之外的服务授权，并由设备侧执行该判断。
  • 证据模型把闸门声明的意图与执行、外部服务的准许或拒绝、设备自身的命令记账放在一起核对。缺失或不一致不会被强行归入成功，而会保留为独立状态。
  • 草案称，静态逐命令策略以及闸门记录与设备记账的对账已经实现，并在 Cisco IOS 与 IOS-XE 上演练。这仍是作者公开的实现陈述，不是独立复现，也不证明广泛部署。
  • 关键缺口尚未关闭：限定具体审批、带有效期且只能消费一次的写入授权没有实现，外部授权决定也尚未成为链中的原生记录。

真正的边界是凭据放在哪里

Datatracker 历史记录，第 07 版在 9 月 6 日上传、被接受并公开。9 月 7 日的正文新增了一套部署配置。它问的不是抽象的“AI 是否可信”，而是一个可以检查的运维问题：自动化闸门被攻破时，攻击者是否同时拿到了能改动生产设备的常驻凭据？

这套配置要求闸门平时只用只读身份连接设备。设备自己的授权机制必须拒绝超出观察范围的命令，不能只依赖闸门内部的分类器。具备写能力的身份不得以可直接使用的形式存放在闸门上；每次写操作都要经过另一个主体的独立判断。

区别在于控制是否能经受闸门失守。如果分类、特权凭据和结果记录都在同一进程中，攻击者控制闸门后，规则与证据会一起倒下。若设备向外部服务询问权限，并把授权请求和命令记账发送到闸门不能独自阻断或伪造的路径，攻破一个组件便不再等同于同时取得授权、执行与解释权。

第 07 版承认，组成部件并不新。RFC 8907早已定义 TACACS+ 的逐命令授权与记账，只读管理身份也很常见。VIRP 主张的增量，是把这些技术组合到自主请求者周围，将读权和写权分给不同身份，并让第三方能够比较闸门叙述与设备侧记录。

机构地位必须单独说明。Datatracker 页面把它标为个人 Internet-Draft，没有 RFC stream，也没有 Responsible AD；页面明确提示任何人都可以提交 Internet-Draft，该文本未获 IETF 认可，在 IETF 标准流程中没有正式地位。使用 IETF 文档格式，不能替代集体授权。

四类记录来自三个控制点

规范列出四类证据。gate_intent/1 在接触设备前记录闸门准备做什么；gate_execution/1 在事后记录闸门声称做了什么，两者被标为已实现。device_accounting/1 来自设备自己的命令记账，经一条可独立到达的收集路径接收并纳入链中，也被标为已实现。

authorization_decision/1 的状态不同。它应当记录外部服务对某一设备、主体与规范命令的准许或拒绝，以及相应时间。格式已经写入规范，但参考实现还没有把它发成链内记录。决定目前保留在授权服务的本地日志中，只能作为另一个来源的附件进入核验材料。

这造成两种拒绝。VIRP 闸门的分类器可以在内部拒绝请求，生成带认证、可链接的闸门记录；外部服务也可以拒绝闸门已经发送的命令，但这项决定尚未进入同一条证据链。二者都可能为真，却代表不同主体在不同位置行使权力。

对账用设备标识、主体身份、规范命令的精确摘要和一段事先声明的时间窗口进行连接。设备时钟不可信时，不能把最接近的事件猜成同一次行动，只能标为 UNRESOLVED。合格记录一致时是 MATCHED；闸门声称执行而找不到设备记录是 GATE-ONLY；设备记账却找不到对应闸门执行是 DEVICE-ONLY；DENIED 则必须依赖授权服务的决定，不能从“没有记账”反推。

允许“不确定”作为正式结论，是这套设计最有价值的治理特征之一。它避免系统用视觉上的完整性掩盖证据连接失败。

设备记账不一定证明命令已执行

RFC 8907将 accounting 描述为记录用户正在做或已经做过的事情。但针对设备管理，它要求客户端为每条“输入”的命令发送记账起始包，不论命令如何获得授权。因此在某些平台上，一条记账记录只能证明命令被输入，不能证明它被准许或真正执行。

VIRP 第 07 版要求每个部署按设备类别说明记账语义：输入、授权、执行，或语义未知。只有已经证明其含义为执行的记录，才能支持“执行发生”的结论。

草案还报告了更窄的 Cisco IOS 与 IOS-XE 观察：在所述演练中，记账对应已执行命令，拒绝不会产生相同记录；随后立即要求读者不要把这个映射推广到其他平台。VIRP 参考仓库由同一项目维护，可以说明作者声称构建了什么，却不能充当独立验证者。

AAA 传输路径同样影响独立性。第 07 版在双方支持时引用 RFC 9887 的 TACACS+ over TLS 1.3。如果闸门能够截获、篡改或压制授权与记账通信，那么架构图上的“外部服务”并没有形成可靠的第二证据源。

一次性写权仍是目标设计

尚未实现的授权路径写得很具体。闸门之外的签发者要验证登记审批人的 Ed25519 签名，签名必须绑定准确的规范命令、目标设备和到期时间。若审批只允许执行一次，就要携带唯一标识；签发者在释放写权之前必须持久记录“已消费”，并拒绝再次使用。仅有到期时间无法阻止授权在有效窗口内被重复播放。

审批对象还必须与设备实际收到的调用相同。驱动若把规范命令渲染成不同字节，就需要证明对应关系。文本策略必须在命令两端锚定，避免更长命令或复合命令利用前缀匹配。有效失效时间还应加入授权服务应用撤销的延迟；异步系统返回“重载成功”，不等于旧许可已经失效。

第 07 版明确把这条 approval-scoped grant 路径标为未实现。当前陈述的状态，是只读身份、操作员身份和默认拒绝组成的静态策略，再加上设备记账对账。静态边界仍能降低爆炸半径，但它不是“每次审批生成一项短暂权能，并在一次使用后消失”的动态机制。

链记录的 Ed25519 签名也有明确边界。它是附加在强制 HMAC 旁的可选功能，默认关闭，并按节点启用。签名可以增加公开核验能力，却不会自动证明设备状态真实，也不会把未进入链的外部决定变成链内事实。

写操作需要一张权能保管凭证

实际评估这套配置时，每次写操作都应留下紧凑凭证：证明闸门常驻身份确实只读；标明独立授权服务；绑定准确命令摘要、目标、审批人、到期时间与唯一授权标识；记录写权在释放前已经被消费，并给出撤销真正生效的时间。

凭证随后连接闸门意图、闸门执行声明、外部授权决定和设备记账。匹配窗口、时钟状态、设备类别的记账语义必须与结论一起保留。证据不足时，应允许 UNRESOLVED 而不是生成一个方便的绿色结果。

这张凭证是 Daniel Kade 的建议，不是 VIRP、RFC 8907、RFC 9887 或 IETF 的既有要求。它的目的，是阻止一个中央界面同时借用授权服务的权力和设备记录的证明力。

来源