Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 320kerberos:05_le_but [le 17/02/2010 à 14:36] – prof
+++ 320kerberos:05_le_but [le 30/06/2018 à 15:56] (Version actuelle) – prof
@@ Ligne 5: / Ligne 5: @@
     * un service d'authentification ;
     * un service d'attribution de tickets d'accès à divers services ;
-  * un (ou plusieurs) serveur(s) de services qui réclame l'authentification du client. Par exemple un serveur http, ou tout autre service « kerberisable ».
+  * un (ou plusieurs) serveur(s) de services qui réclame(nt) l'authentification du client. Par exemple un serveur http, ou tout autre service « kerberisable ».
-L'utilisateur dispose au moins d'un mot de passe qui servira de clé de chiffrement, que nous appèlerons <m>K_user</m> pour que la suite soit bien lisible et compréhensible. Cette clé <m>K_user</m> est réputée connue des seuls utilisateur et <m>AS</m>.
+L'utilisateur dispose au moins d'un mot de passe qui servira de clé de chiffrement pour son authentification initiale, que nous appèlerons <m>K_user</m> pour que la suite soit bien lisible et compréhensible. Cette clé <m>K_user</m> est réputée connue des seuls utilisateur et <m>AS</m>.
 Le serveur <m>TGS</m> dispose d'une clé de chiffrement que nous appèlerons <m>K_tgs</m> et que l'utilisateur ne connait pas.
@@ Ligne 14: / Ligne 14: @@
 {{ :320kerberos:diagramme.png?400 |Diagramme général}}
 ===== Authentification =====
-L'utilisateur doit commencer par s'authentifier auprès du service d'authentification de kerberos. Généralement, cette opération se fait en indiquant le nom de l'utilisateur et son mot de passe.
+L'utilisateur doit commencer par s'authentifier auprès du service d'authentification <m>AS</m> de kerberos. Généralement, cette opération se fait en indiquant le nom de l'utilisateur et son mot de passe dans un formulaire de saisie. Qu'il soit bien clair que ceci ne veut pas dire que le mot de passe va circuler sur le réseau.
-  * (1) l'utilisateur envoie une requête (AS_REQ). Cette requête contient le nom d'utilisateur, en clair, mais pas le mot de passe, bien entendu.
+  * (1) l'utilisateur envoie une requête (AS_REQ). Cette requête contient le nom d'utilisateur, en clair, mais pas le mot de passe, n'ayons pas peur de le répéter.
   * (2) grâce à un système de « challenge » que nous étudierons plus tard, le serveur vérifie que l'utilisateur est bien celui qu'il prétend être. Si c'est le cas, le serveur crée :
     * une clé de session <m>K_session</m> qui ne sera partagée qu'entre le <m>TGS</m> et l'utilisateur. Il la chiffre avec <m>K_user</m> ;
@@ Ligne 23: / Ligne 22: @@
     * il renvoie le tout (AS_REP) à l'utilisateur.
 Ledit utilisateur peut ainsi :
-  * récupérer sa clé de session <m>K_session</m> en la déchiffrant avec sa <m>K_user</m> ;
+  * récupérer sa clé de session <m>K_session</m> en la déchiffrant avec sa <m>K_user</m>. La clé de session ne pourra être utilisée que si le bon mot de passe est connu par les deux protagonistes, sans pour autant qu'il ait été échangé sur le réseau ;
   * ranger son <m>TGT</m> dans un coin, car il ne peut le déchiffrer, ne connaissant pas la clé <m>K_tgs</m>. Rappelons en effet que :\\ <m>TGT=(K_{session}+ID_{user})*K_tgs</m>
 C'est simple, c'est beau. En résumé, l'utilisateur dispose d'une clé de session <m>K_session</m> et d'un <m>TGT</m>. Ce <m>TGT</m> ne peut servir qu'à ceux qui disposent de <m>K_tgs</m> c'est-à-dire au seul <m>TGS</m> qui a émis ce <m>TGT</m>. Si un utilisateur présente au <m>TGS</m> un <m>TGT</m> falsifié, le <m>TGS</m> ne pourra le déchiffrer et n'en fera rien. Il est donc **primordial** de s'assurer qu'il n'y a pas de fuites sur <m>K_tgs</m>, sans quoi, un faux <m>TGS</m> pourrait voir le jour.
 Certains préfèrent une présentation plus graphique, la voici :
-{{ :320kerberos:as.png?700 |Authentification}}
+{{ :320kerberos:as.png?500 |Authentification}}
@@ Ligne 47: / Ligne 46: @@
   * le client va pouvoir s'authentifier dans le service demandé, puisque son accréditation est chiffrée avec la clé du service <m>K_service</m> que le client ne connait pas ;
   * le client va transmettre au service une clé de session avec ce service <m>K_{session service}</m>. Le <m>TGS</m>, qui a de l'éthique, s'étant empressé d'oublier cette clé, seuls le client et le service la connaissent.
-{{ :320kerberos:tgs.png?700 |Ticket de service}}
+{{ :320kerberos:tgs.png?500 |Ticket de service}}
 ===== Authentification du client auprès du service =====
-(5) Le client peut maintenant utiliser son ticket de service pour s'authentifier auprès du service « kerbérisé ».
+(5) Le client peut maintenant utiliser son ticket de service pour s'authentifier auprès du service « kerbérisé ». Il envoie au serveur d'application :
+  * le « blob » qui contient son identité et la clé de session de service, le tout chiffré avec la clé du service (que l'utilisateur ne connait pas) soit <m>({Auth User}+K_{session service})*K_service</m> ;
+  * son identité et un « timestamp », le tout chiffré avec la clé de session de service, soit <m>(ID_user + TimeStamp)*K_{session service}</m> ;
 (6) La réponse AP_REQ est optionnelle et dans notre cas de figure n'existe pas. Inutile donc de se prendre encore un peu plus la tête.
-{{ :320kerberos:aps.png?650 |}}
+{{ :320kerberos:aps.png?400 |}}
+Lorsque le service Kerbérisé reçoit cette requête, comme il dispose de sa clé de service <m>K_service</m>, il peut déchiffrer le « blob » et donc récupérer :
+  * l'identité de l'utilisateur fournie par le <m>TGS</m> ;
+  * la clé de session pour le service <m>K_{session service}</m>, également fournie par le <m>TGS</m>.
+Il peut alors déchiffrer l'identité <m>ID_user</m>, ainsi que le <m>TimeStamp</m>. La comparaison des deux identités permettra au service de s'assurer qu'il n'est pas grugé par un intrus, le Timestamp lui permettra de déduire que ce ticket n'est pas un ticket volé, puis rejoué par un intrus (sauf si l'intrus a pu le faire en moins de 5 minutes).
+Il pourra alors ouvrir ses portes au client.
+==== Et GSSAPI ? ====
+//**Generic Security Services Application Programming Interface**// est en gros une couche d'abstraction qui va permettre de normaliser les discussions entre les services concernant la sécurité. Ainsi, Kerberos 5 implémentant GSSAPI, toute application qui implémente également GSSAPI doit pouvoir utiliser kerberos pour gérer les aspects de sécurité. Nous en verrons un exemple avec ''ssh''.
 ===== Bref... =====
-Lorsque vous saurez que cette présentation est largement simplifiée, dans la mesure où tous les protagonistes appartiennent au même royaume, que nous n'avons pas évoqué le principe des relations inter-royaumes ni de choses comme le renouvèlement, la transmission, la révocation de tikets et encore moins les éventuelles extensions du protocole, vous apprécierez d'autant mieux la complexité de l'usine.
+Lorsque vous saurez que cette présentation est largement simplifiée, dans la mesure où tous les protagonistes appartiennent au même royaume, que nous n'avons pas évoqué le principe des relations inter-royaumes ni de choses comme le renouvèlement, la transmission, la révocation de tickets et encore moins les éventuelles extensions du protocole, vous apprécierez d'autant mieux la complexité de l'usine.
 Ce que nous avons vu devrait permettre de comprendre ce que nous allons observer dans le cas très simple de notre plate-forme de tests.