Network Working Group S. Hartman Internet-Draft MIT Expires: November 21, 2006 May 20, 2006 Requirements for Web Authentication Resistant to Phishing draft-hartman-webauth-phishing-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo proposes requirements for protocols between web identity providers and users and for requirements for protocols between identity providers and relying parties. 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 perform mutual authentication and flag Hartman Expires November 21, 2006 [Page 1]
Internet-Draft Web Phishing Requirements May 2006 situations when the target website is not authorized to accept the identity being offered as this is a strong indication of fraud. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Capabilities of Attackers . . . . . . . . . . . . . . . . 6 3.2 Attacks of Interest . . . . . . . . . . . . . . . . . . . 7 4. Requirements for Preventing Phishing . . . . . . . . . . . . . 8 4.1 Support for Passwords . . . . . . . . . . . . . . . . . . 8 4.2 Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 No Password Equivelents . . . . . . . . . . . . . . . . . 9 4.4 Authenticating the Server . . . . . . . . . . . . . . . . 9 4.5 Protecting Enrollment . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 6.2 Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Hartman Expires November 21, 2006 [Page 2]
Internet-Draft Web Phishing Requirements May 2006 1. Introduction 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 is often sent over a TLS [RFC4346] encrypted connection. As a result of this, the server learns the password and can pretend to be the user to any other system where the user has used the same password. The security of passwords over TLS depends on making sure that the password is sent to the right, trusted server. TLS implementations typically confirm that the name entered by the user in the URL corresponds to the certificate as described in [RFC2818]. 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. 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. This memo presents requirements that significantly reduce the effectiveness of the first category of phishing: these requirements guarantee that 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 can do is try to help the user detect fraud before they release confidential information. So, the approach taken by these requirements is to handle these two types of phishing differently. 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 or whether they are typing their password into a legacy mechanism that will send their password to the server. 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 Hartman Expires November 21, 2006 [Page 3]
Internet-Draft Web Phishing Requirements May 2006 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. Hartman Expires November 21, 2006 [Page 4]
Internet-Draft Web Phishing Requirements May 2006 2. Requirements notation 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 [RFC2119]. Hartman Expires November 21, 2006 [Page 5]
Internet-Draft Web Phishing Requirements May 2006 3. Threat Model This section describes the assumed capabilities of phishers, describes assumptions about web security and describes what vulnerabilities exist. We assume that the browser and operating system are secure and can be trusted by the end user. There are many attacks against browsers and operating systems. However without this assumption we cannot make progress in securing web authentication. So we will assume that browsers and operating systems are secure and note that other work to improve the security of browsers and operating systems is critical to the security of the entire web authentication system. 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. 3.1 Capabilities of Attackers 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. 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. 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. 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, if we want to avoid the user giving the attacker their password, we must transition to a solution where the user would not give the real target site their password. Instead they will need to cryptographically prove that they know their password without revealing it. Hartman Expires November 21, 2006 [Page 6]
Internet-Draft Web Phishing Requirements May 2006 3.2 Attacks of Interest The primary attack of interest is an attack in which the user sends confidential information to an unintended recipient. Another significant attack is an attack in which a recipient gains sufficient credentials to impersonate the user to other recipients. The obvious version of this attack is when the recipient learns the password of the user. However even giving the recipient a time- limited token that can be used to impersonate the user would be an instance of this attack. Note that some authentication systems such as Kerberos [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 this attack. Of less serious concerns at the present time are attacks on data integrity where a phisher provides false or misleading information to a user. Hartman Expires November 21, 2006 [Page 7]
Internet-Draft Web Phishing Requirements May 2006 4. Requirements for Preventing Phishing 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. The requirements discussed here are similar to the principles outlined in "Limits to Anti-Phishing" [ANTIPHISHING]. Most of this work was discovered independently but work from that paper has been integrated where appropriate. Google's perspective on phishing is very interesting because of their operational experience. 4.1 Support for Passwords The web authentication solution MUST support passwords and MUST be secure even when passwords are 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. IT is desirable that a solution support other forms of authentication such as smart cards and one-time passwords as these are useful in some environments. 4.2 Trusted UI 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 browser. The primary concern is to make sure that the user knows the password is being given to trusted software rather than being filled into an HTML form element that will be sent to the server. 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 UI; the Google paper [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. Hartman Expires November 21, 2006 [Page 8]
Internet-Draft Web Phishing Requirements May 2006 In addition to making sure that passwords are only given to trusted components, trusted UI will play another important role in the overall solution to phishing. Once the user is authenticated to the website then the website can use trusted UI based on a secret shared between the user and website to convince the user that they have authenticated to the correct site. This use of trusted UI dependes critically on the requirements of Section 4.4 to guarantee that the phisher cannot obtain the secret. It is tempting to use this form of trusted UI before authentication. For example, a website could request a user name and then display information based on a secret for that user before accepting a password. The problem with this approach is that phishers can obtain this information, because it can be obtained without knowing the password. However if the trusted UI is displayed after authentication then phishers could not obtain the trusted UI. This is one of the many reasons why it is important to prevent phishing targeted at authentication credentials. 4.3 No Password Equivelents A critical requirement is that when a user authenticates to a website, the website MUST NOT receive a password equivalent. A password equivalent is anything that would allow a phisher to authenticate to a third party as the user. There are two implications of this requirement. First, 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 [IABAUTH] seem potentially useful in this case. Note that mechanisms in this space tend to have significant deployment problems because of intellectual property issues. 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 cryptographically bind it to either the website that will receive the token or to a key known only to the user. 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. 4.4 Authenticating the Server The Google paper [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 Hartman Expires November 21, 2006 [Page 9]
Internet-Draft Web Phishing Requirements May 2006 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. Authentication of the server at the TLS level and authentication of the client within the TLS session is not sufficient. AS discussed previously the attacker can direct the user to a site that the attacker controls so the TLS authentication will succeed. Then the attacker can either ignore the authentication or attempt to tunnel the authentication exchange back to the real site. If successful such tunneling could allow the attacker to access the real site as the user. 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 protection that the right server is being contacted than if public key credentials are used. 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. 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. This set of requirements is incompatible with a model where the identity of the relying party is hidden from the identity provider. Sites that need this level of privacy may wish to provide their own identities or to provide aggregation points that can separate the identity provider from the site. The aggregation point needs to know the relying party, but the identity provider only needs to know the Hartman Expires November 21, 2006 [Page 10]
Internet-Draft Web Phishing Requirements May 2006 aggregation point. To prevent attacks where the authentication is tunneled, the protocol between the web browser and website MUST bind the authentication exchange to the channel created by the TLS session. The general concept behind channel binding is discussed in section 2.2.2 of [BTNS]. This paragraph needs to be expanded to point to proposals for doing channel binding with TLS. xxx 4.5 Protecting Enrollment One area of particular vulnerability to phishing is enrollment. 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. However there is one critical aspect in which enrollment impacts the security of authentication. During enrollment, a password is typically established for an account at an identity provider. The process of establishing a password MUST NOT provide a password equivalent to the identity provider. That is, the identity provider MUST NOT gain enough information to impersonate the user to a third party while establishing a password. Hartman Expires November 21, 2006 [Page 11]
Internet-Draft Web Phishing Requirements May 2006 5. Security Considerations 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. 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 or whether they are typing their password into a legacy mechanism that will send their password to the server. 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. This model assumes that the browser and operating system are a trusted component. As discussed in Section 3, there are numerous attacks against host security. Appropriate steps should be taken to minimize these risks. If the host security is compromised, the password can be captured as it is typed by the user. 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. 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; Section 4.2 discusses this requirement. IN addition, a significant risk that users will type their password into legacy HTML forms comes from the incremental deployment of any Hartman Expires November 21, 2006 [Page 12]
Internet-Draft Web Phishing Requirements May 2006 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 a 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. 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. 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. Hartman Expires November 21, 2006 [Page 13]
Internet-Draft Web Phishing Requirements May 2006 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2 Informative References [ANTIPHISHING] Nelson, J. and D. Jeske, "Limits to Anti Phishing", January 2006. Proceedings of the W3c Security and Usability Workshop; ht tp://www.w3.org/2005/Security/usability-ws/papers/ 37-google/' [BTNS] Touch, J., "Problem and Applicability Statement for Better Than Nothing Security", draft-ietf-btns-prob-and-applic-02.txt (work in progress), February 2006. [IABAUTH] Rescorla, E., "A Survey of Authentication Mechanisms", draft-iab-auth-mech-05.txt (work in progress), February 2006. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Author's Address Sam Hartman Massachusetts Institute of Technology Email: hartmans-ietf@mit.edu Hartman Expires November 21, 2006 [Page 14]
Internet-Draft Web Phishing Requirements May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hartman Expires November 21, 2006 [Page 15]