Right. It’s worth noting that many endpoints already publish similar metadata via OpenAPI (Swagger) API descriptions.
Neil On 27 Aug 2023, at 19:42, Dick Hardt <dick.ha...@gmail.com> wrote:
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. 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
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
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
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
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
--
Regards and Best Wishes Jaimandeep Singh
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Regards and Best Wishes Jaimandeep Singh
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
|
