Passa al contenuto principale

3.16. Payload EAP

3.16. Payload EAP​

Il payload EAP (Extensible Authentication Protocol) viene utilizzato per trasportare messaggi EAP in IKEv2, per supportare l'autenticazione basata su metodi EAP (come EAP-TLS, EAP-SIM, ecc.).

Il formato del payload EAP è il seguente:

                 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ EAP Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 21: Formato del payload EAP

o EAP Message (lunghezza variabile) - Contenuto del messaggio EAP, come definito in RFC 3748.

Quando si utilizza EAP in IKEv2, il processo di autenticazione è il seguente:

  1. L'iniziatore invia un payload EAP vuoto (o un payload AUTH senza EAP) nella richiesta IKE_AUTH.
  2. Il risponditore invia il primo messaggio EAP (solitamente EAP-Request/Identity) nella risposta IKE_AUTH.
  3. L'iniziatore invia il messaggio EAP-Response in un successivo scambio INFORMATIONAL.
  4. Questo processo continua finché il metodo EAP non viene completato.
  5. Una volta completato con successo l'EAP, l'iniziatore rispondente DEVE confermare in un messaggio INFORMATIONAL contenente un payload AUTH (se AUTH viene usato).

Nota: i metodi EAP vengono utilizzati per fornire un fattore di autenticazione aggiuntivo durante il processo di autenticazione IKEv2. Tuttavia, il payload AUTH dell'iniziatore (inviato dopo il completamento dell'EAP) protegge il metodo EAP stesso dagli attacchi man-in-the-middle.

Le implementazioni DEVONO supportare la ricezione e l'elaborazione dei payload EAP. Le implementazioni DOVREBBERO supportare almeno un metodo EAP.