Kerberos (protocole)

Principe du protocole Kerberos

Kerberos est un protocole d'authentification réseau qui repose sur un mécanisme de clés secrètes (chiffrement symétrique) et l'utilisation de tickets, et non de mots de passe en clair, évitant ainsi le risque d'interception frauduleuse des mots de passe des utilisateurs. Créé au Massachusetts Institute of Technology en 1988, il porte le nom grec de Cerbère, gardien des Enfers (Κέρβερος). Kerberos a d'abord été mis en œuvre sur des systèmes Unix. Kerberos dialogue en UDP sur le port 88 par défaut.

Composants et termes

Realm

Le Realm (royaume) est un domaine administratif et non physique. Il définit les limites de contrôle d’un serveur d’authentification. Un utilisateur, un ordinateur hôte ou un service appartiennent tous à un realm. Cependant il est possible d’établir des relations entre realm pour permettre l’authentification entre utilisateurs et services de realm différents.

Le nom du royaume est couramment écrit en lettres majuscules (EXAMPLE.COM) et peut être identique au nom de domaine d’une organisation. Cependant le nom d’un hôte est toujours indiqué avec son nom de domaine complet en plus du nom du royaume : host/[email protected].

Centre de distribution de clé (KDC)

Le centre de distribution de clé est un serveur composé de trois éléments : la base de données, le serveur d’authentification (AS) et le serveur d’attribution des tickets (TGS).

Le serveur d’authentification met en place un secret partagé (TGT) entre un utilisateur et le KDC. Ce secret est temporaire et est établi grâce au mot de passe de l’utilisateur qui permet de prouver son identité. Les services sont également authentifiés auprès de l’AS mais la clé n’expire pas.

Le TGS distribue des tickets de session (TS) entre les utilisateurs authentifiés et les services. L’utilisateur ne communique pas son mot de passe avec le service directement.

Fonctionnement

Dans un réseau simple utilisant Kerberos, on distingue plusieurs entités :

• le client (C), a sa propre clé secrète $K_{C}$
• le serveur (S), dispose aussi d'une clé secrète $K_{S}$
• le service d'émission de tickets (TGS pour Ticket-Granting Service), a une clé secrète $K_{TGS}$ et connaît la clé secrète $K_{S}$ du serveur
• le centre de distribution de clés (KDC pour Key Distribution Center), connaît les clés secrètes $K_{C}$ et $K_{TGS}$

Le client C veut accéder à un service proposé par le serveur S.

La première étape pour le client consiste à s'identifier auprès du centre de distribution de clés (KDC). Le client a une clé secrète $K_{C}$, celle-ci est également connue par le serveur de distribution. Le client envoie son nom au serveur de distribution et lui indique le TGS qui l'intéresse. Après vérification sur l'identité du client (cette partie dépend des implémentations, certains serveurs utilisent des mots de passe à usage unique), le serveur de distribution lui envoie alors un ticket $T_{TGS}$. Ce ticket autorise le client à faire des requêtes auprès du TGS.

Ce ticket $T_{TGS}$ est chiffré par le serveur de distribution avec la clé du TGS ($K_{TGS}$). Il contient notamment des informations sur le client mais également la clé utilisée pour établir la communication entre le client et le TGS. Cette clé de session, nous la noterons $K_{C,TGS}$. Le client reçoit également cette clé de session $K_{C,TGS}$, elle a toutefois été chiffrée avec la clé secrète $K_{C}$ du client.

À ce stade, le client possède un ticket $T_{TGS}$ (qu'il ne peut pas déchiffrer) et une clé $K_{C,TGS}$.

La deuxième étape est l'envoi par le client d'une demande de ticket auprès du TGS. Cette requête contient un identifiant (des informations sur le client ainsi que la date d'émission) chiffré avec la clé de session $K_{C,TGS}$ (qui est trouvée par le client en déchiffrant les informations reçues depuis le serveur de distribution avec sa clé secrète). Le client envoie aussi le ticket qui lui avait été transmis par le serveur de distribution.

Le TGS reçoit alors son ticket et il peut le déchiffrer avec sa clé secrète $K_{TGS}$. Il récupère le contenu du ticket (la clé de session) et peut ainsi déchiffrer l'identifiant que lui a envoyé le client et vérifier l'authenticité des requêtes. Le TGS peut alors émettre un ticket d'accès au serveur. Ce ticket est chiffré grâce à la clé secrète du serveur $K_{S}$. Le TGS envoie aussi ce ticket chiffré avec la clé secrète du serveur $K_{S}$ et la clé de session $K_{C,S}$ chiffrée à l'aide de la clé $K_{C,TGS}$ au client pour les communications entre le serveur final et le client.

La troisième étape est le dialogue entre le client et le serveur. Le client reçoit le ticket pour accéder au serveur ainsi que l'information chiffrée contenant la clé de session entre lui et le serveur. Il déchiffre cette dernière grâce à la clé $K_{C,TGS}$. Il génère un nouvel identifiant qu'il chiffre avec $K_{C,S}$ et qu'il envoie au serveur accompagné du ticket.

Le serveur vérifie que le ticket est valide (il le déchiffre avec sa clé secrète $K_{S}$) et autorise l'accès au service si tout est correct.

Sécurité

Une fois qu'un client s'est identifié, celui-ci obtient un ticket (généralement, un fichier texte - mais son contenu peut aussi être stocké dans une zone de mémoire sécurisée). Le ticket joue le rôle d'une carte d'identité à péremption assez courte, huit heures généralement. Si nécessaire, celui-ci peut être annulé prématurément. Sous les systèmes Kerberos comme celui du MIT, ou de Heimdal, cette procédure est généralement appelée via la commande « kdestroy ».

La sécurité de Kerberos repose sur la sécurité des différentes machines qu'il utilise. Une attaque sur le serveur de clés serait dramatique car elle pourrait permettre à l'attaquant de s'emparer des clés privées des clients et donc de se faire passer pour eux. Un autre problème qui pourrait survenir sur la machine du client est le vol des tickets. Ils pourraient être utilisés par une tierce personne pour accéder aux services offerts par les serveurs (si la clé entre le client et le serveur est connue).

L'expiration du ticket permet de limiter les problèmes liés au vol des tickets. De plus, un ticket peut contenir l'adresse IP du client et le ticket n'est alors valable que s'il est employé depuis cette IP (ce champ est toutefois optionnel dans Kerberos, qui peut tout à fait être utilisé sur un réseau attribuant dynamiquement les IP au travers de DHCP). Une attaque sur les identifiants échouera car Kerberos leur ajoute un élément. Cela évite les attaques par renvoi d'identifiants qui auraient été interceptés. Les serveurs conservent l'historique des communications précédentes et peuvent facilement détecter un envoi frauduleux.

L'avantage de Kerberos est de limiter le nombre d'identifiants et de pouvoir travailler sur un réseau non sécurisé. Les identifications sont uniquement nécessaires pour l'obtention de nouveaux tickets d'accès au TGS.

Actuellement, deux implémentations de Kerberos version 5 existent pour OpenLDAP :

• MIT krb5
• Heimdal

Similitudes

Le fonctionnement de Kerberos est calqué sur ce que pratiquent les ouvreurs et ouvreuses des théâtres et des cinémas :

• au moment d'accéder à la séance de cinéma ou de spectacle, le client paye son ticket qui l'authentifie.
• au point d'accès de la salle, l'ouvreur ou l'ouvreuse déchire le ticket en deux, conserve une partie et laisse l'autre au client.
• en cas de contrôle, on vérifie si les deux morceaux du ticket se recollent.
• la durée de vie du ticket est limitée à une séance.

Utilisations

L'identification Kerberos peut être utilisée par ces protocoles/applications :

• Apache
• Eudora
• FileZilla (version 2)
• MacOS (10.2 et suivants)
• Microsoft Windows (2000 et suivant) l'utilise comme protocole d'authentification par défaut
• NFS
• Openfire utilisé conjointement avec Spark
• OpenSSH
• Oracle
• PAM
• Samba
• SOCKS

Implémentations

Il existe plusieurs implémentations libre ou propriétaire du protocole Kerberos. L'implémentation propriétaire la plus courante est la version de Microsoft Kerberos v5 intégré à Active Directory. Les principales implémentations libres sont les suivantes :

• MIT Krb5
• Heimdal
• GNU Shishi

La version MIT Kerberos est choisie par les distributions Linux « Enterprise » comme Red Hat ou SUSE comme l'unique version Kerberos acceptée pour les paquets supportés. Le projet Samba a initialement choisi Heimdal comme librairie Kerberos pour le support Active Directory. Il y a actuellement des efforts pour remplacer Heimdal par MIT Kerberos. La première version de Samba compilé avec MIT Kerberos est la version 4.7.

Voir aussi

Articles connexes

• GSS-API, la couche d'abstraction permettant notamment d'utiliser Kerberos
• Projet Athena
• Carte à puce
• PKINIT Utilisation de l'authentification forte pour Microsoft
• RADIUS
• TACACS

Notes

Liens externes

• Devensys "Principe de fonctionnement de Kerberos"
• « Linux From Scratch et MIT krb5 »
• (en) Heimdal
• (en) rfc4120 décrivant la version 5 du protocole
• (en) Kerberos: The Network Authentication Protocol
• Note technique de l'ANSSI sur les mots de passe (§5)
• Article de l'ANSII présenté à Rennes dans le cadre de la conférence SSTIC 2014
• (en) Description du protocole par le NIST (§11.2)