Résumé

  • Le profil expérimental RADIUS/1.1 n'entre en vigueur que si une connexion TLS ou DTLS négocie radius/1.1 par ALPN ; RADIUS sur UDP et sur TCP reste hors de son périmètre.
  • Une migration n'est démontrée ni par un RFC ni par une case « compatible » : elle se prouve, saut par saut, par la version offerte, sélectionnée, imposée puis par la fermeture vérifiée de l'ancien chemin.

Reconnaître la dette au lieu de réécrire l'histoire

La phrase la plus importante du RFC 9765 n'est peut-être pas normative. Son introduction revient sur une décision prise par le groupe RADEXT : lorsque RADIUS a été placé dans TLS, le secret partagé et les traitements MD5 du paquet ont été conservés. TLS devait entourer le protocole sans obliger les logiciels à changer immédiatement leurs règles d'encodage et de validation. DeKok estime rétrospectivement que ce compromis était probablement mauvais et précise qu'il y avait participé.

Cette reconnaissance ne transforme pas l'ancien choix en absurdité. La compatibilité a permis d'introduire un transport protégé avec peu de modifications. Mais elle a créé une double enveloppe de sécurité : TLS protégeait déjà la liaison, tandis que RADIUS continuait à authentifier et masquer certains éléments avec un secret et MD5. À mesure que les environnements réglementés interdisaient les algorithmes considérés comme fragiles, la redondance devenait une contrainte de conformité et de maintenance.

Le parcours de DeKok explique pourquoi cette dette lui est familière. Sa fiche IETF situe sa rencontre avec RADIUS en 1997 et le lancement de FreeRADIUS en 1999. Le projet FreeRADIUS maintient un serveur de politiques et plusieurs composants d'intégration ; il confronte donc les décisions de standardisation aux configurations et aux erreurs réelles. Pour autant, le RFC 9765 est le produit d'un consensus IETF approuvé pour l'expérimentation, non une consigne privée du fondateur d'un logiciel.

Un transfert de responsabilité cryptographique

Le RFC 2865 avait construit la relation entre client et serveur autour d'un secret commun. Ce secret participait à l'authentification des échanges ; MD5 servait également dans le masquage de données comme le mot de passe utilisateur. Les RFC 6614 et 7360 ont ensuite défini le transport de RADIUS dans TLS et DTLS, sans retirer ces mécanismes internes au paquet.

RADIUS/1.1 opère autrement. Pendant la poignée de main TLS, le client propose des noms d'applications par ALPN et le serveur choisit un nom commun. Le profil ne s'applique que si radius/1.1 est effectivement sélectionné, avec TLS 1.3 ou une version ultérieure. Sur cette liaison, le secret RADIUS cesse d'être utilisé. L'espace des anciens Authenticator devient un jeton opaque de corrélation ; l'ancien identifiant perd sa fonction ; Message-Authenticator n'est plus envoyé ; les attributs auparavant brouillés avec MD5 sont transportés sous leur encodage ordinaire, car TLS assure confidentialité et intégrité.

Dire que la confiance « passe dans TLS » ne signifie pas qu'elle devient automatique. Il faut encore authentifier le pair, décider s'il est autorisé, protéger les clés, maintenir la bibliothèque TLS et observer le résultat de la négociation. Le profil supprime une mécanique redondante ; il rend donc la qualité de la couche de transport plus décisive.

La continuité dans la forme, la rupture dans l'état

Le paquet reste reconnaissable. Sa taille d'en-tête ne change pas ; Code et Length conservent leur sens ; les attributs qui n'utilisaient pas le brouillage MD5 gardent leur format ; les ports de RADIUS/TLS et RADIUS/DTLS sont réutilisés. Le RFC parle d'un profil de transport, pas d'un protocole totalement neuf.

Cependant, 1.0 et 1.1 ne peuvent pas être supposés équivalents sur la même connexion. Les champs réaffectés et l'absence de certains validateurs provoquent le rejet des requêtes ou des réponses si les pairs n'appliquent pas les mêmes règles. L'échec est plutôt sûr du point de vue cryptographique, mais il reste un incident de disponibilité. La sécurité d'une migration se juge aussi à la capacité d'expliquer cette panne et de revenir en arrière sans ouvrir une route incontrôlée.

Le même soin s'impose aux méthodes transportées. Des attributs CHAP ou MS-CHAP peuvent continuer à circuler comme des blocs opaques. RADIUS/1.1 retire MD5 de la protection et du brouillage du paquet sur cette liaison ; il ne modernise pas, par magie, toutes les méthodes d'authentification, tous les annuaires et tous les secrets situés derrière le serveur.

Chaque saut possède sa propre vérité

Dans une chaîne de mandataires RADIUS, une connexion peut avoir négocié 1.1 alors que la suivante utilise encore le RADIUS/TLS historique, UDP ou un autre transport autorisé. Le client d'accès et son premier serveur ne disposent pas nécessairement d'une vue sur le saut menant au serveur d'origine. Une mesure au bord du réseau ne vaut donc pas attestation de bout en bout.

ALPN donne une preuve locale particulièrement utile. Le RFC 7301 organise l'offre du client et le choix du serveur pendant la poignée de main TLS. Le RFC 9765 interdit de déduire 1.1 en l'absence du signal correspondant. Pour les logiciels capables des deux variantes, il recommande d'abord d'autoriser radius/1.0 et radius/1.1. Une fois les deux extrémités vérifiées et la sélection observée, l'administrateur peut imposer 1.1, surveiller la continuité puis refermer l'ancien choix. En cas de problème, le retour temporaire au double mode reste possible pendant l'enquête.

Cette prudence produit une tension. Elle réduit le risque de coupure immédiate, mais elle peut transformer une transition en état permanent. Un fournisseur peut annoncer « supporte 1.1 », l'acheteur peut valider la version, et le trafic peut continuer à choisir 1.0. La seule nomenclature fiable distingue :

  1. le logiciel qui sait parler 1.1 ;
  2. le client qui l'offre réellement ;
  3. la connexion qui le sélectionne ;
  4. la politique qui refuse désormais 1.0 ;
  5. le saut sur lequel les transports historiques sont fermés.

Le statut global doit rester incomplet tant qu'un saut nécessaire ne possède pas cette preuve.

L'apport de DeKok : rendre la correction vérifiable

L'histoire héroïque serait trompeuse. DeKok n'a pas inventé seul RADIUS, ne contrôle pas l'IETF et ne peut pas modifier les équipements des opérateurs. Les auteurs des RFC antérieurs, les membres de RADEXT, les développeurs de TLS, les fournisseurs, les équipes d'identité et les responsables de chaque mandataire détiennent une fraction du résultat. La page d'InkBridge présente DeKok comme créateur et responsable de FreeRADIUS ; elle établit une expérience, pas une souveraineté.

Son geste utile consiste ailleurs : nommer le compromis passé, conserver les éléments de paquet encore utiles, attribuer la sécurité à la couche qui l'assure déjà et donner à l'opérateur un état négocié observable. Le statut expérimental du RFC rappelle que cette proposition doit encore être confrontée aux implémentations et aux déploiements. La correction n'est achevée que lorsque le code tourne, que le bon profil est sélectionné et que l'ancien chemin peut être fermé sans surprise.

Sources