I agree with that too.
Joseph
On 12 Mar 2020, at 14:18, Mike Jones <
Michael.Jones=40microsoft....@dmarc.ietf.org> wrote:
I agree that we should restore the client_id functionality. Thanks for
moving this forward!
-- Mike
*From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Nat Sakimura
*Sent:* Monday, February 24, 2020 6:18 PM
*To:* John Bradley <ve7...@ve7jtb.com>
*Cc:* oauth <oauth@ietf.org>
*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 <ve7...@ve7jtb.com> wrote:
---------- Forwarded message ---------
From: *John Bradley* <ve7...@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 <ka...@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 <ka...@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 <jos...@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 <ve7...@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
<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
OAuth@ietf.org
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
OAuth@ietf.org
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
OAuth@ietf.org
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
OAuth@ietf.org
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
OAuth@ietf.org
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
OAuth@ietf.org
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
