Terminologie Kerberos

La section suivante présente les termes Kerberos et leurs définitions. Ces termes sont utilisés dans la documentation Kerberos. Une bonne compréhension de ces termes est essentielle pour appréhender les concepts Kerberos.

Terminologie spécifique à Kerberos

Vous devez comprendre les termes de cette section pour pouvoir administrer les KDC.

Le Centre de distribution des clés (Key Distribution Center) ou KDC est le composant de Kerberos responsable de l'émission d'informations d'identification. Ces informations d'identification sont créées à l'aide des informations stockées dans la base de données KDC. Chaque domaine a besoin d'au moins deux KDC, un maître et au moins un esclave. Tous les KDC génèrent des informations d'identification, mais seul le KDC maître gère toutes les modifications apportées à la base de données KDC.

Un fichier stash contient la clé principale du KDC. Cette clé est utilisée lorsqu'un serveur est redémarré pour authentifier automatiquement le KDC avant qu'il ne démarre les commandes kadmind et krb5kdc. Etant donné que ce fichier inclut la clé principale, ce fichier et toutes ses sauvegardes doivent être sécurisés. Le fichier est créé avec des autorisations en lecture seule pour root. Pour garder le fichier sécurisé, vous ne devez pas modifier les autorisations. Si le fichier est compromis, la clé peut être utilisée pour accéder à la base de données KDC ou la modifier.

Terminologie spécifique à l'authentification

Vous devez connaître les termes de cette section pour comprendre le processus d'authentification. Les programmeurs et les administrateurs système doivent être familiarisés avec ces termes.

Un client est un logiciel qui s'exécute sur le poste de travail d'un utilisateur. Le logiciel Kerberos qui s'exécute sur le client effectue de nombreuses demandes au cours de ce processus. Par conséquent, il est important de différencier les actions de ce logiciel de celles de l'utilisateur.

Les termes server et service sont souvent interchangeables. Pour clarifier, le terme server est utilisé pour définir le système physique sur lequel le logiciel Kerberos est en cours d'exécution. Le terme service correspond à une fonction particulière prise en charge sur un serveur (par exemple, ftp ou nfs). Dans la plupart des cas, la documentation mentionne les serveurs dans le cadre d'un service, mais cette définition obscurcit la signification des termes. Par conséquent, le terme server fait référence au système physique. Le terme service désigne le logiciel.

Le produit Kerberos utilise deux types de clés. Un type de clé est dérivé du mot de passe. Chaque principal d'utilisateur reçoit une clé dérivée du mot de passe qui n'est connue que du KDC et de l'utilisateur. L'autre type de clé utilisé par le produit Kerberos est une clé aléatoire qui n'est pas associée à un mot de passe et donc n'est pas adapté à l'utilisation par les principaux d'utilisateur. Les clés aléatoires sont généralement utilisées pour les principaux de service qui ont des entrées dans un fichier keytab et les clés de session générées par le KDC. Les principaux de service peuvent utiliser des clés aléatoires étant donné que le service peut accéder à la clé dans le fichier keytab qui lui permet de fonctionner de manière non interactive. Les clés de session sont générées par le KDC (et partagées entre le client et le service) pour assurer la sécurité des transactions entre un client et un service.

Un ticket est un paquet d'informations servant à transmettre en toute sécurité l'identité d'un utilisateur à un serveur ou un service. Un ticket n'est valable que pour un client et un service particulier sur un serveur spécifique. Un ticket contient les informations suivantes :

• Nom du principal du service

• Nom du principal de l'utilisateur

• Adresse IP de l'hôte de l'utilisateur

• Horodatage

• Valeur définissant la durée de vie du ticket.

• Copie de la clé de session

Toutes ces données sont chiffrées dans la clé de service du serveur. Notez que le KDC émet le ticket incorporé dans des informations d'identification décrites ci-dessous. Une fois le ticket émis, il peut être réutilisé jusqu'à son expiration.

Les informations d'identification sont un paquet d'informations comprenant un ticket et la clé de session correspondante. Les informations d'identification sont chiffrées avec la clé du principal effectuant la demande. En règle générale, le KDC génère des informations d'identification en réponse à une demande de ticket d'un client.

Un authentificateur correspond à des informations utilisées par le serveur pour authentifier le principal de l'utilisateur du client. Un authentificateur inclut le nom du principal de l'utilisateur, un horodatage et d'autres données. A la différence d'un ticket, un authentificateur ne peut servir qu'une seule fois, généralement lorsque l'accès à un service est demandé. Un authentificateur est chiffré à l'aide de la clé de session partagée par le client et le serveur. En général, le client crée l'authentificateur et l'envoie à l'aide du ticket du serveur ou du service pour s'authentifier auprès du serveur ou du service.

Types de tickets

Les tickets ont des propriétés qui régissent la façon dont ils peuvent être utilisés. Ces propriétés sont assignées au ticket lors de sa création et peuvent être modifiées ultérieurement. Par exemple, un ticket peut passer de transmissible à transmis. Vous pouvez visualiser les propriétés de ticket à l'aide de la commande klist. Voir Affichage des tickets Kerberos.

Les tickets peuvent être décrits par un ou plusieurs des termes suivants :

Transmissible/transmis (Forwardable/forwarded)

Un ticket transmissible peut être envoyé à partir d'un hôte vers un autre hôte, supprimant la nécessité d'un client de se réauthentifier. Par exemple, si l'utilisateur david obtient un ticket transmissible sur la machine de l'utilisateur jennifer, il peut se connecter à sa propre machine sans devoir demander un nouveau ticket (et donc s'authentifier à nouveau). Pour consulter un exemple d'utilisation d'un ticket transmissible, reportez-vous à l'Exemple 24-1.

Initial

Un ticket initial est un ticket émis directement, et non sur la base d'un ticket d'octroi de tickets. Certains services, tels que les applications modifiant les mots de passe, peuvent nécessiter des tickets marqués comme étant initiaux afin d'assurer que le client peut démontrer qu'il connaît sa clé secrète. Un ticket initial indique que le client s'est récemment authentifié et ne dépend pas d'un ticket d'octroi de tickets qui peut exister depuis un certain temps.

Non valide (Invalid)

Un ticket non valide est un ticket postdaté qui n'est pas encore devenu utilisable. Un ticket non valide est rejeté par un serveur d'application jusqu'à ce qu'il soit validé. Pour être validé, un ticket doit être présenté au KDC par le client dans une demande de TGS, avec l'indicateur VALIDATE, après l'heure de début.

Postdatable/postdaté (Postdatable/postdated)

Un ticket postdaté est un ticket qui ne devient valide qu'après une période spécifiée après sa création. Par exemple, un tel ticket peut être utile avec les tâches exécutées par lots la nuit car le ticket, s'il est volé, ne peut pas être utilisé tant que l'exécution de ces tâches n'a pas eu lieu. Lorsqu'un ticket postdaté est émis, il est émis en tant que non valide et le reste jusqu'à ce que son heure de début soit dépassée, et que le client demande la validation par le KDC. Un ticket postdaté est normalement valide jusqu'à l'heure d'expiration du ticket d'octroi de tickets. Toutefois, si le ticket est marqué comme renouvelable, sa durée de vie est normalement égale à la durée de vie entière du ticket d'octroi de tickets.

Utilisable avec proxy/proxy (Proxiable/proxy)

Parfois, il est nécessaire à un principal de permettre à un service d'effectuer une opération en son nom. Le nom du principal du proxy doit être spécifié lorsque le ticket est créé. La version Oracle Solaris ne prend pas en charge les tickets utilisables avec proxy ou les tickets proxy.

Un ticket utilisable avec proxy est similaire à un ticket transmissible, à ceci près qu'il n'est valide que pour un seul service, tandis qu'un ticket transmissible accorde l'utilisation complète de l'identité du client au service. Un ticket transmissible peut par conséquent être considéré comme une sorte de super-proxy.

Renouvelable (Renewable)

Comme les tickets avec de très longues durées de vie impliquent un risque de sécurité, les tickets peuvent être désignés comme renouvelables. Un ticket renouvelable possède deux moments d'expiration : l'heure à laquelle l'instance courante du ticket expire et la durée de vie maximale de tout ticket (une semaine). Si un client souhaite continuer à utiliser un ticket, il peut le renouveler avant sa première expiration. Par exemple, un ticket peut être valide pendant une heure, et tous les tickets ont une durée de vie maximale de dix heures. Si le client détenant le ticket souhaite le conserver plus d'une heure, il doit le renouveler dans l'heure. Lorsqu'un ticket atteint sa durée de vie maximale (dix heures), celui-ci expire automatiquement et ne peut pas être renouvelé.

Pour plus d'informations sur la façon de visualiser les attributs de tickets, reportez-vous à la section Affichage des tickets Kerberos.

Durée de vie des tickets

Chaque fois qu'un principal obtient un ticket, y compris un ticket d'octroi de tickets (TGT), la durée de vie du ticket est définie comme la plus petite des valeurs de durée de vie suivantes :

• Valeur de durée de vie spécifiée par l'option -l de la commande kinit, si kinit est utilisée pour obtenir le ticket. Par défaut, kinit utilise la valeur de durée de vie maximale.

• Valeur de durée de vie maximale (max_life) spécifiée dans le fichier kdc.conf.

• Valeur de durée de vie maximale spécifiée dans la base de données Kerberos pour le principal de service fournissant le ticket. Dans le cas de kinit, le principal de service est krbtgt/realm.

• Valeur de durée de vie maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur demandant le ticket.

La Figure 25-1 montre comment la durée de vie d'un TGT est déterminée et d'où les quatre valeurs de durée de vie proviennent. Même si cette figure montre comment la durée de vie d'un TGT est déterminée, la même chose se produit globalement pour chaque obtention de ticket par un principal. La seule différence est que kinit n'offre pas une valeur de durée de vie et que le principal de service fournissant le ticket fournit une valeur de durée de vie maximale (au lieu du principal krbtgt/realm).

Figure 25-1 Détermination de la durée de vie d'un TGT

La durée de vie d'un ticket renouvelable est également déterminée à partir de la plus basse de quatre valeurs, mais des valeurs de durée de vie renouvelables sont utilisées à la place, comme suit :

• Valeur de durée de vie renouvelable spécifiée par l'option -r de kinit, si kinit est utilisée pour obtenir ou renouveler le ticket.

• Valeur de durée de vie renouvelable maximale (max_renewable_life) spécifiée dans le fichier kdc.conf.

• Valeur de durée de vie renouvelable maximale spécifiée dans la base de données Kerberos pour le principal de service fournissant le ticket. Dans le cas de kinit, le principal de service est krbtgt/realm.

• Valeur de durée de vie renouvelable maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur demandant le ticket.

Noms de principaux Kerberos

Chaque ticket est identifié par un nom de principal. Le nom de principal peut identifier un utilisateur ou un service. Voici des exemples de noms de principaux.

Tableau 25-4 Exemples de noms de principaux Kerberos