1.3. Choix d'un Principal avec Lequel Communiquer
1.3. Choix d'un Principal avec Lequel Communiquer
Le protocole Kerberos fournit les moyens de vérifier (sous réserve des hypothèses de la Section 1.6) que l'entité avec laquelle on communique est la même entité qui a été enregistrée auprès du KDC en utilisant l'identité revendiquée (nom de principal). Il est toujours nécessaire de déterminer si cette identité correspond à l'entité avec laquelle on a l'intention de communiquer.
Lorsque des données appropriées ont été échangées à l'avance, l'application peut effectuer cette détermination de manière syntaxique en se basant sur la spécification du protocole d'application, les informations fournies par l'utilisateur et les fichiers de configuration. Par exemple, le nom du principal du serveur (y compris le domaine) pour un serveur telnet pourrait être dérivé du nom d'hôte spécifié par l'utilisateur (depuis la ligne de commande telnet), du préfixe "host/" spécifié dans la spécification du protocole d'application, et d'une correspondance avec un domaine Kerberos dérivée syntaxiquement de la partie domaine du nom d'hôte spécifié et des informations de la base de données des domaines Kerberos locaux.
On peut également s'appuyer sur des tiers de confiance pour effectuer cette détermination, mais seulement lorsque les données obtenues auprès du tiers sont convenablement protégées en intégrité lorsqu'elles résident sur le serveur tiers et lorsqu'elles sont transmises. Ainsi, par exemple, on ne devrait pas se fier à un enregistrement DNS non protégé pour mapper un alias d'hôte au nom principal d'un serveur, en acceptant le nom principal comme la partie que l'on a l'intention de contacter, car un attaquant peut modifier la correspondance et usurper l'identité de la partie.
Les implémentations de Kerberos et les protocoles basés sur Kerberos NE DOIVENT PAS utiliser de requêtes DNS non sécurisées pour canoniser les composants de nom d'hôte des noms de principal de service (c'est-à-dire, ils NE DOIVENT PAS utiliser de requêtes DNS non sécurisées pour mapper un nom à un autre afin de déterminer la partie hôte du nom de principal avec lequel on doit communiquer). Dans un environnement sans service de noms sécurisé, les auteurs d'applications PEUVENT ajouter un nom de domaine configuré statiquement aux noms d'hôtes non qualifiés avant de passer le nom aux mécanismes de sécurité, mais ils ne devraient pas faire plus que cela. Les services de noms sécurisés, s'ils sont disponibles, pourraient être dignes de confiance pour la canonisation des noms d'hôtes, mais une telle canonisation par le client NE DEVRAIT PAS être requise par les implémentations KDC.
Note d'implémentation: De nombreuses implémentations actuelles effectuent un certain degré de canonisation du nom de service fourni, utilisant souvent DNS même si cela crée des problèmes de sécurité. Cependant, il n'y a pas de cohérence entre les implémentations quant à savoir si le nom de service est plié en minuscules ou si la résolution inverse est utilisée. Pour maximiser l'interopérabilité et la sécurité, les applications DEVRAIENT fournir aux mécanismes de sécurité des noms qui résultent du pliage du nom saisi par l'utilisateur en minuscules sans effectuer d'autres modifications ou canonisation.