Zusammenfassung

  • RFC 9950 erlaubt, Client- und Server-Credentials zentral zu provisionieren und an einzelnen TACACS+-Servern zu referenzieren oder lokal auszuformulieren.
  • Eine Referenz beschreibt eine beabsichtigte Sicherheitsbeziehung und ihre Verwaltung; sie ersetzt weder die Prüfung im konkreten Austausch noch die lokale Autorisierungsentscheidung.

Referenzen sind in der Konfiguration gerade deshalb wertvoll, weil sie Wiederholung vermeiden. Das TACACS+-Modell aus RFC 9950 kann Client-Credentials und Server-Credentials am oberen Rand des tacacs-plus-Containers anlegen. Ein einzelner Server kann auf diese Sätze verweisen oder die Client-Identität und Server-Authentisierung unmittelbar unter sich festlegen. Damit wird sichtbar, welche Identitäts- und Prüfmaterialien für künftige TLS-Verbindungen vorgesehen sind.

Sichtbarkeit ist jedoch kein erfolgreiches Vertrauen. Ein Credentials-Verweis sagt noch nicht, ob das referenzierte Material korrekt provisioniert, zum Ziel passend, aktuell oder beim nächsten Verbindungsversuch akzeptiert wird. Er sagt ebenso wenig, welche TACACS+-Richtlinie nach einer geschützten Verbindung gilt. RFC 9950 trennt schon in seiner Einordnung Authentisierung, Autorisierung und Accounting: Eine Nutzerprüfung, ein Privilegentscheid und die Aufzeichnung von Aktivität sind nicht derselbe Protokollakt.

RFC 9887 verlangt für TACACS+ über TLS mindestens TLS 1.3 und gegenseitige Authentisierung. RFC 9950 bildet passende Client-Identitäten, Server-Authentisierung, Domainnamen und SNI ab. Das ist ein wichtiger Schritt, um die Beziehung zum TLS-Peer sauber zu konfigurieren. Aber ein TLS-Peer ist nicht automatisch ein politischer Entscheider für jede angeforderte Aktion. Die Bestätigung einer Zertifikatskette beantwortet eine andere Frage als die Zuweisung einer Kommandoebene oder die Feststellung, ob eine bestimmte Aktion ausgeführt wurde.

Das Modell hält auch die alte gemeinsame Geheimnis-Variante fest, weil es installierte Bestände gibt. Es bezeichnet diese Wahl ausdrücklich als Obfuskation ohne nennenswerten Integritäts-, Datenschutz- oder Replay-Schutz und empfiehlt TLS. Die Existenz eines shared-secret ist daher kein Qualitätsstempel. Gerade weil es eine sensible Steuerung der Verbindung erlaubt, schützt RFC 9950 es mit nacm:default-deny-all.

Die Referenzen selbst sind ebenfalls besonders geschützt: Client-Identität und Server-Authentisierung erhalten default-deny-write. RFC 8341 erklärt, wie NACM Nutzer von NETCONF oder RESTCONF auf einen vorkonfigurierten Teil von Operationen und Inhalten beschränken kann. Diese Zugriffssteuerung schützt, wer eine künftige Sicherheitsbeziehung ändern darf. Sie kann nicht aus einer zulässigen Konfigurationsänderung ableiten, dass die spätere Remote-Policy richtig, gerechtfertigt oder erfolgreich umgesetzt war.

Eine saubere Betriebsansicht verbindet deshalb vier Belege nicht zu einem: die Version der referenzierten Credentials, den Zustand des konkreten TLS-Austauschs, den AAA-Entscheid mit seinem lokalen Kontext und die beobachtete Folgeaktion. RFC 9950 liefert den ersten Teil und Teile des zweiten. Die übrigen müssen dort festgehalten werden, wo sie tatsächlich entstehen.