[OpenID] Reconsideringhttp://openid different from https://openid

Sat Sep 29 20:15:49 UTC 2007

John

You need to work through the delegate case which also does an https redirect on the discovery endpoint, BEFORE the client learns the delegate value.

You need to work through the additional delegate case which does an https redirects WHEN the client follows the delegate value to start communication with the Auth endpoint

You need to work through the additional delegate cases (plural) which mixes these two http/https redirect flows.

There are many additional sub-cases you might see fit to analyse, involving an https endpoint downgrading to http during either the discovery or the authentication handoff phases.

---------------

Perhaps a story will help motivate folks to apply rigorous security engineering techniques, even in a consumer-tolerant application? 

I built myself a UML state diagram of what I think the security enforcing controls in the protocol spec seem to require -- from which the C code tables controlling the protocol engines are then auto-generated. While intended to produce nice compact C code for SIM (or other microprocessor) libraries, my tool happens to also produce ANSI-C compilable tables that can equally constrain a good old fashioned Win32 message pump based PC App - allowing for PC "visual" simulation of the protocol machine. (A little bit of simulation programming allows external events issued by the logic to be consumed by GUI controls that allow you the designer to guide a particular protocol run, allowing your human intuition to then guide the security analysis) The nice thing is that the state-completeness function of the UML compiler searches out all flow paths (taking about 1h on my fast PC, for the openid Auth 2.0 states), and the visualization helps you the designer determine the nature of the conflicting conditions underlying the ambiguous state transitions or ambiguous paths that this process identifies in the (UML-formalized) security logic. Once idnetified, you then super-impose conditions that are not described in the spec - to constrain the set of all possible flows to address both your functional needs and your communities tolerance for risk.

This was all a nice re-purposing of the tool chain we applied when designing a "web-embracing" security model enforced by the "key lockbox" that fits on your door, when you have a Realtor sell your (US) house. The nature of Realtors working with other Realtors governed by one or more local trade associations is similar to RPs working with OPs via OP delegation - as the listing realtor (RP) must eventually broker with one of thousands of others Realtors that must be discovered (each being a delegating OP) who come with a personal key issued by one or other mutually trusting MLS authority (each an OP) that gains them admittance to your property via the housekey-lockbox . Hopefully, a buyer wandering through your home during this "showing event" just loves your floral wallpaper, and thus buys the home.

________________________________

From: general-bounces at openid.net on behalf of John Panzer
Sent: Sat 9/29/2007 9:13 AM
To: Pat Patterson
Cc: Martin Atkins; general at openid.net
Subject: Re: [OpenID] Reconsideringhttp://openid different from https://openid

So those are two different things, an HTTP redirect and OpenID
delegation.  At least I'm assuming we're talking about two different
things.  Here's the difference:

Redirect:

Client does GET http://someblog.blogspot.com <http://someblog.blogspot.com/> 
Client gets back a 301 with Location: https://someblog.blogspot.com <https://someblog.blogspot.com/> 

Delegation:

Client does GET http://someblog.blogspot.com <http://someblog.blogspot.com/> 
Client gets back a 200 with content containing <link
rel="openid.delegate" href="https://blah.some.server.org <https://blah.some.server.org/> ">

Clients should follow 301's and should update their internal references
to be the new URL (OpenID identifier).  Clients should use delegation to
figure out how to authenticate a user, but the actual identifier
shouldn't be affected.

Pat Patterson wrote:
> There's been something nagging at me through this discussion: the RP 
> seems to be following the trail all the way to the user's IdP. I 
> thought the user could do some delegation, so there is indirection 
> between the provided URL and the actual URL at the IdP, the benefit 
> being that I remain in control of (say) http://someblog.blogspot.com/ 
> and I can move my actual IdP account from someidp.com to abetteridp.com.
>
> What happens to all this if the RP is supposed to follow the rabbit 
> trail to the bottom and store someidp.com. When I get a better del  from
> abetteridp.com, I'm stuck, am I not?
>
> Cheers,
>
> Pat
>
> On Sep 29, 2007, at 1:38 AM, Lukas Rosenstock wrote:
>
>> Am 29.09.2007, 03:44 Uhr, schrieb John Panzer 
>> <jpanzeracm at johnpanzer.com>:
>>
>>> Then I'm confused. If you do a redirect over http, a MITM attacker  can
>>> modify the response and show the user what appears to be their OP and
>>> collect their password, right?  That is, if the point of  redirecting to
>>> https is to prevent MITM attacks, but the initial redirect itself is
>>> vulnerable to MITM, what have you gained?
>>
>>
>> User logs in for the first time, enters http://myid/, gets  redirected to
>> https://myid/ (this identity is "SSL-validated" and can not be  taken
>> over)
>> and is signed up as https://myid/. All an attacker in control of
>> http://myid/ can do is redirect to https://myid.fakeserver/ which is
>> obviously != https://myid/. So a new account for https:// <https:///> 
>> myid.fakeserver/
>> would be created on the RP, the original account is still safe.
>> Have you taken a look at OpenID implementations, afaik there are  some
>> who
>> do NOT do the redirect (or actually do it, but still take the  entered
>> URL
>> as identifier - those would be vulnerable).
>>
>> --
>> Lukas Rosenstock
>> Identity 2.0 Europe :: http://identity20.eu/
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>
>
> - - - - -
> Pat Patterson
> Federation Architect, Sun Microsystems, Inc.
> pat.patterson at sun.com - http://blogs.sun.com/superpat
> - - - - -
> Join OpenSSO today! http://opensso.dev.java.net/
> - - - - -
>
>
>
>
>

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general