Vous êtes sur la page 1sur 39

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

2
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 3
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

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

6
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

8
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 TGS Service

3 Demande de
ST
2 TGT

1 4 ST
Connexion

5 Demande d accs
au service

6 Serveur de
Validation
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 Transmis
au client
Clef du
client

17
Traitement par le client
Chiffrement

Reu par Authentifiant Authentifiant


Le client

Dchiffrement

Transmis
Clef du Au serveur
18
client De ressource
Traitement par le serveur
Dchiffrement

Authentifiant Authentifiant

Reu par
Le serveur
De ressource

Dchiffrement

OUI NON
Valide ?

Accs Refus
Clef du serveur 19
de ressource
Structure dun Ticket Kerberos
Champ Description
tkt-vno Version (5)
realm Royaume d'origine du ticket Clair
sname Nom de l'AA ayant dlivr le ticket
flags Drapeaux d'tats du ticket
key Clef de session pour l'change futur
crealm Royaume d'origine du client
cname Nom du client
Liste des royaumes ayant pris part dans le schma
transited
d'authentification
authtime Horodatage de l'authentification
starttime Indique partir de quand le ticket est valide Chiffr
endtime Indique l'expiration du ticket
Pour ticket renouvelables ; indique jusqu' quand le
renew-till
ticket peut tre renouvel
Contient 0 ou une liste d'adresses depuis lesquelles le
caddr
ticket est utilisable
Champ utilis par les applications pour passer des
authorization-data 20
donnes spcifiques
Structure dun authentifiant
(authenticator)
Champ Description
authenticator-vno Version (5)
crealm Royaume d'origine du client
cname Nom du client
chksum Somme de contrle d'intgrit (optionnel)
Contient la partie en microsecondes de l'horodatage
cusec
client
ctime Horodatage client
Peut prciser une clef de session pour protger
subkey l'change (optionnel. Par dfaut, contient la clef de
session fournie par l'AA)
seq-number Numro de squence (optionnel)
Champ utilis par les applications pour passer des
authorization-data
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 5 : demande daccs
3 : demande daccs 6 : accs autoris

Clef partage

AA AA

2 3
4
1

5
Client Serveur
6
24
Royaume A 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 n-
tiers
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
3 le flag utilisable en proxy
4 activ
1 3 : Demande de ticket proxy
2
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

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 4 6 5 : Emission du TGT transfrable
7
1 6 : Demande d un ST pour
2 Serveur2
7 : Envoi du ST
1 : Connexion au 8 : Utilisation du ST pour
domaine lemprunt didentit du client
2 : Emission dun
TGT
3 : Demande de ticket
transfrable pour le
33
serveur1
Mode transfert

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

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

35
Active Directory et Kerberos
(courte) Etude comparative
Essai de morphing...

AA
AA
Royaume
Royaume Clefs partages inter-royaume

AA
AA AA

Royaume Royaume

AA AA
Royaume Royaume
Structure hirarchique Kerberos 37
Essai de morphing...

KDC
KDC
Domaine
Domaine Relation d approbation

KDC
KDC KDC

Domaine Domaine

KDC KDC
Domaine Domaine
Fort Windows 2000 38
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