Résumé

  • La RFC 3045 a défini les attributs facultatifs vendorName et vendorVersion dans le root DSE d’un serveur LDAP, afin d’indiquer son éditeur ou d’aider à repérer une anomalie logicielle.
  • Elle a interdit d’utiliser ces chaînes pour découvrir les fonctions prises en charge. Le nom et la version déclarés n’attestaient ni la provenance du logiciel ni le fonctionnement d’une capacité sur ce serveur ou dans cette session.

Un client LDAP consultait déjà le root DSA-specific Entry, ou root DSE, pour obtenir des renseignements propres au serveur auquel il venait de se connecter. La RFC 3045 y a ajouté deux indices possibles : vendorName et vendorVersion. Publiée en janvier 2001 comme RFC informative, elle permettait au serveur de révéler le nom de l’éditeur de son logiciel et la chaîne de version qu’il déclarait. Ces attributs opérationnels à valeur unique n’étaient pas des champs ordinaires qu’un usager de l’annuaire pouvait modifier.

La proposition était volontairement circonscrite. Le client pouvait afficher l’éditeur et la version à l’opérateur ou reconnaître une version associée à une anomalie connue, puis envisager un correctif de contournement. En revanche, la RFC 3045 lui interdisait d’utiliser ces valeurs pour déduire les fonctions prises en charge. Le nom d’un éditeur ne dit pas quels contrôles, extensions ou mécanismes un serveur donné accepte. Une chaîne de version ne dit pas si une fonction est activée dans cette configuration, accessible à cette session authentifiée ou opérationnelle.

Les capacités devaient être annoncées par des mécanismes propres à la fonction concernée.

Cette frontière évitait un raccourci séduisant mais fragile. Un client qui prenait « éditeur X, version Y » pour une négociation de fonctions pouvait ignorer le signal protocolaire prévu à cet effet. Il risquait alors d’activer une opération non prise en charge ou d’écarter une opération disponible. La RFC laissait l’identité du produit donner du contexte à une observation, pas remplacer cette observation.

La syntaxe de version elle-même était conçue contre une fausse précision. La valeur devait être unique d’une version à l’autre, mais la RFC n’imposait ni format ni ordre. La correspondance prévue reposait sur l’égalité, non sur « inférieur à » ou « supérieur à ». Pour déclencher un contournement, le client pouvait comparer exactement la chaîne liée à l’anomalie au lieu de supposer que 8.01 précédait ou suivait 8.5. Une étiquette de version est un nom, pas nécessairement un nombre comparable.

Même une correspondance exacte ne décrivait pas toute l’implémentation. La RFC relevait qu’une anomalie pouvait toucher seulement une partie des serveurs déclarant la même version : les plates-formes, les réglages et les modules d’extension diffèrent. Elle avertissait aussi que la présence d’un nom ou d’une version ne garantissait pas que le serveur avait réellement été produit par cet éditeur ou utilisait cette version. On sait ce que le serveur a déclaré, pas ce que contient son binaire ni tout ce qu’il fera.

Ces attributs restaient facultatifs. Un serveur pouvait en limiter l’accès et le client ne devait pas s’attendre à les trouver. Leur absence ne signifiait ni panne ni incompatibilité. Cette précaution compte, car une information utile au dépannage révèle aussi des détails logiciels à un adversaire. La RFC 3045 signalait expressément qu’un nom ou une version pouvait aider à repérer une faiblesse.

Les modèles LDAP ultérieurs ont maintenu la séparation entre identité et capacité. La RFC 4512 décrit le root DSE comme une entrée opérationnelle propre à chaque serveur et distingue des attributs tels que supportedControl, supportedExtension et supportedFeatures, dont les valeurs peuvent dépendre de la session. Le registre IANA LDAP actuel conserve les OID attribués à vendorName et vendorVersion ; il confirme ces identifiants, pas les déclarations d’un serveur ni ses capacités. La leçon de la RFC 3045 est une division du travail : les étiquettes aident à reconnaître le contexte, mais seules des preuves propres à la fonction indiquent ce qu’une connexion peut réellement utiliser.

Sources