Dans le schéma qui suit, nous avons :

• un utilisateur qui a ouvert une session sur une station de travail ;
• un serveur kerberos, qui abrite deux services distincts :
  • 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(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 pour son authentification initiale, que nous appèlerons pour que la suite soit bien lisible et compréhensible. Cette clé est réputée connue des seuls utilisateur et .

Le serveur dispose d'une clé de chiffrement que nous appèlerons et que l'utilisateur ne connait pas.

Le serveur d'application dispose d'une clé de chiffrement . Cette clé n'est connue que par le et le serveur d'application.

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 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, 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 qui ne sera partagée qu'entre le et l'utilisateur. Il la chiffre avec ;
  • une copie de et l'identité de l'utilisateur que nous nommerons , le tout chiffré avec , ce qui constitue le ;
  • il renvoie le tout (AS_REP) à l'utilisateur.

Ledit utilisateur peut ainsi :

• récupérer sa clé de session en la déchiffrant avec sa . 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 dans un coin, car il ne peut le déchiffrer, ne connaissant pas la clé . Rappelons en effet que :
  

C'est simple, c'est beau. En résumé, l'utilisateur dispose d'une clé de session et d'un . Ce ne peut servir qu'à ceux qui disposent de c'est-à-dire au seul qui a émis ce . Si un utilisateur présente au un falsifié, le 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 , sans quoi, un faux pourrait voir le jour.

Certains préfèrent une présentation plus graphique, la voici :

(3) Si l'utilisateur souhaite accéder à un service nécessitant son authentification (par exemple un serveur http), il devra demander au un ticket de service spécifique. Le client envoie alors au service serveur kerberos une TGS_REQ contenant :

• le nom du service et de l'hôte que le client souhaite contacter ;
• son (toujours chiffré avec la clé du que le client ne connait donc pas) ;
• un élément d'authentification, probablement un « timestamp », chiffré avec la clé de session du client (partagée avec le ). Ce chiffrement prouvera au que le client est bien celui qu'il prétend être (protection contre le vol éventuel du du client) ;

(4) Le va alors répondre en envoyant au client un ticket contenant :

• une clé de session pour le service demandé , chiffrée avec la clé de session du client , soit ;
• une authentification de client, chiffrée avec la clé du service qui n'est connue que du serveur du service et du , si bien qu'un client mal intentionné ne pourra la modifier. Cette authentification contient également une copie de la clé de session du service , ainsi le client et le service la partagent, mais le client ne peut pas modifier cette clé puisque l'exemplaire destiné au service est chiffré avec une clé qu'il ne connait pas, soit qui est donc un « blob » que le client ne peut lire ni modifier;

Ainsi :

• le peut s'assurer de l'authenticité du client qui a chiffré un timestamp avec sa clé de session ;
• le client va pouvoir s'authentifier dans le service demandé, puisque son accréditation est chiffrée avec la clé du service que le client ne connait pas ;
• le client va transmettre au service une clé de session avec ce service . Le , qui a de l'éthique, s'étant empressé d'oublier cette clé, seuls le client et le service la connaissent.

(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 ;
• son identité et un « timestamp », le tout chiffré avec la clé de session de service, soit ;

(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.

Lorsque le service Kerbérisé reçoit cette requête, comme il dispose de sa clé de service , il peut déchiffrer le « blob » et donc récupérer :

• l'identité de l'utilisateur fournie par le ;
• la clé de session pour le service , également fournie par le .

Il peut alors déchiffrer l'identité , ainsi que le . 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.

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.

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.