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

From: Troy Benjegerdes <[email-masked]>
Date: Wed, 18 Oct 2006 12:15:23 -0500

On Mon, Oct 16, 2006 at 12:31:48PM -0700, Scott Kveton wrote:
> Hey Rob,
>  
> > I'm trying to gather requirements for OpenID support. I think I have a
> > reasonable understanding of the draft, but part of the appeal of OpenID
> > is that it doesn't necessarily require browser vendors to do anything :)
> > 
> > I've seen the proposed 2617-style HTTP authentication scheme on the
> > wiki. What else could browser vendors do to make OpenID a smoother
> > experience for users?
> 
> As I posted on the Mozilla wiki:
> 
> http://wiki.mozilla.org/Firefox/Feature_Brainstorming#Identity
> 
> I'd love to see some anti-phishing mojo baked into the browser.  If the user
> could set their trusted IdP (or multiple as the case may be) in the browser
> and then have the browser do something obvious when the users is presented
> with an "untrusted" page asking for their password that would be great IMHO.

I think there needs to be more overlap between the people on the OpenID
list and people on the IETF DIX list... Both of these groups of people
seem to have similiar ideas, and different approaches. A real solution
to this distributed identity problem is going to involve both groups.

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

---

From: Pete Rowley <[email-masked]>
Date: Wed, 18 Oct 2006 10:49:54 -0700

> to this distributed identity problem is going to involve both groups.
If there is going to be a "mojo" in the browser then I think it ought to 
just take care of the authentication itself i.e. the site never gets an 
opportunity to be MITM because users appear to them to always be 
previously authenticated. I also think it _is_ a requirement that the 
browser vendors support this - right now you have to trust that the RP 
is a white hat.

-- 
Pete

---

From: Pete Rowley <[email-masked]>
Date: Wed, 18 Oct 2006 11:49:00 -0700

Mike Glover wrote:
> Pete-
>
>   Why do you have to trust the RP at all?  All the RP ever sees is an assertion that you control the identity URL that you provided. 
That is what the RP sees if they play along with the scheme.
>  Do you see a vulnerability that I'm missing?
>
>   
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.

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.

> -mike
>
> On Wed, 18 Oct 2006 10:49:54 -0700
> Pete Rowley <[email-masked]> wrote:
>  I also think it _is_ a requirement that the 
>   

-- 
Pete

---

From: Chris Drake <[email-masked]>
Date: Thu, 19 Oct 2006 12:20:27 +1000

Hi Scott,

All solutions for client-based MITM and phishing prevention can easily
be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.

We can then leave these people to build their tools and protection
howsoever they like, safe in the knowledge that when it's *done*,
there will be a range of new plugins that will immediately work with
all OpenID 2.0 enabled sites - and best of all - it does not have to
hold up the OpenID 2.0 development in the meantime.

The only thing we need to give to these tools is a way to get the
login process started - that is - OpenIDHTTPAuth: the downloaded
plugin needs to be able to get an entry point for the OpenID CGI code
on the web site.

-----------

Here is a copy of my vote to include the above proposal, which
contains more info abut it too:

Hi,

Why's this proposal "depreciated" ?
( http://www.lifewiki.net/openid/OpenIDProposals )

I'm casting my vote here:

+1 to [PROPOSAL] bare response / bare request

Besides the listed uses, it also allows IdPs to layer privacy and
delegation easily on top of OpenID, as well as permitting cool future
features (like letting a user change something at their IdP, and have
that change be "pushed out" to all relevant RPs).

This is a small and simple to implement "hook" which I believe will be
the dominating bit of OpenID protocol use in future.

Alternatively - if we can standardize a way for the OpenIDHTTPAuth
proposed extension to discover the RP's OpenID "entry point" [so as to
reliably eliminate the "optional" first step proposed here
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good
working alterative way to accommodate the "bare response" part that we
need.

So...

+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL
                       that's somehow available to scripts, plugins,
                       software agents that encounter OpenID login
                       pages.

                       Suggestion: (for OpenID-enabled login pages):-

  <link rel="openid.httpauth" href="http://my.rp.com/openid/blah.cgi">

-----------

Kind Regards,
Chris Drake

>> thereby compromising the users (global) credentials as they pass through.

SK> Right, we've known about this for quite some time unfortunately there hasn't
SK> be a particularly easy solution to it and I classify this as one of those
SK> "The Internet Sucks" problems.  I'm not saying we shouldn't/couldn't do
SK> anything about it I just think the right solution that mixes
SK> ease-of-implementation and user need hasn't been found yet.
 
>> something CardSpace like, or browser plugin that only ever presents a

SK> I think we're headed in this direction.  However, we have to crawl before we
SK> can walk.  At least solving a big chunk of the use cases, getting some
SK> momentum behind the platform and solving a specific problem for users
SK> *today* is better than trying to build the perfect tool.  We can talk and
SK> talk on these lists but we really don't know how users are going to use this
SK> stuff (or abuse it for that matter) until its out there and working in the
SK> wild.

SK> I can't emphasize more the fact that with every passing day that we don't
SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific
SK> user problems that are solved in the existing specification.

SK> - Scott

SK> _______________________________________________
SK> general mailing list
SK> [email-masked]
SK> http://openid.net/mailman/listinfo/general

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Oct 2006 20:56:05 -0700

The MITM attack vector resolution is out of scope of OpenID  
Authentication as it is a ceremony between the user and the IdP. The  
user and IdP need to know they are talking directly to each other.

-- Dick

On 18-Oct-06, at 1:07 PM, Scott Kveton wrote:

> 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.
>
> 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-masked]
> http://openid.net/mailman/listinfo/general
>
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Oct 2006 21:16:13 -0700

> to this distributed identity problem is going to involve both groups.

Hi Troy

All the DIX work was merged into the OpenID 2.0 work. I posted this  
Sept 11th:

	http://www1.ietf.org/mail-archive/web/dix/current/msg00863.html

-- Dick

---

From: Chris Drake <[email-masked]>
Date: Fri, 20 Oct 2006 02:35:24 +1000

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

>> user problems that are solved in the existing specification.

DH> _______________________________________________
DH> general mailing list
DH> [email-masked]
DH> http://openid.net/mailman/listinfo/general

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Oct 2006 09:43:31 -0700

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