3. Lower Layer Behavior

3.1. Requisiti del livello inferiore

EAP fa le seguenti ipotesi sul livello inferiore:

[1] Trasporto inaffidabile. In EAP, l'authenticator ritrasmette le Request per le quali non ha ricevuto una Response, quindi EAP non presume che il livello inferiore sia affidabile. Poiché EAP definisce il proprio comportamento di ritrasmissione, quando EAP funziona su un livello inferiore affidabile, è possibile (sebbene non desiderabile) che si verifichino ritrasmissioni sia nel livello inferiore che nel livello EAP.

Si noti che i pacchetti EAP Success e Failure non vengono ritrasmessi. Senza un livello inferiore affidabile e con un tasso di errore non trascurabile, questi pacchetti potrebbero andare persi, causando un timeout. Pertanto, è opportuno che le implementazioni aumentino la loro resilienza alla perdita dei pacchetti EAP Success o Failure come descritto nella sezione 4.2.

[2] Rilevamento errori del livello inferiore. Sebbene EAP non presupponga che il livello inferiore sia affidabile, fa affidamento sul rilevamento errori del livello inferiore (come CRC, Checksum, MIC, ecc.). I metodi EAP potrebbero non includere un MIC, o anche se lo fanno, potrebbero non calcolarlo su tutti i campi del pacchetto EAP (come i campi Code, Identifier, Length o Type). Pertanto, senza rilevamento errori del livello inferiore, errori non rilevati potrebbero infiltrarsi nei campi di intestazione del livello EAP o del livello del metodo EAP, causando un fallimento dell'autenticazione.

Ad esempio, EAP TLS [RFC2716] calcola il suo MIC solo sul campo Type-Data e tratta l'errore di convalida del MIC come errore fatale. Senza rilevamento errori del livello inferiore, questo e metodi simili non funzionerebbero in modo affidabile.

[3] Sicurezza del livello inferiore. EAP non richiede che il livello inferiore fornisca servizi di sicurezza come riservatezza, autenticazione, integrità e protezione dalla riproduzione per pacchetto. Tuttavia, quando tali servizi di sicurezza sono forniti, i metodi EAP che supportano la derivazione delle chiavi (vedere sezione 7.2.1) possono essere utilizzati per fornire materiale chiave dinamico. Ciò consente di associare l'autenticazione EAP ai dati successivi e di prevenirne la modifica, lo spoofing o la riproduzione. Per i dettagli, vedere la sezione 7.1.

[4] MTU minima. EAP può funzionare su un livello inferiore che fornisce una dimensione MTU EAP di almeno 1020 ottetti.

EAP non supporta il path MTU discovery e la frammentazione e il riassemblaggio non sono supportati da EAP né dai metodi definiti in questo documento: i tipi Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) e expanded Nak Response (254).

In genere, il peer EAP ottiene informazioni sull'MTU EAP dal livello inferiore e imposta la dimensione del frame EAP su un valore appropriato. Quando l'authenticator opera in modalità pass-through, il server di autenticazione non ha alcun mezzo diretto per determinare l'MTU EAP e si affida all'authenticator per fornirgli tali informazioni, ad esempio tramite l'attributo Framed-MTU, come descritto in [RFC3579] sezione 2.4.

Sebbene metodi come EAP-TLS [RFC2716] supportino la frammentazione e il riassemblaggio, i metodi EAP originariamente progettati per l'uso in PPP (dove ai frame di controllo è garantita una MTU di 1500 ottetti, vedere [RFC1661] sezione 6.1) potrebbero non disporre della funzionalità di frammentazione e riassemblaggio.

In assenza di altre informazioni, un metodo EAP può presumere un MTU EAP minimo di 1020 ottetti. Se il payload di un metodo EAP è suscettibile di essere superiore a questo MTU EAP minimo, DOVREBBE includere il supporto per la frammentazione e il riassemblaggio.

Essendo EAP un protocollo "passo dopo passo" (lock step), vi è una certa inefficienza nella gestione della frammentazione e del riassemblaggio. Pertanto, se il livello inferiore supporta la frammentazione e il riassemblaggio (come quando EAP è trasportato su IP), potrebbe essere preferibile che la frammentazione e il riassemblaggio avvengano nel livello inferiore piuttosto che in EAP. Ciò può essere ottenuto fornendo a EAP un MTU EAP artificialmente più grande, in modo che la frammentazione venga gestita nel livello inferiore.

[5] Possibili duplicati. Nel caso di un livello inferiore affidabile, fornirà al livello EAP un flusso di pacchetti senza duplicati. Tuttavia, sebbene la fornitura di pacchetti senza duplicati sia auspicabile, non è un requisito. Il campo Identifier fornisce sia al peer che all'authenticator la capacità di rilevare duplicati.

[6] Garanzie di ordinamento. EAP non richiede che Identifier sia strettamente crescente, e pertanto fa affidamento sulle garanzie di ordinamento del livello inferiore per funzionare correttamente. EAP è stato inizialmente definito per funzionare su PPP e [RFC1661] sezione 1 contiene un requisito di ordinamento:

"Il Point-to-Point Protocol è progettato per collegamenti semplici tra due peer. Questi collegamenti forniscono operazioni bidirezionali simultanee full-duplex e si presuppone la consegna dei pacchetti in ordine."

Il trasporto del livello inferiore EAP DEVE mantenere l'ordine tra origine e destinazione a una priorità data (garanzie di ordinamento fornite da [IEEE-802]).

Se si verifica una riordinazione, ciò causerà generalmente un fallimento dell'autenticazione EAP, provocando la riesecuzione dell'autenticazione EAP. Pertanto, negli ambienti in cui una riordinazione può verificarsi, i fallimenti dell'autenticazione EAP sono destinati a essere comuni. Si raccomanda di eseguire EAP solo su livelli inferiori che forniscono garanzie di ordinamento; l'esecuzione di EAP su trasporto IP o UDP grezzo NON È CONSIGLIATA. L'incapsulamento di EAP in RADIUS [RFC3579] soddisfa il requisito di ordinamento, poiché RADIUS è un protocollo "passo dopo passo" che consegna i pacchetti in ordine.

3.2. Utilizzo di EAP in PPP

Per stabilire la comunicazione su un collegamento point-to-point, ogni estremità del collegamento PPP invia prima i pacchetti LCP per configurare il collegamento dati nella fase di instauazione del collegamento. Dopo l'instauazione del collegamento, PPP fornisce una fase di autenticazione opzionale prima di entrare nella fase del protocollo di livello di rete.

Per impostazione predefinita, l'autenticazione non è obbligatoria. Se l'autenticazione del collegamento è richiesta, l'implementazione DEVE specificare l'opzione di configurazione del protocollo di autenticazione nella fase di instauazione del collegamento.

Se l'identità del peer viene determinata durante la fase di autenticazione, il server può utilizzare tale identità nella scelta delle opzioni di negoziazione del livello di rete successivo.

Quando implementato in PPP, EAP non seleziona un meccanismo di autenticazione specifico durante la fase di controllo del collegamento, ma lo rinvia alla fase di autenticazione. Ciò consente all'authenticator di richiedere ulteriori informazioni prima di determinare un meccanismo di autenticazione specifico. Ciò consente inoltre l'utilizzo di un server "backend" che implementa effettivamente vari meccanismi, mentre l'authenticator PPP si limita a inoltrare lo scambio di autenticazione. La fase di instauazione e autenticazione del collegamento PPP, nonché l'opzione di configurazione del protocollo di autenticazione, sono definite nel Point-to-Point Protocol (PPP) [RFC1661].

3.2.1. Formato dell'opzione di configurazione PPP

Il formato dell'opzione di configurazione del protocollo di autenticazione PPP utilizzata per negoziare EAP è riepilogato di seguito. I campi vengono trasmessi da sinistra a destra.

Esattamente un pacchetto EAP è incapsulato nel campo Information del frame del livello di collegamento dati PPP, dove il campo Protocollo indica il tipo hex C227 (PPP EAP).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Authentication Protocol

C227 (esadecimale) per l'Extensible Authentication Protocol (EAP)

3.3. Utilizzo di EAP in IEEE 802

L'incapsulamento di EAP in IEEE 802 è definito in [IEEE-802.1X]. L'incapsulamento di EAP da parte di IEEE 802 non comporta PPP e IEEE 802.1X non contiene supporto per la negoziazione del livello di collegamento o di rete. Pertanto, in IEEE 802.1X non è possibile negoziare meccanismi di autenticazione non EAP, come PAP o CHAP [RFC1994].

3.4. Indicazioni del livello inferiore

L'affidabilità e la sicurezza delle indicazioni del livello inferiore dipendono dal livello inferiore. Poiché EAP è indipendente dal supporto, la presenza o l'assenza della sicurezza del livello inferiore non viene considerata durante l'elaborazione dei messaggi EAP.

Per migliorare l'affidabilità, se il peer riceve un'indicazione di successo del livello inferiore come definita nella sezione 7.2, PUÒ concludere che un pacchetto Success sia andato perso e comportarsi come se avesse effettivamente ricevuto il pacchetto Success. Ciò include l'ignorare il Success in alcuni casi come descritto nella sezione 4.2.

Una discussione su alcuni problemi di affidabilità e sicurezza delle indicazioni del livello inferiore in PPP, reti cablate IEEE 802 e LAN wireless IEEE 802.11 si trova nelle considerazioni di sicurezza, sezione 7.12.

Dopo il completamento dell'autenticazione EAP, il peer trasmette generalmente dati tramite l'authenticator. Ci si aspetta che vi sia una garanzia che l'entità che trasmette e riceve i dati sia la stessa che ha completato con successo l'autenticazione EAP. Per realizzare ciò, è necessario che il livello inferiore fornisca integrità, autenticazione e protezione dalla riproduzione per pacchetto, e associ tali servizi per pacchetto alle chiavi derivate durante l'autenticazione EAP. In caso contrario, il traffico dati successivo potrebbe essere modificato, falsificato o riprodotto.

Quando il materiale chiave del suite crittografico del livello inferiore è fornito dallo stesso EAP, la negoziazione del suite crittografico e l'attivazione della chiave sono controllate dal livello inferiore. In PPP, il suite crittografico viene negoziato in ECP, quindi è impossibile utilizzare le chiavi derivate dall'autenticazione EAP prima del completamento di ECP. Pertanto, lo scambio EAP iniziale non può essere protetto dal suite crittografico PPP, sebbene la riautenticazione EAP possa esserlo.

Nei supporti IEEE 802, l'attivazione della chiave iniziale si verifica generalmente anche dopo il completamento dell'autenticazione EAP. Pertanto, lo scambio EAP iniziale in genere non può essere protetto dal suite crittografico del livello inferiore, sebbene lo scambio di riautenticazione o pre-autenticazione EAP possa esserlo.