Zusammenfassung

  • Ein Peer kann noch nicht abgelaufenes EAP-Schlüsselmaterial halten, während ein Neustart oder Speicherdruck den passenden Eintrag im Authenticator bereits gelöscht hat.
  • RFC 5247 verlangt für die Wiederverwendung einen geschützten Abgleich. Fehlt ein gemeinsamer Schlüssel für diesen Abgleich, muss neue Authentisierung die Autorität wiederherstellen.

Der Timer maß nur die halbe Wirklichkeit

Ein Endgerät kehrt aus dem Ruhezustand zurück. Sein Cache meldet: Schlüssel vorhanden, Restlaufzeit zwölf Minuten. Es startet die kurze Wiederaufnahme. Der Authenticator findet unter demselben Namen nichts. Ein Prozessneustart hat seine flüchtige Tabelle geleert.

Aus Sicht des Endgeräts ist der Schlüssel nicht abgelaufen. Aus Sicht des Authenticators existiert er nicht. Beide Aussagen können gleichzeitig richtig sein. Erst die zusammengezogene Anzeige „Schlüssel gültig“ ist falsch, weil sie einer lokalen Uhr Wissen über einen fremden Speicher zuschreibt.

RFC 5247 beschreibt genau diesen Fall. Peer oder Authenticator können neu starten oder Ressourcen zurückgewinnen und dabei Teile oder den gesamten Schlüsselcache löschen. Eine ausgehandelte Laufzeit garantiert daher keine fortgesetzte Synchronität. Der Peer kann den Verlust auf der Gegenseite womöglich erst beim Verwendungsversuch erkennen.

Eine Frist ist keine Aufbewahrungsgarantie und schon gar kein Mandat über fremden Arbeitsspeicher.

Drei Ebenen dürfen nicht zu einem Status schrumpfen

Das EAP-Schlüsselmanagement verbindet mehrere Vorgänge. Zwischen Peer und EAP-Server läuft eine Methode, die MSK, EMSK und Identifikatoren liefern kann. AAA transportiert Material und Autorisierungsparameter zum Authenticator. Anschließend handelt ein Secure Association Protocol direkt zwischen Peer und Authenticator den Kontext aus, beweist Besitz und erzeugt transiente Sitzungsschlüssel.

Caching spart einen Teil dieser Arbeit. Es ersetzt jedoch nicht die aktuelle Behauptung, dass beide laufenden Endpunkte denselben benannten Zustand besitzen. Noch weniger ersetzt es die Erzeugung frischer Verkehrsschlüssel, deren Aktivierung oder die Durchsetzung des Zugriffs.

Der lokale Cache-Hit belegt eine gespeicherte Vergangenheit. Erst der geschützte Austausch belegt eine gemeinsame Gegenwart.

Mehrere richtige Schlüssel können trotzdem scheitern

Zwischen denselben Parteien kann mehr als ein Schlüssel gleichen Typs liegen. Deshalb muss das Secure Association Protocol laut RFC den für den Besitznachweis verwendeten Schlüssel ausdrücklich benennen. Sonst könnten beide Seiten einen vorhandenen, aber jeweils anderen Datensatz auswählen.

Der Name koordiniert die Auswahl; er ist selbst kein Besitznachweis. Die Parteien müssen anschließend zeigen, dass sie das zugehörige Material besitzen. Bei Cache-Unterstützung müssen zudem frische unicast und gegebenenfalls multicast TSKs entstehen. Nonces oder Zähler verhindern, dass aus altem EAP-Material schlicht dieselben Verkehrsschlüssel wiederkehren.

Eine belastbare Spur nennt daher Auswahl, Treffer auf beiden Seiten, gemeinsamen Nachweis, Frischebeiträge, Ableitung, Aktivierung, geschütztes Paket und Dienstreaktion. Das Wort „Treffer“ allein lässt fast alle entscheidenden Übergänge offen.

Wiederherstellung ist selbst eine privilegierte Änderung

Wenn nur eine Seite den Zustand verloren hat, liegt Kopieren nahe. Doch das Installieren eines kryptografischen Kontexts verändert eine Sicherheitsgrenze. Der Reparaturbefehl braucht eine Autorität, die noch existiert.

RFC 5247 empfiehlt die Neusynchronisierung über das Secure Association Protocol oder eine Anzeige der unteren Schicht. Besitzen beide Seiten noch einen geeigneten gemeinsamen Schlüssel, kann dieser den Abgleich schützen. Fehlt dieser gemeinsame Anker, ist sichere Neusynchronisierung auf Grundlage des verlorenen Zustands nicht möglich.

Eine ungeschützte Behauptung „ich hatte K“ darf K nicht wieder einsetzen. Dann muss EAP neu beginnen, etwa nach Ablauf eines Timers. Die längere Strecke kann Identität und Richtlinie erneut prüfen, neues Material erzeugen und eine neue Assoziation schaffen.

Das kostet Zeit, bewahrt aber die Beweisrichtung: Autorität erzeugt Zustand; der Wunsch nach Zustand erzeugt keine Autorität.

Gleiche Bytes bedeuten nicht gleichen Geltungsbereich

Die Caches können auch über den zulässigen Einsatz auseinanderliegen. RFC 5247 empfiehlt eine Synchronisierung des Schlüsselumfangs, damit jede Seite den Cache-Bereich der anderen bestimmen und Nutzungsbeschränkungen aushandeln kann.

Ein Kontext für einen Authenticator, Port, Dienst oder ein Verkehrsprofil wird durch verbleibende Laufzeit nicht auf andere Flächen ausgedehnt. Bei einem Wechsel kann AAA zudem einen anderen EAP-Server wählen. Server derselben Realm können dieselben Zugangsdaten prüfen und dennoch nicht denselben persistenten Zustand teilen.

Ein Fehlschlag der Wiederaufnahme kann somit Verlust, falsche Auswahl, Bereichskonflikt, Backend-Wechsel oder neue Richtlinie bedeuten. Ohne zusätzliche Beobachtung ist er weder Passworturteil noch Angriffsnachweis.

Der erste fehlende Beleg zählt

Ein Supportsystem mit nur „Erfolg“ und „Authentisierung fehlgeschlagen“ zerstört die nützlichste Information. Bei einem Cache-Verlust hilft kein Passwortwechsel. Bei einem Bereichskonflikt hilft kein größerer Cache. Bei falscher Backend-Auswahl hilft keine Sperre des Nutzers.

Erfasst werden sollte die früheste offene Grenze: Schlüsselname unbekannt, Kontext nicht vorhanden, Besitznachweis gescheitert, frische TSK nicht abgeleitet, Aktivierung nicht bestätigt, Zugriffspolitik abgelehnt oder geschützter Verkehr ohne nutzbaren Dienst.

Ist die Ursache nicht beobachtet, bleibt sie unbekannt. Die RFC liefert ein Architekturmodell, aber keinen Beweis über einen bestimmten Hersteller, eine Installation oder einen Vorfall.

Asymmetrisches Löschen gehört in den Testplan

Wer immer beide Seiten gemeinsam leert, prüft gerade nicht die gefährliche Bedingung. Vier Fälle sind nötig: beide behalten den Eintrag; nur der Peer behält ihn; nur der Authenticator behält ihn; beide verlieren ihn. Jeder Fall braucht begrenzte Wiederholungen, einen sichtbaren Übergang zur Vollauthentisierung und den Nachweis, dass alte TSKs nicht still wieder aktiviert werden.

Danach folgt der Lasttest. Ein Cache senkt die normale Authentisierungslast. Löschen viele Authenticatoren gleichzeitig ihren Zustand, wandert die gesamte Population zum teuren Pfad. Eine Plattform, die nur für die übliche Trefferquote dimensioniert ist, kann beim Wiederaufbau zusammenbrechen.

Die relevante Kapazität lautet deshalb: sichere Misses pro Sekunde bis zur vollständigen Wiederherstellung—nicht nur Einträge pro Cache.

Sources