Re: [OAUTH-WG] Security BCP Review

Daniel Fett <mail@danielfett.de> Mon, 11 April 2022 15:14 UTC

Return-Path: <mail@danielfett.de>
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 715E23A0DA2 for <oauth@ietfa.amsl.com>; Mon, 11 Apr 2022 08:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielfett.de
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 nuGJDpCNvroo for <oauth@ietfa.amsl.com>; Mon, 11 Apr 2022 08:13:59 -0700 (PDT)
Received: from mout-y-111.mailbox.org (mout-y-111.mailbox.org [91.198.250.236]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FD23A0D9B for <oauth@ietf.org>; Mon, 11 Apr 2022 08:13:58 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:105:465:1:3:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-y-111.mailbox.org (Postfix) with ESMTPS id 4KcXSL3zxfz9sRV; Mon, 11 Apr 2022 17:13:54 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------kaz9giq806v2jzpTHVjsweZs"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=MBO0001; t=1649690032; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q35lH1eX2cUUyBhxqzvP6hAR0gz7idoOnuXnuHnIUbM=; b=LKtdGKLPRsDuE89zF2QDKzf8Aip8qC8xtfTP0w7hQ55SLKcYAIhoZqHSF6/MGc6heKxCjA F8oQfmswr0ZWC9Jmeo0+77F9SiL0qw5NmkQ4ao9Mt+UEZM6uStq1TlHYLFwPTmhrqAwxA0 cW0edaWNCRG+S8bi4/K3P5DhtZgYc+2pQb/2x+EG2nY+e0o2Qimuisa1Nb7lKuqJ1gxIbA /Q5tAE5+1Y4fzGD0ZyOGjTABgVRLf3npp2G5tp5h15vBcnn35i9t9BdnjcldKRL4UsshSs qxKHpsQCF1umK/nn0lBk5k3dD833kvNloAincbmYNQtbpinbawbRTAxMqW2aYA==
Message-ID: <b682b029-1735-70a9-20cb-c0f688a4032b@danielfett.de>
Date: Mon, 11 Apr 2022 17:13:46 +0200
MIME-Version: 1.0
Content-Language: de-DE
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, oauth <oauth@ietf.org>
References: <CADNypP-4tzcRxj6MUjQ_XPASXyvKt8nKOXUaqG2j87rt2VS03A@mail.gmail.com>
From: Daniel Fett <mail@danielfett.de>
In-Reply-To: <CADNypP-4tzcRxj6MUjQ_XPASXyvKt8nKOXUaqG2j87rt2VS03A@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/O12kLVRDdpdLsFsejcyYsbhV5dQ>
Subject: Re: [OAUTH-WG] Security BCP Review
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: Mon, 11 Apr 2022 15:16:30 -0000

Hi Rifaat,

Am 14.02.22 um 22:26 schrieb Rifaat Shekh-Yusef:
>
> As part of the preparation for the shepherd write-up, I reviewed the 
> document and have the following comments:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html 
> <https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html>
>
>
>
> General comment
>
> The document refers to a number of drafts that are not active anymore, 
> e.g., token binding, pop key distribution, signing http requests, etc.
>
> What is the reason behind including these in this document?
>
The reason is to provide a general idea of other approaches that have 
been conceived and to discuss various approaches to specific problems. 
It may be helpful to the reader to see that sometimes, a certain 
solution has been discussed already, even when it was not pursued further.

>
> Section 4.5.4
>
> I am not clear on how the attacker can do that. Let’s take the 
> code_challenge example. Wouldn’t the AS be able to detect this attack 
> because it gets the *code verifier* associated with the *original code 
> challenge* from the Client?
>
Yes, but this can be circumvented if the attacker can modify the 
authorization request from the client to the AS before it reaches the 
AS. In this case, the attacker can define the code_challenge in the 
request such that it works with the code_verifier that will be sent 
later on.
>
>
> Nits
>
> Section 2.1, 3rd paragraph, 3rd sentence: “MAY rely the” to “, MAY 
> rely on the”
>
> Section 2.3, second paragraph: replace ietf-oauth-resource-indicators 
> with RFC8707
>
> Section 4.1.3. Last paragraph: replace the jwsreq and PAR draft 
> references with rfc9101 and rfc9126 respectively.
>
>
> Who might want to sweep through the document and update the various 
> references, as there seem to be too many old references
>
Thanks, we will fix this for the next revision and update the references.

-Daniel