Résumé

  • Pour Butler Lampson et ses coauteurs, l’ordinateur entend d’abord un canal — connexion, clé ou appel système — puis doit établir pour quel principal ce canal peut parler.
  • Cette authentification ne donne pas encore la permission : l’opération, l’objet, la règle d’accès, la délégation et la fraîcheur des preuves restent des décisions séparées.

La requête arrive sans visage

Dans Authentication in Distributed Systems: Theory and Practice, publié en 1992, la scène initiale est volontairement austère. Une ressource est protégée par un gardien. Une requête arrive. Elle a pu traverser le fil d’un terminal, une connexion réseau, un tube entre processus, un appel au noyau ou un canal obtenu après déchiffrement. Rien, dans cette arrivée seule, ne permet de sauter directement à une personne.

Butler Lampson, Martín Abadi, Michael Burrows et Edward Wobber donnent deux noms à deux travaux distincts. Authentifier, c’est déterminer qui a émis la déclaration. Autoriser, c’est interpréter la règle attachée à l’objet et décider si ce principal peut accomplir cette opération. La qualité de la première preuve ne remplit pas la seconde case.

Cette séparation protège le raisonnement contre des raccourcis familiers. Une signature valide n’est pas toute une identité. Une adresse réseau n’est pas un compte. Un compte n’est pas nécessairement la personne assise devant l’écran. Un intitulé de rôle ne contient ni sa nomination ni sa durée. Le système doit exposer les ponts qui relient ces éléments.

Le canal est déjà un principal

Le mot « principal » ne désigne pas seulement un humain. Le papier compte parmi les principaux nommés les personnes, machines, services, rôles et groupes. Les canaux forment une autre famille : un fil, une clé de chiffrement, une adresse réseau ou un mécanisme du système d’exploitation peuvent apporter directement une déclaration à l’ordinateur. Des rôles et délégations composent ensuite des principaux plus précis.

Ce choix de vocabulaire n’humanise pas la clé. Il empêche au contraire de la prendre pour un être humain. Si une signature est vérifiée, la conclusion immédiate concerne le canal défini par cette clé. Si le noyau attribue un appel à un processus, la conclusion dépend du système local. Si un paquet porte une adresse source, la solidité de ce canal réseau reste à apprécier.

La multiplication des sous-canaux n’augmente pas cette solidité. Une connexion peut porter plusieurs ports, puis chaque port plusieurs appels distants. Les auteurs soulignent qu’un sous-canal n’est pas plus digne de confiance que le canal principal. La granularité aide à nommer le trajet ; elle ne répare pas une prémisse faible.

« Parle pour » interdit le saut

La relation centrale peut se lire ainsi : si A parle pour B, une déclaration de A permet au vérificateur de procéder comme si B l’avait faite. Elle sert à chaîner le canal observé, une clé, un nom, une machine, une personne, un rôle ou un groupe. La chaîne ne dit pas que ces éléments sont identiques. Elle dit quelle responsabilité le système accepte, à partir de quelles prémisses.

Une clé de session peut parler pour une clé durable sans devenir cette clé. Une personne peut agir dans le rôle de responsable sans posséder le rôle pour toujours. Un membre peut parler pour un groupe dans le sens limité choisi par le modèle, alors que l’adhésion du groupe évolue. La relation donne une grammaire aux changements que le mot « identité » masque souvent.

Elle peut aussi être restreinte. Parler pour quelqu’un à propos de la lecture d’un fichier n’équivaut pas à parler pour lui sur toute opération et tout objet. Cette qualification importe plus que la longueur d’une chaîne : une preuve étendue avec discipline reste bornée, tandis qu’un seul lien trop large peut ouvrir un pouvoir inattendu.

Un nom dépend de celui qui l’atteste

Dans l’exemple à autorité de certification unique, l’autorité signe l’affirmation qu’une clé parle pour un principal nommé. Le destinataire peut tirer le certificat depuis une base non digne de confiance, car il vérifie la signature. Mais il doit déjà connaître la bonne clé de l’autorité et lui reconnaître le pouvoir d’émettre ce type de liaison.

Le stockage n’est donc pas l’auteur de la vérité ; l’émetteur ne disparaît pas pour autant. Le nom reste situé dans un espace administré. Le papier de 1986 A Global Authentication Service without Global Trust, signé par Andrew Birrell, Lampson, Roger Needham et Mike Schroeder, rendait déjà ce point explicite : nommer un rôle révèle les entités auxquelles on fait confiance pour l’authentifier, et le client doit pouvoir choisir le moment où un nom mutable est lié à un principal.

Le remplacement de la clé d’une autorité illustre le coût de cette dépendance. Anciennes et nouvelles attestations doivent parfois coexister pendant que les clients apprennent une nouvelle racine de confiance. Le passage n’est pas une maintenance invisible : il modifie la preuve que chaque client peut accepter.

Déléguer crée un acteur composé

L’expression « B pour A » ne signifie pas que B devient A. Dans la construction du papier, A délègue et B accepte explicitement. Le principal qui en résulte porte les deux contributions. Cette précision est utile pour un serveur de calcul, une application agissant pour un utilisateur ou un rôle temporairement assumé : l’action garde la trace de son intermédiaire.

La durée compte autant que les noms. Les délégations courtes sont rafraîchies ; lors de la déconnexion, une station peut oublier la clé temporaire qui lui permettait de renouveler les justificatifs. Elle ne devrait alors plus continuer à agir au nom de l’utilisateur. Pour un calcul de longue durée, le papier ne promet pas une solution magique : disponibilité, commodité et révocation restent en tension.

Les caches créent la même dette. Conserver le fait qu’une clé parle pour un principal accélère les décisions, mais retarde la disparition d’une clé compromise ou d’une appartenance retirée. Les auteurs choisissent des durées de vie et un rafraîchissement. Une durée courte réduit la fenêtre d’obsolescence et augmente la dépendance envers la source disponible.

L’objet garde le dernier mot

Après seulement vient l’autorisation. La liste de contrôle est attachée à l’objet protégé ; elle associe des principaux à des droits. La requête vise une opération. Le gardien doit montrer que son principal parle pour une entrée qui possède précisément le droit requis.

Une authentification réussie peut donc conduire à un refus parfaitement correct. Une appartenance de groupe valable ne donne pas accès à tous les objets. Une délégation acceptée pour une tâche ne se propage pas d’elle-même ailleurs. Pour comprendre une décision, il faut joindre la requête à la version de la règle, à l’objet et aux prémisses présentes à cet instant.

Le système décrit cherche à échouer de manière sûre : en cas de doute, il peut refuser une demande légitime, mais ne doit pas créer une autorisation injustifiée. Ce choix protège la ressource tout en pouvant ressembler à une panne pour l’utilisateur. Un refus sans motif observable ne permet pas de distinguer une défense correcte d’une chaîne de preuves cassée.

Conserver le pourquoi de la décision

Le papier propose que la preuve d’accès entre dans la piste d’audit. Ses prémisses viennent de déclarations reçues sur des canaux et d’hypothèses du gardien ; chaque étape applique une règle identifiée. La trace peut ainsi expliquer quel accès a été accordé et pourquoi, au lieu de ne garder qu’un événement « autorisé ».

Elle ne sanctifie pas les prémisses. Une chaîne formellement correcte bâtie sur un canal compromis reste la preuve fidèle d’une hypothèse fausse. L’apport durable de Lampson et de ses coauteurs est plus modeste et plus exigeant : obliger l’infrastructure à montrer la distance entre ce qu’elle a entendu et le pouvoir qu’elle a accordé.

Sources