Mise en place d'un système de sécurité dans un hôpital avec le serveur radius. Cas de l'hôpital saint Joseph de Kinshasa.

II.2. Les Extensions du Protocole Radius

Le protocole Radius d'origine a été étendu afin de le rendre compatible, d'une part avec l'utilisation des réseaux virtuels et, d'autre part, avec les protocoles 802.1X et EAP. Ces apports font de Radius un protocole désormais capable de réaliser des authentifications sur des réseaux locaux.

Nous verrons comment les réseaux virtuels sont mis en jeu. Nous détaillerons comment EAP est architecturé, comment il transporte les protocoles d'authentification et comment Radius transporte EAP.

Nous parcourrons tous les mécanismes mis en oeuvre depuis le branchement (ou l'association) d'un poste de travail sur le réseau, jusqu'au moment de son authentification. Nous verrons également, pour les réseaux sans fil, comment est amorcé le chiffrement des communications de données.

2.1. Les Réseaux Virtuels (VLAN)

Dans Radius, la compatibilité avec la technologie des VLAN est en fait réalisée au travers du support des tunnels (RFC 2868). Cette RFC spécifie comment il est possible d'établir des tunnels de différents types entre un client et un serveur Radius. Elle définit douze types de tunnels et introduit un certain nombre de nouveaux attributs. Cependant, cette RFC ne mentionne pas directement les VLAN.

Cette notion apparaît dans la RFC 3580 qui décrit les spécifications d'usage de 802.1X avec Radius. C'est ici qu'est introduit un treizième type de tunnel : le VLAN. La définition de ce type particulier de tunnel s'opère grâce à trois attributs, déjà définis par la RFC 2868, et auquel un treizième type (VLAN) a été ajouté. Ces attributs sont :

Ø Tunnel-Type : la valeur est VLAN ou 13 ;

Ø Tunnel-Medium-Type: la valeur est 802 pour indiquer qu'il s'applique à un réseau de type IEEE 802 (Ethernet, Token Ring, Wi-Fi) ;

Ø Tunnel-Private-Group-Id: la valeur est le numéro de VLAN qui doit être affecté au port sur lequel est connecté le poste de travail.

Ils ne sont pas spécifiquement liés à l'utilisation de 802.1X et sont pleinement utilisables pour l'authentification Radius-MAC. Jusqu'ici, nous avons vu des attributs liés au processus d'authentification (User-Name, Calling-Station-Id) et émis par les NAS dans les paquets Access-Request, alors que les attributs de type Tunnel sont liés aux autorisations qui seront délivrées par le serveur. Ils seront émis dans les paquets Access-Challenge ou Access-Accept.

26

Le protocole EAP est utilisé pour transporter le protocole d'authentification qu'on veut utiliser (TLS, PEAP...). Nous allons maintenant étudier la structure d'EAP et les différentes phases des échanges.

EAP est un protocole qui place trois couches au-dessus la couche liaison, IEEE 802. C'est là qu'intervient le code logiciel du supplicant. Lorsque l'authentification sera terminée, ces couches EAP resteront en place car elles seront utiles pour gérer, par exemple, les réauthentifications ou encore la rotation des clés GTK qui sera vue au paragraphe « Spécificités Wi-Fi : la gestion des clés de chiffrement et WPA ». Quatre types de paquets sont utilisés pour le protocole EAP :

· Request ;

· Response ;

· Success ;

· Failure.

Elle reçoit et envoie les paquets vers la couche basse et transmet les paquets de type Request, Success et Failure à la couche EAP Peer. Les paquets Response sont transmis à la couche EAP Authenticator »Les couches EAP Peer et EAP Authenticator La couche EAP Peer est implémentée sur le poste de travail, tandis que la couche EAP Authenticator est implémentée sur le NAS et sur le serveur Radius. Ces couches ont pour rôle d'interpréter le type de paquet Request ou Response et deles diriger vers la couche EAP Method correspondant au protocole d'authentification utilisé (par exemple, TLS).

La couche EAP Method

C'est dans cette couche que se tient le code logiciel du protocole d'authentification utilisé. Le NAS n'a pas besoin de cette couche puisqu'il agit de façon transparente (sauf si le serveur Radius est embarqué dans le NAS).

Le rôle du NAS est d'extraire le paquet EAP qui lui arrive du supplicant et de le faire passer dans la couche Radius (et vice versa). Pour cela, il doit encapsuler, c'est-à-dire écrire, le paquet EAP dans un attribut particulier de Radius qui a été ajouté au modèle d'origine pour cette fonction. Il s'agit de l'attribut EAP-Message (numéro 79).

Un autre attribut, Message-Authenticator (numéro 80), a été ajouté. Cependant, nous ne nous appesantirons pas plus sur cet attribut qui possède, à peu près, la même fonction que le champ authenticator vu au chapitre 5, à savoir assurer l'intégrité des paquets EAP.

Cet attribut sera présent dans tous les paquets échangés entre le NAS et le serveur mais n'influe pas sur la compréhension globale du protocole. Du côté du serveur Radius, c'est un module spécifique qui décapsulera la valeur de l'attribut EAP-Message et qui l'interprétera en suivant le modèle de couches d'EAP vu plus haut¹².

On peut découper le protocole EAP en quatre étapes que nous baptiserons :

· Identité externe.

· Négociation de protocole.

· Protocole transporté.

12 https://loufida.com/fonctionnement-de-lauthentification-basee-sur-le-port-ieee-802-1x-dot1x/

27

Gestion des clés de chiffrement. 2.2.1. Le protocole EAP/TLS

TLS dispose de trois fonctions : l'authentification du serveur, l'authentification du client et le chiffrement. Le chiffrement dont il est question ici a pour but de créer un tunnel protégé dans lequel passeront les données sensibles une fois que l'authentification sera faite.

Il s'agit du même principe mis en oeuvre lorsqu'on utilise une URL du type https:// dans un navigateur Internet. Dans notre cas, ce tunnel aura une fonction légèrement différente. Il s'agit de protéger l'authentification elle-même lorsque cela est nécessaire. Par exemple, avec les protocoles PEAP et TTLS pour lesquels il faut protéger les échanges d'authentification du mot de passe.

Avec EAP/TLS, ce tunnel ne sera pas utilisé puisque l'authentification est déjà réalisée avec les certificats qui servent à créer le tunnel. TLS est un protocole d'authentification mutuelle par certificat du client (le supplicant) et du serveur.

Chacun doit donc posséder un certificat qu'il envoie à l'autre qui l'authentifie. Cela impose donc l'existence d'une IGC (Infrastructure de Gestion de Clés). Si elle n'existe pas, il est possible d'en créer une assez facilement.