Zusammenfassung

  • RFC 9678 bindet eine optionale ECDHE-Aushandlung mit X25519 oder P-256 über AT_MAC an den bestehenden EAP-AKA'-Austausch und speist das Ergebnis in K_re, MSK und EMSK ein.
  • Der authentisierte Transcript kann Angebot, Auswahl und öffentliche Werte beweisen; er kann weder den späteren Speicherzustand noch die Löschung aller abgeleiteten Schlüssel attestieren.
  • Eine belastbare Aussage über vergangene Sitzungen braucht getrennte Belege für Richtlinie, Ableitung, Verbraucherbindung, Sitzungsende, Kopieninventar, Vernichtung und einen unabhängigen Wiederherstellungsversuch.

Zwei Prüfungen, zwei Gegenstände

Ein Prüfer verifiziert den aufgezeichneten EAP-AKA'-Austausch. Die angebotenen AT_KDF_FS-Werte sind korrekt, beide öffentlichen ECDHE-Werte stehen an der erwarteten Stelle, und AT_MAC ist gültig. Der Transcript hat seine Prüfung bestanden.

Ein zweiter Prüfer untersucht einen Crashdump des Authentisierungsdienstes. Dort liegt eine noch verwertbare MSK. Die beiden Ergebnisse widersprechen sich nicht. Die erste Prüfung fragt, ob das Protokoll authentisiert ausgeführt wurde. Die zweite fragt, ob sein geheimes Ergebnis nach dem Sitzungsende noch existierte.

Der Fehler entsteht erst, wenn eine Organisation die erste Antwort als Ersatz für die zweite verwendet. Ein MAC schützt Nachrichten vor unbemerkter Veränderung. Er reicht nicht in die Zukunft und meldet nicht zurück, was ein Endpunkt mit seinen Schlüsseln getan hat.

Die präzise Erweiterung

RFC 9678 erschien im März 2025 als Proposed Standard und aktualisiert RFC 9048 sowie dessen Vorgänger RFC 5448. EAP-AKA' stützt sich auf einen symmetrischen Langzeitschlüssel auf Teilnehmer- und Heimatnetzseite. Wird Verkehr gespeichert und dieser Schlüssel später kompromittiert, können ältere Sitzungen ohne unabhängigen flüchtigen Beitrag retrospektiv gefährdet sein.

Die Erweiterung fügt Elliptic Curve Diffie-Hellman hinzu. Der Server sendet eine geordnete Auswahl in einem oder mehreren AT_KDF_FS-Attributen und seinen öffentlichen Wert in AT_PUB_ECDHE. Der Peer wählt eine unterstützte Variante und antwortet mit seinem Wert. IANA registriert die Attributtypen 152 und 153; spezifiziert sind zunächst X25519 und P-256.

Die neuen Attribute werden vom bestehenden AT_MAC erfasst. Ein nicht authentisierter Beobachter kann damit weder öffentlichen Schlüssel noch KDF-Auswahl unbemerkt austauschen. Das gemeinsame Geheimnis trägt zu MK_ECDHE bei; daraus entstehen K_re, MSK und EMSK.

Die Verbesserung richtet sich gegen eine spätere Offenlegung des Langzeitschlüssels. Sie behauptet nicht, einen aktiven Angreifer aufzuhalten, der diesen Schlüssel bereits während der laufenden Authentisierung besitzt und im Pfad sitzt. Sicherheitsbehauptungen müssen daher den Zeitpunkt des Schlüsselbesitzes nennen.

Optionalität erzeugt unterschiedliche Erfolgsarten

Die Erweiterung ist optional. Unterstützt oder akzeptiert ein Peer sie nicht, kann er die neuen Attribute ignorieren und gewöhnliches EAP-AKA' verwenden, sofern seine lokale Richtlinie das zulässt. Ist Forward Secrecy vorgeschrieben, muss die Authentisierung bei fehlender gemeinsamer Option scheitern, statt die schwächere Route als geschützt zu etikettieren.

Ein erfolgreicher Zugang sagt deshalb nicht, welcher Pfad genommen wurde. Eine Flotte kann eine nahezu perfekte Erfolgsrate melden und zugleich einen großen Legacy-Anteil besitzen. Umgekehrt kann eine strikte Einführung sichtbare Ausfälle verursachen, weil sie das Fallback beendet.

Peer und Server besitzen jeweils Entscheidungsspielraum. Messbar werden müssen Fähigkeit, Angebot, konkrete Auswahl, authentisierter Abschluss, erlaubtes Fallback und richtlinienbedingte Ablehnung. Nur so bleibt die Kompatibilitätsentscheidung gegenüber der späteren Exposition sichtbar.

Das Löschpostulat steht im RFC

Die Sicherheitsanalyse macht ihre Aussage über beendete Sitzungen von einer Annahme abhängig: Alle relevanten Sitzungsschlüsselmaterialien wurden gelöscht. Dazu gehören der flüchtige private Wert und abgeleitete Schlüssel, mit denen alter Zustand wiederhergestellt oder weiterverwendet werden könnte.

Die mögliche Menge ist größer als der Speicherbereich der EAP-Bibliothek. Authentisierungsserver, Schlüsseldaemon, Hardwarebeschleuniger, Access Point, Gateway, Reauthentisierungscache, Swap, Ruhezustandsabbild, Core Dump, Backup oder Telemetriesystem können Kopien halten. Eine erfolgreiche Zeroize-Funktion beweist nur etwas über den Bereich, den sie tatsächlich kontrolliert.

Auch „beendet“ hat mehrere Zuständigkeiten. Das EAP-Verfahren kann abgeschlossen sein, während eine Link-Assoziation weiterläuft. Ein Tunnel kann Material länger verwenden. Ein Mobilitätswechsel kann alte und neue Kontexte überlappen lassen. Datenbank und Gateway können verschiedene Ablaufzeiten haben.

Für jede Schlüsselklasse braucht es daher ein definiertes Ruhestandsereignis, einen verantwortlichen Verwahrer, eine maximale Aufbewahrung und einen überprüfbaren Vernichtungsmechanismus. Verschlüsselte Backups sind geschützte Kopien, keine gelöschten Kopien. Forensische Ausnahmen können legitim sein, müssen aber den Umfang der Nichtwiederherstellbarkeitsbehauptung begrenzen.

Reauthentisierung ohne neuen DH-Lauf

Wurde bei der ursprünglichen Vollauthentisierung die Erweiterung verwendet, stammt auch K_re aus der ECDHE-beeinflussten Hierarchie. Spätere Reauthentisierungen erben dadurch Schutz gegen eine nachträgliche Offenlegung des Langzeitschlüssels.

Sie führen aber keinen neuen Diffie-Hellman-Austausch aus. Ein aktuelles Betriebsereignis kann kryptographisch von einer viel älteren Vollauthentisierung abhängen. Alter, Wiederverwendungszahl und Grenze für eine erzwungene neue Vollauthentisierung gehören deshalb zum Kontext.

Wer jede Reauthentisierung als „neues ECDHE“ darstellt, erfindet Frische. Der Nachweis sollte sie mit ihrer Ursprungsauthentisierung verbinden und die verbleibende Lebensdauer von K_re offenlegen.

Der Verbraucher bestimmt die Verkehrseigenschaft

EAP exportiert MSK und EMSK an andere Schichten. Welcher praktische Gewinn entsteht, hängt vom Verbraucher ab. Führt IKEv2 anschließend einen eigenen flüchtigen Austausch durch, kann der Tunnel seine eigene Forward Secrecy erhalten. Verwendet eine Link-Schicht die EAP-Ausgabe direkt, ohne eine weitere unabhängige Vereinbarung, ist RFC 9678 für den historischen Schutz möglicherweise entscheidend.

Der EAP-Erfolg braucht deshalb eine Verbraucherbindung. Welche MSK-Instanz ging an welche Assoziation? Gab es einen weiteren flüchtigen Austausch? Wann endete die Nutzung? Welche nachgelagerte Komponente hielt eine Kopie? Ohne diese Antworten belegt der Transcript eine Methode, aber nicht die Eigenschaft des Datenpfads im Lagebericht.

Eine Beweiskette über den Transcript hinaus

Am Anfang stehen die Richtlinien beider Endpunkte: verpflichtend, bevorzugt oder optional; Fallback erlaubt oder untersagt. Danach folgen Implementierungsversion, unterstützte Verfahren, geordnetes Angebot, Auswahl, öffentliche Werte und MAC-Prüfung.

Ein nicht geheimer Ableitungsbeleg weist nach, dass der ECDHE-Beitrag die vorgesehene Hierarchie erreicht hat. Nicht geheime Kennungen verbinden K_re, MSK und EMSK mit konkreten Verbrauchern. Jeder Legacy-Pfad wird ausdrücklich markiert.

Anschließend werden die Endereignisse aller beteiligten Systeme und ein Inventar möglicher Schlüsselverwahrer erfasst. Jeder Verwahrer quittiert Ablauf, Nullsetzung oder kryptographische Ungültigkeit. Dumps, Snapshots und Aufbewahrungspflichten erscheinen als Ausnahmen im Ergebnis.

Zum Schluss versucht ein autorisierter Test, mit dem alten Transcript und dem später offengelegten Langzeitmaterial die ausgemusterten Sitzungsschlüssel zu rekonstruieren. Ein Fehlschlag in klar benanntem Umfang ist näher an der versprochenen Eigenschaft als eine Konfigurationsmarkierung. Er beweist nicht die Abwesenheit unbekannter Kopien, testet aber die behauptete Verwahrkette.

Mindeststandard und laufender Code

RFC 9678 liefert einen minimalen gemeinsamen Standard: Attribute, Algorithmen, Aushandlung und Ableitung. Er liefert keine Einsatzquote und keine Fernattestation des Speichers. Veröffentlichung ist nicht Implementierung, Implementierung nicht Auswahl, Auswahl nicht Nutzung und Nutzung nicht Vernichtung.

Mit Heng Lus Trennung der Realitätsebenen gehört der IANA-Codepunkt zur Koordination, der authentisierte Transcript zur Protokollebene, der Schlüssel im RAM zum laufenden Code, die Access-Assoziation zum Betrieb und der Wiederherstellungsversuch zur Evidenz. Das Etikett „Forward Secrecy aktiv“ ist nur dann belastbar, wenn es diese Ebenen nicht verschmilzt.

Die Grenze ist kein Mangel des RFC. Kein Netzwerkprotokoll kann zuverlässig attestieren, dass jede lokale und nachgelagerte Kopie verschwunden ist. Der Standard verbessert die kryptographische Ursache. Die Organisation muss die betriebliche Folge beweisen.

Quellen