COMSEC: April 2011 Archives


April 27, 2011

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