Dans cet atelier, nous avons commencé à utiliser l'infrastructure de test mise à poste à Cholet, de façon permanente jusqu'à ce qu'elle ne soit plus nécessaire.

Il s'agit simplement d'une machine routeur avec deux interfaces ethernet, l'une connectée à internet et l'autre connectée à une antenne Ubiquity en 5GHz, établissant un pont avec une seconde antenne. Côté internet, on utilise (pour le moment) un tunnel Hurricane Electric qui nous permet d'adresser et router des blocs IP dans un /48.

   ( Internet )          +-----------------------------+                             +-------------------+
Hurricane Electric ----- |(hurricane0)  Routeur  (eth2)|---- NSM5#0 ---- NSM5#1 -----| Routeur domestique|
                         +-----------------------------+                             +-------------------+

Le routeur de test est accessible aux membres le souhaitant, moyennant une clé SSH. Il s'agit d'un simple laptop sous Linux Mint 17.

Le dépôt git est accessible à l'adresse suivante (une clé publique SSH est nécessaire pour le moment) :

ssh://gitolite@code.ceops.eu:229/wifi-fma.git

Le logiciel serveur d'authentification est Freeradius. Sous les distributions de type Debian, ses fichiers de configuration se trouvent dans /etc/freeradius/.

A priori, il recevra les requêtes d'authentification d'abonnés contenant un identifiant et un mot de passe, et pourra répondre en fournissant (en cas de succès) une adresse IPv4 (comment faire pour fournir le bloc v6 ?) et un numéro de VLAN.

Dans le setup dessiné au-dessus, le serveur RADIUS devra écouter sur l'interface eth2.

Quelques liens :

• http://raisin.u-bordeaux.fr/IMG/pdf/Protocoles-auth-1page.pdf
• http://freeradius.org/radiusd/man/users.html
• http://freeradius.org/radiusd/man/acct_users.html
• http://blog.clemanet.com/freeradius-802-1x-vlan/
• http://fr.wikipedia.org/wiki/Remote_Authentication_Dial-In_User_Service
• http://cric.grenoble.cnrs.fr/Administrateurs/Documentations/authentification/freeradius.php

L'installation Debian de Freeradius contient par défaut une foule de fichiers dans /etc/freeradius/. Seulement un petit nombre nous ont intéressés :

• clients.conf, qui permet d'autoriser des machines distantes à nous émettre des requêtes d'authentification, en protégeant l'accès avec par exemple un secret partagé ;
• eap.conf, pour la configuration de l'authentification EAP ;
• radiusd.conf, le fichier de configuration principal (pas modifié pendant l'atelier)
• users, la base de données des utilisateurs, qui contient les identifiants, mots de passe associés à un numéro de VLAN, IP, …

Pour rajouter un simple utilisateur fictif faimaison dont le mot de passe est netneutrality, nous avons ajouté cette ligne au fichier users :

faimaison       Cleartext-Password := "netneutrality"

C'est aussi dans ce fichier que nous pouvons attribuer des choses telle qu'un numéro de VLAN, pour chaque utilisateur, ainsi qu'une adresse IP (mais il est peu probable que l'assignation d'adresses/blocs IP soit gérée via RADIUS). Cela se fait de cette manière (le dernier paramètre est le numéro de VLAN) :

faimaison       Cleartext-Password := "netneutrality"
      Tunnel-Type = VLAN,
      Tunnel-Medium-Type = 1,
      Tunnel-Private-Group-Id = 42

Quels autres attributs pourront nous être utiles ? Voir la liste des attributs de Freeradius pour en identifier éventuellement d'autres.

A priori, l'attribution d'adresses IPv4 et la délégation de blocs IPv6 ne sera pas gérée par RADIUS mais directement par le serveur DHCP écoutant sur le VLAN « activé » une fois l'identification réussie de l'utilisateur.

C'est pour cela que l'attribut Framed-IP-Address ne sera probablement pas utilisé dans notre configuration de RADIUS (il sert à stocker l'adresse IP comme attribut d'un utilisateur dans RADIUS).

Le fichier clients.conf contient de quoi autoriser des clients RADIUS avec un contrôle d'accès.

Par exemple, autoriser les clients à se connecter avec le secret partagé testing123 se fait avec ce bloc :

client localhost {
        ipaddr = 0.0.0.0
        secret          = testing123
        require_message_authenticator = no
        nastype     = other
}

Ceci est à peine (voire pas du tout) modifié de la configuration de base. Il faudra lire davantage la documentation.

EAP peut être utilisé pour l'authentfication des abonnés.

Pour éviter de faire passer les identifiants et mots de passe en clair sur le réseau, il est possible d'utiliser EAP-TTLS (transaction EAP encapsulée dans un tunnel TLS). Toutefois, d'autres méthodes de sécurisation de la transaction EAP sont envisageables (voir la page Wikipedia dédiée qui liste les possibilités).

Pour EAP-TTLS il faut un certificat et une clé privée côté serveur et diffuser le certificat aux clients (pour qu'ils puissent le vérifier). Cela peut toutefois être un peu complexe de diffuser le certificat aux clients.

Le package FreeRADIUS inclut des clients RADIUS, radclient et radeapclient. Le second supporte la négocation EAP-MD5 mais peut-être pas EAP-TTLS. Pour tester, il faudra peut-être faire autrement.

Avec le protocole RADIUS de base, on peut faire un test local d'authentification comme cela :

echo User-Name=faimaison,User-Password=netneutrality | radclient localhost auth testing123

Une authentification réussie est signalée par un code 2 en réponse.

Pour faire le même test en utilisant EAP, cette commande peut être utilisée :

(echo "User-Name = faimaison";  echo "Cleartext-Password = netneutrality";   echo "EAP-Code = Response";   echo "EAP-Id = 210";   echo "EAP-Type-Identity = faimaison";   echo "Message-Authenticator = 0x00"; ) | radeapclient -x 127.0.0.1 auth testing123

Ce second exemple provient de la page de manuel de radeapclient, et la signification des champs tels que EAP-Id reste obscure.

Une authentification réussie se termine par un paquet Access-Accept.

Nous n'avons pas réussi à faire communiquer le client EAP d'AirOS avec FreeRADIUS en EAP-TTLS. Ça a été le test principal sur AirOS, échoué pour le moment.