François MORRIS Francois.Morris@lmcp.jussieu.fr 10/09/2004
Ce document est disponible en html : http://www.lmcp.jussieu.fr/~morris/802.1X/mobile.html et en PDF : http://www.lmcp.jussieu.fr/~morris/802.1X/mobile.pdf
Ce document présente les résultats des expériences que j’ai effectuées en matière d’authentification 802.1X à la fois en filaire et en sans fil. Les matériels et logiciels utilisés furent :
Point d’accès sans fil Netgear WG302 (Firmware 2.0.3)
Carte Netgear WG511T
Commutateur Cisco Catalyst 3550
Serveur Radius freeradius (1.0.0-pre3) sur un système Linux
PC sous Windows 2000
PC sous Windows XP
PC sous Linux (Fedora Core 2)
La norme IEEE 802.1X permet s’authentifier de façon sûre un matériel connecté sur le réseau, ce qui n’est pas le cas avec la seule adresse MAC qui peut facilement être usurpée.
Dans le cadre d’un réseau filaire avec des commutateurs adaptés, il est possible d’affecter de façon dynamique au matériel qui se connecte des éléments régissant les contrôles d’accès comme le numéro de VLAN ou même des filtres.
Dans le cas d’un réseau sans fil, WPA ou la future norme 802.11i qui permettent de pallier les graves problèmes de sécurité liés au WEP reposent sur une authentification 802.1X
Pour plus d’informations sur les protocoles on pourra se reporter au tutoriel de JRES2003 http://2003.jres.org/TUTORIELS/paper.AA.pdf (texte), http://2003.jres.org/TUTORIELS/paper.A.pdf (diapos) et
http://pc-media.univ-valenciennes.fr:8080/ramgen/jres2003/VPN.rm (vidéo).
Si pour authentifier le poste de travail (supplicant) il est possible d’utiliser soit un certificat, soit un classique couple identifiant, mot de passe, pour le serveur if faut obligatoirement utiliser un certificat. Dans tous les cas le minimum à effectuer est d’installer sur le poste de travail les certificats et éventuellement les CRL du CA racine et des CA intermédiaires.
Sous Windows il existe 3 magasins de certificats associés respectivement
Au compte de l’utilisateur
Au compte du service
Au compte de la machine
Nous verrons par la suite que suivant le cas on utilise le premier ou troisième magasin.
En prenant l’exemple de l’IGC du CNRS, pour introduire les certificats CA ainsi que les CRL dans le magasin lié au compte de l’utilisateur, il possible avec Internet Explorer de se connecter à l’URL suivante
http://igc.services.cnrs.fr/CNRS-Standard/recherche.html
en cliquant sur « Certificat CA » on fait apparaître la fenêtre suivante et il suffit de cliquer sur « Chargement dans le navigateur » pour les 2 certificats.
Un assistant va permettre d’installer le certificat le plus important est le message suivant
Il ne faut pas rêver, peu d’utilisateurs vont lire ce message et encore moins vérifier que l’empreinte du certificat (sha1) correspond bien à celle connue par ailleurs et transmise par un canal sûr. Pourtant il y a un réel risque aux conséquences gravissimes si lors de la connexion non sécurisée un éventuel pirate a remplacé le certificat du CA du CNRS par le sien.
En outre ces certificats devant être installés préalablement à toute authentification sur le réseau comment fait-on puisque l’on n’a pas accès au réseau.
Une solution possible consiste à les installer à partir d’un CD. Nous décrirons plus loin quelques exemples de procédures permettant de réaliser cette opération.
L’avantage du CD est qu’il est possible de le transmettre en mains propres ce qui constitue un canal sûr.
L’installation d’un certificat dans le magasin lié au compte de la machine est plus délicat. Il faut en effet utiliser la console mmc.
Au moins sous Windows et avec les outils standard gérant 802.1X (d’autres produits peuvent être plus ou moins stricts) le certificat du supplicant doit avoir les caractéristiques suivantes :
X509v3 Extended Key Usage : TLS Web Client Authentication. Sinon le système Windows est incapable de trouver un certificat à fournir au serveur Radius. Si on utilise un certificat sur une carte à puce, il doit aussi contenir la valeur Smartcard Logon (oid=1.3.6.1.4.1.311.20.2.2)
Netscape Cert Type : SSL Client. Ce n’est bien évidemment pas requis par Windows mais la bibliothèque openssl employée par freeradius exige que si « Netscape Cert Type » existe, même si X509v3 Extended Key Usage est défini à X509v3 Extended Key Usage, il doit avoir entre autre la valeur SSL Client.
« Subject Alternative Name » doit contenir l’identifiant EAP envoyé au serveur. Dans le cas d’une authentification au démarrage il s’agit d’une valeur de type DNS. Dans le cas d’une authentification après le logon il s’agit de l’identifiant de l’utilisateur rangé dans une valeur de type MSUPN (Microsoft Universal Principal Name). En cas d’absence de ces valeurs l’identifiant est formé en prenant le CN du champ Subject.
Pour le serveur Radius on doit avoir les caractéristiques suivantes :
X509v3 Extended Key Usage : TLS Web Server Authentication.
Netscape Cert Type : SSL Server. Même si ce n’est pas nécessaire cela ne fait pas de mal de l’ajouter.
Subject Alternative Name doit contenir une valeur de type DNS spécifiant l’identité du serveur Radius. C’est utilisé par le supplicant pour vérifier que le serveur fait bien partie d’une liste de ceux qui sont autorisés. Du moins je le présume, car comme le DNS dans Subject Alternative Name était le même que le CN dans Subject, j’ai un petit doute sur celui qui est réellement utilisé. De toute façon ce n’est pas grave car spécifier le nom de machine à la fois dans Subject et Subject Alternative Name est une sage politique.
Avec le supplicant fourni en standard par Microsoft sous Windows 2000 ou XP il est possible d’utiliser 2 méthodes d’authentification EAP-TLS et PEAP.
L’authentification se fait au démarrage de la machine ou/et au logon de l’utilisateur. Le comportement est fixé par la valeur d’une clé dans le registre
HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global\AuthMode
0 (c’est la valeur par défaut) authentification de la machine au démarrage, en cas d’échec authentification de l’utilisateur au logon
1 authentification de la machine au démarrage, puis authentification de l’utilisateur au logon
2 uniquement authentification de la machine
Cependant l’authentification de la machine au démarrage n’aura lieu que si la case « Authentifier en tant qu’ordinateur lorsque les informations de l’ordinateur sont disponibles » est cochée dans la fenêtre suivante :
Il est ainsi possible de définir quand aura lieu l’authentification 802.1X. Nous verrons par la suite que seuls certaines de ces combinaisons sont fonctionnelles ou possèdent un réel intérêt.
Afin de paramétrer correctement le serveur RADIUS, il faut noter certains points.
L’ User-Name envoyé au serveur RADIUS lors d’une authentification de la machine au démarrage est préfixé par la chaîne host/ . Pour une authentification au logon il n’est pas préfixé.
Dans le cas d’une authentification EAP-TLS, User-name est si elle existe la valeur dns du champ Subject Alternative Name du certificat sinon de la valeur CN dans le Subject . User-Name est le cas échéant préfixé par host/ .
Dans le cas d’une authentification PEAP au démarrage User-Name est le nom de la machine tel qu’il est défini dans Windows préfixé par host/.
Dans le cas d’une authentification PEAP au logon en fonction de la configuration, 2 cas sont possibles
User-Name est l’identifiant préfixé par nom\\ où nom est le nom de la machine tel qu’il est défini dans Windows, ayant servi au logon, le mot de passe transmit au serveur RADIUS est celui qui a servi à authentifier la session Windows (case cochée dans la fenêtre ci-dessus).
User-Name ainsi que le mot de passe sont spécifiés dans une fenêtre. En cas d’authentification réussie ces informations sont mémorisées dans le profil de l’utilisateur et ne seront jamais plus demandées lors d’une connexion ultérieure. Si le mot de passe a changé entre temps, l’authentification échoue et la fenêtre est alors de nouveau présentée ce qui permet de donner le nouveau mot de passe.
Le certificat utilisé pour l’authentification au démarrage est celui situé dans le magasin lié au compte de la machine. Pour l’authentification au logon, il s’agit de celui situé dans le magasin lié au compte de l’utilisateur. Attention il n’est pas possible d’activer la « protection renforcée de la clé ». L’option est invalidée pour un certificat lié à la machine et l’authentification 802.1X ne fonctionne pas si on cherche à l’utiliser pour un certificat lié à l’utilisateur. En fonction du moment de l’authentification choisi il faudra installer le certificat dans l’un ou l’autre magasin. Si comme nous l’avons vu ci-dessus, il est simple d’installer à partir d’un fichier PKCS#12 un certificat dans le magasin lié au compte de l’utilisateur. En effet il suffit de cliquer deux fois sur le fichier pour obtenir un assistant. Par contre il est nécessaire d’utiliser la console mmc pour installer un certificat lié au compte de la machine ce qui est beaucoup plus délicat. Il est bien sûr possible d’installer le certificat dans les deux magasins.
Avec PEAP seule l’authentification après le logon est utilisable. De fait, j’ai constaté qu’il était bien possible d’initier une authentification au démarrage de la machine avec comme identifiant le nom Windows de la machine mais je n’ai trouvé aucun moyen de fournir le mot de passe, aucune fenêtre n’étant ouverte pour le demander.
La norme de réseau sans fil 802.11 prévoie une méthode de sécurisation WEP (Wired Equivalent Privacy) qui s’est avéré ne pas répondre du tout aux besoins. Une nouvelle norme 802.11i est en cours d’élaboration au sein de l’IEEE. Elle est sensée résoudre tous les problèmes de sécurité constatés avec le WEP. WiFi est une alliance commerciale destinée à promouvoir le sans fil. Au sein de cette alliance il a été défini une norme provisoire de sécurisation du sans fil WPA (Wi-Fi Protected Access) qui reprend en partie les travaux en cours au sein de l’IEEE dans le cadre de la norme 802.11i.
WPA utilise deux méthodes pour sécuriser les échanges TKIP (Temporary Key Integrity Protocol) qui utilise RC4 comme algorithme de chiffrement et CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) qui lui utilise AES. La première méthode permet de réutiliser le matériel existant pour le WEP avec seulement un changement du micro-code tandis que la deuxième impose un matériel spécifique. Cette dernière est quelquefois appelé WPA2.
WPA utilise 802.1X comme méthode d’authentification. Cependant il a été prévu de conserver un mécanisme d’authentification par secret pré-partagé (WPA-PSK) pour faciliter le déploiement dans de petites structures. Nous verrons par la suite les limites de ce dernier mécanisme.
Il s’agit du cas particulier de l’authentification 8021x appliquée à la sécurisation des liaisons sans fil. Par rapport à ce qui a été traité précédemment nous ne décrirons que ce qui diffère notablement.
Sous Windows XP (il faut une version de Windows XP avec des mises à jours suffisamment récentes), il est possible d’utiliser le supplicant fourni en standard pour faire du WPA à condition que le firmware et le pilote de la carte réseau soient prévus pour. Sous Windows 2000 il n’existe pas d’interface avec le supplicant pour faire du WPA, il faut donc un outil d’une tierce partie. Les méthodes d’authentification sont limitées à EAP-TLS et PEAP en utilisant mschap-v2.
Des produits comme Odyssey de Funk (http://www.funk.com/) ou AEGIS de MeetingHouse (http://www.mtghouse.com/) supportent la plupart des méthodes d’authentification, les anciennes versions de Windows (95, 98, ME, NT, 2000, XP) et un plus grand nombre de cartes réseaux.
L’outil d’administration fournie avec la carte réseau utilisée (Netgear WG511T) permet uniquement de faire du WPA PSK (Pre Shared Key). Sous Windows XP (mais pas 2000) il est possible de faire du WPA (EAP-TLS ou PEAP) en utilisant les outils standards à la condition de ne pas utiliser l’outil d’administration de Netgear. Lors de l’installation il faut cliquer sur « No » dans la fenêtre suivante. Il est bon aussi de cocher la case pour ne plus avoir à répondre à la question à chaque démarrage.
Pour configurer on procédera la façon suivante :
A partir de « Propriétés réseau » on visualise l’onglet « Wireless Network »
On clique alors sur « Add… » pour faire apparaître une fenêtre dans laquelle on spécifie le « SSID » du réseau ici R3UP5, la méthode d’authentification « WPA » ainsi que la méthode de chiffrement « TKIP ».
On clique alors sur l’onglet « Authentification ». Dans un premier temps on va utiliser la méthode PEAP qui est propriétaire Microsoft. Dans ce contexte cocher l’une ou l’autre des cases suivantes n’a pas grand sens, puisque l’authentification va se faire avec un identifiant et un mot de passe fourni par l’utilisateur et il faut bien que celui-ci soit déjà en session.
On clique alors sur « Properties ». Il faut valider le certificat du serveur sinon on perd tous les bénéfice d’une authentification mutuelle et il serait possible de se connecter à une borne d’accès pirate. Le seul cas où on peut se passer de cette validation est lors d’essais préliminaires avant l’installation de certificats. Il faut préciser les CA dont on accepte les certificats, ici CNRS. Il est aussi souhaitable de préciser les serveurs sur lesquels on va s’authentifier. En effet le comportement des outils Microsoft est tel que si un réseau sans fil est visible on peut très facilement par mégarde se connecter dessus et dans un contexte de campus il fort possible que ce soit le réseau du laboratoire d’à côté qui a un certificat délivré par le même CA. Le nom du serveur Radius est celui spécifié dans le certificat envoyé par le serveur (attribut dns de Alternative Subject Name ou à défaut CN de Subject Name). Il ne s’agit pas du nom associé à l’adresse IP du serveur et fourni par le DNS, d’ailleurs le client ne communique pas directement avec le serveur et seul le point d’accès connaît cette adresse. La plus élémentaire des précaution impose d’assurer la redondance des serveurs Radius et il est judicieux de leur attribuer le même certificat, ainsi il suffira de préciser un seul nom dans la liste des serveurs. La méthode d‘authentification est « EAP-MSCHAP v2 », je ne vois pas l’intérêt d’utiliser un certificat dans un tunnel PEAP alors qu’il existe EAP-TLS.
Si on ne précise pas le nom des serveurs Radius mais que l’on demande de valider le nom du serveur alors il apparaîtra lors de l’utilisation une bulle dans la barre des tâches demandant de cliquer pour faire apparaître la fenêtre suivante
Il faut configurer l’authentification en cliquant sur « Configure… ». Il ne faut pas cocher la case suivante.
En effet l’identifiant et le mot de passe utilisés au logon correspondent à une authentification locale sur la machine et non pas un logon à travers le réseau sur un domaine puisque par définition lors de l’authentification 802.1X on n’a pas encore accès au réseau. Il n’y a aucune raison pour que les identifiant, mot de passe utilisés pour une session locale soit les mêmes que ceux pour authentifier l’utilisateur sur le réseau. J’ajouterais que c’est à éviter.
Lors de l’utilisation apparaîtra une fenêtre demandant l’identifiant et le mot de passe. En cas d’authentification fructueuse ceux-ci sont mémorisés et ne seront pas demandés pour une connexion ultérieur au réseau. Si le mot de passe a changé sur le serveur, l’authentification ne peut aboutir et la fenêtre sera présentée comme précédemment pour une nouvelle tentative.
Pour utiliser EAP-TLS comme méthode d’authentifications on sélectionne « Smart Card or other Certificate ».
On clique sur le bouton « Properties » pour faire apparaître la fenêtre suivante. Comme précédemment il faut valider le certificat du serveur et il serait souhaitable de définir les serveurs autorisés (ce qui n’est pas le cas dans l’exemple ci-dessous). La méthode recommandée de choix du certificat en recherche dans le magasin de certificats un ayant les bons attributs et délivrés par le même CA que le serveur.
J’ai effectué des essais avec les versions d’évaluation de SecureW2 (http://www.securew2.com/uk/) de Alfa & Ariss, Odyssey de Funk (http://www.funk.com/) et Aegis de Meeting House (http://www.mtghouse.com/). Si SecureW2 est gratuit pour un usage non commercial il procède d’une logique un peu différente des 2 autres et supporte un moins grand nombre de méthodes d’authentification, en outre mes premiers essais avec une connexion ethernet filaire se sont révélés infructueux et je n’ai pas poursuivi. Le prix public des deux autres est à l’unité d’environ $50. Je n’ai pas poussé mes investigations suffisamment loin pour déterminer lequel de ces deux derniers est le plus adapté. Par rapport au produit standard de Microsoft Aegis et Odyssey présente les avantages suivants :
Beaucoup plus de méthodes d’authentifications possibles. En plus de PEAP, les tunnels EAP-TTLS sont disponibles. En outre une grande variété de méthodes d’authentification peuvent transiter dans ces tunnels. Mais a-t-on réellement besoin de toutes ces méthodes ?
Fonctionne sur des versions de Windows antérieures à Windows XP.
Supporte plus modèle de cartes réseau notamment des modèles un peu anciens. Pour utiliser WPA sous Windows XP il faut des firmware et des pilotes très récents.
Contrôle plus fin du moment où a lieu l’authentification : démarrage de la machine, logon, affichage du bureau…
Les inconvénients sont :
Le coût et la nécessité d’installer un produit supplémentaire.
La maintenance des produits. Avec Windows cela fait partie de la maintenance générale du système.
Ajoute une couche. On peut espérer que le produit Windows est mieux intégré.
Au cours du temps les nouvelles cartes supporteront WPA et les systèmes antérieurs à XP vont disparaître ce qui diminue l’intérêt de ces produits.
Il faut aussi citer le projet wEAP (http://weap.sourceforge.net/) qui est un projet open source de développement de « plug-ins » pour Windows permettant d’inclure de nouvelles méthodes d’authentification EAP à Windows.
Jusqu’ici nous n’avons traité que de WPA avec une authentification 802.1X aussi appelé par certains « WPA Entreprise ». Il existe une variante de WPA qui utilise comme méthode d’authentification un secret pré partagé « WPA PSK » pour « Pre Shared Key ». Comme toute méthode utilisant un secret partagé, elle est vulnérable à des attaques par force brute ou par dictionnaire.
Alors que dans WPA la PMK (Pairwise Master Key) est définie en fonction de paramètres échangés lors de l’établissement de TLS, dans WPA-PSK elle est définie comme un fonction cryptographique du secret partagé. Un pirate à l’écoute du réseau peut récupérer les premiers paquets d’une connexion et chercher à retrouver le secret partagé. Il faut bien noter que l’attaque se fait hors ligne et laisse donc du temps pour essayer de nombreux secrets partagés. Cela étant dit, il s’agit de la seule faiblesse connue de WPA-PSK, les fragilités du WEP ayant été corrigées.
Pour un usage dans à domicile ou dans une petite structure il n’est pas envisageable de mettre en œuvre un serveur Radius ainsi que des certificats et alors WPA-PSK s’impose. La seule précaution consiste à utiliser un secret suffisamment robuste. Il est couramment admis qu’il faut choisir au moins une vingtaine de caractères. Evidemment la difficulté consiste à entrer le secret sur les différents éléments du réseau. En utilisant judicieusement le « copier coller » et un support amovible comme une disquette, un CD ou une clé USB pour les échanges ce n’est pas insurmontable.
Je tiens à rappeler qu’il est impossible d’utiliser cette méthode au delà d’un groupe restreint. Que l’on songe à l’opération qui consiste à changer le secret sur l’ensemble des matériels concernés !
wpa_supplicant (http://hostap.epitest.fi/wpa_supplicant/) est un produit qui permet de faire du WPA sous Linux. J’ai effectué les essais avec un distribution Linux Fedora core 2. Comme j’utilise une carte Netgear WG511T (composant Atheros) j’ai dû récupérer le pilote correspondant madwifi (http://sourceforge.net/projects/madwifi/). Attention il faut utiliser la branche « WPA » de madwifi (argument –r WPA dans la commande CVS). La compilation et l’installation de ces deux produits n’a posé aucun problème.
J'ai effectués des essais avec comme méthode d'authentification EAP-TLS et PEAP +MSCAHP-v2
J'extrais du fichier de configuration /etc/wpa_supplicant.conf les lignes significatives, tout d'abord pour EAP-TLS
network={
ssid="R3UP5"
proto=WPA
key_mgmt=WPA-EAP
pairwise=CCMP TKIP
group=CCMP TKIP
eap=TLS
identity="portable-morris.lmcp.jussieu.fr"
ca_cert="/etc/cert/CNRS.pem"
client_cert="/etc/cert/portable-morris.pem"
private_key="/etc/cert/portable-morris.key"
private_key_passwd="***********"
}
ensuite pour PEAP + MSCHAPv2
network={
ssid="R3UP5"
key_mgmt=WPA-EAP
eap=PEAP
identity="morris"
password="***********"
ca_cert="/etc/cert/CNRS.pem"
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}
Il faut noter qu'actuellement la seule façon de spécifier les certificats CA est de les regrouper dans un fichier PEM. Il n'est pas possible d'utiliser un répertoire. De même les listes de révocation ne sont pas gérées. Il n’y a pas non plus de contrôle sur les serveurs autorisés. Enfin le mot de passe protégeant la clé privée doit être fourni en clair dans le fichier de configuration (ce fichier doit donc impérativement n’être accessible qu’uniquement à son propriétaire). Les modifications à apporter pour corriger ces problèmes ne sont pas très compliquées mais comme nous le verrons par la suite pas forcément nécessaires.
Le point un peu délicat consiste au lancement de l'application wpa_suuplicant au bon moment lors de l'initialisation de l'interface. Pour ne pas avoir à modifier les scripts existants j'ai créés les 2 scripts suivants qui sont appelés automatiquement s’il existe par ifup et ifdown.
/sbin/ifup-pre-local
#!/bin/sh
. /etc/init.d/functions
cd /etc/sysconfig/network-scripts
. network-functions
CONFIG=$(basename $1)
[ -f "${CONFIG}" ] || CONFIG=ifcfg-${1}
source_config
# Wireless WPA
if is_wireless_device ${DEVICE} && [ "$WPA" = yes ]; then
echo "DEBUG Wireless WPA"
[ -x /usr/local/bin/wpa_supplicant ] && /usr/local/bin/wpa_supplicant \
-Bw -c/etc/wpa_supplicant.conf -i$DEVICE
fi
et
/sbin/ifdown-local
#!/bin/sh
echo "DEBUG ifdown-local"
. /etc/init.d/functions
cd /etc/sysconfig/network-scripts
. network-functions
PIDPATH=/var/run
XSUP_PID="${PIDPATH}/xsupplicant-$1"
CONFIG=$(basename $1)
[ -f "${CONFIG}" ] || CONFIG=ifcfg-${1}
source_config
# Wireless wpa_supplicant
# Is the device wireless? If so kill wpa_supplicant
if is_wireless_device ${DEVICE} && [ "$WPA" = yes ] ; then
echo "DEBUG Wireless WPA"
[ -x /usr/local/bin/wpa_supplicant ] && killall wpa_supplicant
exit
fi
Le fichier de configuration de l'interface est
/etc/sysconfig/network-script/ifcfg-ath0
IPV6INIT=no
ONBOOT=no
USERCTL=yes
PEERDNS=yes
TYPE=Wireless
DEVICE=ath0
HWADDR=00:09:5b:c1:e1:ee
BOOTPROTO=dhcp
NETMASK=255.255.255.0
ESSID=R3UP5
MODE=Managed
RATE=Auto
WPA=yes
Xsupplicant est la partie supplicant du projet open1x (http://www.open1x.org/). Il gère le protocole 802.1X pour réseau filaire mais aussi pour réseau sans fil.
La compilation et l'installation a été immédiate.
Le principe est le suivant un programme xsupplicant va surveiller les interfaces et intercepter les trames EAP.
J'extrais du fichier de configuration
/etc/xsupplicant.conf
les informations significatives ou plus exactement celles que j'ai eu à modifier.
Tout d’abord pour eap-tls
identity = <BEGIN_ID>portable-morris.lmcp.jussieu.fr<END_ID>
eap_tls {
user_cert = /etc/cert/portable-morris.pem
user_key = /etc/cert/portable-morris.key
user_key_pass = <BEGIN_PASS>***********<END_PASS>
root_cert = /etc/cert/CNRS.pem
root_dir = /etc/cert/CA
crl_dir = /etc/cert/CRL
cncheck = radius.lmcp.jussieu.fr
cnexact = yes
chunk_size = 1398
random_file = /dev/urandom
}
Ensuite pour peap
identity = <BEGIN_ID>morris<END_ID>
eap-peap {
root_dir = /etc/cert/CA
crl_dir = /etc/cert/CRL
cncheck = radius.lmcp.jussieu.fr
cnexact = yes
chunk_size = 1398
random_file = /path/to/random/source
allow_types = all
eap-mschapv2 {
# username = <BEGIN_UNAME>morris<END_UNAME>
password = <BEGIN_PASS>**********<END_PASS>
}
}
Il faut noter qu’il n’est pas nécessaire de spécifier username puisque la valeur définie dans identity est reprise par défaut.
Evidemment la présence du mot de passe en clair dans le fichier de configuration n’est pas satisfaisante. Il faut au minimum attribuer des droits à ce fichier de configuration de telle sorte que seul son propriétaire puisse y accéder. Il est possible de ne pas spécifier le mot de passe (user_key_pass ou password). Des outils fournis avec xsupplicant permettent de fournir dynamiquement le mot de passe au programme xsupplicant. En particulier qt_gremlin_xsupplicant ouvre une fenêtre lorsqu’un mot de passe est nécessaire. C’est bien adapté lorsque l’authentification 802.1X a lieu après le logon de l’utilisateur. Pour une authentification au démarrage de la machine on peut utiliser xsup_monitor un programme en mode ligne. Une solution pourrait être de mettre les fichiers de configuration dans un système de fichiers chiffré.
Le point un peu délicat est qu’il faut démarrer xsupplicant après l’initialisation de l’interface mais avant le lancement de dhcp. Sur une distribution Fedora core 2 j’ai crée les scripts /sbin/ifup-pre-local (http://www.lmcp.jussieu.fr/~morris/802.1X/ifup-pre-local) et /sbin/ifdown-local (http://www.lmcp.jussieu.fr/~morris/802.1X/ifdown-local) qui sont appelés respectivement par ifup à l’activation de l’interface et ifdown à la désactivation. Je n’ai donc pas eu à modifier les scripts existants ce que je souhaitais éviter à tout prix pour ne pas avoir de soucis lors de mises à jour.
Avec l’option –W xsupplicant peut gérer la partie authentification 802.1X de wpa_supplicant qui doit alors être démarré avec l’option –e. J’ai choisi ce mode fonctionnement car xsupplicant offre actuellement davantage de fonctionnalités que wpa_supplicant : listes de révocation, dialogue pour le mot de passe, contrôle des serveurs Radius autorisés.
Attention au moins avec le matériel et la distribution de Linux que j’utilise, il faut obligatoirement affecter une valeur à la variable KEY dans le fichier /etc/sysconfig/network-scripts/ifcfg-<device>. Sinon le script de démarrage désactive le chiffrement. La valeur n’a aucune importance, en effet la clé sera remplacée dynamiquement par le mécanisme WPA lors de l’authentification.
J’utilise comme serveur Radius freeradius (http://www.freeradius.org) version 1.0.0 sur un système linux. Comme je n’avais pas au préalable de serveur Radius, ce choix m’a semblé le plus adapté. Ce serveur offre de nombreuses possibilités en contre-partie les fichiers de configuration sont assez complexes. Je ne décrirai que les directives sur lesquelles j’ai dû intervenir lors de mes essais. La configuration spécifique à EAP se trouve dans le fichier eap.conf. Attention un certain nombre de méthodes comme EAP-TLS ou PEAP sont commentés par défaut.
La directive
default_eap_type =
spécifie la méthode d’authentification préférée par le serveur. Si le supplicant supporte cette méthode il va l’utiliser sinon il répondra par un rejet en précisant les méthodes qu’il supporte. Comme souvent le supplicant ne peut être configuré que pour une seule méthode à la fois, l’intérêt de paramètre est assez limité.
Les directives certificate_file, private_key_file, private_key_password spécifient le certificat et la clé privée du serveur Radius. La meilleure méthode pour spécifier les certificats des CA est de les mettre dans le répertoire défini par CA_path. Ce répertoire contiendra aussi les CRL. Ne pas oublier de faire un « hash » des certificats et CRL
openssl x509|crl –noout –hash …
Il faut ajouter la directive
verify_depth = 5 (par exemple)
lorsque l’on a plusieurs niveaux de CA comme c’est le cas avec l’IGC du CNRS
Pour random_file j’utilise /dev/urandom
Il me semble indispensable de vérifier si le certificat du supplicant n’est pas révoqué. Cela se fait en codant
check_crl = yes
évidemment il faudra récupérer régulièrement les CRL à l’aide d’un cron par exemple.
Dans le cas d’une authentification EAP-TLS il est tout aussi indispensable de vérifier que l’identité présentée par le supplicant dans la requête EAP correspond bien à celle spécifiée dans son certificat. En effet comme nous le verrons par la suite l’attribution des droits se fait sur l’identité de la requête EAP. Cela peut se faire par
check_cert_cn = %{Stripped-User-Name:- %{User-Name}:-none}
Le fichier users définit les autorisations accordées aux différents utilisateurs (les supplicants en l’occurrence).
Pour un fonctionnement de EAP-TLS compatible avec les différentes identités envoyées suivant le contexte par les différents supplicants j’ai utilisé l’astuce suivante. J’ai supprimé dans le fichier radiusd.conf le commentaire de la directive IPASS dans la section « authorize ». De cette façon les requêtes préfixées par host/ seront relayées vers le serveur en supprimant le préfixe. L’identification non préfixée se retrouvera dans la variable Stripped-User-Name, d’où la signification du check_cert_cn ci-dessus. Voici un exemple de directives dans le fichier users :
DEFAULT Auth-Type := EAP, Service-Type == Framed-User
Tunnel-Type = VLAN,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-ID = "guest",
Cisco-AVPair = "ip:inacl#1=permit ip any host 10.3.3.254",
Cisco-AVPair += "ip:inacl#2=permit ip any host 10.3.4.254",
Cisco-AVPair += "ip:inacl#3=deny ip any 10.3.0.0 0.0.255.255",
Cisco-AVPair += "ip:inacl#4=permit ip any any",
Cisco-AVPair += "mac:inacl#5= permit any any 0x800 0x0",
Cisco-AVPair += "mac:inacl#6= permit any any 0x806 0x0",
Cisco-AVPair += "mac:inacl#7= deny any any",
Fall-Through = Yes
Si pour une machine particulière on souhaite changer un attribut comme le VLAN on peut le faire en ajoutant plus bas dans le fichier la directive suivante :
"portable-morris.lmcp.jussieu.fr" Auth-Type := EAP, Service-Type == Framed-User
Tunnel-Private-Group-ID := "groupe2"
Il faut noter que l’on attribue dynamiquement le numéro de VLAN en fonction de l’identité de la machine qui s’est connectée au réseau. En outre les commutateurs utilisés (Cisco Catalyst 3550) permettent de spécifier des filtres sur les différents ports. C’est ce que nous avons utilisé ici pour interdire le trafic entre deux machines située sur le VLAN considéré, seule la communication avec le routeur est autorisée.
Dans ce qui précède nous avons utilisé EAP-TLS comme méthode d’authentification qui repose sur le certificat du client (supplicant). Pour éviter la gestion de ces certificats clients (le certificat sur le serveur est lui toujours requis) on peut faire transiter dans un tunnel sécurisé une classique authentification par identifiant, mot de passe. Nous allons décrire l’utilisation de PEAP avec mschapv2. Certes il s’agit de protocoles spécifiques à Microsoft mais ils ont l’avantage d’être installés en standard sur les systèmes Windows et permettent de réutiliser facilement les mécanisme d’authentification existants. Dans le fichier eap.conf il n’y a pas grand chose à faire si ce n’est que s’assurer que ce qui concerne peap et mschapv2 ne sont pas en commentaire. Dans le fichier users l’identifiant est spécifié comme suit.
"morris" Auth-Type := EAP, Service-Type == Framed-User
Tunnel-Private-Group-ID := "groupe1"
Cette directive n’est nécessaire que si on souhaite pour un utilisateur particulier changer les valeus par défaut comme ici le VLAN.
Pour l’authentification j’utilise le fichier smbpasswd utilisé par samba. Dans le fichier radiusd.conf il faut coder alors dans la section « modules » :
passwd etc_smbpasswd {
filename = /etc/samba/smbpasswd
format = "*User-Name::LM-Password:NT-Password:SMB-Account-CTRL-EXT::"
authtype = MS-CHAP
hashsize = 100
ignorenislike = no
allowmultiplekeys = no
}
et dans la section « authorize » définir
etc_smbpasswd
Il est aussi possible d’utiliser un contrôleur de domaine Windows pour vérifier le mot de passe en codant dans la section mschap l’utilisation de la commande ntlm_auth qui fait partie de samba. Par contre je n’ai pas testé cette possibilité qui peut s’avérer très intéressante dans un environnement où l’on a déjà déployé une authentification Windows.
Le couplage du serveur Radius avec un annuaire LDAP est particulièrement intéressant dans un environnement où les différentes informations concernant les machines et les utilisateurs sont rangées dans l’annuaire LDAP.
Seules un certain nombre de ports et par conséquents de prises RJ45 son configurés pour l’authentification 802.1X. En effet d’une part les commutateurs les plus anciens que nous avons ne la supportent pas, d’autre part pour un serveur en salle machines dont l’accès est contrôlé, l’authentification 802.1X n’apporte rien en matière de sécurité et complique inutilement les choses. Pour les anciens matériels nous utilisons le protocole Cisco VMPS qui permet d’affecter un VLAN en fonction de l’adresse MAC.
Un certains nombre de VLAN sont définis, à chaque VLAN est associé un sous-réseau IP. Le routage et le filtrage s’effectuent sur des commutateurs/routeurs (Cisco Catalyst 3550) ainsi que sur le firewall d’entrée de réseau. Du fait de l’utilisation de classes d’adresses IP privées (le nombre d’adresses IP officielles est relativement limité et ne permet pas de segmenter finement le réseau) pour certains VLAN une traduction d’adresses (NAT) a éventuellement lieu sur le firewall.
Les ports du commutateur concernés par l’authentification 802.1X sont configurés de la façon suivante :
Affection d’un VLAN inutilisé qui n’est jamais routé. Ainsi si à la suite d’une défaillance quelconque ou d’une erreur de configuration le port était activé, aucun trafic ne pourrait sortir de ce VLAN.
Activation de 802.1X
Définition d’un VLAN invité qui sera affecté si le matériel connecté ne répond pas aux requêtes 802.1X. Cela permet d’accepter, avec des privilèges réduits certes, un matériel ne supportant pas 802.1X.
En cas d’échec de l’authentification 802.1X ou tout simplement refus des créances présentées par le supplicant affectation du VLAN invité.
Le serveur Radius est configuré de telle sorte qu’il interroge un serveur LDAP pour déterminer le VLAN à affecter en fonction de l’identifiant fourni par le supplicant ce qui permet de cloisonner le réseau. Par ailleurs une analyse régulière du trafic des différentes machines connectées permet d’estimer si les mises à jour ont étés effectuées. Dans le cas contraire on va forcer la connexion sur un VLAN permettant de se connecter uniquement vers les sites de mise à jour et surtout pas vers le réseau interne. Cela se fait en rangeant cette information de mise à jour dans l’annuaire LDAP. C’est un moyen d’éviter d’éventuels problèmes après une absence un peu prolongée. Dans le cas d’une authentification EAP-TLS après vérification du certificat fourni par le supplicant (CA valide, CRL) le CN de ce certificat est comparé à l’identifiant. Dans le cas d’une authentification par mot de passe transitant dans un tunnel, le serveur vérifie que le mot de passe est bien valide.
Les commutateurs utilisés permettant d’établir dynamiquement des filtres de niveau 3 (IP) sur chacun des ports nous avons utilisé cette possibilité pour limiter le trafic entre machines sur un même sous réseau. La grande peur est d’avoir un ordinateur portable qui après avoir récupéré quelque part dans le monde un virus le propage aux autres machines, sachant que les postes de travail des utilisateurs sont a priori beaucoup plus vulnérables que les serveurs qui eux sont maintenus à jour et ne tournent pas en général sous Windows.
Pour le sans fil le matériel que nous utilisons ne permet pas de définir sur un point d’accès plusieurs SSID et VLAN comme c’est possible avec un Cisco Aironet 1200 par exemple. Cela signifie que toutes les machines connectés à un point d’accès appartiendront au même VLAN. Ce qui est beaucoup plus gênant est l’impossibilité de séparer le trafic servant à l’administration du point d’accès, aux échanges entre le point d’accès et le serveur Radius des échanges avec les machines connectées en sans fil. En effet il y a un seul VLAN pour connecter le point d’accès au réseau filaire.
Nous avons aussi fait le choix de définir 2 VLAN, 2 SSID sur 2 bornes différentes.
Le premier réseau dans fil sert aux membres du laboratoire. L’authentification se fait en 802.1X ce qui est un pré-requis pour utiliser WPA.
Le deuxième est réservé aux invité et offre uniquement un accès vers l’Internet sans aucune connexion possible vers le réseau interne. Il n’utilise pas WPA ni par conséquent 802.1X, en effet c’est prématuré peu de matériels et logiciels le supportant aujourd’hui. Cependant le chiffrement WEP est mis en œuvre pour offrir un minimum de sécurité. En outre la clé WEP est changée régulièrement.
Pour les postes de travail fixes nous avons choisi d’effectuer l’authentification au démarrage et non après le logon. A cela plusieurs raisons :
Il peut y avoir des services réseaux qui tournent avant toute ouverture de session. C’est bien évidemment le cas si on authentifie les utilisateurs à l’aide d’Active Directory, LDAP ou autre et si on utilise des disques partagés.
Il s’agit en pratique d’ordinateurs individuels et pouvoir attribuer des privilèges différents suivant les utilisateurs n’a pas grand sens. Ce qui est important est de contrôler l’accès de la machine au réseau.
Même si ce n’est pas énorme, l’authentification au logon ne peut que ralentir l’ouverture de la session.
Ce choix de fait restreint les méthodes d’authentification possibles. Avec Windows il pratiquement impossible de fournir un mot de passe avant l’ouverture de session. Sous Linux se serait possible mais fournir un mot de passe lors du boot mais ce n’est pas commode. De toute façon gérer sur un serveur des identifiants, mots de passe pour des machines imposerait une administration assez coûteuse. Les procédures techniques et organisationnelles utilisées pour gérer les comptes d’utilisateur ne peuvent s’appliquer sans modifications notables. La méthode EAP-TLS qui utilise un certificat client s’impose donc, tout l’aspect administration étant assurée par l’IGC.
Il ne faut pas surestimer les difficultés liées à l’utilisation d’un certificat. Pour pouvoir utiliser l’authentification 802.1X sur un poste de travail, il faut déjà installer les certificats et éventuellement CRL du CA ayant délivré le certificat du serveur Radius. Il faut aussi configurer les paramètres de l’authentification (CA autorisés, méthode, etc.). L’installation du certificat client n’ajoute qu’une contrainte finalement mineure dans l’ensemble. Pratiquement la demande de certificat, la configuration de l’authentification 802.1X fait partie de la procédure de mise en service d’une nouvelle machine et est assurée par ceux qui sont en charge du parc de machines.
Le certificat utilisé dans ce contexte est un certificat lié à une machine et non à une personne. Dans le contexte de l’IGC du CNRS il s’agit de « certificat de service » qui ont désormais les attributs qui leur permettent d’être utilisé non seulement pour des serveurs mais aussi des clients.
Sous Windows il n’est pas possible d’activer la « protection renforcée de la clé » et aucun mot de passe ne sera demandé pour déverrouiller la clé privée qui est donc nécessairement récupérable par un moyen ou un autre sur le disque.
Pour les ordinateurs portables nous nous trouvons dans une toute autre situation et l’authentification après le logon est plus adaptée :
Une telle machine doit pouvoir fonctionner hors de toute connexion à un réseau. Lorsqu’elle est connecté l’utilisateur doit spécifier des paramètres de connexion en fonction du réseau d’accueil.
L’utilisateur n’a pas forcément besoin ni envie d’une connexion permanente (un liaison sans fil épuise les batteries).
Pratiquement c’est l’utilisateur qui au cours d’une session lance la connexion.
Pour les ordinateurs portables utilisés de fait comme des postes fixes on pourra se reporter ci-dessus.
L’authentification à travers un tunnel en utilisant le nom et le mot de passe de l’utilisateur est possible. Il n’y a rien à ajouter du côté serveur puisque cette authentification existe déjà pour d’autres usages. Nous utilisons dans ce cas PEAP + MSCHAPv2, certes il s’agit d’un protocole propriétaire mais il l’avantage d’être en standard sur les systèmes Windows et fonctionner aussi sur des systèmes Linux. Alors pourquoi chercher à se compliquer la vie ? Cependant la gestion du mot de passe sous Windows possède quelques faiblesses. Par défaut le nom et le mot de passe utilisés sont ceux ayant servi à ouvrir la session. Avoir les mêmes nom et mot de passe sur l’ordinateur de l’utilisateur n’est pas très satisfaisant en matière de sécurité. L’autre option permet de spécifier le nom et le mot de passe, par contre ceux-ci ne vont être demandé que lors de la première connexion, après une authentification réussie ils sont stockés et plus jamais demandé ce qui n’est guère mieux en matière de sécurité.
L’autre option consiste à utiliser EAP-TLS et par conséquent un certificat client. Il s’agit comme précédemment d’un certificat de service. En effet les certificats personnels délivrés par l’IGC du CNRS n’ont pas les bons attributs (il manque dans Extended Key Usage la valeur TLS client). De toute façon sous Windows comme vu précédemment il n’est pas possible d’activer la « protection renforcée de la clé ». Ne faut pas mieux aussi utiliser deux certificats différents et éviter de risquer de compromettre son certificat personnel ? La vraie question serait plutôt ne faut-il pas utiliser un certificat pour l’authentification et le contrôle d’accès et un autre pour la signature ? En cas de compromission avérée ou présumée d’un certificat servant à l’authentification il suffit de le révoquer. C’est l’équivalent de remplacer la canon de sa serrure en cas de vol ou de perte de ses clés. La compromission du certificat servant à la signature électronique a des conséquences beaucoup plus graves. Un produit comme Mozilla permet de gérer des certificats différents, un pour l’authentification (SSL/TLS), l’autre pour la siganture des messages (S/MIME).
Dans un premier temps nous avons décidés de ne pas confier aux utilisateurs le soin de demander un certificat pour leur machine mais de le faire nous même. Nous attendons d’avoir un peu plus de recul.
Nous avons effectué nos essais avec une carte Netgear WG511T. Elle supporte le 802.11b et 802.11g, Elle permet de faire du WPA par contre les produits d’administration livrés avec ne permettent que WPA-PSK. Il s’agit en réalité d’outils fournis par Aegis. Pour le WPA avec un serveur Radius, il faut soit utiliser Windows XP soit pour des versions antérieures de Windows installer un produit tiers (Aegis, Funk, etc.). Le même constructeur vend aussi une carte WAG511 qui supporte les 802.11a, 802.11b et 802.11g et dont les outils d’administration permettent selon la documentation, je n’ai pas vérifié, de faire du WPA avec serveur Radius et non pas seulement du WPA-PSK. C’est celle que j’aurai dû prendre même si je n’ai pas besoin de du 802.11a. Il faut donc faire très attention lors de l’achat d’une telle carte et si on utilise un version de Windows antérieure à XP bien vérifier qu’elle est livrée avec les outils nécessaires à l’administration de WPA car cela revient globalement moins cher que de se procurer un produit tiers.
La borne d’accès est une Netgear WG302. Elle gère le WPA avec un serveur Radius. Cependant j’ai rencontré quelques problèmes. En analysant les journaux du serveur Radius j’ai constaté que des paquets invalides étaient envoyé au serveur Radius qui les ignorent sans que cela perturbe outre mesure le fonctionnement. Plus grave, quelque soit la durée spécifiée de l’intervalle de réauthentification , celle-ci intervient à une fréquence de l’ordre d’une ou deux minutes ce qui bien évidemment induit une charge élevée et inutile. J’ai signalé le problème à Netgear, j’ai bien eu des réponses comme quoi un ticket d’incident a été ouvert, puis fermé mais rien de plus permettant corriger la situation. La version du firmware est 2.0.3. Il n’est pas possible comme sur certaine bornes de segmenter le réseau, ce qui implique d’avoir des bornes différentes pour le réseau interne et celui des invités. Ce n’est pas forcément un inconvénient si on considère que les bornes permettant de segmenter coûte plusieurs fois le prix de la borne utilisée. Plus gênant à mon avis au point de vue de la sécurité le trafic concernant l’administration de la borne et les échanges avec le serveur Radius utilise nécessairement le même VLAN que les machines connectées à la borne. J’ai essayé de limiter les conséquences en organisant les adresses IP et en attribuant à la borne un netmask ne permettant pas à celle-ci de joindre directement l’adresse IP des machines connectées. Mais cela reste un palliatif qui résisterait difficilement à une attaque judicieusement menée.
Microsoft fournit un utilitaire certmgr.exe qui permet de gérer les certificats. Il est disponible dans le SDK .net, par contre je n’ai pas réussi à le faire fonctionner, il fait référence à un point d’entrée manquant dans la bibliothèque crypt32.dll. Cette utilitaire est aussi disponible dans un produit appelé « Authenticode for Internet Explorer 5.0 » URL : http://www.microsoft.com/downloads/details.aspx?FamilyID=2b742795-d0f0-4a66-b27f-22a95fcd3425&displaylang=en qui lui fonctionne. Le fichier codesigning86.exe est une archive qui comprend différents utilitaire dont certmgr.exe.
Je ne suis pas un spécialiste Windows et il est sûrement possible de faire beaucoup mieux mais voici une tentative pour créer un CD permettant d’installer les certificats
On crée le fichier autorun.inf contenant :
[autorun]
open=cacert.bat
et le fichier cacert.bat (http://www.lmcp.jussieu.fr/~morris/802.1X/cacert.bat) contenant :
@echo off
rem Version 01/09/2004 Francois.Morris@lmcp.jussieu.fr
echo Installation des CA et CRL pour le compte utilisateur
certmgr -add -c CNRS.crt -n CNRS -s -r currentUser root
certmgr -add -c CNRS-Standard.crt -n CNRS-Standard -s -r currentUser ca
certmgr -add -crl CNRS.crl -s -r currentUser ca
certmgr -add -crl CNRS-Standard.crl -s -r currentUser ca
echo Installation des CA et CRL pour le compte machine
certmgr -add -c CNRS.crt -n CNRS -s -r localMachine root
certmgr -add -c CNRS-Standard.crt -n CNRS-Standard -s -r localMachine ca
certmgr -add -crl CNRS.crl -s -r localMachine ca
certmgr -add -crl CNRS-Standard.crl -s -r localMachine ca
root, ca, my correspondent respectivement au magasins contenant les certificats racine, CA intermédiaire et personnels. On se reportera utilement aux clés de registre :
HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates et HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates
On copie sur le CD la commande certmgr.exe (comme une version fonctionnelle de celle-ci est un peu difficile à trouver je l’ai copiée en http://www.lmcp.jussieu.fr/~morris/802.1X/certmgr.exe). Il faut aussi copier les fichiers contenant les certificats et les listes de révocation *.crt et *.crl que l’on peut récupérer pour l’IGC du CNRS à l’URL http://igc.services.cnrs.fr/CNRS-Standard/recherche.html (cliquer sur récupération dans un fichier).
Les listes de révocation doivent impérativement être au format DER alors que celles délivrées par l’IGC CNRS sont en format PEM. On peut les convertir à l’aide de la commande suivante :
openssl crl –inform PEM –outform DER –in … -out …
Il est évidemment possible d’ajouter sur le CD d’autres produits à installer.
Pour installer le certificat de l’utilisateur ou de la machine on peut utiliser la procédure suivante (http://www.lmcp.jussieu.fr/~morris/802.1X/usercert.bat), pour simplifier j’ai supprimé ci-dessous le traitement des erreurs. :
@echo off
rem Version 01/09/2004 Francois.Morris@lmcp.jussieu.fr
rem Installation d'un certificat dans le compte de l'utilisateur et
rem recopie dans le compte de la machine locale
rem Parametre 1 : fichier pkcs#12
rem Parametre 2 : nom du certificat (commonName)
echo Installation du certificat dans le compte de l'utilisateur
echo Ne pas cocher la case "Activer la protection renforcee de cles privees"
echo Cochez la case "Marquer la cle privee comme etant exportable"
echo Laissez cochee la case "Selectionner automatiquement le magasin"
pause
start /w %1
echo Recopie du certificat dans le compte de l'utilisateur
certmgr -add -c -n %2 -s -r currentUser my -s -r localMachine my
Il faut noter qu’il est relativement facile sous Windows d’installer un certificat pour le compte de l’utilisateur, il suffit en effet de cliquer sur le fichier contenant le certificat. Par contre il est beaucoup plus difficile de l’installer pour le compte de la machine locale, il faut passer par la console mmc. La commande certmgr décrite ci-dessus permet de recopier un certificat et sa clé associée du compte utilisateur à celui de la machine locale.
Comme actuellement avec l’IGC du CNRS on doit utiliser des certificats de type « service », j’utilise la procédure suivante pour combiner les deux fichiers contenant l’un le certificat et l’autre la clé privée en un fichier au format pkcs#12 (http://www.lmcp.jussieu.fr/~morris/802.1X/make_p12) :
#!/bin/bash
# Version 02/09/2000 Francois.Morris@lmcp.jussieu.fr
printUsage () {
echo "$0 <certificate name>"
}
if [ $# -lt 1 ]; then
printUsage
exit 1
fi
name=$1
if [ ! -r $name.key ]; then
echo "Can't read key file $name.key"
exit 1
fi
if [ ! -r $name.crt ]; then
echo "Can't read cert file $name.crt"
exit 1
fi
openssl pkcs12 -export -inkey $name.key -in $name.crt -name $name \
–out $name.p12
Afin d’installer facilement les différents certificats sur le poste de travail Windows et accessoirement Linux, j’ai écrit une procédure sous Unix qui à partir des fichiers contenant le certificat et la clé envoyés par l’IGC CNRS génère sur un support amovible comme une disquette tout ce qui est nécessaire. L’ensemble se trouve dans l’archive http://www.lmcp.jussieu.fr/~morris/802.1X/make_disk.tgz.
On a souvent hésité à déployer des réseaux sans fil à cause du manque de sécurité du protocole 802.11 (WEP). Cependant il répondent à un réel besoin et les refuser c’est s’exposer au risque déploiement sauvage. Heureusement WPA fourni une réponse aux faiblesses en matière de sécurité des réseau sans fil. Aujourd’hui il faut impérativement choisir des produits le supportant. Pour un usage à domicile ou dans une petite structure on choisira WPA-PSK dont la mise en œuvre est simple et la sécurité satisfaisante à condition de choisir un secret partagé suffisamment robuste. A une plus grande échelle il est nécessaire d’utiliser une authentification 802.1X avec les contraintes que cela impose : serveur Radius, certificats. Il ne faut cependant pas surestimer les difficultés sachant que des éléments de la solution (authentification, IGC) existent souvent déjà.
Pour un réseau filaire l’authentification 802.1X des matériels connectés offre une plus grande sécurité que les méthodes reposant sur l’adresse MAC qui peut toujours être usurpée. Le principal intérêt me semble être cependant la possibilité de fournir dynamiquement à partir d’un serveur Radius au commutateur des éléments permettant de configurer le port comme le numéro de VLAN ou des filtres.
L’utilisation d’un serveur Radius s’il est un peu délicat à mettre en œuvre offre de nombreuses possibilités pour attribuer finement les droits d’accès en fonction des utilisateurs. Il permet d’assurer un journal détaillé et une comptabilité des connexions. Le fait qu’un serveur Radius puisse relayer les requêtes d’authentification vers d’autres serveur (Radius, LDAP, contrôleur de domaine, etc.) est particulièrement intéressant et permet de s’intégrer facilement dans une architecture existante. Il ne faut donc pas voir le préalable d’un serveur Radius comme une contrainte mais plutôt comme un atout.