Sécurité de transport dans RADIUS vs. RadSec
Lors du déploiement d'une authentification sécurisée utilisant le Extensible Authentication Protocol (EAP), le choix du protocole de transport - RADIUS sur UDP vs. RADIUS sur TLS (RadSec) - joue un rôle crucial pour déterminer la sécurité de la transmission des métadonnées et des éléments de protocole à travers le réseau.
Tant RADIUS que RadSec peuvent transporter des messages EAP, y compris ceux utilisés dans des méthodes courantes comme EAP-TLS, PEAP et EAP-TTLS. Alors que le fonctionnement interne de la méthode EAP reste le même, le protocole de transport influence la visibilité, l'intégrité, la confidentialité des métadonnées et le comportement opérationnel.
Ce document compare comment RADIUS et RadSec affectent le transport EAP - en mettant l'accent sur le chiffrement, l'utilisation du secret partagé, l'exposition des attributs, les implications pour la journalisation et les considérations de déploiement.
Sécurité de transport : différences fondamentales
Les méthodes EAP telles que EAP-TLS, PEAP et EAP-TTLS fournissent des mécanismes d'authentification entre les clients (supplicants) et les serveurs d'authentification. Cependant, ces méthodes n'encryptent pas intrinsèquement le transport des métadonnées entre nœuds intermédiaires. Ce rôle revient au protocole de couche transport :
RADIUS (UDP) transmet les messages EAP et les attributs RADIUS en clair.
RadSec (TLS) chiffre l'intégralité du paquet RADIUS, protégeant tous les attributs et en-têtes de protocole pendant le transit.
Le tableau ci‑dessous résume ces différences qui affectent la confidentialité des attributs tels que l'identité externe, l'IP du NAS, l'identifiant de station appellante, et d'autres. Alors que les méthodes EAP peuvent chiffrer les informations d'identification utilisateur (par ex. certificats ou mots de passe), les métadonnées restent exposées sur un RADIUS standard à moins que RadSec ne soit utilisé.
Protocole de couche transport
UDP (typiquement)
TLS sur TCP
Chiffrement
Pas de chiffrement du transport
Chiffrement complet du transport
Port par défaut*
UDP 1812
TCP 2083
Remarques
Sans état ; peut être filtré par des pare‑feu.
Avec état ; établit des tunnels sécurisés.
*Bien que ces ports soient les standards reconnus, certains déploiements peuvent les personnaliser pour des raisons de politique locale ou d'infrastructure.
Le rôle du secret partagé RADIUS dans les deux protocoles
Le secret partagé RADIUS est utilisé pour l'intégrité des paquets et les comportements de chiffrement hérités. Cela s'applique que le transport soit RADIUS standard ou RadSec.
Principales utilisations :
AVP Message-Authenticator: Garantit l'intégrité du paquet en utilisant HMAC‑MD5.
AVP User-Password (méthodes héritées): Chiffre les identifiants en utilisant le secret partagé.
Compatibilité RadSec: Même avec RadSec, le secret partagé est conservé pour la compatibilité avec la sémantique RADIUS et les systèmes intermédiaires.
Remarque : Le secret partagé n'est jamais transmis sur le réseau - il est utilisé localement pour les opérations HMAC et la validation des AVP.
Visibilité des éléments de données : RADIUS vs. RadSec
Ce tableau compare les principaux éléments de données lors de l'utilisation d'EAP‑TLS sur RADIUS (UDP) et RadSec (TLS), regroupés par risque de visibilité pendant la transmission.
Paquet RADIUS externe
Texte clair (sur UDP ou TCP).
Chiffré (sur TLS).
Comprend à la fois les en‑têtes et les AVP. Par ex., paquet visible dans Wireshark ou tcpdump.
Identité utilisateur (identité externe)
Envoyée en clair.
Chiffré (sur TLS).
[email protected] utilisée pour le routage de domaine (realm).
AVP RADIUS (attributs)
Certains en clair (par ex., NAS‑IP, User‑Name).
Entièrement chiffrés dans TLS.
NAS-IP-Address,
Calling-Station-Id
En‑têtes RADIUS
Texte clair
Chiffrés dans TLS
Code (Access-Request), Identifiant,
Longueur,
Authentificateur
Secret partagé RADIUS
Non transmis (utilisé en interne)
Non transmis (utilisé en interne)
Utilisé pour le chiffrement des AVP et Message-Authenticator validation.
Charge utile EAP
Chiffrée entre le client et le serveur
Chiffrés dans TLS
Inclut la poignée de main TLS, la validation des certificats, etc.
Identifiants utilisateur (certificats/clés)
Chiffrés dans le tunnel EAP
Chiffrés dans le tunnel EAP + TLS
S'applique aux méthodes basées sur les certificats (EAP‑TLS) et sur les mots de passe (PEAP). Certificat client avec sujet CN=jsmith, OU=IT
Mot de passe (par ex., PEAP ou MSCHAPv2)
Chiffré dans la méthode tunnellisée (par ex., PEAP)
Chiffré dans le tunnel EAP + TLS
S'applique aux méthodes basées sur les mots de passe.
Confidentialité de l'identité : identité externe vs. interne
Les méthodes EAP qui utilisent le tunneling ou les certificats (par ex., PEAP, EAP‑TTLS, EAP‑TLS) prennent en charge les identités externes et internes :
Identité externe: Envoyée en clair dans l'AVP User‑Name pour faciliter le routage de domaine. Souvent anonymisée (par ex.,
[email protected]).Identité interne: Transportée de manière sécurisée à l'intérieur du tunnel EAP chiffré (par ex., nom d'utilisateur/mot de passe, CN du certificat).
Comportement selon le transport :
Dans RADIUS, l'identité externe est envoyée en clair et est visible sur le réseau.
Dans RadSec, l'intégralité du paquet, y compris l'identité externe, est chiffrée.
Les préoccupations de confidentialité liées à l'envoi de l'identité externe en clair avec RADIUS peuvent être atténuées en configurant la confidentialité d'identité ou en exploitant des certificats d'appareil qui ne contiennent pas de données à caractère personnel dans l'attribut common name.
Remarque: Certaines plateformes, comme le client EAP natif de Windows, peuvent ne pas prendre en charge la confidentialité d'identité par défaut dans des méthodes comme EAP‑TLS, exposant potentiellement la véritable identité dans la couche externe.
Identité externe
Le tableau ci‑dessous fournit un aperçu des valeurs typiques que diverses plates‑formes OS renseignent pour l'identité externe.
Nom d'utilisateur/Mot de passe
Typiquement :
- UPN
- Adresse e‑mail
Windows (peut être anonymisé)
iOS, iPadOS, macOS (peut être anonymisé)
Android (peut être anonymisé)
Certificat d'appareil
Propriété common name (CN) du nom du sujet du certificat client.
Typiquement :
- DeviceName
- Intune Device ID (GUID)
- AAD Device ID (GUID)
Windows (ne peut pas être anonymisé) *
iOS, iPadOS, macOS (peut être anonymisé)
Android (peut être anonymisé)
Certificat utilisateur
Propriété common name (CN) du nom du sujet du certificat client.
Typiquement :
- UPN
- Adresse e‑mail
Windows (ne peut pas être anonymisé)*
iOS, iPadOS, macOS (peut être anonymisé)
Android (peut être anonymisé)
*Le client EAP utilisé dans Windows ne prend pas en charge la confidentialité d'identité pour EAP‑TLS.
Journalisation et considérations de déploiement
RadSec (TLS)
RadSec chiffre l'intégralité du paquet RADIUS, ce qui empêche l'écoute passive. Cela déplace la journalisation et le diagnostic de l'inspection réseau vers le niveau application ou le serveur RADIUS, car ce sont les points de terminaison qui terminent la session TLS. Les organisations passant à RadSec devraient évaluer les flux de surveillance pour tenir compte du trafic chiffré.
RADIUS (UDP)
La transmission en clair des attributs (User‑Name, NAS‑IP‑Address, etc.) simplifie le dépannage et les diagnostics en direct, permettant la capture de paquets avec un minimum d'outillage. Cependant, cela augmente le risque d'exposition des métadonnées sensibles pendant le transit.
Support réseau
La prise en charge de RadSec n'est pas universelle sur tous les périphériques et infrastructures réseau. De nombreux commutateurs réseau, points d'accès sans fil et pare‑feu ne prennent en charge que le RADIUS traditionnel. Dans les environnements mixtes, un proxy RadSec‑vers‑RADIUS peut être nécessaire pour faire le pont entre composants modernes et hérités. Des évaluations d'infrastructure sont recommandées avant de déployer RadSec en production.
Conclusion et points clés
Transporter les méthodes EAP sur RADIUS ou RadSec offre la même protection forte de bout en bout pour les identifiants utilisateur mais diffère significativement quant à la manière dont les métadonnées et les éléments de protocole sont exposés pendant le transit.
Protection EAP de bout en bout: EAP fournit une protection solide des identifiants utilisateur à la fois sur RADIUS et RadSec.
Différence principale: RADIUS utilise UDP et n'encrypte pas le paquet RADIUS lui‑même, tandis que RadSec encapsule l'intégralité du paquet dans TLS, masquant tous les attributs et en‑têtes sur le réseau.
Confidentialité des métadonnées: RadSec chiffre toutes les métadonnées (en‑têtes, attributs et identité externe), empêchant l'exposition au niveau réseau.
Secret partagé: Le secret partagé n'est jamais transmis. Il n'est utilisé que localement pour calculer les contrôles d'intégrité des messages et vérifier l'authenticité.
Compromis: RadSec offre une confidentialité renforcée mais complique les diagnostics en raison du chiffrement, et sa prise en charge n'est pas universelle sur tous les équipements réseau.
Normes et références RFC
Pour plus de détails sur les protocoles et spécifications :
EAP (Extensible Authentication Protocol) : RFC 3748
EAP‑TLS : RFC 5216
RADIUS (Remote Authentication Dial‑In User Service) : RFC 2865
RadSec (RADIUS over TLS) : RFC 6614
Mis à jour
Ce contenu vous a-t-il été utile ?