Subject: [APPS-REVIEW] Review of draft-hartman-webauth-phishing-05

From: Eric Burger <[email-masked]>
Date: Thu, 18 Oct 2007 12:05:15 -0400

Review of 

http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-05.txt

by Yves Lafon, forwarded on his behalf by Eric.  If you wish to contact the
reviewer directly, use the CC address above.

In 1.
Are single sign-on solutions taken into account ? Impersonation can
happen and have bad effects (web mails, photo archives etc...)
[seems to be handled in 3.2 and 4.1, might be good to introduce this
earlier] 

In 3.
"We assume that users have limited motivation to combat phishing."
motivation ? Or just lack of knowledge to detect phishing attacks. removing
this sentence will keep the meaning of the remaining of the paragrahp
intact.

In 3.1.
"Mechanisms attackers use to accomplish this include links where the
   link name and URI target are misleading; email with links; DNS
   attacks; and on-path network attacks."

what link name and URI target, the real ones (the URI bar) or the ones
displayed by the User-Agent ? (like the bottom destination link bar)

later in 3.1.

"The attacker cannot replicate a UI that depends on information the
   attacker does not know.  For example, an attacker could generally
   replicate the UI of a banking site's login page.  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. "
does that mean that potentially sensitive information should be released
_before_ authentication? It seems linked to paragraph 4.2 below, but the
example given looks strange.

In 4.1.

The use of identity providers might help, but they will be subject to
phishing attacks as well. What will be the impact on phishing if only
a few identity providers services are subject to such attacks instead
of lots of different sites? Faking an UI has a cost, and can lead to
breach in far more services in that case. [4.7 addresses partially
the issue]

In 4.5.

"1.  Assuming that only certificates from trusted CAs are accepted..."
Is this economically feasible ? It would assume that all sites using
TLS should get a certificate from a trusted CA.

In 8.
How can a  "secure web component" be... a secure web component as it is
more and more easy to fake components and make them even look like "real"
windows (in the case of auth popups). There is a contradiction between
giving designers more graphical control to design web-based applications
and the will to be able to expose secure components for authentication.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review