[OAUTH-WG] AD Review of draft-ietf-oauth-par-07

Roman Danyliw <rdd@cert.org> Fri, 14 May 2021 19:16 UTC

Return-Path: <rdd@cert.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CB18A3A34AD for <oauth@ietfa.amsl.com>; Fri, 14 May 2021 12:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aM7EqqGpuT43 for <oauth@ietfa.amsl.com>; Fri, 14 May 2021 12:16:51 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu []) (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 2B0BF3A3D18 for <oauth@ietf.org>; Fri, 14 May 2021 12:16:51 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu []) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 14EJGns1028719 for <oauth@ietf.org>; Fri, 14 May 2021 15:16:49 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 14EJGns1028719
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1621019809; bh=iWgUxZT9EdXfJjzeRidLO0bKki48CGPbCnKZcYgbiZE=; h=From:To:Subject:Date:From; b=EW0rUqlpIBdfaWFBU7n5Rhx6ULGKcCWwgedaGyfEqfI1XL3Hf7xDTHkdCo39h6M4a wEZeip3X7vKpZC+F2DqsIieZZmB0AJqVUJP+Zo34Om+XeY3bj88nzJB6Qo8Yhbvg0P LhWDS6r2/Iwja1aCZHZu5mgkpnhruA86QxgNcqMc=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu []) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 14EJGjsA031857 for <oauth@ietf.org>; Fri, 14 May 2021 15:16:45 -0400
Received: from MORRIS.ad.sei.cmu.edu ( by MORRIS.ad.sei.cmu.edu ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Fri, 14 May 2021 15:16:44 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2242.008; Fri, 14 May 2021 15:16:44 -0400
From: Roman Danyliw <rdd@cert.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: AD Review of draft-ietf-oauth-par-07
Thread-Index: AddI9WHKaUoe8zwOTFyNHeVjlpuPzw==
Date: Fri, 14 May 2021 19:16:43 +0000
Message-ID: <912d493e506e4f2c8e200b6cc71f3b88@cert.org>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0Cu3TM8TDhSsttDfVxfinrWBxqw>
Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-par-07
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, 14 May 2021 19:16:56 -0000


I performed my AD review of draft-ietf-oauth-par-07.  Thanks for the effort to produce this document.  See my feedback below:

** Section 1.1.  Per the first POST example, please provide a bit more text to explain the presence of the Authorization header.

** Section 2.1.  Per step #1, "Authenticate the client in the same way as at the token endpoint." Would it be appropriate to cite Section 2.3.1 of RFC6749 as the reference for "the same way"?

** Section 2.1. Typo.  s/the the/the/

** Section 2.2.  "The format of the "request_uri" value is at the discretion of the authorization server ...", it would be helpful to remind implementers (via reference) that the constraints of Section 10.10 of RFC6749 apply.

   The authorization server MUST prevent attackers from guessing access
   tokens, authorization codes, refresh tokens, resource owner
   passwords, and client credentials.

   The probability of an attacker guessing generated tokens (and other
   credentials not intended for handling by end-users) MUST be less than
   or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

** Section 2.2.  "The string representation of a UUID as a URN per [RFC4122] is also an option for authorization servers to construct "request_uri" values" suggests that a UUID could be used as the "cryptographically strong pseudorandom algorithm such that it is computationally infeasible to predict or guess a valid value" for the random part of the request_uri.  However, a few bits of the 128-bit UUID are in fact not random.  Hence, this UUID construct would seem to violate the guidance of Section 10.10 of RFC6749 noted above.  Likewise, the Section 10.2 of draft-ietf-oauth-jwsreq-34 referenced in Security Considerations also suggest 128-bits.

** Section 2.4.  This section relaxes exact matching of the redirect_uri specified in the current text of the security BCP and OAuth 2.1.  Not relevant to this document, but would it make sense to acknowledge this relaxation in the BCP or caveat language about strict requirements in the v2.1 draft?

** Section 6.  Typo. s/reqired/required/

** Section 7.5.  Per "Clients SHOULD make use of PKCE, a unique "state" parameter, or the OIDC "nonce" parameter" are good advice.  Can the text provide references to each of these.

** Section 8.  Wouldn't some of the privacy considerations of draft-ietf-oauth-jwsreq-34/Section 11 apply?