[Kerberos 5] Compréhension
3. L’authentification Kerberos
L’authentification Kerberos est basée sur un ensemble de messages chiffrés, qui permettent de prouver l’identité d’un interlocuteur.
3.1. Préambule
Contrairement aux mécanismes classiques d’authentification d’un client à un service, un client et un service ne partagent pas, à priori, de secret permettant de réaliser l’identification. Dans Kerberos, seul le KDC partage un secret avec les autres entités du réseau, qu’elles représentent un utilisateur ou un service. Dans le cas d’un service, on appellera ce secret une clé de service, et on conservera le terme « mot de passe » pour un utilisateur classique. Toutefois, le terme générique « clé » pourra être utilisé pour décrire une clé de service ou un mot de passe, selon le contexte.
3.2. Le service d’authentification (AS)
Quand un client souhaite s’authentifier à un service, plutôt que de s’adresser directement au service, il effectue une demande au KDC. Donc, avant toute chose, le client doit s’être authentifié auprès du KDC. Cette phase d’authentification est réalisée par l’AS, le serveur d’authentification.
Le client, lors de cette première phase, envoie donc sa demande au KDC. Cette demande se fait en clair sur le réseau, ce qui ne pose aucun problème puisque aucune donnée sensible n’est présente dans cette demande. Le client envoie en effet : son identifiant, un horodatage, et son adresse réseau.
Le serveur d’authentification renvoie alors au client un paquet de données, contenant un premier ticket, appelé Ticket-Granting Ticket, ou TGT, chiffré avec la clé du service de délivrement de ticket (TGS). Le tout est chiffré avec la clé de l’utilisateur. Pour pouvoir retrouver le TGT, l’utilisateur doit donc déchiffrer ce paquet avec son mot de passe.
La phase d’authentification qui vient de se faire s’est effectuée sans qu’à aucun moment, le mot de passe de l’utilisateur ne transite, en clair, de façon chiffrée ou sous une forme dérivée, sur le réseau. De plus, c’est la seule et unique fois où l’utilisateur devra entrer son mot de passe. Dans toute la suite, il utilisera le TGT que vient de lui fournir l’AS pour négocier avec le KDC.
KRB_AS_REQ
*client *---identifiant, horodatage, adr reseau--->*KDC AS *
*client *<----cle_client(TGT)----------------------*KDC AS *
KRB_AS_REP
3.3. Le service de délivrement de ticket (TGS)
Une fois le client authentifié sur le KDC, il peut demander à accéder à un nouveau service. Le client et le service, à priori, ne partagent aucun secret, ils vont donc passer par le KDC pour établir un tel secret. C’est le KDC qui va générer une clé de chiffrement et la distribuer de façon sécurisée aux deux interlocuteurs. Cette clé de chiffrement est appelée clé de session. Voyons les étapes qui mènent à l’authentification du client à un nouveau service.
Le client envoie sa demande au KDC. Souhaitant accéder au service, il va envoyer au KDC un paquet contenant :
- Le TGT obtenu à l’étape précédente.
- Le nom du service auprès duquel il souhaite s’identifier.
- Son adresse réseau.
- Un horodatage
Le serveur peut alors vérifier le TGT, puisque c’est lui-même qui l’a émis, et qu’il l’a chiffré avec la clé du service TGS qu’il est le seul à connaître. Si le TGT est valide, il renvoie au client une réponse, composée :
- D’un ticket de service, chiffré avec la clé du service distant. Ce ticket contient une clé de session.
- Cette même clé de session, chiffrée avec la clé du client.
KRB_TGS_REQ
*client *--TGT+service+adresse_réseau+horodatage-->*KDC AS*
*client *<--Clé_serv(clé_sess)+Clé_clie(clé_sess)---*KDC AS*
KRB_TGS_REP
Le client peut désormais présenter son ticket de service au service distant. Celui-ci, en déchiffrant ce ticket, obtiendra la clé de session, clé de session que le client aura obtenu en utilisant son TGT. Le client vient de s’authentifier auprès du service ! Le service a l’assurance que le client qui lui parle s’est authentifié préalablement, car seul le KDC connait la clé utilisée pour chiffrer le ticket de service qu’il vient de recevoir.
KRB_AP_REQ
*client *--Clé_ses(horo,client)+Clé_serv(clé_ses)-->* SOF *
*client *<-----------S_client_serveur(horodatage)--* SOF *
KRB_AP_REP
Clé_ses=Clé_sesssion, horo=horodatage, Clé_serv=Clé_service, SOF=serveur offrant un service,
Kerberos permet en outre de réaliser une authentification mutuelle. En effet, si le service est désormais sûr que le client est authentifié, le client, lui, peut également s’assurer que le service auquel il pense parler est le bon, puisqu’ils disposent tous deux d’une clé de session commune, clé que le service n’a pu obtenir que s’il connaissait sa propre clé.
L’échange que l’on vient de décrire pose cependant un problème. Une tierce personne, écoutant le réseau, peut récupérer les données envoyées par l’utilisateur au service - c’est à dire, récupérer le TGS - et le rejouer avant qu’il n’expire. Cette personne n’est pas authentifiée auprès du KDC, mais s’authentifiera tout de même avec succès auprès du service sans problème. Afin d’éviter que l’échange que nous venons de décrire ne soit « rejoué » ultérieurement, s’ajoute donc au Ticket présenté par le client un authentificateur. Cet authentificateur contient en fait un simple horodatage, chiffré avec la clé de session de l’échange.
Quand le service reçoit cet authentificateur, il est incapable de le déchiffrer avant d’avoir déchiffré le TGS, dans lequel il va trouver la clé de session. Une fois cette clé de session récupérée, il va pouvoir déchiffrer l’authentificateur et vérifier la date qu’il contient.
Cette fois-ci, quelqu’un récupérant l’échange ne pourra pas rejouer le ticket, à cause de l’horodatage présent dans l’authentificateur. Il ne pourra pas non plus fabriquer un nouvel authentificateur car il n’a pas connaissance de la clé de session à utiliser pour le chiffrer.
Si vous avez apprécié cet article, s'il vous plait, prenez le temps de laisser un commentaire ou de souscrire au flux afin de recevoir les futurs articles directement dans votre lecteur de flux.
Commentaires
Pas encore de commentaire.
Laisser un commentaire