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

[George Fletcher <[e-mail]>]

I'm a +1 for adding client_id back as well

On 3/12/20 11:31 AM, 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]> wrote:
>
>> I agree with that too.
>>
>> Joseph
>>
>> On 12 Mar 2020, at 14:18, Mike Jones <
>> 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]> *On Behalf Of *Nat Sakimura
>> *Sent:* Monday, February 24, 2020 6:18 PM
>> *To:* John Bradley <[e-mail]>
>> *Cc:* oauth <[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]> wrote:
>>
>>
>> ---------- Forwarded message ---------
>> From: *John Bradley* <[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]>
>>
>>
>> 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]> 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]>
>> 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]> 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]
>>>>>> 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]
>>>>> 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]
>>>> 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]
>>> 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]
>> 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]
>> 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]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth