TRIP
(The Roaming INFN Physicist)


Introduzione

Il problema

Il numero dei dipendenti (o associati) INFN che ogni giorno si trovano a dover lavorare in una sede diversa dalla propria (e non sempre la stessa) è in continua crescita. I problemi che devono essere affrontati e risolti possono essere classificati in queste due categorie (in ordine di difficoltà crescente):

Questo richiede opportune configurazioni, non solamente dei server remoti, ma anche di quelli della rete locale cui il dipendente si sta collegando: ad esempio è necessario che il system manager locale abiliti il server dhcp a rilasciare un indirizzo ip al portatile del viaggiatore.

Il supplemento di autenticazione e autorizzazione necessario si traduce in un aggravio di lavoro per il system manager ("Ehi, stanno per arrivare 150 partecipanti ad un workshop, che hanno bisogno di un accesso wireless") e inconvenienti per il viaggiatore ("Accidenti, nessuno mi aveva detto che avrei dovuto comunicare una settimana prima il mac address della mia scheda!").

Una volta risolto il problema della concessione al visitatore dei permessi necessari per accedere alle risorse della sua Struttura di appartenenza (in pratica l'assegnazione di un indirizzo IP), si presenta quello ben più difficoltoso dell'accesso ai servizi della Struttura ospitante. In questo caso è necessario che le informazioni di autorizzazione vengano trasmesse dalla Struttura di appartenenza a quella ospitante, non essendo pensabile la loro duplicazione. In altri termini è necessaria la realizzazione di un meccanismo di Authentication and Authorization Infrastructure (AAI), che può essere schematizzato nei punti seguenti:

  1. autenticazione dell'utente a cura della Struttura ospitante;
  2. richieste dell'utente;
  3. trasmissione delle richieste alla Struttura di appartenenza per verificarne la legittimità;
  4. trasmissione dell'autorizzazione dalla Struttura di appartenenza a quella ospitante.

Il progetto

Quello che ci proponiamo di realizzare è un'architettura hw e software che permetta la facile autenticazione e autorizzazione del viaggiatore, senza che questo debba preventivamente comunicare la sua presenza al system manager locale. Ad autorizzazione avvenuta il viaggiatore sarà in grado di accedere ai servizi della rete che il responsabile locale avrà autorizzato: tipicamente ottenere un indirizzo IP per raggiungere la propria sede remota, ed avere accesso ai servizi essenziali forniti dalla sede locale (Printing, relay SMTP, file sharing, ecc. ecc.).

Un beneficio aggiuntivo sarà un miglioramento della sicurezza della rete, wireless in particolare, visto che l'accesso sarà basato su controlli più sicuri di quelli sulla semplice esistenza di un mac address in un database di autorizzazione.

I meccanismi che intendiamo prendere in considerazione, anche alla luce delle esperienze altrui, sono i seguenti:

In tutti i casi il server di autorizzazione sarà un server Radius, che è attualmente lo standard di fatto nel settore.

802.1x

Supporta numerosi metodi di autenticazione, in particolare via certificato X.509.

Il sistema può essere rappresentato così:

Il complesso delle comunicazioni fra supplicante, access point e server di autenticazione è schematizzato nella figura seguente:

Il "dialogo" fra i sistemi può essere osservato anche nel log del server RADIUS: log file.

Note di Riccardo Veraldi sull'uso wired.

Note di Ombretta Pinazza sull'uso wireless da client Windows.

Web Portal

Consente l'autenticazione con username/password e con certificato X.509 (tramite Apache SSL).

L'utente, prima di poter accedere alla rete, si deve autenticare tramite una pagina web.

In particolare, il client, dopo che si è collegato all'Access Point, ottiene un indirizzo IP dal DHCP server della VLAN ospiti. Questo indirizzo è bloccato da un Gateway, che intercetta il traffico HTTP e lo dirotta verso il server di autenticazione (RADIUS). Ad autenticazione effettuata, il Gateway permette il passaggio del traffico.


(immagine tratta dai deliverable della TERENA Mobility Task Force)

Una soluzione, basata su FreeRadius e il portale NoCat, è in uso presso la Sezione di Genova, dove sono disponibili anche istruzioni di Mirko Corosu per l'installazione.

Un'altra soluzione, basata su FreeRadius e il portale tino, è in via d'installazione presso la Sezione di Firenze. Al momento sono disponibili brevi istruzioni di Riccardo Veraldi per l'installazione (per veri esperti, siete stati avvertiti...)

VPN

L'uso delle VPN non è stato approfondito per mancanza di risorse (umane).

Server RADIUS

Abbiamo preso in considerazione solo l'implementazione Open Source (FreeRADIUS), che comunque non sembra in nulla inferiore alle altre implementazioni commerciali. come proxy.

Proxying

Il server RADIUS può essere utilizzato anche in modalità proxy, in modo da consentire all'utente remoto di autenticarsi con il server del proprio istituto.


(immagine tratta dai deliverable della TERENA Mobility Task Force)

 

Note di Ombretta Pinazza sulla configurazione di una gerarchia di server RADIUS

Sicurezza

L'autenticazione via username/password ha il grosso difetto che quest'ultima è disponibile, in chiaro, al gestore del server RADIUS con cui ci si sta autenticando, o che si sta utilizzando

Conclusioni

Allo stato attuale la migliore soluzione sembra quella di utilizzare sia l'802.1x sia un Web Portal. Alcuni Access Point sono in grado di gestire entrambi i metodi contemporaneamente (su SSID diversi).

Riccardo Veraldi, il responsabile della realizzazione del progetto, ha preparato una Guida all'implementazione (aggiornata il 8/5/06).

Appendice

Istruzioni di Franco Brasolin su come installare IOS su alcuni modelli di Access Point Cisco.

Bibliografia

Introduzione al problema e alle possibili soluzioni.

TERENA Mobility Task Force.

Presentazioni al II INFN Security Workshop, Parma, 24-25 Febbraio 2004

Presentazioni al III INFN Workshop, Cagliari, 25-27 Maggio 2004

Implementazione di TRIP

EAP e wireless, documenti vari

EAP/TLS

EAP / MD5

RADIUS

802.1x

Microsoft e le tecnologie wireless

Web Portal