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
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/general
DH> _______________________________________________
DH> general mailing list
DH> [EMAIL PROTECTED]
DH> http://openid.net/mailman/listinfo/general
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
