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

Joseph Heenan <joseph@authlete.com> Fri, 17 January 2020 00:38 UTC

Return-Path: <joseph@authlete.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 BF1211200C7 for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 16:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.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 BeYTnYAW-DRp for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 16:38:09 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 B2DC3120059 for <oauth@ietf.org>; Thu, 16 Jan 2020 16:38:09 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id b22so9084147pls.12 for <oauth@ietf.org>; Thu, 16 Jan 2020 16:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HwfmOsoazhSxXl2uRKkTw2hQsvPP14ciWgH7ujJqrk4=; b=vQtGDo/kkO/LRHjlwfb9r6GbaZL1My0w9pRyNJPwnh2XeAcQYHh/3X4tEL34daidR3 teyqCGBktd31QQL3tUoZXnVEaSUuh8sdk0eR13ayw43CcwRGw+6GqAi65Q85pfn65bZi f2VxN8Z8f2ZdM1EulM0yufp8/4GcmgmGdOQ31UNmcXnqYLiWcugd1aiaKukNWsWYsIcH 4ay7WKre/zTnCskRpECgEfL/BwCaTg1IEJBN0RUcr68T3AW3brcccsRa67VYHJxhSaXY /qfPSpjOrmkSDOIRaMM1OQFLqQ/upOoQ9oHUXxyMSIE7g3DMQv7HQnm3MrcYsqXaSKi6 Q5/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HwfmOsoazhSxXl2uRKkTw2hQsvPP14ciWgH7ujJqrk4=; b=YitS067ohx7Tl6W5GJl/ER8PJUB9jy+pRr88uYiSlRHOxG7El2OoDsisCZ9DA7LBKV RpLmnpZTaTHyimfJX+K92JaGTJwg/TywZSPdIagMBB4UUCzi+Uf5slb/ZY41LeLMKqCA zPzYNESTKJfxKCLlfILOSJQxrOA4ySsXiF84+xO4vkiIzaUhzJVB94hztIDgGFIL0ddF 6wx6YrWT+4Uprip4z4T49Z7SSBaI1EdDgudrRadKN7ivalkl1c/IdaaqkoOg45tjAj9J M30oJYULoxAAKg/RH5AXA6EkJfTNRXzpXLEgo9ho12Jt27jrhDVug7DaBJf2s5vOz/lw apbw==
X-Gm-Message-State: APjAAAXFPa9u+cxs3h7cBnWGhsDtoxX7gudnmwlsKzLTc1La5hLHzhgI VP4YqwPrJcOo1X6txFtBOb9CjcSmmVo=
X-Google-Smtp-Source: APXvYqzwrZ9wq+PW0OqAvLqVCCcpUn6whhHV/EUo9eHoxm762C5fYmjrzZouL8is3LDHHK3KxKa4Ng==
X-Received: by 2002:a17:902:c693:: with SMTP id r19mr37067017plx.25.1579221488695; Thu, 16 Jan 2020 16:38:08 -0800 (PST)
Received: from [192.168.128.107] (ai126165179117.73.access-internet.ne.jp. [126.165.179.117]) by smtp.gmail.com with ESMTPSA id g11sm25850704pgd.26.2020.01.16.16.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 16:38:07 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Joseph Heenan <joseph@authlete.com>
In-Reply-To: <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
Date: Fri, 17 Jan 2020 09:38:01 +0900
Cc: oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com> <CAANoGhK0-n6V_RogvVZ=8J8AQCEUUVJQn4_7wSWYixeQM8aZsw@mail.gmail.com> <CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0@CH2PR00MB0843.namprd00.prod.outlook.com> <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> <CAHdPCmNHeUyDjrc32oQPZ5g3oars-XY3vq2p3qt2LzzkZMTw5w@mail.gmail.com> <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/viCl9WQSvheUqO9VhxAuidQZUeI>
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: Fri, 17 Jan 2020 00:38:13 -0000

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 <ve7jtb@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> 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
>> 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
> https://www.ietf.org/mailman/listinfo/oauth