Comment fonctionne l'authentification Kerberos?

J'ai essayé de comprendre le fonctionnement de l'authentification Kerberos. Les informations que j'ai trouvées manquaient toujours de quelque chose comme si une partie de celles-ci était considérée comme acquise. Je suis au courant du processus en général, mais il manque quelques détails.

Obtenir TGT:

1. Tout d'abord, un utilisateur doit obtenir un TGT (Ticket Granting Tickets) du KDC - l'utilisateur envoie une demande avec uniquement son nom d'utilisateur (UPN) et sans son mot de passe . Certaines informations supplémentaires sont fournies pour empêcher un renvoi de la demande, telles que l'adresse IP et l'horodatage. Si une préauthentification est requise, l'heure est hachée avec le mot de passe de l'utilisateur.

2. Le KDC renvoie à l'utilisateur ce qui suit: A. TGT - avec un horodatage, un nom d'utilisateur, une adresse IP et une clé de session - le TGT est crypté avec un secret que seul le KDC connaît et ne peut donc être modifié par personne.
   B. Clé de session pour l'utilisateur et le KDC à utiliser lors d'une communication ultérieure. Ces éléments sont cryptés à l'aide du mot de passe de l'utilisateur (secret de base partagé entre le KDC et l'utilisateur). Si une pré-authentification a été utilisée, le serveur vérifiera si l'horodatage était valide avant de renvoyer les informations.

3. Les utilisateurs reçoivent les informations et les décryptent à l'aide de leur mot de passe - puis les stockent dans sa mémoire (plateau kerberos).

Obtenir TGS:

1. Lorsque l'utilisateur est invité à s'authentifier auprès d'un service, il envoie une demande au KDC pour un TGS (service d'octroi de ticket), la demande contient le TGT, le nom UPN et le SPN (nom du principal du service - disons, l'URI d'une page Web). .

2. Le KDC décrypte ensuite le TGT et valide son authenticité, ce qui correspond à l'UPN, à partir de la même adresse IP et toujours valide (le ticket a une période effective).

3. Le KDC envoie un TGS à l'utilisateur chiffré avec le mot de passe de service.

4. L'utilisateur présente le TGS au service - qui le déchiffre en utilisant son propre mot de passe.

5. L'authentification est terminée car le service compte sur le fait que son mot de passe est uniquement partagé entre lui et le KDC. Il est donc certain que le KDC a authentifié l'utilisateur plus tôt.

Quelques questions:

1. Est-ce que je manque quelque chose ou c'est tout?

2. Quand l'utilisateur et le KDC utilisent-ils la clé de session? À quel point? Pourquoi est-ce nécessaire? Pourquoi le mot de passe utilisateur ne suffit-il pas?

3. Il devrait également y avoir une clé de session entre l'utilisateur et le service (à ma connaissance) - quand et pourquoi est-elle utilisée (comme pour la dernière question)?

4. Kerberos impose une limite d’écart de 5 minutes entre toutes les parties. Je comprends pourquoi le fait de synchroniser l’heure est important, car il est utilisé comme un moyen de chiffrement et de décryptage. Comment se fait-il que l’écart soit correct? Pourquoi 5 minutes?

Je serai heureux pour les corrections si vous avez.

Merci d'avance, Tomer

1) cela semble assez complet, je ne suis pas sûr de tous les détails.

2) Le mot de passe de l'utilisateur ne suffit pas, car il doit être partagé entre deux parties. Les deux seules parties qui le partagent sont le KDC et le client. Si vous envisagez d'envoyer quelque chose sur le réseau, même crypté, il est préférable qu'il ne dure pas longtemps. La clé de session est donc utilisée par le client pour demander le ticket de service (je pense). De plus, le KDC génère des tickets de service avec des clés de session. Ainsi, lorsqu'un client obtient un ticket pour un service LDAP ou HTTP, le KDC génère une clé de session. Cette clé de session se trouve dans le ticket de service, lequel contient également un message crypté destiné à l'agent fournissant le service (le serveur LDAP ou HTTP), qui inclut également la clé de session. Donc, maintenant, le client et le serveur partagent un secret éphémère que le KDC leur a dit à tous les deux. Cette clé est utilisée lorsqu'un protocole est en place pour l'utiliser. Donc, peut-être qu'un serveur telnet pourrait chiffrer le trafic sur le réseau si kerberos est activé, par exemple.

4) Inclure l'heure et une marge de manœuvre de 5 minutes est un moyen de garantir que les horloges ne doivent pas être synchronisées avec précision jusqu'à la milliseconde. Vous pouvez tolérer tous les niveaux normaux de délai réseau ou de pannes réseau, sans pour autant rejouer une demande plus tard. Ce n'est pas bon d'aller chercher un ticket, de le faire fouiner par la NSA, puis quelques jours / semaines / années plus tard après avoir forcé votre mot de passe ou déchiffré à l'aide d'attaques mathématiques fantaisistes découvertes plus tard, ils vont utiliser le ticket encore. S'assurer que le ticket est récent empêche ce type de problème.

La clé de session n'est pas utilisée tout le temps. Par exemple, si vous vous connectez à un site Web https à l'aide de l'authentification Kerberos, vous utiliseriez généralement Kerberos pour l'authentification, mais la clé de session est négociée à l'aide de méthodes https standard (par exemple, SSL / TLS).