But that’s also the same for parameters in a signed (non-encrypted) request object.
— Justin > On Jan 17, 2020, at 11:29 AM, Jim Manico <j...@manicode.com> wrote: > > It’s actually worse. Parameters in a URL leak over bookmarks, browser > history, logs everywhere, referrer headers... > > One of the most primary rules of secure coding on the web is to never put > sensitive data in a URL for •any• verb, not just GET. > > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 > >> On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle >> <richanna=40amazon....@dmarc.ietf.org> wrote: >> >> >> +1 to Justin’s comments. From a security standpoint parameters in the query >> string are no different from those in JWT unprotected headers (or protected >> if they’re also in the request object). Although I‘d amend Justin’s >> suggestion to say that if a parameter is both inside the request object and >> outside and they do not match, reject the request as suspicious. >> >>> On Jan 17, 2020, at 5:45 AM, Justin Richer <jric...@mit.edu> 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: >>> >>> >>> 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 >>>> <mailto: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 >>>>> <mailto: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://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 >>>>>> <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 <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto: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
