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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf