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