1. Le protocole Kerberos

Kerberos est un protocole d'authentification développé par le MIT (Massachusetts Institue of Technology) [1]http://web.mit.edu/Kerberos/ . Il a été conçu afin de fournir une authentification unifiée pour les applications de type client/serveur sur des réseaux qualifiés de non sûrs à l'aide de chiffrement symétrique. L'authentification repose sur une tierce partie de confiance nommée Key Distribution Center (KDC) pour l'attribution de tickets permettant l'accès aux différents services du réseau.

Les implémentations connues de Kerberos sont les suivantes :

• Kerberos MIT : implémentation originale développée par le MIT sous la licence BSD ;
• Microsoft Kerberos V5 : implémentation fournie par Microsoft depuis les versions Windows 2000 ;
• Heimdal : une implémentation alternative du MIT développée en Suède.

Afin de bien comprendre le fonctionnement du protocole Kerberos, il est important de rappeler les différentes entités impliquées dans le processus d'authentification :

• le client (C) souhaitant obtenir un accès à un service ;
• le service d'authentification (AS), qui authentifie le client vis-à-vis du service d'émission de tickets ;
• le service d'émission de tickets (TGS), qui authentifie le client vis-à-vis du service final, à condition que l'authentification avec le serveur d'authentification ait réussi ;
• le serveur (V), qui héberge le service auquel souhaite accéder le client.

Le fonctionnement du protocole Kerberos peut être comparé au processus mis en place dans les salles de cinéma. Tout d'abord, le client (C) achète son ticket d'entrée auprès de la caisse (AS). Dans cette situation, il obtient son ticket en échange d'un moyen de paiement. Ensuite, le client doit présenter son ticket au contrôle (TGS) afin de pouvoir accéder au cinéma. Enfin, devant la salle (V), un dernier contrôle s'assure que le client possède un ticket valable pour accéder à cette salle. Il est à noter que la durée de vie du ticket est limitée à une seule séance.

Il est important de souligner que l'AS et le TGS sont des fonctions du KDC. Le fonctionnement du protocole est décrit par le schéma présenté en page suivante.

Kerberos Protocol

Détaillons maintenant les différentes phases [2]http://www.zeroshell.net/eng/kerberos/ du processus dans le cas d'une authentification sur un poste de travail ou un serveur.

1.1. Authentication Server Request (AS_REQ)

Le processus débute lorsque l'utilisateur tape son identifiant et son mot de passe. Par la suite, un message de demande d'authentification (AS_REQ) est envoyé au service d'authentification (AS).

Ce message, transmis en clair, contient :

• l'identité de l'utilisateur (dupont@DOMAINE.FR) ;
• le nom du service auquel il souhaite accéder ;
• la durée de vie du ticket ainsi que la liste des machines où le ticket peut être utilisé.

1.2. Authentication Server Response (AS_REP)

Le service d'authentification (AS) s'assure que le nom de l'utilisateur, ainsi que le service auquel il souhaite accéder, existent. Si tel est le cas, une réponse (AS_REP) contenant les éléments suivants est envoyée :

• Un ticket nommé TGT (Ticket-Granting Ticket). Ce ticket, chiffré avec la clé secrète du TGS, contient les informations sur les limites de validité du ticket (nom d'utilisateur, nom de domaine, durée de vie, …), ainsi qu'une clé de session que nous appellerons SKtgs.
• La clé de session SKtgs chiffrée avec la clé secrète de l'utilisateur. Dans le cas d'une authentification par mot de passe, la clé secrète de l'utilisateur est un condensat de son mot de passe.

Au terme de cet échange AS_REQ/AS_REP, l'utilisateur et l'AS ont donc échangé :

• Une clé de session SKtgs connue uniquement par l'AS et l'utilisateur (car chiffrée avec la clé secrète de l'utilisateur). Cette clé de session servira pour les échanges ultérieurs avec le TGS.
• Un TGT contenant les limites de validité du ticket (nom d'utilisateur, nom de domaine, durée de vie, ...).Ce TGT est chiffré avec la clé secrète du TGS et n'est donc pas modifiable par l'utilisateur.

1.3. Ticket Granting Server Request (TGS_REQ)

Dès lors que le client reçoit le TGT, une demande (TGS_REQ) est adressée au service d'émission de tickets (TGS) pour la connexion à la station de travail.

Cette demande contient :

• Le nom d'utilisateur et un timestamp de la demande chiffrée avec la clé de session SKtgs. Cet élément est appelé authentificateur (authenticator). Il est à noter que seul un utilisateur légitime est capable de générer un tel élément.
• Le TGT précédemment obtenu.
• Le nom du service auquel l'utilisateur souhaite se connecter, ainsi que la durée de vie du ticket.

1.4. Ticket Granting Server Response (TGS_REP)

À la réception de la demande (TGS_REQ) du client, le TGS effectue les actions suivantes :

• Déchiffre le TGT avec sa clé et vérifie sa validité.
• Vérifie la validité de l'authentificateur en utilisant la clé de session SKtgs présente dans le TGT.

Si le TGS_REQ est valide, il émet alors une réponse TGS_REP contenant :

• Une clé de session (SKservice) entre le service et l'utilisateur. Cette clé est envoyée chiffrée par SKtgs.
• Un ticket de service TS chiffré avec la clé du service et contenant le nom de l'utilisateur, le nom du service, la liste des adresse IP autorisées à accéder au service, un timestamp, une durée de validité, ainsi que la clé de session SKservice.

Quand l'utilisateur reçoit cette réponse, il peut donc déchiffrer la clé SKservice, grâce à la clé SKtgs obtenue lors de l'échange AS_REQ/AS_REP.

1.5. Application Request (AP_REQ) (optionnel)

Dans le cas d'utilisation d'un service sur un équipement tiers, une autre requête (AP_REQ) est envoyée au serveur fournissant le service.

Cette requête contient :

• un nouvel authentificateur, chiffré cette fois avec SKservice ;
• le ticket de service TS.

Le fournisseur de service commence par extraire la clé SKservice présente dans le ticket de service TS. À l'aide de cette clé, il extrait le nom d'utilisateur présent dans l'authentificateur et s'assure qu'il est identique à celui contenu dans le ticket de service.

1.6. Application Response (AP_REP) (optionnel)

Ce dernier échange, qui est optionnel, est envoyé uniquement afin d'assurer une authentification mutuelle entre le client et le serveur fournissant le service (V).

Cette requête contient un timestamp généré par le serveur et est chiffrée avec la clé SKservice.

2. Historique des attaques sur Kerberos

Depuis la publication du protocole Kerberos en 1989, différentes faiblesses ont été identifiées. Dans cette section, nous vous présentons deux attaques connues : KDC Spoofing et Replay attack. Les faiblesses présentées dans ces deux attaques ont été utilisées pour réaliser l'attaque Pass the ticket.