Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support

[Dick Hardt <[e-mail]>]

Just to keep beating that dead horse some more, this demonstrates why  
*how* to solve the issue is out of scope, but that there is an issue  
MUST be in the spec. :-)

btw: that is a cool extension, but wait until you see ours! ;-)

-- Dick

On 19-Oct-06, at 9:40 AM, Gabe Wachob wrote:

> And not to beat a dead horse to a pulp, but the Ph-Off Firefox  
> extension
> from OOTao provides exactly this sort of trustable (based on SSL  
> certs)
> visual indicator that you are actually talking to your real OpenID  
> IDP. Its
> obviously an early iteration, but it *is* there and performs the  
> function
> adequately.
>
> http://chile.ootao.com/phoff/
>
> 	-Gabe
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:general- 
>> [e-mail]] On
>> Behalf Of Chris Drake
>> Sent: Thursday, October 19, 2006 9:35 AM
>> To: Dick Hardt
>> Cc: Digital Identity Exchange; [e-mail]
>> Subject: Re[2]: [dix] Re: Gathering requirements for in-browser  
>> OpenID
>> support
>>
>> Hi Dick,
>>
>> I disagree - the RP is *responsible* for directing the user to the
>> IdP;  This is the highest risk point of MITM attack.  OpenID MUST
>> include something to "enable" a "safe redirect" or browser-chrome
>> activation or whathaveyou.  Granted - chrome etc shouldn't be in the
>> spec, but *enabling* it for the future MUST.
>>
>> Kind Regards,
>> Chris Drake
>>
>>
>> Thursday, October 19, 2006, 1:56:05 PM, you wrote:
>>
>> DH> The MITM attack vector resolution is out of scope of OpenID
>> DH> Authentication as it is a ceremony between the user and the  
>> IdP. The
>> DH> user and IdP need to know they are talking directly to each  
>> other.
>>
>> DH> -- Dick
>>
>> DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote:
>>
>>>>> It is vulnerable to a man in the middle attack - the RP,  
>>>>> instead of
>>>>> redirecting to the IdP redirects to itself or some other site in
>>>>> cahoots, then proxies the conversation between the user and the  
>>>>> IdP
>>>>> thereby compromising the users (global) credentials as they pass
>>>>> through.
>>>>
>>>> Right, we've known about this for quite some time unfortunately
>>>> there hasn't
>>>> be a particularly easy solution to it and I classify this as one of
>>>> those
>>>> "The Internet Sucks" problems.  I'm not saying we shouldn't/
>>>> couldn't do
>>>> anything about it I just think the right solution that mixes
>>>> ease-of-implementation and user need hasn't been found yet.
>>>>
>>>>> There really needs to be user-agent support to avoid that - either
>>>>> something CardSpace like, or browser plugin that only ever  
>>>>> presents a
>>>>> pre-authenticated user.
>>>>
>>>> I think we're headed in this direction.  However, we have to crawl
>>>> before we
>>>> can walk.  At least solving a big chunk of the use cases,  
>>>> getting some
>>>> momentum behind the platform and solving a specific problem for  
>>>> users
>>>> *today* is better than trying to build the perfect tool.  We can
>>>> talk and
>>>> talk on these lists but we really don't know how users are going to
>>>> use this
>>>> stuff (or abuse it for that matter) until its out there and working
>>>> in the
>>>> wild.
>>>>
>>>> I can't emphasize more the fact that with every passing day that we
>>>> don't
>>>> have OpenID v2.0 out the door, we're losing momentum from fixing
>>>> specific
>>>> user problems that are solved in the existing specification.
>>>>
>>>> - Scott
>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> [e-mail]
>>>> http://openid.net/mailman/listinfo/general
>>>>
>>>>
>>
>> DH> _______________________________________________
>> DH> general mailing list
>> DH> [e-mail]
>> DH> http://openid.net/mailman/listinfo/general
>>
>>
>>
>> _______________________________________________
>> general mailing list
>> [e-mail]
>> http://openid.net/mailman/listinfo/general
>
>


_______________________________________________
dix mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dix