Zum Hauptinhalt springen

Anhang B. Zusammenfassung der Änderungen

Dieser Anhang ist nicht normativ.

Dieser Anhang fasst die wesentlichen Änderungen an RFC 2251, RFC 2829 und RFC 2830 zusammen. Neben den unten im Einzelnen aufgeführten Änderungen sollte der Leser dieses Dokuments wissen, dass am ursprünglichen Inhalt der Quelldokumente zahlreiche allgemeine redaktionelle Änderungen vorgenommen wurden. Diese Änderungen umfassen:

  • Das ursprünglich in den Abschnitten 4.2.1 und 4.2.2 der RFC 2251, in der RFC 2829 (alle Abschnitte außer den Abschnitten 2 und 4) und in der RFC 2830 enthaltene Material wurde in einem einzigen Dokument zusammengeführt.

  • Das zusammengeführte Material wurde erheblich umorganisiert und bearbeitet, um verwandte Themen zu gruppieren, den Lesefluss zu verbessern und die Absicht zu klären.

  • Im gesamten Text wurden Änderungen vorgenommen, um ihn an die Definitionen der LDAP-Protokollschichten und die Sicherheitsterminologie der IETF anzugleichen.

  • Die Sicherheitsüberlegungen beider Dokumente wurden auf der Grundlage aktueller Betriebserfahrung erheblich aktualisiert und ergänzt.

B.1. An der RFC 2251 vorgenommene Änderungen​

Dieser Abschnitt fasst die wesentlichen Änderungen zusammen, die dieses Dokument an den Abschnitten 4.2.1 und 4.2.2 der RFC 2251 vornimmt. Weitere wesentliche Änderungen an Abschnitt 4.2.1 der RFC 2251 sind auch in [RFC4511] dokumentiert.

B.1.1. Abschnitt 4.2.1 („Sequenzierung der Bind-Anforderung")​

  • Absatz 1: Der Satz „If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection" wurde entfernt. Die Unbind-Operation erlaubt dieses Verhalten weiterhin, doch wird es nicht ausdrücklich dokumentiert.

  • Klargestellt, dass die Sitzung bei Empfang der BindRequest-PDU in einen anonymen Zustand übergeht und nur dann in einen nicht anonymen Zustand übergeht, wenn die Bind-Anforderung erfolgreich ist.

B.1.2. Abschnitt 4.2.2 („Authentifizierung und andere Sicherheitsdienste")​

  • Die RFC 2251 besagt, dass die anonyme Authentifizierung mit der einfachen Bind-Methode durchgeführt werden MUSS (MUST). Diese Spezifikation definiert den Mechanismus für anonyme Authentifizierung der einfachen Bind-Methode und verlangt, dass alle konformen Implementierungen ihn unterstützen. Andere Authentifizierungsmechanismen, die einen anonymen Authentifizierungs- und Autorisierungszustand erzeugen, können von konformen Implementierungen ebenfalls umgesetzt und verwendet werden.

B.2. An der RFC 2829 vorgenommene Änderungen​

Dieser Abschnitt fasst die wesentlichen Änderungen an der RFC 2829 zusammen.

B.2.1. Abschnitt 4 („Erforderliche Sicherheitsmechanismen")​

  • Der durch TLS geschützte Mechanismus für Name/Kennwort-Authentifizierung (siehe Abschnitt B.2.5 unten) ersetzt den SASL-DIGEST-MD5-Mechanismus als den in LDAP verpflichtend zu implementierenden kennwortbasierten Authentifizierungsmechanismus. Implementierungen werden ermutigt, SASL DIGEST-MD5 [DIGEST-MD5] weiterhin zu unterstützen.

B.2.2. Abschnitt 5.1 („Anonymes Authentifizierungsverfahren")​

  • Klargestellt, dass die anonyme Authentifizierung einen Namenswert der Länge null und einen Kennwortwert der Länge null umfasst. Der nicht authentifizierte Authentifizierungsmechanismus wurde hinzugefügt, um einfache Bind-Anforderungen mit einem Namenswert ungleich null Länge und einem Kennwortwert der Länge null zu behandeln.

B.2.3. Abschnitt 6 („Kennwortbasierte Authentifizierung")​

  • Siehe Abschnitt B.2.1.

B.2.4. Abschnitt 6.1 („Digest-Authentifizierung")​

  • Da der SASL-DIGEST-MD5-Mechanismus nicht mehr verpflichtend zu implementieren ist, ist dieser Abschnitt nun historisch und wurde nicht in dieses Dokument aufgenommen. Abschnitt 6.1 der RFC 2829 dokumentiert den SASL-DIGEST-MD5-Authentifizierungsmechanismus weiterhin.

B.2.5. Abschnitt 6.2 („Authentifizierungswahl 'simple' unter TLS-Verschlüsselung")​

  • Der „simple"-Authentifizierungsmechanismus wurde in Mechanismus für Name/Kennwort-Authentifizierung umbenannt, um ihn besser zu beschreiben.

  • Die Verwendung von TLS wurde verallgemeinert, um sie an die Definitionen der LDAP-Protokollschichten anzugleichen. Der Aufbau von TLS wird nun als eigenständiges Thema erörtert und für die Verwendung mit allen Authentifizierungsmechanismen und anderen Sicherheitsschichten verallgemeinert.

  • Die Implikation wurde entfernt, dass das Attribut userPassword der einzige Speicherort für Kennwortwerte ist, die bei der Authentifizierung verwendet werden. Es gibt keine implizite Anforderung mehr dazu, wie oder wo Kennwörter auf dem Server für die Authentifizierung gespeichert werden.

B.2.6. Abschnitt 6.3 („Andere Authentifizierungswahlen mit TLS")​

  • Siehe Abschnitt B.2.5.

B.2.7. Abschnitt 7.1 („Zertifikatbasierte Authentifizierung mit TLS")​

  • Siehe Abschnitt B.2.5.

B.2.8. Abschnitt 8 („Andere Mechanismen")​

  • Alle SASL-Authentifizierungsmechanismen sind innerhalb von LDAP ausdrücklich zulässig. Konkret bedeutet dies, dass die Mechanismen SASL ANONYMOUS und SASL PLAIN nicht mehr von der Verwendung innerhalb von LDAP ausgeschlossen sind.

B.2.9. Abschnitt 9 („Autorisierungsidentität")​

  • Abgleichregeln für dnAuthzId- und uAuthzId-Werte wurden festgelegt. Insbesondere muss der DN-Wert in der dnAuthzId-Form mithilfe der DN-Abgleichregeln abgeglichen werden, und der uAuthzId-Wert MUSS (MUST) mithilfe der SASLprep-Regeln vorbereitet werden, bevor er oktettweise verglichen wird.

  • Klargestellt, dass uAuthzId-Werte nicht als global eindeutig angenommen werden sollten.

B.2.10. Abschnitt 10 („TLS-Ciphersuiten")​

  • Empfehlungen zu TLS-Ciphersuiten sind nicht mehr in dieser Spezifikation enthalten. Implementierungen müssen nun die Ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA unterstützen und sollten die Ciphersuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA weiterhin unterstützen.

  • Klargestellt, dass die anonyme Authentifizierung einen Namenswert der Länge null und einen Kennwortwert der Länge null umfasst. Der nicht authentifizierte Authentifizierungsmechanismus wurde hinzugefügt, um einfache Bind-Anforderungen mit einem Namenswert ungleich null Länge und einem Kennwortwert der Länge null zu behandeln.

B.3. An der RFC 2830 vorgenommene Änderungen​

Dieser Abschnitt fasst die wesentlichen Änderungen an den Abschnitten 3 und 5 der RFC 2830 zusammen. Leser sollten [RFC4511] für Zusammenfassungen der Änderungen an anderen Abschnitten heranziehen.

B.3.1. Abschnitt 3.6 („Prüfung der Serveridentität")​

  • Der Algorithmus zur Prüfung der Serveridentität wurde erheblich aktualisiert, um sicherzustellen, dass er vollständig und robust ist. Insbesondere wird die Verwendung aller relevanten Werte in den Feldern subjectAltName und subjectName vom Algorithmus abgedeckt, und für jeden Werttyp sind Abgleichregeln festgelegt. Abgebildete (abgeleitete) Formen der Serveridentität können nun verwendet werden, wenn die Abbildung auf sichere Weise erfolgt.

B.3.2. Abschnitt 3.7 („Aktualisierung der Serverfähigkeitsinformationen")​

  • Clients sind nicht mehr verpflichtet, Informationen über Serverfähigkeiten nach dem Aufbau von TLS stets zu aktualisieren. Dies soll Situationen Rechnung tragen, in denen diese Informationen über einen sicheren Mechanismus erlangt wurden.

B.3.3. Abschnitt 5 („Auswirkungen von TLS auf die Autorisierungsidentität eines Clients")​

  • Der Aufbau einer TLS-Schicht auf einer LDAP-Sitzung kann nun dazu führen, dass sich der Autorisierungszustand der LDAP-Sitzung ändert.

B.3.4. Abschnitt 5.2 („Auswirkungen des Schließens der TLS-Verbindung")​

  • Das Schließen einer TLS-Schicht auf einer LDAP-Sitzung ändert den Authentifizierungs- und Autorisierungszustand der LDAP-Sitzung auf der Grundlage der lokalen Richtlinie. Konkret bedeutet dies, dass Implementierungen nicht verpflichtet sind, den Authentifizierungs- und Autorisierungszustand beim Schließen von TLS auf anonym zu setzen.

  • Verweise auf RFC 2401 wurden durch RFC 4301 ersetzt.