2. Extensible Authentication Protocol (EAP)

Lo scambio di autenticazione EAP si svolge nel seguente modo:

[1] L'authenticator invia una Request per autenticare il peer. Questa Request contiene un campo Type che indica ciò che viene richiesto. Esempi di tipi di Request includono Identity, MD5-challenge, ecc. Il tipo MD5-challenge è molto simile al protocollo di autenticazione CHAP [RFC1994]. In genere, l'authenticator invia una Identity Request iniziale; tuttavia, la Identity Request iniziale non è obbligatoria e può essere omessa. Ad esempio, l'identità potrebbe non essere richiesta nei casi in cui è determinata dalla porta a cui il peer è connesso (linea dedicata, centralino privato o porta dial-up), o ottenuta tramite altri mezzi (tramite identificazione del chiamante o indirizzo MAC, nel campo Name della MD5-Challenge Response, ecc.).

[2] Il peer invia un pacchetto Response in risposta a una Request valida. Come il pacchetto Request, il pacchetto Response contiene un campo Type corrispondente al campo Type della Request.

[3] L'authenticator invia una Request aggiuntiva, a cui il peer risponde con una Response. La sequenza di Request e Response continua finché necessario. Poiché EAP è un protocollo "passo dopo passo" (lock step), non può essere inviata una nuova Request prima di ricevere una Response valida (ad eccezione della Request iniziale). L'authenticator è responsabile della ritrasmissione delle Request come descritto nella sezione 4.1. Dopo un numero appropriato di ritrasmissioni, l'authenticator deve terminare la conversazione EAP. Durante una ritrasmissione, o in mancanza di risposta dal peer, l'authenticator NON DEVE inviare pacchetti Success o Failure.

[4] La conversazione continua finché l'authenticator non è in grado di autenticare il peer (risposta inaccettabile a una o più Request), nel qual caso l'implementazione DEVE inviare un EAP Failure (Code 4). In alternativa, la conversazione di autenticazione può continuare finché l'authenticator non determina che il peer è stato autenticato con successo, nel qual caso l'authenticator DEVE inviare un EAP Success (Code 3).

Vantaggi:

o Il protocollo EAP può supportare più meccanismi di autenticazione senza dover negoziare in anticipo un meccanismo specifico.

o I dispositivi NAS (Network Access Server, come switch o access point) non hanno bisogno di comprendere ogni metodo di autenticazione e POSSONO fungere da proxy pass-through per un server di autenticazione backend. Il supporto del pass-through è opzionale. L'authenticator può autenticare il peer localmente pur fungendo da pass-through per peer remoti e metodi di autenticazione che non implementa localmente.

o La separazione tra authenticator e server di autenticazione backend semplifica la gestione delle credenziali e le decisioni di policy.

Svantaggi:

o Quando utilizzato in PPP, EAP richiede l'aggiunta di un nuovo tipo di autenticazione al PPP LCP, modificando così le implementazioni PPP per utilizzarlo. Si discosta inoltre dal precedente modello di autenticazione PPP che negoziava un meccanismo di autenticazione specifico durante il LCP. Analogamente, le implementazioni di switch o access point devono supportare [IEEE-802.1X] per utilizzare EAP.

o Nei casi in cui l'authenticator è separato dal server di autenticazione backend, l'analisi di sicurezza è complicata, così come la distribuzione delle chiavi quando necessaria.

2.1. Supporto per le sequenze

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

Una volta che il peer ha inviato una Response dello stesso Tipo della Request iniziale, l'authenticator NON DEVE inviare una Request di tipo diverso (ad eccezione di una Notification-Request) prima del completamento del turno finale del metodo specifico, e NON DEVE inviare alcuna Request di metodo aggiuntivo di alcun Tipo dopo il completamento del metodo di autenticazione iniziale; il peer che riceve tale Request DEVE considerarla non valida e scartarla silenziosamente. Di conseguenza, la richiesta di identità ripetuta non è supportata.

Il peer NON DEVE inviare un Nak (tradizionale o esteso) in risposta a una Request dopo aver inviato una Response iniziale non Nak. Poiché pacchetti EAP Request contraffatti possono essere inviati da un attaccante, l'authenticator che riceve un Nak inatteso DOVREBBE scartarlo e registrare l'evento.

A causa della vulnerabilità agli attacchi man-in-the-middle (vedere sezione 7.4) e dell'incompatibilità con le implementazioni esistenti, l'uso di più metodi di autenticazione in una conversazione EAP non è supportato.

Nel caso in cui venga utilizzato un singolo metodo di autenticazione EAP, ma all'interno di tale metodo vengano eseguiti altri metodi (metodi "tunneled"), il divieto di più metodi di autenticazione non si applica. Tali metodi "tunneled" appaiono come un singolo metodo di autenticazione per EAP. Poiché i peer che non supportano i metodi "tunneled" possono rispondere con un Nak alla EAP-Request iniziale (tradizionale o estesa), può essere fornita la compatibilità con le versioni precedenti. Per risolvere la vulnerabilità di sicurezza, i metodi "tunneled" DEVONO supportare la protezione contro gli attacchi man-in-the-middle.

2.2. Modello di multiplexing EAP

Concettualmente, un'implementazione EAP è composta dai seguenti componenti:

[a] Livello inferiore. Il livello inferiore è responsabile del trasporto e della ricezione dei frame EAP tra peer e authenticator. EAP funziona su più livelli inferiori, inclusi PPP, LAN cablate IEEE 802 [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. Il livello EAP riceve e invia pacchetti EAP tramite il livello inferiore, implementa il rilevamento duplicati e la ritrasmissione, e distribuisce e riceve messaggi EAP dai e verso i livelli peer e authenticator EAP.

[c] Livelli peer e authenticator EAP. Il livello EAP demultiplexa i pacchetti EAP in arrivo verso i livelli peer e authenticator EAP in base al campo Code. In genere, un'implementazione EAP su un host dato supporterà una delle funzioni peer o authenticator, ma un host può anche agire simultaneamente come peer e authenticator EAP. In tale implementazione, sia il livello peer EAP che il livello authenticator EAP saranno presenti.

[d] Livello del metodo EAP. Il metodo EAP implementa l'algoritmo di autenticazione e invia/riceve messaggi EAP tramite i livelli peer e authenticator EAP. Poiché EAP non supporta la frammentazione, questa è responsabilità del metodo EAP, discusso nella sezione 5.

Il modello di multiplexing EAP è illustrato di seguito. Si noti che l'implementazione non è tenuta a conformarsi a questo modello purché il comportamento su cavo sia coerente con esso.

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

Figure 1: EAP Multiplexing Model

In EAP, il campo Code svolge un ruolo simile al 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 con Code=1 (Request), 3 (Success) e 4 (Failure) vengono consegnati al livello peer EAP (se implementato). I pacchetti EAP con Code=2 (Response) vengono consegnati al livello authenticator EAP (se implementato).

In EAP, il campo Type svolge un ruolo simile al numero di porta in UDP o TCP. Si presume che i livelli peer e authenticator EAP demultiplexino i pacchetti EAP in arrivo in base al Type e li consegnino solo al metodo EAP corrispondente a quel Type. Le implementazioni del metodo EAP su un host possono registrarsi per ricevere pacchetti dal livello peer o authenticator (o entrambi), a seconda del ruolo supportato.

Poiché i metodi di autenticazione EAP potrebbero voler accedere all'identità, le implementazioni DOVREBBERO rendere la Request e la Response Identity accessibili ai metodi di autenticazione (Tipo 4 o superiore), ad eccezione del metodo Identity. Il tipo Identity è discusso nella sezione 5.1.

La Notification Response viene utilizzata solo per confermare che il peer ha ricevuto la Notification Request, non per confermare che ha elaborato il messaggio o lo ha visualizzato all'utente. Il contenuto della Notification Request o Response non è garantito essere disponibile per altri metodi. Il tipo Notification è discusso nella sezione 5.2.

Nak (Tipo 3) o Expanded Nak (Tipo 254) vengono utilizzati per la negoziazione del metodo. Il peer risponde a una EAP Request iniziale di Tipo inaccettabile con una Nak Response (Tipo 3) o una Expanded Nak Response (Tipo 254). Il contenuto delle Nak Response(s) non è garantito essere disponibile per altri metodi. I tipi Nak sono discussi nella sezione 5.3.

I pacchetti EAP il cui Code è Success o Failure non contengono un campo Type e non vengono consegnati ai metodi EAP. Success e Failure sono discussi nella sezione 4.2.

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

2.3. Comportamento pass-through

Quando opera come "authenticator pass-through", l'authenticator esegue i controlli dei campi Code, Identifier e Length come descritto nella sezione 4.1. Inoltra i pacchetti EAP ricevuti dal peer e destinati al suo livello authenticator al server di autenticazione backend; i pacchetti ricevuti dal server di autenticazione backend e destinati al peer vengono inoltrati a quest'ultimo.

Un host che riceve un pacchetto EAP può fare solo una di tre cose: elaborarlo, scartarlo o inoltrarlo. La decisione di inoltro si basa generalmente solo sul controllo dei campi Code, Identifier e Length. L'implementazione di un authenticator pass-through DEVE essere in grado di inoltrare i pacchetti EAP con Code=2 (Response) ricevuti dal peer al server di autenticazione backend. DEVE inoltre essere in grado di ricevere pacchetti EAP dal server di autenticazione backend e inoltrare i pacchetti con Code=1 (Request), Code=3 (Success) e Code=4 (Failure) al peer.

A meno che l'authenticator non implementi localmente uno o più metodi di autenticazione che supportano il ruolo authenticator, i campi di intestazione del livello del metodo EAP (Type, Type-Data) non vengono controllati come parte della decisione di inoltro. Quando l'authenticator supporta metodi di autenticazione locali, può controllare il campo Type per decidere se elaborare il pacchetto stesso o inoltrarlo. Le implementazioni compatibili di authenticator pass-through DEVONO inoltrare per impostazione predefinita i pacchetti EAP di qualsiasi Tipo.

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 l'host non implementi il livello peer EAP, tali pacchetti vengono scartati silenziosamente. Analogamente, i pacchetti EAP ricevuti con Code=2 (Response) vengono demultiplexati dal livello EAP e consegnati al livello authenticator. Pertanto, a meno che l'host non implementi il livello authenticator EAP, tali pacchetti vengono scartati silenziosamente. Il comportamento di un "peer pass-through" non è definito in questo documento e i protocolli AAA come RADIUS [RFC3579] e Diameter [DIAM-EAP] non supportano tale comportamento.

Il modello di inoltro è illustrato nella figura 2.

Peer Pass-through Authenticator Authentication Server

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

Figure 2: Pass-through Authenticator

Per una sessione in cui l'authenticator agisce come pass-through, DEVE determinare il risultato dell'autenticazione esclusivamente sulla base dell'indicazione Accept/Reject inviata dal server di autenticazione backend; il risultato NON DEVE essere determinato dal contenuto dei pacchetti EAP incapsulati con l'indicazione Accept/Reject, né dall'assenza di tali pacchetti EAP incapsulati.

2.4. Funzionamento peer-to-peer

Poiché EAP è un protocollo peer-to-peer, può verificarsi un'autenticazione inversa indipendente e simultanea (a seconda delle capacità del livello inferiore). Entrambe le estremità del collegamento possono agire simultaneamente come authenticator e peer. In questo caso, entrambe le estremità devono implementare i livelli peer e authenticator EAP. Inoltre, le implementazioni del metodo EAP su entrambe le estremità devono supportare sia le funzioni authenticator che peer contemporaneamente.

Sebbene EAP supporti il funzionamento peer-to-peer, alcune implementazioni EAP, metodi, protocolli AAA e livelli di collegamento potrebbero non supportare questa funzionalità. Alcuni metodi EAP possono supportare l'autenticazione asimmetrica, richiedendo al peer un tipo di credenziali e all'authenticator un altro tipo. Gli host che supportano l'autenticazione peer-to-peer utilizzando tali metodi devono configurare entrambi i tipi di credenziali.

Ad esempio, EAP-TLS [RFC2716] è un protocollo client-server, che utilizza generalmente profili di certificati diversi per client e server. Ciò significa che gli host che supportano l'autenticazione peer utilizzando EAP-TLS devono implementare i livelli peer e authenticator EAP, supportare i ruoli peer e authenticator nell'implementazione EAP-TLS e configurare il certificato appropriato per ciascun ruolo.

I protocolli AAA come RADIUS/EAP [RFC3579] e Diameter EAP [DIAM-EAP] supportano solo il funzionamento "authenticator pass-through". Come descritto in [RFC3579] sezione 2.6.2, il server RADIUS risponde con un Access-Reject a un Access-Request che incapsula un pacchetto EAP-Request, Success o Failure. Pertanto, il funzionamento "peer pass-through" non è supportato.

Anche nel caso di utilizzo di un metodo che supporta l'autenticazione bidirezionale e l'indicazione di risultato, diverse considerazioni potrebbero richiedere due autenticazioni EAP (una in ogni direzione). Queste includono:

[1] Supporto della derivazione delle chiavi di sessione bidirezionali nel livello inferiore. I livelli inferiori come IEEE 802.11 potrebbero supportare solo la derivazione e la trasmissione unidirezionale delle chiavi di sessione temporanee. 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, entrambe le estremità possono inviare traffico multicast/broadcast, richiedendo così uno scambio di chiavi di gruppo unidirezionale in ogni direzione. A causa delle limitazioni di progettazione, ciò significa anche che è necessaria una derivazione di chiavi unicast e uno scambio di metodo EAP in ogni direzione.

[2] Supporto del "tie-breaking" nel livello inferiore. I livelli inferiori come la modalità ad hoc IEEE 802.11 non supportano il "tie-breaking", in cui due host che avviano reciprocamente l'autenticazione subirebbero una sola autenticazione. Ciò significa che anche se 802.11 supportasse lo scambio di chiavi di gruppo bidirezionale, potrebbero comunque verificarsi due autenticazioni in ogni direzione.

[3] Soddisfazione della policy del peer. Il metodo EAP può supportare l'indicazione di risultato, consentendo al peer di indicare all'interno del metodo di aver autenticato con successo il server EAP e al server di indicare di aver autenticato il peer. Tuttavia, a meno che tali informazioni non vengano fornite all'authenticator tramite un protocollo AAA, l'authenticator pass-through non saprà che il peer ha accettato le credenziali fornite dal server EAP. L'authenticator DOVREBBE interpretare la ricezione di un attributo chiave in un pacchetto Accept come indicazione che il peer ha autenticato con successo il server.

Tuttavia, anche in caso di autenticazione bidirezionale, la policy di accesso del peer potrebbe non essere soddisfatta durante lo scambio EAP iniziale. Ad esempio, l'authenticator EAP potrebbe non dimostrare l'autorizzazione ad agire simultaneamente nei ruoli peer e authenticator. Pertanto, anche se il peer fornisce un'indicazione di aver autenticato con successo il server EAP, potrebbe richiedere un'autenticazione aggiuntiva nella direzione opposta.