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
