Authentification avec Kerberos

Le protocole Kerberos, basé sur les travaux de Needham et Schroeder, propose un système d'authentification unique (puis mutuelle) d'une entité (utilisateur, serveur, etc) auprès des différents services Kerberos (serveur, imprimante, etc).

Kerberos repose sur plusieurs principes :

• Le mot de passe ne doit jamais circuler sur le réseau, que ce soit en clair ou de manière chiffrée.
• Seul le KDC partage un secret avec les autres entités du réseau.
• Les entités doivent être synchronisées. Par synchronisation, nous devons comprendre que l'heure système des différentes entités doit avoir le plus faible écart possible. Cette sécurité permet de s'assurer qu'un message ne soit intercepté, puis relancé dans le réseau. Un horodatage sera utilisé lors de chaque échange.
• L'authentification est indépendente du système d'exploitation.
• L'authentification est unique (SSO : Single Sign On) et donne accès à tous les services Kerberos.
• L'authentification est mutuelle : le service sait que le client est identifié, et le client sait que le service qui lui répond est bien celui auquel il s'est adressé.

Principe du tiers de confiance : le KDC

Kerberos s'appuie sur une entité de confiance, le KDC (Key Distribution Center), le centre de distributions des clés.

Dans Kerberos, le KDC est divisé en deux services distincts : l'AS et le TGS.

AS (Authentification Service, ou Authentification Server)

Le service d'authentification (AS) assure l'identification unique du client (SSO : Single Sign On), et lui fournit une clé de session qui lui permettra de communiquer avec les services Kerberos.

TGS (Ticket Granting Service)

Le service de délivrement de ticket (TGS) est l'entité qui gère les demandes d'accès aux différents services. Les clients sont déjà identifiés auprès de l'AS, et sont en possession de leur clé de session. Le TGS chiffrera donc cette clé de session avec la clé du service désiré.

L'authentification Kerberos

Identification du client

Comme nous l'avons vu plus haut, dans Kerberos un client ne peut s'adresser directement à un service, il doit passer par le KDC. Il fait donc une demande comprenant son identifiant, un horodatage, et son adresse réseau. Nous pouvons remarquer qu'à ce stade, il ne spécifie pas encore le service auquel il désire accéder : c'est parce qu'il s'adresse plus particulièrement à la partie AS du KDC. Cette demande est envoyée en clair sur le réseau.

L'AS (service d'authentification) renvoie au client un TGT (Ticket-Granting Ticket) chiffré à l'aide de la clé de service du TGS (service de délivrement de ticket). S'il envoie le TGT de cette manière, n'importe qui peut l'intercepter et l'utiliser. C'est pourquoi le TGT chiffré avec la clé de service du TGS est encore chiffré à l'aide de la clé du client, pour s'assurer que ce dernier soit bien le seul à pouvoir l'utiliser.

Le client utilise sa clé pour le déchiffrement, et récupère le TGT qu'il ne sait pas déchiffrer (il est chiffré à l'aide de la clé de service du TGS). C'est à ce moment que débute la SSO : est identifié une seule fois pour récupérer le TGT chiffré, et cette identification (cypher TGT) est valable lors de toute la session.

Comme nous l'avons vu plus haut, un des principes de Kerberos est que le mot de passe ne doit jamais circuler en clair sur le réseau. Cependant, les systèmes d'exploitations qui implémentent Kerberos doivent gérer le moyen de partager un secret entre le client et le KDC. Windows 2000, par exemple, utilise le mot de passe (connu de l'utilisateur et du serveur) pour générer la clé.

Demande d'un service

Le client peut donc à présent envoyer une demande d'accès à un service. La demande comporte le TGT chiffré, le nom du service avec lequel il désire communiquer, son adresse réseau, et un horodatage. La demande est donc traitée par la partie TGS du KDC.

Le TGS vérifie si la machine a bien été identifiée en déchiffrant le TGT à l'aide de sa clé de service. Le client est le seul à pouvoir déchiffrer l'ensemble TGT + chiffrement clé TGS + chiffrement clé client envoyé par l'AS, et le TGS est le seul à pouvoir déchiffrer le TGT + clé TGS renvoyé par le client.

Le TGS peut donc envoyer une clé de session au client. Dans le même envoi, il placera la même clé de session, mais chiffrée à l'aide de la clé du service désiré : c'est le TS (Ticket de Service). Le tout sera chiffré à l'aide de la clé du client.

[(clé de session) chiffrée avec la clé du service + clé de session] chiffré avec la clé du client

Le client reçoit le TS, qu'il déchiffre à l'aide de sa clé. Il est donc en possession de la clé de session, et du TS.

Il peut donc communiquer avec le service en lui envoyant des informations chiffrées à l'aide de la clé de session, et en y joignant le TS.

Du côté du service

Le service récupère le TS et le message chiffré avec la clé de session. Il déchiffre le TS à l'aide de sa clé de service, et possède donc la clé de session qui lui permet de déchiffrer le message.

A ce moment, nous avons un chiffrement symétrique (car une clé secrète identique est utilisée par le client et par le service), et une authentification mutuelle (car le service est sur de l'identité du client car il a eu contact avec l'AS avant de pouvoir prendre contact avec le TGS, et le client est sur de l'identité du service qui lui répond car la réponse est chiffrée à l'aide de la clé de session que seul le service pouvait déchiffrer).

Structure du document