| RFC 2284 : PPP Extension Authentication Protocol |  |
|
Network Working Group Statut de ce document Ce document spécifie un protocole pour la pile standard d’Internet destiné à la Communauté Internet, et nécessite des discussions et des suggestions pour être testé et opérationnel. Référez-vous à l’édition courante des Protocoles Standards Officiels d’Internet ("Internet Official Protocol Standards" (STD 1)) pour connaître l’état d’avancement et de normalisation de ce protocole. La distribution de cette note n’est pas limitée. Copyright Notice Copyright (C) La Communauté Internet (1998). Tous droits réservés. Résumé Le Protocole Point-to-Point (PPP) [1] offre une méthode standard pour transporter des datagrammes multi-protocoles sur des liaisons point-à-point. PPP définit également une extension, un protocole de Contrôle de Liaison (Link Control Protocol), qui permet la négociation d’un protocole d’authentification pour authentifier la paire avant d’autoriser les protocoles de la couche Réseau à transmettre sur cette liaison. Ce document définit le protocole d’extension d’authentification de PPP (PPP Extensible Authentication Protocol). 1. Introduction Pour établir une communication sur une liaison point-à-point, chaque extrémité de la liaison PPP doit d’abord envoyer des paquets LCP pour configurer la liaison de données pendant la phase d’établissement du lien. Après que la liaison a été établi, PPP propose une phase optionnelle d’Authentification avant de procéder à la phase du Protocole de la Couche Réseau (Network-Layer Protocol phase). Par défaut, l’authentification n’est pas obligatoire. Si on souhaite l’authentification de la liaison, l’implémentation doit spécifier les options de configuration du protocole d’authentification pendant la phase d’établissement de la liaison. Ces protocoles d’authentification sont initialement prévus pour être utilisés par les hôtes et les routeurs qui se connectent à un serveur réseau PPP par des lignes ou des circuits commutés, mais peuvent également être utilisés sur des liens dédiés. Le serveur peut utiliser l’identification de l’hôte ou du routeur se connectant afin de choisir les options pour les négociations de la couche Réseau. Ce document définit le PPP Extensible Authentication Protocol (EAP). Les phases d’authentification et d’établissement de liaison, et l’option de configuration du protocole d’authentification, sont définis dans le protocole PPP [1]. 1.1. Specification of Requirements Dans ce document, de nombreux mots sont utilises pour mettre en avant les besoins de la normalisation. Ces mots sont généralement mis en lettres capitales. Les mots-clefs « DOIT », « NE DOIT PAS », « NECESSAIRE », « PEUT », « NE PEUT PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDE », « POURRAIT », et « OPTIONNEL » de ce document sont à interpréter comme décrit dans la RFC 2119 [6]. 1.2. Terminologie Ce document utilise fréquemment les termes suivants : - authentifiant : l’extrémité de la liaison qui demande une authentification. L’authentifiant spécifie le protocole à utiliser dans la Demande de Configuration (Configure-Request) pendant la phase d’établissement de la liaison. - paire : l’autre extrémité de la liaison point-à-point ; l’extrémité qui est authentifiée par l’authentifiant. - détruire (silently discard) : cela signifie que l’implémentation détruit le paquet sans autre traitement. L’implémentation DEVRAIT offrir la possibilité de rapporter l‘erreur dans un fichier de log, comprenant le contenu du paquet détruit, et DEVRAIT enregistrer l’événement pour faire des statistiques. - message à afficher : c’est une chaîne de caractères lisible par un être humain, et qui NE DOIT PAS affecter le fonctionnement du protocole. Le message encodé DOIT suivre le format de transformation UTF-8 [5]. 2. PPP Extensible Authentication Protocol (EAP) Le PPP Extensible Authentication Protocol (EAP) est un protocole
générique pour l’authentification PPP qui supporte plusieurs
mécanismes d’authentification. EAP ne choisit pas un mécanisme
d’authentification particulier pendant la phase de contrôle de la
liaison, mais attend plutôt la phase d’authentification. 1. Une fois la phase d’Etablissement de la Liaison terminée, l’authentifiant envoie une ou plusieurs Requêtes pour authentifier la paire. La Requête a un champ « Type » pour indiquer l’objet de la requête. Les exemples de Requêtes comprennent l’Identité, MD5-challenge, Mot de passe à usage unique (One-Time Password), Generic Token Card, etc. Le Type MD5-challenge correspond sensiblement au protocole d’authentification CHAP. Typiquement, l’authentifiant enverra d’abord une Requête d’Identité, suivie par une ou plusieurs Requêtes pour les informations d’authentification. Quoiqu’il en soit, la Requête initial d’Identité n’est pas obligatoire, et peut être court-circuitée lorsque l’identité est présupposée (lignes spécialisées, liaisons louées, etc.). 2. La paire envoie un paquet de Réponse en réponse à chaque Requête. Comme pour le paquet de Requête, le paquet de Réponse contient un champ « Type » correspondant au champ « Type » de la Requête. 3. L’authentifiant met fin à la phase d’authentification par l’intermédiaire d’un paquet de Succès ou d’Echec. Avantages Le protocole EAP peut supporter de multiples mécanismes d’authentification sans avoir à pré-négocier un mécanisme particulier pendant la phase LCP. Certains éléments (e.g. un serveur d’accès ou NAS) n’auront pas forcement besoin de comprendre tous les types de Requête et devraient néanmoins être capable d’agir en simple agent de passage pour un serveur d’extrémité ("back-end" server) sur un hôte. L’élément aura seulement besoin de regarder le code Succès/Echec pour mettre fin à la phase d’authentification. Désavantages EAP nécessite l’ajout d’un nouveau type d’authentification à LCP et donc, les implémentations de PPP devront être modifiées pour être utilisées. Il varie également du modèle d’authentification précédent de PPP pour la négociation d’un mécanisme d’authentification particulier pendant la phase LCP. 2.1. Format des Options de Configuration Le format des Options de Configuration du Protocole d’Authentification (Authentication-Protocol Configuration Option) permettent de négocier le Protocole d’Authentification EAP est proposé ci-dessous. Les champs sont transmis de gauche à droite.
0 1 2 3
Type : 3 2.2. Format du paquet Un paquet PPP EAP (et exactement un) est encapsulé dans le champ d’information de la trame PPP de la Couche Liaison de Données où le champ protocole est mis à C227 en hexadécimal (PPP EAP). Le format du paquet EAP est donné ci-dessous. Les champs sont transmis de la gauche vers la droite. 0 1 2 3 Code Le champ Code est codé sur un octet et identifie le type
de paquet EAP. 1 Requête Identifiant Le champ Identifiant est codé sur un octet et permet de faire correspondre les réponses et les requêtes. Longueur Le champ Longueur, sur 2 octets, indique la longueur du paquet EAP, comprenant les champs Code, Identifiant, Longueur, et Données. Les octets supplémentaires dépassant l’intervalle donné par le champ Longueur devraient être traités comme du bourrage de la couche Liaison de Données et devraient être ignorés à la réception. Données Le champ Données comporte zéro octet ou plus. Le format du champ Données est determine par le champ Code. 2.2.1. Requête et Réponse Description Le paquet de Requête est envoyé par l’authentifiant à la paire. Chaque Requête a un champ type qui permet d’indiquer ce qui est demandé. L’authentifiant DOIT transmettre un paquet EAP avec le champ Code mis à 1 (Requête). Des paquets de requêtes supplémentaires DOIVENT être envoyés jusqu’à ce qu’un paquet de Réponse valide soit reçu, ou qu’un compteur optionnel de retransmission expire. Les Requêtes retransmises DOIVENT être envoyées avec la même valeur d’identifiant pour être distinguées des nouvelles Requêtes. Le contenu du champ Données dépend du type de Requête. La paire DOIT envoyer un paquet de Réponse en réponse à un paquet de Requête. Les Réponses DOIVENT uniquement être envoyées en réponse à un paquet de Requête reçu et jamais retransmis suite à l’expiration d’un délai. Le champ Identifiant de la Réponse DOIT correspondre à celui de la Requête. Note d’implémentation : Etant donné que le processus d’authentification va souvent demander aux utilisateurs d’entrer des informations, des précautions doivent être prises sur les stratégies de retransmission et l’expiration des délais d’authentification. Il est suggéré d’utiliser par défaut un délai de 6 secondes et un maximum de 10 retransmissions. Certains pourront avoir envie d’augmenter ces délais dans certains cas (e.g. en cas d’utilisation de cartes Token par exemple). De plus, la paire doit être préparée à détruire les retransmissions reçues pendant l’attente des informations entrées par l’utilisateur. Le format des paquets de Requête et de Réponse
est donné ci-dessous. 0 1 2 3 Code 1 pour Requête; Identifiant Le champ Identifiant fait 1 octet. Le champ Identifiant DOIT être le même si un paquet de Requête est retransmis après un délai d’attente de la réponse. Toute nouvelle (non retransmission) Requête DOIT entraîner la modification du champ Identifiant. Si une paire reçoit une Requête dupliquée à laquelle il a déjà envoyé une réponse, il doit réémettre sa Réponse. Si une paire reçoit une Requête dupliquée avant d’avoir envoyé sa Réponse à la Requête initiale (i.e. il attend l’entrée des informations par l’utilisateur), il DOIT détruire la Requête dupliquée. Longueur Le champ Longueur est codé sur 2 octets et indique la longueur du paquet EAP, comprenant les champs Code, Identifiant,Type, et Données. Les octets supplémentaires sortant de l’intervalle spécifié par le champ Longueur devraient être traités comme du bourrage de la couche liaison de données et devraient être ignorés à la réception. Type Le champ Type est codé sur un octet. Ce champ indique le Type de Requête ou de Réponse. Un seul Type DOIT être spécifié par Requête ou Réponse EAP. Normalement, le champ Type de la Réponse sera le même que celui de la Requête. Cependant, il y a également un Type « Nak » (Réponse Négative) pour indiquer qu’un type de Requête est inacceptable par la paire. Lorsqu’on envoie un Nak en Réponse à une Requête, la paire DEVRAIT proposer en alternative un autre Type d’Authentification qu’il accepte. Une sélection initiale de Types est donnée plus loin dans ce document. Données Le champ Données varie en fonction du Type de Requête et de la Réponse associée. 2.2.2. Succès et Echec Description Le paquet de Succès est envoyé par l’authentifiant à la paire pour reconnaître le succès de l’authentification. L’authentifiant DOIT transmettre un paquet EAP avec le champ Code mis à 3 (Succès). Si l’authentifiant ne peut authentifier la paire (Réponses inacceptables à une ou plusieurs Requêtes), alors l’implémentation DOIT transmettre un paquet EAP avec le champ Code mis à 4 (Echec). Un authentifiant PEUT essayer plusieurs Requêtes avant d’envoyer la réponse d’Echec pour prendre en compte les fautes de frappes de l’utilisateur. Note d’implémentation : Du fait que les paquets de Succès et d’Echec ne sont pas suivi d’accusés de réception, ils peuvent éventuellement se perdre. Une paire DOIT prendre en compte cette possibilité. La paire peut utiliser un paquet du Protocole Réseau comme une indication possible de Succès. De même, une Requête de Fin de Session LCP peut être considérée comme un Echec. Le format du paquet d’Echec ou de Succès est donné
ci-dessous. 0 1 2 3 Code 3 pour Succès; Identifiant Le champ Identifiant, codé sur un octet, permet de faire correspondre les réponses aux Réponses. L’identifiant DOIT correspondre au champ Identifiant du paquet de Réponse auquel il répond. Longueur 4 3. Types initiaux de Requête et Réponse EAP Cette section définie un ensemble de Types EAP utilisés lors des échanges Requête/Réponse. D’autres Types pourront être définis dans d’autres documents. Le champ Type, codé sur un octet, identifie la structure d’un paquet de Requête et de Réponse EAP. Les 3 premiers Types sont considérés comme des Types particuliers. Les Types suivants définissent des échanges d’authentification. Le Type Nak est uniquement valide dans les paquets de Réponse , il NE DOIT PAS être envoyé dans un paquet de Requête. Le Type Nak DOIT seulement être envoyé en réponse à une Requête utilisant un code de Type d’authentification. Toutes les implémentations EAP DOIVENT supporter les Types 1 à 4. Ces Types, de même que les Types 5 et 6, sont définis dans ce document. Des RFC ultérieures définiront des Types EAP supplémentaires. 1 Identité 3.1. Identité Description Le Type Identité est utilisé pour demander l’identité
d’une paire. Note d’implémentation : La paire PEUT obtenir l’identité par l’entrée d’informations de l’utilisateur. Il est suggéré que l’authentifiant réessaye la Requête d’Identité en cas d’Identité invalide ou d’Echec de l’authentification pour prendre en compte les fautes de frappe de l’utilisateur. Il est suggéré de réessayer au moins 3 fois la Requête d’Identité avant de mettre un terme à l’authentification avec un message d’Echec. La Requête de Notification PEUT être utilisée pour indiquer une authentification invalide avant de transmettre une nouvelle Requête d’Identité (éventuellement, l’échec PEUT être indiquer par un nouveau message d’Identité). Type 1 Données Ce champ peut contenir un message à afficher dans la Requête. La Réponse utilise ce champ pour renvoyer son Identité. Si l’Identité est inconnue, ce champ peut avoir une longueur de zéro octet. Ce champ NE DOIT PAS être terminé par Null. La longueur de ce champ est déduite du champ longueur du paquet de Requête/Réponse et la valeur Null n’y a pas sa place. 3.2. Notification Description Le Type Notification est optionnellement utilisé pour envoyer un message à afficher de l’authentifiant vers la paire. La paire DEVRAIT afficher ce message à l’utilisateur, ou l’enregistrer dans les logs s’il ne peut l’afficher. Il est prévu pour fournir une notification sur un point précis et impératif. Par exemple, pour un mot de passe avec délai d’expiration qui est sur le point d’expirer, l’entier d’une séquence OTP qui s’approche de 0, une mise en garde sur l’Echec possible de l’authentification, etc. Dans la plupart des cas, la notification n’est pas nécessaire. Type 2 Données Le champ Données dans la Requête contient un message à afficher ayant une longueur supérieure à zéro octet. La longueur du message est déterminée par le champ Longueur du le paquet de Requête. Le message NE DOIT PAS se terminer par Null. Une Réponse DOIT être envoyée en réponse à cette Requête avec un champ Type mis à 2 (Notification). Le champ Données dans la Réponse fait zéro octet de long. La Réponse devrait être envoyée immédiatement, quelque soit la façon dont le message est affiché ou enregistré. 3.3. Nak Description Le Type Nak est uniquement valide dans les messages de Réponse. Il est envoyé en réponse à une Requête comprenant un Type d’Authentification inacceptable. Les Types d’Authentification sont numérotés à partir de 4. La Réponse contient le Type d’Authentification voulu par la paire. Type 3 Données Ce champ DOIT contenir un seul octet indiquant le type d’authentification voulu. 3.4. MD5-Challenge Description Le Type MD5-Challenge (Défi MD5) est similaire au protocole CHAP de PPP [3] (avec l’algorithme MD5). Il faut se référer à la RFC du protocole CHAP (Challenge Handshake Authentication Protocol) de PPP [3] pour plus d’informations sur les spécifications de l’implémentation. La Requête contient un message “défi” pour la paire. Une Réponse DOIT être envoyée en réponse à cette Requête. La Réponse peut être de Type 4 (MD5-Challenge) ou de Type 3 (Nak). La réponse Nak indique le Type de mécanisme d’Authentification que la paire souhaite utiliser. Toutes les implémentations EAP DOIVENT supporter le mécanisme du MD5-Challenge. Type 4 Données Le contenu du champ Données est donné ci-dessous. La référence pour l’utilisation de ces champs est la RFC du protocole CHAP de PPP [3]. 0 1 2 3 3.5. One-Time Password (OTP) Description Le système OTP (Mot de passe à usage unique) est défini dans "A One-Time Password System" [4]. La Requête contient un message à afficher contenant le défi OTP. Une Réponse DOIT être envoyée en réponse à cette Requête. La Réponse DOIT être de Type 5 (OTP) ou de Type 3 (Nak). La réponse Nak indique le Type de mécanisme d’Authentification que la paire souhaite utiliser. Type 5 Données Dans la Requête, le champ Données contient le “défi” OTP sous forme d’un message à afficher. Dans la Réponse, ce champ est utilisé pour les 6 mots du dictionnaire OTP [4]. Le message NE DOIT PAS se terminer par Null. La longueur du champ est déduite du champ Longueur du paquet de Requête/Réponse. 3.6. Generic Token Card Description Le Type Generic Token Card est défini pour être utilisé avec plusieurs implémentations de cartes Token qui demandent l’entrée d’informations par l’utilisateur. La Requête contient un message texte codé en ASCII et la Réponse contient les informations sur la carte Token nécessaires à l’authentification. Typiquement, ce sera des informations lues par un utilisateur de la machine ayant la carte Token et entrées en ASCII. Type 6 Données Le champ Données, dans le Requête, contient un message à afficher ayant une longueur supérieure à zéro octet. La longueur du message est déterminée par le champ Longueur du paquet de Requête. Le message NE DOIT PAS se terminer par Null. Une Réponse DOIT être envoyée en réponse à la Requête avec un champ Type mis à 6 (Generic Token Card). La Réponse contient des données de la carte Token nécessaires pour l’authentification La longueur des Données est déterminée par le champ Longueur du paquet de Réponse. Note sur la Sécurité La sécurité est le sujet principal de cette RFC. L’interaction entre les protocoles d’authentification et PPP est largement dépendante de l’implémentation. Par exemple, suite à un Echec de l’authentification, certaines implémentations ne coupent pas la liaison. L’implémentation préfère limiter et filtrer le trafic des protocoles de la couche Réseau, ce qui donne la possibilité à l’utilisateur de mettre à jour ses mots de passe ou d’envoyer un mail à l’administrateur réseau pour lui indiquer le problème. Il n’y a pas de disposition particulière en cas d’échec ou de nouvelle tentative d’authentification. De toute façon, la machine d’états LCP peut renégocier le protocole d’authentification à tout moment, ce qui permet une nouvelle tentative. Il est recommandé que tout compteur utilisé pour les échecs d’authentification ne soit pas remis à zéro tant que l’authentification n’a pas réussi, ou que la liaison en échec n’a pas été coupée. Il n’y a pas d’obligation à ce que l’authentification soit bidirectionnelle (full-duplex) ou que le même protocole soit utilisé dans les deux directions. Il est parfaitement acceptable que des protocoles différents soient utilisés dans chaque direction. Cela dépendra, évidemment, des protocoles spécifiés et négociés. En pratique, au sein ou associé au serveur PPP, il ne faut pas prévoir qu’un nom d’utilisateur particulier pourra être authentifié par plusieurs méthodes. Cela rendrait l’utilisateur vulnérable aux attaques qui négocieraient la méthode la moins sûre parmi celles proposées (comme PAP plutôt que EAP). Pour chaque nom d’utilisateur, il faudrait plutôt indiquer la seule méthode utilisée pour authentifier cet utilisateur. Si un utilisateur doit utiliser différentes méthodes d’authentification en fonction des circonstances, alors plusieurs identités DEVRAIENT être utilisées, chacune identifiant une seule méthode d’authentification. Références [1] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994. Remerciements Ce protocole est en partie inspiré du draft AHA de Dave
Carrel ainsi que du Protocole CHAP de PPP [3]. Contacts Le groupe de travail peut être contacté par l’intermédiaire de son responsable : Karl F. Fox EMail: karl@ascend.com Adresses des auteurs : Larry J. Blunk EMail: ljb@merit.edu John R. Vollbrecht EMail: jrv@merit.edu |