In una grossa azienza le operazioni legate alla sicurezza sono impegnative. Infatti molte volte dipendenti e clienti hanno il bisogno di accedere alle informazioni e si collegano ai computer dell'azienda pressochè dovunque.

Occorre un considerevole sforzo amministrativo per gestire i collegamenti seriali diretti e i modem condivisi. Da non dimenticare che tutte queste fonti devono essere effettuate in accordo con le politiche di sicurezza aziendali, e qui però sergono delle domande precise: Come puo avvenire questo? Occorre un server di autenticazione per ognuno dei siti dell'azienda stessa? e, in questo caso chi gestisce questi server e come vengono coordinate le loro attività? Oppure l'organizzazione deve utilizzare un solo server centrale per ridurre il lavoro di coordinamento? Bene per venire incontro alle necessità delle organizzazioni di realizzare un sistema integrato per la gestione della sicurezza aziendale, Internet Network Working Group ha pubblicato la RFC 2138, Remote Authentification Dial-In Iser Service (RADIUS), la specifica spiega le procedure per la realizzazione di un server di autentificaficazione, contenente un database centrale per l'indentificazione degli account e per le informazioni necessarie all'autenticazione degli stessi. Una cosa molto importante del RADIUS è di permettere al sever di comunicare con altri server basati sullo stesso protocollo o no. In questo modo il server RADIUS funge da client proxy per gli altri server. La specifica definisce anche come supportare le operazioni specifiche di un utente, quali PPP, rlogin, TELNET eccetera.

Configurazione di RADIUS

[pagebreak]

Il formato del pacchetto RADIUS

La figura di cui sopra, illustra il formato del pacchettto RADIUS.

Il pacchetto è incapsulato in UDP ed è formato dai seguenti campo:

- Code = Identifica il tipo di pacchetto RADIUS come segue:

1 = Richiesta di accesso

2 = Consenso all'accesso

3 = Rifiuto dell'accesso

4 = Richiesta di account

5 = Risposta all'account

11 = Risposta al'accesso

12 = Stato del server

13 = Stato del client

255 = Riservato

- Identifier: verifica la corrispondenza fra richieste e risposte

- Lenght: indica la lunghezza del pacchetto compreso tutti i campi

- Autenticator: è usato per autenticare la risposta dal server RADIUS.

Nel pacchetto di richiesta di accesso il suo valore è un numero a caso di 16 ottetti, chiamato autenticatore di richiesta. Questo numero, insieme a un valore segreto, viene elaborato con l'algoritmo MD5 per creare un valore digest di 16 ottetti, che viene in seguito sottoposto a XOR con la password immessa dall'utente. Il risultato ottenuto è posizionato nell'attributo User-password all'interno del pacchetto di richiesta di accesso. Nei pacchetti ""concenso all'accesso"", ""rifiuto dell'accesso"", ""risposta all'accesso"" questo valore viene invece chiamato autenticatore della richiesta e corrisponde a una funzione con l'algoritmo MD5 calcolata sui seguenti campi del pacchetto richiesta di accesso: Code, Indentificator, lenght e Autenticator

Un esempio di scambi di messaggi RADIUS

La richiesta al server RADIUS da parte del client deve essere un segreto condiviso con il server, in caso contrario la richiesta viene scartata. Una volta superato il controllo iniziale, il server consulta un database che contiene informazioni necessarie per autenticare l'utente.

[pagebreak]

Se anche l'autenticazione è conforme a tutte le richieste, il server a quel punto invia una risposta all'utente sotto forma di messaggio di risposta all'accesso. Il client a sua volta può ritrasmettere la risposta all'utente sotto forma di un prompt e, in ogni caso deve inviare di nuovo il messaggio di richiesta di accesso, con alcuni campi differenti, il principale dei quale è una risposta crittografata alla risposta del server. In seguito all'utente viene presentato un numero a caso e gli viene chiesto di richiesto di crittografarlo e di ritrasmettere il risultato della crittografia. Il server riceve ed esamina questo messaggio e, se tutto quadra, invia un messaggio di accesso al client. Il protocollo RADIUS va comunque molto al di là delle operazioni di supporto all'autenticazione, in quanto il messaggio di accesso concesso contiene informazioni di configurazione, quali PPP, lo user login eccetera. Con il nodo RADIUS si vogliono fornire tutte le informazioni necessarie per supportare la sessione in rete, per esempio un indirizzo IP per la sessione, servizi di compressione, unità di trasmissione massima (MTU ) eccetera. Il client NAS può supportare i protocolli PAP e CHAP . In questo caso il client NAS invia ID e password PAP nel messaggio di richiesta di accesso (precisamente nei campi user-name e password del messaggio). Se si usa il protocollo CHAP, il client NAS genera una risposta e la invia all'utente. Secondo le regole del protocollo CHAP, l'utente risponde con IP CHAP e user name CHAP. A questo punto il clinet NAS trasmette al server RADIUS il messaggio di richiesta di accesso, contenente le due informazioni CHAP.

Quale protocollo usa il RADIUS?

Quali limiti ha il RADIUS?

Anche il RADIUS che sembra cosi perfetto e privi di difetti ha i suoi limiti e questi risiedono nella struttura dei comandi e dello spazio degli indirizzo degli attributi, con conseguente scarsa possibilità di introdurre nuovi servizi. RADIUS operando su UDP non ha meccanismi di timing o di ritrasmissione. Per questi motivi i produttori hanno implementato diverse versioni per queste procedure. RADIUS inoltre ritiene possibile che ci siano messaggi unsolicitied dal server al clinet, cosa ch riduce la sua flessibilità.

[pagebreak]

Per terminare ecco un elenco di prodotti di sicuro interesse:

Bibliografia:

[RFC2138] [1] Rigney, C., Rubens, A., Simpson, W, and Willens, S.; Remote Authentication Dial In User Service (RADIUS), RFC 2138, january 1997
[RFC2139] [2] Rigney, C.; RADIUS Accounting, RFC 2139, January 1997
[RFC1321] [3] R. Rivest; The MD5 Message-Digest Algorithm, RFC 1321, April 1992