4. Formato del Pacchetto EAP

Un riepilogo del formato del pacchetto EAP è mostrato di seguito. I campi vengono 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 (Codice)

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

1 Request 2 Response 3 Success 4 Failure

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

Identifier (Identificatore)

Il campo Identifier è di un ottetto e aiuta ad abbinare le risposte alle richieste.

Length (Lunghezza)

Il campo Length è di due ottetti e indica la lunghezza, in ottetti, del pacchetto EAP inclusi i campi Code, Identifier, Length e Data. Gli ottetti al di fuori dell'intervallo del campo Length devono essere trattati come padding del livello data link 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 (Dati)

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

4.1. Request e Response

Descrizione

Il pacchetto Request (campo Code impostato a 1) viene inviato dall'autenticatore al peer. Ogni Request ha un campo Type che serve a indicare cosa viene richiesto. Pacchetti Request aggiuntivi DEVONO essere inviati fino a quando non viene ricevuto un pacchetto Response valido, scade un contatore di tentativi opzionale o viene ricevuta un'indicazione di guasto del livello inferiore.

Le Requests ritrasmesse DEVONO essere inviate con lo stesso valore Identifier per distinguerle dalle nuove Requests. Il contenuto del campo dati dipende dal tipo di Request. Il peer DEVE inviare un pacchetto Response in risposta a un pacchetto Request valido. Le Responses 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 rinviare la sua Response originale senza rielaborare la Request. Le Requests DEVONO essere elaborate nell'ordine in cui vengono ricevute e DEVONO essere elaborate fino al loro completamento prima di ispezionare la Request successiva.

Un riepilogo del formato dei pacchetti Request e Response segue. I campi vengono 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 (Codice)

1 per Request 2 per Response

Identifier (Identificatore)

Il campo Identifier è di un ottetto. Il campo Identifier DEVE essere lo stesso se un pacchetto Request viene 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 autenticatore 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 Requests e ritrasmissioni, il valore Identifier scelto per ogni nuova Request deve solo essere diverso dalla Request precedente, ma non deve essere univoco all'interno della conversazione. Un modo per ottenere ciò è iniziare l'Identifier con un valore iniziale e incrementarlo per ogni nuova Request. L'inizializzazione del primo Identifier con un numero casuale anziché iniziare da zero è raccomandata, poiché rende gli attacchi di sequenza un po' più difficili.

Poiché lo spazio Identifier è unico per ogni sessione, gli autenticatori non sono limitati a sole 256 conversazioni di autenticazione simultanee. Allo stesso modo, con la riautenticazione, una conversazione EAP potrebbe continuare per un lungo periodo di tempo e non è limitata a soli 256 andata e ritorno.

Nota di implementazione: L'autenticatore è responsabile della ritrasmissione dei messaggi Request. Se il messaggio Request viene ottenuto da altrove (come da un server di autenticazione backend), l'autenticatore dovrà salvare una copia della Request per farlo. Il peer è responsabile del rilevamento e della gestione dei messaggi Request duplicati prima di elaborarli in qualsiasi modo, incluso il passaggio a una parte esterna. L'autenticatore è anche responsabile dello scarto dei messaggi Response con un valore Identifier non corrispondente prima di agire su di essi in qualsiasi modo, incluso il passaggio al server di autenticazione backend per la verifica. Poiché l'autenticatore può ritrasmettere prima di ricevere una Response dal peer, l'autenticatore può ricevere più Responses, ciascuna con un Identifier corrispondente. Fino a quando una nuova Request non viene ricevuta dall'autenticatore, il valore Identifier non viene aggiornato, in modo che l'autenticatore inoltra le Responses al server di autenticazione backend, una alla volta.

Length (Lunghezza)

Il campo Length è di due ottetti e indica la lunghezza del pacchetto EAP inclusi i campi Code, Identifier, Length, Type e Type-Data. Gli ottetti al di fuori dell'intervallo del campo Length devono essere trattati come padding del livello data link 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 (Tipo)

Il campo Type è di un ottetto. Questo campo indica il tipo di Request o Response. Un singolo Type DEVE essere specificato per ogni 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, o corrispondere a un Nak legacy o Expanded (vedere Sezione 5.3) indicando che un Type di Request è inaccettabile per il peer. Un peer NON DEVE inviare un Nak (legacy o expanded) in risposta a una Request, dopo che è stata inviata una Response non-Nak iniziale. Un server EAP che riceve una Response che non soddisfa questi requisiti DEVE scartarla silenziosamente.

Type-Data

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

4.2. Success e Failure

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

I pacchetti Success e Failure NON DEVONO essere inviati da un autenticatore EAP se la specifica del metodo dato non consente esplicitamente al metodo di terminare 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 "in scatola" (un pacchetto Success inviato immediatamente alla connessione). Ciò garantisce che un autenticatore malevolo non sarà in grado di aggirare l'autenticazione reciproca inviando un pacchetto Success prima della conclusione della conversazione del metodo EAP.

Nota di implementazione: Poiché i pacchetti Success e Failure non sono riconosciuti, non vengono ritrasmessi dall'autenticatore e possono essere potenzialmente persi. Un peer DEVE consentire questa circostanza come descritto in questa nota. Vedere anche la Sezione 3.4 per la guida sull'elaborazione delle indicazioni di successo e fallimento del livello inferiore.

Come descritto nella Sezione 2.1, è consentito solo un singolo metodo di autenticazione EAP all'interno di una conversazione EAP. I metodi EAP possono implementare indicazioni di risultato. Dopo che l'autenticatore invia un'indicazione di risultato di fallimento al peer, indipendentemente dalla risposta dal peer, DEVE successivamente inviare un pacchetto Failure. Dopo che l'autenticatore 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.

Sul peer, una volta che il metodo si completa senza successo (cioè, o l'autenticatore invia un'indicazione di risultato di fallimento, o il peer decide che non vuole continuare la conversazione, possibilmente 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 risultare in un timeout.

Sul peer, dopo che le 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 un EAP Success non venga ricevuto, concludere che il pacchetto EAP Success è stato perso e che l'autenticazione si è conclusa con successo.

Se l'autenticatore non ha inviato un'indicazione di risultato e il peer è disposto a continuare la conversazione, il peer attende un pacchetto Success o Failure una volta completato il metodo e NON DEVE scartare silenziosamente nessuno dei due. Nel caso in cui né un pacchetto Success né un pacchetto Failure vengano ricevuti, 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 all'autenticatore e non riesce a farlo, l'autenticatore DEVE inviare un pacchetto Failure e NON DEVE concedere l'accesso inviando un pacchetto Success. Tuttavia, un autenticatore PUÒ omettere di far autenticare il peer a esso in situazioni in cui viene offerto un accesso limitato (ad es., accesso ospite). In questo caso, l'autenticatore DEVE inviare un pacchetto Success.

Quando il peer si autentica con successo all'autenticatore, ma l'autenticatore non invia un'indicazione di risultato, l'autenticatore PUÒ negare l'accesso inviando un pacchetto Failure quando il peer non è attualmente autorizzato per l'accesso alla rete.

Un riepilogo del formato dei pacchetti Success e Failure è mostrato di seguito. I campi vengono 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 (Codice)

3 per Success 4 per Failure

Identifier (Identificatore)

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

Length (Lunghezza)

4.3. Comportamento di Ritrasmissione (Retransmission Behavior)

Poiché il processo di autenticazione coinvolgerà spesso l'input dell'utente, è necessaria una certa attenzione quando si decidono le strategie di ritrasmissione e i timeout di autenticazione. Per impostazione predefinita, quando EAP viene eseguito su un livello inferiore inaffidabile, il timer di ritrasmissione EAP DOVREBBE essere stimato dinamicamente. È suggerito un massimo di 3-5 ritrasmissioni.

Quando viene eseguito su un livello inferiore affidabile (ad es., EAP su ISAKMP/TCP, come in [PIC]), il timer di ritrasmissione dell'autenticatore DOVREBBE essere impostato su un valore infinito, in modo che le ritrasmissioni non si verifichino al livello EAP. Il peer può comunque mantenere un valore di timeout per evitare di attendere indefinitamente una Request.

Quando 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 della rete, quindi 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 Cards (vedere Sezione 5.6).

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

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

[a] Per 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. Calcoli alternativi per creare jitter POSSONO essere utilizzati. Questi DEVONO essere pseudo-casuali. Per una discussione sulla generazione di numeri pseudo-casuali, vedere [RFC1750].

[b] Quando EAP viene trasportato su un singolo collegamento (invece che su Internet), valori più piccoli di RTOinitial, RTOmin e RTOmax POSSONO essere utilizzati. I valori raccomandati sono RTOinitial=1 secondo, RTOmin=200ms e RTOmax=20 secondi.

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

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