Zusammenfassung

  • RFC 4422 unterscheidet die mit den Nachweisen verbundene Authentisierungsidentität von der Identität, als die ein Client handeln möchte; der Server prüft Nachweis und Stellvertretung getrennt.
  • Ein erfolgreicher SASL-Austausch kann Sitzungszustand und eine Sicherheitsschicht herstellen, entscheidet aber nicht automatisch über spätere Aktionen und Ressourcen.

Der Erfolg braucht ein Bezugsobjekt

Ein grünes Symbol ist für Benutzer hilfreich. Für Systeme wird es gefährlich, sobald sein Bezugsobjekt verschwindet. Gültige Nachweise, die Erlaubnis zur Stellvertretung, die Aufnahme in einen Dienst und der Zugriff auf eine Datei sind vier mögliche Entscheidungen. Wer sie als „Login erfolgreich“ zusammenfasst, kann eine spätere Ablehnung weder erklären noch sauber untersuchen.

SASL bildet eine Schnittstelle zwischen verbindungsorientierten Anwendungsprotokollen und austauschbaren Authentisierungsmechanismen. Der Mechanismus beschreibt, wie Nachweise geprüft werden. Das Anwendungsprofil beschreibt, wie die Nachrichten übertragen werden und welche Zustandsänderung das Ergebnis auslöst. Dadurch können sich beide Seiten unabhängig weiterentwickeln.

Bei Erfolg kann eine ausgehandelte Sicherheitsschicht für die folgenden Daten beginnen. Ebenso kann eine Identität mit der Sitzung verbunden werden. Eine Liste aller erlaubten Postfächer, Befehle oder Verwaltungsfunktionen entsteht dadurch nicht. Die nächste Anfrage darf scheitern, ohne dass die vorige Antwort falsch war.

Zwei Identitäten in einem scheinbar einfachen Login

RFC 4422 nennt die mit den Nachweisen verbundene Seite Authentisierungsidentität. Die Autorisierungsidentität bezeichnet die Identität, als die der Client zu handeln wünscht. Im Normalfall sind beide gleich, weshalb viele Oberflächen nur einen Namen zeigen.

Bleibt die Zeichenfolge für die Autorisierungsidentität leer, bittet der Client darum, als die vom Server aus den Nachweisen abgeleitete Identität zu handeln. Das Modell unterstützt aber auch Stellvertretung: A weist sich als A aus und beantragt, als B aufzutreten.

Der Server muss dann zunächst die Nachweise von A prüfen und anschließend entscheiden, ob A als B handeln darf. Scheitert eine der beiden Prüfungen, scheitert der Austausch. Ein gültiges Passwort darf nicht allein deshalb zur Delegationsvollmacht werden, weil sein Besitzer eine andere Identität benennen kann.

Auch eine akzeptierte Autorisierungsidentität ist kein universelles Rollenpaket. Sie speist den Autorisierungszustand dieses Protokolls. Welche Ressource B lesen oder welche Operation B ausführen darf, bleibt eine weitere Entscheidung der Anwendung.

Das Anwendungsprofil beendet den Satz

Das SASL-Kernmodell schreibt nicht allen Protokollen dasselbe Identitätssystem vor. Jedes Profil muss festlegen, wie Mechanismen angeboten und gewählt, Herausforderungen und Antworten getragen, Autorisierungsidentitäten dargestellt und Sicherheitsschichten begonnen werden. Ebenso muss es die Reihenfolge mehrerer Schutzschichten und die Wirkung wiederholter Authentisierungen klären.

Diese Anforderungen markieren die Grenze der Austauschbarkeit. Ein Mechanismus kann kryptografisch verbessert werden, ohne die Bedeutung eines Postfachs zu kennen. Eine Anwendung kann den Mechanismus wechseln, ohne ihr Nachrichtenformat neu zu erfinden. Die Lücke dazwischen darf jedoch nicht mit angenommener Politik gefüllt werden.

In einer Installation folgen häufig weitere Schritte: Namensnormalisierung, Zuordnung zu einem internen Konto, Gruppenauflösung und Ressourcenregeln. Ein fehlerfreies SASL-Protokoll beweist weder die Aktualität noch die Enge dieser lokalen Zuordnungen.

Was die SMTP-Antwort 235 tatsächlich sagt

SMTP AUTH liefert ein begrenztes Beispiel. RFC 4954 definiert 235 2.7.0 Authentication Succeeded als Antwort auf den AUTH-Befehl und ordnet der SMTP-Sitzung eine Autorisierungsidentität zu. Das ist eine Aussage über diesen Befehl, kein Beleg für eine spätere E-Mail-Transaktion.

Wird während AUTH eine Sicherheitsschicht ausgehandelt, springt SMTP sogar in den Anfangszustand zurück. Zuvor gelernte Fähigkeiten werden verworfen, und der Client sollte erneut EHLO senden. Der erfolgreiche Abschluss der Authentisierung kann somit der Beginn einer neu aufgebauten Anwendungsphase sein.

Relay-Regeln, Empfängerprüfung, Inhaltskontrollen, Warteschlangen und Zustellung entscheiden sich danach. Der SMTP-Bezug soll hier keine Zustellungsdebatte wiederholen. Er zeigt, dass selbst ein eindeutiger Zahlencode nur das Verb beantwortet, zu dem er gehört.

Erfolgreich und absichtlich ohne Person

RFC 4505 definiert mit ANONYMOUS einen SASL-Mechanismus, der Zugang ermöglicht, ohne die Identität des Benutzers festzustellen oder offenzulegen. Die Rechte sind üblicherweise eingeschränkt. Freiwillige Spurinformationen werden nicht authentisiert und können gefälscht sein.

Ein SIEM darf daher nicht jeden SASL-Erfolg als „verifizierter Benutzer“ verbuchen. Zuerst muss die Semantik des gewählten Mechanismus bekannt sein. Andernfalls erzeugt die Auswertung eine Identitätsbehauptung, die der Austausch bewusst nicht geliefert hat.

Stärkere Nachweise schreiben keine Zugriffsregel

RFC 7677 registrierte SCRAM-SHA-256 und SCRAM-SHA-256-PLUS. SHA-256 und die Behandlung von Channel Binding stärken den austauschbaren Teil der Authentisierung. Der Mechanismus erfährt dadurch dennoch nicht, wem ein bestimmtes Postfach gehört oder wer einen privilegierten Befehl ausführen darf.

Eine kryptografische Migration kann Risiken für Nachweise und Kanal verringern. Sie beseitigt keine zu große Gruppe, keine abgelaufene Stellvertretung und keine fehlerhafte Ressourcenregel. Wer nur den neuen Mechanismus testet, kann eine moderne Authentisierung vor einer unverändert falschen Autorisierung errichten.

Beweise nicht in ein einziges Benutzerfeld pressen

Für eine Untersuchung sollten Mechanismus, Kanalschutz, abgeleitete Authentisierungsidentität, angeforderte und akzeptierte Autorisierungsidentität, die Stellvertretungsregel sowie die spätere Anwendungsentscheidung getrennt vorliegen. Ein einzelnes Feld „Benutzer“ spart Speicher und vernichtet Erklärbarkeit.

Ohne diese Trennung sehen gestohlene Nachweise, zu breite Delegation, veraltete Verzeichniszuordnung und zu großzügige Anwendungsrechte gleich aus. Ein Erfolgsbit reicht für den Zustandsautomaten, nicht für die Rekonstruktion von Verantwortung.

Auch die Benutzeroberfläche kann präzise bleiben. „Angemeldet als“ beschreibt eine Sitzung. „Darf dieses Objekt ändern“ beschreibt eine geprüfte Berechtigung. Wer beide Aussagen unterscheidet, macht die Ablehnung nach dem Login verständlich und zeigt, wo die Kontrolle tatsächlich liegt.

Quellen