[Openid-specs-ab] Issue #1525: [Federation] Security Considerations (openid/connect)

[peppelinux]

New issue 1525: [Federation] Security Considerations
https://bitbucket.org/openid/connect/issues/1525/federation-security-considerations

Giuseppe De Marco:

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