Différences

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

--- 320kerberos:05_le_but [le 04/03/2010 à 09:39] – prof
+++ 320kerberos:05_le_but [le 30/06/2018 à 15:56] (Version actuelle) – prof
@@ 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.
@@ Ligne 65: / Ligne 64: @@
 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 imlémentant GSSAPI, toute application qui implémente également GSSAPI doit pouvoir utiliser kerberos pour gérer les aspects de sécurité. Nous en verons un exemple avec ''ssh''.
+//**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.