Re: [GNAP] RS validation of access tokens

[Justin Richer <[e-mail]>]

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]> 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]
https://www.ietf.org/mailman/listinfo/txauth