Re: [OAUTH-WG] PAR and client metadata
Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 01 May 2020 09:49 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 6DE153A0D76 for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 02:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=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 wtxtpLurfM7h for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 02:49:23 -0700 (PDT)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 E826C3A0D74 for <oauth@ietf.org>; Fri, 1 May 2020 02:49:22 -0700 (PDT)
Received: by mail-vk1-xa32.google.com with SMTP id 10so2576516vkr.7 for <oauth@ietf.org>; Fri, 01 May 2020 02:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HUbOeFAzPPIU0nl758HZ6ElbP4Te0GZHHmU+EdT101w=; b=04mTdpKf5vnLyzGOcirLZiIa+OL6ShD5pkoN+YpM/8zcy4+mqI427y630dVgQCyFa4 7+nH9lN7FQ4VkXiYHaQfiEo4pGrtu0PH0PrylwqQwdoJAHcZduQLpUB4sabl68WBFilJ hAICFK9AMs2wsXrNNXNLprMX1aB9kt3PatUlIFm7TD2j3mh3RBPbzp4GMUj1A3k++I6R uSaYVDMmfQ1u9Qi2PrLqHrWefRiR5iDdpqXxQ3e7Nj8p2q6G4GevU3Rb+hz8XxboxGbU IA0Dig0HAaFmtJrWoMuwZgWZAuoYpIekW1dAc7XuythRl2USZCTXrZqaUF99WZP6q5Ve Hq5Q==
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=HUbOeFAzPPIU0nl758HZ6ElbP4Te0GZHHmU+EdT101w=; b=kqtZEgpXKMkUdIN9H2EMOSkDdNYPNk8U1Fxxt+HxWbiwbjj730xHRnIRNpULxii8c5 h1PhzH6M9z2Sc7r6f4m4zXsg9i0CewoUFlsEisXSFKnlyZQRkEOzST1KJAYQD9WcJdgN 2CYRpR2aHQO0Axng5KWvGjWHjTE48QV1GQfUpJvH0fTG08bUa1FQpBB6XkGrReEV9Tss UJvFh+/IckAt53WZ1PBhP1qdrLu8sMkuSaJw/afFRTVUQO7rnugknbYtxYzwR8Ifxu6j Cbm7zWY21FX4AzahcmpMvjsj7k27xMbLIjKWBgE/ejLyZnyITi4/PAeHcUyNGWxCmDnK vxcA==
X-Gm-Message-State: AGi0PuZ6TkUs5jCCvnT4Ir6EWjYoVNU+njkMRs4AQc4Akotn3M4XUKKQ hnQZXBZ4HBMHqdgRe8wyYA0irCNfeMJ7WIruf6MTuQ==
X-Google-Smtp-Source: APiQypK3tqz5/WmH6BGny6zWJZYD2N2pzYxi6rtu1nqso9XJWF0lzz/85McJwStb5gNFidJMSmVW2Q9xRloqiwFde4A=
X-Received: by 2002:a1f:a786:: with SMTP id q128mr2113408vke.86.1588326561729; Fri, 01 May 2020 02:49:21 -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> <CALAqi_-eS-yqHfeixdU6O+DUqF0rGEc4x-+8kxLq8xGVS+z-Sg@mail.gmail.com> <CA+k3eCSe-ydb=OfrO4foJpNdH7TwZh6WdgJmMjgYhfxynR1MrQ@mail.gmail.com>
In-Reply-To: <CA+k3eCSe-ydb=OfrO4foJpNdH7TwZh6WdgJmMjgYhfxynR1MrQ@mail.gmail.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Fri, 01 May 2020 11:49:10 +0200
Message-ID: <CAHOkhHF-2L7OyxPjwRzDk8oQYvRCqtdFwK6vbggvq+BN9e9YtQ@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: Filip Skokan <panva.ip@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007fe2c105a49318bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qvfhZIz08yRtuEbgA7Ryka0pPno>
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: Fri, 01 May 2020 09:49:25 -0000
wfm - thanks. Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> 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 <panva.ip@gmail.com> 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= >> 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 <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 <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 >>> >> _______________________________________________ > > >> 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-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Vladimir Dzhuvinov
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Richard Backman, Annabelle
- Re: [OAUTH-WG] PAR and client metadata Filip Skokan
- Re: [OAUTH-WG] PAR and client metadata Sascha Preibisch
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata George Fletcher
- Re: [OAUTH-WG] PAR and client metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR and client metadata George Fletcher
- Re: [OAUTH-WG] PAR and client metadata Vladimir Dzhuvinov
- Re: [OAUTH-WG] PAR and client metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Filip Skokan
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Torsten Lodderstedt