Résumé

  • La RFC 9887 définit TACACS+ sur un TLS 1.3 minimal. Le client commence TLS immédiatement après l’établissement TCP et n’envoie TACACS+ que comme données applicatives TLS ; un échec TLS n’autorise pas un repli non-TLS.
  • L’authentification mutuelle par certificats doit être prise en charge. Chaque pair valide le chemin du certificat distant, y compris la vérification de révocation. Les PSK TLS et les clés publiques brutes sont des options ; une PSK TLS doit rester distincte du secret d’obfuscation TACACS+ ancien.
  • Le TLS 0-RTT est interdit pour les données TACACS+, car le rejeu constitue un risque. Les tickets de reprise sont à usage unique et la révocation doit être revérifiée lors d’une reprise. L’obfuscation historique est obsolète pour le fonctionnement sous TLS ; les pairs positionnent le drapeau non chiffré puisque TLS fournit confidentialité et intégrité.
  • Un serveur TACACS+ TLS doit refuser les connexions non-TLS. La RFC 9887 considère la phase mixte comme non sûre jusqu’à sa fin et indique que sa durée devrait être réduite au minimum. Les serveurs non-TLS devraient être séparés des serveurs TLS. L’IANA a attribué le port TCP 300 et le nom tacacss ; des ports différents restent possibles avec une considération opérationnelle explicite.

La distinction décisive oppose le comportement du protocole à l’architecture de migration. « Pas de repli » est une règle du client : une tentative TLS échouée ne peut pas devenir silencieusement une tentative d’authentification non-TLS. Cela ne signifie pas que chaque équipement peut être mis à niveau simultanément. Une organisation peut conserver un service patrimonial adressé séparément pour le matériel qui ne peut pas encore migrer, mais cette exception maintient un chemin non sûr ; elle ne rend pas le déploiement global sécurisé. La fin de la migration exige donc davantage que la preuve qu’un point d’accès TLS répond.

Sur le point d’accès TLS, la séquence observable commence par une négociation immédiate après l’établissement TCP, puis les enregistrements TACACS+ circulent dans les données applicatives TLS. La base est l’authentification mutuelle par certificats, avec validation du chemin et de l’état de révocation des deux côtés. Une PSK ou une clé publique brute peut être choisie lorsque le protocole le permet, mais une PSK ne doit pas être confondue avec le secret d’obfuscation patrimonial, ni en tenir lieu. La reprise ne supprime pas la vérification de révocation et un ticket ne doit pas être réutilisable.

Aucun pair ne doit envoyer de TACACS+ en 0-RTT.

TLS fournit confidentialité et intégrité ; le mécanisme d’obfuscation TACACS+ est donc obsolète pour le fonctionnement sous TLS et les pairs positionnent le drapeau non chiffré. Cela ne signifie pas qu’un serveur patrimonial est sûr : il s’agit de la représentation dans l’échange protégé par TLS. Le serveur TLS lui-même n’accepte aucune connexion non-TLS. Un serveur non-TLS exploité séparément est une facilité de migration, pas un point de repli.

Les éléments gelés ne permettent pas d’établir la couverture actuelle des implémentations, l’adoption en production du port TCP 300, la durée observée des migrations ou les incidents de rétrogradation, la disponibilité des autorités de certification, la latence de vérification de révocation dans les réseaux déployés, ni les effets de performance mesurés de la reprise TLS. La RFC 9887 n’établit pas non plus la prévalence des déploiements, leurs résultats, la conformité des fournisseurs, l’historique d’incidents ou l’adoption actuelle par les opérateurs.

Parcours de décision pour l’exploitation

  1. Analyse de Theo March : inventorier chaque équipement, son mode TACACS+, son adresse, ses éléments de confiance, sa capacité de certificat ou de PSK, et sa possibilité d’utiliser TCP 300 ou un autre port explicitement évalué.
  2. Si l’équipement prend en charge TLS 1.3 et l’authentification requise, le déplacer vers le serveur TLS. Vérifier le chemin de certificat et la révocation, ou vérifier la méthode PSK/clé publique retenue et sa séparation d’avec les secrets anciens.
  3. Si la négociation TLS échoue, arrêter et diagnostiquer ; ne pas activer de repli client. Si l’équipement ne peut pas migrer, le placer uniquement sur le service patrimonial séparé et consigner, dans l’analyse de Theo March, un responsable et une échéance pour l’exception.
  4. Analyse de Theo March : à la fin de l’exception, supprimer l’accessibilité patrimoniale, les règles de pare-feu et les routes, ainsi que les identifiants ou secrets anciens ; vérifier ensuite que le serveur TLS refuse le trafic non-TLS. Ces contrôles ne sont pas des exigences supplémentaires de la RFC.

Fixtures de vérification

Utiliser une capture montrant l’établissement TCP immédiatement suivi d’une négociation TLS 1.3, sans octets TACACS+ en clair. Présenter un certificat pair invalide ou révoqué et confirmer le refus. Tenter le 0-RTT et confirmer que les données TACACS+ ne sont pas acceptées dans les données précoces. Réutiliser un ticket de reprise et confirmer l’usage unique ainsi qu’une nouvelle vérification de révocation. Envoyer une connexion non-TLS au récepteur TLS et confirmer le refus ; vérifier séparément qu’un échec TLS produit une erreur plutôt qu’une connexion au service patrimonial.

Inspecter enfin le drapeau non chiffré et l’absence d’utilisation du secret d’obfuscation comme PSK TLS.

Sources