Zusammenfassung

  • RFC 3112 zerlegte den abgeleiteten Passwortwert in Scheme, Scheme-Information und Authentifizierungswert. Die Matching Rule konnte TRUE, FALSE oder Undefined liefern; sie beurteilte jedoch einen Vergleich, nicht die Authentifizierung der LDAP-Assoziation.
  • Das Dokument verlangte Bind zur Authentifizierung. Weil das Attribut mehrere Werte zuließ, konnte ein Angreifer mit Schreibrecht ein zweites gültiges Passwort hinzufügen, ohne das bekannte Passwort des Benutzers zu deaktivieren.

Ein wahres Ergebnis im falschen Zustandsautomaten

Ein Client sendet ein Passwort an eine LDAP Matching Rule. Der Server findet einen gespeicherten Wert, liest Scheme und Salt, berechnet das Ergebnis und antwortet wahr. Das Geheimnis stimmt. Trotzdem ist der Client am Verzeichnis noch nicht authentifiziert.

Diese Grenze macht RFC 3112 historisch interessant. Das im Mai 2001 als Informational veröffentlichte „LDAP Authentication Password Schema“ wollte aus Passwörtern abgeleitete Informationen speichern, statt des eigentlichen Passworts, von dem die damalige Verwendung von userPassword ausging. Es definierte Syntax, zwei Matching Rules, ein Capability-Attribut in der Root DSE und eine Hilfsobjektklasse. Unmittelbar danach beschränkte es die Bedeutung: Ein erfolgreiches authPasswordMatch über Compare oder Search reichte nicht für Verzeichniszugriff. Zur Authentifizierung musste Bind verwendet werden.

Vergleich und Bind beantworteten verschiedene Fragen. Matching prüfte, ob eine Eingabe nach dem erklärten Verfahren zu mindestens einem gespeicherten Wert passte. Bind entschied, ob der Server eine Authentication Identity für diese LDAP-Assoziation akzeptierte. Erst dann entschied die Zugriffspolitik, was die daraus entstehende Authorization Identity tun durfte. Die Anwendung außerhalb des Verzeichnisses behielt ihre eigene Geschäftsentscheidung.

Wer diese Übergänge als „Login erfolgreich“ zusammenfasst, zerstört die Beweiskette. Ein Match kann ohne Bind auftreten. Bind kann erfolgreich sein, während eine Änderung verboten bleibt. Ein erlaubtes LDAP-Lesen beweist keinen abgeschlossenen Vorgang in der Anwendung.

Der Wert nannte sein Verfahren

authPasswordSyntax bestand aus drei durch Dollarzeichen getrennten, groß-/kleinschreibungssensitiven Komponenten: scheme, authInfo und authValue. Das Scheme benannte den Mechanismus. authInfo trug häufig einen Base64-kodierten Salt; authValue häufig das abgeleitete Material.

Damit konnten verschiedene Mechanismen nebeneinander existieren. RFC 3112 definierte MD5 und SHA1. Private Namen sollten X- oder eine OID verwenden. supportedAuthPasswordSchemes, nur in der Root DSE erlaubt, veröffentlichte die Scheme-Namen, die der Server zu unterstützen behauptete.

Die Anzeige bewies keine Ausführung. Sie sagte nicht, welches Scheme für eine konkrete Authentifizierung gewählt wurde, wer den Wert schrieb, ob der Salt einzigartig war, ob der Kanal geschützt war, welche Werte getestet wurden oder ob Bind gelang. Capability war kein Execution Trace.

Auch das Datum gehört zur Aussage. Die MD5- und SHA-1-Schemes des RFC bildeten einen Digest über Passwort plus Salt. Der Salt musste mindestens 64 Bit umfassen; Implementierungen mussten bis 128 Bit unterstützen. Das ist eine historische Definition, keine heutige Passwortspeicher-Empfehlung. RFC 8018 machte Salt und Iterationszahl bei passwortbasierter Kryptografie explizit. RFC 9106 spezifizierte die speicherharte Funktion Argon2 und bevorzugte Argon2id für Passwort-Hashing und Schlüsselableitung.

Diese späteren Texte ändern den Befund von 2001 nicht, zeigen aber, warum „sicher gehasht“ ohne exaktes Scheme und Kostenparameter keine Evidenz ist.

Kodierte Gleichheit, Passworttest und Bind

authPasswordExactMatch verglich die bereits strukturierten Komponenten. Gleiche Werte für Scheme, authInfo und authValue ergaben true; kein gleicher Wert ergab false; sonst war das Ergebnis undefined. Es handelte sich um Gleichheit zweier Darstellungen.

authPasswordMatch nahm ein Passwort in einem Extensible-Match-Filter entgegen und prüfte jeden gespeicherten Wert nach dessen Scheme. Ein Treffer reichte für true; nur das Scheitern aller Werte ergab false; eine nicht abschließbare Prüfung ergab Undefined.

Keine Antwort identifizierte den Menschen an der Tastatur. True bewies weder, wer den Kanal kontrollierte, noch das Recht zur Prüfung. False bewies nicht, dass der richtige Eintrag gewählt wurde oder kein externer Credential Store existierte. Undefined war kein falsches Passwort, sondern die bewahrte Tatsache, dass der Server nicht entscheiden konnte.

Die Bind-Pflicht verhinderte, dass der Vergleich mehr Autorität erhielt. RFC 4511 beschrieb später Bind im revidierten LDAP-Protokoll. RFC 4513 trennte Authentication Identity und Authorization Identity. Letztere konnte abgeleitet oder mit einem geeigneten Mechanismus gesondert behauptet werden; der Server musste die Stellvertretung erlauben.

Selbst Bind war daher keine Generalvollmacht. Authentifizierung bestimmte, wen der Server in der Assoziation akzeptierte. Autorisierung bestimmte die erlaubte Operation am Objekt. Die Anwendung entschied über ihr Endergebnis.

Mehrere Werte schufen mehrere mögliche Türen

authPassword konnte mehrere Werte tragen. Für ausgewählte Schemes sollte der Server alle einschlägigen Werte prüfen; einer konnte das Passwort gültig machen. Das unterstützte Migrationen und kontrollierte Überlappung. Es verwandelte Schreibrecht jedoch auch in die Möglichkeit, einen neuen Zugang zu schaffen.

RFC 3112 benennt den Angriff: Wer Schreibzugriff gewinnt, kann einen zusätzlichen Wert speichern, ohne das echte Passwort des Benutzers auszuschalten. Das Opfer meldet sich weiter normal an; Reset oder Lockout fehlen als Warnsignal; die zweite Tür bleibt offen.

Ein Endzustand des Eintrags erklärt die Entstehung nicht. Zwei Werte zeigen nicht, wer sie hinzufügte, welche Policy das erlaubte oder welcher Wert entfernt werden sollte. Nötig sind Add, Replace und Delete, Writer und Authorization Identity, Fingerprint, Scheme, Parameter, Replikation und Ausmusterung.

RFC 3062 hatte bereits eine Password-Modify-Operation definiert. Unter Serverregeln konnte sie das Ziel bestimmen, ein neues Passwort annehmen oder erzeugen und dessen Speicherung wählen. RFC 3112 ließ sich damit verbinden, doch das Attribut allein war kein vollständiges Account-Lifecycle-System.

Der Server durfte authPassword zudem mit userPassword oder einem externen Store kombinieren. Ein beobachteter oder gelöschter Wert beschrieb daher nicht zwingend alle Authentifizierungswege.

Ein abgeleiteter Wert blieb ein Geheimnis

Das RFC betrachtete eine Einwegfunktion nicht als Freigabe zur Veröffentlichung. Es empfahl, abgeleitete Werte wie Klartextpasswörter zu schützen: Algorithmusfehler, Implementierungsfehler oder Offline-Angriffe konnten ein Leck in Zugang verwandeln. Übertragung ohne Vertraulichkeit wurde stark abgeraten.

Auch die Assertion für authPasswordMatch musste geschützt werden. Sie transportierte den Passwortversuch zum Server. Ein offener Kanal konnte ihn verraten; eine zu freie Vergleichsschnittstelle konnte als Online-Rateorakel dienen.

Rechenkosten erzeugten ein Availability-Problem. Ein teures Scheme erschwert Raten, ermöglicht aber auch den Verbrauch von Server-CPU. Rate Limits, Parallelitätsbudget, Timeout und Vergleichsberechtigung gehören zur tatsächlichen Policy. Der Scheme-Name beweist diese Kontrollen nicht.

Der Kontext änderte sich, die Trennung blieb

RFC 3112 stellte seinen Ansatz dem userPassword-Kontext aus RFC 2251, RFC 2252 und RFC 2256 gegenüber. Das war keine ewige Aussage. RFC 4519 stellte später klar, dass userPassword-Werte weder Klartext sein noch für Bind nutzbar sein müssen. Implementierungen entwickelten eigene Formate.

Der Informational-Status beweist auch keine Verbreitung. RFC-Editor- und Datatracker-Einträge belegen Publikation und Dokumentgeschichte. RFC 2829 und RFC 4513 liefern das Sicherheitsmodell; RFC 4511, RFC 4517 und RFC 4519 zeigen die spätere Protokoll-, Matching- und Schema-Linie. Keine Quelle beweist eine konkrete Aktivierung von authPassword.

Beständig blieb die Evidenztrennung. Für die Aussage, ein Benutzer habe sich angemeldet, braucht man Eintrag und Mutationshistorie, Scheme, Salt und Parameter, Compare-/Search-Berechtigung, Kanalzustand, Anfrage und true/false/undefined, getestete Werte, Bind-Anfrage und Antwort, Authentication und Authorization Identity, Folgeoperation, Zugriffsergebnis und Anwendungsausgang.

Das Passwort konnte exakt stimmen. RFC 3112 wusste, dass dieser wahre Satz nicht für Bind sprechen durfte.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3112.html
  2. https://www.rfc-editor.org/info/rfc3112
  3. https://datatracker.ietf.org/doc/rfc3112/
  4. https://www.rfc-editor.org/rfc/rfc2251.html
  5. https://www.rfc-editor.org/rfc/rfc2252.html
  6. https://www.rfc-editor.org/rfc/rfc2256.html
  7. https://www.rfc-editor.org/rfc/rfc2829.html
  8. https://www.rfc-editor.org/rfc/rfc3062.html
  9. https://www.rfc-editor.org/rfc/rfc4511.html
  10. https://www.rfc-editor.org/rfc/rfc4513.html
  11. https://www.rfc-editor.org/rfc/rfc4517.html
  12. https://www.rfc-editor.org/rfc/rfc4519.html
  13. https://www.rfc-editor.org/rfc/rfc8018.html
  14. https://www.rfc-editor.org/rfc/rfc9106.html