Après une (longue) absence et un article au final mis de côté, je viens aujourd’hui vous parler des protocoles que vous utilisez indirectement tous les jours et qui permettent à vos fournisseurs d’effectuer un contrôle d’accès et une mesure d’utilisation des services qu’ils vous fournissent. Je parle évidemment du protocole RADIUS. Ce protocole étant souvent associé au protocole EAP (pour l’authentification des clients sur 802.1x/WPA-Enterprise), je vais également aborder ce dernier. MAIS ce n’est toujours pas terminé ! Avec ces 2 protocoles viennent également d’autres mécanismes qu’il faut aussi définir: EAP-TTLS, PAP, CHAP, PEAP, PWD, etc. On va donc aussi définir ces termes, leurs utilités, leurs faiblesses, etc.

Alors déjà, pourquoi je viens parler de tout cela aujourd’hui ? En fait, j’ai avais besoin d’un serveur RADIUS accolé à mon LDAP pour 3 raisons:

• Avoir la possibilité d’exploiter l’authentification par 802.1x sur mes bornes Wi-Fi (avec possible utilisation des VLAN dynamiques),
• Baser l’authentification de mes VPN (et d’autres services réseau) sur le LDAP à travers RADIUS,
• *L’expérience*.

Cet ensemble de protocoles n’est pas facile à comprendre, et encore moins à maîtriser. Il m’a fallu du temps pour au moins réussir à les comprendre, ainsi que les interactions entre elles, ses forces et défauts, etc. Mais il m’aura fallu encore plus de temps pour réussir à dompter la principale implémentation d’un serveur RADIUS: FreeRADIUS. C’est pourquoi je vais également tenter d’en expliquer le fonctionnement. Je vais aussi traiter de l’authentification avec EAP/RADIUS, car on le trouve beaucoup pour un usage type bornes Wi-Fi. Mes explications pourront aussi s’appliquer à d’autres services, tels que l’authentification sur des équipements réseau, le PPP, etc.

Comme la dernière fois, j’explique les choses comme je les ai comprises. Il est possible qu’il y ait des incohérences, ou bien même des erreurs. Ne pas hésiter à me corriger si besoin.

J’ai décidé de diviser le sujet en 4 parties sur 4 posts (dont celui-ci). Les parties sont les suivantes:

• Présentation générale du protocole RADIUS, ainsi que son fonctionnement. Qu’est-il possible de faire avec, et comment ? (ce post)
• Comment passer un mot de passe sur le réseau: PAP/CHAP/MS-CHAP et les autres, leurs avantages et inconvénients,
• Le fonctionnement du 802.1x/EAP, et ses interactions avec RADIUS,
• Le serveur FreeRADIUS.

---

Et voici la toute première partie du sujet !

Le protocole RADIUS

Qu’est-ce que c’est

Pour commencer, une petite introduction sur le protocole. Wikipédia nous dit que RADIUS est considéré comme un protocole AAA. RADIUS permet d’identifier des utilisateurs, de les autoriser à accéder à des services, et de comptabiliser ses usages. C’est donc un protocole qui permet d’accéder le plus souvent à des services réseau (Wi-FI, xDSL, VPN, etc.) et à des appareils ne disposant pas d’un système de gestion des utilisateurs très poussé (switches, routeurs, etc.).

Concrètement, RADIUS permet d’établir un « pont » entre des équipements ayant un besoin d’authentification des utilisateurs et des équipements fournissant les informations permettant d’authentifier un utilisateur (LDAP et SQL le plus souvent). De plus, RADIUS est un protocole normalisé, il a été défini pour la première fois dans les RFC2138 et 2139. De ce fait, il est possible d’utiliser ce même protocole indifféremment avec la grosse majorité des constructeurs, du moins pour des besoins basiques. On verra plus tard que chaque constructeur a la possibilité d’intégrer sa propre sauce dans RADIUS.

Le client et le serveur RADIUS

Les équipements utilisant RADIUS pour l’authentification des utilisateurs sont en général assez bêtes: ils n’ont pas une notion très poussé de la gestion des utilisateurs se connectant à lui. De ce fait, ces équipements vont déléguer la partie authentification à un serveur RADIUS défini à l’avance. L’équipement attend en retour un « OUI » ou « NON » du serveur RADIUS afin d’autoriser ou non la connexion. La réponse peut également contenir des informations supplémentaires définissant la stratégie à appliquer à l’utilisateur.

Toute l’intelligence se trouve donc dans le serveur RADIUS. Ce dernier dispose donc d’une totale liberté quant au sort qu’il va réserver aux requêtes de connexion. Il peut choisir de s’intégrer à un serveur LDAP pour y chercher les utilisateurs, ou bien simplement hardcoder les identifiants dans un fichier. On peut également définir les stratégies de connexion à renvoyer dans un fichier en dur, ou bien récupérer ces stratégies à partir de certains attributs dans un annuaire. RADIUS peut également choisir de relayer les requêtes à un autre serveur, dans le cas où ce dernier ne peut pas les gérer. Ce dernier système est utilisé dans les dispositifs faisant usage du concept d’itinérance (eduroam, itinérance mobile, etc.).

En somme, un serveur RADIUS peut théoriquement faire ce qu’il veut des requêtes qu’il reçoit, l’équipement requérant attend au minimum juste un « OUI » ou « NON » en retour pour être content.

Les différents acteurs de RADIUS

Dans le contexte de RADIUS, il existe tout un vocabulaire permettant de nommer les différents acteurs intervenant dans les différents processus du protocole:

• Le « supplicant »: l’utilisateur final qui fournit ses informations d’identification,
• Le « NAS » (Network Access Server, ne pas confondre avec le serveur de fichiers): l’équipement qui prend en charge la demande d’identification du supplicant et qui s’adresse au serveur RADIUS. Aussi appelé « client RADIUS », il peut s’agir d’un serveur VPN, DSLAM, une borne Wi-Fi, etc.
• Le « proxy »: un serveur RADIUS qui va relayer une demande d’identification à un autre serveur RADIUS, car le premier serveur ne connaît pas la réponse à la demande d’authentification. Utilisé en général lorsque des utilisateurs de plusieurs royaumes différents veulent se connecter sur un même équipement (eduroam par exemple),
• Le « Home RADIUS »: le serveur final qui vérifie les informations d’identification et qui donne la réponse finale, ainsi que la stratégie à appliquer à l’utilisateur.

Le protocole

Plutôt que de faire un cours magistral, partons plutôt d’une capture de trames pour mieux comprendre en quoi consiste le protocole.

Que vois-on ici ?

• RADIUS n’est au final qu’un petit protocole fonctionnant sur UDP/1813 (la comptabilisation se fait sur le 1813) et qui permet d’échanger des informations par paires de clés-valeurs (les attributs),
• Il existe 4 « verbes » RADIUS (le « code » dans la capture de trames):
  • Access-Request: envoyée du client au serveur et contient des informations permettant d’identifier l’utilisateur qui se connecte,
  • Challenge-Request: lorsque le serveur n’a pas assez d’éléments permettant l’authentification l’utilisateur, le serveur demande plus d’informations,
  • Access-Accept: l’accès est autorisé, le message peut également contenir des informations de stratégie,
  • Access-Reject: l’accès est refusé.
• Les paquets contiennent un certain nombre d’informations en plus du code appelés attributs. Selon le verbe utilisé, les attributs peuvent contenir des informations d’identification, de connexion, ou de stratégie à appliquer à l’utilisateur , etc.

Ces 3 éléments suffisent donc à accomplir le processus décrit dans les 2 premiers A de « AAA »: l’authentification et l’autorisation:

• L’authentification par la transmission d’informations tels que nom d’utilisateur et mots de passe (mais pas seulement),
• L’autorisation par l’acceptation ou le refus, et éventuellement le passage d’attributs supplémentaires donnant la stratégie à appliquer à la connexion.

Les attributs de RADIUS

RADIUS fonctionne donc essentiellement par passage d’attributs. Il en existe plusieurs centaines répertoriées dans des dictionnaires d’attributs. Il existe des attributs « standards » définis par diverses RFC, et d’autres définis par des constructeurs. Et c’est là que se trouve l’un des intérêts de RADIUS. Le protocole n’est pas figé sur les données exactes qu’on peut faire passer: on la possibilité de faire passer quasiment n’importe quoi, la seule condition étant que le serveur et le client doivent comprendre tous les attributs qui passent.

Afin d’illustrer la diversité des attributs, voici quelques exemples d’attributs présents dans les dictionnaires:

• User-Password: Mot de passe PAP, c’est un attribut assez basique,
• Framed-IP-Address: Spécifie une adresse IP à attribuer à l’utilisateur, utilisé dans le cadre de tunnels PPP par exemple,
• Tunnel-Type: Donne le type de tunnel utilisé (PPTP, IP-in-IP, GRE, etc.),
• Cisco-Call-Type:Un attribut utilisé par le matériel Cisco,
• 3GPP-IMSI: un numéro unique identifiant un usager sur les réseaux mobiles 2/3/4G (attribut du consortium 3GPP).

Vous pouvez retrouver les premiers attributs définis par RADIUS ici, ainsi que tous les dictionnaires actuellement connu par FreeRADIUS là.

La sécurité de RADIUS

Maintenant, un petit point sur la sécurité du protocole. Il faut savoir que RADIUS est un protocole très simple, et donc peut se révéler assez sensible. Les informations transitant sont protégées de manière assez faible (CHAP), voire pas du tout (PAP). De même RADIUS ne fournit aucun mécanisme de sécurité, à part un secret partagé entre client et serveur qui passera quand même en clair sur le réseau.

De ce fait, il faut s’assurer que le transport soit bien sécurisé. Par exemple, si du trafic RADIUS devait passer sur internet, il faut faire en sorte de rajouter une couche d’IPSec ou autre VPN. Il faut également s’assurer qu’il n’y ait pas de mouchard qui pourrait écouter les échanges RADIUS, car des informations sensibles peuvent potentiellement être volés (mots de passe par exemple).

Et le processus d’accounting dans tout ça ?

En effet, le protocole RADIUS décrit précédemment traite à la fois de l’authentification, de l’autorisation et de la comptabilité. Ce dernier processus se fait séparément par d’autres messages, sur un autre port, et éventuellement même sur un autre serveur.

Je ne traiterai pas du processus d’accounting pour le moment, car je n’en ai pas l’utilité. Si jamais je devais tout de même l’implémenter plus tard, je ferai probablement un autre article à ce sujet.

Conclusion

En espérant avoir éclairci ce qu’était RADIUS. Nous avons posé ici les généralités du protocoles, nécessaires pour comprendre la suite. Les points plus spécifiques, tels que les interactions avec l’EAP, les protocoles de mot de passe (PAP, CHAP), ainsi que FreeRADIUS. La suite très prochainement !

TL;DR

• RADIUS est un protocole AAA: il gère l’authentification, l’autorisation et la compatibilité à destination d’équipements réseau le plus souvent,
• Toute l’intelligence se trouve dans le serveur RADIUS: dit OUI/NON et donne la stratégie que l’équipement requérant doit appliquer,
• « supplicant »: utilisateur, « NAS »: équipement requérant,
• Messages sous la forme de paquets UDP sur les ports 1812 et 1813, échanges par des verbes et une série de couples clés-valeurs,
• Il existe une multitude d’attributs divers et variés: certains sont standardisés par RFC, d’autres définis arbitrairement par les constructeurs,
• Le protocole est vulnérable et transporte des informations sensibles en clair, il est essentiel de sécuriser le transport.