> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/fr/autre/faqs/security-and-privacy/securite-du-transport-dans-radius-par-rapport-a-radsec.md). # Sécurité du transport dans RADIUS par rapport à RadSec Lors du déploiement d’une authentification sécurisée utilisant le protocole d’authentification extensible (EAP), le choix du protocole de transport — RADIUS sur UDP contre RADIUS sur TLS (RadSec) — joue un rôle essentiel pour déterminer avec quelle sécurité les métadonnées et les éléments du protocole sont transmis 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 inchangé, 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 mettant l’accent sur le chiffrement, l’usage 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 transport : * RADIUS (UDP) transmet les messages EAP et les attributs RADIUS en texte clair. * RadSec (TLS) chiffre l’intégralité du paquet RADIUS, sécurisant tous les attributs et en-têtes du 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 du NAS, l’ID de la station appelante, et bien plus. Bien que les méthodes EAP puissent chiffrer les identifiants utilisateur (par ex., certificats ou mots de passe), les métadonnées restent exposées avec RADIUS standard, sauf si RadSec est utilisé. | Protocole | RADIUS | RadSec | | ----------------------------- | ---------------------------------------------- | ------------------------------------------ | | Protocole de couche transport | UDP (généralement) | 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 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 :** * **AVP Message-Authenticator**: Garantit l’intégrité du paquet à l’aide de HMAC-MD5. * **AVP User-Password (méthodes héritées)**: Chiffre les identifiants à l’aide du secret partagé. * **Compatibilité RadSec**: Même avec 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 contre 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 selon le risque de visibilité pendant la transmission.
Élément de donnéesRADIUS (UDP)RadSec (RADIUS sur TLS)Exemple / Remarques
Paquet RADIUS externeTexte 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 texte clair.Chiffré (sur TLS).anonymous@organisation.com utilisé pour le routage de domaine.
AVP RADIUS (attributs)Certains en texte clair (par ex., NAS-IP, User-Name).Entièrement chiffré dans TLS.

NAS-IP-Address,

Calling-Station-Id

En-têtes RADIUSTexte clairChiffré 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é dans TLSInclut la négociation TLS, la validation du certificat, etc.
Identifiants utilisateur (certificats/clés)Chiffrés dans le tunnel EAPChiffrés dans le tunnel EAP + TLSS’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 tunnelisée (par ex., PEAP)Chiffré dans le tunnel EAP + TLSS’applique aux méthodes basées sur les mots de passe.
*** ### Confidentialité de l’identité : identité externe contre identité interne Les méthodes EAP qui utilisent le tunneling ou des certificats (par ex., PEAP, EAP-TTLS, EAP-TLS) prennent en charge les identités externe et interne : * **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 le transport : * Dans **RADIUS**, l’identité externe est envoyée en texte clair et est visible sur le réseau. * Dans **RadSec**, l’ensemble du paquet, y compris l’identité externe, est chiffré. Les préoccupations de confidentialité liées à la transmission en texte clair de l’identité externe avec RADIUS peuvent être atténuées en configurant la confidentialité de l’identité ou en s’appuyant sur des certificats d’appareil qui ne contiennent pas de données personnelles identifiables (PII) dans l’attribut de nom commun {% 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, ce qui peut exposer la véritable identité dans la couche externe. {% endhint %} #### Identité externe Le tableau ci-dessous donne un aperçu des valeurs typiques avec lesquelles différentes plateformes OS renseignent l’identité externe. | Type d’identifiant | Identité externe | Système d’exploitation applicable | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Nom d'utilisateur/mot de passe |



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

| | | Certificat d’appareil |

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

Généralement :
- DeviceName
- ID d’appareil Intune (GUID)
- ID d’appareil AAD (GUID)

|

| | Certificat utilisateur |

Propriété du nom commun (CN) du sujet du certificat 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 l’application ou le serveur RADIUS, car ce sont les points de terminaison qui mettent fin à la session TLS. Les organisations qui migrent vers RadSec doivent évaluer leurs workflows de supervision afin de prendre en charge le trafic chiffré. #### RADIUS (UDP) La transmission en texte 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 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 l’ensemble des équipements 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 des environnements mixtes, un proxy RadSec-vers-RADIUS peut être nécessaire pour faire le pont entre les 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 Transporter des méthodes EAP via RADIUS ou via RadSec offre la même protection de bout en bout robuste pour les identifiants utilisateur, 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 fournit une protection solide des identifiants utilisateur sur RADIUS et RadSec. * **Différence principale**: RADIUS utilise UDP et ne chiffre 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 toute exposition au niveau du 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 son support n’est pas universel sur tous les équipements réseau. *** ### Normes et références RFC Pour plus de détails sur les protocoles et les spécifications : * EAP (protocole d’authentification extensible) : RFC 3748 * EAP-TLS : RFC 5216 * RADIUS (Remote Authentication Dial-In User Service) : RFC 2865 * RadSec (RADIUS sur TLS) : RFC 6614 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/fr/autre/faqs/security-and-privacy/securite-du-transport-dans-radius-par-rapport-a-radsec.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.