4.2.1.3. EAP-TLS (Transport Layer Security)
Comme d'autres protocoles (SMTP-TLS, IMAP-TLS, HTTPS, etc.),
EAP s'appuie sur TLS pour proposer une authentification
sécurisée. Cette méthode s'appuie sur les certificats
électroniques. Ainsi, chaque partie (serveur et client) doit
posséder un certificat pour prouver son identité.
L'utilisation de certificats possède des avantages et
des inconvénients. Ils sont souvent considérés comme plus
sûrs que les mots de passe, cependant les opérations de gestion
qu'ils engendrent peuvent se révéler fastidieuses
(création, suppression, listes de révocation etc.) et l'existence
d'une infrastructure de gestion de clés (IGC) est requise. La
distribution des certificats aux clients est une contrainte qu'il ne faut pas
négliger.
Figure 12: Diagramme d'échange
EAP-TLS
61
Les explications suivantes se réfèrent aux
étapes numérotées dans la figure 12.
1. Le client s'associe physiquement au point d'accès.
Le point d'accès envoie une requête d'authentification au
client.
2. Le client répond avec son identifiant (nom de
machine ou login), ce message est relayé par le point d'accès
vers le serveur Radius.
3. Le serveur Radius initie le processus d'authentification
TLS par le message TLS start.
4. Le client répond avec un message
client_hello, qui contient :
· des spécifications de chiffrement vides en
attendant qu'elles soient négociées entre le client et le serveur
;
· la version TLS du client ;
· un nombre aléatoire (défi ou
challenge) ;
· un identifiant de session ;
· les types d'algorithmes de chiffrement
supportés par le client.
5. Le serveur renvoie une requête contenant un message
server_hello suivi
· de son certificat (x509) et de sa clé
publique ;
· de la demande du certificat du client ;
· d'un nombre aléatoire (défi ou
challenge) ;
· d'un identifiant de session (en fonction de celui
proposé par le client).
Le serveur choisit un algorithme de chiffrement parmi ceux qui
lui ont été proposés par le client.
6. Le client vérifie le certificat du serveur et
répond avec son propre certificat et sa clé publique.
62
7. Le serveur et le client, chacun de son côté,
définissent une clé de chiffrement principale utilisée
pour la session. Cette clé est dérivée des valeurs
aléatoires que se sont échangées le client et le serveur.
Les messages change_cipher_spec indiquent la prise en compte du
changement de clé. Le message TLS_finished termine la phase
d'authentification TLS (TLS handshake), dans le cas d'EAP-TLS la
clé de session ne sert pas à chiffrer les échanges
suivants.
8. Si le client a pu vérifier l'identité du
serveur (avec le certificat et la clé publique), il renvoie une
réponse EAP sans donnée. Le serveur retourne une réponse
EAP success.
9. La clé de session générée en
(8) est réutilisée par le point d'accès pour créer
une clé WEP qui est transmise au client, dans le cas où il s'agit
d'une station Wifi. La clé de session est valide jusqu'à ce que
le client se déconnecte ou que son authentification expire, auquel cas
il doit s'identifier à nouveau.
Le tunnel TLS créé lors de la création de
la clé de session n'est donc pas exploité. Seul le TLS
Handshake est utilisé, il permet l'authentification mutuelle des
deux parties.
EAP-TLS est une méthode d'authentification performante.
Seul les problèmes liés aux IGC peuvent dissuader de
l'utilisation de cette méthode.
| 
