Making sense of the National Strategy for Trusted Identities in Cyberspace (Part I: Problem Description)

| Comments (6) | COMSEC
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.

6 Comments

My guess is that the underlying agenda isn't improving security but rather accountability. If the third scenario can be made easy and convenient, then it would lower the bar for services to switch from the first scenario to the second one, based on real-world identity. For example, Facebook, as you say, doesn't really try to verify real-world names because it would be difficult and annoying to users to do so. But if that changed, then maybe Facebook would actually verify users' real-world names. This obviously wouldn't do anything to protect Facebook accounts from being stolen, but it would, for example, make it more difficult for someone to get away with doing illegal things using a Facebook account. (Yes, one could always claim that one's Facebook account--or one's NSTIC identity, for that matter--was stolen, or just steal someone else's Facebook account and do mischief with it in their name. But both of these are more difficult to accomplish and get away with than simply creating a pseudonymous Facebook account and doing mischief with it.)

My guess is that the underlying agenda isn't improving security but rather accountability. If the third scenario can be made easy and convenient, then it would lower the bar for services to switch from the first scenario to the second one, based on real-world identity. For example, Facebook, as you say, doesn't really try to verify real-world names because it would be difficult and annoying to users to do so. But if that changed, then maybe Facebook would actually verify users' real-world names. This obviously wouldn't do anything to protect Facebook accounts from being stolen, but it would, for example, make it more difficult for someone to get away with doing illegal things using a Facebook account. (Yes, one could always claim that one's Facebook account--or one's NSTIC identity, for that matter--was stolen, or just steal someone else's Facebook account and do mischief with it in their name. But both of these are more difficult to accomplish and get away with than simply creating a pseudonymous Facebook account and doing mischief with it.)

"in order to do anything online you need to maintain a zillion different usernames and passwords" - the problem here is that a simple solution exists, but people are denied this by security gurus like you.

The solution: use the same username / password EVERYWHERE where real security does not count. I.e., use ekr / password1 in all places, or 430RDWDWD / password1 if you want anonymity. And stick to that!

Yeah, best practices tell you to use different credentials at different sites (or across different trust boundaries), but - why should you? The attack here is that site A can hijack your account on site B. But in real world, 1) they do not, and 2) it does not matter.

Places where it does matter - your work, your bank, gmail, and facebook - are exceptions, they should be handled differently, but they are really few. But for the rest of the net... just ignore security, and you are mostly done.

If you want to go really easy on your memory, then you can also have username = password. So I would use ekr / ekr instead of ekr / password1. Secure? No. But do most of those zillion places need real authentication anyway? Not really. So, let's just skip it.

The agenda of any .gov agency would be to expand the use of real-world identities into the space where pseudonyms would suffice. Or to spend money on brainwashing to make use believe that using real-world names would solve our problems.

Thus, the agenda of non-.gov agencies should be to prove the opposite. Most interactions in current real world do not require strong (mutual) authentication. Why should the virtual world ones differ?

Well, I don't recall denying anyone this solution, but maybe I wasn't paying attention or something, and I agree that the practice you suggest above isn't unreasonable.

That said, I don't know about you, but I actually have quite a large number of independent passwords that correspond to things I want kept secure, by the time you've added up banks, credit cards, amazon, etc. So while I agree that you can reduce the scale of the problem, you still end up with like .1 zillion passwords, at least far more than I care to remember.

NSTIC isn't just about managing authentication credentials.

Another function is the provision of trustable attributes regarding the subject (user). These attributes come from a number of attribute providers, who are accredited to provide certain types of information. Examples might include assertions of age (as you describe), residence (e.g., does this person live in this school district?), credit score, and so forth. These could come from both public agencies and private providers. These primarily support the third scenario that you describe, but that scenario might become more important as new use cases are enabled by the availability of these assertions.

Different levels of assurance will also be supported. Some use cases require really secure authentication, but many low-value transactions are sensitive to the added friction (complexity) of high assurance authentication. The relying party needs to be able to specify the nature of authentication it requires consistent with its risk profile.

Leave a comment