Subject: [GNAP] New I-D: draft-pinkas-gnap-core-protocol

From: Denis <[email-masked]>
Date: Thu, 19 Aug 2021 19:24:19 +0200

Yaron (the chair of the GNAP WG) and myself have had a video conference 
call last week. At the end of this call, Yaron asked me if I could write
an I-D that would summarize the main concepts on how to support an 
Attribute Based Access Control (ABAC) mechanism. I have accepted.

Since during that call, I mentioned that the current description of the 
protocol was both insecure and not interoperable, I indicated
that I will provide a draft describing the main concepts on how to 
support both an Attribute Based Access Control (ABAC) mechanism
as well as a Capability Based Access Control (CBAC) mechanism, both in a 
secure and in an interoperable way.

The draft re-uses many portions of text that I have provided in the 
issues that I have posted on Github.

In order to understand the motivations of the proposal, here after is a 
quick analysis of draft-ietf-gnap-core-protocol-06.

The charter of the GNAP WG states, close to its end :

            "The initial work will focus on using HTTPS for 
communication between the client and the authorization server, (...)"

            See: https://datatracker.ietf.org/doc/charter-ietf-gnap/

Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use 
of HTTPS for communication between the client and the authorization server
and does not take advantage of the security properties obtained thanks 
to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06
does not comply with the GNAP charter.

Instead, draft-ietf-gnap-core-protocol-06 makes use of "client instance 
keys" between the client and the AS and is mute about the relationships
between a "client instance key" and an end-user. From oral explanations 
recently obtained from one of the co-editors, a "client instance key" is 
a key attached
to a device owned by an end-user. How the identity or an identifier of 
the end-user relates to a device is left undefined. If an end-user has 
four devices
(e.g. a laptop, a desktop, a smart phone and a tablet), he will need to 
register with the AS each of these four devices. This is done using 
"out-of-bands" means.
If he looses one of these four devices, he will need to revoke the 
client instance key associated with that device and then, if he has not 
taken one of the three
of other devices with him, he will need to register a new device (i.e. a 
new client instance key). Here again, this is done using "out-of-bands" 
means.
All that information is not present in draft-ietf-gnap-core-protocol-06 
and has only be inferred from the oral explanations provided by one of 
the co-editors.

Furthermore, the client indicates (i.e. claims) to the AS the 
identity/identifier of the end-user. However, since the AS has no way to 
know whether the client
software can be trusted, the AS cannot rely on that claimed information. 
This means that the client/AS protocol, as currently described, is insecure.

In draft-ietf-gnap-core-protocol-06, the client instance secures its 
requests to the AS and RS by presenting an access token, presenting 
proof of a key that it possesses,
or both an access token and key proof together. Such a protection is 
illusory, since a collaborative client is able to perform all the 
cryptographic computations that
another collaborative client needs to claim to be the "owner" of the 
access token. With the use of an Hardware Security Module (HSM), the 
same situation remains.
This means that the client/RS protocol, as currently described, is insecure.

Does the description that is present in draft-ietf-gnap-core-protocol-06 
allows to demonstrate that the protocol is secure? Unfortunately, the 
response to this question
is negative, since the "Security Considerations section" is nearly empty.

Does the description that is present in draft-ietf-gnap-core-protocol-06 
allows to interoperate ? Unfortunately, the response to this questions 
is also negative,
since the structure of the access tokens is left undefined. In 
particular, the verifications that a RS *SHALL* perform on the content 
of an access token to make sure
that it is valid are left undefined. Currently, GNAP is a framework, 
like OAuth 2.0 (RFC 6749) and OAuth 2.1 (draft-ietf-oauth-v2-1-01), and 
is not an interoperable protocol.

At the moment, draft-ietf-gnap-core-protocol-06 only supports "rights". 
In the security literature, this is a Capability based access control 
(CBAC) scheme.
Since a privilege is currently described as being a right and/or an 
attribute, an Attribute based access control (ABAC) scheme should also 
be supported.
This is not the case at the moment.

I have successfully submitted and posted to the IETF repository an 
Individual Submission of an I-D.

    Name:        draft-pinkas-gnap-core-protocol
    Revision:    00
    Title:           Grant Negotiation and Authorization Protocol
    Document date:    2021-08-19
    Group:         Individual Submission
    Pages:         33
    URL: 
https://www.ietf.org/archive/id/draft-pinkas-gnap-core-protocol-00.txt
    Status: 
https://datatracker.ietf.org/doc/draft-pinkas-gnap-core-protocol/
    Htmlized: 
https://datatracker.ietf.org/doc/html/draft-pinkas-gnap-core-protocol

*Abstract:*

       This protocol enables an Authorization Server (AS) to issue 
access  tokens to permit an end-user using a client software to perform
       operations on a protected resource hosted by a Resource Server 
(RS).  These access tokens allow to support capabilities and/or user
       attributes.

       The protocol includes means of specifying how the end-user can  
potentially be involved in an interactive fashion during the
       process.  The client and/or the RS will use these interaction 
mechanisms to involve the end-user, as necessary, to take decisions.

       The protocol uses HTTPS for all communications between the client 
and the AS, as well as between the client and the RS.

Being a version -00, this 33 pages document explains the main concepts 
but does not provide the details of the protocols. The document includes
a Trust Relationships section (1.5) and both a Security Considerations 
section (4) and a Privacy Considerations section (5).

The flow of operations for an access to a protected resource is 
illustrated in Figure 2, on page 26. The creation of RS user accounts is 
not illustrated
on this figure but is explained in the text before.

Denis

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Aug 2021 14:03:45 -0400

I want to clarify one point of confusion here:

>            "The initial work will focus on using HTTPS for communication between the client and the authorization server, (...)"
> 
>            See: https://datatracker.ietf.org/doc/charter-ietf-gnap/ <https://datatracker.ietf.org/doc/charter-ietf-gnap/>
> 
> Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use of HTTPS for communication between the client and the authorization server 
> and does not take advantage of the security properties obtained thanks to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06 
This was quoted out of context and misrepresents the goal. If you read the rest of that sentence, you’ll see that it’s talking about HTTP versions:

The initial work will focus on using HTTPS for communication between the client
and the authorization server, taking advantage of optimization features of
HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to
other protocols such as CoAP when doing so does not conflict with the primary
focus.
What this is saying is that we shouldn’t make something that is only deployable on HTTP/1.

Additionally, the GNAP core draft does already require HTTPS. While the security considerations section (section 12) is not yet filled out (though note — this one of the topics the editors are actively working on), the one item it does have in there mandates HTTPS:

	All requests have to be over TLS or equivalent as per [BCP195 <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#BCP195>].

Therefore, the statement as asserted in this email, and the conclusions that follow it, are not accurate.

 — Justin

---

From: Denis <[email-masked]>
Date: Fri, 20 Aug 2021 10:09:19 +0200

Hi Justin,

There is a difference between the following two sentences :

         All *requests *have to be over TLS or equivalent as per [BCP195 
<https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#BCP195>]. 

        (from : draft-ietf-gnap-core-protocol-06 on *page 105*)

Which "requests" ? Access token requests ? Requests from which entity to 
which other entity ?

and

       The protocol uses HTTPS for all *communications *between the 
client and the AS, as well as between the client and the RS.
       (from: draft-pinkas-gnap-core-protocol-00 on *page 1*).

IMO, the first one is ambiguous  while the second one is crystal clear.

As I wrote, nowhere in draft-ietf-gnap-core-protocol-06, the text is 
taking advantage of the security properties obtained thanks to the use 
of HTTPS.

Nevertheless, there are many other major issues raised about 
draft-ietf-gnap-core-protocol-06, that 
draft-pinkas-gnap-core-protocol-00 attempts
to address and to solve.

The very first version of draft-pinkas-gnap-core-protocol has been 
written from scratch with a Trust Relationships section (1.5) and both
a Security Considerations section (4) and a Privacy Considerations 
section (5). Writing these three sections in a very first version is a
good way to have a document understandable and coherent.

Denis

>> Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the 
>> use of HTTPS for communication between the client and the 
>> authorization server
>> and does not take advantage of the security properties obtained 
>> thanks to the use of HTTPS. This means that 
>> draft-ietf-gnap-core-protocol-06
> This was quoted out of context and misrepresents the goal. If you read 
> the rest of that sentence, you’ll see that it’s talking about HTTP 
> versions:
>
> Additionally, the GNAP core draft does already require HTTPS. While 
> the security considerations section (section 12) is not yet filled out 
> (though note — this one of the topics the editors are actively working 
> on), the one item it does have in there mandates HTTPS:
>
> All requests have to be over TLS or equivalent as per [BCP195 
> <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#BCP195>].
>
>
> Therefore, the statement as asserted in this email, and the 
> conclusions that follow it, are not accurate.
>
>  — Justin

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 20 Aug 2021 12:48:25 +0200

Hi Denis,

I don't understand why you believe the wording in the draft is unclear, but
if so a PR is always welcome. There's no ambiguity as to whether HTTPS is
what we ask for.

The editors always said there would be sections dedicated to trust /
privacy / security. It should land into the github repository soon, but the
underlying assumptions are different.

As for the rest of your draft, there are interesting ideas, but seems to me
that some are either case specific or out of scope of our charter.

Cheers
Fabien

Le ven. 20 août 2021 à 10:09, Denis <[email-masked]> a écrit :

>       The protocol uses HTTPS for all *communications *between the client
> taking advantage of the security properties obtained thanks to the use of
> HTTPS.
>
> draft-ietf-gnap-core-protocol-06, that draft-pinkas-gnap-core-protocol-00
> attempts
> to address and to solve.
>
> The very first version of draft-pinkas-gnap-core-protocol has been written
> from scratch with a Trust Relationships section (1.5) and both
> a Security Considerations section (4) and a Privacy Considerations section
> (5). Writing these three sections in a very first version is a
>            "The initial work will focus on using HTTPS for communication
> between the client and the authorization server, (...)"
>
> and does not take advantage of the security properties obtained thanks to
> the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06
> This was quoted out of context and misrepresents the goal. If you read the
> rest of that sentence, you’ll see that it’s talking about HTTP versions:
>
> Additionally, the GNAP core draft does already require HTTPS. While the
> security considerations section (section 12) is not yet filled out (though
> note — this one of the topics the editors are actively working on), the one
> item it does have in there mandates HTTPS:
>
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>