[openid-specs-rande] Route of denial of service in OIDC Federation?

Roland Hedberg roland at catalogix.se
Thu Sep 26 15:51:18 UTC 2019



> On 24 Sep 2019, at 23:43, Nick Roy <nroy at internet2.edu> wrote:
> 
> Is it possible for a malicious party to generate an arbitrarily long trust chain that an OpenID Connect Federation implementation spends a lot of time verifying? Would making authority_hints mandatory circumvent this? See also: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

At the Nordunet Technical Workshop yesterday two related issues was raised.

- Should a Trust anchor/Intermediate be able to limit the depth of the chain below itself ?
- Should a Trust anchor/intermediate be able to restrict the entity IDs ?

Reference was made to max path and name constraints as used in PKI.

The depth questions has been raised before but nothing has been added to the draft to support that functionality.
The name constraint is new.

If we want to add either constraint it should probably be added to metadata/federation_entity.
Like this (borrowing names/structure ideas from RFC5280):

"metadata": {
    "federation_entity": {
        "federation_api_endpoint":
            "https://example.com/federation_api_endpoint",
        "name": "The example cooperation",
        "homepage_uri": "https://www.example.com",
        "max_path_length": 2,
        "naming_constraints": {
            "permitted": [
                "https://.example.com"
            ],
            "excluded": [
                "https://east.example.com"
            ]
        }
    }
} 

— Roland

It is curious that physical courage should be so common in the world, and moral courage so rare. -Mark Twain, author and humorist (30 Nov 1835-1910)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190926/24465afa/attachment.html>


More information about the openid-specs-rande mailing list