[OpenID] Reconsidering http://openid different from https://openid

[George Fletcher]

Johnny Bufu wrote:
>
> On 19-Sep-07, at 7:07 AM, George Fletcher wrote:
>
>> But isn't that a choice of the RP?  The RP could allow the user to 
>> select an option that says that only https identifiers are allowed.  
>> That would protect the user from the attack of someone using an http 
>> identifier.  This could be the default option and the user could turn 
>> it off if they want.
>
> OpenID being user-centric, and the user being the "owner" of the 
> identifier, I'd say it should be the user's choice.
>
If the user selects that only HTTPS identifiers are to be used... how is 
the user not in control?  I agree that many users might not understand 
the difference, but the user choice doesn't have to be described at the 
technology level.  It could be like the IE "security slider".
> I can see two issues with what you're proposing:
> - how many users will have the knowledge to make the right choice when 
> prompted by the RP?
> - the user has no choice at those RPs who don't care about HTTP/HTTPS 
> differences, and don't prompt the user for making the choice.
>
> I agree the RPs should be allowed to decide authorization and 
> policies, but my feeling is that the protocol should put the user in 
> control over features that impact the security of the identifiers.
>
For those RPs that don't care, the user can always use whichever they 
want.  The user can always use a HTTPS identifier at all sites.  In 
fact, they may chose not to interact with any site that doesn't support 
an HTTPS identifier.

If we are taking a choice away, it is the choice to have two different 
accounts at an RP where the only difference is HTTP vs HTTPS.  Is that a 
bad choice to take away?
>
>> I agree that if an https identifier exists, then an http identifier 
>> with a different OP should not be allowed.
>
> How is an RP able to tell that a HTTPS identifier exists, when the 
> attacker presents the HTTP identifier for the first time to it, after 
> having compromised the DNS such that the HTTPS identifier is no longer 
> reachable?
You are right. It can't. It might try and do some resolution when it 
does receive a HTTPS identifier that matches an existing HTTP 
identifier.  This again could be an RP policy.  Due to association 
handles, the RP should know which OP authenticated the existing account 
identifier.  The RP could use that knowledge to "merge" or "block" the 
HTTPS based attempt.
>
>> It seems like it should be possible to "upgrade" an http to and https 
>> identifier (provided some criteria is met; e.g. the same OP is used 
>> for both identifiers?, the same association handle is used for both?).
>
> Yes, upgrading would be great if it can be made to work nicely.
So what is hindering the process from "working nicely"?  If the OP is 
the same, and the association handle is the same, then both are verified 
by the same OP.  I guess the only other "requirement" would be for the 
OP to make a statement that the two identifiers are really the same.

Of course, this would cause a problem if the user is running their own 
web site and wants to use a different OP for "secure" transactions vs 
"insecure" transactions. Meaning http://alice.personal.example resolves 
to one OP and https://alice.personal.example resolves to a more secure 
but different OP.  However, this is a small edge case and supporting it 
seems like it adds more complications than it solves.
>
>> However, if an https identifier exists (i.e. the user explicitly used 
>> an https identifier in the past) then an http identifier shouldn't be 
>> accepted.  If the user chose to use https at least once in the past, 
>> why would the RP want to allow the user to now use http for the same 
>> identifier?
>
> If I stop paying for a dedicated IP address and a certificate, I won't 
> be able to use http://my.blog.com/ as my (new) identifier at the RPs 
> where I've used https://my.blog.com/ ?
This I agree is a problem... but then your (new) http://my.blog.com 
would be a new identity at the RPs so you would have lost all your data 
anyway (in the current spec).  I believe what Johannes was proposing 
would allow you to actually get to your data at the RP. Though then you 
have the security/spoofing points you pointed out.

I guess I have to wonder, how many of the "mass market" consumers will 
run their own OP, or their own web site that they use as the OpenID.
>
>
> Johnny
>
>
Also, to be "secure" doesn't the whole delegation chain have to be over 
HTTPS?  If I have https://alice.personal.example and it delegates to 
http://op.example with an id of http://alice.op.example, wouldn't the 
same DNS spoofing hacks apply?

Thanks,
George

-- 
Chief Architect                   AIM:  gffletch
Identity Services                 Work: george.fletcher at corp.aol.com
AOL LLC                           Home: gffletch at aol.com
Mobile: +1-703-462-3494
Office: +1-703-265-2544           Blog: http://practicalid.blogspot.com