Résumé

  • IDENT établissait une seconde connexion TCP vers le port 113 de l'hôte distant. La paire de ports de la première connexion, ordonnée du point de vue de l'hôte interrogé, désignait l'état local à examiner.
  • Le projet a perdu un mot à mesure que sa portée devenait plus honnête : Authentication Service en 1984, Authentication Server Protocol en 1985, puis Identification Protocol en 1993.
  • RFC 1413 réserve le résultat à l'audit et interdit d'en faire un identifiant de contrôle d'accès. L'hôte distant peut répondre, cacher, ignorer ou mentir ; le nom reste donc une déclaration située.

Un nom venu de l'autre système

Un serveur B reçoit une connexion depuis le port 6191 de l'hôte A vers son port 23. B connaît les adresses et les ports ; il ne connaît pas l'association tenue par le système d'exploitation de A. Pour l'obtenir, B ouvre une connexion distincte vers A sur TCP 113 et envoie 6191, 23.

L'ordre paraît anodin. Il ne l'est pas. Le premier nombre est local pour celui qui répond, A ; le second est distant pour A. Sur la connexion initiale, B voyait exactement l'inverse. Une requête 23, 6191 ne désigne donc pas le même état et doit échouer ou rester sans résultat utile.

RFC 1413 tire les deux adresses IP de la connexion qui porte la requête. Avec les deux ports, elles forment un périmètre à quatre éléments. IDENT ne demande pas la liste des comptes de A et ne consulte pas une identité mondiale. Il demande à A ce que A associe, à cet instant, à une connexion précise entre A et B.

La réponse USERID répète la paire de ports, fournit un type de système d'exploitation et une chaîne. Le champ de système et un paramètre facultatif de jeu de caractères aident à lire la chaîne, sans lui donner une signification universelle. La valeur OTHER peut même annoncer un jeton non formaté plutôt qu'un nom de compte classique.

L'ambition de 1984

Le premier texte du dossier fermé porte un titre plus fort. RFC 912, en septembre 1984, décrit un Authentication Service au port 113. Parmi les usages envisagés, un serveur FTP pourrait comparer le nom annoncé dans l'application avec l'utilisateur auquel l'autre machine attribue la connexion. Le texte évoque aussi des opérations privilégiées.

La fragilité est déjà reconnue : le résultat dépend de la confiance accordée à l'hôte étranger, à son système de comptes et à sa capacité d'empêcher un usager local de manipuler le service. Si cet hôte est compromis ou complaisant, il peut fournir le nom attendu.

RFC 931, publié en janvier 1985, formalise l'Authentication Server Protocol. La grammaire paire de ports, USERID ou ERROR et OPSYS apparaît, ainsi que des idées de correspondance vers des privilèges locaux. Le mécanisme semblait pouvoir éviter que chaque application refasse une identification.

Or le serveur interrogé ne produisait qu'une association interne. Il ne démontrait pas qui utilisait effectivement le terminal, ne protégeait pas cryptographiquement le retour et ne créait pas de convention commune entre organisations. Un même libellé pouvait désigner des sujets différents, ou être choisi pour provoquer précisément la décision attendue.

Une correction dans le titre

En février 1993, le groupe de travail IDENT de l'IETF publie RFC 1413, qui remplace RFC 931. Le protocole devient Identification Protocol afin, dit le document, de mieux décrire sa fonction.

La section de sécurité fixe alors une limite sans détour. L'information peut être utile à l'audit, mais ne doit pas servir d'identifiant de contrôle d'accès. Si B ouvre une ressource parce que A répond alice, A détient de fait la faculté de fabriquer le nom qui ouvre la porte. La seconde connexion n'a fourni aucune autorité indépendante de A.

La distinction ne rend pas le relevé vain. B peut conserver la réponse avec l'heure, les adresses, les ports et le journal applicatif. L'administrateur de A peut ensuite rapprocher ce paquet de ses connexions, sessions et processus. La réponse accélère une enquête coopérative ; elle ne clôt pas l'enquête.

Le changement de nom est ainsi un progrès de précision. « Identification » décrit ce qu'un hôte déclare associer à un flux. « Authentification » aurait laissé entendre que le réseau avait vérifié une personne ou une qualité que l'autre partie pouvait invoquer.

Le temps compte autant que la paire

Les ports éphémères sont réutilisables. Une paire enregistrée sans heure peut correspondre, plus tard, à une autre connexion. Une trace exploitable doit donc garder les deux adresses, les deux ports, le sens, l'heure de la connexion initiale et l'échange IDENT complet.

La dérivation des adresses depuis la connexion de requête limite les questions hors contexte, mais ne crée pas de preuve cryptographique. Le réseau reste ordinaire et le contenu de la réponse reste sous le contrôle de l'hôte interrogé. La syntaxe exacte établit la pertinence d'une question ; elle n'établit pas la véracité de la réponse.

Le refus de répondre est aussi une réponse de politique

RFC 1413 prévoit plusieurs erreurs. INVALID-PORT signale une requête mal formée ou un port invalide. NO-USER signifie que le service ne sait pas attribuer la connexion à un utilisateur. HIDDEN-USER signifie qu'il le saurait peut-être, mais que sa politique interdit la divulgation. UNKNOWN-ERROR évite d'exposer un détail interne ; une fermeture avant réponse doit être traitée de la même manière.

Ces états n'autorisent pas les mêmes conclusions. HIDDEN-USER n'accuse personne. NO-USER ne démontre pas l'anonymat. UNKNOWN-ERROR ne prouve pas l'absence de correspondance. Chacun décrit ce que le système distant accepte ou parvient à dire à cet instant.

Le RFC compare les enjeux de vie privée à CallerID et Finger. Un nom banal dans les journaux locaux devient une divulgation nouvelle si tout service auquel l'utilisateur se connecte peut le demander. Désactiver IDENT, masquer certains comptes ou renvoyer un alias protège différemment et modifie, en contrepartie, la valeur de corrélation.

Une table de gestion ne transforme pas une déclaration en preuve

RFC 1414 définit une MIB pour le protocole. Ses index sont l'adresse locale, le port local, l'adresse distante et le port distant. Le modèle reprend donc la même géométrie à quatre éléments et expose un identifiant ainsi qu'un état.

RFC 1414 est aujourd'hui classé Historic ; RFC 1413 reste affiché Proposed Standard par le RFC Editor. Ces statuts racontent la trajectoire documentaire, pas le nombre de machines qui répondent aujourd'hui. La MIB répète d'ailleurs que l'identification n'est pas souveraine et ne doit pas commander l'accès. Une valeur structurée devient plus facile à interroger, pas plus vraie.

Le registre IANA des noms de service et des ports conserve ident et l'ancien nom auth pour TCP 113. Il normalise le lieu de rendez-vous et garde la mémoire du changement de nom. Il ne certifie ni le compte, ni l'OS, ni la politique de l'hôte qui répond.

La portée utile d'une déclaration limitée

IDENT a rendu visible une séparation que les systèmes automatisés oublient facilement. L'attribution répond : « quel identifiant cet hôte rattache-t-il à cette connexion ? » L'autorisation répond : « que mon service permet-il, sur la base de preuves qu'il accepte ? » La ressemblance entre les chaînes ne fusionne pas les deux décisions.

La requête est bornée par deux hôtes, deux ports et un moment. La réponse est bornée par l'état et la politique de l'hôte distant. Les erreurs admettent l'ignorance ; HIDDEN-USER admet le secret ; la sécurité admet le mensonge. Dans ce cadre, le nom enrichit une chronologie. Hors de ce cadre, il devient un raccourci contrôlé par la partie même que l'on cherchait à vérifier.

Sources et limites de la preuve

Ces sources établissent les spécifications successives, la MIB et l'enregistrement du service. Elles ne mesurent ni le déploiement actuel, ni l'exactitude des réponses, ni les pratiques de confidentialité, ni la fréquence des abus. Aucun comportement non documenté de traducteurs d'adresses, de mandataires ou de conteneurs n'est déduit ici.