Résumé

  • RFC 1492 est un document informatif de juillet 1993, construit avec Cisco à partir d’une mise en œuvre simple jugée compatible avec une spécification originale inaccessible.
  • Le mémo prévient qu’une découverte ultérieure de l’original pourrait révéler ses erreurs : le code observé circonscrit la reconstruction, mais ne prouve ni le texte perdu ni une norme Internet.
  • Le nonce, la réponse du démon, l’action du serveur terminal et l’ouverture effective d’une connexion sont des reçus distincts ; aucun ne peut absorber les autres.

Le verbe anglais choisi par l’auteur n’est pas décoratif. La mise en œuvre Cisco était believed compatible avec le TACACS simple. Elle n’était pas certifiée conforme par comparaison au document source, puisque ce document existait mais restait hors de portée de l’auteur en raison de questions de copyright. Cette absence constituait précisément la motivation principale de RFC 1492.

Le texte a donc publié une dette de preuve en même temps qu’un protocole exploitable. Il explique qu’une récupération future de la spécification originale pourrait faire apparaître certaines parties comme incorrectes. Au lieu de transformer la collaboration d’un fournisseur en garantie, il distingue l’autorité pratique de l’implémentation et l’autorité documentaire de la source manquante.

Cette distinction est d’autant plus importante que le mémo est Informational et ne définit pas un Internet Standard. Être archivé dans la série RFC rend la description publique, stable et critiquable. Cela ne résout ni la provenance du premier texte, ni la variété des dialectes déployés.

Deux TACACS, deux degrés de continuité

RFC 1492 sépare une version simple de TACACS et une version étendue. La première est celle dont Cisco possédait une implémentation tenue pour compatible avec l’original. La seconde ajoutait des opérations et était utilisée par des serveurs terminaux Cisco ainsi que par le dispositif d’authentification distribué de l’Université du Minnesota. Ces mentions établissent des usages situés. Elles ne prouvent pas une adoption générale, un comportement uniforme ou la réussite d’un déploiement précis.

Le code en fonctionnement apporte néanmoins une contrainte forte. Il révèle quelles demandes sont émises, quels champs reviennent et quelles bifurcations sont possibles. Mais un exécutable peut conserver un bogue, supprimer une option ou ajouter une convention locale. En l’absence du texte initial, l’observation ne dit pas laquelle de ces possibilités relève du dessin d’origine.

LOGIN n’accordait pas tous les CONNECT

Le protocole reliait une demande du client à une réponse du démon. Toute demande devait recevoir une réponse et pouvait donc, en principe, être refusée. Pour LOGIN, une acceptation validait les identifiants fournis et permettait au serveur terminal de commencer une connexion de session. CONNECT venait plus tard, au sein d’une connexion déjà établie, afin de demander l’autorisation d’ouvrir une connexion TCP vers une adresse et un port de destination précis.

Une authentification réussie ne formait donc pas un passeport illimité. Et une réponse positive à CONNECT ne démontrait pas que le serveur terminal avait suivi l’instruction, que le réseau avait livré les paquets ou que la destination avait accepté. Le démon rendait une décision selon ses données ; l’équipement d’accès produisait éventuellement un acte ; la destination et la comptabilité produisaient encore d’autres traces.

L’opérateur du démon choisissait les algorithmes et les données d’acceptation ou de refus. Cette liberté permettait une politique locale, mais empêchait de lire la réponse comme une règle universelle du protocole. Deux sites pouvaient parler le même format et exercer des pouvoirs différents.

Un nonce corrélait, il n’authentifiait pas

Dans l’encodage UDP historique, le service occupait le port 49. Le client plaçait un nonce dans la requête et le démon le recopiait dans sa réponse. La valeur permettait d’associer un datagramme reçu à une question encore en attente. Elle ne prouvait pas l’identité de l’utilisateur, l’authenticité du serveur ou l’intégrité cryptographique de la décision.

Le délai d’attente introduisait une ambiguïté supplémentaire. Le client UDP pouvait réessayer ; le serveur, lui, ne relançait pas. RFC 1492 relève que cette organisation semblait supposer l’idempotence, alors que les demandes ne l’étaient pas réellement. Deux datagrammes identiques peuvent représenter une reprise après perte, mais le premier traitement a peut-être déjà modifié l’état d’une connexion plus vaste. Sans temps, nonce, état du démon et journal d’exécution, le doublon n’est pas automatiquement inoffensif.

Le transport ne protégeait pas le secret

Les variantes UDP et TCP transportaient le nom d’utilisateur et le mot de passe en clair. La section sécurité avertit qu’un observateur du réseau pouvait recueillir ces paires et que le service offrait un terrain de sondage des identifiants. Une réponse ACCEPT ne chiffre pas rétrospectivement la requête qui l’a précédée.

La version TCP cherchait une autre propriété : un cadrage plus simple et une livraison gérée par TCP, avec davantage de place pour les réponses. Elle était explicitement incompatible avec le TACACS historique. Remplacer UDP par un flux fiable améliorait la remise des octets ; cela n’authentifiait pas les extrémités, ne masquait pas les mots de passe et ne démontrait pas l’application de la politique.

TACACS+ éclaire la limite sans réécrire le passé

RFC 8907 a plus tard décrit TACACS+ comme une suite séparant authentification, autorisation et comptabilité. Il avertit également qu’une session de protocole ne correspond pas nécessairement à un utilisateur ou à une action et qu’une demande d’authentification n’est pas automatiquement reliée à une demande d’autorisation. Ce contraste affine notre vocabulaire, mais ne transforme pas rétroactivement TACACS de 1993 en TACACS+.

RFC 927, plus ancien, portait sur l’option TELNET d’identification TUID. RFC 1492 ne doit pas être fondu dans cette histoire : sa singularité tient à la reconstruction d’une spécification indisponible et au partage du pouvoir entre démon et serveur terminal.

La leçon est une discipline des reçus. La garde d’un document, le comportement d’une implémentation, une description publiée, le transport d’une requête, une décision locale et son effet éventuel ont des autorités différentes. Les réunir dans le mot « autorisé » rend l’exploitation commode, mais l’histoire fausse.

Sources