1. Einführung

Das Transport Layer Security (TLS) Protokoll ([TLS1.0], [TLS1.1], [TLS1.2]) wird in einer zunehmenden Vielfalt von Betriebsumgebungen verwendet, einschließlich solcher, die zum Zeitpunkt des ursprünglichen TLS-Designs nicht vorgesehen waren. Die in diesem Dokument eingeführten Erweiterungen sind darauf ausgelegt, TLS in Umgebungen zu betreiben, in denen Autorisierungsinformationen zwischen Client und Server ausgetauscht werden müssen, bevor geschützte Daten ausgetauscht werden. Die Verwendung dieser TLS-Autorisierungserweiterungen ist besonders attraktiv, wenn mehr als ein Anwendungsprotokoll dieselben Autorisierungsinformationen verwenden kann.

Das Format und der Inhalt der in diesen Erweiterungen übertragenen Autorisierungsinformationen sind erweiterbar. Dieses Dokument verweist auf Security Assertion Markup Language (SAML)-Assertion ([SAML1.1], [SAML2.0]) und X.509-Attributzertifikat (AC) [ATTRCERT] Autorisierungsformate, aber es können auch andere Formate verwendet werden. Zukünftige Autorisierungserweiterungen können jede opake Assertion enthalten, die von einem vertrauenswürdigen Aussteller digital signiert ist. In Anerkennung der Ähnlichkeit zur Zertifikatspfadvalidierung empfiehlt dieses Dokument die Verwendung von TLS-Warnmeldungen im Zusammenhang mit der Zertifikatsverarbeitung, um Fehler bei der Verarbeitung von Autorisierungsinformationen zu melden.

Eine direkte Bindung von Identifikations-, Authentifizierungs- und Autorisierungsinformationen an eine verschlüsselte Sitzung ist möglich, wenn all diese innerhalb von TLS behandelt werden. Wenn jede Anwendung eindeutige Autorisierungsinformationen erfordert, sollten diese am besten innerhalb des TLS-geschützten Anwendungsprotokolls übertragen werden. Es muss jedoch darauf geachtet werden, dass geeignete Bindungen sichergestellt werden, wenn Identifikations-, Authentifizierungs- und Autorisierungsinformationen auf verschiedenen Protokollebenen behandelt werden.

Dieses Dokument beschreibt Autorisierungserweiterungen für das TLS-Handshake-Protokoll in TLS 1.0, TLS 1.1 und TLS 1.2. Diese Erweiterungen befolgen die Konventionen, die für TLS-Erweiterungen definiert wurden, die ursprünglich in [TLSEXT1] definiert und in [TLSEXT2] überarbeitet wurden; TLS-Erweiterungen sind jetzt Teil von TLS 1.2 [TLS1.2]. TLS-Erweiterungen verwenden allgemeine Erweiterungsmechanismen für die Client-Hello-Nachricht und die Server-Hello-Nachricht. Die in diesem Dokument beschriebenen Erweiterungen bestätigen, dass sowohl der Client als auch der Server die gewünschten Autorisierungsdatentypen unterstützen. Wenn sie unterstützt werden, werden dann Autorisierungsinformationen in der Supplemental Data Handshake-Nachricht [TLSSUPP] ausgetauscht.

Die Autorisierungserweiterungen können in Verbindung mit TLS 1.0, TLS 1.1 und TLS 1.2 verwendet werden. Die Erweiterungen sind so konzipiert, dass sie rückwärtskompatibel sind, was bedeutet, dass die Handshake-Protokoll-Supplemental-Data-Nachrichten nur dann Autorisierungsinformationen eines bestimmten Typs enthalten, wenn der Client im Client-Hello-Message Unterstützung dafür angibt und der Server im Server-Hello-Message Unterstützung dafür angibt.

Clients kennen typischerweise den Kontext der TLS-Sitzung, die eingerichtet wird; daher kann der Client die Autorisierungserweiterungen bei Bedarf verwenden. Server müssen erweiterte Client-Hello-Nachrichten akzeptieren, auch wenn der Server nicht alle aufgelisteten Erweiterungen "versteht". Der Server wird jedoch keine Unterstützung für diese "nicht verstandenen" Erweiterungen anzeigen. Clients können dann die Kommunikation mit Servern ablehnen, die die Autorisierungserweiterungen nicht unterstützen.

1.1. Konventionen

Die Syntax für die Autorisierungsnachrichten wird unter Verwendung der TLS-Präsentationssprache definiert, die in Abschnitt 4 von [TLS1.0] spezifiziert ist.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind gemäß RFC 2119 [STDWORDS] zu interpretieren.

1.2. Überblick

Abbildung 1 veranschaulicht die Platzierung der Autorisierungserweiterungen und Supplemental-Data-Nachrichten im vollständigen TLS-Handshake.

Die ClientHello-Nachricht enthält eine Angabe der unterstützten Client-Autorisierungsdatenformate und eine Angabe der unterstützten Server-Autorisierungsdatenformate. Die ServerHello-Nachricht enthält ähnliche Angaben, aber alle Autorisierungsdatenformate, die vom Server nicht unterstützt werden, sind nicht enthalten. Sowohl der Client als auch der Server MÜSSEN Unterstützung für die Autorisierungsdatentypen anzeigen. Wenn die Liste der gegenseitig unterstützten Autorisierungsdatenformate leer ist, DARF die ServerHello-Nachricht die betroffene Erweiterung überhaupt nicht tragen.

Eine erfolgreiche Sitzungswiederaufnahme verwendet dieselben Autorisierungsinformationen wie die ursprüngliche Sitzung.

Client                                                   Server

ClientHello (w/ extensions) -------->

                                    ServerHello (w/ extensions)
                                              SupplementalData*
                                                   Certificate*
                                             ServerKeyExchange*
                                            CertificateRequest*
                            <--------           ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                    -------->
                                             [ChangeCipherSpec]
                            <--------                  Finished
Application Data            <------->          Application Data

 *  Zeigt optionale oder situationsabhängige Nachrichten an, die
    nicht immer gesendet werden.

 [] Zeigt an, dass ChangeCipherSpec ein unabhängiger TLS-
    Protokoll-Inhaltstyp ist; es ist eigentlich keine TLS-
    Handshake-Nachricht.

   Abbildung 1.  Autorisierungsdatenaustausch im vollständigen TLS-Handshake