Re: [dix] Agenda bashing

Eric Rescorla <ekr@networkresonance.com> Mon, 03 July 2006 17:17 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS3M-0002EM-Jf; Mon, 03 Jul 2006 13:17:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS3L-0002EH-7p for dix@ietf.org; Mon, 03 Jul 2006 13:17:43 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxS3J-0003xw-Ug for dix@ietf.org; Mon, 03 Jul 2006 13:17:43 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id A182A222425 for <dix@ietf.org>; Mon, 3 Jul 2006 10:25:50 -0700 (PDT)
To: Digital Identity Exchange <dix@ietf.org>
Subject: Re: [dix] Agenda bashing
In-reply-to: Your message of "Mon, 03 Jul 2006 09:27:20 +0200." <44A8C6D8.9010901@cisco.com>
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Mon, 03 Jul 2006 10:17:41 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060703172550.A182A222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
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

Eliot Lear <lear@cisco.com> wrote:
> Pete,
> > So, from the conversation so far, these are the architectural/protocol
> > issues I think need discussing at the BOF:
> >
> > - Discussion of the scope and number of the mechanisms. There seem to
> > be desires for (1) the ability for the user to identify to the server
> > (probably authenticating, preventing phishing as much as possible),
> > (2) the ability to transfer user attributes to the server, (3) the
> > ability to store user attributes remotely, and (4) the ability for a
> > 3rd-party to warrant user attribute claims.
> 
> On point (1) in order to fix phishing it is the server that must
> properly authenticate to the user (e.g., other way round).

That's *one* way to attack phishing (at least the current form).
There are others (cf. PwdHash)

-Ekr
 


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