Zusammenfassung

  • Mit den neuen Policy- und Erweiterungs-OIDs von RFC 8360 kann eine unterstützende Relying Party den Verified Resource Set berechnen und bei einer Überbeanspruchung mit dem nachgewiesenen Teil des CA-Zertifikats weiterarbeiten.
  • Der überschüssige Teil wird nie gültig: Sämtliche Präfixe einer ROA und ASNs eines Router-Zertifikats müssen im jeweiligen VRS liegen; Zertifikate des alten RFC-6487-Profils werden weiterhin vollständig zurückgewiesen.

Warum ein Verwaltungsfehler einen Baum traf

RPKI-Ressourcenzertifikate binden öffentliche Schlüssel an IP-Adressblöcke und Nummern autonomer Systeme. Eine untergeordnete CA kann nur weitergeben, was ihr Aussteller im validierten Pfad bis zum Trust Anchor selbst nachweislich überlassen hat. RFC 3779 definierte die Ressourcenerweiterungen, RFC 6487 das RPKI-Zertifikatsprofil und dessen Validierung.

Das frühe Verfahren setzte eine harte Grenze. Beanspruchte ein CA-Zertifikat auch nur eine Ressource außerhalb des gültigen Bestands seines Ausstellers, war das gesamte Zertifikat abzulehnen. Alle darunterliegenden Zertifikate und signierten Objekte verloren damit ihren Pfad — selbst wenn sie ausschließlich korrekt delegierte Ressourcen betrafen.

Eine solche Überbeanspruchung muss kein Angriff sein. Nach einem Ressourcentransfer kann der Bestand des Elternteils bereits geschrumpft sein, während das Kind sein Zertifikat noch nicht erneuert hat. Verwaltungs- und Ausgabedatenbanken können vorübergehend auseinanderlaufen. RFC 8360 stufte die Wahrscheinlichkeit 2018 als gering, die mögliche Wirkung aber als hoch ein. Nahe am oberen Rand der Hierarchie vergrößert jeder Nachfahre den Ausfallradius.

Geoff Huston, George Michaelson, Carlos Martinez, Tim Bruijnzeels, Andrew Newton und Donald Shaw verfassten RFC 8360 gemeinsam. Ihr alternativer Algorithmus trennt die behauptete von der nachgewiesenen Menge. Der Validator bildet entlang des Zertifizierungspfads den Verified Resource Set, kurz VRS, und verwendet nur die Ressourcen, die jede relevante Stufe trägt.

Verifizieren heißt schneiden, nicht ergänzen

IP- und AS-Ressourcen werden getrennt behandelt. VRS-IP ist die Schnittmenge der gültigen Adressressourcen; VRS-AS die der AS-Nummern. Ohne Überbeanspruchung liefern altes und neues Verfahren dasselbe Resultat. Mit Überbeanspruchung markiert die Differenz genau das, was nicht genutzt werden darf.

Die Alternative ist durch das Zertifikat selbst signalisiert. RFC 8360 führt eine Zertifikatspolicy der Version 2 und neue OIDs für Ressourcenerweiterungen ein. Verwendet das Zertifikat sie, warnt eine kompatible Relying Party über die überzähligen Ressourcen und setzt die Prüfung mit dem VRS fort. Verwendet es weiterhin die Policy aus RFC 6487, erzwingt die Abweichung die Ablehnung. Es gibt keine stillschweigende Lockerung für Altbestände.

Auch ein leerer VRS erweitert die Befugnisse nicht. Das CA-Zertifikat muss allein deshalb nicht sofort verworfen werden, weil der Zustand vorübergehend sein kann. Aus der leeren Menge lässt sich jedoch kein einziges gültiges untergeordnetes Ressourcenobjekt ableiten. Sichtbarkeit im Baum ist keine Ersatzberechtigung.

Im Beispiel des Standards beansprucht eine Kind-CA das gedeckte Netz 192.0.2.0/24 und zusätzlich das ungedeckte 198.51.100.0/24. Der VRS behält das erste und entfernt das zweite. Eine ROA für das erste Netz kann gültig sein; eine für das zweite nicht. Die erhaltene Verfügbarkeit liegt vollständig innerhalb der bestehenden Delegation.

Jedes signierte Objekt behält seine Grenze

Ein fortbestehendes CA-Zertifikat nimmt seinen Nachfahren die Prüfung nicht ab. RFC 6482 definiert die ROA; RFC 8360 verlangt, dass jedes darin genannte Präfix im VRS-IP des End-Entity-Zertifikats liegt. Eine ROA, die eine gültige und eine ausgeschlossene Ressource bündelt, kann somit insgesamt scheitern.

Daraus folgt eine praktische Möglichkeit zur Isolierung. Getrennte ROAs für unabhängige Präfixe verhindern, dass der Verlust eines Netzes andere Origin-Autorisierungen unnötig mitreißt. Bei BGPsec-Router-Zertifikaten gilt dasselbe Muster für VRS-AS: Alle beanspruchten ASNs müssen umfasst sein, und getrennte Zertifikate pro ASN können den Schaden begrenzen.

Der Algorithmus bleibt außerdem innerhalb eines Trust Anchors. Überlappende Ansprüche mehrerer Trust Anchors sind ausdrücklich nicht sein Gegenstand. Ebenso wenig verwandelt er eine lokale Präferenz der Relying Party in kryptografischen Besitz. Er verkleinert den Fehlerbereich in einem validierten Pfad, nicht die Anforderungen an dessen Autorität.

Zuerst müssen die Leser den neuen Typ verstehen

Neue OIDs schaffen eine Kompatibilitätsgrenze. Eine ältere Relying-Party-Software, die das alternative Profil nicht kennt, weist entsprechende Zertifikate ab. RFC 8360 verlangt deshalb, die Validatoren zu aktualisieren, bevor CAs die neuen OIDs einsetzen. Dass ein Herausgeber ein Zertifikat erzeugen kann, sagt nichts über dessen Verständlichkeit bei den Konsumenten.

Die Umstellung darf dennoch selektiv erfolgen. Das Profil wird pro Zertifikat gewählt. Ein Root-Zertifikat kann bei der alten Policy bleiben, während eine untergeordnete CA die neue nutzt, sofern die Validatoren sie beherrschen. So lässt sich die Eindämmung zuerst dort einführen, wo ein Fehler besonders viele Nachfahren erreichen würde.

RFC 8488 hält eine Implementierungssicht aus dem Jahr 2018 fest. Die damalige Beschreibung des RIPE NCC Validators nennt eine vom Betreiber wählbare strikte Validierung und außerhalb dieses Modus ein konfiguriertes alternatives Verhalten. Das ist historische Evidenz für ein Produktdesign, keine Aussage über heutige Voreinstellungen und kein Ersatz für die normativen OID-Regeln von RFC 8360.

Bruijnzeels und seine Mitautoren machten die Prüfung nicht nachsichtiger, sondern genauer. Der Fehler bleibt als Warnung erhalten. Nicht gehaltene Ressourcen bleiben unbrauchbar. Korrekt geerbte Ressourcen müssen aber nicht mehr aus bloßer Nachbarschaft verschwinden. Die Vertrauenskette wird nicht breiter; ihr Ausfallradius wird kleiner.

Quellen