Aller au contenu principal

3. Opération StartTLS

L'opération Start Transport Layer Security (StartTLS), définie à la section 4.14 de [RFC4511], offre la possibilité d'établir TLS [RFC4346] dans une session LDAP.

Les objectifs de l'utilisation du protocole TLS avec LDAP sont de garantir la confidentialité et l'intégrité des données et, facultativement, de fournir une authentification. TLS fournit expressément ces capacités, bien que les services d'authentification de TLS ne soient disponibles pour LDAP qu'en combinaison avec la méthode d'authentification SASL EXTERNAL (voir la section 5.2.3), et encore uniquement si l'implémentation SASL EXTERNAL choisit d'utiliser les informations d'authentification de TLS.

3.1. Procédures d'établissement de TLS​

La présente section décrit les procédures générales que les clients et les serveurs doivent suivre pour l'établissement de TLS. Ces procédures tiennent compte de divers aspects de la couche TLS, notamment la découverte du niveau de sécurité résultant et la revendication de l'identité d'autorisation du client.

3.1.1. Séquencement des demandes StartTLS​

Un client peut envoyer la demande étendue StartTLS à tout moment après l'établissement d'une session LDAP, sauf :

  - lorsque TLS est actuellement établi sur la session,
  - lorsqu'une négociation SASL en plusieurs étapes est en cours sur la session, ou
  - lorsqu'il existe des réponses en attente pour des demandes d'opération précédemment émises sur la session.

Comme décrit dans [RFC4511], section 4.14.1, une violation (détectée) de l'une de ces exigences entraîne le renvoi du resultCode operationsError.

Les implémenteurs de clients devraient veiller à respecter strictement ces exigences de séquencement des opérations afin d'éviter des problèmes d'interopérabilité. L'expérience opérationnelle montre que la violation de ces exigences cause des problèmes d'interopérabilité, car il existe des conditions de concurrence qui empêchent les serveurs de détecter certaines violations de ces exigences, en raison de facteurs tels que la vitesse du matériel du serveur et les latences du réseau.

Il n'existe aucune exigence générale selon laquelle le client doit ou ne doit pas avoir déjà effectué une opération Bind (section 5) avant d'envoyer une demande d'opération StartTLS ; toutefois, lorsqu'un client a l'intention d'effectuer à la fois une opération Bind et une opération StartTLS, il DEVRAIT (SHOULD) d'abord effectuer l'opération StartTLS, afin que les messages de demande et de réponse Bind soient protégés par les services de sécurité des données établis par l'opération StartTLS.

3.1.2. Certificat client​

Si un serveur LDAP demande ou exige qu'un client fournisse un certificat d'utilisateur pendant la négociation TLS et que le client ne présente pas de certificat d'utilisateur approprié (par exemple un certificat pouvant être validé), le serveur peut utiliser une politique de sécurité locale pour déterminer s'il convient de mener à bien la négociation TLS.

Si un client qui a fourni un certificat approprié effectue ensuite une opération Bind en utilisant le mécanisme d'authentification SASL EXTERNAL (section 5.2.3), les informations contenues dans le certificat peuvent être utilisées par le serveur pour identifier et authentifier le client.

3.1.3. Vérification de l'identité du serveur​

Afin de prévenir les attaques de l'homme du milieu, le client DOIT (MUST) vérifier l'identité du serveur (telle que présentée dans le message Certificate du serveur). Dans la présente section, la compréhension qu'a le client de l'identité du serveur (généralement l'identité utilisée pour établir la connexion de transport) est appelée « identité de référence » (reference identity).

Le client détermine le type (par exemple nom DNS ou adresse IP) de l'identité de référence et effectue une comparaison entre l'identité de référence et chaque valeur subjectAltName du type correspondant, jusqu'à l'obtention d'une correspondance. Une fois une correspondance obtenue, l'identité du serveur a été vérifiée et la vérification de l'identité du serveur est terminée. Les différents types de subjectAltName sont mis en correspondance de différentes manières. Les sections 3.1.3.1 à 3.1.3.3 expliquent comment comparer les valeurs des divers types de subjectAltName.

Le client peut faire correspondre l'identité de référence à un type différent avant d'effectuer une comparaison. Des mises en correspondance peuvent être effectuées pour tous les types de subjectAltName disponibles vers lesquels l'identité de référence peut être mise en correspondance ; toutefois, l'identité de référence ne devrait être mise en correspondance qu'avec des types pour lesquels la mise en correspondance est soit intrinsèquement sûre (par exemple l'extraction du nom DNS d'une URI à comparer avec un subjectAltName de type dNSName), soit effectuée de manière sûre (par exemple en utilisant DNSSEC, ou des tables de correspondance hôte-vers-adresse / adresse-vers-hôte configurées par l'utilisateur ou l'administrateur).

L'identité du serveur peut également être vérifiée en comparant l'identité de référence à la valeur Common Name (CN) [RFC4519] du Relative Distinguished Name (RDN) feuille du champ subjectName du certificat du serveur. Cette comparaison est effectuée en utilisant les règles de comparaison des noms DNS de la section 3.1.3.1 ci-dessous, à l'exception du fait qu'aucune correspondance par caractère générique n'est autorisée. Bien que l'utilisation de la valeur Common Name soit une pratique existante, elle est déconseillée, et les autorités de certification sont encouragées à fournir à la place des valeurs subjectAltName. Notons que l'implémentation TLS peut représenter les DN dans les certificats selon X.500 ou d'autres conventions. Par exemple, certaines implémentations X.500 ordonnent les RDN d'un DN selon une convention gauche-à-droite (du plus significatif au moins significatif) au lieu de la convention droite-à-gauche de LDAP.

Si la vérification de l'identité du serveur échoue, les clients destinés à un utilisateur DEVRAIENT (SHOULD) soit avertir l'utilisateur (les clients peuvent donner à l'utilisateur la possibilité de poursuivre la session LDAP dans ce cas), soit fermer la connexion de transport et indiquer que l'identité du serveur est suspecte. Les clients automatisés DEVRAIENT (SHOULD) fermer la connexion de transport, puis renvoyer ou consigner une erreur indiquant que l'identité du serveur est suspecte, ou les deux.

Au-delà de la vérification de l'identité du serveur décrite dans la présente section, les clients devraient être prêts à effectuer d'autres vérifications pour s'assurer que le serveur est autorisé à fournir le service qu'il est prié de fournir. Le client peut avoir besoin d'utiliser des informations de politique locale pour prendre cette décision.

3.1.3.1. Comparaison des noms DNS​

Si l'identité de référence est un nom de domaine internationalisé, les implémentations conformes DOIVENT (MUST) le convertir au format ASCII Compatible Encoding (ACE) tel que spécifié à la section 4 de la RFC 3490 [RFC3490] avant de le comparer aux valeurs subjectAltName de type dNSName. Plus précisément, les implémentations conformes DOIVENT (MUST) effectuer l'opération de conversion spécifiée à la section 4 de la RFC 3490 comme suit :

  * à l'étape 1, le nom de domaine DOIT (SHALL) être considéré comme une « stored string » ;
  * à l'étape 3, définir le drapeau appelé « UseSTD3ASCIIRules » ;
  * à l'étape 4, traiter chaque étiquette à l'aide de l'opération « ToASCII » ; et
  * à l'étape 5, remplacer tous les séparateurs d'étiquettes par U+002E (point).

Après avoir effectué la conversion « to-ASCII », les étiquettes et les noms DNS DOIVENT (MUST) être comparés en vue de l'égalité selon les règles spécifiées à la section 3 de la RFC 3490.

Le caractère générique '*' (ASCII 42) est autorisé dans les valeurs subjectAltName de type dNSName, et ce uniquement en tant qu'étiquette DNS la plus à gauche (la moins significative) de cette valeur. Ce caractère générique correspond à toute étiquette DNS la plus à gauche du nom de serveur. Autrement dit, le sujet *.example.com correspond aux noms de serveur a.example.com et b.example.com, mais ne correspond ni à example.com ni à a.b.example.com.

3.1.3.2. Comparaison des adresses IP​

Lorsque l'identité de référence est une adresse IP, l'identité DOIT (MUST) être convertie en la représentation en chaîne d'octets en « ordre d'octets du réseau » [RFC791][RFC2460]. Pour IP version 4, comme spécifié dans la RFC 791, la chaîne d'octets contiendra exactement quatre octets. Pour IP version 6, comme spécifié dans la RFC 2460, la chaîne d'octets contiendra exactement seize octets. Cette chaîne d'octets est ensuite comparée aux valeurs subjectAltName de type iPAddress. Une correspondance se produit si la chaîne d'octets de l'identité de référence et les chaînes d'octets des valeurs sont identiques.

3.1.3.3. Comparaison d'autres types de subjectName​

Les implémentations de clients PEUVENT (MAY) prendre en charge la mise en correspondance avec des valeurs subjectAltName d'autres types, comme décrit dans d'autres documents.

3.1.4. Découverte du niveau de sécurité résultant​

Après l'établissement d'une couche TLS dans une session LDAP, les deux parties doivent chacune décider indépendamment de poursuivre ou non, en fonction de la politique locale et du niveau de sécurité atteint. Si l'une ou l'autre partie décide que le niveau de sécurité est insuffisant pour qu'elle poursuive, elle DEVRAIT (SHOULD) retirer la couche TLS immédiatement après la fin de la (re)négociation TLS (voir [RFC4511], section 4.14.3, et la section 3.2 ci-dessous). Les implémentations peuvent réévaluer le niveau de sécurité à tout moment et, le jugeant insuffisant, devraient retirer la couche TLS.

3.1.5. Actualisation des informations sur les capacités du serveur​

Après l'établissement d'une couche TLS dans une session LDAP, le client DEVRAIT (SHOULD) écarter ou actualiser toutes les informations sur le serveur qu'il a obtenues avant le début de la négociation TLS et qu'il n'a pas obtenues par des mécanismes sûrs. Cela protège contre les attaques de l'homme du milieu qui auraient pu altérer des informations sur les capacités du serveur récupérées avant l'installation de la couche TLS.

Le serveur peut annoncer des capacités différentes après l'installation d'une couche TLS. En particulier, la valeur de 'supportedSASLMechanisms' peut être différente après l'installation d'une couche TLS (plus précisément, les mécanismes EXTERNAL et PLAIN [PLAIN] ne sont susceptibles d'être listés qu'après l'installation d'une couche TLS).

3.2. Effet de TLS sur l'état d'autorisation​

L'établissement, la modification et/ou la fermeture de TLS peuvent faire passer l'état d'autorisation à un nouvel état. Ce point est examiné plus en détail à la section 4.

3.3. Suites de chiffrement TLS​

Plusieurs questions devraient être prises en compte lors du choix des suites de chiffrement TLS appropriées à une situation donnée. Ces questions comprennent notamment :

  - La capacité de la suite de chiffrement à fournir une protection de confidentialité adéquate pour les mots de passe et les autres données envoyées sur la connexion de transport. Les implémenteurs de clients et de serveurs devraient reconnaître que certaines suites de chiffrement TLS n'offrent aucune protection de confidentialité, tandis que d'autres, qui en offrent une, peuvent être vulnérables à un cassage par force brute, notamment à la lumière de vitesses de processeur toujours croissantes qui réduisent le temps nécessaire pour mener à bien de telles attaques ;

  - Les implémenteurs de clients et de serveurs devraient examiner attentivement la valeur du mot de passe ou des données protégées par rapport au niveau de protection de la confidentialité fourni par la suite de chiffrement, afin de s'assurer que le niveau de protection offert par la suite est approprié ;

  - La vulnérabilité (ou l'absence de vulnérabilité) de la suite de chiffrement aux attaques de l'homme du milieu. Les suites vulnérables aux attaques de l'homme du milieu NE DEVRAIENT PAS (SHOULD NOT) être utilisées pour protéger des mots de passe ou des données sensibles, sauf si la configuration du réseau est telle que le danger d'une attaque de l'homme du milieu est négligeable ;

  - Après l'achèvement d'une négociation TLS (initiale ou ultérieure), les deux homologues du protocole devraient vérifier indépendamment que les services de sécurité fournis par la suite de chiffrement négociée sont adéquats pour l'usage prévu de la session LDAP. S'ils ne le sont pas, la couche TLS devrait être fermée.