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 certificato 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 mediante un certificato utente X.509

PEAP:

Stabilisce un tunnel cifrato TLS all'interno del quale username e password vengono trasmessi tramite MS-CHAPv2. Rispetto a TTLS-PAP, PEAP offre una protezione aggiuntiva della password all'interno del tunnel sicuro, in quanto la password non viene mai inviata in chiaro nemmeno dentro il tunnel.

TTLS:

Protocollo IETF che stabilisce un tunnel cifrato TLS inviando username e password secondo un formato stabilito dalla cosiddetta fase2. Le varianti più comuni sono:

• TTLS-PAP: la password viene inviata in chiaro all'interno del tunnel cifrato. È l'unica opzione quando le password sono memorizzate con hash diversi da NT-Hash.
• TTLS-GTC (Generic Token Card): variante utile per alcuni vecchi dispositivi (es. certe versioni di Symbian OS) che supportano TTLS ma non PAP.

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

Supporto multiplo

Il protocollo EAP è sufficientemente flessibile da consentire la configurazione di più metodi EAP contemporaneamente sullo stesso server RADIUS. In tal caso, è necessario selezionare un metodo "predefinito" che dovrebbe essere quello con il supporto più ampio tra i dispositivi della propria base utenti.

Identità esterne anonime

Quasi tutti i metodi EAP supportano l'uso di identità esterne anonime (anonymous outer identities), una best practice importante per la privacy degli utenti.

Il concetto si basa su due livelli di identità:

• Outer identity (identità esterna): utilizzata per il routing della richiesta di autenticazione attraverso l'infrastruttura RADIUS di eduroam fino all'Identity Provider. La parte username può essere offuscata (es. anonymous, anon, o lasciata vuota), mentre la parte realm (dopo la @) deve essere sempre corretta in quanto contiene le informazioni di routing.

• Inner identity (identità interna): la vera identità dell'utente, rivelata solo all'interno del tunnel cifrato all'Identity Provider. Non deve necessariamente contenere il carattere @.

Esempio

• Outer identity: anonymous@esempio.it
• Inner identity: mario.rossi

Per il routing eduroam viene utilizzata la parte @esempio.it dell'outer identity per instradare la richiesta e stabilire il tunnel sicuro. L'identità reale mario.rossi viene trasmessa solo dentro il tunnel cifrato.

Nota

L'uso delle identità esterne anonime è un'opzione di configurazione lato client. L'Identity Provider non può forzarne l'utilizzo, ma può incoraggiarlo attraverso l'uso di installer preconfigurati (es. tramite eduroam CAT).

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.

Note

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

• È raccomandato l'uso di certificati ECC (ECDSA) rispetto a RSA. I certificati ECC hanno dimensioni significativamente inferiori a parità di sicurezza, riducendo così la frammentazione dei pacchetti RADIUS/UDP e velocizzando l'autenticazione EAP. Alcuni firewall e servizi cloud (es. Microsoft Azure) possono scartare frammenti UDP non ricevuti nell'ordine corretto, causando problemi con certificati RSA di grandi dimensioni. I certificati ECC sono supportati dalla maggior parte dei dispositivi moderni (Android 8+, Windows 8+, iOS 9+).

• 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 Constraints abbia il valore CA:FALSE. Questa estensione deve essere critical. Nota: la Certificate Authority integrata in Windows ha un bug per cui, se si marca l'estensione BasicConstraints come critical, aggiunge automaticamente pathlen=0, non conforme a RFC. Se si utilizza una Windows Certificate Authority, non marcare l'estensione come critical nella richiesta di certificato.

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

Riduzione della validità dei certificati commerciali

A partire dal 2025, tutte le CA pubbliche si sono impegnate a seguire la raccomandazione del CA/B Forum per ridurre progressivamente la validità dei certificati server fino a 47 giorni nei prossimi anni. Se non si adotta un meccanismo di rinnovo automatico dei certificati tramite SCEP, ACME o CertBot, questo comporterà crescenti problemi amministrativi e tecnici. Si consiglia di valutare l'adozione di uno di questi strumenti e di considerare il supporto al rinnovo automatico come criterio importante nella scelta di una CA commerciale.

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

Note

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

Certificati HARICA

Il server RADIUS/EAP deve inviare il certificato server, il certificato intermedio HARICA GEANT TLS e il Cross Certificate from HARICA Root CA 2015 to 2021 come secondo certificato intermedio

• Certificati ECC:
  • GEANT.pem
  • Cross-Certificate-from-HARICA-Root-CA-2015-to-2021.pem
• Certificati RSA:
  • GEANT.pem
  • Cross-Certificate-from-HARICA-Root-CA-2015-to-2021.pem

Quando si usa eduroam CAT come strumento di onboarding, caricare la HARICA Root CA 2015 su CAT:

• ECC: Root-CA-2015.pem
• RSA: Root-CA-2015.pem

Se si desidera avere una chain più corta e non si riscontrano problemi con i client Windows, è sufficiente caricare la HARICA Root CA 2021 su CAT:

• ECC: Root-CA.pem
• RSA: Root-CA.pem

A seguito del passaggio dalla CA Sectigo a HARICA, si suggerisce di seguire la procedura di rollover per garantire la continuità del servizio.

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 @realm, dove realm è un dominio DNS gestito dall'Organizzazione e è una stringa arbitraria

• utilizzare almeno un server di autenticazione, che:

  • rispetti le specifiche di RFC2865 (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.