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

[Dick Hardt]

Hi Chris

I agree this is a risk point, but that it belongs in the security  
considerations that the IdP must ensure it is talking directly to the  
user. There is no reason why there needs to be a standard way of  
solving this though. One IdP may do it one way, another a different  
way. It could also be solved by the browser. It is out of scope of  
the specification ust like how the user authenticates to the IdP is  
out of scope.

If you have an idea on something that the RP would do, I'd love to  
hear it, and then it would be in scope.

-- Dick

On 19-Oct-06, at 9:35 AM, Chris Drake wrote:

> 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
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>
> DH> _______________________________________________
> DH> general mailing list
> DH> general at openid.net
> DH> http://openid.net/mailman/listinfo/general
>
>
>
>