Rapport - Olivier Houssenbay - 802.1x

MMOIRE DE FIN D'TUDES
HOUSSENBAY Olivier
Entreprise d'accueil : Laboratoire de cryptologie et virologie oprationnelle (C+V)O

38 Rue des Docteurs Calmette et Gurin, 53000 Laval
FreeRadius, un serveur d'authentification forte pour

ALCASAR
FreeRadius, a strong authentication server for ALCASAR
M. Vincent GUYOT, Prsident du jury, Enseignant chercheur l'ESIEA, Docteur en Informatique

M. Richard REY, Matre de stage, Ingnieur de recherche en scurit informatique
M. Nicolas DEVILLY, Tuteur pdagogique, Chef d'entreprise de la socit AtoutSens
Table des matires

Remerciements.....................................................................................................................................3
Rsum.................................................................................................................................................4
Abstract.................................................................................................................................................5
I - Introduction......................................................................................................................................6
A ) Entreprise daccueil...............................................................................................................6
B ) Le projet................................................................................................................................7
II - tat de l'art......................................................................................................................................8
A ) LDAP....................................................................................................................................8
B ) Kerberos................................................................................................................................9
C ) Radius....................................................................................................................................9
D ) Diameter..............................................................................................................................10
E ) Le protocole 802.1X............................................................................................................10
F ) Les certificats X.509............................................................................................................11
Partie 1 : Radius..................................................................................................................................12
A ) Historique............................................................................................................................12
B ) Description du protocole.....................................................................................................12
1. Qui peut tre un client RADIUS ?...............................................................................13
2. Le protocole RADIUS dans le modle OSI.................................................................14
3. Format des paquets RADIUS......................................................................................15
4. Les attributs RADIUS.................................................................................................16
5. Les attributs constructeurs...........................................................................................18
6. Les types de paquets RADIUS....................................................................................19
Partie 2 : Radius dans Alcasar............................................................................................................20
A ) L'authentification UAM......................................................................................................22
1. Le mcanisme..............................................................................................................22
2. Scurisation du mot de passe.......................................................................................25
3. Demande d'authentification :.......................................................................................28
4. La base de donnes : MariaDB....................................................................................30
B ) FreeRadius..........................................................................................................................32
C ) Authentification 802.1X......................................................................................................35
D ) Problmes rencontrs : Authentification 802.1X................................................................39
E ) Problmes rencontrs : Point d'accs Wi-Fi........................................................................41
F ) Amliorations & Perspectives.............................................................................................43
Conclusion..........................................................................................................................................44
Bibliographie et Webographie............................................................................................................45
HOUSSENBAY Olivier
Mmoire de fin d'tudes
Remerciements
Avant tout dveloppement sur cette exprience, il apparat opportun de commencer ce
mmoire par des remerciements.
Mes premires penses se tournent vers mon matre de stage M. Richard REY, ingnieur de
recherche en scurit informatique, ainsi que M. Eric Filiol, directeur de recherche, qui mont
accueilli au Laboratoire CVO1 de l'ESIEA2 OUEST.
Je remercie M. REY pour avoir tout mis en uvre pour que mon stage de fin dtudes se
passe dans les meilleures conditions ainsi que pour ses judicieux conseils formuls avec beaucoup
de pdagogie tout au long du stage.
Je souhaiterai aussi remercier M. Nicolas DEVILLY, mon tuteur pdagogique avec qui jai
entretenu de bons rapports. Il a t lcoute et m'a appris adopter une bonne approche
professionnelle au sein du Laboratoire CVO.
Et enfin, un grand merci lquipe du laboratoire qui ma accompagn tout au long de cette
exprience et qui a eu la gentillesse de faire de ce stage, un moment trs profitable.
1 Cryptologie et Virologie Oprationelles

2 cole Suprieure dInformatique, lectronique et Automatique
HOUSSENBAY Olivier
Rsum
Comment dployer un systme d'authentification forte au sein de ALCASAR : Application
Libre pour le Contrle d'Accs Scuris et Authentifi au Rseau ?
Le stage s'est droul en trois parties distinctes : une phase d'analyse et de remise niveau,
une approche approfondie du sujet et la mise en uvre du travail raliser.
Les prmices du projet ont consist analyser le fonctionnement du serveur
d'authentification Freeradius et des protocoles mis en place.
La vrification et la correction de la configuration du serveur Freeradius a permis de mieux
connatre son principe de fonctionnement notamment sur les aspects d'arborescence des fichiers
utiliss par le serveur, les compteurs SQL pour le calcul des autorisations et le protocole
d'identification utilis lors de l'authentification sur le serveur.
La dernire partie du stage consistait reprendre toutes les notions acquises prcdemment
et les mettre en uvre de manire raliser une authentification forte base sur le standard IEEE
802.1X avec une mthode d'authentification bilatrale par certificat client/serveur.
Ce mmoire de stage au sein du laboratoire CVO de l'ESIEA-Ouest montre une dmarche
(problmes et solutions proposes) possible pour apprhender et mettre en place une
authentification forte avec un serveur Radius.
HOUSSENBAY Olivier
Abstract
How to deploy a strong based authentication in ALCASAR: Free Application for Secured
and Authenticated Access Control to Network?
This internship has been done in three parts : an analysis and a review of the prerequisites, a
deep approach about the subject then an implementation of the content involved.
Premises of the project consisted to analyze how the server authentication FreeRadius runs
and the protocols inside.
Checking and patching have been processed through the configuration of Freeradius server
to a better understanding of the operating principle particularly on file tree aspect used by the
server, the SQL counters to compute authorizations and the identification protocol used during the
authentication process on the server.
The last part of this internship was to take all the concepts previously acquired with the aim
to implement a strong authentication based on the IEEE 802.1X standard with a bilateral client /
server certificate authentication method.
This internship dissertation within the CVO laboratory ESIEA West shows a possible way
(problems and given solutions) of understanding and implementing a strong authentication based on
a Radius server.
HOUSSENBAY Olivier
I - Introduction
A ) Entreprise daccueil
LESIEA est implante sur deux sites. On y retrouve le sige social Paris 5 e o les locaux
permettent aux professeurs denseigner principalement dans les classes de 2 e et 3e anne du cycle
dingnieur ainsi que le Mastre SI&S mais galement dautres locaux Ivry-sur-Seine o la
majorit des cours ont lieu. Le campus de Laval, o jai effectu mon stage, ft cr en 1993 grce
des aides de la rgion et des collectivits locales afin de promouvoir la ville et offrir la population
un choix supplmentaire dans le cycle suprieur des tudes.
LESIEA Laval a pour vocation de fournir les mmes enseignements qu Paris avec une
rplication de certaines associations et la venue ponctuelle de certains enseignants de lESIEA Paris.
Nanmoins, ce qui fait la particularit de ce site, rside dans la cration du laboratoire en 2007
Centre de virologie et de cryptologie oprationnelles encadr par M. Eric Filiol et M. Richard
Rey partir de 2008. Plus tard, le label du laboratoire prendre le nom de CNS pour "Confiance
Numrique et Scurit".
M. Eric Filiol a t nomm la tte du CNS aprs sa carrire militaire ce qui octroie au
laboratoire des liens troits avec les ministres de la Dfense, de la Justice ou encore de lIntrieur.
Le laboratoire a ainsi pu encadrer des missions raliser pour ses diffrents ministres en prenant
compte de la scurit mettre en place. Le CNS a d tre ramnag en 2011 afin de correspondre
aux critres ncessaires pour la ralisation de sujets caractres sensibles.
Le laboratoire assure les thmes suivants :
Cryptologie
Analyse et conception de systmes stnographiques
Virologie informatique
Analyse et tudes techniques du concept de guerre informatique
Scurit des environnements embarqus
Algorithmes des structures complexes et applications
Mcanismes de Flash Crash
Le laboratoire sinscrit galement dans une dmarche de veille technologique afin
dapprhender les menaces daujourdhui et celles de demain.
Depuis Janvier 2015, le CNS propose galement certains tudiants la possibilit
deffectuer un stage en tests dintrusions avec laccord des entreprises cibles.
Des projets sont en dveloppement avec, entre autres :
Le projet DAVFI (Dmonstrateurs dAntiVirus Franais et
Internationaux) avec la mise en place de nouveaux modles de
dtection et galement une analyse en profondeur des fichiers
octroyant un meilleur taux de dtection des malwares actuels et
venir. Ce projet sinscrit partir de fvrier 2015 dans la solution Uhuru Antimalware.
Paralllement, une version libre et gratuite est en cours de dveloppement pour les systmes
Windows et Linux ("OpenDAVFI").
Le projet Alcasar gr par M. Richard REY et dvelopp par lui-mme et

un grand nombre de contributeurs. Ce projet a pour but de contrler les
accs internet des utilisateurs prsents sur le rseau via de nombreuses
fonctionnalits garantissant trois grands principes de la scurit :
lauthentification, la non-rpudiation et la traabilit.
HOUSSENBAY Olivier
B ) Le projet
Durant mon stage au sein du laboratoire CVO, j'ai d raliser plusieurs types de missions. Le stage
s'est droul en trois parties :
Une phase de remise niveau rseau par la pratique de plusieurs travaux dirigs et encadrs
par M. Rey
Puis une rdaction du module pdagogique via une tude et application du protocole Radius
et de ses dpendances.
Enfin, la mise en place d'un mcanisme d'authentification forte dans ALCASAR.
La dernire partie correspond la majeure partie de mon stage, mais les travaux prliminaires qui
m'ont t confis ont permis de mieux apprhender la problmatique suivante :
Comment raliser une authentification forte dans une solution existante (ALCASAR) ?
J'aborderai les diffrentes phases suivantes :
Dans un premier temps, un tat de l'art des diffrents moyens disposition pour raliser une
authentification.
Puis, le corps du document dcrira le protocole choisi et son implmentation.
Enfin, je porterai une rflexion sur les problmes techniques que j'ai pu rencontrer au sein
du stage ainsi que les possibles volutions mettre en uvre au sein du projet.
HOUSSENBAY Olivier
II - tat de l'art
Lobjectif premier de mon stage a t de mettre en place un systme dauthentification des
usagers sur le rseau dans le cadre du projet ALCASAR. Tout dabord, que signifie
lauthentification ?
Lauthentification est un des grands principes de la scurit et consiste, dans un systme
dinformation, contrler laccs aux ressources par le biais dune vrification de lidentit dun
utilisateur. Lauthentification existe sous diffrentes formes. On retrouve une description gnrale
de ce quest en mesure de faire un utilisateur pour sauthentifier :
Ce que lutilisateur sait (exemple : un mot de passe)
Ce quil sait faire (exemple : une signature lectronique)
Ce quil est (exemple : la rtine des yeux, son empreinte digitale, )
Ce quil possde (exemple : une carte puce, une carte RFID, un authentificateur USB,
)
Il existe trois types dauthentification :
Lauthentification simple : un seul lment de vrification
Lauthentification forte : deux lments ou plus de vrification
Lauthentification unique : une seule authentification pour accder plusieurs ressources
Quand lauthentification savre-t-elle ncessaire ?
Celle-ci intervient dans les rseaux numrs ci-dessous :
Sur un rseau local
Sur un rseau local tendu : lIntranet
Sur lInternet dans loptique daccder des ressources confidentielles ou commerciales
Cette liste nest pas exhaustive, mais rassemble les principaux usages ce systme.
Les principaux protocoles utiliss sur le march sont les suivants :
A ) LDAP
Un serveur LDAP peut tre communment appel Rpertoire du systme . On le
considre comme une base de donnes, essentiellement dans le but de stocker des informations sur
diverses entits sur le rseau. En gnral, le serveur enregistre les donnes suivantes :
Les noms dutilisateurs et mots de passe
Les droits confrs aux utilisateurs
Les informations de configuration
Les priphriques connects sur le rseau
Lors dune authentification dun utilisateur sur le rseau, le serveur LDAP vrifie les
informations et attribue les droits correspondants au profil renseign. Un serveur LDAP fait office
de cur dauthentification du systme.
HOUSSENBAY Olivier
B ) Kerberos
Lobjectif est de contrler les accs des services sur un serveur. Ce serveur
dauthentification centralis est en mesure dauthentifier les clients vers les serveurs mais linverse
est galement possible. Kerberos utilise une mthode de chiffrement qui ne repose pas sur
lutilisation de clefs publiques. Ce protocole est galement responsable de reporter aux services sur
le rseau lidentit dun utilisateur connect. Pour cela, il contrle le nom dutilisateur et le mot de
passe dune machine qui vient de sauthentifier et utilise un systme de ticket pour lidentification
future de lutilisateur. Ce protocole base donc lauthentification des usagers par lintermdiaire de
tickets.
Le protocole est en mesure de remplacer la phase dauthentification dun serveur LDAP
mais nexclut pas le besoin de celui-ci. En effet, il est possible de coupler Kerberos un serveur
LDAP qui jouerait le rle du stockage des informations sur les utilisateurs.
Le systme de tickets possde des avantages notables compar une authentification par un serveur
LDAP. En effet, si le serveur LDAP tombe en panne, les services rseau vont suivre larrt du
serveur puisquils ncessitent un systme dauthentification. Par ailleurs, le systme de tickets
propos par Kerberos permet dauthentifier les utilisateurs sans avoir consulter dautres serveurs
par lutilisation de signatures cryptographiques. De plus, envoyer les identifiants sur le rseau peut
tre risqu notamment via une attaque de lhomme du milieu . Kerberos possde une contremesure efficace puisque les tickets ne contiennent pas dinformations sensibles, ont une date
dexpiration et ne peuvent tre utiliss que pour le service demand.
C ) Radius
Ce protocole repose sur le principe des 3A : Authentication (Authentification) Authorization
(Autorisation) Accounting (Comptabilisation).
Authentification : Le protocole permet deffectuer une authentification distante, centraliser les
donnes dauthentification et grer les connexions des utilisateurs vers des services distants.
Autorisation : Le protocole vrifie les droits attribus un utilisateur.
Comptabilisation : Le protocole est en mesure de journaliser lactivit dun utilisateur sur le
rseau pour effectuer entre autres une future facturation.
Ce protocole a trouv sa rputation auprs des fournisseurs daccs internet qui lutilisent
pour identifier les clients coupl un serveur LDAP. Il est galement employ pour grer
lauthentification sur des points daccs WIFI. Il repose sur la couche UDP. En effet, Radius est un
protocole dit sans tat ce qui permet de simplifier la mise en uvre du serveur puisque celui-ci
nattend pas daccus de rception.
On trouvera 4 types de paquets permettant deffectuer une authentification Radius :
Access-Request : Ce paquet est envoy par le NAS qui contient les informations
dauthentification du client.
Acess-Accept : Ce paquet est envoy par le serveur afin dautoriser la connexion par
vrification pralable des informations de lutilisateur souhaitant se connecter.
Access-Reject : Le serveur envoie ce paquet lorsquil refuse une connexion si
lauthentification choue ou si la connexion doit prendre fin.
HOUSSENBAY Olivier
Access-Challenge : Le serveur envoie ce paquet afin de demander une rmission du

paquet Access-Request ou pour obtenir des informations complmentaires.
D ) Diameter
Diameter est un protocole d'authentification forte qui offre, tout comme Radius, le triple A
(Authentification = Authentication, Autorisation = Authorization, Comptabilit = Accounting). Il est
utilis sur les rseaux mobiles (3G, 4G, ...) dans l'optique de fournir un accs au rseau et pour
rpondre la problmatique d'itinrance.
Lorsque la technologie IP a t introduite sur les rseaux de tlcommunication, Diameter a
t slectionn pour tre la rfrence des protocoles qui rpondent au modle AAA sur les rseaux
fixe et mobile.
Le protocole Diameter (Diamtre) est un jeu de mots faisant hommage au protocole Radius
(Rayon). Il a t adopt par des organismes de normalisation tels que 3GPP (3rd Generation
Partnership Project) ainsi que l'ETSTI (European Telecommunications Standards Institute) comme
tant le standard des fonctionnalits AAA pour la gnration future des rseaux "Next-Generation
Networks".
Diameter a t conu sous les AAA afin de prendre en charge davantage de fonctionnalits
par rapport son prdcesseur telles que :
La politique de contrle
Les rgles dynamiques
La qualit de service (QOS)
L'allocation de la bande passante
De nouveaux systmes de tarification
Ce protocole peut galement tre tendu de nouvelles applications par l'ajout de nouvelles
commandes ou de couples d'attribut-valeur. Diameter est galement le seul protocole capable de
grer des fonctionnalits temps rel pour des transactions.
Pour rsumer, les atouts apports par Diameter compar au protocole Radius sont les
suivants :
Transmission fiable avec l'utilisation de protocoles avec tat : TCP ou SCTP (Stream
Control Transmission Protocol)
Garantie de la dlivrance des messages Diameter
Possibilit de mettre en place des agents permettant la prise en charge de proxy(s),
redirection(s), relai(s), ...
Modularit illimite afin de permettre l'extension du protocole sur diverses applications.
E ) Le protocole 802.1X
Ce protocole a t cr par lIEEE en Juin 2001. Il consiste authentifier un client sur le
HOUSSENBAY Olivier
10
rseau. Pour ce faire, le protocole EAP (Extensible Authentication Protocol) est coupl au serveur
Radius. Comment le protocole 802.1X entre en jeu avec Radius ?
Lors de linitialisation de la connexion, le port est dans ltat non contrl . Cela signifie
que seuls les paquets 802.1X permettant lauthentification sont autoriss. Lorsque lauthentification
russit, le port bascule alors dans ltat contrl . Ainsi, le trafic provenant du client est accept
et le client accde alors aux ressources partages sur le rseau.
Le protocole 802.1X embarque plusieurs types dEAP :
EAP-TLS : Permet deffectuer une authentification par certificat au niveau client et serveur
EAP-TTLS : Permet deffectuer une authentification par certificat ainsi que mot de passe
par la cration dun tunnel scuris.
EAP-MD5 : Permet deffectuer une authentification par mot de passe.
PEAP : Permet deffectuer une authentification avec mot de passe via une encapsulation
scurise.
LEAP (propritaire CISCO) : Mme rle que PEAP.
F ) Les certificats X.509

Radius permet dauthentifier ses utilisateurs via un certificat. Ci-dessous, un tableau reprsentant les
diffrentes implmentations dun certificat :
Figure 1: Avantages et inconvnients de l'implmentation des certificats X.509

(source http://repo.hackerzvoice.net)
HOUSSENBAY Olivier
11
Partie 1 : Radius
A ) Historique
RADIUS a t conu dans le but initial de contrler l'authentification distance. Ce besoin
est n de la socit Merit Network qui souhaitait identifier ses utilisateurs via la liaison
tlphonique afin de fournir un accs distant son rseau informatique. L'organisation but non
lucratif Merit Network a publi en 1991 une demande d'information ou Request for
Information (RFI) qui spcifiait les fondements du protocole3 RADIUS.
Aprs quelques mois, la socit Livingston Enterprises rpondit cette demande par une
description d'un serveur RADIUS. La proposition fut retenue par Merit Network qui donna le
contrat Livingstone Enterprises . Le protocole RADIUS Remote Authentication Dial-in User
Service traduit littralement par Authentification distance compose par le service utilisateur est
publi par l'IETF4 en Janvier 1997 dans la RFC5 2058 et la RFC 2059.
Cette mme anne, la socit Livingstone Enterprises leader dans l'accs distance des
rseaux informatiques, fut rachete par Alcatel-Lucent. Le standard RADIUS a subi plusieurs
volutions au fil des annes et l'heure d'aujourd'hui, il est de facto le protocole le plus clbre pour
l'authentification des postes de travail, des terminaux mobiles, des quipements rseaux, etc...
La description actualise du standard se trouve dsormais dans la RFC 2865 et la RFC 2866 datant
de Juin 2000.
B ) Description du protocole
Le protocole RADIUS a volu au fil des annes. Il intgre aujourd'hui de nombreuses
fonctionnalits. Auparavant ce protocole rpondait uniquement aux besoins d'authentification et de
traabilit. Il s'est calqu sur le modle du protocole AAA 6 qui permet de raliser trois
fondamentaux de l'accs une ressource informatique :
Authentication (Authentification) : c'est la fonction principale de scurit qui consiste

prouver qu'une identit appartient bien celui qui la prsente. Elle peut tre ralis en
comparant des credentiels (nom d'utilisateur/mot de passe), certificat numrique,etc ;
Authorization (Autorisation) : c'est la capacit accder, une fois l'authentification

valide, un service ou des ressources du systme d 'information ;
Accounting (Compatibilit) : c'est journaliser les accs, les temps de session, les
ressources consommes, etc... afin de garantir la traabilit des informations.
Le principe des changes du protocole RADIUS est bas sur des requtes/rponses (voir figure 2)
avec des clients RADIUS aussi appels NAS7 ou plus simplement service d'authentification.
3
4
5
6
7
Dfinition de protocole en communication

IETF : Internet Engineering Task Force, groupe informel qui publie la plupart des nouveaux standards internet
RFC : Request For Comments, document publi par l'IETF
AAA : Authentication Authorization Accounting, Authentification Autorisation Comptabilit
NAS : Network Access Server, serveur d'accs au rseau
HOUSSENBAY Olivier
12
1. Qui peut tre un client RADIUS ?

Un client RADIUS est un quipement ou bien une solution logicielle qui est capable
d'envoyer des demandes de connexion (requtes) et des messages un serveur RADIUS. Il peut
interprter les rponses du serveur RADIUS et, de ce fait, valider ou non une authentification et/ou
obtenir des autorisations. Par la suite, ces informations sont transmises au poste de travail souhaitant
accder la ressource informatique.
Voici quelques exemples de client RADIUS :
Serveur de connexion VPN8, donne l'accs distance aux ressources informatiques d'une
organisation ;
Points d'accs sans fil utilisant la technologie Wi-Fi 9, fournit un accs au rseau local d'une
entreprise ;
Commutateurs, fournit galement l'accs au rseau local ;
Proxy RADIUS, transfre les requtes/rponses d'un client RADIUS vers un serveur
RADIUS distant.
Figure 2 : Principe des changes du protocole RADIUS
8
9
VPN : Virtual Private Network

Wi-Fi : Wireless Fidelity
HOUSSENBAY Olivier
13
2. Le protocole RADIUS dans le modle OSI 10

Le modle OSI, dvelopp par l'ISO11, est un standard commun afin de normaliser les
communications entre ordinateurs et plus gnralement entre les systmes informatiques. Il dfinit
une architecture dcompose en plusieurs couches, o chacune a une fonctionnalit spcifique. Cela
a permis d'tablir un accord entre les diffrents constructeurs d'quipements informatiques pour
ainsi homogniser l'interconnexion des systmes htrognes.
Les couches du modle OSI sont les suivantes :
Application
Prsentation
Session
Transport
Rseau
Liaison
Physique
Le protocole RADIUS se situe au niveau des couches hautes, dans la couche applicative du
modle OSI. Il se place au-dessus de la couche transport. Les donnes du protocole RADIUS sont
achemines par des segments du protocole UDP 12 et encapsules dans des paquets IP13 (voir figure 3
et 4).
Les ports d'coute UDP utiliss pour accder aux services proposs par le protocole
RADIUS sont les suivants :
1812, reoit les requtes d'authentification et d'autorisations ;
1813, reoit les requtes d' accounting (comptabilit).
Figure 3 : Le protocole RADIUS au sein du modle OSI
Figure 4 : Encapsulation du protocole RADIUS

10
11
12
13
OSI : Open Systems Interconnection

ISO : International Standard Organization
UDP : User Datagram Protocol, c'est de protocole de transmission des donnes
IP : Internet Protocol, fournit un service d'adressage permettant d'identifier les quipements informatique
HOUSSENBAY Olivier
14
3. Format des paquets RADIUS

Le protocole RADIUS utilise un format de paquet bien dfini pour raliser les transactions
d'authentification, d'autorisation et de comptabilit. Le modle des donnes RADIUS contient les
champs ci-contre:
1. Code ;
2. ID ;
3. Longueur ;
4. Authentificateur ;
5. Attributs et Valeurs.
Figure 5 : Format des trames RADIUS

Ces champs accueillent des types de donnes dcrites dans la RFC du protocole RADIUS.
Code
Ce champ identifie le type du paquet RADIUS. En effet, le protocole dfinit 255 types de paquets
que l'on peut trouver dans la RFC 3575. Cependant, je vais citer uniquement les types que j'ai t
amen utiliser.
Il s'agit de :
Access-Request
Access-Challenge
Access-Accept
Access-Reject
Accounting-Request
Accounting-Response
Je dtaillerai plus loin la fonction de ces diffrents types de paquets et leurs utilisations dans le
protocole RADIUS.
ID
Ce champ permet de mettre en relation un identifiant au client RADIUS avec le couple
requtes/rponses.
Longueur
Ce champ contient la longueur totale des donnes RADIUS.
HOUSSENBAY Olivier
15
Authentificateur
Ce champ permet de vrifier l'intgrit des paquets envoys par le serveur RADIUS. Il est calcul
de manire alatoire partir d'un secret partag (mot de passe connu par le serveur et le client) entre
le client et le serveur. Ainsi, le client RADIUS peut s'assurer que la rponse lui vient bien du
serveur RADIUS et non d'un usurpateur.
Attributs et valeurs
Ce champ contient la charge utile du protocole RADIUS. Il est de longueur variable en fonction
des couples d'attributs/valeurs envoys par le client RADIUS en requte ou par le serveur RADIUS
en rponse.
Aprs cette description gnrale du protocole RADIUS, je vais exposer l'utilit du champ attributs
et valeurs .
4. Les attributs RADIUS

Les informations contenues dans les requtes/rponses d'authentification, d'autorisation et de
comptabilits sont transportes par les couples attributs/valeurs du protocole. Le champ attribut et
valeur joue un rle primordial dans les changes RADIUS. En effet, c'est lui qui va vhiculer les
informations relatives l'authentification, l'autorisation ou la comptabilit. Chaque attribut est
caractris par un numro d'attribut, une longueur ainsi qu'une valeur (voir figure 6). Dans le jargon
RADIUS, un couple attribut/valeur est appel AVP "Attributes Value-Pair".
Un attribut peut prendre les valeurs suivantes :
adresse IP ;
date ;
chane de caractre (par exemple un mot de passe) ;
entier (un numro de port) ;
valeur binaire ou hexadcimale
.
Figure 6 : Champ attributs et valeurs du protocole RADIUS

HOUSSENBAY Olivier
16
Dans les paquets RADIUS, le nom d'un attribut n'apparat jamais. Seul le numro de
l'attribut est prsent. La correspondance entre le nom de l'attribut et son numro est faite grce un
dictionnaire d'attributs implment sur le client et sur le serveur.
Les dictionnaires d'attributs contiennent la concordance entre les attributs standards et leurs
numros respectifs. Mais il peut galement avoir des dictionnaires d' attributs constructeurs .
J'aborderai la notion de ces attributs particuliers plus loin.
Le protocole RADIUS compte un grand nombre d'attributs (plus d'une centaine). La liste
complte des attributs est consultable sur le site internet de l'organisation IANA14 au lien suivant :
http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2
Je vais dfinir certains de ces attributs afin de mieux apprhender leur utilisation au sein de
l'authentification RADIUS.
"User-Name"
Cet attribut est envoy par le client RADIUS lors de la demande d'authentification. Il peut
correspondre un identifiant utilisateur associ un mot de passe. Dans le cas de l'authentification
d'une machine, cet attribut peut prendre la valeur de l'adresse physique de celle-ci plus
communment appele adresse MAC15. Lors de l'utilisation d'un certificat lectronique, la valeur
reue par l'attribut User-Name est le nom du porteur du certificat.
"User-Password"
Cet attribut contient le mot de passe associ l'attribut User-Name. Il est galement envoy
par le client RADIUS.
"NAS-IP-Address"
Cet attribut est renseign par le client RADIUS (NAS). Il contient son adresse IP. Cet
attribut peut imposer une restriction. Par exemple, un poste de travail ne pourra s'authentifier que
s'il se connecte partir d'un NAS possdant une adresse IP spcifique.
"Nas-Port"
Cet attribut permet d'ajouter une condition supplmentaire pour l'authentification. Prenons
l'exemple d'un quipement rseau de type commutateur. Ainsi, un poste de travail est autoris
s'authentifier uniquement s'il est connect sur un port prcis du commutateur. L'attribut Nas-Port
donne le numro de port sur lequel est connect un poste utilisateur. Il est envoy par le NAS lors
de la demande d'authentification.
Dans la technologie sans fil, cet attribut perd son sens, car un point d'accs gnre un port
"virtuel" au moment de l'association du poste de travail celui-ci.
"Called-Station-Id"
Cet attribut contient l'adresse MAC du NAS qui demande l'authentification au serveur RADIUS
"Calling-Station-Id"
Cet attribut contient l'adresse MAC du poste de travail souhaitant s'authentifier.
14 IANA : Internet Assigned Numbers Authority, Autorit qui gre la numrotation requise par les protocoles de
communications
15 MAC : Media Access Control, adresse physique unique stocke dans toutes les cartes rseaux
HOUSSENBAY Olivier
17
Comme nous l'avons vu prcdemment, lorsqu'un client RADIUS soumet une requte
d'authentification, il renseigne diffrents attributs. Ces attributs sont dfinis par le standard
RADIUS. Toutefois, il existe des attributs supplmentaires implments par les constructeurs
d'quipement rseau. Ceux-ci offrent des fonctionnalits optionnelles afin de raliser des oprations
ddies sur les quipements par le biais du protocole RADIUS.
5. Les attributs constructeurs

L'ajout d'attribut(s) constructeur permet aux administrateurs rseau de tirer un meilleur
profit des capacits de leurs quipements rseau. En effet, ils offrent aux fournisseurs la possibilit
de spcifier 255 attributs supplmentaires pour leurs matriels. L'implmentation d'un dictionnaire
d'attributs constructeur permet le support de ceux-ci sur le serveur RADIUS. Bien videmment,
seuls les quipements constructeurs pourront interprter la valeur d'un attribut propritaire.
Cet attribut est appel Vendor Specific Attributes (VSA) dans la terminologie RADIUS.
Il est identifi par le numro d'attribut 26. L'attribut VSA est similaire au couple attribut/valeur
(AVP) RADIUS (voir figure 7). Chaque attribut VSA est constitu des champs suivants :
N d'attribut : c'est le numro 26 qui est dfini pour l'attribut VSA dans le standard
RADIUS ;
Longueur : contient la longueur totale de l'attribut ;
Vendor-id : contient le code international du constructeur. Chaque constructeur possde
un code qui lui est propre. On trouve la liste des codes constructeur dans la RFC 1700 ;
N d'attribut constructeur : contient le numro d'attribut spcifi par le constructeur ;
Longueur VSA : contient la longueur du champ VSA ;
Valeur de l'attribut constructeur : contient la valeur de l'attribut VSA.
Figure 7 : Format des attributs VSA
HOUSSENBAY Olivier
18
6. Les types de paquets RADIUS

Comme mentionn dans la sous partie 3, chaque change RADIUS est caractris par un
paquet associ un code. La figure ci-dessous prsente quelques utilisations des types Radius :
Figure 8: Les changes au sein du protocole RADIUS

Le type Access-Request
Lors d'une authentification RADIUS, le dialogue est toujours initi par le NAS. Tout d'abord, il
collecte les informations auprs du poste de travail souhaitant accder la ressource informatique,
puis, il transmet ces informations sous forme de couples attributs/valeurs par le biais du protocole
RADIUS vers le serveur RADIUS. Enfin, la demande d'authentification est alors achemine par un
paquet de type Access-Request .
Le type Access-Challenge
Une fois la demande d'authentification reue par le serveur RADIUS, ce dernier peut demander des
informations supplmentaires au NAS. Il y a alors mission d'un paquet de type AccessChallenge de la part du serveur vers le NAS. En consquence, le serveur attendra la rception d'un
nouveau paquet de type Access-Request de la part du client RADIUS afin d'obtenir les
informations demandes.
Le type Access-Accept
Lorsque l'ensemble des donnes d'authentification mises par le client RADIUS au moyen de
paquet Access-Request ont t valides par le serveur RADIUS. Celui-ci notifie le client du
succs de l'authentification en envoyant un paquet de type Access-Accept . Ce paquet peut
contenir des attributs constructeurs destins au client Radius. Il peut galement comporter des
autorisations (attributs de retour) dfinissant des rgles de scurit appliquer la session du poste
de travail authentifi.
HOUSSENBAY Olivier
19
Le type Access-Reject
Quand un ou plusieurs lments d'authentification transmis par le client RADIUS sont incorrects ou
qu'il ne respectent pas la politique de scurit informatique, le serveur rpond par un paquet de type
Access-Reject .
Le type Accounting-Request
Une fois la phase d'authentification russie, le client RADIUS envoie de manire priodique un
paquet de type Accounting-Request au serveur. Ce paquet fait l'inventaire des traces
enregistres du poste authentifi telles que le temps de session, l'adresse IP attribue, le nombre de
paquets changs sur le rseau, etc.
Le type Accouting-Response
Ce paquet est une rponse du serveur la requte de traabilit mise par le client. Il permet
d'indiquer la russite ou non de l'enregistrement des donnes.
Que souhaite-t-on authentifier et comment ?
Dans un systme d'information, il y a des machines (ou quipements) et des utilisateurs.
Dans le cas de l'authentification des machines, une fois leur identification valide, elles gardent les
mmes droits d'accs au sein du systme. Tout utilisateur sera donc dpendant des droits attribus
la machine.
En revanche, si on authentifie des utilisateurs et non plus des machines, alors chaque utilisateur
bnficiera de droits d'accs personnaliss. Les autorisations attribues la machine authentifie
dpendent de l'usager qui l'utilise.
Les donnes d'authentification prsenter au serveur RADIUS dpendent du niveau de scurit que
l'on souhaite adopter.
Partie 2 : Radius dans Alcasar

Mon travail sur l'authentification forte s'est ax sur principalement sur quatre briques de la
solution ALCASAR. La passerelle d'interception Coova-Chilli, le serveur FreeRadius et la base de
donnes SQL MariaDB.
Bien que ce soit une petite partie des fonctionnalits de ALCASAR cela reste l'un des
principaux piliers de scurit qu'offre cette application open-source.
La figure 9 place le contexte dans lequel j'ai travaill dans le projet. Je dtaillerai dans un
premier temps les lments du cadre A puis ceux du cadre B.
HOUSSENBAY Olivier
20
Figure 9: Schma de principe ALCASAR

Houssenbay Olivier
Mmoire de fin d'tude
21
Aprs avoir effectu un travail de recherche sur FreeRADIUS et compris les principaux
mcanismes d'authentification qu'il embarque, j'ai commenc la prise en main du serveur
FreeRADIUS de Alcasar. Dans un premier temps, il a fallu analyser les changes entre les
diffrentes composantes rattaches au serveur.
Coova-chilli : C'est une passerelle d'interception qui bloque tout dispositif, non authentifi,
du rseau local souhaitant accder l'Internet. Elle fait transiter tout le flux rseau grce une
interface virtuelle TUN016. Par ailleurs, cette composante intgre un mini serveur http qui coute sur
le port 80 afin de rediriger un quipement du rseau de consultation vers la page d'interception
"intercept.php" fournie par le serveur Apache.
Elle traite galement les donnes d'authentification envoyes par l'quipement souhaitant
s'authentifier sur le rseau. De plus, elle est client RADIUS. Ainsi, c'est elle qui va gnrer des
requtes d'authentification destines au serveur FreeRadius. Enfin, elle s'occupe aussi de collecter
des donnes de comptabilit (dure de connexion, volume de donnes chang, etc) et les transmet
au serveur. Elle peut dconnecter un usager.
mon arrive, Coova permettait de raliser une authentification UAM 17 travers un
navigateur Web. Mon objectif tait de trouver une solution pour que Coova puisse galement
proposer un mcanisme d'authentification forte bas sur le standard IEEE 802.1X. J'ai donc tudi
la procdure d'authentification qui tait en place.
Dans un premier temps, je parlerai de l'authentification UAM puis dans un second
temps,j'aborderai la solution IEEE 802.1X greffe au projet. Nous verrons donc comment le
standard 802.1X ralisant une authentification forte peut cohabiter avec le mcanisme
d'authentification universelle.
A ) L'authentification UAM
La force de ce mcanisme est qu'il peut tre dploy dans un milieu o les terminaux et les
systmes sont htrognes. En effet, il suffit que les dispositifs souhaitant sauthentifier disposent
d'un navigateur Web.
Par ailleurs, l'quipe de ALCASAR a dvelopp une solution sre pour l'acheminement des donnes
d'authentification depuis le navigateur de l'usager jusqu' l'application.
1. Le mcanisme
Nous pouvons voir sur la figure 10 un usager s'authentifiant sur le rseau avec les diffrentes phases
d'changes opres entre le navigateur Web de l'usager, Coova-Chilli, le serveur Web Apache et
Radius.
Dans un premier temps, l'utilisateur souhaite accder une URL (exemple : http://google.fr). Cette
requte est intercepte par le service Coova-Chilli qui vrifie si l'adresse IP de l'usager est autorise
accder l'Internet.
16 Network TUNnel : c'est un tunnel rseau qui opre sur la couche 3 (gre les paquets IP)
17 UAM : Universal Access Method, mthode d'accs universelle
HOUSSENBAY Olivier
22
Dans le cas o une authentification est ncessaire :
Coova-Chilli retourne une requte HTTP 18 de redirection de service au navigateur vers le

serveur Apache (https://@IP_ALCASAR/intercept.php). L'URL de redirection contient le
nom de domaine du serveur Web de ALCASAR. L'URI contient une demande de la
ressource "intercept.php" avec en argument un challenge arbitraire ainsi que l'URL
initialement demande par l'utilisateur .
Au travers d'une communication scurise en HTTPS19, le navigateur demande la page

"intercept.php". Cette page intgre un formulaire d'authentification, affiche l'utilisateur le
rsultat des tentatives d'authentification, gre la redirection vers Coova-Chilli, etc ...
L'utilisateur est invit saisir son identifiant et mot de passe. Ces informations sont
transmises, travers le tunnel TLS, au serveur Apache.
Ce dernier effectue des oprations cryptographiques sur le mot de passe puis renvoie le
nouveau contenu au client Web avec, nouveau une requte de redirection HTTP vers la
passerelle d'interception Coova-Chilli.
A la rception des donnes d'authentification, Coova-Chilli envoie une demande

d'authentification au serveur FreeRadius.
Une fois que la rponse de RADIUS parvient, la passerelle envoie une dernire requte de
redirection contenant le rsultat "authentif" vers le navigateur de l'utilisateur.
Enfin, les informations sont achemines Apache qui interprte la rponse de Coova-Chilli
et restitue le rsultat sous forme visuelle pour l'utilisateur.
18 HTTP : HyperText Transfer Protocol

19 HTTPS : HyperText Transfer Protocol Secure
HOUSSENBAY Olivier
23
Figure 10: Schma des changes interception et authentification
HOUSSENBAY Olivier
24
Aprs l'explication des messages changs lors de l'authentification d'un utilisateur sur le
contrleur d'accs au rseau, je vais parler des outils cryptographiques utiliss pour protger
lacheminement du mot de passe de l'utilisateur jusqu' la passerelle Coova-Chilli.
2. Scurisation du mot de passe

La transmission du mot de passe se dcompose en 10 tapes (cf. Figure 11) :
1. Lors de l'interception d'un utilisateur non autoris sur le rseau, la passerelle Coova-Chilli
gnre une chane alatoire que l'on appelle un "challenge" cryptographique. Ce "challenge"
est envoy au navigateur de l'utilisateur. Il interviendra dans la suite pour chiffrer le mot de
passe.
2. L'utilisateur saisit son identifiant et son mot de passe. Le navigateur envoie ces informations
au serveur Apache accompagn du "challenge" mis par Coova-Chilli travers un canal
scuris (SSL/TLS).
3. Le serveur Apache transmet les informations reues au script "intercept.php". Le script
complte le mot de passe par des "0" ("padding") pour obtenir une longueur de trente-deux
caractres.
4. En parallle, il convertit le "challenge" Cova-Chilli en base hexadcimale.
5. A l'installation d'ALCASAR, un secret partag a t mis en place entre Apache et CoovaChilli. Un nouveau challenge (newchal) est cr par concatnation entre le secret partag
(uamsecret) et le challenge "Coova-Chilli" (hexchal).
6. Puis, une empreinte du nouveau challenge est calcule en utilisant l'algorithme de hachage
MD5.
7. Une opration logique de type OU EXCLUSIF est ralise entre l'empreinte MD5 du
nouveau challenge et le mot de passe obtenu l'tape 3. Le masque appliqu au mot de
passe permet de garantir un bon niveau de scurit d'un point de vue cryptographique.
8. Le mot de passe chiffr est transmis au navigateur de l'utilisateur.
9. Le page "intercept.php" de l'usager transmet son tour le mot de passe prcdemment
chiffr par Apache la passerelle Coova-Chilli.
10. La passerelle applique le mme masque calcul par Apache sur le mot de passe reu pour
obtenir le mot de passe en clair. Enfin, elle ralise une requte d'authentification au serveur
Radius.
HOUSSENBAY Olivier
25
Figure 11: Schma de principe de l'acheminement du mot de passe utilisateur

Algorithme de chiffrement du mot de passe
La fonction utilise pour chiffrer le mot de passe utilisateur est un OU EXCLUSIF (cf.
Figure 12), souvent appel XOR (eXclusive OR). Elle prend en entre deux oprandes, le mot de
passe en clair de l'utilisateur et le challenge_Coova-Chilli. Le challenge est une cl symtrique
alatoire partage par les services Coova-chilli et Apache. Elle n'est utilise qu'une seule fois et sert
chiffrer et dchiffrer. On parle alors de masque jetable ou encore de "one-time pad".
Figure 12: Algorithme de chiffrement utilis pour la transmission du mot de passe

lors d'une authentification
HOUSSENBAY Olivier
26
Ct Apache :
challenge_Coova_Apache = md5 [ uamsecret | challenge_Coova ]
mot_de_passe_en_clair XOR challenge_Coova_Apache = mot_de_passe_chiffr
Ct Coova-Chilli :
challenge_Coova_Apache = md5 [ uamsecret | challenge_Coova ]
challenge_Coova_Apache XOR mot_de_passe_en_chiffr = mot_de_passe_en_clair
Cet algorithme parat simpliste et facile casser car il suffit d'avoir la connaissance du
challenge_Coova_Apache pour retrouver le mot de passe en clair.
Cependant, le challenge gnr par Coova est diffrent chaque nouvelle interception. Ce
qui implique que le mot de passe chiffr d'un mme utilisateur ne sera pas identique car le challenge
Coova_Apache sera diffrent.
De plus, l'empreinte MD5 de ce challenge qui sert de cl de chiffrement est difficilement
prdictible car elle ncessite la connaissance du secret commun entre Coova-Chilli et Apache. Une
personne mal intentionne souhaitant obtenir le mot de passe d'un utilisateur devra tenter de deviner
le secret commun afin de produire le masque adquat et dchiffrer le mot de passe.
La cl partage entre Coova-Chilli et Apache est compose de huit caractres
alphanumriques (lettres de lalphabet latin de A Z majuscules et minuscules, chiffres de 0 9).
Ci-dessous le code contenu dans le script d'installation (alcasar.sh) de ALCASAR qui gnre le
secret partag :
Figure 13: Script gnrant le secret partag entre Coova-Chilli et Apache

Par consquent, il y a soixante-deux caractres possibles pour chaque caractre composant le
secret partag. Cela offre 628 possibilits soit 218 x 1012 cls possibles et donc autant de mots de
passe tester.
Nous avons vu dans cette premire partie de l'authentification UAM les interactions de
ALCASAR avec l'utilisateur pour rcuprer les lments d'authentifications. Je vais maintenant
aborder la partie qui concerne le dialogue entre Coova-Chilli, FreeRadius et la base de donnes
MariaDB (cf cadre B de la figure 9).
Nous verrons comment la passerelle Coova-Chilli ralise une authentification Radius auprs
du service d'authentification FreeRadius. Je dtaillerai galement de quelle manire le serveur
identifie un utilisateur et ainsi de quelle faon il calcule ses autorisations. Nous verrons aussi par
quels procds les informations de traabilits sont stockes.
HOUSSENBAY Olivier
27
3. Demande d'authentification :
La Figure 14 dcrit les changes Radius de manire gnrale entre un client Radius et un
serveur Radius. Le client Radius peut tre reprsent par Coova-Chilli.
Figure 14: changes Radius lors d'une demande d'authentification

On retrouve ci-dessous les messages rseau changs entre Coova-Chilli et FreeRadius (cf.
Figure 15). On remarque que la trame n1 est une demande d'authentification qui fait transiter le
nom d'utilisateur et le mot de passe chiffr l'aide d'un challenge et d'un secret partag entre les 2
parties.
Ces messages ont t capturs sur la boucle locale (l0) de Alcasar. L'analyseur de trames
rseau Wireshark a t utilis pour visualiser les changes.
La trame n2 indique que l'utilisateur est autoris accder au rseau.
La trame n3 est une requte de comptabilit (voir dtails Figure 16) qui contient les
donnes de dpart de la session de l'utilisateur.
La trame n4 dcrit la confirmation de l'enregistrement des donnes de session par le serveur
d'authentification.
HOUSSENBAY Olivier
28
Figure 15: Demande d'authentification Radius par Coova-Chilli
Figure 16: Demande d'enregistrement de donnes de comptabilit par Coova-Chilli

HOUSSENBAY Olivier
29
4. La base de donnes : MariaDB

Nous pouvons voir sur la figure ci-dessous la reprsentation des diffrentes tables de Radius.
Les principales tables utilises lors de l'authentification sont "radcheck", "radreply" et "radacct".
Nous verrons donc en dtail leurs spcificits.
Figure 17: Tables Radius

La table "radcheck" dcrite ci-dessous montre comment les identifiants de session sont
stocks.
La colonne "username" indique le nom d'utilisateur stock dans la base, "attribute" spcifie
un attribut de contrle tandis que "value" correspondant la valeur de l'attribut : dans l'exemple
situ Figure 18, nous avons l'attribut de contrle "Crypt-Password" qui correspond l'empreinte du
mot de passe de l'utilisateur. Le mot de passe est hash en utilisant l'algorithme MD5(salted).
Dans les versions futures d'Alcasar (V2.9 et suivantes), l'algorithme a t remplac par le
SHA-256 pour des raisons de scurit. De plus, un salage dynamique (salted) a t ajout afin qu'un
mme mot de passe pour deux utilisateurs diffrents ne puisse pas produire la mme empreinte.
L'intrt de conserver les mots de passe des utilisateurs sous forme d'empreinte permet qu'en cas de
compromission de la base, un attaquant ne puisse pas exploiter directement le mot de passe. Cette
table peut galement contenir des attributs de contrle. Par exemple : un temps de session maximal
journalier ou bien une limitation sur la bande passante alloue.
Figure 18: Table des attributs de contrle Radius

HOUSSENBAY Olivier
30
La table "radreply" contient des attributs de rponse qui ont t pralablement renseigns
dans le profil des utilisateurs. Ici, l'attribut "Filter-Id" est retourn la passerelle Coova-Chilli
lorsque l'authentification est russie. Un script sur la passerelle permet de rcuprer la valeur de
"Filter-Id" et transmet cette information aux composantes de filtrage de Alcasar. Cette table peut
aussi contenir un temps de session maximal autoris l'utilisateur.
Figure 19:
Table des
attributs de
rponse Radius
La table "radacct" regroupe les donnes de comptabilit des utilisateurs. On y retrouve par
exemple ladresse IP de l'utilisateur, l'heure de dbut et de fin de chacune de ces sessions sur le
portail captif, les donnes consommes en envoi et en rception, ...
Figure 20: Table des donnes de journalisation Radius
HOUSSENBAY Olivier
31
B ) FreeRadius
Durant mon stage, j'ai t amen optimiser les fichiers de configuration du serveur
FreeRadius dans Alcasar. Cela a t possible en ayant pris connaissance en amont des mcanismes
d'authentification. Dans un premier temps, je devais identifier les fichiers utiles FreeRadius dans
le cadre du projet Alcasar. Puis, dans un second temps, vrifier si les fichiers taient correctement
configurs. Enfin, il fallait que j'apporte corrections et amliorations afin d'optimiser le
fonctionnement. Voir lgende P. 34
Sur la figure 21, on retrouve une cartographie gnrale des fichiers FreeRadius.
Figure 21: Cartographie des fichiers de FreeRadius
HOUSSENBAY Olivier
32
Le schma reprsent ci-dessous montre les modules activs dans les diffrentes sections du
fichier de configuration principal.
instantiate{} : Section permettant de dfinir un chanage des diffrents modules fournis par
FreeRadius. Ceux-ci sont prchargs au moment o le serveur dmarre. Dans le cas d'une procdure
d'authentification, les modules ne pourront s'excuter qu'uniquement dans l'ordre dans lequel ils ont
t initialiss.
modules {} : Section qui permet de dfinir les chemins des fichiers de configuration de chaque
module. Les versions d'ALCASAR partir de la 2.9 sont en mesure d'appeler seulement les
modules requis pour les besoins du projet. En effet, les modifications que j'ai apportes ont permis
de limiter au ncessaire le nombre de fonctionnalits lors du lancement du serveur FreeRadius.
Les modules permettent d'excuter les tches suivantes :
Effectuer des requtes avec la base de donnes MariaDB ("sql")
Interroger un annuaire ("ldap")
Calculer les temps de connexion l'aide de compteurs sql ("logintime, dailycounter" et
"monthlycounter").
Dfinir une date d'expiration des comptes utilisateurs ("expiration")
Contrler un mot de passe ("pap")
Figure 22: Reprsentation du fichier de configuration principal de FreeRadius
HOUSSENBAY Olivier
33
Le schma suivant dfinit la politique adopte pour le modle AAA. On retrouve les modules
ncessaires pour les sections d'authentification (authentication {}), d'autorisation (authorize {}) et
de comptabilit (accounting {}).
Figure 23: Reprsentation des sections de configuration du serveur virtuel ALCASAR au sein de
FreeRadius
Lgende
Drapeau vert : Fichiers utiles la configuration de FreeRadius pour Alcasar
Drapeau bleu : Fichiers / modules ncessaires pour l'authentification 802.1X.
Drapeau orange : Ajout de fichiers / modules
Drapeau rouge : Suppression de fichier / modules
HOUSSENBAY Olivier
34
C ) Authentification 802.1X
Le protocole 802.1X engendre une communication indirecte entre le poste de travail usager et le
serveur Radius.
Ainsi, le processus d'authentification se fait dans un premier temps entre l'agent 802.1X appel
supplicant et le NAS qui est un quipement rseau (authentificateur) grce EAP 20. Ce dernier
relaye les messages EAP encapsuls dans des paquets Radius au service d'authentification. Le
protocole Radius possde un attribut EAP-message qui permet d'acheminer les messages entre
l'agent 802.1X et le client Radius.
Sur le schma ci-dessous, on observe les diffrentes couches logicielles qui doivent tre
implmentes pour dployer le protocole 802.1X. En effet, l'utilisateur doit possder sur son poste
de travail un agent qui puisse dialoguer avec un quipement rseau en utilisant le protocole EAP.
L'quipement rseau, quant lui, doit prendre en charge le protocole EAP et le protocole Radius
pour changer avec le serveur d'authentification. Enfin, le service d'authentification doit avoir un
module EAP lui permettant de rcuprer les messages EAP issus de l'agent 802.1X.
Figure 24: Implmentation des couches EAP par les diffrents acteurs entrant en jeu dans le
protocole 802.1X
20 EAP : Extensible Authentication Protocol
HOUSSENBAY Olivier
35
On retrouve sur la figure 25, une vue gnrale du modle de fonctionnement du protocole
802.1X.
La premire tape consiste tablir un dialogue entre le systme souhaitant s'authentifier et le

serveur d'authentification.
Ce dialogue est obligatoirement ralis au moyen du protocole EAP. Puis, si le systme

authentifier rpond aux critres requis, le serveur d'authentification envoie un message au client
Radius afin d'autoriser celui-ci. Le systme autoris peut alors accder au rseau.
Figure 25: Schma de principe de l'accs au rseau bas sur le contrle de port
HOUSSENBAY Olivier
36
Figure 26: tat du port du client Radius avant

l'authentification 802.1X
Figure 27: tat du port du client Radius aprs l'authentification

802.1X
Dans les figures 26 et 27 le bloc PAE : Port Access Entity est le composant logique du modle
802.1X. C'est lui qui permet les changes de message EAP entre l'authentificateur et le supplicant.
Les couches EAP intgrent plusieurs mthodes d'authentification. Par consquent, plusieurs
mcanismes d'identification peuvent tre mis en place. Le tableau ci-dessous fait une comparaison
de quatre mthodes d'authentification.
HOUSSENBAY Olivier
37
Mthode
d'authentification
EAP-MD521
EAP-TLS22
EAP-PEAP23
EAP-TTLS24
Mode
d'authentification
Unidirectionnel : Mutuel :
authentification du certificats
client
(client/serveur)
Protocole
d'authentification
de mot de passe
Fonction de
hachage MD5
mot de passe sous
forme d'empreinte
numrique
Non
Tunnel TLS
Non
Oui mais non

utilis
Oui
Oui
PKI29 Client
Non
Oui
Oui (optionnelle)
Oui (optionnelle)
PKI Serveur
Non
Oui
Oui
Oui
Compatibilit avec
des protocoles non
EAP
Non
Non
Non
Oui
Trs bon
Bon
Trs bon,
peut tre utilis
avec des serveurs
d'authentification
qui ne prennent
pas en charge EAP
Oui
Oui
Oui
Faible, vulnrable
au MITM et la
fonction de
Niveau de scurit hachage est
vulnrable aux
attaques par
dictionnaire
Distribution
dynamique de clef
de chiffrement
pour les
communication
sans fil
21
22
23
24
25
26
27
28
29
Non
Mutuel : login/mot Mutuel : login/mot

de passe (client) et de passe (client) et
certificat (serveur) certificat (serveur)
25
EAP-GTC
EAPMSCHAPv226
PAP27
CHAP28
MS-CHAP
EAP-MD5
EAP-MSCHAPv2
MD5 : Message Digest 5

TLS:Transport Layer Security
PEAP : Protected Extensible Authentication Protocol
TTLS : Tunneled Transport Layer Security
GTC : Generic Token Card
MS-CHAP : Microsoft Challenge Handshake Authentication Protocol
PAP : Password Authentication Protocol
CHAP : Challenge Handshake Authentication Protocol
PKI : Public Key Infrastructure
HOUSSENBAY Olivier
38
L'utilit du protocole EAP est de transporter la mthode d'authentification et le protocole

d'authentification.
La mthode d'authentification choisie pour le protocole 802.1X au sein d'ALCASAR est
l'EAP-TLS. Cette mthode offre une authentification forte car elle repose sur deux critres
d'authentification : ce que l'utilisateur connat (mot de passe / code PIN) et ce que l'utilisateur
possde (certificat lectronique embarqu dans une carte puce / authentificateur USB).
Au sein du projet, je devais utiliser la solution Coova-Chilli dans le mcanisme
d'authentification. Il a donc fallu paramtrer celui-ci en proxy Radius afin qu'il puisse relayer les
messages des quipements rseaux vers le serveur Radius. Cela a permis de conserver la fonction de
journalisation des utilisateurs connects sur le rseau de consultation Alcasar.
Figure 28: Implmentation de 802.1X dans ALCASAR
D ) Problmes rencontrs : Authentification 802.1X

Durant mon stage, j'ai t confront un problme de corruption des paquets. Lors de
l'authentification d'un usager, en utilisant la mthode EAP-TLS, le dialogue entre l'agent 802.1X et
le client Radius s'interrompait lorsque l'agent envoyait le certificat client.
On remarque sur la figure ci-dessous que la taille attendue dans l'en-tte 802.1X (1408
octets) ne correspond pas la taille relle donne par la mthode EAP-TLS (2450 octets). Dans la
reprsentation hexadcimale, on peut galement identifier un fragment du certificat utilisateur.
HOUSSENBAY Olivier
39
Figure 29: Dialogue entre supplicant et Coova-Chilli interrompu lors de l'utilisation de la mthode
EAP-TLS.
La figure ci-dessous reprsente les retours ICMP par Coova-Chilli lors de l'authentification
EAP-TLS. Grce ces messages, j'ai pu identifier le problme qui portait sur la taille des paquets
envoys par l'agent 802.1X du poste utilisateur. Le protocole EAP opre sur la couche liaison du
modle OSI et est encapsul par le protocole Ethernet.
Ce protocole ne peut grer la fragmentation des paquets. En effet, seuls les protocoles de
plus haut niveau comme TCP sont en mesure de raliser cette opration grce au contrle de la taille
des paquets en fonction de la MTU30 dfinie.
Figure 30: Messages ICMP retourns par Coova-Chilli
30 MTU : Maximum Transmission Unit
HOUSSENBAY Olivier
40
Ci-dessous, on observe une authentification EAP-TLS complte aprs rsolution du

problme. Cette rsolution a eu lieu par l'ajout d'un attribut de configuration au sein de l'agent
802.1X dfinissant la possibilit de fragmentation des paquets.
Figure 31: Ct supplicant mthode EAP-TLS avec coova en proxy Radius succs
E ) Problmes rencontrs : Point d'accs Wi-Fi

J'ai galement rencontr des difficults lorsque j'ai mis en uvre des authentifications
Radius sans fil dans le cadre de l'criture des travaux dirigs Radius (cf. Annexe 1 P. 91 et P. 92).
J'ai t amen utiliser un point d'accs Netgear WNR 3400v3 ainsi qu'un point d'accs AlcatelLucent 105.
Le firmware initial du constructeur Netgear ne fournissait pas les couches logicielles
ncessaires pour raliser une authentification via Radius. En effet, j'ai d remplacer le firmware
propritaire par un firmware libre (dd-wrt) compatible avec le modle.
La mise jour du firmware a permis d'tendre les fonctionnalits du point d'accs et ainsi
permettre une authentification forte via le protocole Radius.
Malheureusement, le point d'accs en tant que client Radius ne rpondait qu' un seul des 3
critres AAA, soit l'authentification. Le routeur a montr ses limites quant la comptabilit et
l'autorisation o il n'a pu remplir sa tche.
Par consquent, j'ai d utiliser un autre quipement, l'Alcatel-Lucent 105 o j'ai rencontr
une impasse. Ce dernier est un point d'accs bien plus volu que le Netgear car il prend nativement
les fonctionnalits du protocole Radius. On y retrouve 2 critres sur 3 soit l'authentification et la
HOUSSENBAY Olivier
41
comptabilit. Concernant le dernier critre qui est l'autorisation, je me suis aperu que le modle ne
pouvait raliser cette opration que par l'utilisation d'un logiciel tiers appartenant la firme AlcatelLucent. Ce logiciel tant trs coteux, je n'ai pas pu l'acqurir. J'ai donc fait des recherches
infructueuses sur un ventuel firmware libre, ce qui m'a men contacter le constructeur l'origine
du produit Alcatel-Lucent 105. En effet, Alcatel-Lucent n'est pas l'OEM (Original Equipment
Manufacturer traduit littralement par Fabriquant dquipement d'Origine) mais un revendeur
officiel pour ce type de produit.
L'objet de ma requte l'intention d'Aruba tait d'obtenir de leur part le firmware
correspondant ce modle (prenant en charge le triple A) ce quoi ils m'ont rpondu qu'ils n'taient
pas en mesure de le fournir car le numro de srie tait enregistr sous la marque Alcatel-Lucent.
En rsum, du Netgear ou de l'Alcatel-Lucent, les tests n'ont pu tre raliss entirement
avec la technologie sans fil.
Figure 33: Netgear WNR 3400v3
HOUSSENBAY Olivier
Figure 32: Alcatel-Lucent 105
42
F ) Amliorations & Perspectives
L'implmentation du protocole 802.1X tant ralise, une ouverture possible serait de

configurer la passerelle d'interception afin qu'elle puisse grer deux rseaux utilisant des
mthodes d'authentification diffrentes. Ci-dessous, un schma de principe de cette possible
ralisation future.
Figure 34: Gestion de deux rseaux virtuels par CoovaChilli intgrant l'authentification UAM et 802.1X
Une autre amlioration envisageable consisterait exploiter la fonctionnalit COA propos

par FreeRadius afin de modifier les autorisations d'un utilisateur ou de couper la connexion
un usager connect de manire autonome sur un quipement compatible 802.1X.
Mettre en uvre l'implmentation d'un agent 802.1X pour qu'il puisse interagir de manire
intuitive avec les utilisateurs sur des machines en libre accs.
HOUSSENBAY Olivier
43
Conclusion
Les diffrentes tches que j'ai effectues au sein du laboratoire de Laval m'ont permis de
m'enrichir sur les aspects techniques o j'ai pu aborder de nombreux sujets sur les rseaux et la
scurisation de ceux-ci.
Les diffrentes interactions que j'ai eues avec mon matre de stage et les autres membres du
laboratoire m'ont galement enseign de nombreux aspects notamment sur le comportement
adopter en entreprise, la collaboration et l'esprit d'quipe.
L'ambiance au sein du stage tait de rigueur puisque j'tais dans un cadre agrable avec une
vritable entraide entre les membres du CVO.
Sur le plan technique, j'ai explor de manire dtaille de nombreuses facettes du monde des
rseaux informatiques mais aussi du systme Linux. Je retiens de nombreuses notions au sein de ce
stage et, en particulier :
La prise en main de la distribution Mageia

Les caractristiques d'un portail captif
L'authentification
La gestion d'une base d'usagers
Le fonctionnement des quipements rseau (commutateurs, bornes WIFI)
Les attaques sur les rseaux informatiques
Pour rsumer, je qualifierai ce stage d'une relle opportunit et je suis trs reconnaissant de
toute l'quipe du CVO et notamment mon matre de stage M. Richard REY ainsi que mon tuteur
pdagogique M. Nicolas DEVILLY qui m'ont apport le savoir ncessaire pour mener bien
l'ensemble du projet.
tant prsent au Mastre SI&S (Scurit de lInformation et des Systmes) de l'ESIEA, j'ai
pour ambition de poursuivre dans le domaine de la scurit informatique dont le facteur de dpart a
t ce stage.
HOUSSENBAY Olivier
44
Bibliographie et Webographie
Radius
Serge Bordres, Authentification rseau avec Radius, dition Eyrolles
http://en.wikipedia.org/wiki/RADIUS
http://en.wikipedia.org/wiki/IEEE_802.1X
Authentification
http://fr.wikipedia.org/wiki/Authentification
http://www.nolot.eu/Download/Cours/reseaux/m2pro/SESY0708/proto-authentification.pdf
http://repo.hackerzvoice.net/depot_madchat/sysadm/unix.seku/Authentification_de_A_a_Z.pdf
http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol
CNS
http://www.esiea.fr/recherche/expertise-confiance-numerique-securite
Projet Alcasar
http://www.alcasar.net/
Projet Davfi
https://www.davfi.fr/
Projet Uhuru
http://uhuru-am.com
FreeRadius
http://freeradius.org/
http://en.wikipedia.org/wiki/FreeRADIUS
http://www.tldp.org/HOWTO/8021X-HOWTO/freeradius.html
http://deployingradius.com/
Diameter
http://en.wikipedia.org/wiki/Diameter_%28protocol%29
HOUSSENBAY Olivier
45
Table des figures

Figure 1: Avantages et inconvnients de l'implmentation des certificats X.509 (source
http://repo.hackerzvoice.net)..............................................................................................................11
Figure 2 : Principe des changes du protocole RADIUS...................................................................13
Figure 3 : Le protocole RADIUS au sein du modle OSI..................................................................14
Figure 4 : Encapsulation du protocole RADIUS................................................................................14
Figure 5 : Format des trames RADIUS..............................................................................................15
Figure 6 : Champ attributs et valeurs du protocole RADIUS......................................................16
Figure 7 : Format des attributs VSA...................................................................................................18
Figure 8: Les changes au sein du protocole RADIUS......................................................................19
Figure 9: Schma de principe ALCASAR..........................................................................................21
Figure 10: Schma des changes interception et authentification......................................................24
Figure 11: Schma de principe de l'acheminement du mot de passe utilisateur.................................26
Figure 12: Algorithme de chiffrement utilis pour la transmission du mot de passe lors d'une
authentification...................................................................................................................................26
Figure 13: Script gnrant le secret partag entre Coova-Chilli et Apache........................................27
Figure 14: changes Radius lors d'une demande d'authentification..................................................28
Figure 15: Demande d'authentification Radius par Coova-Chilli......................................................29
Figure 16: Demande d'enregistrement de donnes de comptabilit par Coova-Chilli.......................29
Figure 17: Tables Radius....................................................................................................................30
Figure 18: Table des attributs de contrle Radius..............................................................................30
Figure 19: Table des attributs de rponse Radius...............................................................................31
Figure 20: Table des donnes de journalisation Radius......................................................................31
Figure 21: Cartographie des fichiers de FreeRadius..........................................................................32
Figure 22: Reprsentation du fichier de configuration principal de FreeRadius................................33
Figure 23: Reprsentation des sections de configuration du serveur virtuel ALCASAR au sein de
FreeRadius..........................................................................................................................................34
Figure 24: Implmentation des couches EAP par les diffrents acteurs entrant en jeu dans le
protocole 802.1X................................................................................................................................35
Figure 25: Schma de principe de l'accs au rseau bas sur le contrle de port...............................36
Figure 26: tat du port du client Radius avant l'authentification 802.1X..........................................37
Figure 27: tat du port du client Radius aprs l'authentification 802.1X..........................................37
Figure 28: Implmentation de 802.1X dans ALCASAR....................................................................39
Figure 29: Dialogue entre supplicant et Coova-Chilli interrompu lors de l'utilisation de la mthode
EAP-TLS............................................................................................................................................40
Figure 30: Messages ICMP retourns par Coova-Chilli.....................................................................40
Figure 31: Ct supplicant mthode EAP-TLS avec coova en proxy Radius succs........................41
Figure 32: Alcatel-Lucent 105............................................................................................................42
Figure 33: Netgear WNR 3400v3.......................................................................................................42
Figure 34: Gestion de deux rseaux virtuels par Coova-Chilli intgrant l'authentification UAM et
802.1X................................................................................................................................................43
HOUSSENBAY Olivier
46

Rapport - Olivier Houssenbay - 802.1x

Transféré par

Informations du document

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

Rapport - Olivier Houssenbay - 802.1x

Transféré par

Droits d'auteur :

Formats disponibles

MMOIRE DE FIN D'TUDES

Entreprise d'accueil : Laboratoire de cryptologie et virologie oprationnelle (C+V)O

FreeRadius, un serveur d'authentification forte pour

M. Vincent GUYOT, Prsident du jury, Enseignant chercheur l'ESIEA, Docteur en Informatique

Table des matires

Mmoire de fin d'tudes

1 Cryptologie et Virologie Oprationelles

Mmoire de fin d'tudes

Mmoire de fin d'tudes

Mmoire de fin d'tudes

Le projet Alcasar gr par M. Richard REY et dvelopp par lui-mme et

Mmoire de fin d'tudes

Mmoire de fin d'tudes

Mmoire de fin d'tudes

Mmoire de fin d'tudes

Access-Challenge : Le serveur envoie ce paquet afin de demander une rmission du

Mmoire de fin d'tudes

F ) Les certificats X.509

Figure 1: Avantages et inconvnients de l'implmentation des certificats X.509

Mmoire de fin d'tudes

Authentication (Authentification) : c'est la fonction principale de scurit qui consiste

Authorization (Autorisation) : c'est la capacit accder, une fois l'authentification

Dfinition de protocole en communication

Mmoire de fin d'tudes

1. Qui peut tre un client RADIUS ?

Commutateurs, fournit galement l'accs au rseau local ;

Figure 2 : Principe des changes du protocole RADIUS

VPN : Virtual Private Network

Mmoire de fin d'tudes

2. Le protocole RADIUS dans le modle OSI 10

Figure 3 : Le protocole RADIUS au sein du modle OSI

Figure 4 : Encapsulation du protocole RADIUS

OSI : Open Systems Interconnection

Mmoire de fin d'tudes

3. Format des paquets RADIUS

Figure 5 : Format des trames RADIUS

Mmoire de fin d'tudes

4. Les attributs RADIUS

Figure 6 : Champ attributs et valeurs du protocole RADIUS

Mmoire de fin d'tudes

Mmoire de fin d'tudes

5. Les attributs constructeurs

Figure 7 : Format des attributs VSA

Mmoire de fin d'tudes

6. Les types de paquets RADIUS

Figure 8: Les changes au sein du protocole RADIUS

Mmoire de fin d'tudes

Partie 2 : Radius dans Alcasar

Mmoire de fin d'tudes

Figure 9: Schma de principe ALCASAR

Mmoire de fin d'tude

Mmoire de fin d'tudes

Dans le cas o une authentification est ncessaire :

Coova-Chilli retourne une requte HTTP 18 de redirection de service au navigateur vers le

Au travers d'une communication scurise en HTTPS19, le navigateur demande la page

A la rception des donnes d'authentification, Coova-Chilli envoie une demande

18 HTTP : HyperText Transfer Protocol

Mmoire de fin d'tudes

Figure 10: Schma des changes interception et authentification

Mmoire de fin d'tudes

2. Scurisation du mot de passe

Mmoire de fin d'tudes

Figure 11: Schma de principe de l'acheminement du mot de passe utilisateur

Figure 12: Algorithme de chiffrement utilis pour la transmission du mot de passe