Re: [OAUTH-WG] PAR and client metadata

Filip Skokan <panva.ip@gmail.com> Mon, 27 April 2020 18:58 UTC

Return-Path: <panva.ip@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3A03A1932 for <oauth@ietfa.amsl.com>; Mon, 27 Apr 2020 11:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni5n738e3SAh for <oauth@ietfa.amsl.com>; Mon, 27 Apr 2020 11:58:08 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532FB3A1912 for <oauth@ietf.org>; Mon, 27 Apr 2020 11:58:07 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id d197so5589077ybh.6 for <oauth@ietf.org>; Mon, 27 Apr 2020 11:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D6O8XRJpcPmJGKd6bTSWaemEtzzj/LgjEUIybsWH0eY=; b=Z8pQGfbwbfZMKXfqRBzyH3wjWLj2cZzGKEW6Iw7kEuS80StHnG0NinpUXC0Epll2QG 4oHhpF2GsB2TOJPzP6UZzvhoIeevYmD5sMsVTM99pUj39FYcisSrmog2vY9VgLb4NaKq YDQ0m0TuHy+De20VVHtH3Mw1olWoBCes6gSJLjGPUhsGl3SqX0pkP1vbqh3Io7h57ddz aSuQCs+A4lNVkQ0EmODxs2s54xTI3jwi1i3GJfmP2AQorlTjyTIcnkfwJYKGtSj++2Ba Z1vUzbQzwCGxeCuVpG86+KU2j3mT/SYXJtq6JfUIiD0sW9lJbTZ0F14oHviTRcYfN9El ZJqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D6O8XRJpcPmJGKd6bTSWaemEtzzj/LgjEUIybsWH0eY=; b=BMhAH2A+Cj+I+qvhdQjGD1A5W56ADbAOmnXIvLHdpZKpmCPVlUHPBgK3AdNyF7BB+Y ELU7uM5XjncP2PP2gGpScLRLRHSTzloRUcK/gSjvGKCYjQVR+siWULm55+NKVl4WMv7T JF6V9dDTXxLBgYYt39yk/YgyW6xCb3Gy061NBMrXy5ibLEHhFaryeEo9GR0NCBBBRsF3 +KCXOG/w7vlsxMaLMpGHU0TuUc08UzMGaQHefCEocKJG0/9KMNw0zBLKodLjFUKwXABh zCmI7taYreewIYydIutQcnpaShJ3Cp2VsZWswASGWYYtfe1+uKGf2c1sBPrSS94d6wCf VZrw==
X-Gm-Message-State: AGi0PuZ7WeOHOs75JgaPVhN8q1ajFQrnebQfjSGtweecUVikFD9iZjWn v2zmKOpARTu7HjtLgXmIy9ujm/z/zlXe5J2bsg==
X-Google-Smtp-Source: APiQypLQBeM4viA+3F0piQrAouoDhe3j0WEmk0cuVcJE4z5TEtusFDeYTE/z7PDHE54t1vj5/Irv8V0gWrjJLy4TQjA=
X-Received: by 2002:a25:13c1:: with SMTP id 184mr35858698ybt.259.1588013886088; Mon, 27 Apr 2020 11:58:06 -0700 (PDT)
MIME-Version: 1.0
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com> <CA+k3eCQK-1VZBAXCE+QHLNC44dzpVOMjBvZG183v4zq0Po0cyg@mail.gmail.com> <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com> <CDDFE2C7-F7E6-4B01-A514-18432E6E602A@lodderstedt.net>
In-Reply-To: <CDDFE2C7-F7E6-4B01-A514-18432E6E602A@lodderstedt.net>
From: Filip Skokan <panva.ip@gmail.com>
Date: Mon, 27 Apr 2020 20:57:29 +0200
Message-ID: <CALAqi_-eS-yqHfeixdU6O+DUqF0rGEc4x-+8kxLq8xGVS+z-Sg@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000942a6805a44a4b5a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/S76ODyZkHPSA6L69yyx08BuEP5M>
Subject: Re: [OAUTH-WG] PAR and client metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 18:58:17 -0000

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=
40lodderstedt.net@dmarc.ietf.org> 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 <vladimir@connect2id.com>
> 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=
> 40amazon.com@dmarc.ietf.org> 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=
> 40pingidentity.com@dmarc.ietf.org> 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 <
> vladimir@connect2id.com> 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
> >>>>
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> 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
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>