3. Comportamento del Livello Inferiore

3.1. Requisiti del Livello Inferiore (Lower Layer Requirements)

EAP fa le seguenti assunzioni sui livelli inferiori:

[1] Trasporto inaffidabile. In EAP, l'autenticatore ritrasmette le richieste che non hanno ancora ricevuto risposte in modo che EAP non presuma che i livelli inferiori siano affidabili. Poiché EAP definisce il proprio comportamento di ritrasmissione, è possibile (sebbene indesiderabile) che la ritrasmissione si verifichi sia nel livello inferiore che nel livello EAP quando EAP viene eseguito su un livello inferiore affidabile.

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 possono essere persi, causando timeout. È quindi auspicabile che le implementazioni migliorino la loro resilienza alla perdita di pacchetti EAP Success o Failure, come descritto nella Sezione 4.2.

[2] Rilevamento degli errori del livello inferiore. Sebbene EAP non presuma che il livello inferiore sia affidabile, si basa sul rilevamento degli errori del livello inferiore (ad es., CRC, Checksum, MIC, ecc.). I metodi EAP potrebbero non includere un MIC, o se lo fanno, potrebbe non essere calcolato su tutti i campi nel pacchetto EAP, come i campi Code, Identifier, Length o Type. Di conseguenza, senza rilevamento degli errori del livello inferiore, errori non rilevati potrebbero infiltrarsi nei campi di intestazione del livello EAP o del livello del metodo EAP, causando fallimenti di autenticazione.

Ad esempio, EAP TLS [RFC2716], che calcola il suo MIC solo sul campo Type-Data, considera i fallimenti di validazione MIC come un errore fatale. Senza rilevamento degli errori del livello inferiore, questo metodo e altri simili non funzioneranno in modo affidabile.

[3] Sicurezza del livello inferiore. EAP non richiede che i livelli inferiori forniscano servizi di sicurezza come riservatezza per pacchetto, autenticazione, integrità e protezione dalla ripetizione. Tuttavia, quando questi servizi di sicurezza sono disponibili, i metodi EAP che supportano la derivazione delle chiavi (vedere Sezione 7.2.1) possono essere utilizzati per fornire materiale di chiavi dinamico. Ciò rende possibile legare l'autenticazione EAP ai dati successivi e proteggere contro modifiche, spoofing o ripetizioni dei dati. Vedere Sezione 7.1 per i dettagli.

[4] MTU minima. EAP è in grado di funzionare su livelli inferiori che forniscono una dimensione MTU EAP di 1020 ottetti o superiore.

EAP non supporta la scoperta del MTU del percorso, e la frammentazione e il riassemblaggio non sono supportati da EAP, né dai metodi definiti in questa specifica: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) e expanded Nak Response (254) Types.

Tipicamente, il peer EAP ottiene informazioni sull'MTU EAP dai livelli inferiori e imposta la dimensione del frame EAP su un valore appropriato. Quando l'autenticatore opera in modalità pass-through, il server di autenticazione non ha un modo diretto per determinare l'MTU EAP e quindi si affida all'autenticatore per fornirgli queste 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 è garantita una MTU di 1500 ottetti per i frame di controllo (vedere [RFC1661], Sezione 6.1) potrebbero mancare di funzionalità di frammentazione e riassemblaggio.

I metodi EAP possono assumere una MTU EAP minima di 1020 ottetti in assenza di altre informazioni. I metodi EAP DOVREBBERO includere il supporto per la frammentazione e il riassemblaggio se i loro payload possono essere più grandi di questa MTU EAP minima.

EAP è un protocollo lock-step, che implica 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), può essere preferibile che la frammentazione e il riassemblaggio si verifichino nel livello inferiore piuttosto che in EAP. Ciò può essere realizzato fornendo un MTU EAP artificialmente grande a EAP, causando la gestione della frammentazione e del riassemblaggio all'interno del livello inferiore.

[5] Possibile duplicazione. Quando il livello inferiore è affidabile, fornirà al livello EAP un flusso di pacchetti non duplicati. Tuttavia, sebbene sia auspicabile che i livelli inferiori forniscano la non-duplicazione, questo non è un requisito. Il campo Identifier fornisce sia al peer che all'autenticatore la capacità di rilevare i duplicati.

[6] Garanzie di ordinamento. EAP non richiede che l'Identifier sia monotonicamente crescente e quindi si basa sulle garanzie di ordinamento del livello inferiore per un funzionamento corretto. EAP è stato originariamente definito per funzionare su PPP, e [RFC1661] Sezione 1 ha un requisito di ordinamento:

"Il protocollo point-to-point è progettato per collegamenti semplici che trasportano pacchetti tra due peer. Questi collegamenti forniscono un'operazione bidirezionale simultanea full-duplex e si presume che consegnino i pacchetti in ordine."

I trasporti di livello inferiore per EAP DEVONO preservare l'ordine tra una sorgente e una destinazione a un dato livello di priorità (la garanzia di ordine fornita da [IEEE-802]).

Il riordino, se si verifica, tipicamente comporterà un fallimento dell'autenticazione EAP, causando la riesecuzione dell'autenticazione EAP. In un ambiente in cui il riordino è probabile, è quindi previsto che i fallimenti dell'autenticazione EAP saranno comuni. È RACCOMANDATO che EAP venga eseguito solo su livelli inferiori che forniscono garanzie di ordine; l'esecuzione di EAP su trasporto IP o UDP grezzo NON è RACCOMANDATA. L'incapsulamento di EAP all'interno di RADIUS [RFC3579] soddisfa i requisiti di ordine, poiché RADIUS è un protocollo "lock-step" che consegna i pacchetti in ordine.

3.2. Utilizzo di EAP all'interno di PPP (EAP Usage Within PPP)

Per stabilire comunicazioni su un collegamento point-to-point, ciascuna estremità del collegamento PPP invia prima pacchetti LCP per configurare il collegamento dati durante la fase di stabilimento del collegamento. Dopo che il collegamento è stato stabilito, PPP prevede una fase di autenticazione opzionale prima di procedere alla fase del protocollo di livello rete.

Per impostazione predefinita, l'autenticazione non è obbligatoria. Se si desidera l'autenticazione del collegamento, un'implementazione DEVE specificare l'opzione di configurazione del protocollo di autenticazione durante la fase di stabilimento del collegamento.

Se l'identità del peer è stata stabilita nella fase di autenticazione, il server può utilizzare tale identità nella selezione delle opzioni per le negoziazioni del livello rete successive.

Quando implementato all'interno di PPP, EAP non seleziona un meccanismo di autenticazione specifico nella fase di controllo del collegamento PPP, ma piuttosto rinvia questo fino alla fase di autenticazione. Ciò consente all'autenticatore di richiedere ulteriori informazioni prima di determinare il meccanismo di autenticazione specifico. Ciò consente anche l'uso di un server "backend" che effettivamente implementa i vari meccanismi mentre l'autenticatore PPP semplicemente passa attraverso lo scambio di autenticazione. Le fasi di stabilimento del collegamento e autenticazione PPP e l'opzione di configurazione del protocollo di autenticazione sono definite nel protocollo point-to-point (PPP) [RFC1661].

3.2.1. Formato dell'Opzione di Configurazione PPP (PPP Configuration Option Format)

Segue un riepilogo del formato dell'opzione di configurazione del protocollo di autenticazione PPP per negoziare EAP. I campi vengono trasmessi da sinistra a destra.

Esattamente un pacchetto EAP è incapsulato nel campo Information di un frame di livello data link PPP dove il campo di 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 (Tipo)

Length (Lunghezza)

Authentication Protocol (Protocollo di Autenticazione)

C227 (Hex) per Extensible Authentication Protocol (EAP)

3.3. Utilizzo di EAP all'interno di IEEE 802 (EAP Usage Within IEEE 802)

L'incapsulamento di EAP su IEEE 802 è definito in [IEEE-802.1X]. L'incapsulamento IEEE 802 di EAP non coinvolge PPP e IEEE 802.1X non include il supporto per le negoziazioni di livello collegamento o rete. Di conseguenza, all'interno di IEEE 802.1X, non è possibile negoziare meccanismi di autenticazione non-EAP, come PAP o CHAP [RFC1994].

3.4. Indicazioni del Livello Inferiore (Lower Layer Indications)

L'affidabilità e la sicurezza delle indicazioni del livello inferiore dipendono dal livello inferiore. Poiché EAP è indipendente dal mezzo, la presenza o l'assenza di sicurezza del livello inferiore non viene presa in considerazione nell'elaborazione dei messaggi EAP.

Per migliorare l'affidabilità, se un peer riceve un'indicazione di successo del livello inferiore come definito nella Sezione 7.2, PUÒ concludere che un pacchetto Success è stato perso e comportarsi come se avesse effettivamente ricevuto un pacchetto Success. Ciò include la scelta di ignorare il Success in alcune circostanze come descritto nella Sezione 4.2.

Una discussione di alcuni problemi di affidabilità e sicurezza con le indicazioni del livello inferiore in PPP, reti cablate IEEE 802 e LAN wireless IEEE 802.11 può essere trovata nelle Considerazioni sulla Sicurezza, Sezione 7.12.

Dopo che l'autenticazione EAP è completata, il peer trasmetterà e riceverà tipicamente dati tramite l'autenticatore. È auspicabile fornire garanzia che le entità che trasmettono dati siano le stesse che hanno completato con successo l'autenticazione EAP. Per realizzare ciò, è necessario che il livello inferiore fornisca integrità per pacchetto, autenticazione e protezione dalla ripetizione, e leghi questi servizi per pacchetto alle chiavi derivate durante l'autenticazione EAP. Altrimenti, è possibile che il traffico dati successivo venga modificato, spoofato o ripetuto.

Quando il materiale di chiavi per la suite di cifratura del livello inferiore è esso stesso fornito da EAP, la negoziazione della suite di cifratura e l'attivazione della chiave sono controllate dal livello inferiore. In PPP, le suite di cifratura sono negoziate all'interno di ECP in modo che non sia possibile utilizzare chiavi derivate dall'autenticazione EAP fino al completamento di ECP. Pertanto, uno scambio EAP iniziale non può essere protetto da una suite di cifratura PPP, sebbene una ri-autenticazione EAP possa essere protetta.

Nei media IEEE 802, l'attivazione iniziale della chiave si verifica tipicamente anche dopo il completamento dell'autenticazione EAP. Pertanto uno scambio EAP iniziale tipicamente non può essere protetto dalla suite di cifratura del livello inferiore, sebbene uno scambio di ri-autenticazione o pre-autenticazione EAP possa essere protetto.