Résumé

  • Proxy-State transporte une valeur privée qu'un serveur mandataire peut ajouter à une requête et récupérer au retour. Les autres mandataires doivent en préserver le contenu et l'ordre relatif, sans en faire une instruction pour leur propre fonctionnement.
  • La conservation n'impose pas un trajet intégral : un mandataire peut garder les valeurs reçues au lieu de les transmettre plus loin, à condition de les rétablir dans sa réponse.
  • L'authentification entre voisins, l'application d'une politique locale et la restitution d'un état sont des engagements distincts. Aucun ne prouve à lui seul que toute la chaîne a respecté la décision initiale.

Le zéro qui ne terminait rien

Un octet nul au milieu d'une valeur peut paraître anodin. Pour un programme qui attend une chaîne de caractères terminée par zéro, il annonce la fin du texte. Pour une valeur Proxy-State, il peut être une donnée aussi importante que les octets qui le précèdent et le suivent. Le supprimer, ou ignorer ce qui vient après, n'est pas une opération de nettoyage : c'est une modification de l'état d'autrui.

Le RFC 2865, publié en juin 2000, définit les chaînes binaires de RADIUS avec une longueur explicite. Leur traitement doit supporter les octets nuls inclus dans la valeur. Le format interne de Proxy-State reste propre au site ou à l'application. Un intermédiaire peut donc savoir exactement où une valeur commence et finit sans savoir ce qu'elle signifie.

Cette séparation est le sujet de l'histoire. L'interopérabilité ne demandait pas à tous les serveurs de partager une représentation interne des transactions. Elle leur demandait de respecter certaines opérations sur des données dont ils n'étaient pas les auteurs. La précision portait sur le contenant et les obligations de restitution ; la retenue portait sur l'interprétation.

Il ne s'agit pas d'un incident particulier retrouvé dans des journaux. L'exemple du zéro montre simplement comment une commodité de programmation peut contredire un contrat de protocole. Une implémentation qui convertit tout en texte avant de retransmettre peut être plus interventionniste, et moins compatible, qu'une autre qui se contente de conserver les bons octets.

Deux relations autour d'un même serveur

Dans le scénario classique, un serveur d'accès au réseau adresse une demande RADIUS à un serveur d'authentification. Le client du protocole est cet équipement d'accès, pas directement la personne qui cherche à se connecter. Si la demande relève d'un autre domaine, le serveur peut la transmettre à un serveur distant, selon sa configuration.

Le mandataire est ainsi serveur pour son voisin en amont du parcours de la requête et client pour le suivant. Il peut être serveur final pour certains domaines et intermédiaire pour d'autres. Plusieurs mandataires peuvent se succéder ; la présence de Proxy-State ne dispense pas d'éviter les boucles et ne fournit pas à elle seule un protocole de routage.

Le RFC 2607, document informatif de juin 1999, examinait cette architecture pour l'itinérance entre réseaux. Il décrivait des avantages de gestion des relations, d'adaptation aux capacités, de politique et de comptabilisation. Mais il avertissait également que les hypothèses de sécurité de l'époque ne convenaient pas à un déploiement étendu sur Internet. Décrire un usage alors répandu n'était pas le déclarer sûr dans n'importe quel ensemble d'organisations.

Ce point est décisif. Un serveur placé au milieu n'est pas seulement un câble supplémentaire. Il termine une relation et en ouvre une autre. Il peut faire un travail utile sans que la confiance accordée par chacun de ses voisins soit transitive jusqu'à l'autre extrémité.

Une convention de retour, pas un langage universel

Proxy-State existait déjà dans le RFC 2138 d'avril 1997. Le texte de 2000 précise davantage les responsabilités d'une chaîne de mandataires. Chaque serveur qui transmet une requête peut ajouter une seule valeur de ce type, après celles déjà présentes. Il ne peut pas réécrire les valeurs précédentes ni inverser leur ordre.

Le serveur final reprend les Proxy-State reçus dans sa réponse, sans modification et dans le même ordre. Cela vaut pour une acceptation, un refus ou une nouvelle demande de preuve : Access-Accept, Access-Reject et Access-Challenge. Le retour de l'état n'est donc pas une récompense réservée aux connexions autorisées. Il permet aussi de terminer correctement un échange qui n'ouvrira aucun service.

Au retour, le mandataire retire le dernier Proxy-State s'il en avait ajouté un : le sien. Puis il rend la réponse au voisin précédent. Il n'a pas besoin de comprendre les valeurs de tous les autres pour savoir laquelle relève de sa propre opération.

Le mot « dernier » ne fixe pourtant pas la position absolue dans le paquet. Le RFC préserve l'ordre entre attributs de même type, sans imposer l'ordre des types différents ni exiger que les occurrences d'un même type soient contiguës. Un autre attribut peut se trouver entre deux Proxy-State ou après le dernier. Une analogie avec une pile explique le retrait successif ; elle ne doit pas inventer une zone obligatoirement compacte à la fin du message.

Le détour par la mémoire locale

Le contrat comporte une liberté plus surprenante. Un mandataire peut ne pas retransmettre les Proxy-State qu'il a reçus. Dans ce cas, il doit les rattacher à la réponse avant de la rendre à son client. Il peut donc préserver l'engagement envers le voisin sans faire voyager ces valeurs jusqu'au serveur final.

Cela change la lecture d'une capture réseau. L'absence d'une valeur sur la liaison suivante ne suffit pas à établir une perte. Sa présence au retour ne prouve pas davantage que le serveur final l'a vue. Pour juger le mandataire, il faut comparer ce qu'il a reçu et ce qu'il devait restituer à la frontière concernée.

La faculté de garder les valeurs localement déplace une responsabilité. Le mandataire qui choisit cette voie doit pouvoir les retrouver quand la réponse arrive. Le protocole n'impose pas sa structure de stockage ; il impose le résultat attendu. La liberté d'implémentation ne supprime pas le travail que l'implémentation s'est attribué.

Trois attributs que leur opacité ne rend pas interchangeables

Le registre RADIUS d'IANA distingue State, Class et Proxy-State, respectivement sous les numéros 24, 25 et 33. Ces références communes ne disent pas que les trois valeurs suivent la même vie.

State peut aider un serveur à poursuivre une conversation d'authentification : il accompagne un défi, puis revient dans la requête suivante. Class peut passer d'une acceptation aux messages de comptabilisation ; la règle de base recommande sa transmission inchangée lorsque cette comptabilisation est prise en charge. Proxy-State appartient, lui, au mécanisme de retour d'un mandataire et est retiré par son auteur.

Le RFC 5080, de décembre 2007, précise qu'une authentification nouvelle ou recommencée ne doit pas réutiliser le State de la conversation précédente. Le même utilisateur sur le même port ne constitue pas nécessairement la même conversation. Réduire tous ces attributs à un « identifiant de session » générique fait disparaître les responsabilités qu'ils séparent.

La comptabilisation exige elle aussi de lire précisément les confirmations. Dans le RFC 2866, informatif et publié en juin 2000, une Accounting-Response suppose que la demande a été reçue et enregistrée. Elle ne signifie pas seulement qu'un paquet est arrivé. Avec des mandataires qui peuvent attendre une confirmation distante ou prendre eux-mêmes une responsabilité de stockage et de retransmission, un accusé local n'établit cependant pas que chaque organisation a déjà enregistré le même événement.

Le droit de changer certaines choses

L'abstention d'interpréter Proxy-State ne transforme pas le mandataire en relais sans politique. Le RFC 2865 permet de modifier certains attributs pour appliquer des règles locales, tout en interdisant la modification des Proxy-State, State et Class déjà présents. L'immuabilité est circonscrite. Toute modification n'est pas une attaque ; toute présence dans le chemin n'est pas non plus une autorisation de tout modifier.

L'authentification du message original se renouvelle entre voisins. Le mandataire vérifie la réponse avec le secret partagé avec le serveur distant et la rejette si cette vérification échoue. Il enlève sa propre valeur éventuelle, rétablit l'Identifier correspondant à la requête du client précédent et recalcule l'authentificateur pour cette relation. On ne transporte pas une enveloppe cryptographique intacte d'une extrémité à l'autre.

Le RFC 2607 relevait justement qu'un intermédiaire malveillant pouvait contredire la politique attendue. Une règle qui lui interdit de transformer un refus en autorisation n'est pas, par elle-même, un mécanisme qui rend cette action techniquement impossible. Il faut distinguer la permission prévue, la capacité matérielle et la preuve disponible après coup.

Des protections plus récentes, toujours délimitées

Le RFC 6614, expérimental, introduit en mai 2012 un transport RADIUS sur TLS. Le mandataire conserve néanmoins son accès aux messages qu'il traite. Le RFC 9765, également expérimental, définit en avril 2025 le profil RADIUS/1.1 pour TLS et DTLS, en retirant de la liaison concernée les anciens mécanismes de paquet fondés sur MD5 et les secrets partagés.

Ces évolutions ne sont ni une invitation à utiliser aujourd'hui les protections anciennes, ni la preuve que toutes les installations ont adopté le nouveau profil. Un mandataire peut négocier séparément les transports de ses deux côtés. La protection d'un lien ne décrit donc pas nécessairement celle du suivant, et ne garantit pas la conservation de toutes les décisions prises auparavant.

L'opacité de Proxy-State ne remplace aucune de ces protections. Elle limite le couplage des significations privées, pas la visibilité physique des données. Son apport historique est plus précis : savoir transporter et restituer une valeur ne donnait pas le mandat de lui attribuer un sens commun. Il était possible d'être strict sur les obligations partagées tout en laissant les choix internes chez ceux qui les exécutaient.