Zusammenfassung

  • draft-ietf-tls-pake-02 trennt ein gemeinsam unterstütztes PAKE-Scheme von einem vorhandenen Registrierungsdatensatz; bei fehlendem Datensatz darf der Server eine plausible Antwort simulieren.
  • Erst das Client-Finished bestätigt dem Server den sitzungsgebundenen Schlüsselbesitz; Zertifikatsidentität, Kontoberechtigung, Registrierung und Quantenschutz des Passworts bleiben eigene Kontrollen.

Client und Server unterstützten dasselbe PAKE-Scheme. Der Server wählte es aus und schickte seinen Anteil. Im Registrierungsbestand gab es für das Identitätspaar jedoch keinen Datensatz.

Die Aushandlung war erfolgreich. Die Authentisierung musste scheitern.

Revision 02 von draft-ietf-tls-pake wurde am 6. Juli 2026 veröffentlicht und läuft am 7. Januar 2027 ab. Sie ist ein aktiver Informational Internet-Draft der TLS-Arbeitsgruppe, kein RFC, kein fertiges Register, kein Implementierungsnachweis und keine Sicherheitszertifizierung. Der Text weist selbst auf noch fehlende wesentliche Sicherheitsanalyse hin.

Niedrige Entropie braucht ein eigenes Verfahren

Der TLS-1.3-PSK-Binder setzt einen hochentropischen Schlüssel voraus. Ein menschliches Passwort würde beobachtbare Werte für Wörterbuchtests liefern. Der Entwurf transportiert daher PAKE-Nachrichten in einer Erweiterung und kombiniert ihr Ergebnis mit dem regulären ephemeren TLS-Schlüsselaustausch.

Der Client sendet ein gemeinsames Paar aus client_identity und server_identity sowie eine sortierte Liste verschiedener PAKEShare-Angebote. Der Server sucht ein unterstütztes Scheme und anschließend lokales Registrierungsmaterial.

Diese Reihenfolge ist entscheidend. Die Scheme-Tabelle beantwortet, welche Mathematik implementiert ist. Die Registrierungsdatenbank beantwortet, ob für dieses Identitätspaar die erforderlichen Werte existieren. Ein Monitoringfeld darf beide Fragen nicht als pake_match zusammenfassen.

Eine simulierte Antwort schützt den Registrierungsbestand

Fehlt der Datensatz, kann der Server einen zufällig plausiblen Anteil erzeugen und den Ablauf fortsetzen. Der Client kann daraus nicht denselben Schlüssel ableiten und scheitert später mit überwältigender Wahrscheinlichkeit an Finished.

Damit verrät ServerHello nicht sofort, ob ein Konto existiert. Für die Auswertung bedeutet es: Scheme-Auswahl und Serveranteil sind keine positiven Kontobelege. Die Simulation ist bewusst so gestaltet, dass ein unbekannter Benutzer zunächst wie ein falsches Passwort aussieht.

Der Schutz endet nicht beim Nachrichtenformat. Unterschiedliche Datenbankzeiten, Cachepfade, CPU-Kosten, Alerts, Protokolleinträge oder Rate-Limit-Gruppen können die Fälle wieder trennen. Konformität der Bytes ist kein Nachweis für Seitenkanalgleichheit.

Client-Finished ist der entscheidende Übergang

Das PAKE-Geheimnis fließt mit (EC)DHE in den TLS-Schlüsselplan. Finished bestätigt den Transcript. Aus Serversicht ist der Client erst nach erfolgreicher Prüfung seines Finished authentisiert.

Vorher sollten keine Anwendungsdaten fließen. Schon ein personalisierter Header oder eine andere Antwortlänge kann ein echtes Konto bestätigen. Produktionstelemetrie muss daher den Zeitpunkt der Finished-Prüfung und das erste Anwendungsbyte getrennt erfassen.

Auch danach ist die Aussage begrenzt. Finished beweist Schlüsselbesitz für diese Sitzung, nicht den rechtmäßigen Kontoinhaber, eine korrekte Registrierung, ein vertrauenswürdiges Gerät oder die Berechtigung für eine konkrete Aktion. Autorisierung folgt in einer anderen Kontrollfläche.

PAKE-Identität, SNI und Zertifikat haben eigene Besitzer

Der Entwurf erklärt server_identity ausdrücklich für unabhängig von SNI. Die PAKE-Identität indexiert Kontext und Registrierung; SNI dient typischerweise Routing und Dienstauswahl. Sendet der Client zusätzlich signature_algorithms, muss der PAKE-wählende Server Certificate und CertificateVerify liefern.

PAKE allein und PAKE plus Zertifikat sind damit verschiedene Modi. Eine Organisation kann Übereinstimmung der Namen fordern, aber diese Regel stammt aus ihrer Konfiguration. Der Drahtstandard erzeugt sie nicht.

Ein Auditbeleg sollte PAKE-Identität, SNI, validierte Zertifikatsreferenz und resultierendes Anwendungskonto getrennt speichern. Ein normalisiertes Feld verschleiert, welche Authority eine Zuordnung festgelegt hat.

Externes PAKE benötigt einen Verbindungsbeleg

Interne PAKEs passen in ClientHello und ServerHello. Verfahren mit zusätzlichen Runden laufen vor TLS und importieren ihr Ergebnis nach RFC 9258 als externen PSK.

Der spätere PSK-Handshake beweist Besitz des importierten Schlüssels. Er beweist nicht automatisch, dass der frühere PAKE-Lauf mit dem beabsichtigten Peer, den richtigen Rollen und dem richtigen Channel Binding verbunden war.

RFC 9258 bindet importierte Schlüssel an Protokoll, KDF und Kontext. Die Anwendung muss diesen Kontext korrekt liefern und den vorherigen Transcript mit der verbrauchenden Verbindung korrelieren. Ohne diesen Join ist der TLS-Erfolg nur die zweite Hälfte der Beweiskette.

Post-Quanten-Verkehr schützt nicht automatisch das Passwort

Ein hybrider oder post-quantenfähiger TLS-Key-Share kann aufgezeichneten Anwendungsverkehr vor späterer Entschlüsselung schützen. Bleibt das PAKE klassisch, kann sein eigener aufgezeichneter Transcript künftig die Wiedergewinnung eines langfristigen Passworts ermöglichen.

Dann bleibt der alte Verkehr geheim, während das Passwort neue Impersonation erlaubt. Verkehrsvertraulichkeit und Lebensdauer des Credentials brauchen getrennte Statusanzeigen und Migrationspläne.

OQUAKE, OQUAKE+ und eine hybride externe Kombination werden in noch aktiven Forschungsentwürfen beschrieben. Ihre Nennung im TLS-Entwurf ist kein abgeschlossener Auditnachweis.

Registrierung und Reset liegen vor der Verbindung

PAKE setzt bereits provisionierte Passwörter oder Verifier, Identitäten, Salts und Parameter voraus. Der Entwurf regelt nicht, wer die Person beim Anlegen geprüft hat, wer einen Reset genehmigt, wie Schemes migriert oder alte Datensätze gelöscht werden.

Ein perfekter Handshake kann deshalb einen falsch angelegten Datensatz bestätigen. Zwei Verifier können nach einer Migration parallel gültig bleiben. Ein deaktiviertes Anwendungskonto kann noch kryptografisches Material besitzen.

Registrierungsversion, Freigabeauthority, Rotation und Löschbeleg gehören in ein eigenes Ledger. TLS kann diese institutionellen Fakten nicht aus dem Transcript ableiten.

Kompatibilität ist nur der erste Beleg

Das vorgeschlagene Framework ist nützlich, weil es Passwörter nicht als rohe PSKs behandelt und mehrere PAKEs integrieren kann. Seine Flexibilität verlangt aber genauere Zustände.

Gemeinsames Scheme, realer Datensatz, Client-Finished, Zertifikat, Autorisierung und Ergebnis sind aufeinanderfolgende, begrenzte Behauptungen. Ein grünes Symbol an der ersten Stufe darf die restlichen nicht vorwegnehmen.

Die belastbare Führungsentscheidung besteht deshalb darin, jeden Übergang einem Besitzer und einem reproduzierbaren Receipt zuzuordnen. Nur dann kann ein Fehler repariert werden, ohne das gesamte Authentisierungssystem pauschal für sicher oder unsicher zu erklären.

Quellen