Plusieurs clés de chiffrement statiques sur le même réseau Wi-Fi ? Découvrez avec nous comment dans cet article avec Cisco Identity Pre-Shared Key (IPSK).
De plus en plus de terminaux requièrent aujourd’hui une connexion Wi-Fi sans pouvoir supporter une authentification forte en 802.1X. Pour ne pas connecter ces objets à des réseaux complètement ouverts et garder un minimum de chiffrement des trames radio, les administrateurs réseaux optent souvent pour des WLANs à base de WPA2 PSK. Cependant, avec un SSID à base de WPA2 PSK, par défaut tous les terminaux doivent se connecter avec la même clé partagée. Si un terminal est perdu ou volé, la clé partagée peut être potentiellement récupérée par un utilisateur malveillant, qui pourrait ensuite l’exploiter pour déchiffrer le trafic de tous les autres terminaux du même SSID en WPA2 PSK. Pour éviter ce genre de faille de sécurité, une pratique courante consiste à changer la clé partagée du SSID dès qu’un terminal est perdu ou volé. L’inconvénient de cette procédure est que, mis à part la configuration du SSID lui-même, la clé partagée doit être également reconfigurée sur tout le parc des terminaux concernés, avec des coûts opérationnels non négligeables.
Pour répondre à ce type de défis Cisco a introduit la fonction Identity Pre-Shared Key (IPSK).
Le principe de Cisco IPSK consiste à pouvoir supporter sur le même SSID en WPA2 PSK plusieurs terminaux avec des clés différentes.
Même si techniquement possible, l’objectif final n’est pas d’avoir une clé unique par terminal, mais plutôt de déployer différents groupes / profils / sites / etc. de terminaux avec la même clé partagée au sein du même groupe / profil / site / etc., tout en gardant des clés différentes entre différents groupes / profils / sites / etc. De cette manière, si un terminal est perdu ou volé, toujours pour les mêmes raisons de sécurité décrites ci-dessus, on peut se limiter à changer la clé partagée uniquement pour les autres terminaux du même groupe / profil / site / etc., mais pas pour l’ensemble des terminaux se connectant au même SSID en WPA2 PSK.
Quand on configure un SSID pour IPSK, le contrôleur wireless envoie des requêtes RADIUS à un serveur d’authentification pour authentifier l’adresse MAC du terminal qui est en train de se connecter. Le serveur RADIUS pourrait en effet authentifier chaque adresse MAC, si renseignée dans une base interne/externe par exemple : dans ce cas-là on parlerait de IPSK par groupes d’adresses MAC ou par terminal. Mais le serveur RADIUS peut également accepter la requête d’authentification envoyée par le contrôleur sur la base d’autres conditions, sans forcément vérifier l’adresse MAC.
Par exemple, au lieu qu’authentifier l’adresse MAC complète, le serveur RADIUS peut juste valider qu’elle commence avec les trois octets, ou OUI (Organizationally Unique Identifier), d’un constructeur bien précis. Dans ce cas-là on peut parler d’une clé partagée par constructeur / marque de terminaux.
Dans d’autres cas, nous pouvons en alternative valider d’autres paramètres, envoyés par le contrôleur Wi-Fi dans des attributs RADIUS standardisés. Dans l’attribut RADIUS [30] Called-Station-Id le contrôleur Wi-Fi peut injecter des informations comme le nom de l’AP, l’AP Group, le FlexConnect Group, la location d’un AP, etc. De cette manière, sans même devoir confirmer l’adresse MAC d’un terminal, mais juste en validant que l’attribut RADIUS [30] Called-Station-Id contient une valeur bien précise, correspondant par exemple au nom du site de connexion du terminal, nous pouvons attribuer une clé partagée unique pour tous les terminaux se connectant à notre SSID IPSK depuis un site précis.
La solution RADIUS de contrôle d’accès Cisco Identity Services Engine (ISE), par exemple, peut utiliser toutes ces informations (adresse MAC, OUI, Called-Station-Id) et d’autres encore dans les politiques d’autorisation pour confirmer la clé d’un terminal, comme par exemple le profiling aussi.
Une fois l’OUI / le Called-Station-Id / le profil / etc. validé, le serveur RADIUS répond au contrôleur wireless avec un Access-Accept contenant les deux attributs RADIUS pour confirmer la clé de connexion du terminal :
cisco-av-pair=psk-mode=[ascii | hex] cisco-av-pair=psk=<PSK_value>
La valeur de la clé (<PSK_value>) est utilisée par le contrôleur Wi-Fi pour connecter le terminal, qui doit lui aussi être configuré avec cette même clé. Si le serveur RADIUS répond avec un Access-Accept et sans retourner une PSK, le contrôleur utilise la PSK configurée statiquement dans le WLAN. Si le serveur RADIUS répond avec un Access-Reject, le terminal n’est pas autorisé à se connecter.
IPSK permet enfin une gestion plus sécurisée et simplifiée des parcs de terminaux ne pouvant pas supporter le 802.1X et pour lesquels on requiert toujours un réseau wireless chiffré. Tous les détails techniques sur la configuration de cette fonction sont disponibles dans le guide de déploiement dédié :
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-8/b_Identity_PSK_Feature_Deployment_Guide.html
Authors