Zusammenfassung

  • Die Wiedervergabe einer Kennung und das Ende ihrer alten Gerätezuordnung sind verschiedene Vorgänge. Das Zugangssystem muss beide miteinander abstimmen.
  • Status-API und Verkehrssteuerung benötigen eine gemeinsame Sicht auf das jeweilige Gerät. Anschlussort, Adressübersetzung und mehrere Adressen beeinflussen, was die Komponenten unterscheiden können.
  • Eine dauerhafte interne Zuordnung kann Kontinuität ermöglichen, obwohl sichtbare Kennungen wechseln. Diese Verknüpfung bleibt schutzbedürftig und benötigt einen begrenzten Zweck.

Der Übergang zwischen zwei Zuständigkeiten

In einem gedachten Gastnetz gibt die Adressverwaltung einen nicht mehr verwendeten Wert erneut aus. Aus ihrer Sicht ist die Aufgabe erledigt. Der neue Teilnehmer besitzt eine gültige Adresse, und kein anderer aktueller Teilnehmer verwendet denselben Wert. Die Statusanwendung des Portals hat jedoch möglicherweise noch eine Zuordnung zum früheren Gerät.

Für dieses Problem muss keine Komponente vollständig ausfallen. Die Anwendung kann zuverlässig ihren gespeicherten Datensatz zurückgeben. Das Gerät, das Pakete zulässt oder verwirft, kann zuverlässig seine aktuelle Regel anwenden. Unzuverlässig geworden ist die Beziehung zwischen beiden Aussagen.

Das Beispiel beschreibt keine beobachtete Störung eines bestimmten Betreibers. Es verdeutlicht eine Zuständigkeitslücke: Wer stellt fest, dass die alte Zuordnung beendet wurde, bevor der wiedervergebene Wert als Aussage über einen neuen Teilnehmer dient?

Die Captive-Portal-Architektur in RFC 8952 behandelt Geräteidentität als gemeinsame Aufgabe mehrerer Komponenten. Das im November 2020 veröffentlichte Dokument ist „Informational“, keine Spezifikation auf dem Internet Standards Track. Es trennt die Bereitstellung der Zugangsinformationen, die Statusabfrage über eine API, die Benutzerinteraktion im Portal und die Durchsetzung der Verkehrsregeln.

Diese Funktionen dürfen gemeinsam betrieben oder verteilt werden. Entscheidend ist, dass sie in ihrer Kommunikation dasselbe Gerät meinen. Eine einheitliche Produktbezeichnung ersetzt keine übereinstimmende Zuordnung.

Eine Kennung ist nicht auf unbegrenzte Zeit eindeutig

RFC 8952 verlangt Eindeutigkeit unter den Geräten, die zu diesem Zeitpunkt mit diesem Captive Portal interagieren. Ein Wert darf später einem anderen Gerät zugeordnet werden. Unabhängige Portale dürfen denselben Wert für verschiedene Geräte verwenden.

Diese Begrenzung ist sinnvoll. Ein lokaler, zeitlich begrenzter Zugang muss nicht für jeden Besucher eine weltweit dauerhafte Kennung erzeugen. Wiederverwendbare Eigenschaften des Netzes können ausreichend sein.

Die Folge ist jedoch, dass Eindeutigkeit und Lebensdauer getrennt betrachtet werden müssen. Eine heute richtige Zuordnung macht eine gestern richtige Zuordnung nicht weiterhin gültig. Der Wert kann derselbe bleiben, während sich sein Gegenstand ändert.

Für IP-Adressen verlangt Abschnitt 3.4.2, dass Komponenten ihre Abbildung entfernen oder aktualisieren, sobald sich die Zuordnung zwischen Adresse und Gerät ändert. Für die Identifikation über eine physische Schnittstelle verlangt die Architektur, dass sowohl API als auch Durchsetzungsgerät den zugehörigen Zustand ungültig machen, wenn das angeschlossene Gerät wechselt.

Das ist mehr als Datenbankpflege. Die Entscheidung beeinflusst den Gegenstand der nächsten Statusantwort und der nächsten Verkehrsregel. Ein alter Zustand darf nicht allein deshalb als Zustand des neuen Teilnehmers gelten, weil dessen Adresse vertraut aussieht.

Eine begrenzte Aufbewahrung von Übergangsnachweisen ist damit nicht ausgeschlossen. Historische Nachvollziehbarkeit und eine aktive operative Zuordnung sind verschiedene Zwecke. Wer einen alten Datensatz zu Prüfzwecken aufbewahrt, sollte ihn nicht dadurch wieder zum aktuellen Subjekt des Dienstes machen.

Vier Eigenschaften ergeben noch keine Rangliste

Die Architektur empfiehlt, Eindeutigkeit, Widerstand gegen Vortäuschung und Sichtbarkeit für API sowie Durchsetzungsgerät gemeinsam zu bewerten. Sie liefert keine allgemeine Punktzahl, mit der sich für jede Topologie derselbe Sieger bestimmen ließe.

Eine physische Schnittstelle kann ein geeignetes Merkmal sein, wenn an ihr nur eine Geräteinstanz hängt. Teilen sich mehrere Geräte diesen Anschluss, unterscheidet das Merkmal sie nicht mehr. Eine Eigenschaft des Anschlusses ist dann noch vorhanden, aber ihr Geltungsbereich hat sich verändert.

Zudem muss die Information die richtige Stelle erreichen. Das Durchsetzungsgerät kann den Anschluss unmittelbar kennen oder zusätzlichen Kontext erhalten, etwa über einen Tunnel. Für die API stellt sich ein vergleichbares Problem. Ein entfernt betriebener Webdienst erfährt den physischen Zugangspunkt nicht automatisch aus einer gewöhnlichen HTTPS-Anfrage.

Die Bequemlichkeit einer Kennung auf einer Seite darf deshalb nicht als Beweis ihrer Eignung auf der anderen Seite gelten. Die Zuordnung muss entlang der tatsächlich verwendeten Interaktionen funktionieren.

Auch ein Nachweis der Rückerreichbarkeit ist begrenzt. RFC 8952 nennt den TCP-Verbindungsaufbau als etwas, das unter bestimmten Umständen gegen Vortäuschung ausreichen könnte, weist aber auf mögliche Grenzen in Netzen mit gemeinsamem Übertragungsmedium hin. Daraus folgt weder eine universelle Geräteauthentifizierung noch ein Nachweis der Person hinter dem Gerät.

Der Standort der API gehört zum Identitätsmodell

IP-Adressen sind naheliegende Merkmale, doch ihre Aussage hängt vom Beobachtungsort ab. Hinter einer Adressübersetzung kann eine Komponente mehrere Geräte unter einer gemeinsamen sichtbaren Adresse wahrnehmen.

RFC 8952 hält eine eindeutige Identifikation in solchen Fällen für möglich, wenn die Komponenten die Portzuordnung kennen. Die zusätzliche Kenntnis ist die Bedingung. Eine gemeinsam genutzte öffentliche Adresse allein liefert sie nicht.

Die API-Spezifikation RFC 8908, im September 2020 auf dem Standards Track veröffentlicht, formuliert den Abstimmungsbedarf ausdrücklich: Nutzt das Portal die IP-Adressen des Clients zur Identifikation, müssen API und Durchsetzungsgerät dieselben Adressen sehen können.

Damit kann die Verlagerung einer API eine Änderung des Identitätsmodells sein, selbst wenn Titel, Zertifikat und Antwortformat unverändert bleiben. Der Dienst erhält möglicherweise nicht mehr den Kontext, auf dem seine bisherige Zuordnung beruhte.

Eine Abnahme, die lediglich Erreichbarkeit und Antwortsyntax prüft, erfasst diese Veränderung nicht. Sie beweist, dass der Dienst antwortet, aber nicht, worauf er seine Antwort bezieht.

Das ist kein allgemeines Argument gegen zentralen oder entfernten Betrieb. Es ist ein Grund, die Sichtbarkeit der Identifikationsmerkmale als eigene Abhängigkeit einer solchen Entscheidung zu behandeln. Der neue Standort kann sinnvoll sein, wenn die notwendige Zuordnung weiterhin begründet ist.

Was mehrere Adressen zu einem Teilnehmer macht

Ein Endgerät kann IPv4, IPv6 oder mehrere Adressen derselben Familie verwenden. RFC 8952 erlaubt zwei Vorgehensweisen: Die Adressen werden als verschiedene Geräteinstanzen behandelt, oder sie werden in einer gemeinsamen Teilnehmersicht zusammengeführt.

Die physische Anzahl der Geräte entscheidet diese Frage nicht von selbst. Eine Zusammenführung kann einen konsistenten Dienst über mehrere Verkehrswege ermöglichen. Eine Trennung kann für die konkrete Umsetzung sinnvoll sein. Beide benötigen eine dazu passende Leistungsbeschreibung.

Kritisch wird eine Mischung. Verlängert die API einen zusammengefassten Sitzungszustand, während die Verkehrssteuerung Bedingungen nur für eine einzelne Adresse verändert, können die Komponenten unterschiedliche Dienstobjekte behandeln. Das ist eine mögliche Folge unvereinbarer Entscheidungen, kein Befund über sämtliche Dual-Stack-Portale.

Die Architektur erwähnt im IPv6-Kontext eine Identifikation anhand eines Subnetzes. Sie erklärt nicht jedes /64 automatisch zu einem einzigen Teilnehmer. Ob ein Präfix diese Bedeutung besitzt, muss die tatsächliche Anschluss- und Dienststruktur zeigen.

MAC-Adressen nennt das Dokument ebenfalls als mögliche Merkmale unter den allgemeinen Kriterien, ohne ihren Einsatz zu einer universellen Methode auszuarbeiten. Die Schlussfolgerung lautet nicht, Datenschutzfunktionen abzuschalten oder eine unveränderliche Hardwarekennung einzuführen.

Für die Führungsebene liegt darin eine greifbare Entscheidung: Welchen Gegenstand verkauft oder gewährt der Dienst, und welche technische Gruppierung soll diesen Gegenstand abbilden? Eine unbeantwortete Frage wird nicht dadurch kleiner, dass sie als Implementierungsdetail bezeichnet wird.

Ein Link kann den Kontext wechseln

Ein Portal kann Clients aus dem Kontext ihrer Anfragen erkennen und dafür eine gemeinsame URI verwenden. Das kann auf dem erwarteten Pfad funktionieren. Besitzt ein Gerät mehrere Netzschnittstellen oder hängt die DNS-Antwort vom Anfrageursprung ab, kann sich der erforderliche Kontext ändern.

RFC 8952 unterscheidet den API-Zugriff, der kontextabhängig sein darf, von den durch die API bereitgestellten URIs. Diese sollten gerätespezifisch sein und für ihre korrekte Funktion nicht von dem äußeren Kontext abhängen.

RFC 8908 empfiehlt entsprechend eine je Client unterschiedliche bereitgestellte URI, wenn die API notwendige Identitätsinformationen sonst nicht erkennen kann. Eine solche URI kann auch zwischen Sitzungen desselben Geräts wechseln.

Das macht einen ungeschützten Gerätewert in einer URL nicht zu einer sicheren Berechtigung. Die Architektur weist auf Vortäuschungs- und Wiederholungsrisiken hin, wenn nicht authentifizierte Kennungen in URIs verwendet werden. Die richtige Ressource zu adressieren und den richtigen Zugriff zu erlauben bleiben getrennte Aufgaben.

Einige Funktionen dürfen an den Zugang über das Captive Portal gebunden bleiben. Eine von einem anderen Netz aufgerufene Zahlungsseite muss gegebenenfalls deutlich machen, dass der Vorgang nicht die gerade verwendete Verbindung betrifft. Die Fortexistenz eines Links ist keine Erklärung seines aktuellen Dienstbezugs.

TLS schützt einen anderen Teil der Beziehung. RFC 8908 prüft den Server gegen den bereitgestellten Hostnamen, nicht die Sicherheit des Bereitstellungsverfahrens oder die Vertrauensentscheidung des Benutzers über das Netz. Kann das Zertifikat nicht geprüft werden, darf der Client die vorgesehene API-Interaktion nicht fortsetzen.

Auch ein korrekt authentifizierter Server kann intern eine falsche Gerätezuordnung verwenden. Transportvertrauen und sachlich richtige Zuordnung sollten deshalb nicht in einer einzigen Erfolgsanzeige verschwinden.

Die interne Konstante hinter wechselnden Kennungen

Veränderliche anonyme Kennungen können langfristige Wiedererkennung erschweren. Die Datenschutzbetrachtung in RFC 8952 benennt jedoch einen wichtigen Vorbehalt: Komponenten können wechselnde Werte intern auf eine stabile, langfristige Referenz abbilden.

Diese Referenz kann einen betrieblichen Nutzen haben. Sie hilft möglicherweise, eine Sitzung über mehrere Adressen hinweg zu verstehen oder eine vorgesehene Kontinuität zu erhalten. Gleichzeitig bleibt sie ein empfindliches Verknüpfungsmerkmal.

Die sichtbare Kennung kann wechseln, während der Betreiber intern eine fortlaufende Beziehung bewahrt. Verschlüsselte Übertragung schützt vor Einsicht auf dem Transportweg. Sie entscheidet nicht, wer historische Zuordnungen abfragen darf, welchem Zweck sie dienen und wann sie enden.

Weder vollständige Geschichtslosigkeit noch unbegrenzte Aufbewahrung folgt aus der Architektur. Ein konkreter Zuordnungsstreit kann begrenzte Übergangsnachweise erfordern. Daraus ergibt sich keine automatische Notwendigkeit, sämtliche späteren Verwendungen unter derselben internen Referenz zusammenzuführen.

Lu Heng beschreibt das Prinzipal-Agent-Problem als Abstand zwischen Entscheidungsgewalt und Folgen. Als analytische Perspektive führt das hier zur Frage, wer Gruppierung, Wiedervergabe und Aufbewahrung bestimmt. Seine registerspezifische Kritik ist kein Tatsachennachweis gegen Betreiber von Captive Portals.

Sein Text über den Zweck von BTW fordert eine Beschreibung der tatsächlichen Mechanismen statt Werbung für Akteure. Dazu gehört, den Nutzen fortgesetzter Erkennung ebenso ernst zu nehmen wie die Schutzlast einer fortgesetzten Verknüpfung.

Ein Zugangssystem benötigt deshalb nicht zwingend eine dauerhafte Geräteidentität. Es benötigt eine nachvollziehbare Lebensdauer seiner Zuordnung. Die Verantwortung endet nicht damit, eine Adresse wieder verfügbar zu machen. Sie umfasst auch die Bestätigung, dass das System aufgehört hat, unter dieser Adresse den früheren Teilnehmer zu erkennen.

Quellen