Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

Justin Richer <jricher@mit.edu> Thu, 10 October 2019 17:00 UTC

Return-Path: <jricher@mit.edu>
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 A812012006E for <oauth@ietfa.amsl.com>; Thu, 10 Oct 2019 10:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QsAFQ7AeiC39 for <oauth@ietfa.amsl.com>; Thu, 10 Oct 2019 10:00:01 -0700 (PDT)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 63B0D1200CC for <oauth@ietf.org>; Thu, 10 Oct 2019 10:00:01 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x9AGxp4L001593; Thu, 10 Oct 2019 12:59:57 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 10 Oct 2019 12:59:27 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 Oct 2019 12:59:31 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 10 Oct 2019 12:59:31 -0400
From: Justin Richer <jricher@mit.edu>
To: Filip Skokan <panva.ip@gmail.com>
CC: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
Thread-Index: AQHVfwfNa3xPxCQlOEmJVjaFyUAiTKdTt50AgACliwA=
Date: Thu, 10 Oct 2019 16:59:30 +0000
Message-ID: <CDEA2590-FD94-4D84-9252-D22610461F35@mit.edu>
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>
In-Reply-To: <CALAqi_8iCCYC4wm8rsH2EutiDmCWny4PB1-SNrrvM+Bi9o3Z3A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_CDEA2590FD944D849252D22610461F35mitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_UV7OdAUx8ZungQfd2BU9LC1svo>
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: Thu, 10 Oct 2019 17:00:05 -0000

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