-
Die
vorliegende Erfindung betrifft die Authentifizierung von Benutzern
in einem Telekommunikationssystem. Genauer betrifft sie ein System
und ein Verfahren zum Authentifizieren eines Benutzers nach einem
aus vielen Authentifizierungsmechanismen.
-
In
einem Telekommunikationssystem ist die Authentifizierung ein Vorgang,
der zu dem Zweck durchgeführt
werden kann, zu bestätigen,
dass ein Benutzer, der Zugang dazu verlangt, oder dadurch einen
gegebenen Dienst verlangt, derjenige ist, der er zu sein behauptet.
-
Der
Vorgang des Authentifizierens eines Benutzers, der von einem gegebenen
Endgerät
(nachstehend auch als Kommunikationsausrüstung, Benutzerausrüstung oder
UE bezeichnet) auf ein Telekommunikationssystem zugreift, ist abhängig von mehreren
Faktoren wie etwa dem Sicherheitskriterium, das durch das Telekommunikationssystem
ausgeführt
wird, den Merkmalen und Eigenschaften der UE, dem verwendeten Kommunikationsprotokoll, usw.
unterschiedlich. Diese Unterschiede haben verursacht, dass mehrere
Authentifizierungsmechanismen erdacht wurden, um die unterschiedlichen
Authentifizierungsanforderungen der unterschiedlichen Telekommunikationssysteme
zu erfüllen.
-
Daher
verlassen sich zum Beispiel einige bestehende Authentifizierungsmechanismen,
wie etwa ein AKA (Authentifizierungs- und Schlüsselabkommen), ein Authentifizierungsmechanismus,
der in Mobilsystemen verwendet wird, auf einen Geheimschlüssel, der
dem Telekommunikationssystem gemein ist, und ein manipulationssicheres
Identitätsmodul,
gewöhnlich
als Teilnehmeridentitätsmodulkarte oder
SIM-Karte bekannt, das mit dem Endgerät verbunden ist (oder darin
enthalten ist); andere, wie etwa die Authentifizierungsmechanismen,
die zum Zugriff auf Dienste verwendet werden, die durch das Internet
bereitgestellt werden (wie z.B. etwa der Authentifizierungsmechanismus "Basic", der in IETF RCF1945,
Mai 1996, für
das Hypertexttransferprotokoll HTTP beschrieben ist), verlassen
sich auf ein dem Benutzer bekanntes Geheimnis, das in das Endgerät eingegeben
werden muss (z.B. eine Kombination aus Benutzername und Kennwort).
-
Um
zu beschreiben, wie einige Telekommunikationssysteme ihre Authentifizierungsbetriebsmittel
angepasst haben, um einen einzigen Authentifizierungsmechanismus
zu unterstützen,
wird nachstehend die Benutzerauthentifizierung in Mobilkommunikationssystemen
als ein Beispiel ausführlicher beschrieben
werden.
-
In
Mobilkommunikationssystemen wird ein Benutzerauthentifizierungsmechanismus
unterstützt, der
auf der Authentifizierungslogik beruht, die durch eine Anwendung
bereitgestellt wird, welche in eine manipulationssichere intelligente
Karte (SIM-Karte) eingebettet ist. Eine SIM-Karte soll entweder
fest oder entfernbar in der Benutzerausrüstung untergebracht sein, die
zum Zugriff auf diese Systeme verwendet wird.
-
Diese
intelligenten Karten sind für
unterschiedliche Mobilsysteme unterschiedlich bezeichnet; so werden
sie zum Beispiel in einem 2G-Mobilsystem
(einem Mobilsystem der zweiten Generation) (wie etwa einem globalen
System für
mobile Kommunikation, oder GSM) als SIM-Karten bezeichnet, während sie
in einem 3G-Mobilsystem (einem Mobilsystem der dritten Generation)
(wie etwa einem universellen Mobilkommunikationssystem, oder UMTS)
als UICC (UMTS integrierte Schaltkarte) bezeichnet werden.
-
In
der gleichen Weise ist auch die Anwendung (auch Identitätsmodul
genannt), die in die intelligente Karte eingebettet ist, in unterschiedlichen
Mobilsystemen unterschiedlich bezeichnet; so wird sie zum Beispiel
in einem 2G-System SIM (Teilnehmeridentitätsmodul) und in einem 3G-System
USIM (Benutzerdienste-Identitätsmodul)
genannt. Und in einem 3G-System,
das Multimediendienste auf Basis des Internetprotokolls (auch als
IP-Multimediendienste, oder IM-Dienste bekannt) bereitstellt, wird sie
ISIM (IM-Dienste-Identitätsmodul)
genannt. Nachstehend, und der größeren Einfachheit
halber, wird unabhängig
von der Mobiltechnologie, zu dem sie gehört (z.B., ob es sich um 2G,
3G, 3G mit IM-Diensten, usw. handelt), der Ausdruck xSIM verwendet
werden, um auf ein Identitätsmodul
Bezug zu nehmen. Außerdem
wird aus Gründen
der Einfachheit nachstehend der Ausdruck SIM-Karte verwendet werden, um auf wohlbekannte
intelligente Karten Bezug zu nehmen, die in Mobilkommunikationssystemen
verwendet werden.
-
Ein
Benutzer, der über
eine Mitgliedschaft bei einem Mobilsystem verfügt, ist mit einer SIM-Karte
ausgestattet, in der ein xSIM eingebettet ist. Das xSIM enthält neben
anderen Daten eine Kennung des Benutzers und einen Langzeit-Geheimschlüssel (Ki),
der diesem Benutzer einzigartig zugeteilt ist. Das xSIM enthält auch
die Authentifizierungslogik, um auf Basis des Geheimschlüssels (Ki)
einen Authentifizierungsmechanismus zu betreiben. Dies gestattet
einem gegebenen Benutzer, seine/ihre SIM-Karte mit jedem beliebigen
Endgerät
zu verbinden (sofern dieses Endgerät dazu geeignet ist, die Verbindung
mit der SIM-Karte zu akzeptieren und mit ihr zusammenzuarbeiten),
und sie zum Zugang zum Mobilsystem zu benutzen.
-
Ungeachtet
der bestimmten Einzelheiten, die mit der verwendeten Mobiltechnologie
(2G, 3G, 3G mit IM) verbunden sind, ist der Authentifizierungsmechanismus,
der verwendet wird, um einen Benutzer, der auf ein Mobilkommunikationssystem
zugreift, zu authentifizieren, ziemlich ähnlich und als AKA (Authentifizierungs-
und Schlüsselabkommen)
bekannt.
-
Um
den AKA-Authentifizierungsmechanismus zu veranschaulichen, wird
nun unter Bezugnahme auf den Signalisierungsablauf von 1 ein
Authentifizierungsvorgang eines Benutzers von einem Endgerät (UE) im
IMS (IM-Subsystem, oder Internetprotokoll-Multimedien-Subsystem)
eines 3G-Systems
beschrieben werden. Diese Figur wurde vom gegenwärtigen Standard TS 29.228 (V5.0.0;
Juni 2002) genommen, der durch das 3GPP (Partnerschaftsprojekt der
3. Generation), bei dem es sich um ein Standardisierungsforum für 3G-Systeme
handelt, veröffentlicht
wurde. Als ein Beispiel für
eine Anforderung von einem Benutzer, die vor der Gewährung ihrer
Ausführung
einer vorherigen Authentifizierung unterliegt, stellt 1 den
Signalisierungsablauf einer Registrierungsanforderung eines Benutzers
im IMS, wenn dieser Benutzer noch nicht registriert ist, und die
anschließende
Authentifizierung dieses Benutzers dar.
-
Zum
Verständnis
des in 1 dargestellten Ablaufs werden zuerst Einzelheiten
einiger grundlegender Konzepte des IMS gegeben werden. Weitere zusätzliche
Einzelheiten im Zusammenhang mit der Architektur und den grundlegenden
Signalisierungsabläufen
des IMS sind jeweils in den 3GPP-Beschreibungen
TS 23.002 (V5.7.0; Juni 2002) bzw. TS 23.228 (V5.5.0; Juni 2002)
verfügbar.
-
Das
IMS eines 3G-Kommunikationssystems umfasst eine oder mehrere Stellen
eines Satzes von funktionalen Einheiten, die ihren Benutzern Multimediendienste
bereitstellen sollen. Nach den 3GPP-Standards sind einige dieser
funktionalen Einheiten
- – eine Heimatservereinheit,
die für
das Speichern der Teilnehmerdaten der Benutzer des Systems und das
Bereitstellen von Standortinformationen verantwortlich ist (als
Heimatteilnehmerserver, HSS, bezeichnet, weist auch Funktionen des 2G-Heimatstandortregisters,
HLR, auf);
- – eine
Servereinheit, die den Zugriff auf das System zu den von seinen
Benutzern verwendeten Endgeräten
(UEs) bedient (als Proxy-Rufzustandssteuerfunktion,
P-CSCF, bezeichnet);
- – eine
Servereinheit, die das anfängliche
Handhaben von Vorgängen,
die Benutzer des Systems betreffen, bedient (als Abfrage-Rufzustandssteuerfunktion,
I-CSCF, bezeichnet); und
- – eine
Servereinheit, die Sitzungssteuerdienste für Sitzungen, die Benutzer des
Systems betreffen, leistet (als Dienst-Rufzustandssteuerfunktion, S-CSCF, bezeichnet).
-
Das
Protokoll SIP (Sitzungseinleitungsprotokoll, IETF RCF3261, Juni
2002) war das Protokoll, das durch das 3GPP-Forum für das Signalisieren zwischen
einem Benutzerendgerät
(UE) und den Einheiten des IMS wie auch unter den CSCF-Einheiten des
IMS (P-CSCF, I-CSCF, S-CSCF) gewählt
wurde, während
das Protokoll DIAMETER (draft-ietf-aaa-diameter-12.txt, Internet
Draft; Juli 2002) das Protokoll war, das für das Signalisieren zwischen
CSCF-Einheiten und dem Heimatserver HSS gewählt wurde.
-
Schritt 1 von 1 geht
von einem Benutzer aus, der versucht, sich im IMS des 3G-Mobilsystems zu
registrieren. Eine SIP-Nachricht "REGISTRIEREN" wird von seinem Endgerät (UE) zum
Server, der den Zugriff bedient, gesendet. Die Nachricht "REGISTRIEREN enthält neben
anderen Daten eine oder mehrere Kennungen, die sowohl den Benutzer als
auch die Domäne
seines/ihres Netzbetreibers identifizieren.
-
In
Schritt 2 leitet die P-CSCF die Nachricht zur entsprechenden
I-CSCF weiter, die
in Schritt 3 und 4 gegen den HSS nachprüft, ob dieser
Benutzer bereits registriert ist. Unter der Voraussetzung, dass der
Benutzer noch nicht registriert ist, leitet die I-CSCF die Registrierungsanforderung, "REGISTRIEREN", in Schritt 5 zur
S-CSCF weiter, die diesen Benutzer von diesem Endgerät letztendlich
hinsichtlich weiterer IM-Dienste bedienen wird.
-
Die
S-CSCF verfügt über Mittel
zur Feststellung, ob eine Dienstanforderung (wie etwa eine Registrierungsanforderung, "REGISTRIEREN") von einem Benutzer
kommt, der bereits für
diesen Dienst authentifiziert ist, oder nicht. Nach Erhalt der Registrierungsanforderung
von einem noch nicht authentifizierten Benutzer fragt die S-CSCF
dann in Schritt 6 den HSS nach einem oder mehreren Authentifizierungsvektoren
(nachstehend als "AV" bezeichnet), um
diesen Benutzer zu authentifizieren. Der Inhalt eines AV ist für einen
bestimmten Benutzer spezifisch aufgebaut und besteht aus einem Satz
von fünf
Elementen, die als Fünflinge
bezeichnet werden, und
- – zwei Sicherheitsschlüssel (Chiffrierschlüssel, CK,
und Unversehrtheitsschlüssel,
IK), die verwendet werden, um die Datenunversehrtheit und die Vertraulichkeit
der Nachrichten und der Benutzerdaten, die zwischen der UE und dem
Telekommunikationssystem ausgetauscht werden, sicherzustellen;
- – ein
Netzauthentifizierungskennzeichen (AUTN), das wiederum aus einem
Satz von Parametern besteht, von denen einige (die als Anonymitätsschlüssel, AK,
und Nachrichtenauthentifizierungscode, MAC, bezeichnet werden) auf
Basis des gleichen Geheimschlüssels
(Ki) erzeugt werden, der in der xSIM gespeichert ist, die dem Benutzer zugeteilt
ist und mit seiner/ihrer UE verbunden ist;
- – eine
zufällige
Zahl (RAND); und
- – eine
erwartete Antwort (XRES)
umfasst. Ein Satz von Authentifizierungsvektoren, AVs,
für einen
gegebenen Benutzer kann im Voraus im Heimatserver, HSS, verfügbar sein
und zur Bedienung der anfordernden Einheit (S-CSCF) bereit sein; alternativ
können
diese AVs von einem AUC (Authentifizierungszentrum) angefordert
werden.
-
In
Schritt 7 erhält
die S-CSCF einen oder mehrere AVs, die spezifisch zum Authentifizieren
dieses Benutzers durch die S-CSCF aufgebaut sind. Dann wählt sie
einen davon und sendet sie in Schritt 8 bis 10 eine
SIP-Nachricht "401 NICHT
BERECHTIGT" zurück, die
durch die I-CSCF und die P-CSCF zur UE zurückgeht. Diese Nachricht enthält einen
Authentifizierungsdatenkopf, der ein strukturierter Parameter ist,
welcher im SIP verwendet wird, um anzugeben, dass eine Authentifizierung
benötigt
wird (in der SIP-Terminologie
ist Datenkopf der Name, der einem Parameter einer Nachricht gegeben
ist, die zusätzliche
Informationen dafür
enthält).
Dieser Datenkopf befördert
neben anderen Daten ein Authentifizierungszeichenfolgenfeld, das "nonce" genannt wird. In
anderen Authentifizierungsmechanismen (wie etwa "HTTP-Digest"; IETF RFC2617, Juni 1999), kann dieses
nonce eine völlig
freie zufällige Zeichenfolge
sein, die zusammen mit einem durch den Benutzer bereitgestellten
Geheimnis (z.B. einer Kombination aus einem Benutzernamen und einem Kennwort)
durch das Endgerät
verwendet werden wird, um einen "Fingerabdruck" (ein Nachrichtenextrakt)
dieser Daten zu erzeugen, das zum Authentifizieren des Benutzers
dienen wird. Doch in diesem Fall hängt das nonce vom Geheimschlüssel ab
(d.h., ist es eine Funktion von "Ki", f{Ki}), da es eine
Verkettung des Authentifizierungskennzeichens (AUTN) und der Zufallszahl
(RAND) ist.
-
Der
Authentifizierungsdatenkopf befördert ebenso
eine Angabe des Authentifizierungsalgorithmus (die einen Authentifizierungsalgorithmus
auf AKA-Basis angibt), der im xSIM neben anderen Zwecken zum Extrahieren
der Sicherheitsschlüssel,
CK und IK, Nachprüfen
der Nachrichtengültigkeit,
und Berechnen der Antwortzahl, die zurückgesendet werden soll, um
eine gewährte
Authentifizierung in das System zu erhalten, angewendet werden soll.
-
Beim
Erhalt der Nachricht 401 NICHT BERECHTIGT in Schritt 10 gibt
die UE den Inhalt der erhaltenen Nachricht zum xSIM in der angeschlossenen
intelligenten Karte weiter, das die oben beschriebenen Funktionen
durchführt
(in 1 nicht gezeigt). Im Besonderen berechnet die
Authentifizierungslogik im xSIM als Ergebnis des Anwendens eines
bestimmten Chiffrieralgorithmus sowohl auf den Teil des erhaltenen
nonce, der der RAND entspricht, als auch auf den Geheimschlüssel (Ki)
eine Antwortzahl, RES, die sie für
den Benutzer speichert.
-
Sobald
die Antwortzahl RES erhalten ist, wird von der UE in Schritt 11 eine
neue Nachricht "REGISTRIEREN" gesendet. Dieses
Mal enthält
die Nachricht einen Berechtigungsdatenkopf, der ein strukturierter
Parameter ist, der im SIP verwendet wird, um eine Authentifizierung
eines Benutzers anzufordern, sobald eine vorherige Ablehnung (401 NICHT
BERECHTIGT) erhalten wurde. Der Berechtigungsdatenkopf enthält neben
anderen Daten ein Feld, das "Antwort" genannt ist und
auf Basis eines Algorithmus aufgebaut ist, der verschiedene Daten berechnet,
darunter die Antwortzahl RES, die durch das xSIM berechnet wurde.
-
Die
Schritte 12 bis 15 sind eine Wiederholung der
vorhergehenden Schritte 2 bis 5. Wenn die neue
Nachricht "REGISTRIEREN" an der S-CSCF eintrifft,
extrahiert diese die Antwortzahl RES aus dem Feld "Antwort" und vergleicht sie
diese mit der erwarteten Antwort XRES, die im gewählten Authentifizierungsvektor
AV enthalten ist. Wenn sie übereinstimmen,
ist der Benutzer von jenem Endgerät UE authentifiziert. Dann
benachrichtigt sie in den weiteren Schritten 18 und 19 den
HSS, dass sie (d.h., diese S-CSCF) diesem Benutzer von nun an IM-Dienste leisten
wird, und lädt
sie das entsprechende Benutzerprofil dieses Benutzers (d.h., einen
Satz von Daten, die in der S-CSCF verwendet werden, um zu bestimmen,
wie Dienste für
den Benutzer gehandhabt werden sollen) herunter. Schließlich erhält die UE
im Verlauf der Schritte 20 bis 22 eine Bestätigung einer gewährten Registrierung.
-
Moderne
Telekommunikationssysteme wie etwa 3G-Mobilsysteme und genauer 3G-Mobilsysteme,
die IMS aufweisen, um zusätzlich
zur Mobilität Multimediendienste
bereitzustellen, sollen ihre Benutzer von mehreren Endgerätearten
und von mehreren Zugriffsarten her bedienen. Was die Endgerätearten
betrifft, kann es sich um UEs handeln, die unterschiedliche Fähigkeiten
zur Medienhandhabung aufweisen (z.B. die Handhabung von Stimmen,
statischen Bildern, Videos, Daten, usw., und jeder beliebigen Kombination
davon). was die Zugriffsarten betrifft, muss erwähnt werden, dass Mobilbetreiber
heute ihr Angebot in Bezug auf Zugriffsnetze (d.h., das Kommunikationsnetz,
das verwendet wird, um einen Zugriff auf das Mobilsystem bereitzustellen)
durch Aufnehmen der Verwendung unlizenzierter Breitbandzugriffsarten
wie etwa WLAN (drahtloses lokales Netz), die Zugriffsgeschwindigkeiten
bis zu 11 Mbps gestatten, zu den typischen Funkzugriffsnetzen, die
gegenwärtig
in Mobilsystemen verwendet werden, wie etwa GERAN (GSM/EDGE-Funkzugriffsnetz)
oder UTRAN (UMTS terrestrisches Funkzugriffsnetz), erweitern wollen.
-
Diese
Vielzahl von Zugriffsarten betrifft auch die Fähigkeiten und Eigenschaften
der UEs. Die UE kann somit zum Beispiel ein typisches Mobilendgerät, das Kommunikationsmittel
aufweist, die zum Zugriff auf das 3G-System über UTRAN eingerichtet sind,
ein tragbarer Computer, der durch eine andere Art von Zugriffsnetz
wie etwa ein WLAN auf das 3G-System zugreift, usw. sein.
-
Doch
der Umstand, dass auf Basis der Authentifizierungslogik, die durch
eine SIM-Karte bereitgestellt wird, welche auf einen Langzeit-Geheimschlüssel "Ki" zugreift, der in
ihr enthalten ist, nur ein Authentifizierungsmechanismus wie etwa
AKA unterstützt
wird, beschränkt
die Eigenschaften der UEs, die auf diese 3G-Systeme zugreifen können, und zwingt
sie insbesondere, fähig
zu sein, mit einer SIM-Karte verbunden zu werden (oder diese unterzubringen),
und Mittel aufzuweisen, um mit der in dieser SIM-Karte eingebetteten
Funktion zu kommunizieren und zusammenzuwirken. Das heißt, die
Verwendung von UEs, die dem Rest der Fähigkeiten entsprechen können, welche
zum Zugriff auf diese Art von Telekommunikationssystemen benötigt werden,
und die bereits verbreitet verfügbar
sind, wird außer
Acht gelassen.,
-
Obwohl
AKA als ein starker Authentifizierungsmechanismus betrachtet wird,
könnte
es darüber
hinaus von Benutzern, die auf das Telekommunikationssystem zugreifen,
verlangte Betriebsmittel geben, die einer Authentifizierung unterliegen,
aber keine so starke Authentifizierung benötigen.
-
Daher
sollte es wünschenswert
sein, ein weniger restriktives Authentifizierungsrahmenwerk in Telekommunikationssystemen
zu unterstützen,
die mehreren Endgerätearten
Dienste bereitstellen möchten.
-
Die
US-Patentanmeldung US 2001/037,469 A1 offenbart ein Verfahren und
ein System zum Authentifizieren eines Benutzers, der von einem Endgerät ("Kunde, 200") eine Anforderung
eines Diensts ("Anwendungsserver, 202") vornimmt, nach
einem aus mehreren Authentifizierungsmechanismen. Das durch US 2001/037,469
offenbarte Authentifizierungsrahmenwerk gestattet das Vereinfachen
des Zugriffs von Benutzern auf Dienste durch: einmaliges Authentifizieren
eines Benutzers nach einem beliebigen Authentifizierungsmechanismus,
Schaffen einer "Sitzung" für einen
authentifizierten Benutzer, und dann Gewähren eines Zugriffs des Benutzers
auf jeden beliebigen Dienst für
die Dauer der geschaffenen Sitzung. Diese Lösung gestattet es, den Vorgang zum
Auswählen
eines Authentifizierungsmechanismus zu vereinfachen, und befreit
das Telekommunikationssystem in manchen Fällen (d.h., wenn es sich um
eine gültige
Sitzung handelt) davon, einen Benutzer authentifizieren zu müssen. Doch
in US 2001/037,469 gibt es keine Steuerung, um zu bestimmen, welcher
Authentifizierungsmechanismus für eine
Anforderung eines Diensts verwendet werden kann, da keine Auswahlkriterien
gegeben sind, damit, nach dieser Patentanmeldung, jeder beliebige verfügbare Mechanismus
ohne Beschränkung
verwendet werden kann.
-
Die
US-Patentschrift
US
6,434,700 B1 offenbart ebenfalls ein Verfahren und ein
System zum Authentifizieren eines Benutzers von einem Endgerät nach einem
Authentifizierungsmechanismus, der aus mehreren Authentifizierungsmechanismen
ausgewählt
wird. Dieses Patent offenbart eine leichter handhabbare Lösung als
die in US 2001/037,469 offenbarte. Nach der durch
US 6,434,700 offenbarten Lösung werden
die Authentifizierungsmechanismen nach einem Authentifizierungsprofil
("Profilinformationen") ausgewählt, das
mit dem Benutzer, der die Anforderung vornimmt, verbunden ist und
die Art von "Kennwort", die vom durch den
Benutzer betriebenen Endgerät
erhalten werden kann, angibt und, folglich, den entsprechenden Authentifizierungsmechanismus
zum Authentifizieren des erhaltenen Kennworts bestimmt. Sobald er
authentifiziert ist, kann der Benutzer auf jede beliebige Serveranwendung
zugreifen, die im Telekommunikationssystem verfügbar ist. Doch eine wie hierin
offenbarte Lösung
zwingt den Benutzer, stets ein Endgerät zu benutzen, das die Authentifizierungsfähigkeiten
aufweist, die benötigt werden,
um einen Authentifizierungsvorgang nach dem Authentifizierungsmechanismus,
der in seinem Authentifizierungsprofil mit dem Benutzer verbunden ist,
auszuführen.
-
Dieses
Problem kann nach einer wie in der Patentanmeldung WO 02/082296
offenbarten Lösung
gelöst
werden. Nach diesem Dokument wird eine Beziehung zwischen Authentifizierungsmechanismen
und Benutzerkennungen (Benutzernamen/Domänen) erstellt, die später gestattet,
zu bestimmen, welche(r) Authentifizierungsmechanismus (-men) verwendet
werden muss (müssen),
um einen gegebenen Benutzer, der eine Anforderung vornimmt, zu authentifizieren.
Im Gegensatz zu
US 6,434,700 gestattet
die durch WO 02/082296 offenbarte Lösung dem Benutzerendgerät, seine
Authentifizierungsfähigkeiten
anzugeben. Nach WO 02/082296 wird, wenn nach der Benutzerkennung mehr
als ein Authentifizierungsmechanismusergebnis für den Benutzer wählbar ist,
oder auch, wenn der Benutzer, oder sein Endgerät, weiß, welcher Authentifizierungsmechanismus
zu verwenden ist, die endgültige
Entscheidung zur Auswahl des Authentifizierungsmechanismus, der
verwendet werden wird, lokal durch den Benutzer oder sein Endgerät getroffen. Doch
diese lokale Entscheidung könnte
auf einer ungenauen oder veralteten Kenntnis hinsichtlich der Authentifizierungsanforderungen
für den
Zugriff auf einen gegebenen Dienst beruhen.
-
Ein
flexibles Authentifizierungsrahmenwerk sollte nicht zum Nachteil
der Handhabbarkeit des Rahmenwerks ausgeführt sein, weshalb eine flexible Steuerung
der Authentifizierungsmechanismen, die verfügbar sind, um auf Dienste und
Betriebsmittel in einem Telekommunikationssystem zuzugreifen, ein bedeutender
Faktor zum Erreichen dieser Handhabbarkeit ist.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Nach
einem Gesichtspunkt betrifft die Erfindung ein wie in Anspruch 1
beanspruchtes Verfahren zum Authentifizieren von Benutzern. Nach
einem zweiten Gesichtspunkt betrifft die Erfindung ein wie in Anspruch
8 beanspruchtes System zum Authentifizieren von Benutzern. Ausführungsformen
der Erfindung sind in den abhängigen
Ansprüchen
aufgezeigt.
-
Nach
dem Verfahren oder System der Erfindung wird der letztlich gewählte Authentifizierungsmechanismus
zum Authentifizieren eines Benutzers nicht ausschließlich auf
Basis der Authentifizierungsfähigkeiten
des Endgeräts
(falls erhalten), und/oder auf Basis von Daten über Authentifizierungsmechanismen,
die in Authentifizierungsprofilen erstellt sein könnten, welche
mit dem Benutzer oder mit mehreren Benutzern verbunden sind (falls
derartige Profile vorhanden sind) ausgewählt, sondern unter Berücksichtigung
der Eignung des (der) Authentifizierungsmechanismus (-men) für den angeforderten
Dienst oder das angeforderte Betriebsmittel.
-
Das
Verfahren oder System der Erfindung gestattet, dass, zusätzlich zu
anderen möglichen Auswahlkriterien,
nur Authentifizierungsmechanismen, die sich für die Authentifizierungsanforderungen,
welche für
einen gegebenen Dienst oder ein gegebenes Betriebsmittel festgelegt
sind, eignen, ausgewählt
werden können,
um den Zugriff darauf zu gestatten, wodurch gestattet wird, dass
eine handhabbarere Authentifizierungsverfahrensweise zum Zugriff
auf Dienste und Betriebsmittel, die von einem Telekommunikationssystem
geleistet werden, eingesetzt wird, die nach wie vor eine flexible
und gesteuerte Verwendung mehrerer verfügbarer Authentifizierungsmechanismen
erlaubt, wobei die Auswahl des Authentifizierungsmechanismus zum
Authentifizieren eines Benutzers von einem Endgerät sich nicht auf
eine Entscheidung verlassen muss, die durch den Benutzer oder durch
sein Endgerät
getroffen wird und auf einer ungenauen oder veralteten Kenntnis hinsichtlich
der Authentifizierungsanforderungen für den Zugriff auf einen gegebenen
Dienst beruhen könnte.
-
Nach
Ausführungsformen
der Erfindung können
auch Authentifizierungsprofile erstellt werden, um das Erstellen
einer Beziehung zwischen einem Dienst oder einem Betriebsmittel,
auf den/das von einem Endgerät
zugegriffen werden kann, und von Daten im Zusammenhang mit dem (den)
Authentifizierungsmechanismus (-men), der (die) für den Zugriff auf
diesen Dienst oder dieses Betriebsmittel gestattet ist (sind), zu
gestatten. Demgemäß macht
es das Speichern von Profildaten im Zusammenhang mit Diensten/Betriebsmitteln
in einer ähnlichen
Weise wie Profildaten im Zusammenhang mit Benutzern möglich, durch
Vergleichen der passenden Authentifizierungsmechanismen in beiden
Authentifizierungsprofilen leicht zu bestimmen, ob ein gegebener
Authentifizierungsmechanismus zu einem Benutzer, der auf einen gegebenen
Dienst/ein gegebenes Betriebsmittel zugreift, passt, wobei die Authentifizierungsfähigkeiten
des Endgeräts,
das die Anforderung vornimmt, ebenfalls in Betracht gezogen werden
können.
-
Nach
einer weiteren Ausführungsform
der Erfindung kann, sobald ein Authentifizierungsmechanismus zum
Authentifizieren eines Benutzers ausgewählt wurde, eine weitere Auswahl
getroffen werden, um eine Servereinheit im Telekommunikationssystem
auszuwählen,
die den Authentifizierungsvorgang des Benutzers nach dem ausgewählten Authentifizierungsmechanismus
vornehmen wird.
-
Das
Verfahren oder das System der Erfindung gestattet, Authentifizierungsmechanismen
auszuwählen,
die zu einer Authentifizierungsvorgangsweise im Telekommunikationssystem
passen, welche zum Beispiel auf Basis jedes Falls von Benutzerauthentifizierung
und/oder auf einer globalen Basis jene Authentifizierungsmechanismen
angeben kann, die akzeptiert und unterstützt werden können, um
Zugriff auf einen Dienst oder ein Betriebsmittel zu gewähren, der/das
durch das Telekommunikationssystem geleistet wird.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
1 zeigt
einen Authentifizierungssignalisierungsablauf, wie er gegenwärtig im
3GPP-Standard 29.228 für
einen IP-Multimedienbenutzer definiert ist.
-
2 ist
ein Ablaufdiagramm, das den Auswahlvorgang eines Authentifizierungsmechanismus in
einem Telekommunikationssystem nach der Erfindung zeigt.
-
3 zeigt
eine schematische Ansicht verschiedener in einem Telekommunikationssystem
gespeicherter Authentifizierungsdaten, die im Auswahlvorgang von 2 verwendet
werden können,
-
4, 5 und 6 zeigen
vereinfachte Authentifizierungssignalisierungsabläufe nach
Ausführungsformen
der Erfindung.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Die
Erfindung soll nun unter Bezugnahme auf 2 bis 6 hinsichtlich
einer bevorzugten Ausführungsform,
die als ein Beispiel eines Telekommunikationssystems, in dem die
Erfindung angewendet werden kann, ein 3G-Mobilsystem in Betracht zieht,
das das sogenannte IMS (Internetprotokoll-Multimediensubsystem)
ausführt,
ausführlich
beschrieben werden. Es sollte sich jedoch verstehen, dass der Umfang
der vorliegenden Erfindung weder auf diese 3G-Systeme mit IMS noch
auf jedwedes bestimmte Signalisierungsprotokoll oder jedweden bestimmten
Authentifizierungsmechanismus beschränkt ist. Ein Fachmann kann
sie leicht auf jedes beliebige Telekommunikationssystem anwenden, das
eine Benutzerauthentifizierung handhaben muss.
-
Der
grundlegende Ablauf eines Authentifizierungsmechanismenauswahlvorgangs
(200) in einem Telekommunikationssystem nach der vorliegenden Erfindung
ist in 2 gezeigt. Der Vorgang wird im Telekommunikationssystem
nach Erhalt einer Anforderung von einem Endgerät (UE) aufgerufen, welche einen
gegebenen Dienst für
einen Benutzer aufruft, und kann wie jeder beliebige andere Vorgang,
der in einem Telekommunikationssystem läuft, durch Software, Hardware
oder eine Kombination davon ausgeführt werden.
-
Gesichtspunkte,
die die ausführliche
Natur dieser Anforderung behandeln, liegen außerhalb des Umfangs der vorliegenden
Erfindung. Das heißt,
die erhaltene Anforderung kann, zum Beispiel, eine Benutzerregistrierungsanforderung
sein, die darum bittet, eine Kommunikationsausrüstung an das Telekommunikationssystem
anzubinden, um auf weitere Dienste, die dadurch bereitgestellt werden,
zuzugreifen; sie kann auch, zum Beispiel, eine Anforderung sein,
die um einen bestimmten Dienst (oder ein bestimmtes Betriebsmittel)
bittet, der (das) dem Benutzer bereitgestellt werden soll (oder
einen Zugriff erfahren soll), sobald er/sie bereits registriert
ist (wie etwa eine Anrufanforderung, ein Zugriff auf eine Sprachmailbox,
eine Standortinformation hinsichtlich des nächsten Krankenhauses, usw.).
-
Das
Endgerät,
das die Anforderung sendet, kann, zum Beispiel, eine einzelne Kommunikationsausrüstung sein,
die dazu geeignet ist, mit dem Telekommunikationssystem zu kommunizieren,
oder sie kann aus einem Aufbau dieser Kommunikationsausrüstung bestehen,
die mit einer manipulationssicheren Authentifizierungsvorrichtung,
wie etwa einer SIM-Karte, die ein Identitätsmodul (xSIM) aufweist, das
einen Langzeit-Geheimschlüssel
(Ki) und eine Authentifizierungslogik zum Betreiben eines oder mehrerer
Authentifizierungsmechanismen auf Basis dieses Geheimschlüssels enthält, verbunden
ist.
-
Es
soll hier bemerkt werden, dass die Abfolge der Handlungen, die in
den verschiedenen Schritten von 2 veranschaulicht
ist, nur eine mögliche Ausführungsform
eines Vorgangs zum Auswählen
eines Authentifizierungsmechanismus nach der Erfindung zeigt, wobei
die Auswahl auf Basis des Inhalts der Anforderung und, zusätzlich dazu,
auf Basis eines Authentifizierungsprofils im Zusammenhang mit dem
Benutzer, der den Dienst anfordert, getroffen wird. Nichtsdestotrotz
sind andere alternative Abfolgen der in 2 gezeigten
Schritte, sogar Abfolgen, die einen Untersatz dieser Schritte (einschließlich, zum
Beispiel, einer Auswahl, die nur auf Basis des Inhalts oder, alternativ,
des Authentifizierungsprofils getroffen wird) umfassen, gleichermaßen möglich und
können
angesichts der nachstehend offenbarten Informationen von einem Fachmann
gefolgert werden.
-
In
Schritt 201 wird der Inhalt der erhaltenen Anforderung
geprüft.
Im Besonderen kann geprüft werden,
ob die Anforderung Daten (AUI) im Zusammenhang mit einem, oder mehr
als einem, Authentifizierungsmechanismus enthält, der (die) durch die UE
unterstützt
wird (werden). Diese Art von Daten kann in jedem beliebigen geeigneten
(bereits bestehenden oder neu definierten) Parameter der Nachricht,
die die erhaltene Anforderung befördert, befördert werden. Demgemäß können die
AUI, wenn das Protokoll SIP als Beispiel herangezogen wird, in einer SIP-Anforderung
aus einem bestehenden optionalen SIP-Datenkopf, wie etwa einem Authentifizierungsdatenkopf,
bestehen, der den Namen eines wohlbekannten Authentifizierungsmechanismus
angibt. Alternativ könnte
der Name eines oder mehrerer wohlbekannter Authentifizierungsmechanismen
in einem neuen Datenkopf, wie etwa "Authentifizierung unterstützt", der in der SIP-Anforderung enthalten
ist, befördert
werden.
-
Wenn
die Prüfung
von Schritt 201 ein positives Ergebnis ("ja") ergibt, kann in
Schritt 202 geprüft werden,
ob der Authentifizierungsmechanismus, der in der erhaltenen Anforderung
als unterstützt
angegeben ist (oder jeder beliebige davon, wenn mehr als einer angegeben
ist), in einem Authentifizierungsprofil (AUP) enthalten ist, das
für den
Benutzer zutrifft, und das (wie später ausführlich besprochen werden wird)
neben anderen Daten den Satz der Authentifizierungsmechanismen angeben
kann, der im Telekommunikationssystem zum Authentifizieren des Benutzers
unterstützt
wird. Andernfalls, falls die Prüfung von
Schritt 201 ein negatives Ergebnis ("nein")
ergibt, kann die Anforderung gemäß alternativen
Ausführungsformen
entweder abgelehnt ("Ablehnung") werden, oder an
diesem Punkt angenommen ("Annahme/Versuch") werden. Im letzteren
Fall wird in Schritt 204 die Auswahl eines (oder mehr als
eines) Authentifizierungsmechanismus zum Versuch des Authentifizierens
des Benutzers gemäß dem AUP
getroffen, das diesem Benutzer entspricht.
-
Ein
wie oben erwähntes
Authentifizierungsprofil (AUP) kann mit einem bestimmten Benutzer
in Zusammenhang stehen. Ein Telekommunikationssystem weist gewöhnlich ein
Speichermittel auf, um mehrere Daten zu speichern, die mit einem
bestimmten Benutzer in Zusammenhang stehen. Zum Beispiel werden
diese Daten für
einen Benutzer eines Mobilsystems in einem sogenannten Teilnehmerdatenregister
gespeichert, das mit dem Benutzer in Zusammenhang steht, und werden
sie gewöhnlich
in einem Heimatserver (z.B. HLR, HSS) gehalten. Die Natur der Daten,
die pro Teilnehmer in diesem Speichermittel gespeichert sind, hängt gewöhnlich von der
Kompliziertheit und der Vielfalt der Dienste ab, die durch das Telekommunikationssystem
bereitgestellt werden. Für
einen gegebenen Benutzer können somit,
zum Beispiel, die Kennungen, die dem Benutzer zugeteilt sind (und
normalerweise verwendet werden, um auf sein/ihr Teilnehmerdatenregister
zuzugreifen) und in Anzahl und Format mannigfaltig sein können (z.B.
eine E.164-Telefonnummer wie etwa +1-212-555-222, ein einheitlicher
Quellenlokalisierer für
SIP, oder ein SIP-URL wie etwa John Doe@homeABC.net, usw.); Daten,
die, zum Beispiel, mit Zusatzdiensten (z.B. für einen "Anrufweiterleitungs"zusatzdienst: ob für diesen Benutzer eine Anrufweiterleitung
stattfinden kann, unter welchen Bedingungen, die Weiterleitungsnummer,
usw.) in Zusammenhang stehen; usw. gespeichert werden. Das Speichermittel
kann ferner Daten im Zusammenhang mit einem oder mehreren Authentifizierungsmechanismen
speichern, welche unterstützt
werden können,
um diesen Benutzer zu authentifizieren, und wirkt dann als ein einzelnes
AUP.
-
Darüber hinaus
könnte
der gleiche Benutzer mit mehr als einem AUP in Zusammenhang stehen, wobei
jedes einzelne, zum Beispiel, mit jeder einzelnen der Kennungen,
die dem Benutzer zugeteilt sind, oder einer Gruppe davon in Zusammenhang
steht, wodurch eine AUP-Auswahl nach dem Inhalt der erhaltenen Anforderung
gestattet wird, wobei eine Benutzerkennung (ID), die in der Anforderung
erhalten wird, bei der Auswahl berücksichtigt wird.
-
Als
eine alternative Ausführungsform
kann das gleiche Authentifizierungsprofil (AUP) mit mehreren Benutzern
oder sogar mit allen Benutzern des Kommunikationssystems in Zusammenhang
stehen, und wirkt dann als ein kollektives AUP, das ein gemeinsames
Authentifizierungsprofil für
die mehreren Benutzer angibt. In diesem Fall kann das oben erwähnte Teilnehmerdatenregister
eines Benutzers, der einem kollektiven AUP zugeteilt ist, einen
Bezug enthalten, der das entsprechende kollektive AUP aufzeigt.
-
Nach
einer weiteren alternativen Ausführungsform
können
mehrere Benutzer einem einzelnen AUP zugeteilt sein, während andere
Benutzer einem kollektiven AUP zugeteilt sein können. Darüber hinaus kann im gleichen
Telekommunikationssystem mehr als ein kollektives AUP definiert
sein, wobei Gruppen von Benutzern, die keinem einzelnen AUP zugeteilt
sind, irgendeinem davon zugeteilt sind.
-
3 zeigt
schematisch den Inhalt eines AUP (ungeachtet dessen, ob es sich
um ein einzelnes AUP oder ein kollektives AUP handelt). Wie in der
Figur gezeigt kann es eine Liste von Authentifizierungsmechanismen
(in der Figur als "Auth-1", "Auth-2", "Auth-3", usw. bezeichnet)
enthalten, wobei jeder einen bestimmten wohlbekannten Authentifizierungsmechanismus
(wie etwa "AKA", "HTTP-Digest", "HTTP-Basic", usw.) angibt. Als
eine Ausführungsoption
kann die Liste der Authentifizierungsmechanismen (wenn mehr als
einer angegeben ist) nach ihrer Stärke geordnet sein (wie in 3 gezeigt
ist).
-
In
einem AUP könnten
weitere Daten enthalten sein, die nicht in 3 (301)
gezeigt sind. Zum Beispiel könnte
im gleichen AUP pro Dienst oder Betriebsmittel, der/das in einer
von einem Benutzer erhaltenen Anforderung angefordert werden kann, mehr
als die eine in der Figur veranschaulichte Liste vorhanden sein,
wodurch eine Beziehung zwischen einem gegebenen Dienst/Betriebsmittel
und dem Authentifizierungsmechanismus (oder der Liste von Authentifizierungsmechanismen),
das dafür
verwendet werden soll, erstellt wird. Jeder dieser möglichen
Untersätze
aus Authentifizierungsmechanismus (-men) und Dienst/Betriebsmittel,
die in Zusammenhang stehen, in einem AUP kann auch selbst als ein
Authentifizierungsprofil AUP zum Zweck der AUP-Bestimmung, auf die
in weiteren Schritten Bezug genommen werden wird, betrachtet werden.
-
Die
Speicherung der oben erwähnten
Beziehung in einem AUP würde
ein zusätzliches
Kriterium bereitstellen, das zum Auswählen eines Authentifizierungsmechanismus
(oder einer Liste davon) auf Basis des Inhaltes der erhaltenen Anforderung
verwendet werden kann, wobei der/das durch die Anforderung verlangte
Dienst/Betriebsmittel berücksichtigt wird,
wie weiter darauf Bezug genommen werden wird. Somit kann für einen
gegebenen Dienst (wie etwa eine Benutzerregistrierungsanforderung)
einer oder eine Liste von unterstützten Authentifizierungsmechanismen
angegeben sein. In der gleichen Weise kann für andere Dienste oder Zugriffsanforderungen
nach anderen Betriebsmitteln (wie etwa, zum Beispiel, der Zugriff
auf die Sprachmailbox, das Prüfen
des Abrechnungssaldos, usw.) eine andere Liste von unterstützten Authentifizierungsmechanismen festgelegt
sein.
-
Die
möglichen
Kombinationen der alternativen Ausführungsformen im Zusammenhang
mit der AUP-Zuteilung und dem Inhalt, wie sie oben beschrieben sind,
erleichtert die Entwicklung einer flexiblen Authentifizierungsvorgangsweise
im Telekommunikationssystem. Somit kann der (können die) Authentifizierungsmechanismus
(-men), der (die) unterstützt
werden kann (können),
auf Basis eines Benutzers, auf Basis einer Gruppe von Benutzern,
auf Basis des Zugriffs auf einen Dienst/ein Betriebsmittel, oder
Kombinationen davon angegeben sein.
-
Unter
erneuter Bezugnahme auf das Ablaufdiagramm von 2 werden
die in der Anforderung erhaltenen Authentifizierungsdaten, AUI,
in Schritt 202 gegen das AUP, das diesem Benutzer entspricht, geprüft. Wie
früher
erwähnt
kann dieses Prüfen
für Benutzer,
denen mehr als eine Kennung zugeteilt ist, die Benutzerkennung (ID),
die in der Anforderung erhalten wurde, in Betracht ziehen, um das
entsprechende AUP zu bestimmen. Zusätzlich oder alternativ kann
der verlangte Dienst oder das verlangte Betriebsmittel verwendet
werden, um ein AUP zu bestimmen.
-
Wenn
eine Übereinstimmung
("ja") zwischen den durch
das Endgerät
unterstützen
Authentifizierungsmechanismen und einem beliebigen der im AUP angegebenen
Authentifizierungsmechanismen besteht, wird der übereinstimmende Authentifizierungsmechanismus
dann in Schritt 203 ausgewählt. Falls mehr als ein übereinstimmender
Authentifizierungsmechanismus vorhanden ist, kann, als eine Ausführungsoption,
jeder beliebige davon, oder der stärkste, ausgewählt werden.
Alternativ kann die Liste der übereinstimmenden
Authentifizierungsmechanismen zum Zweck der weiteren Auswahl von
Schritt 205 zeitweilig behalten werden.
-
Andernfalls,
falls kein übereinstimmender Authentifizierungsmechanismus
vorhanden ist, kann die Anforderung in der Folge entweder abgelehnt ("Ablehnung") werden, oder ihre
Verarbeitung bis jetzt angenommen werden ("Annahme/Versuch"). Im letzteren Fall wird in Schritt 204 die
Auswahl eines (oder mehr als eines) Authentifizierungsmechanismus
getroffen, um eine Authentifizierung des Benutzers zu versuchen.
-
In
Schritt 204 kann auf Basis des AUP, das mit dem Benutzer
in Zusammenhang steht, ein (oder mehr als ein) Authentifizierungsmechanismus
ausgewählt
werden. Die Bestimmung des AUP kann, wie früher erwähnt, auf mehreren (ausführungsabhängigen)
Kriterien, wie etwa, ob der Benutzer nur einem einzelnen Profil
(entweder einem einzelnen oder einem kollektiven AUP) oder mehr
als einem (z.B., falls der Benutzer mehrere AUPs aufweist, die mit
mehreren Kennungen in Zusammenhang stehen), und/oder auf dem angeforderten
Dienst beruhen. Für
Benutzer, die über
eine oder mehr als eine Kennung verfügen, kann zuerst eine Benutzerkennung
(ID), die in der Anforderung erhalten wurde, verwendet werden; um
das mit dieser Kennung in Zusammenhang stehende AUP auszuwählen (z.B.
zunächst
Ausfindigmachen des Teilnehmerdatenregisters, das mit der erhaltenen
ID in Zusammenhang steht, und dann Herausfinden des entsprechenden
AUP). Außerdem kann,
wie früher
erwähnt,
als eine Option der Dienst oder das Betriebsmittel, der/das durch
die erhaltene Anforderung verlangt wird, verwendet werden, um das
AUP zu bestimmen, das damit in Zusammenhang steht.
-
Sobald
das entsprechende AUP bestimmt wurde, kann im Fall einer Mehrfachübereinstimmung eine ähnliche
Logik wie die vorher unter Bezugnahme auf Schritt 203 beschriebene
angewendet werden. Das heißt,
wenn das AUP mehr als einen Authentifizierungsmechanismus angibt,
kann, als eine Ausführungsoption,
jeder beliebige davon, oder der stärkste ausgewählt werden.
Zum Zweck der weiteren Auswahl von Schritt 205 können außerdem alle oder
ein Satz der Authentifizierungsmechanismen, die im AUP angegeben
sind, zeitweilig behalten werden.
-
In
Schritt 205 kann, wie vorher angegeben, auf Basis des Diensts
oder Betriebsmittels, der/das durch die erhaltene Anforderung betroffen
ist, eine weitere Auswahl getroffen werden, indem er/es mit dem
(den) unterstützten
Authentifizierungsmechanismus (-men) verglichen wird, das (die)
im entsprechenden AUP für
diesen Dienst oder dieses Betriebsmittel angegeben ist (sind). wenn
wir also, zum Beispiel, aus der vorherigen Auswahl, die in den früheren Schritten 203 oder 204 getroffen
wurde, über zwei
ausgewählte
Authentifizierungsmechanismen (z.B. "Auth-1", AKA; und "Auth-3", HTTP-Basic) verfügen, der angeforderte Dienst
eine Registrierungsanforderung REGISTRIEREN ist, und, nach den Daten,
die für
diesen Benutzer optional im betroffenen AUP gespeichert werden können, angegeben
ist, dass (z.B.) für
diesen Dienst nur "Auth-1" akzeptiert werden
soll, dann soll dieses Authentifizierungsverfahren (z.B. "Auth-1", AKA) zum Authentifizieren
des Benutzers für
diese Anforderung verwendet werden.
-
Wenn,
zum Beispiel, die vorher in den früheren Schritten 203 oder 204 getroffene
Auswahl nur einen Authentifizierungsmechanismus ergab, kann Schritt 205 ferner
eine Prüfung
der Umsetzbarkeit des Authentifizierungsmechanismus zur Verwendung
im Authentifizierungsvorgang der Anforderung auf Basis des Diensts
oder Betriebsmittels, den/das sie betrifft, umfassen.
-
In
jedem Fall sollte sich nach der Ausführung von Schritt 205 nur
ein Authentifizierungsmechanismus ergeben.
-
In
Schritt 206 kann eine Bestimmung hinsichtlich des Knotens
(oder der funktionalen Servereinheit) im Telekommunikationssystem,
der (die) letztendlich die Authentifizierung des Benutzers für die erhaltene
Anforderung durchführen
wird, vorgenommen werden. Diese Bestimmung kann, zum Beispiel, auf
Basis einer Datentabelle vorgenommen werden, die jeden unterstützten Authentifizierungsmechanismus
mit dem dafür
berechtigten Knoten im Telekommunikationssystem, d.h., einem Knoten,
der ein wohlbekanntes Authentifizierungsmittel zum Authentifizieren
eines Benutzers nach einem wohlbekannten Authentifizierungsmechanismus
aufweist, in Zusammenhang bringt.
-
Die
genaue Natur der Daten, die auf einen bestimmten berechtigten Knoten
(oder eine bestimmte berechtigte funktionale Servereinheit) verweisen, hängt zu einem
hohen Grad von Ausführungseinzelheiten
wie auch von den bestimmten Eigenschaften des Telekommunikationssystems
(z.B. der Anzahl der Knoten einer gegebenen Art im Telekommunikationssystem,
der Art von Knoten, die beim Bedienen einer gegebenen Anforderung
von einem Benutzer eingreifen, usw.) ab. Somit kann der berechtigte
Knoten, zum Beispiel, durch einen Namen bezeichnet sein, der seine
Art angibt (z.B. "S-CSCF", "HSS", usw.); oder, zum
Beispiel, durch eine Adresse bezeichnet sein, die einen Knoten einzigartig
identifiziert (z.B. "scscf3.homeABC.net", "hss1.homeABC.net", usw.). In jedem
Fall sollen die Daten, die mit dem Knoten, der für einen gegebenen Authentifizierungsmechanismus
berechtigt ist, in Zusammenhang stehen, ausreichend sein, um im
Knoten, der diese Stufe (Schritt 207) des Auswahlvorgangs
(200) betreibt, zu bestimmen, ob er selbst der berechtigte Knoten
ist, oder nicht; und, falls er es nicht ist, den Knoten (oder die
funktionale Servereinheit) zu bestimmen, der (die) dazu berechtigt
ist.
-
Es
soll bemerkt werden, dass der gleiche Knoten berechtigt sein könnte, mehr
als einen Authentifizierungsmechanismus zu bedienen, und dass ein
gegebener Authentifizierungsmechanismus auch von mehr als einem
Knoten im Telekommunikationssystem in der gleichen weise bedient
werden könnte.
-
3 (302)
zeigt eine Tabelle mit einer möglichen
Datengestaltung für
die Bestimmung von Schritt 206, wobei eine Servereinheit
(S-CSCF) zum Authentifizieren nach einem ersten Authentifizierungsmechanismus
(als "Auth-1" vermerkt) berechtigt
ist, während
eine andere Servereinheit (HSS) zum Authentifizieren nach einem
zweiten und einem dritten Authentifizierungsmechanismus (als "Auth-2", "Auth-3" vermerkt) berechtigt
ist.
-
Sobald
die Bestimmung von Schritt 206 vorgenommen ist, wird in
Schritt 207 nachgeprüft,
ob der Knoten (oder die funktionale Servereinheit), der (die) in
dieser Stufe (Schritt 207) des Auswahlvorgangs (200)
läuft,
der (die) eine ist, der (die) für
den ausgewählten
Authentifizierungsmechanismus berechtigt ist. Wenn es der (die)
selbe wie jene(r) ist, der (die) diesen Schritt des Auswahlvorgangs
(200) vornimmt, wird er (sie) dann in Schritt 208 den
Befehl zum Authentifizieren zum registrierenden Endgerät (UE) senden.
Dieser Befehl wird nach wohlbekannten Verfahren, die für die wohlbekannten
ausgewählten
Authentifizierungsmechanismen bestimmt sind, codiert, weiter verarbeitet,
gesendet, usw.
-
Andernfalls,
wenn es sich um einen anderen Knoten handelt, leitet der Knoten,
der diesen Schritt des Auswahlvorgangs (200) vornimmt,
in Schritt 209 die Daten, die vom ausgewählten Knoten
benötigt werden,
um die Authentifizierung des Benutzers nach dem ausgewählten Authentifizierungsmechanismus
durchzuführen,
(z.B. direkt, oder durch einen anderen eingreifenden Knoten) zum
ausgewählten Knoten
weiter. Die bestimmte Natur dieser Daten wird zu einem hohen Grad
vom ausgewählten
Authentifizierungsmechanismus wie auch von der Kenntnis im ausgewählten Knoten
hinsichtlich des Parameters (der Parameter), der (die) zum Durchführen einer
Authentifizierung nach diesem Mechanismus benötigt wird (werden), abhängen. Wenn
der ausgewählte
Authentifizierungsmechanismus zum Beispiel AKA ist, sollte der ausgewählte Knoten
(oder die ausgewählte
funktionale Servereinheit) zur Vornahme der Authentifizierung des
Benutzers von diesem Endgerät
nach AKA dazu fähig
sein, entweder auf den Langzeit-Geheimschlüssel (Ki),
der dem anfordernden Benutzer zur Erzeugung eines (oder mehrerer)
Authentifizierungsvektors (-vektoren) AV auf Basis dieses Langzeit-Geheimschlüssels (Ki)
zugeteilt ist, zuzugreifen, oder einen (oder mehrere) dieser Authentifizierungsvektoren
AV zu erhalten. Wenn der ausgewählte
Authentifizierungsmechanismus zum Beispiel HTTP-Basic ist, sollte
der Knoten (die Einheit) den "Benutzernamen" und das "Kennwort" des Benutzers kennen
(oder erhalten).
-
Vorzugsweise
(obwohl dies in einigen Ausführungsformen,
in denen der Authentifizierungsmechanismus zum Beispiel von den
Daten, die zur Durchführung
der Authentifizierung erhalten wurden, abgeleitet werden kann, überflüssig sein
kann) kann vom Knoten, der den Auswahlvorgang (200) in
dieser Stufe ausführt,
eine ausdrückliche
Angabe des ausgewählten
Authentifizierungsmechanismus zum Knoten, der zur Durchführung der
Authentifizierung berechtigt ist, gesendet werden.
-
Nun
wird auf die in 4, 5 und 6 gezeigten
Signalisierungsabläufe
Bezug genommen, um die Authentifizierung eines Benutzers im IMS
eines 3G-Systems
nach der Erfindung zu veranschaulichen. In allen Fällen, die
in diesen Figuren veranschaulicht sind, wird eine Registrierungsanforderung REGISTRIEREN
als Beispiel für
eine Anforderung, die von einer Benutzerausrüstung (UE1, UE2) erhalten wird
und einer Benutzerauthentifizierung unterliegt, verwendet. Doch
wie vorher erwähnt
kann es mehrere Arten von Anforderungen geben, die, nach der bekannten
Technik und/oder der in einem Telekommunikationssystem eingesetzten
Authentifizierungsvorgangsweise, ebenfalls einer Authentifizierung unterliegen,
und bei denen die Grundsätze
dieser Erfindung gleichermaßen
Anwendung finden können.
-
Außerdem erscheint
das Mittel zum Auswählen
eines Authentifizierungsmechanismus nach Vorgang 200 in
allen gezeigten Fällen
als im HSS ausgeführt
zu werden. Dies sollte als eine vorteilhafte alternative Ausführungsform
betrachtet werden, die weniger Auswirkungen im IMS eines 3G-Systems
aufweist. Ein Grund ist, dass der HSS die Mastereinheit ist, die
Teilnehmerdaten speichert und handhabt und somit über direkten
Zugriff auf, neben anderen Daten, das Authentifizierungsprofil AUP
des Benutzers, der den Dienst anfordert, verfügt. Ein anderer Grund ist,
dass der HSS gegenwärtig
nach dem Erhalt mancher Anforderungen, die gewöhnlich immer einer Authentifizierung
unterliegen, wie etwa eine Registrierungsanforderung, REGISTRIEREN,
stets von der S-CSCF abgefragt wird. Dies sollte jedoch nicht für irgendeine
andere Ausführungsform
als zwingend betrachtet werden, in der das Mittel zum Auswählen eines
Authentifizierungsmechanismus in irgendeiner anderen Einheit (irgendeinem
anderen Knoten), die (der) in die Verarbeitung der Anforderung eingreift, sitzt,
wie, zum Beispiel, in der S-CSCF.
-
Aus
Gründen
der Einfachheit wurden in den Signalisierungsabläufen, die in 4, 5 und 6 gezeigt
sind, andere Einheiten (wie etwa P-CSCFs, I-CSCFs), die in diese
Abläufe
eingreifen (wie in 1 des Stands der Technik gezeigt)
weggelassen.
-
In
Schritt 401, 501 oder 601 von 4, 5 bzw. 6 wird
eine Registrierungsanforderung, REGISTRIEREN, in einer Dienst-Rufzustandssteuerfunktion,
S-CSCF, erhalten. Die Anforderung befördert, nach dem SIP-Protokoll,
eine oder mehrere Kennungen (ID), die den Benutzer, der die Anforderung
ausgibt, identifizieren (wie etwa einen SIP-URL: John Doe@homeABC.net).
Wie vorher unter Bezugnahme auf 1 des Stands
der Technik erwähnt
weist eine S-CSCF des Stands der Technik bereits ein Mittel zum
Erhalten einer Benutzeranforderung und ein Mittel zum Feststellen,
dass dieser Benutzer nicht authentifiziert ist, auf. Daher wird,
falls der Benutzer für
diese Anforderung noch nicht authentifiziert ist (d.h., es sich
in diesem Fall nicht um eine "Wiederregistrierung" handelt), die S-CSCF
in den entsprechenden Schritten 402, 502 oder 602 eine
Anforderung zur Authentifizierung dieses Benutzers (Auth.Anf.)an
den HSS senden. Das Kommunikationsprotokoll, das zum Senden dieser
Anforderung von der S-CSCF zum HSS wie auch für dessen letztendliche Antwort
verwendet wird, kann das oben erwähnte DIAMETER-Protokoll oder
jedes beliebige andere geeignete Kommunikationsprotokoll sein.
-
Die
zum HSS gesendete Anforderung befördert eine oder mehrere der
Benutzerkennungen (ID), die in "REGISTRIEREN" erhalten wurden
und durch den HSS verwendet werden können, um die diesem Benutzer
entsprechenden Daten herauszufinden, wie auch, falls diese in der
Anforderung REGISTRIEREN erhalten wurden, Authentifizierungsinformationen
AUI im Zusammenhang mit einem oder mehreren Authentifizierungsmechanismen,
die durch die Benutzerausrüstung
(UE1, UE2) unterstützt
werden. Die zum HSS gesendete Anforderung kann ferner Informationen
im Zusammenhang mit der Art des Diensts und/oder des Betriebsmittels,
der/das in der erhaltenen Anforderung aufgenommen ist, befördern; somit
kann sie in diesem beispielhaften Fall angeben, dass es sich um
eine "Registrierungsanforderung" handelt.
-
Unterschiede
in den weiteren Schritten von 4, 5 und 6 werden
nachstehend unter Verwendung von beispielhaften Fällen beschrieben werden,
die Veränderungen
bei verschiedenen Faktoren wie etwa den erhaltenen Authentifizierungsinformationen
AUI; dem gewählten
AUP; der Servereinheit, die für
den ausgewählten
Authentifizierungsmechanismus berechtigt ist; oder alternative Ausführungsformen
zum Ausführen
der Authentifizierung des Benutzers von seinem/ihrem Endgerät (UE1, UE2)
nach dem ausgewählten
Authentifizierungsmechanismus zeigen.
-
Das
in 4 gezeigte Endgerät (UE1) ist, zum Beispiel,
ein Mobilendgerät,
das über
UTRAN auf das 3G-System zugreift und mit einer SIM-Karte ausgerüstet ist,
die ein xSIM enthält,
das den Langzeit-Geheimschlüssel (Ki)
speichert, der einem Benutzer des 3G-Systems zugeteilt ist, und
die Authentifizierungslogik enthält,
um den AKA-Authentifizierungsmechanismus auf Basis dieses Geheimschlüssels zu
betreiben. Es sollte bemerkt werden, dass das gleiche Endgerät, UE1,
zusätzlich
fähig sein könnte, jeden
beliebigen anderen wohlbekannten Authentifizierungsmechanismus,
wie etwa HTTP-Basic, zu betreiben, der sich nicht auf eine SIM-Karte,
sondern statt dessen auf die Authentifizierungslogik verlässt, die
durch das Endgerät
durch Zugreifen auf ein durch den Benutzer in das Endgerät eingegebenes
Geheimnis bereitgestellt wird.
-
Nach
dem Erhalt der Anforderung der Authentifizierung (Auth.Anf.) in
Schritt 402 im HSS führt dieser
den wie vorher beschriebenen Authentifizierungsauswahlvorgang (200)
aus.
-
In 4 wurde
angenommen, dass der in der Auswahl (200) ausgewählte Authentifizierungsmechanismus
AKA war (d.h., die UE1 diesen als unterstützt angegeben hatte und er
nach dem entsprechenden AUP gestattet war; oder er nicht durch die UE1
angegeben wurde, aber gemäß dem AUP
und gemäß dem angeforderten
Dienst/Betriebsmittel AKA ausgewählt
wurde), und nach der Tabelle (3, 302),
die in Schritt 206 geprüft
wurde, ist S-CSCF
die Einheit, die zum Durchführen
dieser Authentifizierung berechtigt ist. Daher gibt der HSS der S-CSCF
in Schritt 403 eine Antwort (Auth.Antw.) zurück, die
eine Angabe des ausgewählten
Authentifizierungsmechanismus (AKA) wie auch einen oder mehrere
Authentifizierungsvektoren zum Beginnen der AKA-Authentifizierung
durch die S-CSCF enthält, wobei
jeder davon spezifisch für
diesen Benutzer aufgebaut ist und RAND, AUTN, XRES, CK und IK umfasst.
Zusätzlich
kann der HSS eine ausdrückliche Angabe
senden, die die S-CSCF anweist, die AKA-Authentifizierung selbst
durchzuführen,
obwohl dies nach dem Erhalt der Authentifizierungsvektoren und einer
AKA-Angabe als Antwort (Auth.Antw.) auf eine vorher zum HSS gesendete
Authentifizierungsanforderung (Auth.Anf.) für die S-CSCF nicht notwendig
sein könnte.
Dann beginnt die S-CSCF in Schritt 404 mit der Authentifizierung
des Benutzers von diesem Endgerät
(UE1) nach AKA, die, wie vorher unter Bezugnahme auf 1 beschrieben
wurde, mit dem Senden einer SIP-Nachricht
(401 NICHT BERECHTIGT) zu diesem Endgerät (UE1) beginnt, welche, neben
anderen Daten, eine Authentifizierungszeichenfolge (nonce) befördert, die
eine Funktion des Langzeit-Geheimschlüssels ist (d.h., davon abhängt), da
sie eine geheimschlüsselabhängige Authentifizierungsmarkierung
(AUTN) umfasst.
-
Das
Endgerät
(UE1) gibt dann die Authentifizierungszeichenfolge an das xSIM weiter.
Die Authentifizierungslogik im xSIM erhält mit Hilfe des Langzeit-Geheimschlüssels (Ki),
den es speichert, die Sicherheitsschlüssel CK und IK, prüft die Nachrichtengültigkeit
nach und berechnet die passende Antwort (RES). Diese Antwort (RES)
ist das Ergebnis des Anwendens eines bestimmten Chiffrieralgorithmus,
der durch AKA definiert ist, sowohl auf den Teil der Authentifizierungszeichenfolge
(nonce), der dem RAND-Teil des Authentifizierungsvektors entspricht, als
auch auf den Langzeit-Geheimschlüssel
(Ki); der im xSIM gespeichert ist (in 4 als "f{Ki, RAND} vermerkt).
Sobald sie erlangt wurde, wird diese Antwort (RES) vom xSIM zum
Endgerät
(UE1) weitergegeben, welches in Schritt 405 eine neue Registrierungsanforderung,
REGISTRIEREN, sendet. Wenn die erhaltene Antwort (RES) der erwarteten
Antwort (XRES) des Authentifizierungsvektors, der in dieser AKA-Authentifizierung
verwendet wird, entspricht, sendet die S-CSCF in Schritt 406 eine
Angabe (aktualisiere Standort) zum HSS, die diesen informiert, dass
diese S-CSCF im Besonderen (z.B. scsf5.homeABC.net) diesen Benutzer
im Hinblick auf IM-Dienste bedient. Über diesen Schritt (der Schritt 18 von 1 gleichwertig
ist) hinaus finden weitere, das Verständnis der Erfindung nicht beeinflussende Schritte
statt (in 4 nicht gezeigt), worin das
Benutzerprofil dieses Benutzers vom HSS zum S-CSCF heruntergeladen wird, und worin
das Endgerät
(UE1) eine Bestätigung
seiner Registrierung erhält.
-
5 und 6 zeigen
alternative Ausführungsformen
eines beispielhaften Falls, in dem das durch den Benutzer verwendete
Endgerät
(UE2) zum Beispiel ein typischer tragbarer Computer ist, der keine
damit verbundene SIM-Karte aufweist. Dieses Endgerät (UE2)
kann Kommunikationsmittel (Software und Hardware) enthalten, die
ihm gestatten, durch Verwenden eines wohlbekannten Kommunikationsprotokolls,
wie etwa des SIP-Protokolls, durch ein verbindendes Netz mit einer
anderen Einheit, die das SIP-Protokoll ausführt, zu kommunizieren (z.B.
eine Multimedienkommunikation, eine Datensitzung, usw. herzustellen).
Das Endgerät
kann einen Authentifizierungsmechanismus unterstützen, der sich nicht auf eine
SIM-Karte verlässt,
und der zur Verwendung in Kombination mit dem SIP geeignet ist,
wie etwa HTTP-Digest. In der gleichen Weise, wie diese Art von Endgeräten des
Stands der Technik (wie sie für UE2
beschrieben ist) gewöhnlich
mit zusätzlichen Kommunikationsmitteln
zum Kommunizieren mit anderen Endgeräten durch ein Kommunikationsnetz wie
etwa ein LAN (lokales Netz) versehen sind, können sie mit Mitteln zum Kommunizieren
durch eine andere Art von verbindendem Netz versehen sein, wie etwa
einem WLAN, das, wie früher
erwähnt;
Zugriff auf ein 3G-System bereitstellen könnte.
-
Eine
Anforderung (z.B. eine Registrierungsanforderung, REGISTRIEREN),
die die Identität
seines Benutzers (ID) und HTTP-Digest als AUI angibt, kann in Schritt 501 (oder 601)
von diesem Endgerät UE2
an einer S-CSCF eintreffen. Wie vorher beschrieben würde die
in Schritt 502 (oder 602) gesendete Nachricht
dann die besonderen Daten der erhaltenen Anforderung befördern, und
würde sie
den HSS den Authentifizierungsauswahlvorgang vornehmen lassen.
-
Sowohl
in 5 als auch in 6 wurde
angenommen, dass der im Auswahlvorgang (200) ausgewählte Authentifizierungsmechanismus
HTTP-Digest war; z.B., da die UE2 diesen in REGISTRIEREN als unterstützt angegeben
hatte und er nach dem entsprechenden AUP gestattet war (wenn die
UE2 nichts angegeben hat, könnte
dieser Mechanismus alternativ nach dem AUP und nach dem angeforderten
Dienst/Betriebsmittel ausgewählt
worden sein). Es soll bemerkt werden, dass die erhaltene Anforderung,
REGISTRIEREN, den gleichen Benutzer wie im vorhergehenden Beispiel
von 4 identifizieren kann; d.h., die erhaltene Anforderung
enthält
die gleiche Kennung (ID) oder eine andere, die ebenfalls mit dem
gleichen Benutzer in Zusammenhang steht. Daher könnte dieser Authentifizierungsmechanismus auch
nach dem bestimmten AUP gewählt
worden sein, das mit der ID dieses Benutzers, die in der Anforderung
erhalten wurde, in Zusammenhang steht.
-
Für beide
Abläufe,
die in 5 und 6 veranschaulicht sind, wurde
ein beispielhafter Fall in Betracht gezogen, in dem die in Schritt 206 geprüfte Tabelle
(3, 302) den HSS als die Einheit/den Knoten
angibt, die/der zum Durchführen
der Authentifizierung nach dem ausgewählten Authentifizierungsmechanismus
HTTP-Digest berechtigt ist.
-
Der
mit Schritt 503 von 5 beginnende Ablauf
zeigt eine alternative Ausführungsform,
wobei die S-CSCF in den Authentifizierungssignalisierungsvorgang
eingreift, während
der mit Schritt 603 von 6 beginnende Ablauf den gleichen
Fall für
eine andere alternative Ausführungsform
ohne den Eingriff der S-CSCF in Betracht zieht. In beiden Fällen erzeugt
der HSS unabhängig
von einem Langzeit-Geheimschlüssel
(Ki), der dem Benutzer zugeteilt sein könnte, eine Authentifizierungszeichenfolge (STR).
Daher kann diese Zeichenfolge eine völlig zufällige Folge von Zeichen sein,
obwohl sie auch einige Daten (wie etwa einen Zeitstempel) enthalten könnte, die
die Wiederholung eines Wert vermeiden (wodurch die Qualität des Schutzes
der Authentifizierung vor Wiederholungsangriffen verstärkt wird).
-
In
der alternativen Ausführungsform,
die in 5 gezeigt ist, antwortet der HSS der S=CSCF in Schritt 503 mit
einer Antwort (Auth.Antw.), die eine Angabe des ausgewählten Authentifizierungsmechanismus
(HTTP-Digest) wie
auch die Authentifizierungszeichenfolge (STR) enthält. Zusätzlich kann
der HSS der S-CSCF eine ausdrückliche
Angabe senden, die angibt, dass der HSS zum Authentifizieren des
Benutzers berechtigt ist (d.h., zur Gewährung der Authentifizierung
auf Basis der Antwort berechtigt ist), obwohl diese Angabe (abhängig von
Ausführungseinzelheiten)
für die
S-CSCF nicht notwendig sein
könnte,
falls sie in der Antwort (Auth.Antw.) vom HSS einen gegebenen Authentifizierungsmechanismus
(wie etwa, zum Beispiel, HTTP-Digest) erhält. Dann sendet die S-CSCF
gemäß den vom
HSS erhaltenen Informationen in Schritt 504 eine SIP-Nachricht
(401 NICHT BERECHTIGT) zum Endgerät (UE2), die neben anderen
Daten die erhaltene Authentifizierungszeichenfolge (STR) als nonce
enthält.
-
In
der alternativen Ausführungsform,
die in 6 gezeigt ist, baut der HSS selbst diese Nachricht
(SIP-Nachricht: 401 NICHT BERECHTIGT) auf und sendet er
sie in Schritt 603 zur UE2 (wobei deren Adresse, oder die
Adresse jedes beliebigen anderen Knotens, der beim Signalisieren
vermittelt, im HSS bekannt sein kann, zum Beispiel, wenn sie in
der vorhergehenden Anforderung – Auth.Anf. – enthalten war,
oder wenn sie in jeder beliebigen früher erhaltenen Anfrage oder
Anforderung enthalten war).
-
Um
gemäß der HTTP-Digest-Authentifizierung
eine passende Antwort (RES) aufzubauen, muss die Authentifizierungslogik,
die im Endgerät UE2
tätig ist,
neben anderen Daten einige geheime Daten im Zusammenhang mit ihrem
Benutzer kennen, und muss sie genauer die Kombination aus Benutzername
und Kennwort des Benutzers kennen. Zu diesem Zweck kann sie den
Benutzer (durch eine Benutzerschnittstelle wie etwa ihre Anzeige)
auffordern, diese geheimen Daten einzugeben. Alternativ könnte das
Endgerät
diese geheimen Daten früher von
einer vorhergehenden Benutzereingabe gespeichert haben und kann
es den Benutzer zum Beispiel auffordern, eine persönliche Identifikationsnummer (d.h.,
ein weiteres, zwischen dem Benutzer und dem Endgerät geteiltes
Geheimnis, das verwendet wird, um einige Vorgänge lokal zu authentifizieren)
einzugeben, um ihre Verwendung zu gestatten. Sobald diese geheimen
Daten (z.B., Benutzername = John_Doe; Kennwort = a1B2c3) dem Endgerät UE2 verfügbar sind,
berechnet es unter Verwendung eines wohlbekannten Nachrichtenextraktalgorithmus wie
etwa MD5 (IETF RFC1321, April 1992) oder SHA-1 (Secure Hash Algorithm;
NIST, 180-1, April 1995) dieses Geheimnisses, der mit dem gesamten Inhalt
der erhaltenen Authentifizierungszeichenfolge (STR) und mit anderen
zusätzlichen
Daten (wie etwa einer Bereichskennung) verknüpft ist, die Antwort. Das Ergebnis
des Extraktalgorithmus (RES), das eine Funktion des durch den Benutzer
bereitgestellten Geheimnisses und der Authentifizierungszeichenfolge
(STR) (in 5 und 6 als "f{usr-ID, Passw,
STR} angegeben) ist, wird in Schritt 505 von 5,
oder Schritt 604 von 6, in einer
neuen Registrierungsanforderung, REGISTRIEREN, gesendet.
-
Nach
der in 5 gezeigten Alternative, bei der die S-CSCF in
den Authentifizierungsvorgang eingreift, entpackt diese die Nachricht
und fordert sie in Schritt 506 die Authentifizierung dieses
Benutzers vom HSS (Auth.Anf.). Die in diesem Fall gesendete Nachricht
befördert
neben anderen Daten eine oder mehrere Benutzerkennungen (ID), die
in REGISTRIEREN erhalten wurden, wie auch die erhaltene Authentifizierungsantwort
(RES).
-
In
der in 6 gezeigten alternativen Ausführungsform trifft die neue
Registrierungsnachricht beim HSS ein (Schritt 604), der
sie direkt entpackt und interpretiert.
-
Um
zu bestimmen, ob die erhaltene Antwort (RES) die gültige ist,
muss der HSS den gleichen Extraktalgorithmus über die gleichen Daten durchführen, wie
dies das Endgerät
UE2 getan hat. Zu diesem Zweck kann der HSS über Zugriff auf die Benutzer-ID und
das Kennwort dieses Benutzers so, wie sie sind (d.h., deutlich),
oder auf das entsprechende Ergebnis des Extraktalgorithmus über diese
geheimen Daten verfügen
(wobei diese letztere Option sicherer ist, da sie gestattet, dass
die Kombination aus der Benutzer-ID und dem Kennwort in keinerlei
Knoten deutlich gespeichert ist).
-
Da
die S-CSCF die Einheit sein wird, die den Benutzer hinsichtlich
des angeforderten Diensts bedienen wird, muss sie über die
Authentifizierung des Benutzers für die erhaltene Anforderung
informiert werden. Wenn der Benutzer im HSS erfolgreich authentifiziert
ist, kann der HSS daher eine Antwort (Auth.Antw.) (in 5 oder 6 nicht
gezeigt) zur S-CSCF senden, die angibt, dass der Benutzer eine gewährte Authentifizierung
für die
vorher erhaltene Anforderung (Auth.Anf.) erhalten hat. Anschließend (doch
in 5 oder 6 nicht gezeigt), und zum Zweck
der Übereinstimmung
mit bestehenden Regeln im IMS eines 3G-Systems, kann die S-CSCF dem HSS für diese
bestimmte Dienstanforderung (Registrierung) eine Angabe (aktualisiere
Standort) senden, die angibt, dass insbesondere diese S-CSCF (z.B.
scsf5.homeABC.net) diesen Benutzer hinsichtlich von IM-Diensten bedient.
Wie vorher unter Bezugnahme auf 4 angeführt würde dies
weitere Schritte auslösen,
worin das Benutzerprofil vom HSS zur S-CSCF heruntergeladen wird,
und worin das Endgerät
UE2 eine Bestätigung
der Registrierung erhält.