Nouvelle mthode dauthentification EAP-EHash

Omar Cheikhrouhou*, Maryline Laurent-Maknavicius**, Maher Ben Jemaa*

* Unit de recherche ReDCAD, Ecole Nationale dIngnieurs de Sfax, BP W 3038 Sfax, Tunisie Enis01amor@yahoo.fr, maher.benjemaa@enis.rnu.tn ** CNRS Samovar UMR 5157, GET/INT/LOR, 9 rue Charles Fourier, 91011 Evry, France Maryline.Maknavicius@int-evry.fr
RSUM.

Cet article prsente une nouvelle mthode EAP appele EAP-EHash (EHash pour Encrypted-Hash) qui allie la simplicit et la facilit de dploiement de EAP-MD5 et la robustesse de EAP-TLS. Elle se positionne dans les mmes domaines dapplication que ces deux mthodes EAP existantes (authentification dutilisateurs des serveurs, VPN). Pour un meilleur positionnement de ces mthodes, larticle prsente les deux mthodes EAP-TLS et EAP-MD5, puis EAP-EHash et effectue pour chacune une analyse critique. Enfin, la mthode EAP-EHash est valide formellement laide de loutil AVISPA, ce qui prouve quelle vrifie bien les proprits de scurit dsires, en particulier sa robustesse lattaque Man-In-TheMiddle.
ABSTRACT.

This paper describes a new EAP method called EAP-EHash (EHash for EncryptedHash) which combines simplicity and deployment easiness of EAP-MD5 and robustness of EAP-TLS. EAP-EHash is expected to apply in the same application domains than those two existing methods (user authentication to servers, VPN). For a better positioning of each EAP method, the paper presents first the EAP-TLS and EAP-MD5 methods, and then EAPEHash and realizes a critical analysis of each of them. Finally the EAP-EHash method is formally validated with the AVISPA tool, thus proving that it verifies the expected security properties, especially its robustness to Man-In-The-Middle attacks. Authentification, EAP, EAP-MD5, EAP-TLS, EAP-EHash Authentication, EAP, EAP-MD5, EAP-TLS, EAP-EHash

MOTS-CLS : KEYWORDS:

1. Introduction Le succs du concept EAP (Extensible Authentication Protocol) est davoir introduit la distinction entre le protocole EAP (Aboba, 2004) et les mthodes EAP. Le protocole EAP se rsume encapsuler les donnes servant lauthentification et les mthodes EAP prennent en charge lauthentification en mettant en forme et en interprtant ces donnes dauthentification. Il ressort de cette sparation que les protocoles faisant appel une authentification par EAP ne sont plus attachs une mthode EAP particulire. Ainsi, en cas de failles de scurit dcouvertes sur une mthode EAP, il suffit de changer de mthode EAP ; les protocoles sappuyant sur EAP sont conservs. Ce concept est n du besoin rencontr dans les environnements PPP (Point-toPoint Protocol) et 802 dintgrer plusieurs mthodes dauthentification. Lobjectif tait dintroduire de la flexibilit dans lauthentification ralise par les utilisateurs pour se connecter leur rseau daccs. Il en a dcoul en particulier le protocole 802.1X qui permet un point daccs 802.11 (Access Point) dauthentifier les mobiles avant de leur donner accs une infrastructure de rseau. Notons que EAP tait lorigine prvu pour fonctionner au niveau de la couche 2 (modle OSI). Aujourdhui, grce la dfinition du protocole PANA (Protocol for carrying Authentication for Network Access) qui encapsule EAP au dessus de la couche IP, lauthentification dun utilisateur auprs dun rseau daccs est de niveau applicatif. Cette solution EAP/PANA plat beaucoup aux oprateurs car elle est indpendante de la technologie choisie pour laccs (802.11, PPP, Ethernet, WiMax) et facilite le dploiement des solutions de contrle daccs. A ce jour, plus dune quarantaine de mthodes EAP existent, mais seulement six dentre elles sont standardises lIETF (Internet Engineering Task Force). Parmi ces dernires, les mthodes EAP-MD5 (Aboba, 2004) et EAP-TLS (Aboba, 1999) sont les plus simples de mise en uvre mais elles souffrent de plusieurs inconvnients qui les rendent difficiles dexploitation dans les rseaux IP classiques. Cet article est organis de la faon suivante. La section 3 donne une description des mthodes EAP-MD5 et EAP-TLS suivie dune analyse critique. La section 4 introduit une nouvelle mthode EAP-EHash qui allie la simplicit de EAP-MD5, et certaines proprits de EAP-TLS comme lauthentification mutuelle et la rsistance certaines attaques classiques. Aprs une analyse des proprits de scurit apportes par EAP-EHash (cf. section 5), la section 6 prsente les rsultats de validation laide de loutil AVISPA. Enfin la section 7 fait une synthse comparative des diffrentes mthodes EAP. Pour une illustration pratique de ces mthodes, nous nous placerons dans la suite dans un contexte de rseau IEEE 802.11 et nous considrerons quun utilisateur veut accder une infrastructure de rseau IP et procde une authentification. Les lments de rseau considrs sont prsents la section 2.

Mthode dauthentification EAP-EHash

2. Contexte IEEE 802.11 servant illustration des mthodes EAP Sur les illustrations proposes dans la suite de larticle, trois types dquipements sont considrs : le client EAP intgr dans le mobile permet au rseau daccs dauthentifier le mobile avant de lui donner accs ses ressources rseau ; lauthentificateur EAP est lquipement daccs au rseau (point daccs 802.11) qui bloque le trafic en provenance du mobile jusqu ce que le mobile sauthentifie et condition quil dispose des bonnes autorisations. Lauthentificateur ninterprte pas le contenu des messages EAP, mais il relaie les requtes dauthentification au serveur EAP par exemple sous la forme de messages RADIUS (Remote Authentication Dial-In User Service) ; le serveur EAP en gnral intgr dans un serveur AAA (comme RADIUS) ralise lauthentification du mobile et parfois sauthentifie. Notons que les messages EAP entre client et authentificateur sont encapsuls dans le protocole 802.1X et que les messages EAP sont changs entre authentificateur et serveur EAP grce au protocole RADIUS qui peut encapsuler EAP (Aboba, 2003).

3. Description et analyse critique des mthodes EAP-MD5 et EAP-TLS 3.1. EAP-MD5 La mthode EAP-MD5 (Aboba, 2004) se base sur le protocole CHAP (Challenge Handshake Authentication Protocol) (Simpson, 1996) qui vise authentifier un client en utilisant le principe de dfi-rponse. EAP-MD5 ncessite une cl partage entre client et serveur dauthentification. Cette cl consiste gnralement en un mot de passe associ un nom dutilisateur ou une identit (par exemple une adresse IP ou MAC). Comme lillustre la figure 1, aprs requte de lauthentificateur EAP (tape 1), le client dcline son identit (tape 2) dans un message EAP qui est relay au serveur EAP. Ce dernier envoie un dfi alatoire ou challenge au client (tape 3) qui calcule un hash partir de ce dfi et de la cl partage avec le serveur. Le hash est retourn dans un message EAP (tape 4). Le serveur effectue le mme calcul de hash que le client et compare les deux hash. Deux hash identiques signifient que le client possde la bonne cl, ce qui conduit au succs de lauthentification et lmission dun message dacceptation (tape 5a). Sinon, lauthentification choue et le serveur rejette la demande (tape 5b). En fonction de cette dcision, lauthentificateur autorise ou non le client accder au rseau.

EAP over LAN

EAP Over RADIUS

Client

Authenticator

Authentication server (e.g. RADIUS)

EAP Identity Request

1 RADIUS Access Request (EAP) RADIUS Access Challenge (EAP) 3

EAP Identity Response EAP Request

Calculate a hash based on the challenge (sent in message 3) and the shared secret

EAP Response

RADIUS Access Request (EAP)

Verify response hash using the shared secret

Verify?

EAP-Success EAP-Failure

RADIUS Access Accept (EAP) RADIUS Access Reject (EAP)

5a
yes

5b

No

Figure 1. changes EAP-MD5 dans un contexte IEEE 802.11

3.2. EAP-TLS La mthode EAP-TLS (Aboba, 1999) est issue du protocole TLS (Transport Layer Security) (Dierks, 1999) qui vise protger les changes de donnes sur Internet en mettant en uvre lauthentification mutuelle des participants, la confidentialit des donnes, leur intgrit et lauthentification de leur origine. Pour cela, elle encapsule certains messages TLS dans des enregistrements TLS. De plus, confronte la longueur importante des messages obtenus, EAP-TLS gre elle-mme la fragmentation et rassemblage. Comme lillustre la figure 2, aprs avoir dtect la prsence dun nouveau mobile, lauthentificateur initie lauthentification EAP-TLS en demandant lidentit du client. La rponse est ensuite relaye par lauthentificateur jusquau serveur EAP. Dailleurs, dans toute la suite des changes EAP, lauthentificateur ne fait que relayer les messages EAP entre client et serveur.

Mthode dauthentification EAP-EHash

Figure 2. changes EAP-TLS dans un contexte IEEE 802.11 (en cas de succs) Cest le serveur EAP qui engage la procdure dauthentification qui ncessite sept messages. Les messages 2 5 sont une adaptation des changes du protocole Handshake de TLS (Dierks, 1999). Ces messages permettent aux client et serveur de sauthentifier mutuellement laide de leurs certificats de cls publiques, de gnrer une cl matre commune qui servira gnrer dautres cls, de convenir dune suite cryptographique (fonctions de hachage, algorithmes de chiffrement), de vrifier lintgrit des changes TLS effectus. Plus prcisment, les changes EAP-TLS contiennent la transmission des certificats des deux parties (TLS certificate), avec la possibilit den faire la demande explicite auprs de lautre partie (TLS certificate_request). Ils permettent de convenir dune cl matre commune grce aux

changes TLS server_key_exchange et TLS client_key_exchange, de ngocier une suite cryptographique grce aux messages TLS client_hello et TLS server_hello, de protger les changes TLS avec la suite cryptographique nouvellement convenue (TLS change_cipher_spec) et sauthentifier mutuellement entre client et serveur. Le client sauthentifie en mettant sa signature dans TLS certificate_verify, et le serveur grce au message TLS finished qui prouve au client que le serveur possde la bonne cl prive. Enfin les messages 6 et 7 terminent la session EAP-TLS avec lmission dune rponse EAP pour le client indiquant que le serveur sest authentifi avec succs et lmission par le serveur dun message EAP-Success.

3.3. Analyse critique La mthode EAP-MD5 offre lavantage de ne pas ncessiter beaucoup de ressources pour son traitement. De plus elle nexige pas dinfrastructure de gestion de certificats ou de cls publiques (comme le requiert EAP-TLS), mais elle nest pas utilise aujourdhui car elle est reconnue comme vulnrable aux attaques par dictionnaire et aux attaques par force brute. Enfin, EAP-MD5 est une mthode dauthentification unilatrale dans la mesure o le client sauthentifie auprs du serveur, mais ne peut pas authentifier le serveur. Il nest donc pas possible avec cette mthode de dtecter de faux serveurs EAP et donc des points daccs malveillants (contrls par des intrus). La mthode EAP-TLS offre un niveau de scurit lev puisquelle permet lauthentification mutuelle entre le client. Elle est robuste face aux attaques de lhomme du milieu (Man-In-The-Middle) puisquelle repose sur la cryptographie asymtrique (certificats). Linconvnient majeur de cette mthode est quelle repose sur une infrastructure de gestion de cl (PKI - Public Key Infrastructure) pour assurer la gestion des certificats ct client et ct serveur. Or les PKI sont extrmement coteuses et complexes en terme de gestion et de maintenance. De plus, elles ne sappliquent pas trs bien au contexte des mobiles. En effet, il est dusage, pour les certificats lectroniques, de vrifier la non rvocation dun certificat auprs dune autorit ou dun serveur miroir avant de lutiliser pour authentifier lentit. Dans le cas dun mobile, cette phase de vrification ne peut pas tre ralise puisque le mobile na pas encore accs au rseau. Lors de sa demande de connexion, le mobile va donc prendre le risque daccepter comme valide le certificat du serveur alors quil na aucun moyen de vrifier son tat de validit.

4. Mthode EAP-EHash Comme nous lavons vu prcdemment, les mthodes EAP-TLS et EAP-MD5 ne sont pas idales pour fonctionner dans un environnement IEEE 802.11 du fait de leur

Mthode dauthentification EAP-EHash

Figure 3. changes EAP-EHash dans un contexte IEEE 802.11

lourdeur de gestion, de lauthentification unilatrale, des attaques de lhomme du milieu possibles... Dautres mthodes EAP ont t standardises comme EAP-OTP (One-Time-Password) et EAP-GTC (Generic Token Card) (Aboba, 2004), qui sont simples dusage, mais ne proposent quune authentification unilatrale ou encore EAP-SIM (Subscriber Identity Modules) (Haverinen, 2006), et EAP-AKA (Authentication and Key Agreement) (Arkko, 2006) qui ont t spcifies pour fonctionner dans les environnements GSM/UMTS et qui sont plutt prvues pour fonctionner laide de cartes puce. Nous proposons ici une nouvelle mthode EAP-EHash qui se veut simple, et base sur des cls symtriques. Elle permet lauthentification mutuelle, la mise en place dune cl matre, et tire avantage des mthodes EAP-TLS et EAP-MD5 en vitant les vulnrabilits dtectes dans ces mthodes. Pour cela, EAP-EHash suppose quune cl PSK (Pre-Shared Key) est prpartage entre le client et le serveur EAP et reprend le principe du protocole CHAP (Simpson, 1996) qui est lger dans son traitement. EAP-EHash introduit deux mcanismes : un mcanisme pour fournir lauthentification mutuelle et un

mcanisme pour viter les attaques par dictionnaire et par force brute (cf. lanalyse de la section 5). Comme lillustre la figure 3, aprs avoir reu lidentit du client, le serveur EAP rcupre PSK et gnre les lments suivants : RandS : un nombre alatoire Challenge : un dfi (nombre alatoire) utilis pour authentifier le client AK (Authentication Key) : une cl dauthentification drive de la cl PSK AK= F (PSK, RandS) o F est une fonction alatoire sens unique (par exemples HMAC-SHA-1 ou HMAC-MD5). EK (Encryption Key) : cl de chiffrement servant chiffrer les champs MIC et HASH et drive de PSK EK= F (PSK, RandS || ServerID || ClientID) o || dsigne la concatnation, et ClientID/ServerID sont les identifiants des client et serveur. MIC (Message Integrity Check) : contrle dintgrit cryptographique calcul sur les donnes transmettre avec la cl AK, puis chiffr avec EK. MIC = F (AK, Challenge || ServerID || RandS) Le serveur envoie lensemble de ces paramtres (message 1 de la figure 3), y compris le champ MIC chiffr avec la cl EK, au client via lauthentificateur. rception de ce message, le client gnre les mmes cls AK et EK que le serveur ( partir de PSK) et authentifie le serveur en comparant le MIC chiffr reu avec le MIC calcul localement par le client. Le serveur est correctement authentifi uniquement en cas de MIC identiques. Les cls AK et EK sont utilises pour viter de trop exposer la cl PSK en en faisant une exploitation directe dans la gnration des MIC. En cas de succs de lauthentification du serveur, le client gnre un nombre alatoire RandC et sauthentifie son tour en calculant un HASH partir du Challenge envoy par le serveur comme suit : HASH = F (AK, Challenge || RandC). Dans le message 2, le client envoie RandC et la valeur du HASH chiffre avec EK, au serveur, dans un message EAP-Response. Le serveur qui reoit le message authentifie le client en comparant le HASH reu avec celui calcul en local. Dans le cas dune authentification du client russie, une nouvelle cl IK est calcule : IK= F (PSK, RandS || RandC). Cette cl IK pourra par exemple servir initialiser le protocole IKE (Internet Key Exchange) dans le cas dun besoin de VPN IPsec entre le client et le point d'accs, ou bien elle servira driver des cls de chiffrement IEEE 802.11 partages entre le client et le point d'accs. Notons que le serveur EAP devra alors communiquer cette cl IK au point daccs. Le message 3 de dauthentification EAP. type EAP-Success termine finalement la phase

Mthode dauthentification EAP-EHash

5. Analyse de EAP-EHash La mthode EAP-EHash prsente plusieurs avantages, savoir : Traitement lger : Base sur la cryptographie symtrique, EAP-EHash nexige pas de traitements importants. Cette proprit est essentielle dans les rseaux sans fil puisque les nuds mobiles prsentent des ressources limites en terme de batterie, de puissance de calcul et de capacit mmoire. Authentification rapide : Comme EAP-MD5, EAP-EHash est base sur un mcanisme de dfi/rponse et par consquent exige peu d'changes de messages. Le nombre rduit des messages changs rend lauthentification rapide. Cette proprit est importante dans les rseaux sans fils puisque les noeuds sont mobiles et peuvent tout moment perdre leurs connexions, ce qui est trs perturbant pour les mthodes dauthentification et oblige le mobile rinitialiser la procdure. Authentification mutuelle : La mthode EAP-MD5 ne permet pas au client dauthentifier le serveur, et donc de dtecter un point daccs frauduleux qui serait mis en place par une personne malveillante dans le but despionner les communications des mobiles. La mthode EAP-EHash permet de se prmunir de cette attaque en permettant une authentification mutuelle qui se base sur une cl prpartage. Efficacit contre les attaques par dictionnaire : Avec EAP-MD5, il est possible de raliser une attaque par dictionnaire car un espion peut avoir accs au texte en clair et au hash correspondant et se servir de ces informations pour dcouvrir la cl pr-partage. Avec EAP-EHash, cette attaque nest plus possible car le hash (que ce soit le MIC mis par le serveur ou le HASH mis par le client) est chiffr avec la cl EK. 6. Spcifications et validation Cette section prsente les rsultats de validation de la mthode EAP-EHash obtenus laide de loutil AVISPA (Automated Validation of Internet Security Protocols and Applications) (AVISPA, 2006). Les spcifications obtenues sont disponibles (Cheikhrouhou, 2006-1), et la figure 4 en prsente un extrait. Les proprits suivantes ont pu tre testes : Authentification mutuelle : Le client authentifie le serveur par vrification du champ MAC car linstruction suivante permet de vrifier que le champ MAC reu du serveur est gal la valeur attendue, ce qui prouve que le serveur a pu calculer la valeur des cls AK et EK et donc quil connat la valeur de la cl pr-partage PSK MAC'={MIC(AK',Challenge'.serverId.RandS')} EK'.

De mme, linstruction HASH'={HMAC(AK,Challenge.RandP')}_EK permet au serveur de vrifier que le HASH calcul par le client correspond bien au dfi (Challenge) envoy.

role server( ... played_by S def= ... 1.State=1 /\ RCV(respond_id.peerId)=|> State':=2 /\ RandS':=new() /\ Challenge':=new() /\ AK':=PRF(PSK.RandS') /\ EK':=PRF(PSK.RandS'.serverId.peerId) /\ MAC':={MIC(AK',Challenge'.serverId.RandS')}_EK' /\ SND(Challenge'.serverId.RandS'.MAC') /\ witness(S,P,rs,RandS') /\ witness(S,P,ch,Challenge') /\ secret(AK',sec_ak,{P,S}) /\ secret(EK',sec_ek,{P,S}) 2. State=2 /\ RCV(RandP'.HASH') /\HASH'={HMAC(AK,Challenge.RandP')}_EK =|> State':=3 /\ request(S,P,RandP') /\ SND(success) end role %server %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role peer( ... played_by P def= ... 1.State=1 /\ RCV(Challenge'.serverId.RandS'.MAC') /\ AK'=PRF(PSK.RandS') /\ EK'=PRF(PSK.RandS'.serverId.peerId) /\ MAC'={MIC(AK',Challenge'.serverId.RandS')}_EK' =|> State':=2 /\ RandP':=new() /\ HASH':={HMAC(AK',Challenge'.RandP')}_EK' /\ SND(RandP'.HASH') /\ witness(P,S,rp,RandP') /\ request(P,S,rs,RandS') /\ request(P,S,ch,Challenge') /\ secret(AK',sec_ak,{P,S}) /\ secret(EK',sec_ek,{P,S}) ... end role %peer %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role environnement() def= const p,s,i:agent, mic,h,prf:function, psk_ps,psk_pi,psk_is:symmetric_key intruder_knowledge={p,s,mic,h,prf,psk_pi,psk_is} composition session(p,s,psk_ps,mic,h,prf) /\session(p,i,psk_pi,mic,h,prf) /\session(i,s,psk_is,mic,h,prf) end role

Figure 4. Extrait des spcifications de EAP-EHash dans le langage HLPSL (cf. (Chreikhrouhou, 2006-2) pour les spcifications dtailles)

Mthode dauthentification EAP-EHash

Secret des cls : Dans le langage de spcification HLPSL (High-Level Protocol Specification Language) (Chevalier, 2004) dfini par AVISPA, il est possible dexprimer que les cls AK et EK doivent rester secrtes entre client (P) et serveur (S), grce aux deux instructions : secret(AK',sec_ak,{P,S}) et secret(EK',sec_ek,{P,S}). Robustesse lattaque de lhomme du milieu : Le but de lhomme du milieu est de partager une cl de session IK_as avec le serveur et IK_pa avec le client en leur faisant croire quils communiquent en direct de faon protge. Cette attaque est possible si les paramtres changs servant la construction de la cl ne sont pas authentifis. Les deux primitives request et witness de HLPSL permettent dauthentifier lorigine des messages. Linstruction witness(P,S,rp,RandP'), signifie que le client P veut communiquer avec le serveur S en utilisant la valeur RandP' comme valeur du paramtre rp, et linstruction request(S,P,rp,RandP'), que le serveur S a accept la valeur RandP' comme valeur de rp et maintenant doit vrifier que cette valeur est rellement envoye par P. De mme le client doit authentifier le serveur sur la valeur de RandS. Cette proprit a t vrifie avec succs dans la mthode EAP-EHash et par consquent elle est robuste contre lattaque Man-In-the-Middle. Protection contre le rejeu des messages : Pendant la phase de validation, loutil AVISPA rejoue danciens messages (utiliss dans une session antrieure). Le rsultat de la validation montre que la mthode EAP-EHash est robuste contre le rejeu. En effet, les deux paramtres RandP et RandS permettent dassurer la fracheur des messages changs.

Mthodes EAP EAP-TLS

Authentification mutuelle Oui

Principe Base sur TLS et des certificats lectroniques Dfi-rponse Dfi-rponse avec chiffrement de la rponse

Infrastructure PKI exige Oui

Rapidit de lauthentification Lente

EAP-MD5 EAPEHash

Non Oui

Non Non

Rapide Rapide

Tableau 1. Synthse comparative des mthodes EAP

7. Conclusions Partant du constat que le concept du protocole EAP est couramment utilis dans les rseaux IP filaires ou sans fil pour authentifier les utilisateurs, et que les mthodes EAP courantes (EAP-TLS et EAP-MD5) dans ces environnements l noffrent pas toutes les proprits attendues pour une mise en uvre aise, nous

proposons la mthode EAP-EHash. Cette dernire offre des proprits intressantes de simplicit, de rapidit dexcution, dauthentification mutuelle et de robustesse face des attaques comme lhomme du milieu ou des attaques par dictionnaire. Le tableau 1 compare les proprits obtenues pour EAP-EHash et pour deux autres mthodes classiques (EAP-TLS et EAP-MD5). En particulier, il met en vidence sa simplicit de dploiement sans besoin dinfrastructure PKI (contrairement EAP-TLS), lassurance de se connecter un rseau lgitime grce lauthentification mutuelle, et une consommation en nergie modeste au niveau du mobile pendant la phase dauthentification du fait de la rapidit dexcution et du traitement simple de EAP-EHash. Pour faciliter son dploiement grande chelle, il serait envisageable de considrer que la cl pr-partage est gnre partir dun mot de passe connu de lutilisateur ; ainsi, serait limin le problme du stockage (confidentiel) de la cl dans le mobile et on se retrouverait avec la mme facilit dusage que pour EAP-MD5 tant sur les environnements IP de rseaux filaires que sans fil. 8. Remerciements Nous tenons remercier Monsieur Mohamed Jmaiel (ENIS, Tunisie) pour son aide sur la validation, ainsi que le GET qui a soutenu le projet EcoMesh. 9. Bibliographie
Aboba B., Simon D., PPP EAP TLS Authentication Protocol, RFC 2716, October 1999. Aboba B., Calhoun P., RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP), RFC 3579, September 2003. Aboba B., Blunk L., Vollbrecht J., Carlson J., Levkowetz H., Extensible Authentication Protocol (EAP), RFC 3748, June 2004. Arkko J., Haverinen H., Extensible Authentication protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), RFC 4187, January 2006. AVISPA project, disponible http://www.avispa-project.org, 2006. Cheikhrouhou O., Laurent-Maknavicius M., Ben Jemaa M., Scurit des rseaux mesh sans fil, rapport de Master Recherche, Ecole Nationale d'Ingnieurs de Sfax, 2006-1. Cheikhrouhou O., Laurent-Maknavicius M., Ben Jemaa evry.fr/~maknavic/articles/EAP-EHash-web.pdf, 2006-2. M., http://www-lor.int-

Dierks T., Allen C., The TLS Protocol Version 1.0, RFC 2246, January 1999. Haverinen H., Salowey J., Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM), RFC 4186, January 2006. Chevalier Y., Compagna L., Cuellar J., Drielsma P.H., Mantovani J., Modersheim S., Vigneron L.., A High Level Protocol Specification Language for Industrial SecuritySensitive Protocols , Automated Software Engineering, Vol.180, Sept. 2004, p. 193-205. Simpson W., PPP Challenge Handshake Authentication Protocol (CHAP), RFC 1994, August 1996