expliquez comme j’ai 5 ans: Kerberos-qu’est-ce que Kerberos, et pourquoi devrais-je m’en soucier?
bien que ce sujet ne puisse probablement pas être expliqué à un enfant de 5 ans et être compris, c’est ma tentative de défragmenter la documentation avec des aides visuelles et un langage digeste.,
en un mot
fondamentalement, Kerberos se résume à ceci:
- Un protocole d’authentification
- utilise des tickets pour s’authentifier
- évite de stocker les mots de passe localement ou de les envoyer sur internet
- implique un tiers de confiance
- construit sur la cryptographie à clé symétrique
Vous avez clé secrète pour le service particulier demandé-sur votre machine locale (la création d’un ticket est décrite ci-dessous); tant qu’il est valide, Vous pouvez accéder au service demandé qui se trouve dans un domaine Kerberos.,
généralement, ceci est utilisé dans les environnements internes / d’entreprise. Peut-être que vous voulez accéder à votre site de paie interne pour examiner le peu de bonus que votre patron vous a donné. Plutôt que de saisir à nouveau vos informations d’identification utilisateur/mot de passe, Votre ticket (mis en cache sur votre système) est utilisé pour s’authentifier, ce qui permet une authentification unique.
Votre billet est actualisé lorsque vous vous connectez à votre ordinateur, ou lorsque vous kinit USER au sein de votre terminal.
pour les gens qui aiment les anecdotes, le nom de Kerberos vient de la mythologie grecque, le chien de garde à trois têtes D’Hadès., C’est assez approprié car il faut un tiers (un centre de Distribution de clés) pour s’authentifier entre un client et un service ou une machine hôte.
Royaume Kerberos
Les administrateurs créent des Royaumes – royaumes Kerberos – qui engloberont tout ce qui est disponible pour accéder. Certes, vous n’avez peut – être pas accès à certains services ou machines hôtes définis dans la gestion des stratégies-les développeurs ne doivent pas accéder à tout ce qui concerne la finance, des choses comme ça. Mais un royaume définit ce que Kerberos gère en termes de qui peut accéder à quoi.,
votre machine, le Client, vit dans ce domaine, ainsi que le service ou l’hôte que vous souhaitez demander et le centre de Distribution de clés, KDC (non, pas le KGB, bien que j’y pense toujours aussi). Dans l’exemple suivant, je sépare le serveur D’authentification et le serveur D’octroi de tickets, mais les deux sont dans le KDC.
à garder À l’arrière de votre esprit
Vous pouvez revenir ici après avoir lu à travers les détails sur la façon dont l’exemple fonctionne.,
lors de la demande d’accès à un service ou à un hôte, trois interactions ont lieu entre vous et:
- Le serveur D’authentification
- Le serveur D’octroi de tickets
- Le service ou la machine hôte auquel vous souhaitez accéder.
d’Autres points importants:
- Avec chaque interaction, vous recevrez deux messages. Chaque message est un message que vous pouvez déchiffrer, et celui que vous ne pouvez pas.
- Le service ou la machine auquel vous demandez l’accès ne communique jamais directement avec le KDC.,
- Le KDC stocke toutes les clés secrètes des machines et services utilisateurs dans sa base de données.
- Les clés secrètes sont des mots de passe plus un sel qui sont hachés – l’algorithme de hachage est choisi lors de l’implémentation de la configuration Kerberos. Pour les services ou les machines hôtes, il n’y a pas de mots de passe (qui le saisirait). Une clé est en fait générée par un administrateur lors de la configuration initiale et mémorisée sur le service/la machine hôte.
- encore une fois, ces clés secrètes sont toutes stockées dans la base de données KDC; rappelez-vous la dépendance des Kerberos à la cryptographie à clé symétrique.,
- Le KDC lui-même est chiffré avec une clé principale pour ajouter une couche de difficulté de voler des clés de la base de données.
- Il existe des configurations et des implémentations Kerberos qui utilisent la cryptographie à clé publique au lieu du chiffrement à clé symétrique.
a part: l’ordre des messages et de leur contenu discuté ici ne reflète pas l’ordre dans lequel ils sont envoyés via TCP ou UDP.
l’exemple ci – dessous décrit ce qui se passe lorsque vous demandez quelque chose à un service HTTP interne-comme des informations concernant la paie dans votre intranet d’entreprise.,
Vous et le Serveur d’Authentification
Vous souhaitez accéder à un Service HTTP, mais d’abord vous devez vous présenter au Serveur d’Authentification. La connexion à votre ordinateur, ou kinit USERNAME, initie cette introduction via une demande en texte brut pour un Ticket octroyant un Ticket (TGT)., Le message en texte clair contient:
- votre nom/ID
- Le nom/ID du service demandé (dans ce cas, le service est le serveur D’octroi de tickets),
- votre adresse réseau (peut être une liste d’adresses IP pour plusieurs machines, ou peut être null si vous voulez utiliser sur n’importe quelle machine), et
- durée de vie demandée pour la validité du TGT,
et est envoyé au serveur D’authentification.
Le Serveur d’Authentification permet de vérifier si vous êtes dans la base de données KDC. Cette vérification est uniquement pour voir si vous existez; aucune information d’identification n’est vérifiée.,
S’il n’y a pas d’erreur (par exemple, l’utilisateur n’est pas trouvé), il générera de manière aléatoire une clé appelée clé de session à utiliser entre vous et le serveur D’octroi de tickets (TGS).
le serveur D’authentification vous enverra ensuite deux messages., Un message est le TGT qui contient:
- votre nom/ID,
- Le nom/ID TGS,
- horodatage,
- votre adresse réseau (peut être une liste d’adresses IP pour plusieurs machines, ou peut être null si vous voulez utiliser sur n’importe quelle machine)
- durée de vie du TGT (peut être ce que vous avez demandé initialement, plus faible si vous ou les clés secrètes du TGS sont sur le point d’expirer, ou une autre limite qui a été implémentée pendant Kerberos Setup), et
- clé de session TGS,
et est crypté avec la clé secrète TGS ., L’autre message contient:
- Le nom/ID TGS,
- horodatage,
- durée de vie (identique à celle ci-dessus) et
- clé de Session TGS
et est crypté avec votre clé secrète Client. Notez que la clé de Session TGS est la clé partagée entre vous et le TGS.
Votre clé secrète Client est déterminée en vous demandant votre mot de passe, en ajoutant un sel (composé de ) et en hachant le tout. Maintenant vous pouvez l’utiliser pour déchiffrer le deuxième message afin d’obtenir la clé de Session TGS., Si le mot de passe est incorrect, vous ne pourrez pas déchiffrer le message. Veuillez noter que c’est l’étape dans laquelle le mot de passe que vous entrez est implicitement validé.
Vous ne pouvez cependant pas déchiffrer le TGT car vous ne connaissez pas la clé secrète TGS. Le TGT chiffré est stocké dans votre cache d’informations d’identification.
vous et le serveur D’octroi de tickets
à ce stade, vous avez le TGT que vous ne pouvez pas lire car vous n’avez pas la clé secrète TGS pour le déchiffrer. Vous avez cependant la clé de Session TGS.,
C’est maintenant à votre tour d’envoyer deux messages. Vous préparez d’abord L’authentificateur, chiffré avec la clé de Session TGS, contenant:
- votre nom/ID, et
- horodatage.
vous envoyez un message non chiffré qui contient:
- Le nom/ID du Service HTTP demandé auquel vous souhaitez accéder, et
- durée de vie du Ticket pour le service HTTP,
ainsi que L’authentificateur chiffré et TGT au serveur D’octroi de tickets.
le serveur D’octroi de tickets va d’abord vérifier la base de données KDC pour voir si le service HTTP existe.,
Si oui, le TGS déchiffre le TGT avec sa Clé Secrète . Puisque le TGT maintenant non chiffré contient la clé de Session TGS, le TGS peut déchiffrer L’authentificateur que vous avez envoyé.,en raison:
- comparez votre ID client de L’authentificateur à celui du TGT
- comparez l’horodatage de l’authentificateur à celui du TGT (la tolérance de différence typique du système Kerberos est de 2 minutes, mais peut être configurée autrement)
- vérifiez si le TGT est expiré (l’élément lifetime),
- vérifiez que l’authentificateur n’est pas si l’adresse réseau dans la demande d’origine n’est pas nulle, compare l’adresse IP de la source à votre adresse réseau (ou dans la liste demandée) dans le TGT.,
le serveur attribuant le Ticket génère alors de manière aléatoire la clé de Session du service HTTP et prépare le ticket de service HTTP pour vous qui contient:
- votre nom/ID,
- nom/ID du service HTTP,
- votre adresse réseau (peut être une liste d’adresses IP pour plusieurs machines, ou peut être null si vous/li>
- clé de session de service HTTP,
et la chiffre avec la clé secrète de Service HTTP.
Ensuite, le TGS vous envoie deux messages., L’un est le Ticket de Service HTTP chiffré; l’autre contient:
- nom/ID du service HTTP,
- horodatage,
- durée de vie de la validité du ticket et
- clé de Session du service HTTP,
qui est chiffrée avec la clé de Session TGS.
votre machine déchiffre ce dernier message avec la clé de Session TGS qu’elle a mise en cache précédemment pour obtenir la clé de Session du service HTTP.
votre machine ne peut cependant pas déchiffrer le Ticket de service HTTP car il est crypté avec la clé secrète de service HTTP.,
vous et le service HTTP
pour accéder maintenant au service HTTP, votre machine prépare un autre message D’authentification qui contient:
- votre nom/ID,
- horodatage,
et est crypté avec la clé de Session du service HTTP. Votre machine envoie ensuite L’authentificateur et le Ticket de Service HTTP encore crypté reçu du TGS.
le service HTTP déchiffre ensuite le Ticket avec sa clé secrète pour obtenir la clé de Session du service HTTP., Il utilise ensuite cette clé de Session pour déchiffrer le message D’authentification que vous avez envoyé.,de L’authentificateur à celui du Ticket,
le service HTTP envoie alors un message D’authentification contenant son ID et son horodatage afin de vous confirmer son identité et est chiffré avec la clé de Session du service HTTP.
votre machine lit le message D’authentification en déchiffrant avec la clé de Session de service HTTP mise en cache et sait qu’elle doit recevoir un message avec L’ID et l’horodatage du service HTTP.
Et maintenant, vous avez été authentifié pour utiliser le Service HTTP., Les demandes futures utilisent le Ticket de service HTTP mis en cache, tant qu’il n’a pas expiré comme défini dans l’attribut lifetime.
alors que j’écrirai plus tard, le service HTTP lui-même doit être capable de prendre en charge Kerberos. De plus, vous devez également avoir un navigateur qui prend en charge SPNEGO/Negotiate.,
peut-être relire les points précédemment décrits; consultez telle ou telle implémentation actuelle, en particulier celle sur laquelle je suis payé pour travailler qui communique avec cette implémentation populaire; ou consultez un tutoriel, un guide de ressources, la vidéo de référence qui m’a été envoyée lorsque j’ai commencé à
Les images ci-dessus ont été rendues avec Keynote avec des icônes utilisées de font awesome et glyphicons, et sont disponibles sur slideshare.