1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

[Federation] Security Considerations

Issue #1525 resolved
Giuseppe De Marco created an issue

In this issue I would like to collect the open points and the proposals and ideas related to Security Sicurations in OIDC Fed specs.

My first point is related to the current text we have. I read “… Some of the interfaces defined in this specification could be used for Denial-of-Service attacks (DOS), most notably, Entity Listings (Section 7.3) …“. I don’t see any warning or danger with the entity listing endpoint. For this reason, if there aren’t some motivation we may think to remove that statement and leave the text as it is only for the automatic client registration. Each endpoint works like a common web endpoint and I think that’s these may require some throttling/rate-limit anyway, but it’s no related to OIDC Fed, that would be for the web in general.

The following is focused on additional elements we may consider, I got these during the implementation of OIDC Fed specs:

The role of the trust marks
The static signature validation of a recognizable trust mark, exposed by a partecipant and validated with the public key of its issuer, is the only filter that prevents to a verifier (OP) to send as many http requests as are the authority_hints found during the path. An attacker could exploit the metadata discovery mechanism and use an OIDC Federation for propagating attacks. Each authz request, made by an unknown client, the OP would produce ~3 http requests to third parties in absence of intermediaries, and at least 5 http requests with at least one intermediary. This would be exploited as a driver for an attack. If an OP can’t find any valid trust mark in a Entity Configuration it should reject the request and ban that client_id for minutes.

Regarding the banning strategy I’m suggesting, to the implementors and in a non normative way, to adopt a fibonacci serie in minutes with a TTL (redis works great for that).

a) An attacker wants to exploit the propagation of the metadata discovery and signs an authz request using a fake client_id.
b) the OP receives the authz request
c) the OP checks, before starting any http request to get the Entity Configuration, if that client_id has already been banned in the past. It’s not.
d) the OP fetches the Entity Configuration of the attacker
e) the OP found a missing/invalid trust mark
f) the OP wrote the client_id in the BAN storage with a TTL threshold of 2 minutes
g) the OP rejects the authz request
h) the attacker pushes again the request
i) the OP does its checks as described at point c). Having found that the client_id have been banned in the past it updates the TTL making $last_value*2 (4 minutes) and rejects the authz request

Comments (14)

  1. Joseph Heenan

    Thanks Giuseppe for raising this, I think this is a good point and something that does need to be addressed.

    One part I’m not entirely following - if the client_id being used is fake, is there something that prevents the attacker from just using a different fake client_id each time?

  2. Vladimir Dzhuvinov

    @Joseph Heenan a trust mark that asserts the entity ID (in this case a client_id) is intended to prevent this.

  3. Giuseppe De Marco reporter

    @Joseph Heenan I completely agree with you, that’s why we need a memory usage limit in Redis to prevent a memory consumption attack with a flood of fake client_id.

    anyway, we may assume that fibonacci series was a fancy nerd idea that’s not suitable to free the memory in time. So, simplifying all this, we may adopt a constant TTL value of 5 minutes.

    For a flood of fake client_id, we consider that client_id is a resolvable FQDN (DNS). We also consider that an implementer MAY use the listing endpoint of TA and its itenrmediaries, to get some “hints” on the recognizable partecipants. This latter approach design another pattern as well

  4. Vladimir Dzhuvinov

    The past couple of days I was thinking about the potential security issue with non sanctioned entity types (type meaning OP, RP, etc) in a Federation. The original ticket is linked below.

    • What can prevent a intermediary that is allowed to have only RPs beneath it from adding an OP policy? And that policy being accepted as okay by other entities?
    • What can prevent an entity that was for example registered as RP to also set up an OP, and that OP not get picked up as trusted OP by other RPs in the federation (in the absence of use of type asserting trust marks in the federation)?

    At present the spec has a clear algorithm to resolve trust chains (anchor - intermediate - leaf entity relationships) and policy mechanism for the fields in a metadata. The aspect what types of entity / where they are allowed in the federation appears ambiguous though, and this may lead to issues. I personally feel unsure how this could be effectively approached and addressed. A list of possible or anticipated use cases / policies about the structuring of entity types in a Federation will help here.

    https://bitbucket.org/openid/connect/issues/1493/federation-devise-mechanism-for-policy

  6. Giuseppe De Marco reporter

    we may start a PR to have a security consideration about the use of Trust Marks as filter against the propagation attacks.

    Then we may have another PR to specify that an unprotected resolve endpoint MUST not trigger any new http request (metadata discovery). If an request comes from a untrusted party.

  11. Giuseppe De Marco reporter

    The PR was merged and this issue can be closed right now, however I’d like to discuss also the issue above that may be relevant for the security considerations
    https://bitbucket.org/openid/connect/issues/1534/federation-trust-mark-hint-in-the-authz

    the questions is:

    Can we use the trsut mark in the request and avoid that a OP (trust verifier) collects the Entity Configuration (or trying to do so)?
    Can we reduce the x2 propagation of http requests, simply adopting this hint?

  12. Giuseppe De Marco reporter

    @Joseph Heenan I’ve to correct myself, reading again my opening text in this issue I found a mistake. The Verifier of the trust (in this case an OP) would temporarly ban the requestor’s IP address and not the client_id.

    the IP Address of the user agent that carries the fake authz request.

    It wouldnt be possibile to ban thousands of fake client_id considering that they can be randomnly forged for that scope. My bad! 🙂

  15. Log in to comment
Assignee
Type
enhancement
Priority
minor
Status
resolved
Component
Federation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!