Kerberos (protocole)

Histoire et développement

Le MIT a développé Kerberos pour protéger les services de réseau fournis par le projet Athena. Le protocole a été nommé d'après le personnage mythologique grec Kerberos (ou Cerbère), connu dans la mythologie grecque comme étant le monstrueux chien de garde à trois têtes d'Hadès. Il existe plusieurs versions du protocole ; les versions 1 à 3 ne sont utilisées qu'en interne au MIT.

Steve Miller et Clifford Neuman, les principaux concepteurs de la version 4 de Kerberos (qui utilise l'algorithme de cryptage DES avec des clés de 56 bits), ont publié cette version en 1989, bien qu'ils l'aient principalement destinée au projet Athena.

La version 5, conçue par John Kohl et Clifford Neuman, est apparue sous le nom de RFC 1510 en 1993 (rendue obsolète par la RFC 4120 en 2005), dans l'intention de surmonter les limitations et les problèmes de sécurité de la version 4. Le MIT met gratuitement à disposition une implémentation de la version 5 de Kerberos, sous une licence de logiciel similaire à celle utilisée par la licence BSD.

Plusieurs entreprises ont utilisé la version 5 de Kerberos dans des logiciels commerciaux, notamment :

·         Les systèmes d'exploitation Windows 2000 et ultérieurs de Microsoft utilisent Kerberos comme méthode d'authentification par défaut.
Certains ajouts de Microsoft à la suite de protocoles Kerberos sont documentés dans la RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". La RFC
 4757 documente l'utilisation par Microsoft du chiffrement RC4.
Bien que Microsoft utilise le protocole Kerberos, il n'utilise pas le logiciel du MIT[1].

·         Le système Mac OS X d'Apple utilise également Kerberos dans ses versions client et serveur.

·         Red Hat Linux version 4 et suivantes utilise Kerberos dans les versions client et serveur.

En 2005, le groupe de travail Kerberos de l'IETF a introduit une nouvelle mise à jour des spécifications pour la version 5 de Kerberos [2] :

·         "Encryption and Checksum Specifications" (RFC 3961),

·         "Advanced Encryption Standard (AES) Encryption for Kerberos 5" (RFC 3962),

·         Une nouvelle édition de la spécification Kerberos Version 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Cette version rend obsolète la RFC 1510, clarifie certains aspects du protocole et de l'utilisation prévue dans une explication plus détaillée et plus claire,

·         Une nouvelle édition de la spécification GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism : Version 2". (RFC 4121).

En 2007, le MIT a formé le Consortium Kerberos pour la poursuite du développement.

Protocole

Kerberos utilise comme base le protocole Needham-Schroeder. Il fait appel à une authentification par un tiers de confiance appelée "centre de distribution de clés (KDC)", qui se compose de deux parties logiquement séparées : un serveur d'authentification (AS) et un serveur d'octroi de tickets (TGS). Kerberos fonctionne sur la base de "tickets" (appelés tickets Kerberos) qui servent à prouver l'identité des utilisateurs.

Base de données Kerberos : Le centre de distribution de clés (KDC) gère une base de données de clés secrètes ; chaque entité du réseau - qu'il s'agisse d'un client ou d'un serveur - partage une clé secrète connue d'elle seule et du KDC. La connaissance de cette clé sert à prouver l'identité de chaque entité. Pour la communication entre deux entités, le KDC génère une clé de session qu'elles peuvent utiliser pour sécuriser leurs communications.

Le terme "serveur Kerberos" fait généralement référence au KDC. Pour des raisons de fiabilité, il est possible d'avoir des CDK de secours. Ceux-ci sont appelés "serveurs esclaves Kerberos". Tous les esclaves synchronisent leurs bases de données à partir du serveur Kerberos maître.

Le terme "serveur d'application Kerberisé" fait généralement référence aux programmes Kerberisés avec lesquels les clients communiquent en utilisant des tickets Kerberos pour l'authentification. Par exemple, le serveur telnet Kerberos est un exemple de serveur d'application Kerberisé . Alors que le terme "applications Kerberisées" est utilisé pour désigner le côté client du serveur d'applications Kerberisées, par exemple, le client telnet Kerberos est un exemple d'application Kerberisée

La sécurité du protocole en dépend fortement :

1. Les participants maintiennent un temps vaguement synchronisé.
2. Une déclaration d'authenticité de courte durée : les billets Kerberos.

Description simplifiée du protocole

Les abréviations suivantes seront utilisées :

·         AS = serveur d'authentification

·         TGS = Ticket Granting Server

·         SS ou Server = Service Server (utilisateur du serveur qui demande son service, tel qu'un serveur d'impression, un serveur de fichiers, etc...)

·         TGT = Ticket Granting Ticket (billet Kerberos pour le TGS. Préparé par AS, puis utilisé pour parler avec le TGS).

En bref, le client s'authentifie auprès de l'AS en utilisant un secret partagé à long terme et reçoit un ticket de l'AS. Plus tard, le client peut utiliser ce ticket pour obtenir des tickets supplémentaires pour l'AS en utilisant le même secret partagé. Ces tickets peuvent être utilisés pour prouver l'authentification auprès de SS.

Le protocole en détail

Étapes de connexion basées sur le client utilisateur :

1. Un utilisateur saisit un nom d'utilisateur et un mot de passe sur la machine cliente.
2. Le client effectue une fonction à sens unique (principalement une fonction Hash) sur le mot de passe saisi, et celui-ci devient la clé secrète du client/utilisateur.

Étapes d'authentification des clients :

1. Le client envoie un message en texte clair au SE qui demande des services au nom de l'utilisateur.
   Exemple de message : "L'utilisateur XYZ souhaite demander des services".
   Remarque : ni la clé secrète ni le mot de passe ne sont envoyés à l'AS.
2. L'AS vérifie si le client figure dans sa base de données. Si c'est le cas, le SA renvoie les deux messages suivants au client :
• Message A : Clé de session client/TGS cryptée à l'aide de la clé secrète du client/utilisateur.
• Message B : TGT (qui comprend l'ID du client, l'adresse du réseau du client, la période de validité du billet et la clé de session client/TGS) chiffré à l'aide de la clé secrète du TGS.
3. Une fois que le client reçoit les messages A et B, il décrypte le message A pour obtenir la clé de session Client/TGS. Cette clé de session est utilisée pour les communications ultérieures avec TGS. À ce stade, le client dispose de suffisamment d'informations pour s'authentifier auprès du TGS.
   Note : Le client ne peut pas décrypter le message B, car il est crypté à l'aide de la clé secrète de TGS.

Étapes d'autorisation du service à la clientèle :

1. Lorsqu'il demande des services, le client envoie les deux messages suivants au TGS :
• Message C : composé du TGT du message B et de l'ID du service demandé.
• Message D : Authentificateur (qui se compose de l'ID du client et de l'horodatage), chiffré à l'aide de la clé de session Client/TGS.
2. À la réception des messages C et D, le TGS extrait le message B du message C. Il décrypte le message B en utilisant la clé secrète du TGS. Cela lui donne la clé de session Client/TGS. À l'aide de cette clé, le TGS décrypte le message D (Authenticator) et envoie les deux messages suivants au client :
• Message E : ticket client-serveur (qui comprend l'ID du client, l'adresse du réseau du client, la période de validité et la clé de session client-serveur) chiffré à l'aide de la clé secrète SS.
• Message F : Clé de session client/serveur cryptée avec la clé de session client/TGS.

Étapes de la demande de service au client :

1. À la réception des messages E et F de TGS, le client dispose de suffisamment d'informations pour s'authentifier auprès du SS. Le client se connecte au SS et envoie les deux messages suivants :
• Message E : de l'étape précédente (le ticket Client-à-Serveur, crypté à l'aide de la clé secrète SS).
• Message G : un nouvel authentificateur, qui comprend l'ID du client, l'horodatage et est crypté à l'aide d'une clé de session client/serveur.
2. Le SS décrypte le ticket en utilisant sa propre clé secrète pour récupérer la clé de session client/serveur. En utilisant la clé de session, le SS décrypte l'authentificateur et envoie le message suivant au client pour confirmer sa véritable identité et sa volonté de servir le client :
• Message H : l'horodatage trouvé dans l'Authenticator plus 1 du client, crypté à l'aide de la clé de session client/serveur.
3. Le client décrypte la confirmation à l'aide de la clé de session client/serveur et vérifie si l'horodatage est correctement mis à jour. Si c'est le cas, le client peut alors faire confiance au serveur et peut commencer à émettre des demandes de service au serveur.
4. Le serveur fournit les services demandés au client.

Inconvénients

• Un seul point d'échec : Il nécessite la disponibilité continue d'un serveur central. Lorsque le serveur Kerberos est en panne, personne ne peut se connecter. Ce problème peut être résolu en utilisant plusieurs serveurs Kerberos et des mécanismes d'authentification d'urgence.
• Kerberos exige que les horloges de tous les hôtes concernés soient synchronisées. Les tickets ont une période de disponibilité et si l'horloge de l'hôte n'est pas synchronisée avec l'horloge du serveur Kerberos, l'authentification échouera. La configuration par défaut exige que les horloges ne soient pas espacées de plus de 10 minutes. Dans la pratique, le protocole NTP (Network Time Protocol) est généralement utilisé pour maintenir la synchronisation de tous les hôtes.
• Le protocole d'administration n'est pas standardisé et diffère selon les implémentations du serveur. Les changements de mot de passe sont décrits dans la RFC 3244.
• Comme les clés secrètes de tous les utilisateurs sont stockées sur le serveur central, une compromission de ce serveur compromettra les clés secrètes de tous les utilisateurs.
• Un client compromis compromettra le mot de passe de l'utilisateur.

Pages connexes

• Gestion de l'identité
• Protocole de mot de passe à distance sécurisé (SRP)
• Interface du programme d'application des services de sécurité génériques (GSS-API)