Objectifs :

Etre capable de mettre en œuvre les protocoles 802.1X et RADIUS en vue de

sécuriser l’accès aux réseaux via un switch et un point d’accès WIFI ou n’importe
quel équipement d’accès réseaux compatible avec 802.1x.

Objectifs spécifiques :
1. Savoir expliquer les concepts de RADIUS
2. Maitriser les principaux attributs RADIUS
3. Maitriser les formats des données échangées entre un client et un serveur
RADIUS
4. Savoir mettre en œuvre les différents protocoles d’authentification EAP
5. Savoir contrôler l’accès aux réseaux basés sur les ports en utilisant le
protocole 802.1X aussi bien en environnement Windows que Linux

Sommaire
I. Radius
I.1 Historique
I.2 Description du protocole
I.3 Principes du protocole RADIUS
I.4 Les entités du protocole Radius
I.5 Les formats des données du protocole RADIUS

II. Le protocole 802.1x

II.1. Les protocoles et méthodes d’authentification
II.2. Fonctionnement détaillé de RADIS
II.3. Exemple de cas d’utilisation de RADIUS1x
I. RADIUS
I.1 Historique
RADIUS a été conçu dans le but initial de contrôler l'authentification à distance. Ce
besoin est né de la société « Merit Network » qui souhaitait identifier ses utilisateurs via la
liaison téléphonique afin de fournir un accès distant à son réseau informatique. L'organisation
à but non lucratif « Merit Network » a publié en 1991 une demande d'information ou «
Request for Information » (RFI) qui spécifiait les fondements du protocole RADIUS.

Après quelques mois, la société « Livingston Enterprises » répondit à cette demande

par une description d'un serveur RADIUS. La proposition fut retenue par « Merit Network »
qui donna le contrat à « Livingstone Enterprises ». Le protocole RADIUS « Remote
Authentication Dial-in User Service » traduit littéralement par Authentification à distance
composée par le service utilisateur est publié par l'IETF en Janvier 1997 dans la RFC 2058
et la RFC 2059.

Cette même année, la société « Livingstone Enterprises » leader dans l'accès à

distance des réseaux informatiques, fut rachetée par Alcatel-Lucent. Le standard RADIUS a
subi plusieurs évolutions au fil des années et à l'heure d'aujourd'hui, il est de facto le protocole
le plus célèbre pour l'authentification des postes de travail, des terminaux mobiles, des
équipements réseaux, etc...
La description actualisée du standard se trouve désormais dans la RFC 2865 et la RFC 2866
datant de Juin 2000.

I.2 Description du protocole RADIUS

Le protocole RADIUS (Remote Authentication Dial-In User Service) a évolué au fil
des années. Il intègre aujourd'hui de nombreuses fonctionnalités. Auparavant ce protocole
répondait uniquement aux besoins d'authentification et de traçabilité. Il s'est calqué sur le
modèle du protocole AAA qui permet de réaliser trois fondamentaux de l'accès à une
ressource informatique :
 « Authentication » (Authentification) : c'est la fonction principale de sécurité qui
consiste à prouver qu'une identité appartient bien à celui qui la présente. Elle peut être
réalisé en comparant des « credentiels » (nom d'utilisateur/mot de passe), certificat
numérique, etc… ;

 « Authorization » (Autorisation) : c'est la capacité à accéder, une fois l'authentification

validée, à un service ou des ressources du système d'information ;
  « Accounting » (Compatibilité) : c'est « journaliser » les accès, les temps de session, les
ressources consommées, etc... Afin de garantir la traçabilité des informations

RADIUS est un protocole client-serveur permettant de centraliser des demandes

d'authentification relayées par des équipements de réseau, comme des commutateurs ou
bornes Wifi, considérés alors comme ses clients.

Par extension, un serveur qui centralise des demandes d'authentification et les soumet à un
service d'annuaire LDAP ou à un service de base de données SQL est appelé serveur
RADIUS.
On trouvera 4 types de paquets permettant d’effectuer une authentification Radius :
 Access-Request : Ce paquet est envoyé par le NAS qui contient les
informations d’authentification du client.

 Acess-Accept : Ce paquet est envoyé par le serveur afin d’autoriser la

connexion par vérification préalable des informations de l’utilisateur
souhaitant se connecter.

 Access-Reject : Le serveur envoie ce paquet lorsqu’il refuse une connexion si

l’authentification échoue ou si la connexion doit prendre fin.

 Access-Challenge : Le serveur envoie ce paquet afin de demander une

réémission du paquet « Access-Request » ou pour obtenir des informations
complémentaires.

I.3 Principes du protocole RADIUS

De façon imagée, l'utilisateur qui veut entrer sur le réseau va s'adresser à un "gardien" (un
équipement de réseau) qui lui demande alors de décliner son identité, qui va vérifier, auprès
d'un poste de sécurité central, que l'on peut effectivement le laisser entrer et qui prendra
connaissance des prérogatives qui seront accordées à l'utilisateur après son admission.

I.4 Les entités du service RADIUS

 Figure 1 : Les entités de RADIUS

L'ordinateur sur lequel un utilisateur cherche à se connecter au réseau est appelé le

"supplicant". Il est le "client final" de la demande de connexion. Ce peut-être avec toute
forme de terminal portable, de téléphone IP ou d'ordinateur fixe. Dans la suite, nous
garderons l'expression française "client final" à la place de "supplicant".

L'équipement de réseau sur lequel le client final se connecte (un commutateur - ou une
borne Wifi compatible 802.1x, un routeur) relaye, en tant que client RADIUS, cette
demande de connexion à un serveur d'authentification, le serveur RADIUS, qui va, par
exemple, identifier la personne en rapprochant le nom de connexion et le mot de passe de
ceux stockés dans un fichier, dans un annuaire LDAP ou encore une base de données SQL.

Figure 2 : Principaux clients RADIUS

Si l'identification réussit, l'accord est transmis au client RADIUS qui "ouvrira" alors le port
de connexion.

I.5 Format des données du protocole RADIUS

Le protocole RADIUS se situe au niveau des couches hautes, dans la couche applicative du
modèle OSI. Il se place au-dessus de la couche transport. Les données du protocole RADIUS
sont acheminées par des segments du protocole UDP et encapsulées dans des paquets IP (voir
figure 3 et 4).

Les ports d'écoute UDP utilisés pour accéder aux services proposés par le protocole RADIUS
sont les suivants :
• 1812, reçoit les requêtes d'authentification et d'autorisations ;
• 1813, reçoit les requêtes d' « accounting » (comptabilité).

Figure 3 : Le protocole RADIUS au sein du modèle OSI

Figure 4 : Encapsulation du protocole RADIUS

Le protocole RADIUS utilise un format de paquet bien défini pour réaliser les transactions
d'authentification, d'autorisation et de comptabilité. Le modèle des données RADIUS
contient les champs ci-contre:
1. Code ;
2. ID ;
 3. Longueur ;
4. « Authentificateur » ;
5. Attributs et Valeurs.

Figure 5 : Format des trames RADIUS

Ces champs accueillent des types de données décrites dans la RFC du protocole RADIUS.
 Code

Ce champ identifie le type du paquet RADIUS. En effet, le protocole définit 255 types de
paquets que l'on peut trouver dans la RFC 3575. Cependant, nous allons citer quelques types
de ces derniers à savoir :
 Access-Request
 Access-Challenge
 Access-Accept
 Access-Reject

 ID
Ce champ permet de mettre en relation un identifiant au client RADIUS avec le couple
requêtes/réponses.

 Longueur
Ce champ contient la longueur totale des données RADIUS.
 Authentificateur

Ce champ permet de vérifier l'intégrité des paquets envoyés par le serveur RADIUS. Il est
calculé de manière aléatoire à partir d'un secret partagé (mot de passe connu par le serveur et
le client) entre le client et le serveur. Ainsi, le client RADIUS peut s'assurer que la réponse
lui vient bien du serveur RADIUS et non d'un usurpateur.

 Attributs et valeurs
Ce champ contient la charge utile du protocole RADIUS. Il est de longueur variable en
fonction des couples d'attributs/valeurs envoyés par le client RADIUS en requête ou par le
serveur RADIUS en réponse.

Les informations contenues dans les requêtes/réponses d'authentification, d'autorisation et de

comptabilités sont transportées par les couples attributs/valeurs du protocole. Le champ
attribut et valeur joue un rôle primordial dans les échanges RADIUS. En effet, c'est lui qui va
véhiculer les informations relatives à l'authentification, l'autorisation ou à la comptabilité.
Chaque attribut est caractérisé par un numéro d'attribut, une longueur ainsi qu'une valeur (voir
figure 6). Dans le jargon RADIUS, un couple attribut/valeur est appelé AVP "Attributes
Value-Pair".

Un attribut peut prendre les valeurs suivantes :

• adresse IP ;
• date ;
• chaîne de caractère (par exemple un mot de passe) ;
• entier (un numéro de port) ;
• valeur binaire ou hexadécimale
 Figure 5 : Champ « attributs et valeurs » du protocole RADIUS

Dans les paquets RADIUS, le nom d'un attribut n'apparaît jamais. Seul le numéro de l'attribut
est présent. La correspondance entre le nom de l'attribut et son numéro est faite grâce à un
dictionnaire d'attributs implémenté sur le client et sur le serveur.
Les dictionnaires d'attributs contiennent la concordance entre les attributs standards et leurs
numéros respectifs. Mais il peut également avoir des dictionnaires d' « attributs constructeurs
».

 Les attributs RADIUS

Le protocole RADIUS compte un grand nombre d'attributs (plus d'une centaine). La liste
complète des attributs RADIUS est consultable sur le site internet de l'organisation IANA au
lien suivant : http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-
2
 Exemple :

Tableau 1 : Principaux attributs RADIUS

"User-Name"

Cet attribut est envoyé par le client RADIUS lors de la demande d'authentification. Il peut
correspondre à un identifiant utilisateur associé à un mot de passe. Dans le cas de
l'authentification d'une machine, cet attribut peut prendre la valeur de l'adresse physique de
celle-ci plus communément appelée adresse MAC. Lors de l'utilisation d'un certificat
électronique, la valeur reçue par l'attribut User-Name est le nom du porteur du certificat.
"User-Password"
Cet attribut contient le mot de passe associé à l'attribut User-Name. Il est également envoyé
par le client RADIUS.
"NAS-IP-Address"
Cet attribut est renseigné par le client RADIUS (NAS). Il contient son adresse IP. Cet attribut
peut imposer une restriction. Par exemple, un poste de travail ne pourra s'authentifier que s'il
se connecte à partir d'un NAS possédant une adresse IP spécifique.
"Nas-Port"
Cet attribut permet d'ajouter une condition supplémentaire pour l'authentification. Prenons
l'exemple d'un équipement réseau de type commutateur. Ainsi, un poste de travail est autorisé
à s'authentifier uniquement s'il est connecté sur un port précis du commutateur. L'attribut «
Nas-Port » donne le numéro de port sur lequel est connecté un poste utilisateur. Il est envoyé
par le NAS lors de la demande d'authentification.

Dans la technologie sans fil, cet attribut perd son sens, car un point d'accès génère un port
"virtuel" au moment de l'association du poste de travail à celui-ci.
"Called-Station-Id"
Cet attribut contient l'adresse MAC du NAS qui demande l'authentification au serveur
RADIUS

"Calling-Station-Id"
Cet attribut contient l'adresse MAC du poste de travail souhaitant s'authentifier.

 Les attributs constructeurs

L'ajout d'attribut(s) constructeur permet aux administrateurs réseau de tirer un meilleur profit
des capacités de leurs équipements réseau. En effet, ils offrent aux fournisseurs la possibilité
de spécifier 255 attributs supplémentaires pour leurs matériels. L'implémentation d'un
dictionnaire d'attributs constructeur permet le support de ceux-ci sur le serveur RADIUS.
Bien évidemment, seuls les équipements constructeurs pourront interpréter la valeur d'un
attribut propriétaire.

Cet attribut est appelé « Vendor Specific Attributes » (VSA) dans la terminologie RADIUS.
Il est identifié par le numéro d'attribut 26. L'attribut VSA est similaire au couple
attribut/valeur (AVP) RADIUS (voir figure 7). Chaque attribut VSA est constitué des champs
suivants :
 N° d'attribut : c'est le numéro 26 qui est défini pour l'attribut VSA dans le standard
RADIUS ;
 Longueur : contient la longueur totale de l'attribut ;
 « Vendor-id » : contient le code international du constructeur. Chaque constructeur
possède un code qui lui est propre. On trouve la liste des codes constructeur dans la
RFC 1700 ;
 N° d'attribut constructeur : contient le numéro d'attribut spécifié par le constructeur ;
 Longueur VSA : contient la longueur du champ VSA ;
 Valeur de l'attribut constructeur : contient la valeur de l'attribut VSA.

Figure 6 : Format des attributs VSA

 Les types de paquets RADIUS

Chaque échange RADIUS est caractérisé par un paquet associé à un code. La figure
ci-dessous présente quelques utilisations des types Radius
 Figure 7 : Les échanges au sein du protocole RADIUS
Format de données d’un paquet de type ACCESSS-REQUEST
 Figure 8 : Message de type ACCESS-REQUEST

Format de données d’un paquet de type ACCESSS-CHALLENGE

Figure 9 : Message de type ACCESS-CHALLENGE

Format de données d’un paquet de type ACCESSS-ACCEPT

Figure 10 : Message de type ACCESS-ACCEPT

Format de données d’un paquet de type ACCESSS-REJECT

Figure 11 : Message de type ACCESS-ACCEPT

 II. Le protocole 802.1X
Le protocole 802.1x est une solution standard de sécurisation de réseaux mise au point par
l'IEEE en 2001. 802.1x permet d'authentifier un utilisateur souhaitant accéder à un réseau
(câblé ou Wifi) grâce à un serveur central d'authentification.

L'autre nom de 802.1x est "Port-based Network Access Control" ou "User Based Access
Control".

Le protocole 802.1x permet de sécuriser l'accès à la couche 2 (liaison de donnée) du réseau.

Ainsi, tout utilisateur, qu'il soit interne ou non à l'entreprise, est dans l'obligation de
s’authentifier avant de pouvoir faire quoi que soit sur le réseau. Certains équipements de
réseau compatibles 802.1x peuvent réserver un traitement particulier aux utilisateurs non
authentifiés, comme le placement dans un VLAN "guest", une sorte de quarantaine sans
danger pour le reste du réseau.

Le protocole 802.1x a recours au protocole EAP (Extensible Authentification Protocol) qui

constitue un support universel permettant le transport de différentes méthodes
d'authentification qu'on retrouve dans les réseaux câblés ou sans-fil.

Le protocole 802.1x nécessite donc la présence d'un serveur d'authentification qui peut être
un serveur RADIUS : un serveur Microsoft, Cisco (...) ou un produit libre comme
FreeRADIUS) ou encore un serveur TACACS dans le monde fermé des équipements Cisco.

Un port d'un commutateur réglé en mode 802.1x peut se trouver dans deux états distincts :

 État "contrôlé" si l’authentification auprès du serveur RADIUS a réussi.

 État "non contrôlé" si l’authentification a échoué.

La réussite ou l'échec de l'authentification va donc ouvrir ou fermer le port à toute

communication. Un port ouvert va, par exemple, permettre au client final d'obtenir une
adresse IP auprès d'un serveur DHCP.

Dans des implémentations plus cloisonnées, le serveur RADIUS indiquera par exemple au
client RADIUS dans quel VLAN placer le client final.
 II.1. Les protocoles et méthodes d’authentification
EAP est la couche protocolaire de base de l'authentification. Elle va servir à faire passer un
dialogue d'authentification entre le client final et le serveur RADIUS alors que le port de
connexion est fermé à toute autre forme de communication.

C'est un protocole extensible, au sens où il va permettre l'évolution de méthodes

d'authentification transportées, de plus en plus sûres au cours du temps.

Les méthodes d'authentification ?

Le premier protocole a été PAP (Password Authentification Protocol) avec lequel les mots
de passe circulaient en clair. La sécurité proposée par ce protocole est faible.

Le second protocole qu'ont utilisé les serveurs RADIUS a été CHAP (Challenge Handshake
Authentication Protocol). Il est défini dans la RFC 1994. Avec CHAP, il n'y a pas d'échange
de mots de passe sur le réseau.

Les deux interlocuteurs, qui disposent donc de la même chaîne de caractère secrète,
s'authentifient sans échange du mot de passe par une technique de "challenge" (ou "défi")
basée sur une fonction de hachage à sens unique du secret partagé, telle que MD5.

Au début de la connexion, le serveur réclame la preuve de l’identité du client, en lui

demandant de chiffrer une information. Le client ne peut relever le défi que s’il possède
effectivement la clé unique et secrète partagée.

 Dialogue client-serveur avec CHAP

A. Après l'établissement de la connexion, l'authentificateur envoie une valeur

aléatoire xxxxxx au client.
B. Le client concatène cette valeur xxxxxx au secret partagé, applique une
fonction de hachage (telle que MD5) sur la chaîne obtenue et retourne le
résultat.
C. Le serveur effectue la même opération et compare avec le résultat reçu. La
connexion n'est acceptée que si le résultat est identique.
D. A intervalle régulier, il y a un nouveau défi à relever pour pérenniser la
connexion.
Microsoft a développé une variante de CHAP appelée MS-CHAP qui ajoute une
authentification mutuelle, MSCHAP-V1, puis MSCHAP-V2.

 Dialogue client-serveur avec MSCHAP-V2.

A. Le serveur envoie au client une chaîne composée d'un identifiant de session et
une chaîne aléatoire xxxxx.
B. Le client renvoie son nom d'utilisateur et le résultat d'un hachage de la chaîne
aléatoire xxxxx + L’identifiant de session + le mot-de-passe, et une seconde
chaîne aléatoire yyyyy.
C. Le serveur vérifie le résultat (succès/échec) et retourne celui-ci, avec un
hachage de la chaîne yyyyy et du mot de passe utilisateur.
D. Le client vérifie enfin la correspondance entre les chaînes.
E. La connexion est établie.

 PEAP
PEAP est un protocole de transfert sécurisé (P comme "Protected") d'informations
d'authentification. Il a été mis au point par Microsoft, Cisco et RSA. Il ne nécessite pas de
certificat sur les postes clients, contrairement à EAP/TLS. MS-CHAP s'appuie sur PEAP

 Articulation EAP / PEAP / MSCHAP-V2

 EAP est le mécanisme permettant à un client final de pouvoir communiquer
sur un port 802.1x fermé à toute autre forme de communication.
 PEAP ajoute la notion de protection des échanges par tunnel à ce mécanisme
 MSCHAP est la méthode de reconnaissance mutuelle du client serveur et du
serveur RADIUS qui passe par ce tunnel

Les différentes phases (simplifiées) d'une connexion 802.1x

Au démarrage de la communication, le client final est prié d'envoyer ses identifiants au
serveur RADIUS. Or, à ce moment-là, le client final ne connaît pas l'adresse du - ou des -
serveurs RADIUS du réseau. Il ne dispose peut-être même pas d'adresse IP. De même, le
port du commutateur sur lequel il est connecté est censé être fermé (état non contrôlé).

En réalité, le port contrôlé du commutateur n'est pas totalement fermé. Il va laisser passer
le protocole EAP (Phase  sur le schéma suivant). Cette communication ne peut donc
se faire que par des trames Ethernet de base et non par des paquets IP.

Le client final peut donc envoyer son identité dans un paquet EAP au commutateur. Celui-
ci le retransmet, encapsulé dans un paquet au format RADIUS, au premier serveur RADIUS
de sa liste (s'il en connaît plusieurs) (Phase ).

Le serveur RADIUS reçoit le paquet et interroge sa base de données (Phase ).

Il renvoie le résultat de cette interrogation au commutateur (Phase ), sous forme d'un

commandement d'ouverture du port, éventuellement assorti d'un numéro de VLAN dans
lequel placer le client final. A partir de ce moment seulement, il peut y avoir d'autres trames
échangées entre le client final et le reste du réseau, comme une trame de requête DHCP par
exemple.

Figure 12 : Les différentes phases d’une connexion

Avant authentification

EAP

 Le port ne laisse passer que des trames EAP.

Après authentification

 Le port laisse passer tous les types de trames.

Conséquence de ce fonctionnement général.
L'équipement réseau ne connaît que le protocole RADIUS. Le protocole d'authentification entre
le client final et le serveur RADIUS pourra varier sans que cela soit un blocage pour
l'équipement. En ce sens, on dit que le client RADIUS est "transparent".

II.2. Fonctionnement détaillé de RADIUS

Figure 13 : Authentification RADIUS et 802.1X

Étape 1 - identité externe

1.1 L'équipement demande au client final de décliner son identité (trame EAP-
Request-Identity),

1.2 Le client répond par une trame EAP contenant son nom d'utilisateur (trame EAP-
Response-Identity). Ça tombe bien, les trames EAP sont les seules autorisées à entrer dans
l'équipement.
L'équipement fabrique un paquet IP [access-request] encapsulant la trame [EAP- response-
Identity]. Il ajoute d'autres informations comme l'adresse MAC du client final. Ce paquet IP
est envoyé au serveur RADIUS.

Étape 2 - Négociation de protocole.

Le serveur RADIUS reçoit le paquet [Access-Request] et fabrique un paquet [Access-
challenge] encapsulant une trame [EAP-Request] contenant une proposition de protocole
d'identification, comme PEAP.

L'équipement décapsule le paquet pour transmettre la trame EAP au client final.

Le client final répond dans une trame [EAP-response] transmis de la même manière indirecte
par encapsulation - au serveur RADIUS.

Le client et le serveur étant tombés d'accord sur le protocole d'authentification, on passe à

l'étape suivante.

Étape 3 - TLS handshake

Le serveur RADIUS envoie au client une requête de démarrage [PEAP-START] toujours

par le mécanisme d'encapsulation d'une trame EAP.

Le client final répond par un message [client hello] avec la liste des algorithmes de
chiffrement qu'il connait.

Le serveur envoie son choix d'algorithme, ainsi que son certificat et sa clé publique au client
final.

Le client final authentifie le serveur. Il génère une "pré-master-key" avec la clé publique du
serveur. Le serveur fait de même et un tunnel chiffré est établi entre eux. Le tunnel sert à
protéger l'échange du mot de passe par rapport à une authentification EAP simple.

Rappel : le client final n'a pas de certificat (PEAP). Attention, bien qu'on utilise TLS, on
n’est pas dans "EAP-TLS", méthode utilisant des certificats serveur et client.

Étape 4 - TLS record

Les échanges liés au protocole de validation du mot de passe vont être effectués dans le tunnel
TLS avec MSCHAP-V2.

Le port s'ouvre lorsque le serveur envoie au client final un message [Access-Accept] après
avoir vérifié le mot de passe de l'utilisateur et s'être assuré de ses autorisations.
 II.3. Exemple de cas d’utilisation de RADIUS

Cet exemple de cas d’utilisation permet d’authentifier les utilisateurs finaux qui tentent de
connecter au point d’accès avec un login et un mot de passe qui sont stockés dans un fichier,
dans une base de données, ou dans un annuaire LDAP.

Installation et Configuration

# apt-get install freeradius freeradius-utils

Nous éditons le fichier /etc/freeradius/clients.conf pour déclarer le Point d'accès Wifi comme
suit :

La déclaration d'un point d'accès consiste à préciser son adresse IP ou son adresse réseau et
son mot de passer qui permettent de l'authentifier auprès du serveur freeradius.
Il reste à créer les utilisateurs dans le fichier /etc/freeradius/users pour se connecter avec ces
comptes :

Test de connexion avec les utilisateurs créés avec l’utilitaire radtest :

Pour tester nous allons démarrer le serveur en mode débeug pour voir les différentes requêtes
échangées.

Access-Accept prouve que la connexion est acceptée.

Configuration de Point d'accès
La configuration du point d'accès et le choix du mode d'authentification WPA/WPA2-
Entreprise :

Redémarrer le point d'accès et testons la connexion :