The identity crisis (3) - Trust.

Systems for identity management suffer from severe security, privacy and usability issues. A few of them I have discussed previously. Today I will discuss trust. Trust assumptions in identity management are ill understood, and this leads to interesting security problems.

Trust (like privacy) is a bit of an illusive concept (and really a subject for a separate blog post). We will not present a thorough discussion of the notion of trust in this paper, but refer to Trustguide: Final report instead. For our exposition the following informal definition is sufficient.

Entity A trusts entity B in X if B can break the security or privacy policy of A with respect to X without A's cooperation or knowledge.

Essentially, and even more loosely speaking, this is the same as saying that

A trusts B not to do X if and only if A cannot prevent B from doing X.

Similarly

Entity A trusts entity B if and only if there is an X such that A trusts B in X.

Building trust

Trust can only be built over time. For this, the SP needs to be sure it is talking to the same entity (and the other way around) in different sessions. In many of the current IdM systems, the User does not maintain any state. Moreover, the SP is completely relying on the IP to ensure that the link between different visits of the same user is reliable.

The "proof key" of CardSpace does not solve this: this only prevents an adversary to use a security token it obtained illegally. It works as follows. The proof key pair is generated by the IdP. The IdP sends the private proof key to the User Agent, encrypted using the public key of the UA. The public part is also sent to the User Agent, together with the security token. That whole messages is signed by the IdP. Using the proof key it received earlier, the UA generates a signature over this combination of token and public proof key, and sends all to the RP. The signature proves to the RP that the UA knows the corresponding private proof key.

The binding is only guaranteed as long as the IdP is honest. If the IdP releases the private proof key, or if it uses that proof key itself, the UA is no longer involved. This is why the CardSpace proof key does not solve the problem. It can only be solved if the User Agent and the Relying Party each store part of a key pair, and verify the link directly without external help.

Trust assumptions are ill understood

By using an identity management system, one implicitly agrees to several complex, and poorly understood, trust relationships between the parties that belong to that identity management system. Some of these trust relationships are the side effect of more fundamental security and federation problems with identity management (that I will discuss separately). The trust relationships involved are the following.

The user trusts the IdP not to act on its behalf without his explicit consent.

In many systems for identity management, the IdP essentially does the logging in to a RP, on behalf of a user. It could easily do so, without the user even being present. Clearly the user does not want the IdP to do this. The impact of this concern is unclear (an IdP that betrays the trust of user is soon out of business), but a fix to prevent this scenario is not difficult to implement. Moreover, the user expects the IdP not to release personal information unless explicitly asked by RP and with the permission of the user.

The service provider trusts the IdP not to extend the circle of trust (without his consent).

Depending on the application, a SP may rely on an IdP to provide him with attributes regarding the user accessing the service. Based on these attributes the SP may decide to grant the user access or not. A common example is granting access to a wireless campus network to all students, including those that come from other universities. In this application, the IdP will tell the network whether the user is a student or not. The circle of trust could be extended when a new university wants to join the scheme. In this case the IdP will delegate the responsibility to classify the new members as students to the newly connected IdP, and forward this classification as its own to all SPs that connect to it. Based on the decision of this new, and unknown, IdP the network (by necessity) will grant these users access to its network. The decision to grant access to a user is thus in the hands of the new IdP, which may be undesirable.

But there are many others. The most basic trust relationship underlying identity management (and this is usually well understood) is the following.

• The service provider trusts the IdP to make a particular claim about a particular user.

However, the following trust relationship is equally important and fundamental, yet most people will not realise this.

• The user allows the IdP to make a particular claim about herself to a particular service provider, and allows the service provider to accept such claims from this IdP.

Note also, that these trust relationship are dynamic and context dependent: a user may at some point decide to no longer use the services of an identity provider, and therefore the trust relationship no longer exists. Moreover, the user may only allow the service provider to accept certain claims from the identity provider within a certain context. For example, if a user only accesses a service from work, or during the day, the service provider should not accept claims about the user during the night, or when it appears the service is accessed from an Internet kiosk.

Every trust assumption is a potential security problem, as the trusted party can break the security policy of the other party. From a security point of view, it is preferable to rely on as few trust assumptions as possible.