Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 22 October 2019 16:43 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 A342312009E for <oauth@ietfa.amsl.com>; Tue, 22 Oct 2019 09:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham 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 hWK6KHtqenMY for <oauth@ietfa.amsl.com>; Tue, 22 Oct 2019 09:43:18 -0700 (PDT)
Received: from p3plsmtpa11-03.prod.phx3.secureserver.net (p3plsmtpa11-03.prod.phx3.secureserver.net [68.178.252.104]) (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 9B83712004A for <oauth@ietf.org>; Tue, 22 Oct 2019 09:43:18 -0700 (PDT)
Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id MxFaicVvieKc0MxFciZbph; Tue, 22 Oct 2019 09:43:17 -0700
To: oauth@ietf.org
References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <CAGBSGjqdrCOZAu_2VvtjHVD+rBEK+0B86wNjoyXiQKAwS2Q4hA@mail.gmail.com> <CA+k3eCRatdXp=iMidbRMVxJWVADweykiNnFixH7povuoQzWSVQ@mail.gmail.com> <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> <CALAqi_8iCCYC4wm8rsH2EutiDmCWny4PB1-SNrrvM+Bi9o3Z3A@mail.gmail.com> <CDEA2590-FD94-4D84-9252-D22610461F35@mit.edu> <5F376EBC-866B-4E06-AEA9-0FFCB3625074@mit.edu>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Openpgp: preference=signencrypt
Organization: Connect2id Ltd.
Message-ID: <6cc98c4b-2ec6-1823-f4ba-54c14b49eced@connect2id.com>
Date: Tue, 22 Oct 2019 19:43:14 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <5F376EBC-866B-4E06-AEA9-0FFCB3625074@mit.edu>
Content-Type: multipart/alternative; boundary="------------B1F5927A64FD1E249A7C8CA4"
Content-Language: en-US
X-CMAE-Envelope: MS4wfEoNO0UapKwMOCgXMOLH1h0o/ids7pyuREnJBUiKVWhjmFGCyWGa3eF51eB7nBle7GgsE51fMvEdBA7irgM7CU9OHr8zfXaEyDKsvGWfdLNJecGKYFMk +1bujY36gIHx1I/iHAabBiG+W5/tUg58gQKqm7NFSlm8WMzAy8geuUp/
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/InBErY5r1bTHGxcHmtQOR2PxYp8>
Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
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, 22 Oct 2019 16:43:23 -0000
Thank you Justin for pointing this out. We had the exact same issue when we implemented encrypted JAR - and ended up requiring the client_id. In the absence of a client_id as top level parameter symmetric encryption cannot be handled because there's no good way to find out the client_client secret (unless we try all possible secrets, which is not feasible). We also have a policy to require_request_uri_registration=true and to avoid creating indices also require the client_id for request_uri requests. Vladimir On 10/10/2019 20:01, Justin Richer wrote: > In a related note, JAR currently allows “client_id” to be optional for > exactly the reason of it being included in the request object. > However, it falls into the same issue where you can’t decrypt the > request object without knowing which client’s keys to use, and you > can’t know which client you’re dealing with without decrypting the > object. I think that probably needs to be addressed in JAR. > > — Justin > >> On Oct 10, 2019, at 12:59 PM, Justin Richer <jricher@mit.edu >> <mailto:jricher@mit.edu>> wrote: >> >> Thanks for the response. My concern is that interpretation of the >> requirement to “authenticate the client” could be interpreted in the >> FAPI draft’s sense, which is to say validating the signature on the >> request object and not doing anything else. >> >> The problem comes from the fact that we’re effectively smashing >> together the conditions and assumptions of both the authorization >> endpoint and token endpoint into a new endpoint. It’s going to be >> messy, and we need to be very pedantic about what we mean if this >> draft is going to be implementable. >> >> — Justin >> >>> On Oct 10, 2019, at 3:07 AM, Filip Skokan <panva.ip@gmail.com >>> <mailto:panva.ip@gmail.com>> wrote: >>> >>> > If several of these are sent, they need to be consistent. >>> >>> Given that client authentication precedes processing the rest of the >>> request, if several client authentication methods are provided >>> (header + secret or secret + assertion, etc) you generally reject >>> the request, don't you? >>> >>> Then there's the requirement for the client_id given by >>> authentication method (none is still an "authentication" method - >>> client_id in the body) to match the `iss` and `client_id` in the >>> request object. That's already required by JAR processing rules and >>> also PAR. >>> >>> > But because JAR allows you to send in a request that is only a >>> request object, it also seems like you could pass in just the >>> request object with no other parameters, if I’m reading this right, >>> which would imply that you could be expected to glean the client ID >>> from the request object itself without it being in either a >>> parameter or in another part of the request that’s easily accessed. >>> >>> It was only in the original FAPI revision of PAR that allowed the >>> request object's signature to substitute client authentication, in >>> the individual draft published to IETF that's not the case anymore - >>> hence if "only" a request object is passed - with no client >>> authentication (header, client_id in body, mtls) you fail the request. >>> >>> As far as requiring client_id, here's what my implementation does >>> >>> > When providing form-encoded parameters - client_id must be present >>> in the form. >>> > When providing signed/encrypted request object - client_id must be >>> present in the request object. >>> >>> I wouldn't mind always requiring client_id, and i'm not worried >>> about it not matching e.g. the authorization header because the >>> client authentication middleware in place already takes care of that. >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 10 Oct 2019 at 03:13, Justin Richer <jricher@mit.edu >>> <mailto:jricher@mit.edu>> wrote: >>> >>> So in doing an implementation of this, I ran into this problem >>> as well. Specifically, we need to know which client we’re >>> dealing with to fully validate the encrypted request object as >>> well as perform the authentication. Currently, things are a >>> little underspecified, and part of that comes from the history >>> of this document: in the previous FAPI spec, the (required) >>> signature of the request object acted as de-facto authentication >>> for the client. In PAR, we not only can’t rely on the request >>> itself being signed, we also require handling of client >>> authentication in its many forms. That means the client ID could >>> show up in any combination of: >>> >>> - Form parameter >>> - Authorization header >>> - Client assertion’s “iss" field >>> - Request object’s “client_id” (and “iss”) field >>> >>> If several of these are sent, they need to be consistent. And >>> whatever value comes out needs to be consistent with the >>> client’s authentication method. >>> >>> But because JAR allows you to send in a request that is only a >>> request object, it also seems like you could pass in just the >>> request object with no other parameters, if I’m reading this >>> right, which would imply that you could be expected to glean the >>> client ID from the request object itself without it being in >>> either a parameter or in another part of the request that’s >>> easily accessed. >>> >>> So herein lies the problem. In order to properly process the >>> request object, you need to know which client you’re dealing >>> with so you can validate the signing algs, keys, and all that. >>> For signed requests that’s simple enough — parse in one step, >>> then authenticate the client, then validate the signatures. But >>> for encrypted JWTs it’s less clear: some methods would use only >>> the server’s public key, but symmetric encryption >>> algorithm/encoding pairs would use the client secret as the >>> pairwise secret for the encryption. Which means that we need to >>> know which client sent the request before the decryption happens. >>> >>> Which in turn implies one of two things are true: >>> >>> - You can’t do a request object when it’s encrypted using a >>> symmetric algorithm >>> - You have to require the client ID from some other part of the >>> request, such as a form parameter, auth header, or client >>> assertion; the client_id in the request object cannot be counted >>> on as being sufficient >>> >>> In our current draft implementation of PAR, I’m turning off >>> support for symmetric encryption in this one code path. If we >>> can somehow count on being able to find a client_id every time, >>> then we can refactor our implementation to parse and handle all >>> the client stuff :before: handling the request object itself. In >>> other words, if I always have to send something that identifies >>> the client in addition to the request object, then I can count >>> on that. >>> >>> Thoughts? >>> >>> — Justin >>> >>>> On Sep 30, 2019, at 11:21 AM, Brian Campbell >>>> <bcampbell=40pingidentity.com@dmarc.ietf.org >>>> <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>> wrote: >>>> >>>> >>>> >>>> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki >>>> <aaron@parecki.com <mailto:aaron@parecki.com>> wrote: >>>> >>>> > Depending on client type and authentication method, the >>>> request might >>>> > also include the "client_id" parameter. >>>> >>>> I assume this is hinting at the difference between public >>>> clients >>>> sending only the "client_id" parameter and confidential clients >>>> sending only the HTTP Basic Authorization header which >>>> includes both >>>> the client ID and secret? It would probably be helpful to >>>> call out >>>> these two common examples if I am understanding this correctly, >>>> otherwise it seems pretty vague. >>>> >>>> >>>> What this is trying to convey is that because client >>>> authentication at this Pushed Authorization Request Endpoint >>>> happens the same way as at the token endpoint (and other >>>> endpoints called directly by the client) the client_id >>>> parameter will sometimes be present but not necessarily as some >>>> types of client auth use the client_id parameter (none, >>>> client_secret_post, tls_client_auth, >>>> self_signed_tls_client_auth) and some don't >>>> (client_secret_basic, client_secret_jwt, private_key_jwt). >>>> >>>> Although the draft does later say "The AS MUST validate the >>>> request the same way as at the authorization endpoint" which I >>>> think could reasonably be interpreted as requiring client_id. >>>> e.g., https://tools.ietf.org/html/rfc6749?#section-4..1.1 >>>> <https://tools.ietf.org/html/rfc6749?#section-4.1.1> & >>>> https://tools.ietf.org/html/rfc6749?#section-4.2.1 >>>> >>>> So perhaps the sentence in question should be removed and have >>>> client_id be a required parameter at the PAR endpoint. >>>> >>>> >>>> /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 >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf
- [OAUTH-WG] Fwd: New Version Notification for draf… Torsten Lodderstedt
- Re: [OAUTH-WG] Fwd: New Version Notification for … Janak Amarasena
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Janak Amarasena
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] Fwd: New Version Notification for … Aaron Parecki
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Aaron Parecki
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Dick Hardt
- Re: [OAUTH-WG] New Version Notification for draft… Dave Tonge
- Re: [OAUTH-WG] Fwd: New Version Notification for … Brian Campbell
- Re: [OAUTH-WG] Fwd: New Version Notification for … Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Dick Hardt
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Takahiko Kawasaki
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] New Version Notification for draft… Vladimir Dzhuvinov