2.16. Metodi del Protocollo di Autenticazione Estensibile
2.16. Metodi del Protocollo di Autenticazione Estensibile
Oltre all'autenticazione che usa firme a chiave pubblica e segreti condivisi, IKE supporta l'autenticazione usando i metodi definiti in RFC 3748 [EAP]. Tipicamente, questi metodi sono asimmetrici (progettati per un utente che si autentica presso un server), e potrebbero non essere mutui. Per questa ragione, questi protocolli sono tipicamente usati per autenticare l'iniziatore presso il risponditore e DEVONO essere usati congiuntamente con un'autenticazione basata su firma a chiave pubblica del risponditore presso l'iniziatore. Questi metodi sono spesso associati a meccanismi indicati come meccanismi di "Legacy Authentication".
Sebbene questo documento referenzi [EAP] con l'intento che nuovi metodi possano essere aggiunti in futuro senza aggiornare questa specifica, alcune variazioni più semplici sono documentate qui. [EAP] definisce un protocollo di autenticazione che richiede un numero variabile di messaggi. L'autenticazione estensibile è implementata in IKE come scambi IKE_AUTH aggiuntivi che DEVONO essere completati per inizializzare la IKE SA.
Un iniziatore indica il desiderio di usare EAP omettendo il payload AUTH dal primo messaggio dello scambio IKE_AUTH. (Notare che il payload AUTH è richiesto per l'autenticazione non-EAP, e quindi non è marcato come opzionale nel resto di questo documento.) Includendo un payload IDi ma non un payload AUTH, l'iniziatore ha dichiarato un'identità ma non l'ha provata. Se il risponditore è disposto a usare un metodo EAP, posizionerà un payload EAP (Extensible Authentication Protocol) nella risposta dello scambio IKE_AUTH e differirà l'invio di SAr2, TSi, e TSr finché l'autenticazione dell'iniziatore non sia completata in uno scambio IKE_AUTH successivo. Nel caso di un metodo EAP minimale, l'instaurazione iniziale della SA apparirà come segue:
Initiator Responder
HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr }
Come descritto nella sezione 2.2, quando EAP è usato, il numero di messaggio di ciascuna coppia di messaggi di setup iniziale IKE SA sarà incrementato; la prima coppia di messaggi AUTH avrà ID 1, la seconda sarà 2, e così via.
Per i metodi EAP che creano una chiave condivisa come effetto collaterale dell'autenticazione, quella chiave condivisa DEVE essere usata sia dall'iniziatore che dal risponditore per generare i payload AUTH nei messaggi 7 e 8 usando la sintassi per i segreti condivisi specificata nella sezione 2.15. La chiave condivisa da EAP è il campo della specifica EAP chiamato MSK. Questa chiave condivisa generata durante uno scambio IKE NON DEVE essere usata per alcun altro scopo.
I metodi EAP che non stabiliscono una chiave condivisa NON DOVREBBERO essere usati, poiché sono soggetti a una serie di attacchi man-in-the-middle [EAPMITM] se questi metodi EAP sono usati in altri protocolli che non usano un tunnel autenticato dal server. Si prega di vedere la sezione Considerazioni di Sicurezza per maggiori dettagli. Se sono usati metodi EAP che non generano una chiave condivisa, i payload AUTH nei messaggi 7 e 8 DEVONO essere generati usando rispettivamente SK_pi e SK_pr.
L'iniziatore di una IKE SA che usa EAP ha bisogno di essere capace di estendere lo scambio di protocollo iniziale ad almeno dieci scambi IKE_AUTH nel caso in cui il risponditore invii messaggi di notifica e/o ritenti il prompt di autenticazione. Una volta che lo scambio di protocollo definito dal metodo di autenticazione EAP scelto è terminato con successo, il risponditore DEVE inviare un payload EAP contenente il messaggio Success. Similmente, se il metodo di autenticazione è fallito, il risponditore DEVE inviare un payload EAP contenente il messaggio Failure. Il risponditore PUÒ in qualsiasi momento terminare lo scambio IKE inviando un payload EAP contenente il messaggio Failure.
Seguendo tale scambio esteso, i payload EAP AUTH DEVONO essere inclusi nei due messaggi seguenti quello contenente il messaggio EAP Success.
Quando l'autenticazione dell'iniziatore usa EAP, è possibile che il contenuto del payload IDi sia usato solo per scopi di Autenticazione, Autorizzazione e Accounting (AAA) e per selezionare quale metodo EAP usare. Questo valore può essere diverso dall'identità autenticata dal metodo EAP. È importante che le ricerche di policy e le decisioni di controllo d'accesso usino l'identità realmente autenticata. Spesso il server EAP è implementato in un server AAA separato che comunica con il risponditore IKEv2. In questo caso, l'identità autenticata, se diversa da quella nel payload IDi, deve essere inviata dal server AAA al risponditore IKEv2.