Thomas Groß 5. November 2009 Browserbasierte Identitätsföderation
Inhalt Einleitung Hauptergebnisse Browsermodell Sicherheitsbeweis des WS-Federation Passive Requestor Profils Zusammenfassung 2
Einordnung browserbasierter Identitätsföderation User Wissenschaft Standards Industrie ID Consumer Föderiertes Single Sign-on Neu: Nur Web Browser. (Sonst Dreiparteienauthentifikation) ID Supplier Standardisiert und real: SAML, Liberty, WS-Federation, OpenID Nur Web Browser = zero-footprint Reduziert Benutzermanagementkosten Verbreitet in Zugriffskontrollsystemen 3
SAML 1.1 Browser/Artifact Profile U B C ID Consumer S ID Supplier 1a. Authentifiziere Benutzer 2. Redirect(URLC, artifact) artifact zufällig; DB S.store(artifact); 3. GET(URLC, artifact) 7. 6. Fehlerseite mit non-ssl Link 7a. GET non-ssl Seite 4. Request(artifact) 5. Response(assertion) HTTP Referer: URL mit artifact DB S.lookup(artifact); generiere assertion; DB S.remove(artifact) Quelle: Security Assertion Markup Language (SAML) 1.1, Browser-Artifact Profile 4 Sicherer Kanal Beidseitig
Ziel: Sicherheitsbeweis für browserbasierte Identitätsföderation Interface bei ID Consumer C auth_in C : auth_out C : (start, cid), (acc, cid, idu), (rej, cid, ) Netzwerkangreifer (ITM aus PPT) mit Zugriff auf Browser Informationen Generisches Browser-Verhalten Wesentliche Sicherheitseigenschaft: Kanalauthenzität ID Consumer C erhält Ausgabe (acc, cid, idu) Sicherer Kanal mit Kennung cid ist mit dem einzigen Benutzer U, der die Identität idu bei C's ID Supplier S besitzt. 5
Inhalt Einleitung Hauptergebnisse Browsermodell Sicherheitsbeweis des WS-Federation Passive Requestor Profils Zusammenfassung 6
Hauptergebnisse Erste Sicherheitsanalyse eines standardisierten Föderationsprotokolls [Gross2003] Vergleich mit Vorige Forschungsergebnisse: Kormann und Rubin 2000 Risks of the Passport Single Sign-on Protocol Nachfolgende Forschungsergebnisse: Hansen, Skriever, Nielson 2005 Using static analysis to validate the SAML Single Sign-on Protocol Armando et al. 2008 Formal analysis of a SAML Web Browser Single Sign-on Protocol Gajek, Schwenk, Steiner, Xuan 2009 On the Insecurity of Microsoft's Identity Metasystem CardSpace 7
Hauptergebnisse Erste Sicherheitsanalyse eines standardisierten Föderationsprotokolls [Gross2003] Erstes formales Browsermodell für browserbasierte Protokolle [PfGrSa2005a] Vergleich mit Vorige Forschungsergebnisse: keine Nachfolgende Forschungsergebnisse: Gajek 2008 A universally composable framework for the analysis of browser-based protocols 8
Hauptergebnisse Erste Sicherheitsanalyse eines standardisierten Föderationsprotokolls [Gross2003] Erstes formales Browsermodell für browserbasierte Protokolle [PfGrSa2005a] Erster Sicherheitsbeweis eines standardisierten Föderationsprotokolls mit Browsermodell [PfGrSa2005b] Vergleich mit Vorige Forschungsergebnisse: Arbeiten von Gordon et al. z.b. Secure sessions for Web Services Nachfolgende Forschungsergebnisse: Arbeiten von Gajek, Manulis, Sadeghi und Schwenk 2008 z.b. Provably secure browser-based user-aware mutual authentication over TLS, Enforcing user-aware browser-based mutual authentication with strong locked SOP 9
Inhalt Einleitung Hauptergebnisse Browsermodell Sicherheitsbeweis des WS-Federation Passive Requestor Profils Zusammenfassung 10
Überblick: Sicherheitsbeweise mit dem Browsermodell H U B ^ S FIM C FIM A secchan Behauptung: System ist wiederum ein sicheren Kanal 11
Beispiel aus dem Benutzermodell: passwortbasierte Authentifikation Verhalten von U bei einer Authentifizierungsanfrage (kritischer Ablauf um Phishing zu vermeiden) Waiting gui B,U?(request_uauth, wid, host, sid, ch_type) Step 3. Authentication request Step 4. Verifiziere: host vertraut? ELSE [ P T U P.host = host P.sid = sid P.login ε] ELSE Known trusted server [ch_type P.sec] // gui U,B!(authenticate, wid, P.login, P.sid, false) Step 5. Failure: unknown server / channel insecure Proceed: uauth successful 12
Zweite Hälfte des Zustandsdiagramms einer HTTP Transaktion POST Requests Pages/ Errors Scripted POST GET Requests Redirect User Authentication 13
Inhalt Einleitung Hauptergebnisse Browsermodell Sicherheitsbeweis des WS-Federation Passive Requestor Profils Zusammenfassung 14
WS-Federation Passive Requestor Interop Profile (WSFPI) U B C S 4. Redirect(URI S, (wa, wtrealm, [wreply, wctx, wct]) 5. Authentifiziere Benutzer 6. POSTForm(a, (wresult, [wctx])) 7. POST a := wreply or wtrealm; wresult := sign(name S, (URI S, URI C, id U )) cid bc Kanalauthentizität: C erhält eine Ausgabe (acc, cid bc, idu) Sicherer Kanal mit Kennung cid bc ist mit dem einzigen Benutzer U, der die Identität idu bei C's ID Supplier S besitzt. Annahmen: Cross-protocol key use, Security Realms S/C, Infofluß a. Modell 15
Übersicht über den Sicherheitsbeweis U B S C Authentifiziere Benutzer als idu 6. POSTForm(a, (wresult)) a := wreply or wtrealm; wresult := sign(name S, (URI S, URIC, idu) [a URIC] 7. POST Verifiziere wresult; [URIC = URI C ] Out: (acc, cid bc, idu) 16
Inhalt Einleitung Hauptergebnisse Browsermodell Sicherheitsbeweis des WS-Federation Passive Requestor Profils Zusammenfassung 17
Zusammenfassung Analysen und Protokollvorschläge Erste Sicherheitsanalyse eines standardisierten Föderationsprotokolls Neues SAML 2.0 Profil Janus mit optimaler Sicherheit und Effizienz Co-Design des WS-Federation Passive Requestor Interop Profils Modellierung Erstes formales Modell für browserbasierte Protokolle Erste sinngetreue grafische Spezifikationssprache für RSIM Kanalauthenzität Sicherheitsbeweise Erster Sicherheitsbeweis für ein standardisiertes Föderationprotokoll mit Browsermodell Abgeleitete Testfälle für Föderationssysteme Industrieeinfluß und Validierung Standards: OASIS SAML 1.1 und 2.0, OASIS WS-Federation Produkte: IBM Tivoli Federated Identity Manager (TFIM) 18
WS-Federation Passive Requestor Profile (WSFPI) U B S C 0. Browse 4. Redirect(URI S, (wa, wtrealm, [wreply, wctx, wct]) 5. Authentifiziere Benutzer 6. POSTForm(a, (wresult, [wctx])) a := wreply or wtrealm; wresult := sign(name S, (URI S, URI C, id U )) 7. POST 10. Response Verifiziere... Sicherer Kanal Quelle: WS-Federation Passive Requestor Interop Profile (WSFPI) wie von der Web Services Interoperability Organisation (WS-I) spezifiziert 19
Formale Maschinenmodellierung des Browsermodells 20
IBM Research - Zurich Formale Kollaboration des Browsermodells 21
Formale Modellierung des WSFPI Systems!! ^ "!!!!! "!! " "!! 22
Formale Annahmen Protokollübergreifende Schlüsselverwendung Kanalschlüssel werden nicht wiederverwandt. Signaturschlüssel für Tokens werden nicht für dasselbe Format wiederverwandt. Hohe Qualität der Zertifizierung und Sicherheitsbereiche URI S und URI C sind Teil von Sicherheitsbereichen (Security Realms) Nur Dienste, die von einer Partei vertraut werden, können Zertifikate für Adressen in deren Sicherheitsbereich erhalten. Alle Dienste unter URI C folgen den Vertrauensannahmen von C. Nicht-assoziierte URIs werden auf URI C abgebildet. Browsermodell Informationsfluß, der nicht im Browsermodell modelliert ist, tritt nicht auf. 23
Publikationen der Dissertation Nr Publikation Cites 1 Security analysis of the SAML Single Sign-on Browser/Artifact profile Thomas Groß. Annual Computer Security Applications Conference (ACSAC), 2003. [Gross2003] 2 Proving a WS-Federation passive requestor profile Thomas Groß and Birgit Pfitzmann. ACM Workshop on Secure Web Services (ACM SWS), 2004. [GroPfi2004] 3 Browser model for security analysis of browser-based protocols Thomas Groß, Birgit Pfitzmann, Ahmad-Reza Sadeghi. European Symposium on Research in Computer Security (ESORICS), 2005. [GrPfSa2005] 4 Proving a WS-Federation Passive Requestor Profile with a browser model Thomas Groß, Birgit Pfitzmann, Ahmad-Reza Sadeghi. ACM Workshop on Secure Web Services (ACM SWS), 2005. [GrPfSa2005] 5 SAML artifact information flow revisited Thomas Groß and Birgit Pfitzmann. IEEE Workshop on Web Services Security (IEEE WSSS), 2006. [GroPfi2006] 5 Cites/year: 17.33 Cites/paper: 20.80/14.0/multi Cites/author: 75.67 Papers/author: 2.67 Authors/paper: 2.20/2.0/multi h-index: 5 / g-index: 5 58 12 15 14 6 105 Quelle: Statistiken und Daten bezogen mit Harzing s Publish or Perish, basierend auf Google Scholar Daten vom 24.10.2009 24