Zusammenfassung

  • RFC 9965 reserviert eap.arpa für NAIs, die einen festgelegten Provisionierungsweg und begrenzte, noch nicht authentisierte Konnektivität anfragen.
  • Anfrage, Wahl der EAP-Methode, Serverauthentisierung, Durchsetzung des begrenzten Netzes, Ausgabe einer Berechtigung und reguläre Zulassung sind getrennte Nachweise und Entscheidungen.

Ein unbekanntes Gerät übermittelt eine Kennung mit dem Ende eap.arpa. Ein Netz kann darin die Bitte lesen, beim Erhalt einer Berechtigung zu helfen. Es darf darin nicht die Berechtigung selbst lesen. Darin liegt die zurückhaltende Aussage von RFC 9965, The eap.arpa. Domain and Extensible Authentication Protocol Provisioning.

Der RFC definiert den EAP Provisioning Identifier (EPI): einen NAI, dessen Realm eine Subdomain von eap.arpa. ist. Dieser Realm ist absichtlich unabhängig von einer bestimmten Organisation. Er soll weder automatisch durch vorhandene AAA-Infrastruktur weitergereicht noch über die übliche dynamische Peer-Erkennung aufgelöst werden. Dass eine Organisation ihn lokal routen darf, wird damit nicht untersagt. Die gemeinsame Syntax sagt nur, wie ein Peer nach einer Provisionierungsmethode fragt; der empfangende Betreiber entscheidet weiter, ob er die Anfrage annimmt, wohin er sie leitet und nach welcher Beweislage.

Eine Realm-Zeichenfolge ist deshalb schwache Evidenz. Sie kann zeigen, dass ein Peer in einem EAP-Identitätsaustausch eine bestimmte Anfrage ausgesandt hat. Sie zeigt nicht, wem das Gerät gehört, welche Organisation verantwortlich ist, welches Backend sie bearbeitete oder ob eine Authentisierungsmethode abgeschlossen wurde. Ein Log, das @method.eap.arpa in „vertrauenswürdiges Gerät“ übersetzt, ersetzt eine beobachtete Nachricht durch mehrere nicht beobachtete Entscheidungen.

RFC 9965 beschreibt den Zustand vor diesen Entscheidungen eindeutig. Implementierungen müssen EPI nutzende Peers als nicht vertrauenswürdig behandeln. Nach Annahme einer Provisionierungsmethode gehört der Peer in ein begrenztes Netz, etwa ein Captive Portal; dieses Netz darf keinen uneingeschränkten Zugang zulassen. Ein sicheres Provisionierungsnetz lässt den erwarteten Verkehr zu und blockiert alles andere. Nur ausgewählte schlechte Ziele zu sperren lässt eine größere, schwerer prüfbare Oberfläche zurück.

Auch die Methodengrenze darf nicht übersprungen werden. Der EPI wählt die angefragte Provisionierungsmethode. Nimmt der EAP-Server die Anfrage an, muss die angebotene Methode zu der dem EPI zugeordneten Methode passen; erst dann läuft die normale EAP-Zustandsmaschine weiter. RFC 3748 beschreibt EAP als Authentisierungsrahmen mit mehreren Methoden und hält fest, dass einem authentisierten Peer wegen einer Richtlinie, einer Sitzungsgrenze oder anderer Gründe der Zugang dennoch verweigert werden kann. Methodenwahl ist somit weder EAP-Erfolg noch allgemeine Autorisierung.

Die Serverauthentisierung ist eine weitere Schicht. RFC 9965 verlangt, dass jede Provisionierungsmethode unter eap.arpa. beschreibt, wie der Server authentisiert wird, und empfiehlt TLS-basiertes EAP, wo es Serverauthentisierung, Integrität und Vertraulichkeit liefert. Das ist eine Anforderung an das Methodendesign, kein Nachweis, dass eine konkrete Sitzung ein bestimmtes Zertifikat validiert hat. Eine brauchbare Prüfkette trennt EPI-Anfrage, lokale Routingentscheidung, gewählte Methode, Nachweis der Serverauthentisierung, tatsächlich durchgesetzte begrenzte Netzregel, Berechtigungsentscheidung und spätere Zugangsentscheidung.