Re: [GNAP] RS validation of access tokens

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 <jricher@mit.edu> 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 <yaronf.ietf@gmail.com> 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 <txauth-bounces@ietf.org> on behalf of Justin Richer <
> jricher@mit.edu>
> *Date: *Tuesday, 22 August 2023 at 17:49
> *To: *GNAP Mailing List <txauth@ietf.org>
> *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 <jricher@mit.edu> 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
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> -- TXAuth mailing list TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>