Groupe de travail Réseau	D.L. Mills	
Request for Comments : 1004	University of Delaware	
Traduction Claude Brière de L'Isle	avril 1987	

Schéma d'authentification pour protocoles répartis

Statut de ce mémoire
L'objet de la présente RFC est de concentrer la discussion sur les problèmes d'authentification dans l'Internet et leurs méthodes de solution possibles. Les solutions proposées dans le présent document ne le sont pas pour l'instant comme normes de l'Internet. Il est plutôt espéré qu'un consensus général va émerger sur la solution appropriée aux problèmes d'authentification, conduisant finalement à l'adoption de normes. La distribution du présent mémoire n'est soumise à aucune restriction.

1.	Introduction et généralités

Le présent document suggère un contrôle d'accès intermédiaire et des procédures d'authentification convenables pour les cas où une association va être établie entre plusieurs utilisateurs appartenant à des environnements de confiance différents, mais qui utilisent des protocoles répartis, comme le protocole existant de passerelle extérieure (EGP, Exterior Gateway Protocol) [2], le protocole proposé de passerelles dissemblables (DGP, Dissimilar Gateway Protocol) [3] et des protocoles similaires. Les procédures proposées sont dérivées de celles décrites par Needham et Shroeder [5], mais spécialisées pour le modèle multi utilisateurs réparti typique de ces protocoles.

Le modèle de confiance et l'environnement des menaces sont identiques à ceux utilisés par Kent et autres [1]. Une association est définie comme le chemin réseau de bout en bout entre deux utilisateurs, où les utilisateurs eux-mêmes sont sécurisés, mais le chemin entre eux ne l'est pas. Le réseau peut laisser tomber, dupliquer ou délivrer les messages avec des erreurs. De plus, il est possible qu'un usager hostile (hôte ou routeur) intercepte, modifie et retransmette des messages. Une association est similaire à la connexion traditionnelle, mais sans les exigences de connexion usuelles de livraison sans erreur. Les utilisateurs de l'association sont parfois appelés les associés.

Les procédures proposées exigent que chaque association reçoive une clé de session aléatoire, qui est fournie par un serveur d'authentification appelé la jarre à cookies (Cookie Jar). Les procédures sont conçues pour ne permettre que les associations sanctionnées par la Cookie Jar tout en fonctionnant sur des topologies de réseau arbitraires, y compris des réseaux non sécurisés et des réseaux à support de diffusion, et en présence d'attaquants hostiles. Cependant, l'intention de ces procédures n'est pas de cacher les données (sauf les clés privées) transmises via ces réseaux, mais seulement d'authentifier les messages pour éviter l'espionnage et les attaques en répétition.

Les procédures sont destinées aux systèmes répartis où chaque utilisateur i fait fonctionner un automate de protocole commun en utilisant des variables d'état privées pour chacune des diverses associations possibles simultanément, une pour chaque utilisateur j. Une association est initiée par l'interrogation de la jarre à cookies pour obtenir une clé à utilisation unique K(i,j), qui est utilisée pour chiffrer la somme de contrôle qui authentifie les messages échangés entre les utilisateurs. L'initiateur de l'échange communique alors la clé à son associé au titre de la procédure d'établissement de connexion décrite en [3].

Les informations échangées dans ce modèle de protocole sont largement destinées à converger dans une base de données répartie pour spécifier (autant qu'il est possible) les contenus, et elles n'exigent pas une distribution fiable des occurrences d'événement, autres que celles destinées à accélérer le processus de convergence. Et donc, le modèle est intrinsèquement résistant à la perte ou duplication de message. Lorsque c'est important, des numéros de séquence sont utilisés pour réduire l'impact du dérangement de l'ordre des messages. Le modèle suppose que les associations entre paires, une fois qu'elles ont été sanctionnées, sont entretenues indéfiniment. L'exception est qu'une association est rompue à la suite d'une panne, perte de connexité ou action administrative comme une reconfiguration ou un changement des clés. Finalement, le taux d'échange d'informations est spécifiquement conçu pour être très inférieur aux capacités nominales du réseau, afin de garder faibles les redondances.

2.	Procédures

Une adresse publique A(i) et une clé privée K(i) sont allouées à chaque utilisateur par une procédure hors bande qui sort du domaine d'application de la présente discussion. L' adresse peut prendre de nombreuses formes : un identifiant de système autonome [2], une adresse Internet [6] ou simplement un nom arbitraire. Cependant, quelque soit la forme qu'il prend, chaque message est présumé porter à la fois l'adresse de l'envoyeur et celle du receveur dans son en-tête. Chaque adresse, et sa liste de contrôle d'accès, est présumée disponible dans un répertoire public accessible à tous les usagers, mais la clé privée n'est connue que de l'utilisateur et de la jarre à cookies et n'est pas divulguée dans les messages échangés entre usagers ou entre les usagers et la jarre à cookies.

Une association entre i et j est identifiée par la chaîne binaire consistant en l'enchaînement des adresses A(i) et A(j), avec la clé à utilisation unique K(i,j), sous la forme [A(i),A(j),K(i,j)]. Noter que l'association réciproque [A(j),A(i),K(j,i)] n'est distinguée que par celui des associés qui appelle le premier la jarre à cookies. Il est prévu dans le modèle de protocole que toutes les variables d'état et clés relevant d'une association précédente soient écrasées lorsque une nouvelle association est initiée et aucune mise en antémémoire (suggérée dans [5]) n'est admise.

La clé à utilisation unique K(i,j) est générée par la jarre à cookies à réception d'une demande de la part de l'usager i de l'associer à l'usager j. La jarre à cookies a accès à un tableau d'entrées privé de la forme [A(i),K(i)], où i couvre la gamme de l'ensemble des usagers répertoriés. Le répertoire public inclut pour chaque A(i) une liste L(i) = {j1, j2, ...} des associés permis pour i, qui ne peut être mise à jour que par la jarre à cookies. Celle-ci vérifie d'abord que l'utilisateur demandeur j est dans L(i), puis elle génère un nombre aléatoire pour K(i,j) et le retourne au demandeur, qui le sauvegarde et le passe à son associé durant la procédure d'établissement de connexion.

Dans les diagrammes qui suivent, tous les champs non spécifiquement mentionnés sont non chiffrés. Bien que les mises en œuvre naturelles incluent les champs d'adresse de l'en-tête de message dans la somme de contrôle, cela soulève des difficultés significatives, car il peut être nécessaire de déterminer le chemin à travers le réseau lui-même. Comme cela deviendra évident plus loin, même si un agresseur pouvait réussir à altérer les champs d'adresse afin de provoquer une mauvaise livraison des messages, le résultat n'en serait pas une association utilisable.

Le champ de somme de contrôle est calculé par un algorithme qui utilise tous les bits du message y compris les champs d'adresse de l'en-tête du message, puis il est ordinairement chiffré avec le champ de numéro de séquence par un algorithme approprié en utilisant la clé spécifiée, de sorte que le receveur prévu est assuré que seul l'envoyeur prévu a pu le générer. Dans le système Internet, le choix naturel pour la somme de contrôle est l'algorithme de complément à un sur 16 bits [6], alors que le choix naturel pour le chiffrement est l'algorithme DES [4] (voir l'exposé qui suit pour des développements de ces points). Les procédures détaillées sont les suivantes :

1.	Le demandeur i déroule un identifiant de message aléatoire I et l'envoie avec le spécificateur d'association [A(i),A(j)] comme demande à la jarre de cookies. L'en-tête de message comporte les adresses [A(i),A(C)], où(C) est l'adresse de la jarre à cookies. Le schéma suivant illustre le résultat :

      +-----------+-----------+
      |   A(i)    |   A(C)    |       en-tête de message
      +-----------+-----------+
      |     I     |somme de ct|       identifiant de message
      +-----------+-----------+
      |   A(i)    |   A(j)    |       spécificateur d'association
      +-----------+-----------+

2.	La jarre à cookies vérifie la liste d'accès pour déterminer si l'association [A(i),A(j)] est valide. Si elle l'est, il déroule un nombre aléatoire K(i,j) et construit la réplique ci-dessous. Il effectue la somme de contrôle du message, chiffre le champ j de cookie avec K(j), puis le chiffre avec les autres champs indiqués avec K(i) et envoie finalement la réplique :

      +-----------+-----------+
      |   A(C)    |   A(i)    |       en-tête de message
      +-----------+-----------+
      |     I     |somme de ct|       identifiant de message (chiffré K(i))
      +-----------+-----------+
      |   K(i,j)  |                   cookie i (chiffré K(i))
      +-----------+
      |   K(i,j)  |                   cookie j (chiffré K(j)K(i))
      +-----------+

3.	À réception de la réplique, le demandeur i déchiffre les champs indiqués, sauvegarde le champ de cookie j (chiffré) et copie le champ de cookie i sur le champ de cookie j, de sorte que les deux champs de cookie sont maintenant le K(i,j) original fourni par la jarre à cookie. Puis il vérifie la somme de contrôle et confronte l'identifiant de message à sa liste des demandes en cours, en conservant K(i,j) pour son propre usage. Il déroule alors un nombre aléatoire X pour le champ de cookie j (pour embrouiller les indiscrets) et un autre I' pour l'identifiant de message (initial), puis recalcule la somme de contrôle. Finalement, il insère le champ de cookie j sauvegardé dans le champ de cookie i, chiffre les champs d'identifiant de message avec K(i,j) et envoie le message suivant à son associé :

      +-----------+-----------+
      |   A(i)    |   A(j)    |       en-tête de message
      +-----------+-----------+
      |     I'    |somme de ct|       identifiant de message (chiffré K(i,j))
      +-----------+-----------+
      |  K(i,j)   |                   cookie i (chiffré K(j))
      +-----------+
      |     X     |                   cookie j (bruit)
      +-----------+

4.	À réception du message ci-dessus l'associé j déchiffre le champ de cookie i, l'utilise pour déchiffrer les champs d'identifiant de message et vérifier la somme de contrôle, et conserve le I' et le K(i,j) pour les utiliser plus tard. Finalement, il déroule un nombre aléatoire J' comme son propre identifiant de message initial, l'insère avec la somme de contrôle dans le message de confirmation, chiffre les champs d'identifiant de message avec K(i,j) et envoie le message:

      +-----------+-----------+
      |   A(j)    |   A(i)    |       en-tête de message
      +-----------+-----------+
      |     J'    |somme de ct|       identifiant de message (chiffré K(i,j))
      +-----------+-----------+

5.	Les messages ultérieurs sont tous codés de la même façon. Lorsque de nouvelles données sont générées, l'identifiant de message est incrémenté, une nouvelle somme de contrôle est calculée et les champs d'identifiant de message sont chiffrés avec K(i,j). Le receveur déchiffre les champs d'identifiant de message avec K(i,j) et élimine le message en cas de somme de contrôle ou de numéro de séquence incorrects.

3.	Discussion

Comme les listes d'accès sont considérées comme en lecture seule pour le public, il n'est pas besoin de valider les demandes de la jarre à cookies. Un agresseur peut intercepter, modifier et répéter des portions des répliques de la jarre à cookies ou des messages ultérieurs échangés entre les associés. Cependant, en supposant que l'agresseur ne connaît pas les clés impliquées, des messages altérés échoueront à la vérification de somme de contrôle et seront éliminés.

La sélection "naturelle" de l'algorithme de somme de contrôle de l'Internet et le chiffrement par DES devraient être reconsidérés. La somme de contrôle Internet a plusieurs faiblesses bien connues, y compris l'invariance à l'ordre des mots et l'échange d'octets. De plus, le champ de somme de contrôle lui-même ne fait que seize bits, et un agresseur déterminé peut être capable de découvrir la clé simplement en examinant toutes les permutations possibles du champ de somme de contrôle. Cependant, les procédures proposées ici ne sont pas destinées à compenser les faiblesses de l'algorithme de somme de contrôle, car cette faiblesse existe que l'authentification soit utilisée ou non. Noter aussi que les champs chiffrés incluent le numéro de séquence aussi bien que la somme de contrôle. Dans EGP et le protocole DGP proposé, le numéro de séquence est une quantité de seize bits qui s'incrémente à chaque message successif, ce qui rend l'altération encore plus difficile.

Dans l'application destinée à EGP, DGP, et dans les protocoles similaires les associations peuvent avoir une durée de vie indéfinie, bien que les messages puissent être envoyées entre les associées de façon relativement peu fréquente. Donc, chaque association devrait occasionnellement subir un changement de clés, ce qui peut être fait par l'un ou l'autre associé en envoyant simplement une nouvelle demande à la jarre à cookies et en suivant la procédure ci-dessus. Pour se protéger contre le glanage des clés privées d'utilisateur, chacun d'eux devrait occasionnellement changer ses clés, ce qui est équivalent à changer les mots de passe. Les mécanismes pour ce faire sortent du domaine d'application de la présente proposition.

Un des caractéristiques du présent schéma est que les clés privées d'utilisateur ne sont pas divulguées, sauf à la jarre à cookies. C'est pourquoi deux cookies sont utilisés, un pour i, qu'il est seul à pouvoir  déchiffrer, et l'autre pour j, déchiffrée d'abord par i puis par j, et qui n'est valide qu'à partir de ce moment là. Un intercepteur se faisant passer pour i et renvoyant à la jarre à cookies la réplique pour j se ferait prendre, car le message va échouer à la vérification de somme de contrôle. Un agresseur qui accèderait à la fois à la réplique de la jarre à cookies à i et au message suivant à j verrait essentiellement une permutation aléatoire de tous les champs. Dans tous, sauf le premier message à la jarre à cookies, le champ de somme de contrôle est chiffré, ce qui rend difficile la récupération des contenus originaux des champs de cookie avant le chiffrage en exploitant les propriétés de l'algorithme de somme de contrôle.

Le fait que les adresses qui figurent dans les en-têtes de message soient incluses dans la somme de contrôle protège contre les répétitions avec des adresses modifiées. Cependant, il peut encore être possible de déstabiliser une association en répétant des messages non modifiés provenant d'associations antérieures. IL y a plusieurs possibilités :

1.	Les répétitions des messages 1 et 2 de la jarre à cookies ont une faible probabilité d'être dommageables, car le demandeur fait correspondre à la fois les adresses et le numéro de séquence à utilisation unique avec sa liste de demandes en cours.

2.	Les répétitions du message 3 peuvent amener l'usager j à) supposer à tord une nouvelle association. L'usager j va retourner le message 4 chiffré avec la clé de session supposée, qui peut être une vieille clé, ou même une clé encore valide, mais avec un numéro de séquence invalide. Dans l'un et l'autre cas, l'usager i va ignorer le message 4.

3.	Les répétitions du message 4 ou des messages suivant ont une faible probabilité de cause des dommages, car la vérification du numéro de séquence va les éliminer.

Le second point ci-dessus représente un sujet de préoccupation légitime, car un attaquant déterminé peut glaner les interceptions du message 3 et les répéter dans les temps. Bien que l'attaque ait peu de chances de réussir à établir une association viable, elle peut produire des dépassements de temporisation fréquents et aboutir à un déni de service. Dans le schéma Needham-Shroeder ce problème est évité en exigeant une épreuve supplémentaire qui implique un message envoyé par l'usager j et une réplique de l'usager i, ce qui revient à une prise de contact à trois épisodes.

Cependant, même si on utilisait une prise de contact à trois épisodes, la redondance de protocole supplémentaire induite par un attaquant déterminé peut toujours résulter un déni de service ; de plus, le modèle de protocole est par nature résistant aux mauvaises performances du réseau, qui a la même signature de performances que l'attaquant. La conclusion est que les dépenses et redondances supplémentaires d'une prise de contact à trois épisodes sont injustifiées.

4.	Application à EGP et DGP

Ce schéma peut être incorporé dans les modèles de protocole de passerelle extérieure (EGP, Exterior Gateway Protocol) [2] et de protocole de passerelles dissemblables (DGP, Dissimilar Gateway Protocol) [3] en ajoutant les champs ci-dessus aux messages Request et Confirm de façon directe. Un exemple de la façon dont cela peut être fait est donné en [3]. Afin de conserver un bon fonctionnement de l'automate à états, il est pratique de traiter la réplique de la jarre à cookies comme un événement Start, en sous-entendant que la demande de la jarre à cookies représente un événement extrinsèque qui invoque cette réponse.

La stratégie d'acquisition de voisins prévue dans le protocole DGP de passerelles dissemblables suit la même stratégie que EGP. La stabilité de l'automate à état EGP, utilisé avec des modifications mineures par DGP, a été vérifiée par la simulation d'état et exposée dans un appendice à [2]. L'un et l'autre associé peut envoyer une commande Request à tout moment, ce qui amène à la fois l'envoyeur et le receveur à réinitialiser toutes les informations d'état et à envoyer une réponse Confirm. Dans DGP, l'opération Request implique la transaction de jarre à cookies (messages 1 et 2) puis la commande Request elle-même (message 3). Dans DGP, les clés sont elles aussi réinitialisées, et chaque retransmission d'une commande Request est authentifiée séparément.

Dans DGP la commande Request (message 3) et tous les échanges de message suivants supposent que les clés sont fournies par la jarre à cookies. L'utilisation de toute autre clé résulte en des discordances de somme de contrôle et en l'élimination des messages. Et donc, l'envoyeur sait que sa commande a été effectuée, au moins au moment où la réponse a été envoyée. Si l'un ou l'autre des associés perd ses variables d'état après cet instant, il va ignorer les messages suivants et il va (lui ou son associé) finalement arriver en fin de temporisation et réinitialiser toute la procédure.

Si les deux associés essayent de s'authentifier en même temps, ils peuvent régler les séquences d'authentification qui traversent le réseau. Noter que le message Request s'authentifie lui-même, de sorte que si une commande est reçue par un associé avant la réponse Confirm à une commande Request antérieure envoyée par cet associé, les clés vont être réinitialisées. Et donc, lorsque la réponse Confirm suivante arrive, elle ne sera pas prise en considération non plus que la commande Request renvoyée à la suite de la fin de temporisation. La compétition qui en résulte ne peut être tranchée que lorsque, du fait des errements des temporisations, les séquences ne traversent pas le réseau. C'est un petit peu plus compliqué qu'avec EGP et implique qu'il faut porter plus d'attention aux expirations de temporisations.

Une désassociation fiable est un concept difficile à saisir comme on en a l'exemple dans les séquences de clôture de TCP. Cependant, le modèle de protocole est ici beaucoup moins exigeant. La façon usuelle de dissoudre une association EGP est lorsque un associé envoie une commande Cease à l'autre, qui à son tour envoie une réponse Cease-ack, cependant, cette transaction est spécifiquement supposée non fiable, avec des temporisations pour casser les boucles de réessai. Dans tous les cas, une nouvelle commande Request va écraser tout l'historique et il en résultera une nouvelle association, comme décrit ci-dessus.

Autrement, la seule façon de désassocier de façon fiable est d'arriver en fin de temporisation. Dans ce modèle de protocole, les associés s'engagent dans un protocole d'accessibilité, ce qui exige que chacun envoie un message à l'autre de temps en temps. Chaque associé arrive individuellement en fin de temporisation après une période pendant laquelle aucun message n'a été reçu de l'autre.

5.	Remerciements

Dan Nessett et Phil Karn ont tous deux fourni des idées et commentaires précieux sur les premiers projets du présent rapport. Steve Kent et Dennis Perry ont tous deux fourni des conseils précieux sur cette révision stratégique.

6.	Références

[1]	Kent, S.T., "Encryption-Based Protection for Interactive User/Computer Communication", Proc. Fifth Data Communications Symposium, septembre 1977.

[2]	Mills, D.L., "Exterior Gateway Protocol Formal Specification", DARPA Network Working Group Report RFC-904, M/A-COM Linkabit, avril 1984.

[3]	Mills, D.L., "Dissimilar Gateway Protocol Draft Specification", en préparation, University of Delaware.

[4]	National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standards Publication 46, janvier 1977.

[5]	Needham, R.M., and M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, pp. 993-999, décembre 1978.

[6]	J. Postel, "Protocole Internet", Groupe de travail Réseau DARPA, RFC-791, USC Information Sciences Institute, septembre 1981.