Master SecuriteReseauxMesh OCheikhrouhou FR

Rpublique Tunisienne
Cycle de Formation Doctorale

dans la discipline informatique

NTSID
Mmoire de MASTERE
N dordre: 2006
Ministre de lEnseignement Suprieur

Universit de Sfax
Ecole Nationale dIngnieurs de Sfax

MEMOIRE
prsent

lEcole Nationale dIngnieurs de Sfax

en vue de lobtention du

MASTERE

Nouvelles Technologies des Systmes Informatiques Ddis

par

Omar Cheikhrouhou
(Ingnieur Gnie Informatique)

Scurit des rseaux mesh sans fil

soutenu le 20 mai 2006 , devant la commission d'examen:

M. Mohamed JMAIEL Prsident
M. Slim KANOUN Rapporteur
M. Maher BEN JEMAA Encadreur

Scurit des rseaux mesh sans fil

Omar Cheikhrouhou

.. :
. .
" 1.2.8 " . . .
.
. . . . ........................... -
........................................................

Rsum: Les rseaux mesh sans fil reprsentent la technologie sans fil la plus
rcente. Cependant, la scurit reste un vritable dfi pour cette technologie.
Dans ce rapport, nous proposons des solutions pour la scurit des rseaux mesh
sans fil multi-sauts. D'abord, nous avons propos une extension du mcanisme
d'authentification du protocole 802.1x afin de l'adapter un environnement
multi-sauts et en particulier les rseaux mesh. Ensuite, nous avons dfini des
architectures de rseaux mesh sans fil utilisant le protocole PANA comme
mcanisme dauthentification et de contrle daccs. Enfin, nous avons propos
une nouvelle mthode d'authentification EAP particulirement adapte
l'environnement des mobiles. Cette mthode a t formellement valide.

Abstract: Wireless mesh networks is an evolving newest technology. However,
security is a critical challenge for that technology. In this report, we propose
solutions to secure multi-hops wireless mesh networks. First, we proposed an
extension of the 802.1x authentication framework to be used in a multi-hops
environment. Then, we defined architecture of wireless mesh networks using the
protocol PANA as an authentication and authorization framework. Finally, we
proposed a new EAP authentication method suitable for wireless mesh networks.
This method was formally validated.

: , , , PANA, EAP .
Mots cls : rseaux mesh sans fil, scurit, authentification, contrle d'accs,
PANA, EAP.

Key-words: wireless mesh networks, security, authentication, authorization,
PANA, EAP.
Scurit des rseaux mesh sans fil Omar Cheikhrouhou
Sommaire
Sommaire................................................................................................................................... 1
Liste des figures......................................................................................................................... 3
Liste des tableaux....................................................................................................................... 4
Introduction................................................................................................................................ 5
Introduction................................................................................................................................ 5
Chapitre 1: Les rseaux mesh sans fil ........................................................................................ 6
1 Introduction........................................................................................................................ 6
2 Dfinition........................................................................................................................... 6
3 Architecture........................................................................................................................ 6
4 Avantages et bnfices....................................................................................................... 7
5 Domaines dapplication...................................................................................................... 8
6 Les dfis de scurit......................................................................................................... 10
7 La couche MAC des rseaux mesh (la norme 802.11) .................................................... 10
7.1 Format des trames 802.11........................................................................................ 10
7.2 La scurit dans la norme 802.11............................................................................. 13
7.2.1 Confidentialit.................................................................................................. 13
7.2.2 Authentification................................................................................................ 13
8 Conclusion........................................................................................................................ 13
Chapitre 2 : Extension de larchitecture dauthentification du protocole 802.1X.................... 14
Authentification de niveau 2.................................................................................................... 14
1 Introduction...................................................................................................................... 14
2 Le protocole 802.1X dans les rseaux locaux sans fil...................................................... 14
2.1 Architecture de 802.1X ............................................................................................ 15
2.2 Procdure dauthentification 802.1X ....................................................................... 15
2.3 Les avantages du protocole 802.1X ......................................................................... 16
3 Extension du protocole 802.1X aux rseaux mesh sans fil multi-sauts........................... 17
3.1 Objectifs................................................................................................................... 17
3.2 Extension.................................................................................................................. 18
3.3 Fonctionnement gnral du protocole...................................................................... 19
3.4 Exemple de rseau mesh.......................................................................................... 20
4 Amlioration de la scurit du protocole 802.1X ............................................................ 22
5 Conclusion........................................................................................................................ 23
Chapitre 3: Proposition dune architecture dauthentification base sur le protocole PANA.. 24
Authentification de niveau 3.................................................................................................... 24
1 Introduction...................................................................................................................... 24
2 Le protocole PANA.......................................................................................................... 24
2.1 Prsentation.............................................................................................................. 24
2.2 Architecture.............................................................................................................. 25
2.3 Les diffrentes phases dune session PANA............................................................ 26
2.4 Association de scurit PANA................................................................................. 27
3 Les architectures possibles dun rseau mesh sans fil utilisant PANA............................ 28
4 Procdure dauthentification avec PANA dans les rseaux mesh sans fil ....................... 29
4.1 tape de dcouverte du PAA ................................................................................... 30
4.2 tape dauthentification et dautorisation................................................................ 30
4.3 tablissement dun tunnel IPsec.............................................................................. 32
1
5 Analyse de scurit de la solution.................................................................................... 32
6 Conclusion........................................................................................................................ 33
Chapitre 4 : Conception et validation formelle dune nouvelle mthode EAP........................ 34
1 Introduction...................................................................................................................... 34
2 Le protocole EAP............................................................................................................. 34
2.1 Les avantages du protocole EAP.............................................................................. 34
2.2 Format des paquets EAP.......................................................................................... 35
3 Les mthodes EAP........................................................................................................... 35
3.1 EAP-MD5................................................................................................................. 35
3.2 EAP-TLS.................................................................................................................. 37
4 Conception dune nouvelle mthode EAP : EAP-EHash................................................. 39
5 Analyse de la mthode EAP-EHash................................................................................. 41
6 Validation formelle de la mthode EAP-Ehash............................................................... 42
7 Conclusion........................................................................................................................ 43
Conclusions et perspectives..................................................................................................... 45
Rfrences................................................................................................................................ 47
Annexe A : Spcification de la mthode EAP-EHash dans le langage HLPSL ...................... 50
Annexe B : Types et sous-Types des trames 802.11................................................................ 53
Glossaire................................................................................................................................... 54

2
Liste des figures

Figure 1. Architecture des rseaux mesh sans fil ....................................................................... 7
Figure 2. Dploiement dun rseau mesh dans une entreprise .................................................. 8
Figure 3. Dploiement d'un rseau mesh dans un campus......................................................... 9
Figure 4. Dploiement d'un rseau mesh par un FAI ................................................................ 9
Figure 5. Architecture du protocole 802.1X............................................................................. 14
Figure 6. Messages changs dans lauthentification 802.1X/EAP......................................... 15
Figure 7. Encapsulation des paquets EAP ............................................................................... 16
Figure 8. Relayage des messages dauthentification du supplicant par les noeuds
intermdiaires........................................................................................................................... 17
Figure 9. Format du paquet EAPOL pour les rseaux mesh ................................................... 18
Figure 10. Procdure dauthentification dans un rseau mesh sans fil multi-sauts ................ 19
Figure 11. Exemple de rseau mesh......................................................................................... 20
Figure 12. Le cache des noeuds intermdiaires aprs ltape 1 .............................................. 21
Figure 13. Le cache des noeuds intermdiaires aprs ltape 2 .............................................. 21
Figure 14. Pseudo-algorithme excut par les routeurs mesh................................................. 22
Figure 15. Position protocolaire du protocole PANA [Bournelle04]...................................... 24
Figure 16. Architecture du protocole PANA............................................................................ 25
Figure 17. Dcouverte de PAA par multi-cast......................................................................26
Figure 18. Dcouverte de PAA par dtection de trafic ............................................................ 26
Figure 19. Phase daccs.......................................................................................................... 27
Figure 20. Exemple darchitecture de rseau mesh utilisant PANA (le PAA est spar de
AR/EP)...................................................................................................................................... 28
Figure 21. Les diffrentes tapes et protocoles excuts par le PaC....................................... 29
Figure 22. Procdure dauthentification PANA/EAP (en cas de succs) ................................ 31
Figure 23. Encapsulation des paquets EAP durant lauthentification PANA.......................... 31
Figure 24. Protection des donnes avec le mode tunnel dESP............................................... 32
Figure 25. Format des paquets EAP ........................................................................................ 35
Figure 26. Messages changs dans EAP-MD5....................................................................... 36
Figure 27. Messages changs dans EAP-TLS ........................................................................ 38
Figure 28. Messages changs dans EAP-EHash.................................................................... 40

3
Liste des tableaux

Tableau 1. Contenu des champs adresses en fonction des champs FromDs et ToDs.............. 12
Tableau 2. Codes des paquets EAP.......................................................................................... 18
Tableau 3. Comparaison entre deux architectures de rseau mesh utilisant PANA................ 29
Tableau 4. Comparaison entre mthodes EAP......................................................................... 44
4
Introduction

La technologie sans fil est devenue de plus en plus indispensable dans notre vie quotidienne.
En fait, les entreprises et les gouvernements dploient des rseaux sans fil dans le but
dconomiser le cot et de rendre laccs au rseau confortable aux utilisateurs. En effet, les
quipements sans fil sont moins chers compars au filaire et permettent dconomiser le cot
de cblage dans les btiments. De plus, grce la technologie sans fil, un employ nest plus
oblig dtre dans son bureau physiquement et peut travailler nimporte o pour peu quil se
trouve dans la zone de couverture du point daccs. Cependant, comme les utilisateurs sont de
plus en plus exigeants en terme de mobilit, lide dtendre la zone de couverture dun
rseau WLAN est rcemment adresse par les chercheurs. Cette ide a donn naissance un
nouveau type de rseaux : les rseaux mesh sans fil. En effet, dans un rseau mesh sans fil, le
nud mobile nest plus oblig dtre proximit dun point daccs, comme dans les rseaux
WLAN, puisque son trafic peut tre relay par les nuds intermdiaires situs entre lui et le
routeur mesh. Par consquent, grce aux rseaux mesh, il est possible de dployer un rseau
large zone de couverture avec un cot rduit.
Cependant, la scurit reste un dfi pour ce type de rseau, surtout pour un dploiement
critique comme les domaines militaires, gouvernementaux ou dans le cas dun fournisseur
daccs Internet qui veut limiter laccs ses seuls abonns.
Ce Mastre se place dans ce contexte, et sintresse ltude de la scurit des rseaux mesh
sans fil.
Lobjectif de ce Mastre est donc de proposer des solutions pour fournir des services de
scurit de base dans les rseaux mesh sans fil. Contrairement au rseau filaire, les rseaux
mesh sans fil ne possdent aucun primtre physique ; il est donc ncessaire de mettre en
place un mcanisme de contrle daccs robuste et efficace afin de limiter laccs uniquement
aux nuds autoriss. De plus, nous devons proposer un mcanisme dauthentification qui
permet de sassurer de lidentit des utilisateurs. Il est aussi ncessaire dassurer la
confidentialit des donnes transmises sur le rseau.
Le reste de ce rapport est organis comme suit. Dans le chapitre 1, nous introduisons les
rseaux mesh sans fil en prsentant les avantages, les domaines dapplication ainsi que les
principaux dfis lis la scurit de cette technologie. Ensuite, nous proposons dans le
chapitre 2 une extension du mcanisme dauthentification du protocole 802.1X pour une
utilisation dans un environnement multi-sauts et en particulier dans les rseaux mesh sans fil.
Le chapitre 3 dcrit des architectures de rseau mesh sans fil utilisant le protocole PANA- qui
est en cours de dfinition lIETF- comme mcanisme dauthentification. Comme les deux
mcanismes dauthentification dcrits ci-dessus sont bass sur le protocole EAP, le chapitre 4
dtaille ce protocole et propose une nouvelle mthode dauthentification EAP aux proprits
intressantes. Enfin nous concluons et donnons quelques perspectives ce travail.
5
Chapitre 1: Les rseaux mesh sans fil
1 Introduction
Les rseaux mesh sans fil reprsentent linnovation la plus rcente dans la technologie sans
fil. Ce nouveau type de rseau va permettre un usage plus rpandu des applications sans fil
large bande comme la VoIP ou la visio-confrence. Contrairement aux rseaux sans fil
traditionnels o les nuds communiquent uniquement avec un point central (station de base,
point daccs), dans un rseau mesh sans fil, chaque nud fonctionne, en plus dun simple
terminal, comme un routeur en relayant les donnes issues des autres nuds.
Ce chapitre introduit les rseaux mesh sans fil, en prsentant ses domaines dapplication, ses
avantages ainsi que les verrous de scurit qui sopposent encore au succs de cette
technologie.
2 Dfinition
Un rseau mesh sans fil est une collection de routeurs sans fil, gnralement fixes,
interconnects par des liens radios (Figure 1). Pour connecter les nuds mobiles Internet ou
un rseau filaire, certains de ces routeurs sont connects une infrastructure filaire. Ces
derniers prsentent gnralement deux interfaces : une interface lie linfrastructure filaire et
lautre pour communiquer avec les nuds mobiles et les autres routeurs.
Les rseaux mesh sans fil se distinguent des rseaux locaux sans fil (WLAN) par le fait que
les rseaux mesh possdent des routeurs daccs (appels aussi routeurs mesh) au lieu de
simples points daccs. Ces routeurs possdent en plus de la capacit de routage, des
fonctionnalits dauto-configuration qui leur permettent de lire la topologie dynamique du
rseau et dtablir des chemins appropris. De plus, les routeurs mesh sont interconnects par
des liaisons radio formant par la suite un systme de distribution sans fil qui sera plus flexible
que le systme de distribution filaire des WLANs. Enfin, il faut noter que dans un rseau
mesh les nuds mobiles jouent un rle actif puisquils participent au routage des donnes et
par la suite lextension du rseau.
3 Architecture
Un rseau mesh est gnralement constitu des lments suivants (Figure 1) :
Une infrastructure filaire aussi appele wired backbone sapparente un rseau
filaire dans lequel sont hbergs les serveurs ncessaires ladministration du rseau : serveur
AAA pour lauthentification et le contrle daccs (par exemples RADIUS, Diameter) et
serveur de configuration (par exemple DHCP). La connexion de cette infrastructure Internet
permet de servir lensemble des nuds mobiles du rseau.
Des routeurs mesh, appels aussi routeurs daccs, reprsentent le cur du rseau
puisquils jouent lintermdiaire entre les nuds mobiles (consommateurs du rseau) et
linfrastructure filaire (ressources du rseau). En dautres termes, ils agissent comme des
ponts (bridges) entre les rseaux filaire et sans fil.
Les routeurs mesh maintiennent entre eux et avec les nuds mobiles des chemins en se basant
sur des algorithmes de routage dynamiques comme ceux utiliss dans les rseaux ad hoc. Le
routage dynamique confre au rseau les proprits dauto-configuration et dauto-rparation.
Des nuds mobiles, appels aussi clients mesh, correspondent aux utilisateurs du
rseau qui cherchent utiliser des ressources se trouvant dans linfrastructure filaire ou bien
6
se connecter Internet. Les nuds mobiles sont quips dune interface sans fil qui supporte
la communication avec les rseaux mesh et les autres nuds mobiles.
Dans ce document on sintresse aux rseaux mesh muti-sauts (Figure 1), cest dire quun
nud peut ne pas communiquer directement avec le routeur mesh (ces paquets sont relays
par des nuds intermdiaires).

Internet / Wired Infrastructure
Nomadic
users
Mesh
routers
Wireless connection (802.11 link)
Wired connection (Ethernet link)

Figure 1. Architecture des rseaux mesh sans fil
4 Avantages et bnfices
Lintrt pour les rseaux mesh sans fil est grandissant dans les communauts industrielles et
acadmiques du fait de leurs caractristiques trs intressante [Bruno05], savoir :
Cot de dploiement rduit : les rseaux mesh sans fil sont bass sur des routeurs
mesh qui sont interconnects par des liaisons radios. Cela minimise le nombre de cbles et par
la suite rduit le cot de dploiement du rseau.
Extensible (Scalable) : contrairement aux rseaux WLAN o les nuds
communiquent uniquement avec le point daccs, dans un rseau mesh, les nuds hors de la
zone de couverture des routeurs mesh peuvent se connecter au rseau grce aux nuds
7
intermdiaires relayant leurs trafics. De cette faon le rseau mesh peut tre tendu de
manire transparente.
Support de la mobilit : les nuds dun rseau mesh sans fil transmettent leurs
donnes travers des canaux radios et par la suite ils peuvent se dplacer librement tant
quils restent dans la zone de couverture dautres nuds connects.
Fiable : la redondance des chemins dans un rseau mesh augmente la fiabilit du
rseau. En effet, lorsquun nud intermdiaire quitte le rseau ou choue dans le relayage du
trafic, lmetteur peut basculer vers un autre chemin.

Les caractristiques prsentes ci-dessus montrent bien que les rseaux mesh sans fil hritent
des avantages des rseaux WLAN et des rseaux ad hoc. Les rseaux WLAN en termes
dadministration et les rseaux ad hoc en terme dauto-configuration et de mobilit. Par
consquent, de nouvelles applications mergent aujourdhui grce ce type de rseaux.
5 Domaines dapplication
Contrairement aux rseaux ad hoc qui sont limits aux applications militaires et aux
applications civiles spcifiques, les rseaux mesh satisfont le besoin de plusieurs applications.
En effet, les rseaux mesh peuvent tre dploys dans les lieux publics (aroport, restaurant,
parc) pour offrir une connexion Internet aux passagers et clients. Le choix du rseau mesh
dans ces endroits peut se justifier par le besoin de mobilit et le cot rduit de dploiement.
Les rseaux mesh peuvent aussi tre dploys dans les universits et les campus pour
permettre aux tudiants daccder aux ressources de luniversit ou bien de vrifier leurs
mails depuis nimporte quel endroit, mme en dehors de leur campus.

Figure 2. Dploiement dun rseau mesh dans une entreprise
Une entreprise peut aussi dployer un rseau mesh afin doffrir un certain confort leurs
employs et minimiser le cot de dploiement et de maintenance du rseau. Le rseau mesh
peut tre lunique solution pour relier deux sites distants entre lesquels le cblage est interdit
(par exemple il est interdit de tirer des cbles dans les rues).
8

Figure 3. Dploiement d'un rseau mesh dans un campus
Les rseaux mesh prsentent aussi une solution rentable pour un fournisseur daccs Internet
(FAI) qui peut tendre sa zone de couverture grce la collaboration de ses abonnes. Un seul
nud attach un routeur mesh peut servir plusieurs voisins qui sont trop loigns pour
joindre directement le routeur mesh. Notez que la solution mesh pour offrir une connexion
Internet est intressante dans les milieux ruraux aussi bien quurbains. Dans les milieux
ruraux, tirer des cbles ou des lignes DSL (digital subscriber lines) pour des grandes distances
est trs onreux. De plus cette solution nest pas rentable puisque le nombre dutilisateurs est
gnralement limit. Par consquent, les routeurs mesh permettent dliminer ce cot de
cblage. Dans les milieux urbains o la densit des nuds connects est leve, la solution
mesh peut tre intressante en termes de fiabilit et de qualit de service. En effet, la
redondance de chemins peut augmenter la fiabilit et liminer les congestions dans le rseau.

Figure 4. Dploiement d'un rseau mesh par un FAI

9
6 Les dfis de scurit
Avant que les rseaux mesh sans fil connaissent un large dploiement, plusieurs verrous
doivent tre levs. La scurit reprsente lun des principaux dfis ne pas ngliger. En effet
les rseaux mesh prsentent des caractristiques qui les rendent plus vulnrables aux attaques.
On peut citer par exemple lutilisation de canaux radio qui facilite linterception des donnes
transmises. De plus, ils rendent le rseau mesh sans contrle daccs physique.
Le caractre multi-sauts est une autre vulnrabilit des rseaux mesh. En effet, les donnes
des utilisateurs sont relayes par des nuds qui peuvent prsenter des comportements
malicieux (analyse de linformation, modification des donnes, rejeu des anciennes donnes,
suppression du trafic, ).
Ces nuds participent aussi dans la fonction du routage et par la suite, ils peuvent perturber le
rseau ou le mettre hors service en transmettant de fausses informations de routage. Puisque
les rseaux mesh adoptent les protocoles de routage des rseaux ad hoc, ils sont confronts
aux mmes problmes. Plusieurs travaux ont adress la scurit du routage dans les rseaux
ad hoc ; le lecteur intress peut consulter [Cheikhrouhou05].
Ce travail sintresse en grande partie aux problmes dauthentification et contrle daccs
dans les rseaux mesh. Notez quen gnral la liaison routeur mesh rseau filaire, en
particulier routeur mesh serveur AAA, est scurise. Cette scurit peut tre tablie en
utilisant par exemple un tunnel IPsec dans lequel toutes les donnes sont chiffres.
Il reste donc assurer la scurit de la liaison nuds mobiles (utilisateurs du rseau) - routeur
mesh (point daccs aux ressources du rseau).
7 La couche MAC des rseaux mesh (la norme 802.11)
Les rseaux mesh sans fil peuvent tre considrs comme une extension des rseaux locaux
sans fil WLANs, connus sous le nom rseaux Wi-Fi. En effet, les deux types de rseau
possdent la mme couche liaison de donnes savoir la norme 802.11.
Dans cette section nous allons prsenter la norme 802.11 ainsi que les mcanismes de scurit
dfinis par cette norme. Nous situons aussi ces mcanismes au contexte des rseaux mesh.
7.1 Format des trames 802.11
La norme 802.11 dfinit trois principaux types de trames :
Les trames de donnes, utilises pour la transmission des donnes.
Les trames de contrle, utilises pour contrler l'accs au support (eg. RTS,
CTS, ACK).
Les trames de gestion, transmises de la mme faon que les trames de donnes
pour l'change d'informations de gestion, mais qui ne sont pas transmises aux
couches suprieures.
Toutes ces trames possdent le format suivant :

10
Prambule En tte PLCP Donnes MAC CRC

Contrle de Trame Dure/ID
2 octets
Adresse1
6 octets
Adresse2
6 octets
Adresse3
6 octets
Contrle de squence
2 octets
Adresse4
6 octets
Corps de la trame
0-2312 octets
CRC
4 octets 2 octets

En-tte MAC

Version de
protocole
Type Sous-type To DS From DS
More
Frag
Retry
Pwr
Mgt
More
Data
WEP Order

Octet 1(2 ,2 ,4 bits) Octet 2(8 fois 1 bit)

Prambule :
Il est indpendant de la couche physique et comprend :
Synch : c'est une squence de 80 bits alternant 0 et 1, qui est utilise par
le circuit physique pour slectionner l'antenne approprie (si plusieurs
sont utilises), et pour corriger l'offset de frquence et de
synchronisation.
SFD : le Start Frame Delimiter consiste en la suite de 16 bits 0000 1100
1011 1101 utilise pour dfinir le dbut de la trame.
En-tte PLCP (Trame 802.11) :
L'en-tte PCLP est toujours transmise 1 Mbps et contient des informations logiques
utilises par la couche physique pour dcoder la trame. Les principales informations
sont :
Longueur de mot du PLCP_PDU : il reprsente le nombre d'octets que
contient le paquet, ce qui est utile la couche physique pour dtecter
correctement la fin du paquet.
Fanion de signalisation PLCP : il contient seulement l'information de
taux, encode 0.5 Mbps, incrment de 1 4.5 Mbps
Champs d'en-tte du contrle d'erreur : champ de dtection d'erreur
CRC 16 bits.
Donnes MAC :
Contrle de trame :
Le champ de contrle de trame contient les informations suivantes :
Version de protocole : ce champ contient 2 bits qui pourront tre utiliss pour
reconnatre des versions futures possibles du standard 802.11. Dans la version
courante, la valeur est fixe 0.
Type et sous-type : les 6 bits dfinissent le type et le sous-type des trames : (voir
annexe B)
11
ToDS (vers le systme de distribution) : ce bit est mis 1 lorsque la trame est
adresse au point daccs pour quil la fasse suivre au DS, 0 dans les autres cas.
FromDS (venant du systme de distribution) : ce bit est mis 1 quand la trame
vient du systme de distribution.
More Fragments (dautres fragments) : ce bit est mis 1 si dautres fragments
suivent le fragment en cours.
Retry (retransmission) : ce bit indique que le fragment est une retransmission dun
fragment prcdemment transmis.
Power Management (gestion dnergie) : ce bit indique que la station sera en mode
de gestion dnergie aprs la transmission de cette trame.
More Data (dautres donnes) : galement utilis pour la gestion de lnergie. Il est
utilis par le AP pour indiquer que dautres trames sont stockes pour cette station.
La station peut alors dcider dutiliser cette information pour demander les autres
trames ou pour passer en mode actif.
WEP : indique que le corps de la trame est chiffr suivant lalgorithme WEP.
Order (ordre) : indique que la trame est envoye en utilisant la classe de service
strictement ordonne (Strictly-Ordered service class).

Dure/ID : possde deux significations : pour les trames de polling, reprsente
lidentifiant de la station. Dans les autres trames, cest la valeur de dure utilise pour
le calcul du NAV.
Adresse 1 : est toujours ladresse du rcepteur. Si ToDS vaut 1, cest ladresse de
lAP, sinon, cest ladresse de la station.
Adresse 2 : est toujours ladresse de lmetteur. Si FromDS vaut 1, cest ladresse
de lAP, sinon, cest ladresse de la station mettrice.
Adresse 3 : est ladresse de lmetteur original quand le champ FromDS est 1.
Sinon, et si ToDS est 1, Adresse 3 est ladresse destination.
Adresse 4 : est utilis dans un cas spcial, quand le DS est utilis et quune trame
est transmise dun AP un autre. Dans ce cas, ToDS et FromDS valent tous les deux 1
et il faut donc renseigner la fois lmetteur original et le destinataire.

La table suivante rsume lutilisation des diffrentes adresses dmission et de
rception selon les bits FromDS et ToDS :
Tableau 1. Contenu des champs adresses en fonction des champs FromDs et ToDs.
ToDS FromDs Adresse 1 Adresse 2 Adresse 3 Adresse 4
0 0 DA SA BSSID N/A
0 1 DA BSSID SA N/A
1 0 BSSID SA DA N/A
1 1 RA TA DA SA

Contrle de squence : utilis pour reprsenter lordre des diffrents fragments
appartenant la mme donne et pour reconnatre les trames dupliques.
CRC (Cyclic Redundant Check) : somme de contrle pour vrifier lintgrit de la
trame.

12
7.2 La scurit dans la norme 802.11
7.2.1 Confidentialit
La confidentialit dans les rseaux WLANs est assure grce un chiffrement des trames
802.11. Ce chiffrement de niveau 2 ne peut pas tre utilises dans le cas de rseau mesh. En
effet, dans un rseau mesh les donnes sont relies par les noeuds intermdiaires et par la suite
les en-ttes IP, ncessaires pour le routage de ces donnes, doivent tre transmis en clair. Par
consquent, un chiffrement doit tre mis au niveau 3 ou suprieur. Le protocole ESP dIPsec
peut tre une solution pour assurer la confidentialit dans les rseaux mesh.
7.2.2 Authentification
Lauthentification dans un rseau WLAN est dune extrme importance. En effet
lauthentification permet dempcher quun nud usurpe lidentit dun autre ou utilise son
compte. La norme 802.11 spcifie au dbut (norme 802.11b) deux mcanismes pour
lauthentification : lOpen System Authentification (OA) et le Shared Key Authentification (SA).
La premire technique reprsente le systme dauthentification par dfaut. Aucune
authentification explicite nest excute, et un terminal peut donc sassocier nimporte quel
point daccs (AP). La deuxime utilise une cl secrte partage entre les clients et le point
daccs et lauthentification se droule en quatre tapes. Dans cette deuxime technique
uniquement les nuds possdant la valeur scrte peuvent sauthentifier.
Malheureusement, ces deux techniques taient vites apparus comme insuffisants, pour cela un
nouveau groupe a t cre au sein de lIEEE : le 802.11i WG qui sintresse au problme de
scurit dans la norme 802.11. La norme 802.11i a t cre pour augmenter le niveau de scurit
et viter les failles de scurit dtectes dans les normes antrieurs (802.11b, 802.11g ). En
effet, cette norme repose sur larchitecture dauthentification 802.1X. Cette dernire a rsolu les
problmes de scurit dans les rseaux WLANs mais elle ne peut pas tre directement utilise
dans les rseaux mesh qui reprsentent des chemins multi-sauts. Pour cela, nous avons dfini au
chapitre suivant une extension de cette architecture dauthentification.

8 Conclusion
Dans ce chapitre, nous avons prsent une nouvelle technologie de rseaux : les rseaux mesh
sans fil. Ces derniers hritent des rseaux ad-hoc les caractristiques de mobilit et dauto-
configuration et des WLANs les caractristiques dadministration. Cependant, pour un large
dploiement, certains dfis doivent tre relevs. Lun de ces principaux dfis est la scurit.
Dans ce qui suit, nous prsentons des solutions pour lauthentification et le contrle daccs
dans un rseaux mesh sans fil multi-sauts.

13
Chapitre 2 : Extension de larchitecture dauthentification
du protocole 802.1X
Authentification de niveau 2
1 Introduction
Le problme de lauthentification se pose lorsquon veut limiter laccs des ressources
critiques. En effet, lauthentification permet de sassurer de lidentit des nuds et par la suite
dempcher quun nud nusurpe lidentit dun autre ou nutilise son compte. Dans les
rseaux mesh sans fil, lauthentification et le contrle daccs sont appliqus au niveau des
routeurs mesh qui peuvent tre apparents au port daccs aux ressources (Internet,
serveur,) du rseau.
Dans ce chapitre, nous dtaillons notre proposition dauthentification dans les rseaux mesh
sans fil. Cette solution est base sur le protocole 802.1X et permet de supporter le caractre
multi-sauts des rseaux mesh. Cependant, avant de prsenter notre solution, nous dcrivons
tout dabord le protocole 802.1X.
2 Le protocole 802.1X dans les rseaux locaux sans fil
Le standard 802.1X dfinit un mcanisme de contrle daccs bas sur le port (point
dattachement du nud au rseau) qui permet dautoriser laccs physique au rseau, des
nuds qui se sont authentifis avec succs auprs dun serveur. 802.1X dfinit aussi
lencapsulation des messages dauthentification (typiquement message EAP) dans les trames.

Supplicant
(802.1X client )
Authentication server
(e.g. RADIUS)
Services offered by
Authenticators
system
Authenticator
PAE
Supplicant
PAE
LAN
Uncontrolled port
Controlled port
Unauthorized port
Authenticator
( 802.1X access point)
Internet
Authentication
Server
EAP protocol exchanges
carried in higher-layer
protocol

Figure 5. Architecture du protocole 802.1X
14
2.1 Architecture de 802.1X
Trois entits interviennent dans le protocole 802.1X (Figure 5), savoir :
Le supplicant : appel aussi station ou client 802.1X, le supplicant reprsente lentit
authentifier. Dans un rseau WLAN, le supplicant est typiquement un nud mobile qui veut
accder au rseau.
Lauthentificateur : cest lentit o le contrle daccs au rseau est appliqu.
Lauthentificateur demande au client de sauthentifier avant de lui permettre daccder au
rseau. Dans un rseau WLAN, lauthentificateur est hberg dans le point daccs.
Le serveur dauthentification : cest lentit qui authentifie le client 802.1X, puis il
transmet le rsultat de lauthentification lauthentificateur. Aujourdhui les serveurs
dauthentifications les plus utiliss sont de type RADIUS (Remote Access Dial-In-User
Server) mais une volution vers les serveurs de type Diameter [OpenDiameter] est prvoir.
Comme lillustre la figure 5, le principe du protocole 802.1X est de diviser le port physique
de lauthentificateur en deux ports logiques : le port contrl et celui incontrl. Le port
contrl reste bloqu, tant que le client nest pas encore authentifi avec succs. Les diffrents
messages dauthentification traversent alors le port incontrl. Une fois le client authentifi
avec succs, le port contrl se dbloque pour laisser passer le trafic de donnes du client.
Notez que le port incontrl est configur de manire laisser passer uniquement un certain
type de trafic comme celui li lauthentification.
2.2 Procdure dauthentification 802.1X
Lauthentification 802.1X sappuie sur le protocole EAP (cf. chapitre 4). Figure 6 illustre les
diffrents messages changs lorsquun client veut accder au rseau :
E A P-Success
802.11 A SSOC Response
802.11 A SSOC Request
E A POL Start
E A P I denti ty R esponse
E A P I denti ty R equest
2
1
3
4
E A P over L A N E A P O ver R A DIU S
R A DI U S A ccess R equest (E A P)
R A DI U S A ccess A ccept (E A P) 5
4-Way H andshake
S upplicant
(802.1X client )
A uthentication s erver
(e.g. R A DIU S )
A uthenticator
Internet
M ulti-round authentication mes sage exchanges (depends on the E A P method)
A ssoci ati on A uthenti cati on K ey Exchange

Figure 6. Messages changs dans lauthentification 802.1X/EAP
15
1. Initialement, le client (nud mobile) doit sassocier avec lauthentificateur (point
daccs). la fin de cette association, chaque entit (le client et le point daccs) connat
ladresse MAC de son interlocuteur.
2. Le client initie ensuite la procdure dauthentification en envoyant un message
(EAPOL est lacronyme de EAP Over LAN) lauthentificateur. Start - EAPOL
3. En recevant ce message, lauthentificateur demande lidentit du client.
4. Le client rpond en envoyant une rponse EAP contenant son identit. Cette rponse
est relaye vers le serveur.
Un ensemble de messages spcifiques la mthode dauthentification utilise, sont ensuite
changs entre le serveur et le client, travers lauthentificateur. Le rle de lauthentificateur
durant cet change est simplement de relayer les messages en les encapsulant dans le format
appropri. Notez que la communication entre le supplicant et lauthentificateur est supporte
par le protocole EAPOL et la communication entre lauthentificateur et le serveur RADIUS
est supporte par un protocole EAP over RADIUS . Lencapsulation des paquets EAP est
illustre la figure 7.
Supplicant
(802.1X client )
(e.g. RADIUS)
Authenticator
Internet
MAC 802.11
EAPOL
EAP
MAC 802.11
EAPOL
MAC 802.3
IP
UDP
RADIUS
EAP
MAC 802.3
IP
UDP
RADIUS
EAP

Figure 7. Encapsulation des paquets EAP
5. la fin de la procdure dauthentification le serveur transmet lauthentificateur le
rsultat de lauthentification. En cas dauthentification russie, lauthentificateur convient de
cls avec le client. Le protocole 802.1X ne spcifie pas de mthode pour lchange de cls. La
mthode 4-way handshake illustre la figure 6 est dfinie dans le standard [IEEE-802.11i].
2.3 Les avantages du protocole 802.1X
Le protocole 802.1X a t lorigine conu pour les rseaux filaires (Ethernet). Ensuite il a
t choisi pour augmenter le niveau de scurit dans les rseaux sans fil car il possde les
avantages suivants [wp_interlink02] :
Indpendance de lauthentificateur
Le rle de lauthentificateur durant la procdure dauthentification est simplement de relayer
les messages changs entre le client et le serveur dauthentification. Par consquent,
limplmentation de lauthentificateur est indpendante de la mthode dauthentification
utilise. Par la suite, lauthentificateur reste intact lors dajout, de suppression ou de mise
jour des mthodes dauthentification.
16
Contrle daccs au niveau de ledge
Le protocole 802.1X permet dappliquer le contrle daccs au rseau au niveau des points
daccs qui reprsentent ledge du rseau. Cela permet dempcher les nuds non autoriss
daccder au rseau.
Gestion dynamique de cls de session
Le protocole 802.1X possde un mcanisme qui permet dutiliser des cls de chiffrement
dynamique, de re-authentifier le client et de gnrer des cls de session priodiquement. Cette
proprit augmente le niveau de scurit puisquelle vite le chiffrement dune grande
quantit dinformation par la mme cl.
3 Extension du protocole 802.1X aux rseaux mesh sans
fil multi-sauts
3.1 Objectifs
Le protocole 802.1X permet dauthentifier un nud directement attach lauthentificateur et
dappliquer ensuite un mcanisme de contrle daccs, de niveau 2, bas sur lassociation
entre le client et lauthentificateur. Par consquent, le protocole 802.1X, tel que dfini, ne
peut pas tre appliqu aux rseaux mesh (figure 8) o les nuds sont distants de
lauthentificateur (routeur mesh).
Notre objectif est donc dtendre le protocole 802.1X afin de permettre un nud distant de
sauthentifier auprs du routeur mesh. Ensuite, le contrle daccs peut tre assur grce au
protocole IPsec [RFC2401] [Doraswamy03] qui fournit un chiffrement de donnes de bout-
en-bout.
Notez que le chiffrement de donnes de bout-en-bout ne peut pas tre appliqu au niveau de la
couche liaison puisque les en-ttes IP, ncessaires pour lacheminement des paquets, doivent
tre transmis en clair.

(e.g. RADIUS)
Authenticator
(802.1X mesh router )
Intermediatenode
(802.1X relay)
Supplicant
( 802.1X client)

Figure 8. Relayage des messages dauthentification du supplicant par les noeuds
intermdiaires
Quand un nouveau nud rejoint le rseau, il doit excuter les tapes suivantes :
1. le nud sauthentifie auprs du routeur mesh. Si lauthentification se termine avec
succs, le client et le router mesh partagent une cl. Cette cl sera ensuite utilise comme cl
pr-partage de IKE [RFC2409] [Black00].
2. le routeur mesh ensuite ngocie avec le serveur DHCP pour obtenir une adresse IP en
faveur de ce client.
17
3. une fois quil a obtenu une adresse IP, le client initie le protocole IKE avec le routeur
mesh pour crer une association de scurit pour le protocole IPsec.
4. le trafic du client sera ensuite protg grce au tunnel IPsec cr. Ainsi la
confidentialit des donnes est assure grce au protocole ESP dIPsec et le contrle daccs
au niveau de routeur mesh peut tre fourni par le mcanisme dauthentification de lorigine de
message soit IPsec/AH [RFC2402] soit IPsec/ESP [RFC2406].
3.2 Extension
Afin de permettre lutilisation du mcanisme dauthentification du protocole 802.1X dans les
rseaux mesh sans fil nous proposons dajouter un nouveau composant : le relais. Comme son
nom lindique, le rle du relais est de relayer les messages dauthentification changs entre le
client (supplicant) et le routeur mesh (authentificateur).
Contrairement aux rseaux WLAN, o le client est directement attach au point daccs, dans
un rseau mesh, un ou plusieurs relais peuvent participer la procdure dauthentification
dun nud distant. Par consquent, un mcanisme de routage doit tre mis en place afin
dacheminer ces messages. Rappelons que le client authentifier ne possde pas encore
dadresse IP, de plus pour que le mcanisme dauthentification soit indpendant de la couche
MAC (Medium Access Control) utilise (802.11, 802.15, 802.16 ), il est ncessaire que
cette fonctionnalit soit ajoute au dessus de la couche MAC et donc dans la couche EAPOL.
Effectivement, nous avons ajout deux champs dans la trame EAPOL pour indiquer la source
et la destination du paquet EAP.
De plus nous avons ajout deux champs TimeStamp et MIC pour lutter contre lattaque DoS
dcrite dans [Mishra02]. La trame EAPOL modifie est illustre dans la figure 9.

Type Version Code Length
Destination
Address
Proposed fields to add
Source
Address
TimeStamp MIC
EAP
Packet

Figure 9. Format du paquet EAPOL pour les rseaux mesh
La signification de chaque champ est dcrite comme suit :
Type : de longueur 2 octets, il indique le type de la couche liaison entre le supplicant et
lauthentificateur.
Version : de longueur 1 octet, il spcifie la version du protocole EAPOL utilis.
Code : de longueur 1 octet, il indique le type de paquet EAP. Le champ Code peut prendre
plusieurs valeurs dcrites dans Tableau 2.
Tableau 2. Codes des paquets EAP
Code Valeur Description
EAP-Packet 0000 0000 Indique que la trame transporte un paquet
EAP.
EAPOL-Start 0000 0001 Commence la procdure dauthentification.
EAPOL-Logoff 0000 0010 Utiliser pour se dconnecter.
EAPOL-Key 0000 0011 Indique que la trame transporte des
changes des cls.
18
EAPOL-Encapsulated-ASF-Alert 0000 0100 Indique que la trame transporte une alerte.
Length : de longueur 2 octets, il indique la longueur en octets du champ EAP packet
(contenant un paquet EAP).
Destination address : ce champ contient une adresse MAC identifiant la destination de la
trame EAPOL. Cette adresse est en gnral ladresse du supplicant en cas de requte EAP et
ladresse de lauthentificateur (routeur mesh) en cas de rponse EAP.
Source address : ce champ contient une adresse MAC identifiant lmetteur de la trame
EAPOL. Cette adresse est soit ladresse du supplicant en cas de rponse EAP ou ladresse de
lauthentificateur en cas de requte EAP.
Timestamp : cest un nombre alatoire utilis dans le calcul du champ MIC (Message
Integrity Code) pour assurer la protection anti-rejeu.
MIC (Message Integrity Code) : ce champ est calcul en fonction de la trame EAPOL et de
la cl de session partage entre le client et le routeur mesh (exemple MIC=HMAC-
SHA1(trame EAPOL, cl)). Il permet de dtecter la modification des paquets EAP. Le
premier MIC est calcul par le routeur mesh pour protger le message EAP success. Ensuite
ce champ est prsent dans les messages critiques comme EAPOL-Logoff.
EAP packet : ce champ est prsent seulement dans le cas o le champ code est gal EAP-
Packet, EAPOL-Key, et EAPOL-Encapsulated-ASF-Alert.
3.3 Fonctionnement gnral du protocole
Comme dans les rseaux WLAN, quand un nud rejoint le rseau, il doit sauthentifier. Pour
cela le nouveau nud initie la procdure dauthentification en envoyant une trame EAPOL-
Start destine au routeur mesh. Cette premire trame peut tre diffuse dans le cas o le nud
ne connat aucun voisin (Figure 10).
EAP-Success, TimeStamp, MIC
EAPOL Start
EAP Identity Request
RADIUS Access Accept (EAP)
Derived key
EAPOL Start
Authentication message exchanges
1
2
3
4
EAPOL (EAP Over LAN) EAP Over RADIUS
(e.g. RADIUS)
Authenticator
(802.1X mesh router )
Internet
Intermediate node
(802.1X relay)
Supplicant
( 802.1X client)
MACi1 MACs
Destination Next_hop others

MACs MACi1
.. ...
5

Figure 10. Procdure dauthentification dans un rseau mesh sans fil multi-sauts
19
Les nuds intermdiaires, agissant comme relais 802.1X, font suivre la premire trame
EAPOL-Start et ignorent les autres trames dj traites. Cette trame est identifie par
ladresse MAC du client (lue partir du champ source address).
Pour relier les messages destins ce client (comme les requtes EAP), les nuds
intermdiaires doivent mmoriser le prochain saut vers ce client. Pour cela, avant de faire
suivre la trame EAPOL-Start, les nuds intermdiaires tablissent un pointeur vers le client et
ajoutent une entre leurs caches. Cette entre est compose, essentiellement, de ladresse
MAC du client et ladresse MAC du prochain saut vers ce client. La valeur de ce dernier
champ reprsente ladresse MAC du nud partir de laquelle la trame EAPOL-Start est reue
(Figure 10).
lexception des messages relays par les noeuds intermdiaires, la procdure
dauthentification se droule normalement comme dans les rseaux WLAN.
Une fois le client authentifi avec succs, le serveur dauthentification transmet la cl gnre
au cours de cette authentification vers lauthentificateur (tape 4 dans Figure 10). Pour plus de
dtails sur la manire de gnrer des cls, le lecteur pourra se reporter [Aboba05]. Cette cl
sera utilise dans le calcul du champ MIC dune trame EAPOL transportant un message EAP
success.
3.4 Exemple de rseau mesh
Dans cette section nous prsentons les diffrents messages changs ainsi que les paramtres
sur un cas de figure de rseau mesh illustr la figure11.
Internet
MR1
MR2
(e.g. RADIUS)
N3
N1
N2
supplicant
N4
N5

Figure 11. Exemple de rseau mesh
Comme expliqu prcdemment, le supplicant initie la procdure dauthentification en
diffusant une trame EAPOL-Start (DA=@broadcast, SA=@supplicant).
Chaque noeud intermdiaire recevant cette trame la diffuse son tour en tablissant un
pointeur vers le supplicant.
Normalement, aprs cette tape les caches des nuds intermdiaires de notre cas de figure ont
le format indiqu la figure 12.

20

N1,N5
Destination Next hop Others
Supplicant Supplicant
N2,N3
Supplicant N1
N4
Supplicant N5
Figure 12. Le cache des noeuds intermdiaires aprs ltape 1
Eventuellement, les routeurs mesh reoivent des trames EAPOL-Start et ils rpondent la
premire trame reue et ignorent les autres. Nous supposons que le lien (supplicant, N1, N3,
MR1) possde la plus faible latence, et par consquent le routeur MR1 traite la trame reue de
N3 et ignore les autres.
MR1 (respectivement MR2) envoie une requte EAP au supplicant (DA=@supplicant,
SA=MR1 (respectivement MR2)), demandant son identit. Cette trame est relaye au
supplicant (puisque chaque noeud intermdiaire a dans son cache le prochain nud pour
atteindre le supplicant) et pendant ce relyage chaque noeud intermdiaire tablit un pointeur
MAC au routeur mesh.
Normalement, aprs cette tape (tape 2) les caches des nuds intermdiaires ont le format
indiqu dans la figure 13.

N1
Supplicant Supplicant
MR1 N3
N3
Supplicant N1
MR1 MR1
N4
Supplicant N5
MR2 MR2
N5
Supplicant supplicant
MR2 N4
Figure 13. Le cache des noeuds intermdiaires aprs ltape 2
Le supplicant aussi rpond uniquement la premire trame EAPOL reue. Par consquent, il
rpond la trame reue de N1 et ignore celle reue de N5. Normalement les messages
ultrieurs vont suivre le chemin : (Supplicant, N1, N3, MR1).
Lalgorithme excut par le mesh routeur en recevant une trame EAPOL est illustr la figure
14.

21
//treatment of EAPOL frame
If code=EAPOL-Start then
Add an entry to the cache if isnt yet present otherwise discard packet
Construct an EAP Identity request packet
Initialize timers
Send packet
Else If code=EAPOL-Packet then
//forward message to RADIUS server
Encapsulate EAP packet in a RADIUS message
Initialize timers
Send packet
Else If code=EAPOL-Logoff then
//verify the integrity of the frame
Calculate the MIC of the EAPOL with the MIC set to 0 into MIC_Result
If MIC_Result !=MIC_Frame then
Discard packet
Log event
Else
Accept log-off
Delete all resources reserved for this supplicant
End if
//treatment for other types of EAPOL frame
End if

Figure 14. Pseudo-algorithme excut par les routeurs mesh
Pour chaque entre dans le cache est associ un temporisateur qui indique la fracheur de
lentre. Si lentre nest pas utilise durant la priode indique par le temporisateur alors elle
est dtruite : cest le cas des caches des noeuds N2, N4 et N5 (Figure 11).
4 Amlioration de la scurit du protocole 802.1X
Notre proposition non seulement tend le protocole 802.1X pour tre utilis dans un rseau
mesh, mais augmente aussi son niveau de scurit. En effet, lajout dun mcanisme
dauthentification et de contrle dintgrit par paquet permet dviter les attaques ciblant le
protocole 802.1X.
Protection contre lattaque par dni de service (DoS)
Les trames EAPOL-Logoff servent demander la dconnexion du rseau. En usurpant
ladresse MAC dun client, un attaquant peut raliser un dni de service contre ce dernier en
envoyant au routeur mesh une trame EAPOL-Logoff qui conduit donc la dconnexion du
client. Ce type de comportement dgrade les performances du rseau et peut rendre le rseau
hors service.
Notre proposition permet de lutter contre cette attaque par lajout de deux champs. Le champ
MIC qui est calcul en fonction dune cl connue uniquement par le routeur mesh et le client
et permet dauthentifier lorigine du message. Le deuxime champ est le champ Timestamp
qui permet dviter quun attaquant ne rejoue danciens messages EAPOL-Logoff
authentifis.
22
Par consquent, mme si un attaquant russit usurper lidentit dun client o mmoriser
danciennes trames, il reste incapable de raliser un dni de service puisque ces trames vont
chouer dans le test dintgrit (vrification du champ MIC) et seront ignores.
5 Conclusion
Les rseaux sans fil sont absents de tout contrle daccs physique. Ainsi un mcanisme
dauthentification et de contrle daccs robuste et efficace est une premire ligne de dfense.
Dans ce chapitre, nous prsentons une proposition dextension du mcanisme
dauthentification du protocole 802.1X pour une utilisation dans les rseaux mesh sans fil.
Nous montrons aussi que notre solution permet damliorer le niveau de scurit de ce
dernier. Le contrle daccs et la confidentialit des donnes sont, ensuite, assurs grce au
protocole IPsec.
23
Chapitre 3: Proposition dune architecture
dauthentification base sur le protocole PANA
Authentification de niveau 3
1 Introduction
La scurit dun rseau multi-sauts est critique puisque le client et lauthentificateur ne
communiquent pas directement. En effet, les messages dauthentification changs entre le
client et le routeur mesh sont relays par les nuds intermdiaires, ce qui ncessite le routage
de ces messages. Par consquent, il est plus facile dutiliser un mcanisme dauthentification
qui opre au-dessus de la couche rseau (couche 3) pour bnficier du service de routage de
cette dernire. Ce besoin a donn naissance un nouveau protocole : le protocole PANA.
Dans ce chapitre nous dcouvrons, dabord, le protocole PANA. Ensuite, nous dcrivons
notre proposition darchitecture de scurit pour les rseaux mesh. Enfin, une analyse de la
scurit de cette solution est explique.
2 Le protocole PANA
2.1 Prsentation
Le groupe du travail du protocole PANA (Protocol for Carrying Authentication for Network
Access) est en train de dvelopper un protocole qui permet aux clients de sauthentifier en
utilisant le protocole IP [RFC4016]. Par consquent le protocole PANA est indpendant de la
technologie daccs et il est applicable tout type de topologie de rseau [RFC4058].
Le protocole PANA peut tre dfini comme une couche basse de EAP qui permet donc de
transporter les messages EAP changs entre un client (appel client PANA) et le contrleur
daccs au rseau (appel agent PANA) [J ayaraman05].
La figure 15 prsente la position du protocole PANA dans la pile protocolaire.

IP
UDP
PANA
EAP
EAP method
(MD5,TLS,PEAP,)

Figure 15. Position protocolaire du protocole PANA [Bournelle04]
24
2.2 Architecture
Les quatre entits fonctionnelles dans une architecture de contrle daccs utilisant le
protocole PANA sont (Figure 2) :
Client PANA (PaC) : le PaC reprsente la partie client de limplmentation du
protocole PANA. Il rside dans lentit qui veut accder au rseau. Le PaC est responsable
dinterroger lagent dauthentification PANA et de fournir les rfrences ncessaires pour
prouver son identit [J ayaraman05].
Agent dAuthentification PANA (PAA) : le PAA reprsente la partie serveur de
limplmentation du protocole PANA. Il rside typiquement dans le serveur daccs au rseau
NAS (Network Access Server). Le PAA interagit avec le serveur dauthentification pour
dterminer ltat du contrle daccs, ensuite il transmet cet tat lquipement EP.
Enforcement Point (EP) : lEP reprsente la partie contrle daccs de
limplmentation du protocole PANA. LEP bloque le trafic de donnes dun nud
nouvellement arriv dans le rseau jusqu' ce quil sauthentifie avec succs. Seuls le trafic de
configuration et dauthentification comme DHCP, PAA discovery, PANA, etc. peut passer
librement travers lEP.
LEP reoit les attributs dun client autoris du PAA. Si lEP et le PAA rsident dans un
mme quipement alors un API suffit pour leur communication. Sinon le protocole SNMP
peut supporter cette communication [Mghazli05].
Le serveur dauthentification (AS) : lAS est responsable de vrifier les rfrences
dun client qui demande laccs au rseau et de transmettre ensuite le rsultat au PAA. LAS
et le PAA peuvent rsider dans un mme quipement ; dans ce cas un API suffit pour leur
communication. Sinon ils utilisent un protocole AAA comme Diameter ou RADIUS.

AS PAA
EP
PaC
PANA
S
N
M
P
/
A
P
I
RADIUS/Diameter/API
IKE/4-way handshake
Internet

Figure 16. Architecture du protocole PANA

25
2.3 Les diffrentes phases dune session PANA
Le protocole PANA permet de crer une session entre le client (PaC) et lagent
dauthentification (PAA). Cette session comporte les phases suivantes [Forsberg05] :
Phase de dcouverte : dans cette phase, le PaC dcouvre le PAA. Il y a deux
mthodes pour dcouvrir le PAA : soit le PaC envoie un message sollicitant PANA-PAA-
Discover (figure 17) ou bien le PAA envoie un message non sollicit PANA-Start-Request (
figure 18). Cette dernire mthode est utilise quand lEP dtecte du trafic IP venant dun
nud non autoris. Dans ce cas, lEP informe le PAA qui envoie alors un message PANA-
Start-Request au PaC. Dans les deux mthodes, la phase dauthentification commence quand
le PaC envoie un message PANA-Start-Answer.

PAA
EP
PaC
S
N
M
P
/
A
P
I
1. PANA-PAA-Discover
2. PANA-Start-Request
3. PANA-Start-Answer

2
.

N
o
t
i
f
i
c
a
t
i
o
n
PAA
PaC
3. PANA-Start-Request
4. PANA-Start-Answer
1. unauthenticatednode s Data
EP

Figure 17. Dcouverte de PAA par multi-cast Figure 18. Dcouverte de PAA par dtection
de trafic
Phase dauthentification et dautorisation : la tche principale de la phase
dauthentification et dautorisation est de transporter des messages EAP entre le PaC et le
PAA. Deux implmentations sont possibles. La premire implmentation transporte les
messages EAP dans les messages PANA-Auth-Request et acquitte la rception des messages
EAP par les messages PANA-Auth-Answer. La deuxime implmentation propose de
transporter les messages EAP-Response dans les messages PANA-Auth-Answer afin de
minimiser le nombre d'allers-retours (round-trips).
Le rsultat de lauthentification est transmis de PAA vers le PaC dans un message PANA-
Bind-Request. Ce message peut contenir dautres paramtres comme lidentificateur du
priphrique de chaque EP contrl par le PAA. Le PaC acquitte ce message par un message
PANA-Bind-Answer qui contient son identificateur de priphrique. Le draft [Forsberg05] du
protocole PANA spcifie que lorsque la mthode EAP utilise drive des cls, alors le
message PANA-Bind-Request ainsi que les messages postrieur sont protgs par un MIC
(Message Integrity Code).
Phase daccs : une fois le PaC authentifi avec succs, le PAA configure lEP (ou les
EPs) pour autoriser le trafic de ce PaC et la session PANA passe la phase daccs (Figure
26
19). Durant cette phase le PaC et le PAA peuvent tester la validit de la session PANA en
envoyant un message PANA-Ping-Request. Le rcepteur doit rpondre par un message
PANA-Ping-Answer.

C
o
n
t
r
o
l
PAA
PaC
EP
PAA
PaC
EP
Internet
The EP reject traffic of
unauthorized nodes
After a successful
authentication the PAA
configure the EP to grant
the PaC access to network.
During Access phase Before Access phase

Figure 19. Phase daccs
Phase de r-authentification : afin dtendre la dure de vie dune session PANA, le
PaC initie le processus de r-authentification en envoyant un message PANA-Reauth-
Request. Ce message contient lidentifiant de la session (session-id). En recevant cette requte
le PAA vrifie dabord sil a dj une session tablie avec le PaC avec lidentifiant de session
correspondant. Si cest le cas il lui rpond par un message PANA-Reauth-Answer suivi dun
message PANA-Auth-Request qui initie une nouvelle authentification EAP. Sinon le PAA,
optionnellement, rpond par un message PANA-Error-Request.
Le PAA peut aussi initier le processus dauthentification en envoyant un message PANA-
Auth-Request contenant un nouvel identifiant de session.
Phase de terminaison : si lune des entits (PAA ou PaC) veut terminer la session
alors elle envoie un message de dconnexion explicite. Le message PANA-Termination-
Request est utilis dans ce but. En recevant lacquittement de ce message (PANA-
Termination-Answer), linitiateur peut librer les ressources rserves pour cette session.
2.4 Association de scurit PANA
Une association de scurit PANA est cre comme un attribut dune session PANA lorsque
lauthentification EAP russit avec la cration dune cl AAA-Key. Cette association de
scurit nest pas cre dans le cas o lauthentification choue ou la mthode
dauthentification utilise ne permet pas de crer de cl.
Les attributs dune session PANA ainsi que les attributs dune association de scurit PANA
sont les suivants [Forsberg05] :
Les attributs dune session PANA :
* Session-id : identifiant de session
* device-id du PaC : identificateur du priphrique du client
* adresse IP et port UDP du PaC
* adresse IP de PAA
* liste didentificateurs de priphrique des EPs
* numro de squence de la dernire requte transmise
* numro de squence de la dernire requte reue
27
* charge utile (payload) du dernier message transmis
* intervalle de retransmission
* dure de vie de la session
* protection-capability : indique quelle couche le chiffrement des donnes est ralis
(couche rseau ou couche liaison)
* les attributs dune association de scurit (SA):
+nonce gnr par PaC (pac_nonce)
+nonce gnr par PAA (paa_nonce)
+ AAA-key
+ identificateur de AAA-key
+ PANA_MAC_KEY
La cl PANA_MAC_KEY est drive partir des cls AAA-Key disponibles et elle est
utilise pour assurer la protection dintgrit des messages PANA. Le PANA_MAC_KEY est
calcule de la manire suivante :

PANA_MAC_KEY =les premiers N bits de
HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID)
O la valeur de N dpend de lalgorithme de protection dintgrit utilis, exemple N=160
pour HMAC-SHA1.
3 Les architectures possibles dun rseau mesh sans fil
utilisant PANA
Selon le positionnement des diffrentes entits PANA, nous pouvons proposer plusieurs
architectures de rseaux mesh utilisant PANA comme mcanisme dauthentification et
dautorisation. Comme lEP (Enforcement Point) reprsente lentit PANA o le contrle
daccs est appliqu, alors il est logique de le placer dans le routeur daccs (routeur mesh)
qui reprsente le point de contact entre les clients et les ressources du rseau (figure 20).
AR/EP
RADIUS/Diameter
SNMP
SNMP
PaC
AS PAA
AR/EP
Figure 20. Exemple darchitecture de rseau mesh utilisant PANA (le PAA est spar de
AR/EP)
Deux principales architectures de rseau mesh sont donc envisageables ; elles dpendent du
placement du PAA. Plac le PAA dans le mme quipement que le routeur daccs a
28
lavantage de ne pas exiger de protocole de communication entre le PAA et lEP (un simple
API suffit) et de fait cette solution est plus scurise. Cependant, elle est moins flexible et la
conception du routeur daccs est plus complexe et donc plus chre. De plus, la sparation du
PAA et du routeur daccs rduit le cot de dploiement du rseau puisquun seul PAA peut
contrler plus quun routeur daccs. En outre, le fait quun seul PAA contrle plusieurs
routeurs daccs aide la mobilit des clients puisquun client nest pas oblig de se r-
authentifier lorsquil se dplace vers un autre routeur daccs contrl par le mme PAA.
Une tude comparative entre ces deux architectures est rsume dans le tableau 3.
Tableau 3. Comparaison entre deux architectures de rseau mesh utilisant PANA
PAA spar de EP et AR. PAA dans EP et AR.
Cot de dploiement du
rseau
plus
1
cher
Complexit de la conception
du routeur mesh
plus complexe
Mobilit aide la mobilit des clients
Scurit plus scuris

4 Procdure dauthentification avec PANA dans les
rseaux mesh sans fil

PaC
AR/EP
PAA AS DHCP Server
Configuration (e.g. DHCPv4)
IKE
SA
Authorization [IKE-PSK, PAC-DI,
Session-id]
PANA-Bind-Request /PANA-Bind-Answer
PANA Discovery phase and begin of Authentication and authorization phase

Figure 21. Les diffrentes tapes et protocoles excuts par le PaC

1
Comparaison est relative
29
Comme lillustre la figure 21, quand un nouveau noeud rejoint le rseau, il configure dabord
son adresse IP. Pour cela, il interagit avec un serveur DHCP. Notez que cela suppose que les
routeurs mesh sont configurs de manire laisser passer un certain type de trafic des clients
non authentifis, comme le trafic ARP, de dcouverte de voisin et PANA. la rception
dune adresse IP appele adresse pre-PANA, le PaC initie le protocole PANA. Une fois le
processus dauthentification termin avec succs, le PaC peut initier le protocole IKE avec le
routeur mesh (en particulier lEP) afin dtablir une association de scurit IPsec. Le tunnel
IPsec cr permet de chiffrer les donnes du client et dassurer le contrle daccs au niveau
du routeur mesh.
4.1 tape de dcouverte du PAA
Le but de ltape de dcouverte est que le client PANA (PaC) connaisse ladresse IP de
lagent PANA (PAA). Pour cette raison, le PaC diffuse un message PANA-PAA-Discover
(ayant une adresse multicast et un port UDP bien connus). Chaque PAA recevant ce message
rpond en envoyant un message PANA-Start-Request. Eventuellement, le PaC reoit
plusieurs messages PANA-Start-Request. Par dfaut le PaC choisit le PAA qui a envoy le
premier message PANA-Start-Request.
Pour empcher quun attaquant ne cre un dni de service par consommation de ressources
qui consiste surcharger le PAA avec des messages PANA-PAA-Discover comportant de
fausses adresses IP, le PAA inclut dans le message PANA-Start-Request un cookie qui
contient un nombre alatoire gnralement gnr partir de ladresse IP du PaC. Le cookie
permet donc de garantir que ladresse IP prtendue existe et de cette manire le PAA peut
viter de crer une session pour chaque PaC jusqu ce que ce dernier arrive produire le
mme cookie dans un message PANA-Start-Answer. Notez que le mcanisme de cookie est
optionnel est peut tre ignor dans le cas o lattaque par dni de service nest pas un
problme.
4.2 tape dauthentification et dautorisation
La tche principale du protocole PANA dans cette tape et de transporter les messages EAP
entre le PaC et le PAA. Le choix de la mthode EAP dpend des cls utilises et du niveau de
scurit exig. La seule condition sur la mthode EAP est quelle doit pouvoir gnr une cl
qui va tre utilise ensuite comme cl pr-partage pour IKE.
Procdure dauthentification PANA/EAP
La squence de messages changs durant un processus dauthentification termin avec
succs est illustre la figure 22.
Aprs la phase de dcouverte, le PAA (qui rside dans le routeur mesh) envoie une requte
EAP encapsule dans un message PANA-Auth-Request demandant lidentit du PaC.
En recevant cette requte, le PaC rpond en envoyant son identit (par exemple nom
dutilisateur, nom dhte ) dans une rponse EAP encapsule dans un message PANA-
Auth-Answer.
Le PAA fait suivre, ensuite, lidentit du PaC au serveur dauthentification et partir de ce
moment, le PAA joue un rle de relais entre le PaC et le serveur en dcapsulant les rponses
EAP reues dans un message PANA et puis il les encapsule dans un message AAA (Radius or
Diameter) pour les envoyer au serveur. De mme, le PAA dcapsule les requtes EAP reues
du serveur dans un message AAA et les encapsule dans un message PANA. La Figure 23
illustre lencapsulation protocolaire au niveau de chaque entit.
30
Number of messages depends on EAP method
PANA-Auth-Request (EAP-Request/ Identity)
PANA-Bind-Request (EAP-Success,Device-Id,[protection-Cap], MAC)
PANA-Auth-Answer (EAP-Response/ Identity (MyID)) Access-Request(EAP-Response/ Identity (MyID))
PANA-Auth-Answer (EAP-Response)
Access-Challenge(EAP-Request)
Access-Request(EAP-Response)
Access-Accept(EAP-Success)
RADIUS/Diameter
PaC
AS EP/AR/PAA
PANA-Auth-Request (EAP-Request)
PANA-Bind-Answer (Device-Id, [protection-Cap], MAC )

Figure 22. Procdure dauthentification PANA/EAP (en cas de succs)
Le nombre de messages changs entre le PaC et le serveur travers le PAA dpend de la
mthode EAP utilise. la fin de cet change le serveur transmet au PAA le rsultat
dauthentification. Dans le cas o le PaC est authentifi avec succs, le serveur transmet au
PAA en plus dun message EAP success la cl drive de la mthode EAP.
Le message EAP-Success est encapsul dans un message PANA-Bind-Answer qui est protg
par un champ MIC calcul partir de la cl dj gnre.

RADIUS/Diameter
PaC
AS EP/AR/PAA
MAC 802.3
IP
UDP
RADIUS
EAP
EAP method
(MD5,TLS,)
MAC 802.11
IP
UDP
PANA
MAC 802.3
IP
UDP
RADIUS
EAP
MAC 802.11
IP
UDP
PANA
EAP
EAP method
(MD5,TLS,)

Figure 23. Encapsulation des paquets EAP durant lauthentification PANA

31
4.3 tablissement dun tunnel IPsec
Lorsque lauthentification du client est termine avec succs, le PAA configure lEP pour
autoriser le trafic de ce PaC. Pour cela, le PAA transmet les paramtres de ce dernier comme
lidentifiant de priphrique du client et la cl pr-partage IKE [RFC2409].
Le mode agressif de IKE peut tre utilis puisquil demande moins dchange de messages
que le mode principal [Black00]. IKE sert donc tablir une association de scurit pour
IPsec [RFC2401]. Cette association de scurit permet au PaC et au EP de ngocier les
diffrents paramtres cryptographiques utiliss pour tablir le tunnel IPsec (par exemple
lalgorithme de chiffrement). Avec le protocole ESP dIPsec les donnes du client sont
chiffres comme illustr la figure 24.

IP Header TCP Header Data
Before applying ESP
Authenticated
Encrypted
New IP Header ESP
After applying ESP
IP Header TCP Header Data ESP Trailor ESP Auth
Figure 24. Protection des donnes avec le mode tunnel dESP
5 Analyse de scurit de la solution
Nous montrons dans cette section que la solution propose ci-dessus vrifie les proprits de
scurit dfinies dans [RFC4016]. Ensuite, nous prsentons des attaques potentielles ainsi que
des recommandations pour lutter contre ces attaques.
Protection anti-rejeu
Les messages PANA comportent un numro de squence qui est incrment chaque
nouvelle requte. Ce numro est alatoirement initialis au dbut de la session et il est vrifi
chaque rception dun nouveau message. Un message comportant un numro de squence
diffrent du numro attendu sera ignor [Forsberg05].
En plus daccomplir la livraison ordonne des messages EAP et llimination des doublons,
ce mcanisme permet dviter quun attaquant ne rejoue danciens messages PANA puisquils
vont faire chouer le test de numro de squence.
Protection du PaC contre lattaque DoS
Le rsultat de lauthentification (EAP-Success ou bien EAP-Failure) envoy du PAA vers le
PaC est protg contre la modification par un MAC (Message Authentication Code). Ceci
permet dviter quun attaquant nenvoie de faux messages EAP-Failure au PaC.
Protection contre l'attaque vol de service
Lassociation de scurit PANA cre la fin d'une authentification russie assure l'intgrit
des messages et plus particulirement protge l'identifiant du priphrique du PaC contre
toute modification. Par consquent, il vite l'attaque vol de service dcrit dans [RFC4016].
32
Usurpation des messages du PAA
Comme il n' y a aucune relation de confiance entre le PAA et le PaC durant la phase de
dcouverte, un attaquant peut usurper l'identit de PAA en envoyant par exemple le message
PANA-Start-Request. Si ce message contient des informations lies la scurit comme par
exemple les mthodes d'authentifications supportes, un noeud malicieux peut lancer un
attaque " binding down" qui consiste envoyer de faux messages indiquant des capacits
moins scurises que les capacits relles supportes par le PAA.
Pour cette raison, il est recommand de ngocier les paramtres de scurit (comme par
exemple lalgorithme de chiffrement) aprs l'tablissement de lassociation de scurit, par
exemple dans le message PANA-Bind-Request.
Dni de service contre le PAA
Comme expliqu prcdemment, un attaquant peut surcharger le PAA avec des messages
PANA-PAA-Discover afin de le mettre hors service. Une solution pour attnuer ce
comportement malicieux est d'ajouter un cookie au message PANA-Start-Request. Le cookie
garantit que le PaC est disponible l'adresse IP prtendue (c'est une vraie adresse IP) et ce
n'est pas une adresse IP gnre alatoirement, puisque le PaC est capable de retourner le
mme cookie dans le message PANA-Start-Answer. Ce mcanisme permet d'viter de
rserver des ressources pour des PaC inexistants.
Dni de service contre le serveur DHCP
Le protocole PANA suppose que le client PaC possde une adresse IP avant dexcuter le
protocole PANA. Cette hypothse nous oblige donner une adresse IP au client avant qu'il
ne s'authentifie. Un attaquant peut exploiter cette proprit pour puiser la plage d'adresses IP
disponible dans le serveur DHCP, et par la suite mettre le serveur DHCP, ainsi que le rseau
hors service.
6 Conclusion
Dans ce chapitre nous avons propos une architecture de rseau mesh sans fil utilisant le
protocole PANA comme mcanisme dauthentification et dautorisation et le protocole IPsec
comme mcanisme de contrle daccs et de chiffrement. Une analyse de scurit de la
solution propose est aussi faite afin de la comparer avec dautres.

33
Chapitre 4 : Conception et validation formelle dune
nouvelle mthode EAP
1 Introduction
Comme nous lavons dj expliqu dans les chapitres 2 et 3, lauthentification dans les
rseaux sans fil est base sur le protocole EAP. Nous prsentons dans ce chapitre le protocole
EAP et ses principales mthodes. Ensuite nous dtaillons notre nouvelle mthode EAP
appele EAP-EHash. Cette mthode est propose pour augmenter le niveau de scurit de la
mthode EAP-MD5 dune part et viter la lourdeur de la mthode EAP-TLS dautre part. La
validation formelle de notre mthode EAP-EHash montre que cette mthode est robuste et
quelle vrifie les proprits de scurit dsires. Une tude comparative entre les diffrentes
mthodes EAP est aussi faite pour montrer lavantage de notre contribution.
2 Le protocole EAP
Le protocole EAP (Extensible Authentication Protocol) [RFC3748] est un protocole
dauthentification qui supporte plusieurs mthodes dauthentification. Il fonctionne,
typiquement, au dessus de la couche liaison de donnes avec par exemple le Protocole Point
to Point (PPP) ou IEEE 802.
EAP fournit son propre support pour la retransmission et pour llimination des messages
dupliqus, mais ncessite le bon ordonnancement des messages par la couche infrieure. La
fragmentation n'est pas supporte dans EAP lui-mme; cependant, les mthodes EAP
individuellement peuvent la mettre en uvre.
Larchitecture EAP est compose de trois entits : le client (peer), lauthentificateur
(authenticator) et le serveur dauthentification. Le client est lentit qui souhaite
sauthentifier ; il rpond aux requtes reues de lauthentificateur. Lauthentificateur est
lentit o le contrle daccs au rseau est appliqu. Son rle durant la procdure
dauthentification est de relayer les messages dauthentification entre les client et serveur
dauthentification. Le serveur dauthentification est lentit qui se charge dauthentifier le
client et, pour cela, il implmente les diffrentes mthodes EAP.
Les messages changs durant une procdure dauthentification basique sont les suivants :
1. Aprs la phase dtablissement du lien, lauthentificateur envoie une requte au client
demandant son identit.
2. Le client rpond en envoyant une rponse EAP contenant son identit.
3. La squence de messages requte EAP rponse EAP continue jusqu ce que le
serveur authentifie avec succs le client (message EAP success) ou conclut lchec de
lauthentification (message EAP failure).
2.1 Les avantages du protocole EAP
Le protocole EAP est largement utilis aujourdhui pour la scurit des rseaux aussi bien
filaires que sans fil, vu quil possde plusieurs avantages. En effet, le protocole EAP supporte
plusieurs mthodes dauthentification sans avoir en pre-ngocier une en particulier. De plus
lauthentificateur (point daccs dans le cas de WLAN et routeur mesh dans le cas de WMN)
34
est indpendant de la mthode dauthentification utilise puisque son rle est de relayer les
messages changs entre les client et serveur. Cette caractristique est importante puisquelle
permet de rduire le cot de mise jour de lauthentificateur. La sparation de
lauthentificateur du serveur dauthentification permet aussi de simplifier la gestion des
paramtres de scurit, puisque ladministrateur rseaux peut configurer une seule entit
centrale (serveur dauthentification) au lieu de configurer chaque authentificateur.
2.2 Format des paquets EAP
Le format dun paquet EAP est reprsent la Figure 25. Les champs sont envoys de gauche
droite.
Code Identifier Length Data

Figure 25. Format des paquets EAP
Le champ code est de un octet et identifie le type du paquet EAP. Le protocole EAP dfinit
quatre types de message : requte (code=1), rponse (code=2), succs (code=3) et chec
(code=4).
Le champ identifier est de un octet et permet de faire correspondre les rponses aux requtes.
Le champ length est sur deux octets et indique la longueur en octets du paquet EAP y compris
les champs code, identifier, length et data.
Le champ data, de longueur variable, est prsent uniquement si le message est de type requte
ou rponse (code gale 1 ou 2). Le format de ce champ dpend du type de message et de la
mthode EAP utilise.
3 Les mthodes EAP
Comme dj mentionn, le protocole EAP supporte plusieurs mthodes dauthentification.
Dans cette section nous prsentons deux mthodes basiques de EAP, savoir EAP-MD5 et
EAP-TLS.
3.1 EAP-MD5
La mthode EAP-MD5 est base sur le protocole CHAP (Challenge Handshake
Authentication Protocol) [RFC1994], qui consiste authentifier le client en utilisant le
systme de dfi-rponse. EAP-MD5 ncessite une cl partage entre les client et serveur
dauthentification. Cette cl consiste gnralement en un mot de passe associ un nom
dutilisateur ou une identit (par exemple adresse IP ou adresse MAC).
35
EAP-Failure RADIUS Access Reject (EAP)
EAP-Success
EAP Request
EAP Identity Response
EAP Response
EAP Identity Request
1
2
EAP over LAN EAP Over RADIUS
RADIUS Access Request (EAP)
RADIUS Access Challenge (EAP)
RADIUS Access Request (EAP)
RADIUS Access Accept (EAP) 5a
Client
(e.g. RADIUS)
Authenticator
Calculate a hash based on the
challenge (sent in message 3)
and the shared secret
Verify response hash using
the shared secret
Verify?
yes
No
3
4
5b

Figure 26. Messages changs dans EAP-MD5
Comme illustr la figure 26, aprs lenvoi de lidentit du client (tapes 1 et 2 de la Figure
26), le serveur dauthentification envoie un dfi alatoire au client (tape 3 de la Figure 26).
Ce dernier calcule un hash partir du dfi envoy et de la cl partage avec le serveur et il
envoie le rsultat dans un message de rponse EAP (tape 4 de la Figure 26). Le serveur
effectue le mme calcul que le client. En comparant les deux hashs (le hash calcul avec celui
reu), il vrifie alors si le client possde ou non la bonne cl et par la suite accepte (tape 5a
de la Figure 26) ou rejette (tape 5b de la Figure 26) lauthentification. En fonction de cette
dcision, lauthentificateur autorise ou non le client accder au rseau.
La mthode EAP-MD5 a lavantage de ne pas ncessiter beaucoup de ressources pour son
traitement. De plus elle nexige pas dinfrastructure de gestion de certificats ou de cls
(comme EAP-TLS), mais elle nest pas utilise aujourdhui car elle est reconnue comme
vulnrable aux attaques par dictionnaire et aux attaques par force brute. De plus, EAP-MD5
est une mthode dauthentification sens unique, cest--dire le client doit sauthentifier,
contrairement au serveur qui ne sauthentifie pas. Cela ne permet pas de dtecter les points
daccs malveillants (contrls par des intrus).
36
3.2 EAP-TLS
La mthode EAP-TLS [RFC 2716] (TLS est lacronyme de Transport Layer Security) fournit
un niveau de scurit lev du fait quelle exige que le client et le serveur sidentifient et
sauthentifient par lusage de certificats.
Aprs lenvoi de lidentit du client, les diffrents messages changs par la mthode EAP -
TLS sont illustrs la figure 27 :
1. Le serveur dauthentification envoie un paquet EAP-TLS/Start pour commencer les
changes EAP-TLS avec le client.
2. Le client rpond en envoyant un message TLS client_hello qui contient son numro de
version TLS, un identifiant de session (sessionId), un nombre alatoire, et un ensemble
dalgorithmes/fonctions de scurit supports par le client.
3. Le serveur d'authentification envoie alors une requte EAP contenant un message TLS
server_hello, suivi de son certificat TLS, un nombre alatoire (server_key_exchange), une
demande de certificat du client (certificate_request) et un message server_hello_done. Le
message server_hello contient le numro de version TLS du serveur, un autre nombre
alatoire, un identifiant de session (sessionId), et l'ensemble des algorithmes choisis par le
serveur.
4. la rception de cette requte, le client vrifie le certificat du serveur. Si le certificat
du serveur est valide, le client rpond avec un paquet EAP-Response contenant son certificat,
un nombre alatoire (client_key_exchange) qui dtermine avec le server_key_exchange le
secret partag (TLS master secret), et un certificate_verify qui est une signature lectronique
de la rponse de l'authentification.
5. la rception du paquet EAP-Response, le serveur vrifie le certificat du client et la
signature lectronique. Si le test russit le serveur envoie un paquet EAP-Request contenant
un message change_cipher_spec et un message handshake_finished. Le dernier contient la
rponse de l'authentification du serveur au client. En vrifiant le hash, le client peut
authentifier le serveur EAP.
6. Si le serveur est authentifi avec succs, le client envoie un paquet EAP-Response de
type EAP-TLS sans donnes.
7. Le serveur EAP rpond alors avec un message EAP-Success.

37
EAP-Request/ Identity
EAP-Success
EAP-Request/ EAP-Type=EAP-TLS
(TLS change_cipher_spec, TLS finished)
EAP-Request/ EAP-Type=EAP-TLS (TLS Start)
EAP-Response/ Identity (MyID) Access-Request(EAP-Response/ Identity (MyID))
EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)
EAP-Response/ EAP-Type=EAP-TLS (TLS certificate,
TLS client_key_exchange, [TLS certificate_verify,] TLS
change_cipher_spec, TLS finished)
EAP-Response/ EAP-Type=EAP-TLS
EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello,
TLS certificate, [TLS server_key_exchange,] [TLS
certificate_request,] TLS server_hello_done)
Access-Challenge(EAP-Request/ EAP-Type=EAP-TLS (TLS Start) )
Access-Request(EAP-Response/ EAP-Type=EAP-TLS
(TLS client_hello))
Access-Challenge(EAP-Request/ EAP-Type=EAP-TLS (TLS
server_hello, TLS certificate, [TLS server_key_exchange,] [TLS
certificate_request,] TLS server_hello_done) )
Access-Request(EAP-Response/ EAP-Type=EAP-TLS (TLS
certificate, TLS client_key_exchange, [TLS certificate_verify,] TLS
change_cipher_spec, TLS finished))
Access-Challenge(EAP-Request/ EAP-Type=EAP-TLS
(TLS change_cipher_spec, TLS finished) )
EAP-Response/ EAP-Type=EAP-TLS
Access-Accept(EAP-Success)
Client
(eg RADIUS)
Authenticator
1
2
3
4
5
6
7

Figure 27. Messages changs dans EAP-TLS
38
La mthode EAP-TLS a lavantage de permettre lauthentification mutuelle entre le client et
le serveur et dtre plus robuste face des attaques puisquelle se base sur la cryptographie
asymtrique (certificats).
Linconvnient majeur de cette mthode est quelle exige un PKI (Public Key Infrastructure)
pour la gestion des certificats ct client et ct serveur. Cette contrainte nest pas toujours
ralisable ; de plus elle rend la gestion et la maintenance du rseau plus complexes.
4 Conception dune nouvelle mthode EAP : EAP-EHash
Plusieurs mthodes EAP ont t proposes lIETF, mais aucune de ces mthode nest
satisfaisante : certaines mthodes sont vulnrables aux attaques ; dautres exigent des
contraintes non toujours ralisables. Ce contexte nous a motivs proposer une nouvelle
mthode EAP qui tire avantages des mthodes dj dfinies tout en vitant les vulnrabilits
dj dtectes dans ces mthodes.
En effet, la mthode que nous avons propose, appele EAP-EHash (EHash pour Encrypted
Hash), satisfait les caractristiques suivantes :
Cette mthode est base sur la cryptographie symtrique ; son traitement est donc
lger et nexige pas de grandes puissances de calcul.
Lauthentification est base sur une cl symtrique secrte, partage entre les client et
serveur d'authentification ; il n y a donc pas besoin dinfrastructure particulire pour
la gestion des cls.
Le nombre de messages changs est assez rduit.
Cette mthode fournit lauthentification mutuelle entre le client et le serveur
d'authentification.
Elle est robuste face aux attaques par dictionnaire et celles par force brute qui visent
dcouvrir la valeur secrte de la cl.
Afin de rpondre ces besoins, nous avons utilis le principe du protocole CHAP [RFC1994]
qui est lger dans son traitement. Nous avons aussi propos deux mcanismes : le premier
pour fournir lauthentification mutuelle, le second pour viter les attaques par dictionnaire et
par force brute.

39
EAP-Request/ Identity
EAP-Response/ Identity (MyID) Access-Request(EAP-Response/ Identity (MyID))
Access-Challenge(EAP-Request (challenge || ServerId ||
RandS || {MIC}EK ))
EAP-Request(challenge || ServerId || RandS || {MIC}
EK
)
EAP-Response(RandC || {HASH}
EK
) Access-Request(EAP-Response(RandC ||{HASH}
EK
))
1
2
EAP over LAN EAP Over RADIUS
Authenticator
EAP-Failure RADIUS Access Reject (EAP)
EAP-Success
RADIUS Access Accept (EAP) 3a
Verify?
No
3b
Generate the same keys
as the server and then
verify the MIC field
Verify?
yes
yes
Authentication
server
Client

Figure 28. Messages changs dans EAP-EHash

La figure 28 illustre les changes de messages entre les client et serveur lors dune
authentification avec la mthode EAP-EHash :
1. Aprs avoir reu lidentit du client, le serveur d'authentification consulte sa base de
donnes pour dterminer la valeur PSK (Pre-Shared Key) du secret partag avec cette
identit. Ensuite, il gnre les lments suivants :
RandS : un nombre alatoire.
AK (Authentication Key) : cl dauthentification utilise pour calculer le
champ MIC (Message Integrity Check) ; elle est drive de la cl PSK comme
suit : AK=F (PSK, RandS) o F est une fonction alatoire sens unique
(exemple HMAC-SHA-1).
EK (Encryption Key) : cl de chiffrement utilise pour chiffrer les champs
MIC et Hash ; elle est drive de PSK comme suit : EK=F (PSK, RandS ||
ServerID || ClientID) o || dsigne la concatnation.
Challenge : un dfi (sous la forme dune chane ou nombre alatoire) utilis
pour authentifier le client.
ServerID : lidentit du serveur.

Le serveur d'authentification calcule ensuite le champ MIC comme suit : MIC =F (AK,
Challenge || ServerID || RandS) o F est une fonction de hachage (exemple MD5, SHA-1). Ce
MIC sera ensuite chiffr en utilisant la cl EK. Tous ces lments sont envoys au client dans
un message EAP-Challenge ( travers lauthentificateur).
40
2. rception de ce message, le client gnre les mmes cls (AK et EK) que le serveur.
Le client essaye ensuite dauthentifier le serveur en se basant sur la validit du champ
MIC chiffr. Pour cela, le client effectue les mmes calculs que le serveur pour trouver
le champ MIC chiffr et il lui suffit alors de comparer la valeur obtenue avec celle
reue pour sassurer de lauthenticit du serveur. Si le serveur est authentifi avec
succs, le client doit sauthentifier auprs du serveur. Pour cela il calcule un hash
partir du Challenge envoy par le serveur comme suit : HASH =F (AK, Challenge ||
RandC) o F est une fonction de hachage. Ensuite il envoie RandC et la valeur
chiffre du hash au serveur dans un message EAP-Response.
3. Avec la rponse son dfi, le serveur calcule le hash de la mme manire que le client
et il compare ensuite les deux rsultats. Dans le cas dune authentification du client
russie (hash calcul par le serveur gal celui reu du client), une nouvelle cl est
calcule comme suit : IK=F (PSK, RandS || RandC). Cette cl pourra tre utilise
comme secret partag pour initier le protocole IKE (si un VPN IPsec est mettre en
place entre le client et le point d'accs) ou pour driver des cls de chiffrement IEEE
802.11 partages entre le client et le point d'accs.
5 Analyse de la mthode 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 et de puissance de calcul.

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 fil puisque les
noeuds sont mobiles et peuvent tout moment perdre leurs connexions ou changer de point
daccs ce qui les oblige alors se rauthentifier.
Authentification mutuelle
Linconvnient majeur de la mthode EAP-MD5 et quelle nassure pas lauthentification du
serveur. Cette vulnrabilit peut conduire analyser tout le trafic des utilisateurs en plaant
des points daccs malveillants (contrls par des intrus).
La mthode EAP-EHash permet de lutter contre cette attaque en assurant lauthentification
mutuelle : le serveur est authentifi grce un champ MIC calcul en fonction du secret
partag.
Efficacit contre les attaques par dictionnaire
Contrairement EAP-MD5, EAP-EHash est robuste contre les attaques par dictionnaire
lances par un attaquant et visant dcouvrir la cl partage. En effet, dans EAP-MD5, un
attaquant qui coute le trafic peut dduire la valeur de la cl partage par une attaque par
dictionnaire puisquil possde le texte en clair et le hash correspondant.
EAP-EHash permet de lutter contre cette attaque par deux mcanismes. Le premier consiste
gnrer dautres cls qui sont utilises dans le calcul des champs MIC et hash. Cela permet
41
dassurer la proprit Perfect Forward Secrecy (le secret partag PSK reste inconnu mme
dans le cas o la valeur des cls AK et EK sont rvles). Le deuxime mcanisme consiste
chiffrer les champs MIC et hash pour rendre plus difficile la rvlation de la cl AK.
6 Validation formelle de la mthode EAP-Ehash
La validation formelle d'un protocole cryptographique est ncessaire pour s'assurer de la
robustesse et de la scurit de ce protocole avant de se lancer dans son implmentation.
Plusieurs techniques de validation formelle de protocoles cryptographiques sont utilises.
Nous pouvons citer par exemple CASPER [Donovan99], EVA [EVA], AVISPA [AVISPA] et
d'autres outils bass sur CSP (Communicating Sequentiel Process) [Hoare04].
Nous avons choisi loutil AVISPA (Automated Validation of Internet Security Protocols and
Applications) car il est automatique et assez expressive (permet de vrifier plusieurs
proprits de scurit comme par exemple lauthentification, le secret, la robustesse contre
certaines attaques). De plus AVISPA supporte un nombre illimit de sessions.
L'outil AVISPA dfinit le langage HLPSL (High-Level Protocol Specification Language) qui
se base sur la logique temporelle des actions [Lamport94].
La spcification de la mthode EAP-EHash dans le langage HLPSL se prsente de la faon
suivante :
Puisque l'authentificateur n'intervient pas dans la procdure d'authentification (son rle est
seulement de relayer les messages), nous avons spcifi le protocole avec les deux rles client
(peer) et serveur (server) seulement :
role peer(
P, S: agent,
PSK: symmetric_key,
MIC, HASH, PRF: function,
SND, RCV: channel(dy)
)

role server(
P, S: agent,
PSK: symmetric_key,
MIC, HASH, PRF: function,
SND, RCV: channel(dy)
)

Dans chaque rle, nous spcifions les diffrentes transitions effectues par l'agent qui
reprsente un participant dans le protocole. Les deux rles dclars ci-dessus sont appels rle
de base (basic role). Une session du protocole est une instanciation de diffrents rles de base
et elle est appele rle compos.
Pour vrifier des proprits de scurit, HLPSL emploie des primitives. Par exemple, pour
assurer lauthentification, nous utilisons les deux primitives : witness et request.
witness(P,S,rp,RandP') : veut dire que lagent P veut communiquer avec lagent S en
utilisant la valeur RandP' comme valeur du paramtre rp.
request(S,P,rp,RandP') : veut dire que lagent S a accept la valeur RandP' comme
valeur de rp et maintenant doit vrifier que cette valeur est rellement envoye par
lagent P.
Pour exprimer le fait que lagent S doit authentifier P sur la valeur de RandP', nous utilisons
dans la section goal la primitive authentication_on.
42

goal
aut hent i cat i on_on r p

Nous avons aussi exprim le fait que les cls utilises entre les deux clients doivent restes
secrtes en utilisant la primitive secret.
La spcification complte du protocole EAP-EHash avec le langage HLPSL est illustre en
annexe A.
Pour la validation du protocole EAP-EHash, loutil AVISPA traduit la spcification crite en
langage HLPSL dans un format intermdiaire plus appropri au model-checking.
Le rsultat retourn par loutil AVISPA en utilisant le model-checking ofmc (on-the-fly-
model-checking) est la suivante :

%OFMC
%Ver si on of 2005/ 06/ 07
SUMMARY
SAFE
DETAI LS
BOUNDED_NUMBER_OF_SESSI ONS
PROTOCOL
/ r oot / avi spa- 1. 0/ t est sui t e/ r esul t s/ EHash05. i f
GOAL
as_speci f i ed
BACKEND
OFMC
COMMENTS
STATI STI CS
par seTi me: 0. 00s
sear chTi me: 0. 53s
vi si t edNodes: 137 nodes
dept h: 12 pl i es

Le rsultat de la validation montre bien que la mthode EAP-EHash vrifie les proprits de
scurit souhaites (secret des cls, authentification) et quelle est robuste contre lattaque
man-in-the-middle et le rejeu des messages.
7 Conclusion
Dans ce chapitre, nous avons prsent le protocole EAP qui est largement utilis aujourdhui
pour la scurit des rseaux aussi bien filaires que sans fil. Plusieurs mthodes EAP ont t
proposes au sein de lIETF mais aucune de ces mthodes nest satisfaisante, ce qui nous a
motiv proposer une nouvelle mthode. Aprs la description dtaille de notre mthode
EAP-EHash, nous avons montr formellement que la mthode est robuste contre les attaques
connues et quelle vrifie les proprits de scurit souhaites. Une tude comparative de
notre mthode EAP-EHash avec les mthodes EAP-TLS et EAP-MD5 est illustre sur le
tableau 4.
Mtho
EAP
des Authentification
mutuelle
Architecture de base Exige une
infrastructure
PKI
Dure de
l'authentification
EAP-TLS Oui tablir une session TLS
et vrifier la validit
des certificats du client
et du serveur
Oui Lente
EAP-
MD5
Non Dfi-Rponse Non Rapide
EAP- Oui Dfi-Rponse avec Non Rapide
43
EHash chiffrement de la
rponse et
authentification du
serveur par un MIC
Tableau 4. Comparaison entre mthodes EAP

44
Conclusions et perspectives
Les rseaux mesh sans fil apparaissent comme une nouvelle technologie volutive et
prometteuse. En effet, ils bnficient de caractristiques avantageuses comme un canal de
transmission radio et un chemin multi-sauts, mais ces caractristiques sont galement
dangereuses. En effet, la transmission par voie radio empche la mise en uvre de tout
contrle daccs physique. De plus, la prsence des chemins multi-sauts expose le rseau aux
attaquants analysant ou modifiant le trafic des utilisateurs. Par consquent, la scurit des
rseaux mesh sans fil est un problme qui ne peut pas tre nglig.
Dans ce Mastre, nous avons propos des solutions pour fournir les services de scurit de
base un rseau mesh sans fil. Dabord nous avons expliqu comment nous pouvons tendre
le mcanisme dauthentification du protocole 802.1X aux rseaux mesh sans fil. Nous avons
montr que notre proposition non seulement tend le protocole 802.1X, mais augmente aussi
son niveau de scurit. En effet nous avons ajout deux champs qui assurent lintgrit des
messages et la protection anti-rejeu. Dans cette solution, le rseau authentifie les clients avant
de leur donner une adresse IP. Il est donc ncessaire de dfinir un mcanisme de routage bas
sur le protocole EAPOL pour acheminer les messages dauthentification.
Dans le chapitre 3, nous avons dcrit des architectures de rseau mesh sans fil utilisant le
protocole PANA comme mcanisme dauthentification. PANA est un nouveau protocole en
cours de dfinition lIETF qui convient bien aux rseaux multi-sauts puisquil fonctionne au
dessus de la couche rseau. Cependant dans cette solution, les clients doivent acqurir une
adresse IP avant de sauthentifier. Cette caractristique peut alors tre exploite par un
attaquant pour puiser la plage dadresses IP du rseau et par la suite mettre le rseau hors
service.
Dans les deux solutions dcrites ci-dessus les clients authentifis avec succs initient le
protocole IKE pour tablir une association de scurit IPsec. Cette association de scurit
permet donc dassurer la confidentialit des donnes de bout-en-bout et dappliquer le
contrle daccs au niveau des routeurs mesh.
Comme lauthentification est base sur le protocole EAP nous avons consacr le chapitre 4
dtailler ce protocole ainsi que ses principales mthodes dauthentification. Nous avons aussi
propos une nouvelle mthode dauthentification qui est aussi robuste que la mthode EAP-
TLS et aussi rapide que la mthode EAP-MD5. Notre mthode EAP, appele EAP-EHash
(EHash est lacronyme de Encrypted Hash) assure lauthentification mutuelle en se basant sur
un MIC calcul par le serveur et vrifi par le client et un champ hash calcul par le client et
vrifi par le serveur. La valeur de ces deux champs (MIC et hash) est transmise chiffre afin
de lutter contre les attaques par dictionnaire et par force brute. Afin de sassurer de la
robustesse et des proprits de scurit de la mthode EAP-EHash, nous lavons valide grce
un outil appel AVISPA. Le rsultat de la validation montre bien que notre mthode vrifie
les proprits de scurit dsires.
Les perspectives de ce travail sont :
Implmentation de lextension propose du protocole 802.1X. Cette implmentation
peut se baser sur un code source existant de 802.1X pour viter la rcriture des
diffrents modules. Le site web [Open1X] fournit un code source pour le supplicant
(nomm xsupplicant) et pour lauthentificateur. La tche consiste donc comprendre
et modifier le code du supplicant et de lauthentificateur pour supporter les nouvelles
fonctionnalits et ajouter le composant relais. Cette tche demande une bonne
connaissance du langage C++et du systme dexploitation Linux.
45
Mise en place dune plateforme simulant les architectures proposes dans le chapitre
3. Cette plateforme peut se baser sur le code source du protocole PANA et du serveur
dauthentification Diameter disponible [OpenDiameter]. Cette tche demande aussi
une bonne connaissance du langage C++, du systme dexploitation Linux et de la
configuration rseau.
Une fois les deux tches prcdentes acheves avec succs, nous pouvons alors
proposer une tude comparative entre ces deux solutions afin daider les
administrateurs rseau choisir la solution la plus approprie. Les critres de
comparaison peuvent tre : lefficacit en termes de temps ncessaire pour
lauthentification et de consommation de ressources et la robustesse en termes de
scurit.
Implmentation de la nouvelle mthode propose EAP-EHash et comparaison de ses
performances avec celles des autres mthodes EAP. Cette implmentation peut se
baser sur un code source existant disponible [wire1x].
Dautres aspects ne sont pas adresss dans ce Mastre et peuvent tre proposs comme
perspectives :
Dans ce Mastre nous navons pas adress les problmes de scurit lis la mobilit
des utilisateurs et le roaming. En effet, lorsquun utilisateur se dplace dun routeur
mesh vers un autre, il doit se r-authentifier et par la suite tablir un nouveau tunnel
IPsec avec le nouveau routeur mesh. Pour cela nous devons proposer un mcanisme de
r-authentification efficace et robuste.
Le mcanisme de contrle daccs et le chiffrement de donnes choisis dans ce
Mastre se basent sur le protocole IPsec. Cette solution demande linstallation dun
client IPsec en chacun des nuds, ce qui peut ne pas tre une tche ralisable. Une
autre alternative est dutiliser un tunnel SSL qui agit au niveau de la couche transport
en encapsulant systmatiquement tous les changes. Ltude de cette solution et son
utilisation dans le contexte de rseau mesh sans fil peuvent tre proposes comme
perspectives.
46
Rfrences
Standards

[IEEE-802.1X]

IEEE Standard 802.1X-2004, standard for Local and Metropolitan Area
Networks: Port-Based Network Access Control, December 2004.
[IEEE-802.11i] IEEE Standard 802.11i-2004, standard for Information technology-
Telecommunication and information exchange between systems-Local and
metropolitan area networks-Specific requirements, J uly 2004.

RFC

[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J . Turner, "Internet
Security Association and Key Management Protocol (ISAKMP)", RFC
2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "Internet Key Exchange", RFC 2409,
November 1998.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC
2716, October 1999.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J ., Carlson, J ., and H. Levkowetz,
"Extensible Authentication Protocol (EAP)", RFC 3748, J une 2004.
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network
Access (PANA) Threat Analysis and Security Requirements", RFC 4016,
March 2005.
[RFC4019] Hoffman, P., Algorithms for Internet Key Exchange version 1 (IKEv1),
RFC 4019, May 2005.
[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for
Carrying Authentication for Network Access (PANA) Requirements",
RFC 4058, May 2005.

Draft

[Aboba05] Aboba, B., Simon, D., Arkko, J ., Eronen, P., and H. Levkowetz, "Extensible
Authentication Protocol (EAP) Key Management Framework", draft-ietf-
eap-keying-08, October 2005.
[Forsberg05] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., Yegin, A., "Protocol for
Carrying Authentication for Network Access (PANA)", draft-ietf-PANA-
PANA-10 (work in progress), J uly 2005.
[J ayaraman05] J ayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., Yegin, A., "PANA
47
Framework", draft-ietf-pana-framework-05 (work in progress), J uly 2005.
[Kaufman04] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-
IPsec-ikev2-17 (work in progress), September 2004.
[Mghazli05] Mghazli, Y., Ohba, Y., Bournelle, J ., "SNMP usage for PAA-EP interface",
draft-ietf-pana-snmp-04 (work in progress), J uly 2005.

Books

[Black00]

Black, Uyless D., Internet Security Protocols: protecting IP traffic, 2000.
[Doraswamy03] Doraswamy, N., and D. Harkins, IPsec: The new security standard for the
Internet, Intranets and Virtual Private Networks, 2003.
[Hoare04] Tony Hoare, Communicating Sequential Processes, electronic books, 2004.
disponible en http://www.usingcsp.com/cspbook.pdf

Articles

[Akyildiz05] Akyildiz, I., Wang, X., and W. Wang, Wireless Mesh Networks: A
Survey, Elsevier Computer Networks, 2005, pp.445-487.
[Bruno05] Bruno, R., Conti, M., and E. Gregori, Mesh Networks: Commodity
Multihop Ad Hoc Networks, IEEE Communications, vol. 43, no. 3,
2005.
[Donovan99] Donovan, B., Norris, P., and G. Lowe, "Analyzing a library of security
protocols using casper and FDR", In Workshop on Formal Methods and
Security Protocols, Trento, Italy, J uly 1999.
[Lamport94] Lamport, L., "The temporal logic of actions", ACM Transactions on
Programming Languages and Systems, 16(3):872923, May 1994.
[Mihail05] Mihail, L. Sichitiu, "Wireless Mesh Networks: Opportunities and
Challenges," in Proc of the Wireless World Congress, (Palo Alto, CA),
May 2005.
[Mishra02] Mishra, A. and W. Arbaugh, An initial security analysis of the 802.1X
standard, http://www.cs.umd.edu/~waa/1x.pdf, February 2002.
[Perlman00] Perlman, R. and C. Kaufman, Key Exchange in IPsec: Analysis of IKE,
IEEE Internet Computing, Vol. 4, No. 6, pp.5056, 2000.
[Weyland04] Weyland, A., and T. Braun, Cooperation and Accounting Strategy for
Multi-hop Cellular Networks, In Proceedings of 13th IEEE Workshop on
Local and Metropolitan Area Networks (LANMAN 2004), Mill Valley,
CA, USA, April 2004.

Rapport de recherche & Thse

[Bournelle04] Bournelle, J .,Vers un systme dauthentification intgrant la
configuration dynamique de la mobilit IPv6 et la prise en compte des
dplacements, INT thesis, 2004.
[Cheikhrouhou05] Cheikhrouhou O., Laurent-Maknavicius M., scurit des rseaux
mesh, Rapport de recherche du GET, rapport 06001 LOR, 2006.
Disponible (http://www-lor.int-
evry.fr/%7Emaknavic/Rapports_Recherche/RR_Secu_Mesh.zip)

48

Autres

[AVISPA] Projet Automated Validation of Internet Security Protocols and
Applications: www.avispa-project.org/
[EVA] Projet RNTL-EVA. Rseau National des Technologies Logicielles,
Explication et Vrification Automatique de protocoles cryptographiques:
http://www-eva.imag.fr
[OpenDiameter] www.opendiameter.org
[Open1x] http://open1x.sourceforge.net/
[wire1x] http://wire.cs.nthu.edu.tw/wire1x/
[wp_interlink02] Introduction to 802.1X for Wireless Local Area Networks,
www.interlinknetworks.com/images/resource/using_802.1X_with_interlin
k.pdf, 2002.

49
Annexe A : Spcification de la mthode EAP-EHash
dans le langage HLPSL

%%Pr ot ocol e EAP- EHash
%%aut eur : Chei khr ouhou Omar
%%dat e: 31/ 03/ 2006
%%Al i ce & Bob Not at i on
%S - > P: r equest _i d
%P - > S: r espond_i d. peer I d
%S - > P: chal l enge. ser ver I d. r andS. {MI C( AK, chal l enge. ser ver I d. r andS) }_EK
%AK=F( PSK. r andS)
%EK=F( PSK. r andS. ser ver I d. peer I d)
%F est une f onct i on de hachage sens uni que ( exempl e SHA, HMAC-
SHA)
%P - > S: r andP. {HMAC( AK, chal l enge. r andP}_EK
%HMAC est une f onct i on de hachage sens uni que ( exempl e MD5)
%S - > P: success

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
r ol e ser ver (
P, S: agent ,
PSK: symmet r i c_key,
MI C, HMAC, PRF: f unct i on,
SND, RCV: channel ( dy)
)
pl ayed_by S def =
l ocal
St at e : nat ,
Chal l enge, RandS, RandP: t ext ,
MAC, HASH : message,
AK, EK : message %cl s dr i ves de l a cl par t age PSK
const
r p, r s, ch,
sec_ak, sec_ek : pr ot ocol _i d,
r equest _i d, r espond_i d, success,
peer I d, ser ver I d: t ext

i ni t
St at e: =0
t r ansi t i on
0. St at e=0 / \ RCV( st ar t ) =| >
St at e' : =1 / \ SND( r equest _i d)

1. St at e=1 / \ RCV( r espond_i d. peer I d) =| >
St at e' : =2 / \ RandS' : =new( )
/ \ Chal l enge' : =new( )
/ \ AK' : =PRF( PSK. RandS' )
/ \ EK' : =PRF( PSK. RandS' . ser ver I d. peer I d)
/ \ MAC' : ={MI C( AK' , Chal l enge' . ser ver I d. RandS' ) }_EK'
/ \ SND( Chal l enge' . ser ver I d. RandS' . MAC' )
/ \ wi t ness( S, P, r s, RandS' )
/ \ wi t ness( S, P, ch, Chal l enge' )
/ \ secr et ( AK' , sec_ak, {P, S})
/ \ secr et ( EK' , sec_ek, {P, S})

2. St at e=2 / \ RCV( RandP' . HASH' )
/ \ HASH' ={HMAC( AK, Chal l enge. RandP' ) }_EK
%Chal l enge and not Chal l enge'
50
=| >
St at e' : =3 / \ r equest ( S, P, RandP' )
/ \ SND( success)

end r ol e %ser ver
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

r ol e peer (
P, S: agent ,
MI C, HMAC, PRF: f unct i on,
SND, RCV: channel ( dy)
)
pl ayed_by P def =
l ocal
St at e : nat ,
Chal l enge, RandS, RandP: t ext ,
MAC, HASH: message,
AK, EK : message %cl s dr i ves de l a cl par t age PSK

const
r p, r s, ch,
sec_ak, sec_ek : pr ot ocol _i d,
r equest _i d, r espond_i d, success,
peer I d, ser ver I d: t ext

i ni t
St at e: =0
t r ansi t i on
0. St at e=0 / \ RCV( r equest _i d) =| >
St at e' : =1 / \ SND( r espond_i d. peer I d)

1. St at e=1 / \ RCV( Chal l enge' . ser ver I d. RandS' . MAC' )
%Peer doi t vr i f i er l a val i di t du champ MI C
/ \ AK' =PRF( PSK. RandS' )
/ \ EK' =PRF( PSK. RandS' . ser ver I d. peer I d)
/ \ MAC' ={MI C( AK' , Chal l enge' . ser ver I d. RandS' ) }_EK'
=| >
St at e' : =2 / \ RandP' : =new( )
/ \ HASH' : ={HMAC( AK' , Chal l enge' . RandP' ) }_EK'
/ \ SND( RandP' . HASH' )
/ \ wi t ness( P, S, r p, RandP' )
/ \ r equest ( P, S, r s, RandS' )
/ \ r equest ( P, S, ch, Chal l enge' )
/ \ secr et ( AK' , sec_ak, {P, S})
/ \ secr et ( EK' , sec_ek, {P, S})

2. St at e=2 / \ RCV( success) =| >
St at e' : =3

end r ol e %peer

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
r ol e sessi on(
P, S: agent ,
MI C, HMAC, PRF: f unct i on
)
def =

51
l ocal
Speer , Rpeer , Sser ver , Rser ver : channel ( dy)

composi t i on
peer ( P, S, PSK, MI C, HMAC, PRF, Speer , Rpeer )
/ \ ser ver ( P, S, PSK, MI C, HMAC, PRF, Sser ver , Rser ver )

end r ol e

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
r ol e envi r onnement ( )
def =
const
p, s, i : agent ,
mi c, h, pr f : f unct i on,
psk_ps, psk_pi , psk_i s: symmet r i c_key

i nt r uder _knowl edge={p, s, mi c, h, pr f , psk_pi , psk_i s}

composi t i on
sessi on( p, s, psk_ps, mi c, h, pr f )
/ \ sessi on( p, i , psk_pi , mi c, h, pr f )
/ \ sessi on( i , s, psk_i s, mi c, h, pr f )

end r ol e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
goal
aut hent i cat i on_on ch, r s
aut hent i cat i on_on r p
%secr ecy_of key
secr ecy_of sec_ak, sec_ek
end goal
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%excut i on du pr ot ocol e
envi r onnement ( )

52
Annexe B : Types et sous-Types des trames 802.11

Le tableau suivant illustre les types et sous-types des trames 802.11 et les valeurs
correspondantes :

Valeur
du type
Description du
type
Valeur du sous-type
(b7 b6 b5 b4)
Description du sous type
00 Gestion 0000 Requte dassociation
00 Gestion 0001 Rponse dassociation
00 Gestion 0010 Requte de r-association
00 Gestion 0011 Rponse de r-association
00 Gestion 0100 Demande denqute
00 Gestion 0101 Rponse denqute
00 Gestion 0110-0111 Rservs
00 Gestion 1000 Balise
00 Gestion 1001 ATIM
00 Gestion 1010 Dsassociation
00 Gestion 1011 Authentification
00 Gestion 1100 Dsauthentification
00 Gestion 1101-1111 Rservs
01 Contrle 0000-1001 Rservs
01 Contrle 1010 PS-Poll
01 Contrle 1011 RTS
01 Contrle 1100 CTS
01 Contrle 1101 ACK
01 Contrle 1110 CF-End
01 Contrle 1111 CF-End et CF-ACK
10 Donnes 0000 Donnes
10 Donnes 0001 Donnes et CF-ACK
10 Donnes 0010 Donnes et CF-Poll
10 Donnes 0011 Donnes, CF-ACK et CF-Poll
10 Donnes 0100 Fonction nulle (sans donnes)
10 Donnes 0101 CF-ACK (sans donnes)
10 Donnes 0110 CF-Poll (sans donnes)
10 Donnes 0111 CF-ACK et CF-Poll (sans donnes)
10 Donnes 1000-1111 Rservs
11 Rserv 0000-1111 Rservs
53
Glossaire
802.1X
Norme de l'IEEE pour le contrle d'accs un rseau. Le contrle est exerc au niveau d'un
port d'un commutateur, ou pour chaque association dans un AP. Ce standard repose sur l'EAP,
et l'authentification des utilisateurs est gnralement ralise par un serveur RADIUS.
802.11
Norme conue par l'IEEE en 1997 pour les rseaux locaux sans fil, et constamment amliore
depuis. Elle dfinit trois couches physiques (infrarouge, FHSS et DSSS sur les frquences de
2,4 GHz) et une couche MAC offrant de nombreuses fonctionnalits : partage du mdia,
fragmentation, conomie d'nergie, scurit...
802.11i
Norme de scurit sur les liaisons wi-fi. Cette norme tend vers l'utilisation de TKIP pour
aboutir la standardisation de l'algorithme AES.
A
AAA (Autorisation, Authentification, Accounting)
Un serveur AAA gre l'authentification des utilisateurs, leurs autorisations et la
comptabilisation de leurs connexions (voir aussi RADIUS).
Ad Hoc
Dans un rseau Wi-Fi de type Ad Hoc, les stations communiquent directement entre elles
plutt que par le biais d'un AP (voir aussi Infrastructure).
AES (Advanced Encryption Standard)
Algorithme de cryptage symtrique extrmement rapide et sr. La norme de scurit WPA2
repose sur le TKIP ou l'AES.
Algorithme cryptographique ou de chiffrement
Procd ou fonction mathmatique utilise pour le chiffrement et le dchiffrement. Dans la
cryptographie moderne, l'algorithme est souvent public et le secret du chiffre dpend d'un
paramtre appel clef.
Analyse du trafic
Observation des caractristiques extrieures du trafic transitant sur un rseau afin de tenter
d'en tirer des informations : frquence des transmissions, identits des tiers communicants,
quantits de donnes transfres. Associes des informations de nature diffrente (date de
rendez-vous, actualit,...), ces lments peuvent permettre aux adversaires de faire des
dductions intressantes.
Association de scurit (SA)
Cest un rapport entre deux entits ou plus qui dcrit comment les entits utiliseront des
services de scurit pour communiquer solidement. Ce rapport est reprsent par un ensemble
d'information qui peut tre considr comme un contrat entre les entits. L'information doit
tre convenue et partage entre toutes les entits.

54
Authenticit
Terme qui dsigne le service de scurit qui consiste assurer la fois l'intgrit et
l'authentification de l'origine des donnes.
Authentification
On distingue deux types d'authentification :
1. Authentification d'un tiers : Cest l'action qui consiste prouver son identit. Ce
service est gnralement rendu par l'utilisation d'un "change d'authentification" qui
implique un certain dialogue entre les tiers communiquants.
2. Authentification de l'origine des donnes : Elle sert prouver que les donnes reues
ont bien t mises par l'metteur dclar. Dans ce cas, l'authentification dsigne
souvent la combinaison de deux services : authentification et intgrit en mode non
connect.
C
Certificat
Document lectronique qui renferme la clef publique d'une entit, ainsi qu'un certain nombre
d'informations la concernant, comme son identit. Ce document est sign par une autorit de
certification ayant vrifi les informations qu'il contient.
Chiffrement, chiffrer
Application d'un algorithme cryptographique un ensemble de donnes appeles texte en
clair afin d'obtenir un texte chiffr. Le chiffrement est un mcanisme de scurit permettant
d'assurer la confidentialit des donnes.
Clef (secrte, publique, prive)
Paramtre d'un algorithme de chiffrement ou de dchiffrement, sur lequel repose le secret.
On distingue deux types de clefs :
1. les clefs secrtes, utilises par les algorithmes symtriques, pour lesquels la clef de
chiffrement et de dchiffrement sont identiques.
2. les couples (clef publique, clef prive), utiliss par les algorithmes asymtriques, pour
lesquels clef de chiffrement et de dchiffrement sont distinctes.
Clef de chiffrement de clefs
Clef utilise exclusivement pour chiffrer d'autres clefs, afin de les faire parvenir un
interlocuteur. Une clef de chiffrement de clef a gnralement une dure de vie assez longue,
par opposition aux clefs qu'elle sert chiffrer.
Clef de session
Clef ayant une dure de vie trs limite, gnralement une session. Les clefs de session sont
gnralement des clefs secrtes, utilises pour chiffrer les donnes transmises, et que les tiers
communiquants gnrent en dbut de communication.
Confidentialit
Service de scurit qui consiste s'assurer que seules les personnes autorises peuvent
prendre connaissance d'un ensemble de donnes. Le mcanisme qui permet d'obtenir ce
service est gnralement le chiffrement des donnes concernes l'aide d'un algorithme
cryptographique.
On parle aussi de confidentialit du trafic lorsqu'on dsire empcher l'analyse du trafic en
cachant les adresses source et destination, la taille des paquets, la frquence des changes,...
55
Contrle d'accs
Service de scurit permettant de dterminer, aprs avoir authentifi un utilisateur, quels sont
ses privilges et de les appliquer. Ce service a pour but d'empcher l'utilisation d'une
ressource (rseau, machine, donnes,...) sans autorisation approprie.
Cryptage, crypter
Termes drivs de l'anglais to encrypt et souvent employs incorrectement la place de
chiffrement et chiffrer. En toute rigueur, ces termes n'existent pas dans la langue franaise.
Si le "cryptage" existait, il pourrait tre dfini comme l'inverse du dcryptage, c'est--dire
comme l'action consistant obtenir un texte chiffr partir d'un texte en clair sans connatre
la clef. Un exemple concret pourrait tre de signer un texte choisi en reproduisant un
chiffrement avec la clef prive de la victime. Mais on prfre parler dans ce cas de
contrefaon.
Cryptanalyse ou analyse cryptographique
Science qui tudie la scurit des procds cryptographiques pour tenter de trouver des
faiblesses et pouvoir en particulier effectuer un dcryptage avec succs.
Cryptogramme
Aussi appel texte chiffr. Donnes obtenues par application d'un algorithme de chiffrement.
Le contenu smantique de ces donnes n'est pas comprhensible.
Cryptographie
tude du chiffrement et du dchiffrement, ainsi que des procds permettant d'assurer
l'intgrit, l'authentification,...
"Discipline incluant les principes, moyens et mthodes de transformation des donnes, dans le
but de cacher leur contenu, d'empcher que leur modification passe inaperue et/ou
d'empcher leur utilisation non autorise." [ISO 7498-2]
Cryptologie
tude scientifique de la cryptographie et de la cryptanalyse.
D
Dchiffrement
Action inverse du chiffrement, lorsque celui-ci est rversible : l'aide d'un algorithme
cryptographique et d'une clef, on reconstruit le texte en clair partir du texte chiffr.
Dcryptement, dcryptage
Action qui consiste "casser" le chiffrement d'un texte de faon retrouver le texte en clair
sans connatre la clef qui permet son dchiffrement normal.
Dni de service
"Impossibilit d'accs des ressources pour des utilisateurs autoriss ou introduction d'un
retard pour le traitement d'oprations critiques." [ISO 7498-2].
DHCP (Dynamic Host Configuration Protocol)
Protocole permettant de configurer les adresses IP de faon dynamique.
Disponibilit
Service de scurit qui assure une protection contre les attaques visant dgrader ou rendre
impossible l'accs un service.
56
E
EAP (Extensible Authentication Protocol)
Protocole trs gnrique permettant lidentification dutilisateurs selon diverses mthodes
(mot de passe, certificat, carte puce). Normalis par lIETF comme extension du protocole
PPP, lEAP est maintenant galement la base du 802.1X, lui-mme la base du WPA.
Empreinte (digest)
Aussi appel condens, chane de taille fixe obtenue par application d'une fonction de hachage
un ensemble de donnes.

F
Fonction sens unique
Une fonction sens unique est une fonction facile calculer mais difficile inverser. La
cryptographie clef publique repose sur l'utilisation de fonctions sens unique brche
secrte : pour qui connat le secret (i.e. la clef prive), la fonction devient facile inverser.
Fonction de hachage
Aussi appele fonction de condensation, fonction qui convertit une chane de longueur
quelconque en une chane de taille infrieure et gnralement fixe ; cette chane est appele
empreinte (digest en anglais) ou condens de la chane initiale.
Fonction de hachage sens unique
Fonction de hachage qui est en plus une fonction sens unique : il est ais de calculer
l'empreinte d'une chane donne, mais il est difficile d'engendrer des chanes qui ont une
empreinte donne. On demande gnralement en plus une telle fonction d'tre sans collision,
c'est--dire qu'il soit impossible de trouver deux messages ayant la mme empreinte.
I
ICV (Integrity Check Value)
"Valeur de vrification d'intgrit". Cette valeur est calcule par l'expditeur sur l'ensemble
des donnes protger. L'ICV est alors envoye avec les donnes protges. En utilisant le
mme algorithme, le destinataire recalcule l'ICV sur les donnes reues et la compare l'ICV
originale. Si elles se correspondent, il en dduit que les donnes n'ont pas t modifies.
IETF (Internet Engineering Task Force)
Un des groupes de travail charg de rsoudre les problmes techniques du rseau. C'est par
son biais que les standards Internet sont prpars et labors.
IKE (Internet Key Exchange)
Protocole dfinit par lIETF permettant lchange de cls entre deux tiers.
Intgrit
Service de scurit qui consiste s'assurer que seules les personnes autorises pourront
modifier un ensemble de donnes. Dans le cadre de communications, ce service consiste
permettre la dtection de l'altration des donnes durant le transfert.
On distingue deux types d'intgrit :
1. L'intgrit en mode non connect permet de dtecter des modifications sur un
datagramme individuel, mais pas sur l'ordre des datagrammes.
57
2. L'intgrit en mode connect permet en plus de dtecter la perte de paquets ou leur
rordonnancement.
L'intgrit est trs lie l'authentification de l'origine des donnes, et les deux services sont
souvent fournis conjointement.
IPsec (Internet Protocol Security)
Norme dfinissant une extension de scurit pour le protocole IP dans l'objectif d'offrir des
services d'authentification, d'intgrit et de confidentialit.
L
Liaison
Ensemble de matriels (cbles, modems, concentrateurs, routeurs,...) qui relient physiquement
deux quipements terminaux.
M
MAC (Message Authentication Code)
Code d'authentification de message.
Message
Dans le monde des rseaux, un message est une suite de donnes binaires formant un tout
logique pour les tiers communiquants. Lorsqu'un message est trop long pour tre transmis
d'un seul bloc, il est segment et chaque segment est envoy sparment dans un paquet
distinct.
MIC (Message Integrity Check)
Nombre calcul partir d'un message et envoy avec celui-ci. Le rcepteur peut ainsi s'assurer
que le message n'a pas t modifi.
MIM (Man In the Middle)
Une attaque MIM consiste pour un pirate s'interposer entre deux stations du rseau, leur
insu, de faon espionner leurs changes, voire les modifier.
N
Non-rejouabilit
Garantie qu'un adversaire ayant intercept des messages au cours d'une communication ne
pourra pas les faire passer pour des messages valides en les injectant soit dans une autre
communication, soit plus tard dans la mme communication.
P
PANA (Protocol for Carrying Authentication for Network Access)
Protocole agissant au-dessus de la couche IP permettant de transporter les messages
dauthentification, typiquement message EAP, entre un client et un agent (appel agent
PANA).
Perfect Forward Secrecy
Proprit d'un protocole d'change de clef selon laquelle la dcouverte, par un attaquant, du
ou des secrets long terme utiliss ne permet pas de retrouver les clefs de sessions.
R
RADIUS (Remote Authenticiation Dial-In-User Service)
Protocole de type AAA.

58
Rejeu
Action consistant envoyer un message intercept prcdemment, en esprant qu'il sera
accept comme valide par le destinataire.
Rpudiation
"Le fait, pour une des entits impliques dans la communication, de nier avoir particip aux
changes, totalement ou en partie." [ISO 7498-2]
RFC (Request For Comment)
Littralement, "Appel commentaires". C'est en fait un document dcrivant un des aspects
d'Internet de faon relativement formelle (gnralement, spcification d'un protocole). Ces
documents sont destins tre diffuss grande chelle dans la communaut Internet et
servent souvent de rfrence. On peut les trouver sur la plupart des sites FTP.
S
Signature numrique
"Donnes ajoutes une unit de donnes, ou transformation cryptographique d'une unit de
donnes, permettant un destinataire de prouver la source et l'intgrit de l'unit de donnes
et protgeant contre la contrefaon (par le destinataire, par exemple)." [ISO 7498-2].
Une signature numrique fournit donc les services d'authentification de l'origine des donnes,
d'intgrit des donnes et de non-rpudiation. Ce dernier point la diffrencie des codes
d'authentification de message, et a pour consquence que la plupart des algorithmes de
signature utilisent la cryptographie clef publique. D'autre part, la signature peut prendre
deux formes :
1. "transformation chiffre" : un algorithme cryptographique modifie directement le
message (par exemple chiffrement du message avec une clef prive).
2. "donnes annexes" : des donnes supplmentaires sont adjointes au message (par
exemple une empreinte, chiffre avec une clef prive).
Somme de contrle
Condens d'un ensemble de donnes, calcul par l'expditeur avant l'envoi des donnes et
recalcul par le destinataire la rception pour vrifier l'intgrit des donnes transmises.
T
Texte chiffr
Aussi appel cryptogramme.
Donnes obtenues par application d'un algorithme de chiffrement. Le contenu smantique de
ces donnes n'est pas comprhensible.
Texte en clair
Donnes intelligibles, dont la smantique est comprhensible.
Tierce partie (ou tiers) de confiance (Trusted Third Party)
Tiers jouant un rle dans la scurisation des changes entre deux partenaires en participant
la mise en uvre de mcanismes de scurit. On parle aussi de notarisation.
Tunneling
Technique consistant crer un "tunnel" entre deux points du rseau en appliquant une
transformation aux paquets une extrmit (gnralement, une encapsulation dans un
protocole appropri) et en les reconstituant l'autre extrmit.
59
V
Vecteur d'initialisation (Initialization Vector, IV)
Bloc de texte de valeur quelconque servant initialiser un chiffrement avec chanage de blocs,
et donc faire en sorte que deux messages identiques donnent des cryptogrammes distincts.
VPN (Virtual Private Network)
Rseau priv virtuel. Cest un rseau dordinateurs changeant entre eux de linformation par
des liaisons cryptes. On peut assimiler ces liaisons cryptes des tunnels protgs,
empruntant un rseau de voies ouvertes et publiques (par exemple Internet). On peut par
exemple interconnecter les rseaux de deux sites dune entreprise en tablissant un VPN,
passant par lInternet.

60

Master SecuriteReseauxMesh OCheikhrouhou FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Master SecuriteReseauxMesh OCheikhrouhou FR

Transféré par

Droits d'auteur :

Formats disponibles

Rpublique Tunisienne

Cycle de Formation Doctorale

Vous aimerez peut-être aussi