Aller au contenu principal

3.16. Extensible Authentication Protocol (EAP) Payload

3.16. Extensible Authentication Protocol (EAP) Payload​

Le Extensible Authentication Protocol payload, désigné EAP dans le présent document, permet d'authentifier les IKE SA à l'aide du protocole défini dans le RFC 3748 [EAP] et des extensions ultérieures à ce protocole. Lors de l'utilisation d'EAP, une méthode EAP appropriée doit être sélectionnée. De nombreuses méthodes ont été définies, spécifiant l'utilisation du protocole avec divers mécanismes d'authentification. Les types de méthodes EAP sont listés dans [EAP-IANA]. Un bref résumé du format EAP est inclus ici pour plus de clarté.

                    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 24 : Format du EAP payload

Le type de charge utile pour un EAP payload est quarante-huit (48).

                    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      | Identifier    |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      | Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 25 : Format du message EAP

  • Code (1 octet) - Indique si ce message est une Request (1), Response (2), Success (3) ou Failure (4).

  • Identifier (1 octet) - Utilisé dans PPP pour distinguer les messages rejoués des messages répétés. Comme dans IKE, EAP s'exécute sur un protocole fiable, l'Identifier n'a ici aucune fonction. Dans un message de réponse, cet octet DOIT être identique à l'identifiant de la requête correspondante.

  • Length (2 octets, entier non signé) - La longueur du message EAP. DOIT être inférieure de quatre à la Payload Length de la charge utile encapsulante.

  • Type (1 octet) - Présent uniquement si le champ Code est Request (1) ou Response (2). Pour les autres codes, la longueur du message EAP DOIT être de quatre octets et les champs Type et Type_Data NE DOIVENT PAS être présents. Dans un message Request (1), Type indique les données demandées. Dans un message Response (2), Type DOIT être soit Nak, soit correspondre au type de données demandées. Comme IKE transmet une indication d'identité de l'initiateur dans le premier message de l'échange IKE_AUTH, le répondant NE DEVRAIT PAS envoyer de requêtes d'identité EAP (type 1). L'initiateur PEUT toutefois répondre à de telles requêtes s'il les reçoit.

  • Type_Data (longueur variable) - Varie selon le Type de Request et la Response associée. Pour la documentation des méthodes EAP, voir [EAP].

Comme IKE transmet une indication d'identité de l'initiateur dans le premier message de l'échange IKE_AUTH, le répondant NE DEVRAIT PAS envoyer de requêtes d'identité EAP. L'initiateur PEUT toutefois répondre à de telles requêtes s'il les reçoit.

Dernière mise à jour le