[OpenID] Bug in OpenID RP implementations

[Andrew Arnott]

Eric,

There is indeed a bug somewhere in the OpenID auth process for
https://ejnorman.protectnetwork.org.  Here is what's going on:

   1. Discovery on https://ejnorman.protectnetwork.org tells the RP the
   following information (among other unlisted data):
      1. The Provider implements OpenID 1.x (a 2.0 RP recognizes that this
      is a 1.0 Provider because the tag is openid.server instead of
      openid2.provider)
      2. The OP Local Identifier is https://ejnorman.protectnetwork.org,
      because there is no openid.identity tag in the identity page and
therefore
      the Claimed Identifier implicitly assumed per the spec.
      2. The RP crafts an OpenID request asking the provider to assert an
   identity for https://ejnorman.protectnetwork.org
   3. (user authentication at the OP, beyond control of the RP)
   4. The OP is then sending a positive assertion for
   http://ejnorman.protectnetwork.org (note the *lack* of the HTTPS
   scheme).  This means the Provider doesn't support sending assertions for
   HTTPS claimed identifiers because although the RP asked it to, it refused
   and changed it to an insecure claimed identifier.
   5. The RP receives the assertion, notices that the local identifier
   (openid.identity) has changed from HTTPS to HTTP.  This contradicts what the
   RP's earlier discovery told it about the HTTPS claimed id and therefore
   fails because the spec mandates that the asserted info matches the
   discovered info.

As far as I can brainstorm right now, there is exactly one correct solution
to this problem:
Add an openid.identity tag to your identity page with a value of
http://ejnorman.protectnetwork.org so that the discovery data matches the
asserted data.

At first I thought that I could fix dotnetopenid so that when dealing with
1.0 OPs it could perform discovery again on the new openid.identity value
and allow that new data to match the asserted data and then let the user log
in.  But on further thought I don't think this would be a secure and true
interpretation of the spec.  See, if the user types in
https://ejnorman.protectnetwork.org/, then the claimed identifier in this
case is exactly that URL because no redirects occur.  When the assertion
comes back for the non-SSL openid.identity, even if the RP did discovery on
the http://ejnorman.protectnetwork.org<https://ejnorman.protectnetwork.org/>(non-SSL)
url, that would be of no use to the original Claimed Identifier.
The only thing the RP could safely do at that point is proceed to log in the
user as if their claimed identifier was the HTTP one rather than the HTTPS
one.  But this isn't what the user typed in or presumably wanted.

So what we have here is a misconfigured identity page, in my opinion.  And
the fix is (happily) quite easy.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Thu, Jan 1, 2009 at 2:18 PM, Eric Norman <ejnorman at doit.wisc.edu> wrote:

>
> On Jan 1, 2009, at 2:45 PM, Andrew Arnott wrote:
>
> > Eric,
> >
> > I believe it is exactly the problem that Peter is facing.
> >
> > Regarding the behavior you saw, Eric, DotNetOpenId doesn't ever demote
> > https to http (or if so it would be a bug), but it will go through all
> > endpoints listed for a given OpenID and chooses from among that list.
> > So if your OpenID has multiple service endpoints listed (through an
> > XRDS file) can you check whether a non HTTPS OP Endpoint is among the
> > list?
>
> The address bar said http, but I might have looked
> to quickly.  It could have been protectnetwork that
> did the demotion.
>
> > I'd very much like to know the particular OpenID you were trying it
> > with so I can examine the behavior if you'd care to share (perhaps off
> > the list if you wish).
>
> https://ejnorman.protectnetwork.org
>
> This has worked at some OpenID sites in the past.
>
> In any case, there's certainly a bug somewhere since
> the error message I quoted is complaining about
> something I never typed.
>
> Eric Norman
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090101/bb54ad84/attachment-0002.htm>