Zum Hauptinhalt springen

5. Bind-Operation

Die Bind-Operation ([RFC4511], Abschnitt 4.2) ermöglicht den Austausch von Authentifizierungsinformationen zwischen Client und Server, um einen neuen Autorisierungszustand aufzubauen.

Die Bind-Anforderung gibt üblicherweise die gewünschte Authentifizierungsidentität an. Einige Bind-Mechanismen erlauben es dem Client zudem, die Autorisierungsidentität anzugeben. Wird die Autorisierungsidentität nicht angegeben, leitet der Server sie auf implementierungsspezifische Weise aus der Authentifizierungsidentität ab.

Wird die Autorisierungsidentität angegeben, MUSS (MUST) der Server überprüfen, dass die Authentifizierungsidentität des Clients berechtigt ist, die geltend gemachte Autorisierungsidentität anzunehmen (z. B. für sie als Stellvertreter zu handeln). Der Server MUSS (MUST) die Bind-Operation mit einem resultCode invalidCredentials in der Bind-Antwort ablehnen, wenn der Client dazu nicht berechtigt ist.

5.1. Einfache Authentifizierungsmethode​

Die einfache Authentifizierungsmethode der Bind-Operation bietet drei Authentifizierungsmechanismen:

  - einen Mechanismus für anonyme Authentifizierung (Abschnitt 5.1.1).

  - einen nicht authentifizierten Authentifizierungsmechanismus (Abschnitt 5.1.2).

  - einen Mechanismus für Name/Kennwort-Authentifizierung, der Anmeldeinformationen aus einem Namen (in Form eines LDAP-Distinguished-Name [RFC4514]) und einem Kennwort verwendet (Abschnitt 5.1.3).

5.1.1. Mechanismus für anonyme Authentifizierung der einfachen Bind-Methode​

Ein LDAP-Client kann den Mechanismus für anonyme Authentifizierung der einfachen Bind-Methode verwenden, um ausdrücklich einen anonymen Autorisierungszustand aufzubauen, indem er eine Bind-Anforderung mit einem Namenswert der Länge null sendet und die einfache Authentifizierungswahl mit einem Kennwortwert der Länge null angibt.

5.1.2. Nicht authentifizierter Authentifizierungsmechanismus der einfachen Bind-Methode​

Ein LDAP-Client kann den nicht authentifizierten Authentifizierungsmechanismus der einfachen Bind-Methode verwenden, um einen anonymen Autorisierungszustand aufzubauen, indem er eine Bind-Anforderung mit einem Namenswert (einem Distinguished Name in LDAP-Zeichenkettenform [RFC4514] ungleich null Länge) sendet und die einfache Authentifizierungswahl mit einem Kennwortwert der Länge null angibt.

Der vom Client übergebene Distinguished-Name-Wert ist nur für Zwecke der Nachverfolgung (z. B. Protokollierung) bestimmt. Der Wert darf nicht authentifiziert oder anderweitig validiert werden (einschließlich der Prüfung, dass der DN auf ein vorhandenes Verzeichnisobjekt verweist). Der Wert darf (unmittelbar oder mittelbar) nicht für Autorisierungszwecke verwendet werden.

Nicht authentifizierte Bind-Operationen können erhebliche Sicherheitsprobleme mit sich bringen (siehe Abschnitt 6.3.1). Insbesondere können Benutzer, die eine Name/Kennwort-Authentifizierung beabsichtigen, versehentlich ein leeres Kennwort übergeben und dadurch schlecht implementierte Clients dazu veranlassen, einen nicht authentifizierten Zugriff anzufordern. Clients SOLLTEN (SHOULD) so implementiert sein, dass die Auswahl des nicht authentifizierten Authentifizierungsmechanismus durch den Benutzer auf einem anderen Weg als der Eingabe eines leeren Kennworts verlangt wird. Clients SOLLTEN (SHOULD) die Eingabe eines leeren Kennworts in einer Benutzeroberfläche für Name/Kennwort-Authentifizierung nicht zulassen. Darüber hinaus SOLLTEN (SHOULD) Server standardmäßig nicht authentifizierte Bind-Anforderungen mit einem resultCode unwillingToPerform fehlschlagen lassen.

5.1.3. Mechanismus für Name/Kennwort-Authentifizierung der einfachen Bind-Methode​

Ein LDAP-Client kann den Mechanismus für Name/Kennwort-Authentifizierung der einfachen Bind-Methode verwenden, um einen authentifizierten Autorisierungszustand aufzubauen, indem er eine Bind-Anforderung mit einem Namenswert (einem Distinguished Name in LDAP-Zeichenkettenform [RFC4514] ungleich null Länge) sendet und die einfache Authentifizierungswahl mit einem Kennwortwert als OCTET STRING ungleich null Länge angibt.

Server, die den in der Bind-Anforderung gesendeten DN auf einen Verzeichniseintrag mit einer zugehörigen Menge eines oder mehrerer mit diesem Mechanismus verwendeter Kennwörter abbilden, vergleichen das übergebene Kennwort mit dieser Kennwortmenge. Das übergebene Kennwort gilt als gültig, wenn es mit irgendeinem Element dieser Menge übereinstimmt.

Ein resultCode invalidDNSyntax zeigt an, dass der im Namenswert gesendete DN syntaktisch ungültig ist. Ein resultCode invalidCredentials zeigt an, dass der DN syntaktisch korrekt, aber für Zwecke der Authentifizierung nicht gültig ist, dass das Kennwort für den DN nicht gültig ist oder dass der Server die Anmeldeinformationen anderweitig als ungültig betrachtet. Ein resultCode success zeigt an, dass die Anmeldeinformationen gültig sind und der Server bereit ist, der durch diese Anmeldeinformationen identifizierten Instanz Dienste bereitzustellen.

Das Serververhalten ist für Bind-Anforderungen undefiniert, die den Mechanismus für Name/Kennwort-Authentifizierung mit einem Namenswert der Länge null und einem Kennwortwert ungleich null Länge angeben.

Der Mechanismus für Name/Kennwort-Authentifizierung der einfachen Bind-Methode eignet sich nicht für die Authentifizierung in Umgebungen ohne Vertraulichkeitsschutz.

5.2. SASL-Authentifizierungsmethode​

Die sasl-Authentifizierungsmethode der Bind-Operation bietet die Möglichkeit, jeden SASL-Mechanismus zu verwenden, einschließlich Authentifizierungsmechanismen und anderer Dienste (z. B. Dienste für Datensicherheit).

5.2.1. SASL-Protokollprofil​

LDAP erlaubt die Authentifizierung über jeden SASL-Mechanismus [RFC4422]. Da LDAP native anonyme und Name/Kennwort-Authentifizierungsmethoden (Klartext) enthält, werden die SASL-Mechanismen ANONYMOUS [RFC4505] und PLAIN [PLAIN] üblicherweise nicht mit LDAP verwendet.

Jedes Protokoll, das SASL-Dienste nutzt, ist verpflichtet, bestimmte Informationen bereitzustellen, die beschreiben, wie diese über das Protokoll bereitgestellt werden ([RFC4422], Abschnitt 4). Dieser Abschnitt erläutert, wie LDAP jede dieser Profilanforderungen erfüllt.

5.2.1.1. SASL-Dienstname für LDAP​

Der SASL-Dienstname für LDAP ist „ldap", der bei der IANA als SASL-Dienstname registriert wurde.

5.2.1.2. Einleitung der SASL-Authentifizierung und Protokollaustausch​

Die SASL-Authentifizierung wird über eine BindRequest-Nachricht ([RFC4511], Abschnitt 4.2) mit den folgenden Parametern eingeleitet:

  - version ist 3.
  - AuthenticationChoice ist sasl.
  - Das Element mechanism der Sequenz SaslCredentials enthält den Wert des gewünschten SASL-Mechanismus.
  - Das optionale Feld credentials der Sequenz SaslCredentials KANN (MAY) verwendet werden, um eine anfängliche Client-Antwort für Mechanismen bereitzustellen, die so definiert sind, dass der Client zuerst Daten sendet (siehe [RFC4422], Abschnitte 3 und 5).

Im Allgemeinen besteht ein SASL-Authentifizierungs-Protokollaustausch aus einer Reihe von Server-Herausforderungen (Challenges) und Client-Antworten, deren Inhalt für den SASL-Mechanismus spezifisch und von ihm definiert ist. Daher kann es bei einigen SASL-Authentifizierungsmechanismen erforderlich sein, dass der Client auf eine oder mehrere Server-Herausforderungen antwortet, indem er mehrfach BindRequest-Nachrichten sendet. Eine Herausforderung wird dadurch angezeigt, dass der Server eine BindResponse-Nachricht mit dem resultCode

saslBindInProgress sendet. Dies zeigt an, dass der Server vom Client verlangt, zur Fortsetzung des Authentifizierungsvorgangs eine neue BindRequest-Nachricht mit demselben SASL-Mechanismus zu senden.

Für die LDAP-Nachrichtenschicht sind diese Herausforderungen und Antworten undurchsichtige Binär-Token beliebiger Länge. LDAP-Server verwenden das Feld serverSaslCreds (ein OCTET STRING) in einer BindResponse-Nachricht, um jede Herausforderung zu übertragen. LDAP-Clients verwenden das Feld credentials (ein OCTET STRING) in der Sequenz SaslCredentials einer BindRequest-Nachricht, um jede Antwort zu übertragen. Beachten Sie, dass LDAP, anders als einige Internetprotokolle, in denen SASL verwendet wird, nicht textbasiert ist und diese Herausforderungs- und Antwortwerte nicht Base64-transformiert.

Clients, die eine BindRequest-Nachricht mit gewählter sasl-Wahl senden, SOLLTEN (SHOULD) einen Wert der Länge null im Feld name senden. Server, die eine BindRequest-Nachricht mit gewählter sasl-Wahl empfangen, IGNORIEREN (SHALL) jeden Wert im Feld name.

Ein Client kann eine SASL-Bind-Verhandlung abbrechen, indem er eine BindRequest-Nachricht mit einem anderen Wert im Feld mechanism von SaslCredentials oder mit einer anderen AuthenticationChoice als sasl sendet.

Wenn der Client eine BindRequest sendet, bei der das Feld mechanism von sasl eine leere Zeichenkette ist, MUSS (MUST) der Server eine BindResponse mit einem resultCode authMethodNotSupported zurückgeben. Dies ermöglicht es dem Client, eine Verhandlung abzubrechen, wenn er es mit demselben SASL-Mechanismus erneut versuchen möchte.

Der Server zeigt den Abschluss des SASL-Herausforderungs-Antwort-Austauschs an, indem er mit einer BindResponse antwortet, deren resultCode-Wert nicht saslBindInProgress ist.

Das Feld serverSaslCreds in der BindResponse kann verwendet werden, um eine optionale Herausforderung mit einer Erfolgsbenachrichtigung für Mechanismen einzuschließen, die so definiert sind, dass der Server zusammen mit der Anzeige des erfolgreichen Abschlusses zusätzliche Daten sendet.

5.2.1.3. Optionale Felder​

Wie oben erörtert, stellt LDAP ein optionales Feld zum Transport einer anfänglichen Antwort in der Nachricht bereit, die den SASL-Austausch einleitet, und ein optionales Feld zum Transport zusätzlicher Daten in der Nachricht, die das Ergebnis des Authentifizierungsaustauschs anzeigt. Da der mechanismusspezifische Inhalt dieser Felder die Länge null haben kann, verlangt SASL, dass Protokollspezifikationen detailliert darlegen, wie sich ein leeres Feld von einem fehlenden Feld unterscheidet.

Anfängliche Antwortdaten der Länge null werden in der einleitenden Nachricht, einer BindRequest-PDU, durch das Vorhandensein des OCTET STRING SaslCredentials.credentials (der Länge null) in dieser PDU von fehlenden anfänglichen Antwortdaten unterschieden. Beabsichtigt der Client nicht, mit der den SASL-Austausch einleitenden BindRequest eine anfängliche Antwort zu senden, MUSS (MUST) er den OCTET STRING SaslCredentials.credentials weglassen (statt einen OCTET STRING der Länge null einzuschließen).

Zusätzliche Daten der Länge null werden in der Ergebnisnachricht, einer BindResponse-PDU, durch das Vorhandensein des OCTET STRING serverSaslCreds (der Länge null) in dieser PDU von fehlenden zusätzlichen Antwortdaten unterschieden. Beabsichtigt ein Server nicht, in der BindResponse-Nachricht, die das Ergebnis des Austauschs anzeigt, zusätzliche Daten zu senden, MUSS (SHALL) der Server den OCTET STRING serverSaslCreds weglassen (statt einen OCTET STRING der Länge null einzuschließen).

5.2.1.4. Oktett, ab dem ausgehandelte Sicherheitsschichten wirksam werden​

SASL-Schichten werden wirksam, nachdem die abschließende BindResponse im SASL-Austausch mit dem resultCode success vom Server gesendet und vom Client empfangen wurde.

Sobald eine SASL-Schicht, die Dienste für Datenintegrität oder -vertraulichkeit bietet, wirksam wird, bleibt die Schicht wirksam, bis eine neue Schicht eingerichtet wird (d. h. ab dem ersten Oktett nach der abschließenden BindResponse der Bind-Operation, die die neue Schicht wirksam gemacht hat). Somit wird eine aufgebaute SASL-Schicht durch eine fehlgeschlagene oder nicht-SASL-Bind-Operation nicht beeinflusst.

5.2.1.5. Ermittlung der unterstützten SASL-Mechanismen​

Clients können die von einem Server unterstützten SASL-Mechanismen ermitteln, indem sie das Attribut 'supportedSASLMechanisms' aus dem Wurzel-DSE (DSA-Specific Entry) lesen ([RFC4512], Abschnitt 5.1). Die Werte dieses Attributs, sofern vorhanden, führen die Mechanismen auf, die der Server im aktuellen LDAP-Sitzungszustand unterstützt. LDAP-Server SOLLTEN (SHOULD) allen Clients — auch solchen mit anonymer Autorisierung — erlauben, das Attribut 'supportedSASLMechanisms' des Wurzel-DSE sowohl vor als auch nach dem SASL-Authentifizierungsaustausch abzurufen. Der Zweck des letzteren Abrufs ist es, dem Client die Erkennung möglicher Herabstufungsangriffe zu ermöglichen (siehe Abschnitt 6.4 und [RFC4422], Abschnitt 6.1.2).

Da SASL-Mechanismen kritische Sicherheitsfunktionen bereitstellen, sollten Clients und Server so konfigurierbar sein, dass angegeben werden kann, welche Mechanismen zulässig sind, und dass nur diese Mechanismen verwendet werden dürfen. Sowohl Clients als auch Server müssen bestätigen, dass das ausgehandelte Sicherheitsniveau ihren Anforderungen entspricht, bevor sie die Sitzung nutzen.

5.2.1.6. Regeln für die Verwendung von SASL-Schichten​

Bei der Einrichtung einer SASL-Schicht SOLLTE (SHOULD) der Client alle Informationen über den Server verwerfen oder aktualisieren, die er vor Beginn der SASL-Verhandlung erhalten hat und die er nicht über sichere Mechanismen erhalten hat.

Wenn eine Sicherheitsschicht niedrigerer Ebene (etwa TLS) eingerichtet ist, MUSS (SHALL) jede SASL-Schicht unabhängig von der Reihenfolge ihrer Verhandlung über solchen Sicherheitsschichten geschichtet werden. In allen anderen Belangen wirken die SASL-Schicht und andere Sicherheitsschichten unabhängig voneinander: Sind beispielsweise sowohl eine TLS-Schicht als auch eine SASL-Schicht wirksam, so beeinträchtigt das Entfernen der TLS-Schicht den fortgesetzten Dienst der SASL-Schicht nicht.

5.2.1.7. Unterstützung mehrerer Authentifizierungen​

LDAP unterstützt mehrere SASL-Authentifizierungen, wie in [RFC4422], Abschnitt 4, definiert.

5.2.1.8. SASL-Autorisierungsidentitäten​

Einige SASL-Mechanismen erlauben es Clients, eine gewünschte Autorisierungsidentität für die LDAP-Sitzung anzufordern ([RFC4422], Abschnitt 3.4). Die Entscheidung, ob der aktuellen Authentifizierungsidentität der Zugriff auf die angeforderte Autorisierungsidentität erlaubt wird, ist eine Angelegenheit der lokalen Richtlinie. Die Autorisierungsidentität ist eine Zeichenkette aus UTF-8 [RFC3629] kodierten [Unicode]-Zeichen, die der folgenden Augmented Backus-Naur Form (ABNF) [RFC4234] entspricht:

  authzId = dnAuthzId / uAuthzId

  ; distinguished-name-based authz id
  dnAuthzId =  "dn:" distinguishedName

  ; unspecified authorization id, UTF-8 encoded
  uAuthzId = "u:" userid
  userid = *UTF8 ; syntax unspecified

wobei die Regel distinguishedName in Abschnitt 3 von [RFC4514] und die Regel UTF8 in Abschnitt 1.4 von [RFC4512] definiert ist.

Die Wahl dnAuthzId wird verwendet, um Autorisierungsidentitäten in Form eines Distinguished Name geltend zu machen, die nach der Abgleichregel distinguishedNameMatch abzugleichen sind ([RFC4517], Abschnitt 4.2.15). Es wird nicht verlangt, dass der geltend gemachte distinguishedName-Wert der eines Eintrags im Verzeichnis ist.

Die Wahl uAuthzId erlaubt es Clients, eine Autorisierungsidentität geltend zu machen, die nicht in Distinguished-Name-Form vorliegt. Das Format von userid ist nur als Folge von UTF-8 [RFC3629] kodierten [Unicode]-Zeichen definiert, und jede weitere Interpretation ist eine lokale Angelegenheit. Beispielsweise kann der userid einen Benutzer eines bestimmten Verzeichnisdienstes identifizieren, ein Anmeldename oder eine E-Mail-Adresse sein. Ein uAuthzId SOLLTE (SHOULD NOT) nicht als global eindeutig angenommen werden. Zum Vergleich von uAuthzId-Werten MUSS (MUST) jeder uAuthzId-Wert mithilfe des SASLprep-Algorithmus [RFC4013] als „query"-Zeichenkette ([RFC3454], Abschnitt 7) vorbereitet werden, und dann werden die beiden Werte oktettweise verglichen.

Die obige Grammatik ist erweiterbar. Die Produktion authzId kann erweitert werden, um zusätzliche Formen von Identitäten zu unterstützen. Jede Form ist durch ihr eindeutiges Präfix gekennzeichnet (siehe Abschnitt 3.12 von [RFC4520] zu Registrierungsanforderungen).

5.2.2. SASL-Semantik innerhalb von LDAP​

Implementierer müssen darauf achten, die Semantik der SASL-Spezifikationen beizubehalten, wenn sie Daten verarbeiten, die im LDAP-Protokoll eine andere Semantik haben.

Beispielsweise verwendet der SASL-DIGEST-MD5-Authentifizierungsmechanismus [DIGEST-MD5] eine Authentifizierungsidentität und einen Realm, die syntaktisch einfache Zeichenketten und semantisch einfache Benutzernamen- [RFC4013] und Realm-Werte sind. Diese Werte sind keine LDAP-DNs, und es wird nicht verlangt, dass sie als solche dargestellt oder behandelt werden.

5.2.3. SASL-EXTERNAL-Authentifizierungsmechanismus​

Ein Client kann den Mechanismus SASL EXTERNAL ([RFC4422], Anhang A) verwenden, um den LDAP-Server zu bitten, ihn zu authentifizieren und mithilfe der von einer unteren Sicherheitsschicht ausgetauschten Sicherheits-Anmeldeinformationen (etwa durch TLS-Authentifizierung) eine resultierende Autorisierungsidentität aufzubauen. Wurden die Authentifizierungs-Anmeldeinformationen des Clients nicht auf einer unteren Sicherheitsschicht aufgebaut, MUSS (MUST) der SASL-EXTERNAL-Bind mit einem resultCode inappropriateAuthentication fehlschlagen. Obwohl diese Situation zur Folge hat, dass die LDAP-Sitzung in einem anonymen Zustand verbleibt (Abschnitt 4), wird der Zustand einer eingerichteten Sicherheitsschicht nicht beeinflusst.

Ein Client kann entweder verlangen, dass seine Autorisierungsidentität automatisch aus seinen auf einer unteren Sicherheitsschicht ausgetauschten Authentifizierungs-Anmeldeinformationen abgeleitet wird, oder er kann ausdrücklich eine gewünschte Autorisierungsidentität angeben. Ersteres wird als implizite Geltendmachung bezeichnet, letzteres als ausdrückliche Geltendmachung.

5.2.3.1. Implizite Geltendmachung​

Eine implizite Geltendmachung der Autorisierungsidentität erfolgt durch Aufrufen einer Bind-Anforderung der SASL-Form unter Verwendung des Mechanismusnamens EXTERNAL, die das optionale Feld credentials (in der Sequenz SaslCredentials in der BindRequest) nicht einschließt. Der Server leitet die Autorisierungsidentität des Clients gemäß der lokalen Richtlinie aus der von einer Sicherheitsschicht bereitgestellten Authentifizierungsidentität ab (z. B. aus einem während der Einrichtung der TLS-Schicht verwendeten öffentlichen Schlüsselzertifikat). Die zugrunde liegenden Mechanismen hierfür sind implementierungsspezifisch.

5.2.3.2. Ausdrückliche Geltendmachung​

Eine ausdrückliche Geltendmachung der Autorisierungsidentität erfolgt durch Aufrufen einer Bind-Anforderung der SASL-Form unter Verwendung des Mechanismusnamens EXTERNAL, die das Feld credentials (in der Sequenz SaslCredentials in der BindRequest) einschließt. Der Wert des Felds credentials (ein OCTET STRING) ist die geltend gemachte Autorisierungsidentität und MUSS (MUST) wie in Abschnitt 5.2.1.8 dokumentiert aufgebaut werden.