Brevet FR2889780A1 — publié le 20070216

La présente invention est relative au domaine du contrôle d'accès à un réseau de communication à protocole IP (Internet Protocol). Elle s'applique particulièrement bien à l'accès radio à de tels réseaux. En effet, dans un contexte d'accès radio à un réseau de communication, il n'y a pas de connexion prédéterminée entre les équipements d'accès et les hôtes (pour host en langue anglaise). Ces hôtes sont des équipements mobiles ayant la capacité de communiquer avec un réseau selon le protocole IP. Il peut notamment s'agir de terminaux tels des terminaux mobiles de communication de type GSM, UMTS, CDMA etc. d'ordinateurs portables, d'assistants personnels numériques (ou PDA pour Personal Digital Assistant ) etc. Du fait de la mobilité des hôtes (et éventuellement des équipements d'accès), ceux-ci ne peuvent être associés de façon définitive à un équipement d'accès comme cela est habituellement le cas dans un réseau de communication fixe. Un nouvel hôte ou un hôte qui s'est déplacé dans la zone de couverture d'un équipement d'accès, doit donc se connecter dynamiquement à cet équipement d'accès. Cette connexion dynamique engendre différents types de problèmes liés au contrôle d'accès. Cette exigence de contrôle d'accès est nécessaire dans différents contextes. Par exemple, il est souhaitable d'éviter qu'un visiteur d'une entreprise muni d'un équipement mobile puisse accéder librement au réseau local de celle-ci. Il est aussi important d'éviter qu'un tiers malattentionné puisse se connecter à un réseau de communication pour accéder à des informations sensibles ou nuire à l'intégrité du réseau. Ainsi, du point de vue de l'équipement d'accès, il faut s'assurer de l'identité de l'hôte afin de déterminer s'il peut effectivement se connecter au réseau de communication, et le cas échéant quels seront ses droits dans ce réseau. Inversement, l'hôte doit aussi s'assurer de l'identité de l'équipement d'accès auquel il désire se connecter. Le document P802.1X promu par l'IEEE propose une solution de contrôle d'accès intitulée Draft Standard for Port Based Network Access Control . Il définit un mécanisme utilisant les caractéristiques d'accès physique des infrastructures de réseaux locaux ou LAN (pour Local-Area Network en langue anglaise) définies par les standards de la famille IEEE 802. Il permet ainsi d'authentifier les hôtes attachés à un port LAN en mode point à point et d'empêcher les accès et transmission sur ce port si l'authentification n'est pas assurée. Toutefois ce mécanisme présente de nombreux désavantages. Tout d'abord, il s'intéresse aux ports des équipements et se situe donc au deuxième niveau du modèle en couches OSI (Open System Interconnect) promu par I'ISO (International Standards Organization). Ce deuxième niveau, nommé Liaison de données ( Data Link Layer en langue anglaise) couvre l'interface des équipements qui doivent communiquer. Cette couche dépend de la technologie mise en oeuvre pour l'établissement de cette liaison. Or, nous avons vu qu'un hôte et un équipement d'accès pouvaient être reliés par différentes technologies. Sans prétendre établir une liste exhaustive, on peut citer les normes de téléphonie mobile comme GSM, UMTS, mais aussi WiFi, Ethernet, Blue Tooth, Wimax... La norme WiFI définie par les normes IEEE 802.11, la technologie Bluetooth définie par les normes IEEE 802.15, la technologie WiMAX ( Wordwide Interoperability for Microwave ACCess ) définie par la norme IEEE 802.13, par exemples, possèdent toutes des techniques de liaison de donnée différentes. Et même, au sein d'une même famille de technologies, plusieurs versions peuvent co-exister entraînant des techniques de liaison de données différentes. Aussi, le mécanisme P802.1X présente l'important inconvénient de 30 nécessiter autant d'implémentations que de technologies supportées par le 2889780 3 système. Cela engendre bien entendu une augmentation substantielle du coût du système, ainsi qu'une utilisation accrue des ressources disponibles. Un second inconvénient est qu'il nécessite un serveur d'authentification dédié. Ce serveur, appelé authentication server peut communiquer avec l'équipement d'accès par le protocole AAA ( Authentication Authorization Accounting ) défini par le RFC 2906 de l'IETF. Il peut alternativement s'agir d'un serveur RADIUS ( Remote Authentication Dial In User Service ) défini par le RFC 2865 de I'IETF. Là encore, la présence indispensable d'un serveur dédié rend le système très coûteux, surtout dans un milieu hétérogène, puisque la nature des informations nécessaires à l'authentification est différente selon chacun des types de serveurs. L'invention a pour but de résoudre ces différents problèmes techniques. Elle a pour objet un équipement d'accès à un réseau de communication, pourvu d'une interface de radio-communication apte à transmettre des paquets de données avec des hôtes mobiles situés dans une zone géographique associée à cette interface, des moyens de négociation prévus pour établir un échange de paquets de données avec un hôte mobile de la zone géographique sollicitant l'accès audit réseau de communication, et des moyens de transmission pour transmettre des paquets de données formant un flux de données, entre un ou plusieurs équipements distants situés dans le réseau de communication et les hôtes mobiles enregistrés dans une liste d'hôtes mobiles autorisés mémorisée dans l'équipement d'accès, les moyens de transmission ne transmettant aucun paquet de données de ou vers les hôtes mobiles non enregistrés dans la liste d'hôtes mobiles autorisés. L'équipement d'accès de l'invention se caractérise en ce que les moyens de négociation comportent des moyens de contrôle prévus pour authentifier l'hôte mobile à partir de l'échange de paquets de données et pour modifier la liste d'hôtes mobiles autorisés en fonction de cette authentification. 2889780 4 Selon les mises en oeuvre de l'invention, celle-ci peut comporter une ou plusieurs des caractéristiques suivantes: É la liste d'hôtes mobiles autorisés est une base de type ACL (pour Access Control List en langue anglaise), É les moyens de négociations transmettent un message d'annonce à l'hôte mobile contenant le statut de l'authentification, É l'échange de paquets de données comporte un message de sollicitation contenant un certificat contenant des informations nécessaires et suffisantes pour permettre l'authentification, É les moyens de contrôle sont prévus pour accéder à la clé publique d'un tiers de confiance, ces informations nécessaires et suffisantes pour permettre l'authentification comprenant des informations réduites cryptées par la clé privée du tiers de confiance. Par ailleurs, l'invention a également pour objet un procédé pour contrôler l'accès d'hôtes mobiles à un réseau de communication à travers un équipement d'accès pourvu d'une interface de radio-communication apte à transmettre des paquets de données avec un des hôtes mobiles lorsque celui-ci est situé dans une zone géographique associée à l'équipement d'accès. Le procédé comporte une étape d'échange de paquets de données entre ledit équipement d'accès et les hôtes mobiles et une étape de transmission consistant à transmettre par l'équipement d'accès des paquets de données formant flux de données entre un ou plusieurs équipements distants situé dans le réseau de communication et les hôtes mobiles si et seulement si ceux-ci ont été préalablement enregistrés dans une liste d'hôtes mobiles autorisés mémorisée dans l'équipement d'accès. Ce procédé se caractérise en ce que, préalablement à l'étape de transmission, l'équipement d'accès procède à l'authentification de chaque hôte mobile sollicitant l'accès au réseau de communication, à partir de cet échange de paquets de données, et modifie la liste d'hôtes mobiles autorisés en fonction de cette authentification. L'invention et ses avantages apparaîtront de façon plus claire dans la description qui va suivre, en liaison avec les figures annexées. La figure 1 représente le contexte dans lequel s'inscrit la présente invention. La figure 2 est un schéma fonctionnel d'un équipement d'accès selon l'invention. La figure 3 illustre l'échange de paquets de données entre un hôte mobile et un équipement d'accès selon l'invention. Ainsi que représentée par la figure 1, l'équipement d'accès EA possède une interface radio IR. Cette interface est associée à une zone géographique Z (également appelée couverture ) dont les caractéristiques techniques correspondent au type de technologie mis en oeuvre. Il peut s'agir de quelques dizaines de mètres pour une interface radio WiFiTM, quelques centaines de mètres avec Bluetooth ou même plusieurs 15 kilomètres avec une interface radio WiMAX. Cette zone géographique Z a été représentée sur la figure 1 comme approximativement circulaire, mais dans la réalité cette zone est plus ou moins dépendante des obstacles du terrain. Il est à noter également qu'un même équipement d'accès EA peut 20 éventuellement posséder plusieurs interfaces radio afin de pouvoir transmettre selon plusieurs technologies de radio-communication. L'équipement d'accès EA possède par ailleurs une interface filaire IF avec un réseau de communication fixe N auquel est relié un ou plusieurs équipements distants Ep. Des hôtes mobiles H,, H2, H3 peuvent évoluer dans l'espace et, à un moment donné, être dans la zone Z associée à l'interface radio IR de l'équipement d'accès EA. Comme évoqué précédemment, ces hôtes mobiles peuvent être des terminaux mobiles de radiocommunication, des assistants personnels numériques (PDA pour Personnal Digital Assistant ), des ordinateurs portables munis d'une interface radio, etc. Dans l'exemple de la figure 1, les hôtes mobiles H, et H2 sont dans cette zone géographique Z. L'hôte mobile H3 est situé en dehors de cette zone géographie Z et ne peut donc pas physiquement communiquer avec l'équipement d'accès EA. Lorsqu'un hôte mobile est dans la zone géographique Z, il est en mesure de solliciter l'accès au réseau de communication N, notamment afin de communiquer avec un équipement distant Ep. Cet équipement distant ED peut être un hôte avec lequel il souhaite échanger des informations (une communication téléphonique ou vidéo, par exemple). Il peut aussi s'agir d'un serveur vidéo, ou bien d'une passerelle vers un autre réseau (non représenté sur la figure). Les paquets de données qui sont échangés entre les hôtes mobiles et l'équipement d'accès EA peuvent être conformes au protocole IP et préférentiellement au protocole IPv6 ( Internet Protocol version 6 ). II est connu en soi de disposer à l'intérieur d'un équipement d'accès, une liste d'hôtes autorisés. Selon l'invention, cette liste répond préférentiellement à la technologie ACL ( Access Control List selon la terminologie en langue anglaise, ou Liste de contrôle d'accès ). Il s'agit d'une liste d'identificateurs des hôtes autorisés à se connecter à un équipement. Cette technologie n'a pas fait l'objet de travaux de normalisation, mais est largement utilisée par les constructeurs d'équipements. La sollicitation d'accès au réseau de communication N est effectuée par un échange de paquets de données entre l'hôte mobile H,, H2 sollicitant l'accès et l'équipement d'accès EA au réseau de communication N. Lorsque la sollicitation d'accès débouche, l'hôte mobile est ajouté dans une liste des hôtes mobiles autorisés, mémorisée à l'intérieur de l'équipement d'accès EA. L'équipement d'accès EA peut alors transmettre des flux de données 30 entre ces deux parties. Ces flux de données se présentent sous la forme d'ensemble de paquets de données. Ils peuvent être unidirectionnels ou bidirectionnels. Les paquets de données appartenant à un flux de données contiennent une adresse source et une adresse destination permettant leur acheminement à travers le réseau de communication N. Ces informations sont contenues dans un entête clairement distinct des données utiles véhiculées par le paquet. La figure 2 montre de façon plus détaillée une architecture fonctionnelle possible de l'équipement d'accès EA. II dispose de moyens de transmission MT prévus pour transmettre les flux de données F entre le réseau de communication et l'hôte mobile (non représentés). Cette transmission peut avoir lieu dans les deux sens, comme évoqué précédemment. Ces moyens de transmission MT transmettent effectivement les flux de données à condition que l'hôte mobile ait été préalablement authentifié. Une liste d'hôtes mobiles autorisés ACL est donc prévue dans l'équipement d'accès EA. Aussi, si un hôte mobile n'appartient pas à la liste ACL, les moyens de transmission MT ne transmettront aucun flux de paquets de et vers celui-ci. Il sera alors complètement déconnecté du réseau de communication. Au contraire, si l'hôte mobile appartient à la liste ACL, alors la transmission des flux de données F est possible. Selon l'invention, cette liste des hôtes mobiles autorisés ACL est initialement vide. Dans cet état, aucun hôte mobile n'est en mesure de transmettre des flux de données avec le réseau de communication. Chaque hôte mobile sollicitant un accès au réseau de communication effectue un échange de paquets de données NS, NA avec des moyens de négociation MN contenues dans l'équipement d'accès EA. Grâce à cet échange, l'hôte mobile transmet aux moyens de négociation MN des informations qui permettent à l'équipement d'accès EA de 30 l'authentifier. 2889780 8 L'échange en question est illustré par la figure 3 sous la forme de chronogramme vertical. Le temps est orienté du haut vers le bas, et les flèches indiquent la direction de la transmission des différents messages transmis entre un hôte mobile H (à gauche) et l'équipement d'accès EA (à droite). Dans une première étape, l'équipement d'accès transmet un message RA à l'hôte H. Ce message d'annonce RA est une annonce de routeur ( Router Advertisment ) qui permet à un équipement conforme au protocole IP d'annoncer son existence à son environnement. C'est grâce à la transmission périodique et en mode multi-cast de ce message d'annonce RA que l'hôte mobile peut être informé de la présence d'un équipement d'accès EA dans son voisinage (ou plutôt, qu'il est dans la zone géographique Z associée à un équipement d'accès EA). Le format et le type d'information transmis dans les messages d'annonce RA sont définis dans le RCF 2461 de l'IETF, intitulé Neighbor Discovery for IP Version 6 (IPv6). qui décrit le protocole NDP ( Network Discovery Protocol .) L'hôte mobile H transmet alors un message de sollicitation NS ( Network Solicitation ). Un tel message est conforme au RFC 2461 précédemment évoqué. Aussi, le format des informations contenues respecte le standard ICMPv6, c'est-à-dire selon un formalisme TLV, Type, Length, Value . Le message de sollicitation NS comporte un entête et éventuellement un ensemble d'options. Cette entête est une entête propre au protocole NDP, qui est donc distinct de l'entête IP qui débute tout paquet IP. Cette entête NDP comporte - un champ type valant 135 pour un message de sollicitation NS du type Neighbor Solicitation Message . - un champ Code valant 0 - un champ checksum , conforme au standard ICMPv6, et permettant de contrôler l'intégrité du contenu du message de sollicitation. - Un champ Reserved , non utilisé par ce type de messages. - Un champ target address indiquant l'adresse IP du destinataire du message de sollicitation. Il s'agit ici de l'adresse IP de l'équipement d'accès EA qui est connu de l'hôte H grâce au message d'annonce RA reçu de celui-ci. - Éventuellement un ou plusieurs champs Options . Différentes options ont été définies. L'option Source Link-layer address a été définie dans ce RFC 2461. Le RFC 3971 intitulé Secure Neighbor Discovery (SEND) définie d'autres options, notamment: - CGA option - RSA signature option . La méthode de cryptage RSA (pour Rivest, Shamir et Adleman, les noms des inventeurs) se caractérise par le fait qu'une clé différente est utilisée pour le décryptage et pour le cryptage. Cette méthode permet donc d'utiliser une clé publique pour le cryptage et une clé privée pour le décryptage. Comme expliqué en détail dans le RFC 3971, l'hôte H utilise sa propre clé privé pour crypter un ensemble de données (adresses IP, entêtes du message de sollicitation etc.) et ainsi former sa signature . Cette signature est insérée dans le champ RSA signature option en dernier dans la construction du message. Le champ CGA option permet de donner une liste de tiers de confiance permettant d'authentifier l'émetteur, ici l'hôte H, auprès du destinataire, ici l'équipement d'accès EA. Celui-ci dispose également d'une seconde liste de tiers de confiance permettant de l'authentifier. En utilisant un tiers de confiance commun, l'équipement d'accès EA peut transmettre les informations nécessaires dans un message d'annonce NA ( Neighbor Advertisement ) permettant à l'hôte H d'authentifier l'équipement d'accès EA. Ce tiers de confiance commun peut être un tiers de confiance présent dans les deux listes de tiers de confiance. Dans la mesure où les tiers de confiance sont organisés de façon arborescente, il peut aussi s'agir d'un tiers de confiance dont les branches descendantes comportent des tiers de confiance à la fois pour l'hôte H et pour l'équipement d'accès EA. Selon l'invention, une option Certificats est ajoutée dans les messages de sollicitation NS. Elle permet à l'hôte H de transmettre aux moyens de négociation MN de l'équipement d'accès EA des informations lui permettant de l'authentifier. Ce certificat peut être un identificateur de l'hôte H, signé par un tiers de confiance. Il peut contenir son adresse IP, par exemple. Ce certificat peut être conforme à la recommandation X.509 de l'ITU- T (International Telecommunication Union), intitulée Information technology Open systems intectionnection The Directory: Public-Key and attribute certificate frameworks et se baser sur les travaux de l'IETF (Internet Engineering Task Force) pour adapter cette recommandation pour les protocoles de la pile IP. Ces travaux se sont concrétisés par plusieurs RFC et Internet drafts et sont notamment regroupés dans le groupe de travail PKIX (pour Public-Key Infrastructure (X.509) ) établi à l'automne 1995. Le premier des documents normatifs définis par le groupe de travail PKIX est le RFC 2459 intitulé Public Key Infrastructure Certificate and CRL Profiles Ce certificat est préférentiellement signé en utilisant la clé privée du tiers de confiance (ou CA pour Certificate Authority , en langue anglaise) associé à l'hôte mobile H. Typiquement, un algorithme est appliqué au certificat pour fournir une information réduite. Cette information réduite peut alors être crypté par cette clé privée du tiers de confiance puis l'information réduite et l'information réduite cryptée sont attachés au certificat, dans l'option Certificat , avant d'être envoyé dans le message de sollicitation NS. À la réception du message de sollicitation NS, les moyens de contrôle MC peuvent vérifier le contenu de celui-ci. Notamment, ils peuvent vérifier si les options CGA option et RSA signature option sont conformes aux requis du protocole SEND défini par le RFC 3971. En outre, les moyens de négociation MN vérifient le certificat contenu dans l'option Certificats , au moyen de moyens de contrôle MC. Dans la situation où l'option Certificats est signée comme évoqué précédemment, il utilise la clé publique du tiers de confiance afin de décrypter l'information réduite cryptée. Le résultat du décryptage de l'information réduite cryptée doit normalement donner l'information réduite, telle qu'également transmise dans l'option Certificat . Si cela est effectivement le cas, les moyens de contrôle MC peuvent être assurés que le certificat a été signé par ce tiers de confiance. Le message de sollicitation NS est alors authentifié. Dans le cas contraire, il n'est pas authentifié et doit être rejeté. Afin de décrypter l'information réduite cryptée, les moyens de contrôle MC doivent avoir accès à la clé publique du tiers de confiance utilisé par l'hôte mobile H. Cette clé publique peut être d'ores et déjà à disposition des moyens de contrôle MC. Il peut aussi avoir à accéder à une base de données des tiers de confiance, accessible sur le réseau de communication N. Différents modes de réalisation sont alors possibles en fonction de l'infrastructure à clé publique (ou PKI pour Public Key Infrastructure ) mise en oeuvre. Les travaux du groupe de travail PKIX laissent en effet beaucoup de possibilités et à l'heure actuelle aucune infrastructure possible ne l'emporte véritablement sur les autres. Aussi, l'invention ne saurait être réduite à l'une ou l'autre de ces infrastructures PKI, ni aux exemples donnés ci-dessus. Elle s'applique au contraire à toute implémentation permettant à l'équipement d'accès EA de disposer des informations nécessaires et suffisantes pour authentifier l'hôte mobile H. 2889780 12 Dans une mise en oeuvre particulière de l'invention, une fois authentifiée, les moyens de contrôle MC peuvent vérifier les droits d'accès de l'hôte mobile H. En effet, un hôte mobile H peut être authentifié mais ne pas pour autant se voir accéder l'ensemble des droits d'accès. Dans certains cas, son authentification peut entraîner un rejet de sa sollicitation. C'est le cas s'il a été mis dans une liste noire par exemple (ou blacklist en anglais). Il peut aussi ne se voir concéder que des droits d'accès limités (à une partie du réseau, à une partie des services disponibles sur le réseau, etc.). Si les moyens de contrôle MC authentifient l'hôte H comme pouvant accéder au réseau de communication, il modifie alors la liste des hôtes mobiles autorisés. Cette modification peu consister à ajouter l'adresse IP de l'hôte H dans la base ACL. Ainsi, chaque paquet reçu par les moyens de transmission MT ayant cette adresse IP comme adresse source seront transmis vers le réseau de communication. En outre, préférentiellement, les moyens de négociation MN renvoient un message d'annonce NA vers l'hôte mobile H pour l'informer du statut de sa sollicitation. Ce message d'annonce NA peut être du type Neighbor Solicitation tel que défini dans le RFC 2461 de l'IETF (paragraphe 4.4). Ce message d'annonce Neighbor Advertisement possède un format similaire à celui du message de sollicitation NS Neighbor Solicitation décrit précédemment. Une option supplémentaire Policy Notification Option peut être utilisée pour transmettre un statut de la sollicitation transmise par le message de sollicitation NS. Cette option peut par exemple prendre trois valeurs: - 0 , si le certificat est accepté par l'équipement d'accès EA. - 1 , si le certificat n'a pas pu être évalué par l'équipement d'accès EA, par exemple parce qu'il est de type inconnu. 30 - 2 , si le certificat est refusé par l'équipement d'accès EA. De cette façon, à la réception du message d'annonce NA, l'hôte H est informé de s'il doit transmettre un nouveau certificat (cas où l'option vaut 1 ) ou bien si ces paquets seront transmis par l'équipement d'accès ou non. En fonction de cela, il peut opter pour le choix d'un autre équipement d'accès dont il serait dans la zone géographique Z, ou bien informer l'utilisateur qu'il ne peut accéder au réseau de communication. REVENDICATIONS 1) Equipement d'accès (EA) à un réseau de communication (N), pourvu d'une interface de radio-communication (IR) apte à transmettre des paquets de données avec des hôtes mobiles (H,, H2, H3) situés dans une zone géographique (Z) associée à ladite interface (IR), des moyens de négociation (MN) prévus pour établir un échange de paquets de données (RA, NS, NA) avec un hôte mobile de ladite zone géographique sollicitant l'accès audit réseau de communication, et des moyens de transmission (MT) pour transmettre des paquets de données formant un flux de données (F), entre un ou plusieurs équipements distants (ED) situés dans ledit réseau de communication et les hôtes mobiles enregistrés dans une liste d'hôtes mobiles autorisés (ACL) mémorisée dans ledit équipement d'accès, lesdits moyens de transmission ne transmettant aucun paquet de données de ou vers les hôtes mobiles non enregistrés dans ladite liste d'hôtes mobiles autorisés, caractérisé en ce que lesdits moyens de négociation comportent des moyens de contrôle (MC) prévus pour authentifier ledit hôte mobile à partir dudit échange de paquets de données et pour modifier ladite liste d'hôtes mobiles autorisés en fonction de cette authentification. 2) Équipement d'accès selon la revendication précédente, dans lequel ladite liste d'hôtes mobiles autorisés est une base de type ACL. 3) Equipement d'accès selon la revendication 1 ou 2, dans lequel lesdits moyens de négociations transmettent un message d'annonce (NA) 25 audit hôte mobile contenant le statut de ladite authentification. 4) Equipement d'accès selon l'une des revendications précédentes dans lequel ledit échange de paquets de données comporte un message de sollicitation (NS) contenant un certificat contenant des informations nécessaires et suffisantes pour permettre ladite authentification. 5) Equipement d'accès selon la revendication 4 dans lequel lesdits moyens de contrôle sont prévus pour accéder à la clé publique d'un tiers de confiance, lesdites informations comprenant des informations réduites cryptées par la clé privée dudit tiers de confiance. 6) Procédé pour contrôler l'accès d'hôtes mobiles (H,, H2, H3) à un réseau de communication (N) à travers un équipement d'accès (EA) pourvu d'une interface de radio-communication (IR) apte à transmettre des paquets de données avec un desdits hôtes mobiles lorsque celui-ci est situé dans une zone géographique (Z) associée audit équipement d'accès (EA), ledit procédé comportant une étape d'échange de paquets de données (RA, NS, NA) entre ledit équipement d'accès et lesdits hôtes mobiles et une étape de transmission consistant à transmettre des paquets de données formant flux de données (F) par ledit équipement d'accès entre un ou plusieurs équipements distants (ED) situé dans ledit réseau de communication et lesdits hôtes mobiles si et seulement si ceux-ci ont été préalablement enregistrés dans une liste d'hôtes mobiles autorisés (ACL) mémorisée dans ledit équipement d'accès, caractérisé en ce que, préalablement à ladite étape de transmission, l'équipement d'accès procède à l'authentification de chaque hôte mobile sollicitant l'accès au réseau de communication, à partir dudit échange de paquets de données, et modifie ladite liste d'hôtes mobiles autorisés en fonction de cette authentification.