Post on 21-Dec-2015
transcript
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
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
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
• 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.
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
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
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>
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 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.)
• 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?