Notarized Federated Identity Management for Web Services Michael
Notarized Federated Identity Management for Web Services Michael T. Goodrich University of California, Irvine Roberto Tamassia Danfeng Yao Brown University Work supported in part by the National Science Foundation Notarized. Inc. Federated Identity and by IAM Technology, DBSec 2006 Management
Outline Introduction to federated identity management (FIM) Ø Notarized federated identity management model and protocol Ø STMS and its application in notarized FIM Ø Identity theft and proposed countermeasure Ø DBSec 2006 Notarized Federated Identity Management 2
Motivation Ø Digital identity management (DIM) l Ø Users tend to choose weak passwords l Ø A user logs in only once to a site, then is automatically authenticated Cookie-based SSO approach (used by Microsoft Passport) l Ø As the number of passwords to remember increases Single sign-on (SSO) and federated identity management l Ø To protect sensitive personal information in on-line transactions Does not support cross-domain single sign-on Approach using cryptographic-enabled assertions l Secure Assertion Markup Language (SAML) DBSec 2006 Notarized Federated Identity Management 3
SSO and FIM DBSec 2006 Notarized Federated Identity Management 4
Provider model in SAML Specially designed for general cross-domain single sign-on Ø Identity Provider (Id. P) Ø l Ø Service Provider (Se. P) l l Ø Id. P is the system that asserts information about a subject Se. P is the system that relies on the information supplied to it by the identity provider Relying party Used in Liberty Alliance Federated Identity Management for single sign-on DBSec 2006 Notarized Federated Identity Management 5
Identity Federation Ø Websites of different admin domains need to trust each other's access control verdicts l Ø Issues l l Ø Circle of trust How to securely maintain the identity federation when members may leave or join the circle of trust? How to provide separation of Id. P and Se. P for the privacy protection of the user? These questions have not been extensively studied l l Existing SSO solutions assume pre-established trust relationship among providers Id. P and Se. P communicate to each other during SSO process DBSec 2006 Notarized Federated Identity Management 6
Notarized Federated Identity Management We introduce a trusted third-party, called notary server Ø The notary information of an assertion provides its trustworthiness Ø Distributed implementation of the notarized federated identity management framework using STMS Ø We also present a robust authentication protocol that is resilient against identity theft attacks, using identity-based encryption Ø DBSec 2006 Notarized Federated Identity Management 7
Notarization Ø Notary server l l Ø Third party trusted by identity providers and service providers Notarizes assertions submitted by identity providers Answers queries on notarized assertions asked by the service providers Prevents direct communication between the identity provider and the service provider Notarized assertion l l l Generated by identity provider Authenticated by notary server Trusted by service provider DBSec 2006 Notarized Federated Identity Management 8
Security Requirements Ø Security l Ø Secrecy l Ø A polynomial-time adversary cannot forge a valid notarized assertion Notarized assertion should not leak sensitive information of a user to unauthorized parties, including the notary server Accountability l Identity providers should be held accountable for the assertions that they generate; and for any unauthorized information disclosure about the user DBSec 2006 Notarized Federated Identity Management 9
Overview of Notarized FIM S_ID: session ID Hashed_ID: hashed S_ID Attr. Name: name of attribute required by Se. P Id. P 3. Authenticates 4. Signed S_ID, attr. names 9. Unblind and verify 6. Query for hashed_ID 1. Service request User Se. P 5. Signed blinded assertion with hashed_ID 2. S_ID, attr. names Notary Server 7. Notarized blinded assertion 8. Notarized blinded assertion DBSec 2006 Notarized Federated Identity Management 10
Protocol Design Challenges How to protect the identity of the user from the service provider? Ø How to blind the content of an assertion from the notary server? Ø l How to unblind by the service provider? How to hold the identity provider accountable for unauthorized disclosure? Ø Our solution uses lightweight crypto primitives Ø l l hash function XOR symmetric encryption digital signature DBSec 2006 Notarized Federated Identity Management 11
Implementation of Notarized FIM Protocol Ø Ø Two public parameters P 1, P 2 The user and Se. P compute a session_ID N l Ø The user requests Id. P to generate assertions l Ø Signed request to Id. P for accountability Id. P blinds an assertion l l l Ø XOR each party’s random string Computes the hashed_ID h = Hash(N, P 1) Generates an assertion S using h for index Computes the blinding factor K = Hash(N, P 2) Encrypts S with K using a symmetric encryption scheme Blinded assertion is called S’ Id. P submits an assertion to the notary server l l Sign S’ with its private key Notary server stores S’, and stores the signature for accountability DBSec 2006 Notarized Federated Identity Management 12
Implementation of the notarized FIM protocol (Cont’d) Ø The user queries for an assertion of a hashed_ID l l Ø Notary server notarizes an assertion l l l Ø Retrieves the blinded assertion S’ Signature approach: Signs S’ with its private key STMS approach: computes the proof for S’ The user unblinds and verifies an assertion l l Ø Computes the hashed_ID h = Hash(N, P 1) Queries the notary server for assertions of h The user verifies the notary information Computes the blinding factor K = Hash(N, P 2) Decrypts S’ with K and obtains S Detect unauthorized information disclosure The service provider unblinds and verifies the assertion DBSec 2006 Notarized Federated Identity Management 13
Privacy and Accountability User Id. P Se. P Notary Server User Id. P DBSec 2006 Signs Access S_ID, assertion Accesses Blinded assertion Request for attributes Stored by Assertions to notary Stored by Notarized Federated Identity Management Id. P Notary Server 14
Notary server realization: STMS Ø The Secure Transaction Management System [Goodrich, Tamassia et al. ] implements an authenticated dictionary Basis (signed) Updates t Responder A DS Source DS DBSec 2006 t Query Response Responder B DS Notarized Federated Identity Management User Answer Proof Basis (signed) 15
STMS in Notarized FIM 5. Signed blinded assertion with hashed_ID Id. P 3. Authenticates 4. Signed S_ID, attr. names 9. Unblind and verify Signed STMS basis, updates per time quantum 6. Query for hashed_ID 1. Service request User Se. P Notary Source 2. S_ID, attr. names Notary Responder 7. Notarized blinded assertion 8. Notarized blinded assertion DBSec 2006 Notarized Federated Identity Management 16
Outline of the talk Introduction to federated ID Ø Provider model in SAML Ø Notarized federated identity management model and protocol Ø Identity theft and countermeasure Ø DBSec 2006 Notarized Federated Identity Management 17
An authentication protocol robust against identity theft Ø Identity theft causes l Private information insecurely stored and entered • On credit card company’s computers, in DMV’s cabinets, in your bank, in your trash can … Ø How to proactively control the release of your private information? l Secure storage • Prevent dumpster diving l Safe disclosure • Prevent shoulder surfing l Ø Existing approaches l l Ø With minimal changes to current financial and administrative infrastructure Centralized processing Heavy-weight Zero-knowledge proofs Our approach l To design a lightweight authentication protocol using identity-based encryption DBSec 2006 Notarized Federated Identity Management 18
An authentication protocol with identity-based encryption 6. Is the identity-based public key revoked? Revocation Server 3. Submits identitybased public key for authentication Identity Provider 4. Challenge ciphertext 5. Result of decryption with private key DBSec 2006 Periodic updates of revoked identity-based public keys 1. Registers identity-based public key ID Authority User 2. Issues corresponding private key Notarized Federated Identity Management 19
Related work Ø Ø Ø Anonymous credentials [Camenisch Lysyanskaya 01] [Camenisch Herreweghen 02] Federated ID management models [Camenisch et al 05] [Bhargav-Spantzel Squicciarini Bertino 05] [Pfitzmann Waidner 03] Web service framework [Bonatti Samarati 02] Identity theft detection [van Oorschot Stubblebine 05] Identity-based encryption [Boneh Franklin 01] SAML [OASIS], WS-Federation [IBM et al] DBSec 2006 Notarized Federated Identity Management 20
Conclusions Notarized federated identity management is a solution for establishing trust in web services Ø Notary server provides an anchor of trust Ø Notarized FIM protocol provides accountability, privacy, and secrecy for participants Ø IBE-based credentials and exchanges hold promises for identity theft solutions Ø DBSec 2006 Notarized Federated Identity Management 21
Acknowledgements Ø David Croston at IAM Technology, Inc DBSec 2006 Notarized Federated Identity Management 22
DBSec 2006 Notarized Federated Identity Management 23
Generations of the model S_ID: One-time session ID Hashed_ID: hashed S_ID Attr. Name: name of attribute required by Se. P Id. P 3. Authenticates 4. Signed S_ID, attr. names 9. Unblind and verify Se. P A Se. P B 5. Signed blinded assertion with hashed_ID Optional path 6. Query for hashed_ID 1. Service request 2. S_ID, attr. names User Notary Server 7. Notarized blinded assertion 8. Notarized blinded assertion DBSec 2006 Notarized Federated Identity Management 24
- Slides: 24