Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements

Dick Hardt <dick@sxip.com> Fri, 07 July 2006 04:32 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyi1T-0005bM-Fu; Fri, 07 Jul 2006 00:32:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyi1R-0005bH-Vq for dix@ietf.org; Fri, 07 Jul 2006 00:32:57 -0400
Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyi1Q-0000mi-Jf for dix@ietf.org; Fri, 07 Jul 2006 00:32:57 -0400
Received: from [192.168.1.105] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k674WsQp008187 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 6 Jul 2006 21:32:54 -0700 (PDT) (envelope-from dick@sxip.com)
In-Reply-To: <tslac7ma4o4.fsf@cz.mit.edu>
References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> <1b587cab0606240923sd7f435ds7fbf1aeecf2b304f@mail.google.com> <E2067EC0-B18E-433B-940C-BE30463396AA@sxip.com> <tslac7ma4o4.fsf@cz.mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <4C91C488-0D77-4204-A0F0-0005D0691F19@sxip.com>
Content-Transfer-Encoding: 7bit
From: Dick Hardt <dick@sxip.com>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Thu, 06 Jul 2006 21:32:53 -0700
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com
X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: Digital Identity Exchange <dix@ietf.org>, ietf-http-auth@lists.osafoundation.org
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

On 6-Jul-06, at 12:56 PM, Sam Hartman wrote:

>>>>>> "Dick" == Dick Hardt <dick@sxip.com> writes:
>
>     Dick> Agreed. My point is that it is much easier to solve it in
>     Dick> one place then on all sites. The IdP can become a
>     Dick> combination of client side and server side code to deal much
>     Dick> more effectively with the phishing issue. It is unreasonable
>     Dick> for every site to do that.
>
> I'm missing something here.  Long term, it seems like all the clients
> are going to need to change so that they can interact with the new
> IDPs.  Long term, the servers are definitely going to need to change
> so they can accept information from the IDPs.  I don't see why it is
> unreasonable to solve this on all sites long-term.  In fact, I believe
> we're going to have to in order to deal with my requirement 4.4
> (mutual authentication).  And yes, I think that requirement is really
> important because without it, you don't have assurance that you aren't
> giving personal information to the wrong party--you don't have
> assurance that you aren't being phished.

I'll see if I can clarify:

1) Most sites are not targeted by phishers today, and unlikely to be  
targeted in the future, so they should not be forced to put in  
technology for resolving phishing.

2) Currently the user has NO trusted site or client and is easily  
phished. Once the user has one trusted software system, then that  
system can more easily determine the identity of other sites. In  
other words, the user will not have to build up the full assurance  
stack with each site, the user can leverage something they already  
trust to assist in making the trust decision.

>
>
> I think the question we should be asking in this space is whether
> there is something we can do in short-to-medium term that has
> acceptable intermediate security.  A quetion you're presumably
> interested in is whether DIX or something close to it would be such a
> something.

Agree that we need to work on a a short-to-medium term improvement.
Phishing, like most complex problems, likely requires a combination  
of things to minimize.
Per my comments above, once the user has a trusted identity agent,  
DIX could be used by the user to interact in a more trusted manner  
with other sites, with a lower burden on those sites.

>
> I don't know what my answer to that question is.  I hope to have
> decided by the end of the BOF.

I think the BOF is going to be interesting -- uncertain on what will  
be answered. :)

-- Dick

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