4. EAP Packet Format

Un résumé du format de 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      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

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

     Request
     Response
     Success
     Failure

Puisque EAP ne définit que les codes 1-4, les paquets EAP avec d'autres codes DOIVENT être ignorés silencieusement par l'authenticator et le peer.

Identifier

Le champ Identifier est un octet et aide à mettre en correspondance les réponses avec les requêtes.

Length

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 du remplissage de la couche de liaison de données et DOIVENT être ignorés à la réception. Un message dont le champ Length est supérieur au nombre d'octets reçus DOIT être ignoré silencieusement.

Data

Le champ Data est composé de 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 sur 1) est envoyé par l'authenticator au peer. Chaque Request possède un champ Type qui sert à indiquer ce qui est demandé. D'autres paquets Request DOIVENT être envoyés jusqu'à ce qu'une Response valide soit reçue, qu'un compteur de tentatives optionnel expire, ou qu'une indication d'erreur soit reçue de la couche inférieure.

Les Request retransmises DOIVENT être envoyées avec la même valeur d'Identifier afin de les distinguer des nouvelles Request. Le contenu du champ data dépend du type de Request. Le peer DOIT envoyer un paquet Response en réponse à un paquet Request valide. Les Response ne DOIVENT être envoyées qu'en réponse à une Request valide et NE DOIVENT JAMAIS être retransmises sur un temporisateur.

Si un peer reçoit une Request valide en double pour laquelle il a déjà envoyé une Response, il DOIT renvoyer sa Response originale sans retraiter la Request. Les Request DOIVENT être traitées dans l'ordre de leur réception et DOIVENT être traitées jusqu'à achèvement avant d'examiner 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      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   1 for Request
   2 for Response

Identifier

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

Le champ Identifier de la Response DOIT correspondre à celui de la Request actuellement en attente. Un authenticator recevant une Response dont la valeur Identifier ne correspond pas à la Request actuellement en attente DOIT l'ignorer silencieusement.

Pour éviter la confusion entre nouvelles Request et retransmissions, la valeur Identifier choisie pour chaque nouvelle Request doit seulement être différente de la Request précédente, mais ne doit pas être unique au sein de la conversation. Une façon d'y parvenir consiste à démarrer l'Identifier à partir d'une valeur initiale et à l'incrémenter pour chaque nouvelle Request. Il est recommandé d'initialiser le premier Identifier avec un nombre aléatoire plutôt que de partir de zéro, car cela rend les attaques de séquence légèrement plus difficiles.

Puisque l'espace Identifier est unique pour chaque session, l'authenticator n'est pas limité à seulement 256 conversations d'authentification simultanées. De même, avec la ré-authentification, une conversation EAP pourrait se poursuivre sur une longue période et n'est pas limitée à seulement 256 allers-retours.

Note d'implémentation : L'authenticator est responsable de la retransmission des messages Request. Si le message Request est obtenu ailleurs (comme à partir d'un serveur d'authentification backend), alors l'authenticator devra sauvegarder une copie de la Request pour pouvoir le faire. Le peer 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 de les transmettre à une tierce partie. L'authenticator est en outre responsable de l'ignorance silencieuse des messages Response dont la valeur Identifier ne correspond pas avant d'agir sur eux de quelque manière que ce soit, y compris de les transmettre au serveur d'authentification backend pour vérification. Puisque l'authenticator peut retransmettre avant de recevoir une Response du peer, l'authenticator peut recevoir plusieurs Response, chacune avec un Identifier correspondant. Jusqu'à ce qu'une nouvelle Request soit reçue de l'authenticator, la valeur Identifier n'est pas mise à jour, ainsi l'authenticator transmet les Response au serveur d'authentification backend, une à la fois.

Length

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 du remplissage de la couche de liaison de données et DOIVENT être ignorés à la réception. Un message dont le champ Length est supérieur au nombre d'octets reçus DOIT être ignoré silencieusement.

Type

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

Le champ Type de la Response DOIT correspondre à celui de la Request, ou correspondre à un Nak hérité ou étendu (voir la section 5.3) qui indique qu'un type de Request n'est pas acceptable pour le peer. Un peer NE DOIT PAS envoyer un Nak (hérité ou étendu) en réponse à une Request, après qu'une Response initiale non-Nak a été envoyée. Un serveur EAP recevant une Response ne satisfaisant pas ces exigences DOIT l'ignorer silencieusement.

Type-Data

Le champ Type-Data varie avec le type de Request et la Response correspondante.

4.2. Success et Failure

Le paquet Success est envoyé par l'authenticator au peer après l'achèvement d'une méthode d'authentification EAP (type 4 ou supérieur) pour indiquer que le peer a été authentifié avec succès auprès de l'authenticator. L'authenticator DOIT transmettre un paquet EAP avec le champ Code défini sur 3 (Success). Si l'authenticator ne peut pas authentifier le peer (réponses inacceptables à une ou plusieurs Request), alors après l'échec de la méthode EAP en cours, l'implémentation DOIT transmettre un paquet EAP avec le champ Code défini sur 4 (Failure). Un authenticator peut souhaiter émettre plusieurs Request avant d'envoyer une réponse Failure pour permettre des erreurs de saisie humaine. 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 authenticator EAP si la spécification de la méthode donnée ne permet pas explicitement que la méthode se termine à ce point. Une implémentation peer EAP recevant un paquet Success ou Failure dont l'envoi n'est pas explicitement permis DOIT l'ignorer silencieusement. Par défaut, un peer EAP DOIT ignorer silencieusement un paquet Success « canned » (un paquet Success envoyé immédiatement à l'ouverture de la connexion). Cela garantit qu'un authenticator malveillant ne soit pas en mesure de contourner l'authentification mutuelle en envoyant un paquet Success avant la fin de la conversation de la méthode EAP.

Note d'implémentation : Puisque les paquets Success et Failure ne sont pas acquittés, ils ne sont pas retransmis par l'authenticator et pourraient potentiellement être perdus. Un peer DOIT tenir compte de cette circonstance comme décrit dans cette note. Voir également la section 3.4 pour les lignes directrices sur le traitement des indications de succès et d'échec de la couche inférieure.

Comme décrit à la section 2.1, au sein d'une conversation EAP, une seule méthode d'authentification EAP est autorisée. Les méthodes EAP peuvent implémenter des indications de résultat. Après que l'authenticator a envoyé une indication de résultat d'échec au peer, indépendamment de la réponse du peer, il DOIT ensuite envoyer un paquet Failure. Après que l'authenticator a envoyé une indication de résultat de succès au peer et a reçu une indication de résultat de succès du peer, il DOIT ensuite envoyer un paquet Success.

Côté peer, une fois la méthode terminée sans succès (c'est-à-dire, l'authenticator envoie une indication de résultat d'échec, ou le peer décide de ne pas vouloir poursuivre la conversation, probablement après avoir envoyé une indication de résultat d'échec), le peer DOIT terminer la conversation et indiquer l'échec à la couche inférieure. Le peer DOIT ignorer silencieusement les paquets Success et PEUT ignorer silencieusement les paquets Failure. Par conséquent, la perte d'un paquet Failure n'entraîne pas nécessairement un dépassement de temps.

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

Si l'authenticator n'a pas envoyé d'indication de résultat et que le peer est disposé à poursuivre la conversation, le peer attend un paquet Success ou Failure une fois la méthode terminée, et NE DOIT PAS les ignorer silencieusement. Dans le cas où ni un paquet Success ni un paquet Failure n'est reçu, le peer DEVRAIT terminer la conversation pour éviter de longs dépassements de temps dans le cas où le paquet perdu serait un EAP Failure.

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

Lorsque le peer s'authentifie avec succès auprès de l'authenticator, mais que l'authenticator n'envoie pas d'indication de résultat, l'authenticator PEUT refuser l'accès en envoyant un paquet Failure dans les cas où le peer n'est pas actuellement 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      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   3 for Success
   4 for Failure

Identifier

Le champ Identifier est un octet et aide à mettre en correspondance les réponses avec les réponses. Le champ Identifier DOIT correspondre au champ Identifier du paquet Response auquel il est envoyé en réponse.

Length

4.3. Comportement de retransmission

Puisque le processus d'authentification impliquera souvent la saisie par l'utilisateur, un certain soin doit être pris dans 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 temporisateur 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 temporisateur de retransmission de l'authenticator DEVRAIT être réglé sur une valeur infinie, de sorte que les retransmissions n'aient pas lieu à la couche EAP. Le peer peut toujours maintenir une valeur de délai d'attente pour éviter d'attendre indéfiniment une Request.

Lorsque le processus d'authentification nécessite la saisie par l'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 pourrait ne pas être utile. Au lieu de cela, le temporisateur de retransmission DEVRAIT être réglé pour fournir suffisamment de temps à l'utilisateur pour répondre, des délais plus longs étant requis dans certains cas, comme lorsque des cartes à jeton sont impliquées (voir la section 5.6).

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

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

[a] Afin d'éviter les comportements de synchronisation qui peuvent se produire avec des temporisateurs fixes entre systèmes distribués, le temporisateur de retransmission est calculé avec un jitter en utilisant la valeur RTO et en ajoutant aléatoirement une valeur extraite entre -RTOmin/2 et RTOmin/2. D'autres calculs peuvent être utilisés pour créer du jitter. 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 un seul lien (plutôt que sur Internet), des valeurs plus petites de RTOinitial, RTOmin et RTOmax peuvent être utilisées. Les valeurs suggérées sont RTOinitial=1 seconde, RTOmin=200ms et RTOmax=20 secondes.

[c] Lorsque EAP est transporté sur un seul lien (plutôt que sur Internet), les estimations PEUVENT être faites sur une base par-authenticator, plutôt que sur une base par-session. Cela permet à l'estimation de retransmission d'utiliser au maximum les informations sur le comportement de la couche de liaison.

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