Résumé

  • L’Identifier RADIUS ne compte qu’un octet. Il sélectionne une requête encore en attente ; le client vérifie ensuite le Response Authenticator à partir de l’Authenticator de 16 octets de cette requête et du secret partagé sur le saut.
  • Une retransmission inchangée vers le même serveur conserve l’Identifier, le Request Authenticator et le port source. Le serveur renvoie la réponse mise en cache sans rejouer l’authentification ; toute modification des attributs ouvre une nouvelle tentative.

Le problème n’était pas de trouver un numéro plus grand

Le format RADIUS place un Code, un Identifier de huit bits, une longueur, un champ Authenticator de seize octets et une suite d’attributs au début de chaque échange. Deux cent cinquante-six valeurs semblent peu pour une infrastructure qui peut traiter plusieurs connexions simultanées, perdre des datagrammes UDP, consulter un serveur secondaire et enchaîner plusieurs défis.

Le premier RFC RADIUS, RFC 2058, paraît en janvier 1997. RFC 2138 le remplace dès avril, puis RFC 2865 stabilise en 2000 l’architecture classique. Aucun de ces textes ne transforme l’octet en registre universel. Il « aide » à rapprocher requête et réponse.

Sa portée est délibérément courte. Pour une même adresse source et un même port UDP, le client ne doit pas réutiliser une valeur tant que la requête précédente attend une réponse ou n’a pas expiré. RFC 5080 conseille une allocation par valeur la moins récemment utilisée. Le numéro 37 signifie donc « le 37 actuellement en attente dans ce contexte », et non « la trente-septième authentification de l’histoire ».

Le protocole n’a pas agrandi une autorité centrale chargée de distribuer des numéros. Il a réduit la prétention du numéro.

Une réponse devait porter la trace de sa question

Dans un Access-Request, le champ de seize octets est le Request Authenticator. RFC 2865 demande de le changer avec tout nouvel Identifier et recommande une valeur imprévisible, unique pendant la durée de vie du secret partagé.

Cette exigence ne sert pas seulement à multiplier les combinaisons. La répétition d’un Request Authenticator avec le même secret peut rendre réutilisable une réponse interceptée. Une valeur future prévisible peut permettre à un adversaire de faire préparer une fausse réponse avant la requête légitime.

Le serveur recopie l’Identifier dans Access-Accept, Access-Reject ou Access-Challenge, puis calcule le Response Authenticator sur le Code, l’Identifier, la longueur, le Request Authenticator original, les attributs de réponse et le secret partagé. À la réception, le client utilise d’abord l’octet pour retrouver une requête candidate encore en attente. Il vérifie ensuite le calcul avec la valeur de seize octets propre à cette requête.

Une vieille réponse portant le bon numéro mais liée à une ancienne question échoue donc au contrôle. L’Identifier réduit la recherche ; le Request Authenticator lie la réponse ; le secret authentifie le pair sur ce saut ; l’état en attente donne une échéance. La preuve est composée.

Retransmettre ne voulait pas dire recommencer

RADIUS a choisi UDP parce qu’une décision d’accès tolère quelques secondes, mais guère une livraison fiable plusieurs minutes plus tard. Le client garde une copie au-dessus du transport, gère ses minuteries et peut réessayer ou interroger un autre serveur.

Cette liberté exige une règle nette. Si les attributs ne changent pas et que le client retransmet vers le même serveur, il doit conserver Request Authenticator, Identifier et port source. Le nouveau datagramme représente la même tentative de livraison.

Si un attribut change, l’Identifier et le Request Authenticator doivent changer aussi. Ajouter un horodatage, remplacer une réponse de mot de passe ou demander un autre service ne rafraîchit pas une ancienne requête : cela pose une nouvelle question. L’identité humaine peut rester la même ; l’identité transactionnelle ne l’est plus.

Cette distinction évite qu’une propriété sociale floue — « c’est toujours le même utilisateur » — remplace un invariant vérifiable sur le réseau.

Le serveur répétait la réponse, pas la décision

RFC 5080 rend obligatoire la détection des Access-Request en double et la conservation temporaire de la réponse produite. Si le doublon arrive après Access-Accept, Access-Reject ou Access-Challenge, le serveur renvoie la réponse originale sans traiter de nouveau la requête. S’il arrive pendant le traitement, il est silencieusement écarté.

Le choix protège les effets annexes. Un système d’identité peut incrémenter un compteur, consommer un code à usage unique, inscrire une ouverture de session ou lancer une consultation coûteuse. Deux datagrammes causés par une perte ne doivent pas produire deux actes métier.

Le cache compare adresse source, port source, Identifier, socket de réception et Request Authenticator. Il ne vit normalement que cinq à trente secondes. Si les quatre premières coordonnées correspondent mais que le Request Authenticator diffère, l’entrée précédente est invalidée : la ressemblance visible ne suffit pas à faire du paquet un doublon.

Renvoyer le verdict mis en cache ne donne pas à celui-ci une éternité. C’est une réparation bornée d’une livraison probablement perdue.

Une requête modifiée retirait toute compétence à l’ancienne réponse

Imaginons un premier Access-Request encore en calcul. Le client modifie ensuite un attribut et envoie une nouvelle tentative avec de nouveaux matériaux. La réponse tardive du premier serveur peut être cryptographiquement correcte pour l’ancien paquet. Elle n’est plus compétente pour le paquet courant.

Le client doit abandonner les réponses de l’ancienne tentative. Il traite la première réponse valide de la requête encore en attente et rejette les suivantes comme non sollicitées. Une réponse ne conserve pas son droit de décider après la fermeture de la fenêtre qui lui donnait sens.

Access-Challenge illustre le même principe dans une conversation à plusieurs tours. Le serveur peut rendre un attribut State et demander une réponse supplémentaire. Le NAS envoie alors un nouvel Access-Request, avec un nouvel Identifier et un nouveau Request Authenticator, tout en retournant State. State relie les tours de la session ; il ne transforme pas plusieurs questions en une transaction unique.

Des serveurs alternatifs peuvent malgré tout appliquer des politiques différentes. Le premier résultat valide l’emporte côté client, mais le protocole ne synchronise pas miraculeusement les annuaires, les règles ou l’état. Cette cohérence appartient à l’exploitant.

Accept n’était pas un ordre capable de créer le service

Le nom Access-Accept peut donner au paquet une autorité excessive. RFC 2865 précise pourtant que si le NAS ne peut fournir le service demandé dans la réponse, il doit traiter celle-ci comme un rejet.

Un Response Authenticator valide établit qu’un pair détenteur du secret a répondu à la requête encore pendante et que le paquet n’a pas été modifié selon la construction historique. Il ne crée ni VLAN, ni route, ni capacité physique. Il ne prouve pas davantage que l’utilisateur est bien celui qu’il prétend être indépendamment de la méthode d’authentification transportée, ni que le service a effectivement circulé.

L’autorité du paquet s’arrête donc à la frontière d’exécution locale.

Chaque proxy refaisait la preuve pour son voisin

Dans une chaîne RADIUS, un proxy vérifie la réponse du serveur distant avec leur secret, retire le dernier Proxy-State qu’il avait ajouté, restaure l’Identifier attendu par le client précédent et recalcule un Response Authenticator avec le secret de ce saut amont.

La preuve n’est pas une signature de bout en bout du serveur d’origine. Elle est locale à chaque voisinage. Proxy-State aide à ramener le paquet dans l’ordre de la chaîne et reste opaque pour celui qui ne l’a pas créé ; il ne confère aucun droit d’accès.

Une trace qui ne garde que « Identifier 37 — Accept » détruit précisément ce qui permettait de l’interpréter. Il faut conserver le saut, l’adresse et le port du client, le socket récepteur, la durée d’attente, une empreinte protégée du Request Authenticator, l’action du cache, le chemin de proxy et l’effet appliqué. Le secret partagé et les attributs d’identification sensibles, eux, ne doivent pas être journalisés en clair.

Les minuteries pouvaient synchroniser une panne

Le scénario des milliers de NAS n’est pas une fiction ajoutée après coup. RFC 5080 décrit les clients qui réessayent toutes les secondes sans recul de congestion et montre comment un redémarrage collectif peut submerger le serveur.

Son algorithme recommandé augmente progressivement le délai, ajoute une gigue et fixe des plafonds au délai, au nombre d’essais et à la durée totale. La gigue sert à désynchroniser les équipements ; elle n’a pas besoin d’être cryptographiquement forte. L’imprévisibilité du Request Authenticator répond à une menace différente. Mutualiser un faible générateur sous prétexte que les deux valeurs sont « aléatoires » confondrait stabilité et sécurité.

En surcharge, un serveur peut privilégier les requêtes qui portent un State valide afin d’achever les conversations déjà engagées. Un proxy peut traiter les réponses du serveur d’origine avant de nouvelles demandes. Cette préférence protège la progression et limite les retries ; elle ne crée pas une classe supérieure d’utilisateurs.

TLS a ensuite déplacé la responsabilité

RFC 6614 a placé RADIUS dans TLS sur TCP en 2012, tout en conservant les calculs historiques MD5 et le secret fixe radsec à l’intérieur du tunnel. Le transport protégeait la connexion sans supprimer l’ancien mécanisme de paquet.

En 2025, RFC 9765 définit RADIUS/1.1. Lorsque les deux pairs négocient explicitement ce profil par ALPN sur TLS 1.3 ou ultérieur, le secret partagé et les calculs MD5 disparaissent. L’ancien espace Authenticator devient un Token opaque de seize octets ; il reprend la corrélation demande-réponse et rend l’ancien Identifier inutile.

Cette évolution délimite l’article BTW déjà consacré à RADIUS/1.1. Elle ne change pas RADIUS/UDP et ne modernise pas automatiquement les autres sauts d’une chaîne de proxies. Elle confirme seulement une constante : même quand TLS porte l’authenticité, une transaction a encore besoin d’une valeur de corrélation assez large et liée à son contexte.

Une construction historique, pas une approbation de MD5

Le Response Authenticator classique ne doit pas être présenté comme une cryptographie à reproduire aujourd’hui. Il ne prouve ni la justesse de la politique, ni l’engagement d’un enregistrement comptable, ni l’honnêteté de tous les proxies, ni la livraison du service. Les RFC établissent les règles et leur évolution, pas la conformité d’un produit ou la part du parc encore concernée.

L’héritage utile de RADIUS est plus modeste. Un nom court peut fonctionner si sa portée, sa durée et les autres éléments de preuve restent visibles. Il devient trompeur lorsqu’un système d’audit conserve le numéro et oublie le contexte vivant qui lui donnait autorité.