Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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: general-bounces at openid.net [mailto:general- bounces at openid.net] On
Behalf Of Chris Drake
Sent: Thursday, October 19, 2006 9:35 AM
To: Dick Hardt
Cc: Digital Identity Exchange; general at openid.net
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
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



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




_______________________________________________
dix mailing list
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.