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

[Vladimir Dzhuvinov <[e-mail]>]

+1

Thanks!

Vladimir

On 12/03/2020 17:31, Brian Campbell wrote:
> +1 (again) that `client_id` should be allowed/required as a query
> parameter outside the request object JWT or URI and that its value has
> to be the same as within the request object.
>
> On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     I agree with that too.
>
>     Joseph
>
>>     On 12 Mar 2020, at 14:18, Mike Jones
>>     <Michael.Jones=[e-mail]
>>     <mailto:Michael.Jones=[e-mail]>> wrote:
>>
>>     I agree that we should restore the client_id functionality. 
>>     Thanks for moving this forward!
>>      
>>                                                            -- Mike
>>      
>>     *From:* OAuth <[e-mail]
>>     <mailto:[e-mail]>> *On Behalf Of *Nat Sakimura
>>     *Sent:* Monday, February 24, 2020 6:18 PM
>>     *To:* John Bradley <[e-mail] <mailto:[e-mail]>>
>>     *Cc:* oauth <[e-mail] <mailto:[e-mail]>>
>>     *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured
>>     Authorization Request (JAR) vs OIDC request object
>>      
>>     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 <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>          
>>         ---------- Forwarded message ---------
>>         From: *John Bradley* <[e-mail]
>>         <mailto:[e-mail]>>
>>         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 <[e-mail] <mailto:[e-mail]>>
>>
>>          
>>
>>         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
>>         <[e-mail] <mailto:[e-mail]>> 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
>>             <[e-mail] <mailto:[e-mail]>> 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
>>             <[e-mail] <mailto:[e-mail]>> 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
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749%23section-3.2.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986096572&sdata=m6%2BaTTp1bBtLcoJ883HIFFg5OPqcqW9Mo%2B8ennoFgaM%3D&reserved=0>>
>>             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
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FlkOhwiDj_hCI55BQRdiR9R0JwgI&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=lkS8YioL8fTeiuLU%2F2MzebzCB%2FA%2FPPy%2Fl1Wi%2BLFKCFE%3D&reserved=0>
>>             > >>> 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
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2F-tUrNY1X9eI_tQGI8T-IGx4xHy8&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=QNpyHqv10Dfu9MQzkhVs%2By23ShloRw9GIbn8%2B6pvigo%3D&reserved=0> and
>>             >
>>             >>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FUke1nxRlgx62EJLevZgpWCz_UwY&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986116568&sdata=JTvXisbbmnXSpNRFJQkEKvO%2BkXiLdtEr%2FoH8obLtlo8%3D&reserved=0> and
>>             > >>> so on.
>>             > >>> 
>>             > >>> _______________________________________________
>>             > >>> OAuth mailing list
>>             > >>> [e-mail] <mailto:[e-mail]>
>>             > >>> https://www.ietf.org/mailman/listinfo/oauth
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986126557&sdata=I5KDQT%2BdT0lapMOr71odsiCRrZ7csVZMuaYnMzsWwhM%3D&reserved=0>
>>             > >> 
>>             > >> _______________________________________________
>>             > >> OAuth mailing list
>>             > >> [e-mail] <mailto:[e-mail]>
>>             > >> https://www.ietf.org/mailman/listinfo/oauth
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0>
>>             > > 
>>             > > _______________________________________________
>>             > > OAuth mailing list
>>             > > [e-mail] <mailto:[e-mail]>
>>             > > https://www.ietf.org/mailman/listinfo/oauth
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0>
>>             > 
>>
>>             > _______________________________________________
>>             > OAuth mailing list
>>             > [e-mail] <mailto:[e-mail]>
>>             > https://www.ietf.org/mailman/listinfo/oauth
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986146548&sdata=%2B1PGj7U2CLMlh6HWf8BuGIvqtcGkz0hLMJYlktmkLc4%3D&reserved=0>
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986156545&sdata=2lgFg7%2F%2BLZ%2FgoabHcpK1ggg1FgNaArMIUKojGxJ%2BdLk%3D&reserved=0>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>         <https://nam06.safelinks..protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=Ex9kDYE8r4E0Y2KxMdDpwtZVWdNrq1Uqm6eYFf1LcsI%3D&reserved=0>
>>
>>
>>      
>>     -- 
>>     Nat Sakimura (=nat)
>>     Chairman, OpenID Foundation
>>     http://nat.sakimura.org/
>>     <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=%2FEt7X7DH8psh0JPtSnZGyk6qtliZUySH4z9%2BbLAEeTs%3D&reserved=0>
>>     @_nat_en
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> /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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov