initial draft of trust relationships

[fimbault]

No description provided.

[netlify]

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

🔨 Explore the source changes: db7453f

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

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

[agropper]

This is a great start.

RS override of an access token is the most common source of confusion in UMA 2 and other use cases where trust does not assume broad federation. For example, a client involved in a Denial of Service attack on the RS, would need to be blocked no matter the validity of the access token. This issue is typically cited as the reason for:

• not allowing the RO to fully control the AS, and / or
• introducing client registration with the RS.

Censorship of the AS or the client by the RS is a huge privacy problem because it limits the opportunity for agency on the part of the RO. The RS is typically in a position to impose terms on the RO and, given a security excuse, will typically compromise privacy.

Mitigation of this RS censorship issue can involve notification of the RO directly or via the AS and other means that could be out of scope for GNAP. This issue is so common and so important, however, that I hope we can mention it as part of this section.

[jricher]

This is a great start. Needs to have changelog updated but overall is good.

[Denisthemalice]

About Section 1.4 Trust relationships

The first sentence states:

GNAP defines its trust objective as: "the RO trusts the AS to ensure
access validation and delegation of protected resources to end-users,
through third party clients.

This is not a trust objective, nor a trust relationship, since a trust relationship is defined between two components
for some kind of behavior. Example: "an entity A trusts an entity B for some kind of behavior or action C".

The second sentence considers the following pairs of roles:

1. end-user/ RO,
2. end-user/client,
3. client/AS,
4. RS/RO,
5. AS/RO,
6. AS/RS

The trust relationships between the end-user and the AS are not described. Furthermore, it cannot be inferred form a transitive trust relationship that would exist between the end-user and the client on one side and the client and the AS on the other side. This leaves wide open how end-users can be authenticated by the ASs

In addition, the following text does not detail these six relationships in terms of trust.

In particular,

• for the client/AS relationship, the text states that the "core specification makes access tokens opaque to the client and defines the request/response scheme in detail, therefore avoiding extra trust hypotheses from this critical piece of software". Making access tokens opaque to the client has nothing to do with trust relationships but with a privacy property called "transparency".

• for the RS/RO relationship, the text states that "the RS promises it protects its resources from unauthorized access". Using the so-called "Promise Theory" (from the Book of Promises) does not allow to define a trust relationship. The key question is what kind of "promise" made by the RS (or the RO ???) is or is not trusted by another party. The text does not say a word about it. It should also be remembered that trust is not a bi-lateral relationship but a unilateral relationship. So, as an example, the RO/RS relation should also be considered (if any trust relationship exists between these two roles).

• for the AS/RO relationship, the text states that "the AS is expected to follow the decisions made by the RO". However, a previous sentence states: "For instance, the AS may decide to either take into account or discard hints provided by the client". By implication, the RO can take decisions that are not based on the wishes from the client, but those modified in an unknown way by the AS. With such a sentence, the client cannot be confident that the RO will take decisions based on his own wishes.

• for the AS/RS relationship, the text states that " the AS promises to issue valid access tokens to legitimate client requests". Here again, the key question is not what the AS does or is supposed to do, but what kind of "promise" made by the AS is or is not trusted by the RS. In addition an AS/RS relationship has nothing to do with "legitimate client requests".

The text is mute whether Capabilities based Access Control (CBAC) and/or Attribute based Access Control (ABAC) are supported.

For each case, the trust conditions are different. Reading "between the lines", it appears that only capabilities are supported in draft-07, whereas both CBAC and ABAC should be supported. See draft-pinkas-gnap-core-protocol-00 which details the trust relationships for each case.

In summary, this section is unable to correctly describe the trust relationships between the components of the system.
It is not possible to build a secure system when the trust conditions are not clearly explained.

"As your Idea's clear, or else obscure,
Th' Expression follows perfect, or impure:
What we conceive, with ease we can express"

The Art of Poetry, written in French by the Sieur de Boileau, Made English.

In French:

"Ce que l'on conçoit bien s’énonce clairement,
Et les mots pour le dire arrivent aisément."

Chant I », L'Art poétique, Nicolas Boileau,

[fimbault]

Denis,

I appreciate Poetry but your comments are obviously made without the understanding of promises and trust. Please refer to the definitions, instead of making vague arguments.

[agropper]

On Sat, Oct 2, 2021 at 5:24 PM Denisthemalice ***@***.***> wrote: <snip>

This leaves wide open how end-users can be authenticated by the ASs

I don't see this as a problem. An example might help. <snip>

- - for the AS/RS relationship, the text states that " the AS promises to issue valid access tokens to legitimate client requests". Here again, the key question is not what the AS does or is supposed to do, but what kind of "promise" made by the AS is or is not trusted by the RS. In addition an AS/RS relationship has nothing to do with "legitimate client requests". I tend to agree with Denis here. The AS should not make any promises to

the RS. The AS promises are only to the RO. The AS is a delegate of the RO and the RS that doesn't like giving that power to the RO should withhold their services.

- The text is mute whether Capabilities based Access Control (CBAC) and/or Attribute based Access Control (ABAC) are supported.

That's not a big problem. Although ABAC has the same issues as identity-based access control (what do we call IBAC?), I don't see GNAP needing to outlaw IBAC or ABAC as long as CBAC and token introspection are natively supported. - Adrian —

…

You are receiving this because you commented. Reply to this email directly, view it on GitHub <#306 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YMNNFAPN7JPXUKVKRTUE52AJANCNFSM5C54IRJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[fimbault]

"The AS should not make any promises to
the RS". That's an interesting view. The reason I've added that is that how RS protected resources is a design choice by backend developers, who expect that delegating access control will be easier to manage through an AS. Hence I don't think we can entirely dismiss that aspect of things, even if I agree that the key stakeholder is the RO.

An example (not to be understood as a requirement, just an illustration) has recently been provided by Josh Mandel, with the wish that the service may audit the origin of client instance accesses.

[Denisthemalice]

@fimbault The Book of Promises (a 318 pages thick document) is not a document that is currently used in the security community.

The concept of trust is even left undefined in section 1.4 THE MAIN CONCEPTS

However, the two following definitions are present:

Promise: When an intention is publicly declared to some audience (called its scope) it becomes a promise.
Thus a promise is a stated intention.

Intention: A subject or type of possible behaviour. i.e. something that can be interpreted to have significance.

The first sentences defining what trust means are on pages 108 and 109:

Trust is a valuation, made autonomously, by an individual agent about another agent or its promise.

Proposal 1 (Trust). An agent’s expectation that a promise will be kept. It may be assigned a value lying between 0 and 1, in the manner of a Bayesian probability.

About Proposal 1: In computer security, we consider that the security level of a chain is equivalent to the security level of the weakest link of the chain. We do not compose with the probabilities of the various links of a chain.

IMO, the book of promises is well adapted in a supply chain where one or more elements of a chain can fail due to some circumstances like weather, strikes, or incidents. It is not suited for computer security protocols which deal with unilateral relationships between two components.

This section should consider the concept of trust (i.e. Agent A trusts Agent B for some kind of behavior C)
rather than the concept of promises which reverses the unilateral relationship.

[fimbault]

Back on Denis's comments in more detail :

• "The trust relationships between the end-user and the AS are not described." We can indeed, it's not in the initial draft of that section because mostly covered by the client as a user agent. It would be interesting to describe the part related to interaction methods. Although it's not a simple as the pinkas draft is saying, as this relationship is still going through a user agent (a browser in many cases)
• for the client/AS relationship : opaque tokens are not only a transparency property (which is how you view it, but there have been numerous discussions that explain why the group views it differently)
• for the RS/RO relationship and the relationship between promises and trust, we have clear definitions (chapter 10 of the book)
• for the AS/RO relationship, your point is only argumentative, as you mix RO and client issues. In particular, "the client cannot be confident that the RO will take decisions based on his own wishes" is a rewording of previous issues you entered, and we already responded.
• for the AS/RS relationship : answered above

All those comments obviously come directly from the hypothesis you've put into your pinkas draft, but GNAP doesn't adhere to most of those. The trust description in the pinkas draft mixes issues that are actually security or privacy issues, which is exactly what we decided not to do.

• the pinkas draft discusses HTTPS and TLS in the trust model, while those protocols say nothing on the trust between system components. Using a specific protocol is not a trust issue. One could very well use other protocols (e.g. a protocol adapted to the IoT domain) and still provide the same level of trust. The pinkas draft continues with measures such as "use a trust anchor". Again that may be a consequence of a trust issue, but is not a trust model per say. Later again, the text mixes the trust model and actual measures (e.g. sign access tokens), and even does so with specific methods (a CA), therefore discarding all other possibilities.
• the pinkas draft then deals with the end-user. However some of the descriptions are so generic that they could mislead the reader. For instance, "The end-user is trusting his client to manage the interactions with the AS and with the RS, whether these interactions are performed using APIs or using a User Interface (UI)." This hinders many practical threats.
• then we have a lengthy discussion on capabilities vs RBAC, which only obscures things in my view.

[fimbault]

@Denisthemalice You seem to dislike "promise theory", for no other reason that you don't know about it (and obviously didn't try bothering, as your comments demonstrate). But your alternative is only to say that "A trusts B for action C", which doesn't bring any definition at all, it just makes it circular. "Trust is trust"... doesn't help me. Promise theory does bring those definitions in a formal way (and originates from IT).
Again, we can discuss improvements (it's only meant as an "initial draft" of that section), but it doesn't strike me that your alternative is any better.

[Denisthemalice]

@fimbault :

ISO 10181-1 defines trust in the following way:

3.3.28 trust
Entity X is said to trust entity Y for a set of activities if and only if entity X relies upon entity Y
behaving in a particular way with respect to the activities.

[fimbault]

Yes, a very all or nothing definition that doesn't fit well with modular system design. As you correctly point out, overall security is based on the weakest link, so it's hard to define trust as something you blindly rely upon. We instead need a model upon which we can reason about.

[agropper]

@fimbault said:

"The AS should not make any promises to the RS". That's an interesting view. The reason I've added that is that how RS protected resources is a design choice by backend developers, who expect that delegating access control will be easier to manage through an AS. Hence I don't think we can entirely dismiss that aspect of things, even if I agree that the key stakeholder is the RO.

An example (not to be understood as a requirement, just an illustration) has recently been provided by Josh Mandel, with the wish that the service may audit the origin of client instance accesses.

@jricher said in https://mailarchive.ietf.org/arch/msg/txauth/eV8O7KjGnXE6tQn5DlSvCA7EmQw/

The AS issues tokens that are trusted, the RS trusts and executes those tokens. Giving an unknown party complete security control over your API is terrifying, and we've already seen that what actually happens is that people build in a internal AS to handle that case anyway. It's why we have things like security assertions and token exchange and application gateways.

I hope GNAP can be absolutely clear that having the RO specify where her privacy policies are stored and available as an AS does not mean giving the RS "complete security control". This sets up an undesirable compromise between privacy and security.

GNAP must not force the RO to share policies with the RS trust domain regardless of whether that trust domain implements their own AS for their own policy reasons. As mentioned in #306 (comment), RS security overrides to an access token are always available to the RS.

What's important is that the RS:

• clearly describes its policies for security overrides before the RO decides to trust the RS, and
• optionally, the RS has a way to notify the RO if a security override has occurred and what to do about it.

I'm not saying that these security override features must be normative in GNAP core. I am insisting that GNAP core enable and describe how the RO can specify the GANP AS that will have their policies when some end-user presents via some client.

[fimbault]

Yes, said differently, it's not possible to define trust statically, it's context dependant (including policy decisions, threats, etc.)

[agropper]

@fimbault How does this relate to my comments #306 (comment) and #306 (comment) and elsewhere as, effectively allowing the RO to choose the AS that has their policies as controller of any particular RS?

[fimbault]

The current thread is about trust relationships. My answer relates to your comments insofar an implementation of what you describe actually involves policies which may or may not change how some of the actors (the RO in particular) involved in the protocol may assess trust. Of course the current thread doesn't go beyond that.