L’authentification Kerberos

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

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

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é

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

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.

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)

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

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 »

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

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

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é

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

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

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

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.

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

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

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

Structure d’un Ticket Kerberos

Structure d’un authentifiant (authenticator)

Accès à un autre domaine Authentication accross boundaries

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

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

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

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.

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

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

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 »

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

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

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

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

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

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)

Active Directory et Kerberos (courte) Etude comparative

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

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

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…