Missing Details for Verificaton of Identity Information

[cwaldm]

Introduction

This issue is based on a formal security analysis of the GNAP specification, which we are working on as a group in the Institute for Information Security at the University of Stuttgart, extending previous analysis work done by Florian Helmschmidt (pq2).

One of the security properties that we have been working to prove that the GNAP specification satisfies is security with respect to authentication. This security property states that an attacker should not be able to log in at an honest (protocol-following) client instance using the account of an honest end user at an honest AS.
We were unable to prove that GNAP satisfies this property because of missing details about the use of GNAP as an authentication protocol, in particular about how a client instance identifies end user accounts.

It is currently unclear how exactly GNAP can be used as an authentication protocol. While it seems that a realistic implementation based on the specification is most likely secure, there exist possible interpretations of the specification that are problematic.

Most notably, if a client instance chooses to use the subject information returned by the AS as a sole identifier of end user accounts, the following flow is possible, in which an attacker is able to log in as an honest (protocol-following) user at an honest client, provided only that the honest user has an account at an attacker client that uses the same AS.

Problem Flow

Note that in this diagram, while the attacker is shown as three separate components (Attacker Client, Attacker User, and Attacker AS), we assume that there is only one attacker, which can share information between these different roles.

This attack combines two flows. In the first flow, an honest end user attempts to log in using an attacker-controlled client with the identity u at an honest AS (HAS). As a result of this login flow (which is specification-compliant), the attacker client is sent the subject identifier u.
In a subsequent flow, the attacker can initiate a grant with an honest client using an attacker-controlled AS (AAS), which can then return this same subject identifier u to the client. At this point, the attacker has successfully logged in at the honest client with the identity u.

This flow presents a clear problem, in that an attacker is able to log in as an honest user at an honest client. Note that the first portion of this flow, where the honest user logs in at an attacker client, may be unnecessary if subject information is sufficiently guessable (e.g. if it follows the email identifier format).

Proposed Resolution

The simplest resolution to this problem is to clarify in the specification that client instances should not rely solely on subject information returned by an AS to identify a user account. For instance, the pair (subject information, AS) is sufficient to uniquely identify a user account at the client, since subject information uniquely identifies a user at the AS. Practically, the information identifying the AS should likely be a domain of the AS, or perhaps the URI of one of its endpoints.

Why does this fix the problem?

With this change, in order for an end user to be logged in at an honest client instance using an account managed by an honest AS, the subject information identifying that account must have been sent directly from this honest AS to the client.

By modifying the client to use both the identity u and the AS at which it requested subject information to identify an account, this attack can be avoided. With this change, upon receiving the subject identifier u from AAS, the client logs in the attacker as (u, AAS), an account which, if it exists, has access to it managed by AAS, rather than HAS.

Session Integrity

This is related to ietf-wg-gnap/gnap-resource-servers#56.

This proposed change also resolves an issue with session integrity for authentication, in which an honest end user can end up logged in at an honest client as an attacker account managed by an honest AS. This attack is similar to that presented in ietf-wg-gnap/gnap-resource-servers#56.
The proposed change avoids this attack by limiting which accounts an attacker AS can authorize logins for to those which it manages, preventing a form of "privilege escalation" where a single attacker AS can provide access to accounts which it does not manage.
In the case of authorization, presented in ietf-wg-gnap/gnap-resource-servers#56, this corresponds to the check performed by the RS to ensure that the AS at which it performs token introspection is responsible for access to the resources for which it provides access rights.

Conclusion

If GNAP is to be used as an authentication protocol, its specification should be more explicit about what identifying information is needed to identify an end user at the CI. While reasonable implementations of the GNAP specification are unlikely to encounter this issue, it is possible to give an implementation that complies with the specification, but nevertheless has serious security issues. With this change, we are able to show both an authentication property (an attacker should not be able to log in to an honest client using the account of an honest user at an honest AS) and a session integrity property for authentication (an honest end user should not get logged in at an honest client with any other user's account at an honest AS).

[jricher]

Related to #75, but could probably use additional text in the specification.

Even though GNAP is not on its own intended to be an authentication protocol, I think that clarifying that all subject information provided to a client instance needs to be taken in the context in which it was issued is a reasonable clarification, both in terms of the normative processing of the subject information as well as a security consideration. This is a common practice in federation requirements, see NIST SP800-63C:

An RP SHALL treat subject identifiers as not inherently globally unique. Instead, the value of the assertion’s subject identifier is usually in a namespace under the assertion issuer’s control. This allows an RP to talk to multiple IdPs without incorrectly conflating subjects from different IdPs.