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 • Propagation of sensitive information • Consequence of existing identity systems: Safety and convenience of conducting Internet transactions not ideal What is digital identity? 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 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 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 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 Digital Identity on the Internet: Current Problems Problems with Current (Non-) Solutions • • • • • • • 1. Unreliability 2. Inconvenience 3. Inconsistence 4. Impermanence / In-transience 5. Insecurity 6. Propagation 7. Intrusion 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. 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 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. 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.” 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. 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. 6. Propagation • There is a vast propagation of 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.’ 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. Legal Situation 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. 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 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. 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. 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. 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. Best & Worst States • Best: – North Dakota – South Dakota – Maine • Worst: – Arizona – Nevada – California • (All deserts…?) 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. Original Solution Proposed 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 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 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 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 Oh, wait…uh…wow. Existing Technological Solutions Microsoft .NET Passport 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 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 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 Federated Identity with SAML - Pull Profile 1 2 4 airline.com 5 3 User rentalcar.com Federated Identity with SAML - Push Profile 1 2 airline.com 3 User rentalcar.com 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 1. Sender encrypts message using shared key 2. Sender encrypts shared key using recipient’s public key – Sender sends (1) and (2) to recipient 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-xmlc14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsasha1" /> <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> More Recent Developments URL-Based Identity Management: OpenID 1. 2. 3. 4. 5. 6. 7. 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 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 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? 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 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 InfoCard Demo InfoCard Typical Usage Scenario InfoCard Typical Usage Scenario (cont’d) InfoCard Benefits and Problems InfoCard Benefits • 1. Unreliability: – Infocard makes it possible to identify people, and is agnostic of physical authentication. • Roughly 2 levels: – Self-issued ID -> weak – ID from a certified provider -> strong • 2. Inconvenience – No need to memorize passwords, create multiple accounts, register manually at sites. InfoCard Benefits (contd.) • 3. Inconsistency: – InfoCard provides one unified, clean interface for managing identity. – The interface is rooted in the OS, not the browser. • Protected from assault via MPAPI. • It is not clear whether the interface will style itself over user-themes. – Basic concepts to understand: Cards & Claims. InfoCard Benefits (contd.) • 4. Impermanence – Infocard automatically handles things like log-in and expiration, so there’s no need to do it manually. – The system is independent of local HTTP requests, it runs in its own protected process space. Transitivity: – Infocard opens the door to the possibility of ID transitivity, via ID federation. – If you have an ID at provider 1 (e.g. Yale) and it is compatible with provider 2 (e.g. MS), they can federate the information. – The combined information will result in a stronger ID. • I.e. the person is a certified student and an employee. InfoCard Benefits (contd.) • 5. Insecurity – Depends on the strength of the WS-* implementation. – Nixing of password for security tokens eliminates a huge security problem. – System protected from a lot of local-machine hazards via OS-kernel level memory protection, process protection. – Implementation can keep up to date via automatic user-independent updates. InfoCard Benefits (contd.) • 6. Propagation – Infocard helps reduce the propagation of sensitive information by preventing the leak in the first place. – Uses a system of “claims” – You don’t send the information they don’t need. – The result is less of your data flying around. InfoCard Benefits (contd.) • 7. Intrusion / Participation – Infocard does not address intrusion directly. – You can use infocard and still get email spam. – However, let’s say you set a blog up, and it is Infocard compatible. • You can add as many claims as you want. – E.g. commercial interest, political affiliation. • You can ask for ID certified by educational organizations. – E.g. only college students may post. Potential InfoCard problems • Perhaps a false sense of security • Infocard doesn’t address the issue of Trust directly. • If you honor the claims of an unscrupulous vendor, your information still falls in their hands. • It might be difficult to reconcile strong organizational ID with weak individual ID. • Introduces deep OS-integration. – Last one didn’t work so well => IE6 Infocard and Anonymity • Infocard does not address anonymity. – The goal is the opposite: good ID. • But it does allow it – sort of: – You can use “bogus” (and weak) infocards. • However, this is problematic. – Inconvenient, – Pseudonymous – Still traceable at the network/IP level. Infocard and Anonymity (contd.) • Interface It would be good to support anonymous communication at the interface level: – Allow automatic client generation of bogus cards that aren’t linked. Use a different (new) one each time. – Allow individual infocard-level granularity for proxy support. • E.g. tell it to always use Tor/Privoxy when using one of your bogus cards, or combine with above. Other Infocard Improvements • Computer Automation One should be able to add CAPTCHA claims for weak / anonymous IDs. • Trust It would be highly convenient to link the claims of a vendor with trust-information providers. E.g.: - Community Sites. - Government databases? And Specially with organizations that people trust “in real life.” E.g.: - The Better Business Bureau (BBB). - Consumer Reports Other Infocard Improvements (contd.) • Authentication – Infocard is more or less agnostic about physical authentication. – The assumption is that if you’re properly logged on to your machine, you are the person owning those infocard. – Vista will help with this issue, but there is no provision for things like recovery (e.g. if your system is cracked). – Additional built-in support for smart cards, specialized hardware tokens, biometrics, etc. would be desirable. • Peer Review – Information is still changing quickly and is not widely available. Once finalized, experts should evaluate it to see its defects before it goes live. • What does Bruce Schneier have to say about it?