2. Autorisierungserweiterungstypen

Die allgemeinen Erweiterungsmechanismen ermöglichen es Clients und Servern auszuhandeln, ob bestimmte Erweiterungen verwendet werden und wie bestimmte Erweiterungen verwendet werden. Wie in [TLS1.2] spezifiziert, wird das in der erweiterten Client-Hello-Nachricht und erweiterten Server-Hello-Nachricht verwendete Erweiterungsformat hier der Bequemlichkeit halber wiederholt:

struct {
   ExtensionType extension_type;
   opaque extension_data<0..2^16-1>;
} Extension;

Der extension_type identifiziert einen bestimmten Erweiterungstyp, und die extension_data enthalten spezifische Informationen für den bestimmten Erweiterungstyp. Dieses Dokument spezifiziert die Verwendung von zwei neuen Erweiterungstypen: client_authz und server_authz. Diese Erweiterungstypen werden in Abschnitt 2.1 bzw. Abschnitt 2.2 beschrieben. Diese Spezifikation fügt zwei neue Typen zu ExtensionType hinzu:

enum {
   client_authz(7), server_authz(8), (65535)
} ExtensionType;

Die Autorisierungserweiterungen sind relevant, wenn eine TLS-Sitzung eingerichtet wird, und diese Erweiterungstypen DÜRFEN NICHT in der erweiterten Server-Hello-Nachricht erscheinen, es sei denn, derselbe Erweiterungstyp erschien in der entsprechenden Client-Hello-Nachricht. Clients DÜRFEN KEINE Erweiterungstypen in der erweiterten Client-Hello-Nachricht senden, es sei denn, sie sind bereit, die zugehörigen Autorisierungsinformationen vom Server zu akzeptieren. Wenn ein Client die client_authz-Erweiterung sendet, MUSS der Client auch die server_authz-Erweiterung senden.

Der Server MUSS sowohl auf die client_authz- als auch auf die server_authz-Erweiterungen in der Client-Hello-Nachricht prüfen, und er MUSS mit Erweiterungen für jeden gegenseitig unterstützten Autorisierungsdatentyp antworten. Der Server DARF NICHT mit der client_authz-Erweiterung antworten und nicht auch mit der server_authz-Erweiterung antworten und umgekehrt.

2.1. Die client_authz- und server_authz-Erweiterungen

Um dem TLS-Server Autorisierungsinformationen anzubieten, KÖNNEN Clients eine Erweiterung vom Typ "client_authz" in die erweiterte Client-Hello-Nachricht aufnehmen. Um Autorisierungsinformationen vom TLS-Server anzufordern, KÖNNEN Clients eine Erweiterung vom Typ "server_authz" in die erweiterte Client-Hello-Nachricht aufnehmen. Das "extension_data"-Feld jeder dieser Erweiterungen MUSS eine ClientAuthzFormatList enthalten, wie unten beschrieben:

struct {
   AuthorizationDataFormat authz_format_list<1..2^8-1>;
} ClientAuthzFormatList;

Der Typ AuthorizationDataFormat wird verwendet, um die Autorisierungsinformationen in der SupplementalData-Nachricht zu beschreiben. Der Typ AuthorizationDataFormat ist wie folgt definiert:

enum {
   x509_attr_cert(0), saml_assertion(1),
   x509_attr_cert_url(2), saml_assertion_url(3), (255)
} AuthorizationDataFormat;

Die Zertifikat- und Zertifikat-URL-Autorisierungsdatentypen MÜSSEN von einer URL-Position für den Autorisierungsserver begleitet werden. Die Zertifikat- und Zertifikat-URL-Typen ermöglichen zusammen mit der Autorisierungsserver-URL, dass die Autorisierungsentscheidung von einer dritten Partei getroffen wird, die möglicherweise vom TLS-Client und TLS-Server getrennt ist.

Die Bedeutung der authz_format_list ist wie folgt:

• x509_attr_cert gibt an, dass die Client-Autorisierungsinformationen ein X.509-Attributzertifikat (AC) [ATTRCERT] sind.

• saml_assertion gibt an, dass die Autorisierungsinformationen eine SAML-Assertion [SAML1.1] [SAML2.0] sind.

• x509_attr_cert_url gibt an, dass die Autorisierungsinformationen ein X.509-Attributzertifikat (AC) [ATTRCERT] sind, das als URI [HTTP] bereitgestellt wird.

• saml_assertion_url gibt an, dass die Autorisierungsinformationen eine SAML-Assertion [SAML1.1] [SAML2.0] sind, die als URI [HTTP] bereitgestellt wird.

Die Autorisierungsdaten werden in einer SupplementalData-Nachricht [TLSSUPP] übertragen. Client und Server wissen, welche SupplementalData-Nachrichten verwendet werden, basierend auf der ClientAuthzFormatList und der ServerAuthzFormatList aus der erweiterten Client-Hello-Nachricht und der erweiterten Server-Hello-Nachricht. Die Daten für jedes Autorisierungsformat in der ClientAuthzFormatList und ServerAuthzFormatList MÜSSEN in derselben Reihenfolge in der SupplementalData-Nachricht enthalten sein.

2.2. Client Hello

Das Format des TLS-Client-Hello wird hier dargestellt, um die Platzierung der Autorisierungserweiterungen zu zeigen. Die vollständige Spezifikation der Client-Hello-Nachricht kann in [TLS1.0], [TLS1.1] und [TLS1.2] gefunden werden.

Um dem TLS-Server die Unterstützung von Autorisierungsinformationen anzuzeigen, KÖNNEN Clients eine oder beide der client_authz- und server_authz-Erweiterungen in eine erweiterte Client-Hello-Nachricht aufnehmen.

Wenn der Client die client_authz-Erweiterung einschließt, gibt er die Menge der Autorisierungsdatentypen an (die in SupplementalData-Handshake-Nachrichten [TLSSUPP] übertragen werden), die der Client bereit ist, dem Server bereitzustellen.

Wenn der Client die server_authz-Erweiterung einschließt, gibt er die Menge der Autorisierungsdatentypen an (die in SupplementalData-Handshake-Nachrichten [TLSSUPP] übertragen werden), die der Client bereit ist, vom Server zu empfangen.

Die client_authz- und server_authz-Erweiterungen MÜSSEN aus der Client-Hello-Nachricht weggelassen werden, wenn der Client eine Sitzungswiederaufnahme initiiert.

Die allgemeine Struktur der erweiterten Client-Hello-Nachricht ist in [TLSEXT2] definiert, die hier zur Klarheit reproduziert wird:

struct {
   ProtocolVersion client_version;
   Random random;
   SessionID session_id;
   CipherSuite cipher_suites<2..2^16-2>;
   CompressionMethod compression_methods<1..2^8-1>;
   select (extensions_present) {
      case false:
         struct {};
      case true:
         Extension extensions<0..2^16-1>;
   };
} ClientHello;