WO2005091565A1 - Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant - Google Patents

Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant Download PDF

Info

Publication number
WO2005091565A1
WO2005091565A1 PCT/FR2005/000303 FR2005000303W WO2005091565A1 WO 2005091565 A1 WO2005091565 A1 WO 2005091565A1 FR 2005000303 W FR2005000303 W FR 2005000303W WO 2005091565 A1 WO2005091565 A1 WO 2005091565A1
Authority
WO
WIPO (PCT)
Prior art keywords
tunnel
portal
source terminal
sour
port
Prior art date
Application number
PCT/FR2005/000303
Other languages
English (en)
Other versions
WO2005091565A9 (fr
Inventor
Florent Bersani
Olivier Charles
Franck Veysset
Laurent Butti
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2005091565A1 publication Critical patent/WO2005091565A1/fr
Publication of WO2005091565A9 publication Critical patent/WO2005091565A9/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities

Definitions

  • the invention relates generally to the techniques of accessing a computer network.
  • the invention relates to a method for controlling access from a source terminal to a network comprising an access point for this terminal, a firewall connected to the access point, and an authentication portal served. by an authentication database, this portal placing the firewall in an access authorization state in response to an initial basic mode access request from the source terminal and including the provision to the data portal validating credentials, failing which the firewall is placed in an access barred state, this portal retaining the firewall in a basic mode access authorization state in response to the periodic provision , by the source terminal and on a secure token exchange channel, a valid authentication token in default of which the firewall is placed in its access barred state, and the source terminal selectively communicating in tunnel mode with a te rminal destination network through a tunnel making the token exchange channel unusable.
  • Network access control is the process by which the operator of a network allows or does not allow a potential user to use his network.
  • a user of a network may indeed have to establish a tunnel to a remote host, tunnel in which it encapsulates its traffic.
  • this tunnel may be in blocking mode, that is to say reject all communications that would not borrow this tunnel in the sense of reception as in the direction of the broadcast.
  • This blocking mode is in fact an additional guarantee of security for the user. Indeed, in the case where a user connects via a tunnel to the private network or "intranet" of his company, a hacker can not attack this user or use it as a relay to access the intranet of the company. this last.
  • the invention aims to propose a method that allows the operator of a network to maintain access control to his network, even in the case where a user chooses to use a tunnel mode blocker.
  • the method of the invention is essentially characterized in that the portal places and keeps the firewall in its authorization state. access for a tunnel mode connection allowing communication through the tunnel between the source terminal and the destination terminal in response to a tunnel mode access request originating from the source terminal and including the provision to the portal, through the secure token exchange channel, valid identification data of the tunnel.
  • the tunnel identification data includes a destination terminal address, a source terminal address, and an identification of the tunnel protocol used.
  • the Tunnel Access Preliminary Request can respond to an invitation from the portal to the source terminal to provide valid credentials for a tunnel connection.
  • Such an invitation may be permanent, periodic, or triggered by detecting preparations to establish a tunnel connection.
  • the invitation sent by the portal to the source terminal to provide it with valid identification data for a connection in tunnel mode takes for example the form of a session maintenance window also used for the connection in basic mode, this window session maintenance advantageously comprising an end-of-connection button in tunnel mode.
  • the portal In response to detecting a tunnel end of connection from the source terminal, the portal sends the source terminal an invitation to provide valid authentication data to return to the basic connection mode. In any case, the portal can selectively terminate a tunnel mode connection by placing the firewall in its no access state.
  • the invention therefore also relates to a source terminal equipped with means for requiring a connection of this source terminal in blocking tunnel mode with a destination terminal of a network through a firewall controlled by a captive portal of the network, this source terminal being characterized in that it is furthermore equipped with identification means capable of responding to a specific, permanent or periodic invitation of identification addressed by the captive portal to this source terminal by providing this captive portal, through a channel secure token exchange, valid identification data of the tunnel, said identification means being advantageously of a software nature.
  • the invention also relates to a captive portal provided with means for conditionally authorizing a blocking tunnel connection of a source terminal with a destination terminal of a network through a firewall controlled by the captive portal, this gate being characterized in that it is furthermore equipped with means of control capable of sending the source terminal a one-off, permanent or periodic identification invitation requiring the provision, via a secure token exchange channel, of valid identification data tunnel, said control means being preferably of a software nature.
  • IP Address The address of a device using IP (see this word) as the OSI model layer 3 protocol (see this word).
  • MAC Address The address of a device connected to a shared medium used by layer 2 of the OSI model (see this word).
  • DHCP Dynamic Host Configuration Protocol: A protocol for dynamically assigning addresses on an IP network (see this word).
  • DNS National service of the Internet ensuring the conversion of domain names into IP addresses (see this word).
  • HTML An Internet document format defined by Standard RFC 1866.
  • IP Internet Protocol
  • Internet Protocol Network-level protocol used in connectionless Internet (datagram principle).
  • IPsec (Acronym from Internet Protocol Security): Security protocol used in the Internet.
  • MAC (Acronym derived from the English “Medium Access Control”): General term designating the layer that manages the sharing of a transmission medium between different stations.
  • Open Source Free software that meets defined qualitative requirements.
  • OSI Open System Interconnection
  • Preprocessor Object-oriented scripting language, free to use, to completely manage a website.
  • SSL Secure Socket Layer
  • TCP (Acronym derived from the English "Transport Control Protocol": Connection-oriented transport protocol, allowing a reliable exchange of any amount of data between two devices (level 4 OSI - see this word) connected by one or more networks using IP (see this word).
  • Transport layer security protocol defined by RFC 2246. Version 1.0 of TLS is actually SSL version 3 (see this word).
  • UDP User Datagram Protocol
  • URL (Acronym from Uniform Resource Locator): Address format for finding a resource.
  • VPN (Acronym derived from the English "Virtual Private Network"): Virtual Private Network.
  • IEEE 802.3-2002 IEEE Standard for Information Technology Communications and Information Exchange between Systems - Local and Metropolitan Area Networks - Specifies Requirements - Part 3: Meaningful Carrier Multiple Access with Collision Detection (CSMA / CD) Access Method and Physical Layer Specifications.
  • TLS Dierks, T. and Allen, c, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • VTUN The easiest way to create Virtual Tunnels over TCP / IP networks with traffic shaping, compression and encryption, http: //vtun.sourceforge.net/.
  • Wi-Fi protected Access Wi-Fi Alliance, version 1.2, December 2002.
  • the method described below typically applies to a scenario where the network operator realizes access control at the TCP / IP level and where the user wishes to use a tunnel such as [IPsec] in blocking mode.
  • the invention can find a relevant use in the IEEE 802.11 radio networks ([IEEE-802.11-1997] and [IEEE-802.11-1999]) of "first generation", that is to say which do not implement the new security features at level 2 of the [OSI] model such as WPA or 802. lli., and in the IEEE 802.3 ([IEEE 802.3-2002]) and Ethernet wired networks that perform access control according to the "captive portal" paradigm ".
  • a prerequisite for access control is authentication. Authentication allows the network operator to determine with certainty the identity of the user who seeks to use his network.
  • the network operator decides according to the identity of the user whether the latter is authorized or not to access the network.
  • This paradigm makes it possible to perform access control to TCP / IP networks:
  • the portal name captive When connected to the network, the user is invited to open his Internet browser, and his first request using the latter is automatically redirected to the authentication portal of the operator (hence the portal name captive).
  • This captive portal allows the user to authenticate securely, for example using SSL / [TLS] protocols.
  • All other requests from the unauthenticated user are blocked by a firewall that performs filtering by MAC address and / or IP address.
  • the firewall is updated to allow the traffic of this user.
  • the architecture of a captive portal thus implicates globally (Figure) a P_ACC access point, a PF firewall, the authentication portal itself PORT, and a database identification BDD.
  • the access point P_ACC offers a source terminal T_SOUR a wireless connection channel (Wi-Fi for example) to the Internet.
  • the PF firewall directly controls the access of the T_SOUR terminal to the Internet by filtering the packets (typically at the IP and TCP level), and by filtering by MAC address.
  • the PORT portal authenticates the user, intercepts requests from unauthenticated users, redirects these users to an authentication page, has his authentication data verified by the database BDD, modifies the rules of the firewall PF in function of the result of this check, and therefore pilot the state of the firewall.
  • the BDD database contains the valid data of authorized users, and responds to requests from the PORT portal.
  • the captive portal PORT uses an additional access control by token exchanged between the source terminal and the authentication portal.
  • the captive portal in fact keeps a secure communication channel open with the user, on which the user must present periodically, or event, an authentication token.
  • the failure to present this token causes the firewall to be reset in the blocking state for this user.
  • an unauthorized user spoofing the MAC address and / or IP address of an authorized user will not be able to present this token and will see its connection completed.
  • the mechanisms of operation of TCP / IP protocols will make unusable connections: the unauthorized user, if he wants to take advantage of the connection of the authorized user has, for the time being, no choice but to silence the authorized user, for example by denial of service. After shutting down the authorized user, the unauthorized user can only take advantage of the service as long as the captive portal does not require the presentation of the token, a time interval that can be configured at the PORT captive portal.
  • Hot-Spots using IEEE 802.11 technology and deployed in highly frequented locations, such as hotel receptions or airport waiting rooms, where the provision of an Internet connection has a high added value
  • the weak point of the known technique of captive portal which strengthens access control by filtering IP address and / or MAC address by an authentication token exchange, lies precisely in the fact that this technique assumes that the operator and the user are able to dialogue in order to exchange the token.
  • the security by token exchange is maintained and the user can not mount a tunnel in blocking mode, for example to the intranet of his company, because the first request for exchange of token after the establishment of the tunnel will fail and the user traffic will be blocked.
  • the invention enables the operator of a network to maintain effective access control to his network, even in the case where the user chooses to use a tunnel in blocking mode.
  • the "captive portal" paradigm with token exchange authentication is amended to allow two types of connection, namely (1) a basic mode connection type in which the user does not use a tunnel in blocking mode which would prevent communication with the network operator, this basic mode being identical to the known operation of the "captive portal” paradigm, and (2) a tunnel mode connection type, in which the user uses a blocking tunnel which prevents it from communicating with the network operator.
  • the captive portal When the captive portal is informed that the user wishes to use a tunnel in blocking mode, it deactivates the authentication by token exchange (which the user is no longer able to perform) and modifies the firewall rules to authorize only the traffic of the user corresponding to the tunnel established by him, this user being identified by his IP address and / or his MAC address, and the tunnel being for example identified by the source IP address, by the IP address of the destination terminal T_DEST, as well as by the transport protocol.
  • token exchange which the user is no longer able to perform
  • an unauthorized user should not only usurp the IP address and / or the MAC address of the authorized user but also insert into the tunnel established by the user , which can, on the one hand, be impossible insofar as the tunnel is protected by cryptographic techniques, and on the other hand, prove to be useless and uninteresting for the unauthorized user who has only communicate with the remote T_DEST host chosen as tunnel termination by the authorized user.
  • This transition can be made at the initiative of the user or the operator of the network.
  • the token exchange channel that he intends to establish a tunnel which will prevent him from communicating with the operator of the network. It can then communicate to the network operator the public characteristics of this tunnel (for example the source and destination IP addresses of this tunnel) in order to allow it to go into tunnel mode by modifying the PF firewall filtering rules. , or let the operator detect these characteristics and then switch to tunnel mode;
  • the public characteristics of this tunnel for example the source and destination IP addresses of this tunnel
  • the network operator switches the connection in the tunnel mode or not.
  • the network operator decides to no longer use the tunnel he has established and then sends an ordinary request outside this tunnel. This request is intercepted by the network operator (because it has changed the firewall rules by going into the tunnel mode) which performs the re-authentication the source terminal T_SOUR. In case of successful authentication and authorization, the network operator switches the tunnel mode connection to the basic mode;
  • the operator decides to no longer let the user use his tunnel and resets the rules of his PF firewall for this user, who sees his tunnel blocked. To try to reestablish his connection, this user must then authenticate with the portal, either as a new user or by using re-authentication mechanisms. In case of successful authentication and authorization, the network operator restores the connection in basic mode.
  • the user connects to the network whose access control is performed by the captive portal;
  • the network allows it to retrieve conventional connectivity information (IP address, DNS server addresses, default gateway addresses %), this is usually done using a DHCP exchange;
  • the user decides to authenticate with the network in order to have access to the services offered by the local site (typically the Internet);
  • the user sends a request to the Internet which is intercepted by the filtering engine (default rules) and redirected to the "captive portal".
  • the "captive portal” then presents the authentication page to the user;
  • the user enters his authentication data (typically a login number and a password) which will be validated by the "captive portal";
  • the "Captive Portal” interacts with the filter engine to change the default filtering rules for that user. At this time, the user is then able to communicate to the outside (typically the Internet) according to the new filtering rules communicated to the filtering engine;
  • the “captive portal” pushes a periodic authentication window to the user, this window makes it possible to maintain the session between the user and the captive portal thanks to the notion of authentication token.
  • This window is here called “session maintenance window”.
  • the session maintenance window can be written in HTML code, making it possible to initiate a connection periodically to a well-formatted URL (containing in particular the authentication token).
  • the mode transition mechanism is implemented in the token exchange channel, this specific mode allowing a dialogue authenticated by the token, and protected by TLS between the user and the "captive portal".
  • the invention consists here in providing, for a connection in tunnel mode, the provision by the user of additional information, such as for example the destination address of the tunnel (DNS name or IP address), that is to say say the address of the destination terminal T_DEST.
  • DNS name or IP address the destination address of the tunnel
  • the procedure used is valid and allowed, it causes the base mode to switch to tunnel mode by the following steps.
  • the "captive portal” receives the information identification of the required tunnel, which passes through the session maintenance window via the secure token exchange channel.
  • the "captive portal” analyzes the request containing the destination address of the tunnel.
  • This portal communicates to the filtering engine new filtering rules allowing only the communication between the user and the specified address and disables the session keeping window function. It is then based only on MAC / IP filtering and the new filtering rules function of the destination address of the tunnel.
  • the session maintenance window has an end tunnel mode button, and the user can specify that he wants to end the tunnel mode by activating this button of the session maintenance window.
  • the "captive portal” receives the information that passes through this session maintenance window, which is encrypted by TLS / SSL and authenticated by the authentication token.
  • the “captive portal” analyzes the request containing the end of tunnel mode information and communicates to the filtering engine new filtering rules, which are the same as for a conventional authenticated connection without tunnel mode. Finally, the "captive portal” reactivates the session maintenance window function.
  • the session maintenance window must therefore include:
  • this session maintenance window may also include an end of connection button for the end of tunnel establishment, that is, ie the transition from tunnel mode to basic mode.
  • tunneling can be initiated by either the user or the captive portal.
  • the user In the case where the user triggers the passage in tunnel mode, he must first retrieve a form from the captive portal and display it in his Internet browser. The user then fills in the form specifying the characteristics of the only flows he wishes to be authorized. It returns the completed form to the captive portal, which verifies the authenticity of the form and interprets it in terms of filtering rules.
  • the firewall In order to automate tunneling, it is the access control system that must take the initiative. For this, the firewall must be configured to react to the passage of data flows indicating the preparation of a connection in tunnel mode. When it recognizes one of these streams (for example, mounting an IPsec tunnel causes UDP 500 packets to pass), the firewall blocks it and sends a form to the user's browser that is causing it the detected flow.
  • the firewall pre-fills the form and presents it to the user who only has to validate or refuse the change of mode under the conditions specified in this form. If the user validates the form, then the captive portal goes into tunnel mode. The portal stops presenting a periodic authentication window to the user and sets up the strict rules, which allows the user to establish his tunnel. In the case where the form could not be completely pre-filled, the user must complete it before validation.
  • the user In the case where the user is the initiator of the transition in tunnel mode and where the form allows, the user has the opportunity to negotiate at once several tunnels (that is to say tunnels of different natures or to be set up for different machines).
  • the method of the invention is particularly easy to use with the IPsec protocol insofar as (a) the implementation of this protocol generally causes a passage of the user in blocking mode (the machine can no longer communicate with outside the IPsec tunnel), which forces tunneling to continue to work, and where (b) the streams that initialize the IPsec tunnel mount, ie IKE and its variants, are very characteristic because they use well known TCP / UDP ports, usually UDP 500. Because of this, the protocol IPsec adapts well to the automatic change of mode at the initiative of the captive portal.
  • tunnel construction protocols are effectively used in accordance with the invention, in particular the protocols named SSL and GRE for example, as well as less common encapsulations, such as PPP over SSH, or blocking mode implementations [VTUN]. .
  • protocols that are not explicitly used to mount a tunnel can also be used in the context of the invention, even if the need is not as obvious as with the tunnel construction protocols.
  • Captive portals generally use the "http" protocol and related tools (browser, runtime language such as Java or PHP, cryptographic protocols like SSL) to interact with the user. Nevertheless, any other functionally equivalent solution can be used for the implementation of the method of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un procédé de contrôle d'accès d'un terminal source (T_SOUR) à un réseau comportant notamment un pare-feu (PF) et un portail (PORT) d'authentification, ce portail plaçant et conservant le pare-feu dans un état d'autorisation d'accès en réponse à une requête initiale valide d'accès en mode de base émanant du terminal source, et à la fourniture périodique ultérieure d'un jeton d'authentification valide, le terminal source pouvant en outre communiquer en mode tunnel avec un terminal de destination (T_DEST) du réseau à travers un tunnel bloquant l'échange du jeton. Selon l'invention, le portail ne place et conserve le pare-feu dans son état d'autorisation d'accès pour une connexion en mode tunnel qu'en réponse à une requête préalable d'accès en mode tunnel, émanant du terminal source et incluant la fourniture au portail de données d'identification valides du tunnel.

Description

PROCEDE DE CONTROLE D'ACCES A UN RESEAU D'UN TERMINAL SOURCE UTILISANT UN TUNNEL EN MODE BLOQUANT.
L'invention concerne, de façon générale, les techniques d'accès à un réseau informatique.
Plus précisément, l'invention concerne un procédé de contrôle d'accès d'un terminal source à un réseau comportant un point d'accès pour ce terminal, un pare-feu relié au point d'accès, et un portail d'authentifîcation servi par une base de données d' authentification, ce portail plaçant le pare-feu dans un état d'autorisation d'accès en réponse à une requête initiale d'accès en mode de base émanant du terminal source et incluant la fourniture au portail de données d'authentifîcation valides, à défaut desquelles le pare-feu est placé dans un état d'interdiction d'accès, ce portail conservant le pare- feu dans un état d'autorisation d'accès en mode de base en réponse à la fourniture périodique, par le terminal source et sur un canal sécurisé d'échange de jeton, d'un jeton d'authentifîcation valide à défaut duquel le pare-feu est placé dans son état d'interdiction d'accès, et le terminal source communiquant sélectivement en mode tunnel avec un terminal de destination du réseau à travers un tunnel rendant le canal d'échange de jeton inutilisable.
Le contrôle d'accès à un réseau est la procédure par laquelle l'opérateur d'un réseau autorise ou n'autorise pas un usager potentiel à utiliser son réseau.
Or il existe des situations dans lesquelles il n'est, pour l'heure, plus possible à l'opérateur de maintenir le l'opérateur du réseau.
Pour des raisons fonctionnelles ou des raisons de sécurité, un usager d'un réseau peut en effet être amené à établir un tunnel vers un hôte distant, tunnel au sein duquel il encapsule son trafic. Selon la configuration et les logiciels utilisés, ce tunnel peut être en mode bloquant, c'est-à-dire rejeter toutes les communications qui n'emprunteraient pas ce tunnel dans le sens de la réception comme dans le sens de l'émission.
Ce mode bloquant constitue en fait une garantie de sécurité supplémentaire pour l'usager. En effet, dans le cas où un usager se connecte via un tunnel au réseau privé ou "intranet" de son entreprise, un pirate ne peut pas attaquer cet usager ni l'utiliser comme relais pour accéder à l'intranet de l'entreprise de ce dernier.
Dans ce contexte, l'invention a pour but de proposer un procédé qui permet à l'opérateur d'un réseau de maintenir le contrôle d'accès à son réseau, même dans le cas où un usager choisit d'utiliser un tunnel en mode bloquant.
A cette fin, le procédé de l'invention, par ailleurs conforme à la définition générique qu'en donne le preainbule ci-dessus, est essentiellement caractérisé en ce que le portail place et conserve le pare-feu dans son état d'autorisation d'accès pour une connexion en mode tunnel permettant une communication à travers le tunnel entre le terminal source et le terminal de destination en réponse à une requête préalable d'accès en mode tunnel émanant du terminal source et incluant la fourniture au portail, à travers le canal sécurisé d'échange de jeton, de données d'identification valides du tunnel.
Par exemple, les données d'identification du tunnel incluent une adresse du terminal de destination, une adresse du terminal source, et une identification du protocole du tunnel utilisé.
La requête préalable d'accès en mode tunnel peut répondre à une invitation adressée par le portail au terminal source à lui fournir des données d'identification valides pour une connexion en mode tunnel .
Une telle invitation peut être permanente, périodique, ou être déclenchée par la détection de préparatifs d'établissement d'une connexion en mode tunnel.
L'invitation adressée par le portail au terminal source à lui fournir des données d'identification valides pour une connexion en mode tunnel prend par exemple la forme d'une fenêtre de maintien de session utilisée également pour la connexion en mode de base, cette fenêtre de maintien de session comportant avantageusement un bouton de fin de connexion en mode tunnel .
En réponse à la détection d'une fin de connexion en mode tunnel émanant du terminal source, le portail adresse au terminal source une invitation à lui fournir des données d'authentifîcation valides pour retourner au mode de connexion de base . En toute hypothèse, le portail peut mettre sélectivement fin à une connexion en mode tunnel en plaçant le pare-feu dans son état d'interdiction d'accès.
L'invention concerne donc également un terminal source doté de moyens pour requérir une connexion de ce terminal source en mode tunnel bloquant avec un terminal de destination d'un réseau à travers un pare-feu contrôlé par un portail captif du réseau, ce terminal source étant caractérisé en ce qu'il est en outre doté de moyens d'identification propres à répondre à une invitation ponctuelle, permanente ou périodique d'identification adressée par le portail captif à ce terminal source en fournissant à ce portail captif, à travers un canal sécurisé d'échange de jeton, des données d'identification valides du tunnel, lesdits moyens d'identification étant avantageusement de nature logicielle.
L'invention concerne encore un portail captif doté de moyens pour autoriser conditionnellement une connexion en mode tunnel bloquant d'un terminal source avec un terminal de destination d'un réseau à travers un pare-feu contrôlé par ce portail captif, ce portail étant caractérisé en ce qu'il est en outre doté de moyens de contrôle propres à adresser au terminal source une invitation ponctuelle, permanente ou périodique d'identification requérant la fourniture, à travers un canal sécurisé d'échange de jeton, de données d'identification valides du tunnel, lesdits moyens de contrôle étant de préférence de nature logicielle.
D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est faite ci-après, à titre indicatif et nullement limitatif, en référence à la figure unique, qui représente schématiquement les moyens fonctionnels nécessaires à la mise en œuvre de l'invention.
Compte tenu de la nécessité, pour décrire dans le détail le procédé de l'invention d'une manière compréhensible pour l'homme du métier, d'utiliser le vocabulaire standard de ce dernier, le lecteur peu familier du domaine concerné trouvera ci-après les définitions et références utiles à sa propre compréhension de la description.
I . DEFINITIONS .
Adresse IP : Adresse d'un équipement utilisant IP (voir ce mot) comme protocole de couche 3 du modèle OSI (voir ce mot) .
Adresse MAC : Adresse d'un équipement connecté à un médium partagé utilisé par la couche 2 du modèle OSI (voir ce mot) .
DHCP (Acronyme tiré de l'anglais "Dynamic Host Configuration Protocol") : Protocole d'attribution dynamique des adresses sur un réseau IP (voir ce mot) .
DNS (Acronyme tiré de l'anglais "Domain Name Server" ou "Domain Name System") : Service essentiel de l'Internet assurant la conversion des noms de domaines en adresses IP (voir ce mot) . HTML (Acronyme tiré de l'anglais "HyperText Markup Language") : Format de document Internet défini par la Norme RFC 1866.
IP (Acronyme tiré de l'anglais "Internet Protocol") : Protocole de niveau réseau utilisé dans 1 ' Internet orienté sans connexion (principe du datagramme) .
IPsec (Acronyme tiré de l'anglais "Internet Protocol Security" ) : Protocole de sécurité utilisé dans l'Internet.
MAC (Acronyme tiré de l'anglais "Médium Access Control") : Terme général désignant la couche qui gère le partage d'un support de transmission entre différentes stations.
Open Source (Expression anglaise) : Logiciel libre répondant à des exigences qualitatives définies.
OSI (Acronyme tiré de l'anglais "Open System Interconnection") : Modèle d'interconnexion des systèmes ouverts où 1 ' ensemble des actions permettant de faire coopérer plusieurs équipements informatiques est structuré en couches correspondant à des niveaux de détails différents .
PHP (Acronyme tiré de l'anglais "PHP Hypertext
Preprocessor" ) : Langage de script orienté objet, de libre utilisation, permettant de gérer complètement un site Internet .
SSL (Acronyme tiré de l'anglais "Secure Socket Layer") : Norme de mode de communication sécurisée sur réseau, initialement utilisée par le navigateur de marque "Netscape", puis officialisée.
TCP (Acronyme tiré de l'anglais "Transport Control Protocol") : Protocole de transport orienté connexion, permettant un échange fiable d'une quantité quelconque de données entre deux équipements (niveau 4 OSI - voir ce mot) reliés par un ou plusieurs réseaux utilisant IP (voir ce mot) .
TLS (Acronyme tiré de l'anglais "Transport Layer
Security" ) : Protocole de sécurisation de la couche transport, défini par la norme RFC 2246. La version 1.0 de TLS est en fait la version 3 de SSL (voir ce mot) .
UDP (Acronyme tiré de l'anglais "User Datagram Protocol") : Protocole de transport de blocs de données indépendants, ou "paquets", transitant sur un réseau et contenant toutes les informations nécessaires à leur routage.
URL (Acronyme tiré de l'anglais "Uniform Resource Locator") : Format d'adresse permettant de retrouver une ressource.
VPN (Acronyme tiré de l'anglais "Virtual Private Network") : Réseau privé virtuel.
II . RÉFÉRENCES .
[IEEE-802.1X-2001] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port- Based Network Access Control", IEEE Standard 802. IX, Septembre 2001.
[IEEE 802.3-2002] IEEE Standard for Information technology Télécommunications and information exchange between Systems - Local and metropolitan area networks - Spécifie requirements - Part 3 : Carrier Sensé Multiple Access with Collision Détection (CSMA/CD) Access Method and Physical Layer Spécifications.
[IEEE-802.11-1997] Institute of Electrical and Electronics Engineers, "Information Technology - Télécommunications and Information Exchange between Systems - Local and Metropolitan Area Network -Spécifie Requirements - Part 11: Wireless LAN Médium Access Control (MAC) and Physical Layer (PHY) Spécifications", IEEE Standard 802.11, 1997.
[IEEE-802.11-1999] Institute of Electrical and Electronics Engineers, "Information Technology - Télécommunications and Information Exchange between Systems - Local and Metropolitan Area Network - Spécifie Requirements - Part II: Wireless LAN Médium Access Control (MAC) and Physical Layer (PHY) Spécifications", IEEE Standard 802.11, 1999.
[IEEE-802.lli] Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplément to Standard for Télécommunications and Information Exchange Between Systems - LAN/MAN Spécifie Requirements - Part II: Wireless LAN Médium Access Control (MAC) and Physical Layer (PHY) Spécifications: Spécification for Enhanced Security" , IEEE Draft 802. lli (work in progress) , 2003.
[IPsec] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, Novembre 1998.
[OSI] International Organization for Standardization, "Open Systems Interconnexion", ISO 7498.
[TLS] Dierks, T. and Allen, c, "The TLS Protocol version 1.0", RFC 2246, Janvier 1999.
[VTUN] The easiest way to create Virtual Tunnels over TCP/IP networks with traffic shaping, compression and encryption, http: //vtun.sourceforge.net/ .
[WPA] Wi-Fi protected Access, Wi-Fi Alliance, version 1.2, Décembre 2002.
Le procédé décrit ci-après s'applique typiquement à un scénario où l'opérateur du réseau réalise un contrôle d'accès au niveau TCP/IP et où l'usager souhaite utiliser un tunnel tel que [IPsec] en mode bloquant.
L'invention peut trouver un usage pertinent dans les réseaux radioélectriques IEEE 802.11 ( [IEEE-802.11-1997] et [IEEE-802.11-1999] ) de «première génération», c'est à dire qui ne mettent pas en oeuvre les nouvelles fonctionnalités de sécurité au niveau 2 du modèle [OSI] comme WPA ou 802. lli., et dans les réseaux filaires IEEE 802.3 ([IEEE 802.3-2002]) et Ethernet qui réalisent un contrôle d'accès selon le paradigme de «portail captif».
III. ETAT DE LA TECHNIQUE ANTÉRIEURE Un préliminaire au contrôle d'accès est 1 ' authentification. L' authentification permet à l'opérateur du réseau de déterminer avec certitude l'identité de l'usager qui cherche à utiliser son réseau.
Pour authentifier un usager, l'opérateur d'un réseau doit dialoguer avec ce dernier.
En cas d'authentifîcation réussie, l'opérateur du réseau décide en fonction de l'identité de l'usager si ce dernier est autorisé ou non à accéder au réseau.
Afin d'éviter que des usagers illégitimes ne profitent indûment du réseau, il est nécessaire pour le contrôle d'accès :
- de s'assurer que seuls les usagers que l'opérateur a autorisés peuvent utiliser le réseau, c'est-à-dire d'éviter qu'un usager non-autorisé ne puisse utiliser le réseau; et de maintenir la relation d'authentifîcation avec l'usager, c'est-à-dire de s'assurer que l'usager autorisé qui utilise le réseau est bien le même que celui qui s'est authentifié, afin d'éviter qu'un usager non-autorisé usurpe l'identité d'un usager autorisé.
Plusieurs techniques permettent de réaliser un contrôle d'accès au réseau, en particulier : des techniques physiques : par exemple les prises permettant d'accéder au réseau sont situées dans des locaux fermés à clefs; et
- des techniques logiques : par exemple l'accès au réseau est conditionné par la possession d'un secret permettant d'employer des techniques cryptographiques.
En l'absence de mécanismes de sécurité incluant le contrôle d'accès au niveau 2 (lien de données) du modèle à sept couches de l' [OSI] ou du fait des coûts liés au déploiement de tels mécanismes quand ils existent et du très faible taux de pénétration de ces derniers dans le parc d'équipement des usagers, le paradigme du «portail captif» a été développé .
Ce paradigme permet de réaliser un contrôle d'accès aux réseaux TCP/IP :
- en réalisant un filtrage sur les adresses MAC et IP; et
- en utilisant des jetons d'authentifîcation échangés entre le terminal source et le portail d'authentifîcation.
Lors de sa connexion au réseau, l'usager est invité à ouvrir son navigateur Internet, et sa première requête à 1 ' aide de ce dernier est automatiquement redirigée vers le portail d'authentifîcation de l'opérateur (d'où le nom de portail captif). Ce portail captif permet à l'usager de s'authentifier de manière sécurisée, par exemple en utilisant les protocoles SSL/ [TLS] .
Toutes les autres requêtes de l'usager non-authentifié sont bloquées par un pare-feu qui réalise un filtrage par adresse MAC et/ou adresse IP. En cas d'authentifîcation réussie et dans le cas où l'usager authentifié est autorisé à accéder au réseau, le pare-feu est mis à jour pour laisser passer le trafic de cet usager.
L'architecture d'un portail captif implique ainsi globalement (figure) un point d'accès P_ACC, un pare-feu PF, le portail d'authentifîcation lui-même PORT, et une base de données d'identification BDD.
Le point d'accès P_ACC offre à un terminal source T_SOUR une voie de connexion sans fil (Wi-Fi par exemple) au réseau Internet .
Le pare-feu PF contrôle directement l'accès du terminal T_SOUR au réseau Internet en filtrant les paquets (typiquement au niveau IP et TCP) , et en opérant un filtrage par adresse MAC.
Le portail PORT authentifie l'usager, intercepte les requêtes des usagers non-authentifiés, redirige ces usagers vers une page d'authentifîcation, fait vérifier ses données d'authentifîcation par la base de données BDD, modifie les règles du pare-feu PF en fonction du résultat de cette vérification, et pilote donc l'état du pare-feu.
La base de données BDD contient quant à elle les données valides des usagers autorisés, et répond aux requêtes du portail PORT.
Comme le contrôle d'accès par adresse MAC et adresse IP est intrinsèquement faible (il est en effet très facile, par simple manipulation logicielle, d'usurper l'adresse MAC et l'adresse IP d'un usager), le portail captif PORT utilise un contrôle d'accès supplémentaire par jeton échangé entre le terminal source et le portail d'authentifîcation.
Le portail captif garde en effet un canal de communication sécurisé ouvert avec l'usager, sur lequel l'usager doit présenter périodiquement, ou sur événement, un jeton d'authentifîcation. Le défaut de présentation de ce jeton entraîne la réinitialisation du pare-feu dans l'état bloquant pour cet usager. Ainsi, un usager non-autorisé usurpant l'adresse MAC et/ou l'adresse IP d'un usager autorisé ne pourra pas présenter ce jeton et verra sa connexion terminée. Même si la présence simultanée d'un usager autorisé chargé de présenter le jeton et d'un usager non-autorisé usurpant l'adresse MAC et l'adresse IP de cet usager autorisé est envisageable, les mécanismes de fonctionnement des protocoles TCP/IP rendront les connexions inutilisables: l'usager non-autorisé, s'il veut profiter de la connexion de l'usager autorisé n'a, pour l'heure, pas d'autre choix que de faire taire l'usager autorisé, par exemple par du déni de service. Après avoir fait taire l'usager autorisé, l'usager non-autorisé ne peut profiter du service que tant que le portail captif n'exige pas la présentation du jeton, intervalle de temps qui peut être configuré au niveau du portail captif PORT.
Le paradigme de «portail captif» tel que décrit jusqu'à présent s'applique, par exemple, tant aux réseaux radioélectriques utilisant la technologie IEEE 802.11 qu'aux réseaux locaux filaires utilisant les technologies IEEE 802.3/Ethernet. Dans le cas des réseaux radioélectriques utilisant la technologie IEEE 802.11, les mécanismes de sécurité prévus à l'origine dans la norme [IEEE802.11-1997] et [IEEE802.il- 1999] ont rapidement révélé des problèmes majeurs qui rendent leur utilisation tout aussi compliquée qu'inefficace: c'est la faillite consommée en 2000 et 2001 des mécanismes de sécurité connus sous l'acronyme "WEP".
Bien que des mécanismes de sécurité plus robustes soient en cours de déploiement [WPA] ou de spécification [IEEE- 802. lli], ils ne présentent pas à l'heure actuelle de maturité suffisante pour être déployés à grande échelle.
Deux scénarios dans lesquels le paradigme de «portail captif» s'applique aux réseaux radioélectriques utilisant la technologie IEEE 802.11 sont :
- les réseaux radioélectriques locaux, appelés "Hot-Spots", utilisant la technologie IEEE 802.11 et déployés dans des lieux très fréquentés, par exemple les réceptions d'hôtels ou les salles d'attente d'aéroport, où la mise à disposition d'une connexion à Internet présente une forte valeur ajoutée; et
- les accès à un réseau offerts par une entreprise à ses visiteurs pour permettre à ces derniers de travailler plus efficacement, par exemple dans les salles de réunion.
Dans le cas des réseaux locaux filaires utilisant les technologies IEEE 802.3/Ethernet, aucun mécanisme de sécurité n'a été prévu à l'origine. Ce n'est qu'en 2001, avec l'adoption de la norme [IEEE802.1X-2001] , que des mécanismes de sécurité ont vu le jour pour ces réseaux.
Cependant leur taux de pénétration dans le parc des équipements usagers est encore faible. C'est pour cela qu'une entreprise souhaitant offrir un accès réseau à ses visiteurs, par exemple en salle de réunion, peut être amenée à utiliser le paradigme de «portail captif».
Le point faible de la technique connue de portail captif, qui renforce le contrôle d'accès par filtrage d'adresse IP et/ou adresse MAC par un échange de jeton d'authentifîcation, réside justement dans le fait que cette technique suppose que l'opérateur et l'usager soient capables de dialoguer pour pouvoir s'échanger le jeton.
Or, l'application la plus typique utilisée par les usagers dans les scénarios présentés précédemment consiste pour ces usagers à monter un tunnel (créant ainsi un VPN) vers l'intranet de leur entreprise.
Pour des raisons de sécurité, la plupart des applications de VPN empêchent alors toutes les communications à destination ou en provenance de l'usager, autres que celles qui passent à l'intérieur du VPN. Il s'agit donc de tunnels en mode bloquant .
Dans ce cas, il n'est donc plus possible de maintenir l'échange du jeton d'authentifîcation, et aucune solution n'est disponible à l'heure actuelle pour résoudre ce problème. En conséquence :
- soit la sécurisation par échange de jeton est alors purement et simplement abandonnée dans le paradigme de «portail captif», auquel cas le contrôle d'accès au réseau ne consiste plus qu'en un filtrage par adresse IP et/ou adresse MAC, ce qui présente des vulnérabilités critiques,
- soit la sécurisation par échange de jeton est maintenue et l'usager ne peut pas monter un tunnel en mode bloquant, par exemple vers l'intranet de son entreprise, car la première demande d'échange de jeton postérieure à l'établissement du tunnel échouera et le trafic de l'usager sera bloqué.
IV. PRINCIPE DE L ' INVENTION
L'invention permet à l'opérateur d'un réseau de maintenir un contrôle d'accès efficace à son réseau, même dans le cas où l'usager choisit d'utiliser un tunnel en mode bloquant.
Pour ce faire, le paradigme de «portail captif» avec authentification par échange de jeton est amendé pour permettre deux types de connexion, à savoir (1) un type de connexion en mode de base dans lequel l'usager n'utilise pas de tunnel en mode bloquant qui 1 ' empêcherait de communiquer avec l'opérateur du réseau, ce mode de base étant identique au fonctionnement connu du paradigme de «portail captif», et (2) un type de connexion en mode tunnel, dans lequel l'usager utilise un tunnel en mode bloquant qui 1 ' empêche de communiquer avec 1 ' opérateur du réseau. Lorsque le portail captif est informé que l'usager souhaite utiliser un tunnel en mode bloquant, il désactive 1 ' authentification par échange de jeton (que l'usager n'est plus en mesure d'effectuer) et modifie les règles du pare- feu pour ne plus autoriser que le trafic de l'usager correspondant au tunnel établi par lui, cet usager étant identifié par son adresse IP et/ou son adresse MAC, et le tunnel étant par exemple identifié par l'adresse IP source, par l'adresse IP du terminal de destination T_DEST, ainsi que par le protocole de transport.
Ainsi, pour usurper l'identité de l'usager autorisé, un usager non autorisé devrait non seulement usurper l'adresse IP et/ou l'adresse MAC de l'usager autorisé mais aussi s'insérer dans le tunnel établi par l'usager, ce qui peut, d'une part, s'avérer impossible dans la mesure où le tunnel est protégé par des techniques cryptographiques, et d'autre part, se révéler inutile et inintéressant pour l'usager non-autorisé qui n'a que faire de communiquer avec l'hôte distant T_DEST choisi comme terminaison du tunnel par l'usager autorisé.
Pour permettre ces transitions, les fonctionnalités du canal servant à échanger le jeton dans le mode de base sont étendues : désormais 1 ' opérateur et ses usagers peuvent en plus échanger de manière sécurisée des informations de transition via ce canal.
A . Transi tion du mode de base vers le mode tunnel .
Cette transition peut s'effectuer à l'initiative de l'usager ou de l'opérateur du réseau.
Pour ce faire :
- soit l'usager signale, à l'aide du canal d'échange du jeton, qu'il compte établir un tunnel qui l'empêchera de communiquer avec l'opérateur du réseau. Il peut alors communiquer à l'opérateur du réseau les caractéristiques publiques de ce tunnel (par exemple les adresses IP source et destination de ce tunnel) afin de lui permettre de passer dans le mode tunnel en modifiant les règles de filtrage du pare-feu PF, ou laisser l'opérateur détecter ces caractéristiques puis basculer dans le mode tunnel ;
- soit l'opérateur du réseau détecte que l'usager est en train d'établir un tunnel, avertit l'usager de la détection de cette opération via le canal d'échange du jeton, et lui présente pour confirmation les caractéristiques publiques détectées de ce tunnel via le canal d'échange du jeton. En réponse à la confirmation ou à 1 ' infirmation reçue de l'usager en mode sécurisé, l'opérateur du réseau bascule ou non la connexion dans le mode tunnel .
B. Transi tion du mode tunnel vers le mode de base .
Cette transition s'effectue à l'initiative de l'usager ou de l'opérateur du réseau. Ainsi :
- soit l'usager décide de ne plus utiliser le tunnel qu'il a établi et envoie alors une requête ordinaire en dehors de ce tunnel. Cette requête est interceptée par l'opérateur du réseau (car il a modifié les règles du pare-feu en passant dans le mode tunnel) qui procède à la ré-authentification du terminal source T_SOUR. En cas d'authentifîcation réussie et d'autorisation, l'opérateur du réseau bascule la connexion du mode tunnel vers le mode de base;
- soit l'opérateur décide de ne plus laisser l'usager utiliser son tunnel et réinitialise les règles de son pare- feu PF pour cet usager, qui voit donc son tunnel bloqué. Pour chercher à rétablir sa connexion, cet usager doit alors s'authentifier auprès du portail, soit comme un nouvel utilisateur, soit en utilisant des mécanismes de ré- authentification. En cas d'authentifîcation réussie et d'autorisation, l'opérateur du réseau rétablit la connexion en mode de base.
V. DESCRIPTION D'UN MODE PARTICULIER DE RÉALISATION DE L'INVENTION.
Dans cette partie de la description, qui explique comment le procédé de 1 ' invention peut être mis en oeuvre dans un mécanisme connu de contrôle d'accès par «portail captif», seules sont décrites les transitions du mode de base vers le mode tunnel (ou inversement) à l'initiative de l'usager. Le principe de basculement entre ces deux modes de fonctionnement est équivalent, que ce basculement intervienne à l'initiative de l'usager ou de l'opérateur.
A. Rappel du contexte actuel .
On présente ici le mode de fonctionnement classique d'une connexion d'un usager à un réseau supportant la technologie de «portail captif». Cette technologie est mise en oeuvre dans de nombreux produits commerciaux, et est disponible également dans un produit Open Source appelé NoCatAuth (notamment décrit sur le site http://nocat.net).
Cette solution de «portail captif» Open Source pilote plusieurs moteurs de filtrage Open Source comme "iptables", "packetfilter" ou "IPFilter", respectivement décrits sur les sites : http://iptables.org, http://www.benzedrine.cx/pf.html, et http://www.ipfilter.org.
Il permet de piloter ces moteurs de filtrage grâce à un dialogue entre le portail captif et une application pilotant le moteur de filtrage.
Les étapes du processus standard de connexion sont les suivantes .
1. L'usager se connecte au réseau dont le contrôle d'accès est réalisé par le portail captif;
2. Le réseau lui permet de récupérer les informations de connectivité classique (adresse IP, adresses serveurs DNS, adresses passerelle par défaut...), ceci étant généralement effectué à l'aide d'un échange DHCP;
3. L'usager décide de s'authentifier auprès du réseau afin d'avoir accès aux services offerts par le site local (typiquement l'Internet);
4. L'usager envoie une requête vers l'Internet qui est interceptée par le moteur de filtrage (règles par défaut) et redirigée vers le «portail captif». Le «portail captif» présente alors la page d'authentifîcation à l'usager;
5. L'usager entre ses données d'authentifîcation (typiquement un numéro de connexion et un mot de passe) qui seront validées par le «portail captif»;
6. Le «portail captif» interagit avec le moteur de filtrage de manière à modifier les règles de filtrage par défaut pour cet utilisateur. A ce moment-là, l'usager est alors capable de communiquer vers l'extérieur (typiquement l'Internet) en fonction des nouvelles règles de filtrage communiquées au moteur de filtrage;
7. Le« portail captif» pousse une fenêtre d'authentifîcation périodique à l'usager, cette fenêtre permet de maintenir la session entre l'usager et le portail captif grâce à la notion de jeton d'authentifîcation. Cette fenêtre est ici dénommée «fenêtre de maintien de session».
En pratique, la fenêtre de maintien de session peut être écrite en code HTML, permettant d'initier une connexion de manière périodique vers une URL bien formatée (contenant en particulier le jeton d'authentifîcation).
B. Mise en œuvre de 1 'invention dans le contexte rappelé ci-dessus .
La mise en œuvre de l'invention dans le système de «portail captif» conduit à affiner les règles de la stratégie de sécurité du mécanisme de filtrage, afin de n'autoriser que les flux explicitement déclarés par l'usager.
Le mécanisme de transition entre modes est mis en oeuvre dans le canal d'échange de jeton, ce mode spécifique permettant un dialogue authentifié grâce au jeton, et protégé par TLS entre l'usager et le «portail captif».
L'invention consiste ici à prévoir, pour une connexion en mode tunnel, la fourniture par l'usager d'une information supplémentaire, comme par exemple l'adresse destination du tunnel (nom DNS ou adresse IP) , c'est-à-dire l'adresse du terminal de destination T_DEST.
Une fois connecté en mode de base, l'usager dispose ainsi de deux options .
Soit il ne désire pas établir de tunnel, auquel cas il n'a besoin de fournir aucune information supplémentaire par rapport à la situation de l'art antérieur, et la session se poursuit classiquement en mode de base.
Soit l'usager désire établir un tunnel, auquel cas il utilise la fenêtre de maintien de session utilisateur pour spécifier le tunnel qu'il souhaite emprunter, par exemple en indiquant l'adresse de destination du tunnel.
Si la procédure utilisée est valide et autorisée, elle provoque le basculement du mode de base dans le mode tunnel par les étapes suivantes .
Tout d'abord, le «portail captif» reçoit l'information d'identification du tunnel requis, qui transite dans la fenêtre de maintien de session via le canal sécurisé d'échange de jeton. Le «portail captif» analyse alors la requête contenant l'adresse de destination du tunnel. Ce portail communique au moteur de filtrage de nouvelles règles de filtrage n'autorisant que la communication entre l'usager et l'adresse spécifiée et désactive la fonction de fenêtre de maintien de session. Il se base alors uniquement sur un filtrage MAC / IP et les nouvelles règles de filtrage fonctions de l'adresse de destination du tunnel.
Une fois connecté en mode tunnel, l'usager dispose de deux options .
Soit il ne désire plus maintenir le tunnel ni communiquer en dehors du tunnel, auquel cas il peut se déconnecter brutalement. Cette connexion ne pourra pas être utilisée de manière frauduleuse car les règles de filtrage n'autorisent que le tunnel préalablement établi, ce qui n'a que peu d'intérêt pour l'attaquant. Pour se déconnecter proprement, l'usager peut spécifier dans la fenêtre de maintien de session qu'il désire terminer sa session. Ceci a pour effet de considérer l'usager comme non authentifié et de remettre les règles de filtrage par défaut.
Soit l'usager désire fermer son tunnel mais continuer à communiquer en mode de base après la fermeture du tunnel. Si la procédure utilisée par l'usager est valide et autorisée, elle provoque le basculement du mode tunnel dans le mode de base de la façon suivante.
En fait, dès que l'usager ferme son tunnel, qui est en mode bloquant, il peut communiquer vers l'extérieur. Par exemple, la fenêtre de maintien de session est dotée d'un bouton de fin de mode tunnel, et l'usager peut spécifier qu'il veut mettre fin au mode tunnel en activant ce bouton de la fenêtre de maintien de session. Le «portail captif» reçoit 1 ' information qui transite dans cette fenêtre de maintien de session, qui est chiffrée par TLS / SSL et qui est authentifiée par le jeton d'authentifîcation. Le «portail captif» analyse alors la requête contenant 1 ' information de fin de mode tunnel et communique au moteur de filtrage de nouvelles règles de filtrage, qui sont les mêmes que pour une connexion classique authentifiée sans mode tunnel. Enfin, le "portail captif" réactive la fonction de fenêtre de maintien de session.
En résumé, la fenêtre de maintien de session doit donc comprendre:
- les informations nécessaires à l'établissement du mode de base (par exemple adresse IP, jeton d'authentifîcation...), et un formulaire pour l'établissement du mode tunnel (requérant par exemple l'adresse de destination et l'identification du protocole utilisé par le tunnel), et qui permet la transition du mode de base vers le mode tunnel , cette fenêtre de maintien de session pouvant également comprendre un bouton de fin de connexion pour la fin d'établissement de tunnel, c'est-à-dire la transition du mode tunnel vers le mode de base. VI . VARIANTES
Le procédé précédemment décrit peut être complété ou adapté au contexte de l'invention selon plusieurs variantes, l'utilisation de ces variantes étant conditionnée par les capacités du terminal source T_SOUR.
Tout d'abord, le passage en mode tunnel peut se faire à l'initiative soit de l'usager soit du portail captif.
Dans le cas où c'est l'usager qui déclenche le passage en mode tunnel, il doit d'abord récupérer un formulaire auprès du portail captif et l'afficher dans son navigateur Internet. L'usager remplit alors le formulaire en spécifiant les caractéristiques des seuls flux qu'il souhaite se voir autoriser. Il renvoie le formulaire rempli au portail captif, qui vérifie l'authenticité du formulaire et l'interprète en termes de règles de filtrage.
Dans une optique d'automatisation du passage en mode tunnel, c'est le système de contrôle d'accès qui doit prendre l'initiative. Pour cela le pare-feu doit être configuré pour réagir au passage de flux de données indiquant la préparation d'une connexion en mode tunnel. Lorsqu'il reconnaît un de ces flux (par exemple le montage d'un tunnel IPsec provoque le passage de paquets UDP 500), le pare-feu le bloque et envoie un formulaire dans le navigateur de l'usager qui est à l'origine du flux détecté.
Si le pare-feu dispose de suffisamment d'informations avec les données qu'il a pu détecter, alors il pré-remplit le formulaire et le présente à l'usager qui n'a plus qu'à valider ou refuser le changement de mode aux conditions précisées dans ce formulaire. Si l'usager valide le formulaire, alors le portail captif passe en mode tunnel. Le portail cesse de présenter une fenêtre d'authentifîcation périodique à l'usager et met en place les règles strictes, ce qui permet à l'usager d'établir son tunnel. Dans le cas où le formulaire n'a pu être complètement pré-rempli, l'usager doit le compléter avant validation.
Dans le cas où c'est l'usager qui est à l'initiative du passage en mode tunnel et où le formulaire le permet, l'usager a la possibilité de négocier d'un coup plusieurs tunnels (c'est-à-dire des tunnels de natures différentes ou à établir à destination de machines différentes) .
Tous les types de flux, pourvu qu'il soit possible de les désigner dans un formulaire tel qu'évoqué au point précédent, peuvent faire l'objet d'un filtrage par le portail captif.
Toutefois, le procédé de l'invention est particulièrement facile à utiliser avec le protocole IPsec dans la mesure où (a) la mise en œuvre de ce protocole provoque généralement un passage de l'usager en mode bloquant (la machine ne peut plus communiquer en dehors du tunnel IPsec) , ce qui impose le passage en mode tunnel pour pouvoir continuer à fonctionner, et où (b) les flux qui initialisent le montage d'un tunnel IPsec, c'est-à-dire IKE et ses variantes, sont très caractéristiques car ils utilisent des ports TCP/UDP bien connus, généralement UDP 500. De ce fait, le protocole IPsec s'adapte bien au changement automatique de mode à l'initiative du portail captif.
Néanmoins d'autres protocoles de construction de tunnels sont efficacement utilisables conformément à l'invention, notamment les protocoles nommés SSL et GRE par exemple, ainsi que des encapsulations moins courantes, tels que PPP over SSH, ou des implémentations [VTUN] en mode bloquant.
Enfin, les protocoles qui ne servent pas explicitement à monter un tunnel ("http" ou "telnet" par exemple) peuvent aussi être utilisés dans le cadre de l'invention, même si le besoin n'est pas aussi flagrant qu'avec les protocoles de construction de tunnels.
Les portails captifs utilisent généralement le protocole "http" et les outils connexes (navigateur, langage d'exécution comme Java ou PHP, protocoles cryptographiques comme SSL) pour dialoguer avec l'usager. Néanmoins, toute autre solution fonctionnellement équivalente peut être utilisée pour la mise en œuvre du procédé de l'invention.

Claims

REVENDICATIONS
1. Procédé de contrôle d'accès d'un terminal source (T_SOUR) à un réseau comportant un point d'accès (P_ACC) pour ce terminal, un pare-feu (PF) relié au point d'accès (P_ACC) , et un portail (PORT) d'authentifîcation servi par une base (BDD) de données d'authentifîcation, ce portail (PORT) plaçant le pare-feu (PF) dans un état d'autorisation d'accès en réponse à une requête initiale d'accès en mode de base émanant du terminal source (T_SOUR) et incluant la fourniture au portail (PORT) de données d'authentifîcation valides, à défaut desquelles le pare-feu est placé dans un état d'interdiction d'accès, ce portail (PORT) conservant le pare-feu (PF) dans un état d'autorisation d'accès en mode de base en réponse à la fourniture périodique, par le terminal source (T_SOUR) et sur un canal sécurisé d'échange de jeton, d'un jeton d'authentifîcation valide à défaut duquel le pare-feu (PF) est placé dans son état d'interdiction d'accès, et le terminal source (T_SOUR) communiquant sélectivement en mode tunnel avec un terminal de destination (T_DEST) du réseau à travers un tunnel rendant le canal d'échange de jeton inutilisable, caractérisé en ce que le portail (PORT) place et conserve le pare-feu (PF) dans son état d'autorisation d'accès pour une connexion en mode tunnel permettant une communication à travers le tunnel entre le terminal source (T_SOUR) et le terminal de destination (T_DEST) en réponse à une requête préalable d'accès en mode tunnel émanant du terminal source
(T_SOUR) et incluant la fourniture au portail (PORT) , à travers le canal sécurisé d'échange de jeton, de données d'identification valides du tunnel.
2. Procédé de contrôle d'accès suivant la revendication 1, caractérisé en ce que les données d'identification du tunnel incluent une adresse du terminal de destination (T_DEST) .
3. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce que les données d'identification du tunnel incluent une adresse du terminal source (T_SOUR) et, éventuellement, une identification du protocole utilisé par le tunnel.
4. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce que la requête préalable d'accès en mode tunnel répond à une invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel.
5. Procédé de contrôle d'accès suivant la revendication 4, caractérisé en ce que l'invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel est permanente ou périodique .
6. Procédé de contrôle d'accès suivant la revendication 4, caractérisé en ce que l'invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel est déclenchée par la détection de préparatifs d'établissement d'une connexion en mode tunnel.
7. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes combinée à la revendication 4, caractérisé en ce que l'invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir -des données d'identification valides pour une connexion en mode tunnel prend la forme d'une fenêtre de maintien de session utilisée également pour la connexion en mode de base.
8. Procédé de contrôle d'accès suivant la revendication 7, caractérisé en ce que la fenêtre de maintien de session comporte un bouton de fin de connexion en mode tunnel .
9. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce qu'en réponse à la détection d'une fin de connexion en mode tunnel émanant du terminal source (T_SOUR) , le portail (PORT) adresse au terminal source (T_SOUR) une invitation à lui fournir des données d'authentifîcation valides pour retourner au mode de connexion de base.
10. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce que le portail (PORT) met sélectivement fin à une connexion en mode tunnel en plaçant le pare-feu (PF) dans son état d'interdiction d'accès.
11. Terminal source (T_SOUR) doté de moyens pour requérir une connexion de ce terminal source en mode tunnel bloquant avec un terminal de destination (T_DEST) d'un réseau à travers un pare-feu (PF) contrôlé par un portail captif (PORT) du réseau, caractérisé en ce qu'il est en outre doté de moyens d'identification propres à répondre à une invitation ponctuelle, permanente ou périodique d'identification adressée par le portail captif (PORT) à ce terminal source (T_SOUR) en fournissant à ce portail captif (PORT), à travers un canal sécurisé d'échange de jeton, des données d'identification valides du tunnel.
12. Terminal source (T_SOUR) suivant la revendication 11, caractérisé en ce que lesdits moyens d'identification sont de nature logicielle.
13. Portail captif (PORT) doté de moyens pour autoriser conditionnellement une connexion en mode tunnel bloquant d'un terminal source (T_SOUR) avec un terminal de destination (T_DEST) d'un réseau à travers un pare-feu (PF) contrôlé par ce portail captif (PORT) , caractérisé en ce qu'il est en outre doté de moyens de contrôle propres à adresser au terminal source (T_SOUR) une invitation ponctuelle, permanente ou périodique d'identification requérant la fourniture, à travers un canal sécurisé d'échange de jeton, de données d'identification valides du tunnel .
14. Portail captif (PORT) suivant la revendication 13, caractérisé en ce que lesdits moyens de contrôle sont de nature logicielle.
PCT/FR2005/000303 2004-02-18 2005-02-10 Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant WO2005091565A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0401623 2004-02-18
FR0401623A FR2866496A1 (fr) 2004-02-18 2004-02-18 Procede de controle d'acces a un reseau d'un terminal source utilisant un tunnel en mode bloquant

Publications (2)

Publication Number Publication Date
WO2005091565A1 true WO2005091565A1 (fr) 2005-09-29
WO2005091565A9 WO2005091565A9 (fr) 2006-06-22

Family

ID=34803451

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/000303 WO2005091565A1 (fr) 2004-02-18 2005-02-10 Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant

Country Status (2)

Country Link
FR (1) FR2866496A1 (fr)
WO (1) WO2005091565A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020169980A1 (en) * 1998-12-01 2002-11-14 David Brownell Authenticated firewall tunneling framework
US20030156566A1 (en) * 2002-02-20 2003-08-21 Doug Griswold Mobile data communications apparatus, methods and computer program products implementing cellular wireless data communications via a wireless local area network
WO2003093951A2 (fr) * 2002-05-04 2003-11-13 Instant802 Networks Inc. Point d'acces ameliore et controleur de reseau sans fil

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020169980A1 (en) * 1998-12-01 2002-11-14 David Brownell Authenticated firewall tunneling framework
US20030156566A1 (en) * 2002-02-20 2003-08-21 Doug Griswold Mobile data communications apparatus, methods and computer program products implementing cellular wireless data communications via a wireless local area network
WO2003093951A2 (fr) * 2002-05-04 2003-11-13 Instant802 Networks Inc. Point d'acces ameliore et controleur de reseau sans fil

Also Published As

Publication number Publication date
FR2866496A1 (fr) 2005-08-19
WO2005091565A9 (fr) 2006-06-22

Similar Documents

Publication Publication Date Title
EP1605660B1 (fr) Contrôle d'accès à un réseau d'un terminal source utilisant un tunnel en mode bloquant
EP1733533B1 (fr) Procede et systeme de gestion d'autorisation d'acces d'un utilisateur au niveau d'un domaine administratif local lors d'une connexion de l'utilisateur a un reseau ip
EP1678899B1 (fr) Procede et dispositif d acces a un terminal serveur mobile d un premier reseau de communication au moyen d un termi nal client d un autre reseau de communication
FR2844941A1 (fr) Demande d'acces securise aux ressources d'un reseau intranet
EP1733539B1 (fr) Dispositif et procédé de détection et de prévention d'intrusions dans un réseau informatique
EP3476095A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP2692089B1 (fr) Mécanisme de redirection entrante sur un proxy inverse
EP1965559B1 (fr) Procédé de sécurisation d'un flux de données
EP1494391A1 (fr) Procédé de configuration automatique d'un routeur d'accès, compatible avec le protocole DHCP, pour effectuer un traitement automatique spécifique des flux IP d'un terminal client
FR2889780A1 (fr) Controle d'acces d'un equipement mobile a un reseau de communication ip par modification dynamique des politiques d'acces
EP1738526B1 (fr) Procede et systeme d'accreditation d'un client pour l'acces a un reseau virtuel permettant d'acceder a des services
FR2838896A1 (fr) Procedes et dispositifs pour former des connexions de reseau securisee sur un reseau prive
WO2014067880A1 (fr) Procede d'authentification mutuelle entre un terminal et un serveur distant par l'intermediaire d'un portail d'un tiers
WO2007010101A2 (fr) Detection d’une intrusion par detournement de paquets de donnees dans un reseau de telecommunication
EP2608590A1 (fr) Auto-configuration d'un équipement pour la connexion à un réseau sans fil sécurisé
EP1672849A1 (fr) Procédé d'exploitation d'un réseau informatique local relié à un réseau distant privé par un tunnel IPsec
WO2005091565A1 (fr) Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant
WO2022069825A1 (fr) Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes.
EP1432210A1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d'un reseau de communications
WO2006037864A2 (fr) Procede de controle d'acces a un reseau d'un terminal source utilisant un tunnel en mode bloquant, et programmes d'ordinateur pour sa mise en oeuvre
FR2895816A1 (fr) Systeme, dispositif portable et procede pour la configuration d'un dispositif communicant dans un reseau
WO2006082296A2 (fr) Procede et dispositif de detection d'usurpations d'adresse dans un reseau informatique
US20060010486A1 (en) Network security active detecting system and method thereof
WO2004015953A2 (fr) Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local
EP4113900A1 (fr) Procede et dispositif de securisation d'un reseau local comprenant un commutateur reseau auquel est reliee une station par liaison filaire

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
COP Corrected version of pamphlet

Free format text: PAGES 1-27, DESCRIPTION, REPLACED BY NEW PAGES 1-27; DUE TO A SCANNING ERROR DURING THE TECHNICAL PREPARATIONS FOR INTERNATIONAL PUBLICATION

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase