Identity Provider

Un Identity Provider è un ente che partecipa alla federazione eduroam fornendo ai propri utenti le credenziali necessarie per poter accedere alla rete.

Possono aderire come Identity Provider gli enti che sono collegati alla rete GARR come indicato in Chi può aderire ad eduroam.

Requisiti

I requisiti per essere un Identity Provider sono:

  • Un RADIUS server correttamente configurato

  • Supporto a EAP

  • Un Certificati per il server RADIUS

  • Un sistema di gestione delle identità (es. LDAP, Active Directory, DB, ...)

EAP

Il protocollo EAP è un contenitore che trasporta i dati di autenticazione all'interno dei cosiddetti metodi EAP.

I metodi EAP maggiormente utilizzati in eduroam sono:

TLS:

L'autenticazione avviene mediate un certificato utente X.509

PEAP:

Protocollo Microsoft che stabilisce un tunnel cifrato TLS inviando username e password dopo averne effettuato l'hash MS-CHAPv2

TTLS:

Protocollo IETF che stabilisce un tunnel cifrato TLS inviando username e password secondo un formato stabilito dalla cosiddetta fase2

La scelta del metodo da utilizzare non è arbitraria ma dipende da come sono memorizzate le credenziali degli utenti nella base dati utente (Identity Management).

  • Se l'Identity Management supporta i certificati utente X.509, è possibile utilizzare TLS

  • Nel caso di credenziali username/password:

    • Se la password è memorizzata in chiaro oppure cifrata con hash NT-Hash (es. Active Directory), è possibile utilizzare PEAP e TTLS. In questo caso è preferibile l'uso di PEAP rispetto a TTLS.

    • Se la password è memorizzata in altri formati (es. md5, sha1, ...), allora è possibile utilizzare solo TTLS con fase2 PAP

Certificati

Il protocollo EAP richiede un certificato X.509 lato server con cui i client possano correttamente identificare il RADIUS server della propria Home Institution, instaurare un tunnel cifrato e, solo dopo, inviare le credenziali.

Un certificato per il server RADIUS può essere emesso sia da una Certificate Authority (CA) nota, sia da una CA privata. Da un punto di vista tecnico non fa molta differenza in quanto, attraverso l'utilizzo di CAT, i dispositivi degli utenti vengono automaticamente configurati con il certificato della CA che ha emesso il certificato del server RADIUS. Tuttavia bisogna considerare quanto segue:

  • una CA commerciale potrebbe avere una data di scadenza relativamente breve al verificarsi della quale tutti i dispositivi andrebbero riconfigurati. Una CA privata, invece, può essere creata con una data di scadenza molto lunga.

  • nella scelta tra una CA commerciale e una CA privata, è necessario verificare che siano rispettati i requisiti di seguito indicati.

  • alcuni dispositivi, in particolar modo Android, non effettuano la verifica del CN del certificato, ma solo che esso sia stato emesso dalla CA. Questo significa che chiunque abbia un certificato emesso dalla medesima CA può pretendere di essere il RADIUS server per l'utente in questione che, a questo punto, invierebbe le proprie credenziali lungo il canale cifrato. Una CA privata, sotto il proprio controllo, invece, riduce se non annulla tale rischio.

  • una CA privata consente di emettere il certificato senza CA intermedie il che significa meno frammentazione e autenticazioni più veloci.

Nota

Sulla base delle suddette considerazioni, ove possibile e dove ci sia expertise, è consigliabile creare una CA ad-hoc per il servizio eduroam.

I dispositivi che si collegano ad eduroam sono molto variegati su come validano i certificati server. Ecco il set minimo di raccomandazioni relative ai certificati in modo che essi siano quanto più compatibili con i vari sistemi.

  • Il certificato della CA che ha emesso il certificato server deve essere un certificato X.509v3

  • Un CN che contiene spazi (es. Radius of University...) può creare problemi con alcuni dispositivi (es. Apple iOS 6.x). Il nome del certificato (CN) deve essere un Full Qualified Domain Name.

  • Il CN non deve essere un wildcard (es. *.realm.it). Dispositivi com Windows 8 e 8.1 hanno mostrato problemi.

  • Alcuni dispositivi consultano solo il CN, altri solo il SubjectAltName:DNS. E' quindi buona norma che vi siano entrambi e che abbiano lo stesso valore.

  • I certificati a firma MD5 sono considerati insicuri da tutti i moderni sistemi. Il certificato deve essere firmato con un algoritmo che sia almeno SHA-1. E' raccomandato SHA-256 o superiore in quanto SHA-1 risulta ormai deprecato da alcuni browser. Al momento il fatto di essere deprecati dai browser non ha impatti sull'uso EAP.

  • I certificati con chiave pubblica inferiore a 1024 bit sono considerati insicuri dai moderni sistemi operativi. La chiave pubblica deve avere una lunghezza di almeno 2048 bit

  • Il certificato deve avere le seguenti estensioni:

    • Anche se il certificato è utilizzato per EAP, alcuni sistemi come Windows XP e successivi richiedono l'estensione TLS Web Server Authentication (OID: 1.3.6.1.5.5.7.3.1

    • Pochi recenti sistemi operativi (es. Windows Phone 8) richiedono che sia presente l'estensione CRL Distribution Point e che punti ad una URL con un CRL valido. Alcuni sistemi richiedono solo la presenza di questo campo ma non effettuano verifiche sulla URL.

    • I certificati non devono essere certificati CA. Pertanto è necessario che l'estensione Basic Contraint abbia il valore CA:FALSE. Questa estensione deve essere critical.

  • ChromeOS sembra rifiutare i certificati di tipo EV (Extended Validation). Se è in uso questo sistema, i certificati devono essere di tipo Domain-Validated (DV) o Organisation-Validated (OV).

Nota

A differenza dei siti web, il certificato non deve necessariamente avere il CN pari all'hostname. E' sufficiente che sia un FQDN il cui valore non è necessario che sia registrato nel DNS.

Attenzione

Se un Identity Provider utilizza più server per resilienza del servizio, allora tutti i certificati dei RADIUS server devono avere lo stesso CN. In alternativa è possibile, per semplicità, utilizzare lo stesso certificato su tutti i server.

I dispositivi hanno necessità di validare il certificato server. A tal fine è necessario che il certificato della Root CA che ha emesso il certificato server sia presente sul dispositivo.

Nella sessione di autenticazione, quindi, non ha alcun valore aggiunto il fatto che il server radius invii al client l'intera catena di certificati compreso il certificato della Root CA. Anzi, questo comporta solo uno scambio maggiore di informazione, maggiore frammentazione e tempi di autenticazione più lunghi.

Ove il certificato server sia emesso da una CA intermedia, può essere utile che il server radius invii il proprio certificato e quello della CA intermedia che lo ha rimato in modo tale che è sufficiente che sul dispositivo dell'utente finale sia presente solo la Root CA.

Il server radius deve inviare sempre e solo il proprio certificato ed eventuali certificati di CA intermedie. L'unica deroga a questa regola è se sono in uso presso la propria organizzazione dei dispositivi Blackberry che vogliono che il server invii il certificato della Root CA.

Realms

Un ente che aderisce ad eduroam come Identity Provider può richiedere la registrazione dei domini di cui è autoritativo.

Il GARR ha la delega internazionale dei realm che terminano con .it. Tuttavia, per venire incontro alla crescente richiesta di adesione con domini che non terminano con .it, GARR ha implementato il meccanismo di Discovery Dinamico che consente agli Identity Provider di registrare anche domini .eu, .com, .org, etc.

Obblighi

Come stabilito dal Regolamento Italiano della Federazione eduroam un Identity Provider deve:

  • mettere in atto una procedura di assegnazione credenziali che preveda l’accertamento dell'identità personale dell’utente a cui vengono assegnate

  • essere in grado, su richiesta del GARR o delle pubbliche autorità, di fornire in tempi rapidi l’identità dell’utente a cui corrispondono le credenziali indicate

  • rendere pubblica la propria procedura di identificazione e assegnazione delle credenziali

  • nominare almeno una persona responsabile del servizio, comunicandone al GARR il nominativo, l'indirizzo email e il numero di telefono. Eventuali variazioni di contatti tecnici e delle relative informazioni devono essere comunicate al GARR

  • collaborare con il GARR nel caso di abusi, incidenti di sicurezza o altri problemi che derivino dal servizio eduroam stesso, in accordo con l'AUP della rete GARR, nonché con le politiche di sicurezza della rete GARR e la legislazione in vigore

  • utilizzare identità EAP esterne della forma <name>@realm, dove realm è un dominio DNS gestito dall'Organizazione e <name> è una stringa arbitraria

  • utilizzare almeno un server di autenticazione, che:
    • rispetti le specifiche di RFC2685 (RADIUS) e RFC2866 (RADIUS Accounting)

    • risponda alle eventuali ICMP Echo Request inviati dai processi di monitor installati dal GARR

    • risponda alle richieste da parte dei server del GARR sulle porte 1812/udp, 1813/udp o, in alternativa, 1645/udp, 1646/udp

    • accetti almeno un tipo di autenticazione EAP

    • sia sincronizzato con una sorgente temporale o generatore di tempo affidabile (NTP)

  • creare, su richiesta del GARR, un "test account eduroam" (credenziali di accesso al servizio) messo a disposizione del GARR per finalità di test e debugging del servizio

  • conservare, per un periodo minimo di sei mesi o maggiore se prescritto dalla legislazione vigente, le informazioni relative agli accessi ed in particolare:
    • data e ora di ogni operazione

    • il Calling-Station-Id nelle richieste di autenticazione

    • le identità interna (inner-identity) ed esterna(outer-identity) della richiesta

    • il valore del Chargeable-User-Identity se l'IdP l'ha generato

    • il risultato dell’autenticazione restituito dall’authentication server

    • i valori di Accounting Session Id e Accounting status type per le richieste di Accounting

  • agire come supporto tecnico e di servizio per i propri utenti: infatti solamente i responsabili locali possono scalare le problematiche di supporto tecnico, di servizio o di sicurezza a nome dei propri utenti presso il GARR o presso le altre Organizzazioni

E' inoltre raccomandato:

  • installare un server RADIUS secondario

  • predisporre una pagina web che contenga la propria AUP e le informazioni necessarie per la connessione.