RFC 9887 - Technische Zusammenfassung (Deutsche Version)

Dokument: Terminal Access Controller Access-Control System Plus (TACACS+) über TLS 1.3
RFC-Nummer: 9887
Veröffentlichungsdatum: Dezember 2025
Status: PROPOSED STANDARD
Aktualisiert: RFC 8907

Schnellreferenz

Kritische Anforderungen (MUST)

Anforderung	Spezifikation	Abschnitt
TLS-Version	TLS 1.3 mindestens	3.2
Portnummer	TCP 300 für TLS	3.1, 7
Authentication	Gegenseitig (Client + Server)	3.1
Zertifikatsvalidierung	Vollständiger Pfad + Widerruf	3.4.1
Obfuscation	DARF NICHT mit TLS verwendet werden	4
Unencrypted-Flag	MUSS auf 1 gesetzt sein	4
0-RTT-Daten	DÜRFEN NICHT gesendet werden	5.1.2
Fallback	DARF NICHT auf Nicht-TLS	5.1.1

Unterstützte Authentication-Methoden

Zertifikatsbasiert (MANDATORY)
- X.509-Zertifikate mit vollständiger Kettenvalidierung
- Widerrufsüberprüfung erforderlich
- DNS-ID, IP-ID oder SRV-ID für die Serveridentität
- Unterstützung der SNI-Erweiterung erforderlich
Pre-Shared Keys (PSK) (OPTIONAL)
- Externe PSKs (keine Resumption-PSKs)
- Mindestlänge 16 Oktette
- MÜSSEN sich von Obfuscation-Shared-Secrets unterscheiden
Raw Public Keys (RPK) (OPTIONAL)
- Liegen außerhalb des Geltungsbereichs dieses Dokuments
- Siehe RFC 7250 für Details

Portzuweisung

Dienst	Port	Protokoll	Verwendung
TACACS+ (Legacy)	49	TCP	Verbindungen ohne TLS
TACACS+ über TLS	300	TCP	Verbindungen mit TLS 1.3+

IANA-Registrierung: Dienstname „tacacss“ auf Port 300/TCP

TLS-Konfigurationsanforderungen

Obligatorische Cipher Suites

Obligatorische TLS-1.3-Suites (RFC 8446 Abschnitt 9.1)
Sollten durch Betreiber konfigurierbar sein

Zertifikatsanforderungen

Pfadvalidierung: RFC 5280 Abschnitt 6
Identitätsvalidierung: RFC 9525
Widerruf: Muss bei Erstverbindung und Resumption geprüft werden
SNI: Muss unterstützt werden (RFC 6066 Abschnitt 3)

Verbotene Funktionen

❌ TLS-Versionen < 1.3
❌ 0-RTT Early Data
❌ Upgrade von Nicht-TLS
❌ MD5-basierte Obfuscation
❌ Fallback auf Nicht-TLS

Verbindungslebenszyklus

Client                                    Server
  |                                          |
  |--- TCP-Verbindung zu Port 300 --------->|
  |                                          |
  |<-- TLS-1.3-Handshake (mutual Authentication) ----->|
  |                                          |
  |--- TACACS+-Daten (TLS-Anwendungsdaten) >|
  |<-- TACACS+-Antwort ----------------------|
  |                                          |
  |--- Schließen (nach Sitzung oder Timeout) >|

Verbindungsmodi

Single-Connection-Modus (RFC 8907 Abschnitt 4.3)
- Mehrere TACACS+-Sitzungen über eine TLS-Verbindung
- Unterliegen Inaktivitäts-Timeout
- Verbindung kann kurz bestehen bleiben
Nicht-Single-Connection-Modus
- Eine TACACS+-Sitzung pro TLS-Verbindung
- TCP wird nach Abschluss der Sitzung geschlossen

TLS-Resumption

Ticket-Lebensdauer: Sollte konfigurierbar sein (einschließlich 0 Sekunden)
Einmalige Verwendung: Jedes Ticket nur für eine Resumption
Widerrufsüberprüfung: Während der Resumption erforderlich
Serververhalten: Sollte erlauben, wenn Ticket gültig und unbenutzt

Zusammenfassung Sicherheitsaspekte

Adressiertes Bedrohungsmodell

Bedrohung	Gegenmaßnahme
Abhören	TLS-1.3-Verschlüsselung
Man-in-the-Middle	Gegenseitige Authentication
Wiederholungsangriffe	Kein 0-RTT, Nonce-Mechanismen
Downgrade-Angriffe	Getrennte Ports, kein Fallback
Schwache Kryptografie	MD5 obsolet, nur TLS 1.3

Sicherheit im Betrieb

Trennung von TLS und Nicht-TLS
- EMPFOHLEN: Getrennte physische Hosts
- MUSS: Getrennte Portnummern
- Verhindert Exposition durch Fehlkonfiguration
Zertifikatsmanagement
- BCP 195 (RFC 7525) befolgen
- Wildcard-Zertifikate: auf dedizierte Subdomain beschränken
- CA-Erreichbarkeit: Planung bei Netzwerkisolierung
Konfigurationsklarheit
- Explizite TLS-/Nicht-TLS-Modusindikatoren
- Validierungswarnungen bei Port-Mismatch
- Getrennte Konfigurationsabschnitte

Migrationsstrategie (5 Phasen)

Phase 1: Bewertung

Inventur aller TACACS+-Clients und -Server
TLS-fähige vs. Legacy-Geräte identifizieren
Änderungen der Netzwerktopologie planen

Phase 2: Pilot

TLS-Server auf Port 300 in Testumgebung bereitstellen
Test-Clients konfigurieren
Zertifikatsinfrastruktur validieren

Phase 3: Erste Ausrollung

Teilmenge der Produktions-Clients migrieren
Auf Probleme überwachen
Parallele Nicht-TLS-Infrastruktur aufrechterhalten

Phase 4: Schrittweises Rollout

Verbleibende Clients schrittweise migrieren
Ausnahmen für Legacy-Geräte dokumentieren
Kompensationskontrollen für Nicht-TLS umsetzen

Phase 5: Abschluss

Nicht-TLS-Infrastruktur außer Betrieb nehmen
Abschließendes Sicherheitsaudit
Dokumentation aktualisieren

Kritische Regel: Clients DÜRFEN NICHT auf Nicht-TLS zurückfallen, wenn TLS fehlschlägt

Implementierungs-Checkliste

Server-Implementierung

Client-Implementierung

Hinweise zur Referenzimplementierung

Zertifikats-Identitätsvalidierung

Akzeptable Identifikatortypen:
- DNS-ID: tacacs.example.com
- IP-ID: 192.0.2.1 oder 2001:db8::1
- SRV-ID: _tacacs._tcp.example.com

NICHT akzeptabel:
- URI-ID (wird für TACACS+ nicht verwendet)

Wildcard-Zertifikate

✅ GUT: *.tacacs.example.com (dedizierte Subdomain)
❌ SCHLECHT: *.example.com (zu breit)

PSK-Identitätsformat

- Mindestlänge: 16 Oktette
- RFC 9257 Abschnitt 6.1 befolgen
- Muss sich von Obfuscation-Secrets unterscheiden

Betriebsliche Best Practices

Monitoring
- Alle TLS-Handshake-Fehler protokollieren
- Alarm bei Nicht-TLS-Verbindungsversuchen auf Port 300
- Ablaufdaten von Zertifikaten verfolgen
Zertifikats-Lebenszyklus
- Erneuerung automatisieren (z. B. ACME-Protokoll)
- Zertifikatsketten lokal vorhalten
- Planung für CA-Ausfälle
Tests
- Regelmäßige TLS-Konfigurationsaudits
- Cipher-Suite-Kompatibilitätstests
- Validierung von Failover-Szenarien
Dokumentation
- Inventar von TLS- vs. Nicht-TLS-Servern pflegen
- Migrationszeitplan dokumentieren
- Vertrauensanker der Zertifikate festhalten

Compliance-Anforderungen

FIPS 140-3

TLS 1.3 mit zugelassenen Cipher Suites
MD5-Obfuscation obsolet (nicht konform)
Zertifikatsbasierte Authentication empfohlen

Branchenstandards

PCI DSS: Starke Kryptografie erforderlich
NIST SP 800-52: TLS-Richtlinien
BCP 195: TLS-Best Practices

Häufige Fallstricke

❌ Port-Mismatch: TLS-Client verbindet zu Port 49
❌ Fallback-Logik: Nicht-TLS nach TLS-Fehler versuchen
❌ Gemischte Secrets: Dieselben Schlüssel für Obfuscation und PSK
❌ 0-RTT aktiviert: Early Data senden
❌ Zertifikatsvalidierung deaktiviert: Ungültige Zertifikate akzeptieren
❌ Gleicher Host: TLS und Nicht-TLS auf demselben Server
❌ Wildcard-Missbrauch: *.example.com für alle Dienste
❌ Keine Widerrufsüberprüfung: CRL/OCSP-Validierung überspringen

Leistungsaspekte

TLS-Handshake-Overhead

Voller Handshake: ~2 RTT (TLS 1.3)
Resumption: ~1 RTT
Gegenmaßnahme: Resumption bei wiederholten Verbindungen nutzen

Verbindungspersistenz

Single-Connection-Modus reduziert Handshake-Häufigkeit
Balance zwischen Verbindungswiederverwendung und Timeout-Einstellungen
Typischer Timeout: 60–300 Sekunden

Zertifikatsvalidierung

Validierte Zertifikate cachen
OCSP-Stapling zur Latenzreduzierung nutzen
TLS Cached Information Extension (RFC 7924) erwägen

Fehlerbehebung

Symptom	Mögliche Ursache	Lösung
Verbindung verweigert	Falscher Port	Client auf Port 300 prüfen
Handshake-Fehler	TLS-Versions-Mismatch	TLS-1.3-Unterstützung sicherstellen
Zertifikatsfehler	Ungültige Zertifikatskette	CA-Vertrauen und Zertifikatsgültigkeit prüfen
Authentication fehlgeschlagen	Problem gegenseitiger Authentication	Client- und Serverzertifikate prüfen
TAC_PLUS_UNENCRYPTED_FLAG-Fehler	Flag nicht gesetzt	Client setzt Flag auf 1
Resumption abgelehnt	Ticket abgelaufen/benutzt	Normal; voller Handshake folgt

Zukünftige Aspekte

YANG-Datenmodell

Standardisiertes Konfigurationsmodell erforderlich
Würde Automatisierung und Konsistenz unterstützen
Sollte TLS-spezifische Parameter enthalten

Protokollerweiterungen

Dieses Dokument fokussiert TLS 1.3
Zukünftige TLS-Versionen werden voraussichtlich funktionieren
IETF TLS WG auf Updates beobachten

IPv6-Einsatz

Keine Änderungen an IPv6-Empfehlungen
TLS verhält sich über IPv4 und IPv6 gleich
IP-ID für IP-basierte Zertifikatsidentität nutzen

Kurzer Entscheidungsbaum

Benötigen Sie TACACS+-Sicherheit?
├─ JA → TLS nutzen (dieser RFC)
│   ├─ Moderne Geräte → Zertifikatsbasierte Authentication
│   ├─ Eingeschränkte Geräte → PSK erwägen
│   └─ Legacy-Geräte → Getrennte Nicht-TLS-Infrastruktur
│
└─ NEIN → Prüfen, ob TACACS+ passend ist
    └─ Hochsicherheitsumgebungen erfordern TLS

Dokumentstatus

Standards Track: Ja
Implementierung erforderlich: Für neue Einsätze
Abwärtskompatibilität: Paralleler Betrieb während der Migration
Obsoletisiert: Nur MD5-Obfuscation-Mechanismus
Aktualisiert: RFC 8907 (fügt TLS-Profil hinzu)

Zuletzt aktualisiert: 26. Dezember 2025
Dokumentversion: 1.0 (vollständige deutsche Version)
Gepflegt von: RFC-Übersetzungsprojekt

Schnellreferenz​

Kritische Anforderungen (MUST)​

Unterstützte Authentication-Methoden​

Portzuweisung​

TLS-Konfigurationsanforderungen​

Obligatorische Cipher Suites​

Zertifikatsanforderungen​

Verbotene Funktionen​

Verbindungslebenszyklus​

Verbindungsmodi​

TLS-Resumption​

Zusammenfassung Sicherheitsaspekte​

Adressiertes Bedrohungsmodell​

Sicherheit im Betrieb​

Migrationsstrategie (5 Phasen)​

Phase 1: Bewertung​

Phase 2: Pilot​

Phase 3: Erste Ausrollung​

Phase 4: Schrittweises Rollout​

Phase 5: Abschluss​

Implementierungs-Checkliste​

Server-Implementierung​

Client-Implementierung​

Hinweise zur Referenzimplementierung​

Zertifikats-Identitätsvalidierung​

Wildcard-Zertifikate​

PSK-Identitätsformat​

Betriebsliche Best Practices​

Compliance-Anforderungen​

FIPS 140-3​

Branchenstandards​

Häufige Fallstricke​

Leistungsaspekte​

TLS-Handshake-Overhead​

Verbindungspersistenz​

Zertifikatsvalidierung​

Fehlerbehebung​

Zukünftige Aspekte​

YANG-Datenmodell​

Protokollerweiterungen​

IPv6-Einsatz​

Kurzer Entscheidungsbaum​

Verwandte RFCs​

Dokumentstatus​