Network Working Group M. St. Johns Request for Comments: 1413 US Department of Defense Obsoletes: 931 February 1993 Protocollo Ident Traduzione a cura di ComiSAT Brescia, Apr. 2004 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di Questa Memoria Questa RFC specifica una traccia standard di protocollo IAB per la comunita' Internet, e richiede discussioni e suggerimenti per migliorie. Per la posizione di standardizzazione e lo stato di questo protocollo si prega di far riferimento all'edizione attuale dello "IAB Official Protocol Standards". La distribuzione di questo documento non e' soggetta a limitazioni. 1. INTRODUZIONE L'Identification Protocol (Protocollo di Identificazione, noto anche come "Ident Protocol" o semplicemente "Ident") fornisce uno strumento per determinare l'identita' di un utente di una particolare connessione TCP. Data una coppia di numero di porte TCP, esso ritorna una stringa di caratteri che identifica l'utente di quella connessione sul sistema del server. Il Protocollo di Identificazione veniva chiamato in precedenza Authentication Server Protocol (Protocollo Server di Autenticazione). E' stato rinominato per meglio riflettere la sua funzione. Questo documento e' un prodotto del Gruppo di Lavoro del Protocollo d'Identita' Client TCP dell'IETF. 2. PANORAMICA Questa e' un'applicazione basata su connessione TCP. Un server ascolta per connessioni TCP sulla porta TCP 113 (decimale). Una volta che una connessione viene stabilita il server legge una linea di dati che specifica la connessione in oggetto. Se esiste, l'identificazione dell'utente della connessione in oggetto dipendente dal sistema viene inviata come risposta. Il server puo' quindi chiudere la connessione oppure continuare a leggere/rispondere ad altre richieste. Il server dovrebbe chiudere la connessione dopo che e' passato un tot di tempo configurabile senza richieste - viene raccomandato un idle timeout (tempo di attesa massimo) di 60-180 secondi. Il client puo' chiudere la connessione in qualsiasi momento; tuttavia per tenere conto dei ritardi di rete il client dovrebbe aspettare almeno 30 secondi (o piu') dopo una richiesta prima di abbandonarla e chiudere la connessione. St. Johns [Page 1] RFC 1413 Identification Protocol February 1993 3. RESTRIZIONI Le richieste sono consentite solamente per connessioni pienamente specificate. La richiesta contiene la coppia di porte locale/remoto - la coppia di indirizzi locale/remoto usata per specificare a pieno la connessione viene presa dagli indirizzi locale e remoto della richiesta di connessione. Questo implica che un utente sull'indirizzo A puo' eseguire richieste al server sull'indirizzo B solamente per le connessioni tra A e B. 4. FORMATO RICHIESTA/RISPOSTA Il server accetta semplici richieste di testo della forma: , dove e' la porta TCP (decimale) sull'altro capo (dove sta girando il server "ident"), e e' la porta TCP (decimale) sul sistema sorgente (client) N.B. - Se un client sull'host A vuole domandare ad un server sull'host B si una connessione specificata localmente (sulla macchina del client) come 23, 6191 (an inbound TELNET connection), il client deve in realta' domandare di 6191, 23 - ovvero il modo in cui la connessione sarebbe specificata sull'host B. Ad esempio: 6191, 23 La risposta a questo e' la seguente forma: , : : dove , sono la stessa coppia della richiesta, e' una parola chiave che identifica il tipo di risposta, e dipende dal contesto. Le informazioni ritornate sono quelle associate alla connessione TCP pienamente specificata identificata da , , , , dove e sono gli indirizzi IP remoto e locale della connessione oggetto di richiesta - ad es., la connessione TCP al Server col Protocollo di Identificazione. ( e sono prese dalla richiesta). Ad esempio: 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USER St. Johns [Page 2] RFC 1413 Identification Protocol February 1993 5. TIPI DI RISPOSTA Una risposta puo' essere di due tipi: USERID In questo caso, e' una stringa che consiste in un nome di sistema operativo (con l'dentificatore facoltativo del set di caratteri), seguito da ":" e da una stringa di identificazione. Il set di carattere (se presente) e' separato dal nome del sistema operativo da una ",". L'dentificatore del set di caratteri viene utilizzato per indicare il set di caratteri della stringa di identificazione. L'identificatore del set di caratteri, se omesso, e' "US-ASCII" di default (vedasi piu' avanti). I nomi di sistema operativo e di set di caratteri consentiti sono specificati nella RFC 1340, "Numeri Assegnati" o sue successive. In aggiunta a questi nomi di sistema operativo e di set di caratteri specificati nella "Numeri Assegnati" vi e' uno speciale caso di identificatore di sistema operativo - "ALTRO". A meno che "ALTRO" sia specificato come tipo di sistema operativo, ci si aspetta che il server ritorni la "normale" identificazione dell'utente di questa connessione. In questo contesto "normale" puo' essere usato per significare una stringa di caratteri che identificano in modo univoco l'utente della connessione come un'identificazione utente assegnata dall'amministratore e usata ad esempio come identificazione utente per la posta, o come parte "utente" di una combinazione utente/password usata per avere l'accesso alle risorse di sistema. Quando viene specificato un sistema operativo (qualsiasi cosa tranne "ALTRO"), ci si aspetta che l'id entificatore utente sia in una forma piu' o meno utile - ad esempio qualcosa che potrebbe essere usata come argomento di un "finger" o come indirizzo mail. "ALTRO" indica che l'identificatore e' una stringa di caratteri non formattata consistente in caratteri stampabili del set di caratteri specificato. "ALTRO" dovrebbe essere specificato se l'identificatore utente non incontri i vincoli del paragrafo precedente. L'invio di un segno di verifica cifrato, o il ritorno di altre informazioni non relative all'id- utente ma comunque relative all'utente (come il nome reale e il numero di telefono presi da un passwd file UNIX) sono entrambi esempi di casi in cui St. Johns [Page 3] RFC 1413 Identification Protocol February 1993 "ALTRO" dovrebbe essere utilizzato. Ci si aspetta che gli identificatori utenti ritornati siano stampabili nel set di caratteri indicato. L'identificatore e' un ottetto stringa non formattata - sono consentiti tutti gli ottetti ad eccezione dell'ottale 000 (NUL), 012 (LF) e 015 (CR). N.B. - i caratteri spazio (040) che seguono i due punti di separazione SONO parte della strnga di identificazione e non possono essere ignorati. Una stringa di risposta viene inoltre terminata normalmente con un CR/LF (N.d.T.: Control Return + Line Feed). N.B. Una stringa puo' essere stampabile, ma non lo deve essere *necessariamente*. ERRORE L'utente della porta puo' per qualche motivo non essere determinato, spiega il perche'. Quelli che seguono sono i valori consentiti di e relativo significato: INVALID-PORT (porta non valida) La porta locale o quella remota e' stata specificata impropriamente. Questo potrebbe essere ritornato se una o entrambe le porte sono fuori range (i numeri di porta TCP sono compresi tra 1 e 65535), interi negativi, reali o in qualche modo non riconosciuti come interi non- negativi. NO-USER (nessun utente) La connessione specificata dalla coppia di porte non e' attualmente in uso o non attualmente appartenente ad un'entita' identificabile. HIDDEN-USER (utente nascosto) Il server e' riuscito ad identificare l'utente di questa porta, ma le informazioni non sono ritornate. UNKNOWN-ERROR (errore sconosciuto) Impossibile determinare l'utente della connessione; motivo sconosciuto. In questo errore rientra tutto cio' che non e' stato considerato con gli errori precedenti. Facoltativamente, questo codice PUO' essere ritornato al posto di qualsiasi altro codice d'errore specifico se, per esempio, il server desidera nascondere informazioni implicite col ritorno di quel codice d'errore, o per qualsiasi altro St. Johns [Page 4] RFC 1413 Identification Protocol February 1993 motivo. Se un server implementa una tal caratteristica, DEVE essere configurabile e DEVE ritornare per default l'appropriato messaggio d'errore. Potranno essere eventualmente specificati e definiti altri valori in revisioni future a questo documento. Se un implementatore ha una necessita' di specificare un codice di errore non standard, tale codice deve iniziare con la "X". In aggiunta, al server e' permesso far decadere la richiesta senza dare una risposta. Ciascuna chiusura prematura (ad esempio quando il client non riceve l'EOL - N.d.T. End Of Line) dovrebbe essere considerata come avere lo stesso significato che "ERROR : UNKNOWN ERROR". SINTASSI FORMALE ::= ::= "," ::= ::= "015 012" ; CR-LF Indicatore End Of Line ::= | ::= ":" "ERROR" ":" ::= ":" "USERID" ":" ":" ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" | "HIDDEN-USER" | ::= [ "," ] ::= "OTHER" | "UNIX" | ...ecc. ; (Vedasi "Numeri Assegnati") ::= "US-ASCII" | ...ecc. ; (Vedasi "Numeri Assegnati") ::= ::= 1*64 ; 1-64 caratteri ::= "X"1*63 ; 2-64 caratteri inizianti con /X St. Johns [Page 5] RFC 1413 Identification Protocol February 1993 ::= 1*5 ; 1-5 cifre. ::= "0" | "1" ... "8" | "9" ; 0-9 ::= /?"'~`{}[]; > ; a-z maiuscoli e minuscoli piu' ; stampabili meno il carattere due punti ":" ::= 1*512 ::= Note di Sintassi: 1) Per promuovere l'interoperabilita' tra implementazioni diverse, riguardo allo spazio bianco, la seguente sintassi e' capita per comprendere la filosofia del "sii conservatore in cio' che invii e liberale in cio' che accetti". I clients e i server non dovrebbero generare spazi bianchi non necessari (caratteri spazio e tab) ma dovrebbero comunque accettarli ovunque siano a meno che siano in un token. Nelle risposte d'analisi i caratteri spazio possono presentarsi in ogni dove, tranne all'interno di un segno (token). Nello specifico, e' consentito un qualsiasi ammontare di spazio bianco all'inizio o alla fine di una linea sia per le richieste che per le risposte. Questo non si applica per risposte che contengono un ID utente in quanto tutto cio' che segue i due punti dopo il tipo di sistema operativo fino al CR/LF terminante e' considerato parte dell'ID utente. Il CR/LF terminante NON e' considerato parte dell'ID utente. 2) Nonostante quanto detto, i servers dovrebbero limitare l'ammontare di spazio bianco che inviano all'ammontare utile o ragionevole piu' piccolo. I client dovrebbero sentirsi liberi di chiudere una connessione se ricevono 1000 caratteri senza ricevere un . 3) Il limite di 512 caratteri sull'ID utente e quello di 64 caratteri sui token dovrebbe essere compreso per significare quanto segue: a) Nessun nuovo token (ad esempio OPSYS o ERROR-TYPE) e b) un server NON DOVREBBE inviare piu' di 512 ottetti di un ID utente e un client DEVE accettarne almeno 512. St. Johns [Page 6] RFC 1413 Identification Protocol February 1993 A causa di questa limitazione un server DEVE ritornare la porzione piu' significativa dell'ID utente nei primi 512 ottetti. 4) I set di caratteri e gli identificatori di set di carattere dovrebbero tracciare direttamente a quelli definiti o riferiti con l'RFC 1340, "Numeri Assegnati" o sue successive. Gli identificatori di set di caratteri si applicano solamente al campo di identificazione utente - tutti gli altri campi saranno definiti, e cosi' spediti, in US-ASCII. 5) Sebbene il viene sopra definito come un , esso deve seguire il formato e i vinvoli di set di caratteri impliciti del ; vedasi discussione precedente. 6) Il set di caratteri fornisce al client un contesto per stampare od archiviare le stringhe di identificazione utente ritornate. Se il client non riconosce o non implementa il set di carattere ritornato deve gestire la stringa d'identificazione ritornata come OTTETTO, ma dovrebbe in aggiunta archiviare o riportare il set di caratteri. Una stringa OTTETTO dovrebbe essere stampata, archiviata o gestita in notazione esadecimale (0-9a-f) in aggiunta a qualsiasi altra implementazione il client implementi - cio' costituisce una rappresentazione standard fra implementazioni differenti. 6. Considerazioni sulla Sicurezza Le informazioni ritornate da questo protocollo sono tanto affidabili quanto l'host che le fornisce O l'organizzazione che opera sull'host. Per esempio, un PC in un laboratorio comune ne ha poca se qualsiasi controllo su di esso per prevenire un utente dall'avere questo protocollo ritorna ogni identificazione che l'utente desidera. Inoltre, se un host e' stato compromesso le informazioni ritornate potrebbero essere completamente errate e fuorvianti. Il Protocollo di Identificazione non e' concepito per essere un protocollo di autorizzazione di controllo d'accesso. Nel migliore dei casi fornisce alcune informazioni di verifica supplementari rispetto alle connessioni TCP. Nel peggiore dei casi fornisce invece informazioni fuorvianti, non corrette o maliziosamente manomesse. L'uso delle informazioni ritornate da questo protocollo per motivi diversi dalla verifica e' fortemente sconsigliato. Nello specifico, l'uso delle informazioni del Protocollo di Identificazione per prendere decisioni sul controllo d'accesso - come metodo primario (ad es. nessuna verifica) o come aggiunta ad altri metodi - puo' comportare un indebolimento della normale sicurezza di un host. St. Johns [Page 7] RFC 1413 Identification Protocol February 1993 Un server di Identificazione puo' rivelare informazioni relative ad utenti, entita', oggetti o processi che potrebbero normalmente essere considerati privati. Un server di Identificazione fornisce un servizio che e' all'incirca analogo all'Identificazione del Chiamante fornita da alcune compagnie di telefono e molte delle medesime considerazioni e argomentazioni sulla privacy che si applicano al servizio telefonico si applicano anche a questo protocollo. Se non desideraste far girare un server "finger" per motivi di privacy potreste non voler far girare nemmeno questo protocollo. 7. RINGRAZIAMENTI I ringraziamenti vanno a Dan Bernstein, responsabile principale del rinnovamento d'interesse per questo protocollo e per aver portato alla luce alcuni errori nell'RFC 931. Riferimenti [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January 1985. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. Indirizzo dell'Autore Michael C. St. Johns DARPA/CSTO 3701 N. Fairfax Dr Arlington, VA 22203 Phone: (703) 696-2271 EMail: stjohns@DARPA.MIL St. Johns [Page 8]