DE602004012103T2

DE602004012103T2 - Verfahren zum verteilen von passwörtern

Info

Publication number: DE602004012103T2
Application number: DE602004012103T
Authority: DE
Inventors: Vesa Matti Torvinen; Monica Wifvesson; Alfredo Gonzalez-Plaza
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2003-06-27
Filing date: 2004-06-24
Publication date: 2009-03-12
Anticipated expiration: 2024-06-25
Also published as: KR20060032602A; WO2005002166A2; DE602004012103D1; RU2006102352A; CN1813455A; GB0314971D0; ATE387795T1; RU2325774C2; EP1639782A2; ES2300792T3; WO2005002166A3; US20070005730A1; CN100556033C; EP1639782B1

Description

Gebiet der Erfindung
Die Erfindung betrifft ein Verfahren zum Verteilen von Passwörtern. Insbesondere betrifft die Erfindung, obwohl nicht nur, ein Verfahren zum Erzeugen eines Passworts zur Verwendung bei einem Endbenutzergerät zum Zugreifen auf einen entfernten Server bzw. Remote Server, wobei das Passwort beibehalten wird für eine nachfolgende Verwendung.
Hintergrund der Erfindung
Die Erzeugung und Verteilung von Endbenutzerpasswörtern für Anwendungen und Anwendungproxis ist problematisch. Auf der einen Seite tendieren Endbenutzer dazu, Passwörter zu erzeugen, die einfach und kurz sind, und deshalb mit dem Risiko einhergehen, dass sie aufgedeckt werden durch unautorisierte Dritte. Andererseits ist ein Herausfinden der Beziehung zwischen Endbenutzeridentitäten und ihren Passwörtern oft unsicher und teuer.
Es gibt Mechanismen, die die Wiederverwendung von vorexistierenden Passwörtern erlauben zwischen verschiedenen Trust-Domains bzw. Domains, denen vertraut wird, wie zum Beispiel Single-Sign-On-Lösungen, die entwickelt wurden von der Liberty Alliance. Jedoch ist es oft notwendig, sich auf eine dritte Person zu verlassen, Zum Ausführen der Authentifizierung. Wenn solch eine Anordnung verwendet wird, nimmt der Dienstanbieter nicht aktiv in der Authentifizierung teil. Andererseits ist die durch den Dienstanbieter ausgeführte Passwortverwaltung nicht immer passend, weil das Handhaben der Passwörter in Anwendungsservern bzw. Application-Servern komplexe und teuere Verwaltungsverfahren benötigt, beispielsweise Aufrechterhalten der Passwortlebenszeiten, Überlappen von Passwortwerten, Regelungen hinsichtlich gültiger Werte und so weiter. Zusätzlich wollen sich Endbenutzer nicht viele Passwörter merken, und sie tendieren zur Verwendung der gleichen Passwörter mit mehreren Anwendungsservern, was klarerweise die Höhe an Sicherheit verringert.
Die Hypertext-Transfer-Protocol-(HTTP)-Digest-Authentifizierungsgrundstruktur, wie in dem IETF-Dokument RFC 2617 beschrieben, kann Verfahren enthalten, die in der Lage sind, Endbenutzerpasswörter zu erzeugen. Beispielsweise ist eine HTTP-Digest-Authentifizierung, die eine Authentifizierung und Schlüsselübereinstimmung (AKA, Key Agreement) verwendet, wie in RFC 3310 beschrieben, ein Verfahren zum Erzeugen von Endbenutzerpasswörtern unter Verwendung einer existierenden Third-Generation-(3GPP)-Authentifizierungsinfrastruktur, basierend auf AKA-Berechtigungsnachweisen, die gespeichert werden auf einem sabotagesicheren Gerät, der sogenannten ISIM/USIM/SIM-Karte. Details der obigen Grundstrukturen können auf http://www.ietf.org/rfc.html gefunden werden. Selbst wenn die HTTP-Digest-AKA einen flexiblen Weg bereitstellt zum Erzeugen von frischen Passwörtern ohne Benutzerinvolvierung, enthält es keinen Standardweg zum Delegieren dieser Passwörter an Dritte, wie zum Beispiel Anwendungsserver oder Proxies. Ferner nimmt HTTP-Digest-AKA an, dass die Passwörter nur einmal benutzt werden können.
Angabe der Erfindung
Es ist eine Aufgabe der Erfindung, die obigen Probleme zu bewältigen oder mindestens abzuschwächen. Insbesondere ist es eine Aufgabe der vorliegenden Erfindung, die Passwörter zu delegieren, die erzeugt werden unter Verwendung von HTTP-Digest-AKA an einen Dritten, so dass die Passwörter sicher verwendet werden können für eine nachfolgende Authentifizierung.
Diese und andere Aufgaben werden erreicht durch die Anfangsauthentifizierung, die durchgeführt wird zwischen dem Endbenutzergerät und seinem Heimnetzwerk, unter Verwendung von HTTP-Digest mit einem Algorithmus, der in der Lage ist, Passwörter zu generieren, beispielsweise HTTP-Digest-AKA. Während der Anfangsauthentifizierung initiiert das Heimnetzwerk einen Prozess, in dem das neue Passwort verbunden wird mit der Identität des Dritten, wie zum Beispiel einem Anwendungsserver oder einem Proxy, und mit einer neuen temporären Endbenutzeridentität für diesen Dritten. Das Endbenutzergerät und der Dritte können anfangen, das neue Passwort zu verwenden, und in Bezug stehende Identitäten unter Verwendung von HTTP-Digest als ein Authentifizierungsverfahren.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Erzeugen eines Passworts bereitgestellt für eine Verwendung durch ein Endbenutzergerät (UE), um auf einen entfernten Server zuzugreifen, umfassend:
Senden einer Anforderung für eine Zugriff von dem UE auf den entfernten Server;
Erzeugen einer temporären Identität für das UE;
Senden eines Authentifizierungsknotens in dem Heimnetzwerk des UE von Details der Anforderung für einen Zugriff;
bei dem Authentifizierungsknoten oder dem entfernten Server, Erzeugen einer Hypertext-Transfer-Protokoll-(HTTP)-Digest-Aufforderung, unter Verwendung eines Algorithmus, der in der Lage ist,
Endbenutzerpasswörter zu erzeugen, einschließlich Details über die temporäre Identität des UE;
bei dem UE, Erzeugen eines Passworts, basierend auf der HTTP-Digest-Aufforderung, wobei das Passwort im Zusammenhang steht mit der Identität des entfernten Servers und der Identität des UE; und
Speichern des Passworts und der temporären Identität des UE bei dem UE.
Der Algorithmus zum Erzeugen von Endbenutzerpasswörtern ist bevorzugt HTTP-Digest-Authentifizierung und Schlüsselübereinstimmung (AKA, Authentication and Key Agreement), obwohl es erkannt wird, dass andere Algorithmen verwendet werden können.
Bevorzugt wird die Identität: des entfernten Servers gesendet an den Authentifizierungsknoten, was die Erzeugung der HTTP-Digest-Challenge bzw. HTTP-Digest-Aufforderung ermöglicht, um die Identität des entfernten Servers einzuschließen. Die Identität des entfernten Servers ist bevorzugt auf dem UE gespeichert.
Die temporäre Identität des UE wird bevorzugt erzeugt bei dem entfernten Server.
In einer Ausführungsform kann der Schritt eines Sendens von Details der Anforderung für einen Zugriff auf den Authentifizierungsknoten Umlenken der Anforderung für einen Zugriff auf den Authentifizierungsknoten enthalten. Die HTTP-Digest-Challenge kann dann erzeugt werden bei dem Authentifizierungsknoten, und von dem Authentifizierungsknoten direkt an das UE gesendet werden. Das Passwort wird bevorzugt gespeichert bei dem Authentifizierungsknoten.
Nachdem das Passwort erzeugt wurde, wird das UE bevorzugt authentifiziert bei dem Authentifizierungsknoten und die Anforderung für einen Zugriff umgeleitet von dem Authentifizierungsknoten zurück an den entfernten Server.
In einer alternativen Ausführungsform kann der Schritt eines Sendens von Details der Anforderung für einen Zugriff auf den Authentifizierungsknoten enthalten, dass der entfernte Server direkt den Authentifizierungsknoten kontaktiert. Die HTTP-Digest-Challenge kann erzeugt werden bei dem Authentifizierungsknoten und gesendet werden von dem Authentifizierungsknoten an den entfernten Server. Alternativ kann der entfernte Server die HTTP-Digest-Challenge erzeugen. Die HTTP-Digest-Challenge wird dann direkt gesendet von dem entfernten Server an das UE.
Ein HTTP-Digest-AKA-Challenge-Passwort kann enthalten sein in der Information, die gesendet wird von dem Authentifizierungsknoten an den entfernten Server, was dem UE ermöglicht, authentifiziert zu werden bei dem entfernten Server. Alternativ kann das UE authentifiziert werden bei dem Authentifizierungsknoten, und ein Authentifizierungsergebnis kann zurückgegeben werden an den entfernten Server.
Die oben beschriebenen Verfahren resultieren in einem Passwort, das im Zusammenhang steht mit der Identität des UE und dem entfernten Server, und gespeichert wird bei dem UE und dem Authentifizierungsknoten oder entfernten Server. Dies ermöglicht nachfolgenden Zugriff von dem UE auf den entfernten Server ohne den Bedarf zum Erzeugen eines weiteren Passworts. Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zum Zugreifen auf einen entfernten Server von einem Endbenutzergerät bereitgestellt, wobei das Verfahren umfasst:
Erzeugen und Speichern eines Passworts unter Verwendung eines Verfahrens, wie oben beschrieben;
Senden einer Anforderung für einen Zugriff von dem UE auf den entfernten Server;
bei dem entfernten Server, Erzeugen einer HTTP-Digest-Challenge, einschließlich von Details der Identität des entfernten Servers und temporären Identität des UE und Senden der Challenge an das UE; und
bei dem UE, Senden einer Authentifizierungsantwort einschließlich der temporären Identität des UE, und ein Nachweis über einen Besitz des Passworts an den entfernten Server.
Falls das Passwort nicht bei dem entfernten Server gespeichert wird, kann es notwendig sein, eine Authentifizierungsanforderung von dem entfernten Server an den Authentifizierungsknoten zu senden. Das Passwort kann dann gesendet werden von dem Authentifizierungsknoten an den entfernten Server, was eine Authentifizierung des UE an dem entfernten Server ermöglicht. Alternativ kann das UE authentifiziert werden an dem Authentifizierungsknoten und eine Bestätigung der Authentifizierung kann gesendet werden von dem Authentifizierungsknoten an den entfernten Server.
Kurze Beschreibung der Zeichnungen
1 zeigt eine schematische Darstellung eines Netzwerks.
2A stellt eine Sequenz für eine Passworterzeugung und eine Identitätsübereinstimmung zwischen einem Endbenutzergerät (UE) und Anwendungsserver dar.
2B stellt eine alternative Sequenz für eine Passworterzeugung und Identitätsübereinstimmung zwischen einem Endbenutzergerät (UE) und Anwendungsserver dar.
3 stellt die Sequenz dar, involviert in der Verwendung eines neuen Passworts.
Während die Erfindung anwendbar ist auf verschiedene Modifizierungen und alternative Formen, wurden spezifische Ausführungsformen derselben mittels Beispielen in den Zeichnungen gezeigt, und werden hierin detailliert beschrieben. Es sollte verstanden werden, dass jedoch diese Spezifizierung nicht vorgesehen ist, die Erfindung auf die bestimmten Formen, die hierin offenbart sind, zu begrenzen, aber im Gegenteil dazu soll die Erfindung alle Modifizierungen, Äquivalente und Alternativen abdecken, die in den Umfang der Erfindung fallen, wie in den anhängenden Ansprüchen definiert.
Detaillierte Beschreibung der bevorzugten Ausführungsformen
1 stellt eine typische Anordnung dar, in der ein Endbenutzergerät (UE) 101, verbunden mit einem Heimnetzwerk 102, beispielsweise einem Universalmobiltelekommunikationssystem-(UMTS, Universal Mobile Telecommunications System)-Netzwerk, wünscht auf einen Anwendungsserver 103 zuzugreifen, der verbunden ist mit einem weiteren Netzwerk 104. Das UE 101 beinhaltet ein sabotageresistentes Gerät, wie zum Beispiel ein IP-Multimedia-Service-Identitätsmodul (ISIM, IP-Multimedia Services Identity Module), auf dem Information gespeichert werden kann. Gemäß der HTTP-Digest-Authentifizierungs- und Schlüsselübereinstimmungs-(AKA)-Grundstruktur wird ein gemeinsames Geheimnis vorher eingerichtet zwischen dem ISIM des UE 1 und einem Authentifizierer 105 in dem Heimnetzwerk 102. Das Geheimnis wird gespeichert in dem ISIM des UE 101.
Der Authentifizierer 105 erzeugt einen Authentifizierungsvektor, basierend auf dem gemeinsamen Geheimnis und einer Sequenznummer. Der Authentifizierungsvektor enthält eine Zufallsaufforderung bzw. Random Challenge, ein Netzwerkauthentifizierungs-Token, ein erwartetes Authentifizierungsergebnis, einen Session-Schlüssel für eine Integrity-Überprüfung und einen Session-Schlüssel für eine Verschlüsselung. Der Authentifizierungsvektor wird heruntergeladen auf den Anwendungsserver 103. Der Anwendungsserver 103 erzeugt eine Authentifizierungsanforderung, enthaltend die Random Challenge und das Netzwerkauthentifierer-Token, was geliefert wird an das UE 101.
Unter Verwendung des gemeinsamen Geheimnisses und der Sequenznummer verifiziert das UE 101 das Netzwerkauthentifizierungs-Token, enthalten in der Authentifizierungsanforderung mit dem ISIM. Falls die Verifizierung erfolgreich ist, wurde das Netzwerk authentifiziert. Das UE 101 produziert dann eine Authentifizierungsantwort unter Verwendung des gemeinsamen Geheimnisses und der Random Challenge, und liefert diese an den Anwendungsserver 103. Der Anwendungsserver 103 vergleicht die Authentifizierungsantwort, die empfangen wird von dem UE 101, mit der erwarteten Antwort, die empfangen wird von dem Authentifizierer 103. Falls die zwei übereinstimmen, wurde der Benutzer erfolgreich authentifiziert, und die Session-Schlüssel in dem Authentifizierungsvektor können verwendet werden zum Schützen weiterer Kommunikationsvorgänge zwischen dem UE 101 und dem Anwendungsserver 103. Jedoch muss, das nächste Mal, wenn das UE 101 wünscht, auf den Anwendungsserver 103 zuzugreifen, das gleiche Prozedere befolgt werden zum Authentifizieren des Netzwerks und Erhalten von Session-Schlüsseln; es gibt keinen Mechanismus zum Speichern eines Passworts für eine zukünftige Verwendung durch das UE 101.
2A zeigt eine Ausführungsform eines Systems zum Authentifizieren des UE 101 bei dem Anwendungsserver (AS) 103. In der ersten Phase wird das UE 101 authentifiziert unter Verwendung von HTTP-Digest-AKA und das erzeugte Passwort wird verbunden mit den Identitäten des Anwendungsservers 103 und dem UE 101. Um die Prozesse zu verstehen, die in 2A gezeigt werden, ist es notwendig, zwei Konzepte zu definieren, die verwendet werden in der HTTP-Digest-Authentifizierungsgrundstruktur.
Ein "Realm" ist ein String, der dem UE 101 kennzeichnet, welcher Benutzername und Passwort zu verwenden sind. Dieser String enthält mindestens den Namen des Authentifizierungscenters 103 und kann zusätzlich die Sammlung der Benutzer kennzeichnen, die Zugang haben können. Ein Beispiel kann sein registered users@home.com. In dem Kontext von 3GPP/AKA wird der Realm des Heimnetzwerks typischerweise gespeichert in der SIM/USIM/ISIM-Karte des UE 101.
Ein "Benutzername" (username) ist der Name des Benutzers in dem spezifizierten Realm. Dieser String wird verwendet durch den Anwendungsserver 103 zum Finden des korrekten Passworts für den Benutzer. In dem Kontext von 3GPP/AKA wird der Benutzername, der in dem Heimnetzwerk verwendet wird, typischerweise gespeichert in der SIM/USIM/ISIM-Karte des UE 101. In den meisten Fällen ist der Benutzername der gleiche, wie die sogenannte Private Identity (IMPI). Ein 3GPP-Benutzername identifiziert die Teilnahme, und aus diesem Grund sind die Passwörter spezifisch für das Endbenutzergerät eher als zu dem realen Endbenutzer. In einer normalen HTTP-Authentifizierungsgrundstruktur werden Benutzername und Passwort eingetippt durch den Endbenutzer, aber in dem Kontext von 3GPP/AKA werden diese Felder automatisch durch das UE 101 ausgefüllt.
Wie in 2A gezeigt, haben in der ersten Phase das UE 101 und der Anwendungsserver 103 kein gemeinsames Geheimnis. Das UE 101 wird anfangs authentifiziert unter Verwendung von HTTP-Digest-AKA, und das erzeugte Passwort wird verbunden mit den Identitäten des UE 101 und des Anwendungsservers 103. Das Prozedere weist die folgenden Schritte auf:

1a) Das UE 1 sendet eine HTTP-Anforderung (typischerweise HTTP GET) an den Anwendungsserver 103.
2a) Da der Anwendungsserver 103 und das UE 101 kein gemeinsames Geheimnis haben, leitet der Anwendungsserver 103 die Anforderung an den Authentifizierer 105 um. Vor einem Umleiten der Anforderung kann der Anwendungsserver 103 einen neuen temporären Benutzernamen für das UE 101 definieren. Der Anwendungsserver 103 enthält diesen Benutzernamen und seine eigene Identitätsinformation in der Anforderung. Die Identitätsinformation ist typischerweise codiert in dem URI-Parameter in einem Standardformat, beispielsweise username@realm.
3a) Der Authentifizierer 105 überprüft, um zu sehen, ob der Anwendungsserver 103 authentifiziert wird, für eine HTTP-Umleitung und fordert ein neues HTTP-Digest-AKA-Passwort an für das UE 101. Falls dies der Fall ist, nimmt dann der Authentifizierer 105 die Identitätsinformation von der Anforderung und codiert diese Information in einem HTTP-Digest-AKA-Challenge, was gesendet wird an das UE 101. In einer Ausführungsform gibt der Authentifizierer 105 die Identitätsinformation in die sogenannten "Serverdaten" des HTTP-Digest-AKA, wie in RFC 3310 beschrieben. Durch Einschließen der Identität in der Challenge, kann der Authentifizierer 105 sicher sein, dass die Identität des Anwendungsservers 103 oder die temporäre Identität des Endbenutzers nicht verändert werden kann durch irgendeine Partei (wie zum Beispiel ein Angreifer) zwischen dem UE 101 und dem Authentifizierer 103, weil die Aufforderung bzw. Challenge zurückgegeben wird an den Authentifizierer 105 in der nächsten Nachricht.
4a) Das UE 101 authentifiziert das Netzwerk (wie definiert in dem Standard-AKA-Protokoll) und erzeugt ein neues Passwort, basierend auf der HTTP-Digest-AKA-Challenge. Das UE 101 speichert lokal die Identität des Anwendungsservers 104 und das neuerzeugte Passwort, das später zu benutzen ist für gegenseitige Authentifizierung mit dem Anwendungsserver 103. Falls die Challenge, enthaltend auch einen neuen temporären "Benutzernamen", erzeugt durch den Anwendungsserver 103, wird auch dieser Benutzername mit dem Passwort und der Anwendungsserver-103-Identität gespeichert. Sowohl der Anwendungsserver, als auch die UE-Identitäten sind codiert in der HTTP-Digest-AKA-Challenge, beispielsweise unter Verwendung des Formats username@realm. Das UE 101 sendet die Authentifizierungsantwort an den Authentifizierer 103. Der neue "Benutzername" (username) wird markiert als ein temporärer Benutzername durch das UE 101. Dieser Benutzername und das in Bezug stehende HTTP-Digest-AKA-Passwort wird entfernt, wenn ein neuer "Benutzername" und Passwort erzeugt werden für den gleichen Realm. Falls die Challenge nicht einen neuen temporären Benutzernamen enthält, dann kann der existierende Benutzername wieder verwendet werden.
5a) Der Authentifizierer 105 authentifiziert das UE 101 und falls erfolgreich, speichert das neue Passwort und die Identitäten des UE 101 und des Anwendungsservers 103, was später zu verwenden ist. Die Anforderung wird umgeleitet zurück an den Anwendungsserver 103.

Falls es passt, kann der Anwendungsserver 103 der Anfangsauthentifizierung vertrauen, die ausgeführt wird durch den Authentifizierer 105. Falls der Authentifizierer 105 nicht als sicher wahrgenommen wird, kann der Anwendungsserver 103 auch neu das UE 101 abfragen, nun unter Verwendung des neu erzeugten Passworts. Dieses Mal wird HTTP-Digest-AKA nicht verwendet zur Authentifizierung. Anstatt dessen wird HTTP-Digest mit einem anderen Algorithmus verwendet, beispielsweise MD 5 kann verwendet werden, wie in RFC 2617 beschrieben.
2B zeigt eine alternative Ausführungsform eines Systems zum Authentifizieren des UE 101 an dem Anwendungsserver (AS) 103. Die erste Phase wird ausgeführt unter Verwendung eines unterschiedlichen Prozederes mit den folgenden Schritten:

1b) Das UE 1 sendet eine HTTP-Anforderung (typischerweise HTTP GET) an den Anwendungsserver 103.
2b) Da der Anwendungsserver 103 und UE 101 kein gemeinsames Geheimnis haben, fordert der Anwendungsserver 103 eine HTTP-Digest-AKA-Authentifizierungs-Challenge (Abfrage) direkt von dem Authentifizierer 105 an. Wie in der vorher beschriebenen Ausführungsform kann die Anforderung die Identität des Anwendungsservers 103 und eine neue temporäre Identität des UE 101 enthalten.
3b) Der Authentifizierer 105 überprüft, um zu sehen, ob der Anwendungsserver 103 autorisiert ist zum Anfordern eines neuen HTTP-Digest-AKA-Passworts für dieses UE 101. Falls dies der Fall ist, nimmt dann der Authentifizierer die Identität des Anwendungsservers und die temporäre Identität des Endbenutzers (falls vorhanden) von der Anforderung und codiert diese Information in der HTTP-Digest-AKA-Challenge, wie in dem vorher beschriebenen Ausführungsformen. Alternativ kann der Anwendungsserver 103 auch diese Information für die Challenge enthalten in Schritt 4b, die unten beschrieben ist. Identitätsinformation ist codiert in einem Standardformat, beispielsweise username@realm oder temporary username@remote realm. Von dem Anwendungsserver 103 benötige Information zum Erzeugen der HTTP-Digest-AKA-Challenge wird zurückgesendet an den Anwendungsserver 103. Falls diese Parameter das HTTP-Digest-AKA-Passwort enthalten, können die Prozessschritte 6b) und 7b) unten nicht benötigt werden.
4b) Das UE 101 wird abgefragt durch ein HTTP-Digest-AKA-Authentifizierungs-Challenge. Der Anwendungsserver 103 kann den Anwendungsserver und Endbenutzeridentitäten hinzufügen an den Authentifizierungs-Challenge vor einem Senden des Challenge an das UE 101. Jedoch muss in diesem Fall der Anwendungsserver 103 der Endpunkt für die Authentifizierung sein, und besitzt das HTTP-Digest-AKA-Passwort.
5b) Das UE 101 authentifiziert das Netzwerk (wie definiert in Standard-AKA-Protokoll) und erzeugt ein neues Passwort, basierend auf dem HTTP-Digest-AKA-Challenge. Das UE speichert lokal die Identität des Anwendungsservers 103 (beispielsweise den "Realm"), das neu erzeugte Passwort und den neuen temporären "Benutzernamen" für sich selbst (falls vorhanden), der später zu verwenden ist durch den Anwendungsserver 103 für gegenseitige Authentifizierung mit dem Anwendungsserver – falls vorhanden. Das UE 101 sendet die Authentifizierungsantwort an den Anwendungsserver 103. Wie in der vorher beschriebenen Ausführungsform markiert das UE 101 den potentiellen neuen "Benutzernamen" als temporären Benutzernamen.
6b) Falls der Anwendungsserver 103 das Endbenutzerpasswort nicht empfangen hat in Schritt 3b oben, fordert er nun den Authentifizierer auf zum Ausführen der Authentifizierung.
7b) Falls der Anwendungsserver 103 das Endbenutzerpasswort nicht empfangen hat in Schritt 3b oben, und er eine Authentifizierung in Schritt 6b angefordert hat, authentifiziert der Authentifizierer 105 das UE 101 und gibt das passende Ergebnis an den Anwendungsserver 103. Der Authentifizierer 105 kann auch das Endbenutzerpasswort an den Anwendungsserver 103 bei dieser oder einer späteren Stufe senden.
8b) Falls die UE-Authentifizierung erfolgreich war, wird der Dienst geliefert an das UE 101.

Entweder die Prozeduren folgend, die oben mit Bezug auf 2A oder 2B beschrieben wurden, resultiert darin, dass der Anwendungsserver 103 und das UE 101 ein gemeinsames Geheimnis haben. Das nächste Mal, dass der Anwendungsserver 103 das UE 101 authentifizieren muss (was direkt nach den vorherigen Prozederes sein kann, oder nach einer längeren Zeitperiode, beispielsweise das nächste Mal, wenn das UE 101 den Anwendungsserver 103 kontaktiert), ist das Prozedere, wie in 3 gezeigt.

1c) Das UE 101 sendet eine HTTP-Anforderung (typischerweise HTTP GET) an einen Anwendungsserver 103.
2c) Da der Anwendungsserver 103 und das UE 101 kein gemeinsames Geheimnis haben, fragt der Anwendungsserver 103 das UE 101 ab mit einem HTTP-Digest-Challenge. Die Challenge enthält die Identität des Anwendungsservers 103 in dem "Realm"-Parameter.
3c) Das UE 101 sendet eine Authentifizierungsantwort (typischerweise in HTTP GET-Anforderung) zurück an den Anwendungsserver 103 unter Verwendung des neuen "Benutzernamens" und Passworts für den Anwendungsserver 103, erzeugt während der vorherigen Phase (oben beschrieben mit Bezug auf 2b oder 2c). Falls der neue temporäre Benutzername nicht erzeugt wurde, dann wird der normale AKA-spezifische Benutzername verwendet. Das UE 101 verwendet den "Realm"-Parameter zum Identifizieren des korrekten Passworts.
4c) Falls der Anwendungsserver 103 das Endbenutzerpasswort besitzt, werden dieser Schritt und der folgende Schritt 5c) nicht benötigt. Falls der Anwendungsserver 103 das Endbenutzerpasswort nicht besitzt, dann fordert der Anwendungsserver 103 von dem Authentifizierer 105 an (oder eine andere Netzwerkentität (nicht gezeigt), wo der Authentifizierer 105 das UE-spezifische Passwort gespeichert hat) für eine Authentifizierung.
5c) Es gibt zwei verschiedene Möglichkeiten bei dieser Stufe. Der Authentifizierer 105 kann sich um die Authentifizierung für den Anwendungsserver 103 kümmern. In diesem Fall braucht der Anwendungsserver 103 nicht das Passwort zu kennen, und der Authentifizierer gibt einfach Information an den Anwendungsserver 103, ob oder ob nicht Authentifizierung erfolgreich war. Alternativ kann der Authentifizierer 105 das Passwort an den Anwendungsserver 103 senden, der dann die Authentifizierung ausführt.

Falls die Authentifizierung erfolgreich war, liefert der AS den Dienst an das UE.
Es wird verstanden werden, dass Variationen von den oben beschriebenen Ausführungsformen noch immer in den Umfang der Erfindung fallen können. Beispielsweise, wie in RFC 2617 bemerkt, braucht der Authentifizierer nicht tatsächlich das Klartextpasswort des Benutzers zu kennen. Solange der verarbeitet Wert des Benutzernamens, Realms und Passwort verfügbar ist für den Server, kann die Gültigkeit eines Authentifizierungs-Headers verifiziert werden.

Claims

Ein Verfahren zum Erzeugen eines Passworts zur Verwendung durch ein Endbenutzergerät, UE, zum Zugreifen auf einen entfernten Server, umfassend: Senden einer Anforderung für einen Zugriff von dem UE auf den entfernten Server; Erzeugen einer temporären Identität für das UE; Senden an einen Authentifizierungsknoten in dem Heimnetzwerk des UE Details von der Anforderung für einen Zugriff; bei dem Authentifizierungsknoten oder dem entfernten Server, Erzeugen einer Hypertext-Transferprotokoll-HTTP-Aufforderung, unter Verwendung eines Algorithmus, der in der Lage ist, Endbenutzerpasswörter zu generieren, einschließlich von Details über die temporäre Identität des UE; bei dem UE, Erzeugen eines Passworts, basierend auf der HTTP-Aufforderung, wobei das Passwort im Zusammenhang steht mit der Identität des entfernten Servers und der Identität des UE; und Speichern des Passworts und der temporären Identität des UE bei dem UE.
Ein Verfahren, wie in Anspruch 1 beansprucht, wobei der Algorithmus, der in der Lage ist zum Erzeugen von Endbenutzerpasswörtern, eine HTTP-Digest-Authentifizerung und Key-Agreement, AKA, ist.
Ein Verfahren, wie in Anspruch 1 oder 2 beansprucht, ferner umfassend Senden der Identität des entfernten Servers an den Authentifizierungsknoten, wobei der Schritt eines Erzeugens der HTTP-Digest-Aufforderung enthält, ein Verwenden der Identität des entfernten Servers, und wobei die Identität des entfernten Servers gespeichert wird bei dem UE.
Ein Verfahren, wie in Anspruch 1, 2 oder 3 beansprucht, wobei die temporäre Identität des UE erzeugt wird bei dem entfernten Server.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, wobei der Schritt eines Sendens von Details über die Anforderung zum Zugriff auf den Authentifizierungsknoten Umleiten der Anforderung zum Zugreifen auf den Authentifizierungsknoten enthält.
Ein Verfahren, wie in Anspruch 5 beansprucht, wobei die HTTP-Digest-Aufforderung erzeugt wird bei dem Authentifizierungsknoten und gesendet wird von dem Authentifizierungsknoten direkt an das UE.
Ein Verfahren, wie in Anspruch 5 oder 6 beansprucht, wobei das Passwort gespeichert wird bei dem Authentifizierungsknoten.
Ein Verfahren, wie in Anspruch 5, 6 oder 7 beansprucht, ferner umfassend Authentifizieren des UE bei dem Authentifizierungsknoten, und Umleiten der Anforderung zum Zugriff von dem Authentifizierungsknoten zurück zu dem entfernten Server, nachdem das Passwort erzeugt wurde.
Ein Verfahren, wie in einem der Anspruche 1 bis 4 beansprucht, wobei der Schritt eines Sendens von Details über die Anforderung zum Zugreifen auf den Authentifizierungsknoten enthält, dass der entfernte Server den Authentifizierungsknoten direkt kontaktiert.
Ein Verfahren, wie in Anspruch 9 beansprucht, wobei die HTTP-Digest-Aufforderung erzeugt wird bei dem Authentifizierungsknoten und gesendet wird von dem Authentifizierungsknoten an den entfernten Server.
Ein Verfahren, wie in Anspruch 9 beansprucht, wobei die HTTP-Digest-Aufforderung erzeugt wird bei dem entfernten Server.
Ein Verfahren, wie in Anspruch 10 oder 11 beansprucht, ferner umfassend ein Senden der HTTP-Digest-Aufforderung von dem entfernten Server an das UE.
Ein Verfahren, wie in Anspruch 11 beansprucht, ferner umfassend, dass ein HTTP-Digest-AKA-Aufforderungspasswort in der Information enthalten ist, die gesendet wird von dem Authentifizierungsknoten an den entfernten Server und Authentifizieren des UE bei dem entfernten Server.
Ein Verfahren, wie in einem der Ansprüche 9 bis 12 beansprucht, ferner umfassend Authentifizieren des UE bei dem Authentifizierungsknoten und Zurückgeben eines Authentifizierungsergebnisses an den entfernten Server.
Ein Verfahren zum Zugreifen eines entfernten Servers von einem Endbenutzergerät, UE, wobei das Verfahren umfasst: Erzeugen und Speichern eines Passworts unter Verwendung eines Verfahrens, wie in einem der vorhergehenden Ansprüche beansprucht; Senden einer Anforderung zum Zugriff von dem UE an den entfernten Server; bei dem entfernten Server, Erzeugen einer Hypertext-Transfer-Protokoll, HTTP, Digest-Aufforderung, die Details über die Identität des entfernten Servers enthält, und Senden der Aufforderung an das UE; und bei dem UE, Senden einer Authentifizierungsantwort, die die temporäre Identität des UE enthält, sowie einen Nachweis über einen Besitz des Passworts, an den entfernten Server.
Ein Verfahren, wie in Anspruch 15 beansprucht, ferner umfassend Senden einer Authentifizierungsanforderung von dem entfernten Server an den Authentifizierungsknoten, Senden des Passworts von dem Authentifizierungsknoten an den entfernten Server, und Authentifizieren des UE bei dem entfernten Server.
Ein Verfahren, wie in Anspruch 15 beansprucht, ferner umfassend Senden einer Authentifizierungsanforderung von dem entfernten Server an den Authentifizierungsknoten, Authentifizieren des UE bei dem Authentifizierungsknoten, und Senden einer Bestätigung der Authentifizierung von dem Authentifizierungsknoten an den entfernten Server.