Résumé

  • La révision 07 du projet individuel draft-howard-virp a été déposée le 6 septembre 2026 et porte la date du 7 septembre. Ce n’est ni une norme, ni un texte adopté par un groupe de travail, ni une position approuvée par l’IETF.
  • Son nouveau profil External Authorization Binding limite l’identité permanente de la passerelle aux commandes d’observation et confie l’autorisation d’écrire à un service que la passerelle ne contrôle pas.
  • Le modèle rapproche la déclaration et le compte rendu de la passerelle, la décision du service d’autorisation et la comptabilité émise par l’équipement. Un écart devient GATE-ONLY, DEVICE-ONLY ou UNRESOLVED, au lieu d’être absorbé dans un résultat binaire.
  • Le texte affirme qu’une politique statique par commande et le rapprochement avec les traces d’équipement ont été implémentés et exercés sur Cisco IOS et IOS-XE. Il s’agit d’un constat publié par l’auteur, pas d’une reproduction indépendante ni d’une preuve de déploiement général.
  • Le mécanisme le plus exigeant reste au stade de la spécification : les droits d’écriture limités par approbation, échéance et consommation unique ne sont pas implémentés, et la décision externe n’est pas encore une pièce native de la chaîne.

Une passerelle ne peut pas être son propre contre-pouvoir

L’historique Datatracker enregistre le dépôt et l’acceptation de la révision 07 le 6 septembre. Le texte daté du 7 septembre ajoute un profil qui répond à une question plus matérielle que le vocabulaire habituel de la « gouvernance de l’IA » : où se trouve l’identifiant capable de modifier un routeur lorsque l’automate qui demande l’action est compromis ?

Dans le profil proposé, la passerelle se présente au dispositif avec une identité permanente en lecture seule. Le serveur d’autorisation consulté par l’équipement doit refuser toute commande hors de la classe d’observation. L’identité permettant d’écrire ne peut pas dormir sur la passerelle sous une forme immédiatement utilisable. Sa mise à disposition suppose une décision par action, prise par un acteur distinct.

La séparation change le sens d’un contrôle. Un filtre logé dans la même passerelle que le secret privilégié disparaît avec la compromission de cette passerelle. Une règle appliquée par l’équipement à partir d’un service extérieur oblige en revanche l’attaquant à franchir un second point de contrôle. Les demandes d’autorisation et les événements de comptabilité doivent en outre emprunter une voie que la passerelle ne peut ni falsifier ni étouffer à elle seule.

Le texte ne prétend pas avoir inventé ces briques. La RFC 8907 décrit depuis longtemps l’autorisation TACACS+ commande par commande et la comptabilité. Les comptes d’administration limités à la lecture sont usuels. La nouveauté revendiquée réside dans leur composition autour d’un demandeur autonome, puis dans la comparaison de son récit avec une trace produite ailleurs.

Il faut maintenir la portée institutionnelle exacte. La fiche Datatracker présente VIRP comme un Internet-Draft individuel, sans flux RFC ni responsable AD. Elle rappelle qu’un tel document peut être soumis par quiconque, n’est pas avalisé par l’IETF et n’a pas de statut formel dans son processus de normalisation. Un en-tête IETF ne transforme donc pas l’architecture en décision collective.

Le rapprochement porte sur des preuves qui n’ont pas la même origine

La révision décrit quatre objets. gate_intent/1 annonce l’action avant le contact avec l’équipement ; gate_execution/1 consigne ensuite ce que la passerelle dit avoir fait. Les deux sont déclarés implémentés. device_accounting/1 transporte l’événement de comptabilité produit par l’équipement et reçu par un collecteur indépendant de la passerelle ; ce chemin est également déclaré implémenté.

authorization_decision/1 demeure différent. Il devrait porter le permis ou le refus du service externe, l’équipement, l’identité, la commande canonique ou son empreinte et l’horodatage. Le format est spécifié, mais l’implémentation de référence ne l’ajoute pas encore à la chaîne. La décision reste dans le journal local du service et rejoint le dossier comme pièce séparée.

Cette lacune explique pourquoi deux refus doivent rester distincts. Le refus du classificateur VIRP est produit et chaîné dans la frontière de collecte. Le refus du service externe appartient à un autre décideur et n’a pas encore la même garde cryptographique. Les présenter sous une étiquette commune ferait disparaître l’endroit où l’autorité a réellement été exercée.

Le rapprochement compare l’équipement, l’identité du principal, l’empreinte exacte de la commande canonique et une fenêtre temporelle déclarée. Un temps non fiable oblige au statut UNRESOLVED. Lorsque les pièces qualifiées concordent, l’action est MATCHED. Le récit isolé de la passerelle devient GATE-ONLY. Une trace d’équipement sans exécution correspondante de la passerelle devient DEVICE-ONLY. DENIED exige la décision d’autorisation elle-même ; son absence ne se déduit pas d’un silence comptable.

Ce vocabulaire est plus qu’une présentation. Il empêche le système de convertir automatiquement un rapprochement approximatif en succès. Il offre aussi un emplacement explicite à l’inconnu, condition indispensable lorsqu’un automate agit sur un réseau réel.

La comptabilité TACACS+ ne signifie pas toujours « exécuté »

La RFC 8907 définit la comptabilité comme l’enregistrement de ce qu’un utilisateur fait ou a fait. Mais, pour l’administration d’équipements, elle demande l’envoi d’un événement de début pour chaque commande saisie, quelle que soit la manière dont cette commande a été autorisée. Selon le constructeur, l’événement peut donc prouver la saisie sans prouver l’autorisation ni l’exécution.

La révision 07 impose en conséquence de documenter, pour chaque classe d’équipements, la sémantique effective : commande saisie, autorisée, exécutée ou événement dont la portée reste inconnue. Un rapprochement ne peut conclure à l’exécution qu’avec une source dont ce sens a été établi.

Le projet rapporte que, lors des exercices annoncés sur Cisco IOS et IOS-XE, l’événement correspondait à une commande exécutée et qu’un refus n’en produisait pas. Il interdit d’étendre ce constat à d’autres plates-formes. Le dépôt de référence, maintenu par le même projet, renseigne l’état revendiqué par l’auteur ; il ne remplace pas une validation indépendante.

La protection du chemin AAA compte également. Le texte renvoie au profil TLS 1.3 de la RFC 9887 lorsqu’il est pris en charge. Une autorité « extérieure » sur un schéma perd son indépendance si la passerelle peut modifier, intercepter ou supprimer les échanges qui transportent décision et comptabilité.

Le droit éphémère existe dans le texte, pas encore dans le programme

Le mécanisme cible est détaillé. Un émetteur autre que la passerelle vérifierait la signature Ed25519 d’un approbateur inscrit, liée à une commande exacte, à un équipement et à une échéance. L’approbation destinée à une seule exécution posséderait un identifiant unique. L’émetteur devrait enregistrer sa consommation de manière durable avant de libérer le droit d’écriture, puis refuser toute réutilisation. L’échéance ne suffit pas : pendant la fenêtre valide, une approbation non consommée resterait rejouable.

La commande approuvée doit encore correspondre à l’invocation envoyée à l’équipement. Si un pilote transforme la forme canonique, cette correspondance doit être démontrée. Une règle textuelle doit être ancrée aux deux extrémités pour empêcher une commande plus longue ou composée de profiter d’un préfixe autorisé. Enfin, la révocation effective inclut le délai de propagation du service ; le retour réussi d’un rechargement ne prouve pas qu’un changement asynchrone est déjà appliqué.

Or la révision 07 classe explicitement ce parcours comme non implémenté. L’état annoncé aujourd’hui est une politique statique : une identité de lecture, une identité d’opérateur et le refus du reste. Ce dispositif peut limiter les dégâts. Il ne faut simplement pas le confondre avec un droit dynamique, lié à une approbation et consommé une fois.

Même prudence pour les signatures de chaîne : la révision ajoute une signature Ed25519 facultative par entrée et par tête, en plus du HMAC obligatoire. Elle est désactivée par défaut et configurable par nœud. Elle ajoute une possibilité de vérification publique, mais ne transforme pas chaque observation en preuve de l’état réel de l’équipement.

Le reçu de garde à exiger

Pour une action d’écriture, un reçu exploitable devrait montrer que l’identité permanente de la passerelle est bien limitée à la lecture, nommer le service d’autorisation distinct, lier l’approbation à l’empreinte exacte de la commande et de la cible, puis consigner l’identifiant unique, la consommation et l’expiration effective du droit.

Il devrait ensuite rapprocher intention, exécution déclarée, décision externe et comptabilité de l’équipement. La fenêtre de temps, l’état des horloges et la sémantique propre à la famille d’équipements doivent accompagner le verdict. UNRESOLVED doit rester une conclusion acceptable.

Ce reçu est ma recommandation, non une exigence de VIRP, de la RFC 8907, de la RFC 9887 ou de l’IETF. Son objectif est simple : empêcher une interface centrale d’emprunter simultanément le pouvoir du service d’autorisation et la valeur probante du dispositif.

Sources