Kerberos

Cross - platform authentication and single sign - on

Version 1.0 du 23 janvier 2004

Exposs de nouvelles technologies des rseaux

Septembre 2003 Fvrier 2004 Ecole d'ingnieur en Informatique et Rseaux de l'universit de Marne - laValle Clment DEBON Julien VICTOR

Kerberos

TABLE DES MATIRES

I.Introd uction ...................................................................................................................................3 II.Pourquoi utiliser un service d'authentification ?...............................................................4 III.Le protocole Needham Schroeder, base de Kerberos ....................................................5
1 2 3 4 5 6 7 8 Prsentation du protocole Needha m - Schroeder ......................................................................................... 5 Drouleme nt du protocole .................................................................................................................................... 6 Qu'est - ce que Kerberos ?....................................................................................................................................... 9 Prsentation de l'authentification avec Kerberos ........................................................................................ 0 1 TGS / TGT................................................................................................................................................................. 13 Mon royaume pour Kerberos ............................................................................................................................. 14 Audit ........................................................................................................................................................................... 15 Les ports utiliss par Kerberos ..........................................................................................................................1 6

IV.L'volution de Kerberos, V1 V5........................................................................................17

1 Athena ........................................................................................................................................................................ 17 2 Des versions internes ............................................................................................................................................ 17 3 Versions 4 et 5........................................................................................................................................................ 18 3.1 Des origines la version 4......................................................................................................................... 18 3.2 Quoi de neuf dans la version 5?.............................................................................................................. 8 1 3.3 Les diffrences entre la version 4 et la version 5..............................................................................1 9

V.Mise en oeuvre sur diffrentes platefor mes .....................................................................2 2

1 Le serveur .................................................................................................................................................................. 22 2 Le client ou le serveur d'application ................................................................................................................ 23

VI.L'avenir de Kerberos ............................................................................................................... 5 2

1 Une volution permane n t e .................................................................................................................................. 25 2 De nouvelles bases ................................................................................................................................................. 25 3 Une refonte totale du systm e d'authe ntification ?................................................................................... 6 2

VII.Conclusion ................................................................................................................................28 VIII.Bibliographie ...........................................................................................................................29

Kerberos
Historique du docum ent

I. INTRODUCTION
aKu m6uNt>zb.gV zgQ{ s[M 7%):wO, D*<^

Le dbut de ce document est crypt. En effet, pourquoi dciderions - nous de laisser ces informations la vue de tous ? Comment savoir dans quel but vous voulez y avoir accs ? Et puis, tout d'abord... qui tes - vous ? Voici autant de questions que l'on peut se poser ds le dbut d'une conversation entre deux personnes. Autant de questions qui peuvent survenir autant dans la vie de tous les jours que dans le monde virtuel. Si, lors d'une conversation banale, la prsence d'oreilles indiscrtes (o qu'elles se trouvent) est tolrable, il n'en va pas de mme dans le domaine de l'informatique. Des donnes circulent en permanence, reprsenta n t autan t de donnes confidentielles que de donnes personnelles. Lorsque l'on consulte des donnes confidentielles, comme l'tat de notre compte bancaire via Internet, il est vident que l'on ne veut comm u niq uer qu'avec notre banque. Et pour tre certain qu'il s'agisse bien de notre banque , il va nous falloir les outils adquats pour la reconnatre.

Kerberos
Pourquoi utiliser un service d'aut hentification ?

II. POURQUOI UTILISER UN SERVICE D'AUTHENTIFICATION ?

Tout d'abord, il faut se souvenir que dans des temps trs reculs l'chelle de l'informatique, dans les annes 70, les terminaux taient relis au serveur par des liens spcialiss. Pour s'infiltrer, un cracker devait donc obligatoiremen t se brancher physique me n t sur ces liens. Lorsque les rseaux ont commenc utiliser un modle client - serveur et que les terminaux ont t remplacs par les PC, les administrate ur s ne pouvaient plus avoir confiance dans les utilisateurs finaux. En effet, ceux- ci peuvent dsor mais modifier un logiciel ou couter le rseau. Il a donc fallu mettre en place un systme permetta n t de rtablir cette confiance sur le rseau. Aujourd'h ui, alors que nous consultons tous les jours nos e- mails, ou que nous changeons des donnes que nous souhaiterions confidentielles, les mots de passe et les donnes circulent la plupart du temps en clair entre notre poste et le serveur ou le destinataire. Cela signifie que quiconq ue surveillant nos donnes pourra lire nos conversations, nos mots de passe et donc nos donnes. La solution propose est la mise en place d'un systme d'authentification, permettan t d'assurer que deux interlocuteur s se connaissent et savent qui est l'autre. Comme les comm u nications peuvent, en principe, tre vues par n'impor te qui, il a t propos de les scuriser, afin que seules les person nes concernes puissent consulter ces informations confidentielles. Kerberos est l'un des protocoles d'authentification disponibles. Il a t cr par le MIT pour solutionner ces diffrents problmes de scurit des rseaux.

Page 4 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

III. LE PROTOCOLE NEEDHAM SCHROEDER, BASE DE KERBEROS

1 Prsentation du protocole Needham - Schroeder
Deux chercheurs du Xerox Palo Alto Center, Roger Needham et Michael Schroeder, ont dfini, vers la fin des annes 70, une platefor me scurise permettan t d'authentifier les utilisateurs. Ils ont mis en place deux protocoles, dont l'un utilisant des cls prives de cryptage, et qui est la base de Kerberos. Le systme dfini est suppos vivre dans un environne me n t hostile, o n'impor te qui est capable d'couter les paquets sur le rseau et de les modifier. Cependant, ils ont pris comme hypothse que l'utilisateur choisira un mot de passe respectant certains critres (en particulier, en vitant un mot de passe trop court ou un mot trop commu n). Ainsi, ce protocole ne protge en rien contre une attaque de type force brute (brut force) ou utilisant un dictionnaire de mots. Le protocole dfinit trois participants dans le rseau :

un client ; un serveur proposa nt le service que l'utilisateur veut utiliser ; un serveur d'authentification.

Le client reprsente la machine effectuant la requte d'authentification : en gnral, il s'agit d'un PC. Le serveur est un serveur applicatif, comme par exemple un serveur de messagerie ou bien un serveur de fichiers. Enfin, le serveur d'authentification est un serveur ddi, dtenant l'ensemble des cls de cryptage des clients et des serveurs du rseau. Il ne s'agit pas ici d'authentifier l'utilisateur avec le serveur d'authentification en utilisant un simple mot de passe. Le protocole Needham - Schroeder fournit un mcanisme permetta n t de distribuer une cl de cryptage au client et au service, celle- ci disposant d'une validit limite dans le temps. L'authentification des deux parties se fait alors au travers de cet change.

Page 5 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

2 Droulement du protocole
Premirement, le client contacte le serveur d'authentification. Il envoie un message contenant son identit ainsi que celle du serveur d'application qu'il tente de contacter. Il y joint galement une valeur alatoire.

Figure 3.1 : Premier change

Le serveur d'authentification reoit ces informations, et recherche les cls prives de cryptage correspon d a n t au service et l'utilisateur. Il adjoint une troisime cl utilisation unique, gnre alatoirement, appele cl de session et utilise pour scuriser les comm u nications entre le serveur d'application et le client. Dans ce protocole, le serveur d'authentification ne comm u nique jamais directement avec le serveur d'application. Il retour ne au client un message contenant la cl de session ainsi que l'identit vrifie des deux parties. Comment ce message peut - il tre protg d'une personne coutant sur le rseau ? Et avant cela, comment le serveur d'authentification peut - il tre certain de l'identit du client lorsqu'il le contacte ? La rponse est apporte par plusieurs couches de cryptage. Tout d'abord, le message est constr uit de manire ce que seul le serveur d'authentification puisse le lire. Il contient le nom du client ainsi qu'une cl de session. Afin d'viter la possibilit d'tre capt sur le rseau, il est crypt l'aide de la cl du serveur d'application. Or, seuls le serveur de service et le serveur d'authentification connaissen t cette cl. Dans la terminologie de Kerberos, on parlera de ticket pour un tel message.

Page 6 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

Le message de retour destin au client contient le message d'origine, le nom du serveur d'application, une copie de la cl de session ainsi que la cl alatoire du client. Ce message est crypt l'aide de la cl prive du client. Le serveur d'authentification ne peut pas dter miner si le client est bien qui il prten d tre. Il retour nera ce message quiconque le lui demander a, pour autant que l'utilisateur fasse bien partie de sa base d'infor matio n s. Cependant, comme le message est crypt l'aide de la cl du client, seul celui- ci pourra dcrypter ce message.

Figure 3.2 : Construction de la rpons e pour le client

Le client reoit donc le message, et doit alors entrer la cl (le mot de passe) permettan t de le dcrypter. S'il ne donne pas le bon, l'authentification aura chou. En cas de succs, le client aura alors charge de faire suivre la cl de session au serveur d'application. Il pourra alors lui faire parvenir le ticket , contenant une copie de la cl de session et le nom du client, le tout crypt l'aide de la cl du serveur d'application. Seul le serveur de services est alors capable de dcrypter le message, et donc de rcuprer la cl de session.

Figure 3.3 : Envoi

du ticket de service

Page 7 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

A partir de l, la comm u nication entre les deux parties ne peut tre interprete que par elles. Le client sait qu'il s'adresse au bon serveur, puisque lui seul tait en mesure de dcrypter le message contenant la cl de session. De son ct, le serveur d'application sait que le client est bien qui il prten d tre, puisqu'il a t capable de dcrypter le message contenant la cl de session et l'identit du client qui lui a t ensuite transfr. Cependant, il reste une attaque laquelle faire face. Le rseau tant considr comme non scuris, une personne mal intentionne serait en mesure de rcuprer tous les messages circulant, et en particulier le message d'authentification envoy par le client au serveur d'application. Elle pourrait alors utiliser ce message plus tard et le renvoyer au serveur d'application. Dans ce cas, si le serveur n'utilisait pas la cl de session pour scuriser la comm u nication avec le client, l'attaqua n t pourrait se faire passer pour sa victime. La solution apporte par le protocole Needham Schroeder oblige le client prouver qu'il dtient bien la cl de session : pour ce faire, le serveur d'application gnre un autre nombre alatoire, qu'il crypte l'aide de la cl de session et fait parvenir au client. Le client dcrypte alors ce nombre et doit, par exemple, lui ajouter une unit, puis le renvoyer crypt avec cette mme cl de session. De cette manire, seul le vrai client, dtenant la cl de session, est en mesure de rpondre au serveur de service avec le bon nombre.

Figure 3.4 : Vrification mutuelle de l'identit

Le protocole Kerberos utilise une approche similaire pour viter ce type d'attaq ue, mais il est bas sur un systme d'horloges synchronises.

Page 8 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

3 Qu'est - ce que Kerberos ?

Kerberos a t conu dans le but de proposer un protocole d'authentification multi - platefor me, disposant d'un systme de demande d'identification unique, et permetta n t de contacter ensuite autant de services que souhait. C'est pour ces raisons qu'il s'appuie sur le protocole de Needham Schroeder. Il s'agit d'un protocole scuris, dans le sens o il ne trans me t jamais de mot de passe en clair sur le rseau.. Il trans met des messages crypts dure de vie limite. Le terme single sign- on , utilis en sous - titre de ce document, dcrit le fait que l'utilisateur final n'a besoin de s'authentifier qu'une fois pour utiliser toutes les ressources du rseau suppor ta n t Kerberos au cours de sa journe de travail (en ralit, au cours du temps de session spcifi par l'administrate ur : environ vingt heures, en gnral). Le systme Kerberos repose sur un tiers de confiance (Trusted third party), dans le sens o il s'appuie sur un serveur d'authen tification centralis dans lequel tous les systmes du rseau ont confiance. Toutes les requtes d'authentification sont ainsi routes au travers de ce serveur Kerberos centralis. Le systme d'authentification mutuelle utilis permet non seulement de prouver que l'utilisateur derrire son clavier est bien qui il prtend tre, mais aussi que le service qu'il tente d'utiliser correspon d galement. De cette manire, la commu nication instaure assure la confidentialit des donnes sensibles. Les trois concepts dfinis ci- dessus permettent de dcrire les bases du service d'authentification rseau Kerberos.

Page 9 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

4 Prsentation de l'authentification avec Kerberos

Kerberos s'appuie donc sur ces bases lorsqu'un utilisateur du rseau souhaite utiliser un service. Les trois entits prsentes ici, le client, le service et le serveur d'authentification, sont dfinies en tant que principals dans Kerberos. Le service a besoin de savoir qui est l'metteur de la requte. C'est pour cela que l'utilisateur lui prsente un ticket, qui lui a t remis par le centre de distribution des cls Kerberos, ou KDC (Kerberos Key Distribution Center ). Le ticket doit donc contenir des informations permetta n t d'identifier clairemen t l'utilisateur. Il doit montrer que l'metteur dtient une information que lui seul peut connatre, comme par exemple un mot de passe. Kerberos ncessite que l'utilisateur et le service bnficient de cls enregistres auprs du KDC, et requiert la synchronisation des horloges des clients et des serveurs du rseau. La cl de l'utilisateur est drive d'un mot de passe que lui- seul connat, tandis que celle du service est gnre alatoirement (personne ne peut taper de mot de passe dans ce cas). A partir de ce point, le droulement est trs similaire au protocole dcrit prcde m m e n t. Le client met une requte auprs du KDC, prcisant son nom ainsi que celui du service souhait. Lorsque le KDC reoit ce message, il cre deux copies d'une cl gnre, la cl de session, qui sera utilise au cours de la comm u nication entre le client et le service.

Figure 4.1 : Premier change avec le service d'aut he ntification

Page 10 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

Figure 4.2 : rponse du service d'aut hentification

Figure 4.3 : requete au TGS

Page 11 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

Le KDC envoie un message compor ta n t deux botes , l'une contenant une copie de la cl de session ainsi que le nom du service, crypte l'aide de sa cl prive ; la seconde contenant la deuxime copie de la cl de session, ainsi que le nom de l'utilisateur, et crypte l'aide de la cl du serveur d'application. Cette deuxime cl est appele ticket .

Figure 4.4 : rponse du TGS

L'utilisateur ouvre la premire bote avec sa cl et rcupre le nom du service. Il ne peut pas ouvrir la seconde, puisqu'elle a t ferme avec la cl du serveur d'application. Il va alors composer un nouveau message contenan t non seulement cette deuxime bote, mais aussi une bote contenant son nom et l'heure d'envoi et crypte l'aide de la cl de session. Cette troisime bote est appele authenticator dans le jargon Kerberos. Le serveur d'application reoit ce message, ouvre la deuxime bote l'aide de sa cl prive, obtient ainsi la cl de session qu'elle contient et peut enfin ouvrir la troisime bote qui lui tait destine. Le service connat ainsi le nom de son interlocuteur, et l'heure de son poste de travail. Cette information est trs importante, puisqu'elle permet de s'assurer que personne n'a copi le ticket. Comme les horlo ges ne sont pas toujours en parfaite synchronie, une marge de cinq minutes est autorise par dfaut. De plus, le service maintient une liste des authenticator envoys, afin de s'assurer qu'ils ne soient pas r- mis.

Page 12 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

Ticket de service

Ticket - Granting Ticket

Authenticator

Figure 4.5 : les diffrent s tickets circulant sur le rseau

En gnral, l' authenticator contient beaucoup plus d'infor ma tions que celles que nous exposons ici, comme par exemple un checksum pour valider l'intgrit des donnes, ou une cl de cryptage pour assurer la confidentialit des comm u nications futures entre le client et le service. Parfois, l'utilisateur souhaite que le service s'authentifie son tour. Pour cela, le service rcupre l'heure de la troisime bote ( authenticator ), le met dans une quatrime bote avec son nom, et la crypte l'aide de la cl de session. Quoi qu'il en soit, cette bote doit contenir l'heure contenue dans la troisime, pour assurer au client la provenance du message, car lui- seul est en mesure de valider cette information.

5 TGS / TGT
Les changes dcrits jusqu'ici sont ncessaires chaque fois qu'un utilisateur tente d'atteindre un service, et chaque fois qu'il doit entrer un mot de passe (qui permet de dcrypter la premire bote). Une solution consisterait stocker la cl drive du mot de passe, mais cela engendrerait un problme de scurit : une copie de ces cls permettr ait de se faire passer pour l'utilisateur. Kerberos offre une solution ce problme, en rpartissant les fonctionnalits du KDC : d'un ct le serveur d'authentification ( Authentication Server ) ; de l'autre, le serveur d'obtention de ticket ( Ticket - Granting Server ). Le serveur d'authentification est charg de produire les tickets pour le TGS.

Page 13 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

Le client fourni un mot de passe, en change duquel le TGS lui donne un ticket ( Ticket - Granting Ticket ) et la cl de session associe (cf Figure 4.2). Celui- ci est valable en gnral pendant huit heure. Il s'agit de la seule comm u nication entre le client et le serveur d'authentification. Comme le TGT est le premier ticket obtenu, il est aussi appel ticket initial . Ensuite, quel que soit le service dont voudra bnficier le client, il enverra le TGT au TGS afin d'obtenir un ticket ordinaire (cf Figures 4.3 et 4.4). Il n'aura donc plus besoin d'entrer son mot de passe, puisque le KDC et lui- mme partagent la cl de session. L'utilisateur peut donc simplement adresser un message au TGS, contenant le TGT ainsi qu'un nouvel authenticator , ce qui l'identifiera immdiate men t.

6 Mon royaume pour Kerberos

Jusqu' prsent nous n'avons considr qu'un seul serveur d'authentification et un seul TGS, installs ou non sur la mme machine. Cependant, dans une grande entreprise, il n'est pas rare de dcomposer le rseau en royaumes ou realm . En effet, avec une augmentation des requtes d'authentification sur le rseau, le KDC deviendrait un goulot d'tranglement pour le processu s, ce qui n'est pas permis pour un systme distribu comme Kerberos. Les royaumes correspon de n t gnralement aux zones DNS. Par consquen t, le nom du royaume est, dans ce cas, le nom de domaine DNS en majuscule. Pour permettre a un utilisateur d'un royaume d'atteindre un service situ dans un autre, le royaume de l'utilisateur doit s'authentifier auprs du TGS distant ( Remote TGS ). Les deux royaumes changent alors une paire de cls, qu'ils utiliseront uniqueme n t lors de la phase d'authentification entre royau mes. En fait, cette procdure est transparente pour l'utilisateur. Le program me Kerberos se charge de contacter le serveur d'authentification pour accder au TGS, puis il contacte le TGS pour atteindre le TGS distant, et enfin le service. Kerberos V5 propose mme une structure hirarchique des royaumes, car il n'est pas toujours utile de tous les traverser pour atteindre le service. En fait, l'ensemble des royaumes traverser est enregistr dans les tickets.

Page 14 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

Le cas d'un client voulant atteindre un service au travers d'un routeur mais dont l'adresse est translate (NAT) pose une difficult, car l'adresse IP de la machine mettant la requte apparat dans les tickets. La solution consiste soit paramtrer chaque client du rseau NAT afin qu'il utilise l'adresse interne du routeur pour les demandes de tickets, soit utiliser l'option - A de l'application kinit , pour prciser une demande de tickets sans adresse IP. Il est aussi possible de modifier le fichier /etc / k r b 5.co n f en y ajoutant, dans la section libdefaults , la ligne :
noad d re s s e s = true

Toutes ces procdures vous semblent sans doute bien compliques, mais aux yeux de l'utilisateur, tout ceci est transparent : les program m es Kerberos se chargent de contacter le bon royaume, et l'utilisateur n'a plus qu' simplement utiliser le service qu'il dsire.

7 Audit
Il est bien entend u important de s'assurer qu'aucune personne extrieure ne soit capable d'attaquer une machine du rseau, mais il est tout aussi important de raliser des audits en interne pour s'assurer de l'abscence de toute activit illicite. Pour cela, Kerberos propose de nombreuses options de journalisation de l'activit. Bien que Windows 2000 ne propose aucun journal par dfaut, ils sont paramtr ables depuis la console de gestion de la politique de scurit.

Page 15 / 29

Kerberos
Le protocole Needha m Schroeder, base de Kerberos

8 Les ports utiliss par Kerberos

Le tableau suivant rcapitule les ports utiliss par le serveur Kerberos, ainsi que la description du service correspon d a n t.

Version Kerberos 5

Port 88 749

tcp oui oui non

udp oui non oui non oui

Description Service de tickets Kerberos 5 Service Kerberos 5 pour le changement du mot de passe de l'utilisateur Service de conversion Kerberos 5 4 de tickets de

4444 749 464 Kerberos 4 750 751 761 oui oui oui oui oui non oui non

Service d'administration de Kerberos 5 Service de changement de mot de passe pour une machine d'administration KDC Service de tickets Kerberos 4 Service d'administration Kerberos 4 Service de changement de mot de passe Kerberos 4

Page 16 / 29

Kerberos
L'volution de Kerberos, V1 V5

IV. L'VOLUTION DE KERBEROS, V1 V5

1 Athena
Le projet Athena, soutenu par un consortiu m de vendeurs d'ordinate ur s, est lanc en mai 1983, pour une dure de 5 ans. Son but tait de dvelopper des stratgies, ainsi que des logiciels, dans le cadre d'un systme rseau client serveur. Il devait, l'origine, tre uniqueme n t utilis par le MIT. Vont ainsi tre conus des systmes encore utiliss de nos jours, comme par exemple NFS (Network File System) et le serveur X (base de l'interface graphique des systmes Unix). L'ide d'un systme d'authen tification a germ au sein du MIT lorsqu'il est devenu vident que ses tudiants allaient tre autoriss accder des serveurs de fichiers sur un rseau assez grand. Ce projet a t raccroch au projet Athena. L'objectif de ce projet tait de dvelopper un protocole rseau d'authentification : celui- ci devait centraliser la confiance dans quelques machines d'un rseau, qui allaient tre troitement surveilles et contrles. Les comm u nications d'authen tification entre ces serveurs de confiance et les autres ordinateur s du rseaux devaient tre cryptes afin de ne pas pouvoir tre interceptes (scurisation). Depuis sa conception au sein du projet Athena, le protocole Kerberos a subit d'impor tan te s modifications, lui permettan t d'acqurir une meilleure facilit d'utilisation, une grande modularit et plus de scurit.

2 Des versions internes

Les versions 1, 2 et 3 du protocole sont internes au MIT et auront servi exprimenter de nouveaux concepts, pour finalement concevoir un systme stable. Elles sont donc plutt considres comme des versions de test du protocole.

Page 17 / 29

Kerberos
L'volution de Kerberos, V1 V5

3 Versions 4 et 5
3.1 Des origines la version 4
Mise disposition le 24 janvier 1989, la premire version publique du protocole a t rapidement approuve et mise en oeuvre par plusieurs concepteur s de systmes d'exploitation. En rponse la lgislation amricaine leur interdisant l'exportation de leur prod uit, en particulier cause de l'utilisation de DES (algorithme de cryptographie), une version spciale ddie l'exportation a t conue. Surnom me Bone, elle ne contient donc plus aucun code de cryptage. Dans l'universit australienne Bond, Errol Young dveloppe sa propre implmenta tion de l'algorithme DES et l'intgre la version Bones. Cela va donner eBones qui, dveloppe en dehors des Etats - Unis, ne tombe plus sous sa lgislation et peut tre librement exporte. Plusieurs implmenta tions du protocole Kerberos 4 ont t dveloppes. Mme si certaines sont encore assez activement utilises, la version 4 de l'implmenta tion du MIT est dornavant en phase de maintenance, et peut tre considre comme termine. Il est aujour d' h ui recom m a n d d'utiliser la version 5, dernire en date.

3.2 Quoi de neuf dans la version 5?

La version 5 du protocole Kerberos a t dveloppe afin d'appor ter de nouvelles fonctionnalits et de nouvelles amliorations du point de vue de la scurit. La nouveaut la plus importante docu ment a tion dans la RFC1510. Ont t amliors :

pour la prnit du protocole est sa

la dlgation des tickets des types de cryptage extensibles des authentifications inter - royaumes amliores ...

Page 18 / 29

Kerberos
L'volution de Kerberos, V1 V5

3.3 Les diffrences entre la version 4 et la version 5

Gnralits
Kerberos V5 est ainsi suprieur la V4 dans bien des domaines. Cependan t, ces amliorations ont un cot : de plus faibles perfor ma nces. Cependant, cette nouvelle version permet entre autres d'utiliser des algorithmes de cryptage plus puissants et fiables, car DES a depuis t reconn u vulnrable certaines attaques. La plupart de ces vulnrabilits sont pourtant dues au MIT, et sa propre implmentation des algorithmes, et peuvent ne pas tre prsentes dans d'autres implmentations de Kerberos. Malheureuse m e n t, tout comme sa version prcdente, l'implmentation du protocole par le MIT est toujours soumise aux lois amricaines (malgr le nouveau statut des logiciels libres dans ce cadre) et ne peut tre lgalemen t exporte en dehors des territoires US. La version 4 de Kerberos est, pour le moment encore, assez utilise. Cette version n'est pas aborde dans ce document, au profit de la version 5 (qui reste compatible avec la version 4).

Une nouvelle norme de codage

Le plus difficile, dans une comm u nication informatique (comme humaine), est de se faire comprendr e par son interlocuteur. Tout va bien lorsque, d'un ct comme de l'autre, les normes de codage (ou de langage) est identique. Cela devient plus difficile avec la diversit des ordinateur s, et des systmes que l'on peut rencontrer. En informatique, ce problme se pose essentiellement dans la reprsenta tion des nombres : little- endian (bit de poids faible la fin), et big- endian (bit de poids fort la fin). Le protocole TCP/IP utilise la reprsenta tion big- endian , mais les dfenseur s du little- endian restent nombreux. La version 4 utilise un bit supplment aire (appel bit B) dfinissan t la reprsenta tion utilise dans le message :

0 dans le cas de big- endian 1 pour little- endian

Page 19 / 29

Kerberos
L'volution de Kerberos, V1 V5

Le protocole V5 utilise quant lui une reprsentation totalement diffrente. Il utilise un standar d de formatage des donnes, nomm ASN.1 (pour Abstract Syntax Notation One), standar dis par l'ISO (International Standar d s Organization). Cela permet Kerberos d'tre encore plus flexible, en autorisant des champ s optionnels et/o u de taille variable. Cependant, ce choix entraine le doublement de la taille des messages envoys.

Une dure de vie des tickets modifie

Le systme de gestion de la dure de vie des tickets avec Kerberos V4 ne permettait pas une grande marge de manoeuvre. En effet, la dure tait code sur 1 octets, et pouvait donc avoir en tout 255 valeurs diffrentes. Chaque valeur tant un multiple de 5 minutes, un ticket ne pouvait rester valide que 21 heures au maximu m. Si cette valeur maximu m restait correcte et approprie pour la plupart des cas, il n'en reste pas moins que de nombreux utilisateurs et administrate u r s devaientt redeman der un nouveau ticket toutes les 21 heures. Dans la version V5, cette dure de vie est reprsente sur 17 octets, avec 1 seconde par unit. Les temps reprsents sont donc virtuellement illimits, puisqu'il est maintenan t possible de faire expirer un ticket Kerberos jusqu'au dernier jour de l'anne 9999. De plus, la division en seconde du temps permet une plus grande matrise et une plus grande prcision dans les processus d'authentification.

Une dlgation amliore

La version 5 amliore grandemen t le processus de dlgation des tickets. Ainsi, contrairement la version 4, il devient possible de transfrer un ticket un autre ordinateur. La version 4 ne permet qu'une dlgation partielle, autorisant un utilisateur se connecter un autre royaume que le sien.

Page 20 / 29

Kerberos
L'volution de Kerberos, V1 V5

Un hachage des mots de passe prenant en compte la pratique

Les cls Kerberos sont des chanes d'octets (une cl DES, par exemple, a une longueur de 8 octets), compor ta n t des nombres entre 0 et 255. Comme il est difficile pour un utilisateur de se souvenir de ces nombres, Kerberos intgre un mcanisme de hachage permetta n t de transcrire une chane de caractres en une chane d'octets. Ce mcanisme ne va pas permettre, par contre, de retrouver la chane de caractres originelle. Un inconvnient majeur utilisateur possdant des le mme mot de passe rcupre en sniffant le intentionne pourra aussi possde un compte. n'avait pas t pens lors de la version 4 : un comptes sur plusieurs royaumes va vouloir garder sur tous les royaumes. Cependant, si la cl est rseau, cela signifie alors que la personne malaccder tous les royaumes sur lequel l'utilisateur

Pour limiter les dgts, la version 5 du protocole va aussi intgrer le nom du royau me dans le processus de hachage, ce qui permettr a de gnrer des cls diffrentes, pour un mme mot de passe, mais sur des royaumes diffrents.

De nouveaux algorithmes de cryptographie

Comme expliqu plus haut, l'algorithme DES n'est plus, de nos jours, considr comme fiable. Pouvant tre dcrypt en quelques heures en utilisant un cluster de machines, il est mme considr comme inutilisable d'un point de vue scurit par de nombreuses personnes. Le protocole V4 ne permet pas, moins d'nor mes modifications dans sa structu re, d'utiliser un systme de cryptage alternatif. Le protocole V5 permet donc de grer les algorithmes de manire modulaire, et intgre par dfaut Triple- DES (cls de 168 bits, contre 56 bits avec DES), qui est bien plus scurisant et solide. Cependant, le systme de cryptage DES est gard pour des raisons de compatibilit avec le protocole V4 de Kerberos.

Page 21 / 29

Kerberos
Mise en oeuvre sur diffrentes platefor m e s

V. MISE EN OEUVRE SUR DIFFRENTES PLATEFORMES

1 Le serveur
Dans le cadre de la rdaction de ce document, nous avons procd l'installation d'un serveur Windows 2003 beta. Nous avons configur notre serveur en tant que contrleur principal de domaine, serveur DNS et serveur de fichiers. De cette manire, la base Active Directory a t installe, autorisant l'utilisation de Kerberos 5 dans la gestion des mots de passe des utilisateur s. En effet, Kerberos est directement intgr LDAP.

Page 22 / 29

Kerberos
Mise en oeuvre sur diffrentes platefor m e s

La console d'administration des machines et des utilisateurs d'Active Directory permet ensuite de paramtrer l'utilisation de Kerberos dans la gestion des mots de passe. Nous avons ainsi pu paramtrer les options suivantes

durcissement de la politique de mots de passe dure de vie ...etc

Kerberos utilise DNS pour la localisation des enregistremen t s de service DNS (SRV, RFC 2052) et peut, l'aide des enregistremen t s TXT, localiser le royau me appropri correspon d a n t un nom d'hte ou un nom de domaine. Par contre, lorsqu'il s'agit de contacter un royaume non - Windows, il est ncessaire d'utiliser un program me particulier, ksetu p , pour entrer les informations manuellement. Sous Unix, la translation entre nom de machine et nom de royaume est ralise dans le fichier /etc / k r b 5.co n f , de la mme manire que /etc / h o s t s est utilis pour rsoudre les noms de machines en adresses IP.

2 Le client ou le serveur d'application

Sous Windows 2000, XP ou 2003, le simple fait d'ajouter la machine au domaine permet de bnficier de Kerberos lors de l'authentification de l'utilisateur. Sous Linux, que l'on utilise le client MIT ou Heimdal, il convient de paramtrer le fichier de configuration /etc / k r b 5.co n f . Ce fichier contient le nom et l'adresse des KDC avec lesquels le client est autoris comm u niquer. En fait, il correspon d au fichier de configuration du KDC, qu'il est donc possible de dployer facilement. Cependant, il est possible d'y apporter des modifications, suivant le poste concern, mais il est ncessaire de toujours entrer les bonnes valeurs pour trois des attributs qu'il contient :

Page 23 / 29

Kerberos
Mise en oeuvre sur diffrentes platefor m e s

libdefault / default_realm : cette option, utilise Kerberos, prcise le royaume contacter ;

par

toute

application

Ensuite, chacun des royaumes que le client sera susceptible de contacter doivent tre dcrits, soit dans la partie realms de ce fichier, soit prciss dans le DNS. Concernant le fichier krb5.conf, l'attribut le plus importan t ici est kdc ; Enfin, la section domain_realm fait le lien entre royaume et DNS, en faisant correspon d r e un domaine DNS un nom de royaume.

Sous Linux, si l'on veut utiliser une application avec Kerberos, il convient d'utiliser une version kerbrise de cette application. Ces versions sont gnralement disponibles sur Internet.

Page 24 / 29

Kerberos
L'avenir de Kerberos

VI. L'AVENIR DE KERBEROS

1 Une volution permanente
Kerberos a toujours t en constante volution, entre autres pour y intgrer les nouvelles technologies et pour palier aux nouvelles menaces. Plusieurs extensions de Kerberos V existent donc, et proposent des aperus des nouveauts qui seront implmentes dans les versions venir du protocole. Elles sont disponibles en tant que brouillon Internet (Internet Draft) au sein de l'IETF (the Internet Engineering Task Force).

2 De nouvelles bases
Il existe plusieurs faons pour authentifier gnralement, une entit) ; on peut se baser sur :

une

personne

(ou

plus

ce qu'il sait ce qu'il a ce qu'il est

Ce qu'il sait est tout simplement un mot de passe qui va permettre, par comparaison ou par dcryptage, par exemple, de vrifier que la personne est bien celle qu'elle dit tre. Seule cette technique est actuellement utilise par le protocole Kerberos. Ce qu'il a est plus subtil car il fait appel un objet que la person ne cherchant s'authentifier a en sa possession. Le plus souvent, il s'agit d'un appareil gnrant 'alatoiremen t' une suite de nombres / c a r actres. Cette suite ne sera valable uniquemen t que pendant un temps donn, et servira l'authentification. Une version future de Kerberos devrait permettre l'utilisation de suppor ts de type SmartCard, qui permettr aient d'utiliser des cls beaucoup plus longues (mais trs difficiles utiliser dans le premier cas), pour augmenter encore la scurit. Ce qu'il est est justement une mthode encore peu utilise pour le moment, et fait appel des mcanismes de biomtrie (empreinte digitale, rtine...). Cette technique n'est pas encore utilise, entre autres par le manque de logiciels l'utilisant rellement, ainsi que du peu de matriels encore
Page 25 / 29

Kerberos
L'avenir de Kerberos

onreux. L'intrt de ce systme est qu'il supprime la duplication, le vol, l'oubli et la perte. Cependant, long terme, cette technique risque de ne pas tre exempte de piratage. Une autre amlioration dans ce domaine serait la gnralisation, non pas de l'utilisation d'une de ces techniques d'authentification, mais de plusieurs d'entre - elles combines.

3 Une refonte totale du systme d'authentification ?

Les dbuts de Kerberos se droulaient en mme temps que les dbuts (ou presque) de la cryptographie asymtrique (dite cls publiques). A cette poque, ces algorythmes n'taient pas trs utiliss, entre autres cause de la puissance de calcul ncessaire, mais aussi cause des brevets dposs. La loi de Moore et le temps ont maintenant permis cette technologie d'tre plus gnralement utilise en matire de scurit (SSL, et maintenan t TSL, par exemple), et son implmentation dans Kerberos est plus que jamais l'ordre du jour. En matire de scurit, les cls asymtriques prsentent des atouts non ngligeables face aux cls symtriques (ou cryptographie cls prives). Elles vont permettre, en plus de la cryptographie des messages, de signer des messages (et donc authentifier son emetteur). Cependant, la mdaille possde quelques revers : le temps de traitemen t (utilisation de nombres plusieurs centaines de chiffres) reste, mme de nos jours, encore assez problmatique pour les grands ensembles de donnes. De plus, il est toujours difficile de s'assurer que la personne qui fournit sa cl publique est rellement celle qu'elle prtend tre. Le premier problme se rsoud en utilisant (comme de nombreux protocoles l'heure actuelle) un mlange de cls publiques (phase d'initialisation) et de cls prives (phase de trans mission de donnes). Le second peut tre corrig de deux manires diffrentes. Globalemen t, l'utilisation d'un PKI (Public Key Infrastr uct ur e), sorte de base de donnes regrou pan t les cls publiques accompagnes d'infor ma tions sur son propritaire, permet de s'assurer de l'identitit du propritaire d'une cl publique donne, car les organismes les valident eux- mmes. Moins
Page 26 / 29

Kerberos
L'avenir de Kerberos

centralis, des outils comme le package PGP vont faire intervenir une tierce person ne, connaissant personnellement le propritaire, qui va alors signer la cl publique, et donc permettre une identification formelle . Ces types de mesures sont autant de protections contre des attaques man - in- the- middle . L'utilisation des cls asymtriques avec Kerberos est donc dsor mais d'actualit, mais ncessiterait la rvision complte des mcanismes d'authentification dans le protocole Kerberos.

Page 27 / 29

Kerberos
Conclusion

VII. CONCLUSION

Le protocole Kerberos permet l'authentification des utilisateurs services du rseau. Il assure ainsi un certain degr de scurit.

et des

Du point de vue de l'utilisateur, son utilisation est trans paren te. Cependan t, il perd son anonymat sur le rseau. Cependant, une relle politique de scurit passe aussi par la mise en place de moyens tels que :

paramtrage correct des autorisations dtection des intrusions utilisation de logiciels /syst m e s rgulierement mis jour ...

Kerberos, en tant que systme d'autentification, n'est donc qu'un des maillons indissociables de toute la chane de scurit. Son rle est primor dial, car il va permettre la certification de la validit des interlocuteur s sur le rseau, mais sera totalement inutile si des portes sont laisses grandes ouvertes aux crackers, leur permettan t de prendre possession des comptes avec privilges.

Page 28 / 29

Kerberos
Bibliographie

VIII. BIBLIOGRAPHIE
Kerberos, The Definitive Guide Jason Garman Edition O'Reilly ISBN 0- 596 - 00403 - 6 Kerberos, A Network Authentication System Brian Tung Edition Addison Wesley ISBN 0- 201 - 37924 - 4 redhat magazine #1 (comptes rseau avec LDAP et Kerberos)

Page 29 / 29