L’authentification Kerberos

Présentation au sujet: "L’authentification Kerberos"— Transcription de la présentation:

1 L’authentification Kerberos

2 Rappels sur Kerberos Développé initialement au MIT, dans le cadre du projet Athena au début des années 80 Version courante : Kerberos V5 V4 et V5 sont non-interopérables

3 Généralités Principes Kerberos V5 Basé sur la notion de « Ticket »
Cryptographie à Clefs secrètes Authentification mutuelle Tickets limités dans le temps Mécanismes anti-rejeux Kerberos V5 Améliorations par rapport à V4 (tickets transferrables, time stamps…) Standards IETF : RFCs 1510 et 1964

4 Architecture L’architecture de Kerberos constitue une architecture 3 tiers : un client un serveur de ressources une autorité approuvée L’autorité approuvée : est un serveur dit « de confiance », reconnu comme tel par le client et le serveur et dont on présuppose qu’il est parfaitement sécurisé

5 Terminologie (1/2) Un « principal » Kerberos :
est un client Kerberos, identifiable par un nom unique. Un utilisateur, un client, un serveur sont des « principaux » Kerberos Une autorité approuvée : stocke les informations de sécurité relatives aux principaux génère et gère les clefs de session

6 Terminologie (2/2) Un « royaume » Kerberos :
est une organisation logique dans laquelle s'exécute au moins une AA, est capable d’authentifier les principaux déclarés sur ce serveur. Un KDC (Key Distribution Center): est le nom donnée dans Windows 2000 à l’autorité approuvée.

7 Notion de ticket Un ticket est une structure de données constituée d’une partie chiffrée et d’une partie claire. Les tickets servent à authentifier les requêtes des principaux Deux type de Tickets : Ticket Granting Ticket (TGT) Service Ticket (ST)

8 Services Kerberos Deux types de services sont requis :
un service d’authentification (AS ou Authentication Service) un service d’octroi de tickets (TGS ou Ticket Granting Service) Ces services ne tournent pas nécessairement sur le même serveur

9 Clefs cryptographiques
Dans Kerberos, une AA (ie un KDC) génère et stocke les clefs secrètes (Ksec) des principaux qui lui sont rattachés. (Dans W2K, Ksec est directement dérivée du mot de passe de l’utilisateur) Pour des raisons de sécurité, ces clefs secrètes ne servent que lors de la phase initiale d’authentification Dans toutes les autres phases, on utilise des clefs de session « jetables »

10 Description des échanges
Accès à une ressource Description des échanges

11 Authentification initiale
1 : Requête d’authentification 2 : Emission d’un Ticket TGT La requête initiale contient (en clair) l’identité du requérant et le serveur pour lequel on demande un TGT. Le serveur émet un TGT pour le client La partie chiffrée l’est avec la clef Ksec du client => seul le bon client peut déchiffrer cette partie

12 Demande d’un ST 1 : Requête de ticket de service 2 : Emission d’un Ticket ST On utilise le TGT obtenu précédemment pour requérir un ST Le serveur émet un ST pour le client et pour le service considéré

13 Accès au service 1 : Requête de service 2 : Poursuite des échanges On utilise le ST obtenu précédemment pour accéder au service Le serveur de ressources valide alors (ou non) la requête

14 Résumé TGS Service AS Service Serveur de ressource 3 Demande de ST 2
TGT 1 Connexion 4 ST 5 Demande d ’accès au service 6 Validation Serveur de ressource

15 Génération et composition d’un ticket
Traitement des échanges

16 Accès en trois passes Génération du ticket par le serveur et transmission au client, Traitement du ticket par le client et préparation de la requête au serveur, Traitement de la requête par le serveur et poursuite des échanges.

17 Génération d’un ticket
Chiffrement Ticket Chiffrement Clef de session Transmis au client Clef du serveur de ressource Clef du client

18 Traitement par le client
Chiffrement Authentifiant Authentifiant Reçu par Le client Déchiffrement Transmis Au serveur De ressource Clef du client

19 Traitement par le serveur
Déchiffrement Authentifiant Authentifiant Reçu par Le serveur De ressource Valide ? Déchiffrement OUI Accès NON Refus Clef du serveur de ressource

20 Structure d’un Ticket Kerberos

21 Structure d’un authentifiant (authenticator)

22 Accès à un autre domaine
Authentication accross boundaries

23 Principe Quand un utilisateur d’un royaume A souhaite atteindre un serveur d’un royaume B : il contacte sa propre AA, qui lui transmet un Refferal Ticket (TGT chiffré avec une clef partagée inter-royaume) qui servira à obtenir auprès de l’AA de B un ST pour le serveur souhaité.

24 Schéma de principe 1 : demande d’accès
4 : renvoi d’un ticket pour le serveur 2 : renvoi d’un ticket pour B 5 : demande d’accès 3 : demande d’accès 6 : accès autorisé Clef partagée AA AA 3 4 2 1 5 Serveur Client 6 Royaume A Royaume B

25 Contraintes S’il existe plusieurs royaumes Kerberos, la distribution des clefs suit une complexité exponentielle ! Solution retenue : une structure hiérarchique des royaumes, autorisant l’accès aux ressources par rebonds successifs

26 Structure hiérarchique
Chaque lien entre royaumes indique le partage d’une clef inter-royaume. L’obtention d’un ticket se fait de proche en proche.

27 Avantages d’une telle architecture
Préserve l’isolement des royaumes entre eux. Tout client d’un royaume peut accéder aux ressources de n’importe quel serveur (si ce dernier l’autorise)… …même si ce serveur ne fait pas partie du royaume du client. Les relations entre royaumes sont donc : transitives bidirectionnelles

28 Kerberos et les applications n-tiers
Mécanismes d’emprunt d’identité

29 Les application n-tiers
Un client accède à un « portail » applicatif. Il ne voit que ce portail... ...qui relaie ses demandes auprès des serveurs de ressources adéquats. Dans cette architecture, le portail agit directement en lieu et place du client. Deux méthodes utilisables dans Kerberos : mode « proxy » mode « transfert »

30 Tickets Proxy (1/2) Principe
Le client récupère un TGS depuis un KDC et le transmet au serveur, Le serveur utilise directement ce TGS pour se connecter à la ressource comme s’il était le client

31 Tickets proxy (2/2) 5 6 Serveur 2 4 3 Serveur 1 2 1
1 : Connexion au domaine 2 : Emission d’un TGT avec le flag « utilisable en proxy » activé 3 : Demande de ticket proxy pour le serveur2, via le serveur1 4 : Emission du ticket proxy 5 : Emission du ticket pour serveur2 6 : Serveur1 emprunte l ’identité du client pour atteindre serveur2

32 Tickets transférables (1/2)
Principe Le client obtient un TGT qu’il peut transférer à un serveur Le serveur agit alors comme le client, en effectuant une demande de ST au KDC, comme s’il était le client

33 Tickets transférables (2/2)
5 8 Serveur 2 4 3 Serveur 1 2 1 4 : Renvoi d’un TGT transférable pour Serveur1 6 7 5 : Emission du TGT transférable 6 : Demande d ’un ST pour Serveur2 7 : Envoi du ST 1 : Connexion au domaine 8 : Utilisation du ST pour l’emprunt d’identité du client 2 : Emission d’un TGT 3 : Demande de ticket transférable pour le serveur1

34 Mode transfert Avantages
- de requêtes réseau si plusieurs ressources à atteindre transparent (inutile de connaître le serveur atteint) Inconvénients + de requêtes réseau si une seule ressource est atteinte moins sécurisant : le TGT est une vraie délégation de pouvoir nécessité de faire confiance dans le serveur

35 Mode proxy Avantages - de requêtes réseau si une seule ressource est atteinte plus sécurisant : le ST n’est valable QUE pour la ressource considérée Inconvénients + de requêtes réseau si plusieurs ressources à atteindre non transparent (nécessite de connaître le serveur atteint)

36 Active Directory et Kerberos
(courte) Etude comparative

37 Essai de morphing... Structure hiérarchique Kerberos AA AA Royaume
Clefs partagées inter-royaume AA AA AA Royaume Royaume AA AA Royaume Royaume Structure hiérarchique Kerberos

38 Essai de morphing... Forêt Windows 2000 KDC KDC Domaine Domaine
Relation d ’approbation KDC KDC KDC Domaine Domaine KDC KDC Domaine Domaine Forêt Windows 2000

39 Conclusions L’architecture en domaines de Windows 2000 n’est qu’un « coup de peinture » appliqué sur l’architecture Kerberos Elle découle donc directement des travaux du MIT…