Zusammenfassung

  • Der EMU-Arbeitsgruppenentwurf EAP-PPT vom 30. September sagt in Fassung 04 ausdrücklich, dass das innere Verfahren weder MSK noch EMSK ableitet und dem tragenden Tunnelverfahren kein EAP-PPT-Schlüsselmaterial melden darf. Fassung 03 teilte noch 128 Oktette aus einem TLS-Exporter in zwei 64-Oktett-Schlüssel auf. Das Dokument steht bei I-D Exists; es ist weder RFC noch Nachweis eines produktiven Einsatzes.
  • Die Prüfung eines Privacy-Pass-Tokens kann Zugang autorisieren, erzeugt aber kein neues Geheimnis, das Peer und EAP-PPT-Server miteinander teilen. Ein TLS-Endpunkt kann seinen Exporter-Wert selbst berechnen. Ihn als unabhängig beigesteuerten Innenschlüssel zu verbuchen, ließe die kryptografische Bindung stärker aussehen, als sie ist.

Die Frage nach einem vorhandenen Schlüssel reicht bei einem geschachtelten Zugangsverfahren nicht aus. Entscheidend ist, wer ihn berechnen konnte. EAP-PPT übermittelt ein Privacy-Pass-Token innerhalb eines serverauthentisierten TLS-Tunnels. Die dritte Entwurfsfassung leitete aus dessen Exporter einen Wert von 128 Oktetten ab und bezeichnete die beiden Hälften als Master Session Key und Extended Master Session Key des inneren Verfahrens. Die vierte Fassung nimmt diese Konstruktion zurück. Abschnitt 5.7 erklärt, EAP-PPT erzeuge beide Schlüssel nicht und dürfe auch kein entsprechendes Material an das Tunnelverfahren melden.

Das ist mehr als eine redaktionelle Umbenennung. Bei einem öffentlich prüfbaren Token verwendet der Server den öffentlichen Schlüssel des Ausstellers. Bei einem privat prüfbaren Token verwendet er Material, das Aussteller und EAP-PPT-Server teilen. Der Peer, der das Token vorzeigt, ist an diesem zweiten Geheimnis nicht beteiligt. Er belegt den Besitz eines Inhaber-Nachweises, vereinbart aber durch dessen Einlösung kein neues gemeinsames Geheimnis mit dem Server. Der Endpunkt des äußeren TLS-Tunnels kennt dagegen die Sitzung, aus der der frühere Exporter-Wert stammt.

Die abgeleiteten Bytes können existieren, ohne eine unabhängige Verbindung zwischen Token-Inhaber und Tunnel-Peer zu beweisen.

Das überarbeitete Verzeichnis der Sicherheitsmerkmale verneint für EAP-PPT Schlüsselerzeugung und kryptografische Bindung. Es bejaht weiterhin Channel Binding. Letzteres dient dem Abgleich von Netzwerkinformationen, die Peer und Serverseite sehen, und ist nicht derselbe Nachweis wie ein gemeinsam ausgehandelter Innenschlüssel. Ebenso wenig bedeutet der fehlende Innenschlüssel, dass der gesamte Zugang unverschlüsselt wäre: Das tragende EAP-Tunnelverfahren authentisiert seinen Server und liefert den Verbindungsschlüssel an den Authenticator. Die neue Aussage begrenzt den Anspruch des Tokens, nicht die Aufgabe des Tunnels.

Abschnitt 9.4 beschreibt, weshalb eine falsche Zuschreibung gefährlich sein kann. Akzeptiert der Peer das Zertifikat eines Angreifers, könnte dieser einen TLS-Tunnel zum Peer aufbauen, den inneren EAP-PPT-Austausch an einen echten Server weiterleiten und das Token für den eigenen Zugang einlösen. Als primäre Abwehr nennt der Entwurf strenge Zertifikatsprüfung anhand netzspezifischer Vertrauensanker und der erwarteten Serverkennung. Weder Vertrauen beim ersten Kontakt noch eine Nutzer-Ausnahme nach fehlgeschlagener Prüfung soll die Grenze aufweichen.

Zusammenlegung von Serverfunktionen, Channel Binding, kurze Lebensdauer und Erkennung doppelter Einlösung können Folgen begrenzen; sie machen ein Inhaber-Token nicht zu einem Schlüsselaustausch.

Fassung 04 ändert außerdem das Nachrichtenformat von JSON zu TLV und präzisiert Parsing und Fehlerbehandlung. Das ist ein eigener technischer Strang, kein Beleg für einen bekannten Vorfall oder einen Defekt bei einem Anbieter. Die nachprüfbare Nachricht hier ist die Streichung einer Schlüsselbehauptung, die vom TLS-Endpunkt selbst erfüllbar war. Ein Sicherheitsbegriff sollte die Herkunft der Garantie anzeigen, nicht nur das Vorhandensein eines Zahlenwerts.

Quellen