Architecture Kerberos et circulation des tickets

Kerberos a été développé au MIT dans le cadre du projet Athena, dans les années 1980, afin de fournir une authentification réseau sécurisée pour un environnement informatique distribué. Nommé d’après le chien à trois têtes qui garde les Enfers, il fournit une authentification mutuelle entre les clients et les services à l’aide d’un tiers de confiance : le centre de distribution des clés.

Le KDC possède deux composants logiques : le service d’authentification (AS) et le service d’octroi de tickets (TGS). Dans Microsoft Active Directory, ils s’exécutent tous deux sur le contrôleur de domaine. L’AS gère la connexion initiale et délivre les tickets d’octroi de tickets (TGT). Le TGS délivre des tickets de service pour accéder à des services précis.

Le client commence l’authentification en envoyant un AS-REQ au service d’authentification. Kerberos moderne exige une pré-authentification : le client chiffre un horodatage avec sa clé à long terme (dérivée du mot de passe) afin de prouver qu’il connaît le mot de passe. Cela empêche les attaques par dictionnaire hors ligne contre les messages AS-REQ non protégés.

L’AS vérifie les données de pré-authentification et répond par un AS-REP contenant un ticket d’octroi de tickets (TGT) chiffré avec la clé à long terme du compte krbtgt (que le client ne peut pas déchiffrer), ainsi qu’une clé de session chiffrée avec la clé à long terme du client. Le client ne déchiffre que la partie qui lui est destinée afin d’obtenir la clé de session du TGS.

Lorsque le client souhaite accéder à un service, il envoie un TGS-REQ au service d’octroi de tickets, en incluant le TGT (comme preuve de son identité) et un authentificateur chiffré avec la clé de session du TGS. Le TGS déchiffre le TGT avec la clé krbtgt afin de vérifier l’identité du client.

Le TGS répond avec un ticket de service chiffré avec la clé à long terme du service cible, ainsi qu’une nouvelle clé de session chiffrée pour le client. Le client ne peut pas lire le contenu du ticket de service, mais uniquement la partie qui lui est destinée. Ce ticket de service prouve l’identité du client auprès du service.

Le client envoie un AP-REQ au service cible, en incluant le ticket de service et un nouvel authentificateur chiffré avec la clé de session du service. Le service déchiffre le ticket de service à l’aide de sa propre clé à long terme, vérifie l’authentificateur et authentifie le client. Aucun mot de passe n’est jamais envoyé au service.

Un domaine Kerberos est un domaine administratif géré par un seul KDC. L’authentification interdomaines est établie au moyen de clés interdomaines partagées entre les KDC de domaines différents. Lorsqu’un client du domaine A accède à un service du domaine B, le KDC du domaine A délivre un ticket de recommandation que le client présente au KDC du domaine B.

Les tickets Kerberos ont une durée de validité configurée (généralement 10 heures pour les TGT), après laquelle ils expirent et une nouvelle authentification est nécessaire. Les TGT peuvent également être configurés comme renouvelables, ce qui permet au client de demander un nouveau TGT au KDC sans saisir à nouveau ses identifiants, jusqu’à une durée maximale de renouvellement.

Kerberos utilise deux types de clés. Les clés à long terme sont dérivées des mots de passe des comptes et servent uniquement à chiffrer certaines parties des messages d’authentification. Les clés de session sont négociées à nouveau pour chaque échange d’authentification et servent à la session de communication effective. La compromission d’une clé de session ne révèle pas la clé à long terme.

Kerberos fournit une authentification mutuelle (le client et le service sont tous deux vérifiés), une protection contre la relecture (grâce aux horodatages et aux authentificateurs) et une confidentialité persistante pour chaque session. Le KDC n’expose jamais les clés à long terme dans le fonctionnement normal. La principale hypothèse de confiance est que le KDC lui-même n’est pas compromis.

Kerberos utilise un KDC composé des services AS et TGS. La connexion produit un TGT (AS-REQ/AS-REP). L’accès à un service nécessite d’échanger le TGT contre un ticket de service (TGS-REQ/TGS-REP). Le ticket de service est présenté au service cible (AP-REQ). Seuls le KDC et les services concernés peuvent lire les tickets. Les domaines permettent l’authentification interdomaines grâce à la confiance interdomaines.