Résumé

  • service [AT] domaine [AT] hôte — où [AT] représente le signe arobase ASCII littéral de la syntaxe RFC — ne dit pas seulement quel serveur a répondu. Le nom demande si cet hôte possède l’autorité nécessaire pour fournir ce service au domaine visé.
  • Quand le mécanisme ou le serveur ne reconnaît pas ce type de nom, RFC 5178 permet un repli vers l’identité de l’hôte à condition de vérifier séparément son autorisation. Une reconnexion réussie ne remplace pas ce contrôle.

Le voyant est repassé au vert après désactivation de l’option. Le client a retrouvé le serveur, négocié son mécanisme et ouvert sa session. Dans un rapport d’exploitation, l’incident pourrait se terminer ici : « incompatibilité résolue ».

Pourtant, l’option désactivée n’était pas un embellissement. Elle portait la partie du nom qui disait au nom de quel domaine le serveur était autorisé à agir.

RFC 5178 part d’un cas subtil. Une réponse DNS SRV non protégée peut être falsifiée. L’attaquant n’a pas forcément besoin d’usurper l’identité du serveur qu’il désigne. Il peut orienter le client vers une machine qui possède un véritable identifiant et un véritable secret. L’authentification fondée sur l’hôte confirme alors honnêtement que la machine est celle annoncée par la réponse mensongère.

La preuve est correcte et la question est mauvaise.

Trois composantes pour conserver l’intention

Le type GSS_C_NT_DOMAINBASED_SERVICE introduit une forme simple : un service, le domaine desservi et le nom de l’hôte concret. La syntaxe d’affichage est service [AT] domaine [AT] hôte. IANA lui attribue la valeur 5 dans le registre des types de noms GSS-API.

Chaque composante garde une responsabilité. Le service désigne la fonction. Le domaine décrit la portée administrative ou la ressource commune. L’hôte identifie l’accepteur sélectionné, éventuellement parmi plusieurs membres d’une grappe. Une réponse de découverte propose ce membre ; elle ne lui confère pas à elle seule le mandat du domaine.

Le serveur doit donc présenter une accréditation qui correspond à la triple portée. Dans la logique de RFC 5178, la disponibilité de cette accréditation matérialise l’autorisation. Le gestionnaire qui la crée ne publie pas une simple étiquette : il délègue à cette machine le droit de s’authentifier comme fournisseur de ce service pour ce domaine.

Cette localisation de la décision est utile. Elle permet de garder la découverte remplaçable et distribuée sans lui attribuer l’autorité finale. Elle rend aussi l’erreur plus précise. Si le mauvais hôte possède le bon triplet, il faut examiner l’émission, la copie, la durée de vie ou la révocation de l’accréditation — pas seulement le DNS.

Le coût réel du mode compatible

La spécification n’ignore pas le parc existant. Certains mécanismes GSS ne négocient pas le nouveau type. Certains serveurs ne l’acceptent pas. Un client LDAP ancien peut avoir été conçu pour service [AT] hôte, et le serveur peut ne posséder aucune accréditation portant le domaine. Activer unilatéralement la nouvelle forme peut donc casser l’interopérabilité.

RFC 5178 répond par une obligation, pas par un oubli : si l’initiateur revient au nom fondé sur l’hôte, il doit vérifier que cette identité d’hôte est autorisée à fournir le service pour le domaine voulu. La même règle vaut pour un initiateur qui ne connaît pas du tout les noms fondés sur le domaine.

Une configuration de repli valable a donc besoin d’un registre explicite : quels hôtes peuvent représenter quel service pour quel domaine, qui l’a décidé, pour quelle durée et selon quelle procédure de retrait. Sans cette preuve, le repli ne préserve pas l’ancienne sécurité. Il remplace l’ancienne question par « le serveur sait-il prouver son propre nom ? ».

L’exploitation doit distinguer trois états : la forme domaine-hôte fonctionne ; elle est indisponible mais une autorisation d’hôte équivalente existe ; elle est indisponible et le client accepte tout de même la cible découverte. Seul le deuxième est un repli maîtrisé.

Une chaîne réussie reste composée de plusieurs reçus

Un contexte GSS établi avec le triplet attendu est une preuve forte et délimitée. Il relie un mécanisme, une accréditation et un nom de service dont la portée inclut le domaine. Il ne prouve pas que la réponse DNS était authentique, que l’accréditation aurait dû être encore active, que l’application autorise l’opération demandée ou que les données rendues sont correctes.

La chaîne observable doit conserver l’intention initiale avant qu’elle ne soit transformée : domaine demandé par l’utilisateur ou la configuration, requête de découverte, état DNSSEC, ensemble de candidats, hôte choisi, type de nom, forme importée, nom canonique du mécanisme, realm contacté, accréditation présentée, résultat GSS, décision de l’application et effet constaté.

Dire « Kerberos OK » écrase cette chaîne. Une accréditation volée ou émise trop largement peut produire le même résultat. Une application peut aussi refuser une opération après une authentification correcte. À l’inverse, un échec du nouveau type peut être une absence de support et non une attaque.

L’affichage Unicode n’est pas l’identité canonique

RFC 5178 ajoute une autre difficulté : la même intention doit traverser des interfaces ASCII, ACE et UTF-8. L’import classique doit accepter les domaines internationalisés encodés en ACE. Une variante UTF-8 recommandée accepte UTF-8 ou ACE. L’affichage classique émet ASCII ou ACE ; la variante UTF-8 doit produire de l’UTF-8 et ne pas produire d’ACE.

Ces règles ne rendent pas les chaînes imprimées interchangeables. GSS-API distingue le nom interne, sa représentation affichée, le nom propre au mécanisme et la forme exportée. RFC 2743 précise même qu’un nom importé puis affiché n’est pas garanti de ressortir sous la même chaîne ni sous le même identifiant de type.

La comparaison d’autorisation doit suivre GSS_Compare_name, la canonisation du mécanisme ou la forme exportée prévue, non un memcmp entre deux journaux lisibles. L’enjeu s’est accru quand le cadre IDNA de RFC 3490 a été remplacé par IDNA2008 et ses distinctions A-label/U-label. Cette évolution ne modifie pas rétroactivement RFC 5178 ; elle oblige à tracer le profil et la conversion effectivement employés.

Conserver seulement l’affichage Unicode facilite la lecture mais peut empêcher la reproduction du principal authentifié. Conserver seulement l’ACE permet la reproduction mais cache ce que l’administrateur croyait approuver. Les deux vues, le type de nom et la forme canonique doivent rester liées.

Kerberos ne confond pas le domaine et le realm

RFC 5179 mappe le triplet vers Kerberos V : service en première composante, hôte en deuxième, domaine en troisième. Il recommande le type NT-SRV-HST-DOMAIN, valeur 12. Le realm reste une décision distincte, obtenue par les méthodes Kerberos applicables.

La considération de sécurité est particulièrement révélatrice : le realm doit être dérivé de l’hôte, non du champ domaine fourni dans la chaîne d’entrée. Le domaine décrit le mandat du service ; il ne doit pas pouvoir se nommer lui-même autorité d’authentification.

La preuve utile en production n’est donc pas que la chaîne contenait deux signes arobase. Il faut savoir quel principal a été produit, quel realm a été consulté, quelle accréditation a répondu et quelle règle applicative a reconnu cette identité.

NFS montre la séparation en action

RFC 6641 emploie ensuite ce schéma pour trouver, via DNS SRV, les serveurs racines d’un espace de fichiers NFSv4 associé à une organisation. DNSSEC reste recommandé lorsqu’il est disponible. Le nom fondé sur le domaine ajoute un contrôle : seuls les serveurs approuvés devraient posséder l’accréditation nfs [AT] domaine [AT] hôte correspondante.

La découverte choisit une destination possible. L’accréditation prouve une délégation. NFS négocie sa sécurité et applique ses règles. Le montage et les fichiers observés constituent encore d’autres résultats. Aucun reçu ne devrait prétendre être les quatre.

Ce découpage impose aussi de synchroniser sans confondre deux inventaires. Retirer un hôte du SRV sans révoquer son accréditation le rend moins facile à trouver, pas nécessairement incapable de s’authentifier. Révoquer l’accréditation en le laissant dans SRV produit une cible publiée mais inutilisable. Le rapprochement des deux ensembles révèle l’écart ; les fusionner dans un simple état « actif » le dissimule.

La compatibilité n’est donc pas le contraire de la sécurité. Elle devient dangereuse lorsqu’elle efface silencieusement le mandat que le nom devait conserver.

Sources