Mise en place sur le point d'accès d'un réseau wifi

. . . Attributs, valeurs et dictionnaires

Les attributs sont l'essence même du protocole. C'est eux qui véhiculent les informations nécessaires aux NAS pour qu'ils puissent assurer les connexions. Le RFC 2138 définit pas moins de 41 attributs utilisés pour les opérations d'authentifications et d'autorisations. Les 15 attributs nécessaires a la comptabilisation sont eux définis dans le RFC 2139.

Les attributs ne peuvent être employés de manière anarchique. Le standard interdit l'emploi de certains attributs dans des types de paquets bien définis. Un exemple trivial est celui de l'attribut User-Password qui ne peut-être employé que dans un paquet de type Access-Request.

Un attribut est caractérisé par 3 champs représentés graphiquement sur ce schéma :

Le numéro (1 octet) : compris entre 1 et 255, le numéro identifie l'information qui caractérise l'attribut. Par exemple : 1 = User-Name.

La taille (1 octet) : la taille est calculée en fonction du contenu de l'attribut et doit être supérieure à 3.

La valeur (taille variable) : c'est dans ce champ qu'est contenu l'information véhiculée par l'attribut.

La littérature définit le terme de AVP (Attribute Value Pair). En français cette abréviation est parfois traduite en paire A/V (pour paire d'attribut et de valeur). En effet, un attribut est similaire à une variable informatique. Une variable étant caractérisée par son nom, son type et sa valeur, il en va de même pour un attribut.

Les types d'attributs sont bien entendu standardisés et peuvent être :

L'attribut numéro 26 est très particulier. Baptisé Vendor-Specific, il permet aux équipementiers de définir leurs propres paires A/V. Chaque vendeur s'est vu attribuer un identifiant spécifique (sur 1 octets). Les paires A/V spécifiques au vendeur sont encapsulées dans l'attribut 26 comme représenté dans le schéma ci-dessous :

La plupart des implémentations RADIUS utilisent un dictionnaire pour stocker leurs informations. Un dictionnaire peut par exemple être concrétisé dans un simple fichier. L'annexe 3 montre un exemple de ce a quoi peut ressembler un dictionnaire. L'emploi d'un dictionnaire est surtout très avantageux pour définir ses propres attributs (dans le cas de l'utilisation d'attribut Vendor-Specific évidemment).

Une liste exhaustive des paires A/V et de leur utilisation n'a pas sa place dans ce travail, les attributs étant clairement définis dans les documents de standardisation.

. . . EAP

Défini par le RFC 2284, EAP est l'abréviation de Extensible Authentication Protocol. Ce protocole n'est pas un composant requis dans un serveur RADIUS mais est inclus dans de nombreuses implémentations. EAP est une extension du protocole PP. L'abréviation EAP seule est communément admise, bien que les RFC parlent logiquement de PPP-EAP.

PPP est utilisé afin d'établir une communication point a point. Il prévoit trois phases consécutives. Tout d'abord, l'établissement d'un lien entre les deux intervenants a l'aide du protocole LCP (Link Control Protocol). Ensuite, ce lien étant établi, une phase optionnelle d'identification peut avoir lieu. Pour finir, ce sont les protocoles NCP (Network Control Protocols) qui sont utilisés pour configurer le protocole réseau employé durant toute la durée de la communication.

C'est au niveau de la deuxième phase de PPP que EAP entre en jeu. Au lieu d'imposer une phase d'identification, ce protocole entame d'abord une négociation sur la méthode d'authentification qui va ensuite être employée. Après que la négociation a abouti, la méthode retenue est appliquée. L'intérêt de cette façon de travailler réside dans le fait de supporter virtuellement n'importe quelles méthodes d'authentifications (d'oü l'emploi du terme extensible). Ces dernières peuvent alors être vues comme de simples plugins (ou librairies). Ces librairies seront installées aussi bien sur le client PPP que sur le serveur PPP.

Les NAS et les serveurs RADIUS modernes supportent cette extension. Pour ce qui est du NAS, lors d'une communication EAP, il agit comme une passerelle entre le client et le serveur RADIUS (voir le schéma ci-après). Ces deux dernières entités doivent donc avoir au moins une méthode d'authentification en commun.

Les méthodes pouvant intervenir lors d'une authentification utilisant EAP sont diverses. Citons en quelques-unes :

· EAP-MD5 est similaire à CHAP.

· EAP-GTC (GTC : Generic Token Card) : cette méthode utilise une carte
sur laquelle est noté un simple texte représentant un jeton (token).

· EAP-OTP (OTP : One Time Password) : cette méthode est basée sur l'emploi de fonctions de hachage de manière a ce que un hash (sur base d'un mot de passe, par exemple) ne soit utilisé que lors d'une et d'une seule transaction.

· EAP-TLS (Transport Layer Security) : cette méthode emploie une infrastructure à clés publiques pour authentifier les différentes parties.

Afin de supporter EAP, RADIUS définit deux nouveaux attributs EAPMessage et Message-Authenticator. La séquence classique d'authentification du client se passe comme suit :

Le client contacte le NAS et demande une identification de type EAP.

Le NAS envoie alors un paquet de type EAP-Request/Identity au client.

Le client répond par paquet de type EAP-Response/Identity.

Le NAS (qui pour rappel est un client RADIUS), contacte maintenant le serveur RADIUS et lui envoie un paquet de type Access-Request en encapsulant la demande du client dans l'attribut EAP-Message.

Le serveur RADIUS qui est compatible EAP, renvoie un paquet de type Access-Challenge contenant aussi un attribut EAPMessage.

Le NAS décapsule alors l'attribut et le transfert au client.

Le protocole d'authentification continue alors avec le nombre d'itérations nécessaires aboutissant en fin de parcours soit a un Access-Accept ou à un Access-Reject de la part du serveur RADIUS.

111.2. Gestion des types d'authentification

La plupart des serveurs permettent d'activer/désactiver les différentes

méthodes d'authentification qu'ils supportent. Un petit rappel des protocoles disponibles et leurs propriétés :

PAP : Password Authentication Protocol. C'est la méthode la plus simple. Le mot de passe voyage en clair entre la client et le NAS (cet

38

échange étant encapsulé par PPP par exemple). Il est ensuite chiffré par le secret partagé entre le NAS et le serveur radius. Une fois le mot de passe reçu, il est déchiffré et comparé à celui stocké dans la base de données.

CHAP : Challenge-Handshake Authentication Protocol. Ici, le mot de passe n'est pas envoyé sur le réseau mais on envoie une preuve de la connaissance de celui-ci au travers du succès d'un challenge (un défi), ce qui peut sembler plus intéressant qu'un mot de passe circulant en clair. Malheureusement, l'inconvénient de cette technique est qu'elle nécessite d'avoir accès au véritable mot de passe, et non a un hachage a sens unique de celui ci. En effet, les règles de bonne pratique en ce qui concerne le stockage des mots de passe recommandent vivement de ne pas enregistrer ce dernier en clair

(afin de réduire notamment la possibilité d'usurpation d'identité). C'est ce que font d'ailleurs par défaut la majorité des systèmes d'exploitations.

MS-CHAP: Microsoft Challenge-Handshake Authentication Protocol. Cette technique mise au point par la firme de Redmond est une modification de CHAP afin de pallier le problème d'accès au mot de passe. Elle permet en effet d'effectuer une authentification par challenge sans que le serveur n'ait a connaître réellement le mot de passe (le serveur ne connaissant

ème

que le hash de celui-ci). Deux versions co-existent, la 2 étant plus sûre car

ère

créée pour pallier le manque de la 1 .

EAP : Extensible Authentication Protocol qui n'est pas un protocole d'authentification a proprement parler. Il s'agit en fait d'un protocole d'accès, tout comme PPP, qui permet (a l'instar de ce dernier) une plus grande souplesse dans la négociation de la méthode d'authentification. C'est donc au

ème

niveau de la 2 couche du modèle OSI (802.1x) qu'il intervient. Pour l'utiliser, il

faut bien entendu disposer de NAS (points d'accès sans fil ou switchs) compatibles avec ce protocole. Ces derniers étant configurés pour transférer les requêtes AAA vers un serveur radius par exemple. FreeRADIUS supporte diverses méthodes d'identifications EAP que sont EAP-MD5, LEAP, EAP-GTC, EAP-SIM, EAP-TLS, EAP-TTLS, EAP-PEAP.

NB: le protocole digest (issu de l'authentification http) est également disponible mais assez peu employé. L'idée est la même que pour MS-CHAP lors de l'entrée en session, les preuves d'identités qui continuent a circuler durant la session étant dérivée de divers paramètres aléatoires passés lors de l'initiation du protocole et modifiés au cours des échanges. Ce dernier est utilisé notamment par certains serveurs SIP.

Afin d'activer PAP, CHAP et MS-CHAP dans FreeRADIUS, il suffit que ces lignes soient présentes dans le fichier radiusd.conf :

pap {encryption_scheme = md5}

chap {authtype = CHAP}

mschap {authtype = MS-CHAP}

Le paramètre utilisé pour PAP est la méthode de hashing utilisée pour stocker le mot de passe de l'utilisateur (clear, crypt, md5 ou sha1). La méthode proposée par Microsoft peut prendre d'autres paramètres particuliers a certaines implémentations. Mais pour une utilisation générique, ils peuvent être ignorés.

Pour EAP : se rendre dans le fichier eap.conf (inclus par défaut dans le fichier de configuration principal). La variable default_eap_type permet de choisir un type d'authentification par défaut. Le reste de la configuration dépendra des méthodes EAP que l'on souhaite utiliser.

. 3. Problèmes de sécurité, attaques et contre-mesure 111.3.1. Les paquets de type Access-Request

Le problème de sécurité réside dans le fait que le standard ne prévoit aucune vérification pour ce type de message. Bien entendu, le serveur RADIUS vérifie qu'un paquet Access-Request est bien transmis par un de ses clients, mais les techniques de subtilisation d'adresses IP (IP spoofing) sont aujourd'hui une réalité. Si un opposant est capable de se faire passer pour un NAS, il peut alors effectuer une série d'attaques afin de déterminer, par exemple, le mot de passe d'un utilisateur.

La contre mesure proposée est de rendre l'utilisation de l'attribut Message-Authenticator obligatoire dans tous les paquets de type Access-Request. Si cet attribut n'est pas présent, le serveur ignore le message. L'attribut Message-Authenticator est le résultat d'une fonction de hachage utilisant le secret partagé comme clé.

111.3.2. Attribut User-Password

L'attribut User-Password est protégé par une méthode qui n'est pas considérée comme crypto graphiquement sûre. Elle est basée sur un chiffrement en chaîne (similaire au chiffrement de Vernam).

La clé employée pour ce chiffrement est le résultat d'un hachage MD5 du secret partagé concaténé au Request-Authenticator. La taille du message à chiffrer est fixée à 16 octets. Si le mot de passe est composé d'au moins de 16 caractères, il est complété par des caractères de valeur null. Les deux valeurs sont ensuite XORées et placées dans le paquet envoyé sur le réseau.

L'attaque est basée sur l'idée que, sur un système chargé, le champ Request-Authenticator fini tôt ou tard par utiliser une ancienne valeur. Si l'opposant est capable de sniffer le trafic entre un NAS et un serveur RADIUS et de se constituer une base de données de Request-Authenticator, il finira par posséder deux messages chiffrés par la même clé. Le résultat d'une opération XOR sur ces deux messages sera deux password (ou partie de password) XORé, ce qui permettra plus que probablement de déduire le mot de passe.

~ . . Secret partagé

Une grande critique faite a RADIUS est qu'il autorise l'emploi du même secret partagé pour plusieurs clients (ce qui facilite grandement les attaques). De plus, ce secret n'a pas de longueur minimum et certaine implémentation du serveur (ou certain NAS) le limite parfois à 16 caractères. Enfin, le secret est souvent entré a l'aide d'un clavier n'autorisant pas l'emploi des 256 valeurs possibles pour chaque caractère.

Une attaque peut être tentée pour déterminer le secret partagé. Celleci suppose que l'opposant peut soumettre une requête à un NAS et sniffer en même temps le trafic entre ce NAS et le serveur RADIUS. L'opposant soumet un mot de passe de son choix (et de moins de 16 caractères) au NAS et intercepte le paquet Access-Request. Vu qu' il connaît le mot de passe, un simple XOR lui renvoie le MD5 (voir ci-avant). Ce hash contient le secret partagé et un Request Authenticator connu. L'opposant peut maintenant déterminer (hors connexion), le secret partagé en utilisant une attaque de type brute force.

~ . . Quelques mots sur Diameter

RADIUS a été la première véritable implémentation d'un protocole AAA. Il est connu et utilisé par la majorité des équipementiers en télécommunication ce qui lui assure encore une belle carrière. Néanmoins, les manquements inhérents à sa conception ont encouragé de nouvelles initiatives. Diameter est l'une d'entre elles et commence déjà a faire parler d'elle. Sa

18

standardisation est toujours en cours , les documents déjà disponibles a l'IETF en sont encore au stade de brouillon (Internet-Draft)¹⁹.

Diameter peut se définir comme une amélioration de RADIUS (ce qui n'est pas étonnant étant donné que les notions de bases sont édictées par l'architecture AAA). En quelque sorte, Diameter corrige les défauts de son prédécesseur. Les avantages de Diamater sur RADIUS sont les suivants :

Amélioration du transport :

Augmentation conséquente de la taille des paquets (16 Mo au lieu de 4 Ko).

19 http://docs.hp.com/en/T1428-90011/index.html

19 Utilisation de TCP ou de SCTP

en lieu et place de UDP. Ces

deux protocoles sont adaptés aux problématiques de congestion réseau.

Les paquets perdus sont retransmis par le plus proche voisin. Avec RADIUS, lorsqu'une requête est perdue, c'est le NAS a l'origine de cette requête qui, puisqu'il ne recevra pas de réponse, décidera de réémettre une nouvelle demande.

Une connexion persistante est utilisée entre chaque partie de façon à détecter une panne éventuelle.

Amélioration du proxying :

Le maillage entre les intervenants combiné à la détection des
pertes provoquent la retransmission du paquet au bon endroit.
Un intervenant ne pouvant joindre son voisin par défaut

transférera le paquet en utilisant un autre chemin (si celui-ci

permet d'aboutir a destination).

· Un intervenant a la possibilité de mettre des requêtes en attente. Grâce à cela, si un lien est interrompu momentanément (et qu'il est la seule voie d'accès), les paquets seront envoyés dès le rétablissement de celui-ci.

Amélioration du contrôle des sessions :

La gestion des sessions est indépendante de l'accounting. Un type de paquet spécifique est destiné à la gestion des sessions. Le serveur peut demander la clôture d'une session ou demander une ré-authentification.

Amélioration de la sécurité :

La sécurité de proche en proche est assurée via IPSEC ou TLS. Diameter propose une sécurité de bout en bout en utilisant le chiffrement et les procédures de signature digitale.

Plus besoin de secret partagé.

. . Périphérie du serveur RADIUS

Comme stipulé précédemment, il existe diverses bases de données utilisateurs dont la plus importante (celle des utilisateurs internes) est stockée dans Active Directory. Dans ce cas, la plupart des administrateurs systèmes décideraient de consolider cette base et y centraliseraient le maximum d'informations. La démarche a été tout autre.

solution étant intimement liée à AD, faire marche arrière était impossible.

Un choix de raison a donc été fait : celui d'avoir, non pas une, mais deux bases de données d'utilisateurs. Les membres du personnel restant gérés par l'infrastructure Windows déjà en place et tous les autres étant regroupés dans une base de données MySQL.

Le dernier problème à résoudre est de déterminer le chemin par lequel Free RADIUS va accéder à la DB utilisateur de AD. Trois choix possibles :

Utiliser NTLM et une simple authentification basée sur MS-CHAP. (Cette technique est abordée au point 5.4.4.4)

Utiliser le connecteur LDAP d'Active Directory. Qui permet a la fois l'authentification et l'autorisation, mais oblige l'utilisation du protocole PAP (voir le point 5.4.4.3)

Installer IAS et utiliser FreeRADIUS comme proxy.

ème

C'est la 2 solution qui a été retenue assumant le fait que l'on ne

souhaitait pas utiliser IAS et que l'utilisation de LDAP n'imposait aucune modification sur les serveurs Microsoft. La contrainte de l'utilisation de PAP ne posait pas de problèmes, les paquets étant restreints au VLAN de management car les applications employées par ces utilisateurs sont de type WEB.

Le schéma ci-après clôture cette partie. Il est organisé autour du serveur radius, on y retrouve tous les intervenants et les protocoles utilisés. Les traits de couleurs caractérisent les protocoles : en rouge le type d'authentification entre le client final et le NAS, en vert les paquets radius, en jaune les échanges de certificats et en bleu l'accès vers les bases de données.