-
Technisches Gebiet
-
Die Erfindung betrifft ein Verfahren zur Authentifikation eines Benutzers gegenüber Ressourcen-Anbietern, die über mindestens ein Kommunikationsnetz miteinander verbunden sind, wobei zwischen dem Benutzer und einem ersten Ressourcen-Anbieter eine Authentifikation stattfindet, welche mindestens dem ersten Ressourcen-Anbieter die Identität des Benutzers nachweist, wobei bei der Authentifikation zwischen dem Benutzer und dem ersten Ressourcen-Anbieter Kontextdaten, die mindestens die Identität des Benutzers enthalten, und vom Benutzer eine Signatur der Kontextdaten erstellt werden und dass die Kontextdaten und die Signatur bei Bedarf von dem ersten Ressourcen-Anbieter jeweils einem weiteren Ressourcen-Anbieter zur Authentifikation des Benutzers gegenüber dem weiteren Ressourcen-Anbieter übermittelt werden, wobei der weitere Ressourcen-Anbieter die Signatur mit Hilfe eines öffentlichen Schlüssels des Benutzers prüft.
-
Stand der Technik
-
Zur Benutzung von verschiedenen Ressourcen über Kommunikationsnetze ist eine Authentifikation des Benutzers immer dann erforderlich, wenn der Zugang zu den Ressourcen nur bestimmten Benutzern gewährt werden soll oder wenn die Benutzung kostenpflichtig ist. Dabei können unterschiedliche Typen von Ressourcen-Anbietern involviert sein, beispielsweise Anbieter von Zugangsnetzen, Internet-Service-Provider, Anbieter von Location-Based-Services, Anbieter von Plattformen, Anbieter von Anwendungsdiensten, wie beispielsweise E-Mail-Dienste oder Informationsdienste, beispielsweise Datenbanken – im Folgenden auch Parteien oder Anbieter genannt. In der Praxis kann es erforderlich sein, dass sich ein Benutzer bei mehreren bzw. allen diesen Anbietern authentifizieren muss.
-
Diese mehrfache Authentifikation kann nachteilig sein, insbesondere wenn die Authentifikation einen relativ großen Rechenaufwand im Endgerät des Benutzers bedeutet und somit zeitraubend ist. Um diesen Nachteil zu vermeiden, ist ein Verfahren bekannt geworden, bei welchem ein einziger Authentifikationsvorgang die Authentifikation des Benutzers gegenüber mehreren Parteien ermöglicht, ohne dass hierzu weitere Interaktionen zur Authentifikation von Seiten des Benutzers bzw. seines Endgerätes – im folgenden der Einfachheit halber auch Benutzer genannt – erforderlich sind. Ein solches Verfahren nennt man Single Sign-on (SSO). Dabei erfolgt eine Authentifikation zwischen dem Benutzer und einer ersten Partei – im folgenden auch Authentifizierer genannt.
-
Eine Umsetzung eines derartigen Verfahrens im Zusammenhang mit der Verwaltung von mehreren Aufgaben, die von einer Verwaltungseinrichtung für einen Benutzer an verschiedene Ressourcen übertragen werden, ist beispielsweise aus
US 2005/0117587 A1 bekannt.
-
Will der Benutzer Ressourcen anderer Parteien verwenden, erzeugt der Authentifizierer eine SSO-Nachricht, in der eine von ihm erzeugte Signatur enthalten ist. Die weiteren Parteien müssen hierbei dem Authentifizierer dahingehend vertrauen, dass es sich bei dem Benutzer tatsächlich um die Identität handelt, welche der Authentifizierer angibt. Die weiteren Parteien müssen dieser Aussage jedoch immer glauben, da sie keine Möglichkeit haben, dies zu überprüfen. Durch eine Signatur des Authentifizierers in der SSO-Nachricht kann nur sichergestellt werden, dass die SSO-Nachricht tatsächlich vom Authentifizierer stammt. Genau genommen kann der Authentifizierer jedoch alles behaupten. Ein solches SSO-System hängt also davon ab, ob die weiteren Parteien den Authentifizierer gut kennen und ob sie ihm hinsichtlich der Korrektheit der von ihm erzeugten SSO-Nachrichten vertrauen.
-
Dieses Verfahren ist beispielsweise auch beschrieben in Thomas Wason: Liberty ID-FF Architecture Overview (Version: 1.2), 2003, http://www.projectliberty.org/specs.
-
Bei diesem bekannten Verfahren ist es jedoch möglich, dass der Authentifizierer den anderen Parteien mit Erfolg eine falsche Benutzer-Identität vorspiegelt.
-
Bei einem Verfahren der eingangs genannten Gattung (Gasser, M., et al., An Architecture for Practical Delegation in a Distributed System, IEEE, 1990, Seiten 20–30) wird nicht das Vertrauen der Ressourcen-Anbieter in den Authentifizierer vorausgesetzt, da die SSO-Nachricht von dem Benutzer erzeugt und signiert wird. Eine Überprüfung der Signatur des Benutzers durch die Ressourcen-Anbieter ist demzufolge grundsätzlich möglich. Die Ressourcen-Anbieter haben jedoch keine Möglichkeit, auf die SSO-Nachricht Einfluss zu nehmen. Eine Weiterleitung (Roaming) einer bestehenden Mobilfunkverbindung von einem ersten Provider (Ressourcen-Anbieter) zu einem zweiten Provider (Ressourcen-Anbieter) ist deshalb ohne die erneute Zustimmung des Benutzers zu dem zweiten Provider oder ohne ein Vertrauen der Provider untereinander nicht möglich.
-
Aufgabe der Erfindung ist es demzufolge, ein Verfahren der eingangs genannten Gattung so auszugestalten, dass auch eine Weiterleitung einer Anfrage zwischen einzelnen Ressourcen-Anbietern in einfacher Weise ermöglicht wird, ohne dass eine erneute Bestätigung durch den Benutzer erforderlich wird und ohne dass die einzelnen Ressourcen-Anbieter sich untereinander vertrauen müssen.
-
Darstellung der Erfindung
-
Diese Aufgabe wird erfindungsgemäß dadurch gelöst, dass die vom Benutzer zu signierenden Kontextdaten von dem ersten Ressourcen-Anbieter bestimmt werden.
-
Der öffentliche Schlüssel des Benutzers kann der weiteren Partei gleichzeitig oder auf anderen Wegen übermittelt werden bzw. der anderen Partei bereits bekannt sein. Die Kontextdaten und die Signatur der Kontextdaten werden im Folgenden auch SSO-Nachricht genannt.
-
Bei dem erfindungsgemäßen Verfahren muss der erste Ressourcen-Anbieter den anderen Ressourcen-Anbietern Daten präsentieren, die er keinesfalls selbst erzeugen kann und welche von den anderen Ressourcen-Anbietern hinsichtlich ihres Erzeugers überprüft werden können. Ferner wird durch das erfindungsgemäße Verfahren ausgeschlossen, dass der Authentifizierer die von den Benutzern erzeugten Identifikationsdaten mit Erfolg in einem anderen Zusammenhang wieder verwendet, um mit einem solchen Angriff einen Ressourcen-Anbieter eine falsche Identität vorspielen zu können.
-
Dadurch, dass die vom Authentifizierer an einen Ressourcen-Anbieter weitergegebene SSO-Nachricht die Identität des Benutzers enthält, kann der Ressourcen-Anbieter überprüfen, dass der Authentifizierer tatsächlich den entsprechenden Benutzer authentifiziert hat. Damit wird ausgeschlossen, dass ein Authentifizierer in der SSO-Nachricht eine falsche Benutzeridentität behaupten kann. Die Identität des Benutzers sollte hierzu in eindeutiger Weise angegeben werden, z. B. mittels eines Benutzerzertifikats.
-
Außerdem arbeitet das erfindungsgemäße Verfahren dadurch effizient, dass die erste Partei (der Authentifizierer) keine neue Signatur erzeugen muss, sondern die ohnehin zur Authentifikation erforderliche Signatur benutzt.
-
Eine vorteilhafte Weiterbildung des Verfahrens besteht darin, dass die Kontextdaten ferner eine Zeitangabe der Authentifikation enthalten. Dadurch kann der Ressourcen-Anbieter überprüfen, ob die Authentifikation des Benutzers unmittelbar vor dem Zeitpunkt stattgefunden hat, an welchem er die SSO-Nachricht empfangen hat, oder ob es sich um eine Kopie einer alten SSO-Nachricht handelt. Dadurch ist es einem Ressourcen-Anbieter möglich zu erkennen, wenn eine unfaire Partei eine Kopie einer alten SSO-Nachricht einspielt.
-
Eine andere vorteilhafte Weiterbildung besteht darin, dass die Kontextdaten ferner Zufallswerte enthalten. Diese Weiterbildung erlaubt es Empfängern zu erkennen, ob es sich bei einer empfangenen SSO-Nachricht um eine neue SSO-Nachricht oder um die Kopie einer alten SSO-Nachricht handelt, welche bereits zu einem früheren Zeitpunkt empfangen wurde. Hierbei müssen die Zufallswerte aus einer genügend großen Menge entnommen werden, damit die Kollisionswahrscheinlichkeit entsprechend klein ist.
-
Zufallswerte werden bei jeder Authentifikation des Benutzers jeweils neu ausgewählt. Bei bestimmten Anfragen an Ressourcen-Anbieter, welche über Authentifizierer weitergeleitet werden, kann es erwünscht sein, dass ein Dienst über den Authentifizierer für jede stattgefundene Authentifikation des Benutzers nur genau einmal angefragt werden darf. Damit Kopien erkannt werden können, muss der Ressourcen-Anbieter die in den SSO-Nachrichten empfangenen Zufallswerte über einen bestimmten Zeitraum abspeichern.
-
Bei dem erfindungsgemäßen Verfahren kann vorgesehen sein, dass die Kontextdaten ferner die Identität der ersten Partei enthalten. Hierdurch kann der Ressourcen-Anbieter überprüfen, wer den Benutzer authentifiziert hat. Das bedeutet, dass ein Ressourcen-Anbieter die SSO-Nachricht nur dann akzeptieren sollte, wenn die Identität des Senders der SSO-Nachricht und die Identität des in der SSO-Nachricht behaupteten Authentifizierers übereinstimmen. Dadurch kann ausgeschlossen werden, dass Angreifer Kopien von SSO-Nachrichten verwenden und behaupten, sie hätten den Benutzer authentifiziert.
-
Das erfindungsgemäße Verfahren kann auch dadurch weitergebildet werden, dass die Kontextdaten ferner die Identitäten derjenigen weiteren Parteien enthalten, denen gegenüber die Authentifikation möglich sein soll. Dadurch kann ausgeschlossen werden, dass ein unfairer Authentifizierer erfolgreich SSO-Nachrichten zu Ressourcen-Anbietern schicken kann, welche nicht vom Benutzer gewünscht sind.
-
Eine andere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens besteht darin, dass die Kontextdaten ferner Informationen über das bei der Authentifikation gegenüber der ersten Partei verwendete Protokoll enthalten und/oder dass die Kontextdaten ferner Informationen über die bei der Authentifikation gegenüber der ersten Partei angewendeten kryptographischen Verfahren enthalten.
-
Hierdurch wird dem Ressourcen-Anbieter klar ersichtlich, wie die im Authentifizierungsverfahren erzeugte und ausgetauschte Signatur überprüft werden soll. Hängt die in der SSO-Nachricht enthaltene Signatur ebenfalls von den Bezeichnungen für das jeweils verwendete Protokoll und die Verfahren ab, so soll es einem unfairen Sender einer SSO-Nachricht nicht möglich sein, den Ressourcen-Anbieter durch fälschliches Behaupten anderer Protokolle und Verfahren erfolgreich zu überlisten.
-
Der Benutzer kann sich im Rahmen der Aushandlung von Verfahren mit dem Authentifizierer auch darauf einigen, welche Variante von potenziell mehreren SSO-Mechanismen zwischen Authentifizierer und Ressourcen-Anbieter verwendet werden soll. Dies kann beispielsweise dann gewünscht sein, wenn es für den SSO-Mechanismus unterschiedliche Varianten mit unterschiedlichen Sicherheitsniveaus gibt. Hängt die vom Benutzer berechnete Signatur von der Bezeichnung dieses Protokolls ab, dann kann der Ressourcen-Anbieter überprüfen, ob die Variante des von dem Authentifizierers gewählten SSO-Mechanismus mit der Variante des SSO-Mechanismus übereinstimmt, welcher von dem Benutzer vorgeschlagen wurde, wenn die Kontextdaten ferner Informationen über das bei der Erstellung, Übermittlung und Prüfung der Kontextdaten und der Signatur verwendete Protokoll enthalten.
-
Grundsätzlich kann es möglich sein, dass ein Ressourcen-Anbieter den Benutzern unterschiedliche Dienste/Ressourcen zur Verfügung stellt. In diesem Zusammenhang kann es von Vorteil sein, wenn gemäß einer anderen Weiterbildung die Kontextdaten ferner Bezeichnungen der Dienste enthalten, für welche jeweils eine Authentifikation gegenüber jeweils einer weiteren Partei gelten soll.
-
Vor diesem Hintergrund ist es im Interesse des Benutzers, wenn der in der SSO-Nachricht spezifizierte Dienst eines gewünschten Ressourcen-Anbieters von dem Benutzer entsprechend signiert ist. Dadurch kann der Ressourcen-Anbieter überprüfen, ob der über den Authentifizierer angefragte Dienst tatsächlich von dem Benutzer erwünscht ist. Sofern eine eindeutige Bezeichnung des Dienstes vom Benutzer bei der Signaturberechnung berücksichtigt wird, können unerwünschte Modifikationen in der vom Ressourcen-Anbieter empfangenen SSO-Nachricht erkannt werden. Der Ressourcen-Anbieter sollte dann ausschließlich die Nutzung des oder der Dienste gestatten, welche in der SSO-Nachricht spezifiziert sind.
-
Ein Ressourcen-Anbieter kann seine Dienste zu verschiedenen Bedingungen, z. B. mit unterschiedlicher Dienstqualität anbieten. Sollte es dem Benutzer möglich sein, unter diesen Bedingungen auszuwählen, so kann die Auswahl dem Ressourcen-Anbieter in der SSO-Nachricht dadurch mitgeteilt werden, dass die Kontextdaten ferner weitere Bedingungen bezüglich der Nutzung von Diensten enthalten. Auch hier ermöglicht es die Sicherung der Auswahl durch eine Signatur des Benutzers, dass der Ressourcen-Anbieter überprüfen kann, ob die in der SSO-Nachricht enthaltenen Bedingungen tatsächlich von dem Benutzer gewünscht sind.
-
Eine andere vorteilhafte Ausgestaltung der Erfindung besteht darin, dass die Kontextdaten ferner Tarif-Bedingungen von in Anspruch genommenen Diensten enthalten. Damit kann ein Benutzer sicher stellen, dass der Ressourcen-Anbieter seine Dienste nicht zu anderen Tarifen als vom Benutzer vorgegeben abrechnet.
-
In der Praxis müssen bei einer Interaktion zwischen Benutzer und Anbieter nicht notwendigerweise alle oben genannten Typen von Kontextdaten ausgehandelt bzw. ausgetauscht werden. Entsprechend werden dann auch nicht alle Kandidaten von Kontextdaten bei der Signaturerzeugung auf Benutzerseite berücksichtigt. Darüber hinaus können bei einer Aushandlung grundsätzlich auch weitere in der obigen Liste nicht enthaltene Daten ausgetauscht werden, welche vor einem Hintergrund weiterer Sicherheitsziele relevant sein können.
-
Welche Kontextdaten jeweils signiert und als SSO-Nachricht übertragen werden, hängt von den jeweiligen Umständen ab. Häufig wird ein Aushandeln der Komponenten der Kontextdaten zwischen Benutzer und Authentifizierer erfolgen.
-
Kurze Beschreibung der Zeichnungen
-
Ausführungsbeispiele der Erfindung sind in der Zeichnung anhand mehrerer Figuren dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
-
1 die Erzeugung und Weiterleitung der SSO-Nachricht,
-
2 die Erzeugung und Weiterleitung der SSO-Nachricht zusammen mit einer Authentifikation des Authentifizierers,
-
3 ein Ausführungsbeispiel mit mehreren Parteien auf Netz- und Dienstebene und
-
4 eine schematische Darstellung der bei der Erzeugung und Übermittlung der SSO-Nachricht auftretenden Daten.
-
Wege zur Ausführung der Erfindung
-
Bei den Ausführungsbeispielen nach den 1 bis 3 nimmt zunächst ein Benutzer 1 bzw. dessen Endgerät eine Kommunikation mit einem Authentifizierer 2 auf. Dabei enstehen innerhalb der Authentifikation 3 Kontextdaten, die der Benutzer 1 signiert. Die Signatur der Kontextdaten wird dann dem Authentifizierer 2 übermittelt, der sie überprüft und zusammen mit den Kontextdaten speichert.
-
Möchte der Benutzer außer mit dem Authentifizierer 2, der ein Netzbetreiber sein kann oder auch selbst andere Dienste anbietet, mit einer anderen Partei 4 eine Kommunikation aufnehmen oder deren Dienste in Anspruch nehmen, was einer Authentifikation bedarf, so sendet der Authentifizierer 2 die SSO-Nachricht 5, die aus Kontextdaten und aus der Signatur der Kontextdaten besteht, der Partei 4 zu. Die Partei 4 prüft dann mit Hilfe des öffentlichen Schlüssels des Benutzers 1 die Signatur und entnimmt den Kontextdaten die Identität des Benutzers. Das gleiche Verfahren kann mit weiteren Parteien 4n durchgeführt werden.
-
Bei dem in 2 dargestellten Szenario erfolgt zusätzlich zur Übermittlung der SSO-Nachricht 5 eine Authentifikation des Authentifizierers 2 gegenüber der Partei 4 und gegebenenfalls gegenüber anderen Parteien bis zur Partei 4n.
-
3 stellt das erfindungsgemäße Verfahren im Falle eines Szenarios mit mehreren Parteien auf Netz- und Dienstebene dar. Die Authentifikation und damit die Bildung der SSO-Nachricht erfolgt beispielsweise gegenüber einem Netz 6, das die SSO-Nachricht 5 bei Bedarf über weitere Netze 7, 8 an verschiedene Dienste 9 bis 9m weitergibt.
-
Je nach Aushandlung wählen Benutzer und Authentifizierer bei der Authentifikation des Benutzers eine bestimmte Menge von Kontextdaten aus, die von dem Benutzer abschließend signiert werden. Dabei werden die ausgewählten Kontextdaten vor der Signatur in eine entsprechende Reihenfolge gebracht und durch Konkatenation zusammengefasst. Wenn der Authentifizierer die Signatur des Benutzers als korrekt verifiziert hat, erzeugt er aus den erforderlichen Kontextdaten und der Signatur eine SSO-Nachricht, die er an die entsprechenden Ressourcenanbieter weiterleitet Die in der SSO-Nachricht, eingebetteten Kontextdaten und Signatur des Benutzers erfüllen im Rahmen des SSO mehrere Zwecke:
- – Verifikation der Integrität der Kontextdaten und Initiierung von Aktionen des Ressourcenanbieters auf Basis dieser Kontextdaten,
- – Überprüfbarkeit der Benutzeridentität durch beliebige Dritte, ohne dass diese dem Authentifizierer vertrauen müssen, da die SSO-Nachricht nicht gefälscht werden kann, sofern das Signaturverfahren sicher ist,
- – Nichtabstreitbarkeit für Accountingzwecke: Durch die Signatureigenschaften ist jederzeit nachweisbar, dass ein Benutzer bestimmte Dienste eines Ressourcenanbieters zu einem bestimmten Zeitpunkt und zu bestimmten Bedingungen angefordert hat. Das kann hilfreich sein, wenn der Benutzer abstreitet, bestimmte Dienste angefragt zu haben.
-
Das erfindungsgemäße Verfahren, bei dem die von dem Authentifizierer erzeugte SSO-Nachricht nicht erfolgreich gefälscht werden kann, kann grundsätzlich in Verbindung mit bestehenden Authentifikationsverfahren eingesetzt werden. Damit dies möglich ist, muss der Benutzer seine Identität zunächst gegenüber dem Authentifizierer mittels einer Signatur auf entsprechende Kontextdaten beweisen. Aus der empfangenen Signatur und den signierten Daten erzeugt der Authentifizierer anschließend eine SSO-Nachricht. Darüber hinaus müssen in dem Authentifikationsverfahren auch genau diejenigen Typen von Kontextdaten ausgetauscht und bei der Signaturberechnung berücksichtigt werden, welche für den SSO-Mechanismus verwendet werden sollen. Sieht das Authentifikationsprotokoll nicht alle gewünschten Typen von Kontextdaten vor, so sind folgende zwei Strategien möglich:
- 1. Anwendung der standardmäßig im Authentifikationsprotokoll enthaltenen Kontextdaten: Da eine Veränderung des Authentifizierungsprotokolls nicht immer möglich bzw. auch nicht immer gewünscht ist, besteht grundsätzlich auch die Möglichkeit, sich bei der Erzeugung der SSO-Nachricht auf die ausgetauschten Daten zu beschränken, welche das Authentifizierungsprotokoll standardmäßig verwendet. Soll die SSO-Nachricht auf der Basis eines unmodifizierten Authentifikationsprotokolls erzeugt werden, so müssen die Benutzer und Ressourcenanbieter dem Authentifizierer dahingehend vertrauen, dass dieser die SSO-Nachricht nicht für unerwünschte Zwecke missbraucht.
- 2. Einbeziehung neuer Kontextdaten in das Authentifikationsprotokoll: Sind in dem Authentifikationsprotokoll, auf welches das SSO-System aufgesetzt werden soll, nicht alle gewünschten Kontextdaten vorgesehen, so besteht die Möglichkeit, das Protokoll um diese Kontextdaten zu ergänzen, so dass diese Kontextdaten bei der Erzeugung der Signatur berücksichtigt werden. Da hierfür bestehende Implementierungen von Authentifikationsprotokollen modifiziert werden müssen, ist dies jedoch nicht immer möglich.
-
Für das erfindungsgemäße Verfahren ist das TLS-Protokoll als Authentifizierungsprotokoll geeignet, auf dessen Basis ein SSO-Mechanismus realisiert werden kann. Das TLS-Protokoll ist beispielsweise in T. Dierks, C. Allen: The TLS Protocol Version 1.0. RFC 2246, January 1999 beschrieben und wird in einer älteren Variante auch als SSL-Protokoll bezeichnet. Es verfügt über Varianten, so genannte Cipher Suites, in welchen unter anderem zum Zweck der Authentifikation von Benutzern Signaturen erzeugt und an eine authentifizierende Partei geschickt werden. Das TLS-Protokoll wird üblicherweise oberhalb der Transportschicht (Schicht 4, Transport Layer) nach dem OSI-Referenzmodell eingesetzt.
-
Mittlerweile gibt es Standards, in denen das TLS-Protokoll als Sicherheitsprotokoll im Rahmen des PPP-EAP-TLS-Protokolls direkt über der Sicherungsschicht (Schicht 2, Data Link Layer) eingesetzt wird. Das PPP-EAP-TLS-Protokoll ist dabei eine spezielle Variante des EAP-Protokolls. Vereinfacht kann man sagen, dass bei dem PPP-EAP-TLS-Protokoll die Sicherungsmechanismen des TLS-Protokolls direkt zwischen zwei Punkten über der Sicherungsschicht angewendet werden. Auch wenn die PPP-EAP-TLS-Variante über einer anderen Schicht realisiert ist, so werden in diesem Rahmen die gleichen kryptographischen Protokolle und Verfahren angewendet wie auch in der eigentlichen Variante des TLS-Protokolls.
-
In dem TLS- wie auch in dem PPP-EAP-TLS-Protokoll werden die in der Kommunikationsbeziehung zu verwendenden Schutzmechanismen zunächst von den beiden Kommunikationspartnern ausgehandelt. Diese Aushandlung wird im Rahmen von TLS als Handshake-Protokoll bezeichnet. In diesem Zusammenhang werden sowohl die zu verwendenden kryptographischen Verfahren (Cipher Suites) für die verschiedenen Schutzziele festgelegt als auch die notwendigen Daten zur Erzeugung kryptographischer Parameter ausgetauscht.
-
Für einen TLS-basierten (TLS, PPP-EAP-TLS) SSO-Mechanismus sind lediglich diejenigen Varianten von Aushandlungen in Verbindung mit gewählten Cipher Suites relevant, in denen die Authentifizierung des Benutzers gefordert ist und der Benutzer zu seiner Authentifizierung eine Signatur erzeugt, welche er an den Authentifizierer schickt. Das TLS-Protokoll beinhaltet darüber hinaus auch die Möglichkeit, bei welcher ausschließlich der Server authentifiziert wird, als auch anonymitätsfördernde Varianten, bei welchen gar keine Partei authentifiziert wird.
-
Welche Schutzmaßnahmen letztendlich angewendet werden sollen, hängt von der jeweiligen Aushandlung zwischen Authentifizierer und Benutzer ab. Nach der Aushandlung der zu verwendenden Verfahren und dem Austausch weiterer Daten werden diese schließlich angewendet, so dass die weitere Kommunikation entsprechend gesichert abläuft. Für den TLS-basierten (TLS, PPP-EAP-TLS) SSO-Mechanismus sei darüber hinaus angenommen, dass die Benutzer und Authentifizierer über geeignete Zertifikate verfügen, welche zur Authentifizierung eingesetzt werden. Für den TLS-basierten (TLS, PPP-EAP-TLS) SSO-Mechanismus ist insbesondere das Zertifikat des Benutzers relevant. Der zu dem Zertifikat gehörende geheime Schlüssel sollte sich darüber hinaus zur Berechnung von Signaturen eignen.
-
In der herkömmlichen Anwendung des TLS- bzw. PPP-EAP-TLS-Protokolls wird die zur Benutzerauthentifikation vom Benutzer (Client) erzeugte und zum Authentifizierer (Server) geschickte Signatur von dem Authentifizierer auf Korrektheit überprüft. Bei negativem Prüfergebnis bricht der Authentifizierer die Verbindung ab. Bei positivem Prüfergebnis werden die ausgehandelten Sicherungsverfahren angewendet. Wenn die Signatur verifiziert wurde, so wird diese im TLS- bzw. PPP-EAP-TLS-Protokoll nicht mehr benötigt und kann gelöscht werden. In dem hier beschriebenen SSO-Mechanismus soll diese Signatur jedoch zur Erzeugung einer SSO-Nachricht verwendet werden, weshalb der Authentifizierer sie nach der Verifikation nun zu diesem Zweck in seinem Speicher behält.
-
Im TLS- bzw. PPP-EAP-TLS-Protokoll signiert der Benutzer zur Authentifikation Nachrichten des Handshake-Protokolls. Hierzu werden die zu signierenden Nachrichten in der Reihenfolge ihres Auftretens konkateniert und anschließend signiert. Danach wird die Signatur des Benutzers im Rahmen des Handshake-Protokolls zum Authentifizierer geschickt. Dabei bezieht sich die Signatur des Benutzers nur auf alle diejenigen Handshake-Nachrichten, die vor der Signaturerzeugung ausgetauscht wurden, da die Nachricht, in welcher die Signatur zum Authentifizierer geschickt wird, nicht bei der Signaturberechnung berücksichtigt werden kann. Bei der Signaturberechnung sind die in 4 dargestellten Handshake-Nachrichten relevant.
-
Nachdem der Benutzer die bei dem Handshake erzeugten und erhaltenen Daten bei 19 zu Kontextdaten zusammengefasst und die Signatur bei 20 auf Basis der Kontextdaten berechnet hat, schickt er in der darauf folgenden Nachricht 21 (CertificateVerify) die Signatur an den Authentifizierer. In die SSO-Nachricht sind deshalb neben der Signatur des Benutzers alle Handshake-Nachrichten eingefügt, welche der CertificateVerify-Nachricht 21 vorangegangenen sind.
-
Damit der SSO-Mechanismus geeignet gesichert werden kann, sollten ebenfalls die zur Detektion von Missbrauch erforderlichen Kontextdaten in der SSO-Nachricht enthalten sein. Da jedoch die Berechnung der Signatur ausschließlich über den Nachrichten des Handshake-Protokolls berechnet wurde, muss man sich zur Sicherung des SSO-Mechanismus bei diesem Ausführungsbeispiel auf die im Handshake-Protokoll ausgetauschten Daten beschränken.
-
Da das Handshake-Protokoll zur Aushandlung von Sicherungsmechanismen über einen unsicheren Kanal dient, werden in dem Handshake-Protokoll selbst bereits einige Sicherungsmechanismen angewendet und spezielle Daten ausgetauscht, welche es Benutzer und Authentifizierer erlauben, Angriffe zu erkennen. Einige der zur Sicherung des Handshake-Protokolls ausgetauschten Daten können als Kontextdaten im Rahmen des SSO-Mechanismus wieder verwendet werden. Da die Daten des Handshake-Protokolls von dem Benutzer signiert worden sind, liegen diese ebenfalls in der SSO-Nachricht als gesicherte Kontextdaten vor, so dass potenzielle Angriffe von dem Ressourcenanbieter erkannt werden können. Zur Umsetzung einiger für den SSO-Mechanismus erforderlicher Kontextdaten sollen die folgenden Daten verwendet werden, welche im Handshake-Protokoll ausgetauscht werden:
- – Identität des Benutzers: Die Identität des Benutzers (Client) wird im Rahmen des Handshake-Protokolls in der Nachricht ClientCertificate 17 ausgetauscht. Das in dieser Nachricht ausgetauschte Zertifikat des Benutzers eignet sich zur Beschreibung der Identität des Benutzers im Rahmen des SSO-Mechanismus.
- – Identität der authentifizierenden Partei: Die Identität des Authentifizierers (Server) wird im Rahmen des Handshake-Protokolls in der Nachricht ServerCertificate 13 ausgetauscht. Das in dieser Nachricht ausgetauschte Zertifikat des Authentifizierers eignet sich zur Beschreibung der Identität des Authentifizierers im Rahmen des SSO-Mechanismus.
- – Der Zeitpunkt der Authentifikation (Sekunde, Minute, Stunde, Tag, Monat, Jahr): Der Zeitpunkt der Authentifikation ist im Rahmen des Handshake-Protokolls in den Nachrichten ClientHello 11 und ServerHello 12 enthalten. Der in diesen Nachrichten ausgetauschte Zeitwert eignet sich ebenfalls zur Wiederverwendung im Rahmen des SSO-Mechanismus.
- – Der öffentliche Schlüssel des Signierers: Der Signierer schickt seinen öffentlichen Schlüssel zur Signaturverifikation zusammen mit seinem Zertifikat, was im Rahmen des Handshake-Protokolls in der Nachricht ClientCertificate 17 geschieht.
- – Das bei der Authentifikation verwendete Protokoll und die kryptographischen Verfahren: Dieses ergibt sich aus der Versionsbeschreibung des durchgeführten TLS-Protokolls, welche in den Nachrichten ClientHello (clientseitiger Vorschlag) 11 und ServerHello (serverseitiger Vorschlag) 12 enthalten ist, und aus den Cipher Suites, welche in den Nachrichten ClientHello (Vorschlag) 11 und ServerHello (Auswahl) 12 ausgehandelt wurden. Auf Basis dieser Information kann der Ressourcenanbieter in einem SSO-Mechanismus erkennen, auf Basis welcher Verfahren der Benutzer die Signatur berechnet hat und wie die Benutzersignatur vom Ressourcenanbieter überprüft werden muss.
- – Zufallswerte (von Benutzer und Authentifizierer wählbar): Die sich als Kontextdaten des SSO-Mechanismus eignenden Zufallswerte werden im Handshake-Protokoll in den Nachrichten ClientHello 11 und ServerHello 12 ausgetauscht. Diese Zufallswerte können im Rahmen des SSO-Mechanismus als Kontextdaten zur Detektion von Angriffen verwendet werden, wenn nur eine einmalige Benutzung der SSO-Nachricht vorgesehen ist und die weitere Partei die erstmals empfangene SSO-Nachricht für Vergleichszwecke speichert.
-
Damit sind die im Handshake-Protokoll ausgetauschten Daten, welche für den SSO-Mechanismus relevant sind, erläutert. Wenn noch weitere Typen von Kontextdaten für den SSO-Mechanismus gewünscht sind, wie sie beispielsweise oben aufgeführt sind, können die entsprechenden Daten in einer modifizierten Fassung des Handshake-Protokolls von TLS bzw. PPP-EAP-TLS berücksichtigt werden. Wenn diese Daten in einer modifizierten Fassung des TLS- bzw. PPP-EAP-TLS-Protokolls im Rahmen des Handshake-Protokolls ausgetauscht werden sollen, dann müssen diese vor der CertificateVerify Nachricht 21 ausgetauscht werden. Hierzu könnte man beispielsweise für das TLS- bzw. PPP-EAP-TLS-Protokoll neue Erweiterungen vorsehen, ähnlich wie die in S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright: Transport Layer Security (TLS) Extensions, RFC 3546, June 2003 vorgeschlagenen Erweiterungen. Die bislang vorgeschlagenen Erweiterungen von TLS dienen jedoch anderen Zwecken, so dass sie für den vorgeschlagenen SSO-Mechanismus nicht verwendet werden können.
