Anhang B. Stand der Technik (Prior Art)

(Dieser Abschnitt ist nicht normativ.)

Die Empfehlungen dieses Dokuments abstrahieren von den Empfehlungen der Spezifikationen für eine breite Palette von Anwendungsprotokollen. Zu Vergleichszwecken und um die Geschichte des Denkens innerhalb der IETF bezüglich der Überprüfung der Anwendungsdienst-Identität zu skizzieren, sammelt dieser informative Abschnitt den Stand der Technik, indem er den genauen Text aus verschiedenen RFCs enthält (die einzigen Änderungen sind einige Änderungen der Referenznamen für die Konsistenz mit dem Hauptteil dieses Dokuments und das Weglassen von irrelevance Text, markiert durch die Zeichen "[...]").

B.1. IMAP, POP3 und ACAP (1999)

Im Jahr 1999 spezifizierte [USINGTLS] den folgenden Text bezüglich der Überprüfung der Anwendungsdienst-Identität in IMAP, POP3 und ACAP.

2.4. Server-Identitätsüberprüfung (Server Identity Check)

Während der TLS-Verhandlung MUSS (MUST) der Client sein Verständnis des Server-Hostnamens gegen die Server-Identität überprüfen, die in der Certificate-Nachricht des Servers präsentiert wird, um Angriffe durch Man-in-the-Middle zu verhindern. Der Abgleich erfolgt gemäß den folgenden Regeln:

Der Client MUSS (MUST) den Server-Hostnamen, den er zum Öffnen der Verbindung verwendet hat, als den Wert verwenden, der mit dem im Server-Zertifikat ausgedrückten Servernamen verglichen wird. Der Client DARF NICHT (MUST NOT) irgendeine Form des Server-Hostnamens verwenden, die von einer unsicheren entfernten Quelle abgeleitet ist (z. B. ein unsicherer DNS-Lookup). CNAME-Kanonisierung wird nicht durchgeführt.

Wenn eine subjectAltName-Erweiterung vom Typ dNSName im Zertifikat vorhanden ist, SOLLTE (SHOULD) sie als Quelle der Identität des Servers verwendet werden.

Der Abgleich erfolgt ohne Berücksichtigung der Groß-/Kleinschreibung.

Das Wildcard-Zeichen "*" KANN (MAY) als linker Namensbestandteil im Zertifikat verwendet werden. Zum Beispiel würde *.example.com mit a.example.com, foo.example.com usw. übereinstimmen, aber nicht mit example.com.

Wenn das Zertifikat mehrere Namen enthält (z. B. mehr als ein dNSName-Feld), wird eine Übereinstimmung mit einem dieser Felder als akzeptabel angesehen.

Wenn die Übereinstimmung fehlschlägt, SOLLTE (SHOULD) der Client entweder eine explizite Benutzerbestätigung verlangen oder die Verbindung beenden und angeben, dass die Identität des Servers verdächtig ist.

B.2. HTTP (2000)

Im Jahr 2000 spezifizierte [HTTP-TLS] den folgenden Text bezüglich der Überprüfung der Anwendungsdienst-Identität in HTTP.

3.1. Server-Identität (Server Identity)

Im Allgemeinen werden HTTP/TLS-Anforderungen durch Dereferenzieren eines URI generiert. Infolgedessen ist der Hostname des Servers dem Client bekannt. Wenn der Hostname verfügbar ist, MUSS (MUST) der Client ihn gegen die Identität des Servers überprüfen, wie sie in der Certificate-Nachricht des Servers präsentiert wird, um Angriffe durch Man-in-the-Middle zu verhindern.

Wenn der Client externe Informationen bezüglich der erwarteten Identität des Servers hat, KANN (MAY) die Überprüfung des Hostnamens weggelassen werden. (Zum Beispiel kann sich ein Client mit einer Maschine verbinden, deren Adresse und Hostname dynamisch sind, aber der Client kennt das Zertifikat, das der Server präsentieren wird.) In solchen Fällen ist es wichtig, den Umfang der akzeptablen Zertifikate so weit wie möglich einzugrenzen, um Angriffe durch Man-in-the-Middle zu verhindern. In speziellen Fällen kann es für den Client angemessen sein, die Identität des Servers einfach zu ignorieren, aber es muss verstanden werden, dass dies die Verbindung für aktive Angriffe offen lässt.

Wenn eine subjectAltName-Erweiterung vom Typ dNSName vorhanden ist, MUSS (MUST) diese als Identität verwendet werden. Andernfalls MUSS (MUST) das (spezifischste) Common Name-Feld im Subject-Feld des Zertifikats verwendet werden. Obwohl die Verwendung des Common Name bestehende Praxis ist, wird sie missbilligt, und Zertifizierungsstellen werden ermutigt, stattdessen den dNSName zu verwenden.

Der Abgleich erfolgt unter Verwendung der in [PKIX-OLD] spezifizierten Abgleichsregeln. Wenn mehr als eine Identität eines gegebenen Typs im Zertifikat vorhanden ist (z. B. mehr als ein dNSName-Name), wird eine Übereinstimmung mit einer beliebigen der Menge als akzeptabel angesehen. Namen können das Wildcard-Zeichen * enthalten, das als übereinstimmend mit jedem einzelnen Domänennamen-Bestandteil oder Bestandteilsfragment angesehen wird. Z. B. stimmt .a.com mit foo.a.com überein, aber nicht mit bar.foo.a.com. f.com stimmt mit foo.com überein, aber nicht mit bar.com.

In einigen Fällen wird der URI als IP-Adresse anstelle eines Hostnamens angegeben. In diesem Fall muss der subjectAltName iPAddress im Zertifikat vorhanden sein und genau mit der IP im URI übereinstimmen.

Wenn der Hostname nicht mit der Identität im Zertifikat übereinstimmt, MÜSSEN (MUST) benutzerorientierte Clients entweder den Benutzer benachrichtigen (Clients KÖNNEN (MAY) dem Benutzer in jedem Fall die Möglichkeit geben, die Verbindung fortzusetzen) oder die Verbindung mit einem Fehler wegen falschem Zertifikat beenden. Automatisierte Clients MÜSSEN (MUST) den Fehler in einem geeigneten Audit-Protokoll protokollieren (falls verfügbar) und SOLLTEN (SHOULD) die Verbindung beenden (mit einem Fehler wegen falschem Zertifikat). Automatisierte Clients KÖNNEN (MAY) eine Konfigurationseinstellung bereitstellen, um diese Überprüfung zu deaktivieren, MÜSSEN (MUST) aber eine Einstellung bereitstellen, um sie zu aktivieren.

Beachten Sie, dass in vielen Fällen der URI selbst aus einer nicht vertrauenswürdigen Quelle stammt. Die obige Überprüfung bietet keinen Schutz gegen Angriffe, bei denen diese Quelle kompromittiert ist. Wenn der URI beispielsweise durch Klicken auf eine HTML-Seite erhalten wurde, die selbst nicht über HTTP/TLS erhalten wurde, könnte ein Man-in-the-Middle den URI ersetzt haben. Um diese Form des Angriffs zu verhindern, sollten Benutzer das vom Server präsentierte Zertifikat sorgfältig prüfen, um festzustellen, ob es ihren Erwartungen entspricht.

B.3. LDAP (2000/2006)

Im Jahr 2000 spezifizierte [LDAP-TLS] den folgenden Text bezüglich der Überprüfung der Anwendungsdienst-Identität in LDAP.

3.6. Server-Identitätsüberprüfung (Server Identity Check)

Der Client MUSS (MUST) sein Verständnis des Server-Hostnamens gegen die Server-Identität überprüfen, die in der Certificate-Nachricht des Servers präsentiert wird, um Angriffe durch Man-in-the-Middle zu verhindern.

Der Abgleich erfolgt gemäß den folgenden Regeln:

Der Client MUSS (MUST) den Server-Hostnamen, den er zum Öffnen der LDAP-Verbindung verwendet hat, als den Wert verwenden, der mit dem im Server-Zertifikat ausgedrückten Servernamen verglichen wird. Der Client DARF NICHT (MUST NOT) den kanonischen DNS-Namen des Servers oder eine andere abgeleitete Form des Namens verwenden.

Wenn eine subjectAltName-Erweiterung vom Typ dNSName im Zertifikat vorhanden ist, SOLLTE (SHOULD) sie als Quelle der Identität des Servers verwendet werden.

Der Abgleich erfolgt ohne Berücksichtigung der Groß-/Kleinschreibung.

Das Wildcard-Zeichen "*" ist erlaubt. Wenn es vorhanden ist, gilt es nur für den linken Namensbestandteil.

Zum Beispiel würde *.bar.com mit a.bar.com, b.bar.com usw. übereinstimmen, aber nicht mit bar.com. Wenn mehr als eine Identität eines gegebenen Typs im Zertifikat vorhanden ist (z. B. mehr als ein dNSName-Name), wird eine Übereinstimmung mit einer beliebigen der Menge als akzeptabel angesehen.

Wenn der Hostname gemäß der obigen Überprüfung nicht mit der dNSName-basierten Identität im Zertifikat übereinstimmt, SOLLTEN (SHOULD) benutzerorientierte Clients entweder den Benutzer benachrichtigen (Clients können dem Benutzer in diesem Fall die Möglichkeit geben, die LDAP-Sitzung fortzusetzen) oder die Verbindung beenden und angeben, dass die Identität des Servers verdächtig ist. Automatisierte Clients SOLLTEN (SHOULD) die Verbindung schließen und einen Fehler zurückgeben und/oder protokollieren, der angibt, dass die Identität des Servers verdächtig ist.

Über die in diesem Abschnitt beschriebene Server-Identitätsüberprüfung hinaus SOLLTEN (SHOULD) Clients bereit sein, weitere Überprüfungen durchzuführen, um sicherzustellen, dass der Server berechtigt ist, den Dienst bereitzustellen, den er beobachtet wird bereitzustellen. Der Client KANN (MAY) lokale Richtlinieninformationen verwenden müssen.

Im Jahr 2006 spezifizierte [LDAP-AUTH] den folgenden Text bezüglich der Überprüfung der Anwendungsdienst-Identität in LDAP.

3.1.3. Server-Identitätsüberprüfung (Server Identity Check)

Um Angriffe durch Man-in-the-Middle zu verhindern, MUSS (MUST) der Client die Identität des Servers (wie in der Certificate-Nachricht des Servers präsentiert) überprüfen. In diesem Abschnitt wird das Verständnis des Clients von der Identität des Servers (typischerweise die Identität, die zum Aufbau der Transportverbindung verwendet wird) 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 erzeugt wird. Sobald eine Übereinstimmung erzeugt wird, wurde die Identität des Servers überprüft und die Server-Identitätsüberprüfung ist abgeschlossen. Verschiedene subjectAltName-Typen werden auf unterschiedliche Weise abgeglichen. Die Abschnitte 3.1.3.1 - 3.1.3.3 erläutern, wie Werte verschiedener subjectAltName-Typen verglichen werden.

Der Client kann die Referenzidentität vor der Durchführung des Vergleichs auf einen anderen Typ abbilden. Das Mapping kann für jeden verfügbaren subjectAltName-Typ durchgeführt werden, auf den die Referenzidentität abgebildet werden kann. Die Referenzidentität sollte jedoch nur auf Typen abgebildet werden, für die das Mapping entweder inhärent sicher ist (z. B. Extrahieren eines DNS-Namens aus einem URI zum Vergleich mit einem subjectAltName vom Typ dNSName) oder auf sichere Weise durchgeführt wird (z. B. unter Verwendung von [DNSSEC] oder unter Verwendung einer vom Benutzer oder Administrator konfigurierten Host-zu-Adresse/Adresse-zu-Host-Lookup-Tabelle).

Die Identität des Servers kann auch überprüft werden, indem die Referenzidentität mit dem Common Name (CN) [LDAP-SCHEMA] Wert im letzten Relative Distinguished Name (RDN) des Subject-Felds des Server-Zertifikats verglichen wird (wobei sich "letzter" auf die DER-codierte Reihenfolge bezieht, nicht auf die Reihenfolge der Präsentation in einer String-Repräsentation der DER-codierten Daten). Dieser Vergleich erfolgt unter Verwendung der Regeln für den Vergleich von DNS-Namen in Abschnitt 3.1.3.1 unten, mit der Ausnahme, dass kein Wildcard-Abgleich erlaubt ist. Die Verwendung des Common Name-Werts ist bestehende Praxis, wird jedoch missbilligt, und Zertifizierungsstellen werden ermutigt, stattdessen subjectAltName-Werte zu verwenden. Beachten Sie, dass TLS-Implementierungen DNs in Zertifikaten gemäß X.500 oder anderen Konventionen darstellen können. Beispielsweise ordnen einige X.500-Implementierungen RDNs in einem DN unter Verwendung einer Links-nach-Rechts-Konvention (vom signifikantesten zum am wenigsten signifikanten) anstelle der LDAP-Rechts-nach-Links-Konvention an.

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

Über die in diesem Abschnitt beschriebene Server-Identitätsüberprüfung hinaus sollten Clients bereit sein, weitere Überprüfungen durchzuführen, um sicherzustellen, dass der Server berechtigt ist, den Dienst bereitzustellen, den er angefordert wird bereitzustellen. Der Client muss möglicherweise lokale Richtlinieninformationen verwenden, um diese Bestimmung vorzunehmen.

3.1.3.1. Vergleich von DNS-Namen (Comparison of DNS Names)

Wenn die Referenzidentität ein internationalisierter Domänenname ist, MÜSSEN (MUST) konforme Implementierungen ihn in das in Abschnitt 4 von RFC 3490 [IDNA2003] spezifizierte ASCII Compatible Encoding (ACE) Format konvertieren, bevor sie ihn mit subjectAltName-Werten vom Typ dNSName vergleichen. Konkret MÜSSEN (MUST) konforme Implementierungen die in Abschnitt 4 von RFC 3490 spezifizierte Konvertierungsoperation wie folgt durchführen:

in Schritt 1 SOLL (SHALL) der Domänenname als "gespeicherter String" betrachtet werden;

in Schritt 3 das Flag namens "UseSTD3ASCIIRules" setzen;

in Schritt 4 jedes Label mit der Operation "ToASCII" verarbeiten; und

in Schritt 5 alle Label-Trennzeichen in U+002E (Punkt) ändern.

Nach Durchführung der "ToASCII"-Konvertierung MÜSSEN (MUST) die DNS-Labels und Namen gemäß den in Abschnitt 3 von RFC 3490 spezifizierten Regeln auf Gleichheit verglichen werden.

Das Wildcard-Zeichen '*' (ASCII 42) ist in subjectAltName-Werten vom Typ dNSName erlaubt, und dann nur als das linke (am wenigsten signifikante) DNS-Label in diesem Wert. Dieses Wildcard-Zeichen entspricht jedem einzelnen linken DNS-Label im Servernamen. Das heißt, das Subjekt *.example.com entspricht dem 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 (Comparison of IP Addresses)

Wenn die Referenzidentität eine IP-Adresse ist, MUSS (MUST) die Identität in einen Oktett-String in "Netzwerk-Byte-Reihenfolge" [IP] [IPv6] konvertiert werden. Für IP Version 4, wie in RFC 791 spezifiziert, enthält der Oktett-String genau 4 Oktetts. Für IP Version 6, wie in RFC 2460 spezifiziert, enthält der Oktett-String genau 16 Oktetts. Dieser Oktett-String wird dann mit subjectAltName-Werten vom Typ iPAddress verglichen. Eine Übereinstimmung liegt vor, wenn die Referenzidentität (Oktett-String) und der Wert (Oktett-String) identisch sind.

3.1.3.3. Vergleich anderer subjectName-Typen (Comparison of Other subjectName Types)

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