A couple of months ago, I spoke with a security researcher at a conference about the NSTIC. He questioned the need for an intermediary to manage users’ identity information; he asked why we don’t just do this at the user’s endpoint, eliminating the need for the user to trust an external party. This is a good place to begin a discussion about the NSTIC architecture.

An intermediary, usually referred to as an Identity Provider (IdP), represents the subject (user) in transactions. In the NSTIC model, the IdP is operated by a third party that is chosen by the user. A user would want to choose an IdP operated by an entity they trust, one that is very secure and reliable, and is accredited for the strength of authentication required for the range of transactions the user expects to require. Depending on their need for high-assurance identity for the kinds of things they do online, they might also want to choose an IdP that is accredited for that level of trust.

The alternatives to a third-party identity provider are either to operate the identity system without an IdP at all or with one operated directly by the user.

In the absence of an identity provider, we are basically where we are now. Users are forced to keep track of a large number of credentials, typically one for each service, including at least an identifier and either a password or some other authentication device such as a token. The management of these credentials can be a substantial burden. If they use passwords for authentication, there is a tendency to use the same password on multiple services, placing all at risk if any of them is compromised. If the user uses hardware tokens or smart cards, they would need to carry as many as necessary and keep track of which to use in each situation. Of course, these tokens could be standardized and used for multiple services but that would put some token service in a de facto position as an IdP.

An identity provider could be operated directly by the user, probably directly on the user’s endpoint. This solves the credential management problem but introduces new problems if that endpoint is compromised, lost or damaged. The risk of compromise can be mitigated by encrypting the credentials on the endpoint, but would still be vulnerable to a multi-pronged attack (key logging and theft of the laptop, for example). Loss or damage to the endpoint can be mitigated by backing up the credentials securely, but the track record of the general public when it comes to such best practices is poor. This also limits the user to the use of that endpoint for all transactions, which becomes a problem for use cases that don’t involve traditional endpoints.

An IdP also performs the important privacy function of providing “safety in numbers.” As part of its function, the IdP substitutes the identifier used to authenticate to it with an opaque per-relying party identifier. This opaque identifier, in the absence of attributes identifying the user, provides pseudonymity and discourages correlation of the user across multiple services. But suppose instead that the IdP represents exactly one user. In that case, the choice of IdP alone provides a correlation handle that defeats pseudonymity. On the other hand, if there is only a small number of IdPs from which to choose, the likelihood that there is one with a high degree of user trust decreases and the concentration of trust in a few parties becomes a concern. For this reason, there is a “sweet spot” between having a few IdPs with many accounts or alternatively having individual IdPs per user or perhaps per family.

An IdP can also fulfill an important security function by monitoring usage patterns for suspicious activity. Suppose I authenticated from California and a few minutes later authenticated from someplace far away: I’d like to get an alert about that, much as my credit card provider alerts me of suspicious activity. This makes some people nervous on privacy grounds, so perhaps they want to use an IdP that doesn’t do that. That’s another reason that IdP choice is important. Overall, while the use of an intermediary introduces new security risks, it provides new opportunities to improve security as well.

2 Comments.

There's one really big hole here. "National Strategy" suggests government approved, which implies backdoors. At the very least, copyright and patent maximalists will insist on an easy-unveil mechanism to facilitate enforcement of their restrictions.
As the leader of Greece found out a few years ago, this is a perfect recipe for devastation when someone learns how to access these backdoors. Past experience shows that bad guys will find ways to do this.
Like Social Security numbers, giving people a single "identity" (really identification, as identity is internal and also varies depending on the situation) is just going to make it easier for online bad guys to do more damage at one time. Because we assign so much power to that one number, students have to give the number to schools or colleges, employees have to give it to employers, borrowers have to give it to lenders, renters have to give it to landlords. At any of those points, this all-powerful code can leak, with devastating consequences for the victim.
This single identity, with backdoors and easy-unveil capability, is likely to become a required part of posting user-generated content online (including comments like this one). This is almost guaranteed to result in negative consequences for anyone whose opinion varies from the official line as issued by the person's workplace, by the major media, or by government officials.

W^L+:
The term "National Strategy" is perhaps an unfortunate choice for something the Government isn't actually operating, but rather acting as a convener and adopter.
The distributed nature of an NSTIC identity between an identity provider and multiple attribute providers I believe will make it harder to install backdoors since they would need to be in multiple places. Identity systems are still subject to legal process (at least for the jurisdiction in which they reside) but that is true regardless of the system architecture or who runs it.
With NSTIC, you wouldn't be giving a global identifier to schools, employers, lenders, and so forth. Rather, you would be directing your identity provider to assert a new unique identifier to those parties. This is referred to on page 12 of the Strategy where it seeks to "minimize the ability to link credential use among multiple service providers." There is no new all-powerful identifier created.
Thanks for your thoughts.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.