Zusammenfassung

  • Mit dem Release vom 28. Juli 2026 führte ARIN für Reg-RWS die Authentifizierung über den Authorization-Header ein. Am Folgetag schloss ARIN ACSP-Vorschlag 2022.5 und hielt zugleich fest, dass API-Schlüssel in URL-Parametern weiterhin akzeptiert werden.
  • Die geprüften öffentlichen Quellen bestätigen die Alternative und empfehlen den Wechsel. Sie nennen aber weder Abschaltdatum noch Migrationsstufen, Zahl der verbleibenden URL-Aufrufe oder Nutzungsanteil des Headers. Der Abschluss dokumentiert eine gelieferte Funktion, nicht das Ende des alten Transportwegs und nicht die abgeschlossene Migration der Clients.

Zwei verschiedene Uhren

Ein Aufruf an ein Register muss zwei Fragen beantworten: Welche Ressource ist gemeint, und darf der Aufrufer auf sie zugreifen? Reg-RWS automatisiert unter anderem die Verwaltung von RPKI- und IRR-Daten, Reassignments und Reallocations sowie Änderungen an Netzblöcken. Über Jahre konnte der API-Schlüssel in der Query einer URL stehen. Seit Juli 2026 gibt es einen zweiten Weg: Die URL benennt die Ressource; der Schlüssel wird getrennt im Authorization-Header übertragen.

Das funktionale Ergebnis kann gleich sein. Die Zahl der Orte, an denen die Zugangsdaten auftauchen können, ist es nicht. URLs landen häufig im Browserverlauf, in Request-Logs, Proxy-Aufzeichnungen und Diagnosematerial. ARIN selbst nennt in seiner Erläuterung vom August Browser-Verläufe sowie Server- und Proxy-Logs als Speicherorte, an denen ein Schlüssel aus einer URL zurückbleiben kann. Der Header verringert die Wahrscheinlichkeit einer versehentlichen Weitergabe.

Unsichtbar wird das Geheimnis dadurch nicht: Eine Anwendung, ein Proxy, ein Tracing-System oder ein Support-Dump kann den Authorization-Wert bei falscher Konfiguration ebenfalls aufzeichnen. Der praktische Sicherheitsgewinn liegt in einer kleineren standardmäßigen Angriffsfläche, nicht im Ende der Schlüsselverwaltung.

Die Chronologie trennt Umsetzung und Migration. ACSP-Vorschlag 2022.5 wurde am 11. Februar 2022 eingereicht. Er verlangte eine Alternative zum API-Token in REST-URLs und verwies darauf, dass Systeme mit vollständigen URL-Logs einen gültigen Schlüssel für Log-Leser sichtbar machen könnten; daraus könne ein unbefugter Zugriff entstehen. Eine Frist nannte der Einreicher nicht. Am 23. Februar erklärte ARIN den HTTP-Header zur besten Lösung, nahm die Arbeit in die Priorisierung für die Engineering Roadmap 2023 auf und sagte, der Vorschlag bleibe bis zur Umsetzung offen.

Am 28. Juli 2026 meldete ARIN, dass REST-Aufrufe den Authorization-Header mit dem Schema ApiKey nutzen können. Am 29. Juli hielt die Abschlussantwort fest, dass die bevorzugte Alternative umgesetzt sei und URL-Parameter weiterhin angenommen würden. Der Vorschlag galt als erfüllt, weil die verlangte Option verfügbar war. Daraus folgt nicht, dass die frühere Option abgeschaltet wurde. Die technische Erläuterung vom 11. August und ARIN Bits im September bestätigen erneut: URL-Aufrufe sind derzeit zulässig, sollen irgendwann auslaufen und sollten schon jetzt durch die Header-Methode ersetzt werden.

Hier laufen zwei Uhren. Die erste misst die Lieferung: Ein Vorschlag wird aufgenommen, geprüft, umgesetzt und geschlossen. Die zweite misst die Migration: Kunden müssen die Änderung entdecken, ihre Tools anpassen, das neue Request-Format prüfen, den Schlüssel aus den URLs entfernen und die alte Form nicht mehr verwenden. Für die erste Uhr gibt es im öffentlichen Vorgang ein klares Enddatum. Für die zweite fehlen dort ein öffentlicher Termin und ein Fortschrittsmaß.

Das ist kein Argument gegen den Abschluss des Vorschlags. Wenn eine Anfrage eine zusätzliche Authentifizierungsoption verlangt und diese Option funktioniert, kann die Anforderung erfüllt sein, obwohl Kunden Zeit zur Umstellung brauchen. Die Governance-Frage beginnt danach. Solange der alte Weg unterstützt wird, geht es nicht mehr nur um eine Codeänderung, sondern um eine Betriebsvereinbarung zwischen ARIN und den Organisationen, deren Skripte, Automatisierungsplattformen oder Dienstleister das Register ansprechen.

Warum der Ablageort des Schlüssels zählt

Ein API-Schlüssel ist kein gewöhnliches Request-Feld. ARIN beschreibt ihn als Geheimnis zur Identifikation des Nutzers und weist darauf hin, dass bestimmte REST-Aktionen ein Konto voraussetzen, das mit einem entsprechend berechtigten Point of Contact verknüpft ist. Steht der Schlüssel in der Query, reist er mit der Adresse der Ressource. Systeme, die URLs speichern oder weiterkopieren, können ihn über den ursprünglichen Prozess hinaus aufbewahren. Browser-Verläufe sowie Server- und Proxy-Logs, die ARIN nennt, zeigen diesen unbeabsichtigten Aufbewahrungsweg.

Die Header-Methode verlagert die Authentifizierungsinformation, nicht die angeforderte Ressource. ARIN dokumentiert das Feld Authorization und das Schema ApiKey. Client, Automatisierungstool oder Provisionierungsdienst muss dieses Feld zuverlässig mitsenden, ohne Endpunkt oder Bedeutung der Anfrage zu verändern. Dann muss die URL das Geheimnis nicht mehr als zusätzlichen Parameter enthalten.

Ein technischer Standard bietet einen passenden Vergleich, allerdings mit klarer Grenze. IETF RFC 6750 behandelt OAuth-Bearer-Token, nicht ARINs ApiKey-Schema. Der RFC empfiehlt den Authorization-Header und rät davon ab, solche Token in URI-Parameter zu schreiben, weil URLs mit hoher Wahrscheinlichkeit protokolliert werden. Das bedeutet weder, dass Reg-RWS OAuth verwendet, noch dass der RFC unmittelbar für ARIN gilt. Es zeigt eine bekannte Eigenschaft des HTTP-Betriebs: Ein sensibler Wert in einem URI gelangt leichter in allgemeine Aufzeichnungen als eine Zugangsinformation in einem dafür vorgesehenen Request-Feld.

Ein Header ist noch keine vollständige Sicherheitsrichtlinie. Administratoren können alle Header protokollieren; Tracing-Produkte können sie erfassen; Debug-Dumps können sie speichern; ein Client kann den Schlüssel vor einem Redirect wieder in die URL setzen. Die Umstellung sollte deshalb mit Filtern für Authorization-Werte in Logs, geschützter Schlüsselablage, Zertifikatsprüfung und einem Verfahren zum Ersetzen offengelegter Schlüssel verbunden sein. Das sind Maßnahmen auf Betreiberseite, keine neuen ARIN-Funktionen, die dieser Artikel behauptet.

Auch der Migrationsaufwand ist ungleich verteilt. Ein Team mit einem gepflegten Client ändert womöglich ein Konfigurationsfeld und testet einige Aufrufe. Ein Netzbetreiber mit alten Skripten, Anbietersoftware, Zeitplänen, ausgelagertem Betrieb und getrennten RPKI- oder IRR-Werkzeugen muss jede Stelle finden, an der die Query zusammengesetzt wird. Ohne Messung bleibt dieser Aufwand für das Register unsichtbar. Die fortgesetzte Kompatibilität beweist daher nicht, dass jeder informierte Kunde freiwillig den stärker exponierten Weg gewählt hat.

Was die öffentlichen Quellen belegen

Die Quellen tragen vier getrennte Aussagen:

  1. Header-Authentifizierung ist für Reg-RWS verfügbar. Das Juli-Release und die aktuelle Dokumentation zu REST-Methoden beschreiben sie.
  2. ARIN bevorzugt diese Methode und empfiehlt den Wechsel. Das sagen die technische Erläuterung im August und die September-Übersicht.
  3. URL-Token werden in den geprüften öffentlichen Unterlagen weiterhin akzeptiert. Die Abschlussantwort vom 29. Juli sagt es ausdrücklich; die aktuelle REST-Methodenseite wiederholt es.
  4. Die geprüften Unterlagen veröffentlichen weder Abschaltdatum noch Migrationsstufen, Zahl der URL-Aufrufe oder Anteil der Header-Nutzung.

Die vierte Aussage ist bewusst begrenzt. Sie besagt, dass diese Kennzahlen in den zitierten öffentlichen Quellen fehlen. Sie beweist nicht, dass ARIN keine internen Daten, keinen vertraulichen Plan und keine Gespräche mit Kunden hat. Die Quellen berichten auch keinen Sicherheitsvorfall. Der Vorschlag von 2022 beschreibt einen plausiblen Offenlegungsweg; die Unterlagen von 2026 erklären, weshalb ARIN die Alternative bevorzugt. Keine Quelle meldet einen tatsächlich offengelegten Schlüssel oder eine unbefugte Änderung im Register.

Diese Grenze verhindert zwei entgegengesetzte Fehlschlüsse. Der erste wäre, die vier Jahre als Beleg für Versagen zu werten. Der Vorschlag nannte keine Frist, und die Quellen dokumentieren eine umgesetzte Alternative. Der zweite wäre, den Abschluss als Beweis für verschwundenes Risiko zu lesen. Die Abschlussantwort lässt URL-Aufrufe ausdrücklich zu; die September-Mitteilung spricht von einer künftigen Abschaltung, ohne Datum. Eine sicherere Option kann bereitstehen, während ein stärker exponierter Altweg weiter offen bleibt.

Kompatibilität ist auch ein Serviceversprechen

Den alten Weg vorübergehend offen zu halten, kann die verantwortliche Entscheidung sein. Eine sofortige Sperre könnte einen unbeaufsichtigten, aber wichtigen Prozess der Ressourcenverwaltung unterbrechen. Fehlgeschlagene Automatisierung könnte Registeränderungen, RPKI- oder IRR-Arbeit, Reassignments oder andere Abläufe verzögern, die Kunden auf Reg-RWS aufgebaut haben. Die öffentlichen Quellen nennen solche Einsatzfelder, beziffern aber nicht den Schaden eines konkreten Ausfalls. Eine Register-API gehört zur Betriebsinfrastruktur der Kunden und ist kein beliebig ersetzbarer Demo-Endpunkt.

Kompatibilität kostet ebenfalls. Jede unterstützte Request-Form wird zu einem Zustand, den Dokumentation, Support, Client-Maintainer und Nutzerteams verstehen müssen. Wird ein Weg empfohlen und ein anderer ohne Frist weiterbetrieben, kann „bevorzugt“ zu einer Anweisung ohne Entscheidungsdatum werden. Neue Integrationen übernehmen vielleicht alte Beispiele; ruhende Skripte werden womöglich nie geprüft; eine interne Sicherheitsprüfung kann das Thema abhaken, sobald es irgendeine Header-Option gibt.

Die Antwort ist nicht, identifizierbare Nutzungsdaten einzelner Kunden zu veröffentlichen. Ein Übergang lässt sich sichtbar machen, ohne Identitäten oder Geheimnisse offenzulegen. ARIN könnte zumindest die vorgesehenen Phasen, den Startpunkt des Abschaltzeitraums, die Länge der Vorankündigung, die Kommunikation von Kompatibilitätsänderungen und mögliche Kriterien für eine Verlängerung erläutern. Wenn noch kein Datum feststeht, hilft diese Aussage mehr, als Kunden aus „irgendwann“ selbst einen Termin ableiten zu lassen.

Die geprüften Quellen zeigen nicht, dass ARIN solche Etappen zugesagt hat. Das sind Empfehlungen für einen vorhersehbaren künftigen Übergang, keine Beschreibung eines aktuellen Plans. Die Unterscheidung ist wichtig: Ein veröffentlichtes Datum begründet eine Verpflichtung. Wenn ARIN diese Entscheidung noch nicht getroffen hat, sollte eine Analyse sie nicht als beschlossen darstellen.

Ein Abschaltplan braucht mehr als eine Release-Notiz

Eine technisch erfolgreiche Migration besteht nicht nur aus einem funktionierenden Header-Beispiel. Betreiber müssen wissen, welche Endpunkte und Werkzeuge es unterstützen, ob bekannte Client-Bibliotheken inkompatibel sind, wie Fehler bei fehlendem oder fehlerhaftem Header aussehen und ob ein Aufruf Header und URL-Token zugleich senden könnte. ARINs öffentliche Anleitungen beantworten die grundlegende Syntaxfrage. In den geprüften Unterlagen findet sich aber weder eine öffentliche Kompatibilitätsliste nach Clients noch ein Nutzungs-Dashboard.

Ein solches Dashboard müsste keinen Kunden identifizieren. Aggregierte Zahlen könnten zeigen, ob Header-Aufrufe URL-Aufrufe ersetzen, ob ein langer Restbestand bleibt und ob die Umstellung von wenigen Integrationen abhängt. Eine Abschaltankündigung könnte diese Signale mit Daten verbinden: Bekanntgabe, Ende neuer URL-Beispiele, Warnphase, abschließende Kompatibilitätsprüfung und ein vorgeschlagenes Abschaltfenster. Falls eine Kennzahl nicht ohne Offenlegung betrieblicher Daten veröffentlicht werden kann, könnte ARIN stattdessen die Entscheidungskriterien nennen und den Status jeder Phase mitteilen.

Für Kunden ist das Warten auf einen allgemeinen Abschalttermin keine Sicherheitsstrategie. Die Empfehlung ist bereits klar: Sobald der Client Header-Authentifizierung unterstützt, sollte der Schlüssel aus der URL entfernt werden. Teams können nach Query-Konstruktion in Code und Konfiguration suchen, zuerst gemeinsame Bibliotheken aktualisieren, die Filterung von Authorization in Logs und Traces prüfen, repräsentative Lese- und Schreibaufrufe nach den eigenen Änderungsverfahren testen und offengelegte Schlüssel ersetzen. Das bleibt unabhängig vom Abschaltdatum sinnvoll.

Entscheidend ist ein getesteter Wechsel; ein String-Ersatz beweist nicht, dass alle Clients gleich reagieren.

Das Register sollte den Endtermin auch nicht zur Überraschung machen. Ein gestufter Ablauf verschafft Zeit, nicht selbst gepflegte Clients zu finden, Anbieter anzusprechen, Runbooks zu aktualisieren und Monitoring zu prüfen. Warnungen können der Ablehnung vorausgehen; die Ablehnung kann erst später greifen; ein dokumentiertes Ausnahmeverfahren kann echte Abhängigkeiten auffangen, ohne den vorläufigen Weg stillschweigend dauerhaft zu machen. Die Quellen sagen nicht, dass ARIN diese Kontrollen gewählt hat. Es sind übliche Bausteine, wenn die Kompatibilitätsfolgen über die implementierende Organisation hinausreichen.

Was „geschlossen“ bedeutet

Der Vorschlag von 2022 verlangte eine sicherere Methode für REST-Authentifizierung. ARIN stellte sie bereit und schloss den Vorgang. In diesem engen Sinn ist der Status korrekt. Ein Vorgangsstatus misst aber keine Migration. Er belegt die Umsetzung der Alternative; er sagt nicht, wie viele Clients das alte Format verwenden, welche Vorlaufzeit gilt oder wann die Kompatibilität endet.

Für ARIN-Kunden ist die praktische Folgerung schlicht: Neue und gepflegte Clients sollten den Header verwenden; die URL-Unterstützung ist als Kompatibilität zu behandeln, nicht als gleichwertige Sicherheitsoption. Für ARIN bleibt die Governance-Aufgabe, eine künftige Abschaltung so transparent zu machen, dass aus einer Empfehlung ein koordinierter Wechsel wird. Die Quellen rechtfertigen weder einen Vorwurf wegen einer Offenlegung noch eine Schuldzuweisung. Sie rechtfertigen die Frage, welches öffentliche Signal den Start der zweiten Uhr markieren wird.

Quellen