Upload
ahmed-elkasimi
View
20
Download
0
Embed Size (px)
Citation preview
L’authentification KerberosL’authentification Kerberos
2
Rappels sur KerberosRappels sur Kerberos
Développé initialement au MIT, dans le cadre du projet Athena au début des années 80Version courante : Kerberos V5V4 et V5 sont non-interopérables
Développé initialement au MIT, dans le cadre du projet Athena au début des années 80Version courante : Kerberos V5V4 et V5 sont non-interopérables
3
GénéralitésGénéralités
PrincipesBasé sur la notion de « Ticket »Cryptographie à Clefs secrètesAuthentification mutuelleTickets limités dans le tempsMécanismes anti-rejeux
Kerberos V5Améliorations par rapport à V4 (tickets transferrables, time stamps…)Standards IETF : RFCs 1510 et 1964
PrincipesBasé sur la notion de « Ticket »Cryptographie à Clefs secrètesAuthentification mutuelleTickets limités dans le tempsMécanismes anti-rejeux
Kerberos V5Améliorations par rapport à V4 (tickets transferrables, time stamps…)Standards IETF : RFCs 1510 et 1964
4
ArchitectureArchitecture
L’architecture de Kerberos constitue une architecture 3 tiers :
un clientun serveur de ressourcesune autorité approuvée
L’autorité approuvée :est un serveur dit « de confiance », reconnu comme tel par le client et le serveuret dont on présuppose qu’il est parfaitement sécurisé
L’architecture de Kerberos constitue une architecture 3 tiers :
un clientun serveur de ressourcesune autorité approuvée
L’autorité approuvée :est un serveur dit « de confiance », reconnu comme tel par le client et le serveuret dont on présuppose qu’il est parfaitement sécurisé
5
Terminologie (1/2)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 principauxgénère et gère les clefs de session
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 principauxgénère et gère les clefs de session
6
Terminologie (2/2)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.
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 ticketNotion 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 principauxDeux type de Tickets :
Ticket Granting Ticket (TGT)Service Ticket (ST)
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 principauxDeux type de Tickets :
Ticket Granting Ticket (TGT)Service Ticket (ST)
8
Services KerberosServices 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
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 cryptographiquesClefs 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’authentificationDans toutes les autres phases, on utilise des clefs de session « jetables »
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’authentificationDans toutes les autres phases, on utilise des clefs de session « jetables »
Accès à une ressourceAccès à une ressource
Description des échangesDescription des échanges
11
Authentification initialeAuthentification 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 clientLa partie chiffrée l’est avec la clef Ksec du client => seul le bon client peut déchiffrer cette partie
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 clientLa partie chiffrée l’est avec la clef Ksec du client => seul le bon client peut déchiffrer cette partie
12
Demande d’un STDemande 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 STLe serveur émet un ST pour le client et pour le service considéré
On utilise le TGT obtenu précédemment pour requérir un STLe serveur émet un ST pour le client et pour le service considéré
13
Accès au serviceAccès au service
1 : Requête de service
2 : Poursuite des échanges
On utilise le ST obtenu précédemment pour accéder au serviceLe serveur de ressources valide alors (ou non) la requête
On utilise le ST obtenu précédemment pour accéder au serviceLe serveur de ressources valide alors (ou non) la requête
14
RésuméRésumé
1
Connexion
2 TGT
3 Demande deST
4 ST
5 Demande d ’accèsau service
6
Validation
AS Service TGS Service
Serveur deressource
Génération et composition d’un ticket
Génération et composition d’un ticket
Traitement des échangesTraitement des échanges
16
Accès en trois passesAccè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 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 ticketGénération d’un ticket
Transmisau client
Ticket
Clef desession
Clef du serveurde ressource
Clef duclient
Chiffrement
Chiffrement
18
Traitement par le clientTraitement par le client
Clef duclient
Authentifiant
TransmisAu serveur
De ressource
Reçu parLe client
Déchiffrement
Chiffrement
Authentifiant
19
Traitement par le serveurTraitement par le serveur
Clef du serveurde ressource
Valide ?OUI
Accès
NON
Refus
Authentifiant
Reçu parLe serveur
De ressource
Déchiffrement
Déchiffrement
Authentifiant
20
Structure d’un Ticket KerberosStructure d’un Ticket Kerberos
Champ Descriptiontkt-vno Version (5)realm Royaume d'origine du ticketsname Nom de l'AA ayant délivré le ticketflags Drapeaux d'états du ticketkey Clef de session pour l'échange futurcrealm Royaume d'origine du clientcname Nom du client
transitedListe des royaumes ayant pris part dans le schéma d'authentification
authtime Horodatage de l'authentificationstarttime Indique à partir de quand le ticket est valideendtime Indique l'expiration du ticket
renew-tillPour ticket renouvelables ; indique jusqu'à quand le ticket peut être renouvelé
caddrContient 0 ou une liste d'adresses depuis lesquelles le ticket est utilisable
authorization-dataChamp utilisé par les applications pour passer des données spécifiques
Clair
Chiffré
21
Structure d’un authentifiant (authenticator)Structure d’un authentifiant (authenticator)
Champ Descriptionauthenticator-vno Version (5)crealm Royaume d'origine du clientcname Nom du clientchksum Somme de contrôle d'intégrité (optionnel)
cusecContient la partie en microsecondes de l'horodatage client
ctime Horodatage client
subkeyPeut préciser une clef de session pour protéger l'échange (optionnel. Par défaut, contient la clef de session fournie par l'AA)
seq-number Numéro de séquence (optionnel)
authorization-dataChamp utilisé par les applications pour passer des données spécifiques
Accès à un autre domaineAccès à un autre domaine
Authentication accross boundariesAuthentication accross boundaries
23
PrincipePrincipe
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é.
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 principeSchéma de principe
Royaume A Royaume B
Clef partagée
AA AA
ServeurClient
1
2 34
5
6
1 : demande d’accès
2 : renvoi d’un ticket pour B
3 : demande d’accès
4 : renvoi d’un ticket pour le serveur
5 : demande d’accès
6 : accès autorisé
25
ContraintesContraintes
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
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érarchiqueStructure 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 architectureAvantages 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 :
transitivesbidirectionnelles
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 :
transitivesbidirectionnelles
Kerberos et les applications n-tiers
Kerberos et les applications n-tiers
Mécanismes d’emprunt d’identitéMécanismes d’emprunt d’identité
29
Les application n-tiersLes 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 »
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)Tickets Proxy (1/2)
PrincipeLe 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
PrincipeLe 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)Tickets proxy (2/2)
12
3 4
5 6
1 : Connexion au domaine2 : 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
6 : Serveur1 emprunte l ’identité du client pour atteindre serveur2
5 : Emission du ticket pour serveur2
Serveur 1
Serveur 2
32
Tickets transférables (1/2)Tickets transférables (1/2)
PrincipeLe client obtient un TGT qu’il peut transférer à un serveurLe serveur agit alors comme le client, en effectuant une demande de ST au KDC, comme s’il était le client
PrincipeLe client obtient un TGT qu’il peut transférer à un serveurLe serveur agit alors comme le client, en effectuant une demande de ST au KDC, comme s’il était le client
33
4 : Renvoi d’un TGT transférable pour Serveur1
Tickets transférables (2/2)Tickets transférables (2/2)
12
3 4
5 8
1 : Connexion audomaine
2 : Emission d’un TGT3 : Demande de ticket transférable pour le serveur1
5 : Emission du TGT transférable
7 : Envoi du ST
6 : Demande d ’un ST pour Serveur2
Serveur 1
Serveur 2
67
8 : Utilisation du ST pour l’emprunt d’identité du client
34
Mode transfertMode transfert
Avantages- de requêtes réseau si plusieurs ressources à atteindretransparent (inutile de connaître le serveur atteint)
Avantages- de requêtes réseau si plusieurs ressources à atteindretransparent (inutile de connaître le serveur atteint)
Inconvénients+ de requêtes réseau si une seule ressource est atteintemoins sécurisant : le TGT est une vraie délégation de pouvoirnécessité de faire confiance dans le serveur
Inconvénients+ de requêtes réseau si une seule ressource est atteintemoins sécurisant : le TGT est une vraie délégation de pouvoirnécessité de faire confiance dans le serveur
35
Mode proxyMode proxy
Avantages- de requêtes réseau si une seule ressource est atteinteplus sécurisant : le ST n’est valable QUE pour la ressource considérée
Avantages- de requêtes réseau si une seule ressource est atteinteplus sécurisant : le ST n’est valable QUE pour la ressource considérée
Inconvénients+ de requêtes réseau si plusieurs ressources à atteindrenon transparent (nécessite de connaître le serveur atteint)
Inconvénients+ de requêtes réseau si plusieurs ressources à atteindrenon transparent (nécessite de connaître le serveur atteint)
Active Directory et KerberosActive Directory et Kerberos
(courte) Etude comparative(courte) Etude comparative
37
Essai de morphing...Essai de morphing...
AA
AA AAAA
AA
AA AA
Royaume
Royaume
Royaume
Royaume
Royaume Royaume
Clefs partagées inter-royaume
Structure hiérarchique Kerberos
38
Essai de morphing...Essai de morphing...
KDC
KDC KDCKDC
KDC
KDC KDC
Domaine
Domaine
Domaine
Domaine
Domaine Domaine
Relation d ’approbation
Forêt Windows 2000
39
ConclusionsConclusions
L’architecture en domaines de Windows 2000 n’est qu’un « coup de peinture » appliqué sur l’architecture KerberosElle découle donc directement des travaux du MIT…
L’architecture en domaines de Windows 2000 n’est qu’un « coup de peinture » appliqué sur l’architecture KerberosElle découle donc directement des travaux du MIT…