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
