Re: [OAUTH-WG] PAR and client metadata

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 26 April 2020 14:57 UTC

Return-Path: <torsten@lodderstedt.net>
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 8965A3A07F0 for <oauth@ietfa.amsl.com>; Sun, 26 Apr 2020 07:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=lodderstedt.net
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 jacpxJcAPXDI for <oauth@ietfa.amsl.com>; Sun, 26 Apr 2020 07:57:49 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 CB0023A07EC for <oauth@ietf.org>; Sun, 26 Apr 2020 07:57:48 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id z6so17413734wml.2 for <oauth@ietf.org>; Sun, 26 Apr 2020 07:57:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E99585H9FZUFFzbPwRU8Es9IkjIKwmG8b9EwUAdzWbI=; b=rukzd30w8r9Kp8orbqHBMSdETtGG25LYXQwAr+neS1BbOtZRiu+EmuWzvHvB651KCN AeKRH8EcqFHUnLJba4R7IqiTdIC5drFZrFXOvJGPiTnke4KMc6uw6i94njPJhUrbbRLB 3bhZKKTyNJhiiqPgy/DfmfoBSgmRRTDPaXH9HCf7KgdXakQuz2rixPhL29gg+erkRLj5 hALCMPblh1S5GMzQCLTcZaBEs44ENq06JK/BvIkMbiqAm4hEGrmEDP9sxju1LfcI5eHL w9zVrEdb4EUEiW7I+CXM8sVLQ/DIH7sjNJ13Ou7bEz6PqQN48t/PWkuxK3E+7lOOaeeQ MZkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E99585H9FZUFFzbPwRU8Es9IkjIKwmG8b9EwUAdzWbI=; b=j76FgWU6yxIEjFoaHZU2mHnD15NAje/0uA4Ewq7nzuBlWShy9A285MH1S4Yz41WDfc EdbRrxHMk9cIlXeDrtSxYQzxa/dlRBs7z23jj9SaqVfOzBbegjiCzvaZiWuQPEdrxhfg JyieBrC36msrqiL4/5v0q/Kk7Ku37/JocmBe4HS9i0IN89aiAI8sVAEdJ3DJofPQEPo8 S7vz0uxeLfCQlRSnA/rIwq7juRqE5ztaokf1GSQJQ3B4EqcV3reNDjYvIlBUT+fH2TUI DGKmEJ6XbzBg9gKAG2/ec3Te1FFhLF+LDD5eXUYice7E4xXT2HcgOIySV3VYWZaZDsPR CJEA==
X-Gm-Message-State: AGi0PuZxA7h9qORYhCmD5GkViLFgYiRF9WCgh1zJwC7Fophe41brQG5m tO5HRUFI/fIZTFwipk6TMnLLl14phA0=
X-Google-Smtp-Source: APiQypLpTu4e0IuqwCF6dHQoOTulIvztL61Kk5DbmhKHU96Xl1R/f3bufoKjKdxu2KS/1XecJJF0+Q==
X-Received: by 2002:a1c:770e:: with SMTP id t14mr20653601wmi.187.1587913066112; Sun, 26 Apr 2020 07:57:46 -0700 (PDT)
Received: from p200300eb8f301fbe504ffe40cdc43adf.dip0.t-ipconnect.de (p200300EB8F301FBE504FFE40CDC43ADF.dip0.t-ipconnect.de. [2003:eb:8f30:1fbe:504f:fe40:cdc4:3adf]) by smtp.gmail.com with ESMTPSA id h16sm19460302wrw.36.2020.04.26.07.57.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 07:57:45 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>
Date: Sun, 26 Apr 2020 16:57:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDDFE2C7-F7E6-4B01-A514-18432E6E602A@lodderstedt.net>
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com> <CA+k3eCQK-1VZBAXCE+QHLNC44dzpVOMjBvZG183v4zq0Po0cyg@mail.gmail.com> <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gkGm6rQxC3eCf8WjRGNsE_YTwHg>
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, 26 Apr 2020 14:57:52 -0000

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