Le protocole Radius
Séquence d’établissement d’une
session RADIUS
Le protocole Radius
Le protocole RADIUS (Remote Authentication Dial-In User Service) a été développé à l’origine par Steve Willens pour la société Livingston Enterprises comme un serveur d’authentification et d’accounting. Depuis devenu la propriété de Lucent Technologie, il appartient maintenant au domaine public et a été amendé par plusieurs RFC consécutives. La première normalisation a été celle énoncée par la RFC 2058 en 1997, elle fut modifiée dans la RFC 2138 et la version actuelle est la RFC 2868.
RADIUS est aujourd’hui le protocole d’authentification le plus utiliser et le plus implémenté par les équipementiers réseaux. En effet bon nombre d’entre eux possèdent leur propre bibliothèque de paramètres RADIUS.
Le protocole RADIUS repose sur la couche protocolaire UDP, jusqu’à la RFC 2138 il utilisait le port 1645, mais pour des problèmes de conflit avec d’autres protocoles le port 1812 lui a été attribué. Le principe de fonctionnement du protocole réside dans l’utilisation d’un secret qui n’est jamais transmit au travers du réseau. Ce secret sert de clef pour authentifier les transactions et effectuer le cryptage du mot de passe.
RADIUS offre un modularité complète en ce qui concerne le mécanisme d’authentification, on effet la plus par de méthode actuelle sont supportées (LDAP, PAP, CHAP, MS-CHAP, EAP, LEAP, ….).
Le protocole RADIUS est donc un protocole d’authentification, d’accounting mais pas d’autorisation, il fait pourtant parti de la famille des protocoles AAA (Authentication, Accounting, Authorization). Ceci est du à sa grande extensibilité, en effet le protocole repose sur la transmission d’attribut Clef/Valeur. Le liste de ces attributs n’est pas limitée c’est pourquoi les principaux équipementiers développent leurs propres attributs (AvPairs) dans des librairies propriétaires (VSA : Vendor Specific Attributes). La fonctionnalité d’autorisation peut donc être assurer au travers de l’exploitation de ces attributs propriétaires par les systèmes d’exploitation des équipements. D’où la présence de RADIUS dans la famille des protocoles AAA.
Structure des trames RADIUS
Figure
6 : Structure des trames RADIUS
La trame RADIUS contient cinq champs, le rôle de chacun d’entre eux est explicité ci-dessous.
Le champ CODE
Le champ CODE permet de spécifier le type du message contenu dans la trame. Neuf valeur sont possible pour ce champs chacune correspondant à un type de message possible lors des transactions RADIUS. Ces valeurs et leurs significations sont présentées dans le tableau ci-dessous.
|
Valeur |
Description |
|
1 |
Access-Request |
|
2 |
Access-Accept |
|
3 |
Access-Reject |
|
4 |
Accounting-Request |
|
5 |
Accounting-Response |
|
11 |
Access-Challenge |
|
12 |
Status-Server (experimental) |
|
13 |
Status-Client (experimental) |
|
255 |
Reserved |
Figure
6 : Valeur du champ Code RADIUS
Le champ Identifier et Length
Le champ « Identifier » sert à corréler les trames de requête et de réponse au sien des NAS (Network Access Server).Le champ « Length » sert lui à spécifier la longueur de la trame.
Le champ Authenticator
Ce champ permet d’authentifier les réponses du serveur RADIUS le plus souvent il consiste en un hachage MD5 du secret. Il permet aussi de préciser le mécanisme d’authentification de l’utilisateur à utiliser.
Le champ Attributes
Ce champ contient tout les tuples d’attributs valeurs de la requêtes ou réponse. Il contient les données transportées par la trame.
Remarque
Il est important de noter que seul le champ identifier et l’attribut contenant le mot de passe sont cryptés, le reste de la trame passe en clair sur le réseau.
Séquence d’établissement d’une session RADIUS
Le schéma ci-dessous présente les échanges effectués lors de l’établissement d’une session RADIUS classique.
Figure
6 : Etablissement d’une session RADIUS
1. Envois du couple «Login / password» crypte avec la clé partagée.
2. Si le couple est valide Access-accept avec demande d’éventuelles informations supplémentaires (adresse IP, masque de réseau, etc.) qui amènerons à un nouvel échange Acces-request Access-accept.
3. Envois d’informations pour l’accounting (phase Comptabilité).
4. Le serveur répond lorsque les informations de compatibilité sont stockées.
5. Envois d’informations pour l’accounting (phase Comptabilité).
6. Le serveur répond lorsque les informations de compatibilité sont stockées.