# Sécurité du transport dans RADIUS vs. RadSec Lors du déploiement d’une authentification sécurisée à l’aide du 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 à quel point les métadonnées et les éléments du protocole sont transmis de manière sécurisée sur le réseau. RADIUS et RadSec peuvent tous deux transporter des messages EAP, y compris ceux utilisés dans des méthodes courantes comme EAP-TLS, PEAP et EAP-TTLS. Bien que le fonctionnement interne de la méthode EAP reste le même, le protocole de transport influe sur la visibilité, l’intégrité, la confidentialité des métadonnées et le comportement opérationnel. Ce document compare l’impact de RADIUS et de RadSec sur le transport EAP — en se concentrant 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é du 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 ne chiffrent pas intrinsèquement le transport des métadonnées entre les nœuds intermédiaires. Ce rôle revient au protocole de la couche de transport : * RADIUS (UDP) transmet les messages EAP et les attributs RADIUS en clair. * RadSec (TLS) chiffre l’intégralité du paquet RADIUS, sécurisant ainsi 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é d’attributs tels que l’identité externe, l’adresse IP NAS, l’ID de station appelante, et plus encore. Bien que les méthodes EAP puissent chiffrer les informations d’identification de l’utilisateur (par exemple, certificats ou mots de passe), les métadonnées restent exposées via RADIUS standard, sauf si RadSec est utilisé. | Protocole | RADIUS | RadSec | | ----------------------------- | ---------------------------------------------- | ------------------------------------------ | | Protocole de couche transport | UDP (généralement) | TLS sur TCP | | Chiffrement | Aucun chiffrement du transport | Chiffrement complet du transport | | Port par défaut\* | UDP 1812 | TCP 2083 | | Remarques | Sans état ; peut être filtré par les pare-feu. | Avec état ; établit des tunnels sécurisés. | \*Bien que ces ports soient les normes reconnues, 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. **Principaux usages :** * **Message-Authenticator AVP**: Assure l’intégrité du paquet à l’aide de HMAC-MD5. * **User-Password AVP (méthodes héritées)**: Chiffre les informations d’identification à l’aide du secret partagé. * **Compatibilité RadSec**: Même dans RadSec, le secret partagé est conservé pour assurer la compatibilité avec la sémantique RADIUS et les systèmes intermédiaires. {% hint style="info" %} **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. {% endhint %} *** ### Visibilité des éléments de données : RADIUS vs. RadSec Ce tableau compare les principaux éléments de données lors de l’utilisation de EAP-TLS sur RADIUS (UDP) et RadSec (TLS), regroupés selon le risque de visibilité pendant la transmission.
Élément de donnéesRADIUS (UDP)RadSec (RADIUS sur TLS)Exemple / Remarques
Paquet RADIUS externeEn clair (sur UDP ou TCP).Chiffré (sur TLS).Inclut à la fois les en-têtes et les AVP. Par ex., paquet visible dans Wireshark ou tcpdump.
Identité de l’utilisateur (identité externe)Envoyée en clair.Chiffré (sur TLS).anonymous@organisation.com utilisée pour le routage de domaine.
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 RADIUSEn clairChiffrés dans TLS

Code (Access-Request), Identifiant,

Longueur,

Authentificateur

Secret partagé RADIUSNon transmis (utilisé en interne)Non transmis (utilisé en interne)Utilisé pour le chiffrement des AVP et la validation de Message-Authenticator .
Charge utile EAP Chiffrée entre le client et le serveurChiffrés dans TLSInclut la négociation TLS, la validation du certificat, etc.
Informations d’identification de l’utilisateur (certificats/clé)Chiffrées dans le tunnel EAPChiffrées dans le tunnel EAP + TLSS’applique aux méthodes basées sur des certificats (EAP-TLS) et sur des 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 tunnelisée (par ex., PEAP)Chiffré dans le tunnel EAP + TLSS’applique aux méthodes basées sur un mot de passe.
*** ### Confidentialité de l’identité : identité externe vs. identité interne Les méthodes EAP qui utilisent le tunneling ou des certificats (par ex., PEAP, EAP-TTLS, EAP-TLS) prennent en charge des 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., `anonymous@domain.com`). * **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 les transports : * 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 à la transmission en clair de l’identité externe avec RADIUS peuvent être atténuées en configurant la confidentialité de l’identité ou en exploitant des certificats d’appareil qui ne contiennent pas de données PII dans l’attribut common name {% hint style="info" %} **Remarque**: Certaines plateformes, comme le client EAP natif de Windows, peuvent ne pas prendre en charge la confidentialité de l’identité par défaut dans des méthodes comme EAP-TLS, exposant potentiellement la véritable identité dans la couche externe. {% endhint %} #### Identité externe Le tableau ci-dessous fournit un aperçu des valeurs typiques que différentes plateformes OS renseignent pour l’identité externe. | Type d’informations d’identification | Identité externe | OS applicable | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Nom d’utilisateur/Mot de passe |



Généralement :
- UPN
- Adresse e-mail

| | | Certificat d’appareil |

Propriété common name (CN) du nom du sujet du certificat du client.

Généralement :
- Nom de l’appareil
- ID de l’appareil Intune (GUID)
- ID de l’appareil AAD (GUID)

|

| | Certificat utilisateur |

Propriété common name (CN) du nom du sujet du certificat du client.

Généralement :
- UPN
- Adresse e-mail

|

| \*Le client EAP utilisé dans Windows ne prend pas en charge la confidentialité de l’identité pour EAP-TLS. *** ### Considérations de journalisation et 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 de l’application ou du serveur RADIUS, car ce sont les points de terminaison qui mettent fin à la session TLS. Les organisations qui migrent vers RadSec devraient évaluer leurs flux de supervision afin de prendre en charge le 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 une capture de paquets avec un outillage minimal. Cependant, cela augmente le risque d’exposition des métadonnées sensibles pendant le transit. #### Prise en charge réseau La prise en charge de RadSec n’est pas universelle sur tous les équipements et infrastructures réseau. De nombreux commutateurs réseau, points d’accès sans fil et pare-feu ne prennent en charge que RADIUS traditionnel. Dans des environnements mixtes, un proxy RadSec-vers-RADIUS peut être nécessaire pour faire le lien entre composants modernes et hérités. Il est recommandé d’évaluer l’infrastructure avant de déployer RadSec en production. *** ### Conclusion et points clés Le transport des méthodes EAP via RADIUS ou via RadSec offre la même protection robuste de bout en bout pour les informations d’identification des utilisateurs, mais diffère considérablement dans la manière dont les métadonnées et les éléments du protocole sont exposés pendant le transit. * **Protection EAP de bout en bout**: EAP offre une protection robuste des informations d’identification des utilisateurs via RADIUS et RadSec. * **Différence principale**: RADIUS utilise UDP et ne chiffre pas lui-même le paquet RADIUS, 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 toute exposition au niveau réseau. * **Secret partagé**: Le secret partagé n’est jamais transmis. Il est utilisé uniquement 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 le diagnostic en raison du chiffrement, et sa prise en charge n’est pas universelle sur l’ensemble des équipements réseau. *** ### Normes et références RFC Pour plus de détails sur les protocoles et les spécifications : * EAP (Extensible Authentication Protocol) : RFC 3748 * EAP-TLS : RFC 5216 * RADIUS (Remote Authentication Dial-In User Service) : RFC 2865 * RadSec (RADIUS sur TLS) : RFC 6614 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/fr/autre/faqs/security-and-privacy/securite-du-transport-dans-radius-vs.-radsec.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.