L�authentification Kerberos by 9b0l5938

VIEWS: 69 PAGES: 39

									L’authentification Kerberos
Rappels sur Kerberos

 Développé initialement au MIT, dans le cadre
 du projet Athena au début des années 80
 Version courante : Kerberos V5
 V4 et V5 sont non-interopérables




                                                2
Généralités

 Principes
   Basé sur la notion de « Ticket »
   Cryptographie à Clefs secrètes
   Authentification mutuelle
   Tickets limités dans le temps
   Mécanismes anti-rejeux
 Kerberos V5
   Améliorations par rapport à V4 (tickets
   transferrables, time stamps…)
   Standards IETF : RFCs 1510 et 1964        3
Architecture

 L’architecture de Kerberos constitue une architecture
 3 tiers :
    un client
    un serveur de ressources
    une autorité approuvée
 L’autorité approuvée :
    est un serveur dit « de confiance »,
    reconnu comme tel par le client et le serveur
    et dont on présuppose qu’il est parfaitement sécurisé


                                                            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é approuvée :
   stocke les informations de sécurité relatives aux
   principaux
   génère et gère les clefs de session
                                                       5
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.


                                                        6
Notion 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 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 nécessairement
 sur le même serveur


                                                         8
Clefs 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’authentification
 Dans toutes les autres phases, on utilise des clefs de
 session « jetables »

                                                            9
Accès à une ressource
  Description des échanges
Authentification 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 client
 La partie chiffrée l’est avec la clef Ksec du client => seul le bon
 client peut déchiffrer cette partie

                                                                         11
Demande 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 ST
 Le serveur émet un ST pour le client et pour le service considéré




                                                                     12
Accès au service

                   1 : Requête de service



                   2 : Poursuite des échanges


 On utilise le ST obtenu précédemment pour accéder au service
 Le serveur de ressources valide alors (ou non) la requête




                                                                13
Résumé
   AS Service                               TGS Service

                           3 Demande de
                                ST
               2 TGT


         1                                 4 ST
   Connexion


                                    5 Demande d ’accès
                                         au service


                            6                       Serveur de
                       Validation
                                                    ressource
                                                                 14
Génération et composition d’un
            ticket
      Traitement des échanges
Accè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.



                                              16
Génération d’un ticket

                                         Chiffrement
                  Chiffrement

       Clef de
       session



Clef du serveur
 de ressource
                                Ticket                 Transmis
                                                       au client
      Clef du
       client

                                                                   17
Traitement par le client
                                              Chiffrement

 Reçu par                    Authentifiant                  Authentifiant
 Le client

             Déchiffrement




                                          Transmis
 Clef du                                 Au serveur
                                                                            18
  client                                De ressource
Traitement par le serveur
                              Déchiffrement

   Authentifiant                                  Authentifiant


     Reçu par
    Le serveur
   De ressource

                   Déchiffrement



                                            OUI                   NON
                                                  Valide ?




                                    Accès                           Refus
Clef du serveur                                                             19
 de ressource
Structure d’un Ticket Kerberos
 Champ                Description
 tkt-vno              Version (5)
 realm                Royaume d'origine du ticket                               Clair
 sname                Nom de l'AA ayant délivré 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 schéma
 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
                      données spécifiques
Structure d’un authentifiant
(authenticator)
Champ                Description
authenticator-vno    Version (5)
crealm               Royaume d'origine du client
cname                Nom du client
chksum               Somme de contrôle d'intégrité (optionnel)
                     Contient la partie en microsecondes de l'horodatage
cusec
                     client
ctime                Horodatage client
                     Peut préciser une clef de session pour protéger
subkey               l'échange (optionnel. Par défaut, contient la clef de
                     session fournie par l'AA)
seq-number           Numéro de séquence (optionnel)
                     Champ utilisé par les applications pour passer des
authorization-data
                     données spécifiques
                                                                             21
Accès à 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 partagée inter-royaume)
   qui servira à obtenir auprès de l’AA de B un ST
   pour le serveur souhaité.



                                                      23
Schéma de principe
1 : demande d’accès             4 : renvoi d’un ticket pour le serveur
2 : renvoi d’un ticket pour B   5 : demande d’accès
3 : demande d’accès             6 : accès autorisé

                                    Clef partagée



         AA                                                              AA



                          2            3
                                               4
                  1

                                       5
               Client                                                    Serveur
                                               6
                                                                                   24
            Royaume A                                            Royaume B
Contraintes

 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



                                                   25
Structure 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.                    26
Avantages 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 :
   transitives
   bidirectionnelles
                                                27
Kerberos et les applications n-
             tiers
    Mécanismes d’emprunt d’identité
Les 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 »                             29
Tickets Proxy (1/2)

 Principe
   Le 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




                                                         30
Tickets proxy (2/2)

              5                        6                            Serveur 2


                      Serveur 1
                                  1 : Connexion au domaine
                                  2 : Emission d’un 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 transférables (1/2)

 Principe
   Le client obtient un TGT qu’il peut transférer à 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 transférables (2/2)

                            5                       8                            Serveur 2


                                    Serveur 1
                                                4 : Renvoi d’un TGT
                                                transférable pour Serveur1
                        3       4   6           5 : Emission du TGT transférable
                                         7
                   1                            6 : Demande d ’un ST pour
                            2                   Serveur2
                                                7 : Envoi du ST
1 : Connexion au                                8 : Utilisation du ST pour
domaine                                         l’emprunt d’identité du client
2 : Emission d’un
TGT
3 : Demande de ticket
transférable pour le
                                                                                         33
serveur1
Mode transfert

 Avantages                 Inconvénients
 - de requêtes réseau si   + de requêtes réseau si
 plusieurs ressources à    une seule ressource est
 atteindre                 atteinte
 transparent (inutile de   moins sécurisant : le
 connaître le serveur      TGT est une vraie
 atteint)                  délégation de pouvoir
                           nécessité de faire
                           confiance dans le
                           serveur
                                                     34
Mode proxy

 Avantages                 Inconvénients
 - de requêtes réseau si   + de requêtes réseau si
 une seule ressource est   plusieurs ressources à
 atteinte                  atteindre
 plus sécurisant : le ST   non transparent
 n’est valable QUE pour    (nécessite de connaître
 la ressource considérée   le serveur atteint)




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

                                                                  AA
             AA
                                                              Royaume
             Royaume     Clefs partagées inter-royaume



                                                         AA
   AA                   AA


   Royaume                                         Royaume


                                              AA                  AA
                                       Royaume                Royaume
 Structure hiérarchique Kerberos                                        37
Essai de morphing...

                                                                  KDC
             KDC
                                                              Domaine
             Domaine     Relation d ’approbation



                                                        KDC
   KDC                 KDC


   Domaine                                         Domaine


                                            KDC                    KDC
                                     Domaine                  Domaine
 Forêt Windows 2000                                                      38
Conclusions

 L’architecture en domaines de Windows 2000
 n’est qu’un « coup de peinture » appliqué sur
 l’architecture Kerberos
 Elle découle donc directement des travaux du
 MIT…




                                                 39

								
To top