Zusammenfassung

  • Zertifikatspfad, CertificateVerify und Finished belegen genau definierte kryptografische Tatsachen. Sie legen kein VLAN an, installieren keine ACL und öffnen keinen kontrollierten Port.
  • Die EAP-Architektur trennt erfolgreiche Authentisierung von späterer Autorisierung und von der Fähigkeit des Authenticators, einen bewilligten Dienst tatsächlich bereitzustellen.
  • Ein belastbarer Nachweis verbindet PKI, EAP, AAA, Schlüsseltransport, lokale NAS-Ausführung und beobachteten Verkehr, ohne einen früheren Beleg zum Stellvertreter aller späteren zu machen.

Zwei grüne Anzeigen, kein einziges Paket

In einem konstruierten Ablauf prüft der Client um 08:14:02 Uhr Zertifikatskette und Namen des EAP-Servers; der Server prüft das Clientzertifikat. CertificateVerify zeigt den Besitz der privaten Schlüssel. Finished zeigt den gemeinsamen geschützten Handshake-Zustand. Die PKI-Anzeige wird grün.

Um 08:14:03 Uhr verbindet das Backend die authentisierte Identität mit NAS, Port und gewünschtem Dienst. Es gibt eine bedingte Rolle und ein bestimmtes VLAN zurück. Auch die Policy-Anzeige wird grün.

Um 08:14:04 Uhr stellt der Switch fest, dass dieses VLAN im benötigten Forwarding-Kontext fehlt. Er kann die Autorisierung nicht umsetzen und hält den kontrollierten Port geschlossen. Weder DHCP noch IPv6-Konfiguration noch Anwendungsverkehr beginnen.

Die Szene schreibt keinem Betreiber oder Produkt einen Fehler zu. Sie verdichtet Grenzen aus RFC 5216, RFC 3748 und RFC 3579. Die Teilereignisse sind wahr. Nur die zusammenfassende Aussage „Netzzugang erfolgreich“ überschreitet ihre Aussagekraft.

Was der Handshake wirklich bestätigt

RFC 5216 verwendet TLS für zertifikatsbasierte gegenseitige Authentisierung, integritätsgeschützte Aushandlung, Schlüsselaustausch und EAP-Schlüsselableitung. Die Pfadprüfung beantwortet, ob ein Zertifikat unter der lokalen Vertrauenspolitik zu einem akzeptierten Anker führt. CertificateVerify beantwortet den Besitz der privaten Schlüssel. Finished bindet beide Seiten an denselben Transcript und Schlüsselzustand.

Keiner dieser Belege enthält den Zustand des Switchports, die Verfügbarkeit eines VLANs, das Ergebnis einer Filterinstallation oder die Gesundheit einer Anwendung. Zertifikatsfelder können authentisierte Eingaben für eine Policy liefern; sie führen diese Policy nicht aus.

Der heutige Vertrag umfasst Aktualisierungen. RFC 8996 verwirft TLS 1.0 und 1.1. RFC 9190 definiert EAP-TLS mit TLS 1.3 und ändert Ablauf sowie Schlüsselhierarchie. RFC 9965 ergänzt eap.arpa. Normativer Status ist weder Implementierungsnachweis noch Betriebsstatistik.

Die Authorization-Sektion von RFC 9190 gilt für EAP-TLS allgemein. Das äußere EAP-Response/Identity ist nicht durch EAP-TLS authentisiert. Autorisierung und Accounting müssen sich auf authentisierte Informationen aus Zertifikat, PSK-Identität oder Resumption-Zustand stützen. NAS, MAC, IP, Port und SSID dürfen als weitere Kontexteingaben dienen.

Damit ist die Rollenverteilung klar: Authentisierung liefert verlässliche Fakten; Autorisierung bewertet sie im aktuellen Kontext.

EAP-Success ist kein synchroner Weltzustand

RFC 3748 erklärt, dass ein synchrones Authentisierungsergebnis keine synchrone Autorisierung garantiert. Ein AAA-Proxy kann entscheiden, ohne dass der EAP-Server es sieht. Ein AAA-Server kann erst nach erfolgreicher Authentisierung feststellen, dass keine Berechtigung besteht. Oder das Backend bewilligt, während der Authenticator den Dienst wegen fehlender Ressourcen nicht liefern kann.

Diese Fälle trennen Entscheider, Erlaubnis und Fähigkeit. Ein einziger Success-Zähler löscht genau jene Information, die den Fehler lokalisiert.

RFC 4137 beschreibt EAP-Zustandsmaschinen und ihre Signale an die untere Schicht. eapSuccess ist das Ergebnis dieser Maschine. Es liest weder VLAN-Tabelle noch Adresspool noch Applikationspfad.

Schlüsselbesitz ist keine Amtsurkunde

RFC 5247 trennt die Ableitung von MSK/EMSK, den AAA-Transport zum Authenticator und das Secure-Association-Protokoll. So bleibt sichtbar, wer welche Aussage treffen kann.

Der Rahmen sagt ausdrücklich: Der Nachweis des Besitzes von Schlüsselmaterial beweist nicht notwendigerweise die Berechtigung, dieses Material zu besitzen. Eine lokale Handshake-Prüfung kann denselben Schlüssel auf Peer und NAS zeigen, ohne nachzuweisen, dass das Backend gerade diesem NAS die Nutzung gestattete.

RFC 4962 fordert Peer- und Authenticator-Autorisierung. RFC 4017 behandelt gegenseitige Authentisierung, Schlüsselstärke und Autorisierung getrennt. RFC 5295 bindet EMSK-Ableitungen an Nutzung und Domäne. Geheime Bytes tragen keine unbegrenzte institutionelle Vollmacht.

Ein Accept kann lokal unerfüllbar sein

In einer RADIUS-Architektur leitet der NAS EAP häufig nur weiter. RFC 3579 definiert Access-Accept und Access-Reject als eigene Ergebnisse. Reject verlangt Ablehnung; Accept beendet die Phase und kann Rolle, VLAN, Filter und Lebensdauer enthalten.

Kann der NAS den angeforderten Dienst nicht anbieten, muss er den entsprechenden Accept wie einen Reject behandeln. RFC 3580 warnt außerdem vor Widersprüchen zwischen RADIUS-Pakettyp und gekapseltem EAP Success oder Failure. Die Zugriffskontrolle folgt der RADIUS-Entscheidung, nicht einem isolierten Wort.

Das Backend belegt seine Anweisung. Der NAS muss belegen, dass er Attribute verstand, Rolle oder VLAN auflöste, ACLs installierte, die sichere Assoziation abschloss und den Port öffnete. Danach bleiben Adresse, Nachbarschaft, DNS, Route und Anwendung.

Netzkontext besitzt eigene Quellen

RFC 6677 adressiert den „lying NAS“, der Peer und AAA unterschiedliche Netzwerkgeschichten erzählt. Channel Binding vergleicht die Wahrnehmungen über einen geschützten Kanal.

Das Verfahren ist nötig, weil ein Peer-Zertifikat SSID, Port, Roaming-Anbieter oder Diensteigenschaft nicht automatisch authentisiert. Auch ein gültiges Channel-Binding-Ergebnis beweist nur den definierten Kontext, nicht die spätere Paketlieferung.

RFC 7542 regelt NAI; RFC 9427 passt TLS-basierte EAP-Typen an TLS 1.3 an. Beide stärken die Verknüpfung der Nachweise, nicht deren Überspringen.

Resumption konserviert keine gesamte Berechtigung

RFC 9190 behandelt akzeptierte TLS-1.3-Resumption als authentisiert und sicher mit einer früheren Sitzung verbunden. Zugleich darf die fortgesetzte Sitzung nicht mehr Privileg erhalten als ursprünglich vorgesehen.

Während ein Ticket kryptografisch gültig bleibt, können Zertifikat, Rolle, NAS-Kontext, SSID-Policy und VLAN wechseln. Zertifikatsgültigkeit, Sperrstatus, Ticket, Autorisierung, Port und Dienst laufen auf verschiedenen Uhren.

OCSP-Stapling hilft bei der Sperrprüfung, bevor der Peer allgemeinen Netzzugang besitzt. Dieser Bootstrap ist kein Nachweis für das danach gelieferte Netz.

Die Belegkette

Der PKI-Beleg enthält Anker, Ketten-Hashes, geprüften Namen, Zeitraum und Sperrentscheidung. Der TLS-Beleg enthält Version, Suite, CertificateVerify und Finished ohne Geheimnisse. Der EAP-Beleg enthält Methode und geschütztes Ergebnis.

AAA enthält Identität, NAS, Kontext, Policy-Version, Accept/Reject und Attribute. Der Schlüsseltransport enthält Empfänger und Scope. Der NAS enthält Attributauswertung, VLAN/Rolle, ACL, Assoziation und Portzustand. Der Dienstbeleg enthält Adresse, Nachbar, DNS, Route und erste erfolgreiche Applikation.

„Zertifikat gültig, Autorisierung verweigert“, „Accept empfangen, Dienst fehlt“ und „Port offen, Anwendung gescheitert“ sind ehrliche Zustände. Eine Sammelampel darf sie nicht vernichten.

Quellen

  1. RFC 5216
  2. RFC 5216 im Datatracker
  3. Status von RFC 5216
  4. Historie von RFC 5216
  5. Errata zu RFC 5216
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption