Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Tom Jones <[e-mail]>]

The security reason for exclusion of error codes and other information is
that the data helps the attacker subvert the app. I continue my attempt to
avoid helping the attacker.

thx ..Tom (mobile)

On Sat, Aug 26, 2023, 7:58 AM Dick Hardt <[e-mail]> 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=
> [e-mail]> 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=
>> [e-mail]> 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=
>>> [e-mail]> 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 <
>>>> [e-mail]> 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
>>>>> [e-mail]
>>>>> 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
>>>> [e-mail]
>>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>