4.2.1.4. EAP-TTLS (Tunneled TLS) et EAP-PEAP (Protected
EAP)
Ces deux méthodes sont assez similaires. Elles
s'appuient sur la confidentialité proposée par l'encapsulation
dans un tunnel pour réaliser une authentification via login/mot de passe
ou token-card.
63
On distingue deux phases d'authentification :
· Première phase : identification du serveur par
le client en utilisant un certificat (validé par une autorité de
certification)
· Deuxième phase : identification du client par
le serveur par login/password
À l'issue de la première phase, le tunnel TLS
chiffré s'établit, garantissant une grande confidentialité
des échanges pour la phase 2 où le client transmet ses
éléments d'authentification (login/password) via CHAP,
PAP, MS-CHAP ou MS-CHAPv2 pour EAP-TTLS et
MS-CHAPv2, token-card ou certificat (similaire à
EAP-TLS) pour EAP-PEAP.
La différence principale entre EAP-PEAP et EAP-TTLS
vient de la manière d'encapsuler les échanges lors de la
deuxième phase. Pour EAP-PEAP, les données
échangées entre le client et le serveur au travers du tunnel TLS
sont encapsulées dans des paquets EAP. EAP-TTLS utilisent des AVP
(Attribute-Values Pairs) encapsulées dans des paquets EAP-TTLS,
le format AVP d'EAP-TTLS est compatible avec le format AVP de Radius, ce qui
simplifie les échanges entre le serveur EAP-TTLS et le serveur Radius
qui contient les informations relatives aux utilisateurs, dans le cas où
les informations ne sont pas directement stockées sur le serveur
EAP-TTLS. La méthode EAP-PEAP ne peut-être utilisée qu'avec
un serveur Radius supportant EAP (figure 13). EAP-TTLS est plus souple, il est
toujours nécessaire de dialoguer avec un serveur EAP, cependant ce
serveur peut retransmettre directement la requête auprès d'un
serveur Radius ne gérant pas EAP (figure 6).
64
Figure 13: Echanges EAP-TTLS
L'avantage présenté par ces deux méthodes
vient du fait que le client peut être authentifié par mot de
passe, on supprime donc la complexité de gestion liée aux
certificats caractéristique de EAP-TLS, tout en proposant une
authentification mutuelle. PEAP est proposé nativement dans Windows 7 et
Windows XP, ce qui peut grandement faciliter son déploiement. Par
ailleurs, l'implémentation de EAP-PEAP dans les clients
d'authentification proposés par Cisco n'est pas compatible avec celle de
Microsoft. Ainsi, on ne pourra pas s'authentifier avec EAP-PEAP depuis un
client natif Windows sur un serveur Radius Cisco de type ACS.
EAP-TTLS et PEAP s'adressent principalement aux sites ne
disposant pas d'IGC. De plus, il est tout à fait possible d'utiliser les
informations stockées dans un annuaire LDAP relié au serveur
RADIUS pour proposer un identifiant unique pour toutes les applications.
65
Figure 14: Diagramme d'échanges EAP-TTLS ou
EAP-PEAP
Les explications suivantes se réfèrent aux
étapes numérotées dans la figure 7.
1 à 5) Les échanges sont presque similaires
à EAP-TLS. Le client authentifie le serveur par l'intermédiaire
d'un certificat (étape 5).
6) Cette étape diffère légèrement
d'EAP-TLS car le client n'a pas besoin de fournir de certificat, la clé
qui sert à chiffrer la session peut donc être créée
directement. À la fin de cette étape, le TLS handshake
est terminé, les échanges suivants seront donc chiffrés
par la clé de session.
7) En effet, l'établissement d'un tunnel TLS permet de
chiffrer les échanges, le client fournit donc ses identifiants
(login/mot de passe) au serveur en utilisant par exemple MS-CHAPv2.
8 et 9) Similaires à EAP-TLS
66
EAP-TTLS et EAP-PEAP sont des méthodes très
proches et l'utilisation d'un tunnel TLS chiffré leur confère un
bon niveau de confidentialité. EAP-PEAP présente l'avantage
d'être supporté nativement par Windows XP et 2000. EAP-TTLS permet
une meilleure interopérabilité avec les serveurs Radius ne
supportant pas EAP.
| 
