Résumé

  • Ident rendait la requête propre à une connexion : les ports désignaient le serveur et le client tels que l’hôte interrogé les voyait, puis cet hôte renvoyait l’identifiant qu’il associait à la socket.
  • Le RFC 931 avait proposé un usage expérimental pour la connexion automatique à FTP. En 1993, le RFC 1413 parle d’un protocole d’identification et interdit de transformer sa réponse en décision d’authentification ou de contrôle d’accès.

Deux ports, un point de vue

L’exemple parlant du RFC 1413 ressemble à une correction de saisie. Une connexion apparaît localement sous la forme 23, 6191 ; pour interroger l’autre extrémité à son sujet, il faut envoyer 6191, 23. La connexion n’a pas changé. Ce sont les termes « local » et « étranger » qui s’inversent parce que la demande est désormais formulée depuis l’autre machine.

Ce renversement servait de clé au protocole. Un client Ident ouvrait une connexion sur le port TCP 113 de l’hôte et envoyait une ligne contenant <port-sur-le-serveur>, <port-sur-le-client>. Les adresses IP provenaient de la connexion TCP vers le service Ident lui-même. Avec les deux ports, elles désignaient une connexion TCP déjà établie. Le serveur pouvait alors renvoyer l’identifiant, dépendant du système, qu’il associait à cette connexion sur sa propre machine.

La portée de l’échange était volontairement étroite. Il ne demandait pas à un service central de retrouver une personne sur Internet ; il demandait à une machine comment son système associait une socket donnée à une chaîne d’identification. Une réponse USERID comprenait un système d’exploitation et un identifiant. ERROR signalait notamment qu’aucun propriétaire ne pouvait être déterminé. Le RFC 1413 prévoyait aussi HIDDEN-USER quand le serveur savait qui utilisait le port mais taisait cette information à la demande de l’utilisateur.

Ce n’était pas la même surface de requête que le service Name/Finger antérieur. Une requête Finger vide pouvait demander la liste des personnes connectées à une machine ; Ident sélectionnait une seule connexion TCP par sa paire de ports. Une liste de présence et une chaîne associée à une socket ne répondent pas à la même question opérationnelle. L’article consacré à Name/Finger traite cette première frontière.

« Authentication Server » : une idée d’application

La filiation commence avec le RFC 912 de Mike St. Johns, publié en septembre 1984 sous le titre « Authentication Service ». Il proposait un service TCP sur le port 113 capable de renvoyer l’identifiant du propriétaire d’une connexion TCP donnée. Parmi les usages possibles figuraient l’authentification automatique dans FTP et la vérification d’opérations privilégiées. Le texte avertissait déjà que la fiabilité variait selon les machines et laissait chaque application décider de la confiance à accorder à la réponse.

Le RFC 931, publié en janvier 1985, a remplacé cette proposition. Il décrivait plus formellement une réponse qui associait un système d’exploitation à un identifiant utilisateur. Pour FTP, il esquissait une commande USER sans argument afin que le serveur puisse s’appuyer sur le service. Le mémo qualifiait expressément cet usage d’expérimental et répétait la mise en garde sur la confiance accordée à l’hôte. Il décrit une intégration proposée ; il ne démontre pas que les serveurs FTP l’aient largement adoptée.

La différence entre une réponse protocolaire et une décision applicative est déterminante. L’Authentication Server ne vérifiait pas un mot de passe de façon indépendante et ne prouvait pas qui se trouvait devant un terminal. Il rapportait l’identifiant local que l’hôte attribuait à une connexion. Un serveur FTP pouvait choisir d’en tenir compte, mais ce choix et ses conséquences relevaient de l’application et de sa relation de confiance avec l’autre machine.

En 1993, le nom a fixé la limite

Publié en février 1993, le RFC 1413 a rendu obsolète le RFC 931 et renommé l’ancien Authentication Server Protocol en Identification Protocol, ou Ident, « pour mieux refléter sa fonction ». Il a conservé le port TCP 113 et la paire propre à chaque connexion. Il a aussi précisé le traitement de plusieurs requêtes sur une même connexion Ident et de réponses telles que HIDDEN-USER.

Les considérations de sécurité laissaient peu de place à une interprétation plus ambitieuse. La confiance accordée aux données ne pouvait pas dépasser celle accordée à l’hôte ou à l’organisation qui l’exploitait. Le protocole ne devait servir ni à l’autorisation ni au contrôle d’accès ; au mieux, il apportait un élément supplémentaire pour auditer les connexions TCP. Le RFC déconseillait fortement les autres usages et signalait le risque de divulguer des informations habituellement privées.

Cette limite découlait du trajet de la donnée. Le serveur produisait son identifiant à partir de la vue de son propre système d’exploitation. Une machine compromise pouvait fournir une réponse trompeuse ; sur une machine de laboratoire ouverte, un utilisateur pouvait peut-être choisir l’identifiant affiché. Une ligne USERID conforme ne transformait pas la déclaration du serveur en fait vérifié indépendamment. Le client apprenait ce que l’hôte interrogé disait de la connexion, pas si une personne avait été authentifiée ailleurs.

Le changement de vocabulaire marque donc une frontière historique utile, sans prouver que tous les usages antérieurs ont cessé. Le RFC 1413 nomme le service « identification » plutôt qu’« authentification » et limite l’inférence qu’il est prudent de tirer de sa réponse. Les RFC ne disent pas combien de sites exploitaient Ident, à quelle fréquence un identifiant était masqué, ni quels logiciels FTP s’en servaient. Un texte de normalisation décrit un protocole ; il ne constitue pas un recensement de son adoption.

Ce que la paire de ports permet d’établir

Dans une piste d’audit, l’identifiant fourni par un hôte peut être un indice utile si l’enregistrement conserve l’hôte, le sens de la connexion, les ports, l’heure et la réponse. Il peut aider à déterminer quel compte local l’autre extrémité associait à une socket. Il ne prouve pas que la personne nommée a initié le trafic, qu’elle contrôlait la machine distante ou que l’application pouvait accepter cette affirmation.

L’histoire du protocole tient à cette séparation. Le RFC 931 décrivait une façon dont une application pouvait consommer une chaîne utilisateur distante. Le RFC 1413 a nommé le service selon l’identification qu’il renvoyait réellement et a déconseillé d’en faire une autorité. Une paire de ports rendait une connexion lisible par l’hôte qui la gérait ; la décision de confiance appartenait toujours au système qui choisissait quoi faire de la réponse.

Sources