One document matched: draft-hartman-webauth-phishing-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2818 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
<!ENTITY rfc5090 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5090.xml'>
<!ENTITY rfc4559 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml'>
<!ENTITY rfc5056 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY rfc4346 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'>
<!ENTITY rfc4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
]>
<rfc category="info" ipr="full3978" docName="draft-hartman-webauth-phishing-09.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Web Phishing Requirements">Requirements for Web Authentication Resistant to Phishing</title>
<author initials="S." surname="Hartman" fullname="Sam Hartman">
<organization abbrev="Painless Security">
Painless Security, LLC</organization>
<address>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<date month="August" year="2008"/>
<abstract>
<t>This memo proposes requirements for protocols between web
browsers and relying parties at websites; these requirements
also impact third parties involved in the authentication
process. These requirements minimize the likelihood that
criminals will be able to gain the credentials necessary to
impersonate a user or be able to fraudulently convince users to
disclose personal information. To meet these requirements
browsers must change. Websites must never receive information
such as passwords that can be used to impersonate the user to
third parties. Browsers should authenticate the website to the browser as part of authenticating the user to the website. Browsers MUST flag situations when this authentication fails and flag situations when the target website is not authorized to
accept the identity being offered as this is a strong indication
of fraud. These requirements may serve as a basis for
requirements for preventing fraud in environments other than the
web. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Typically, web sites ask users to send a user name and
password in order to log in and authenticate their identity to
the website. The user name and plaintext password are often sent
over a TLS <xref target="RFC4346"/> encrypted connection. As a
result of this plaintext password protocol, the server learns the password and can pretend
to be the user to any other system where the user has used the
same user name and password. The security of passwords over TLS depends on
making sure that the password is sent to the right, trusted
server and on that server not exposing the password to third parties. HTTPs <xref target="RFC2818" /> implementations typically confirm that the name
entered by the user in the URL corresponds to the certificate. </t>
<t>One serious security threat on the web today is phishing.
Phishing is a form of fraud where an attacker convinces a user
to provide confidential information to the attacker believing
they are providing the information to a party they trust with
that information. For example, an email claiming to be from a
user's bank may direct the user to go to a website and verify
account information. The attacker captures the user name and
password and potentially other sensitive information. Domain
names that look like target websites, links in email, and many
other factors contribute to phishers' ability to convince users
to trust them.</t>
<t>Typically the user names and password are not directly valuable to the phisher. However they can be used to access resources of value. For example a bank password may permit money transfer or access to information useful in identity theft. </t>
<t>It is useful to distinguish two targets of phishing.
Sometimes phishing is targeting web authentication credentials
such as user name and password. Sometimes phishing is targeting
other confidential information, such as bank account numbers.
This memo presents requirements
that can be part of a solution to significantly reduce the effectiveness of the first
category of phishing: provided that a user uses an authentication mechanism that meets these requirements, even if
the user authenticates to the wrong server, that server cannot
impersonate the user to a third party. However, to combat
phishing targeted at other confidential information, the best we
know how to do is help the user detect fraud before they release
confidential information.</t>
<t>The approach taken by this memo is to handle
these two types of phishing differently. The user is given new authentication mechanisms. If the user uses these mechanisms,they have strong assurances that their password
has not been disclosed and that the ensuing data returned from the
server was generated by a party that either knows their password or
who is authenticated by an identity provider (a third party involved in the authentication exchange in order to allow credentials to be used across a wider variety of websites) who knows their
password. The server can then use confidential information
known to the user and server to enhance the user's trust in
its identity beyond what is available given the social
engineering attacks against TLS server authentication. If a
user authenticates to the wrong server but discovers
this before they give that server any other confidential
information, then there exposure is very limited. The success of this solution depends heavily on whether the user uses the new authentication mechanisms; designing ways for users to tell if they are using the authentication mechanisms and encouraging users to use these mechanisms will be critical to achieving any security benefit from these requirements.
The success of a solution to preventing the disclosure of other confidential information based on giving users information about whether they are authenticated to the right server depends on the user being able to take advantage of this information and choosing to do so.
</t>
<t>The requirements presented in this memo are intended to be
useful to browser designers, designers of other HTTP
applications and designers of future HTTP authentication
mechanisms. </t> <t>These requirements and mechanisms that meet
these requirements are not sufficient to stop phishing; at best,
they form part of a solution. The World Wide Web Consortium
proposes recommendations on user interface guidelines for web
security context <xref target="WSCUIG"/>. These guidelines
propose mechanisms that will make it more likely that users will
detect fraud before authentication. Efforts to limit the effect of malicious software and to provide trustable software for authentication are also important. Efforts to track known frauds and alert users when they encounter fraudulent sites are also critical. Together, all these efforts may significantly reduce phishing.</t>
<section title="Purpose of this Memo">
<t>In publishing this memo, the IETF recommends making available authentication mechanisms that meet the requirements outlined in <xref target="REQUIREMENTS" /> in HTTP user agents including web browsers. It is hoped that these mechanisms will prove a useful step in fighting phishing. However this memo does not restrict work either in the IETF or any other organization. In particular, new authentication efforts are not bound to meet the requirements posed in this memo unless the charter for those efforts chooses to make these binding requirements. Less formally, the IETF presents this memo as an option to pursue while acknowledging that there may be other promising paths both now and in the future. </t>
</section>
<section title="Progress to Date">
<t>This non-normative section describes the author of this memo's impressions of the current state of HTTP authentication with regard to these requirements.</t>
<t>In the spring of 2008, Microsoft demonstrated that with no change to the spec, GSS-API and NTLM HTTP authentication could be extended to support channel binding <xref target="RFC5056" /> <xref target="RFC4559"/>. At first glance, the Microsoft extension appears to meet all the requirements outlined in this memo for an authentication mechanism. In addition, Microsoft has outlined extensions to HTTP digest authentication that also appear to meet these requirements <xref target="DIGEST-BIND"/>. The Microsoft extensions do not provide the client with information on whether the server supports the extension; so the client may not know whether it is strongly authenticated or not. Also, the Microsoft extensions are focused for enterprise deployment and so concerns regarding upgrade negotiation and other issues that would be important in a wider deployment are not covered. However Microsoft's efforts underscore that new security mechanisms are not needed in order to meet these requirements. Originally, I had expected that changes to meet these requirements would be more extensive, but still expected they would be incremental changes to existing mechanisms.</t>
<t>However there is still work that needs to be done in order to make mechanisms meeting these requirements available in a usable manner across the Internet. Most of that work concerns usability and falls outside the IETF. Results of the usability work may fall within the IETF; mechanisms for picking the right credentials to use for a given site may require minor extensions to security mechanisms . Mechanisms to provide smoothe upgrades from plaintext password protocols to mechanisms meeting these requirements may require additional HTTP headers, particularly for non-browser agents. In addition, these requirements may be useful to efforts that are designing HTTP authentication mechanisms for unrelated reasons.</t>
</section>
</section>
<section title="Terminology">
<section title="Passwords and Interface">
<t>There are two related concepts: the user interface of passwords and plaintext password protocols. A plaintext password protocol is a protocol where the server receives credentials sufficient to impersonate a user to third parties. A password interface provides a user experience where a user types a password into any computer, including one they have never used before and that is sufficient to authenticate. The requirements in this memo require support for password user interfaces as one option for authentication. The requirements of this memo are incompatible with plaintext password protocols. </t>
</section>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
</section><section anchor="THREAT" title="Threat Model">
<t>This section describes the assumed capabilities of phishers,
describes assumptions about web security and describes what
vulnerabilities exist. Human factors issues contribute significantly to these vulnerabilities. For example, security information dialogues in web browsers can provide information on the subject of a certificate. However, users rarely examine this information, so an attacker could be successful even if examining the security dialogue would show an attack. This threat model is intended to include these sorts of attacks and so it is broader than the technical threats against protocols. Efforts are under way to improve these human factors issues <xref target="WSCUIG" />. However these efforts only reduce the risk that a user will be confused; even given improved user experience for dealing with security context information, users will make mistakes and believe that an attacker's site is the site they intended to communicate with. </t>
<t> We assume that the implementations of authentication systems can be trusted sufficiently to meet their design objectives. This does not mean that the entire local system and browser need to be trusted. However if there is a component that has access to users' passwords, that component needs to be secure enough to be trusted not to divulge passwords to attackers. Similarly in a system that used smart cards, the smart cards would need to be trusted not to give attackers access to private keys or other authentication material. Designing implementations to limit the size and complexity of the most trusted components and to layer trust will be important to the security of implementations. Designing protocols to enable good implementation will be critical to the utility of the protocols. As a consequence of this assumption, these
requirements are insufficient to provide protection against
phishing if malicious browser extensions, Trojan software or
other malicious software is installed into a sufficiently trusted part of the
local computer or authentication tokens. </t>
<t>We
assume that users have limited motivation to combat phishing.
Users cannot be expected to read the source of web pages,
understand how DNS works well enough to look out for spoofed
domains, or understand URI encoding. Users do not typically
understand certificates and cannot make informed decisions about
whether the subject name in a certificate corresponds to the
entity they are attempting to communicate with. As a consequence of this assumption, users will likely be fooled by strings either in website names or certificates that look visually similar but that are composed of different code points. </t>
<section title="Capabilities of Attackers">
<t>We assume attackers can convince the user to go to a website of their
choosing. Since the attacker controls the web site and since
the user chose to go to the website the TLS certificate will
verify and the website will appear to be secure. The
certificate will typically not be issued to the entity the
user thinks they are communicating with, but as discussed
above, the user will not notice this.
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 do not make informed decisions on how to respond to such a
warning, making them inclined to accept the bogus certificate.
</t>
<t>The attacker can convincingly replicate any part of the UI
of the website being spoofed. The attacker can also spoof
trust markers such as the security lock, URL bar and other
parts of the browser UI sufficiently that a significant class of users will not treat the spoofed security indicators as a problem. There is one limitation to the
attacker's ability to replicate UI. 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. 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.</t>
<t>It's not clear how valuable this limitation on the attacker's ability will prove in practice. Research into the effectiveness of security indicators <xref target="SECIND"/> suggests that users do not pay attention to security indicators. One difference between the security indicators tested in today's research and using private information to detect fraud is that the private information may be directly related to the task the user is trying to perform. However the attacker can attempt to come up with a convincing explanation such as a partial outage or system upgrade for why the private information is not available. </t>
<t>The attacker can convince the user to do anything with the
phishing site that they would do with the real target site.
As a consequence, when passwords are used, if we want to avoid
the user giving the attacker their password, the web site must
prove that it has an established authentic relationship with
the user without requiring a plaintext password protocol.
One approach could be to transition to a solution
where the user could not give the real target site their
password if they are using a new mechanism. Instead they will need to cryptographically prove
that they know their password without revealing it.</t>
</section>
<section title="Attacks of Interest">
<t>The ultimate goal of these requirements is to provide protection against disclosure of confidential information to unintended parties. These requirements focus on two such disclosures and handle them separately. The first category is disclosure of credentials that could allow an unintended party to impersonate the user, possibly gaining access to additional confidential information. The second attack is disclosure of confidential information not directly related to authentication. The second class of attack cannot be directly defeated, but we can give information to users that they could use to help know when they are communicating with an unintended party.</t>
<t> Note that some authentication systems such as
Kerberos <xref target="RFC4120"/> provide a facility to
delegate the ability to act as the user to the target of the
authentication. Such a facility when used with an
inappropriately trusted target would be an instance of the first class of
attack. Solutions to these requirements with similar facilities MUST discuss the security considerations surrounding use of these facilities. </t>
<t>Of less serious concerns at the present time are attacks on
data integrity where a phisher provides false or misleading
information to a user.</t>
</section>
</section>
<section anchor="REQUIREMENTS" title="Requirements for Authentication that Protects Credentials">
<t>This section describes requirements for web authentication
solutions. These solutions are intended to prevent phishing
targeted at obtaining web authentication credentials. These
requirements will make it more difficult for phishers to target
other confidential information.</t>
<section title="Support for Passwords and OTher Methods">
<t>The web authentication solution MUST support the password user interface and
MUST be secure even when the password interface is commonly used. In
many environments, users need the ability to walk up to a
computer they have never used before and log in to a website.
Carrying a smart card or USB token significantly increases
the deployment cost of the website and decreases user
convenience. The smart card is costly to deploy because it requires a process for replacing smart cards, requires support staff to be trained in answering questions regarding smart cards and requires a smart card to be issued when an identity is issued. Smart cards are less convenient because users cannot gain access to protected resources without having their card physically with them. Many public access computers do not have smart cards available and do not provide access to USB ports; when they do they tend not to support smart cards. It is important not to underestimate the training costs (either in money or user frustration) of teaching people used to remembering a user name and password about a new security technology. Sites that aggregate identity--for example allowing a user to log into an identity provider and then gain access to other resources may be a significant part of a solution. However we cannot assume that a given user will have only one such website: there are valid and common reasons a user (or the relying party) would not trust all identity information to one such site. </t>
<t>A solution to these requirements MUST also support smart cards and other authentication solutions. Some environments have security requirements that are strong enough that passwords simply are not a viable option. Many efforts are under way to reduce the deployment costs of token-based authentication mechanisms and to address some of the concerns that make passwords a requirement today. </t>
</section>
<section anchor="TRUSTEDUI" title="Trusted UI">
<t>Users need the ability to trust components of the UI in
order to know that the UI is being presented by a trusted
component of the device. The primary concern is to make
sure that the user knows any password is being given to
trusted software rather than being filled into an HTML form
element that will be sent to the server as part of a plaintext password protocol.</t>
<t>There are many approaches to establishing a trusted UI. One example is to use a dynamic UI based on a secret shared
by the user and the local UI; the paper <xref target="ANTIPHISHING"/>
recommends this approach. The W3C recommends this approach for security indicators in section 7.1 of its user interface guidelines <xref target="WSCUIG" />. However, the W3C notes that research suggests users may not pay attention to these trust indicators. A second approach is to provide a
UI action that highlights trusted or non-trusted components
in some way. This could work similarly to the Expose feature
in Apple's Mac OS X where a keystroke visually distinguishes
structural elements of the UI. Of course such a mechanism
would only be useful if users actually used it. Finally, another potential approach is to benefit from extensive research
in the multi-level security community in
designing UIs to display classified, compartmentalized
information. It is critical that these UIs be able to label
information and that these labels not be spoofable. These approaches are not exhaustive and may not even be good; they are provided to demonstrate that thought into how to design trusted UIs is ongoing. However, designing a user interface that allows users of the web to distinguish trusted components from components potentially controlled by an attacker is an open problem. It is likely that transitioning to many new security protocols will depend on a solution to this problem.</t>
</section>
<section title="No Password Equivelents">
<t>A critical requirement is that when a user authenticates to
a website, the website MUST NOT receive a strong password
equivalent <xref target="IABAUTH"/>. A strong password equivalent is anything that would
allow a phisher to authenticate as a user with a different
website. Consequently, plaintext password protocols are
incompatible with these requirements. Weak password
equivalents (quantities that act as a password for a given
service but cannot be reused with other services ) are
problematic outside of the context of enrolling a user or
changing a password. The requirement for mutual
authentication <xref target="MUTUAL" /> is incompatible with
sending weak password equivalents in every authentication.
Even if that requirement is relaxed, the scope of a particular
weak password equivalent needs to be carefully considered.
Consider for example a protocol that hashes a password and the
host name component of a URI together to form a weak password
equivalent. The same password equivalent is used regardless
of which certificate authority certifies the public key of the
website. If an attacker mounted a man-in-the-middle attack,
presenting a self-signed certificate, and the user
accepted the certificate when asked by the browser, then the
attacker would receive the same weak password equivalent
needed to access the legitimate website. Such a protocol
would not do a good job of addressing the threats outlined in
the threat model. However if mutual authentication were not a
requirement, a protocol that hashed a password and the public key
from the TLS certificate of the website to form a weak
password equivalent might meet the other requirements. In any
event, weak password equivalents MUST NOT be sent without
confidentiality protection.
</t>
<t>There are two implications of this requirement. First,
a strong cryptographic authentication protocol needs to be used
instead of sending the password encrypted over TLS. The
zero-knowledge class of password protocols such as those
discussed in section 8 of the IAB authentication mechanisms
document <xref target="IABAUTH"/> seem potentially useful in
this case at a first glance. However, mechanisms in this space tend to have
significant deployment problems because of intellectual
property issues. </t>
<t>The second implication of this requirement is that if an
authentication token is presented to a website, the website
MUST NOT be able to modify the token to authenticate as the
user to a third party. The
party generating the token must bind it to
either the website that will receive the token or to a key
known only to the user. Binding could include cryptographic binding or mechanisms such as issuing a one-time password for use with a specific website. If tokens are bound to keys, the
user MUST prove knowledge of this key as part of the
authentication process. The key MUST NOT be disclosed to the
server unless the token is bound to the server and the key is
only used with that token or server. </t>
</section>
<section anchor="MUTUAL" title="Mutual Authentication">
<t><xref target="ANTIPHISHING"/> describes a requirement for
mutual authentication. A common phishing practice is to
accept a user name and password as part of an attempt to make
the phishing site authentic. The real target is some other
confidential information. The user name and password are
captured, but are not verified. After the user name and
password are entered, the phishing site collects other
confidential information. When mutual authentication fails,
there is a strong indication of a problem: either the user
supplied the wrong credential or the website is not the one
the user intended to communicate with. </t> <t>Requiring
mutual authentication excludes a class of mechanisms where a
weak password equivalent is generated for the server and is
sent. One prominent member of this class is <xref
target="PWDHASH" />; this mechanism has the desirable property
that it requires no change to the server and can be
implemented locally on the browser. These mechanisms provide
better security than plaintext password protocols. However
attacks where the server ignores authentication in order to
obtain confidential information are important enough that it
is desirable to develop mechanisms that provide this
assurance. The desire to develop these new mechanisms is not
intended to discourage the deployment of mechanisms like
Pwdhash that improve security today. </t>
<t>Typically one protocol performs authentication of both
parties. There tend to be opportunities for a
man-in-the-middle attack when one protocol authenticates one
direction and another protocol authenticates the opposite
direction. Sometimes, as in the case of TLS and plaintext
password protocols, the opportunity for attacks depends on
human factors issues or certificate management. In other
cases, attacks may be more direct. Authentication of the
server and client at the TLS level is sufficient to meet the
requirement of mutual authentication. If authentication is
based on a shared secret such as a password, then the
authentication protocol MUST prove that the secret or a
suitable verifier is known by both parties. Interestingly the
existence of a shared secret will provide better confidence
that the right server is being contacted than if public key
credentials are used in their typical mode. By their nature, public key credentials
allow parties to be contacted without a prior security
association. In protecting against phishing targeted at
obtaining other confidential information, this may prove a
liability. However public key credentials provide strong
protection against phishing targeted at obtaining
authentication credentials because they are not vulnerable to
dictionary attacks. Such dictionary attacks are a significant
weakness of shared secrets such as passwords intended to be
remembered by humans. For public key protocols, the mutual authentication
requirement would mean that the server typically needs to sign
an assertion of what identity it authenticated or of the request as a whole. </t>
</section>
<section anchor="BINDING" title="Authentication Tied to
Request and Response">
<t>Users expect that whatever party they authenticate to will
be the party that generates the content they see. One
possible phishing attack is to insert the phisher between the
user and the real site as a man-in-the-middle. On
today's websites, the phisher typically gains the user's
user name and password. Even if the other requirements of
this specification are met, the phisher could gain access to
the user's session on the target site. This attack is of
particular concern to the banking industry. A
man-in-the-middle may gain access to the session which may
give the phisher confidential information or the
ability to execute transactions on the user's behalf. </t>
<t>The authentication system MUST guarantee to the user and
the target server that the request was generated by the authenticated user and the response is generated by the
target server . This can be done in
several ways including:
<list style="numbers">
<t>Assuming that only certificates from trusted CAs are
accepted and the user has not bypassed server certificate
validation, it is sufficient to confirm that the identity
of the server at the TLS level is the same at the HTTP
authentication level. In the case of TLS client
authentication this is trivially true. Note however that <xref target="WSCUIG" /> recommends accepting self-signed certificates in some cases, so relying on this approach for cases other than TLS authentication may be problematic.</t>
<t>Another alternative is to bind
the authentication exchange to the channel created by the TLS
session. The general concept behind channel binding is
discussed in <xref target="RFC5056"/>. Channel binding has been added to HTTP authentication mechanisms based on digest authentication and on GSS-API, suggesting that support for channel binding is workable for future HTTP authentication mechanisms. </t>
</list>
</t>
</section>
<section title="Restricted Identity Providers">
<t>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 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. For such
identities, the user MUST be assured that the target server
is authorized by the identity provider to accept identities
from that identity provider. Several mechanisms could be used
to accomplish this:
<list style="numbers">
<t>The target server can provide a certificate issued by
the identity provider as part of the authentication.</t>
<t>The identity provider can explicitly approve the
target server. For example in a redirect-based scheme the
identity provider knows the identity of the relying party
before providing claims of identity to that party. A
similar situation happens with Kerberos or Digest Authentication in a AAA infrastructure <xref target="RFC5090"/>.</t>
</list>
</t>
</section>
<section title="Protecting Enrollment">
<t>One area of particular vulnerability to phishing is
enrollment of a new identity in an authentication system. Protecting against phishing targeted at obtaining
other confidential information as a new service is established
is outside the scope of this document. If confidential
information such as credit card numbers are provided as part
of account setup, then this may be a target for phishing.</t>
<t>However there is one critical aspect in which enrollment
impacts the security of authentication. During enrollment, a
password is typically established for an account or other security credentials are associated with an account. The process of establishing a password
MUST NOT provide a strong password equivalent (a quantity such as the password itself that could be used to log into another service where the same password is used as the user). That is, parties other than the user and web browser MUST NOT gain enough
information to impersonate the user to a third party while
establishing a password. </t>
</section>
</section>
<section anchor="SERVER" title="Is it the right Server?">
<t>In <xref target="REQUIREMENTS"/>, requirements were presented
for web authentication solutions to minimize the risk of
phishing targeted at web access information. This section
discusses in a non-normative manner various mechanisms for
determining that the right server has been contacted.
Authenticating to the right party is an important part of
reducing the risk of phishing targeted at other confidential
information.</t> <t>Validation of the certificates used in TLS
and verification that the name in the URI maps to these
certificates can be useful. As discussed in <xref
target="THREAT"/>, attackers can spoof the name in the URI.
However the TLS checks do defeat some attacks. The W3C user
interface guidelines may significantly increase the value of
these checks <xref target="WSCUIG" />. As discussed in <xref
target="BINDING"/>, TLS validation may be important to
higher-level checks.</t> <t>A variety of initiatives propose to
assign trust to servers. This includes proposals to allow users
to indicate certain servers are trusted based on information
they enter. Also, proposals to allow third parties including
parties established for this purpose and existing certificate
authorities to indicate trust have been made. These proposals
will almost certainly make phishing more difficult.</t> <t>In
the case where there is an existing relationship, these
requirements provide a way that information about the
relationship can be used to provide assurance that the right
party has been contacted. </t> <t>In <xref
target="TRUSTEDUI"/>, we discuss how a secret between the user
and their local computer can be used to let the user know when a
password will be handled securely. A similar mechanism can be
used to help the user once they are authenticated to the
website. The website can present information based on a secret
shared between the user and website to convince the user that
they have authenticated to the correct site. This depends
critically on the requirements of <xref target="BINDING"/> to
guarantee that the phisher cannot obtain the secret. </t>
<t>Various schemes have used a secret shared between the server
and the web browser before authentication. Cookies or some
other state management mechanism are used to select the right
secret to display as the user logs into the site. Unfortunately
these schemes have proven ineffective in practice <xref
target="SECIND"/>. However, the set of information that can be
used as contextual clues to evaluate whether the right server
has been reached after authentication is much greater. For
example, a bank server knows what accounts a user has and knows
their balances. A business partner may have information about
past transactions or the current state of transactions. If this
information is related to the task that the user is trying to
perform, they may be more likely to evaluate it and notice
problems than they are to notice a missing security indicator
before login. Strong authentication mechanisms enable this type
of evaluation after the user has logged in. However it is not known how effective this will be in practice.</t>
</section>
<section title="Iana Considerations">
<t>This document requests no action of IANA.</t>
</section>
<section title="Acknowledgments">
<t>I'd like to thank the MIT Kerberos Consortium for its funding
of work on this memo prior to April 2008.</t>
<t>I'd like to thank Nicolas Williams, Matt Knopp and David Blumenthal for helping me walk through these requirements and make sure that if a solution met them it would actually protect against the real world attacks consumers of our technology are facing. I was particularly focusing on attacks that financial institutions are seeing and their help with this was greatly appreciated.</t>
<t>I'd like to thank Eric Rescorla and Ben Laurie for their significant comments on this draft.</t>
<t>Eliot Lear provided many last call comments and helped work through several long standing issues with the document.</t>
<t>Christian Vogt provided text and review comments.</t>
<t>The requirements discussed here are similar to the principles
outlined in "Limits to Anti-Phishing" <xref
target="ANTIPHISHING"/>. Most of this work was discovered
independently but work from that paper has been integrated where
appropriate. It seems good that these requirements are similar to the principles outlined by someone facing phishing as an operational reality.</t>
</section>
<section title="Security Considerations">
<t>This memo discusses the security of web authentication and
how to minimize the risk of phishing in web authentication
systems. This section discusses the security of the overall
system and discusses how components of the system that are not
directly within the scope of this document affect the security
of web transactions. This section also discusses residual risks
that remain even when the requirements proposed here are
implemented. </t>
<t>The approach taken here is to separate the problem of
phishing into phishing targeted at web authentication
credentials and phishing targeted at other information. Users
are given some trusted mechanism to determine whether they are
typing their password into a secure browser component that will
authenticate them to the web server--a component that presents a password interface--or whether they are typing
their password into a legacy mechanism that will send their
password to the server as part of a plaintext password protocol. If the user types a password into the
trusted browser component, they have strong assurances that
their password has not been disclosed and that the page returned
from the web server was generated by a party that either knows
their password or who is authenticated by an identity provider
who knows their password. The web server can then use
confidential information known to the user and web server to
enhance the user's trust in its identity beyond what is
available given the social engineering attacks against TLS
server authentication. If a user enters their password into the
wrong server but discovers this before they give that server
any other confidential information, then there exposure is very
limited.</t>
<t>This model assumes that the parts of the browser and operating system with access to passwords or other long-term credentials are
trusted software. As discussed in <xref target="THREAT"/>,
there are numerous attacks against host security. Appropriate
steps should be taken to minimize these risks. If the
security of the trusted software is compromised, the password can be captured as it is
typed by the user.</t>
<t>This model assumes that users will only enter their
passwords into trusted browser components. There are several
potential problems with this assumption. First, users need to
understand the UI distinction and know what it looks like when
they are typing into a trusted component and what a legacy HTML
form looks like. It is not clear that we have yet developed a solution to this user interface problem. Users must care enough about the security of
their passwords to only type them into trusted components. The
browser must be designed in such a way that the server cannot
create a UI component that appears to be a trusted component but
is actually a legacy HTML form; the W3C user interface guidelines <xref target="WSCUIG"/> provides requirements that are designed to prevent security sensitive user interface from being spoofed by attacker-supplied content. The W3C guidelines provide requirements for a more limited context focused around security context but not authentication information. However starting from these requirements may be a successful approach.</t>
<t>In addition, a significant risk that users will type their
password into legacy HTML forms comes from the incremental
deployment of any web authentication technology. Websites will
need a way to work with older web browsers that do not yet
support mechanisms that meet these requirements. Not all
websites will immediately adopt these mechanisms. Users will
sometimes browse from computers that have mechanisms meeting
these requirements and sometimes from older browsers. They
only gain protection from phishing when they type passwords
into trusted components. If the same password is sometimes used with
websites that meet these requirements and sometimes with legacy
websites, and if the password is captured by a phisher targeting
a legacy website, then that captured password can be used even
on websites meeting these requirements. Similarly, if a user is
tricked into using HTML forms when they should not, passwords
can be exposed. Users can significantly reduce this risk by
using different passwords for websites that use trusted browser
authentication than for those that still use HTML forms. </t>
<t>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 of offline dictionary attack can be removed once a password is already
established by using a zero-knowledge password protocol.
The risk of online dictionary attack is always present. The risk of offline 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 can minimize
this risk. When zero-knowledge password protocols are used, being
extra careful to make sure the right server is used when
establishing a password can significantly reduce this risk.</t>
</section>
</middle>
<back>
<references title="Normative References">&rfc2119;
<reference anchor="WSCUIG" target="http://www.w3.org/TR/wsc-ui/">
<front>
<title>Web Security Context: User Interface Guidelines</title>
<author initials="T." surname="Roessler " fullname="" role="Editor">
<organization>W3C</organization>
</author>
<author initials="A." surname="Saldhana " fullname="" role="Editor">
<organization>Redhat</organization>
</author>
<date day="24" month="July" year="2008"/>
</front>
<seriesInfo name="W3C" value="Working Draft"/>
<annotation>Publication of this draft needs to block until and unless this references is approved as some form of W3C recommendation.</annotation>
</reference>
</references>
<references title="Informative References">
&rfc2818;
&rfc4346;
&rfc4120;
&rfc5056;
&rfc5090;
&rfc4559;
<reference anchor="PWDHASH" target="http://crypto.stanford.edu/PwdHash/pwdhash.pdf">
<front>
<title>Stronger Password Authentication Using Browser Extensions</title>
<author initials="B." surname="Ross">
<organization></organization>
</author>
<author initials="C." surname="Jackson">
<organization></organization>
</author>
<author initials="N." surname="Miyake">
<organization></organization>
</author>
<author initials="D." surname="Boneh">
<organization></organization>
</author>
<author initials="J." surname="Mitchell">
<organization></organization>
</author>
<date month="" year="2005"/>
</front>
<seriesInfo name="Proceedings" value="14th Usenix Security Symposium"/>
</reference>
<reference anchor="SECIND" target="http://www.deas.harvard.edu/~rachna/papers/emperor-security-indicators-bank-sitekey-phishing-study.pdf">
<front>
<title>The Emperor's New Security Indicators: An evaluation of
website authentication and the effect of role playing on usability
studies</title>
<author initials="S." surname="Schechter " >
<organization></organization>
</author>
<author initials="R." surname="Dhamija " >
<organization></organization>
</author>
<author initials="A." surname="Ozment" >
<organization></organization>
</author>
<author initials="I." surname="Fischer" >
<organization></organization>
</author>
<date month="May" year="2007"/>
</front>
<seriesInfo name="IEEE" value="Symposium on Security and Privacy"/>
</reference>
<reference anchor="ANTIPHISHING">
<front>
<title>Limits to Anti Phishing</title>
<author initials="J." surname="Nelson">
<organization>Google</organization>
</author>
<author initials="D." surname="Jeske">
<organization>Google</organization>
</author>
<date month="January" year="2006"/>
</front>
<annotation>Proceedings of the W3c Security and Usability Workshop; http://www.w3.org/2005/Security/usability-ws/papers/37-google/'</annotation>
</reference>
<reference anchor="IABAUTH">
<front>
<title>A Survey of Authentication Mechanisms</title>
<author initials="E." surname="Rescorla">
<organization></organization>
</author>
<date day="22" month="February" year="2006"/>
</front>
<seriesInfo name="internet-draft" value="draft-iab-auth-mech-05.txt"/>
</reference>
<reference anchor="DIGEST-BIND">
<front>
<title>Channel Binding for HTTP Digest Authentication</title>
<author initials="S." surname="Santesson">
<organization></organization>
</author>
<author initials="K." surname="Damour">
<organization></organization>
</author>
<author initials="P." surname="Hallin">
<organization></organization>
</author>
<date day="" month="July" year="2008"/>
</front>
<seriesInfo name="internet-draft" value="draft-santesson-digestbind-01.txt"/>
</reference>
</references>
<section title="Trusted UI Mechanisms">
<t>There are three basic approaches to establishing a trusted
UI. The first is to use a dynamic UI based on a secret known
by the user; <xref target="ANTIPHISHING"/>
recommends this approach. A second approach is to provide a
UI action that highlights trusted or non-trusted components
in some way. This could work similarly to the Expose feature
in Apple's OS X where a keystroke visually distinguishes
structural elements of the UI. Of course such a mechanism
would only be useful if users actually used it. Finally, the
multi-level security community has extensive research in
designing UIs to display classified, compartmentalized
information. It is critical that these UIs be able to label
information and that these labels not be spoofable. </t>
<t>See <xref target="SERVER"/> for another case where
confidential information in a UI can be used to build trust.</t>
</section>
<section title="Change History">
<t>Note to rfc editor: This section should be removed prior to publication.</t>
<section title="Changes Since 08">
<t>Propose a new purpose section. Also, add a note describing what has been done to date on these issues.</t>
</section>
<section title="Changes since 07">
<t><list>
<t>Reword the abstract not to talk about identity providers</t>
<t>Define identity provider. I'm moving away from using it except where necessary, but I think that there a couple of cases where the term is helpful rather than confusing.</t>
<t>Add a paragraph to the introduction helping to define how this work fits in with other work. </t>
<t>Significantly rework the mutual authentication requirement to describe why pwdhash is excluded, to give more motivation and to try and clarify that authentication at different layers is problematic</t>
<t>Rework the requirement for binding authentication to requests and responses. The discussion of channel binding was obsolete and has been updated based on advances in that area. Drop the comment about redirect based schemes, because that depends on certificate validation and the W3C guidelines recommend accepting self-signed certificates in some cases.</t>
<t>Remove most references to identity providers from restricted identities section and protecting enrollment section. The concepts don't actually depend on whether an identity provider is used.</t>
<t>Rework the section on finding the right server to provide a more accurate description of image hints prior to login and to discuss the uncertainty surrounding the effectiveness of strategies discussed.</t>
<t>Rephrase terminology in security considerations to be consistent with changes throughout the rest of the document. Refer to the W3C guidelines as appropriate.</t>
</list>
</t>
</section>
<section title="Changes since 06">
<t><list>
<t>Much expanded description of concerns about weak
password equivalents. They are not excluded except by the
mutual authentication requirement. However there are
significant scoping issues with them.</t>
<t>Clarify that the effectiveness of confidential information being used to strengthen mutual authentication depends on users taking advantage of that.</t>
<t>Continue to clarify differences between plaintext password protocols and the password user interface</t>
<t>Reduce the use of the term identity provider; it's not entirely clear that concept needs to be worked in here and right now identity provider is an undefined term</t>
<t>The text on how to make trusted UIs sounded very authoritative; that was not the intent, so rework that text. </t>
</list>
</t>
</section>
<section title="Changes since 05">
<t><list>
<t>Clarified introduction to distinguish what happens at the TLS layer and what at the HTTP layer. Discuss motivation of phishing more.</t>
<t>In the introduction, restate claims to be more accurate. These requirements are useful if users actually use the authentication mechanisms; convincing them to do so and making it obvious whether they are is a significant risk. Also, we may give them the theoretical information necessary to detect fraud, but whether they act on that is open.</t>
<t>Add a purpose of this memo section. Whatever text ends up there after community discussion needs to be called out in the last call.</t>
<t>Add a section calling out the difference between plaintext password protocols and password interface. This needs to be worked into the rest of the document.</t>
<t>Update the threat model. Significant hopefully clarifying changes.</t>
</list>
</t>
</section>
<section title="Changes since 02">
<t><list>
<t>Updated discussion of TLS authentication to point out that it does meet the requirement of mutual authentication.</t>
<t>Added pointer to HTTP TLS channel bindings work</t>
</list>
</t>
</section>
<section title="Changes since 01">
<t><list>
<t>Updated threat model to give examples of attacks that are in scope and to more clearly discuss host security based on comments from Chris Drake.</t>
<t>Clarify attacks of interest to be consistent with the introduction. </t>
<t>Fix ups regarding one-time passwords. I'm not sure that OTPs can meet all the requirements but clean things up where they clearly can meet a requirement.</t>
<t>Clarify that in the mutual authentication case I'm concerned about authentication of client to the server.</t>
<t>Clean up bugs in security considerations</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
<!-- LocalWords: cryptographically
-->
| PAFTECH AB 2003-2026 | 2026-04-23 19:47:38 |