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

Chris Drake <christopher@pobox.com> Thu, 19 October 2006 18:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaczs-0003VD-9z; Thu, 19 Oct 2006 14:52:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaczq-0003V8-VM for dix@ietf.org; Thu, 19 Oct 2006 14:52:02 -0400
Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaczo-0007Aq-OJ for dix@ietf.org; Thu, 19 Oct 2006 14:52:02 -0400
Received: from GRUNT (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k9JIpmeg018899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 18:51:49 GMT
Date: Thu, 19 Oct 2006 18:52:01 +1000
From: Chris Drake <christopher@pobox.com>
X-Priority: 3 (Normal)
Message-ID: <927247889.20061019185201@pobox.com>
To: Dick Hardt <dick@sxip.com>
Subject: Re[4]: [dix] Re: Gathering requirements for in-browser OpenID support
In-Reply-To: <1272B7BB-A670-4F00-A482-2AAE6AFAE5FC@sxip.com>
References: <000d01c6f39d$3a1f4260$d27d11ac@AMSOFTWachob> <1272B7BB-A670-4F00-A482-2AAE6AFAE5FC@sxip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 1.4 (+)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Cc: 'Digital Identity Exchange' <dix@ietf.org>, public-usable-authentication@w3.org, Gabe Wachob <gabe.wachob@amsoft.net>, general@openid.net
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org

Dick: Sounds like you've got a cool extension for OpenID.
Andy: We've seen and congratulate you on yours
Myself: I've got one as well
Here's a list with a dozen or more folks with similar:-
public-usable-authentication@w3.org

SO - technology that takes AWAY from the RP the opportunity to
initiate the OpenID login is a good way to safely prevent MITM
attacks - the only thing that remains is to nut out exactly how we
want to achieve this.

We need...
1. A way for a software agent to recognize an RP (and hence take the
   user to their real chosen IdP with chrome switched on etc)
2. A way for an IdP to initiate the login with the RP

How shall we all agree to handle this?  Who wants to write it up?
This seems like a simple tweak to the existing "OpenIDHTTPAuth"
extension, or even the "Bare Request" proposal.  I think we should
maybe unify all this into a single proposal - does that sounds
sensible?

My proposal is:
RP's login page MUST contain
<link rel="openid.entry" href="https://my.rp.com/openid/entry.cgi">


This solves 1 & 2 since agents can tell immediately that this is an
OpenID 2.0 enabled page (without the overhead of fetching yadis
documents etc), and at the same time find out how to kick the login
process off.  For *me* - this is sufficient.  Dick? Andy? I'm guessing
you need something extra - maybe a flag so you know whether or not the
user is already logged in?, or whether the page currently displayed is
actually requesting that a new login takes place?, or perhaps some
info about which identity a user selected to be logged in with: you
guys know your own chrome ideas best - do you need this, or anything
else?

Kind Regards,
Chris Drake


Friday, October 20, 2006, 2:45:23 AM, you wrote:

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

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

DH> -- Dick

DH> 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@openid.net [mailto:general- 
>>> bounces@openid.net] On
>>> Behalf Of Chris Drake
>>> Sent: Thursday, October 19, 2006 9:35 AM
>>> To: Dick Hardt
>>> Cc: Digital Identity Exchange; general@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@openid.net
>>>>> http://openid.net/mailman/listinfo/general
>>>>>
>>>>>
>>>
>>> DH> _______________________________________________
>>> DH> general mailing list
>>> DH> general@openid.net
>>> DH> http://openid.net/mailman/listinfo/general
>>>
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general@openid.net
>>> http://openid.net/mailman/listinfo/general
>>
>>




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