DE10238928A1

DE10238928A1 - Verfahren zur Authentifizierung eines Nutzers eines Kommunikationsendgerätes bei Nutzung eines Dienstnetzes

Info

Publication number: DE10238928A1
Application number: DE10238928A
Authority: DE
Inventors: Stefan Dipl.-Ing. Matt
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2002-08-22
Filing date: 2002-08-22
Publication date: 2004-03-11
Anticipated expiration: 2022-08-23
Also published as: DE10238928B4

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zur Authentifizierung eines Nutzers eines Kommunikationsendgerätes bei Nutzung eines einen Dienst organisierenden Dienste-Servers in einem zweiten Dienstnetz, bei dem DOLLAR A - dem Nutzer bei einer Anmeldung bei einem Betreiber eines ersten Dienstnetzes und/oder bei Registrierung in dem ersten Dienstnetz ein Kennzeichen (Token) und eine öffentliche Kennung zugeordnet wird, DOLLAR A - das dem Nutzer zugeordnete Kennzeichen und die ihm zugeordnete öffentliche Kennung an den Dienste-Server in dem zweiten Dienstnetz übertragen wird, DOLLAR A - von dem Kommunikationsendgerät eine erste Zufallszahl und die öffentliche Kennung mit einer Authentifizierungs-Aufforderungsnachricht an den Dienste-Server in dem zweiten Dienstnetz gesendet wird, DOLLAR A - in dem Dienste-Server in dem zweiten Dienstnetz aus der ersten Zufallszahl und dem dem Dienste-Server in dem zweiten Dienstnetz für den Nutzer des Kommunikationsendgerätes zugesendeten Kennzeichen gemäß eines ersten funktionalen Zusammenhangs (f1) ein erster Wert berechnet wird und zusammen mit einer zweiten Zufallszahl an das Kommunikationsendgerät gesendet wird, DOLLAR A - in dem Kommunikationsendgerät aus der ersten Zufallszahl und dem dem Nutzer des Kommunikationsendgerät zugeordneten Kennzeichens gemäß des ersten funktionalen Zusammenhangs (f1) ein zweiter Wert berechnet wird und dieser mit dem ersten Wert verglichen wird, DOLLAR A - bei Übereinstimmung des ersten und des zweiten Wertes die Authentizität des ...

Description

Bei Mobilfunknetzen der zweiten und dritten Generation, wie beispielsweise bei UMTS-Netzen, werden Mobilfunknutzern Dienste angeboten, die von für eine Diensterbrinung optimierten Spezialnetzen erbracht werden. In einer 3GPP Standardisierung wurde mit Release 5 ein derartiges Dienstnetz, ein sogenanntes IMS (IP Multimedia System) definiert. Die Dienstnutzer werden dabei über ein Zugangsnetz, wie beispielsweise ein nach dem GPRS-Standard arbeitendes Kommunikationsnetz, mit dem Dienstnetz verbunden. Es ist in der Regel für Netzbetreiber von Interesse, vor einer Diensterbringung die Identität der Dienstnutzer festzustellen und bei erfolgreicher Authentifizierung diese Nutzer zu registrieren.

In der deutschen Patentanmeldung 10223248.2 wird ein Authentifizierungsverfahren zur sicheren Authentifizierung eines Teilnehmers eines Dienstnetzes der oben genannten Art beschrieben.

Ausgehend von dieser Erfindung ist es eine Aufgabe der vorliegenden Erfindung ein einfaches und schnelles Verfahren zur Authentifizierung eines Nutzers bereitzustellen, der Dienste außerhalb eines Dienstnetzes der oben genannten Art nutzt. Darunter versteht man beispielsweise Dienste, die keine IMS-Applikationsdienste innerhalb einer IMS-Verbindung zur Verfügung stellen. Eine IMS-Verbindung ist durch einen IMS Call-Aufbau, eine Durchführung von IMS-Applikationsdiensten und einen IMS Call-Abbau gekennzeichnet. Man bezeichnet dies dann auch als IMS-Session. Solche Dienste-Server, die keine IMS-Applikationsdienste innerhalb einer IMS-Verbindung zur Verfügung stellen, können sich dabei in einem IMS Dienstnetz befinden oder außerhalb in einem anderen Dienstnetz.

Gelöst wird diese Aufgabe durch ein erfindungsgemäßes Verfahren gemäß dem unabhängigen Anspruch 1. Weitere Vorteile des erfindungsgemäßen Verfahrens werden in den Unteransprüchen aufgeführt.

Gemäß Anspruch 1 der vorliegenden Erfindung wird ein Verfahren zur Authentifizierung eines Nutzers eines Kommunikationsendgerätes bei Nutzung eines einen Dienst organisierenden Dienste-Servers in einem zweiten Dienstnetz bereit gestellt, bei dem

– dem Nutzer bei einer Anmeldung bei einem Betreiber eines ersten Dienstnetzes und/oder bei Registrierung in einem ersten Dienstnetz ein Kennzeichen (Token) und eine öffentliche Kennung zugeordnet wird,
– das dem Nutzer zugeordnete Kennzeichen und die ihm zugeordnete öffentliche Kennung an den Dienste-Server in dem zweiten Dienstnetz übertragen wird,
– von dem Kommunikationsendgerät eine erste Zufallszahl und die öffentliche Kennung mit einer Authentifizierungs-Aufforderungsnachricht sicher an den Dienste-Server in dem zweiten Dienstnetz gesendet wird,
– in dem Dienste-Server aus der ersten Zufallszahl und dem dem Dienste-Server für den Nutzer des Kommunikationsendgerätes zugesendeten Kennzeichen gemäß eines ersten funktionalen Zusammenhangs (f 1) ein erster Wert berechnet wird und zusammen mit einer zweiten Zufallszahl an das Kommunikationsendgerät gesendet wird,
– in dem Kommunikationsendgerät aus der ersten Zufallszahl und dem dem Nutzer des Kommunikationsendgerät zugeordneten Kennzeichens gemäß des ersten funktionalen Zusammenhangs (f1) ein zweiter Wert berechnet wird und dieser mit dem ersten Wert verglichen wird,
– bei Übereinstimmung des ersten und des zweiten Wertes die Authentizität des Dienste-Servers erkannt wird.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens berechnet das Kommunikationsendgerät aus der zweiten Zufallszahl und dem dem Nutzer des Kommunikationsendgerätes zugeordneten Kennzeichen gemäß eines zweiten funktionalen Zusammenhangs (f2) einen dritten Wert und sendet diesen zusammen mit einer Anforderungsnachricht an den Dienste-Server in dem zweiten Dienstnetz. In dem Dienste-Server wird aus der zweiten Zufallszahl und dem dem Dienste-Server für den Nutzer des Kommunikationsendgerätes zugesendeten Kennzeichen gemäß des zweiten funktionalen Zusammenhangs ein vierter Wert berechnet und dieser wird mit dem dritten Wert verglichen. Bei Übereinstimmung des dritten und des vierten Wertes wird sodann die Authentizität des Nutzers des Kommunikationsendgerätes erkannt.

Mittels des erfindungsgemäßen Verfahrens kann ein Teilnehmer eines ersten Dienstnetzes, in welchem der Teilnehmer sich mittels des in der deutschen Anmeldung DE 10223248.2 beschriebenen Authentifizierungsverfahrens registrieren lassen kann, sich nun auch ohne weitere zusätzlich nötige Parameter, wie beispielsweise einem Passwort, bei einem Dienste-Server in einem zweiten Dienstnetz authentifizieren und von diesem angebotene Dienste nutzen. Das erfindungsgemäße Verfahren ge währleistet eine gegenseitige sichere Authentifikation des Nutzers und des entsprechenden Dienste-Servers.

Bei dem zweiten Dienstnetz kann es sich dabei beispielsweise um eine von dem ersten Dienstnetz vollkommen unabhängige Infrastruktur handeln, in welchem der Dienste-Server steht. Bei dem Dienste-Server kann es sich dabei beispielsweise um einen Server eines externen Anbieters (3^rd-party) oder um ein externes Terminal handeln.

In einer anderen bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens sind das erste und das zweite Dienstnetz identisch. Das bedeutet, dass der Dienste-Server zwar in dem ersten Dienstnetz, wie beispielsweise einem IMS-Dienstnetz steht, dort aber nicht innerhalb einer sogenannten IMS-Verbindung als IMS-Applikationsserver beteiligt ist.

In einer anderen besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird als erstes Dienstnetz ein Dienstnetz verwendet, das in der 3GPP Standardisierung Release 5 definiert ist, nämlich das sogenannte IMS (IP Multimedia System). Mittels des erfindungsgemäßen Verfahrens ist es einem IMS-Nutzer nun möglich neben subskribierten IMS-Diensten, für die der Nutzer sich über das in der DE 10223248.2 beschriebene Verfahren authentifiziert, andere Dienste, wie beispielsweise Terminal-Software Updates, d.h. Aktualisierungen von Endgeräte-Software oder eine Selbstadministration einiger IMS-Dienste, wie beispielsweise Buddy-List-Selfadministration über eine unabhängige Infrastruktur, d.h. nicht über IMS, oder unabhängig von sogenannten IMS-Sessions sicher vornehmen zu können, ohne zusätzliche Authentifizierungsparameter verwenden zu müssen.

Erfindungsgemäß wird eine gegenseitige sichere Authentifikation des Nutzers und des entsprechenden Dienste-Servers in dem zweiten Dienstnetz gewährleistet, um darüber hinaus einen sicheren Datenaustausch, beispielsweise für Aktualisierungen von Endgeräte-Software oder Modifikationen von Nutzer spezifischen Daten zu ermöglichen.

Erfindungsgemäß ist das Verfahren nicht auf eine spezifische Luftschnittstelle, wie beispielsweise GERAN/UTRAN, zwischen dem Nutzer und dem zweitem Dienstnetz, in welchem der Dienste-Server steht, beschränkt. Erfindungsgemäß ist es möglich, dass sich beispielsweise ein IMS-Administrations- und/oder ein 3^rd-Party Server in einem eigenen Sicherheitsbereich außerhalb des IMS-Netzes befindet. Verfügt beispielsweise der IMS-Administrations- und/oder der 3^rd-Party Server über einen öffentlichen Internet-Zugang, wie beispielsweise über PSTN/RAS (Remote Access Server) so ist mittels des erfindungsgemäßen Verfahrens trotzdem ein sicherer Zugang zu dem jeweiligen Server und ein sicherer Datenaustausch zwischen dem jeweiligen Server und dem Nutzer möglich. Voraussetzung dabei ist lediglich, dass das Kommunikationsendgerät des Nutzers über entsprechende Zugangs-Technologien verfügt.

Ein großer Vorteil der vorliegenden Erfindung ist darin zu sehen, dass für den Zugang zu einem IMS-Administrationsund/oder 3^rd-Party Server neben den durch eine IMS-Registrierung erhältliche IMS Sicherheitsparameter für den Nutzer keine weiteren festgelegten Parameter nötig sind. Das bedeutet, dass von dem Nutzer keine zusätzlichen Vorgehensschritte, wie beispielsweise eine Passwort-Eingabe gefordert werden.

Darüber hinaus ist die Identität, die der Nutzer für die Authentifizierung nutzen kann eindeutig.

Ferner ist das erfindungsgemäße Verfahren sehr einfach ausführbar und sehr effizient, da bereits parallel bestehende Mechanismen ausgenutzt werden.

Vorzugsweise wird das Kennzeichen (Token) zu dem Dienste-Server in dem zweiten Dienstnetz, wie beispielsweise zu einem Administrationsnetz und/oder einem 3^rd-Party Server über einen gesicherten Kanal übertragen. Hierbei können gängige Sicherheitsprotokolle, wie sie beispielsweise in IETF (IPsec, TLS) definiert sind, verwendet werden. Dies kann beispielsweise während einer Registrierung des Nutzers in dem ersten Dienstnetz, wie beispielsweise in einem IMS-Netz vonstatten gehen, wobei dabei das Kennzeichen von dem ersten Dienstnetz zu dem Dienste-Server in dem zweiten Dienstnetz gesendet wird. Ferner ist es aber auch denkbar, dass der Nutzer bzw. sein Kommunikationsendgerät noch kein Kennzeichen zugeordnet bekam, da er noch nicht in dem ersten Dienstnetz registriert ist. Somit kann der Nutzer des Kommunikationsendgerätes ein Kennzeichen nicht über eine erfolgreiche Registrierung in dem ersten Dienstnetz, wie beispielsweise über eine IMS-Registrierung erhalten. Um dennoch Dienste des Dienste-Servers in dem zweiten Dienstnetz sicher in Anspruch nehmen zu können, wie beispielsweise die Durchführung eines Herunterladens von Software aus dem zweiten Dienstnetz, kann dem Nutzer über einen unabhängigen sicheren Kanal ein Kennzeichen, eine Nutzer-Identität (User-ID) und eine entsprechende zur Durchführung des erfindungsgemäßen Verfahrens nötige Software übermittelt werden. Dies kann beispielsweise beim Kauf des Kommunikationsendgerätes und/oder bei der Anmeldung des Nutzers bei dem Betreiber (Operator) des ersten Dienst nettes, wie beispielsweise beim IMS-Betreiber vonstatten gehen. Der den gewünschten Dienst zur Verfügung stellende Dienste-Server, für welchen der Nutzer subskribiert ist, bezieht die nötigen Daten über eine sichere Verbindung von einer entsprechenden Vermittlungsstelle (S-CSCF) des ersten Dienstnetzes. Befindet sich der Dienste-Server beispielsweise in dem IMS-Dienstnetz, so kann die Datenübertragung über ein ISC-Interface erfolgen.

Durch die erfindungsgemäße Vorgehensweise, das Kennzeichen zwischen dem Nutzer und dem Dienste-Server nur in verschlüsselter Form (preshared-key), nämlich als berechneter Wert, der sich aus einem funktionalen Zusammenhang zwischen einer Zufallszahl und dem Kennzeichen ergibt, zu verschicken, kann vermieden werden, dass Antworten auf Authentifizierungs-Anforderungen (Authentifizierungs-Requests) im Klartext übertragen werden. Dadurch ist keine Zugangsnetz-Sicherheit erforderlich, was eine Unabhängigkeit des Zuganges garantiert.

Weitere Vorteile des erfindungsgemäßen Verfahrens werden anhand der folgenden Figuren näher erläutert. Es zeigen
1 ein Ausführungsbeispiel einer Anordnung zur Ausführung des erfindungsgemäßen Verfahrens und
2 eine schematische Darstellung eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens.
In 1 ist ein Radio-Zugangsnetz, wie beispielsweise ein nach „General Packet Radio Service"-Vorgaben arbeitendes Mobilfunknetz GPRS dargestellt, über welches ein Kommunikationsendgerät UE einen Zugang zu einem Dienstnetz, wie es beispielweise in dem 3GPP Standard definiert ist, d.h. einem IMS-Netz, erhält. Bei dem Kommunikationsendgerät UE kann es sich z.B. um Mobiltelefone, Laptops oder Palmtops mit Mobilfunkmodul handeln. Von dem Dienstnetz IMS ist schematisch lediglich eine Vermittlungsstelle S-CSCF (CSCF = Call Session Control Function; S-CSCF = Serving-CSCF), welche mit einem Applikations-Server und einem Heimatregister HSS verbunden ist, dargestellt. Über die Datenverbindung 1 werden Informationen zur Nutzerauthentifizierung zwischen dem Radio-Zugangsnetz und dem IMS-Netz ausgetauscht. Über diese Datenverbindung wird die Registrierung des Kommunikationsendgerätes UE in dem IMS-Netz vorgenommen. Ferner wird dabei auch ein dem Kommunikationsnetz zugeordnetes Kennzeichen (Token) übertragen. Der Ablauf der Registrierung wird in der DE 10223248.2 beschrieben.
Mittels des Kommunikationsendgeräts UE können nun über ein beliebiges Zugangsnetz Dienste außerhalb des IMS-Dienstnetzes von einem externen Dienste-Server in einem zweiten Dienstnetz, wie z.B. einem Nutzer-Administrations- und/oder 3^rd-Party-Server angefordert werden. Zuvor ist jedoch eine Authentifizierung des Kommunikationsendgeräts UE in dem zweiten Dienstnetz vorzunehmen.
Wenn also ein Nutzer eines Kommunikationsendgerätes Dienste eines Dienste-Servers in einem zweiten Dienstnetz außerhalb des IMS-Netzes nutzen möchte, so wird in dem vorliegenden Beispiel dessen Kommunikationsendgerät UE zunächst in das Radio-Zugangsnetz eingebucht (das Zugangsnetz ist heute oftmals durch ein sog. „Release 1999"-GPRS-Netzwerk realisiert). Beim Einbuchen in das GPRS-Netz wird eine an sich bekannte GPRS-Nutzer-Authentifizierung durchgeführt, diese nutzt die im Kommunikationsendgerät vorhandene SIM-Karte. Zusätzlich dazu muss sich das Kommunikationsendgerät beim Dienstnetz IMS re gistrieren und dabei authentifizieren. Beide Prozeduren, die Anmeldung im Zugangsnetz GPRS und die Anmeldung (Registrierung) im Dienstnetz IMS, werden z.B. automatisch beim Einschalten des Kommunikationsendgerätes durchgeführt. Einen wesentlichen Teil des Registrierens bei dem Dienstnetz stellt das Authentifizieren durch das Dienstnetz dar. Dabei wird während des Registrierens des Kommunikationsendgerätes bei dem Dienstnetz ein Nutzer des Kommunikationsendgerätes authentifiziert. Genau betrachtet wird dabei die SIM-Karte des Nutzers, welche in das Kommunikationsendgerät eingelegt ist, erkannt und dadurch auf die Person des Nutzers geschlossen.
Gemäß dem in der DE 10223248.2 beschriebenen Verfahrens wird dem Nutzer bei der Registrierung im IMS-Dienstnetz ein Kennzeichen (Token) zugeordnet. Dieses Kennzeichen (Token) wird dann über eine Datenverbindung 2 von dem IMS-Dienstnetz zu dem Dienste-Server, nämlich beispielsweise einem Nutzer-Administrations- und/oder 3^rd-Party-Server zusammen mit einer öffentlichen Kennung des Nutzers übertragen.
Mittels dieser dann im Dienste-Server vorliegenden Parameter wird der Nutzer über eine Datenverbindung 3 bei dem Dienste-Server authentifiziert. Auch wird darüber ein sicherer Datenaustausch vorgenommen. Dank des erfindungsgemäßen Verfahrens besteht keine Notwendigkeit für den Nutzer spezielle kryptographische Parameter wie PIN, Passwörter, TAN-Nummern für unterschiedliche Nutzer-Administrations- und/oder 3^rd-Party-Server zur Verfügung zu stellen. Für einen Operator des IMS-Dienstnetzes ergibt sich daraus die Möglichkeit, Authentifiaktionsdienste für 3^rd-Parties seinen Nutzern bzw. Kunden anzubieten.
Abhängig von Daten, die es zu übermitteln gilt, können unterschiedliche Sicherheitsstufen angewendet werden, beispielsweise eine einseitige Authentifikation, d.h. nur eine Server- oder Nutzer-Authentifizierung oder eine gegenseitige Authentifizierung, Integritätsschutz beim Herunterladen von Software und/oder Integritätsschutz und Vertraulichkeit (Confidentiality) bei einer Aktualisierung eines Adressbuches, d.h. von sogenannten Listen-Updates, wie beispielsweise einer sogenannten Buddy-List.
Ferner wird es durch das vorliegende erfindungsgemäße Verfahren möglich, eine schnelle Erweiterung und Einbringung eines Authentifizierungs-Verfahrens auf neue Nutzer-Administrations- und/oder 3^rd-Party-Server. Keine speziellen Parameter müssen seitens der bestehenden IMS Infrastruktur zusätzlich generiert werden.
In 2 ist dargestellt, wie eine gegenseitige Authentifizierung (Server und Nutzer) bei einem Dienste-Server in einem zweiten Dienstnetz bei vorheriger Registrierung in einem IMS-Dienstnetz erfolgt. Das Ausführungsbeispiel beginnt mit der Einbuchung (Schritt 1) eines Kommunikationsendgerätes UE in ein Zugangsnetz, in diesem Beispiel in ein GPRS Zugangsnetz. Dabei wird eine GPRS-Nutzer-Authentifizierung ausgeführt. Ist diese erfolgreich, wird ein sog. „PDP Context" erzeugt und von einer Gateway-GPRS-Vermittlungsstelle GGSN (GGSN = Gateway GPRS Support Node) eine temporäre IP-Adresse IP-SRC-UE an das Kommunikationsendgerät UE vergeben. Diese IP-Adresse erlaubt es anderen Netzteilnehmern, IP-Pakete an das Kommunikationsendgerät zu schicken.
Nach erfolgreicher Aktivierung eines PDP-Kontextes als Voraussetzung für den Zugang zu IMS Diensten, muss der Nutzer in dem IMS-Dienstnetz registriert werden. Dies verläuft nach dem in der DE 10223248.2 beschriebenen Verfahren. Während des Authentifizierungs-Vorgangs wird dem Nutzer ein Kennzeichen zugeordnet und ihm übermittelt. Dies erfolgt bei einer RE-Registrierung in einer 200 OK Response. Die Registrierung wird fortgesetzt und der Nutzer erfolgreich authentifiziert. Dies wird dem Nutzer in einer sogenannten 200 OK Nachricht bestätigt.
In dem folgenden Schritt (Schritt 6) übermittelt die Vermittlungsstelle S-CSCF das Kennzeichen (Token) sowie eine öffentliche Kennung (User-ID) an den Administrations- und/oder 3^rd-Party-Server, wofür der Nutzer eine Autorisierung besitzt. Dieses Kennzeichen kann als gemeinsames Geheimnis verwendet werden und ermöglicht dem Dienste-Server, den entsprechenden Nutzer zu authentifizieren bzw. dem Nutzer, den Server zu authentifizieren. Dieses Kennzeichen kann auch als Basis für weitere Schlüssel und Algorithmen, die davon abgeleitet werden, dienen. Das bedeutet, dass die Authentifizierung bei dem Dienste-Server Nutzer-spezifisch realisiert wird. Es muss dabei gewährleistet sein, dass die Datenverbindung zwischen dem IMS-Dienstnetz und dem Dienste-Server, d.h. hier die Datenverbindung zwischen der Vermittlungsstelle S-CSCF des IMS-Dienstnetzes und dem Server gesichert ist. Hierzu können gängige Sicherheits-Protokolle verwendet werden, wie sie beispielsweise die IETF (Internet Engineering Task Force) definiert hat, wie beispielsweise IPsec (IP Security) oder TLS (Transport Layer Security).
Nach der erfolgreichen Registrierung des Nutzers in dem IMS-Dienstnetzes können beispielsweise IMS-Sessions durchgeführt werden und anschließend wieder abgebaut werden (Schritte 7). Letztlich kann sich der Nutzer wieder de-registrieren und den PDP-Kontext abbauen (Schritte 8 und 9).
Der in den Schritten 1 bis 9 beschriebene Vorgang beschreibt eine PDP-Kontext-Aktivierung und anschließende IMS Registrierung sowie einen IMS-Session-Auf- und Abbau sowie eine PDP-Kontext-Deaktivierung. Die sich nun anschließende Authentifikation von einem Administrations- und/oder 3^rd-Party-Server ist ein unabhängiger Prozess. Das bedeutet, dass das Kennzeichen (Token), dass bei jeder Registrierung bzw. Re-Registrierung neu generiert wird, häufiger übertragen wird. Das ist notwendig, damit das Kennzeichen (Token) im Kommunikationsendgerät UE sowie auf den Administrations- und/oder 3^rd-Party-Servern konsistent ist. Um ein zu häufiges Übertragen des Kennzeichens, wie in Schritt 6 beschrieben, zu vermeiden, ist es ebenfalls möglich, das Kennzeichen (Token) erst mit einer IMS-De-Registrierung an die Administrationsund/oder 3^rd-Party-Server zu schicken. In diesem Fall wäre aber eine parallele IMS-Registrierung und Nutzer-Authentifizierung bei einem Administrations- und/oder 3^rd-Party-Server nicht möglich. Erfindungsgemäß ist es daher konfigurierbar, wann das Kennzeichen (Token) übertragen wird, d.h. bei (Re)-Registrierung bzw. bei IMS-Deregistrierung.
Im vorliegenden Beispiel wird davon ausgegangen, dass der Nutzer sich mit seinem Kommunikationsendgerät UE über das PSTN (Public Switched Telephone Network) an einem RAS (Remote Access Server) einwählt, um eine Internet-Verbindung zu erhalten. Dies setzt voraus, dass das UE hierzu in der Lage ist, neben einem GPRS Zugang, wie er für IMS Dienste notwendig ist, weitere Zugangsmöglichkeiten zu unterstützen. Darüber hinaus muss gewährleistet sein, das der Administrations- und/oder 3^rd-Party-Server über das öffentliche Internet erreichbar ist. Es ist aber ebenfalls denkbar, dass der Administrations- und/oder 3^rd-Party-Server beispielsweise nur über einen GPRS-Zugang erreichbar ist. Dies ist möglich, da erfindungsgemäß keine speziellen Sicherheits-Anforderungen an den Server bestehen, die vom Zugangsnetz abhängig sind.
In Schritt 11 wird in dem Kommunikationsendgerät UE eine Zufallszahl RAND1 generiert. Diese wird benötigt, um das zuvor ausgetauschte Kennzeichen (Token) nicht im Klartext übertragen zu müssen, da aufgrund der Zugangsnetz-Unabhängigkeit erfindungsgemäß keine Sicherheits-Anforderungen an das Zugangsnetz gestellt werden. In 12 wird eine http-Verbindung zu dem Administrations- und/oder 3^rd-Party-Server etabliert. Das Kommunikationsendgerät UE generiert eine http-Anforderungsnachricht http-REQ an den Administrations- und/oder 3^rd-Party-Server, wobei die Zufallszahl RAND1, eine Nutzer-Kennung sowie eine Auth-Req-Flag (Authentication-Request-Flag) übermittelt wird. Das Auth Req-Flag wird benötigt, um diesen http-Request als Authentifikationsanfrage zu identifizieren (Message-Type). Die Nutzer-Kennung wird benötigt, damit der Administrations- und/oder 3^rd-Party-Server das korrespondierende Kennzeichen (Token) für die weitere Authentifikation zugrunde legen kann. Diese Nachricht entspricht einer Aufforderungsnachricht (Challenge-Nachricht) zur Authentifizierung des Servers. Nach Erhalt der Aufforderung kann der Administrations- und/oder 3^rd-Party-Server bereits eine Zufallszahl RAND2 generieren, die er für die Nutzer-Authentifizierung verwendet. In einer Antwort-Nachricht (Response) erhält das Kommunikationsendgerät UE nun einen Wert fl(Kennzeichen, RAND1), der sich über einen eindeutigen funktionalen Zusammenhang f1 aus dem Kennzeichen (Token) sowie der Zufallszahl RAND1 ergibt. Wie bereits erwähnt kann somit verhindert werden, dass das Kennzeichen (Token) im Klartext übertragen werden muss. Ein derartiger funktionaler Zusammenhang f1 kann beispielsweise durch MD5 (IETF RFC2403) oder SHA-1 (IETF RFC2404) realisiert werden. Darüber hinaus wird die Zufallszahl RAND2 übertragen, um die Nutzer-Authentifizierung zu initiieren (Challenge für User-Authentication). Das Kommunikationsendgerät UE berechnet über den funktionalen Zusammenhang f1 aus RAND1 und dem ihm von dem IMS zugeordneten Kennzeichen Kennzeichen* einen zweiten Wert fl(Kennzeichen*, RAND1) und vergleicht diesen mit dem ersten zu ihm übertragenen Wert f1(Kennzeichen, RAND1). Bei Übereinstimmung ist erkannt, dass das an den Administrationsund/oder 3^rd-Party-Server übertragene Kennzeichen gleich ist dem dem Kommunikationsendgerät UE zugeordneten Kennzeichen. Somit ist der Administrations- und/oder 3^rd-Party-Server authentifiziert, da nur er diesen Wert berechnen kann, denn nur er kennt das Kennzeichen. Für Confidentiality und/oder Integritätsschutz späterer Nutzdaten kann bei Bedarf das Kommunikationsendgerät UE hieraus einen weiteren Schlüssel generieren, der sich folgendermaßen zusammensetzen kann:
Schlüssel=f (Kennzeichen, RAND1, RAND2)
Hierfür kann beispielsweise der MD5 Algorithmus angewendet werden.
Das Kommunikationsendgerät UE übermittelt nun seinerseits das verschlüsselte Kennzeichen (Token) als funktionaler Zusammenhang von Kennzeichen und der Zufallszahl RAND2 an den Administrations- und/oder 3^rd-Party-Server zusammen mit der Nut zer-Kennung und einem request flag, um diesen http-Request von dem im 12. Schritt beschriebenen unterscheidbar zu machen.
Der Administrations- und/oder 3^rd-Party-Server selbst kann nun die Authentifizierung des Nutzers mit dem Kommunikationsendgerät UE vornehmen und bei Bedarf ebenfalls einen Schlüssel generieren, wie es in Schritt 15 beschrieben ist.
Letztendlich werden dann Nutzer-spezifische Daten von dem Administrations- und/oder 3^rd-Party-Server heruntergeladen, wie beispielsweise Selfadministration Data oder SW-Upgrades. Dabei können gegebenenfalls ein Integritätsschutz bzw. Vertraulichkeits-Mechanismen unter Verwendung eines Schlüssels verwendet werden. Hierzu können bestehende Mechanismen und Algorithmen verwendet werden, wie sie die IETF bzw. auch die 3GPP vorsieht.

Claims

Verfahren zur Authentifizierung eines Nutzers eines Kommunikationsendgerätes (UE) bei Nutzung eines einen Dienst organisierenden Dienste-Server in einem zweiten Dienstnetz, bei dem – dem Nutzer bei einer Anmeldung bei einem Betreiber eines ersten Dienstnetzes (IMS) und/oder bei Registrierung in dem ersten Dienstnetz (IMS) ein Kennzeichen (Token) und eine öffentliche Kennung (User-ID) zugeordnet wird, – das dem Nutzer zugeordnete Kennzeichen (Token) und die ihm zugeordnete öffentliche Kennung (USER-ID) an den Dienste-Server in dem zweiten Dienstnetz übertragen wird, – von dem Kommunikationsendgerät (UE) eine erste Zufallszahl (RAND1) und die öffentliche Kennung (USER-ID) mit einer Authentifizierungs-Aufforderungsnachricht (Authentication-Request) an den Dienste-Server in dem zweiten Dienstnetz gesendet wird, – in dem Dienste-Server in dem zweiten Dienstnetz aus der ersten Zufallszahl (RANDl) und dem dem Dienste-Server in dem zweiten Dienstnetz für den Nutzer des Kommunikationsendgerätes (UE) zugesendeten Kennzeichen (TOKEN) gemäß eines ersten funktionalen Zusammenhangs (f1) ein erster Wert berechnet wird und zusammen mit einer zweiten Zufallszahl (RAND2) an das Kommunikationsendgerät (UE) gesendet wird, – in dem Kommunikationsendgerät (UE) aus der ersten Zufallszahl (RANDl) und dem dem Nutzer des Kommunikationsendgerätes zugeordneten Kennzeichen gemäß des ersten funktionalen Zusammenhangs (f1) ein zweiter Wert berechnet wird und dieser mit dem ersten Wert verglichen wird, – bei Übereinstimmung des ersten und des zweiten Wertes die Authentizität des Dienste-Servers erkannt wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ferner – das Kommunikationsendgerät (UE) aus der zweiten Zufallszahl (RAND2) und dem dem Nutzer des Kommunikationsendgerätes zugeordneten Kennzeichen gemäß eines zweiten funktionalen Zusammenhangs (f2) einen dritten Wert berechnet und diesen zusammen mit einer Anforderungsnachricht an den Dienste-Server in dem zweiten Dienstnetz sendet, – in dem Dienste-Server aus der zweiten Zufallszahl (RAND2) und dem dem Dienste-Server für den Nutzer des Kommunikationsendgerätes zugesendeten Kennzeichen (Token) gemäß des zweiten funktionalen Zusammenhangs (f2) ein vierter Wert berechnet wird und dieser mit dem dritten Wert verglichen wird, – bei Übereinstimmung des dritten und des vierten Wertes die Authentizität des Nutzers des Kommunikationsendgerätes (UE) erkannt wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Kommunikationsendgerät (UE) und/oder der Dienste-Server aus dem Kennzeichen, der ersten und der zweiten Zufallszahl gemäß eines dritten funktionalen Zusammenhangs einen Schlüssel generiert.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die funktionalen Zusammenhänge durch einen Verschlüsselungsalgorithmus, insbesondere durch einen MD5- und/oder einen SHA-1-Algorithmus realisiert werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als erstes Dienstnetz ein Dienstnetz verwendet wird, das in der 3GPP Standardisierung Release 5 definiert ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das erste und das zweite Dienstnetz identisch sind.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass als zweites Dienstnetz ein von dem ersten Dienstnetz unabhängige Infrastruktur verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das dem Nutzer zugeordnete Kennzeichen und die ihm zugeordnete Anmelde-IP-Adresse und/oder öffentliche Kennung an den Dienste-Server in dem zweiten Dienstnetz von dem ersten Dienstnetz bei Registrierung, Re-Registrierung oder Deregistrierung des Kommunikationsendgerätes in bzw. aus dem ersten Dienstnetz übertragen wird.