+

WO2006037864A2 - 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 - Google Patents

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 Download PDF

Info

Publication number
WO2006037864A2
WO2006037864A2 PCT/FR2005/001881 FR2005001881W WO2006037864A2 WO 2006037864 A2 WO2006037864 A2 WO 2006037864A2 FR 2005001881 W FR2005001881 W FR 2005001881W WO 2006037864 A2 WO2006037864 A2 WO 2006037864A2
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
source terminal
sour
firewall
network
Prior art date
Application number
PCT/FR2005/001881
Other languages
English (en)
Other versions
WO2006037864A3 (fr
Inventor
Laurent Butti
Olivier Charles
Franck Veysset
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 WO2006037864A2 publication Critical patent/WO2006037864A2/fr
Publication of WO2006037864A3 publication Critical patent/WO2006037864A3/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/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • 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
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Definitions

  • the invention relates generally to the techniques of accessing a computer network.
  • the invention relates to a method of 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 portal or valid authentication data firewall, failing which the firewall is placed in a blackout state, the firewall remaining in a basic mode access permission state in response to the periodic supply, by the source terminal and on a token exchange secure channel, a token one default valid authentication which the firewall is placed in its state of prohibition of access, and the source terminal selectively communicating in tunnel mode with a term Inal destination network through a tunnel blocking.
  • 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.
  • the 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 the machine of this user to use it as a relay to access the intranet of the company of the latter.
  • 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 at least the periodic provision of the authentication token is performed by transmitting on at least one unblocked level 3 port of the OSI model of the exchange channel established between the source terminal and the firewall, which results in the periodic provision of the authentication token continuing to be ensured during a blocking tunnel communication.
  • the method of the invention comprises, after a successful initial authentication operation of the source terminal, at least one secret creation operation implemented on the source terminal and / or on the captive portal by at least one of the respective application programs, and operations of retransmission of this secret to corresponding authentication entities of the source terminal and the firewall.
  • secret as used in the present description will be understood as covering not only, literally, a particular secret, well defined and directly usable, but also all the elements allowing to derive or reconstruct a this secret in the true sense.
  • the secret can advantageously be transmitted from the captive portal to the source terminal in an authentication window.
  • the authentication window can also ensure the transmission, from the captive portal to the source terminal, of a counter initialized both on the source terminal and the captive portal side.
  • the authentication window may advantageously comprise a disconnect button.
  • the authentication token is periodically supplied for example by one entity authentication to the source terminal of the firewall authentication entity verifies that mistletoe token.
  • the counter is preferably periodically provided by the authentication entity of the source terminal to the firewall authentication entity, which verifies this counter.
  • the firewall authentication entity After verification of data provided by the authentication entity of the source terminal, the firewall authentication entity can thus place a firewall filtering module in a state of authorization or prohibition of access , depending on the result of this check.
  • the authentication entity of the source terminal is for example made in Java language, downloaded during the initial authentication of this source terminal, and executed in the session maintenance window. Furthermore, the transmission level 3 set up between the authentication entities one of the source terminal and the firewall is advantageously developed in DHCP.
  • the invention also relates to a first computer program intended to be implemented on a source terminal and designed to conditionally authorize a connection of this source terminal in blocking tunnel mode with a destination terminal of a network through a controlled firewall.
  • this first program being characterized in that it comprises an initialization module able to recover a shared secret from the portal and to initialize a counter, a periodic authentication confirmation module called by the an initialization module and able to develop and send to the firewall, and on an unblocked port of layer 3 of the OSI model, a unique authenticator depending at least on the shared secret and content of the counter, and a module update and decision called by the periodic confirmation module d 1 authentication and own to increment the counter, to end at the connection in the event of a communication anomaly with the firewall, and to call again the periodic authentication confirmation module in the opposite case, which results in the source terminal continuing to be authenticated by the fire during tunnel lock connection.
  • the invention also relates to a second computer program intended to be installed on a firewall installed in a network, and controlled by a captive portal of the network, to conditionally authorize a connection in blocking tunnel mode between a source terminal and a destination terminal of this network through the firewall, this second program being characterized in that it comprises a network listening module, a selection module, and a module analysis and decision, in that the network listening module is clean, in response to an authentication request received from the source terminal, to retrieve a shared secret from this source terminal, in that the module of selection is called by the listener and able to locate, in a stream of frames flowing on the layer 3 of the OSI model, authentication frames of the source terminal, and to route the authentication frames to the module d analysis and decision, and in that the analysis and decision module verifies the content of the authentication frames, terminates the connection of the source terminal in the event of an anomaly, and updates the authorization rules used connection s by the firewall otherwise.
  • the invention finally relates to a source terminal at least equipped with the first program defined above and a firewall at least equipped with the second program defined above.
  • FIG 1 shows schematically the functional means necessary for the implementation of the invention
  • FIG. 2 represents the information flows implemented work between the source terminal, the firewall and the portal authentifiention 1, from the authentication from the source terminal;
  • FIG. 3 represents the flows of information implemented between the source terminal, the firewall and the authentication portal, during the use of the tunnel in blocking mode
  • FIGS. 4A and 4B are flowcharts respectively representing the computer program implemented on the source terminal, and the computer program implemented on the firewall.
  • 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).
  • ARP Address Resolution Protocol
  • DHCP (Acronym from the Dynamic Host Configuration Protocol): protocol for automatically configuring users of an IP network (see this word) and dynamically allocating addresses on such a network.
  • DNS National service of the Internet ensuring the conversion of domain names into IP addresses (see this word).
  • Hash function this expression refers to a function that converts a string of any length into a smaller fixed size string, this string is called a fingerprint
  • hash The result of a hash function is the same for the same input string, but in principle there are no two similar hash function results.
  • Keyed hash function This expression refers to a hash function that, in addition to a string of any length, takes a secret key as input.
  • HMAC-MD5 (Acronym from “Keyed-Hashing for Message Authentication” - “Message Digest 5”): Cryptographic algorithm of the type “key hash function” (see this expression).
  • HMAC-SHAl (Acronym from “Keyed-Hashing for Message Authentication” - “Secure Hash Algorithm"): Cryptographic algorithm of the type "function hash key” (see this expression).
  • HTML An Internet document format defined by Standard RFC 1866.
  • HTTPS (Acronym taken from the English “HyperText Transfer Secure Protocol": Transmission protocol from the browser “Netscape” and linked to a secure connection.
  • 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 Systems Interconnection Model open where all the actions allowing to cooperate several computer equipment is structured in layers corresponding to different levels of detail.
  • 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 TLS: Transport Layer Security Protocol, defined by RFC 2246. Version 1.0 of TLS is actually version 3 of SSL (see this word).
  • UDP User Datagram Protocol
  • DHCP DHCP Options and BOOTP Vendor Extensions, RFC 2132, March 1997.
  • HMAC-MD5 Krawczyk H., Bellare M., and Canetti R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • MAC LAN Access Control Medium
  • PHY Physical Layer
  • MAC Wireless LAN Medium Access Control
  • PHY Physical Layer
  • TLS Dierks, T. and Allen, c, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • Wi-Fi protected Access Wi-Fi Alliance, version 1.2, December 2002.
  • the method described below typically applies to a scenario in which the network operator performs access control at the TCP / IP level and in which the user wishes to use a tunnel such as [IPsec] in blocking mode.
  • the invention may find relevant use in the IEEE 802.11 radio networks ([IEEE-802.11-1997] and
  • 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 based on the identity of the user if it is allowed or denied access to the network. In order to prevent illegitimate users from taking unfair advantage of the network, it is necessary for access control:
  • sockets for accessing the network are located in locked rooms;
  • 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 pass the traffic of that user.
  • the architecture of a captive portal (FIG. 1), which allows a source terminal T_SOUR to communicate in tunnel mode with a destination terminal T_DEST of the network, thus generally implies a P_ACC access point, a PF firewall, the portal authentication-1 itself PORT, and BDD identification database.
  • the access point P_ACC offers the 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 non-authenticated users, redirects these users to an authentication page, has his authentication data verified by the database BDD, modifies the rules of the firewall PF by 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 token access control 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 periodically present, or on event, an authentication token. Failure to present this token resets the firewall to state blocking for this user. Thus, 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. Even if the simultaneous presence of an authorized user responsible for presenting the token and an unauthorized user usurping the MAC address and IP address of this authorized user is possible, 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.
  • the "captive portal" paradigm as described so far applies, for example, to both radio networks using IEEE 802.11 technology and wired local area networks using IEEE 802.3 / Ethernet technologies.
  • 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 reinforces the access control by filtering IP address and / or MAC address by an authentication token exchange, lies precisely in the fact that this technique supposes that the operator and the user are able to dialogue in order to be able to exchange the token.
  • 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.
  • This invention proposes a periodical re-authentication mode totally invisible to the user. Furthermore, the use of a transmission channel not affected by the blocking mode between the terminal and the captive portal allows the exchange of additional information, such as connection times or volumes consumed.
  • the invention is based on the observation that the blocking mode technique used for example by IPsec users has the property of filtering data packets at level 3 of the OSI model.
  • the DHCP protocol allows the establishment of the IP connectivity for the user requesting the information necessary for the proper functioning of his connection (@IP, @DNS, ⁇ gateway, netmask ).
  • This connectivity information is allocated to the user in a temporary (lease), and renewed periodically at the initiative of the user. If the renewal does not occur before the end of the lease, then the server considers that the user is no longer present or does not wish to renew his lease (lease completed). The user no longer has IP connectivity. Therefore, the "blocking" mode of an IPsec tunnel can not block communications when addresses are allocated dynamically and temporarily by DHCP, otherwise connectivity loss would make the service impossible to secure, especially in the case of short leases. (This is generally the case in public "hot spot" networks).
  • the DHCP protocol is transported in ports 67 and 68 of the UDP protocol. These ports (standardized to I 1 IANA, see http://www.iana.org) are necessarily authorized and unblocked from the station to the outside even in blocking mode.
  • the allowed protocols are generally the 67 / UDP and 68 / UDP ports. However, other ports may be allowed (for example, 4500 / UDP for NAT Traversal).
  • the invention takes advantage of the existence of non-blocked ports to maintain the exchange of authentication token 1, and specifically uses authorized ports (67 / UDP, 68 / UDP) mode by "blocking", not unauthorized protocols (http or https) used in the prior art.
  • This technique allows both to keep the blocking mode of the IPsec user and to use a strong authentication protocol, thus significantly improving the basic access control currently performed based on the IP address and / or MAC.
  • the session control that is to say, typically the token exchange mechanism between the T_SOUR source terminal and the PORT portal, is moved to the authorized ports (UDP / 67 and UDP / 68). , which makes it independent of any blocking mode
  • the invention uses on the one hand an entity (also called “module”) PAl authentication protocol and APPLIl application program implemented in the source terminal T_SOUR, on the other hand an entity (or " module) PA2 authentication protocol and a function (also called “module”) FILT filtering implemented in the firewall PF, and finally an application program APPLI2 implemented in the PORT captive portal.
  • entity also called “module”
  • module PA2 authentication protocol
  • function also called "module”
  • FILT filtering implemented in the firewall PF
  • APPLI2 implemented in the PORT captive portal
  • the dialog D1 symbolizes the dialog allowing the authentication of the user in an SSL session and the calculation of a shared secret between the source terminal T_SOUR and the PORT portal;
  • the dialogue D2 symbolizes the injection into the authentication protocol entity PA1 of the source terminal T_SOUR, the secret calculated through the dialogue Dl;
  • the dialogue D3 symbolizes the injection into the authentication protocol entity PA2 of the firewall PF of the secret calculated using the dialogue D1.
  • the dialog D1 symbolizes the dialogue which, although transiting through the layer 2 (denoted L2) and the layer 1 (denoted L1) of the OSI model, constitutes an ECHG exchange established on the layer 3 of the OSI model between the authentication protocol entity PA1 of the source terminal T_SOUR and the corresponding entity PA2 of the firewall PF and allows periodic re-authentication of the user;
  • the dialogue D2 symbolizes the IPsec communication between the source terminal T_SOUR and the destination terminal T_DEST;
  • the dialog D3 symbolizes the update of the filtering rules by the PA2 entity of the firewall PF, depending on the result of the re-authentication.
  • the authentication protocol entity PA1 implemented in the terminal T_S0UR must therefore be able to interact (dialogue D2 in FIG. 2) with the application program APPLI1 which distributes it secrets when the authentication of the terminal T_SOUR on the network (dialogue D1 of Figure 2) succeeded.
  • the PAl authentication protocol entity implemented in the terminal T_SOUR must also be in direct relation with the layer 3 of the OSI model, by which it communicates with the corresponding entity PA2 implemented in the firewall PP (dialogue D1 of FIG. 3, seen in its form ECHG ).
  • the authentication protocol entity PA2 implemented in the PP firewall must be able to interact (dialogue D3 in FIG. 2) with the application program APPLI2 which distributes it secrets when the authentication of the terminal T_SOUR on the network has succeeded, and with the FILT function of packet filtering (dialogue D3 of FIG. 3) to make it "pass" when the authentication verified by the entities PA1 and PA2 succeeds and "blocking" when the authentication verified by the PAl and PA2 entities fail.
  • the d 1 authentication protocol entity PA2 implemented in the firewall PF must also be in direct contact with the layer 3 of the OSI model, in which it communicates with the corresponding PAl implementation entity in the source terminal T_SOUR (dialog Dl of Figure 3, seen in its form ECHG).
  • the T_SOUR terminal and the PF firewall must be in direct view on layer 3 of the OSI model, that is to say they can be separated by any number of routers, the presence of these routers being devoid of any impact on the implementation of the invention.
  • the process includes an initial phase authentication of the T_SOUR terminal, and a subsequent periodic phase of re-authentication of PAl and PA2 entities.
  • the source terminal T_SOUR or its user, authenticates with the captive portal PORT by exchanging data via the secure link symbolized by the dialogue D1 of FIG. 2, this confidential link being able to be realized in TLS / SSL in a classic way.
  • the FILT filtering module of the PF firewall is controlled by the PA2 entity
  • this FILT filtering module being, in the opposite case, controlled to become blocking. Under these conditions, as long as the FILT filter module is on, the data stream in which the terminal T_SOUR is involved can freely circulate. If this terminal chooses to go into blocking mode, for example by calling IPsec with certain types of software, then the re-authentication between the PAl and PA2 entities can continue, the access control at the level of the firewall PF thus remaining valid .
  • This open source “captive portal” solution controls several open source filtering engines like “iptables”, “packetfilter” or “IPFilter”, respectively described on the sites: http://iptables.org, http: //www.benzedrine .cx / pf.html, and http: //www.ipfilter.org. It allows to control these filtering engines through a dialogue between the captive portal and an application controlling the filtering engine.
  • 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 DHCP exchanges;
  • 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 that is intercepted by the filtering engine (default rules) and redirected to the "captive portal".
  • the "captive portal” then presents the banner 1 authentication to the user -
  • the user enters his authentication data (typically a username 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 point, the user is then able to communicate to the outside (typically the Internet) in function of the new filtering rules communicated to the filtering engine;
  • the “captive portal” pushes a periodical authentication window to the user, this window making it possible to maintain the session between the user and the captive portal thanks to the notion of authentication token, and thus still being called here "Session maintenance window”.
  • the session maintenance window can be written in HTML code, for initiating a connection periodically to a well-formatted URL (containing in particular the authentication token).
  • the use of the session maintenance window which is protected by SSL / TLS cryptographic mechanisms (https in FIG. 2), makes it possible to derive a secret which is specific to the T_SOUR terminal and the PORT captive portal.
  • the invention can then use specific cryptographic mechanisms to ensure the confidentiality of the information transported in the new protocol specified in the authorized ports (67 / UDP, 68 / UDP), as well as the function called "anti-replay", c that is, the function to block connection spurious attacks consisting of making a user think that a user is still active and recovering his connection to a connection. moment chosen, for example during an inadvertent disconnection.
  • the secret protected by SSL / TLS, is transmitted from the PORT portal to the T_SOUR terminal in the authentication window in response to a successful authentication of this T_J3OUR terminal.
  • a counter which is initialized both on the side of the terminal T_SOUR, and on the side of the captive portal PORT, this secret and this counter allowing both to avoid spoofing attacks. identity and replay attacks.
  • a cryptographic algorithm of the hash function type (such as HMAC-MD5 or HMAC-SHAl) takes as input information such as the counter, the IP address of the terminal T_SOUR which are known to the captive portal, as well as the shared secret (used as a key to the hash function) This results in a fixed-length string that ensures both user authentication (thanks to the shared secret), anti-replay (thanks to the counter) and 1 authentication of the machine (thanks to the IP address).
  • the packet is sent from the PAl entity of the terminal T_SOUR to the PA2 entity of the firewall PF thanks to the new protocol implemented by the invention in the authorized ports (67 / UDP, 68 / UDP), then is analyzed by the captive portal PORT which verifies the secret and the counter.
  • PORT Portal's access control system considers identity theft and, depending on the security policy, chooses the most appropriate decision for the situation, such as to close the connection by sending an instruction to the FILT filtering module, or to ignore the packet and to continue to wait for a valid packet to be received (the connection then being closed if no valid packet is received before the expiration a delay corresponding to the validity period of an authentication).
  • the invention is inserted at the level of the 7th step of the standard connection process as recalled above, namely that in which the captive portal periodically pushes an authentication window to the user to maintain the session between this user and the user. captive portal through the exchange of an authentication token.
  • the session maintenance window comprises application software PAl implementing an authentication protocol associated with a program that displays a disconnect button allowing the user of the source terminal T_SOUR to disconnect properly.
  • This technique is based on client-server development in the authorized ports (67 / UDP, 68 / UDP).
  • the application software running on the T_SOUR terminal periodically sends packets over the unicast IP Ethernet segment to the PF firewall, indicating that this terminal is still active; if an attacker has invalid authentication tokens, they will be detected by the cryptographic methods used.
  • the security policy can easily be adapted to this type of event. It is then possible, for example, to disconnect the user and trigger an alarm with administrators of the captive portal. It is also possible not to consider the spoofed token, to continue to wait for a valid packet until the end of a predetermined time allotted for the connection, and to trigger an alarm with administrators of the captive portal.
  • the information contained in the packets sent by the source terminal T_S0UR are listened to by a PA2 application software present on the PF firewall. The latter is able, thanks to the information contained in the packets sent, to determine that the user of the terminal T_SOUR is legitimate, and that this terminal is still connected;
  • the PORT captive portal will allow the connection of the T_SOUR terminal only for a previously fixed residual session time.
  • the portal PORT access control system will then consider that the user is no longer present on the network and is no longer authorized to communicate through the PF firewall.
  • the captive portal will therefore update the PF firewall filtering rules to prohibit the connection of the T_SOUR terminal.
  • the portal PORT access control system will be informed that this user wishes to disconnect. To do this, the user will inform the portal PORT access control system of his desire to leave the network by using the logout button of the session maintenance window. The access control system of the PORT will then consider that the user is no longer present on the network and is no longer allowed to communicate through the PF firewall. The captive portal will therefore update the PF firewall filtering rules to prohibit the connection of the T_SOUR terminal.
  • the communication between the T__SOUR terminal and the PORT captive portal must be carried out in an authorized port, it is possible to use a UDP-based protocol that fulfills the desired functions as described.
  • the invention can therefore be implemented easily by specifying a client-server protocol at the UDP level.
  • this software is transparently downloaded from the captive portal as a result of the successful authentication of the source terminal with this portal; this can be done through the session maintenance window which carries the authentication token in the current process;
  • this software is disabled at the end of the session by closing the session maintenance window.
  • the invention offers the additional advantage of allowing transit of information other than authentication data. For example, it is possible to take advantage of the open communication channel in the authorized ports and not likely to be blocked to pass the billing information of the operator of the captive portal to the user (volume of data exchanged, time consumed , remaining time, etc.), this type of information can be displayed in the session maintenance window as a dashboard.
  • FIGS. 4A and 4B The computer programs implemented on the source terminal T_SOUR and on the firewall PF are respectively illustrated, functionally and schematically, in FIGS. 4A and 4B.
  • the program illustrated in FIG. 4A which is installed on the source terminal T_SOUR, is designed to conditionally authorize a connection of this source terminal in blocking tunnel mode with the destination terminal T_DEST of the network through the firewall PF.
  • This program essentially consists of an initialization module M_INIT, a periodic authentication confirmation module M_AUTH_PER, and an update module and decision M_MAJ_DEC.
  • the purpose of the M_INIT initialization module is to start the authentication process.
  • this module M_INIT which is activated after the initial authentication of the source terminal T_SOUR with the captive portal PORT, allows this source terminal to retrieve the shared secret S communicated by the portal PORT, and to initialize a counter n.
  • the periodic confirmation module 1 M_AUTH__PER authentication which is called by the initialization module M_INIT is own to develop a single authenticator and transmit this authenticator on non-blocked ports Layer 3 of the OSI model to the firewall -fire PF.
  • the issued authenticator is for example developed as a function f of the IP address of the source terminal, the content of the counter n, and the shared secret S.
  • the updating and decision module M_MAJ_DEC which is called by the periodic authentication confirmation module M_AUTH_PER, essentially fulfills two functions.
  • this module increments the counter n for the next authentication of the source terminal.
  • the M_MAJ_DEC module monitors the communication with the firewall, so as to terminate the connection in the event of an anomaly, and in particular in case of prolonged silence on the part of the firewall.
  • M_AUTH_PER to allow the latter to proceed to a new authentication of the source terminal T_SOUR with PF firewall during blocking tunnel connection.
  • the program illustrated in FIG. 4B which is installed on the PF firewall, is designed to conditionally authorize a blocking tunnel connection between the source terminal T_SOUR and the destination terminal T_DEST of the network through this firewall PF.
  • This second program essentially comprises a listening module M_ECOUT, an M_SELECT selection module, and an analysis and decision module M_ANAL_DEC.
  • the M_ECOUT listening module is constantly listening to the network.
  • the selection module M_SELECT which is called by the M_ECOUT listener, is adapted to identify, in the stream of frames circulating over the layer 3 of the OSI model, the TR frames which constitute the frame 1 of the source terminal authentication TR_AUTH T_SOUR, and refer to those frames 1 TR_AUTH authentication to the analysis module and M_ANAL_DEC decision.
  • the analysis and decision module M_ANAL_DEC has meanwhile the function of verifying the content on TR_AUTH d 1 authentication frames received from the source terminal, that is to say, to develop a decision function g based on these TR_AUTH frames.
  • the analysis and decision M_MTAL_DEC triggers an operation INHIB_PF corresponding to the destruction, on the firewall PF, of the access rules of the source terminal T_SOUR.
  • the analysis and decision module M_ANAL_DEC triggers an operation Mi ⁇ J_PF corresponding to the creation or the update, on the firewall PF, of the rules of access of the source terminal T_SOUR.

Landscapes

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

Abstract

L ' invention concerne notamment 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 d1 authentif ication, 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 d1 authentif ication valide, le terminal source pouvant en outre communiquer en mode tunnel avec un terminal de destination du réseau à travers un tunnel bloquant (M_BLQ) . Selon l'invention, la fourniture périodique du jeton d' authentif ication est réalisée par une transmission sur un port non bloqué de la couche de niveau 3 du modèle OSI, de sorte que le jeton continue à être fourni lors d'une communication en mode tunnel bloquant.

Description

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.
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'authentification 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 ou au pare-feu de données d'authentification valides, à défaut desquelles le pare-feu est placé dans un état d'interdiction d'accès, le pare-feu restant 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 d1authentification 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 bloquant.
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 contrôle d'accès à son réseau parce que l'usager choisit d'utiliser un tunnel en mode bloquant, ce qui rend impossibles les communications entre l'usager et l'opérateur du réseau.
Pour des raisons fonctionnelles ou des raisons de sécurité, l'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 la machine de cet usager pour l'utiliser comme relais afin d'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 préambule ci-dessus, est essentiellement caractérisé en ce qu'au moins la fourniture périodique du jeton d'authentification est réalisée par une transmission sur au moins un port non bloqué de niveau 3 du modèle OSI du canal d'échange établi entre le terminal source et le pare-feu, ce dont il résulte que la fourniture périodique du jeton d' authentification continue à être assurée lors d'une communication en mode tunnel bloquant.
Par exemple, le procédé de l'invention comprend, postérieurement à une opération initiale réussie d'authentification du terminal source, au moins une opération d'élaboration d'un secret mise en œuvre sur le terminal source et / ou sur le portail captif par l'un au moins de programmes d'application respectifs, et des opérations de retransmission de ce secret à des entités d'authentification correspondantes du terminal source et du pare-feu.
Par convention, le terme de "secret" tel qu'utilisé dans la présente description sera compris comme couvrant non seulement, au sens propre, un secret particulier, bien défini et directement utilisable, mais également tous les éléments permettant de dériver ou de reconstruire un tel secret au sens propre.
Le secret peut avantageusement être transmis du portail captif au terminal source dans une fenêtre d'authentification.
Dans ce cas, notamment, la fenêtre d'authentification peut également assurer la transmission, du portail captif vers le terminal source, d'un compteur initialisé à la fois du côté du terminal source et du portail captif. En outre, la fenêtre d'authentification peut avantageusement comporter un bouton de déconnexion.
Postérieurement à une opération initiale réussie d1authentification du terminal source, le jeton d' authentification est par exemple périodiquement fourni par l'entité d1authentification du terminal source à destination de l'entité d'authentification du pare-feu, gui vérifie ce jeton.
De même, postérieurement à une opération initiale réussie d' authentification du terminal source, le compteur est de préférence périodiquement fourni par 1 ' entité d'authentification du terminal source à destination de l'entité d'authentification du pare-feu, qui vérifie ce compteur.
Après vérification de données fournies par l'entité d'authentification du terminal source, l'entité d'authentification du pare-feu peut ainsi placer un module de filtrage du pare-feu dans un état d'autorisation ou d'interdiction d'accès, en fonction du résultat de cette vérification.
L'entité d'authentification du terminal source est par exemple réalisée en langage Java, téléchargée lors de 1 ' authentification initiale de ce terminal source, et exécutée dans la fenêtre de maintien de session. Par ailleurs, la transmission de niveau 3 établie entre les entités d1authentification du terminal source et du pare- feu est avantageusement développée dans le protocole DHCP.
L' invention concerne également un premier programme d'ordinateur destiné à être implanté sur un terminal source et conçu pour autoriser conditionnellement 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 premier programme étant caractérisé en ce qu'il comprend un module d'initialisation propre à récupérer un secret partagé en provenance du portail et à initialiser un compteur, un module de confirmation périodique d'authentification appelé par le module d'initialisation et propre à élaborer et à émettre à destination du pare-feu, et sur un port non bloqué de la couche 3 du modèle OSI, un authentifiant unique dépendant au moins du secret partagé et du contenu du compteur, et un module de mise à jour et de décision appelé par le module de confirmation périodique d1authentification et propre à incrémenter le compteur, à mettre fin à la connexion en cas d'anomalie de communication avec le pare-feu, et à appeler à nouveau le module de confirmation périodique d'authentification dans le cas contraire, ce dont il résulte que le terminal source continue à être authentifié par le pare-feu pendant la connexion en mode tunnel bloquant.
L'invention concerne également un deuxième programme d'ordinateur destiné à être implanté sur un pare-feu installé dans un réseau, et contrôlé par un portail captif du réseau, pour autoriser conditionnellement une connexion en mode tunnel bloquant entre un terminal source et un terminal de destination de ce réseau à travers le pare-feu, ce deuxième programme étant caractérisé en ce qu'il comprend un module d'écoute du réseau, un module de sélection, et un module d'analyse et de décision, en ce que le module d'écoute du réseau est propre, en réponse à une demande d' authentification reçue du terminal source, à récupérer un secret partagé en provenance de ce terminal source, en ce que le module de sélection est appelé par le module d'écoute et propre à repérer, dans un flux de trames circulant sur la couche 3 du modèle OSI, des trames d'authentification du terminal source, et à aiguiller les trames d' authentification vers le module d'analyse et de décision, et en ce que le module d'analyse et de décision vérifie le contenu des trames d'authentification, met fin à la connexion du terminal source en cas d'anomalie, et met à jour les règles d'autorisation de connexion utilisées par le pare-feu dans le cas contraire.
L'invention concerne enfin un terminal source au moins équipé du premier programme défini ci-dessus et un pare-feu au moins équipé du deuxième programme défini ci-dessus.
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 aux dessins annexés, dans lesquels :
la figure 1 représente schématiquement les moyens fonctionnels nécessaires à la mise en œuvre de l'invention;
- la figure 2 représente les flux d'informations mis en œuvre entre le terminal source, le pare-feu et le portail d1authentifiention, à partir de la procédure d'authentification du terminal source; et
- la figure 3 représente les flux d'informations mis en œuvre entre le terminal source, le pare-feu et le portail d'authentification, pendant l'utilisation du tunnel en mode bloquant; et
- les figures 4A et 4B sont des organigrammes représentant respectivement le programme d'ordinateur mis en œuvre sur le terminal source, et le programme d'ordinateur mis en œuvre sur le pare-feu.
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. DÉFINITIONS.
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) . ARP (Acronyme tiré de l'anglais "Address Resolution Protocol") : Protocole de résolution des adresses IP en adresses MAC, de niveau 2 du modèle OSI (voir ce mot) , permettant de faire communiquer des stations sur un réseau à base Ethernet. Les communications réelles sont en effet basées sur les adresses MAC de la source et du destinataire.
DHCP (Acronyme tiré de l'anglais "Dynamic Host Configuration Protocol") : Protocole de configuration automatique des usagers d'un réseau IP (voir ce mot) et d'attribution dynamique des adresses sur un tel réseau.
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) .
Fonction de hachage : cette expression désigne une fonction qui convertit une chaîne de caractères de longueur quelconque en une chaîne de caractères de taille fixe de taille inférieure, cette chaîne est appelée empreinte
(hash) . Le résultat d'une fonction de hachage est le même pour la même chaîne d'entrée, mais en principe il n'existe pas deux résultats semblables de fonction de hachage.
Fonction de hachage à clef : cette expression désigne une fonction de hachage qui, en plus d'une chaîne de caractères de longueur quelconque, prend en entrée une clef secrète.
HMAC-MD5 (Acronyme tiré de l'anglais "Keyed-Hashing for Message Authentification" - "Message Digest 5") : Algorithme cryp'tographique du type "fonction à hachage à clef" (voir cette expression) .
HMAC-SHAl (Acronyme tiré de l'anglais "Keyed-Hashing for Message Authentification" - "Secure Hash Algorithm" ) : Algorithme cryptographique du type "fonction à hachage à clef" (voir cette expression) .
HTML (Acronyme tiré de l'anglais "HyperText Markup Language") : Format de document Internet défini par la Norme RFC 1866.
HTTPS (Acronyme tiré de l'anglais "HyperText Transfer Protocole Secure") : Protocole de transmission issu du navigateur "Netscape" et lié à une connexion sécurisée.
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ù l'ensemble des actions permettant de faire coopérer plusieurs équipements informatiques est structuré en couches correspondant à des niveaux de détails différents.
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 .
[ARP] Address Resolution Protocol, "An Ethernet Address Resolution Protocol", RFC 826, November 1982.
[DHCP] DHCP Options and BOOTP Vendor Extensions, RFC 2132, Mars 1997.
[HMAC-MD5] Krawczyk H., Bellare M., and Canetti R., "HMAC : Keyed-Hashing for Message Authentification" , RFC 2104, February 1997.
[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:
Wάreless 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.1Ii] 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. Hi (work in progress) , 2003.
[IPsec] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, Novembre 1998.
[NAT-T] Negotiation of NAT-Traversal in the IKE, Internet Draft, Février 2004.
[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.
[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 dans lequel l'opérateur du réseau réalise un contrôle d'accès au niveau TCP/IP et dans lequel 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.Hi., 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 d1authentification 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 d1authentification 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 1 'accès au réseau est conditionné par la possession d'un secret permettant d'employer des techniques cryptographiques.
En 1 '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' [0SI] 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 d1authentification échangés entre le terminal source et le portail d'authentification au niveau de logiciels d'application.
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'authentification 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'authentification 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 (figure 1), qui permet à un terminal source T_SOUR de communiquer en mode tunnel avec un terminal de destination T_DEST du réseau, implique ainsi globalement un point d'accès P_ACC, un pare-feu PF, le portail d1authentification lui-même PORT, et une base de données d'identification BDD. Le point d'accès P_ACC offre au 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'authentification, fait vérifier ses données d'authentification 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'authentification.
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'authentification. 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.1Ii], 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'authentification, 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'authentification, 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 1 '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.
Cette invention propose un mode de ré-authentification périodique totalement invisible à l'usager. Par ailleurs, l'emploi d'un canal de transmission non affecté par le mode bloquant entre le terminal et le portail captif permet l'échange d'informations supplémentaires, comme par exemple des durées de connexion ou des volumes consommés .
L'invention repose sur l'observation du fait que la technique de mode bloquant utilisée par exemple par les usagers de IPsec a la propriété de filtrer les paquets de données au niveau 3 du modèle OSI.
Néanmoins, bien que cette propriété n'ait pas été publiée par les éditeurs de logiciels, l'utilisation d'un tunnel en mode bloquant ne peut pas s'affranchir de certaines communications, telles que celles qui concernent l'attribution dynamique d'adresses sur un réseau IP et qui sont typiquement effectuées par le protocole DHCP, ou telles que celles qui dépendent de la manière dont est réalisé le mode bloquant.
En effet, le protocole DHCP permet l'établissement de la connectivité IP pour l'usager demandant les informations nécessaires au bon fonctionnement de sa connexion (@IP, @DNS, ©passerelle, masque de réseau...) . Ces informations de connectivité sont allouées à l'usager de manière temporaire (bail) , et renouvelées périodiquement à l'initiative de l'usager. Si le renouvellement n'intervient pas avant la fin du bail, alors le serveur considère que l'usager n'est plus présent ou ne désire pas renouveler son bail (bail terminé). L'usager n'a plus alors de connectivité IP. Par conséquent, le mode "bloquant" d'un tunnel IPsec ne peut bloquer les communications lorsque les adresses sont allouées dynamiquement et temporairement par DHCP, faute de quoi des pertes de connectivité rendraient le service impossible à assurer, surtout dans le cas de baux courts (ceci est généralement le cas dans les réseaux de type "hot spot" public) .
Le protocole DHCP est transporté dans les ports 67 et 68 du protocole UDP. Ces ports (standardisés à I1IANA, cf. http://www.iana.org) sont nécessairement autorisés et donc non bloqués depuis la station vers l'extérieur même en mode bloquant.
La description ci-après fera par commodité l'hypothèse que les protocoles autorisés sont de manière générale les ports 67/UDP et 68/UDP. Il est toutefois possible que d'autres ports soient autorisés (par exemple, 4500/UDP pour le NAT- Traversal) .
L'invention met à profit l'existence de ports non bloqués pour maintenir l'échange du jeton d1authentification, et plus précisément utilise les ports autorisés (67/UDP, 68/UDP) par le mode "bloquant", et non les protocoles non autorisés (http ou https) utilisés dans l'art antérieur.
Cette technique permet à la fois de garder le mode bloquant de l'usager IPsec et d'utiliser un protocole d'authentification fort, améliorant ainsi de façon notable le contrôle d'accès élémentaire actuellement réalisé sur la base de l'adresse IP et/ou MAC.
Pour ce faire, le contrôle de session, c'est-à-dire typiquement le mécanisme d'échange de jeton entre le terminal source T_SOUR et le portail PORT, est déplacé au niveau des ports autorisés (UDP/67 et UDP/68) , ce qui permet de le rendre indépendant de tout mode bloquant
(M_BLQ sur la figure 3) éventuellement mis en place par l'usager du terminal T_SOUR.
En effet, il n'est pas possible, pour l'usager d'un tunnel en mode bloquant, d'empêcher les communications de son terminal T_SOUR dans les ports autorisés (67/UDP, 68/UDP) , dans la mesure où ce terminal doit impérativement pouvoir dialoguer au niveau DHCP avec le serveur DHCP pour assurer le renouvellement de son bail de manière périodique, et où il se retrouverait donc totalement isolé du réseau si ces communications étaient interrompues.
Concrètement, l'invention utilise d'une part une entité (encore appelée "module") de protocole d'authentification PAl et un programme d'application APPLIl mis en œuvre dans le terminal source T_SOUR, d'autre part une entité (ou "module") de protocole d'authentification PA2 et une fonction (encore appelée "module") de filtrage FILT mises en œuvre dans le pare-feu PF, et enfin un programme d'application APPLI2 mis en œuvre dans le portail captif PORT. Sur le figure 2, le dialogue Dl symbolise le dialogue permettant 1 'authentification de l'utilisateur dans une session SSL et le calcul d'un secret partagé entre le terminal source T_SOUR et le portail PORT; le dialogue D2 symbolise l'injection, dans l'entité de protocole d'authentification PAl du terminal source T_SOUR, du secret calculé grâce au dialogue Dl; et le dialogue D3 symbolise l'injection, dans l'entité de protocole d' authentification PA2 du pare-feu PF, du secret calculé grâce au dialogue Dl.
Sur le figure 3, le dialogue Dl symbolise le dialogue qui, bien que transitant à travers la couche 2 (notée L2) et la couche 1 (notée Ll) du modèle OSI, constitue un échange ECHG établi sur la couche 3 du modèle OSI entre l'entité de protocole d'authentification PAl du terminal source T_SOUR et l'entité correspondante PA2 du pare-feu PF et permet la ré-authentification périodique de l'utilisateur; le dialogue D2 symbolise la communication en IPsec entre le terminal source T_SOUR et le terminal de destination T_DEST; et le dialogue D3 symbolise la mise à jour des règles de filtrage par l'entité PA2 du pare-feu PF, en fonction du résultat de la ré-authentification.
L'entité de protocole d'authentification PAl mise en œuvre dans le terminal T_S0UR doit donc pouvoir interagir (dialogue D2 sur la Figure 2) avec le programme d'application APPLIl qui lui distribue des secrets lorsque l'authentification du terminal T_SOUR sur le réseau (dialogue Dl de la figure 2) a réussi.
L'entité de protocole d'authentification PAl mise en œuvre dans le terminal T_SOUR doit également être en relation directe avec la couche 3 du modèle OSI, par laquelle elle communique avec 1 'entité PA2 correspondante mise en œuvre dans le pare-feu PP (dialogue Dl de la figure 3, vu dans sa forme ECHG) .
L'entité de protocole d'authentification PA2 mise en œuvre dans le pare-feu PP doit pouvoir interagir (dialogue D3 sur la Figure 2) avec le programme d'application APPLI2 qui lui distribue des secrets lorsque 1 'authentification du terminal T_SOUR sur le réseau a réussi, et avec la fonction FILT de filtrage de paquets (dialogue D3 de la figure 3) pour la rendre "passante" lorsque 1 'authentification vérifiée par les entités PAl et PA2 réussit et "bloquante" lorsque 1 'authentification vérifiée par les entités PAl et PA2 échoue.
L'entité de protocole d1authentification PA2 mise en œuvre dans le pare-feu PF doit également être en relation directe avec la couche 3 du modèle OSI, par laquelle elle communique avec l'entité PAl correspondante mise en œuvre dans le terminal source T_SOUR (dialogue Dl de la figure 3, vu dans sa forme ECHG) .
Le terminal T_SOUR et le pare-feu PF doivent être en vue directe sur la couche 3 du modèle OSI, c'est-à-dire qu'ils peuvent être séparés par un nombre quelconque de routeurs, la présence de ces routeurs étant dépourvue de toute incidence sur la mise en oeuvre de l'invention.
Chronologiquement, le procédé comprend une phase initiale d'authentification du terminal T_SOUR, et une phase ultérieure périodique de ré-authentification des entités PAl et PA2.
Durant la phase d'authentification initiale, le terminal source T_SOUR, ou son usager, s'authentifie auprès du portail captif PORT en échangeant des données via le lien sécurisé symbolisé par le dialogue Dl de la figure 2, ce lien confidentiel pouvant être réalisé en TLS/SSL de manière classique.
Des secrets sont dérivés de cette authentification, symétriquement sur le terminal source T_SOUR et sur le portail captif PORT, par les programmes d'application respectifs APPLIl et APPLI2, puis retransmis par ces derniers aux entités d'authentification correspondantes PAl et PA2 (dialogues D2 et D3 de la figure 2) .
Une fois que les entités PAl et PA2 ont reçu les secrets permettant une reconnaissance mutuelle, elles mettent périodiquement en œuvre le protocole de ré-authentification du terminal T_SOUR par le pare-feu PF (dialogue Dl de la figure 3) .
Tant que cette ré-authentification réussit, le module de filtrage FILT du pare-feu PF est commandé par l'entité PA2
(dialogue D3 de la figure 3) pour rester passant pour les données du terminal T_SOUR (dialogue D2 de la figure 3), ce module de filtrage FILT étant, dans le cas contraire, commandé pour devenir bloquant. Dans ces conditions, tant que le module de filtrage FILT est passant, le flux de données dans lequel le terminal T_SOUR est impliqué peut librement circuler. Si ce terminal choisit de passer en mode bloquant, par exemple en appelant IPsec avec certains types de logiciels, alors la ré- authentification entre les entités PAl et PA2 peut continuer, le contrôle d'accès au niveau du pare-feu PF restant ainsi valide.
V. DESCRIPTION D'UN MODE PARTICULIER DE RÉALISATION DE L'INVENTION.
Cette partie de la description 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».
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. II 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'échanges 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 bannière d1authentification à l'usager,-
5. L'usager entre ses données d'authentification (typiquement un nom d'utilisateur 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 usager. 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'authentification périodique à l'usager, cette fenêtre permettant de maintenir la session entre l'usager et le portail captif grâce à la notion de jeton d'authentification, et étant donc encore ici appelé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'authentification) .
B. Mise en œuvre de 1 'invention dans le contexte rappelé ci-dessus.
L'utilisation de la fenêtre maintien de session, qui est protégée par des mécanismes cryptographiques à base de SSL/TLS (https sur la figure 2) , permet de dériver un secret qui est propre au terminal T_SOUR et au portail captif PORT. L'invention peut alors utiliser des mécanismes cryptographiques spécifiques afin d'assurer la confidentialité des informations transportées dans le nouveau protocole spécifié dans les ports autorisés (67/UDP, 68/UDP) , ainsi que la fonction dite "anti-rejeu" , c'est-à-dire la fonction destinée à bloquer des attaques parasites de connexion consistant à faire croire qu'un usager est toujours actif et à récupérer sa connexion à un moment choisi, par exemple lors d'une déconnexion intempestive.
Compte tenu de la multitude des possibilités offertes par les outils connus de l'homme du métier pour assurer une protection cryptographique, l'invention sera décrite ci- dessous au moyen d'un unique exemple particulier, non limitatif.
Le secret, protégé par SSL/TLS, est transmis du portail PORT vers le terminal T_SOUR dans la fenêtre d'authentification en réponse à une authentification réussie de ce terminal T_J3OUR. Dans la fenêtre d'authentification est également transmis un compteur qui est initialisé à la fois du côté du terminal T_SOUR, et du côté du portail captif PORT, ce secret et ce compteur permettant à la fois d'éviter les attaques d'usurpation d'identité et les attaques par re-jeu.
Un algorithme cryptographique de type fonction de hachage à clef (tel que HMAC-MD5 ou HMAC-SHAl) prend en entrée des informations telles que le compteur, l'adresse IP du terminal T_SOUR qui sont connues du portail captif, ainsi que le secret partagé (utilisé en tant que clef de la fonction de hachage à clef) . Il en résulte une chaîne de longueur fixe qui permet d'assurer à la fois 1 'authentification de l'utilisateur (grâce au secret partagé), l'anti-rejeu (grâce au compteur) et 1 'authentification de la machine (grâce à l'adresse IP) .
Le paquet est envoyé de l'entité PAl du terminal T_SOUR vers l'entité PA2 du pare-feu PF grâce au nouveau protocole mis en oeuvre par l'invention dans les ports autorisés (67/UDP, 68/UDP) , puis est analysé par le portail captif PORT qui vérifie le secret et le compteur.
Si la vérification se conclut par un succès, alors le compteur est incrémenté.
Dans le cas contraire, le système de contrôle d'accès du portail PORT considère qu'il y a usurpation d'identité et choisit, en fonction de la politique de sécurité, la décision la plus appropriée à la situation, telle que celle qui consiste à fermer la connexion en envoyant une instruction au module de filtrage FILT, ou à ignorer le paquet et à continuer d'attendre la réception d'un paquet valide (la connexion étant alors fermée si aucun paquet valide n'est reçu avant l'expiration d'un délai correspondant à la durée de validité d'une authentification) .
L'invention s'insère au niveau de la 7ème étape du processus standard de connexion tel que rappelé précédemment, à savoir celle dans laquelle le portail captif pousse périodiquement une fenêtre d'authentification à l'usager pour maintenir la session entre cet usager et le portail captif grâce à l'échange d'un jeton d'authentification.
L'invention conserve cette procédure de maintien de session, mais utilise une voie différente pour l'échange de l'information d'authentification entre l'usager et le portail captif. En pratique, la fenêtre de maintien de session comprend un logiciel d'application PAl mettant en œuvre un protocole d'authentification associé à un programme qui affiche un bouton de déconnexion permettant à l'usager du terminal source T_SOUR de se déconnecter proprement.
Cette technique repose sur un développement en mode client serveur dans les ports autorisés (67/UDP, 68/UDP) .
Le recours au langage Java pour la réalisation du logiciel du côté du terminal source est avantageux, bien que non obligatoire.
Les étapes ultérieures du processus de connexion suivant 1 ' invention sont les suivantes.
8. Le logiciel d'application exécuté sur le terminal T_SOUR envoie périodiquement des paquets sur le segment Ethernet en unicast IP vers le pare-feu PF, indiquant ainsi que ce terminal est toujours actif; si un attaquant présente des jetons d'authentification invalides, ceux-ci seront détectés par les procédés cryptographiques utilisés. La stratégie de sécurité peut facilement être adaptée à ce type d'événement. Il est alors possible, par exemple, de déconnecter l'usager et de déclencher une alarme auprès des administrateurs du portail captif. Il est également possible de ne pas considérer le jeton usurpé, de continuer d'attendre un paquet valide jusqu'à la fin d'un délai prédéterminé alloué à la connexion, et de déclencher une alarme auprès des administrateurs du portail captif. 9. Les informations contenues dans les paquets envoyés par le terminal source T_S0UR sont écoutées par un logiciel d'application PA2 présent sur le pare-feu PF. Ce dernier est capable, grâce aux informations contenues dans les paquets envoyés, de déterminer que l'usager du terminal T_SOUR est bien légitime, et que ce terminal est toujours connecté;
10. Deux cas sont possibles pour la déconnexion du terminal source T_SOUR:
I a. Si l'usager se déconnecte brutalement du réseau, c'est- à-dire sans utiliser le bouton de déconnexion de la fenêtre de maintien de session, il ferme du même coup cette fenêtre de maintien de session, de sorte que le logiciel d'application PAl cessera d'être exécuté. En conséquence, le portail captif PORT n'autorisera plus la connexion du terminal T_SOUR que pendant un temps de session résiduel préalablement fixé. Le système de contrôle d'accès du portail PORT considérera alors que l'usager n'est plus présent sur le réseau et n'est plus autorisé à communiquer à travers le pare-feu PF. Le portail captif mettra donc à jour les règles de filtrage du pare-feu PF pour interdire la connexion du terminal T_SOUR.
b. Si l'usager se déconnecte proprement du réseau, le système de contrôle d'accès du portail PORT sera informé que cet usager souhaite se déconnecter. Pour ce faire, l'usager informera le système de contrôle d'accès du portail PORT de son souhait de quitter le réseau en utilisant le bouton de déconnexion de la fenêtre de maintien de session. Le système de contrôle d'accès du portail PORT considérera alors que l'usager n'est plus présent sur le réseau et n'est plus autorisé à communiquer à travers le pare-feu PF. Le portail captif mettra donc à jour les règles de filtrage du pare-feu PF pour interdire la connexion du terminal T_SOUR.
Dans la mesure où la communication entre le terminal T__SOUR et le portail captif PORT doit être réalisée dans un port autorisé, il est possible d'utiliser un protocole à base UDP qui remplit les fonctions souhaitées telles que décrites. L'invention peut donc être mise en oeuvre aisément en spécifiant un protocole client-serveur au niveau UDP.
Par ailleurs, dans la mesure où l'invention impose la présence d'un logiciel d'application (PAl, figure 2) à exécuter sur le terminal source, il peut être judicieux de faire en sorte :
- que ce logiciel soit téléchargé de manière transparente depuis le portail captif à la suite de 1 'authentification réussie du terminal source auprès de ce portail; ceci peut être réalisé par 1 ' intermédiaire de la fenêtre de maintien de session qui transporte le jeton d'authentification dans le procédé actuel;
- que ce logiciel soit exécuté en local sur le terminal source de manière transparente pour l'usager; et
- que ce logiciel soit désactivé à la fin de la session par la fermeture de la fenêtre de maintien de session. L'invention offre l'avantage supplémentaire de permettre de faire transiter des informations autres que des données d'authentification. Par exemple, il est possible de profiter du canal de communication ouvert dans les ports autorisés et non susceptibles d'être bloqués pour faire passer des informations de facturation de 1 ' opérateur du portail captif vers l'usager (volume de données échangées, temps consommé, temps restant, etc. . .), ce type d'information pouvant être affiché dans la fenêtre de maintien de session sous la forme d'un tableau de bord.
Les programmes d'ordinateur mis en œuvre sur le terminal source T_SOUR et sur le pare-feu PF sont respectivement illustrés, de manière fonctionnelle et schématique, aux figures 4A et 4B.
Le programme illustré à la figure 4A, qui est implanté sur le terminal source T_SOUR, est conçu pour autoriser conditionnellement une connexion de ce terminal source en mode tunnel bloquant avec le terminal de destination T_DEST du réseau à travers le pare-feu PF.
Ce programme est essentiellement constitué d'un module d'initialisation M_INIT, d'un module de confirmation périodique d'authentification M_AUTH_PER, et d'un module de mise à jour et de décision M_MAJ_DEC.
Le module d'initialisation M_INIT a pour fonction de démarrer le processus d'authentification.
Pour ce faire, ce module M_INIT, qui est activé après l'authentification initiale du terminal source T_SOUR auprès du portail captif PORT, permet à ce terminal source de récupérer le secret partagé S communiqué par le portail PORT, et d'initialiser un compteur n.
Le module de confirmation périodique d1authentification M_AUTH__PER, qui est appelé par le module d'initialisation M_INIT, est propre à élaborer un authentifiant unique et à émettre cet authentifiant sur les ports non bloqués de la couche 3 du modèle OSI, à destination du pare-feu PF.
Comme le suggère symboliquement la figure 4A, l'authentifiant émis est par exemple élaboré comme une fonction f de l'adresse IP du terminal source, du contenu du compteur n, et du secret partagé S.
Le module de mise à jour et de décision M_MAJ_DEC, qui est appelé par le module de confirmation périodique d'authentification M_AUTH_PER, remplit essentiellement deux fonctions.
Tout d'abord ce module incrémente le compteur n en vue de la prochaine authentification du terminal source.
Et d'autre part, le module M_MAJ_DEC surveille la communication avec le pare-feu, de manière à mettre fin à la connexion en cas d'anomalie, et notamment en cas de silence prolongé de la part du pare-feu.
En l'absence d'anomalie, le M_MAJ_DEC appelle à nouveau le module de confirmation périodique d'authentification
M_AUTH_PER pour permettre à ce dernier de procéder à une nouvelle authentification du terminal source T_SOUR auprès du pare-feu PF pendant la connexion en mode tunnel bloquant.
Le programme illustré à la figure 4B, gui est implanté sur le pare-feu PF, est conçu pour autoriser conditionnellement une connexion en mode tunnel bloquant entre le terminal source T_SOUR et la terminal de destination T_DEST du réseau à travers ce pare-feu PF.
Ce second programme comprend essentiellement un module d'écoute M_ECOUT, un module de sélection M_SELECT, et un module d'analyse et de décision M_ANAL_DEC.
Le module d'écoute M_ECOUT est en permanence à l'écoute du réseau.
Le module de sélection M_SELECT, qui est appelé par le module d'écoute M_ECOUT, est propre à repérer, dans le flux de trames circulant sur la couche 3 du modèle OSI, les trames TR qui constituent les trames d1authentification TR_AUTH du terminal source T_SOUR, et à aiguiller ces trames d1authentification TR_AUTH vers le module d'analyse et de décision M_ANAL_DEC.
Le module d'analyse et de décision M_ANAL_DEC a quant à lui pour fonction de vérifier le contenu des trames d1authentification TR_AUTH reçues du terminal source, c'est-à-dire d'élaborer une fonction de décision g sur la base de ces trames TR_AUTH.
Si les données contenues dans les trames TR_AUTH ne sont pas reconnues comme acceptables, le module d'analyse et de décision M_MTAL_DEC déclenche une opération INHIB_PF correspondant à la destruction, sur le pare-feu PF, des règles d'accès du terminal source T_SOUR.
Si au contraire les données contenues dans les trames TR_AUTH sont correctes, le module d'analyse et de décision M_ANAL_DEC déclenche une opération Mi\J_PF correspondant à la création ou à la mise à jour, sur le pare-feu PF, des règles d'accès du terminal source T_SOUR.

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'authentification servi par une base (BDD) de données d'authentification, 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) ou au pare-feu (PF) de données d'authentification valides, à défaut desquelles le pare-feu est placé dans un état d'interdiction d'accès, le pare-feu
(PF) restant 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 d1authentification 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 bloquant, caractérisé en ce qu'au moins la fourniture périodique du jeton d1authentification est réalisée par une transmission sur au moins un port non bloqué de la couche de niveau 3 du modèle OSI du canal d'échange établi entre le terminal source (T_SOUR) et le pare-feu (PF) , ce dont il résulte que la fourniture périodique du jeton d1authentification continue à être assurée lors d'une communication en mode tunnel bloquant.
2. Procédé de contrôle d'accès suivant la revendication
1, caractérisé en ce qu'il comprend, postérieurement à une opération initiale réussie d'authentification du terminal source (T_SOUR) , au moins une opération d'élaboration d'un secret mise en œuvre sur le terminal source (T_SOUR) et / ou sur le portail captif (PORT) par l'un au moins de programmes d'application respectifs (APPLIl7 APPLI2) , et des opérations de retransmission (D2 et D3 de la figure 2) de ce secret à des entités d'authentification correspondantes (PAl, PA2) du terminal source (T_SOUR) et du pare-feu (PF) .
3. Procédé de contrôle d'accès suivant la revendication
2, caractérisé en ce que le secret est transmis, de façon sécurisée, du portail captif (PORT) au terminal source
(T_SOUR) dans une fenêtre d'authentification.
4. Procédé de contrôle d'accès suivant la revendication
3, caractérisé en ce que la fenêtre d1authentification assure également la transmission, du portail captif (PORT) vers le terminal source (T_SOUR) , d'un compteur initialisé à la fois du côté du terminal source (T_SOUR) et du portail captif (PORT) .
5. Procédé de contrôle d'accès suivant l'une quelconque des revendications 3 et 4, caractérisé en ce que la fenêtre d'authentification comporte un bouton de déconnexion.
6. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes combinée à la revendication
2, caractérisé en ce que, postérieurement à une opération initiale réussie d'authentification du terminal source (T_SOUR) , le jeton d'authentification est périodiquement fourni par l'entité d'authentification (PAl) du terminal source (T_SOUR) à destination de l'entité d'authentification (PA2) du pare-feu (PF), qui vérifie ce jeton.
7. Procédé de contrôle d'accès suivant les revendications 4 et 6, caractérisé en ce que, postérieurement à une opération initiale réussie d'authentification du terminal source (T_SOUR) , le compteur est périodiquement fourni par l'entité d'authentification (PAl) du terminal source (T_SOUR) à destination de l'entité d1authentification (PA2) du pare-feu (PF) , qui vérifie ce compteur.
8. Procédé de contrôle d'accès suivant l'une quelconque des revendications 6 et 7, caractérisé en ce que l'entité d'authentification (PA2) du pare-feu (PF), après vérification de données fournies par l'entité d'authentification (PAl) du terminal source (T_SOUR) , place un module de filtrage (FILT) du pare-feu dans un état d'autorisation ou d'interdiction d'accès en fonction du résultat de cette vérification.
9. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes combinée à la revendication 2, caractérisé en ce que l'entité d'authentification (PAl) du terminal source (T_SOUR) est réalisée en langage Java, téléchargée lors de 1 'authentification initiale de ce terminal source, et exécutée dans la fenêtre de maintien de session.
10. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes combinée à la revendication 2, caractérisé en ce que la transmission de niveau 3 établie entre les entités d1authentification (PAl, PA2) du terminal source (T_SOUR) et du pare-feu (PF) est développée dans le protocole DHCP.
11. Programme d'ordinateur destiné à être implanté sur un terminal source (T_SOUR) et conçu pour autoriser conditionnellement 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 comprend un module d'initialisation (M_INIT) propre à récupérer un secret partagé (S) en provenance du portail (PORT) et à initialiser un compteur (n) , un module de confirmation périodique d'authentification (M_AUTH_PER) appelé par le module d'initialisation (M_INIT) et propre à élaborer et à émettre à destination du pare-feu (PF) , sur un port non bloqué de la couche 3 du modèle OSI, un authentifiant unique dépendant au moins du secret partagé (S) et du contenu du compteur (n) , et un module de mise à jour et de décision (M_MAJ_DEC) appelé par le module de confirmation périodique d'authentification (M_AUTH_PER) et propre à incrémenter le compteur (n) , à mettre fin à la connexion en cas d'anomalie de communication avec le pare- feu, et à appeler à nouveau le module de confirmation périodique d'authentification (M_AUTH_PER) dans le cas contraire, ce dont il résulte que le terminal source (T_SOUR) continue à être authentifié par le pare-feu (PF) pendant la connexion en mode tunnel bloquant.
12. Programme d'ordinateur destiné à être implanté sur un pare-feu (PF) installé dans un réseau, et contrôlé par un portail captif (PORT) du réseau, pour autoriser conditionnellement une connexion en mode tunnel bloquant entre un terminal source (T_SOUR) et un terminal de destination (T_DEST) de ce réseau à travers le pare-feu
(PF), caractérisé en ce qu'il comprend un module d'écoute
(M_ECOUT) du réseau, un module de sélection (M_SELECT) , et un module d'analyse et de décision (M_ANAL_DEC) , en ce que le module d'écoute (M_ECOUT) du réseau est propre, en réponse à une demande d'authentification reçue du terminal source (T_SOUR) , à récupérer un secret partagé (S) en provenance de ce terminal source, en ce que le module de sélection (M_SELECT) est appelé par le module d'écoute (M_ECOUT) et propre à repérer, dans un flux de trames circulant sur la couche 3 du modèle OSI, des trames d'authentification (TR_AUTH) du terminal source (T_SOUR) , et à aiguiller les trames d'authentification (TR_AUTH) vers le module d'analyse et de décision (M_ANAL_DEC) , et en ce que le module d'analyse et de décision (M_ANAL_DEC) vérifie le contenu des trames d'authentification (TR_AUTH) , met fin à la connexion du terminal source (T_SOUR) en cas d'anomalie, et met à jour les règles d'autorisation de connexion utilisées par le pare-feu (PF) dans le cas contraire.
13. Terminal source, caractérisé en ce qu'il est au moins équipé du programme selon la revendication 11.
14. Pare-feu, caractérisé en ce qu'il est au moins équipé du programme selon la revendication 12.
PCT/FR2005/001881 2004-10-01 2005-07-21 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 WO2006037864A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0410398 2004-10-01
FR0410398 2004-10-01

Publications (2)

Publication Number Publication Date
WO2006037864A2 true WO2006037864A2 (fr) 2006-04-13
WO2006037864A3 WO2006037864A3 (fr) 2007-04-05

Family

ID=34952474

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/001881 WO2006037864A2 (fr) 2004-10-01 2005-07-21 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

Country Status (1)

Country Link
WO (1) WO2006037864A2 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317838B1 (en) * 1998-04-29 2001-11-13 Bull S.A. Method and architecture to provide a secured remote access to private resources
US7769838B2 (en) * 2001-08-23 2010-08-03 The Directv Group, Inc. Single-modem multi-user virtual private network

Also Published As

Publication number Publication date
WO2006037864A3 (fr) 2007-04-05

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
US7320143B2 (en) Method of gaining secure access to intranet resources
Patel et al. Securing L2TP using IPsec
US7661131B1 (en) Authentication of tunneled connections
US7890759B2 (en) Connection assistance apparatus and gateway apparatus
US7305546B1 (en) Splicing of TCP/UDP sessions in a firewalled network environment
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
EP1753173B1 (fr) Contrôle d'accès d'un équipement mobile à un réseau de communication IP par modification dynamique des politiques d'accès
EP1965559B1 (fr) Procédé de sécurisation d'un flux de données
FR2838896A1 (fr) Procedes et dispositifs pour former des connexions de reseau securisee sur un reseau prive
EP1351440A1 (fr) Dispositif pour la multidiffusion sécurisée
EP3643044A1 (fr) Procédé d'activation de traitements appliqués à une session de données
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
EP1672849B1 (fr) Procédé d'exploitation d'un réseau informatique local relié à un réseau distant privé par un tunnel IPsec
WO2022136796A1 (fr) Procedes pour la redirection de trafic, terminal, controleur, serveur d'autorisation, serveurs de resolution de noms, et programme d'ordinateur correspondants
FR2895816A1 (fr) Systeme, dispositif portable et procede pour la configuration d'un dispositif communicant dans un reseau
WO2005091565A9 (fr) Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant
WO2015097363A1 (fr) Procédé de ralentissement d'une communication dans un réseau
WO2006082296A2 (fr) Procede et dispositif de detection d'usurpations d'adresse dans un reseau informatique
EP4540971A1 (fr) Procédé de communication entre deux équipements, premier équipement, deuxième équipement et programme d'ordinateur correspondants
Patel et al. RFC3193: Securing L2TP using IPsec
WO2022117941A1 (fr) Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants
FR3124669A1 (fr) Procede et dispositif de securisation d’un reseau local comprenant un commutateur reseau auquel est reliee une station par liaison filaire
WO2004015953A2 (fr) Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local
FR2955727A1 (fr) Procede securise d'acces a un reseau et reseau ainsi protege

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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 KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG 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: A2

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 LV 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
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载