Auth 2.0 spec errata regarding delegation vs. directed identity
mart at degeneration.co.uk
Wed May 14 18:20:12 UTC 2008
In a conversation yesterday I found out that a particular existing
OpenID Provider is acting in a way that defeats delegation. This is
allowed by the spec, but has non-obvious degenerate behavior:
* You delegate to your identifier with this provider
* Another user of this provider logs in with your delegate URL
* Provider uses the other user's existing session to determine his
identifier, and allows the user to log in.
* Provider returns an assertion with openid.identity set to the other
user's identifier, but with openid.claimed_id still set to your delegate
* RP does discovery on the delegate URL and finds that its
openid2.provider is the correct provider, so the assertion succeeds and
the other user has logged in as you.
It seems to me that there are several different failings here that
together result in this "hole":
* The provider is not checking that openid.identity in the initial
request is a valid identity for the active user. If it is not, an error
message should be presented to the user. For example, in this case
LiveJournal will say "The site you just came from seems to want to
verify an identity that you, as exampleusername, cannot provide". Of
course, the magic identity value for directed identity is valid for any
user as a special case.
* The RP, when verifying that the openid.claimed_id URL in the
assertion is valid, checks only that the openid2.provider value is
correct, and doesn't check that the openid2.local_id value matches
(after removing the fragment part) the openid2.identity URL.
It's particularly concerning because it looks to the user like
delegation is working correctly, and the user is unlikely to try to log
in as another user to notice the vulnerability they've exposed
Both of the above are currently allowed by the Auth 2.0 spec, but since
doing the above checks doesn't seem to remove any useful possibilities,
I think there ought to be some sort of errata that requires the checks
I've listed above.
The latter check at the RP also suggests that OPs supporting multiple
identifiers per user must not present the user with identifier
substitution UI except in the directed identity case. The identifier
asserted *must* match the identifier in the initial request, since in
the delegation case that is the value of openid2.local_id that the RP
will ultimately verify.
Sadly I didn't catch the full name of the guy that discovered this
issue, but I believe his first name was John. Feel free to chime in and
take credit for this, John!
 I won't name the provider here, since any users already doing
delegation to their identifier at this provider will be vulnerable to
the above. Folks from the provider were part of this conversation, so
hopefully they will fix it by requiring that the requested identifier
matches the authenticated user.
More information about the specs