Skip to main content

2. Authorization Extension Types

The general extension mechanisms enable clients and servers to negotiate whether to use specific extensions, and how to use specific extensions. As specified in [TLS1.2], the extension format used in the extended client hello message and extended server hello message is repeated here for convenience:

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

The extension_type identifies a particular extension type, and the extension_data contains information specific to the particular extension type. This document specifies the use of two new extension types: client_authz and server_authz. These extension types are described in Section 2.1 and Section 2.2, respectively. This specification adds two new types to ExtensionType:

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

The authorization extensions are relevant when a TLS session is being established, and these extension types MUST NOT appear in the extended server hello message unless the same extension type appeared in the corresponding client hello message. Clients MUST NOT send extension types in the extended client hello message unless they are prepared to accept the associated authorization information from the server. If a client sends the client_authz extension, the client MUST also send the server_authz extension.

The server MUST check for both the client_authz and server_authz extensions in the client hello message, and it MUST respond with extensions for each authorization data type that is mutually supported. The server MUST NOT respond with the client_authz extension and not also respond with the server_authz extension, and vice versa.

2.1. The client_authz and server_authz Extensions​

To offer authorization information to the TLS server, clients MAY include an extension of type "client_authz" in the extended client hello message. To request authorization information from the TLS server, clients MAY include an extension of type "server_authz" in the extended client hello message. The "extension_data" field of each of these extensions MUST contain a ClientAuthzFormatList as described below:

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

The AuthorizationDataFormat type is used to describe the authorization information in the SupplementalData message. The AuthorizationDataFormat type is defined as follows:

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

The certificate and certificate URL authorization data types MUST be accompanied by a URL location for the authorization server. The certificate and certificate URL types, along with the authorization server URL, allow the authorization decision to be made by a third party, which may be separate from the TLS client and TLS server.

The meaning of the authz_format_list is as follows:

  • x509_attr_cert indicates that the client authorization information is an X.509 attribute certificate (AC) [ATTRCERT].

  • saml_assertion indicates that the authorization information is a SAML assertion [SAML1.1] [SAML2.0].

  • x509_attr_cert_url indicates that the authorization information is an X.509 attribute certificate (AC) [ATTRCERT] provided as a URI [HTTP].

  • saml_assertion_url indicates that the authorization information is a SAML assertion [SAML1.1] [SAML2.0] provided as a URI [HTTP].

The authorization data is carried in a SupplementalData message [TLSSUPP]. The client and server know which SupplementalData messages are being used based on the ClientAuthzFormatList and the ServerAuthzFormatList from the extended client hello message and the extended server hello message. The data for each authorization format in the ClientAuthzFormatList and ServerAuthzFormatList MUST be included in the same order in the SupplementalData message.

2.2. Client Hello​

The format of the TLS client hello is presented here to show the placement of the authorization extensions. The full specification of the client hello message can be found in [TLS1.0], [TLS1.1], and [TLS1.2].

In order to indicate the support of authorization information to the TLS server, clients MAY include one or both of the client_authz and server_authz extensions in an extended client hello message.

When the client includes the client_authz extension, it indicates the set of authorization data types (carried in SupplementalData handshake messages [TLSSUPP]) that the client is prepared to provide to the server.

When the client includes the server_authz extension, it indicates the set of authorization data types (carried in SupplementalData handshake messages [TLSSUPP]) that the client is prepared to receive from the server.

The client_authz and server_authz extensions MUST be omitted from the client hello message if the client is initiating a session resumption.

The general structure of the extended client hello message is defined in [TLSEXT2], which is reproduced here for clarity:

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;
Last updated on