Zusammenfassung

  • Im gegenseitigen Modus signierte der Client sowohl die Server-Challenge als auch einen selbst erzeugten Zufallswert. Die abschließende Serversignatur umfasste beide Werte und ergänzte einen dritten, weil der Client die erste Server-Challenge schon vor der Wahl seines eigenen Werts kannte.
  • Der dritte Wert band die Serverantwort an einen neuen Zufallsbeitrag. Er machte den Mechanismus aber nicht zu einem sicheren Kanal: RFC 3163 bietet weder Integrität noch Vertraulichkeit und warnt vor weiterhin möglichen aktiven Angriffen.

Was wie eine Wiederholung aussieht

Der Ablauf wirkt zunächst redundant. Der Server sendet eine Zufalls-Challenge, der Client signiert einen sie enthaltenden Nachweis, und anschließend signiert auch der Server einen Nachweis mit derselben Challenge. Wozu benötigt das abschließende Servertoken dann noch einen dritten Zufallswert?

Die Antwort in RFC 3163, „ISO/IEC 9798-3 Authentication SASL Mechanism“, ergibt sich aus der Reihenfolge der Entscheidungen. Entscheidend ist nicht die Anzahl der Nachrichten, sondern wer die Challenge der Gegenseite bereits kannte, als er seinen eigenen Zufallswert wählte. Diese Reihenfolge begrenzt, was eine Signatur über den Austausch belegen kann.

Das im August 2001 als Experimental veröffentlichte Memo definiert zwei Mechanismusfamilien. 9798-U-<algorithm> authentisiert den Client gegenüber dem Server. 9798-M-<algorithm> ergänzt die gegenseitige Entity-Authentisierung: Der Client signiert eine Server-Challenge, danach signiert der Server eine Client-Challenge. Beide verwenden asymmetrische Signaturen und X.509-Zertifikate; zu den beschriebenen Prüfungen gehört die Verarbeitung des Zertifizierungspfads.

Reihenfolge der signierten Werte

In beiden Modi erzeugt der Server zunächst R_B. Danach wählt der Client R_A und sendet TokenAB mit Zertifikatsinformationen und einer Signatur über R_A und R_B. Optional kann der Client auch eine Serverkennung aufnehmen. Der Server prüft die Signatur, gleicht R_B mit seiner ursprünglichen Challenge ab und kontrolliert gegebenenfalls die Kennung.

Im einseitigen Modus schließt dieses Client-Token den Kernablauf ab. Der gegenseitige Modus ergänzt die Serverantwort: TokenBA2 enthält das Serverzertifikat und eine Signatur über R_A, R_B sowie einen neuen Wert R_C. Der Client prüft Zertifikat und Signatur, gleicht die beiden früheren Werte mit den vorherigen Schritten ab und kontrolliert eine etwaige Clientkennung.

Abschnitt 7 erklärt R_C. Weil die Client-Signatur R_A einschließt, kann der Server keine Signatur über Daten erhalten, die er vor Beginn des Mechanismus selbst festgelegt hat. Die Gegenrichtung ist jedoch nicht symmetrisch: Der Client kannte R_B, bevor er R_A wählte. Die Serversignatur muss R_B enthalten, damit der Client den Ablauf prüfen kann; dieser Wert allein bietet dem Server aber nicht denselben Schutz. Deshalb nimmt RFC 3163 R_C in das vom Server signierte TokenBA2 auf.

Das ist die konkrete Begründung des RFC, kein allgemeiner Nachweis gegen sämtliche Relays, Wiederholungen oder aktiven Angriffe. Die Werte müssen von einem kryptografisch starken Zufallszahlengenerator stammen; Vorhersagbarkeit macht den Mechanismus angreifbar. Der dritte Wert begegnet dem beschriebenen Zeitversatz, nicht sämtlichen Eigenschaften außerhalb des signierten Transkripts.

Eine Signatur schützt keine Sitzung

Die Grenze ist ausdrücklich festgelegt. RFC 3163 zufolge liefert der Mechanismus nur Authentisierung. Er gewährleistet weder die Integrität späterer Protokollnachrichten noch die Vertraulichkeit ihrer Inhalte. Der Sicherheitsteil beschränkt den Schutz auf passives Belauschen und nennt aktive Angriffe, einschließlich Session-Hijacking, als weiterhin möglich. Die IESG-Anmerkung kritisiert noch deutlicher, dass das Verfahren den Aufwand einer PKI auf sich nimmt, aber die Integrität jeder Übertragung verwirft; TLS könne den Effekt mit Integritätsvorteilen bereitstellen.

Auch die Zertifikatsfelder vereinen diese Ebenen nicht. authID in TokenAB kann eine für Zugriffskontrolle verwendete Identität bezeichnen, die vom Zertifikatssignierer abweicht. Annahme des Zertifizierungspfads, Mechanismus-Authentisierung, Identitätszuordnung und Anwendungsautorisierung sind getrennte Entscheidungen. Eine gültige Signatur belegt, dass ein Schlüssel die abgedeckten Daten signiert hat – nicht, was eine Anwendung erlauben sollte.

Das IMAP-Beispiel im RFC zeigt ebenfalls nicht den gegenseitigen Modus. Es demonstriert einseitige 9798-U-Authentisierung und erklärt, dass Base64-Kodierung sowie das vorangestellte + aus dem IMAP-Profil stammen, nicht aus dem SASL-Mechanismus. Das Beispiel ist eine Protokollillustration, kein Beleg für Nutzung oder Interoperabilität.

Lu Hengs Note 20 dient hier ausschließlich als interpretative Linse: tatsächliche Protokollprüfungen von weitergehenden Aussagen über Identität oder Autorität trennen. Nonce-Abgleich und verifizierte Signaturen sind Belege im Transkript; Kanalschutz und Anwendungsrechte brauchen andere Kontrollen. Diese Linse wird den RFC-Autoren nicht zugeschrieben.

Quellen

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. RFC-Editor-Eintrag zu RFC 3163
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. IANA-Register der SASL-Mechanismen
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile