It is not too late to add to the security considerations. It seems that the new application/oauth.authz.req+jwt media-type is helpful in this regard, in that if an AS can require that content-type from dereferencing the request_uri, then seeing anything else indicates that the request was bogus (or an attack). I guess existing OIDC deployments aren't exactly in a position to do that, though.
-Ben On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote: > Is it too late to add it to the security considerations for JAR? > > — Neil > > > On 16 Jan 2020, at 08:15, Dominick Baier <dba...@leastprivilege.com> wrote: > > > > > > Agreed - that’s why we disabled request_uri by default and added > > extensibility points to implement validation. > > > > I thought it is odd that this was not mentioned in the typical “security > > considerations” in the OIDC spec.. > > > > ——— > > Dominick Baier > > > >> On 16. January 2020 at 08:07:44, Neil Madden (neil.mad...@forgerock.com) > >> wrote: > >> > >> If the AS can’t validate the request_uri it may also open itself up to > >> SSRF attacks where a malicious client uses the request_uri to probe/attack > >> resources inside the AS’s private network. This was a crucial part of the > >> recent Capital One breach for example [1]. ForgeRock currently requires > >> strict validation of request_uris against a client-specific whitelist for > >> exactly this reason. > >> > >> NB some clients might legitimately be on that private network (eg > >> microservices) so changing to a global whitelist for all clients is > >> undesirable. > >> > >> [1]: https://ejj.io/blog/capital-one > >> > >> — Neil > >> > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <vladi...@connect2id.com> > >>> 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 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. > >>> > >>> Vladimir > >>> > >>> > >>> > >>>> Best Regards, > >>>> Taka > >>>> > >>>> > >>>> > >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov > >>>> <vladi...@connect2id.com> wrote: > >>>>> John, thanks, much appreciated! > >>>>> > >>>>>> On 11/01/2020 21:36, John Bradley wrote: > >>>>>> Yes JAR is not prohibiting paramater replication in the header. > >>>>>> > >>>>>> I will see if i can add something in final edits to call that out. > >>>>>> > >>>>>> John B. > >>>>>> > >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote: > >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter > >>>>>>> replication be used for client_id or the client_id ass "iss" even > >>>>>>> though it isn't explicitly mentioned in the JAR spec? > >>>>>>> > >>>>>>>> On 11/01/2020 02:58, John Bradley wrote: > >>>>>>>> Right we just don't say to put the iss there in OIDC if it's > >>>>>>>> symetricly encrypted. > >>>>>>> OIDC doesn't have the symmetric key selection issue, I suppose that > >>>>>>> why the possibility to replicate params to the JWE header isn't > >>>>>>> mentioned at all. OIDC requires the top-level query params to > >>>>>>> represent a valid OAuth 2.0 request, and there client_id is required. > >>>>>>> If the client_id is present the client registration together with any > >>>>>>> present client_secret can be retrieved. > >>>>>>> > >>>>>>> I reread the JAR spec, this is the only place that mentions handling > >>>>>>> of symmetric JWE. > >>>>>>> > >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2 > >>>>>>> > >>>>>>>> (b) Verifying that the symmetric key for the JWE encryption is the > >>>>>>>> correct one if the JWE is using symmetric encryption. > >>>>>>> > >>>>>>> Vladimir > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones > >>>>>>>> <michael.jo...@microsoft.com> wrote: > >>>>>>>>> The technique of replicating JWT claims that need to be publicly > >>>>>>>>> visible in an encrypted JWT in the header is defined at > >>>>>>>>> https://tools.ietf.org/html/rfc7519#section-5.3. (Thanks to Dick > >>>>>>>>> Hardt for bringing this need to my attention as we were finishing > >>>>>>>>> the JWT spec.) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- Mike > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: OAuth <oauth-boun...@ietf.org> On Behalf Of John Bradley > >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM > >>>>>>>>> To: Vladimir Dzhuvinov <vladi...@connect2id.com> > >>>>>>>>> Cc: IETF oauth WG <oauth@ietf.org> > >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization > >>>>>>>>> Request (JAR) vs OIDC request object > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The intent was to do that, but specs change once the OAuth WG and > >>>>>>>>> IESG get there hands on them. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Being backwards compatible with OIDC is not a compelling argument > >>>>>>>>> to the IESG. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> We were mostly thinking of asymmetric encryption. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Specifying puting the issuer and or the audience in the headder has > >>>>>>>>> come up in the past but probably is not documented. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> John B > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov > >>>>>>>>> <vladi...@connect2id.com> wrote: > >>>>>>>>> > >>>>>>>>> Yes, putting the client_id into the JWE header is a way around the > >>>>>>>>> need > >>>>>>>>> to have the client_id outside the JWE as top-level authZ request > >>>>>>>>> parameter. > >>>>>>>>> > >>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I just > >>>>>>>>> checked > >>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20. > >>>>>>>>> > >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies on the > >>>>>>>>> presence of client_id as top-level parameter, together with > >>>>>>>>> requiring > >>>>>>>>> RPs to register their request_uri's (so that we don't need to build > >>>>>>>>> and > >>>>>>>>> store an index of all request_uri's). I just had a look at "DDoS > >>>>>>>>> Attack > >>>>>>>>> on the Authorization Server" and also realised the request_uri > >>>>>>>>> registration isn't explicitly mentioned as attack prevention ("the > >>>>>>>>> server should (a) check that the value of "request_uri" parameter > >>>>>>>>> does > >>>>>>>>> not point to an unexpected location"). > >>>>>>>>> > >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1 > >>>>>>>>> > >>>>>>>>> To be honest, I feel quite bad about the situation with JAR we are > >>>>>>>>> in > >>>>>>>>> now. For some reason I had the impression that OAuth JAR was going > >>>>>>>>> to be > >>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as with > >>>>>>>>> other > >>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs. > >>>>>>>>> > >>>>>>>>> I find it unfortunate I didn't notice this when I was reviewing the > >>>>>>>>> spec > >>>>>>>>> in the past. > >>>>>>>>> > >>>>>>>>> Vladimir > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote: > >>>>>>>>> > Vladimir, > >>>>>>>>> > > >>>>>>>>> > For that very case the payload claims may be repeated in the JWE > >>>>>>>>> > protected header. An implementation wanting to handle this may > >>>>>>>>> > look for iss/client_id there. > >>>>>>>>> > > >>>>>>>>> > Odesláno z iPhonu > >>>>>>>>> > > >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov > >>>>>>>>> >> <vladi...@connect2id.com>: > >>>>>>>>> >> > >>>>>>>>> >> I just realised there is one class of JARs where it's practially > >>>>>>>>> >> impossible to process the request if merge isn't supported: > >>>>>>>>> >> > >>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC > >>>>>>>>> >> allows > >>>>>>>>> >> for that and specs a method for deriving the shared key from the > >>>>>>>>> >> client_secret: > >>>>>>>>> >> > >>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption > >>>>>>>>> >> > >>>>>>>>> >> If the JAR is encrypted with the client_secret, and there is no > >>>>>>>>> >> top-level client_id parameter, there's no good way for the OP to > >>>>>>>>> >> find > >>>>>>>>> >> out which client_secret to get to try to decrypt the JWE. Unless > >>>>>>>>> >> the OP > >>>>>>>>> >> keeps an index of all issued client_secret's. > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> OP servers which require request_uri registration > >>>>>>>>> >> (require_request_uri_registration=true) and don't want to index > >>>>>>>>> >> all > >>>>>>>>> >> registered request_uri's, also have no good way to process a > >>>>>>>>> >> request_uri > >>>>>>>>> >> if the client_id isn't present as top-level parameter. > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> Vladimir > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote: > >>>>>>>>> >>> > >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley > >>>>>>>>> >>>>> <ve7...@ve7jtb.com>: > >>>>>>>>> >>>> I think Torsten is speculating that is not a feature people > >>>>>>>>> >>>> use. > >>>>>>>>> >>> I’m still trying to understand the use case for merging signed > >>>>>>>>> >>> and unsigned parameters. Nat once explained a use case, where a > >>>>>>>>> >>> client uses parameters signed by a 3rd party (some > >>>>>>>>> >>> „certification authority“) in combination with > >>>>>>>>> >>> transaction-specific parameters. Is this being done in the wild? > >>>>>>>>> >>> > >>>>>>>>> >>> PS: PAR would work with both modes. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> OAuth mailing list > >>>>>>>>> OAuth@ietf.org > >>>>>>>>> https:// > >>>>>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>> -- > >>> Vladimir Dzhuvinov > >>> _______________________________________________ > >>> 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
