April 2011 Archives


April 27, 2011

Right now (yes, now!) Amazon has the Kindle edition of Consider Phlebas available for $.99. If you like space opera, Banks's Culture novels are generally a pretty good bet and while CP isn't my favorite, $.99 is a smoking deal. If you have a Kindle, that is. If not, the price is a somewhat less attractive $114.99 (and that's if you like ads).
On April 15, the Obama Administration launched their grandly named "National Strategy for Trusted Identities in Cyberspace" (NSTIC) (fancy site; document). NSTIC, which I propose we pronounce "niss-tick", is yet another in a long line of grand unified theories for Internet identity (does anyone but the government use the term "cyberspace"?). The framing of the problem should be familiar: in order to do anything online you need to maintain a zillion different usernames and passwords, which is a huge pain in the ass. Wouldn't it be nice if somehow that problem went away?

Unfortunately, there's a big jump from that to the globalized identity system that NIST envisions, which is straight out of the mid-2000 federated identity tradition (which. as we all know, was a huge success). I'll go into more detail about this in a later post but for those of you who aren't familiar with it, the idea is that there would be a whole bunch of "identity providers" that you would be able to sign up with. They'd give you some kind of credential which you could use to identify yourself to third parties (e.g., your bank). So, you'd have a choice of identity providers to sign up with and your bank would have a choice of which ones to trust and hopefully you'd meet in the middle. Moreover, the system would be designed so you could (somehow) use the same identity across all your devices and that the people you were identifying yourself to wouldn't learn more about you than they had to (the paradigmatic case here is proving you're over 18 without revealing your name). Presumably this would somehow be facilitated by the feds. The marketing term for all this stuff is "Identity Ecosystem".

As I said, these ideas have been floating around for quite some time as you can see from my comments on a previous such initiative. And as with previous initiatives, NSTIC seems to suffer from trying to conflate a bunch of different problems and use cases. In particular, while the "too many passwords" problem is evocative, there seem to be a number of different scenarios hiding behind it. As far as I can tell, the majority of user oriented 1 online authentication use cases fit into one of the (unevocatively named) categories below. I'm going to frame these in the Web context, but they obviously apply generally.

  • Continuity of Identity (aka pseudoynmous accounts). A very large number of the authentication transactions you do don't require the relying party (i.e., the Web site) to have any real notion of who you are. When you store photos on Flickr, the primary concern is that you have some unique identity and that the same person is accessing your account from day to day. I.e., that nobody else can post pictures as you. Even systems like Facebook which ask for your real name don't make any significant attempt to verify it. So, what's inconvenient about a new interaction with a site like that is that you have to go through the ceremony of choosing a new username and password with them which you then have to remember. Lowering this entry barrier is one reason that sites often just use Facebook Connect for authentication even though it involves giving up account control to Facebook.2
  • Binding to Existing Accounts. The second major case is where you already have some account relationship with a provider (e.g., your bank). Nearly all these providers already have a mechanism for remotely establishing your identity because they want to be able to interact with you over the phone. The problem here isn't too different from the previous problem, except that we want to not only establish continuity of identity but also somehow bind it to their existing account. So, for instance, when you get a new credit card, you log onto the site and authenticate with the card number, your SSN, address, etc. and then create an account exactly as you would with Flickr; the difference is just that that account is then tied to your existing relationship.
  • Establishing Real-World Identities. The final case to consider is where you want to establish your real-world identity to someone who you have no prior relationship with. This actually happens surprisingly rarely, but it does happen. Consider the case where you want to sign up for a credit card online with a company you don't have a relationship with. You give them all sorts of identifying information that isn't really that hard to guess (hence identity theft). If you had a credential attesting to that information, then they would be able to independently verify it and that would potentially make identity theft harder. That credential has to come from someone outside of the site because they don't have any relationship with you yet. Of course, once you've proved that information once, then any further interactions are back to the continuity of identity case.

I don't claim that this is a complete (or the only) taxonomy but I think that it does capture the bulk of the relevant scenarios. To me, what's most striking here is that the two scenarios which are the bulk of the interactions don't really need any kind of centralized or federated authentication infrastructure at all. Rather, the problem is that our existing distributed pairwise authentication technology (usernames and passwords) isn't up to the job. There has actually been quite a bit of work on enhancing the browser platform to support better mechanisms (e.g., less unpleasant SSL/TLS client certificates) and while it hasn't really gone anywhere, it's not clear that the UI/UX and deployment challenges that have stalled those avenues are any less severe for a federated identity system of the kind described here. Indeed, one of the attractive features about Facebook Connect is that it has comparatively little UI impact, though you also probably aren't that excited about anyone who has your Facebook credentials being able to suck money out of your bank account.

The third scenario is where the meat is, but as far as I can tell it's the one that happens the least often. If we were able to solve the bilateral authentication problem adequately, we could probably limp along with the existing lame mechanisms for doing the initial binding to your real-world identity. This is especially true because we're going to need to support lower-tech (i.e., voice-only) transactions for a long time, so if we're concerned about the security of the system as a whole it might be better to work on mitigations that apply to both cases.

So much for the motivating cases for this effort, which I think are fairly lacking. I'll have more to say about the proposed structure and implementation in future posts.

1. The other set of cases that this document considers is not user-oriented at all, but rather provider oriented. On Page 8, they suggest that you could use this stuff to authenticate "Smart Grid" electricity meters to electric companies and vice versa. There's nothing wrong with this, but it doesn't require any kind of identity ecosystem. The smart meter is installed by the power company and they can easily establish shared credentials with it at the time of install and deployment. I have no idea what this "Envision It!" box is doing here.

2. It's worth noting that a number of these sites do attempt to verify real-world identity in the form of email address, but the major uses of that verification are for password reset and preventing the creation of large numbers of accounts for use by spammers, so you could imagine getting these services in other ways.


April 23, 2011

Today's update on cool stuff on the Internet:

OK, so the last one probably isn't as good, unless you're some kind of serious nerd. But check the first two out.


April 12, 2011

I've done a whole pile of flights since my last update on airport whole body imagers. I've flown out of SFO a bunch of times and SJC once. Pretty much every time they've had whole body imagers of one type or another but each time they're only in some fraction of the lines (with the rest of the queues just having magnetometer), so you can pick a line that has the magnetometer. At some checkpoints they do have someone directing you to a specific line, but so far nobody has actually managed to direct me to the imager.

In other news, SJC's new Terminal B is really nice. Aside from just being generally modern, they now have power at something like half the seats (though they don't look that comfortable). (See here). Plus there's a Jamba Juice. Seems like a small thing but considering that your best breakfast option at SFO is an overpriced Peet's small things can matter.


April 7, 2011

As I said earlier, DANE faces serious deployment hurdles, even in certificate lock mode: it works best when the records are signed with DNSSEC, and even if you deploy it without DNSSEC, which is tricky, it only provides protection to clients which have been upgraded, which is going to take a while. Phillip Hallam-Baker, Rob Stradling, and Ben Laurie have proposed a mechanism called Certificate Authority Authorization (CAA), which, while more of a hack, looks rather easier to deploy.

With CAA, as with DANE, a domain can publish a record in the DNS that says says "only the following CAs should issue certificates for me." However, unlike DANE, the record isn't addressed to clients but rather to CAs. The idea here is before issuing a certicate to a domain a CA checks for the CAA record; if there's a record and the issuing CA isn't on it, it doesn't issue the certificate. This mechanism has the advantage that there are only a relatively small number of root CAs and they have a relationship with the browser vendors, so the browser vendors could at least in theory insist that the CAs honor it, thus providing some protection to everyone almost immediately. Moreover, it's easier to recover from screwups: if you misconfigure your CAA record, all that happens is a CA can't issue you a new cert till you reconfigure your DNS, as opposed to your site suddenly becoming unreachable.

Obviously, CAA is inferior to DANE an end-to-end security perspective, as it relies on all the CAs behaving correctly. However, since the primary risk here is probably not intentional CA malfeasance but rather the comparatively weak authentication procedures many CAs use. However, if a CA is able to determine that under no circumstances should they be issuing a certificate for a domain, then the weakness of those authentication measures becomes somewhat less important. It's not perfect but it seems like a potentially worthwhile risk containment strategy, especially as it allows you to select a certificate authority whose security measures you trust, rather than having to rely on the security of the weakest CA on the browser root list.


April 6, 2011

Spent last week at IETF Prague and in a fit of stinginess decided to stay at the nearby Hotel Opera. It was generally OK, though you get what you pay for here, since the conference Hilton was rather nicer. (Important safety tip: the room I was in didn't have a shower, just a tub with a handheld wand, which isn't that great.) For future reference, the Jury's Inn is closer to the Hilton and a bit more modern (I've stayed at all three.)

Anyway, I'm on my way out on Sunday and I stop at the front desk to check out. The guy asks if I've used the minibar and I say "no" and he says something about how "We'll send someone up to check. Please wait." So, I decide to be neat and I have a seat and a few minutes later the dude they sent calls down and the guy at the front desk tells me everything is OK and I can go. Really, this doesn't make much sense, though. First, they collect your credit card (actually, I don't remember for sure if Hotel Opera did, but every other hotel I've ever been at does), so they can just bill it to my credit card without my help. Second, what happens if I just walk out instead of waiting for you to check the minibar, or if they discover I actually emptied it? They're going to call the cops to bring me back? This doesn't seem sensible. Finally, what stops me from just leaving without stopping by the front desk? So, I don't really understand what threat model this practice makes sense for.


April 4, 2011

Dear Twitter people,

It's not good when your site gets wedged so not only do I just get the title bar with no content, but I can't even log out to reset. Had to delete all my Twitter cookies to restore state. Outstanding!


Most people who have backpacked in the Sierras have gotten to experience the fun of the bear canister. Traditional bear canisters are a big cylinder (I have the BV 500, which looks like a gigantic Nalgene bottle). Canisters are serviceable in the sense that the bears don't get your food, but they're heavy (the BV 500 is 1.16 kg) and awkward to carry. Also, in a lightweight pack with a thin framesheet/pad or no pad at all the canister tends to deform the shape of the pack, leaving a ridge down the center of the pack and you with a sore back, so backpackers have been on the lookout for something new for a while. Until now, the best alternative was the Ursack a kevlar bag with an optional metal insert, but it's not approved for use in Yosemite or Sequoia Kings Canyon, so it's not entirely optimal.

About a year ago I ran into some guys at the climbing gym who were producing a new bear canister and it looks like they have now got it almost ready for market. The Camp 4 Outdoors Bearier 700 is a roughly spherical plastic container in two halves which clip together. The Bearier is lighter weight than the lightest plastic container (< 2 lbs for 700 ci) and seems to be comparable to the lightest canister, the carbon fiber Bearikade. Because it separates at the middle the system is modular so that you can add a ring (called the Grubhub) in between the halves to expand capacity by another 300 ci. In addition, because the halves separate and have a drawstring closure to keep your stuff in, they can be packed separately. In particular, if you want to keep them in your pack you can pack each hemisphere with the face towards your back, presenting a flat surface and thus hopefully reducing discomfort. The major drawback seems to be that it's not going to be as comfortable to sit on as a canister, though supposedly the ends are flat so you can if you want to. (See various comments here.)

I haven't seen one of these in person, only in pictures, so I don't know how it will fit in my pack. Also, they have yet to be approved by any of the relevant bear approving agencies, so it's premature to get too excited. Still, it looks like it might be a cool innovation.


April 2, 2011

Attention IETF readers: the Hilton Wi-Fi network is still accessible via the IETF credentials. I'm sitting in the lobby now waiting to go to the airport and getting better network connectivity than I had all during IETF week, what with noone else clogging the Intertubes.

Unfortunately, while Internet is free at the Red Carpet Club in San Francisco, in the Lufthansa lounge in Frankfurt, where I will be spending 2 hours today, it is the standard shockingly expensive service you've come to expect from T-Mobile.


April 1, 2011

Yesterday at the IETF SAAG meeting I watched (and then tore into) a presentation about a proposed PAKE authentication mechanism for HTTP. Regardless of the merits of this particular mechanism—and in my opinion they were pretty slight—it's not clear to me that any new HTTP authentication mechanism is going to have a significant impact on the browser authentication problem. [Note: I'm talking here about authentication for users in browsers. The problem is different for non-browser user agents.]

Currently the way that 99+% of Web authentication works is that you connect to the server (hopefully over HTTP) and the server gives you a login page with a password in an HTML form. You type your password into the form and click "submit" and the password gets sent to the server.

Let me start with two premises, that while I think not universally agreed on, are fairly uncontroversial:

  • Passwords aren't going away. Much as we might like everyone to use HTTPS certificate-based client authentication, for the foreseeable future the only credential that people have that's really portable from machine to machine and can be reliably used by servers is passwords.
  • Phishing is the big problem. If people use HTTPS and go to the right site, then passwords work tolerably well (especially if you use a password manager). At least they can be secure. However, passwords aren't very secure at all in the face of phishing.

PAKE systems (or even hash-based systems such as HTTP Digest or PwdHash) are supposed to protect against this threat since the server never gets a cleartext copy of your password. The idea here is that instead of providing a form the server would prompt the client for authentication. The client would then give the user some dialog where they could type in their password (in many cases, the expectation is that they would have a single password which, via the magic of cryptography, they can use with every site; see for instance [HWF05]). The client and the server would perform some cryptographic authentication handshake (without the client giving the server the user's password directly) and at the end of the day the client would be authenticated. In some, but not all, of these systems the client also gets to authenticate the server via the password, but that's mostly a nice to have rather than a hard requirement. The major advantage here is that if you visit the wrong site, the server doesn't learn your password and so can't impersonate you to others.

So, why isn't this that great? The difficult part is the phrase "some dialog where they could type their password". Remember that we're assuming that the user has visited the wrong site and so the attacker controls what they see inside their browser. The natural thing for the attacker to do is therefore to produce it's own dialog that claims to be the dialog for the new authentication mechanism, capture the user's password, and they're good to go. In order to thwart this attack, we need to have the dialog be distinguishable. I.e., it needs to look and/or behave in some way that the attacker can't imitate, even though he controls the web site that the user/victim is visiting. From a technical perspective, there are a number of mechanisms that will work. For instance, anything generated by the site, even if it's a popup, will appear wrapped in "browser chrome" (a frame, most likely, with a title bar) so you could tell the user never to type their password into a dialog box wrapped in chrome. Unfortunately, there is a lot of evidence that users actually don't make this kind of distinction very well (the standard cite here is [SDOF07]). The problem is made even harder by the fact that sites generally want to have a fair amount of control of the look and feel of the login experience, but that makes it even harder to build a UI which is reliably distinguishable.

Going back to the initial question, in my view the major problem here is the user interface/experience. If that problem were somehow solved there are a large number of protocol mechanisms that would significantly improve security. There's some question about what the best set of tradeoffs is between protocol complexity, backward compatibility, etc. but those are just standard protocol engineering issues, not something that's particularly difficult. However, until we solve that user interface problem, I don't see newer, more secure protocol mechanisms adding a lot of value.