From nobody Thu Jan 13 06:32:35 2022 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D803A124F for ; Thu, 13 Jan 2022 06:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.893 X-Spam-Level: X-Spam-Status: No, score=0.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_FILL_THIS_FORM_FRAUD_PHISH=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIZYvSHFe-6w for ; Thu, 13 Jan 2022 06:32:30 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F973A1209 for ; Thu, 13 Jan 2022 06:32:29 -0800 (PST) Received: from [192.168.1.11] ([82.121.144.115]) by smtp.orange.fr with ESMTPA id 819OnddvXSDrI819OnngbC; Thu, 13 Jan 2022 15:32:27 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: OWU3ZmVkYWM0M2UwZWM1YifxM2Q3ZDk1YiUzNWJiZTM2MiliMTI0N2YxZmQ= X-ME-Date: Thu, 13 Jan 2022 15:32:27 +0100 X-ME-IP: 82.121.144.115 Content-Type: multipart/alternative; boundary="------------RAMoPFLYfgYSZ0FWsJFiGn6o" Message-ID: <4429563c-0967-ceb7-a9fa-0c3e74c755e3@free.fr> Date: Thu, 13 Jan 2022 15:32:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-GB From: Denis To: "txauth@ietf.org" Archived-At: Subject: [GNAP] Eight issues for discussion before and at the next WG virtual meeting X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 14:32:34 -0000 This is a multi-part message in MIME format. --------------RAMoPFLYfgYSZ0FWsJFiGn6o Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello every one, Most of the following observations have already been advertised in previous virtual GNAP meetings as well at the last OAuth workshop virtual meeting. However, time has been lacking to discuss them. Since a GNAP virtual meeting is scheduled next week, I have transformed these observations into issues, so that that can be individually discussed in GitHub before the meeting and then at the meeting. I publish the content of eight new posted issues below, so that every one can get an overview of all of them and, if interested, can directly point to each of them with a single click. I have a specific request to the editors: please, do not close any of these issues before the next virtual GNAP meeting. *1.****Trust relationships are still left undefined in GNAP draft-08 * https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/368 **Section 1.4 of draft-08 is supposed to be about “/trust relationships/”, but it is not. It is based on “Promise Theory” document (302 pages) where “ /A //promise is a stated intention /”. “ /Each agent defines its own valuation function of promises given or received /”. On page 108 (!), there is a first attempt to define what Trust means: /Proposal /1 (Trust). An agent’s expectation that a promise will be kept. It may be assigned a value lying between0 and1, in the manner of a _Bayesian probability_/./ Such an approach is confusing : it is mixing trust relationships with security threats. In the IT community, trust is a binary condition (0 or1): either you trust something or you don’t. *It is not a Bayesian probability*. A trust relationship is rather simple and is composed of three parts : An entity A … is trusting an entity B … for some kind of behavior C. /…being aware that some conditions “out of control” might happen/ Section 1.4 of draft-08 is failing to indicate the trust relationships that may exist between: - Client instances and end-users, - End-users and ASs, - Client instances and ASs, Trust relationships need to be clear and understandable. Without them, it will not be possible to demonstrate the security of the architecture. In draft-08, the following questions have no answer: How may a client instance be associated with an end-user ? This is left undefined. How may an AS be confident that a legitimate user is using a given client instance ? This is left undefined. *2. The Authentication of end-users by an AS is currently not required* https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/369 Extract from the Introduction on page 5 of draft-08: This protocol allows a piece of software, the client instance, to request delegated authorization to resource servers and to request direct information.(…) The end-useroperating the software mayinteract with the authorization server to authenticate, provide consent, and authorize the request. Hence, the authentication of end-users by an AS is not required. Does it mean that the authentication of the "piece of software" used by an end-user SHALL be mandatory ? If so, how this "piece of software" should associated with end-user is left undefined. Considerations about an end-user for changing that "piece of software" or using several pieces of software at the same instant of time are not mentioned. How an AS may associate some rights or attributes with an end-user is left undefined. Note that the EU Payments Services Directive (PSD2) /mandates the use of MFA (Multi Factor Authentication) with the AS/. Why a strong authentication of end-users by an AS would not be sufficient, hence avoiding the authentication of "pieces of software" ? *3.* *R**ights and attributes **SHOULD be equally supported** *https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/370 The core draft defines: _Privilege_:right *or attribute *associated with a subject _Access Token_:a data artifact representing a set of rights *and/or attributes* However, the core draft does not allow a RS to distinguish between rights and attributes. The core protocol should define two fields in an access token request to distinguish between rights (i.e. capabilities) and attributes. A set of standard _attribute types_ should be defined to support ABAC (Attribute Based Access Control) : e.g. first name, family name, birth date, birth location, home address, email address, social security number, citizenship(s), etc … *4.* *Both attributes (ABAC) and capabilities (CBAC) SHOULD be supported * https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/371 At the moment, a client is able to request with a fine degree a precision a specific set of rights that should be included into an access token. However, a client is unable to request a specific set of attributes that should be included into an access token. As a consequence, the /support of rights/ versus the /support of attributes/ is unbalanced. Implicitly, the core draft mandates a /bilateral/pre-relationship between every pair of AS / RS. This is not advertised in the draft. Such bilateral pre-relationship limits the scalability of the architecture. When attributes only are supported, no /bilateral/ pre-relationship between an AS and a RS is necessary. The core document only implicitly allows an AS to add attributes into an access token /at its own discretion/, without any specific request for them to be included from the client (and hence the end-user). This means that the core document does not allow an AS to add specific attributes into an access token upon the request from the client (and hence from the end-user). This has *severe consequences in term of the end-user privacy* which are not mentioned in the draft. First of all, since rights are always included, this means that the AS MUST be aware of the identity of the RS. In addition, the AS cannot be kept ignorant of which actions will be performed by a client and on which resources. *This allows the AS to act as "Big Brother"*. However, this can be prevented in the case where attributes only are supported. Secondly, in order to support "good practices" (User Notice, User Choice, User Consent and Transparency)or legislation like the EU GDPR, the end-user should be informed about the set of attributes that are requested _by a RS_and should also be able to know the treatment(s) that will be done with such attributes. At the moment, a dialogue between the client and the RS is missing. A specific RS end-point should be defined and dedicated for such dialogue. If the end-user agrees to provide that set of attributes to the RS, he should be able to indicate to the AS which attributes types(/and optionally values/) should be included into the access token. At the moment, the client is unable to specify to the AS a set of attributes to be included into the access token. In addition, an end-user is even unable to know which set of attributes are known by the AS. If this situation is going to last, the privacy consideration section should clearly indicate these limitations. *5. A RS is currently only able to trust a single AS * https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/372 This limitation should be removed and can be removed. For details, see: draft-pinkas-gnap-core-protocol-00.txt The /Proposal/for a Regulation amending Regulation (EU) No 910/2414 as regards establishing a framework for a European Digital Identity of 3 June 2021 should not be ignored. /It paves the way for the use of //multiple////attribute servers//./ If such limitation is not removed, it should be clearly advertised in the core draft. *6.* *Bearer access tokens and key-bound access tokens are not the single types of access tokens * **https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/373 **OAuth (and GNAP draft-08) postulate that only two classes of access tokens may exist: - key-bound access tokens where the access token is bound to a key used by the client instance in its request, and       - bearer access tokens that do not include a key used by the client instance in its request. If a hardware security module (HSM) is being used, it prevents a legitimate client or a user to know the /value //of a client private key/, but it does not prevent the /use//of that private key/by a legitimate client willing to collaborate with another client. If a client accepts to collaboratewith another client, the use of key-bound access tokens does not offer a protection against the use of an access token by another client. GNAP (and OAuth) are not resistant to client collaborative attacks. As long as this situation will last, this should be clearly advertised in the draft. However, there exits a solution to address this issue which has already been advertised to the WG: the addition into the access token of a "buid" field : Binding User IDentifier. As a side consequence, a distinction should be done between long_term_user_accounts and short_term_user_accountssupported by a RS. For details, see: draft-pinkas-gnap-core-protocol-00.txt *7. **Draft-08 makes a general assumption that an end-user and a RO are the same entity* https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/374 ** **Extract from page 13 of draft-08:      Note that the RO and end-user are often the same entity in practice, but GNAP makes no general assumption that they are. Unfortunately, this Note is wrong. Section 1.5 is failing to provide a single example where the end-user is not also the RO and where the RO is an automated process. This comment has already made several times, but no action has been made to take care of it up to now: section 1.5 has still not been modified. *8.* *GNAP versus GNAF*: *do the current drafts describe a protocol or a framework ? * https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/51 * *_Response_: They describe a framework since two independent implementations of the drafts will be unable to interoperate. In particular, the issue about "Format of defining REQUIRED vs OPTIONAL request/response elements (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/257) is still opened. The protocols are not defined end-to-end. In particular, which treatments and verifications should be done by a RS are still left undefined. As long as this situation will last, the document cannot be considered as a "Grant Negotiation and Authorization *Protocol*" (GNAP) but rather as a "Grant Negotiation and Authorization *Framework*" (GNAF). Denis --------------RAMoPFLYfgYSZ0FWsJFiGn6o Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hello every one,

Most of the following observations have already been advertised in previous virtual GNAP meetings as well at the last OAuth workshop virtual meeting.
However, time has been lacking to discuss them. Since a GNAP virtual meeting is scheduled next week, I have transformed these observations into issues,
so that that can be individually discussed in GitHub before the meeting and then at the meeting.

I publish the content of eight new posted issues below, so that every one can get an overview of all of them and, if interested, can directly point to each
of them with a single click.

I have a specific request to the editors: please, do not close any of these issues before the next virtual GNAP meeting.

1. Trust relationships are still left undefined in GNAP draft-08

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/368

Section 1.4 of draft-08 is supposed to be about “trust relationships”, but it is not. It is based on “Promise Theory” document (302 pages)
where “ A promise is a stated intention ”. “ Each agent defines its own valuation function of promises given or received ”.

On page 108 (!), there is a first attempt to define what Trust means:

  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.

Such an approach is confusing : it is mixing trust relationships with security threats.

In the IT community, trust is a binary condition (0 or 1): either you trust something or you don’t. It is not a Bayesian probability.

A trust relationship is rather simple and is composed of three parts :

An entity A … is trusting an entity B … for some kind of behavior C.
…  being aware that some conditions “out of control” might happen

Section 1.4 of draft-08 is failing to indicate the trust relationships that may exist between:

   - Client instances and end-users,
   - End-users and ASs,
   - Client instances and ASs,

Trust relationships need to be clear and understandable. Without them, it will not be possible to demonstrate the security of the architecture.

In draft-08, the following questions have no answer:

How may a client instance be associated with an end-user ? This is left undefined.

How may an AS be confident that a legitimate user is using a given client instance ? This is left undefined.
 

2. The Authentication of end-users by an AS is currently not required

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/369

Extract from the Introduction on page 5 of draft-08:

      This protocol allows a piece of software, the client instance, to request delegated authorization to resource servers and to request direct information.  (…)
      The end-user operating the software may interact with the authorization server to authenticate, provide consent, and authorize the request.

Hence, the authentication of end-users by an AS is not required. Does it mean that the authentication of the "piece of software" used by an end-user SHALL be mandatory ?
If so, how this "piece of software" should associated with end-user is left undefined.

Considerations about an end-user for changing that "piece of software" or using several pieces of software at the same instant of time are not mentioned.

How an AS may associate some rights or attributes with an end-user is left undefined.

Note that the EU Payments Services Directive (PSD2) mandates the use of MFA (Multi Factor Authentication) with the AS.

Why a strong authentication of end-users by an AS would not be sufficient, hence avoiding the authentication of "pieces of software" ?


3. Rights and attributes SHOULD be equally supported

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/370

The core draft defines:

      Privilege:  right or attribute associated with a subject
      Access Token:  a data artifact representing a set of rights and/or attributes

However, the core draft does not allow a RS to distinguish between rights and attributes.

The core protocol should define two fields in an access token request to distinguish between rights (i.e. capabilities) and attributes.

A set of standard attribute types should be defined to support ABAC (Attribute Based Access Control) :
e.g. first name, family name, birth date, birth location, home address, email address, social security number, citizenship(s), etc …

4. Both attributes (ABAC) and capabilities (CBAC) SHOULD be supported

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/371

At the moment, a client is able to request with a fine degree a precision a specific set of rights that should be included into an access token.
However, a client is unable to request a specific set of attributes that should be included into an access token.

As a consequence, the support of rights versus the support of attributes is unbalanced.

Implicitly, the core draft mandates a bilateral pre-relationship between every pair of AS / RS. This is not advertised in the draft.

Such bilateral pre-relationship limits the scalability of the architecture.

When attributes only are supported, no bilateral pre-relationship between an AS and a RS is necessary.

The core document only implicitly allows an AS to add attributes into an access token at its own discretion,
without any specific request for them to be included from the client (and hence the end-user).

This means that the core document does not allow an AS to add specific attributes into an access token upon the request from the client
(and hence from the end-user).

This has severe consequences in term of the end-user privacy which are not mentioned in the draft.

First of all, since rights are always included, this means that the AS MUST be aware of the identity of the RS.
In addition, the AS cannot be kept ignorant of which actions will be performed by a client and on which resources.
This allows the AS to act as "Big Brother". However, this can be prevented in the case where attributes only are supported.

Secondly, in order to support "good practices" (User Notice, User Choice, User Consent and Transparency) or legislation like the EU GDPR,
the end-user should be informed about the set of attributes that are requested by a RS and should also be able to know the treatment(s)
that will be done with such attributes. At the moment, a dialogue between the client and the RS is missing. A specific RS end-point
should be defined and dedicated for such dialogue.

If the end-user agrees to provide that set of attributes to the RS, he should be able to indicate to the AS which attributes types (and optionally values)
should be included into the access token. At the moment, the client is unable to specify to the AS a set of attributes to be included into the access token.
In addition, an end-user is even unable to know which set of attributes are known by the AS.

If this situation is going to last, the privacy consideration section should clearly indicate these limitations.

5. A RS is currently only able to trust a single AS

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/372

This limitation should be removed and can be removed. For details, see: draft-pinkas-gnap-core-protocol-00.txt

The Proposal for a Regulation amending Regulation (EU) No 910/2414 as regards establishing a framework for a European Digital Identity
of 3 June 2021 should not be ignored. It paves the way for the use of multiple attribute servers.

If such limitation is not removed, it should be clearly advertised in the core draft.

6. Bearer access tokens and key-bound access tokens are not the single types of access tokens

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/373

OAuth (and GNAP draft-08) postulate that only two classes of access tokens may exist: 
      - key-bound access tokens where the access token is bound to a key used by the client instance in its request, and
      - bearer access tokens that do not include a key used by the client instance in its request.

If a hardware security module (HSM) is being used, it prevents a legitimate client or a user to know the value of a client private key,
but it does not prevent the use of that private key by a legitimate client willing to collaborate with another client.

If a client accepts to collaborate with another client, the use of key-bound access tokens does not offer a protection
against the use of an access token by another client.

GNAP (and OAuth) are not resistant to client collaborative attacks.

As long as this situation will last, this should be clearly advertised in the draft.

However, there exits a solution to address this issue which has already been advertised to the WG: the addition into the access token of a "buid" field : Binding User IDentifier.
As a side consequence, a distinction should be done between long_term_user_accounts and short_term_user_accounts supported by a RS.

For details, see: draft-pinkas-gnap-core-protocol-00.txt


7. Draft-08 makes a general assumption that an end-user and a RO are the same entity

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/374

Extract from page 13 of draft-08:

     Note that the RO and end-user are often the same entity in practice, but GNAP makes no general assumption that they are.

Unfortunately, this Note is wrong. Section 1.5 is failing to provide a single example where the end-user is not also the RO and where the RO is an automated process.

This comment has already made several times, but no action has been made to take care of it up to now: section 1.5 has still not been modified.

8. GNAP versus GNAF: do the current drafts describe a protocol or a framework ?

https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/51

Response: They describe a framework since two independent implementations of the drafts will be unable to interoperate.

In particular, the issue about "Format of defining REQUIRED vs OPTIONAL request/response elements (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/257) is still opened.

The protocols are not defined end-to-end. In particular, which treatments and verifications should be done by a RS are still left undefined.

As long as this situation will last, the document cannot be considered as a "Grant Negotiation and Authorization Protocol" (GNAP)
but rather as a "Grant Negotiation and Authorization Framework" (GNAF).


Denis


--------------RAMoPFLYfgYSZ0FWsJFiGn6o--