Distribution de clés
La technique d’authentification par clé secrète n’explique pas comment le client et le serveur obtiennent la clé de session secrète à utiliser dans les sessions entre elles. S’ils sont des gens, ils pourraient se réunir en secret et s’entendre sur la clé. Toutefois, si le client est un programme s’exécutant sur une station de travail et si le serveur est un service exécuté sur un serveur réseau, cette méthode ne fonctionnera pas.
Un client souhaite communiquer avec de nombreux serveurs et a besoin de clés différentes pour chacun d’eux. Un serveur communique avec de nombreux clients et a également besoin de clés différentes pour chacun d’eux. Si chaque client a besoin d’une clé différente pour chaque serveur et que chaque serveur a besoin d’une clé différente pour chaque client, la distribution de clé devient un problème. En outre, la nécessité de stocker et de protéger de nombreuses clés sur de nombreux ordinateurs crée un risque de sécurité énorme.
Le nom du protocole Kerberos suggère sa solution au problème de distribution de clés. Kerberos (ou Cerberus) était une figure de la mythologie grecque classique, un chien féroce à trois têtes qui empêchait les intrus vivants d’entrer dans les Enfers. Comme la garde mythique, le protocole Kerberos a trois têtes : un client, un serveur et une tierce partie de confiance pour effectuer la médiation entre eux. L’intermédiaire approuvé dans ce protocole est le centre de distribution de clés (KDC).
Le KDC est un service qui s’exécute sur un serveur physiquement sécurisé. Il gère une base de données avec des informations de compte pour tous les principaux de sécurité de son domaine. Un domaine est l’équivalent Kerberos d’un domaine dans Windows.
En plus d’autres informations sur chaque principal de sécurité, le KDC stocke une clé de chiffrement connue uniquement du principal et du KDC. Il s’agit de la clé master utilisée dans les échanges entre chaque principal de sécurité et le KDC. Dans la plupart des implémentations du protocole Kerberos, cette clé master est dérivée à l’aide d’une fonction de hachage à partir du mot de passe d’un principal de sécurité.
Lorsqu’un client souhaite créer une connexion sécurisée avec un serveur, le client commence par envoyer une requête au KDC, et non au serveur qu’il souhaite atteindre. Le KDC crée et envoie au client une clé de session unique pour le client et un serveur à utiliser pour s’authentifier mutuellement. Le KDC a accès à la clé master du client et à la clé master du serveur. Le KDC chiffre la copie du serveur de la clé de session à l’aide de la clé de master du serveur et la copie du client à l’aide de la clé master du client.
Le KDC pourrait remplir son rôle d’intermédiaire de confiance en envoyant la clé de session directement à chacun des principaux de sécurité impliqués, mais dans la pratique, cette procédure ne fonctionnera pas, pour plusieurs raisons. Au lieu de cela, le KDC envoie les deux clés de session chiffrées au client. La clé de session du serveur est incluse dans un ticket de session.