Aller au contenu principal

5. Opération Bind

L'opération Bind ([RFC4511], section 4.2) permet l'échange d'informations d'authentification entre le client et le serveur afin d'établir un nouvel état d'autorisation.

La demande Bind spécifie généralement l'identité d'authentification souhaitée. Certains mécanismes Bind permettent également au client de spécifier l'identité d'autorisation. Si l'identité d'autorisation n'est pas spécifiée, le serveur la dérive de l'identité d'authentification d'une manière propre à l'implémentation.

Si l'identité d'autorisation est spécifiée, le serveur DOIT (MUST) vérifier que l'identité d'authentification du client est autorisée à endosser (par exemple à se substituer à) l'identité d'autorisation revendiquée. Le serveur DOIT (MUST) rejeter l'opération Bind avec un resultCode invalidCredentials dans la réponse Bind si le client n'y est pas ainsi autorisé.

5.1. Méthode d'authentification simple​

La méthode d'authentification simple de l'opération Bind fournit trois mécanismes d'authentification :

  - Un mécanisme d'authentification anonyme (section 5.1.1).

  - Un mécanisme d'authentification non authentifié (section 5.1.2).

  - Un mécanisme d'authentification nom/mot de passe utilisant des informations d'authentification composées d'un nom (sous la forme d'un nom distingué LDAP [RFC4514]) et d'un mot de passe (section 5.1.3).

5.1.1. Mécanisme d'authentification anonyme de Bind simple​

Un client LDAP peut utiliser le mécanisme d'authentification anonyme de la méthode Bind simple pour établir explicitement un état d'autorisation anonyme en envoyant une demande Bind avec une valeur de nom de longueur nulle et en spécifiant le choix d'authentification simple contenant une valeur de mot de passe de longueur nulle.

5.1.2. Mécanisme d'authentification non authentifié de Bind simple​

Un client LDAP peut utiliser le mécanisme d'authentification non authentifié de la méthode Bind simple pour établir un état d'autorisation anonyme en envoyant une demande Bind avec une valeur de nom (un nom distingué sous forme de chaîne LDAP [RFC4514] de longueur non nulle) et en spécifiant le choix d'authentification simple contenant une valeur de mot de passe de longueur nulle.

La valeur de nom distingué fournie par le client est destinée à être utilisée uniquement à des fins de traçage (par exemple la journalisation). La valeur ne doit pas être authentifiée ni autrement validée (y compris la vérification que le DN désigne un objet d'annuaire existant). La valeur ne doit pas être utilisée (directement ou indirectement) à des fins d'autorisation.

Les opérations Bind non authentifiées peuvent présenter des problèmes de sécurité importants (voir la section 6.3.1). En particulier, les utilisateurs souhaitant effectuer une authentification nom/mot de passe peuvent fournir par inadvertance un mot de passe vide et amener ainsi des clients mal implémentés à demander un accès non authentifié. Les clients DEVRAIENT (SHOULD) être implémentés de manière à exiger que l'utilisateur choisisse le mécanisme d'authentification non authentifié par un moyen autre que la saisie d'un mot de passe vide. Les clients DEVRAIENT (SHOULD) interdire la saisie d'un mot de passe vide dans une interface utilisateur d'authentification nom/mot de passe. En outre, les serveurs DEVRAIENT (SHOULD) par défaut faire échouer les demandes Bind non authentifiées avec un resultCode unwillingToPerform.

5.1.3. Mécanisme d'authentification nom/mot de passe de Bind simple​

Un client LDAP peut utiliser le mécanisme d'authentification nom/mot de passe de la méthode Bind simple pour établir un état d'autorisation authentifié en envoyant une demande Bind avec une valeur de nom (un nom distingué sous forme de chaîne LDAP [RFC4514] de longueur non nulle) et en spécifiant le choix d'authentification simple contenant une valeur de mot de passe OCTET STRING de longueur non nulle.

Les serveurs qui font correspondre le DN envoyé dans la demande Bind à une entrée d'annuaire associée à un ensemble d'un ou plusieurs mots de passe utilisés avec ce mécanisme compareront le mot de passe présenté à cet ensemble de mots de passe. Le mot de passe présenté est considéré comme valide s'il correspond à un membre quelconque de cet ensemble.

Un resultCode invalidDNSyntax indique que le DN envoyé dans la valeur de nom est syntaxiquement invalide. Un resultCode invalidCredentials indique que le DN est syntaxiquement correct mais non valide à des fins d'authentification, que le mot de passe n'est pas valide pour ce DN, ou que le serveur considère autrement les informations d'authentification comme invalides. Un resultCode success indique que les informations d'authentification sont valides et que le serveur est disposé à fournir le service à l'entité que ces informations identifient.

Le comportement du serveur n'est pas défini pour les demandes Bind spécifiant le mécanisme d'authentification nom/mot de passe avec une valeur de nom de longueur nulle et une valeur de mot de passe de longueur non nulle.

Le mécanisme d'authentification nom/mot de passe de la méthode Bind simple ne convient pas à l'authentification dans les environnements dépourvus de protection de confidentialité.

5.2. Méthode d'authentification SASL​

La méthode d'authentification sasl de l'opération Bind fournit les moyens d'utiliser tout mécanisme SASL, y compris des mécanismes d'authentification et d'autres services (par exemple des services de sécurité des données).

5.2.1. Profil de protocole SASL​

LDAP permet l'authentification via tout mécanisme SASL [RFC4422]. Comme LDAP comprend des méthodes d'authentification natives anonyme et nom/mot de passe (en clair), les mécanismes SASL ANONYMOUS [RFC4505] et PLAIN [PLAIN] ne sont généralement pas utilisés avec LDAP.

Chaque protocole qui utilise les services SASL est tenu de fournir certaines informations décrivant la manière dont ils sont exposés à travers le protocole ([RFC4422], section 4). La présente section explique comment chacune de ces exigences de profilage est satisfaite par LDAP.

5.2.1.1. Nom de service SASL pour LDAP​

Le nom de service SASL pour LDAP est « ldap », qui a été enregistré auprès de l'IANA comme nom de service SASL.

5.2.1.2. Lancement de l'authentification SASL et échange de protocole​

L'authentification SASL est lancée au moyen d'un message BindRequest ([RFC4511], section 4.2) avec les paramètres suivants :

  - La version est 3.
  - AuthenticationChoice est sasl.
  - L'élément mechanism de la séquence SaslCredentials contient la valeur du mécanisme SASL souhaité.
  - Le champ facultatif credentials de la séquence SaslCredentials PEUT (MAY) être utilisé pour fournir une réponse initiale du client pour les mécanismes définis comme faisant envoyer des données au client en premier (voir [RFC4422], sections 3 et 5).

En général, un échange de protocole d'authentification SASL consiste en une série de défis du serveur (challenges) et de réponses du client, dont le contenu est propre au mécanisme SASL et défini par celui-ci. Ainsi, pour certains mécanismes d'authentification SASL, il peut être nécessaire que le client réponde à un ou plusieurs défis du serveur en envoyant plusieurs fois des messages BindRequest. Un défi est indiqué par l'envoi, par le serveur, d'un message BindResponse dont le resultCode est

saslBindInProgress. Cela indique que le serveur demande au client d'envoyer un nouveau message BindRequest avec le même mécanisme SASL pour poursuivre le processus d'authentification.

Pour la couche de messages LDAP, ces défis et réponses sont des jetons binaires opaques de longueur arbitraire. Les serveurs LDAP utilisent le champ serverSaslCreds (un OCTET STRING) d'un message BindResponse pour transmettre chaque défi. Les clients LDAP utilisent le champ credentials (un OCTET STRING) de la séquence SaslCredentials d'un message BindRequest pour transmettre chaque réponse. Notons que, contrairement à certains protocoles Internet où SASL est utilisé, LDAP n'est pas fondé sur du texte et n'effectue pas de transformation Base64 de ces valeurs de défi et de réponse.

Les clients envoyant un message BindRequest avec le choix sasl sélectionné DEVRAIENT (SHOULD) envoyer une valeur de longueur nulle dans le champ name. Les serveurs recevant un message BindRequest avec le choix sasl sélectionné IGNORERONT (SHALL) toute valeur du champ name.

Un client peut abandonner une négociation Bind SASL en envoyant un message BindRequest avec une valeur différente dans le champ mechanism de SaslCredentials, ou avec un AuthenticationChoice autre que sasl.

Si le client envoie une BindRequest dont le champ mechanism de sasl est une chaîne vide, le serveur DOIT (MUST) renvoyer une BindResponse avec un resultCode authMethodNotSupported. Cela permettra au client d'abandonner une négociation s'il souhaite réessayer avec le même mécanisme SASL.

Le serveur indique l'achèvement de l'échange défi-réponse SASL en répondant par une BindResponse dont la valeur de resultCode n'est pas saslBindInProgress.

Le champ serverSaslCreds de la BindResponse peut être utilisé pour inclure un défi facultatif avec une notification de succès, pour les mécanismes définis comme faisant envoyer des données supplémentaires par le serveur en même temps que l'indication de la réussite.

5.2.1.3. Champs facultatifs​

Comme indiqué ci-dessus, LDAP fournit un champ facultatif pour transporter une réponse initiale dans le message qui lance l'échange SASL, et fournit un champ facultatif pour transporter des données supplémentaires dans le message indiquant le résultat de l'échange d'authentification. Le contenu propre au mécanisme de ces champs pouvant être de longueur nulle, SASL exige que les spécifications de protocole détaillent la manière dont un champ vide se distingue d'un champ absent.

Une donnée de réponse initiale de longueur nulle se distingue de l'absence de donnée de réponse initiale, dans le message de lancement (une PDU BindRequest), par la présence de l'OCTET STRING SaslCredentials.credentials (de longueur nulle) dans cette PDU. Si le client n'a pas l'intention d'envoyer de réponse initiale avec la BindRequest qui lance l'échange SASL, il DOIT (MUST) omettre l'OCTET STRING SaslCredentials.credentials (plutôt que d'inclure un OCTET STRING de longueur nulle).

Une donnée supplémentaire de longueur nulle se distingue de l'absence de donnée de réponse supplémentaire, dans le message de résultat (une PDU BindResponse), par la présence de l'OCTET STRING serverSaslCreds (de longueur nulle) dans cette PDU. Si un serveur n'a pas l'intention d'envoyer de données supplémentaires dans le message BindResponse indiquant le résultat de l'échange, le serveur DOIT (SHALL) omettre l'OCTET STRING serverSaslCreds (plutôt que d'inclure un OCTET STRING de longueur nulle).

5.2.1.4. Octet où les couches de sécurité négociées prennent effet​

Les couches SASL prennent effet après la transmission par le serveur et la réception par le client de la BindResponse finale de l'échange SASL, avec un resultCode success.

Une fois qu'une couche SASL fournissant des services d'intégrité ou de confidentialité des données prend effet, la couche reste en vigueur jusqu'à l'installation d'une nouvelle couche (c'est-à-dire au premier octet suivant la BindResponse finale de l'opération Bind qui a fait prendre effet à la nouvelle couche). Ainsi, une couche SASL établie n'est pas affectée par un Bind échoué ou non SASL.

5.2.1.5. Détermination des mécanismes SASL pris en charge​

Les clients peuvent déterminer les mécanismes SASL qu'un serveur prend en charge en lisant l'attribut 'supportedSASLMechanisms' du DSE racine (DSA-Specific Entry) ([RFC4512], section 5.1). Les valeurs de cet attribut, le cas échéant, énumèrent les mécanismes que le serveur prend en charge dans l'état actuel de la session LDAP. Les serveurs LDAP DEVRAIENT (SHOULD) permettre à tous les clients — même ceux disposant d'une autorisation anonyme — de récupérer l'attribut 'supportedSASLMechanisms' du DSE racine à la fois avant et après l'échange d'authentification SASL. Le but de cette dernière récupération est de permettre au client de détecter d'éventuelles attaques par rétrogradation (voir la section 6.4 et [RFC4422], section 6.1.2).

Les mécanismes SASL fournissant des fonctions de sécurité critiques, les clients et les serveurs devraient être configurables pour spécifier quels mécanismes sont acceptables et n'autoriser l'utilisation que de ces mécanismes. Les clients comme les serveurs doivent confirmer que le niveau de sécurité négocié répond à leurs exigences avant de commencer à utiliser la session.

5.2.1.6. Règles d'utilisation des couches SASL​

Lors de l'installation d'une couche SASL, 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 SASL et qu'il n'a pas obtenues par des mécanismes sûrs.

Si une couche de sécurité de niveau inférieur (telle que TLS) est installée, toute couche SASL DOIT (SHALL) être superposée à ces couches de sécurité, indépendamment de l'ordre de leur négociation. À tous autres égards, la couche SASL et les autres couches de sécurité agissent indépendamment : par exemple, si une couche TLS et une couche SASL sont toutes deux en vigueur, le retrait de la couche TLS n'affecte pas le service continu de la couche SASL.

5.2.1.7. Prise en charge d'authentifications multiples​

LDAP prend en charge plusieurs authentifications SASL, telles que définies dans [RFC4422], section 4.

5.2.1.8. Identités d'autorisation SASL​

Certains mécanismes SASL permettent aux clients de demander une identité d'autorisation souhaitée pour la session LDAP ([RFC4422], section 3.4). La décision d'autoriser ou non l'identité d'authentification actuelle à accéder à l'identité d'autorisation demandée relève de la politique locale. L'identité d'autorisation est une chaîne de caractères [Unicode] encodés en UTF-8 [RFC3629] correspondant à la grammaire Augmented Backus-Naur Form (ABNF) [RFC4234] suivante :

  authzId = dnAuthzId / uAuthzId

  ; distinguished-name-based authz id
  dnAuthzId =  "dn:" distinguishedName

  ; unspecified authorization id, UTF-8 encoded
  uAuthzId = "u:" userid
  userid = *UTF8 ; syntax unspecified

où la règle distinguishedName est définie à la section 3 de [RFC4514] et la règle UTF8 est définie à la section 1.4 de [RFC4512].

Le choix dnAuthzId est utilisé pour revendiquer des identités d'autorisation sous la forme d'un nom distingué, à mettre en correspondance conformément à la règle de correspondance distinguishedNameMatch ([RFC4517], section 4.2.15). Il n'est pas exigé que la valeur distinguishedName revendiquée soit celle d'une entrée de l'annuaire.

Le choix uAuthzId permet aux clients de revendiquer une identité d'autorisation qui n'est pas sous forme de nom distingué. Le format de userid n'est défini que comme une séquence de caractères [Unicode] encodés en UTF-8 [RFC3629], et toute interprétation supplémentaire relève de l'affaire locale. Par exemple, le userid peut identifier un utilisateur d'un service d'annuaire spécifique, être un nom de connexion ou être une adresse de messagerie. Un uAuthzId NE DEVRAIT PAS (SHOULD NOT) être supposé globalement unique. Pour comparer des valeurs uAuthzId, chaque valeur uAuthzId DOIT (MUST) être préparée comme chaîne « query » ([RFC3454], section 7) à l'aide de l'algorithme SASLprep [RFC4013], puis les deux valeurs sont comparées octet par octet.

La grammaire ci-dessus est extensible. La production authzId peut être étendue pour prendre en charge des formes supplémentaires d'identités. Chaque forme se distingue par son préfixe unique (voir la section 3.12 de [RFC4520] pour les exigences d'enregistrement).

5.2.2. Sémantique de SASL au sein de LDAP​

Les implémenteurs doivent veiller à préserver la sémantique des spécifications SASL lorsqu'ils traitent des données qui ont une sémantique différente dans le protocole LDAP.

Par exemple, le mécanisme d'authentification SASL DIGEST-MD5 [DIGEST-MD5] utilise une identité d'authentification et un domaine (realm) qui sont syntaxiquement des chaînes simples et sémantiquement des valeurs simples de nom d'utilisateur [RFC4013] et de domaine. Ces valeurs ne sont pas des DN LDAP, et il n'est pas exigé qu'elles soient représentées ou traitées comme telles.

5.2.3. Mécanisme d'authentification SASL EXTERNAL​

Un client peut utiliser le mécanisme SASL EXTERNAL ([RFC4422], annexe A) pour demander au serveur LDAP de l'authentifier et d'établir une identité d'autorisation résultante, en utilisant les informations d'authentification de sécurité échangées par une couche de sécurité inférieure (par exemple par l'authentification TLS). Si les informations d'authentification du client n'ont pas été établies à une couche de sécurité inférieure, le Bind SASL EXTERNAL DOIT (MUST) échouer avec un resultCode inappropriateAuthentication. Bien que cette situation ait pour effet de laisser la session LDAP dans un état anonyme (section 4), l'état de toute couche de sécurité installée n'est pas affecté.

Un client peut soit demander que son identité d'autorisation soit automatiquement dérivée de ses informations d'authentification échangées à une couche de sécurité inférieure, soit fournir explicitement une identité d'autorisation souhaitée. La première est appelée revendication implicite, la seconde revendication explicite.

5.2.3.1. Revendication implicite​

Une revendication implicite d'identité d'autorisation est effectuée en invoquant une demande Bind de la forme SASL utilisant le nom de mécanisme EXTERNAL, sans inclure le champ facultatif credentials (situé dans la séquence SaslCredentials de la BindRequest). Le serveur dérive l'identité d'autorisation du client de l'identité d'authentification fournie par une couche de sécurité (par exemple un certificat de clé publique utilisé pendant l'installation de la couche TLS), conformément à la politique locale. Les mécanismes sous-jacents de cette opération sont propres à l'implémentation.

5.2.3.2. Revendication explicite​

Une revendication explicite d'identité d'autorisation est effectuée en invoquant une demande Bind de la forme SASL utilisant le nom de mécanisme EXTERNAL, en incluant le champ credentials (situé dans la séquence SaslCredentials de la BindRequest). La valeur du champ credentials (un OCTET STRING) est l'identité d'autorisation revendiquée et DOIT (MUST) être construite comme documenté à la section 5.2.1.8.