Lauthentification Kerberos

Rappels sur Kerberos

Dvelopp initialement au MIT, dans le cadre du projet Athena au dbut des annes 80 Version courante : Kerberos V5 V4 et V5 sont non-interoprables

Gnralits
Principes
Bas sur la notion de Ticket Cryptographie Clefs secrtes Authentification mutuelle Tickets limits dans le temps Mcanismes anti-rejeux

Kerberos V5
Amliorations par rapport V4 (tickets transferrables, time stamps) Standards IETF : RFCs 1510 et 1964

Architecture
Larchitecture de Kerberos constitue une architecture 3 tiers :
un client un serveur de ressources une autorit approuve

Lautorit approuve :
est un serveur dit de confiance , reconnu comme tel par le client et le serveur et dont on prsuppose quil est parfaitement scuris

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 approuve :

stocke les informations de scurit relatives aux principaux gnre et gre les clefs de session
5

Terminologie (2/2)
Un royaume Kerberos :
est une organisation logique dans laquelle s'excute au moins une AA, est capable dauthentifier les principaux dclars sur ce serveur.

Un KDC (Key Distribution Center):

est le nom donne dans Windows 2000 lautorit approuve.

Notion de ticket
Un ticket est une structure de donnes constitue dune partie chiffre et dune partie claire. Les tickets servent authentifier les requtes des principaux Deux type de Tickets :
Ticket Granting Ticket (TGT) Service Ticket (ST)
7

Services Kerberos
Deux types de services sont requis :
un service dauthentification (AS ou Authentication Service) un service doctroi de tickets (TGS ou Ticket Granting Service)

Ces services ne tournent pas ncessairement sur le mme serveur

Clefs cryptographiques
Dans Kerberos, une AA (ie un KDC) gnre et stocke les clefs secrtes (Ksec) des principaux qui lui sont rattachs. (Dans W2K, Ksec est directement drive du mot de passe de lutilisateur) Pour des raisons de scurit, ces clefs secrtes ne servent que lors de la phase initiale dauthentification Dans toutes les autres phases, on utilise des clefs de session jetables
9

Accs une ressource

Description des changes

Authentification initiale
1 : Requte dauthentification

2 : Emission dun Ticket TGT

La requte initiale contient (en clair) lidentit du requrant et le serveur pour lequel on demande un TGT. Le serveur met un TGT pour le client La partie chiffre lest avec la clef Ksec du client => seul le bon client peut dchiffrer cette partie
11

Demande dun ST
1 : Requte de ticket de service

2 : Emission dun Ticket ST

On utilise le TGT obtenu prcdemment pour requrir un ST Le serveur met un ST pour le client et pour le service considr

12

Accs au service
1 : Requte de service

2 : Poursuite des changes

On utilise le ST obtenu prcdemment pour accder au service Le serveur de ressources valide alors (ou non) la requte

13

Rsum
AS Service
3 Demande de ST 2 TGT

TGS Service

1
Connexion

4 ST

5 Demande d accs au service

6 Validation

Serveur de ressource

14

Gnration et composition dun ticket

Traitement des changes

Accs en trois passes

Gnration du ticket par le serveur et transmission au client, Traitement du ticket par le client et prparation de la requte au serveur, Traitement de la requte par le serveur et poursuite des changes.

16

Gnration dun ticket

Chiffrement Chiffrement
Clef de session

Clef du serveur de ressource

Ticket
Clef du client

Transmis au client

17

Traitement par le client

Chiffrement Reu par Le client Dchiffrement
Authentifiant

Authentifiant

Clef du client

Transmis Au serveur De ressource

18

Traitement par le serveur

Dchiffrement Authentifiant Authentifiant

Reu par Le serveur De ressource

Dchiffrement

OUI

Valide ?

NON

Clef du serveur de ressource

Accs

Refus

19

Structure dun Ticket Kerberos

Champ tkt-vno realm sname flags key crealm cname transited authtime starttime endtime renew-till caddr authorization-data Description Version (5) Royaume d'origine du ticket Nom de l'AA ayant dlivr le ticket Drapeaux d'tats du ticket Clef de session pour l'change futur Royaume d'origine du client Nom du client Liste des royaumes ayant pris part dans le schma d'authentification Horodatage de l'authentification Indique partir de quand le ticket est valide Indique l'expiration du ticket Pour ticket renouvelables ; indique jusqu' quand le ticket peut tre renouvel Contient 0 ou une liste d'adresses depuis lesquelles le ticket est utilisable Champ utilis par les applications pour passer des donnes spcifiques Clair

Chiffr

20

Structure dun authentifiant (authenticator)

Champ authenticator-vno crealm cname chksum cusec ctime subkey seq-number authorization-data Description Version (5) Royaume d'origine du client Nom du client Somme de contrle d'intgrit (optionnel) Contient la partie en microsecondes de l'horodatage client Horodatage client Peut prciser une clef de session pour protger l'change (optionnel. Par dfaut, contient la clef de session fournie par l'AA) Numro de squence (optionnel) Champ utilis par les applications pour passer des donnes spcifiques
21

Accs un autre domaine

Authentication accross boundaries

Principe
Quand un utilisateur dun royaume A souhaite atteindre un serveur dun royaume B :
il contacte sa propre AA, qui lui transmet un Refferal Ticket (TGT chiffr avec une clef partage inter-royaume) qui servira obtenir auprs de lAA de B un ST pour le serveur souhait.

23

Schma de principe
1 : demande daccs 4 : renvoi dun ticket pour le serveur

2 : renvoi dun ticket pour B

3 : demande daccs

5 : demande daccs
6 : accs autoris Clef partage

AA

AA

2 1

3 4

5 Client Royaume A 6

Serveur 24 Royaume B

Contraintes
Sil existe plusieurs royaumes Kerberos, la distribution des clefs suit une complexit exponentielle ! Solution retenue :
une structure hirarchique des royaumes, autorisant laccs aux ressources par rebonds successifs

25

Structure hirarchique

Chaque lien entre royaumes indique le partage dune clef inter-royaume. Lobtention dun ticket se fait de proche en proche.

26

Avantages dune telle architecture

Prserve lisolement des royaumes entre eux. Tout client dun royaume peut accder aux ressources de nimporte quel serveur (si ce dernier lautorise) mme si ce serveur ne fait pas partie du royaume du client. Les relations entre royaumes sont donc :
transitives bidirectionnelles
27

Kerberos et les applications ntiers

Mcanismes demprunt didentit

Les application n-tiers

Un client accde un portail applicatif. Il ne voit que ce portail... ...qui relaie ses demandes auprs des serveurs de ressources adquats. Dans cette architecture, le portail agit directement en lieu et place du client. Deux mthodes utilisables dans Kerberos :
mode proxy mode transfert
29

Tickets Proxy (1/2)

Principe
Le client rcupre un TGS depuis un KDC et le transmet au serveur, Le serveur utilise directement ce TGS pour se connecter la ressource comme sil tait le client

30

Tickets proxy (2/2)

5 6 Serveur 2

Serveur 1 1 : Connexion au domaine 2 : Emission dun TGT avec le flag utilisable en proxy activ 3 : Demande de ticket proxy pour le serveur2, via le serveur1 4 : Emission du ticket proxy

3 1 2

5 : Emission du ticket pour serveur2

6 : Serveur1 emprunte l identit du client pour atteindre serveur2 31

Tickets transfrables (1/2)

Principe
Le client obtient un TGT quil peut transfrer un serveur Le serveur agit alors comme le client, en effectuant une demande de ST au KDC, comme sil tait le client

32

Tickets transfrables (2/2)

5 8 Serveur 2

Serveur 1 4 : Renvoi dun TGT transfrable pour Serveur1 3 1 2 4 6 7 5 : Emission du TGT transfrable 6 : Demande d un ST pour Serveur2 7 : Envoi du ST 8 : Utilisation du ST pour lemprunt didentit du client

1 : Connexion au domaine 2 : Emission dun TGT 3 : Demande de ticket transfrable pour le serveur1

33

Mode transfert
Avantages - de requtes rseau si plusieurs ressources atteindre transparent (inutile de connatre le serveur atteint) Inconvnients + de requtes rseau si une seule ressource est atteinte moins scurisant : le TGT est une vraie dlgation de pouvoir ncessit de faire confiance dans le serveur
34

Mode proxy
Avantages - de requtes rseau si une seule ressource est atteinte plus scurisant : le ST nest valable QUE pour la ressource considre Inconvnients + de requtes rseau si plusieurs ressources atteindre non transparent (ncessite de connatre le serveur atteint)

35

Active Directory et Kerberos

(courte) Etude comparative

Essai de morphing...
AA Royaume Royaume Clefs partages inter-royaume

AA

AA Royaume

AA

AA

Royaume

AA Royaume

AA Royaume 37

Structure hirarchique Kerberos

Essai de morphing...
KDC Domaine Domaine Relation d approbation

KDC

KDC Domaine

KDC

KDC

Domaine

KDC Domaine

KDC Domaine 38

Fort Windows 2000

Conclusions
Larchitecture en domaines de Windows 2000 nest quun coup de peinture appliqu sur larchitecture Kerberos Elle dcoule donc directement des travaux du MIT

39