6.2 Client-Befehle - Nicht authentifizierter Zustand (Client Commands - Not Authenticated State)
Im nicht authentifizierten Zustand etabliert der AUTHENTICATE- oder LOGIN-Befehl die Authentifizierung und tritt in den authentifizierten Zustand ein. Der AUTHENTICATE-Befehl bietet einen allgemeinen Mechanismus für eine Vielzahl von Authentifizierungstechniken, Datenschutz und Integritätsprüfung, während der LOGIN-Befehl ein konventionelles Benutzername-Klartext-Passwort-Paar verwendet und keine Möglichkeit bietet, Datenschutz oder Integritätsprüfung zu etablieren.
Der STARTTLS-Befehl ist eine alternative Form zur Etablierung von Sitzungsdatenschutz und Integritätsprüfung, etabliert aber selbst keine Authentifizierung und tritt nicht in den authentifizierten Zustand ein.
Server-Implementierungen können (können) den Zugriff auf bestimmte Postfächer ohne Etablierung der Authentifizierung erlauben. Dies kann mittels des ANONYMOUS [SASL]-Authentifikators geschehen, der in [ANONYMOUS] beschrieben ist. Eine ältere Konvention ist ein LOGIN-Befehl mit der Benutzer-ID "anonymous"; in diesem Fall ist ein Passwort erforderlich, obwohl der Server wählen kann, jedes Passwort zu akzeptieren. Die Einschränkungen für anonyme Benutzer sind implementierungsabhängig.
Sobald authentifiziert (einschließlich als anonym), ist es nicht möglich, wieder in den nicht authentifizierten Zustand einzutreten.
Zusätzlich zu den universellen Befehlen (CAPABILITY, NOOP und LOGOUT) sind die folgenden Befehle im nicht authentifizierten Zustand gültig: STARTTLS, AUTHENTICATE und LOGIN. Siehe die Sicherheitsüberlegungen (Abschnitt 11) für wichtige Informationen zu diesen Befehlen.
6.2.1 STARTTLS-Befehl
Argumente: keine
Antworten: keine spezifische Antwort für diesen Befehl
Ergebnis:
- OK - starttls abgeschlossen, TLS-Verhandlung beginnen
- NO - TLS-Verhandlung kann aufgrund eines Server-Konfigurationsfehlers nicht initiiert werden
- BAD - STARTTLS nach erfolgreicher TLS-Verhandlung empfangen oder Argumente ungültig
Beachten Sie, dass der STARTTLS-Befehl nur auf Klartext-Ports verfügbar ist. Der Server muss (muss) immer mit einer markierten BAD-Antwort antworten, wenn der STARTTLS-Befehl auf einem impliziten TLS-Port empfangen wird.
Eine TLS [TLS-1.3]-Verhandlung beginnt unmittelbar nach dem CRLF am Ende der markierten OK-Antwort vom Server. Sobald ein Client einen STARTTLS-Befehl ausgibt, darf (darf) er keine weiteren Befehle ausgeben, bis eine Serverantwort gesehen wurde und die TLS-Verhandlung abgeschlossen ist. Einige frühere Server-Implementierungen haben die STARTTLS-Verarbeitung fehlerhaft implementiert und enthalten bekanntermaßen die STARTTLS-Klartext-Befehlsinjektionsschwachstelle [CERT-555316]. Um diese Schwachstelle zu vermeiden, müssen (müssen) Server-Implementierungen eines der folgenden Dinge tun, wenn Daten im selben TCP-Puffer nach dem CRLF empfangen werden, das den STARTTLS-Befehl startet:
-
Zusätzliche Daten aus dem TCP-Puffer werden als Beginn des TLS-Handshakes interpretiert. (Wenn die Daten im Klartext vorliegen, führt dies zum Scheitern des TLS-Handshakes.)
-
Zusätzliche Daten aus dem TCP-Puffer werden verworfen.
Beachten Sie, dass die erste Option für Clients freundlicher ist, die den Beginn des STARTTLS-Befehls mit TLS-Handshake-Daten in eine Pipeline stellen.
Nach erfolgreicher TLS-Verhandlung bleibt der Server im nicht authentifizierten Zustand, auch wenn während der TLS-Verhandlung Client-Anmeldeinformationen bereitgestellt werden. Dies schließt nicht aus, dass ein Authentifizierungsmechanismus wie EXTERNAL (definiert in [SASL]) die durch die TLS-Verhandlung bestimmte Client-Identität verwendet.
Sobald TLS gestartet wurde, muss (muss) der Client zwischengespeicherte Informationen über Server-Fähigkeiten verwerfen und sollte (sollte) den CAPABILITY-Befehl erneut ausgeben. Dies ist notwendig, um sich vor aktiven Angriffen zu schützen, die die Fähigkeitenliste vor STARTTLS ändern. Der Server kann (kann) verschiedene Fähigkeiten ankündigen und sollte (sollte) insbesondere die STARTTLS-Fähigkeit nach einem erfolgreichen STARTTLS-Befehl nicht (nicht) ankündigen.
Beispiel:
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS-Verhandlung, weitere Befehle unter TLS-Schicht>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: a004 OK Success (tls protection)
6.2.2 AUTHENTICATE-Befehl
Argumente:
- SASL-Authentifizierungsmechanismusname
- OPTIONALE anfängliche Antwort
Antworten: Fortsetzungsdaten können angefordert werden
Ergebnis:
- OK - Authentifizierung abgeschlossen, jetzt im authentifizierten Zustand
- NO - Authentifizierungsfehler: nicht unterstützter Authentifizierungsmechanismus, Anmeldeinformationen abgelehnt
- BAD - Befehl unbekannt oder Argumente ungültig, Authentifizierungsaustausch abgebrochen
Der AUTHENTICATE-Befehl zeigt einen [SASL]-Authentifizierungsmechanismus dem Server an. Wenn der Server den angeforderten Authentifizierungsmechanismus unterstützt, führt er einen Authentifizierungsprotokoll-Austausch durch, um den Client zu authentifizieren und zu identifizieren. Er kann (kann) auch eine OPTIONALE Sicherheitsschicht für nachfolgende Protokollinteraktionen aushandeln. Wenn der angeforderte Authentifizierungsmechanismus nicht unterstützt wird, sollte (sollte) der Server den AUTHENTICATE-Befehl ablehnen, indem er eine markierte NO-Antwort sendet.
Der AUTHENTICATE-Befehl unterstützt die optionale "anfängliche Antwort"-Funktion, die in Abschnitt 4 von [SASL] definiert ist. Der Client muss sie nicht verwenden. Wenn ein SASL-Mechanismus "anfängliche Antwort" unterstützt, aber vom Client nicht angegeben wird, behandelt der Server dies wie in Abschnitt 3 von [SASL] angegeben.
Der von diesem Protokollprofil von [SASL] angegebene Dienstname ist "imap".
Der Authentifizierungsprotokoll-Austausch besteht aus einer Reihe von Server-Herausforderungen und Client-Antworten, die spezifisch für den Authentifizierungsmechanismus sind. Eine Server-Herausforderung besteht aus einer Befehlsfortsetzungsanforderungsantwort mit dem "+"-Token, gefolgt von einer base64-codierten (siehe Abschnitt 4 von [RFC4648]) Zeichenkette. Die Client-Antwort besteht aus einer einzelnen Zeile, die aus einer base64-codierten Zeichenkette besteht. Wenn der Client einen Authentifizierungsaustausch abbrechen möchte, gibt er eine Zeile aus, die aus einem einzelnen "*" besteht. Wenn der Server eine solche Antwort empfängt oder wenn er eine ungültige base64-Zeichenkette empfängt (z. B. Zeichen außerhalb des base64-Alphabets oder nicht-terminales "="), muss (muss) er den AUTHENTICATE-Befehl ablehnen, indem er eine markierte BAD-Antwort sendet.
Wie bei jeder anderen Client-Antwort muss (muss) die anfängliche Antwort als base64 codiert sein. Sie muss (muss) auch außerhalb einer zitierten Zeichenkette oder eines Literals übertragen werden. Um eine anfängliche Antwort der Länge Null zu senden, muss (muss) der Client ein einzelnes Füllzeichen ("=") senden. Dies zeigt an, dass die Antwort vorhanden ist, aber es sich um eine Zeichenkette der Länge Null handelt.
Beim Decodieren der base64-Daten in der anfänglichen Antwort müssen (müssen) Decodierungsfehler wie in jeder normalen SASL-Client-Antwort behandelt werden, d. h. mit einer markierten BAD-Antwort.
Wenn der Client eine anfängliche Antwort mit einem SASL-Mechanismus verwendet, der keine anfängliche Antwort unterstützt, muss (muss) der Server den Befehl mit einer markierten BAD-Antwort ablehnen.
Wenn durch den [SASL]-Authentifizierungsaustausch eine Sicherheitsschicht ausgehandelt wird, tritt sie unmittelbar nach dem CRLF in Kraft, das den Authentifizierungsaustausch für den Client abschließt, und dem CRLF der markierten OK-Antwort für den Server.
Beispiel:
S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED] Server ready
C: A01 STARTTLS
S: A01 OK STARTTLS completed
<TLS-Verhandlung, weitere Befehle unter TLS-Schicht>
C: A02 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: A02 OK CAPABILITY completed
C: A03 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A03 OK Success (tls protection)
6.2.3 LOGIN-Befehl
Argumente:
- Benutzername
- Passwort
Antworten: keine spezifischen Antworten für diesen Befehl
Ergebnis:
- OK - Anmeldung abgeschlossen, jetzt im authentifizierten Zustand
- NO - Anmeldefehler: Benutzername oder Passwort abgelehnt
- BAD - Befehl unbekannt oder Argumente ungültig
Der LOGIN-Befehl identifiziert den Client gegenüber dem Server und trägt das Klartext-Passwort zur Authentifizierung dieses Benutzers. Der LOGIN-Befehl sollte (sollte) nur als letztes Mittel verwendet werden (nachdem versucht wurde, sich mit dem AUTHENTICATE-Befehl ein- oder mehrmals zu authentifizieren und dies fehlgeschlagen ist), und es wird empfohlen, dass Client-Implementierungen eine Möglichkeit haben, jede automatische Verwendung des LOGIN-Befehls zu deaktivieren.
Beispiel:
C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
Hinweis: Die Verwendung des LOGIN-Befehls über ein unsicheres Netzwerk (wie das Internet) stellt ein Sicherheitsrisiko dar, da jeder, der den Netzwerkverkehr überwacht, Klartext-Passwörter erhalten kann. Aus diesem Grund dürfen (dürfen) Clients LOGIN nicht (nicht) in unsicheren Netzwerken verwenden.