Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

Nat Sakimura <sakimura@gmail.com> Thu, 16 January 2020 15:48 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E19312098C for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 07:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa3ieWCkf28f for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 07:48:09 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B15120952 for <oauth@ietf.org>; Thu, 16 Jan 2020 07:48:01 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id w15so19686906wru.4 for <oauth@ietf.org>; Thu, 16 Jan 2020 07:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QfdyrAxj/arJ0W2BsnOanl5UR6TW19m474DoWh6fr/Q=; b=AUlGGOfTXlbjgJrLsLjK6PF8W+9h5Mu8zBapfGB3oaoLfCNZym2UFQ8CggeLmFQlGL zdgWdGzQPnkZoHdq+nlg3cKG2xJpYunLCsl+gjOM54pN19DoDNZU5W7bFSu+6Ouaqc4s DkLftWUa6ogwPGwUVgVdIEJf3JugELooE0x+pxZR+glvtdrG5mXtx4Fbf6Wwrm2nHH26 Swoxx7vFxGi2aTMXmErb6H3X6taWxxJjBckL1Z5c1QtztSDr4bUUsQs2mm9bqc1VSNCV mxSxQm0+Eq6t7PZyB39Pvs8j9wbr4INKjufftYJUzADwn526Jfl/rHOauahM/9jOi6Q6 t8tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QfdyrAxj/arJ0W2BsnOanl5UR6TW19m474DoWh6fr/Q=; b=q+moKz6OUFtSjYrdwDPe02vyVOUPjs195CxCUE3nYtlPvakQ6wqN8JBHAKn4BBIBDo 7aN7vNWw4cyGlZBHfIvija/Vaw43cShbtM4TuJXDHRsksS5sZWrIDHH2iDEzSisnDdWa bR6k5rFunMcXDgb1qClfUBVtC0JE4iEXP0S/YvVVlhKvZ7haRe7aW/8jCyR9VO5NhtiC oZOCIYi3hXCwHPblOvXNSKMCXxm8as5VvYN0Ti4Mj5Qxymng0YhdzNBPKn/XO3HQLbUl 0WA/Y7GD/YeAgPeelz5NQgRmLaaIIS7W1afozjSfZO/wSRoGI4E90sGUnDGJdq2nUOOV AXiQ==
X-Gm-Message-State: APjAAAV82mGB+Ti3LuxUug76qmiZ+AqCrnGhsxjEIwAEXu+L4Y6nqSe1 7Frk0qtDtCP/q7vS51zFZvL0ZcJvOw68bnYfyIw=
X-Google-Smtp-Source: APXvYqze6ebYLCtXuswTVZUgfHqgf1GS+XbHVRvU8ZhxkGyevKP2TeRtEAEqTUn0s3vEqU8Hcdf1e1rFiuZyrTOitC0=
X-Received: by 2002:adf:f98c:: with SMTP id f12mr3846291wrr.138.1579189679294; Thu, 16 Jan 2020 07:47:59 -0800 (PST)
MIME-Version: 1.0
References: <CAO7Ng+vZk2OCuc_JOp6Nwh=+GXrDnOop4KBhierFCvoBOOcw6Q@mail.gmail.com> <CCE34816-FBAF-4971-B75B-3F70769E56AE@forgerock.com> <20200116143233.GJ80030@kduck.mit.edu>
In-Reply-To: <20200116143233.GJ80030@kduck.mit.edu>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 17 Jan 2020 00:47:45 +0900
Message-ID: <CABzCy2C1Bi_ic8XoELCw=qpo_3UcuEb8opX9s_6QFMq3ZBkCTA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Neil Madden <neil.madden@forgerock.com>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000de0e18059c43bfb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gtsPBkDUVohvRaP34YBxQ9gckg8>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2020 15:48:18 -0000

Right. We could add a security consideration like that, though the
mitigation probably is pretty much the same as what is stated in 10.4.1:

the server should (a) check that
   the value of "request_uri" parameter does not point to an unexpected
   location, (b) check the content type of the response is "application/
   oauth.authz.req+jwt" (c) implement a time-out for obtaining the
   content of "request_uri", and (d) not perform recursive GET on the
   "request_uri".

If not, please let me know so that we can add that as the mitigation as
well.

Existing OIDC deployment cannot make use of application/oauth.authz.req+jwt
but it has to validate that content is a valid request object anyways and
if it is malformed, it MUST stop the processing and return an error
invalid_request_uri. So, unlike in the case of Capital One's SSRF, the
content of the request_uri will not be exposed. The main downside is
therefore as depicted in the current draft, consumption of the network and
processing power of the AS, and the unwanted access load to the servers
serving the URL pointed by request_uri. The above-quoted mitigations were
introduced to address these issues.




On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> 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 <dbaier@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.madden@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 <
> vladimir@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 <
> vladimir@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.Jones@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-bounces@ietf.org> On Behalf Of John Bradley
> > >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
> > >>>>>>>>> To: Vladimir Dzhuvinov <vladimir@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 <
> vladimir@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 <
> vladimir@connect2id.com>gt;:
> > >>>>>>>>> >>
> > >>>>>>>>> >> 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 <
> ve7jtb@ve7jtb.com>gt;:
> > >>>>>>>>> >>>> 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
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en