RadSec : Sécuriser le trafic d'authentification RADIUS avec TLS

RadSec : Sécuriser le trafic d'authentification RADIUS avec TLS. Un briefing technique Purple. Introduction et contexte. Bienvenue dans ce briefing technique Purple. Je vais vous présenter RadSec — RADIUS sur TLS — ce que c'est, pourquoi c'est crucial aujourd'hui et comment le déployer concrètement. Ce guide s'adresse directement aux architectes réseau et aux ingénieurs sécurité qui exploitent déjà un RADIUS cloud ou qui prévoient d'y migrer. Si vous utilisez encore des serveurs RADIUS sur site avec UDP et un secret partagé, ce briefing est fait pour vous. Plantons le décor. RADIUS est l'épine dorsale de l'authentification réseau depuis plus de trente ans. Il sous-tend le 802.1X, le WPA2-Enterprise, le WPA3-Enterprise et pratiquement tous les systèmes de Captive Portal en production aujourd'hui. Le protocole lui-même, défini dans la RFC 2865, a été conçu à une époque où Internet était bien différent. Le trafic d'authentification entre vos équipements NAS — vos points d'accès, commutateurs et contrôleurs — et votre serveur RADIUS transitait via UDP, sur le port 1812 pour l'authentification et le port 1813 pour l'accounting. Et ce trafic ? Il était en grande partie non chiffré. La seule protection résidait dans un secret partagé utilisé pour masquer l'attribut du mot de passe utilisateur, et même cette méthode présente des faiblesses bien documentées. Pendant des années, cela était acceptable car le trafic RADIUS restait sur des réseaux privés et contrôlés. Vos équipements NAS et votre serveur RADIUS se trouvaient sur le même réseau local (LAN) ou étaient connectés via un circuit MPLS dédié. La surface d'attaque était gérable. Mais le monde a changé. Les infrastructures cloud-natives, les déploiements sur des sites distribués, les overlays SD-WAN et la transition vers des services RADIUS cloud ont fondamentalement modifié le modèle de menace. Votre trafic d'authentification traverse désormais l'Internet public ou, au mieux, des infrastructures partagées que vous ne contrôlez pas entièrement. C'est là que RadSec intervient. Analyse technique approfondie. RadSec, formellement défini dans la RFC 6614, est l'équivalent de RADIUS sur TLS. Le concept est simple : au lieu d'envoyer des paquets RADIUS via UDP, vous les encapsulez dans une connexion TLS sur TCP. Résultat : tout le trafic d'authentification et d'accounting entre votre NAS et votre serveur RADIUS est entièrement chiffré, authentifié mutuellement et protégé en intégrité. La RFC 7360 étend cela au DTLS — Datagram TLS sur UDP — ce qui préserve certaines caractéristiques de latence du transport UDP d'origine tout en ajoutant le chiffrement. Pour la plupart des déploiements d'entreprise, le TLS sur TCP est le choix idéal. Le DTLS mérite d'être envisagé dans les environnements à haut débit et sensibles à la latence, comme les déploiements dans les grands stades.Parlons de la mécanique. RadSec fonctionne sur le port TCP 2083, qui est le port attribué par l'IANA pour ce protocole. Lorsqu'un équipement NAS initie une connexion RadSec, il ouvre une connexion TCP vers le serveur RADIUS sur le port 2083 et effectue un handshake TLS. Ce handshake est mutuel — le client (votre NAS) et le serveur présentent tous deux des certificats X.509. Le certificat du serveur est validé par rapport à une autorité de certification (CA) de confiance. Le certificat client identifie le NAS auprès du serveur RADIUS. Une fois la session TLS établie, les paquets RADIUS transitent à l'intérieur de ce tunnel chiffré exactement comme ils le feraient sur UDP, mais désormais avec une confidentialité, une intégrité et une protection contre le rejeu totales. Il s'agit d'une évolution majeure par rapport au RADIUS traditionnel, et ce de trois manières importantes. Premièrement, le transport s'effectue via TCP et non UDP. Cela signifie que vous bénéficiez d'une livraison fiable et ordonnée. Les paquets perdus sont retransmis automatiquement. Deuxièmement, l'authentification des deux points de terminaison repose sur des certificats et non sur un secret partagé. Cela élimine toute une catégorie d'attaques basées sur des secrets partagés faibles ou compromis. Troisièmement, l'intégralité du paquet RADIUS est chiffrée, et pas seulement l'attribut du mot de passe. Cela signifie que les noms d'utilisateur, les identifiants de session et tous les attributs RADIUS sont protégés en transit. Du point de vue de la gestion des certificats, vous avez besoin d'une PKI (infrastructure à clés publiques) pour émettre et gérer les certificats de votre serveur RADIUS et de vos équipements NAS. En pratique, la plupart des fournisseurs de RADIUS cloud, y compris l'infrastructure d'authentification cloud-native de Purple, gèrent pour vous la gestion des certificats côté serveur. Votre responsabilité consiste à provisionner les certificats clients sur vos équipements NAS. Pour les déploiements à grande échelle, cette tâche est généralement gérée via votre plateforme de gestion de réseau ou un système dédié de gestion des certificats. Les certificats doivent utiliser au minimum RSA 2048 bits ou ECDSA P-256, avec une période de validité qui équilibre la charge opérationnelle et l'hygiène de sécurité — douze mois constituant un choix par défaut raisonnable. Comparons maintenant cette méthode à l'approche alternative que de nombreuses organisations utilisent aujourd'hui : les tunnels IPsec ou les overlays VPN pour protéger le trafic RADIUS. L'IPsec est une approche tout à fait valable, mais elle opère à une couche différente. Vous chiffrez l'ensemble du trafic entre deux points de terminaison, ce qui ajoute de la complexité — vous devez gérer l'IKE, les clés pré-partagées ou les certificats pour le tunnel lui-même, ainsi que la charge opérationnelle liée au maintien de l'état du tunnel sur potentiellement des centaines de sites. RadSec est plus ciblé. Il chiffre spécifiquement le trafic du protocole RADIUS, fonctionne au niveau de la couche applicative et s'intègre directement à votre infrastructure RADIUS. Pour les déploiements RADIUS cloud où vous connectez de nombreux équipements NAS sur des sites distribués à un serveur cloud centralisé, RadSec est architecturalement plus propre et opérationnellement plus simple. Laissez-moi vous expliquer à quoi ressemble un déploiement multi-site en pratique. Vous disposez d'un serveur RADIUS dans le cloud — disons la plateforme de Purple — avec un certificat TLS valide provenant d'une autorité de certification (CA) de confiance. Vous avez trois types de sites : un hôtel, un magasin de détail et un centre de conférence. Chacun dispose d'équipements NAS — points d'accès, commutateurs ou contrôleurs LAN sans fil. Chaque équipement NAS doit être configuré avec l'adresse du serveur RadSec, le port 2083 et un certificat client. Le NAS initialise la connexion TLS, la double authentification (mutual handshake) s'effectue et, à partir de ce moment, tout le trafic d'authentification 802.1X pour les invités et le personnel de ce site est acheminé de manière chiffrée vers le serveur RADIUS dans le cloud. Si la connexion TLS s'interrompt — par exemple, en raison d'une coupure réseau — le NAS la rétablit automatiquement. Ce modèle de connexion persistante est en réalité plus efficace que l'UDP pour les déploiements à fort volume, car vous évitez la surcharge liée au traitement par paquet. Du côté du pare-feu, vous devez autoriser le trafic TCP sortant sur le port 2083 depuis votre réseau de gestion NAS vers l'adresse IP ou le FQDN de votre serveur RADIUS. Si vous appliquez une politique de filtrage de sortie stricte, vous devrez également autoriser le trafic de retour. C'est bien plus simple que de gérer des règles de pare-feu IPsec, qui nécessitent souvent des exceptions pour le protocole ESP et l'IKE sur les ports UDP 500 et 4500. Recommandations de mise en œuvre et pièges à éviter. Voyons maintenant ce qui pose réellement problème lors des déploiements RadSec, car il existe des modes de défaillance récurrents que je constate au sein des organisations. Le premier problème, et le plus courant, concerne les échecs de validation de la chaîne de certificats. Votre équipement NAS doit faire confiance à la CA qui a signé le certificat du serveur RADIUS. Si vous utilisez un fournisseur de RADIUS dans le cloud avec un certificat provenant d'une CA publique reconnue — DigiCert, Let's Encrypt, Sectigo — la plupart des équipements NAS modernes lui feront confiance par défaut. Mais si vous utilisez une CA interne, vous devez déployer le certificat de la CA sur chaque équipement NAS. Ce point est souvent négligé lors du déploiement initial et se manifeste par des échecs de handshake TLS qui ressemblent à des problèmes de connectivité. Le second piège est l'expiration des certificats. Contrairement aux secrets partagés, qui n'expirent pas, les certificats ont une durée de validité définie. Si le certificat de votre serveur RADIUS expire, tous les équipements NAS de votre parc échoueront simultanément à s'authentifier. Vous devez mettre en place une gestion du cycle de vie des certificats — avec un renouvellement automatisé dans la mesure du possible, ainsi qu'un suivi et des alertes bien avant l'expiration. Un préavis de quatre-vingt-dix jours est le minimum ; trente jours est préférable. Le troisième problème concerne la compatibilité des équipements NAS. Tous les équipements NAS ne prennent pas en charge RadSec de manière native. Les anciennes versions de Cisco IOS, certains contrôleurs Aruba hérités et certains points d'accès grand public ne supportent pas RadSec. Avant de vous lancer dans un déploiement RadSec, auditez votre parc de NAS pour en vérifier la compatibilité. Cisco IOS-XE 16.x et versions ultérieures, Aruba AOS-CX, Ruckus SmartZone et la série Juniper EX offrent tous un support solide de RadSec. Pour les équipements qui ne supportent pas RadSec nativement, un proxy RadSec — une option open-source comme radsecproxy — peut combler le manque, en acceptant le protocole UDP RADIUS des équipements hérités et en le transmettant via TLS au serveur RADIUS cloud. La quatrième considération concerne la persistance de la connexion et les keepalives. RadSec utilise des connexions TCP persistantes, mais les pare-feu et les équipements NAT dotés de politiques de temporisation agressives peuvent interrompre silencieusement les connexions inactives. Configurez des keepalives TCP sur vos connexions RadSec — généralement, un intervalle de keepalive de soixante secondes suffit pour éviter une interruption prématurée de la connexion. La plupart des implémentations de serveurs RADIUS et d'équipements NAS prennent en charge cette configuration. Pour Cisco IOS-XE, la configuration RadSec ressemble à ceci. Vous définissez un serveur RADIUS avec l'adresse de votre point de terminaison RADIUS cloud, spécifiez TLS comme transport, référencez votre trustpoint — qui est le magasin de certificats sur l'équipement — et définissez le port de destination sur 2083. Vous référencez ensuite ce serveur dans la configuration de votre groupe de serveurs AAA. Les spécificités varient selon la version de la plateforme, mais la structure logique reste cohérente d'un fournisseur à l'autre. Pour les contrôleurs Aruba fonctionnant sous AOS, vous configurez le serveur RADIUS avec l'option RadSec activée, spécifiez le certificat de l'autorité de certification (CA) pour la validation du serveur et, en option, configurez un certificat client pour le TLS mutuel. L'implémentation d'Aruba est mature et bien documentée. Questions et réponses rapides. Permettez-moi de passer en revue les questions que l'on me pose le plus souvent sur RadSec. RadSec ajoute-t-il de la latence ? Le handshake TLS ajoute une légère surcharge lors de l'établissement initial de la connexion — généralement moins de 100 millisecondes. Une fois la connexion établie, la surcharge par paquet est négligeable. Pour l'authentification 802.1X, où le handshake n'a lieu qu'une fois par session, cela ne représente pas un problème significatif. Puis-je exécuter RadSec en parallèle avec le RADIUS UDP traditionnel ? Oui. La plupart des serveurs RADIUS prennent en charge les deux simultanément. Lors d'une migration, vous pouvez exécuter RadSec pour les sites qui le prennent en charge et revenir à l'UDP pour les sites hérités. C'est l'approche de migration recommandée. RadSec est-il requis pour la conformité PCI DSS ? La version 4.0 de PCI DSS exige que le trafic d'authentification soit protégé en transit. RadSec est l'un des moyens les plus directs de répondre à cette exigence pour l'authentification basée sur RADIUS. Si vous traitez des paiements par carte sur un réseau qui utilise l'authentification RADIUS, RadSec devrait figurer sur votre feuille de route de conformité. RadSec fonctionne-t-il avec l'EAP ? Oui. L'EAP — Extensible Authentication Protocol — est encapsulé au sein de RADIUS, de sorte que l'EAP-TLS, le PEAP et l'EAP-TTLS fonctionnent tous de manière transparente sur RadSec. L'échange EAP lui-même n'est pas affecté. Qu'en est-il de la comptabilisation RADIUS (accounting) ? La RFC 6614 couvre à la fois le trafic d'authentification et de comptabilisation. Vos données de comptabilisation — enregistrements de début, de fin et de mise à jour intermédiaire de session — sont également chiffrées sur la même connexion TLS sur le port 2083. Résumé et prochaines étapes. Pour résumer : RadSec est la couche de transport idéale pour RADIUS dans tout déploiement où le trafic d'authentification traverse une infrastructure que vous ne contrôlez pas entièrement. Cela concerne le RADIUS cloud, les déploiements multi-sites, les environnements SD-WAN et tout scénario où le trafic RADIUS traverse l'internet public ou l'infrastructure d'un opérateur partagé. Les actions clés pour votre équipe sont : premièrement, auditer votre parc de NAS pour vérifier la compatibilité RadSec et identifier les appareils qui nécessiteront un proxy. Deuxièmement, solliciter votre fournisseur de RADIUS cloud — ou évaluer les fournisseurs qui prennent en charge RadSec nativement — et comprendre leur approche de la gestion des certificats. Troisièmement, établir un processus de gestion du cycle de vie des certificats avant la mise en production. Quatrièmement, mettre à jour vos règles de pare-feu pour autoriser le port TCP 2083 en sortie depuis votre réseau de gestion NAS. Cinquièmement, tester votre configuration RadSec dans un environnement de pré-production avant le déploiement en production, en accordant une attention particulière à la validation de la chaîne de certificats et à la persistance de la connexion sous charge. Pour les organisations qui exploitent la plateforme de Purple pour le WiFi invité et l'authentification sur des sites distribués, RadSec est le transport recommandé pour la connectivité RADIUS cloud. Il s'aligne sur l'architecture cloud-native de Purple et garantit que les données d'authentification circulant entre vos sites et la plateforme sont entièrement protégées — ce qui est essentiel tant pour votre posture de sécurité que pour vos obligations de conformité au titre du GDPR et de la norme PCI DSS. Si vous planifiez un déploiement ou souhaitez discuter de votre architecture spécifique, l'équipe Purple est votre point de départ idéal. Ceci était un briefing technique de Purple sur RadSec. Merci pour votre écoute.