Sphéria Val de France souhaite que la solution à sa problématique réponde à l’objectif suivant : vérifier l’identité des équipements voulant se connecter à son réseau afin de les autoriser ou non à se connecter.
Cette identification va être rendue possible par l’utilisation du protocole 802.1x qui effectue une authentification de l’équipement client au moment de la connexion physique au réseau. La phase d’authentification sera assurée au travers du protocole EAP, le protocole 802.1x ne fournissant qu’un cadre fonctionnel à l’interaction entre les équipements. Il est donc nécessaire d’étudier les différentes méthodes d’authentification qu’il propose afin de choisir celles qui sont le plus adapté à l’environnement de SVF.
6.1. Principe général du protocole 802.1x
Le protocole 802.1x est composé de trois entités qui interagissent pour le processus d’authentification :
• Le système à authentifier ou Supplicant,
• Le système authentificateur ou Authenticator : c’est un équipement réseau (commutateur, routeur, borne wifi …) qui agit comme une barrière de sécurité entre le Supplicant et le réseau protégé. Il sert de relais entre le Supplicant et le serveur d’authentification et gère le PAE (Port Access Entity) qui permet au Supplicant d’accéder ou non au réseau,
• Le serveur d’authentification ou Authentication Server : il s’agit généralement d’un serveur RADIUS.
Figure 13: Les 3 entités qui interagissent dans le protocole 802.1x.
6.2. Le point d’accès au réseau : PAE
Le PAE est le point d’accès physique au réseau géré par le système authentificateur et sur lequel va être réalisée l’authentification. Dans le cas d’un commutateur il s’agit du port de connexion.
La principale innovation du protocole 802.1x réside dans ce concept : le port physique est scindé en deux ports logiques :
• Un port appelé « non contrôlé », qui gère toutes les trames spécifiques au protocole 802.1x et qui est toujours connecté,
• Un port appelé « contrôlé » qui peut être soit ouvert, soit fermé.
Ainsi avant l’authentification du demandeur, seul le mode non contrôlé est possible, permettant les échanges d’information d’authentification. Ces flux sont appelés flux EAPOL (EAP Over Lan).
Figure 14: État du PAE avant la phase d'authentification.
Une fois que l’authentification est réalisée avec succès, le port contrôlé est basculé de l’état ouvert à l’état fermé et les flux autorisés peuvent être émis à destination du réseau.
Figure 15: État du PAE après une authentification réussie.
Serveur d’authentification
Réseau Client
Equipement d’accueil Port non contrôlé
Port contrôlé Serveur d’authentification Réseau Client Equipement d’accueil Port non contrôlé
Port contrôlé
6.3. Fonctionnement du protocole 802.1x
Comme je l’ai indiqué précédemment, le protocole 802.1x implique trois composants : le système à authentifier, l’authentificateur et le serveur d’authentification.
Il convient toutefois de noter que bien que les différentes conversations entre le client, l’authentificateur et le serveur d’authentification (et les protocoles utilisés) sont par un abus de langage communément appelées 802.1x, en réalité seule la conversation entre l’authentificateur et le client est 802.1x (ou EAPOL).
La communication entre le serveur d’authentification et l’authentificateur utilise le protocole RADIUS alors que la conversation entre le serveur d’authentification et le système à authentifier s’appuie sur le protocole EAP et les EAP-Methods.
Figure 16: Les différents protocoles composant le 802.1x.
Le point clé du fonctionnement du protocole 802.1x est que le client ne peut communiquer qu’avec l’authentificateur.
Dans la phase d’authentification 802.1x, le système authentificateur se comporte comme un mandataire entre le système à authentifier et le serveur d’authentification.
Si l’authentification réussit, le système authentificateur donne l’accès à la ressource qu’il contrôle.
Le serveur d’authentification va quant à lui gérer l’authentification proprement dite en vérifiant les informations d’authentification du système à authentifier.
On peut considérer qu’il existe 4 scénarios d’interactions qui couvrent l’ensemble des cas que l’on peut rencontrer.
6.3.1. Scénario 1 : Processus de base
L’authentificateur va initier le processus d’authentification lorsqu’il détecte une connexion sur l’un de ses ports. S’il obtient une réponse à sa requête d’identité, il contacte le serveur RADIUS pour valider le contenu de la réponse. Le serveur RADIUS lui indique alors si le client est autorisé à se connecter au réseau.
Figure 17: Exemple de dialogue lors du processus d'authentification.
6.3.2. Scénario 2 : Supplicant non configuré
Le Supplicant n’est pas configuré pour le 802.1x, l’Authentificateur ne reçoit pas de réponse à ses requêtes d’identité, il place alors le Supplicant dans un vlan Guest ou désactive le port sur lequel la connexion intervient.
Figure 18: Exemple de dialogue lorsque le Supplicant n’est pas configuré.
6.3.3. Scénario 3 : Pas d’authentificateur
Le Supplicant est connecté sur un port sur lequel le 802.1x n’est pas activé. Le Supplicant a 2 choix :
• Etre passif et attendre une requête d’identité EAPOL de la part de
l’Authentificateur,
Figure 19: Exemple de dialogue sans authentificateur, Supplicant en mode passif.
• Emettre une requête EAPOL-Start qui va demander à l’Authentificateur de commencer le processus.
Figure 20: Exemple de dialogue sans authentificateur, Supplicant en mode actif.
Dans tous les cas le Supplicant ne recevra pas de réponse. Il arrêtera d’essayer de s’authentifier et se connectera au réseau.
6.3.4. Scénario 4 : Pas de serveur d’authentification
Dans ce dernier scénario le Supplicant et l’Authentificateur sont bien présents mais il manque le serveur d’authentification ou celui-ci est injoignable.
Lors des premières implémentations du protocole ce cas faisait que le port de l’Authentificateur était systématiquement laissé à l’état non-autorisé. Désormais le Supplicant peut être placé dans un vlan Guest ou autorisé à accéder au réseau selon la configuration de l’Authentificateur.
Figure 21: Exemple de dialogue sans serveur d'authentification.