One of the main problems, as I see it, with security research is the chicken and the egg. Let’s say you come up with a snazzy new protocol, but this protocol requires a smart client (or modification to a browser). Additionally, you have some identity providers that are not terribly difficult to develop, but are not deployed. Now, how do you justify deploying all these modifications or new service providers if there are no clients to take advantage of them? On the other hand, how do you justify upgrading all the clients to support a protocol that has no identity providers?

The real answer is that you compromise. Either you find some company whose business model can benefit directly from the technology and have them be a champion, and hope that you can get enough marketing (yes you heard me, marketing) and people interested that it creates some momentum and adoption.

One of the coolest protocols I’ve read about is SRP. It’s the bomb, really. Password based, strong cryptographic properties, mutual authentication—both the client AND the service provider are authenticated, phishing attacks to obtain your password are not an issue. I could go on, it’s got some serious coolness. Additionally, some work at BYU shows how it can be extended to make it solve a lot of problems that OpenID is aimed at, without the drawbacks. (Heck, it even allows you to delegate access to other users.)

Problem is, SRP and its extensions require a smart client, and modification of service providers. Chicken and the egg. Drat.

Thoughts:

I’m wondering if it can be adopted by compromise, by providing a signed java applet to perform the smart client responsibilities for wireless authentication.

Another thought, what if you could get one half of the problem solved, like getting widespread deployment of the smart client, the other side could very easily drop into place.

Early Adopters

Interesting tech is usually adopted by the geeks before it goes mainstream. Now, not all things the geeks embrace make it mainstream, but a lot of things mainstream were solidly in geek territory in the beginning. One way to get early adopters is to:

• make a polished smart client for the linux desktop (gnome/kde)
• on the server make your software as easy to use as an apache module etc.

The key is real solutions that at least the geeks can use today.

Ride Someone Else’s Coattails

OK. Everyone agrees that smart phones/smaller devices are going to be a key part of the foreseeable future. Why not use this trend to lift usable security mechanisms out of their academic tar pit? Just to be controversial I’m going to say Android is going to be huge. What if someone stepped up, and implemented this slick, efficient, just-what-the-doctor-ordered password smart client for the Android platform that happened to support SRP? Let’s say it took off like the iPhone, I think it is realistic to see broader adoption of SRP across the board if, in a year after launch there are 90 million installed clients with active users.

HassleMe is a cool looking free service that I ran into recently.

Not eating enough fruit? Forgot to feed the fish again? Need a little help keeping your New Year’s resolutions? Tell us what to hassle you about, and we’ll nag you via email at semi-unpredictable intervals.

I like the simplicity of it. I also like that you can configure a rough timing scheme. I could see myself configuring a ‘hassle’ everyday for only a short time. Either it would get ingrained into my head to do the thing everyday and I wouldn’t need the nagging anymore or it would be too much and the virtual nagging would become a little too real.

It would be fantastic for things that don’t happen quite as frequently. I know I’m no the only one that on occasion realizes that a month has passed by without me knowing.

Methinks the integration can go just a titch deeper – instead of just reminding, allow the notification to be actionable. For instance, if I mail you a reminder to blog, if you respond to the email, your response could be posted directly to your blog. Same goes for a journal.

An identity system with a delegation mechanism is really needed here. If I really want this service to post to my blog, well, I shouldn’t have to give it my blog password. I should be able to grant access to an application (the reminder service) to post a blog entry or whatever else without me disclosing my password. AtomPub can get us a lingua-franca to converse with all these web services, but it doesn’t provide the identity part.

You know how a lot of people, when they post presentation slides, say that it’s really difficult to “get” the presentation from just the slides? Well I mean it. Seriously. My slides have very few words. If you’re still interested, be sure to check out the actual paper (pdf).

I don’t use PowerPoint or the like, instead I use a XUL application that runs in any Mozilla based-browser (like Firefox, Camino, Netscape etc.). In order to see the presentation, you’ll need to use one of those browsers.

This presentation was given at the Digital Identity Management Workshop of CCS in Virginia on 2 November 2007.

Reputation Presentation at DIM 2007

To download the presentation to view it locally I’ve also bundled it into a zip file

These slides were presenting the paper Using Reputation to Augment Explicit Authorization

The essence of our argument is that there is a spectrum of authorization approaches.

• no authorization
• authentication as authorization (where you can do anything if you are only able to log in)
• explicit authorization where someone has to manually grant access to another person.

The first two can be automated, no manual intervention required. The gap between the second and third is considerable. We believe that reputation can be used to bridge that wide gap giving systems many characteristics of explicit authorization in an automated way, so that the system itself can be self scaling (in terms of authenticating users).

UPDATE By popular demand the presentation is also available in PDF form .

The summary:

MountainWest RubyCamp 2007
Saturday, November 17th 2007
1:00 PM – 4:00 PM
Salt Lake City Library
Level 4 Meeting Room

The organizers have asked that if you’re coming to put your name on the wiki page

I’ve never been to a “Camp” before but I hear they are like “unconferences”. I go to the Internet Identity Workshop which is an unconference, and the results have been fantastic. Those who come are actively involved in the discussion, it’s quite refreshing.

I don’t know if I will present or not. I could lead a discussion and get people up to speed with the digital identity landscape—OpenID, CAS, InfoCard and some secret sauce :)

If you’re interested but a little put off that it is specifically about “Ruby” you should come anyway. Ruby is a good excuse to get together and rub elbows, it’s not an excuse to exclude interesting people or ideas.

There are two main types of authentication systems, credential based authentication and relationship based authentication.

An example of a credential based system is your driver’s license. When I present my driver’s license I am presenting a hard-to-forge token from a trusted third party, in this case the government. Since you know it is hard to forge you are comfortable accepting that it is indeed from the state of Oregon, since the biometric is printed directly on the token you are comfortable accepting that I am subject being asserted and so you accept that as identification. You don’t need to call the Oregon DMV or contact them in any way. You have the credential and can verify it with just the information available.

An example of a relationship based system is your credit card. The card itself doesn’t carry any money on it—the merchant must contact the issuer of the credit card on every transaction. The credit card is basically a note saying, “call Discover, this is my account number to ask them if I have sufficient funds for this purchase”. The merchant actually calls up Discover, asks them if I have sufficient funds and Discover says “yes” or “no”. Discover must be contacted on every transaction. Without contacting Discover, the merchant can’t verify anything.

Even though a lot of identity systems are a mixture of these two, the essence of the protocol falls into one of these two camps.

OpenID is a relationship based system. To log into a website, you present your OpenID, a url, which is basically a note telling the website who your identity provider is (you lookup the url to obtain the XRDS service document that contains this information). The website hasn’t necessarily run into this identity provider before so it must decide if it trusts it enough for what the application is providing.

InfoCards are mostly credential based. A website or service presents at login identity providers it will accept. After the user selects an appropriate card the card selector contacts the identity provider and obtains credentials. The assertions are signed cryptographically by the identity provider’s private key (hard to forge) and are given to the original website. The website verifies the assertions by checking the signatures with the identity provider’s public key.

Credential based systems:

• assertions are hard to forge tokens
  • usually comes down to something based on the Public Key Infrastructure (PKI) (cryptography)
• credentials are difficult to revoke (that’s why InfoCards limit the time assertions are valid to mitigate this)
• we don’t have to contact the issuer of the credential to verify it
  • can work offline
  • performant

Relationship based systems:

• assertions are just another party saying “yes” or “no”
  • Not dependent on PKI (although you do need to know that the identity provider is who they say they are)
• credentials are easy to revoke—the next time the question is asked the identity provider says “no” and they will be asked on the next transaction
• we must be able to contact the issuer on each transaction.
  • must be online
  • verification is “slower” than verifying a credential (contacting someone else is slower than just verifying locally)

PKI has been around for a long time but has not caught on with the public in general. It’s hard enough for geeks to get right. Relationship based systems are very natural, they model how a lot of things work in real life. In later posts I’ll write about some of my latest work—taking things that are possible with credential based systems but aren’t available for general use and seeing if I can tweak them into something feasible using relationships in the hopes that it could actually become generally available.