5. Sicherheitsüberlegungen

Dieser Abschnitt behandelt Sicherheitsprobleme im Zusammenhang mit der Verwendung eines Tickets. Tickets müssen authentifiziert und verschlüsselt werden, um Änderungen oder Mithören durch einen Angreifer zu verhindern. Mehrere unten beschriebene Angriffe werden möglich sein, wenn dies nicht sorgfältig erfolgt.

Implementierungen sollten darauf achten, dass die Verarbeitung von Tickets nicht die Wahrscheinlichkeit eines Denial-of-Service erhöht, wie unten beschrieben.

5.1. Ungültigmachen von Sitzungen

Die TLS-Spezifikation verlangt, dass TLS-Sitzungen für ungültig erklärt werden, wenn Fehler auftreten. [CSSC] erörtert die Sicherheitsauswirkungen hiervon im Detail. In der Analyse in diesem Papier stellt das Versäumnis, Sitzungen für ungültig zu erklären, kein Sicherheitsrisiko dar. Das liegt daran, dass der TLS-Handshake eine nicht umkehrbare Funktion verwendet, um Schlüssel für eine Sitzung abzuleiten, sodass Informationen über eine Sitzung keinen Vorteil bieten, um das Master-Secret (master secret) oder eine andere Sitzung anzugreifen. Wenn ein Schema zur Ungültigmachung von Sitzungen verwendet wird, sollte die Implementierung die Integrität des Tickets verifizieren, bevor sie den Inhalt verwendet, um eine Sitzung für ungültig zu erklären, um sicherzustellen, dass ein Angreifer keine ausgewählte Sitzung für ungültig erklären kann.

5.2. Gestohlene Tickets

Ein Lauscher oder ein Man-in-the-Middle kann das Ticket erhalten und versuchen, es zu verwenden, um eine Sitzung mit dem Server aufzubauen; da das Ticket jedoch verschlüsselt ist und der Angreifer den geheimen Schlüssel nicht kennt, hilft ein gestohlenes Ticket einem Angreifer nicht, eine Sitzung wiederaufzunehmen. Ein TLS-Server MUSS (MUST) eine starke Verschlüsselung und einen starken Integritätsschutz für das Ticket verwenden, um zu verhindern, dass ein Angreifer einen Brute-Force-Mechanismus nutzt, um den Inhalt des Tickets zu erhalten.

5.3. Gefälschte Tickets

Ein bösartiger Benutzer könnte ein Ticket fälschen oder verändern, um eine Sitzung wiederaufzunehmen, seine Lebensdauer zu verlängern, einen anderen Benutzer zu imitieren oder zusätzliche Privilegien zu erlangen. Dieser Angriff ist nicht möglich, wenn das Ticket mit einem starken Integritätsschutzalgorithmus wie einem schlüsselbasierten HMAC-SHA-256 geschützt ist.

5.4. Denial-of-Service-Angriffe

Das im empfohlenen Ticket-Format definierte Feld key_name hilft dem Server, Tickets, die er nicht ausgegeben hat, effizient zurückzuweisen. Ein Angreifer könnte jedoch eine große Anzahl von Tickets speichern oder erzeugen, um sie an den TLS-Server zur Verifizierung zu senden. Um die Möglichkeit eines Denial-of-Service zu minimieren, sollte die Verifizierung des Tickets leichtgewichtig sein (z. B. unter Verwendung effizienter kryptografischer Algorithmen mit symmetrischen Schlüsseln).

5.5. Verwaltung der Ticket-Schutzschlüssel

Eine vollständige Beschreibung der Verwaltung der Schlüssel, die zum Schutz des Tickets verwendet werden, liegt außerhalb des Geltungsbereichs dieses Dokuments. Eine Liste EMPFOHLENER (RECOMMENDED) Vorgehensweisen ist unten angegeben.

• Die Schlüssel sollten sicher erzeugt werden, indem die Zufälligkeitsempfehlungen in [RFC4086] befolgt werden.

• Die Schlüssel und kryptografischen Schutzalgorithmen sollten mindestens 128 Bit stark sein. Einige Ciphersuites und Anwendungen können einen kryptografischen Schutz von mehr als 128 Bit Stärke erfordern.

• Die Schlüssel sollten für keinen anderen Zweck als das Erzeugen und Verifizieren von Tickets verwendet werden.

• Die Schlüssel sollten regelmäßig geändert werden.

• Die Schlüssel sollten geändert werden, wenn sich das Ticket-Format oder die kryptografischen Schutzalgorithmen ändern.

5.6. Lebensdauer von Tickets

Der TLS-Server kontrolliert die Lebensdauer des Tickets. Server bestimmen die akzeptable Lebensdauer anhand der betrieblichen und sicherheitsbezogenen Anforderungen der Umgebungen, in denen sie eingesetzt werden. Die Lebensdauer des Tickets kann länger sein als die in [RFC4346] empfohlene Lebensdauer von 24 Stunden. TLS-Clients kann ein Hinweis auf die Lebensdauer des Tickets gegeben werden. Da die Lebensdauer eines Tickets nicht spezifiziert sein kann, hat ein Client seine eigene lokale Richtlinie, die bestimmt, wann er Tickets verwirft.

5.7. Alternative Ticket-Formate und Verteilungsschemata

Wenn das in diesem Dokument definierte Ticket-Format oder Verteilungsschema nicht verwendet wird, dann muss bei der Analyse der Sicherheit der Lösung große Sorgfalt walten. Insbesondere wenn vertrauliche Informationen wie ein geheimer Schlüssel an den Client übertragen werden, MUSS (MUST) dies unter Verwendung sicherer Kommunikation geschehen, um zu verhindern, dass Angreifer den Schlüssel erhalten oder ändern. Außerdem MUSS (MUST) die Integrität und Vertraulichkeit des Tickets mit starken kryptografischen Techniken geschützt werden, um eine Verletzung der Sicherheit des Systems zu verhindern.

5.8. Identitätsdatenschutz, Anonymität und Nicht-Verknüpfbarkeit

Dieses Dokument schreibt vor, dass der Inhalt des Tickets vertraulich geschützt ist, um ein Durchsickern seines Inhalts, etwa benutzerrelevanter Informationen, zu vermeiden. Somit verhindert es die Offenlegung potenziell sensibler Informationen, die im Ticket mitgeführt werden.

Der ursprüngliche Handshake-Austausch, der zum Erhalt des Tickets verwendet wurde, bietet aufgrund der Eigenschaften von TLS möglicherweise keine Vertraulichkeit der Identität des Clients. Eine weitere relevante Sicherheitsbedrohung ist die Möglichkeit für einen Angreifer auf dem Pfad, mehrere TLS-Handshakes zu beobachten, bei denen dasselbe Ticket verwendet wird, und daraus zu schließen, dass sie zu denselben Kommunikationsendpunkten gehören. Anwendungsentwickler, die den in diesem Dokument beschriebenen Ticket-Mechanismus verwenden, sollten berücksichtigen, dass Nicht-Verknüpfbarkeit (unlinkability) [ANON] nicht notwendigerweise gegeben ist.

Während eine vollständige Erörterung dieser Themen außerhalb des Geltungsbereichs dieses Dokuments liegt, sollte angemerkt werden, dass es möglich ist, ein Ticket unter Verwendung eines TLS-Renegotiation-Handshakes auszustellen, der nach einem durch einen vorherigen Handshake aufgebauten sicheren Tunnel erfolgt. Dies kann helfen, einige Datenschutz- und Nicht-Verknüpfbarkeitsprobleme in manchen Umgebungen zu adressieren.