5. Initial EAP Request/Response Types
5. Initial EAP Request/Response Types
Pour déterminer la méthode d'authentification à utiliser, des paquets EAP Request/Response sont envoyés au début de l'authentification. Ce document définit les types initiaux communs à toutes les implémentations EAP : Identity, Notification, Nak, MD5-Challenge, One-Time Password, Generic Token Card et Expanded Nak. Les autres types EAP sont définis dans les documents de méthode EAP. Toutes les implémentations EAP DOIVENT prendre en charge Identity, Nak, MD5-Challenge, One-Time Password, Generic Token Card et Expanded Nak.
Les documents de méthode EAP DEVRAIENT indiquer si la méthode prend en charge la fragmentation, la dérivation de clés, l'authentification mutuelle et l'indication de résultat. Ces propriétés sont décrites plus en détail à la section 7.5.
5.1. Identity
5.1.1. Aperçu
Description
Au début de l'authentification, l'authenticateur PEUT envoyer un paquet EAP-Request de type Identity au homologue, demandant une Response au EAP-Request Identity. À moins que le homologue ne connaisse déjà son identifiant par d'autres moyens (par exemple l'ID d'appelant pour un utilisateur composé), le homologue DEVRAIT répondre par un paquet EAP-Response Identity contenant son Network Access Identifier (NAI) [RFC2486]. Dans certains environnements, l'authenticateur PEUT utiliser la partie domaine du NAI pour router la demande d'authentification (par exemple dans un proxy RADIUS [RFC2865]). D'autres utilisations du NAI sont discutées dans [RFC2486].
Si l'authenticateur ne démarre pas l'authentification en envoyant un EAP-Request Identity, le homologue PEUT envoyer un EAP-Response Identity contenant sa réponse au NAI après avoir reçu la première EAP-Request. Si une authentification immédiate du homologue est requise au début de l'authentification et que l'identité du homologue n'est pas importante, l'authenticateur PEUT contourner le EAP-Request Identity et envoyer directement un autre type de EAP-Request (comme MD5-Challenge).
Type
1
Type-Data
Le champ Type-Data PEUT contenir un bloc de données composé de texte affiché à l'utilisateur, l'invitant à saisir. Ce texte DOIT être représenté en caractères ISO 10646 encodés en UTF-8 [ISO.10646]. L'authenticateur DEVRAIT envoyer la EAP-Request suivante immédiatement après avoir reçu la EAP-Response du homologue ; un paquet EAP-Response de type 1 NE DEVRAIT PAS provoquer la réémission d'un EAP-Request Identity.
Dans les implémentations, les homologues et authenticateurs DEVRAIENT rendre la paire Request/Response Identity visible pour les méthodes d'authentification, afin que les méthodes puissent obtenir l'identité si nécessaire (par exemple pour les méthodes tunnelisées).
5.1.2. Gestion des identités
Dans certains environnements, l'indisponibilité ou la mauvaise présentation des informations d'identité du homologue (par exemple, en utilisant le format NAI mais sans inclure suffisamment d'informations pour identifier de manière unique l'utilisateur entre deux pairs) peut entraîner un échec d'authentification. Les problèmes de gestion des identités dans les déploiements EAP incluent la sélection d'identité et la protection d'identité.
Sélection d'identité
Lors de l'établissement de la liaison, le homologue ne connaît pas les capacités de l'authenticateur et PEUT utiliser une identité par défaut lors de l'initiation de l'authentification. Dans les méthodes basées sur certificat, le certificat utilisé révèle généralement l'identité du homologue. Dans des méthodes comme EAP-TLS [RFC2716], EAP-TTLS [EAP-TTLS] et PEAP [PEAP], le certificat, le nom d'utilisateur ou l'identité anonyme utilisé PEUT différer à chaque tentative d'authentification. Une fois que l'authenticateur a authentifié le homologue, il PEUT fournir des conseils sur le nom d'utilisateur ou le certificat que le homologue doit utiliser (par exemple dans le tunnel). Cela peut être utilisé comme identité pour une deuxième tentative d'authentification après l'échec de la négociation d'identité initiale.
Protection d'identité
Avant la fin de l'authentification EAP, l'identité du homologue PEUT être exposée à des tiers. Pour éviter cette exposition, les méthodes EAP PEUVENT prendre en charge la protection d'identité (par exemple par chiffrement ou identifiant anonyme). Dans EAP-TLS [RFC2716], l'identité peut être fournie dans le tunnel, la protégeant ainsi de l'écoute passive. Dans EAP-TTLS [EAP-TTLS] et PEAP [PEAP], une identité anonyme est utilisée pour la poignée de main initiale, et l'identité réelle est fournie dans le tunnel.
5.2. Notification
Description
Un paquet EAP-Request ou EAP-Response dont la valeur de type est Notification est utilisé pour transmettre un message lisible par l'homme. Le homologue PEUT afficher ce message à l'utilisateur, ou PEUT le journaliser et/ou le présenter à un administrateur. L'authenticateur PEUT envoyer une notification pour informer l'utilisateur de quelque chose (par exemple "Vous allez être déconnecté"). Le homologue DEVRAIT répondre avec un paquet EAP-Response de valeur Notification, et PEUT choisir de ne pas afficher le message (ou seulement une partie de celui-ci). Cependant, le message DEVRAIT être fourni en caractères ISO 10646 encodés en UTF-8 [ISO.10646].
Si une demande de Notification est envoyée avant la fin de l'authentification, le homologue DEVRAIT envoyer une réponse de Notification, même s'il choisit de ne pas afficher le message. Une notification envoyée après l'achèvement du processus d'authentification EAP PEUT être ignorée par le homologue, et NE DOIT EN AUCUN CAS être utilisée pour transporter des données destinées à une autre méthode EAP.
Type
2
Type-Data
Message texte à afficher à l'utilisateur, en caractères ISO 10646 encodés en UTF-8 [ISO.10646].
5.3. Nak
5.3.1. Legacy Nak
Description
Le homologue envoie un paquet EAP-Response dont la valeur de type est Nak pour indiquer à l'authenticateur son désaccord avec la EAP-Request initiale. Un NAK n'est envoyé qu'en réponse à une EAP-Request et lorsque la réponse initiale envoyée n'était pas un Nak, et ne devrait apparaître que près du début de l'authentification. Généralement, un Nak n'est envoyé que lorsque l'authenticateur demande un type d'authentification non pris en charge par le homologue, mais peut également être envoyé lorsque l'authenticateur demande un type d'authentification pris en charge par le homologue mais avec des détails de configuration inacceptables (par exemple, le homologue prend en charge la méthode mais le NAS ne peut pas fournir la qualité de service requise par la méthode). Lors de la réception d'un Nak, l'authenticateur PEUT répondre en envoyant le type d'authentification suggéré par le homologue dans le Nak, ou en envoyant une autre EAP-Request. Les documents de méthode EAP PEUVENT indiquer si une méthode peut être négociée (via Nak) ou si elle est obligatoire (c'est-à-dire qu'elle doit être implémentée au début de l'authentification).
Notez que Nak est une fonctionnalité héritée d'EAP avec une capacité d'extension limitée. Les nouvelles méthodes d'authentification DEVRAIENT utiliser l'Expanded Nak (section 5.3.2), car Nak ne peut pas être utilisé pour indiquer un désaccord avec un Expanded Type (section 5.3.2). De plus, certaines méthodes EAP sont conçues pour être négociées plutôt que d'utiliser Nak (par exemple dans les méthodes tunnelisées). Par conséquent, il est recommandé d'utiliser l'Expanded Nak lorsque possible.
Type
3
Type-Data
Dans le Nak traditionnel, le champ Type-Data est composé d'un ou plusieurs octets indiquant le type d'authentification que le homologue est disposé à utiliser dans sa réponse initiale. Par exemple, si le homologue reçoit une demande MD5-Challenge (Type 4) mais prend en charge One-Time Password (Type 5) et Generic Token Card (Type 6), il répond par un Nak dont le champ Type-Data contient les valeurs 5 et 6.
5.3.2. Expanded Nak
Description
Expanded Nak est utilisé pour négocier des types de méthode EAP. Il est similaire à Nak mais utilise le format Expanded Type (voir section 5.3.2). Expanded Nak peut indiquer un désaccord avec les types traditionnels et étendus.
Type
254
Type-Data
Pour Expanded Nak, le champ Type-Data commence par Vendor-Id et Vendor-Type (voir section 5.3.2). Étant donné que Expanded Nak est utilisé pour la négociation, le champ Vendor-Type est utilisé pour indiquer le type de méthode d'authentification (traditionnel ou étendu) que le homologue est disposé à utiliser. Le champ Vendor-Id est utilisé pour indiquer le fournisseur. Par exemple, si un Expanded Type a été demandé mais que le homologue préfère utiliser une autre méthode, les champs Vendor-Id et Vendor-Type du Expanded Nak devraient indiquer la méthode préférée par le homologue.
5.4. MD5-Challenge
5.4.1. Aperçu
Description
Le type MD5-Challenge correspond au protocole CHAP PPP [RFC1994] et fournit une authentification similaire à CHAP dans EAP. MD5-Challenge utilise la fonction de hachage MD5 [MD5] avec une clé partagée pour l'authentification. MD5-Challenge est la méthode EAP la plus largement déployée et est implémentée dans de nombreux points d'accès sans fil existants. MD5-Challenge fournit une authentification mutuelle sur la clé partagée, mais ne prend pas en charge la dérivation de clés ou le tunneling. MD5-Challenge ne fournit pas de protection d'identité. MD5-Challenge est vulnérable aux attaques par dictionnaire.
L'implémentation spécifique de MD5-Challenge se trouve dans [RFC1994] section 5. Dans EAP, les paquets MD5-Challenge sont calculés de manière similaire à CHAP, la principale différence résidant dans l'encodage des champs Value-Size et Response. Dans EAP, Value-Size est transporté dans le champ Value plutôt que comme un champ séparé.
Type
4
Type-Data
Pour EAP MD5-Challenge, le champ Type-Data contient les champs Value-Size, Value et Name, formatés comme suit.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value-Size
Un octet indiquant la longueur du champ Value en octets.
Value
Ce champ contient la valeur de hachage ou la valeur de défi, dont la longueur est indiquée par le champ Value-Size.
Name
Ce champ contient le nom d'hôte ou le nom d'utilisateur de l'expéditeur. Ce champ DOIT contenir des caractères ISO 10646 encodés en UTF-8 [ISO.10646].
5.4.2. Notes d'implémentation
Les paquets MD5-Challenge sont calculés comme suit :
[1] L'authenticateur envoie un paquet EAP-Request au homologue avec le champ Type défini sur 4 (MD5-Challenge) et le champ Type-Data contenant une valeur de défi.
[2] Sur le homologue, la valeur de hachage MD5 est calculée en utilisant la clé partagée, l'Identifier du homologue, la valeur de défi et le champ Name comme entrées. Le homologue répond avec un paquet EAP-Response contenant la valeur de hachage.
[3] L'authenticateur vérifie la valeur de hachage, et si elle correspond, l'authenticateur a authentifié avec succès le homologue.
5.5. One Time Password (OTP)
Description
Le type One Time Password correspond au système de mot de passe à usage unique défini dans [RFC2289]. Le type OTP permet l'authentification à l'aide de mots de passe à usage unique, où chaque mot de passe n'est utilisé qu'une seule fois. Cette méthode fournit une protection contre les attaques par relecture, car une mot de passe différent est utilisé pour chaque tentative d'authentification. OTP ne fournit pas d'authentification mutuelle ni de dérivation de clés.
Type
5
Type-Data
Pour le type OTP, le champ Type-Data contient un bloc de données composé de texte affiché à l'utilisateur, l'invitant à saisir, suivi d'un espace, puis du mot de passe à usage unique. Ce texte DEVRAIT être représenté en caractères ISO 10646 encodés en UTF-8 [ISO.10646]. Le format spécifique du champ est décrit dans [RFC2289].
5.6. Generic Token Card (GTC)
Description
Le type Generic Token Card est utilisé pour prendre en charge diverses implémentations de cartes à jeton. Le type GTC permet à l'authenticateur d'envoyer un défi au homologue, qui utilise ensuite sa carte à jeton pour calculer la réponse. GTC ne spécifie pas les détails de l'implémentation de la carte à jeton ; il prend plutôt en charge le passage du défi/réponse d'un serveur d'authentification externe au homologue. GTC ne fournit pas d'authentification mutuelle ni de dérivation de clés.
Type
6
Type-Data
Pour le type GTC, le champ Type-Data contient un bloc de données composé de texte affiché à l'utilisateur, l'invitant à saisir, suivi d'un espace, puis de la valeur générée par la carte à jeton. Ce texte DEVRAIT être représenté en caractères ISO 10646 encodés en UTF-8 [ISO.10646].
5.7. Types étendus (Expanded Types)
Description
Puisque de nombreuses utilisations existantes d'EAP sont spécifiques à un fournisseur, le Type de méthode étendu (Expanded Type) est disponible pour permettre aux fournisseurs de prendre en charge leurs propres Types étendus non adaptés à un usage général.
Le Type étendu est également utilisé pour étendre l'espace global des Types de méthode au-delà des 255 valeurs originales. Un Vendor-Id de 0 mappe les 255 Types possibles originaux sur un espace de 2^32-1 Types possibles. (Le Type 0 est uniquement utilisé dans une réponse Nak pour indiquer qu'il n'y a pas d'alternative acceptable).
Une implémentation qui prend en charge l'attribut étendu DOIT traiter les Types EAP inférieurs à 256 de manière équivalente, qu'ils apparaissent sous la forme d'un octet unique ou sous la forme du Vendor-Type de 32 bits au sein d'un Type étendu dont le Vendor-Id est 0. Les pairs non équipés pour interpréter le Type étendu DOIVENT envoyer un Nak comme décrit à la section 5.3.1, et négocier une méthode d'authentification plus appropriée.
Un résumé du format du Type étendu 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Vendor-Id (cont) | Vendor-Type...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type (cont) | Vendor-Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
254 pour le Type étendu (Expanded Type)
Vendor-Id
Le Vendor-Id est de 3 octets et représente le SMI Network Management Private Enterprise Code du fournisseur dans l'ordre des octets réseau, tel qu'alloué par l'IANA. Un Vendor-Id de zéro est réservé à l'usage de l'IETF pour fournir un espace de Types EAP global étendu.
Vendor-Type
Le champ Vendor-Type est de quatre octets et représente le type de méthode spécifique au fournisseur.
Si le Vendor-Id est zéro, le champ Vendor-Type est une extension et un sur-ensemble de l'espace de noms existant pour les Types EAP. Les 256 premiers Types sont réservés pour la compatibilité avec les Types EAP à octet unique déjà attribués ou pouvant l'être à l'avenir. Ainsi, les Types EAP de 0 à 255 sont sémantiquement identiques, qu'ils apparaissent sous forme de Types EAP à octet unique ou sous forme de Vendor-Type lorsque le Vendor-Id est zéro. Il y a une exception à cette règle : les paquets Expanded Nak et Legacy Nak partagent le même Type, mais doivent être traités différemment car ils ont un format différent.
Vendor-Data
Le champ Vendor-Data est défini par le fournisseur. Lorsqu'un Vendor-Id de zéro est présent, le champ Vendor-Data sera utilisé pour transporter le contenu des méthodes EAP de Types définis par l'IETF.
5.8. Expérimental (Experimental)
Description
Le Type expérimental (Experimental Type) n'a pas de format ni de contenu fixe. Il est destiné à être utilisé lors de l'expérimentation de nouveaux Types EAP. Ce Type est prévu à des fins expérimentales et de test. Aucune garantie d'interopérabilité entre les pairs utilisant ce Type n'est fournie, comme indiqué dans [RFC3692].
Type
255
Type-Data
Non défini (Undefined)