DE602004003568T2

DE602004003568T2 - Netzzugangskontrolle für ein mit einem VPN-Tunnel verbundenes Endgerät

Info

Publication number: DE602004003568T2
Application number: DE602004003568T
Authority: DE
Inventors: Olivier Charles; Laurent Butti; Franck Veysset
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2004-06-01
Filing date: 2004-06-01
Publication date: 2007-09-20
Anticipated expiration: 2024-06-02
Also published as: ES2279308T3; EP1605660A1; EP1605660B1; US7730527B2; DE602004003568D1; ATE347773T1; US20050273848A1

Description

Die Erfindung betrifft allgemein die Techniken des Zugriffs auf ein Datennetz.
Genauer betrifft die Erfindung ein Verfahren zur Kontrolle des Zugriffs eines Quelle-Terminals auf ein Netz mit einem Zugriffspunkt für dieses Terminal, mit einer Firewall, die mit dem Zugriffspunkt verbunden ist, und mit einem Authentifizierungsportal, das von einer Authentifizierungsdatenbank bedient wird, wobei dieses Portal die Firewall in einen Zustand der Zugriffsautorisierung versetzt als Antwort auf eine Anfangs-Zugriffsanforderung im Basismodus, die vom Quelle-Terminal stammt und die Lieferung gültiger Authentifizierungsdaten an das Portal oder die Firewall einschließt, mangels derer die Firewall in einen Zustand der Zugriffsverhinderung versetzt wird, wobei die Firewall in einem Zustand der Zugriffsautorisierung im Basismodus bleibt als Antwort auf die periodische Lieferung eines gültigen Authentifizierungstokens durch das Quelle-Terminal und auf einem gesicherten Token-Austauschkanal, mangels dessen die Firewall in ihren Zustand der Zugriffsverhinderung versetzt wird, und das Quelle-Terminal selektiv im Tunnelmodus mit einem Ziel-Terminal des Netzes über einen blockierenden Tunnel kommuniziert.
Die Zugriffskontrolle auf ein Netz ist die Prozedur, mit der der Betreiber eines Netzes einen potentiellen Benutzer autorisiert oder nicht autorisiert, sein Netz zu nutzen.
Es gibt aber Situationen, in denen es heute dem Betreiber nicht mehr möglich ist, die Zugriffskontrolle zu seinem Netz aufrechtzuerhalten, da der Benutzer die Verwendung eines Tunnels im blockierenden Modus wählt, was die Kommunikationen zwischen dem Benutzer und dem Netzbetreiber unmöglich macht.
Aus funktionellen oder Sicherheitsgründen kann der Benutzer eines Netzes nämlich veranlasst sein, einen Tunnel zu einem fernen Host aufzubauen, ein Tunnel, in dessen Innerem er seinen Verkehr verkapselt. Gemäß der Konfiguration und den verwendeten Softwareprogrammen kann dieser Tunnel im blockierenden Modus sein, d.h. alle Kommunikationen zurückweisen, die diesen Tunnel nicht sowohl in Empfangsrichtung als auch in Senderichtung verwenden.
Dieser blockierende Modus stellt tatsächlich eine zusätzliche Sicherheitsgarantie für den Benutzer dar. In dem Fall, in dem ein Benutzer sich über einen Tunnel mit dem privaten Netz oder dem "Intranet" seiner Firma verbindet, kann ein Pirat nämlich nicht die Maschine dieses Benutzers angreifen, um sie als Relais zu verwenden, um auf das Intranet von dessen Firma zuzugreifen.
Der Vorteil und die Modalitäten eines solchen Schutzes sind insbesondere im Artikel von HAIDONG XIA & al beschrieben: "Detecting and blocking unauthorized access in Wi-Fi networks" NETWORKING 2004. NETWORKING TECHNOLOGIES, SERVICES AND PROTOCOLS. THIRD INTERNATIONAL IFIP-TC6 NETWORKING CONFERENCE (LECTURE NOTES IN COMPUT. SCI., Mai 2004, Seiten 795–806, ISBN: 3-540-21959-5).
In diesem Kontext hat die Erfindung zum Ziel, ein Verfahren vorzuschlagen, das es dem Betreiber eines Netzes ermöglicht, die Zugriffskontrolle auf sein Netz beizubehalten, selbst wenn ein Benutzer die Verwendung eines Tunnels im blockierenden Modus wählt.
Zu diesem Zweck ist das erfindungsgemäße Verfahren, das ansonsten der generischen Definition entspricht, die die obige Einleitung angibt, hauptsächlich dadurch gekennzeichnet, dass zumindest die periodische Lieferung des Authentifizierungstokens durch eine Übertragung in der Schicht der Ebene 2 des OSI-Modells des Token-Austauschkanals, der zwischen dem Quelle-Terminal und der Firewall aufgebaut ist, durchgeführt wird, woraus folgt, dass die periodische Lieferung des Authentifizierungstokens bei einer Kommunikation im blockierenden Tunnelmodus weiter gewährleistet ist.
Zum Beispiel weist das erfindungsgemäße Verfahren nach einer gelungenen Anfangsoperation der Authentifizierung des Quelle-Terminals mindestens eine Operation der Ausarbeitung eines Geheimnisses, die im Quelle-Terminal und/oder im Captive-Portal durch mindestens eines von Anwendungsprogrammen durchgeführt wird, und Operationen der Rückübertragung dieses Geheimnisses an entsprechende Authentifizierungseinheiten des Quelle-Terminals und der Firewall auf.
In der Regel wird der Begriff "Geheimnis", wie er in der vorliegenden Beschreibung verwendet wird, als nicht nur im eigentlichen Sinn ein besonderes Geheimnis, das genau definiert und direkt verwendbar ist, sondern ebenfalls alle Elemente abdeckend verstanden, die es ermöglichen, ein solches Geheimnis im eigentlichen Sinn abzuleiten oder zu rekonstruieren.
Das Geheimnis kann vorteilhafterweise vom Captive-Portal zum Quelle-Terminal in einem Authentifizierungsfenster übertragen werden.
Insbesondere in diesem Fall kann das Authentifizierungsfenster ebenfalls die Übertragung eines Zählers vom Captive-Portal zum Quelle-Terminal gewährleisten, der sowohl auf der Seite des Quelle-Terminals als auch des Captive-Portals initialisiert wird.
Außerdem kann das Authentifizierungsfenster vorteilhafterweise einen Abschaltknopf aufweisen.
Nach einer gelungenen Anfangsoperation der Authentifizierung des Quelle-Terminals wird das Authentifizierungstoken zum Beispiel periodisch von der Authentifizierungseinheit des Quelle-Terminals an die Authentifizierungseinheit der Firewall geliefert, die dieses Token verifiziert.
In gleicher Weise wird nach einer gelungenen Anfangsoperation der Authentifizierung des Quelle-Terminals der Zähler vorzugsweise periodisch von der Authentifizierungseinheit des Quelle-Terminals an die Authentifizierungseinheit der Firewall geliefert, die diesen Zähler verifiziert.
Nach der Verifizierung von Daten, die von der Authentifizierungseinheit des Quelle-Terminals geliefert werden, kann die Authentifizierungseinheit der Firewall ein Filtermodul der Firewall in Abhängigkeit vom Ergebnis dieser Verifizierung in einen Zustand der Zugriffsautorisierung oder der Zugriffsverhinderung versetzen.
Die Authentifizierungseinheit des Quelle-Terminals wird zum Beispiel in der Programmiersprache Java hergestellt, die bei der Anfangsauthentifizierung dieses Quelle-Terminals heruntergeladen und im Sitzung-Aufrechterhaltungsfenster ausgeführt wird.
Außerdem wird die Übertragung der Ebene 2, die zwischen den Authentifizierungseinheiten des Quelle-Terminals und der Firewall aufgebaut wird, vorteilhafterweise gemäß einer Erweiterung des Protokolls ARP entwickelt.
Die Erfindung betrifft ebenfalls ein erstes Computerprogramm, das dazu bestimmt ist, in einem Quelle-Terminal installiert zu werden, und das entwickelt wurde, um bedingt eine Verbindung dieses Quelle-Terminals im blockierenden Tunnelmodus mit einem Ziel-Terminal eines Netzes über eine Firewall zu autorisieren, die von einem Captive-Portal des Netzes kontrolliert wird, wobei dieses erste Programm dadurch gekennzeichnet ist, dass es einen Initialisierungsmodul, der geeignet, ein vom Portal kommendes gemeinsames Geheimnis zu empfangen und einen Zähler zu initialisieren, einen Modul zur periodischen Authentifizierungsbestätigung, der vom Initialisierungsmodul angerufen wird und geeignet ist, eine einzige Authentifizierung, die mindestens vom gemeinsamen Geheimnis und vom Inhalt des Zählers abhängt, auszuarbeiten und an die Firewall und an die Schicht 2 des OSI-Modells zu senden, und einen Aktualisierungs- und Entscheidungsmodul aufweist, der vom Modul der periodischen Authentifizierungsbestätigung angerufen wird und geeignet ist, den Zähler zu inkrementieren, die Verbindung im Fall einer Kommunikationsanomalie mit der Firewall zu beenden, und im gegenteiligen Fall erneut den Modul der periodischen Authentifizierungsbestätigung anzurufen, woraus sich ergibt, dass das Quelle-Terminal während der Verbindung im blockierenden Tunnelmodus weiter von der Firewall authentifiziert wird.
Die Erfindung betrifft ebenfalls ein zweites Computerprogramm, das dazu bestimmt ist, in einer Firewall installiert zu werden, die in einem Netz installiert ist und von einem Captive-Portal des Netzes kontrolliert wird, um bedingt eine Verbindung im blockierenden Tunnelmodus zwischen einem Quelle-Terminal und einem Ziel-Terminal dieses Netzes über die Firewall zu autorisieren, wobei dieses zweite Programm dadurch gekennzeichnet ist, dass es einen Hörmodul des Netzes, einen Auswahlmodul, und einen Analyse- und Entscheidungsmodul aufweist, dass der Hörmodul des Netzes geeignet ist, um als Antwort auf eine Authentifizierungsanforderung, die vom Quelle-Terminal empfangen wird, ein von diesem Quelle-Terminal kommendes gemeinsames Geheimnis abzurufen, dass der Auswahlmodul vom Hörmodul angerufen wird und geeignet ist, in einem Fluss von Rahmen, die in der Schicht 2 des OSI-Modells zirkulieren, Authentifizierungsrahmen des Quelle-Terminal zu erfassen und die Authentifizierungsrahmen zum Analyse- und Entscheidungsmodul zu leiten, und dass der Analyse- und Entscheidungsmodul den Inhalt der Authentifizierungsrahmen verifiziert, die Verbindung des Quelle-Terminals im Fall einer Anomalie beendet, und im gegenteiligen Fall die von der Firewall verwendeten Verbindungs-Autorisationsregeln aktualisiert.
Die Erfindung betrifft ebenfalls ein System zur Kontrolle des Zugriffs eines Quelle-Terminals auf ein Datennetz, mit einer Firewall, die zwischen dem Datennetz und einem Zugriffspunkt für das Quelle-Terminal angeordnet ist, und mit einem Authentifizierungsportal, das den Zustand der Firewall steuert, wobei die Firewall in der Lage ist, einen gesicherten Kommunikationskanal für das Quelle-Terminal offen zu halten, unter der Bedingung, dass das Quelle-Terminal periodisch oder bei einem Ereignis ein Authentifizierungstoken sendet, wobei dieses System dadurch gekennzeichnet ist, dass:

– die Firewall einen Authentifizierungsprotokollmodul und einen Filtermodul aufweist, wobei der Authentifizierungsprotokollmodul in der Lage ist, den Filtermodul für die Kommunikationen zwischen dem Quelle-Terminal und dem Datennetz "leitend" oder "sperrend" zu machen, je nachdem, ob das Quelle-Terminal authentifiziert wird oder nicht,
– das Authentifizierungsportal ein Anwerfindungsprogramm enthält, das in der Lage ist, Geheimnisse an den Authentifizierungsprotokollmodul auszugeben, wenn die Anfangsauthentifizierung des Quelle-Terminals im Datennetz erfolgreich war,
– das Quelle-Terminal einen Authentifizierungsprotokollmodul und ein Anwendungsprogramm aufweist, wobei das Anwendungsprogramm in der Lage ist, Geheimnisse an den Authentifizierungsprotokollmodul auszugeben, wenn die Anfangsauthentifizierung des Quelle-Terminals im Datennetz erfolgreich war,

Weitere Merkmale und Vorteile der Erfindung gehen klar aus der nachfolgenden Beschreibung hervor, die unverbindlich und nicht einschränkend ist und sich auf die beiliegenden Zeichnungen bezieht. Es zeigen:
1 schematisch die Betriebsmittel, die für die Anwendung der Erfindung notwendig sind;
2 die Informationsflüsse, die zwischen dem Quelle-Terminal, der Firewall und dem Authentifizierungsportal ausgehend von der Authentifizierungsprozedur des Quelle-Terminals verwendet werden; und
3 die Informationsflüsse, die zwischen dem Quelle-Terminal, der Firewall und dem Authentifizierungsportal während der Verwendung des Tunnels im blockierenden Modus verwendet werden, und
die 4A und 4B Ablaufdiagramme, die das im Quelle-Terminal verwendete Computerprogramm bzw. das in der Firewall verwendete Computerprogramm darstellen.
Aufgrund der Notwendigkeit, um das erfindungsgemäße Verfahren in einer für den Fachmann verständlichen Weise ausführlich zu beschreiben, das Standardvokabular dieses letzteren zu verwenden, findet der mit dem betreffenden Bereich wenig vertraute Leser nachfolgend die Definitionen und Referenzen, die für sein eigenes Verständnis der Beschreibung nützlich sind.
1. DEFINITIONEN.
IP-Adresse: Adresse einer Einrichtung, die IP (siehe dieses Wort) als Protokoll der Schicht 3 des OSI-Modells (siehe dieses Wort) verwendet.
MAC-Adresse: Adresse einer Einrichtung, die mit einem gemeinsam genutzten Medium verbunden ist, das von der Schicht 2 des OSI-Modells (siehe dieses Wort) verwendet wird.
ARP (aus dem Englischen entnommenes Akronym "Address Resolution Protocol"): Protokoll der Auflösung der IP-Adressen in MAC-Adressen der Ebene 2 des OSI-Modells (siehe dieses Wort), das es ermöglicht, Arbeitsplätze auf einem Netzwerk auf Ethernetbasis kommunizieren zu lassen. Die realen Kommunikationen basieren nämlich auf den MAC-Adressen der Quelle und des Empfängers.
DHCP (aus dem Englischen entnommenes Akronym "Dynamic Host Configuration Protocol"): Dynamisches Zuweisungsprotokoll der Adressen in einem IP-Netz (siehe dieses Wort).
DNS (aus dem Englischen entnommenes Akronym "Domain Name Server" oder "Domain Name System"): Hauptdienst des Internets, der die Umwandlung der Domainnamen in IP-Adressen (siehe dieses Wort) gewährleistet.
Hash-Funktion: Dieser Ausdruck bezeichnet eine Funktion, die eine Kette von Buchstaben beliebiger Länge in eine Kette von Buchstaben mit fester Größe kleinerer Größe umwandelt, diese Kette wird Fingerabdruck (hash) genannt. Das Ergebnis einer Hash-Funktion ist das gleiche für die gleiche Eingangskette, aber im Prinzip gibt es keine zwei gleichen Hash-Funktion-Ergebnisse.
Hash-Funktion mit Schlüssel: Dieser Ausdruck bezeichnet eine Hash-Funktion, die zusätzlich zu einer Buchstabenkette beliebiger Länge am Eingang einen Geheimschlüssel nimmt.
HMAC-MD5 (aus dem Englischen entnommenes Akronym "Keyed-Hashing for Message Authentification" – "Message Digest 5"): Kryptographischer Algorithmus des Typs "Hash-Funktion mit Schlüssel" (siehe diesen Ausdruck).
HMAC-SHA1 (aus dem Englischen entnommenes Akronym "Keyed-Hashing for Message Authentification" – "Secure Hash Algorithm"): Kryptographischer Algorithmus des Typs "Hash-Funktion mit Schlüssel" (siehe diesen Ausdruck).
HTML (aus dem Englischen entnommenes Akronym "HyperText Markup Language"): Internet-Dokumentformat, definiert durch die Norm RFC 1866.
HTTPS (aus dem Englischen entnommenes Akronym "HyperText Transfer Protocol Secure"): Vom Browser "Netscape" stammendes und mit einer gesicherten Verbindung verbundenes Übertragungsprotokoll.
IP (aus dem Englischen entnommenes Akronym "Internet Protocol"): Im Internet verwendetes, orientiertes Netzebenenprotokoll ohne Verbindung (Prinzip des Datagramms).
IPsec (aus dem Englischen entnommenes Akronym "Internet Protocol Security"): Im Internet verwendetes Sicherheitsprotokoll.
MAC (aus dem Englischen entnommenes Akronym "Medium Access Control"): Allgemeiner Begriff, der die Schicht bezeichnet, die die gemeinsame Nutzung eines Übertragungsträgers zwischen verschiedenen Stationen verwaltet.
Open Source (englischer Ausdruck): Freie Software, die definierten qualitativen Anforderungen entspricht.
OSI (aus dem Englischen entnommenes Akronym "Open System Interconnection"): Modell der Zusammenschaltung der offenen Systeme, bei dem die Gesamtheit der Aktionen, die es ermöglichen, mehrere Computereinrichtungen kooperieren zu lassen, in Schichten strukturiert ist, die unterschiedlichen Detailebenen entsprechen.
SSL (aus dem Englischen entnommenes Akronym "Secure Socket Layer"): Norm des Modus der gesicherten Kommunikation im Netz, ursprünglich vom Browser der Marke "Netscape" verwendet und dann offiziell bestätigt.
TCP (aus dem Englischen entnommenes Akronym "Transport Control Protocol"): Verbindungsorientiertes Transportprotokoll, das einen zuverlässigen Austausch einer beliebigen Menge von Daten zwischen zwei Einrichtungen (OSI-Ebene 4 – siehe dieses Wort) erlaubt, die über ein oder mehrere Netze verbunden sind, die IP verwenden (siehe dieses Wort).
TLS (aus dem Englischen entnommenes Akronym "Transport Layer Security"): Sicherungsprotokoll der Transportschicht, definiert durch die Norm RFC 2246. Die Version 1.0 von TLS ist tatsächlich die Version 3 von SSL (siehe dieses Wort).
UDP (aus dem Englischen entnommenes Akronym "User Datagram Protocol"): Transportprotokoll von unabhängigen Datenblöcken oder "Paketen", die über ein Netz gehen und alle für ihr Routing notwendigen Informationen enthalten.
URL (aus dem Englischen entnommenes Akronym "Uniform Ressource Locator"): Adressenformat, das es ermöglicht, eine Ressource wiederzufinden.
VPN (aus dem Englischen entnommenes Akronym "Virtual Private Network"): Virtuelles privates Netz.
II. REFERENZEN.

[ARP] Address Resolution Protocol, "An Ethernet Address Resolution Protocol", RFC 826, November 1982.
[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.1X, September 2001.
[IEEE 802.3-2002] IEEE Standard for Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.
[IEEE-802.11-1997] Institute of Electrical and Electronics Engineers, "Information Technology – Telecommunications and Information Exchange between Systems – Local and Metropolitan Area Network – Specific Requirements – Part 11: Wireless LAN Medium Access Control (MAC} and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1997.
[IEEE-802.11-1999] Institute of Electrical and Electronics Engineers, "Information Technology – Telecommunications and Information Exchange between Systems – Local and Metropolitan Area Network – Specific Requirements – Part I1: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements – Part I1: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE Draft 802.11i (work in progress), 2003.
[IPsec] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[OSI] International Organization for Standardization, "Open Systems Interconnexion", ISO 7498.
[TLS] Dierks, T. and Allen, C., "The TLS Protocol version 1.0", RFC 2246, Januar 1999.
[WPA] Wi-Fi protected Access, Wi-Fi Alliance, version 1.2, Dezember 2002.

Das nachfolgend beschriebene Verfahren betrifft typischerweise ein Szenario, bei dem der Netzbetreiber eine Zugriffskontrolle zur Ebene TCP/IP durchführt, und bei dem der Benutzer einen Tunnel wie [IPsec] im blockierenden Modus verwenden möchte.
Die Erfindung kann eine relevante Anwendung finden bei den funkelektrischen Netzen IEEE 802.11 ([IEEE-802.11- 1997] und [IEEE-802.11-1999]) der "ersten Generation", d.h., die nicht die neuen Sicherheitsfunktionalitäten in der Ebene 2 des Modells [OSI] wie WPA oder 802.11i. anwenden, und in den drahtgebundenen Netzen IEEE 802.3 ([IEEE 802.3-2002]) und Ethernet, die eine Zugriffskontrolle gemäß dem Paradigma des "Captive-Portals" durchführen.
III. STAND DER TECHNIK
Vor der Zugriffskontrolle liegt die Authentifizierung. Die Authentifizierung ermöglicht es dem Betreiber des Netzes, mit Gewissheit die Identität des Benutzers zu bestimmen, der sein Netz benutzen möchte.
Um einen Benutzer zu authentifizieren, muss der Betreiber eines Netzes mit diesem dialogisieren.
Bei einer erfolgreichen Authentifizierung entscheidet der Betreiber des Netzes in Abhängigkeit von der Identität des Benutzers, ob dieser autorisiert ist oder nicht, auf das Netz zuzugreifen.
Um zu vermeiden, dass illegitime Benutzers unberechtigt vom Netz profitieren, ist es für die Zugriffskontrolle notwendig:

– sich zu vergewissern, dass nur die Benutzer, die der Betreiber autorisiert hat, das Netz benutzen können, d.h. zu verhindern, dass ein nicht autorisierter Benutzer das Netz benutzen kann; und
– die Authentifizierungsbeziehung mit dem Benutzer aufrechtzuerhalten, d.h. sich zu vergewissern, dass der autorisierte Benutzer, der das Netz nutzt, sehr wohl derjenige ist, der sich authentifiziert hat, um zu verhindern, dass ein nicht autorisierter Benutzer die Identität eines autorisierten Benutzers unbefugt verwendet. Mehrere Techniken ermöglichen es, eine Zugriffskontrolle zum Netz durchzuführen, insbesondere:
– physikalische Techniken: Zum Beispiel befinden sich die Anschlüsse, die den Zugriff zum Netz erlauben, in verschlossenen Räumen; und
– logische Techniken: Zum Beispiel ist der Zugriff zum Netz durch den Besitz eines Geheimnisses bedingt, das es ermöglicht, kryptographische Techniken zu verwenden.

In Abwesenheit von Sicherheitsmechanismen, die die Zugriffskontrolle auf der Ebene 2 (Datenlink) des Modells mit sieben Schichten des [OSI] umfassen, oder aufgrund der mit der Ausbreitung solcher Mechanismen verbundenen Kosten, wenn sie existieren, und der sehr geringen Penetrationsrate dieser letzteren in den Gerätepark der Benutzer, wurde das Paradigma des Captive-Portal" entwickelt.
Dieses Paradigma ermöglicht es, eine Kontrolle des Zugriffs auf die TCP/IP-Netze durchzuführen:

– mittels Durchführung einer Filterung an den Adressen MAC und IP; und
– durch Verwendung der Authentifizierungstoken, die zwischen dem Quelle-Terminal und dem Authentifizierungsportal ausgetauscht werden.

Bei seiner Verbindung mit dem Netz wird der Benutzer aufgefordert, seinen Internet-Browser zu öffnen, und seine erste Anfrage mit Hilfe dieses letzteren wird automatisch zum Authentifizierungsportal des Betreibers umgeleitet (daher der Name Captive-Portal). Dieses Captive-Portal ermöglicht es dem Benutzer, sich gesichert zu authentifizieren, zum Beispiel unter Verwendung der Protokolle SSL/[TLS).
Alle anderen Anfragen des nicht authentifizierten Benutzers werden von einer Firewall blockiert, die eine Filterung über MAC-Adresse und/oder IP-Adresse durchführt. Bei einer erfolgreichen Authentifizierung und in dem Fall, in dem der authentifizierte Benutzer autorisiert ist, auf das Netz zuzugreifen, wird die Firewall aktualisiert, um den Verkehr dieses Benutzers durchzulassen.
Die Architektur eines Captive-Portals (1), das es einem Quelle-Terminal T_SOUR erlaubt, im Tunnelmodus mit einem Ziel-Terminal T_DEST des Netzes zu kommunizieren, setzt so global einen Zugriffspunkt P_ACC, eine Firewall PF, das Authentifizierungsportal PORT selbst, und eine Identifikationsdatenbank BDD voraus.
Der Zugriffspunkt P_ACC bietet dem Quelle-Terminal T_SOUR einen drahtgebundenen oder drahtlosen Verbindungskanal (Wi-Fi zum Beispiel) zum Internet.
Die Firewall PF kontrolliert direkt den Zugriff des Terminals T_SOUR auf das Internet, indem sie die Pakete (typischerweise auf der IP- und TCP-Ebene) filtert, und indem sie eine Filterung über MAC-Adresse durchführt.
Das Portal PORT authentifiziert den Benutzer, fängt die Anfragen der nicht authentifizierten Benutzer ab, leitet diese Benutzer zu einer Authentifizierungsseite um, lässt seine Authentifizierungsdaten von der Datenbank BDD verifizieren, verändert die Regeln der Firewall PF in Abhängigkeit vom Ergebnis dieser Verifizierung und steuert somit den Zustand der Firewall.
Die Datenbank BDD enthält ihrerseits die gültigen Daten der autorisierten Benutzer und antwortet auf die Anfragen des Portals PORT.
Da die Zugriffskontrolle über MAC-Adresse und IP-Adresse intrinsisch schwach ist (es ist tatsächlich sehr einfach, durch einfache Softwaremanipulation, die MAC-Adresse und die IP-Adresse eines Benutzers unbefugt zu verwenden), verwendet das Captive-Portal PORT eine zusätzliche Zugriffskontrolle durch ein Token, das zwischen dem Quellen-Terminal und dem Authentifizierungsportal ausgetauscht wird.
Das Captive-Portal bewacht nämlich einen gesicherten Kommunikationskanal, der mit dem Benutzer offen ist, in dem der Benutzer periodisch oder bei einem Ereignis ein Authentifizierungstoken präsentieren muss. Die fehlende Präsentation dieses Tokens führt zum Reset der Firewall in den für diesen Benutzer blockierenden Zustand. So kann ein nicht autorisierter Benutzer, der unbefugt die MAC-Adresse und/oder die IP-Adresse eines autorisierten Benutzers verwendet, dieses Token nicht präsentieren, und seine Verbindung wird beendet. Selbst wenn die gleichzeitige Anwesenheit eines autorisierten Benutzers, der das Token präsentieren muss, und eines nicht autorisierten Benutzers, der die MAC-Adresse und die IP-Adresse dieses autorisierten Benutzers unbefugt verwendet, vorstellbar ist, machen die Betriebsmechanismen der TCP/IP-Protokolle die Verbindungen unbrauchbar: Wenn der nicht autorisierte Benutzer von der Verbindung des autorisierten Benutzers profitieren will, hat er derzeit keine andere Wahl als den autorisierten Benutzer verstummen zu lassen, zum Beispiel durch Dienstverweigerung. Nachdem er den autorisierten Benutzer zum Verstummen gebracht hat, kann der nicht autorisierte Benutzer vom Dienst nur so lange profitieren, wie das Captive-Portal nicht die Präsentation des Tokens fordert, ein Zeitintervall, das auf der Ebene des Captive-Portals PORT konfiguriert werden kann.
Das Paradigma des "Captive-Portal", wie es bis jetzt beschrieben wurde, betrifft zum Beispiel sowohl die funkelektrischen Netzwerke, die die Technologie IEEE 802.11 verwenden, als auch die lokalen drahtgebundenen Netzwerke, die die Technologien IEEE 802.3/Ethernet verwenden.
Im Fall der funkelektrischen Netzwerke, die die Technologie IEEE 802.11 verwenden, haben sich bei den Sicherheitsmechanismen, die ursprünglich in der Norm [IEEE802.11-1997] und [IEEE802.11-1999] vorgesehen waren, schnell große Probleme herausgestellt, die ihre Verwendung ebenso schwierig wie wirkungslos machen: Es ist das perfekte Scheitern 2000 und 2001 der unter dem Akronym "WEP" bekannten Sicherheitsmechanismen.
Obwohl robustere Sicherheitsmechanismen derzeit verbreitet werden [WPA] oder spezifiziert werden [IEEE-802.11i], haben sie bis jetzt keine ausreichende Reife, um in großem Umfang verbreitet zu werden.
Zwei Szenarien, bei denen das Paradigma des "Captive-Portal" die funkelektrischen Netzwerke betrifft, die die Technologie IEEE 802.11 verwenden, sind

– die lokalen funkelektrischen Netzwerke, "Hot-Spots" genannt, die die Technologie IEEE 802.11 verwenden und an vielbesuchten Orten verbreitet werden, zum Beispiel Hotelhallen oder Flughafen-Wartesäle, wo die Bereitstellung einer Internetverbindung einen großen Zusatzwert darstellt; und
– die Zugriffe auf ein Netz, die von einem Unternehmen seinen Besuchern angeboten werden, um es diesen letzteren zu ermöglichen, wirksamer zu arbeiten, zum Beispiel in den Konferenzräumen.

Im Fall der lokalen drahtgebundenen Netzwerke, die die Technologien IEEE 802.3/Ethernet verwenden, wurde ursprünglich kein Sicherheitsmechanismus vorgesehen. Erst 2001, mit der Übernahme der Norm [IEEE802.1X-2001], sind Sicherheitsmechanismen für diese Netzwerke entstanden.
Ihre Penetrationsrate in den Gerätepark der Benutzer ist aber noch gering. Daher kann ein Unternehmen, dass seinen Besuchern einen Netzzugang zum Beispiel im Konferenzraum anbieten möchte, sich veranlasst sehen, das Paradigma "Captive-Portal" zu verwenden.
Der Schwachpunkt der bekannten Technik des Captive-Portals, das die Zugriffskontrolle durch Filterung der IP-Adresse und/oder der MAC-Adresse durch einen Austausch von Authentifizierungstoken verstärkt, liegt genau darin, dass diese Technik voraussetzt, dass der Betreiber und der Benutzer in der Lage sind, zu dialogisieren, um das Token austauschen zu können.
Die typischste von den Benutzern in den vorgestellten Szenarien verwendete Anwendung besteht für diese Benutzer aber darin, in einen Tunnel (wodurch ein VPN erzeugt wird) zum Intranet ihres Unternehmens einzutreten.
Aus Sicherheitsgründen verhindern die meisten VPN-Anwendungen dann alle anderen Kommunikationen zu oder von dem Benutzer als diejenigen, die innerhalb des VPN verlaufen. Es handelt sich also um Tunnel im blockierenden Modus.
In diesem Fall ist es also nicht mehr möglich, den Austausch von Authentifizierungstoken aufrechtzuerhalten, und es gibt derzeit keine Lösung für dieses Problem.
Folglich:

– wird entweder die Sicherung durch Austausch eines Token dann ganz einfach im Paradigma "Captive-Portal" aufgegeben, in welchem Fall die Zugriffskontrolle zum Netz nur noch in einer Filterung über IP-Adresse und/oder MAC-Adresse besteht, was kritische Schwachstellen aufweist,
– oder die Sicherung durch Austausch von Token wird aufrechterhalten, und der Benutzer kann nicht in einen Tunnel im blockierenden Modus, zum Beispiel zum Intranet seines Unternehmens, eintreten, da die erste Anfrage des Austauschs von Token nach dem Aufbau des Tunnels fehlschlagen und der Verkehr des Benutzers blockiert wird.

IV. PRINZIP DER ERFINDUNG
Die Erfindung ermöglicht es dem Betreiber eines Netzes, eine wirksame Zugriffskontrolle zu seinem Netz aufrechtzuerhalten, selbst in dem Fall, in dem der Benutzer sich entscheidet, einen Tunnel im blockierenden Modus zu benutzen.
Diese Erfindung schlägt einen Modus der periodischen Neu-Authentifizierung vor, die für den Benutzer vollkommen unsichtbar ist. Außerdem ermöglicht die Verwendung eines Übertragungskanals, der nicht vom blockierenden Modus zwischen dem Terminal und dem Captive-Portal betroffen ist, den Austausch von zusätzlichen Informationen, wie zum Beispiel Verbindungsdauern oder verbrauchte Mengen.
Die Verbindung beruht auf der Beobachtung der Tatsache, dass die Technik des blockierenden Modus, die vom Beispiel von den Benutzers von IPsec verwendet wird, die Eigenschaft hat, die Datenpakete in der Ebene 3 des OSI-Modells zu filtern.
Diese Eigenschaft, die von den Herausgebern von Softwareprogrammen nicht veröffentlicht wird, hat zur Folge, dass die Verwendung eines Tunnels im blockierenden Modus sich nicht von den Kommunikationen lösen kann, die in der Ebene 2 des OSI-Modells vom implizierten Protokoll ausgeführt werden, zum Beispiel dem ARP-Protokoll.
Die Erfindung nutzt diese Eigenschaft, um den Austausch des Authentifizierungstokens aufrechtzuerhalten, aber auf der Ebene 2 des OSI-Modells und nicht auf den Ebenen 3 und höheren, wie im derzeitigen Stand der Technik.
Die so eingebrachte Änderung ermöglicht es, sowohl den blockierenden Modus des Benutzers IPsec beizubehalten, als auch ein starkes periodisches Authentifizierungsprotokoll zu verwenden.
Hierzu wird die Sitzungskontrolle, d.h. typischerweise der Mechanismus des Austauschs von Token zwischen dem Quelle-Terminal T_SOUR und dem Portal PORT, in die Ebene 2 des OSI-Modells (L2 in den 2 und 3) verschoben, was es ermöglicht, sie von jedem blockierenden Modus (M_BLQ in 3) unabhängig zu machen, der ggf. vom Benutzer des Terminals T_SOUR in höheren Schichten dieses Modells eingesetzt wurde.
Es ist dem Benutzer eines Tunnels im blockierenden Modus nämlich nicht möglich, die Kommunikationen seines Terminals T_SOUR in der Ebene 2 des OSI-Modells zu verhindern, da dieses Terminal unbedingt in der Ebene 2 mit den Gateways oder Routern des Netzes dialogisieren können muss, um Datenpakete nach außen zu senden und von außen zu empfangen, und wobei es vollständig vom Netz isoliert wäre, wenn dieser Dialog unterbrochen würde.
Konkret verwendet die Erfindung einerseits eine Einheit (auch "Modul" genannt) eines Authentifizierungsprotokolls PA1 und ein Anwendungsprogramm APPLI1, das im Quelle-Terminal T_SOUR angewendet wird, andererseits eine Einheit (oder "Modul") eines Authentifizierungsprotokolls PA2 und eine Funktion (auch "Modul" genannt) der Filterung FILT, die in der Firewall PF eingesetzt werden, und schließlich ein Anwendungsprogramm APPLI2, das im Captive-Portal PORT eingesetzt wird.
Die Authentifizierungsprotokolleinheit PA1, die im Terminal T_SOUR eingesetzt wird, muss fähig sein, mit dem Anwendungsprogramm APPLI1 zu interagieren (Dialog D2 in 2), das ihm Geheimnisse zuteilt, wenn die Authentifizierung des Terminals T_SOUR im Netz (Dialog D1 der 2) gelungen ist.
Die Authentifizierungsprotokolleinheit PA1, die im Terminal T_SOUR eingesetzt wird, muss ebenfalls in direkter Verbindung mit der Schicht 2 (L2) des OSI-Modells stehen, über die sie mit der entsprechenden Einheit PA2 kommuniziert, die in der Firewall PF (Dialog D1 der 3) eingesetzt wird.
Die Authentifizierungsprotokolleinheit PA2, die in der Firewall PF eingesetzt wird, muss fähig sein, mit dem Anwendungsprogramm APPLI2 (Dialog D3 in 2), das ihm Geheimnisse zuteilt, wenn die Authentifizierung des Terminals T_SOUR im Netz gelungen ist, und mit der Funktion FILT der Filterung von Paketen (Dialog D3 der 3) zu interagieren, um sie "leitend" zu machen, wenn die von den Einheiten PA1 und PA2 verifizierte Authentifizierung gelingt, und "blockierend", wenn die von den Einheiten PA1 und PA2 verifizierte Authentifizierung scheitert.
Die Authentifizierungsprotokolleinheit PA2, die in der Firewall PF eingesetzt wird, muss ebenfalls in direkter Verbindung mit der Schicht 2 des OSI-Modells stehen, über die sie mit der entsprechenden Einheit PA1 kommuniziert, die im Quelle-Terminal T_SOUR eingesetzt wird (Dialog D1 der 3).
Abgesehen von einer besonderen Anpassung, die später diskutiert werden wird, müssen das Terminal T_SOUR und die Firewall PF direkt in der Schicht 2 des OSI-Modells sichtbar sein, d.h. ohne jeden Zwischenrouter.
Chronologisch weist das Verfahren eine Anfangsphase der Authentifizierung des Terminals T_SOUR und eine spätere periodische Phase der Neu-Authentifizierung der Einheiten PA1 und PA2 auf.
Während der Phase der Anfangsauthentifizierung authentifiziert sich das Quelle-Terminal T_SOUR oder sein Benutzer beim Captive-Portal PORT durch Austausch von Daten über das gesicherte Link, das durch den Dialog D1 der 2 symbolisiert wird, wobei dieses vertrauliche Link in TLS/SSL in üblicher Weise hergestellt werden kann.
Geheimnisse werden aus dieser Authentifizierung symmetrisch auf das Quelle-Terminal T_SOUR und auf das Captive-Portal PORT von den Anwendungsprogrammen APPLI1 bzw. APPLI2 abgeleitet und dann von diesen letzteren an die entsprechenden Authentifizierungseinheiten PA1 und PA2 (Dialoge D2 und D3 der 2) weiter übertragen.
Wenn die Einheiten PA1 und PA2 die Geheimnisse empfangen haben, die eine gegenseitige Erkennung ermöglichen, setzen sie periodisch das Protokoll der Neu-Authentifizierung des Terminals T_SOUR durch die Firewall PF ein (Dialog D1 der 3).
So lange diese Neu-Authentifizierung gelingt, wird der Filtermodul FILT der Firewall PF von der Einheit PA2 gesteuert (Dialog D3 der 3), um für die Daten des Terminals T_SOUR leitend zu bleiben (Dialog D2 der 3), wobei dieser Filtermodul FILT im gegenteiligen Fall gesteuert wird, um blockierend zu werden.
So lange der Filtermodul FILT leitend ist, kann unter diesen Umständen der Datenfluss, in den das Terminal T_SOUR impliziert ist, frei zirkulieren. Wenn dieses Terminal beschließt, in den blockierenden Modus überzugehen, zum Beispiel unter Aufruf von IPsec bei bestimmten Typen von Softwareprogrammen, kann die Neu-Authentifizierung zwischen den Einheiten PA1 und PA2 fortgesetzt werden, wodurch die Zugriffskontrolle auf der Ebene der Firewall PF gültig bleibt.
V. BESCHREIBUNG EINER BESONDEREN AUSFÜHRUNGSFORM DER ERFINDUNG.
Dieser Teil der Erfindung erklärt, wie das erfindungsgemäße Verfahren in einen bekannten Mechanismus der Zugriffskontrolle durch ein "Captive-Portal" eingesetzt werden kann.
A. Erinnerung an den aktuellen Kontext.
Hier wird der klassische Betriebsmodus einer Verbindung zwischen einem Benutzer und einem Netzwerk angegeben, das die Technologie des "Captive-Portal" unterstützt. Diese Technologie wird in vielen kommerziellen Produkten eingesetzt und ist ebenfalls in einem Produkt Open Source verfügbar, das mit NoCatAuth bezeichnet ist (insbesondere auf der Internetseite http://nocat.net beschrieben).
Diese "Captive-Portal"-Open-Source-Lösung steuert mehrere Open-Source-Filter-Engines wie "iptables", "packetfilter" oder "IPFilter", die jeweils auf den Internetseiten: http://iptables.org, http://www.benzedrine.cx/pf.html, und http://www.ipfilter.org. beschrieben sind.
Es ermöglicht die Steuerung dieser Filter-Engines aufgrund eines Dialogs zwischen dem Captive-Portal und einer Anwendung, die die Filter-Engine steuert.
Die Schritte des Standard-Verbindungsprozesses sind die folgenden.

1. Der Benutzer verbindet sich mit dem Netz, dessen Zugriffskontrolle vom Captive-Portal durchgeführt wird;
2. das Netz erlaubt ihm, die Informationen der klassischen Konnektivität (IP-Adresse, DNS-Server-Adressen, Standard-Gateway-Adressen, ...) abzurufen, wobei dies im Allgemeinen mit Hilfe von DHCP-Austauschvorgängen erfolgt;
3. der Benutzer beschließt, sich im Netz zu authentifizieren, um Zugriff zu den von der lokalen Website (typischerweise das Internet) angebotenen Dienste zu erhalten;
4. der Benutzer sendet eine Anfrage an das Internet, die von der Filter-Engine (Standard-Regeln) aufgefangen und zum "Captive-Portal" umgeleitet wird. Das "Captive-Portal" präsentiert dann dem Benutzer das Authentifizierungsbanner;
5. der Benutzer gibt seine Authentifizierungsdaten ein (typischerweise ein Benutzername und ein Passwort), die vom "Captive-Portal" validiert werden;
6. das "Captive-Portal" interagiert mit der Filter-Engine, um die Standard-Filterregeln für diesen Benutzer zu ändern. In diesem Moment ist der Benutzer in der Lage, nach außen zu kommunizieren (typischerweise mit dem Internet) in Abhängigkeit von den neuen Filterregeln, die der Filter-Engine mitgeteilt werden;
7. das "Captive-Portal" schiebt ein periodisches Authentifizierungsfenster zum Benutzer, wobei dieses Fenster es ermöglicht, aufgrund des Begriffs des Authentifizierungstokens die Sitzung zwischen dem Benutzer und dem Captive-Portal aufrechtzuerhalten, das hier also auch "Sitzung-Aufrechterhaltungsfenster" genannt wird.

In der Praxis kann das Sitzung-Aufrechterhaltungsfenster im HTML-Code geschrieben werden, was es ermöglicht, periodisch eine Verbindung zu einer gut formatierten URL zu initiieren (die insbesondere das Authentifizierungstoken enthält).
B. Anwendung der Erfindung im oben aufgeführten Modus.
Die Verwendung des Sitzung-Aufrechterhaltungsfensters, das von kryptographischen Mechanismen auf der Basis von SSL/TLS (https in 2) geschützt wird, ermöglicht es, ein Geheimnis abzuleiten, das dem Terminal T_SOUR und dem Captive-Portal PORT eigen ist. Die Erfindung kann dann spezifische kryptographische Mechanismen verwenden, um die Vertraulichkeit der Informationen zu gewährleisten, die im neuen Protokoll transportiert werden, das in der Ebene 2 des OSI-Modells spezifiziert wird, sowie die "Anti-Replay" genannte Funktion, d.h. die Funktion, die dazu bestimmt ist, Störattacken der Verbindung zu blockieren, die darin bestehen, glauben zu lassen, dass ein Benutzer immer noch aktiv ist, und seine Verbindung in einem gewählten Moment zu erlangen, zum Beispiel bei einem unbeabsichtigten Abmelden.
Unter Berücksichtigung der Vielfalt von Möglichkeiten, die von den dem Fachmann bekannten Werkzeugen zur Gewährleistung eines kryptographischen Schutzes bekannt sind, wird die Erfindung nachfolgend anhand eines einzigen besonderen, nicht einschränkend zu verstehenden Beispiels beschrieben.
Das Geheimnis, das von SSL/TLS geschützt wird, wird vom Portal PORT zum Terminal T_SOUR im Authentifizierungsfenster als Antwort auf eine gelungene Authentifizierung dieses Terminals T_SOUR übertragen. Im Authentifizierungsfenster wird ebenfalls ein Zähler übertragen, der sowohl vom Terminal T_SOUR als auch vom Captive-Portal PORT initialisiert wird, wobei dieses Geheimnis und dieser Zähler es ermöglichen, sowohl die Angriffe der widerrechtlichen Aneignung der Identität als auch die Angriffe durch Replay zu verhindern.
Ein kryptographischer Algorithmus vom Typ Hash-Funktion mit Schlüssel (wie HMAC-MD5 oder HMAC-SHA1) nimmt am Eingang Informationen wie den Zähler, die IP-Adresse des Terminals T_SOUR, die dem Captive-Portal bekannt sind, sowie das gemeinsam genutzte Geheimnis (das als Schlüssel der Hash-Funktion mit Schlüssel verwendet wird). Daraus entsteht eine Kette fester Länge, die es ermöglicht, sowohl die Authentifizierung des Benutzers (aufgrund des gemeinsam genutzten Geheimnisses), das Anti-Replay (aufgrund des Zählers) und die Authentifizierung der Maschine (aufgrund der IP-Adresse) zu gewährleisten.
Das Paket wird mit Hilfe des von der Erfindung verwendeten Protokolls der Ebene 2 von der Einheit PA1 des Terminals T_SOUR zur Einheit PA2 der Firewall PF geschickt, und wird dann vom Captive-Portal PORT analysiert, das das Geheimnis und den Zähler verifiziert.
Wenn die Verifizierung von Erfolg gekrönt ist, wird der Zähler inkrementiert.
Im gegenteiligen Fall nimmt das Zugriffskontrollsystem des Portals PORT an, dass eine widerrechtliche Identitätsaneignung vorliegt und wählt in Abhängigkeit von der Sicherheitspolitik die am besten für die Situation geeignete Entscheidung, zum Beispiel diejenige, die darin besteht, die Verbindung zu unterbrechen, indem ein Befehl an den Filtermodul FILT geschickt wird, oder das Paket zu ignorieren und weiter auf den Empfang eines gültigen Pakets zu warten (wobei die Verbindung dann unterbrochen wird, wenn kein gültiges Paket vor dem Ablauf einer Frist empfangen wird, die der Gültigkeitsdauer einer Authentifizierung entspricht).
Die Erfindung fügt sich auf der Ebene des siebten Schritts des Standard-Verbindungsprozesses ein, wie er oben in Erinnerung gerufen wurde, d.h. derjenigen, in der das Captive-Portal periodisch ein Authentifizierungsfenster zum Benutzer schiebt, um die Sitzung zwischen diesem Benutzer und dem Captive-Portal mit Hilfe des Austauschs eines Authentifizierungstoken aufrechtzuerhalten.
Die Erfindung behält dieses Verfahren der Aufrechterhaltung der Sitzung bei, verwendet aber einen anderen Weg für den Austausch der Authentifizierungsinformation zwischen dem Benutzer und dem Captive-Portal.
In der Praxis weist das Sitzung-Aufrechterhaltungsfenster eine Anwendungssoftware PA1 auf, die ein Authentifizierungsprotokoll einsetzt, das einem Programm zugeordnet ist, das einen Abschaltknopf anzeigt, der es dem Benutzer des Quelle-Terminal T_SOUR ermöglicht, sich richtig abzuschalten.
Diese Technik beruht auf einer Entwicklung im Client/Server-Modus in der Ebene 2.
Das Zurückgreifen auf die Java-Programmiersprache für die Herstellung der Software auf der Seite des Quelle-Terminals ist vorteilhaft, aber nicht zwingend.
Die späteren Schritte des erfindungsgemäßen Verbindungsverfahrens sind die folgenden.

8. Die im Terminal T_SOUR ausgeführte Anwendungssoftware sendet periodisch Pakete auf dem Ethernet-Segment zur Firewall PF, wodurch sie anzeigt, dass dieses Terminal immer noch aktiv ist; wenn ein Angreifer ungültige Authentifizierungstoken präsentiert, werden diese von den verwendeten kryptographischen Verfahren erfasst. Die Sicherheitsstrategie kann leicht an diese Art Ereignis angepasst werden. Es ist dann zum Beispiel möglich, den Benutzer abzuschalten und einen Alarm bei den Administratoren des Captive-Portal auszulösen. Es ist ebenfalls möglich, das unbefugt verwendete Token nicht zu berücksichtigen und weiter bis zum Ende einer vorbestimmten Zeitdauer, die der Verbindung zugeteilt ist, auf ein gültiges Paket zu warten und einen Alarm bei den Administratoren des Captive-Portal auszulösen.
9. Die in den vom Quelle-Terminal T_SOUR gesendeten Paketen enthaltenen Informationen werden von einer Anwendungssoftware PA2 abgehört, die in der Firewall PF vorhanden ist. Letztere ist aufgrund der in den gesendeten Paketen enthaltenen Informationen in der Lage, zu bestimmen, dass der Benutzer des Terminals T_SOUR legitim ist, und dass dieses Terminal nach wie vor verbunden ist;
10. Zwei Fälle sind für das Abschalten des Quelle-Terminals T_SOUR möglich:
a. Wenn der Benutzer sich abrupt aus dem Netz abschaltet, ohne den Abschaltknopf des Sitzung-Aufrechterhaltungsfensters zu benutzen, schließt er gleichzeitig dieses Sitzung-Aufrechterhaltungsfenster, so dass die Anwendungssoftware PA1 nicht mehr ausgeführt wird. Folglich autorisiert das Captive-Portal PORT die Verbindung des Terminals T_SOUR nur noch während einer vorher festgelegten Restsitzungszeit. Das Zugriffskontrollsystem des Portals PORT nimmt dann an, dass der Benutzer nicht mehr im Netz und nicht mehr autorisiert ist, über die Firewall PF zu kommunizieren. Das Captive-Portal aktualisiert also die Filterregeln der Firewall PF, um die Verbindung des Terminals T_SOUR zu verbieten.
b. Wenn der Benutzer sich korrekt aus dem Netz ausschaltet, wird das Zugriffskontrollsystem des Portals PORT informiert, dass dieser Benutzer sich abschalten möchte. Hierzu informiert der Benutzer das Zugriffskontrollsystem des Portals PORT über seinen Wunsch, das Netz zu verlassen, indem er den Abschaltknopf des Sitzung-Aufrechterhaltungsfensters benutzt. Das Zugriffskontrollsystem des Portals PORT nimmt dann an, dass der Benutzer nicht mehr im Netz und nicht mehr autorisiert ist, über die Firewall PF zu kommunizieren. Das Captive-Portal aktualisiert also die Filterregeln der Firewall PF, um die Verbindung des Terminals T_SOUR zu verbieten.

Insofern als die Kommunikation zwischen dem Terminal T_SOUR und dem Captive-Portal PORT mittels eines Protokolls der Ebene 2 durchgeführt werden muss, ist es möglich, bereits existierende Protokolle wie ARP zu verwenden, um die Nutzdaten in spezifischen Zonen des Protokolls zu verkapseln. Die einzige zwingend zu beachtende Erfordernis ist es, zu veranlassen, dass der Serverbereich in der Lage ist, das auf der Seite des Benutzers spezifizierte Protokoll zu verstehen. Es ist aber auch möglich, ein Protokoll auf Ethernet-Basis zu spezifizieren, wobei es wichtig ist, ein Protokoll in der Ebene 2 zu spezifizieren.
Da das von der Anwendungssoftware der Sitzungsaufrechterhaltung verwendete Protokoll sich in der Ebene 2 der OSI-Schicht befindet, durchquert es nicht die Einrichtungen der Ebene 3, d.h. typischerweise die Router. Es kann also notwendig sein, ebenfalls ein Protokoll der Verkapselung und des bidirektionalen Transports der Rahmen der Schicht 2 des Benutzers von und/oder zu der fernen Firewall zu spezifizieren.
Diese Notwendigkeit betrifft den Rahmen zentralisierter Architekturen zwischen mehreren "Hot Spots", die an getrennten geographischen Orten verteilt sind, die dann alle miteinander an einem zentralen Standort verbunden sind, wo sich ein zentrales Captive-Portal befindet.
Eine andere Lösung besteht jedoch darin, Captive-Portale an jedem fernen "Hot Spot" zu verbreiten und keine Zugriffskontrolle mehr an einem zentralen Standort durchzuführen.
Außerdem kann es insofern, als die Erfindung das Vorhandensein einer Anwendungssoftware (PA1, 2) bedingt, die im Quelle-Terminal auszuführen ist, vernünftig sein, dafür zu sorgen, dass:

– diese Software transparent vom Captive-Portal heruntergeladen wird nach der gelungenen Authentifizierung des Quelle-Terminals in diesem Portal; dies kann über das Sitzung-Aufrechterhaltungsfenster erfolgen, das das Authentifizierungstoken im aktuellen Verfahren transportiert;
– diese Software lokal im Quelle-Terminal in für den Benutzer transparenter Weise ausgeführt wird; und
– diese Software am Ende der Sitzung durch das Schließen des Sitzung-Aufrechterhaltungsfensters deaktiviert wird.

Die Erfindung bietet den zusätzlichen Vorteil zu erlauben, dass andere Informationen als Authentifizierungsdaten weitergeleitet werden. Es ist zum Beispiel möglich, vom offenen Kommunikationskanal in der Schicht 2 zu profitieren, der nicht blockiert werden kann, um Fakturierungsinformationen vom Betreiber des Captive-Portals zum Benutzer zu übermitteln (Menge ausgetauschter Daten, verbrauchte Zeit, verbleibende Zeit, usw.), wobei diese Art Information im Sitzung-Aufrechterhaltungsfenster in Form eines Armaturenbretts angezeigt werden kann.
Die Computerprogramme, die im Quelle-Terminal T_SOUR und in der Firewall PF eingesetzt werden, sind funktionell und schematisch in den 4A bzw. 4B dargestellt.
Das in 4A veranschaulichte Programm, das im Quelle-Terminal T_SOUR installiert ist, ist konzipiert, um bedingt eine Verbindung dieses Quelle-Terminals im blockierenden Tunnelmodus mit dem Ziel-Terminal T_DEST des Netzes über die Firewall PF zu autorisieren.
Dieses Programm besteht hauptsächlich aus einem Initialisierungsmodul M_INIT, einem Modul der periodischen Authentifizierungsbestätigung M_AUTH_PER, und einem Aktualisierungs- und Entscheidungsmodul M_MAJ_DEC.
Der Initialisierungsmodul M_INIT hat die Aufgabe, den Authentifizierungsprozess zu starten.
Hierzu erlaubt dieser Modul M_INIT, der nach der Anfangsauthentifizierung des Quelle-Terminals T_SOUR im Captive-Portal PORT aktiviert wird, es diesem Quelle-Terminal, das gemeinsam genutzte Geheimnis S abzurufen, das vom Portal PORT mitgeteilt wird, und einen Zähler n zu initialisieren.
Der Modul der periodischen Authentifizierungsbestätigung M_AUTH_PER, der vom Initialisierungsmodul M_INIT aufgerufen wird, ist geeignet, einen einzigen Authentikator zu erarbeiten und diesen Authentikator in der Schicht 2 des OSI-Modells an die Firewall PF zu senden.
Wie es 4A symbolisch vorschlägt, wird der gesendete Authentikator zum Beispiel als eine Funktion f der IP-Adresse des Quelle-Terminals, des Inhalts des Zählers n und des gemeinsam genutzten Geheimnisses S ausgearbeitet.
Der Aktualisierungs- und Entscheidungsmodul M_MAJ_DEC, der vom Modul der periodischen Authentifizierungsbestätigung M_AUTH_PER aufgerufen wird, erfüllt hauptsächlich zwei Funktionen.
Zunächst inkrementiert dieser Modul den Zähler n für die nächste Authentifizierung des Quelle-Terminals.
Und andererseits überwacht der Modul M_MAJ_DEC die Kommunikation mit der Firewall, um die Verbindung im Fall einer Anomalie zu beenden, und insbesondere im Fall eines längeren Schweigens der Firewall.
Wenn keine Anomalie vorliegt, ruft der M_MAJ_DEC erneut den Modul der periodischen Authentifizierungsbestätigung M_AUTH_PER auf, um es diesem letzteren zu erlauben, eine neue Authentifizierung des Quelle-Terminals T_SOUR in der Firewall PF während der Verbindung im blockierenden Tunnelmodus durchzuführen.
Das in 4B veranschaulichte Programm, das in der Firewall PF installiert ist, ist konzipiert, um bedingt eine Verbindung im blockierenden Tunnelmodus zwischen dem Quelle-Terminal T_SOUR und dem Ziel-Terminal T_DEST des Netzes über diese Firewall PF zu autorisieren.
Dieses zweite Programm enthält hauptsächlich einen Hörmodul M_ECOUT, einen Auswahlmodul M_SELECT, und einen Analyse- und Entscheidungsmodul M_ANAL_DEC.
Der Hörmodul M_ECOUT hört permanent das Netz ab.
Der Auswahlmodul M_SELECT, der vom Hörmodul M_ECOUT aufgerufen wird, ist geeignet, um im in der Schicht 2 des OSI-Modells zirkulierenden Rahmenfluss die Rahmen TR zu erfassen, die die Authentifizierungsrahmen TR_AUTH des Quelle-Terminals T_SOUR bilden, und diese Authentifizierungsrahmen TR_AUTH zum Analyse- und Entscheidungsmodul M_ANAL_DEC zu lenken.
Der Analyse- und Entscheidungsmodul M_ANAL_DEC hat seinerseits die Funktion, den Inhalt der Authentifizierungsrahmen TR_AUTH zu verifizieren, die vom Quelle-Terminal empfangen werden, d.h. eine Entscheidungsfunktion g auf der Basis dieser Rahmen TR_AUTH zu erarbeiten.
Wenn die in den Rahmen TR_AUTH enthaltenen Daten nicht als akzeptabel erkannt werden, löst der Analyse- und Entscheidungsmodul M_ANAL_DEC eine Operation INHIB_PF aus, die der Zerstörung der Zugriffsregeln des Quelle-Terminals T_SOUR in der Firewall PF entspricht.
Wenn dagegen die in den Rahmen TR_AUTH enthaltenen Daten korrekt sind, löst der Analyse- und Entscheidungsmodul M_ANAL_DEC eine Operation MAJ_PF aus, die der Erzeugung oder der Aktualisierung der Zugriffsregeln des Quelle-Terminals T_SOUR in der Firewall PF entspricht.

Claims

Verfahren zur Kontrolle des Zugriffs eines Quelle-Terminals (T_SOUR) auf ein Netz mit einem Zugriffspunkt (P_ACC) für dieses Terminal, mit einer Firewall (PF), die mit dem Zugriffspunkt (P_ACC) verbunden ist, und mit einem Authentifizierungsportal (PORT), das von einer Authentifizierungsdatenbank (BDD) bedient wird, wobei dieses Portal (PORT) die Firewall (PF) in einen Zustand der Zugriffsautorisierung versetzt als Antwort auf eine Anfangs-Zugriffsanforderung im Basismodus, die vom Quelle-Terminal (T_SOUR) stammt und die Lieferung gültiger Authentifizierungsdaten an das Portal (PORT) oder die Firewall (PF) einschließt, mangels derer die Firewall in einen Zustand der Zugriffsverhinderung versetzt wird, wobei die Firewall (PF) in einem Zustand der Zugriffsautorisierung im Basismodus bleibt als Antwort auf die periodische Lieferung eines gültigen Authentifizierungstokens durch das Quelle-Terminal (T_SOUR) und auf einem gesicherten Token-Austauschkanal, mangels dessen die Firewall (PF) in ihren Zustand der Zugriffsverhinderung versetzt wird, und das Quelle-Terminal (T_SOUR) selektiv im Tunnelmodus mit einem Ziel-Terminal (T_DEST) des Netzes über einen blockierenden Tunnel kommuniziert, dadurch gekennzeichnet, dass zumindest die periodische Lieferung des Authentifizierungstokens durch eine Übertragung in der Schicht der Ebene 2 des OSI-Modells des Token-Austauschkanals, der zwischen dem Quelle-Terminal (T_SOUR) und der Firewall (PF) aufgebaut ist, durchgeführt wird, woraus folgt, dass die periodische Lieferung des Authentifizierungstokens bei einer Kommunikation im blockierenden Tunnelmodus weiter gewährleistet ist.
Zugriffskontrollverfahren nach Anspruch 1, dadurch gekennzeichnet, dass es nach einer gelungenen Anfangsoperation der Authentifizierung des Quelle-Terminals (T_SOUR) mindestens eine Operation der Ausarbeitung eines Geheimnisses, die im Quelle-Terminal (T_SOUR) und/oder im Captive-Portal (PORT) durch mindestens eines von Anwendungsprogrammen (APPLI1, APPLI2) durchgeführt wird, und Operationen der Rückübertragung (D2 und D3 der 2) dieses Geheimnisses an entsprechende Authentifizierungseinheiten (PA1, PA2) des Quelle-Terminals (T_SOUR) und der Firewall (PF) aufweist.
Zugriffskontrollverfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Geheimnis auf gesicherte Weise vom Captive-Portal (PORT) zum Quelle-Terminal (T_SOUR) in einem Authentifizierungsfenster übertragen wird.
Zugriffskontrollverfahren nach Anspruch 3, dadurch gekennzeichnet, dass das Authentifizierungsfenster ebenfalls die Übertragung eines Zählers vom Captive-Portal (PORT) zum Quelle-Terminal (T_SOUR) gewährleistet, der sowohl auf der Seite des Quelle-Terminals (T_SOUR) als auch des Captive-Portals (PORT) initialisiert wird.
Zugriffskontrollverfahren nach einem der Ansprüche 3 und 4, dadurch gekennzeichnet, dass das Authentifizierungsfenster einen Abschaltknopf aufweist.
Zugriffskontrollverfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass nach einer gelungenen Anfangsoperation der Authentifizierung des Quelle-Terminals (T_SOUR) das Authentifizierungstoken periodisch von der Authentifizierungseinheit (PA1) des Quelle- Terminals (T_SOUR) an die Authentifizierungseinheit (PA2) der Firewall (PF) geliefert wird, die dieses Token verifiziert.
Zugriffskontrollverfahren nach den Ansprüchen 4 und 6, dadurch gekennzeichnet, dass nach einer gelungenen Anfangsoperation der Authentifizierung des Quelle-Terminals (T_SOUR) der Zähler periodisch von der Authentifizierungseinheit (PA1) des Quelle-Terminals (T_SOUR) an die Authentifizierungseinheit (PA2) der Firewall (PF) geliefert wird, die diesen Zähler verifiziert.
Zugriffskontrollverfahren nach einem der Ansprüche 6 und 7, dadurch gekennzeichnet, dass nach der Verifizierung von Daten, die von der Authentifizierungseinheit (PA1) des Quelle-Terminals (T_SOUR) geliefert werden, die Authentifizierungseinheit (PA2) der Firewall (PF) einen Filtermodul (FILT) der Firewall in Abhängigkeit vom Ergebnis dieser Verifizierung in einen Zustand der Zugriffsautorisierung oder der Zugriffsverhinderung versetzt.
Zugriffskontrollverfahren nach einem der vorhergehenden Ansprüche 2 bis 8, dadurch gekennzeichnet, dass die Authentifizierungseinheit (PA1) des Quelle-Terminals (T_SOUR) in der Programmiersprache Java hergestellt wird, die bei der Anfangsauthentifizierung dieses Quelle-Terminals heruntergeladen und im Sitzung-Aufrechterhaltungsfenster ausgeführt wird.
Zugriffskontrollverfahren nach einem der vorhergehenden Ansprüche 2 bis 9, dadurch gekennzeichnet, dass die Übertragung der Ebene 2, die zwischen den Authentifizierungseinheiten (PA1, PA2) des Quelle-Terminals (T_SOUR) und der Firewall (PF) aufgebaut wird, gemäß einer Erweiterung des Protokolls ARP entwickelt wird.
Computerprogramm, das dazu bestimmt ist, in einem Quelle-Terminal (T_SOUR) installiert zu werden, und das entwickelt wurde, um bedingt eine Verbindung dieses Quelle-Terminals im blockierenden Tunnelmodus mit einem Ziel-Terminal (T_DEST) eines Netzes über eine Firewall (PF) zu autorisieren, die von einem Captive-Portal (PORT) des Netzes kontrolliert wird, dadurch gekennzeichnet, dass es einen Initialisierungsmodul (M_INIT), der in der Lage ist, ein vom Portal (PORT) kommendes gemeinsames Geheimnis (S) zu empfangen und einen Zähler (n) zu initialisieren, einen Modul zur periodischen Authentifizierungsbestätigung (M_AUTH_PER), der vom Initialisierungsmodul (M_INIT) angerufen wird und in der Lage ist, eine einzige Authentifizierung, die mindestens vom gemeinsamen Geheimnis (S) und vom Inhalt des Zählers (n) abhängt, auszuarbeiten und an die Firewall (PF) und an die Schicht 2 des OSI-Modells zu senden, und einen Aktualisierungs- und Entscheidungsmodul (M_MAJ_DEC) aufweist, der vom Modul der periodischen Authentifizierungsbestätigung (M_AUTH_PER) angerufen wird und in der Lage ist, den Zähler (n) zu inkrementieren, die Verbindung im Fall einer Kommunikationsanomalie mit der Firewall zu beenden, und im gegenteiligen Fall erneut den Modul der periodischen Authentifizierungsbestätigung (M_AUTH_PER) anzurufen, woraus sich ergibt, dass das Quelle-Terminal (T_SOUR) während der Verbindung im blockierenden Tunnelmodus weiter von der Firewall (PF) authentifiziert wird.
Computerprogramm, das dazu bestimmt ist, in einer Firewall (PF) installiert zu werden, die in einem Netz installiert ist und von einem Captive-Portal (PORT) des Netzes kontrolliert wird, um bedingt eine Verbindung im blockierenden Tunnelmodus zwischen einem Quelle-Terminal (T_SOUR) und einem Ziel-Terminal (T_DEST) dieses Netzes über die Firewall (PF) zu autorisieren, dadurch gekennzeichnet, dass es einen Hörmodul (M_ECOUT) des Netzes, einen Auswahlmodul (M_SELECT), und einen Analyse- und Entscheidungsmodul (M_ANAL_DEC) aufweist, dass der Hörmodul (M_ECOUT) des Netzes geeignet ist, um als Antwort auf eine Authentifizierungsanforderung, die vom Quelle-Terminal (T_SOUR) empfangen wird, ein von diesem Quelle-Terminal kommendes gemeinsames Geheimnis (S) zu empfangen, dass der Auswahlmodul (M_SELECT) vom Hörmodul (M_ECOUT) angerufen wird und geeignet ist, in einem Fluss von Rahmen, die in der Schicht 2 des OSI-Modells zirkulieren, Authentifizierungsrahmen (TR_AUTH) des Quelle-Terminal (T_SOUR) zu erfassen und die Authentifizierungsrahmen (TR_AUTH) zum Analyse- und Entscheidungsmodul (M_ANAL_DEC) zu leiten, und dass der Analyse- und Entscheidungsmodul (M_ANAL_DEC) den Inhalt der Authentifizierungsrahmen (TR_AUTH) verifiziert, die Verbindung des Quelle-Terminals (T_SOUR) im Fall einer Anomalie beendet, und im gegenteiligen Fall die von der Firewall (PF) verwendeten Verbindungs-Autorisationsregeln aktualisiert.
System zur Kontrolle des Zugriffs eines Quelle-Terminals auf ein Datennetz, mit einer Firewall (PF), die zwischen dem Datennetz und einem Zugriffspunkt (P_ACC) für das Quelle-Terminal (T_SOUR) angeordnet ist, und mit einem Authentifizierungsportal (PORT), das den Zustand der Firewall (PF) steuert, wobei die Firewall (PF) in der Lage ist, einen gesicherten Kommunikationskanal für das Quelle-Terminal (T_SOUR) offen zu halten, unter der Bedingung, dass das Quelle-Terminal (T_SOUR) periodisch oder bei einem Ereignis ein Authentifizierungstoken sendet, dadurch gekennzeichnet, dass: – die Firewall (PF) einen Authentifizierungsprotokollmodul (PA2) und einen Filtermodul (FILT) aufweist, wobei der Authentifizierungsprotokollmodul (PA2) in der Lage ist, den Filtermodul (FILT) für die Kommunikationen zwischen dem Quelle-Terminal (T_SOUR) und dem Datennetz "leitend" oder "sperrend" zu machen, je nachdem, ob das Quelle-Terminal (T_SOUR) authentifiziert wird oder nicht, – das Authentifizierungsportal (PORT) ein Anwendungsprogramm (APPLI2) enthält, das in der Lage ist, Geheimnisse an den Authentifizierungsprotokollmodul (PA2) auszugeben, wenn die Anfangsauthentifizierung des Quelle-Terminals (T_SOUR) im Datennetz erfolgreich war, – das Quelle-Terminal (T_SOUR) einen Authentifizierungsprotokollmodul (PA1) und ein Anwendungsprogramm (APPLI1) aufweist, wobei das Anwendungsprogramm (APPLI1) in der Lage ist, Geheimnisse an den Authentifizierungsprotokollmodul (PA1) auszugeben, wenn die Anfangsauthentifizierung des Quelle-Terminals (T_SOUR) im Datennetz erfolgreich war, und dass der Authentifizierungsprotokollmodul (PA1) in der Lage ist, die Authentifizierungstoken über die Schicht 2 des OSI-Modells an den Authentifizierungsprotokollmodul (PA2) zu senden.