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

[Denis <[e-mail]>]

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