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

Justin Richer <jricher@mit.edu> Thu, 10 October 2019 01:12 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 32618120020 for <oauth@ietfa.amsl.com>; Wed, 9 Oct 2019 18:12:42 -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 W5D5TnaVVzkP for <oauth@ietfa.amsl.com>; Wed, 9 Oct 2019 18:12:40 -0700 (PDT)
Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 B699C120044 for <oauth@ietf.org>; Wed, 9 Oct 2019 18:12:39 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x9A1Cav7030103; Wed, 9 Oct 2019 21:12:36 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 9 Oct 2019 21:12:36 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 9 Oct 2019 21:12:36 -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; Wed, 9 Oct 2019 21:12:36 -0400
From: Justin Richer <jricher@mit.edu>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
CC: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
Thread-Index: AQHVfwfNzZ3+8oU6oUeuCpMp7hKgZQ==
Date: Thu, 10 Oct 2019 01:12:36 +0000
Message-ID: <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@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>
In-Reply-To: <CA+k3eCRatdXp=iMidbRMVxJWVADweykiNnFixH7povuoQzWSVQ@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_53D85F8532034E368A8EB0FC9AB3D1AEmitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2s7aUlxjdTxuQXHT7jJrIkQ4gNI>
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 01:12:42 -0000

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