RFC 3112 : correspondance du mot de passe, pas authentification

Résumé

RFC 3112 structurait une valeur dérivée en trois parties sensibles à la casse : le schéma, ses informations et la valeur d’authentification. Une règle pouvait répondre TRUE, FALSE ou Undefined, mais elle ne faisait qu’évaluer une comparaison.
Le texte exigeait encore l’opération Bind pour authentifier l’association LDAP. Puisqu’un attribut pouvait contenir plusieurs valeurs, un acteur autorisé à écrire pouvait aussi ajouter un second mot de passe valide sans casser celui que l’utilisateur connaissait.

Une comparaison exacte, une association encore anonyme

Un client envoie un mot de passe dans un filtre LDAP. Le serveur retrouve une valeur, lit son schéma et son sel, calcule le résultat attendu, puis répond vrai. Le secret correspond. Pourtant le client n’a pas encore été authentifié auprès de l’annuaire.

Cette frontière donne à RFC 3112 son intérêt historique. Publié en mai 2001 comme document Informational, « LDAP Authentication Password Schema » cherchait à conserver dans LDAP des informations dérivées du mot de passe plutôt que le mot de passe lui-même tel que l’usage de userPassword était alors présenté. Il définissait une syntaxe, deux règles de correspondance, un attribut de capacité dans le DSE racine et une classe d’objet auxiliaire. Après avoir rendu la vérification possible, il interdisait d’en gonfler le sens : un authPasswordMatch réussi par Compare ou Search ne suffisait pas pour accéder à l’annuaire. Il fallait exécuter Bind.

La comparaison et Bind appartenaient à deux machines d’état. La première demandait si une chaîne soumise concordait avec au moins une valeur selon son schéma. La seconde demandait si le serveur acceptait une identité d’authentification pour cette association protocolaire. Ensuite seulement, les règles d’autorisation décidaient des opérations permises. Une application extérieure gardait encore la décision sur son propre acte métier.

Un journal qui réduit tout cela à « connexion réussie » détruit les preuves. Une comparaison peut réussir sans Bind ; Bind peut réussir alors qu’une lecture reste interdite ; une lecture autorisée ne prouve pas que l’action finale de l’application a abouti.

Le mode de calcul voyageait avec la valeur

La syntaxe authPassword alignait trois composants séparés par le signe dollar : scheme, authInfo et authValue. Le nom du schéma décrivait le mécanisme. authInfo contenait souvent un sel encodé en base64 ; authValue, le résultat dérivé, lui aussi fréquemment encodé en base64. Les composants étaient sensibles à la casse.

Cette structure autorisait plusieurs mécanismes dans un même annuaire. RFC 3112 définissait les noms MD5 et SHA1. Un mécanisme privé devait employer le préfixe X- ou un identifiant d’objet. Dans le DSE racine, supportedAuthPasswordSchemes pouvait annoncer les noms compris par le serveur.

L’annonce ne disait pas ce qui s’était réellement passé. Elle ne prouvait ni le schéma choisi pour une entrée, ni la qualité du sel, ni l’auteur de la valeur, ni la protection du canal, ni le résultat de Bind. Une capacité déclarée n’est pas une trace d’exécution.

La distance historique doit rester explicite. Les constructions MD5 et SHA-1 du document concaténaient mot de passe et sel, puis appliquaient le condensat. Le sel devait comporter au moins 64 bits, et les implémentations devaient accepter jusqu’à 128 bits. C’est une description de 2001, pas une recommandation actuelle. RFC 8018 rend ensuite visibles sel et nombre d’itérations dans les techniques à mot de passe ; RFC 9106 décrit Argon2, fonction à mémoire coûteuse, et préfère Argon2id pour le hachage de mots de passe et la dérivation de clé.

Ces textes ultérieurs n’effacent pas RFC 3112 : ils montrent pourquoi le nom précis du mécanisme et ses paramètres ne peuvent être résumés par « haché de façon sûre ».

Trois résultats qui ne répondaient pas à la même question

authPasswordExactMatch comparait des représentations déjà structurées. Il répondait vrai lorsqu’une valeur stockée possédait les mêmes schéma, information et valeur ; faux lorsqu’aucune n’était identique ; indéterminé dans les autres cas.

authPasswordMatch prenait au contraire un mot de passe soumis par un filtre extensible. Le serveur appliquait à chaque valeur son propre mécanisme. Un seul succès rendait le résultat vrai ; l’échec de toutes les valeurs le rendait faux ; l’impossibilité de terminer l’évaluation le rendait Undefined.

Ces trois états avaient une portée utile. Faux ne signifiait pas que la personne n’existait pas, que l’entrée était la bonne ou qu’aucun magasin externe ne pouvait l’authentifier. Indéterminé ne devait pas être transformé en « mauvais mot de passe » : le serveur n’avait justement pas pu conclure. Vrai ne prouvait ni qui tenait le clavier, ni qui contrôlait le canal, ni si le demandeur avait le droit de tester cet attribut.

Bind créait l’état d’authentification de l’association. RFC 4511 a ensuite reformulé cette opération dans la révision de LDAP, et RFC 4513 a clarifié la séparation suivante : l’identité d’autorisation utilisée pour les décisions d’accès peut être déduite de l’identité authentifiée ou, pour certains mécanismes, demandée séparément si le serveur autorise cette délégation.

Même Bind ne constituait donc pas une permission universelle. Il établissait l’identité acceptée sur une association. Une politique d’accès décidait si cette identité pouvait comparer, lire ou modifier un objet. L’application utilisatrice de LDAP demeurait responsable de son résultat métier.

Plusieurs valeurs, plusieurs portes possibles

L’attribut n’était pas limité à une seule valeur. Pour les schémas sélectionnés, le serveur devait considérer les valeurs pertinentes et pouvait valider le mot de passe dès qu’une d’elles correspondait. Cette souplesse aidait une migration ou une période de chevauchement. Elle transformait également chaque droit d’écriture en droit potentiel d’ajouter un secret.

RFC 3112 décrit directement le danger : un attaquant qui obtient l’écriture peut stocker une valeur supplémentaire sans désactiver le véritable mot de passe de l’utilisateur. Celui-ci continue à se connecter ; aucun incident visible de réinitialisation ne l’alerte ; la deuxième porte reste ouverte.

L’état final de l’entrée ne suffit pas à raconter cette histoire. Deux valeurs présentes ne révèlent pas qui les a créées, quelle règle les a autorisées, quelle opération les a propagées ou quel secret devait disparaître. Il faut conserver chaque ajout, remplacement et suppression, avec identité d’écriture, décision d’autorisation, empreinte, schéma, paramètres, réplication et date de retrait.

RFC 3062 avait défini une opération étendue de modification du mot de passe. Elle permettait au serveur de sélectionner la cible, d’accepter ou de générer un nouveau secret et de choisir son stockage sous contrôle, sans réduire le cycle de vie du mot de passe à une écriture ordinaire de l’attribut. RFC 3112 pouvait participer à ce dispositif, mais ne le remplaçait pas.

Le serveur pouvait aussi combiner authPassword, userPassword et un magasin externe. Voir un attribut ne révélait donc pas l’ensemble des chemins d’authentification. Supprimer une valeur ne révoquait pas nécessairement les autres.

Une dérivation restait un secret exposable

Le document refusait l’idée rassurante qu’un condensat à sens unique pouvait être publié. Il recommandait de protéger les valeurs dérivées comme des mots de passe en clair : une faiblesse d’algorithme, une erreur d’implémentation ou une attaque hors ligne pouvait convertir la fuite en accès. Leur transfert sans confidentialité était fortement déconseillé.

L’assertion de authPasswordMatch devait recevoir la même protection. Elle transportait précisément le mot de passe candidat. Un canal non protégé pouvait le divulguer ; une règle de comparaison accessible sans frein pouvait devenir un oracle de devinettes en ligne.

Le coût de calcul ajoutait un risque de disponibilité. Un mécanisme cher ralentit l’attaquant, mais lui donne aussi un moyen de consommer le processeur du serveur. Les limites de débit, budgets de concurrence, délais et droits d’appeler la comparaison font donc partie du sens opérationnel du mécanisme.

Une proposition datée, une séparation durable

RFC 3112 opposait son schéma au userPassword décrit par RFC 2256 dans le contexte LDAP de 1997. Cette opposition ne doit pas devenir une règle éternelle. RFC 4519 a ensuite précisé que les valeurs de userPassword ne devaient pas nécessairement être en clair ni même servir à Bind. Les implémentations ont également utilisé des représentations qui leur étaient propres.

Le statut Informational interdit une autre exagération. Les fiches RFC Editor et IETF Datatracker prouvent la publication et l’historique du texte, pas son déploiement général. RFC 2251, RFC 2252 et RFC 2256 donnent le contexte de protocole et de schéma ; RFC 2829 et RFC 4513 replacent le mot de passe dans le modèle de sécurité ; RFC 4511, RFC 4517 et RFC 4519 montrent la lignée révisée. Aucun de ces documents ne prouve qu’un annuaire déterminé a activé authPassword.

La leçon solide réside ailleurs. Une représentation structurée n’est pas une politique exécutée. Une comparaison réussie n’est pas une association authentifiée. Une association authentifiée n’est pas une autorisation globale. Et une autorisation LDAP ne garantit pas le résultat observé dans l’application.

Pour enquêter, il faut donc conserver l’entrée exacte et l’historique de ses mutations, le schéma et ses paramètres, le canal, le droit d’exécuter Compare ou Search, la requête et son état vrai, faux ou indéterminé, les valeurs réellement testées, puis la requête Bind, sa réponse, les identités d’authentification et d’autorisation obtenues, l’opération suivante et son résultat applicatif.

Le mot de passe pouvait correspondre parfaitement. RFC 3112 savait que cette vérité devait s’arrêter à la porte de Bind.

Le mot de passe correspondait. L’utilisateur n’était pas encore authentifié : RFC 3112

Pourquoi c'est important

Résumé

Une comparaison exacte, une association encore anonyme

Le mode de calcul voyageait avec la valeur

Trois résultats qui ne répondaient pas à la même question

Plusieurs valeurs, plusieurs portes possibles

Une dérivation restait un secret exposable

Une proposition datée, une séparation durable

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance