Zusammenfassung

  • Akzeptiert ein Server die Wiederaufnahme einer TEAP-Sitzung, wird Phase 2 nach RFC 9930 vollständig umgangen. Das Ticket muss daher weiterhin mit abgeschlossener innerer Authentisierung und dem heute maßgeblichen Berechtigungszustand verbunden sein.
  • Lassen sich neue Zugangsdaten nicht dem Ticket zuordnen, muss der Server es ungültig machen und bei der nächsten Verbindung eine vollständige Neuauthentisierung erzwingen.

Wiederaufnahme ist kein bloßer Komfort. Wo Nutzer und Geräte sich mehrmals täglich neu verbinden, belastet jede vollständige Ausführung der inneren Methoden das Identitätssystem. RFC 9930 verlangt deshalb, dass jede TEAP-Implementierung Wiederaufnahme unterstützt, und nennt Skalierbarkeit und Stabilität als Nutzen. Unterstützen heißt jedoch nicht, jedes vorgelegte Ticket anzunehmen.

TEAP verteilt eine vollständige Authentisierung auf zwei Phasen. Phase 1 baut mit TLS einen geschützten und authentisierten Tunnel auf. In Phase 2 laufen innere Methoden und TLVs: Maschine, Nutzer oder beide können authentisiert, Zugangsdaten ausgestellt oder geändert, Crypto-Binding ausgeführt und geschützte Ergebnisse ausgetauscht werden. RFC 6678 formuliert die Anforderungen an ein standardisiertes getunneltes EAP-Verfahren; RFC 3748 liefert Rollen und Ergebnislogik von EAP. Ein bestehender Tunnel belegt nicht den Abschluss seiner inneren Prüfung.

Genau dort spart die Wiederaufnahme. Stimmt der Server zu, wird Phase 2 laut RFC 9930 vollständig übersprungen. Lehnt er ab, folgt auf einen vollständigen TLS-Handshake zwingend Phase 2. Der Zustand kann serverseitig liegen oder mit einem clientseitigen Ticket nach dem Muster von RFC 5077 transportiert werden. In TLS 1.3 schafft NewSessionTicket aus RFC 8446 PSK-bezogenen Zustand für eine spätere Verbindung. Daraus folgt keine automatische Fortgeltung jeder Zugangsentscheidung.

Ein Ticket kann sogar vor der inneren Authentisierung entstehen. RFC 9427 weist darauf hin, dass TLS 1.3 NewSessionTicket nach dem Finished des Clients senden darf, obwohl das innere Verfahren noch nicht gelaufen ist. Ein Client könnte das Ticket erhalten, abbrechen und anschließend eine Wiederaufnahme ohne abgeschlossene innere Prüfung versuchen. Der Server darf Wiederaufnahme daher nur zulassen, wenn die innere Authentisierung erfolgreich abgeschlossen wurde. Am besten verzögert er die Ticketvergabe; andernfalls muss er Tickets fehlgeschlagener Sitzungen verwerfen oder entwerten. Ist der Abschlussstatus nicht erkennbar, gilt die innere Authentisierung als nicht erfolgt und muss vor Zugang nachgeholt werden.

Auch Crypto-Binding ist keine Autorisierungsentscheidung. Nach einer erfolgreichen inneren Methode verlangt RFC 9930 Intermediate-Result und Crypto-Binding. Der Compound MAC verbindet Beteiligte, Tunnel und Authentisierungsfolge und kann Austausch- oder Bindungsfehler offenlegen. Er wählt weder VLAN noch ACL, Rolle, Kontostatus oder Dienstumfang. Selbst bei einem erfolgreichen Result TLV kann der Peer weitere Schritte verlangen, wenn seine Richtlinie nicht erfüllt ist; der Server reagiert nach lokaler Policy.

Das Zeitproblem bleibt nach einer einwandfreien Erstsitzung bestehen. Phase 2 kann Zugangsdaten bereitstellen oder ändern. Spätere Autorisierung muss deshalb auf den authentisierten Zugangsdaten beruhen, nicht auf einer anonymen oder abweichenden Identität aus Phase 1. Bei Wiederaufnahme müssen neue Zugangsdaten dem Sitzungsticket zugeordnet sein. Ist das nicht möglich, muss der Server die Tickets der aktuellen Sitzung ungültig machen. Die nächste Verbindung durchläuft dann die vollständige Authentisierung, sodass ein neues Ticket wieder eine nachvollziehbare Autorisierungsgrundlage erhält.

RFC 9190 erfasst weitere Veränderungen zwischen ursprünglichem Handshake und Wiederaufnahme: Informationen über Peer, Authenticator oder umgebende Protokollschichten. Können sie Autorisierung, Accounting oder Policy beeinflussen, muss die Entscheidung neu bewertet werden. Ist keine sichere Entscheidung möglich, soll der Server die Wiederaufnahme ablehnen und einen vollständigen Handshake fortsetzen. Die Sieben-Tage-Obergrenze eines TLS-1.3-Tickets ist keine siebentägige Zugangsberechtigung.

Der Betriebsnachweis muss die Kette rekonstruieren: Hash von Ticket oder Session ID, Aussteller, Ausgabe und Ablauf, ursprüngliche Vollsitzung, Abschluss der inneren Authentisierung, Versionen von Zugangsdaten und Policy, Authenticator-Kontext, zwischenzeitliche Änderungen, Neubewertung sowie Grund für Annahme, Ablehnung oder Entwertung. Davon getrennt folgen die aktuelle Autorisierung, die Umsetzungsquittung des NAS und beobachteter Verkehr oder Dienstzustand. RFC 5247 ordnet EAP-Schlüssel und Identitäten ein, beweist aber keine dieser Folgewirkungen.

Heng Lus Prinzip der minimalen Anfangsspezifikation setzt die passende Grenze: Das gemeinsame Ticket trägt nur den begrenzten Zustand, der Interoperabilität ermöglicht. Die spätere Entscheidung bleibt lokal und zurechenbar. Laufender Code muss zeigen, was tatsächlich geprüft wurde; Ticket, authentisierte Zugangsdaten, aktuelle Policy, Autorisierung, Umsetzung und Ergebnis bleiben eigene Realitätsebenen. Vertrauenswürdig ist die Abkürzung erst, wenn sich erklären lässt, was ausgelassen wurde und warum.

Sources