Résumé

  • Publié en mars 2026 comme norme proposée, le RFC 9950 remplace le RFC 9105 et ajoute TLS 1.3 au modèle YANG de TACACS+. Il décrit l’ordre des serveurs, le choix obligatoire entre TLS et l’ancien brouillage, les références d’identifiants, le routage de gestion et des compteurs opérationnels.
  • Une configuration validée n’atteste ni la capacité réelle d’un parc, ni le bon fonctionnement des trois fonctions AAA, ni l’accès de secours. Elle n’identifie pas davantage la personne habilitée à accepter le risque d’une bascule.
  • Un reçu de bascule AAA, limité dans le temps, doit relier la configuration exacte aux essais, aux générations d’identifiants, à la continuité des compteurs, au retour arrière, au décideur et à la fermeture du chemin non chiffré. Ce reçu est une proposition de gouvernance locale, non une obligation de l’IETF.

Le serveur répond, mais la décision reste muette

Une équipe peut préparer une configuration exemplaire : deux serveurs ordonnés, TLS sélectionné pour chacun, certificat client référencé dans un coffre, nom de domaine fixé, SNI activé, interface source et VRF de gestion indiquées. Le validateur YANG n’y trouve rien à redire. Un essai de connexion produit même un voyant vert.

Pourtant, au moment de supprimer l’accès ancien, personne ne peut répondre à quatre questions simples. Tous les routeurs visés comprennent-ils la même révision du modèle ? Le compte d’astreinte conserve-t-il les commandes nécessaires ? La comptabilité TACACS+ arrive-t-elle avec l’identité attendue ? La console locale a-t-elle été essayée sans dépendre du service que l’on modifie ?

Ce silence n’est pas un défaut du RFC. Il marque la limite entre une spécification technique et une décision d’exploitation. Le RFC 9950 normalise une manière de représenter l’état souhaité. L’autorisation de bascule porte sur le passage, nécessairement incertain, de l’état présent vers cet état souhaité.

La nuance est décisive pour l’AAA centralisé. Une erreur touche le mécanisme qui protège les autres mécanismes. Un mauvais chemin de routage, un nom de serveur mal vérifié ou une règle d’autorisation trop étroite peut priver les administrateurs de l’accès dont ils ont besoin pour corriger l’erreur. À l’inverse, conserver sans limite le mode historique maintient la possibilité de rabattre les communications vers une protection plus faible.

Le document de configuration montre donc la destination. Il faut un autre artefact pour prouver que l’organisation peut faire le trajet, revenir si nécessaire et fermer le détour.

Ce que le RFC 9950 rend enfin explicite

Le modèle place les serveurs TACACS+ dans une liste ordonnée par l’utilisateur. Adresse et port doivent former des couples distincts. L’ordre n’est pas une présentation : après un délai ou un échec, il détermine le serveur suivant. La redondance devient ainsi une intention observable, plutôt qu’une série opaque de commandes propres à un constructeur.

Chaque entrée impose un choix de sécurité. La branche TLS réutilise les paramètres YANG prévus pour TLS et permet de référencer des identifiants client ainsi que les éléments servant à authentifier le serveur. L’autre branche conserve le secret partagé de TACACS+, nommé obfuscation. Le RFC le déconseille au profit de TLS, tout en reconnaissant que le parc installé ne disparaît pas le jour de la publication.

Le modèle porte aussi le domaine, l’usage de SNI, le port, l’interface source et l’instance réseau. Ces paramètres forment un seul chemin effectif. Tester un certificat depuis le réseau de production ne prouve pas qu’il sera validé depuis la VRF de gestion. Tester une adresse IP sans le nom attendu ne prouve pas l’identité du service. Déclarer un serveur secondaire sans provoquer le basculement ne prouve pas qu’il prendra le relais.

Des compteurs donnent de la visibilité sur les connexions et les erreurs, notamment celles qui concernent les certificats et les clés publiques brutes. Le champ discontinuity-time indique quand leur continuité a été rompue. Sans cette information, un faible total d’erreurs peut être pris pour une semaine stable alors qu’il ne couvre que les minutes qui suivent un redémarrage.

Cette précision améliore l’automatisation et l’audit. Elle n’accorde aucune autorité. Une machine peut constater que le choix tls est présent ; elle ne sait pas si le comité de changement accepte le risque résiduel, ni si l’équipe de nuit possède réellement une voie de reprise.

Référencer un secret ne prouve pas la confiance

La référence d’identifiant est préférable à la copie d’une clé privée ou d’un mot de passe dans chaque équipement et chaque ticket. Elle facilite la rotation et réduit les fuites. Mais le mot « présent » est trompeur lorsqu’il décrit seulement une référence syntaxiquement valide.

Une référence peut viser une version du coffre disponible sur certains appareils et absente sur d’autres. Le certificat client peut être valide mais associé au mauvais groupe sur le serveur. Le certificat du serveur peut appartenir à une chaîne approuvée tout en présentant un nom qui ne correspond pas au domaine configuré. Une clé publique brute peut être celle de la génération précédente. Une horloge fausse suffit à rendre inutilisable une chaîne pourtant correcte.

Le reçu ne doit donc jamais contenir le secret. Il doit conserver un identifiant non secret de génération : empreinte de certificat, version de coffre, politique d’émission, période de validité et cohorte d’équipements testée. La preuve utile joint cet identifiant à une transaction observée. Une référence nue est trop faible ; une copie du secret est dangereuse.

L’authentification mutuelle ne clôt pas non plus la démonstration. Le routeur vérifie le serveur ; le serveur vérifie le client ; la politique AAA attribue ensuite des droits à l’utilisateur ou à l’automate ; enfin, la comptabilité doit enregistrer l’action sous une identité retrouvable. Le succès de TLS atteste le canal, pas la cohérence de ces décisions successives.

Tester trois fonctions plutôt qu’un seul écran de connexion

TACACS+ distingue authentification, autorisation et comptabilité. Un opérateur pressé transforme volontiers un accès réussi en preuve que « l’AAA fonctionne ». Or une migration de transport peut préserver l’authentification et dérégler les deux autres fonctions.

Un certificat client différent peut conduire le serveur à un groupe de politiques inattendu. L’administrateur se connecte, mais la commande de récupération est refusée. Un profil en lecture seule obtient trop de droits. Les enregistrements comptables utilisent un nouveau nom de client et ne rejoignent plus la bonne recherche. Chacun de ces cas est compatible avec une poignée de main TLS parfaitement saine.

L’essai doit donc suivre les conséquences. Il comprend un administrateur autorisé, une action volontairement refusée, un rôle restreint, un compte d’automatisation et un enregistrement comptable retrouvé dans le système aval. Il ne promet pas que toutes les commandes futures seront correctes ; il vérifie que l’identité, le droit et la trace se rejoignent sur le nouveau chemin.

L’accès d’urgence appartient à cette même preuve. Une procédure de console jamais exécutée n’est qu’une hypothèse. Il faut montrer qu’elle atteint un échantillon représentatif sans solliciter le TACACS+ central, préciser qui en détient les moyens et prévoir comment cet usage exceptionnel sera tracé. Ce contrôle est coûteux ; c’est précisément pourquoi il est souvent omis alors qu’il porte la plus grande part du risque.

La coexistence doit avoir une date de péremption

Le RFC 9887 refuse la détection opportuniste de TLS. La configuration doit indiquer sans ambiguïté quel service est utilisé, et les modes TLS et non-TLS emploient des ports distincts. Durant la migration, leur coexistence laisse une voie de déclassement. Le texte demande donc de réduire cette période et d’isoler sur des serveurs séparés les clients qui ne savent pas encore utiliser TLS.

Le vieux chemin n’est pas une assurance gratuite. Il est une dette de sécurité mesurable dans le temps.

Une marche arrière sérieuse comporte l’artefact de configuration précédent, la procédure d’application, l’opérateur habilité, la voie d’accès et la dernière heure à laquelle le retour reste sûr. La formule « garder le port 49 au cas où » ne remplit aucun de ces critères. Sans date, propriétaire et essai, elle installe le provisoire dans l’architecture.

Mais fermer trop tôt n’est pas plus vertueux. Avant la bascule, le retour doit être réellement essayé sur une cohorte représentative. S’il dépend lui-même de l’AAA central en cours de modification, la circularité impose l’arrêt. Le délai de décision doit aussi tenir dans les périodes de validité des identifiants et dans une fenêtre de compteurs restée continue.

La bonne mesure n’est donc ni « toujours deux chemins » ni « supprimer l’ancien immédiatement ». C’est un intervalle court, observable, attribué à un décideur et terminé par une preuve de fermeture.

Les huit pièces du reçu de bascule

Le reçu proposé reste volontairement extérieur au module YANG. Une norme commune ne doit pas nommer le comité de changement d’une entreprise, pas plus qu’une entreprise ne doit présenter sa procédure interne comme une règle de l’IETF.

  1. Identité de configuration. Révision du module, adaptation constructeur s’il y en a une, empreintes des configurations candidate et active, ordre exact des serveurs.
  2. Capacité de la cohorte. Équipements, versions logicielles, formes d’authentification et versions TLS effectivement testées ; les exceptions sont nommées.
  3. Choix de sécurité et générations. Branche sélectionnée par serveur, références non secrètes des identifiants, attente de nom/SNI et version de la politique de confiance.
  4. Preuve du chemin. Essai depuis la VRF, l’interface source, la destination et le port réels, avec vérification d’identité. Le laboratoire ne remplace pas le réseau de gestion.
  5. Preuve AAA. Résultats d’authentification, d’autorisations permises et refusées, de rôles et de comptabilité retrouvable, tous liés aux mêmes empreintes.
  6. Observation continue. Fenêtre commencée après le dernier discontinuity-time, avec taux et dénominateurs pour les erreurs de connexion et d’identité.
  7. Reprise et autorité. Décideur, risques acceptés, accès local ou console testé, artefact de retour, exécutant et dernière heure de repli.
  8. Clôture. Échéance du mode ancien et preuve de sa suppression ou de son isolement. Toute exception conserve une cohorte, un responsable et une prochaine date.

L’empreinte du reçu le rend comparable, pas infaillible. Sa valeur réside dans les liens entre les éléments. Une modification ultérieure de liste de serveurs, une rotation d’identifiants, une mise à jour logicielle ou un changement de route peut invalider une partie de la conclusion et déclencher un reçu plus étroit.

Protéger celui qui peut écrire la configuration

Le RFC 9950 avertit que ses nœuds modifiables sont sensibles. Détourner la liste de serveurs peut permettre à un attaquant de prendre le contrôle complet d’un équipement. La remarque suit la logique de l’AAA : celui qui choisit le lieu où l’identité est vérifiée influence aussi les permissions et la mémoire des actions.

NACM peut limiter les comptes autorisés à lire ou écrire les nœuds YANG. Cette restriction est nécessaire, mais elle ne lie pas encore une écriture particulière à une preuve et à une décision valables. Un compte techniquement habilité peut agir hors fenêtre ou avec une configuration différente de celle qui a été approuvée.

Il faut séparer préparation, approbation et application, puis lier l’approbation aux empreintes de configuration et de preuve. L’autorisation expire avec la fenêtre. Les dérogations d’urgence restent visibles. Un privilège générique et permanent d’administrateur réseau ne doit pas devenir le substitut d’une décision précise.

C’est là que l’infrastructure sert de miroir politique. La documentation peut dire que le mode ancien doit disparaître ; la personne capable d’en prolonger l’usage détient le pouvoir réel. La procédure peut exiger la comptabilité ; la personne capable d’accepter son absence fixe le seuil réel. Observer le système d’application révèle mieux la constitution de l’organisation que relire ses principes abstraits.

La norme n’a pas à signer à la place de l’opérateur

Demander au RFC un objet universel d’approbation serait une erreur de niveau. Le rôle de la norme est de fournir des sémantiques de configuration interopérables. Le choix du moment, de la cohorte, du risque et du responsable appartient au contexte local.

Cette séparation rend possible une spécification initiale minimale et une décision future localisée. Un opérateur peut ajouter le reçu sans modifier TACACS+ ni prétendre imposer son organisation aux autres. Un autre peut employer un outil différent, pourvu qu’il conserve les mêmes jonctions vérifiables.

L’adoption volontaire n’efface pas les obligations internes. Après avoir choisi TACACS+ pour protéger l’administration, une organisation peut être liée par ses contrats, ses règles d’emploi, ses engagements clients ou ses contrôles d’audit. C’est de ces actes que vient l’autorité de bascule, non du seul numéro RFC.

Enfin, les sources étudiées ne signalent aucun verrouillage ou déclassement subi par un réseau nommé lors d’une migration RFC 9950. Les scénarios décrits sont des mécanismes à tester, pas des faits divers à inventer. Le reçu doit renforcer le réel, non produire le récit qui justifierait son existence.

La fermeture fait partie du changement

À la fin, l’équipe compare l’état actif à l’empreinte approuvée, confirme la continuité des compteurs, retrouve les écritures comptables et vérifie qu’une tentative non-TLS échoue ou ne rejoint que la cohorte ancienne explicitement isolée. La clôture doit être aussi visible que le feu vert initial.

Sinon, le tableau de bord célébrera TLS pendant que la porte précédente restera entrouverte. Le RFC 9950 sait décrire la nouvelle porte ; le RFC 9887 explique pourquoi l’ancienne ne peut pas rester une solution de confort. Aucun des deux ne peut accepter le risque au nom de l’opérateur.

Ce pouvoir doit laisser un reçu : la configuration traversée, les identités actives, les fonctions AAA observées, la voie de retour éprouvée, le décideur responsable et l’heure à laquelle le pont ancien a réellement été levé.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — notice du RFC 9950
  5. RFC 9950 — Modèle de données YANG pour TACACS+
  6. RFC Editor — notice du RFC 9887
  7. RFC 9887 — TACACS+ sur TLS 1.3
  8. RFC Editor — notice du RFC 9105
  9. RFC 9105 — Modèle de données YANG pour TACACS+
  10. RFC 8907 — Protocole TACACS+
  11. RFC 8341 — Modèle de contrôle d’accès à la configuration réseau
  12. RFC 9645 — Modèle YANG pour TLS et DTLS
  13. RFC 9525 — Identité de service dans TLS