DE602004008293T2

DE602004008293T2 - Transparente Zugangsauthentifikation in GPRS-Kern-Netzwerken

Info

Publication number: DE602004008293T2
Application number: DE602004008293T
Authority: DE
Inventors: Stephan Blicker; Matthias Britsch
Original assignee: T Mobile Deutschland GmbH
Current assignee: Telekom Deutschland GmbH
Priority date: 2003-07-31
Filing date: 2004-07-30
Publication date: 2008-05-08
Anticipated expiration: 2024-07-31
Also published as: DE602004008293D1; CA2532083C; US7770216B2; CN1830191A; EP1649661B1; PT1649661E; CN100589480C; ATE370602T1; WO2005015875A1; PL1649661T3; US20060195898A1; CA2532083A1; ES2293316T3; EP1649661A1

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System für die transparente Zugangsauthentifikation in mobilen 2G- und 2.5G-Zugangsnetzwerken. Dies schließt die Kommunikationsnetzwerke der Norm GSM, GPRS und UMTS mit ein, die Fachleuten sehr wohl bekannt sind.
Bei der Standardisierung eines universalen, mobilen Telekommunikationssystem (UMTS Rel. 5) sind umfassende Mittel vorgesehen, um die Authentifikation auf der Anwendungsschicht durchzuführen, ohne dass es erforderlich ist, mit den darunterliegenden Funk- und Transportnetzwerken untereinander zu arbeiten (interwork). Die Mechanismen basieren auf der Annahme, dass eine spezifische Umgebung für die Entwicklung von IP-Multimedia-Subsystemdienstleistungen (IMS) vorbereitet wird. Es schließt die Verwendung der IMS-SIM-Anwendung (ISIM) mit ein, die wiederum Rel. 99UICCs in den angeschlossenen Endgeräten benötigt, um die Authentifikation und die Schlüsselübereinkunft (key agreement) (AKA) zu handhaben. Bei der Entwicklung von IMS- und auf IMS basierenden Dienstleistungen in einer Netzwerkumgebung, die durch die Verwendung von SIM-Karten charakterisiert ist, wird der standardisierte Authentifikationsmechanismus nicht anwendbar sein.
In der technischen Spezifikation 3GPP TS 33.203, „Access Security for IP-based Services" (= Zugangssicherheit für auf IP basierenden Dienstleistungen), Ausgabe 5, V5.6.0, Juni 2003, XP-002264085, wird ein Verfahren für die transparente Zugangsauthentifikation von Teilnehmern offengelegt, die mit einem authentifizierenden Netzwerkbereich durch ein GPRS-Kern-Netzwerk oder ein UMTS-Netzwerk verbunden sind, wobei bei dem Verfahren Daten verwendet werden, die von einer Netzwerkschicht während der Einrichtung eines PDP-Kontextes in GPRS-Netzwerken assembliert wurden.
Es ist die Aufgabe der Erfindung, ein Verfahren und ein System für die transparente Zugangsauthentifikation bereitzustellen, die es ihr gestattet, bis zum Endgerät authentifikationstransparent zu laufen, ohne dass proprietäre Erweiterungen und Tätigkeiten seitens des Netzwerkes oder des Kunden erforderlich sind.
Das Aufgabe wird erreicht, indem ein Verfahren und ein System bereitgestellt werden, so wie dies in den unabhängigen Ansprüchen beschrieben ist.
Andere Merkmale, die für die Erfindung als charakteristisch betrachtet werden, sind in den abhängigen Ansprüchen niedergelegt.
Die vorliegende Erfindung beschreibt ein Verfahren für die Anwendungsschichtauthentifikation von Teilnehmern, die mit dem authentisierenden Netzwerkbereich durch ein 2G- oder 2.5G-General-Packet-Radio-Service-(GPRS)-Kern-Netzwerk oder ein 3G-UMTS-Netzwerk verbunden sind. Die Authentifikation wird auf Daten basieren, die durch die Netzwerkschicht während der Einrichtung eines PDP-Kontextes in GPRS-Netzwerken assembliert wurden. Diese Informationen werden durch die Standard-SIM-Kartenanwendung gesichert. Da dieselben Mechanismen für die Authentifikation in 3G-Netzwerken angewendet werden, ist der überdies beschriebene Mechanismus dort ebenfalls anwendbar. In keiner Weise wird irgendeine Norm während der Verwendung eines 2G- oder 2.5G-Netzwerkes berührt, weil bei der Norm keine Authentifikation auf der Anwendungsschicht vorgesehen ist. Für die UMTS-Rel. 5-Normen und folgende sieht die Norm bestimmte Verfahren vor. Die Anwendung des überdies beschriebenen Verfahrens würde möglich sein, obgleich der standardisierte Authentifikationsmechanismus ausgeschaltet werden muss. Das Ausschalten des standardisierten Authentifikationsmechanismusses könnte als normensensitiv ausgelegt werden, aber die nachfolgende Anwendung des überdies beschriebenen Mechanismusses wäre erneut normenwillfährig.
Weiterhin werden ein Migrationspfad zur UMTS-Rel. 5-standardisierten Authentifikation und das Konzept der parallelen Anwendung von beiden Mechanismen beschrieben.
Unter Bezugnahme auf die Zeichnungen wird die Erfindung jetzt in weiteren Einzelheiten beschrieben werden.
In 1 wird die allgemeine Konstruktion des Systems zur Durchführung der Erfindung wiedergegeben.
In 2 wird ein Ausführungsbeispiel der Erfindung mit Migration zur IMS-willfährigen Konstruktion wiedergegeben.
Unter Bezugnahme auf 1 und während der Einrichtung des PDP-Kontextes authentisiert der Serving-GPRS-Unterstützungsknoten(punkt) (SGSN) den Teilnehmer unter Verwendung des A3-/A8-Algorithmusses und basierend auf der SIM-Karte der Endgeräte bei einem GSM- und 2.5G- und EDGE-Zugangsnetzwerk.
Der Gateway-GPRS-Unterstützungsknoten 1 (GGSN) empfängt eine Anfrage zur Schaffung eines Kontextes und fragt einen Radius-(Registrierungs)-Server 2 (Remote Authentification Dial-In User Service = Fernauthentisierungseinwahl-Nutzerdienst) an, um eine IP-Adresse zu erhalten, die dem speziellen PDP-Kontext zugeordnet ist. Innerhalb des Kontextes erhält der Radius-Server 2 die MSISDN und/oder die IMSI des Teilnehmers. Somit ist in der Sessionsdatenbank 3 des Radius-Servers 2 für jeden PDP-Kontext ein Paar an IP-Adressen und IMSI/MSISDN gespeichert. Basierend auf dem Tunnelendpunkt ID (TEID) filtert der GGSN 1 alle Pakete, die durch den PDP-Kontext laufen, wenn er erst einmal eingerichtet worden ist, nach der richtigen IP-Quellenadresse (source address). Dies bedeutet, dass der GGSN 1 das Zueinanderpassen/Angleichen der TEID-/IP-Adressenpaare überprüft, um somit die Fälschung von Quellenadressen und ein so genanntes „IP spoofing" über den gesamten Lebensdauerzyklus des PDP-Kontextes zu verhindern. Der TEID identifiziert einen Tunnelendpunkt im eingehenden GTP-U-(GPRS-Tunnelprotokoll-Nutzer) oder GTP-C-Protokoll (GPRS-Tunnelprotokoll-Steuerung) eindeutig. Die empfangende Seite eines GTP-Tunnels ordnet den TEID-Wert für die zu verwendende Übermittlungsseite örtlich zu. Die TEID-Werte werden zwischen Tunnelendpunkten unter Verwendung von GTP-U-Nachrichten (oder RANAP [Radio Accress Network Application Part = Funkzugriffs-Netzwerk-Anwendungsteil]) im UTRAN (UMTS terrestrial Radio Access Network = erdgebundenes UMTS-Funkzugangsnetzwerk) ausgetauscht. Im Anwendungsbereich besteht eine Teilnehmerdatenbank 4, die alle PubIDs speichert, die der Teilnehmer in dem Bereich unter Bezugnahme auf seine PrivID, die in dem entsprechenden Anwendungsbereich einzigartig ist, verwendet. Die PrivID ist mit einer MSISDN und/oder einer IMSI korreliert.
Zu Anmeldezwecken nennt der Nutzer in der Anfrage seine PrivID. Bei Erhalt der Anmeldeanfrage fragt der Registrierungs-Proxy (registration proxy) 5 die Teilnehmerdatenbank 4 an, die die IDs des Teilnehmers (sowohl öffentlich als auch privat) zusammen mit der MSISDN/IMSI enthält. Diese Daten werden in einer Tabelle auf der Plattform der Proxy Anmeldestelle gespeichert. Anschließend fragt der Proxy Server 5 die Sessionsdatenbank 3 des Radius-Servers 2 an, um die zugeordnete IP-Adresse jener Session und die IMSI/MSISDN zu erhalten, die bereits vom Heimatstandortregister (Home Location Register [HLR]) des Netzwerkes authentisiert wurden.
Die Authentikation des HLR garantiert weiterhin, dass die IP-Adresse ebenfalls als authentisiert betrachtet werden kann. Diese Informationen werden ebenfalls in der Liste der Plattform des Proxyn Servers gespeichert.
Gemäß der Erfindung beginnt der Proxy-Server nun mit dem Authentifikationsverfahren.
Zunächst einmal prüft der Proxy-Server 5 die IMSI/MSISDN von der Radius-Server-Datenbank 3 und der Anwendungsbereichsdatenbank 4, ob sie zusammenpassen. Wenn die Paare nicht zusammenpassen, hat der Teilnehmer versucht, sich mit einer falschen PrivID zu registrieren, die mit seiner IMSI/MSISDN nicht in Wechselbeziehung steht; wenn die Paare zusammenpassen, wird der nächste Schritt durchgeführt.
Der zweite Schritt beinhaltet die Prüfung der Teilnehmer-IP-Adresse in der IP-Netzwerkschicht, d. h. im IP-Paket-Overhead-Bereich nach der Quellenadresse, ob diese mit der IP-Adresse zusammenpasst, die vom Radius-Server 3 zugeordnet wurde. Da die IP-Adresse einer IMSI-/MSISDN-authentisierten Session zugeordnet wurde, kann die IP-Adresse ebenfalls als authentisiert betrachtet werden.
Wenn die Paare nicht zusammenpassen, hat der Teilnehmer eine falsche IP-Adresse verwendet; wenn die Paare zusammenpassen, wird der nächste Schritt durchgeführt.
Der Proxy-Server 5 analysiert die Anwendungsschicht auf IP-Adressen, die beispielsweise in den Köpfen der SIP-Anmeldenachrichten, den SDP-Nachrichteninhalten usw. angegeben sind, und er prüft, ob sie mit der IP-Adresse zusammenpasst, die bereits überprüft worden ist, ob sie mit der IP-Adresse zusammenpasst, die vom Radius-Server 2 zugeordnet wurde. Wenn die Paare nicht zusammenpassen, hat der Teilnehmer eine falsche Kennzeicheninformation verwendet, z. B. Antwortadressen usw. Wenn die Paare zusammenpassen, kann der Sessionsaufbau (session setup) als authentisiert betrachtet werden.
Bei allen nachfolgend beim Proxy-Server 5 eingehenden Nachrichten prüft er nach der Quellenadresse, ob die IP-Adresse im IP-Paket-Overhead-Bereich mit jener in den Headern des Anwendungsschichtprotokolls angegebenen zusammenpasst, und er prüft die zusammenpassenden Paare gegenüber der IP-Adresse, die vom Radius-Server 2 zugeordnet wurde.
Wenn PubIDs in der folgenden Session verwendet werden, werden die PubIDs gegenüber der PrivID überprüft, die in einer Tabelle der Plattform des Proxy-Servers gespeichert war, nachdem die Anwendungsbereichsdatenbank 4 abgefragt wurde.
Die beschriebene Funktion gibt dem Netzwerkbetreiber die Möglichkeit, die Authentisierungstransparenz bis zum Endgerät auszuführen, ohne dass proprietäre Erweiterungen und Funktionen seitens des Netzwerkes oder des Kunden erforderlich sind. Bei einer SIP-basierender Kennzeichnung sind Migration zu den vollständig willfährigen UMTS-Rel. 5-Mechanismen und eine Strategie zum Parallelbetrieb erforderlich, was jetzt beschrieben wird.
Da der IMS-Bereich, so wie er für UMTS Rel. 5 standardisiert wurde, seinen eigenen Authentisierungsmechanismus enthalten wird, ist es notwendig, ein Szenarium zu unterstützen, bei dem die Teilnehmer zu ISIM-fähigen Endgeräten überwechseln. Um den Vorteil des standardisierten Authentisierungsmechanismus auszunutzen, müssen beide Mechanismen parallel zueinander unterstützt werden. Dies geschieht durch eine zusätzliche Funktion, die jede eingehende Kennzeichnungsnachricht zunächst auf das Protokoll hin überprüft; wenn es irgendein anderes Protokoll als das SIP-Protokoll ist, wird die Session an den Proxy-Server 5 geleitet.
Unter Bezugnahme auf 2 wird dieselbe Leitentscheidung getroffen, wenn die Nachricht auf SIP basiert, aber der Kunde die standardisierte UMTS-Rel. 5-Authentisierung nicht unterstützt. Wenn der Kunde das standardisierte Authentisierungsverfahren unterstützt, z. B. er ist ISIM-fähig, wird die Nachricht an die standardkonforme Proxy Call State Control Function (P-CSCF) geleitet. Der erste Trigger für Wegeleitentscheidunguen ist die Protokollart, so wie er oben beschrieben ist.
Weiterhin könnten der Schlüsselaustauschmechanismus (key exchange mechanism), der für den Aufbau der sicheren Verbindung zwischen UE und P-CSCF (wenn das Endgerät mit dem Schlüsselvergleich [key agreement] beginnt, kann es als standardkonform betrachtet werden, und die Anfrage wird an die P-CSCF geleitet) verwendet wurde oder andere Elemente, die im Kopf des UMTS Rel. 5 angegeben sind, sowie irgendein privater Nebenanschluss getriggert werden, was möglich, jedoch nicht notwendig ist. Wenn Triggerpunkte, die bei der Kennzeichnung verfügbar sind, unzureichend sind, können ebenfalls Datenbankverweise für Basisleitentscheidungen verwendet werden.
Das Authentisierungsverfahren sieht wie folgt aus:
Zunächst einmal wird eine Entscheidung benötigt, durch welchen Knoten(punkt) P-CSCF 6 oder der Proxy-Server 5 das Register geroutet werden soll.
Hierfür wird ein Routingmodul 7 bereitgestellt, das der Standardeingangspunkt für alle Nachrichten sein wird. Durch Analyse der PrivID wird das Routingmodul 7 entscheiden, welcher Knoten(punkt) die Nachricht verarbeiten wird. Innerhalb des Bereichsteils des Netzwerkzugangsidentifizierers (NAI) – siehe 3GPP-Spezifikation 23.228 – bezieht sich das Routingmodul 7 auf Unterbereiche (z. B. user@gprs.tmo.de und user@tmc.umts.de). Dies macht es erforderlich, dass Netzwerkzugangsidentifizierer Unterbereiche für 3G-Teilnehmer bereitstellen müssen.
Das Routingmodul 7 wird durch alleinige Verwendung des PrivID einen Leiteingang festlegen, und die nachfolgenden Nachrichten werden durch die IP-Quellenadresse, die in der Leittabelle aufgeführt ist, identifiziert werden. Das Routingmodul 7 identifiziert die verantwortliche Proxy-Funktion, d. h. den Proxy-Server 5 oder die P-CSCF 6, durch die Analyse des PrivID (URIs-Unterbereiche). Dieser stellt die Anfrage an IMSI/MSISDN und URIs, die nach dieser Funktion auszuwählen sind.
In dem Fall, dass abgesehen vom SIP andere Protokolle, so wie beispielsweise SAMTP, HTTP, SOAP (NET) usw., angewendet werden sollen, muss der Proxy-Server 5 erweitert werden und die Teilnehmer durch Verwendung der IP-Adresse authentisieren, danach die IMSI/MSISDN auflösen/zerlegen und den entsprechenden Identifizierer des Protokolls angleichen, der im Teilnehmerprofil der Teilnehmerdatenbank 4 gespeichert ist. Dies verlangt nach der Besetzung des Teilnehmerprofils mit den erforderlichen Datenelementen und der Erweiterung des Routingmoduls, um protokollabhängiges Leiten zu ermöglichen.
In dem Fall, dass separate Zugangsnetzwerke verwendet werden, muss die Anwendungsplattform wissen, welche Art von Zugangsnetzwerk verwendet wird, um die Bereitstellung der Dienstleistung entsprechend anzupassen. Dies verlangt danach, dass gegenüber dem SGSN eine Änderungsanfrage erfolgen muss, um es dem SGSN zu ermöglichen, den Zugangstyp dem SGGN mitzuteilen, das ihn in die Radius-Anfrage einbeschließt, und somit wird der Zugangsnetzwerktyp in der Sessionsdatenbank 3 verfügbar sein. Dies ermöglicht allen Anwendungen, den Zugangsnetzwerktyp anzufragen und zu verwenden, z. B. hinsichtlich der Qualität der Dienstleistungsmittel (QoS).
Abkürzungen

2.5.G

Generation 2,5 (z. B. GPRS, EDGE)

2G

zweite Generation (z. B. GSM)

3G

dritte Generation (z. B. UMTS)

AKA

Authentisierungs- und Schlüsselübereinkunft (Authentication and key arrangement)

CC

leitungsvermittelt (circuit switched)

IMS

IP-Multimedia-Subsystem

IMSI

internationale Identität des mobilen Teilnehmers (International Mobile Subscriber Identity)

ISIM

IMS-SIM

MSISDN

ISDN-Nummer der mobilen Station (Mobile Station ISDN number)

NAI

Netzwerkzugangsidentifizierer (network access identifier(

P-CSCF

Proxy-Call-State-Control-Function

SIM (card)

(GSM) Teilnehmer-Identitätsmodul(-karte)

SIP

Sessionsinitiierungsprotokoll (session initiation protocol)

TEID

Tunnelendpunkt-ID (Tunnel Endpoint ID)

UE

Nutzerendgerät (User Equipment)

UICC

UMTS-IC-Karte

UMTS

universales, mobiles Telekommunikationssystem

URI

einheitlicher Resourcenanzeiger (uniform ressource locator)

Claims

Ein Verfahren für die transparente Zugriffsberechtigung von Teilnehmern, die durch ein GPRS-Kernnetzwerk oder ein UMTS-Netzwerk mit einem Berechtigungsnetzwerkbereich verbunden sind, wobei bei dem Verfahren Daten verwendet werden, die während der Erstellung eines PDP-Kontextes in GPRS-Netzwerken durch eine Netzwerkschicht assembliert werden, wobei – wenn ein Netzkoppler-GPRS-Stützknoten (1) eine Kontexterzeugungsanfrage erhält – er einen Registrierungs-Server (2) abfragt, um eine IP-Adresse zu erhalten, die dem besonderen PDP-Kontext zugeordnet ist, und innerhalb des Kontextes erhält der Registrierungs-Server (2) eine ISDN-Nummer einer mobilen Station -MSISDN- und/oder eine internationale mobile Teilnehmeridentität – IMSI – des Teilnehmers und speichert für jeden PDP-Kontext ein Paar einer IP-Adresse und einer IMSI/MSISDN in einer Sessionsdatenbank (3), und dass ein Ersatz-Server (proxy server) (5) vorgesehen ist, der die IMSI/MSISDN von einem Registrierungs-Server (2), einer Sessionsdatenbank (3) und die IMSI/MSISDN von einer Anwendungsbereichsdatenbank (4) zwecks Übereinstimmung überprüft, und dass – wenn die IMSI-/MSISDN-Paare übereinstimmen – der Ersatz-Server (proxy server) (5) die IP-Adresse eines Teilnehmers, die in der IP-Netzwerkschicht zugeordnet wurde, zwecks Übereinstimmung mit der IP-Adresse, die vom Registrierungs-Server (2) zugeordnet wurde, überprüft, und dass der Ersatz-Server (proxy server) (5) die Anwendungsschicht für IP-Adressen analysiert, die in den Kopfsätzen der Registrierungsnachrichten angegeben sind und sie zwecks Übereinstimmung mit der IP-Adresse der Netzwerkschicht überprüft, die bereits zwecks Übereinstimmung mit der IP-Adresse, die vom Registrierungs-Server (2) zugeordnet wurde, überprüft worden war.
Ein Verfahren gemäß Anspruch 1, das den Schritt beinhaltet, dass ein Serving-GPRS-Stützknoten (SCSN) den Teilnehmer während der Erstellung des PDP- Kontextes unter Verwendung des A3-/A8-Algorithmusses auf der Grundlage einer Endgerät-SIM-Karte authentisiert.
Ein Verfahren gemäß irgendeinem der vorangehenden Ansprüche, das den Schritt beinhaltet, dass es bei allen Folgenachrichten, die beim Ersatz-Server (proxy server) (5) eingehen, die Übereinstimmung der IP-Adresse im IP-Paket-Overhead-Speicherfeld für eine Ursprungsadresse mit der in den Anwendungsschichtprotokoll-Kopfsatzspeicherfeldern enthaltenen überprüft und die übereinstimmenden Paare gegenüber der IP-Adresse, die durch den Registrierungs-Server (2) zugeordnet wurde, verifiziert.
Ein Verfahren gemäß irgendeinem der vorangehenden Ansprüche, dass ein Leitwegmodul (7) vorgesehen ist, das eine Standardeingangsstelle für alle Nachrichten ist und durch Auswertung der Private ID – PrivID – entscheidet, welcher Netzwerkknoten die Nachricht verarbeiten wird.
Ein System von Geräten in einem mobilen Telekommunikationsnetzwerk, dadurch gekennzeichnet, dass mindestens ein erstes Authentisierungsgerät (2) über eine Datenleitung mit einem zweiten Gerät (5; 6) verbunden ist, das in Übereinstimmung mit dem in Anspruch 1 genannten Verfahren Daten assembliert.
Ein System gemäß Anspruch 5, wobei das erste (1) Gerät einen Registrierungs-Server (2) beinhaltet.
Ein System gemäß Anspruch 5 oder 6, wobei das erste (1) Gerät (2) mit einer Sessionsdatenbank (3) verbunden ist.
Ein System gemäß irgendeinem der Ansprüche 5 bis 7, wobei das zweite Gerät einen Ersatz-Server (proxy server) (5) beinhaltet.
Ein System gemäß irgendeinem der Ansprüche 5 bis 8, wobei das zweite Gerät eine Annäherungsanrufstatussteuerungsfunktion (proxy call state control function) (6) beinhaltet.
Ein System gemäß irgendeinem der Ansprüche 5 bis 9, wobei das zweite Gerät (5; 6) mit einer Teilnehmerdatenbank (4) verbunden ist.
Ein System gemäß irgendeinem der Ansprüche 5 bis 10, wobei ein Leitwegmodul (7) vorgesehen ist, das durch Auswertung der Private ID – PrivID – entscheidet, welches Netzwerk die Nachricht verarbeiten wird.