Notes on Distributed Identity, etc.

OSAF's use cases

Calendar sharing

The main use case OSAF has for distributed identity is to share calendars outside of the set of normal users on the sharer's home server. This is the case we use tickets for in Chandler 0.6 and 0.7, but we'd like access to something more secure in the long run. There are many minor variants on the use case, sharing personal and group calendars, sharing read/write, read-only, or just free-busy information. Ideally, we want:

• The initial owner of the calendar, who chooses to share it with another user, needs to be able to identify outside users somehow. One of the most useful identifiers would be email addresses or addresses of the same form.
• The outside users need to get reasonably easy access to the information that's been shared to them. They need to be able to prove their identity fairly securely but without having to get yet another account on the calendar server.
• The server administrator needs something easy to administer and reasonably secure.

Access to calendar services (and other shares)

Once we see more standard formats for calendar data on public sites (e.g. venue schedules, sports team schedules big and small, speaking engagements and arts programs), Chandler users will want to subscribe to those calendars. But often the service provider wants some kind of user identifier to allow access to this content, whether because the content is somewhat sensitive, or because the service provider wants to have some way of tracking usage (for advertising revenues, for example). To date, the main way of tracking user information has been for each user to get yet another account on each service. That's why I have an account on Yahoo for my quilting group calendar and would need additional accounts on Meetup and Eventful if I wanted to use those services much. I have created accounts for W3C workshops and for ApacheCon^? attendance, then used calendar and other shared data from those sites to plan my attendance.

The ideal here is for those services to either grant me accounts on their service, or to allow me to use an identity from some other authority to track my access. Perhaps I could use

• a work-provided identity vouch-safed by an OSAF server, for use registering for ApacheCon^? or W3C workshop
• my Yahoo 'mad_knitter' account to provide a fairly anonymous identity for use on sites like Meetup
• an identity vouch-safed by my home Internet service provider for other non-work use

Single Sign-On and Federated Identity

Single sign-on is the ideal within many enterprises that want to reduce password/account management costs and increase usability. "Single" means that for any corporate application (including email, calendar), the user has only one account and sign-on.

A goal that goes a little further is that ideally the user should only have to sign on once during a session in which the user starts several different applications.

• Improves usability further: fewer application login screens to deal with, and possibly simpler server preference settings
• Improves security further: fewer application servers need to know the user's password, fewer protocols transport sensitive authorization information, thus fewer targets for hackers (like a house with fewer doors)

Federated Identity

This concept seems of greatest use to universities, who want not only single sign-on within a university, but also the ability to share credentials with other universities etc. Course sharing is one of the use cases for this -- a student at one university shouldn't need to get an account at other universities too in order to take shared courses.

The term federated seems to indicate that there may well be an explicit trust relationship between each pair of universities. Administrators might setup or approve the relationship and set limits on what non-local identities are allowed to do.

Shibboleth and SAML

Shibboleth is the name of the overall Internet2 system for federated identity. Security Assertion Markup Language (SAML) is one of the components of Shibboleth and other systems -- it's the data format (like iCalendar is for calendar data).

• Jump to a quick example

Some Shibboleth implementations only work for Web pages. Partly that's because the Web allows servers to run this process without requiring any client-side support for new authorization mechanisms. The Web allows this because of forms and redirects

• Demo and diagrams

Simple Web-scale distributed identity

One problem with these from the user's point of view is that they only work for the cases that an administrator has setup. It's not going to help a university student use their university identity to get a book discount at Amazon. Still less is it going to solve our use cases above such as letting me use my OSAF identity to register for ApacheCon^? and see the speaker calendar. So now we try to imagine systems that work on Internet-scale.

• YADIS is Yet Another Distributed Identity System?
• YADIS marries LID, OpenID and [http://en.wikipedia.org/wiki/Iname][inames]]
• SXIP is similar

All of these share the following characteristics:

• Identities are in the form of an HTTP URL
• They have relying parties which want some kind of identity for users but don't need to maintain it
• They involve identity service providers who vouch for an identity
• Relying parties redirect to the identity service provider (based on the domain in the identity URL)
• Identities are verified by asking for a password
• Use is redirected back to relying party

Quick demo

• Try "http://mylid.net/osafdemo" login at NHIN Wiki
• Note anti-phishing warning!

Phishing

The recent W3C Workshop on "Transparency and Usability of Web Authentication" had a lot of material on phishing and anti-phishing proposals. Recall that phishing happens when users get email convincing them to click on a link that they believe will be Paypal, EBay or some other site. But this happens not only through email, but also when one Web site convinces the user to click to another and provide their account information.

The flexibility of HTML (or any similar thin client interface) means that it's trivial for a hacker to make their site appear to be Paypal, EBay, etc. Anything inside the display frame can be spoofed -- and some things outside.

Some of the anti-phishing proposals use browser "chrome":

1. Centralized site whitelists could be maintained, and when the user visits a whitelisted site, the fact that it's known shows up in the chrome of the browser (e.g. next to the 'lock' icon)
2. Pet names has the user assign a private nickname for frequently-visited Web sites. If after visiting a known site the user doesn't see their petname they know they're being phished.
3. Shared bookmarks were suggested as a way of showing well-known sites.

What are the possible flaws with this? Well, users already have browsers with information about sites they visit frequently and log into: pre-filled login forms. What do users do when they encounter a form that's blank? They fill it in. It's too easy to unthinkingly fill in forms, and there are too many perfectly good reasons why the form might be empty or the site look oddly different today and login fail. Some HCI research is being done here though it's only beginning.

• Phishing IQ test
• Garfinkel and Miller, 2006, Do Security Toolbars Actually Prevent Phishing Attacks?

"We evaluated three types of security toolbars, as well as browser address and status bars, to test their effectiveness at preventing phishing attacks. All failed to prevent users from being spoofed by high-quality phishing attacks.

"Users fail to continuously check the browser’s security indicators, since maintaining security is not the user’s primary goal. Although users sometimes noticed suspicious signs coming from the indicators, they either did not know how to interpret the signs or they explained them away. Many users had no idea how sophisticated an attack could be, and do not know good practices for staying safe online."

Phishing relating to Distributed Identity

There are two ways phishing and distributed identity systems relate:

• Distributed Identity can make phishing harder or easier
• Distributed Identity can make the rewards of phishing bigger

So it's really hard to say if distributed identity will make the situation better or worse, overall.

More ambitious Web-scale distributed identity

Microsoft Infocard

• Compare to Passport
• Create new card screenshot
• Choose chard screenshot

* Google's requirements for contrast

* Identity Based Encryption

• Stanford research initially -- Dan Boneh
• Based on an email address
• Voltage^?

HTTP Authentication problems

• Limitations of basic and digest
  • Both use passwords?
  • Limits of flexibility in Digest aren't clear
  • Limited interop beyond the core uses

• Proposed work to replace MD5 algorithm

• No binding for SASL to HTTP
  • SASL fundamentally designed for connection-oriented protocols

• No common way to log off
  • Problem for rich clients at least, maybe for browsers too

• Distributed identity would need some way of providing remote identity
  • Rich clients can't use forms and redirects

Summary

• Big problem space, big solution space
• Lots of moving pieces
• Many, many interoperability concerns: mail, IM, HTTP, *DAV
• Many standards organizations already involved: IETF, OASIS, Liberty

-- LisaDusseault - 09 Apr 2006