Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 08:58:23 -0700

1. This is not principally a protocol problem but rather a UI problem.
   The protocol problems are generally well understood. If the UI
   problems are solved, nearly any protocol will work. In particular,
   there have been a number of published designs [1] [2] that have mostly
   adequate (though not perfect) protocols, though without complete
   solutions to the UI problem. Indeed, a slightly different design
   for Digest (in which the absolute URI was hashed) combined with
   a secure UI would pretty much defeat current phishing attacks.

2. It's really important to distinguish between different levels of
   attack.  Conventional phishing attacks rely on generating a reference
   which appears to be valid but actually points at the attacker's
   site. (This is why SSL/TLS doesn't help much).

   But this is different from attacks in which the attacker actually
   intercepts the user's communication. In these settings, some sort
   of cryptographic protection for the channel (a la HTTPS) or the
   messages (a la S-HTTP) must be provided.

   On a similar note, in current phishing attacks the attacker 
   attempts to directly extract the user's password. If C-R mechanisms
   are used, a dictionary attack is natural. I assume that's why
   you wave in the direction of ZKPPs in S 4.3. However, it's 
   worth asking whether we would be satisified with a system that
   was only partly strengthened against dictionary attacks (see [2]
   again).

3. The term "password equivalent" is a bit confusing. See draft-iab-auth-mech
   for some discussion of strong versus weak password equivalent.

4. I agree that server authentication is a good, but I'm not totally
   sold that it's a necessity. It's principally important when you're
   changing credentials, but even then with a properly designed scheme
   where the server has a weakly password equivalent credential, the
   exposure is fairly limited. A standard practice is to hash the
   hostname into the password hash stored on the server.

5. You write:

   The risk of dictionary attack is always a significant concern for
   password systems.  Users can (but typically do not) minimize this
   risk by choosing long, hard to guess phrases for passwords.  The risk
   can be removed once a password is already established by using a
   zero-knowledge password protocol.

This is not strictly true. A ZKPP removes the risk of offline dictionary
attack, but not online attack. These attacks do still get mounted [3]

   However the risk of dictionary
   attack is always present when setting up a new password  or changing
   a password.  Minimizing the number of services that use the same
   password and being extra careful to make sure the right server is
   used when establishing a password can minimize this risk.

It's not clear to me that this helps, unless you're assuming a ZKPP.
If the attacker can capture a hashed password or C-R handshake (which
a phisher can generally force in non-ZKPP cases) then they can mount an
offline dictionary attack anyway. Consider a typical design where the user has
a master password P and then generates per-site passwords as
H(Site-Name || P). In the C-R handshake, the user provides:

H(challenge || H(Site-Name || P).

Dictionary attacking this isn't significantly harder than dictionary attacking
H(Site-Name || P).

6. You write:

   In situations where there is an identity provider that is separate
   from the website as a relying party, additional requirements are
   needed.  The identity provider MUST verify that the website  is a
   valid relying party for this identity.  Some identity providers will
   allow anyone to accept their identity.  However particularly for
   financial institutions and large service providers it will be common
   that only authorized business partners will be able to accept the
   identity.  The confirmation that the the relying party is such a
   business partner  will often be a significant part of the value
   provided by the identity provider, so it is important that the
   protocol enable this.  The relying party MUST prove its identity is
   the one expected by the identity provider.

I agree that this is is a likely business goal for identity providers,
but it's not required for protection against phishing. Really, there
are two interests here:

1. To prove to the user (the guy with the browser) that he is doing
   business with an "authorized" provider.
2. To allow the identity provider to extract rents from the relying
   parties.

Neither strictly requires the relying party authenticating to the
identity provider during the transaction. The first can obviously
done by issueing the relying party a long-term credential. The
second can be done by encrypting the credential under the relying
party's key. You don't necessarily need the identity provider to
receive a proof that the relying party was able to decrypt it.

-Ekr

[1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell
Stronger Password Authentication Using Browser Extensions.
Proceedings of the 14th Usenix Security Symposium, 2005.

[2] Halderman, J. A., Waters, B., and Felten, E. W. 2005. A convenient
method for securely managing passwords. In Proceedings of the 14th
international Conference on World Wide Web (Chiba, Japan, May 10 - 14,
2005). WWW '05. ACM Press, New York, NY, 471-479. DOI=
http://doi.acm.org/10.1145/1060745.1060815
      
[3] http://www.whitedust.net/article/27/Recent%20SSH%20Brute-Force%20Attacks/

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 May 2006 11:14:57 -0500

> 1. This is not principally a protocol problem but rather a UI problem.

I've not read Sam's I-D yet, but he did present to me last week, so
perhaps I can comment.

This is not just a UI problem, and there are several problems.

Sam seems to assume that enrolment is not the problem he should be
solving, but that it is already solved (even if it isn't).

Given this assumption then the principal problem is about tying the UI
and the protocols.  And I couldn't agree more.

Now, that pesky enrolment problem...  Except it's not quite so pesky; it
requires that the user not get confused (conned) once [per-site?], at
enrolment.

Beyond that, users don't want to have to enroll every time, at least not
with passwords.  But now I must go read Sam's I-D.

>    a secure UI would pretty much defeat current phishing attacks.

So, the protocols and the [secure] UI have to be "combined" -- can you
expand on this?  How is this not what Sam proposes?  Or are you two in
violent agreement?  :)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 May 2006 11:18:31 -0500

On Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre wrote:
> On 5/22/06, Eric Rescorla <[email-masked]> wrote:
> >  solutions to the UI problem.
> 
> One aspect of Sam's document that concerned me was the section on
> possible UI solutions. The requirements around spoofing seem directly
> opposed to the branding and usage patterns that web authors require.
> HTTP authentication currently presents a modal dialog with no design
> control, and this is a significant reason most sites opt for form
> controls.

Sam wants to put control over the UI in the web site's authors' hands.

But he wants this UI tied intimately to a new browser function that is
tied intimately to authentication protocols.

> Roy has previously mentioned that 401 Unauthorized responses should be
> displayed to the user. This would allow a site to embed a new type of
> form control for authentication purposes... but as I mentioned above,
> this intermingling could increase the risk of spoofing.

As Sam says: the browser must change.  There are problems we cannot
solve using nothing more than HTML, HTTP/HTTPS and existing browser
functionality.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 09:24:29 -0700

> This is not just a UI problem, and there are several problems.

I agree that there are several problems, but only some subset of those
problems are the "phishing" problem.

> expand on this? 

This is all pretty much laid out in the PwdHash and Felten papers.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 10:12:49 -0700

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>
>     Eric> This is all pretty much laid out in the PwdHash and Felten
>     Eric> papers.
>
> Sure.  My goal here is to describe a series of reasonably obvious
> requirements so that we can evaluate solutions because we'e seen some
> solutions like the ones you cite that meet a large number of these
> conditions and we've seen other solutions that do not.

This was in response to Nico asking:

 "So, the protocols and the [secure] UI have to be "combined" -- can you
 expand on this? "

> I find specific requirements useful in such situations.

Right. I indicated in my message, I'm not sure this draft dissects the
reqts correctly.

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 May 2006 12:21:09 -0500

>  "So, the protocols and the [secure] UI have to be "combined" -- can you

I asked two other questions in the same paragraph.  All three were aimed
at rooting out whether you happen to be in broad agreement with Sam's
position.  This particular question was aimed at understanding in what
respects your view differs from Sam's.  Pointing me at these papers
doesn't answer my question :)

But I'll score you two as being in broad agreement anyways (if nothing
else it's a safe bet).

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 10:25:42 -0700

Sam Hartman <[email-masked]> writes:

>     Eric> Right. I indicated in my message, I'm not sure this draft
>     Eric> dissects the reqts correctly.
>
> Understood. However all your criticisms to date have been rather
> minor.

Hmm... I didn't mean to give that impression. I certainly don't
think the "it's all about UI" point is minor.

In any case, I'll try to write up a more substantial review when
I have some more time, probably in the next week or so.

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 10:28:08 -0400

Hi folks.

One thing that concerns me thinking about authentication and identity
on the web is how to make sure that we don't make phishing worse and
in fact to make sure that we significantly improve it.  I've written a
draft on requirements for web authentication solutions to minimize
phishing risk.  That draft has been submitted but is not yet in the ID
repository so I'm attaching a copy.

I believe that DIX, my proposal or anything else in this space needs
to meet these requirements or requirements that are very similar.
Some of these requirements apply to the protocol used between an
identity provider and a subject to authenticate to the identity
provider.  Other requirements apply to protocols used to carry
authentication or identity information between identity providers and
relying parties.  Some requirements apply to both.  The line is a bit
blurry in some solutions.

Comments are welcome.

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 22 May 2006 12:14:51 -0400

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:53:00 -0400

>>  Understood. However all your criticisms to date have been
    >> rather minor.

    Eric> Hmm... I didn't mean to give that impression. I certainly
    Eric> don't think the "it's all about UI" point is minor.

I am not sure whether it is minor.  I think we are in broad agreement
that the interesting work in this space must involve the UI and is not
principally a protocol problem.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:10:56 -0400

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 22 May 2006 12:14:51 -0400

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:53:00 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:10:56 -0400

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 22 May 2006 12:14:51 -0400

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:53:00 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:10:56 -0400

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:22:37 -0400

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 12:57:28 -0400

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> 1. This is not principally a protocol problem but rather a
    Eric> UI problem.  The protocol problems are generally well
    Eric> understood. If the UI problems are solved, nearly any
    Eric> protocol will work. In particular, there have been a number
    Eric> of published designs [1] [2] that have mostly adequate
    Eric> (though not perfect) protocols, though without complete

I agree with you that this is not principally a protocol problem.  I'm
not sure I agree that this is principally a UI problem; I think it is
principally an architecture problem where you need the UI and protocol
to cooperate.

I also believe that as you point out, the protocol problems are mostly
solved.  I do think there is still work to do on getting a protocol
that is easy to deploy and that for example deals with enrollment,
etc.

    Eric> 2. It's really important to distinguish between different
    Eric> levels of attack.  Conventional phishing attacks rely on
    Eric> generating a reference which appears to be valid but
    Eric> actually points at the attacker's site. (This is why SSL/TLS
    Eric> doesn't help much).

    Eric>    But this is different from attacks in which the attacker
    Eric> actually intercepts the user's communication. In these
    Eric> settings, some sort of cryptographic protection for the
    Eric> channel (a la HTTPS) or the messages (a la S-HTTP) must be
    Eric> provided.

Are there specific places in my document where you believe the distinction is critical?

    Eric>    On a similar note, in current phishing attacks the
    Eric> attacker attempts to directly extract the user's
    Eric> password. If C-R mechanisms are used, a dictionary attack is
    Eric> natural. I assume that's why you wave in the direction of
    Eric> ZKPPs in S 4.3. However, it's worth asking whether we would
    Eric> be satisified with a system that was only partly
    Eric> strengthened against dictionary attacks (see [2] again).

Yes, probably.  I think we'd be satisfied with many things better than
what we have:-) I think we'd like to get a ZKPP, but I think we have
no reason to assume the IPR situation will be any better with this
effort.

    Eric> 3. The term "password equivalent" is a bit confusing. See
    Eric> draft-iab-auth-mech for some discussion of strong versus
    Eric> weak password equivalent.

Your IAB draft seems to be focusing on what is stored rather than on
what is transported in the protocol.  I don't have a problem if a
server stores a weak password equivelant, but I do have a problem if
the server stores or even receives a strong password equivelant.

    Eric> 4. I agree that server authentication is a good, but I'm not
    Eric> totally sold that it's a necessity. 

I will work on selling you or revising my position.
    Eric> 5. You write:

    Eric>    The risk of dictionary attack is always a significant
    Eric> concern for password systems.  Users can (but typically do
    Eric> not) minimize this risk by choosing long, hard to guess
    Eric> phrases for passwords.  The risk can be removed once a
    Eric> password is already established by using a zero-knowledge
    Eric> password protocol.

    Eric> This is not strictly true. A ZKPP removes the risk of
    Eric> offline dictionary attack, but not online attack. These
    Eric> attacks do still get mounted [3]

Yes, and I even know that:-) Thanks for pointing out that I was being
sloppy.  Will fix.

    Eric>    However the risk of dictionary attack is always present
    Eric> when setting up a new password or changing a password.
    Eric> Minimizing the number of services that use the same password
    Eric> and being extra careful to make sure the right server is
    Eric> used when establishing a password can minimize this risk.

    Eric> It's not clear to me that this helps, unless you're assuming
    Eric> a ZKPP.  If the attacker can capture a 
    Eric> hashed password or
    Eric> C-R handshake (which a phisher can generally force in
    Eric> non-ZKPP cases) then they can mount an offline dictionary
    Eric> attack anyway. Consider a typical design where the user has
    Eric> a master password P and then generates per-site passwords as
    Eric> H(Site-Name || P). In the C-R handshake, the user provides:

    Eric> H(challenge || H(Site-Name || P).

    Eric> Dictionary attacking this isn't significantly harder than
    Eric> dictionary attacking H(Site-Name || P).

I'm not sure what you meant by this above.  If you mean using
different passwords, I meant using different master passwords.  I
believe that actually does help.  But I was assuming a ZKPP in that
paragraph, and I believ in the ZKPP case, contacting the right server
does help.  I will update the text.

    Eric> 6. You write:

    Eric>    In situations where there is an identity provider that is
    Eric> separate from the website as a relying party, additional
    Eric> requirements are needed.  The identity provider MUST verify
    Eric> that the website is a valid relying party for this identity.
    Eric> Some identity providers will allow anyone to accept their
    Eric> identity.  However particularly for financial institutions
    Eric> and large service providers it will be common that only
    Eric> authorized business partners will be able to accept the
    Eric> identity.  The confirmation that the the relying party is
    Eric> such a business partner will often be a significant part of
    Eric> the value provided by the identity provider, so it is
    Eric> important that the protocol enable this.  The relying party
    Eric> MUST prove its identity is the one expected by the identity
    Eric> provider.

    Eric> I agree that this is is a likely business goal for identity
    Eric> providers, but it's not required for protection against
    Eric> phishing. Really, there are two interests here:

    Eric> 1. To prove to the user (the guy with the browser) that he
    Eric> is doing business with an "authorized" provider.  2. To
    Eric> allow the identity provider to extract rents from the
    Eric> relying parties.

    Eric> Neither strictly requires the relying party authenticating
    Eric> to the identity provider during the transaction. The first
    Eric> can obviously done by issueing the relying party a long-term
    Eric> credential. The second can be done by encrypting the
    Eric> credential under the relying party's key. You don't
    Eric> necessarily need the identity provider to receive a proof
    Eric> that the relying party was able to decrypt it.

I don't believe that my requirements would require that the relying
party talk to the identity provider.  I believe that assuming a
reasonable set of trust anchors, having the web browser ask the
identity provider if the dnsname is allowed to accept the identity.
That provides a protocol hook allowing the identity provider to meet
the requirement that it MUST confirm the relying party is a valid
relying party for the identity.  If the relying party later proves
that it has a trusted certificate for this identity it meets the
second requirement.

Can you suggest clarifications to the text?

    Eric> -Ekr

P.S. Thanks for the references.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:15:43 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre
    Nicolas> wrote:
    >> >1. This is not principally a protocol problem but rather a UI
    >> problem.  > The protocol problems are generally well
    >> understood. If the UI > problems are solved, nearly any
    >> protocol will work. In particular, > there have been a number
    >> of published designs [1] [2] that have mostly > adequate
    >> (though not perfect) protocols, though without complete >
    >> One aspect of Sam's document that concerned me was the section
    >> on possible UI solutions. The requirements around spoofing seem
    >> directly opposed to the branding and usage patterns that web
    >> authors require.  HTTP authentication currently presents a
    >> modal dialog with no design control, and this is a significant
    >> reason most sites opt for form controls.

    Nicolas> Sam wants to put control over the UI in the web site's
    Nicolas> authors' hands.

    Nicolas> But he wants this UI tied intimately to a new browser
    Nicolas> function that is tied intimately to authentication
    Nicolas> protocols.

    >> Roy has previously mentio
Exactly.

I don't think we want today's http authentication dialogues.

Really. the secure UI could be as simple as any of the following:

* You choose what icon is used for bullets in a secure password form
  control when you create your account on a computer.  The standard
  bullet is used if it is a normal HTML control; the one you selected
  is used if it is a control that will make the password available
  only to the trusted authentication part of the browser.

*  You have a keystroke and mouse action that will hide non-trusted components of the UI.

I'm not a UI designer.  I don't know how to come up with a UI that
maximizes the probability that the user will actually notice when they
are typing a password into the wrong place.  I'm just trying to
demonstrate that we need not have something as clunky as current http
authentication dialogues.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 11:13:26 -0700

> principally an architecture problem where you need the UI and protocol

I don't think I agree. Both of the papers I cited above provide
basically acceptable phishing defenses without changing the wire
protocol (they do change the password on the server, of
course). So, you could certainly do better with a protocol,
but I think we have existence proofs that one isn't needed.

> Are there specific places in my document where you believe the distinction is critical?

Well, whenever you're talking about capturing credentials versus
capturing the session. Since non-reusable credentials protect
against credential capture but not against hijacking.

> the server stores or even receives a strong password equivelant.

Sure.

> Can you suggest clarifications to the text?

I don't think so because we don't agree on the requirements. My 
point is that the relying party does not need to prove its
authorization to the identity provider in any way
in order to solve the phishing problem. It may be required if
the identity provider wants to charge relying parties, but
even then it can be done without "confirming" as I indicated
above.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 11:51:13 -0700

Sam Hartman <[email-masked]> writes:

>     >>  I don't believe that my requirements would require that the
>     >> relying party talk to the identity provider.  I believe that
>     >> assuming a reasonable set of trust anchors, having the web
>     >> browser ask the identity provider if the dnsname is allowed to
>     >> accept the identity.  That provides a protocol hook allowing
>     >> the identity provider to meet the requirement that it MUST
>     >> confirm the relying party is a valid relying party for the
>     >> identity.  If the relying party later proves that it has a
>     >> trusted certificate for this identity it meets the second
>     >> requirement.
>     >> 
>     Eric> I don't think so because we don't agree on the
>     Eric> requirements. My point is that the relying party does not
>     Eric> need to prove its authorization to the identity provider in
>     Eric> any way in order to solve the phishing problem. 
>
> OK, we disagree on the requirements.  I believe that allowing the
> identity provider to validate the identity actually provides
> significant defenses against phishing.
>
>
> Assume that examplebank.com is a financial institution that acts as an
> identity provider for themselves and for business partners.  If they
> are given the ability to confirm that the website I'm going to is
> allowed to accept their identity, then they can give me an error if I
> attempt to use their identity with some random phishing site I got a
> link to in email.
>
> You may disagree that this defense is important.  However it is a
> defense.

And I never said otherwise, but just being a defense does not
make it a requirement.

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 May 2006 13:53:30 -0500

> You may disagree that this defense is important.  However it is a

It amounts to a hook for white/black-listing.

It can only really work well as a whitelist, and only if the list is
kept very small.

ISPs acting as IdPs may not want to be in the blacklisting business,
and whitelisting won't be an option.

So I see this as an optional feature, not a requirement.

Nico
--

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 22 May 2006 14:45:45 -0400

On 5/22/06, Nicolas Williams <[email-masked]> wrote:
>
> As Sam says: the browser must change.

Sure, and I suspect almost all browser vendors are willing to do that,
but I think better security is an insufficient motivator for web
authors. The requirement for mutual authentication was interesting to
me. Groups extending Web formats and APIs[1] often encounter
situations where a slightly elevated trust level for certain scripts
would be useful.

Offering a carrot in the form of an extended JavaScript API for
authenticated scripts would probably accelerate deployment of these
new efforts.

[1] http://www.w3.org/2006/webapi/

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 14:40:36 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 May 2006 17:09:55 -0500

> authenticated scripts would probably accelerate deployment of these

Call it an "extended JavaScript API" or something else, it doesn't
matter what it is called, as long as it is:

a) a browser function
b) that can be invoked from an HTML UI element
c) and which ties into the actual protocol and authentication
   mechanism(s) used on the wire

Again, you can call the HTML UI element a form, or something else.

It is a carrot.  Those who don't want to use it won't have to.

But why not use it if it's available?

That this all has to live in the browser should be no obstacle.  That
web site authors have to detect its presence in their client browsers
and choose to use it should be no obstacle either.

Nico
--

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 24 May 2006 10:47:34 +0100

On 2006-05-22 13:53:00 -0400, Sam Hartman wrote:

> I think we are in broad agreement that the interesting work
> in this space must involve the UI and is not principally a
> protocol problem.

I very much agree.

Incidentally, you may want have a look at the report from the
March W3C workshop:

  http://www.w3.org/2005/Security/usability-ws/report

We (W3C) are currently thinking about how to best charter work
that would specify some browser user interface components that
would have to be outside the control of web sites, and could be
used to make sure that users know (as opposed to look at on
their screens) where they are going to send their confidential
information.

Another element that we took as important from the workshop in
NYC is to enable user agents to reliably recognize HTML forms
that are used for authentication.  This ability would enable
user agents to manage credentials on behalf of the user. It
would also enable user agents to *not* submit credentials using
HTTP POST (even when entered through HTML forms), but instead
grab them and use them for whatever HTTP-level authentication
mechanism is used.  User agents could also do intelligent
things in the UI to make sure that users understand what they
are doing here.

PS: I'm currently at WWW 2006 in Edinburgh.  If any of you guys
want to chat more about this, please feel free to drop me a
line, so we can meet up somewhere.

Regards,
-- 
Thomas Roessler, W3C   <[email-masked]>