Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata
Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 07 January 2020 13:58 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 9A32712010D for <oauth@ietfa.amsl.com>; Tue, 7 Jan 2020 05:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 UgS_-RvDpDfv for <oauth@ietfa.amsl.com>; Tue, 7 Jan 2020 05:58:25 -0800 (PST)
Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (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 7709E120120 for <oauth@ietf.org>; Tue, 7 Jan 2020 05:58:25 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id opNGik7E8n9FUopNHitjBq; Tue, 07 Jan 2020 06:58:24 -0700
x-spam-cmae: v=2.3 cv=SNc8q9nH c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=UM_DoP-0AAAA:8 a=LS6YZpeZAAAA:8 a=vggBfdFIAAAA:8 a=DVqm7IH0AAAA:8 a=-B3230MOAAAA:8 a=pGLkceISAAAA:8 a=BBoBmrX5DfzL3ZKhHt8A:9 a=MuVwZFWdJ64b3vTM:21 a=Ty4s1fouFGWNx9UI:21 a=QEXdDO2ut3YA:10 a=r_AD4E2wVIxbPAgEuloA:9 a=tgtXeDFGb3I7toZQ:21 a=P4tNvQTW8I36gEdL:21 a=jVb8tlh8HRYajJk3:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=TEVHQOIvcflanWNqQbWu:22 a=IRr2vCDBpksuBOXhfkKu:22 a=M6wP_kGduNurgptF5PJY:22 a=Z6yIbYtmj3_f4zpjOCXI:22 a=IdGyktwZ2tr74praB_5u:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
To: Filip Skokan <panva.ip@gmail.com>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Dave Tonge <dave.tonge@moneyhub.com>, oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>
References: <E1C4F217-8A9F-4E26-A488-C17D741C1D34@lodderstedt.net> <CALAqi_-J6vUSc11V1L2L+tGfZEjqdya6R0rqV-kxiM2NoFb0Zw@mail.gmail.com> <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> <CA+k3eCS6SdAKjOp67o_zUytnNGnpM4p5UO68CvZeEXg11PWrtg@mail.gmail.com> <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> <CALAqi_8tM4E0UgOt0Bq-DTx0d-putVWv-grt6=jXVES5GHfMZw@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>
Date: Tue, 07 Jan 2020 15:58:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CALAqi_8tM4E0UgOt0Bq-DTx0d-putVWv-grt6=jXVES5GHfMZw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030205050400070805000602"
X-CMAE-Envelope: MS4wfJ0fCYBSZ1rLzyqyVkZuZ8CDGICBQQUHGaMbMB9Zg2dr/oEkCQ9VqIlaYOHm8qlWHaGUX1yO5uikg7N6hL2fZZRDtrgP1s7c6IXJazKJenMX1VClVwT+ DT3pCp+XyjTYuVM5o/kj+0RRaxwbb0ad/LjRCd3asM72oYjVRKdgpguuRnvDzY4e1cLNcBb44d1Jx5+SfxN+BXRQKSnalseiMc50zg6+gcp05rTLtHWKiU0D 3PDnEQtXU2qqQWAsdq1PbXA41EnXdlF8TUiEOYkDMuYnbaZVUOuAfZ3ON3CbjiJ1phZj+Xgvi2tHmHATL/5eqQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Lz6kWcdZP5lD1hVE6b8l3Ez6fQw>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR 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: Tue, 07 Jan 2020 13:58:28 -0000
On 07/01/2020 00:22, Filip Skokan wrote: > We've been discussing making the following change to the language > > The AS SHOULD validate the request in the same way as at the > authorization endpoint. The AS MUST ensure that all parameters to > the authorization request are still valid at the time when the > request URI is used. > Could you expand a bit on the second sentence? Alternative suggestion: The AS MUST validate the request in the same way as at the authorization endpoint, or complete the request validation at the authorization endpoint. Vladimir > This would allow the PAR endpoint to simply stash the encrypted > request object instead of decrypting and validating it. All within the > bounds of "SHOULD - We’d like you to do this, but we can’t always > require it". This supports "light weight PAR" implementation rather > than introducing the unnecessary complexity in the form of a second JWKS. > > Best, > *Filip* > > > On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle > <richanna=40amazon.com@dmarc.ietf.org > <mailto:40amazon.com@dmarc.ietf.org>> wrote: > > The issue isn’t that the PAR endpoint needs access to one specific > request object decryption key that could reasonably be shared > across AS endpoints, but that it actually needs access to the > private keys for all encryption public keys in the JWK set pointed > to by the AS’s jwks_uri metadata property. Since there is no way > to designate one particular key as the one to use for encrypting > request objects, clients may reasonably use any encryption public > key in the JWK set to encrypt a request object. As one example of > how this could expose sensitive data to the PAR endpoint, if the > PAR endpoint has all the decryption keys for the keys in the AS’s > JWK set, it would be able to decrypt ID Tokens sent in > id_token_hint request parameters. As more and more use cases > develop for encrypting blobs for the AS, this issue will only get > worse. > > > > The PAR endpoint can’t simply stash the encrypted request object, > as it is required to verify the request, according to §2.1: > > > > The AS MUST process the request as follows: > > > > ... > > > > 3. The AS MUST validate the request in the same way as at the > > authorization endpoint. ... > > > > This language needs to be more flexible, IMHO, to allow for > lightweight PAR endpoints that may not have the information or > authority needed to perform all the validation that happens at the > authorization endpoint. I need to think about this more before I > can say if it would adequately address my concerns, but it’d be a > good start and makes sense in its own right. > > > > I think it’s pretty risky for us to base decision on an assumption > that no one is going to need or want to encrypt pushed request > objects, particularly when they’re JWTs, and JWTs have well > established support for encryption, and encrypted JWTs are > supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. > But if you insist, here are a few examples for why someone might > want to do this: > > 1. The request object is passed by reference, and accessible on > the public Internet. > 2. The request object contains sensitive transaction-related data > in RAR parameters that the client’s authN/authZ stack doesn’t > need to have access to. > 3. The AS requires request object encryption to minimize exposure > to the hosted PAR endpoint service it uses. > 4. #2, but the threat vector is gaps in end-to-end TLS. > 5. Any of the above, but the concern is message integrity, and > the AS requires requested objects to be encrypted for > confidentiality and integrity protection and does not support > signed request objects. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Neil Madden <neil.madden@forgerock.com > <mailto:neil.madden@forgerock.com>> > *Date: *Monday, January 6, 2020 at 6:29 AM > *To: *Brian Campbell <bcampbell@pingidentity.com > <mailto:bcampbell@pingidentity.com>> > *Cc: *"Richard Backman, Annabelle" <richanna@amazon.com > <mailto:richanna@amazon.com>>, Nat Sakimura <nat@sakimura.org > <mailto:nat@sakimura.org>>, Dave Tonge <dave.tonge@moneyhub.com > <mailto:dave.tonge@moneyhub.com>>, Torsten Lodderstedt > <torsten@lodderstedt..net <mailto:torsten@lodderstedt.net>>, oauth > <oauth@ietf.org <mailto:oauth@ietf.org>> > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata > > > > Agreed. > > > > In addition, I'm not sure why the PAR endpoint would need access > to the decryption keys at all. If you're using encrypted request > objects then the PAR endpoint receives an encrypted JWT and then > later makes the same (still encrypted) JWT available to the > authorization endpoint. If the PAR endpoint is doing any kind of > decryption or validation on behalf of the authorization endpoint > then they are clearly not in separate trust boundaries. > > > > -- Neil > > > > > > On 6 Jan 2020, at 13:57, Brian Campbell > <bcampbell=40pingidentity.com@dmarc.ietf.org > <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>> wrote: > > > > I really struggle to see the assumption that an entity be able > to use the same key to decrypt the same type of message > ultimately intended for the same purpose as an artificial > limit. The same general assumption underlies everything else > in OAuth/OIDC (Vladimir's post points to some but not all > examples of such). There's no reason for PAR to make a one-off > exception. And should there be some deployment specific reason > that truly requires that kind of isolation, there are > certainly implementation options that aren't > compatibility-breaking. And having said all that, I'm honestly > a little surprised anyone is thinking much about encrypted > request objects with PAR as, at least with my limited > imagination, there's not really a need for it. > > > > > > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle > <richanna=40amazon.com@dmarc.ietf.org > <mailto:40amazon.com@dmarc.ietf.org>> wrote: > > PAR introduces an added wrinkle for encrypted request > objects: the PAR endpoint and authorization endpoint may > not have access to the same cryptographic keys, even > though they're both part of the "authorization server." > Since they're different endpoints with different roles, > it's reasonable to put them in separate trust boundaries. > There is no way to support this isolation with just a > single "jwks_uri" metadata property. > > The two options that I see are: > > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. > > I strongly perfer #1 as it has a very minor impact on > deployments that don't care (i.e., they just set > par_jwks_uri and jwks_uri to the same value) and failing > to support this trust boundary creates an artificial limit > on implementation architecture and could lead to > compatibility-breaking workarounds. > > – > Annabelle Richard Backman > AWS Identity > > > On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten > Lodderstedt" <oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org> on behalf of > torsten=40lodderstedt.net@dmarc.ietf.org > <mailto:40lodderstedt.net@dmarc.ietf.org>> wrote: > > Hi Filip, > > > On 31. Dec 2019, at 16:22, Filip Skokan > <panva.ip@gmail.com <mailto:panva.ip@gmail.com>> wrote: > > > > I don't think we need a *_auth_method_* metadata for > every endpoint the client calls directly, none of the new > specs defined these (e.g. device authorization endpoint or > CIBA), meaning they also didn't follow the scheme from RFC > 8414 where introspection and revocation got its own > metadata. In most cases the unfortunately named > `token_endpoint_auth_method` and its related metadata is > what's used by clients for all direct calls anyway. > > > > The same principle could be applied to signing (and > encryption) algorithms as well. > > > > This I do not follow, auth methods and their signing > is dealt with by using > `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - > there's no encryption for the `_jwt` client auth methods. > > Unless it was meant to address the Request Object > signing and encryption metadata, which is defined and IANA > registered by OIDC. PAR only references JAR section 6.1 > and 6.2 for decryption/signature validation and these do > not mention the metadata (e.g. request_object_signing_alg) > anymore since draft 07. > > Dammed! You are so right. Sorry, I got confused somehow. > > > > > PS: I also found this comment related to the same > question about auth metadata but for CIBA. > > Thanks for sharing. > > > > > Best, > > Filip > > thanks, > Torsten. > > > > > > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt > <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> > wrote: > > Hi all, > > > > Ronald just sent me an email asking whether we will > define metadata for > > > > pushed_authorization_endpoint_auth_methods_supported and > > > pushed_authorization_endpoint_auth_signing_alg_values_supported. > > > > The draft right now utilises the existing token > endpoint authentication methods so there is basically no > need to define another parameter. The same principle could > be applied to signing (and encryption) algorithms as well. > > > > What’s your opinion? > > > > best regards, > > Torsten. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth >
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metada… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metada… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metada… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metada… Filip Skokan
- [OAUTH-WG] PAR metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR metadata Filip Skokan
- Re: [OAUTH-WG] PAR metadata Brian Campbell
- Re: [OAUTH-WG] PAR metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR metadata Richard Backman, Annabelle
- Re: [OAUTH-WG] PAR metadata Vladimir Dzhuvinov
- Re: [OAUTH-WG] PAR metadata Brian Campbell
- Re: [OAUTH-WG] PAR metadata Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metada… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Torsten Lodderstedt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metada… Justin Richer
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Justin Richer