2. Extensible Authentication Protocol (EAP)

Lo scambio di autenticazione EAP procede come segue:

[1] L'autenticatore (authenticator) invia una richiesta (Request) per autenticare il peer.

La richiesta ha un campo Type per indicare cosa viene richiesto. Esempi di tipi di richiesta includono Identity (identità), MD5-challenge, ecc. Il tipo MD5-challenge corrisponde strettamente al protocollo di autenticazione CHAP [RFC1994]. Tipicamente, l'autenticatore invierà una Identity Request iniziale; tuttavia, una Identity Request iniziale non è richiesta e PUÒ essere ignorata. Ad esempio, l'identità potrebbe non essere richiesta quando è determinata dalla porta a cui il peer si è connesso (linee dedicate, switch dedicato o porte dial-up), o quando l'identità viene ottenuta in altro modo (tramite l'identità della stazione chiamante o indirizzo MAC, nel campo Name della MD5-Challenge Response, ecc.).

[2] Il peer invia un pacchetto Response in risposta a una richiesta valida.

Come con il pacchetto Request, il pacchetto Response contiene un campo Type, che corrisponde al campo Type della richiesta.

[3] L'autenticatore invia un pacchetto Request aggiuntivo, e il peer risponde con una Response.

La sequenza di richieste e risposte continua finché necessario. EAP è un protocollo "lock step", quindi a parte la richiesta iniziale, una nuova richiesta non può essere inviata prima di ricevere una Response valida. L'autenticatore è responsabile della ritrasmissione delle richieste come descritto nella Sezione 4.1. Dopo un numero appropriato di ritrasmissioni, l'autenticatore DOVREBBE terminare la conversazione EAP. L'autenticatore NON DEVE inviare un pacchetto Success o Failure quando ritrasmette o quando non riesce a ottenere una risposta dal peer.

[4] La conversazione continua finché l'autenticatore non può autenticare il peer (risposte inaccettabili a una o più richieste), nel qual caso l'implementazione dell'autenticatore DEVE trasmettere un EAP Failure (Code 4). Alternativamente, la conversazione di autenticazione può continuare finché l'autenticatore determina che si è verificata un'autenticazione riuscita, nel qual caso l'autenticatore DEVE trasmettere un EAP Success (Code 3).

Vantaggi:

o Il protocollo EAP può supportare più meccanismi di autenticazione senza dover pre-negoziare uno particolare.

o I dispositivi Network Access Server (NAS) (ad es., uno switch o access point) non devono comprendere ogni metodo di autenticazione e POSSONO agire come agente pass-through per un server di autenticazione backend. Il supporto per pass-through è opzionale. Un autenticatore PUÒ autenticare peer locali, mentre allo stesso tempo agisce come pass-through per peer non locali e metodi di autenticazione che non implementa localmente.

o La separazione dell'autenticatore dal server di autenticazione backend semplifica la gestione delle credenziali e il processo decisionale delle policy.

Svantaggi:

o Per l'uso in PPP, EAP richiede l'aggiunta di un nuovo tipo di autenticazione a PPP LCP e quindi le implementazioni PPP dovranno essere modificate per usarlo. Si discosta anche dal precedente modello di autenticazione PPP di negoziazione di un meccanismo di autenticazione specifico durante LCP. Allo stesso modo, le implementazioni di switch o access point devono supportare [IEEE-802.1X] per utilizzare EAP.

o Quando l'autenticatore è separato dal server di autenticazione backend, ciò complica l'analisi di sicurezza e, se necessario, la distribuzione delle chiavi.

2.1. Supporto per le Sequenze (Support for Sequences)

Una conversazione EAP PUÒ utilizzare una sequenza di metodi. Un esempio comune di questo è una richiesta Identity seguita da un singolo metodo di autenticazione EAP come MD5-Challenge. Tuttavia, il peer e l'autenticatore DEVONO utilizzare solo un metodo di autenticazione (Type 4 o superiore) all'interno di una conversazione EAP, dopo di che l'autenticatore DEVE inviare un pacchetto Success o Failure.

Una volta che un peer ha inviato una Response dello stesso Type della richiesta iniziale, un autenticatore NON DEVE inviare una richiesta di un Type diverso prima del completamento del round finale di un determinato metodo (con l'eccezione di una Notification-Request) e NON DEVE inviare una richiesta per un metodo aggiuntivo di qualsiasi Type dopo il completamento del metodo di autenticazione iniziale; un peer che riceve tali richieste DEVE trattarle come non valide e scartarle silenziosamente. Di conseguenza, Identity Requery non è supportato.

Un peer NON DEVE inviare un Nak (legacy o expanded) in risposta a una richiesta dopo che è stata inviata una Response non-Nak iniziale. Poiché pacchetti EAP Request falsificati possono essere inviati da un attaccante, un autenticatore che riceve un Nak inaspettato DOVREBBE scartarlo e registrare l'evento.

Più metodi di autenticazione all'interno di una conversazione EAP non sono supportati a causa della loro vulnerabilità agli attacchi man-in-the-middle (vedere Sezione 7.4) e incompatibilità con le implementazioni esistenti.

Quando viene utilizzato un singolo metodo di autenticazione EAP, ma altri metodi vengono eseguiti al suo interno (un metodo "tunneled"), il divieto contro più metodi di autenticazione non si applica. Tali metodi "tunneled" appaiono come un singolo metodo di autenticazione per EAP. La compatibilità con le versioni precedenti può essere fornita, poiché un peer che non supporta un metodo "tunneled" può rispondere alla EAP-Request iniziale con un Nak (legacy o expanded). Per affrontare le vulnerabilità di sicurezza, i metodi "tunneled" DEVONO supportare la protezione contro gli attacchi man-in-the-middle.

2.2. Modello di Multiplexing EAP (EAP Multiplexing Model)

Concettualmente, le implementazioni EAP consistono nei seguenti componenti:

[a] Livello inferiore (Lower layer). Il livello inferiore è responsabile della trasmissione e ricezione di frame EAP tra il peer e l'autenticatore. EAP è stato eseguito su una varietà di livelli inferiori inclusi PPP, LAN IEEE 802 cablate [IEEE-802.1X], LAN wireless IEEE 802.11 [IEEE-802.11], UDP (L2TP [RFC2661] e IKEv2 [IKEv2]) e TCP [PIC]. Il comportamento del livello inferiore è discusso nella Sezione 3.

[b] Livello EAP (EAP layer). Il livello EAP riceve e trasmette pacchetti EAP tramite il livello inferiore, implementa il rilevamento dei duplicati e la ritrasmissione, e consegna e riceve messaggi EAP da e verso i livelli peer e autenticatore EAP.

[c] Livelli peer e autenticatore EAP (EAP peer and authenticator layers). In base al campo Code, il livello EAP demultiplexa i pacchetti EAP in arrivo ai livelli peer e autenticatore EAP. Tipicamente, un'implementazione EAP su un determinato host supporterà la funzionalità peer o autenticatore, ma è possibile per un host agire sia come peer EAP che come autenticatore. In tale implementazione saranno presenti sia i livelli peer che autenticatore EAP.

[d] Livelli di metodo EAP (EAP method layers). I metodi EAP implementano gli algoritmi di autenticazione e ricevono e trasmettono messaggi EAP tramite i livelli peer e autenticatore EAP. Poiché il supporto per la frammentazione non è fornito da EAP stesso, questa è responsabilità dei metodi EAP, che sono discussi nella Sezione 5.

Il modello di multiplexing EAP è illustrato nella Figura 1 di seguito. Si noti che non vi è alcun requisito che un'implementazione sia conforme a questo modello, purché il comportamento on-the-wire sia coerente con esso.

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                 +------------>-------------+

Figura 1: Modello di Multiplexing EAP

All'interno di EAP, il campo Code funziona in modo molto simile a un numero di protocollo in IP. Si presume che il livello EAP demultiplexi i pacchetti EAP in arrivo in base al campo Code. I pacchetti EAP ricevuti con Code=1 (Request), 3 (Success) e 4 (Failure) vengono consegnati dal livello EAP al livello peer EAP, se implementato. I pacchetti EAP con Code=2 (Response) vengono consegnati al livello autenticatore EAP, se implementato.

All'interno di EAP, il campo Type funziona in modo molto simile a un numero di porta in UDP o TCP. Si presume che i livelli peer e autenticatore EAP demultiplexino i pacchetti EAP in arrivo in base al loro Type e li consegnino solo al metodo EAP corrispondente a quel Type. Un'implementazione di metodo EAP su un host può registrarsi per ricevere pacchetti dai livelli peer o autenticatore, o da entrambi, a seconda del ruolo o dei ruoli che supporta.

Poiché i metodi di autenticazione EAP potrebbero voler accedere all'identità, le implementazioni DOVREBBERO rendere la Identity Request e Response accessibili ai metodi di autenticazione (Types 4 o superiore), oltre al metodo Identity. Il Type Identity è discusso nella Sezione 5.1.

Una Notification Response viene utilizzata solo come conferma che il peer ha ricevuto la Notification Request, non che l'ha elaborata o visualizzata il messaggio all'utente. Non si può presumere che i contenuti della Notification Request o Response siano disponibili per un altro metodo. Il Type Notification è discusso nella Sezione 5.2.

Nak (Type 3) o Expanded Nak (Type 254) vengono utilizzati per scopi di negoziazione del metodo. I peer rispondono a una EAP Request iniziale per un Type inaccettabile con una Nak Response (Type 3) o Expanded Nak Response (Type 254). Non si può presumere che i contenuti della o delle Nak Response siano disponibili per un altro metodo. Il o i Type Nak sono discussi nella Sezione 5.3.

I pacchetti EAP con Codes di Success o Failure non includono un campo Type e non vengono consegnati a un metodo EAP. Success e Failure sono discussi nella Sezione 4.2.

Date queste considerazioni, i messaggi Success, Failure, Nak Response(s) e Notification Request/Response NON DEVONO essere utilizzati per trasportare dati destinati alla consegna ad altri metodi EAP.

2.3. Comportamento Pass-Through

Quando opera come "autenticatore pass-through", un autenticatore esegue controlli sui campi Code, Identifier e Length come descritto nella Sezione 4.1. Inoltra i pacchetti EAP ricevuti dal peer e destinati al suo livello autenticatore al server di autenticazione backend; i pacchetti ricevuti dal server di autenticazione backend destinati al peer vengono inoltrati ad esso.

Un host che riceve un pacchetto EAP può fare solo una di tre cose con esso: agire su di esso, scartarlo o inoltrarlo. La decisione di inoltro è tipicamente basata solo sull'esame dei campi Code, Identifier e Length. Un'implementazione di autenticatore pass-through DEVE essere in grado di inoltrare i pacchetti EAP ricevuti dal peer con Code=2 (Response) al server di autenticazione backend. Deve anche DEVE essere in grado di ricevere pacchetti EAP dal server di autenticazione backend e inoltrare pacchetti EAP con Code=1 (Request), Code=3 (Success) e Code=4 (Failure) al peer.

A meno che l'autenticatore non implementi localmente uno o più metodi di autenticazione che supportano il ruolo di autenticatore, i campi di intestazione del livello di metodo EAP (Type, Type-Data) non vengono esaminati come parte della decisione di inoltro. Quando l'autenticatore supporta metodi di autenticazione locali, PUÒ esaminare il campo Type per determinare se agire sul pacchetto stesso o inoltrarlo. Le implementazioni di autenticatore pass-through conformi DEVONO per impostazione predefinita inoltrare pacchetti EAP di qualsiasi Type.

I pacchetti EAP ricevuti con Code=1 (Request), Code=3 (Success) e Code=4 (Failure) vengono demultiplexati dal livello EAP e consegnati al livello peer. Pertanto, a meno che un host non implementi un livello peer EAP, questi pacchetti verranno scartati silenziosamente. Allo stesso modo, i pacchetti EAP ricevuti con Code=2 (Response) vengono demultiplexati dal livello EAP e consegnati al livello autenticatore. Pertanto, a meno che un host non implementi un livello autenticatore EAP, questi pacchetti verranno scartati silenziosamente. Il comportamento di un "peer pass-through" non è definito all'interno di questa specifica ed è non supportato dai protocolli AAA come RADIUS [RFC3579] e Diameter [DIAM-EAP].

Il modello di inoltro è illustrato nella Figura 2.

Peer Autenticatore Pass-Through Server di Autenticazione

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         +-------->--------+           +--------->-------+

Figura 2: Autenticatore Pass-Through

Per le sessioni in cui l'autenticatore agisce come pass-through, DEVE determinare l'esito dell'autenticazione esclusivamente in base all'indicazione Accept/Reject inviata dal server di autenticazione backend; l'esito NON DEVE essere determinato dal contenuto di un pacchetto EAP inviato insieme all'indicazione Accept/Reject, o dall'assenza di tale pacchetto EAP incapsulato.

2.4. Operazione Peer-to-Peer

Poiché EAP è un protocollo peer-to-peer, un'autenticazione indipendente e simultanea può avvenire nella direzione inversa (a seconda delle capacità del livello inferiore). Entrambe le estremità del collegamento possono agire come autenticatori e peer allo stesso tempo. In questo caso, è necessario che entrambe le estremità implementino i livelli autenticatore e peer EAP. Inoltre, le implementazioni del metodo EAP su entrambi i peer devono supportare sia la funzionalità autenticatore che peer.

Sebbene EAP supporti l'operazione peer-to-peer, alcune implementazioni EAP, metodi, protocolli AAA e livelli di collegamento potrebbero non supportarla. Alcuni metodi EAP possono supportare l'autenticazione asimmetrica, con un tipo di credenziale richiesta per il peer e un altro tipo per l'autenticatore. Gli host che supportano l'operazione peer-to-peer con tale metodo dovrebbero essere provisionati con entrambi i tipi di credenziali.

Ad esempio, EAP-TLS [RFC2716] è un protocollo client-server in cui tipicamente vengono utilizzati profili di certificato distinti per il client e il server. Ciò implica che un host che supporta l'autenticazione peer-to-peer con EAP-TLS dovrebbe implementare sia i livelli peer che autenticatore EAP, supportare sia i ruoli peer che autenticatore nell'implementazione EAP-TLS e provisionare certificati appropriati per ciascun ruolo.

I protocolli AAA come RADIUS/EAP [RFC3579] e Diameter EAP [DIAM-EAP] supportano solo l'operazione "autenticatore pass-through". Come notato in [RFC3579] Sezione 2.6.2, un server RADIUS risponde a una Access-Request che incapsula un pacchetto EAP-Request, Success o Failure con un Access-Reject. Non c'è quindi supporto per l'operazione "peer pass-through".

Anche quando viene utilizzato un metodo che supporta l'autenticazione reciproca e le indicazioni di risultato, diverse considerazioni possono dettare che sono necessarie due autenticazioni EAP (una in ciascuna direzione). Queste includono:

[1] Supporto per la derivazione di chiavi di sessione bidirezionale nel livello inferiore. I livelli inferiori come IEEE 802.11 possono supportare solo la derivazione unidirezionale e il trasporto di chiavi di sessione transitorie. Ad esempio, lo scambio di chiavi di gruppo definito in [IEEE-802.11i] è unidirezionale, poiché nella modalità infrastruttura IEEE 802.11, solo l'Access Point (AP) invia traffico multicast/broadcast. Nella modalità ad hoc IEEE 802.11, dove entrambi i peer possono inviare traffico multicast/broadcast, sono necessari due scambi di chiavi di gruppo unidirezionali. A causa delle limitazioni del design, ciò implica anche la necessità di derivazioni di chiavi unicast e scambi di metodi EAP in ciascuna direzione.

[2] Supporto per il tie-breaking nel livello inferiore. I livelli inferiori come IEEE 802.11 ad hoc non supportano il "tie-breaking" in cui due host che iniziano l'autenticazione l'uno con l'altro procederanno solo con una singola autenticazione. Ciò implica che anche se 802.11 supportasse uno scambio di chiavi di gruppo bidirezionale, due autenticazioni, una in ciascuna direzione, potrebbero ancora verificarsi.

[3] Soddisfazione della policy del peer. I metodi EAP possono supportare indicazioni di risultato, consentendo al peer di indicare al server EAP all'interno del metodo che ha autenticato con successo il server EAP, così come per il server di indicare che ha autenticato il peer. Tuttavia, un autenticatore pass-through non sarà consapevole che il peer ha accettato le credenziali offerte dal server EAP, a meno che queste informazioni non vengano fornite all'autenticatore tramite il protocollo AAA. L'autenticatore DOVREBBE interpretare la ricezione di un attributo chiave all'interno di un pacchetto Accept come un'indicazione che il peer ha autenticato con successo il server.

Tuttavia, è possibile che la policy di accesso del peer EAP non sia stata soddisfatta durante lo scambio EAP iniziale, anche se si è verificata un'autenticazione reciproca. Ad esempio, l'autenticatore EAP potrebbe non aver dimostrato l'autorizzazione ad agire sia nel ruolo peer che autenticatore. Di conseguenza, il peer potrebbe richiedere un'autenticazione aggiuntiva nella direzione inversa, anche se il peer ha fornito un'indicazione che il server EAP si è autenticato con successo presso di esso.