7. Considerazioni sulla Sicurezza

Questa sezione definisce un modello di minaccia generico e le rivendicazioni di sicurezza del metodo EAP che mitigano queste minacce.

Si prevede che il modello di minaccia generico e le corrispondenti rivendicazioni di sicurezza vengano utilizzati per definire i requisiti del metodo EAP per l'uso in ambienti specifici. Un esempio di tale analisi dei requisiti è fornito in [IEEE-802.11i-req]. Una sezione sulle rivendicazioni di sicurezza è richiesta nelle specifiche del metodo EAP, in modo che i metodi EAP possano essere valutati rispetto ai requisiti.

7.1. Modello di Minaccia (Threat Model)

EAP è stato originariamente sviluppato per l'uso con PPP [RFC1661] ed è stato successivamente adattato per l'uso nelle reti IEEE 802 cablate [IEEE-802] in [IEEE-802.1X]. Successivamente, EAP è stato proposto per l'uso su reti LAN wireless e su Internet. In tutte queste situazioni, è possibile per un attaccante ottenere l'accesso ai collegamenti su cui vengono trasmessi i pacchetti EAP. Ad esempio, gli attacchi all'infrastruttura telefonica sono documentati in [DECEPTION].

Un attaccante con accesso al collegamento può condurre diversi attacchi, tra cui:

[1] Un attaccante può tentare di scoprire le identità degli utenti intercettando il traffico di autenticazione.

[2] Un attaccante può tentare di modificare o falsificare pacchetti EAP.

[3] Un attaccante può lanciare attacchi denial-of-service falsificando indicazioni di livello inferiore o pacchetti Success/Failure, riproducendo pacchetti EAP o generando pacchetti con identificatori sovrapposti.

[4] Un attaccante può tentare di recuperare la passphrase montando un attacco dizionario offline.

[5] Un attaccante può tentare di convincere il peer a connettersi a una rete non affidabile montando un attacco man-in-the-middle.

[6] Un attaccante può tentare di interrompere la negoziazione EAP per causare la selezione di un metodo di autenticazione debole.

[7] Un attaccante può tentare di recuperare chiavi sfruttando tecniche di derivazione delle chiavi deboli utilizzate nei metodi EAP.

[8] Un attaccante può tentare di sfruttare suite di cifratura deboli utilizzate successivamente al completamento della conversazione EAP.

[9] Un attaccante può tentare di eseguire attacchi di downgrade sulla negoziazione della suite di cifratura di livello inferiore per garantire che una suite di cifratura più debole venga utilizzata successivamente all'autenticazione EAP.

[10] Un attaccante che agisce come autenticatore può fornire informazioni errate al peer EAP e/o al server tramite meccanismi out-of-band (come tramite un protocollo AAA o di livello inferiore). Ciò include fingere di essere un altro autenticatore o fornire informazioni incoerenti al peer e al server EAP.

A seconda del livello inferiore, questi attacchi possono essere effettuati senza richiedere prossimità fisica. Quando EAP viene utilizzato su reti wireless, i pacchetti EAP possono essere inoltrati dagli autenticatori (ad esempio, pre-autenticazione) in modo che l'attaccante non abbia bisogno di trovarsi nell'area di copertura di un autenticatore per effettuare un attacco contro di esso o i suoi peer. Quando EAP viene utilizzato su Internet, gli attacchi possono essere effettuati a distanza ancora maggiore.

7.2. Rivendicazioni di Sicurezza (Security Claims)

Per articolare chiaramente la sicurezza fornita da un metodo EAP, le specifiche del metodo EAP DEVONO includere una sezione Rivendicazioni di Sicurezza, comprese le seguenti dichiarazioni:

[a] Meccanismo. Questa è una dichiarazione della tecnologia di autenticazione: certificati, chiavi pre-condivise, password, token card, ecc.

[b] Rivendicazioni di sicurezza. Questa è una dichiarazione delle proprietà di sicurezza rivendicate dal metodo, utilizzando i termini definiti nella Sezione 7.2.1: autenticazione reciproca, protezione dell'integrità, protezione dalla riproduzione, riservatezza, derivazione delle chiavi, resistenza agli attacchi dizionario, riconnessione rapida, binding crittografico. La sezione Rivendicazioni di Sicurezza di una specifica del metodo EAP DOVREBBE fornire una giustificazione per le rivendicazioni fatte. Questo può essere realizzato includendo una prova in un'Appendice o includendo un riferimento a una prova.

[c] Forza della chiave. Se il metodo deriva chiavi, la forza effettiva della chiave DEVE essere stimata. Questa stima è destinata agli utenti potenziali del metodo per determinare se le chiavi prodotte sono sufficientemente forti per l'applicazione prevista.

La forza effettiva della chiave DOVREBBE essere indicata come numero di bit, definito come segue: Se la forza effettiva della chiave è di N bit, i migliori metodi attualmente noti per recuperare la chiave (con probabilità non trascurabile) richiedono, in media, uno sforzo paragonabile a 2^(N-1) operazioni di un cifrario a blocchi tipico. La dichiarazione DOVREBBE essere accompagnata da una breve giustificazione che spiega come è stato derivato questo numero. Questa spiegazione DOVREBBE includere i parametri necessari per raggiungere la forza della chiave indicata in base alla conoscenza attuale degli algoritmi.

(Nota: Sebbene sia difficile definire esattamente cosa significhino "sforzo paragonabile" e "cifrario a blocchi tipico", approssimazioni ragionevoli sono sufficienti qui. Consultare ad esempio [SILVERMAN] per ulteriori discussioni.)

La forza della chiave dipende dai metodi utilizzati per derivare le chiavi. Ad esempio, se le chiavi sono derivate da un segreto condiviso (come una password o un segreto a lungo termine), e possibilmente da informazioni pubbliche come i nonce, la forza effettiva della chiave è limitata dalla forza del segreto a lungo termine (assumendo che la procedura di derivazione sia computazionalmente semplice). Per fare un altro esempio, quando si utilizzano algoritmi a chiave pubblica, la forza della chiave simmetrica dipende dalla forza delle chiavi pubbliche utilizzate.

[d] Descrizione della gerarchia delle chiavi. I metodi EAP che derivano chiavi DEVONO fornire un riferimento a una specifica della gerarchia delle chiavi o descrivere come dovrebbero essere derivate le Master Session Key (MSK) e le Extended Master Session Key (EMSK).

[e] Indicazione delle vulnerabilità. Oltre alle rivendicazioni di sicurezza fatte, la specifica DEVE indicare quali delle rivendicazioni di sicurezza dettagliate nella Sezione 7.2.1 NON vengono fatte.

7.2.1. Terminologia delle Rivendicazioni di Sicurezza per i Metodi EAP

Questi termini sono utilizzati per descrivere le proprietà di sicurezza dei metodi EAP:

Negoziazione protetta della suite di cifratura (Protected ciphersuite negotiation)

Questo si riferisce alla capacità di un metodo EAP di negoziare la suite di cifratura utilizzata per proteggere la conversazione EAP, nonché la protezione dell'integrità della negoziazione. Questo non si riferisce alla capacità di negoziare la suite di cifratura utilizzata per proteggere i dati.

Autenticazione reciproca (Mutual authentication)

Questo si riferisce a un metodo EAP in cui, in uno scambio interblocato, l'autenticatore autentica il peer e il peer autentica l'autenticatore. Due metodi unidirezionali indipendenti, eseguiti in direzioni opposte, non forniscono autenticazione reciproca come qui definita.

Protezione dell'integrità (Integrity protection)

Questo si riferisce alla fornitura di autenticazione dell'origine dei dati e protezione contro modifiche non autorizzate delle informazioni per i pacchetti EAP (inclusi Request e Response EAP). Quando si fa questa rivendicazione, una specifica del metodo DEVE descrivere i pacchetti EAP e i campi nel pacchetto EAP che sono protetti.

Protezione dalla riproduzione (Replay protection)

Questo si riferisce alla protezione contro la riproduzione di un metodo EAP o dei suoi messaggi, incluse le indicazioni di risultato di successo e fallimento.

Riservatezza (Confidentiality)

Questo si riferisce alla cifratura dei messaggi EAP, inclusi Request e Response EAP, e indicazioni di risultato di successo e fallimento. Un metodo che fa questa rivendicazione DEVE supportare la protezione dell'identità (vedere Sezione 7.3).

Derivazione delle chiavi (Key derivation)

Questo si riferisce alla capacità del metodo EAP di derivare materiale di chiave esportabile, come la Master Session Key (MSK) e l'Extended Master Session Key (EMSK). La MSK viene utilizzata solo per un'ulteriore derivazione delle chiavi, non direttamente per la protezione della conversazione EAP o dei dati successivi. L'uso dell'EMSK è riservato.

Forza della chiave (Key strength)

Se la forza effettiva della chiave è di N bit, i migliori metodi attualmente noti per recuperare la chiave (con probabilità non trascurabile) richiedono, in media, uno sforzo paragonabile a 2^(N-1) operazioni di un cifrario a blocchi tipico.

Resistenza agli attacchi dizionario (Dictionary attack resistance)

Quando viene utilizzata l'autenticazione tramite password, le password sono comunemente selezionate da un insieme piccolo (rispetto a un insieme di chiavi a N bit), il che solleva preoccupazioni riguardo agli attacchi dizionario. Si può dire che un metodo fornisce protezione contro gli attacchi dizionario se, quando utilizza una password come segreto, il metodo non consente un attacco offline che ha un fattore di lavoro basato sul numero di password nel dizionario di un attaccante.

Riconnessione rapida (Fast reconnect)

La capacità, nel caso in cui un'associazione di sicurezza sia stata precedentemente stabilita, di creare una nuova associazione di sicurezza o rinnovata in modo più efficiente o in un numero ridotto di round-trip.

Binding crittografico (Cryptographic binding)

La dimostrazione da parte del peer EAP al server EAP che una singola entità ha agito come peer EAP per tutti i metodi eseguiti all'interno di un metodo tunnel. Il binding PUÒ coinvolgere anche il server EAP che dimostra al peer che una singola entità ha agito come server EAP per tutti i metodi eseguiti all'interno di un metodo tunnel. Se eseguito correttamente, il binding serve a mitigare le vulnerabilità man-in-the-middle.

Indipendenza di sessione (Session independence)

La dimostrazione che gli attacchi passivi (come la cattura della conversazione EAP) o gli attacchi attivi (inclusa la compromissione della MSK o EMSK) non consentono la compromissione di MSK o EMSK successive o precedenti.

Frammentazione (Fragmentation)

Questo si riferisce al fatto che un metodo EAP supporti la frammentazione e il riassemblaggio. Come indicato nella Sezione 3.1, i metodi EAP DOVREBBERO supportare la frammentazione e il riassemblaggio se i pacchetti EAP possono superare l'MTU minimo di 1020 ottetti.

Binding del canale (Channel binding)

La comunicazione all'interno di un metodo EAP di proprietà del canale protette dall'integrità, come identificatori di endpoint, che possono essere confrontate con i valori comunicati tramite meccanismi out-of-band (come tramite un protocollo AAA o di livello inferiore).

Nota: Questo elenco di rivendicazioni di sicurezza non è esaustivo. Proprietà aggiuntive, come la protezione aggiuntiva contro il denial-of-service, possono anche essere rilevanti.

7.3. Protezione dell'Identità (Identity Protection)

Uno scambio di identità è opzionale all'interno della conversazione EAP. Pertanto, è possibile omettere completamente lo scambio di identità o utilizzare uno scambio di identità specifico del metodo una volta stabilito un canale protetto.

Tuttavia, quando è supportato il roaming come descritto in [RFC2607], può essere necessario localizzare il server di autenticazione backend appropriato prima che la conversazione di autenticazione possa procedere. La parte di dominio del Network Access Identifier (NAI) [RFC2486] è tipicamente inclusa nella EAP-Response/Identity per consentire allo scambio di autenticazione di essere instradato al server di autenticazione backend appropriato. Pertanto, anche se la parte del nome peer del NAI può essere omessa nella EAP-Response/Identity dove sono presenti proxy o relay, la parte di dominio può essere richiesta.

È possibile che l'identità nella risposta di identità sia diversa dall'identità autenticata dal metodo EAP. Questo può essere intenzionale nel caso della privacy dell'identità. Un metodo EAP DOVREBBE utilizzare l'identità autenticata quando prende decisioni di controllo degli accessi.

7.4. Attacchi Man-in-the-Middle

Quando EAP è tunnelizzato all'interno di un altro protocollo che omette l'autenticazione del peer, esiste una potenziale vulnerabilità a un attacco man-in-the-middle. Per maggiori dettagli, vedere [BINDING] e [MITM].

Come indicato nella Sezione 2.1, EAP non consente sequenze non tunnelizzate di metodi di autenticazione. Se fosse consentita una sequenza di metodi di autenticazione EAP, il peer potrebbe non avere la prova che una singola entità abbia agito come autenticatore per tutti i metodi EAP nella sequenza. Ad esempio, un autenticatore potrebbe terminare un metodo EAP e quindi inoltrare il metodo successivo nella sequenza a un'altra parte senza la conoscenza o il consenso del peer. Similmente, l'autenticatore potrebbe non avere la prova che una singola entità abbia agito come peer per tutti i metodi EAP nella sequenza.

Il tunneling di EAP all'interno di un altro protocollo consente un attacco da parte di un autenticatore EAP malevolo che tunnelizza EAP a un server legittimo. Quando il protocollo di tunneling viene utilizzato per l'instaurazione delle chiavi ma non richiede l'autenticazione del peer, un attaccante che convince un peer legittimo a connettersi a lui sarà in grado di tunnelizzare pacchetti EAP a un server legittimo, autenticarsi con successo e ottenere la chiave. Questo consente all'attaccante di stabilirsi con successo come man-in-the-middle, ottenendo l'accesso alla rete, nonché la capacità di decifrare il traffico dati tra il peer legittimo e il server.

Questo attacco può essere mitigato dalle seguenti misure:

[a] Richiedere l'autenticazione reciproca all'interno dei meccanismi di tunneling EAP.

[b] Richiedere il binding crittografico tra il protocollo di tunneling EAP e i metodi EAP tunnelizzati. Quando è supportato il binding crittografico, è necessario anche un meccanismo per proteggersi dagli attacchi di downgrade che lo aggirerebbero. Per maggiori dettagli sul binding crittografico, vedere [BINDING].

[c] Limitare i metodi EAP autorizzati per l'uso senza protezione, in base alla policy del peer e dell'autenticatore.

[d] Evitare l'uso di tunnel quando è disponibile un singolo metodo forte.

7.5. Attacchi di Modifica dei Pacchetti

Sebbene i metodi EAP possano supportare l'autenticazione dell'origine dei dati, l'integrità e la protezione dalla riproduzione per pacchetto, il supporto non è fornito all'interno del livello EAP.

Poiché l'Identificatore è solo un singolo ottetto, è facile da indovinare, consentendo a un attaccante di iniettare o riprodurre con successo pacchetti EAP. Un attaccante può anche modificare gli header EAP (Code, Identifier, Length, Type) nei pacchetti EAP dove l'header non è protetto. Ciò potrebbe causare l'eliminazione inappropriata o l'errata interpretazione dei pacchetti.

Per proteggere i pacchetti EAP da modifiche, spoofing o riproduzione, sono raccomandati metodi che supportano la negoziazione protetta della suite di cifratura, l'autenticazione reciproca e la derivazione delle chiavi, nonché l'integrità e la protezione dalla riproduzione. Vedere la Sezione 7.2.1 per le definizioni di queste rivendicazioni di sicurezza.

I MIC specifici del metodo possono essere utilizzati per fornire protezione. Se un MIC per pacchetto è impiegato in un metodo EAP, allora i peer, i server di autenticazione e gli autenticatori che non operano in modalità pass-through DEVONO validare il MIC. I fallimenti di validazione del MIC DOVREBBERO essere registrati. Se un fallimento di validazione del MIC sia considerato un errore fatale o meno è determinato dalla specifica del metodo EAP.

È RACCOMANDATO che i metodi che forniscono protezione dell'integrità dei pacchetti EAP includano la copertura di tutti i campi dell'header EAP, inclusi i campi Code, Identifier, Length, Type e Type-Data.

Poiché i messaggi EAP dei tipi Identity, Notification e Nak non includono il proprio MIC, può essere desiderabile che il MIC del metodo EAP copra le informazioni contenute in questi messaggi, nonché l'header di ogni messaggio EAP.

Per fornire protezione, EAP può anche essere incapsulato all'interno di un canale protetto creato da protocolli come ISAKMP [RFC2408], come fatto in [IKEv2], o all'interno di TLS [RFC2246]. Tuttavia, come indicato nella Sezione 7.4, il tunneling EAP può portare a una vulnerabilità man-in-the-middle.

I metodi EAP esistenti definiscono Message Integrity Checks (MIC) che coprono più di un pacchetto EAP. Ad esempio, EAP-TLS [RFC2716] definisce un MIC su un record TLS che potrebbe essere suddiviso in più frammenti; nel messaggio FINISHED, il MIC è calcolato sui messaggi precedenti. Quando il MIC copre più di un pacchetto EAP, un fallimento di validazione del MIC è tipicamente considerato un errore fatale.

7.6. Attacchi Dizionario

Gli algoritmi di autenticazione tramite password come EAP-MD5, MS-CHAPv1 [RFC2433] e Kerberos V [RFC1510] sono noti per essere vulnerabili agli attacchi dizionario. Le vulnerabilità di MS-CHAPv1 sono documentate in [PPTPv1]; le vulnerabilità di MS-CHAPv2 sono documentate in [PPTPv2]; le vulnerabilità di Kerberos sono descritte in [KRBATTACK], [KRBLIM] e [KERB4WEAK].

Per proteggersi dagli attacchi dizionario, sono raccomandati metodi di autenticazione resistenti agli attacchi dizionario (come definito nella Sezione 7.2.1).

Se viene utilizzato un algoritmo di autenticazione noto per essere vulnerabile agli attacchi dizionario, la conversazione può essere tunnelizzata all'interno di un canale protetto per fornire protezione aggiuntiva. Tuttavia, come indicato nella Sezione 7.4, il tunneling EAP può portare a una vulnerabilità man-in-the-middle, e pertanto sono preferiti metodi resistenti agli attacchi dizionario.

7.7. Connessione a una Rete Non Affidabile

Con i metodi EAP che supportano l'autenticazione unidirezionale, come EAP-MD5, il peer non autentica l'autenticatore, rendendo il peer vulnerabile a un attacco da parte di un autenticatore malevolo. I metodi che supportano l'autenticazione reciproca (come definito nella Sezione 7.2.1) affrontano questa vulnerabilità.

In EAP, non vi è alcun requisito che l'autenticazione sia full duplex o che lo stesso protocollo sia utilizzato in entrambe le direzioni. È perfettamente accettabile che diversi protocolli siano utilizzati in ciascuna direzione. Questo dipenderà, ovviamente, dai protocolli specifici negoziati. Tuttavia, in generale, completare un'unica autenticazione reciproca unificata è preferibile a due autenticazioni unidirezionali, una in ciascuna direzione. Questo perché autenticazioni separate che non sono legate crittograficamente in modo da dimostrare che fanno parte della stessa sessione sono soggette ad attacchi man-in-the-middle, come discusso nella Sezione 7.4.

7.8. Attacchi di Negoziazione

In un attacco di negoziazione, l'attaccante tenta di convincere il peer e l'autenticatore a negoziare un metodo EAP meno sicuro. EAP non fornisce protezione per i pacchetti Nak Response, sebbene sia possibile per un metodo includere la copertura delle Nak Response in un MIC specifico del metodo.

In o associato a ciascun autenticatore, non è previsto che un particolare peer nominato supporti una scelta di metodi. Questo renderebbe il peer vulnerabile ad attacchi che negoziano il metodo meno sicuro all'interno di un insieme. Invece, per ogni peer nominato, DOVREBBE esserci un'indicazione di esattamente un metodo utilizzato per autenticare quel nome peer. Se un peer deve utilizzare diversi metodi di autenticazione in circostanze diverse, allora DOVREBBERO essere impiegate identità distinte, ciascuna che identifica esattamente un metodo di autenticazione.

7.9. Idiosincrasie di Implementazione

L'interazione di EAP con i livelli inferiori come PPP e IEEE 802 è altamente dipendente dall'implementazione.

Ad esempio, in caso di fallimento dell'autenticazione, alcune implementazioni PPP non terminano il collegamento, ma limitano piuttosto il traffico nei protocolli di livello rete a un sottoinsieme filtrato, il che a sua volta consente al peer di avere l'opportunità di aggiornare i segreti o inviare una mail all'amministratore di rete indicando un problema. Similmente, mentre un fallimento dell'autenticazione comporterà il rifiuto dell'accesso alla porta controllata in [IEEE-802.1X], può essere consentito traffico limitato sulla porta non controllata.

In EAP, non vi è alcuna disposizione per i tentativi di ri-autenticazione falliti. Tuttavia, in PPP, la macchina a stati LCP può rinegoziare il protocollo di autenticazione in qualsiasi momento, consentendo così un nuovo tentativo. Similmente, in IEEE 802.1X, il Supplicant o l'Authenticator può ri-autenticarsi in qualsiasi momento. È raccomandato che tutti i contatori utilizzati per i fallimenti di autenticazione non vengano ripristinati prima di un'autenticazione riuscita o di una successiva terminazione del collegamento fallito.

7.10. Derivazione delle Chiavi

È possibile per il peer e il server EAP autenticarsi reciprocamente e derivare chiavi. Per fornire materiale di chiave per l'uso in una suite di cifratura negoziata successivamente, un metodo EAP che supporta la derivazione delle chiavi DEVE esportare una Master Session Key (MSK) di almeno 64 ottetti e un'Extended Master Session Key (EMSK) di almeno 64 ottetti. I metodi EAP che derivano chiavi DEVONO fornire autenticazione reciproca tra il peer EAP e il server EAP.

La MSK e l'EMSK NON DEVONO essere utilizzate direttamente per proteggere i dati; tuttavia, sono di dimensioni sufficienti per consentire la derivazione di una AAA-Key successivamente utilizzata per derivare Transient Session Keys (TSK) per l'uso con la suite di cifratura selezionata. Ogni suite di cifratura è responsabile di specificare come derivare i TSK dalla AAA-Key.

La AAA-Key è derivata dal materiale di chiave esportato dal metodo EAP (MSK ed EMSK). Questa derivazione avviene sul server AAA. In molti protocolli esistenti che utilizzano EAP, la AAA-Key e la MSK sono equivalenti, ma sono possibili meccanismi più complicati (vedere [KEYFRAME] per i dettagli).

I metodi EAP DOVREBBERO garantire la freschezza della MSK e dell'EMSK, anche nei casi in cui una parte potrebbe non avere un generatore di numeri casuali di alta qualità. Un metodo RACCOMANDATO è per ciascuna parte fornire un nonce di almeno 128 bit, utilizzato nella derivazione della MSK e dell'EMSK.

I metodi EAP esportano la MSK e l'EMSK, ma non i Transient Session Keys, al fine di consentire ai metodi EAP di essere indipendenti dalla suite di cifratura e dal mezzo. Il materiale di chiave esportato dai metodi EAP DEVE essere indipendente dalla suite di cifratura negoziata per proteggere i dati.

A seconda del livello inferiore, i metodi EAP possono essere eseguiti prima o dopo la negoziazione della suite di cifratura, in modo che la suite di cifratura selezionata possa non essere nota al metodo EAP. Fornendo materiale di chiave utilizzabile con qualsiasi suite di cifratura, i metodi EAP possono essere utilizzati con un'ampia gamma di suite di cifratura e mezzi.

Per preservare l'indipendenza degli algoritmi, i metodi EAP che derivano chiavi DOVREBBERO supportare (e documentare) la negoziazione protetta della suite di cifratura utilizzata per proteggere la conversazione EAP tra il peer e il server. Questo è distinto dalla suite di cifratura negoziata tra il peer e l'autenticatore, utilizzata per proteggere i dati.

La forza dei Transient Session Keys (TSK) utilizzati per proteggere i dati dipende in definitiva dalla forza delle chiavi generate dal metodo EAP. Se un metodo EAP non può produrre materiale di chiave di forza sufficiente, allora i TSK possono essere soggetti a un attacco di forza bruta. Per consentire distribuzioni che richiedono chiavi forti, i metodi EAP che supportano la derivazione delle chiavi DOVREBBERO essere in grado di generare una MSK e un'EMSK, ciascuna con una forza effettiva della chiave di almeno 128 bit.

I metodi che supportano la derivazione delle chiavi DEVONO dimostrare la separazione crittografica tra i rami MSK ed EMSK della gerarchia delle chiavi EAP. Senza violare un'assunzione crittografica fondamentale (come la non invertibilità di una funzione unidirezionale), un attaccante che recupera la MSK o l'EMSK NON DEVE essere in grado di recuperare l'altra quantità con un livello di sforzo inferiore alla forza bruta.

Le sottostringhe non sovrapposte della MSK DEVONO essere crittograficamente separate l'una dall'altra, come definito nella Sezione 7.2.1. Cioè, la conoscenza di una sottostringa NON DEVE aiutare a recuperare un'altra sottostringa senza violare un'assunzione crittografica difficile. Questo è richiesto perché alcune suite di cifratura esistenti formano i TSK semplicemente dividendo la AAA-Key in pezzi di lunghezza appropriata. Similmente, le sottostringhe non sovrapposte dell'EMSK DEVONO essere crittograficamente separate l'una dall'altra e dalle sottostringhe della MSK.

L'EMSK è riservata per uso futuro e DEVE rimanere sul peer EAP e sul server EAP dove è derivata; NON DEVE essere trasportata a, o condivisa con, parti aggiuntive, né utilizzata per derivare altre chiavi. (Questa restrizione sarà allentata in un documento futuro che specifica come l'EMSK possa essere utilizzata.)

Poiché EAP non fornisce una negoziazione esplicita della durata delle chiavi, i peer EAP, gli autenticatori e i server di autenticazione DEVONO essere preparati per situazioni in cui una parte scarta lo stato delle chiavi, che rimane valido su un'altra parte.

Questa specifica non fornisce una guida dettagliata su come i metodi EAP derivano la MSK e l'EMSK, come la AAA-Key è derivata dalla MSK e/o dall'EMSK, o come i TSK sono derivati dalla AAA-Key.

Lo sviluppo e la validazione degli algoritmi di derivazione delle chiavi sono difficili, e di conseguenza, i metodi EAP DOVREBBERO riutilizzare meccanismi ben consolidati e analizzati per la derivazione delle chiavi (come quelli specificati in IKE [RFC2409] o TLS [RFC2246]), piuttosto che inventarne di nuovi. I metodi EAP DOVREBBERO anche sfruttare meccanismi ben consolidati e analizzati per la derivazione di MSK ed EMSK. Maggiori dettagli sulla Derivazione delle Chiavi EAP sono forniti in [KEYFRAME].

7.11. Suite di Cifratura Deboli

Se dopo l'autenticazione EAP iniziale, i pacchetti di dati vengono inviati senza autenticazione, integrità e protezione dalla riproduzione per pacchetto, un attaccante con accesso al mezzo può iniettare pacchetti, "capovolgere bit" nei pacchetti esistenti, riprodurre pacchetti, o persino dirottare completamente la sessione. Senza riservatezza per pacchetto, è possibile intercettare i pacchetti di dati.

Per proteggersi dalla modifica, dallo spoofing o dall'intercettazione dei dati, è raccomandato utilizzare metodi EAP che supportano l'autenticazione reciproca e la derivazione delle chiavi (come definito nella Sezione 7.2.1), insieme a livelli inferiori che forniscono riservatezza, autenticazione, integrità e protezione dalla riproduzione per pacchetto.

Inoltre, se il livello inferiore esegue la negoziazione della suite di cifratura, dovrebbe essere compreso che EAP non fornisce di per sé la protezione dell'integrità di tale negoziazione. Pertanto, al fine di evitare attacchi di downgrade che porterebbero all'uso di suite di cifratura più deboli, i client che implementano la negoziazione della suite di cifratura del livello inferiore DOVREBBERO proteggersi contro il downgrade della negoziazione.

Questo può essere fatto consentendo agli utenti di configurare quali suite di cifratura sono accettabili come questione di policy di sicurezza, oppure la negoziazione della suite di cifratura PUÒ essere autenticata utilizzando materiale di chiave derivato dall'autenticazione EAP e un algoritmo MIC concordato in anticipo dai peer del livello inferiore.

7.12. Livello di Collegamento

Ci sono problemi di affidabilità e sicurezza con le indicazioni del livello di collegamento in PPP, LAN IEEE 802 e LAN wireless IEEE 802.11:

[a] PPP. In PPP, le indicazioni del livello di collegamento come LCP-Terminate (indicazione di fallimento del collegamento) e NCP (indicazione di successo del collegamento) non sono autenticate né protette dall'integrità. Pertanto, possono essere falsificate da un attaccante con accesso al collegamento.

[b] IEEE 802. I frame EAPOL-Start ed EAPOL-Logoff di IEEE 802.1X non sono autenticati né protetti dall'integrità. Pertanto, possono essere falsificati da un attaccante con accesso al collegamento.

[c] IEEE 802.11. In IEEE 802.11, le indicazioni del livello di collegamento includono i frame Disassociate e Deauthenticate (indicazioni di fallimento del collegamento) e il primo messaggio dell'handshake a 4 vie (indicazione di successo del collegamento). Questi messaggi non sono autenticati né protetti dall'integrità, e sebbene non siano inoltrabili, possono essere falsificati da un attaccante nel raggio d'azione.

In IEEE 802.11, i frame di dati IEEE 802.1X possono essere inviati come frame di dati unicast di Classe 3 e sono quindi inoltrabili. Ciò significa che sebbene i messaggi EAPOL-Start ed EAPOL-Logoff possano essere autenticati e protetti dall'integrità, possono essere falsificati da un attaccante autenticato remoto dal bersaglio quando è abilitata la "pre-autenticazione".

In IEEE 802.11, un'indicazione di "collegamento interrotto" è un'indicazione inaffidabile di fallimento del collegamento, poiché la forza del segnale wireless può andare e venire e può essere influenzata da interferenze a radiofrequenza generate da un attaccante. Per evitare ripristini non necessari, è consigliabile smorzare queste indicazioni, piuttosto che passarle direttamente a EAP. Poiché EAP supporta la ritrasmissione, è robusto contro le perdite di connettività transitorie.

7.13. Separazione dell'Autenticatore e del Server di Autenticazione Backend

È possibile per il peer EAP e il server EAP autenticarsi reciprocamente e derivare una AAA-Key per una suite di cifratura utilizzata per proteggere il traffico dati successivo. Questo non presenta problemi sul peer, poiché il peer e il client EAP risiedono sulla stessa macchina; tutto ciò che è richiesto è che il client derivi la AAA-Key dalla MSK e dall'EMSK esportate dal metodo EAP, e poi passi una Transient Session Key (TSK) al modulo della suite di cifratura.

Tuttavia, nel caso in cui l'autenticatore e il server di autenticazione risiedano su macchine diverse, ci sono diverse implicazioni per la sicurezza.

[a] L'autenticazione avverrà tra il peer e il server di autenticazione, non tra il peer e l'autenticatore. Questo significa che non è possibile per il peer validare l'identità dell'autenticatore con cui sta parlando, utilizzando solo EAP.

[b] Come discusso in [RFC3579], l'autenticatore fa affidamento sul protocollo AAA per conoscere il risultato di una conversazione di autenticazione, e non guarda il pacchetto EAP incapsulato (se presente) per determinare il risultato. In pratica, questo implica che il protocollo AAA parlato tra l'autenticatore e il server di autenticazione DEVE supportare l'autenticazione, l'integrità e la protezione dalla riproduzione per pacchetto.

[c] Dopo il completamento della conversazione EAP, dove verranno abilitati servizi di sicurezza del livello inferiore come riservatezza, autenticazione, integrità e protezione dalla riproduzione per pacchetto, un protocollo di associazione sicura DOVREBBE essere eseguito tra il peer e l'autenticatore al fine di fornire autenticazione reciproca tra il peer e l'autenticatore, garantire la vivacità delle chiavi di sessione transitorie, fornire negoziazione protetta della suite di cifratura e delle capacità per i dati successivi, e sincronizzare l'uso delle chiavi.

[d] Una AAA-Key derivata dalla MSK e/o dall'EMSK negoziata tra il peer e il server di autenticazione PUÒ essere trasmessa all'autenticatore. Pertanto, un meccanismo deve essere fornito per trasmettere la AAA-Key dal server di autenticazione all'autenticatore che ne ha bisogno. La specifica dei meccanismi di derivazione, trasporto e wrapping della AAA-Key è al di fuori dell'ambito di questo documento. Maggiori dettagli sulla Derivazione della AAA-Key sono forniti in [KEYFRAME].

7.14. Password in Chiaro

Questa specifica non definisce un meccanismo di autenticazione tramite password in chiaro. L'omissione è intenzionale. L'uso di password in chiaro consentirebbe alla password di essere catturata da un attaccante con accesso a un collegamento su cui vengono trasmessi pacchetti EAP.

Poiché i protocolli che incapsulano EAP, come RADIUS [RFC3579], potrebbero non fornire riservatezza, i pacchetti EAP possono successivamente essere incapsulati per il trasporto su Internet, dove potrebbero essere catturati da un attaccante.

Di conseguenza, le password in chiaro non possono essere utilizzate in sicurezza all'interno di EAP, a meno che non siano incapsulate all'interno di un tunnel protetto con autenticazione del server. Alcuni degli stessi rischi si applicano anche ai metodi EAP senza resistenza agli attacchi dizionario, come definito nella Sezione 7.2.1. Vedere la Sezione 7.6 per i dettagli.

7.15. Binding del Canale

È possibile per un autenticatore EAP compromesso o implementato in modo inadeguato comunicare informazioni errate al peer EAP e/o al server. Questo può consentire a un autenticatore di impersonare un altro autenticatore o di comunicare informazioni errate tramite meccanismi out-of-band (come tramite un protocollo AAA o di livello inferiore).

Quando EAP viene utilizzato in modalità pass-through, il peer EAP tipicamente non valida l'identità dell'autenticatore pass-through, verifica solo che l'autenticatore pass-through sia affidabile dal server EAP. Questo crea una potenziale vulnerabilità di sicurezza.

La Sezione 4.3.7 di [RFC3579] descrive come un autenticatore pass-through EAP che agisce come client AAA può essere rilevato se tenta di impersonare un altro autenticatore (come inviando attributi NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] o NAS-IPv6-Address [RFC3162] errati tramite il protocollo AAA). Tuttavia, è possibile per un autenticatore pass-through che agisce come client AAA fornire informazioni corrette al server AAA, mentre comunica informazioni fuorvianti al peer EAP tramite un protocollo di livello inferiore.

Ad esempio, è possibile per un autenticatore compromesso utilizzare il Called-Station-Id o il NAS-Identifier di un altro autenticatore quando comunica con il peer EAP tramite un protocollo di livello inferiore, o per un autenticatore pass-through che agisce come client AAA fornire un Calling-Station-Id [RFC2865][RFC3580] del peer errato al server AAA tramite il protocollo AAA.

Per affrontare questa vulnerabilità, i metodi EAP possono supportare uno scambio protetto di proprietà del canale come identificatori di endpoint, inclusi (ma non limitati a): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] e NAS-IPv6-Address [RFC3162].

Utilizzando tale scambio protetto, è possibile confrontare le proprietà del canale fornite dall'autenticatore tramite meccanismi out-of-band con quelle scambiate all'interno del metodo EAP. Quando vengono riscontrate discrepanze, queste DOVREBBERO essere registrate; possono essere prese anche azioni aggiuntive, come negare l'accesso.

7.16. Indicazioni di Risultato Protette

In EAP, i pacchetti Success e Failure non sono né riconosciuti né protetti dall'integrità. Le indicazioni di risultato migliorano la resilienza alla perdita di pacchetti Success e Failure quando EAP viene eseguito su livelli inferiori che non supportano la ritrasmissione o la sincronizzazione dello stato di autenticazione. In mezzi come IEEE 802.11, che fornisce la ritrasmissione, così come la sincronizzazione dello stato di autenticazione tramite l'handshake a 4 vie definito in [IEEE-802.11i], la resilienza aggiuntiva è tipicamente di beneficio marginale.

A seconda del metodo e delle circostanze, le indicazioni di risultato possono essere falsificabili da un attaccante. Si dice che un metodo fornisce indicazioni di risultato protette se supporta le indicazioni di risultato, così come le rivendicazioni di "protezione dell'integrità" e "protezione dalla riproduzione". Un metodo che supporta indicazioni di risultato protette DEVE indicare quali indicazioni di risultato sono protette e quali non lo sono.

Le indicazioni di risultato protette non sono richieste per proteggersi dagli autenticatori malevoli. In un metodo di autenticazione reciproca, richiedere che il server si autentichi al peer prima che il peer accetti un pacchetto Success impedisce a un attaccante di agire come autenticatore malevolo.

Tuttavia, è possibile per un attaccante falsificare un pacchetto Success dopo che il server si è autenticato al peer, ma prima che il peer si sia autenticato al server. Se il peer accettasse il pacchetto Success falsificato e tentasse di accedere alla rete mentre non si è ancora autenticato con successo al server, potrebbe essere montato un attacco denial-of-service contro il peer. Dopo tale attacco, se il livello inferiore supporta le indicazioni di fallimento, l'autenticatore può sincronizzare lo stato con il peer fornendo un'indicazione di fallimento del livello inferiore. Vedere la Sezione 7.12 per i dettagli.

Se un server dovesse autenticare il peer e inviare un pacchetto Success prima di determinare se il peer ha autenticato l'autenticatore, potrebbe verificarsi un timeout di inattività se l'autenticatore non è autenticato dal peer. Quando supportato dal livello inferiore, un autenticatore che rileva l'assenza del peer può rilasciare risorse.

In un metodo che supporta le indicazioni di risultato, un peer che ha autenticato il server non considera l'autenticazione riuscita fino a quando non riceve un'indicazione che il server lo ha autenticato con successo. Similmente, un server che ha autenticato con successo il peer non considera l'autenticazione riuscita fino a quando non riceve un'indicazione che il peer ha autenticato il server.

Per evitare problemi di sincronizzazione, prima di inviare un'indicazione di risultato di successo, è desiderabile per il mittente verificare che esista un'autorizzazione sufficiente per concedere l'accesso, sebbene, come discusso di seguito, questo non sia sempre possibile.

Sebbene le indicazioni di risultato possano consentire la sincronizzazione del risultato di autenticazione tra il peer e il server, questo non garantisce che il peer e l'autenticatore saranno sincronizzati in termini di loro autorizzazione o che non si verificheranno timeout. Ad esempio, il server EAP potrebbe non essere consapevole di una decisione di autorizzazione presa da un proxy AAA; il server AAA potrebbe verificare l'autorizzazione solo dopo che l'autenticazione è stata completata con successo, per scoprire che l'autorizzazione non può essere concessa, o il server AAA potrebbe concedere l'accesso ma l'autenticatore potrebbe non essere in grado di fornirlo a causa di una temporanea mancanza di risorse. In queste situazioni, la sincronizzazione può essere raggiunta solo tramite indicazioni di risultato del livello inferiore.

Le indicazioni di successo possono essere esplicite o implicite. Ad esempio, quando un metodo supporta i messaggi di errore, un'indicazione di successo implicita può essere definita come la ricezione di un messaggio specifico senza messaggio di errore precedente. I fallimenti sono tipicamente indicati esplicitamente. Come descritto nella Sezione 4.2, un peer scarta silenziosamente un pacchetto Failure ricevuto in un punto dove il metodo non consente esplicitamente l'invio. Ad esempio, un metodo che fornisce i propri messaggi di errore potrebbe richiedere che il peer riceva un messaggio di errore prima di accettare un pacchetto Failure.

L'autenticazione, l'integrità e la protezione dalla riproduzione per pacchetto delle indicazioni di risultato protegge contro lo spoofing. Poiché le indicazioni di risultato protette richiedono l'uso di una chiave per l'autenticazione e la protezione dell'integrità per pacchetto, i metodi che supportano le indicazioni di risultato protette DEVONO anche supportare le rivendicazioni di "derivazione delle chiavi", "autenticazione reciproca", "protezione dell'integrità" e "protezione dalla riproduzione".

Le indicazioni di risultato protette affrontano alcune, ma non tutte, le vulnerabilità denial-of-service dovute allo spoofing dei pacchetti Success e Failure. I metodi EAP possono tipicamente fornire indicazioni di risultato protette solo in certe circostanze. Ad esempio, gli errori possono verificarsi prima della derivazione delle chiavi, e quindi potrebbe non essere possibile proteggere tutte le indicazioni di fallimento. È anche possibile che le indicazioni di risultato non siano supportate in entrambe le direzioni o che la sincronizzazione non sia raggiunta in tutte le modalità operative.

Ad esempio, in EAP-TLS [RFC2716], nell'handshake di autenticazione client, il server autentica il peer, ma non riceve un'indicazione protetta su se il peer lo ha autenticato. Al contrario, il peer autentica il server ed è consapevole se il server lo ha autenticato. Nell'handshake di ripresa della sessione, il peer autentica il server, ma non riceve un'indicazione protetta su se il server lo ha autenticato. In questa modalità, il server autentica il peer ed è consapevole se il peer lo ha autenticato.