BOF Request: WARP - Web Authentication Resistant to Phishing

[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 <hardiequalcomm.com>

     Lisa Dusseault <lisaosafoundation.org>

Applications Area Advisor:

     Lisa Dusseault <lisaosafoundation.org>
Mailing Lists:

   General Discussion: ietf-http-authlists.osafoundation.org
   To Subscribe: ietf-http-auth-requstlists.osafoundation.org
   In Body: In Body: subscribe
   Archive: http://w
ww.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-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

Hello Sam,

I read your webauth-phishing draft. I thought it explored
the phishing
problem space really well.

Your BOF request below seems to go further in scope though
and
overlaps with what the DIX group have been working on. I'm
going
to work through your text calling out the bits where the
scope of DIX
and WARP appear to overlap.

[A quick aside. I just published some updated DIX drafts
today...
Use Cases, Protocol, and Assertion. They're all available
here:
http://dixs.org/index.php/DIX_Protocol_Internet_Drafts
]

On 23-May-06, at 2:34 PM, Sam Hartman wrote:

>    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.

This is a good thing. With DIX we chose for the actual
authentication
of the user to be out of scope. We just focused on how the
resultant
authentication assertion would be moved from the Identity
Provider
to the Relying Party. (To use SAML terminology.)

> The
>    first problem is  that users must remember and
maintain passwords
>    for each HTTP service they use.

The way I'm reading this I think this goes beyond the scope
of  
authenticating
the user... perhaps towards identifying the user. In DIX we
enable  
third-party
authentication and identify the user with an identifier (a
URI...  
typically a URL).

> 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.

Is this in the scope of the IETF though... to provide UI
requirements...
to be met by the W3C?

>    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.

In DIX we term this the Identity Agent, which can be a
Website or
an Application.

What kinds of 'assertions about identity' do you mean?
I'd assumed
your identity provider would only be generating
authentication
assertions. In DIX we support both self asserted and
third-party
attribute value assertions. Note that that's not just from
the Identity
Provider, but from other Service Providers authoritative for
some
attribute of the user.

And to what kinds of third parties?  Thus far I'd assumed
that the
only parties involved were the User Agent and the Identity
Provider.
I think these are the 'HTTP services' above. Which in DIX
is a
Service Provider that consumes the attributes and assertions
from
the Identity Agent. Is this what you mean? This bit clearly
overlaps
with DIX.

> 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.

This sounds very much like DIX, and Identity 2.0 in
general... but
doesn't cover all of Kim's Laws of Identity. You could
just reference
that, but I'm concerned you're trying to take on the whole
thing,
rather than just tackling a more secure way of
authenticating the
user.

>    WARP needs to support mobile users,

'Mobile' equals 'cell phone' to me... a european thing
perhaps.
Maybe there's a better word, but I can't think of one.

> including users that use
>    HTTP services from computers they have never used
before.  WARP
>    must not require per-service or
per-identity-provider
>    configuration.

I don't understand that statement. WARP can be deployed
without
changing any service or IdP code/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.

That's all good.

> It is
>    desirable that WARP be able to carry assertions
about identity such
>    as Security Assertion Markup Language assertions.

But, is this DIX again. What are the assertions about and
where are
the coming from and going to. I'm suspecting they're any
assertion and
they're coming from the IdP to the SP. DIX covers that with
more
flexibility... in that roles of the IdP are separated out.

>    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

That's good.

> and
>    protocol for the interaction between the identity
provider and
>    website.

I think this is DIX...

>     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.

I'm not sure how this will work in practice. I'd image the
W3C would
want to define their own UI/HTML requirements... but I'm
sure they'd
welcome input if the group generates some requirements as a
side-effect of the work.

> 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.

I read this as WARP does 'authentication resistant to
phishing', and
I don't think that covers a protocol from the identity
provider to the
website.

> * A proposed standard describing how an identity is
registered  with
>   an identity provider or website.

What does that mean? Maybe I just need more detail. But why
an
'or' in 'identity provider or website'...

In DIX a User Identifier is either assigned by the Identity
Agent, or
the user delegates authentication of an existing URL to an
Identity
Agent. And a Service Provider has a range of options over
whether
the User needs to identify themselves or not. There are
privacy
benefits to the SP being able to offer a service without
actually
having to create an 'account'.

> * A proposed standard describing how an identity
associated with a
>   user is linked to an HTTP service's concept of an
account.

Sounds much like the 'or website' bit above. But again...
DIX
does this... and is set up so that you don't need to.

In summary:

I think there's lots of value in WARP for dealing with
authentication
of the user to the identity provider... but if you go beyond
that from
the identity provider to the website then you're coving the
scope
of DIX... which in-my-not-so-humble-opinion has thought
through
and dealt with all these issues already and more besides.

I think that if the scope of the work can be tightened up
and there
are people interested in working on this that it'll be a
great
complement to the DIX work.

John
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

Hi, John.  Thanks for the new drafts.  I especially look
forward to
the new use cases draft and will sit down to read that after
finishing
this reply.

I do agree there is significant overlap; my interest in this
area was
more or less directly motivated by the DIX bof and
evaluating SXIP,
Infocard and other solutions for a talk I gave at a
conference.



I think we view the requirements somewhat differently or at
least view
what requirements need to be solved when somewhat
differently.

I'm OK with a solution that supports situations where I
have a single
alegidly unique identifier today but that can transition to
more
complex forms of identity claims in the future.  You seem to
want sets
of identity claims today.

I'm much more interested in reusing existing security
technology and
am not interested in working on entirely new protocols. 
(And I do see
this as a security problem which may also be a difference in
how we
come at this.)


I consider requirements related to binding things together
at multiple
levels (4.4 in my draft) really critical to forward progress
on
phishing.  A lot of people disagree with me.  One on one I
have been
able to convince people that I'm right, but the text in the
current
section 4.4 clearly does not stand on its own and needs
significant
revision.

Finally, I think it critical that whatever solution we have
here needs
to work both with non-web HTTP applications (atompub,
caldav, webdav,
deltav) and with non-HTTP applications.  I'd hate to see
people pushed
towards HTTP as a substrate to get better identity
management.

Needless to say my vision of the solution space is different
because I
view these requirements differently.


I am working on a specific solution proposal to demonstrate
that what
I want to do can be accomplished with incremental changes to
existing
technology.


--Sam

_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

On 2-Jun-06, at 8:01 AM, Sam Hartman wrote:

> I think we view the requirements somewhat differently
or at least view
> what requirements need to be solved when somewhat
differently.

Yes, that may well be the case. We're coming at this from a
different
angle than you.

> I'm OK with a solution that supports situations where
I have a single
> alegidly unique identifier today

I'm not sure if you're saying this but... DIX does not
impose any
specific number of identifiers on a user. They can have as
many
as they choose to have, from 0 to infinity.

> but that can transition to more
> complex forms of identity claims in the future.  You
seem to want sets
> of identity claims today.

I find the 'claim' term to be a bit ambiguous, so try to
avoid it.  
I'm not
sure how claims relate to identifiers in your comment above.

The DIX protocol draft specifies how the an attribute value
assertion can be moved between parties... and the assertion
draft shows how those attribute value assertions could
actually
be third party attested attribute value assertions.

The benefits are that websites that use common property
names
will get more data of better quality and users won't have
to deal
with tedious user registration forms.... And... if we can
move
around third party assertions (Beth>21) then we have a
safer
more productive internet.

> I'm much more interested in reusing existing security
technology and
> am not interested in working on entirely new protocols.

Well, we are too. Hence the reuse of SAML/HTML/HTTP/HMAC,
etc.
We're just bringing the bits together in such a way that
the barrier
to adoption (the really big problem) can be as low as
possible.

> (And I do see
> this as a security problem which may also be a
difference in how we
> come at this.)

Yes, we're coming at this from a slightly different
angle... not that
security isn't important, but we feel that we can provide
real value
with just enough security... and show a roadmap of how
people
can move up to more security when they need it.

> I consider requirements related to binding things
together at multiple
> levels (4.4 in my draft) really critical to forward
progress on
> phishing.  A lot of people disagree with me.  One on
one I have been
> able to convince people that I'm right, but the text
in the current
> section 4.4 clearly does not stand on its own and needs
significant
> revision.

I agree with you.

> Finally, I think it critical that whatever solution we
have here needs
> to work both with non-web HTTP applications (atompub,
caldav, webdav,
> deltav) and with non-HTTP applications.  I'd hate to
see people pushed
> towards HTTP as a substrate to get better identity
management.

I agree too.

I think the DIX messages could be mapped onto other
protocols, or
pushed down into the stack. Our approach though has been to
try
to avoid changing any code and any user behaviour. Not easy.

> Needless to say my vision of the solution space is
different because I
> view these requirements differently.

Yes.

> I am working on a specific solution proposal to
demonstrate that what
> I want to do can be accomplished with incremental
changes to existing
> technology.

I'm looking forward to reading that. I hope you get buy in
for  
solving the
secure user authentication problem.

John

_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

>>>>> "John" == John Merrells
<merrellssxip.com> writes:

    John> I'm not sure if you're saying this but... DIX
does not
    John> impose any specific number of identifiers on a
user. They
    John> can have as many as they choose to have, from 0
to infinity.

No, but dix does support transporting more than one claim
and does
support claims that are not identifiers.

I don't view doing so as a requirement.

    >> but that can transition to more complex forms
of identity
    >> claims in the future.  You seem to want sets of
identity claims
    >> today.

    John> I find the 'claim' term to be a bit
ambiguous, so try to
    John> avoid it.  I'm not sure how claims relate to
identifiers in
    John> your comment above.

I use the terms claim, identity, subject and relying party
as they are used in the Laws of Identity paper.

An identifier is a claim that is alegidly unique; email
addresses are
viewed by some as identifiers.  Email addresses *are* the
identifier
within the namespace of amazon.com identifiers as an
example.

--Sam
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth