Résumé

  • La RFC 927 a proposé l’option Telnet 26, TUID, pour qu’un hôte ayant déjà authentifié une personne puisse remettre à une cible consentante son identifiant binaire de 32 bits.
  • Le couple WILL TUID / DO TUID devait être établi avant l’envoi de la valeur ; WON'T et DON'T faisaient du refus un résultat normal, non une panne.
  • Les quatre octets désignaient l’utilisateur affirmé par l’hôte source. Ils ne prouvaient ni le contrôle du mot de passe, ni l’autorisation sur la cible, ni le résultat d’une commande.

La RFC 927, publiée par Brian A. Anderson de BBN en décembre 1984, porte un titre presque administratif : TACACS User Identification Telnet Option. Son problème était très concret. Une personne s’était déjà identifiée auprès d’un Terminal Access Controller, ou TAC, avec un nom et un mot de passe corrects. Lorsque le TAC ouvrait ensuite une session Telnet vers un autre hôte pour son compte, fallait-il vraiment recommencer le dialogue ?

La réponse proposée tenait dans l’option TUID, code 26. Le Telnet côté utilisateur pouvait annoncer qu’il authentifierait la personne et enverrait son UUID. Le Telnet serveur pouvait répondre qu’il accepterait cette authentification. Une sous-négociation transportait alors un nombre binaire de 32 bits.

Le dispositif déplaçait donc moins un secret qu’une responsabilité. Le mot de passe restait auprès du premier système. La cible recevait l’affirmation d’un autre opérateur et devait décider si elle méritait confiance.

Une authentification locale devenait une affirmation distante

Le motif exposé par la RFC est précis : TACACS exigeait du candidat un couple nom/mot de passe correct avant de lui permettre de joindre un hôte par le TAC. Pour éviter une seconde authentification, le TAC pouvait transmettre à la cible ce que le texte appelle son identité prouvée, c’est-à-dire son UUID.

Cette expression ne doit pas transformer le paquet en preuve autonome. Le travail de vérification s’était produit en amont. Le nombre envoyé ne rejouait pas l’échange du mot de passe et ne permettait pas à la cible d’en contrôler la justesse. Il référençait le résultat que l’hôte source disait avoir obtenu.

La phrase décisive vient juste après : les hôtes pouvaient accepter l’authentification du TAC, ou non, à leur choix. L’économie d’une invite dépendait donc d’un lien de confiance volontaire. Le TAC pouvait témoigner de son propre contrôle ; il ne pouvait pas imposer à la cible les conséquences de ce contrôle.

L’accord devait précéder la valeur

Le protocole Telnet avait déjà séparé le service minimal des options facultatives. La RFC 854 encadrait l’offre, la demande, l’acceptation et le refus avec WILL, DO, WON'T et DON'T. La RFC 855 ajoutait une règle pour les paramètres : les deux parties conviennent d’abord de comprendre l’option ; la sous-négociation vient ensuite.

Dans TUID, cette grammaire distribuait clairement les rôles. IAC WILL TUID signifiait que le côté utilisateur se proposait d’authentifier l’usager et d’envoyer son identifiant. IAC DO TUID signifiait que le côté serveur demandait ce service ou acceptait de se fier à l’authentification du correspondant. WON'T refusait la première charge ; DON'T refusait la seconde.

Ce n’est qu’après l’accord que IAC SB TUID <uuid> IAC SE transmettait les quatre octets. La RFC illustrait deux ordres valides : le serveur pouvait demander avant l’offre, ou l’utilisateur offrir avant la demande. Elle montrait aussi les deux échecs propres : le côté utilisateur pouvait répondre WON'T, le serveur DON'T.

Les valeurs par défaut étaient précisément le refus. Un logiciel ignorant TUID ne glissait pas par accident dans une relation de confiance. Il restait dans le Telnet ordinaire, où la cible pouvait maintenir sa propre procédure d’identification.

Quatre octets ne portaient pas leur propre garantie

Le mot UUID évoque aujourd’hui un identifiant de 128 bits souvent écrit avec des tirets. La RFC 927 n’emploie pas ce format. Elle définit un nombre binaire de 32 bits. Les exemples montrent les valeurs 1, 255 et tous les bits à un, sans préciser de mécanisme global d’allocation.

Comme Telnet réservait l’octet 255 pour IAC, toute occurrence de cette valeur dans le paramètre devait être doublée. La RFC écrit donc la valeur 255 comme trois octets nuls suivis de IAC IAC. Ce dédoublement assurait la transparence du flux ; il ne chiffrait rien et ne signait rien.

Le document ne définit ni durée de vie, ni anti-rejeu, ni horodatage, ni aléa, ni collision, ni liaison cryptographique à la session. Il ne dit pas comment deux organisations harmonisent leurs espaces de numéros ni comment une cible associe la valeur à un compte local. Une capture peut établir qu’une valeur a été présentée sous TUID. Elle ne démontre pas qui a tapé le mot de passe, si le système source était sain, ou si la base cible donnait le même sens au nombre.

Reconnaître quelqu’un n’autorise pas son action

Accepter l’authentification amont ne répondait qu’à une question : la cible traiterait-elle l’affirmation du premier hôte comme une preuve suffisante de l’identité représentée par la connexion ? La RFC 927 ne conférait aucun droit général de lire un fichier, d’exécuter une commande ou d’obtenir un privilège.

La distinction apparaît plus nettement dans des textes ultérieurs, sans qu’il faille les projeter en 1984. La RFC 1492, reconstruction informative publiée en 1993, décrit TACACS comme une requête nom/mot de passe à laquelle un démon peut répondre par acceptation ou refus. Elle décrit aussi CONNECT comme une décision distincte portant sur une destination dans le contexte d’une connexion déjà ouverte.

Cette source garde une limite importante : son auteur n’avait pas obtenu la spécification TACACS originale pour des raisons de droit d’auteur et avertissait que de nouvelles informations pourraient révéler des erreurs. La prudence historique exige de conserver cette incertitude.

La RFC 8907 concerne le TACACS+ beaucoup plus tardif. Elle sépare authentification, autorisation et comptabilité, et souligne que le protocole n’associe pas lui-même une requête d’authentification à une requête d’autorisation. Ce n’est pas une description rétroactive de TUID. C’est un vocabulaire moderne pour nommer une frontière déjà visible : l’identité affirmée et la permission accordée sont deux décisions.

Le refus local faisait partie du mécanisme commun

La RFC 927 ne créait ni fédération obligatoire ni autorité centrale des identités. Elle indiquait que deux hôtes consentants pouvaient utiliser TUID et citait même les hôtes d’un même site. Le standard rendait leur dialogue interprétable ; il ne désignait pas l’un comme mandataire souverain de l’autre.

Le registre IANA des options Telnet conserve aujourd’hui le code 26 sous le nom TACACS User Identification et renvoie à la RFC 927. Le registre prouve l’affectation durable du code. Il ne mesure ni diffusion historique ni usage actuel.

Cette retenue est le cœur de l’histoire. Une spécification minimale peut fixer la forme d’une affirmation, l’ordre de son échange et la possibilité d’un refus, tout en laissant l’autorité au système qui supportera la conséquence. Le réseau n’avait pas besoin que tous les hôtes partagent une base d’identités. Il avait besoin que ceux qui choisissaient de coopérer sachent exactement quelle parole circulait.

Une interface plus simple exigeait une trace plus riche

Pour l’usager, le gain était visible : un mot de passe de moins. Pour la cible, le coût changeait de forme. Il fallait administrer la liste des sources dignes de confiance, connaître leurs espaces de numéros, maintenir la correspondance locale et retirer rapidement la confiance après une compromission ou une réorganisation.

Un journal ne gardant que « connexion réussie » détruit cette chaîne. Il devient impossible de distinguer une vérification locale, une acceptation TUID, une correspondance de compte, une autorisation de commande et l’effet final dans l’application. L’absence de seconde invite ne doit pas devenir l’absence de second jugement.

Les preuves devraient donc conserver séparément le résultat d’authentification source, la négociation WILL/DO, la valeur et son espace de noms, la politique de confiance cible, le compte local choisi, l’autorisation appliquée et l’action observée. Chaque fait s’arrête à la décision qu’il décrit.

L’apport historique de la RFC 927 n’est pas d’avoir résolu l’identité universelle. Il est d’avoir exposé le marché réel : un hôte pouvait éviter de répéter un secret parce qu’il acceptait la parole d’un autre, mais il restait libre de ne pas l’accepter. L’UUID traversait la connexion ; le mandat de la cible demeurait sur place.

Sources et limites

Cette analyse utilise les RFC 854, 855 et 927, le registre IANA, puis les comparaisons bornées des RFC 1492 et 8907. Elles établissent la syntaxe, la motivation déclarée, l’affectation du paramètre et des distinctions ultérieures. Elles ne prouvent ni large déploiement, ni filiation directe vers l’authentification fédérée moderne, ni protection cryptographique, ni réussite d’une session réelle.