Résumé

  • RFC 9950 distingue l’adresse ou le nom utilisé pour le transport TACACS+ du nom de domaine qui peut alimenter SNI.
  • Cette séparation améliore la description d’une connexion future; elle n’atteste ni l’autorité institutionnelle d’un serveur ni l’autorisation d’un utilisateur.

Dans une configuration centralisée, les noms tendent à recueillir un sens excessif. Un nom de domaine semble pouvoir répondre à des questions qui dépassent la connexion : qui est l’interlocuteur, qui gère le service, qui a le droit de décider, quel résultat doit être accepté. RFC 9950 dessine une frontière plus précise. Son module YANG ajoute un conteneur tacacs-plus au modèle système et permet de déclarer, pour chaque serveur, une adresse, un port, un type de service, un choix de sécurité et plusieurs paramètres de chemin.

Le document introduit notamment un nom de domaine de serveur qui peut être transmis dans l’extension TLS Server Name Indication. Il indique explicitement que ce nom est distinct de l’adresse IP ou du nom d’hôte utilisé pour établir la connexion de transport. Ce n’est pas une nuance de mise en forme. Elle évite de faire d’un identifiant de couche TLS une affirmation totale sur l’itinéraire, la propriété d’une infrastructure, l’organisation responsable ou le jugement que rendra le serveur distant.

Le modèle peut aussi nommer l’interface ou l’adresse source, une instance VRF, un délai d’attente et le mode de connexion unique. Ces choix définissent les conditions dans lesquelles le client tentera l’échange. Une VRF correcte ne garantit pas une décision correcte. Un délai d’attente de cinq secondes ne donne pas une réponse plus vraie. La redondance de la liste de serveurs ne prouve pas qu’un serveur est disponible, honnête ou chargé de la même politique. La configuration décrit la surface de l’expérience future; elle n’en contient pas le résultat.

La sécurité de transport garde elle aussi son objet propre. RFC 9950 peut exprimer des identités de client, de l’authentification de serveur et des références à des ensembles d’identifiants. Il conserve aussi une option d’obfuscation par secret partagé pour une base installée, tout en précisant que cette obfuscation ne fournit pas de protection significative d’intégrité, de confidentialité ou contre la relecture et qu’elle est dépréciée au profit de TLS. RFC 9887 impose TLS 1.3 et l’authentification mutuelle pour TACACS+ sur TLS.

L’authentification mutuelle protège la relation entre deux pairs de transport; elle ne décide pas quelles commandes un utilisateur peut exécuter après cette relation.

Le modèle ne confond pas davantage les trois fonctions AAA. RFC 9950 décrit l’authentification comme validation d’un nom d’utilisateur et d’un mot de passe, l’autorisation comme accès aux commandes selon des niveaux de privilège, et la comptabilité comme suivi de l’activité. Un certificat validé ou un nom SNI envoyé ne transforme pas ces trois questions en une réponse unique. Le serveur peut être joignable et correctement authentifié tout en devant encore appliquer une politique locale et circonstanciée.

Les compteurs opérationnels confirment la nécessité de cette prudence. Les ouvertures, fermetures, échecs et délais de connexion, ainsi que les messages et sessions, sont des observations utiles. Ils peuvent signaler une panne ou un changement de comportement. Ils ne disent pas quel compte a été accepté, quelle règle a été appliquée ou si une commande a produit son effet. Leur caractère en lecture seule ne leur donne pas une portée causale plus large.

Enfin, RFC 9950 traite la configuration elle-même comme un objet de sécurité. Le document avertit qu’une modification non autorisée de la liste de serveurs peut rediriger l’équipement vers un serveur compromis. Le secret partagé reçoit default-deny-all, tandis que les références d’identité et d’authentification reçoivent default-deny-write. Ces restrictions gouvernent qui peut consulter ou modifier la surface de contrôle. Elles ne remplacent pas le responsable qui interprète un échange AAA et décide de ses conséquences.