Zum Hauptinhalt springen

6. Sicherheitsüberlegungen

Sicherheitsfragen werden im gesamten Dokument erörtert. Das wenig überraschende Ergebnis ist, dass Sicherheit ein integraler und notwendiger Bestandteil von LDAP ist. Dieser Abschnitt erörtert eine Reihe LDAP-bezogener Sicherheitsüberlegungen.

6.1. Allgemeine Sicherheitsüberlegungen zu LDAP​

LDAP selbst bietet keine Sicherheit und keinen Schutz gegen den Zugriff auf oder die Aktualisierung des Verzeichnisses durch andere Mittel als das LDAP-Protokoll, z. B. gegen die Einsichtnahme in Server-Datenbankdateien durch Datenbankadministratoren.

Sensible Daten können in nahezu jeder LDAP-Nachricht transportiert werden, und ihre Offenlegung kann in vielen Ländern Datenschutzgesetzen oder anderen rechtlichen Regelungen unterliegen. Implementierer sollten geeignete Maßnahmen ergreifen, um sensible Daten vor der Offenlegung gegenüber unbefugten Instanzen zu schützen.

Eine Sitzung, auf der der Client keine Dienste für Datenintegrität und Vertraulichkeit aufgebaut hat (z. B. über StartTLS, IPsec oder einen geeigneten SASL-Mechanismus), ist Angriffen von Zwischenstationen (man-in-the-middle) ausgesetzt, die Informationen während der Übertragung einsehen und ändern. Client- und Server-Implementierer SOLLTEN (SHOULD) Maßnahmen ergreifen, um sensible Daten in der LDAP-Sitzung mithilfe der in diesem Dokument erörterten Datenschutzdienste vor diesen Angriffen zu schützen. Clients und Server sollten die Möglichkeit bieten, so konfiguriert zu werden, dass sie diese Schutzmaßnahmen verlangen. Ein resultCode von

confidentialityRequired zeigt an, dass der Server den Aufbau eines (stärkeren) Schutzes der Datenvertraulichkeit verlangt, um die angeforderte Operation auszuführen.

Zugriffskontrolle sollte stets angewandt werden, wenn sensible Informationen gelesen oder Verzeichnisinformationen aktualisiert werden.

Verschiedene Sicherheitsfaktoren, einschließlich Authentifizierungs- und Autorisierungsinformationen sowie Dienste für Datensicherheit, können sich im Verlauf der LDAP-Sitzung ändern, sogar während der Ausführung einer bestimmten Operation. Implementierungen sollten im Umgang mit sich ändernden Sicherheitsfaktoren robust sein.

6.2. Sicherheitsüberlegungen zu StartTLS​

Jede durch die Verwendung der StartTLS-Operation gewonnene Sicherheit wird durch die Verwendung von TLS selbst gewonnen. Die StartTLS-Operation allein bietet keine zusätzliche Sicherheit.

Das durch die Verwendung von TLS bereitgestellte Sicherheitsniveau hängt unmittelbar sowohl von der Qualität der verwendeten TLS-Implementierung als auch von der Art ihrer Verwendung ab. Darüber hinaus kann ein Angreifer als Zwischenstation die erweiterte Operation StartTLS aus dem Attribut 'supportedExtension' des Wurzel-DSE entfernen. Beide Parteien SOLLTEN (SHOULD) unabhängig das erreichte Sicherheitsniveau feststellen und ihm zustimmen, sobald TLS aufgebaut ist und bevor sie die TLS-geschützte Sitzung zu nutzen beginnen. Beispielsweise könnte das Sicherheitsniveau der TLS-Schicht auf Klartext herunterverhandelt worden sein.

Clients MÜSSEN (MUST) entweder den Benutzer warnen, wenn das erreichte Sicherheitsniveau keinen annehmbaren Schutz der Datenvertraulichkeit und/oder Datenintegrität bietet, oder so konfigurierbar sein, dass sie die Fortsetzung ohne ein annehmbares Sicherheitsniveau verweigern.

Wie in Abschnitt 3.1.2 dargelegt, kann ein Server eine lokale Sicherheitsrichtlinie verwenden, um zu entscheiden, ob die TLS-Verhandlung erfolgreich abgeschlossen werden soll. Informationen im Zertifikat des Benutzers, die von der Zertifizierungsstelle ausgestellt oder geprüft wurden, sollten vom Richtlinienadministrator bei der Konfiguration der Identifizierungs- und Autorisierungsrichtlinie herangezogen werden.

Server-Implementierer SOLLTEN (SHOULD) es Serveradministratoren ermöglichen, zu wählen, ob und wann Datenvertraulichkeit und -integrität verlangt werden, sowie zu wählen, ob die Authentifizierung des Clients während des TLS-Handshakes verlangt wird.

Implementierer sollten die in der TLS-Spezifikation [RFC4346] erörterten Sicherheitsüberlegungen zu TLS kennen und verstehen.

6.3. Sicherheitsüberlegungen zur Bind-Operation​

Dieser Abschnitt erörtert mehrere Sicherheitsüberlegungen, die für die LDAP-Authentifizierung über die Bind-Operation relevant sind.

6.3.1. Sicherheitsüberlegungen zum nicht authentifizierten Mechanismus​

Die Betriebserfahrung zeigt, dass Clients den nicht authentifizierten Authentifizierungsmechanismus der einfachen Bind-Methode missbrauchen können (und dies häufig tun) (siehe Abschnitt 5.1.2). Beispielsweise kann ein Clientprogramm auf der Grundlage einer erfolgreich abgeschlossenen Bind-Operation entscheiden, Zugriff auf Nicht-Verzeichnisinformationen zu gewähren. LDAP-Serverimplementierungen können auf eine nicht authentifizierte Bind-Anforderung eine Erfolgsantwort zurückgeben. Dies kann beim Client fälschlich den Eindruck hinterlassen, der Server habe die durch den Distinguished Name repräsentierte Identität erfolgreich authentifiziert, während in Wirklichkeit ein anonymer Autorisierungszustand aufgebaut wurde. Clients, die die Ergebnisse einer einfachen Bind-Operation für Autorisierungsentscheidungen verwenden, sollten nicht authentifizierte Bind-Anforderungen aktiv erkennen (indem sie prüfen, dass das übergebene Kennwort nicht leer ist) und angemessen reagieren.

6.3.2. Sicherheitsüberlegungen zum Name/Kennwort-Mechanismus​

Der Mechanismus für Name/Kennwort-Authentifizierung der einfachen Bind-Methode offenbart das Kennwort gegenüber dem Server, was ein inhärentes Sicherheitsrisiko darstellt. Es gibt andere Mechanismen, wie SASL DIGEST-MD5 [DIGEST-MD5], die das Kennwort nicht gegenüber dem Server offenbaren.

6.3.3. Kennwortbezogene Sicherheitsüberlegungen​

LDAP erlaubt mehrwertige Kennwortattribute. In Systemen, in denen Einträge genau ein Kennwort haben sollen, sollten administrative Kontrollen bereitgestellt werden, um dieses Verhalten durchzusetzen.

Die Verwendung von Klartextkennwörtern und anderen ungeschützten Authentifizierungs-Anmeldeinformationen ist in offenen Netzen stark abzulehnen, wenn der zugrunde liegende Transportdienst Vertraulichkeit nicht gewährleisten kann. LDAP-Implementierungen SOLLTEN (SHOULD NOT) standardmäßig keine Authentifizierungsmethoden unterstützen, die Klartextkennwörter und andere ungeschützte Authentifizierungs-Anmeldeinformationen verwenden, es sei denn, die Daten auf der Sitzung sind mithilfe von TLS oder eines anderen Schutzes der Datenvertraulichkeit und Datenintegrität geschützt.

Die Übertragung von Kennwörtern im Klartext — üblicherweise zur Authentifizierung oder Änderung — stellt ein erhebliches Sicherheitsrisiko dar. Dieses Risiko lässt sich vermeiden, indem SASL-Authentifizierungsmechanismen [RFC4422] verwendet werden, die Kennwörter nicht im Klartext übertragen, oder indem vor der Übertragung von Kennwortwerten Dienste für Datenvertraulichkeit auf Transport- oder Sitzungsschicht ausgehandelt werden.

Um die mit der Übertragung von Kennwörtern verbundenen Sicherheitsrisiken zu mindern, MUSS (MUST) eine Serverimplementierung, die einen kennwortbasierten Authentifizierungsmechanismus unterstützt, der Kennwörter im Klartext überträgt, einen Richtlinienmechanismus unterstützen, der zum Zeitpunkt der Authentifizierung oder Kennwortänderung verlangt, dass:

     eine TLS-Schicht erfolgreich eingerichtet wurde.

     ODER

     ein anderer Mechanismus zur Datenvertraulichkeit bereitgestellt wurde, der den Kennwortwert vor Mithören schützt.

     ODER

     der Server für die Operation einen resultCode von confidentialityRequired zurückgibt (d. h. Name/Kennwort-Bind mit Kennwortwert, SASL-Bind, der einen Kennwortwert im Klartext überträgt, add oder modify mit einem userPassword-Wert usw.), selbst wenn der Kennwortwert korrekt ist.

Serverimplementierungen möchten möglicherweise auch Richtlinienmechanismen bereitstellen, um Konten in Situationen ungültig zu machen oder anderweitig zu schützen, in denen ein Server erkennt, dass ein Kennwort eines Kontos im Klartext übertragen wurde.

6.3.4. Sicherheitsüberlegungen zu gehashten Kennwörtern​

Einige Authentifizierungsmechanismen (z. B. DIGEST-MD5) übertragen einen Hash des Kennwortwerts, der für Offline-Wörterbuchangriffe anfällig sein kann. Implementierer sollten darauf achten, solche gehashten Kennwortwerte während der Übertragung mithilfe von TLS oder anderen Vertraulichkeitsmechanismen zu schützen.

6.4. Sicherheitsüberlegungen zu SASL​

Solange kein Dienst für Datenintegrität auf einer LDAP-Sitzung eingerichtet ist, kann ein Angreifer die übertragenen Werte der Antwort auf das Attribut 'supportedSASLMechanisms' ändern und damit die Liste der verfügbaren SASL-Mechanismen so herabstufen, dass sie nur den unsichersten Mechanismus enthält. Um diese Art von Angriff zu erkennen, kann der Client die vom Server bereitgestellten SASL-Mechanismen sowohl vor als auch nach dem Einrichten des Dienstes für Datenintegrität auf einer LDAP-Sitzung abrufen. Stellt der Client fest, dass die integritätsgeschützte Liste (die nach dem Einrichten des Dienstes für Datenintegrität erhaltene Liste) einen stärkeren Mechanismus enthält als die zuvor erhaltene Liste, sollte der Client annehmen, dass die zuvor erhaltene Liste von einem Angreifer geändert wurde. In diesem Fall wird empfohlen, dass der Client die zugrunde liegende Transportverbindung schließt und sich dann erneut verbindet, um die Sitzung wiederherzustellen.

6.5. Verwandte Sicherheitsüberlegungen​

Zusätzliche Sicherheitsüberlegungen zu den verschiedenen in diesem Dokument erörterten Authentifizierungsmethoden und -mechanismen gelten und finden sich in [RFC4422], [RFC4013], [RFC3454] und [RFC3629].