5. Extension Negotiation (Erweiterungsaushandlung)

5.1. Extension Definition (Erweiterungsdefinition)

Dieses Dokument definiert eine neue TLS-Erweiterung, extended_master_secret (mit Erweiterungstyp 0x0017), die verwendet wird, um sowohl dem Client als auch dem Server zu signalisieren, die Berechnung des erweiterten Hauptgeheimnisses zu verwenden. Das Feld extension_data dieser Erweiterung ist leer. Somit ist die gesamte Kodierung der Erweiterung 00 17 00 00 (hexadezimal).

Obwohl sich dieses Dokument nur auf TLS bezieht, kann die hier vorgeschlagene Erweiterung auch mit Datagram TLS (DTLS) [RFC6347] verwendet werden.

Wenn der Client und der Server dieser Erweiterung zustimmen und ein vollständiger Handshake stattfindet, MÜSSEN sowohl Client als auch Server den Algorithmus zur Ableitung des erweiterten Hauptgeheimnisses verwenden, wie in Section 4 definiert. Alle anderen kryptografischen Berechnungen bleiben unverändert.

5.2. Client and Server Behavior: Full Handshake (Client- und Serververhalten: Vollständiger Handshake)

Im Folgenden verwenden wir den Ausdruck "Handshake abbrechen" als Abkürzung für das Beenden des Handshakes durch Senden eines fatalen handshake_failure-Alarms.

In allen Handshakes MUSS ein Client, der dieses Dokument implementiert, die Erweiterung extended_master_secret in seinem ClientHello senden.

Wenn ein Server, der dieses Dokument implementiert, die Erweiterung extended_master_secret empfängt, MUSS er die Erweiterung in seine ServerHello-Nachricht aufnehmen.

Wenn sowohl das ClientHello als auch das ServerHello die Erweiterung enthalten, verwendet die neue Sitzung die Berechnung des erweiterten Hauptgeheimnisses.

Wenn der Server ein ClientHello ohne die Erweiterung empfängt, SOLLTE er den Handshake abbrechen, wenn er nicht mit Legacy-Clients interagieren möchte. Wenn er sich entscheidet, den Handshake fortzusetzen, dann DARF er die Erweiterung NICHT in das ServerHello aufnehmen.

Wenn ein Client ein ServerHello ohne die Erweiterung empfängt, SOLLTE er den Handshake abbrechen, wenn er nicht mit Legacy-Servern interagieren möchte.

Wenn der Client und der Server beschließen, einen vollständigen Handshake ohne die Erweiterung fortzusetzen, MÜSSEN sie die Standard-Hauptschlüsselableitung für die neue Sitzung verwenden. In diesem Fall ist die neue Sitzung nicht durch die in diesem Dokument beschriebenen Mechanismen geschützt. Daher sollten Implementierer die Richtlinien in Section 5.4 befolgen, um gefährliche Nutzungsszenarien zu vermeiden. Insbesondere sollte das aus der neuen Sitzung abgeleitete Hauptgeheimnis nicht für die Authentifizierung auf Anwendungsebene verwendet werden.

5.3. Client and Server Behavior: Abbreviated Handshake (Client- und Serververhalten: Verkürzter Handshake)

Der Client SOLLTE KEINEN verkürzten Handshake anbieten, um eine Sitzung wiederaufzunehmen, die kein erweitertes Hauptgeheimnis verwendet. Stattdessen SOLLTE er einen vollständigen Handshake anbieten.

Wenn der Client sich entscheidet, auch für solche Sitzungen einen verkürzten Handshake anzubieten, um eine unsichere Legacy-Wiederaufnahme zu unterstützen, dann ist die aktuelle Verbindung nicht durch die Mechanismen in diesem Dokument geschützt. Daher sollte der Client die Richtlinien in Section 5.4 befolgen, um gefährliche Nutzungsszenarien zu vermeiden. Insbesondere ist die Neuverhandlung auf dieser Verbindung nicht mehr sicher, selbst wenn Client und Server die Erweiterung für die Neuverhandlungsanzeige unterstützen [RFC5746].

Wenn ein verkürzter Handshake angeboten wird, MUSS der Client die Erweiterung extended_master_secret in seinem ClientHello senden.

Wenn ein Server ein ClientHello für einen verkürzten Handshake empfängt, der anbietet, eine bekannte frühere Sitzung wiederaufzunehmen, verhält er sich wie folgt:

Wenn die ursprüngliche Sitzung die Erweiterung extended_master_secret nicht verwendet hat, aber das neue ClientHello die Erweiterung enthält, dann DARF der Server den verkürzten Handshake NICHT durchführen. Stattdessen SOLLTE er mit einem vollständigen Handshake fortfahren (wie in Section 5.2 beschrieben), um eine neue Sitzung auszuhandeln.
Wenn die ursprüngliche Sitzung die Erweiterung extended_master_secret verwendet hat, aber das neue ClientHello sie nicht enthält, MUSS der Server den verkürzten Handshake abbrechen.
Wenn weder die ursprüngliche Sitzung noch das neue ClientHello die Erweiterung verwenden, SOLLTE der Server den Handshake abbrechen. Wenn er mit einem verkürzten Handshake fortfährt, um eine unsichere Legacy-Wiederaufnahme zu unterstützen, ist die Verbindung nicht mehr durch die Mechanismen in diesem Dokument geschützt, und der Server sollte die Richtlinien in Section 5.4 befolgen.
Wenn das neue ClientHello die Erweiterung enthält und der Server sich entscheidet, den Handshake fortzusetzen, dann MUSS der Server die Erweiterung extended_master_secret in seine ServerHello-Nachricht aufnehmen.

Wenn ein Client ein ServerHello empfängt, das einen verkürzten Handshake akzeptiert, verhält er sich wie folgt:

Wenn die ursprüngliche Sitzung die Erweiterung extended_master_secret nicht verwendet hat, aber das neue ServerHello die Erweiterung enthält, MUSS der Client den Handshake abbrechen.
Wenn die ursprüngliche Sitzung die Erweiterung verwendet hat, aber das neue ServerHello die Erweiterung nicht enthält, MUSS der Client den Handshake abbrechen.

Wenn der Client und der Server den verkürzten Handshake fortsetzen, leiten sie die Verbindungsschlüssel für die neue Sitzung wie üblich aus dem Hauptgeheimnis der ursprünglichen Sitzung ab.

5.4. Interoperability Considerations (Überlegungen zur Interoperabilität)

Um die Interoperabilität mit Legacy-Clients und -Servern zu ermöglichen, kann ein TLS-Peer entscheiden, vollständige Handshakes zu akzeptieren, die die Legacy-Hauptschlüsselberechnung verwenden. Wenn dies der Fall ist, müssen sie zwischen Sitzungen unterscheiden, die Legacy- und erweiterte Hauptgeheimnisse verwenden, indem sie ein Flag zum Sitzungsstatus hinzufügen.

Wenn ein Client oder Server sich entscheidet, mit einem vollständigen Handshake ohne die Erweiterung für das erweiterte Hauptgeheimnis fortzufahren, wird die neue Sitzung anfällig für den in Section 1 beschriebenen Man-in-the-Middle-Schlüsselsynchronisationsangriff. Daher DARF der Client oder Server KEIN Schlüsselmaterial basierend auf dem neuen Hauptgeheimnis für eine spätere Authentifizierung auf Anwendungsebene exportieren. Insbesondere MUSS er [RFC5705] und jedes Extensible Authentication Protocol (EAP), das auf Verbundauthentifizierung angewiesen ist, deaktivieren [COMPOUND-AUTH].

Wenn ein Client oder Server sich entscheidet, einen verkürzten Handshake fortzusetzen, um eine Sitzung wiederaufzunehmen, die das erweiterte Hauptgeheimnis nicht verwendet, wird die aktuelle Verbindung anfällig für einen Man-in-the-Middle-Handshake-Protokollsynchronisationsangriff, wie in Section 1 beschrieben. Daher DARF der Client oder Server die verify_data des aktuellen Handshakes NICHT für die Authentifizierung auf Anwendungsebene verwenden. Insbesondere MUSS der Client die Neuverhandlung und jede Verwendung der "tls-unique"-Kanalbindung [RFC5929] auf der aktuellen Verbindung deaktivieren.

Wenn die ursprüngliche Sitzung ein erweitertes Hauptgeheimnis verwendet, aber das ClientHello oder ServerHello im verkürzten Handshake die Erweiterung nicht enthält, KANN es sicher sein, den verkürzten Handshake fortzusetzen, da er durch das erweiterte Hauptgeheimnis der ursprünglichen Sitzung geschützt ist. Dieses Szenario kann beispielsweise auftreten, wenn ein Server, der diese Erweiterung implementiert, eine Sitzung aufbaut, die Sitzung jedoch später auf einem anderen Server wiederaufgenommen wird, der die Erweiterung nicht unterstützt. Da solche Situationen ungewöhnlich sind und wahrscheinlich das Ergebnis vorübergehender oder unbeabsichtigter Fehlkonfigurationen sind, empfiehlt dieses Dokument, dass der Client und der Server solche Handshakes abbrechen MÜSSEN.