Aller au contenu principal

2. Types d'extension d'autorisation

Les mécanismes d'extension généraux permettent aux clients et aux serveurs de négocier s'il faut utiliser des extensions spécifiques et comment les utiliser. Comme spécifié dans [TLS1.2], le format d'extension utilisé dans le message client hello étendu et le message server hello étendu est répété ici pour plus de commodité :

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

Le champ extension_type identifie un type d'extension particulier, et extension_data contient des informations spécifiques au type d'extension particulier. Ce document spécifie l'utilisation de deux nouveaux types d'extension : client_authz et server_authz. Ces types d'extension sont décrits dans la Section 2.1 et la Section 2.2, respectivement. Cette spécification ajoute deux nouveaux types à ExtensionType :

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

Les extensions d'autorisation sont pertinentes lorsqu'une session TLS est en cours d'établissement, et ces types d'extension NE DOIVENT PAS apparaître dans le message server hello étendu à moins que le même type d'extension n'apparaisse dans le message client hello correspondant. Les clients NE DOIVENT PAS envoyer de types d'extension dans le message client hello étendu à moins qu'ils ne soient prêts à accepter les informations d'autorisation associées du serveur. Si un client envoie l'extension client_authz, le client DOIT également envoyer l'extension server_authz.

Le serveur DOIT vérifier la présence des extensions client_authz et server_authz dans le message client hello, et il DOIT répondre avec des extensions pour chaque type de données d'autorisation mutuellement pris en charge. Le serveur NE DOIT PAS répondre avec l'extension client_authz sans répondre également avec l'extension server_authz, et vice versa.

2.1. Les extensions client_authz et server_authz​

Pour offrir des informations d'autorisation au serveur TLS, les clients PEUVENT inclure une extension de type "client_authz" dans le message client hello étendu. Pour demander des informations d'autorisation au serveur TLS, les clients PEUVENT inclure une extension de type "server_authz" dans le message client hello étendu. Le champ "extension_data" de chacune de ces extensions DOIT contenir une ClientAuthzFormatList comme décrit ci-dessous :

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

Le type AuthorizationDataFormat est utilisé pour décrire les informations d'autorisation dans le message SupplementalData. Le type AuthorizationDataFormat est défini comme suit :

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

Les types de données d'autorisation de certificat et d'URL de certificat DOIVENT être accompagnés d'un emplacement URL pour le serveur d'autorisation. Les types de certificat et d'URL de certificat, ainsi que l'URL du serveur d'autorisation, permettent que la décision d'autorisation soit prise par un tiers, qui peut être distinct du client TLS et du serveur TLS.

La signification de authz_format_list est la suivante :

  • x509_attr_cert indique que les informations d'autorisation client sont un certificat d'attribut (AC) X.509 [ATTRCERT].

  • saml_assertion indique que les informations d'autorisation sont une assertion SAML [SAML1.1] [SAML2.0].

  • x509_attr_cert_url indique que les informations d'autorisation sont un certificat d'attribut (AC) X.509 [ATTRCERT] fourni sous forme d'URI [HTTP].

  • saml_assertion_url indique que les informations d'autorisation sont une assertion SAML [SAML1.1] [SAML2.0] fournie sous forme d'URI [HTTP].

Les données d'autorisation sont transportées dans un message SupplementalData [TLSSUPP]. Le client et le serveur savent quels messages SupplementalData sont utilisés en fonction de la ClientAuthzFormatList et de la ServerAuthzFormatList du message client hello étendu et du message server hello étendu. Les données pour chaque format d'autorisation dans la ClientAuthzFormatList et la ServerAuthzFormatList DOIVENT être incluses dans le même ordre dans le message SupplementalData.

2.2. Client Hello​

Le format du client hello TLS est présenté ici pour montrer le placement des extensions d'autorisation. La spécification complète du message client hello peut être trouvée dans [TLS1.0], [TLS1.1] et [TLS1.2].

Pour indiquer la prise en charge des informations d'autorisation au serveur TLS, les clients PEUVENT inclure une ou les deux extensions client_authz et server_authz dans un message client hello étendu.

Lorsque le client inclut l'extension client_authz, il indique l'ensemble des types de données d'autorisation (transportés dans les messages de poignée de main SupplementalData [TLSSUPP]) que le client est prêt à fournir au serveur.

Lorsque le client inclut l'extension server_authz, il indique l'ensemble des types de données d'autorisation (transportés dans les messages de poignée de main SupplementalData [TLSSUPP]) que le client est prêt à recevoir du serveur.

Les extensions client_authz et server_authz DOIVENT être omises du message client hello si le client initie une reprise de session.

La structure générale du message client hello étendu est définie dans [TLSEXT2], qui est reproduite ici par souci de clarté :

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;