Digital Identity Management on the Internet

Digital Identity Management on the Internet

Al Gutierrez and Will Tsui

CPSC 457Spring 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

• 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

Client-Side Personas

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 environments, not individual Internet users

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

airline.com

rentalcar.com

12

3

4

5

User

Federated Identity with SAML - Push Profile

airline.com

rentalcar.com

12

3User

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 key1. Sender encrypts message using shared key2. 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-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>

More Recent Developments

URL-Based Identity Management: OpenID

1. User enters identity URL at the relying party2. Relying party redirects browser to identity URL3. User logs in at identity URL4. Identity URL verifies relying party by checking access

control list5. Identity URL sends security token back to browser6. Browser redirects security token to relying party7. 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.


• 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.


• 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.


• 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.


• 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.)

• InterfaceIt 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 AutomationOne 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?

Documents

Digital Identity Management on the Internet