Re: [OAUTH-WG] PAR and client metadata

["Richard Backman, Annabelle" <[e-mail]>]

As I think through this, I’m struggling to identify the threats this actually helps mitigate.

A client metadata parameter implies that the value may be different for different clients, and that any given client won’t already know via other means whether or not it needs to use PAR. That means we’re only talking about dynamic clients since statically registered clients already have some proprietary out-of-band registration mechanism (e.g., a developer console).

A client metadata parameter also implies that the AS allows some clients to make non-PAR requests (otherwise it would be an AS metadata parameter). If that’s the case then presumably a malicious party could register their own client that doesn’t use PAR.

So it seems to me that the only scenario that this parameter would protect against is a malicious party impersonating a dynamically registered client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack the attacker uses its own client.

If a client can do PAR, then it can do authorization code grant and PKCE, so we’re further limited to scenarios where the attacker does not need to be able to redeem the authorization code themselves. What threats fall into this category?

—
Annabelle Backman (she/her)
AWS Identity

On Apr 14, 2020, at 2:44 PM, Brian Campbell <bcampbell=[e-mail]> wrote:



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


I was hoping to get to a rough consensus in support of the idea before coming up with a name that everyone will hate :)

In the meantime, however, name suggestions are of course welcome.


On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <[e-mail]<mailto:[e-mail]>> wrote:

I'm all for that.

I suppose you have already thought of a suitable name? :)

Vladimir

On 14/04/2020 23:08, Brian Campbell wrote:
Using PAR can facilitate improved security by giving clients a (relatively) simple means for sending a confidential, integrity protected, and (for confidential clients anyway) authenticated authorization request.

It seems like some of that improved security could be undermined by a malicious actor somehow getting a user to navigate to a URL of a regular old parameterized authorization request. One variation of the Mix-Up Attack does this https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4..1> for example and email, social media, online forums, etc., are other ways a user might be tricked into following a maliciously crafted link.

Following from that it seems logical that an authorization server might want to restrict some clients from sending a regular parameterized authorization request and instead require use of the PAR endpoint to initiate an authorization request. Something like this could, of course, be implemented as custom policy or configuration in any AS. But I'm thinking it might be common enough to warrant adding a client metadata parameter to the PAR draft specifically for it. The metadata (and registered extensions) defined by Dynamic Client Registration [RFC7591] has come to imply a general data model and expected associated behaviors for clients that is useful for authorization server implementations, even when the Dynamic Client Registration Protocol isn't directly in play. This particular situation seems like a good potential candidate for a new such client metadata parameter that would indicate that the given client can only use a request_uri value obtained from the PAR endpoint to initiate an authorization request. And that a regular old fashioned authorization request from the given client would result in an error.

Do the folks of this fine WG think something like this would be a worthwhile addition to the PAR draft?





CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth