L'internet rapide et permanent

Outils pour utilisateurs

Outils du site

Vous êtes ici : L'internet rapide et permanent » Kerberos » Principe général

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
320kerberos:05_le_but [le 21/02/2010 à 10:29] – prof320kerberos:05_le_but [le 30/06/2018 à 15:56] (Version actuelle) – prof
Ligne 5: Ligne 5:
     * un service d'authentification ;     * un service d'authentification ;
     * un service d'attribution de tickets d'accès à divers services ;     * 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. 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}} {{ :320kerberos:diagramme.png?400 |Diagramme général}}
- 
 ===== Authentification ===== ===== 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 :   * (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> ;     * 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.     * il renvoie le tout (AS_REP) à l'utilisateur.
 Ledit utilisateur peut ainsi : 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>   * 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. 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 : Certains préfèrent une présentation plus graphique, la voici :
-{{ :320kerberos:as.png?400 |Authentification}}+{{ :320kerberos:as.png?500 |Authentification}}
  
  
Ligne 56: Ligne 55:
 (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. (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 : 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 :
Ligne 64: Ligne 63:
  
 Il pourra alors ouvrir ses portes au client. 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... ===== ===== 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. 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.
  
Principe général: Dernière modification le: 21/02/2010 à 10:29 par prof