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

Filip Skokan <panva.ip@gmail.com> Thu, 10 October 2019 07:07 UTC

Return-Path: <panva.ip@gmail.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 8892E12004D for <oauth@ietfa.amsl.com>; Thu, 10 Oct 2019 00:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rsd7Zy6mLpEx for <oauth@ietfa.amsl.com>; Thu, 10 Oct 2019 00:07:19 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D782120033 for <oauth@ietf.org>; Thu, 10 Oct 2019 00:07:19 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id x3so4026454oig.2 for <oauth@ietf.org>; Thu, 10 Oct 2019 00:07:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CCSHvmEl97ZZqXLcOi5Io1E0tRHRIiyUg1S6Ex6ZzEk=; b=K1C22S+QJWua3jIsD7k1NNMiP9+PNptSNqfLG5k8p6EvUrNrv68CNtXnFuvou/ZXUa PdS2GtRJ0dAq540RbxrElTPKd9mCWklpgVRlu0GIpJOVJ48CJzbjhSz209QVGhEUBSjz lhjFMjru3XQ0R8uM1Pmf7pIhl38QX1BGZuH9gFNZsh0bqhER9F16PSoZ7e69nq7jNcM6 1yAwnXkzfz4zbZbWt3wHZz2iml4sNRwbgMV368JKmGD7YRy5ljOVeVxtEvNYJwZfCFMx D07l47k7DXMHOxElTzMIQMeb8KSw7PGpDKcMBtls4yolBhUFMskzHE6j8ENb7HV8OLUa Lzng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CCSHvmEl97ZZqXLcOi5Io1E0tRHRIiyUg1S6Ex6ZzEk=; b=pXn9EAE6P8O0ZN/BiFbnWkmfKv2NVoAxY/MFahd6ZMss0Fu1I3XgILc8AGnD5IXk2h sT9FP4dIyID6RBKPkNA6empXx9QeIHmio2zRRAqFBv9FLJw+ogCUVgz0KyIq9gyAGSLA hvZy6Nekd3P+1z3xLQJJniC0/uOGUq/vDzsgmAVEFUu03TLzx0X4NWzPCW7LPcIWEGeq uYVd4a2RudjBtyeEFRDX38jJSuqH5IkjEBw1t32EEEXw9ZlM1b0N7F6QslYkh5KTmk6m M1YWEAfCiYrAfD9SqEanLDuiNYL9PfBoeN+4gZzmMRIfMSHRuMe2ZasBykC2ymiqO4w7 SkgQ==
X-Gm-Message-State: APjAAAXbCduG6L6dqBmLSiL46BMngcRyYP5/cAde/PXFMqQ3Z3VQg6Cz GiiMKmwabNYm1zGnId09uptPAhzojXtFdTp5YA==
X-Google-Smtp-Source: APXvYqyzJT7qChBSvyMwo40AS8UX0idjyrNA0QnAEAsSxd3M6CceRwb10IB/+mSf/Z+2tifq2rNypGLJ35ynl3+/t8I=
X-Received: by 2002:aca:5ed4:: with SMTP id s203mr6028388oib.149.1570691238447; Thu, 10 Oct 2019 00:07:18 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu>
From: Filip Skokan <panva.ip@gmail.com>
Date: Thu, 10 Oct 2019 09:07:00 +0200
Message-ID: <CALAqi_8iCCYC4wm8rsH2EutiDmCWny4PB1-SNrrvM+Bi9o3Z3A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051cfc70594890da0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vGhvFsvRC8IfcipUWyhp7swmZuA>
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 07:07:22 -0000

> 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>; 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>; wrote:
>
>
>
> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki <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
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>