Zusammenfassung

  • Revision 07 des individuellen Internet-Drafts draft-howard-virp wurde am 6. September 2026 eingereicht und ist auf den 7. September datiert. Sie ist weder IETF-Standard noch WG-Übernahme oder gebilligtes IETF-Design.
  • Das neue Profil External Authorization Binding beschränkt die ständige Geräteidentität des Gates auf Beobachtungsbefehle. Über Schreibzugriffe entscheidet ein Dienst, den das Gate nicht kontrolliert.
  • Das Modell gleicht Absicht und Ausführungsbehauptung des Gates mit Geräte-Accounting und der externen Erlaubnis oder Ablehnung ab. Lücken erhalten eigene Zustände, statt als Erfolg oder Verweigerung interpretiert zu werden.
  • Der Text meldet statische Befehlsrichtlinien und den Abgleich mit Geräte-Accounting als implementiert und auf Cisco IOS und IOS-XE erprobt. Das ist eine Hersteller- beziehungsweise Autorenangabe, keine unabhängige Reproduktion und kein Nachweis breiter Nutzung.
  • Die entscheidende dynamische Strecke fehlt: genehmigungsgebundene, befristete und einmalig verbrauchbare Schreibrechte sind nicht implementiert; externe Autorisierungsentscheidungen werden noch nicht als native Ketteneinträge erzeugt.

Ein kompromittiertes Gate darf seine eigene Grenze nicht aufheben

Die Datatracker-Historie verzeichnet Upload, Annahme und Veröffentlichung von Revision 07 am 6. September. Der Text vom 7. September stellt eine praktische Frage: Liegt im Gate, das Anweisungen eines autonomen Akteurs entgegennimmt, zugleich das Geheimnis, mit dem Produktionsgeräte verändert werden können?

Im neuen Profil lautet die Antwort: dauerhaft nicht. Das Gate meldet sich mit einer Identität an, die nur Beobachtungsklassen ausführen darf. Das Gerät muss einen getrennten Autorisierungsdienst befragen und Befehle außerhalb dieser Klasse dort ablehnen lassen. Eine schreibfähige Identität darf nicht in einer Form auf dem Gate liegen, die ohne gesonderte Entscheidung eines anderen Akteurs nutzbar wird.

Das ist mehr als eine zusätzliche Regel. Befinden sich privilegiertes Geheimnis, Klassifizierer und Ergebnisprotokoll im selben Prozess, fällt mit diesem Prozess auch die Trennung. Erzwingt dagegen das Gerät eine Entscheidung eines unabhängigen Dienstes und sendet Autorisierungs- sowie Accounting-Daten über einen vom Gate unabhängigen Weg, kann die Kompromittierung des Gates nicht allein Erlaubnis und Beweis herstellen.

Die Bausteine sind älter. RFC 8907 beschreibt TACACS+-Autorisierung je Befehl und Accounting; Nur-Lese-Konten gehören zum Betriebsalltag. VIRP beansprucht als Beitrag deren Zusammensetzung um einen automatisierten Antragsteller sowie eine Evidenzschicht, die dessen Darstellung mit geräteseitigen Ereignissen vergleicht.

Der institutionelle Status ist enger. Die Datatracker-Seite nennt ein individuelles Internet-Draft ohne RFC-Stream und ohne Responsible AD. Sie weist ausdrücklich darauf hin, dass jeder ein I-D einreichen kann, dass dieses Dokument nicht von der IETF gebilligt ist und im Standardisierungsprozess keine formale Stellung besitzt. Das Dokumentformat schafft kein Mandat.

Vier Belegtypen mit unterschiedlicher Verwahrung

gate_intent/1 hält vor dem Gerätekontakt fest, was das Gate tun will. gate_execution/1 beschreibt danach, was es nach eigener Darstellung getan hat. Beide gelten im Text als implementiert. device_accounting/1 stammt vom Gerät, wird über einen unabhängig erreichbaren Sammler empfangen und beim Eingang verkettet. Auch dies wird als implementiert bezeichnet.

authorization_decision/1 befindet sich in einem anderen Zustand. Der Eintrag soll Erlaubnis oder Ablehnung des externen Dienstes samt Gerät, Identität, kanonischem Befehl oder Digest und Zeit tragen. Die Semantik ist spezifiziert, doch die Referenzimplementierung schreibt den Eintrag noch nicht in die Kette. Die Entscheidung verbleibt im lokalen Dienstprotokoll und wird als fremdbezogene Anlage präsentiert.

Deshalb gibt es zwei Arten von Verweigerung. Lehnt der VIRP-Klassifizierer im Gate ab, entsteht ein authentifizierter Ketteneintrag. Lehnt der externe Dienst einen bereits gesendeten Befehl ab, stammt der Beschluss von einem unabhängigen Kontrollpunkt, hat aber noch nicht dieselbe Kettenverwahrung. Ein gemeinsames Etikett würde den Entscheider unsichtbar machen.

Der Abgleich verbindet Gerätekennung, vom Gerät gesehene Principal-Identität, exakten Digest des kanonischen Befehls und ein deklariertes Zeitfenster. Eine nicht gesicherte Uhr führt zu UNRESOLVED. Übereinstimmende qualifizierte Belege ergeben MATCHED; nur vom Gate behauptete Ausführung wird GATE-ONLY; nur vom Gerät erfasste Aktivität DEVICE-ONLY; DENIED verlangt die Autorisierungsentscheidung und folgt nicht aus fehlendem Accounting.

Ungewissheit als Ergebnis ist kein Mangel. Sie verhindert, dass ähnliche Befehle oder nahe Zeitpunkte so lange zusammengerückt werden, bis eine scheinbar vollständige Prüfung entsteht.

Accounting ist nicht auf jedem Gerät ein Ausführungsbeleg

RFC 8907 beschreibt Accounting als Aufzeichnung dessen, was ein Benutzer tut oder getan hat. Für Geräteadministration sollen Clients jedoch für jeden eingegebenen Befehl einen Startdatensatz senden, unabhängig von dessen Autorisierung. Ein Datensatz kann deshalb Eingabe statt Genehmigung oder Ausführung belegen.

VIRP verlangt eine Festlegung je Geräteklasse: Steht das Ereignis für eingegeben, autorisiert, ausgeführt oder unbekannte Ausführungssemantik? Nur nachweislich ausführungsbezogene Daten dürfen eine Ausführungsklassifikation tragen.

Für die eigenen Versuche auf Cisco IOS und IOS-XE berichtet der Text, Accounting habe ausgeführten Befehlen entsprochen und eine Ablehnung habe keinen solchen Datensatz erzeugt. Die Übertragung auf andere Plattformen wird ausdrücklich untersagt. Das VIRP-Referenzrepository wird vom selben Projekt gepflegt; es dokumentiert dessen Behauptungen, ersetzt aber keine unabhängige Prüfung.

Auch der AAA-Transport gehört zur Grenze. Revision 07 verweist auf RFC 9887 für TACACS+ über TLS 1.3, sofern beide Seiten dies unterstützen. Ein organisatorisch getrennter Dienst ist keine unabhängige Quelle, wenn das Gate seinen Kommunikationsweg verändern oder unterdrücken kann.

Die Einmalfreigabe ist genau beschrieben und dennoch nicht vorhanden

Ein Aussteller außerhalb des Gates soll die Ed25519-Signatur eines registrierten Genehmigers prüfen, gebunden an exakten Befehl, Zielgerät und Ablauf. Eine für einmalige Ausführung bestimmte Genehmigung erhält eine eindeutige Kennung. Vor Ausgabe der Schreibbefugnis muss der Aussteller den Verbrauch dauerhaft speichern und Wiederverwendung verweigern. Ein Ablaufdatum verhindert keinen mehrfachen Einsatz innerhalb des Zeitfensters.

Die genehmigte Operation muss außerdem der tatsächlichen Geräteanweisung entsprechen. Verändert ein Treiber die kanonische Darstellung, ist diese Abbildung nachzuweisen. Textregeln müssen an beiden Enden verankert sein, damit längere oder zusammengesetzte Befehle nicht über Präfixe passen. Der wirksame Ablauf schließt die Verzögerung des Autorisierungsdienstes ein; eine erfolgreiche asynchrone Neuladung beweist nicht die sofortige Rücknahme.

Revision 07 markiert diesen approval-scoped grant als nicht implementiert. Gemeldet wird eine statische Richtlinie aus Nur-Lese-Identität, Operator-Identität und Ablehnung aller übrigen Befehle, ergänzt um den Abgleich. Das kann den Schaden begrenzen. Es ist aber keine kurzlebige Fähigkeit, die aus einer einzelnen Genehmigung entsteht und nach einem Verbrauch erlischt.

Auch die neuen Ed25519-Signaturen pro Eintrag und Kettenkopf sind optional, standardmäßig ausgeschaltet und je Knoten aktivierbar. Sie ergänzen den verpflichtenden HMAC. Wo sie aktiv sind, ermöglichen sie zusätzliche öffentliche Prüfung, ohne Gerätewahrheit oder die fehlende externe Entscheidungsverkettung zu liefern.

Ein Verwahrungsbeleg für jeden Schreibzugriff

Für jede schreibfähige Aktion sollte ein Beleg die dauerhafte Nur-Lese-Identität, den unabhängigen Autorisierungsdienst, exakten Befehlsdigest, Ziel, Genehmiger, Ablauf, eindeutige Freigabekennung und den vor Ausgabe gespeicherten Verbrauch verbinden. Er sollte den tatsächlichen Wirksamkeitszeitpunkt einer Rücknahme und die an das Gerät gesendete Anweisung nennen.

Anschließend werden Gate-Absicht, behauptete Ausführung, externe Entscheidung und Geräte-Accounting verbunden. Zeitfenster, Uhrenzustand und gerätespezifische Accounting-Semantik bleiben Teil des Ergebnisses. Reichen die Belege nicht, ist UNRESOLVED korrekt.

Dieser Beleg ist eine Empfehlung von Daniel Kade, keine Vorgabe von VIRP, RFC 8907, RFC 9887 oder der IETF. Er soll verhindern, dass eine zentrale Oberfläche zugleich die Autorität des externen Dienstes und die Beweiskraft des Geräts übernimmt.

Quellen