Zusammenfassung

  • RFC 5296 verkürzt die EAP-Reauthentisierung, doch das Fortschreiben des Replay-Zustands, die Antwort an den Peer, der AAA-Schlüsseltransport und die TSK-Einrichtung bleiben getrennte Commits.
  • Eine belastbare Kette ordnet jedes rMSK genau einem Authentikator und einer Generation zu und führt bis zur Installation und Zugangsentscheidung.

Der schnelle Pfad hat mehrere Enden

ERP erspart beim Wechsel des Authentikators einen vollständigen EAP-Methodenlauf. Initiate geht über den Authentikator zum ER-Server, Finish kommt in einer Runde zurück. Der Authentikator reicht die ERP-Nachrichten durch, während AAA das abgeleitete rMSK transportiert.

Der Peer leitet dasselbe rMSK ab. Erst danach kann das Protokoll der unteren Schicht TSKs etablieren und Zugang durchsetzen. Eine geringe Rundlaufzeit sagt nichts darüber, ob diese Kette vollständig war.

Die Annahme verändert den Replay-Zustand

Initiate führt 16-Bit-SEQ, genau ein keyName-NAI, Kryptosuite und Authentisierungstag. Bei neuer rRK beginnt SEQ bei null. Der Server prüft Erwartungswert oder ein unbenutztes Fenster, Suite und Integrität.

Bei Erfolg leitet er rMSK aus rRK und SEQ ab. Finish wiederholt SEQ; der Server erhöht den Erwartungswert oder aktualisiert das Fenster. Verlorene Antwort oder verlorener AAA-Transport setzen diesen Zustand nicht zwingend zurück.

Der Beleg braucht Vorzustand, Fenster, Used-Set, Entscheidung, Zeit und Nachzustand. Das Eingangspaket ist kein Datenbank-Commit-Beweis.

Identifier kennzeichnet die ausstehende Runde

Eine Wiederholung behält den EAP Identifier, eine neue Initiate-Nachricht verwendet einen anderen. Finish muss zum Identifier der offenen Anfrage passen.

Identifier korreliert Transport; SEQ schützt gegen Replay und geht in rMSK ein. Ein allgemeiner Request-Schlüssel kann die Wiederholung als neue Autorisierung zählen. Das empfohlene Löschen des Authentikatorzustands nach 300 Sekunden synchronisiert nicht automatisch Peer und Server.

Ein authentisches Finish ist kein AAA-Ack

Der Peer prüft die erwartete SEQ und Integrität und berechnet rMSK. Danach ist die Lower-Layer-SA bereit, gestartet zu werden.

Finish beweist eine Antwort eines rIK-Inhabers, nicht die Zustellung oder Installation beim Authentikator. Auch Generation, TSK-Erfolg und Paketfreigabe bleiben offen. Finish-Erzeugung, Prüfung, AAA-Send/Receive, Installation, SA-Start, SA-Ende und Access-Verdict erhalten eigene Ereignisse.

Ein rMSK gehört zu einem Authentikator

rMSK entsteht aus rRK, Label, SEQ und Länge. Es darf nicht von mehreren Authentikatoren geteilt werden und lebt höchstens so lange wie rRK. Nach neuer rRK stammen künftige rMSKs daraus; bereits gelieferte alte können bis zum Ablauf weiterlaufen.

Rotation ist daher kein gemeinsamer Umschaltpunkt. Jeder Authentikator braucht einen Lebenslauf für Empfang, Installation, Auswahl und Retirement.

Beim Bootstrap kann die untere Schicht ein erhaltenes rMSK ignorieren, wenn frühere TSKs aus einem MSK gelten, oder neue TSKs aufbauen. Empfang und Nutzung sind verschieden.

Parallelität macht aus dem nächsten Wert ein Fenster

Mehrere gleichzeitige ERP-Läufe über verschiedene Authentikatoren können ungeordnet eintreffen. Ein Server darf unbenutzte SEQ-Werte in einem lokal gepflegten Fenster akzeptieren.

Zur Rekonstruktion gehören Grenzen, Fenstergeneration, Verbrauchsmenge, Durchgangs-Authentikator und Policy-Version. Eine Fensteränderung erweitert Annahmebefugnis ohne Schlüsseländerung.

Nicht prüfbare Fehler bleiben mehrdeutig

Der Server sendet bei Fehler ein Failure-Finish und schützt es mit gültiger rIK. Bei abgelehnter Suite kann er Alternativen anbieten; ein PRF-Wechsel verlangt neue Ableitungen.

Scheitert Replay- oder Integritätsprüfung, kann ein Angreifer die Nachricht erzeugt haben oder es fehlt eine gemeinsame Suite. Der Peer weiß es nicht und retransmittiert weiter. Monitoring darf daraus keine sichere Angreiferzuordnung machen.

Aktueller Root-Besitz qualifiziert nur für den nächsten Schritt

RFC 6696 ersetzte RFC 5296 rückwärtskompatibel und verlangt beim impliziten Bootstrap die Prüfung aktuell gültigen Root-Materials. Ein gefundener alter Kontext genügt nicht.

Aktueller Besitz berechtigt zur Antwort, beweist aber keine Installation. Die Root-Generation muss mit SEQ, rMSK, Ziel und Lower-Layer-Ergebnis verbunden bleiben.

Der vollständige Beleg

rRK-Generation und Ablauf; keyName-NAI und Domäne; Identifier; SEQ und Fenster; Suite und Integrität; Annahme und Zählerübergang; rMSK und exklusiver Authentikator; Finish; AAA-Transaktion; Empfang und Installation; Peer-Ableitung; ausgewählter MSK/rMSK; TSK; Zugang; Full-EAP-Fallback; Retransmissions- und Channel-Binding-Verdikt gehören zusammen. Geheimwerte bleiben draußen.

Sources