1 / 62

Digital Identity Management on the Internet

Digital Identity Management on the Internet. Al Gutierrez and Will Tsui CPSC 457 Spring 2006. Intro. Internet: simple end-to-end design Dumb, minimal network: only connects devices Improving technology => More high value transactions More accounts at online services

agalia
Download Presentation

Digital Identity Management on the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related