[fwd] [Ietf-http-auth] BOF proposal: making the web safe and easy for Eliot's father (from: hartmans-ietf@MIT.EDU)

Archiving; it may be worth checking back on this one during the
5 June W3C/IETF liaison call.

Regards,
-- 
Thomas Roessler, W3C   <tlr@w3.org>






----- Forwarded message from Sam Hartman <hartmans-ietf@MIT.EDU> -----

From: Sam Hartman <hartmans-ietf@MIT.EDU>
To: ietf-http-auth@lists.osafoundation.org
Cc: lear@cisco.com
Date: Mon, 15 May 2006 15:25:44 -0400
Subject: [Ietf-http-auth] BOF proposal: making the web safe and easy for
	Eliot's father
List-Id: ietf-http-auth.osafoundation.org



Hi.  I'm putting together a proposal for a BOF at IETF 66 of
phishing-safe identity for the web an other HTTP applications.

I hope to have both a problem statement draft and a requirements draft
about avoiding phishing attacks.  These drafts will hopefully be done
by May 22.  I'd appreciate it if people would indicate any interest
they may have in this BOF.

During the DIX BOF at IETF 65, Eliot Lear tried to cut through a
complicated discussion of web identity and propose a smaller subset of
the problem for us to solve.  he wants us to create a way for his dad
to securely access websites without having multiple passwords all over
the place.  We spent some time trying to figure out the
characteristics of Eliot's dad.  Eliot's dad and users like him use
the web from many computers, including computers they own, computers
in businesses and computers made available to the public they have
never used before.  They don't understand certificates, are not going
to be good at checking URL bars and certainly will not read the source
of a page before logging into a website.  I propose that we try and
make the web safe and easy to use for Eliot's dad.

To do this, I think it is critical that we present a coherent proposal
for web identity management at the next IETF in response to DIX.
There are two messages I'd like to send.  The first is that we need to
deal with phishing.  The second message we want to send is that
reinventing a new authentication framework is really hard and that we
have technology that should be reused.


So, here's my idea for a set of BOF presentations at IETF 66.

First, we start out by describing the Eliot's father problem.  You
want to be able to use a smaller number of passwords; sometimes you
only want to be able to use them from one computer, sometimes you want
to be able to use them anywhere.  Sometimes you provide the identity,
sometimes the server provides the identity.  A third party can provide
the identity, but they need to be associated with either you or the
site you are trying to connect to in some way.  Long term you need to
support more than passwords, but passwords are the important thing
today.


Then, we get someone to describe the phishing problem.  You must never
send a token that can be used by the website to impersonate you to
third parties: if the website is an attacker then they can become you
on the real site.  Here is where Infocard, DIX, SAML bearer assertions
all fail.  Browsers must change; cite w3c auth workshop.  You need to
have some form of dynamic trusted UI.  Take a look at
http://www.w3.org/2005/Security/usability-ws/papers/37-google/ as a
draft of some requirements in this space.

 show that many situations require a trusted party acting as an
identity provider.  Discuss how difficult designing trusted third
parties are and getting them deployed.  Point out that DIX and
Infocard are new trusted third parties authentication systems.  Desire
to use technology that can scale to Internet-wide deployment.
Establish following requirements for trusted third party:

* Must support smart cards, SRP-like mechanisms, normal passwords, one
  time passwords, anything someone might use.

* Must work with more than the web.  Identity assertions need to
  travel from the web into back office systems even if those systems
do not fully trust the web site as an authorizer.

* Desire to share authentication with email, IM and other services.

Show how much of these requirements we can meet today with existing
technology to argue that using existing technology is plausible.  I
propose showing this based on Kerberos.  Personally I think that
Kerberos has a lot to offer in this space, but the important thing is
to demonstrate that existing authentication frameworks are worth
reusing, not to prematurely push a particular solution.


I believe that if you were trying to show Kerberos in this space you
could demo Kerberos working to enroll an identity in a third party
identity provider.  Demo using that identity to access a website from
a second computer that knows nothing about the identity.  Truthfully
be able to assert that neither computer needed prior configuration
either about the identity provider or the website.  


Proposed deliverables of a working group:


* Requirements document describing the Eliot's father problem.

* Requirements document describing what it means to have web identity
  that is reasonably safe from phishing.
* Guidance to W3C on what information browsers will need from HTML to
  provide a good user experience for authentication.

* An architecture document describing how the solution fits together.
  Unlike most IETF protocols we need to focus on UI issues as well as
  the low level protocol issues.  While we may want the UI issues
  handled in W3C, I think it critical that we be working on the
  architecture in parallel to the UI issues so that requirements can
  filter in both directions.


  * Technical solution to binding a user-provided identity to a
website.  In DIX terms, a technical solution for telling a website
about a homesite.  This is more challenging in an environment where
you care about phishing.

* Technical solution for enrolling a user in  a identity
  provider--again harder than a form asking for your new password if
  you care about phishing.

* A GAP analysis of usability issues in the chosen authentication
  technology.  While I think existing technologies such as Kerberos
  are reusable, there is work to do.  In the case of Kerberos,
  firewall friendly transport and some realm configuration issues.  In
  the case of X.509, lots of enrollment problems and lots of browser
  UI issues.


--Sam
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-auth@osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

----- End forwarded message -----

Received on Tuesday, 16 May 2006 19:06:28 UTC