8 Kerberos

8.1 implémentation.

Développé (circa 1988) au MIT [47, 19], Kerberos est le protocole d'identification du projet Athena [25] (10 000 terminaux et 1 000 serveurs). Il a été porté dans d'autres réseaux de taille comparable.

8.2 objectifs.

Le premier objectif est de faire face à la taille du réseau. Il faut donc que l'identification ne constitue pas un goulet d'étranglement. Par ailleurs les mots_de_passe étant la cible préférée des attaques, ils ne doivent pas rester mémorisés dans le terminal durant la session et encore moins être demandés à l'utilisateur plus d'une fois par login.

8.3 chiffrement.

A clef secrète (DES)

8.4 hypothèses.

Terminaux sans disque, et surtout à espace-mémoire non-partagé. Aucune menace due à un partage de l'espace d'adressage, ou à un rpc et encore moins à rlogin n'est donc à craindre sur les terminaux.

Le protocole nécessite des horloges synchronisées à 5 mn de tolérance maximale sur l'ensemble du site.

8.5 déroulement.

Deux avatars d'un même scénario se succèdent. Le premier, décrit Table 8 est joué au moment du login du principal P. La centrale d'identification S est Kerberos, et Q désigne un serveur particulier, le "Ticket Granting Server" (TGS). P et S (=Kerberos) justifient mutuellement de leur identité par la connaissance du mot de passe (Wp) de P, qui recueille un ticket (ti_gti) d'introduction auprès de TGS. Puis P et Q (=TGS) justifient mutuellement de leur identité par la connaissance de la clef de session ks, connaissance prouvant à son tour la connaissance par l'un de Wp et par l'autre de Wtgs.

Table 8: Dialogue avec Kerberos.

1	$P\hookrightarrow S$	$P, Q, X$
	$S$	ti_tgi = $\left\{ P, Ttl\_ks, ks\right\} _{Wq}$
2	$S\hookrightarrow P$	$\left\{ Ts, Q, ks, ti\_tgi\right\} _{Wp}$
3	$P\hookrightarrow Q$	ti_tgi, $\left\{ Tp, P\right\} _{ks}$, question
4	$Q\hookrightarrow P$	$\left\{ Tp+1\right\} _{ks}$, réponse

Puis, tant que P ne se délogue pas, c'est la version de la Table 9 qui est jouée : la centrale d'identification S est désormais le TGS, et Q désigne un quelconque autre serveur. P et S (=TGS) justifient mutuellement de leur identité par la connaissance du ks affecté à P, qui recueille un ticket d'introduction auprès du serveur Q. La suite du dialogue est inchangée.

Table 9: Dialogue avec le TGS.

1	$P\hookrightarrow S$	ti_tgi, $\left\{ Tp, P\right\} _{ks}$, requete
	$S$	ticket = $\left\{ P, Ttl\_k, k\right\} _{Wq}$
2	$S\hookrightarrow P$	$\left\{ Ts, Q, k, ticket\right\} _{ks}$
3	$P\hookrightarrow Q$	ticket, $\left\{ Tp, P\right\} _{k}$, question
4	$Q\hookrightarrow P$	$\left\{ Tp+1\right\} _{k}$, réponse

On remarque l'utilisation de l'horloge répartie pour définir la plage de validité (= time to live) attribué soit au ti_gti soit aux tickets ordinaires. Cette plage n'a aucun besoin d'être mesurée avec précision : une erreur de l'ordre de 10% serait tout à fait tolérable et n'engendrerait pas grand trouble.

8.6 critique.

Les critiques qui suivent ont été formulées soit par des auteurs proches du groupe Kerberos [3]... soit par les auteurs du protocole eux-mêmes lors des révisions successives [19].

1. L'horloge répartie est utilisée pour fabriquer les nonces désignés par Ts et Tp dans les Table 8 et Table 9. Constituant la seule partie récente du message dans lequel ils apparaissent, ils servent à prouver l'identité de S et de P. Ce choix est sujet à controverse. Nous ne sommes pas pour notre part convaincus de ce qu'il s'agisse d'un choix heureux, et nous donnons les raisons de cette opinion dans l'annexe A9.
2. La configuration matérielle sur laquelle Kerberos est fondé est loin d'être standard : dans le monde Unix, la règle est bien plutôt aux stations de travail possédant par elles-mêmes des fichiers et des processus (démons divers), ayant eux aussi besoin d'être identifiables. Or le stockage d'un password dans une machine physiquement accessible est loin d'être simple. Il faudrait quelque chose en ROM qui s'exécute au moment du boot, et cesse d'être lisible par la suite, comme cela existe dans le BIOS des PC-486.
3. Par ailleurs, sur des stations multi-utilisateurs, et accessibles par rlogin, il n'est pas bien certain que les clefs de session (obtenues par un utilisateur pour s'identifier avec les différents serveurs, et valables environ une journée) soient à l'abri des autres utilisateurs logués sur la même station. Or il est clair que la possibilité de rlogin, ou en tout cas de rpc doit être maintenue, ne serait-ce que pour pouvoir collecter, en tâche de fond, la puissance de calcul de tout un campus pour mener des simulations chronophages.
4. L'attaque systématique contre les passwords n'est pas traitée, au contraire. Les demandes de ti_gti se font en clair, et la réponse de Kerberos contient tout ce qu'il faut de texte vérifiable pour que des écoutes passives permettent de recueillir l'équivalent de /etc/password puis de procéder aux attaques habituelles [42].
5. Kerberos utilise le DES-PCBC dans l'intention de réaliser en une seule étape un checksum cryptographique en plus d'un chaînage des blocs. Or le DES-PCBC ne permet pas de réaliser cet objectif. Au contraire même (pour une discussion détaillée, se reporter à notre annexe G7.b).
6. La version 4 de Kerberos ne permettait pas les délégations d'identité. Pour envoyer un fichier depuis un serveur de fichier vers une imprimante distante, il est pourtant plus commode de déléguer ses droits au serveur de fichier pour qu'il présente le tout au serveur d'impression plutôt que de devoir tout gérer soi-même, à grand renfort de tickets. La version 5 traite cette question.

8.7 conclusion.

Ce protocole constitue une référence majeure, et il est bien clair que tout intrus capable de passer outre ce protocole serait a fortiori capable de passer à travers tout autre protocole actuellement publié.