Résumé

  • L’exemple de rlogin dans l’annexe du RFC 1507 révèle une question d’identité à plusieurs étapes : la demande part d’une machine, est portée par un utilisateur, puis peut déclencher un appel vers un autre service.
  • DASS pouvait authentifier à la fois l’utilisateur et le nœud d’origine, puis transmettre des justificatifs avec le processus distant. Il rattachait les clés publiques à une hiérarchie de noms X.500 et de CA.
  • Le document était expérimental. Il décrit une architecture et ses dépendances, sans établir qu’elle ait été adoptée par des opérateurs.

Le serveur devait savoir qui était à l’autre bout

L’annexe A du RFC 1507 met en scène un utilisateur qui ouvre une session distante, puis accède à un service depuis cette session. Le service n’a pas seulement à vérifier un message signé. Il doit savoir si la demande vient de l’utilisateur attendu, de la machine qui l’héberge, ou de l’association des deux.

Le Distributed Authentication Security Service, ou DASS, prend au sérieux cette différence. Il traite personnes, ordinateurs et applications comme des principaux capables de s’authentifier. Dans un scénario courant, les justificatifs comprennent deux ensembles de secrets : l’un associé à l’utilisateur, l’autre au nœud. Les deux peuvent signer une demande. La ressource peut alors autoriser « cet utilisateur depuis cette machine » sans confondre l’identité de l’un avec celle de l’autre.

Cette distinction est plus précise qu’un compte unique attaché à un poste. Le RFC rappelle qu’une personne peut avoir des comptes sur dix machines, lesquels ne disent pas spontanément qu’ils appartiennent au même individu. DASS voulait qu’un nom global soit reconnu par chaque nœud, même si l’accès local restait lié à un compte du système d’exploitation. Une règle proche de .rhosts devait assurer la transition : l’hôte pouvait faire correspondre un principal global à son compte local sans autoriser une par une toutes les machines intermédiaires.

L’identité globale n’abolissait donc pas les comptes. Elle changeait la preuve présentée avant d’y arriver. Cette nuance détermine ce que le protocole pouvait établir et ce que le système receveur devait encore décider.

Une hiérarchie de clés plutôt qu’un répertoire unique

Pour DASS, le nom devait être lié à une clé publique. La clé privée permettait de signer une demande ; le certificat, signé par une autorité de certification (CA), associait la clé à un principal et indiquait une date d’expiration. Un vérificateur n’avait pas à connaître la clé de chaque utilisateur à l’avance : il pouvait examiner les certificats qui formaient le chemin de confiance.

Ce chemin suivait la hiérarchie X.500. Chaque CA certifiait les clés des principaux de son répertoire et les clés des CA voisines dans la structure parent-enfant. Une certification croisée pouvait relier deux branches éloignées sans qu’une autorité située à la racine soit nécessairement le point de confiance unique. Le RFC envisage aussi des « îlots » de noms dont les autorités locales seraient connectées par un tiers reconnu.

La hiérarchie ne supprimait pas le pouvoir d’une CA ; elle en bornait le rayon. Une autorité compromise pouvait fabriquer une identité dans son propre périmètre. Plus haut dans l’arbre, l’effet s’étendait davantage ; plus bas, il suivait la branche de répertoire concernée. Le modèle rendait ainsi le compromis de confiance visible dans la structure des noms.

Cette construction avait toutefois un coût de gouvernance pratique. Quelqu’un devait enregistrer le nom, vérifier le lien entre le principal et sa clé, exploiter la CA, puis rendre les certificats consultables. La forme globale de l’identité dépendait d’un service distribué et de ses administrateurs locaux. Une signature mathématiquement valide ne révélait pas, à elle seule, la qualité de cette procédure d’enregistrement.

Les justificatifs accompagnaient le processus

Après l’authentification initiale, DASS prévoyait que le système d’exploitation associe les justificatifs aux processus lancés par l’utilisateur. Lorsqu’un service distant devait en appeler un autre, il pouvait recevoir une délégation. Le document décrit la délégation comme une capacité à agir au nom de l’utilisateur, pas simplement comme une preuve que celui-ci s’est connecté plus tôt.

Les secrets de l’utilisateur pouvaient être disponibles brièvement au moment de la connexion. Le nœud les utilisait pour produire des justificatifs, puis devait les oublier à la déconnexion. Un service pouvait ensuite usurper temporairement le principal délégué. La limite principale de cette version est précisée dans le texte : la durée pouvait être bornée, mais pas encore les droits exacts que le service devait exercer. L’architecture signalait la délégation plus fine comme une possibilité future.

Le premier saut restait une exception. Le RFC reconnaissait qu’avant la disponibilité des cartes à puce, l’authentification initiale par mot de passe pouvait être écoutée. Après le nœud de connexion, le mot de passe ne devait plus circuler sur le réseau. Une carte à puce pouvait conserver la clé privée et signer lors de l’ouverture de session, mais cela reste une proposition d’architecture et de matériel futur.

Les messages signés dépendaient du temps

Le choix entre défi-réponse et horodatage était lui aussi une décision d’exploitation. DASS préférait inclure l’heure dans un message signé plutôt que d’ajouter plusieurs allers-retours. Pour qu’un message intercepté ne soit pas rejoué, le vérificateur devait rejeter les demandes trop anciennes et garder en mémoire les authentificateurs déjà vus dans la fenêtre autorisée.

Le RFC distingue la vérification de validité d’un certificat et la détection du rejeu. La première pouvait fonctionner avec une horloge exacte à quelques heures près. La seconde demandait une heure monotone, coordonnée entre les machines à quelques minutes près, et un état durable des messages récents. Une dérive trop grande pouvait bloquer une demande valide. Un recul de l’heure pouvait permettre de réutiliser un message expiré. Le DASS n’était donc pas uniquement un échange de signatures : il supposait aussi une infrastructure de temps et un stockage anti-rejeu.

Le répertoire portait l’état de révocation

Le RFC exposait deux manières de retirer un certificat après la compromission possible d’une clé. La première consistait à renouveler les certificats avant leur expiration. DASS envisageait une durée ordinaire d’environ un an ; pour maîtriser la charge des CA et les communications avec les utilisateurs, certains renouvellements pouvaient être espacés de plusieurs mois. La protection par expiration était donc une sortie lente, sensible à la précision de l’horloge.

La deuxième méthode consistait à maintenir dans le service de nommage la liste des certificats encore acceptables. Si un certificat disparaissait de cet ensemble, il ne devait plus être cru. C’était plus rapide en principe, mais soumis à la propagation et aux caches. Le document avertit que l’authentification devenait aussi disponible que le service de nommage, tandis que la sécurité du retrait dépendait de la protection de ce service. DASS ne prenait pas alors en charge les listes de révocation X.509.

Cette dépendance complète le tableau commencé par rlogin. Le serveur a besoin du nom, des certificats qui l’étayent, d’une heure cohérente et de l’état courant du répertoire. Si l’un de ces maillons manque ou est périmé, il peut rejeter un utilisateur légitime ou accepter une identité qui aurait dû être retirée. Le RFC décrit ces compromis ; il ne rapporte pas un incident précis.

Une proposition d’architecture, pas une preuve d’usage

Le statut du RFC 1507 est explicite : DASS est expérimental et ne spécifie pas de norme Internet. Le document comporte une annexe sur son utilisation avec le Generic Security Service API. Le RFC 1508 définit séparément l’interface générique, et le RFC 1509 ses liaisons C. Leur voisinage montre une architecture pensée pour des applications, pas le nombre d’applications qui l’auraient intégrée.

Le même mois, le RFC 1510 décrivait Kerberos V5, un autre modèle fondé sur des justificatifs mais structuré autour d’un centre de distribution de clés. Le RFC 1704, publié l’année suivante, répertoriait diverses options d’authentification. Ce contexte ne permet pas de dire que DASS a gagné ou perdu dans les déploiements. Les sources ici ne fournissent pas de mesure d’adoption.

L’intérêt historique de DASS tient plutôt à la manière dont il découpe la demande : l’utilisateur, la machine, le principal nommé, la clé certifiée, le processus délégué et le compte local ne sont pas interchangeables. Le protocole voulait faire voyager une identité tout en laissant des décisions à l’hôte et à la ressource. Pour comprendre ce qu’une réponse authentifiée aurait signifié, il faut conserver toutes ces distinctions.

Sources