Le standard RADIUS est basé sur un ensemble d’attributs relatifs aux utilisateurs. Ils sont tous stockés dans la base RADIUS d’un serveur d’authentification. Au cours d’une connexion, un échange d’informations a lieu entre le serveur et le client. Le standard RADIUS propose un certain nombre d’attributs devant être mis en œuvre, mais beaucoup d’implémentations spécifiques du protocole apportent leur propre jeu d’attributs.
Le protocole RADIUS permet une authentification utilisateur/mot de passe ou utilisateur/challenge/réponse ou les deux, qui peut être configurée spécifiquement pour chaque utilisateur. La vérification est réalisée par le serveur RADIUS, qui retourne alors un “authentication reply” au client qui a émis la requête. L’autorisation, elle, est réalisée par l’équipement coté client, en utilisant les informations sur l’utilisateur retournées par le serveur.
Le protocole RADIUS est basé sur un échange de paquets utilisant le protocole UDP. Il existe 4 types de paquets UDP différents :
- « Access-Request » ;
- « Access-Accept » ;
- « Access-Reject » ;
- « Access-Challenge ».
Il est important de noter que contrairement au protocole TACACS +, il n’est pas possible de chiffrer l’intégralité des paquets RADIUS (chiffrement du mot de passe uniquement).
Afin de se connecter à l’équipement coté client, le client RADIUS récupère d’abord toutes les informations nécessaires (login, mot de passe). La méthode de récupération de ces informations dépend de la configuration du client. Il peut s’agir directement d’un prompt invitant l’utilisateur à entrer ces informations, ou bien d’utiliser les valeurs transmises par le protocole de communication (ex : PPP).
Le client RADIUS crée ensuite un paquet de type « Access-Request » contenant les informations dont le serveur RADIUS a besoin (nom, mot de passe, ID du client, ID du port). Si un mot de passe est présent, il sera haché en utilisant MD5.
Une fois que le serveur reçoit la requête, il vérifie d’abord que le client partage un secret avec lui, puis récupère les informations concernant l’utilisateur. Celles-ci sont extraites d’une base de données qui peut être locale au serveur RADIUS, ou bien appartenir à un autre serveur RADIUS (dans ce cas, le serveur RADIUS jouera lui-même le rôle de client). Si un mot de passe doit être communiqué, il sera vérifié par le serveur.
Dans le cas où l’une des informations transmises par le client s’avère incorrecte, le serveur retourne un paquet « Access-Reject » indiquant au client que la connexion a été refusée et pouvant contenir un message d’explication. Dans le cas contraire, le serveur retourne un paquet « Access-Challenge ». Le paquet contient un nombre aléatoire que le client doit chiffrer.
En retour, le client émet de nouveau le paquet « Access-Request » mais contenant cette fois la réponse au challenge. Le serveur peut alors renvoyer :
- un paquet « Access-Accept » si l’authentification est validée ;
- un paquet « Access-Reject » dans le cas contraire ;
- un paquet « Access-Challenge » si un complément d’information est nécessaire.
Lors de l’envoi du paquet « Access-Accept », le serveur ajoute, dans le paquet, une liste de valeurs correspondant aux paramètres de l’utilisateur. Elles sont utilisées par le l’équipement coté client qui réalise la phase d’autorisation. Si elles sont valides, l’utilisateur est alors connecté.
Au démarrage d’un service, l’équipement côté client émet un paquet « Accounting-Start » au serveur RADIUS. Cet équipement centralise les informations, puis les envoie au serveur au moment de la fermeture du service dans un paquet « Accounting Stop » (quantité transmise, débit, bande passante, temps d’émission, ...).
A l’instar du protocole TACACS+, le protocole RADIUS implémente également la notion de couples attributs/valeurs permettant de définir tous les paramètres d’autorisation que l’administrateur désire mettre en œuvre.
Contrairement au protocole TACACS+, le protocole RADIUS intègre, dans son implémentation, une notion de type de données.