Zusammenfassung

  • RFC 9918 behält die gegenseitige X.509-Authentisierung für NETCONF über TLS bei und warnt davor, einer CA zugleich Zertifikate für NETCONF-Berechtigte und andere Zwecke ausstellen zu lassen.
  • Pfadvalidierung, Dienstidentität, geordnete Zertifikat-zu-Benutzer-Abbildung, NACM, RPC, Datastore-Commit und Gerätewirkung sind getrennte Beweisschichten.
  • Eine belastbare Änderungsspur beginnt bei Zertifikat und Mapping-Regel und endet erst bei bestätigtem Zustand und unabhängig beobachteter Wirkung.

Der praktische Prüfpunkt liegt nicht im Schloss-Symbol einer TLS-Verbindung, sondern in der Ausgabeliste der CA. Welche Personen, Dienste und Maschinen können von ihr ein Zertifikat erhalten? Und deckt sich diese Menge tatsächlich mit den Parteien, die einen NETCONF-Server betreten dürfen?

RFC 9918 aktualisiert den TLS-Transport für NETCONF. Für TLS 1.2 bleibt gegenseitige Authentisierung vorgeschrieben; bei TLS 1.3 wird sie empfohlen und bevorzugt, wenn sie verfügbar ist. Early Data ist ausgeschlossen. Verbindungsaufbau, Framing, Beendigung sowie die Identitätsprüfung von Client und Server folgen weiterhin RFC 7589.

Die folgenreichste Passage betrifft jedoch nicht die Chiffren. RFC 9918 empfiehlt, dass CAs in der NETCONF-Vertrauensliste Zertifikate ausschließlich an Parteien ausstellen, die auf NETCONF-Server zugreifen dürfen. Stellt dieselbe CA auch Zertifikate für andere Zwecke aus, könnten diese unangemessen akzeptiert werden. Der Fehler benötigt weder einen gestohlenen privaten Schlüssel noch gebrochene Kryptografie. Eine zu breite Ausgabepopulation genügt.

RFC 5280 beschreibt die X.509-Pfadvalidierung: Signaturen, Gültigkeitszeiträume, Basic Constraints, Richtlinien, Vertrauensanker und verfügbare Sperrinformationen. Das sind notwendige Nachweise für den Zertifizierungspfad. Sie besagen für sich allein nicht, dass die lokale Netzverwaltung dem Endteilnehmer eine Rolle eingeräumt hat. Ein Trust Store ist kein Berechtigungsverzeichnis.

Nach der Pfadprüfung muss der NETCONF-Server aus dem Zertifikat einen Benutzernamen gewinnen. RFC 7589 legt dafür eine geordnete Liste von Abbildungsregeln fest. Eine Regel kann den Fingerabdruck des Endzertifikats oder den Fingerabdruck einer vertrauenswürdigen CA im Pfad treffen. Anschließend liefert sie entweder einen fest konfigurierten Namen oder leitet ihn etwa aus rfc822Name, dNSName, IP-Adresse, dem ersten unterstützten subjectAltName oder – als veralteter, nicht bevorzugter Weg – aus Common Name ab.

Die Reihenfolge ist wirksame Konfiguration. Eine breite CA-Regel vor einer präzisen Endzertifikat-Regel kann aus demselben kryptografischen Material einen anderen NETCONF-Namen erzeugen. Trifft eine Regel, kann aber keinen gültigen Namen erzeugen, wird die Suche fortgesetzt; ohne erfolgreiche Regel endet die Sitzung. RFC 7407 modelliert diese Oberfläche in YANG. Deshalb gehören Version, Reihenfolge und aktive Werte der Mapping-Liste in jede forensisch brauchbare Aufzeichnung.

Ein Audit sollte den Fingerabdruck des Endzertifikats und der Kette, Prüfzeitpunkt, Anker, Richtlinien und Sperrstatus festhalten. Danach folgen Nummer und Typ der getroffenen Regel, Treffer auf Endzertifikat oder CA, verwendetes Namensfeld und resultierender Benutzername. Der Logeintrag „Zertifikat akzeptiert“ komprimiert genau jene Entscheidungen weg, die später über die Reichweite des Vertrauens Auskunft geben würden.

Auch ein Benutzername ist noch keine Autorisierung. RFC 6241 verlangt, dass die Transportschicht eine authentisierte Identität übergibt und der Server deren Berechtigungen während der Sitzung kennt und durchsetzt. RFC 8341 stellt mit NACM eine weitere, eigenständige Entscheidungsfläche bereit: Benutzer, Gruppen, Operation, Ziel-Daten oder Aktion sowie die zum Verarbeitungsbeginn geltenden Regeln.

Darum kann ein einwandfreies Zertifikat zu einem abgelehnten RPC führen. Derselbe Benutzer kann für eine Leseoperation zugelassen und für eine Schreiboperation abgelehnt werden. Authentisierung leiht sich nicht das Ergebnis der Autorisierung; die Autorisierung schreibt rückwirkend nicht den Zertifizierungspfad um. Diese Trennung ist kein Formalismus, sondern die Voraussetzung, um einen Erfolg oder eine Ablehnung erklären zu können.

Selbst ein akzeptiertes <edit-config> beweist noch keine Änderung im Netz. Die Message-ID verbindet Anfrage und Antwort. Die Wahl von candidate oder running, Sperren, Validierung, Commit oder Confirmed Commit und das anschließende Auslesen belegen den Datastore-Zustand. Ob das Gerät die Konfiguration übernommen hat, ob die Weiterleitung sich geändert hat und ob der Dienst wie beabsichtigt reagiert, muss zusätzlich gemessen werden. Ein <ok> ist keine Verkehrsbeobachtung.

Die serverseitige Identität folgt derselben Disziplin. RFC 9525 verlangt, dass der Client seine zulässigen Referenzidentitäten unabhängig von den vom Server angebotenen Identifikatoren bildet und dann nach einer Übereinstimmung sucht. Pfadgültigkeit, Sperrstatus und die Autorität, den Dienst zu repräsentieren, bleiben getrennte Fragen. RFC 9325 gibt aktuelle TLS-Empfehlungen. RFC 9846 erläutert die schwächeren Eigenschaften von Early Data. Dessen Verbot verhindert NETCONF-Operationen vor abgeschlossener Authentisierung, verkleinert aber keine CA mit gemischtem Zweck.

IANA führt netconf-tls auf TCP-Port 6513 und verweist auf RFC 7589 sowie RFC 9918. Die Registrierung belegt Namen und Portzuweisung. Sie belegt weder einen lauschenden Dienst noch zugelassene Quellnetze, TLS-Version, Mapping-Regel, NACM-Entscheid oder eine Änderung des Datenpfads.

Heng Lus Gedanke einer minimalen Anfangsspezifikation unterstützt eine kleine gemeinsame Regel, deren Einhaltung lokal überprüfbar bleibt, ohne lokale Berechtigung als globale Wahrheit auszugeben. Running Code als Primat gibt den reproduzierbaren Belegen aus Kette, Mapping, NACM, RPC und Datastore mehr Gewicht als dem Etikett „vertrauenswürdig“. Die Realitätsschichten verhindern, dass PKI-Gültigkeit, Identität, Autorität und Wirkung einander Gewissheit leihen. Diese Bezüge sind offengelegte redaktionelle Linsen, keine zusätzlichen IETF-Anforderungen.

Die operative Konsequenz ist eng, aber anspruchsvoll: Eine CA braucht einen sichtbaren Zweck und eine bekannte Ausgabepopulation. Wer beides nicht begrenzen kann, muss die nachgelagerten Mapping- und Autorisierungskontrollen entsprechend präziser machen. Erst wenn der erzeugte Name, die damalige Berechtigung, die Operation, der Commit und die Wirkung gemeinsam rekonstruierbar sind, wird aus einer erfolgreichen TLS-Verbindung eine belastbare Änderungsspur.

Quellen