Universit Claude Bernard Lyon 1 Master Systmes Informatique et Rseaux 2006/2007

Travail dEtude et de Recherche

Services d'authentification et annuaires

Thibaut DE DOMPSURE, Vincent SAGE 12 dcembre 2006

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

Table des Matires

1- Introduction ........................................................................................................................ 3 2- Protocoles d'authentifications. .......................................................................................... 4 2.1- PAP ............................................................................................................................. 4 2.2- CHAP ......................................................................................................................... 4 2.3- MS-CHAP ................................................................................................................... 5
2.3.1-Version 1 ............................................................................................................................ 5 2.3.2-Version 2 ............................................................................................................................ 5

2.4- EAP ............................................................................................................................ 6

2.4.1-EAP-MD5 .......................................................................................................................... 7 2.4.2-EAP-TLS............................................................................................................................ 7 2.4.3-EAP-TTLS / PEAP ........................................................................................................... 7 2.4.4-LEAP ................................................................................................................................. 7

2.5- 802.1X ......................................................................................................................... 7 3- Services dauthentification de la couche rseau ............................................................... 8 3.1- IPsec ........................................................................................................................... 8
3.1.1-Protocole AH ..................................................................................................................... 9 3.1.2-Protocole ESP .................................................................................................................. 10

3.2- NuFW ....................................................................................................................... 11 4- Services dauthentification de la couche session ............................................................ 13 4.1- SSL/TLS ................................................................................................................... 13 5- Services dauthentification applicatifs ............................................................................. 14 5.1- RADIUS ................................................................................................................... 14 5.2- TACACS+ ................................................................................................................ 16 5.3- Kerberos ................................................................................................................... 17 5.4- Authentification web ................................................................................................. 19
5.4.1-PHP/ASP ......................................................................................................................... 19 5.4.2-.htaccess............................................................................................................................ 19

6- Annuaires ........................................................................................................................... 20 6.1- Active Directory ........................................................................................................ 20 6.2- LDAP........................................................................................................................ 20 6.3- NIS/NIS+ ................................................................................................................ 21 7- Les volutions venir ....................................................................................................... 22 7.1- Diameter ................................................................................................................... 22 7.2- Liberty Alliance ......................................................................................................... 22 7.3- La biomtrie .............................................................................................................. 23 8- Conclusion ......................................................................................................................... 24 9- Bibliographie ..................................................................................................................... 25 9.1- Documentations crites ............................................................................................. 25 9.2- Documentations en lignes ......................................................................................... 25

Rapport de TER de Thibaut de Dompsure et Vincent Sage

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

1-

Introduction

Scuriser le systme dinformation est de plus en plus difficile, surtout lheure o le nombre dapplications et le degr douverture vers lextrieur vont croissant. Dfinir les personnes autorises accder au systme dinformation constitue lune des bases de la scurit. Cette authentification des utilisateurs quelle soit interne ou externe au cercle de confiance est indispensable. Lauthentification englobe souvent des concepts et des approches diffrentes. Il y a plusieurs moyens dauthentification. Ils sont gnralement regroups en trois grandes catgories : - Il y a ce que l'on connat : un mot de passe, un code PIN ... - Il y a ce que lon a : une carte puce, un certificat ... - Il y a ce que lon est : la biomtrie. Lauthentification par mot de passe est utilise en grande majorit dans les systmes scuriss, car cest la plus simple mettre en place. Nous verrons nanmoins les autres possibilits dauthentifications et les avantages. Sachant que les services dfinissent lensemble des oprations accessibles par des protocoles, les services dauthentifications regroupent donc lensemble des oprations pour sauthentifier, quel que soit le protocole et quelle que soit la couches ISO. Les services dauthentification ont tous besoins dune base de connaissance afin dy stocker toutes sortes dinformations. Ces informations peuvent tre trs varies et peuvent tablir un vritable profil en fonction de lentit qui sauthentifie. Cette base de connaissance est appele annuaire . Lannuaire est donc aussi un service permettant de maintenir de faon cohrente, contrl, organis, une grande quantit de donne relative des personnes, des machines ou des ressources. Notre tude bibliographique porte sur les services dauthentifications et les annuaires.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

2-

Protocoles d'authentifications.

Les mcanismes dauthentification dcrits dans cette partie ont tout dabord t des protocoles de couche 2 (liaison de donnes) puisquils ont t initialement utiliss par le protocole PPP (Point-to-Point Protocol) qui permet louverture de session sur le rseau RTC. Actuellement, ils sont galement utiliss dans la couche rseau grce aux volutions de PPP : PPPoA (over ATM) et PPPoE (over Ethernet) qui sont principalement utiliss pour ouvrir des connexions ADSL. Cependant, ces mcanismes sont les briques de nombreux serveurs et applications dauthentification comme Radius.

2.1-

PAP

Le protocole PAP (Password Authentication Protocol), utilis avec le protocole PPP, permet didentifier un utilisateur auprs dun serveur PPP en vue dune ouverture de connexion sur le rseau. Aprs une phase de synchronisation entre le client et le serveur pour dfinir lutilisation du protocole PPP et PAP, le processus dauthentification se fait en deux tapes : - Le client envoie son nom PAP ainsi que son mot de passe en clair. - Le serveur qui dtient une table de noms d'utilisateurs et de mots de passe vrifie que le mot de passe correspond bien lutilisateur et valide ou rejette la connexion.

Fig. 1 : Illustration des 2 tapes d'authentification du protocole PAP PAP est le plus simple des protocoles dauthentification, il est donc trs facile implmenter. Mais tant donn que le mot de passe circule en clair sur le rseau, cest aussi le moins scuriser et il est donc fortement dconseill car il ne procure aucune scurit. Dautre part, mme si le mot de passe est crypt, il est toujours possible dutiliser un sniffer afin de capturer la requte dauthentification et de la rutiliser pour sauthentifier (attaque par rejeu).

2.2-

CHAP

Contrairement au protocole PAP, le protocole CHAP (Challenge Handshake Authentication Protocol) permet une authentification scurise par hachage MD5 (Message Digest 5). MD5 est une fonction de hachage cryptographique permettant dobtenir lempreinte numrique dun message partir de laquelle il est impossible de retrouver le message original. Ainsi, en envoyant lempreinte du mot de passe au serveur, le client peut montrer quil connat bien le mot de passe sans avoir rellement lenvoyer sur le rseau. Aprs le mme type de synchronisation que pour le protocole PAP, le mcanisme dauthentification est bas sur un dfi (challenge) en 3 tapes : Rapport de TER de Thibaut de Dompsure et Vincent Sage 4

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

- Le serveur envoie au client un nombre alatoire de 16bits ainsi quun compteur incrment chaque envoie. - Le client gnre une empreinte MD5 de lensemble constitu par : son mot de passe, le nombre alatoire et le compteur reu puis il envoie cette empreinte. - Le serveur calcul galement de son cot lempreinte MD5 grce au mot de passe du client stock localement puis il compare son rsultat lempreinte envoye par le client. Si les deux empreintes sont identiques, le client est bien identifi et la connexion peut seffectuer sinon, elle est rejete.

Fig. 2 : Illustration des 3 tapes d'authentification du protocole CHAP Ce mcanisme dauthentification procure CHAP deux avantages : tout dabord, si la requte dauthentification envoye par le client est intercepte, elle ne pourra pas tre rejoue, en effet chaque empreinte calcule par le client est unique puisquelle fait intervenir le compteur qui est incrment chaque envoi par le serveur. Dautre part, lors dune session tablie par le protocole CHAP, le serveur envoie rgulirement des challenges au client de faon vrifier son identit, cette mesure de protection supplmentaire permet donc de se prmunir des vols de session.

2.32.3.1-

MS-CHAP
Version 1

MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) est la version spcifique de CHAP mise au point par Microsoft. Plus quune simple version prioritaire, MS-CHAP apporte galement quelques amliorations CHAP. Un des principaux inconvnients de CHAP est que le serveur doit dtenir les mots de passe des utilisateurs en clair pour pouvoir vrifier lempreinte MD5 envoye par les clients, ce qui constitue une vulnrabilit potentielle en cas de compromission du serveur. Pour remdier cette faiblesse, le protocole MS-CHAP intgre une fonction de hachage propritaire permettant de stocker sur le serveur un hash intermdiaire du mot de passe. Ainsi, en travaillant uniquement avec ce hash intermdiaire la place du mot de passe, le client et le serveur peuvent raliser le mme type de procdure que dans la figure 2, ainsi, le mot de passe en clair na plus besoin dtre stock sur le serveur. 2.3.2- Version 2 Malgr lavance de MS-CHAP par rapport CHAP, Microsoft cra une seconde version du protocole (MS-CHAP-v2) pour rsoudre deux principales faiblesses de MS-CHAP-v1, dune part le fait que le client ne puisse pas vrifier lauthenticit du serveur sur lequel il veut se connecter et dautre part que lalgorithme de hachage propritaire utilis soit trs vulnrable des attaques par brute-force. Voici le fonctionnement du processus dauthentification mutuelle fournit par MS-CHAP-v2 : - Le serveur daccs distant envoie une demande de vrification au client contenant un identificateur de session I et une chaine C1 gnre alatoirement. - Le client envoie alors une rponse contenant : son nom dutilisateur, une chaine alatoire C2 et un hash de lensemble form par 3 lments : la chaine C1, lidentificateur de session I et son mot de passe. Rapport de TER de Thibaut de Dompsure et Vincent Sage 5

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

- Le serveur vrifie la rponse du client et il renvoie une rponse contenant : une chaine indiquant le succs ou lchec de lauthentification, et un hash de lensemble form par 3 lments : la chaine C2, lidentificateur de session I et son mot de passe. - Le client vrifie son tour la rponse dauthentification et tablit la connexion en cas de russite.

Fig. 3 : Illustration des 4 tapes d'authentification du protocole MS-CHAP-v2 Cette mthode dauthentification est bien mutuelle car elle permet effectivement au client dtre sr de lidentit du serveur car seul le serveur peut lui renvoyer son mot de passe dans le hash ltape 3. Du fait de cette amlioration notable et des faiblesses de MS-CHAP-v1, seule la seconde version de MS-CHAP est supporte par le dernier systme dexploitation de Microsoft : Windows Vista.

2.4-

EAP

EAP (Extensible Authentification Protocol) nest pas directement un mcanisme dauthentification comme peuvent ltre PAP ou CHAP, il sagit en ralit dune extension du protocole PPP qui a permis duniversaliser et de simplifier lutilisation des diffrents protocoles dans le cadre des rseaux sans fils et les liaisons Point-A-Point. EAP contient une douzaine de mthodes dauthentification, les plus utilises tant EAP-MD5, EAP-TLS, EAP-TTLS, LEAP ou encore EAP-AKA pour lUMTS. Il faut distinguer des types de trafic EAP : celui entre le client et le point daccs : EAP over LAN (utilisant un mdia 802.11a, b ou g) et celui entre le point daccs et le serveur dauthentification : EAP over Radius.

Fig. 4 : Diffrents types de trafic EAP

Rapport de TER de Thibaut de Dompsure et Vincent Sage

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

2.4.1-

EAP-MD5

EAP-MD5 est une des mthodes dauthentification les plus simples dEAP, il est trs simple mettre en place et son mcanisme dauthentification est semblable la mthode CHAP (fig. 2). Cependant, cette mthode ne permet pas la distribution de cls WEP, il est donc inutilisable pour les rseaux sans fils. De plus, cette mthode ne permet donc pas dauthentification mutuelle et tout comme CHAP, elle est vulnrable aux attaques par force-brute ou au vol de session. 2.4.2EAP-TLS

EAP-TLS est bas sur le protocole TLS que nous allons dvelopper un peu plus loin. Ce protocole utilise deux certificats permettant une authentification mutuelle afin de crer un canal scuris. De cette faon, mme si le mot de passe client est dcouvert, il ne sera daucune utilit sans le certificat client. EAP-TLS offre donc un trs bon niveau de scurit et est un standard ouvert IETF, pour ces raisons, il est implant dans de trs nombreux matriels sans fils. Le principal reproche que lon peut faire ce protocole est, qutant donn lobligation dutiliser un certificat diffrent pour chaque client, il peut savrer compliqu et coteux mettre en place dans un grand parc de machines. 2.4.3- EAP-TTLS / PEAP Assez similaire avec EAP-TLS, cette mthode propose galement une authentification mutuelle la diffrence que le client na pas besoin de dtenir un certificat. En effet, dans un premier temps le client identifie bien le serveur en utilisant un certificat (valid par une autorit de certification), mais ensuite, le serveur identifie le client par un couple login, password. A partir du moment ou le serveur est identifi, un tunnel TLS chiffr est tablit permettant au client denvoyer son login et mot de passe via les mthodes vue ci-avant : PAP, CHAP ou MSCHAPv2. Lavantage dEAP-TTLS est donc de permettre une authentification mutuelle sans avoir recours une infrastructure de gestion de cls (IGC). Le protocole PEAP (Protected EAP) fonctionne de la mme faon quEAP-TTLS la seule diffrence quil ne peut fonctionner quen direct avec un serveur radius supportant EAP, alors que EAP-TLS est plus souple et peut utiliser un serveur intermdiaire TTLS redirigeant les messages vers un serveur Radius non EAP. 2.4.4- LEAP LEAP (Lightweight EAP) est une implmentation propritaire dEAP dveloppe par Cisco sur ses quipements actifs. Ce protocole fonctionnant avec des cartes puces prsente plusieurs dfaillances puisque dune part il utilise la mthode MS-CHAPv1 pour tablir lidentification du client par le point daccs et dautre le login/mot de passe en clair sur le rseau.

2.5-

802.1X

802.1X nest pas rellement un protocole mais une norme dfinissant un contrle de laccs au rseau bas sur le port. Ce standard mis au point par lIEEE (Institute of Electrical and Electronics Engineers) pour objectif de raliser une authentification au moment de la connexion au rseau (filaire ou sans fil) pour permettre la connexion ce dernier. Pour raliser lauthentification, les changes dans 802.1X sont bass sur EAP (voir ci-avant). 802.1X dfinit trois types dlments : - Le demandeur (supplicant) qui reprsente lhte dsirant accder au rseau

Rapport de TER de Thibaut de Dompsure et Vincent Sage

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

- Lauthentificateur direct (authenticator) : Cest un lment actif qui met en uvre le processus douverture ou de fermeture de laccs au rseau en fonction de la rponse du serveur dauthentification. Lauthentificateur peut aussi bien tre un commutateur, un point daccs sans fils ou un commutateur/routeur. - Le serveur dauthentification : il rpond aux requtes de lauthentificateur en lui indiquant si le demandeur peut se connecter ou pas. Le serveur dauthentification peut trs bien tre intgr au commutateur mais, dans ce cas, il ne permet pas une gestion centralise des accs. Cest pourquoi l plupart du temps, il dagit dun serveur indpendant, comme Radius. 802.1X dfinit deux types des ports sur lauthentificateur les ports contrls et non contrls : - Les ports non contrls permettent lauthentificateur de communiquer avec dautres nuds du rseau. Le port utilis pour communiquer avec le serveur dauthentification est donc non contrl. - Les ports contrls permettent au demandeur de communiquer avec le rseau aprs avoir t autoris. Avant cette autorisation, aucune trame ne peut tre mise du demandeur vers le rseau. Lensemble de ces deux ports sappelle le point daccs au rseau (PAE), il est indpendant de la nature physique de ces ports (RJ45, connecteur SC, MT-RJ, 802.11a,b,g). Si une authentification est refuse par le serveur, un systme de temporisation au niveau de lauthentificateur est effectu (60 secondes par dfaut) permettant de limiter les attaques de type force brute . Malgr un contrle daccs efficace au rseau, 802.1X possde nanmoins quelques faiblesses : par exemple sil ny a aucune restriction sur le nombre dadresses MAC autorises par port, il est tout fait possible pour un utilisateur de brancher un hub et donc de faire bnficier dautres personnes le port ouvert. Dautre par, des attaques par rejeu et des vols de session sont possibles, particulirement lors de son utilisation en milieu Wifi. 802.1X propose donc un niveau de scurit correct mais pour une protection optimale il doit tre coupl dautres technologies (par exemple de chiffrement), particulirement en Wifi avec WPA.

3- Services dauthentification de la couche rseau 3.1IPsec

Fig. 5 : La pile TCP/IP et IPsec Profitant de la dfinition du nouveau protocole IPv6, lIAB (Internet Architecture Board) a dcid dintgrer des services de scurit dans le protocole IP lui-mme. IPsec sinsre dans la pile de protocole TCP/IP, au niveau IP. Le niveau de scurit dIPsec est li la puissance des algorithmes utiliss. Avant de pouvoir dtailler le service dauthentification, il est ncessaire de connatre la diffrence entre le mode de transport et le mode tunnel. Rapport de TER de Thibaut de Dompsure et Vincent Sage 8

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

Deux modes peuvent tre utiliss : Le mode transport : il est plutt utilis dans une configuration point point. Il prend le flux de la couche 4 du modle OSI, ralise les mcanismes de signature et de chiffrement, puis transmet les donnes la couche IP. Les en-ttes du message sont donc construits par le protocole IP. Les adresses dmission et de destination des paquets IP sont envoyes en clair. Le mode tunnel : il est utilis entre deux passerelles de scurit pour relier des systmes dinformations dentreprises. Il chiffre les flux jusqu la couche IP incluses, ce qui offre un niveau de scurit suprieur au mode transport. Notre but ici ne sera pas de dtailler le fonctionnement du protocole IPsec mais, de voir plus particulirement, le service dauthentification offert par IPsec. Cest une authentification de couche 3 : elle authentifie des htes et non des personnes. Limplmentation de ce service se traduit par des informations supplmentaires se trouvant dans les en-ttes, en fonction du mode dacheminement des donnes et des modes utiliss. Dans tous les cas, les donnes sont authentifies par le champ appel ICV (Integrity Check Value). Ce sont des donnes dauthentification. Ce champ est de taille variable. Cest un terme gnrique qui dsigne soit une signature numrique, soit un code dauthentification de message (Message Authentication Mac). AH et ESP ne spcifient pas d'algorithme de signature particulier, ceux-ci sont dcrits sparment, cependant la RFC 2402 et 2406 demandent ce que les algorithmes de hachage s MD5 et SHA-1 soient implments. Le rsultat obtenu est une empreinte fixe de donnes : Si cest un code dauthentification de message, lICV est le rsultat dun hachage sens unique cl secrte. Lempreinte dpend des donnes et de la cl. Si cest une signature numrique, lICV est en fait le chiffrement dune empreinte partir dune cl publique. Cette technique a lavantage dajouter le service de non rpudiation en plus dassurer lauthentification et lintgrit. Mais elle est cependant moins utilise en pratique car une cryptographie cl publique consomme plus de ressource

. Le service dauthentification ne peut-tre rendu que sil y a eu, au pralable, un dialogue initial permettant lchange de cls. Il peut tre fait manuellement sil y a peu de machine. Si le nombre de machines augmente, la spcification IPsec propose des procds d'change automatique de cls comme le protocole IKE (Internet Key Exchange RFC 2409). Deux protocoles sont proposs par la norme : AH et ESP. On les utilisent en fonction des services que lon dsir avoir. 3.1.1- Protocole AH Le protocole AH (Authentication Header - RFC2402) : garanti lauthentification de la provenance du paquet (en-tte IP), lintgrit et le non-rejeu des donnes. AH dans le mode transport Dans le mode transport, l'intgrit et l'authentification sont assures par l'insertion de l'en-tte AH entre l'en-tte IP dorigine et la charge utile IP (les donnes). La valeur ICV qui se trouve dans len-tte AH est calcule sur base de l'en-tte IP dorigine, de l'en-tte AH et de la charge utile IP.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

Fig. 6 : Datagramme AH AH dans le mode tunnel Dans le mode tunnel, AH encapsule un paquet IP, avec un en-tte AH et un nouvel en-tte IP, puis signe ce nouveau paquet en vue d'en garantir l'intgrit et l'authentification. La valeur ICV se trouve dans len-tte dauthentification.

Fig. 7 : Datagramme AH (mode tunnel) Ainsi, on est sr que les datagrammes IP reues sont bien mis par l'hte dont l'adresse IP est indique comme adresse source dans les en-ttes. On peut remarquer que pour le protocole AH, ladresse dorigine et ladresse destination font partie du contrle dintgrit. Par consquent, une translation dadresse (NAT) est impossible. 3.1.2- Protocole ESP Le protocole ESP (Encapsulated Security Payload RFC 2406) : garanti lauthentification de la charge utile dIP (segment TCP, message UDP, message ICMP) , lintgrit, le non-rejeu des donne et la confidentialit des donnes. ESP peut tre utilis seul ou combin AH. ESP avec le mode transport En mode de transport, ESP ne signe pas l'ensemble du paquet. Seule la charge utile IP (les donnes) est protge, et non l'en-tte IP. La valeur ICV se trouve dans les donnes dauthentification et elle est calcule sur base de l'en-tte ESP, des donnes de la charge utile et du code de fin ESP (remorque ESP sur le schma).

Rapport de TER de Thibaut de Dompsure et Vincent Sage

10

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

Fig. 8 : Datagramme ESP ESP avec le mode tunnel

Fig. 9 : Datagramme IP (mode transport) En mode tunnel, ESP encapsule un paquet IP avec un en-tte ESP et un nouvel en-tte IP, ainsi qu'un code de fin d'authentification ESP o se trouve la valeur ICV. On peut remarquer que l'en-tte IP n'est pas protg par le hachage. L'en-tte IP n'est donc pas ncessairement protg contre une modification. IPsec est un protocole de niveau 3 et il ne fournit donc qu'une authentification de niveau gal, c'est--dire une authentification des machines. Lutilisation du protocole AH ou ESP noffre pas le mme niveau dauthentification. Il faut utiliser ESP et AH pour assurer le chiffrement, l'intgrit des donnes et l'authentification de l'en-tte IP.

3.2-

NuFW

NuFW est un pare-feu authentifiant ouvert et libre (licence GPL v2) disponible sous linux et bas sur Netfilter. Comme tout pare-feu bas sur Netfilter, NuFW permet le filtrage et le routage des paquets, mais cest uniquement son rle de passerelle dauthentification que nous allons nous intresser. Concrtement, NuFW fonctionne comme une passerelle par laquelle passent toutes les requtes des clients, mais contrairement un simple filtrage au niveau IP, NuFW prend rellement en compte la notion d'utilisateur en interrogeant le client nufw grce au serveur d'authentification "nuauth". Ainsi, cette passerelle peut autoriser ou nom la connexion en fonction des permissions de l'utilisateur (stockes dans un LDAP par exemple) et mettre jour une table des connexions authentifies. Le principe de NuFW est d'authentifier et d'associer un identifiant chaque paquet mis par un client suivant l'algorithme suivant :

Rapport de TER de Thibaut de Dompsure et Vincent Sage

11

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

Fig. 10: Algorithme d'authentification d'un paquet 1- Une application classique situe sur le client envoie un paquet. 2- Le client NuFW envoie une requte au serveur NuFW 3- Le serveur NuFW envoie une demande d'authentification au serveur d'authentification nuauth 4- Le serveur nuauth cherche les permissions en interrogeant le client NuFW . 5- Nuauth envoie la rponse au serveur NuFW. 6- En fonction de la rponse, le serveur NuFW autorise ou non la transmission du paquet au serveur distant. NuFW possde une option permettant de mettre en place trs facilement une solution d'authentification unique (SSO : Single Sign On). Cette solution SSO permet lutilisateur de sauthentifier une seule fois au niveau de la passerelle, les authentifications tant effectues par les serveurs qui vont se charger dinterroger le Systme NuFW. En activant cette option, NuFW stocke dans une base SQL les paramtres IP d'une connexion, l'utilisateur qui l'a ouverte et l'tat de la connexion (ferme, tablie, ouverte). Ainsi, comme tout serveur distant connat les paramtres IP des connexions entrantes, il peut trs facilement faire le lien avec l'utilisateur en interrogeant la base SQL du serveur NuFW et autoriser ou non l'accs. Voici le schma de fonctionnement de la solution SSO de NuFW

Fig. 11: Fonctionnement du SSO NuFW

1234L'utilisateur envoie un paquet la passerelle pour accder un serveur distant. La passerelle NuFW vrifie l'autorisation de passage du paquet (voir ci-avant). NuFW rempli la table SQL avec l'IP, l'utilisateur et l'tat de la connexion. La passerelle NuFW transmet le paquet au serveur distant.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

12

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1 5- Le serveur interroge la base SQL pour connatre l'utilisateur qui mis le paquet. 6/7- En fonction de l'utilisateur l'application rpond la passerelle qui transmet au client.

2006-2007

4- Services dauthentification de la couche session 4.1SSL/TLS

Le protocole propritaire SSL (Secure Socket Layer) t dvelopp par Netscape pour scuriser les transactions entre un client et un serveur web (gnralement un site marchand). Il existe plusieurs versions de SSL : la version 3.0 est la plus rpandue, mais depuis la version 3.1 SSL t rebaptis TLS version 1 (Transport Layer Security) et standardise par l'IETF. SSL ou TLS sont des protocoles situs dans la couche session et fonctionnent donc indpendamment des applications qui les utilisent. Ils permettent d'assurer non seulement des services d'authentification, mais aussi des services de confidentialit par chiffrement symtrique (DES, IDEA, 3DES, ...) et d'intgrit par hachage MD5 ou SHA-1. Actuellement SSL et TLS sont principalement utiliss pour scuriser des changes HTTP, ce qui donne le protocole HTTPS, mais en ralit, SSL et TLS permettent de crer des tunnels scuriss et peuvent donc tre utiliser avec nimporte quel protocole scuris de couche suprieur comme FTP, SMTP, etc. De plus, les nombreuses librairies disponibles permettent dimplmenter SSL/TLS dans de nombreux langages (PHP, C++, etc.). Les deux protocoles ne sont pas interoprables mais TLS propose un mcanisme de compatibilit ascendante avec SSL. TLS napporte pour linstant que peut damliorations par rapport SSL, mais dans lavenir, les nouveaux algorithmes de chiffrement lui seront intgrs et il deviendra plus scuris que SSL. SSL/TLS, contrairement aux protocoles que nous avons dfinis jusqu maintenant ne sert pas authentifier un client auprs dun serveur, mais un serveur auprs dun client afin que le client soit sr quil ne communique pas avec un serveur factice. Une fois cette authentification ralise, le client et le serveur schangent une cl secrte qui va leur permettre de communiquer en chiffrant leurs messages avec un algorithme de chiffrement symtrique. La phase de communication chiffre sappelle : SSL Record Protocol et la phase dauthentification : SSL Handshake Protocol. Dans le cadre de notre recherche, cest cette ngociation qui nous intresse, voici ses diffrentes tapes :
1- Le client se connecte au serveur puis lui envoie un message CLIENT-HELLO contenant plusieurs informations dont la version de SSL/TLS et les algorithmes de chiffrements quil supporte. 2- Le serveur lui renvoie le nom de lalgorithme le plus sr quil a en commun avec le client et un certificat X509 contenant sa cl publique. Ce certificat est sign par une autorit de certification. 3- A la rception du certificat, le client doit effectuer trois vrifications : - La priode de validit du certificat X509 : gnralement un certificat est valide un an, si la date et lheure ne sont pas dans la priode de validit le processus dauthentification ne va pas plus loin. - La validit de lautorit de certification (AC) : chaque client SSL possde une liste de certificats des autorits de certifications de confiance, si le nom distinct (DN : Distinguished Name) de lAC correspond bien au DN dune AC de confiance existante dans la liste alors elle est valide. - La validit de la signature numrique de lmetteur : En utilisant la cl publique de lAC, le client peut vrifier la signature du certificat X509 du serveur, en effet, cette signature t ralise par la cl prive de lAC donc seule lAC pu signer le certificat. Une quatrime tape optionnelle peut tre ralise pour vrifier que lIP du serveur correspond bien celle dfinit dans le certificat. 4- Une fois le serveur authentifi, le client calcule et envoie un code secret intermdiaire quil chiffre avec la cl publique RSA du serveur.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

13

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

5- Le serveur dchiffre le code secret intermdiaire avec sa cl prive RSA. Le client et le serveur utilisent ce code secret intermdiaire pour crer une cl secrte de session compatible avec lalgorithme de chiffrement symtrique dfinit ltape 2. 6- Le serveur envoie au client un message chiffr avec la cl secrte de session indiquant au client que la ngociation est termine et que les prochains changes seront chiffrs avec cette cl secrte de session.

TLS propose galement une authentification du client auprs du serveur grce un certificat client dans ce cas, ltape 4 le client envoie galement son certificat au serveur pour que celui-ci puisse vrifier sa validit. SSL/TLS propose donc une authentification forte base sur des cls RSA trs difficilement cassables, cependant toute la force de ce protocole repose uniquement sur la validation certificat, cest pour cette raison que SSL peut malgr tout tre vulnrable une attaque du type Man in the middle . En effet, si quelquun arrive intercepter toutes les communications entre le client et le serveur, il peut alors rcuprer le certificat lgitime envoy par le serveur et lui substituer son propre certificat valide de cette faon le client valide automatiquement le certificat et le pirate peut se faire passer pour le serveur auprs du client et pour le client et auprs du serveur. Le pirate peut ainsi dchiffrer toutes les communications de faon totalement transparente.

5- Services dauthentification applicatifs 5.1RADIUS

Remote Authentication Dial-In User Service - RFC 2865 et RFC 2866 RADIUS est une norme de lIETF (Internet Engineering Task Force). Cest un protocole dauthentification standard Client/serveur qui permet de centraliser les donnes dauthentification : Les politiques dautorisation et de droits daccs, traabilit. Ce processus doit tre reli une source dinformations, qui est souvent un annuaire LDAP. Auparavant, les noms et les mots de passe des utilisateurs devaient tre dupliqus sur chaque serveur pouvant tre accd distance (par un modem RTC par exemple). Larriv de RADIUS permit aux fournisseurs daccs Internet dauthentifier les utilisateurs distants connects, partir dune seule base utilisateurs. Ce protocole avait particulirement un sens avant lADSL illimit, car il permettait de mesurer le temps prcis de connexion des abonns et facturer en consquence. Lidentification sur les sites Web peut aussi tre gre par RADIUS. Apache est sans doute le client RADIUS le plus rpandu (le module mod_auth_radius permet Apache de valider une authentification en interrogeant un serveur Radius). Aujourdhui, ce protocole est aussi souvent utilis pour les connexions Internet sans fil (WLAN - avec le protocole 802.1X qui assure l'identification par port pour l'accs un rseau). On le retrouve aussi au sein de la tlphonie sur IP comme outil de gestion des connexions, autour du protocole SIP notamment. Dans ce cas, l'annuaire SIP charg de l'authentification communique avec le serveur Radius en utilisant ce protocole. Son fonctionnement est simple : 1. Lutilisateur (le supplicant dans la RFC) se connecte (via PPP ou Telnet) un client RADIUS (ou NAS : Network Access Server), qui est en gnral une passerelle/proxy. 2. Le client RADIUS demande lutilisateur son nom et son mot de passe, et il les communique de manire scurise un serveur RADIUS reli une base de donnes ou un annuaire LDAP. 3. En fonction de la zone daccs demande et des droits de lutilisateur, le serveur RADIUS peut exiger des informations supplmentaires pour lauthentification.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

14

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

- La rponse CHALLENGE permet dviter de transmettre le mot de passe. Le client envoie alors une autre requte rpondant au Challenge pour s'authentifier. - Si lidentification russie, le Serveur rpond par un ACCEPT (REJECT dans le cas contraire). 4. Le serveur RADIUS envoie enfin les autorisations de lutilisateur. Il pourra par la suite bloquer une connexion en cours et assurer une journalisation des accs.

Fig. 12 : Fonctionnement de Radius Les limitations du protocole : Il a t conu au dpart pour des identifications sur des liaisons lentes et peu sres. Le choix du protocole UDP (port 1812) conduit des changes laborieux bass sur des temporisations de rmission et des changes daccus de rception. Scurit relative reposant sur le secret partag. Certaines implmentations clientes limitent en plus sa taille. Chiffrement de lattribut User-password par une fonction de hashage MD5, plutt rserv pour des oprations de signature. Le rejeu des rponses du serveur est possible. Pas de mcanisme d'identification du serveur. Il est ainsi possible de se faire passer pour un serveur RADIUS et de rcolter les noms et mots de passe des utilisateurs.

Les normes qui compltent le protocole RADIUS sont les protocoles dauthentification PAP, CHAP ou EAP. Le successeur du protocole Radius pourrait tre le protocole Diameter. Nous en parlerons plus loin. Les diffrentes implmentations de RADIUS sont : - Microsoft : le service d'authentification IAS pour Windows Serveur 2000/2003, et NPS (Network Policy Server) pour Windows Server Vista. - Communaut du libre : OpenRadius et FreeRadius. IAS et NPS IAS (Internet Authentication Service) est le service d'authentification Internet sur Windows 2000 (Serveur IAS) et Windows Server 2003 (Service IAS). Cest une implmentation Microsoft du serveur RADIUS : Le service IAS joue le rle du serveur RADIUS. Il effectue une authentification, une autorisation et une gestion des comptes centralises des connexions pour de Rapport de TER de Thibaut de Dompsure et Vincent Sage 15

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

nombreux types d'accs rseau (accs sans fil, accs par commutateur d'authentification, accs par connexion distance et VPN). En tant que proxy RADIUS, le service IAS peut envoyer les messages d'authentification et de gestion de comptes d'autres serveurs RADIUS. NPS (Network Policy Server) est l'implmentation d'un serveur et proxy RADIUS sur Windows Serveur Vista. Il remplace le service d'authentification Internet (IAS) de Windows Server 2003. Cette nouvelle implmentation effectue toutes les fonctions dj prsentes dans IAS notamment pour les connexions VPN, pour les connexions sans fil et pour les connexions bases sur 802.1X. De plus, NPS effectue une valuation du bon fonctionnement du rseau et rserve un accs limit ou illimit pour les clients NAP. NAP (Network Access Protection) est une nouvelle protection de laccs rseau dans Windows Server Vista. Il offre de nouvelles possibilits au niveau stratgie de scurit : Par exemple il peut demander que les entits du rseau possdent les dernires mises jour du systme d'exploitation et les derniers fichiers de signature antivirus. En fonction de cela, les entits auront plus ou moins de droits sur le rseau. Ces entits sont appels client NAP. NPS prend en charge aussi l'envoi du trafic RADIUS via IPv6 (RFC 3162).

5.2-

TACACS+

Tout comme Radius, TACACS+ (Terminal Access Controller Access Control System Plus) est un serveur dauthentification permettant de centraliser les autorisations daccs dans un parc dentreprise. Ce protocole invent par CISCO Systems a remplac TACACS et XTACACS mais nest pas bas sur ceux-ci. TACACS+ supporte diffrents types darchitectures, par exemple, si un utilisateur utilise une connexion point point, cest le serveur daccs qui va jouer le rle de client TACACS+ pour interagir avec le serveur TACACS+, en revanche, si lutilisateur utilise une connexion Wifi, cest le point daccs qui va jouer le rle de client TACACS. Dautre part, TACACS peut tre utilis pour sauthentifier sur un matriel CISCO, dans ce cas la connexion est initie sur le matriel CISCO, cest ce dernier qui va interroger le serveur RADIUS.

Fig. 13 : Diffrentes architectures supportes par TACACS La particularit de TACACS+ par rapport aux serveurs dauthentification traditionnels est a sparation protocolaire des trois fonctions AAA (Authentication, Authorization, Accounting). En effet, TACACS+ permet dutiliser des technologies diffrentes, que ce soit pour dterminer lidentit dune personne, de dterminer ses droits, ou encore de grer lenregistrement des logs. TACACS utilise le protocole TCP (port 49) et gnralement une seule session (authentification, autorisation ou enregistrement de logs) est ralise par connexion TCP. Chaque session est numrote et les paquets peuvent tre chiffrs par cet identifiant de sessions.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

16

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

La phase dauthentification peut supporter plusieurs protocoles comme des techniques de type PAP (login - mot de passe) ou encore CHAP ( base de challenge). Ensuite, quelque soit la fonction AAA demande au serveur TACACS+, une session suit toujours le mme protocole : le client envoie une requte START au serveur dcrivant le type de session initie, puis, des paires de messages de type REQUEST/REPONSE contenant des paires attributs-valeur . La RFC ne dfinit pas dimplmentation spcifique pour le stockage des informations relatives aux comptes utilisateur, le serveur TACAC+ peut aussi bien utiliser des fichiers systmes (/etc/passwd), des bases de donnes, des cartes puces ou encore dautres serveur dauthentification comme Kerberos. TACACS+ est donc un serveur dauthentification relativement simple mais il couvre quand mme lensemble des fonctions AAA et de plus il peut sintgrer tout type dinfrastructure de part sa libert dimplmentation.

5.3-

Kerberos

Kerberos est un protocole dauthentification rseau standardis par lIETF. Lobjectif de Kerberos est double : scuriser un change sur un rseau non scuris et avoir une authentification fiable de lutilisateur. Il est bas sur deux entits : - Le serveur dauthentification (AS : Authentication Server) qui prend en charge toute la partie authentification pur du client. Cest lui seul qui peut permettre au client de communiquer au TGS (grce un ticket daccs). - Le serveur de distribution de tickets (TGS : Ticket Granting Server) prend en charge les demandes daccs aux services des clients dj authentifis. Lensemble des infrastructures serveur de Kerberos AS et TGS est appel le centre de distribution de cls (KDC : Key Distribution Center). Ils sont gnralement regroups sur le mme serveur. Dans Kerberos, tous les tiers doivent prouver leur identit : on utilise des mcanismes dauthentification mutuelle. Le protocole est bas sur des tickets horodats et chiffrs. Les changes reposent sur un systme de cryptographie (algorithme DES) base de cls symtriques. Kerberos partage avec chaque client du rseau une cl secrte faisant office de preuve d'identit. Les mcanismes dauthentification : Le client dsir accder au serveur pour obtenir un service. Ce serveur est reprsent dans notre schma par lApplication Server. Le client a sa propre cl prive Kc. Le serveur a sa propre cl prive Ks. Le TGS a sa propre cl prive Ktgs et connat la cl prive du serveur Ks LAS connat les cls prives du client et de TGS. Le TGS et AS sont deux entits normalement de confiance.

1. AS_REQ : le client sidentifie auprs de lAS laide dun mot de passe ou dune carte puce. 2. LAS vrifie dans sa base (par exemple AD) que le client existe. Il gnre une cl de session Kc,tgs.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

17

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

Puis il envoie au client AS_REP : - Une cl de session Kc,tgs chiffre avec Kc, qui fera office de mot de passe temporaire pour chiffrer les communications suivantes. - Un ticket d'accs T1 au service de dlivrement de ticket, chiffr avec Ktgs (que le client ne peut donc pas dchiffrer). Il contient notamment lheure de lopration, sa dure de validit, ladresse de la machine cliente ainsi que la cl de session Kc,tgs. 3. TGS_REQ : le client fait une demande de ticket auprs du TGS. Le client lui transmet : - Le ticket daccs T1 que lAS lui avait donn . - Un identifiant contenant des informations sur le client avec la date dmission, chiffres avec la cl de session Kc,tgs 4. Le TGS : - Dchiffre avec sa cl, le ticket daccs T1. Il obtient la cl de session Kc,tgs. Le TGS est maintenant certain que le client a bien obtenu le T1 de lAS. - Dchiffre alors les informations que le client avait prcdemment chiffr avec la cl de session. Il vrifie que la dure de validit est correcte. Puis le TGS envoie au client TGS_REP qui comprend : - Un ticket T2 pour accder au serveur dapplication. Il est chiffr avec la cl priv de ce serveur Ks. - Une seconde cl de session Kc,s pour les communications entre le serveur final et le client. Cette cl a t chiffre avec la cl initiale Kc,tgs. 5. Le client dchiffre la seconde cl de session Kc,s avec Kc,tgs Il envoie AP_REQ au serveur dapplication deux informations : - Un nouvel identifiant chiffr avec Kc,s - Le ticket daccs T2 6. Le serveur dapplication vrifie que le ticket est valide en dchiffrant T2 avec Ks. Il obtient Kc,s.

Le serveur peut alors vrifier la cohrence entre les deux informations. Par exemple il vrifie que la demande est conforme ce qui est autoris par le ticket. Une rponse positive ou ngative AP_REP est envoye au client. Les points forts de Kerberos : Le transit des mots de passe sur le rseau est chiffr. Il permet aux utilisateurs de sauthentifier une fois pour toutes lors du login. Ils pourront aprs utiliser tous les services daccs distance sans avoir fournir chaque fois leur login et mot de passe. Ils sont en fait toujours authentifis de manire transparente par Kerberos pour eux. Sparation des rles : lAS et le TGT. Cest la base de Kerberos. Mais dans la ralit, ces deux rles sont regroups en une mme entit (KDC). Impossible de rejouer un change deux fois de la mme manire (grce au timestamps).

Les points faibles de Kerberos : - Le chiffrement symtrique ncessite un partage des cls entre lAS et le client. - Les horloges doivent tre parfaitement synchronises : en effet, lanti-rejeu sappuie sur le timestamps . - Lauthentification mutuelle nest pas disponible lors du premier change entre lAS et le client. Le client ne peut pas certifier que lAS et bien celui quil prtend tre. En revanche, le client peut exiger que le serveur dapplication s'authentifie son tour (lors de la dernire tape). Ce dernier s'excute en renvoyant la date courante (plus rcente que celle du prcdent message du client) chiffre avec Kc,s. Etant donn que seuls le client et le serveur connaissent Kc,s, le client peut raisonnablement penser que c'est bien le serveur qui lui rpond. Remarque : Kerberos est le mcanisme dauthentification par dfaut dans Windows pour vrifier lidentit dun utilisateur ou dun ordinateur. Les rles de lAS et TGS sont pris en compte par le contrleur de domaine, en sappuyant sur lannuaire Active Directory. Rapport de TER de Thibaut de Dompsure et Vincent Sage

18

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

On pourrait distinguer deux types dauthentifications sous Windows : - Il y a louverture de session interactive qui permet de sauthentifier en local sur lordinateur. Elle sappuie sur le rfrentiel utilisateur local appel base SAM (Security Accounts Manager) - Il y a lauthentification rseau qui permet daccder un ordinateur distant pour en parcourir les rpertoires. Elle sappuie sur la base SAM de lordinateur distant. Il existe aussi un mcanisme (notion de domaines Windows) qui permet de mixer les deux : Ainsi il est possible de sauthentifier sur lordinateur local en utilisant une base de comptes utilisateurs stocks sur un serveur rseau. Pour grer les donnes du rseau, Windows utilise un annuaire : Active Directory.

5.4-

Authentification web

Comme nous lavons montr ci-avant, les protocoles SSL et TLS permettent de mettre un place un service dauthentification (et de chiffrement) pour http, mais mme sil est possible deffectuer une authentification du client grce TLS, lobjectif principal de ces protocoles est de permettre dtre certain de lauthenticit du serveur. Pour mettre en place une authentification des clients il existe plusieurs mthodes applicatives. 5.4.1- PHP/ASP La mthode la plus simple pour raliser une authentification des utilisateurs avec un langage script tel que PHP ou ASP est de crer un formulaire permettant de saisir login et mot de passe puis de crer un page PHP ou ASP appele par le formulaire et vrifiant que le login et le mot de passe sont valide en les comparant ceux stocks en dur dans la page PHP ou ASP. La page dauthentification tant excute ct serveur il est priori impossible pour un client de lire son contenu. La page PHP suivante permet de raliser ce type dauthentification :
<?php if ($_POST['pseudo'] = login_valide && $_POST['passwd']=passwd_valide) header('Location: authorized_page.php'); else echo 'Pseudo ou mot de passe erron !';

?>

Les inconvnients de ce type dauthentification sont bien videmment nombreux : dune part nimporte qui ayant accs la page depuis le serveur peut lire les login et mots de pass, et dautre part la maintenance des comptes est fastidieuse et non centralise. La mthode la plus utilise est donc gnralement un interfaage avec une base de donnes. PHP permet par dfaut une connexion avec un trs grand nombre de bases de donnes, et si une base nest pas supporte ou alors si ASP est utilis, le pilote propritaire ODBC (Open DataBase Connectivity) dvelopp par Microsoft peut tre utilis. Pour raliser linterfaage, la page PHP/ASP doit dfinir les proprits de la base de donnes : nom dutilisateur, mot de passe, adresse rseau de la base de donnes, et nom de la base afin de pouvoir initier une connexion avec elle. Puis, une fois la connexion effectue, il suffit dutiliser des requtes SQL du type : "SELECT login, passwd FROM authorized_accounts" afin de vrifier les permissions des utilisateurs. 5.4.2- .htaccess Les fichiers .htaccess sont des fichiers texte propres au serveur web Apache. Ils permettent de dfinir des rgles daccs toute une partie, voir tout le site hberg. Ils sont stocks dans le rpertoire sur lequel on dsire effectuer lauthentification et contiennent une instruction par ligne : Tout dabord il faut spcifier lendroit o sont contenus les login/mot de passe des visiteurs autoriss (AuthUserFile, AuthGroupFile) puis il faut dfinir le message de la bote de Rapport de TER de Thibaut de Dompsure et Vincent Sage

19

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

dialogue qui va safficher pour que lutilisateur rentre son login et son mot de passe. Enfin, entre les balises <limit GET POST> ou <limit PUT POST> (suivant le type de requte) et </limit> il faut spcifier quels sont les utilisateurs autoriss (par exemple require user Toto ). Les fichiers .htaccess permettent galement de filtrer les utilisateurs par IP ou dutiliser MD5 pour raliser un hash des mots de passe.

6- Annuaires 6.1Active Directory

Active Directory est un annuaire systme hirarchique et compatible LDAP. Il permet de localiser, rechercher et grer des ressources reprsentes par des objets de l'annuaire. Il offre des mcanismes de scurit pour protger ses informations. Il permet de grer des ressources lies la gestion du rseau (domaines, comptes utilisateurs, stratgies de scurit etc). La base de donnes d'AD est distribue ce qui lui amliore la tolrance aux pannes. Active Directory respecte le standard LDAPv3. Il est donc capable d'interagir avec des clients et des serveurs LDAP d'autres origines. Les protocoles d'change entre serveurs AD sont propritaires et non publics. Un contrleur de domaine ne pourra donc pas travailler avec lannuaire d'un fournisseur tiers. Certains produits Microsoft sont installs par dfaut (ou fortement conseills lors de l'installation): DNS, serveur WeB. D'autres bnficient d'une forte intgration avec AD (serveur de courrier Exchange, ISA Server). Active Directory centralise l'authentification. Le contrle d'accs peut tre dfini la fois sur chaque objet de l'annuaire et sur chaque proprit de ces objets. Il fournit non seulement le stockage mais galement l'tendue d'application des stratgies de scurit. Quels que soient les qualits des produits concurrents (Serveurs Apaches, annuaires openldap ou novell, serveurs DNS etc), leur mise en place sera forcment moins naturelle que celles des produits Microsoft. AD est l'un des maillons de la conqute du march des serveurs par Microsoft. Le support par AD d'un certain nombre de protocoles standard a pour but de fdrer l'ensemble des ressources rseau autour de serveurs Microsoft. Nous ne rentrerons pas dans les dtails techniques de configuration dAD. Mais nous allons plutt nous attach aux mcanismes gnraux quil utilise : LDAP et KERBEROS notamment.

6.2-

LDAP

LDAP (Lightweight Directory Access Protocol) est actuellement en version 3 et il est normalis par lIETF. Il sagit dun protocole dinterrogation dannuaire. On dit quil est allg, par comparaison la norme X500, son anctre, dont la mise en uvre tait trs lourde. LDAP au cur du systme dinformation. Il regroupe les donnes dune entit au mme endroit. On dit que cest un annuaire fdrateur. Cest un standard incontournable : la plupart des applications rcentes sappuient dessus : les outils de messageries, les actifs du rseau (proxy, firewall), les progiciels de gestion, les intranets etcUne majorit de logicielles utilisent LDAP pour lauthentification. LDAP est une base donne hirarchique et non pas relationnelle comme les SGBD. On peut ainsi reprsenter son contenu sous forme darbre. Lannuaire est conu pour Rapport de TER de Thibaut de Dompsure et Vincent Sage

20

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

rfrencer toutes sortes dinformations : informations sur des personnes, sur des applications, sur un parc informatique Le concept de lannuaire, cest de maintenir de faon cohrente et contrle une grande quantit de donnes et doptimiser la consultation en lecture au dpend de lcriture. Les accs concurrents sont grs et la quantit de donne pouvant tre stocke est quasi illimit. La contrepartie est que les mises doivent tre ponctuelles et les enregistrements peu volumineux : On utilise des chanes de caractre courtes et on limite le nombre de fichiers binaires (certificats, photos). LDAP propose donc des mcanismes pour grer lauthentification. Plusieurs mthodes sont possibles en fonction du niveau de scurit dsir : - La connexion anonyme est gnralement limite la consultation de parties restreintes de lannuaire. - Lauthentification par login/mot de passe. - Lauthentification par login/mot de passe avec hachage de ce dernier. - Lauthentification par login/mot de passe sur TLS avec un tunnel TLS entre le client et lapplication et un tunnel TLS entre lapplication et lannuaire. - Lauthentification par certificat X509. - Authentification plus labore grces aux API SASL (Simple Authentification and Security Layer). Cette API permet dintgrer facilement des mcanismes dauthentification forte comme Kerberos, Radius, ou des systmes de mot de passe usage unique comme OTP. Il est aussi possible de scuriser les changes entre lannuaire LDAP et les clients par LDAP sur TLS ou LDAPS. Le principal avantage de LDAP est la normalisation de l'authentification. Il est trs facile de programmer un module d'authentification reposant sur LDAP partir d'un langage possdant une API LDAP. C'est l'opration Bind qui permet d'authentifier un utilisateur. Aujourdhui, de plus en plus d'applications Web possdent un module d'authentification prenant en charge LDAP. Les applications peuvent ainsi dlguer ltape dauthentification lannuaire LDAP qui met en uvre lune des mthodes prcdentes. Par exemple sur les systmes GNU/Linux rcents, les fichiers password et shadow sont de plus en plus remplacs par des appels LDAP. Les donnes peuvent tre accdes par le module PAM (Pluggable Authentication Modules). PAM est un mcanisme (sous Linux, Solaris, HP-UX) qui permet justement de dlguer les fonctionnalits dauthentification, sans recompiler quoi que ce soit. PAM peut tre paramtr en fonction de lapplication (base de compte NTLM pour les anciennes versions de Windows, base de compte Unix ou autre) et en fonction du mode daccs lapplication (Intranet, Extranet, Web). Le module de connexion de PAM fournit linterface avec les annuaires (ou les fichiers). Cest cette couche qui validera que lidentifiant et le mot de passe sont valides et retournera une rponse aux applications.

6.3-

NIS/NIS+

NIS (Network Information Service) est un systme de base de donnes distribue fonctionnant au dessus de RPC et permettant de grer et stocker les informations systmes (les noms d'hte /etc/hosts, les comptes utilisateurs /etc/passwd, etc) et de les diffuser tous les htes du rseau. Originairement, NIS portait le nom Yellow Pages (YP) mais Sun la renomm NIS, cependant, toutes les commandes NIS commencent par yp. NIS est architectur en diffrents domaines, chaque domaine contient : un serveur NIS matre qui maintient la base de donnes, des serveurs esclaves optionnels qui dchargent le serveur matre et font office de sauvegarde, et des clients NIS qui peuvent interroger les serveurs

Rapport de TER de Thibaut de Dompsure et Vincent Sage

21

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

matres ou esclaves. Le serveur matre est le seul pouvoir modifier la base de donnes (changements de mots passe, etc.). Ds quune modification est effectue sur la base, elle est automatiquement propage aux serveurs esclaves. Le principal inconvnient de NIS est sont manque de scurit : nimporte quel hte du rseau peut interroger le serveur sans avoir sauthentifier. Une volution de NIS plus scurise et permettant de grer de gros rseaux t dveloppe par Sun : NIS+. Cette version totalement reconue supporte le chiffrement des donnes et lauthentification scurise par RPC. Malgr ces amliorations, NIS et NIS+ ne font plus lobjet de dveloppements spcifiques et sont remplacs par LDAP, beaucoup plus puissant et complet.

7- Les volutions venir 7.1Diameter

Diameter, une solution d'authentification utilisant le protocole TCP au niveau de la couche transport, au lieu d'UDP dans le cas de Radius. Il est de toute manire compatible avec les normes Radius et EAP. Ce nest pas une extension de RADIUS mais un successeur du protocole. Il est bas sur TCP et utilise des attributs de grande taille. Diameter est destin aux changes entre serveurs sur des liaisons sres ; les serveurs Diameter (non dploys pour l'instant) sont gnralement compatibles Radius. Un certain nombre de types d'attributs Diameter se retrouvent dj dans EAP-TTLS par exemple.

7.2-

Liberty Alliance

Cr par un consortium dditeur (notamment Intel, France-Telecom, Verisign, IBM, Sun) afin de contrer le systme propritaire Passport de Microsoft. Passport est en effet un moteur SSO (Single Sign On) qui consiste simplement sauthentifier une fois sur le systme dinformation. Les sessions sont alors propages aux applications sappuyant sur ce systme dauthentification unique. Liberty propose de standardiser linvocation des services didentit en dfinissant un protocole bas sur les standards et indpendant des langages de programmation. Il dfinit une infrastructure base sur des fournisseurs de services et des fournisseurs didentits : - Les fournisseurs de services sont les applications ncessitant une authentification, donc consommatrices de donnes utilisateur. - Les fournisseurs didentit dlivrent ces informations utilisateurs. - Ces acteurs sont relis entre eux par des cercles de confiance dfinissant des accords de coopration. Ils s'changent des informations sur l'identit de leurs utilisateurs respectifs. Elles prsument qu'en amont lesdits utilisateurs ont t correctement authentifis. La grande innovation des fournisseurs didentit est doffrir, en plus de lauthentification, une srie de services autour du rfrentiel utilisateur : - Un service de SSO (Single Sign On) qui permet de propager des sessions utilisateurs entre fournisseurs de services. - Un service de Global Logout, qui permet de mettre fin lensemble des sessions chez les fournisseurs de services. - Un service de profil utilisateurs qui permet de sparer les donnes profils utilisateurs et den rglementer laccs. Le projet Liberty dcrit une srie de services didentit user-centric grce auxquels, leur usager peut grer laccs ses donnes personnelles. Liberty Alliance apporte aussi la notion de Rapport de TER de Thibaut de Dompsure et Vincent Sage 22

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

fdration. Au lieu que ce soit un fournisseur de service qui dcide si un utilisateur a le droit d'accder son service sans se r-identifier, c'est l'utilisateur qui dcide s'il veut accder ce service sans se r-identifier. Dautres nouveaux concepts sont apports : comme une nouvelle technologie de chiffrement permettant l'utilisateur de masquer ses donnes personnelles au fournisseur d'identit central, ainsi qu'aux fournisseurs de services dans chaque "cercle de confiance". L'utilisateur peut garder ainsi la mainmise sur les informations qu'il accepte de voir transiter entre deux sites de commerce en ligne. Reste ensuite trouver un point d'quilibre entre, d'un ct, la tendance enfermer le client dans un systme o il est tenu faire confiance au fournisseur d'identit, et de l'autre, la valeur ajoute que constitue la complte matrise de ses donnes prives pour l'utilisateur. Enfin, Liberty Alliance n'a pas confiance dans les mots de passe. L'authentification forte simpose petit petit. Cest une authentification forte base de jetons, cartes puce, biomtries ou produits similaires. Les mots de passe sont jugs dpasss pour une scurit digne de ce nom. Elle vite le risque d'usurpation d'identits, le seul mot de passe ne suffisant plus accder aux services. Si ce standard est en cours de finalisation (une nouvelle version est sortie en novembre 2006), il commence tre implment par les grands diteurs (Sun, Novell, SAP etc...).

7.3-

La biomtrie

La biomtrie apparat comme le meilleur moyen de s'authentifier, de faon fiable et pratique. C'est difficilement falsifiable. On distingue les moyens de biomtrie physiques (la main, les yeux), des moyens de biomtrie issus du comportement de la personne (la voix, la signature). Il y a diffrents moyens biomtriques pour s'authentifier : 1. La gomtrie de la main : Identifier quelqu'un par la forme de sa main et/ou ses empreintes digitales sont des moyens faciles utiliser et qui offre des bonnes performances. 2. La rtine : Identifier une personne en analysant son empreinte rtinienne , cest--dire la disposition des vaisseaux sanguins du fond de l'oeil. Pour rcuprer cette empreinte, il faut obliger l'utilisateur regarder dans un dispositif qui claire le fond de l'il. En gnral, les gens sont assez rticents ce moyen d'authentification. Pourtant, ce serait le moyen le plus sr. 3. L'iris : Son motif est unique pour chaque individu. L'authentification via l'iris ne ncessite pas d'clairer la rtine. 4. Le visage : Identifier une personne sur les caractristiques de son visage : distance entre le nez et la bouche, entre les yeux... 5. La signature : Identifier quelqu'un sur la faon dont il signe un texte : la vitesse, la pression exerce ... 6. La voix : Identifier une personne sur la tonalit de sa voix (caractristiques de ses frquences). Ce nest pas sur la reconnaissance de ce qu'elle dit.
Caractristiques Facilit d'utilisation Cause d'erreur Empreinte digitale Gomtrie de la main Rtine Iris Visage Signature Voix

Moiteur, la Blessure la clairage Lunettes salet, ge. main, l'ge. trop faible.

clairage, Changement le bruit, l'ge, les dans la le temps, lunettes, signature. un rhume les

Rapport de TER de Thibaut de Dompsure et Vincent Sage

23

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1 cheveux. Caractristiques La prcision Acceptation du public Niveau de scurit requis Stabilit dans le temps Empreinte digitale Gomtrie de la main Rtine Iris Visage

2006-2007

Signature

Voix

Tableau trouv sur http://www.securite.teamlog.com Pour mettre en place un systme dauthentification biomtrique, il faut : - Dans un premier temps : rcuprer les donnes et les stocker dans un endroit scuris. - Ensuite, lors de l'authentification : Il faut rcuprer les donnes stockes, rcuprer la nouvelle empreinte puis comparer les deux "empreintes" biomtriques. La mise en place d'un moyen de biomtrie implique du matriel pour rcuprer l'information (le capteur), une base de donnes pour rcuprer les informations, une recherche pour dterminer au mieux les besoins. Elle implique aussi la mise en place et l'installation et la connexion du systme ct utilisateur, la formation des utilisateurs et la mise en place de procdures d'exception quand une personne n'arrive pas s'identifier, sans oublier la maintenance du systme. Au final, cela demande une certaine adaptation au mcanisme au dbut. On peut aussi imaginer l'utilisation de moyens biomtriques dans une PKI (Public Key Infrastructure), o les utilisateurs possderaient une carte puce avec identification d'une empreinte digitale en plus. La biomtrie est une solution dauthentification forte qui gagne petit petit du chemin.

8- Conclusion
Notre tude montre que le systme dauthentification parfait nexiste pas, aucune mthode nest gnrique et il est indispensable de connatre parfaitement linfrastructure rseau et systme pour choisir le systme dauthentification le plus adapt. Il faut galement bien distinguer les mthodes dauthentification faibles des mthodes dauthentification forte : il est certain qu lheure actuelle les systmes bass sur des mots de passe sont moins robustes que les systmes base des certificats. Cependant quelles que soient les donnes sur lesquelles se base une authentification, si elles sont numriques, il y a toujours un risque de vol d'identit. C'est pour cette raison que l'avenir se tourne donc plutt vers des techniques priori infalsifiables comme la biomtrie. Le futur s'oriente galement vers des systmes d'identit centraliss pouvant tre propags. Ces systmes d'authentifications uniques permettent non seulement de simplifier l'accs aux services protgs mais surtout de limiter les risques potentiels lis aux authentifications multiples. Enfin, il ne faut pas oublier que la scurit est un tout, et que l'authentification en est la premire brique, elle doit imprativement tre complte, par exemple par des technologies de gestion des droits ou de chiffrement.

Rapport de TER de Thibaut de Dompsure et Vincent Sage

24

Master 2 Systmes Informatique et Rseaux de lUniversit Claude Bernard Lyon1

2006-2007

9- Bibliographie 9.1Documentations crites

G. Plouin, J. Soyer et M-E. Trioullier : Scurit des architectures Web, Dunod, 2004. G. Pujolle : Initiation aux Rseaux, Eyrolles, 2000. A. Tanenbaum : Rseaux 4e Ed, Pearson Education, 2004. S. Borderes, N. Makarevitch : Authentification rseau avec Radius, Eyrolles, 2006. J. Garman : Kerberos: The Definitive Guide, Oreilly, 2003. J. Bournelle et M. Laurent-Maknavicius : Adaptation et implmentation de Diameter/AAA pour Mobile IPv6, Proceeding of the DNAC 2002, 2002. Y. Legrandgrard : Le protocole IPSec et les Rseaux Virtuels Privs, 2006

9.2-

Documentations en lignes
LDAP : http://www.ietf.org/rfc/rfc4403.txt http://www.cru.fr/ldap/ NIS/NIS+ : http://tldp.org/HOWTO/NISHOWTO/ Liberty Alliance : http://www.projectliberty.org/ Autres : http://www.securite.teamlog.com http://www.wikipedia.org http://www.Microsoft.com http://www.commentcamarche.net http://www.supinfo-projects.com http://www710.univ-lyon1.fr/~ogluck http://graal.ens-lyon.fr/~ycaniou http://www.securite.org/ http://www.ietf.org

Protocoles dauthentification : http://www.labocisco.com/ArticleComp.asp?ARID=30 http://www.ietf.org/rfc/rfc2284.txt http://open1x.sourceforge.net/ NuFW : http://www.nufw.org SSL/TLS : http://www.certa.ssi.gouv.fr/site/CERTA-2005REC-001 http://www.openssl.org http://www.ietf.org/rfc/rfc2246.txt RADIUS : http://www.freeradius.org http://www.ietf.org/rfc/rfc2865.txt TACACS+ : http://www.ietf.org/rfc/rfc1492.txt http://www.cisco.com/warp/public/614/7.html Kerberos : http://www.ietf.org/rfc/rfc4120.txt Authentification web : http://www.securiteinfo.com/conseils/htaccess.s html Active Directory http://www.lami.univ-evry.fr/~petit/

Rapport de TER de Thibaut de Dompsure et Vincent Sage

25