6.2 Comandi client - Stato non autenticato (Client Commands - Not Authenticated State)
Nello stato non autenticato, il comando AUTHENTICATE o LOGIN stabilisce l'autenticazione ed entra nello stato autenticato. Il comando AUTHENTICATE fornisce un meccanismo generale per una varietà di tecniche di autenticazione, protezione della privacy e controllo dell'integrità, mentre il comando LOGIN utilizza una coppia convenzionale nome utente e password in chiaro e non ha mezzi per stabilire la protezione della privacy o il controllo dell'integrità.
Il comando STARTTLS è una forma alternativa di stabilire la protezione della privacy e il controllo dell'integrità della sessione, ma non stabilisce di per sé l'autenticazione né entra nello stato autenticato.
Le implementazioni server possono (possono) consentire l'accesso a determinate caselle di posta senza stabilire l'autenticazione. Questo può essere fatto per mezzo dell'autenticatore ANONYMOUS [SASL] descritto in [ANONYMOUS]. Una convenzione più vecchia è un comando LOGIN che utilizza l'userid "anonymous"; in questo caso, è richiesta una password sebbene il server possa scegliere di accettare qualsiasi password. Le restrizioni imposte agli utenti anonimi dipendono dall'implementazione.
Una volta autenticati (incluso come anonimi), non è possibile rientrare nello stato non autenticato.
Oltre ai comandi universali (CAPABILITY, NOOP e LOGOUT), i seguenti comandi sono validi nello stato non autenticato: STARTTLS, AUTHENTICATE e LOGIN. Vedere le Considerazioni sulla sicurezza (Sezione 11) per informazioni importanti su questi comandi.
6.2.1 Comando STARTTLS
Argomenti: nessuno
Risposte: nessuna risposta specifica per questo comando
Risultato:
- OK - starttls completata, iniziare la negoziazione TLS
- NO - la negoziazione TLS non può essere avviata a causa di un errore di configurazione del server
- BAD - STARTTLS ricevuto dopo una negoziazione TLS riuscita o argomenti non validi
Si noti che il comando STARTTLS è disponibile solo sulle porte in chiaro. Il server deve (deve) sempre rispondere con una risposta BAD etichettata quando il comando STARTTLS viene ricevuto su una porta TLS implicita.
Una negoziazione TLS [TLS-1.3] inizia immediatamente dopo il CRLF alla fine della risposta OK etichettata dal server. Una volta che un client emette un comando STARTTLS, non deve (non deve) emettere ulteriori comandi fino a quando non viene vista una risposta del server e la negoziazione TLS è completa. Alcune implementazioni server passate hanno implementato in modo errato l'elaborazione STARTTLS e sono note per contenere la vulnerabilità di iniezione di comandi in chiaro STARTTLS [CERT-555316]. Per evitare questa vulnerabilità, le implementazioni server devono (devono) fare una delle seguenti cose se vengono ricevuti dati nello stesso buffer TCP dopo il CRLF che avvia il comando STARTTLS:
-
I dati extra dal buffer TCP vengono interpretati come l'inizio della negoziazione TLS. (Se i dati sono in chiaro, ciò risulterà nel fallimento della negoziazione TLS.)
-
I dati extra dal buffer TCP vengono scartati.
Si noti che la prima opzione è più amichevole per i client che mettono in pipeline l'inizio del comando STARTTLS con i dati di negoziazione TLS.
Dopo una negoziazione TLS riuscita, il server rimane nello stato non autenticato, anche se vengono fornite credenziali client durante la negoziazione TLS. Questo non preclude un meccanismo di autenticazione come EXTERNAL (definito in [SASL]) dall'utilizzare l'identità client determinata dalla negoziazione TLS.
Una volta avviato TLS, il client deve (deve) scartare le informazioni memorizzate nella cache sulle capacità del server e dovrebbe (dovrebbe) riemettere il comando CAPABILITY. Questo è necessario per proteggersi da attacchi attivi che alterano l'elenco delle capacità prima di STARTTLS. Il server può (può) pubblicizzare capacità diverse e, in particolare, non dovrebbe (non dovrebbe) pubblicizzare la capacità STARTTLS dopo un comando STARTTLS riuscito.
Esempio:
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<Negoziazione TLS, i comandi successivi sono sotto il livello TLS>
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 Comando AUTHENTICATE
Argomenti:
- Nome del meccanismo di autenticazione SASL
- Risposta iniziale OPZIONALE
Risposte: i dati di continuazione possono essere richiesti
Risultato:
- OK - autenticazione completata, ora nello stato autenticato
- NO - fallimento dell'autenticazione: meccanismo di autenticazione non supportato, credenziali rifiutate
- BAD - comando sconosciuto o argomenti non validi, scambio di autenticazione annullato
Il comando AUTHENTICATE indica un meccanismo di autenticazione [SASL] al server. Se il server supporta il meccanismo di autenticazione richiesto, esegue uno scambio di protocollo di autenticazione per autenticare e identificare il client. Può (può) anche negoziare un livello di sicurezza OPZIONALE per le interazioni di protocollo successive. Se il meccanismo di autenticazione richiesto non è supportato, il server dovrebbe (dovrebbe) rifiutare il comando AUTHENTICATE inviando una risposta NO etichettata.
Il comando AUTHENTICATE supporta la funzionalità di "risposta iniziale" opzionale definita nella Sezione 4 di [SASL]. Il client non ha bisogno di usarla. Se un meccanismo SASL supporta la "risposta iniziale", ma non è specificata dal client, il server la gestisce come specificato nella Sezione 3 di [SASL].
Il nome del servizio specificato dal profilo [SASL] di questo protocollo è "imap".
Lo scambio di protocollo di autenticazione consiste in una serie di sfide del server e risposte del client che sono specifiche del meccanismo di autenticazione. Una sfida del server consiste in una risposta di richiesta di continuazione del comando con il token "+" seguito da una stringa codificata in base64 (vedere Sezione 4 di [RFC4648]). La risposta del client consiste in una singola riga costituita da una stringa codificata in base64. Se il client desidera annullare uno scambio di autenticazione, emette una riga costituita da un singolo "*". Se il server riceve tale risposta, o se riceve una stringa base64 non valida (ad esempio, caratteri al di fuori dell'alfabeto base64 o "=" non terminale), deve (deve) rifiutare il comando AUTHENTICATE inviando una risposta BAD etichettata.
Come con qualsiasi altra risposta client, la risposta iniziale deve (deve) essere codificata come base64. Deve (deve) anche essere trasmessa al di fuori di una stringa tra virgolette o di un letterale. Per inviare una risposta iniziale di lunghezza zero, il client deve (deve) inviare un singolo carattere di riempimento ("="). Questo indica che la risposta è presente, ma è una stringa di lunghezza zero.
Esempio:
S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED] Server ready
C: A01 STARTTLS
S: A01 OK STARTTLS completed
<Negoziazione TLS, i comandi successivi sono sotto il livello TLS>
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 Comando LOGIN
Argomenti:
- nome utente
- password
Risposte: nessuna risposta specifica per questo comando
Risultato:
- OK - accesso completato, ora nello stato autenticato
- NO - fallimento dell'accesso: nome utente o password rifiutati
- BAD - comando sconosciuto o argomenti non validi
Il comando LOGIN identifica il client al server e trasporta la password in chiaro che autentica questo utente. Il comando LOGIN non dovrebbe (non dovrebbe) essere utilizzato se non come ultima risorsa (dopo aver tentato e fallito l'autenticazione utilizzando il comando AUTHENTICATE una o più volte), ed è raccomandato che le implementazioni client abbiano un mezzo per disabilitare qualsiasi uso automatico del comando LOGIN.
Esempio:
C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
Nota: L'uso del comando LOGIN su una rete non sicura (come Internet) è un rischio per la sicurezza, perché chiunque monitori il traffico di rete può ottenere password in chiaro. Per questo motivo, i client non devono (non devono) usare LOGIN su reti non sicure.