Zum Hauptinhalt springen

4. Veraltung der TACACS+-Verschleierung (Obsolescence of TACACS+ Obfuscation)

Der in Abschnitt 4.5 von [RFC8907] dokumentierte Verschleierungsmechanismus ist schwach.

Die Einführung von TLS-Authentifizierung und -Verschlüsselung in TACACS+ ersetzt diesen früheren Mechanismus, daher wird die Verschleierung hiermit als veraltet erklärt. Dieser Abschnitt beschreibt, wie TACACS+-Clients und -Server in Bezug auf den Verschleierungsmechanismus funktionieren MÜSSEN.

Peers DÜRFEN NICHT (MUST NOT) Verschleierung mit TLS verwenden.

Ein TACACS+-Client, der eine TACACS+ TLS-Verbindung initiiert, MUSS (MUST) das TAC_PLUS_UNENCRYPTED_FLAG-Bit setzen und damit bekräftigen, dass für die Sitzung keine Verschleierung verwendet wird. Alle nachfolgenden Pakete MÜSSEN (MUST) das TAC_PLUS_UNENCRYPTED_FLAG-Bit auf 1 gesetzt haben.

Ein TLS TACACS+-Server, der ein Paket mit dem nicht auf 1 gesetzten TAC_PLUS_UNENCRYPTED_FLAG-Bit über eine TLS-Verbindung empfängt, MUSS (MUST) einen Fehler von TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR oder TAC_PLUS_ACCT_STATUS_ERROR zurückgeben, je nachdem, was für den TACACS+-Nachrichtentyp angemessen ist, mit dem auf 1 gesetzten TAC_PLUS_UNENCRYPTED_FLAG-Bit und die Sitzung beenden.

Ein TACACS+-Client, der ein Paket mit dem nicht auf 1 gesetzten TAC_PLUS_UNENCRYPTED_FLAG-Bit empfängt, MUSS (MUST) die Sitzung beenden und SOLLTE (SHOULD) diesen Fehler protokollieren.

5. Sicherheitsüberlegungen (Security Considerations)

5.1. TLS​

Dieses Dokument verbessert die Vertraulichkeit, Integrität und Authentifizierung der Verbindung und des Netzwerkverkehrs zwischen TACACS+-Peers durch Hinzufügen von TLS-Unterstützung.

Das einfache Hinzufügen von TLS-Unterstützung zum Protokoll garantiert nicht den Schutz des TLS TACACS+-Servers und der Clients. Es ist für die Betreiber und Gerätehersteller unerlässlich, die neuesten Best Practices einzuhalten, um die Integrität von Netzwerkgeräten sicherzustellen und sichere TLS-Schlüssel und Verschlüsselungsalgorithmen auszuwählen.

[BCP195] bietet umfassende Anleitungen für die Implementierung und Bereitstellung von Protokollen, die TLS verwenden. Diejenigen, die Secure TACACS+ implementieren und bereitstellen, müssen die in [BCP195] oder seinen nachfolgenden Versionen beschriebenen Empfehlungen zu TLS 1.3 einhalten.

5.1.1. TLS-Verwendung (TLS Use)​

Neue TACACS+-Produktionsbereitstellungen SOLLTEN (SHOULD) TLS-Authentifizierung und -Verschlüsselung verwenden.

TLS TACACS+-Server (wie in Abschnitt 2 definiert) DÜRFEN (MUST NOT) keine Nicht-TLS-Verbindungen zulassen, wegen der in Abschnitt 5.3 beschriebenen Bedrohung durch Downgrade-Angriffe oder Fehlkonfiguration. Stattdessen SOLLTEN (SHOULD) separate Nicht-TLS TACACS+-Server eingerichtet werden, um diese Clients zu bedienen.

Es wird NICHT EMPFOHLEN (NOT RECOMMENDED), TLS TACACS+-Server und Nicht-TLS TACACS+-Server auf demselben Host bereitzustellen, aus den in Abschnitt 5.3 diskutierten Gründen. Nicht-TLS-Verbindungen würden besser durch Bereitstellung der erforderlichen Nicht-TLS TACACS+-Server auf separaten Hosts bedient.

TACACS+-Clients DÜRFEN NICHT (MUST NOT) auf eine Nicht-TLS-Verbindung zurückfallen, wenn eine TLS-Verbindung fehlschlägt. Dieses Verbot schließt während der Migration einer Bereitstellung ein (Abschnitt 6.1).

5.1.2. TLS 0-RTT​

TLS 1.3-Wiederaufnahme- und PSK-Techniken ermöglichen es, frühe Daten zu senden, auch bekannt als 0-RTT-Daten, Daten, die gesendet werden, bevor der TLS-Handshake abgeschlossen ist. Die Wiederholung dieser Daten ist ein Risiko. Angesichts der Sensibilität von TACACS+-Daten DÜRFEN Clients KEINE (MUST NOT) Daten senden, bis der vollständige TLS-Handshake abgeschlossen ist; das heißt, Clients DÜRFEN KEINE (MUST NOT) 0-RTT-Daten senden und TLS TACACS+-Server MÜSSEN (MUST) Clients, die dies tun, abrupt trennen.

TLS TACACS+-Clients und -Server DÜRFEN NICHT (MUST NOT) die early_data-Erweiterung einschließen. Siehe Abschnitte 2.3 und 4.2.10 von [RFC8446] für Sicherheitsbedenken.

5.1.3. TLS-Optionen (TLS Options)​

Die Empfehlungen in [BCP195] MÜSSEN (MUST) befolgt werden, um zu bestimmen, welche TLS-Versionen und -Algorithmen unterstützt, veraltet, obsolet oder aufgegeben werden sollten.

Außerdem schreibt Abschnitt 9 von [RFC8446] obligatorisch unterstützte Optionen vor.

5.1.4. Nicht erreichbare Zertifizierungsstelle (CA) (Unreachable Certificate Authority)​

Betreiber sollten sich des Potenzials der Isolierung von TLS TACACS+-Server und/oder -Client von der CA ihres Peers durch Netzwerkausfälle bewusst sein. Die Isolierung von der CA eines Public-Key-Zertifikats führt dazu, dass die Überprüfung des Zertifikats fehlschlägt und somit die TLS-Authentifizierung des Peers fehlschlägt. Der in Abschnitt 3.4.1 erwähnte Ansatz kann dabei helfen, dies zu adressieren und sollte in Betracht gezogen werden.

5.1.5. TLS-Servernamenindikator (SNI) (TLS Server Name Indicator)​

Betreiber sollten sich bewusst sein, dass die TLS SNI-Erweiterung Teil des TLS-Client-Hello ist, das im Klartext gesendet wird. Es unterliegt daher dem Abhören. Siehe auch Abschnitt 11.1 von [RFC6066].

5.1.6. Serveridentitäts-Wildcards (Server Identity Wildcards)​

Die Verwendung von Wildcards in TLS-Serveridentitäten schafft einen Single Point of Failure: ein kompromittierter privater Schlüssel eines Wildcard-Zertifikats betrifft alle Server, die es verwenden. Ihre Verwendung MUSS (MUST) den Empfehlungen von Abschnitt 7.1 von [RFC9525] folgen. Betreiber MÜSSEN (MUST) sicherstellen, dass der Wildcard auf eine Subdomain beschränkt ist, die ausschließlich TLS TACACS+-Servern gewidmet ist.

5.2. TACACS+-Konfiguration (TACACS+ Configuration)​

Implementierer müssen sicherstellen, dass das zur Aktivierung von TLS eingeführte Konfigurationsschema unkompliziert ist und keinen Raum für Mehrdeutigkeit darüber lässt, ob TLS oder Nicht-TLS zwischen dem TACACS+-Client und dem TACACS+-Server verwendet wird.

Dieses Dokument empfiehlt die Verwendung einer separaten Portnummer, auf die TLS TACACS+-Server lauschen werden. Wenn Bereitstellungen die Standardwerte nicht explizit überschrieben haben, MÜSSEN (MUST) TACACS+-Client-Implementierungen die korrekten Portwerte verwenden:

  • Port 49: für Nicht-TLS-Verbindung TACACS+
  • Port 300: für TLS-Verbindung TACACS+

Implementierer können eine einzelne Option für TACACS+-Clients und -Server anbieten, um alle Nicht-TLS TACACS+-Operationen zu deaktivieren. Wenn sie auf einem TACACS+-Server aktiviert ist, wird er nicht auf Anfragen von Nicht-TLS TACACS+-Client-Verbindungen antworten. Wenn sie auf einem TACACS+-Client aktiviert ist, wird er keine Nicht-TLS TACACS+-Serververbindungen herstellen.

Eine häufige Fehlkonfiguration besteht darin, TLS auf dem Server zu aktivieren, aber den Client so zu konfigurieren, dass er den Nicht-TLS-Port verwendet, oder umgekehrt. Um dies zu verhindern, SOLLTEN (SHOULD) klare Konfigurationspraktiken Folgendes umfassen:

  • Explizite TLS/Nicht-TLS-Modusindikatoren in Konfigurationsdateien
  • Validierungswarnungen, wenn Portnummern nicht mit dem konfigurierten Modus übereinstimmen
  • Separate Konfigurationsabschnitte für TLS- und Nicht-TLS-Server

5.3. Bekannte TCP/IP-Portnummer (Well-Known TCP/IP Port Number)​

Eine neue Portnummer wird als angemessen erachtet (statt eines Mechanismus, der ein Upgrade von einer anfänglichen Nicht-TLS TACACS+-Verbindung aushandelt), weil sie Folgendes ermöglicht:

  • einfaches Blockieren der unverschleierten oder verschleierten Verbindungen durch die TCP/IP-Portnummer,
  • passive Intrusion Detection Systems (IDSs), die die unverschleierten überwachen, werden durch die Einführung von TLS nicht beeinträchtigt,
  • Vermeidung von On-Path-Angriffen, die ein Upgrade stören können, und
  • Verhinderung der versehentlichen Offenlegung sensibler Informationen aufgrund von Fehlkonfiguration.

6. Betriebsüberlegungen (Operational Considerations)

6.1. Migration (Migration)​

Um einen reibungslosen Übergang von Legacy-TACACS+-Bereitstellungen zu TLS-gesichertem TACACS+ zu erleichtern, müssen Organisationen ihre Migration sorgfältig planen. Die häufigsten Migrationsstrategien sind:

Parallelbetrieb (Parallel Operation): Betreiber können neue TLS TACACS+-Server neben vorhandenen Nicht-TLS-Servern bereitstellen. Dies ermöglicht eine schrittweise Client-Migration ohne Dienstunterbrechung. Wie jedoch in Abschnitt 5.1.1 erwähnt, wird es NICHT EMPFOHLEN (NOT RECOMMENDED), sowohl TLS- als auch Nicht-TLS-Dienste auf demselben Host auszuführen.

Phasenmigration (Phased Migration): Ein empfohlener Ansatz umfasst:

  1. Bewertungsphase (Assessment Phase): Identifizieren Sie alle TACACS+-Clients und -Server in der Umgebung
  2. Pilotphase (Pilot Phase): Stellen Sie TLS TACACS+-Server auf Port 300 in einer Testumgebung bereit
  3. Erstbereitstellung (Initial Deployment): Konfigurieren Sie eine Teilmenge von Clients für die Verwendung der neuen TLS-Server
  4. Schrittweiser Rollout (Gradual Rollout): Migrieren Sie schrittweise zusätzliche Clients
  5. Überwachungsperiode (Monitoring Period): Stellen Sie einen stabilen Betrieb sicher, bevor Sie fortfahren
  6. Abschluss (Completion): Außerbetriebnahme der Nicht-TLS-Infrastruktur, sobald alle Clients migriert sind

Während der Migration DÜRFEN (MUST NOT) TACACS+-Clients nicht so konfiguriert werden, dass sie auf Nicht-TLS-Verbindungen zurückfallen, wenn eine TLS-Verbindung fehlschlägt (Abschnitt 5.1.1). Dieses Verbot ist entscheidend, um Downgrade-Angriffe zu verhindern.

Betreiber sollten während der Migration detaillierte Protokolle führen, um Clients zu identifizieren, die noch Nicht-TLS-Verbindungen versuchen.

6.2. Wartung von Nicht-TLS TACACS+-Clients (Maintaining Non-TLS TACACS+ Clients)​

Einige Legacy-Geräte unterstützen möglicherweise kein TLS und können nicht aktualisiert werden. Für diese Geräte haben Betreiber mehrere Optionen:

  1. Separate Nicht-TLS-Infrastruktur (Separate Non-TLS Infrastructure): Stellen Sie dedizierte Nicht-TLS TACACS+-Server auf separaten Hosts bereit (EMPFOHLEN). Diese Server sollten wenn möglich in einem stärker eingeschränkten Netzwerksegment isoliert werden.

  2. Schrittweise Hardware-Erneuerung (Gradual Hardware Refresh): Planen Sie den Austausch oder die Aktualisierung von Legacy-Geräten als Teil normaler Erneuerungszyklen.

  3. Kompensierende Kontrollen (Compensating Controls): Wenn Legacy-Geräte verbleiben müssen, implementieren Sie zusätzliche Sicherheitskontrollen auf Netzwerkebene wie dedizierte VLANs, verstärkte Überwachung oder verschlüsselte Tunnel auf der Netzwerkschicht.

Nicht-TLS TACACS+-Server SOLLTEN (SHOULD) klar dokumentiert und überwacht werden. Organisationen sollten ein Zieldatum für die vollständige TLS-Migration haben.

6.3. YANG-Modell für TACACS+-Clients (YANG Model for TACACS+ Clients)​

Ein YANG-Datenmodell zur Konfiguration von TACACS+-Clients, einschließlich TLS-spezifischer Parameter, wäre vorteilhaft für die Netzwerkautomatisierung und konsistente Konfigurationsverwaltung über heterogene Netzwerkgeräte hinweg.

Ein solches Modell könnte Folgendes umfassen:

  • Serveradressen und Portnummern
  • TLS-Konfigurationsparameter (Zertifikatspfade, Cipher-Suites usw.)
  • Fallback-Verhalten und Timeout-Einstellungen
  • Authentifizierungsprioritäten

Die Entwicklung eines standardisierten YANG-Modells liegt außerhalb des Umfangs dieses Dokuments, wird aber als zukünftige Arbeit gefördert. Organisationen, die TACACS+ über TLS in YANG-basierten Verwaltungssystemen implementieren, sollten die Entwicklung herstellerneutraler Modelle in Betracht ziehen.

7. IANA-Überlegungen (IANA Considerations)

IANA hat die TCP-Portnummer 300 mit dem Dienstnamen "tacacss" für TACACS+ über TLS zugewiesen:

Service Name: tacacss
Transport Protocol: TCP
Port Number: 300
Description: TACACS+ over TLS
Reference: RFC 9887

8. Danksagungen (Acknowledgments)

Die Autoren möchten die Beiträge und das Feedback der Teilnehmer der IETF Operations and Management Area Working Group (OPSAWG) anerkennen. Besonderer Dank gilt denen, die während der Entwicklung dieser Spezifikation wertvolle Beiträge geleistet haben, einschließlich Überprüfungen, Vorschläge und Implementierungserfahrungen, die dazu beigetragen haben, dieses Dokument zu formen.

Die Arbeit zur Verbesserung der TACACS+-Sicherheit durch TLS wurde durch den Bedarf der operativen Gemeinschaft nach besserem Schutz des Geräteverwaltungsverkehrs vorangetrieben. Die Autoren schätzen die kollaborative Anstrengung, die diese Spezifikation möglich gemacht hat.

9. Referenzen (References)

9.1. Normative Referenzen (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

    • https://www.rfc-editor.org/info/rfc2119

  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

    • https://www.rfc-editor.org/info/rfc8174

  • [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

    • https://www.rfc-editor.org/info/rfc8446

  • [RFC8907] Dahm, T., Ota, A., Medway Gash, D., and L. Grant, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", RFC 8907, DOI 10.17487/RFC8907, September 2020.

    • https://www.rfc-editor.org/info/rfc8907

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.

    • https://www.rfc-editor.org/info/rfc5280

  • [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023.

    • https://www.rfc-editor.org/info/rfc9525

  • [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.

    • https://www.rfc-editor.org/info/rfc6066

9.2. Informative Referenzen (Informative References)​

  • [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011.

    • https://www.rfc-editor.org/info/rfc6151

  • [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014.

    • https://www.rfc-editor.org/info/rfc7250

  • [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016.

    • https://www.rfc-editor.org/info/rfc7924

  • [RFC9257] Housley, R., "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022.

    • https://www.rfc-editor.org/info/rfc9257

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.

    • https://www.rfc-editor.org/info/rfc7525

  • [FIPS-140-3] National Institute of Standards and Technology, "Security Requirements for Cryptographic Modules", FIPS PUB 140-3, March 2019.

    • https://csrc.nist.gov/publications/detail/fips/140/3/final

  • [REQ-TLS13] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", RFC 8996, DOI 10.17487/RFC8996, March 2021.

    • https://www.rfc-editor.org/info/rfc8996

Adressen der Autoren (Authors' Addresses)​

Thorsten Dahm
Email: [email protected]

John Heasley
NTT
Email: [email protected]

Douglas C. Medway Gash
Cisco Systems, Inc.
Email: [email protected]

Andrej Ota
Google Inc.
Email: [email protected]

Letztes Update am