Subject: Review of draft-hartman-webauth-phishing-05

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Aug 2007 18:31:11 +0300

Sam,

I reviewed your document on "Requirements for Web Authentication Resistant to
Phishing".  I think the document is very useful.  Here are some comments:

The document provides guidance on designing secure authentication mechanisms
for Web services.  The goal is to replace HTML-form- and password-based
mechanisms that are commonly used today.  The document is a valuable step
forward in the combat against phishing.  However, below are a few issues that
Sam might want to address before this documents becomes RFC.

Section 3.1 (Capabilities of Attackers):

The 1st paragraph lists mechanisms by which an attacker can trick a victim user
into accepting a spoofed Web site.  One of them is "on-path network attacks".  I
am unsure what is meant by this.  It could refer to attacks on DNS, but those
attacks are listed separately.  It could also refer to MiTM attacks on TLS
connection establishment, but it is assumed that certificates are available.  In
consequence, I would assume that it refers to the process of obtaining a
certificate.  But this is unclear and should be clarified.

Section 3.1 (Capabilities of Attackers):

The 2nd paragraph of section 3.1 describes which components of a UI an attacker
might be able to forge.  The text differentiates between components that are
based on special knowledge about the user (such as an account balance or
transaction history), and components that do not require such knowledge (such as
a loginpage).  What I am missing here is some thoughts on how far forgery of the
latter type of component could enable forgery of the former type.

Reusing the examples in parentheses, an attacker might be able to trick a victim
user into providing a password via a spoofed login page, and then retrieve the
user's current account balance and transaction history from the legitimate site
in order to subsequently print it on another spoofed page.

Section 4.3 (No Password Equivalents):

The terms "strong/weak password equivalence" seem to be used differently in this
document than in [draft-iab-auth-mech], which is uses as a reference in this
document.  In [draft-iab-auth-mech], the terms are used to describe a dependency
between login credentials for different systems, while in this document, they
are used for the data exchanged between an authenticator and an authenticatee.

Section 8 (Security Considerations):

Paragraph 5 mixes two issues:

  (i)  Web sites using both the proposed authentication mechanism and
       a legacy, HTML-based mechanism for backwards compatibility

  (ii) users who take the same password for Web sites with the proposed
       authentication mechanism and Web sites with a legacy
       authentication mechanism

These two issues are orthogonal and should be separated.

While the document suggests a solution for issue (ii) -- which calls for users
not to use the same password for different Web sites --, there is no suggested
solution for issue (i).  One possible solution could be provide a mechanism by
which users can disable access through legacy authentication mechanisms.
Re-enabling access for legacy authentication mechanisms could be accomplished
only through the proposed authentication mechanism.  Maybe Sam wants
to add this to his draft...

Editorial:

- General

    Abbreviation "UI" is never spelled out.  I'd recommend spelling
    it out everywhere.

- Abstract

    s/providers and users and for /providers and users, and/

    s/These requirements may serve/These requirements may also serve/ ?

- Section 4.1

    s/Passwords and OTher Methods/Passwords and Other Methods/

    s/do not have smart cards/do not have smart card readers/

    s/access to other resources may/access to other resources--may/

- Section 4.2

    s/security community has/security community has done/

- Section 4.3

    s/No Password EquivelentsN/o Password Equivalents/

- Section 4.6

    s/the the/the/

Best regards,
- Christian

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Aug 2007 13:08:26 -0400

Hi.

Both your and Eric's comments need a longer response.

It was my intent to use strong and weak password equivelantsin the
same way as the IAB document.  We agree on what the IAB document
defines the terms to mean.  I'll go look through my text and clarify
what needs clarification.

I'm confused by your comments on 3.1.  I agree with you that an
attacker could take for example a login password in today's systems
and use that to to gain the information necessary to spoof other UI.

The primary goal of this document is to propose requirements that make
it difficult for the attacker to capture such a password.

What do you think I'm doing wrong in 3.1.

Also in 3.1 you talk about on-path attacks.  I guess this needs better
wording because basically everyone who has read the document has
commented on that phrase.  So, examples of an on-path attack include
mounting a MITM against TLS and hoping the user will click "accept
this certificate" for the bogus cert you provide; DNS attacks; etc.
I'm trying to say that attackers have these capabilities and that we
need to evaluate both current and future systems against such attacks.
How can I help clarify what I'm trying to say?

---

From: Christian Vogt <[email-masked]>
Date: Thu, 23 Aug 2007 13:10:58 +0300

Hi Sam.

> it difficult for the attacker to capture such a password.

Alright, I see that the intent of section 3.1 is actually to describe
capabilities that an attacker will *always* have, i.e., even in case it
does not know (and cannot acquire) a username/password from a victim
user.  Maybe you can clarify this by changing the latter part of paragraph
2 of section 3.1 like this:

   OLD

                                                     However the
   attacker probably could not replicate the account summary page until
   the attacker learned the user name and password because the attacker
   would not know what accounts to list or approximate balances that
   will look convincing to a user.  Of course attackers may know some
   personal information about a user.  Websites that want to rely on
   attackers not knowing certain information need to maintain the
   privacy of that information.

   NEW

                                                     However the
   attacker probably could not replicate the account summary page
   until the attacker learned the user name and password because the
   attacker would not know what accounts to list or approximate
   balances that will look convincing to a user.  Preventing the
   attacker from acquiring a victim's user name and password would thus
   make it impossible for an attacker to spoof a user interface that
   shows such individual data.

What I did is replacing the last two existing sentences with a new
one.  Would you agree?

> How can I help clarify what I'm trying to say?

Here is some text that you could take to replace the currently last
sentence in paragraph 1 of section 3.1.  If you wish, feel free to
copy and paste:

   Mechanisms attackers use to accomplish this include links with a
   misleading name or URI, which they may distribute in emails;
   attacks against DNS; and man-in-the-middle attacks against a TLS
   handshake.  The former two attacks allow the attacker to pass
   authentication because the victim user can be tricked into
   accepting the attacker's certificate.  The latter attack will
   typically create a warning on the victim user's side, but many
   users cannot make informed decisions on how to respond to such a
   warning, making them inclined to accept the bogus certificate.

Hope this helps,
- Christian