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 nelle versioni fino alla 7, non consentono di configurare via UI 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, indipendentemente dal nome del server radius, 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, che emette solo uno o pochi certificati 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. Tale CA può avere una durata abbastanza lunga per prevenire il rollover frequente della CA su tutti i dispositivi e dovrebbe essere limitata all'emissione dei certificati per l'Identity Provider.

I dispositivi che si collegano ad eduroam sono molto variegati ed impongono diversi requisiti sul contenuto dei certificati. Fortunatamente tali requisiti non sono mutualmente esclusivi.

L'elemento più importante del certificato è il nome del server. Poiché non si tratta di un server web, non è necessario che il certificato si emesso esattamente con il nome del server in uso. Tuttavia alcuni dispositivi richiedono che sia un hostname sintatticamente valido; quindi è una buona idea che sia un fully-qualified domain name, senza necessità che esista il corrispondente record nel DNS. Si noti che, per le suddette premesse, ove vi sia necessità di resilienza, è possibile utilizzare lo stesso certificato su più server. Ciò evita, ove i client effettuino la verifica del nome del certificato, configurare più nomi server. Il nome del server dovrebbe essere sia nel campo Common Name che nel subjectAltName:DNS.

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.

• Alcuni dispositivi consultano solo il CN, altri solo il SubjectAltName:DNS, altri entrambi. E' quindi buona norma che vi siano entrambi e che siano sincronizzati. Fare attenzione alle maiuscole e minuscole: nel caso in cui il campo CN e il campo subjectAltName differiscano per maiuscole e/o minuscole, alcuni dispositivi potrebbero non validare correttamente il certificato.

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

• I certificati con firma MD5 sono considerati insicuri da tutti i moderni sistemi e SHA-1 è stato deprecato. Il certificato deve essere firmato con un algoritmo che sia almeno SHA-256 o superiore.

• 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 sebbene sia già consigliato l'uso di chiavi a 3072 bits o superiore.

• 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.

• Il certificato dovrebbe avere una validità massima di 825 giorni o anche meno.

• 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 possono avere lo stesso CN utilizzando, di fatto, 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.

Sectigo / "AAA Certificate Services"

Questa CA ha firmato, nel 2020, un certificato CA intermedio come proprio certificato radice. Ciò porta a un nuovo percorso della catena CA più breve che si ferma alla variante di USERTrust RSA Certificate Authority. Il vecchio percorso della catena della CA con una CA con lo stesso nome come variante intermedia e un certificato CA radice denominato AAA Certificate Services continua ad essere offerto da Sectigo solo per compatibilità con sistemi legacy molto vecchi che non sono a conoscenza della variante radice di USERTrust.

NON È CONSIGLIATO scaricare e utilizzare la catena più lunga poiché Windows 10 ha problemi noti nella creazione di un percorso attendibile quando la CA USERTrust è già installata come variante radice (cosa che diventa sempre più comune oggigiorno).

Gli Identity Provider che utilizzano certificati di questa CA non devono includere la variante CA intermedia di USERTrust RSA Certificate Authority nel loro strumento di onboarding e nelle configurazioni del server EAP. Tutti i supplicant contemporanei includono questa CA come CA radice e possono creare una catena di fiducia con essa.

In sintesi:

• Il server RADIUS/EAP deve inviare il certificato del server e gli intermedi sotto USERTrust RSA Certification Authority. Si tratta in genere di un solo certificato intermedio con i nomi GEANT OV RSA CA 4 o Sectigo RSA Organization Validation Secure Server CA

• Quando si utilizza eduroam CAT come strumento di onboarding, includere solo la variante radice di USERTrust RSA Certificate Authority

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.

Federazione

Resource Provider