L’authentification Kerberos

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 • 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. Accès à une ressource Description des échanges

11. 1 : Requête d’authentification 2 : Emission d’un Ticket TGT Authentification initiale 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. 1 : Requête de ticket de service 2 : Emission d’un Ticket ST Demande d’un 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. 1 : Requête de service 2 : Poursuite des échanges Accès au service 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. TGS Service AS Service 3 Demande de ST TGT 2 ST 1 4 Connexion 5 Demande d ’accès au service 6 Validation Résumé 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. Chiffrement Chiffrement Clef de session Clef du serveur de ressource Transmis au client Ticket Clef du client Génération d’un ticket

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

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

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. 1 : demande d’accès Clef partagée 3 2 4 1 5 6 Schéma de principe 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é AA AA Serveur Client 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. 5 6 1 : Connexion au domaine 3 4 1 2 Tickets proxy (2/2) Serveur 2 Serveur 1 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. 5 8 4 : Renvoi d’un TGT transférable pour Serveur1 1 : Connexion au domaine 3 6 4 7 1 2 Tickets transférables (2/2) Serveur 2 Serveur 1 5 : Emission du TGT transférable 6 : Demande d ’un ST pour Serveur2 7 : Envoi du ST 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. 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 Mode transfert

35. 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) Mode proxy

36. Active Directory et Kerberos (courte) Etude comparative

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

38. Essai de morphing... 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…