Hello.
I'd like to draw your attention te the following BOF proposal. Please
discuss on ietf-http-auth@xxxxxxxxx I'd appreciate comments and
indications of interest.
I'd also like to draw your attention to two resources besides the BOF proposal:
http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-May/000241.html
contains a better describption of what I think the BOF presentations
should cover.
http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-00.txt
contains my comments on anti-phishing requiremnts and I hope will be a
starting point for what it means for web authentication to be
resistant to phishing. I believe that similar requirements should
apply to other proposals including things in the DIX space.
--- Begin Message ---
[Sent to the ADs; comments very much appreciated.]
BOF Description:
At IETF 65, the DIX BOF demonstrated a consensus to work on a solution
to the problem that there are two many passwords for the web. This
BOF proposes to develop a authentication architecture for the web and
other HTTP-based applications using existing technology with at most
small changes necessary to improve deployability that addresses this
problem. One of the critical challenges facing the web today is the
problem of phishing, where users are directed to fraudulent websites
that request confidential information. Any solution to the phishing
problem will require UI changes in web browsers. However the HTTP
authentication architecture needs to work with these UI changes and
provide clear technical requirements for the security features
required from the UI.
Proposed Charter:
Web Authentication Resistant to Phishing (WARP)
Applications Area Director(s):
Ted Hardie <hardie@xxxxxxxxxxxx>
Lisa Dusseault <lisa@xxxxxxxxxxxxxxxxx>
Applications Area Advisor:
Lisa Dusseault <lisa@xxxxxxxxxxxxxxxxx>
Mailing Lists:
General Discussion: ietf-http-auth@xxxxxxxxxxxxxxxxxxxxxxx
To Subscribe: ietf-http-auth-requst@xxxxxxxxxxxxxxxxxxxxxxx
In Body: In Body: subscribe
Archive: http://www.imc.org/atom-syntax/mail-archive/
Description of Working Group:
WARP is chartered to develop a method for using existing
authentication technology to address two critical problems with
authentication for the web and other HTTP-using applications. The
first problem is that users must remember and maintain passwords
for each HTTP service they use. The second problem is that of
phishing. While browser UIs must change in order to combat the
problem of phishing, WARP must work with these UI changes and must
provide clear technical requirements for the security features
needed from authentication UI.
WARP will attack the problem of multiple passwords in two ways.
First, it will be safe from a security standpoint to use the same
password with multiple HTTP services. Second, WARP will support
the concept of an identity provider, which is a service that
clients can authenticate to and that can make assertions about
their identity to third parties. Employers authenticating their
employees to business partners, distributed communities that share
a concept of identity and services like Microsoft's Passport service
demonstrate the wide variety of identity providers. There will
never be a single identity that a user can use on the web: many
users would not choose to use the same identity in a work context
that they use personally; similarly business relationships and
policies will dictate what identities services can accept.
However WARP will support the concept of identity providers so
that when policies permit, users can minimize the number of
identities they use. WARP must support identity providers
associated with servers and should support identity providers that
have relationships with users.
WARP needs to support mobile users, including users that use
HTTP services from computers they have never used before. WARP
must not require per-service or per-identity-provider
configuration. While WARP is focused on passwords as that is
expected to be the primary means of authentication, WARP needs
to support other credentials including smart cards, one-time
passwords and zero-knowledge password protocols. It is
desirable that WARP be able to carry assertions about identity such
as Security Assertion Markup Language assertions.
The WARP working group will first write a problem statement and a
requirements draft describing what it means to produce an
authentication solution that is resistant to phishing. Then WARP
will choose a mandatory-to-implement authentication technology and
protocol for the interaction between the identity provider and
website.
WARP will coordinate with W3C in working on the UI implications of
phishing. WARP will not propose specific UI nor specific
extensions to HTML, although WARP may recommend requirements for
both as these requirements directly impact the security or
deployability of WARP.
Deliverables:
* Problem statement for WARP
* Requirements for authentication resistant to phishing
* WARP protocol document describing how an existing authentication
system is used to meet the requirements of WARP. This document
may specify mandatory to implement modes in addition to those
specified in the underlying system.
* A proposed standard describing how an identity is registered with
an identity provider or website.
* A proposed standard describing how an identity associated with a
user is linked to an HTTP service's concept of an account.
BOF Agenda (2.5 hour slot requested):
* Presentation on the multiple passwords problem (10 minutes)
* Presentation on phishing (30 minutes)
* Presentation arguing that existing technology is available (30
minutes)
* Description of Charter (10 minutes)
* Discussion
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-auth@xxxxxxxxxxxxxxxxx
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
--- End Message ---
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf