From hannes.tschofenig@siemens.com Wed Oct 4 06:42:02 2023 Return-Path: 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 194C1C14F73E for ; Wed, 4 Oct 2023 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=siemens.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHTUh1nfVzgS for ; Wed, 4 Oct 2023 06:41:58 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on2051.outbound.protection.outlook.com [40.107.14.51]) (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 3C900C151992 for ; Wed, 4 Oct 2023 06:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xo6vy34ynTNoRsqkrZtHzuGu/Rp6xdc36IR0M8uII03u+mqdtwXArB1FYdtkakJB0i5zmlV8oYWSoc//hOi6Fv774qcHoukN2v42nLFvp+WRr8Ic0T/d4ZVyvLXTd54/OGxTL3OJwAM1uhnAROUXgy6JBqgTdH+SwItbteHMMwgt1kQprIyf1MxIQyNNHnxULNg5VxuqkFK99P/MdMVyYcuaveQI0BYO+R3InX33AEOh9I4CAaXQmyvLRwHB8UNBQvG+AyeAlk6nOsaNEuH4yPOcn89j5xHLtb+ctI4Kuc7xjP9zn6FW4rPQDrDBgBWJJd4umcNWpPXbKwG+1r6V2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UNEgvgLP+L3liOoXqDclwFmqWLrhlF8Jo7/4RYdiEjM=; b=Xh9W/Vx5OmqttsmkalGXMlaRenRAuz+zOqhYhMvThZeiG7chDDU7cffftCv5H2J4ADCj00DaPwdLbe6l9/3SMeZ3oSoNXMjkUiJ2qbr43A1x3qmEa7d4xuDiRu+HzKnJUMLfLd4gLigXsz6Px4wyNZgg42g1zdQoIwk0+DsQZqnDrsq0okHYR+h7DTbWlktWZAdiOz6LjLuoVfRJZiOmC7S8kFvpjZKLxpF/LXSxntrGBPLWrSXlPrrwy8XFc434Utlf/1YSZOREHLSFm1PtBev+MGec4LWFCo2QbS9yPN6x0shMI+P0TOuKmDhuFw+UwMaDtg65jk7Et5oP+KbMzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UNEgvgLP+L3liOoXqDclwFmqWLrhlF8Jo7/4RYdiEjM=; b=lXD3suDwi61XzCJMpkhXHGxvNhRmmMrbtxAZWl3bV7O5Sc/ix3WDLXhGEue7ownEcYK3QuQdpAQG4B4UthyBGrCs+X71xNubgQbIxjKJEPcvsorqH6obL6oddnP3b02/kOdWKVQf+46o8t9ck+MMNGgxwZpth2S/FloSPn6wco6QhA8piB8XtLf1sdRSqfJxocD1/1X5J6HLiARFunsEC6W+8x6Y6YNLh7Mj59Um4MVpHomTlkULvxR8SLTQqRzfLGKAIWNdDTsr8SKg1WDtknp6ksSI5E/9O9nUCPp0wg74gCSKihIyiupLwas2OV+0eXFkr2qXlf9hhSluXeEFjA== Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5ab::22) by DU0PR10MB5409.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:328::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.33; Wed, 4 Oct 2023 13:41:30 +0000 Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM ([fe80::1eff:e69e:8a93:2ca2]) by AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM ([fe80::1eff:e69e:8a93:2ca2%5]) with mapi id 15.20.6838.016; Wed, 4 Oct 2023 13:41:30 +0000 From: "Tschofenig, Hannes" To: "oauth@ietf.org" Thread-Topic: Shepherd Review of draft-ietf-oauth-security-topics-23 Thread-Index: Adn2yEff+T1F71CiTvyT1q4np/SeaQ== Date: Wed, 4 Oct 2023 13:41:30 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=468b0aa3-4cfd-47b5-b189-85812348fde9; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2023-10-04T13:39:47Z; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR10MB7427:EE_|DU0PR10MB5409:EE_ x-ms-office365-filtering-correlation-id: 9b7315d4-26fd-4a8b-57d7-08dbc4df9d80 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P6aTSa3AUnr+QDX+mceD8ZW6HKnph8NzfCtq0K++wMDGKiWo2vSC909+lJ9c5ZOmP7fCLOd7dlAkXIloDquodOzqLilR/uKPGLDsdkCMo15o/3altx4V/1DpAjmF5m0dhg9v/y1/eqPUKsji7h+WmxjEVVPRl/hVfBOz9da+jh2V8lJwQbHoEtJVLqKPyYcQy6Tto1L19nQLa7Al3q6t95nHBgyj5AUtZbtgSZBil17Iog1ALK/nbqFnXLk/AR7ZADwAiDfLt2zr/3P3CyB5pcIvambuI4iPtX2qrjyGkdRIFTgHaSy8ITk3edypOC8Pu7McebTgzG75pBFzml90ep5cRYlCYazNzL3wa0iGBZXfQxf6RUjafA9qC0mK/BZ+1kwE2WMPs6MC129pslQIV2iWhR3ql7gFkrXzus5chCr77mgnuIl94MVpmuHrHojgZLx2s45CBH6Y+ZOo0g1Rd6E5Z43SPj1pqscOavd7hUverk6ChTYg/rNQ+wYYM6Q5pO6orpToi5yRTTSOyfsmhxzkIXtjEvITkh0WQ0cqKTqRmz8bc4jKjq3yOXYE1zglRIoPK+9qbajzJqaDhexB7FEcJFlBHEbagUQyB6Muico= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(396003)(136003)(346002)(366004)(376002)(230922051799003)(451199024)(64100799003)(1800799009)(186009)(55016003)(6506007)(478600001)(7696005)(71200400001)(33656002)(966005)(38100700002)(86362001)(122000001)(82960400001)(166002)(38070700005)(15650500001)(2906002)(83380400001)(66574015)(6916009)(26005)(316002)(9686003)(8676002)(76116006)(5660300002)(66946007)(66476007)(66446008)(64756008)(41300700001)(52536014)(8936002)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QKx6Y/I9b5sKYXfvN/uVGT2neHb1lApU9p+3Jx60spLzrlIHR6l/Wt5CzgjT?= =?us-ascii?Q?xCC0CXHM7gC8arS3o+xvK1ayZ5/dns3SZrptwgJpIwup2Qlb4yyb+AMB+BuX?= =?us-ascii?Q?Jh37OXWL5U9N0o73VWiS1OCZJCdfcwCmr1frqfLTUo/T0O5yxWauGOAENNW7?= =?us-ascii?Q?TWhEvyM608ybvhnA5oT1+bOxaYZNyRf/aEIRRXERozDU5oLttNTuXrlEUthC?= =?us-ascii?Q?20FF3FDxBLVxhKPSEdCyFmjNfxWUHTvSlbldx/a12wmehdE+0vi6RRIdBbSx?= =?us-ascii?Q?/dzfSYPqhvOXMOjnpOe9u9656/SH64SJYaFBkvhy2D9n9hBAnRCW2c8YFIt4?= =?us-ascii?Q?n3qpcwVDmtDLHIc+h5ABJXGtBY7VucC8LDM0C7ybEk8w4HdZQANeGN7vPFrT?= =?us-ascii?Q?HkgKY+SYhWMzUFIA4IQHuRBestEE6JKTnzcJ51tF15xgclDo03gquY7h5kdR?= =?us-ascii?Q?3Z8Yxh6Keo/KpZu4m3wbXtn1C1N9iPf37cI7Ia4M2s/R+2SYk3A/bjB3cIOK?= =?us-ascii?Q?oVA2J3kCb9lNXlLvwjKh6AmmoQBOuIREMyjx6+8WM8DqNCYCmPlcAqjInatW?= =?us-ascii?Q?3XRwCjv0Nyq4TIDvN3LfWUPM8s6hLMsD49aW6eqd/zgET1Tmg0XXLfCPxCU7?= =?us-ascii?Q?cugDXbFlGW8w1tdWS6V3xQxwl+yLu35bnX7rHHnUvVP5ET/Efu8ceM/0KVcp?= =?us-ascii?Q?fnu2qHo9u/9n/MTM1kmebKponExhz4bSfx+TvQ/oPmyY6UrF5Rgxul+vgblE?= =?us-ascii?Q?28jo75mpIY2njKmZDdYVpxnHxO+xIlQYkbZtfJxuIOphGer5EPucy4gQQrGJ?= =?us-ascii?Q?q+I9UMDlvCTjsS2uaZZk5DjE7voBMWd4S5gwoO+xwEFMApU6PtTVbaxrjzpU?= =?us-ascii?Q?im4XCW1cDLgU0usPqcok4oYRCwjaPVWEX3fO8ExfolTCvoYEsF2XwlxCDOJ/?= =?us-ascii?Q?Xa66NK9Sn2LsbyeFcEZLmeAwiYM2J7VtbnIFdBqBvLihZ0QFLy5YMkfr2/ix?= =?us-ascii?Q?OJyLTaUnl00PalPRxNt+doEJk5FIbm5DJ6FN6x/v6KItzhJVBnmYYDh5OJvC?= =?us-ascii?Q?qz+j2joBmqdi1zQz8IOy5Jm7PH9edhktIJskhCoDqN8/w+uFxtcdPLN2LnD1?= =?us-ascii?Q?beh0XejknBEWpZcWqU0TYfC6Z2IciIN/z9xFhg+RZZddgej8dPGsi0FEEWCA?= =?us-ascii?Q?7un26sDACkdqytZvhiewNe/jQa52wmuKBMZ57KNwCir5KPdeqa2uq3VU9evS?= =?us-ascii?Q?TxZqUkg76fTivPKiSuwShHazmXqx8lhj3FDSuwVcspb/f62dlwKUFfTv7N/6?= =?us-ascii?Q?QO6xa3I1XSB5UX6xXGQU+pChpuE3VUVw92j3EuT6peZHdzuBBvKGetVcGokS?= =?us-ascii?Q?iFxxYJ1lbkb8586+wOqYw6VIjTSbYiVaD8zodgsn4yr4OrTDEgBfZYpuIHAb?= =?us-ascii?Q?q2U9YLapOvFR8mWLdPQxIfWSTvPitoTebLR7Wi5TggOI6JpeJOFSv80K64fp?= =?us-ascii?Q?U5PfhKKhHzVPh4USBCoj/BMjsFvdObXGydZTaVMy3HPLhmI/wCCCPqh1TDUu?= =?us-ascii?Q?vZQix4Lh0uWLOFP9r30xITl45t9xSWTRSfY8HF5B0qnIRYxxE8hl1/WDHI3u?= =?us-ascii?Q?8A=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AS8PR10MB74277A2DAC89D987531F7F74EECBAAS8PR10MB7427EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9b7315d4-26fd-4a8b-57d7-08dbc4df9d80 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2023 13:41:30.1994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pb3fyfrJiQA4CWTJmFNwYVrfsZNhwWnks9MojaGqKAWmIYM79h+TTDjKehSkwj4hot7yad5Ztx2Y8xZY/MxMxF+jCSeNKJbBiGD5BPrEY8U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR10MB5409 Archived-At: Subject: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2023 13:42:02 -0000 --_000_AS8PR10MB74277A2DAC89D987531F7F74EECBAAS8PR10MB7427EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, here are some comments as part of my shepherd review of the OAuth Security = BCP. First, I want to send a big "Thanks" to everyone in the group for the work = on this document and to the authors in particular. It has taken us a while = to come up with such an impressive list of security recommendations for OAu= th 2.0. At this point in time my review comments can only be minor given the amount= of feedback this documents has already received. Here are a few remarks. I believe we should indicate that the specification updates other OAuth RFC= s. The obvious documents it updates are RFC 6749, RFC 6750 and RFC 6819. You can set these "updates" in the template you are using. In Section 1 you say: " It does not supplant the security advice given in [RFC6749], [RFC6750], and [RFC6819], but complements those documents. " In the subsequent paragraph you state that you "depreciate some modes of op= eration". I believe you are need to be clear about what you are doing in relationship= to these prior documents. It might also be useful to say something about O= Auth 2.1. Expand abbreviations on first use. Example: "AS" and "PKCE" in Section 2.1.= The AS abbreviation is only expanded later in Section 3. Decide whether yo= u want to use abbreviations or not. You mix them throughout the document wi= thout no reasons. Listing the abbreviations in Section 1.2 may also be useful. There are not = that many abbreviations anyway. I have wording suggestions for this paragraph: FROM: " Authorization servers SHOULD use client authentication if possible. It is RECOMMENDED to use asymmetric (public-key based) methods for client authentication such as mTLS [RFC8705] or using signed JWTs ("Private Key JWT") in accordance with [RFC7521] and [RFC7523] (in [OpenID.Core] defined as the client authentication method private_key_jwt). When such methods for client authentication are used, authorization servers do not need to store sensitive symmetric keys, making these methods more robust against a number of attacks. " TO: " Authorization servers SHOULD enforce client authentication, if possible. It is RECOMMENDED to use asymmetric cryptography for client authentication, such as mTLS [RFC8705] or using signed JWTs ("Private Key JWT"), in accordance with [RFC7521] and [RFC7523] (in [OpenID.Core] defined as the client authentication method private_key_jwt). When asymmetric cryptography for client authenticatio= n is used, authorization servers do not need to store sensitive symmetric keys, making client authentication more robust against leakage of keys. " (Note: For the reader it is always better if they are told what attacks are prevented rather than saying "a number of attacks". You don't want the = reader to guess what you mean.) Section 2 is a summary of what follows in Section 4. Maybe you can make thi= s explicit either in the title of Section 2 or in the first paragraph of Section 2. Section 3. You write: " These attackers conform to the attacker model that was used in formal analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal attacker model. Implementers MUST take into account all possible types of attackers in the environment in which their OAuth implementations are expected to run. " When you say "these attackers" please clarify which attackers you are talki= ng about. Prior to this paragraph you have just spoken about various forms of network= attackers. Just before that you talked about network and web attackers. Then, you introduce more attackers and you keep talking about "this attacke= r model" and "these attackers". Make it easier for the reader by referring explictly whi= ch attackers you are talking about in a specific paragraph. Then, you conclude the section with a hint that there is an even stronger a= ttacker model. As a reader I might want to know what this stronger attacker model looks li= ke and why you do not consider it in this document. Section 4.1.1: You write: " Note: Vulnerabilities of this kind can also exist if the authorization server handles wildcards properly. " I believe you are saying that the vulnerabilities caused by incorrect redir= ect URI validation parsing when you refer to "this kind". I would also remove the "note" Section 4.1.3: You write: " * Servers on which callbacks are hosted MUST NOT expose open redirectors (see Section 4.11). " Are you talking about authorization servers (which is what was referenced i= n the paragraph before)? Section 4.10.1: Sender-constrained Access Tokens The text gives the reader the impression that the token binding would be an= option for developers to use. I don't think that this is the case. I am particularly referring to this se= ntence: " * *DPoP* ([I-D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of- Possession at the Application Layer) outlines an application-level sender-constraining for access and refresh tokens that can be used in cases where neither mTLS nor OAuth Token Binding (see below) are available. " I would change it to: " * *DPoP* ([I-D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of- Possession at the Application Layer) outlines an application-level sender-constraining for access and refresh tokens that can be used in cases where mTLS is not available. " I would then remove the subsequent text talking about old, expired drafts. Alternatively, you could move the text to the appendix. Section 4.10.2: Audience Restricted Access Tokens In the text you say: " Audience restriction essentially restricts access tokens to a particular resource server. The authorization server associates the access token with the particular resource server and the resource server SHOULD verify the intended audience. " You have to put a MUST here. If the resource server does not check the audi= ence restriction when using audience restricted access tokens then you obviously= do not get the value from it. It is like using DPOP and not using the proof-of-pos= session. Likewise the SHOULD language in this sentence is also questionable: " The client SHOULD tell the authorization server the intended resource server. The proposed mechanism [RFC8707] could be used or by encoding the information in the scope value. " If the client does not tell the authorization server what the intended reso= urce server is then how should the authorization server know (unless in a very limited = setup). Also the reference to RFC 8707 is a bit weak. We standardized resource indi= cators: why not recommend using it? Section 4.10.3: The section heading is "Discussion: Preventing Leakage via = Metadata". The content of the section is not really a discussion but rather a descript= ion of why this path has not been taken. I wonder whether it would be better to move t= his section to the appendix and then start the text by explaining why other solutions h= ave been used instead of this approach. Section 4.11: I would put the definition about what an "open redirector" is= into the terminology section since you are using the term already in earlier sections. Here is the definition: " An open redirector is an endpoint that forwards a user's browser to an arbitrary URI obtained from a query parameter. " Typos/Wording: FROM: " Afterwards, the updated the OAuth attacker model is presented. " TO: " Afterwards, the updated OAuth attacker model is presented. " Section 4.1: "... wild ." ^ Consider using the guidelines for inclusive language: https://www.rfc-editor.org/part2/#inclusive_language For example, "If the attacker is able to ... , **he** will directly get acc= ess to ..." Another example is "whitelisted". Section 4.1.2: a wording suggestion. FROM: " The attack described here combines this behavior with the client as an open redirector (see Section 4.11.1) in order to get access to access tokens. " TO: " The attack described here combines this behavior with the client as an open redirector (see Section 4.11.1) to obtain access tokens. " Section 4.7.1: word missing FROM: " PKCE provides robust protection against CSRF attacks even in presence of an that can read the authorization response (see Attacker A3 in Section 3). " TO: " PKCE provides robust protection against CSRF attacks even in presence of an attacker that can read the authorization response (see Attacker A3= in Section 3). " Section 4.18.2: capitalization FROM: " Wildcard origins like "*" in postMessage MUST not be used as attackers can use them to leak a victim's in-browser message to malicious origins. " TO: " Wildcard origins like "*" in postMessage MUST NOT be used as attackers can use them to leak a victim's in-browser message to malicious origins. " You might also want to replace the short title "oauth-security-topics" (whi= ch can be found on each page) with something like "OAuth 2.0 Security BCP". Ciao Hanns --_000_AS8PR10MB74277A2DAC89D987531F7F74EECBAAS8PR10MB7427EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

here are some comments as part = of my shepherd review of the OAuth Security BCP.

 

First, I want to send a big &qu= ot;Thanks" to everyone in the group for the work on this document and = to the authors in particular. It has taken us a while to come up with such = an impressive list of security recommendations for OAuth 2.0.

 

At this point in time my review= comments can only be minor given the amount of feedback this documents has= already received.

 

Here are a few remarks.

 

I believe we should indicate th= at the specification updates other OAuth RFCs. The obvious documents it upd= ates are RFC 6749, RFC 6750 and RFC 6819.

You can set these "updates= " in the template you are using.

 

In Section 1 you say:

"

It does not supplant the securi= ty advice given in

   [RFC6749], [RFC675= 0], and [RFC6819], but complements those documents.

"

 

In the subsequent paragraph you= state that you "depreciate some modes of operation".<= /span>

 

I believe you are need to be cl= ear about what you are doing in relationship to these prior documents. It m= ight also be useful to say something about OAuth 2.1.

 

 

Expand abbreviations on first u= se. Example: "AS" and "PKCE" in Section 2.1. The AS abb= reviation is only expanded later in Section 3. Decide whether you want to u= se abbreviations or not. You mix them throughout the document without no reasons.

Listing the abbreviations in Se= ction 1.2 may also be useful. There are not that many abbreviations anyway.=

 

 

I have wording suggestions for = this paragraph:

 

FROM:

"

 

   Authorization serv= ers SHOULD use client authentication if possible.

 

   It is RECOMMENDED = to use asymmetric (public-key based) methods for

   client authenticat= ion such as mTLS [RFC8705] or using signed JWTs

   ("Private Key= JWT") in accordance with [RFC7521] and [RFC7523] (in

   [OpenID.Core] defi= ned as the client authentication method

   private_key_jwt).&= nbsp; When such methods for client authentication are

   used, authorizatio= n servers do not need to store sensitive symmetric

   keys, making these= methods more robust against a number of attacks.

 

"

 

TO:

"

 

   Authorization serv= ers SHOULD enforce client authentication, if possible.

 

   It is RECOMMENDED = to use asymmetric cryptography for

   client authenticat= ion, such as mTLS [RFC8705] or using signed JWTs

   ("Private Key= JWT"), in accordance with [RFC7521] and [RFC7523] (in

   [OpenID.Core] defi= ned as the client authentication method

   private_key_jwt).&= nbsp; When asymmetric cryptography for client authentication is<= /span>

   used, authorizatio= n servers do not need to store sensitive symmetric

   keys, making clien= t authentication more robust against leakage of keys.

 

"

 

(Note: For the reader it is alw= ays better if they are told what attacks

are prevented rather than sayin= g "a number of attacks". You don't want the reader

to guess what you mean.)

 

Section 2 is a summary of what = follows in Section 4. Maybe you can make this explicit

either in the title of Section = 2 or in the first paragraph of Section 2.

 

 

 

Section 3.

 

You write:

 

"

   These attackers co= nform to the attacker model that was used in formal

   analysis efforts f= or OAuth [arXiv.1601.01229].  This is a minimal

   attacker model.&nb= sp; Implementers MUST take into account all possible

   types of attackers= in the environment in which their OAuth

   implementations ar= e expected to run.

"

 

When you say "these attack= ers" please clarify which attackers you are talking about.<= /span>

Prior to this paragraph you hav= e just spoken about various forms of network attackers.

Just before that you talked abo= ut network and web attackers.

 

Then, you introduce more attack= ers and you keep talking about "this attacker model" and

"these attackers". Ma= ke it easier for the reader by referring explictly which attackers

you are talking about in a spec= ific paragraph.

 

Then, you conclude the section = with a hint that there is an even stronger attacker model.

As a reader I might want to kno= w what this stronger attacker model looks like and why you

do not consider it in this docu= ment.

 

 

Section 4.1.1:

 

You write:

"

Note: Vulnerabilities of this k= ind can also exist if the

   authorization serv= er handles wildcards properly.

"

 

I believe you are saying that t= he vulnerabilities caused by incorrect redirect URI validation parsing when= you refer to "this kind".

I would also remove the "n= ote"

 

 

Section 4.1.3:

 

You write:

 

"

   *  Servers on= which callbacks are hosted MUST NOT expose open

      = redirectors (see Section 4.11).

"

 

Are you talking about authoriza= tion servers (which is what was referenced in the paragraph before)?

 

 

Section 4.10.1: Sender-constrai= ned Access Tokens

 

The text gives the reader the i= mpression that the token binding would be an option for developers to use.<= o:p>

I don't think that this is the = case. I am particularly referring to this sentence:

 

"

 

   *  *DPoP* ([I= -D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of-

      = Possession at the Application Layer) outlines an application-level

      = sender-constraining for access and refresh tokens that can be used

      = in cases where neither mTLS nor OAuth Token Binding (see below)<= /span>

      = are available.

"

 

I would change it to:

"

 

   *  *DPoP* ([I= -D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of-

      = Possession at the Application Layer) outlines an application-level

      = sender-constraining for access and refresh tokens that can be used

      = in cases where mTLS is not available.

"

 

I would then remove the subsequ= ent text talking about old, expired drafts.

Alternatively, you could move t= he text to the appendix.

 

 

Section 4.10.2: Audience Restri= cted Access Tokens

 

In the text you say:=

 

"

   Audience restricti= on essentially restricts access tokens to a

   particular resourc= e server.  The authorization server associates the

   access token with = the particular resource server and the resource

   server SHOULD veri= fy the intended audience.

"

 

You have to put a MUST here. If= the resource server does not check the audience

restriction when using audience= restricted access tokens then you obviously do not

get the value from it. It is li= ke using DPOP and not using the proof-of-possession.

 

Likewise the SHOULD language in= this sentence is also questionable:

 

"

The client SHOULD tell the auth= orization server the intended resource

   server.  The = proposed mechanism [RFC8707] could be used or by

   encoding the infor= mation in the scope value.

"

 

If the client does not tell the= authorization server what the intended resource server

is then how should the authoriz= ation server know (unless in a very limited setup).

 

Also the reference to RFC 8707 = is a bit weak. We standardized resource indicators: why not

recommend using it?<= /span>

 

Section 4.10.3: The section hea= ding is "Discussion: Preventing Leakage via Metadata".=

The content of the section is n= ot really a discussion but rather a description of why

this path has not been taken. I= wonder whether it would be better to move this section

to the appendix and then start = the text by explaining why other solutions have been used instead of this a= pproach.

 

 

Section 4.11: I would put the d= efinition about what an "open redirector" is into the terminology= section since you

are using the term already in e= arlier sections. Here is the definition:

 

"

An open redirector is an endpoi= nt that forwards a user’s

   browser to an arbi= trary URI obtained from a query parameter.

"

   =

 

Typos/Wording:

 

FROM:

"

Afterwards, the updated the OAu= th attacker model is presented.

"

 

TO:

"

Afterwards, the updated OAuth a= ttacker model is presented.

"

 

Section 4.1:<= /p>

 

"... wild ."

     &= nbsp;   ^

 

Consider using the guidelines f= or inclusive language:

https://www.rfc-editor.org/part2/#inclusi= ve_language

 

For example, "If the attac= ker is able to ... , **he** will directly get access to ..."

 

Another example is "whitel= isted".

 

Section 4.1.2: a wording sugges= tion.

 

FROM:

"

The attack

   described here com= bines this behavior with the client as an open

   redirector (see Se= ction 4.11.1) in order to get access to access

   tokens.=

"

 

TO:

"

The attack

   described here com= bines this behavior with the client as an open

   redirector (see Se= ction 4.11.1) to obtain access tokens.

"

 

 

Section 4.7.1: word missing

 

FROM:

 

"

PKCE provides robust protection= against CSRF attacks even in presence

   of an that can rea= d the authorization response (see Attacker A3 in

   Section 3). <= /o:p>

"

 

TO:

 

"

PKCE provides robust protection= against CSRF attacks even in presence

   of an attacker tha= t can read the authorization response (see Attacker A3 in=

   Section 3). <= /o:p>

"

 

 

 

Section 4.18.2: capitalization<= o:p>

 

FROM:

 

"

Wildcard origins like "*&q= uot; in postMessage MUST not be used as

   attackers can use = them to leak a victim's in-browser message to

   malicious origins.=

"

TO:

 

"

Wildcard origins like "*&q= uot; in postMessage MUST NOT be used as

   attackers can use = them to leak a victim's in-browser message to

   malicious origins.=

"

 

You might also want to replace = the short title "oauth-security-topics" (which can be found on ea= ch page) with something like "OAuth 2.0 Security BCP".=

 

Ciao

Hanns

 

--_000_AS8PR10MB74277A2DAC89D987531F7F74EECBAAS8PR10MB7427EURP_--