Vous êtes sur la page 1sur 39

L authentification 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
L architecture de Kerberos constitue une architecture 3 tiers :
un client un serveur de ressources une autorit approuve

L autorit approuve :
est un serveur dit de confiance , reconnu comme tel par le client et le serveur et dont on prsuppose qu il 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 d authentifier les principaux dclars sur ce serveur.

Un KDC (Key Distribution Center):


est le nom donne dans Windows 2000 l autorit approuve.

Notion de ticket
Un ticket est une structure de donnes constitue d une partie chiffre et d une 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 d authentification (AS ou Authentication Service) un service d octroi 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 l utilisateur) Pour des raisons de scurit, ces clefs secrtes ne servent que lors de la phase initiale d authentification 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) l identit du requrant et le serveur pour lequel on demande un TGT. Le serveur met un TGT pour le client La partie chiffre l est avec la clef Ksec du client => seul le bon client peut dchiffrer cette partie
11

Demande d un 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 d un 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 d un 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 d un Ticket Kerberos


t tm m f y m m t t t tm t tt m tm w-t C N L ' H I I P t C t C V N ri i (5) y m ' t t m 'AA y t t t p ' t t t t f p ' f t y m ' t m t t y m y tp p t t tf t t ' t tf t p t t t t ' p t t t t t b ; j ' tp t t t t0 t ' p t t t b mp t p pp t p p p f C

C ff

z t

20

Structure d un authentifiant (authenticator)


authenticator-vno crealm cname chksum cusec ctime subkey seq-number authorization-data Version (5) Royaume d'origine du client Nom du client Somme de contrle d'intgrit (optionnel) ontient 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) hamp utilis par les applications pour passer des donnes spcifiques
21

Accs 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 partage inter-royaume) qui servira obtenir auprs de l AA de B un ST pour le serveur souhait.

23

Schma de principe
1 : demande daccs 2 : renvoi dun ticket our B 3 : demande daccs 4 : renvoi dun ticket our le serveur 5 : demande daccs 6 : accs autoris Clef artage

AA

AA

2 1

3 4

5 Client Ro aume A 6

Serveur 24 Ro aume B

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

25

Structure hirarchique

Chaque lien entre ro aumes indique le artage dune clef inter ro aume. Lo tention dun ticket se fait de roche en roche.

26

Avantages d une telle architecture


Prserve l isolement des royaumes entre eux. Tout client d un royaume peut accder aux ressources de n importe quel serveur (si ce dernier l autorise) 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 d emprunt d identit

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 s il 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 utilisa le en rox activ 3 : Demande de ticket rox our le serveur2, via le serveur1 4 : Emission du ticket rox 5 : Emission du ticket our serveur2 6 : Serveur1 em runte l identit du client our atteindre serveur2 31

3 1 2

Tickets transfrables (1/2)


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

32

Tickets transfrables (2/2)


5 8 Serveur 2

Serveur 1 4 : Renvoi dun TGT transfra le our Serveur1 3 1 2 1 : Connexion au domaine 2 : Emission dun TGT 3 : Demande de ticket transfra le our le serveur1 4 6 7 5 : Emission du TGT transfra le 6 : Demande d un ST our Serveur2 7 : Envoi du ST 8 : Utilisation du ST our lem runt didentit du client

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 n est 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 Ro aume Ro aume Clefs artages inter ro aume

AA

AA

AA

AA

Ro aume

Ro aume

AA

AA Ro aume 37

Structure hirarchique Kerberos

Ro aume

Essai de morphing...
KDC KDC Domaine Domaine Relation d a ro ation

KDC KDC KDC

Domaine

Domaine

KDC

KDC Domaine 38

Fort Windows 2000

Domaine

Conclusions
L architecture en domaines de Windows 2000 n est qu un coup de peinture appliqu sur l architecture Kerberos Elle dcoule donc directement des travaux du MIT

39