Zusammenfassung

  • draft-ietf-emu-eap-ppt-04 entfernt die 128 Oktette, die der Vorgänger aus dem äußeren TLS-Exporter ableitete, und stellt klar: EAP-PPT erzeugt weder MSK noch EMSK.
  • Ein Privacy-Pass-Token ist eine im Tunnel übertragene Inhaberberechtigung. Der Tunnelterminator sieht das Token und berechnet denselben Exporter-Wert; die Bytes beweisen keine Identität von Inhaber und Endpunkt.

Der kryptografische Exporter tat, was verlangt war: Er gab 128 Oktette aus. Der Fehler lag nicht in der Berechnung, sondern in der Aussagekraft, die das Protokoll diesem Ergebnis zugeschrieben hätte.

Revision 03 von Extensible Authentication Protocol (EAP) Using Privacy Pass Token leitete die Oktette unter dem Label EXPORTER_EAP_PPT_Key_Material aus dem äußeren TLS-Tunnel ab. EAP-Typ und eingelöstes Token standen im Kontext. Eine Implementierung konnte die Ausgabe als Master Session Key und Extended Master Session Key von EAP-PPT melden.

Revision 04 vom 30. September löscht diese Konstruktion. EAP-PPT liefert keine MSK und keine EMSK; Implementierungen dürfen der Tunnelmethode kein EAP-PPT-Schlüsselmaterial melden. Die Streichung beseitigt keinen echten Schutz. Sie verhindert, dass überzeugend aussehende Bytes eine Bindung behaupten, die ihre Eingaben nicht herstellen.

Das Inhaber-Token bringt kein exklusives Geheimnis ein

EAP-PPT läuft als innere EAP-Methode. Der Peer bezieht außerhalb des Protokolls ein Privacy-Pass-Token von einem Issuer, tritt in einen serverauthentisierten TLS-Tunnel einer anderen EAP-Methode ein und übermittelt das Token zur Einlösung an den EAP-PPT-Server.

Öffentlich prüfbare Tokens werden mit dem öffentlichen Schlüssel des Issuers verifiziert. Privat prüfbare Tokens nutzen Material, das Issuer und EAP-PPT-Server teilen. In keinem Fall entsteht ein neues gemeinsames Geheimnis zwischen Peer und Server. Der Peer weist Besitz nach, indem er eine übertragbare Inhaberberechtigung sendet; der Server prüft ihre Gültigkeit.

Der TLS-Exporter gehört dagegen zur äußeren Sitzung. Jede Partei, die den Tunnel terminiert, kann dieselbe Ausgabe berechnen. Da das Token durch diesen Tunnel läuft, kennt der Terminator auch den Tokenwert im Exporter-Kontext. Der Kontext unterscheidet Ableitungen, fügt aber keinen vor dem Terminator verborgenen Beitrag hinzu.

Der Wert kann frisch, sitzungseindeutig, korrekt bezeichnet und 128 Oktette lang sein. Trotzdem beantwortet er nicht die entscheidende Frage: Welches nur dem inneren Peer bekannte Geheimnis floss ein? Keines. Länge und zufälliges Aussehen ersetzen keine exklusive Beteiligung.

Äußeres TLS beweist den inneren Peer nicht

In TEAP wird die Verwechslung gefährlich. Ein Crypto-Binding TLV kann Material aus Tunnel und innerer Methode verbinden. Meldet EAP-PPT als inneren Schlüssel einen Wert, der vollständig aus demselben Tunnel und einem für dessen Terminator sichtbaren Token stammt, sieht das Ergebnis wie die Verknüpfung zweier unabhängiger Beweise aus. Tatsächlich besitzt eine Partei alle Eingaben.

Revision 04 benennt das Problem ausdrücklich. Der alte Wert würde einer Tunnelmethode erlauben, einen Crypto-Binding TLV zu berechnen, ohne eine kryptografische Bindung von EAP-PPT an den Tunnel sicherzustellen. Der Nachrichtenablauf zeigt zwei Beiträge; die Geheimnisstruktur enthält nur einen.

Die korrigierte Grenze ist klar. EAP-PPT autorisiert einen Peer durch Token-Einlösung, schlüsselt aber nicht den Link. Das Schlüsselmaterial für den Link kommt von der äußeren EAP-Tunnelmethode. Zeigt ein Produkt für EAP-PPT weiterhin MSK oder einen exporterartigen Schlüssel, ist das kein zusätzlicher Beweis, sondern die Rückkehr der gestrichenen Mehrdeutigkeit.

Eine schlüssellose innere Methode verändert das Relay-Risiko

Ohne innere kryptografische Bindung ist die Prüfung des Serverzertifikats die erste Verteidigung gegen Relays. Bringt ein Angreifer den Peer dazu, dessen TLS-Tunnel zu akzeptieren, kann er den EAP-PPT-Austausch zu einem echten Dienst weiterleiten, das Inhaber-Token beobachten und für eigenen Zugang einlösen.

Der Entwurf verlangt deshalb eine strenge, netzspezifische Prüfung des EAP-Serverzertifikats. Der Peer soll die erwartete Identität abgleichen, Fehler ablehnen statt dem Nutzer eine Ausnahme anzubieten und nicht auf Trust on First Use bauen. Wird origin_info im Privacy-Pass-Challenge gesetzt und mit der Zertifikatsidentität verglichen, begrenzt dies Challenge-Ersetzung; inneres Schlüsselmaterial entsteht dadurch nicht.

Auch die Serverplatzierung ist Teil des Modells. Werden EAP- und EAP-PPT-Server zusammengelegt, entfällt eine innerhalb des Anbieters ausnutzbare Trennung. Getrennte Phase-1- und Phase-2-Server werden ohne geschützte Beziehung und ein abgesichertes Zwischenprotokoll nicht empfohlen. Das ist eine Vertrauensgrenze, nicht nur eine Betriebsfrage.

Channel Binding kann eine Abweichung zwischen dem vom Peer angenommenen Netz und dem dem Server bekannten Authenticator erkennen. Kurzlebige Tokens begrenzen Verluste; Double-Spend-Erkennung kann ein Relay nachträglich sichtbar machen. Diese Maßnahmen helfen, verleihen der gestrichenen Exporter-Ausgabe aber keine Bindungswirkung.

Das Token kann vor dem Kontexturteil verbraucht sein

Revision 04 fügt außerdem eine Reihenfolge hinzu, die eine allgemeine Erfolgsmetrik verdecken würde. Nach erfolgreicher Einlösung kann der EAP-PPT-Server vor EAP Success ein EAP-Request/PPT-Channel-Binding senden. Er darf darauf verzichten, wenn eine frühere EAP-Methode passende Informationen geliefert hat.

Mit dem Empfang dieser Anfrage weiß der Peer, dass das Token akzeptiert und verbraucht ist. Spätere Ereignisse ändern dies nicht. Eine fehlerhafte Antwort, ein ungültiger Kontext, ein EAP-Fehler oder später verweigerter Zugang machen das Token nicht wiederverwendbar. Wiederholungsregeln vor der Einlösung gelten ab diesem Punkt nicht mehr.

„Token verbraucht“ ist somit ein enger Beleg. Er beweist die Einlösung, nicht erfolgreiches Channel Binding, EAP Success, Installation äußerer Link-Schlüssel, eine RADIUS/NAS-Zulassung oder tatsächlich nutzbaren Netzverkehr.

Verbrauch als Verbindung zu zählen, verschmilzt mehrere unabhängige Entscheidungen. EAP Success als Beweis dafür zu behandeln, dass dieselbe Entität Token und Tunnel kontrollierte, würde in der Telemetrie genau die Überbehauptung wiederholen, die Revision 04 aus dem Schlüsselplan entfernt.

Revision 04 ändert mehr als das Encoding

Die neue Fassung ersetzt JSON-Inhalte durch TLVs im TEAP-Stil und transportiert Privacy-Pass-Strukturen direkt statt in base64url. Hinzu kommen ein No-Suitable-Token TLV, Regeln für Länge, Duplikate, vollständigen Feldverbrauch und eine Verschachtelungsebene, eine M-Bit-Regel für unbekannte TLVs und Testvektoren auf Oktettebene.

Fehlercode 9 trennt eine fehlerhafte Nachricht ohne Einlösung von einem wohlgeformten Token, das bei der Prüfung scheitert. Diese Trennung entscheidet über die Wiederverwendung. Außerdem erweitert der Entwurf die Relay-Analyse und präzisiert Empfehlungen für öffentliche, private und föderierte Tokenarten.

Präzision auf dem Draht ist kein Einsatznachweis. Das Dokument ist ein aktiver Internet-Draft der EMU-Arbeitsgruppe mit dem Ziel Proposed Standard. Datatracker führt weiterhin I-D Exists, ohne zuständigen Area Director, Shepherd oder Telechat. Es ist kein RFC; die eingefrorenen Quellen belegen weder Implementierung noch Interoperabilität, Leistung oder Einführung.

Der Betrieb muss getrennte Belege verbinden

Ein prüfbarer Betrieb speichert getrennt: konfiguriertes Netz und erwarteten EAP-Servernamen; geprüftes Zertifikat, Trust Anchor und tatsächlichen TLS-Endpunkt; Challenge und origin_info; Tokenart, Issuer-Schlüssel und Challenge-Hash; Einlöseergebnis und Verbrauchszeit; Quelle und Ergebnis des Channel Binding; EAP Success oder Failure; äußere Link-Schlüssel; RADIUS/NAS-Entscheidung; beobachteten Zugang.

Das Zertifikat beantwortet, welchen Server der Peer akzeptierte. Die Einlösung beantwortet, ob die Berechtigung gültig war. Channel Binding vergleicht Netzkontexte. Das EAP-Ergebnis markiert ein Protokollende. Erst NAS-Entscheidung und Verkehr zeigen nutzbaren Zugang. Ein einziges Feld „authentifiziert“ kann diese Kausalität nicht enthalten.

Die Lehre lautet nicht, Spezifikationen gering zu schätzen. Revision 04 ist gerade deshalb wertvoll, weil sie einer plausiblen Ausgabe keine unbegründete Autorität gibt. Der laufende Betrieb muss die Verknüpfungen bewahren, die 128 gestrichene Oktette nie beweisen konnten.

Quellen