Network Working Group J. Myers Request for Comments: 1734 Carnegie Mellon Category: Standards Track December 1994 Il comando di autenticazione POP3 AUTH Traduzione a cura di ComiSAT Brescia, Apr. 2003 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questo documento Questo documento specifica una traccia di protocollo Internet standard per la comunita’ Internet, e richiede discussioni e suggerimenti per migliorie. Per la standardizzazione e lo stato di questo protocollo si faccia riferimento all’edizione corrente dell’”Internet Official Protocol Standards” (STD 1). La distribuzione di questo documento non e’ soggetta a limitazioni. 1. Introduzione Questo documento descrive il comando facoltativo AUTH, per indicare un meccanismo di autenticazione al server, fornendo uno scambio di protocollo di autenticazione e facoltativamente negoziando un meccanismo di protezione per interazioni tra protocolli successivi. I meccanismi di autenticazione di protezione usati dal comando POP3 AUTH sono quelli utilizzati dall’IMPAP4. 2. Il comando AUTH AUTH meccanismo Argomenti: Una stringa che identifica un meccanismo di autenticazione IMAP4, come definito dall’[IMAP4-AUTH]. Ogni utilizzo della stringa “imap” usata in un’identita’ di autenticazione server nella definizione di un meccanismo di autenticazione viene sostituita con la stringa “pop”. Restrizioni: Usabile solamente nello stato di AUTORIZZAZIONE Spiegazione: Il comando AUTH indica al server un meccanismo di autenticazione. Se il server supporta il meccanismo di autenticazione richiesto, effettua uno scambio di protocollo di autenticazione per autenticare ed identificare l’utente. Facoltativamente, negozia anche un meccanismo di protezione per interazioni di protocollo successive. Se il meccanismo di autenticazione richiesto non e’ Myers [Page 1] RFC 1734 POP3 AUTH December 1994 supportato, il server dovrebbe rifiutare il comando AUTH inviando una risposta negativa. Lo scambio di protocollo di autenticazione consiste in una serie di richieste del server e risposte del client che sono specifiche al meccanismo di autenticazione. Una richiesta server, altrimenti conosciuta come una risposta di pronto, e’ una linea consistente in un carattere “+” seguito da un singolo spazio e una stringa codificata in BASE64. La risposta del client consiste invece in una linea contenente una stringa codificata in BASE64. Se il client volesse cancellare uno scambio di autenticazione dovrebbe inoltrare una linea con un singolo “*”. Se il server riceve una tale risposta deve rifiutare il comando AUTH mediante l’invio di una risposta negativa. Un meccanismo di protezione fornisce integrita’ e privacy alla sessione di protocollo. Se viene negoziato un meccanismo di protezione esso viene applicato a tutti i dati successivi inviati sulla connessione. Il meccanismo di protezione ha effetto subito dopo la CRLF che conclude lo scambio di autentivazione per il client, e la CRLF della risposta positiva per il server. Una volta che il meccanismo di protezione ha effetto, il flusso degli ottetti dei comandi e delle risposte viene processato in buffers di testo cifrato. Ciascun buffer e’ trasferito sulla connessione come un flusso di ottetti preceduti da un campo di quattro ottetti nell’ordine di byte di rete che rappresentano la lunghezza dei dati che seguono. La lunghezza massima del buffer cifrato viene definita dal meccanismo di protezione. Al server non e’ richiesto di supportare alcun meccanismo di autenticazione particolare, cosi’ a nessun meccanismo di autenticazione e’ richiesto supportare alcun meccanismo di protezione. Se un comando AUTH fallisce con una risposta negativa, la sessione rimane nello stato di AUTORIZZAZIONE e il client puo’ provare un altro meccanismo di autenticazione inoltrando un altro comando AUTH, o tentare l’autenticazione mediante l’uso dei comandi USER/PASS oppure APOP. In altre parole, il client puo’ richiedere tipologie di autenticazione in ordine di preferenza decrescente, con i comandi USER/PASS o APOP come ultima risorsa. Se il client completa lo scambio di autenticazione con successo, il server POP3 inoltra una risposta positiva e la sessione POP3 entra nello stato di TRANSAZIONE. Risposte possibili: +OK maildrop locked and ready (maildrop bloccata e pronta) -ERR authentication exchange failed (scambio di autenticazione fallito) Myers [Page 2] RFC 1734 POP3 AUTH December 1994 Esempi: S: +OK POP3 server ready C: AUTH KERBEROS_V4 S: + AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: + or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: +OK Kerberos V4 authentication successful ... C: AUTH FOOBAR S: -ERR Unrecognized authentication type Nota: le linee di interruzione nella prima risposta del client sono per chiarezza editoriale e non presenti in autenticatori reali. Myers [Page 3] RFC 1734 POP3 AUTH December 1994 3. Sintassi formale La seguente specifica di sintassi utilizza la notazione Backus-Naur Form (BNF) come specificato nell’RFC 822. A meno che non sia diversamente specificato, tutti i caratteri alfabetici sono case-insensitive [N.d.T.: non vi e’ distinzione tra maiuscole e minuscole]. L’uso di caratteri maiuscoli o minuscoli per definire stringhe significative e’ solamente per chiarezza esplicativa. Le implementazioni DEVONO accettare tali stringhe in modalita’ case-insensitive. ATOM_CHAR ::= atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / <"> / "\" auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64) CRLF auth_type ::= 1*ATOM_CHAR base64 ::= *(4base64_CHAR) [base64_terminal] base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "+" / "/" ;; Case-sensitive base64_terminal ::= (2base64_char "==") / (3base64_char "=") CHAR ::= continue_req ::= "+" SPACE base64 CRLF CR ::= CRLF ::= CR LF CTL ::= Myers [Page 4] RFC 1734 POP3 AUTH December 1994 LF ::= SPACE ::= TAB ::= 4. Riferimento [IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, Carnegie Mellon, December 1994. 5. Considerazioni relative alla sicurezza Sono state discusse nel corso di questi appunti. 6. Indirizzi dell’autore John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 EMail: jgm+@cmu.edu Myers [Page 5]