Zusammenfassung

  • Die FRID ist eine vom Server erzeugte pseudonyme NAI, mit der ein bestehender EAP-IKEv2-Kontext gesucht wird. Ein Treffer belegt nicht, dass der vorlegende Peer die Kontextschlüssel besitzt.
  • Erst die mit dem alten Kontext geschützten Nachrichten 3 und 4, neue SPIs, frische Nonces und eine erfolgreiche neue Schlüsselableitung erlauben EAP-Success und frische MSK/EMSK. Autorisierung, Installation und Dienst folgen später.

Ein Trace enthält dieselbe FRID wie gestern und denselben Responder-SPI im EAP-IKEv2-Header. Trotzdem muss der neue Lauf neue Proposal-SPIs und neue Nonces liefern. Die Wiederverwendung des alten Kontexts und die Erzeugung einer neuen Sitzung sind gleichzeitig wahr.

RFC 5106 beschreibt EAP-IKEv2 als Experimental EAP-Methode. Im vollständigen Lauf ist der EAP-Server IKEv2-Initiator, der Peer Responder. Beide handeln Algorithmen aus, tauschen Diffie-Hellman-Werte und Nonces und prüfen die AUTH-Werte in geschützten Payloads. Erst der erfolgreiche Abschluss erlaubt MSK und EMSK.

Der Server kann dabei eine Next Fast-ID ausgeben. Die darin enthaltene Fast-Reconnect-ID folgt dem NAI-Format. Der Benutzerteil ist ein serverseitig erzeugtes Pseudonym; der Realm bleibt für AAA-Routing erhalten. Die Zuordnung zum permanenten Identifikator und zum Sicherheitskontext liegt beim Server.

Die FRID benennt somit keinen neuen kryptografischen Principal. Sie ist eine Referenz auf Zustand. Ein frischer Zufallsanteil und Eindeutigkeit im Serververbund verhindern Kollisionen und erschweren Korrelation, ersetzen aber keinen Nachweis mit den alten Schlüsseln.

Auch die Serverwahl ist nicht garantiert. Der nächste Versuch kann einen anderen Home-Server erreichen. Ein zentraler Mapping-Dienst wird empfohlen; fehlt er, darf ein Server die permanente Identität anfordern. Ein unbekanntes Pseudonym kann daher Replikations-, Routing- oder Eviction-Ursachen haben.

Der Peer darf Fast Reconnect nur anstoßen, wenn der letzte erfolgreiche Lauf eine FRID geliefert hat. Die EAP-Identity-Response bleibt erforderlich. Nach dem Lookup entscheidet lokale Policy, ob der Server den schnellen oder den vollständigen Ablauf verwendet. Der Peer muss auf einen vollständigen Message 3 vorbereitet sein.

Schon diese Phase besitzt getrennte Zustände: FRID vorgelegt, Kontext gefunden, Policy gewählt. Keine dieser Beobachtungen ist der Beweis, dass der Absender auf den gefundenen Kontext zugreifen kann.

Der schnelle Lauf verwendet eine CREATE_CHILD_SA-ähnliche Nachrichtenfolge. Message 3 ist mit den Schlüsseln des vorherigen erfolgreichen Kontexts verschlüsselt und integritätsgeschützt. Der Server muss in jeder Proposal-Substructure einen neuen, von null verschiedenen SPI wählen. Ni muss frisch sein. Ein optionaler KEi-Wert muss ebenfalls frisch sein und zur Gruppe des früheren vollständigen Laufs gehören.

Der Peer entschlüsselt und verifiziert Message 3. Danach wählt er einen eigenen neuen Proposal-SPI, erzeugt Nr und optional KEr und schützt Message 4. Der Server entschlüsselt und verifiziert diese Antwort. Nur eine korrekte Message 4 macht den Lauf erfolgreich und erlaubt EAP-Success.

Damit kann das Datenbank-Lookup vollständig richtig und die Authentisierung trotzdem falsch sein. Der gespeicherte Kontext kann einer anderen Generation angehören, die Integritätsprüfung kann scheitern oder ein Nonce kann gegen die Freshness-Regel verstoßen. Das Lookup wählt Prüfmaterial; es ersetzt die Prüfung nicht.

Nach Erfolg wird SKEYSEED aus altem SK_d, Ni, Nr und gegebenenfalls neuem Diffie-Hellman-Geheimnis gebildet. Die EAP-IKEv2-Schlüssel werden neu erzeugt. KEYMAT liefert anschließend 64 Oktette MSK und 64 Oktette EMSK. Vor erfolgreichem Abschluss dürfen diese Exporte nicht entstehen.

Session-ID enthält Methodentyp sowie das neue Ni und Nr. Peer-ID und Server-ID werden dagegen aus dem ursprünglichen vollständigen Lauf übernommen. FRID, Principal-Identitäten und Sitzungskennung beantworten verschiedene Fragen: welcher Kontext, welche Parteien, welcher Lauf.

Der Freshness-Nachweis braucht deshalb mehr als einen Zeitstempel. Ein Audit speichert Kontextgeneration, beide Proposal-SPIs, Nonce-Digests, optional die DH-Gruppe, Message-3/4-Verifikation und die daraus entstandene Session-ID. Ein generisches Feld reconnected=true kann keine Wiederverwendung erkennen.

Replay-Schutz folgt ebenfalls der Schlüsselgeneration. Nach einem erfolgreichen Reconnect sollen alte Message-3-Pakete scheitern, weil die Prüfschlüssel rotiert wurden. Vor der erfolgreichen Transition kann eine Wiederholung auch Retransmission sein. FRID-Häufigkeit allein unterscheidet diese Fälle nicht.

Die FRID-Rotation besitzt eine eigene Bestätigungsgrenze. Der Peer kann einen neuen NFID empfangen, aber vor dauerhafter Speicherung ausfallen. Der Server sollte daher den zuletzt verwendeten und den zuletzt ausgegebenen FRID halten. Scheitert die Authentisierung, darf der FRID des letzten erfolgreichen Laufs nicht überschrieben werden.

Das ist eine Commit-Regel. „Ausgegeben“ bedeutet nicht „beiderseits gespeichert“. Wer ausschließlich den neuesten Wert behält, kann durch einen verlorenen Abschluss den letzten funktionsfähigen Wiederanlaufpfad zerstören.

EAP-Success belegt den Methodenabschluss. RFC 5247 ordnet den Schlüsselexport in eine größere Architektur ein. AAA-Policy, Schlüsseltransport zum Authenticator, Installation im Lower Layer, erster geschützter Verkehr und nutzbarer Dienst benötigen eigene Belege.

RFC 5106 unterstützt kein Channel Binding. Ein erfolgreicher kryptografischer Lauf beweist daher nicht alle Eigenschaften des darunterliegenden Zugangsnetzes. Die Anzeige „am richtigen Netz verbunden“ wäre eine zusätzliche Behauptung, keine direkte Folge von EAP-Success.

Auch das historische Algorithmenprofil ist kein heutiger Freibrief. Die Interoperabilitätsbasis von 2008 nennt MODP 1024, 3DES und SHA-1-basierte Verfahren. Historische Konformität und aktuelle kryptografische Zulässigkeit müssen mit Suite und Policy-Version getrennt dokumentiert werden.

Ein brauchbares Ereignismodell erfasst FRID-Digest, Realm, ausgebenden und empfangenden Server, Mapping-Ergebnis, Kontextgeneration, Fast/Full-Entscheidung, SPIs, Nonce-Digests, DH-Gruppe, beide Nachrichtenprüfungen, Session-ID, EAP-Ergebnis und Key Handles. Rohschlüssel gehören nicht in Telemetrie.

Danach werden AAA-Entscheidung, Installationsreceipt, erstes geschütztes Paket und Serviceprobe verknüpft. So lautet der Alarm nicht „Reconnect kaputt“, sondern etwa nonce_reuse, context_generation_mismatch, message4_integrity_failed, success_without_key_export oder installed_without_traffic.

Fast Reconnect spart einen vollständigen Authentisierungslauf, weil er auf einem zuvor authentisierten Kontext aufbaut. Er spart nicht die Freshness-Anforderungen und nicht den Beweis, dass beide Seiten diesen Kontext noch gemeinsam kontrollieren.

Kontextablauf braucht einen Grundcode. not_found kann fehlende Replikation, Memory Eviction, Policy Expiry oder bewussten Widerruf verdecken. Diese Ursachen verlangen andere Reaktionen. Der Server sollte deshalb Tombstone, letzte erfolgreiche Generation und Ablaufentscheidung erhalten, ohne den alten Schlüssel weiter nutzbar zu machen.

Ein leerer Kontext darf nicht unter einer noch bekannten FRID rekonstruiert werden. Ohne alte Schlüssel und Authentisierungsgeschichte wäre nur der Datenbankschlüssel gleich. Der sichere Recovery-Pfad ist ein vollständiger Lauf, der nach aktueller Credential- und Kryptopolicy einen neuen Kontext erzeugt.

Performance wird entlang der Übergänge gemessen: Identity bis Lookup, Lookup bis Message 3, Message 3 bis Message 4 und Message 4 bis Success. Eine schnellere Cache-Abfrage kann den ersten Wert verbessern und gleichzeitig mehr Generation-Mismatches produzieren. Das Ziel ist eine schneller belegte Sitzung, nicht ein schneller Treffer.

Retransmission und Replay benötigen eine Attempt-Kennung. Dieselbe FRID kann bei Paketverlust innerhalb eines Laufs wiederkehren oder später gegen eine neue Generation eingesetzt werden. Kontextgeneration, SPI, Ni und Nachrichtenhash trennen die Fälle. Ein FRID-basierter Zähler allein ist sowohl für Security als auch Zuverlässigkeit zu grob.

Quellen