要約

  • 個人提出のInternet-Draft draft-howard-virp 第07版は2026年9月6日に提出され、本文は9月7日付である。IETF標準でも、ワーキンググループ採択文書でも、IETFが承認した設計でもない。
  • 新設されたExternal Authorization Bindingでは、ゲートの常設IDを観測用に限定し、それを超えるコマンドはゲート外のサービスが機器側で許可する。
  • ゲートの意図と実行記録、外部サービスの許否、機器のコマンド会計を突き合わせる。不一致や不足は、成功に丸めず固有の状態として残す。
  • 本文は、静的なコマンド単位ポリシーと機器会計との照合を実装し、Cisco IOSとIOS-XEで試したと述べる。これは著者側の報告であり、独立再現や一般普及の証明ではない。
  • 承認に限定され、有効期限を持ち、一度だけ消費できる書き込み許可は未実装である。外部の許否判断も、まだチェーンの第一級レコードになっていない。

ゲートを破られても書けない構造

Datatrackerの履歴は、第07版が9月6日にアップロードされ、受理され、公開されたことを示す。9月7日付の本文が扱う中心課題は、AIの善悪ではない。自律エージェントから要求を受けるゲートが侵害されたとき、実機を書き換える資格情報まで同じ場所から奪われるのか、という問題だ。

新プロファイルでは、ゲートが常時使えるIDは観測クラスのコマンドだけを許される。範囲外のコマンドは、ゲート内部の分類器だけでなく、機器が参照する外部認可サービスによって拒否されなければならない。書き込み可能なIDは、別主体による操作ごとの判断なしに使える形でゲートへ保存してはならない。

これは実装上の権力分立である。特権秘密、分類器、実行記録が同じプロセスに集まれば、そのプロセスの侵害は制約と証拠を同時に壊す。機器自身が独立サービスへ認可を問い合わせ、認可と会計をゲートから独立して到達できる経路へ送れば、ゲート単独では判断も記録も作り替えにくくなる。

部品そのものは新しくない。RFC 8907はTACACS+のコマンド単位認可と会計を定め、読み取り専用の管理IDも一般的である。VIRPが新規性として掲げるのは、自律的な要求者を制約された主体として扱い、読み取りと書き込みのIDを分け、ゲート外で生まれた証拠と照合できるように組み合わせる点だ。

制度上の位置付けは控えめに読まなければならない。Datatrackerの文書ページは個人Internet-Draftと表示し、RFC streamもResponsible ADもない。誰でも提出でき、この文書はIETFの支持を受けておらず、標準化過程で正式な地位を持たないと明記している。IETF形式の文書であること自体は、共同体の委任を意味しない。

同じ行為を三つの場所から見る

第07版は四つの証拠型を定める。gate_intent/1は機器へ接触する前にゲートの予定を記録し、gate_execution/1は後でゲートが実行したとする内容を記録する。両方とも実装済みとされる。device_accounting/1は機器が生成したコマンド会計で、ゲートと独立に到達できる収集先で受け取り、チェーンへ追加する。これも受信側は実装済みとされる。

残るauthorization_decision/1は、外部サービスによる許可または拒否を、機器、主体、正規コマンドまたはダイジェスト、時刻とともに保持するための形式である。形式は仕様にあるが、参照実装はまだチェーン内レコードとして出力しない。判断はサービスのローカルログに残り、別由来の添付資料として検証束へ加わるだけだ。

したがって拒否も二種類ある。VIRP側の分類器が要求を止めれば、ゲート内部の認証済みチェーン記録になる。外部認可サービスが送信済みコマンドを拒否すれば、その判断は独立しているが、現時点では同じチェーン保管を持たない。二つを一語にまとめると、誰がどこで権限を使ったかが消える。

照合キーは、機器ID、機器が認識した主体ID、正規コマンドの正確なダイジェスト、そして宣言済み時間窓である。機器時計が確立していなければUNRESOLVEDにする。条件を満たす双方の記録が一致すればMATCHED、ゲートの実行主張だけならGATE-ONLY、機器会計だけならDEVICE-ONLY、拒否は認可判断からDENIEDとする。

不確実を正式な結果に残すことは重要だ。近い時刻の似たコマンドを便宜的に結び付ければ、監査の形だけが整い、事実は失われる。

TACACS+会計が示す内容は機器ごとに違う

RFC 8907では、会計は利用者が行っている、または行ったことを記録する仕組みである。一方、機器管理では、認可方法にかかわらず入力された全コマンドについて会計開始パケットを送るよう求める。このため、ある機器の記録は「入力」を示すだけで、「許可」や「実行」まで証明しないことがある。

VIRPは、機器クラスごとに会計の意味を確立するよう要求する。入力、認可、実行、または実行意味不明のどれなのかを宣言し、実行を示すと確認された記録だけを実行判定に使う。

本文はCisco IOSとIOS-XEの演習について、会計が実行済みコマンドに対応し、拒否では会計が出なかったと報告する。ただし他のプラットフォームへ一般化しないよう明示する。参照リポジトリも同じプロジェクトが管理しているため、著者の実装主張を調べる一次資料にはなるが、独立検証にはならない。

AAA経路の保護も証拠の一部である。第07版は、双方が対応するときRFC 9887のTACACS+ over TLS 1.3を参照する。認可サービスが別筐体でも、ゲートが通信を変更、遮断、偽装できれば、独立性の前提は弱い。

一回限りの許可は設計済み、未構築

目標となる許可は具体的に書かれている。ゲート以外の発行者が、登録承認者のEd25519署名を検証し、正確なコマンド、対象機器、有効期限との結合を確認する。一回実行用の承認には固有IDを持たせ、発行者は書き込み権限を渡す前に消費を永続記録し、再利用を拒む。有効期限だけでは、期限内の反復利用を防げない。

承認された正規コマンドと、機器に送られた実際の呼び出しも一致しなければならない。ドライバが表現を変えるなら、その対応関係を証明する。文字列ポリシーは前後を固定し、長い複合コマンドが接頭辞一致で許可されるのを防ぐ。実効期限には認可サービスの反映遅延を含め、非同期変更での再読み込み成功を即時失効の証拠にしない。

しかし第07版は、このapproval-scoped grantが未実装だと明記する。現状の主張は、読み取りID、運用者ID、それ以外の拒否から成る静的ポリシーと、機器会計との照合である。静的分離にも価値はあるが、承認ごとに短命の権能を作り、一度で消す仕組みとは別だ。

チェーンのEd25519署名も任意で、既定では無効、ノード単位で有効化する。必須HMACに加える公開検証手段であり、機器の真実を自動的に保証したり、外部判断の未実装を補ったりはしない。

書き込み権限の保管証明

運用者が求めるべき証明は、ゲートの常設IDが読み取り専用であること、独立認可サービス、正確なコマンドと対象、承認者、有効期限、固有許可ID、発行前の消費記録、実際の失効時刻を一つに結ぶものだ。最終的に機器へ送られた呼び出しも示す必要がある。

そのうえで、ゲートの意図、実行主張、外部の判断、機器会計を照合し、時間窓、時計状態、機器固有の会計意味を残す。材料が足りなければUNRESOLVEDが正解である。

これはDaniel Kadeの提案であり、VIRP、RFC 8907、RFC 9887、IETFの既存要件ではない。一つの画面が認可サービスの権力と機器記録の証明力を同時に借りるのを防ぐための運用上の形式である。

情報源