Identity Intermediaries and the NSTIC
This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.
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.