Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

Filip Skokan <panva.ip@gmail.com> Thu, 12 March 2020 15:26 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 1F3643A07AA for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 08:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 eHYYWpXN3Dvj for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 08:26:30 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 610273A078A for <oauth@ietf.org>; Thu, 12 Mar 2020 08:26:30 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id d8so6851725qka.2 for <oauth@ietf.org>; Thu, 12 Mar 2020 08:26:30 -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=du6y8kmPahonB2VYqmcUMAsB06U6X78rvuzS1RRiwmc=; b=Bydi5qOS5fcODx1tRcIiutTbV5i3+I/o/1aEmL9OqNnSvwQHTJWUYNHzewNpBIMBXJ qOTFH7NtSO30iQo6BrrzWCSqG/X/aKNGW99Zq9tz78nVFanmjTiDzTLzXu76LEZ9Z3Wc FWyEhrBb5bN9jtNwbJ15ZA8JisXtil9pzgGvK/zx7Jsye7Zd0Byo7HsWyhTcOvq7O+8M UBaP9IZ/xOoBzvyRXz12JzEgkdSUmQL2v5OZZbnwvr7k1r0FVJAN8Tjn/ClusqiYoXzY Eu+aY2P6glZkeMwbCK+19mmj1ANZEEgatWhn6ABT1T79OlWnnkICBofUEeGqZEXkOCf7 p6nQ==
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=du6y8kmPahonB2VYqmcUMAsB06U6X78rvuzS1RRiwmc=; b=rhxUxEnaCHYD9un6JwSDSO1wX61/l6EQqVvHWptRQwAjodUIwJ6nXgq9RvfGPuLb1M rZcorXZrXQjhJOwHL9miScghNefWy4VvVq1hs4odjPQlMBFA/qhAqAEdsa5Uujbh2wqe CTEl+2iIO/i99eUkcpmmXi66VNDUOmTGA1/ugtBHb8uutEwgt+23KFB9HXqG5ZkEJLht Xqsa/ODaX/8HTATr0ALWZOdDaWr98xnDN+EJeWrB9a6Qn/jTRBEkDA79XS9BWWGqf0q/ 4NQzceGtx29SVN4ren2Rb7NlhuyqKaQknkC4gv/MIEP+qFlh11Ouu6X278w+RB04w4Wg 3n2Q==
X-Gm-Message-State: ANhLgQ230RpWzCawKYIzGeEe/7uNB8aFJAmt0QJpAe69M3esEKyx8WbL I/WZrBHZASqPZ/fztc+PloOEga6BKNotQp1dkw==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtLRBO9iuYY61+Nfw1ry3+MfCt04yBuE+4t1bAB?= =?utf-8?q?GolSVSSxjfcx9O5GlPMevGJ6bx6/cwQfgNvZm2JeQNM3Rsg=3D?=
X-Received: by 2002:a25:a041:: with SMTP id x59mr9215338ybh.259.1584026789254; Thu, 12 Mar 2020 08:26:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> <CAHdPCmNHeUyDjrc32oQPZ5g3oars-XY3vq2p3qt2LzzkZMTw5w@mail.gmail.com> <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com> <D6837D1F-01B6-4B46-8DF7-41969BE96112@mit.edu> <20200118025320.GV80030@kduck.mit.edu> <CAANoGhKtgqob_7AmFJ-OfROSx7QopehFdKAx8qmR8rUdzLNWPA@mail.gmail.com> <CAANoGhJgz6QC8rTwXH4Fik9bRydFDuAJB3Kpvoj3j1MCX2CZOw@mail.gmail.com> <CABzCy2B1ApKF6qKRNbaYiaR8sJEDiOkgjMxZV4vVmyfQ4xVYag@mail.gmail.com>
In-Reply-To: <CABzCy2B1ApKF6qKRNbaYiaR8sJEDiOkgjMxZV4vVmyfQ4xVYag@mail.gmail.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Thu, 12 Mar 2020 16:25:53 +0100
Message-ID: <CALAqi_9psoycwD9=+NPWzNTOgB4E1iOSyN+u0HbO4Dsb-z2fRQ@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000169b3605a0a9fae0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0c9C676u9fVcpxQLJPDHeiDNa4Y>
Subject: Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
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, 12 Mar 2020 15:26:33 -0000

Yes, that sounds good to me.

Best,
Filip


On Tue, 25 Feb 2020 at 03:18, Nat Sakimura <sakimura@gmail.com> wrote:

> So, where should we take it to?
> Just add back client_id as it used to be?
>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>>
>> ---------- Forwarded message ---------
>> From: John Bradley <ve7jtb@ve7jtb.com>
>> Date: Sat, Jan 18, 2020, 9:31 PM
>> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request
>> (JAR) vs OIDC request object
>> To: Benjamin Kaduk <kaduk@mit.edu>
>>
>>
>> If you put the iss in the JWE header it is integrity protected, as JWE
>> only supports AAD encryption algs.
>>
>> It is more of a problem when the client is sending a requestURI in that
>> case having the clientID in the GET to the Authorization endpoint is useful.
>>
>> I think there is a argument for explicitly allowing the clientID as long
>> as it exactly matches the clientID in the JAR.
>>
>> John B.
>>
>> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>>
>>> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
>>> > I don’t agree with this stance from a security or implementation
>>> perspective.
>>> >
>>> > If there’s a clear order of precedence for the information, it’s not
>>> particularly problematic. Everything inside the request object is to be
>>> taken over things outside the request object. We have the exact same
>>> semantics and process with dynamic registration, where the software
>>> statement is carried alongside plain JSON claims, and the two are mixed
>>> with a very simple algorithm:
>>> >
>>> >  - If a field is inside the signed payload, use that value and ignore
>>> any copy of it on the outside
>>> >  - If a field is not inside the signed payload and is outside the
>>> signed payload, use the outside value
>>> >
>>> > Can someone please point out a concrete security issue with this
>>> algorithm? This is the extent of the “merge” semantics that we need here,
>>> and it would solve not only the ability to use this for use cases that call
>>> for a more static request object (perhaps signed by a third party and not
>>> the client) along side the plain parameters that can vary, but also the
>>> backwards compatibility issue that’s been discussed. With this algorithm in
>>> place, you could have OIDC clients actually be compliant with the spec,
>>> since OIDC requires replication of the values inside the request object on
>>> the outside with exact matches. An OIDC server wouldn’t be fully compliant
>>> with the new spec since it would reject some compliant JAR requests that
>>> are missing the external parameters, but that’s fairly easy logic to add on
>>> the OIDC side. And in that case you get a matrix of compatibility like:
>>>
>>> I agree that the merge algorithm is simple and fairly straightforward to
>>> implement.  But, as Joseph has been alluding, it's only simple if you've
>>> already made the decision to use all the parameters, both from inside and
>>> from outside the signed payload.  The security risk lies about having to
>>> make the trust decision twice, more than the mundane details of actually
>>> doing the merge.  (Though there is still some latent risk, given that
>>> we've
>>> seen some really crazy quality of implementation out there.)
>>>
>>> It's certainly *possible* that things end up fine in many well-deliniated
>>> cases where merging can be used.  But it's more complicated to reason
>>> about, and I don't remmber seeing much previous discussion about the
>>> specifics of the double trust decision.
>>>
>>> -Ben
>>>
>>> >
>>> >               JAR Server | OIDC Server  |
>>> > ------------+------------+--------------+
>>> > JAR Client  |     YES    |      NO      |
>>> > OIDC Client |     YES    |     YES      |
>>> >
>>> > Breaking one out of the four possible combinations in a very
>>> predictable way is, I think, the best way to handle backwards compatibility
>>> here.
>>> >
>>> > But between this issue and JAR’s problematic call for the value of a
>>> request_uri to always be a JWT and be fetchable by the AS (neither of which
>>> are true in the case of PAR) makes me think we need to pull this back and
>>> rework those things, in a push back to the IESG’s comments.
>>> >
>>> >  — Justin
>>> >
>>> >
>>> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.com>
>>> wrote:
>>> > >
>>> > > I agree with this, particularly the security concerns of merging. If
>>> we merge, we can much guarantee there will eventually be a security issue
>>> where an attacker is able to gain an advantage by adding a parameter to the
>>> url query (which the server would then happily process if that parameter
>>> isn’t found inside the request object). Ruling out that case makes security
>>> analysis (particularly when creating new OAuth2 parameters) significantly
>>> simpler.
>>> > >
>>> > > Putting the iss in the JWE header and having the client_id
>>> duplicated outside the request object seem to address all the concerns I’ve
>>> seen raised.
>>> > >
>>> > > (It seems like it may be unnecessary to have the client_id
>>> duplicated outside if the request_uri is a PAR one though.)
>>> > >
>>> > > Joseph
>>> > >
>>> > >
>>> > >
>>> > >> On 16 Jan 2020, at 22:40, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> > >>
>>> > >> I agree with the IESG reasoning that merging is problimatic.  Once
>>> we
>>> > >> allow that given a unknown list of possible paramaters with diffrent
>>> > >> security properties it would be quite difficult to specify safely.
>>> > >>
>>> > >> Query paramaters can still be sent outside the JAR, but if they are
>>> in
>>> > >> the OAuth registry the AS MUST ignore them.
>>> > >>
>>> > >> Puting the iss in the JWE headder addresses the encryption issue
>>> without
>>> > >> merging.
>>> > >>
>>> > >> I understand that some existing servers have dependencys on getting
>>> the
>>> > >> clientID as a query paramater.
>>> > >>
>>> > >> Is that the only paramater that people have a issue with as oposed
>>> to a
>>> > >> nice to have?
>>> > >>
>>> > >> Would allowing the AS to not ignore the clientID as a query
>>> paramater as
>>> > >> long as it matches the one inside the JAR, basicly the same as
>>> Connect
>>> > >> request object but for just the one paramater make life easier for
>>> the
>>> > >> servers?
>>> > >>
>>> > >> I am not promising a change but gathering info before proposing
>>> something.
>>> > >>
>>> > >> John B.
>>> > >>
>>> > >>
>>> > >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>>> > >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>> > >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>> > >>>>> Well, embedding a client_id claim in the JWE header in order to
>>> > >>>>> achieve "request parameters outside the request object should
>>> not be
>>> > >>>>> referred to" is like "putting the cart before the horse". Why do
>>> we
>>> > >>>>> have to avoid using the traditional client_id request parameter
>>> so
>>> > >>>>> stubbornly?
>>> > >>>>>
>>> > >>>>> The last paragraph of Section 3.2.1
>>> > >>>>> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749
>>> says
>>> > >>>>> as follows.
>>> > >>>>>
>>> > >>>>>   /A client MAY use the "client_id" request parameter to identify
>>> > >>>>>   itself when sending requests to the token endpoint.  In the
>>> > >>>>>   "authorization_code" "grant_type" request to the token
>>> endpoint,
>>> > >>>>>   *an unauthenticated client MUST send its "client_id" to prevent
>>> > >>>>>   itself from inadvertently accepting a code intended for a
>>> client
>>> > >>>>>   with a different "client_id".*  This protects the client from
>>> > >>>>>   substitution of the authentication code.  (It provides no
>>> > >>>>>   additional security for the protected resource.)/
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> If the same reasoning applies, a client_id must always be sent
>>> with
>>> > >>>>> request / request_uri because client authentication is not
>>> performed
>>> > >>>>> at the authorization endpoint. In other words, */an
>>> unauthenticated
>>> > >>>>> client (every client is unauthenticated at the authorization
>>> endpoint)
>>> > >>>>> MUST send its "client_id" to prevent itself from inadvertently
>>> > >>>>> accepting a request object for a client with a different
>>> "client_id"./*
>>> > >>>>>
>>> > >>>> Identifying the client in JAR request_uri requests can be really
>>> useful
>>> > >>>> so that an AS which requires request_uri registration to prevent
>>> DDoS
>>> > >>>> attacks and other checks can do those without having to index all
>>> > >>>> request_uris individually. I mentioned this before.
>>> > >>>>
>>> > >>>> I really wonder what the reasoning of the IESG reviewers was to
>>> insist
>>> > >>>> on no params outside the JAR JWT / request_uri.
>>> > >>>>
>>> > >>>> I'm beginning to realise this step of the review process isn't
>>> > >>>> particularly transparent to WG members.
>>> > >>> Could you expand on that a bit more?  My understanding is that the
>>> IESG
>>> > >>> ballot mail gets copied to the WG precisely so that there is
>>> transparency,
>>> > >>> e.g., the thread starting at
>>> > >>>
>>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
>>> > >>> Which admittely is from almost three years ago, but that's the
>>> earliest
>>> > >>> that I found that could be seen as the source of this behavior.
>>> > >>>
>>> > >>> -Ben
>>> > >>>
>>> > >>> P.S. some other discussion at
>>> > >>>
>>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8
>>> and
>>> > >>>
>>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY
>>> and
>>> > >>> so on.
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> 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
>>> > >
>>> > > _______________________________________________
>>> > > 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
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>