Le protocole Kerberos est basé sur un algorithme d’authentification fondé sur une cryptographie. L’utilisation de cet algorithme ne permet pas à une personne malveillante qui écoute le dialogue d’un client à l’insu de ce dernier de se faire passer pour lui plus tard. Ce système permet à un processus client travaillant pour un utilisateur donné de prouver son identité vis-à-vis d’un serveur sans envoyer de données dans le réseau permettant à un tiers de découvrir le code d’authentification.
L’ensemble du protocole Kerberos est basé sur un mécanisme permettant au processus client de prouver qu’il possède la clé de chiffrement qui est connue des seuls utilisateurs de base et du serveur.
Ce mécanisme peut être résumé par le schéma ci-dessous :
Figure 51 : Modèle de fonctionnement du protocole KERBEROS
Dans le cadre d’une implémentation du protocole KERBEROS, le client et le processus client ne connaissent pas la clé de chiffrement de base utilisée pour l’authentification. Quand un client doit répondre à une demande d’identification, il se met en contact avec un serveur d’authentification. Le client et le serveur d’authentification possèdent la même clé d’authentification (clé client) qui équivaut à un mot de passe pour le client concerné. Le client envoie un message d’authentification Kerberos chiffré avec sa clé client au serveur d’authentification. Celui-ci utilise la clé client pour vérifier l’identité de l’émetteur. Si le message est déchiffré, le client est alors identifié.
Dans le cas d’une identification positive du client, le serveur d’authentification émet un ticket Kerberos, certificat chiffré contenant une clé unique permettant d’identifier le client (clé de session) et une date limite de validité du certificat. Ce ticket Kerberos est chiffré à l’aide d’une clé connue seulement du serveur d’authentification et du serveur de vérification (clé de serveur). Puisque cette clé n’est connue que des serveurs d’authentification et de vérification, il est impossible au client de modifier le ticket sans que cela passe inaperçu.
Le certificat est alors acheminé jusqu’au serveur de vérification qui le déchiffre à l’aide de la clé de serveur et utilise la clé de session obtenue pour authentifier le client. Dans le schéma ci-dessus, la demande n°1 de vérification, génère la réponse n°2 qui délivre un ticket de vérification et la clé de session. Les messages n°3 et 4 permettent l’authentification en prouvant que le client connaît la clé de session incluse dans le ticket Kerberos.
Le protocole Kerberos est implémenté en standard par le système d’exploitation Windows 2000. Des versions « Kerberos » des différents outils existent également en standard sous la plupart des environnements Unix.
L'authentification MS-Kerberos n'est pas universelle et elle n'est pas utilisée par de nombreux systèmes de connexion à la machine. Les serveurs FTP et Telnet fournis dans W2K ne connaissent pas MS-Kerberos, tout comme les services Macintosh fournis en standard.
Il est à noter également qu’il n'existe pas de support de MS-Kerberos dans le middleware comme la messagerie MS-Exchange. Il n'y a pas de SSH (Secure Shell) fourni en standard, ni de SSH disponible supportant MS-Kerberos, ce qui constitue un frein important compte tenu de l'importance de SSH. De plus, il ne faut pas oublier que les clients habituels Windows 95 et 98 n'ont bien sûr pas de support pour MS-Kerberos. Tout cela limite donc très fortement la portée à court terme de MS-Kerberos.
Pour le développeur d'applications, Microsoft ne fournit pas les API (Application Program Interface) Kerberos, mais des API propriétaires spécifiques : SSPI (Security Support Provider Interface).
Une application « cerberisée » (supportant Kerberos) ne peut ainsi pas être recompilée sur Windows 2000. Les SSPI sont proches des GSS-API mais restent différentes et n'existent que sur l’environnement Microsoft. À noter que les noms des royaumes MS-Kerberos sont obligatoirement les noms du DNS, seule la casse changeant.
Un client Windows 2000 trouve le serveur Kerberos (KDC) auquel il doit s'adresser par le DNS qui repose sur la bonne configuration du client. En outre, il n'y a pas véritablement de compatibilité entre MS-Kerberos et Kerberos V diffusé avec DCE (Distributed Computing Environment) (Solaris, Aix, HP-UX, OSF-1) même s’il est vrai que cette dernière solution est peu implémentée.
La sécurité dans MS-Kerberos repose sur le champ propriétaire SID dont le fonctionnement est tenu secret par Microsoft.
Une autre difficulté est de savoir quand l'authentification MS-Kerberos est utilisée. La seule solution est d'avoir un serveur Kerberos MIT et de le tester avec un compte déclaré uniquement dans ce serveur. Si cela fonctionne, c'était une authentification Windows NT, sinon, il s'agissait de l'authentification centralisée Kerberos.
Les attaques suivantes sont toujours possibles malgré l'authentification MS-Kerberos :
- la connexion anonyme (null session) permet par défaut la lecture de tous les objets ;
- la connexion anonyme par MSRPC permet d'avoir la liste des utilisateurs ;
- W2K a des comptes par défaut : Administrator, Guest, IUSR-systemname, etc.;
- il est possible d'extraire les hashes de la SAM locale ou d'Active Directory, et les techniques de crackages seront alors utilisables.