2.2.2. Le protocole EAP/PEAP
PEAP est un protocole qui a été
développé par Microsoft, Cisco et RSA security pour pallier le
principal problème d'EAP/TLS, à savoir la nécessité
de distribuer des certificats à tous les utilisateurs ou machines. Cela
peut être une charge importante, voire ingérable pour certains
sites.
Comme avec EAP/TLS, c'est une authentification mutuelle qui
s'établit entre le supplicant et le serveur. Mais cette fois, elle est
asymétrique. Le serveur sera authentifié par son certificat
auprès du supplicant qui, lui-même, s'authentifiera auprès
du serveur par la présentation d'un identifiant et d'un mot de
passe.Seul le serveur a besoin d'un certificat. Mais les clients doivent tout
de même installer le certificat de l'autorité qui a émis le
certificat du serveur.
Cela permet de s'assurer que les mots de passe sont
envoyés au bon serveur et non à un usurpateur. Comme un mot de
passe va être envoyé par le supplicant au serveur, il faudra bien
que ce dernier le valide en fonction d'une base d'authentification qu'il pourra
interroger.
Le serveur Radius devra donc être
paramétré de manière à pouvoir valider le mot de
passe. En principe, si on décide d'utiliser PEAP, cela signifie que
cette base existe déjà sur le site. En général, il
s'agit d'une base Windows mais il est aussi possible d'utiliser une base
LDAP.
Une authentification PEAP se décompose suivant le
modèle à quatre étapes d'EAP que nous avons vu
précédemment:
1. Étape « Identité externe ».
2. Étape « Négociation de protocole
».
28
3. Étape « Protocole transporté ».
4. Étape « Clés de chiffrement ».
PEAP n'est autre que la mise en oeuvre des deux phases du
protocole TLS dont nous avons parlé précédemment. Phase
TLS Handshake.
o Le serveur envoie au supplicant une requête de
démarrage de PEAP au moyen d'un paquet EAP-Request contenant
EAP-Type=PEAP (PEAP-start).
o Le supplicant répond (client_hello) avec la liste
des algorithmes de chiffrement qu'il est capable d'utiliser.
o Le serveur envoie son certificat et sa clé publique
au supplicant. Il lui transmet aussi l'algorithme qu'il a choisi parmi la liste
qu'il a reçue précédemment.
o Le supplicant authentifie le certificat du serveur. Il
génère la Pré-Master Key. Celle-ci est chiffrée
avec la clé publique que vient de lui envoyer le serveur.
o Client et serveur calculent la Master Key et le tunnel
chiffré est ainsi établi.
2.2.3. Le protocole EAP/TTLS
TTLS (Tunneled Transport Layer Security) a été
développé par les sociétés Funk Software et
Certicom. Son objectif est exactement le même que celui de PEAP,
c'està-dire fournir un protocole d'authentification mutuelle entre le
poste client et le serveur d'authentification.
Le premier s'authentifie grâce à un couple
identifiant-mot de passe, et le second, avec un certificat. En revanche, la
technique utilisée est différente. Au départ, les choses
sont identiques. Le protocole EAP est mis en oeuvre et se déroule
suivant les quatre étapes que nous avons vues précédemment
: identité externe, négociation de protocole, protocole
transporté, clés de chiffrement. TTLS intervient dans
l'étape « Protocole transporté ».
TTLS se différencie de PEAP à deux niveaux.
D'une part les informations sont transportées au moyen de couples
Attributs/Valeurs (AVP) compatibles avec ceux de Radius. D'autre part, la
notion de serveur TTLS est introduite. Il s'agit d'un serveur qui s'intercale
entre l'équipement réseau et le serveur d'authentification. Bien
sûr, le serveur TTLS n'est pas forcément une machine
séparée du serveur d'authentification.
Le supplicant communique toujours grâce à EAP
avec l'équipement réseau. Ce dernier n'a plus de relation directe
avec le serveur d'authentification, mais avec le serveur TTLS, au moyen du
protocole Radius. C'est également avec Radius que le serveur TTLS
communique avec le serveur d'authentification.
TTLS s'appuie sur TLS pour réaliser, comme avec PEAP,
une authentification en deux phases. La phase TLS Handshake pour établir
un tunnel chiffré, et la phase TLS Record pour faire passer dans le
tunnel un protocole d'authentification par mot de passe.
29
Mais, cette fois, les paquets du protocole d'authentification
dans le tunnel vont être encapsulés dans des paquets du protocole
TTLS qui, eux-mêmes, sont formés de couples Attribut/Valeur (AVP)
compatibles avec ceux de Radius.
| 
