Zum Hauptinhalt springen

3. StartTLS-Operation

Die in Abschnitt 4.14 von [RFC4511] definierte Operation Start Transport Layer Security (StartTLS) bietet die Möglichkeit, TLS [RFC4346] in einer LDAP-Sitzung aufzubauen.

Die Ziele der Verwendung des TLS-Protokolls mit LDAP sind die Gewährleistung von Datenvertraulichkeit und -integrität sowie optional die Bereitstellung von Authentifizierung. TLS bietet diese Fähigkeiten ausdrücklich, allerdings stehen die Authentifizierungsdienste von TLS für LDAP nur in Kombination mit der SASL-EXTERNAL-Authentifizierungsmethode zur Verfügung (siehe Abschnitt 5.2.3), und auch dann nur, wenn die SASL-EXTERNAL-Implementierung beschließt, die TLS-Anmeldeinformationen zu nutzen.

3.1. Verfahren zum Aufbau von TLS​

Dieser Abschnitt beschreibt die Gesamtverfahren, die Clients und Server beim Aufbau von TLS befolgen müssen. Diese Verfahren berücksichtigen verschiedene Aspekte der TLS-Schicht, einschließlich der Ermittlung des resultierenden Sicherheitsniveaus und der Geltendmachung der Autorisierungsidentität des Clients.

3.1.1. Sequenzierung von StartTLS-Anforderungen​

Ein Client kann die erweiterte StartTLS-Anforderung jederzeit nach dem Aufbau einer LDAP-Sitzung senden, außer:

  - wenn derzeit TLS auf der Sitzung aufgebaut ist,
  - wenn auf der Sitzung eine mehrstufige SASL-Verhandlung im Gange ist, oder
  - wenn noch Antworten auf zuvor auf der Sitzung gestellte Operationsanforderungen ausstehen.

Wie in [RFC4511], Abschnitt 4.14.1, beschrieben, führt eine (erkannte) Verletzung einer dieser Anforderungen zur Rückgabe des resultCode operationsError.

Client-Implementierer sollten sicherstellen, dass sie diese Anforderungen an die Operationssequenzierung strikt einhalten, um Interoperabilitätsprobleme zu vermeiden. Die Betriebserfahrung zeigt, dass die Verletzung dieser Anforderungen Interoperabilitätsprobleme verursacht, da es Wettlaufsituationen gibt, die Server daran hindern, einige Verletzungen dieser Anforderungen zu erkennen, was auf Faktoren wie die Hardwaregeschwindigkeit des Servers und Netzwerklatenzen zurückzuführen ist.

Es gibt keine allgemeine Anforderung, dass der Client vor dem Senden einer StartTLS-Operationsanforderung bereits eine Bind-Operation (Abschnitt 5) durchgeführt haben muss oder nicht; wenn ein Client jedoch sowohl eine Bind-Operation als auch eine StartTLS-Operation durchführen will, SOLLTE (SHOULD) er zuerst die StartTLS-Operation durchführen, damit die Bind-Anforderungs- und -Antwortnachrichten durch die von der StartTLS-Operation aufgebauten Dienste für Datensicherheit geschützt sind.

3.1.2. Client-Zertifikat​

Wenn ein LDAP-Server während der TLS-Verhandlung von einem Client ein Benutzerzertifikat verlangt oder fordert und der Client kein geeignetes Benutzerzertifikat vorlegt (z. B. eines, das validiert werden kann), kann der Server eine lokale Sicherheitsrichtlinie verwenden, um zu entscheiden, ob die TLS-Verhandlung erfolgreich abgeschlossen werden soll.

Wenn ein Client, der ein geeignetes Zertifikat vorgelegt hat, anschließend eine Bind-Operation unter Verwendung des SASL-EXTERNAL-Authentifizierungsmechanismus durchführt (Abschnitt 5.2.3), können die Informationen im Zertifikat vom Server verwendet werden, um den Client zu identifizieren und zu authentifizieren.

3.1.3. Prüfung der Serveridentität​

Um Angriffe von Zwischenstationen (man-in-the-middle) zu verhindern, MUSS (MUST) der Client die Identität des Servers (wie im Certificate-Message des Servers dargestellt) überprüfen. In diesem Abschnitt wird das Verständnis des Clients von der Identität des Servers (üblicherweise die zur Herstellung der Transportverbindung verwendete Identität) als „Referenzidentität" (reference identity) bezeichnet.

Der Client bestimmt den Typ (z. B. DNS-Name oder IP-Adresse) der Referenzidentität und führt einen Vergleich zwischen der Referenzidentität und jedem subjectAltName-Wert des entsprechenden Typs durch, bis eine Übereinstimmung erzielt wird. Sobald eine Übereinstimmung erzielt wurde, ist die Identität des Servers überprüft und die Prüfung der Serveridentität abgeschlossen. Verschiedene subjectAltName-Typen werden auf unterschiedliche Weise abgeglichen. Die Abschnitte 3.1.3.1 bis 3.1.3.3 erläutern, wie Werte der verschiedenen subjectAltName-Typen zu vergleichen sind.

Der Client kann die Referenzidentität vor dem Vergleich auf einen anderen Typ abbilden. Abbildungen können für alle verfügbaren subjectAltName-Typen durchgeführt werden, auf die die Referenzidentität abgebildet werden kann; die Referenzidentität sollte jedoch nur auf Typen abgebildet werden, für die die Abbildung entweder von Natur aus sicher ist (z. B. Extrahieren des DNS-Namens aus einer URI zum Vergleich mit einem subjectAltName vom Typ dNSName) oder auf sichere Weise erfolgt (z. B. unter Verwendung von DNSSEC oder von benutzer- oder administratorkonfigurierten Nachschlagetabellen Host-zu-Adresse / Adresse-zu-Host).

Die Identität des Servers kann auch durch Vergleich der Referenzidentität mit dem Common Name (CN) [RFC4519] im Blatt-Relative Distinguished Name (RDN) des Felds subjectName des Serverzertifikats überprüft werden. Dieser Vergleich wird nach den Regeln für den Vergleich von DNS-Namen in Abschnitt 3.1.3.1 unten durchgeführt, mit der Ausnahme, dass keine Platzhalterübereinstimmung zulässig ist. Obwohl die Verwendung des Common-Name-Werts gängige Praxis ist, ist sie veraltet, und Zertifizierungsstellen werden ermutigt, stattdessen subjectAltName-Werte bereitzustellen. Beachten Sie, dass die TLS-Implementierung DNs in Zertifikaten gemäß X.500 oder anderen Konventionen darstellen kann. Beispielsweise ordnen einige X.500-Implementierungen die RDNs eines DN nach einer Links-nach-rechts-Konvention (vom höchstwertigen zum niedrigstwertigen) statt nach der Rechts-nach-links-Konvention von LDAP.

Wenn die Prüfung der Serveridentität fehlschlägt, SOLLTEN (SHOULD) benutzerorientierte Clients entweder den Benutzer benachrichtigen (die Clients können dem Benutzer in diesem Fall die Möglichkeit geben, die LDAP-Sitzung fortzusetzen) oder die Transportverbindung schließen und anzeigen, dass die Identität des Servers verdächtig ist. Automatisierte Clients SOLLTEN (SHOULD) die Transportverbindung schließen und dann einen Fehler zurückgeben oder protokollieren, der anzeigt, dass die Identität des Servers verdächtig ist, oder beides.

Über die in diesem Abschnitt beschriebene Prüfung der Serveridentität hinaus sollten Clients darauf vorbereitet sein, weitere Prüfungen vorzunehmen, um sicherzustellen, dass der Server berechtigt ist, den Dienst bereitzustellen, um dessen Bereitstellung er gebeten wird. Der Client muss hierfür möglicherweise Informationen aus der lokalen Richtlinie heranziehen.

3.1.3.1. Vergleich von DNS-Namen​

Wenn die Referenzidentität ein internationalisierter Domänenname ist, MÜSSEN (MUST) konforme Implementierungen ihn vor dem Vergleich mit subjectAltName-Werten vom Typ dNSName in das in Abschnitt 4 der RFC 3490 [RFC3490] angegebene ASCII Compatible Encoding (ACE) umwandeln. Insbesondere MÜSSEN (MUST) konforme Implementierungen die in Abschnitt 4 der RFC 3490 angegebene Konvertierungsoperation wie folgt durchführen:

  * in Schritt 1 ist der Domänenname als „stored string" zu betrachten;
  * in Schritt 3 ist das Flag namens „UseSTD3ASCIIRules" zu setzen;
  * in Schritt 4 ist jede Beschriftung mit der Operation „ToASCII" zu verarbeiten; und
  * in Schritt 5 sind alle Beschriftungstrenner in U+002E (Punkt) zu ändern.

Nach Durchführung der „to-ASCII"-Konvertierung MÜSSEN (MUST) die DNS-Beschriftungen und -Namen nach den in Abschnitt 3 der RFC 3490 angegebenen Regeln auf Gleichheit verglichen werden.

Das Platzhalterzeichen '*' (ASCII 42) ist in subjectAltName-Werten vom Typ dNSName zulässig, und zwar nur als am weitesten links stehende (niedrigstwertige) DNS-Beschriftung dieses Werts. Dieser Platzhalter entspricht jeder am weitesten links stehenden DNS-Beschriftung im Servernamen. Das heißt, der Subject *.example.com entspricht den Servernamen a.example.com und b.example.com, aber nicht example.com oder a.b.example.com.

3.1.3.2. Vergleich von IP-Adressen​

Wenn die Referenzidentität eine IP-Adresse ist, MUSS (MUST) die Identität in die Oktettketten-Darstellung in „Netzwerk-Byte-Reihenfolge" [RFC791][RFC2460] umgewandelt werden. Für IP Version 4, wie in RFC 791 festgelegt, enthält die Oktettkette genau vier Oktette. Für IP Version 6, wie in RFC 2460 festgelegt, enthält die Oktettkette genau sechzehn Oktette. Diese Oktettkette wird dann mit subjectAltName-Werten vom Typ iPAddress verglichen. Eine Übereinstimmung liegt vor, wenn die Oktettkette der Referenzidentität und die Oktettketten der Werte identisch sind.

3.1.3.3. Vergleich anderer subjectName-Typen​

Client-Implementierungen KÖNNEN (MAY) den Abgleich mit subjectAltName-Werten anderer Typen unterstützen, wie in anderen Dokumenten beschrieben.

3.1.4. Ermittlung des resultierenden Sicherheitsniveaus​

Nachdem eine TLS-Schicht in einer LDAP-Sitzung aufgebaut wurde, sollen beide Parteien jeweils unabhängig entscheiden, ob sie auf der Grundlage der lokalen Richtlinie und des erreichten Sicherheitsniveaus fortfahren. Entscheidet eine der Parteien, dass das Sicherheitsniveau für die Fortsetzung unzureichend ist, SOLLTE (SHOULD) sie die TLS-Schicht unmittelbar nach Abschluss der TLS-(Neu-)Verhandlung entfernen (siehe [RFC4511], Abschnitt 4.14.3, und Abschnitt 3.2 unten). Implementierungen können das Sicherheitsniveau jederzeit neu bewerten und sollten die TLS-Schicht entfernen, wenn es sich als unzureichend erweist.

3.1.5. Aktualisierung der Serverfähigkeitsinformationen​

Nachdem eine TLS-Schicht in einer LDAP-Sitzung aufgebaut wurde, SOLLTE (SHOULD) der Client alle Informationen über den Server verwerfen oder aktualisieren, die er vor Beginn der TLS-Verhandlung erhalten hat und die er nicht über sichere Mechanismen erhalten hat. Dies schützt vor Angriffen von Zwischenstationen, die beliebige vor der Installation der TLS-Schicht abgerufene Serverfähigkeitsinformationen geändert haben könnten.

Der Server kann nach der Installation einer TLS-Schicht andere Fähigkeiten ankündigen. Insbesondere kann der Wert von 'supportedSASLMechanisms' nach der Installation einer TLS-Schicht anders sein (konkret werden die Mechanismen EXTERNAL und PLAIN [PLAIN] wahrscheinlich erst nach der Installation einer TLS-Schicht aufgeführt).

3.2. Auswirkung von TLS auf den Autorisierungszustand​

Der Aufbau, die Änderung und/oder das Schließen von TLS kann dazu führen, dass der Autorisierungszustand in einen neuen Zustand übergeht. Dies wird in Abschnitt 4 weiter erörtert.

3.3. TLS-Ciphersuiten​

Bei der Auswahl von TLS-Ciphersuiten, die für eine gegebene Situation geeignet sind, sollten mehrere Aspekte berücksichtigt werden. Diese Aspekte umfassen:

  - die Fähigkeit der Ciphersuite, einen angemessenen Schutz der Vertraulichkeit für Kennwörter und andere über die Transportverbindung gesendete Daten zu bieten. Client- und Server-Implementierer sollten erkennen, dass einige TLS-Ciphersuiten keinen Vertraulichkeitsschutz bieten, während andere, die ihn bieten, anfällig für ein Brechen mittels Brute-Force sein können, insbesondere angesichts ständig steigender CPU-Geschwindigkeiten, die die für solche Angriffe benötigte Zeit verkürzen;

  - Client- und Server-Implementierer sollten den Wert des geschützten Kennworts oder der geschützten Daten sorgfältig gegen das von der Ciphersuite gebotene Niveau des Vertraulichkeitsschutzes abwägen, um sicherzustellen, dass das von der Ciphersuite gewährte Schutzniveau angemessen ist;

  - die Anfälligkeit (oder deren Fehlen) der Ciphersuite für Angriffe von Zwischenstationen. Ciphersuiten, die für Angriffe von Zwischenstationen anfällig sind, SOLLTEN (SHOULD NOT) nicht zum Schutz von Kennwörtern oder sensiblen Daten verwendet werden, es sei denn, die Netzwerkkonfiguration ist so beschaffen, dass die Gefahr eines Angriffs von Zwischenstationen vernachlässigbar ist;

  - nach Abschluss einer TLS-Verhandlung (ob erstmalig oder erneut) sollten beide Protokollpartner unabhängig voneinander überprüfen, dass die von der ausgehandelten Ciphersuite bereitgestellten Sicherheitsdienste für die beabsichtigte Nutzung der LDAP-Sitzung angemessen sind. Sind sie es nicht, sollte die TLS-Schicht geschlossen werden.