Digital Identity Management on the Internet

1. Digital Identity Management on the Internet Al Gutierrez and Will Tsui CPSC 457 Spring 2006

2. Intro • Internet: simple end-to-end design • Dumb, minimal network: only connects devices • Improving technology => • More high value transactions • More accounts at online services • Propagation of sensitive information • Consequence of existing identity systems: Safety and convenience of conducting Internet transactions not ideal

3. What is digital identity?

4. Identity in the Physical World • We are unique, irreplicable individuals, right? • iden·ti·ty “the condition of being the same with something described or asserted.” (Merriam-Webster) • Identity is how one is described either by self-assertions or by assertions of another. • Real-world example: buying alcohol

5. Identity in the Physical World • How well can we identify someone in real life? • Identification is never perfect • Authentication: three factors • Something you are • Something you have • Something you know

6. Digital Identity and Its Limitations • Digital identity is a set of characteristics asserted “by one digital subject about itself or by another digital subject, in a digital realm.” (Microsoft) • As in the real world • Identity need not be human • Limited by authentication factors • Authentication inherently more difficult on the Internet

7. Digital Identity Management • Focused on maintaining these asserted characteristics of subjects, a.k.a. claims • Why is digital identity management important? • Inventory • Access control • Out of scope: authentication

8. Digital Identity on the Internet: Current Problems

9. Problems with Current (Non-) Solutions • 1. Unreliability • 2. Inconvenience • 3. Inconsistence • 4. Impermanence / In-transience • 5. Insecurity • 6. Propagation • 7. Intrusion

10. 1. Unreliability Unreliable identification of people. • It's possible to identify machines (with caveats). • It's not possible to secure remote machines. • Perhaps this is provably so. • One-way protocols can be spoofed. • To wit: SMTP, the default outgoing mail protocol. • It's possible to secure the (network) channel between machines. • It's possible to conduct transactions between machines. • Currently, it's not possible to identify the parties concretely. • Very poor management of identification information.

11. 2. Inconvenience • People currently have to register and create multiple 'accounts.' • People have to create strong, independent passwords. This is usually not even done properly. • People have to remember or securely store all this info. • Many sites require CAPTCHAs. • Completely Automated Public Turing test to tell Computers and Humans Apart • Determine whether a ‘user’ is ‘human’ for a period of time. • Login systems are primitive and rely on browsers. • Cookies • URL Query Strings • HTTP 1.1 Basic Auth

12. 3. Inconsistency • There are various types of registration/login systems around. • Many, many different authentication ‘schemes’ and associated GUIs that vary across: • Servers (Apache / IIS / …) • Languages (PHP, Perl, Ruby, C/CGI…) • Frameworks (Rails, Struts, Form systems, CMSs…) • Functionality greatly varies across these systems. e.g. Can I reset my password? or Can I delete my account? • This is not necessarily the site creators’ fault: - There is a great burden of work on sites. - There is a burden on the user too, to learn too much.

13. 4. Impermanence / In-transience Online identity is not meaningfully transitive. • An account in domain A is useless at domain B. • So is Reputation/Credibility/Credit/Experience across domains. • E.g. Two different MMOs where the same person wants to keep a single character / persona. • Identity is also “ephemeral” • HTTP is a stateless protocol • Therefore, everything on top resembles this. • After a period of time, IDs usually “expire.”

14. 5. Insecurity Current infrastructure is basically insecure. • People lose/leak passwords. • People choose weak passwords. • Cookies are vulnerable to XSS attacks. • Machines can be compromised. • Trojans. • Keyloggers. • Viruses/Spyware/Malware. • Protocols/Ciphers become outdated / breakable: • e.g. SSL1, MD4 and possibly MD5.

15. 5. Insecurity (contd.) • The security of the system is a chain. • It's subject to 'the weakest link‘ • When that link is broken, a person's identity can be compromised. • Not too hard, given some very insecure public systems out there. • e.g. Yale's SSN fiasco. • Servers can be compromised. • e.g. the Lexis-Nexis massive leak. • etc., etc.

16. 6. Propagation • There is a vast propagationof sensitive information. • Very prone to leaking. • Leaks are also vulnerable to weakest link. • E.g. • Amazon (likely secure) => Shady Vendor • Amazon (likely secure) => Shady Shipper • The current paradigm is leak, then secure. • A better paradigm would be based around ‘prevention.’

17. 7. Intrusion • Essentially involuntary actions. • Lots of unsolicited communication • Commercial • Anonymous / Ambiguous • A lot of spam belongs here. • Religious • Political • Can result in privacy violations • e.g. Hidden HTTP requests in HTML email.

18. Legal Situation

19. Legal Situation • The law cannot target “general improvement.” • It must aim for specific problems, and make those things punishable. • E.g. Identity Theft • The current environment is: • Certain federal agencies. • The individual states’ id-related laws.

20. Federal Level • The Federal Trace Commision (FTC) takes care of overall complaints. • The FTC can also take care of issues with unassigned agencies: • Credit Cards, Debt. (FDC Act) • For Bankruptcy: U.S. Trustee (UST). • For Passports: U.S. State Dept. • Tax fraud: IRS. • Drivers’ Licenses: state DMV

21. Federal Level (Contd.) • Mail theft: USPS. • Phone fraud: Depends on utility. • Financial Crimes: U.S. Secret Service • Bank fraud: Office of the Comptroller of the Currency (OCC) • Only “National” banks. • Social Security Numbers: SS Administration • Student Loans: U.S. Dept. Of Education • Prosecution is done by the U.S. DOJ.

22. Federal Level (contd.) • If you suffer even one instance of ID theft involving multiple pieces of information, you’re in for: • a lot of work. • small chance of success of recovery. • Thus, people are less likely to do anything. • Dozens of federal agencies doing piecemeal work. • ID is an afterthought in general, relegated to some “Customer Relations” dept.

23. Federal Level (contd.) • There is also the Identity Theft and Assumption Deterrence Act (1998), -> 18 U.S.C. §1028 • For all intents and purposes it’s pre-internet. • Makes certain violations a felony. • Allows the FBI to get involved. • Somewhat strong “in theory” (up to 15 years). • Discrepancies between businesses and individuals.

24. State Level Legislation • Mostly a patchwork of laws. • About 16 have financial freeze laws. • Prevents thieves from obtaining new credit. • About 23 have “security” breach notification statutes. • All passed in 2005, effective in 2006. • California led the way, starting in 2003. • Alerts victims (usually) only when there is harm.

25. Best & Worst States • Best: • North Dakota • South Dakota • Maine • Worst: • Arizona • Nevada • California • (All deserts…?)

26. Legislative Problems • The law tends to move slowly. • It is very difficult for the govt. to follow technology closely. • Witness DOJ v. Microsoft, where it was clueless. • On the internet, the problem is a fast arms race. • Spammers vs. Email Filters • Viruses vs. Anti-Viruses • Phishers vs. Phishing Databases • The law usually can’t get technical enough to be practical. • Results in vagueness. • Thus may not be enforceable.

27. Original Solution Proposed

28. Client-Side Transactions • End user controls the flow of personal information, not the relying party (online service that relies on identity claims) • Example: ordering a book from Amazon • temporary financial transaction IDs • shipping transaction ID

29. Client-Side Transactions • Addresses: • (2) Inconvenience: client-side interface would mediate all sensitive information transactions; manage multiple accounts in one place; no need to remember (strong) passwords for each account • (3) Inconsistency: standardized means of disseminating personal information • (6) Propagation: only supply relying parties with necessary information • (5) Insecurity: doesn’t rely on weak, user-created usernames & passwords

30. Client-Side Personas • Relies on Client-side Transactions • Create multiple personas • Locally or on ‘naïve,’ encrypted stores on remote servers (not restricted to local machine) • Limit the propagation of sensitive information by generating unique GUIDs and strong passwords

31. Client-Side Personas • Addresses: • (1) ID Unreliability: personas can be government-trusted • (4) ID Persistency: unique GUID can automatically authenticate sessions • (7) Intrusion (via ‘participation’): incoming communications only from trusted users

32. Oh, wait…uh…wow.

33. Existing Technological Solutions

34. Microsoft .NET Passport

35. Microsoft .NET Passport: Problems • Online services had to pay a subscription fee • Single point-of-failure • Do we trust Microsoft to take part in all of our online transactions? • No context-based identity

36. Enter: The Liberty Alliance • 2001: Sun, Sprint, Sony, Verisign, eBay… • Single sign-on system based on a “circle of trust” • Federated identity • Aggregating personal information across multiple systems • Authenticating a user across multiple systems • Exchanging claims via SAML, the Security Assertions Markup Language • Focus on identity systems for corporate environments, not individual Internet users

37. SAML Tokens • Represent security credentials using XML • A way of creating an distributing authentication and authorization assertions • Three distinct types of assertions: • SAML authentication assertions: subject, method, time • SAML attribute assertions: associates subject with attributes • SAML authorization assertions: associates subject with resource permissions

38. Federated Identity with SAML - Pull Profile 1 4 airline.com 2 5 3 User rentalcar.com

39. Federated Identity with SAML - Push Profile 1 airline.com 2 3 User rentalcar.com

40. Secure Transfer of SAML Tokens • A secure communication between two authenticated parties must follow the principles of: • Non-repudiation • Data integrity • Confidentiality • XML Encryption: confidentiality • Sender generates random shared key • Sender encrypts message using shared key • Sender encrypts shared key using recipient’s public key • Sender sends (1) and (2) to recipient

41. Secure Transfer of SAML Tokens • XML Signature: non-repudiation + data integrity <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> <Reference URI="http://www.yale.edu/index.html"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0E~LE=</SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName> <X509Certificate> MIID5jCCA0+gA...lVN </X509Certificate> </X509Data> </KeyInfo> </Signature>

42. More Recent Developments

43. URL-Based Identity Management: OpenID • User enters identity URL at the relying party • Relying party redirects browser to identity URL • User logs in at identity URL • Identity URL verifies relying party by checking access control list • Identity URL sends security token back to browser • Browser redirects security token to relying party • Relying party verifies security token directly with identity URL

44. URL-Based Identity Management: SXIP • Similar to OpenID, but adds functionality for profile exchange • Centralized way of managing personal information • Multiple personas • Updating personal information • SXIP 2.0 extension: support for trusted claims • i.e. verified e-mail address

45. Pros and Cons of URL-Based Identity +Uses existing web & browser technologies + Easy to adopt: no new software needed + Accessible from anywhere —Inconvenient typing of URLs —Open to phishing attacks —Trusted claims?

46. The WS-* Architecture: An Identity Metasystem • IBM and Microsoft, working with OASIS • An “Identity Metasystem” to create an open identity architecture that allows older identity management systems to work alongside new advances in identity technology • Set of protocols for distributing claims • Components • Negotiating protocols • Transforming claims

47. Implementing WS-*: Microsoft InfoCard • InfoCard identity selector GUI: a client application allowing user control of digital identities (which are comprised of claims) • InfoCards are encrypted XML documents • No actual identity information is stored in them • Identity information stored with Identity Providers • Contains means of accessing claims • Metadeta that describes claims associated with the digital identity • Identity technology (SAML, X.509, Kerberos?) • Issuer (Verisign, Thawte, self-issued?) • Unique identifier

48. InfoCard Demo

49. InfoCard Typical Usage Scenario

50. InfoCard Typical Usage Scenario (cont’d)