Aller au contenu principal

Annexe B. Résumé des modifications

La présente annexe n'a pas de caractère normatif.

La présente annexe résume les changements substantiels apportés aux RFC 2251, RFC 2829 et RFC 2830. Outre les changements spécifiques détaillés ci-dessous, le lecteur du présent document doit savoir que de nombreux changements rédactionnels généraux ont été apportés au contenu original des documents sources. Ces changements comprennent les suivants :

  • Les éléments initialement présents dans les sections 4.2.1 et 4.2.2 de la RFC 2251, dans la RFC 2829 (toutes les sections sauf les sections 2 et 4) et dans la RFC 2830 ont été réunis en un seul document.

  • Les éléments ainsi réunis ont été substantiellement réorganisés et remaniés afin de regrouper les sujets connexes, d'améliorer la fluidité du document et de clarifier l'intention.

  • Des changements ont été apportés dans tout le texte pour l'aligner sur les définitions des couches de protocole LDAP et la terminologie de sécurité de l'IETF.

  • Des mises à jour et des ajouts substantiels ont été apportés aux considérations de sécurité des deux documents, sur la base de l'expérience opérationnelle actuelle.

B.1. Modifications apportées à la RFC 2251​

La présente section résume les changements substantiels apportés par le présent document aux sections 4.2.1 et 4.2.2 de la RFC 2251. D'autres changements substantiels apportés à la section 4.2.1 de la RFC 2251 sont également documentés dans [RFC4511].

B.1.1. Section 4.2.1 (« Séquencement de la demande Bind »)​

  • Paragraphe 1 : suppression de la phrase « If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection ». L'opération Unbind permet toujours ce comportement, mais il n'est pas documenté explicitement.

  • Précision apportée sur le fait que la session passe à un état anonyme dès la réception de la PDU BindRequest et qu'elle ne passe à un état non anonyme que si et quand la demande Bind réussit.

B.1.2. Section 4.2.2 (« Authentification et autres services de sécurité »)​

  • La RFC 2251 indique que l'authentification anonyme DOIT (MUST) être effectuée au moyen de la méthode bind simple. La présente spécification définit le mécanisme d'authentification anonyme de la méthode bind simple et exige que toutes les implémentations conformes le prennent en charge. D'autres mécanismes d'authentification produisant un état d'authentification et d'autorisation anonyme peuvent également être mis en œuvre et utilisés par les implémentations conformes.

B.2. Modifications apportées à la RFC 2829​

La présente section résume les changements substantiels apportés à la RFC 2829.

B.2.1. Section 4 (« Mécanismes de sécurité exigés »)​

  • Le mécanisme d'authentification nom/mot de passe (voir la section B.2.5 ci-dessous), protégé par TLS, remplace le mécanisme SASL DIGEST-MD5 comme mécanisme d'authentification fondé sur un mot de passe obligatoire à mettre en œuvre dans LDAP. Les implémentations sont encouragées à continuer de prendre en charge SASL DIGEST-MD5 [DIGEST-MD5].

B.2.2. Section 5.1 (« Procédure d'authentification anonyme »)​

  • Précision apportée sur le fait que l'authentification anonyme suppose une valeur de nom de longueur nulle et une valeur de mot de passe de longueur nulle. Le mécanisme d'authentification non authentifié a été ajouté pour traiter les demandes Bind simples comportant une valeur de nom de longueur non nulle et une valeur de mot de passe de longueur nulle.

B.2.3. Section 6 (« Authentification fondée sur un mot de passe »)​

  • Voir la section B.2.1.

B.2.4. Section 6.1 (« Authentification Digest »)​

  • Le mécanisme SASL-DIGEST-MD5 n'étant plus obligatoire à mettre en œuvre, cette section est désormais historique et n'a pas été reprise dans le présent document. La section 6.1 de la RFC 2829 continue de documenter le mécanisme d'authentification SASL DIGEST-MD5.

B.2.5. Section 6.2 (« Choix d'authentification "simple" sous chiffrement TLS »)​

  • Le mécanisme d'authentification « simple » a été renommé mécanisme d'authentification nom/mot de passe, afin de mieux le décrire.

  • L'utilisation de TLS a été généralisée pour l'aligner sur les définitions des couches de protocole LDAP. L'établissement de TLS est désormais examiné comme un sujet indépendant et généralisé pour être utilisé avec tous les mécanismes d'authentification et les autres couches de sécurité.

  • Suppression de l'implication selon laquelle l'attribut userPassword est le seul emplacement de stockage des valeurs de mot de passe utilisées pour l'authentification. Il n'existe plus aucune exigence implicite quant à la manière dont les mots de passe sont stockés sur le serveur pour l'authentification, ni à l'endroit où ils le sont.

B.2.6. Section 6.3 (« Autres choix d'authentification avec TLS »)​

  • Voir la section B.2.5.

B.2.7. Section 7.1 (« Authentification par certificat avec TLS »)​

  • Voir la section B.2.5.

B.2.8. Section 8 (« Autres mécanismes »)​

  • Tous les mécanismes d'authentification SASL sont explicitement autorisés au sein de LDAP. Concrètement, cela signifie que les mécanismes SASL ANONYMOUS et SASL PLAIN ne sont plus exclus de l'utilisation au sein de LDAP.

B.2.9. Section 9 (« Identité d'autorisation »)​

  • Spécification des règles de correspondance pour les valeurs dnAuthzId et uAuthzId. En particulier, la valeur DN de la forme dnAuthzId doit être mise en correspondance à l'aide des règles de correspondance de DN, et la valeur uAuthzId DOIT (MUST) être préparée à l'aide des règles SASLprep avant d'être comparée octet par octet.

  • Précision apportée sur le fait que les valeurs uAuthzId ne doivent pas être supposées globalement uniques.

B.2.10. Section 10 (« Suites de chiffrement TLS »)​

  • Les recommandations relatives aux suites de chiffrement TLS ne figurent plus dans la présente spécification. Les implémentations doivent désormais prendre en charge la suite de chiffrement TLS_RSA_WITH_3DES_EDE_CBC_SHA et devraient continuer de prendre en charge la suite de chiffrement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

  • Précision apportée sur le fait que l'authentification anonyme suppose une valeur de nom de longueur nulle et une valeur de mot de passe de longueur nulle. Le mécanisme d'authentification non authentifié a été ajouté pour traiter les demandes Bind simples comportant une valeur de nom de longueur non nulle et une valeur de mot de passe de longueur nulle.

B.3. Modifications apportées à la RFC 2830​

La présente section résume les changements substantiels apportés aux sections 3 et 5 de la RFC 2830. Les lecteurs sont invités à consulter [RFC4511] pour les résumés des changements apportés aux autres sections.

B.3.1. Section 3.6 (« Vérification de l'identité du serveur »)​

  • Mise à jour substantielle de l'algorithme de vérification de l'identité du serveur afin de garantir qu'il est complet et robuste. En particulier, l'utilisation de toutes les valeurs pertinentes des champs subjectAltName et subjectName est couverte par l'algorithme, et des règles de correspondance sont spécifiées pour chaque type de valeur. Les formes mises en correspondance (dérivées) de l'identité du serveur peuvent désormais être utilisées lorsque la mise en correspondance est effectuée de manière sûre.

B.3.2. Section 3.7 (« Actualisation des informations sur les capacités du serveur »)​

  • Les clients ne sont plus tenus d'actualiser systématiquement les informations sur les capacités du serveur après l'établissement de TLS. Il s'agit de tenir compte des situations où ces informations ont été obtenues par un mécanisme sûr.

B.3.3. Section 5 (« Effets de TLS sur l'identité d'autorisation d'un client »)​

  • L'établissement d'une couche TLS sur une session LDAP peut désormais entraîner un changement de l'état d'autorisation de la session LDAP.

B.3.4. Section 5.2 (« Effets de la fermeture de la connexion TLS »)​

  • La fermeture d'une couche TLS sur une session LDAP modifie l'état d'authentification et d'autorisation de la session LDAP en fonction de la politique locale. Concrètement, cela signifie que les implémentations ne sont pas tenues de ramener les états d'authentification et d'autorisation à l'état anonyme lors de la fermeture de TLS.

  • Remplacement des références à la RFC 2401 par la RFC 4301.