Zusammenfassung

  • RFC 2444 ersetzte anwendungsspezifische OTP-Parser durch einen benannten SASL-Mechanismus mit festgelegten Austauschformaten.
  • Der Mechanismus authentisierte anhand einer OTP-Antwort, lieferte aber weder Sicherheitsschicht noch Sitzungsschutz, Serverauthentisierung oder Schutz vor aktiven Angriffen.

Eine erfolgreiche Anmeldung beantwortet nicht automatisch die Frage, ob die anschließende Sitzung geschützt ist. Genau diese Trennung macht RFC 2444 greifbar. Das Dokument von 1998 beschreibt, wie das One-Time Password (OTP) als Mechanismus in die Simple Authentication and Security Layer (SASL) eingebunden werden kann. Zuvor ergänzten Anwendungen OTP laut RFC auf ad-hoc-Art und werteten Eingaben heuristisch aus. Ein benannter Mechanismus sollte die Integration über Anwendungsprotokolle hinweg vorhersagbarer machen, statt für jedes Protokoll einen eigenen Passwortparser zu verlangen.

Standardisierung bedeutete hier nicht, dass der gesamte Kanal gesichert wurde. RFC 2222 unterschied die Authentisierung von einer optional ausgehandelten Sicherheitsschicht für den weiteren Austausch. RFC 2444 sagt ausdrücklich, dass sein OTP-Mechanismus keine solche Schicht bereitstellt. Er gewährleistet weder Vertraulichkeit der Sitzung noch Authentisierung des Servers oder Schutz vor aktiven Angriffen. Ein positives Ergebnis der Authentisierung gilt deshalb nur für diesen Austausch; es ist kein Nachweis dafür, dass der Client den Server kennt oder spätere Befehle verschlüsselt sind.

Der Profiltext stützt sich auf das OTP-System aus RFC 2289 und die erweiterten Antworten aus RFC 2243. Server müssen hex, word, init-hex und init-word unterstützen. Die ersten beiden Formen übermitteln eine Antwort, die init--Varianten erlauben zusätzlich, die Sequenz neu zu initialisieren. MD5-Unterstützung ist vorgeschrieben, SHA-1 wird empfohlen. Der Client soll eine zu niedrige Sequenznummer anzeigen und dem Nutzer eine Rücksetzung anbieten. Nach jeder Verwendung wird der betreffende Eintrag in der Authentisierungsdatenbank aktualisiert. Einheitliche Nachrichtenformate lösen also nicht von Kompatibilitäts- und Zustandsfragen.

Als Anwendungsfall nennt RFC 2444 einen nicht vertrauenswürdigen Client, etwa ein öffentliches Terminal. Ein abgefangenes OTP soll diesem Gerät nur eine Gelegenheit geben, im Namen des Nutzers zu handeln. Das ist enger als der Schutz der danach laufenden Sitzung. Eine kompromittierte Authentisierungsdatenbank bleibt laut Dokument Wörterbuchangriffen ausgesetzt, auch wenn sie nicht einem Klartext-Passwortspeicher entsprechen muss. RFC 2444 warnt zudem vor passiven Wörterbuchangriffen und verlangt Schutz vor dem Race-Angriff, den die zugrunde liegende OTP-Spezifikation beschreibt. Einmalverwendung ist ein begrenzter Schutz, kein Rundumschutz.

Auch innerhalb von SASL bleiben Identitäten getrennt: Die Authentisierungsidentität bezeichnet die vorgelegten Zugangsdaten, die Autorisierungsidentität die gewünschten Rechte. Bei Stellvertretung müssen beide nicht übereinstimmen; eine leere Autorisierungsidentität kann der Server aus den Zugangsdaten ableiten. Eine korrekte OTP-Antwort entscheidet daher nicht allein, welche Aktion erlaubt ist. Mechanismusname, Challenge-Format, Kodierung durch das jeweilige Anwendungsprotokoll, Transportschutz, Serveridentität und Autorisierungsentscheidung sind getrennte Ebenen.

RFC 2444 aktualisierte die SASL-Spezifikation von 1997 und erklärte die vorgesehene Nutzung des S/Key-SASL-Mechanismus für obsolet. RFC 4422 ersetzte später das ursprüngliche SASL-Grunddokument; RFC 5034 beschreibt ein POP3-Profil, RFC 5802 einen anderen Mechanismus, SCRAM. Diese Dokumente markieren die Weiterentwicklung des Rahmens, belegen jedoch weder eine flächendeckende Nutzung von RFC 2444 noch die heutige Eignung seiner Kryptografieempfehlungen aus dem Jahr 1998. Ein RFC beschreibt normatives Verhalten, keine installierte Basis.

Der historische Beitrag bleibt damit präzise: Anwendungen erhielten einen standardisierten OTP-Einstieg statt uneinheitlicher lokaler Parser. Die verbleibenden Pflichten sind ebenso präzise verteilt. Protokolldesigner legen den Transport der SASL-Tokens fest; Implementierungen halten Sequenzänderungen konsistent; Betreiber schützen den Kanal nach der Authentisierung; Anwendungen ordnen Identitäten Berechtigungen zu. Einmal war die Antwort nutzbar. Die Sitzung musste weiterhin für sich geschützt werden.

Quellen