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…