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

Vladimir Dzhuvinov <vladimir@connect2id.com> Fri, 10 January 2020 21:29 UTC

Return-Path: <vladimir@connect2id.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 BFAE3120119 for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 13:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LFIZRU4uOBty for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 13:29:13 -0800 (PST)
Received: from p3plsmtpa12-08.prod.phx3.secureserver.net (p3plsmtpa12-08.prod.phx3.secureserver.net [68.178.252.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A0012008C for <oauth@ietf.org>; Fri, 10 Jan 2020 13:29:12 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id q1qAiTGrbfh6jq1qBicMV4; Fri, 10 Jan 2020 14:29:12 -0700
To: Filip Skokan <panva.ip@gmail.com>
Cc: oauth@ietf.org
References: <fc3805e5-e908-00db-a734-990721371ab2@connect2id.com> <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>
Date: Fri, 10 Jan 2020 23:29:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000404020203050107070909"
X-CMAE-Envelope: MS4wfCUhJxpOq8sSuUggV30OiNc60w0JhiLK1EmF4gj0KnFhVpXejL/8QuZRy5eWTKMqUYNFmMmLF7j6/ZpbMAt6zdTHE8zwLw/qtX6E4+yzr1Q3byU3qrda 0zeEx5WAj+H0j78DZO+3pzm3R0cp3bQEDxdeJdsUZVbMbi18r3rWE0+CXa102oulLByM9wjHYlwAEwndA7kZWg3LGvM0Fqrof8w=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-hizSYHRZLWNeLFYxW6eFNi4xrM>
Subject: Re: [OAUTH-WG] 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, 10 Jan 2020 21:29:15 -0000

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>om>:
>>
>> 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>om>:
>>>> 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.