Hi Dick, My previous emails do not even obliquely refer to security by obscurity. It is about design patterns and excessive information disclosure.
Regards Jaimandeep Singh On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt, <dick.ha...@gmail.com> wrote: > Jaimandeep: Do I understand your objection to adoption is that providing a > resource discovery endpoint increases the attack surface as an > attacker gains knowledge about the resource? > > If I understand that correctly, then you are suggesting security through > obscurity. > > As mentioned by Aaron, there is no requirement for a resource to support > the resource metadata, and the metadata itself could be protected. > > Practically though, I believe the argument that security is improved by > not having a resource discovery endpoint is false. Most resources have > publicly available documentation which will contain the same information, > and while the docs are not necessarily machine readable, LLMs can make it > pretty accessible. > > Even if you wanted to keep it secret, if applications that use the > resource are readily available, how the applications interact with the > resource can be discerned through reverse engineering. > I think that a security consideration calling out that a malicious actor > more readily has access to the protected resource metadata is an adequate > response. > > For my use case, the protected resource metadata is required for the > functionality I plan to implement. The AS has no prior knowledge about the > protected resource, and when a request is made, the AS learns about the PR > and presents the user with an experience based on the metadata for the user > to make a decision to grant access. > > /Dick > > > > On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh <jaimandeep.phdcs21= > 40nfsu.ac...@dmarc.ietf.org> wrote: > >> 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....@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...@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.i...@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 mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
