2.16. Extensible Authentication Protocol Methods (Metodi EAP)

2.16. Extensible Authentication Protocol Methods (Metodi EAP)

Oltre a firme a chiave pubblica e segreti condivisi, IKE supporta metodi definiti in RFC 3748 [EAP]. Spesso asimmetrici (utente verso server), possono non essere reciproci. Di solito autenticano l'iniziatore verso il rispondente e DEVONO essere usati insieme all'autenticazione del rispondente verso l'iniziatore basata su firma a chiave pubblica.

Questo documento cita [EAP] per aggiungere metodi senza aggiornare la specifica; qui si documentano varianti semplici. [EAP] richiede un numero variabile di messaggi. L'autenticazione estensibile in IKE sono scambi IKE_AUTH aggiuntivi che DEVONO completarsi per inizializzare l'IKE SA.

L'iniziatore indica EAP omettendo AUTH dal primo messaggio IKE_AUTH. Con IDi senza AUTH dichiara identità senza provarla. Se il rispondente accetta EAP, mette payload EAP nella risposta IKE_AUTH e ritarda SAr2, TSi, TSr fino all'autenticazione successiva dell'iniziatore.

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 in 2.2, con EAP ogni coppia di messaggi iniziali incrementa il numero; prima coppia IKE_AUTH ID 1, seconda 2, ecc.

Se il metodo EAP crea un segreto condiviso, quel segreto DEVE essere usato da entrambi per AUTH nei messaggi 7 e 8 come in 2.15. Il campo è MSK nella specifica EAP. Questo segreto generato durante IKE NON DEVE servire ad altri scopi.

Metodi EAP che non stabiliscono chiave condivisa NON DOVREBBERO essere usati: vulnerabili a MITM [EAPMITM] in altri protocolli senza tunnel autenticato dal server. Se usati, AUTH in 7 e 8 DEVONO usare SK_pi e SK_pr rispettivamente.

L'iniziatore con EAP DEVE poter estendere lo scambio iniziale ad almeno dieci scambi IKE_AUTH (notifiche, ripetizione prompt). Dopo successo EAP, il rispondente DEVE inviare payload EAP Success; in caso di fallimento Failure. Il rispondente PUÒ terminare in qualsiasi momento con Failure.

Dopo tale scambio esteso, i payload AUTH EAP DEVONO comparire nei due messaggi dopo quello con Success.

Con EAP, IDi può servire solo a routing AAA e scelta metodo, diverso dall'identità autenticata da EAP. Policy e controllo accesso DEVONO usare l'identità realmente autenticata. Spesso il server EAP è su server AAA separato; l'identità autenticata, se diversa da IDi, DEVE essere inviata dall'AAA al rispondente IKEv2.