Zusammenfassung

  • Ein EAP Provisioning Identifier nach RFC 9965 ist eine öffentliche NAI, mit der ein Peer eine Bereitstellungsmethode anfragt. Er belegt weder Geräteidentität noch Eigentum oder einen Anspruch auf regulären Netzzugang.
  • Ein angenommener Peer bleibt nicht vertrauenswürdig. Nur erwarteter Verkehr darf passieren; Dauer, Datenmenge, Dienste, Versuche und gleichzeitige Sessions sind zu begrenzen, die Peers untereinander zu isolieren.
  • Ein Schließungsbeleg für den Bereitstellungspfad sollte Anfrage, tatsächlich umgesetzte Beschränkung und Entfernung oder Ablauf zusammenführen. Das ist Daniel Kades redaktioneller Vorschlag, keine IETF-Vorgabe.

Der Ausnahmezustand beginnt mit einer öffentlichen Zeichenfolge

Bei der ersten Inbetriebnahme fehlt häufig genau das, was normale Authentisierung voraussetzt: ein Passwort, Zertifikat oder anderes gerätespezifisches Merkmal. Das Gerät braucht Verbindung, um das Merkmal zu bekommen, darf ohne Merkmal aber noch nicht ins normale Netz. RFC 9965 ordnet diesen Zirkelschluss durch EAP Provisioning Identifiers, kurz EPI.

Ein EPI folgt dem NAI-Format aus RFC 7542. Der Realm unter eap.arpa und der Benutzerteil benennen den gewünschten Mechanismus. Im IANA-Register stehen unter anderem @noob.eap.arpa für EAP-NOOB und portal@tls.eap.arpa für einen beschränkten Portalzugang über EAP-TLS.

Die Kennung kann vorab in Geräte eingebaut werden, weil sie öffentlich ist. Gerade deshalb ist sie kein exklusiver Besitznachweis. Wer sie sendet, beweist nicht, dass das Gerät aus einer autorisierten Lieferung stammt, noch im Besitz des ersten Käufers steht, im Inventar geführt wird oder das Produktionsnetz betreten darf.

RFC 9965 belässt die Kennung in ihrem engen Bedeutungsraum. Implementierungen müssen einen EPI-Peer als nicht vertrauenswürdig behandeln. Der Betreiber darf die Anfrage nach lokaler Politik oder Kapazität ablehnen. Nimmt er sie an, muss er das Gerät in ein begrenztes Netz einordnen; unbeschränkter Zugang ist ausgeschlossen.

Ein erfolgreiches EAP-Ergebnis bedeutet damit nur, dass der schmale Vorgang beginnen darf. Auch die spätere Ausstellung eines Zertifikats ist noch kein Beleg für den Zustand am Switch oder Access Point. Dort kann die vorläufige ACL weiterleben, obwohl der Ausstellungsdienst seinen Auftrag erledigt hat.

Diese Restregel ist kein bloßes Aufräumproblem. Ihr Endzeitpunkt gehört zur ursprünglichen Zugangsentscheidung. Ein Ausnahmezustand ohne nachweisbares Ende ist keine befristete Ausnahme.

eap.arpa ist kein Wegweiser zu einer fremden Autorität

Der Name ähnelt einer DNS-Domain. RFC 9965 trennt jedoch den NAI-Realm eap.arpa vom Domainnamen eap.arpa.. IANA führt ihn im Register besonderer Domainnamen, doch er soll nicht über normales DNS aufgelöst und nicht außerhalb von EAP verwendet werden. DNS-Anfragen sollen NXDOMAIN erhalten.

Damit bleibt die Entscheidung lokal. Ein AAA-System soll aus der öffentlichen Zeichenfolge nicht automatisch einen entfernten Vertrauensgeber entdecken. Das empfangende Netz entscheidet, ob es die Kennung kennt, die zugeordnete Methode akzeptiert, welche Bereitstellungsserver erreichbar sind und wie lange.

Auch die Fehlerpfade sind eng. Eine fehlerhafte EPI führt zu EAP Failure. Bei unbekannter Kennung, nicht unterstützter Methode oder einer Methode, die nicht zur EPI passt, wird ein Nak mit Typ null verwendet. Mit Bereitstellungsmerkmalen darf keine allgemeine Methodenaushandlung stattfinden.

Die Registrierung sichert gemeinsame Syntax und Zuordnung. Sie entscheidet nicht, ob ein konkretes Gerät legitim ist. Die IETF definiert den Mechanismus, IANA verwaltet die Namen, der Netzbetreiber beherrscht die Zugangskante, und der institutionelle Gerätehalter entscheidet über die endgültige Aufnahme. Diese Mandate sollten in den Nachweisen getrennt bleiben.

Die richtige Prüfeinheit ist daher eine einzelne, kurzlebige Session: Anfrage, lokaler Beschluss, umgesetzte Regel, Ressourcenbudgets, Ergebnis und Ende.

Begrenzung ist eine Positivliste

Ein Rollenname wie „Onboarding“ sagt noch nicht, was das Gerät tatsächlich erreichen kann. RFC 9965 beschreibt das sichere Bereitstellungsnetz als Umgebung, in der ausschließlich erwarteter Verkehr erlaubt und alles andere blockiert wird. Nur bekannte schädliche Ziele zu sperren, lässt vergessene Kanäle offen; selbst DNS kann zum Datentransport missbraucht werden.

Der Nachweis muss deshalb bis zum Enforcement reichen. Welche Filter-ID, VLAN-Zuordnung, ACL, dynamische Rolle oder Controller-Regel wurde installiert? Welche Fassung? Auf welchen Geräten? Welche Ziele, Protokolle und Ports waren erlaubt? Welche Hilfsdienste für Zeit, Namensauflösung oder Zertifikatsprüfung waren nötig? Eine wohlklingende Bezeichnung beantwortet diese Fragen nicht.

Der RFC nennt mehrere voneinander unabhängige Grenzen:

  • Bereitstellung soll gewöhnlich in Sekunden bis einigen Dutzend Sekunden erfolgen; lange Zeiten können auf ein Problem hinweisen.
  • Die übertragene Datenmenge soll begrenzt sein.
  • Die Zahl erreichbarer Dienste soll klein und zweckgebunden bleiben.
  • Versuche sollen einer Ratenbegrenzung unterliegen; auffällige Peers können blockiert werden.
  • Die Gesamtzahl gleichzeitig bereitgestellter Peers soll begrenzt werden.
  • Peers im begrenzten Netz dürfen nicht miteinander kommunizieren.

Die Zeitgrenze verhindert dauerhaften Aufenthalt. Das Bytebudget beschränkt die Nutzung als Übertragungskanal. Die Positivliste verkleinert die Reichweite. Rate und Parallelität schützen RADIUS, Adressvergabe, Zertifikatsdienste und Support. Isolation verhindert, dass unbekannte Geräte einander im selben Segment angreifen.

Keine Grenze ersetzt eine andere. Zehn Sekunden voller Internetzugang bleiben weitreichend. Eine präzise ACL ohne Ablauf wird zur dauerhaften Nebenroute. Eine kleine Warteschlange schützt noch nicht vor Peer-to-Peer-Verkehr.

Der in RFC 9965 erwähnte RADIUS Filter-Id ist ein mögliches Bindeglied zur Zugriffspolitik, aber nicht die einzig zulässige Technik. Entscheidend ist, dass der Name auf die damals wirksame Fassung zurückgeführt werden kann. Eine unveränderte Bezeichnung bei vergrößerter Positivliste macht historische Protokolle mehrdeutig.

Wiederholungen dürfen die Frist ebenfalls nicht umgehen. Beginnt der Peer nach jedem Ablauf sofort eine neue Session, entsteht aus vielen kurzen Ausnahmen eine lange. Zähler und Rate müssen eine geeignete, datensparsame Zugangskonstellation zusammenfassen, ohne daraus vorschnell eine dauerhafte Identität zu machen.

Unbekannter Peer, bekannter Server

„Unauthenticated provisioning“ bedeutet nicht, dass beide Seiten anonym bleiben dürfen. Jede Methode unter eap.arpa muss einen Weg zur Authentisierung des Servers festlegen, entweder in EAP oder später über ein geschütztes Protokoll wie HTTPS. Der Peer muss das lokale Netz weiterhin als nicht vertrauenswürdig behandeln.

Bei portal@tls.eap.arpa kann EAP-TLS einen nicht authentisierten Peer in den begrenzten Portalzustand bringen. Der EAP-Server muss dennoch etwa durch ein Zertifikat authentisiert werden. Ein allgemein bekanntes TLS-PSK würde diese Sicherheit nicht liefern.

Die Asymmetrie ist sachgerecht. Das Netz akzeptiert von einem Unbekannten wenige, eng geführte Pakete. Das Gerät soll seine künftige dauerhafte Konfiguration nicht von einer ebenso unbekannten Stelle beziehen. Ein On-Path-Angreifer könnte sonst die Bootstrap-Ausnahme in langfristige Kontrolle umwandeln.

RFC 8952 unterscheidet Bereitstellungsdienst, Captive-Portal-API, Benutzerportal und Enforcement Device. Der Dienst kann eine erfolgreiche Ausstellung melden, während das Enforcement Device noch die alte Regel hält. Ein Client kann einen zwischengespeicherten Status anzeigen, der nicht mehr mit Zeit- oder Bytebudget im Netz übereinstimmt.

Der glaubwürdigste Schließungsnachweis kommt daher vom Gerät, das Pakete tatsächlich erlaubt oder sperrt, beziehungsweise von einer unmittelbaren Beobachtung dieses Zustands. Ein gesendeter Controllerbefehl ist Absicht, keine fertige Zustandsänderung.

Ausstellen und zulassen sind verschiedene Beschlüsse

Die Bereitstellung kann ein Zertifikat, eine Schlüsselreferenz, Konfiguration oder einen Out-of-Band-Schritt nach RFC 9140 hervorbringen. Sie kann auch wegen Serverprüfung, falscher Methode, Zeitüberschreitung, Budget, Kapazität oder lokaler Ablehnung enden.

Ein gemeinsamer Status „fertig“ verdeckt diese Unterschiede. Die Ausstellung einer Berechtigung belegt weder die korrekte Zuordnung zum lokalen Bestand noch ihre aktuelle Gültigkeit, ihren Dienstumfang oder die erfolgreiche nächste Authentisierung.

Eine klare Folge beendet zuerst die EPI-Session. Danach beginnt der Peer eine gewöhnliche Authentisierung mit dem neuen Merkmal. Die aktuelle Autorisierungspolitik entscheidet für die nun authentisierte Identität über den nächsten Zugriff. Die Nutzererfahrung darf nahtlos sein; die beiden Autoritätsentscheidungen bleiben getrennt.

Wird die Rolle in derselben Verbindung umgeschaltet, braucht der Nachweis dieselbe logische Kante: geschützte Referenz auf das neue Merkmal, resultierende Identität, verwendete Autorisierungsfassung, neue Regel und Entfernung der alten beschränkten Regel. Ein Teilfehler sollte zum engeren Zustand führen, nicht zu einer Mischung beider Rechte.

Genau hier unterscheidet sich diese Untersuchung vom vorhandenen Beitrag zu RFC 9966. TLS-POK kann ein begrenztes Wissen über einen gerätespezifischen Bootstrap Key belegen, ohne dessen rechtmäßige Verwahrung zu erklären. Dieser Artikel prüft nicht erneut die Schlüsselkette, sondern den Netzwerkzustand um die öffentliche EPI. Schlüsselbeweis und ACL-Schließung beantworten verschiedene Fragen.

Ein Schließungsbeleg in sieben Verknüpfungen

Der lokale Beleg sollte enthalten:

  1. Anfrage: genaue EPI, EAP-Methode, Zeit, Authenticator oder NAS, Schnittstelle und kurzlebige Session-ID.
  2. Entscheidung: Annahme oder Ablehnung, Politikfassung, Kapazitätslage, Grundklasse und verantwortlicher Dienst.
  3. Umsetzung: tatsächlich installierter Filter, Segment, Rolle oder ACL samt Fassung und Enforcement-Punkten; Positivliste, Default-Deny und Peer-Isolation.
  4. Budgets: Start, harte Frist, Byteobergrenze, Dienste, Versuchszähler, Ratenstatus und belegte Parallelkapazität.
  5. Servernachweis: Authentisierungsmethode, Zertifikats- oder Trust-Anchor-Referenz, Prüfergebnis und eng gefasste Ausnahme.
  6. Ergebnis: Erfolg oder genaue Fehlerklasse; bei ausgestelltem Merkmal nur geschützte Referenz und vorgesehene Laufzeit, niemals Geheimnisse.
  7. Schließung: Zeitpunkt und Grund von Entfernung oder Ablauf, Beobachtung am Enforcement, Restflussbehandlung, etwaige neue authentisierte Session und Abgleich verwaister Zustände.

Eine öffentliche Sicht kann Verteilungen von Dauer, Politikfassungen, Fehlerklassen und offene Ausnahmen zeigen. Gerätekennungen, Zertifikate, Ports und detaillierte Positivlisten bleiben geschützt. Hashes können nachträgliche Ersetzungen erkennbar machen, beweisen aber weder die Rechtmäßigkeit der Ursprungspolitik noch die Ehrlichkeit des Messpunkts.

Der „Schließungsbeleg“ ist ein redaktioneller Vorschlag von Daniel Kade. RFC 9965 schreibt ihn nicht vor. Er ist weder IETF-Zertifikat noch Netzwerkberechtigung oder Artikel-API-Objekt. Er macht eine lokale Verantwortung prüfbar, die der Standard bewusst nicht zentralisiert.

Ein abgelaufener Timer ist noch keine entfernte Regel

Der TTL-Wert kann im Controller null sein, während die ACL im Switch fortbesteht. Ein Löschbefehl kann eine alte Generation treffen oder bei getrennter Verbindung als erledigt erscheinen. Umgekehrt kann das Zugangsgerät die Regel bereits entfernt haben, obwohl die Orchestrierung noch eine aktive Session anzeigt.

Geplanter Ablauf, Aktion der Steuerung und Beobachtung im Datenpfad sind getrennt zu speichern. Ihre Differenz ist ein Befund. Automatischer Ablauf und bestätigte Entfernung sind ebenfalls nicht dasselbe Ereignis.

Auch Fehlschläge müssen eng enden. Ein ausgefallenes Portal darf keinen allgemeinen Internetzugang auslösen. Ein langsamer Zertifikatsdienst darf die Frist nicht still verlängern. Fehlerhafte Konfiguration darf keinen endlosen Wartezustand schaffen.

Die Prüfung vergleicht drei Bilder: die beabsichtigte Politik, die während der Session realisierte Politik und den Restzustand danach. Abweichungen dürfen nicht in einer grünen Gesamtkennzahl verschwinden.

Das entspricht Heng Lus Policy Mirror: Der formale Text zeigt die vorgesehene Autorität, laufende Konfiguration den tatsächlich ausgeübten Einfluss. Erst wenn beides vergleichbar ist und die Ausnahme ihr Ende belegt, wird der provisorische Pfad regierbar.

Grenzen und Quellen

Die Quellen belegen Standards, Register und beschriebene Risiken. Sie messen keine Verbreitung, nennen keinen Betreiber mit einer Implementierung und dokumentieren keinen Vorfall. Technik, Fristen und Vertraulichkeit unterscheiden sich nach Umgebung.

Der Beleg ist keine Geräteidentität, juristische Zulassung, Verzeichnisakte oder Netzwerk-Credential. Seine Aussage bleibt kleiner: Ein unbekannter Peer erhielt für einen begrenzten Zeitraum eine eng definierte Verbindung, und diese Verbindung endete, bevor eine neue Authentisierungsentscheidung den nächsten Zustand schuf.