Résumé

  • RFC 1258, publié en septembre 1991, décrit BSD rlogin comme une implémentation courante largement utilisée, sans en faire une norme Internet. L’ouverture transporte une chaîne vide, les noms d’utilisateur client et serveur, puis des données de terminal.
  • Le raccourci sans mot de passe dépendait d’utilisateurs ou d’hôtes placés dans une confiance locale. Le RFC précise qu’un hôte de confiance compromis peut ouvrir tous les systèmes qui le configurent ainsi, qu’un nom d’hôte peut être usurpé après compromission du DNS ou du réseau, et qu’un fichier de confiance inscriptible peut recevoir des ajouts indignes de confiance.

Le dialogue initial décrivait une demande

Après l’établissement de TCP, le client rlogin envoyait quatre chaînes terminées par nul. La première était vide ; venaient ensuite le nom présenté côté client, le nom de compte demandé côté serveur et le type ou la vitesse du terminal. Le zéro renvoyé par le serveur indiquait qu’il avait reçu ces chaînes et passait au transfert de données.

Cette petite séquence possède une apparence administrative rassurante. Elle expose un demandeur, un compte cible, un terminal et une réponse du serveur. Mais elle ne confond pas ces éléments. Le premier nom est ce que le client affirme ; le second est le compte qu’il demande ; l’information de terminal organise l’affichage ; l’octet zéro accuse réception du début de l’échange. Aucun de ces actes ne vaut, par lui-même, attestation cryptographique de la machine ou de la personne.

RFC 1258 est d’autant plus utile qu’il ne donne pas à ce format une dignité excessive. Il documente un usage commun entre hôtes Unix et explique le confort sémantique du terminal par rapport à Telnet. Il ne transforme ni une chaîne bien formée ni une session qui atteint le mode données en preuve que la décision locale d’écarter le mot de passe était autorisée, inchangée ou juste.

La confiance était une règle de réception

Le mécanisme décisif se trouvait donc hors des quatre chaînes : un système pouvait décider que certains utilisateurs ou certains hôtes n’auraient pas à saisir de mot de passe. Cette décision était prise là où le compte était servi. Elle pouvait s’appuyer sur un nom d’hôte, mais le nom n’était pas un témoin indépendant.

Le RFC dit que la spécification d’un hôte de confiance est ordinairement un nom d’hôte. Il ajoute qu’une compromission du serveur de noms d’une organisation ou de son réseau peut permettre à un hôte non digne de confiance de se faire passer pour un système de confiance. Ce passage ne prouve pas qu’un cas nommé s’est produit ; il sépare précisément ce que le raccourci ne pouvait pas établir.

Le fichier qui contenait les connexions de confiance avait sa propre histoire de garde. S’il était laissé inscriptible par d’autres utilisateurs, des ajouts non fiables pouvaient s’y glisser. Un serveur pouvait donc voir les chaînes attendues et accepter une connexion pendant que l’enregistrement local qui motive l’exception avait déjà perdu son intégrité. L’échange sur le fil ne rendait pas visible l’auteur de la règle.

Une confiance locale pouvait étendre une conséquence distante

Le point le plus net de RFC 1258 concerne l’étendue. Contourner l’authentification par mot de passe pour des hôtes de confiance ouvre tous les systèmes ainsi configurés lorsqu’un seul est compromis. La relation n’était pas seulement un raccourci entre deux terminaux : elle formait un ensemble de dépendances.

Une liste peut sembler modeste sur chaque machine. Pourtant, chaque entrée ajoute une condition dont l’évolution devient pertinente pour les autres machines qui l’acceptent. C’est pourquoi la suggestion historique d’un seul poste de travail admis vers les autres systèmes, plutôt qu’une confiance sans distinction entre tous, mérite attention. Elle ne certifie aucun poste. Elle limite seulement le domaine auquel une compromission peut se propager.

RFC 1258 mentionne aussi les extensions d’authentification sécurisée telles que Kerberos. Ce rappel n’ajoute pas rétrospectivement une preuve aux chaînes de rlogin. Il révèle que les auteurs distinguaient déjà la commodité d’une relation de confiance et un mécanisme d’authentification plus fort.

Sources et limites des preuves

Cet article repose sur RFC 1258, BSD Rlogin. Il établit le statut documentaire de 1991, le terminal, le port TCP décrit alors, les chaînes initiales, l’accusé de réception, la confiance d’hôte et les avertissements liés au DNS, au réseau, aux fichiers et aux extensions. Il n’établit ni usage actuel, ni vulnérabilité présente, ni compromission réelle, ni identité d’utilisateur, ni autorisation, ni résultat de session.