Authenticator

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).

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.

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 :

• le supplicant, qui est le client souhaitant se raccorder au réseau,
• l'authenticator, ou network access server (NAS) qui est l'équipement sur lequel le « supplicant » désire se connecter,
• l'authentication server (AS), qui est le serveur d'authentification.

Il est primordial de comprendre qu'une station cliente qui ne sait pas 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 :

• le supplicant sera un PC (GNU/Linux, Mac OS, ou même Windows),
• l'authenticator sera un point d'accès Wi-Fi (mais ce pourrait être aussi bien un switch sur un réseau filaire),
• l'authentication server sera un serveur RADIUS. (FreeRADIUS 1.1.3, sur une Debian « etch », ou encore sur une Ubuntu 6.10).

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 :

• TLS, qui nécessite un certificat pour le serveur comme pour le supplicant,
• PEAP, où seul un certificat côté serveur est nécessaire, le supplicant utilisant un couple « utilisateur/mot de passe »,
• TTLS, assez similaire à PEAP, mais non supporté par Microsoft Windows.

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).

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 :

• au supplicant d'être authentifié par le serveur,
• par la suite, au point d'accès d'authentifier le supplicant,
• enfin, le supplicant doit également authentifier le point d'accès.

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.

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.

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) :

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.

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.

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.

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 va 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.