Remote Authentication Dial-In User Service

RADIUS (Remote Authentication Dial-In User Service) est un protocole client-serveur permettant de centraliser des données d'authentification. Le protocole RADIUS a été inventé et développé en 1991 par la société Livingston enterprise (rachetée par Lucent Technologies), qui fabriquait des serveurs d'accès au réseau pour du matériel uniquement équipé d'interfaces série ; il a fait ultérieurement l'objet d'une normalisation par l'IETF.

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article ne cite pas suffisamment ses sources (août 2010).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».

En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

Normalisation

La dernière version du protocole RADIUS est normalisée par l'IETF dans deux RFC : RFC 2865^[1] (RADIUS authentication) et RFC 2866^[2] (RADIUS accounting) de juin 2000. Le successeur du protocole RADIUS pourrait être le protocole Diameter (jeu de mots sur le double du rayon). Le protocole est souvent dénommé AAA (Authentication Authorization Accounting), la phase d'autorisation (définition des droits d'accès) étant accomplie lors de la réponse d'identification (ajout d'attributs au paquet "Authentication Response"). Un autre exemple de protocole AAA aurait pu être TACACS de Cisco, mais il est propriétaire ; et depuis la publication de la norme 802.1X qui donne en annexe D comme seul exemple de mise en œuvre le protocole Radius, ce dernier est devenu un standard de fait du AAA.

Utilité

Le but de RADIUS était à l'origine de permettre aux fournisseurs d'accès à Internet d'authentifier les utilisateurs distants utilisant les connexions par modem RTC à partir de multiples serveurs mais d'une seule base utilisateurs. Dans la situation précédente, les noms et mots de passe des utilisateurs devaient être dupliqués dans chaque appareil ayant besoin d'identifier des utilisateurs. De même, l'authentification POP (messagerie électronique) devait être gérée par ce biais. L'identification sur les sites Web par un nom et un mot de passe est aussi gérée en RADIUS, le serveur Apache est un des clients Radius les plus répandus. C'est toujours l'utilisation la plus courante du protocole RADIUS : nom et mot de passe de connexion à l'Internet, mais de plus en plus les réseaux sans fil ou filaires y ont aussi recours pour identifier les utilisateurs.

Le protocole RADIUS permet de faire la liaison entre des besoins d'identification et une base d'utilisateurs en assurant le transport des données d'authentification de façon normalisée. L'opération d'authentification est initiée par un client du service RADIUS, qui peut être un boîtier d'accès distant (NAS : Network Access Server), un point d'accès réseau sans fil, un pare-feu (firewall), un commutateur, un autre serveur. Le serveur la traite en accédant si nécessaire à une base externe : base de données SQL, annuaire LDAP, comptes d'utilisateur de machine ou de domaine ; un serveur Radius dispose pour cela d'un certain nombre d'interfaces ou méthodes.

Fonctionnement de l'identification

Schéma Client Radius entre les postes utilisateurs et le serveur Radius

Le poste utilisateur (supplicant dans les RFC) transmet une requête d'accès à un client RADIUS pour entrer sur le réseau. Ce client se charge de demander les informations identifiant l'utilisateur : le nom d'utilisateur (login) et le mot de passe par exemple.

Le client RADIUS génère selon le protocole une requête Access-Request contenant les informations d'authentification. Le serveur RADIUS peut traiter lui-même cette requête ou la transmettre à un autre serveur RADIUS par un mécanisme appelé Proxy Radius. Le serveur Radius chargé de l'identification finale (appelé Home Radius) peut traiter la demande s'il dispose de suffisamment d'éléments dans l'Access-Request ou demander des informations supplémentaires par un renvoi de paquet "Access Challenge", auquel le client répondra par un autre « Access-Request », et ainsi de suite. Les échanges sont retransmis par la chaîne de serveurs Radius proxy intermédiaires dans un sens et dans l'autre.

Quand le serveur Radius dispose de suffisamment d'éléments (jusqu'à une douzaine d'échanges pour les protocoles complexes de type EAP) le serveur RADIUS valide ou refuse l'identification en renvoyant un paquet de type : Access-Accept ou Access-Reject.

Protocoles de mot de passe

RADIUS connaît nativement deux protocoles de mot de passe : PAP (échange en clair du nom et du mot de passe), et CHAP (échange basé sur un hachage de part et d'autre avec échange seulement du « challenge »). Le protocole prévoit deux attributs séparés : User-Password et CHAP-Password.

Depuis, se sont greffées les variations Microsoft: MS-CHAP et MS-CHAP-V2; leur similitude avec CHAP permet de les transporter en RADIUS de la même façon, à l'initiative du serveur et sous réserve de possibilité de transport de bout en bout du supplicant au client Radius, du client au serveur Radius et enfin du serveur Radius à la base de données d'identification.

C'est sur cette dernière étape que souvent le bât blesse : rien n'est prévu par exemple en LDAP pour transporter le challenge ni les étapes spécifiques de MS-CHAP ou MS-CHAP-V2 qui, du coup, se terminent exclusivement sur des bases d'identification Microsoft locales pour le serveur Radius.

Autorisation

L'identification RADIUS peut être enrichie d'une autorisation, par exemple pour un client de fournisseur d'accès son adresse IP, son temps de connexion maximal, son temps d'inactivité. Tous ces paramètres sont définis par des attributs du paquet dans les RFC, en l'occurrence pour cet exemple l'attribut 8, plus connu sous son nom "convivial" Framed-IP-Address, bien que le protocole ne connaisse en fait que les numéros, et les attributs Session-Timeout et Idle-Timeout. Les attributs standards sont définis dans les RFC, les attributs spécifiques d'un fournisseur ou VSA (Vendor Specific Attributes) sont multiplexés dans l'attribut 26 : chaque fournisseur se voit attribuer un numéro unique permettant de l'identifier, un octet de cet attribut définit un numéro de VSA, ce qui permet à chaque fournisseur de définir jusqu'à 255 attributs spécifiques pour son matériel. Le serveur Radius s'adapte à ces "dialectes" par des dictionnaires d'attributs...

Comptabilisation (accounting)

La deuxième fonction d'un serveur Radius est l'accounting (ou comptabilisation) assurant à la fois la journalisation des accès et la facturation. Définie par des RFC différents, gérée sur des ports UDP différents (1646 ou 1813 pour les plus courants alors que l'identification est faite sur les ports 1645 ou 1812), cette fonction est souvent assurée par un programme ou même un serveur différent.

L'accounting se base sur deux types de paquets principaux: Accounting Start et Accounting Stop, une session est définie comme l'intervalle entre un Start et un Stop. Le paquet Accounting Start émis par le client Radius après connexion effective de l'utilisateur à la suite d'une phase d'identification réussie contient des données de base: nom d'utilisateur (mais pas le mot de passe inutile ici), adresse IP affectée, date et heure de connexion, type de connexion, type de service, etc.

Quand l'utilisateur se déconnecte du service ou que le client Radius le déconnecte sur inactivité, dépassement de temps de connexion ou autre, ce client Radius envoie un paquet Accounting Stop avec le même identificateur de session, le serveur Radius peut alors clore la session et journaliser la déconnexion, souvent avec un grand nombre de paramètres dans le paquet Stop : temps de connexion, type d'utilisation, nombre de paquets et d'octets échangés selon les divers protocoles, et éventuellement des informations plus confidentielles sur les sites visités ou contenus échangés.

Il existe d'autres types de paquets d'accounting : Intermédiaire (émis à intervalles périodiques par le client entre Start et Stop, utile au cas où le Stop serait perdu), On (le client Radius a démarré) et Off (le client Radius va s'arrêter), ce dernier pour mémoire, il est rare qu'un appareil prévienne avant de tomber en panne ou de planter.

Pour faciliter le travail de liaison entre la phase d'identification et la phase de comptabilisation (le serveur radius peut avoir reçu des centaines d'autres requêtes entre les deux), l'attribut Class est envoyé vers le client avec le paquet Access-Accept; le client Radius a pour consigne de le renvoyer tel quel dans le paquet Accounting Start. Le serveur Radius peut donc inclure dans cet attribut toutes les informations utiles pour faire la liaison entre une identification réussie, accompagnée souvent d'une réservation de ressources - canal, PVC ou adresse IP par exemple - et l'utilisation effective de ces ressources.

Dans le cas où l'opération est abandonnée (il n'y a pas de paquet Accounting Start correspondant après une identification réussie), un mécanisme doit restituer les ressources réservées; la plupart des mises en œuvre utilisent un mécanisme de temporisation pour cela (phantom accounting record). Les ressources réservées par l'identification, occupées par l'Accounting Start sont normalement libérées par le paquet Accounting Stop, ce qui implique par exemple qu'un serveur Radius ne peut attribuer des adresses IP que s'il gère aussi la fonction d'accounting.

L'accounting a aussi une fonction légale: l'accès à l'Internet doit être identifié, et tout utilisateur doit être traçable au moins vers un numéro de compte ou de carte bancaire, c'est pourquoi la fonction d'accounting est toujours activée chez les FAI et les enregistrements conservés: sur commission rogatoire d'un juge, le FAI peut fournir l'identification à un instant donné de toute adresse IP.

Limitations

RADIUS a été conçu pour des identifications par modem, sur des liaisons lentes et peu sûres ; c'est la raison du choix du protocole UDP, bien expliquée dans RFC2138. Ce choix technique d'un protocole non agressif conduit à des échanges laborieux basés sur des temporisations de réémission, des échanges d'accusés de réception qui se justifiaient tant que la connexion à l'Internet relevait du principe "bouteille à la mer" d'UDP, mais n'ont plus lieu d'être par exemple entre opérateurs dans les activités de roaming ou de Proxy Radius → Diameter utilise TCP ou SCTP
RADIUS base son identification sur le seul principe du couple nom/mot de passe ; parfaitement adaptée à l'époque (1996), cette notion a dû être adaptée par exemple pour l'identification des terminaux mobiles par leur numéro IMEI ou par leur numéro d'appel (Calling-Station-ID en Radius) sans mot de passe (alors que la RFC interdit le mot de passe vide !)
RADIUS assure un transport en clair, seul le mot de passe est chiffré par hachage ; la sécurité toute relative du protocole repose sur le seul secret partagé et impose la sécurisation des échanges entre le client et le serveur par sécurité physique ou VPN → Diameter peut utiliser IPSec ou TLS
RADIUS limite les attributs, gérés sous forme de chaîne "Pascal" avec un octet en tête donnant la longueur, à 255 octets, cohérents avec la notion de nom/mot de passe, mais inadapté à toute tentative d'introduction de biométrie (fond d'œil, empreinte digitale) de cryptographie (certificat) → Diameter utilise des attributs sur 32 bits au lieu de 8 (déjà présents dans certaines extensions EAP de RADIUS, notamment TTLS)
RADIUS est strictement client-serveur, d'où des discussions et bagarres de protocoles propriétaires quand un serveur doit légitimement tuer une session pirate sur un client → Diameter a des mécanismes d'appel du client par le serveur
RADIUS n'assure pas de mécanisme d'identification du serveur ; or se faire passer pour un serveur est un excellent moyen de récolter des noms et mots de passe → EAP assure une identification mutuelle du client et du serveur

Versions obsolètes de RADIUS

La première version de RADIUS date de janvier 1997 et était définie par RFC 2058^[3] et RFC 2059^[4]. Seul un prototype de code Merritt a existé, aucune réalisation selon ces RFC n'est arrivée sur le marché.
La deuxième version date de la même année (avril 1997) et était définie par RFC 2138^[5] et RFC 2139^[6]. Les serveurs Radius de première génération utilisaient ces RFC, certains sont encore en production.

Extensions de RADIUS

EAP (Extensible Authentication Protocol) est un protocole conçu pour étendre les fonctions du protocole Radius à des types d'identification plus complexes; il est indépendant du matériel du client Radius et négocié directement avec le supplicant (poste client, terminal d'accès). C'est ce qui a permis de le mettre en place rapidement sur un maximum d'appareils réseau puisqu'il n'utilise que deux attributs Radius servant de protocole de transport, et a conduit à une explosion de types EAP : EAP-MD5 défini dans le RFC comme exemple, mais aussi EAP-TLS, EAP-TTLS, EAP-PEAP (version 0 Microsoft, version 1 Cisco, version 2 bientôt), EAP-MS-CHAP-V2, EAP-AKA, EAP-LEAP et EAP-FAST (Cisco), EAP-SIM, etc
802.1X est un protocole assurant l'identification par port pour l'accès à un réseau ; il n'est pas lié explicitement à RADIUS dans son principe et utilise dans toutes ses définitions les termes "serveur AAA" et "protocole AAA", mais il se trouve que l'annexe D du document de référence mentionne comme "exemple" de protocole et serveur AAA le seul RADIUS. Toutes les mises en œuvre de 802.1X connues s'appuient donc sur RADIUS.
Diameter n'est pas vraiment une extension mais un successeur du protocole RADIUS ; il est basé sur TCP/SCTP alors que Radius est en UDP, il utilise des attributs de grande taille (Radius est limité à 254 octets par attribut) et il est destiné aux échanges entre serveurs sur des liaisons sûres ; les serveurs Diameter sont généralement compatibles Radius. Un certain nombre de types d'attributs Diameter se retrouvent déjà dans EAP-TTLS par exemple.

Voir aussi