Résumé

  • La RFC 9887 attribue un service distinct à TACACS+ sur TLS, impose TLS 1.3 et l’authentification mutuelle, interdit les données applicatives en 0-RTT et proscrit tout repli vers le service non-TLS après un échec.
  • Les deux voies peuvent coexister pendant la transition, mais cette période demeure explicitement non sûre jusqu’à son achèvement ; la joignabilité du service ancien ne prouve pas la continuité du service protégé.

Dans une migration de sécurité, la phrase décisive n’est pas toujours celle qui ouvre la nouvelle voie. C’est souvent celle qui fixe la conduite à tenir lorsque cette voie disparaît. La RFC 9887 donne cette consigne à TACACS+ : un client ne doit pas revenir à une connexion non-TLS lorsque la connexion TLS échoue, y compris pendant la migration.

TACACS+ transporte des décisions d’administration d’équipements. La RFC 8907 distingue authentification, autorisation et comptabilité, mais son ancien brouillage du corps des paquets n’est pas une protection moderne du transport. La RFC 9887 remplace ce mécanisme sur la variante protégée par l’authentification et le chiffrement TLS. Elle ne pose pas une option supplémentaire sur le même service indifférencié.

Deux services réellement séparés

Après l’établissement TCP, la négociation TLS commence immédiatement. Il est interdit de partir d’une session non protégée pour la « mettre à niveau ». Le service TLS écoute séparément du service historique : à défaut de choix explicite, le premier emploie le port TCP 300 et le second le port 49. Le registre IANA associe le nom tacacss au nouveau port.

Cette séparation rend la règle vérifiable. Le filtrage peut distinguer les flux, un acteur en chemin ne peut pas saboter une négociation de montée en gamme et une ambiguïté de configuration expose moins facilement des données sensibles. La RFC recommande aussi des hôtes distincts. Les équipements incapables de TLS peuvent conserver un serveur ancien dédié ; celui-ci ne devient pas pour autant la relève implicite d’un client censé exiger TLS.

Un port ouvert n’établit qu’une possibilité. Il ne démontre ni le pair visé, ni la version négociée, ni le certificat validé, ni la fin du handshake, ni la requête TACACS+ acceptée, ni l’autorisation, ni l’action réellement exécutée. Ces observations ont des responsables et des horloges différents.

Le handshake ne prend pas la décision métier

TLS 1.3 constitue le minimum et les versions antérieures sont interdites. La spécification actuelle est la RFC 9846, complétée pour l’exploitation par la RFC 9325. L’authentification mutuelle par certificats doit être prise en charge comme option commune d’interopérabilité.

Chaque pair vérifie la chaîne et la révocation conformément au profil X.509. L’identité du service suit les règles de la RFC 9525. Une vérification réussie authentifie le pair de transport. Une politique locale peut encore refuser la connexion, puis TACACS+ doit décider ce qu’un utilisateur ou une commande peut faire.

Le raccourci probatoire est donc invalide. Un certificat valable n’est pas une autorisation de commande. Un handshake terminé n’est pas un enregistrement comptable. Une réponse d’autorisation positive ne prouve ni l’exécution de l’action ni l’état final de l’équipement. La protection du transport garde sa fonction propre.

La RFC refuse aussi l’anticipation en 0-RTT. Les données TACACS+ ne peuvent pas précéder l’achèvement du handshake ; l’extension early_data est interdite et le serveur coupe un client qui envoie de telles données. Un ticket de reprise peut aider à établir une nouvelle connexion authentifiée, mais il n’autorise pas une entrée AAA exposée à la répétition.

Une panne ne change pas la règle

L’interdiction de repli empêche un événement de disponibilité de devenir en silence une modification de politique. Un certificat expiré, une révocation, une chaîne incomplète, une autorité de certification inaccessible ou un serveur indisponible créent une pression réelle. Aucun de ces faits ne transforme le serveur ancien joignable en pair protégé acceptable.

Il faut donc concevoir la continuité dans le même référentiel de preuve : plusieurs serveurs sûrs, chaînes provisionnées, révocation disponible, rotation testée, supervision indépendante et récupération hors bande. Une organisation peut prévoir une dérogation humaine, limitée dans le temps et traçable. Elle ne doit pas apparaître comme une branche de nouvelle tentative cachée dans le client.

La migration est une fenêtre d’exposition

La coexistence des deux services peut être nécessaire. La RFC 9887 en nomme néanmoins le coût : la migration reste non sûre jusqu’à sa fin et la période pendant laquelle un client connaît les deux types de serveurs doit être réduite.

Un tableau affichant 90 % de clients migrés ne prouve donc pas que la surface est sécurisée à 90 %. La voie faible restante peut toujours recevoir du trafic sensible ; provoquer l’échec de la voie TLS peut devenir précisément la stratégie d’un attaquant. La fin exige la preuve que les clients concernés utilisent TLS, ne peuvent pas retourner discrètement au port 49 et que les serveurs anciens restants ne servent qu’une population explicitement isolée.

D’autres dépendances doivent rester visibles. SNI apparaît en clair dans le message initial. Un certificat générique concentre le risque sur tous les serveurs couverts et doit être cantonné à un sous-domaine TACACS+ dédié. La découverte de service n’est pas définie. Ces éléments ne désignent aucune autorité institutionnelle ; ils sont des entrées qu’une gouvernance locale doit assumer.

Sources