Résumé

  • La RFC 1510, publiée en septembre 1993, reliait les domaines Kerberos par des clés inter-domaines et des tickets TGT (tickets pour le service d’octroi des tickets). Le champ transited formait un ensemble non ordonné de domaines intermédiaires ; le domaine du client et celui du service apparaissaient ailleurs dans le ticket.
  • Un passage direct entre deux domaines peut ainsi produire un champ transited vide. La RFC 4120, qui a remplacé la RFC 1510 en 2005, a rendu le contrôle explicite : le serveur applicatif vérifie lui-même le chemin ou rejette le ticket inter-domaine dépourvu de l’indicateur de contrôle par le KDC.

Analyse

Deux extrémités hors du champ

Prenons des noms de Realm schématiques : une personne inscrite dans ALPHA.EXAMPLE demande un ticket pour un service de fichiers dans BETA.EXAMPLE. Si les deux Realms partagent la clé inter-domaine requise et qu’aucun troisième Realm ne s’interpose, le champ transited peut rester vide. Les champs d’extrémité identifient toujours le client et le service ; la valeur vide indique un saut direct.

Lisez transited comme un relevé compact des Realm intermédiaires. Les extrémités figurent dans d’autres champs ; un saut direct ne produit aucune entrée au milieu.

La RFC 1510 décrit un domaine Kerberos comme une zone administrative dotée de son propre service. Le nom du domaine fait partie de l’identité du client, et le service destinataire peut s’en servir pour décider s’il honore la demande. Pour passer dans un autre domaine, les administrateurs établissent une clé inter-domaine ; une clé distincte peut servir dans chaque sens. Le service de tickets distant est enregistré comme principal dans l’autre domaine, ce qui permet au KDC distant de déchiffrer le ticket reçu de son partenaire.

Le client n’a donc pas besoin d’un compte séparé dans chaque domaine de destination. Il obtient d’abord un TGT pour le service d’octroi des tickets (TGS) du domaine distant, puis le présente afin d’obtenir un ticket destiné à l’application. La clé partagée constitue le pont cryptographique. L’installation et la maintenance de ce pont relèvent d’un choix administratif.

Les Realm intermédiaires, dans un ensemble sans ordre

La route peut traverser plusieurs domaines. La RFC 1510 décrit comme typiques les hiérarchies où chaque domaine partage une clé avec son parent et des clés distinctes avec ses enfants. Elles permettent de construire un chemin lorsque les extrémités ne partagent pas de clé directe. Le texte autorise aussi des chemins alternatifs qui contournent certains domaines, par exemple pour accélérer les échanges. Hors hiérarchie, une autre base de données peut être nécessaire pour établir la route.

RFC 1510 range les Realm intermédiaires dans un ensemble non ordonné et compresse les noms hiérarchiques usuels pour raccourcir le champ. L’ordre disparaît de ce relevé. Pour reconstruire la chronologie, le service a besoin d’un autre journal.

Le service de tickets ajoute le Realm qui a émis le ticket reçu ; son propre Realm reste hors du champ. RFC 1510 donne la raison de sécurité : un serveur ne peut masquer sa participation en omettant simplement son nom. La règle a une limite explicite, car un serveur malveillant pourrait omettre d’autres Realm. La politique du service doit donc évaluer les autres déclarations du chemin.

En juillet 2005, la RFC 4120 a remplacé la RFC 1510 et décrit plus nettement le contrôle attendu. Le serveur applicatif reste responsable de l’acceptation ou du rejet et doit s’assurer que les KDC concernés sont dignes de confiance pour authentifier ce client. Le KDC du domaine de destination peut appliquer sa politique, puis inscrire TRANSITED-POLICY-CHECKED dans le ticket de service. Sans cet indicateur, l’application doit vérifier elle-même les domaines traversés ou rejeter le ticket. La RFC avertit aussi qu’un KDC non fiable peut fabriquer la liste, même si elle ne contient que des noms réputés fiables.

Le pouvoir passe de main en main : les administrateurs installent les clés inter-domaines ; les KDC émettent les tickets et déclarent leurs contrôles ; les applications tranchent sur les chemins acceptés. Ajouter une clé peut raccourcir une route et faciliter les échanges. Le même geste élargit aussi le cercle d’identités que les services pourront accepter. La personne qui ajoute cette clé autorise de futurs accès et choisit le trajet qu’ils suivront.

La note de septembre 1993 indique que le protocole était encore examiné et ne faisait pas alors l’objet d’une proposition de normalisation Internet. RFC 4120 est entrée dans la filière Standards Track en 2005 et a détaillé les obligations d’implémentation. La preuve manquante est un relevé de déploiement des années 1990 indiquant quels serveurs vérifiaient transited ; ce relevé établirait si ce contrôle existait dans les systèmes en service, tandis que les RFC décrivent le protocole prévu.

Sources