Security Considerations

[jricher]

Adds an initial set of security considerations to the GNAP core draft. Additional considerations to be added in future edits as discussion evolves.

[netlify]

✔️ Deploy Preview for gnap-core-protocol-editors-draft ready!

🔨 Explore the source changes: 3eba247

🔍 Inspect the deploy log: https://app.netlify.com/sites/gnap-core-protocol-editors-draft/deploys/6140ea49254cf000082134e4

😎 Browse the preview: https://deploy-preview-304--gnap-core-protocol-editors-draft.netlify.app/draft-ietf-gnap-core-protocol

[fimbault]

I agree with the suggested changes, as discussed during the editor's meeting. Maybe we'll find additional topics to cover later on, but that's a very good starting point.

Also includes answers to many open issues, which we'll be able to close

[Denisthemalice]

About Section 12. Security Considerations (page 109)

Section 12.1 states:

Even though requests from the client instance to the AS are signed, the signature method alone does not protect the request from interception by an attacker.

This has nothing to do with the title of this section which is "TLS Protection in Transit".
There is no justification of the reason(s) why the requests from the client instance to the AS should or shall be signed.

Section 12.1 also states:

The use of key-bound access tokens does not negate the requirement for protecting calls to the RS with TLS.

This has nothing to do with the title of this section which is "TLS Protection in Transit".
There is no justification of the reason(s) why key-bound access tokens should or shall be used.

The next sentence states:

While the keys and signatures associated a bound access token will prevent an attacker from using a stolen token".

It should be observed that those keys and signatures associated to a bound access token do not prevent an attacker from using a stolen token, if a legitimate client collaborates with another client.

Section 12.2 (Protection of Client Instance Key Material) states:

"Client instances are identified by their unique keys".

The rational for authentication client instances using a unique key is not explained. The access tokens contain the rights or privileges of a human user and not those for a client instance.

The relationship between client instances and end-users is not explained.

Section 12.3 states:

The AS performs critical functions in GNAP, including authenticating client software, managing interactions with end-users to gather consent and provide notice, and issuing access tokens for client instances to present to resource servers.

While the text explicitly states that the AS authenticates the client software, the text is mute about the authentication of the end-user by the AS.

Section 12.6 is about Bearer Access Tokens states:

Bearer access tokens can be used by any party that has access to the token itself, without any additional information.

In the context of GNAP, bearer tokens are not defined. However, there exists a definition of the bearer flag which is the following:

"bearer" If this flag is included, the access token being requested is a bearer token. If this flag is omitted, the access token is bound to the key used by the client instance in this request, orthe key’s most recent rotation.

Bearer access tokens are tokens that do not include a key used by the client instance in its request. The use of such a key does not offer a protection against the use of an access token by another client, if the client accepts to collaborate with another client.

However, it is possible to obtain a protection against the use of an access token by another client by using bearers tokens, if they include a specific field that does not exist in draft -07. Such a protection is explained in details in draft-pinkas-gnap-core-protocol-00. See the text on page 9 about the "buid" field which is a "binding user identifier" that allows a RS to verify that the access token is associated with the right (short-term or long-term) user account. This field allows to detect the inappropriate use of an access token by a malicious user.

Section 12.6 states:

It also means that any party that is able capture of the token value in storage or in transit is able to use the access token.

and also:

In GNAP, key-bound access tokens are the default due to their higher security properties.

Both sentences are incorrect, as soon as a "binding user identifier" field is used in the access token.

Section 12.8 (Exposure of End-user Credentials to Client Instance) states:

Consequently, no interaction methods defined in the GNAP core require the end-user to enter their credentials, but it is technologically possible for an extension to be defined to carry such values. Such an extension would be dangerous as it would allow rogue client software to directly collect, store, and replay the end-user’s credentials outside of any legitimate use within a GNAP request.

Such an incorrect conclusion is the consequence of a missing trust relationship. A key point is whether the end-user is trusting or not his client instance for not stealing his credentials and for displaying the correct information.

The end-user authentication towards the AS is even considered as "dangerous" !

Furthermore, "end-user authentication" is implicitly interpreted as being the use of a password.

GNAP should be targeted to be world-wide usable, including within Europe and the EU. As of December 31 st, 2020, the European Union (EU) is requiring that consumer electronic payments over € 50 ($ 60) require MFA (Multi-factor authentication).
This requirement is defined as part of the Payments Services Directive (PSD2) that took effect in January 2018.

Article 97
Authentication

1. Member States shall ensure that a payment service provider applies strong customer authentication where the payer:
   (a) accesses its payment account online;
   (b) initiates an electronic payment transaction;
   (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

(30) ‘strong customer authentication’ means an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data;

In 2016, for example, the Dutch Data Protection Authority (Dutch DPA) specifically indicated that hospitals need to use 2FA in patient portals. It can be concluded that the Dutch DPA believes that medical data, which is sensitive personal data according to the GDPR, needs to be secured with 2FA (Two factors authentication).

It is thus fundamental for GNAP to be able to support both 2FA (Two factors authentication)
and MFA (Multi-factor authentication).

draft-pinkas-gnap-core-protocol-00 supports the end-user authentication as a mandatory feature of the core protocol.
It is able to support any kind of end-user multi-factor authentication protocol.

Section 12.9 (Mixing Up Authorization Servers) states:

If a client instance is able to work with multiple AS’s simultaneously, it is more possible for an attacker to add a compromised AS to the client instance’s configuration and cause the client software to start a request at the compromised AS. This AS could then proxy the client’s request to a valid AS in order to attempt to get the resource owner to approve access for the legitimate client instance.

A client instance needs to always be aware of which AS it is talking to throughout a grant process, and ensure that any callback for one AS does not get conflated with the callback to different AS.

This threat does not exist as soon as TLS is supported and the end-user verifies that it is connected to the appropriate AS.

Section 12.10 (Processing of Client-Presented User Information) states:

GNAP allows the client instance to present assertions and identifiers of the current user to the AS as part of the initial request. This information should only ever be taken by the AS as a hint, since the AS has no way to tell if the represented person is present at the client software, without using an interaction mechanism. This information does not guarantee the given user is there, but it does constitute a statement by the client software that the AS can take into account.

This highlights the fact that the information presented by the client about the end-user is only identifying the claimed end-user and by no way authenticating it. This is insecure.

Later on the text continues with:

If the client instance’s audience identifier is known to the AS and can be associated with the client instance’s presented key, the AS can also evaluate that the appropriate client instance is presenting the claimed assertion.

Such a condition would not comply with the EU Payments Services Directive (PSD2) that took effect in January 2018.
In addition, the core protocol does not support any feature able to make the difference between a trusted client instance and an untrusted client instance.

Section 12.11 (Client Instance Pre-registration) states:

It also is sensible to pre-register client instances when the software is acting on its own behalf, without the need for a runtime approval by a resource owner or any interaction with an end-user.

Such a statement would change the model, since access tokens only contain information about end-users and not about client instances.

Section 12.12 (Client Instance Impersonation) states:

(..) a malicious client instance could impersonate legitimate client software for the purposes of tricking users into authorizing the malicious client.

Since the end-user needs to trust his client, such a threat does not exist.

In summary, this Security Considerations section exhibits major security weaknesses present in draft -07.

A redesign of the protocol would be necessary, but such a redesign will only be possible once the trust relationships will be reconsidered and rewritten.

[fimbault]

@Denisthemalice since you relate the core of your criticisms to the trust relationships #306, I guess we should resolve this first. But I suspect we just have different world views and objectives, which makes you present GNAP as "insecure" or "not private by design", while those choices are very conscious design decisions (just not yours). And quite importantly, we demonstrated over and over again why your criticisms don't hold true.