4. EAP Packet Format

Un riepilogo del formato del pacchetto EAP è mostrato di seguito. I campi sono trasmessi da sinistra a destra.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

Il campo Code è un ottetto e identifica il Tipo di pacchetto EAP. I codici EAP sono assegnati come segue:

     Request
     Response
     Success
     Failure

Poiché EAP definisce solo i codici 1-4, i pacchetti EAP con altri codici DEVONO essere scartati silenziosamente sia dagli authenticator che dai peer.

Identifier

Il campo Identifier è un ottetto e aiuta ad abbinare le Response alle Request.

Length

Il campo Length è di due ottetti e indica la lunghezza, in ottetti, del pacchetto EAP includendo i campi Code, Identifier, Length e Data. Gli ottetti al di fuori dell'intervallo del campo Length dovrebbero essere trattati come riempimento del livello di collegamento dati e DEVONO essere ignorati alla ricezione. Un messaggio con il campo Length impostato su un valore maggiore del numero di ottetti ricevuti DEVE essere scartato silenziosamente.

Data

Il campo Data è costituito da zero o più ottetti. Il formato del campo Data è determinato dal campo Code.

4.1. Request and Response

Description

Il pacchetto Request (campo Code impostato su 1) è inviato dall'authenticator al peer. Ogni Request ha un campo Type che serve a indicare ciò che viene richiesto. DEVONO essere inviati ulteriori pacchetti Request finché non viene ricevuto un pacchetto Response valido, non scade un contatore di tentativi opzionale, o non viene ricevuta un'indicazione di errore dal livello inferiore.

Le Request ritrasmesse DEVONO essere inviate con lo stesso valore di Identifier per distinguerle dalle nuove Request. Il contenuto del campo data dipende dal Request Type. Il peer DEVE inviare un pacchetto Response in risposta a un pacchetto Request valido. Le Response DEVONO essere inviate solo in risposta a una Request valida e non DEVONO mai essere ritrasmesse su un timer.

Se un peer riceve una Request duplicata valida per la quale ha già inviato una Response, DEVE reinviare la propria Response originale senza rielaborare la Request. Le Request DEVONO essere elaborate nell'ordine in cui vengono ricevute e DEVONO essere elaborate fino al completamento prima di esaminare la Request successiva.

Un riepilogo del formato dei pacchetti Request e Response segue. I campi sono trasmessi da sinistra a destra.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   1 for Request
   2 for Response

Identifier

Il campo Identifier è un ottetto. Il campo Identifier DEVE essere lo stesso se un pacchetto Request è ritrasmesso a causa di un timeout in attesa di una Response. Qualsiasi nuova Request (non ritrasmissione) DEVE modificare il campo Identifier.

Il campo Identifier della Response DEVE corrispondere a quello della Request attualmente in sospeso. Un authenticator che riceve una Response il cui valore Identifier non corrisponde a quello della Request attualmente in sospeso DEVE scartare silenziosamente la Response.

Per evitare confusione tra nuove Request e ritrasmissioni, il valore Identifier scelto per ciascuna nuova Request deve solo essere diverso dalla Request precedente, ma non deve essere univoco all'interno della conversazione. Un modo per ottenerlo è iniziare l'Identifier da un valore iniziale e incrementarlo per ogni nuova Request. Si raccomanda di inizializzare il primo Identifier con un numero casuale anziché partire da zero, poiché ciò rende gli attacchi di sequenza leggermente più difficili.

Poiché lo spazio Identifier è univoco per ogni sessione, agli authenticator non è limitato a sole 256 conversazioni di autenticazione simultanee. Analogamente, con la riautenticazione, una conversazione EAP potrebbe continuare per un lungo periodo di tempo e non è limitata a sole 256 andate e ritorno.

Implementation Note: L'authenticator è responsabile della ritrasmissione dei messaggi Request. Se il messaggio Request è ottenuto da altro luogo (come da un server di autenticazione backend), allora l'authenticator dovrà salvare una copia della Request per poterlo realizzare. Il peer è responsabile del rilevamento e della gestione dei messaggi Request duplicati prima di elaborarli in qualsiasi modo, incluso il passarli a una parte esterna. L'authenticator è inoltre responsabile dello scarto dei messaggi Response con un valore Identifier non corrispondente prima di agire su di essi in qualsiasi modo, incluso il passarli al server di autenticazione backend per la verifica. Poiché l'authenticator può ritrasmettere prima di ricevere una Response dal peer, l'authenticator può ricevere multiple Response, ciascuna con un Identifier corrispondente. Fino a quando non viene ricevuta una nuova Request dall'authenticator, il valore Identifier non viene aggiornato, così che l'authenticator inoltra le Response al server di autenticazione backend, una alla volta.

Length

Il campo Length è di due ottetti e indica la lunghezza del pacchetto EAP includendo i campi Code, Identifier, Length, Type e Type-Data. Gli ottetti al di fuori dell'intervallo del campo Length dovrebbero essere trattati come riempimento del livello di collegamento dati e DEVONO essere ignorati alla ricezione. Un messaggio con il campo Length impostato su un valore maggiore del numero di ottetti ricevuti DEVE essere scartato silenziosamente.

Type

Il campo Type è di un ottetto. Questo campo indica il Tipo di Request o Response. UN singolo Type DEVE essere specificato per ciascuna Request o Response EAP. Una specifica iniziale dei Types segue nella Sezione 5 di questo documento.

Il campo Type di una Response DEVE corrispondere a quello della Request, oppure corrispondere a una Nak legacy o estesa (vedere la Sezione 5.3) che indica che un Request Type non è accettabile per il peer. Un peer NON DEVE inviare una Nak (legacy o estesa) in risposta a una Request, dopo che è stata inviata una Response iniziale non-Nak. Un server EAP che riceve una Response che non soddisfa questi requisiti DEVE scartarla silenziosamente.

Type-Data

Il campo Type-Data varia con il Tipo di Request e la relativa Response.

4.2. Success and Failure

Il pacchetto Success è inviato dall'authenticator al peer dopo il completamento di un metodo di autenticazione EAP (Type 4 o superiore) per indicare che il peer è stato autenticato con successo presso l'authenticator. L'authenticator DEVE trasmettere un pacchetto EAP con il campo Code impostato su 3 (Success). Se l'authenticator non può autenticare il peer (Response inaccettabili a una o più Request), allora dopo il completamento non riuscito del metodo EAP in corso, l'implementazione DEVE trasmettere un pacchetto EAP con il campo Code impostato su 4 (Failure). Un authenticator PUÒ desiderare di emettere multiple Request prima di inviare una risposta Failure per consentire errori di digitazione umana. I pacchetti Success e Failure NON DEVONO contenere dati aggiuntivi.

I pacchetti Success e Failure NON DEVONO essere inviati da un authenticator EAP se la specifica del metodo dato non consente esplicitamente che il metodo termini in quel punto. Un'implementazione peer EAP che riceve un pacchetto Success o Failure dove l'invio non è esplicitamente consentito DEVE scartarlo silenziosamente. Per impostazione predefinita, un peer EAP DEVE scartare silenziosamente un pacchetto Success "canned" (un pacchetto Success inviato immediatamente all'apertura della connessione). Ciò garantisce che un authenticator rogue non sia in grado di aggirare l'autenticazione reciproca inviando un pacchetto Success prima della conclusione della conversazione del metodo EAP.

Implementation Note: Poiché i pacchetti Success e Failure non vengono confermati, non vengono ritrasmessi dall'authenticator e potrebbero andare potenzialmente persi. Un peer DEVE tenere conto di questa circostanza come descritto in questa nota. Vedere anche la Sezione 3.4 per le linee guida sul processamento delle indicazioni di successo e fallimento del livello inferiore.

Come descritto nella Sezione 2.1, all'interno di una conversazione EAP è consentito un solo metodo di autenticazione EAP. I metodi EAP possono implementare indicazioni di risultato. Dopo che l'authenticator invia un'indicazione di risultato di fallimento al peer, indipendentemente dalla risposta del peer, DEVE successivamente inviare un pacchetto Failure. Dopo che l'authenticator invia un'indicazione di risultato di successo al peer e riceve un'indicazione di risultato di successo dal peer, DEVE successivamente inviare un pacchetto Success.

Lato peer, una volta completato il metodo senza successo (ovvero, l'authenticator invia un'indicazione di risultato di fallimento, oppure il peer decide di non voler proseguire la conversazione, probabilmente dopo aver inviato un'indicazione di risultato di fallimento), il peer DEVE terminare la conversazione e indicare il fallimento al livello inferiore. Il peer DEVE scartare silenziosamente i pacchetti Success e PUÒ scartare silenziosamente i pacchetti Failure. Di conseguenza, la perdita di un pacchetto Failure non deve necessariamente comportare un timeout.

Lato peer, dopo che indicazioni di risultato di successo sono state scambiate da entrambe le parti, un pacchetto Failure DEVE essere scartato silenziosamente. Il peer PUÒ, nel caso in cui non venga ricevuto un EAP Success, concludere che il pacchetto EAP Success sia andato perso e che l'autenticazione sia terminata con successo.

Se l'authenticator non ha inviato un'indicazione di risultato e il peer è disposto a proseguire la conversazione, il peer attende un pacchetto Success o Failure una volta completato il metodo, e NON DEVE scartarli silenziosamente. Nel caso in cui non venga ricevuto né un pacchetto Success né un pacchetto Failure, il peer DOVREBBE terminare la conversazione per evitare lunghi timeout nel caso in cui il pacchetto perso fosse un EAP Failure.

Se il peer tenta di autenticarsi presso l'authenticator e non vi riesce, l'authenticator DEVE inviare un pacchetto Failure e NON DEVE concedere l'accesso inviando un pacchetto Success. Tuttavia, un authenticator PUÒ omettere di far autenticare il peer presso di esso in situazioni in cui è offerto un accesso limitato (ad esempio, accesso guest). In questo caso, l'authenticator DEVE inviare un pacchetto Success.

Laddove il peer autentica con successo presso l'authenticator, ma l'authenticator non invia un'indicazione di risultato, l'authenticator PUÒ negare l'accesso inviando un pacchetto Failure nei casi in cui il peer non è attualmente autorizzato per l'accesso di rete.

Un riepilogo del formato dei pacchetti Success e Failure è mostrato di seguito. I campi sono trasmessi da sinistra a destra.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   3 for Success
   4 for Failure

Identifier

Il campo Identifier è un ottetto e aiuta ad abbinare le risposte alle Response. Il campo Identifier DEVE corrispondere al campo Identifier del pacchetto Response a cui è inviato in risposta.

Length

4.3. Retransmission Behavior

Poiché il processo di autenticazione spesso comporterà l'input dell'utente, deve essere posta qualche cura nel decidere le strategie di ritrasmissione e i timeout di autenticazione. Per impostazione predefinita, laddove EAP è eseguito su un livello inferiore non affidabile, il timer di ritrasmissione EAP DOVREBBE essere stimato dinamicamente. È suggerito un massimo di 3-5 ritrasmissioni.

Quando è eseguito su un livello inferiore affidabile (ad esempio, EAP su ISAKMP/TCP, come in [PIC]), il timer di ritrasmissione dell'authenticator DOVREBBE essere impostato su un valore infinito, così che le ritrasmissioni non avvengano al livello EAP. Il peer può ancora mantenere un valore di timeout per evitare di attendere indefinitamente una Request.

Laddove il processo di autenticazione richiede l'input dell'utente, i tempi di andata e ritorno misurati possono essere determinati dalla reattività dell'utente piuttosto che dalle caratteristiche di rete, così che la stima dinamica del RTO potrebbe non essere utile. Invece, il timer di ritrasmissione DOVREBBE essere impostato in modo da fornire tempo sufficiente all'utente per rispondere, con timeout più lunghi richiesti in alcuni casi, come quando sono coinvolte Token Card (vedere la Sezione 5.6).

Al fine di fornire all'authenticator EAP una guida circa il valore di timeout appropriato, un suggerimento può essere comunicato all'authenticator dal server di autenticazione backend (come tramite l'attributo RADIUS Session-Timeout).

Al fine di stimare dinamicamente il timer di ritrasmissione EAP, sono RACCOMANDATI gli algoritmi per la stima di SRTT, RTTVAR e RTO descritti in [RFC2988], incluso l'uso dell'algoritmo di Karn, con le seguenti potenziali modifiche:

[a] Al fine di evitare comportamenti di sincronizzazione che possono verificarsi con timer fissi tra sistemi distribuiti, il timer di ritrasmissione è calcolato con un jitter utilizzando il valore RTO e aggiungendo casualmente un valore estratto tra -RTOmin/2 e RTOmin/2. Possono essere utilizzati calcoli alternativi per creare jitter. Questi DEVONO essere pseudo-casuali. Per una discussione sulla generazione di numeri pseudo-casuali, vedere [RFC1750].

[b] Quando EAP è trasportato su un singolo collegamento (anziché su Internet), possono essere utilizzati valori più piccoli di RTOinitial, RTOmin e RTOmax. I valori consigliati sono RTOinitial=1 secondo, RTOmin=200ms e RTOmax=20 secondi.

[c] Quando EAP è trasportato su un singolo collegamento (anziché su Internet), le stime POSSONO essere fatte su base per-authenticator, piuttosto che su base per-sessione. Ciò consente alla stima di ritrasmissione di fare il massimo uso delle informazioni sul comportamento del livello di collegamento.

[d] Un'implementazione EAP PUÒ cancellare SRTT e RTTVAR dopo aver ridotto il timer più volte, poiché è probabile che gli attuali SRTT e RTTVAR siano errati in questa situazione. Una volta cancellati SRTT e RTTVAR, essi dovrebbero essere inizializzati con il successivo campione RTT prelevato come descritto nell'equazione 2.2 di [RFC2988].