Aller au contenu principal

4. Format du Paquet EAP

4. Format du Paquet EAP​

Un résumé du format du paquet EAP est présenté ci-dessous. Les champs sont transmis de gauche à droite.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+

Code

Le champ Code est d'un octet et identifie le type de paquet EAP. Les codes EAP sont attribués comme suit :

1 Request 2 Response 3 Success 4 Failure

Étant donné qu'EAP ne définit que les codes 1-4, les paquets EAP avec d'autres codes DOIVENT être silencieusement rejetés par les authentificateurs et les pairs.

Identifier (Identifiant)

Le champ Identifier est d'un octet et aide à associer les réponses aux requêtes.

Length (Longueur)

Le champ Length est de deux octets et indique la longueur, en octets, du paquet EAP incluant les champs Code, Identifier, Length et Data. Les octets en dehors de la plage du champ Length doivent être traités comme un remplissage de couche liaison de données et DOIVENT être ignorés à la réception. Un message avec le champ Length défini sur une valeur supérieure au nombre d'octets reçus DOIT être silencieusement rejeté.

Data (Données)

Le champ Data contient zéro ou plusieurs octets. Le format du champ Data est déterminé par le champ Code.

4.1. Request et Response​

Description

Le paquet Request (champ Code défini à 1) est envoyé par l'authentificateur au pair. Chaque Request a un champ Type qui sert à indiquer ce qui est demandé. Des paquets Request supplémentaires DOIVENT être envoyés jusqu'à ce qu'un paquet Response valide soit reçu, qu'un compteur de nouvelle tentative optionnel expire ou qu'une indication de défaillance de couche inférieure soit reçue.

Les Requests retransmises DOIVENT être envoyées avec la même valeur Identifier afin de les distinguer des nouvelles Requests. Le contenu du champ de données dépend du type de Request. Le pair DOIT envoyer un paquet Response en réponse à un paquet Request valide. Les Responses DOIVENT uniquement être envoyées en réponse à une Request valide et ne jamais être retransmises sur un minuteur.

Si un pair reçoit une Request dupliquée valide pour laquelle il a déjà envoyé une Response, il DOIT renvoyer sa Response originale sans retraiter la Request. Les Requests DOIVENT être traitées dans l'ordre dans lequel elles sont reçues, et DOIVENT être traitées jusqu'à leur achèvement avant d'inspecter la Request suivante.

Un résumé du format des paquets Request et Response suit. Les champs sont transmis de gauche à droite.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Code

1 pour Request 2 pour Response

Identifier (Identifiant)

Le champ Identifier est d'un octet. Le champ Identifier DOIT être le même si un paquet Request est retransmis en raison d'un délai d'expiration en attendant une Response. Toute nouvelle Request (non-retransmission) DOIT modifier le champ Identifier.

Le champ Identifier de la Response DOIT correspondre à celui de la Request actuellement en attente. Un authentificateur recevant une Response dont la valeur Identifier ne correspond pas à celle de la Request actuellement en attente DOIT silencieusement rejeter la Response.

Afin d'éviter toute confusion entre les nouvelles Requests et les retransmissions, la valeur Identifier choisie pour chaque nouvelle Request doit seulement être différente de la Request précédente, mais n'a pas besoin d'être unique dans la conversation. Une façon d'y parvenir est de commencer l'Identifier à une valeur initiale et de l'incrémenter pour chaque nouvelle Request. L'initialisation du premier Identifier avec un nombre aléatoire plutôt que de commencer à zéro est recommandée, car cela rend les attaques de séquence quelque peu plus difficiles.

Étant donné que l'espace Identifier est unique pour chaque session, les authentificateurs ne sont pas limités à seulement 256 conversations d'authentification simultanées. De même, avec la réauthentification, une conversation EAP peut se poursuivre sur une longue période de temps et n'est pas limitée à seulement 256 allers-retours.

Note d'implémentation : L'authentificateur est responsable de la retransmission des messages Request. Si le message Request est obtenu ailleurs (comme d'un serveur d'authentification backend), l'authentificateur devra alors sauvegarder une copie de la Request pour y parvenir. Le pair est responsable de la détection et de la gestion des messages Request en double avant de les traiter de quelque manière que ce soit, y compris en les transmettant à une partie externe. L'authentificateur est également responsable de rejeter les messages Response avec une valeur Identifier non correspondante avant d'agir sur eux de quelque manière que ce soit, y compris en les transmettant au serveur d'authentification backend pour vérification. Étant donné que l'authentificateur peut retransmettre avant de recevoir une Response du pair, l'authentificateur peut recevoir plusieurs Responses, chacune avec un Identifier correspondant. Jusqu'à ce qu'une nouvelle Request soit reçue par l'authentificateur, la valeur Identifier n'est pas mise à jour, de sorte que l'authentificateur transmet les Responses au serveur d'authentification backend, une à la fois.

Length (Longueur)

Le champ Length est de deux octets et indique la longueur du paquet EAP incluant les champs Code, Identifier, Length, Type et Type-Data. Les octets en dehors de la plage du champ Length doivent être traités comme un remplissage de couche liaison de données et DOIVENT être ignorés à la réception. Un message avec le champ Length défini sur une valeur supérieure au nombre d'octets reçus DOIT être silencieusement rejeté.

Type

Le champ Type est d'un octet. Ce champ indique le Type de Request ou Response. Un seul Type DOIT être spécifié pour chaque Request ou Response EAP. Une spécification initiale des Types suit dans la Section 5 de ce document.

Le champ Type d'une Response DOIT soit correspondre à celui de la Request, soit correspondre à un Nak legacy ou Expanded (voir Section 5.3) indiquant qu'un Type de Request est inacceptable pour le pair. Un pair NE DOIT PAS envoyer un Nak (legacy ou expanded) en réponse à une Request, après qu'une Response non-Nak initiale a été envoyée. Un serveur EAP recevant une Response ne répondant pas à ces exigences DOIT silencieusement la rejeter.

Type-Data

Le champ Type-Data varie avec le Type de Request et la Response associée.

4.2. Success et Failure​

Le paquet Success est envoyé par l'authentificateur au pair après l'achèvement d'une méthode d'authentification EAP (Type 4 ou supérieur) pour indiquer que le pair s'est authentifié avec succès auprès de l'authentificateur. L'authentificateur DOIT transmettre un paquet EAP avec le champ Code défini à 3 (Success). Si l'authentificateur ne peut pas authentifier le pair (Responses inacceptables à une ou plusieurs Requests), alors après l'achèvement infructueux de la méthode EAP en cours, l'implémentation DOIT transmettre un paquet EAP avec le champ Code défini à 4 (Failure). Un authentificateur PEUT souhaiter émettre plusieurs Requests avant d'envoyer une réponse Failure afin de permettre les erreurs de frappe humaines. Les paquets Success et Failure NE DOIVENT PAS contenir de données supplémentaires.

Les paquets Success et Failure NE DOIVENT PAS être envoyés par un authentificateur EAP si la spécification de la méthode donnée ne permet pas explicitement à la méthode de se terminer à ce point. Une implémentation pair EAP recevant un paquet Success ou Failure où l'envoi d'un tel paquet n'est pas explicitement autorisé DOIT le rejeter silencieusement. Par défaut, un pair EAP DOIT silencieusement rejeter un paquet Success "en conserve" (un paquet Success envoyé immédiatement après la connexion). Cela garantit qu'un authentificateur malveillant ne pourra pas contourner l'authentification mutuelle en envoyant un paquet Success avant la conclusion de la conversation de méthode EAP.

Note d'implémentation : Étant donné que les paquets Success et Failure ne sont pas acquittés, ils ne sont pas retransmis par l'authentificateur et peuvent potentiellement être perdus. Un pair DOIT permettre cette circonstance comme décrit dans cette note. Voir également la Section 3.4 pour des conseils sur le traitement des indications de succès et d'échec de la couche inférieure.

Comme décrit dans la Section 2.1, une seule méthode d'authentification EAP est autorisée au sein d'une conversation EAP. Les méthodes EAP peuvent implémenter des indications de résultat. Après que l'authentificateur envoie une indication de résultat d'échec au pair, quelle que soit la réponse du pair, il DOIT ensuite envoyer un paquet Failure. Après que l'authentificateur envoie une indication de résultat de succès au pair et reçoit une indication de résultat de succès du pair, il DOIT ensuite envoyer un paquet Success.

Sur le pair, une fois que la méthode se termine sans succès (c'est-à-dire soit l'authentificateur envoie une indication de résultat d'échec, soit le pair décide qu'il ne veut pas continuer la conversation, éventuellement après avoir envoyé une indication de résultat d'échec), le pair DOIT terminer la conversation et indiquer l'échec à la couche inférieure. Le pair DOIT silencieusement rejeter les paquets Success et PEUT silencieusement rejeter les paquets Failure. En conséquence, la perte d'un paquet Failure n'a pas besoin de résulter en un délai d'attente.

Sur le pair, après que les indications de résultat de succès ont été échangées par les deux côtés, un paquet Failure DOIT être silencieusement rejeté. Le pair PEUT, dans le cas où un EAP Success n'est pas reçu, conclure que le paquet EAP Success a été perdu et que l'authentification s'est terminée avec succès.

Si l'authentificateur n'a pas envoyé d'indication de résultat, et que le pair est disposé à continuer la conversation, le pair attend un paquet Success ou Failure une fois que la méthode est terminée, et NE DOIT PAS rejeter silencieusement l'un ou l'autre. Dans le cas où ni un paquet Success ni un paquet Failure n'est reçu, le pair DEVRAIT terminer la conversation pour éviter de longs délais d'attente au cas où le paquet perdu était un EAP Failure.

Si le pair tente de s'authentifier auprès de l'authentificateur et échoue, l'authentificateur DOIT envoyer un paquet Failure et NE DOIT PAS accorder l'accès en envoyant un paquet Success. Cependant, un authentificateur PEUT omettre de faire authentifier le pair auprès de lui dans des situations où un accès limité est offert (par exemple, accès invité). Dans ce cas, l'authentificateur DOIT envoyer un paquet Success.

Lorsque le pair s'authentifie avec succès auprès de l'authentificateur, mais que l'authentificateur n'envoie pas d'indication de résultat, l'authentificateur PEUT refuser l'accès en envoyant un paquet Failure lorsque le pair n'est actuellement pas autorisé pour l'accès réseau.

Un résumé du format des paquets Success et Failure est présenté ci-dessous. Les champs sont transmis de gauche à droite.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

3 pour Success 4 pour Failure

Identifier (Identifiant)

Le champ Identifier est d'un octet et aide à associer les réponses aux Responses. Le champ Identifier DOIT correspondre au champ Identifier du paquet Response auquel il est envoyé en réponse.

Length (Longueur)

4

4.3. Comportement de Retransmission (Retransmission Behavior)​

Étant donné que le processus d'authentification impliquera souvent une saisie utilisateur, certaines précautions doivent être prises lors de la décision des stratégies de retransmission et des délais d'authentification. Par défaut, lorsque EAP est exécuté sur une couche inférieure non fiable, le minuteur de retransmission EAP DEVRAIT être estimé dynamiquement. Un maximum de 3-5 retransmissions est suggéré.

Lorsqu'il est exécuté sur une couche inférieure fiable (par exemple, EAP sur ISAKMP/TCP, comme dans [PIC]), le minuteur de retransmission de l'authentificateur DEVRAIT être défini à une valeur infinie, de sorte que les retransmissions ne se produisent pas au niveau de la couche EAP. Le pair peut toujours maintenir une valeur de délai d'attente afin d'éviter d'attendre indéfiniment une Request.

Lorsque le processus d'authentification nécessite une saisie utilisateur, les temps d'aller-retour mesurés peuvent être déterminés par la réactivité de l'utilisateur plutôt que par les caractéristiques du réseau, de sorte que l'estimation dynamique du RTO peut ne pas être utile. Au lieu de cela, le minuteur de retransmission DEVRAIT être défini de manière à fournir un temps suffisant à l'utilisateur pour répondre, avec des délais plus longs requis dans certains cas, comme lorsque des cartes à jeton (voir Section 5.6) sont impliquées.

Afin de fournir à l'authentificateur EAP des indications sur la valeur de délai d'attente appropriée, un indice peut être communiqué à l'authentificateur par le serveur d'authentification backend (comme via l'attribut RADIUS Session-Timeout).

Afin d'estimer dynamiquement le minuteur de retransmission EAP, les algorithmes pour l'estimation de SRTT, RTTVAR et RTO décrits dans [RFC2988] sont RECOMMANDÉS, y compris l'utilisation de l'algorithme de Karn, avec les modifications potentielles suivantes :

[a] Afin d'éviter les comportements de synchronisation qui peuvent se produire avec des minuteurs fixes parmi les systèmes distribués, le minuteur de retransmission est calculé avec une gigue en utilisant la valeur RTO et en ajoutant aléatoirement une valeur tirée entre -RTOmin/2 et RTOmin/2. Des calculs alternatifs pour créer de la gigue PEUVENT être utilisés. Ceux-ci DOIVENT être pseudo-aléatoires. Pour une discussion sur la génération de nombres pseudo-aléatoires, voir [RFC1750].

[b] Lorsque EAP est transporté sur une liaison unique (par opposition à sur Internet), des valeurs plus petites de RTOinitial, RTOmin et RTOmax PEUVENT être utilisées. Les valeurs recommandées sont RTOinitial=1 seconde, RTOmin=200ms et RTOmax=20 secondes.

[c] Lorsque EAP est transporté sur une liaison unique (par opposition à sur Internet), les estimations PEUVENT être effectuées par authentificateur, plutôt que par session. Cela permet à l'estimation de retransmission de tirer le meilleur parti des informations sur le comportement de la couche liaison.

[d] Une implémentation EAP PEUT effacer SRTT et RTTVAR après avoir reculé le minuteur plusieurs fois, car il est probable que les SRTT et RTTVAR actuels soient erronés dans cette situation. Une fois que SRTT et RTTVAR sont effacés, ils devraient être initialisés avec le prochain échantillon RTT pris comme décrit dans l'équation 2.2 de [RFC2988].

Dernière mise à jour le