Le wi-fi sécurisé
 09/03/2007 
 Christian CALECA 
Liste des cours

Authenticator

[ Accueil ] [ Introduction ] [ Solutions ] [ Authenticator ] [ WPA2 ] [ Authentifications ] [ Les certificats ]

Définition

L'authenticator utilise le protocole 802.1x. C'est un protocole qui a été défini dans le but d’autoriser l’accès physique à un réseau local après une phase d’authentification. Ce protocole peut aussi bien s'appliquer à un "port" physique (un point d'entrée sur un switch, par exemple), que sur un "port" virtuel (l'attachement à un point d'accès Wi-Fi).

authenticator Il est peut être nécessaire de passer un peu de temps à bien comprendre le principe d'un port contrôlé par 802.1x (authenticator).

Lorsque le client (supplicant) se connecte (Ethernet) ou s'attache à un point d'accès (802.11), l'accès au LAN lui est fermé. Le seul trafic autorisé sera constitué des échanges entre le supplicant et le serveur d'authentification.

Le port ne pourra s'ouvrir sur le LAN sans restrictions qu'une fois l'authentification réussie.

authenticator Bien entendu, physiquement, il n'y a qu'un seul port. Ce port physique est composé de deux ports virtuels :
  • l'un, non contrôlé, mais qui ne laisse passer que le trafic d'authentification (RADIUS),
  • l'autre, contrôlé, qui est destiné à laisser passer tout le trafic Ethernet, mais qui est fermé jusqu'à ce que l'authentification soit réussie.

802.1x ne peut se jouer qu'à trois personnages :

Il est primordial de comprendre qu'une station cliente qui ne sait jouer le rôle de "supplicant" ne pourra jamais accéder au LAN. Pour jouer ce rôle, il faut un bout de logiciel spécifique sur le client. Windows XP intègre ce logiciel depuis le SP1. Sous Linux, il faudra installer wpasupplicant, par exemple. La plupart des distributions modernes installe par défaut ce composant.

Typiquement, dans le cadre de notre étude :

Mais 802.1x n'est qu'un support. 802.1x va servir à transporter un protocole d'authentification, comme EAP (Extensible Authentication Protocol). Comme son nom le laisse supposer, EAP est plutôt souple et permet diverses méthodes d'authentification, plus ou moins efficaces. Il faut bien comprendre qu'EAP n'apporte pas à lui seul la moindre authentification, il sert lui-même à supporter diverses méthodes d'authentification.

Nous retiendrons trois de ces méthodes :

Pratiquement, nous ferons du TLS si nous avons le courage de créer un certificat par supplicant, et la liste de révocation qui doit aller avec ; nous ferons du PEAP sinon, puisque c'est possible sur les clients GNU/Linux comme sur les clients Windows et Mac OS X. Les deux solutions apportent un niveau de sécurité technique que l'on peut, au moment où ces lignes sont écrites, considérer comme suffisant.

Cependant, un couple "utilisateur/mot-de-passe" valide peut s'obtenir plus facilement qu'un certificat. Aussi préfèrerons-nous utiliser TLS que PEAP (ou TTLS).

Note importante

802.1.x n'est pas une solution exempte de failles. Il est indispensable d'utiliser par dessus des systèmes d'authentification qui permettent :

Si les deux derniers points ne sont pas vérifiés à chaque paquet transmis, nous courons le risque de voir un attaquant mettre hors jeu un client dûment authentifié, pour lui voler sa place, ou placer un point d'accès pirate pour tromper le client en cours de session.

TLS, PEAP et TTLS répondent à cette problématique.

Principe de fonctionnement

principe

Lorsque le "supplicant" découvre le point d'accès, ce dernier ne lui ouvre pas de port, jusqu'à ce que le "supplicant" soit authentifié par le serveur. Seul le trafic nécessaire à 802.1x sera toléré avant une authentification réussie.

radius

Entre le supplicant et l'authenticator, aussi longtemps que l'authentification n'est pas entièrement réussie (réponse positive du serveur RADIUS), le seul trafic permis est le dialogue d'authentification, le client n'a pas accès au réseau (depuis le temps que je le dis, j'espère maintenant que c'est bien compris).

Entre l'authenticator et le serveur, le trafic se fait classiquement sur UDP/IP, ce qui permet de disposer d'un serveur d'authentification très éloigné, si besoin est. Ce trafic est appelé "EAP over RADIUS".

D'une manière générale, les échanges se font de la sorte (cas d'une authentification réussie) :

radius

Authentifications nécessaires

Compte tenu des divers risques introduits (faux serveur d'authentification, faux point d'accès, faux client), il convient de mettre en place des stratégies qui permettent de minimiser les risques de leurre.

Authentification du serveur

Le serveur va utiliser un certificat (sorte de carte d'identité, réputée authentique, sous la responsabilité d'une "Certificate Authority", ou "Autorité de certification"). Le serveur communique au client la partie publique de ce certificat, et le client peut vérifier auprès de la CA que ce certificat est bien valide.

Authentification du client

Le client peut utiliser divers moyens, qui vont du certificat (même procédure que pour le serveur), au bon vieux couple "nom d'utilisateur/mot de passe", en passant par des systèmes à base de carte à puce ou d'empreintes biométriques.

Authentification du point d'accès

Ici, le problème est un peu plus compliqué. Que devons-nous vérifier en réalité ? Nous devons être "sûr" que le point d'accès auquel le client s'est attaché à la suite de la procédure d'authentification ne vas pas être remplacé par un point d'accès "voleur" en cours de session (man in the middle).

802.11i (WPA2) offre la technique, actuellement la plus sûre, pour s'affranchir de ce risque. Nous verrons ceci plus loin.

[ Précédente ] [ Accueil ] [ Suivante ]