Authentification centralisée

ANCIEN SITE

Ces pages font un point sur ce à quoi nous travaillons au Centre Réseau et Informatique Commun concernant l'authentification centralisée.

Plan de cette page :

I) Nos objectifs

II) Organigramme de la solution complète

III) Fonctionnement en 802.1X
      a) Schéma de principe d'authentification au sein du site
      b) Schéma fonctionnel au niveau d'un labo
      c) Interactions LDAP-Radius
      d) Authentification hors du site

IV) Maquette et essais en 802.1x
a) Installation de FreeRADIUS
b) Exemples de connexion

V) Portail captif
      a) Le principe
      b) L'installation
      c) La configuration
      d) Si Problème de fonctionnement

VI) Wifi
a) Configuration (pour les administrateurs):
b) Modes de connexions (pour les utilisateurs) :

VII) VPNs

VIII) Accounting

IX) Aspects sécurité

Avec une clé WPA seule
Via le portail captif
En 802.1x
Via le VPN

X) Contributions

I) Nos objectifs :

Nous souhaitons prendre en compte les éléments suivants dans une solution globale :

les demandes de WiFi (nécessité d'une sécurisation forte et d'une détection des bornes pirates),
la délocalisation de certains chercheurs,
le besoin de mobilité,
la nécessité désormais d'identifier les utilisateurs d'un réseau,
les virus mis en circulation dans les laboratoires par les portables.

La solution envisagée s'appuie le plus possible sur :

Les standards ( Radius , 802.1X , LDAP, EAP TLS/TTLS , les VLANs, ...),
Les logiciels libres ( FreeRadius , SecureW2 , Xsupplicant , openVPN , ...),
La réflexion et le travail entamé dans les universités depuis 2003 ( voir aussi ).

Du fait, cette solution devrait être compatible avec la politique de gestion des accès au réseau telle qu'elle se prépare en France ( ARREDU ), et dans le monde ( EduRoam ).

La problématique les virus :

Afin de répondre à la problématique les virus mis en circulation dans les laboratoires, nous souhaitons conditionner l'accès au réseau à la salubrité de l'ordinateur.

Rappels sur 802.1X :

802.1X est un standard IEEE destiné à gérer l'accès au réseau d'un laboratoire dès le niveau physique. C'est pourquoi au sein du laboratoire tous les commutateurs (ou switches) doivent supporter le protocole 802.1X, et que chaque ordinateur doit être physiquement relié à un port de commutateur.
Note :
Une borne Wifi supportant le protocole 802.1X accueille comme un commutateur plusieurs ordinateurs, mais sur des ports virtuels.

Le principe est le suivant : quand l'utilisateur allume son PC ou son Mac (ou le connecte au réseau), le commutateur sur lequel est raccordé l'ordinateur demande une authentification, typiquement le login de l'utilisateur.
Le commutateur se charge ensuite de transmettre ce login au serveur d'authentification central (Radius).
Pour recueillir le mot de passe il s'établit ensuite un tunnel chiffré entre l'ordinateur et le serveur d'authentification.
Le Radius soumet alors ce couple "login/mot de passe" au serveur d'annuaire central (LDAP).
Le LDAP renvoie alors :

si cette authentification est valide
le réseau virtuel (ou VLAN) dans lequel le commutateur doit placer cet utilisateur (typiquement en réseau interne ou en réseau invité).

Méthodes d'identification supportées :

Pour réaliser l'authentification, le protocole 802.1X s'appuie sur EAP (Extensible Authentication Protocol). Il y a plusieurs types d'EAP :

EAP-TLS exige un certificat électronique côté serveur (afin que l'utilisateur puisse l'authentifier de façon sûre) ET un certificat électronique côté utilisateur.
EAP-TTLS n'impose un certificat électronique que côté serveur et un "login/mot de passe" côté utilisateur (le certificat du serveur pour créer un tunnel dans lequel transitera le mot de passe).
PEAP, developpé par Microsoft et Cisco, travaille de la même façon que EAP-TTLS, mais brouille le mot de passe avant de l'envoyer dans le tunnel. Aussi, à réception, le serveur Radius est incapable de le comparer avec celui qu'il a côté LDAP. Pour une explication plus précise cliquez ici.

C'est pourquoi, le type d'authentification que nous avons retenu est EAP-TTLS+PAP (avec la méthode PAP le mot de passe reste en clair, dans le tunnel crypté)

II) Organigramme de la solution complète :

Figure 1
Réactions du Radius central à réception d'une demande d'authentification

III) Fonctionnement en 802.1X :

a) Schéma de principe d'authentification au sein du site :

Figure 2
Tous les départements pointent sur un serveur Radius central, lequel interroge la base LDAP centrale. Le Radius central répondra également aux demandes d'authentification venant de l'extérieur du site (exemple: dupont@grenoble.fr depuis un labo de Bordeaux).

b) Schéma fonctionnel au niveau d'un labo :

Figure 3
c) Interactions LDAP-Radius :

Dans notre LDAP central une personne est permanente ou non-permanente.
Pour la problématique nomadisme on a ajouté dans l'annuaire :

Un champ spécial "radiusGroupName". Ce champ -qui n'est exploité que par Radius- peut prendre la valeur "interneLABO-XX" ou "inviteLABO-XX".
Ce champ n'est modifiable que par l'administrateur informatique du labo.
Une entrée "visiteurs" réservée aux enregistrements de très courte durée (de 1 heure à une semaine).
Cette entrée "visiteurs" est une branche particulière de l'arbre LDAP :
- On ne crée pas de e-mail sur le serveur pour cette personne
- La fiche contient:
  son nom, son prénom, son e-mail, le nom du permanent qui le reçoit, le nombre de jours (max 8).
  Au delà de cette période la fiche est placée en mémoire pour des besoins éventuels d'identification ultérieurs.
- Le "radiusGroupName" prend par défaut la valeur : "inviteLABO-XX", où LABO-XX=labo de la secrétaire qui remplit la fiche.

Ces adaptations, associées aux règles mises en place dans les configurations Radius, permettent une grande latitude dans les autorisations. Ainsi pour l'utilisateur « dupont » qui appartient au labo XX :

Si "interneLABO-XX" et "interneLABO-YY" sont définis pour Dupont en LDAP, il sera indifféremment accepté dans les réseaux internes des labos XX et YY (mais uniquement dans ceux-là). Voici un exemple de trace.
Si depuis son labo XX il souhaite accéder au réseau interne, il s'authentifie simplement par « dupont ».
Pour accéder de même au réseau interne de son labo XX alors qu'il est pysiquement dans le labo YY, il devra s'authentifier par « dupont@LABO-XX » (on nomme cette extension "@LABO-XX" un realm).

Quelques principes :

Si un utilisateur est "interne" dans un labo quelconque, il est accepté par défaut dans le réseau "invites" de tous les autres.
Le visiteur d'un labo ne sera accepté que dans le réseau « invites » de son labo (il a par défaut la valeur : "inviteLABO-XX").
Pour être accepté dans le réseau « invites » du labo ZZ il devra être défini en LDAP inviteLABO-ZZ"

d) Authentification hors du site :

Un chercheur de Grenoble est en visite sur un site extérieur.

S'il veut se connecter sur le site de Grenoble il doit utiliser le VPN (quand le programme sera disponible, le client VPN lancera le test de salubrité).
Le serveur VPN, si le test de salubrité est satisfaisant, donnera alors accès au réseau interne du département.

S'il se trouve sur un site EduRoam exigeant une authentification : le Radius transmet à Grenoble le couple "login/mot de passe" que le chercheur a fourni. Si celui-ci est correct, l'utilisateur, identifié, peut alors accéder au réseau du site visité.

IV) Maquette et essais en 802.1x :

a) Installation de FreeRADIUS :

Pour que le TLS fonctionne il est nécessaire de télécharger et installer la version CVS. En effet la licence du logiciel OpenSSL n'est pas compatible avec la licence GPL de FreeRADIUS, aussi les modules EAP/TLS (rlm_eap_tls.so) et EAP/TTLS (rlm_eap_ttls.so) ne sont pas compilés par défaut dans le package FreeRADIUS sur Debian.
Pour les télécharger aller sur Le site FreeRadius

Dans /usr/local/src/ :

tar zxvf freeradius-snapshot-xxxxxxxx.tar.gz
cd freeradius-snapshot-xxxxxxxx/
./configure --prefix=/usr/local/freeradius
make
make install
(Actuellement on a la version : "2.0.0-pre0, for host x86_64-unknown-linux-gnu, built on Oct 3 2006")

Voici nos fichiers de configurations FreeRadius actuels :

Fichier	Description
radiusd.conf	Fichier de configuration de base
eap.conf	Regroupe tous les modules d’authentification EAP
clients.conf	Clients autorisé à communiquer avec FreeRadius (Switch, Borne, ...) Contient l'adresse IP du/des clients autorisés à venir se connecter, ainsi que le secret partagé entre le client (le Switch) et le Radius.
users	Fichier où s'effectuent les tests successifs d'authentification. Selon l'adresse IP, le groupe, etc.
huntgroups	Associe des variables (groupes de clients) à des adresses IP.
proxy.conf	Associe un domaine (realm) à l'adresse du serveur Radius correspondant.
ldap.attrmap	Correspondance des attributs LDAP et Radius

Voici le schéma de la maquette utilisant les fichiers de configuration ci-dessus :

Installations et configurations annexes

Configuration du SWITCH (Cisco 2950)
Note : Il a été nécessaire de télécharger la dernière version pour corriger différents problèmes.

Configuration du Routeur MCBT (Cisco 3550)

Configuration du fichier /etc/network/ interfaces du serveur DHCP.

b) Exemples de connexion :

Dans les exemples ci-dessous :

l'utilisateur se trouve physiquement au labo MCBT

il a pour login "jean.dupont" mais s'authentifie par son alias de mail "dupont"
En effet en base LDAP on a placé en champ "mail" les aliases possibles (de la forme user@grenoble.cnrs.fr).

.------------------------ en fichier radiusd.conf : ----------------------------------------.
|modules {                                                                                  |
|   ldap ldap {                                                                             |
|      groupname_attribute = radiusGroupName                                                |
|      #                                                                                    |
|      # On verifie si l'utilisateur s'est connecté en "dupont" ou "dupont@grenoble.cnrs.fr |
|      # car en base LDAP on a placé en champ "mail" les aliases possibles                  |
|      filter = "(|(|(uid=%{Stripped-User-Name:-%{User-Name}})(mail=%{Stripped-User-Name:-%{User-Name}}))(mail=%{Stripped-User-Name:-%{User-Name}}@grenoble.cnrs.fr))"
|      base_filter = "(objectclass=radiusprofile)"                                          |
|      groupmembership_filter = "(|(|(uid=%{Stripped-User-Name:-%{User-Name}})(mail=%{Stripped-User-Name:-%{User-Name}}))(mail=%{Stripped-User-Name:-%{User-Name}}@grenoble.cnrs.fr))"
`-------------------------------------------------------------------------------------------'

les connexions ont lieu en Wifi

Premier exemple :

L'utilisateur "dupont" est un permanent du labo MCBT (radiusGroupName=interneMCBT).
Il veut se connecter au réseau interne de son labo (il a entré "dupont" pour s'identifier).
-> il est admis dans le VLAN "interne" du MCBT

Deuxième exemple :

L'utilisateur "dupont" est un visiteur du labo MCBT (radiusGroupName=inviteMCBT).
Il a entré "dupont" pour s'identifier.
-> Après identification il est admis dans le VLAN "invites" du MCBT

Troisième exemple :

L'utilisateur "dupont" est un permanent du labo NANO (radiusGroupName=interneNANO) et se trouve dans le labo MCBT.
Puisqu'il s'identifie simplement par « dupont » c'est qu'il cherche à entrer dans le réseau interne du MCBT.
Il ne peut y prétendre car il n'y a pas "interneMCBT" dans son "radiusGroupName", cependant, puisqu'il est "interne" d'un labo du site
-> il est placé dans le réseau "invites" du MCBT

Quatrième exemple :

L'utilisateur "dupont" est un visiteur du labo NANO (radiusGroupName=inviteNANO)
mais il demande à se connecter au réseau interne du labo MCBT (pour s'identifier il a simplement entré "dupont").
-> il est rejeté

Cinquième exemple :

L'utilisateur "dupont" est un visiteur du labo NANO (radiusGroupName=inviteNANO)
mais il demande ["dupont@NANO"] à se connecter au réseau interne du labo NANO
-> il est rejeté

Sixième exemple :

L'utilisateur "dupont" est un permanent du labo MCBT (radiusGroupName=interneMCBT)
mais il demande ["dupont@NANO"] à se connecter au réseau interne du labo NANO.
-> il est rejeté

Septième exemple :

L'utilisateur "dupont" est un permanent du labo NANO (radiusGroupName=interneNANO)
et il demande ["dupont@NANO"] à se connecter au réseau interne du labo NANO.
-> Après identification il est admis dans le VLAN "interne" du NANO

Huitième exemple :

L'utilisateur "dupont" est un permanent du laboratoire de Toulouse. Il est physiquement dans le labo MCBT et s'authentifie aue réseau par "dupont@toulouse.cnrs.fr"
-> Après identification auprès du Radius de Toulouse il est admis dans le VLAN "invites" du laboratoire dans lequel il se trouve (ici le MCBT)

Pour ce cas de proxification sur l'ARREDU nous avons dû adapter nos configurations.

V) Portail captif :

a) Le principe :
Un Portail Captif est un serveur qui intercepte la première tentative de connexion d'un navigateur, puis demande une authentification. Si le login et mot de passe fournis sont corrects l'accès Internet est donné.

1) Explication simplifiée d'un portail captif via une borne Wifi

2) Schéma de détail technique :

Au démarrage du Portail Captif tun0 se crée et prend 10.8.128.5 sur eth1.
(ce tunnel -non crypté, sert à garantir une voie unique entre les divers clients du Portail Captif)

(1) le client demande une adresse sur le réseau
-> le Portail Captif lui donne une adresse non-routable en 10.8.128.x
(2) quand le client fait une requête web (port 80 ou 443),
-> le Portail Captif intercepte cette requête
-> il demande une authentification (une fenêtre de demande Login/mot de passe s'ouvre chez le client)
(ces informations sont cryptées car le Portail Captif est un serveur HTTPS)
(3) le Portail Captif les transmet au Radius Central.
(4) Si l'authentification est OK :
- le Portail Captif accorde au client une adresse IP routable.
  (parmi une plage d'adresses non-routables->routables pré-définie (Ex: 10.8.128.5->147.173.128.5). Détails ci-dessous en "configuration de ChilliSpot").
- pour les besoins d'accounting (cf. chapitre 8) le Radius Central crée une entrée en base SQL

3) Tests :

Si le client n'a pas SecurW2 ou a désactivé l'authentification, dès qu'il tente une connexion Internet il voit apparaitre la fenêtre de demande d'authentification de Chilli.
On peut vérifier cela
sur le Switch :
SW# sh interface fa0/19 status (le port où est connecté le PC ou la borne)
passe de :
sur le PC client :
cmd: ipconfig (devrait s'être vu attribué une adresse en 10.18.x.x
Status           Vlan
passe de :
notconnect      1
à :
connected      846
Autoconfiguration de l'adresse IP......... 169.254.182.7
à :
Adesse IP..................................10.8.246.2
sur le serveur Chilli :
tail -99 /var/log/daemon.log

b) L'installation :

apt-get install apache2
apt-get install chillispot

c) La configuration :

d) Si problèmes de fonctionnement :

Etapes d'une connection avec Chillispot	En cas de problème vérifier
Attribution d'une adresse au client par chillispot	chilli.conf et chilli.iptables Est ce que chillispot est bien démarré ?
Ouverture d'une page web sur le client - Interception par Chillispot de la requête - Redirection vers la page hotspotlogin.cgi	Apache et ses logs Hotspotlogin.cgi Le uamsecret Est ce que la page web est accessible par le client manuellement ? https://10.8.240.1/cgi-bin/hotspotlogin.cgi
L'utilisateur entre son Login/Mot de passe	chilli.iptables et la configuration de freeradius

Vous pouvez aussi essayer :

# chillispot --fg --debug

Note :
Le portail captif place en principe le client dans un réseau non routable, mais ici c'est le réseau 10.8.x.x qui est utilisé (un réseau tunnelisé entre le Campus et le Polygone de Grenoble). De la sorte, un client peut se connecter directement au serveur VPN du Campus de son choix (sans avoir à s'authentifier auprès du serveur du Polygone).

VI) Wifi :

Pour les administrateurs :
Configurations préalables pour une salle de conférence.
Documentation complète (2005) de la borne HP WL420 + ses Release notes (2007)
Pour les clients (chercheurs, visiteurs) :
Rappel : une borne WiFi annonce par des SSID les réseaux auxquels elle permet d'accéder. Votre ordinateur "voit" ces SSID via sa carte WiFi. Pour "voir" ces SSID et donc les réseaux sans fil disponibles :
a) cliquez sur Démarrer -> Paramètres -> Connexions réseau.
b) Faire un clic droit sur Connexion réseau sans fil -> Afficher les réseaux sans fil disponibles

Au minimum deux types d'accès sont supportés dans les salles de conférence :
1. Pour les conférences de courte durée (de l'ordre d'une journée) : utilisez le SSID qui comporte le mot invite (Exemple DR invite pour la salle de conférence de la DR).
  A l'aide d'une clé (d'une quinzaine de caractères) que le responsable de la conférence vous communique, vous avez alors accès au réseau Internet (et non pas au réseau interne du laboratoire).
  Note: Cette méthode ne permet aucune identification de la personne. Mais il serait administrativement lourd d'affecter à chaque participant un "login/mot de passe".
  Voici un exemple de connexion.
2. Pour les conférences de plusieurs jours : utilisez le SSID qui comporte le mot chillispot (Exemple NANO D420 chillispot pour la salle de conférence du 3ème de NANO)
  Cet SSID vous fait passer par un portail captif, lequel vous demandera de vous authentifier par le couple "login/mot de passe" qui vous a été fourni (1).
  Note: Il vous faut activer le JavaScript sur votre navigateur.
  Voici un exemple de connexion.
Un troisième type d'accès est le 802.1X. Il est supporté dans les labos.

Note: Parmi les SSID annoncés par une borne, l'un d'entre eux est prioritaire. Il s'affichera en tête des réseaux "vus" par votre ordinateur. Pour vous faciliter les choses, durant la durée d'une conférence le SSID "invite" sera prioritairement annoncé par la borne, sinon ce sera le SSID "chillispot".

_____________
(1) Si vous êtes extérieur au site utilisez le couple "login/mot de passe" que vous a fourni le responsable de la conférence
Si vous êtes sur la messagerie de grenoble.cnrs.fr, utilisez votre "login/mot de passe" habituel

VII) VPNs :

Pour le nomadisme sur la plaque grenobloise et en particulier pour les VPNs, le campus a réparti un réseau privé de classe A entre les divers établissements. Ainsi l'IMAG a le réseau 10.6.0.0/16, l'INPG le 10.4.0.0/16, le CNRS le réseau 10.8.0.0/16, etc. Pour laisser circuler ce réseau privé entre le Polygone et le Campus un tunnel a été établi.

a) Connexion :

Le schéma ci-dessus illustre quelques exemples de connexions :

Un enseignant de l'IMAG (portable vert) veut se connecter depuis le Polygone à son labo :
- en labo2, il récupère dynamiquement une adresse en 10.8.2.0/24 (en labo1 il aurait récupéré une adresse en 10.8.1.0/24)
- il lance une connexion vers le serveur VPN de l'IMAG (en 10.6.1.12)
- Rt-labo2 sait que tout ce qui n'est pas 10.8.0.0 est à router sur le Campus
- Rt-CAMPUS sait que 10.6.0.0 est à router vers Rt-IMAG
- une fois à l'IMAG, la connexion est orientée vers 10.6.1.12.
Un chercheur (portable mauve) veut se connecter depuis chez lui à son labo (labo2)
- il lui suffit de lancer la connexion sur l'adresse routable du serveur VPN de labo2
Depuis l'IMAG, un chercheur (portable cyan) veut se connecter à son labo (labo1)
- à l'IMAG il récupère dynamiquement une adresse en 10.6.10.0/24 (de l'INP il aurait récupéré une adresse en 10.4.10.0/24)
- il lance une connexion vers le serveur VPN de labo1 qui est en 10.8.1.12
- Rt-IMAG sait que tout ce qui n'est pas 10.6.0.0 est à router sur Rt-CAMPUS
- Rt-CAMPUS sait que 10.8.0.0 est à router vers le CNRS
- Rt-CNRS oriente la connexion vers Rt-labo1, qui l'oriente ensuite sur le serveur VPN du labo.

Le serveur VPN du labo exige alors une authentification.

b) Authentification :

C'est l'établissement auquel on se connecte qui fixe le type d'authentification et qui la gère. Elle peut se faire par certificat ou par "login/mot de passe". Dans tous les cas il est souhaitable qu'une base de données commune soit consultée.

Dans le cas d'une authentification par certificat :

si le serveur VPN de labo1 ne veut pas accepter dans le réseau interne tous les utilisateurs du CNRS, il ira consulter le serveur LDAP afin de n'accepter que ceux de labo1

Dans le cas d'une authentification par "login/mot de passe" :

les serveurs Radius et LDAP seront consultés.

VIII) Accounting :

L'accounting permet de se conformer à la loi du 26 mars 2006 qui demande aux FAIs -que nous sommes, de conserver pour tout accès Internet les informations permettant d'identifier un utilisateur.
De même, tout établissement membre du projet EduRoam / ARREDU (authentification répartie) s'engage auprès de RENATER lors de la signature de la charte EduRoam à respecter cette disposition de traçabilité

Le serveur Radius dispose :

de l'adresse MAC,
de la période de connexion,
du login.

Cependant puisque ce n'est pas lui qui a affecté l'adresse IP au client, il ne sait pas quelle adresse IP a été affectée, puisqu'elle l'a été par un serveur DHCP externe (**). Il faut donc aller chercher cette adresse dans les logs de DHCP, ainsi que l'adresse MAC et l'heure d'attribution.
L'adresse MAC servira de clé de liaison entre les informations fournies par le serveur DHCP et le serveur Radius, et l'heure attestera qu'il s'agit bien de la bonne connexion.

Schéma illustrant le principe d'accounting.
Fichier sql.conf inclus en radiusd.conf.

Pré-Requis :
Installation de MySQL

Au final on obtient quelque chose de la forme :

radius# mysql -u root
radius# mysql> use accounting
radius# mysql> select UserName FramedIPAddress, AcctStartTime, AcctStopTime, CallingStationId, FramedIPAddress from radacct;

+--------------------+---------------------+---------------------+-------------------+-----------------+
| FramedIPAddress    | AcctStartTime       | AcctStopTime        | CallingStationId  | FramedIPAddress |
+--------------------+---------------------+---------------------+-------------------+-----------------+
| jean.dupont        | 2007-03-28 16:44:47 | 2007-03-28 16:46:03 | 00-0F-B0-73-8F-0B | 10.8.240.10     |
| jean.dupont        | 2007-03-28 16:46:05 | 2007-03-28 16:56:56 | 00-0F-B0-73-8F-0B | 10.8.240.10     |
| jean.dupont        | 2007-03-28 17:13:51 | 2007-03-28 17:15:28 | 00-A0-D1-35-6C-19 | 10.8.240.3      |
| jean.dupont        | 2007-03-28 17:15:44 | 2007-03-28 17:16:36 | 00-A0-D1-35-6C-19 | 10.8.240.3      |
| jean.dupont        | 2007-03-28 17:17:23 | 2007-03-28 17:35:53 | 00-A0-D1-35-6C-19 | 10.8.240.3      |
| jean.dupont        | 2007-03-29 10:16:22 | 2007-03-29 10:19:03 | 00-0F-B0-73-8F-0B | 10.8.240.7      |
| jean.dupont        | 2007-03-29 10:19:05 | 2007-03-29 10:19:21 | 00-0F-B0-73-8F-0B | 10.8.240.4      |
| jean.dupont        | 2007-03-29 11:11:21 | 2007-03-29 11:11:56 | 00-0F-B0-73-8F-0B | 10.8.240.5      |
| jean.dupont        | 2007-04-04 17:43:41 | 2007-04-04 17:45:43 | 00-A0-D1-35-6C-19 | 10.8.240.12     |
| jean.dupont        | 2007-04-23 11:40:55 | 2007-04-23 11:43:40 | 00-30-65-80-36-48 | 147.173.246.4   |
| jean.dupont        | 2007-05-04 17:52:00 | 2007-05-04 17:52:04 | 00-04-76-A2-F3-2F | 147.173.246.3   |
+--------------------+---------------------+---------------------+-------------------+-----------------+

radius# mysql> quit

IX) Aspects sécurité :

Avec une clé WPA seule :

Une clé WPA encrypte sur 256 bits, cependant l'encryption ne sera considérée comme fiable que si la pass phrase comporte un minimum de 21 caractères ! (de même pour une clé WPA2)
C'est dire l'importance du choix de la pass phrase.
Bien évidemment cette pass phrase devra avoir une durée de vie la plus courte possible, typiquement le temps d'une conférence d'une journée au plus.

Via le portail captif :

Il y a cryptage entre le poste client et le portail captif le temps de la transmission du "login/mot de passe". Par contre il n'y a pas de cryptage entre le portail captif et le Radius central et ensuite les échanges du client sur le réseau circulent en clair.

En 802.1x :

Dans le tunnel chiffré établit entre le poste client et le Radius central la transmission du "login/mot de passe" est sécurisée. Mais une fois le port du Swich ouvert (accord du Radius) les échanges du client sur le réseau circulent en clair.
Sauf en WiFi où tous les échanges sont cryptés en WPA ou WPA2.

Via le VPN :

Qu'il soit SSL ou Ipsec, une clé de session de 1048 bits, crypte tous les échanges (identification et trafic) entre le poste client et le serveur VPN.

X) Contributions :

Vos commentaires, corrections, compléments d'informations, sont les bienvenus : CRIC@grenoble.cnrs.fr

Nous pouvons également ajouter à cette page un lien vers la votre.

CNRS / Centre Réseau et Informatique Commun (CRIC) - Dernière modification : 15/06/2010.