Ticket-Granting Tickets
Comme le protocole Kerberos a été conçu à l’origine, une clé master pour un utilisateur a été dérivée d’un mot de passe fourni par l’utilisateur. Lorsqu’un utilisateur s’est connecté, le client Kerberos sur la station de travail de l’utilisateur a accepté le mot de passe de l’utilisateur et l’a converti en clé de chiffrement en passant le texte via une fonction de hachage unidirectionnel. Le hachage résultant était la clé master de l’utilisateur. Le client a utilisé cette clé master pour déchiffrer les clés de session reçues de KDC.
Le problème avec la conception Kerberos d’origine est que le client a besoin de la clé master de l’utilisateur chaque fois qu’il déchiffre une clé de session à partir du KDC. Cela signifie que le client doit demander à l’utilisateur le mot de passe au début de chaque échange client/serveur, ou que le client doit stocker la clé de l’utilisateur sur la station de travail. Les interruptions fréquentes de l’utilisateur sont trop intrusives. Le stockage de la clé sur la station de travail risque de compromettre une clé dérivée du mot de passe utilisateur, qui est une clé à long terme.
La solution du protocole Kerberos à ce problème consiste à ce que le client obtienne une clé temporaire à partir du KDC. Cette clé temporaire est uniquement adaptée à cette session d’ouverture de session. Lorsqu’un utilisateur se connecte, le client demande un ticket pour le KDC comme il demanderait un ticket pour n’importe quel autre service. Le KDC répond en créant une clé de session d’ouverture de session et un ticket pour un serveur spécial, le service complet d’octroi de tickets du KDC. Une copie de la clé de session de connexion est incorporée dans le ticket et le ticket est chiffré avec la clé master du KDC. Une autre copie de la clé de session d’ouverture de session est chiffrée avec la clé master de l’utilisateur dérivée du mot de passe d’ouverture de session de l’utilisateur. Le ticket et la clé de session chiffrée sont envoyés au client.
Lorsque le client obtient la réponse du KDC, il déchiffre la clé de session d’ouverture de session avec la clé master de l’utilisateur dérivée du mot de passe de l’utilisateur. Le client n’a plus besoin de la clé dérivée du mot de passe de l’utilisateur, car le client va maintenant utiliser la clé de session de connexion pour déchiffrer sa copie de toute clé de session de serveur qu’il obtient du KDC. Le client stocke la clé de session d’ouverture de session dans son cache de tickets, ainsi que son ticket pour le service complet d’octroi de tickets du KDC.
Le ticket pour le service complet d’octroi de tickets est appelé ticket d’octroi de ticket (TGT). Lorsque le client demande au KDC un ticket pour un serveur, il présente des informations d’identification sous la forme d’un message d’authentificateur et d’un ticket ( dans ce cas un TGT) comme il présenterait des informations d’identification à n’importe quel autre service. Le service d’octroi de tickets ouvre le TGT avec sa clé de master, extrait la clé de session d’ouverture de session pour ce client et utilise la clé de session de connexion pour chiffrer la copie d’une clé de session du client pour le serveur.