1. Introduction

Le protocole Transport Layer Security (TLS) ([TLS1.0], [TLS1.1], [TLS1.2]) est utilisé dans une variété croissante d'environnements opérationnels, y compris ceux qui n'étaient pas envisagés au moment de la conception originale de TLS. Les extensions introduites dans ce document sont conçues pour permettre à TLS de fonctionner dans des environnements où des informations d'autorisation doivent être échangées entre le client et le serveur avant que des données protégées ne soient échangées. L'utilisation de ces extensions d'autorisation TLS est particulièrement intéressante lorsque plusieurs protocoles d'application peuvent utiliser les mêmes informations d'autorisation.

Le format et le contenu des informations d'autorisation transportées dans ces extensions sont extensibles. Ce document fait référence aux formats d'autorisation d'assertion Security Assertion Markup Language (SAML) ([SAML1.1], [SAML2.0]) et de certificat d'attribut (AC) X.509 [ATTRCERT], mais d'autres formats peuvent être utilisés. Les futures extensions d'autorisation peuvent inclure toute assertion opaque signée numériquement par un émetteur de confiance. Reconnaissant la similitude avec la validation du chemin de certification, ce document recommande l'utilisation de messages d'alerte TLS liés au traitement des certificats pour signaler les échecs de traitement des informations d'autorisation.

Une liaison directe des informations d'identification, d'authentification et d'autorisation à une session chiffrée est possible lorsque toutes ces informations sont gérées au sein de TLS. Si chaque application nécessite des informations d'autorisation uniques, il peut être préférable de les transporter dans le protocole d'application protégé par TLS. Cependant, il faut veiller à assurer des liaisons appropriées lorsque les informations d'identification, d'authentification et d'autorisation sont gérées à différentes couches de protocole.

Ce document décrit les extensions d'autorisation pour le protocole de poignée de main TLS dans TLS 1.0, TLS 1.1 et TLS 1.2. Ces extensions observent les conventions définies pour les extensions TLS qui ont été initialement définies dans [TLSEXT1] et révisées dans [TLSEXT2]; les extensions TLS font désormais partie de TLS 1.2 [TLS1.2]. Les extensions TLS utilisent des mécanismes d'extension généraux pour le message client hello et le message server hello. Les extensions décrites dans ce document confirment que le client et le serveur prennent tous deux en charge les types de données d'autorisation souhaités. Ensuite, si elles sont prises en charge, les informations d'autorisation sont échangées dans le message de poignée de main de données supplémentaires [TLSSUPP].

Les extensions d'autorisation peuvent être utilisées conjointement avec TLS 1.0, TLS 1.1 et TLS 1.2. Les extensions sont conçues pour être rétrocompatibles, ce qui signifie que les messages de données supplémentaires du protocole de poignée de main ne contiendront des informations d'autorisation d'un type particulier que si le client indique les prendre en charge dans le message client hello et que le serveur indique les prendre en charge dans le message server hello.

Les clients connaissent généralement le contexte de la session TLS en cours d'établissement; ainsi, le client peut utiliser les extensions d'autorisation lorsqu'elles sont nécessaires. Les serveurs doivent accepter les messages client hello étendus, même si le serveur ne "comprend" pas toutes les extensions répertoriées. Cependant, le serveur n'indiquera pas la prise en charge de ces extensions "non comprises". Les clients peuvent alors rejeter les communications avec les serveurs qui ne prennent pas en charge les extensions d'autorisation.

1.1. Conventions

La syntaxe des messages d'autorisation est définie à l'aide du langage de présentation TLS, qui est spécifié dans la section 4 de [TLS1.0].

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le RFC 2119 [STDWORDS].

1.2. Vue d'ensemble

La figure 1 illustre le placement des extensions d'autorisation et des messages de données supplémentaires dans la poignée de main TLS complète.

Le message ClientHello inclut une indication des formats de données d'autorisation client pris en charge et une indication des formats de données d'autorisation serveur pris en charge. Le message ServerHello contient des indications similaires, mais tous les formats de données d'autorisation non pris en charge par le serveur ne sont pas inclus. Le client et le serveur DOIVENT tous deux indiquer la prise en charge des types de données d'autorisation. Si la liste des formats de données d'autorisation mutuellement pris en charge est vide, le message ServerHello NE DOIT PAS porter du tout l'extension affectée.

Une reprise de session réussie utilise les mêmes informations d'autorisation que la session d'origine.

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

 *  Indique des messages optionnels ou dépendant de la situation qui
    ne sont pas toujours envoyés.

 [] Indique que ChangeCipherSpec est un type de contenu de protocole
    TLS indépendant; ce n'est en fait pas un message de poignée de
    main TLS.

   Figure 1.  Échange de données d'autorisation dans la poignée de main TLS complète