Zusammenfassung

  • RIPE NCC stellt sein RPKI-Dashboard auf OpenID Connect um und hat begonnen, die heutigen API-Schlüssel durch OIDC-basierte, in RIPE NCC Access integrierte Schlüssel zu ersetzen. Das Vorhaben ist noch in Arbeit.
  • Eine getrennte Beacon-Initiative wurde nicht umgesetzt, weil die verwendete API ROA-Änderungen für den gesamten RIPE-NCC-Adressraum ermöglicht hätte. Sichere Identität und begrenzte Änderungsmacht sind unterschiedliche Anforderungen.

Ein Zugang kann eindeutig einer Person zugeordnet, mit einem zweiten Faktor geschützt und sauber widerrufen werden. Trotzdem kann er zu mächtig sein. Gerade bei automatisierten Änderungen an Routing-Autorisierungen entscheidet deshalb nicht nur die Qualität der Anmeldung, sondern der kleinste nachweisbare Wirkungsbereich.

RIPE NCC hat am 17. September seinen RPKI-Plan für das vierte Quartal 2026 aktualisiert. Darin kündigt die Organisation an, das Dashboard über RIPE NCC Access mit OpenID Connect auszustatten. Zugleich läuft die Arbeit, bestehende RPKI-API-Schlüssel durch OIDC-basierte und in das SSO integrierte Schlüssel zu ersetzen. Deren Verwaltung soll im Dashboard erfolgen. Weitere Angaben zu Umsetzung und Zeitplan sind für ein kommendes RIPE Meeting vorgesehen. Der Status lautet ausdrücklich „in Arbeit“.

Der Schritt kann die Betriebssicherheit verbessern. RIPE NCC Access verlangt Zwei-Faktor-Authentifizierung. Nach der veröffentlichten Sicherheitsrichtlinie sind API-Schlüssel einem konkreten Benutzerkonto zugeordnet, höchstens ein Jahr gültig und werden deaktiviert, wenn das SSO-Konto abgeschaltet oder die Maintainer-Rolle im zuständigen System entzogen wird. Eine gemeinsame Verwaltung macht Eigentum, Ablauf und Widerruf besser sichtbar.

OIDC löst jedoch zunächst ein Identitätsproblem. Der Standard beschreibt eine Identitätsschicht über OAuth 2.0, mit der ein Client eine erfolgte Authentifizierung und die zugehörigen Angaben prüfen kann. Daraus folgt noch nicht, ob ein automatischer Client nur lesen, Änderungen vormerken oder veröffentlichen darf. Ebenso wenig legt OIDC fest, auf welchen LIR, welches Zertifikat oder welche Präfixe sich die Rechte beziehen.

Auch OAuth trennt mehrere Dimensionen. Ein Resource Indicator benennt den geschützten Dienst, für den ein Token bestimmt ist. Scopes beschreiben die beantragte Zugriffsart. Aktuelle Sicherheitsempfehlungen fordern eine enge Audience. Doch ein Token, das ausschließlich beim RPKI-Dienst akzeptiert wird, kann innerhalb dieses Dienstes weiterhin zu viele Ressourcen erreichen. Diese Grenze muss die Anwendung setzen.

Warum das relevant ist, zeigt der zweite Vorgang auf derselben Seite. Aus der Community kam der Wunsch nach einer bekannten Routing-Beacon mit wechselnder RPKI-Gültigkeit. RIPE NCC setzte sie nicht um, weil die dazu genutzte API ROAs im gesamten RIPE-NCC-Adressraum hätte bearbeiten können. Das sei nicht akzeptabel; gemeinsam mit dem RIS-Team soll ein anderer Weg gesucht werden.

Daraus darf kein Vorwurf gegen das noch nicht veröffentlichte OIDC-Design werden. Die Beacon-API ist ein eigener Fall, und es gibt keinen Beleg dafür, dass künftige Mitgliedsschlüssel dieselbe Reichweite erhalten. Belegt ist aber, dass RIPE NCC übermäßige Änderungsrechte als Grund anerkennt, eine nützliche Funktion zu stoppen.

Bei ROAs ist das folgerichtig. Ein signiertes ROA-Objekt autorisiert ein Ursprung-AS, ein Präfix anzukündigen, optional bis zu einer maximalen Länge. Der gehostete Dienst bildet daraus Konfigurationen mit jeweils einem Ursprung-AS, einem Präfix und einer Maximallänge und übernimmt Signatur, Veröffentlichung und Erneuerung. Über die heutige API lassen sich mehrere ROAs in einem Aufruf hinzufügen oder löschen.

Bestehende Schutzmechanismen liefern Bausteine für die Umstellung. Wer ein nicht gehaltenes Präfix bearbeiten will, erhält laut Dokumentation eine 403-Antwort. Im Dashboard können Änderungen vorgemerkt, betroffene BGP-Ankündigungen geprüft und anschließend gemeinsam angewendet werden. Die API kann auch die Wirkung eines noch nicht existierenden ROA berechnen.

Die Beweiskette muss deshalb getrennt bleiben: Identität des Principals, Audience des Tokens, erlaubte Aktion, zugelassene Ressourcen, Annahme der Änderung, Veröffentlichung des Objekts, Abruf durch Validatoren, lokale Router-Policy und beobachtetes BGP-Ergebnis. Ein erfolgreicher Login belegt weder eine Veröffentlichung noch eine Routenwirkung.

Als redaktionelle Linse dienen Heng Lus Überlegungen zur minimalen Anfangsspezifikation, zu Realitätsebenen und zum Principal-Agent-Problem der Internet-Governance. Auf RPKI übertragen sprechen sie für enge Ausgangsrechte und spätere Entscheidungen nahe an der betroffenen Ressource. Das ist keine RIPE-NCC-Position.

Quellen