Subject: Re: [OAUTH-WG] PAR and client metadata

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 1 May 2020 11:49:10 +0200

wfm - thanks.

Brian Campbell <bcampbell=[email-masked]> schrieb am Mo.
27. Apr. 2020 um 21:06:

> require_pushed_authorization_requests works for me and is maybe/arguably a
> bit better by being more consistent with other names.
>
> On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan <[email-masked]> wrote:
>
>> Alternatively, `require_pushed_authorization_requests`. Since we already
>> have the `*require_*request_uri_registration` server and `*require_*
>> auth_time` client metadata properties.
>>
>> WDYT?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt <torsten=
>> [email-masked]> wrote:
>>
> Hi all,
>>>
>>> I think this topic has several aspects:
>>> - Is the client required to use PAR only? Doesn’t this also mean it is
>>> required to use request_uri only?
>>> - Is there a need to separate those to questions or shall we treat this
>>> as the same?
>>> - Who decides whether PAR and request_uri are required? The client for
>>> its instances or the AS for the whole deployment?
>>>
>>> I’m in favour of coupling enforced PAR use with enforced request_uri use
>>> even though it means the setting is useful with PAR only, not with all
>>> JAR-based clients.
>>> I think both the client as well as the AS should be able to declare
>>> forced PAR. If the AS is able to basically turn of traditional
>>> authorization requests, it can consequently utilize the changed protocol
>>> properties in terms of security and robustness in its deployment. This
>>> means, for example, the AS no longer needs to require pre-registered
>>> redirect URIs for confidential clients. It also means, the AS can use
>>> voluminous claims/authorization details objects without worrying about
>>> fragile long request URLs.
>>>
>>> So here is my proposal:
>>>
>>> 1) Add server metadata parameter “pushed_authorization_requests_only” of
>>> type boolean - It requires any client to use PAR, the AS will refuse to
>>> process any authorization request containing parameters other than
>>> request_uri + client_id (as required by
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
>>> request parameters need to be passed via PAR.
>>> 2) Add client registration parameter
>>> “pushed_authorization_requests_only” - It requires this client to use PAR
>>> only. The AS won’t accept any authorization request containing more than
>>> request_uri + client_id for that particular client.
>>>
>>> What are your thoughts?
>>>
>>> best regards,
>>> Torsten.
>>>
>>> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov <[email-masked]>
>>> wrote:
>>> >
>>> > In a off-list conversation Torsten floated the idea of letting
>>> confidential PAR-only clients register without a redirect_uris and having
>>> this "PAR only" parameter will enable that.
>>> >
>>> > A "PAR only" parameter will also prevent client developers from
>>> accidentally making plain authz requests (for clients that rely on PAR for
>>> the extra security).
>>> >
>>> > Vladimir
>>> >
>>> > On 16/04/2020 18:39, Brian Campbell wrote:
>>> >>
>>> >>
>>> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle <richanna=
>>> [email-masked]> wrote:
>>> >> 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).
>>> >>
>>> >> As I tried to articulate in the original email and Filip also
>>> mentioned in a different fork of this email thread, defining metadata can
>>> be beneficial even when it's not used dynamically at runtime. So we're not
>>> only talking about dynamic clients.
>>> >>
>>> >>
>>> >>
>>> >> 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).
>>> >>
>>> >> A per client setting seems necessary for existing ASs to roll out PAR
>>> support over time or just generally in support of diverse client
>>> capabilities and requirements.
>>> >>
>>> >>
>>> >> 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.
>>> >>
>>> >> This client metadata parameter is meant to be something that would
>>> prevent a malicious actor from controlling the content of the authz request
>>> parameters, which could be done by crafting the link and tricking a user
>>> into following it. I mentioned mix-up as an example because the first
>>> variant of it desribed at
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>>> does something along those lines.
>>> >>
>>> >>
>>> >>
>>> >> 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=
>>> [email-masked]> 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 <
>>> [email-masked]> 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
>>> 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
>>> >>>>
>>> >>>> [email-masked]
>>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>
>>> >>> _______________________________________________
>>> >>> OAuth mailing list
>>> >>> OAuth@ietf...org <[email-masked]>
>>> >>> 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
>>> >>> OAuth@ietf...org <[email-masked]>
>>> >>> https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > [email-masked]
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>
>
>> OAuth mailing list
>> [email-masked]
>> 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.*