Kerberos est un service d’authentification permettant d’accéder à des ressources sur réseau, en se reposant sur un mécanisme de distribution de clés symétriques. Il est utilisé notamment par Windows pour le service d’Active Directory. Le Kerberos Consortium gère ce projet en accès libre.

Différence entre Kerberos et NTLM

NTLM était utilisé autrefois par Windows. Il fonctionnait à la façon classique d’un mot de passe, avec stockage en base du mot de passe que l’utilisateur devait fournir pour s’authentifier. La principale différence entre les deux systèmes est la vérification tierce partie et la capacité de chiffrement plus efficace de Kerberos. 

Voici le principe d’une authentification via Kerberos.

Faut s’accrocher un peu pour comprendre. En gros, le client (C) peut se connecter au serveur (S) sans rien connaître de (S). Tout passe par une infrastructure tierce, appelée Centre de Distribution de Clés (KDC) qui comprend un serveur d’authentification et un serveur d’émission de tickets.

En termes imagées, le client va auprès d’un bureau de sécurité (le serveur d’authentification) et demande un badge ayant une durée limitée. A l’aide de ce badge, il se rend à un service d’émission de tickets (celui qui est responsable de la ressource), et demande un ticket pour accéder à la ressource. Sauf qu’à chaque étape, tout est chiffré avec des clés symétriques.

Pré-requis

Pour cela, des clés privées doivent au préalable avoir été échangées entre tiers. Ainsi :

• La clé privée spécifique au client doit être connue du serveur d’authentification. La clé est (toujours ?) dérivée du mot de passe servant à l’authentification sur l’AS via une fonction string2key ;
• La clé privée du serveur de tickets (TGS) doit être connue du serveur d’authentification ;
• La clé privée du serveur ressource (S) doit être connue du serveur de tickets (TGS).

Comme autre pré-requis, le client (C) doit avoir un principal, c’est-à-dire être connu du réseau. Côté client, il faut également savoir gérer ce protocole, ce qui est le cas pour Windows (GSSAPI).

Les différentes étapes

Pour cela, voici les opérations :

1. Le client s’authentifie auprès du serveur d’authentification (Authentication Server, AS), en général via login/mot de passe ;
2. Le serveur d’authentification lui renvoie un ticket d’authentification (Ticket Granting Ticket, ou TGT), qui l’authentifie durant un certain temps. Ce TGT est chiffré avec la clé du serveur de tickets, et ne peut donc pas être déchiffré par le client. A côté de cela, le serveur d’authentification envoie également une clé de session à utiliser pour l’échange avec le serveur de tickets (TGS) ;
3. Pour accéder au serveur (S), le client (C) va utiliser ces éléments : il envoie le ticket d’authentification (TGT) au serveur de tickets (TGS) en le chiffrant avec la clé de session ;
4. Le serveur de tickets déchiffre le TGT, le vérifie, et envoie alors au client une clé d’échange finale entre le client et le serveur (en bleu), chiffrée avec la clé de session, ainsi qu’un ticket de service chiffré avec la clé du serveur ;
5. Le ticket de service est chiffré avec la clé du serveur : le client ne peut donc ni le lire, ni le modifier.

Cache

Le ticket d’authentification (TGT) ayant une certaine durée de validité, il doit être protégé convenablement dans un cache approprié, dont Kerberos exige qu’il soit en mémoire non swappable (pour éviter qu’il soit écrit sur un disque), accessible uniquement au niveau noyau, etc.

Le protocole interdit également tout stockage du mot de passe ou du secret obtenu via string2key.

MIT Kerberos Consortium – Protocol Tutorial

Les attaques

Sources

• Explication de l’authentification Kerberos (varonis.fr)
• Kerberos : Principe de fonctionnement – Devensys Cybersecurity
• MIT Kerberos Consortium – Protocol Tutorial
• Kerberos en Active Directory – hackndo
• Fonctionnement de Kerberos (mit.edu)
• Les protocoles LDAP, DNS et Kerberos | IT-Connect
• L’Internet Rapide et Permanent – Le protocole Kerberos (developpez.com)

Voir aussi

• Active Directory