5. Initial EAP Request/Response Types

Per determinare il metodo di autenticazione da utilizzare, all'inizio dell'autenticazione vengono inviati pacchetti EAP Request/Response. Questo documento definisce i tipi iniziali comuni a tutte le implementazioni EAP: Identity, Notification, Nak, MD5-Challenge, One-Time Password, Generic Token Card ed Expanded Nak. Gli altri tipi EAP sono definiti nei documenti dei metodi EAP. Tutte le implementazioni EAP DEVONO supportare Identity, Nak, MD5-Challenge, One-Time Password, Generic Token Card ed Expanded Nak.

I documenti dei metodi EAP DOVREBBERO indicare se il metodo supporta frammentazione, derivazione delle chiavi, autenticazione reciproca e indicazione di risultato. Queste proprietà sono descritte più dettagliatamente nella sezione 7.5.

5.1. Identity

5.1.1. Panoramica

Description

All'inizio dell'autenticazione, l'authenticator PUÒ inviare al peer un pacchetto EAP-Request di tipo Identity, richiedendo una Response alla EAP-Request Identity. A meno che il peer non conosca già la propria identità per altri mezzi (ad esempio l'ID del chiamante per un utente dial-up), il peer DOVREBBE rispondere con un pacchetto EAP-Response Identity contenente il proprio Network Access Identifier (NAI) [RFC2486]. In alcuni ambienti, l'authenticator PUÒ utilizzare la parte di dominio del NAI per instradare la richiesta di autenticazione (ad esempio in un proxy RADIUS [RFC2865]). Altri usi del NAI sono discussi in [RFC2486].

Se l'authenticator non avvia l'autenticazione inviando una EAP-Request Identity, il peer PUÒ inviare un EAP-Response Identity contenente la propria risposta al NAI dopo aver ricevuto la prima EAP-Request. Se all'inizio dell'autenticazione è richiesta un'autenticazione immediata del peer e l'identità del peer non è importante, l'authenticator PUÒ ignorare la EAP-Request Identity e inviare direttamente un altro tipo di EAP-Request (come MD5-Challenge).

Type

Type-Data

Il campo Type-Data PUÒ contenere un blocco di dati composto da testo visualizzato all'utente, invitandolo all'input. Questo testo DEVE essere rappresentato con caratteri ISO 10646 codificati in UTF-8 [ISO.10646]. L'authenticator DOVREBBE inviare la EAP-Request successiva immediatamente dopo aver ricevuto la EAP-Response del peer; un pacchetto EAP-Response di tipo 1 NON DOVREBBE causare la ripetizione dell'invio di una EAP-Request Identity.

Nelle implementazioni, i peer e gli authenticator DOVREBBERO rendere la coppia Request/Response Identity accessibile ai metodi di autenticazione, in modo che i metodi possano ottenere l'identità se necessario (ad esempio per i metodi tunneled).

5.1.2. Gestione dell'identità

In alcuni ambienti, l'indisponibilità o la scarsa presentazione delle informazioni di identità del peer (ad esempio, utilizzando il formato NAI ma senza includere informazioni sufficienti per identificare univocamente l'utente tra due peer) può causare un fallimento dell'autenticazione. I problemi di gestione dell'identità nelle distribuzioni EAP includono la selezione dell'identità e la protezione dell'identità.

Selezione dell'identità

All'instauazione del collegamento, il peer non conosce le capacità dell'authenticator e PUÒ utilizzare un'identità predefinita quando avvia l'autenticazione. Nei metodi basati su certificato, il certificato utilizzato rivela generalmente l'identità del peer. In metodi come EAP-TLS [RFC2716], EAP-TTLS [EAP-TTLS] e PEAP [PEAP], il certificato, il nome utente o l'identità anonima utilizzati POSSONO differire a ogni tentativo di autenticazione. Una volta che l'authenticator ha autenticato il peer, PUÒ fornire indicazioni sul nome utente o sul certificato che il peer dovrebbe utilizzare (ad esempio nel tunnel). Ciò può essere utilizzato come identità per un secondo tentativo di autenticazione dopo il fallimento della negoziazione dell'identità iniziale.

Protezione dell'identità

Prima del completamento dell'autenticazione EAP, l'identità del peer PUÒ essere esposta a terze parti. Per prevenire tale esposizione, i metodi EAP POSSONO supportare la protezione dell'identità (ad esempio tramite crittografia o identificatori anonimi). In EAP-TLS [RFC2716], l'identità può essere fornita all'interno del tunnel, proteggendola così dall'ascolto passivo. In EAP-TTLS [EAP-TTLS] e PEAP [PEAP], per l'handshake iniziale viene utilizzata un'identità anonima e l'identità reale viene fornita all'interno del tunnel.

5.2. Notification

Description

Un pacchetto EAP-Request o EAP-Response con valore di tipo Notification viene utilizzato per trasmettere un messaggio leggibile dall'uomo. Il peer PUÒ visualizzare questo messaggio all'utente o PUÒ registrarlo e/o presentarlo a un amministratore. L'authenticator PUÒ inviare una notifica per informare l'utente di qualcosa (ad esempio "Stai per essere disconnesso"). Il peer DOVREBBE rispondere con un pacchetto EAP-Response di valore Notification e PUÒ scegliere di non visualizzare il messaggio (o solo una parte di esso). Tuttavia, il messaggio DOVREBBE essere fornito con caratteri ISO 10646 codificati in UTF-8 [ISO.10646].

Se una richiesta di Notification viene inviata prima del completamento dell'autenticazione, il peer DOVREBBE inviare una risposta di Notification, anche se sceglie di non visualizzare il messaggio. Una notifica inviata dopo il completamento del processo di autenticazione EAP PUÒ essere ignorata dal peer e NON DEVE essere utilizzata per trasportare dati destinati a un altro metodo EAP.

Type

Type-Data

Messaggio di testo da visualizzare all'utente, in caratteri ISO 10646 codificati in UTF-8 [ISO.10646].

5.3. Nak

5.3.1. Legacy Nak

Description

Il peer invia un pacchetto EAP-Response con valore di tipo Nak per indicare all'authenticator il proprio disaccordo con la EAP-Request iniziale. Un NAK viene inviato solo in risposta a una EAP-Request e quando la risposta iniziale inviata non era un Nak, e dovrebbe apparire solo vicino all'inizio dell'autenticazione. In genere, un Nak viene inviato solo quando l'authenticator richiede un tipo di autenticazione non supportato dal peer, ma può anche essere inviato quando l'authenticator richiede un tipo di autenticazione supportato dal peer ma con dettagli di configurazione inaccettabili (ad esempio, il peer supporta il metodo ma il NAS non può fornire la qualità del servizio richiesta dal metodo). Alla ricezione di un Nak, l'authenticator PUÒ rispondere inviando il tipo di autenticazione suggerito dal peer nel Nak o inviando un'altra EAP-Request. I documenti dei metodi EAP POSSONO indicare se un metodo può essere negoziato (tramite Nak) o se è obbligatorio (ovvero deve essere implementato all'inizio dell'autenticazione).

Si noti che Nak è una funzionalità legacy di EAP con capacità di estensione limitata. I nuovi metodi di autenticazione DOVREBBERO utilizzare Expanded Nak (sezione 5.3.2), poiché Nak non può essere utilizzato per indicare disaccordo con un Expanded Type (sezione 5.3.2). Inoltre, alcuni metodi EAP sono progettati per essere negoziati anziché utilizzare Nak (ad esempio all'interno di metodi tunneled). Pertanto, si raccomanda di utilizzare Expanded Nak quando possibile.

Type

Type-Data

Nel Nak tradizionale, il campo Type-Data è composto da uno o più ottetti che indicano il tipo di autenticazione che il peer è disposto a utilizzare nella sua risposta iniziale. Ad esempio, se il peer riceve una richiesta MD5-Challenge (Tipo 4) ma supporta One-Time Password (Tipo 5) e Generic Token Card (Tipo 6), risponde con un Nak il cui campo Type-Data contiene i valori 5 e 6.

5.3.2. Expanded Nak

Description

Expanded Nak viene utilizzato per negoziare i tipi di metodo EAP. È simile a Nak ma utilizza il formato Expanded Type (vedere sezione 5.3.2). Expanded Nak può indicare disaccordo sia con tipi tradizionali che estesi.

Type

254

Type-Data

Per Expanded Nak, il campo Type-Data inizia con Vendor-Id e Vendor-Type (vedere sezione 5.3.2). Poiché Expanded Nak viene utilizzato per la negoziazione, il campo Vendor-Type viene utilizzato per indicare il tipo di metodo di autenticazione (tradizionale o esteso) che il peer è disposto a utilizzare. Il campo Vendor-Id viene utilizzato per indicare il fornitore. Ad esempio, se è stato richiesto un Expanded Type ma il peer preferisce utilizzare un altro metodo, i campi Vendor-Id e Vendor-Type di Expanded Nak dovrebbero indicare il metodo preferito dal peer.

5.4. MD5-Challenge

5.4.1. Panoramica

Description

Il tipo MD5-Challenge corrisponde al protocollo CHAP PPP [RFC1994] e fornisce un'autenticazione simile a CHAP in EAP. MD5-Challenge utilizza la funzione di hash MD5 [MD5] con una chiave condivisa per l'autenticazione. MD5-Challenge è il metodo EAP più ampiamente distribuito ed è implementato in molti access point wireless esistenti. MD5-Challenge fornisce autenticazione reciproca sulla chiave condivisa, ma non supporta la derivazione delle chiavi o il tunneling. MD5-Challenge non fornisce protezione dell'identità. MD5-Challenge è vulnerabile agli attacchi a dizionario.

L'implementazione specifica di MD5-Challenge si trova in [RFC1994] sezione 5. In EAP, i pacchetti MD5-Challenge vengono calcolati in modo simile a CHAP, con la differenza principale nella codifica dei campi Value-Size e Response. In EAP, Value-Size viene trasportato nel campo Value anziché come campo separato.

Type

Type-Data

Per EAP MD5-Challenge, il campo Type-Data contiene i campi Value-Size, Value e Name, formattati come segue.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value-Size

Un ottetto che indica la lunghezza del campo Value in ottetti.

Value

Questo campo contiene il valore hash o il valore challenge, la cui lunghezza è indicata dal campo Value-Size.

Name

Questo campo contiene il nome host o il nome utente del mittente. Questo campo DEVE contenere caratteri ISO 10646 codificati in UTF-8 [ISO.10646].

5.4.2. Note di implementazione

I pacchetti MD5-Challenge vengono calcolati come segue:

[1] L'authenticator invia un pacchetto EAP-Request al peer con il campo Type impostato su 4 (MD5-Challenge) e il campo Type-Data contenente un valore challenge.

[2] Sul peer, il valore hash MD5 viene calcolato utilizzando la chiave condivisa, l'Identifier del peer, il valore challenge e il campo Name come input. Il peer risponde con un pacchetto EAP-Response contenente il valore hash.

[3] L'authenticator verifica il valore hash e, se corrisponde, l'authenticator ha autenticato con successo il peer.

5.5. One Time Password (OTP)

Description

Il tipo One Time Password corrisponde al sistema di password monouso definito in [RFC2289]. Il tipo OTP consente l'autenticazione utilizzando password monouso, in cui ogni password viene utilizzata una sola volta. Questo metodo fornisce protezione contro gli attacchi di riproduzione, poiché per ogni tentativo di autenticazione viene utilizzata una password diversa. OTP non fornisce autenticazione reciproca né derivazione delle chiavi.

Type

Type-Data

Per il tipo OTP, il campo Type-Data contiene un blocco di dati composto da testo visualizzato all'utente, invitandolo all'input, seguito da uno spazio e quindi dalla password monouso. Questo testo DOVREBBE essere rappresentato con caratteri ISO 10646 codificati in UTF-8 [ISO.10646]. Il formato specifico del campo è descritto in [RFC2289].

5.6. Generic Token Card (GTC)

Description

Il tipo Generic Token Card viene utilizzato per supportare varie implementazioni di token card. Il tipo GTC consente all'authenticator di inviare una challenge al peer, che utilizza quindi la propria token card per calcolare la risposta. GTC non specifica i dettagli dell'implementazione della token card; piuttosto, supporta il passaggio della challenge/risposta da un server di autenticazione esterno al peer. GTC non fornisce autenticazione reciproca né derivazione delle chiavi.

Type

Type-Data

Per il tipo GTC, il campo Type-Data contiene un blocco di dati composto da testo visualizzato all'utente, invitandolo all'input, seguito da uno spazio e quindi dal valore generato dalla token card. Questo testo DOVREBBE essere rappresentato con caratteri ISO 10646 codificati in UTF-8 [ISO.10646].

5.7. Tipi Espansi (Expanded Types)

Descrizione

Poiché molti degli usi esistenti di EAP sono specifici di un fornitore, il Tipo di metodo Espanso (Expanded Type) è disponibile per consentire ai fornitori di supportare i propri Tipi Espansi non adatti all'uso generale.

Il Tipo Espanso è inoltre utilizzato per espandere lo spazio globale dei Tipi di Metodo oltre i 255 valori originali. Un Vendor-Id di 0 mappa i 255 possibili Tipi originali su uno spazio di 2^32-1 possibili Tipi. (Il Tipo 0 è utilizzato solo in una risposta Nak per indicare che non vi è un'alternativa accettabile).

Un'implementazione che supporta l'attributo Espanso DEVE trattare i Tipi EAP inferiori a 256 in modo equivalente, sia che appaiano come un singolo ottetto, sia che appaiano come il Vendor-Type a 32 bit all'interno di un Tipo Espanso il cui Vendor-Id è 0. I peer non in grado di interpretare il Tipo Espanso DEVONO inviare un Nak come descritto nella Sezione 5.3.1 e negoziare un metodo di autenticazione più adatto.

Un riepilogo del formato del Tipo Espanso è 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Vendor-Id (cont)            | Vendor-Type...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor-Type (cont)                 |  Vendor-Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

254 per il Tipo Espanso (Expanded Type)

Vendor-Id

Il Vendor-Id è di 3 ottetti e rappresenta il SMI Network Management Private Enterprise Code del fornitore in network byte order, come allocato da IANA. Un Vendor-Id di zero è riservato per l'uso da parte dell'IETF nel fornire uno spazio di Tipi EAP globale espanso.

Vendor-Type

Il campo Vendor-Type è di quattro ottetti e rappresenta il tipo di metodo specifico del fornitore.

Se il Vendor-Id è zero, il campo Vendor-Type è un'estensione e un superset dello spazio dei nomi esistente per i Tipi EAP. I primi 256 Tipi sono riservati per la compatibilità con i Tipi EAP a singolo ottetto che sono già stati assegnati o potrebbero esserlo in futuro. Pertanto, i Tipi EAP da 0 a 255 sono semanticamente identici, sia che appaiano come Tipi EAP a singolo ottetto, sia che appaiano come Vendor-Type quando il Vendor-Id è zero. Vi è un'eccezione a questa regola: i pacchetti Expanded Nak e Legacy Nak condividono lo stesso Type, ma devono essere trattati in modo diverso poiché hanno un formato differente.

Vendor-Data

Il campo Vendor-Data è definito dal fornitore. Quando è presente un Vendor-Id di zero, il campo Vendor-Data sarà utilizzato per trasportare i contenuti dei metodi EAP di Tipi definiti dall'IETF.

5.8. Sperimentale (Experimental)

Descrizione

Il Tipo Sperimentale (Experimental Type) non ha formato o contenuto fisso. È destinato all'uso quando si sperimentano nuovi Tipi EAP. Questo Tipo è inteso per scopi sperimentali e di test. Non viene fornita alcuna garanzia di interoperabilità tra peer che utilizzano questo Tipo, come delineato in [RFC3692].

Type

255

Type-Data

Non definito (Undefined)