Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
Jaimandeep Singh <jaimandeep.phdcs21@nfsu.ac.in> Sat, 26 August 2023 03:29 UTC
Return-Path: <jaimandeep.phdcs21@nfsu.ac.in>
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 B5C5DC15170B for <oauth@ietfa.amsl.com>; Fri, 25 Aug 2023 20:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=nfsu.ac.in
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 VxJBiR3sZwti for <oauth@ietfa.amsl.com>; Fri, 25 Aug 2023 20:29:28 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C52C14CE25 for <oauth@ietf.org>; Fri, 25 Aug 2023 20:29:28 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-4ff9b389677so2301317e87.3 for <oauth@ietf.org>; Fri, 25 Aug 2023 20:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfsu.ac.in; s=google; t=1693020566; x=1693625366; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bqP394kh6lf5ONstbUbT7I8I09oGJOA3Vw1zCJ3/Jx4=; b=ATpVJ8kcarcdzeZ4ZkZufiBEZbQISUEfJroI6puEzhlpnWRv5uoqt+O4QzhbEkdqLb Ei5qAb9vkB7n2AwmcLKhSHMxPYTPIFKTqxI5IdNr5cTlWt5XUP9tYMlRcEH+d00d6rdg 18kgQ7JM2bhlY5oncChBpKaJyCxnQAZ/MIAkE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693020566; x=1693625366; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bqP394kh6lf5ONstbUbT7I8I09oGJOA3Vw1zCJ3/Jx4=; b=DKml7nwL9TtGsjVpijQSoWOOQLSvgiMT7MIXYpYaBLacoVgHxjbKsQ3vNxfASCEIF9 7RE1NB3ztBnPHBdSRoGpT+xRkM+MHp67chWS/+F6t1mcTOJdBhcdiO29/ZKO8PvfzUGi 2HjQFOSFxjaaMhv8Wk/zXJgkt0ZHH2d8nvvSUyW8PqZZUx4SPCGViz98axpu86LxEdlq R70ok0qTNd8OlEQMU3jxftBsV1WNWGKtuaKhzu8BkK1fekf1bDb3LJBStQnRokGoUVpf rrQn+A1zOAy8HU+05TTAf0Zw1NO1vrIGWmOR89E5RcD/mhu5LhsVsX/1AiCBStBey/5u KqXg==
X-Gm-Message-State: AOJu0YxSUaVIfvqOkExDQOOrzRAvAY7EFUxTHa8BAesXOx1hSI9bcUcO tcpSGce+LIy8J8CqEKWy+BJdj1xSN9XubrBClZElYw==
X-Google-Smtp-Source: AGHT+IE+dm/OwPUBFoiBrFDDuh0wPaL1yeoGYZnRnzevdmgjMXST+sLVAZQS2kDFzfymChMPhAIezBU+6RmQBS7B2qk=
X-Received: by 2002:ac2:4285:0:b0:500:9977:bdce with SMTP id m5-20020ac24285000000b005009977bdcemr5980138lfh.62.1693020565361; Fri, 25 Aug 2023 20:29:25 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP_ve-rMFrioC0LS=NowESnTn1LSOU0pV4=K8hht4zy+Nw@mail.gmail.com> <CAODMz5FsmR7mxGuZk5=bOg4zP9PEAHhsWbnK7uvU_Q3ATKuc8g@mail.gmail.com> <CAGBSGjpWB5ynNQM5fLUwd9SoaN8hs-87aiMxPk4km9jVrfLHqw@mail.gmail.com>
In-Reply-To: <CAGBSGjpWB5ynNQM5fLUwd9SoaN8hs-87aiMxPk4km9jVrfLHqw@mail.gmail.com>
From: Jaimandeep Singh <jaimandeep.phdcs21@nfsu.ac.in>
Date: Sat, 26 Aug 2023 08:59:11 +0530
Message-ID: <CAODMz5GuGUhZWJZrbkGW_Pj0LefDQqsSCd++4ODMJBKCwR1Wcw@mail.gmail.com>
To: Aaron Parecki <aaron=40parecki.com@dmarc.ietf.org>
Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000656b240603cb11b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7EdvdWxaw8oTu1oYhVkZzd5q1FY>
Subject: Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 26 Aug 2023 03:29:32 -0000
Hi Aaron, Thx for your suggestions. I have reviewed the recordings and I would suggest following: 1. Design Consideration: The two components of the OAuth 2.0 ecosystem authorization server (step 1) and protected resource server (step 2) may appear independent, but from systems perspective there is a linear dependency between them. Directly engaging with step 2, even in a limited capacity, threatens the established sequence and poses substantial security and architectural implications. 2. Information Disclosure: Say I have my HIPPA record stored on a protected resource server, I don't want any app to even know that I have such a resource available with a protected resource server in the first place. The concept of exposing the mere existence of such data raises a glaring concern. Looking at Google, it has a fine-grained authorization strategy that meticulously limits access for its RESTRICTED scopes only to apps that meet certain security benchmarks. Once, the malicious apps come to know of the prized data at the resource server, it will lead to targeted phishing attacks, as was highlighted during the 117 meeting, underscoring the fragility of this approach. 3. The Imperative of Gradation and Minimal Exposure: Even if we have to go down this path, there is a definite need to mitigate the perils of overexposure. Instead we can look at gradation strategy, wherein the scopes could be categorized into levels, spanning from generic (Level 0) to tightly controlled (Level 5) access. There is no requirement of secondary URI in this appch. For instance, the sensitive scopes like level 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no need to divulge if a particular resource is present or not and not even the address of the authorization server. Thanks Jaimandeep Singh On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki <aaron= 40parecki.com@dmarc.ietf.org> wrote: > Hi Jaimandeep, > > As with many OAuth extensions, this is not obligatory to implement unless > you need the functionality it provides. Many of the concerns you mention > are referenced in the security considerations section of the draft already, > and we would of course be happy to further expand that section as > appropriate. > > As we presented during the last two IETF meetings, there are many use > cases that would benefit from this draft that currently don't have an > interoperable solution. I would suggest you review those presentation > recordings so better understand the use cases. > > Aaron > > > > > On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh <jaimandeep.phdcs21= > 40nfsu.ac.in@dmarc.ietf.org> wrote: > >> I do not support the adoption because of following: >> >> 1. Increased Attack Surface and Information Disclosure: The proposed >> draft inherently expands the attack surface by allowing the retrieval of >> detailed information about the protected resources held with a >> particular resource server, as outlined in section 3.1. We are >> inadvertently exposing the resources supported by the protected resource >> server. The secondary URIs which correspond to each of the protected >> resources further expands the potential attack vectors. To illustrate, if a >> protected resource server supports resources from 1 to 10, and a client >> requests metadata for all these resources, it leads to 11 requests (1 + >> 10). This exposes a total of 11 URIs to potential attackers with >> information disclosure. >> >> 2. Lack of Client Verification and Potential DDoS Vulnerability: There is >> absence of client application verification before it accesses the APIs. >> This can lead to the possibility of malicious client applications >> initiating Distributed Denial of Service (DDoS) attacks. >> >> 3. Impact on Processing Time due to Multiple Resources: The need to >> wildcard match/support numerous secondary URIs based on the number of >> protected resources could lead to increased processing time. >> >> 4. Strengthening the Existing System with Adequate Error Codes: Our >> existing OAuth RFC, can handle this issue gracefully by incorporating error >> codes. This ensures that, at the very least, access tokens are verified >> before any specific information is disclosed. >> >> Thanks >> Jaimandeep Singh >> >> On Thu, Aug 24, 2023 at 12:32 AM Rifaat Shekh-Yusef < >> rifaat.s.ietf@gmail.com> wrote: >> >>> All, >>> >>> This is an official call for adoption for the *Protected Resource >>> Metadata* draft: >>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ >>> >>> Please, reply on the mailing list and let us know if you are in favor of >>> adopting this draft as WG document, by *Sep 6th.* >>> >>> Regards, >>> Rifaat & Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Regards and Best Wishes >> Jaimandeep Singh >> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- Regards and Best Wishes Jaimandeep Singh LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
- [OAUTH-WG] Call for adoption - Protected Resource… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Dick Hardt
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Michael Jones
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Orie Steele
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Pieter Kasselman
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Giuseppe De Marco
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Michael Prorock
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Nicole Roy
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Steinar Noem
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Heather Flanagan
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Tobias Looker
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Aaron Parecki
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Amir Sharif
- Re: [OAUTH-WG] Call for adoption - Protected Reso… David Waite
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Leif Johansson
- Re: [OAUTH-WG] Call for adoption - Protected Reso… John Bradley
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Oliver Terbu
- Re: [OAUTH-WG] [External Sender] Call for adoptio… George Fletcher
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Neil Madden
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Jaimandeep Singh
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Michael Schwartz
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Aaron Parecki
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Jaimandeep Singh
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Dick Hardt
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Tom Jones
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Jaimandeep Singh
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Dick Hardt
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Neil Madden
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Joseph Heenan
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Daniel Fett
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Takahiko Kawasaki
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Atul Tulshibagwale
- Re: [OAUTH-WG] [External Sender] Re: Call for ado… George Fletcher
- Re: [OAUTH-WG] [External Sender] Re: Call for ado… Atul Tulshibagwale
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Brian Campbell
- Re: [OAUTH-WG] Call for adoption - Protected Reso… Atul Tulshibagwale