Re: [GNAP] RS validation of access tokens

[Justin Richer <[e-mail]>]

Any key provided would be used to present the access token. A key used to decrypt the resource by the client would need to be some kind of api-specific extension for it to be provided. You could use the same key structures, or even declare as part of your API that it uses the same keys, but GNAP does not provide a mechanism for that kind of information on its own because it’s specific to the resource being protected.

 — Justin

On Aug 23, 2023, at 5:47 PM, Adrian Gropper <[e-mail]> wrote:

Apologies for not completely understanding the issue and this may be a dumb question.

In our use-case, the resource is typically encrypted at rest. Whatever interaction there is between the CI and AS, does GNAP specifiy how the AS can provide a key to the CI?

Thanks,
Adrian

On Wed, Aug 23, 2023 at 10:19 AM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
I had a similar conversation with the researchers. The feature is there largely for symmetric keys, but it’s possible that the AS could provide a key pair back to the client in this field to use asymmetric crypto.

My personal take, as an implementor, is that we can address this with warnings about its intended use, and with a full discussion about the tradeoffs and increased attack surfaces it’s not really relevant whether it’s a symmetric key or an asymmetric one.

Another possible response is to remove the AS-provided key feature entirely and relegate it to an extension. That’s a more drastic change at this stage, of course. I don’t have a good insight into how much this particular feature is used in the wild.

 — Justin

On Aug 23, 2023, at 12:28 PM, Yaron Sheffer <[e-mail]<mailto:[e-mail]>> wrote:

Hi Justin,

Thank you for clarifying this attack with the researchers.

Regarding your first bullet, I went back to the core protocol and I’m wondering why we allow a key to be included in the Grant Response. The document does not shed any light on use cases for this feature. If this is only useful for symmetric keys (is it?), we could restrict it explicitly to this particular case in order to reduce the attack surface. It is not too late to tweak the protocol if this would improve its security.

Thanks,
                Yaron

From: TXAuth <[e-mail]<mailto:[e-mail]>> on behalf of Justin Richer <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 22 August 2023 at 17:49
To: GNAP Mailing List <[e-mail]<mailto:[e-mail]>>
Subject: Re: [GNAP] RS validation of access tokens

This issue was discussed today at the OAuth Security Workshop, I was in attendance along with three of the researchers who had proposed the issue into GitHub. Fundamentally, we came to the understanding that the security property being modeled under attack was not fundamental to GNAP, but it does warrant a reasonable set of warnings for implementors to avoid accidentally stumbling into it.

The proposed outcome is to write or clarify three main points:

- Call out more clearly that a token with an AS-provided key has some of the same attack surfaces as a bearer token. While such a token could not be used directly by the RS, it can be captured and replayed to an unwitting client application by an attacker, with the key intact. Warnings against using and accepting AS-provided keys will be written up. Currently the feature will remain in the core specification with these warnings in the RS draft, though this may warrant a specific cross reference added to core.

- As proposed in the issue below by Yaron, a new section will be written in the RS draft describing the importance of AS choice for token validation and acceptance.

- A new security consideration section in the RS draft that discusses the token substitution attack, the circumstances under which it can occur, and the tradeoffs for those circumstances.


If you have input into any of these items, please suggest text that might help.

Thank you,
 — Justin




On Jul 29, 2023, at 5:54 AM, Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:

As discussed in the meeting today, the following issue raises a question on the security properties of the RS processing tokens during a specific kind of attack:

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

While the editors believe that this can be addressed sufficiently with a security consideration, the conversation in the room indicated that there is further discussion that needs to be had first. The editors and chairs are planning to reach out to the research team that filed the issue for clarification. With the OAuth Security Workshop coming up, this might prove a good opportunity to discuss the issue with the security and research community. The editors will bring the results of those discussions back to the list.

If you have something to add to the attack and model as described, please add to the discussion on the GitHub issue.

 — Justin
--
TXAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/txauth

-- TXAuth mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/txauth