RFC 4517 - Lightweight Directory Access Protocol (LDAP) : Syntaxes and Matching Rules

• Statut: Proposed Standard
• Publié: June 2006
• Stream: IETF
• Met à jour: RFC3698
• Remplace: RFC2252, RFC2256
• Errata: Pas d'errata

---

Résumé

Chaque attribut stocké dans un annuaire LDAP (Lightweight Directory Access Protocol), dont les valeurs peuvent être transférées dans le protocole LDAP, a une syntaxe définie qui contraint la structure et le format de ses valeurs. La sémantique de comparaison pour les valeurs d'une syntaxe ne fait pas partie de la définition de la syntaxe mais est plutôt fournie par des règles de correspondance définies séparément. Les règles de correspondance spécifient un argument, une valeur d'assertion, qui a également une syntaxe définie. Ce document définit un ensemble de base de syntaxes et de règles de correspondance à utiliser pour définir des attributs pour les annuaires LDAP.

Table des matières

1. Introduction
2. Conventions
3. Syntaxes 3.1. Considérations générales 3.2. Définitions communes 3.3. Définitions de syntaxe 3.3.1. Description de type d'attribut (Attribute Type Description) 3.3.2. Chaîne de bits (Bit String) 3.3.3. Booléen (Boolean) 3.3.4. Chaîne de pays (Country String) 3.3.5. Méthode de livraison (Delivery Method) 3.3.6. Chaîne d'annuaire (Directory String) 3.3.7. Description de règle de contenu DIT (DIT Content Rule Description) 3.3.8. Description de règle de structure DIT (DIT Structure Rule Description) 3.3.9. DN 3.3.10. Guide amélioré (Enhanced Guide) 3.3.11. Numéro de téléphone de télécopie (Facsimile Telephone Number) 3.3.12. Fax (Fax) 3.3.13. Temps généralisé (Generalized Time) 3.3.14. Guide (Guide) 3.3.15. Chaîne IA5 (IA5 String) 3.3.16. Entier (Integer) 3.3.17. JPEG 3.3.18. Description de syntaxe LDAP (LDAP Syntax Description) 3.3.19. Description de règle de correspondance (Matching Rule Description) 3.3.20. Description d'utilisation de règle de correspondance (Matching Rule Use Description) 3.3.21. Nom et UID optionnel (Name and Optional UID) 3.3.22. Description de forme de nom (Name Form Description) 3.3.23. Chaîne numérique (Numeric String) 3.3.24. Description de classe d'objet (Object Class Description) 3.3.25. Chaîne d'octets (Octet String) 3.3.26. OID 3.3.27. Autre boîte aux lettres (Other Mailbox) 3.3.28. Adresse postale (Postal Address) 3.3.29. Chaîne imprimable (Printable String) 3.3.30. Assertion de sous-chaîne (Substring Assertion) 3.3.31. Numéro de téléphone (Telephone Number) 3.3.32. Identifiant de terminal télétex (Teletex Terminal Identifier) 3.3.33. Numéro de télex (Telex Number) 3.3.34. Temps UTC (UTC Time)
4. Règles de correspondance 4.1. Considérations générales 4.2. Définitions de règles de correspondance
5. Considérations de sécurité
6. Remerciements
7. Considérations IANA
8. Références Annexe A. Résumé des identificateurs d'objet de syntaxe Annexe B. Changements par rapport à la RFC 2252

1. Introduction

Chaque attribut stocké dans un annuaire LDAP (Lightweight Directory Access Protocol) [RFC4510], dont les valeurs peuvent être transférées dans le protocole LDAP [RFC4511], a une syntaxe définie (c'est-à-dire un type de données) qui contraint la structure et le format de ses valeurs. La sémantique de comparaison pour les valeurs d'une syntaxe ne fait pas partie de la définition de la syntaxe mais est plutôt fournie par des règles de correspondance définies séparément. Les règles de correspondance spécifient un argument, une valeur d'assertion, qui a également une syntaxe définie. Ce document définit un ensemble de base de syntaxes et de règles de correspondance à utiliser pour définir des attributs pour les annuaires LDAP.

Il est conseillé aux lecteurs de se familiariser avec les modèles d'informations d'annuaire [RFC4512] avant de lire le reste de ce document. La section 3 fournit des définitions pour l'ensemble de base des syntaxes LDAP. La section 4 fournit des définitions pour l'ensemble de base des règles de correspondance pour LDAP.

Ce document fait partie intégrante de la spécification technique LDAP [RFC4510], qui rend obsolète la spécification technique LDAP précédemment définie, RFC 3377, dans son intégralité.

Les sections 4, 5 et 7 de la RFC 2252 sont rendues obsolètes par [RFC4512]. Le reste de la RFC 2252 est rendu obsolète par ce document. Les sections 6 et 8 de la RFC 2256 sont rendues obsolètes par ce document. Le reste de la RFC 2256 est rendu obsolète par [RFC4519] et [RFC4512]. Tout sauf la section 2.11 de la RFC 3698 est rendu obsolète par ce document.

Un certain nombre d'éléments de schéma qui étaient inclus dans la révision précédente de la spécification technique LDAP ne sont pas inclus dans cette révision de LDAP. Les éléments de schéma d'infrastructure à clé publique sont maintenant spécifiés dans [RFC4523]. À moins d'être réintroduits dans de futures spécifications techniques, le reste doit être considéré comme historique.

Les changements par rapport à la RFC 2252 sont décrits à l'annexe B de ce document.

2. Conventions

Dans ce document, les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" doivent être interprétés comme décrit dans BCP 14, RFC 2119 [RFC2119].

3. Syntaxes

Les définitions de syntaxe contraignent la structure des valeurs d'attribut stockées dans un annuaire LDAP et déterminent la représentation des valeurs d'attribut et d'assertion transférées dans le protocole LDAP.

Les syntaxes requises pour le fonctionnement de l'annuaire, ou qui sont d'usage courant, sont spécifiées dans cette section. Les serveurs DEVRAIENT reconnaître toutes les syntaxes répertoriées dans ce document, mais ne sont pas tenus de les prendre en charge autrement, et PEUVENT reconnaître ou prendre en charge d'autres syntaxes. Cependant, la définition de syntaxes arbitraires supplémentaires est déconseillée car elle entravera l'interopérabilité. Les implémentations client et serveur n'ont généralement pas la capacité de reconnaître dynamiquement de nouvelles syntaxes.

3.1. Considérations générales

La description de chaque syntaxe spécifie comment les valeurs d'attribut ou d'assertion conformes à la syntaxe doivent être représentées lors de leur transfert dans le protocole LDAP [RFC4511]. Cette représentation est appelée encodage spécifique à LDAP pour la distinguer des autres méthodes d'encodage des valeurs d'attribut (par exemple, l'encodage des règles d'encodage de base (BER) [BER] utilisé par les annuaires X.500 [X.500]).

3.2. Définitions communes

Les règles ABNF suivantes sont utilisées dans un certain nombre de définitions de syntaxe de la section 3.3.

      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
                           PLUS / COMMA / HYPHEN / DOT / EQUALS /
                           SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")

3.3. Définitions de syntaxe

(Les définitions détaillées des syntaxes spécifiques sont omises ici. Veuillez vous référer au document original.)

4. Règles de correspondance

Les règles de correspondance définissent l'algorithme à utiliser pour comparer une valeur d'attribut et une valeur d'assertion.

4.1. Considérations générales

Chaque règle de correspondance est identifiée de manière unique par un identificateur d'objet [ASN.1]. Les règles de correspondance définies dans ce document ont également un nom court (descripteur).

Les définitions de règles de correspondance spécifient la syntaxe de la valeur d'assertion à comparer. La syntaxe de la valeur d'attribut n'est pas spécifiée mais doit être compatible avec la syntaxe de la valeur d'assertion.

4.2. Définitions de règles de correspondance

(Les définitions détaillées des règles de correspondance spécifiques sont omises ici. Veuillez vous référer au document original.)

5. Considérations de sécurité

De nombreuses syntaxes définies dans ce document impliquent des données binaires ou des chaînes de format spécifique. Une analyse ou un traitement incorrect de ces valeurs peut entraîner des vulnérabilités de sécurité telles que des débordements de tampon. Les implémenteurs doivent s'assurer de gérer toutes les syntaxes de manière robuste.

La complexité des règles de correspondance varie. Certaines (comme la correspondance de sous-chaîne) peuvent être coûteuses en calcul. Les serveurs doivent prendre des mesures pour empêcher les attaques par déni de service, par exemple en limitant le temps ou l'utilisation des ressources pour les recherches.

6. Remerciements

(Voir l'original)

7. Considérations IANA

(Voir l'original)

8. Références

(Voir l'original)