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

• Status: Proposed Standard
• Veröffentlicht: June 2006
• Stream: IETF
• Aktualisiert: RFC3698
• Ersetzt: RFC2252, RFC2256
• Errata: Keine Errata

---

Zusammenfassung

Jedes Attribut, das in einem Lightweight Directory Access Protocol (LDAP)-Verzeichnis gespeichert ist und dessen Werte im LDAP-Protokoll übertragen werden können, hat eine definierte Syntax, die die Struktur und das Format seiner Werte einschränkt. Die Vergleichssemantik für Werte einer Syntax ist nicht Teil der Syntaxdefinition, sondern wird stattdessen durch separat definierte Übereinstimmungsregeln bereitgestellt. Übereinstimmungsregeln geben ein Argument an, einen Behauptungswert, der ebenfalls eine definierte Syntax hat. Dieses Dokument definiert einen Basissatz von Syntaxen und Übereinstimmungsregeln zur Verwendung bei der Definition von Attributen für LDAP-Verzeichnisse.

Inhaltsverzeichnis

1. Einführung
2. Konventionen
3. Syntaxen 3.1. Allgemeine Überlegungen 3.2. Allgemeine Definitionen 3.3. Syntaxdefinitionen 3.3.1. Attributtyp-Beschreibung (Attribute Type Description) 3.3.2. Bitfolge (Bit String) 3.3.3. Boolesch (Boolean) 3.3.4. Länderzeichenfolge (Country String) 3.3.5. Zustellungsmethode (Delivery Method) 3.3.6. Verzeichniszeichenfolge (Directory String) 3.3.7. DIT-Inhaltsregel-Beschreibung (DIT Content Rule Description) 3.3.8. DIT-Strukturregel-Beschreibung (DIT Structure Rule Description) 3.3.9. DN 3.3.10. Erweiterter Leitfaden (Enhanced Guide) 3.3.11. Fax-Telefonnummer (Facsimile Telephone Number) 3.3.12. Fax 3.3.13. Generalisierte Zeit (Generalized Time) 3.3.14. Leitfaden (Guide) 3.3.15. IA5-Zeichenfolge (IA5 String) 3.3.16. Ganzzahl (Integer) 3.3.17. JPEG 3.3.18. LDAP-Syntaxbeschreibung (LDAP Syntax Description) 3.3.19. Übereinstimmungsregel-Beschreibung (Matching Rule Description) 3.3.20. Übereinstimmungsregel-Verwendungsbeschreibung (Matching Rule Use Description) 3.3.21. Name und optionale UID (Name and Optional UID) 3.3.22. Namensform-Beschreibung (Name Form Description) 3.3.23. Numerische Zeichenfolge (Numeric String) 3.3.24. Objektklassen-Beschreibung (Object Class Description) 3.3.25. Oktettfolge (Octet String) 3.3.26. OID 3.3.27. Andere Mailbox (Other Mailbox) 3.3.28. Postanschrift (Postal Address) 3.3.29. Druckbare Zeichenfolge (Printable String) 3.3.30. Teilzeichenfolgen-Behauptung (Substring Assertion) 3.3.31. Telefonnummer (Telephone Number) 3.3.32. Teletex-Terminalkennung (Teletex Terminal Identifier) 3.3.33. Telexnummer (Telex Number) 3.3.34. UTC-Zeit (UTC Time)
4. Übereinstimmungsregeln 4.1. Allgemeine Überlegungen 4.2. Definitionen von Übereinstimmungsregeln
5. Sicherheitsüberlegungen
6. Danksagungen
7. IANA-Überlegungen
8. Referenzen Anhang A. Zusammenfassung der Syntax-Objektbezeichner Anhang B. Änderungen gegenüber RFC 2252

1. Einführung

Jedes Attribut, das in einem Lightweight Directory Access Protocol (LDAP)-Verzeichnis [RFC4510] gespeichert ist und dessen Werte im LDAP-Protokoll [RFC4511] übertragen werden können, hat eine definierte Syntax (d. h. einen Datentyp), die die Struktur und das Format seiner Werte einschränkt. Die Vergleichssemantik für Werte einer Syntax ist nicht Teil der Syntaxdefinition, sondern wird stattdessen durch separat definierte Übereinstimmungsregeln bereitgestellt. Übereinstimmungsregeln geben ein Argument an, einen Behauptungswert, der ebenfalls eine definierte Syntax hat. Dieses Dokument definiert einen Basissatz von Syntaxen und Übereinstimmungsregeln zur Verwendung bei der Definition von Attributen für LDAP-Verzeichnisse.

Lesern wird empfohlen, sich mit den Verzeichnisinformationsmodellen [RFC4512] vertraut zu machen, bevor sie den Rest dieses Dokuments lesen. Abschnitt 3 enthält Definitionen für den Basissatz von LDAP-Syntaxen. Abschnitt 4 enthält Definitionen für den Basissatz von Übereinstimmungsregeln für LDAP.

Dieses Dokument ist ein integraler Bestandteil der technischen Spezifikation von LDAP [RFC4510], die die zuvor definierte technische Spezifikation von LDAP, RFC 3377, in ihrer Gesamtheit ersetzt.

Die Abschnitte 4, 5 und 7 von RFC 2252 werden durch [RFC4512] obsolet. Der Rest von RFC 2252 wird durch dieses Dokument obsolet. Die Abschnitte 6 und 8 von RFC 2256 werden durch dieses Dokument obsolet. Der Rest von RFC 2256 wird durch [RFC4519] und [RFC4512] obsolet. Alles außer Abschnitt 2.11 von RFC 3698 wird durch dieses Dokument obsolet.

Eine Reihe von Schemaelementen, die in der vorherigen Revision der technischen Spezifikation von LDAP enthalten waren, sind in dieser Revision von LDAP nicht enthalten. Schemaelemente der Public Key Infrastructure werden jetzt in [RFC4523] spezifiziert. Sofern sie nicht in zukünftigen technischen Spezifikationen wieder eingeführt werden, ist der Rest als historisch zu betrachten.

Die Änderungen gegenüber RFC 2252 sind in Anhang B dieses Dokuments beschrieben.

2. Konventionen

In diesem Dokument sind die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" so zu interpretieren, wie in BCP 14, RFC 2119 [RFC2119] beschrieben.

3. Syntaxen

Syntaxdefinitionen schränken die Struktur von Attributwerten ein, die in einem LDAP-Verzeichnis gespeichert sind, und bestimmen die Darstellung von Attribut- und Behauptungswerten, die im LDAP-Protokoll übertragen werden.

Syntaxen, die für den Verzeichnisbetrieb erforderlich sind oder allgemein verwendet werden, werden in diesem Abschnitt spezifiziert. Server SOLLTEN alle in diesem Dokument aufgeführten Syntaxen erkennen, sind jedoch nicht verpflichtet, sie anderweitig zu unterstützen, und KÖNNEN andere Syntaxen erkennen oder unterstützen. Die Definition zusätzlicher willkürlicher Syntaxen wird jedoch nicht empfohlen, da dies die Interoperabilität behindert. Client- und Serverimplementierungen haben normalerweise nicht die Fähigkeit, neue Syntaxen dynamisch zu erkennen.

3.1. Allgemeine Überlegungen

Die Beschreibung jeder Syntax gibt an, wie Attribut- oder Behauptungswerte, die der Syntax entsprechen, dargestellt werden sollen, wenn sie im LDAP-Protokoll [RFC4511] übertragen werden. Diese Darstellung wird als LDAP-spezifische Codierung bezeichnet, um sie von anderen Methoden zur Codierung von Attributwerten zu unterscheiden (z. B. die Basic Encoding Rules (BER)-Codierung [BER], die von X.500 [X.500]-Verzeichnissen verwendet wird).

3.2. Allgemeine Definitionen

Die folgenden ABNF-Regeln werden in einer Reihe der Syntaxdefinitionen in Abschnitt 3.3 verwendet.

      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. Syntaxdefinitionen

(Detaillierte Definitionen der spezifischen Syntaxen werden hier weggelassen. Bitte beziehen Sie sich auf das Originaldokument.)

4. Übereinstimmungsregeln

Übereinstimmungsregeln definieren den Algorithmus, der zum Vergleichen eines Attributwerts und eines Behauptungswerts verwendet werden soll.

4.1. Allgemeine Überlegungen

Jede Übereinstimmungsregel wird eindeutig durch einen Objektbezeichner [ASN.1] identifiziert. Die in diesem Dokument definierten Übereinstimmungsregeln haben auch einen Kurznamen (Deskriptor).

Übereinstimmungsregeldefinitionen geben die Syntax des zu vergleichenden Behauptungswerts an. Die Syntax des Attributwerts ist nicht angegeben, muss aber mit der Syntax des Behauptungswerts kompatibel sein.

4.2. Definitionen von Übereinstimmungsregeln

(Detaillierte Definitionen der spezifischen Übereinstimmungsregeln werden hier weggelassen. Bitte beziehen Sie sich auf das Originaldokument.)

5. Sicherheitsüberlegungen

Viele der in diesem Dokument definierten Syntaxen beinhalten Binärdaten oder Zeichenfolgen mit einem bestimmten Format. Eine falsche Analyse oder Verarbeitung dieser Werte kann zu Sicherheitslücken wie Pufferüberläufen führen. Implementierer sollten sicherstellen, dass alle Syntaxen robust verarbeitet werden.

Die Komplexität von Übereinstimmungsregeln variiert. Einige (wie Teilzeichenfolgenübereinstimmung) können rechenintensiv sein. Server sollten Maßnahmen ergreifen, um Denial-of-Service-Angriffe zu verhindern, z. B. durch Begrenzung der Zeit oder Ressourcennutzung für Suchvorgänge.

6. Danksagungen

(Siehe Original)

7. IANA-Überlegungen

(Siehe Original)

8. Referenzen

(Siehe Original)