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 gt
• 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?
• identity 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 propagation of sensitive
  information.
• Very prone to leaking.
• Leaks are also vulnerable to weakest link.
• E.g.
• Amazon (likely secure) gt Shady Vendor
• Amazon (likely secure) gt 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, youre
  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), -gt 18 U.S.C. 1028
• For all intents and purposes its 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 cant 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 doesnt 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, waituhwow.
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 recipients
  public key
• Sender sends (1) and (2) to recipient

41
Secure Transfer of SAML Tokens

• XML Signature non-repudiation data integrity

• ltSignature xmlns"http//www.w3.org/2000/09/xmldsi
  g"gt
• ltSignedInfogt
• ltCanonicalizationMethod Algorithm"http//www.w3
  .org/TR/2001/REC-xml-c14n-20010315"/gt
• ltSignatureMethod Algorithm"http//www.w3.org/2
  000/09/xmldsigdsa-sha1" /gt
• ltReference URI"http//www.yale.edu/index.html
  "gt
• ltDigestMethod Algorithm"http//www.w3.org/20
  00/09/xmldsigsha1" /gt
• ltDigestValuegtj6lwx3rvEPO0vKtMup4NbeVu8nklt/Di
  gestValuegt lt/Referencegt
• lt/SignedInfogt
• ltSignatureValuegtMC0ELElt/SignatureValuegt
• ltKeyInfogt
• ltX509Datagt
• ltX509SubjectNamegtCNEd Simon,OXMLSec
  Inc.,STOTTAWA,CCAlt/X509SubjectNamegt
• ltX509Certificategt MIID5jCCA0gA...lVN
  lt/X509Certificategt
• lt/X509Datagt
• lt/KeyInfogt
• lt/Signaturegt

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 (contd)
51
InfoCard Benefits and Problems
52
InfoCard Benefits

• 1. Unreliability
• Infocard makes it possible to identify people,
  and is agnostic of physical authentication.
• Roughly 2 levels
• Self-issued ID -gt weak
• ID from a certified provider -gt strong
• 2. Inconvenience
• No need to memorize passwords, create multiple
  accounts, register manually at sites.

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

54
InfoCard Benefits (contd.)

• 4. Impermanence
• Infocard automatically handles things like log-in
  and expiration, so theres 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.

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

56
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 dont send the information they dont need.
• The result is less of your data flying around.

57
InfoCard Benefits (contd.)

• 7. Intrusion / Participation
• Infocard does not address intrusion directly.
• You can use infocard and still get email spam.
• However, lets 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.

58
Potential InfoCard problems

• Perhaps a false sense of security
• Infocard doesnt 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 didnt work so well gt IE6

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

60
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 arent 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.

61
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

62
Other Infocard Improvements (contd.)

• Authentication
• Infocard is more or less agnostic about physical
  authentication.
• The assumption is that if youre 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?