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

[Dick Hardt <[e-mail]>]

For many resources, the information is already disclosed. What is excessive
to you might be crucial to others -- and my use case, the disclosure is
crucial.

Extrapolating your basis for objecting, that another endpoint provides
additional attack surface, we would not do ANY new endpoints or
functionality since they would all provide more attack surface.

On Sat, Aug 26, 2023 at 11:38 PM Jaimandeep Singh <
[e-mail]> wrote:

> 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, <[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
>>>
>>