Kerberos et la Scurit e e

Emmanuel Bouillon
Commissariat ` lEnergie Atomique a Direction des Applications Militaires BP 12, 91680 Bruy`res-le-Chatel, France e emmanuel.bouillon@cea.fr

Rsum An dvaluer la pertinence de Kerberos dans un contexte e e e donn, il convient de comprendre non seulement lintrt de ce protoe ee cole mais aussi ses limites, y compris en termes de scurit. Cet article e e propose de rappeler bri`vement le fonctionnement du protocole Kerbee ros, puis de dcrire certains probl`mes de scurit qui peuvent se poser e e e e lors de son dploiement. e Les points abords sont regroups en deux catgories : dune part les e e e probl`mes inhrents au protocole lui-mme, dautre part les probl`mes e e e e lis aux dicults pratiques de dploiement. Les aspects de la premi`re e e e e catgorie rappelleront les limitations connues de Kerberos et seront pre e sents ` la lumi`re des implmentations actuelles. Les aspects de la e a e e deuxi`me catgorie aborderont les dicults lies ` la mise en uvre e e e e a de ce protocole, ces dicults pouvant aboutir ` des compromis impace a tant la scurit. e e Les lments prsents dans cet article visent ` aider ` valuer : lapport ee e e a ae de Kerberos dans un environnement donn, la cohrence de cet apport e e au vu des mesures de scurit existantes dans cet environnement et la e e pertinence de cette solution par rapport ` dautres mesures de scurit. a e e

1
1.1

Introduction
Quest-ce que Kerberos ?

Selon la mythologie, Kerberos est le chien ` trois ttes gardant le pont mea e nant aux portes de lenfer. Plus rcemment, Kerberos fut le nom choisi pour le e mcanisme dauthentication dun projet men au MIT appel Athena. Aujoure e e dhui, Kerberos est un protocole dauthentication rseau. La version actuelle du e protocole, la version 5, est un standard dni dans la RFC 1510 [1]. Les versions e 1 ` 3 ne sont restes que des versions de dveloppement. La version 4 est dcrite a e e e dans [2] et [3]. 1.2 Intrts du protocole e e

Peu de mcanismes rsolvent le probl`me de lauthentication rseau unie e e e e e en milieu htrog`ne, qui plus est, mixte Unix/MS Windows. Lutilisation pour ee e

Actes du symposium SSTIC04

lauthentication, des NIS (Network Information Services), de SSH pour la distribution de chiers passwd et shadow, dUIS (Unix Integration Services) service Microsoft qui nest plus support, des SFU (Service For Unix) sous Wine dows, de LDAP, sont des techniques qui sourent toutes de dfauts de mise e en uvre et de scurit. Kerberos prsente lavantage dtre un standard dispoe e e e nible sous les syst`mes libres (Linux, *BSD) et sous les syst`mes propritaires, e e e Solaris (SunMicrosystem), Irix (SGI), Windows 2000 et XP. La portabilit des e implmentations OpenSource permet de complter cette liste. Bien s r, Kere e u beros rsout plusieurs probl`mes de scurit classiques dans lauthentication e e e e des clients et des services au sein dun rseau. Enn, Kerberos est aujourdhui le e principal mcanisme de scurit sous-jacent support dans les implmentations e e e e e e de la GSSAPI [4,5]. Cette API tant la base des RPCSEC GSS, mcanisme e dsign pour scuriser la prochaine version de NFS (version 4, [6]). e e e 1.3 Objectif de cet article

Pour mieux valuer la pertinence de ce protocole dans un contexte donn, il e e convient den comprendre non seulement les avantages mais aussi les limites, y compris en termes de scurit. Cet article propose de rappeler le fonctionnement e e du protocole Kerberos, puis de dcrire certains probl`mes de scurit qui peuvent e e e e se poser lors du dploiement de Kerberos. Les points abords sont regroups en e e e deux catgories : e Les probl`mes inhrents au protocole lui-mme ; e e e Les probl`mes lis aux dicults pratiques de dploiement. e e e e Dans la suite, une application sera dite kerbrise pour signier quelle e e supporte le protocole Kerberos.

2
2.1

Le protocole Kerberos
Caractristiques du protocole e

Le protocole Kerberos se base sur les deux articles [7] et [8]. Il permet lauthentication des utilisateurs et des services sur un rseau suppos non s r. Par e e u exemple, les donnes sur ce rseau peuvent tre lues ou modies, les adresses e e e e des machines peuvent tre fausses. Ces informations ne peuvent donc servir e e a ` lauthentication. Kerberos utilise une tierce partie de conance. Toutes les entits du rseau, utilisateurs et services, appels principaux, font conance ` e e e a cette tierce partie (le serveur Kerberos ou KDC pour Key Distribution Center). Enn, Kerberos utilise des mcanismes de chirement bass sur des algorithmes e e a ` clef symtrique (ou secr`te) : tous les principaux partagent cette clef secr`te e e e avec le serveur Kerberos. 2.2 Fonctionnement dtaill : de lauthentication par secret e e partag ` Kerberos v5 ea

Dans toute la suite, Alice (A) sera lentit qui initie la communication (anae logie avec le client, lutilisateur), Bob (B) lentit qui rpond (analogie avec le e e

Actes du symposium SSTIC04

service, serveur applicatif). Kab sera la clef partage entre Alice et Bob (on a e Kab = Kba ). Authentication par secret partag Kerberos utilise des algorithmes de e chirement ` clef secr`te pour lauthentication. La mani`re la plus simple de a e e faire de lauthentication ` laide de tels algorithmes est la suivante : a 1. Alice appelle Bob 2. Bob rpond ` Alice avec un nombre gnr alatoirement, Nb e a e e e e 3. Alice retourne Kab {Nb } A lissue de cet change, Bob en dchirant la rponse de Alice, vrie que e e e e Alice conna bien la clef secr`te Kab . Pour une authentication mutuelle, Alice t e met ` son tour un nombre alatoire (Na ) que Bob retourne chir par Kab . e a e e Une autre mthode pour lauthentication mutuelle ` laide dun algorithme e a a ` clef secr`te est de faire envoyer par Bob, non pas un nombre alatoire, mais ce e e nombre chir par Kab . Alice dchire ce message, eectue une opration triviale e e e sur le nombre obtenu et le renvoie chir. On obtient le schma suivant : e e 1. Alice appelle Bob 2. Bob envoie Kab {Nb } 3. Alice dchire le message, obtient Nb et envoie Kab {Nb 1} e 4. Alice envoie Kab {Na } 5. Bob dchire le message, obtient Na et envoie Kab {Na 1} e Ce qui, en regroupant les messages indpendants, donne (schma 1) : e e 1. Alice envoie Kab {Na } 2. Bob dchire le message, obtient Na , envoie Kab {Na 1} et Kab {Nb } e 3. Alice dchire le message, obtient Nb et envoie Kab {Nb 1} e Cest ce schma qui appara dans le protocole de Needham et Schroeder [7]. e t Avec une amlioration toutefois : e Utilisation dune tierce partie de conance Lun des inconvnients majeurs e du schma 1 est son manque dextensibilit. La gnralisation ` m utilisateurs et e e e e a n services, implique la distribution pralable de m n clefs partages. Une solue e tion ` cette problmatique est lintroduction dune tierce partie de conance (une a e autre solution est lutilisation dun algorithme de chirement asymtrique pour e ngocier une clef de session symtrique). Cette tierce partie (TP) de conance e e conna les secrets partags de chaque entit ` authentier (Ka pour Alice, Kb t e ea pour Bob). Lauthentication mutuelle peut alors se faire comme suit : 1. Alice demande ` TP daccder ` Bob a e a 2. TP gn`re une clef de session entre Alice et Bob, Kab e e 3. TP envoie Ka {Kab , Bob} ` Alice et Kb {Kab , Alice} ` Bob a a

Actes du symposium SSTIC04

A ce niveau, on peut appliquer le schma 1 pour lauthentication mutuelle e par algorithme ` clef secr`te. En eet, Alice connaissant Ka , peut en dduire a e e Kab . De mme, Bob connaissant Kb peut en dduire Kab . e e On remarque cependant que pour la distribution de Kab , Alice, le client envoie un message alors que la tierce partie commune ` tous les utilisateurs en a envoie deux. On prf`re en gnral faire porter la charge sur le client et non ee e e sur la tierce partie qui doit grer tous les clients. On modie donc lg`rement le e e e schma prcdent qui devient : e e e 1. Alice demande ` TP daccder ` Bob a e a 2. TP gn`re une clef de session entre Alice et Bob, Kab e e 3. TP envoie Ka {Kab , Bob} et Kb {Kab , Alice} ` Alice a 4. Alice appelle Bob et lui envoie Kb {Kab , Alice} Alice, qui ne conna pas Kb , ne peut rien faire de Kb {Kab , Alice} si ce nest t lenvoyer ` Bob. Cette information est le ticket pour dialoguer avec Bob. a On abouti alors au schma de Needham et Schroeder, le nombre alatoire N1 , e e envoy avec la premi`re requte nest l` que pour rendre unique cette requte et e e e a e sa rponse pour viter des attaques de type rejeu. e e 1. Alice demande ` TP daccder ` Bob et joint N1 a e a 2. TP gn`re une clef de session entre Alice et Bob, Kab e e 3. TP envoie Ka {N1 , Kab , Bob, T icketb} ` Alice, o` T icketb = Kb {Kab , Alice} a u 4. Alice dchire la rponse, en tire T icketb et Kab e e 5. Alice appelle Bob avec T icketb et Kab {Na } (schma 1) e 6. Bob dchire le Ticket, en tire Kab , rpond avec Kab {Na 1, Nb } e e 7. Alice rpond avec Kab {Nb 1} e Kerberos Le protocole Kerberos amliore le schma de Needham et Schroeder e e dune part en remplaant les nombres alatoires par des dates (timestamps), c e dautre part en sparant le rle de la tierce partie de conance en deux services : e o Le service dauthentication (AS pour Authentication Service) Le gnrateur de ticket de service (TGS pour Ticket Granting Service) e e Lutilisation des timestamps permet dintroduire la premption de ticket et e de rduire la fentre de temps pendant laquelle le rejeu de ticket est possible. e e Ce type dattaque est surtout empch par lutilisation dun cache stockant les e e authenticateurs reus et dont la date de validit na pas expir. On note que c e e cette proprit introduit une dpendance entre Kerberos et le service de temps. ee e La sparation du rle du KDC en deux services induit deux types de ticket e o dirents : e Le TGT (Ticket Granting Ticket) est envoy par lAS. Une demande de e TGT est en fait une demande dacc`s au service TGS. Le TGT est donc le e ticket du service TGS. La rponse de lAS contient aussi la clef de session e entre le client (A) et le service TGS (Ka,tgs ) chire par la clef secr`te du e e client (Ka ).

Actes du symposium SSTIC04

Le TS (Ticket Service) pour un service donn (S) est envoy par le TGS sur e e prsentation dun TGT et dun timestamps chir avec la clef de session e e Ka,tgs . Le TGS sait donc que le client a pu dchirer la rponse de lAS e e et donc conna la clef secr`te Ka . Le TGS gn`re une clef de session entre t e e e A et S, Ka,s . La rponse du TGS contient donc notamment, cette clef de e session chire par Ka,tgs (A pourra ainsi la dduire) et le TS proprement e e dit, constitu, entre autre, de Ka,s chir par Ks , la clef secr`te du service e e e S (S, sur prsentation de ce ticket pourra en dduire Ka,s ). e e La mme clef Ka,tgs permet dobtenir les clefs de session des services accds e e e pendant toute la validit du TGT. Le principal avantage de cette sparation e e des rles du KDC est de permettre le SSO (Single Sign On). En eet, seul o lexploitation du TGT ncessite lutilisation de la clef secr`te du client. Ainsi, e e tant que son TGT est valide, le client pourra acqurir des TS sans rutiliser sa e e clef, qui est directement dduite du mot de passe dans le cas dun utilisateur. e Cette proprit, couple avec la possibilit de rendre le TGT forwardable, cestee e e a `-dire rutilisable une fois connect au service, permet ` Kerberos de fournir un e e a SSO.

La pr-authentication Au cours du dialogue prcdent, on constate quil e e e nest pas ncessaire de conna Ka pour obtenir de la tierce partie de conance e tre un TGT et un message chir par Ka . Il sut de le demander ` lAS pour e a lobtenir. La pr-authentication rsout ce probl`me. Elle exige que la requte ` lAS, e e e e a mise par le client, soit accompagne dun timestamp chir par Ka . LAS peut e e e ainsi valider que la requte mane bien dune entit connaissant sa clef secr`te. e e e e

2.3

Les relations de conance inter-royaume

Kerberos prvoit la possibilit quun principal puisse sauthentier aupr`s e e e de principaux nappartenant pas ` son royaume : Il sagit de lauthentication a inter-royaume. Cela implique dtablir une relation de conance entre les deux e royaumes. Cette relation peut tre unilatrale ou bilatrale. e e e Deux mthodes sont possibles pour tablir une telle relation. e e Mthode directe Les deux KDC partagent une clef secr`te utilise pour proue e e ver lidentit dun principal lorsquil change de royaume. Linconvnient de e e cette mthode est son manque dextensibilit. La gnralisation ` n royaumes e e e e a impose lchange de n (n 1)/2 clefs ou n (n 1) clefs dans le cas de e relations bilatrales. Ceci peut tre rsolu par lutilisation de la mthode e e e e transitive. Mthode transitive Dans ce cas, on dnit le chemin des royaumes partageant e e une clef secr`te. Ce chemin peut tre soit explicite (mcanisme des CApath, e e e Certicate Authority Path) soit hirarchique via le DNS. e

Actes du symposium SSTIC04

Kerberos et la scurit e e

Cette partie rappelle certains des probl`mes de scurit qui peuvent tre e e e e rencontrs au cours du dploiement de Kerberos sur un rseau. e e e 3.1 Probl`mes inhrents au protocole e e

Les probl`mes dcrits ci-apr`s sont connus de longue date. Pour certains, Dug e e e Song [9] notamment a dmontr la faisabilit de leur exploitation. Lobjectif de e e e ce paragraphe est den rappeler le principe et de montrer que sans prcaution, ces e attaques sont toujours valables dans les implmentations actuelles du protocole. e Attaque par dictionnaire et pr-authentication Dans la version 4 du e protocole, le mcanisme de pr-authentication ntait pas prvu. Nimporte qui e e e e pouvait obtenir un message chir avec la clef secr`te dun utilisateur donn. e e e Toute la scurit reposait sur lincapacit de dduire la clef secr`te de ce message. e e e e e Bien s r, compte tenu de la propension des utilisateurs ` choisir des mots de u a passe faibles, une attaque par dictionnaire avait clairement de fortes chances dtre fructueuse. e Sans pr-authentication, crire un outil qui ferait lquivalent dun ypcat e e e passwd avec les NIS ne pose pas de dicults. e D`s lors, adapter un outil de craquage de mots de passe pour lui permettre e dattaquer ces messages chirs est assez simple. Dug Song propose un patch e pour John the Ripper [10] et la version 4 de Kerberos. Avec lav`nement de e la version 5 de Kerberos et lapport de la pr-authentication, la conscience de e cette faiblesse du protocole sest estompe. Les documentations insistent peu sur e son utilit. Il convient alors de faire les remarques suivantes sur ce sujet : e La pr-authentication nest pas active par dfaut sur nombre dimple e e e mentations du protocole. Elle est notamment impossible si lon souhaite une compatibilit avec Kerberos version 4. e Lactivation de la pr-authentication diminue le risque mais ne llimine e e pas puisque dans le cas dune authentication licite, le message chir peut e tre lu sur le rseau. Modier un snier ` cette n est simple. e e a Adapter un outil de craquage de mot de passe ` la version 5 du protocole a est simple. En consquence, il est important de rappeler que la pr-authentication est e e une option indispensable ` la scurit de Kerberos mais nlimine pas compl`a e e e e tement le risque dattaque par dictionnaire tant que la clef secr`te sera drive e e e dun mot de passe statique choisi par lutilisateur. La mise en place de mesures assurant la robustesse des mots de passe choisis par les utilisateurs est un moyen ecace de lutter contre ce probl`me. Le support e par Kerberos dalgorithmes de chirement asymtrique (PKINIT [11]) coupl e e avec lutilisation dun deuxi`me facteur pour lauthentication, une carte ` puce e a par exemple, supprimerait le risque dune telle attaque. Esprons que les eorts e actuels pour lintgration de PKINIT et de la pr-authentcation matrielle e e e aboutiront rapidement.

Actes du symposium SSTIC04

Usurpation du KDC Cette deuxi`me attaque a aussi t mise en vidence par e ee e Dug Song notamment. Le but de ce paragraphe est den expliquer le principe, de donner les moyens de sen protger et leurs limites, ceux-ci ntant que rarement e e prconiss dans les documentations. e e Fondamentalement, Kerberos permet dauthentier un utilisateur aupr`s dun e service kerbris et rciproquement. Cependant, on peut dans le cadre du de e e e ploiement de Kerberos, utiliser ce protocole comme point dentre sur un rseau, e e cest-`-dire au niveau de lauthentication syst`me. a e Le moyen le plus simple pour y parvenir est lutilisation dun module PAM, dautres font excuter la commande kinit ` la connexion de lutilisateur ou e a encore changent la commande de login. Dans le cas de lutilisation dun module PAM, le syst`me se sert de la capacit ` dchirer la rponse du KDC avec le mot e ea e e de passe fourni par lutilisateur pour lauthentier. Il ne sagit pas dune relle e authentication Kerberos aupr`s dun service. Le dfaut de cette conguration e e est quil ny pas authentication de la rponse du KDC. La requte et lanalyse e e de sa rponse sont faites par le client. Si la clef donne par lutilisateur permet e e de dchirer le TGT obtenu, lutilisateur est autoris ` se connecter et poss`de e ea e un TGT. Ce nest que sil cherche ` accder ` un service kerbris quil sen a e a e e servira pour faire une demande de TS. Ce manque dauthentication de la rponse du KDC permet une attaque par e usurpation du KDC si lon a la possibilit dcouter et dinjecter du trac entre e e le syst`me cible et le KDC. Si la seule prsentation dun TGT correspondant ` la e e a clef secr`te fournie au login permet de se connecter ` un syst`me, il est possible e a e de contourner cette authentication comme suit : 1. Lattaquant se connecte au nom de la victime en entrant un mot de passe quelconque 2. Le syst`me met une requte de TGT e e e 3. Lattaquant rpond en utilisant la clef drive du mot de passe quil a luie e e mme fournie au syst`me e e 4. La rponse peut tre dchire par la clef : lutilisateur est autoris ` se e e e e e a connecter Bien s r, le TGT ainsi obtenu ne permettra pas dobtenir de TS valide. Mais u une fois connect, lutilisateur peut accder au disque et ` tous les services non e e a kerbriss (Home en NFSv3 non kerbris par exemple). e e e e Une contre-mesure pour cette attaque est de vrier lauthenticit de la e e rponse du KDC en demandant un TS avec ce TGT pour le service host du e syst`me local et den vrier la validit. Si la rponse est valide, le KDC partage e e e e non seulement la clef secr`te de lutilisateur mais aussi celle du service host du e syst`me. Il est ` noter que le module PAM Kerberos le plus utilis [12] prvoit e a e e cette fonctionnalit mais elle nest pas documente. e e Kerberos et son environnement On dcrit parfois Kerberos comme un proe tocole faisant peu dhypoth`ses sur la scurit du rseau o` il est dploy. Il e e e e u e e

Actes du symposium SSTIC04

convient cependant de comprendre les consquences dune compromission mme e e partielle du rseau sur lauthentication. e La compromission, au niveau adminstrateur, dune machine quelconque du rseau aboutit ` la compromission des clefs des services de cette machine et e a des tickets des utilisateurs qui y sont connects. Lattaquant peut alors usurper e lidentit : e des services de cette machine tant que leurs clefs ne sont pas changes e des utilisateurs authentis sur cette machine pendant la dure de validit e e e de leurs tickets Linstallation dun cheval de Troie pourra aboutir ` la compromission de mots a de passe des utilisateurs, rendant lusurpation de leur identit possible jusquau e changement de leur mot de passe. En consquence, le dploiement de Kerberos ne e e permet pas de sabstenir dautres mesures lmentaires de scurit comme linsee e e tallation des mises ` jour de scurit. Enn, dans un environnement kerbris, a e e e e la compromission dune seule machine spcique, un KDC, conduit au contrle e o total par lattaquant de tous les authentiants de entits Kerberos (utilisateurs e et services) de ce royaume. On comprend la ncessit de scuriser avec soin les e e e machines assurant cette fonction et aussi de cloisonner les dirents groupes e dutilisateurs dans des royaumes dirents. e Kerberos et lautorisation Lobjectif dune solution de scurit est de sate e taquer ` la problmatique des trois A (Authentication, Autorization, Accouna e ting). Kerberos cherche ` rsoudre le probl`me du premier A, lauthentication. a e e Il fournit au service lassurance que lutilisateur qui se prsente ` lui est bien e a celui quil prtend tre (` la scurit de la clef secr`te pr`s). Rciproquement, e e a e e e e e lutilisateur sait quil sadresse bien au service escompt (` la scurit du e a e e chier keytab pr`s). De plus, en centralisant les demandes (choues ou russies) e e e e de connexions des clients aux services, Kerberos permet de tracer prcisment e e lacc`s de qui ` quoi. Il participe ainsi ` la traabilit, le troisi`me A. Par e a a c e e contre, Kerberos ne participe pas au processus dautorisation. Celui-ci revient au service, conant dans lidentit de son client. Cependant, les services clase siques des implmentations de Kerberos, ne fournissent pas de mcanisme daue e torisation gnrique. Lutilisation ` des ns dautorisation du chier .k5login e e a est limite. Lintgration du support des PAM, par exemple, est dicile compte e e tenu principalement du fait que ce mcanisme ne garantit pas la distinction entre e authentication et autorisation. 3.2 Probl`mes lis aux dicults pratiques de dploiement e e e e

Kerberos peut amliorer notablement la scurit dun rseau. Cependant son e e e e dploiement est dicile, ` tel point quon le dconseille parfois [13] : e a e In our opinion, most sites are better o without it [sic]. Ces dicults aboutissent souvent ` un compromis entre la meilleure solution e a du point de vue de la scurit et les contraintes dadministration oprationnelle. e e e Ce paragraphe prsente une liste non exhaustive de dicults pratiques qui e e

Actes du symposium SSTIC04

peuvent tre rencontres lors du dploiement de Kerberos et dont les solutions e e e ou contournements auront des consquences sur la scurit. e e e ` Installation via le rseau A son installation, la machine nest pas kerbrise. e e e Ce processus automatique ne peut donc pas compl`tement tre scuris par Kere e e e beros. Un moyen de distribuer les chiers keytab dune machine est dutiliser la commande kadmin, de donner le mot de passe dun principal privilgi et dexe e traire le chier keytab. Toute solution enti`rement automatique aboutit ` un e a certain niveau dexposition du chier keytab. Il est videmment des environnee ments o` lintervention dun administrateur ` chaque (r-)installation nest pas u a e envisageable. Acc`s ` un service sans mot de passe Plusieurs tches dadministration e a a classiques ncessitent lacc`s ` un service sans fournir de mani`re interactive laue e a e thentiant de lidentit utilise. De telles procdures sont bien videmment die e e e cilement compatibles avec une mthode dauthentication s re. Citons quelques e u exemples : Excution de procdures automatiques : e e Lobtention dun TGT ncessite toujours lutilisation de la clef secr`te du e e principal concern. Si une procdure automatique a besoin daccder ` un e e e a service kerbris (un script en crontab par exemple), comment lui faire e e obtenir un TGT puis un TS pour ce service. Plusieurs solutions ont t ee proposes pour rsoudre ce probl`me [14,15]. Elles correspondent chacune e e e a ` un compromis entre la scurit et la faisabilit. e e e Dpannage des utilisateurs : e Il est parfois ncessaire ` un administrateur de prendre lidentit dun e a e utilisateur, par exemple pour dboguer un probl`me quil narrive pas ` e e a reproduire dans son environnement. Que faire si ce probl`me ncessite e e lacc`s ` un service kerbris. Comment ladministrateur peut-il obtenir e a e e un TGT au nom de lutilisateur ? Une solution vidente pour les implmentations qui utilisent un cache de tie e cket local sur le disque dur est dutiliser ce chier sous root. Ceci ncessite e toutefois que lutilisateur soit simultanment connect. Cette contrainte e e peut tre juge trop importante. Dans ces conditions, comment un utilisae e teur peut obtenir le TGT dun autre utilisateur ? Fondamentalement, un administrateur du KDC est omnipotent sur tous les principaux. Il peut donc obtenir un TGT pour un utilisateur. Cependant, certaines implmentations rendent ceci compliqu si lon ne soue e haite pas rinitialiser le mot de passe de lutilisateur. Cest le cas pour e limplmentation du MIT, pas pour Heimdal. De plus, la population des e administrateurs des KDC nest pas ncessairement la mme que celle qui e e dpanne les utilisateurs. e Excution de commandes en mode batch : e Cette problmatique regroupe les deux dicults prcdentes puisquil e e e e sagit pour un processus syst`me dexcuter des commandes de mani`re e e e

10

Actes du symposium SSTIC04

automatique, au nom dun utilisateur quelconque. Situation que lon peut rencontrer au niveau de lordonnancement dun serveur de calcul parall`le e par exemple. [16] notamment propose une solution. Les relations interroyaume peuvent aussi tre utilises ecacement. Cela revient toutefois ` e e a dnaturer la scurit de Kerberos en redonnant aux administrateurs une e e e partie de leur pouvoir. Relation de conance unilatrale et ticket forwardable Etablir une e relation de conance inter-royaume est le moyen souvent prconis pour pere e mettre ` un utilisateur authenti dans un royaume (ROYAUME-1) daccder a e e a ` un service dun autre royaume (ROYAUME-2). Ceci implique que les responsables de ROYAUME-2 font conance dans lauthentication et la scurit mise e e en place dans ROYAUME-1. Si cette conance nest pas rciproque, il convient e de ne mettre en place quune relation de conance inter-royaume unilatrale : e Un utilisateur avec un TGT de ROYAUME-2 ne pourra pas obtenir un TS pour un service du ROYAUME-1. Comme rappel prcdemment, loption forwardable dun ticket permet e e e dobtenir un SSO. Par exemple, ` chaque rebond de machine en machine, cest-`a a dire ` chaque obtention de TS, le TGT est dupliqu sur la machine cible. Ainsi, le a e mot de passe de lutilisateur na pas ` tre fourni de nouveau, lauthentication ae Kerberos est toujours possible. Cest pourquoi cette option est si prise des e utilisateurs quand il sagit du service host/machine. Cependant, si cette option est active dans ROYAUME-1 et accepte e e dans ROYAUME-2, le TGT dun utilisateur authenti dans ROYAUME-1 et e accdant ` un service de ROYAUME-2 sera dupliqu sur la machine cible. D`s e a e e lors, un administrateur de ROYAUME-2 peut accder au TGT de cet utilisateur. e Ainsi, la relation de conance unilatrale entre ROYAUME-2 et ROYAUME-1 e ncessite toutefois, dans ces conditions (ticket forwardable et donc intgration e e dans le SSO de ROYAUME-1), que les responsables de ROYAUME-1 fassent conance aux administrateurs de ROYAUME-2. Ce qui fait nettement voluer e la signication de la relation de conance unilatrale. e Protection des administrateurs Les points prcdents conrment une fois de e e plus que les administrateurs occupent une place cruciale pour la scurit dun e e rseau, quand bien mme kerbris. Les eorts consentis pour le dploiement e e e e e de Kerberos doivent donc tre en rapport avec ceux ddis ` la protection des e e e a administrateurs et de leurs stations de travail. Les premiers seraient inutiles si les homes des administrateurs sont exports par NFS ` tous et leurs displays e a accessibles, par exemple. Authentication applicative Le support de lauthentication syst`me via e Kerberos est maintenant largement rpandu. Son dploiement peut donc tre e e e envisag mme en environnement htrog`ne. Cependant, le syst`me dexploitae e ee e e tion nest souvent pas lunique partie du syst`me dinformation o` une authentie u cation est requise. Lacc`s au mail, via les protocoles POP ou IMAP, doit tre e e

Actes du symposium SSTIC04

11

pris en considration. Lacc`s ` une base de donnes ou a une appplication Web e e a e ` par exemple, peut exiger une authentication supplmentaire ou simplement la e mme mais renouvele pour accorder son acc`s. e e e Dans le cas dune authentication renouvele, cest-`-dire o` lapplication e a u utilise le mme protocole que lauthentication syst`me, il est vident que le e e e dploiement de Kerberos aura des consquences sur le fonctionnement de lape e plication. Mme si des standards, le plus souvent bass sur la GSSAPI, voient e e progressivement le jour [17,18], leur intgration nest jamais transparente. Cet e impact est donc ` prendre en compte d`s lorigine du projet de dploiement. Dans a e e le cas dune authentication applicative reposant sur un protocole dirent, le e probl`me repose de nouveau sur la cohrence des mcanismes de scurit mis e e e e e en uvre. Par exemple, si les deux mthodes dauthentication reposent sur un e mot de passe au choix de lutilisateur, le mcanisme dauthentication le plus e faible aaiblit le plus fort compte tenu de la probabilit dun choix identique e pour ces mots de passe.

Compatibilit des implmentations Le protocole Kerberos dans sa vere e sion 5 est un standard bien dni [1]. Lors de son dploiement se pose la quese e tion du choix dune ou plusieurs implmentations de ce protocole. Certaines e sont OpenSource comme limplmentation du MIT ou Heimdal, dautres proe pritaires comme SEAM, fournie par Sun Microsystem ou Active Directory. Deux e catgories de probl`mes peuvent appara : e e tre Les incompatibilits avec le protocole lui-mme : limplmentation est-elle e e e respectueuse de la RFC de Kerberos, de la RFC de la GSSAPI ? Les incompatibilits entre implmentations si le choix a t fait den utilie e ee ser plusieurs : notamment, des probl`mes peuvent appara au niveau de e tre lAPI dadministration, du changement de mot de passe, des relations dapprobation et des algorithmes supports. Sur ce dernier point par exemple, e pour tablir une relation dapprobation entre un KDC MIT et un KDC e Windows 2000 Server SP4, il est ncessaire de dgrager la liste des algoe e rithmes supports. Un tel contournement a videmment un impact sur la e e scurit. Ce probl`me est rsolu avec un KDC sous Windows 2003. e e e e

Conclusion

Kerberos ore un moyen puissant et ecace de scuriser un rseau. Son e e adoption par un grand nombre de syst`mes dexploitation est gage de prennit. e e e Nanmoins, il est important den conna le fonctionnement, les limites ainsi e tre que les dicults de son dploiement et de son administration. Ces derni`res poue e e vant ventuellement aboutir ` des compromis impactant la scurit. On pourra e a e e alors apprhender de mani`re cohrente la scurit dun rseau et viter le danger e e e e e e e den survaluer le niveau. e

12

Actes du symposium SSTIC04

Rfrences ee
1. J. Kohl et B. Cliord Neuman, The Kerberos Network Authentication Service (Version 5), Internet Request for Comments RFC 1510, septembre 1993. 2. B. Cliord Neuman et T. Tso, Kerberos : An Authentication Service for Computer Networks, IEEE Communications, Vol. 32, number 9, pp. 33-38, septembre 1994. 3. J. Kohl, B. Cliord Neuman et T. Tso, The Evolution of the Kerberos Authentication System In Distributed Open Systems, IEEE Computer Society Press, pp. 78-94, 1994. 4. E. Bouillon et P. Deniel, Premiers pas avec la GSSAPI, Linux Magazine, volume 52, juillet 2003. 5. J. Linn, The Kerberos Version 5 GSS-API Mechanism, Internet Request for Comments RFC 1964, juin 2001. 6. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler et D. Noveck, Network File System (NFS) verion 4 Protocol, Internet Request for Comments RFC 3050, avril 2003. 7. R. Needham et M. Schroeder, Using Encryption for Authentication in Large Networks of Computers, Communications of the ACM, Vol. 21, number 12, pp. 993999, dcembre 1978. e 8. D. Denning et G. Sacco, Time stamps in Key Distribution Protocols, Communications of the ACM, Vol. 24 numro 8, pp. 533-536, aot 1981. e u 9. http://www.monkey.org/~dugsong/ 10. http://www.openwall.com/john 11. B. Tung, C. Neuman, M. Hur, A. Medvinski, J. Wray et J. Trostle, Public Key Cryptography for Initial Authentication in Kerberos, IETF Internet-Draft. 12. http://sourceforge.net/projects/pam-krb5/ 13. E. Nemeth, G. Snyder, S. Seebass et T. Hein, Unix system administration Handbook, Prentice Hall, 3`me dition, 2001. e e 14. Kerberos FAQ, kerberos-faq.html http://www.cmf.nrl.navy.mil/CCS/people/kenh/

15. I. Hollander, P. Rajaram, et C. Tanno, Morgan Stanley & Co, Kerberos on Wall street, Usenix, 1996. 16. A. Rubin et P. Honeyman, Long Running Jobs in an Authenticated Environment, Usenix, 1993. 17. E. Baize et D. Pinkas, The Simple and Protected GSS-API Negotiation Mechanism, Internet Request for Comments RFC 2478, dcembre, 1998. e 18. R. J. Detry, S. D. Kleban et P. C. Moore, The Generalized Security Framework, http://www.prod.sandia.gov/cgi-bin/techlib/access-control.pl/ 2001/018338.pdf, juin 2001.