Re: [OAUTH-WG] PAR and client metadata

Vladimir Dzhuvinov <vladimir@connect2id.com> Sun, 19 April 2020 08:09 UTC

Return-Path: <vladimir@connect2id.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 C8C993A074B for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 01:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.211
X-Spam-Level: *
X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MISSING_HEADERS=1.207, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 OXV6NC6guWYD for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 01:09:22 -0700 (PDT)
Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0A93A0747 for <oauth@ietf.org>; Sun, 19 Apr 2020 01:09:21 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Q50xjBTawnYyoQ50yjg0Y6; Sun, 19 Apr 2020 01:09:21 -0700
X-CMAE-Analysis: v=2.3 cv=d86LNirE c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=4kG_aAeuAw_d-pNtDboA:9 a=hVy5dM5bJJFa2tYy:21 a=QymQuDMcWa3YDhTZ:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=DVh3MC2FUoLFXO0QobUA:9 a=OBK4qm-CHOFXXD4I:21 a=F02Jg16fTNAJCQ-b:21 a=HKBuKgiWF3ZbqhlZ:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
Cc: oauth <oauth@ietf.org>
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com> <CA+k3eCQK-1VZBAXCE+QHLNC44dzpVOMjBvZG183v4zq0Po0cyg@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>
Date: Sun, 19 Apr 2020 11:09:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCQK-1VZBAXCE+QHLNC44dzpVOMjBvZG183v4zq0Po0cyg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060206000806060900080801"
X-CMAE-Envelope: MS4wfNtkJvTZCkVkqBgGPvzQdFSWwohwHSsztUFLup0W400G3f6VHa6k4hiq07VQRGP1/L6r/wyf/0QxIalPo/tUfyPOvtD6JdriPxrSn2gOCpHPFMauOEZS Jl3mTIcLVtQBuJQx8V0iNYZT65TxTu6mG1i+QFOySXQU1v0T7Dg9rOvD
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Uiz82mBvhPTTtA53jxeUFQDMJMw>
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: Sun, 19 Apr 2020 08:09:24 -0000

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
> <mailto: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
>>     <mailto: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 <mailto: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
>>>         <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 <mailto:OAuth@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org <mailto: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 <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>