[Openid-specs-ab] Discovery security considerations.

Mike Jones Michael.Jones at microsoft.com
Thu Dec 19 22:28:47 UTC 2013


The new text is now in place (with a few more tweaks) at http://openid.bitbucket.org/openid-connect-discovery-1_0.html#Impersonation.

				-- Mike

-----Original Message-----
From: Mike Jones 
Sent: Thursday, December 19, 2013 1:37 PM
To: 'John Bradley'
Cc: Openid-specs Ab
Subject: RE: Discovery security considerations.

Thanks for sending this, John.  Here's the version that I propose to put into the doc.

				-- Mike

7.2  Impersonation Attacks

TLS certificate checking MUST be performed by the RP, as described in Section 7.1, when making an OpenID Provider Configuration Request.   Checking that the server certificate is valid for the Issuer URL prevents man-in-middle and DNS-based attacks.  These attacks could cause an RP to be tricked into using an attacker's keys and endpoints, which would enable impersonation of the legitimate Issuer.   If an attacker can accomplish this, they can access the accounts of any existing users at the affected RP that can be logged into using the OP that they are impersonating.

An attacker may also attempt to impersonate an OpenID Provider by publishing a Discovery document that contains an Issuer claim using the Issuer URL of the Issuer being impersonated, but with its own endpoints and signing keys.  This would allow it to issue ID Tokens as that Issuer, if accepted by the RP.   To prevent this, RPs MUST ensure that the Issuer URL they are using for the Configuration Discovery exactly matches the value of Issuer claim in the OP Metadata document retrieved by the RP.


-----Original Message-----
From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
Sent: Thursday, December 19, 2013 11:08 AM
To: Mike Jones
Cc: Openid-specs Ab
Subject: Discovery security considerations.

Section  7.2 Provider Configuration Request

TLS certificate checking MUST be performed by the client when making a Provider Configuration Request.   Checking that the server certificate is valid for the issuer URI, prevents man in the middle or DNS based attacks.  These attacks may cause a client to be tricked into accepting an attackers keys and endpoints to impersonate a legitimate issuer.   If an attacker can do this, they can access accounts of any users already created at affected client that have subjects scoped to the issuer they are impersonating.

Section  7.3 Client configuration of Issuer Endpoints & Keys

An AS may attempt to impersonate another AS by publishing a Discovery document that contains a issuer claim containing the issuer URL of another issuer as the value, but with it's own endpoints and signing keys.  This would allow it to issue issue id_tokens as that issuer.   To prevent this clients MUST ensure that the issuer URL they are discovering exactly matches the value of issuer claim in the provider metadata document retrieved by the client.  





More information about the Openid-specs-ab mailing list